Topics discussed:

• A test asserted integer where the arithmetic runs over Range.low and Range.high, which are decimals — add two decimals and you get a decimal. FHIRPath does implicit conversions but never decimal to integer, and SQL on FHIR does not infer types at all: you declare the type, and a wrong declaration should error. The reference implementation is oddly tolerant, so tests it passes can still fail on a stricter runner.
• The value set of FHIR versions includes abbreviated, non-release entries like 4.0. The concern is that you can pin to something that is not a real release and whose fields differ from the version you actually meant, so declaring a version should probably be constrained to full releases — 4.0.1, R4B, R5.
• On Parquet the leaning was to standardise the general, lossless, nested representation first and let a view runner cut it down afterwards. It will never match a purpose-built representation for speed, but it takes the raw-FHIR work off everyone: you get standard tooling on top, and you only spend the extra effort when your requirements actually justify it.
• The bulk data angle: continuously serialising huge amounts of data into JSON is expensive on export, and import has the same problem in reverse. The open question was whether removing the JSON serialisation step entirely would make the scalability problems go away, or just move them.
• Parquet is not always one file — it is commonly a directory partitioned on something like patient id or date, much like partitioning in a SQL database, so each Spark worker takes a slice. Whether implementations must tolerate partitioned Parquet was raised and left open. The reasons an implementer wanted Parquet at all were plain: compression, an intermediate format for loading into SQL tables, and reading one column directly instead of a thousand JSON files.