openEHR

The Problem with Traditional EHRs

Electronic health records today are rigid. Vendor A structures blood pressure one way, Vendor B structures it differently. Want to add a new data field? That's a database change, software update, and vendor negotiation. Clinical knowledge is trapped in proprietary formats, inaccessible across systems.

Worse, when you switch vendors - and healthcare organizations do, every 7-15 years - you face data migration nightmares. Fields don't map cleanly. Historical records get distorted or simplified. Decades of clinical data risk being degraded each time you change systems.

openEHR offers a fundamentally different approach. Instead of vendors defining data structures in code, clinicians define them using standardized models called archetypes. These models are vendor-neutral, version-controlled, and reusable across any openEHR system. Clinical knowledge becomes an asset you own, not something locked in a vendor's database schema.

What is openEHR?

openEHR is both a specification and a community. The specification defines how to model clinical data using a two-level approach. The community - clinicians, informaticians, vendors, and researchers worldwide - creates and maintains shared clinical models.

The project started in the late 1990s, born from frustration with proprietary health records. Founders asked: "What if we separated clinical knowledge (what to record) from software (how to record it)?" The answer became openEHR.

The Two-Level Modeling Approach

Traditional EHRs use a single level: database tables define both the structure and meaning of data. A "blood_pressure" table has columns for systolic, diastolic, position, etc. Change the clinical requirement? Change the table structure. That requires developers, testing, and deployment - slow and expensive.

openEHR separates this into two levels:

Level 1: Reference Model (Stable Foundation)

The reference model defines generic building blocks - universal structures like:

• Composition: A clinical document (like an encounter note)
• Observation: Something observed or measured
• Action: Something done (procedure performed, medication given)
• Evaluation: Clinical assessment or diagnosis
• Instruction: Request or order

These never change. They're not specific to any clinical concept - they're abstract containers that can hold any clinical information.

Level 2: Archetypes (Clinical Knowledge)

Archetypes define specific clinical concepts using the reference model building blocks. An archetype for "blood pressure" specifies:

• It's an Observation (Level 1 type)
• It has systolic and diastolic values
• Units are mmHg
• Optional: patient position, cuff size, location
• Constraints: systolic must be numeric, 0-300 range

Archetypes are written in ADL (Archetype Definition Language), not code. Clinicians can read and modify them without programming. Change the clinical requirement? Update the archetype. No software changes needed - the EHR reads the new archetype and adapts.

Archetypes Explained

What's in an Archetype?

An archetype contains:

• Concept: What clinical thing does this represent (blood pressure, problem list, medication order)?
• Structure: What data elements are needed? How are they organized?
• Constraints: What values are valid? Which fields are mandatory?
• Terminology bindings: How do codes map to standards like SNOMED, LOINC?
• Metadata: Author, version, purpose, usage notes

Reusable and Composable

Archetypes can include other archetypes. A "medication order" archetype might include:

• A "medication" archetype (drug name, strength, form)
• A "dosage" archetype (amount, frequency, route)
• A "timing" archetype (start date, duration, specific times)

This composability means you build complex clinical documents from smaller, tested pieces. Like LEGO blocks - reusable, interchangeable, and combinable in countless ways.

The Clinical Knowledge Manager (CKM)

The openEHR foundation maintains a repository of archetypes called the Clinical Knowledge Manager. It's like GitHub for clinical models:

• Hundreds of peer-reviewed archetypes
• Version control and change history
• Review and approval processes
• Multiple languages
• Free for anyone to use

Rather than every organization modeling "blood pressure" independently, they use the CKM archetype. This creates true semantic interoperability - everyone means the same thing when they say "systolic blood pressure."

Templates: Archetypes in Context

Archetypes define what can be recorded. Templates define what will be recorded in a specific situation. They constrain archetypes further for local use.

Templates drive the user interface. An EHR generates forms from templates - which fields to display, in what order, with what labels. Change the template, the form updates automatically.

Queries and Analytics

Because data is stored according to archetypes, querying becomes standardized. openEHR uses AQL (Archetype Query Language), a SQL-like language that references archetypes directly.

Want all patients with systolic blood pressure above 140? Write a query referencing the blood pressure archetype. That query works on any openEHR system, regardless of vendor, because they all use the same archetype.

This is transformative for research and analytics. Queries written once run across institutions. Multi-site studies don't need to harmonize data formats - they're already harmonized by shared archetypes.

Benefits of openEHR

1. Future-Proof Data

Clinical data is stored in a vendor-neutral format based on archetypes. Switch vendors? Your archetypes come with you. The new system reads the same archetypes and presents data correctly. No lossy migrations.

2. Clinical Governance

Clinicians control data models, not IT departments or vendors. Want to add a new assessment tool? Model it as an archetype. No waiting for vendor releases or expensive customizations.

3. True Semantic Interoperability

Systems sharing archetypes understand each other precisely. Not just "this field is called blood_pressure" but "this is systolic blood pressure, measured in mmHg, with the patient sitting, at a specific time."

4. Efficient Development

Software developers build generic tools that work with any archetype. They don't write code for each clinical concept. This means:

• Faster development - build once, apply to all archetypes
• Fewer bugs - generic code is tested more thoroughly
• Easy customization - clinical teams modify archetypes, not code

5. Support for Research and Quality Improvement

Standardized data models enable:

• Cross-institutional studies with minimal data harmonization
• Quality metrics based on precise definitions
• Clinical decision support that works across systems
• Population health analysis with consistent data

Real-World Implementations

National Health Systems

Several countries have adopted openEHR nationally:

• Norway: National medication record system
• Slovenia: National EHR infrastructure
• Russia: National health platform (Moscow first)
• Brazil: Public health system deployments

These national implementations demonstrate openEHR can scale to millions of patients while maintaining data quality and interoperability.

Hospital and Regional Systems

• UK hospitals using openEHR for specific departments (emergency, intensive care)
• Australian health networks for chronic disease management
• Asian hospitals for cancer registries and specialty care

Research and Clinical Trials

Research institutions use openEHR for:

• Clinical trial data capture - archetypes ensure consistent data across sites
• Registries - disease-specific databases with standardized models
• Cohort studies - leveraging EHR data with guaranteed structure

Challenges and Considerations

Learning Curve

openEHR is conceptually different. Teams used to traditional databases must learn new concepts: archetypes, templates, two-level modeling. This takes time and training.

Limited Vendor Support

Major EHR vendors (Epic, Cerner) don't use openEHR. They have proprietary data models. This means:

• Organizations must choose openEHR-native systems or
• Build bridges/facades between traditional EHRs and openEHR

Several vendors specialize in openEHR (Marand, Code24, Better, Ocean Informatics). But they're smaller than the giants, which can concern procurement departments.

Archetype Governance

Freedom to create archetypes is powerful but requires governance. Who approves new archetypes? How do you prevent duplicates? How do you ensure quality? Organizations need processes and roles (clinical modelers, archetype reviewers).

Performance Considerations

Flexible data models can have performance trade-offs. Querying archetype-based data is sometimes slower than querying fixed tables. Modern openEHR platforms mitigate this with indexing and caching, but it's a consideration for very high-transaction environments.

openEHR vs FHIR

People often compare openEHR and FHIR. They're complementary, not competing:

• openEHR: Focused on persistent storage, clinical detail, long-term data integrity within systems
• FHIR: Focused on exchange, interoperability, accessing data across systems

Many openEHR implementations export data via FHIR APIs. openEHR stores the data with full fidelity, FHIR provides a standard interface for external access. They work well together.

Getting Started with openEHR

For Healthcare Organizations

1. Learn: Explore openehr.org, read case studies, attend webinars
2. Assess fit: Is your organization ready for clinical modeling? Do you have governance capacity?
3. Pilot: Start small - one department or use case
4. Engage vendors: Evaluate openEHR-native EHR vendors
5. Build skills: Train clinical modelers, informaticians in archetype development

For Developers

1. Study specifications: openEHR.org has detailed specs for reference model, archetypes, AQL
2. Try open-source servers: EHRbase, Atomik - full openEHR implementations you can install locally
3. Use SDKs: Libraries exist for Java, .NET, Python to work with openEHR data
4. Explore CKM: Browse archetypes to understand how clinical concepts are modeled

For Clinical Modelers

1. Take courses: openEHR foundation and universities offer modeling training
2. Use archetype designers: Tools like Archetype Designer provide GUIs for creating archetypes
3. Join community: Engage in CKM reviews, mailing lists, working groups
4. Start simple: Model familiar concepts (vitals, allergies) before complex ones

The Vision: Computable Health Knowledge

openEHR's ultimate goal is to make clinical knowledge computable. Not just data interoperability, but knowledge interoperability. Clinical models, decision rules, care pathways - all shareable, reusable, and executable across systems.

Imagine:

• A new guideline published as executable archetypes and rules, implementable instantly across systems
• Research findings encoded as computable models, immediately usable for CDS
• Best practices captured once, deployed everywhere
• Data that remains usable for decades, regardless of software changes

This vision requires cultural change - thinking of clinical knowledge as an asset to be explicitly modeled and shared. But the technical foundation exists in openEHR's specifications and growing adoption.