Virtual Medical Record

Aziz Boxwala, MD, PhD

March 12, 2013

Virtual Medical Record An HL7 specification for a patient data model for use in

clinical decision-support UML class model - informative XML schema

“Influenced” by HL7 RIM Formal HL7 v3 model has not been created

Adoption Used in OpenCDS project as part of a decision-support service Other groups using it internationally

History Release 1 – balloted in 2010 Release 2 – to be balloted in May 2013

New classes and data types and minor changes to existing classes and types To support HeD

VMR Snippet

QDM Snippet

Use of VMR in Health eDecisions The HeD implementation guide requires the use

of VMR for specifying clinical data and actions in a CDS artifact (HeD use case 1) VMR is used by reference as a data model

Means, it is not built into the HeD specification. Rather, it is a requirement in the implementation guide

Allows changes to the model without changes to the HeD schema

VMR used as a model of patient data Used to write data mapping expressions Used in logical criteria

VMR used as a model of “interventions” Used to construct the CDS output/actions

Key differences from QDM VMR has a more formal model

Hierarchy Datatypes of attributes Cardinality/optionality

QDM includes an expression language VMR supports prospective proposals? QDM has more classes/concepts VMR has more detailed attributes

Perhaps, more pertinent to CDS than to CQM E.g., dose, route and frequency of medications

Difference is less since QDM Dec 12 version VMR is extensible

VMR 1.0 Pros VMR is balanced in expressivity and generality

Impacts maintainability and usability of the model VMR is computable

Due to the more formal model Retrospective data (events, orders) and

prospective actions (proposals) Relatively intuitive

E.g., Naming, attributes XML serialization format is lightweight

VMR 1.0 Cons Model semantics

Hierarchy extends by the Clinical Intervention type A substance administration event has the same ancestor as a substance

administration proposal Substance administration proposal and procedure proposal are in different

hierarchies Some attributes need more precise semantics

Not sufficiently detailed Extensibility requires use of “RelatedClinicalStatement” and

“RelatedEntity” Makes artifacts much more complex Requires specification of constraints on the model using templates E.g., Diagnostic Radiological Exam with contrast and view specified as a

Procedure Proposal E.g., Complex IV Medication (in order set)

ISO data types are opaque and complex Scope of the model

More details on clinical context

Proposed path forward Complete requirements definition for CDS and CQM Revise model semantics

Use of composition E.g., Combine “Event” with

“SubstanceAdministrationStatement” Similar to stage in QDM

Base statements on an existing model

Extend coverage of model Coverage should be 90/10 for CDS and Quality

Measurement Requires further analysis for extensibility mechanism for

the 10% Separate out expression language Consider ballot at HL7 in a future cycle