FHIR, openEHR, or OMOP? Building a health data platform means deciding how to store its data. These three standards serve different purposes. The right internal model depends on what the platform needs to do.
Three standards, three purposes
FHIR describes how systems exchange health data. It provides resources such as Patient, Observation, and MedicationRequest. Profiles specify more precisely what an interface expects. Examples from Germany include ISiK and the MIOs.
openEHR focuses on the long-term storage of clinical information. It separates the technical reference model from clinical content models, known as archetypes. Clinical content can therefore evolve without changing the technical foundation each time.
OMOP standardises data for research. A shared database schema and standardised vocabularies enable comparable analyses across different data sources. Some details of the original context may be lost during conversion.
The model follows the application
A FHIR interface does not require everything to be stored internally as FHIR resources. An application can use its own model and translate data into FHIR for exchange. Storing resources directly can make sense when the platform mainly receives, manages, and passes on FHIR resources.
The platform’s tasks are what matter: which data belongs together? Which queries need to be fast? How are changes, access rights, and clinical rules represented? These questions should guide the choice. A custom model offers flexibility but also requires maintenance and translation. openEHR can provide a foundation for clinical data storage; OMOP primarily supports analysis.
Semantics matter more than syntax
Sharing data depends on systems understanding its meaning in the same way. Syntax describes how data is structured; semantics describes what it means. A shared format makes exchange easier, but is not enough on its own.
A laboratory result illustrates the difference: storing it in a custom table or as a FHIR Observation does not, by itself, tell us what was measured. That requires the measured quantity, unit, time of measurement, and patient association. Codes such as LOINC for the measured quantity and UCUM for the unit make the meaning explicit. If these details are missing, storing the result as a FHIR resource does not solve the problem.
For model selection, this means the internal structure can vary, but the required meaning must be preserved. Review the intended FHIR profiles and, where relevant, OMOP requirements during design. They establish which details and codes your model must contain and how these can be mapped. This makes translation part of the design from the start.
A practical decision
Start with the actual workflows, queries, and interfaces. Use them to assess whether FHIR, openEHR, or a custom model best supports internal data storage. Plan for translation into the required exchange formats from the outset. If OMOP is needed for research or quality analysis, consider its requirements early too.
Future AI applications need the same foundations: clear meaning, temporal context, and traceable sources. Preserving this information is a central task of the data model.