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

Introduction

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 thirty years ago¹. This developed from a basic automated charting tool into the anesthesia information management system (AIMS)², becoming comprehensive data warehouses used for clinical, administrative, and research purposes. AIMS add value beyond direct patient care by sharing anesthesia systems and data horizontally and vertically within the healthcare organization³. 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, and 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 one 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 work 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 a 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 HTML5, Canvas, and JavaScript. Originally, it interfaced indirectly with the CompuRecord AIMS (Philips, Andover, MA, USA), using an internal lightweight data abstraction layer. Vital signs and other data were transferred in real time from each anesthesia record to our pre-existing 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), the MySQL relational database (Oracle Inc., Redwood City, CA, USA), and the Vis.js visualization library (Almende B.V., Rotterdam, Netherlands).

When our practice migrated from CompuRecord to Epic Anesthesia (Epic Systems, Madison, WI, USA), 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)⁸. This can be accessed using standard web data retrieval protocols such as the Simple Object Access Protocol (SOAP)⁹. We built a C# data loader service to fetch anesthetic data in real time using Epic Web Services API calls (e.g., GetSurgicalRecords, GetFlowSheetRows, GetPatientResultComponents, GetSmartDataValues, GetClinicalNotes). The loader service runs every five 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 less than one 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 (e.g., vital signs that have been corrected). Instead, every Web Services call will re-fetch 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 feed¹⁰ 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 post-op medications (e.g. 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 application programming interface¹¹. It is readily extensible both by adding features directly and also with common healthcare information interchange technologies such as HL7 and SMART on FHIR (Substitutable Medical Applications, Reusable Technologies on Fast Healthcare Interoperability Resources)¹². 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¹³. 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¹⁴. 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; e.g., 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¹⁵, 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, USA) is a large, urban academic anesthesia practice with over 140 faculty, 184 residents and fellows, and 38 certified registered nurse anesthetists staffing four 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 three 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 application programming interfaces (APIs). This occurred in parallel to our Epic planning and building process. Currently, OR Watch is in production use at four 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 protected health information (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 upon which reveals further details) indicates critical intraoperative lab values or vital signs¹⁶. 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.

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 one-click availability of any prior anesthesia records, and another flag that indicates presence of critical events in prior anesthetics, as determined algorithmically; as we previously described¹⁶. Another flag indicates if a patient is scheduled in multiple locations (for example, 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. Note alert icons: 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 one 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 post-anesthesia 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 (e.g. 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 four 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 an custom-designed in-house AIMS/EHR to provide access to anesthetic charts and some scheduling information.⁶ 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 in order to send alerts to the correct provider¹⁷.

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 pre-anesthesia record review feature using OR Watch¹⁶. 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 healthcare enterprise through electronic health record innovation.

We note some potential disadvantages to our approach. Building and maintaining custom applications requires expertise and resources (i.e., software developers) that may not be provided or supported by the enterprise 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 (e.g. 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 non-proprietary, 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.

Glossary of Terms

AIMS

Anesthesia Information Management System

API

Application Programming Interface

EHR

Electronic Health Record

HL7

Health Level 7

HTML5

Hypertext Markup Language version 5

HTTPS

Hypertext Transfer Protocol Secure

MAC

Minimum Alveolar Concentration

PHI

Protected Health Information

SMART on FHIR

Substitutable Medical Applications, Reusable Technologies on Fast Healthcare Interoperability Resources

SOAP

Simple Object Access Protocol

SQL

Structured Query Language

SSO

Single Sign-On

VPN

Virtual Private Network