Null Values in HL7V2.x

In HL7V2.x the null value is indicated by ¦""¦. When a system receives this it interprets that the particular attributes value has been changed to null as the sending system has deleted the value of that particular data element in its database. It also indicates that the data element is available in the sending system’s database but currently not valued. The receiving system on receiving it should change the current value to null for that data element. However the absence of a field (¦¦) from sending system indicates that the value of the absent element may not have changed since the last event and the receiving system should retain the current value. The absence of a field (¦¦) may also indicate that the particular data element is not available in the sending system’s database.

A few tips on interpretation of "null" value and "not available" in HL7V2.x messages for application programmers

1.If the HL7 NULL value is present in message received and if the application processing allows a field to be changed to null for this source, the Interface needs to null existing application data elements.

2. If an optional non-repeating field or entire optional segment is absent in a received message, the Interface must not null the existing application values.

3. The application Interface should not support partial updates of repeating data. If some fields in a set of repeating fields are absent or null, the Application Interface may inappropriately overlay valid data or retain unwanted values. The Application Interface must not “error” the message.

4. The Application Interface must not support partial updates of repeating prioritized segments. If some segments in a set of repeating ordered segments are absent, the Application Interface may inappropriately overlay valid data or retain unwanted values. The Application Interface must not “error” the message.

5. When a message is sent the Application Interface must value all available changed and unchanged data elements in a segment

6.The Application Interface must send all instances of a repeating field.

7. The Application Interface must send all instances of repeating prioritized segments. For segments that repeat but can be uniquely identified and updated as an atomic unit, the Application Interface may send only the segment that has changed.

8.The Application Interface must send a null value for attributes that are present in the application database but have a null value. The option to send the HL7 null value need to be configurable by feed and not by field. The Application Interface must interpret zeros in a date field as null and zeros in an Application coded value field as null; however, the Application Interface must interpret zeros in a numeric field as a valid value.

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.

Strengths of HL7V3.0

Optionality -HL7 version 3.0 has very little optionality which is one of the weaknesses of version 2.x. The RIM which is the basis for version 3 has no concept of optionality. The need for a value in the message is defined by trigger event rather than the data definition. This has led to better message definitions. Optionality in version 3 is replaced by “Conditionality” which means that the presence of a data field in the message may be allowed or not depending on the value of another field..

Model based - Version 3.0 is based on an object oriented model; Reference Information Model (RIM) to create message specifications. The model provides an explicit representation of the semantic and terminology relationships that is present in the information present in the fields of HL7 messages.

Conformance - HL7’s version 3.0 is primarily intended to be a stable and definite standard which will allow vendors to conform to a universal standard. This will allow regulatory agencies and local HL7 bodies where applicable test the applications to an agreed standard and provide a conformance certificate to the vendor.

Technology independent - Version 3 introduced the concept of “Implementable Technology Specification (ITS)” which describes the process of instantiating a message from its definition. Currently XML is the widely used and probably only one ITS available publicly. But unlike V2.x; HL7V3.0 ITS allows other technologies to be used for messages e.g. UML ITS, JavaBeans etc.

Electronic Health Record - HL7 version 3 offers a much more efficient method to communicate information between clinical systems by providing the context of information in the messages which is not possible in version 2.x. It also provides the ability to collect clinically coded information for the purpose of maintaining Electronic Health Record for sharing clinical data consistently across organizations. Version 3 is emerging as the standard of choice for creating national EHR’s due to the level of semantic interoperability provided by it.

Localization and Refinement: HL7 Inc allows a balloted HL7V3.0 specification to be further constrained for region specific profile aided by a HL7 Inc Affiliate. This localization of messages allows quick deployment of HL7V3.0 for an organization or region to meet their specific needs.

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.

Strengths of HL7V2.x

Strengths of HL7V2.x

Mature Standard – HL7V2.x emerged as a mature stable standard in healthcare informatics after the specifications went through series of review iterations and modifications to cater to the needs of market. The HL7V2.x specifications are currently available and ready for use and easily implementable. A large number of existing applications are HL7V2.x conformant.

International Standard – HL7 has international affiliates in around 28 countries covering all major countries. It has emerged as the dominant clinical information standard in these markets. Majority of the HL7V2.x specifications including HL7V2.3/2.4 have been classified as ANSI accredited standards. HL7V2.4 is now being proposed as ISO standard. Apart from this some countries such as Germany have legislations that stipulate use of HL7V2.x.

Backward Compatibility - The biggest advantage of HL7V2.x is the ability of different versions of HL7V2.x to interoperate with one another. The rules for compatibility between different versions (e.g. V2.3.1, V2.4 and V2.5) have been documented in the specifications. These rules describe the transmission and receipt of messages and converting their contents to data values with full backward compatibility between all HL7V2.x versions.

Optionality - The use of optionality in HL7V2.x messages is helpful in gaining consensus and documenting compact specification. If a data field is declared optional within a segment then the segment can be re-used in different messages without defining a new segment which requires similar data fields. However there is a wide misuse of this optimality which will be discussed in next section.

Message Size: The chief virtue of HL7V2.x message specification is that its syntax is quite compact and hence the size of the message is minimal. This brings a huge benefit to the economy of bandwidth