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.
I first started thinking about the handling of HL7 3.0 XML messages when I got involved with a GotDotNet open community project to design and build an HL7 Library. This project has since gone dormant but I’ve still been thinking about this area. What is the best approach to processing HL7 3.0 XML messages at the time of receipt? Is there a need for an HL7 3.0 object model that deserializes from and serializes to XML? Of course, answers to these questions will be derived from establishing use case scenarios that reflect the business requirements for messaging and workflow. I will soon be brainstorming use case scenarios with others, including my colleague Simon Chester who is our Healthcare Industry Architect and who has a deep knowledge of solutions architecture and enterprise application integration for the healthcare industry.
Simon has posted his thoughts on an HL7 3.0 object model which reflects our recent conversations on this subject of an HL7 3.0 object model. Since then I’ve been in more discussions about how to process the receipt of HL7 3.0 messages and the need for object model deserialization. One interesting idea that came up was to use SQL Server 2005 to persist HL7 3 messages and then use SQL Server Notification Services to notify subscribers. I recently learned that SQL Server 2005 provides the capability to “register” schema collections and then create typed “xml” columns. These typed “xml” columns then provide XML instance validation during persistence and allow indexing on the elements within the XML document. The great thing about having indices on the XML elements for typed “xml” columns, is that it facilitates efficient query operations against a column’s XML document content. You no longer have to pick those elements you want represented as separate indexed columns. Other possible advantages to using SQL Server 2005 for HL7 3.0 XML message persistence include: logging and tracking of all message content without the need to implement separate logging and tracking functionality (may address some/all of Infoway’s requirements for HIAL-level log management services), using SQL Server Notification Services to publish HL7 3.0 message content to subscribers in a more purposed and “simplistic” form, the abstraction of HL7 3.0 message structures away from the core business logic and workflow.
