TOC PREV NEXT INDEX

openEHR logo


3 Aims of the openEHR Architecture

3.1 Overview

This section provides a brief overview of the requirements underpinning the openEHR architecture. The openEHR architecture embodies 15 years of research from numerous projects and standards from around the world. It has been designed based on requirements captured over many years.

Because the architecture is highly generic, and particularly due to being archetype-driven, it satisfies many requirements outside the original concept of the "clinical EHR". For example, the same reference architecture can be used for veterinary health or even "care" of public infrastructure or listed buildings. This is due to the fact that the reference model embodies only concepts relating to "service and administrative events relating to a subject of care"; it is in archetypes and templates that specifics of the kinds of care events and subjects of care are defined. In another dimension, although one of the requirements for the openEHR EHR was a "patient-centric, longitudinal, shared care EHR", it is not limited to this, and can be used in purely episodic, specialist situations, e.g. as a radiology department record system. Requirements for various flavours of "health care record" can be categorised according to the two dimensions, scope, and kind of subject, as shown in FIGURE 2.

In this figure, each bubble represents a set of requirements, being a superset of all requirements of bubbles contained within it. Requirements for a generic record of care for any kind of subject in a local deployment are represented by the top left bubble. The subsequent addition of requirements corresponding to living subjects and then human subjects is represented by the bubbles down the left side of the diagram. The requirements represented by the largest bubble on the left hand side correspond to "local health records for human care", such as radiology records, hospital EPRs and so on. Additional sets of requirements represented by wider bubbles going across the diagram correspond to extending the scope of the content of the care record first to a whole subject (resulting in a patient-centric, longitudinal health record) and then to populations or cohorts of subjects, as done in population health and research. From the (human) healthcare point of view, the important requirements groups extend all the way to the bottom row of the diagram.

Going down the diagram, requirements corresponding to increasing specificity of subject of care (from "any" to "human") are mostly implemented in openEHR by the use of archetypes. Going across the diagram, the requirements corresponding to increasing scope of record content (from episodic to population) are mainly expressed in different deployments, generally going from standalone to a shared interoperable form. One of the key aspirations for EHRs today is the "integrated care record" sought by many health authorities today1, which provides an informational framework for integrated shared care.

As a result of the approach taken by openEHR, components and applications built to satisfy the requirements of an integrated shared care record can also be deployed as (for example) an episodic radiology record system.

Some of the key requirements developed during the evolution of GEHR to openEHR are listed in the following sections, corresponding to some of the major requirements groups of FIGURE 2.

Generic Care Record Requirements

The openEHR requirements include the following, corresponding to a basic, generic record of care:

Health Care Record (EPR)

The following requirements addressed in openEHR correspond to a local health record, or EPR:

Shared Care EHR

The following requirements addressed in openEHR correspond to an integrated shared care EHR:

3.2 Clinical Aims

From a more specifically clinical care perspective (rather than a record-keeping perspective), the following requirements have been identified during the development of openEHR:

The Integrated Care EHR holds great promise: to generalise and make widely available the benefits of computerisation that have been demonstrated individually and in isolated settings. These can be summarised as:

One comprehensive statement of EHR requirements covering many of the above is the ISO Technical Report 183082 for which an openEHR profile has been created3. The requirements summarised above are described in more detail in the openEHR EHR Information Model document.

3.3 Deployment Environments

Ultimately any software and information architecture only provides utility when deployed. The architecture of openEHR is designed to support the construction of a number of types of system. One of the most important, the integrated shared care health record is illustrated in FIGURE 3.

In this form, the openEHR services are added to the existing IT infrastructure to provide a shared, secure health record for patients that are seen by any number of health providers in their community context. openEHR-enabled systems can also be used to provide EMR/EPR functionality at provider locations. Overall, a number of important categories of system can be implemented using openEHR including the following:

1The Integrated Care EHR is described in ISO/TR 20514 (2005)
2see http://www.openehr.org/downloads/ISOEHRRequirements.zip
3see http://www.openehr.org/svn/specification/TRUNK/publishing/requirements/iso18308_conformance.pdf


openEHR Foundation
http://www.openEHR.org
TOC PREV NEXT INDEX