Ian McNicoll

Introduction to openEHR Reference Model (RM)

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’

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

Archetypes and the RMArchetypes 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

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

Outline of a health recordThe 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

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)

Key openEHR ClassesEHR

FOLDER (optional)

COMPOSITION

SECTION (optional)

ENTRYELEMENT

ELEMENT

ENTRYELEMENT

ELEMENT

ENTRYELEMENT

ELEMENT

ELEMENT

ELEMENT

CLUSTER

ELEMENT

SECTION (optional)

openEHR data objectsEHR

COMPOSITION = ‘Nursing Observations

SECTION Vital signs

ENTRY Blood P.Systolic

Diastolic

ENTRY PulseRate

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

EHRTop-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

FOLDERAllow Compositions to be organised into convenient groups for local use

e.g. Group compositions by a single admission or care plan

A Composition can be in multiple folders

Composition - the document containerRoot ‘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

RM attributes for Compositions Subject

The patient identifier

Composer The clinical author identifier

ParticipationsOther individuals involved

AttestationsSign-off by a senior clinician

Committer, commit_timeThe person and Datetime that the record was ‘saved’

Start_time, End_time (The start and end times of the clinical encounter

Health_care_facility, Location The polyclinic identifier and specific location e.g. “Clinic Room 3”

SECTIONUsed to divide complex compositions into manageable pieces

Just for human navigation and organisation

Can be nested

No important clinical RM attributes

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)

Key openEHR ClassesEHR

FOLDER (optional)

COMPOSITION

SECTION (optional)

ENTRYELEMENT

ELEMENT

ENTRYELEMENT

ELEMENT

ENTRYELEMENT

ELEMENT

ELEMENT

ELEMENT

CLUSTER

ELEMENT

SECTION (optional)

ENTRY classesA 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

Clinical Investigator Cycle

Observations: the result of a clinical examination / test

RM attributes for ObservationsProvider (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-TimeThe start date_Time of an individual event

Useful when there are multiple samples for one test

e.g pulse / BP monitoring.

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

Instruction: an order or request

RM attributes for InstructionsProvider (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

TimingComplex timing schedule for the whole instruction (rarely used)

Action : a clinical procedure or workflow step

RM attributes for ActionsProvider (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_stepthe workflow status of the Action

e.g. planned, in-progress, completed, cancelled

Admin entry - for non-clinical data

No special RM attributes other than subject, provider

openEHR RM overview

Compositions Set of entries comprising a clinical care session or document eg test result, letter

EHR The electronic health record for one person

Folders High-level organisation of the EHReg per episode, per clinical speciality

Sections Clinical headings reflecting the workflowand consultation/reasoning process

Clusters Compound entries, test batterieseg blood pressure, full blood count

Elements Element entries: leaf nodes with valueseg reason for encounter, body weight

Data values Date types for instance values egcoded terms, measurements with units

Entries Clinical “statements” about Observations,Evaluations, and Instructions

Key openEHR ClassesEHR

FOLDER (optional)

COMPOSITION

SECTION (optional)

ENTRYELEMENT

ELEMENT

ENTRYELEMENT

ELEMENT

ENTRYELEMENT

ELEMENT

ELEMENT

ELEMENT

CLUSTER

ELEMENT

SECTION (optional)

Elements - the individual data points

‘Leaf nodes’ inside an Entry

Can be ‘multiple occurrence’

Clusters - allows elements to be grouped

‘Branch nodes’ inside an Entry

Groups multiple elements

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

Quantity datatypes: amounts, ranges

RM attributes for Quantity datatypeUnits

e.g.mmHg, mmol/l, /min

Normal_rangeFor lab or device normal ranges

e.g. 20-46 mmol/l

Other reference rangesFor age or sex-specific reference ranges

Normal range for children : 18-28 mmol/l

Magnitude_statusTo allow numeric to be qualified

E.g <= 5 (Less than or equal to 5)

∼ 7.3 (approximately 7.3)

Normal_statusHigh, normal, low based on HL7 lab messages

e.g. HHH,HH,H, ,L,LL,LLL

Text/ CodedText datatypes : for Text or coded items

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_codeThe 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|

Date / time

Can be partial

e.g. Year+Month, Year only

Timezones are supported

Other datatypesDuration : 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

Time in openEHR

radiologist - assess imagesdata entry

commitimaging reportradiology

OBSERVATION.data.origin

COMPOSITION.context.start_time

COMPOSITION.context.end_time

VERSION.audit.time

openEHRrecord

Glucose Tolerance Test

Contributions / versioning

COMPOSITION ‘category’

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

Links example

Other stuff

Demographics

Extract model

Audit

Attestation