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.