Recently I took a dive into the world of Microsoft Intermediate Language (MSIL). Why? I didn’t yet have the source code for an assembly I was referencing and I needed to remove a date validation constraint that was affecting the solution. This is how I resolved the situation:
- Disassembled the assembly into Microsoft Intermediate Language (IL) using the Microsoft IL Disassembler (ildasm.exe) located in “C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin”.
- Edited the MSIL file and updated the date validation code to pass validation.
- Assembled the IL back into an assembly using the Microsoft IL Assembler (ilasm.exe) located in “C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322″.
Pretty straight forward except for having to learn some MSIL. Oh, and there was also the effort required to identify the area of code in question. To cut that story short, I’ll simply say that I pinned down the boolean variable that was used to determine if today’s date was within or outside of the hard coded date range … and that variable is simply “named” variable “2″. I searched the MSIL file for all areas where variable “2″ was updated and then came across the date validation logic that I had to amend.
Following is the MSIL code snippet containing the date validation check which I’ve amended to pass validation by “widening” the year values. This snippet is asking the question: Is the current date between Oct 3, 2009 and Aug 7, 2000? If so, then the “date invalid” flag is set to true, otherwise leave the “date invalid” flag as false.
- IL_0017: Get the current date and push it on to the stack.
- IL_001c: Push the value 0×7d9 (2009) on to the stack.
- IL_0021: Push the value 10 on to the stack.
- IL_0023: Push the value 3 on to the stack.
- IL_0024: Instantiate a DateTime instance for the date Oct 3, 2009. This will pop the year, month, and day values from the stack leaving the current date (from IL_017) at the top of the stack.
- IL_0029: Compare the current date to Oct 3, 2009 and place the result on the stack.
- IL_002e: Load the value 0 on to the stack.
- IL_002f: Compare the value 0 (from top of stack) to the DateTime::Compare result (second from top on the stack) and branch to IL_004a if greater than or equal. In other words, if “Now” is greater than or equal to Oct 3, 2009, branch to IL_004a where the date validation flag is set to true, meaning “failed validation”.
- IL_0031 to IL_0048: Compare “Now” to the date Aug 7, 2000 and branch to IL_004c if “Now” is greater than or equal to Aug 7, 2000. In other words, branch past the code that sets the date validation flag “invalid” (value of 1).
- IL_004a to IL_004b: Push the value 1 (true, in this case) on to the stack and store that value (stloc) in location 2 (”variable 2″). In order words set the “date is invalid” variable to true.
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.
I was recently in a meeting to discuss and help refine my company’s solutions approach when I mentioned the importance of having a “zero feature release” (ZFR). Some people in the meeting were not familiar with the meaning of a ZFR. I went on to explain that a ZFR is essentially the release of the project’s first iteration that includes all components of the project’s architecture and infrastructure (or as many as possible), but “no features”. Why is this so important? Because highlighting and addressing architectural issues early, is significantly easier than addressing them during later release stages. Leaving core architectural pieces to later release stages can dramatically increase project risk in terms of time, quality, and costs.
A couple of quotes from Kent Beck’s book Extreme Programming Explained highlight the focus of the first iteration:
…the first iteration must be a functioning skeleton of the system as a whole… For the first iteration, pick a set of simple, basic stories that you expect will force you to create the whole architecture. Then narrow your horizon and implement the stories in the simplest way that can possibly work. At the end of this exercise you will have your architecture.
(Beck 113)
The first iteration puts the architecture in place. Pick stories for the first iteration that will force you to create ‘the whole system,’ even if it is in skeletal form.
(Beck 134)
Deployment and configuration issues (like architectural issues) must also be identified as early as possible. Too often, deployment and configuration issues arise later in the project lifecycle creating project delays, increasing costs, and risking the quality of the deliverable. Therefore, in addition to an architectural focus, a zero feature release must also be focused on validating the deployment and configuration of the system.
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.
One of the frustrations with BizTalk 2004 maps is the obscurity of functoids when viewing maps in Visual Studio. Depending on the volume of functoids in a map and/or depending on the degree of functoid chaining, easily understanding functoid usage can be impossible without diving into the functoid properties. So, I’ve written a stylesheet that transforms a BizTalk 2004 map into an HTML view containing the following information:
- The node links between source and destination schemas.
- All functoids used in the map are displayed with their parameters.
- Chained functoids are displayed as nested “function” calls.
- For HL7 schemas where source and desitnation are the same message type, links between different nodes are highlighted. The way I do this is not reliable as it depends on detecting a pattern in the root node name; looks for node names ending in ‘GLO_DEF’. Is there a more reliable way?
The other advantage to having HTML views of your maps is that HTML is a much more friendly format to share with non-developers who need to understand the transformations (e.g. testers) and who may not have access to Visual Studio.
You can download the stylesheet here. Consider it a beta version as it has not yet been fully tested (e.g. haven’t tested against all functoids, haven’t verified that all links and functoids are being reported correctly, haven’t tested against a wide variety of maps, etc).
At the moment I’m running the stylesheet using the Microsoft command line transformation utility (msxsl). Other more seamless approaches would be:
- A right-click explorer context menu for “.btm” files that would present a menu item to transform the map into an HTML view.
- Integration into Visual Studio so that you can choose to open a map as an HTML view (can’t remember how best to do this but I’m sure it can be done).
I’m sure there are a number of improvement/enhancements that can be made (e.g. including the functoid/link label attributes in the output). So please feel free to provide any feedback/ideas you have.
Following is a sample screen shot of an HTML view of a BizTalk HL7 map (click on the image to see the actual HTML):
