ESI Logs Detail Lost Transactions

During the past several years, I have seen ESI (External Systems Inbound) logs detailing problems with the inbound interfaces for Millennium® systems. Unfortunately, people often don’t believe the data I show them. If there were interface issues, I am told, lots of people would know. I wish that were true. When an interface or Millennium first went live, the interfaces might have been error-free, but errors invariably are introduced over the years following changes on the sending system and in Millennium. Rather than deny their existence, users should be working to identify errors and warnings and determine how to correct these issues.

An interface is a group of executables that communicates with another system, like an interface engine or a registration system. These executables allow the systems to communicate without a person reading data from one system and retyping that data into another. The data can be registration or demographic information, such as the patient name, medical record number, date of birth, next of kin, etc. Or it may be clinical information, like a laboratory or radiology order or information from pharmacy dispensing machines. If an error occurs with one of these transactions, the information might not get to its destination, which can lead to sub-optimal clinical care and sub-optimal financial health for the organization. A check of the ESI message logs will help you identify these errors.

Before telling you how to do just that, here’s a quick cheat sheet of the HL7 acronyms of the transaction types (msh_msg_type) you’re likely to encounter:

  • DFT — Detail Financial Transaction
  • ORM — Order or pharmacy order
  • ORU — Order status update, new order or point-of-care observation
  • SIU — Schedule Information Unsolicited
  • ADT — Admissions, Discharges and Transfers (demographics)
  • MDM —  Medical Document Management transaction (e.g., transcribed results)

A complete list of the transaction or message types that compose the HL7 standards can be downloaded from http://www.hl7.org/implement/standards/index.cfm for a nominal fee.

The first step to diagnosing ESI issues is to gather your data. Create two files, one for ESI warnings and one for ESI errors, and run the following queries:

For warnings from CCL:

Rdb SELECT msh_msg_type, msh_msg_trig, msh_sending_app, error_text from ESI_LOG where error_stat = 'ESI_STAT_WARNING' go

For warnings from SQL:

SELECT msh_msg_type, msh_msg_trig, msh_sending_app, error_text from ESI_LOG where error_stat = 'ESI_STAT_WARNING’;

For errors from CCL:

Rdb SELECT msh_msg_type, msh_msg_trig, msh_sending_app, error_text from ESI_LOG where error_stat = 'ESI_STAT_FAILURE' go

For errors from SQL:

SELECT msh_msg_type, msh_msg_trig, msh_sending_app, error_text from ESI_LOG where error_stat = 'ESI_STAT_FAILURE’;

The data will be returned in four columns, which can be pulled into Excel or any spreadsheet or database software and sorted. Create pivot tables that show what message types are having issues. It might be obvious that errors represent failures, but be aware that warnings are often transaction failures as well. For example, a warning of msh_msg_type of DFT with an msh_msg_trig of P03 will have a message such as “Invalid Service Resource Code,” “No rows exist on bill_item_modifier table for this CDM” or “No Matching Debit Charge.” Each represents a financial transaction that did not update the financial record, which means your organization was not compensated for the care you provided.

ESI warnings also result if an appropriate alias has not been built. The ESI server will not understand where to put the data and will send a warning to the message log, but nobody will know that the transaction failed unless someone is checking the log.

ESI failures are often build or configuration issues, such as a missing alias for a code set or missing priority codes, specimen type codes or detailed task assays. The interface might also be sending addendums to a transcribed report that is not in Millennium. No matter what the reason, none of the transactions updated the clinical record, and your clinicians are treating their patients without the most up-to-date information.

Once you have the number and type of events and understand their importance, you can prioritize how to analyze and resolve them.

Prognosis: A quick review of ESI logs can provide great insight into where Millennium might not be fully updating the clinical and financial database. Setting up the processes to review and resolve these events as quickly as your change control allows will provide great benefit to your patients.