Requirements of the Proposed System

People

Overview

The people involved in the system will vary considerably, all having different requirements for what they will do with the system. Patients, doctors, nurses, and administrative users already exist of course, but a new position will arise as well. This position will be one of system maintenance. How everybody interacts with the system and they need to get out of it is a very important consideration in our design.

New positions

System maintenance: People in charge of this area will be of utmost importance. The hospital is dependent on the system functioning correctly, so proper maintenance is needed to make sure the system is proceeding smoothly. The people in this area will also need to make changes to the system as needed. If new requirements come up, they will need to access the actual databases and programming that is under the system. They will require specialized knowledge and should be experts in databases and programming. They should also be familiar with every aspect of the system, inside and out. They will be responsible for backups of critical system data to protect against data loss. They will be called upon to restart the system in the unfortunate event of a system failure. They should have the necessary skills to minimize the time this will take.

Current positions

Doctor: As a very busy caretaker, the doctor will depend on the system to give him a proper schedule to carry out, as well as critical patient information. It should be noted that the doctor will actually have very little direct interaction with the system. He will rely instead on administrative users (i.e. secretaries) and nurses to access the information he needs. When diagnosing a patient, he will require access to the patient's record, perhaps inquiring about his/her medical history. As well, the doctor requires knowledge of his own work schedule, which includes any appointments and operations he is responsible for. A doctor may take time to familiarize himself with the system, but will probably find little time in his/her schedule to actually use it personally. After diagnosis, a doctor may find it necessary to book further appointments for a patient or perhaps even book an operation. He will inform the nurses/secretaries of this need and let them take care of it.

Nurse: Nurses are caretakers themselves, but are also called upon to assist doctors. Their interaction with the system will be more direct than doctors. A nurse should be fairly familiar with the system and be able to access the information they need with relative ease by themselves. A doctor may request that a patient's medical history be brought up, or perhaps book another appointment or operation. Nurses are also called upon to prepare rooms and/or patients for operations and so will need to know what operations are scheduled.
Nurses will need to know their own personal schedules as well as what specific operations they have been assigned to. All these tasks can be delegated to the secretaries as well, depending on the situation (i.e. hectic day at the hospital). Nurses are occasionally called upon to notify next of kin and related tasks, so will need the patient's information. Also, they may need to call in doctors that are on-call, so this information is required as well.

Secretaries: More than anyone, secretaries/receptionists will have the most direct interaction with the system. They will be required to respond to requests for information from every source, including nurses, doctors, managers, and patients. The tasks outlined in the doctor and nurse profiles can eventually trickle down to be performed by the secretaries. Patients can request their schedule information, or new patient information may have to be entered. Managers may request reports on room availability, etc. New doctors and new nurses will also have to be entered into the database. There will also be a need to handle check-ins and check-outs efficiently. Receptionists should be very familiar with almost every aspect of the system, at least from an external point of view.

Managers: The managers of the hospital will be direct users of the system, and should have knowledge at a level similar to nurses. However, they will be more interested in doctor and nurse records, rather than patient records. They will be responsible for the general scheduling of hours for nurses and doctors. A major task will be the input of the schedules into the system. Also, the managers will wish to control the assignments of nurses into different wards. The doctor and nurse databases may also be tied into some sort of payroll/accounting system and the manager will be involved in that. Additionally, they will be interested in statistical reports that help them in the organization of the hospital (i.e. bed availability reports).

Patients: Patients of course, will not be directly interacting with the system at all. However, they will be interested in some areas of information. Mostly, they will interact with the receptionists in order to obtain information. They may want to know what appointments/operations they are booked for and confirm the locations and times. Also, they may want to know when certain doctors are in (if they have preferences). They may also want their records updated when their personal information changes. They will also need to know their billing information. Additionally, they will be initiating check-ins and check-outs, as well as changing their medical history with every appointment or operation they receive.

Patient Relatives/Friends: These people will also request information from the receptionists. Mainly, they will be interested in patient information, such as where the patient is located, his/her condition, and what doctor is responsible for them. They will expect this information to be readily available.

Procedures

Functional Specifications For O/R

This is the meat of our system, and wow, you guys have done a very good job on this. Thanks for the good-work.

Schedule Operation

1.1 SCHEDULE PATIENT TO OPERATION ROOM:

Function: A patient is scheduled to an operation room for a given treatment. A recovery room is also assigned.

Inputs : Operation room number, operation date & time, operation duration ,recovery room number, recovery date & time, recovery duration, treatment, patient ID, patient name (opt), doctor(s) ID, doctor name(s) (opt), nurse(s) ID, nurse name(s) (opt), meeting number

Error Conditions:


• Syntax errors: prompt user to re-enter data
• Patient ID does not exist: prompt user for re-entry
• Doctor ID does not exist: prompt user for re-entry
• Nurse ID does not exist: prompt user for re-entry
• Patient name does not exist: prompt user to re-enter name
• Doctor name(s) does not exist: prompt user to re-enter name
• Nurse name(s) does not exist: prompt user to re-enter name
• Recovery date/time conflicts: prompt user to re-enter date/time
• Operation date/time conflicts: prompt user to re-enter date/time
• Recovery room number does not exist: prompt user to re-enter room number
• Operation room number does not exist: prompt user to re-enter room number
• Operation date/time is greater than Recovery date/time: prompt the user to re-schedule both dates/times
• Operation/Recovery dates/times are made too far in advance: prompt the user to re-schedule dates/times
• Meeting number is already being used: prompt user to re-enter
1.2 MODIFY PREVIOUSLY SCHEDULED OPERATION

Function: Any of the original inputs for an existing operation may be updated. This function will automatically remove all staff from the operation roster if the date/time is modified.(Staff schedules will have to be re-entered)

Inputs : Operation room number, operation date/time, operation duration, recovery room number, recovery date/time, recovery duration, patient ID number, patient name (opt), doctor ID, doctor name(s) (opt), nurse ID, nurse name(s) (opt), meeting number

Error Conditions:

• Syntax errors: prompt user to re-enter data
• Patient ID does not exist: prompt user for re-entry
• Doctor ID does not exist: prompt user for re-entry
• Nurse ID does not exist: prompt user for re-entry
• Patient name does not exist: prompt user to re-enter name
• Doctor name(s) does not exist: prompt user to re-enter name
• Nurse name(s) does not exist: prompt user to re-enter name
• Meeting number does not exist: prompt user for re-entry
• Recovery date/time conflicts: prompt user to re-enter date/time
• Operation date/time conflicts: prompt user to re-enter date/time
• Recovery room number does not exist: prompt user to re-enter room number
• Operation room number does not exits: flag user to re-enter room number
• Operation date/time is greater than Recovery date/time: prompt the user to reschedule both dates/times
• Operation/Recovery dates/times are made to far in advance: prompt the user to reschedule dates/times
• Meeting number does not exist: prompt user to re-enter
1.3 OPERATION CANCELLATION:

Function: An operation is canceled for a given patient. This function will clear recovery room schedules, as well as operation schedules and any schedules of staff that have been added to the operation.

Inputs : Meeting number

Error Conditions:

• Syntax errors: prompt user to re-enter data
• Meeting number does not exist: prompt user for re-entry
1.4 ASSIGN STAFF TO OPERATION

1.4.1 ASSIGN DOCTOR TO OPERATION

Function: Assign a doctor to an operation. Checks for doctor schedule conflicts.

Inputs : doctor ID, doctor name (opt), operation date/time, operation room number, meeting number

Error Conditions:

• Syntax Errors: prompt user to re-enter data.
• doctor ID does not exist: prompt user to re-enter ID.
• doctor name does not exist : prompt user to re-enter name.
• operation date/time does not exist: prompt user to re-enter date/time.
• operation room number does not exist: prompt user to re-enter room number.
• meeting number does not exist: prompt user to re-enter number
• doctor schedule conflicts: tell the user to either use a different doctor or exit the function and advise user to change doctor schedule.
• doctor ID and meeting number already exist in combination: prompt user to re-enter data.
1.4.2 REMOVE DOCTOR FROM OPERATION

Function: Deletes a doctor from an operation.

Inputs : doctor ID, doctor name (opt), meeting number

Error Conditions:

• Syntax Errors: prompt user to reenter data.
• doctor ID does not exist: prompt user to reenter ID.
• doctor name does not exist: prompt user to reenter name.
• meeting ID does not exist: prompt user to reenter data.
1.4.3 ASSIGN NURSE TO OPERATION

Function: Assign a nurse to an operation. Checks for nurse schedule conflicts.

Inputs : nurse ID, nurse name (opt), operation date/time, operation room number, meeting number

Error Conditions:

• Syntax Errors: prompt user to re-enter data.
• Nurse ID does not exist: prompt user to re-enter ID.
• Nurse name does not exist: prompt user to re-enter name.
• Operation date/time does not exist: prompt user to re-enter date/time.
• Operation room number does not exist: prompt user to re-enter room number.
• Meeting number does not exist: prompt user to re-enter number
• Nurse schedule conflicts: tell user to either use a different nurse or exit the function and advise user to change nurse schedule.
• Nurse ID and Meeting number already exist: prompt user to re-enter data.
1.4.4 REMOVE NURSE FROM OPERATION

Function: Removes a nurse from an operation.

Inputs : nurse ID, nurse name (opt), meeting number

Error Conditions:

• Syntax Errors: prompt user to re-enter data.
• Nurse ID does not exist: prompt user to re-enter ID.
• Nurse name does not exist: prompt user to re-enter name.
• Meeting ID does not exist: prompt user to re-enter data.

Report functions for the O/R

1.5.1 GENERATE OPERATION ROOM REPORT

Function: a report is generated for operation rooms.

Inputs : room number, start date, finish date(optional)

Outputs : Reports operations to be done in the operation room listing in order of date and time of operation. Reports can be done daily, weekly, or any other length of time determined by start date and finish date of the search.

If no finish date is entered only a daily report is done for the room. This report will also list:

• the patient name/ID
• the doctor(s) name/ID
• the scheduled nurses name/ID
• the type of operation
• the length of the operation

Error Conditions:

• Syntax incorrect in date or operation room number.
• Start date is > finish date
• Date doesn't exist. i.e.: Jan. 32, 1997
• Operation room number doesn't exist: prompt for user re-entry
1.5.2 GENERATE O/R SCHEDULE FOR EMPLOYEE

Function: generates report for employees' schedule

Inputs : ID number, start date, name (opt), finish date (opt)

Outputs : Reports a doctor/nurse's schedule ordered by date and time. The report will be as long as is specified by start date and finish date. As well, if a finish date is not specified the function does a daily schedule for the employee.

The report will also list:

• length of operation or appointment
• the patient being seen or operated on i.e.: name/ID
• the type of operation or reason for the appointment. (treatment)

Error Conditions:

• Syntax incorrect in inputs.
• Doctor/Nurse ID doesn't exist: prompt user for re-entry
• Doctor/Nurse name doesn't exist: prompt user for re-entry
• Start date is > finish date
• Dates don't exist. i.e.: Jan. 32, 1997
1.5.3 GENERATE DAILY PATIENT LIST FOR O/R

Function: generates report of patients for the day (for O/R)

Inputs : date

Outputs : lists patients for the day, alphabetically by name.

Also reports:

• patient's ID
• length of operation
• doctor's name/ID.
• treatment

Error Conditions:

• Syntax incorrect for the date.
• Date doesn't exist: prompt user for reentry
1.5.4 GENERATE O/R SCHEDULE FOR PATIENT

Function: generates report for patient (query)

Inputs : patient name (opt), patient ID

Outputs : lists a patient's operation and appointments, listed in order of date. Searches on both patient's name and ID.

Also lists:

• the doctor the patient is seeing.
• length of stay either for an operation or for a ward.

Error Conditions:

• syntax incorrect for patient name/ID#
• patient name/ID# doesn't exist

Wait List

2.1 ASSIGN PATIENT TO WAIT LIST

Function: Assigns a patient to the wait list

Inputs : patient ID, patient name(opt), duration, treatment, priority number

Outputs: adds a patient to the wait list datastore

Error Conditions:

• Syntax Errors: prompt user to re-enter data.
• Patient ID already in use: prompt user to re-enter ID.
• Patient name already in use: prompt user to re-enter name.

Error Condition: Patient name already in use. -There may be two John Smith's who are patients at the hospital. System must allow for both to be on the waiting list at the same time. Please look at this guys.

2.2 REMOVE PATIENT FROM WAIT LIST

Function: Removes patient from the wait list.

Inputs: patient ID, patient name (opt)

Outputs: Removes a patient from the wait list datastore

Error Conditions:

• Syntax Errors: prompt user to re-enter data.
• Patient ID does not exist: prompt user to re-enter ID.
• Patient name does not exist: prompt user to re-enter name.

Are the operation schedule (1.1) and the waiting list connected? Meaning, does the patient automatically get removed from the waiting list when they are scheduled for an operation, or is it a manual entry done by the staff? - It's very nice if we can have this done automatically.

2.3 MODIFY WAIT LIST INFORMATION

Function: Changes Priority number or treatment, duration for a given patient.

Inputs : patient ID, patient name (opt), priority number, treatment, duration

Output: Modified patient to datastore

Error Conditions:

• Syntax Errors: prompt user to re-enter data.
• Patient ID does not exist: prompt user to re-enter ID.
• Patient name does not exist: prompt user to re-enter name.
• Priority number does not exist: prompt user to re-enter number.

A superb job on the reports guys.

2.4 VIEW WAIT LIST INFORMATION Function: Lists all patients currently awaiting operations.

Inputs : none

Outputs : Lists of records containing patient ID, patient name, duration of wait, treatment, priority number

Error Conditions: none

2.5 VIEW PATIENT WAIT LIST INFORMATION

Function: Displays a patient's current waiting status for an operation(s).

Inputs : Patient ID, patient name (opt)

Outputs : Patient's record including his priority number

Error Conditions:

• Syntax Errors: prompt user to re-enter data.
• Patient ID does not exist: prompt user to re-enter ID.
• Patient name does not exist: prompt user to re-enter name.

The following is a listing of reports which can be generated for operating room information. These include reports for: operation room schedules, employee schedules in O/R, daily patient reports in O/R, and patient operation reports.

The next section details the functions deemed to be necessary for the HSS to monitor and manipulate data regarding wards other than the operating and recovery wards. This includes data regarding the three principle members of any hospital situation: patient, nurse and doctor.

Patient subsystem:
This is a superb job. We are very pleased with the work done on this section. Way to go guys.

Patient Functions

3.1 FUNCTION NAME: ADD PATIENT INFO

Input: - Patient name, street, city, province, postal code, phone number, history, phone number 2 (opt)

Output: - A unique identification number is assigned - Patient is added to the database

Error Conditions:

• Syntactically incorrect inputs
• Cannot add a patient which already exists
• Field inputs missing except phone number 2
3.2 FUNCTION NAME: MODIFY PATIENT INFO

Input: - Patient ID, (patient name, street, city, province, postal code, phone number, history , phone number 2)- opt

Output: - Displays patient information - User able to change information in field(s)

Error Conditions:

• Syntactically incorrect inputs
• Patient doesn't exist
3.3 FUNCTION NAME: DISPLAY PATIENT INFORMATION

Input: - Patient ID, patient name (opt)

Output: - Displays all information in patient fields (incl. ID name, street, city, province, postal code, phone number, history, phone number 2 (opt))

Error Conditions:

• Syntactically incorrect inputs
• Patient ID does not exist
• Patient name does not exist
3.4 FUNCTION NAME: DISPLAY PATIENT SCHEDULE

Input: - Patient ID, patient name (opt)

Output: - Displays appointments with doctors or operation date/time(s)

Error Conditions:

• Syntactically incorrect inputs
• Patient ID does not exist
• Patient name does not exist
3.5 REPORT NAME: PATIENT LISTING

Input: - Specify a particular ward(s) or entire hospital

Output: - Listing of all patients; their identification number, name, and location (ward number)

Error Conditions:

• Ward specified does not exist
• syntactically incorrect
3.6 FUNCTION NAME: CHECK-IN PATIENT

Input: - patient ID
- patient name(opt)
- ward #
- room #


If patient is new then, Add a patient. If patient is in database then, Modify a patient. Specify ward that patient will stay in

Output: - Assigns patient a room and bed specific to the ward

Error Conditions:

• No available beds in specified ward
• syntax incorrect
3.7 FUNCTION NAME: CHECK-OUT PATIENT

Input: - Patient ID, patient name (opt), released by(name), patient history update(opt)

Output: - Displays patient information

Entered by user, an update of medical history Makes specified bed available Calculates total cost incurred (days of stay * cost per day)

Error Conditions:

• Syntactically incorrect inputs
• Patient ID or name does not exist
• Patient is not currently checked-in the hospital

Each of the identified functions required for doctor information is listed below in detail, including the generation of reports.

Ward/Bed Functions

4.1 FUNCTION NAME: ADD A BED

Input: - ward number, room number, bed ID (Capital letter ie A, B...)

Can be added to any ward or room

Error conditions:

• Syntactically incorrect inputs
• ward number does not exist: prompt user for re-entry
• room number does not exist: prompt user for re-entry

For error conditions, it should include a case where the bed already exists.

4.2 FUNCTION NAME: REMOVE A BED

Input: - Ward number, Room number, Bed ID

Output: - Will remove a bed from system

Error conditions:

• bed currently being used
• bed scheduled for future use
• bed does not exist
• Syntactically incorrect inputs
4.3 FUNCTION NAME: MODIFY BED INFO

Input: - Ward number, Room number, Bed ID

Output: - Modifies bed information

Used when beds moved around in the hospital

Also used to manually modify bed availability

Error conditions:

• bed does not exist
• Syntactically incorrect inputs

For error conditions, it should include a case where ward number and room number don't exist.

4.4 FUNCTION NAME: DISPLAY BED INFO

Input: - Ward number, Room number (Optional), Bed ID (Optional)

Output: - Displays bed information for any particular bed specified

Will display info based on parameters passed:

1. Ward number
2. Ward number AND room number
3. Ward number, room number, AND bed ID

Option 1 will list bed info for all beds in the ward.

Option 2 will list bed info for all beds in a particular room.

Option 3 will list bed info for a specific bed.

Error conditions:

• Syntactically incorrect inputs
• Bed, room, or ward number does not exist
4.5 REPORT NAME: BED AVAILABILITY REPORT (WARD)

Input: - Ward number

Output: - list of beds still available in a certain ward specified by user

- also includes a total of the number of beds still available in the ward

Error conditions:

• Ward does not exist
• Syntactically incorrect inputs
4.6 REPORT NAME: BED AVAILABILITY REPORT (ENTIRE HOSPITAL)

Input: - (none)

Output: - list of available beds for entire hospital separated by wards

also includes a total of the number of beds still available broken down by ward and the entire hospital

4.7 REPORT NAME: ROOM TYPE AVAILABILITY REPORT (WARD):

Input: - Room type, ward number

Output: - lists all rooms of certain type specified by the user that still have available beds

- also lists the specific beds which are available

Error conditions:

• Room type does not exist
• ward number does not exist
4.8 REPORT NAME: ROOM TYPE AVAILABILITY REPORT (ENTIRE HOSPITAL):

Input: - Room type

Output: - as above, except for the entire hospital, and broken down by ward

Error conditions:

• Room type does not exist

The functions listed below outline the basic functions needed to manipulate and keep track of information regarding nurses within wards.

Nurse and Doctor Functions

General Comment:
We are sure that you have taken this into consideration; however, just to make sure, it's very convenient if a nurse/doctor can be refered to EITHER by name OR by ID.

5.1.1 FUNCTION NAME: ADD A NURSE

Input: - nurse name, street, city, province, postal code (opt), phone number 1, phone number 2 (opt)

Output: - adds a nurse into the database

- assigns a unique nurse number to each nurse

Error conditions:

• Syntactically incorrect inputs
• Field inputs missing (all fields must be defined)

You might have covered this case already, but just to make sure: Will the system be able to handle collision? - What if we have two personnel who have identical records? This will unlikely happen, but just to be on a safe note.

5.1.2 FUNCTION NAME: REMOVE A NURSE

Input: - nurse ID, nurse name(opt)

Output: - removes a nurse from the database

Error conditions:

• Syntactically incorrect inputs
• Nurse ID does not exist
• Nurse name does not exist
5.1.3 FUNCTION NAME: MODIFY NURSE INFO

Input: - nurse ID, (nurse name, street, city, province, postal code, phone number 1, phone number 2)-opt Output: - modifies any nurse info fields except nurse ID

Error conditions:

• Syntactically incorrect inputs
• Nurse ID does not exist
5.1.4 FUNCTION NAME: DISPLAY NURSE INFO

Input: - nurse ID, nurse name (opt)

Output: - displays a nurse's whole record

Error conditions:

• Syntactically incorrect inputs
• Nurse ID does not exist
• Nurse name does not exist

Nurse Reports

5.1.5 REPORT NAME: NURSE DAILY SCHEDULE REPORT

Input: - date or (none)

Output: - outputs a schedule for a particular day listing the nurses working that day - default is current day (nurse names and IDs )

Error conditions:

• Incorrect date
5.1.6 REPORT NAME: NURSE WEEKLY SCHEDULE REPORT

Input: - date or (none)

Output: - as above, except for an entire week, broken down by day - default is current week

Error conditions:

• Incorrect date
5.1.7 REPORT NAME: NURSE MONTHLY SCHEDULE REPORT

Input: - date or (none)

Output: - as above, except for an entire month, broken down by week and day - default is current month

Error conditions:

• Incorrect date
5.1.11 REPORT NAME: NURSE YEARLY SCHEDULE REPORT (not shown on DFD)

Input: - date or (none)

Output: - as above, except for an entire year, broken down by month, week and day - default is current year

Error conditions:

• Incorrect date
5.1.8 REPORT NAME: INDIVIDUAL NURSE SCHEDULE REPORT

Input: - nurse ID - nurse name(opt) - date (default: current day)

Output: - outputs a list of a nurse's schedule for any given day in the system

Error conditions:

• Incorrect date
• nurse ID does not exist
• nurse name does not exist
• syntax incorrect
5.1.9 REPORT NAME: NURSE LIST REPORT

Input: - ward number or (none)

Output: - outputs a list of all nurses in a particular ward, or the entire hospital if no input is given (nurse IDs and nurse names)

Error conditions:

• Ward does not exist
• Syntactically incorrect ward number
5.1.10 REPORT NAME: ON-CALL LIST

Input: - (none)

Output: - generates output listing all nurses that are on call currently (nurse name, nurse id, and phone # are listed)

There are two types of patients who may stay at the hospital: a patient who has checked-in because of medical reasons, or the patient who is scheduled for an operation. The following set of functions allow for this distinction, as well as the ability to generate patient reports as specified below.

Doctor Functions

5.2.1 FUNCTION NAME: ADD A DOCTOR

Input: - name, street, city, province, postal code (opt), phone number, pager number

Output: - A unique identification number is assigned - Doctor is added to the database

Error Conditions:

• Syntactically incorrect inputs
• Doctor name already exist
• Field inputs missing (all fields must be defined)
5.2.2 FUNCTION NAME: DELETE DOCTOR INFO

Input: - ID number, name (opt), appointments and O/R schedules for the doctor from the database

Output: - Remove the doctor from the database, re-assign doctor's schedule to another doctor but asks for confirmation before doing so.

Error Conditions:

• Syntactically incorrect inputs
• Doctor IDs of either doctor do not exist
5.2.3 FUNCTION NAME: MODIFY A DOCTOR

Input: - ID number, (name, street, city, province, postal code, phone number, pager number)-opt

Output: - Displays doctor information, user able to change information in field(s)

Error Conditions:

• Syntactically incorrect inputs
• Doctor ID doesn't exist
5.2.4 FUNCTION NAME: DISPLAY DOCTOR INFORMATION

Input: - ID number, name (opt), doctor information from database

Output: - Displays all information in doctor fields

Error Conditions:

• Syntactically incorrect inputs
• Doctor ID doesn't exist
• Doctor name doesn't exist

Doctor Reports

5.2.5 REPORT NAME: DOCTOR LISTING

Input: - Specify a particular ward(s) or entire hospital

Output: - Listing of all doctors, their identification number, name, and their specialization

Error Conditions:

• Ward specified does not exist
• Syntactically incorrect input
5.2.6 REPORT NAME: DOCTOR DAILY SCHEDULE

Input: - ID number, name (opt), date (default is current date), schedule from database

Output: - Display the specified day schedule for the specified doctor

Error Conditions:

• Syntactically incorrect inputs
• Doctor ID doesn't exist
• Doctor name doesn't exist
• Date is invalid
5.2.7 REPORT NAME: DOCTOR WEEKLY SCHEDULE

Input: - ID number, doctor name (opt), date (default is current week - Sunday to Saturday), schedule from database

Output: - Display the specified weekly schedule for the specified doctor

Error Conditions:

• Syntactically incorrect inputs
• Doctor ID doesn't exist
• Doctor name doesn't exist
• Week is invalid
5.2.8 REPORT NAME: DOCTOR MONTHLY SCHEDULE

Input: - ID number, doctor name (opt), date (default is current month), schedule from database

Output: - Display the specified monthly schedule for the specified doctor

Error Conditions:

• Syntactically incorrect inputs
• Doctor ID doesn't exist
• Doctor name doesn't exist
• Month is invalid
5.2.9 REPORT NAME: DOCTOR'S PATIENT LISTING

Input: - ID number, doctor name (opt), patients from database

Output: - Display the patient list for the doctor

Error Conditions:

• Syntactically incorrect inputs
• Doctor ID doesn't exist
• Doctor name doesn't exist

• Data Dictionary

You guys have done a super job on this. Thanks for your work.

Data Flow Diagrams:

• Level 1 DFD
• Ward Functions
• Operation Functions
• Operation Room Functions
• Nurse Functions
• Doctor Functions
• Patient Functions
• Staff Assignment Functions
• Wait List Functions

This is a very in-depth analysis, we appreciate your philosophy of "users first". Thanks for your work, and we at the committee have agreed to give you the freedom to choose the approach that you think appropriate. We may train some of our staff to be familiar with MS-Access, and the package in particular.

Software

Platform Considerations

In determining a reasonable platform for any information system, one must consider the users' needs, especially in those of performance, convenience, and delivery time.

Today's computing environments offer excellent graphical environments which can dramatically enhance convenience and flexibility, and they can be run on inexpensive hardware without sacrificing performance. Thus ISIS Development has chosen to use a Graphical User Interface.

A system such as this one has important data manipulation features not visible to the user which will affect system performance dramatically. Additionally, data design must be relatively quick and totally reliable. Relational databases are a well established solution to such a problem, and so Hospital 2000's system will be implemented using such a tool. Which one is to be used is another issue, dependent on hardware and expected data volume. Please see recommendations below.

Prototype Implementation

The prototype system will be written in MS-Access, as it allows convenient design of both a relational database and a graphical user interface to the database. Additionally, it can be run on the cheapest hardware available, namely PCs. This is not to mean the final project should be done in Access, but will demonstrate the style, data design, and interface that the final system will present. The current screen shots are from a "pre-prototype", a mock up done while data design is in progress.

Software Recommendations

A system such as this depends on two layers of underlying software: an operating system, to run the computer, and a database management system to store the data reliably and provide efficient access to it. Both can affect performance and cost dramatically.

Operating Systems:

Windows or Windows NT operating systems. The former is cheaper and faster, but less reliable and lacks security features. Windows NT, however, is ideal for a shared-data server, and should be the operating system used seeing as how a PC server has been chosen.

For the end-user computers, again either Windows is possible, and in this case it doesn't really matter which is chosen. Windows would be sufficient and is cheaper, thus this is what the prototype will be developed in.

Databases:

MS-Access will by itself handle the data requirements. It is the cheapest solution, although somewhat limited. Due to Access's capabilities, we have decided that it will be used for the database platform. Access has its own version of SQL and as such is a good package for the Hospital 2000 system.

In Conclusion, ISIS Development recommends a graphical user interface using Windows on PCs, and a separate data server computer using MS-Access on Windows NT. The interface prototypes that will be presented will be done in MS-Access.

Hardware

There are two aspects to the system which may each be allocated their own hardware: the database and the user interface. Putting the data on a server allows for data sharing and centralization. First we discuss user-interface hardware considerations, then the data server.

By far, the most cost-effective setup for this system is to implement a system that will work with Windows PCs. The hardware for these is universally available and cheap, and also offers more than adequate power for Hospital 2000's system's needs, and expandability for the future. Thus we will be using some form of Windows PC for the user interface computers.

For the database, Windows PCs can be equipped for high-volume data throughput and are reasonably affordable. As such, we will be using PCs as the database, set up with special hardware to ensure that the system will be more than adequate for the Hospital 2000's system.