Virtual Medical Records, HL7 Models and Simplification

As I've previously reported, there are a number of different activities in HL7 regarding simplification.  One of these activities is around the development of a model for the virtual medical record (VMR) to use in the Domain Analisys Model.  The VMR concept has been around for more than a decade, but has yet to really be standardized.

The HL7 Clinical Decision Support workgroup is currently exploring the US Federal Health Information Model.

I have (as usual), a somewhat different view of what the VMR should be.  The VMR to me is to the medical record as the Document Object Model is to XML and HTML.  It is described by a UML model with a set of classes, interfaces and the relationships between them, and then has bindings to various programming languages and formats (Java, JavaScript, PERL, C++, PHP, XML, et cetera). 

All HL7 Version 3 models derive from the HL7 V3 Reference Information Model, Data types and vocabulary.  I don't see this changing in the VMR, but I do forsee changes to how we would develop a model for it.  As I've been exploring this area, I see some things missing from the current HL7 methodology.  The first of these is interfaces.  Interfaces represent an excellent way to capture common design capabilities.  There are two examples of "interfaces" that should be used in the VMR.  The first of these is the "Annotatable" interface.  A class that implements this interface supports the ability to add annotations to an information item (a class in the model) that has an author, data enterer, date of authorship, and free text.  This interface represents a way to access annotations described in the A_Annotation (Universal) COCT_RM590000UV CMET that is used in several places in HL7 Version 3. 

Here's a bit of pseudo-code defining Annotation and the Annotatable interface.

class Annotation extends Act {
    String readwrite Text;
    List readonly Authors;
    List readonly DataEnterer;
    Act readonly Subject;
}

interface Annotatable  {
    List readonly Annotations;
}

The Annotatable interface can be implemented by any Act.  It provides access to the list of annotations on that act.  Each annotation provides access to the text, authors, data enterer, and the act that is the subject of the annotation.

The Severity interface is similar, except that it provides access to a single Severity class that represents the severity of a concern, allergy, or reaction.

I'm using about ten sources for modeling content.  The most important is probably the clinical statement pattern.  Other important sources are the standards and draft standards in the Care Record domain, and domain specific content in the Clinical Genomics pedigree topic, Orders and Observations, Pharmacy and Medications, and Immunization.  Another important modelling sources is of course the HL7 Continutity of Care Document.  This latter document helps to define the major categories of information that I would expect to appear in the Patient class.  I think the US Federal Healthcare Information Model will help identify some of the neccessary relationships, but it's just at much to detailed a level.

Below is a list of just some of the classes that I've found thus far (and my work is nowhere near complete):

Class	RIM Class Type	Specialization
Allergy Intollerance Concern	Act	CONC
Allergy Intollerance List	Act	LIST
Annotation	Act	OBS
AssessmentComponent	Act	OBS
AssessmentScore	Act	OBS
Author	Participation	AUT
CarePlan	Act	PCPR
Causes	Participation	CAGNT
Consumable	Participation	CSM
Custodian	Participation	CST
Document	Act	DOC
Fullfills	ActRelationship	FLFS
Goal	Act	OBS
Guideline	Act	PCPR
Healthcare Facility	Role	SDLOC
Informant	Participation	INF
Legal Authenticator	Participation	LA
Medication	Role	ADMM
Organization	Entity	ORG
Patient	Role	PAT
Place	Entity	PLC
Precondition	ActRelationship	PRCN
Procedure	Act	PROC
Reaction	Act	OBS
Reason	ActRelationship	RSON
Record Target	Participation	RCT
ReferenceRange	ActRelationship	REFV
Related Party	Role	ROL
Substance Administration	Act	SBADM

Some of these will wind up being split (e.g., Substance Administration will eventually show up as Immunization and Medication) in the model), others will be renamed (e.g., Record Target to MedicalRecord or some such).

Once I get the list to a point where I think it is complete, I'll begin developing a set of UML diagrams.  There'll be some interesting effects as I go through this work.  The use of packages and interfaces is not something that's not often been done in the HL7 Version 3 models.  Using the W3C DOM as a model has gotten me thinking about what I know (UML modeling) and the V3 RIM, and applying it.  I've gone from someone who has an outsider's view of HL7 to having a detailed insider's view, and gotten lost in the woods in the process (as I suspect many of us in HL7 have).  Using another standard that I know well like the DOM has given me a new map to work with.

There are quite a number of techniques that the DOM uses in its models that could vastly simplify HL7 Version 3.  The idea that there could be a standard way to interact with the medical record that is consistent across not just serialization, but also dealing with dynamic behaviors is getting to be pretty interesting.  I'm already imagining that there will be a base class that supports XML and Text representations, and other features that support declarations of conformance (templates) and validations, and ...

Packaging will make it easier to separate and scope these different concerns (e.g., conformance and validation).  Having identified the appropriate package for a class or interface will enable use to determine whether different parts of the VMR are in or out of scope for a particular project.