SQL on FHIR WG Meetings
SQL on FHIR WG Meeting — May 17, 2024
May 17, 2024

Topics discussed:

  • The boundary functions ran into JavaScript itself: numbers are 64-bit doubles, so you get about 16 significant digits, while FHIR decimals need more. Rather than build a separate fixed-point decimal, the group decided to treat it as a known issue in the JavaScript FHIRPath engine and fix it upstream. The reference implementation is allowed to fail that test — better that than every other implementation inheriting the bug.
  • Which led to a rule worth stating plainly: the tests assert what the FHIRPath specification says, not what the JavaScript engine does. The reason field already in the test framework covers the rest — you record why a test is skipped instead of inventing an excluded status — and the implementation dashboard should surface that reason rather than showing a bare fail.
  • A proposal to add sorting to ViewDefinition, carried over from data requirements, which have sort and limit. The objection: a ViewDefinition sees one resource at a time, so sorting inside one resource is easy but useless, and sorting the output table is out of scope — that is what SQL is for. If sort and limit belong anywhere it is on a future operation that materialises a view, since they flex at runtime while a ViewDefinition should be static. Left out.
  • That exchange exposed a gap in the narrative. People arrive assuming a ViewDefinition is "SQL in FHIR language" — an easy mistake to make, and partly the spec's fault for talking in end-to-end use cases. The scope is one resource at a time, no joins, no cross-resource anything; it is a building block you then build your SQL on. An issue was logged to state the non-goals explicitly.
  • For Parquet the next step is concrete rather than abstract: pick one resource — Patient, or US Core Patient so extensions are in play — have everyone who has done this share their actual Parquet schema before the meeting, and expect maybe 80% to agree, so the discussion can go straight at the 20% that does not. The original SQL projection document is the common ancestor of the existing implementations, so it serves as the shared baseline.