Reusing Archetypes and Introducing the Reference Model

When working with openEHR, there’s one golden rule: don’t reinvent the wheel.

The openEHR Clinical Knowledge Manager (CKM) already contains thousands of archetypes built by clinicians, informaticians, and developers from around the world. These archetypes represent common healthcare concepts like blood pressure, lab tests, allergies, and diagnoses.

By reusing existing archetypes, we:

• save time,
• reduce errors, and
• ensure different systems can understand and exchange data with each other.

Before creating anything new, always check the CKM first.

The usual guideline is to first pick archetypes from the international CKM, then national, and lastly regional or project specific archetypes. The concept you need has likely already been modelled and reviewed by the community. If you don’t find anything that fits, you can go ahead and create an archetype.

How does reuse enable interoperability?

The reuse of archetypes allows interoperability because they’re all built on the same foundation: the openEHR Reference Model, or RM. The RM defines the rules and structure that make archetypes interoperable.

Think of the health ecosystem as having three layers:

• At the bottom is the database, where data is stored.
• In the middle is the data platform, defined by the openEHR Reference Model.
• At the top are applications, such as EHRs and analytics dashboards.

The RM defines that middle layer, the data platform, and acts as a blueprint that keeps data consistent between databases and applications.

What does the Reference Model contain?

The RM defines how data is structured and represented

It has two key parts:

• Structural classes, which define how information is organised.
• Data types, which define the kinds of data that can be recorded.

Structural Classes

Structural classes are the backbone of openEHR, they define how data is organised and linked together. These follow from the programming concept of classes where a class is a template or a blueprint, that is used to create specific instances called objects.

For example, a Ford car and a Toyota car both fall under the category of Cars.

In this case, Car is the class, serving as a template to create objects, Ford and Toyota. The class Car could have characteristics like, “brand”, “color”, etc, and the individual objects can specify the brand as Ford or Toyota.

openEHR’s Structural classes (e.g. COMPOSITION, SECTION) work in the same way. Each time information is recorded, instances are created of these classes. Archetypes and Templates decide what additional information is captured within these instances based on clinical requirements.

The main structural classes defined in the RM are:

• COMPOSITION: A container for one clinical encounter or document.
• SECTION: Used for human-readable grouping (like “History” or “Lab results”).
• CLUSTER: A reusable building block used inside ENTRYs to represent smaller details (for example, lab analytes, body site, or measurement method).
• ENTRY: An abstract class that represents the main units of clinical content. ENTRY has five subtypes:
  • OBSERVATION: Measured or observed data (e.g., vital signs, history).
  • EVALUATION: Clinical judgements (e.g., diagnoses, assessments).
  • INSTRUCTION: What should be done (e.g., medication orders, care plans).
  • ACTION: What was actually done (e.g., procedures, administered medication).
  • ADMIN_ENTRY: Administrative information (e.g., referrals, appointments).

Templates and slot rules decide how these classes are combined and how often they appear.

Slots

Slots are central to how openEHR archetypes enable reuse. Each archetype we use is a component that can be fit together in order to create a comprehensive clinical data model. When building a template, we add archetypes to ‘slots’ in other archetypes.

There are rules that govern which archetypes can go into which:

• COMPOSITION and SECTION can contain only SECTION and ENTRY archetypes
• ENTRY and CLUSTER can contain only CLUSTER archetypes

The Archetype Designer only shows relevant archetypes that can be added in a particular part of a template according to the above slot rules. E.g. an ENTRY cannot be added into another ENTRY or a CLUSTER.

Data Types

All openEHR data values are defined by DV_* classes. These ensure that different systems interpret the same kind of data the same way.

Data Type	Description	Example
DV_TEXT	Human-readable text	“Fever”
DV_CODED_TEXT	Coded value linked to a terminology	38341003 - Hypertensive Disorder
DV_QUANTITY	Numerical value + unit	120 mmHg
DV_BOOLEAN	True or False	“Yes” / “No”
DV_DATE_TIME	Combined date and time	2025-10-15T10:30Z
DV_MULTIMEDIA	Image, audio, or binary content	X-ray image or ECG trace

These data types make sure that different types of information, such as a blood pressure measurement, a diagnosis label, and a clinical note are all recorded in consistent and machine-readable ways.

How do archetypes map to the Reference Model?

Every archetype in openEHR is built on top of the Reference Model. When you create or reuse an archetype, you’re really filling in the details of an RM class.

Here are a few examples:

• Blood pressure: based on OBSERVATION, because it’s measured data.
• Diagnosis: based on EVALUATION, because it’s a clinical judgement.
• Medication order: based on INSTRUCTION, because it’s an order to act.
• Medication given: based on ACTION, because it records what actually happened.

Each archetype not only maps to a structural RM class but also uses RM-defined data types inside it.

Specialisation

Sometimes, an existing archetype needs to be tailored for a specific context. In openEHR, this is done through specialisation.

For example, a general Weight archetype can be specialised into Birth Weight.

The specialised archetype inherits everything from its parent but can add or narrow details as needed. When you query for all weights, data from Birth Weight will also appear — making reuse even more powerful.

Recap

The Reference Model is the foundation of openEHR. It defines the structure and data types that archetypes reuse to represent clinical meaning. Templates then bring archetypes together into real-world forms that clinicians use.

In short:

• Reuse archetypes, don’t reinvent them.
• Follow the RM as it keeps everything consistent.
• Build templates to bring it all together.

By following these principles, openEHR systems stay interoperable by design, structured, reusable, and ready for the future of health data.