System Overview

2.1 General Description:

The HMS (Hospital Management system) deals primarily with the scheduling and tracking of various hospital resources and patients. HMS schedules doctors and nurses to perform surgical procedures or to staff a given ward. HMS also admits patients, assigns them a room [in an appropriate ward] if one is available or assigns the patient to an admissions waiting list.

HMS is grouped into 3 major components:

Each component contains task related functions.

2.2 Summary of Required System Functions:

2.2.1 Patient Administration:

The patient administration module provides all the information regarding patients. Such information includes name, hospital insurance #, address and phone number, treatment information, admission date, room occupied and operation information if any. This module deals with adding, updating and deleting patient information. This module also handles admissions wait list features that include additions, deletions and updates to the waiting list.

Click here for a complete listing of patient attributes.

2.2.1.1 User admits new patientUser: authorized administrator/admitting nurse

2.2.1.2 User admits previous patientUser: authorized administrator/admitting nurse

2.2.1.3 User changes treatment for patientUser: authorized administrator/doctor/nurse.

2.2.1.4 User takes patient off Waiting listUser: Authorized administrator, Admitting nurse, nurse/doctor.

2.2.1.5 User discharges patient.User: nurse/doctor or authorized administrator

2.2.1.6 User inquires about patient informationUser: nurse/doctor/authorized administrator

2.2.1.7 User generates notification to patientUser: authorized administrator

2.2.2 Staff-Administration Functions:

The staff administration module deals with staff information and scheduling. This module allows the user to add, delete and update staff records. The user may also view a particular staff record on demand.

Click here to see a complete list of staff attributes.

2.2.2.1 User hires staffUser: Authorized administrator

2.2.2.2 User terminates staff memberUser: authorized administrator

2.2.2.3 User updates staff informationUser: authorized administrator

2.2.2.4 User inquires about staff informationUser: authorized administrator/doctor/nurse

Customer Comment

Certain basic features of the organization of the hospital should be relatively easy to change. For example if we want to expand a particular ward we should be able to do it without requiring a major software rewrite. In addition, the algorithm and tasks of the system are well thought out and organized. This has been demonstrated by the possible errors that were presented.

2.2.3 Scheduling:

The scheduling module, schedules staff into wards and operating rooms according to specific requirements. The scheduling module can be also used to schedule operating theaters and recovery rooms for surgical procedures.

Click here for a list of staff scheduling rules.

2.2.3.1 User books an operation

2.2.3.1.1 User books an operating roomUser: authorized administrator/doctor/nurse

2.2.3.1.2 User schedules staff for operationUser: authorized administrator

2.2.3.2 User changes scheduled operationUser: authorized administrator/doctor/nurse

2.2.3.3 User cancels an operationUser: authorized administrator/doctor/nurse

2.2.3.4 User makes up work scheduleUser: authorized administrator

2.2.3.5 User updates work scheduleUser: authorized administrator

2.2.3.6 User views own work schedule scheduleUser: doctors/nurses

2.2.3.7 User views ward scheduleUser: authorized administrator/nurses/doctors

2.2.3.8 User queries operation scheduleUser: Authorized Administrator/Nurses/Doctors

Customer Comment

We have noticed that many of these functions are aimed at certain members of the staff. This is something that we overlooked, but now that it has been pointed out we will require certain other features. a) Administrator Information Storage. e.g. Title, ... with the rest same as other staff. b) Functions acting on administrators. e.g. Add administrators, delete, change info. c) Each user must be assigned a password, which can be changed by the user or administrator. d) There will be 1 special administrator called the "SUPER ADMINISTRATOR" he/she is the only one able to alter information about administrators. e) The "SUPER ADMINISTRATOR'S" password is to be INITIALLY hardwired into the system by the developers. We realize this does have the danger where the "SUPER ADMIN" forgets his/her password, so we ask that the developer suggest a method or keep some backdoor feature of which only the developer is aware. In summary, all the systems functions should have a certain priority level, where higher levels can access all functions of the same and lower levels. The hierarchy at present would look like: "SUPER ADMINISTRATOR"->adminstrators->doctors/nurses. NOTE: (JUST PART OF WISH LIST) At the present, we do not have at horizontal differentiation. (i.e. doctors and nurses can all access the same functions.) If at all possible we would like the system implemented in such a way, that if in the future we do add new forms off staff and require some form of horizontal differentiation, this will not require a complete revamp of current functions and data structures.

Next Section
Previous Section
Back to the Functional Specification titlepage
Back to Sirius Software Product's Home Page

Last Modified Jan. 30, 1996 by

Howell Cobb