Project
Hospital 2000
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.
The HSS (Hospital Scheduling System) will provide Project Hospital2000 and its future users a plethora of scheduling abilities of which include:
- reliable operation scheduling and updating of waiting lists, based on patient status.
- automatic determination of bed availability status for wards.
- advance employee schedule viewing inclusive of on-call status.
- password security system for employees.
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.
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 date/time, recovery duration, treatment, patient ID number, doctor(s) ID, nurse(s) ID
Some of the treatment names are quite long, and difficult to remember. Thus we would appreciate if you can have a list where we can choose type of treatment from.Error Conditions:
Should a list of treament type be implemented as suggested above, the input for treament type should be always correct.
The patient name was not an input, was it ???
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 date/time, recovery duration, treatment, patient ID number, Doctor ID, Nurse ID, Meeting number
Error Conditions:
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:
Function: Assign a doctor to an operation. Checks for doctor schedule conflicts.
Inputs : doctor ID, operation date/time, room number, Meeting number
Error Conditions:
Function: Deletes a doctor from an operation.
Inputs : doctor ID, Meeting number
Error Conditions:
Function: Assign a doctor to an operation. Checks for doctor schedule conflicts.
Inputs : Nurse ID, operation date/time, room number, meeting number
Error Conditions:
Function: Removes a nurse from an operation.
Inputs : nurse ID, Meeting number
Error Conditions:
Function: Assigns a nurse to a ward.
Inputs : nurse ID, ward number
Error Conditions:
Function: Assigns a patient to the wait list
Inputs : patient ID, duration, treatment, priority number
Error Conditions:
Function: Removes patient from the wait list.
Inputs : patient ID, queue number
Error Conditions:
Function: Changes Priority number or treatment for a given patient.
Inputs : patient ID, queue number, priority number, treatment, duration
Error Conditions:
Function: Lists all patients currently awaiting an operation(s).
Inputs : none
It would be nice if we can optionally enter a treatment type (again, could be chosen from a list) in which case only patients who are waiting for that type of operation/treatment are listed.
Error Conditions: none
Function: Lists a patient current waiting status for an operation(s).
Inputs : Patient ID
Error Conditions: none
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.
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 day's report is done for the room. This report will also list:
Error Conditions:
Function: generates report for employees' schedule
Inputs : doctor/nurse ID, start date, <finish date>
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 day's schedule for the employee.
The report will also list:
Error Conditions:
Function: generates report for patient (query)
Inputs : patient name/ID#
Outputs : lists a patient's operation and appointments, listed in order of date. Searches on both patient's name and ID. Also lists:
Error Conditions:
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.
Input: - All attributes of bed (availability field optional)
Output: - Will add a bed to the system
Can be added to any ward or room
default setting will make a bed available
Error conditions:
Input: - Ward number, Room number, Bed number
Output: - Will delete a bed from system
Error conditions:
Input: - Ward number, Room number, Bed number, {fields that need to be changed}
Output: - Modifies bed fields
Used when beds moved around in the hospital
Also used to manually modify bed availability
Error conditions:
Input: - Ward number, Room number(Optional), Bed number(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 number
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:
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:
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
Input: - Room type
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:
Input: - Room type
Wouldn't we want to know what ward we are looking at? - Are we missing a ward input?
Output: - as above, except for the entire hospital, and broken down by ward
Error conditions:
The functions listed below outline the basic functions needed to manipulate and keep track of information regarding nurses within wards.
Input: - all nurse fields, except for nurse number
Output: - adds a nurse into the database
- assigns a unique nurse number to each nurse
Error conditions:
Input: - nurse number
Output: - deletes a nurse from the database
Error conditions:
Input: - nurse number, {all fields that need to be changed}
Output: - modifies nurse info fields (i.e. change of name, phone numbers, etc)
Error conditions:
Input: - nurse number or nurse name
Output: - displays a nurse's whole record
Error conditions:
We would like to be able to print out nurse schedule, just like there is for doctors.
Input: - date or (none)
Output: - outputs a schedule for a particular day listing the nurses working that day - default is current day
Error conditions:
Input: - date or (none)
Output: - as above, except for an entire week, broken down by day - default is current week
Error conditions:
Input: - date or (none)
Output: - as above, except for an entire month, broken down by week and day - default is current month
Error conditions:
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
Error conditions:
Input: - (none)
Output: - generates output listing all nurses that are
on call currently
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.
Input: - All patient fields
Output: - A unique identification number is assigned - Patient is added to the database
Error Conditions:
Input: - Patient identification number or patient name
Output: - Displays patient information - User able to change information in field(s)
Error Conditions:
We would like to know how you would handle the situation where we have two patients with same name.
Input: - If patient is new then, Add a patient.
Would you clarify on what you expect the user to key in ?
If patient is in database then, Modify a patient.
Specify ward that patient will stay in
Output: - Assigns patient a room and bed number specific to the ward
Error Conditions:
Input: - Patient identification number
We feel that we should keep track of the staff who releases the patient as well.
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:
Input: - Patient identification number or patient name
Output: - Displays all information in patient fields
Error Conditions:
Input: - Patient identification number or patient name
Output: - Displays appointments with doctors or operation date/time(s)
If there are no times booked, we would like the system to print out something stating that fact as well, rather than just give staff a blank screen which may make our staff think something might be going wrong.
Error Conditions:
Input: - Specify a particular ward(s) or entire hospital
Output: - Listing of all patients, their identification number, name, and location
Error Conditions:
Each of the identified functions required for doctor information is listed below in detail, including the generation of reports.
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 :)
Input: - All doctor fields
Output: - A unique identification number is assigned - Doctor is added to the database
Error Conditions:
Input: - Doctor identification number of doctor to be deleted, doctor identification number of replacement doctor
We feel that specifying a replacement doctor is not very necessary. For instance, a doctor moves and we can't find a replacement for him yet, we would still want to remove his record from the database, don't you think?
Output: - Remove the doctor from the database, re-assign doctor's schedule to another doctor
Error Conditions:
Input: - Doctor identification number or doctor name
Output: - Displays doctor information, user able to change information in field(s)
Error Conditions:
Input: - Doctor identification number or doctor name
Output: - Displays all information in doctor fields
Error Conditions:
Input: - Specify a particular ward(s) or entire hospital
Output: - Listing of all doctors, their identification number, name, and their specialization
Error Conditions:
Input: - Doctor identification number, date (default is current date)
Output: - Display the specified day schedule for the specified doctor
Error Conditions:
Input: - Doctor identification number, week (default is current week - Sunday to Saturday)
Output: - Display the specified weekly schedule for the specified doctor
Just to make sure that we agree on the output: the date of the Monday of the week will be nice: (eg: the week of Jan. 13, 1997.)
Error Conditions:
Input: - Doctor identification number, month (default is current month)
Output: - Display the specified monthly schedule for the specified doctor
We would like to keep track of the year as well so we can keep track of records from year to year.
Error Conditions:
Input: - Doctor identification number
Output: - Lists all the patients currently under the supervision of specified doctor
Error Conditions:
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.
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.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:
Macintosh PCs
Windows PCs
UNIX Workstations
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.
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:
UNIX of some flavour will be shipped with the UNIX machine if that is chosen as the server. It features high performance and reliability, and would be recommended in this situation.
PCs can run "plain" 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 would be the recommendation if a PC server was chosen.
For the end-user computers, again either Windows is possible,
and in this case it doesn't really matter which is chosen. "Plain"
Windows would be sufficient and is cheaper, and is what the prototype will
be developed in.
Databases:
For UNIX platforms, ISIS Development recommends Oracle as the database server. It is reliable, efficient, and well respected in the industry. Additionally, tools exist for using Oracle with Windows user interfaces such as the one being prototyped.
Windows servers, especially with NT, run SQL Server well. It, too, is well-respected and has tools for use with Windows. If a Windows server is chosen, SQL Server would be the recommended database platform.
MS-Access will by itself handle the data requirements.
It is the cheapest solution, but also the least efficient and most limited.
High volumes of data will eventually require one of the aforementioned
options. However, because of Access's capabilities, the decision of database
platforms can be delayed until later in the development cycle.
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.
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:
We feel that the "book operation" button should be renamed to "schedule operation" instead to describe the functionality of the button better.
The logo looks very good, however, we would love something more "conventional" for our system.
It seems that the "Stop" button is to exit the system, you should be aware
that this is a permanent system, and staff will not have a chance to exit
the system
The "Book bed" button takes us to the "Ward Scheduling" screen. We would like
to have a consistent name so our staff can be sure that they didn't do anything
wrong.
Book an Operation
Book a Bed
Staff Information
Patient Information
Help
Quit
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.
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:
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.
Doctors:
Keeps track of basic doctor information. Any information
about qualifications, scheduling etc. is stored in
other tables.
Nurses:
Keeps track of basic nurse information. Any information
about qualifications, scheduling etc. is stored in other tables.
Patients:
Keeps track of basic patient information.
Schedule:
The main table for any "scheduled" event in
the hospital.
Qualifications:
Keeps track of staff qualifications. Basically tells you
whether doctor x is qualified to perform operation y.
Equipment (may or may not use this table depending on time constraints):
Keeps track of which equipment is required for a given operation. No primary key on this one since any operation might require more than one type of equipment. It might be better to split this up into two tables to save the end-user typing in the same piece of equipment six times.
Numeric_Series:
This table keeps track of any number that is to be incremented in the system. Examples:
Waiting_List:
This table keeps track of the waiting list for patients.
Operations/Hospital Events:
This keeps track of the different types of operations that the staff are capable of performing. This is also used in the schedule to tell doctors/nurses WHAT they will be doing at a given time.
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).
Ward_bookings:
This keeps track of all of the bookings in the "recovery" ward. This is where patients "check in" and "check out" of rooms.
Beds:
Keeps track of which beds are "currently" in
use in the hospital.
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:
Christine Anderson
Norman Chow
Chiasen Chung (Charles)
Jonathan Chang
Jordan Goudreau
Don Luu
Liz Wong
Brandon Kurucz
Michael Shareski
Peter Macmurchy
Donald Tetreault
Conway Yu
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".!