Page 1

openEHR Primer - openEHR :: future proof and flexible EHR specifications

Page 1 of 6

Home » Resources » Getting Started... » openEHR Primer page

openEHR Primer Contents l l l l l l l l l l l l

The Current Situation in Health Information The openEHR Foundation The EHR Distributed Health Information Environment Models, Data, Terminology The openEHR approach How openEHR can Improve Clinical Care Security, Privacy and Consent Standards Open Source Research and Education The openEHR Community

The Current Situation in Health Information Health Information Systems today suffer from a number of key problems: l

lack of interoperability and vendor lock-in;

l

cost and difficulty of maintenance, given the rate of change and sheer size of the information in the health domain;

l

lack of support for security, privacy and consent.

These shortcomings are widely recognised, but doing something about them is not simple, because of the sheer volume of health data being produced, and the number and complexity of systems. There is no silver bullet fix, of course. However, the openEHR Foundation proposes solutions based on a reconceptualisation of the problem space not in narrow IT implementation terms, but in terms of an integrated framework of technical modelling, domain modelling, and software engineering. The following sections describe openEHR thinking in more detail.

The openEHR Foundation The openEHR Foundation was created to enable the development of open specifications, software and knowledge resources for health information systems, in particular electronic health record (EHR) systems. It publishes all its specifications, and builds reference implementations of them, as open source software. It also develops 'archetypes' and a terminology for use with EHRs. More information about the Foundation can be found in the About Us section.

The EHR In openEHR, the definition of the "electronic health record" corresponds to the "Integrated Care EHR" as defined in ISO/DTR 20514: l

The Integrated Care EHR is defined as a repository of information regarding the health of a

Create PDF with GO2PDF for free, if you wish to remove this line, click here to buy Virtual PDF Printer http://www.openehr.org/shared-resources/getting_started/openehr_primer.html 8/9/2010


openEHR Primer - openEHR :: future proof and flexible EHR specifications

Page 2 of 6

subject of care in computer processable form, stored and transmitted securely, and accessible by multiple authorised users. It has a commonly agreed logical information model which is independent of EHR systems.Its primary purpose is the support of continuing, efficient and quality integrated health care and it contains information which is retrospective, concurrent and prospective. In practical terms, this means that an EHR has the following characteristics: l

patient-centred: one EHR relates to one subject of care, not to an episode of care at an

l

institution; longitudinal: it is a long-term record of care, possibly birth to death;

l

l

comprehensive: it includes a record of care events from all types of carers and provider institutions tending to a patient, not just one speciality; in other words there are no important care events of any kind not in the EHR; prospective: not only are previous events recorded, so is decisional and prospective information such as plans, goals, orders and evaluations.

Distributed Health Information Environment

Click to enlarge The notion of a distributed health computing environment is a key part of the openEHR vision. Health computing environments need to be modular, secure, and web-enabled. The diagram shown above may help to visualise the breadth of information services and types needed in a reasonable deployment. Much of the current openEHR thinking on distributed computing environments in health is based on the excellent previous works of the (then) OMG Corbamed taskforce, and the Distributed Healthcare Environment (DHE) work done in Europe in EU-funded projects such as RICHE and EDITH, and the HANSA and PICNIC implementation projects.

Models, Data, Terminology Health information systems can be built by defining information models, implementing them in databases and applications, and adding clinical terminologies. However, to build a future-proof health computing environment for lifelong shared care requires somewhat more. Firstly, there need to be requirements, without which no proper modelling can be done. The requirements on which openEHR is based include: l

The GEHR project requirements;

l

Technical EHR requirements written for the Australian GEHR project; Requirements developed over the years since GEHR in Europe, documented in Dr Dipak Kalra's

l

Create PDF with GO2PDF for free, if you wish to remove this line, click here to buy Virtual PDF Printer http://www.openehr.org/shared-resources/getting_started/openehr_primer.html 8/9/2010


openEHR Primer - openEHR :: future proof and flexible EHR specifications

l

Page 3 of 6

doctoral thesis; the ISO 18308 requirements for an Electronic Health Record Architecture.

The information models of openEHR are based on many years of exploring these requirements and developing implementations, and can be found on the specification page. These models were developed from the ground up on the basis of a "two-level modelling" approach, of which archetypes are a major aspect (archetypes FAQ). Terminology is used in openEHR via the mediating technology of archetypes and templates, which allow domain models (e.g. of things like "blood pressure measurement", "physical examination", "biochemistry lab result") to be defined neutrally with respect to terminologies; these models can then be bound to multiple terminologies as needed. EHR is also developing a small terminology for use with its models (see openEHR Terminology).

The openEHR approach openEHR formalises the Electronic Health Record in terms of: 1. Reference model (RM) This is the model that describes the health record itself - not the clinical data that is contained within it. The reference model deals with containers such as Folders and Compositions. Compositions are a broader concept than documents - but include documents. Examples of Compositions are an ECG report, a progress note, a laboratory report and a referral. The Composition is the minimum unit of communication and committal to the EHR. The openEHR Reference Model specifications are available from the specification page; online UML. 2. Archetype Model (AM) Archetypes are descriptions of valid Entries, Sections and Compositions. These are expressed in a formal manner which enables them to be shared between systems. A blood pressure archetype represents a description of all the information a clinician might want to report about a blood pressure measurement, and may include some aspects which are mandatory. A 'SOAP' archetype describes the sections of a problem oriented health note and which entries are valid under each section - for example only diagnoses may be allowed under the 'A' section. Templates are logical models of user forms - and are described in terms of choices of archetypes whose data are captured on a particular form. See the Archetypes and Templates FAQ. The openEHR Archetype Model specifications are available from the specification page; online UML. 3. Service Model (SM) This is the computational viewpoint of the openEHR architecture. The service model consists of service definitions for the major services in the EHR computing environment. These are largely derived from existing work in OMG Corbamed, CEN HISA and implementation experience. 4. Terminology and other Ontologies Underpinning archetype-enabled health record systems are knowledge resources such as vocabularies, terminologies and ontologies, which define the semantics of terms and concepts referenced in the health record. Archetypes enable multiple terminologies to be used, and in any natural language in which they are available. The relationship of the formal artefacts of openEHR is shown below.

Create PDF with GO2PDF for free, if you wish to remove this line, click here to buy Virtual PDF Printer http://www.openehr.org/shared-resources/getting_started/openehr_primer.html 8/9/2010


openEHR Primer - openEHR :: future proof and flexible EHR specifications

Page 4 of 6

Click to enlarge The Architectural Overview (PDF, HTML) provides a good summary of the technical architecture of openEHR.

How openEHR can Improve Clinical Care The effects of using a system whose software is built on a reference model, but whose clinical models are represented and processed separately are several. l

Software maintenance is reduced, since the software does not have to be changed every

l

time the model of some clinical data changes - only the archetypes change. Data validity is increased, because archetypes are used to validate all data input to the EHR.

l

From a clinical point of view, data is more trustworthy. Interoperability is vastly increased, because data are comunicated between systems only in terms of standard, open reference model instances, while knowledge interoperability is achieved by the sharing of archetypes between computer systems. Archetypes are used at both ends to validate and query the data. Wider interoperability improves the sharing of information among clinicians inside a hospital, in a community care network, and at larger distances.

l

l

Standards-based. The openEHR Reference Model is based on ISO and CEN EHR standards, and is interoeprable with HL7 and EDIFACT message standards. This enables openEHR-based software to be integrated with other software and systems. Integration with Existing/Legacy systems. Being standards-based, openEHR software can integrate with the many systems which use well-known data interoperability standards. Further, the use of archetypes enables data from legacy relational databases to be "purified" as it is converted, and exception reports generated, indicating errors in the data.

In short, clinical data are more likely to be correct, is more sharable, and software is not subject to "vendor lock-in" - all leading to better quality and more cost-effective clinical care.

Security, Privacy and Consent The security requirements of health data are likely to be greater, and more difficult to satisfy than for any other kind of data, including financial. This is partly because of the seeming paradox of conflicting needs of the two primary categories of health data stakeholders: l l

clinicians: to do shared care, clinicians need more open EHRs; patients: need privacy, and are likely to prefer more closed EHRs.

The potential threats to improper use of health data are numerous, and range from doctors and

Create PDF with GO2PDF for free, if you wish to remove this line, click here to buy Virtual PDF Printer http://www.openehr.org/shared-resources/getting_started/openehr_primer.html 8/9/2010


openEHR Primer - openEHR :: future proof and flexible EHR specifications

Page 5 of 6

patients retrospectively modifying data, to insurance companies and employers making decisions on policies and jobs based on private health facts. Ross Anderson's BMA Security paper is worth a read on the subject of threats and solutions for secure health information. The openEHR approach to security rests on the same premise proposed by the BMA (quoted in the above paper): l

Informed consent: patients have a right to expect that you [the clinician] will not pass on any personal information which you learn in the course of your professional duties, unless they agree.

With this premise realised in a secure health environment, a second premise relating to clinician access can be stated: l

Relevance of access: clinicians should only have access to the patient's health record if it can be established that they are currently engaged in provision of care for the patient, at the current time.

The openEHR specifications assume both of these premises, and most of the principles described in Anderson's paper. In particular, privacy settings can be set on selected parts of the EHR, not just the whole thing.

Standards The openEHR Foundation sees standards as vitally important in improving the prospects of highquality health records and systems, but also sees "paper-only" standards as flawed. Standards are only useful with validation via implementation, and a recognised feedback path into the standards process. Accordingly, openEHR people are heavily involved in health standards work in Europe (CEN TC/251) and internationally (HL7 and ISO). However, openEHR does more: it produces specifications of systems which are based not just on standards, but on good modelling and engineering principles, and which are perfected over time by ongoing implementation experience. The results of all work are fed back into the specifications, which of course are available to standards bodies. The Archetype Definition Language (ADL; specification for ADL 1.4; ADL 2.0) is a good example of a formalism which was written by members of openEHR, and tested in software before being proposed for adoption by both CEN TC/251 and HL7 for use in their archetypes and templates standards respectively. The openEHR standards pages are available here: ISO, CEN, HL7.

Intellectual property and open source openEHR's approach to open source is simple: any interoperability component must be available in open source form, and so must its specification. This is the only way to get industry vendors together to cooperate on interoperability components, rather than competing by making their systems noninteroperable. The result is systems which contain trusted interoperability components, developed and certified in the open, and vendors who compete on quality of applications and infrastructure instead. All of openEHR's specifications are openly available (under the openEHR copyright notice), as is its

Create PDF with GO2PDF for free, if you wish to remove this line, click here to buy Virtual PDF Printer http://www.openehr.org/shared-resources/getting_started/openehr_primer.html 8/9/2010


openEHR Primer - openEHR :: future proof and flexible EHR specifications

Page 6 of 6

software (under the Mozilla "tri-license"). See the licensing page for details. Comments (0)

Contact webmaster

Copyright 2007 openEHR

Discussions about online resources

Create PDF with GO2PDF for free, if you wish to remove this line, click here to buy Virtual PDF Printer http://www.openehr.org/shared-resources/getting_started/openehr_primer.html 8/9/2010

Primer