The openEHR Foundation has published a set of specifications defining a health information reference model, a language for building 'clinical models', or archetypes, which are separate from the software, and a query language. The architecture is designed to make use of external health terminologies, such as SNOMED CT, LOINC and ICDx. Components and systems conforming to openEHR are 'open' in terms of data (they obey the published openEHR XML Schemas), models (they are driven by archetypes, written in the published ADL formalism) and APIs. They share the key openEHR innovation of adaptability, due to the archetypes being external to the software, and significant parts of the software being machine-derived from the archetypes.
The essential outcome is systems and tools for computing with health information at a semantic level, thus enabling true analytic functions like decision support, and research querying.
This allows domain experts - clinicians, allied health workers, and other experts - to be directly involved in defining the semantics of clinical information systems, and it also makes using terminology much easier. You can see a whole repository of these models, known as 'archetypes' here, and the archetype specification is now an ISO standard (ISO 13606-2). These are now being used by several national governments to specify national e-health information standards.
openEHR has also defined specifications for clinical information models, EHR Extracts, demographics, data types and various kinds of service interfaces. These have been used in hospitals and summary EHR systems in various countries.
A second dimension via which the openEHR modelling approach can be viewed is single-source modelling. Within this approach, archetypes and templates are definitive models of semantics, without commitment to specific messaging or document standards, or other technologies. Instead, concrete expressions are now generated artefacts. Practically, this means that data schemas such as HL7 CDA, ASTM CCR and HL7 and other message formats are now generated rather than manually modelled. Once single-source modelling is established, other outputs including UI forms and software source code. This means that a model for 'microbiology result' only needs to be done once to enable reports, UI forms, CDAs and other message formats to be generated.
Above the data level, clinical process must be supported. openEHR does this in various ways. Central to its EHR information model is the concept of the 'Instruction' and 'Action', which represent orders and actions. The Instruction State Machine provides a standard model of process, and is used to map steps from specific intervention workflows like vaccination, medication prescription, radiology and surgery. Actions (e.g. drug administrations) can be tracked with respect to their original order, and this provides the basis for modelling higher-level concepts such as active Care Plans. Rule engines are used to detect relevant actions and update current statuses of patient intervention workflows.
The second aspect of process support is the ability to detect trigger events (e.g. a specific kind of test result, out of range vital sign etc) and generate notifications to care team members and other actors. This is typically implemented with rules based on archetype queries, and integration engine notification management.
There are some key benefits to openEHR's approach. Firstly, it is now possible to build an EHR repository independently of content specifications. In other words, your EHR system doesn't need to know a priori about any of the clinical data it will process, such as vital signs, diagnoses or orders. Models for those things are developed separately. Models for data sets and forms are also developed separately, and UI form components are now generatable from these definitions. This enables a new generation of EHR systems that routinely adapts to new requirements - because that's how the architecture is designed in the first place.
Secondly, building software is now very different. Significant parts of the software are now generated by tools from the templates, reducing the amount of work to do, and greatly improving semantic traceability. Model-generated code and UI (user interface) is an area of continual innovation in openEHR, and promises to revolutionise health computing.
Another benefit is portable queries - queries based on content models, not phsyical database schemas. Coupled with EHR and vEHR service interface APIs, these are enabling a new class of decision support tools.
In clinical terms, health professionals are now for the first time experiencing direct involvement in the construction and ongoing development of EHR systems. This means that the quality of the data is better - they designed it, and it also enables applications that work for them to be built.
Strategically, the openEHR approach enables a platform-based e-health software market, in which vendors and developers of back-end and front-end solutions interface via standardised information, standardised content models and terminology, and standardised service interfaces. This gives procurement stakeholders new choices. It also allows app developers to concentrate on their apps, and simply plug in to a reliable back-end.
This website will give you information on how it all works, and how to become a member of openEHR. Are you a clinical professional? You can help creating and reviewing the archetypes. Are you a message designer? You may want to get involved in building template-based message specifications, based on the archetypes. Are you a software developer? You can help build the new generation of EHR tools. If you are a researcher, you can get involved in specifying how openEHR querying, published terminologies and standards like CDISC can be used to improve how longitudinal data-based studies are done. Maybe you want to obtain tools and solutions? You will find vendor solutions, as well as open source components.
Specifications Quick Links
Clinical Models Quick Links
Copyright © 2015 openEHR Foundation. All rights reserved | Webmaster