Topics discussed:
- The tabular profile adds nothing new — it just declares that every column returns a single scalar value, which the existing
collection: falseon 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
typerequired, 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
typeshould 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
fhirVersionquestion 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, andjoin()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.