Nikolai's five API use cases, and Brian's rival sketch built on CRMI packaging — Feb 25, 2025
Bashir on Parquet on FHIR's non-goals
The draft's non-goals section listed query writer experience as out of scope, but a query that fails because a field is missing isn't a matter of taste.
Arjun agreed the error condition is a top-level requirement — what he'd meant to rule out was massaging the schema so queries read more nicely to non-experts, which he argued is SQL on FHIR's job, not Parquet on FHIR's.
Someone who wants a Parquet file out of a FHIR system and their own SQL over it, with no ViewDefinition anywhere — that case belongs in scope too.
Why the draft splits comprehensive from focus
Comprehensive serves the raw-SQL user, but it forces whatever builds it to know all of FHIR and to take a haircut on capability — recursion has to stop somewhere. Focus has no such limit and zero loss, and is what a runner sits on.
The point: converting between the two is cheap, so the split costs nothing compared with tools inventing incompatible schemas.
Bashir thought the draft's recursion depth of six was huge. John said Pathling uses three, that it should be hard-coded rather than a parameter, and that he doesn't know the right number.
Nikolai — what an API actually has to do
- Discovery — through the capability statement
- Asynchronous bulk export
- Synchronous evaluation — for debugging a view
- Authoring — pointing a ViewDefinition builder at any runner, the way Brian's FHIRPath lab switches engines
- A black box — takes a set of views plus queries and hands back results
The last one is the one I care about. Hospitals shouldn't have to know there's a bucket to download from before they can report a metric.
Brian — the other end of the life cycle
Publishing views as FHIR packages through the IG publisher, identifying them by canonical URL and version rather than the logical id a server happens to mint, and pulling a whole set down with CRMI's $package on an ImplementationGuide.
He'd also drafted an $execute operation following CRMI's knowledge-artifact semantics, so it looks like the CQL and measure operations people already know.
Nikolai said run was the better name, since the thing is called a runner. The Binary in Brian's draft was only there because ViewDefinition isn't a real FHIR resource yet and the tooling complains.
Steve — running views on top of $export
Only needed one extra viewDefinition parameter to inherit since and type.
What he'd found users want is the job now, on a cron, or continuously — and continuous needs an as-of date to mean anything.
Nikolai pointed at the part nobody has solved: once the result is a pile of files in a bucket, updates and deletes have nowhere to go, so you can't just keep appending pages of new data.