Inter-query dependencies merged, and Steve's six consistency fixes open the FHIR async mess — Jun 9, 2026
Inter-query dependencies landed
In both the spec and the reference implementation.
John split them into two profiles — SQL Query and SQL View, the same shape except a View can't take parameters — and grouped them under a single SQL menu item because the navigation was getting crowded.
The open question he left: whether you can actually run a SQL View. Nikolai's answer: yes, and you can export it as CSV too — it's just a bad idea on a large dataset.
Steve's six consistency fixes (#358–#363)
The kind of drift you only notice when you build all four operations rather than one. Good ideas had been sprinkled into the newer operations and never backported to the older ones.
His fix: a single operations-common.md page holding everything the four operations share, so there's one place to change instead of four.
Nikolai wanted the refactor done first with no semantic changes at all, then the changes layered on top of it.
Chunked encoding (#361) — resolved by drawing the line
Streaming only means anything for the run operations, because export never hands back data — it hands back a manifest of file locations.
And those locations are deliberately unspecified; the spec says URI, which might be an internal bucket or a local path, and might not be HTTP at all. How the client fetches the file is out of scope.
#363 — 303 or 200 for async completion — unanswerable
FHIR now has three competing async patterns:
- The original ad hoc bulk data JSON manifest
- The R5 bundle-based one
- Josh Mandel's newer incubator version
Nikolai prefers Josh's, because it drops the forced Bundle response and separates the status code for are you finished? from the status code for the result.
John's objection was practical: he implements async once in Pathling and uses it for every operation, and won't maintain different semantics per operation.
Nobody in the room could say where the incubator IG had actually landed.
Nikolai — seed a community FHIR-to-OMOP project
His argument: the valuable part isn't the transformation code — it's the corner cases.
A single Condition can land in three different OMOP tables depending on the code; one ICD-10 code can fan out into several SNOMED codes and several rows.
His unit for that is a test case: some FHIR resources in, the expected OMOP rows out, and a note explaining why.
Arjun liked the framing of a shared evaluation framework rather than yet another implementation.
John's worry was engagement — that it quietly becomes two people working alone unless the wider community is brought in properly.