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 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 HOSPITAL 2000 planning committee is pleased to see that our primary goals coincide.The HSS (Hospital Scheduling System) will provide Project Hospital2000 and its future users a plethora of scheduling abilities of which include:
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. In addition, being aware of the dynamic and everchanging
nature of a fastpaced hospital environment, the system will have a level of
flexibility in its functinal applications to ease its use. Hence, users of the
HSS will also find the 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 committee would like to stress the fundamental
importance of reliability and accuracy over a finely tuned human/computer
interface. The lives of many potential care recipients rely on the durability of
the data integrity in the system. Thus any deficiencies in this regard may
result in the inadvertant loss of patron life, ultimately defeating our
resonisbility to the general public and our commitment to patient
safety. However, we believe the attention to HCI is still very important.
To further detail the ISIS interpretation of the Hospital
Scheduling System, we are providing a listing of the functions and their
interfaces 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.
Also included is a detailed description of the interfaces of
the functions to establish a feel for how one might navigate around the HSS and
each of its composite functions. This will provide a general sense of how the
system's users will interact with the HSS through each of its steps, when
presented with particular tasks to be executed (ie. 'admitting a patient').
Screen images are provided to simulate the system currently being designed -
note: this is only a preliminary prototype and may not evolve exactly as
represented in this document.
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 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:
Overall, the HSS will be responsible for the majority of scheduling duties as far as it relates to patients, doctors, nurses and the wards/rooms in which all activities take place. With such a system in place, many needs must be met to ensure the reliable operation of the HSS. For this reason, we at ISIS recommend the following future provisions:
The Committee would be interested to know for sure if the tutorial sessions will be included with delivery of system or not.
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.
ISIS promises to provide a system both flexible and reasonable in its applications and their relative ease of use. Aside from a few mitigating circumstances regarding this project, the majority of the HSS's desired tasks will be implemented to the expected standards and quality of operation. What follows is a detailed listing of these project bounds.
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.
To further elaborate upon the bounds of this project, two other system areas must be addressed. It is assumed that a accounting system will operating parallel to the HSS. To this end, the HSS shall only be responsible for simple cost keeping, and the maintenance/modification of hospital resource records from which accounting bills can be generated. Password functionality will not be of a terribly complex nature. Instead, it will consist of a global staff password, through which the system can be used. After a designated amount of time has elapsed, a screen lock will occur and access will once again have to be made via the global staff password. This represents the extent to which both cost-keeping and password security will be implemented in the Hospital Scheduling System.
The project objectives have already been agreed upon, thus the Committee has no problems with the lack of automated scheduling for employee records. Similarily, the Committee does not expect a full acounting package from the system.Regarding the global password decision, the Committee believes that an individual user password and login name would be preferrable. However, the Committee is willing to remain flexible on issue, so long as ISIS can justify the decision with a benifit in reduced development costs and demostrate that no security comprimises exist as a result of the decision.
Although prelimimary system criteria will be limited to prototypes, this will enable the Toward2000 Committee to view initial mock-ups of the HSS and determine if the thrust of its direction is agreeable. Hopefully, this shall be sufficient to develop an comprehensive understanding of the true system to meet the needs for Project Hospital 2000.
To enable a more coherent logical parcelling of the HSS, the system has been separated into five distinct processing areas. This will allow for a more straightforward understanding of the functionality which comprises much of the systems integral processes. The five processing areas are as listed:
Each of the above listed processing areas have the basic ability to add, modify and delete (the exception being patients as they can not be removed from the system), as well as reports particular to their designated areas (ie. nurse reports). Process staff requests is broken down into smaller subsidiary parts representing the actual staff members within the system - doctor and nurse. Other than this general distinction, the organization of the system is fairly intuitive.
In order to give a more lucid understanding of the system, we have included a simple diagram below which outlines the major entities and relationships between them. An example of an entity would be a patient's attributes and all data which the system uses to relate them with other entities. A relationship is just as was implied above, and entails the data entities may share among themselves.
