Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Friday, August 20, 2010


Today I gave a presentation on VMR to the EHRA and fell completely flat on my face. Either I totally didn’t understand my audience, or as my colleague described to me, just simply started off in the wrong direction. It didn’t help that I had a technology failure with my modeling tool (I’ll blame it on Friday the 13th) and had a complete mess of a model (autoformatting and routing should be banned) an hour before the presentation.

As a result, I put together this simple FAQ to maybe undo the damage, and provide a simple example. I’m going to elaborate on this over the coming weeks.
What is a VMR?

The Virtual Medical Record is an object model according to definition 2 provided on Wikipedia:
A collection of objects or classes through which a program can examine and manipulate some specific parts of its world. In other words, the object-oriented interface to some service or system. Such an interface is said to be the object model of the represented service or system. For example, the Document Object Model (DOM) [1] is a collection of objects that represent a page in a web browser, used by script programs to examine and dynamically change the page. There is a Microsoft Excel object model [2] for controlling Microsoft Excel from another program, and the ASCOM Telescope Driver [3] is an object model for controlling an astronomical telescope.
The reference to the W3C Document Object Model is especially relevant, because it is an object model that many software developers are familiar with, and upon which the current draft work in HL7 is built upon.

The VMR is not a “wire format” for communicating patient healthcare information between disparate systems. It is also not a set of classes or interfaces implemented in any specific programming language. It is instead a computational independent representation of how one can interact with a health information system to access medical information about a single patient. That representation describes how the classes and interfaces behave, and what information and services they provide. The representation of the object model is in UML.

How do I use the VMR?
In order to use the VMR, you need an implementation of it in a platform specific environment. That implementation provides the various classes and interfaces described in the object model, and may provide other capabilities also. The mechanism by which the object model is implemented is not specified by the VMR. What the VMR does specify is how the implementation must behave when information is requested, or services are accessed.
What data sources does the VMR use?
It is up to the specific VMR implementation. As I previously stated, these could be data sources like a healthcare providers electronic medical record, a patients personal health record, or any number of other sources of healthcare information for the person. This information could be stored in CCD or CDA format, could be send to the VMR as HL7 Version 2 messages, DICOM Information Objects, or X12N transactions.
What does the VMR look like?
The VMR looks like a UML model with documentation on the various classes and interfaces, and on their methods and properties.

Figure 1 Core of the VMR
At the very core of the VMR is a class called the Medical Record. The medical record is an collection of clinical statements associated with one person. These clinical statements may come from an EMR, a PHR, a Clinical Data Repository, a specialized HIT application, an immunization registry, et cetera, or it may be a composition of information available from a number of disparate systems.
The collection of clinical statements stored in the VMR can be accessed through VMR methods that filter the list of clinical statements. These methods allow more direct access to conditions, allergies, medications, immunizations, vital signs, lab results, orders, et cetera.

Why person and not patient?
A person acts in a role of patient with a number of different healthcare provider organizations. The VMR is not limited to data from only one healthcare provider. Furthermore, it could also include information that the person entered into their own PHR, and they could have no relationship with any specific healthcare provider.

How would I use the VMR?
The first presumption is that someone has defined a set of rules (called a platform binding) which describe how the classes, interfaces, methods and properties described in the VMR Object Model are translated into the various platform (or programming language) dependent features. The next is that someone has actually implemented the VMR for that platform.
Let’s take an example that many of you are familiar with, an EMR system. To implement a VMR using that EMR system, you would:
  1. Select a programming language, e.g., JavaScript (or more accurately, ECMAScript, but I don’t want to confuse everyone).
  2. Create a set of programmable objects following the rules of the binding for JavaScript.
    1. Create a set of objects that allow a user “read-only” access to information stored in your EMR system.
    2. Create a set of objects that allow a user to create new clinical statements that may or may not be stored in your EMR system (that’s an implementation decision, not one that VMR specifies).
  3. Provide some way for an end user to write JavaScript code which uses those exposed objects. 
So, in a VMR, we could look at four classes (defined abstractly below):

Class Person {
  PN Name; // HL7 V3 Person Name
  TS birthDate; // HL7 V3 Time Stamp
  CD gender; // HL7 V3 Concept Descriptor (Code)
  MedicalRecord  record;

Class MedicalRecord {
  Person owner;
  List statements;
  void add(ClinicalStatement);
  VMRImplementation implementation;

Class Concept {
   BL matches(ClinicalStatement s);

Class ClinicalStatement {
  II id;
  CD code;
  TS effectiveTime;  // A simplification for the example, could be IVL_TS 
  MedicalRecord source;
  Person subject;

Class VMRImplementation {
  ClinicalStatement createAct(CD actCode); // Also a simplification

And then implement a clinical decision support rule about determination of eligibility for a mammogram as follows:

var age = now() – record.owner.dateOfBirth;
if (record.patient.gender.code == “F” &&  age > AGE40YEARS && age < AGE70YEARS)
  record.add(record.implementation .createAct(MAMOGRAMELIGIBLE));

This is a rather simplified example of a rule I’m presently working on to describe this concept. A more elaborate version of the rule checks to see if they’ve have a complete bilateral mastectomy or two complete unilateral mastectomies first, before determining that the patient is eligible, in order to determine whether they still need to worry about mammography. A patient without breasts would not usually need a mammogram (but might need other testing). This example completely ignores the underspecified concept of concept, which I talk about in a separate blog posting.


Post a Comment