Introduction

A basic tenet of anesthesia crisis management is getting help from colleagues early in the crisis [1]. This brings additional expertise and extra hands to the scene to assist and hopefully increase the chances of successful rescue. The call for help itself should not unduly distract or burden the clinician. The response should also be rapid, but delays created by the communication workflow can slow this response time.

Similarly, anesthesia technicians are an integral part of many anesthesia practices. These team members may be responsible for cleaning and resetting anesthesia workstations between cases, or answering urgent or emergent calls for supplies, equipment, repairs, or other assistance during cases in progress. Delays in communicating these needs can negatively impact efficiency or safety.

In order to facilitate timely communication with clinicians and technicians, a multi-functional electronic messaging system was developed to decrease communication latency of calls for help.

System design

Clinician communication

In our institution, a clinician needing urgent help typically either calls our anesthesia coordination desk from a nearby phone him/herself, or asks the circulating nurse in the room to do so. The coordinating desk clerk who receives the call then manually reviews the daily assignment schedule to find other staff who might be of assistance. Typically, these are attending anesthesiologists assigned to work with residents and/or nurse anesthetists (i.e., not working alone and therefore potentially available to assist others) and who are also in geographic proximity to the crisis location (i.e., same building and/or floor). These candidates are then manually contacted by the coordination clerk by phone, one-way pager, or text message [2].

This communication workflow has many points of delay or failure. The desk may be temporarily unmanned or the clerk could be on another call when the initial call for help comes in. The schedule review then takes time. Then the calls/messages to potential helpers must be made/sent. In the case of messages, sometimes the message is simply to call the desk, in which case more time is then needed for the responder to call back and get instructions. The process may also tie up the desk phone when it may be needed for other crisis management communication.

Prior to this project, we had already created a messaging system available on all anesthesia computer recordkeeping workstations (Fig. 1). This web-based interface allows clinicians to send a text message to any individual clinician in the department. It also has pre-defined messages (e.g. “Preparing for induction”, “Preparing for emergence”) commonly used by residents. Messages sent with this system are sent to hospital-issued one-way text pagers, and in some cases, are mirrored as text messages to clinicians' mobile phones by special arrangement with our telecommunications office. Also prior to this project, we had a home-grown electronic scheduling system which includes a database containing all the daily clinical assignments for each clinician/location [3].

Fig. 1
figure 1

Web-based text messaging interface for sending messages from anesthesia workstations to anesthesia technicians and clinicians

Full size image

In order to facilitate calls for help, we added a "Call for Help" button to our messaging webpage (Fig. 2). The button is location specific based on a browser cookie containing the location of the workstation from which the button was clicked. Clicking the button brings up a roster of attending anesthesiologists who are potentially available and nearby, as well as the daily clinical coordinator, all determined by an automated scheduling database query (Fig. 3). After hours, the on-call team members are listed instead. The default list has all names selected, but individual persons can be deselected as desired. Clicking the button on this screen sends a “Help Needed” pager message along with the originating location to everyone selected on the list. The system was created using PHP: Hypertext Preprocessor (PHP) on our hospital intranet platform, including Structured Query Language (SQL) functions for the daily assignment queries and Client Uniform Resource Locator (cURL) functions to interface with our pager service provider’s gateway. Testing was done to validate expected function.

Fig. 2
figure 2

Virtual “panic button” to locate and summon clinical assistance during an intraoperative crisis

Full size image
Fig. 3
figure 3

Roster of clinicians potentially available to provide assistance during a crisis and trigger button to send text messages requesting help to those selected * = Clinical Coordinator

Full size image

Although the old system of calling for clinical help may have more nuanced human-guided selection of helpers, it is expected that the new system makes up for this with faster communication and a larger pool of potential responders. The old and new systems are not mutually exclusive; clinicians can both click and ask the nurse to call for help.

Technician communication

In our institution, a team of anesthesia technicians is responsible for cleaning and stocking anesthesia workstation between cases, as well as bringing equipment and providing technical assistance during cases. Each technician is assigned to a cluster of anesthesia locations and carries a one-way text pager. During off hours, as case volume decreases, the number of technicians on duty also decreases and each remaining technician becomes responsible for more locations. Historically, technicians were contacted by clinicians by manually paging them via the hospital’s phone system and then waiting for a call back to convey what was needed.

In order to improve communication with the technicians, a web-based technician messaging portal was created on our departmental website and available on all anesthesia workstation computers along with the clinician messaging system (Fig. 1). The webpage allows for selection of a location to identify the originating location of messages (which is recorded in a cookie for persistence). A free text box allows entry of a message to the technician which usually obviates the need for a call back. This field is pre-populated with a message requesting a room reset, that being the most frequent request, but this message can be deleted and replaced with another message. There are also other pre-defined messages that can be added including notification about special cleaning needed for infection control, or an emergency designation that results in the message being mirrored to anesthesia technician supervisors to augment the response.

In order to increase efficiency further, the process for requesting room turnovers was automated by interfacing with our electronic medical record (Epic; Verona, WI) (EMR). An “Out of Room” event charted in the anesthesia record is captured by our locally developed Epic web-services interface, the location of the event is determined from the case record, and a lookup table is used to determine which anesthesia technician to notify based on location and time of day. A text message notifying the appropriate technician is then automatically transmitted so they can start the cleaning process sooner and reduce turnover delays.

Discussion

We leveraged our informatics expertise, web technology, and EMR to streamline communication with anesthesia clinicians and technicians in routine and urgent situations. The new system, like all systems, still has some delay and points of potential failure, but fewer than the manual systems [4].

We have not yet done a formal study of the utilization of the new system, nor do we have the historical data to be able to do an objective study comparing it to the previous system. However, we have received anecdotal reports from staff that the new system has resulted in their arrival at the scene in time to actually be of help. (Prior to implementation of this system, staff were contacted one at a time, so by the time people further down the list were notified and arrived, the clinical crisis had already partially or fully played out.) Technical staff have also praised the system’s ability to give them early warning of the need for turnovers, rather than waiting for more urgent requests that would come later in the workflow. Testing of the reliability and latency of our enterprise paging system itself was not conducted because it had already been in use for many years and was not altered by our work.

Other alert systems have been described. One hardwired system utilizes fixed displays/keypads mounted throughout the facility that can be used to trigger and broadcast requests for assistance [5]. However, these messages are displayed on all local stations where staff must first go and read them to determine if the request is directed specifically at them or not. Our system required no hardwiring, using a pre-existing computer and pager network instead—making its implementation easier and lower in cost. It also allows more convenient and directed messaging, alerting only those who are actually needed (based on changing daily assignments imported automatically from our scheduling system) on their personal pager or smartphone wherever they are. Another system was designed to recall staff in a mass casualty situation using a staff contact database and text messages sent to personal smartphones [6]. Neither system is integrated with an EMR to dynamically change message recipients based on daily clinical assignments, or encompasses routine paging of technicians to expedite turnovers as the system described herein.

Commercial EMRs may also contain native messaging functionality, but may have limited flexibility in implementation. They may require specialized client software (and security) to be installed on each user's smartphone; this may be objectionable to some users, requiring the provision of enterprise devices for each user to carry. They may also lack the flexibility to dynamically change the message recipients based on daily staff assignments and time of day. The user interface is also controlled by the software vendor, not the end users. Although there may be generic communication management systems that could perform some of the tasks, they would not be integrated with our scheduling or EMR systems as needed. As has often been the case for our department, custom programming using open-source tools and interfaces to coexisting systems were required to create a solution meeting our local specifications [7].