Implementation of an Anesthesia Information Management System (AIMS)

Abstract

During the administration of anesthesia, the anesthesia provider has historically created a paper record, charted manually, that included extensive patient care–related data (vital signs, other parameters, etc) and commentaries. DocuSys, a proprietary anesthesia information management system (AIMS), creates an electronic version of the anesthesia record and provides additional information. It electronically captures data from clinical monitors and other sources, including scheduling applications and laboratory computers. The AIMS facilitates chart entries such as drug doses and case narratives. Benefits of an AIMS include improved legibility of the anesthesia record and greater efficiency in documentation efforts. Use of the AIMS assists the practitioner with decision support logic, such as the timing of antibiotic administration and the inclusion of legally required documentation. Upon case completion, the AIMS data are immediately available to other information systems, such as billing and medical records. Data can be made available from a single case or, more important, from thousands of cases to analyze variables such as efficiency of services, adherence to best practices, patient outcomes, and clinical research. The AIMS was deployed at the main campus of the Ochsner Health System on March 26, 2009. In this article, we discuss the issues involved in the AIMS implementation process: the successes, surprises, and continued challenges.

INTRODUCTION

In fall 2008, the Department of Anesthesiology began the implementation of DocuSys, a proprietary anesthesia information management system (AIMS), as part of a comprehensive perioperative information management strategy. The system was deployed on March 26, 2009. This article discusses the implementation process and the issues encountered.

WHAT IS AN AIMS, AND WHAT VALUE DOES IT SERVE?

Historically, anesthesiology has included a manually transcribed, detailed record of the patient's intraoperative course. The record includes both graphic and numerical charting of various parameters, as well as descriptive comments regarding procedures and observations. Ochsner's basic record had remained relatively unchanged for decades. Figure 1 shows an example of a neatly charted paper record. Even in its best form, such a document presents challenges in legibility and accuracy. The anesthesia provider transcribes numerical parameters from the monitors, requiring a considerable expenditure of time for the subsequent charting. In complex cases or with unstable patients requiring multiple clinical interventions, the number of parameters to be documented may increase significantly and there may be a considerable time lag between observation and charting. Immediate patient care must take priority over charting.

Figure 1.

Manually charted anesthesia record.

Figures 2 and 3 show the anesthesia data on the printed AIMS record. Measurements obtained via various monitoring devices are automatically transmitted to the chart in real time with fidelity and clarity. The anesthetist is free for direct patient care and ongoing vigilance while the AIMS charts the vital parameters. The modern AIMS is, however, more than an electronic recording of relevant case measurements and narrative commentary. For example, it can

Figure 2.

Graph/grid anesthesia information management system electronic anesthesia record.

Figure 3.

Narrative commentary report from anesthesia information management system electronic anesthesia record.

• Retrieve and chart relevant patient data from other existing sources such as the surgical scheduling database

• Add software-based logic to provide clinical alerts and prompts so key patient care steps are not omitted

• Transmit case-related data to systems external to the AIMS, such as sending a list of the anesthesia supplies used to the hospital billing department

• Create a database of patient-related information that can be easily retrieved for clinical review, administrative analysis, or research

• Be queried by conventional database tools to analyze patient care, patient outcomes, and operational efficiencies across hundreds to thousands of patient encounters.

The context in which Ochsner decided to acquire an AIMS was partially in anticipation of potential federal mandates that would soon require electronic record keeping except in select circumstances. However, the actual decision was driven by key organizational stakeholders who sought specific benefits from such a system. Prime criteria for selection of the AIMS were

• Benefits to patient safety

• Improved legibility of the anesthesia record

• Expedited transfer of the anesthesia case record to our existing electronic hospital record system

• Improved controlled substance tracking

• Potential facilitation of clinical research

• Need for general administrative tools and reports

• Improved cost management of hospital supplies

• Ease of integration into the existing information systems infrastructure.

While facilitation of professional billing was desired, direct electronic submission was not a criterion for AIMS selection. Existing policies required that a human coder review all professional billing prior to submission for payment.

PRODUCT SELECTION

The Ochsner selection process for an AIMS took place during the calendar year 2007, with a final contract signed in December 2007. The selection team included representatives from Anesthesia, Information Systems (IS), Hospital Management, Pharmacy, and Hospital Medical Records. The team selected DocuSys 7.0 (DocuSys Digital Medical Solutions, Mobile, AL) after examining varied stakeholders' interests and AIMS capabilities for perioperative charting. The scope of the contract included preoperative, intraoperative, and postoperative components. Figure 4 shows the components of the DocuSys AIMS. Full commitment to product configuration, determination of hardware requirements, and acquisition were initiated in summer 2008. The product as purchased contained the following primary modules:

Figure 4.

Anesthesia information management system modules within DocuSys. Components below the horizontal line were part of the initial implementation. Items above the line were not initially implemented because they were in the final stages of product integration by the vendor.

1. PreSurgical Care Management System (PCM) consists of HealthQuestionnaire and PreopPlanner. The HealthQuestionnaire is a web-based patient questionnaire that the patient completes and that is designed to replace a paper questionnaire. Once preoperative personnel verify the patient's answers, software logic in the PreopPlanner uses the information to recommend institution-specific preoperative testing and medical and anesthetic consultations. A report can be generated and communicated to surgeons and primary care physicians by way of a printable summary sent by fax or mail. The verified medical information is transferred electronically into DocuView. The criteria used by the PreopPlanner to recommend further actions are completely configurable and can be selected to reflect clinical best practices for an individual setting.

2. DocuView is a web-based electronic preanesthetic record, designed to replace the paper preanesthetic form containing relevant patient information. In elective surgical cases, the majority of this information is prepared days before surgery.

3. DocuSafe consists of three separate modules that follow the patient's clinical course on the day of surgery from the preoperative area to the operating room (OR) and on to the Postanesthesia Care Unit (PACU). Throughout each of these settings, the charting of patient care takes place in a different design environment, but data flow from each one to the next so that, together, the data become the legal record of the anesthetic encounter.

While DocuSys offered a narcotics wastage station, we elected to use our newly installed Pyxis (Pyxis Corp., San Diego, CA) machines so as not to have duplicate functionalities. Our AIMS implementation process benefited from extensive work done by colleagues earlier in 2008 to deploy the Pyxis system for perioperative medication tracking/dispensing in every OR. That implementation created our basic formulary, gave us interface experience with Pharmacy, and prepared us for the demands of training staff. The installation experience also gave us several potential options for solving DocuSys installation problems.

When we reviewed the implementation process during fall 2008, we decided to separate the implementation of the intraoperative and postoperative day of surgery components from all preoperative components because the preoperative modules were undergoing major redesign by the vendor. Ochsner was to be an early adopter of the vendor's integrated preoperative package of the PCM and DocuView.

In spring 2010, Merge Healthcare purchased DocuSys. This acquisition has resulted in an additional delay in the design and implementation of the preoperative PCM and DocuView modules.

IMPLEMENTATION

Ochsner's Information Technology Environment and DocuSys Requirements

The information technology environment within Ochsner was already well evolved at the project's initiation, including an electronic clinic medical record developed by the institution, Ochsner Clinical Workstation (OCW), and numerous separate proprietary systems dedicated to OR scheduling, laboratory data access, hospital information management, pharmacy support, and other functions. Existing separately from OCW was our hospital medical record, Horizon Patient Folder (HPF) by McKesson (San Francisco, CA), that primarily consists of the paper hospital record scanned as images into an electronic patient record. The sophistication of this process is not in how the data are collected as images but rather in how the images are indexed and retrieved to re-create the paper chart in electronic fashion. At the time of the DocuSys initiation, some hospital electronic information systems (Obstetrics and Cardiology) had recently begun electronically printing images to HPF.

A dedicated IS task force worked with the DocuSys vendor on the equipment acquisition, installation of servers and client computers (PCs), software installation, and network integration. A principal early challenge was determining which existing components were critical to the perioperative process and establishing reliable communication links with existing systems. Decisions about system interfaces with the AIMS used iterative processes of must/should and cost/benefit. Data to be sent to the AIMS included patient identifiers, allergies, scheduling information, and laboratory values, while data to be exported included hospital billing information, supplies usage, and controlled substance usage.

System interfaces were developed in house using our established Cloverleaf Interface Engine (Lawson, St. Paul, MN) and other techniques. The Cloverleaf Interface Engine receives a data request from an application, requests and receives the data from the data source, reformats the data if required, and then forwards the data to the requesting application. Our interface IS support group worked closely with the AIMS vendor to customize the data integration. Systems are increasingly being forced to standardize data formats, so interface issues should become less formidable in the future. Interface issues, however, will probably never entirely disappear.

The DocuSys software and database reside on a secure server networked to multiple DocuSys client PCs (Figure 5). Each PC has the workstation DocuSafe software installed, as well as Capsule Technologies' (Paris, France) DataCaptor. DataCaptor is the intermediate software between the data device (monitor) and the DocuSafe software (Figure 6). It translates the monitor data stream into data that DocuSys can interpret. DataCaptor serves a rather unique role, and several other vendors use it to link their proprietary AIMS software to various monitoring devices. Because this linkage is critical, much preparatory time is spent prior to clinical use ensuring that each data element from the monitor appears, correctly identified, in the electronic record.

Figure 5.

Diagram of Ochsner local area network. PACU, postanesthesia care unit; OR, operating room.

Figure 6.

Integration of patient and equipment data sources by the anesthesia information management system using DataCaptor as the translation software.

All PCs run Windows XP and Internet Explorer 7.0 (Microsoft, Redmond, WA). Installation of the DocuSafe software uncovered some unexpected conflicts with institutional network management and software policies. Most of the conflicts dealt with network security and required software applications for all institutional PCs. The network security issues were ultimately addressed, but the presence of other required software applications was more difficult to resolve between the institution and the vendor. DocuSys specifically mandated the software operating environment for DocuSafe to assure operational stability of the product. While accommodations were made, Ochsner required that software for system maintenance remain on the PCs. Its presence does not seem to have caused any significant problems.

One important application, OCW, could not be installed without conflict. Because viewing the clinic record in OCW was desired, a secure web link was created to allow full access to a browser-based version of OCW. The user can also reach other Ochsner intranet resources. External internet access is also possible through specific approved web links to resources. As staff define external resources of clinical value, additional access can be added. Internet access via DocuSys presents potential problems in that it opens the door to malware. Education, professional integrity, and good network anti-malware software and hardware are paramount to protecting the system.

The Workstation

Figure 7 shows a typical OR AIMS installation. The client PC workstation consists of a basic tower PC, touch-screen liquid crystal display (LCD) monitor, keyboard, wireless Bluetooth barcode scanner, and a serial interface connection to each device that is connected to the DocuSys PC. In general, we required one connection to each patient monitor displaying physiologic data and one to the anesthesia machine for machine-specific data. These specifications resulted in the need for 2 to 3 serial ports on our client PCs. New anesthesia machines that include integrated physiologic monitors require a single serial connection, thus greatly reducing the required hardware and cables.

Figure 7.

Typical anesthesia workstation including (1) DocuSys computer, (2) DocuSys touch-screen liquid crystal display monitor and keyboard, (3) Bluetooth barcode scanner, (4) physiologic monitor display, (5) anesthesia machine display, (6) movable boom containing outlets for anesthesia gases and network connection, and (7) the Pyxis machine.

The keyboard and LCD display are mounted on the right side of the anesthesia machines, above the tower PC. Placing these components adjacent to the main anesthesia monitor at the head of the OR table would have been ideal from a patient observation perspective but proved impractical for mounting and access. Placement of the LCD display and keyboard could be enhanced with more costly mounts, but presently our standard mount works satisfactorily for most users. Despite creative installation, space is cramped in several ORs. The need to have serial cables running into the PC and local area network cables from the PC is a weak link in the process (Figure 8). We move our machines extensively within the OR, so a common problem is a cable disconnect that we readily restore once we detect it. Even unexpected loss of power to the system is readily recoverable because data are stored both on the client PC and the main server. Therefore, uninterruptable power supplies are not required. PACU PCs, which are not used for real-time data acquisition, are wireless laptops.

Figure 8.

Multiple cables at the back of the DocuSys computer.

Workflow

The general workflow for the usage of the AIMS at implementation is shown in Figure 9. Because the preoperative module installation was deferred to a later date, the patient AIMS record is initiated upon opening the chart at entry into the OR using the DocuSafe Intraop Module. For now, all preoperative data remain in the paper configuration. Upon transfer of patients from the OR to the PACU, cases are closed from within the postoperative module using the dedicated wireless PCs. The expectation is that once the preoperative pieces are operational, the electronic charting will begin in the preoperative day of surgery area and will include data collected hours to days earlier into DocuView, either in the preoperative clinic setting or on hospital floors (using wireless tablet PCs). Additional day of surgery preoperative information such as fasting status will be added in the day of surgery units.

Figure 9.

Anesthesia information management system (AIMS) implementation workflow strategy.

The ability to configure aspects of the AIMS product according to institutional needs required a clear understanding of the workflow process that it was to replace. A subset of anesthesiology staff physicians, residents, and certified registered nurse anesthetists (CRNAs) was designated to accomplish this task and became the early adopters of the system, its best educators, and also its troubleshooters. They spent many hours envisioning the desired outcome of the paper-to-electronic transformation. Some of the issues to be resolved included

• What would the electronic record look like on the LCD display?

• What parameters should be recorded?

• At what location on the display should a given parameter be charted?

• What events should be marked by Case Progress Buttons, facilitating time stamps and documentation?

• What should Case Action Buttons contain to facilitate data entry?

• What should be listed in a formulary of drugs and supplies?

• What mandatory data (hard stops) would be required before the case record could be closed?

To resolve these issues, we analyzed in detail our current processes in anesthetic cases and the information created. Appreciating the time-tested logic and efficiency of our existing paper record, we set up the display image of the anesthesia record to look as similar to it as possible (Figure 10). The Case Progress and Action buttons were designed to mirror the typical chronology of case flow and to meet our standard documentation needs. The buttons for case conduct, ie, the buttons on the surgery tab for the intraoperative and postoperative periods (Figures 11A and B), were customizable, but buttons on the other tabs (Figures 11C and D) that perform specific functions were not customizable.

Figure 10.

Anesthesia record as displayed on liquid crystal display monitor. Note scroll bars and expanded content on the commentary at 08:46 as cursor hovers over it.

Figure 11.

Content of buttons on (a) surgery intraoperative tab, (b) surgery postoperative tab, (c) administrative tab, and (d) miscellaneous tab (used to access Ochsner Health System intranet and internet).

The electronic record that would be sent to Hospital Medical Records had to be in black and white, so symbols rather than colors were used to indicate graphed parameters. Color options for the LCD display were used, however, for ease of viewing and for how effectively they would reproduce on a black and white record. Given those considerations, pastel colors had to be eliminated.

At the end of a case, the traditional handwritten paper record is in multiple, similar-looking pages. In contrast, when printed in full the electronic record consists of both graphic and descriptive reports that collate items of like character for easy review. The first report most resembles the paper record, with grid and graphic data (Figure 2) but without narrative comments. The next report groups the narrative comments in chronological order (Figure 3). Most of the comments were originally entered via prescripted DocuNotes (Figure 12) that were selected from drop-down menus and consist of a basic note with internal drop-down choices to add details. These basic notes can be easily annotated by the addition of free text, giving the user complete control for accurate documentation. Additional electronic reports present timed lists of drugs and fluids given.

Figure 12.

DocuNote screen with drop-down box showing selection choices for mask ventilation.

We collaborated extensively with Medical Records to select the required reports and define their final format. Satisfying The Joint Commission, Medicare, and other legal requirements for documentation was an absolute necessity. Fail safes were created to prevent inadvertent case closure and submission of an incomplete chart to Medical Records. For instance, the record cannot be submitted if any of the following is missing: legal attestations, selected surgical information, selected anesthesia information, or patient identifiers. The software allows for not only electronic submission but paper printing as well. Two concerns are relevant, though. First, the electronic record is not environmentally friendly. The printed report, accessed from the administrative tab (Figure 11C), is many pages longer than its former paper chart counterpart. Therefore, documents are printed only as required clinically for communication, and the printed report contains a subset of those reports electronically submitted to Medical Records. Second, the printed documents are clearly printed with the label NOT FOR THE LEGAL MEDICAL RECORD to ensure that they are not manually scanned into HPF, as is the custom with our paper records.

Based on the user reviews, we easily identified elements of the AIMS process that could not be altered to match current practice and made educational plans to address these changes in practice. One such issue was how additions, amendments, or edits are made once the electronic record is closed, rendering alteration of the record impossible. Our solution was to write any addenda onto a blank copy of our current paper record and submit it to Medical Records to be scanned into the HPF patient file.

Our expressed concerns about some elements of the software resulted in our receiving an interval upgraded version of the software from DocuSys (version 7.1) prior to implementation that addressed many of our concerns. By spring 2011, we expect to have the next major version (8.0) installed, and with it, to address several ongoing deficiencies, including the mechanism for amending a closed electronic record with an appropriate audit trail.

Product Roll-Out Phase One: Training

After the preliminary configurations of the system were completed and interface requirements were met, introduction to our department began. In-service trainings were held over 2 months. Each training session included a full demonstration of the intraoperative and postoperative modules over 3-4 hours with 4-8 attendees. The resources required to support these sessions represented a major cost to the organization. A single staff physician conducted all sessions to standardize the teaching process and to facilitate a more rapid integration of users' suggestions and concerns into the final product. Specifically, end-user training input had substantial impact on the content of DocuNotes and case closure hard stops, drug tracking and wastage, and the strategy for paper record usage. A paper record would always be available if the AIMS were not operational or not available, as in anesthesia locations outside the main ORs.

A topic of concern was how to edit incorrect data and times, understanding that the electronic record contains an internal log of all changes to the record. Any edits to the record that could potentially cause misinterpretation of the motivations behind the edit would best be commented on in the chart narrative. For example, a delete function exists so artifactual data can be removed if other data surrounding the time point support the change. If supporting data are not present, the data are best left as displayed with explanatory notation about the error.

A similar issue for deliberation was the timing of entries. The anesthesia provider frequently charts the traditional paper record retrospectively because of time constraints during the case. The electronic chart also allows for retrospective charting of comments. Each entry into the electronic record is marked by the time when it was entered. However, editing the time stamp is justified and desirable to accurately indicate when an event occurred. In other instances, commentaries do not require linkage to any particular time, so the time stamp upon data/commentary entry is appropriate. In some scenarios, altering a time stamp might be construed as trying to misrepresent the course of events. In those circumstances, the original entry time stamp should remain and the note include reference to the time when the event actually occurred.

In general, data and time stamps are edited when appropriate. Improvement in our use of the system has led to fewer required edits. The anesthesia provider is at all times responsible for the information being recorded, including manual charting in the event of equipment error or failure.

Product Roll-Out Phase Two: Practice in OR and Mock Implementation

Once trained, all anesthesia providers had access to operational test systems in many of the ORs. These systems could be activated and used along with our paper record, which remained the legal document during this phase. Much troubleshooting occurred during these days. Mock implementation occurred as an explicit event over several days with vendor support on hand. Anesthesia providers were expected to produce both paper and electronic charts in all cases where feasible and to compare the records for accuracy. Such duplicated charting and record comparison was the most significant operational burden on our staff.

Although the expectation at the mock implementation was that all systems would be operational, the reality fell short in several areas:

• Narcotic tracking and wastage

• User log on

• Image quality of the printed electronic record

• Accuracy of the surgery scheduling interface

• Difficulties with wireless units because of conflicts over dynamic versus static internet protocol (IP) addresses

• Incomplete allergy data from the pharmacy database.

The narcotic tracking challenge almost stopped the implementation. DocuSys had to be able to directly communicate with Pyxis to facilitate the reconciliation of all federal- and state-controlled drugs, primarily narcotics. In other words, controlled drugs that Pyxis vended to a provider had to be fully accounted for in DocuSys as administered to the patient. The DocuSys software could not accept Pyxis data directly. The DocuSys solution was to have Pyxis send information regarding vended, wasted, and returned controlled substances to a newly created drug reconciliation database on the DocuSys server. Through an intranet web link in DocuSafe, the user could readily view the Pyxis information. While not as easy as having the Pyxis data appear directly adjacent to administered drugs on the AIMS record, being able to manually compare the information was a reasonable solution. After case closure, DocuSys sends its data to the same reconciliation database. An automated report performs departmental audits of the reconciliation database daily. Any drug discrepancies are dealt with immediately. The new version of DocuSys will allow for direct data communication with Pyxis and side-by-side review of controlled substance administration, vending, and wastage.

DocuSys required the use of Windows Active Directory for provider log-on identification names and passwords, which initially created confusion because Windows Active Directory was not in general use institutionally. All providers had to obtain a unique log on for the DocuSys PCs. Recently, all clinical computer access was changed to Windows Active Directory, and a uniform password is now in use.

All of the above issues were solved prior to full implementation except for the incomplete allergy data from the pharmacy database. This issue was difficult because DocuSys used a newer version of allergy coding than the hospital pharmacy system. Institutional allergy codes were in the process of being upgraded, but this upgrade was not in place for implementation. Patient allergies were traditionally tracked across clinic and hospital encounters by the allergy card function in OCW. Thus, while the potential functionality of the DocuSys automatic allergy alerts was missing, clinicians still had documentation of patient allergies from the OCW source.

Product Roll-Out Phase Three: Live Implementation—March 26, 2009

The project went live several weeks after the mock implementation under a set of conditions designed to facilitate its acceptance, optimize the system's performance, and maximize patient safety. The initial implementation was restricted to the 22 main ORs to assure availability of adequate support staff in the ORs and in the PACU. Because case completion and closure occur in the PACU, the PACU was a major site for staff education and expert case audit prior to closure. Select staff were positioned there to review and assist in case closure. During the implementation, all providers were encouraged to use the AIMS on all cases, but not using it because of special case circumstances was also acceptable. Consequently, very short cases and emergency cases were frequently done as paper records. This strategy allowed the anesthesia provider the ultimate control of the process for best patient care and efficiency during what was clearly a learning experience. This approach reduced the anxiety associated with implementation.

OPERATIONAL ISSUES

As of January 1, 2011, we have performed more than 28,400 anesthetic cases using the AIMS. In general, the system has performed well, with only occasional isolated in-room failures associated with cable or power disconnects. The need for equipment maintenance has been minimal. The LCD monitors are cleaned using the same methods as other monitor screens, and the keyboards are protected with special plastic covers. The stability of the hardware in a rather hostile environment has been excellent. The system servers have been down only for scheduled maintenance and upgrade events. Vendor support has been required primarily for database and interface issues. Except for reporting issues, other database issues have primarily involved user error in recording incorrect patient information. The most dramatic interface dilemma was the discovery that the automatic backup of some of our longer cases occasionally exceeded the maximum size allowed by the DocuSys software backup protocol. We discovered this backup issue when we found that chunks of data were missing from the database. However, because of system redundancy, the missing chunks of data existed on the original client PC. The vendor resolved the issue with the DocuSys backup limitations.

From a patient safety perspective, adverse drug alerts have not been fully implemented. Activation of these alerts requires entering the administered drug into the AIMS prior to the drug's administration to the patient and also requires that the patient's concurrent medication and allergy data are already available to the software. During the early implementation process, neither patient allergy nor medication data sources were electronically available. This led to continuation of the preexisting paper charting practice wherein drug administration is frequently charted following the actual administration. Practitioners are aware of patient allergy data but do not benefit from additional software oversight. Although patient allergies are now included in the database, old behavior may still prevail, with the practitioner entering the drug into the system following drug administration.

As an alternative to direct manual entry of drugs, drug selections can be scanned into the system from a barcode list at the anesthesia workstation (Figure 13). When fully implemented, scanning will offer a more efficient way to enter drugs into the AIMS prior to administration to the patient. Although a wireless Bluetooth barcode reader for drug administration is available in every OR, it is not yet in routine usage. This limited usage is primarily because of technical and training issues associated with

Figure 13.

Wireless Bluetooth barcode scanner and barcode anesthesia drug quickpick list.

• Misplacement of the wireless unit in the charging cradle, resulting in loss of charge

• Difficulty with creating readable drug list barcodes

• The initial lack of allergy data at implementation

• The ongoing lack of documentation within the DocuSys database of the patient's medications taken on a routine basis.

The first 3 items have been addressed. The final concern awaits the implementation of the preoperative modules that will include all patient medications. In the future, use of the wireless barcode reader is a high priority. The entry of a drug into AIMS prior to the drug's administration is critical to accrue the full advantages of AIMS decision support.

The development of the controlled substance tracking solution (the daily reconciliation report) created an unexpected consequence. Pharmacy had lobbied hard for this feature because for many years, the OR drug audits have been done manually. Pharmacy's support of the DocuSys project hinged on the requirement that controlled substance reconciliation be an integral part of case closure (a hard stop) and that the Department of Anesthesiology assume the primary role for auditing all cases. After implementation, Pharmacy would audit the auditors as needed. Although we have now become much more efficient in the audits, immediately after implementation all cases required considerable time to audit and communicate with practitioners as necessary regarding drug discrepancies. The time and cost associated with drug reconciliation were not primarily the result of any issue with DocuSys, but rather the result of a major change in our workflow.

Another operational issue has been the maintenance of the client PC software. Upgrades to the basic DocuSafe application have to be sent to all 50+ client PCs. As we used the system, we defined sets of new DocuNotes that needed to be available at the client PCs. The process of updating the software at each PC requires diligence and accuracy. We now have a dedicated IS support individual who performs these upgrades.

ACCEPTANCE

While anxiety over the transition to an electronic medical record was expected, our group's concerns seem to be a reasonable demonstration of what other groups might experience. Our group is large (30+ physician staff, 18 residents, and 50+ CRNAs), diverse in age, and varied in computer skills. In general, the acceptance has been excellent, and users routinely complain when the system is down in their OR. In the months since implementation, the intraoperative use of the AIMS has expanded rapidly to include most cases where the equipment is relatively fixed (main ORs, obstetrical ORs, and outpatient surgery ORs). We have also recently gone live at another hospital with 3 ORs. Providers now regard paper charting as inefficient and far prefer the electronic record. This preference does not seem to be case or provider specific. Presently, DocuSys is not used in peripheral areas where anesthesia machines do not reside permanently and require transport. Newer anesthesia machines on order should facilitate use of the AIMS, even in peripheral areas.

BENEFITS OF THE AIMS SYSTEM

Documentation, Decision Support, and Reporting

During the basic configuration of the software, we could determine hard stops required for completion of the chart. We have used hard stops to ensure that all legal attestations are made, that the practitioner has fully accounted for the use of certain drugs, and that various other activities have been documented as complete, such as an electronically signed attestation documenting staff anesthesiologist presence for intubation.

Narrative DocuNotes were created to meet desired documentation requirements, and selected ones can be made mandatory. For example, the transfer of patient care from one provider to another has been identified as a potential high-risk event for the loss of key elements in case information or strategy. We created a note that the first provider must complete when transferring care. The note prompts communication about patient status, comorbidities, airway issues, plans for postoperative care, etc. This note is not a hard stop because this event does not occur in all cases. Database reports can audit the use of this note to ensure that it is used appropriately. In contrast, to meet Pharmacy's drug reconciliation needs, viewing the Pyxis controlled drug data and placing a note of verification were made a hard stop required for case closure.

Numerous possibilities exist for software-based logic to encourage specific best practices. Monitoring alerts can be triggered when a selected parameter exceeds limits, thus encouraging an appropriate action. As an example, a patient temperature below a set minimum triggers an alert suggesting the use of warming devices. Allergy alerts are triggered if a drug to which the patient is allergic is entered into the system prior to administration. The content of descriptive notes can be selected to encourage appropriate actions and documentation of these actions. The software recognizes antibiotic drugs and understands that the routine best practice is to give the antibiotic prior to the surgical incision. Thus, when the provider presses an Anesthesia Ready time-stamp button prior to pressing the Surgical Incision time-stamp button, the system checks whether an antibiotic has been given. If not, the system prompts the provider to give an antibiotic at that time or explain why one will not be administered. This alert and the audit feedback reports generated have led to a dramatic improvement in our performance on the Surgical Care Improvement Project 1a metric, regarding the timely administration of antibiotics prior to incision. A second antibiotic alert appears when one should consider redosing a particular antibiotic, based on each antibiotic's recommended dose interval.

Additional built-in decision support in the current software includes protocols relating patient obesity (body mass index) to potential obstructive sleep apnea and to the risk of deep venous thrombosis based on type of surgical procedure. Future versions of the software will allow anesthesia practices to configure their own additional protocols, triggered by specific patient and clinical data.

The availability of thousands of data elements associated with each case allows for extensive data analysis and reporting on individual cases and groups. Data analysis depends on the data collected (as determined in the configuration process), the database structure, and the reporting tools used. DocuSys currently uses Microsoft SQL 2005 Express to allow us to run predefined reports and perform ad hoc queries of the database. The vendor provides numerous management reports as well as quality measures and can create special reports, such as those related to performance and quality of care metrics. Figure 14 shows a report designed to identify the frequency with which staff use the measurement of end tidal carbon dioxide as confirmation of appropriate airway ventilation after they induce general anesthesia. Such vendor-supplied reports require anticipation of need and time to develop, and they are rigid once written.

Figure 14.

Performance measure showing the use of end tidal carbon dioxide (ETCO₂) to monitor airway ventilation after induction of anesthesia.

Database users can run ad hoc queries, with the assistance of our in-house IS staff if needed. These reports represent a less rigid and more spontaneous reporting process. For example, we might examine which patients required intubation using a video laryngoscope (glidescope). This item appears as a selection in the DocuNote describing intubation. These patients could be further analyzed according to provider, etc. Ad hoc queries allow for maximal spontaneous interrogation of the database but also require a thorough understanding of the technical structure: what is stored in the database, where it is stored, and how database tables relate to each other. Our use of ad hoc reporting has not been as successful as we originally expected. Usage has improved, though, with dedicated in-house IS support and vendor revisions to the database structure.

Practice Quality Measures

A single clinical encounter between a provider and a patient, viewed alone, can represent quality of care and efficient practice; however, performance manifested over hundreds of cases is more representative and revealing. As a group practice, we have established various measures to monitor our practice and our practitioners. Adherence to the antibiotic performance measure is one example and can be reviewed across all practitioners and case types, creating opportunities for quality improvement. Similarly, the appropriate and timely use of various monitoring techniques, such as end tidal carbon dioxide monitoring, can be followed as patient safety and practitioner performance measures. Since 2000, new individuals certified by the American Board of Anesthesiology must recertify every 10 years. To maintain certification, these professionals must report measures of clinical practice quality. Such data can be extracted from these types of cumulative AIMS practice reports.

The AIMS allows Ochsner to aggregate clinical data for submission to the Anesthesia Quality Institute (AQI). Ochsner is one of a few academic institutions submitting this type of information through an AIMS. For most practices, data come from billing and other hospital databases. Participation in the AQI will not only enable professionals to readily document their practice but will allow individuals and groups to benchmark their performance against larger aggregates of practitioners. Federal agencies are increasingly seeking such documentation and basing payment partly on participation in these activities.

EXPECTATIONS MET AND EXPECTATIONS YET TO BE FULFILLED

In general, DocuSys has met intraoperative expectations. It has proven to be an easy-to-use and stable clinical platform. Unmet issues have resided primarily in the ease with which reports can be run using the database. The vendor has identified database reporting as a problem, and the new version of the software will include significant changes to reporting services. The new version also contains other significant improvements, such as mechanisms for editing a closed record. We also look forward to the integration of the preoperative workflow.

The introduction of the AIMS to our department has been a transformative event that has put us on a journey to improve the documentation of what we do, to understand better how we do it, and to share data across thousands of patient encounters to provide the foundation for future improvement in patient care.