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. Motivation and Important Model Features
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
SCT 14May

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
SCT 14May

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"/> <id root="" extension=""/> <observationFocus code="" codeSystem="" displayName="Systolic BP"/> <observationValue> <physicalQuantity value="120" unit="mmHg"/> </observationValue> </observationResult> </relatedClinicalStatement> <observationFocus code="" codeSystem="" displayName="Diastolic BP"/> <physicalQuantity value="80" unit="mmHg"/>

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
SCT 14May

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

15. Clinical Statement Central to vMR

16. Example Clinical Statement
SCT 14May

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"/>
<observationFocus code="" codeSystem="" displayName="Systolic BP"/>
<observationValue>
<physicalQuantity value="120" unit="mmHg"/>
</observationValue>
</observationResult>
</relatedClinicalStatement>

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 ProcedureProposal ProcedureOrder
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
SCT 14May

26. Problem Model – CCD vs. VMR
SCT 14May

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:
SCT 14May