As your CORE HL7 Listener(s) are running (whether locally or as a service) and they receive a properly formatted HL7 message it will be written to the Data Folder you have selected in your listener profile. There will always be only 1 (one) HL7 message per file and the HL7 data in the file will have the TCP/IP envelope (BOM and EOM) removed.
Files will be named like so: Message.<ID>.<DateTimeStamp>.<FileExtension>
•<ID> is the ID field from your listener profile.
•<FileExtension> is the File Extension field from your listener profile.
•<DateTimeStamp> will be a system date time stamp down to the millisecond.
We placed a lot of thought into the file naming conventions we use. We are always cognizant of the fact that your CORE HL7 Listener is only 1 part of a larger HL7 interface and that after we are done with a file and have successfully written it out to the Data Folder, another process of yours still has to read the data folder, pick up these messages, and process them.
If you examine the file names they are crafted in such a way that if you view the Data Folder in Windows File Explorer you can sort the folder contents by EITHER File Name OR Last Modified date and the order is actually identical (either ascending or descending). With HL7 it is always vital that your process(es) which handle the HL7 messages processes them in the correct order (IE the order they were received from the sender).
What happens if an error occurs writing the HL7 message out to the Data Folder?
Answer: Obviously this should never happen, but it's always possible. Network shares go down, user rights get mixed up, HDD space runs low, etc. When this scenario occurs your CORE HL7 Listener will do the following:
•Send a NAK (negative HL7 Acknowledgement) back to the sender indicating that an error has occurred. It will do this even if you have configured your listener profile to NEVER send HL7 Acknowledgements or AUTOMATIC and the incoming message does not indicate that an ACK is expected.
•STOP Listening. It will remain stopped until the problem resolves itself checking every few seconds. For instance, if your Data Folder resides on a network share and the hosting server is being rebooted or goes offline at all, your listener will stay stopped until it can "see" the Data Folder again, then it will restart.
Your CORE HL7 Listener(s) receive data in a stream, and they will evaluate that stream to determine if it contains a recognizable HL7 message. Data which is unrecognized as HL7 is ignored (eaten) by the Listener. This means that if someone sends a recipe for soup into your HL7 Listener it is ignored.
However, it is possible for data to be received which is formatted just enough to recognized as probably a HL7 message attempt but is still fundamentally malformed according to the world governing bodies of HL7 (HL7.org). Some examples might be:
•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 your 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.
IF your CORE HL7 Listener(s) detect a malformed message it will still ACK the message as expected but instead of writing the message out to the Data Folder, it will write the message out to the Malformed sub-folder of the Data Folder. The data files will be created using same naming convention as regular data files, BUT, the malformed message is NEVER "Optimized" according to your selections in your Listener Profile(s), the malformed files will always contain only the "Raw" HL7 exactly as received by your Listener.
