openEHR sll-2015final

Rong Chen, MD, PhDopenEHR Management Board

Co-lead, openEHR Specification Program

CMIO, Cambio Healthcare Systems

Copyright 2015 openEHR Foundation

Thomas BealeopenEHR Management Board

Co-lead, openEHR Specification Program

CTO, Ocean Informatics

"eHealth is just healthcare management of the 21st century. It's not an ICT project.”◦ Madis Tiik, CEO, Estonian E-Health Foundation

Copyright 2014 openEHR FoundationCopyright 2014 openEHR Foundation

Open or closed?

Retain or cede control?



govpayers

vendors

provider institutionssolutions

builddeploy care

SDOs

?

Q:How much influence

does the buyer really have?

A: control points

are usually limited to

Function points, limited

standards conformance


govpayers

vendors


builddeploy care

SDOs

?

How much influence

Government?


govpayers

vendors


builddeploy care

SDOs

e-health programme

?

Technical requirements

based on?


e-health programme

govpayers

vendors


builddeploy care

SDOs

? integrate

PLATFORM

Now procurement

has a means of

requiring

conformance –

a fully defined set

of specifications

Copyright 2015 openEHR

1. Standard Information model

2. Standard content

definitions

Service API

B2B Service API

Service API

Service API

B2B Service API B2B Service API

Service API

Service API Service API

Service API

4. Standard

interfaces

3. Open terminologies

5. Semantic Querying

app app

other system


e-health programme

govpayers

vendors


builddeploy care

SDOs

? integrate

PLATFORM

Except the

buyer side has

no means of

influence


e-health programme

govpayers

vendor

provider institutions

builddeploy care

SDOs

?

solution

PLATFORM

And no visibility

Primarily the Patient data (EHR/CDR)◦ Want to use as needed, including unplanned uses

◦ Value of data relies on its computability


And ways of interacting with it◦ Open application APIs - Enable new apps to be

added at any time in a known way, e.g. care planning

◦ B2B service interfaces - e.g. lab data, EHR extract to DW, quality registers

And open knowledge engineering – develop microbiology result definition and terminology subsets…. Once, for the whole jurisdiction


Environment with (un-?)controlled cost characteristic

Cost characteristic is based on ability to modify the environment in a relatively fine-grained way, with the price relating to the true underlying cost of the component in question◦ Add / remove apps

◦ Change / add back-ends

◦ Add / modify connection points

◦ Reprocess data at will


With monolithic supplier, not only are the technical details outsourced, so too is the ability to control costs of incremental change◦ The cost of a change is what the supplier says it is

You are now invested in the supplier’s development path, not your own


No vendor lock-in

Free access to, use & reuse of data… forever

Incremental deployment of components according to customer timeline

Direct clinical engagement (ask Norway!)

Control over costs




2. Standard content

definitions

Service API

B2B Service API

Service API

Service API


Service API


Service API

4. Standard

interfaces



app app

other system

We don’t propose a ‘bag of standards’

Instead we propose a coherent platform definition, managed by a single .org entity◦ That defines many key elements – information

models, content models, guidelines,

◦ And sources others from elsewhere, and integrates them properly

IHE.net with openEHR profiles

IHTSDO, WHO, WONCA, LOINC etc

HL7 FHIR? CDA?

OMG RLUS, EIS

etc


Most of the semantics come from clinical models (‘archetypes’ and ‘templates’) and terminology

These are built by clinical people (e.g. Norway MoH / Bergen…) in a crowd-sourced fashion

They ultimately define data-sets & value-sets

Which can be used to generate usable software artefacts

we no longer wait for some SDO to produce a standard for ‘discharge summary’


Non-profit organisation based at UCL

1300+ Members from 71 countries

All specifications & schemas publicly available

Software open source (GPL, LGPL, Apache2)

Is to define (parts of) a health computing ‘platform’ that addresses these challenges:◦ Information and workflow complexity

◦ Constantlychanging clinical requirements

◦ A long-lived patient-centric EHR

◦ Enables diverse e-health vendor components and products to work together


The clinical domain generates most of the requirements◦ And is changing all the time

We therefore need to model the clinical domain to do sustainable ICT◦ Terminology models the ‘facts’

◦ We still need to model the information & workflow

openEHR enables a model-based tool chain for building sustainable software solutions


Nr semantic definitions huge and constantly growing – O(1E6)

Nearly all semantic definitions only doable by domain professionals◦ Not IT people

Number of technical expressions substantial and always changing – O(1E2)◦ Prog langs, various XSD, JSON, UI, …


We need to enable domain professionals to do the semantic modelling directly◦ special tools and formalisms

We need to do the models upstream of the technical representations◦ requires model software transform tools

We need to build systems that accept generated model artefacts… forever



Deployed

system

consumes new

content definitions

... forever

Forms and

messages formally

based on content

models



2. Standard content

definitions

Service API

B2B Service API

Service API

Service API


Service API


Service API

4. Standard

interfaces



app app

other system

The road ahead is a process not a product

It’s an ecosystem not a monoculture


http://www.openEHR.org

http://www.openEHR.org/ckm


http://www.openehr.org/

http://www.openehr.org/ckm

openEHR sll-2015final

Healthcare

Transcript of openEHR sll-2015final