Chapter 29. Perioperative Information Management Systems

1. Perioperative information management systems (PIMS) are software systems that manage the documentation, workflow, and charge capture of the operating room (OR) environment. PIMS are composed of two main components: anesthesia information management systems (AIMS) and operating room management information systems (ORMIS).

2. AIMS have been shown to improve processes of care. However, the expense and effort of implementing these systems has prevented widespread adoption.

3. Point-of-care software and hardware are available in many different forms. Each has its advantages and disadvantages. Ultimately, the institutional leaders need to decide on the best fit for its users.

4. Functional components of AIMS include automated device interfaces, user-entered documentation, decision support capabilities, charge capture, and reporting capabilities.

5. Functional components of ORMIS include clinical documentation, process reporting, OR scheduling, resource management, and patient tracking.

6. AIMS and ORMIS need to be configurable systems to account for changes in practice patterns, new regulatory requirements, and updates in medical technology.

7. AIMS need to integrate with hospital-wide electronic medical records (EMRs). The anesthetic record needs to be available for viewing as part of the medical record, and anesthesiologists need to view enterprise patient information in the perioperative environment while using the AIMS.

8. Institutions need to have disaster preparedness strategies including data redundancy plans to account for failure at each level of software and hardware architecture.

9. PIMS vendors will continue to add new features and functionality to their systems. Exciting opportunities lie in the standardization of content and ability to aggregate and analyze large amounts of clinical data.

Information technology is rapidly altering clinical practice. Health care providers interact with, and depend on, electronic medical information every day. From humble beginnings as extensions of billing and registration systems, newer clinical information systems are designed to allow management of clinical workflow, and in best cases, improve the quality of care delivered to our patients. There is ample evidence that perioperative information management systems (PIMS) can improve documentation accuracy, clinical compliance, process-of-care measures, and even improve operational efficiency. However, there are still detractors who feel these systems hamper the clinician's ability to focus on the patient. Although the adoption of PIMS has been slower than expected, the number of successful implementations is clearly increasing, and many departments that do not have systems are in the process of implementing. More than just documenting care, AIMS customers are using the immense amount of data generated to better understand perioperative medicine and develop practices that improve the quality of care. They are also providing feedback to the commercial vendors of these systems that are resulting in improvements in usability and functionality. PIMS have 2 major components: anesthesia information management systems (AIMS) and OR management information systems (ORMIS). AIMS are software that anesthesiologists use to document perioperative care of the patient. OR personnel use ORMIS to schedule surgical procedures, track resources, and document clinical care and billable items. This chapter introduces the functional components of PIMS. It also explains how these components work together and why they are important to the practice of perioperative medicine.

An automated intraoperative anesthesia recording machine was described by McKesson in 1934.1 This device recorded tidal volume, fraction of inspired oxygen (Fio2), and blood pressure and represented one of the first attempts to reduce the manual transcription of physiologic parameters. Later, Piepenbrink et al described the use of video recorders to document all the information available to the anesthesiologist as the intraoperative record.2 Despite these bold yet unsuccessful attempts, paper has endured as the medium of choice to document the perioperative experience. Modern anesthesia information systems initially attempted to replace the paper record primarily by functioning as intraoperative record keepers. They captured physiologic data from the clinical monitors and recorded them in the anesthetic record. These electronically captured data were supplemented by manually entered information to complete the intraoperative record. Over time, these systems have grown from merely intraoperative record keepers to perioperative information management systems (PIMS). These systems now enable electronic documentation of the entire perioperative clinical experience: preoperative, intraoperative, and postoperative care. They also allow users to view historical patient records and help users track patients throughout their perioperative stay. As these systems have moved from functioning as intraoperative record keepers to workflow managers, departments have started to appreciate benefits in billing, compliance, quality assurance documentation, as well the expected benefits in legibility, availability, and clinical research. The impetus to increase the breadth and depth of functionality in PIMS came from several sources. First, more sophisticated hardware and software allowed electronic capture of more parameters from medical devices. This in turn allowed for less manual transcription of information and greater user acceptance of PIMS. As data interfacing became more secure and prevalent, users developed more confidence in the reliability of transmitted variables. Second, as the anesthesiology departments started to understand gaps in the systems, they worked with the PIMS vendors to develop features that allowed for comprehensive workflow management. For example, preoperative clinic, quality assurance, and postoperative care modules were integrated with the intraoperative record keepers. Finally, hospitals began recognizing the important fiscal role of the OR. ORs generate a significant proportion of the health care enterprise's overall profits, and small changes in perioperative anesthesia processes may lead to large changes in revenue collection. As a result, PIMS began to incorporate more billing functionality.

As AIMS have become more prevalent, users have begun to use them as agents of process improvement. Examples of process improvement features include required documentation elements and case documentation templates that allows users to deliver more consistent care for similar patients and procedures. As PIMS have become integrated with other hospital systems, redundant documentation has been reduced, clinical efficiency has been improved, and documentation accuracy has increased. The integration of preoperative and postoperative care documentation with the intraoperative record keeper has created a comprehensive perioperative record. This has not only allowed for a longitudinal view of the patient's perioperative course but also enabled information to flow more seamlessly.

Billing processes have also demonstrated enormous improvements with the implementation of PIMS. The creation of a legible record, requiring important billing elements to be completed, and electronically transmitting the record to billing departments has streamlined billing processes. Adverse events documentation, long underreported with paper systems, has become more closely integrated with clinical workflow when included with a PIMS. In the most comprehensive implementations, PIMS have become workflow management tools, allowing clinicians to document their entire experience with the patients while improving processes for critical ancillary functions such as billing and quality assurance. Other implementations are much more limited, suggesting that although PIMS have great potential, much improvement in the software, ease of implementation, and affordability needs to be realized (Fig. 29-1).

Software systems used in the perioperative environment come from a variety of commercial vendors. However, they can be grouped into 3 broad architectural categories: medical devices, client/server, and Web based.3 AIMS that are part of the anesthesia machine or physiologic monitor are labeled as medical devices. The software user interface is incorporated into the device. For example, the AIMS may be accessed through the physiologic monitor screen or a monitor on the anesthesia machine. Advantages of this model include reduced probability of error with the recording of hemodynamic parameters. Also, because the user interface of the device is familiar to the clinician, adoption of AIMS may be easier. However, medical devices are more rigorously regulated than medical software. Although this may improve the reliability of the software, new features may take much longer to develop and incorporate.

The second category is the traditional client/server. In this model, software files are installed on the local workstation. These files provide instructions on how the software should interact with the user. The files on the workstation (also known as the client) primarily interact with a central computer housing patient data (the server) by exchanging patient data and user requests. Client/server software is developed in one of two ways: "thick" or "thin" client. A thick client typically provides significant functionality independently of the central server. The name is contrasted to thin client, which describes a computer heavily dependent on a server's applications. A thick client still requires at least periodic connection to a network or central server but is often characterized by the ability to perform many functions without that connection. In contrast, a thin client generally does as little processing as possible and relies on accessing the server each time input data need to be processed or validated.4 Client/server software maintenance can be very resource intensive for hospital information technology (IT) staff because of the need to update all individual workstations every time there is an update in the client software. In addition, files loaded on the workstation are susceptible to interactions with files from other programs with unintended consequences. Fortunately, advanced system management and automation tools can allow for quick distribution and installation of upgrades to workstations. Although a dichotomy between "thick" and "thin" client has been described here, the implementation reality is a continuum with systems being identified as close to one extreme or the other.

The advantages of thick clients are as follows:

• Fewer server requirements. Because the point-of-care computer is doing much of the application processing, the thick client server does not need the level of performance of a thin client server. This allows for less expensive servers to be used.
• Offline or downtime working. If the central server is down, clinical care can still be documented on the point-of-care computer. When the central server goes back up, the data can be synchronized.
• Better user experience. Thick clients typically allow for a richer user experience because many of the features are in the point-of-care software (and not on the server) and therefore not dependent on network bandwidth, which can be variable.

The advantages of thin clients are as follows:

• Data not stored on local workstation. Because the server contains all of the data, possibility of loss of data becomes confined to relatively few servers, instead of the many computers located at the point of care.
• Less expensive point-of-care hardware. Although the server needs to be powerful to handle the processing load, the point-of-care computer typically needs to be much less powerful than for a thick client. Less expensive hardware in the ORs, where computing equipment may be easily broken or stolen, could lower overall system costs.

Web-based software uses Web browsers to display the user interface, and it stores the application instructions in a central computer known as the Web server. Software upgrades are limited to only the Web servers. The workstations are spared because it is only used to house the Web browser. This model is extremely advantageous for large workstation deployments in multiple locations or when the software needs to be accessed remotely. However, user interface development tools and capabilities are currently less mature for Web-based software than client/server, so the interaction between the clinician and software is less robust. In addition, the software may be optimized for a particular Web browser (ie, Microsoft Internet Explorer) and be incompatible with others (ie, Mozilla Firefox). The reality is that currently the lines are blurring between client/server and Web-based models. In addition, combinations of all 3 categories of point-of-care software are possible and may be used to optimize the user's experience and resource requirements of hospital IT staff3 (Table 29-1).

Point-of-care hardware the workstation or medical device that the application is accessed from, including the keyboard and monitor, and also the mounting equipment used to house the hardware. Several considerations go into choosing the appropriate hardware for each clinical setting where the software is being used.

1. The hardware should be ergonomic. Mounting equipment should have adequate range of motion to allow the user to interact with the software and simultaneously take care of the patient. Keyboard should be adjustable.

2. The hardware should be compliant with hospital infection control guidelines. Typically, the hospital's infection control team will review all the equipment.

3. The hardware should be durable. It should be resistant to water and other spills, and usable in a variety of temperature settings. The hardware should also withstand the usual "bumps and bruises" of the OR.

4. The hardware should be procured in an economical manner. Workstation prices are continually dropping, and typically the hardware purchase is one of the last purchases in an implementation to take advantage of the downward price trajectory of computing equipment.

5. The hardware should be usable in multiple environments, or the hospital should be able to buy equipment specific to each area that the software will be used.

A few vendors require vendor-specific hardware, either workstations or special keyboards, bar code scanners, or even syringe pumps. Hospitals should evaluate the usefulness of each of the specialized hardware against cost, support, and training issues (Table 29-2).

Although each of the commercially available systems has its own set of features and functionality, the most successful systems have enough breadth of functionality to serve the needs of clinicians, billing staff, and quality improvement groups. The core functional components include:

• Automated physiologic device interfaces
• User-entered documentation
• Staff and billing documentation
• Alerts and reminders
• Anesthesia history and physical
• Reporting for quality improvement, compliance, or research purposes

Automated Physiologic Device Interfaces

Among the most critical feature of AIMS is its ability to interface data automatically from the medical devices into the intraoperative record. Interfaces are software and hardware that allow one system to communicate with another. Without device interfaces, the user would be required to manually type in all of the physiologic data into the system to create the anesthetic record. User acceptance would be limited. In addition, intraoperative records generated by AIMS with device interfaces have been shown to be more accurate that handwritten records and therefore more useful for review, research, and quality improvement purposes.5

In terms of the physiologic parameters that are interfaced from the monitors to the AIMS, a "more is better" philosophy predominates. Although not always possible for technical reasons, every device that records physiologic information should be able to send the information to the intraoperative record electronically. Devices commonly interfaced to the AIMS include physiologic monitors, anesthesia machines, ventilators, bispectral index sensor (BIS), and continuous cardiac output monitors. Less commonly interfaced devices include heart/lung bypass machines and infusion pumps. Table 29-3 lists many of the commonly recorded parameters by devices found in the anesthesia cockpit. Basic hemodynamic variables such as blood pressure, heart rate, and pulse oximetry must absolutely be interfaced. Other useful parameters include gas analyzer data, such as inspired and expired inhalational anesthetic concentrations, Fio2, and end-tidal carbon dioxide. Ventilator data such as tidal volume, respiratory rate, and peak pressures should also be sent to the AIMS.

Physiologic device interface implementations typically leverage existing monitoring networks that were created to provide a central viewing area for waveforms (such as ECG) and vital signs from multiple locations. The physiologic device interface server copies information from the monitoring server and places it into the AIMS database. If the physiologic monitors also display information from other devices (such as BIS) and that information is transmitted over the monitoring network, then the interface server can copy information from these other devices as well. If there are devices that are not connected to the monitoring network, the data from those devices must be copied into a local processing device (usually a workstation). This workstation then sends the patient information to a central database server, which then copies it into the AIMS. If there is no monitoring network at all, then all devices must interface to the AIMS at the point of care. Then, all patient information is sent from the client to the server.

Each device may have its own communication protocol with the network. With new devices arriving with increasing frequency to the health care market, the ability for an AIMS vendor to create interfaces with every device can be extremely difficult and expensive, and many have chosen to outsource this work to specialized interface vendors.

Data Interfaced from Physiologic Devices

Data recorded in the physiological monitors can be either intermittent (eg, noninvasive blood pressure readings) or continuous (eg, pulse oximetry saturation [Spo2] or invasive arterial blood pressure). For both intermittent and continuous data, there needs to be clear understanding between the user and vendor on how information is captured by the AIMS. For example, if noninvasive blood pressure is set to cycle at 3-minute intervals, then the expectation is that the AIMS will capture each noninvasive blood pressure reading. In contrast, continuous parameters are interfaced at defined intervals that allow an accurate representation of the patient's clinical condition but do not overwhelm the AIMS with data. For example, sampling the Spo2 every minute may be appropriate; however sampling every second may be information overload. Currently, no standards have been defined for the frequency of data capture. Each AIMS typically has its own algorithm for data capture from physiologic monitors, and institutions should be aware of the data capture interval and algorithm for its system.

Pitfalls of Device Integration

Artifact

Data artifact can come from a variety of sources such as manipulation of the device (movement of a noninvasive blood pressure cuff), electrocautery, and flushing of an arterial line. Clinicians using paper documentation account for these occurrences when noting vital signs and typically filter out the spurious values. Most AIMS allow the user to annotate the spurious data and remove it from the AIMS display. Although programs with algorithms designed to recognize artifact and annotate clinical records have been described in the literature, they are not in widespread use.6,7 Institutions with AIMS have found that users manually edit interfaced data (especially pulse rate, pulse oximetry, and blood pressure) in a significant number of cases.8 Whether this is due to data artifact or other reasons is not entirely clear. However, clinicians using paper documentation have a tendency to artificially smooth out real variations in hemodynamic parameters. AIMS makes this tendency more difficult to carry out, but it does not completely eliminate the ability to artificially reduce variation.

Data Loss

When devices are interfaced to the AIMS, the expectation is that the interface will work 100% of the time. In reality, there may be cases when the interfaces are down due to network failure, maintenance, or some other reason. For these instances, AIMS and hospital IT departments typically have a warning system (alert on the screen or automatic page that immediately notifies users of this (hopefully) rare occurrence. In addition to inciting user frustration, failure to recognize loss of data may increase medical liability.9 Manual input of data or temporary reversion to paper documentation is the most common backup plan.

Complexity

Ideally, interfacing between devices and AIMS would be as simple as plugging in all the necessary cables and clicking Start. Unfortunately, medical devices use a range of communication technologies protocols (RS232, RS485, 802.11, IrDA). As updated models are released, they may have slightly different software loaded on them. Each of these models has to be interfaced to the AIMS. Moreover, clinical information requires a completely safe and secure exchange of data. Safeguards to ensure that the interfaces are reliable to health care standards add a considerable amount of cost and complexity to interfacing projects.10 The device industry and health care professionals have realized the need to improve communication between devices and systems. Integrating the Healthcare Enterprise (IHE) is an initiative that promotes the use of established standards. IHE has created protocols so that systems developed using IHE guidelines communicate better with each other and are easier to implement. Increasing use of these interoperability guidelines should help reduce the cost of interfacing and increase adoption (Table 29-3).

Technical Infrastructure for Physiologic Device Interfaces

The network used to transmit all the information gathered from the devices must be robust, reliable, and secure. Each hospital must perform an accurate analysis of its network before implementing an AIMS. Networks with relatively poor reliability may need a system that supports storage of clinical information locally. Other institutions that have a more reliable network may not need such redundancy. Hospitals and vendors also need to agree on how clinical data streams will be separated from other applications on the network. Options include a separate physical network or a virtual private network.3

User Entered Documentation

Preoperative Record

A thorough history and physical completed in a timely manner allows for optimal care of the patient and minimizes delays in starting cases. In most instances, the preoperative process starts at the surgeon's office, where the initial history and physical is completed and testing is ordered. Then the patient is evaluated in advance (phone triage, preoperative testing clinic) or the morning of surgery, where the anesthesiologist first views the patient's health information. Well-designed preoperative modules of AIMS are able to manage the multiple scenarios in which preoperative information in collected. In comprehensive implementations, much of the information for the history and physical is collected from other sources including previous anesthesia history and physicals, and it is presented to the anesthesiologist for review. The anesthesiologist can then spend less time collecting information and more time analyzing it to produce a safe anesthetic plan (Fig. 29-2).

Preoperative documentation can be divided into several categories:

1. Patient demographics: examples include name, gender, and date of birth. This information is usually interfaced from hospital registration systems or OR scheduling systems and rarely entered manually

2. Preoperative testing: laboratory results, ECG, x-ray, echocardiography. Interfacing of preoperative testing data is highly variable among implementations and depends on a number of factors, including the technical ability of the testing systems to interface with AIMS and vice versa. More important is the model of patient care. If the preoperative testing is done at a facility completely unrelated to the OR facility, then it may not be possible to exchange information electronically because systems in unrelated facilities rarely communicate with each other.

3. Allergies and medications: includes reactions of each allergy and last time that each medication was taken. This information is typically collected by nursing staff or is available from previous visits. If the information is automatically captured from other sources, then the anesthesiologist must verify before completing the history and physical. If not, then the system should be designed to easily input allergies and medications.

4. Past medical history and review of systems: includes previous surgeries and problems with anesthesia. Usually follows a systems approach. If manually entered, then systems typically provide multiple methods to input the information, selecting from a list of choices, typing information into a text box, or choosing a default option (eg, "within normal limits"). If the AIMS has the ability to capture information automatically that was previously entered, then the information must be verified before becoming part of the final medical record.

5. Physical examination: vital signs, height, weight, heart sounds, lung fields, and airway assessment. This information can be interfaced from the physiologic monitor and/or captured from the initial nursing assessment. In addition, AIMS can provide useful tools to take information automatically from the history and physical and calculate derived values such as body mass index or risk prediction scores.

6. Procedure information: includes surgeon and proposed operation. This information should be automatically captured from the OR scheduling system. If not, AIMS typically allow users to select from a list of choices.

7. Anesthetic assessment and plan: includes American Society of Anesthesiologists physical status, airway management plan, monitoring, and patient discussion acknowledgment.

The preoperative components of AIMS help improve the quality of care of patients by helping collect all of the relevant information to perform a safe anesthetic. They can prevent information from being missed or overlooked and automatically provide guidance to prevent adverse events. For example, preoperative information collected in an AIMS can help to predict patients needing antiemetic rescue.11 They can save clinicians time by eliminating the need to search for information or manually enter information that has already been collected by someone else. Conversely, poorly integrated and designed systems may reduce the satisfaction of providers and patient focus. Preimplementation planning is of utmost importance.

Intraoperative Record

The intraoperative component of the AIMS must allow for quick and accurate documentation. Screen layout must be well thought out, methodology of data input should be intuitive, and the overall ergonomics should be conducive to the multitasking that occurs in the OR environment.12

Although much of the clinical information is automatically captured from the physiologic monitors or other medical devices into the intraoperative record, there are observations that need to be manually entered because of either the type of information captured or hardware/software limitations. For example, train-of-four information may need to be entered manually because the nerve stimulator does not record the number of twitches. Specific items are required for quality assurance or billing reasons and must be documented by the user in the anesthetic record. AIMS can be used to increase the documentation compliance rate.13 However, there are also instances where despite the implementation of an AIMS, incomplete documentation persisted in the anesthesia record14 (Table 29-4).

After the case is complete and all the data have been entered in the system, the record is closed, typically triggered by an event (such as anesthesia end). Alternatively, AIMS have a separate action to close the record. After the record is closed, any additional items documented should be highlighted as addendum information (Fig. 29-3).

Staff and Billing Information

AIMS can be extremely useful to billing and compliance teams by ensuring all items required for billing are accurately recorded and that all compliance measures are accounted for. Many institutions that use AIMS have been able to improve billing significantly. Spring et al were able to reduce their percentage of unbillable records from 1.31% to 0.04% and increase annual revenue by $400,000.15

Staff Concurrency Checks

Many anesthesia care models have a number of anesthetic caregivers involved in a single case. Anesthesiologists may be supervising multiple nurses or residents, breaks are given, and responsibility of care is transferred from one anesthesiologist to another. Anesthesiologists are expected to sign in and out of cases accurately and reliably as they are associated or disassociated with them. However, in a typically busy day in an OR, time-related documentation mistakes commonly occur. This can have multiple adverse ramifications. Specific institutions, as well as insurance companies, have guidelines on the number of cases that an anesthesiologist can supervise simultaneously. AIMS can keep track of the cases that each anesthesiologist is associated with and perform real-time concurrency checks, so no caregiver is associated with more cases than is allowed at any given time. This saves the billing team a time-consuming task and reduces the possibility of rejected bills; furthermore, it allows anesthesia departments to be compliant with institutional policies.

Automatic Charge Capture

Anesthesia charge capture is a complex process, involving not only the complexity of the procedure but the patient's clinical condition and the time spent with the patient. Every single anesthetic is a unique charge. AIMS can provide significant revenue optimization by ensuring that all billable clinical activities are captured and reducing the time spent by the billing staff in generating a charge.

Acute care anesthesia professional services fees include 4 main categories:

1. Base units: refers to the complexity of the case (lower units assigned for monitored anesthesia care [MAC] ophthalmology cases and higher units for cardiac bypass cases).

2. Time units: how long the anesthesiologist was directly responsible for the patient.

3. Qualifying circumstances unit: a variety of special situations such as use of induced hypotension or extremes of patient age

4. Flat-fee procedure charges: non–time-based charges involving invasive procedures such as preoperative placement of arterial lines, use of peripheral nerve blocks for postoperative pain relief, or emergent nonoperative airway management

These categories are then compiled to create a bill. AIMS can help this process by abstracting the necessary billing information from the anesthetic record. This information includes:

• Patient indentifying information (such as medical record number). Medical record numbers are usually interfaced from hospital registration systems or OR scheduling systems.
• Provider information (all anesthesiologists and attending surgeons involved in the case). AIMS allow users to sign in and out of a case. This information is then recorded as part of the anesthetic record. The documentation of surgeons involved in case is either captured from the ORMIS or manually entered by the user into the AIMS.
• Anesthesia times (anesthesia start and end).
• Procedure information (complete procedure and accompanying diagnosis). The billing team requires comprehensive procedural information to generate an accurate bill. For example, it is important that the billing staff know that a spinal procedure was a multilevel fusion with instrumentation to assign the appropriate base unit. Procedures listed in the scheduling system can be used as a starting point for the documented procedure in the anesthetic record, but many times it needs to be modified to reflect the procedure actually performed.16
• Anesthesia type and procedures: MAC, general anesthesia, regional block, lines placed.

Decision Support

Decision support is any aid that reduces the possibility of error or increases the probability of making the correct decision. Decision support functionality in AIMS can help standardize clinical practices, reduce errors of omission, and prevent anesthesiologists from delivering harmful medication or medication doses.17

Case Templates

Cardiac anesthesia cases are managed differently from routine hysterectomies. Cataracts are managed different from craniotomies. Intraoperative templates take these into account and enable best practices to be followed. Templates can significantly help institutions follow practice guidelines. Placing antibiotic dosing on case templates, in addition to physician-specific reminders, increased compliance with antibiotic administration from 69% to 92% in one study.18

Alerts and Reminders

Alerts and reminders are important tools that help ensure the completeness of documentation and adherence to standard of care. When used judiciously, they guide the user to perform the right action without interfering with the speed of documentation. When used excessively, they slow the user down and decrease user acceptance. Alerts and reminders fall under the broader category of decision support. Within the context of the AIMS, they can take several forms, including:

• Pop-up windows in the AIMS
• Pager or e-mail messages
• Highlighting or bolding of certain items within the AIMS

These features have been used in AIMS to address institutional compliance issues. There have been many examples of improved administration of prophylactic antibiotics with AIMS using alerts and reminders.18-20 Wax et al studied the administration of antibiotic prophylaxis in patients before and after the implementation of a visual reminder. They found that compliance increased from 82.4% to 89.1% with the reminder.19 Sandberg et al used automated text messaging to reduce missing allergy documentation from 30% to 8%.21 Kheterpal et al developed an automated reminder system for peripheral arterial catheter documentation in the ORs. The experimental group received pager alerts when the arterial line documentation was not completed in a timely fashion. During the 2-month trial, the group that received pager reminders had a significantly higher documentation rate (88% vs 75%; p <0.001). Interestingly, when all users were sent reminders, the documentation rate increased to 99%. This resulted in a net increase in reimbursement of $40,500 annually.22 Despite the potential advantages, one must be cautious when implementing alerts. As stated earlier, when too many alerts are activated in a system, "alert fatigue" sets in and effectiveness of all alerts is decreased (Fig. 29-5).

Workflow Engine

Workflow engines are the tools that allow users to complete their task more efficiently. They work in the background of AIMS as the behind-the-scenes functionality that powers decision support. They can create pending work lists to remind anesthesiologists of documents that need to be signed or patients that need to be evaluated. They can send automatic pages to users informing them of critical labs or test results for upcoming patients. They can also work in conjunction with patient tracking systems to inform users of the status of patients (ready in preoperative holding, OR ready for patient, postoperative care area slot assigned for patient, etc). Workflow engines deliver their output through multiple modalities: on a dedicated screen, via e-mail or pager, or an alert or reminder within the AIMS. They are part of the AIMS toolkit that can improve the quality of care. Kooij et al used a decision support (or workflow) engine to study adherence to postoperative nausea and vomiting (PONV) guidelines. When automated reminders were sent to users, adherence to PONV guidelines jumped from 38% to 73%. When the automated reminders were removed, adherence dropped back down to 37%.23

Reporting for Quality Improvement, Compliance, or Research Purposes

Institutions implement AIMS for many reasons: increased operational efficiency, adoption of best practices, and reduced liability. They also implement AIMS to comply with local and national regulatory requirements. The Centers for Medicare and Medicaid Services (CMS) has implemented pay for reporting efforts and is now exploring the implementation of value-based purchasing. Initially, CMS asked for voluntary reporting on a number of quality measures. For anesthesiologists, these included timely administration of prophylactic antibiotics and maintenance of perioperative normothermia.24 Robust reporting functionality is crucial to meeting or validating all of these objectives. Analyzing clinical, financial, and operational metrics across patients provide data-driven justification for process changes. The resulting cost savings and improvement in charge capture and patient outcomes can provide justification for the cost of implementing AIMS.

Reports can be categorized as standardized or ad hoc. Standardized reports are usually provided by the vendor when an AIMS is purchased. They are commonly used across institutions and include reports such as cases per anesthesia provider, cases by anesthesia type, and total anesthesia time per case type. These reports are either automatically generated or easily obtained from the system. They might be available from the ORMIS as well. In general, OR management software tends to have more standard reports than AIMS due to its increased product maturity. As the number of AIMS implementations continues to increase, we expect more standard reports to be available. Ad hoc reports are unique database queries that answer specific clinical, operational, and financial questions at a given institution. They typically require a deep level of understanding of the system database and querying tools used to access it. Institutions and vendors need to have clear discussions on the availability of standard reports and the limitations of ad hoc reporting tools. Some institutions with large reporting requirements have a separate reporting database. Patient data are transferred from the application database to this reporting database, which is optimized for querying. Then commercially available off-the-shelf reporting tools such as Crystal Reports or SAS can be used to create ad hoc reports.3

Limitations

A major limitation of the ability to create usable reports is the method of data collection. For example, if difficult airway documentation is a free text box where the clinician types in details about the situation, then creating a report to describe difficult airways may be difficult because of the variability in user input. If the clinician had to select among a several choices in a list specifically built for difficult airways, then the report may be easier to create and much more usable. In addition, reporting tools may assume specific content and data nomenclature. This may limit configurability of the system. Tradeoffs between the ease of report creation and clinician ease of use occur constantly. Institutions must ascertain their reporting needs and configure their systems so they can create the necessary reports but not burden the user with lengthy lists and rarely used choices. Ultimately, a well-defined content development philosophy that balances reporting versus ease of use is of utmost importance to institutions with large reporting requirements (Table 29-5).

ORMIS is a software application or a suite of applications that contains the ability to schedule a case, document all the materials and supplies used, create a bill for those materials and supplies, organize staffing for rooms and cases, and document clinical nursing care in all perioperative areas.25 An ORMIS may interface with an AIMS, may contain an AIMS as one of its modules, or may be completely unrelated to an AIMS that is being used in the same health care facility (usually not the best workflow). There is usually some overlap in functionality between the ORMIS and AIMS, and deciding which application to use for a specific task is an important decision each facility must make as part of the implementation process (Table 29-6).

All commercially available ORMIS use standard off-the-shelf personal computer workstations with keyboards to enter information. Most documentation is entered manually, but some systems have device interfaces and barcode reading technology available as well. Radiofrequency identification (RFID) technology is being increasingly used to track materials, equipment, and sometimes staff and patients.26

Operating Room Scheduling

A core component of the ORMIS is the ability to schedule a case. Primary information needed by the application include the surgeon(s), patient, procedure(s), date of procedure, location, and duration of surgery. Additional information collected includes basic patient demographic and medical history, special equipment needed, and preferred type of anesthesia. ORMIS are able to assign anesthesiologists and nursing staff to specific cases and rooms. When cases are scheduled, the ORMIS is able to retrieve the list of required surgical equipment, trays, and supplies from its database automatically and associate those items with the case. It also allows for special equipment or instructions to be added to a specific case.

ORMIS have functionality to enable surgical schedulers to maintain a block model of scheduling, where surgeons typically have dedicated slots during a day to perform their cases. Some have the ability to allow end users (surgeons or their designees) to schedule their own cases within defined parameters. Many ORMIS have a viewing application that allows users to view the OR schedule remotely through the Web or through other hospital systems.

In addition to scheduling cases, some ORMIS have the ability to schedule the proposed disposition for each patient. This allows for more efficient coordination of enterprise-wide resources and patient throughput25 (Fig. 29-6).

Materials Management

The materials management functionality for ORMIS ensures that the correct supplies are present for each case and maintains inventory to keep track of each item's availability. It can also interface with hospital-wide material management systems so that a facility can keep track of all supplies and equipment that are used and order additional supplies as needed. ORMIS have functionality to manage all the equipment that an OR contains: track location of equipment, servicing information, and maintenance schedules.

Billing and Charge Capture

During a case, the circulating nurse is typically responsible for documenting all items that are used during the case (with some exceptions, such as medications given to the patient by the anesthesiologist) in the ORMIS. This information is entered manually, or newer/updated systems allow the use of barcode technology for documentation. All items that are billable are sent to the billing system to generate a charge for the patient.

Clinical Documentation

ORMIS contain modules to document the perioperative nursing care of the patient. Because there is some overlap between nursing and anesthesia documentation, ideally AIMS and ORMIS interface with each other to reduce redundant documentation.

Intraoperative Documentation

Circulating nurses are responsible for the documentation in the OR. In addition to all the billable items, they document certain clinically focused elements as well. Since resource documentation is a significant proportion of the documentation, intraoperative nursing documentation typically resides in the ORMIS. Clinical documentation elements may include:

• Patient position and positioning aids
• Medications administered on surgical field
• Implant information
• Laser use and settings
• Bed types and accessories
• Staff names and roles, with in and out times
• Actual procedure completed
• Time information (room setup/cleanup, room start/stop, case start/stop, anesthesia start/stop, time out, incision/dressing times)
• Tourniquet on and off times
• Drains, tubes, catheters
• Estimated blood loss

Systems that have templates and easy-to-use lists based on the type of case can significantly ease the burden of data entry.

Preoperative Documentation

The main preoperative documentation functionality is the preoperative nursing assessment. Because this is a largely clinical assessment, it often resides in the enterprise clinical information system or the AIMS. Typical elements include:

• Verification of allergies and reactions to allergies
• Medications taken or held
• Brief medical history
• Vital signs and physical assessment.
• Presence of family members
• Mobility issues, activity limitations
• Language/interpreter requirements
• Pain score
• Results of point-of-care testing such as blood glucose and urine pregnancy tests
• Intravenous access obtained
• Medications dispensed

Postoperative Documentation

Postoperative documentation is completed by postoperative anesthesia care unit (PACU) nurses. PACUs are high acuity clinical environments and systems that automatically capture vital signs decrease manual documentation for the nurses and allow them to focus on the patients. Because of this physiologic monitoring focus, PACU documentation often resides in the AIMS or hospital EMR. PACU documentation modules allow nurses to document the flow sheet and patient assessment including:

• Pain score
• Level of consciousness
• Wound assessment
• Drain and tube assessment
• Bowel and bladder function
• Aldrete score

Process Reporting

All the information that is interfaced or painstakingly entered into the ORMIS can be queried to help the perioperative areas provide better and more efficient care. These reports can be categorized into several different categories: administrative, operational, financial, or clinical.

ORMIS have built-in standard reports, and some also contain functionality that allows creation of ad hoc reports by individual facilities, based on the institution's unique characteristics. ORMIS may also use third-party tools to access the database to create custom reports (Table 29-7). Commonly used reports include:

• Daily OR schedule
• Block and room use
• Equipment use
• Number of procedures by location or service or surgeon
• Scheduled case time versus actual case time with reason for delay
• Time per procedure per surgeon

Patient Tracking

Patient tracking components of ORMIS take all the scheduling information and clinical documentation entered to create a real-time view showing the progress of the day's cases. The initial starting point is the OR schedule of the day. The progress of each case is shown by a visual cue triggered by a documentation event in the perioperative area. For example, selecting "In Room" in the intraoperative component of the ORMIS when a patient is taken to the operating automatically changes the color of the case as seen on the patient tracker. In this way, the progress of cases becomes readily transparent and changes can be made to facilitate patient throughput as the situation of cases changes during the course of a day. Schedule adjustments, such as room changes or case cancellations, are automatically updated on the patient tracker. If the AIMS is part of the ORMIS or interfaced to it, important information such as anesthesia personnel and anesthesia times can be reflected on the patient tracker. Many ORs currently have large dry-erase boards used as patient trackers. The electronic patient tracker automates this whiteboard, enhances it by adding information provided from the OR in real time, and distributes the information to any workstation that is able to view the tracker. This distribution of information allows all users to participate in enhancing patient throughput (Fig. 29-7).

Key features of tracking systems include:

• Access
  • Secure, widespread availability
  • Patient information confidentiality functionality
  • View/Edit modes depending on user accessing system
  • Real-time updates
• Preoperative related
  • Graphic display of preoperative holding area
  • View of patient's location within preoperative holding area
  • Visual cue that patient is ready/not ready for transport to OR
  • View of pending items if patient is not ready for OR
  • Ability to notify staff with patient's readiness status for OR
• Intraoperative related
  • Graphic display the operating rooms
  • View of patient location within OR
  • Ability to see anesthesia providers assigned to the room
  • Ability to see surgeons assigned to the room
  • Ability to see procedure being performed
  • Ability to see stage of case (induction, incision, closing, etc)
  • Ability to see if a room is open/ready for patient, closed, dirty, or in use
  • Visual cue that case is running over allotted time.
  • Ability to notify staff of patient's readiness status for PACU
• Postoperative Related
  • Graphic display of postoperative care area
  • View of patient's location within the postoperative care area.
  • Ability to see if a PACU slot is open/ready for patient, closed, dirty, or in use
  • Ability to notify staff with patient's readiness status for PACU discharge

Interfacing with Anesthesia Information Management Systems

OR management systems and anesthesia information management systems can be part of the same suite of applications integrated by a single database. More commonly, they are separate systems build specifically for their own end users. Because certain clinical and administrative information overlaps between the 2 systems (eg, allergies and scheduling information), an interface between the 2 systems can be a vital part of any implementation.

Key Considerations for AIMS and ORMIS Interfacing

Once it is clear which system will be used for each specific part of the perioperative process, then users must determine the documentation elements common to both systems. There must be consistency in the naming and defining of terms between systems to avoid confusion. Ideally, the systems should be able to both send and receive information to and from each other depending on the item documented and facility-specific workflow. Sources of truth must be defined for vital information such as allergies. Data elements that are typically interfaced include scheduling information and allergies. However, common elements of the nursing assessment and anesthesia history and physical, surgical, and anesthetic time stamps, and key intraoperative patient data such as fluids could also be shared, ensuring consistency between systems and a decrease in redundant documentation.

Scheduling Information

The OR schedule is generated from the ORMIS, but the end users of AIMS depend on the schedule as well to access and create the anesthetic record. Updates to the OR schedule should be sent to the AIMS in real time and include relevant procedural and patient demographic information.

Nursing Assessment

Preoperative nurses are typically first to see the patient the day of surgery. Information collected by these clinicians that is useful for anesthetics includes allergies, medications, medical history, review of systems, and vital signs. In the best designed implementations, elements in the nursing assessment that can be incorporated into the anesthesia history and physical are sent to the AIMS. This can significantly reduce the time to complete documentation and improves user satisfaction but does not obviate the need for the anesthesiologist to verify and assume responsibility for the information contained in the anesthesia preoperative history and physical.

Surgical and Anesthetic Time Stamps

OR facility fees and anesthesia professional services fees both depend on time elements for billing. Therefore, both ORMIS and AIMS users document time stamps. When interfacing time stamps, users must decide which system primarily documents a specific time element and then if the information should be sent to the other system. For example, anesthesiologists should always document the anesthesia start and end times. However, many ORMIS include the ability to document surgeon in-room times. The anesthesiologist would not necessarily require this information for the anesthetic record; therefore, it would not need to be sent to the AIMS. Time stamps that are used in common and should be exchanged include:

• Patient in/out room
• Anesthesia start/stop
• Surgery start/complete

Key Intraoperative Patient Data

The documentation of fluids in/out, blood loss, urine output, and other important intraoperative measures is primarily the responsibility of the anesthesiologist but can also be part of the nursing intraoperative record and initial postoperative assessment. As such, data exchange from the AIMS to the ORMIS can reduce redundant manual data entry.

PIMS bought from vendors are not ready for use immediately after procurement. They need to be customized for the specific needs of a facility. Moreover, the system must allow for changes in standards of care and regulatory requirements and advances in medical technology. As facilities grow and mature, processes change, clinical practice evolves, and improvements in workflow are proposed and need to be incorporated by the information system. This adaptability, or configurability, is crucial to the success of the PIMS implementation. Each system has a different level of configurability. Some changes to the application may require the vendor approval or assistance. In other cases, the facility may be able to make the changes. The vendor typically supplies tools that allow the facility to make content changes stored in the database. A few examples of these content changes include:

• Adding or changing names of surgical or anesthesia personnel who use the system
• Adding, removing, or editing elements of the clinical documentation forms
• Adding or removing interfaced devices as the facility changes devices
• Adding or removing locations as new facilities grow or shrink

Facilities need to be aware of the configurability of their system. They should know the aspects that need involvement from the vendor and that can be changed by the facility IT staff.

AIMS are just one of many software systems used in an institution. These multitudes of systems were typically implemented over long periods of time and have varying levels of interoperability. They include the hospital EMR, computerized provider order entry systems, laboratory information systems, radiology systems, document imaging systems, and many others. The anesthetic record needs to become part of the EMR so that other providers can view it when necessary. Given that AIMS are not typically fully integrated parts of the hospital EMR, there has to be an interface built between them. Most EMRs and document imaging systems are able to accept an exported image of the anesthetic record as long as it is in a supported format (PDF, TIFF, etc). AIMS should be able to send a document or image of the anesthetic record to the EMR. The EMR then provides a method for other providers to access and view the record from sites other than the OR where the AIMS are installed. Ideally, documentation of medications given or fluids in/out and other important clinical information would automatically populate an institutions electronic nursing flow sheet and medication administration record. This level of integration is rarely seen today but is certainly a goal for an integrated EMR.

Equally important as accessing the anesthetic record from the EMR is accessing patient information while the anesthesiologist is using the AIMS. There are several ways this can be accomplished, and the methodology depends on many factors: the interfacing capability of the AIMS and institutional software systems, institutional philosophy regarding access of its systems, and breadth of deployment of other systems within an institution. One method is to interface the AIMS with key clinical information systems needed by users. In this scenario, laboratory, pathology, and departmental testing information; dictated notes such as history and physical and discharge summaries; radiology images; medication administration; and electronic orders would be interfaced to the AIMS for viewing by the anesthesiologist. A second scenario is using single logon architecture with patient context to automatically launch other hospital systems such as the hospital EMR with the same patient displayed to avoid having to search for the patient again. This scenario has the advantage of requiring less interfacing work but requires the user to be familiar with each of the applications that are opened. A third scenario is that the user has to open each system manually, including the paper chart, separately to find the necessary clinical information. The reality is that because the transition to EMRs is a long journey, clinicians use combinations of all 3 scenarios to retrieve clinical information in many institutions and a find a way to balance efficiency with retrieving all the necessary information to take care of the patient.

The information stored in AIMS needs to be available in real time and also be safe and secure. A data redundancy plan as part of an overall disaster preparation strategy is essential to any AIMS architecture. Disaster preparedness strategies look at several different levels of failure and develop a plan for each case. For example, if the network goes down in one or a few ORs, the plan would be different than if the network went out in the entire hospital. A well-designed disaster preparedness plan includes redundancy and automatic failover at important points of failures such as data storage areas, storage network, network switches and routers, and servers. The institution, with input from the clinicians, medical records, and IT staff, should include with this plan a trigger of when to revert to paper charting, also known as "code white."3

Data redundancy starts at the workstation level. Some AIMS vendors store patient data locally. In the event of network or central server failure, the clinician would simply continue using the local workstation. When the network or server resumes operation, the data would be sent to the server, and no patient data would be lost. Database servers can be clustered (ie, grouped so that identical servers serve as backup for each other). One server is the designated primary server, and the second is continuously making sure that primary server is working properly. If any significant problems are detected, the backup server automatically takes over and alerts the appropriate personnel. IT staff can usually acquire this backup capability when purchasing the AIMS. They can also manually start up a backup server when problems are detected; however, this method typically causes a short period of downtime for the application.

Backups are also available for the hard drives where the data are stored. A redundant array of independent drives (RAID) system stores the same data on multiple drives. The failure of one drive does not cause the loss of patient data. If a drive fails, it can simply be replaced by the IT staff, and the simultaneous backup continues. Storage area networks (SANs) expand the simple concept of RAID into enterprise storage solutions. Large arrays of redundant hard drives are shared across database servers. The SAN itself can be replicated to a remote backup SAN. In the case of natural disaster such as fire or flood, patient information can simply be retrieved from the mobile SAN. Multilevel and secure data redundancy is complex and expensive. However, no AIMS should be installed without one. The clinical and medicolegal ramifications for unrecoverable data may be far worse.

The decision to implement an AIMS, although offering significant possibilities of improvement on many fronts, is not one to make lightly. The initial cost and maintenance of these systems can consume a significant proportion of a department's annual capital budget. In addition, the implementation process provides not only the excitement of technological advancement but also the frustrations of health care process change. The net result is usually a system that, although not perfect, is superior to the paper record it replaced. After the initial implementation phase, the vast majority of users prefer the AIMS to the paper anesthetic record. AIMS implementations require dedicated personnel from both the vendor and institution. Clinician champions of the system need to come forward or be recruited, and protected time needs to be allotted to the implementation. Once the due diligence has been complete, and the system has been selected and purchased, the real work begins.27

Phases of the Implementation Process

Design

This is the planning stage. Clinicians and users envision in detail how the system will be used. Workflow is mapped out, screens are reviewed and designed, and use cases are discussed so that the system can be configured appropriately. Vendor implementation teams and institutional IT staff typically help in this stage by mocking up screens, providing guidance on the limits and best use of the features and preventing deviation from initial project scope. In this stage, clinicians test different hardware combinations and decide on the best choice for their facility.

Build

This is the configuration stage. Vendor or institution application specialists build out each of the screens. History and physical screens, anesthesia intraoperative templates, nursing assessment modules, and every other screen that needs configuration are built or modified to specification. Specialists upload or input all additional and institution-specific data needed to operate the system. These include locations, users, equipment, supplies, charges, medications, allergies, and many others. In this stage, hardware is purchased and installed, including point-of-care workstations if needed, central servers, and backup equipment. This process can be time consuming and tedious but ultimately makes the system usable for a specific institution.

Test

Once the build is complete, it needs to be thoroughly tested. Typically, systems are initially tested by the vendor implementation team and the institution IT staff, and then detailed screen testing and use case testing is performed by selected end users of the system. The testing should cover as many use cases and workflow scenarios as possible to uncover bugs in the system and prevent surprises when the system is live and running in a real clinical or operational environment. Rigorous testing ensures that every data element on every screen is tested in as many combinations as possible. Load testing is done to ensure that when multiple users are performing the same task, the system does not deteriorate. Performance testing ensures that response times are to specifications. Disaster preparedness plans are tested to ensure that backup systems are functioning properly.

Train

After adequate testing, the all end users of the system must be trained on the system. Training should be concise, focusing on broad concepts of navigating and documenting. Well-designed systems do not take an overwhelming amount of training for users to grasp basic concepts and be able to function within the system. Many specific questions can then be answered during the initial go-live.

Go-Live

Go-live is the culmination of all the hard work put in by the implementation team. The hope is that the effort expended during the previous phases makes for a smooth go-live with satisfied end users. The reality is that issues always arise, minor malfunctions are discovered, and some features do not work as planned. A go-live team that is flexible and responsive to end-users is invaluable to making the initial days successful. For inexperienced institutions, vendor implementation teams can provide valuable expertise during these times.

Maintenance and Upgrade

The go-live is just the start of the journey. During the life of the software product, maintenance will be required; changes will be made to both the content and features of the system. Newer releases will come out that provide exciting new functionality but may break existing features that users depended on. As the institution becomes familiar with, then inextricably linked to the product, clinicians will start to forget the time when the product was not around.28

AIMS continue to evolve in features and functionality. As software development technology improves, regulatory requirements change, and users continue to work in partnership with vendors on improving the systems, AIMS vendors are incrementally providing better user experiences and more robust software.

Vendor Environment

Our expectation is that the vendor environment will continue to consolidate. Although this has the potential to stifle innovation and increase bureaucracy, it can also lead to substantially greater investment in a product. The ultimate outcome of vendor consolidation for clinicians and institutions remains to be seen.

Decision Support and Integration with Physiologic Monitors

A major opportunity for innovation involves the use of advances decision support in AIMS. Currently, vendors provide relatively straightforward decision support functionality with case templates, simple alerts, and reminders. We expect further integration with medication libraries and drug checking to allow systems to provide timely drug interaction warnings, including:

1. Dose range checking

2. Default drug doses based on patient weight

3. Drug/allergy checking

4. Drug/drug reaction checking

In addition, smart alarms that collect information from multiple devices to help alert the user regarding catastrophic emergencies have developed as research tools and may be on the horizon for commercial products as well. Links to evidence are currently found on many Computerized Physician Order Entry products and should start to be seen in AIMS products as well.

Standardization of Content and Data Extracts

The information entered and stored in AIMS is valuable for many reasons, one of which is the opportunity to aggregate and analyze the information to improve the quality of care. Data entered into a system may reflect similar clinical concepts but be entered differently. For example, one user may enter the term sleep apnea and the other OSA. Content standardization efforts aim to create consistency in data to allow large-scale aggregation and analysis of data. Terminology standards like SNOMED CT already exist.29 We expect upcoming versions of AIMS to have functionality that allows institutions to map their existing clinical terms to terminology standards like SNOMED CT. This will allow for enhanced interoperability of systems. Benefits include:

1. Ability to conduct large-scale population studies of adverse events using data from multiple institutions.

2. Ability to share quality improvement or other reports between institutions.

3. Ability to interface with other systems in less time with lower expense.

Features and Functionality

Continued advancement is general features and functionality can be expected. More widespread use of touchscreen and multitouch navigation can be incorporated with current technology. Voice recognition technology is being used in research settings and will hopefully move to commercial availability.30 Greater use of biometric authentication, barcode technology, and RFID will enhance the user experience. Greater focus on screen layout ergonomics will make the information easier to process. Better search technology will allow quicker documentation of data that references libraries, such as medications and allergies. Finally, more robust networking and processing hardware should allow for faster screen changes and increased speed of documentation.

PIMS have 2 main components: AIMS and ORMIS. They are available from commercial vendors as (1) part of an enterprise EMR, (2) packaged together as part of a PIMS, or (3) as separate systems with varying levels of integration. They are used to help manage both the documentation and the workflow that OR personnel encounter every day. AIMS have been used for more than 30 years, first as rudimentary record keepers, now as active assistants to anesthesiologists, researchers, and billing staff. The complexity of implementations of these systems has increased as the complexities of the systems have increased. Although the core functionality of AIMS and ORMIS continues to evolve and be updated, the greatest opportunity lies in the standardization of content and resultant large-scale aggregation and analysis of data. Most anesthesiologists still document the anesthetic record on paper, but the day when paper will be the exception and not the norm is approaching. How quickly and with what type of response from the anesthesiology community will largely be determined by carefully applying the lessons learned from those using the systems today.

• Kheterpal S. Architecture. In: Stonemetz J, Ruskin K, eds. Anesthesia Informatics. London, UK: Springer; 2008:147-165.
• Reeves C, Stonemetz, J. Automated charge capture. In: Stonemetz J, Ruskin K, eds. Anesthesia Informatics. London, UK: Springer; 2008: 269-294.
• Reynolds, M. Device interfaces. In: Stonemetz J, Ruskin K, eds. Anesthesia Informatics. London, UK: Springer; 2008:109-143.
• Ritchie G, Robinson ST. Implementation of an AIMS. In: Stonemetz J, Ruskin K, eds. Anesthesia Informatics. London, UK: Springer; 2008:49-66.
• Shah, N, O'Reilly M. Intraoperative charting requirements. In: Stonemetz J, Ruskin K, eds. Anesthesia Informatics. London, UK: Springer; 2008:191-208.
• Vigoda MM, O'Reilly M, Gencorelli FJ, Lubarsky DA. Decision support. In: Stonemetz J, Ruskin K, eds. Anesthesia Informatics. London, UK: Springer; 2008:295-310.
• Wilson M. Components of an ORMS. In: Stonemetz J, Ruskin K, eds. Anesthesia Informatics. London, UK: Springer; 2008:333-344.