Hospital Management System Requirements Sheet

Hospital Management System Requirements
Sheet
(Subject to further change)
This is an informal specification of what we as hospital administrators want from the

company designing a system to help us manage our hospital efficiently and effectively.
General Problem Statement

Due to budget cutbacks and general concern for providing the best service possible to the
public, we as a hospital would like to ensure that we are using our scarce hospital resources
in the most efficient manner possible. With this in mind we would like you to design a
system which will help us manage our hospital in an efficient, effective manner. Specifically
the system should help us schedule and monitor the various resources that we have at the
hospital. This includes keeping track of available beds, waiting lists for patients, patients
expected length of stay, scheduling of surgeries, patient notification and billing, scheduling
of nurses and doctors.
The following information provides a more detailed breakdown of how our hospital is
organized. The main hospital consists of one building with 10 floors. here are 7 wards
which occupy various floors of the hospital.
Ward Floors Beds
Obstetrics 8 50
Cardiology 7 50
Intensive Care 6 50
Recovery 4,5 100
Geriatrics 3 50
Pediatrics 9 50
Operating 2 20
DATA
The system must store the following information:
 For hospital (physical building):

o # of wards
 For each ward:
o type of ward
o # of beds
 For each bed
o ward it's in
o whether or not it's occupied
o patient who's in it
o Date patient started occupying bed.
Scheduling of hospital staff must take the following information into account. Each floor
requires a supervising nurse and 5 regular nurses during the day and 1 supervising and 2
Regular nurse in the evenings. Obstetrics, Cardiology, Intensive care and Operating all
require nurses with that specialty. Two doctors with the appropriate specialty are required
during the day and one in the evening for each floor. two doctors and two nurses are
required for each operation.
For hospital staff:
 Name (Last Name, First Name)

 Address (Full Address, including city, province/state, country)
 Position (Doctor or Nurse)
 Level (Supervising, Regular)
 Specialty (Cardiology, Pediatrics...)
 Schedule to work:(which consists of the following entries)
 Date to work. (Month/Day/Year)
 Hour to start working (In military format e.g. 24:00)
 Hour to end working (In military format)
 Ward in which to work.
For doctors the following additional information:
 Operating schedule
 (all stuff from schedule above)
 type of operation
 patient to operate on
The system should also be able to keep track of certain patient information. The system
should generate a notification letter 2 week before a patient is admitted to the hospital as
well as lists of patients being admitted and discharged on the next day. Finally the system
should generate an invoice for the patients stay.
For patients:
 Name (Last Name, First Name)

 Address (Full Address, including city, province/state, country)
 Insurance number (SIN, whatever it is in the states)
 Type of treatment required.
 For patients on waiting list:
 Position on waiting list
 Priority
 Date (first on waiting list)
 For patients in bed:
 bed info
 The system should also:
 Keep track of past info.
e.g. Old schedule, patients who were there, whether or not operation was successful.
ACTIVITIES
The system must be able to perform the following actions. (JUST EXAMPLES!)
1. Must schedule hospital staff according to the following rules:

o Staff must not work too many consecutive shifts.
o Staff cannot be off work for too many consecutive shifts.
o The number of staff working must be as large as possible at
o all times.
o Doctors cannot be scheduled to work a ward and operate at the same time.
2. Manage the waiting list:
o Must be able to add patients to the waiting list
o Must be able to take patients off the waiting list:
 For those who got spontaneously better just remove from list.
 For those who got a bed, transfer patient info to bed.
 As patients removed from waiting list, positions must be updated
according to SOME rules. e.g. patients of higher priority move up list
faster.
3. Add and remove hospital staff:
o Note this may mean altering the schedule for every other staff member who is
working
Class Diagrams Examples

Here we provide some examples of class diagrams:
 Design Pattern - Abstract Factory

 Domain Model - Library
 Domain Model - Hospital Management
 Domain Model - DICOM Model of the Real World
Abstract Factory Design Pattern
Abstract Factory is creational software design pattern. This pattern provides interfaces for
creating families of related or dependent objects without specifying their concrete classes.
Client software creates a concrete implementation of the abstract factory and then uses the
generic interfaces to create the concrete objects that are part of the family of objects. The client
does not know or care which concrete objects it gets from each of these concrete factories since
it uses only the generic interfaces of their products.
Use of this pattern makes it possible to interchange families of concrete classes without changing
the code that uses them. It separates details of implementation of a set of objects from their
usage.
Class Diagram Example - Abstract Factory Design Pattern
Library Domain Model

Library Domain Model describes main classes and relationships which could be used during
analysis phase to better understand domain area for Integrated Library System (ILS), also
known as a Library Management System (LMS).
Class Diagram Example - Library Domain Model
Hospital Management Domain Model

Domain model for the Hospital Management System is represented by several class diagrams.
Hospital Organization Domain model - Patient, Hospital, Staff - Operations, Administrative,
Technical.
Domain model - Patient, Doctors and Treatments
DICOM Model of the Real World

An example of class diagram representing domain model ("model of the real world") for Digital
Imaging and Communications in Medicine (DICOM). This diagram is based on E-R model
Fig.7-3 of DICOM standard Part 3 - PS 3.3-2009.
Diagram represents DICOM extended domain, abstract description of the real world objects used
in the Modality-IS Interface. Modality is a piece of imaging equipment, e.g. computed
tomography (CT) or ultrasound (US).
A Patient is a human or an animal receiving, or registered to receive, healthcare services, or is
the subject of research studies. A Clinical Document is a part of the medical record of a patient.
It is a documentation of clinical observations and services provided to the patient.
A Service Episode is a collection of events, context in which the treatment or management of an

arbitrary subset of a Patient’s medical conditions occurs. Service episode is entirely arbitrary; it
may include a single outpatient visit or a hospitalization, or extend over significant period of
time, e.g., the duration of a pregnancy, or an oncology treatment regimen. A service episode may
involve one or more Healthcare Organizations (administrative entities that authorize
Healthcare Providers to provide services within their legal administrative domain, e.g.
hospitals, private physician’s offices, multispecialty clinics, nursing homes).
Visit is a part of service episode, collection of events that fall under the accountability of a
particular Healthcare Organization in a single facility. A visit may be associated with one or
more physical locations (e.g. different rooms, departments, or buildings) within the same facility.
An Imaging Service Request is a set of one or more Requested Procedures selected from a list
of Procedure Types. An Imaging Service Request is submitted by one authorized imaging
service requester to one authorized imaging service provider in the context of one Service
Episode. An Imaging Service Request may be associated with one or more Visits that occur
within the same Service Episode.
A modality Scheduled Procedure Step is an arbitrarily defined scheduled unit of service, that is
specified by the Procedure Plan for a Requested Procedure. It prescribes Protocol which may be
identified by one or more Protocol Codes. A modality Scheduled Procedure Step involves
equipment (e.g. imaging equipment, surgical equipment, etc), human resources, supplies,
location, and time.
A Modality Performed Procedure Step is an arbitrarily defined unit of service that has actually
been performed (not just scheduled). It contains references to zero or more Series of Images.
Class Diagram Example - DICOM Domain Model for Modality-IS Interface

Hospital Management System Requirements Sheet

Uploaded by

Copyright:

Available Formats

Hospital Management System Requirements Sheet

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hospital Management System Requirements Sheet

Uploaded by

Copyright:

Available Formats

Hospital Management System Requirements

This is an informal specification of what we as hospital administrators want from the

General Problem Statement

Ward Floors Beds

Recovery 4,5 100

 For hospital (physical building):

For hospital staff:

 Name (Last Name, First Name)

For doctors the following additional information:

 Name (Last Name, First Name)

1. Must schedule hospital staff according to the following rules:

Class Diagrams Examples

 Design Pattern - Abstract Factory

Class Diagram Example - Abstract Factory Design Pattern

Library Domain Model

Class Diagram Example - Library Domain Model

Hospital Management Domain Model

DICOM Model of the Real World

A Service Episode is a collection of events, context in which the treatment or management of an

You might also like