HL7 V3 Ready

The difficulties in mapping HL7V2.x to HL7V3.0 does not make a solution based on transformation and translation easy to implement. The difficulties encounter by initial adopters is making the total adoption of HL7V3.0 very difficult. Version 3 was created as a replacement for Version 2.x, but it is observed that the two versions are catering to distinct markets. However the impending success of major projects like UK-CFH is going to make HL7V3.0 a major standard and replace HL7V2.x in the longer run. It is a well known fact that big bang change of standards in applications deployed in clinical settings is a recipe for major disaster so proposal for a transition path to independent “V3-ready” implementations and “V3-ready” implementations of Version 2.x is required. The following approaches are proposals for an HL7V3.0 ready implementation.

New HL7 V3 domains: Most of the domains which exist in HL7V2.x have equivalence in HL7V3.0 for e.g. ADT in V2.x has equivalent domain called Patient Administration in V3.0, Scheduling exists in both HL7V2.x and HL7V3.0. However the limitations of HL7V2.X did not cater for advances in clinical areas like Clinical Genomics and Clinical trials but the specifications in these areas are well defined in HL7V3.0. It is recommended that organizations start implementing these new domains in their applications using HL7V3.0 and support the existing HL7V2.x messages in other domains before phasing them out as HL7V3.0 standards in those domains mature.

Z- Segment and Z- Fields: Most of the existing clinical settings in different countries have implemented and deployed HL7V2.x specifications in their applications. The ease of implementing HL7V3.0 in these applications depends on the architectural framework and openness to extension. For legacy application which has a V2.x interface and implementing V3.0 in these applications is a cost intensive then it is recommended to use Z-segments and Z-Fields and wrap multiple messages in a single message so that the content needed to populate a v3 message can be obtained. This approach may mitigate some of the mapping and transformation issues defined in the above section.

RIM based Data Model: It should be possible to modify the physical data model of the clinical applications to follow the HL7 model. This means maintaining a relationship between the HL7V3.0 RIM based data model and physical database model. The success of this approach depends on how closely the physical data model matches the RIM logical data model (e.g. D-MIM, R-MIM). This will enable the mapping of HL V3.0 message attributes with the required table attributes in the database.

HL7V3 Conformance for V2.x Implementation: The version 3.0 approaches of use cases, story boards, interaction models and vocabulary can be used in Version 2.x implementations so that the message profiles developed for Version 2 can be mapped onto Version 3 at some point in the future. The development of message profiles as a means to guide a new HL7V2.x implementation or modify an existing HL7V2.x implementation is consistent with HL7V3.0 development methodology. This will allow us to focus on non-data aspects of HL7V3.0 i.e. defining the interactions in an implementation and the application behavior associated with this implementation. The focus shift will enable us to concentrate on HL7V3.0 messages data structure as the need for changes to application functionality is reduced.

CDA Implementation: An alternative strategy is to use CDA (Clinical Document Architecture). The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange. CDA documents are encoded in XML and derive their machine processable meaning from the HL7 Reference Information Model (RIM) and use the HL7 Version 3 Data Types. The factor that makes it easy to move to CDA is that this specification defines a multi level architecture where each level is derived from a more basic level. The levels refer to varying degrees of required markup granularity and specificity and not the depth or granularity of the content. Figure below shows the definition of different CDA Levels

Figure: CDA Levels

CDA Levels provide iteratively adding greater markup to clinical documents apart from establishing baselines for conformance. As Level one includes only header includes and semantics in level one body is easy initially to implement this and have a defined phased approach to other levels.

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.

HL7V2.x - HL7V3.0 Transformation / Translation

The adoption of any new messaging standard will be faster only if there exists a clear and defined transformation and migration strategy between the new standards and existing standards. It is always preferred to handle such a strategy in a middleware so as not to modify the core clinical applications to cater to the standard which is very expensive in the shorter run. However till now there is no clearly defined guidance to facilitate such a transformation of messages between Version 2 and Version 3.

These differences in methodology make the transformation from one version to another difficult. Technically it is possible to map the segments in V2 messages to XML sub-tree in XML schema with defined conversion mapping rules. However site specific interpretations of V2.x with user defined segments and fields make the transformation to V3.0 based on a common reference model appear like a mapping from a proprietary standard to a universal standard.

There are several instances where HL7 V2-V3 mapping has been attempted and tools are made available for specific projects like caBIG (Cancer Biomedical Informatics Grid) and commercial tools like Oracle HTB. Figure below shows a generic architecture used in these different initiatives. The mapping in these tools is manual and there is no pre-defined intelligent mapping or guidance provided with the tool sets. Exceptional domain expertise is required to perform the mapping in these tools.

The message structures used by HL7 v2 and V3 are different and the initial step involves converting the messages to a common canonical format before the mapping can be done. The V3.0 XML format is not compatible with the string delimited non-XML V2.x format. The V2.x XML encoding will enable it to be compatible with V3.0 XML format. The canonical transformation component will enable both these XML messages to be converted into an intermediate format to enable the mapping. The mapping between V2 and V3 is relatively straight forward in some cases of demographic data and clinical data where HL7V2.x segments directly map onto HL7 V3 classes. In other areas it has been not possible to map the different versions. A summary of some of the the difficulties faced during the mapping are [ Full details in my to be shortly published white Paper ]

Data Types

• Formats of Character Strings to Semantic data values
• Context and Content driven mapping issues leading to information loss

Conformance Patterns

• Clear definition of roles for Senders and Receivers in HL7V3.0
• No Clear guidance on application behaviour using HL7V2.x

Vocabulary

• V3.0 has strong semantic foundation and V2.x has no formal binding to Voc
• No one to one data types exist

Cardinality Constraints

V2.x messages shallower and less expressive than HL7V3.0 messages


Wrappers

Insufficient information in HL7V2.x-MLLP compared to HL7V3.0-ebXML/SOAP