View
270
Download
1
Category
Preview:
Citation preview
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
Recommended