Two things that got called ergonomics
The Parquet on FHIR draft listed query portability and query-writer experience as non-goals. Bashir objected: a query erroring because a field is absent isn't an ergonomics nicety, it's a top-level requirement.
The distinction drawn in reply: making a schema pleasant to write queries against is SQL on FHIR's job, but not being able to know in advance whether your query will blow up is a different class of problem entirely.
Two implementation patterns
- Parquet as substrate under a ViewDefinition runner
- Someone who wants nothing to do with ViewDefinitions — just Parquet out of a FHIR system that they can point raw SQL at
The second was argued to be in scope and drew agreement, and the next draft is meant to make both patterns and their goals explicit.
Comprehensive vs focused, plus recursion depth still open
The comprehensive schema serves the raw-SQL user, but its builder needs full knowledge of the FHIR spec and has to take a haircut on capability, since recursion must stop somewhere. The focused schema has no such limit and can be truly zero-loss, and suits runners.
The important part: the two are compatible and cheap to convert between — unlike the incompatible schemas different tools have each invented.
Recursion depth stayed open: the draft said six, Pathling uses three, and six was called huge.
Nikolai — API use cases
- Discovery via CapabilityStatement
- Bulk export
- A synchronous real-time mode for debugging
- A black-box job where you post ViewDefinitions plus queries and get results back without caring what happened in between
The authoring case has a concrete payoff — a standard API would let the ViewDefinition builder point at any runner, the way FHIRPath Lab switches engines.
He also flagged that bulk export kicks off via GET, which he argued breaks HTTP semantics for a state-changing operation. Left for next time.
Brian — the publishing side
ViewDefinitions in a FHIR package via the IG publisher, marked as definitions rather than examples so tooling treats them as knowledge artifacts, distributed as npm tarballs through the FHIR package API, and referenced by canonical URL and version — because a logical ID is whatever that one server chose to mint and refers to nothing universally.
$package on the ImplementationGuide pulls the whole set. His $execute sketch had to declare its ViewDefinition parameter as Binary, because ViewDefinition still isn't a resource and the tooling complains otherwise.