This presentation provides an overview of the openEHR reference model.

1. Ian McNicoll
Introduction to openEHR
Reference Model (RM)

2. openEHR RM for ‘mortals’
The clinical modelling tools hide
most of the Reference Model
and detailed understanding is
not required for clinicians or 3rd
party developers
Some aspects of the RM are
worth knowing as it carries a
few key pieces of information
that do not need to be modelled
in archetypes i.e we get those
‘for free’

3. Technical modelling basics
A few basic ideas from the world
of technical modelling will help
BUT .. the whole point of openEHR
and archetypes is to hide most of
this complexity

4. Classes
‘Classes’ are definitions of
data structures
the ‘assembly instructions’ or
‘recipe’
Classes have attributes
(properties)

5. Datatypes
Datatypes describe the basic type
of information being carried
a piece of text
a quantity
a date or time duration
an image
etc, etc

6. Inheritance
Classes can based on other
‘parent’ classes
called inheritance or ‘sub-
classing’
the sub-classes ‘inherit’ all the
properties or attributes of the
parent
Dog is a sub-class of Animal
‘Labrador' is a sub-class of ‘Dog’
If ‘Dog’ has an attribute of ‘tail’, The
Labrador class will also have ‘Tail’

7. Facebook class example
Mailing Address

8. Objects
Objects carry the data
specified by the classes
Classes are ‘the recipe’
Objects are ‘the cake’

9. What does the RM cover?
Set of classes defining the generic
structure of a patient health record
Medico-legal context + audit details
Health data versioning specification
Handling archetypes data via paths
‘LOCATABLE class
Datatype definitions

10. Archetypes and the RM
Archetypes are built on top of the RM
classes and ‘inherit’ their attributes
e.g. An Observation archetype such as
Blood pressure inherits the attributes of
the RM OBSERVATION class
Archetypes use the RM datatypes
Most of these properties are technical
but some are important to clinical
modellers

11. Clinical records overview
Pablo Pazos: Design and Implementation of clinical database using openEHR
http://www.slideshare.net/pablitox/design-and-implementation-of-clinical-databases-using-openehr?related=3

12. Outline of a health record
The openEHR health record is a
tree-like structure
The root for a single patient is
the EHR
All of the patient data is
contained in COMPOSITIONS
At the end of each branch of
the tree is a leaf node - the
actual datapoint, the ELEMENT
which carries the value
http://www.slideshare.net/pablitox/design-and-implementation-of-
clinical-databases-using-openehr?related=3

13. Archetypes are based on RM ‘classes’
EHR
Folders
Compositions
Sections
Entries
Clusters
Elements
Electronic health record for one person
High level organisation of the EHR,
e.g. by episode or by specialty
Set of entries comprising a clinical care
session or document, e.g. encounter, result
Clinical headings reflecting workflow or
consultation process
Clinical statements about observations,
evaluations, instructions, actions
Entry subcomponents, e.g. device details or
inspired oxygen information
Leaf nodes of name-value pair and
datatype, e.g. body weight = 60kg (Quantity)

14. Key openEHR Classes
EHR
FOLDER (optional)
COMPOSITION
SECTION (optional)
ENTRY
ELEMENT
ELEMENT
ENTRY
ELEMENT
ELEMENT
ENTRY
ELEMENT
ELEMENT
ELEMENT
ELEMENT
CLUSTER
ELEMENT
SECTION (optional)

15. openEHR data objects
EHR
COMPOSITION = ‘Nursing Observations
SECTION Vital signs
ENTRY Blood P.
Systolic
Diastolic
ENTRY Pulse
Rate
Rhythm
General appearance
Skin colour
Behaviour
Skin turgor
Capillary
Return
Hydration
SECTION = ‘Other obs’
ehr_id = 5c8a8636-bc98-4441-abd5-e9cf396e8833
134 mmHg
86 mmHg
134 mmHg
Irregular
Jaundiced
Normal
Reduced
30s

16. EHR
Top-level container for all of the
data for a single patient
Each EHR has a unique,
anonymous ID the ehr_id
This needs to be associated with a
real-world identifier e.g NHS
Number to allow the patient to be
identified

17. Composition - the document container
Root ‘document’ for clinical data
Carries most key medico-legal metadata
composer (clinical_author), start_time, end_time
organisation, clinical setting
All recorded patient data saved inside a Composition
Carries unique ID
UID::serverID::Version_Suffix
5c8a8636-bc98-4441-abd5-e9cf396e8833::ripple_osi.ehrscape.c4h::1
Versioned
All changes will create a new version

18. RM attributes for Compositions
Composer
The clinical author identifier
Participations
Other individuals involved
Attestations
Sign-off by a senior clinician
Committer, commit_time
Person and Datetime that the record was ‘saved’
Start_time, End_time
Start and end times of the clinical encounter
Health_care_facility, Location
Polyclinic identifier and specific location e.g. “Clinic Room 3”

19. SECTION
Used to divide complex
compositions into
manageable pieces
Just for human navigation
and organisation
Can be nested
No important clinical RM
attributes

20. ENTRY classes
A set of ENTRY sub-classes
carry all of the clinical
payload
These are organised to fit
the ‘Clinical investigator’
cycle
OBSERVATION
EVALUATION
INSTRUCTION
ACTION
ADMIN ENTRY

21. Clinical Investigator Cycle

22. Observations: the result of a clinical
examination / test

23. RM attributes for Observations
Provider (optional ‘provider of information’, where this
differs from the Composer)
Subject (optional where record is not about the patient)
Participations (Other people involved)
Origin
The start dateTime of the Observation
The duration of the observation
Event-Time
The start date_Time of an individual event
Useful when there are multiple samples for one test
e.g pulse / BP monitoring.

24. Evaluations: “what is going on”
Evaluations are the key
clinical decision part of the
record
What do we think is going on?
‘Problem’, ‘Recommendation’,
Goal, ‘Allergy’
No special RM attributes
other than provider,
participations, subject

25. Instruction: an order or request

26. RM attributes for Instructions
Provider (optional ‘provider of information’, where this
differs from the Composer)
Subject (optional where record is not about the patient)
Participations (Other people involved)
Activities
allows multiple chained ‘sub-instructions’
Narrative (mandatory safety feature)
needed in data, to ensure a complex instruction can always be
dropped back to simple narrative
Timing
Complex timing schedule for the whole instruction (rarely used)

27. Action : clinical procedure or workflow step

28. RM attributes for Actions
Provider (optional ‘provider of information’, where
this differs from the Composer)
Participations (Other people involved)
e.g. Operating assistant
Time (the date and time that the action was
performed)
e.g. date of a procedure or a prescription
Current_status and careflow_step
the workflow status of the Action
e.g. planned, in-progress, completed, cancelled

29. Datatypes
The modelling tools expose
most aspects of the data
types that are of interest to the
clinical modeller
Some RM attributes of
datatypes are not clear or
only apply to the actual data,
not the models

30. Quantity datatypes: amounts, ranges

31. RM attributes for Quantity datatype
Units
e.g.mmHg, mmol/l, /min
Normal_range
For lab or device normal ranges
e.g. 20-46 mmol/l
Other reference ranges
For age or sex-specific reference ranges
Normal range for children : 18-28 mmol/l
Magnitude_status
To allow numeric to be qualified
E.g <= 5 (Less than or equal to 5)
∼ 7.3 (approximately 7.3)
Normal_status
High, normal, low based on HL7 lab messages
e.g. HHH,HH,H, ,L,LL,LLL

32. Text/ CodedText datatypes : for Text or
coded items

33. RM attributes for Text/CodedText datatype
Any Text datatype can also act as a CodedText datatype
if you have defined an element to be Text, it can still carry
CodedText
Defining_code
The actual code of a CodedText e.g “123478-AS”
The terminology/version of the CodedText e.g. “ICD-10”
Mappings
to external terminologies
e.g. The original code is an internal code “at007::Left” but is
mapped to SNOMED code |123456|left|

34. Other datatypes
Duration : 1 day , 3 minute, including ages
Boolean: True/ False
Proportion: 83%
Ordinal: 3: Moderate
Multimedia: Image, Sound
Identifier: NHSNumber
Parsable Text: XML, JSON
URI : Web-type links

35. Time in openEHR
radiologist - assess images
data entry
commitimaging report
radiology
OBSERVATION.
data.origin
COMPOSITION.
context.start_time
COMPOSITION.
context.end_time
VERSION.
audit.time
openEHR
record

36. Contributions / versioning

37. COMPOSITION ‘category’

38. ‘Event’ category
Each time new data is committed, a completely new
composition instance is created
Lab reports, nursing observations, doctor encounter
5c8a8636-bc98-4441-abd5-e9cf396e8833::ripple_osi.ehrscape.c4h::1
77a-bc98b345-4421-ba6d5-fc89f396e8855::ripple_osi.ehrscape.c4h::1
Ehrscape POST /composition

39. ‘Persistent’ Category
Each time new data is committed, the original instance
is overwritten
Problem list, End of Life Summary
77a-bc98b345-4421-ba6d5-fc89f396e8855::ripple_osi.ehrscape.c4h::1
77a-bc98b345-4421-ba6d5-fc89f396e8855::ripple_osi.ehrscape.c4h::2
Ehrscape PUT /composition

40. Episode vs Longitudinal persistence
Longitudinal Persistence
Some persistent summaries should exist and be
updated throughout the patient’s lifetime
End of Life summary, GP problem list
Episodic Persistence
Most outpatient and hospital summaries e.g Allergy
lists, Problem lists need to be re-created at admission,
then maintained for the period of admission.
A new Problem list may need ot be created for each
episode of care

41. but - always use ‘event’ !!!
We recommend always setting category
to ‘event’
Setting category to ‘persistent’ currently
removes the context of the Composition,
making it unsuitable for episodic care
i.e loses capacity to record start_time,
setting, location
will be changed soon in RM specification
Use documentation to tell developers
whether to save the composition as an
event, episodic persistent or longitudinal
persistent composition.

42. Links
Most of the relationships between different Entries
and Elements is defined in archetypes and
templates, generally in the same Composition
Links allow the system developer to connect
different Entries which do not have a ‘pre-cooked’
association, and where the Entries live in different
Compositions

43. Links example

44. Other stuff
Demographics
Extract model
Audit
Attestation