The openEHR Developers' workshop 2016

Owned by Shinji Kobayashi
Last updated: 05-Sept-2016 by Erik Sundvall
5 min read

The openEHR Developers' workshop

Shinji Kobayashia, Koray Atalag (Deactivated)b, Erik Sundvall c,d ,Christian Chevalleye , Samar El Heloua, Sebastian Garde, Ian McNicollg, 

aKyoto University, Japan, bUniversity of Auckland, cLinköping University, dRegion Östergötland, eADOC Software, fOcean Informatics, gHandiHealth

Abstract

The openEHR project is well-known for publishing and updating a set of open specifications to build maintinable and semantically interoperable (and even intraoperable) electronic health record systems that stay agile in a changing clinical reality. It is closely related to the family of ISO 13606 standards and to CIMI (now an HL7 WG). The detailed openEHR clinical models (archetypes and templates) are authored by global and regional clinical communities in an online environment where the authoring and review process gathers views and concensus from a breadth of clinical specialities. The 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 based implementations and integrations primarily from developer and systems-engineering perspectives. In recent years several different technical openEHR persistence implementation approaches have been published, two recent approaches using graph-databases and combinations of relational+schemaless databases will also be described and discussed. Developers in an openEHR context nowadays thus have access to both a wealth of detailed clinical models and a wealth of published approaches to technical implementation using various persitence solutions, APIs and programming languages.

Keywords:

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

1. Introduction

Initially, we will provide an overview of the openEHR architecture and the clinical+technical usage contexts. This is followed by a number of presentations introducing various openEHR projects and related integrations. After the introduction and between each subtopic presentation there will be Q&A and open discussions with the 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 An openEHR architecture overview

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 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)
  • The mix of people, process and technology; how using archetypes, templates, AQL and GDL etc. a as a basis in EHR systems enables agility in adapting to changing clinical needs and reduces maintenance time. 
  • Options on the spectrum between semantic intraoperability and interoperability. (By intraoperability we here refer to the possibility to align internal clinical EHR datamodels across organizational boundaries and insi systems from different vendors - and thus easily share both data and share the workload of model authoring and maintenance.)

  • A quick overview of different exisiting (previously published/available/discussed) approaches to implementing openEHR; persistence solutions, APIs, programming languages, open source core reference implementnations (in e.g. Java, C#, Ruby, Eiffel)

  • Comparing steps needed to implement archetype-based systems from scratch versus using/integrating existing openEHR based components and APIs
  • A quick overview of where in the world openEHR is used.

1.2. Examples of implementation and integration projects

See below for abstracts of short presentations

1.3. Discussion

Final open discussion, questions and answers

2. Examples of implementation and integration approaches

2.1. Short presentations: 

2.1.1 HL7 FHIR, openEHR and IHE: perspectives on coexistence and collaboration (Erik Sundvall, Ian McNicoll, Koray Atalag and Borut Fabjan) 

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 succesfully used in IHE profiled exchange environments and some are IHE-certified, we'll also discuss such options and combinations. (Update:Slides of this part attached - sorry we did not have time to cover IHE in these.)

2.2.2 EtherCIS a new Open Source OpenEHR backend server (Christian Chevalley)

EtherCIS is a DB centric openEHR compliant SOA platform. It exposes a RESTful API handling OpenEhr entities under three formats (Flat json, AQLPath json and XML). The motivation of EtherCIS has been to provide an open, scalable yet secure clinical data repository that can be queried using different languages (AQL and SQL). SQL querying is performed using standard tools, as recent progresses in DB  developments now allow combinations of relational and schema-less data structures. We will discuss our experiences (and failures) with previous persistence approaches, pros and cons of the current one and future perspectives in line with major DB engines developments.

2.2.3 Implementation of an openEHR repository using a Graph Database (Samar El Helou)

Building openEHR repositories is challenging since it requires a thorough grasp and implementation of the openEHR Reference Model (RM) that has numerous classes in a tree-structure with deep hierarchy. Moreover, a mismatch between the database model and the RM can lead to high development time and cost. The graph model shares many semantic similarities with the definitions of the openEHR RM making it a potential fit for its representation and implementation. We will propose a method for implementing an openEHR repository by a graph database employing the labeled property graph model. We will also discuss some limitations and opportunities of persisting openEHR data with Neo4j.

2.2.4 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.

 

3. Workshop speakers

  • Shinji Kobayashi, MD, PhD - Kyoto University, Japan
  • Sebastian Garde, Dr. sc. hum., Dipl.-Inform. Med., FACHI - Ocean Informatics, Germany
  • Erik Sundvall, MSc, PhD - Linköping University and Region Östergötland, Sweden
  • Christian Chevalley, Founder and Technical Director, ADOC Software, Thailand
  • Samar El Helou - Kyoto University, Japan
  • Borut Fabjan, Marand, Slovenia

4. References