HL7 Message Interfaces

Creating a HL7 message interface does not have to be as confusing as the HL7 world would have you believe. The biggest problem that people have when starting out is that they try and attack the entire interface as a single problem when in fact there are several moving pieces which should always be considered separately. When you start out we always recommend that you begin with a whiteboard and on that board draw a vertical line down the middle. On the left side write Message Transport and on the right side write Message Processing (see below). Now that you've split your interface project into 2 categories (Transport and Processing) comes the hardest thing for developers new to HL7 to understand. 

HintDon't ever think of these 2 categories together! Through your entire project always consider them separately. Message Transport is always how you will receive and/or send HL7 messages. Message Processing is always what you will actually DO with HL7 messages you receive or how you will CREATE HL7 messages that you need to send.

HL7Whiteboard
HL7 Interface Whiteboard

Now let's break it down even further. What are your real goals with your HL7 interface? Do you need to receive HL7 messages? Do you need to send HL7 messages? Do you need to do both? Sometimes people can be confused by this who are new to HL7 and have the question:

smallbulb

Isn't HL7 bi-directional? There's really only one HL7 transaction that is actually bi-directional and if you don't know what that is then, trust us, you aren't using it. So let's break our interface down even further with TWO white boards. One for INBOUND messages and one for OUTBOUND messages. Nothing changes in our earlier example. For both whiteboards we are still separating Transport and Processing (and never thinking of them together), but now we are also going to separate our inbound and outbound interface tasks and NEVER think of them together either (see below).

If you plan and design your HL7 interfaces like this you will wind up with a more robust, flexible and easy to understand product at the end.

smallbulbOne final thing to consider. Who are YOU in the interface? Something that can frequently get forgotten when creating a HL7 message interface is the notion that it is always a negotiation between two pieces of software (call them Trading Partners) and typically there will be one or more clients in the middle who initiate or broker the negotiation. So what is your position in this negotiation? Consider the example of a simple Laboratory HL7 interface to receive Lab reports.

The parties involved are 1) the Lab producing and sending the reports, 2) the medical software that needs to receive the Lab reports, and 3) the client (doctor, hospital, clinic, etc) who uses the Lab from #1 and the software from #2. Who you are in this scenario can have a great influence on how much work you have to do because: 

  • bluehint16If you are #2 (the medical software) with a small market share and the Lab (#1) is a very large laboratory then you might find yourself needing to make many changes or do extra work because, frankly, the Laboratory doesn't care whether they interface with you or not.
  • #
  • bluehint16If you are #1 (the Lab) and you are a small lab and #2 is a large powerful medical software package then you might actually NEED the interface more than your trading partner does.
  • #
  • bluehint16Now, if you are #3 (the client) and you order 10,000 lab tests per month then we can tell you from experience that the Laboratory (#1) will do absolutely anything that you ask. They will be happy to hand-deliver lab results on a thumb-drive to #2 (the medical software) every day and bring breakfast along as well.

 

 

  Next Article: HL7 Message Transport BlueRightArrow32