Dr Ian McNicollCo-chair, openEHR

Medinfo 2015, São Paulo

openEHR: the open platform revolution

www.openehr.org

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

capable of supporting an open ecosystem

vendor neutral

technology neutral

licensed with Apache/CC-BY-SA 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

Megasuite architecture

‘open ecosystem’ architecture

Two-level modelling

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

openEHR:Supporting an open eHealth Pl

Megasuite

Best of Breed

Platform

Open Ecosystem

“One system to rule them all”• English NHS NPfIT• Enterprise/GP Systems• Limited external integrations

Many systems ~ 100• Portals• Integration engines• Bespoke integrations

“Own the Platform”• Health Vault, Apple, Lorenzo, etc• ~1000 apps• Partner interfaces

The “Internet “of Digital Health• Healthcare Services Platform

Consortium• Moscow eHealth• devoManc

Separation of concerns…Allows system developers to optimise the RM layer without having to make any changes to accommodate 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, developed and maintained by clinicians

The native archetype format is ADL (Archetype Definition Language), but it is also expressible in XML, JSON, UML (AML)

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

openEHR: Archetypes• open source computable

models of discrete clinical concepts

• Familiar components of a health record• Blood pressure, Body weight• Symptom,Medication order, Family

history• Urea, Creatinine results

• ‘Maximal dataset’• Capture as many clinical perspectives

as possible• A Universal use case

openEHR: Templates• Templates deliver the

datasets by aggregating archetypes together

• Represent real-world datasets: ‘Vital signs data entry screen’, ‘Discharge summary’, ‘End of Life Care plan’

• Key clinical endpoint and starting point for generation of technical artefacts

CKM: web-based ‘democratised’ collaborative review

openehr.org/ckm

Clinical Information models factory

AQL: Information-model querying

openEHR systems support information model querying, independent of the actual persistence layer/ querying mechanism

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 physical persistence schema

Stakeholders in control• Two-level modelling gives

healthcare stakeholders control of their information, safe in the knowledge that whatever they design into archetypes will be consumed safely by an openEHR system

• If they share archetypes with another system, they have interoperability out-of-the box

• If they need to move data to a different vendor, this requires no transforms or other processing

‘Best of breed’ architecture

‘Closed platform’ architecture

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

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

Two-level modellingLow-level ‘stable’ reference model

Basic classes, structures, datatypes

Version control, auditing

Separate ‘clinical modelling’ layer which is applied as a ‘constraint’ on the RM

Clinical content is defined and managed separately but is always conformant to the RM and can always be consumed by the RM

Vendor-neutral querying

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 mad or have a very big budget to do so (for starters)

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

Does it scale?

openEHR: 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

HSCIChave adopted openEHR as primary ‘clinical content standards methodology’

acquiring a separate ‘English CKM’

developing archetypes for

PRSB Discharge summary

GPOC-R / GP2GP

Allergies, Blood pressure, Document metadata

http://www.infostandards.org/

documents/data-structures-v1-0-richard-

kavanagh-pptx.pptx

HSCIC

openEHR: Clinical Data Repositories

openEHR: App development

open-source Collaborative clinical content

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

From Russia with Love?http://www.woodcote-consulting.com/moscow-ehealth-a-model-for-the-uk/

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

HSPC: SMART on FHIR on Clinical Models

NHS England NHS Code4Health/Open source program

Using openEHR EHRscape engine for SME / clinical training

Supporting openEHR-based ‘Open platform’ approach

OPENeP

HANDIHealth / Integration Pioneers

‘HSCIC CKM’ licence

‘NHS Code4Health’

SMARTPlatformsPluggable Webapp

API

HL7 FHIR Clinical Content

Exchange NHS API

‘inVivo’Datastore

Detailed Clinical Content Development

Clinical leadership PRSB

Terminology CentreHSCIC

NonopenEHR

datastores

Archetype+ SNOMED Clinical Content definitions

Code4Health Ehrscape

openEHR summary• Designed for storing and querying

rich clinical dataset

• New content is defined directlyby clinicians and can be immediately uploaded into the clinical data repository

• Vendor-neutral data modelsTechnology-neutral data models

• Vendor-neutral data queryingTechnology-neutral data querying

Come and visit …