Classes in the vMR Model
There have been several attempts at defining what high level classes should be in a vMR and the aim is to extract the essential patient history that is important for clinical decision support without including every possible attribute. Ideally a vMR should be extendable for local use, but have a core set of properties common to most use cases. Here is a collation of conceptual ideas drawn from past vMR projects and current implementation experience from one member of the project.
An important aspect of a vMR is that there might be several "Contexts" in which it is used. The model can vary between contexts. For example GELLO has a default context of a single patient, much like Arden. However GELLO could be used to extract data over a population of patients or during report creation. These are some contexts:
Contexts
- Patient
- Population
- Report or Template
The GELLO standard refers to a RMIM view of the HL7 V3 RIM and this works well as it allows access to Act Subclasses as a collection of related records, which in the default context, belong to a single patient. In this default context these are candidate classes which could be visible at the top level.
- Observation
- Family History
- Patient
- Procedures
- Allergies
- Problem List
- Orders
- Appointments
- Substance Administration
- Immunizations
- Pregnancy History
Many of these are collections of classes that are modelled on the RIM, but simplified as much as possible. In some cases the subject has been modelled in more than one place eg Family History and ideally the most complete model should be used as long as any user can detect that some data is not available. There is inconsistancy in modelling some classes, eg Observation and the aim of a vMR should be to unite these differences into a common representation for the purposes of decision support.
An important requirement is the ability to reference Templated data, as it is unlikely that all clinical data will be modelled using RMIMs. A Gello class representation of the template, which would also have a UML representation is probably the best form of modelling as it allows local extension. There are several potential template formats that need to be mapped to vMR classes, ideally in a dynamic way.
