A Software Communication Tool for the Tele-‐ICU 1
1
2
Denise M. Pimintel, RN, MN , Shang Heng Wei, BS , Alberto Odor, MD University of California, Davis, California 1 2 ( Student; Advisor) Abstract The Tele Intensive Care Unit (tele-‐ICU) supports a high volume, high acuity population of patients. There is a high-‐ volume of incoming and outgoing calls, especially during the evening and night hours, through the tele-‐ICU hubs. The tele-‐ICU clinicians must be able to communicate effectively to team members in order to support the care of complex and critically ill patients while supporting and maintaining a standard to improve time to intervention. This study describes a software communication tool that will improve the time to intervention, over the paper-‐ driven communication format presently used in the tele-‐ICU. The software provides a multi-‐relational database of message instances to mine information for evaluation and quality improvement for all entities that touch the tele-‐ ICU. The software design incorporates years of critical care and software design experience combined with new skills acquired in an applied Health Informatics program. This software tool will function in the tele-‐ICU environment and perform as a front-‐end application that gathers, routes, and displays internal communication messages for intervention by priority and provider. Introduction The objective of this study is to improve communication within the tele-‐ICU. The primary objective is to develop and validate an electronic software tool to improve real-‐time communication and workflow in the tele-‐ICU hub. A secondary objective is to archive data for data mining to enable the development of new methods or the refinement of existing methods for further improvements in communication and workflow. This work indicates that there is a need for such a tool and that this tool can improve communication and workflow in the tele-‐ICU hub. The motivation for this software communication tool is that the tele-‐ICU staff currently has no formal message delivery mechanism within the hub environment or the existing software programs. The main goals of the current software systems are surveillance through displays and alerts, clinical documentation, on-‐line decision support, and outcomes tracking 1. Currently, the tele-‐ICU that we studied is using an internally developed, manual paper process to facilitate communication among multiple nursing providers to a single physician provider within the hub. The use of an electronic tool could aid in improving the real-‐time delivery, prioritization, and intervention of a request within the tele-‐ICU hub. The benefits of this type of communication tool are provided below. a. The tool provides a standardized format for clinical communication to organize content and decrease errors. b. The tool provides delivery and prioritization of multiple messages to a single physician provider, which improves the time to intervention for tele-‐ICU intervention and evaluation requests. c. The tool provides a tracking board display, which i. Allows messages to appear in a queue and be sorted and displayed by provider preference. (E.g., priority, originator, who it’s routed to, facility, time, etc.), and ii. Allows all team members to view workload in real-‐time, which assists in managing busy providers in the care of the patients and keeps workload moving forward. d. The administrator functionality of the tool allows unit leadership to customize data collection fields by adding elements or rearranging order sorts for display functionality while maintain data integrity. e. The preselected choices within the tool increase efficiency in recording message data and capture occurrence patterns for data mining. f. The electronic tracking of user and time stamping capabilities of the tool allow for a quantitative look at services provided and user metrics. g. The tool’s electronic message recording provides the ability to archive data for future evaluation. 1
1139
The result of this work is a software tool for communication and message delivery within the tele-‐ICU, which was developed and presented in conjoint theses, one by a clinician and one by a software engineer (authors) 2, 3. The first thesis describes the clinical path to design2. The second thesis describes the actual development of the software and its functionality 3. Background Clinicians in the tele-‐ICU juggle multiple requests for interventions on high-‐acuity patients across servicing hospitals. Demands are both external, like incoming requests by phone, and self-‐driven discovered events from surveillance monitoring that trigger an outgoing call to bedside staff4. The current software applications, however, do not provide a method for gathering front-‐end operations that come into and go out of the tele-‐ICU. Front-‐end operations such as information reception, gathering data, movement, and tracking are all important parts of a communication process in a high-‐volume, high-‐acuity area5. Capturing these data warrant further inspection and attention. Standardized Communication Message Collection/Format Communication between providers is extremely important in the high acuity and complex environment of the tele-‐ ICU. The efficiency and accuracy at which the information is disseminated to the appropriate interventionalist is the pivotal point of (timely) success versus (delayed possibly too late) missed opportunity or failure. The staff must possess skills in effective listening and have the experience to put together a message so that it can be interpreted without distortion or distraction6. The need to build a communication structure for effective information sharing is clearly evident. The link between skilled communication and patient safety is well documented in the literature 7. Many reviewing bodies have recognized the importance and potential pit falls of communication failures (e.g., the Joint Commission, the Leapfrog Group, and the National Institute of Medicine) 8, 9, 10. Unskilled communication leads to medical errors, delays in treatment, and decreased patient satisfaction. Responding to requests for intervention from a standard format decreases ambiguity, organizes content, allows the message to be globally understood, and gets the recipient to the purpose or need immediately and efficiently. This leads to overall safety and will decrease the time-‐to-‐intervention in the tele-‐ICU. Many methods for structuring written communication in the medical field have been developed. Acronyms used to delineate the format for communication are common. Historically, there are multiple formats such as: SOAP (Subjective, Objective, Assessment, Plan) notes, APIE (Assessment, Plan, Intervention, Evaluation) notes, SBAR (Situation, Background, Assessment, Recommendation) notes, SAFE (Situation, Assessment, Findings, Figures, Express and Expect), to name a few. All of these types of communication structures will organize the information/content in a logical and efficient way for presentation to the recipient. They encourage the composer to stick to a formal, concise, uniform way of gathering, organizing, and presenting data with the goal of minimizing error and increasing the efficiency of message communication. For the purpose of this investigation the Situation, Background, Assessment, and Recommendation (SBAR) format was used. The organization had implemented the use of it prior to beginning this study, and the staff both within the tele-‐ICU and the external sites had accepted it. The SBAR format was developed by Kaiser Permanente for communication in high-‐risk situations and is recognized by many as a quality initiative for improving skilled professional collaboration7. Tracking Board Technology/Movement/Tracking of Message The tele-‐ICU environment has multiple professional nurses simultaneously fielding requests and discovering issues at remote sites. With only one physician in “the box” at a time, the communication must be precise and triaged in a uniform fashion to reach the physician provider in a priority-‐sorted order. The tele-‐ICU has pre-‐designated priorities of Emergent, Urgent, Routine, and FYI (for your information). Standardized time frames for receipt of the message based on these intervention-‐based categories have also been suggested: Emergent, within 5 minutes; 2
1140
Urgent, within 10 minutes; Routine, within 15 minutes. Categories are chosen based on the severity of life threatening symptoms needing intervention. Currently, there is no way to quantify the time-‐to-‐intervention in this environment or to substantiate the reality of these time frames. The emergency department is an area of medicine that uses the concepts of urgency and triage as approaches to identifying which patients need immediate advanced provider attention. In reviewing the techniques used in Emergency Rooms, the concept of tracking boards seems to fit well in the workflow of the tele-‐ICU. Bisantz said, “The tracking board serves as a critical cognitive artifact, storing and communicating information across time and individuals.”11. Message collection and triage within the tele-‐ICU must travel to the appropriate user for intervention and resolution. When considering the complex, high-‐volume, and high-‐acuity environment of the tele-‐ICU, requests must be prioritized and timed for tracking and intervention. Tracking board technology facilitates a prioritized presentation of the requests in a standardized communication format. Prioritizing an open visible queue provides real-‐time tracking of the lifecycle of the request. It allows the event to be visible and tracked from arrival to intervention and then back to originator for closed-‐loop follow-‐up and monitoring by the support staff. Statement of the Problem Timely intervention is a major goal of tele-‐ICU surveillance, and all processes that translate and deliver communication to the point of intervention are critical. In this high-‐volume, high-‐acuity environment, the priority of response is the most important. As such, messages should be presented in a queue that is customized to the specific end-‐user. The volume of intervention requests increases during the evening and night hours. For example, the hub in this study recorded interventions for critically ill patients as greater than 21,000 interventions in 2010 and greater than 22,000 interventions in 2011. This volume justifies the use of timers, priority flagging, and important information (relevant user data) displays built into programming to direct, timely, efficient recognition and flow of information between the tele-‐ICU staff. Summary Communication in the tele-‐ICU is important and needs to be concise and efficient to maintain patient safety. Tele-‐ ICU messages must be timely and must be prioritized upon arrival to an advanced provider for interpretation and intervention. Electronic tools can be designed to support development of an efficient method to accomplish this. Proven formats for communication such as the SBAR can be used to organize messages. Electronic technology can aid in message gathering and movement within the tele-‐ICU. Tracking-‐board technology can be applied to move multiple messages to a single advanced provider for intervention. Tracking workload and workflow within a tele-‐ ICU can provide rich, discrete data to aid in education, patient safety, and strategic planning. These combined concepts, with proven tools for message delivery, will help improve patient outcomes, because they contribute a unique and novel approach for developing communication and tracking methods within the tele-‐ICU hub. Our software communication tool meets these needs. Methods The basis for the software tool was the analysis of two months of data collected from use of a paper tool in the tele-‐ICU. This analysis looked at the use of the tool and the compliance with fields within the tool. The analysis also included the frequency and description of types of data used in each field. The number of paper tool messages available and the historical record of calls and census were also compared. Paper SBAR tool sheets were collected each shift and stored for researchers to evaluate. The process of transcribing and transforming the dataset was done manually. The data format was simple enough to use a single ® row of column headers in an Excel worksheet. The call volume was a little more than 2,000 calls for both months. The raw data were examined for use, compliance, and utilization of specific fields present on the current paper tool (Figure 1). These statistics allowed us to evaluate the importance of a specific field for inclusion in the electronic tool. 3
1141
Figure 1. Compliance of Use: Paper based SBAR fields Compliance with form use also pointed us to high functioning users of the paper-‐based tool. These individuals were sought out early in the process to be members of the staff evaluation team. The post-‐processing data were used to take a second look at the data obtained and allowed us to re-‐sort data by common occurrence. Sorting this way allowed us to capture discrete elements, which we built into the tool for future data mining. The authors watched the operations within the tele-‐ICU and discussed process and workflow with both nurses and physicians. From these observations and interviews, current-‐state workflow was mapped, reviewed, and approved by all as authentic. After review of current state and gathering management objectives, a future state workflow was proposed, accepted and design began. Software Development A modular-‐tier application approach to the architecture separates the layers of the program. The architecture is separated in three tiers: (1) Web, (2) Business, and (3) Enterprise Information. This modular design allowed for different groups of developers to focus on specific layers and create a transparency to the database level. This design helped to provide development, maintenance and scalability of the back end process and database layers while not affecting the front-‐end processes. The login page and all other front-‐end web pages were part of web tier. All business logic like the ability to consume and process Admission Discharge Transfer (ADT) feed was in business tier. Database schema, data, and database server were in the enterprise Information tier (EIS). The architecture was mapped to a model-‐view-‐controller (MVC) framework. MVC model is an architecture pattern that has the emphases on code reusability and separation of concerns12. Model was analogous to the EIS tier, view was analogous to the web tier, and controller was analogous to the business tier. Because security is of utmost importance when working with protected health information (PHI), consideration for data security and integrity were reviewed throughout the design. Data elements in the requirements were defined in an object-‐oriented way using an entity-‐relationship diagram (ERD). Entities and their relationships were visualized in the ERD as the foundation of the database schema. An entity could have one-‐to-‐one, one-‐to-‐many, many-‐to-‐one, and many-‐to-‐many relationships to another entity. Additionally, the relationships between two entities could be unidirectional or bidirectional. An entity could also be thought of as a concept in the environment (e.g., forms, events, users, etc.). The relationships were the links between the entities. For instance, a user could have many forms and a form could have many events. 4
1142
The open source technology was chosen for its strengths in its openness, its fast-‐iteration of development, and its peer review processes13. The software was built on top of web platform, because services and data delivered by web technology could be controlled and managed centrally. This simplified the maintenance of the software for the developer. Also, accessing a web application for the end user was simple and easy. No download and installation of the software was needed. Java™ was used. It is an object-‐oriented, distributed, and multithreaded programming language. The Java™ Virtual Machine allows source code to be implemented once and executed in various combinations of operating systems and underlying hardware. It also has a wide adaption and a strong developer community. Java™ Enterprise Edition Platform (Java™ EE) Version 6 of the platform was chosen to be the technology framework. It was the enterprise solution for implementing “large-‐scale, multi-‐tiered, scalable, reliable, and secure network applications”14. Java™ Authentication and Authorization Service (JAAS) was used to secure the software from public and unauthorized access. Form-‐based authentication was used to authenticate users with user names and passwords. Authorization was based on user roles. User data had to be managed through the application. GlassFish Server (GlassFish) Open Source Edition 3.1.2 was used to host the software. Apache Derby (Derby) was used to store the data. The two technologies are based on Java™, they are open source, and they are the standard application server and database server15, 16. The software was developed using iterative and test-‐driven methods to ensure the requirements were fulfilled and the quality had been met. During the software development phases, features were released and improved on a weekly basis. JUnit, a Java™ unit-‐testing library was used to develop test cases. It was run against the feature implementation periodically. In addition to the programmable testing, quality assurance was done by the authors. Found bugs were reported and tracked on a spreadsheet on Google Drive and repaired. Results Design for Usability The software was designed with usability in mind. Attention to detail organizing features and functionality to deliver relevant information to user, to reduce barriers in data entry were considered. In addition to usability, the software provides the functionality of capturing form data about a request, tracking messages in a queue, and generating analytics about the communication workflow. User interface (UI) starts with a navigation menu that groups similar software functionalities. Message form and message queue are listed under Form and Queue, and personal reports are part of Your Analytics. For provider and health care associate (HCA), the group commands are as follows: the two menu groups (Form & Queue and Your Analytics), a logout button to sign out of the system, along with a display of user name and their role. For the administrator, there are two additional options for managing users and selection data. Users with different roles can be assigned different access levels to perform different tasks. Search functionality is integrated into the discrete fields of facility, bed, situation, background, assessment, recommendation, action, and provider. When the user looks up an item by searching it, the list filters to only show the relevant choices. The design included the event history of a message listed in chronological order. The event types, event timestamp, by whom, and the target user of the Routed event are displayed. The historical perspective of a message provides complete transparency. This information is displayed next to the opened form in a non-‐intrusive way. The user can alter the view to display or hide. Notification flags appear on the top right-‐hand corner in response to a user’s actions and were built to communicate success or failure of a message command. The notification will fade out in 15 seconds automatically or can be closed manually before the 15 seconds. If an input validation error is encountered, an error message will inform the user what went wrong and how to fix it. The goal is to be informative and not disruptive and acts only as an informational message to complete the event. 5
1143
Software Features The tool design includes the ability to: 1. View all messages and sort by provider preference 2. Time and user stamp all interactions with message instance (Track time to intervention) 3. Choose preselected commonly used data options (Record discrete data elements) 4. Select functionality in the fields by toggle, double click, drop down, and smart search 5. Work with auto-‐populating and re-‐routing smart field 6. Save any message instance before routing 7. Implement Administrator functionality for user management, shift presence selection, viewed option order sort, and additional data base fields for new selection choices, with the ability to retire old, if needed Form Design When user logs in to the system, a new form is presented. The layout of the form and data are based on the utilization analysis of the paper form. Facility and bed data are based on the results of organizational structure, and the provider data are based on the results of social structure. Save and Route buttons are based on the message lifecycle in future state. Predefined choices in the Situation, Background, Assessment, Recommendation, and Action (SBARA) fields are based on the analysis of data pattern (Figure 2). The size of the form is designed to fit in a 19-‐inch monitor, which is the standard dimension used in the tele-‐ICU hub. The page does not have a scroll bar, because scrolling takes time and minimizing non-‐essential movement in the software, this creates a better user experience. It is also why tabs are used in the SBARA fields. If the fields were laid out one after another the form would be too long and wide to view, and a scroll bar would be required to navigate around the page.
Figure 2. Tele-‐ICU Communication Tool Form Design
6
1144
Form Features For usability and data quality, predefined choices are provided. There are different ways of present input selections: in a single selection display or multi selection display, both provide discrete data elements. The design decisions are based on three factors, the amount of data to be displayed, the time taken to look up an item, and the time taken to select it. The balance between screen real estate and the ease of viewing the options is delicate, sometimes it can be subjective and requires user feedback. Currently, there are 65 staff members in this tele-‐ICU hub. User selects one person to route to. Single selection drop-‐down list of user names and dynamic list functionality is a more suitable UI component. Designing required fields to ensure data integrity and usefulness such as Patient name, facility/bed, and incoming or outgoing call are preset to save a message. If one of these fields is not entered, the form cannot be saved to the system. Similarly, two more required fields exist to route: they are priority and provider. These data have to be entered to make the routed information relevant. Software validates these fields. Once the necessary data are entered, user can route the message by clicking on the Route button. And the message will appear in the message queue. Queue Design The user can track messages in the queue through its sorting mechanism. Messages are sorted automatically using three criteria. The first criterion is whom the message is routed to. Then, the messages are sorted by priority. Lastly, they are sorted by routed time so that the earliest shows up first. This draws provider attention immediately to the most urgent and time critical messages first. Manual sorting of the queue is possible by the five message attributes. Clicking on a column header sorts to providers’ preference. If desired to find a particular message, the queue can also be searched through the smart text dynamic filtering fields. When more information about a message is needed, the user can click on the open-‐detail button to view the detail (Figure 3). When that happens, the system generates a timestamp of the provider reading the message.
Figure 3. Tele-‐ICU Communication Tool Queue View
7
1145
Queue Features The message queue is updated in real-‐time with new data by server push technology. When there are new data, server pushes them to the client browser. This is fundamentally different than data polling where client consistently pulls data from the server regardless of the existence of new data. Polling can take up server’s resource and will not scale well. If the number of messages goes over 15, pagination appears and only 15 messages are displayed per page to minimize scrolling. The current page information and the page navigation are shown first. Components include, “Jump to Page selection” (displaying each page number from the first page to the last) and “the number of messages per page” (can be set by selecting 5, 10, 15, 20 or 50 value). The user can decide to view all the routed messages in one page or view a manageable list with pagination. The sorting and searching mechanisms perform the same way, independent of the use of multiple pages; it is sorted on or searched against the whole queue. Analytics reporting was designed to be helpful in presenting information about the communication workflow and showcase the power of reporting functionality and its potential. Presenting analytics visually in reports and dashboards empowers user to perform a self-‐evaluation and allows leadership to design visual cues that support strategic goals of care delivery. Designed in the software are three report metrics on communication activities that are personalized for the individual user. Each report has two measures. The first measure is based on today’s activities; the second measure is based the average value of all user interactions. The first reporting metric is time to intervention in minutes (it is calculated by subtracting the time of first MD reading the message from the time when the message was first created and is categorized by priorities from the most critical to the least). This keeps the user informed about whether or not the requests have been addressed in a timely fashion. The second reporting metric is about the real-‐time reporting of message volume by priorities (information about personal workload today compared to their daily average). The third and final metric is message volume from the perspective of the different message events (the number of messages created, read, updated, routed, and resolved). Administrative Functions were included to enhance the usability of the software. An administrator of the system can add new user, manage user access, and edit user information. Administrators can also create new options to be displayed in a discrete field. Options in these fields can be manually ordered and configured as shown or hidden from user selection. Software quality assurance was confirmed by testing functions featured in the form, the message queue, the personalized analytics, and the administrative data management, validated against test scripts in which various use cases demonstrated and confirmed that it performs as expected. Discussion The application of informatics to the day-‐to-‐day practice of healthcare and real-‐time use of the tool and its design elements and functionality, combine to solve electronic tracking and message delivery in the tele-‐ICU. The close partnership of the specialized clinician and the software engineer has facilitated the development and creation of an electronic tool to improve patient care and workflow tracking. Communication, and its message elements, can be gathered in a systematic way. This will improve real-‐time decision-‐making by improving the time to intervention. Reducing the time to intervention will improve patient outcomes and provide better data for evaluation and quality improvement. Specifically three functionalities not possible with a paper process and their benefits to the stakeholders of the tele-‐ICU are described below. Benefits of the “Save” Functionality Tele-‐ICU RNs manage a patient assignment of 30 to 40 patients per assignment. As calls come in requesting help or evaluation, the tele-‐ICU RN assigned to the facility takes the call. They listen, gather data from caller, and begin to collect information for message development. After leaving the caller, the RN often spends moments looking at the patient’s medical record and physiologic trending to gather further information to evaluate the request. Almost immediately, due to experience, the RN has a sense of the level of priority for the call. If another call is 8
1146
received prior to completion of the data collection, the RN can choose to save the information and accept the start of a new message. The software is designed with the functionality to allow the end-‐user to store messages prior to completion and honor higher priority calls as needed. After completing the higher priority call, they can return to the same place in the older call and complete the previous message for delivery. This flexibility is essential for the complex demands and volume placed on the tele-‐ICU RN. Benefits of Electronic Prioritization and Tracking Board Technology The capability to set message priorities allows the tracking board display to sort and present visual messages in order of importance. Thus, the physician gets a standard message presentation from all providers in one triaged format and provides the visual time displays for monitoring, which help to assure timely intervention. The tracking-‐board design of the queue affords all providers in the room a visual perception of incoming workload and volume by facility. It sorts by individual users, which allows multiple users to have their own sort preferences displayed. It allows the leadership staff and staff in slower geographical areas a visual on work pending and the ability to jump in and help with workload management during high-‐volume times. It also organizes messages and safeguards follow through in a break relief or shift change event so messages are not lost in transition. These intervention requests are significantly more complex and present a greater risk of missed or lost messages during transitions with a paper process. Benefits of Data Mining Having the life cycle and contents of a communication message stored and tracked electronically has many benefits to all levels of the organization. The benefits can be looked at from three different perspectives: (1) the tele-‐ICU hub, (2) the external facilities utilizing the tele-‐ICU, and (3) the corporate leadership teams. The tele-‐ICU hub can benefit from examination of data both qualitatively and quantitatively on many different service metrics. Some of the metrics, such as time to intervention, types of requests, acuity, and volume by time of day, staffing patterns, and types of outreach education needed improve real-‐time mentoring and clinical decision support tools. Provider performance in response time and type of interventions help visualize outcomes in terms of patient care delivery improvement and strategic planning. The external facilities using the tele-‐ICU hub can benefit from an examination of the types of issues communication messages to the tele-‐ICU contain. Types of support requested can lead to review and improvement of in house policies and targeted educational needs for staff and ancillary services. Support can be sorted into many different categories, such as decision support or consultation, physical support in the form of physician orders, either new, clarifying or discrepancy resolution, test evaluation and intervention or just family and patient communication needs. Examining at a local level could aid in strategic planning for facility growth and development. All of these areas benefit patient safety and patient satisfaction. The corporate structure has a responsibility to lead, direct, and support the external sites in accomplishing their mission as a community care provider. The data has the potential to give a partial view of the needs, resource, success, and limitations of a facility. The tele-‐ICU hub can aid in surveillance and intervention in large corporate initiatives to improve patient care such as the national sepsis campaign. The results of this research are currently being implemented in the tele-‐ICU on a SharePoint platform, by the regional facility. The next step is to perform a pilot test of this software tool in a tele-‐ICU to evaluate its effectiveness under actual operational conditions. It should be noted that this front-‐end software module could be integrated directly into the primary software being used in the tele-‐ICU. It should also be noted that this type of front-‐end application can have significance in other clinical arenas that require triage and priority message queues to move messages amongst clinical providers. Acknowledgements This work summarizes two theses that address a new software communication tool for the tele-‐ICU. Denise 2 Pimintel’s thesis describes the clinical path to design , while Shang Wei’s thesis describes the actual development
9
1147
3
of the software and its functionality . We would like to acknowledge our thesis committee advisors, Dr. Odor (Chair), Dr. Malyj and Teresa Rincon, RN (Committee members). Works Cited 1. Pimintel DM. A Communication Tool for the Tele-‐ICU: A Clinician's Perspective. 2013. 2. Wei SH. A Communication Tool for the Tele-‐ICU: A Software Engineer's Perspective. 2013. 3. Koninklijke Philips Electronics N.V. eICU Media Room. [Online]; 2012 [cited 2013 2 23. Available from: http://eicu.mediaroom.com/. 4. Venditti A, Ronk C, Kopenhaver T, Fetterman S. Tele-‐ICU “Myth Busters”. AACN Advanced Critical Care. 2012; 23(3): p. 302–311. 5. Rufo R. Virtual ICU Foundations for healthier environment. Nursing Management. 2007 February: p. 32-‐39. 6. The AACN Tele-‐ICU task force. American Association of Critical-‐Care Nurses. [Online];2013. 7. Goran S F. Partnership for a Healthy Work Environment: Tele-‐ICU/ICU Collaborative. AACN Advanced Critical Care. 2012; 23(3): p. 289-‐301. 8. Joint Commission on Accreditation of Healthcare Organizations. The Joint Commission Guide to Improving Staff Communication Oakbrook Terrace: Joint Commission Resources; 2005. 9. Leapfrog Group. Leapfrog Hospital Quality and Safety Survey. Washington: 2006. 10. Committee on Quality of Health Care in America, Institute of Medicine. Crossing the Quality Chasm: A New Health System for the 21st Century. Washington, DC: Institute of Medicine, Committee on Quality of Health Care in America; 2001. 11. Bisantz A M ea. Emergency department status boards: A case study in information systems transition. Journal of Cognitive Engineering and Decision Making. 2010; 4(1): p. 39-‐68. 12. Wikipedia. [Online]; 2013 [cited 2013. Available from: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller. 13. Bergquist M, Ljungberg J. The power of gifts: organizing social relationships in open source communities. Information Systems Journal. 2008: p. 305-‐320. 14. Oracle. [Online]; 2011 [cited 2012 December 17. Available from: http://docs.oracle.com/javaee/6/firstcup/doc/gcrky.html. 15. Java.net. [Online]; 2012 [cited 2012 December 17. Available from: http://glassfish.java.net/. 16. The Apache Software Foundation. [Online]; 2012 [cited 2012 December 17. Available from: http://db.apache.org/derby/.
10
1148
1
2
Denise M. Pimintel, RN, MN , Shang Heng Wei, BS , Alberto Odor, MD University of California, Davis, California 1 2 ( Student; Advisor) Abstract The Tele Intensive Care Unit (tele-‐ICU) supports a high volume, high acuity population of patients. There is a high-‐ volume of incoming and outgoing calls, especially during the evening and night hours, through the tele-‐ICU hubs. The tele-‐ICU clinicians must be able to communicate effectively to team members in order to support the care of complex and critically ill patients while supporting and maintaining a standard to improve time to intervention. This study describes a software communication tool that will improve the time to intervention, over the paper-‐ driven communication format presently used in the tele-‐ICU. The software provides a multi-‐relational database of message instances to mine information for evaluation and quality improvement for all entities that touch the tele-‐ ICU. The software design incorporates years of critical care and software design experience combined with new skills acquired in an applied Health Informatics program. This software tool will function in the tele-‐ICU environment and perform as a front-‐end application that gathers, routes, and displays internal communication messages for intervention by priority and provider. Introduction The objective of this study is to improve communication within the tele-‐ICU. The primary objective is to develop and validate an electronic software tool to improve real-‐time communication and workflow in the tele-‐ICU hub. A secondary objective is to archive data for data mining to enable the development of new methods or the refinement of existing methods for further improvements in communication and workflow. This work indicates that there is a need for such a tool and that this tool can improve communication and workflow in the tele-‐ICU hub. The motivation for this software communication tool is that the tele-‐ICU staff currently has no formal message delivery mechanism within the hub environment or the existing software programs. The main goals of the current software systems are surveillance through displays and alerts, clinical documentation, on-‐line decision support, and outcomes tracking 1. Currently, the tele-‐ICU that we studied is using an internally developed, manual paper process to facilitate communication among multiple nursing providers to a single physician provider within the hub. The use of an electronic tool could aid in improving the real-‐time delivery, prioritization, and intervention of a request within the tele-‐ICU hub. The benefits of this type of communication tool are provided below. a. The tool provides a standardized format for clinical communication to organize content and decrease errors. b. The tool provides delivery and prioritization of multiple messages to a single physician provider, which improves the time to intervention for tele-‐ICU intervention and evaluation requests. c. The tool provides a tracking board display, which i. Allows messages to appear in a queue and be sorted and displayed by provider preference. (E.g., priority, originator, who it’s routed to, facility, time, etc.), and ii. Allows all team members to view workload in real-‐time, which assists in managing busy providers in the care of the patients and keeps workload moving forward. d. The administrator functionality of the tool allows unit leadership to customize data collection fields by adding elements or rearranging order sorts for display functionality while maintain data integrity. e. The preselected choices within the tool increase efficiency in recording message data and capture occurrence patterns for data mining. f. The electronic tracking of user and time stamping capabilities of the tool allow for a quantitative look at services provided and user metrics. g. The tool’s electronic message recording provides the ability to archive data for future evaluation. 1
1139
The result of this work is a software tool for communication and message delivery within the tele-‐ICU, which was developed and presented in conjoint theses, one by a clinician and one by a software engineer (authors) 2, 3. The first thesis describes the clinical path to design2. The second thesis describes the actual development of the software and its functionality 3. Background Clinicians in the tele-‐ICU juggle multiple requests for interventions on high-‐acuity patients across servicing hospitals. Demands are both external, like incoming requests by phone, and self-‐driven discovered events from surveillance monitoring that trigger an outgoing call to bedside staff4. The current software applications, however, do not provide a method for gathering front-‐end operations that come into and go out of the tele-‐ICU. Front-‐end operations such as information reception, gathering data, movement, and tracking are all important parts of a communication process in a high-‐volume, high-‐acuity area5. Capturing these data warrant further inspection and attention. Standardized Communication Message Collection/Format Communication between providers is extremely important in the high acuity and complex environment of the tele-‐ ICU. The efficiency and accuracy at which the information is disseminated to the appropriate interventionalist is the pivotal point of (timely) success versus (delayed possibly too late) missed opportunity or failure. The staff must possess skills in effective listening and have the experience to put together a message so that it can be interpreted without distortion or distraction6. The need to build a communication structure for effective information sharing is clearly evident. The link between skilled communication and patient safety is well documented in the literature 7. Many reviewing bodies have recognized the importance and potential pit falls of communication failures (e.g., the Joint Commission, the Leapfrog Group, and the National Institute of Medicine) 8, 9, 10. Unskilled communication leads to medical errors, delays in treatment, and decreased patient satisfaction. Responding to requests for intervention from a standard format decreases ambiguity, organizes content, allows the message to be globally understood, and gets the recipient to the purpose or need immediately and efficiently. This leads to overall safety and will decrease the time-‐to-‐intervention in the tele-‐ICU. Many methods for structuring written communication in the medical field have been developed. Acronyms used to delineate the format for communication are common. Historically, there are multiple formats such as: SOAP (Subjective, Objective, Assessment, Plan) notes, APIE (Assessment, Plan, Intervention, Evaluation) notes, SBAR (Situation, Background, Assessment, Recommendation) notes, SAFE (Situation, Assessment, Findings, Figures, Express and Expect), to name a few. All of these types of communication structures will organize the information/content in a logical and efficient way for presentation to the recipient. They encourage the composer to stick to a formal, concise, uniform way of gathering, organizing, and presenting data with the goal of minimizing error and increasing the efficiency of message communication. For the purpose of this investigation the Situation, Background, Assessment, and Recommendation (SBAR) format was used. The organization had implemented the use of it prior to beginning this study, and the staff both within the tele-‐ICU and the external sites had accepted it. The SBAR format was developed by Kaiser Permanente for communication in high-‐risk situations and is recognized by many as a quality initiative for improving skilled professional collaboration7. Tracking Board Technology/Movement/Tracking of Message The tele-‐ICU environment has multiple professional nurses simultaneously fielding requests and discovering issues at remote sites. With only one physician in “the box” at a time, the communication must be precise and triaged in a uniform fashion to reach the physician provider in a priority-‐sorted order. The tele-‐ICU has pre-‐designated priorities of Emergent, Urgent, Routine, and FYI (for your information). Standardized time frames for receipt of the message based on these intervention-‐based categories have also been suggested: Emergent, within 5 minutes; 2
1140
Urgent, within 10 minutes; Routine, within 15 minutes. Categories are chosen based on the severity of life threatening symptoms needing intervention. Currently, there is no way to quantify the time-‐to-‐intervention in this environment or to substantiate the reality of these time frames. The emergency department is an area of medicine that uses the concepts of urgency and triage as approaches to identifying which patients need immediate advanced provider attention. In reviewing the techniques used in Emergency Rooms, the concept of tracking boards seems to fit well in the workflow of the tele-‐ICU. Bisantz said, “The tracking board serves as a critical cognitive artifact, storing and communicating information across time and individuals.”11. Message collection and triage within the tele-‐ICU must travel to the appropriate user for intervention and resolution. When considering the complex, high-‐volume, and high-‐acuity environment of the tele-‐ICU, requests must be prioritized and timed for tracking and intervention. Tracking board technology facilitates a prioritized presentation of the requests in a standardized communication format. Prioritizing an open visible queue provides real-‐time tracking of the lifecycle of the request. It allows the event to be visible and tracked from arrival to intervention and then back to originator for closed-‐loop follow-‐up and monitoring by the support staff. Statement of the Problem Timely intervention is a major goal of tele-‐ICU surveillance, and all processes that translate and deliver communication to the point of intervention are critical. In this high-‐volume, high-‐acuity environment, the priority of response is the most important. As such, messages should be presented in a queue that is customized to the specific end-‐user. The volume of intervention requests increases during the evening and night hours. For example, the hub in this study recorded interventions for critically ill patients as greater than 21,000 interventions in 2010 and greater than 22,000 interventions in 2011. This volume justifies the use of timers, priority flagging, and important information (relevant user data) displays built into programming to direct, timely, efficient recognition and flow of information between the tele-‐ICU staff. Summary Communication in the tele-‐ICU is important and needs to be concise and efficient to maintain patient safety. Tele-‐ ICU messages must be timely and must be prioritized upon arrival to an advanced provider for interpretation and intervention. Electronic tools can be designed to support development of an efficient method to accomplish this. Proven formats for communication such as the SBAR can be used to organize messages. Electronic technology can aid in message gathering and movement within the tele-‐ICU. Tracking-‐board technology can be applied to move multiple messages to a single advanced provider for intervention. Tracking workload and workflow within a tele-‐ ICU can provide rich, discrete data to aid in education, patient safety, and strategic planning. These combined concepts, with proven tools for message delivery, will help improve patient outcomes, because they contribute a unique and novel approach for developing communication and tracking methods within the tele-‐ICU hub. Our software communication tool meets these needs. Methods The basis for the software tool was the analysis of two months of data collected from use of a paper tool in the tele-‐ICU. This analysis looked at the use of the tool and the compliance with fields within the tool. The analysis also included the frequency and description of types of data used in each field. The number of paper tool messages available and the historical record of calls and census were also compared. Paper SBAR tool sheets were collected each shift and stored for researchers to evaluate. The process of transcribing and transforming the dataset was done manually. The data format was simple enough to use a single ® row of column headers in an Excel worksheet. The call volume was a little more than 2,000 calls for both months. The raw data were examined for use, compliance, and utilization of specific fields present on the current paper tool (Figure 1). These statistics allowed us to evaluate the importance of a specific field for inclusion in the electronic tool. 3
1141
Figure 1. Compliance of Use: Paper based SBAR fields Compliance with form use also pointed us to high functioning users of the paper-‐based tool. These individuals were sought out early in the process to be members of the staff evaluation team. The post-‐processing data were used to take a second look at the data obtained and allowed us to re-‐sort data by common occurrence. Sorting this way allowed us to capture discrete elements, which we built into the tool for future data mining. The authors watched the operations within the tele-‐ICU and discussed process and workflow with both nurses and physicians. From these observations and interviews, current-‐state workflow was mapped, reviewed, and approved by all as authentic. After review of current state and gathering management objectives, a future state workflow was proposed, accepted and design began. Software Development A modular-‐tier application approach to the architecture separates the layers of the program. The architecture is separated in three tiers: (1) Web, (2) Business, and (3) Enterprise Information. This modular design allowed for different groups of developers to focus on specific layers and create a transparency to the database level. This design helped to provide development, maintenance and scalability of the back end process and database layers while not affecting the front-‐end processes. The login page and all other front-‐end web pages were part of web tier. All business logic like the ability to consume and process Admission Discharge Transfer (ADT) feed was in business tier. Database schema, data, and database server were in the enterprise Information tier (EIS). The architecture was mapped to a model-‐view-‐controller (MVC) framework. MVC model is an architecture pattern that has the emphases on code reusability and separation of concerns12. Model was analogous to the EIS tier, view was analogous to the web tier, and controller was analogous to the business tier. Because security is of utmost importance when working with protected health information (PHI), consideration for data security and integrity were reviewed throughout the design. Data elements in the requirements were defined in an object-‐oriented way using an entity-‐relationship diagram (ERD). Entities and their relationships were visualized in the ERD as the foundation of the database schema. An entity could have one-‐to-‐one, one-‐to-‐many, many-‐to-‐one, and many-‐to-‐many relationships to another entity. Additionally, the relationships between two entities could be unidirectional or bidirectional. An entity could also be thought of as a concept in the environment (e.g., forms, events, users, etc.). The relationships were the links between the entities. For instance, a user could have many forms and a form could have many events. 4
1142
The open source technology was chosen for its strengths in its openness, its fast-‐iteration of development, and its peer review processes13. The software was built on top of web platform, because services and data delivered by web technology could be controlled and managed centrally. This simplified the maintenance of the software for the developer. Also, accessing a web application for the end user was simple and easy. No download and installation of the software was needed. Java™ was used. It is an object-‐oriented, distributed, and multithreaded programming language. The Java™ Virtual Machine allows source code to be implemented once and executed in various combinations of operating systems and underlying hardware. It also has a wide adaption and a strong developer community. Java™ Enterprise Edition Platform (Java™ EE) Version 6 of the platform was chosen to be the technology framework. It was the enterprise solution for implementing “large-‐scale, multi-‐tiered, scalable, reliable, and secure network applications”14. Java™ Authentication and Authorization Service (JAAS) was used to secure the software from public and unauthorized access. Form-‐based authentication was used to authenticate users with user names and passwords. Authorization was based on user roles. User data had to be managed through the application. GlassFish Server (GlassFish) Open Source Edition 3.1.2 was used to host the software. Apache Derby (Derby) was used to store the data. The two technologies are based on Java™, they are open source, and they are the standard application server and database server15, 16. The software was developed using iterative and test-‐driven methods to ensure the requirements were fulfilled and the quality had been met. During the software development phases, features were released and improved on a weekly basis. JUnit, a Java™ unit-‐testing library was used to develop test cases. It was run against the feature implementation periodically. In addition to the programmable testing, quality assurance was done by the authors. Found bugs were reported and tracked on a spreadsheet on Google Drive and repaired. Results Design for Usability The software was designed with usability in mind. Attention to detail organizing features and functionality to deliver relevant information to user, to reduce barriers in data entry were considered. In addition to usability, the software provides the functionality of capturing form data about a request, tracking messages in a queue, and generating analytics about the communication workflow. User interface (UI) starts with a navigation menu that groups similar software functionalities. Message form and message queue are listed under Form and Queue, and personal reports are part of Your Analytics. For provider and health care associate (HCA), the group commands are as follows: the two menu groups (Form & Queue and Your Analytics), a logout button to sign out of the system, along with a display of user name and their role. For the administrator, there are two additional options for managing users and selection data. Users with different roles can be assigned different access levels to perform different tasks. Search functionality is integrated into the discrete fields of facility, bed, situation, background, assessment, recommendation, action, and provider. When the user looks up an item by searching it, the list filters to only show the relevant choices. The design included the event history of a message listed in chronological order. The event types, event timestamp, by whom, and the target user of the Routed event are displayed. The historical perspective of a message provides complete transparency. This information is displayed next to the opened form in a non-‐intrusive way. The user can alter the view to display or hide. Notification flags appear on the top right-‐hand corner in response to a user’s actions and were built to communicate success or failure of a message command. The notification will fade out in 15 seconds automatically or can be closed manually before the 15 seconds. If an input validation error is encountered, an error message will inform the user what went wrong and how to fix it. The goal is to be informative and not disruptive and acts only as an informational message to complete the event. 5
1143
Software Features The tool design includes the ability to: 1. View all messages and sort by provider preference 2. Time and user stamp all interactions with message instance (Track time to intervention) 3. Choose preselected commonly used data options (Record discrete data elements) 4. Select functionality in the fields by toggle, double click, drop down, and smart search 5. Work with auto-‐populating and re-‐routing smart field 6. Save any message instance before routing 7. Implement Administrator functionality for user management, shift presence selection, viewed option order sort, and additional data base fields for new selection choices, with the ability to retire old, if needed Form Design When user logs in to the system, a new form is presented. The layout of the form and data are based on the utilization analysis of the paper form. Facility and bed data are based on the results of organizational structure, and the provider data are based on the results of social structure. Save and Route buttons are based on the message lifecycle in future state. Predefined choices in the Situation, Background, Assessment, Recommendation, and Action (SBARA) fields are based on the analysis of data pattern (Figure 2). The size of the form is designed to fit in a 19-‐inch monitor, which is the standard dimension used in the tele-‐ICU hub. The page does not have a scroll bar, because scrolling takes time and minimizing non-‐essential movement in the software, this creates a better user experience. It is also why tabs are used in the SBARA fields. If the fields were laid out one after another the form would be too long and wide to view, and a scroll bar would be required to navigate around the page.
Figure 2. Tele-‐ICU Communication Tool Form Design
6
1144
Form Features For usability and data quality, predefined choices are provided. There are different ways of present input selections: in a single selection display or multi selection display, both provide discrete data elements. The design decisions are based on three factors, the amount of data to be displayed, the time taken to look up an item, and the time taken to select it. The balance between screen real estate and the ease of viewing the options is delicate, sometimes it can be subjective and requires user feedback. Currently, there are 65 staff members in this tele-‐ICU hub. User selects one person to route to. Single selection drop-‐down list of user names and dynamic list functionality is a more suitable UI component. Designing required fields to ensure data integrity and usefulness such as Patient name, facility/bed, and incoming or outgoing call are preset to save a message. If one of these fields is not entered, the form cannot be saved to the system. Similarly, two more required fields exist to route: they are priority and provider. These data have to be entered to make the routed information relevant. Software validates these fields. Once the necessary data are entered, user can route the message by clicking on the Route button. And the message will appear in the message queue. Queue Design The user can track messages in the queue through its sorting mechanism. Messages are sorted automatically using three criteria. The first criterion is whom the message is routed to. Then, the messages are sorted by priority. Lastly, they are sorted by routed time so that the earliest shows up first. This draws provider attention immediately to the most urgent and time critical messages first. Manual sorting of the queue is possible by the five message attributes. Clicking on a column header sorts to providers’ preference. If desired to find a particular message, the queue can also be searched through the smart text dynamic filtering fields. When more information about a message is needed, the user can click on the open-‐detail button to view the detail (Figure 3). When that happens, the system generates a timestamp of the provider reading the message.
Figure 3. Tele-‐ICU Communication Tool Queue View
7
1145
Queue Features The message queue is updated in real-‐time with new data by server push technology. When there are new data, server pushes them to the client browser. This is fundamentally different than data polling where client consistently pulls data from the server regardless of the existence of new data. Polling can take up server’s resource and will not scale well. If the number of messages goes over 15, pagination appears and only 15 messages are displayed per page to minimize scrolling. The current page information and the page navigation are shown first. Components include, “Jump to Page selection” (displaying each page number from the first page to the last) and “the number of messages per page” (can be set by selecting 5, 10, 15, 20 or 50 value). The user can decide to view all the routed messages in one page or view a manageable list with pagination. The sorting and searching mechanisms perform the same way, independent of the use of multiple pages; it is sorted on or searched against the whole queue. Analytics reporting was designed to be helpful in presenting information about the communication workflow and showcase the power of reporting functionality and its potential. Presenting analytics visually in reports and dashboards empowers user to perform a self-‐evaluation and allows leadership to design visual cues that support strategic goals of care delivery. Designed in the software are three report metrics on communication activities that are personalized for the individual user. Each report has two measures. The first measure is based on today’s activities; the second measure is based the average value of all user interactions. The first reporting metric is time to intervention in minutes (it is calculated by subtracting the time of first MD reading the message from the time when the message was first created and is categorized by priorities from the most critical to the least). This keeps the user informed about whether or not the requests have been addressed in a timely fashion. The second reporting metric is about the real-‐time reporting of message volume by priorities (information about personal workload today compared to their daily average). The third and final metric is message volume from the perspective of the different message events (the number of messages created, read, updated, routed, and resolved). Administrative Functions were included to enhance the usability of the software. An administrator of the system can add new user, manage user access, and edit user information. Administrators can also create new options to be displayed in a discrete field. Options in these fields can be manually ordered and configured as shown or hidden from user selection. Software quality assurance was confirmed by testing functions featured in the form, the message queue, the personalized analytics, and the administrative data management, validated against test scripts in which various use cases demonstrated and confirmed that it performs as expected. Discussion The application of informatics to the day-‐to-‐day practice of healthcare and real-‐time use of the tool and its design elements and functionality, combine to solve electronic tracking and message delivery in the tele-‐ICU. The close partnership of the specialized clinician and the software engineer has facilitated the development and creation of an electronic tool to improve patient care and workflow tracking. Communication, and its message elements, can be gathered in a systematic way. This will improve real-‐time decision-‐making by improving the time to intervention. Reducing the time to intervention will improve patient outcomes and provide better data for evaluation and quality improvement. Specifically three functionalities not possible with a paper process and their benefits to the stakeholders of the tele-‐ICU are described below. Benefits of the “Save” Functionality Tele-‐ICU RNs manage a patient assignment of 30 to 40 patients per assignment. As calls come in requesting help or evaluation, the tele-‐ICU RN assigned to the facility takes the call. They listen, gather data from caller, and begin to collect information for message development. After leaving the caller, the RN often spends moments looking at the patient’s medical record and physiologic trending to gather further information to evaluate the request. Almost immediately, due to experience, the RN has a sense of the level of priority for the call. If another call is 8
1146
received prior to completion of the data collection, the RN can choose to save the information and accept the start of a new message. The software is designed with the functionality to allow the end-‐user to store messages prior to completion and honor higher priority calls as needed. After completing the higher priority call, they can return to the same place in the older call and complete the previous message for delivery. This flexibility is essential for the complex demands and volume placed on the tele-‐ICU RN. Benefits of Electronic Prioritization and Tracking Board Technology The capability to set message priorities allows the tracking board display to sort and present visual messages in order of importance. Thus, the physician gets a standard message presentation from all providers in one triaged format and provides the visual time displays for monitoring, which help to assure timely intervention. The tracking-‐board design of the queue affords all providers in the room a visual perception of incoming workload and volume by facility. It sorts by individual users, which allows multiple users to have their own sort preferences displayed. It allows the leadership staff and staff in slower geographical areas a visual on work pending and the ability to jump in and help with workload management during high-‐volume times. It also organizes messages and safeguards follow through in a break relief or shift change event so messages are not lost in transition. These intervention requests are significantly more complex and present a greater risk of missed or lost messages during transitions with a paper process. Benefits of Data Mining Having the life cycle and contents of a communication message stored and tracked electronically has many benefits to all levels of the organization. The benefits can be looked at from three different perspectives: (1) the tele-‐ICU hub, (2) the external facilities utilizing the tele-‐ICU, and (3) the corporate leadership teams. The tele-‐ICU hub can benefit from examination of data both qualitatively and quantitatively on many different service metrics. Some of the metrics, such as time to intervention, types of requests, acuity, and volume by time of day, staffing patterns, and types of outreach education needed improve real-‐time mentoring and clinical decision support tools. Provider performance in response time and type of interventions help visualize outcomes in terms of patient care delivery improvement and strategic planning. The external facilities using the tele-‐ICU hub can benefit from an examination of the types of issues communication messages to the tele-‐ICU contain. Types of support requested can lead to review and improvement of in house policies and targeted educational needs for staff and ancillary services. Support can be sorted into many different categories, such as decision support or consultation, physical support in the form of physician orders, either new, clarifying or discrepancy resolution, test evaluation and intervention or just family and patient communication needs. Examining at a local level could aid in strategic planning for facility growth and development. All of these areas benefit patient safety and patient satisfaction. The corporate structure has a responsibility to lead, direct, and support the external sites in accomplishing their mission as a community care provider. The data has the potential to give a partial view of the needs, resource, success, and limitations of a facility. The tele-‐ICU hub can aid in surveillance and intervention in large corporate initiatives to improve patient care such as the national sepsis campaign. The results of this research are currently being implemented in the tele-‐ICU on a SharePoint platform, by the regional facility. The next step is to perform a pilot test of this software tool in a tele-‐ICU to evaluate its effectiveness under actual operational conditions. It should be noted that this front-‐end software module could be integrated directly into the primary software being used in the tele-‐ICU. It should also be noted that this type of front-‐end application can have significance in other clinical arenas that require triage and priority message queues to move messages amongst clinical providers. Acknowledgements This work summarizes two theses that address a new software communication tool for the tele-‐ICU. Denise 2 Pimintel’s thesis describes the clinical path to design , while Shang Wei’s thesis describes the actual development
9
1147
3
of the software and its functionality . We would like to acknowledge our thesis committee advisors, Dr. Odor (Chair), Dr. Malyj and Teresa Rincon, RN (Committee members). Works Cited 1. Pimintel DM. A Communication Tool for the Tele-‐ICU: A Clinician's Perspective. 2013. 2. Wei SH. A Communication Tool for the Tele-‐ICU: A Software Engineer's Perspective. 2013. 3. Koninklijke Philips Electronics N.V. eICU Media Room. [Online]; 2012 [cited 2013 2 23. Available from: http://eicu.mediaroom.com/. 4. Venditti A, Ronk C, Kopenhaver T, Fetterman S. Tele-‐ICU “Myth Busters”. AACN Advanced Critical Care. 2012; 23(3): p. 302–311. 5. Rufo R. Virtual ICU Foundations for healthier environment. Nursing Management. 2007 February: p. 32-‐39. 6. The AACN Tele-‐ICU task force. American Association of Critical-‐Care Nurses. [Online];2013. 7. Goran S F. Partnership for a Healthy Work Environment: Tele-‐ICU/ICU Collaborative. AACN Advanced Critical Care. 2012; 23(3): p. 289-‐301. 8. Joint Commission on Accreditation of Healthcare Organizations. The Joint Commission Guide to Improving Staff Communication Oakbrook Terrace: Joint Commission Resources; 2005. 9. Leapfrog Group. Leapfrog Hospital Quality and Safety Survey. Washington: 2006. 10. Committee on Quality of Health Care in America, Institute of Medicine. Crossing the Quality Chasm: A New Health System for the 21st Century. Washington, DC: Institute of Medicine, Committee on Quality of Health Care in America; 2001. 11. Bisantz A M ea. Emergency department status boards: A case study in information systems transition. Journal of Cognitive Engineering and Decision Making. 2010; 4(1): p. 39-‐68. 12. Wikipedia. [Online]; 2013 [cited 2013. Available from: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller. 13. Bergquist M, Ljungberg J. The power of gifts: organizing social relationships in open source communities. Information Systems Journal. 2008: p. 305-‐320. 14. Oracle. [Online]; 2011 [cited 2012 December 17. Available from: http://docs.oracle.com/javaee/6/firstcup/doc/gcrky.html. 15. Java.net. [Online]; 2012 [cited 2012 December 17. Available from: http://glassfish.java.net/. 16. The Apache Software Foundation. [Online]; 2012 [cited 2012 December 17. Available from: http://db.apache.org/derby/.
10
1148
