Downloaded 23 times
Uploaded byfreshEHR Clinical Informatics Ltd.
2 7 open_ehr rm reference model overview
The document provides an introduction to key concepts in the openEHR Reference Model (RM) including: 1) It describes several core RM classes - EHR, Composition, Section, and Entry - that define the structure of a patient health record in openEHR. Compositions contain patient data organized into Sections and Entries. 2) It explains key attributes for different types of Entries defined in the RM like Observations, Evaluations, Instructions, and Actions that support the "clinical investigator cycle". 3) It outlines important datatypes in the RM like Quantity, Text, and CodedText and their relevant attributes for modeling clinical data values and coded items. 4) It describes how archetypes are
More Related Content
Similar to 2 7 open_ehr rm reference model overview
2 7 open_ehr rm reference model overview
- 1. Ian McNicoll Introduction toopenEHR 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 Afew 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 definitionsof data structures the ‘assembly instructions’ or ‘recipe’ Classes have attributes (properties)
- 5. Datatypes Datatypes describe thebasic type of information being carried a piece of text a quantity a date or time duration an image etc, etc
- 6. Inheritance Classes can basedon 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.
- 8. Objects Objects carry thedata specified by the classes Classes are ‘the recipe’ Objects are ‘the cake’
- 9. What does theRM 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 theRM 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 PabloPazos: 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 ahealth 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 basedon 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 forall 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 - thedocument 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 forCompositions 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 dividecomplex compositions into manageable pieces Just for human navigation and organisation Can be nested No important clinical RM attributes
- 20. ENTRY classes A setof 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.
- 22. Observations: the resultof a clinical examination / test
- 23. RM attributes forObservations 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 isgoing 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 orderor request
- 26. RM attributes forInstructions 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 : clinicalprocedure or workflow step
- 28. RM attributes forActions 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 toolsexpose 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.
- 31. RM attributes forQuantity 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 forText/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.
- 37.
- 38. ‘Event’ category Each timenew 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 timenew 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 Longitudinalpersistence 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 - alwaysuse ‘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 therelationships 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.
- 44.