To understand HL7 Message exchange over TCP/IP it's important to start with the RECEIVER (the HL7 Listener). Although not often discussed any properly written and configured HL7 Listener should behave rather like a Web Server. It should be able to accept multiple simultaneous connections from HL7 Senders (like the CORE HL7 Sender) and receive, process, and acknowledge messages from all simultaneously.
It is because of this that according to the powers that be in the governing bodies of HL7 (HL7.org) assert that the proper way to SEND a HL7 message to a listener is to do the following for every message sent:
1.Establish a TCP/IP connection to the waiting Listener's TCP/IP address and Port number.
2.Send your HL7 message.
3.If expected, wait an appropriate amount of time for the Listener to respond with a HL7 ACK.
4.Close the TCP/IP connection to the Listener.
You might think, "that's an awful lot of opening and closing connections, doesn't that slow me down?". The short answer is NO, not in any way that a human could notice. This TCP/IP "handshake" is very fast and once you establish a connection (which might take a few milliseconds to a half second) and close it that connection information is cached in the Windows TCP/IP stack for a short while so that when you reconnect it's virtually instantaneous IF the HL7 Listener is still online and visible. The real performance cost of doing it right should not amount to more than a couple of dozen send operations per hour out of 10s of thousands of send operations.
Can't I just Keep the Connection open with the Listener? You can, there's a setting for it in your Sender Profiles, but you should not unless your Trading Partner insists on it, and IF they insist on it, you should push back on it and ask why? Because....
HL7 Interfaces Are Always A Negotiation
Any time you create a HL7 interface it is (or should be) a negotiation between the two Trading Partners. Beyond the very basic information, TCP/IP addresses, Port Numbers, VPNs and how they will work, both parties should have a reasonable expectation of more information from the other side and then a resolution if any conflicts exist.
If you are the SENDER:
If you are creating and sending HL7 messages, or even if you are just a middle man passing messages through, you should be prepared to tell your Trading Partner at least the following:
•What version(s) of HL7 are you exchanging.
•What types of HL7 messages will you be delivering.
•In each type of HL7 message what HL7 segments can they expect.
•Any pertinent details of the message content. Required fields or segments, data formats etc.
•What is your anticipated message volume. Per day, per hour, do you have peak hours of traffic, etc.
•Any variations from the HL7 Standards which are required by you.
You should also always ask of the Trading Partner at least the following:
•Do they have any volume limitations which might conflict with your own volume requirements?
•How much time do they need to process and acknowledge each message? This will inform you of how set up your Sender Profile in section 3.
•Do they require any deviations from the HL7 Standards.
If you are the RECEIVER:
If you are receiving HL7 messages it's really mostly just the reverse you should be prepared to tell your Trading Partner at least the following:
•What version(s) of HL7 are you exchanging.
•What types of HL7 messages will you be expecting.
•In each type of HL7 message what HL7 segments do you expect.
•Any pertinent details of the message content. Required fields or segments, data formats etc.
•What are your message volume capacity limitations. Per day, per hour etc.
•How much time you need to process and acknowledge each message.
•What types of HL7 acknowledgements you will be sending back.
•Any variations from the HL7 Standards which are required by you.
You should also always ask of the Trading Partner at least the following:
•What is their anticipated HL7 message volume. Per day, per hour, peak hours, etc.
•Will there be any deviations from the HL7 Standards in the messages sent.
