A Web-Based Perioperative Dashboard as a Platform for Anesthesia Informatics Innovation.

Abstract

Physician anesthesiologists have a long and storied history of using technical innovation to improve patient care. Initially, this innovation was focused on hardware. During the 1980s and 1990s, with the rise of the personal computer, the focus shifted to software. The electronic “anesthesia record keeper” was first described over 30 years ago.1 This developed from a basic automated charting tool into the anesthesia information management system (AIMS),2 becoming comprehensive data warehouses used for clinical, administrative, and research purposes. An AIMS adds value beyond direct patient care by sharing anesthesia systems and data horizontally and vertically within the health care organization.3 Yet as hospitals consolidate into large health systems, the standalone AIMS has become obsolete, increasingly replaced by proprietary enterprise electronic health record (EHR) systems. We contend this hinders innovation. Enterprise EHR vendors typically provide a monolithic “all-in-one” solution on a common platform for all functions—administration, billing, clinical charting, and decision support. This approach is claimed to reduce support, integration, development, and training costs. This is in marked contrast to the classic AIMS, which took a “best-of-breed” approach where the software was highly customized to the needs of the specific end-user. The billing office used billing software, the report writers used reporting software, and the clinicians used an interface often designed by fellow clinicians. The “all-in-one” approach has led to dissatisfaction among clinicians, with usability graded as unacceptable and a major contributor to physician burnout.4,5 Ideally, EHR shortcomings could be quickly solved in response to user feedback. However, this idealism is at odds with the business model and development process of EHR vendors. When the AIMS is only 1 component of an enterprise EHR, the cost of migrating away from only the AIMS component is generally unjustifiably high from the health system perspective, so there is little financial incentive for the vendor to innovate. The ability to create custom solutions is necessary to support and drive research into improvement in AIMS functionality. We describe a custom web-based application, providing functionality absent in the enterprise EHR, that we use to streamline clinical and operational workflows. Our study is distinct from existing efforts focused on clinical decision support.6,7 The focus is on supporting and enabling the call team and daily coordinator to most efficiently staff and coordinate the complex dance of scheduling activities that occurs in busy anesthesia practice. Originally built to work with a standalone AIMS, its modular architecture allowed us to easily adapt it to an enterprise EHR system. The greater significance of this project is that it shows, in an era of monolithic enterprise EHR systems, the importance of open access to EHR data, without which innovation in anesthesia informatics could not occur. METHODS Technical Architecture Our custom perioperative dashboard, OR Watch, is a web application that utilizes modern technologies like Hypertext Markup Language version 5 (HTML5), Canvas, and JavaScript. Originally, it interfaced indirectly with the CompuRecord AIMS (Philips, Andover, MA), using an internal lightweight data abstraction layer. Vital signs and other data were transferred in real time from each anesthesia record to our preexisting perioperative data warehouse. OR Watch retrieved these data from that system rather than interacting directly with CompuRecord. A separate database stored personnel and scheduling information generated by the surgical scheduling system Horizon Surgical Manager (McKesson, Irving, TX) as well as separate custom applications used by departmental administration. One of these custom applications is the on-call assignment scheduling system. A feed from the hospital inpatient bed management system (Cerner, Inc, Kansas City, MO) provided locations of inpatients. We consciously chose not to create a mobile app native to a particular operating system. This allowed compatibility with all modern mobile and desktop devices and minimized the need to modify OR Watch to accommodate new devices. All features were designed and tested on desktop and mobile devices in parallel. The open-source technology stack was chosen for technical merit, simplicity of use, and easy license compliance. It includes the Python programming language (Python Software Foundation, Beaverton, OR), the MySQL relational database (Oracle Inc, Redwood City, CA), and the Vis.js visualization library (Almende B.V., Rotterdam, the Netherlands). When our practice migrated from CompuRecord to Epic Anesthesia (Epic Systems, Madison, WI), the modular design of OR Watch enabled us to switch the source for intraoperative data and case information without significant rebuilding of the core application. The preferred method for building applications that augment core Epic functionality is to use the Epic Web Services application programming interface (API).8 This can be accessed using standard web data retrieval protocols such as the Simple Object Access Protocol (SOAP).9 We built a C# data loader service to fetch anesthetic data in real time using Epic Web Services API calls (eg, GetSurgicalRecords, GetFlowSheetRows, GetPatientResultComponents, GetSmartDataValues, GetClinicalNotes). The loader service runs every 5 minutes and retrieves data for up to 500 cases at a time using multiple concurrent API calls. The loader reorganizes the data to match our local schema and deposits the results into the local relational database using Structured Query Language (SQL) statements to create a coherent mirror of relevant clinical data. The sequence of extract-transform-load typically takes <1 minute of wall clock time. Unfortunately, Web Services has certain limitations. For example, there is no way to apply fine-grained query filters (analogous to a SQL WHERE clause), such as precise time range limitations, checkpoints indicating what data have already been fetched, or limiting the query to user invalidated or changed data (eg, vital signs that have been corrected). Instead, every Web Services call will refetch all data for a case. The loader service copes with this by leveraging the SQL database engine to efficiently filter duplicate data when updating local tables. OR Watch accesses these local tables in the same manner as it did previously with CompuRecord, requiring minimal refactoring of its SQL query statements. Another limitation is that scheduling data are not easily available for previous or future days or for anesthetizing locations not managed through Epic. Scheduling data are therefore obtained via a separate Health Level 7 (HL7) data feed10 from the applications supporting those locations. Intraoperative medication data (“One Step Meds”) are also not available via Web Services in our Epic build. These data are therefore also obtained via HL7 feed, transformed and processed by a separate application and merged by our custom loader service with the data retrieved from Web Services. An advantage of this approach is that all medications charted as part of the anesthesia phase of care, including both immediate pre- and postoperative medications (eg, medications given in the recovery area), are coherently mirrored in local SQL tables. OR Watch is accessible programmatically with a stateless Hypertext Transfer Protocol Secure (HTTPS)–based API.11 It is readily extensible both by adding features directly and also with common health care information interchange technologies such as HL7 and Substitutable Medical Applications, Reusable Technologies on Fast Healthcare Interoperability Resources (SMART on FHIR).12 For patient privacy and regulatory compliance, client web browsers must use the encrypted HTTPS protocol from within the institutional intranet. Users must sign in using the institutional single sign-on (SSO) authentication system, and this identity is recorded in an audit log of each access of protected health information (PHI). OR Watch is accessible through web browsers on hospital workstations or mobile devices connected to the hospital local network, or remote workstations and smartphones by virtual private network (VPN). User Interface Design We felt that it was critical not to introduce a new look and feel because this could increase the perceived difficulty of use. Since most people in our institution are familiar with web applications from Google LLC (Mountain View, CA), we used the open Google Material Design standard.13 This provides a consistent experience between OR Watch and other familiar applications, and between desktop and mobile versions. Clarity of data presentation was the primary user interface design goal.14 As such, OR Watch uses certain inviolable visual conventions. For example, an attending/resident team is always listed with the attending above and resident below. “Attending:” and “Resident:” labels are omitted, reducing clutter. Any violation of this convention would prevent the user from trusting the meaning of the spatial relationship, compromising usability. Similarly, wherever they are displayed, anesthesia provider names are annotated to show the respective current “out-by” time or on-call status. These annotations are unobtrusively displayed, which allows the user to infer their meaning if desired or else ignore them. Limiting the information displayed improves clarity. For example, in the case detail view, OR Watch displays a graph of vital signs rather than numeric values, and only certain vital signs are shown; for example, mean but not systolic/diastolic arterial pressures are plotted. Colors follow common conventions: systemic arterial pressures in red, central venous pressures in blue, and pulmonary arterial pressures in yellow. The concentrations of exhaled volatile agents are plotted as minimum alveolar concentration (MAC) values normalized to age,15 colorized as on most vaporizers. This is generally sufficient to depict clinical trends, but numeric values remain available from the traditional (and authoritative) EHR. RESULTS Development and Deployment The Mount Sinai Health System (New York City, NY) is a large, urban academic anesthesia practice with over 140 faculty, 184 residents and fellows, and 38 certified registered nurse anesthetists staffing 4 hospitals, collectively administering over 400 anesthetics per day across all locations. We utilized the CompuRecord standalone AIMS from 1991 to 2018. In 2015, we began the development of OR Watch. Fully deployed by early 2016, OR Watch rapidly became widely used among anesthesia, surgical, and critical care providers at all levels of training, including physician assistants and nursing staff. Our health system had been using the Epic Inpatient module since 2011, and Epic Ambulatory since 2007. In 2018, we transitioned to the Epic perioperative (OpTime) and anesthesia (Epic Anesthesia) modules. This involved over 3 years of planning and building by vendor consultants working with our own departmental informatics specialists, including physicians, software developers, and business managers. Despite this, fundamental design and functionality limitations of the EHR resulted in a final build with similar deficiencies to the prior system, including no integration with staff scheduling and no first-class mobile access to anesthetic charts. The deficiencies extended to the all-in-one user interface of Epic, which was significantly slower and harder to use than our prior AIMS. Recognizing that Epic Anesthesia would not replace the functionality provided by OR Watch, we refactored OR Watch to integrate with the Epic Anesthesia module through the provided APIs. This occurred in parallel to our Epic planning and building process. Currently, OR Watch is in production use at 4 hospitals in our health system. Functionality Beyond the Enterprise EHR OR Watch provides a variety of functions not available in the enterprise EHR, distinct from pure clinical decision support. An overview page of all anesthetizing locations provides those responsible for managing anesthesia staffing at any given moment (“coordinators,” “board runners,” etc) with the real-time status of each location (Figure 1A). This overview is free of PHI. Color coding and perioperative event abbreviations indicate the progress of a case, provider names are shown, a counter indicates the number of scheduled cases remaining in each location, and an alert icon (hovering on which reveals further details) indicates critical intraoperative laboratory values or vital signs.16 On-call staff assignments are integrated into all OR Watch reports, a linkage we were unable to achieve with the EHR’s existing reports.Figure 1.: Main views of all anesthetics currently in progress or recently finished. A, Overview of all anesthetizing locations. B, Detailed view of all anesthetizing locations.A more detailed linear version of this overview is also available (Figure 1B). It adds information about the procedure, the surgeon, the on-call status of anesthesia care team members, and details of any alerts. Selecting a specific location opens the anesthesia record for that location. This allows remote monitoring of vital signs, case events, free text comments, drug administration, fluid in/out, transplanted organ ischemic times, cardiopulmonary bypass and aortic cross-clamp times, and other items of interest to physician anesthesiologists supervising a care team as well as to providers managing the patient postoperatively. Perhaps the most unique feature is a page that lists anesthesia providers and the anesthetizing location they are currently covering, as well as a history of their locations for the day. Figure 2 depicts a version of the page limited to the call team. This allows coordinators to easily keep track of providers available for staff relief in the evening as cases finish and late cases start.Figure 2.: Anesthesia provider view with work history for the current day.A master schedule is also available for planning upcoming cases. Each afternoon, the next day’s case schedule and assignments are posted so assigned staff can begin reviewing the cases and planning. This view contains various icons including one that indicates 1-click availability of any prior anesthesia records and another flag that indicates the presence of critical events in prior anesthetics, as determined algorithmically, as we previously described.16 Another flag indicates if a patient is scheduled in multiple locations (eg, a case spanning radiological imaging and a neurosurgical procedure). These functions remain available in the current day’s live schedule (Figure 3).Figure 3.: Detail view of daily schedule with real-time updates. Magnifying glass signifying previous anesthesia record available or inspection; red exclamation point signifying the existence of algorithmically determined critical events in a prior anesthetic record; and yellow exclamation point signifying that this patient is scheduled to be anesthetized in more than 1 location on the same day. Current patient inpatient locations are shown in blue boxes.A patient-specific preoperative evaluation memo functionality is also provided. These memos are entered into OR Watch by clinicians in the anesthesiology preoperative evaluation clinic to highlight specific anesthesia-related concerns and appear on the master schedule as an icon next to the patient. Because they are attached to a patient rather than specific to an encounter, they are less likely to be inadvertently missed or overlooked when a case is rescheduled into a new patient encounter. In our practice, inpatients scheduled for an anesthetic are seen the night beforehand, usually by the on-call team. To facilitate the division of labor for this task, OR Watch provides a printable handout divided into individual case slips to be distributed among the on-call team. Each case slip lists the patient location, procedure name, and scheduled anesthesia care team. To facilitate timely completion of postanesthesia evaluations, OR Watch provides a list of a given provider’s recent cases along with patient location or contact information and a notation whether a postoperative evaluation note has been entered. In addition, a list of all recent postpartum patients who received an anesthetic allows the obstetric anesthesia team to easily conduct postoperative evaluations. A drug reconciliation report shows per-case drug administration totals. Distinct from a simple listing of individual drug doses, this allows clinicians and pharmacists to efficiently audit controlled substance usage and identify discrepancies between drug obtained from the pharmacy and drug administered to patients. A view of one’s prior cases aids case logging for trainees and clinical review. This obviates any perceived need for trainees to keep records of cases that include PHI or go through a cumbersome process of manually viewing the Epic schedule for multiple days. An interface to the institutional pager system facilitates quickly sending text messages to multiple providers at once (eg, the on-call team). DISCUSSION We have described a web application that helps automate the cognitive integration required to optimize the overall workflow of a surgical facility. OR Watch is currently used by a large academic anesthesia department across 4 hospitals to improve situational awareness and facilitate a number of daily tasks in the preoperative, intraoperative, and postoperative phases of anesthetic care. We demonstrated the generalizability of our approach by switching its primary data source from a standalone AIMS to an integrated EHR. OR Watch gives a concrete accounting of anesthesiology information needs that cannot be completely fulfilled with only EHR features due to limitations in EHR application scope and external data integration. Specifically, staff scheduling data could not be integrated into either the AIMS or EHR in our experience. Local applications have been previously described that integrate anesthesia chart information, surgical scheduling, and anesthesia staff scheduling to a lesser degree than OR Watch. One example used a mobile application that extended a custom-designed in-house AIMS/EHR to provide access to anesthetic charts and some scheduling information.6 Another provides a degree of situational awareness: a decision support system developed for a labor and delivery unit integrated surgical scheduling, EHR data, and physician scheduling to send alerts to the correct provider.17 OR Watch is an example of an emerging class of modern web applications that provide both functionalities unavailable in traditional EHRs and a platform for further innovation. For example, we rapidly implemented and conducted A/B testing for a preanesthesia record review feature using OR Watch.16 Enterprise EHRs are frankly not designed with local innovation in mind—only local customization. We hope that our experience will guide vendor decision-making around the features to add to anesthesia EHR systems. Unexpectedly, we found that many perioperative staff members outside the anesthesia department also adopted OR Watch. By making the application available to the hospital at large, surgical and other services have also benefited, demonstrating another way that physician anesthesiologists provide value to the greater health care enterprise through EHR innovation. We note some potential disadvantages to our approach. Building and maintaining custom applications requires expertise and resources (ie, software developers) that may not be provided or supported by the enterprise information technology (IT) organization. This cost must then be borne by the department. Ongoing development must be planned for, since EHR interfaces and clinical needs change over time. Redundant/parallel systems can drift apart over time, potentially limiting their clinical utility. Finally, strict adherence to data security regulations (eg, Health Insurance Portability and Accountability Act) requires special effort. We recognize that the specific implementation details of OR Watch may not be relevant to every anesthesia practice. Nevertheless, we believe our experience highlights the importance of maintaining nonproprietary, well-documented interfaces to access an institution’s own patient data housed in a proprietary EHR. Enterprise EHR system deployments have consolidated to only a few vendors who enjoy full control over data access interfaces. Without the EHR interfaces described above, it would not have been possible to explore adding new functionality to streamline our clinical processes. We submit that it is critically important to maintain and improve such access. Only with this access guarantee can further innovation by practicing physician anesthesiologists in anesthesia EHR systems proceed unfettered, and drive future improvements in patient care. DISCLOSURES Name: Thomas T. Joseph, MD, PhD. Contribution: This author conceived and developed the software described, and helped write the manuscript. Name: David B. Wax, MD. Contribution: This author helped write the manuscript. Name: Raymond Goldstein, BS. Contribution: This author helped develop the software described in the manuscript. Name: Jia Huang, MS. Contribution: This author helped develop the software described in the manuscript. Name: Patrick J. McCormick, MD, MEng. Contribution: This author helped develop the software described and write the manuscript. Name: Matthew A. Levin, MD. Contribution: This author helped develop the software described and write the manuscript. This manuscript was handled by: Thomas M. Hemmerling, MSc, MD, DEAA.