Recently I have been working with the BETA version of the HL7 accelerator for BizTalk Server 2006 (due out real soon now). For those of you know don’t know, HL7 is the horrible specification for the exchange of information between systems that service the medical industry. Just to show you how horrible it is, I thought I would share a sample message:

It should be plainly obvious from this (WTF!!!) that this is a message which notifies us that the patient is being discharged from the medical facility (ADT message group, message ID A03).

The documentation that comes with the accellerator is pretty good but it assumes that you know a lot about HL7 which may or may not be true. In my particular case I am just a .NET developer with BizTalk skills who was asked to map from one HL7 message format version to another.

If you are in the same situation then I share the following high-level steps to you as a way to get this up and running:

1. Create a solution; there are going to be lots of sub-projects.
2. Create a common project; which common project you use will depend on the version of HL7 that you are dealing with. If you are dealing with v2.3.1 then you are going to need to use the BTAHL7V231Common Project. Once the project is created you will need to sign it with a strong name key (duh – its a BizTalk project). This project contains the underlying schema types required by the particular version of HL7 that you are using.
3. Create an empty project; in this project you will add the specific message schemas that you want to work with (for example ADT AD03). When you go to add a BTAHL7 schema a dialog will come up. Select your schema and click finish (twice). Once this is done add a reference to the BTAHL7V231Common project that you created earlier. Once again, remember to sign the assembly with a strong name key.
4. Repeat steps two and three; for each different version of HL7 that you want to work with and message that you want to map between.
5. Create an empty project for mapping; while you could put a map inside one of the assemblies that you have created I recommend that you put the maps inside a seperate assembly in this case. Create an empty BTAHL7 project and at a BizTalk map file too it. Add a reference to the two BTAHL7 projects that contain the message schemas AND the common projects that they reference. Go ahead and map the two schemas (this is the fun bit because some schemas are VERY large, and the names differ just slightly. Once again – sign the assembly with a strong name key.
6. Deploy the assemblies; you should be able to do this without any problems from Visual Studio. If you are using a virtual machine go and have cup of coffee.
7. Create send and receive ports; using the snazzy new administration tools in BizTalk Server 2006 quickly knock up a send and receive port, I recommend using the file adapter for testing purposes. There isn’t anythinig special about these ports other than they use BTAHL72X[Send/Receive]Pipeline.
8. Apply your map; apply your message map to the send port and set a BTS.MessageType filter to equal “http://microsoft.com/HealthCare/HL7/2X#ADT_A03_231_GLO_DEF”.
9. Press the big red button; restart the host instance just for good measure and drop your sample message into the location that the receive port is looking. If you don’t have a sample message grab one from the following location: “C:\Program Files\Microsoft BizTalk Accelerator for HL7 1.3\Samples”.

Its easy when you know how, but unfortunately if its the first time that you are doing it you see quite a few error messages before you see any success.

What about HL7 v3?

Good question. Getting good information on HL7 v3 is pretty hard, the specification really isn’t baked yet and what I have seen scares the crap out of me (possibly more than the sample message above). What they seem to be doing is building a type system on top of XML and then layering the various messaging requirements they have on top of that. To me, this seems like an abuse of XML and is perhaps one of the reasons the spec hasn’t made it out the door.

Personally, I think that the medical industry needs to hand the design of messaging formats over to a number of commercial software vendors (say IBM and Microsoft), in my experience this kind of arrangement ends up with much better results (I cite the pace of development around SOAP vs. XForms as an example).