Labelling a ViewDefinition's intent — enum, or a FHIR profile? — Mar 5, 2024

Labelling a view with its intended use

Views turned out to be useful for more than the original idea of a flat table of scalars — some people want nested structure or repeated fields — so the proposal was to label a view with its intended use.

Then tooling can check the view actually matches the label, and you can look at one and tell immediately that this can be exported as a CSV while that one is a more complicated structure.

Two ways to model it:

• An enumerated intent field on the resource
• A FHIR profile per intent

Profiles won on extensibility — new intents can be added as they emerge, with their own constraints, by anyone, from their own repository.

Two ideas hiding inside "intent"

The objection: intent is being asked to carry two unrelated ideas.

• Artefact identity — is this identified by a URI and published in an IG, or am I handing it to a Python library to run right now?
• Output capability — is the output flat like CSV, or a nested Spark schema, or JSON text in a column?

The answer was that profiles can carry both — but the mix was acknowledged rather than resolved.

The catch with profiles — for the tabular case, the profile is almost empty

There's no way to express every column is a non-repeated scalar as a checkable constraint, so it works as a tag and nothing validates it. There is precedent for profiles that attach semantics the tooling can't enforce.

The argument that carried: one mechanism rather than two. Profiles genuinely pay off in the shareable case, where the constraints are real — require the URL, require the name, require experimental to be false.

Not v1 scope

Nobody argued for any of this in the first version — nothing is v1 scope except what we've got.

Two practical snags noted:

• The ViewDefinition is a logical model rather than a resource, so it has no meta in which to declare which profiles it conforms to
• Profiling logical models pokes at the corners of the FHIR tooling that are less well tested

A view runner does more than run

There's validating a ViewDefinition, inferring the schema it will produce, and just answering can you run this at all? — operations that stop short of executing anything, and that the spec could describe as roles you either implement or don't.

It matters because layers get built on top: Pathling is being re-architected to use ViewDefinitions as its primitive, with things like aggregate running FHIRPath over the schema the first layer produced — which only works if you can infer that schema from the view.