openEHR basics

Understanding openEHR isn't an academic exercise — it's what makes the difference between a data model that survives your first production change and one that requires a dev sprint every time a field is added.

Atomik is built on openEHR. The more you understand the standard, the more you'll get out of the platform. This guide covers the concepts you'll encounter daily: the information models, the separation of data from application code, and the archetype/template system that makes schema-free clinical storage possible.

openEHR is an open standard with 20+ years of specifications, a global community, and growing adoption — particularly in national health systems across Europe, Australia, and Latin America. It captures requirements, patterns, and best practices for Health Information Systems that most custom implementations discover the hard way after years in production.

openEHR draws a clear distinction between EHR-related information and demographic information, and provides specifications for both. The EHR Information Model covers these entities:

• EHR represents the complete and unique health record of a patient
• CONTRIBUTION represents a change set for an EHR
• COMPOSITION represents a record or document that belongs to an EHR, COMPOSITIONs are added to an EHR contained in a CONTRIBUTION
• FOLDER represents and organizational structure that can hold documents and other folders
• VERSION represents one version of a record of document, in general it's a version of a COMPOSITION or FOLDER
• ENTRY represents an individual clinical statement, and includes data structures and data fields
• DATA VALUE represents the type for a specific field or data point (text, code, date, boolean, multimedia, etc.)

The openEHR Demographic Model does the same with these entities:

• PERSON represents a person party
• ORGANIZATION represents an organization party, like a hospital
• GROUP represents a group of parties, for instance a surgery team
• ROLE represents a role that could be played by a party, for instance a person could be a physician or could be a patient, two different roles
• PARTY RELATIONSHIP represent any kind of relationship between two parties, for instance a family relationship between two persons
• PARTY IDENTITY represents identity information for a party
• CONTACT represents contact information for a party, including address

openEHR recommends separate repositories for EHR and demographic data. Atomik supports both patterns: run them together in one instance (simpler setup, shared maintenance, faster prototyping) or split them across separate instances to match the strict openEHR architecture. Either way, both use the same codebase.

Separation of data from application

This is the most important concept in openEHR — and the one with the biggest impact on your delivery speed.

This is possible because of openEHR's dual-modeling approach: a stable Reference Information Model that generic software can implement once, and a separate layer of Archetypes and Templates that domain experts manage without touching the software. The standardized modeling process also means information definitions are formally governed over the long term — no silent inconsistencies accumulating over years.

The openEHR Archetype Model describes the artifacts used to define, manage and share definitions of health information. These definitions include: structure, constraints and terminology. These definitions allow you to express any kind of information you want to store and manage in a health information system, and all definitions use the same standardized elements (Archetypes and Templates) to create complex data structures. This flexibility comes from the underlying Reference Information Model, because all the elements used in these definitions come from it.

The Reference Information Model is mainly composed by the specifications mentioned above (EHR and Demographic), and defines generic data structures that can be configured in different ways to express any kind of data structure. That "configuration" of the Information Model is done by Archetypes and Templates.

Archetypes and Templates

These are openEHR models used to describe information structures. The openEHR recommendation is for these models to be created by Domain Experts, yes these are clinicians not IT people. There are some positive consequences of this recommendation. First, clinical information is defined and managed by professionals that actually know what they are talking about. Second, we, IT people, can rely on these Domain Experts for the information definitions, while we focus on solving pure engineering problems (dealing with clinical knowledge is not one of them).

Domain Experts will use modeling tools to create, manage and share Archetypes and Templates. There are plenty of modeling tools available and the learning curve is not so steep. We offer a training course specifically to learn about Clinical Information Modeling with openEHR, that includes the methodology and tools needed to create your own models.

When Domain Experts create these information models, they first start creating all required Archetypes which define the basic structures that will be reusable parts in different documents, like Blood Pressure, Pulse, Body Temperature, Medication Order, Procedure, etc. Each of those concepts will have their associated data structures in one Archetype each.

Another option, instead of creating all Archetypes from scratch is to grab the ones that are available in the international Clinical Knowledge Manager (CKM). An interesting characteristic of Archetypes is that, since they include terminology about the concept that Archetype represents, you can translate an Archetype to different languages, so your document definitions can be in several languages. Many Archetypes in the CKM are already translated, and if you need to use an Archetype form there that is not translated to a specific languages, you can contribute with the translation. This is how the Clinical Modeling Community works: by contributions.

Finally when you have all the Archetypes needed by certain document, those Archetypes are combined in a Template. An openEHR Template is basically a huge Archetype that represents a clinical document. Note we use the term "clinical" in a very loose way here, since in an openEHR Template you can represent records that contain many concepts (Archetypes) but might not be for a strictly "clinical" context, for instance, a Template could define the data structures needed to record Exercise Tracking, Procedure Consents, basic Administrative data, etc.

So the output of the Clinical Modeling process executed by Domain Experts is a Template in a form that can be consumed by software systems. That final form is called Operational Template (OPT). The OPT is just an XML file that contains all the structure definitions, data constraints and terminology from all the Archetypes referenced by the Template. OPTs are actually what the Clinical Modelers will handle the IT team to implement the corresponding user interface, application logic and persistence that will allow a software system to store and retrieve data defined by the OPT.

Since Atomik is an openEHR-based system, it follows that process: you need to upload the OPTs used by your applications so it knows how the data will look like, then Atomik will know how to process and store it when your application commits data to Atomik.

Future proof models

One final thing to know about openEHR is that knowledge models (Archetypes and Templates) and data stored based on those models, are all versionable. Let's say you have an Archetype, for instance Blood Pressure, that will be the first version of the Archetype. Then in the future some extra requirement about Blood Pressure is needed, then you modify the Archetype and release the second version of the Archetype. From now on, all Blood Pressure data will follow the v2 Archetype, while current data follows v1. That is normal in healthcare systems, but most systems don't have this requirement formally defined. Then when data about Blood Pressure is queried and retrieved, data recorded for v1 and v2 of the Archetype will be returned.

Then data itself is versionable. That means, when a modification, amendment or even deleting existing data is needed, in openEHR the current data won't be modified, but a new version of the data will be created and linked with the previous version. This maintains a cohered audit log of all the changes done to the data, creating a history that can be navigated, and each item in the data history has an audit log including the type of change, timing, reason and the responsible for the change, answering all the basic questions for an audit log system.

openEHR training

At CaboLabs we provide formal training on different aspects of openEHR, from understanding the specifications, to implementation, including clinical modeling for domain experts. You can find more at our education website.