To have a discussion about HL7 Standard TCP/IP Message exchange it is important for everyone to understand what is happening and for everyone to use the same terminology. The most common misconception, or misstatement, is that the HL7 Sender sends HL7 message files, or that a HL7 Listener receives HL7 Message files. If you want to exchange files you use FTP or email with attachments. To your CORE HL7 Sender a file is merely a container for HL7 messages. In a nutshell, we open the container, take out the HL7 message(s) inside, and deliver them via a TCP/IP stream to the destination HL7 Listener.
When running your CORE HL7 Sender profile works in a continuous loop between the Data Folder and a sub-folder of the Data Folder named CSQueue. The CSQueue sub-folder is very important and the primary thing to remember is that it belongs to US (your CORE HL7 Sender), you should never place any data files in this folder yourself. The sending operation loop works like this.
•Step 1. The CSQueue sub-folder is polled for HL7 message files which WE (your Sender Profile) have placed there to be sent. If there are no messages queued it proceeds to Step 2. If there are ANY messages in this folder your Sender will attempt to process the queue from oldest file to newest file and deliver the HL7 message(s) to the Destination. If the queue cannot be processed, for instance if the destination HL7 Listener is off-line, the VPN is down, firewalls are blocking traffic, etc. etc. your profile will stop, pause for a brief period (10-30 seconds or so) and starts again with Step 1. As each message is successfully delivered to the destination the queue file containing it is deleted. When the CSQueue folder is empty (and only then) will it advance to Step 2 and examine the Data Folder.
•Step 2. The Data Folder is polled for *.<FileExtension>. If no eligible* files are detected it moves on to Step 3. If any eligible* files are detected they are sorted by the Last Modified date on the file and each file is opened up and analyzed, any HL7 messages detected are extracted and written to the CSQueue folder to be delivered. If, during this process, any message is discovered to be Malformed, that message will be written to the CSMalformed sub-folder of the data folder. Once all messages in the file have been extracted and written to the queue the file is deleted and the profile moves on to the next data file. You can consider what this means. If you place a data file with 50,000 HL7 messages into the Data Folder we will extract those messages and create 50,000 individual files in the CSQueue folder. Once the Data Folder has been processed (IE it is empty of eligible files) it will advance to Step 3.
•Step 3. IF the operations in Step 2 resulted in any messages being written to the CSQueue sub-folder your profile will immediately loop back and start again with Step 1. IF there were no eligible* files detected your processor will pause for 10 seconds and then begin the cycle again with Step 1. There are some exceptions to this 10 second wait which will be explained below.
•*In Step 2, what makes a file eligible to be processed? Any files with 0 bytes are ignored. There is also some latency here as well in that your CORE HL7 Sender will NOT process any file in the Data Folder unless it is at least 1 second old. If files like this are detected your profile knows that, while not eligible now, they will become eligible in the next second or so and will NOT wait 10 seconds but will immediately begin the cycle again with Step 1.
IF a HL7 message is discovered to be malformed in some way which prevents it from being delivered to the destination it will be written to the CSMalformed sub-folder of the Data Folder. These malformed files will always contain only the "Raw" HL7 exactly as was detected in the original data file.
•No Message Control ID. The Message Control ID (MSH 10.1) is ABSOLUTELY required to exchange HL7 messages over TCP/IP. It is this field which Listener(s) use to send ACKs back to the sender.
•Only 1 segment detected. There is no VALID HL7 message which contains only 1 segment. Even a HL7 ACK messsage contains 2 segments. If this scenario occurs it is usually a miscommunication between the sender and the receiver over what to use as the SOM (Segment Delimiter).
•Improperly Escaped Data. This can occur if the body of the HL7 message contains an unexpected SOM character or CRLF.
•It is a HL7 Ackknowledgement Message. You cannot send messages with a type (MSH 9.1) of ACK. Acknowledgement messages are sent BACK to the sender from the listener and you cannot ACK an ACK.
Your Important Takeaways From this Page
You should always monitor the CSMalfomed sub-folder of the Data Folder. This folder should always be empty. If it contains any files they should be autopsied to determine what the problem is and it should be corrected.
If you see data files backing up in the Data Folder and cannot figure out why, look in the CSQueue folder. If there are messages in there your Sender Profile is working trying to deliver those messages and will ignore the Data Folder until it has delivered them all. If that's empty make sure that the files in the data folder are not 0 byte files and are not future-dated.
