Table of Contents
maxLevel 8 minLevel 2

 

The vMR Data Structure

Notes about the Virtual Medical Record (vMR), its structure, and how to use it

Last Updated:  7/15/2013 9:16 AM

Purpose of a virtual Medical Record

A virtual Medical Record (vMR) is a data structure designed specifically and solely for decision support.  It is NOT intended for persistence in anything more than a processing log file, and it is NOT intended to carry complete provenance as a medical document.  It is lightweight and engineered for computability in preference to human readability.  It is sometimes described as a clinical document turned inside out to make the actionable data elements more prominent.

...

On the other hand, the listed structure is flatter and more amenable to analysis by writing rules.  For example, all ClinicalStatements of the same type are in the same list, where a rule can iterate over them to locate data that is of interest.

The Internal vMR Structure in OpenCDS

Datatypes

Internal datatypes began as a clone

...

There is a MappingUtility which performs mapping between internal and external datatypes.  Names of mapping methods are structured as “{DT}2Internal{DT}” or “Internal{DT}2{DT}” where {DT} represents the name of the datatype.

vMR Classes

All VMR classes defined in the external schema are expected to be present in the internal structure except for the following:

...

By the way, there is nothing special about an OpenCDS concept.  It is simply a concept which someone writing a clinical rule determines to be useful for expressing the elements involved in the logic of the rule.  It is created in a terminology system by mapping a list of standard (or proprietary) codes (aka concept descriptors, or CD data) to a single concept descriptor for the OpenCDS concept.  This means that we have a single reference that we can use to write a rule about any of the codes in the source data that match the desired concept.  It separates the writing of the logic of the rule from the maintenance of the data codes that are constantly evolving.  The rules don’t need to change when codes are added or deprecated.  Mappings don’t necessarily need to change to adjust the logic of a rule.

Mapping from External Structure

Interfaces: org.opencds.vmr.v1_0.mappings.in

IPayloadUnmarshaller.java

...

We provide an implementation to support Drools fact lists.  Users interfacing to a different inferencing engine requiring a different internal structure, but still based on the VMR, can replace this module as required.

Mapping to External Structure

Interfaces: org.opencds.vmr.v1_0.mappings.out

IBuildResultSet.java

The implementation of this interface accepts the processed fact lists from the inferencing engine, and produces a structured output in the CDSOutput schema structure.  This structure is then further processed by the implementation of the IMappingOutbound interface.

...

The implementation of this interface accepts the CDSOutput structure produced by the implementation of the IBuildResultSet interface, and produces a base64 string for return as a response by the DSS service. 

Using the vMR in OpenCDS

This is intended to be an overview of the general organization of the vMR, and a big-picture guideline to how you might use it.  First, here is a somewhat organized view of the structure of the VMR, which will be followed by some suggestions on how to use it in OpenCDS, both for input, and for output. 

Abstract Base Classes

There are two groups of data structures in the vMR: Clinical Statements describe “activities” of interest, and Entities are the people, places, and “things” that have a role in those medical activities.  These abstract classes cannot be separately instantiated, but you can refer to them in rules.  For example, you could examine the common elements in a base class to draw broad conclusions about whether a particular activity happened, did NOT happen, was proposed, or was ordered.

...

This contains the common elements for all persons, places, organizations, and other “things.”  It is the basis for both EvaluatedPerson, and for the 7 other groups of entities. 

Instantiatable Classes

The classes listed here are not abstract.  You can instantiate them to send data to OpenCDS, and you can instantiate them in rules to return inferred data from OpenCDS to your application.

...

• AppointmentRequest
• CommunicationOrder
• ObservationOrder
• ProcedureOrder
• SubstanceAdministrationOrder
• SupplyOrder

Populating Data for submission to OpenCDS

Choose your structure

The vMR is very flexible, and there is more than one way to do just about anything.  In general, it is probably a good idea to choose the general structural approach that most closely matches the structure of your data.

...

These “best practices” will be posted in a separate document.

Populating Output Data in Rules for Return from OpenCDS

OpenCDS Output Structure

A portion of the output structure of OpenCDS is pre-defined, but there is still more than one way to create output.  There are two major choices:  1.) single result element; or 2.) CDSOutput result containing vMR structured data.

...

These “best practices” will be posted in a separate document.

Change Tracking

...