Should a ViewDefinition state its column types, or infer them? — Jan 16, 2024

The proposal — flip inference from expected to optional

The spec currently expects implementations to infer column types, and that should flip. A shareable ViewDefinition ought to state its types, with inference as an optional feature of a smarter implementation.

The reason is cost — inference means walking StructureDefinitions, handling choice types and complex types, and someone who has written that from scratch reported it is a significant chunk of work. It only matters when the target is typed: a database table, Parquet or protobuf care, a CSV export does not.

Dynamic evaluation vs typed storage

The counter was that inference belongs at the FHIRPath level, not the FHIR level — if you can parse a FHIRPath expression you should know its FHIRPath type, and not every expression even has a FHIR type (a comparison operator does not).

The reply drew the real line: a dynamic engine like HAPI applies a path to an actual resource and hands back Base objects, so it never needs to know how a Patient is shaped. But creating a table means there is no resource — you have to answer what type this path will yield for some future Patient, and that is where StructureDefinitions come in.

Dynamic evaluation, statically typed storage.

The existing design's rationale

From a long thread back in September: inference was deliberately constrained so no full path parser is needed. Either it is a simple path off a root resource — look the key up in the StructureDefinition — or it is an ofType() expression, and anything else requires an explicit type.

The trade-off was chosen for authoring ergonomics: you should not have to write boolean every time you write patient.active. Nobody claimed it was the necessary right answer; it was a judgment call about where to put the cost.

Three type systems in play — the source of most of the confusion

• FHIR's types — from the data model
• FHIRPath's — much smaller set (boolean, string, integer, decimal, date, dateTime)
• The database's

Does an implementation need to know an element is markdown, or is a string enough? The coarse FHIRPath set is tempting until you notice it collapses date and dateTime, which very much matters at the database level.

Separately, a proposal to strip the ANSI database type hint out of the spec entirely and leave it to implementations.

Where it settled

Types will not be required by default, and the discussion moves back to Zulip where it has history.

Two ideas floated for later:

• Draft versus finalised ViewDefinitions, where an authoring tool with inference emits a fully typed final version
• Hanging the requirement off the shareable profile that has been discussed but never actually built

The instinct expressed was to push complexity onto the small set of deep implementers rather than the much larger set of IG authors, who should not be counting types through their own FHIRPath by hand.