Weakness of HL7V3.0

Administrative Overhead: The version 2.x has very simple administrative process than Version 3. Modifications to 2.x standard are done easily by editing the change into the appropriate word processing document. In Version 3 changes need to be done to the computerized models, and the downstream consequences in the message structures need to be taken care of. This disparity comes into focus especially when introducing small changes into existing interfaces.

Message Size: The usage of XML as ITS and the adoption of ebXML as the wrapping mechanism for HL7V3.0 messages increased the message size hugely compared to a HL7V2.X message. The two layered wrappers consisting of ebXML wrapper and HL7 wrapper with duplicate elements contributed to the size.

Technological Barriers: HL7V3.0 has been built on RIM a decision which has been made in 1996. Technological changes and new architectural patters e.g. SOA make RIM which uses for e.g. UML look like a legacy hangover. The level of extensibility of RIM with well-designed ontologies for functions like computerized decision support which came with advances in clinical research is unknown and undefined.

Learning Curve: There is a very steep learning curve in understanding HL7V3.0 and there are no standard implementation and deployment guides available for starters. They need to traverse through the documentation available on HL7V3.0 site and the structure of documentation adds further complexity to the understanding of Version 3.0.

Inadequate RIM: The HL7 RIM contains an ad hoc mixture of health-specific concepts and domain-independent concepts. There are no classes to represent key clinical concepts such as 'diagnosis', 'problem' etc .HL7 proponents would argue that it is indeed possible to represent 'problems', 'diagnoses', etc. using RIM components. This may well be the case, by using suitable values of codes etc, but the general view of this is that HL7 RIM is far too abstract to provide a useful basis for the specification of health event summaries,

Multiple Tools: Multiple tools are used to design and build HL7V3.0 message specifications. For example the RIM is defined using UML, D-MIM and R-MIM using Visio, HMD using Rose Tree and the messages are in XML. The story boards are in formal English language and the application roles, triggers and interactions are in a PubDB. The usage of different tools in designing and publishing message specifications is expensive.

Weakness of HL7V2.x

Inter-Intra Enterprise - HL7 V2.x limitations came to the fore with the advent of Electronic Health Record (EHR) which involves exchange of data across organizations. The need for inter-enterprise data exchange exposed the ambiguous data semantics of HL7V2.x which is due to the fact that version 2 messages are based on no explicit model .For example relationship of OBX to OBR and ORC to PID is implied but not specified. Fields within a message originate from different implicit data models and lead to inconsistent interpretation of these fields.

Semantic Framework - The presence of semantics framework is crucial in understanding the definition of each element of data in the message and the relationship with other data elements. It is also crucial for representing coded elements and relationships within the terminology. So the absence of a semantics framework in HL7V 2.x messages makes it mandatory that the applications involved in the exchange of data needs to be programmed to interpret the different values that come in a field from other applications. This need for interpretation of messages by applications using programming increased the costs and effort for deployment of HL7V2.x messages.

Backward Compatibility - The mandatory requirement of maintaining backward compatibility between different versions of HL72.x is an overhead and constrains HL7V2.x from adopting new terminology and communication standards. This constraint led to version HL7V2.x being termed more of a data exchange standard rather than interoperability standard.

Data Relationship - There is a vague definition of relationship between message types, event types, and the structure of a message in HL7V2.x. There are no clearly defined rules describing the association between events and messages. For example in version2.3 a single ORM message is associated with different events such as new order, modify order and cancel order. In some scenarios the event types describes the message structure and the real time events associated with the messages and in other scenarios it describes the location of the target system where the data in the message has to be transmitted.

Methodology - There is no explicit methodology defined for building of HL7 V2.x messages. There is no detailed documentation associated with specifications to give guidance to developers and implementers on constructing HL7V2.x messages. Trigger events and data fields are described in formal language. The same message definitions are used for different trigger events. The different chapters in the documented specifications are not consistent in usage of trigger events and status codes. The specification concentrates solely on the behavior of sending system and does not define the receiving systems behavior nor does it provide guidance when a specific receiving system is expected to honor a trigger event or accept a message. HL7V2.x methodology is based on structured programming language but does not have formal operations and object oriented concepts such as generalization and specialization hierarchies.

Optionality - There is a substantial amount of optionality built in HL7VV2.x messages making it difficult for specifying precise contract terms for HL7 interfaces. Optionality also led to vendors making ambiguous HL7 conformance statements as it is difficult to define the exact semantics of a specific message. The use of optionality increased the costs of development of interfaces for applications which came with out-of-box HL7 interfaces. This led to HL7V2.x being termed as not a plug-and-play standard which usually is required for messaging standards in any industry for e.g. SWIFT standards for banking.

Security – Security has been always considered out-of-scope for HL7V2.x messages. There is no explicit support for security functions such as encryption, restricted access to data and digital signatures.