HL7V2.x to HL7V3.0 Translation Issues Details-2

In continuation of my previous post this post lists the other issues associated with HL7 v2.x to HL7v3 translation

Conformance Patterns: The other major issue with the transformation of messages is the behavior of application when a particular information exchange takes place. In HL7V3.0 apart from the trigger events and interactions there exists the notion of application role as senders and receivers. The application role is characterized as the entire set of interactions for which the sender and receiver are responsible for transmitting. HL7V3.0 clearly defines the possible interactions and the application behavior associated these interactions in the form of responses for which the sender and receiver needs to adhere to. The differences in messages between V2.x and V3.0 and absence of clear guidance on V2.x regarding application behavior on receipt of message makes the transformation exercise more difficult.

Vocabulary: It is a well known fact that 80% of HL7 V2.x message failures are a result of code mismatches. HL7V2.x needs a translation table for each interface and this puts a huge overhead on HL7V2.x implementation. Version 2.x has no formal binding of standard vocabularies to structures. The bindings are ad hoc and always site specific. However Version 3.0 has a strong semantic foundation in explicitly defined concept domains drawn from the standard terminologies. Each concept in a vocabulary domain (a defined set of coded concepts) is represented using a code from a specific vocabulary. The mapping of an ad hoc vocabulary to a standard vocabulary is problematic as cases like one-to-many and many-to-many mappings will be encountered which can be resolved only manually and cannot be automated. One major issue with vocabulary is the emergence of SNOMED as vocabulary of choice for HL7V3.0 messages. SNOMED Post-coordination which describes representation of a Concept using a combination of two or more codes is not possible for V2.x messages up to V2.4 and this makes the mapping and translation more difficult.

Cardinality Constraints: The mapping of cardinality constraints between HL7V3.0 and HL7V2.x is very complex due to the HL7V2.x messages being shallower and less expressive than HL7V3.0 messages. So HL7V2.x messages are unlikely to be able to represent the full range of allowed cardinalities of attributes and associations that HL7V3.0 message can represent

Wrappers: The information present in the HL7V2.x TCP-IP MLLP wrapper is insufficient to populate the ebXML/SOAP HL7V3.0 wrappers to enable the communication and routing of the messages at the integration layer level where HL7 wrappers are not considered. HL7 V3.0 XML ITS can use MLLP for transport but the HL7 interaction semantics defined in the V3.0 standard transport specification using SOAP/ebXML will be disturbed.

HL7V2.x to HL7V3.0 Translation Issues Details-1

In my last post i mentioned that i will publish the detailed information of the translation issues in a white paper. I wanted to use the white paper as a medium to let the wider auidence know of the issues which i thought were deterrent for undertaking the strategy of HL7V2-V3 translation. However the profile of visitors to the blog did convince me that publishing the information here will receive wider publicity. In the first of posts i will discuss the issues with data types.

Semantics: The attributes/data fields in both HL7 v2.x and HL73.0 are associated with a specific HL7 data types. In both the versions data types are basic building blocks of information exchanged in the messages. In V2.x data types are just another level of nesting and the different data types are just considered “formats” of character strings that would appear in HL7 data fields. In V3 the data types define clearly the semantics of data values that can be assigned to a data element. All the data types that exist in Version 2.X do not exist in Version 3 and this complicates the mapping. A few data types like composite types, such as CN (CN - composite ID number and name), contain multiple concepts, and are now represented more explicitly in the information model as either attributes or classes. Some data types like NM (Numeric) in V2.x are expanded in V3 into multiple data types like Integer Number (INT) and Real or Decimal Number (REAL). Other types, such as ID, IS, and CE, received more rigorous definition and an automatic 1:1 mapping is often not possible.

Context: Most of the mapping issues are context driven, for example observations that reside in ‘allergies and adverse reactions’ class of HL7V3.0 contain observations and no clear guidance is available if these need to mapped to general observations in OBX or to AL1 segment in HL7 v2.x. Some other issues are with the message content, for example there is a mismatch between V2.x and V3.0 in terms of Laboratory orders as all V3 Lab Messages are specimen centric i.e. one specimen , several tests and results . V2.5 is specimen centric and match V3 structure but V2.2 to V2.4 which most lab systems in Europe use does not contain any specimen information. The confusion in V2.x on data types like Composite Quantity with Unit" (CQ) which existed in all versions of HL7 v2.x had contradicted with measurement observations (OBX) where numerical result (value type NM) and the units are sent in separate OBX field. In HL7V3 there is only data type Physical Quantity (PQ) with attributes ‘value’ and ‘unit’.

Time: There are some clearly documented and known issues with time data types between V2 and V3.The TQ (Timing Quantity) data type which describes when a service should be performed and how frequently have potentially three V3 data types that can be mapped onto PIVL – Periodic Interval of Time, EIVL – Event-Related Periodic Interval of Time and GTS – General Timing Specification. Both the data types are complex and have multiple representational approaches and no specific level mappings are currently available. The TQ data type has been deprecated from HL7V2.5.

Another issues with the time data types is that the v3 data type Interval IVL containing a single time point is suggested to map to v2.x data type TS (Time Stamp). This mapping carries a risk of semantics loss as v3 IVL used in this way states that the ‘event’ occurred over an interval containing the specified time point, whereas TS states that the ‘event’ occurred at the specified point in time.

Information Loss:There are some imperfect mappings where information loss can be caused when external vocabularies are used in HL7. For example in HL7V2.X the Observation identifier (CE) carries the name of the coding system as a string and in v3.x the coding system is indicated by an OID (Object Identifier) which are globally unique. However in general the OID in HL7V3.0 in general is mapped to HD (Hierarchical descriptor) and EI (Entity identifier) HL7V2.x data types and generally used for facilities, applications, organizations, providers, patients, etc.