Iowa Health Methodist Central Sterilization Processing ...seniord.ece.iastate.edu/projects/archive/dec1103/... · Central Sterile Processing is in charge of making sure the OR gets

Iowa Health Methodist

Central Sterilization Processing (CSP)

Project Plan

Team Members:

Charles Ristau

Tariq Azmy

Theron Worthington

Yiksen Tan

Project Contact:

Austin Smith

Advisor:

Daji Qiao

Iowa Health Methodist CSP dec11-03 P a g e | i

TABLE OF CONTENTS

TABLE OF CONTENTS……………………………………………………..………………….……..i

LIST OF FIGURES……………………………………………………….………………………….. ii

1. INTRODUCTION

1.1 Executive Summary………………………………………...……………..……………..1

1.2 General Problem/Need Statement………………………………….…………………….1

1.3 General Solution Approach………………………………………..………..……………1

1.4 Concept Diagram…………………………………………………………………………2

1.5 System Description……………………………………………………………..………...3

2. CONSIDERATIONS

2.1 Intended Users……………………………………………………………………………4

2.2 Operating Environment................................................................................................... 4

2.3 Assumptions/Limitations…………………………………………………..…………….4

3. SYSTEM LAYOUT

3.1 User Interface Description.............................................................................................. 5

3.2 System Block Diagram……………………………………………………...…………...6

3.3 Functional Requirements……………………………………………………...…………7

3.4 Non-Functional Requirements…………………………………………………………..8

4. SYSTEM PLANNING

4.1 Expected End Product……………………………………….…………………………..9

4.2 Risks and Risks Management…………………………………………………...……...10

4.3 Work Breakdown Structure...........................................................................................10

Iowa Health Methodist CSP dec11-03 P a g e | ii

4.4 Statement of Work……………………………………………….…………………….11

4.5 Schedule…………………………………………………...………………………...…13

4.6 Costs…………………………………………….……………………………………..14

5. SUMMARY……………………………………………………………...…………………...…14

REFERENCES………………………………………………….…………………………………..15

LIST OF FIGURES

Figure 1- Concept Diagram……………………………………………………………………………………..…2

Figure 2- System Block Diagram……………………………………………………………………………...6

Figure 3- Schedule……………………………………………………………………………………………………13

Iowa Health Methodist CSP dec11-03 Page | 1

1.Introduction

1.1 Executive Summary

This project plan outlines a proposal for a system that handles instrument requests

at the Methodist Hospital in Des Moines. Deliverables include a software system for

managing the requests, along with two computer terminals set-up for working with

the software system. Contained in this document are various aspects of the plan,

including functional and non-functional requirements, use cases for the proposed

system, concept diagrams, a schedule for the work to be done.

1.2 General Problem Statement

In the Iowa Health System hospitals, operating rooms use large amounts of

different types of instruments everyday in surgeries. Central Sterile Processing is in

charge of making sure the OR gets all these instruments and making sure they are

cleaned and sterilized. Most of the needed instruments are prepared ahead of time

for the scheduled operations throughout the day.

Sometimes, however, additional instruments are needed. Requests for these

instruments are generally made through phone calls or notes left on instrument

trays. This can cause problems on a day where many requests are made, which ties

up the phone lines and provides an inefficient system of logging and tracking the

instrument requests.

1.3 General Solution Approach

In order to solve the current problem, we have decided to implement a system to

log requests made by the OR staff and log and forward the requests as necessary

through CSP. This system will have two terminals in the OR area, one on the north

side of the OR and one on the south side of the OR. By being connected to the

hospital's network and the instrument database, the system will be able to aid

nurses in requesting the correct equipment and getting those requests through to

CSP. It will also be run on certain CSP computer terminals, specifically in the

upstairs decontamination room and in the sterilization room, where the instrument

requests proceed through.


1.4 Concept Diagram

- Physical process

- Software process

Requests are sent

through the

existing network to

decontamination

Sending: Nurses’

Requests are

processed via new

visual

communication

system, received

orders are cleared

by the nurse.

Receiving: Nurses

receive specified

surgical equipment

from CSP, update

the needed tools

list, clearing

received items from

instrument waiting

queue

Sterilization

receives requests

from

decontamination

terminal, prepares

needed equipment

Instruments delivered

1 2

3

Operating

Room

Decontamination Sterilization

Third party monitoring

the request system


Figure 1- The process of requesting an instrument broken into four main steps.

1.5 System Description

Requesting System - The requesting system is the software system that will be

mounted on all of the terminals in the OR and CSP. This software serves as the

main program where it typically connects both of the terminals at each side through

the network in the hospital. This system also will be two-way communication where

the information can be sent interchangeably. There are two main operations in this

system, which are request and feedback.

Request

The request operation is the main function where all the instruments needed

by the nurses will be entered via this function and the information will be

sent to the receiving terminal at Decontamination Room. The information

such as type and quantity of the instruments, or the tray that contains sets

of surgical instruments will be entered in this function.

Feedback

Feedback is the function that enables the CSP staff at the receiving terminal

to give feedback about status of the requested instruments. Feedback such

availability of the items, will be sent to OR terminals by the CSP staff.

Operating Rooms

There are two terminals in OR area which will be placed at north and south area.

These terminals will have the requesting system in it and terminal and they will

simultaneously connect to the system. These terminal are also the place where the

nurses at OR will use to make a request or other operation described before.

Central Sterile Processing - There are two rooms in CSP; Decontamination

Room and Prep & Pack Room. These two rooms will have computer terminal in it

where these terminals will be used as the receiving terminals.

Both terminals will also have the system installed in them but only the terminal in

Decontamination Room all the requests from the OR. After the staff in

Decontamination Room has received and confirmed all the requests, then this

information will be sent to the terminal in Prep & Pack Room. The Prep & Pack

Room staffs will then, prepare the appropriate instruments to be sent to OR. There

will also be a notification system involved in this process where once a request has

been made; the system will send an alert to the staff on duty through pager or

beeper.


Database - Database contains all the information and details of hospital

instruments. All terminals that have this software implemented will share this

database. The database from the SPM will be used and integrated to this requesting

system.

Terminal - Terminals at the OR will be having touch screen capabilities where it

will speed up the request and make the system user friendly. Terminals in the CSP

will be computers operated on Windows.

2. CONSIDERATIONS

2.1 Intended users

The intended users for the system are nurses who work in the operating room and

Central Sterile Processing staff in decontamination. The nurse and CSP staff is

already familiar with the SPM system, so the new visual interface should be

relatively easy for the users to learn.

2.2 Operating Environment

In general, the requesting system will be used in the Iowa Health Hospital. The

projected location, which the system will be operated in, is between the Hospital’s

Central Sterile Processing area and the Operating Rooms. There are two corridors in

OR area which are at the north and south area of the OR. Two terminals (touch

screen monitor) will be put at each of these areas. At CSP, one terminal will be

placed at the Contamination Room, the place where all instruments get

contaminated before being sent to the sterilization room. In addition, there will also

be another terminal at Prep and Pack Room, the room where all the instruments

undergo sterilization process after being decontaminated. A pager will be used as

notification devices and the receiving range is within the area of the hospital.

2.3 Assumptions Limitations

Only nurses use upstairs OR terminal. The CSP staff will use the decontamination

workstation. There will be an easy to use GUI implemented for instrument order

status. Workstation computers are already part of a network.


3. System Layout

3.1 User Interface Description

The user will be able to make requests on one of the two OR monitors by typing in

the name of the instrument and then confirming the instrument selection. The

communication system will efficiently relay instrument orders from the nurses to

CSP through a computer network. After CSP delivers the instruments to the

nurses, the system will be updated by means of a GUI. A touch screen interface

may make this more user friendly and easier to navigate.

The advantage of having a visual display is to decrease the amount of time spent

documenting phone calls as the system will be able to make documentation updates

automatically once the nurses receive the needed surgical equipment.

The system will provide the user with a list of suggestions as the name of the

instrument is typed at the terminal. There will then be the option for the nurse to

make an instrument order after compiling a list of needed instruments. The CSP

staff then receives this order from a networked workstation computer and prepares

the needed instruments. After CSP expedites the needed equipment, they clear the

specified instrument order from the queue. Upon receipt of the needed equipment,

the nurse will then clear the completed instrument order.


3.2 System Block Diagram (Fig. 2)

Coordinator

Terminal

Requests

Information

Status

Update

Status

Update

Operating

Room Terminal

Decontamination

Room Terminal

Clean Core

Terminal

Decontamination

Status Board

Terminal

Clean Core

Status Board

Terminal


3.3 Functional Requirements

1. Operating Room Terminal

Create a Request

Has an interface for user to input the request information such as room

number, case number and equipment list. Confirmation window will pop

up before request get send out.

Edit/Change Request

Has an interface for user to edit/change the request. User can add

additional equipment, delete particular equipment, and change case

number. User has to confirm their change before it gets modify.

Cancel Request

User has to click on the particular request then click CANCEL REQUEST.

User has to confirm their cancelation before it gets cancel from the

requests queue.

Request Fulfill

User has to click on the particular request then click REQUEST

FULFILL. User has to do confirmation before it gets update to the

system.

Requests Queue

Every request will appear on request queue according to the priority; top

request will have first priority. Different colors will be used for different

request status; Blue indicates working on; Yellow indicates pending; Red

indicates error with request. Green indicates instruments are on the

way.

2. Decontamination Room Terminal

Request Queue

Every request will appear on request queue according to the priority.

User will have to process from the top list. “Flashing” will have the first

priority. Red color flashing indicates it is “Flashing” request which need

to process as soon as possible.

Decontamination Done

User has to update the status on request queue. Once Done is clicked,

the request will be send to Clear core Terminal.

3. Clean Core Terminal

Request Queue


User will have to process from the top list. “Flashing” will have the first

priority. Red color flashing indicates it is “Flashing” request which need

to process as soon as possible.

Clean Core Done


User has to update the status on request queue. Once Done is clicked, a

status update message will send to Operating Room Terminal to notify

operating room staff that equipment is ready.

4. CSP Coordinator Terminal

Request Queue


Different colors will be used for different request status; Blue indicates

working on; Yellow indicates pending; Red indicates error with request.

Green indicates instruments are on the way.

3.4 Non-Functional Requirements

1. User friendly

1.1. Simple and straight forward user interface

Request input

Only require necessary information, such as list of instruments, OR room

number, Time needed, and Special Priority.

Input method

OR user only has to type the needed instruments and click on other

related information which takes no longer than 1 minute. (Depend on

the number of instruments requested.)

1.2. User Interface organize

Font size and type, background and font color

It will be in readable font size and type (e.g. Times New Roman but not

something like freestyle script). Use contrast background and font color,

for easy to read.

Display the request information accordingly

For the convenient of CSP and Decontamination’s operator, the request

information will begin with OR room number, Time needed, and list of

instruments.

2. Effective display

Different color indicates different levels of priority

Have the request flashing for Flashing case; Red indicates need it less than

30 minutes; Green indicates not needed in coming 2 hours and etc.

3. Reliability

3.1. Confirmation

Decontamination’s staff

Decontamination’s staff needs to check on the request that they are

working. So that any changes made by OR for that request,

Decontamination’s staff will receive notification.

4. Increase the effectiveness


Apply the auto-matched technique during input the instruments

Instead of typing the full name of the instrument, the software will auto-

matched the instrument that has same initial character while typing. OR

user can simply choose from the lists.

5. Security

5.1. User

Only OR user get to access to the software.

5.2. Data

No other information shows or needs for the request. No patient or surgery

detail can be obtained from this software.

6. Maintainability

6.1. Easy to maintain

Only need to provide correct “Case #” to the system. Not necessary for

routinely checkup. Easy fix by technician.

4. System Planning

4.1 Expected End Product

Currently, several deliverables are planned for in this proposal. They are as follows:

- Instrument Request System: This is the main software component that will

provide the desired functionality for this project, taking instrument requests

and distributing them to the necessary areas in the OR and CSP. This will be

a program runnable on Windows systems, as used in the hospital. It can be

installed to the specific computers used for this system, including the

terminals to be placed in the north and south areas of the OR area.

- OR Computer Terminals: These will be computer systems, preferably with

touch screens, set up to run the instrument request system, with the OR

staff as the intended users. Currently, two are planned, with one for the

north side of the OR and one for the south side of the OR.

- Setting up other Computers to use the software: We will also set-up other

systems to use the software program for managing instrument requests. This

will include setting-up the software on computers in decontamination and

sterilization areas, along with other possible additional computers.


4.2 Risks and Risk Management

- Unlike many other projects with hospitals, this project does not have the risk

of sharing sensitive or confidential information, nor does it need to restrict

information based on users, since it will only be used in specific areas and

does not connect to a database with confidential information. This project

does, however, carry other risks.

- One risk is delivering the information between terminals in a timely fashion.

During critical times, slow delivery times can result in delaying procedures,

pushing back an already loaded operation schedule. Ensuring that

information travels swiftly is an important concern in the design. Any

network service interrupts can also be a risk, but there is little our program

can do about such a problem, except to make sure to reconnect as soon as

possible.

- Another risk is relaying the correct information. Incorrect information would

create more problems than the program solves, increasing the amount of

time it takes to prepare the necessary instruments. A problem such as this

has two sources: Errors caused by the program, and errors put in by the

staff. Correctness of information in the program is a problem that has to be

carefully dealt with during creation. Errors from the staff may be somewhat

decreased by having the software help staff confirm that they requested the

correct instrument, by checking their request against a database of

instruments, for example.

4.3 Work Breakdown Structure

1. Charles Ristau

Charles is the team leader and will have control of the entire software design.

His main responsibility is managing the group. He will be designing the User-

Interface.

2. Theron Worthington

Theron, our Communication Liaison, will in charge of networking. He will also

aid in designing the User-Interface design.

3. Mohd Tariq Azmy

Tariq will be responsible for hardware implementing. He will be helping

Theron in networking.

4. Yik Sen Tan

Yik Sen will be responsible for hardware implementing. He will also help

Charles with the User-Interface design.


4.4 Statement of Work

1. Problem definition

Task objective

To understand client’s problem and the objective for their solution.

Task approach

Advisor

Have meeting with advisor in order to clarify the proposal which

submitted by client.

Market survey and group discussion

Each group members do market survey/research on the solution and

discuss during group meeting.

Client

Contact with client either by email or by person, in order to obtain more

information and clarify on vague concern.

Task expected results

Advisor

Obtain professional suggestion on particular topic from advisor. Lead the

team in a correct way. Always beyond the schedule.

Market survey and group discussion.

Have a deeper and clearer insight of the problem and solution. Able to

come out the solution the client wanted or even better solution.

Client

Get as much as possible related information from client. Understand

their needs and their preference for the solution.

2. Technology and implementation considerations and selection

Task objective

Choose an appropriate software language.

Task approach

Check or study the language that current using in their tracking system

software (SPM).

Discuss with advisor and has his advice and suggestion.

Study and research on the different advantages on using different

languages.


Finalize or decide the language that will be using in this software.

3. End-product design

Task objective

The end-product design will be a software that work with client current

system

Task approach

Gather information.


Conclude the requirements from client

Have a design architecture

Follow the design architecture


Successfully design the software by time.

4. End-product testing

Task objective

To make sure it work perfectly and achieve and reach the client needs.

Task approach

Run the software several times and input it with different possible cases.

Double confirmation with client concerns the requirements.


Able to discover the part that needed to be refined.

Make sure it works perfectly. Otherwise fix the issues that it has.

5. End-product documentation

Task objective

Record the important and necessary documentation which associated with

the end-product.

Task approach

Create project plan

Create design document

Compile the design documents


Able to compile the important documents, which are important for later

explanation and clarification of the end-product.

6. End-product demonstration

Task objective

To demonstrate and exhibit the end-product to client, advisor, faculty

members, industrial review panel, and students.

Task approach

Each team member will have to present and demonstrate the end-product.

Each group will be graded or questioned by client, advisor, faculty members,

and industrial review panel. Each team member should be able to explain or

answer the question/s.


Client, advisor, faculty members, and industrial review panel understand and

recognize the end-product.

7. Project reporting

Task objective

To update the client and advisor on our recent work and future plan.

Task approach

Weekly email report


Provide project plan

Provide design document

Project final report development


Client and advisor get update the team current situation and future plan.

Client and advisor also can make improvement or/and adjustment when

they have new thought. They will able to make correction before the team

goes any further.

4.5 Schedule (Fig. 3)

1/9 1/16 1/23 1/30 2/6 2/13 2/20 2/27 3/6 3/13 3/20 3/27 4/3 4/10 4/17 4/24 5/1

Senior Design Introduction

Problem Definition

Problem Definition

Identify End-Users and End-Uses

Identify Requirements and Solution

Technology Selection

Choosing the Programming Language

Research Networking

Devices Selection

End Product Design

Database Design

Code Design

Testing Design

Finalize Design

Project Documentation

Project Plan

Design Document

Project Reporting

Weekly Report

Website


4.6 Costs

• $2,000 (grant) Available Total

• 3 Monitors(< $900)

• Labor $1,000 (<100 hours @ $10/hour)

• Workstation computers available

• Total: <$1,900

5. Summary

The plan of improvement for the CSP system includes arranging a communication

system that will efficiently relay instrument orders from the nurses to CSP through

a process coordinator. After CSP delivers the instruments to the nurses, the

system will be updated by means of a GUI. A touch screen interface may make

this more user friendly and easier to navigate.

The advantage of having a visual display is to decrease the amount of time

spent documenting phone calls as the system will be able to make documentation

updates automatically once the nurses receive the needed surgical equipment. If

the SPM framework can be integrated, then the tracking information could be

utilized in the proposed communication system.

8/21 8/28 9/4 9/11 9/18 9/25 10/2 10/9 10/16 10/23 10/30 11/6 11/13 11/20 11/27 12/4 12/11

End Product Implementation

Software Coding

Device Setup and Installation

Bug Fixes

Test Planning

End Product Testing

Test Execution/Evaluation

Error Analysis

Project Documentation

Project Poster

Final Project Documentation

Project Reporting

Weekly Report

Website


References

Iowa Health

Methodist

http://www.iowahealth.org/

Documents

Iowa Health Methodist Central Sterilization Processing ...seniord.ece.iastate.edu/projects/archive/dec1103/... · Central Sterile Processing is in charge of making sure the OR gets