HUYNH, NATHAN PhD; TAAFFE, KEVIN PhD; FREDENDALL, LARRY PhD; BURRIS, ROBERT BS; CHILDERS, ASHLEY KAY MS; LIVINGSTON, JENNA BSN, RN; DILLER, TOM MD, MMM
Hospitals are complex systems characterized by many dynamic and interrelated subsystems that function in parallel. To improve any aspect of these systems, hospital administrators and analysts need to be able to study the workflow processes within and between these systems. Unfortunately, evaluation of workflow processes is not routinely done in healthcare because of the complexity and subjectivity of observational methods required to conduct such analyses. This has resulted in limited baseline knowledge of existing workflow processes for assessments of redesigns and for computer simulations. Thus, more effective process observational tools are required to support process redesign and innovation in a controlled environment. This article describes the development and utilization of a workflow data capturing device used in actual healthcare settings to capture Perioperative Services (POS) workflow and to identify the variables within POS that affect the delivery and quality of clinical procedures received by the patients.
Perioperative Services "is defined as the subsystem of a hospital that produces elective surgery, preoperative care, and postoperative care. POS can be thought of as a 'hospital within-a-hospital' that uses multiple inputs, such as capital and personnel, to produce multiple products, such as procedures by specialty."1 It consists of three processes: preoperative, intraoperative, and postoperative. The preoperative process involves scheduling procedures in an operating room (OR) and preparing the patient before and on the day of the procedure. The intraoperative process involves the surgical procedure to be performed by a surgeon with support from POS staff (including at least a nurse anesthetist, anesthesiologist, surgical technician, and circulating nurse). The postoperative process involves scheduling recovery rooms for the patients and providing the appropriate level of nursing care and supplies until discharge or transfer from POS to the appropriate nursing unit in the hospital. Patient flow through the POS system can be affected by the work processes or services within POS.2 The patient's perception of the quality of care being provided and the surgeon's perception of the ability of POS to safely support the clinical procedures may be predicated on the efficient flow of services within POS.1
The importance of POS to hospitals, surgeons, and patients is well known, and the value of understanding how the performance of the various POS components affects patient safety, health, and the quality of the clinical outcomes is also well known.3 In addition, surgical services are the largest source of revenue for hospitals.4 While it is clear to administrators and clinicians that the POS system needs to be improved, the multiple components within POS (eg, staff, facilities, etc) and their interdependent relationships make POS difficult to manage, since it is not entirely clear how the many components interact and their effects on patient health and safety and the quality of the clinical procedures performed. To date, there is limited understanding of how the management of the various resources within POS (eg, nurses, supplies, and equipment) affects the flow of patients; hence, it is difficult for administrators to know what changes to make within POS to improve patient flow. Our study aims to shed light on this subject by examining the work processes and flow of services through the entire POS system (not just one department or unit) to gain a complete understanding of the different subsystems and of their interactions.
PRIOR PERIOPERATIVE SERVICES AND DATA COLLECTION RESEARCH
There has been limited medical research on the preoperative and postoperative processes within POS, although some researchers have considered more than intraoperative factors such as management, team, staff, and task factors in their studies.5-8 Work in this area examines how environmental and process factors in the OR affect performance and patient outcomes6,7 and have found wide variations in OR performance in terms of on-time starts,9 room turnaround times,10 supply expenditures,4 and clinical process outcomes11 across hospitals. Sandberg et al2 concluded that the current POS system design taxes the cognitive capacity of the healthcare providers and that three phases of POS are inefficient and ineffective with many redundant processes and fragmented communication and integration systems.
Our work is motivated in part by recent research that suggests that improved OR performance depends on the synchronization of the functions of key personnel within POS5 and that ensuring that the primary flow (ie, the patient flow in POS) is fast and even improves system performance.12 Some hospitals have improved patient care by focusing on process flow,13-15 but it is clear from the literature that additional research is needed to identify the variables within POS that affect the delivery and quality of clinical procedures received by the patients. Our study seeks to fill this knowledge gap by tracking POS staff members as they perform their activities to capture the interactions between the POS processes to determine those factors in POS that inhibit a swift, even flow of patients through the procedures. The information gathered from this study will allow researchers to apply engineering management methodologies such as detailed process maps, simulation, and optimization techniques to improve POS operations.
Collecting data via handheld devices has been conducted in several healthcare settings over the past 15 years. In the formative years, early work focused on whether using handheld computers to collect data is the right choice. For example, Weber et al16 discussed in detail issues and challenges researchers must consider before using handheld computers to collect data. They concluded that using handheld computers would be beneficial because the computerized method of recording data can reduce errors in data that may arise each time it is handled and the time required for coding and data entry. Subsequently, a number of studies found that using handheld computers and personal digital assistants (PDAs) to collect data was adequate for their studies. For example, McBride et al17 found the use of a handheld computer to collect data in an orthopedic outpatient clinic to yield comparable results to paper forms. Similarly, Guadagno et al18 had success with using PDAs to collect data in emergency departments for a multisite study on elder neglect. A comprehensive list of earlier healthcare studies that use handheld computers to collect data can be found in Weber et al.16
It is interesting to note that the caveats often mentioned in earlier work concerning handheld computers and PDAs are more along the line of education (ie, making sure the users know how to use the technology) and technological difficulties such as transferring data between the handheld device and computer. Devices such as iPods (Apple Computer, Cupertino, CA) and smart phones have grown at an unprecedented pace during the last 10 years, and they have become ubiquitous devices. Nowadays, a great majority of the population know how to operate a smart phone. On the technology front, transferring data between devices has never been easier with Wi-Fi (Wi-Fi Alliance, Austin, TX) and Bluetooth technology (Bluetooth SIG, Kirkland, WA).
SELECTION OF HARDWARE AND SOFTWARE
A challenging aspect of documenting the observed processes while tracking the POS staff is recording the specific times and sequence in which the activities took place in the fast-paced, dynamic environment of the POS. Often, POS staff perform multiple tasks concurrently, and they may be interrupted before completing one task to perform other activities. In addition, a staff member may have a preferred sequence for completing the tasks that is different from another's. Tracking multiple short tasks that may be completed out of sequence is difficult using the traditional paper-and-pencil method, and data gathered with paper-and-pencil method require additional effort to transfer to a computer for analysis.
A variety of hardware and software platforms are available for developing an automated data collection tool. Choices of hardware include laptops, handheld computers, and smart phones. Programming languages include C#, C++, Java, HTML, and XML. Our selection criteria for the hardware and programming language were as follows:
1. The tool must be easy to carry (ie, observers should be able to carry the device in one hand for an extended period, up to 6 hours).
2. The tool must provide a friendly interface to log activity data (ie, observers should be able to record tasks with minimal steps involving pressing and scrolling).
3. The tool must be easy to implement (ie, the research team should be able to develop the application using standard applications in a short amount of time).
4. The tool must be affordable (ie, the cost of the devices should not be prohibitive such that it would deter hospitals from purchasing and utilizing them).
5. The tool must allow standardized and consistent data collection among users (ie, the application must provide consistent time stamps and activity entries in the database regardless of the chosen device).
We elected to use the iPhone/iPod Touch (Apple Computer, Cupertino, CA) for hardware, and we chose to develop a Web-based application instead of a native iPhone/iPod application ("app" hereafter). By developing a Web-based app, we did not need to go through Apple's approval process, which saved time, and the Web-based app worked on other smart phones such as the Palm Pre (Hewlett Packard/Palm, Sunnyvale, CA) and Google Android (Google Inc, Mountain View, CA). In addition, a Web-based app allowed for a faster development cycle and real-time application updates.
The research team developed the app, named POS Trac, as a Web-based application using the latest HTML 5 specification, which delivers rich, interactive media without the need for additional plug-ins. One of the most prominent features of the specification is the HTML 5 Offline Support that POS Trac uses to allow the user to store data locally. The Offline Support feature allows the application to be used even when there is no Internet connection. Unlike natively installed applications, POS Trac is readily accessible over the Internet so that it was easy for the researchers to retrieve the latest app and update their device.
In addition to the core functionalities, POS Trac includes several features that facilitate the data collection efforts. A Notes feature allows the user to record additional or special observations to each activity being recorded, so special circumstances can be captured (eg, a technician receives a phone call to expedite a needed instrument set). While recording data, the app automatically sorts the open, paused, and completed tasks in a manner that is convenient for the observers. Also, the app clearly indicates to the users when there is a task that has an open interrupt that is required to be completed before another task can be created. The app includes other checking mechanisms to prevent users from recording data out of sequence. Finally, when data collection for a session is complete, POS Trac provides the users with the ability to e-mail the collected data to any e-mail account. A comma-separated values (CSV) file is automatically created and delivered as an attachment.
Designing this app to allow for the recording of data in the fast-paced, dynamic, and highly-sensitive POS environment was challenging. The initial design was modified multiple times based on project team discussions focusing on specific measures to record, automated versus textual fields, and the general user-friendliness of the app. The final app design evolved over several weeks of trials and use in the field. This section discusses the final design capabilities and features of the app used to collect data for our study. Note that our study uses only the data collected from the final app design.
Figure 1A shows the app's icon on the iPod's home screen (see POS Trac β in the circle of Figure 1A). To launch the app, users simply need to tab on the icon. As mentioned, the app will work regardless of the presence of Internet connectivity.
At the beginning of the shadowing process, the data collectors would go to the settings screen to select the department and title of the employee they are tracking for that session (Figure 1B). The user name, if entered, allows the study team to know who collected the data. For our data collection, it was important to keep anonymity of staff, as our purpose was more driven by research questions that focus on overall process improvement. However, adding staff names and/or ID numbers to the saved data would be an easy enhancement. The special app features are also included in the settings screen. As discussed, the Email CSV capability allows the data collector to send the collected data to his/her e-mail account. The users also have the capability to see the raw data and copy it to an e-mail or text application. The Reset Database feature is used to clear out previously collected data (the app deletes all data stored in the local database). This is typically done before the start of each shadowing session. We found it necessary to have version numbers (eg, 2.1.1) to ensure that every data collector had the app version with the most recent functionality. As significant learning can take place during the data collection process, we were able to provide a much better tool by allowing such version updates. Denoting the version number on the screen became a crucial piece of information to provide.
Figure 1C shows an example of POS Trac's main screen. In this case, the user is tracking a patient care technician (PCT) from the preoperative department. At the top, the app indicates the department and employee the observer is tracking. The main section of the screen shows up to five most recent tasks that have been entered. The tasks are sorted in reverse chronological order with the completed tasks listed under open (ie, pending) tasks. Notice that completed tasks (eg, Direct Patient Care) have end times, whereas open tasks have only start times.
The app is designed to allow for only one active task at a time. Whenever a new task is created, that task automatically becomes the active task, and the previous active task is put into a paused mode. The notation "(A)" denotes an active task, and "(P)" denotes a paused task. The app also indicates which task has associated interruptions. The value (eg, ) to the right of the task name indicates the number of times a task has been interrupted. Red indicates that the task has an open interrupt, and gray indicates that the task has a closed interruption. Users are not allowed to create a new task when an active task has an open interrupt. For example, the scenario shown in Figure 1C indicates that the task "other" has one open interruption. The app will issue an error message if the user attempts to add another task. To add a new task, the open interruption must first be stopped.
If users wish to view all recorded tasks instead of just the five most recent tasks, they can select the option "show all tasks." The bottom part of the main screen is a predefined task list for each employee type. To record an activity, users would swipe (ie, scroll) up or down the list and then tab the appropriate task. A corresponding start time would be recorded in the database and shown under the task name. To avoid having a gap between the stop time of one task and the start time of the next task, the app is programmed to set the start time of the new task equal to the stopped time of the previous task when the users record the activity in that sequence.
To expedite the task of recording an activity and ensure standardized data collection, a set of essential tasks was developed for each resource. This is done not only to avoid making the data collectors swipe through several screens to find the appropriate activity, but also to make the task of process mapping easier. Table 1 shows the essential tasks for the four primary resources in the preoperative department.
The POS Trac app also includes an edit screen (Figure 1D). Users can make changes to a task by selecting its name on the main screen. As shown, the edit screen allows the user to resume a paused task, stop a task, delete a task, and edit information associated with a task. For example, the user can edit the task name by choosing another option from the list or manually override a timestamp. In addition, on the edit screen, the users can record an interruption to an active task, stop an open interruption, or make note of additional or special observations (Figures 1E and 1F).
All interruptions that occur are classified as shown in Table 2. "Sequence dependent" means that the staff member was interrupted and had to shift attention from the active task because a prior task was not completed on time (ie, completion of the current task depends on completing a prior task). "Staff inquiry" and "nonstaff inquiry" mean that the staff member was interrupted by a fellow staff member (eg, surgeon) or nonstaff member (eg, family member of patient), respectively. When it is not clear what the interrupted task is, "other" is used.
The POS Trac allows the data collectors to record up to five interruptions during the process of completing the primary task. In the background, it records each interruption type and the start and stop time of each interruption. Similarly, every time a task is paused and resumed, those pause and resume times are recorded. A limit of five pause and resume times is set for each task.
USE OF APPLICATION DATA
The app-generated CSV file can be opened with any text or spreadsheet program. However, a spreadsheet program such as Excel (Microsoft, Redmond, WA) would make it easier to sort and analyze the data. Figure 2 shows a sample of the data collected and the format in which it is generated by the app. Each task is treated as a separate record in the database, and all information related to a task is shown on the same line.
The collected workflow data provide a rich data source that can serve many purposes such as benchmarking, data mining, and simulation. For our study, we used the data to accomplish two key objectives. First, we used the data to create detailed process flow maps of resources, equipment, and patients. That is, in addition to showing the sequence of activities, we were able to provide the mean duration and standard deviation of the duration for each task as well as the average number of workflow interruptions. Such flow maps helped the team identify bottlenecks in the system and find causes for those delays. The interruption data we collected are especially helpful for answering our research questions. Second, we used the data to create a computer simulation model. Computer simulation is a widely used operations research tool that can be used to evaluate, improve, and optimize processes. Many healthcare organizations are beginning to utilize this tool. We chose simulation over analytical methods because of the need to capture minute process details and complex dynamics in POS. It provides us with a more realistic representation of the actual system and hence eliminates the need to make restrictive assumptions. Once our simulation model is built, calibrated, and validated, it could then be used to answer various contemplated strategic, tactical, and operational questions.
CHALLENGES AND POTENTIAL OF THE APP
A significant challenge and limitation in designing the app to suit our study needs were the iPhone/iPod's screen size. This screen size limitation (3.5-inch diagonal) required us to break up the information into several screens and required users to swipe up to find information in a list. With the advent of Apple's iPad, which has a screen size several times larger than the iPhone/iPod Touch (9.7-inch diagonal), such a device would allow for much quicker entry of data because the users could quickly pick a task from a list without having to navigate screen to screen (eg, main to edit) frequently. Also, the iPad's larger screen size would allow for development of an app that could track multiple resources simultaneously. However, if it is important to observe and collect data more discretely, the current device size may still be preferred to a device such as the iPad.
The potential of the app to collect data is even more powerful considering its use with radiofrequency identification (RFID) technology. Apple has already filed patents related to a mobile "ID App" capable of using an RFID sensor. By having the ability to read RFID tags, the app could be programmed to automatically "sense" staff members, patients, and nearby equipment. Thus, with such technology, researchers would be able to gather much more information automatically, such as the patient whom the resource attended to, the movements and associated walking distance made by the resource, and the medication given to the patient by the resource.
Because of the need to track POS staff members as they perform their activities in a fast-paced, dynamic environment, the study team found that it needed to have an automated tool to facilitate the recording effort and to overcome the shortcomings of the paper-and-pencil method as well as stencil-based devices. We developed a Web-based application that can be operated on the iPhone, iPod Touch, and other smart phones such as the Palm Pre and Google Android. We found that the app collected data much more easily than the other methods in several ways: (1) time stamps are instantaneous and consistent among the data collectors, (2) activities are entered via swipe-and-click capability, (3) multiple active tasks and tasks that were interrupted can be tracked, and (4) collected data can be output to Microsoft Excel or Access for analysis. In addition, it was easy to modify the app to include and record data on additional items beyond those that were originally planned, and updates and downloads of the latest app could be done seamlessly. Hence, the app can be easily modified to gather data in similar settings at other hospitals. Finally, the app has the potential to be even more useful when used with the iPad and/or in conjunction with RFID technology.
This study benefitted greatly from the feedback and suggestions made by the following graduate students from Clemson University and the University of South Carolina: (1) Bryan Pearce, (2) Sriram Venkataraman, (3) Narges Hosseini, and (4) Megan Hyman.
© 2011 Lippincott Williams & Wilkins, Inc.