Roberto Ruggeri has posted an excellent update on his activity at the HL7 Plenary and Working Group Meeting. He provides a good overview of the 3 different health groups that form the Connecting for Health consortium and how their architectures differ from a clinical data aggregation perspective. He also discusses work around pinning down HL7 messaging standards and the difficulty in adopting HL7 3 for infrastructure components due to the significant investments in HL7 2.X.
The other difficulty he mentions is related to the lack of guidance on how to transform between 3.0 and 2.X. This area is something that is key to helping vendors and organizations adopt and integrate HL7 3.0 into environments heavily populated with HL7 2.X solutions. Developing solid guidance and, ideally, “accelerators”, that provide “kick-start” transformations between 3.0 and 2.X will be needed to ease the migration to, and integration with, HL7 3.0 environments. Assuming 2.X messages are being processed in BizTalk as XML using the BizTalk HL7 Accelerator, how does one establish “kick-start” transformations to map HL7 3.0 messages to 2.X and vice versa? This is an area I am planning to investigate. It may not be that straight forward as highlighted by the whitepaper “Navigating the pitfalls: Implementing HL7 version 3” which states:
Don’t assume v2 - v3 mapping can be done at the integration layer
If your application already supports HL7 v2: HL7 v2-v3 migration by means of a mapping is problematic. The main problem is not the mapping itself (although HL7 v3 is much more detailed than HL7 v2), but the behaviour of the application. This is mainly a business flow issue. The dynamic behaviour and trigger events in V2 and V3 are sufficiently different, that your application behaviour will need to map on to them differently. If your application has to support both HL7 v3 as well as HL7 v2: create a new communication module for the HL7 v3 messages/documents, and use it in parallel to the HL7 v2 communication module.
 | HL7, HL7 3, HL7 2 |
