vMR: the HL7 virtual Medical Record Standard

1. vMR: the HL7 virtual Medical Record Standard May 16, 2013 Health eDecisions All Hands Call Claude Nanjo David Shields

2. Presentation Goal • Provide a broad general understanding of the vMR • Describe the motivation for such a model • Describe the high-level organizational structure of the vMR • Describe the relationship between the vMR and CCDA documents

3. Why do we need a vMR? Motivation and Important Model Features

4. Background A “holy grail” of clinical informatics is scalable, interoperable CDS Key requirement for interoperable CDS and re-use of CDS knowledge resources = use of a common patient data model Referred to as a “Virtual Medical Record” or vMR (Johnson et al., AMIA Annu Symp Proc, 2001) Lack of a common vMR has been a major barrier to sharing knowledge and scaling CDS

5. Example Challenge without VMR Observation Blood Pressure Code = BP Systolic = 120 mmHg Value = 120/80 mmHg Diastolic = 80 mmHg Observation Vital Sign Code = BP Type = BP Observation Value = 120/80 Code = SBP Units = mmHg Value = 120 mmHg Observation Code = DBP Value = 80 mmHg

6. Blood Pressure in the vMR <observationResult> <templateId root=""/> <id root=""/> <observationFocus code="" codeSystem="" displayName="Blood Pressure"/> <observationEventTime low="" high=""/> <relatedClinicalStatement> <targetRelationshipToSource code="" codeSystem="" displayName="PartOf"/> <observationResult> <id root="" extension=""/> <observationFocus code="" codeSystem="" displayName="Systolic BP"/> <observationValue> <physicalQuantity value="120" unit="mmHg"/> </observationValue> </observationResult> </relatedClinicalStatement> <relatedClinicalStatement> <targetRelationshipToSource code="" codeSystem="" displayName="PartOf"/> <observationResult> <id root="" extension=""/> <observationFocus code="" codeSystem="" displayName="Diastolic BP"/> <observationValue> <physicalQuantity value="80" unit="mmHg"/> </observationValue> </observationResult> </relatedClinicalStatement> </observationResult>

7. Purpose and Design Principles • Designed specifically and solely for CDS • Not intended for persistence or provenance as medical document • Lightweight and engineered for computability (over human readability) • Compromise between clinical detail and broad generalization • 80/20 rule • Favors model stability

8. Features of the vMR – Part I • Core datatypes based on simplified ISO 21090, also known as HL7 datatypes R2 • Loosely based on CCD and the HL7 Clinical Statement • Gave base classes business-friendly names • Promoted negation and mood to explicit classes to reduce possible errors • Resolved confusion around CDA code, effective-time, and status • Removed less useful attributes for CDS

9. Features of the vMR – Part II • Extensible • Attribute/Template extension mechanism • Entity and Clinical Statement Relationships • Also considering class extension mechanism • UML specializations • Schema extensions • Designed to allow flattening of hierarchical structure for easier computation

10. vMR Goal • Provide common information model upon which interoperable clinical decision support resources (e.g., rules) can be developed

11. Project History • Analysis of data required by 20 CDS systems from 4 countries (Kawamoto et al., AMIA 2010) • Refinement of vMR via implementation within OpenCDS • Adopted in September 2011 as Informative Specification • Enhancements balloted in May 2013 to address Health eDecision pilot feedback and to better support order set authoring based on an review of existing CPOE system implementations

12. Structural Organization of the vMR

13. Simplified ISO 21090 Data Types

14. vMR-Specific Core Types Support Expressivity and Model Stability

15. Clinical Statement Central to vMR

16. Example Clinical Statement

17. Progressive Specialization

18. Core Data Structures in vMR • Entities • People, places, and things • Clinical Statement • Clinical activities • Root of vMR is the Patient • (an EvaluatedPerson) • A Patient may have other associated EvaluatedPersons (e.g., family history) • An EvaluatedPerson has associated Clinical Statements

19. Relationships in the vMR • Related Entity • Example: MMR Vaccine • Relationship of following is “PartOf” above • Measles Vaccine • Mumps Vaccine • Rubella Vaccine • XML Example: <substanceAdministrationEvent> <substance> <substanceCode code="" codeSystem="" displayName="MMR Vaccine"/> <relatedEntity> <targetRole code="" codeSystem="" displayName="PartOf"/> <administrableSubstance> <substanceCode code="" codeSystem="" displayName="Measles Vaccine"/> </administrableSubstance> </relatedEntity> </substance> </substanceAdministrationEvent>

20. Relationships in the vMR (cont.) • Related Clinical Statement • Example: Blood Pressure Observation • Relationship of following is “PartOf” above • Systolic Blood Pressure • Diastolic Blood Pressure • XML Example: <observationResult> <observationFocus code="" codeSystem="" displayName="Blood Pressure"/> <relatedClinicalStatement> <targetRelationshipToSource code="" codeSystem="" displayName="PartOf"/> <observationResult> <observationFocus code="" codeSystem="" displayName="Systolic BP"/> <observationValue> <physicalQuantity value="120" unit="mmHg"/> </observationValue> </observationResult> </relatedClinicalStatement> </observationResult>

21. Relationships in the vMR (cont.) • Entity Relationship To Clinical Statement • Example: Lab Diagnostic Procedure • Relationship of following is “SubjectOf” above • Sputum Sample • Blood Sample • XML Example: <procedureEvent> <procedureCode code="" codeSystem="" displayName="Culture and Sensitivity"/> <relatedEntity> <targetRole code="" codeSystem="" displayName=“SubjectOf"/> <specimen> <id extension="" root=""/> <entityType code=“” codeSystem=“” /> <description value="arterial blood" /> </specimen> </relatedEntity> </procedureEvent>

22. Groups of Clinical Activities • AdverseEvent • Encounter • Goal • Observation • Problem • Procedure • SubstanceAdministration • Supply • Communication (TBD)

23. Handling ‘Mood’ • UndeliveredProcedure • Never performed • ProcedureProposal • Proposed but not yet ordered • ProcedureOrder • Ordered • ScheduledProcedure • Scheduled but not yet delivered • ProcedureEvent • Delivered and recorded

24. Handling NegationInd as Classes • AdverseEvent/DeniedAdverseEvent • Problem/DeniedProblem • ObservationResult/UnconductedObservation • SupplyEvent/UndeliveredSupply • Etc…

25. Why Not Just Use the CCDA as the vMR? CCDA does not include all needed information E.g., Family history model suitable for CDS CCDA is not sufficiently intuitive for direct use by CDS knowledge authors CCDA is deeply nested and verbose, which adds performance penalties in volume production HOWEVER: CCDA can be mapped into the vMR, which has a simpler structure that is more conducive to evaluation The vMR and CCDA are complimentary and intended for different purposes

26. Problem Model – CCD vs. VMR

27. From CCDA to vMR • CCDA can be transformed into a vMR but not vice-versa (vMR is a ‘subset’ of CCDA) • CDS Services should operate on one model. The vMR was designed for this purpose. • Transformation path from CCDA to vMR should be documented (or transform should be provided) • Separate CCDA-to-vMR service with service composition?

28. Further Information vMR: http://wiki.hl7.org/index.php?title=Virtual_Medical_Record_(vMR)