90 likes | 229 Views
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
E N D
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
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 HeDschema • 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