Requirement Specification Document

Of
Hospital Management System
 Table of Contents

Title Page no

1. Introduction ………..3
2. System Function ………..4
2.1. Register ………..4
2.2. Schedule Management ………..4
2.3. Analysis ………..5
2.4. Information extraction by
Central Administrator ………..5
2.5 Periodic Updates ………..5
2.6 Information extraction on
Client’s Side ………..5
2.7 Check Status
3. Non Functional Requirments ………..6
4. Functionality ………..7
4.1. Register ………..8
4.2. Schedule Management ………..9
4.3. Analysis ………..10
4.4. Information extraction by
Central Administrator ………..11
4.5 Periodic Updates ………..12
4.6 Information extraction on
Client’s Side ………..13
4.7 Check Status ………..14
5. Conceptual Model ………..15

Glossary ………..22
1. Introduction
It has always been a challenging task when it comes to managing things. This project deals with
designing a framework for centralized administrative tool for an integrated hospital management
system, which addresses all the major functional areas of modern multi-specialty hospitals and is
a fully integrated online system. It enables better patient care, patient safety, efficiency and
reduced costs. It provides easy access to critical information there by enabling the management
to take better decisions on time. For instance, the management can view the revenue generated
and expenses made by each hospital in the group and thus analyze the performance of a hospital.
The system provides the benefits of streamlining of operations, enhanced administration and
control, improved response, cost control and improved profitability. Throughout our discussion,
a server refers to the Central Administrator who will manage the hospitals and client will refer to
the individual hospital administrators. Some of the features of our software have been listed
below:
 Monitors, which hospital software’s are up
 Enable the automatic transfer of critical information from the central server to the clients
and periodic updates on both the sides (to manage network failures).
 Maintenance of the schedule and also the work sheet of the Doctors. The Central
Administrator can view and edit the schedule of any doctor at any time.
 Doctors can view their daily appointment schedules for any day.
 A way to extract the Statistical information about all the hospitals and storing for later
retrieval and comparison (and also about individual doctors).
 Maintenance of information about the equipments
 Information extraction in various combinations
 The software is highly secure and flexible. It allows the administrator to configure
different information access privileges for different individuals depending on their role in
the Hospital.
 The system provides the following reports and more at the click of button daily cash
collections, patient turnover, billing and medical records related reports etc. Enabling
management to take better decisions

2. System Functions
The current system under consideration deals with hospital management. The main functions of
this system are
 Register
 Schedule Management
 Analysis
 Information Extraction by Central Administrator
 Periodic Updates
 Information Extraction on Client’s Side
 Check Status
The rest of the section explains each of the function in detail.

2.1. Register
A new hospital software can register with the server and from then on, it will be monitored by
the administrator. This new hospital will be added to the database and only the hospitals which
are the members of this software can access its features.

2.2. Schedule Management

At any point of time the administrator can enter a doctor’s name or select a set of doctors and get
his/her schedule for a particular period of time. The administrator selects the hospital name and
the department from which he wants to view the list of doctors. He can also query by giving the
doctor’s name. The request is queried from the client database and the result shown to the
administrator. He can further edit the schedule of a doctor and save the changes done. On the
other end a doctor can see his schedule for any number of days.

2.3. Analysis
The Central Administrator can analyze the information stored in the Central database using
graphical analysis provided by the software. The tool will give the administrator a choice to do
comparisons of the performance of various hospitals in terms of the intake of patients, revenue
and expenditure etc over different periods of time in order to facilitate in a better decision
making.

2.4 Information Extraction by Central Administrator

The Central Administrator can extract any kind of information about the hospitals from the system. If the
information is present in the central system then the administrator can directly access that, else he will the
extract the desired information from the client system(s).

2.5. Periodic Updates

This is an implicit functionality of the system to ensure that there is consistency in the client side
database as well as server side database.

2.6.Information Extraction on Client’s Side

Client to client communication can take place only through the central sever. They cannot
communicate directly. Say a hospital administrator wants to view another hospital’s information
so whatever query is generated by it goes to the central database which redirects it the respective
clients database and sends the result to the client which generated the query.

2.7.Check Status
It’s very important to know that which hospital’s software’s are running up. After a particular
period of time all the clients will be sent a signal which they have to acknowledge signifying that
they are up and running.
3. Non-Functional Requirements
Some of the Non functional requirements of the system under consideration identified are
Network Reliability- It is assumed that when the network is down, the Central Administrator
can view the current status of the connected clients. It is assumed that network is fault-tolerant.

Security Issues- The periodic updates are sent across the network and are required to be
protected from unauthorized access by some fake users. The need for encrypted documents arises
at this point.

Authentication- Some stronger ways of identification and authentication is required.

4. Functionality
The use-case diagram of the system is shown below.
Four actors have been identified out of which two are primary and the two are secondary actors.
The Central Administrator, Client Administrator are the primary actors of the system and the
Central System and Client System are the secondary actors. We use the term Central System
and Central Server interchangeably. The following subsections explain each use-case in detail.

4.1. Register

Use Case: Register.

Actors: Client Administrator (Primary), Client System (Secondary), Central System (Secondary)
Purpose: To register a Client Hospital with the Central Server.
Pre-Condition: Client Administrator is identified and authenticated.
Post-Condition: The system registers the client hospital..
Overview: A Client Hospital should be able to register itself with the Central Server in
order to be a part of the network consisting of the central system and other registered
client hospitals.
Rank: medium
Main Success Scenario:
1. The Client Administrator enters the registration details in Client System.
2. The Client System in turn sends the register request to the Central System.
3. The Central System authenticates and sends a confirmation to the Client System.
4. The Client System displays the registration status to the Client Administrator.
Alternative Scenario:
2a. Invalid Registration Details
System notifies the error.
2b. Network failure
System notifies the error.
Frequency of occurrence:
Once
4.2. Manage Work Schedule

Use Case: Manage work Schedule

Actors: Central Administrator (Primary Actors)
Central System and Client system (Secondary Actors)
Purpose: To manage the schedule of a doctor or set of doctors for a set of days.
Pre-Condition: Administrator is identified and authenticated.
Post-Condition: The schedule of doctors are saved and stored in the database.
Overview: The Central Administrator can view the schedule of a doctor or set of doctors
for a particular period and hence can edit it if he/she wishes so. On the client
end the doctor can view his schedule and can confirm to the changes made to
his schedule.
Rank: High
Main Success Scenario
1. Administrator enters a particular doctor’s name and get his/her schedule for a period of
time, ranging from 1 day to 1 week.
2. Administrator enters a set of doctor’s name and gets theirs schedule respectively.
3. The Administrator edits a doctor’s schedule and saves it.
Alternative Scenario
1a. the name entered by administrator does not exist; in this case error is notified.
3a. When the doctor doesn’t confirm to the changes made in his schedule by the
administrator. In such case the administrator is notified along with the reason and
hence, the administrator decides accordingly.
Frequency of Occurrence
Can be many times in a day.
4.3 Analysis :

Use Case: Data Analysis.

Actors: Administrator (Primary), Administrator System (Secondary)
Purpose: To facilitate periodic analysis of data thereby helping in decision-making process.
Overview: Administrator may seek the analysis of daily data over a period of time. The
administrator will be choosing from a set of different tools for analysis. The data
will be taken from the local database and presented to administrator in digest or
pictorial form.
Rank: high
Pre-Condition: The analysis is requested after minimum stipulated period so that there will be
data for that period.
Post-Condition: Views will be generated for the analysis
Main Success Scenario:
1. The Administrator logs in.
2. He/She requests for the analysis of data for a period of time.
3. Data is available for that period in the local database.
4. Data is fetched and processed according to the administrator need.
5. The analysis is presented to the administrator along with options of discard/save.
6. The analysis is saved or discarded depending on the administrator decision.

Alternative Scenario:
1a. Invalid Username. The error is notified.
4a. If the data for that period is not available in the database, the administrator is notified of
the failure and prompted to reduce the time period of analysis.
Frequency of occurrence:
Periodic
4.4. Information Extraction by Central Administrator

Use Case: Information Extraction by Central Administrator.

Actors: Central Administrator (Primary), Central System (Secondary), Client System
(Secondary)
Purpose: To extract information about a hospital or a group of hospitals in various forms.
Pre-Condition: Central Administrator is identified and authenticated.
Post-Condition: The system displays the desired information to the Central Administrator.
Overview: The Central Administrator should be able to extract any kind of information about the
hospitals from the system. If the information is present in the central system then the
administrator can directly access that, else he will the extract the desired information
from the client system(s).
Rank: high
Main Success Scenario:
1. Central Administrator selects the type of information wanted – Hospital Information, get
some doctor’s schedule etc.
2. The Central System then looks for the desired information in its database.
3. If the information is not present in the central system then the system sends the query to
the client system(s).On successful reply, the System displays the desired output.
Alternative Scenario:
2a. Doctor’s name is invalid.
System notifies the error.
2b. Network failure
System notifies the error.
Frequency of occurrence:
Nearly Continuous
4.5 Periodic Updates

Use Case: Check Status

Actors: Central System and Client system (Secondary Actors).
Purpose: To update the databases of both client and Central administrator.
Pre-Condition: Both the Client and Administrator nodes are up.
Post-Condition: Both the databases are updated.
Overview: The database of the Central Administrator is periodically updated using the respective
client databases (over the network) in order to maintain data integrity and consistency
and reduce data redundancy.

Rank: medium
Main Success Scenario
1. The Central database connects to the respective client systems and updates the
information on its side using the Client databases.
2. On a successful update, the central administrator is notified.
Alternative Scenario
2a. In case of a network failure, the Central Administrator gets the appropriate
message on the screen.
Frequency of Occurrence
Can be many times in a day.
4.6. Information Extraction on Client’s Side

Use Case: Information Extraction on Client’s Side.

Actors: Client Administrator (Primary), Client System (Secondary), Central System (Secondary)
Purpose: To extract information about other hospitals (among the group of hospitals) in various
forms.
Pre-Condition: Client Administrator is identified and authenticated.
Post-Condition: The system displays the desired information to the Client Administrator.
Overview: The Client Administrator should be able to extract information about other hospitals
in the group. He can inquire about information regarding other hospitals, get schedule
of doctor’s in other hospitals and even check the present status of the network in case
some information exchange is required .In fact, even the doctors can inquire
regarding the same provided they have been given separate accounts.
Rank: medium
Main Success Scenario:
4. Client Administrator selects the type of information wanted – Hospital Information, get
some doctor’s schedule or Check Status.
5. The client System generates the desired query and sends to the Central Server to get the
desired information.
6. On a successful reply from the Central Server, the Client System displays the desired
output.
Alternative Scenario:
2a. Doctor’s name is invalid.
System notifies the error.
2b. Network failure
System notifies the error.
Frequency of occurrence:
Nearly Continuous
4.7. Check Status

Use Case: Check Status

Actors: Central Administrator (Primary Actors)
Central System and Client system (Secondary Actors)
Purpose: To check whether the particular hospital nodes are up or not
Pre-Condition: Administrator is identified and authenticated.
Post-Condition: The checked status is stored in the database of the Central Administrator.
Overview: The Central Administrator can view the status of a hospital or set of hospitals
at any particular point of time. Then he can store the status in Central System
at a point of time and also a history of statuses over a some specified period.
Rank: medium
Main Success Scenario
3. Administrator will send some minimal information to all Client Systems after a specified
amount of time.
4. If any response is obtained, it concludes that the hospital network is connected and it is
‘up’.
Alternative Scenario
2a. When the administrator doesn’t receive any response from a particular hospital, it
concludes that for that particular client system there is some problem in the network and
make its status as ‘down’.
Frequency of Occurrence
Can be many times in a day.