Anesthesia providers produce and record extraordinary amounts of physiologic, pharmacologic, and care management information. Since the previous edition of this text was published in 2011, there has been exponential growth in the use of computerized anesthesia information management systems (AIMS) both as a stand-alone system and as part of an overall patient care electronic health record (EHR). In the late 1990s, only a handful of academic anesthesia practices had an AIMS installation, with even fewer in private practice settings. However, by 2007 approximately 44% of academic medical centers had completed or were in the process of implementing AIMS. A 2014 follow-up survey estimated that 84% of U.S. academic medical centers would have an AIMS installed by the end of that year. The prediction was that within a few years, few anesthesia trainees would graduate from residency having used a paper anesthetic record.1 EHRs will likely incorporate the growing number of adjunct electronic devices and other software, combining all into the global term health information technology, or health IT. Given the enormous impact of health IT on patient care, anesthesia providers must have an understanding of these technologies including their potential benefits and hazards. The scientific discipline that serves as the foundation of health IT is medical informatics (the branch of information science that relates to health care and biomedicine), which encompasses health informatics, medical computer science, and computers in medicine. Given their special skills and knowledge, anesthesia providers should be key players in the development, assessment, selection, and deployment of perioperative health IT. Anesthesia teams now need a working knowledge of the applicable theory and practice of medical informatics. In this chapter, several key health IT topics for the anesthesia provider will be reviewed, with a focus on AIMS, including some considerations for managing the procurement and operation of information technology in an anesthetic practice.
1. HISTORY OF ANESTHESIA DOCUMENTATION AND AIMS
The origins of the modern AIMS date back to the creation of the paper record in 1895 by neurosurgeon and physiologist Harvey Cushing and his medical school classmate E.A. Codman. (2) As pioneers of anesthesia quality improvement, Codman and Cushing had challenged each other to improve their anesthesia practice. In support of this goal, they were the first to collect and review physiologic data using written anesthesia records just 50 years after the discovery of anesthesia. About the same time, Cushing and others began to employ newly invented automated hemodynamic monitors with paper-based recordings, including noninvasive arterial blood pressure measurements. Over the subsequent 50 years, the anesthetic record maintained the same basic format for representation of hemodynamics, albeit with a slow and steady increase in the amount and types of data recorded. These two innovations—documentation of significant events during actual anesthesia and surgery coupled with automated real-time recordings of hemodynamic vital signs— formed the foundation of the modern AIMS.
The late 1970s and early 1980s saw the rollout and initial evaluation of the computerized anesthesia automated record keeper (AARK), but commercialization and widespread adoption were slowed by the limited availability of cheap and reliable computer hardware and software. (3) Yet, many benefits of AARKs became apparent, even within the limitations of this nascent technology. AARKs corrected limitations of paper records such as recall bias, illegible records, missing data or whole records (with regulatory and billing implications), and the lack of an audit trail for medical/legal purposes. Clinical studies of AARKs also revealed that they produced a more accurate record of hemodynamic variables than handwritten charts. (4) For instance, handwritten anesthetic records had increased “data smoothing” (i.e., recorded data were often approximated, leading to less variation between individually recorded data points) as compared to AARKs.
The 1990s and early 2000s heralded a proliferation of advanced computer hardware and software, such as local area networks, the Internet, digital hemodynamic monitors, medical communication protocols such as Health Level Seven International (HL7), and a significant reduction in the cost of computer processing power. Coupled with the voracious demand for more data that paper records could not satisfy, the relatively simple AARKs evolved into fullfledged AIMS, with numerous additional capabilities.
2. THE DEMAND FOR DATA
In 2001, the Anesthesia Patient Safety Foundation (APSF) endorsed and advocated “the use of automated record keeping in the perioperative period and the subsequent retrieval and analysis of the data to improve patient safety.” (5) There were also demands for anesthesia and perioperative data for such purposes as compliance documentation, research, quality assurance, and the streamlining of billing and administrative functions. However, U.S. federal government action may have most catalyzed the rapid pace of EHR adoption in this country in the 21st century. The Health Information Technology for Economic and Clinical Health (HITECH) Act, enacted as part of the American Recovery and Reinvestment Act of 2009, encouraged the adoption and appropriate use of health IT, including provisions for monetary incentives and penalties.
In 2011, the U.S. Department of Health and Human Services (HHS) Centers for Medicare & Medicaid Services (CMS) initiated the Medicare and Medicaid EHR Incentive Programs. Their Meaningful Use (MU) criteria encourage U.S. health care providers and organizations to adopt health IT through a staged process, via variable payments or penalties. For ongoing MU compliance, organizations must—by 2017—satisfy Stage 3 rules, which consolidate and update many of the Stage 1 and 2 requirements, as well as add requirements for privacy and security practices and the electronic submission of clinical quality measure (CQM) data for all providers. Reporting compliance within the MU system is complex. For instance, there are specific reporting, incentive, and hardship exemption rules that may apply to anesthesia providers. Advice from the American Society of Anesthesiologists, HHS, Office of the National Coordinator for Health Information Technology (ONC), and health IT professionals may help navigate these requirements. (6,7) The requirements are dynamic, and in early 2016, in response to stakeholder feedback, the federal government was developing the Advancing Care Information program. This new program’s intent is to simplify or replace the MU program, focusing on improving interoperability (see later) and creating user-friendly technology designed to support physician workflows. Up to date information about federal guidelines and requirements for health IT is available online. (8)
Discrete data collection and reporting within a health care organization is often cited as a key reason to implement health IT. Reporting supports analysis of workflows; guides efforts at utilization, scheduling, and resource management improvements; permits the measurement of costs, quality, and clinical outcomes; satisfies compliance regulations; serves research studies; and may be required by external public and private agencies. Important data will often reside across multiple systems, leading to the rise of the Data Warehouse, a central repository of integrated data, pooled from one or more separate sources.
Although local reporting has great potential, these local data are leading to the creation of national and international large databases, termed data registries. (9) Several observational data registries are focused on the fields of anesthesia and perioperative care: the Anesthesia Quality Institute (AQI), National Anesthesia Clinical Outcomes Registry (NACOR), the data registry of the Multicenter Perioperative Outcomes Group (MPOG), the Society for Ambulatory Anesthesia (SAMBA) database (SAMBA Outcomes Registry, SCOR), the Pediatric Regional Anesthesia Network, and the Society for Cardiovascular Anesthesiologists Adult Cardiac Anesthesia Module. These data registries can receive data directly from health IT, but several issues make sharing data from local health IT difficult. First, a significant investment of time and other resources is required to map local clinical concepts to the registry data schema. Another barrier to full harvesting of the information contained within these datasets is the inconsistency among the varieties of clinical taxonomies—universally agreed-upon anesthesia “data dictionary” has yet to appear. A third issue is the missing or inaccurate data in health IT anesthesia documentation. This problem may be intractable without significant expense of resources or technological advances because clinicians cannot be expected to be high-quality data-entry personnel while simultaneously administering anesthesia and caring for patients. Finally, much of health IT data is not discrete, structured, or categorized and rather is represented in plain text; that is, natural/human language. Until natural language processing (NLP, a field of artificial intelligence in which computer software understands human languages) matures, much of this information cannot be used to great extent.
Despite such challenges, there is significant potential for local and national registries with respect to quality improvement and health care research. These data can help describe the current state of clinical care and allow for benchmarking of process and outcome measures across multiple organizations, as well as sharing of lessons learned. Pooled data can also be analyzed to explore the relationships between specific patient care factors and clinical outcomes, especially when these outcomes are rare, although there are concerns that such observational, large cohort studies have significant shortcomings compared to traditional prospective randomized controlled trials. (10) But large datasets—often called big data—have helped big business in other fields visualize novel customer-product interrelationships and devise new strategies. Perhaps, big data techniques will be a cost- and time-effective way to augment prospective interventional studies and basic science research in anesthesia. Some anticipated uses of big data include modeling the risk of complications for perioperative patients and sending such information back to the EHR systems to inform clinical decision support (CDS) rules, possibly predicting problems before they actually occur. New computer techniques, such as machine learning or cognitive inference computing, may be able to use big data to draw conclusions from data in ways humans cannot.
3. PROFESSIONAL PERFORMANCE DATA REPORTING WITH HEALTH IT
Electronic reporting of professional quality is a specific use of health IT data that is responsible for many reporting initiatives. The Physician Quality Reporting System (PQRS) receives quality information from individual eligible professionals and group practices for CMS. PQRS quality measures are designed to help eligible professionals and group practices assess their performance across a range of quality domains. In 2019, CMS plans to merge several current quality and value-based assessment systems (including MU and PQRS) into either Merit-based Incentive Payment Systems (MIPS) or advanced Alternative Payment Models (APMs) stemming from the recent Medicare Access and CHIP Reauthorization Act of 2015 (MACRA). (11)
Quality measure reporting is recognized as a critical feature of an EHR. Some systems give the option of recording quality documentation within the EHR itself. Conversely, perhaps this reporting should be conducted outside the EHR to reduce the risk of unwanted legal discovery. An alternative to direct documentation is membership in a CMS-approved qualified clinical data registry that has an option for collection and submission of PQRS quality measures data on behalf of individual providers. The AQI is currently designated as both a Patient Safety Organization, which meets criteria established in the Patient Safety Rule of the HHS and a qualified clinical data registry. Qualified clinical dataregistries and patient safety organizations have a high level of medicolegal discovery protection to encourage accurate reporting. (12) Because MPOG is also a 2015 qualified clinical data registry via its Anesthesiology Performance Improvement and Reporting Exchange registry (ASPIRE), NACOR and MPOG participants can leverage their participation in these data registries to also satisfy federal reporting requirements.
4. FEATURES OF THE ELECTRONIC HEALTH RECORD IN ANESTHESIA AND PERIOPERATIVE CARE
The EHR is a longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting. Although there are significant realized and potential advantages of using EHRs for patients, providers, and the health care organization, there are also many potential pitfalls. Careful design may make the difference between an effective EHR and a failed project. Because the fundamental purpose of the EHR is to support required clinical and administrative activities, the EHR should be intuitive and guide users as well as provide access to the right information at the right time to meet the needs of modern health care.
System feature requirements specific to AIMS include the AARK core functions (permanent recording of device data/device integration from hemodynamic monitors, anesthesia machines, and other clinical devices), capture of meta-data such as case events (e.g., in-the-room time; cardiopulmonary bypass time), documentation of preoperative evaluation (including the use of structured data to support reporting and CDS), management of perioperative orders, and integration with the patient’s EHR and other records in various health IT systems. Key targets for integration include the following:
- Medication data (requiring integration with pharmacy systems, which encompasses patient allergies, medication orders, administrations, interactions, formulary, and costs)
- Laboratory and radiology systems (study orders and results, ability to record point-of-care test results)
- Provider orders, notes, and consults
- Nursing assessments including “ins and outs”
- Billing functions (create charges to patient and their insurance plan)
- Patient tracking (integration with admission/discharge/ transfer application)
- Perioperative management systems (e.g., case ordering, scheduling, utilization management)
For modular AIMS (components of a larger EHR), this integration may be operationalized via shared databases and routines (e.g., the AIMS module records medication orders and administrations in the enterprise database shared with the pharmacy and other clinical applications). For standalone AIMS, multiple interfaces (hardware and software) may be required to communicate data back and forth between the AIMS and the other health IT systems (described earlier) to avoid a perioperative information “black hole.”Perhaps the most important EHR feature is reliability. The EHR must be fault tolerant, meaning resistant to diverse challenges such as software “bugs,” hacking, hardware failures, network errors, and even natural disasters. Preparing for business continuity after a failure includes a fail-safe workflow (e.g., paper records with scanning) and redundant data storage. Two common models for protecting data are (1) data mirroring, in which an application on a local workstation works with locally stored data that are automatically copied to remote storage (or a cloud), and (2) the client-server model in which the local workstation (the client) works with data stored on a remote computer (the server). An advantage of data mirroring is that it may be resistant to brief network interruptions. Client-server architectures can simplify system management by centralizing software and data to ease maintenance and backup activities.
5. HEALTH CARE INFORMATION PRIVACY AND SECURITY
Health care providers are morally and legally obligated to protect the privacy of their patients as well as the security of the EHR. The Health Insurance Portability and Accountability Act (HIPAA) Privacy, Security, and Breach Notification Rules are U.S. regulations that codify this obligation into law. (13) The Privacy Rule sets standards for when and how protected health information (PHI), may be used and disclosed in any medium, including electronic, written, and oral. PHI includes any data that could be used to identify a patient, and when stored in digital form is termed electronic PHI (ePHI). The Security Rule requires certain precautions so that access to health IT systems is limited to those with legitimate purposes and proper authorization. The Breach Notification Rule requires health care providers and organizations to report any breach (a loss of patient privacy or failure of health IT security) to HHS, patients, and, in some cases, the media.
The HHS Office for Civil Rights is responsible for administering and enforcing the HIPAA Security Rule. The details are complex and are described in detail on the HHS website. (14) In addition to HIPAA, other applicable federal, state, and local laws, as well as health care organizations’ policies, may govern the protection of ePHI. Some key HIPAA provisions include the provision of an official notice of privacy rights to all patients, generally at “check-in” or on admission. Therefore, routine use of clinical data for anesthesia care generally does not require additional consent. However, patient authorization may be required for disclosure of PHI to other entities. Patients have a right to their own medical record as well as to limit access to their PHI. There are also laws that restrict changing information in the electronic record for fraudulent purposes. Modern EHRs should have extensive audit trails and integrity checks to detect alterations.
Data security is an evolving field, and as new system capabilities offer increased features, new vulnerabilities also emerge. HHS has raised the alarm about a recent increase in ePHI privacy breaches, detailed in a document on privacy and the security of ePHI produced by ONC. (15) Institutions and individual providers share responsibility in breach prevention. The security of health IT is a significant concern; for example, unknown hospital system hackers have held EHR data for ransom.
At the health care organizational level, the security officer must perform a risk analysis, develop a risk mitigation plan, and approve electronic systems, such as an EHR. Purchasers of health IT must conduct security risk analyses upon installation or upgrade. The health care organization may also benefit from the work of the Health Information Trust Alliance (HITRUST), a U.S. organization that, in collaboration with health care, technology, and information security leaders, has established a Common Security Framework. This includes a prescriptive set of controls that seek to harmonize the requirements of multiple regulations and standards and can be employed by organizations that create, access, store, or exchange sensitive and regulated data. MU Stage 3 includes provisions that the Food and Drug Administration will deliver new tools to help mobile health product developers manage health care data security.
6. SELECTED KEY TOPICS FOR HEALTH IT
Interoperability
Health care data collection and management systems often consist of a core application (computer program) and separate modular applications or data sources (within the organization and outside the organization) that extend functionality. Some organizations take a predominantly modular approach and have many separate applications from multiple vendors in order to meet their complete health IT needs (e.g., the laboratory system, the orders system). When functions are largely centralized within the same general application, an organization may be said to have an enterprise system. The ability to communicate among the various modules and with outside applications and data sources is referred to as interoperability. With high-level interoperability, organizations can share data even when using different types or versions of health IT. (16,17) Interoperability can be operationalized at different levels: software applications (1) may share information with built-in functionality, (2) may share data from application to application using standardized formats (e.g., HL7) or application programming interfaces (APIs), or (3) may interface remotely via health information exchanges (HIEs), which are large data stores that aggregate data from various health care organizations. Interoperability replaces inefficient paper workflows and reduces duplicative testing and medication mistakes. Interoperability also fosters better preventive care and chronic disease management, as well as improving provider communication.
In order to meet MU rules, modular software applications must be able to exchange and use electronic health information without special effort on the part of the user. The ONC has devised an “interoperability road map” to guide current and future development of a learning health system. (18) Interoperability also includes multiple device integration in which data from physiologic monitors, anesthesia machines, ventilators, intravenous pumps, medication dispensers, and other electronic devices are automatically captured by the EHR. The Internet of Things (IOT) is the broader trend in interoperability, in which many electronic devices (from home appliances, to vehicles, to personal health devices) are becoming interconnected, with resultant rapid growth in functionality (as well as increased security risks). Although interoperability is a challenging and resource-intensive process, it is a key promising feature of future health IT.
System Design, User Interface, and Usability
The innumerable pieces of medical data in an EHR include laboratory test and imaging results, demographic information, billing and compliance data, scheduling, materials management, pharmacy data, physiologic data, and provider clinical documentation. Clinical assessment of patients might require users to find information on multiple screens, at different levels within the same application, or among several applications. A “hunt and peck” approach, or presentation of data on screens in a way that impedes global comprehension, produces an enormous memory and cognitive burden on users and does not take into account human factors. In addition to reducing efficiency, poor user interface and data visualization design may impede efficient pattern recognition, clinical assessment, and accurate documentation. More broadly, poor user interface and system design can prevent clinicians from not only understanding what is happening to a patient but also being able to integrate information and predict and prepare for future events, a phenomenon termed situational awareness. Situational awareness was initially described in the field of aviation but has been applied to anesthesia. It is defined as the collective functioning of teams and applies to complex systems involving groups of clinicians and computer systems in perioperative care. (19)
In computer science and informatics, the user interface denotes all features of an information device with which a user may interact, including when and how the system invites interaction and how it responds to it. A good health IT user interface allows clinicians to quickly comprehend and process large amounts of information safely and efficiently. The user interface may be constrained by the overall design of the health IT system. Therefore, overall system design must be informed by the principles of computer-human interaction. Human factors engineering is the practice of considering the real-world needs and abilities of the technology user—expecting humans to act as humans—that is, to make mistakes as part of their normal interaction with the technology, and to have resource-constrained cognitive abilities and memory. One technique for improving human-computer system performance is user-centered design—an iterative technology development workflow—in which cycles of design and prototype development are informed by early user-based evaluation, such as simulation and evaluation of user interfaces during development. Although such iterative engineering practices may have larger up-front costs, there may be significant savings as technologies that are more acceptable to users are rolled out and expensive “redos” are avoided.
Design principles from industries other than computer science and aviation can also be successfully adapted to health IT. The industrial safety concept of a hierarchy of controls has been applied to health care and anesthesia IT, in which levels of intervention to defeat a hazard are described in order of most to least effective.20 The most effective controls are those that simply eliminate a risk, that is, make it impossible for the bad outcome to occur. An example is a hard stop rule that does not permit ordering a medication with a lethal dose. The next level of intervention is substitution, in which a less hazardous process is substituted for the hazardous one, such as replacing anesthesia-drawn up medications with prefilled syringes with standardized concentrations, or in health IT, replacing free text with specific check boxes or buttons. Engineering the controls refers to making it easier to avoid a hazard through system design. For example, the risk of a COWPIE (charting on wrong patient in EHR) can be reduced by including patient identification photographs in the EHR on various crucial screens or by requiring bar code scanning of identification bracelets for critical activites like blood product transfusion. The next level of danger avoidance is built on adminstrative or organizational practices and education, such as checklists prior to procedures (which can be built into AIMS workflows). The least effective level of control is at the individual level, such as training workers to always click on a link to check allergies prior to starting a case. Whenever possible, AIMS engineers and governance members should try to prevent hazards (e.g., patient safety, compliance issues, billing problems) at higher levels of control, and work with clinical and institutional leadership to eliminate, replace, or engineer them away. (21)
Usability is the extent to which a technology helps users achieve their goals in a satisfying, effective, and efficient manner within the constraints and complexities of their work environment. The American Medical Informatics Association (AMIA) has recommended usability principles in building EHRs. Several of these principles are particularly applicable to technology rolled out in the perioperative environment: minimalism (the ability to access core function quickly), reversibility (functionality to undo simple user errors), and memory (memory load reduction, to reduce the cognitive burden of operating the system, preserving memory capacity for core tasks).
The AMIA recommendation of flexibility highlights the usefulness of system customization. It is clear that usability may be increased by customizing the interface according to user preferences and roles. However, there are also benefits to standardizing user interfaces and system behaviors according to local and national norms, such that health IT developers must carefully balance the benefits of customization versus those of standardization. Although there is no single accepted evaluation tool for assessing usability of health IT, standardized questionnaires, simulation, and screen and video recording have been employed to evaluate user satisfaction, charting accuracy, situational awareness (effectiveness), and the number of “clicks” to complete a task (efficiency) in an old versus a new AIMS. Such testing should be performed both prior to implementation, and periodically after rollout with the goals of assessing and directing improvements in human interaction with the hardware, software, and human workflows that compose the total system.
An important corollary to usability concerns the resiliency of the users. When faced with low-usability, but mandated-to-be-used health IT systems, health care professionals will generally find a way to accomplish their goals, in spite of the system limitations. In such cases, although the health IT system may appear to be working successfully, the demands on the user’s memory and attention (such as relying on system “work-arounds” or having their “face buried in the computer screen”) may result in not only operating less efficiently but also in decreased situational awareness, clinical performance, and user satisfaction. (22)
Clinical Decision Support
CDS is an important feature of effective modern health IT and one of the most touted reasons for organizations to purchase health IT:
Clinical decision support provides clinicians, staff, patients, or other individuals with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and health care. CDS encompasses a variety of tools to enhance decision-making in the clinical workflow. These tools include computerized alerts and reminders to healthcare providers and patients; clinical guidelines; condition-specific order sets; focused patient data reports and summaries; documentation templates; diagnostic support; and contextually relevant reference information, among other tools. (8)
CDS may be passive, in which the system, by presenting the clinician with the right information at the right time, assists with decision making. Passive CDS includes the display of relevant laboratory results or vital signs, or providing quick access to appropriate checklists, protocols, standards, or policies and is tightly linked with user interface design. Passive CDS supports the basic levels of situational awareness: knowing what is happening now to one’s patient. Active CDS uses logic (i.e., rules) to detect particular clinical scenarios and then execute actions, such as generating a warning, alert, or automated action. For example, an EHR can automatically monitor a patient’s vital signs and laboratory results, and, when a significant anomaly is detected, such as signs of systemic inflammatory response syndrome, it generates a pop-up alert, sends a pager/smartphone alert, lights up a monitoring “dashboard,” or suggests laboratory or medication orders. Active CDS can address failures of higher levels of situational awareness; that is, failure to integrate and analyze data from various sources to interpret a clinical situation. CDS may be implemented at the user level or may operate at a multipatient level, in real time, or over a longer period of time (e.g., an operating room efficiency dashboard).
CDS has many potential and realized benefits in managerial workflows, in process of care, and ultimately in care outcomes. In anesthesia, CDS has improved cardiac workup protocol adherence, warned of anticoagulation status before a regional block, sent near real-time reminders and notifications for intraoperative and critical care, and reduced some adverse outcomes, such as postoperative nausea and vomiting. (23,24) One significant limitation of CDS is that it cannot utilize information that is not accessible, such as medical history information from another, nonintegrated health system, nor data that have yet to be recorded in the EHR. What good is a drug-drug interaction alert that fails to appear because it does not know the patient’s home medications or signals after the concerning medication has already been given? Automation-induced complacency describes the situation in which clinicians become overly dependent on alerts or other CDS and then fail to recognize and act on that same situation when CDS fails to warn them. Ensuring adequate EHR data and structure so that CDS is not a black box—that is, so that the provider understands how the CDS works and on what data it depends—may reduce these errors.
A 2016 National Patient Safety Goal to reduce unhelpful alerts and alarms addresses the inverse situation, in which too many or nonhelpful CDS warnings cause confusion and degradation of clinician performance through the phenomenon of alert fatigue. Given the consequences of alerts that fail to signal or warn inappropriately, CDS, especially active CDS, should be evaluated similarly to hemodynamic alarms or laboratory tests. They have measurable sensitivity and specificity, and in practice, coupled with the incidence of the issue to be detected, also have positive and negative predictive values; that is, what is the probability that the presence (or absence) of a CDS alert reflects the presence (or absence) of a true significant situation. To determine the impact of an active CDS intervention, health IT management should test it “in the background” and determine the warning characteristics, and once it has been rolled out, should measure the effect that the CDS tool has on health care provider behavior, such as ordering a new test or medication. One common sense recommendation is to avoid hard stops as much as possible, which can have the unintended consequence of completely stopping the ability of a user to perform productive work, a situation made exponentially worse when flawed design makes it impossible to satisfy the rule that led to the hard stop (a significant drawback for user satisfaction and effectiveness). If hard stops must be used for critical patient safety reasons, then it may be best to first test the rule as a caution or soft stop, observe for appropriate behavior, and, only when validated, turn on hard stop functionality.
Transitioning to Health IT: From Paper Records to an AIMS, and Beyond
When transitioning from a traditional paper workflow, or when migrating to a new health IT system, decisions should be guided by such principles as usability, adding value to clinical work, supporting features such as CDS and reporting, and mitigating risks. These risks should not be underestimated, and an assessment of any IT system should include careful analysis and ongoing monitoring of untoward side effects. Anesthesia and perioperative leaders have a central role to play in acquiring new AIMS or perioperative information management systems. They should be leaders in the consideration of new anesthesia and perioperative health IT and should work directly with potential vendors and application developers. Even if their health care organization is purchasing an enterprise-wide EHR, they still have the important role of sharing their evaluation of the AIMS and perioperative modules, and evaluating which components are acceptable (or not). Note the role of change management, the intersection of the new technology with the organization’s culture, project communication, and implementation plan. Crucial “people factors” needed for a successful rollout include strongly committed leadership, a project champion with strong political and social skills, and early and frequent inclusion of end users in the project, from the initial design process to final evaluation. Users may be more drawn to a new system by their perception of the utility of the system—what can it do?—rather than by their perception of ease of use. But both are important, so project education not only should include how to use the system, but should demonstrate how the new tool can improve clinical care or the user’s effectiveness and efficiency. (25)
When initiating a new AIMS or related health IT, remember that the primary goal of these systems is to improve the quality of the health of individual patients. Fundamental to this is that it support the quality, managerial, and financial “health” of the organization. However, when, in the interest of supporting these secondary goals, the burden of data entry becomes excessive, system usability and provider satisfaction will likely suffer. A recent American College of Physicians position paper highlights these tensions: “As value-based care and accountable care models grow, the primary purpose of the EHR should remain the facilitation of seamless patient care to improve outcomes while contributing to data collection that supports necessary analyses.” (26) Although numerous stakeholders may wish to have additional data recorded in the medical record, it is the role of health IT governance and clinical leaders to prioritize these tasks according to institutional priorities. They must also advocate for overall usability, such that the act of using the new technology itself improves and does not degrade patient care.
Legal Issues and Responsibilities of the AIMS User
Several cases in the literature have described the risks, such as legal liabilities, of using AIMS with design flaws or inadequate training or user practices. One of the most common apprehensions about AIMS concerns device integration, when transitioning from paper records to an AIMS. Providers have been concerned that the nowvisible greater variation in autodocumented vital signs, and the inevitable data artifacts, will somehow present medicolegal risks. Although inaccurate autodocumentation, artifacts, and unnoticed data dropouts do present some risks, there is no historical evidence of significant medicolegal negative consequences to providers in general from the proper use of an AIMS. (27,28) In fact, the automatic recording of physiologic data may be welcomed by the specialty of anesthesia, because it removes the known problems of human filtering of data and improves the credibility of the record. Nonetheless, EHR users must understand the basic workflow of device data acquisition and be able to detect and correct failure of data capture. EHRs should also permit easy notation of artifact or data collection errors.
A case report of a patient undergoing a craniotomy illustrates these concerns. (29) According to legal records, upon returning from a break, the responsible anesthesia provider found that the device data/vital sign data stream had failed, without being noticed by the interim anesthesia provider who had covered the patient during the break. As a result, 93 minutes of data were not entered in the chart. The patient had postoperative quadriplegia, and the missing anesthetic documentation may have contributed to settling the case. The anesthesiologist did not recognize the interpretation of data transmission because the “active” window obscured the graphic display of data. This case emphasizes that monitoring devices occasionally fail and the need for the anesthesia provider to be vigilant.
Although improvements in AIMS design since this case include using CDS to display an alert when data flow is interrupted, ultimately, it is the responsibility of the health IT user to follow institutional, local, and national standards to create a complete and accurate anesthetic and medical record. Users may even need to periodically manually enter missing data or flag data gaps and artifacts according to the institutional policy. Such workflows also apply in cases of system or network downtime. When there are data issues, it is best to document fully and transparently what transpired, and to correct the record as soon as possible. Audit trails are discoverable and record the source of data and the time they were modified. Obviously, very late changes to an anesthetic record could have the appearance of impropriety.
7. CONCLUSION AND THE FUTURE
Health IT is ubiquitous and inevitable, and evidence indicates that health IT does have real benefits, (30) but the design and details are crucial. Health IT should support both the clinical needs of providers and patients, as well as the financial and management needs of the organization. All anesthesia providers must understand how health IT impacts patient care. Anesthesia providers must be involved in IT decision making and development to ensure that current and future systems support the specific needs of perioperative care. Indeed, anesthesia trainees also have a role in advancing health IT, recognizing that IT systems can be useful for education and learning. (31,32) Health IT is still evolving rapidly and it is critical to monitor and study its use as it applies to perioperative and critical care. The use of health IT is essential to the concept of a perioperative surgical home (PSH).
Acquisition and use of data will drive future changes in every organization. It is said that you can’t manage what you can’t measure. Once a large number of organizations contribute data about their patients into aggregated data pools, health IT may transform and improve patient care in ways far beyond current achievements.
8. QUESTIONS OF THE DAY
1. What are the potential advantages of the electronic health record (EHR)?
2. What type of information is considered protected health information (PHI)?
3. What are the recommended information privacy and security practices for the anesthesia provider using an EHR?
4. Describe some examples of passive and active clinical decision support (CDS) in health care. What are the potential benefits and hazards of CDS?
5. What factors promote success in the transition from paper records to an electronic anesthesia information management system (AIMS)?
