AIHealth
On-premise clinical platform with local LLMs, RAG on FHIR/DICOM data, diagnostic support, remote follow-up. Architecture designed for the MDR pathway.
Discover AIHealth →
Digital Health
Medical software development compliant with CE and MDR regulatory standards. Clinical decision support systems, AI integration in clinical workflows.
Discover →An alternative approach
Alongside the HL7 family — v2, CDA R2 and the new FHIR — there is a school of healthcare interoperability with different origins and philosophy: openEHR. Born out of the academic work and European projects of the 1990s (GEHR, SynEx, Good European Health Record) and consolidated in the openEHR Foundation — a UK-based non-profit — openEHR proposes a sharp separation between two levels: a stable, generic reference information model, and a clinical level governed by clinicians themselves through constructs called archetypes.
The underlying idea is that clinical data models evolve with medicine and must be specified by the domain professionals, not by developers. If the technical information model can be kept small and stable, the clinical level is free to evolve without breaking applications.
Two levels: Reference Model and archetypes
The openEHR Reference Model (RM) is a small family of classes with general semantics: COMPOSITION (the container of a clinical event, the conceptual equivalent of a document), SECTION (logical grouping), OBSERVATION (measurements, findings), EVALUATION (clinical judgements, diagnoses, status assessments), INSTRUCTION (orders, plans), ACTION (actions performed). The data type model includes DV_QUANTITY, DV_CODED_TEXT, DV_DATE_TIME, DV_TEXT, DV_ORDINAL, DV_PROPORTION and others.
On top of the RM sit archetypes: specifications in ADL (Archetype Definition Language) describing a clinical concept — blood pressure, heart rate, blood glucose, a migraine episode, the list of active problems, family history — by constraining the use of RM classes. A Blood pressure archetype declares that it is an OBSERVATION with two DV_QUANTITY systolic and diastolic in millimetres of mercury, a patient position field, a cuff size field and so on. Constraints are formally described and verifiable.
Templates aggregate multiple archetypes into a form oriented to a specific use case — for example a triage form or a post-operative monitoring pattern.
ADL and AQL
ADL is the formal language archetypes are written in. The current stable version is ADL 1.4; an ADL 2 revision is in the works but not yet standard. An ADL definition is a text file with a hierarchical structure declaring the concept, cardinality constraints, usable terminologies and linguistic bindings (every archetype is multilingual by design).
AQL — Archetype Query Language — is the query language equivalent to SQL, but based on archetype paths rather than the column names of a table. An AQL query on an openEHR record fetches, for example, all fasting glucose measurements above a threshold, regardless of the underlying physical database.
Clinical governance: Clinical Knowledge Manager
One of the most characteristic aspects of openEHR is the clinical governance of archetypes. The openEHR Foundation maintains a public repository — Clinical Knowledge Manager (CKM) — where archetypes and templates are discussed, reviewed, approved and versioned by international clinical committees. The principle is that a Body weight or Pain intensity archetype used in Norway, Australia or the United Kingdom should be the same archetype, discussed and governed in one place.
In practice each country or project can still specialise or produce local archetypes, but the design criterion is the adoption of international ones when available.
The relationship with ISO 13606
The parallel between openEHR and ISO 13606 — Electronic health record communication — is tight and often a source of confusion. ISO 13606 is the ISO/CEN standard for EHR communication, split into several parts (Part 1 Reference Model, Part 2 Archetype Interchange Specification, Part 3 Reference Archetypes and Term Lists, Part 4 Security, Part 5 Interface Specification). The ISO 13606 Reference Model is a subset compatible with openEHR’s, and ISO 13606 archetypes use an ADL dialect consistent with openEHR’s.
Differences concern scope: ISO 13606 focuses on EHR communication between systems (export/import), whereas openEHR also covers native data persistence; governance: formal ISO with committee SC251 vs. the openEHR Foundation non-profit community; and speed of evolution.
In many cases an openEHR system can export ISO 13606-conformant records without extra effort.
Adoption
Adoption of openEHR as of 2015 is concentrated in a few specific geographies. The UK NHS has used it in local shared care record projects. Norway has regional programmes on openEHR. Slovenia has a national platform based on Marand’s Think!EHR. Finland and Australia have significant projects. Germany has start-ups and academic hospitals experimenting with openEHR-based Clinical Data Repositories.
In Italy, adoption is limited for now to research and individual projects, with the FSE infrastructure firmly anchored to HL7 CDA R2. openEHR is nevertheless a recurring reference in the technical debate about the second generation of FSE systems, as a possible clinical modelling layer underneath transport standards.
Implementations
The openEHR implementation ecosystem includes:
- Think!EHR Platform by Marand (Slovenia), used in production in several geographies
- Ocean Health Systems (Australia), with archetype authoring tools and a CDR
- Code24 EHRServer and other smaller open source projects
- Ethercis — Apache-licensed open source CDR, in early stage of development
- openEHR Java Libraries official from the Foundation
- Archetype Designer and Template Designer — editors for clinical authoring
Implementations are fewer than in the HL7 ecosystem, but oriented to Clinical Data Repository rather than messaging/document exchange.
The distinctive trait
The distinctive trait of openEHR is moving clinical decisions towards those who make them: a clinician can read, discuss and modify an archetype without being a programmer; an information system can adapt to a new clinical model by updating an archetype and a template, without changing databases, applications or interfaces. It is a model that requires an initial investment in modelling discipline but, in theory, makes the evolution of the system sustainable over the long horizons on which medicine actually evolves.
References: openEHR Foundation — Architecture Overview, Reference Model, Archetype Definition Language (ADL). ISO 13606 parts 1–5. Clinical Knowledge Manager (CKM). Marand Think!EHR, Ocean Health Systems, Ethercis.