TCP/IP interfaces are an implementation of the HL7 Minimal Lower Layer Protocol (MLLP).
For the technical description of the interface, refer to TCP/IP Technical Specifications.
Interfaces can be either a "client" or a "server", irrespective of whether the interface is incoming or outgoing in HL7Connect.
In the TCP/IP relationship, the "client" is responsible for initiating the connection to the "server". The server simply waits on a port, for a client to connect to it.
Once the connection is established, messages will flow both ways irrespective of who is the client or server.
If the connection is broken for some reason, then is up to the client to initiate the connection again to the server.
How should you decide if your interface should be a client or server in the relationship? Here are some hints:
Controls how long HL7Connect will wait for a response after sending a message. If no response is received, the connection will be dropped, and the message will be sent again or discarded as configured in the Sending Control for the interface.
Controls what kind of acknowledgements HL7Connect sends.
|Always Acknowledge||HL7Connect will always send a response message|
|Negative Acknowledgements||HL7Connect will only send response messages that contain Errors or Rejections|
|Errors||HL7Connect will only send response messages that contain Errors (AE)|
|Rejections||HL7Connect will only send response messages that contain Rejections (AR)|
|No Response||HL7Connect will never send a response message|
|As specified||HL7Connect will respond based on the settings in MSH-15|
The default option is Always Acknowledge. This setting is applied right at the end of the message processing pipeline; it will apply whether a message is being stored or passed through. The acknowledgements will appear in the HL7Connect message logs even if they are not sent to the sender.
|TCP Port|| The port on which the interface will listen.
The valid range of port numbers is 1 - 65535.
NOTE: Avoid ports that are used by other processes.
|Client Restriction|| This can be used to restrict the IP address of the client used to connect to the system. This security measure is about the
only one available to use while using MLLP. Leaving these fields blank allows any client open access to the interface.
The IP address of the client trying to access the interface, will be compared to the specified IP address. If the portions of the
IP Address, in the address range specified by the Mask, match, then the client will be granted access.
|Connection Limit||An incoming interface can be configured to accept more than 1 connection. By default, the interface will only accept a single connection.|
|IP Address||The network name, or IP address, of the server to connect to. The name must equate to an IP address, resolvable by DNS.|
|TCP Port||The port the server is listening to|
|Reconnection Delay||Length of time before the interface attempts reconnection, once a connection has been lost, or a connection attempt fails. The default is 15 seconds, with 0 not regarded as a valid value.|
You can get HL7Connect to notify whenever a connection is established or lost. This is most useful for monitoring connections and sending an SMS message (via an SMTP gateway) when the connection is lost.
Lower Layer Protocol is a very simple network protocol that uses an open TCP socket to transmit messages in either direction. TCP messages are wrapped in framing bytes. If there is no messages being transmitted, then there will be no data transmitted. This can have unfortunate interactions with firewalls due to the fact that firewalls often drop connections that have had no traffic for a given period of time. When firewalls drop these connections, they generally do not notify the actual TCP client and server that the connection has been dropped using the standard TCP packet exchange for this, so neither side is notified that the connection has been lost.
What happens after this depends on whether the client or the server is initiating the message exchange..
If the server is initiating message exchange, then when it sends the message, the firewall may return a TCP error; in this case it will close the connection and report a transport error. Since it is a server, it will now wait for a new connection. Alternatively, if the firewall does not return any TCP packet (which some don't) then the traffic will simply be lost, and the server will time out without an answer. Either way, the client will not get any notification, and will continue waiting in the mistaken belief that it still has a valid connection.
If the client is sending, it will send the message, and either receive an error from the firewall or timeout waiting for a reply. In either of these circumstances, it will close the connection, and report an error. Then it will attempt to reconnect to the server. The server will receive this as a new connection attempt and may accept it if it is configured to allow more than one connection.
Note that this is with HL7Connect at each end. If either end is not HL7Connect, they may be configured differently, and handle reconnection differently, but what happens at the TCP level is the same.
If you are sending messages across a firewall that times out inactive connections, your best configuration is to make the outgoing interface a TCP client and set the Server to accept unlimited connections (and you may observe the connection count gradually rising on the server). Note that if an HL7Connect outgoing interface is set as server, then it can only allow one connection, and this configuration may not be possible across a firewall.
If the remote software is not HL7Connect, it may be best to make HL7Connect the client and set it to reconnect after a short time period if there is no traffic. If this period is shorter than the firewall timeout, then the connections are closed cleanly at both ends, and stable messaging should be acheivable.
Some messaging agents do not wish to have HL7 acknowledgements returned. This is risky, because there is no positive confirmation that a message has been received, and lost messages are simply lost, particularly when combined with the firewall issues discussed above. However in some circumstances, this is not a problem; for instance, a patient monitor that sends an update every minute - if a packet is lost, well, there'll be another one in a minute.
In such cases, it's important to set up the interface so that a connection will be properly re-established if there is a problem in the network (in consideration of the discussion above). This may require setting the interface to restart if no messages have been received within a given time period.