Healthcare Interoperability Insights: Log Files

When working through the complexities of a healthcare integration project or monitoring day to day operations within your existing interface environment, it is sometimes necessary to “dig in” to the discrete message data being moved between applications, whether it is HL7, XML, X12, NCPDP SCRIPT, etc.  For instance, there are scenarios common to healthcare integration which often require an analyst to find specific messages and perform some sort of action on the data, once it is found.

One example of this would be when an HIS system distributes an order message (ORM) to a downstream application, such as a RIS or a LIS, but the order doesn’t make it into the system.  The downstream application’s end-user might need assistance finding the patient’s “missing” order, and that task might fall to the interface analyst at the site.  Assuming that the applications in question have log files where the individual orders can be accessed, the interface analyst then needs to review the log files for both the sending and receiving applications, until they can find the “missing” order and determine why it wasn’t delivered.

Depending on the capabilities of the application, they may need to do this review a single message at a time, or they may make use of any existing filtering capabilities to vastly quicken their search, perhaps filtering by day, time of day, and specific message data for the interface in question.  If the log file also contains the TCP/MLP connection state information, hex character views for all messages in the data stream, or any acknowledgement messages sent or received, then the job of the analyst is eased, as each piece of relevant information increases the likelihood of discovering the root cause of the issue and a path for quick resolution.

Once the interface analyst finds the missing order, they may then wish to “re-send” the message to the downstream application.  At this point in the process they need to consider factors such as whether or not the message needs to be reprocessed through any translation logic, or if it can be sent as is, etc.  Once that has been identified, the analyst will typically either go back to the sending application and re-queue the message, or re-send the message directly from the log file if they have the capability to do so.

Ideally, if the interface analyst’s applications are sufficiently robust, or if they are using an interface engine with the necessary logs and all of the aforementioned tools and capabilities at their disposal, they can affect a fast and accurate resolution to the issue, and any delays on patient care can be reduced or eliminated.