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]"