In openEHR the clinical meaning of a piece of data lives in an artefact separate from the code and the database schema — the archetype — written in a formal language and versioned on its own, independently of the software that runs it. This is where openEHR breaks away from the other schools of health interoperability, built instead around the format of the messages exchanged.

Context

When people talk about standards for the electronic health record, the usual reference is the HL7 family: v2 messages, CDA R2 documents and, for a few years now, FHIR resources, still at Draft Standard for Trial Use stage. All of these solve a problem of exchange: how to move a clinical datum from one system to another. openEHR tackles a different problem — the native representation and persistence of clinical data over time.

The roots lie in the European projects of the 1990s: the Good European Health Record (GEHR), funded under the EU Third Framework Programme between 1992 and 1995, and the later work consolidated in the openEHR Foundation, a not-for-profit body based in the United Kingdom. The problem observed then still holds today. Medical knowledge changes constantly, whereas software systems have long and expensive release cycles. Every time a clinical protocol changes, someone has to alter schemas, queries and interfaces. Over ten or twenty years this becomes untenable.

Architecture

openEHR’s answer is two-level modelling. The lower level is the Reference Model (RM): a small family of classes with entirely generic semantics, implemented once in software and deliberately kept still. The main structural classes are COMPOSITION (the container for a clinical act, close to the idea of a document), SECTION (grouping), OBSERVATION (recordings and measurements), EVALUATION (judgements, diagnoses, state assessments), INSTRUCTION (orders and plans) and ACTION (performed actions). On top of these sits a family of data types: DV_QUANTITY, DV_CODED_TEXT, DV_TEXT, DV_DATE_TIME, DV_ORDINAL, DV_PROPORTION and others.

The upper level is that of archetypes. An archetype describes a clinical concept — blood pressure, body weight, a problem list, family history — by constraining the RM classes. The blood pressure archetype, say, declares an OBSERVATION holding two DV_QUANTITY values (systolic and diastolic, in millimetres of mercury), plus a few optional fields for patient position, measurement site and cuff size. The constraints are written out explicitly — cardinalities, ranges, permitted terminologies — and so a machine can check them.

Archetypes are written in ADL (Archetype Definition Language). The stable version is ADL 1.4, released in 2007 and revised in 2008 as part of AM Release 1.0.2; the object model that matches it is the Archetype Object Model (AOM 1.4). An ADL definition is a text file with a hierarchical structure declaring the concept, the constraints, the terminology bindings and the language translations — every archetype is multilingual from birth. An ADL 2 revision has been in progress for some time, but is not yet a standard.

Above archetypes sit templates: aggregations built for a specific use case — a triage form, a post-operative monitoring pattern — that select the archetypes relevant to that situation and narrow them further.

To query the data there is AQL (Archetype Query Language): a declarative language that writes queries along archetype paths rather than over table columns. An AQL query such as “all fasting blood glucose readings above a given threshold” is written against the clinical model, knowing nothing of the underlying physical storage schema.

The critical point

The technically decisive fact is that archetypes and templates are runtime data, not code. The software knows only the Reference Model; it loads archetypes and templates at execution time and interprets them. Adding or changing a clinical concept means publishing a new archetype or template, not recompiling the application or migrating the database schema.

This shifts the boundary of responsibility. The definition of what blood pressure clinically is becomes an artefact a clinician can read, discuss and correct without being a programmer. To keep all this governable at international scale, the openEHR Foundation maintains a public repository, the Clinical Knowledge Manager (CKM), where archetypes are proposed, reviewed by clinical panels and published through a formal lifecycle (draft, review, consensus, versioning). The CKM in its current form has been running since 2009. The underlying idea is that the Body weight archetype used in Norway, Australia or the United Kingdom be the same archetype, discussed in one place; local specialisations remain possible, but derived from the international ones.

Implications

With ISO 13606 — the standard for Electronic Health Record communication, split across five parts — there is a direct and often misread relationship. ADL 1.4 and AOM 1.4 are the basis of ISO 13606 part 2 (Archetype Interchange Specification): the ISO 13606 Reference Model is a compatible subset of the openEHR one, and the two archetype dialects line up. The scope, though, differs sharply: ISO 13606 standardises the communication of EHR between systems (export and import), whereas openEHR also covers native persistence. In practice an openEHR repository can export ISO 13606-conformant extracts at little extra cost.

Adoption, in 2015, is concentrated in a handful of countries. Slovenia runs a national platform built on openEHR technology; Norway has regional programmes; the United Kingdom, Australia and Finland have substantial projects, often built on clinical data repositories rather than on document exchange. In Italy adoption stays confined to research and the odd isolated project, while the national health record infrastructure is anchored to HL7 CDA R2; openEHR appears in technical debate as a possible clinical-modelling layer beneath the transport standards, not as their replacement.

Limits

The price of the separation is the modelling discipline it takes upstream. Producing interoperable data requires active and competent archetype governance; without it, every project redefines its own concepts and ends up with the same semantic fragmentation the model was meant to head off, only at a higher level. The implementation ecosystem, too, is narrower than HL7’s: fewer mature tools, fewer vendors. AQL, sound as it is conceptually, has uneven implementations and performance that depends heavily on how a repository materialises archetype paths. And the real gain — a system that evolves by updating an archetype rather than by running a migration — shows up over long horizons, while you pay the entry cost straight away. The return goes to those who plan for durability and accept paying up front.

https://specifications.openehr.org/releases/AM/latest/ADL1.4.html https://specifications.openehr.org/releases/AM/latest/AOM1.4.html https://specifications.openehr.org/releases/QUERY/latest/AQL.html https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html https://ckm.openehr.org/ckm/ https://www.noze.it/en/insights/openehr-clinical-archetypes/

Cover image: Diagram of the openEHR semantic framework: Reference Model, Archetypes and Templates boxes, AQL queries and Terminology feeding the… — diagram by openEHR International, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Openehr_4pillars.png