Figure 1: HMS main dialogue screen
The operating platform for the HMS will be Intel based personal computers. This platform was chosen for ease of acquisition, low cost and possible ownership of a number of units by the city hospital. A UNIX mainframe platform was considered but was rejected due to cost considerations.
The software system will be developed using Microsoft Access to
design and build the user interface while Oracle is being considered
for the database features. Microsoft Access was chosen for its
ease of use and flexibility when prototyping systems with windows
type graphical user interfaces.
Sounds like a good system. It should meet our requirements.
Customer Comment
The HMS will use a windows type graphical user interface. This type of interface was chosen as it typically involves very little additional training. Figure 1 illustrates a preliminary design for the systems main dialogue screen.
The HMS main screen will display scheduling information in a clear concise format. All screen functions are accessible using a pointing device (i.e. a mouse) to select the desired action. The current time and date are to be displayed on the screen at all times. The pull down menu bar at the top of the screen can be accessed either using a pointing device or with a special set of key-strokes (such as ALT =). A help option is accessible via the pull down menu bar.
Scheduling options may be accessed directly from this main screen. It was felt that scheduling options would be the most commonly used function. Hence, the scheduling options must be easily accessible; this was the basis of the decision to include scheduling options on the main screen.
The user can select scheduling options for a given ward, operating theater or room by clicking on the applicable buttons at the top right of the main screen. These functions may also be accessed by using the pull down menus at the top of the main screen.
All scheduling information is displayed in the large box in the center of the main screen. Figure 1 shows an example of the staff/ward schedule option. The numbers below the display box indicate the date of the given shift. Vertical and horizontal scroll bars will control the user's view of this display box. This display window can be changed to show operating theater and room scheduling information either by using the buttons [to the right of the display box] or buy using the appropriate pull down menu item.
Personnel options may be invoked by clicking on the 'Personnel' button at the bottom of the main screen. A preliminary design for the personnel options screen is shown in figure 2. From this screen, one is able to add and delete staff records and update existing records. An error message box at the bottom of the screen informs the user of possible input errors.
Patient options may be invoked by clicking on the 'Patient' button at the bottom of the main screen. A preliminary design for the patient options screen is shown in figure 3. From this screen, one is able to perform all of the necessary patient functions. The appropriate functions can be invoked by clicking on the appropriate button [at the right side of the screen - see figure 3]. An error message box at the bottom of the screen informs the user of possible error conditions. All wait list options are controlled from this screen.
If a Microsoft Windows type of interface system is being used, will it conform to common Windows procedures for keyboard shortcuts, i.e. CTRL+S = Save, CTRL + O = Open File.
This section discusses some possible implementation details for the project. The material is quite technical in nature and would be beyond the scope of the average user evaluating the project. In fact, this section has been included merely to satisfy the assignment specifications. Realistically, it is much too early to be discussing in the life of the project to be discussing technical implementation details.
A very important aspect of this project will be the patient admissions waiting list. As circular queues are easily maintainable, this will be the main data structure for the patient wait list. Patients will always be added to the wait list at the tail of the queue and will be admitted to the hospital when they reach the head of the queue.
The room schedules will probably be implemented as linked lists. The staff schedule and operating theater schedule will also be implemented using linked lists. As these items would most often be accessed sequentially and be of varying lengths, linked list implementation makes sense.
When a patient is to be admitted, a greedy algorithm is to be
used when finding a room. Searches for available rooms are to
commence from the first day after the current date. If a room
is not available for that date, the next day is investigated.
The search continues in this fashion until a room is found for
the patient.
This discussion seems to contradict the discussion of Operating
Platform, which indicates that database tools will be used to
store the information. In addition, data structures have not been
mentioned clearly. We would like to know what are the main data
objects for this system, and their respective attributes. This
will give us an idea of how well you understand our requirements.
We don't think its too early to mention preliminary data structures,
even if they are subject to future changes when deemed necessary.
Customer Comment
Next Section
Previous Section
Back to the Functional Specification titlepage
Back to Sirius Software Product's Home Page