Anyone building a platform for health data has to decide early in which model the data is stored internally. FHIR is the obvious candidate, because it is required at the interfaces anyway. openEHR and OMOP come up regularly as well. This article places the three standards and explains why none of them should automatically become the internal data model.
FHIR, openEHR, and OMOP solve different problems
FHIR is an HL7 standard for data exchange. It defines resources such as Patient, Observation, or MedicationRequest and a REST API through which systems read and write those resources. The resources are cut so that each can be transmitted on its own, without further context. In Germany, FHIR is mandatory for many systems through ISiK, the ePA, and the MIOs.
openEHR is a model for the long-term storage of clinical information. It separates a stable technical reference model from the clinical content models, the archetypes, which are maintained by clinicians. The goal is a patient record whose meaning survives decades and system migrations. openEHR is designed for persistence. Exchange with foreign systems is only a side concern.
OMOP is the common data model of the OHDSI community for research on observational data. It maps data from many sources into a single relational schema with standardised vocabularies so that the same analysis can run at different sites. Context and detail are deliberately lost in the process. OMOP is not intended for operational care.
The three models therefore answer different questions: how systems exchange data, how clinical meaning is preserved over time, and how data becomes comparable for analysis. None of them replaces another.
An exchange standard is not a database schema
Grahame Grieve, who initiated FHIR, addressed the question of whether to store FHIR resources as FHIR at the FHIR DevDays in 2022. His framing: HL7 standardises the interfaces between applications and says nothing about what happens inside an application. FHIR resources are designed for robust exchange and deliberately denormalised for that purpose. Querying a native FHIR store directly he describes as exhausting.
The reason lies in the requirements of an operational system. It has to ensure data integrity, enforce permissions, query quickly, and evolve with its own domain logic. A model optimised for exchange between foreign systems meets those requirements only by accident. The same applies to OMOP, which is designed for analysis. Grieve sums up the difference simply: operational data needs context and precision, analytical data needs uniformity.
Storing FHIR directly makes sense when the application itself is a FHIR server, for example as a facade in front of existing systems or as a hub for exchange. Once an application carries its own domain logic, a model of its own with a FHIR interface in front of it is the more robust choice.
Interoperability comes from preserved meaning
Whether a lab value is stored internally as a FHIR Observation is secondary. What matters is what is known about it: the concept, for example as a LOINC code, the unit in UCUM, the time of measurement, the source, and the status in case the value was later corrected. If those attributes are present, a FHIR Observation can be generated from them at any time, and so can a row in the OMOP Measurement table. If they are missing, a FHIR-shaped data structure does not help.
Interoperability is therefore first of all a matter of semantics. It arises when systems use the same terminologies and carry the same accompanying attributes. The relevant terminologies are well known: LOINC for lab values, SNOMED CT for clinical concepts, ICD-10-GM for diagnoses, ATC and PZN for medicines, UCUM for units. In Germany, SNOMED CT has been licensed through the BfArM since 2021 and is free to use within the country.
In practice this means keeping FHIR in mind while modelling. The profiles required at the interfaces, for example from the ISiK base module or the MIOs, define which codes and value sets are mandatory. Those bindings belong in the internal model from the start. The structure of the FHIR resource itself does not need to be replicated there.
What must be structured
A model of your own does not mean giving up structure. Certain information has to be deterministic, because applications and people make decisions on it: identities of patients and encounters, timestamps, measurements with units, the status of medications and diagnoses, consent and permissions, the origin of every piece of information, and its versions.
For this core, a normalised model with fixed terminology bindings pays off. Other information, such as free text from reports or raw data from devices, can be stored in its original form and structured only when a use case requires it. Provenance has to be preserved in both cases.
Recommendation
The internal data model should follow from your own use cases. FHIR belongs at the interfaces, with the profiles and terminologies required there. OMOP can be generated later from a semantically clean model, once research or quality reporting calls for it. openEHR is worth studying as a model for modelling, even if you do not adopt the stack. The separation of a technical reference model from clinical content models, and consistent versioning, carry over.
The same applies to AI systems. A language model that is meant to interpret clinical data needs meaning, time, and provenance. The schema in which the data sits internally is irrelevant to it.