The openEHR Health Computing Platform
Introduction
The architecture of openEHR is a response largely to the requirement for semantic interoperability. Semantic interoperability is the ability of computers and software to mutually understand the meaning of information. It requires information to be computable, not just shareable, and is required in the following places.
-
in the 'application stack': i.e. from the GUI down to the
database (regardless of the actual method of deployment of these things). It is
essential that what is presented at the GUI is understood the same way by the
software as it is by the human user. The meaning of information must be
preserved from this point down through layers of business logic to its
representation in the persistence (data storage) layer. If this is not the case,
information entered by a user will not safely reach the part of the system which
allows it to be shared with other users or other systems, or even the same user
at a later time.
Achieving semantic coherence in the application stack is not always as simple as it seems given that more than one vendor may be responsible for various parts of the software. - between systems: the meaning of the information captured in any particular application or system needs to be preserved when it is transmitted to another system. This applies to systems within the same provider enterprise and across enterprises.
Addressing this need in a sustainable way has not proven easy. One of the biggest challenges has been how to deal with context- and site-dependent capture and use of data, while standardising its meaning in a context-independent way (a 'blood pressure measurement' doesn't change its meaning after all) and yet avoid the trap of hard-modelling things in software, creating an unmaintainable solution.
Some theorists in the field have thought that terminology was the sole answer to semantic interoperability, but this has turned out to be incorrect for a number of reasons, the main one being that terminology does not provide an appropriate place for modelling the compositional structures or semantics of structured information. Terminologies also do not represent constraints well, nor data types other than the textual. Terminology therefore has an important place in the infrastructure, but is not the totality of it.
Others claim that defining messages is sufficient to enable semantic interoperability. However, while messages of some form or other are literally needed between systems, using messages as the design basis for a semantically interoperable infrastructure does not work very well. Firstly, because they do not take account of the application stack - they treat applications as black boxes. Secondly, the basic notion of a message is a carrier of a change of state or an event, rather than (necessarily) a coherent model of structured information. Thirdly, message models usually contain a lot of details to do with the messaging activity, i.e. sending, receiving, acknowledgements, and so on. A proper solution to the problem of semantically interoperable content cannot avoid accounting for what happens inside systems as well as what happens between them. A more appropriate way to model messages is as conversations between web-services, where the message schemas are machine-generated from other more reusable models of information.
Service Architecture
|
An engineering view of the architectural framework of openEHR is that of a service-oriented system of systems, with distinct services for EHR, demographics, workflow, adminstration, knowledge artefacts (including terminology), identification, security, orchestration and discovery. One of the major features of openEHR is the a semantic architecture for the information-rich services, e.g. EHR, demographics and administration, and their corresponding user applications (e.g. doctors desktop, nurse systems). |
|
Semantic Architecture
|
The openEHR information architecture takes the following form:
The openEHR semantic architecture is visualised on the right. The part shown in cyan is defined by openEHR specifications. A key feature of this architecture is the two middle model layers, i.e. archetypes and templates. Archetypes are models of clinical content, defined on the basis of topic, such as 'blood pressure measurement', 'physical examination' and 'diagnosis'. Templates are artefacts that reuse data points defined within archetypes to create refined data sets particular to use context, which almost always means that they correspond to a particular kind of business event (health service event) - e.g. a certain kind of patient visit. Templates are then the basis for creating screen forms, message schemas and other derived artefacts for information use. |
|
||
|
The relationships and dependency between different kinds of artefacts in this architecture are visualised on the right. Within the artefact ecosystem, archetypes are of key importance, since they constitute the basis for building templates, building queries and defining mappings to terminology. It is therefore important that they are as far as possible independent of particular concrete expressions or uses, such as GUI forms, messages, and executable code. These latter artefacts should all be machine generated from more abstract artefacts such as archetypes and templates. |
|
The openEHR Reference Model (RM)
The openEHR RM formalises the Electronic Health Record as follows:
|
|
Advantages of the openEHR architecture
The advantages of the architecture include the following:
- Semantic coherence in the application stack (all layers of software know what the data mean)
- A high level of re-use of artefacts – define once, reuse many times
- A single, stable reference model for sharing clinical and related information
- A standardised query language for writing portable queries
- A standardised, re-usable way of connecting to terminology
The Architectural Overview (PDF, HTML) provides a good summary of the technical details of openEHR.
There are no comments.