When implementing an interfacing solution directly using the Chameleon SDK, there are a number of things to consider, specifically with regards to message delivery over TCP/IP. This page does not apply to Iguana implementations since Iguana handles all the networking side of HL7 interfacing and has been tested under a wide range of hostile TCP/IP conditions.

Writing good quality network interface code that can handle various problems with TCP/IP is not trivial. It is important that this is realized by the system's Primary Integration Engineer.

The most common mistake is to only test with well behaved TCP/IP listeners during development and not anticipate how some counterparties in production will not be well behaved. Typically this is because many HL7 interfaces that you will encounter in production have not been implemented well by other Primary Integration Engineers that also did not know about the issues with networking problems.

In an ideal world the following would be the way that all outgoing HL7 interfaces, for example, would work:

• 1. Poll application for message.
• 2. Send message.
• 3. Wait for an ACK.
• 4. Either:

Receive ACK, verify that ACK is well formed and the message control ID matches the message sent. Then, mark message and sent in database and go back to step 1.

Time out. This should be configurable. Resend the message and go back to step 3.

In practice, however, a number of complications enter into the above scenario. One of the biggest problems in TCP/IP network programming is that everything is asynchronous (i.e. even though the application may think it is connected to the remote host, it may not be since the remote host can disconnect at any time.

Well-written networking software will always check every single network operation and gracefully recover when problems crop up with the network - like when the counterparty disconnects. Poorly written networking software is what we call 'Good news code' which assumes everything is working as expected. 'Good news code' is really bad news since it leads to intermittent, mysterious and difficult-to-troubleshoot problems on customer sites.

A QA person will need to write a program to simulate a hostile TCP/IP counterparty to rigorously check an in-house written HL7 client server to ensure that it can reliably deliver messages without losing data to a poorly behaved HL7 server. In terms of effort, about 2-3 days of development time for the QA person should be budgeted for every day of development.

Other common networking problems to test are:

• Test with high latency. Set up a remote host on a very far away server. Using a remotely hosted web server is not a bad way to do this. Obviously some custom software will need to be written to do this.
• The application should be configurable to work with some systems that cannot be guaranteed to send back valid ACKs for each message.