student health center: whiteboard - vanderbilt … · web viewthe convenience of the whiteboard...

12/9/2010

Student Health Center: Whiteboard

Jennifer Swails, Administrator, Student Health Center Team SHC James Jiang, Yi Liang, Moses Morjain ENGM273 – Systems Engineering

Student Health Center Whiteboard

Executive SummaryThe Student Health Center is a primary care clinic that only sees registered

Vanderbilt students to provide them with first-rate primary healthcare services that are unique to a college environment. Presently there is an oral communication system in place at SHC that manages the transfer of patient information for treatment. This system operates by integrating information from two databases and relaying the information to providers. This system is not performing to an acceptable standard because of its dependence on face-to-face communication for medical workers resulting in increased delay for the patient and providers.

The incremental change of the current system will involve usage of an electronic mobile device such as a pager for nurses and doctors to optimize services because it speeds up notifications among providers and signals them to go to certain areas without unnecessary searches. The clean-slate Whiteboard system proposal will integrate patient scheduling information, patient room tracking, medical record viewing, and real-time information viewing and communication between medical workers. The Whiteboard will be an updated communication of medical information through continually refreshed screenshots of the Whiteboard display. The convenience of the Whiteboard will reduce communication delay and improve efficiency of SHC processes.

The Whiteboard will reduce time used for communicating patient information in a work shift down to 17 minutes from 2.13 hours, which is much greater than the incremental system improvement of 1.7 hour. Whiteboard will also increase daily clinic capacity to 224 students per day from 160 students per day and will save patients 25 minutes for every check up. The incremental system in contrast can only increase daily clinic capacity to 192 students per day and will only save patients 5 minutes for every check up.

The selected system alternative is not a preference for one proposed system over the other but for both proposed systems. The mobile device system should be implemented first because something needs to be done immediately to improve the flow and communication at SHC. The cost of mobile devices is not high and can be easily managed within the SHC budget. The Whiteboard system should be concurrently developed and then implemented after its completion while the mobile device system is being integrated and used. The final system will be a symbiotic combination of both proposed systems. The mobile device system will be the quick-patch to bring some immediate improvements and the Whiteboard system will bring about even greater improvements in the SHC. The mobile device can be used alongside the Whiteboard when voice communication is needed to elaborate on text communication seen on the Whiteboard display. The initial system transitions into a partnership with another system to serve the ultimate goal of improving SHC operations.

Most medical clinics and facilities at Vanderbilt Hospital have a Whiteboard that is connected to the databases it uses. However, very few of these Whiteboards are connected with each other. A potential future direction for the SHC Whiteboard would be to identify the facilities at Vanderbilt Hospital most used by SHC and find a way to connect the SHC Whiteboard to those facilities so they can gain an appropriate amount of access for efficient information transfer.

Page 1 of 86


Table of Contents

Executive Summary.............................................................................................................1Table of Contents.................................................................................................................21. Introduction and Background- System Context..........................................................42 General Description of System Architecture...............................................................63 Requirements Analysis................................................................................................84 Functional Architecture.............................................................................................145 Physical and Operational Architecture......................................................................256 Current System Performance.....................................................................................287 The Proposed System................................................................................................318 Test and Evaluation...................................................................................................659 Risk Management......................................................................................................6810 Project Management Plan..........................................................................................7611 Recommendations and Key Issues/Future Directions...............................................8112 References..................................................................................................................8413 Appendices and Applicable Documents....................................................................85

Figures

Figure 1: External Systems Diagram...................................................................................7Figure 2: Baseline Scenario I/O Trace.................................................................................9Figure 3: System reorganizes patient order due to patient emergency................................9Figure 4: High volume of patients or low number of nurses.............................................10Figure 5: System directs patient to Vanderbilt Hospital....................................................10Figure 6: The Oral Communication System shall exist.....................................................12Figure 7: The Oral Communication System shall perform functions................................12Figure 8: The Oral Communication System shall benefit the SHC...................................13Figure 9: Functional Hierarchy Diagram for the complete system...................................14Figure 10: Collect Data Hierarchy.....................................................................................15Figure 11: Process Data Hierarchy....................................................................................15Figure 12: Output Data Hierarchy.....................................................................................16Figure 13: Optimize SHC Services Hierarchy...................................................................17Figure 14: Perform Oral Communication FFBD...............................................................17Figure 15: Collect Data FFBD...........................................................................................18Figure 16: Process Data FFBD..........................................................................................18Figure 17: Output Data FFBD...........................................................................................19Figure 18: Optimize SHC services FFBD.........................................................................20Figure 19: Perform Oral Communication Functions EFFBD............................................20Figure 20: Perform Oral Communication Functions EFFBD............................................21Figure 21: Process Data EFFBD........................................................................................22Figure 22: Output Data EFFBD.........................................................................................23

Page 2 of 86


Figure 23: Optimize SHC services EFFBD.......................................................................24Figure 24: Oral Communication System Physical Hierarchy............................................25Figure 25: Medical Center staff and professionals Physical Hierarchy............................26Figure 26: Database Physical Hierarchy............................................................................26Figure 27: Operational Architecture..................................................................................27Figure 28: Time Used for Communication........................................................................28Figure 29: Daily Clinic Capacity.......................................................................................29Figure 30: Root-Cause Analysis Diagram.........................................................................29Figure 31: ESIA Diagram..................................................................................................32Figure 32: Top Level Requirement Hierarchy...................................................................34Figure 33: Mobile Communication System Shall Perform Functions...............................35Figure 34: The Mobile Communication System Shall Benefit the SHC...........................36Figure 35: The Whiteboard System shall exist..................................................................37Figure 36: The Whiteboard System shall perform functions.............................................38Figure 37: The Whiteboard System shall benefit the SHC................................................39Figure 38: Time Wasted Metric.........................................................................................39Figure 39: Capacity metric................................................................................................40Figure 40: Patient wait time metric...................................................................................41Figure 41: Perform mobile communication functions.......................................................42Figure 42: Collect Data hierarchy......................................................................................42Figure 43: Output Data hierarchy......................................................................................43Figure 44: Optimize SHC services hierarchy....................................................................44Figure 45: Perform Mobile Communication Functions FFBD..........................................44Figure 46: Collect Data FFBD...........................................................................................45Figure 47: Output Data FFBD...........................................................................................45Figure 48: Optimize SHC services FFBD.........................................................................46Figure 49: Perform Mobile Communication Functions EFFBD.......................................46Figure 50: Collect Data EFFBD........................................................................................47Figure 51: Output Data services EFFBD...........................................................................48Figure 52: Optimize SHC Services EFFBD......................................................................49Figure 53: Perform Whiteboard Functions functional hierarchy.......................................50Figure 54: Collect Data functional hierarchy....................................................................50Figure 55: Collect Data functional hierarchy....................................................................51Figure 56: Output Data functional hierarchy.....................................................................51Figure 57: Optimize SHC services functional hierarchy...................................................52Figure 58: Perform Whiteboard Functions FFBD.............................................................52Figure 59: Collect Data FFBD...........................................................................................53Figure 60: Process Data FFBD..........................................................................................54Figure 61: Output Data FFBD...........................................................................................54Figure 62: Optimize SHC services FFBD.........................................................................55Figure 63: Perform Whiteboard Functions EFFBD...........................................................56Figure 64: Collect Data EFFBD........................................................................................56Figure 65: Process Data EFFBD........................................................................................57Figure 66: Output Data EFFBD.........................................................................................58Figure 67: Optimize SHC services EFFBD.......................................................................59

Page 3 of 86


Figure 68: Mobile Communication System Physical Hierarchy.......................................60Figure 69: Medical Center staff and professionals Physical Hierarchy............................60Figure 70: Database Physical Hierarchy............................................................................61Figure 71: Mobile Communication Device Physical Hierarchy........................................61Figure 72: Mobile Communication System operational architecture................................62Figure 73: Mobile Communication Morphological Box...................................................62Figure 74: Whiteboard System physical hierarchy............................................................63Figure 75: Whiteboard System operational architecture...................................................63Figure 76: Whiteboard Morphological Box......................................................................64Figure 77: Mobile Communication system qualification matrix.......................................65Figure 78: Whiteboard system qualification matrix..........................................................67Figure 79: Mobile Implementation Risks..........................................................................70Figure 80: Mobile Operational Risks................................................................................71Figure 81: Whiteboard Implementation Risks...................................................................72Figure 82: Whiteboard Operational Risks.........................................................................72Figure 83: Work Breakdown Structure-Incremental.........................................................76Figure 84: Work Breakdown Structure- Clean Slate.........................................................77Figure 85: Gantt chart........................................................................................................77Figure 86: Incremental Budget..........................................................................................78Figure 87: Clean Slate Budget...........................................................................................79Figure 88: Detailed Mobile Device Implementation Gantt chart......................................85Figure 89: Detailed Whiteboard Implementation Gantt chart...........................................85

1. Introduction and Background- System Context

1.1 System’s underlying mission

The Student Health Care Center’s mission is to provide Vanderbilt students with first-rate primary healthcare services unique to a college environment that is inexpensive to students and as efficient as possible without sacrificing quality.

The mission of the oral communication system within Student Health Care Center is to relay information between medical professionals that is mainly mediated by nurse practitioners and staff. The system provides patient location, patient treatment, and overall correspondence between workers.

1.2 System current statusThe oral communication system’s performance is measured by number

students treated by the Student Health Clinic per day and by the time it takes to delegate information for patient treatment.

This system is not performing to an acceptable standard due to many causes. The dependence on direct communication between nurses and doctors

Page 4 of 86


results in nurses searching for the doctors, which increases delay time for the patient to be seen and treated. The outcome is a lower number of students being treated at Student Health Care Center.

1.3 System prioritiesThe top priorities of the oral communication system are to transfer

treatment information between medical workers and to act as a mediator of EPIC for the primary physicians that see the patient. The nurses transfer information to the doctors. For example, nurses tell the doctors information from EPIC such as chief complaint of the patient. The doctors also communicate information back to the nurses to direct them with patient treatment.

An opportunity for the current oral communication system is to integrate a mobile communication device such as a walkie-talkie. Threats that this system currently faces are information delay and information integrity. Having nurses physically move around to communicate to doctors impedes system efficiency. The transport of verbal information between many people increases the probability of misinformation.

1.4 System’s core competencies

The Student Health Care Center’s core competencies are efficient, high quality healthcare for patients specific to a college environment and low costs for students.

Our center of gravity is divided mainly between operational leadership and customer intimacy. Operational leadership is necessary for the oral communication system to run smoothly and provide medical workers with information on time. Customer intimacy is necessary because the oral communication system should ultimately work for the patient so they can have a good experience from receiving proper and high quality treatment.

1.5 Role of project

The role of our project advances the oral communication system’s mission by foreseeing and resolving future obstacles in providing information on time for medical workers. The specific threats that this project is addressing are information delay and information integrity.

This project is a large leap for the current oral communication system in terms of risk and technological uncertainty because we are creating a new electronic system that uses EPIC and STAR panel to relay information. The project reinforces efficient, high quality healthcare for students by reducing wait time and lag. This project is a high priority for this system because the delay of information and the absence of an information integrity check are threats to the Student Health Care Center’s mission to provide healthcare services.

Page 5 of 86


2 General Description of System Architecture 2.1 Operational concept

The vision of the system is to have the patient treatment information flow quickly and smoothly between the nurses and the doctors throughout the clinic.

The current oral communication system operates in this way: Patient checks in for appointment through EPIC. The providers (nurses and doctors) log into STAR panel to see a list of patient names for that day. The list includes only the names and no additional information. The nurses then walk around Student Health Center to look for the patient and gather information. The nurses inform the doctors and the doctors respond back to the nurses with further instruction. A dialogue between nurses and doctors continue until the patient is checked out.

The project needs to communicate and integrate information from EPIC and Star panel so it will reduce lag time for medical workers when they need to pull up patient information. The project shall keep real-time information until the patient is checked out so immediate changes in patient treatment can be shared among medical workers efficiently. The project will reduce delay time for patient being seen by alerting doctors or nurses of extended waits.

2.2 Stakeholder identification and roles (by life cycle stage)

Concept

Student Health Center Medical Professional

Student Health Center Administrator

Design



Page 6 of 86


Production


Operations/ Employment



Student Health Center Staff

Patient

Disposal


Student Health Center medical professionals are a stakeholder in the operations and employment stage because what they care about are communicating information. Medical professionals are also stakeholder in the concept and design stage because they want the oral communication system to provide services that they need and those services are presented in a format that is most convenient to them.

Student Health Center administrator is a stakeholder in all life cycle stages. The administrator wants to ensure the oral communication system provides services that doctors need and are presented in a way that is convenient them. The administrator also has a stake in the production, operations/employment, and disposal stages. The administrator approved the production of the oral communication system and is charge of the disposal of the oral communication system to take place.

Patients have a stake in the operations/employment stage because they want to see improvements in their visit as a product of the oral communication system. For example, they want doctor visits to be more time efficient.

2.3 External Systems Diagram

Page 7 of 86


Figure 1: External Systems Diagram

There are five external systems that will interact with the oral communication system: EPIC server system, STAR Panel server system, Student Health Center computer system, the Student Health Center staff, and patient. These five external systems will interact with the oral communication system in the following ways. The STAR panel, EPIC scheduling system and the Student Health Center computer system all interact with the oral communication system by providing the appropriate information needed. The receptionist will sign in the patient on EPIC when he or she arrives and oral communication system will relay the check-in to the medical professional. The EPIC will send the patient’s scheduling information to the nurses. The Star Panel will send the patient’s medical records and medical notes to the provider. The patient receives healthcare expedited by the oral communication system.

3 Requirements Analysis 3.1 Identify all operational scenarios

3.1.1 Oral Communication System functions properly3.1.2 Oral Communication System reorganizes patient order due to patient

emergency3.1.3 Oral Communication System fails to function due to high volume of

patients3.1.4 Oral Communication System fails due to low number of nurses or

providers3.1.5 Oral Communication System directs patient to Vanderbilt Hospital

Page 8 of 86


3.2 Outline of operations scenarios

3.2.1 System functions properly3.2.1.1 Patient checks in through EPIC3.2.1.2 Patient is directed by staff to specific waiting area3.2.1.3 Nurse finds and brings patient to a checkup room3.2.1.4 Nurse finds provider for patient3.2.1.5 Primary physician treats patient 3.2.1.6 Primary physician finds and instructs nurse for further patient treatment3.2.1.7 Nurse provides additional care to patient3.2.1.8 Nurse directs patient to check out 3.2.1.9 Patient checks out

3.2.2 System reorganizes patient order due to patient emergency 3.2.2.1 Patient checks in through EPIC

3.2.2.2 Nurse brings patient to checkup room 3.2.2.3 Nurse finds provider for patient3.2.2.4 Primary physician treats patient3.2.2.5 Primary physician finds and instructs nurse for further patient treatment3.2.2.6 Nurse provides additional care to patient3.2.2.7 Nurse directs patient to check out3.2.2.8 Patient checks out

3.2.3 System fails to function due to high volume of patients or low number of nurses3.2.3.1 Patient checks in through EPIC3.2.3.2 Patient is directed by staff to specific waiting area3.2.3.3 Nurse fails to find the patient3.2.3.4 Patient reschedules for another time

3.2.4 System directs patient to Vanderbilt Hospital3.2.4.1 Patient checks into the system through EPIC3.2.4.2 Patient is directed by staff to specific waiting area3.2.4.3 Nurse finds and brings patient to a checkup room3.2.4.4 Nurse finds provider for patient3.2.4.5 Primary physician instructs nurse to bring patient to Vanderbilt Hospital3.2.4.6 Patient goes to hospital

Page 9 of 86


3.3 Sequence Diagram (I/O Trace)

Figure 2: Baseline Scenario I/O Trace

Figure 3: System reorganizes patient order due to patient emergency

Page 10 of 86


Figure 4: High volume of patients or low number of nurses

Figure 5: System directs patient to Vanderbilt Hospital

3.4 Complete Requirements Hierarchy (numbered shall/should/will system requirement statements).

3.4 Oral Communication System shall exist.3.4.1 Oral Communication system shall perform functions.3.4.2 Oral Communication system shall benefit the SHC.

3.4.1 The Oral Communication system shall perform functions.3.4.1.1 Oral Communication system shall relay information between medical workers.3.4.1.2 Oral Communication system shall direct patient treatment3.4.1.3 Oral Communication system shall integrate EPIC and STAR information

Page 11 of 86


3.4.1.4 Oral Communication system shall update STAR with new records.3.4.1.5 Oral Communication system shall direct patient to other treatment center if needed.

3.4.2 Oral Communication system shall benefit the SHC.3.4.2.1 Oral Communication system shall require minimal training of the clinical faculty.3.4.2.2 Oral Communication system shall improve flow in SHC.3.4.2.3 Oral Communication system shall enhance worker communication.

3.5 Technical Performance Metrics and Target Levels.

Oral Communication system shall relay information between medical workers in less than 20 minutes. This information was presented to us by the SHC administrator; it’s her projection on how much time it takes to communicate between workers.

Oral Communication system shall update STAR and EPIC records daily. As with above, this information was presented to us by the SHC administrator.

Oral Communication shall improve flow in SHC by serving at least 160 patients per day. This information was presented to us by the SHC administrator as the average number of patients that come into SHC every day.

3.6 Requirements Priority Tree

The function branch has equally weighted sub-branches because the SHC administrator informed us every requirement have the same importance. Not meeting one requirement will impede the performance of the system. The benefit branch has equally weighted sub-branches as well because the SHC administrator values all three benefits equally after our meeting with the client.

Page 12 of 86


Figure 6: The Oral Communication System shall exist

Figure 7: The Oral Communication System shall perform functions

Page 13 of 86


Figure 8: The Oral Communication System shall benefit the SHC

Page 14 of 86


4 Functional Architecture

4.1 Functional Hierarchy Diagram

Figure 9: Functional Hierarchy Diagram for the complete system

The main functions of the oral communication system constitutes of four components: collect data, process data, output data, and optimize SHC services. Nurse practitioners initially collect patient data to see relevant information pertaining to the appointment. Processed data is the integrated information gathered by the nurses that will be given to the physicians. Output data is the information that is exchanged between nurses, physicians and administrative staff. Optimization of SHC services is the reaction by medical professionals due to the information flow.

Page 15 of 86


Figure 10: Collect Data Hierarchy

Within collection of data, there are 3 components: retrieval of STAR panel data, retrieval of EPIC data, and collection of real-time patient data. EPIC data is needed to see scheduling information. STAR panel data is the needed to order to see the patient’s medical record. Collection of real-time patient data is the verbal correspondence between nurse practitioners and physicians in regards with patient treatment.

Figure 11: Process Data Hierarchy

Page 16 of 86


The processing of data comes from 3 sources: STAR, EPIC, and real-time patient information. After initial collection, the information needs to be processed by medical professionals in preparation to transfer patient treatment data.

Figure 12: Output Data Hierarchy

The output data are patient treatment information, update of STAR panel, and new patient scheduling. The correspondence between nurses and doctors results in patient treatment information being exchanged. Nurses update STAR panel after patient appointment to keep record of treatment. Further need of appointments will bring about new scheduling.

Page 17 of 86


Figure 13: Optimize SHC Services Hierarchy

SHC services can be improved in its efficiency in many ways. Monitoring of patient wait period will ensure patient experience of SHC is satisfactory. Alerting physician of prolonged waits will reduce inefficient use of checkup rooms. Tracking of patient location will minimize delay of communication between medical professionals.

4.2 Functional Flow Block Diagram (FFBD)

Figure 14: Perform Oral Communication FFBD

The functions of the oral communication system are series, where each subsequent function is dependent on the success of the previous function. Collection of patient data is needed initially to start out the function flow. The collected data is then processed and

Page 18 of 86


outputted. The outputted data, which is the dialogue between nurses and doctors, leads to optimization of SHC services.

Figure 15: Collect Data FFBD

Collection of data has three components: retrieval of STAR panel data, retrieval of EPIC data, and collection of real-time patient data. Retrieval of STAR panel data and EPIC data occur independently of each other because the success of either action is mutually exclusive. STAR and EPIC data will tell the nurses if the patient is present for appointment and give the nurses the patient’s medical record. The STAR panel and EPIC data leads to the real-time collection of patient treatment information as it goes back and forth between medical workers.

Figure 16: Process Data FFBD

Page 19 of 86


The collected data has to be processed by both nurses and physicians. Background information of the patient in terms of the appointment and medical record is processed first before medical professionals’ process information about the patient treatment. Processing of appointment information and medical record is independent.

Figure 17: Output Data FFBD

The exchange of patient treatment information is the main output for nurses and physicians. This exchange of information occurs during the patient appointment. After the patient checks out, the nurse updates STAR panel to record patient treatment. New scheduling is needed for further appointments.

Page 20 of 86


Figure 18: Optimize SHC services FFBD

During the patient appointment, nurse practitioners must monitor patient wait period and keep track of which room patient is in. By keeping check of this information, they alert doctors of prolonged waits to make sure patient’s time is not wasted and SHC services are optimal.

4.3 Enhanced FFBD (EFFBD)

Figure 19: Perform Oral Communication Functions EFFBD

Page 21 of 86


Presence of patient information is needed for collection of data. Without initial patient information on STAR and EPIC, collection of data serves no purpose. Medical professionals will merge the data of STAR panel, EPIC, and real-time patient treatment information. The merged data will be processed and outputted as the transferred patient information. The transferred patient information is the verbal exchange between nurses and providers. This verbal exchange will ideally optimize SHC services to result in improved efficiency.

Figure 20: Perform Oral Communication Functions EFFBD

Presence of patient information must exist in STAR panel and EPIC first before nurses can retrieve it. The retrieved information from the electronic systems will be used during the verbal exchange between nurses and doctors. The dialogue between them results in overall merged patient information.

Page 22 of 86


Figure 21: Process Data EFFBD

The merged patient information will be processed independently depending on source. EPIC information will be processed for patient location, scheduling and billing. STAR panel information will be processed for patient’s medical information. The processed STAR panel and EPIC information will be used while real-time patient treatment information is being exchanged between nurses and doctors. This flow results in the total processed patient data.

Page 23 of 86


Figure 22: Output Data EFFBD

The total patient data processed by nurses and doctors is needed before patient treatment instructions can be given. The patient treatment will eventually be updated into STAR panel after patient checkout. Physician referral is also needed for further appointments. This whole process leads to patient treatment information being exchanged between medical professionals.

Page 24 of 86


Figure 23: Optimize SHC services EFFBD

The transfer of patient treatment information is what causes the nurse to pay attention to patient wait period and patient location. If the patient is to receive some injection in a timely manner, these two pieces of information is crucial. The patient tracking by the nurses will alert the physicians of prolonged waits so they can immediately go see the patient of interest. The ideal outcome is improved efficiency in SHC.

Page 25 of 86


5 Physical and Operational Architecture5.1 Generic Architecture

This is the physical hierarchy for the oral communication system. Physical components complement the functions and requirements described in the previous sections.

Figure 24: Oral Communication System Physical Hierarchy

The current oral communication system that exists at Student Health Center consists of two components: medical professionals and electronic databases as seen on figure 24. The medical professionals are the ones communicating with each other verbally and the information shared is based on patient data gleaned from electronic databases.

Page 26 of 86


Figure 25: Medical Center staff and professionals Physical HierarchyThe Student Health Center workers are composed of three groups of individuals, hence three components as shown on figure 25. The three groups are nurses, providers, and administrative staff. These groups are the further specification of medical professionals within SHC communicating with one another verbally.

Figure 26: Database Physical Hierarchy

Page 27 of 86


As illustrated on figure 26, the database components are EPIC and STAR panel. EPIC contains the scheduling information and chief complaint. STAR panel contains the patient’s medical record. These sources of information are continually used in the dialogue between medical professionals when treating the patient.

5.2 Operational Architecture

The operational architecture maps out the requirements, functions and components that are needed to interact with each other.

Figure 27: Operational Architecture

The operational architecture maps which functions fulfill each requirement and which component performs each function as seen horizontally on figure 27. Each component can fulfill more than one function and each function can fulfill more than one requirement.

Page 28 of 86


6 Current System Performance

6.1 Technical Performance Measurement

Target

Current

0 0.5 1 1.5 2 2.5

0.283

2.13

Time Used for Communication

Hours

17 Min

Figure 28: Time Used for Communication

The current time used for communication at SHC between medical professionals is 2.13 hours (2 hours 8 minutes). 2 hours and 8 minutes are used everyday in a medical worker’s shift solely for communicating patient information rather than seeing the patient. This number was calculated by information given by Ms. Swails, the SHC Administrator, who reported that 15 minutes are wasted in every work hour for communicating patient information and the average workday is 8.5 hours. The target level is 17 minutes in a medical worker’s shift used for communicating patient information. This target level was obtained by the projection that 2 minutes for every work hour will be used for communication.

(15 min/hr * 8.5 hr) / (1 hr/60 min) = 2.13 hr

Page 29 of 86


Target

Current

0 50 100 150 200 250

224

160

Daily Clinic Capacity

Patient visits per day

Figure 29: Daily Clinic Capacity

The current clinic capacity is 160 patients per day. Ms. Swails, the SHC administrator, reported this statistic. The target level is 224 patients seen every day. The target level is a 40% increase from the current capacity of 160 patients. A 40% improvement was chosen because 220 patients are seen daily during flu season and a potential solution to the oral communication system should advance SHC processes to the degree of where its current maximum capacity is considered a normal patient input.

6.2 Diagnosis of current performance

Figure 30: Root-Cause Analysis DiagramPage 30 of 86


The four categories that contribute to our overall success are technology, environment, medical staff and process. STAR and EPIC have a communication barrier where they are unable to communicate with each other. Their incompatibility puts key patient information in two sources that individually need to be accessed by medical professionals, which adds onto communication delay. In addition, the absence of an electronic communication between medical workers prevents instantaneous updates on patient treatments. The medical staff members have inconsistent shifts, meaning there are days when the SHC has 8 nurses and there are days when there are 3 nurses. The inconsistent shifts cause workload to fluctuate unstably so overall there is increased work. The environment has limited space in terms of waiting areas, which leads to congestion of incoming patients. Lastly, the system process creates high patient wait time because of the communication delay between medical professionals and the inability to track patients. All these factors result in less patients being treated in the Student Health Center.

6.3 Implications for system improvement

The implications for the changes that are needed in the system would have to be the proper implementation of the EPIC and STAR panel in the project. The current gaps in our system are delay of communication, flow of the clinic and wait period. In our implementation we would decrease these gaps and enhance performance by creating better communication lines between the medical professionals. We would do this by making EPIC and STAR interact and display information for the medical professionals which in effect increases the flow of patients in the clinic.

Page 31 of 86


7 The Proposed System

7.1 Proposed System Research

For the system solution of incremental change under existing constraints, interviews with the Student Health Center administrator and Vanderbilt’s Network Security Administrator provided the primary research. Our group suggested a mobile, electronic device to improve SHC communication. Our group listed some possible devices and the SHC administrator gave us her evaluation of the ease of each device’s integration into SHC. The network security administrator provided insight on the threats of freely communicating medical information through mobile devices so our options were further selectively reduced.

The clean slate approach of reconstructing the entire system from scratch would involve creating something completely new that incorporates all the functions of the previous system as well as new system functions. Primary information for this system solution was obtained from interviews as well. Interviews with Vanderbilt’s Whiteboard Consultant (Raychel Enck), SHC administrator, Vanderbilt’s Network Security Administrator, and the student group working on improving the Vanderbilt’s Cancer Center outpatient whiteboard provided our group with ideas of current solutions to communication breakdown in a medical setting and up-to-date specifications of these solutions’ performance.

Our results show that both approaches are possible because of the low difficulty level in adopting these proposed systems in terms of technology and usage. In addition, the resource and finance needed for the proposed systems are not high. The advantage of applying incremental change is because some medical professionals might not fully adapt to the clean-slate system or prefer its usage so they revert back to paper notes. The advantage of applying the clean-slate approach is seeing greater, immediate improvements in communication given initial approval by users.

7.1.1 Incremental Proposal-mobile communication systemThe incremental change of the current system will involve usage of an electronic mobile device. For example, pagers for nurses and doctors will optimize SHC services because it speed up notifications among providers and signal them to go to certain areas without unnecessary searches. The inclusion of the electronic mobile devices is simply an addition of the current oral communication system. The proposal for the incremental system will emphasize changes to the existing architecture in the following ways (business process re-engineering).

Page 32 of 86


Figure 31: ESIA DiagramEliminate Simplify Integrate AutomatePatient wait time

Communication delay

Wait room congestion

Logistic work STAR Panel

EPIC

Electronic communication

Patient location tracking

Repeated tasks

Collection of data will be simplified since collecting real-time patient data by nurses will not require tracking patient location, resulting in less information being processed later in communication by nurses to doctors. The electronic mobile device will speed up monitoring patient wait period and alerting physicians of prolonged waits since it will notify medical workers when a patient is overlooked. This improvement will ensure the integrity of optimizing SHC services.

7.1.2 Clean Slate Proposal- WhiteboardThe needs the proposed system will fulfill are integration of patient scheduling, patient room tracking, medical record viewing, and real-time information viewing and communication between medical workers such as clinical notes or lab results. Meeting these requirements will expedite the work of SHC medical professionals and staff to ultimately optimize SHC processes and improve the quality of primary care received by students. The needs are fulfilled within the Student Health Care Center facility when this clean-slate Whiteboard system comes to fruition and when the existing systems (STAR panel and EPIC) are integrated with each other through this electronic Whiteboard. These goals will be fulfilled by the physical components of a new data server and its complement electronic devices for user interaction. The Whiteboard will serve as the mode of up-to-date communication for succinct medical information (lab results, chief complaint, vaccination record, etc.) through continually refreshed screenshots of the Whiteboard display between medical workers for by having them directly input it into the electronic whiteboard system. Access to EPIC scheduling and STAR panel can also be accessed through the Whiteboard without individually opening these data servers. The convenience of all these processes will reduce communication delay and improve efficiency of SHC processes. The display of the Whiteboard consists of the patient name listed in specified sequence horizontally with a series of vertical columns that correspond with information of a new data type. Implementing the Whiteboard system will be the perfect solution to fulfill the needs of SHC.

Page 33 of 86


7.2 Operational Concept of Proposed Systems

The incremental proposal of integrating an electronic mobile device is a moderate modification to the current oral communication system. This proposed system will increase the efficiency of communication between nurses and providers by removing extraneous walking and the face-to-face communication. Information is now exchanged more quickly through a device. Instead of making nurses run back and forth within the clinic, which delays the information flow and increases congestion, the mobile communication system allow nurses to communicate across the clinic instantaneously. Overall, the operational concept of the incremental proposal is not too different from the current system because certain tasks such as picking up documents from another worker will still require the nurse to walk there and there is also a limitation to the range of the electronic mobile device. The operational concept of the incremental proposal is just a modified version of the current oral communication system’s operations. Besides the incorporation of an electronic device, nearly all aspect of the operations will remain the same.

The clean-slate Whiteboard system is a significant change in the operational concept from the current oral communication system because nearly all information communicated between providers will be now digitalized for rapid transfer, viewing, and modification. A patient list will be generated everyday for the SHC providers on the electronic Whiteboard. The patient list is ordered based on specification of the provider such as patient name, gender, age, or another characteristic. For every patient listed horizontally, there are a series of vertical columns that correspond to specific types of information. These types of information can be blood results, vaccine record, or anything else needed. The electronic Whiteboard display will be a screenshot that updates periodically. These updates will occur every 4 minutes. 4 minutes were chosen as a parameter based on current Whiteboard performances in other clinics at Vanderbilt Hospital. The electronic Whiteboard system needs to communicate and integrate information from EPIC and Star panel so it will reduce lag time for medical workers when they need to pull up patient information. Whiteboard needs to display real-time information so immediate changes in a patient status can be shared by medical workers efficiently. Whiteboard will reduce delay time for patient being seen by alerting doctors or nurses of extended waits as well as keeping track of patient location in checkup rooms. The new systems will automate the process of information flow through the clinic, which is currently done by human interactions.

7.3 Proposed System Requirements

Incremental Proposal:

7.3.1 Mobile Communication System shall exist.7.3.1.1 Mobile Communication system shall perform functions.7.3.1.2 Mobile Communication system shall benefit the SHC.

7.3.1.1 Mobile Communication system shall perform functions.

Page 34 of 86


7.3.1.1.1 Mobile Communication system shall relay information between medical workers7.3.1.1.2 Mobile Communication system shall direct patient treatment7.3.1.1.3 Mobile Communication system shall direct patient to other treatment center if needed. 7.3.1.1.4 Mobile Communication system shall communicate with EPIC

7.3.1.2 Mobile Communication system shall benefit the SHC.7.3.1.2.1 Mobile Communication system shall require minimal training of the clinical faculty.7.3.1.2.2 Mobile Communication system shall improve flow in SHC.7.3.1.2.3 Mobile Communication system shall enhance worker communication.

Figure 32: Top Level Requirement Hierarchy

The weight factors were chosen as equal values in the second level because the system performing its function and having those functions benefit SHC are same in significance.

Page 35 of 86


Figure 33: Mobile Communication System Shall Perform Functions

The incremental system proposal is a slight adaptation of the current oral communication system. Therefore, the weight factors of each requirement remained the same in its equal weight because the failure of one requirement will hinder the success of meeting the remaining requirements. The technical performance parameter of less than 15 minutes was chosen for the requirement of relaying information between medical workers because it currently takes 15 minutes for every work hour for communication between nurses as stated by the SHC administrator. A system solution should improve performance so it has to relay information in less than 15 minutes for every work hour to be considered an improvement of the current system.

Page 36 of 86


Figure 34: The Mobile Communication System Shall Benefit the SHC

The incremental system proposal is an adaptation of the current oral communication system. The weight factors of each requirement are the same because the failure of one requirement will hinder the success of meeting the remaining requirements. The technical performance parameter of 192 patients seen per day for the improvement of flow in SHC was chosen because it is a 20% increase from the daily average of 160 patients as stated by the SHC administrator. A 20% increase was selected based on statistics given by the Vanderbilt’s Whiteboard Consultant, Ms. Enck. Further explanation is given in 7.4 Proposed System Metric

Clean Slate Proposal:

7.3.2. The Whiteboard System shall exist.7.3.2.1 The Whiteboard system shall perform functions.7.3.2.2 The Whiteboard system shall benefit the SHC.

7.3.2.1 The Whiteboard system shall perform functions.7.3.2.1.1 The Whiteboard system shall authenticate its users.7.3.2.1.2 The Whiteboard system shall accept a valid MRN number7.3.2.1.3 The Whiteboard system shall communicate with the EPIC system.7.3.2.1.4 The Whiteboard system shall communicate with the STAR system.7.3.2.1.5 The Whiteboard system shall integrate EPIC and STAR information

Page 37 of 86


7.3.2.1.6 The Whiteboard system shall update STAR with new records.7.3.2.1.7 The Whiteboard system shall relay information between medical

workers7.3.2.2 The Whiteboard system shall benefit the SHC.7.3.2.2.1 The Whiteboard system shall require no training of the clinical faculty for use.7.3.2.2.2 The Whiteboard system shall facilitate flow in the clinic.7.3.2.2.3 The Whiteboard system shall decrease overall wait time.

Figure 35: The Whiteboard System shall exist

The weight factors were chosen as equal values in the second level because the system performing its function and having those functions benefit SHC are same in significance.

Page 38 of 86


Figure 36: The Whiteboard System shall perform functions

The Whiteboard functions all have equal weight factors. After our interview with Vanderbilt’s Whiteboard Consultant, Ms. Enck who looked reviewed our hierarchy, she informed us that each requirement is equally important because the success of all of them is necessary for the system to exist and meet the needs of its users (providers and nurses). The technical performance parameters of 4 minutes for updating STAR panel and less than 1 minute for relaying information were statistics given by Ms. Enck based on current performance of existing Whiteboard systems at Vanderbilt Hospital.

Page 39 of 86


Figure 37: The Whiteboard System shall benefit the SHC

The weight factors of flow facilitation and wait-time decrease requirements are higher than the no-training requirement and equal to each other because flow and wait time are crucial for improvement of SHC processes while training is only a preferable convenience to the user and does not impede SHC process significantly. The SHC administrator approved the weight factor selection. The technical performance parameter of 224 patients was chosen because it is a 40% increase from the current daily average of 160 patients. There should be a 40% improvement because 220 patients are seen daily during flu season and an electronic Whiteboard system should advance SHC processes to the degree of where its current maximum capacity is considered a normal patient input. 25-minute reduction from patient wait time was selected as another technical performance parameter because Whiteboard will eliminate the 10 minutes per work hour used by doctors and 15 minutes per work used nurses for distal communication as stated by the SHC administrator. 10 complaints per 1000 users were selected as another technical performance parameter because it is the current technical performance parameter of current Whiteboard systems at Vanderbilt hospital as stated by Vanderbilt’s Whiteboard Consultant, Ms. Enck.

7.4 Proposed System Metrics

Whiteboard

Mobile

Current

0 0.5 1 1.5 2 2.5

0.283

1.7

2.13

Time Wasted for Communication

Hour

Figure 38: Time Wasted Metric

The current time used for communication at SHC between medical professionals is 2.13 hours (2 hours 8 minutes). 2 hours and 8 minutes are used everyday in a medical worker’s shift solely for communicating patient information rather than seeing the patient. This number was calculated by information given by Ms. Swails, the SHC Administrator, who reported that 15 minutes are wasted in every work hour and the average workday is 8.5 hours. The improvement is 17 minutes in a medical worker’s shift

Page 40 of 86


used for communicating patient information. This value was obtained by the statistic that 2 minutes for every work hour are used for Whiteboard communication as stated by Vanderbilt’s Whiteboard Consultant, Ms. Enck. The incremental, mobile device system proposal uses 20% less time for communication than the current system (hence a 20% improvement). Ms. Enck also presented to our group this value. The 20% improvement and the 2-minute estimate were obtained through data analysis of Whiteboard and non-Whiteboard users. Current Whiteboard systems at Vanderbilt Hospital send user information to a separate database that analyzes the information to see if performance is actually improving and ways to further improve processes. The 20% improvement of the incremental proposal was based off the 20% improvement of certain clinics at Vanderbilt hospital that only use an electronic mobile device (pagers) for communication rather than a Whiteboard system. The results showed that an electronic mobile device reduced their communication delay by 20% when compared to their previous, purely verbal communication. However, the electronic mobile device still pales in comparison to the benefit of the Whiteboard.

(15 min/hr * 8.5 hr) / (1 hr/60 min) = 2.13 hr

Whiteboard

Mobile

Current

0 50 100 150 200 250

224

192

160

Daily Clinic Capacity

Patient visits per day

Figure 39: Capacity metric

The current clinic capacity is 160 patients per day. Ms. Swails, the SHC administrator, reported this statistic. The improvement brought by the Whiteboard is 224 patients seen per day. This improvement is a 40% increase from the current capacity of 160 patients. A 40% improvement was chosen because 220 patients are seen daily during flu season and the electronic Whiteboard should advance SHC processes to the degree of where its current maximum capacity is considered a normal patient input. There is a 20% improvement of patients seen per day in the mobile device system proposal when compared to the current system. The 20% improvement was obtained through data

Page 41 of 86


analysis of Whiteboard and non-Whiteboard users (refer to the Figure 38 explanation for additional information).

Whiteboard

Mobile

Current

0 5 10 15 20 25 30

25

5

0

Patient Wait-Time Reduction

Minutes

Figure 40: Patient wait time metric

25-minute reduction from patient wait time was selected as another technical performance parameter because the electronic Whiteboard will eliminate the 10 minutes per work hour used by doctors and 15 minutes per work used nurses for distal communication as stated by the SHC administrator. There is no patient wait-time reduction for the current system because it is used as the basis and the current system is inefficient. There is a 20% improvement of patient wait-time reduction in the mobile device system proposal when compared to the current system. The 20% improvement was obtained through data analysis of Whiteboard and non-Whiteboard users (refer to Figure 39 explanation for additional information).

Page 42 of 86


7.5 Proposed System Functional ArchitectureIncremental Proposal:

Functional Hierarchy

Figure 41: Perform mobile communication functionsThe main functions of the mobile device proposal are similar to the current system. The mobile device will be used to gather information and transfer information to ultimately optimize SHC services.

Figure 42: Collect Data hierarchy

Page 43 of 86


Information gathered via the mobile device will come from sources such as STAR panel, EPIC scheduling, and current treatment data for the patient.

Figure 43: Output Data hierarchy

The information communicated includes additional instruction on patient treatment and further scheduling for the patient if more appointments are needed.

Page 44 of 86


Figure 44: Optimize SHC services hierarchy

Optimization of SHC services remain similar to the current system in the sense that the final goal is still to monitor patient wait period, track patient rooms, and alert physicians.

FFBD:

Figure 45: Perform Mobile Communication Functions FFBD

Collection of data must occur before data is outputted to improve SHC services.

Page 45 of 86


Figure 46: Collect Data FFBD

Retrieval of STAR panel and EPIC data occur independently since they are 2 separate databases. Only after patient background information is gathered can real-time data on patient treatment be exchanged between medical workers.

Figure 47: Output Data FFBD

Providing information on patient treatment and patient scheduling are independent processes.

Page 46 of 86


Figure 48: Optimize SHC services FFBD

Monitoring patient wait period and tracking patient rooms are independent processes that must occur before alerting physicians of prolonged waits.

EFFBD:

Figure 49: Perform Mobile Communication Functions EFFBD

Page 47 of 86


Presence of patient information must exist before collecting information on the patient. The collected information must exist before information is transferred. Information is now communicated through the mobile device to another medical worker to improve efficiency of SHC processes.

Figure 50: Collect Data EFFBD

Presence of existing patient information on STAR panel and EPIC is a necessary starting point for data collection of the patient before patient treatment information can be collected.

Page 48 of 86


Figure 51: Output Data services EFFBD

The total collected data on the patient is needed before patient treatment instructions can be given and physician referral is required for further appointments.

Page 49 of 86


Figure 52: Optimize SHC Services EFFBDThe transfer of patient treatment information via mobile device is what causes the nurse to pay attention to patient wait period and patient location. If the patient is to receive some injection in a timely manner, these two pieces of information is crucial. The patient tracking by the nurses will alert the physicians of prolonged waits so they can immediately go see the patient of interest. The ideal outcome is improved efficiency in SHC.

Clean-Slate Proposal Functional Hierarchy:

Page 50 of 86


Figure 53: Perform Whiteboard Functions functional hierarchyWhiteboard has to collect, process, and output information with the goal of optimizing SHC services.

Figure 54: Collect Data functional hierarchyCollection of data includes verification of the user and data retrieval from EPIC scheduling, STAR panel, and real-time Whiteboard information such as clinical notes.

Page 51 of 86


Figure 55: Collect Data functional hierarchyData collected from EPIC, STAR, and real-time patient treatment will be processed.

Figure 56: Output Data functional hierarchy

Page 52 of 86


Output of information includes showing patient medical information to providers and updating STAR panel of patient’s treatment for the appointment.

Figure 57: Optimize SHC services functional hierarchyOptimization of SHC services are the result of Whiteboard monitoring patient wait time, tracking patient rooms, alerting providers, and providing decision support.

FFBD:

Figure 58: Perform Whiteboard Functions FFBD

Page 53 of 86


Data must be collected before processed, processed before outputted, and outputted before the resulting improvement can be seen.

Figure 59: Collect Data FFBDWhen the user first logons onto Whiteboard, he or she must verify their identity. After success of identity verification, retrieval of patient information begins. Retrieval of past information on STAR and EPIC can either succeed or fail. Retrieval of real-time Whiteboard can result in only complete or incomplete patient information depending on whether the specified and requested information has been updated onto Whiteboard.

Page 54 of 86


Figure 60: Process Data FFBDProcessing of real-time Whiteboard, EPIC, and STAR data occur independently of one another.

Figure 61: Output Data FFBDDisplaying information to providers and updating STAR panel occur independently one another.

Page 55 of 86


Figure 62: Optimize SHC services FFBDMaking sure patient visit and their treatment are efficiently handled optimizes services in SHC. Patients should not wait for a long period before being seen especially if they are overlooked or have been lost by the nurses. Each patient visit should be effectively used so decision support within Whiteboard will remind and suggest to the provider vaccinations, research opportunities, and other information.

EFFBD:

Page 56 of 86


Figure 63: Perform Whiteboard Functions EFFBDPresence of patient information initiates data collection. The collected information along with the new real-time data from Whiteboard will be processed for output. Full output data will allow SHC processes to be optimized as it represents expediency of information transfer between providers.

Figure 64: Collect Data EFFBD

Page 57 of 86


User input is needed for ID verification. User authentication allows the process to continue towards data collection. The product is the data collected corresponding to each source.

Figure 65: Process Data EFFBDThe collected data from the different sources will allow their individual processing to produce a total patient information profile.

Page 58 of 86


Figure 66: Output Data EFFBDThe total patient information profile will be displayed to providers and new treatment information will be updated to STAR panel.

Page 59 of 86


Figure 67: Optimize SHC services EFFBDPatient wait time and presence of patient are the only 2 factors needed to facilitate their visit. Provider request of the patient will allow Whiteboard decision support to automatically review certain information to offer suggested treatment options to the provider such as if the patient has an overdue vaccination.

Page 60 of 86


7.6 Proposed System Physical and Operational Architecture

Incremental:

Figure 68: Mobile Communication System Physical Hierarchy

Figure 69: Medical Center staff and professionals Physical Hierarchy

Page 61 of 86


Figure 70: Database Physical Hierarchy

Figure 71: Mobile Communication Device Physical HierarchyThe mobile communication system consists of medical workers that will use the mobile devices to accelerate the transfer of information from STAR and EPIC databases.

Page 62 of 86


Figure 72: Mobile Communication System operational architecture

Figure 73: Mobile Communication Morphological BoxTransmitter Receiver Tactile Power

Bluetooth – IEEE 11073 certified

Bluetooth – IEEE 11073 certified

Keyboard Lithium Iron-phosphate fast charge battery

Infrared – IEEE 11073 certified

Infrared – IEEE 11073 certified

Touch Screen

Lithium Ion Battery

Voice over IP – SIP encrypted

Voice over IP – SIP encrypted

External wall outlet

Wi-Fi – WPA Encrypted Wi-Fi – WPA Encrypted

AA/AAA battery

The transmitter and receiver for the mobile communication device can come in four modes: Bluetooth, infrared, voice over IP, and Wi-Fi. The transmitters and receivers must be matched based on the same type meaning a Bluetooth transmitter must have a Bluetooth receiver. For the four different modes, information security is crucial so there are different protection standards. The IEEE 11073 certified standard for the Bluetooth and infrared is HIPAA compatible. SIP encryption is needed for voice over IP and WPA encryption is needed for Wi-Fi for them to be HIPAA compatible. After selecting a mode for communication, the remaining decisions are on the tactile and power components. The tactile component can be either a keyboard or a touch screen depending on user preference but it has no requirements for transmitter and receiver mode. The power component can also be any of the four listed and it has no requirements for transmitter and receiver mode but a lithium ion battery is preferable because it is the most efficient.

Clean-slate:

Page 63 of 86


Figure 74: Whiteboard System physical hierarchy The Whiteboard system will allow the user to gain access to patient information from databases after it is processed, gathered, and displayed via user interaction devices.

Figure 75: Whiteboard System operational architecture

Page 64 of 86


Figure 76: Whiteboard Morphological BoxUser Input device Network Storage Processor Keyboard T1 hard-line Web storage IntelTouch-screen T3 hard-line Off-site data center AMDTrack pad 802.11 b/g/n WPA

encrypted Wi-FiVoice command

The user input device for Whiteboard can be keyboard, touch-screen, track pad, or voice command. For the least expensive option that will still satisfy the requirements, voice command is an unlikely selection so the choice of the remaining three options is dependent on user preference. The network can be T1 hard-line; T3 hard-line, or 802.11 b/g/n WPA encrypted Wi-Fi. The network selection has no restrictions for what was chosen as the user input device. Though Wi-Fi can be possible, it is advised against because of inherent, higher security risks and SHC is a small enough facility where Wi-Fi usage would not bring any significant performance benefits. The choice of T3 hard-line or T1 hard-line can be either one depending on the current network in place at Vanderbilt University. T3 hard-line is better than T1 hard-line but T1 hard-line can still easily meet the standards required by users. The temporary storage of Whiteboard information can be either web storage or off-site storage at a data center and they do not have specific network or user input device requirements. Off-site data storage is preferred because it is currently used by Whiteboards at Vanderbilt Hospital so this method can be easily implemented. It also demonstrates that off-site data storage meets information storage security standards since it is being used by Vanderbilt Hospital. Web storage is advised against because of higher security risks and lower capacity to store information. The processors can either be Intel or AMD. They do not have specific requirements on the user input device, network, and storage selections. Intel is the preferred selection because its architecture is more widely used.

8 Test and Evaluation

Incremental – Mobile Communication System:Page 65 of 86


Physical test:

7.3.1.1.2 The provider needs to physically direct patient treatments

7.3.1.1.3 The nurses or staff needs to physically direct patient to other treatment center

Inspection:

7.3.1.1.1 This requirement is validated by observing the clinic to see whether the information relay between workers exist

7.3.1.2.2 This requirement is validated by inspection of the patient flow between wait-room and treatment area

7.3.1.2.3 This requirement is validated by inspection of the medical center workers and the efficiency of communication

Simulation:

7.3.1.1.4 Validate this requirement by logging into EPIC through a nurse or staff

Demonstration: 7.3.1.2.1 Technician’s demonstration of the system procedure is sufficient enough for SHC workers to work on a daily basis

Figure 77: Mobile Communication system qualification matrix Req ID Requirement Qualification Method

7.3.1.1.1 Mobile Communication System shall relay information between medical workers

Inspection

7.3.1.1.2 Mobile Communication System shall direct patient treatment

Physical test

7.3.1.1.3 Mobile Communication System shall direct patient to other treatment center if needed.

Physical test

7.3.1.1.4 Mobile Communication System shall communicate with EPIC

Simulation

7.3.1.2.1 Mobile Communication System shall require minimal training of the clinical faculty

Demonstration

7.3.1.2.2 Mobile Communication System shall improve flow in the SHC

Inspection

7.3.1.2.3 Mobile communication System shall enhance worker communication

Inspection

Page 66 of 86


Clean slate - Whiteboard:

Inspection:

7.3.2.2.2 This requirement is validated by inspection of the patient flow between wait-room and treatment area

7.3.2.2.3 This requirement is validated by inspecting the average wait time reduced in the clinic; specifically this requirement is targeted to meet the 25 minutes average wait time reduced for a patient

7.3.2.1.7 This requirement is validated by observing the clinic to see whether the information relay between workers exist

Simulation:

7.3.2.1.1 Logging to Star panel simulate the working condition of authentication requirement

7.3.2.1.2 Inputting MRN into star panel with valid results simulate the working condition of verification requirement

7.3.2.1.3 EPIC system simulate this requirement by “feeding” information into whiteboard

7.3.2.1.4 By displaying medical record data from star panel simulate the working condition communication between whiteboard and star panel

7.3.2.1.5 Displaying the scheduling and medical data, whiteboard simulate the integration requirement

7.3.2.1.6 Star panel refresh every 4 minutes with updated medical data from whiteboard simulates this requirement

Demonstration:

7.3.2.2.1 Technician’s demonstration of the system procedure is sufficient enough for SHC workers to work on a daily basis

Figure 78: Whiteboard system qualification matrix Req ID Requirement Qualification Method

7.3.2.2.1 The Whiteboard system shall require no training of the clinical faculty for use.

Demonstration

7.3.2.2.2 The Whiteboard system shall facilitate flow in the clinic. Inspection

Page 67 of 86


7.3.2.2.3 The Whiteboard system shall decrease overall wait time. Inspection7.3.2.1.1 The Whiteboard system shall authenticate its users. Simulation7.3.2.1.2 The Whiteboard system shall accept a valid MRN

number from its user.Simulation

7.3.2.1.3 The Whiteboard system shall communicate with the EPIC system.

Simulation

7.3.2.1.4 The Whiteboard system shall communicate with the STAR system.

Simulation

7.3.2.1.5 The Whiteboard system shall integrate EPIC and STAR information.

Simulation

7.3.2.1.6 The Whiteboard system shall update STAR with new records.

Simulation

7.3.2.1.7 The Whiteboard system shall relay information between medical workers.

Demonstration

9 Risk Management9.1 Risk Identification and Analysis

There are two major categories of risk that are present: implementation risks and operational risks.

Incremental – Mobile communication system:

9.1.1 Mobile Implementation Risks9.1.1.1 Training delay

Page 68 of 86


This is a moderate risk but it is still an issue due to the fact that the medical professional and staff will not be able to use the system in a timely manner with the proper training necessary. 9.1.1.2 Devices interference

Device interference is a moderate to high risk since it would become difficult for the medical professionals and staff to use the mobile communication devices when interferences are present.9.1.1.3 Insufficient devices

This would be a moderate to high risk since the medical professionals and staff would not have sufficient access to the mobile communication system in its beginning stages.

9.1.2 Mobile Operational Risks9.1.2.1 Incorrect frequency

This would be a low to moderate risk but still have high consequences since the medical professionals and staff would not be able to communicate through the mobile communication system. 9.1.2.2 Loss of equipment

It is a minor risk but the consequence is high since losing the device would create a breach of information for the clinic. The integrity of the information would be compromised. 9.1.2.3 Equipment malfunction

It is likely that this risk occur. There would be high consequences since medical professionals and staff would have communication barriers. 9.1.2.4 Noise pollution

Although this is an unlikely scenario, the repercussions of this risk would be high since there would be too much noise in the clinic. Many patients will complain about the unnecessary noises.

Clean-slate – Whiteboard:

9.1.3 Whiteboard Implementation Risks9.1.3.1 Fails to present information

This is an unlikely scenario to occur, the consequences of this risk would be high since the information is not displayed and there will be a serious communication breakdown. This would cause the system to completely fail.9.1.3.2 Fails to connect to network

This is also unlikely to happen but this risk would have high consequences since the medical data and the scheduling information would not be able to communicate with each other. This would cause the system to completely fail. 9.1.3.3 Learning curve

This would be a moderate issue and would have moderate to high consequences. Providers and staff would need to learn how to use the system efficiently. 9.1.3.4 Integration delay

Page 69 of 86


This could be a moderate issue with moderate to high consequences. Integrating the whiteboard into the current system during the work hours can result in serious delay and miscommunications.

9.1.4 Whiteboard Operational Risks9.1.4.1 Fails to connect to database

This is also unlikely to happen but this risk would have high consequences since the medical data and the scheduling information would not be able to communicate with each other. This would cause the system to completely fail. 9.1.4.1 Power Failure

This is a very unlikely risk but when it would occur, it could potentially wipe out the whole system to the point where data could be lost and the system cannot operate. 9.1.4.3 Fails to refresh automatic information

This risk is unlikely but the consequences would be high since the pertinent data would not be available to medical professionals, which would then create confusion within in the clinic.9.1.4.4 Information overload

In an information overload the clinic could be at overcapacity due to an overload of patients. Overloading could create a loss of data and would not allow pertinent information to be displayed properly.9.1.4.5 Human Error

This is a likely risk and could have high consequences since the provider could make a mistake in inputting medical information or information pertaining to a certain patient.9.1.4.6 Duplication of name

This is a very unlikely risk, but when this risk occurs it would cause confusion for providers, staff, and nurses.

9.2 Risk Consequence Matrix

As figure 72 through 75 suggest, some risks are much more damaging than others. The red zone shows severe need for mitigation plans, while the oranges and green are less severe and are not in need of comprehensive remedy and attention. The diagrams are separated by the life cycle stages –implementation and operational.

Incremental – Mobile communication system:

Page 70 of 86


Figure 79: Mobile Implementation Risks

Page 71 of 86


Figure 80: Mobile Operational Risks


Figure 81: Whiteboard Implementation Risks

Page 72 of 86


Figure 82: Whiteboard Operational Risks

9.3 Risk Mitigation Strategy.Incremental – Mobile communication system:

9.3. 1 Mobile Implementation Risks9.3.1.1 Training delay

The training sessions should be scheduled before the devices arrive. The training session should maintain a vigorous time schedule; in addition the providers and nurses are required to attend all session and will have an assessment at the end of each session to check up on progress.

9.3.1.2 Devices interference

Encrypt the frequency of the device will help maintain the information confidentiality. By setting the transmitter/receiver on a specific medical standard will eliminate any interference with public wireless devices.

9.3.1.3 Insufficient devices

Ordering enough sets of devices in the beginning stage to even have spare sets will greatly reduce the chance of insufficient devices in the future. In addition, constantly checking up on the inventory and the maintenance

Page 73 of 86


conditions of the device will also help reducing the chance of this risk from happening.

9.3.2 Mobile Operational Risks

9.3.2.1 Incorrect frequency

Be clear to all the medical staff, provider, and nurses about the frequency that the devices are operating on. A reminder email or memo daily will refresh users’ memory and help reduce the delay this risk cause.

9.3.2.2 Loss of equipment

The medical staff would have to be held accountable for losing their mobile communication devices. A fine needs to be enforced when a situation of loss equipment occurs.

9.3.2.3 Equipment malfunction

Hire an on-site technician specializes in medical mobile devices will help with any technical difficulties that arise during clinic operation hours.

9.3.2.4 Noise pollution

Hands-free accessories are purchased with the devices in order to decrease the noises that are made by the communication system. Users are strongly recommended to have those accessories on during operation, but are not required if using such accessories conflict with providing medical care.


9.3.3 Whiteboard Implementation Risks

9.3.3.1 Fails to present information

Test the display unit extensively prior to implementation. In addition, an onsite technician should be present at all time within the SHC to help with any technical difficulties.

9.3.3.2 Fails to connect to network

Have beta test during the research and development stage of the system will help reduce any network complications. Also an onsite technician should be present at all time within the SHC to help with any technical difficulties.

Page 74 of 86


9.3.3.3 Learning curve

The training sessions should be scheduled before the devices arrive. The training session should maintain a vigorous time schedule; in addition the providers and nurses are required to attend all session and will have an assessment at the end of each session to check up on progress.

9.3.3.4 Integration delay

The integration process would have to occur when the clinic is on off-operation hours in order to decrease any delay that would occur if implementing during the day.

9.3.4 Whiteboard Operational Risks

9.3.4.1 Fails to connect to database

Have beta test during the research and development stage of the system will help reduce any database compatibility and connectivity issues. Also an onsite technician should be present at all time within the SHC to help with any technical difficulties.

9.3.4.2 Power Failure

A backup power supply would have to be implemented into the system in order to avoid any loss of data due to power failure.

9.3.4.3 Fails to refresh information automatically

Making manually refresh available to the medical staff will not impede the process. Also an onsite technician should be present at all time within the SHC to help with any technical difficulties.

9.3.4.4 Information overload

A temporary storage unit should be in place in case of an overload so whiteboard can “dump” its excess information into storage to prevent any loss of information.

9.3.4.5 Human Error

Incorporating an AI system within whiteboard to prompt an error message to the provider in order to prove the validity of the information will decrease the effects of human error.

Page 75 of 86


9.3.4.6 Duplication of name

A color code system should be in place to avoid any confusion caused by duplication of names. Also the AI system will prompt an error message to ensure the duplicated names are correct.

10 Project Management Plan10.1 Work Breakdown Structure.

The Work Breakdown Structure outlines the steps needed to transition from current system to final system in hierarchical order. Each step requires necessary resources and time committed to make the transition as smooth as possible. Budget and project time management are detailed in the section below.

Page 76 of 86


Figure 83: Work Breakdown Structure-Incremental

Page 77 of 86

System Implementation

Mobile Device Implementation

Initial Device Test

Device Acquisition

Frequency Standardization

Spare Device

Training

Schedule Training

Device Demonstration

Clinic Flow Evaluation Technical Support

System Implementation

White Board Implementation

Initial Components

Test

Device Acquisition

Display Test

Power Test

Tactile Components

Test

Initial Network Test

Connect to Network

Connect to Databases

EPIC

Star Panel

Connect to Storage Units

Training

Schedule Training

White Board Demonstration

Clinic Flow Evaluation

Technical Support


Figure 84: Work Breakdown Structure- Clean Slate

10.2 Project Schedule.

The implementation of the project will approximately take six months. There are two main parts to the implementation plan with two auxiliary plans that are necessary to the success of the system transition. The clinic flow evaluation will start once the first part of the implementation is almost complete to critical assess the effectiveness of the mobile device. The evaluation will continue until the white board is fully incorporated to ensure consistency. Technical support will go online when mobile devices are implemented.

Figure 85: Gantt chart

In order to ensure the smoothest transition, the initial phase of implementation will consist of mobile devices. They will be tested against frequency interferences so they can provide the highest services to medical professionals. A detailed project timeline of the initial mobile device implementation is included in the appendix.

The white board will be acquired at around the end of the mobile devices implementation. This stage of implementation takes the majority of the time due to the complexity of the making of this medical software. After the electronic white board is acquired, many initial hardware tests will run to ensure the quality. Networking and software integrating will immediately follow the completion of hardware tests so the delay of system transitioning can be minimized. A detailed timeline is included in the appendix as well.

The medical professionals working in the clinic will have the opportunities to be familiar with the mobile devices once the devices are distributed. At the same time, they will be followed up by technician on the progress on white board transitioning so the time caused by learning curve of white board can be shortened once the white board is fully integrated.

System administrator will periodically evaluate the progress to ensure the system is implemented in a timely fashion. In addition, he/she will start to monitor the flow process to observe the significant increase in efficiency.

Page 78 of 86


10.3 Budget.

Figure 86: Incremental BudgetItem Cost per Unit Number of

HoursNumber of Units

Shipping Total Cost

Electronic Technician/technical support

$ 30/hour 168 1 - $5,040.00

Mobile Device $179/Unit - 27 $7.75 $4,840.75Total $9,880.75

There are three different levels included in the mobile communication budget. These levels are employees, hardware and software. The total cost of this project is estimated to be about $9,880.75.

10.3.1 Employees for Mobile Device

The electronic technician/technical support would take care of all the hardware support, which would include the maintenance of the mobile communication device. The cost per unit for the electronic technician would be 30 dollars per hour and would round to a total annual cost of $5040.

10.3.2 Hardware for Mobile Device

The mobile communication device would serve the clinic by allowing the medical professionals to communicate with each other. Each medical professional will need their own device and to avoid any issues there will need to be a surplus of devices on site. Each device comes in a pair, which runs about 30 dollars per pair. There will need to be about 27 pairs; this will round out to a total cost of $4,840.75.

Figure 87: Clean Slate BudgetItem Cost per Unit Number of

HoursNumber of Units

Shipping Total Cost

Electronic Technician/technical support

$ 30/hour 168 1 - $5040.00

Medical Information technician/technical support

$14/hour 336 1 - $4704.00

Display $200/unit - 10 $7.75 $2,007.75Keyboard $14/unit - 10 $7.75 $147.75Software $1500/unit - 10 - $15,000Total $26,899.50

Page 79 of 86


There are three different levels included in the Whiteboard budget. These levels are employees, hardware and software. The major upfront cost would come from the software and hardware components of this project. The total cost of this project is estimated to be about $26,899.50.

10.3.4 Employees for Whiteboard

The electronic technician/technical support would take care of all the hardware support, which would include the maintenance of the whiteboard, keyboard, and display. The cost per unit for the electronic technician would be 30 dollars per hour and would round to a total annual cost of $5040.

The medical information technician/technical support would take care of all the software support, which would include the medical software component to the Whiteboard system. These professionals would be an auxiliary to the electronic technician and would cost about $14 per hour and have a total annual cost of $4704.

10.3.5 Hardware for Whiteboard

The display will allow medical professionals to view the medical software. The display will be needed in every room of the student health center facility. The cost of the display will be $200 per unit and we will need about 10 of these units, the shipping will cost around $7.75 which will make the total cost of this unit $2007.75.

The keyboard will serve as the tactile device that will allow the medical professionals to work with the Whiteboard system. This item is inexpensive and will cost about $14 per unit; we will need 10 units, which will round out the total cost to 147.75 including shipping costs.

10.3.6 Software for Whiteboard

The software component is vital since it will run Whiteboard. The software is licensed and can only be installed on one computer so we will need 10 copies of the software. The software costs $1500 per unit, which will round out the total cost to $15,000.

Page 80 of 86


11 Recommendations and Key Issues/Future Directions11.1 Analysis of Alternative Approaches

The incremental system of utilizing mobile devices for communication at Student Health Center has less risk involved and is a quick patch-up to the current problems being faced when compared to the alternative, clean-slate Whiteboard system. The “new” technology introduced is not a difficult adaptation since mobile communication devices are familiar in usage to most people. The costs are also low because the primary cost is only the cost and maintenance of the mobile devices, which are relatively inexpensive. However, like all quick fixes, this selection has less reward due to its lower potential to help the Student Health Center. Besides reducing the need for face-to-face communication and speeding up the transfer of information between individuals, the number of processes for a single patient still remain the same so overall SHC operations have not been maximally optimized. Even though nurses and doctors have less need to physically find each other and the transfer of words between them are faster, the tasks of looking up and requesting patient information from different people still remain the same so the quantity of processes have not changed – only the quality of each individual process has improved. The selection of the clean-slate Whiteboard system carries high risk and a delay in terms of implementation and user adaptation. There is no current, adept Whiteboard functioning at the Student Health Center so its introduction will be something completely new and few people will be familiar with this technology. The lack of familiarity with the Whiteboard system will create initial user delay for SHC despite user training. In addition, the Whiteboard system is much more complex than the mobile device system so more planning, time, and resources (both monetary and physical) will be needed for a successful implementation. SHC will need to decide how to get the finance for this higher cost system and figure out where all the physical components (displays, interface, wiring, etc.) of this system will be placed within a limited space. Higher cost, higher complexity, and lower familiarity all lead to higher risk than a mobile device system. The successful implementation and integration of the Whiteboard system will therefore take longer. Moreover, the time for medical workers to become comfortable with the Whiteboard will be longer due to the system’s higher, inherent complexity. However, the benefit is a greater potential to improve SHC processes and overall operation. Whiteboard not only improves the quality of individual processes by reducing the need for face-to-face communication and speeding up the transfer of information but also lowers the number of processes needed for each patient. It can quickly access updated, patient medical

Page 81 of 86


information so medical workers no longer have to keep on asking each other. Less asking means less processes and higher efficiency.

11.2 Discussion of Selected ApproachThe client’s selection as voiced by the Student Health Center Administrator, Ms.

Swails, was not a preference for one proposed system over the other but for both proposed systems. She saw the value of the incremental and clean-slate proposals. Her decision is to first implement the mobile device system because something needs to be done immediately to improve the flow and communication at SHC. The cost of mobile devices is not high and can be easily managed within the SHC budget. Ms. Swails plans for the Whiteboard system to be concurrently developed and then implemented after its completion while the mobile device system is being integrated and used. The final system will be a symbiotic combination of both proposed systems. The mobile device system will be the quick-patch to bring some immediate improvements and the Whiteboard system will bring about even greater improvements in the SHC. The mobile device can be used alongside the Whiteboard when voice communication is needed to elaborate on text communication seen on the Whiteboard display.

This sequence is a variation of the “interim and end-state solution.” It’s similar in

the sense that the mobile device system is the interim solution and the end-state solution is the mobile device and Whiteboard system working together. It’s different from the “interim and end-state solution” design because the organization does not migrate from one system to a final system that’s separate and different from the initial system. Rather the initial system transitions into a partnership with another system to serve the ultimate goal of improving SHC services and operations.

11.3 Outstanding Issues.Issues in going forward with the implementation lie in the proposed Whiteboard

system. The mobile device system has few to no issues because it’s less complicated. Missing information needed for implementing the Whiteboard is related to technical application. SHC needs to find out whether or not a new server is needed solely for the Whiteboard. If not and Whiteboard is partitioned into another server currently being used, SHC needs to find out which nearby server has enough capacity. In addition, SHC needs to choose whether or not wireless transfer of information will be used on Whiteboard and evaluate the security risk with that choice. If not then SHC needs to decide on how to get the wiring from the server to SHC in the most secure way. The missing information in this case is the security evaluation and the level of security needed for the content of the medical information. The scope of work is large if the SHC Whiteboard is built as a separate entity with its own server and database but the work will be less if it is built into a system already being used by SHC that has all its information transfer issues resolved. A suggestion by Vanderbilt’s Whiteboard Consultant, Ms. Enck, was to build the Whiteboard system for SHC within STAR panel.

11.4 Future Directions.One large limitation to the SHC Whiteboard system (and in general to all

Whiteboard systems) once implemented is its limited capacity for communication with

Page 82 of 86


other Whiteboards. Most medical clinics and facilities at Vanderbilt Hospital have a Whiteboard that is connected to the databases it uses. However, very few of these Whiteboards are connected with each other. If the SHC had a patient’s blood tested somewhere at Vanderbilt Hospital and the results were needed for the patient’s treatment at SHC, the lab worker would ideally want to login into the SHC Whiteboard and input the results in the column reserved for it so SHC providers can see the result as quickly as possible with the least amount of unnecessary steps needed to obtain that information. However, due to the lack of Whiteboard networks, this function is not possible and the information is communicated through the phone or in person. A proposed project for a follow-on team would be to identify the facilities at Vanderbilt Hospital most used by SHC and find a way to connect the SHC Whiteboard to those facilities so they can gain an appropriate amount of access for efficient information transfer.

Page 83 of 86


12 ReferencesAnderson, Bjorn. Business Process Improvement Toolbox Second Edition. Milwaukee: Quality Press, 2007.

Buede Dennis. The Engineering Design of Systems. Hoboken: Wiley, 2008.

Enyck, Raychel, Meeting, Vanderbilt Whiteboard Consultant,Nashville, November 8, 2010.

Hauser, Drew, Meeting, Vanderbilt Cancer Center Whiteboard Group,Nashville, November 4,2010.

STARPANEL Vanderbilt's Electronic Medical Record Last modified June 20, 2005. www.mc.vanderbilt.edu/programs/.../StarPanel%20Training.ppt

Page 84 of 86

http://www.mc.vanderbilt.edu/programs/.../StarPanel%20Training.ppt


13 Appendices and Applicable Documents

Figure 88: Detailed Mobile Device Implementation Gantt chart

Figure 89: Detailed Whiteboard Implementation Gantt chart

Page 85 of 86