First API release ships R4-compatible — because R4 is what people will run for years yet — Sep 23, 2025
R4-compatible, not R4
It isn't an R4 spec, it's R4-compatible, because what we're publishing is a logical model rather than a real R4 resource.
My personal view is that the world will sit on R4 for many years, so publishing something that works there is good enough — and the remaining work is editorial rather than a matter of open decisions.
Why not hand-build a multi-version spec
FHIR may be about to grow one properly. FHIR-I is pulling some resources out of core and into IGs for R6, and there's an active discussion about whether those IGs should be multi-version — nobody wants to maintain a separate spec per FHIR version, or per US Core version for that matter.
If IG Publisher grows support for that, SQL on FHIR would use it. So: R4 now, and wait rather than invent conditional machinery by hand.
Arjun — FHIR-to-OMOP shouldn't be a one-way street
Filling data into OMOP is worthwhile and everyone should go to town on it, but he wants the more controversial direction too — OMOP back out into tabular FHIR, or whatever you call the output of a ViewDefinition.
He also thinks the first is the stepping stone to the second: build tabular schemas of FHIR resources shaped for loading into OMOP, and those same schemas become the targets when you reverse the transformation.
There is no one true data model and never will be. You shape data for the use case — which is exactly why multiple representations of the same thing exist.
Rust FHIRPath engines keep multiplying
The Helios one is out and open source, another is being built in the Octo tooling, and others are in progress.
A good FHIRPath engine is roughly a year of work. My own team is months in with prior experience and still not done.
The interesting side effect: building one seriously surfaces real gaps in the FHIRPath specification itself, which is where his recent run of questions on the FHIRPath channel came from.