Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

2 7 open_ehr rm reference model overview

59 views

Published on

This presentation provides an overview of the openEHR reference model.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

2 7 open_ehr rm reference model overview

  1. 1. Ian McNicoll Introduction to openEHR Reference Model (RM)
  2. 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. 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. 4. Classes ‘Classes’ are definitions of data structures the ‘assembly instructions’ or ‘recipe’ Classes have attributes (properties)
  5. 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. 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. 7. Facebook class example Mailing Address
  8. 8. Objects Objects carry the data specified by the classes Classes are ‘the recipe’ Objects are ‘the cake’
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 21. Clinical Investigator Cycle
  22. 22. Observations: the result of a clinical examination / test
  23. 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. 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. 25. Instruction: an order or request
  26. 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. 27. Action : clinical procedure or workflow step
  28. 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. 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. 30. Quantity datatypes: amounts, ranges
  31. 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. 32. Text/ CodedText datatypes : for Text or coded items
  33. 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. 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. 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. 36. Contributions / versioning
  37. 37. COMPOSITION ‘category’
  38. 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. 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. 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. 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. 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. 43. Links example
  44. 44. Other stuff Demographics Extract model Audit Attestation

×