Project Hospital 2000

This is the comment from the customer - The Toward2000 Committee - regarding your initial proposal on the Project Hospital2000. First and foremost, we thank you for your efforts and hard-work to meet such a short deadline. We hope that. as you said, by working in tandem, we could deliver an ideal hospital to serve our community better. You will find that the comments follow immediately the section to which the comments belong, and the comments are written in red and italic.

ISIS welcomes The Toward2000 Planning Committee in the joint development of the Project Hospital2000 software system. Our intention is to foster an atmosphere of cooperation and interaction through the exchange of ideas vital to the vision you have of your system. By working in tandem, a comprehensive system can be created to encompass your needs for effective and efficient time management, and as a result, assist those who truly require attention ... the patients. The following document endeavors to continue the sharing of ideas between our two groups.

From the initial contact we have had with your administrative committee, our software group has identified two primary goals that the development of such a system should meet: 1) allocation of time/human resources and 2) allocation of time/space resources. To clarify, time/human resources reflect the basic scheduling of employees (both doctors and nurses), while time/space resources include the overall control of patient traffic within wards to ensure precise bed allocation and estimations of bed availability, as well as the scheduling of expected and unexpected operations. The desired system should be able to manipulate either of these resources in a variety of ways. The informal specification that follows explains and details just this.

System Overview

With the HSS assuming the majority of the hospital scheduling responsibilities, the system's users will: spend less time amidst the shuffling of paper, spend more time with patients, have access to immediate and accurate information on the status of hospital functions, and in turn, generate confidence within the workplace. As a result, hospital efficiency will increase on the whole. Users of the HSS will also find transition to the new system a gentle one with lucid, easy to understand commands and actions. This will establish a comfort with the HSS, rather than an alienation which so many other systems generate. With this combination of user confidence and comfort fostered by the HSS, the daily on-goings of the hospital will be simple and orderly.

The system overvies provides a good summary of the capabilities specified by our requirements. We especially agree with your heavy emphasis on friendly user interaction.

User Interaction

To further detail the ISIS interpretation of the Hospital Scheduling System, we are providing a listing of the functions recognized as vital to the system's operation. Two fundamental differences were noticed between the needed functions, thus requiring a slight alteration in the design approach to be considered. A distinction between wards was identified and split into two basic categories: operating rooms and wards. While most of the design is similar, recovery time had to be taken into consideration for functions which dealt with O/R. This added another level of complexity to the scheduling techniques necessary for the HSS, but in general to cope with scheduling from the O/R perspective a meeting number will be assigned to all operations to monitor all present and all upcoming scheduled operations. The designation of this unique meeting number will allow for easy cancellation and re-bookings for operations.

Functional Specifications For O/R

First, a general comment: we notice that in all functions (where applicable) the IDs of doctors, nurses and patients are needed as inputs. This, however, is quite inconvenient for our staff as we address each other by name rather than by a number. Given this, we would like you to enable us to have the option to either enter a name or an ID number for doctors, nurses, and patients (again, where applicable.) Should a name be duplicated, we would like you to bring up a list of possible completions (name with ID with other information regarding that doctor/nurse/patient) from which our staff can choose the one they want.

1. Schedule Operation

1.1 Schedule Patient to Operation Room:

1.2 Modify Previously Scheduled Operation

1.3 Operation Cancellation:

1.4 Assign Staff to Operation

We have great trouble understanding why we have to implement these functionalities. When we schedule an operation, we have already assigned a fixed number of staff to the patient, and thus there is no need to further assign/remove staff to the operation. If there are changes, we can modify via function 1.2 above. In all cases, we can only modify who are on an operation, not how many. It is very dangerous that we can remove a staff from an operation. This will potentially create a scenario where there is no doctor assigned to an operation! We strongly think that you mean "Staff" instead of "Operation." In this case, yes, we want to be able to add a doctor/nurse to our staff, remove her/him from our list, and so on .... We suggest that you should contact us ASAP to clarify this.

2. Wait List

2.1 Assign Patient to Wait List

2.2 Remove Patient from Wait List

2.3 Modify Wait List Information

2.4a View Wait List Information

2.4b View Patient Wait List Information

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.

3. Report functions for the O/R

3. 1 Create report for operation rooms

3.2 Create report for employees

3.3 Create report of daily patients

3.4 Create report for patient

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.

4. Ward/Bed Functions

4.1 Function Name: Add a bed

4.2 Function Name: Delete a bed

4.3 Function Name: Change bed info

4.4 Function Name: Display bed info

5. Ward/bed reports

5.1 Report Name: Bed Availability Report (ward)

5.2 Report Name: Bed Availability Report (entire hospital)

5.3 Report Name: Room Type Availability Report (ward):

5.4 Report Name: Room Type Availability Report (entire hospital):

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

6. Nurse Functions

6.1 Function Name: Add a Nurse

6.2 Function Name: Delete a Nurse

6.3 Function Name: Change Nurse info

6.4 Function Name: Display Nurse info

7. Nurse Reports

We would like to be able to print out nurse schedule, just like there is for doctors.

7.1 Report Name: Daily schedule report

7.2 Report Name: Weekly schedule report

7.3 Report Name: Monthly schedule report

7.4 Report Name: Nurse list report

7.5 Report Name: On-call list

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.

8. Patient Functions

8.1 Function Name: Add a patient

8.2 Function Name: Modify a patient

We would like to know how you would handle the situation where we have two patients with same name.

8.3 Function Name: Check-in patient

8.4 Function Name: Check-out patient

8.5 Function Name: Display Patient Information

8.6 Function Name: Patient Schedule

9. Patient Reports

9.1 Report Name: Patient Listing

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

10. Doctor Functions

We feel that more appropriate usage of words would be nice: for instance, one cannot delete a doctor or modify a doctor. We can delete a doctor off the database but deleting a doctor just doens't make any sense :)

10.1 Function Name: Add a doctor

10.2 Function Name: Delete a doctor

10.3 Function Name: Modify a Doctor

10.4 Function Name: Display Doctor Information

11. Doctor Reports

11.1 Report Name: Doctor Listing

11.2 Report Name: Doctor Daily Schedule

11.3 Report Name: Doctor Weekly Schedule

11.4 Report Name: Doctor Monthly Schedule

11.5 Report Name: Doctor's Patient Listing

Hospital Scheduling System: The User's View

The most important considerations in the design of a user interface are simplicity, consistency, clarity and speed of access. A difficulty that surfaces when designing any non-trivial system is the tradeoff between simplicity and speed of access. For the experienced user, much time can be lost in a day wading through several levels of menus. On the other hand, menus provide the easiest method of navigating the system.

It is with these considerations in mind that we have made our choices in designing the user interface for Hospital2000. With the understanding that the system will be accessed by various hospital employees, we are recommending a menu-based system. However, since the system will be used consistently by administrative personnel who will spend much of their time setting up the scheduling of operations and beds, we have limited the maximum depth of menus to three. In addition, we recommend "hot keys" (or shortcut keys) for direct access to most of the system tasks. This should allow rapid access to all essential system tasks.

From the user's perspective, we view the system as essentially two main functional units. The primary unit consists of the scheduling functions and for this reason, we have chosen to provide direct access to these tasks from the main menu. The secondary unit is the supporting database, consisting of the patient, doctor, nurse, ward and operating room information. We expect that these entities will need to be updated from time to time, but less frequently than the main scheduling of beds and operating rooms. Nevertheless, the ability to make changes to any of the information stored in the database will involve no more than two menu selections from the main screen.

As a customized system, we have attempted to simplify the scheduling tasks as much as possible. We intend to permit the user to arrange a time for an operation or a bed for a patient by providing a minimal amount of information, assuming that the patient data has already been entered. By using a graphical user interface (GUI), mouse support will also be available; this will further simplify the procedure.

As for the database, we are recommending a system that should have a familiar look and feel to any experienced computer user. We can accomplish this by using a popular database management system -- for prototyping the system we have chosen Microsoft Access. This should minimize the learning curve for the Hospital2000 staff and allow you to focus on the scheduling unit.

A final consideration in the design of the user interface is the generation of various reports. This system will have the capability to generate any report that is needed though the query features of the database management system. However, it is reasonable to consider a set of standard reports that are predefined in the system. We recommend, for example, that operating room schedules be printed out on demand. Since this was not previously specified we suggest further discussion of reports with you.

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.

We believe that the choice to use a GUI is a wise one, since it will add to the useablility of the system. Good job in highlighting the various features/drawbacks of the possible hardware platforms.

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.


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.

There are three major categories of hardware capable of running graphical user interfaces:

By far the most cost-effective solution is Windows PCs. The hardware for these is universally available and cheap, while offering more than adequate power for Hospital 2000's system's needs, and expandability for the future. Macintosh PCs are another reasonable choice, however they feature a higher price/performance ratio than Windows PCs, and are not a specialty of ISIS Development. UNIX Workstations offer superb performance but at significant cost. This additional performance would not benefit the kind of work being done at the user level, so the extra cost is not justified for the user interface computers. Thus we recommend some form of Windows PC for the user interface computers.

For the database, the same computers mentioned for user interface are also applicable. However, Macintosh computers are not designed for high-volume data throughput and would not be worth using as dedicated data computers, or servers. Windows PCs can be equipped for such a task quite affordably. Their performance however, while probably better than the Macintosh, cannot compare to that of UNIX servers. Since these are commonly integrated with PC workstations, a UNIX database server is a reasonable consideration for this system. UNIX machines are very expensive, however, and careful thought must be given to the performance required by this system. ISIS Development therefore recommends that either a PC or a UNIX computer be used as the data server, depending on Hospital 2000's requirements. In the meantime, it will be proto-typed on the PC platform.

Excellent and well thought out analysis. We agree holeheartedly with you choices of hardware systems. We are concerned, however about the difficulty and training issues regarding the UNIX systems. Our first priority is useability, and we need to know how we are affected in this manner, should we decide to purchase a UNIX server.

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.

Briefly, then:

Operating Systems:


The rundown of available databases is somewhat sketchy. Only one Unix option is given.

Summary of Platform Recommendations

ISIS Development recommends a graphical user interface using Windows on PCs, and a separate data server computer, either Oracle on UNIX or SQL server on Windows NT, subject to further discussion with the Towards 2000 Committee. The interface pre-prototypes presented are done in MS-Access.

User Interactions

Generally speaking we are very pleased with your efforts spent on designing a user-friendly environment. The buttons interface is very easy to use and we praise you for that. However, there are some places that we find that there are places that need some improvement. For instance, as mentioned above, we would like to stress on the point of having a listing for wards/treatment types, etc. so we can choose our inputs from and don't have to remember their names. We would also like to have a consistent naming convention (see the comments following the main screen for an example.) You can also find some suggestions immediately following the screen-shots as examples of what we would like to be improved.

On activation of this system, the user is presented with login screen and is prompted for a name (or ID) and a password. After login, the main menu appears on the screen. The user is presented with these 5 selections which will appear as buttons on the main menu:

The 'Book an Operation' button schedules a patient to an operation to be performed by a particular doctor. The time, day and location for this operation will also be determined.

When the user chooses the 'Book a Bed' option, a patient is scheduled to a particular bed in a particular room of the hospital.

The 'Staff Information' option allows the user to add, modify, delete, or display information on a particular staff member. This will generally be information of a doctor or a nurse. Any of the attributes of the staff member can be changed by the user. In this system, there is no protection of one's data. So, one individual can modify another's personal information. This is usually not recommended but this function was part of the customer's specifications. Hopefully, no one in this hospital is hostile.

We would like to have last name listed above the middle name (ie: last, middle, first) because we tend to remember our last names in formal environment.
A button allows us to see the working schedule would be nice.

The 'Patient Information' option is selected if the user wants to add, modify, or delete information on a particular patient. Again, any of the attributes of the patient can be changed by the user.

The 'Help' option is given at every screen to assist the user on what actions are possible and how the user is supposed to do something.

The 'Quit' option allows the user to exit the system. This would only be accessible from the main menu screen. The login screen should re-appear automatically. In order to get back into the system, the login info has to be re-entered.

At any screen where data has to be physically entered by the user, an 'OK' and 'Cancel' option is allowed. For example, when the user needs to modify information of a patient, the user enters the data for all the attributes of the patient that need to be changed and then presses the 'OK' button on completion. However, if the user decides to cancel the operation, then the 'Cancel' button should be pressed and the user is brought back to the main menu. Entering information is as easy as clicking on the required field and typing in the information.

At any time information needs to be entered, error messages will be shown on the screen to inform the user of problems with the input.

A basic sample execution of this system:

Assume the login information has been entered, and the user is facing the main menu screen. Now, assume the user presses the button labeled 'Patient Info'. The user is brought to another screen in which he's allowed to add, modify, delete, or display a patient record. He decides to delete the data and presses the appropriate button. Then, on another screen, the user enters the primary key(s) of the patient attributes. The user enters this data, and presses the 'OK' button. The system searches through the data base for information regarding this patient. If the patient is not found, then some sort of error message is displayed and the user is allowed to re-enter the data. Let's say the user is careful and enters valid data. The entire record is presented to the user on the next screen, so the user knows what he is deleting. He presses 'OK'. At this point, the user is given a warning screen to confirm the user's action. He presses 'OK' again, and the system does the job. Afterwards, the user is automatically brought back to the main menu.

Another sample transcript of the interaction with this system:

Again, the main menu screen is presented to the user. Assume, it is a doctor (a surgeon) who has come to schedule an operation for one of his patients. He presses the button labeled 'Book an operation' when he arrives at his computer. Another screen appears which allows the doctor to enter any information necessary for this operation. This would include the patient name as well as the time and place of operation. Finally, the doctor enters his name, and other appropriate info. After all this is completed, he presses the 'OK' button. At this point, if any of the fields are incorrect, or for whatever reason, he would be allowed to re-enter that information. For now, assume the doctor made no mistakes. In this case, the data is processed by the system. Then, the main menu screen reappears to begin another request.

HSS Management Plan

ISIS has developed the skeleton of a system which will largely rely upon a database engine, hence providing much of the system's functionality for the major information structures which must be monitored (for example: doctor, nurse, and patient). By keeping track of these information entities within a relational 'table' form - the relationships among these entities can be easily cross referenced to generate the desired record process, whether it be simple report listing or record modification. This approach we believe will give the HSS a flexibility which might have gone unrealized had another methodology been selected.

With this in mind, the overall thrust of the Hospital Scheduling System from an algorithmic perspective will also be greatly dictated by the choice of database. Through basic query techniques, which are provided for within the database structure, many of the overall desired system processes can be achieved in a satisfactory manner. To deal with such scheduling dilemmas as waiting lists and operation scheduling each patient will be given a priority number to identify the severity and urgency of his/her medical state. Although not a 'true' algorithm, this tagging of patients with a priority number, will give a reasonable means of placing patients appropriately within the operation scheduling system. To alleviate the problem in determining 'when' someone or something can be scheduled, regardless of the nature of what is being scheduled (for example, the booking of a patient, an operation, or an employee's work schedule), a probing algorithm will be utilized. Whether this is a greedy algorithm or a more simple linear probe will be left up to the decision of the programmers after some preliminary testing and simple implementation is done. Aside from the aforementioned algorithms, much of the algorithmic dimension of the HSS shall be guided vastly by the database portion of the system. As a general overview of the system and the relationships among the various data members the following schematic is provided:

We agree with the use of relational tables to store data in the database engine. Crossreferencing is certainly a very important feature for us, and so the relational table model suits our needs best. While we are less concerned with the actual algorithms used to implement the priority scheme, we ask that the user will be given some degree of flexibility to monitor and modify priorities associated with patients. In particular, if the priorities happen to be assigned automatically, the user should have some way to overide them. As an aside: we believe that the use of the term "probe" in the document is a objectional misuse of terminology and that the word itself should be confined to medical and/or Star Trek contexts only!

HSS Schematic

To further illuminate the details of the information structure of the HSS, a list is provided below containing each of the data entities along with its vital elements (attributes) that the system must store. By no means is this list exhaustive, but instead an indication of what we have recognized as vital information. If anything has been overlooked, feel free to contact any member of the ISIS for clarification.






Equipment (may or may not use this table depending on time constraints):



Operations/Hospital Events:

Should reserve an ID (maybe 0) for "Time off" so that staff can book time off in the schedule (it's not really an "operation" but more of an event).




After thoroughly examining the informal specifications for Project Hospital2000, we at ISIS have decided that much of what you desire for your system is attainable, given albeit the short amount of time to develop such an expansive system. The only system aspects that will not be implemented within the HSS are automated scheduling (for employee scheduling, doctor/patient status reports, and letter forming. Most functions in the Hospital Scheduling System will have the capacity for automatic scheduling, especially those involving bed availability, operation scheduling and waiting lists, except for those functions which schedule an employee's work itinerary. The fluctuating nature of a doctor's practice (between hospital and family practice), coupled with the inevitable occurrences of sick days and vacation time, make employee scheduling something much more tailored to a manual entry basis. Doctor and patient status reports will not be part of the HSS due to the obscure description given of them, with the intention that these will be covered in the above listed patient and doctor reports. If we have misunderstood the seeming overlapping quality of these reports, please notify any member of the ISIS group of any glaring discrepancies. Finally, the letter forming process for operation notification (to patients) is something which is slightly outside the scope of the system which ISIS believes it can implement within the specified time period. However, if time does permit, this will be a definite aspect of the HSS which our programmers will endeavor to implement.

Once again, all at ISIS shall aim at meeting each of the criteria specified by the Project Hospital2000 committee in a manner deemed to be acceptable to all involved, especially the future users of the system. If any part of the Hospital Scheduling System has been misrepresented in our preliminary analysis please contact any of the ISIS management representatives listed below:


Ward Function Development:

O/R Function Development:

System Overview:

Interface Development and Research:


algorithm - a well structured method for solving a particular computational or logical problem.

database - a collection of files that store related information and allow updates and sophisticated queries.

function - an action or procedure the system must perform

GUI - Graphical User Interface. A "user interface" (see below) which uses computer graphics combining features such as windows, buttons, menus, and icons.

ISIS - Isis, a goddess in Egyptian mythology, was given powers by the god Thoth to restore life. She was one of the most important figures in all of Egyptian mythology. In our case, also an acronym for International Software Information Systems.

O/R - Operation Rooms - a ward whose rooms are used for surgery.

Query - a common set of database commands which allow for the manipulation of records (e.g. insert, select, update).

Platform - the underlying hardware and software on which our system will depend

Report - a system output listing specified subsets data from the database in a fixed, people-friendly format.
server - a computer dedicated to file and database work on which the system's data would reside. Doesn't do user interaction

User interface - the portion of a program (including things like windows and buttons) which allows a person to communicate with the computer

Workstation - a computer used by end-users for interactive work such as data entry and retrieval. Runs the "user interface".!

[Table of Contents] [ISIS homepage]