openEHR

In one line

openEHR separates clinical knowledge from software: a small, stable reference model plus clinician-authored archetypes (maximal data models for concepts like blood pressure) composed into templates — so the record outlives any application.

The problem it solves

In a conventional EHR, the clinical content — what a "blood pressure" record contains, which fields a discharge summary has — is baked into the application's database schema. Change the content and you change the software; replace the software and the data model (and often the data) is at risk. openEHR's bet is that clinical knowledge changes far faster than it should be allowed to break the record, so it pulls that knowledge out of the code.

Two-level modelling

This is the core idea, and it's worth getting precise:

• Level 1 — the Reference Model (RM). A small, stable, generic information model (compositions, entries, clusters, data types). Engineers build software to the RM once; it almost never changes.
• Level 2 — archetypes. Clinicians define maximal data models for clinical concepts — an archetype for "blood pressure" includes systolic, diastolic, position, cuff size, everything anyone might record. Archetypes are authored and governed in open libraries (the international Clinical Knowledge Manager, CKM), not by programmers.
• Templates then constrain and combine archetypes for a specific form or document (an antenatal visit might use 8 archetypes, hiding fields it doesn't need).

Because software targets only the stable RM, new clinical content is new archetypes/templates (data), not a new release (code) — the same "configuration over code" principle behind much of modern health IT.

Querying: AQL

Data persists in vendor-neutral clinical data repositories and is queried with AQL (Archetype Query Language) — an archetype-aware query language that asks for clinical meaning ("every systolic BP > 140 for this patient") independent of how any app stored it.

openEHR vs FHIR — not a rivalry

The most common confusion. They optimise different things:

	openEHR	FHIR
Optimised for	the persistent record (storage)	the exchange interface (APIs)
Strength	deep, governed clinical models; longevity	developer reach; quick integration
Typical role	inside the system, for decades	at the edges, between systems

Many modern architectures use both: openEHR (or a similar model-driven store) as the durable record inside, FHIR at the boundaries for exchange.

Where it shows up in digital health

National and regional EHR programmes (strong adoption across parts of Europe — e.g. national records — and growing in the Nordics, UK regions, and beyond), vendor-neutral clinical data repositories, and any project whose horizon is decades, where "the app will be replaced but the record must not die" is the requirement that picks the architecture.

Common pitfalls

• Treating it as a FHIR competitor — they solve different problems; choosing one because you rejected the other usually means you've mis-framed the need.
• Skipping clinical governance — the model's value comes from clinician-authored, peer-reviewed archetypes; let engineers invent them and you lose the point.
• Underestimating the learning curve — the RM/archetype/template/AQL stack is powerful but conceptually heavier than CRUD-on-FHIR.

Key takeaways

• openEHR keeps clinical models outside the software, so records outlive applications.
• Two-level modelling: stable RM (engineers) + governed archetypes/templates (clinicians).
• AQL queries by clinical meaning, vendor-neutrally.
• Think "openEHR inside, FHIR at the edges" — complementary, not competing.