Jump to content

openEHR

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Silje (talk | contribs) at 22:20, 5 February 2015 (changing category to the more correct "Standards for electronic health records", changing the template since openEHR isn't software but a set of specifications). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

openEHR is an open standard specification in health informatics that describes the management and storage, retrieval and exchange of health data in electronic health records (EHRs). In openEHR, all health data for a person is stored in a "one lifetime", vendor-independent, person-centred EHR. The openEHR specification is not concerned with the exchange of data between EHR-systems as this is the primary focus of other standards such as EN 13606 and HL7.

The openEHR specifications are maintained by the openEHR Foundation, a not for profit foundation supporting the open research, development, and implementation of openEHR EHRs. The openEHR specifications are based on a combination of 15 years of European and Australian research and development into EHRs and new paradigms, including what has become known as the archetype methodology[1][2] for specification of content.

The openEHR specifications include information and service models for the EHR, demographics, clinical workflow and archetypes. They are designed to be the basis of a medico-legally sound, distributed, versioned EHR infrastructure.

Multi-level Modelling Methodology

The key innovation in the openEHR framework is to leave all specification of clinical information out of the information model (also commonly known as "reference model" in health informatics) but, most importantly, to provide a powerful means of expressing what clinicians and patients report that they need to record so that the information can be understood and processed wherever there is a need.[citation needed]

Clinical content is specified in terms of two types of artefact which exist outside the information model. The first, known as "archetypes" provides a place to formally define re-usable data point and data group definitions, i.e. content items that will be re-used in numerous contexts. Typical examples include "systemic arterial blood pressure measurement" and "serum sodium". Many such data points occur in logical groups, e.g. the group of data items to document an allergic reaction, or the analytes in a liver function test result. Some archetypes contain numerous data points, e.g. 50, although a more common number is 10-20. A collection of archetypes can be understood as a "library" of re-usable domain content definitions, with each archetype functioning as a "governance unit", whose contents are co-designed, reviewed and published.

The second kind of artefact is known in openEHR as a "template", and is used to logically represent a use case-specific data-set, such as the data items making up a patient discharge summary, or a radiology report.[3] A template is constructed by referencing relevant items from a number of archetypes. A template might only require one or two data points or groups from each archetype. In terms of the technical representation, openEHR templates cannot violate the semantics of the archetypes from which they are constructed. Templates are almost always developed for local use by software developers and clinical analysts. Templates are typically defined for GUI screen forms, message definitions and document definitions, and as such, correspond to "operational" content definitions.

The justification for the two layers of models over and above the information model is that if data set definitions consist of pre-defined data points from a library of such definitions, then all recorded data (i.e. instances of templates) will ultimately just be instances of the standard content definitions. This provides a basis for standardised querying to work. Without the archetype "library" level, every data set (i.e. chunk of operational content) is uniquely defined and a standard approach to querying is difficult.

Accordingly, openEHR defines a method of querying based on archetypes, known as AQL (Archetype Querying Language).[4]

Notably, openEHR has been used to model shared care plan. The archetypes have been designed to accommodate the concepts of the shared care plan.[5]

While individual health records may be vastly different in content, the core information in openEHR data instances always complies to archetypes. The way this works is by creating archetypes which express clinical information in a way that is highly reusable, even universal in some cases.[6]

Formalisms

openEHR archetypes are expressed in "Archetype Definition Language", an openEHR public specification. Two versions are available: ADL 1.4,[7] and ADL 1.5,[8] a forthcoming (2013) release with better support for specialisation, redefinition and annotations, among other improvements.[9] The 1.4 release of ADL and its "object model" counterpart Archetype Object Model (AOM) are the basis for the CEN and ISO "Archetype Definition Language" standard (ISO standard 13606-2).

Templates have historically been developed in a simple, de facto industry-developed XML format, known as ".oet", after the file extension.[10] In future, templates may be expressed in ADL 1.5, enabling them to be processed seamlessly with archetypes.

Quality Assurance of Archetypes

Various principles for developing archetypes have been identified.[11] For example, a set of openEHR archetypes needs to be quality managed to conform to a number of axioms such as being mutually exclusive. The archetypes can be managed independently from software implementations and infrastructure, in the hands of clinician groups to ensure they meet the real needs on the ground. Archetypes are designed to allow the specification of clinical knowledge to evolve and develop over time. Challenges in implementation of information designs expressed in openEHR centre on the extent to which actual system constraints are in harmony with the information design.[citation needed]

In the field of Electronic health records there are a number of existing information models with overlaps in their scope which are difficult to manage, such as between HL7 V3 and SNOMED CT. The openEHR approach faces harmonisation challenges unless used in isolation.[citation needed]

International collaboration

Following the openEHR approach, the use of shared and governed archetypes globally would ensure openEHR health data could be consistently manipulated and viewed, regardless of the technical, organisational and cultural context. This approach also means the actual data models used by any EHR are flexible, given that new archetypes may be defined to meet future needs of clinical record keeping. Recently work in Australia has demonstrated how archetypes and templates may be used to facilitate the use of legacy health record and message data in an openEHR health record system, and output standardised messages and CDA documents.

The prospect of gaining agreement on design and on forms of governance at the international level remains speculative, with influences ranging from the diverse medico-legal environments to cultural variations, to technical variations such as the extent to which a reference clinical terminology is to be integral.

The openEHR Framework is consistent with the new Electronic Health Record Communication Standard (EN 13606). It is being used in parts of the UK NHS Connecting for Health Programme and has been selected as the basis for the national program in Sweden. It is also under evaluation in a number of countries including Denmark, Slovakia, Chile and Brazil. It is beginning to be utilised in commercial systems throughout the world.

Clinical Knowledge Manager

One of the key features of openEHR is the development of structures and terminologies to represent health data. Due to the open nature of openEHR, these structures are publicly available to be used and implemented in health information systems. Commonly, community users share, discuss and approve these structures in a repository known as the Clinical Knowledge Manager (CKM). Some currently used openEHR CKMs:

See also

References

  1. ^ Beale, Thomas (2002). "Archetypes: Constraint-based Domain Models for Future-proof Information Systems" (PDF). Proceedings of the 11th OOPSLA Workshop on Behavioural Semantics. (PDF)
  2. ^ S. Heard & T. Beale. (eds.) (2007). "openEHR Architecture Overview" (PDF). openEHR Foundation. Retrieved 9 April 2013. {{cite web}}: |author= has generic name (help) (PDF)
  3. ^ "What is openEHR". openEHR Foundation. Retrieved 9 April 2013.
  4. ^ "Archetype Query Language (AQL)". openEHR Foundation. Retrieved 9 April 2013.
  5. ^ Hagglund, M; Chen, R.; Koch, S (2011). "Modeling shared care plans using CONTsys and openEHR to support shared homecare of the elderly". Journal of the American Medical Informatics Association. 18 (1): 66–69. doi:10.1136/jamia.2009.000216.
  6. ^ "Clinical Standardisation". openEHR Foundation. Retrieved 9 April 2013.
  7. ^ Beale, T; Heard, S, eds. (12 Dec 2008), Archetype Definition Language 1.4 (PDF), openEHR Foundation.
  8. ^ openEHR Specification Program (15 Apr 2013), Archetype Definition Language 1.5 (PDF), openEHR Foundation.
  9. ^ "ADL/AOM 1.5 specifications". openEHR Foundation. Retrieved 9 April 2013.
  10. ^ "Template ".oet" XSD". openEHR Foundation. Retrieved 9 April 2013.
  11. ^ S. Heard & T. Beale. (eds.) (2005). "Archetype definitions and principles" (PDF). openEHR Foundation. Retrieved 9 April 2013. {{cite web}}: |author= has generic name (help) (PDF)
Retrieved from "https://en.wikipedia.org/w/index.php?title=OpenEHR&oldid=645808599"