openehr The Reference Model Thomas Beale Sam Heard

openEHR

The Reference Model

Thomas Beale

Sam Heard

What openEHR

provides

openEHR Semantic architecture

1:N

Templates

1:N

Reference Model

Archetypes

1:N

Terminology

interface

Messages

Querying

Screen Forms

1:

N

Reports

Data conversion

schemas

Terminologies

S

no

m

ed

CT

ICD

x

ICP

C

Specification Map

Data Structures

Data Types

Demographic

EHR

Security

EHR Extract

virtual EHR

Archetype OM

Support

(identifiers, terminology access)

AM

RM

SM

EHR

service

archetype

service

demographic

service

terminology

service

{

core

Common

{

patterns

{

domain

{

Integration

}

Composition

openEHR Archetype Profile

Template OM

The reference model –

Structure of one EHR

All

versioned

Structure of one Composition

ENTRYs –

where the

Context Model in openEHR

data values

temporal structure

clinical statement

healthcare event

spatial structure

EHR

ENTRIES

organise by: SECTIONS

organise by: FOLDERs

COMPOSITION

commit to EHR

(Contribution)

recorded in (1:1)

recorded in (1:N)

data-entry session

Time in openEHR

Real-world

activities

observation

sample/

collection time

measurement/

reporting time

healthcare event

data entry

OBSERVATION.

COMPOSITION.

VERSION.

openEHR

record

COMPOSITION.

commit

time-lag recorded in

OBSERVATION.data

archetyped attribute in

if relevant

context.start_time

data.origin

context.end_time

generally

= instant event

Time in openEHR

radiologist - assess images

data entry

commit

imaging

report

radiology

OBSERVATION.

data.origin

COMPOSITION.

context.start_time

COMPOSITION.

context.end_time

VERSION.

audit.time

openEHR

record

Time in openEHR

commit

vital

nurse obs.

OBSERVATION.

data.origin

VERSION.

audit.time

(hospital)

signs

commit

vital

OBSERVATION.

data.origin

VERSION.

audit.time

signs

commit

vital

OBSERVATION.

data.origin

VERSION.

audit.time

signs

0100

0500

0900

ADMIN_ENTRY

move to ward

time = ...

ADMIN_ENTRY

discharge

time = ...

openEHR

record

Security Features

Entry types

Data Structures

Data Types

Demographic

EHR

Security

EHR Extract

virtual EHR

Archetype OM

Support

(identifiers, terminology access)

AM

RM

SM

EHR

service

archetype

service

demographic

service

terminology

service

{

core

Common

{

patterns

{

domain

{

Integration

}

Composition

openEHR Archetype Profile

Template OM

Entry types based on process

This process is cyclic & repetitive

Clinicians don’t always document every step

investigator

Investigator

agents

History of Solutions

GeHR Australia – early version of Entry types

based on information categories in

History of Solutions – Act-based

Includes



RICHE



HL7v3 RIM



Many others

Problems



Everything is an act – good for tracking business

process steps, but not natural to physicians

Our approach – ‘Clinical Investigator’

Based on

clinical

process

MedInfo 2007

paper

f()

observations

evaluation

interventions

clinical investigator system

patient

system

observations

evaluation

clinical investigator system

interventions

goals

a) problem-solving metaphor

-+

administrative context

goals

observations)

(desired

patient

system

observations)

(desired



Entry types based on process

This process is cyclic & repetitive

Clinicians don’t always document every step

investigator

Investigator

agents

Leading to an Ontology

observation/

intervention

recorded

information

history

opinion

assessment

care

information

admin

information

proposal

diagnosis

risk

goal

recommendation

intervention

scenario

prognosis

instruction

xxx

xxx

= observation-related

= intervention-related

observation

action

cognitive/temporal

categories

categories

analytical

categories

investigation

request

request

OBSERVATION

ACTION

EVALUATION

INSTRUCTION

ADMIN_ENTRY

(with a speculative part for Admin)

admin

information

admission

scheduling

reservation

appointment

completion

transfer

discharge

referral

commence

task event

patient event

ment

emergency

birth

death

Specification Map

Data Structures

Data Types

Demographic

EHR

Security

EHR Extract

virtual EHR

Archetype OM

Support

(identifiers, terminology access)

AM

RM

SM

EHR

service

archetype

service

demographic

service

terminology

service

{

core

Common

{

patterns

{

domain

{

Integration

}

Composition

openEHR Archetype Profile

Template OM

RM data types & structures

terminology

support

definitions

measurement

identification

text

data_types

basic

quantity

date_time

_{specification}

time_

uri

multimedia

history

data_structures

item_structure

History – Storing Device Data

Efficiently

14,400 x 1 second

samples from device

5 x Events in

openEHR History

openEHR

EHR Extract

Specification Map

Data Structures

Data Types

Demographic

EHR

Security

EHR Extract

virtual EHR

Archetype OM

Support

(identifiers, terminology access)

AM

RM

SM

EHR

service

archetype

service

demographic

service

terminology

service

{

core

Common

{

patterns

{

domain

{

Integration

}

Composition

openEHR Archetype Profile

Template OM

Basis of versioning



(similarly to CVS, Subversion etc…)



We use the

Composition

as the unit of

change (like a file in Subversion)



Folder structure also versioned



We use the

Contribution

as the unit of

committal (like a change-set)



Pre-commit check ensures that the current

state of Compositions & Folder structure

unchanged since check-out

Contrib

12/4/2003

Contrib

15/4/2003

Contrib

20/4/2003

Contrib

22/4/2003

Versioning

Family

History

Current

medications

Problem

List

Care

Plan

Contact

12/4/2003

Test Results

15/4/2003

Contact

20/4/2003

Problem

List ++

Current

Meds ΔΔ

Care

Plan

Δ

Correction

22/4/2003

User A

System

User B

Conflicts & Merging – One System

v1

commit

v2

v1b

v1a

commit?

v2a

v3

commit

Sys B

Synchronisation Problems

Sys A

v1

v2

v3

Sys C

v1

v1

v1

Do we have

the latest?

Are we getting

Duplicates?

Solutions:

• designated master

repository from which

to update

• reliable, global

version identification

scheme

Distributed conflicts

Sys A

v1

v2a

Sys C

v1

This can only happen:

1. where no master designated

2. no update-before-commit

3. patient presents in both

places

i.e. ad hoc situation, e.g. patient

sick while on holiday

Solution:

One of the systems will be the

Patient’s ‘home’ system

Why is the openEHR RM useful?

Because it was developed with clinical input



OGTT example

It provides a solid ontological basis for the next

levels:



Archetypes



Templates