You are on page 1of 14

1.

Introduction
GoodHealth, Inc. started as a super specialty hospital in 2003. In 2006, the management decided to increase its revenue by registering smaller clinics and hospitals under its brand at a nominal licensing cost. As a result, GoodHealth was able to increase its revenue and brand awareness across the country. The smaller clinics benefited by associating with the GoodHealth brand name and by obtaining expert assistance provided by the super specialty hospital. Today, GoodHealth employs more than 300 doctors across its clinics and boats of a combined capacity of 2000 beds. GoodHealth uses a robust document-based system at its super-specialty hospital to maintain patient records and activities. The front desk officers and medical staff maintain a list of all the patients registered with the hospital. They record all patientrelated activities, such as appointments with doctors, out-patient visits, pharmacy details, and laboratory testing services information, in a traditional ledgerbased system. However, the record maintenance system is complex and time consuming. The hospital staff has requested the management to start using an automated system that should:
2.

Cater to a high volume of patients. Store and retrieve information from a central repository. Process data quickly. Be easy to learn and should require minimal training. Generate invoices/bills to be handed over to the patients after discharge/visit. Generate various reports for the senior management.

Current system problem

The current system in use is a paper-based system. It cannot provide updated lists of patients within a reasonable timeframe. In addition the hospital stores medical record of patients manually, causes loss, incorrect data and takes lot of time when generating reports.

3. Solution
1.1 Purpose

The purpose of this document is to describe all the requirements for the Hospital management system at GoodHealth, Inc., taking care of all the user requirements. 1.2 Scope

The proposed software product is the Hospital management system at GoodHealth. The system will be used to get the information from the patients and then storing that data for future usage. It will be used to allocate beds to patients on a priority basis, and to assign doctors to patients in designated wards as need arises. It provides separate billing method for indoor and outdoor patients. The systems data storage patient records, medical activities. The front desk officers and medical staff record all patient-related activities, such as appointments with

doctors, out-patient visits, pharmacy details, and laboratory testing services information into data that can be stored in DB. 1.3 Definitions, Acronyms, and Abbreviations

This subsection should provide the definitions of all terms, acronyms and abbreviations required to properly interpret the SRS document. If any term has multiple meanings, its intended meaning in the SRS document must be clearly stated to avoid any subjective interpretation. HPMS - Hospital management system. SRS - Software Requirements Specification

4. General Description
4.1. Product Perspective This Hospital Patient Management System is a self-contained system that manages activities of the hospital as bed assignment, operations scheduling, personnel management and administrative issues. Various stakeholders are involved in the hospital system. A general picture of the system and the relationship between various stakeholders in the hospital is shown in Picture 2. 4.2. Product Functions The system functions can be described as follows:
Registration: When a patient is admitted, the front-desk staff checks to see if the patient is already registered with the hospital. If he is, his/her Personal ID number is entered into the computer. Otherwise a new Personal ID number is given to this patient. The patients information such as date of birth, address and telephone number is also entered into computer system.

Consultation: The patient goes to consultation-desk to explain his/her condition so that the consulting nurse can determine what kind of ward and bed should be assigned to him/her. There are two possible circumstances: a) If there is a bed then the patient will be sent to the bed to wait for the doctor to come. b) If there is no bed, the patient is put on a waiting list until a bed becomes available. Patient check out: If a patient checks out, the administrative staff shall change his beds status from the system to free and discharge status in his Medical record to true. Additionally, patient must pay their entire bill before check out by using payment function.
Report Generation: The system generates reports on the following information: patients, bed availability and staff schedules after every six hours. It prints out all the information on who has used which bed, when and the doctor that is taking care of a given patient as well as expected medical expenses.

4.3. User Characteristics The system will be used in the hospital. The administrators, doctors, nurses and front-desk staff will be the main users. Given the condition that not all the users are computer-literate, some users may have to be trained on using the system. The system is also designed to be user-friendly. It uses a Graphical User Interface (GUI).

Front-desk staff: They all have general reception and secretarial duties. Every staff has some basic computer training. They are responsible for patients check-in or notification of appropriate people (e.g. notify administrator or nurse when an event occurs). Administrators: They all have post-secondary education relating to general business administration practices. Every administrator has basic computer training. They are responsible for all of the scheduling and updating day/night employee shifts. Administrators in the wards are responsible for assigning doctors and nurses to patients. Nurses: All nurses have post-secondary education in nursing. Some nurses are computer literate. Consulting nurses to whom patients give short descriptions of their conditions are also responsible for assigning patients to appropriate wards if the beds are available, otherwise putting patients on the waiting list. Nurses in wards will use the HPMS to check their patient list. Doctors: All doctors have a medical degree. Some have further specialized training and are computer literate. Doctors will use the HPMS to check their patients list.

4.4. General Constraints The system must be user-friendly 4.5. Assumptions and Dependencies It is assumed that one hundred IBM compatible computers will be available before the system is installed and tested. It is assumed that the Hospital will have enough trained staff to take care of the system The new system should be compatible with SQL Server databases, have C# based components on the server, and an HTML/JavaScript based browser client.

5. Specific Requirements
5.1. Functional Requirements Registration Add patients The HPMS shall allow front-desk staff to add new patients to the system. Assign ID The HPMS shall allow front-desk staff to give each patient a ID and add it to the patients medical record. This ID shall be used by the patient throughout his/her stay in hospital. Consultation Assign Bed The consulting nurse shall use HPMS to assign the patient to an appropriate ward and bed. Assign to Waiting List The consulting nurse shall use HPMS to assign Patient to a waiting list if no bed is available. Medical matter management Assign Medical staff The administrative staff in the ward shall use HPMS to assign a doctor or a nurse to a given patient. Generate Report (normal) The HPMS shall generate the patients situation record every two hours for normal patients. Generate Report(Severe) The HPMS shall generate patients situation record every half hour for severe patients. Record procedure The whole treatment procedure for the patient shall be recorded by the system. Inform patients The HPMS shall automatically inform the patients who are on the bed waiting list of available beds whenever they become available. Check Out Discharge patient The administrative staff in the ward shall be allowed to change medical record and patients status from the system when the patient checks out. Add to beds-available list The administrative staff in the ward shall be allowed to put the beds just evacuated in beds-available list. Report Generation Patient information Every six hours the HPMS shall generate reports on patients about the following information: patients ID, patients name, ward name, bed number and the doctors name. Bed Availability Every six hours the HPMS shall generate reports on bed availability about the following information: ward name, bed number, occupied/unoccupied Staff Schedule Every six hours the HPMS shall generate reports on staff schedule about the following information: staff ID, staff name, staff type, duty shift. Database Patient Mandatory Information Each patient shall have the following mandatory information: first name, last name, phone number, personal ID number, address, postal code, city, country, Patient type. Update Patient Information The HPMS shall allow the user to update any of the patients information.

Search for Patient The HPMS shall allow the user to search for patients information by last name or patient ID. Staff Mandatory Information Each staff in hospital shall have the following mandatory information: identification number, first name, last name, phone number, address, postal code, city, country, employee type, duty schedule. Update Staff Information The HPMS shall allow the user to update any of the staffs information. Medical staff Information The HPMS shall allow the user to search for medical staff information by last name, or ID number. Ward Types The ward is categorized into four types: Maternity, Surgical, Cancer and Cardiac. Ward Information Each ward in HPMS shall include the following mandatory information: ward name, ward number, list of bed in ward. Bed Information Each bed in HPMS shall include the following information: bed number, status occupied/unoccupied, prices. Ward Search The HPMS shall allow users to search the ward, room, and bed directly by ward number and bed number respectively, or by hierarchal hyperlinks from ward to bed. 5.2. Design Constraints Database The system shall use the Sql Server Database, which is open source and free. Operating System The Development environment shall be Windows 2000. Web-Based The system shall be a Web-based application. 5.3. Non-Functional Requirements Security Patient Identification The system requires the patient to identify himself /herself using PID Logon ID Any user who uses the system shall have a Logon ID and Password. Modification Any modification (insert, delete and update) for the Database shall be synchronized and done only by the administrator in the ward. Front Desk staff Rights Front Desk staff shall be able to view all information in HPMS, add new patients to HPMS but shall not be able to modify any information in it. Administrators' Rights Administrators shall be able to view and modify all information in HPMS Nurses' Rights Nurses shall only be able to view all information in HPMS. Doctors Rights Doctors shall only be able to view all information in HPMS Performance Requirements Response Time The system shall give responses in 1 second after checking the patients information. Capacity The System must support 1000 people at a time. User-interface The user-interface screen shall respond within 5 seconds.

Conformity The systems must conform to the Microsoft Accessibility guidelines Maintainability Back Up The system shall provide the capability to back-up the Data Errors The system shall keep a log of all the errors.
Reliability

Availability The system shall be available all the time.

Picture 1: ER-diagram

Picture 2: Use case

6.

Use case
6.1. Name: Hospital Admission

Identifier: UC1 Description: Receive and make patient s medical records. Goal Check patients ID, enter information, issue medical card Preconditions (List the state(s) the system can be in before this use case starts) 1. Valid patients record in database . Frequency 2000 times a day.

Basic Flow (Describe the normal processing path, aka, the Happy Path) 1. The case start when the patient enter the hospital, his information will be sent to the hospital receptionist 2. Enter information about his condition, his name, address, health insurance..,. 3. If patient is already exist in database, return patients ID. 4. Otherwise create new patient record. 5. Assign doctor or nurse healing and helping this patient. 6. Alternative Flow 1: Switch to Use case Bed allotment if he stay in hospital and be assigned bed. Otherwise skip this step. 7. Use case ends when all information about patient enter correctly and added to system, patient receive printed card using for all medical service in the hospital. Post conditions (List the state(s) the system can be in when this use case ends) 1. Patient with data added in the system. 2. Issue a card to patient for using in the hospital. Actors (List of actors that participate in the use case) Patient Desk officer Included Use Cases (Optional, List of use cases that this use case includes) None Extended Use Case (Optional, The use case, if any, that this use case extends) Bed Allotment (UC2)

6.2. Name: Bed allotment Identifier: UC2 Description: Assign bed to patient if they choose to stay at the hospital. Goal When this use case complete, patient has assigned correct bed. Preconditions (List the state(s) the system can be in before this use case starts) 1. Patient exist and valid in DB (Use case Hospitalization UC1) Frequency (Approximately how often this use case is realized, e.g., once a week, 500 times a day, etc.) 500 times a day. Basic Flow (Describe the normal processing path, aka, the Happy Path) Use case begins when use case Hospitalization (UC1) switch to this use case Check if assigned beds status is free and valid in DB, return beds ID. Assign bed to patient. Use case ends when all information about patient and bed enter correctly and updated to database, switch back to use case Hospitalization (UC1). Post conditions (List the state(s) the system can be in when this use case ends) 1. Patient and bed data updated in the system. 2. Switch back to use case Hospitalization (UC1). Actors (List of actors that participate in the use case) Patient Desk officer Included Use Cases (Optional, List of use cases that this use case includes) None Extended Use Case (Optional, The use case, if any, that this use case extends) None 1. 2. 3. 4.

6.3. Name: Discharge Identifier: UC3 Description: Before discharge from hospital, patient has to pay all medical bills and complete their medical record. Goal All medical bills of this patient are paid and their medical record is complete. Preconditions (List the state(s) the system can be in before this use case starts) 1. Patient must have doctor's consent to discharge. 2. Valid medical record in DB. Frequency 100 times a day.

Basic Flow (Describe the normal processing path, aka, the Happy Path) 1. Use case begins when patient has doctors consent to discharge or patient want to discharge. 2. Desk officer enter Patient ID and press Search. 3. Choose Patient and press OK. 4. Patient review their treatment and their medical bills. 5. Patient agrees to discharge, if there is at least one Bill isnt paid, switch to use case Pay Bill. 6. Update medical record, patient record. 7. Use case ends when all progress are completed, patient has their prescription, all bills are paid. Post conditions (List the state(s) the system can be in when this use case ends) 1. Patient with data updated in the system. 2. Generate bills, prescription to discharge. Actors (List of actors that participate in the use case) Patient Desk officer

Included Use Cases (Optional, List of use cases that this use case includes) None Extended Use Case (Optional, The use case, if any, that this use case extends) Pay Bill

6.4. Name: Pay Bill Identifier: UC4 Description: Patient pay medical bills. Goal All medical bills of this patient are completely paid. Preconditions (List the state(s) the system can be in before this use case starts)
1. Valid patients ID, bills ID.

Frequency 1000 times a day. Basic Flow (Describe the normal processing path, aka, the Happy Path) 1. Use case begins when use case Discharge switch to this use case or Patient want to Pay their Bill. 2. List all unpaid bill of Patient. 3. Patient review their medical fees, total money. 4. Patient chooses payment method and accepts pay. 5. Update bills status in DB if success. 6. Use case ends when all progress is completed, switch back to use case Discharge. Post conditions (List the state(s) the system can be in when this use case ends) 1. Bills data updated in the system. 2. Generate bills receipt. Actors (List of actors that participate in the use case) Patient Desk officer Included Use Cases (Optional, List of use cases that this use case includes) None Extended Use Case (Optional, The use case, if any, that this use case extends) None

6.5. Name: Raise Bill Identifier: UC5 Description: Desk officer raise bills. Goal All medical bills of patient are completely raised. Preconditions (List the state(s) the system can be in before this use case starts) 1. Valid patients ID . 2. Already has fee and charge list. Frequency 1000 times a day.

Basic Flow (Describe the normal processing path, aka, the Happy Path) 1. Use case begins when Patient needs to use medical services, and desk officer choose to raise bill. 2. Desk officer enter Patient ID. If Patient exists in DB, show on screen. Other wise, show error message. 3. Desk officer choose Bill type. There are three types: Hospital charges, Lab services, Pharmacy medicine. 4. After press OK, the system will search and list the right services and money base on Bill type. 5. Choose services and presses OK, Bill will be added into database with status Pending. 6. Use case ends when all progress is completed, Bill added into DB with right money fee. Post conditions (List the state(s) the system can be in when this use case ends) 1. Bills data added into DB. Actors (List of actors that participate in the use case) Patient Desk officer Included Use Cases (Optional, List of use cases that this use case includes) None Extended Use Case (Optional, The use case, if any, that this use case extends) None

Terms and Conditions By signing this document, I agree to provide complete information on the product that will be developed. Also, it will be developed according to the specifications listed in this document, unless decreed otherwise. By signing this document, I indicate that I am satisfied by the information present here, and I give the company a full go-ahead to build the product, based on the information listed in this document.

<Project Manager> Date:

<Client sign-off point> Date: