Roberto Ruggeri has just posted an article announcing the publication of the Microsoft Connected Health Framework. As usual, Roberto has done a good job of introducing and explaining things and, therefore, you should be able to easily discern how the Connected Health Framework (CHF) is being positioned. I really like Roberto’s focus on how CHF is not intended as a vertically targeted, technology-centric framework but is, instead, geared towards the interaction of services and business components in a industry-neutral manner. As Roberto says:
What makes a solution specific to healthcare is the type of messages that are exchanged, the security and policies for authentication, authorization and information access and of course the nature of services and business components
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.
