Dr Ian McNicoll

What is openEHR?

Megasuite architecture

‘Best of breed’ architecture

‘Closed platform’ architecture

‘open platform’ architecture

What is openEHR?An open specification for a health information model

capable of supporting an open ecosystem

vendor neutral

technology neutral

licensed with Apache to allow open and closed source business models

What is openEHR not?openEHR is NOT

an open source health application

a downloadable app

owned by a single vendor or commercial organisation

commercially unfriendly

‘open platform’ architecture

openEHR Foundation

Not-for-profit company based at University College, London, UK.

Owns the Intellectual Property and has high-level governance role

New Management Board recently elected

Alliance of Industry and Clinical representatives

www.openehr.org

openEHR activitiesOwns the Intellectual Property

all openly licensed Apache, CC-BY-SA, CC-BY-ND

Supports revision of specifications

Website / communications

maintains an international repository of freely available clinical content models - ‘archetypes’

openEHR Software

open source/free Modelling tools

Archetype Editor, Template Designer

Archetype Workbench

Guideline Definition Language editor

open source demo code

openEHR - key goalProvide specifications that allow a system developer to meet the very difficult requirements of health system building

but keep the data in any openEHR system completely interoperable and queryable

regardless of programming language

regardless of human language

regardless of internal database technology

openEHR - SpecificationsNormal technical specifications with UML diagrams etc

openEHR Reference model

how the health data is represented in a patient record

openEHR Archetype object model

how the clinical content definitions are represented separately from the Reference model

Separation of concerns…Allows system developers to optimise the RM layer without having to make any changes to accomodate new clinical concepts

Allows a relatively small, optimisable ‘kernel’ to be maintained

no data model reconfiguration

no database schema reconfiguration

Separation of concerns…All of the ‘clinical content’ is defined in archetypes, and is developed and maintained by clinicians using dedicated tooling

The native file format is ADL (Archetype Definition Language), a DSL but it is also expressible in xml, json etc

ADL is an ISO-standard also used by the ISO 13606 and CIMI

Everything in an archetype is based on and conformant with the reference model

Clinical Information models factory

AQL: Information-model queryingopenEHR systems support information model querying, independent of the actual persistence layer/ querying mechanism

Archetype Query language

vendor/technology neutral querying

To query an openEHR system you only have to know which archetypes are in use. You do not have to know the persistence layer schema

It is the responsibility of the system developer to create a mapping between the AQL statement and the native querying mechanism

Vendor-neutral querying

SMARTPlatformsPluggable Webapp

API

HL7 FHIR Clinical Content Exchange

NHS API

‘inVivo’Datastore API

Detailed Clinical Content

Development

Clinical leadership PRSB

Terminology CentreHSCIC

NonopenEHR systems

Archetype+ SNOMED Clinical Content definitions

However ….Building an openEHR back-end is easy if you follow the specifications

BUT

building a performant openEHR back-end is hard

must accept new semi-arbitrary tree-like structures

must support information-model querying

must be fast and flexible

This is not a trivial engineering exercise

Technical approachesNormalised RDBMS

hard to respond to content changes

O-R mapping such as Hibernate

does not scale well

NoSQL solutions

seemingly a good fit but not much real-world experience

Mumps implementation

MongoDB used in academic ‘big data project’

Commercial offerings

RDBMS + indexed binary blobs

Postgres, Oracle, SQL Server

minimal normalisation

minimal use of SQL features

The good news…You do not have to build your own back-end

you have to be crazy or have a very big budget to do so

There are at least 10 commercial providers of back-end openEHR servers and more being developed

The APIs are small and easy to use once you understand the basic concepts

Stack Compositions

Templatevalidation AQL GDL

supportopen

source Separate product

Think!EHR Oracle Yes Yes Yes Yes Yes

OceanEHR SQL server Yes Yes Yes Yes Yes

DipsEHR SQL Server Yes Yes Yes Yes ?

EtherCIS PostgreSQL Yes Yes In dev In dev Yes Yes

Infinni SQL Server Yes Yes ? Yes

Base24 PostgreSQL Yes Yes In dev In dev Yes

Cabolabs Yes Yes Yes Yes

Nousco ? Yes Yes Yes

Privantis PostgreSQL Yes Yes In dev In dev In dev

Medrecord360 ? Yes Yes

Current CDR market

eHealth'('City'of'Moscow''

Reproduced'with'permission''h9p://bit.ly/1w9wZQy''

Does it scale?

openEHR Service API

openEHR: App development

Faster, safer app developmentFaster and easier to build new apps based on openEHR

use existing archetypes

Much faster to respond to changes in clinical practice

Interoperability out-of-the-box

Growing ‘open platform’ market

National ‘standards’ development

Healthcare Information Standards Process #FAIL

Clinical stakeholders engage through top-

down governance

Committee-based

Late vendor engagement

Fixed review cycles

Unclear / unresponsive

change request mechanism

Evolutionary standardisation ‘distributed Governance’

Implementers

Secondary endorsement

openEHR summaryDesigned for storing and querying rich clinical dataset

New content is defined directly by clinicians and can be immediately uploaded into the clinical data repository

Vendor-neutral data models Technology-neutral data models

Vendor-neutral data querying Technology-neutral data querying