ESI Logs Detail Lost Transactions

Updated: Sep 21, 2018

by David Hallberg


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.

  • Grey LinkedIn Icon
  • Grey Twitter Icon
  • Grey Facebook Icon
  • CernerUsersIcon

4500 West 89th Street

Prairie Village, KS 66207

Phone: 913.649.1024

© 1995 - 2020 Softek Solutions, Inc.

All rights reserved.

Cerner®, Cerner Millennium®, and Cerner Smart Hospital® are all registered trademarks of Cerner Corporation, or its subsidiaries or divisions, registered in the US and other countries, and Softek makes no claim in or to the same. Cerner Corporation is not affiliated with Softek and does not endorse or sponsor our products or services.