Technological advancements have revolutionized not only patient monitoring and therapeutic equipment, but also something as fundamental as the anesthesia record itself. The paper anesthesia record, still in use at more than 95% of U.S. hospitals, has been replaced at some institutions by an anesthesia information management system (AIMS). An AIMS is a comprehensive software application that fulfills the clinical, communication, medicolegal, regulatory, and charge capture roles of the paper record. Given their evolving role, AIMS are increasingly being recognized as valuable anesthesia “devices” that may improve patient safety and process efficiency—going far beyond the role of a paper record replacement.
History of Anesthesia Information Management Systems
The first paper anesthesia records were developed and described by the pioneering surgeons Codman and Cushing in 1894. As surgical medical students assigned the task of anesthetizing surgical patients, they established a wager regarding who could minimize the overall complications experienced by their patients. To that end, each began graphically recording patient vital signs during the operation: heart rate, respiratory rate, and temperature ( Figure 21–1 ). Although it is unclear who won the wager, this seminal effort in anesthesia patient safety reveals a fundamental concept: the anesthesia record’s primary role is to improve patient safety . Initially, this was perceived to be accomplished purely by recording and evaluating the patient’s physiological trend. As a result, some of the earliest efforts were focused purely upon automation of physiological parameter recordings, including a crude yet innovative vital sign recorder that looked similar to a polygraph machine ( Figure 21–2 ). The advent of personal computers in the 1980s was an important turning point in the development of modern day AIMS. Technologically savvy anesthesiologists began to extract real-time digital data elements from the anesthesia machine and physiological monitor and store them on local personal computer storage media. These vital signs were printed out and represented the physiological recording element of a paper anesthesia record.
Next, user data entry devices such as keyboards and proprietary keypads were integrated into the workstation and allowed the anesthesiologist to document elements that could not be automatically recorded using device interfaces: clinical interventions, procedures, observations, and medications. This virtual document combining physiological and device information with user entered elements could then be printed out and replace the paper anesthesia record. This paper record replacement gave rise to the term anesthesia record keeper (ARK) and reflected the state of AIMS until the mid to late 1990s. Beginning in the late 1990s and year 2000, AIMS evolved from paper anesthesia record replacements to true information systems. Leveraging the explosion of healthcare information technology, AIMS began to integrate with other clinical information systems and incorporate more perioperative documents. Most recently, AIMS have developed into workflow management solutions, the source of critical reporting data, and alerts and reminders regarding clinical or administrative elements.
Point-of-Care Software
In general, modern AIMS software can be grouped into three broad categories: traditional client-server, web-based, and handheld. Each type of software implementation leverages a unique information technology infrastructure. The decision to implement a given type of point-of-care software must incorporate cost and functionality criteria.
The first group of point-of-care AIMS software is the ubiquitous client-server architecture. Before the advent of web browsers, most modern software required a variety of files to be installed on each local workstation. These files provided the instructions for how the software should behave, display information, and interact with the user. The primary interaction between the workstation (known as the client) and the location of the patient data (known as the server) was the exchange of data. A balance of duties exists between the client and server computers; hence, the term client-server application . Unfortunately, this type of software provides distribution and maintenance challenges for an institution’s information technology staff. Because most of the instructions for the application’s behavior are stored locally in files on the workstation, the files must be updated on all workstations by the information technology staff. As clinical information technology offerings expand, client-server applications may become victim to unintentional interactions between two applications that share a common file. Updates to the file by one vendor could have an impact on another vendor’s application. However, new management and automation tools allow upgrades to be sent to the client workstations through the network and enable careful version checking for the files shared across vendors. Most importantly, the development tools for client-server software are extremely mature and allow advanced user interface development. They have progressed through multiple generations of improvement and offer a very robust development environment with very detailed control over the workstation itself. Historically, client-server applications have been more capable of leveraging unique point-of-care hardware, such as barcode readers and radiofrequency tags.
Web-based software uses web browsers to perform the display function and stores the application instructions in a more centralized location, known as a web or application server. Rather than distributing instruction files to every point-of-care workstation, most of the application logic is stored on the centralized web server. Ubiquitous web browsers that are already installed on the point-of-care workstation then interpret these instructions from a specific web server. The workstation interacts with the web server not only for data, but also for display instructions, validation rules, and business logic. When a vendor offers software upgrades, files can be updated on only a limited number of centralized web servers. Web software is especially advantageous when the workstations that access the system are extremely large in number or in unpredictable locations. For example, access to an operating room schedule from hundreds of surgeons’ offices may be best enabled by web software. Because the development tools available for web-based software are not as mature as those for client-server development, user interfaces and robustness are less advanced. This drawback is rapidly being mitigated through extensive efforts by the software industry. A more challenging drawback can be inconsistency between the web-browser software and the instructions on the web server. Some advanced capabilities and instructions might require a specific browser version or vendor. In addition, easier access to the application is associated with increased security risk; therefore, security concerns may be heightened.
The latest software tools blur the dichotomy between client-server and web-based applications. Using technologies that maintain a centralized store for the instructions, they also copy software that interprets the instructions to individual workstations. This decreases dependency on the browser vendor and version. Decreased dependency on the browser also enables more advanced user interfaces and complex business logic to be run efficiently.
Finally, some software is designed specifically to run on mobile, hand held devices that have unique requirements for ergonomics, speed, and screen size. The widely variant user interfaces of a desktop computer and hand held PocketPC or iPhone demand that software be designed specifically for the mobile device, even though it might be similar to that run on a desktop. A combination of all three types of software is possible and may actually optimize the speed, usability, and cost of the system.
Point-of-Care Hardware
Most potential customers recognize the importance of choosing the right software model and vendor, and they recognize the difficulty of this task. However, choosing the correct point-of-care hardware remains a very challenging decision that is often overlooked by customers. The workstation bears a number of point-of-care demands. Given the increasing healthcare industry focus on nosocomial infections, the institution’s infection control leadership must review the potential point-of-care hardware. Stationary, mounted hardware must be capable of being cleaned as part of the routine housekeeping process during patient turnover. Typical cleaning agents could harm hardware not designed for the point-of-care environment. Hence, water-resistant keyboards that lack crevices capable of housing infectious materials are often chosen. One should also confirm that the hardware is reliable in difficult environments. Certain clinical situations (burn surgery or pediatric operating rooms) warrant a room temperature outside the typical operating range of a standard workstation.
Although they are mounted, stationary workstations are routinely moved by maintenance and housekeeping staff. Exposure of the equipment to this level of maneuvering should be considered when evaluating the necessary durability. In addition, a small footprint is helpful to minimize the space consumed by the information system in already cramped patient care areas. Finally, regardless of which hardware is chosen, it must be mounted or secured in an economical and effective manner. Although the price of workstations continues to plummet due to the commoditization of computer hardware, simple mounting arms and carts remain relatively expensive items that often surpass the cost of the workstation itself. In addition, the AIMS workstation display can be mounted on either side of the anesthesia machine, each with its own advantages and disadvantages. Mounting on the left side (near the head of the operating table) allows the user to interact with the AIMS display while looking at the patient and surgical field. Theoretically, this enables vigilance and may enable real-time documentation. Alternatively, the AIMS display can be mounted on the right side of the anesthesia machine. Proponents of this ergonomic choice note that the head of the bed is an already-overcrowded area with multiple IV poles, infusion pumps, ancillary monitors, and additional devices. The addition of another piece of hardware near this sterile area exacerbates an existing ergonomic challenge, possibly reducing patient safety. Displays mounted on the right side of the anesthesia machine can be articulated toward the head of the bed during anesthesia induction to enable real-time documentation and then articulated back to a natural position during maintenance of anesthesia. Figures 21–3 and 21–4 demonstrate these two alternative approaches.
Despite these healthcare-specific point-of-care hardware demands, most current AIMS can be deployed on any standard, modern personal computer. However, this flexibility brings with it an overabundance of options. In addition, each point-of-care—advanced testing clinic, preoperative holding room, operating room, offsite procedure site, imaging suite, PACU, ICU, or general care floor—presents its own challenges and opportunities for the information technology department. Potential customers may wish to work with the healthcare-specific division of a general computer hardware manufacturer. Furthermore, vendors’ user groups are invaluable sources of advice and experience that can substantially reduce frustration, cost, and project delay. Unfortunately, access to this resource typically occurs only after installation. Though the highly competitive computer hardware industry offers many pricing options, the initial capital costs must be balanced with the long-term operating maintenance expenses associated with each hardware option.
Many AIMS implementations depend upon the familiar touch-screen user interface of modern physiological monitors. This application paradigm is familiar to many anesthesiologists and may reduce the initial training effort required. In addition, touchscreen-focused interfaces that decrease the need for a keyboard or mouse may be more sustainable in the tight confines of the operating room. The additional space consumed by a keyboard and mouse is valuable real estate competing with other anesthesia devices. However, elimination of the keyboard and mouse often proves difficult because of the stringent user interface demands placed upon software dependent upon a touch-screen user interface. All buttons, scroll bars, and action areas must be “touchable” with a finger rather than stylus or pointing device. Furthermore, since most AIMS implementations also install other applications upon the point of care workstation (enterprise electronic mail, web browser, medical reference), a keyboard and mouse is necessary for these cross-industry applications that do not assume a touchscreen.
Some vendors offer unique functionality that requires vendor-specific hardware. Proprietary hardware such as special keyboards, entry keypads, or syringe pumps can be specialized for the AIMS feature set. Even if proprietary hardware is not required, some advanced functionality could require hardware such as barcode readers or radio-frequency sensors, and a typical information technology department is not familiar with this equipment or comfortable supporting it. The value of the advanced functionality must be assessed in terms of the potentially high initial cost, ongoing maintenance effort, and information technology training requirements. Optimistically, these issues will wane as AIMS and other point-of-care information systems increase their market penetration.
Functional Components of an Anesthesia Information Management System
Much like an anesthesia machine has discrete functional components that work together to create a complete medical device, an AIMS is also a complex system of functional modules and systems working together to create a complete patient care “device.” Consideration of the individual components comprising a complete AIMS allows one to consider the variant levels of functionality available. More importantly, absence of one of these components at a given implementation allows us to consider the impact and capabilities of a given AIMS implementation.
Figure 21–5 is a hierarchical rendering of a comprehensive AIMS. At its core, a modern AIMS is based upon a functioning physiological device interface, intraoperative record keeper functionality for user-entered documentation, basic operating room schedule integration, and some type of outbound rendering of the final anesthesia record itself. The next level of application maturity and functionality is shown in the next concentric circle. This incremental maturity may reflect incorporation of clinical areas upstream or downstream of the operating room itself—the required preoperative anesthesia history and physical (H&P) or compulsory postoperative inpatient visit or outpatient phone call. Alternatively, this advanced functionality may include more comprehensive uses of the intraoperative data such as a quality improvement reporting module or richer user interface such as minor procedure documentation templates.
The most advanced AIMS implementations extend beyond the intraoperative anesthesia period and could be considered perioperative clinical information systems. Postanesthesia care unit nursing documentation, preoperative clinics, preoperative nursing assessments, and comprehensive acute pain service documentation by physicians and nurses are incorporated into some comprehensive AIMS implementations. Alternatively, an advanced AIMS may contain functionality that goes beyond the typical medical purpose of the anesthesia record: automated research infrastructure, preoperative and postoperative patient trackers and workflow managers, and alerts and reminder systems.
Automated Physiological Device Interfaces
Integrating the physiological monitor and device data from point-of-care devices is a critical element of a perioperative clinical information system. The frequent vital signs and device settings collected in the operating room and postanesthesia care unit warrant an efficient means of transferring digital data from these devices to the computerized clinical record. Commonly interfaced devices include physiological monitors, anesthesia machines, gas analysis monitors, and ancillary monitors such as level of consciousness and continuous cardiac output. Less commonly interfaced devices include heart-lung bypass machines, infusion pumps, and digital urimeters.
A fundamental question raised by AIMS implementations is the desired sampling rate of the automated device interfaces . Although the standard of care in paper anesthesia records is the recording of heart rate and blood pressure every 5 minutes (via graphing) and other elements every 15 minutes, an AIMS allows extremely granular data recording. Most commercially available AIMS support recording of continuous values every 15 seconds—far more granular than in the paper record. The vast majority of current AIMS implementations chooses to only store values every 60 seconds for medical record purposes. An important issue raised by this sampling rate is which mathematical function should be used to “filter” continuous data to the desired interval—median, most recent value, or mean. In a paper anesthesia record, this “filtering” is performed by anesthesiologists as they choose to record certain values while excluding others, a process known to be less accurate than an AIMS automated interface.
A second important issue is the management of monitoring artifacts in an automated device interface environment. Artifacts due to clinical issues (i.e., electrocautery interface, noninvasive cuff occluding flow to an invasive arterial catheter) or intervention (arterial blood gas sampling occluding flow to an invasive arterial catheter) are typically ignored by the anesthesiologist when recording values in a paper record. However, AIMS generally do not perform any automatic artifactual filtering due to medicolegal and technical issues. As a result, spurious blood pressures or heart rates may be present throughout the record. Although many anesthesiologists fear a litigious practice environment and the potential liability associated with these values, these concerns are contradicted by actual experience. The illegible, error prone, and interpretation-based paper record may represent a higher risk than automatic recording of completely defensible clinical artifacts. The veracity of the AIMS device data may be its greatest asset and offer legal protection in establishing the true observed physiological parameters during an adverse clinical event. The acuity of perioperative clinical events demands that the anesthesiologist focus on therapy and diagnosis over documentation; as a result, paper anesthesia records suffer from a retrospective documentation limitation that becomes painfully apparent during legal proceedings.
Technical Infrastructure for Automated Physiological Device Interfaces
To enable the remote viewing of waveforms, many physiological monitoring implementations from the leading vendors have included a “monitoring network,” which carries vital-sign information to central viewing stations. These networks can be leveraged to interface device data into the AIMS. Using a centralized interface server, information is copied from the monitoring network to the AIMS database server—the source of the anesthesia intraoperative record data. Because each vendor’s monitoring network uses a slightly different language to transmit the device data, it is critical to ensure that the interface server is capable of interpreting a given monitoring vendor’s protocol. If the physiological monitors already display data from other devices, such as the anesthesia machine, ventilator, gas analyzer, or ancillary monitors, the monitoring network will probably also contain information from these additional devices. Connecting these ancillary devices generally requires some type of integration device in each operating room. In this situation, the interface server may fulfill all of the device integration requirements ( Figure 21–6 , A ).
