Imagine arriving at a new clinic expecting your complete medical history to appear seamlessly in their system. Instead, you receive a pile of PDFs in inconsistent formats, with missing fields and mismatched codes. That’s the real-world cost of siloed, vendor-specific EHRs. openEHR was designed to change all that. It’s not merely another standard. It’s an entire framework for how clinical data is modeled, stored, queried, and governed. Think of it as healthcare’s very own set of interoperable building blocks.

Origins & governance: Building a vendor-neutral foundation

In 2003, a coalition of European researchers and clinicians recognized that unless clinical data standards were truly open and community-driven, the same integration bridges would be rebuilt again and again. They formed the non-profit openEHR Foundation and, in 2006, published the first Reference Model and archetype server specifications.

Today, openEHR is driven by a layered, collaborative ecosystem:

• openEHR Foundation: Holds the intellectual property, maintains the legal and strategic framework, and oversees the overall management of the reference model and archetype specifications.

• Specification Governance Boards: 

  • Architecture Review Board (ARB) owns and evolves the technical Reference Model. 

  • Clinical Review Board (CRB) validates and refines the archetype and template specifications.

• Clinical Knowledge Manager (CKM) Community: An open, web-based forum where clinicians, informaticians, and domain experts propose, discuss, and approve clinical archetypes and templates in real time.

On top of these internal bodies, openEHR’s Reference Model and archetype methodology have been incorporated into ISO standards (notably ISO 13606), ensuring alignment with internationally recognized best practices. Ongoing efforts refine core specifications, expand the global archetype library, and develop open-source tooling to keep clinical data accurate, adaptable, and entirely vendor-neutral.

The big idea: Multi-level modeling

At its heart, openEHR separates how data is stored from what the data means - a principle known as multi-level modeling. This approach delivers both technical stability (core structures never change, protecting long-term investments) and clinical agility (new data requirements can be defined without database migrations or software releases). In practice, stable Reference Model components snap together with flexible clinical archetypes, just like LEGO™ bricks that can be rearranged on demand.

Under the hood: The Reference Model

With that principle in mind, here’s the technical foundation everyone shares. The Reference Model defines a consistent hierarchy for storing every piece of clinical information:

• EHR: The top-level record representing a patient’s complete file.

• Composition: A self-contained document, such as a discharge summary or lab report, complete with author, time, and context.

• Section: Human-readable groupings inside a Composition (for example, “Medications,” “Allergies,” or “Vital Signs”).

• Entry: The atomic clinical record, such as a single blood-pressure reading, a diagnosis, a medication order, or a performed intervention.

• Cluster & Value: Nested groups of related fields (clusters) and leaf values (numbers, coded text, dates) within an Entry.

Because every openEHR system uses the same Composition, Section, Entry hierarchy, locating a patient’s weight or lab result is as straightforward as navigating a familiar folder structure. No guessing which table or column was used.

Clinical modeling: Archetypes & Templates

On top of this stable foundation live clinician-driven definitions:

• Archetypes are blueprints for single clinical concepts (e.g. “Blood Pressure”), specifying exactly which fields belong together (systolic, diastolic, cuff position, timestamp) and their allowed units.

• Templates combine multiple archetypes into real-world forms (e.g. an “Annual Exam” template that includes blood pressure, heart rate, weight, and smoking status).

Because archetypes and templates live outside the core storage engine, updates and new definitions can go live immediately. No code changes, no system downtime. Clinicians get to define what matters in near real time.

Making data work: AQL & GDL

Once data is validated against archetypes and stored in standard structures, the next question becomes, “How can insights be extracted or decisions automated?” Two powerful, optional tools answer that need:

• Archetype Query Language (AQL) replaces complex navigation of nested Compositions and Entries with concise, SQL-style queries against archetypes. For example, a single AQL statement against the “Blood Pressure” archetype can fetch each patient’s latest systolic reading. In a multi-site context - say, Malmö and Uppsala hospitals both running openEHR with the same archetype - one query delivers harmonized results across locations, making cross-site reporting and research exceptionally simple.

• Guideline Definition Language (GDL) embeds clinical decision rules directly into the model. Rules like “alert if systolic blood pressure exceeds 140” can run in real time or batch, producing alerts, care-plan recommendations, or dashboard feeds; without rewriting application code.

These tools showcase how a model-driven approach can power everything from ad-hoc analytics to embedded clinical decision support.

Leyr + openEHR: Bridging today’s standards

openEHR isn’t yet as widely adopted as FHIR or HL7v2, so many health systems still use a patchwork of standards. That’s where Leyr comes in right now: providing a  unified API layer over FHIR, HL7v2, proprietary APIs and openEHR. By translating between these different formats and models, Leyr ensures that systems both using and not using openEHR can exchange data through a single interface. Your application doesn’t need customized integrations for each EHR; Leyr handles the heavy lifting.

Most health systems today operate with a complex mix of standards - FHIR, HL7v2, proprietary data models and APIs, and yes, some openEHR implementations too.

This is exactly where Leyr delivers immediate value.

Instead of building separate integrations for each standard, Leyr provides a unified API layer that seamlessly translates between all these formats. Whether your EHR uses cutting-edge openEHR archetypes or legacy HL7v2 messages, your applications connect through one consistent interface.

The bottom line: You focus on building better healthcare solutions. We handle the integration complexity.

Ready to Simplify Your Healthcare Integrations?

Stop wrestling with multiple API standards and proprietary formats. See how Leyr's unified approach can streamline your health system integrations in just 15 minutes.

Schedule a Demo →

Join leading healthcare organizations who've already simplified their data exchange with Leyr's platform.