openEHR is a set of specifications for the core components of a health information platform, which has many desired characteristics included by design:
- Vendor Neutral
- Technology Agnostic
- Maintainable
- Interoperable
- Standardized Data
- Computable Data Specifications
- Versionable Data
- Driven by Domain Experts (Clinicians)
- Supports any Terminology/Thesaurus/Coding System
- Semantically Coherent
The maintenance of the openEHR specifications is done by the Standard Editorial Committee (SEC), using a governance process similar to an open source project. The openEHR specifications are openly and freely available to anyone wanting to implement them. That is why we say that openEHR is an "open source specification", but this shouldn't be confused with "open source software": openEHR is not a software system, is a set of blueprints for a health information platform.
The intellectual property of the the openEHR standard is managed by the openEHR Foundation, a non-for-profit organization based in the UK.
The openEHR Methodology
The for a successful implementation of the openEHR specifications, we recommend to focus on three processes:
- Governance
- Clinical Modeling
- Engineering
openEHR Governance
Any openEHR project should have a governance process defined, which includes how to manage different professionals, processes, assets and technologies involved in the implementation of the specifications.
Planning and managing each aspect of the implementation and defining openEHR adoption strategies should also be part of the governance process. To define and execute this process successfully, it is key to get advice to knowledgeable professionals in the openEHR community.
openEHR Clinical Modeling
openEHR defines the 'dual model' approach to separate knowledge artifacts and health data from the management of the implementation technologies. This is a key aspect of the openEHR software development paradigm, which is the main reason why openEHR systems are highly modifiable: changes in clinical content don't affect the technology, and changes in the technology don't affect clinical content and data. This is one of the main differentiators of openEHR systems from the traditional monolithic EHR architectures.
The dual model involves the creation and maintenance of definitions of health information data sets, outside the technical implementation of the EHR platform. This contributes to the separation of the technical engineering processes from the clinical information management, allowing IT professionals and clinical domain experts to manage each area independently and more efficiently.
openEHR Engineering
This process includes the technical implementation of the openEHR specifications on a concrete technology stack, the management of modifications and fixes, integration with different communication protocols, messaging formats and data exchange standards, management of openEHR tooling and systems that allow to manage knowledge assets in an efficient way.
The openEHR Architecture
Another aspect of the openEHR specifications is the architecture proposed. The core components include a clinical data repository and a demographic data repository. That is why in openEHR the clinical data resides in a different repository than the patient and clinician identification and location data.
This aspect applies security measures by design, including the possibility of using the clinical information for secondary uses (non-clinical uses), without the need of adding more security measures to the clinical data repository. This is compatible with the HIPAA requirements in the US.
This implies that an openEHR clinical data repository can be used outside the strictly clinical context, and be used for public healthcare and research, among other non-clinical, purposes. As you can see openEHR goes beyond the strictly EHR use, and could be used in single organization, federated, regional, national and international contexts.
The openEHR Layered Architecture
The openEHR specifications have an inherent layered design, a pattern that allows adding different levels of semantics to data structures, which simplifies the standardized implementation of the basic functionalities for the EHR platform: store and query, data exchange, analytics, data validation, GUI generation, etc.
The core of the openEHR specifications is the openEHR Reference Model (RM), which is the lower layer in the openEHR layered architecture. The RM is a generic data model for clinical, demographic, versioning and audit data. The RM doesn't include any domain specific knowledge, so it defines the most abstract level of information.
The second layer is defined by the Archetype Model, which allows to define constraints over the RM to specify atomic domain concepts. For instance, an archetype can be used to define the concepts of Blood Pressure, Heart Rate, Laboratory Study Request, Diagnosis, Medication Prescription, Procedure Execution, Obstetric Summary, Care Plan, Apgar Score, etc. An archetype includes the definition of: 1. a data structure, 2. data validation constraints, 3. terminology, 4. management metadata.
The third layer is the Template Model, which allows to join different archetypes together for a specific use or context. For instance, a template can be used to define a clinical document for cardiology visits. A template could contain references to many archetypes, define which parts of those archetypes to use or not use, and even define more constraints over the constraints already defined in archetypes, but those extra constraints can't contradict the archetype constraints.
On top of templates we have many other layers, including:
- Clinical Decision Support
- GUI Specification
- Data Query
- Data Mappings
- Workflows
All the aforementioned openEHR elements have a formal and computable representation, which enables software to consume those elements as metadata that defines how the system behaves. This implies a change of paradigm in current EHR design and development methodologies: openEHR software is generic, adaptable and maintainable by design. So the same software components could be used to create different types of systems just by changing the openEHR elements.
Future proof & Cost effective
In the EHR world, most implementation projects require 2-5 years for implementation of systems that will be maintained for the next 15-20 years until a reengineering process is needed to keep up to new requirements and current technologies. Most people focus on the implementation costs, while the maintenance costs are far higher.
Current monolithic EHR architectures are not designed to be easily or cost-effectively modifiable, and each new functional requirement implies changes on many components of the software, from the database to the presentation layer. The openEHR specifications, proposed architecture, methodologies, processes and related tools are defined so any openEHR implementation is easily modifiable by design. The dual model approach is the key here: most new requirements for the EHR are implemented as modifications on clinical models, not on software components. So openEHR software could accept changes for clinical records, without touching one single line of code, or even modifying the database structure: yes, new data can be recorded and queried in the software, without modifying it.
This level of modifiability of openEHR systems allow to cut the maintenance costs to the minimum, and also can reduce the costs of reengineering, technology migration and data migration, since what's important in an openEHR environment is the data, not the implementation technology.