Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

The openEHR Developers' workshop

Ian McNicoll a,b, Koray Atalag c`, Erik Sundvall d,e, Sebastian Garde f , Thomas Beale

aopenEHR Foundation, bCHIME UCL cUniversity of Auckland, cLinköping University, cRegion Östergötland, fOcean Informatics

Abstract

The openEHR project is well-known for publishing and updating a set of open specifications against which implementers can build highly maintainable and semantically interoperable (and even intraoperable) electronic health record systems that can  respond in an agile way to changing clinical reality. It is closely related to the family of ISO 13606 standards and to HL7 CIMI and has influenced HL7 FHIR architecture development. The detailed openEHR clinical models (archetypes and templates) are authored by global and regional clinical communities. supported by an online environment and distributed governance process which draw heavily on open-source distributed development methodology. openEHR archetypes are often used as a source of clinical requirements gathering also in non-archetype-based systems and interoperability standards (e.g.HL7 FHIR).

This workshop will introduce and discuss openEHR from an implementation and systems-engineering perspective. In recent years several different technical openEHR persistence implementation approaches have been developed and made available to third-party implementers. Developers in an openEHR context nowadays thus have access to both a wealth of detailed clinical models, a variety of published approaches to technical implementation, third-party solutions, APIs and programming languages.

Keywords:

Electronic Health Records, openEHR, archetype, interoperability, intraoperability, open-source software, clinical standards, HL7 FHIR, IHE

1. Introduction

After a brief introduction to the openEHR architecture, governance  and ‘open platform’ philosophy, a number of presentations will introduce a series of openEHR-related projects, current topics and research interests.

This will be followed by a plenary session to discuss issues raised by the presentations or other topics raised by workshop participants.

Knowledge of the openEHR specification/technology and computer science is helpful to understand some details in the workshop, but not required for understanding the general concepts.

1.1 openEHR architecture overview

openEHR is an open specification, for a clinical information model architecture, capable of supporting an ‘open health data platform’ which is both vendor and technology-neutral. Systems built on openEHR can respond directly to clinical innovation and diversity, without complex and expensive re-engineering. openEHR has been adopted by a number of implementers and national organisations to underpin system development or national clinical standards programs, with proven scalability and vendor-neutrality. There is increasing interest in the deployment of openEHR-based clinical data repositories alongside traditional clinical systems as a more agile and responsive partner, sometimes described as a ‘Bi-modal’ approach or ‘Post-modern EHR’.

The core technology of openEHR specification features a multi-level modeling system, often referred to as ‘archetype-based systems’. In this archetype-based technology, technical implementation is separated from the continuously updated detailed clinical modeling concerns in a way that makes it easier for implementers to maintain semantic intra- or interoperability. In this workshop introduction, we will briefly overview:

  • The openEHR reference model (RM) and the Archetype Model (AM) and associated specification documentations etc.

  • Standardized approaches to clinical querying (AQL), REST-interfaces and Clinical Decision Support rules (GDL)

  • Existing (previously published/available/discussed) approaches to implementing openEHR; persistence solutions, APIs, programming languages, open source core reference implementations (in e.g. Java, C#, Ruby, Eiffel)

  • Where in the world openEHR is used.

1.2. openEHR in practice

See below for abstracts of short presentations

1.3. Discussion

Final open discussion, questions and answers

2. openEHR in practice

2.1. Short presentations:

’.

2.1.1 HL7 FHIR, openEHR and IHE: perspectives on coexistence and collaboration (Erik Sundvall)

The HL7 FHIR standard has many benefits over some previous HL7 approaches and is gaining a lot of attention and implementation. There is also FHIR-hype, usually not from the core team behind FHIR, but from others hoping that FHIR will solve (almost) all healthcare information interoperability needs. We will highlight some differences and commonalities between the FHIR and openEHR approaches and exemplify how context of use and political/business views influences the short- and long-term benefits of different options and combinations. Some systems based on openEHR are successfully used in IHE profiled exchange environments and some are IHE-certified, we'll also discuss such options and combinations.

2.1.2  Process-enabled openEHR - future directions (Thomas Beale)

Building on the solid semantic architecture and existing features this work, such as its standard state machine for tracking order lifecycle, and its 500+ archetypes (detailed clinical models), the openEHR Specifications group is working on adding support for

  • planned actions

  • order sets

  • care plans

  • managed medications

  • Reporting

The aim is to provide an open architecture for a process-enabled EHR that helps the clinical team take a person needing care from where they are now to a goal state, via an efficient, evidence-based pathway tailored for the patient.

2.1.3 Clinical Knowledge Manager (Sebastian Garde)  

To be able to exchange clinical information in a semantically safe way across different openEHR-based systems, it is important to agree on the clinical concepts used in these systems. In openEHR, such concepts are formally expressed in archetypes and developed in regional, national and international collaboration. It is crucial that clinicians - even without any knowledge of openEHR - are inherently involved in this process by being able to review and comment as required. Only this can ensure that the clinical content models are clinically valid and comprehensive. To enable this collaboration, the Clinical Knowledge Manager (CKM) has been developed as a web-based system for collaborative development, management, validation, review and publishing of openEHR archetypes and other clinical knowledge resources. CKM is used internationally by the openEHR foundation as well as in several regional and national programmes. CKM supports the 'federation' of archetypes, so that the various programmes can work independently and to their own timelines, while sharing archetypes with each other where possible.

2.1.4 Working with openEHR Semantically (Koray Atalag)

We have used openEHR to model and persist experimental data that underpins computational physiology models (e.g. VPH, Human Physiome). The idea is then to link both experimental and real-world clinical information to these quantitative and predictive models to create a new breed of decision support tools that can deliver highly personalised and precision medicine. We have had some key important learnings while representing such models and especially when semantically annotating them - which in openEHR world corresponds to term and constraint bindings and data instance level term mappings. We will explain our methodology and discuss lessons learned which we hope will facilitate the use of openEHR in Semantic Web environments.

3. Workshop speakers

  • Ian McNicoll, MSc, MbChB, openEHR, CHIME UCL London

  • Thomas Beale, openEHR, London

  • Sebastian Garde, Dr. sc. hum., Dipl.-Inform. Med., FACHI - Ocean Informatics, Germany

  • Erik Sundvall, MSc, PhD - Linköping University and Region Östergötland, Sweden

  • Koray Atalag, MD, PhD, FACHI - University of Auckland, New Zealand

4. References

  • No labels