Notice: Get a jump on 2015 — Pay your 2015 ASA membership dues now!


About ASA

The American Society of Anesthesiologists is an educational, research and scientific association of physicians organized to raise and maintain the standards of the medical practice of anesthesiology and improve the care of the patient.


Information for Authors



Published monthly, the NEWSLETTER contains up-to-date information on Society activities and other areas of interest. 

Subscribe to the ASA NEWSLETTER



N. Martin Giesecke, M.D., Chair



Send general NEWSLETTER questions to

October 1, 2013 Volume 77, Number 10
Challenges in Creating and Maintaining Interfaces With an AIMS Patrick J. McCormick, M.D.

Anesthesia information management systems (AIMS) create electronic records that constitute a portion of a larger medical record. A single anesthetic for a surgical intervention is just one encounter within a comprehensive medical record that contains information from many divergent sources. One of the most essential (yet least glamorous) tasks that confront departmental champions for anesthesia information technology is creating and maintaining interfaces that move data to and from the AIMS. This critical task supports many functions that may include medical recordkeeping, professional billing, quality assessment/performance improvement, research and practitioner compensation.


Interfaces are challenging for departmental administrators, because a malfunctioning interface may occur at nearly any time, and warning systems are difficult to create and maintain. The largest threat of interface failures is that data losses will lead to negative effects on the functions supported by the AIMS interfaces, from which recovery may be difficult or impossible. As with so many IT efforts, proper planning, operational implementation and system documentation will be the most effective tools for reducing the potential for failure.


This article reviews lessons learned by one institution’s anesthesia informatics team related to building and maintaining critical interfaces to and from the AIMS platform. Three examples are presented:

• A link created with a hospital data warehouse to transmit data to the Anesthesia Quality Institute;

• A bidirectional link with our hospital’s electronic medical record; and

• The electronic interface with our professional billing vendor.


The Value of a Highly Developed Specification

Like many AIMS, the data recorded at our institution reflect what occurred within the O.R., but not during the time before and after. The informatics team needed to combine data from other hospital systems with the AIMS data to create a single record. This encounter-level data would improve our ability to conduct research, examine quality and contribute complete case data to the Anesthesia Quality Institute’s National Anesthesia Clinical Outcomes Registry


At the outset of this project, the hospital data warehouse had recently completed the task of centralizing multiple data sources. Our team began the interface specification process by asking the hospital data warehouse team how they could help us retrieve basic information about the patient’s hospital visit that corresponded to a given anesthetic case. Table 1 summarizes the steps we took to develop the interface specification.


Table 1: Essential Elements of a Data Interface

Agree with your interface partners on the overall goals and basic units of work

Write a detailed specification of what you want, without anything left to the imagination

Implement the specification on both sides with a rapid development cycle

Create checks to improve data quality by filtering artifact

Institute periodic automated monitoring for functionality and errors


Next, we compiled a list of all of the data elements we wished to retrieve, including current medications, discharge status, length of stay and other metrics. For each element, we specified the time interval that we wished the element to cover. Simply saying “for this visit” was not sufficient. For example, if a patient arrived in January for a visit, and then came for surgery in April, no new medications would appear on the April encounter if there was no change from the January list. So, we asked for “all medications currently being taken at the time of this encounter.”


Another data element that was difficult to specify was: “How many days did the patient live after the visit?” The data warehouse team created several fields for us to address this issue. One indicated the patient’s discharge disposition, and another indicated if the patient had died on any subsequent visit. A third field reported the date of death within the Social Security Death Index for that patient’s Social Security number. The Social Security Death Index has significant limitations, however. Since November 2011, state records have been removed from the index, reducing the number of new entries each year by 1 million.3 Also, some departments do not collect a patient’s Social Security number unless it is required for billing the patient’s insurance carrier.


Once the specification was completed, the data warehouse team created the report. After about two months of programming, we started using the report on a regular basis. Any cases that could not be matched to encounters in the hospital data warehouse were followed up to identify ways to improve the matching algorithm. By incorporating the hospital encounter-level records, we were able to begin contributing data regarding the vast majority of cases to the Anesthesia Quality Institute, including length of stay, discharge status, ICD-9 diagnosis and procedure codes, and laboratory test results.


The Robustness Principle

All interfaces should follow the robustness principle, also known as Postel’s Law: “Be conservative in what you do, be liberal in what you accept from others.”2 The meaning of this statement is that interface software should always send data in exactly the same format, but allow data that are being received to vary slightly or to contain noise. The most robust interface software ignores variations and noise in incoming data.


As part of our department’s documentation compliance initiative, we asked the enterprise electronic medical record (EMR) team for a feed alerting us whenever an anesthesia note (pre-op, handoff or post-op) was filed. Our EMR team provided a report generated several times a day. The interface software was written to read these periodic reports and stream the data to our database. The compliance software then sent an email reminder to all providers whose recent cases did not have the appropriate EMR notes.


Some of the periodic reports were revised versions of reports originally written for human consumption, and many had unusual date and time formatting. The reports would usually show up at the appointed time, but some days they would not. Sometimes, the report would claim that no notes were written, which was highly unlikely.


We wrote our interface software to be very forgiving of variances within the reports and to perform “sanity checks” on the data. Another goal we set was to have the interface report details of how the data were not meeting expectations. Objective data are far more helpful to data interface partners than broad complaints such as “it’s not working the way you said it would.”


Lessons From 10 Years of One Interface

In 2004, our departmental team created a special interface to generate complete billing vouchers using data from our AIMS system.1 Almost 10 years later, that interface continues to function well, handling thousands of charges every month. One reason this interface has survived is the multiple layers of checks and reports formed. Even now, we continue to create more of these checks to ensure that every case is billed properly.


After creating an anesthesia data warehouse for research purposes, we began daily cross-checks of the cases in the data warehouse with the cases in the billing database. We found that due to an AIMS limitation, it was possible for a case to appear in the data warehouse, but not in the billing voucher report.


While only occurring once every few weeks, these cases were never being billed properly. The daily check against a parallel data source allowed us to identify and correct these “missing” cases.


Another reason this interface has remained robust is that an automated feedback mechanism was designed at the beginning. Data on anesthetic cases are constantly arriving, imported into tables segregated by whether the data are new or an update of old data (Table 2). If data are missing when the interface attempts to create a voucher, the case is temporarily set aside, and an email is generated asking for missing data (often e-signatures or case times) to be filled in. Once the case is modified with the missing data, the voucher is completed. If time passes and the case remains incomplete, our department administrators are notified.


Table 2: Types of Data Interface Tables

Direct feed of new data

Corrections of previously entered data

Additions of new data from previous encounters that were overlooked (e.g., downtime)


Having multiple layers of automated notifications is important. If the interface simply generated a traditional “reject report” for problem cases, our administrators would have to manually notify each provider, which is highly time-consuming and error-prone.


This article has illustrated some departmental examples of building and maintaining robust data interfaces that share anesthesiology case data with the other systems and stakeholders. The ways in which we store data regarding anesthesia patient encounters will change in the future and perhaps be improved by migrations to enterprise solutions. The need to exchange that data with others will, however, remain an important task of anesthesia informatics teams, and the principles elucidated by this article are likely to remain valid even as systems evolve.

Patrick J. McCormick, M.D. is an Assistant Professor of Anesthesiology, Icahn School of Medicine at Mount Sinai, New York, New York.


1. Sack K. Researchers wring hands as U.S. clamps down on death record access. New York Times. October 8, 2012:A17. Accessed August 15, 2013.

2. Postel J, ed.; Information Sciences Institute, University of Southern California. DOD Standard Transmission Control Protocol. RFC: 761. Published January 1980. Accessed August 15, 2013.

3. Reich DL, Kahn RA, Wax D, Palvia T, Galati M, Krol M. Development of a module for point-of-care charge capture and submission using an anesthesia information management system. Anesthesiology. 2006;105(1):179-186.

Previous Article / Next Article