vmr: the hl7 virtual medical record standard may 16, 2013 health edecisions all hands call claude...

vMR: the HL7 virtual Medical Record Standard

May 16, 2013Health eDecisions All Hands Call

Claude NanjoDavid Shields

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

2

Why do we need a vMR?

Motivation and Important Model Features

3

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

Example Challenge without VMR

Observation Blood PressureCode = 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

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>

6

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

7

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

8

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

9

vMR Goal

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

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

Structural Organization of the vMR

12

Simplified ISO 21090 Data Types

vMR-Specific Core Types Support Expressivity and Model Stability

14

Clinical Statement Central to vMR

15

Example Clinical Statement

Progressive Specialization

17

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

18

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> 19

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>20

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>

21

Groups of Clinical Activities

• AdverseEvent

• Encounter

• Goal

• Observation

• Problem

• Procedure

• SubstanceAdministration

• Supply

• Communication (TBD)22

Handling ‘Mood’• UndeliveredProcedure

– Never performed

• ProcedureProposal– Proposed but not yet ordered

• ProcedureOrder– Ordered

• ScheduledProcedure– Scheduled but not yet delivered

• ProcedureEvent– Delivered and recorded

23

Handling NegationInd as Classes

• AdverseEvent/DeniedAdverseEvent

• Problem/DeniedProblem

• ObservationResult/UnconductedObservation

• SupplyEvent/UndeliveredSupply

• Etc…

24

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

Problem Model – CCD vs. VMR

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?

27

Further Information

vMR:

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