1. Virtual Medical Record Aziz Boxwala, MD, PhD March 12, 2013

2. 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

3. VMR Snippet

4. QDM Snippet

5. 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

6. 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

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

8. 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

9. 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