Debunking 5 Myths about openEHR

For information managers at large-scale healthcare organisations and regions, the dream is clear: a ‘vendor-neutral’ data layer where clinical information outlives the applications that created it. These days, this vision almost naturally leads to an exploration of openEHR as a solution.

However, because openEHR represents a significant shift from traditional ‘application-centric’ thinking, it is often surrounded by persistent myths. To help you build a sound data strategy, we decided to debunk five of the most common misconceptions.

1. “We don’t need openEHR, because we already use FHIR.”

This is perhaps the most common misunderstanding in healthcare IT today. It stems from viewing FHIR and openEHR as competitors. In reality, they solve two different problems.

• The Myth: FHIR is a complete solution for data persistence and clinical modeling.
• The Reality: FHIR (Fast Healthcare Interoperability Resources) was primarily designed for exchange, moving data between systems. Meanwhile, openEHR was designed for persistence. The long-term, high-fidelity storage of clinical data.

FHIR is excellent for sharing specific resources (like a medication list), but it does not define how a hospital should structure its entire clinical record for the next 20 years. Using them together, openEHR for your internal Source of Truth and FHIR as the API for external exchange, is the gold standard for innovative healthcare organisations.

2. “openEHR is just a modeling standard (or just a database).”

Depending on who you talk to, openEHR is either described as “just a modeling standard” or “just a Clinical Data Repository” (CDR). Neither is the full story.

• The Myth: You only need openEHR to model data and templates, or you only need it as a storage bucket.
• The Reality: openEHR is a multi-level platform architecture. It consists of:
  • The Reference Model (RM): The fixed technical ‘bricks’ (the software code).
  • Archetypes & Templates: The clinical ‘blueprints’ (the medical knowledge).
  • The CDR: The engine that stores data according to those blueprints.

If you only use the models, you have a nice dictionary but no book. If you only use a CDR without understanding the models, you’ve just bought another proprietary database. The power lies in the separation of software from clinical knowledge.

3. “openEHR is an academic project, not a production-ready standard.”

Because openEHR grew out of university research and has a heavy emphasis on ‘formalisms’, some IT leaders fear it’s too ‘ivory tower’ for the everyday reality of large-scale healthcare organisations.

• The Myth: openEHR is a theoretical framework that lacks large-scale, real-world ‘battle testing’.
• The Reality: We are well past the theoretical phase. Entire regions and countries have moved toward openEHR-based regional records and our very own VAR CODE24 developed its EHR system entirely on openEHR since as early as 2010.

openEHR is powering high-volume clinical systems in some of the most complex healthcare environments in the world. It is not an experiment; it is an industrial-strength architecture for those who have outgrown the limitations of legacy EHRs.

4. “We will have to create new archetypes for every single use case.”

When clinical teams start with data modeling, they often try to recreate their existing paper or digital forms as case-specific archetypes. This is a strategic mistake.

• The Myth: An archetype should be designed for a specific use case, like a Cardiology Admission Form.
• The Reality: Archetypes are designed to be usage-agnostic and inclusive. Many have already been modeled by the openEHR Community and are made available for free in the Clinical Knowledge Manager (CKM) of openEHR International, a global repository of thousands of peer-reviewed archetypes.

An openEHR archetype is a universal definition of a clinical concept (e.g., ‘Blood Pressure’). It contains every possible data point anyone might ever need. The template is where you constrain that archetype for a specific use case (e.g., ‘School Nurse Check-up’). By reusing universal archetypes (from the CKM) across different templates, you ensure that ‘Blood Pressure’ recorded in the ER is recorded the same way as ‘Blood Pressure’ recorded in the ICU, enabling seamless data aggregation. In short: you don’t build the bricks, you choose which ones to use to build your house.

5. “openEHR is only for the clinical domain – for demographic data you need FHIR.”

Most people familiar with the basics of openEHR know how it can be used for clinical data, but they do not realise that openEHR also offers specifications for modeling demographic data.

• The Myth: openEHR is not suited to handle demographic data.
• The Reality: The openEHR Demographics Specifications are of good quality and based on the same archetype/template design as the specifications for clinical data.

While it is, of course, not wrong per se to use openEHR for clinical data and FHIR for demographic data side by side, there are definitely benefits to using openEHR for both, which we explain in more detail in this article. The Cadasto data platform allows for combined queries of both openEHR clinical data and demographic data.

Knowing What We Are Dealing With

To support organisations and regions in making the right decisions for their care data foundation, we believe that it is important to debunk common myths such as the ones described above. You have to know what you are dealing with in order to make informed decisions that will help your organisation for the long term.