CASE

STUDY
HOSPITAL MANAGEMENT SYSTEM

NAME : HARSH GUPTA STD :

SECOC16
SUBJECT : SOFTWARE ENGINEERING

Aim
To study the principles of software engineering and to link knowledge to a real-
world application of an online Hospital Management System (HMS).

Objective
The project is aimed to develop to maintain the day to day state of admission/discharge of patients, list
of doctors, reports generation, and so on. It is designed to achieve the following objectives:
1. To computerize all details regarding patient details & hospital details.
2. Scheduling the appointment of patient with doctors to make it convenient for both.
3. Scheduling the services of specialized doctors and emergency properly so that facilities provided by
hospital are fully utilized in effective and efficient manner.
4. The information of the patients should be kept up to date and there record should be kept in the
system for historical purposes.

System Description
The Hospital Management System (HMS) is a web application, which used for the
control of hospital services. The HMS web application can be accessed by either
mobile or computer browser. The HMS application combines all details
regarding doctors, patients, nurses, hospital administrative, etc. into one
software. It has parts that make up a hospital with various professions. This
chapter has three main subtitles in order to illustrate the working principle of
the HMS system clearly. Firstly,
the main modules of the system will be mentioned with its purposes. Then, the
main users of the system with regard to their roles and privileges. And Finally,
the complete working flow of the system will be explained.

Software Development Model

The Software Development Lifecycle (SDLC) that will be used for the development
of the HMS web application is the Agile SDLC Model. This model has been
chosen
because of many reasons including:

• It minimizes the risks by creating software in the form of minor

boxes (iterations).
• It allows for recurrent alterations.
• It improves the quality since defects are found and fixed early. (Existek, 2017)

• It enables the customer to see the result to check if he is satisfied

or not. In other words, it helps to release the first product version fast.
• It does not treat the development steps as large sequential
steps. It makes them all ongoing processes instead.
• It tends to work well in small projects where flexibility and speed
are essential. (Jamsheer K., 2018)
Besides, according to research that has been conducted by the Standish
Group, the Agile model has achieved a high rate of success that surpasses the
Waterfall model success rate

On the other hand, it has some limitations like:

• The new requirements might clash with the existing system architecture.

• Changes in the system may be led to exceed the expected time

in some cases. (Existek, 2017)
In conclusion, agile is the best for the HMS web application since it allows for
more flexibility and incremental iteration, consequently, more features
(adjustment of requirements) can be done. The Figure below shows the
agile model’s
process of development

The Working Flow of HMS System

HMS System allows the patients to register via a registration module (form), which

gathers and stores all required patient’s data such as name, e-mail, gender,
etc. Registered patients can skip this step and login directly using their username
and password through the login module. Nevertheless, unregistered users can
only take advantage of major system features such as viewing the hospital
timings. After the patient creates an account and register, he can access the
allowed system features/functionalities for patients. Patients can view available
appointments, book
an appointment and manage his/her own profile. After the patient book an
appointment, he can visit the hospital according to his appointment.
Once the patient reaches the hospital, the receptionist will issue a clinic number
for him since the receptionist has access to the system to view the appointments
list and
status with nurses and doctors. The HMS system also allows the receptionist
to create patient accounts and book an appointment, referring to the doctors’
schedule, for unregistered patients.
Once patient’s turn came, the patient can explain his condition to the consulting
nurse, so that the nurse performs the pre-assessment examinations to diagnose
the problem and then redirect him to the concerned doctor/clinic. The HMS
system enables the nurse to allot patients for the concerned doctors, to view
doctors’ status and to update patients’ account.
Then, the concerned doctor will diagnose the patient, and then enter the
prescription needed for the patient. If the doctor sees that the patient needs any
further examinations like collecting and processing specimens, the system allows the

doctor to redirect the patient to the Nurse again. After the nurse collects
the specimens, the specimens will be sent to the laboratory so that the lab
assistant can
process, analyse the specimens, and then generate and enter the test results into
the system. Furthermore, the doctor can redirect the patient to the lab assistant if
there
is a need to perform examinations such as X-Ray images, CT scan, MRI. The lab
assistant can access the system and generate test reports regarding the
examinations or test performed.
On the other hand, the doctor keeps track of the examination results entered by the

lab assistant and then recommend further actions to be taken if required, as well
as enters a new prescription for the patient.
The system also allows the patient to access his account to see prescription
details and view his reports along with doctor advice. This feature is very useful
since test reports usually take a long time to be generated, so that the patient
may leave the hospital and view the results along with doctor’s advice through his
account without the need of going to the hospital again.
Once the prescription is ready, the pharmacist will prepare the medicines for the
patient and enters the dose and guidelines of each medicine into the system.
When the patient goes to the pharmacy of the hospital, he/she will find the
medicines
ready so that he/she can pick and go easily. The patient has two options to know
the dose and guidelines of each medicine, either by asking the pharmacist
directly or by
accessing his/her account to see it. This will help the patient be aware of
the medicines’ dose if he/she forgets it.
Finally, the patient will need to go to the cashier to pay for his/her visit. The system

allows the cashier to create and order invoice for payment through the
billing module. In addition, the cashier can watch the payment history of the
patients.

Requirements Gathering

• User requirements
The user requirements specify what the HMS system must be capable of doing to

solve the problems of the set of potential users of HMS. The system owners and
end- users write them with information from Quality Assurance. The user
requirements are identified using natural language, along with diagrams for a
broader understanding. The specifications listed in this section will be checked
and tested in
the Quality Qualification or User Acceptance Testing. User Requirements

Specifications are not meant to be a technical document because it

should be understandable by readers with basic knowledge of the system. [
CITATION

enc19 \l 1033 ]
The user requirements can be categorized into two major categories, which are:

• Functional requirements
Functional requirements define the function of the device, explaining
the actions taken by the HMS system clearly and quantitatively.
These
requirements define the capabilities of the HMS system, as well as its
process or workflow. It also determines the form of input and output
desired. Some of the functional requirements of the HMs system are:
• Registration
The admin is the only user who can register doctors, nurses, receptions,

lab assistants, cashiers and pharmacists. The patient can register

through the registration module. In addition, the system should
allow a receptionist to register new patients into the system.
• Authentication

The user (patients) should be able to create an account in the HMS

system through the registration module (form). The following details
should be
entered in the registration module: Full Name
oUsername (ID)
oE-
mail
oGe
nder
oPhone
Number
oDate of
Birth
oPassword
oConfirm Password
• Login
The system must enable registered users including all categories of users

to log in through the login module, by entering the username and

password.
• Manage Account
Users of the HMS system should have the ability to manage their account

including changing their password, email or phone number.

• Input validation
The system should validate all inputs entered by the user to ensure that

the user does not leave any blank required fields. This is also important
to ensure that the inputs are entered in the correct format and does not
exceed the size specifies.
• Unique Username (ID)

The username of each user in the HMS system should be unique. Equally
important, the system should verify that the username, which is entered
in the registration form, is not already used by another user in the system.
• Issuing clinic numbers

The receptions should have the ability to view nurses’ schedule to use
the system for issuing a clinic number for patients.
• Allot patients for doctors
The system shall enable nurses to view doctors’ status (Schedule) to allot
patients successfully for the concerned doctors in terms of their
problem.
• Appointment List
The receptionist shall be able to view the full appointment list.
• Booking an appointment

The system shall provide the available appointment to receptionist and

patients in order to book a new appointment.
• Updating Schedules

The system shall update the schedules of users automatically

whenever a new appointment is booked or a patient is redirected.
• Inform (Notify) Users

The system shall inform doctors, nurses, lab assistants, pharmacist

whenever an action has to be taken by them.
• Creating Prescription

The doctor shall user the system to create/enter a prescription for the
patient. On the other hand, the patient also should have access to
view the prescription through his/her account.

• Redirecting Patients

The system shall enable doctors to redirect the patient to nurses and lab
assistants.
• Generating Reports

The system shall enable lab assistants to generate test reports like X-Ray
images, CT scan, MRI reports.
• View Reports by patient

The patients shall use the system to view their test results reports as
well as doctors’ advice and prescription.
• View Reports by doctor

The system shall allow doctors to view the patients’ reports and enter
required advice for the patient, as well as new prescriptions if needed.
• Dose of Medicine

The system shall allow the pharmacist to enter the dose and guidelines
of each medicine for patients.
• Examination and Medicine Costs

The system shall allow lab assistants and pharmacist to enter the
costs of the examinations and medicines.
• Check Out (Payment)

The system shall allow the cashier to create and order invoice for
payment through the billing module. The cashier shall watch the
payment history of the patients.

Non-Functional Requirements

The non-functional requirement defines the operational requirements off the

system, as well as the constraints to be followed in order to improve the

system's functionality. The following are some of the non-functional
requirement that needs to be considered in the HMS system:
• Availability
The system must be available 24/7.
• Capacity
The system must support a load of 3000 users at a time.
• Performance

oResponse Time: The system must respond within 2 seconds

after verifying the details and other data of the patient. In
other words, the time to load a web page over a 56Kbps
modem connection should not exceed 2 seconds.
oUser Interface: User interface display shall response within 5
seconds.
oConformity: The system should be in accordance with Windows
Accessibility
Virus Protection: Devices in the hospital that use the system
must have firewalls enabled and an Active Anti-Virus in usage.
• Durability

In case of failure, the system should be recovered by itself within 10

seconds, and the server must receive a comprehensive crash report
stating the problem occurred.
• Adaptability

The system (web application) must be adaptive and responsive to

support devices of all types.
• Security

oModification: Changes in the system like (insert, erase, and

update) is coordinated and performed by the Admin only.
oUser Rights: users’ activity of the system should be controlled
so that each user can access the allowable activities only.
oData: the transaction data should be transmitted in an encrypted

form.

oDatabase Protection: the database should be protected by a

strong password.
• Safety and Maintainability

A backup of the database should be performed every week, so that the

system can be recovered in case of any database damage, which may be
occurred due to a catastrophic failure, such as a disk crash.
• Accessibility

The system can be accessed by the Admin and many other users but the
access level is controlled of each user as per their scope of work.

System Requirements
System requirements define the specifications required to use the system.
The following are some of the System requirements that need to be considered
for the
HMS system:

• The system needs to run seamlessly with at least 300 MB of

Internal Memory and 700MB of Random Access Memory (RAM)
• The system needs a minimum Internet speed of 500 kbps to
successfully refresh and load pages/modules.
• The system (webApp) needs internet connectivity to work to
access [CITATION Sha19 \l 1033 ]

Requirements Elicitation
The requirements elicitation is one of the most error-prone and difficult steps
in the phase of requirements gathering. The purpose of elicitation is to
understand and
explore the requirements of consumers. Elicitation is performed to evaluate the

collected requirements in details, before the analysis stage. There are various
techniques of requirements elicitation including brainstorming, interviews,
prototyping, observation, and many other techniques. [ CITATION AnA18 \l 1033 ]
However, the best two techniques that may suit the HMS system are:
• Observation

Observation allows the analysts to analyse and gather valuable

information, which is already available. This technique is essential as all
business analysts will report what they see in other forms such as
business procedure prototypes and diagramming along with the defined
use cases. [ CITATION Mor12 \l 1033 ]
• Interviews
Interviews allow working through the knowledge base of the system's
users so that developers can understand how users think. This technique
plays a big role in writing strong requirements. It also helps to gather a
large amount of data quickly. [ CITATION AnA18 \l 1033 ]
However, both of the techniques work well in gathering the requirements of the
HMS system, even though observation would be more effective for the HMS
system since
the system has various user categories. Observation enables the analyst to
provide his/her opinion of understanding the work so that ensuring that no
confusion exists. [ CITATION Mor12 \l 1033 ]

Requirement Validation
Requirements validation is mainly used to ensure that the defined
requirements match the desires of the users. It is involved with finding the issues
or problems
related to the requirements. Validation of Requirements is a very essential step as
issues related to requirements may lead to extreme modification when perceived
later in the development process. There are various techniques of requirements

validation including test case generation, requirements Reviews, prototyping,

walk- through and automated consistency analysis. The best two techniques that
may suit the HMS system are:
• Test Case Generation
This technique involves performing a number of test cases, in order to reveal

the issues related to the requirements. If the test case is difficult or

impossible to be designed, it is widely believed that the implementation
of
the system will be also difficult, so that the requirements must be
reconsidered.
• Requirements Reviews
This technique involves reading and reviewing the Software Requirements

Specification (SRS) document by a group of people including those who

interact with the customer and system developers, in order to analyse the SRS
document in details to check inconsistency, errors and ambiguity.

However, both of the techniques work well invalidating the requirements of the
HMS system, even though Requirements Reviews would be more effective for the
HMS system. Using Requirements Reviews will enable to initiate negotiations
with the
customer, in order to find a solution if a problem or error was found. [ CITATION
Oma16 \l 1033 ]

Diagrams
This section describes four types of diagrams, which used in the
requirements gathering stage.

Overall behaviour –

Data Flow Diagram (DFD)

The DFD diagram – Context Level is used to describe the overall behaviour of the

HMS system . The main symbols used in DFD diagrams:

User interaction - Use Case Diagram

The Use Case Diagram is used to simplify and analyse the requirements of the
HMS system . This type of diagram consists of four main components,
which are the boundary of the system, the actors, the use cases and the
relationships between the use cases and actors. The use cases help to determine
the expected
behaviour of the system but not the exact method to make it happen. The
key concept of a use case diagram is to design the system from the perspective of
the
end-use

Conclusion
In conclusion, this report discusses a case study of an online web-based Hospital
Management System (HMS). The aim, objectives, background and problem
statement of the project, followed by, the system description, its main actors and
modules are clearly stated. In addition, a suitable Software Development LifeCycle
(SDLC) was outlined properly, along with its advantages and disadvantages.
Furthermore, the user, system and domain requirements of the HMS system
including the requirements elicitation and validation techniques required
were determined. The UML and behavioural diagrams described the system and
illustrated
the relationship between objects, and the processes flow of the HMS system, which

helps to better understand the system. The discussed design of the interfaces
provides good user experience and offers accessibility features for users of the
system. Through the identified verification tools, the HMS system was ensured to
work as per the expectations. Followed by, the applicable types of testing web
applications/HMS system. In the end, the development costs, potential major risks
and how they can be addressed, quality assurance principles as well as standards are
to be followed through software management, were successfully determined in
order to make the HMS system market successfu