SQL on FHIR WG Meetings
SQL on FHIR WG Meeting — April 23, 2024
Apr 23, 2024

Topics discussed:

  • The tabular profile adds nothing new — it just declares that every column returns a single scalar value, which the existing collection: false on a column already expresses. The point is to give the common flat case a label you can point at, the same way you set any profile on any FHIR resource.
  • The shareable profile makes column type required, and the group could not settle it. Requiring it buys stronger profile validation; leaving it optional and assuming string saves you writing type strings in a lot of places where they would be obvious. Good arguments both ways, so it stayed as it was for now.
  • Someone asked whether type should be bound to a value set. All FHIR primitives is too broad — that lets through markdown and id — so it needs narrowing to a sensible set, possibly just the FHIRPath built-in primitives. Nobody had checked whether such a value set already exists.
  • The fhirVersion question turned out to be about FHIRPath, not FHIR. join() with no argument throws in one Java implementation and works in another, which traces to implementation versions rather than FHIRPath versions — only two versions of FHIRPath have ever been published. Whether a FHIRPath version needs pinning too was left open, with a clear preference for not having to.
  • A new implementer working through the tests found two bugs: a test asserting the FHIR type name, which is not a type, and join() over an empty collection returning an empty string where the spec says empty input gives empty output — probably the JavaScript FHIRPath engine, so it needs reporting upstream. Their verdict on the JSON tests was that the implementation would not have been possible without them: some things are just hard to describe in words, and you need a test to fail to see why.