HL7 V3 dubbed "The Foundation of Healthcare Interoperability"

Health Level Seven’s Version 3 Normative Edition 2005 standards have been made available in the Members' Area of www.HL7.org. They are dubbed "The Foundation of Healthcare Interoperability". The HL7 RIM, in particular, is asserted to be a critical component of the V3 development process.

"The rules require that all information structures in derived models be traceable back to the RIM and that their semantic and related business rules not conflict with those specified in the RIM. The RIM therefore is the ultimate source for all information content in HL7 V3 standards." It is the "root of all information models and structures developed as part of the V3 development process", including those information models and structures in areas such as Clinical Genomics.

On the other hand the RIM contains definitions such as the following:

Living Subject: A subtype of Entity representing an organism or complex animal, alive or not.

Animal: A subtype of Living Subject representing any animal-of-interest to the Personnel Management domain.

Person: A subtype of Living Subject representing single human being [sic] who, in the context of the Personnel Management domain, must also be uniquely identifiable through one or more legal documents (e.g. Driver’s License, Birth Certificate, etc.).

[It seems that in the latest version of the RIM documentation the last two definitions have been removed; however they survive in the HL7 Glossary.]

This leads immediately to the question whether the biology which is incorporated in the RIM is able to bear the load which has been placed upon it. It may also lead to some scepticism concerning the process of design-by-ballot which led to these and similarly questionable outcomes.

The following piece of nonsense suggests also that the authors of the RIM have problems with understanding what is meant by 'definition':

QueryBySelection: This class contains the definition of a Query by Selection. This is an HL7 query in which a request can specify any or all of the variables offered by a data server and may additionally specify any permissible operators and values for each variable as published in a query conformance statement. This query format is considered an open query because it allows a selection specification against a published data base schema.

Here the definiens is asserted to be 'contained in' the definiendum. (As if one were to formulate a definition of number by writing: 'a number contains the definition of a number'.)

The second sentence contains a dangling anaphora (what does 'this' refer to?) In addition, it identifies the entire class which is to be defined with one of its instances.

The third sentence confuses 'query format' with 'query', and contains the vague expression 'is considered is'. (Compare 'an even number is considered as a number that is divisible by 2'.)

HL7 and Object Oriented Programming

In the HL7 V3 Introduction/Backbone document (Published 12/30/2004) it is claimed that:

"HL7 V3 adopts an Object Oriented (OO) approach using Unified Modeling Language (UML) principles. HL7 employs a completely new development approach with V3. HL7 V3 uses an OO approach that is model and repository-based. This OO approach is supported with trained facilitators, formal education classes, and computerized tools. This approach leads to increased detail, clarity and precision of the specification and finer granularity in the ultimate message. This helps functional committees meet the challenges of de novo interface design, and increases functional breadth and evolution of assumptions. It helps new members become productive in fewer meetings. This is an enormous aid to providing institutional memory and sharing work in progress across committees and to the membership at large. "

We know of only one peer-reviewed publication addressing the degree to which HL7 V3, does in fact correspond to OO modeling principles. This is:

Eduardo Fernandez and Tami Sorgente, "An analysis of modeling flaws in HL7 and JAHIS", Proceedings of the 2005 ACM symposium on Applied Computing, Santa Fe, New Mexico, 2005, pp. 216 - 223

whose authors (F&S) assert:

"Instead of using the Unified Modeling Language (UML), the standard notation for object-oriented software development, these two organizations (HL7 and JAHIS) have developed specialized object-oriented models. This has resulted in languages which are incompatible with the current use of UML. The consequences of this choice are the loss of the possible use of a large variety of existing models and patterns. What is worse, it will be difficult to add security specifications in their models, a critical aspect in the electronic interchange of medical records. We discuss here the shortcomings of HL7 and JAHIS as modeling languages and as languages in which to add security specifications."

"HL7 is complex and designed for implementation, not for conceptual modeling. We show below some of the sources of complexity. Although the designers deny having a software orientation, it is clear that the model contains artifacts normally used in the design stage of software systems. A measure of their complexity is that their documentation is hard to understand."

Specific problems identified by F&S can be summarized as follows:

1. Because of its ad hoc variation of UML, HL7 V3 becomes incompatible with the conceptual models already developed for medical systems.
   
   
2. V3 has an explicit concept of entity, which is not appropriate for a UML conceptual model, where everything is an entity; thus adding an entity class does not add anything to the semantics of the model. The class is present in V3 because 'entity' is there used, idiosyncratically to mean entities of a specific type (people, places, organizations, ...).
   
   
3. V3 treats associations in an idiosyncratic way, giving them no name and no semantic value, and placing their semantics in a separate class. UML associations have semantic value and association classes can be used to add details to links.
   
   
4. In V3 states are hidden as mood codes: UML uses state diagrams to describe the stages in the lifecycle of an object. In HL7 these stages are implicitly encoded using mood codes. This precludes any analysis of state correctness and correlation with sequence (scenario) diagrams.
   
   
5. V3 is cumbersome and inefficient: As a result of its misuse of associations the models are unnecessarily complex. Models that in UML take a few classes and associations require a much larger number of classes in HL7 V3.
   
   
6. V3 uses arbitrary software-dictated names to distinguish the different types of classes in their model and these classes, e.g. by using a prefix letter, as in 'P_patient', to indicate a class of type Participation. In this way the benefits of compositionality are lost. The same effect can be achieved much more naturally in UML by using stereotypes, e.g., of the form '[Participation] Patient', which allow easy extension to new cases, so that one does not need to predefine all the class names one will need from the very start.
   
   
7. Loss of the possibility of using security patterns and models: Given the importance of security when medical records are fully computerized and exchanged through the Internet, this may be V3's most serious flaw.

As F&S point out,

"Some of these deficiencies were already noted by Mead (see C. Mead, "HL7: Challenges, Benefits, and Applications", HL7 UK, December 2003), who said that the following may be true about HL7:

HL7 has assembled a considerable amount of process and number of artifacts without too much concern to UML. [F&S: Exactly, they invented their own notation.]

HL7 is not (in general) interested in software systems. [F&S: While they do use software-oriented aspects in the model, their approach does not follow the rules of software engineering.]

HL7 does not have extensive internal modeling/UML expertise. [F&S: Clearly]"

List of Problem Areas

A more precise specification of areas of focus reads as follows:

• problems of documentation in relation to the factors of intelligibility by the human beings who must create software and refined messages and domain information models on its basis;
  
  
• the steep learning curve: does HL7 V3 have the ability of to be taught and therefore engaged with, and used (evidence so far in this category is that it is highly problematic, and the perceived complexity is a major barrier to engagement and easy use)?
  
  
• problems of implementation: the decision by HL7 to adopt the new RIM-based methodology was adopted already in 1997, and versions of the RIM were available already in 1999; why, after six years of effort, and considerable investment, is it so difficult to name even one successful large-scale implementation of V3?
  
  
• problems of quality of the HL7v3 artifacts and methods in terms of whether they convey intended (or even sensible) meanings and can be used with well-designed ontologies for functions like computerised decision support (and in general for the sorts of sophisticated tasks which will increasingly become necessary with the advance of genomics-based biomedical (informatics) research);
  
  
• external problems concerning the relationship of the HL7 V3 corpus to the outside world; is the very methodology of HL7 V3 appropriate to the world as it is today, with increasing migration towards web-based technology?
  
  
• problems of internal consistency of the HL7 RIM from an ontological point of view: for while the RIM is presented officially as an information model (so that the instances of its classes would be information/data items), its documentation is formulated in such a way that the examples given are in very many cases examples not of information about real objects / processes but of these real objects / processes themselves;
  
  
• software problems, for example concerning the degree to which shortfalls in consistency and clarity of documentation may lead to the further problem of message and software developers creating incompatible / buggy / unworkable solutions; is HL7 V3 able to support the economic production of maintainable, reusable and extendible software?
  
  
• functional problems concerning the fitness of v3 for its claimed purposes (messaging and apparently EHR and decision support at least); here we will attempt a comparison of what v3 actually offers with current requirements in the various functional areas of the health computing platform -- to what degree is V3 appropriate for satisfying well-known requirenments in clinical informatics?
  
  
• technical probems concerning the quality of HL7v3 with respect to accepted practice in information modelling, object-orientation, software engineering and data management. Items in this category talk about whether v3 supports the construction of good quality, re-usable software, integration into modern computing infrastructures and development environments;
  
  
• problems of usability of the V3 domain models (RMIMs etc) by specialists in the corresponding domains, and problems relating to the ability of clinical and other domain specialists to engage directly, given the specific methodology of HL7 V3 for producing new specialized information models for each new domain, models which differ in unanticipatable ways from the RIM which serves as their starting point;
  
  
• problems of appropriateness: to what degree is HL7 V3 specifically appropriate to the US case and to what degree can it be applied in other countries, where issues of third party invoicing play a less central role?
  
  
• terminology problems relating to the ability of HL7 V3 to integrate properly with clinical terminologies such as SNOMED CT;
  
  
• problems with the HL7 business model: is there some conflict of interest involved in the fact that those, such as consultants, who stand to benefit from overly complex standards or unclearly formulated documentation (and from the fact that documentation is not publicly available for peer review by the wider community), are also involved in the balloting process which determines what the standards and documentation should be?
  
  
• problems with HL7 governance processes: decisions on modifications to HL7 standards are based on a balloting procedure involving a number of distinct constituencies, which means that any change must be slow, and this may be problematic in an age of rapid technological change; are those members of the relevant constituencies working with new technologies able to influence the development of HL7 V3 in a timely fashion?
  

Misleading Claims regarding HL7 V3

As an example under the heading "problems with HL7 V3", consider the following claim,

• HL7 V3 is the standard of choice for countries and their initiatives to create national EHR and EHR data exchange standards as it provides a level of semantic interoperability unavailable with previous versions and other standards. Significant V3 national implementations exist in many countries, e.g. in the UK (e.g. the English NHS), the Netherlands, Canada, Mexico, Germany and Croatia. Within the US, jurisdictional agencies needing support for large scale integration (e.g. CDC, FDA) have adopted V3.

from a 'white paper' issued by a group of European messaging experts in November 2005. Again, we believe that the claim that there exist 'significant V3 national implementations' is at best misleading. The NHS is certainly attempting a national implementation of V3 in the United Kingdom, though this is for the purposes of messaging (for which HL7 was of course originally designed) not as a 'national EHR ... standard'. Even in regard to the fulfilment of these purposes, moreover, the NHS is confronting considerable difficulties in implementing V3.

We are sceptical that there are significant 'national implementations' of V3 which would justify the claim that it is the EHR 'standard of choice' in the other countries mentioned. In particular, none of the countries mentioned is using the "functional specifications" for EHR under development within the V3 framework (which may have something to do with the fact that the specifications in question were designed with the rather special case of the USA in mind).

Misleading Claims regarding HL7 and EHR

As an example under the heading "HL7 and EHR", consider the document entitled "HL7 EHR System Functional Model and Standard: Draft Standard for Trial Use" (see also the revised version here). This document does not, in spite of its title, contain a functional model for an EHR system. Rather, it is merely specification of requirements - a profile of what would be needed to create such a functional model.

To call something a "model" is to suggest that it belongs on the solution side of the fence, rather than on the side of problem description, which is where these functional specifications belong. There is nothing in these specifications which provides information about how an EHR system could be built, only information about what it might be required to do, in the specific US-case.

In fact, the main intention of this work was not as requirements for building systems – for this more technical requirements are needed, like ISO 18308. Rather it is intended as a checklist for system procurers to determine whether a given product satisfied some particular functional profile. It was designed as a way of a) comparing systems and b) determining system compliance.

We suspect, however, that the very title of the mentioned document has led to misleading assumptions. Thus the US Department of Health and Human Services (HHS) published a report on national health IT developments in 2004 containing the statement that:

• "With HHS participation, HL7 has also created a functional model and standards for electronic health records."

We would be pleased to see HL7's "standard for electronic health records".

The Australia HealthConnect Clinical Information Project (CIP) considered the RIM in a report which came to the following conclusions [3]:

adopting HL7 RIM as a foundation for representing all HealthConnect EHR concepts will:

• Significantly increase the complexity of concept representation;
  
  
• Entail considerable burden upon HealthConnect staff to map clinical concepts to the RIM;

and

• Likely lead to confusion in communication with HealthConnect stakeholders who are not well versed in HL7 concepts and methodologies.

HealthConnect (Australia). Clinical Information Project Phase 1 Report, PART A Stream 1: Clinical Information Framework. 2004.

Areas of Focus

We shall concentrate especially on two areas:

1. HL7 and the Electronic Health Record

2. HL7 Version 3 and its problems regarding

• intellectual coherence

• ability to support software

Rationale

HL7 (Health Level 7) is a standard for healthcare-specific data exchange between computer applications.

Considerable resources are being invested in the HL7 project by governments and industry as part of national health IT projects with expenditures running into the billions of dollars.

Many claims are made on behalf of HL7 by its advocates. The goal of this blog is to investigate the merits of these claims, and to provide some needed independent perspective on the HL7 project.