Cutting the last change down to a single link so v2 can ship, and what SQL on FHIR adds to FHIR-to-OMOP — Sep 10, 2024

Minimise the change, ship the release

The only thing standing between the group and a tag was where to link the functional model page from. The argument that won was explicitly about shipping: minimise the change, put a short for more information link at the top of the ViewDefinition page and in the table of contents, and stop dragging out a release that is otherwise done.

Then call it a release candidate on Zulip, and if nobody objects, declare it released.

What SQL on FHIR adds to a FHIR-to-OMOP conversion

The worry coming back from the Vulcan side: this is yet another FHIR-to-OMOP transformation that ignores what they have already learned.

The response the group wanted to make: it isn't a conversion project at all — it's a way of proving out and improving SQL on FHIR. And a conversion built on a standard view layer has genuinely different characteristics from one written directly against FHIR.

A concrete objection to how the mapping was being collected

Listing FHIR elements down one side and asking people to fill in the OMOP column opposite can't express the real work. Getting to a given OMOP column usually needs a FHIRPath expression — pulling a race extension, say — not a field-to-field correspondence.

Starting from the OMOP columns and working back is the direction that survives contact with the data.

The hypothesis worth testing

There is real variability in how FHIR-to-OMOP can be done, and a common set of intermediate views might absorb most of it, so the last mapping step becomes simpler than reaching into FHIR elements directly. The only way to find out is to run it through a couple of genuinely different scenarios.

The IG publisher is two things at once

• It runs views over resources during publication into a SQLite database
• It validates any ViewDefinitions in the guide

Its validator doesn't understand forEach: it sees a path that can return a list and complains you haven't set collection, when forEach has already unnested it.

Related, and unresolved: ViewDefinitions written for R4 fail against an R5 default, which raises the question of what an engine should do when a view declares one FHIR version and the resource is another.