Skip to content

Why they need each other

This is the chapter to read before a meeting where someone asks why the organization is paying for both.

The short answer

Exchange without analysis is a filing cabinet. Analysis without exchange is a silo that cannot be refreshed. An organization that has only FHIR can move data and cannot learn from it at scale. An organization that has only OMOP can learn from a snapshot and cannot easily get the next one.

What FHIR gives an OMOP program

A supply line that already exists. In the United States, certified EHR technology has to expose FHIR APIs under the ONC certification requirements that flow from the 21st Century Cures Act. That regulation did something no research program could have done on its own: it made a standardized clinical data interface a routine feature of production health IT rather than a custom integration project.

Before that, building an OMOP instance from an EHR meant a bespoke extraction against a proprietary schema, negotiated per vendor and per version, often per site. Now there is a defined starting point. It is not effortless, but it is a different order of problem.

Refreshability. A bespoke extract is a project. A FHIR interface is a service. The difference shows up when someone asks for updated data, which they always do. A pipeline built on a documented API can be rerun; one built on a hand-negotiated database extract often cannot without repeating the negotiation.

Portability of the acquisition layer. A Bulk FHIR export from one conformant server looks broadly like a Bulk FHIR export from another. Your acquisition and staging code has a real chance of transferring across sites. The transformation still needs site-specific work, but the plumbing generalizes.

A validation surface. FHIR resources can be validated against profiles mechanically. Errors caught at the FHIR layer are errors that never reach your OMOP CDM, and they come with machine-readable messages rather than a puzzled analyst noticing something looks wrong three months later.

What OMOP gives a FHIR program

A question the data can actually answer. FHIR can tell you everything about one person. It cannot easily tell you the incidence of a condition, the comparative safety of two drugs, or whether a care pathway changed outcomes. Those questions need a population-scale relational structure with standardized terminology, and that is the thing OMOP is.

Comparability across institutions. Two hospitals with conformant FHIR servers can still code the same clinical idea differently, because base FHIR permits it and profiles constrain it only partially. Two hospitals with OMOP instances have run their codes through the same standardized vocabulary, so a concept set means the same thing in both. That is what makes network studies possible.

A method ecosystem. OHDSI has spent years building analytical methods, tooling, and empirical calibration approaches that assume the OMOP CDM. ATLAS for cohort definition, the HADES packages for analysis, the Data Quality Dashboard for validation, Achilles for characterization. Adopting the OMOP CDM means adopting all of that, which is a much larger gift than the schema itself.

Federation without data movement. Because the model and vocabulary are shared, an analysis can be written once and executed at many sites, with only summary results returned. Sensitive data stays home. That property is what makes multi-institution research feasible under realistic governance, and it depends entirely on the standardization that OMOP provides.

The pairing, stated plainly

FHIR is how the data gets to you. OMOP is how the data becomes evidence.

They are not competitors and the choice between them is not a real choice. An organization doing serious observational research needs a reliable acquisition path and a rigorous analytical structure, and these are the two standards that have achieved enough adoption to serve those roles.

The joint work, and why it is happening now

The HL7 and OHDSI communities have been formally collaborating since 2021 with the goal of aligning the two models. That collaboration has moved through several stages: general guidance and a cookbook, domain-specific pilots including oncology work grounded in mCODE, connectathon testing, and now a published implementation guide with an active ballot.

The FHIR to OMOP Implementation Guide is developed under HL7's Vulcan accelerator in collaboration with OHDSI. Edition 1 was published as an informative specification in April 2026, and a version is currently going through Standard for Trial Use ballot in the September 2026 cycle.

The practical significance is that the transformation is moving from folklore to specification. For years, every organization solved these problems independently and the solutions lived in institutional memory and internal wikis. A balloted guide means the decisions get written down, reviewed on the record, and improved by the accumulated judgment of people who have made them before.

If you are doing this work, you are exactly the person whose experience the guide needs. See the IG chapter for how to read it and how to participate.

Talking points for the meeting

If you need to defend the pairing to someone controlling a budget:

  • FHIR is already required infrastructure under certification rules, so the acquisition layer is largely a sunk cost that the research program can use rather than a new expense
  • OMOP is the entry ticket to multi-institution research networks, which is how a single site gets access to population sizes it could never assemble alone
  • The combination lets sensitive data stay local while still contributing to and benefiting from network-scale evidence
  • The transformation between them is being standardized right now, which lowers the long-run cost of maintaining it and reduces the risk of building something idiosyncratic

Next