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.
Beta 1.1 of HL7 Insight has been released with the following new cosmetic features:
- Added ability to change the font size and the font type (fixed width only).
- Now supports word wrap; can be toggled on or off.
- Added ability to change the message display colors, including: background color, HL7 encoding character colors, field text color, and segment ID color.
- When started will restore the HL7 Insight window to the previous position and size.
You can download HL7 Insight Beta 1.1 here. Going forward, I will also place HL7 Insight releases on a separate “HL7 Insight” web page.
Do you work with HL7 2.X messages and need to decipher field content? Ever spend time counting segment fields in HL7 2.X messages trying to locate and understand content of interest? If so, then HL7 Insight will help save you time, giving you quick insight into your HL7 message content. Summary of features:
- Load an HL7 message, point the mouse at segments and fields of interest, and receive instant tooltip-style feedback, including: segment ID, field number, field length, optionality, and detailed data type information;
- Supports all HL7 2.X versions up to and including version 2.5;
- Supports HL7 message “batches” (note: the BSH and FSH segments are not currently supported and must be excluded from the batch before displaying in HL7 Insight);
- Colorizes the HL7 message text;
Sample HL7 Insight screen shots:
The HL7 Insight tool is currently in beta and has not yet been extensively tested with all HL7 2.X versions. Please let me know if you encounter any bugs/issues or if you have any questions and/or suggestions. After installation please see the file “ReleaseNotes.txt” for a list of known issues.
You can download beta 1 of HL7 Insight here.
