Hospital Management System

Supervisor

Dr. Umar Qasim

Submitted by

Areeba Shehbaz {2021_SE_11}

Department of Computer Science,

University of Engineering and Technology, Lahore, New-Campus.
[1-May-2023]
 Table of Content

Abstract: ............................................................................................ 3
Introduction: ..................................................................................... 3
System Analysis: ............................................................................... 5
Existing System: .................................................................................... 5
Proposed System: ................................................................................... 6
Scope: ................................................................................................. 7
Software Requirement Specification:............................................. 7
Requirement Specification: ............................................................. 7
Database Schema of Hospital Management System: ............................... 7
Physical Database Schema: ..................................................................... 8
Logical Database Schema........................................................................ 8
List of table: ....................................................................................... 8
System Design: ..............................................................................................8
Use Case:............................................................................................................8
ER Diagram: ......................................................................................................9
Normalization: ..............................................................................................9
Types of Normalization: ..................................................................................12
First Normal Form: ..........................................................................................12
Second Normal Form: ......................................................................................13
Third Normal Form: .......................................................................................15
BCNF: .............................................................................................................16
System Implementation:..........................................................................17
Sample Screenshots: ........................................................................................18
Conclusion ....................................................................................... 24
Abstract:
The purpose of the project “Hospital Management System” is to computerize the
front office Management of hospital to develop software which is user friendly
simple, fast and cost-effective. It deals with the collection of patient’s information
like add patient, update patient, delete patient, search patient, view patient diagnosis,
etc. Traditionally, it was done manually. The main function of the system is register
and store patient details and doctor details and retrieve these details as and when
required, and also to manipulate these details meaningfully. The Hospital
Management System can be entered using a username and password. It is accessible
by an admin. Only he can add data into the database. The data can be retrieved easily.
The data are well protected for personal use and make the data processing very fast.

Introduction:
HMS is designed to improve the quality and management of hospital in the areas of
clinical process analysis and activity-based costing. It enables you to develop your
organization and improve its effectiveness and quality of work. Managing the key
processes efficiently is critical to the success of hospital helps you manage your
processes.
HMS is powerful, flexible, and easy to use and is designed and developed to deliver
real conceivable benefits to hospitals. The project HMS includes registration of
patients, storing their details into the system by using database. The software has
the facility to give unique id for every patient and stores the details of every patient
and the staff manually. It also aims at providing low-cost reliable automation of the
existing systems. The system also provides excellent security of data at every level
of user-system interaction and also provides reliable storage facilities. Admin can
view availability of a doctor and details of a patient using the id, name.
 System Analysis
Existing system:
The current manual system has a lot of paper work. To maintain the records of sale
and service manually, is a time consuming task. With the increase in database, it will
become a massive task to maintain the database. Requires large quantities of file
cabinets, which are huge and require quite a bit of space in the office, which can be
used for storing records of previous details. The retrieval of records of previously
registered patients will be a tedious task. Lack of security for the records, anyone
disarrange the records of your system. If someone want to check details of the
available doctors the previous system does not provide any necessary detail of this
type.
All this work is done manually by the receptionist and other operational staff and lot
of papers are needed to be handled and taken care of. Doctors have to remember
various medicines available for diagnosis and sometimes miss better alternatives as
they can’t remember them at that time.
Advantages:
 No extra training required
 Easy to implement
 Can be stored anywhere
 Requires minimum effort.
Disadvantages:
 Needs lots of paper.
 Problem with maintenance.
 Volumes of data becomes problem.
 Once data is burned it cannot be reproduced easily.
 Data handling is problem.
Proposed system:
The HMS is designed for any hospital to replace their existing manual paper-based
system. The new system is to control the information of patients as well as doctors,
these services are to be provided in an efficient, cost-effective manner, with the goal
of reducing the time and resources currently required for such tasks.
The complete set of rules and procedure related to hospital’s day to day activities
and generating reports is called “HMS”. It is computerized management system, this
system also keeps records of hardware assets besides software of this organization.
The proposed system will keep track of doctors, patients, rooms. This project is GUI
based software that will help in storing, updating and retrieving the information
through various user-friendly menu-driven modules.
Goals for Proposed system:
I. The system should be easy to operate.
II. The working in the organization will be well planned and organized.
III. The level of accuracy in the proposed system will be higher.
IV. The reliability of the proposed system will be high due to proper storage of
information.
V. Provide quick and efficient retrieval of information.
Advantages:
 Low maintenance cost.
 Volume of data is not an issue.
 Data can be converted easily to information.
 Data cannot be corrupted easily with proper backup.
 It can be expanded as well as data communication is possible.
Disadvantages:
 High starting cost requires.
 Additional manpower is necessary.
 Data communication system will have an additional cost.

Scope:
The proposed software product is the Hospital Management system (HMS). The
system will be used in any hospital, clinic to get the information from the patients
and then storing that data for future usages. The current system in use is a paper
based system. It is too slow and cannot provide updated lists of patients within
reasonable timeframe. The intention of the system is to reduce over-time pay and
increase the number of patients that can be treated accurately.

Software Requirement Specification:

Software requirements deals with defining software resources requirements and pre-
requisites that need to be installed on a computer to provide optimal functioning of
an application. These requirements or pre-requisites are generally not included in the
software installation package and need to be installed separately before the software
is installed.
Software requirements for present project
Operating system : Window 10
Front-end : C Sharp
Back-end : MySQL
Development environment/tools : Visual studio

Requirement Specification:
The entire project consists of one module and all the functionality is performed by
this module, which is
Admin:
1. Admin Activity
2. Patient Management
 Add Patient
 Delete Patient
 Search Patient
 Update Patient
 View Patient

3. Doctor Management
 Add Doctor
 Delete Doctor
 Search Doctor
  Update Doctor
 View Doctor
4. Nurse Management
 Add Nurse
 Delete Nurse
 Search Nurse
 Update Nurse
 View Nurse

5. Employee Management
 Add Employee
 Delete Employee
 Search Employee
 Update Employee
 View Employee
6. Rooms Management
 Add Rooms
 Delete rooms
 Update rooms
 Search rooms
 View rooms
7. Bill Management
 Add bill
 View bill
 Delete bill
 Search bill
 Update bill

Database Schema of Hospital Management System:

A database schema is the skeleton structure that represents the logical view of the
entire database. It defines how the data is organized and how the relations among
them are associated. It formulates all the constraints that are to be applied on the
data. A database schema can be divided broadly into two categories:
Physical Database Schema: This schema pertains to the actual storage of data and
its form of storage like files, indices, etc. It defines how the data will be stored in a
secondary storage.
Logical Database Schema: This schema defines all the logical constraints that need
to be applied on the data stored. It defines tables, views, and integrity constraints.

List of table:
 Doctors
 Patients
 Inpatients
 Outpatients
 Employees
 Nurse
 Labs
 Rooms
 Bill

System Design
Use case Diagram:
ER Diagram:
 Normalization
The process of structuring and handling the relationship between data to minimize
redundancy in the relational table and avoid the unnecessary anomalies properties
from the database like insertion, update and delete. It helps to divide large database
tables into smaller tables and make a relationship between them. It can remove the
redundant data and ease to add, manipulate or delete table fields. A normalization
defines rules for the relational table as to whether it satisfies the normal form.
A normal form is a process that evaluates each relation against defined criteria and
removes the multivalued, joins, functional and trivial dependency from a relation. If
any data is updated, deleted or inserted, it does not cause any problem for database
tables and help to improve the relational table' integrity and efficiency.
Objective of Normalization
 It is used to remove the duplicate data and database anomalies from the
relational table.
 Normalization helps to reduce redundancy and complexity by examining new
data types used in the table.
 It is helpful to divide the large database table into smaller tables and link them
using relationship.
 It avoids duplicate data or no repeating groups into a table.
 It reduces the chances for anomalies to occur in a database.

Actual Tables:
Doctors: create table Doctors(ID int Primary key, name varchar(50),departmentvarchar(30),)
Employees: create table Employee(ID int Primary key, name varchar(50),department
varchar(30),)

Patients: create table Patients(ID int primary key , name varchar(50),phone_no int,gender
varchar(7),disease varchar(25), bloodgroup varchar(3), DoctorId int references Doctors on
delete set null, age int,bill_no int )

InPatients: create table Inpatients(patient_ID int, Room_no int references Rooms on delete set
null,lab_no int references Labs on delete set null,date_of_admit date,date_of_discharge
date,advance int,Doctors_ID int references Doctors on delete set null ,bill_no int references Bill
on delete set null,room_allocatedby int references Employee on delete set null)

OutPatients: create table Outpatients(Patient_id int, date_no date,

lab_no int references Labs on delete set null ,Doctors_ID int references Doctors on delete set null
,bill_no int references Bill on delete set null ,)

Labs: create table Labs(lab_no int primary key,Doctors_ID int references Doctors on delete set
null, test_Date date, PatientID int references Patients on delete set null,)

Rooms: create table Rooms(Room_no int primary key, Room_type nvarchar(20),room_status

varchar(15),)

Bill: create table Bill(bill_no int primary key,PatientId int references Patients on delete set
null,patient_type varchar(20),medicine_charges int,doctor_charges int,
Nursing_charges int,lab_charges int,total_Bill INT)

Nurses: create table Nurses(NurseId int primary key,Nurse_Name varchar(10),

Position varchar(10),INDuty_time datetime, Outduty_time datetime)

Types of Normalization
1. First Normal Form (1NF)
2. Second Normal Form (2NF)
3. Third Normal Form (3NF)
4. Boyce and Codd Normal Form (BCNF)

First Normal Form (1NF):

The table will be in First Normal Form (1NF) if all the attributes of the table
contain only atomic values. We can also say that if a table holds the multivalued
data items in attributes or composite values, the relation cannot be in the first
normal form. So, we need to make it first normal form by making the entries of the
table atomic.

To Achieve 1NF:

Doctors:
To achieve 1NF the "department" column could be normalized into a separate
"Departments" table, with a primary key "DepartmentID" and a "DepartmentName"
column. Then, the "Doctors" table can reference the "Departments" table using the
foreign key "DepartmentID" instead of the "department" column.
Employees:
Same as with the "Doctors" table, the "department" column could be normalized into
a separate "Departments" table, with a primary key "DepartmentID" and a
"DepartmentName" column. Then, the "Employees" table can reference the
"Departments" table using the foreign key "DepartmentID" instead of the
"department" column.
Patients:
The "disease" column could be normalized into a separate "Diseases" table, with a
primary key "DiseaseID" and a "DiseaseName" column. Then, the "Patients" table
can reference the "Diseases" table using the foreign key "DiseaseID" instead of the
"disease" column.
The "bloodgroup" column could be split into a separate "BloodGroups" table, with
a primary key "BloodGroupID" and a "BloodGroupName" column. Then, the
"Patients" table can reference the "BloodGroups" table using the foreign key
"BloodGroupID" instead of the "bloodgroup" column.
InPatients:
The "Doctors_ID" column and "room_allocatedby" column could be normalized
into separate "Doctors" and "Employees" tables, respectively, with their
corresponding primary keys and foreign keys in the "InPatients" table.
OutPatients:
Same as with the "InPatients" table, the "Doctors_ID" column could be normalized
into a separate "Doctors" table, with a primary key and foreign key in the
"OutPatients" table.
Labs:
The "Doctors_ID" column and "PatientID" column could be normalized into
separate "Doctors" and "Patients" tables, respectively, with their corresponding
primary keys and foreign keys in the "Labs" table.
Rooms , Bill and Nurse tables appear to meet the first normal form.

Second Normal Form (2NF):

A Relation will be in 2NF if it follows the following condition:

1. The table or relation should be in 1NF or First Normal Form.

2. All the non-prime attributes should be fully functionally dependent on the
candidate key.
3. The table should not contain any partial dependency.

To Achieve 2NF:
As all the tables are already in 1NF since all columns have atomic values and each
row has a unique identifier. So to meet second and third point of 2NF some
changing to have made are:
Doctors: To move it to 2NF, we need to ensure that all non-key attributes are
dependent on the entire primary key, which in this case is the "Doctor_ID" column.
The only non-key attribute is the "Department" column, which is functionally
dependent on the primary key. Thus, the "Doctors" table is already in 2NF.
Employees: To move it to 2NF, we need to ensure that all non-key attributes are
dependent on the entire primary key, which is the "Employee_ID" column. The
only non-key attribute is the "department" column, which is functionally dependent
on the primary key. Thus, the "Employees" table is already in 2NF.
Patients: To move it to 2NF, we need to ensure that all non-key attributes are
dependent on the entire primary key, which in this case is the "Patient_ID" column.
The non-key attributes are "patient_name", "age", "gender", "address", "phone",
"disease", and "bloodgroup". The "disease" and "bloodgroup" attributes are
functionally dependent on the primary key. However, the other attributes
("patient_name", "age", "gender", "address", and "phone") are only dependent on a
part of the primary key. To fix this, we can create a new table "Patient_Details"
with columns "Patient_ID" (primary key), "patient_name", "age", "gender",
"address", and "phone". Then, we can remove these columns from the "Patients"
table, leaving only "Patient_ID", "disease", and "bloodgroup".
InPatients: To move it to 2NF, we need to ensure that all non-key attributes are
dependent on the entire primary key, which in this case is the combination of
"Patient_ID" and "Admission_ID". The non-key attributes are "Admission_Date",
"Room_Number", "Doctors_ID", and "room_allocatedby". The "Admission_Date",
"Room_Number", and "room_allocatedby" attributes are functionally dependent on
the entire primary key. However, the "Doctors_ID" attribute is only dependent on a
part of the primary key ("Patient_ID"). To fix this, we can create a new table
"Admissions" with columns "Patient_ID" (primary key), "Admission_ID" (primary
key), "Admission_Date", "Room_Number", and "room_allocatedby". Then, we
can remove these columns from the "InPatients" table, leaving only "Patient_ID"
and "Admission_ID" (primary key) and "Doctors_ID". This way, the "InPatients"
table is now in 2NF.
OutPatients: : To move it to 2NF, we need to ensure that all non-key attributes are
dependent on the entire primary key, which in this case is the combination of
"Patient_ID" and "Doctors_ID" .So the table is in 2NF.
Rooms: The "department" column in the "Rooms" table could be creating a partial
dependency because the room number alone may not be sufficient to uniquely
identify a room. Instead, we could create a separate "Departments" table (as
described earlier), with a primary key "DepartmentID" and a "DepartmentName"
column. Then, the "Rooms" table can reference the "Departments" table using the
foreign key "DepartmentID" instead of the "department" column.
Bill: The "PatientID" column in the "Bill" table could be creating a partial
dependency because a patient may have multiple bills associated with them. We
could split the "Bill" table into two separate tables: "Patients" and "Bills". The
"Patients" table would have a primary key "PatientID" and other patient
information (such as name and contact details). The "Bills" table would have a
primary key "BillID", a foreign key "PatientID" referencing the "Patients" table,
and other bill information (such as total amount and payment status).
Nurse: This table is already in 2NF because all non _key attributes depend on
primary key.

Third Normal Form (3NF):

The table will be in Third Normal Form (3NF) if it follows the given conditions:

1. The table or relation should be in 2NF.

2. It should not contain any transitive dependency. A Transitive Dependency is
that any non-prime attribute determines or depends on the other non-prime
attribute.

To Achieve 3NF:

Doctors, Employees, Nurse , Patients, Outpatients, Bill, Room Tables are already
in 3NF.
InPatients: To move the "InPatients" table to 3NF, we can create a new table
"Admissions" with columns "Patient_ID" (primary key), "Admission_ID" (primary
key), "Room_Number", "date_of_admit", "date_of_discharge", "advance",
"Doctors_ID". Then, we can remove "Patient_ID", "Room_no", "date_of_admit",
"date_of_discharge", "advance", and "Doctors_ID" from the "InPatients" table,
leaving only "Admission_ID" (primary key), "lab_no", "bill_no", and
"room_allocatedby". This way, all non-key attributes are dependent on the entire
primary key.
Labs: To move the "Labs" table to 3NF, we can create a new table "LabTests"
with columns "test_ID" (primary key), "lab_no", "test_Date", "PatientID", and
"Doctors_ID". Then, we can remove "Doctors_ID" from the "Labs" table, leaving
only "lab_no" (primary key) and "test_Date". We can also remove "PatientID"
from the "Labs" table and add it as a foreign key to the "LabTests" table.

BCNF:
It stands for Boyce Codd Normal form, which is the next version of 3NF.
Sometimes, it is also pronounced as 3.5 NF. A normal form is said to be in BCNF if
it follows the given conditions:

 A table or relation must be in 3NF.

 If a relation R has functional dependencies (FD) and if A determines B, where
A is a super Key, the relation is in BCNF.

To Achieve BCNF:

Patients: There are two candidate keys in this table - ID and bill_no. However, the
DoctorId column is not a candidate key, but it is functionally dependent on the ID
column in the Doctors table. To bring the Patients table to BCNF, the DoctorId
column should be removed from the table, and a separate table linking doctors to
patients should be created.
InPatients: The InPatients table has a composite primary key consisting of
patient_ID and date_of_admit attributes, and it has two foreign keys, Doctors_ID
and bill_no. It violates BCNF because it has a transitive dependency between
Doctors_ID and bill_no attributes through patient_ID and date_of_admit. If we
decompose this table into two tables, one with patient_ID, date_of_admit, room_no,
lab_no, and advance, and the other with patient_ID, date_of_admit, Doctors_ID, and
bill_no, then we can eliminate this transitive dependency.
OutPatients : The OutPatients table has a direct foreign key reference to the Doctors
table, and it violates BCNF because it has a partial dependency on the composite
primary key of Patients table (Patient_id). If we decompose this table into two tables,
one with Patient_id, date_no, lab_no, and bill_no, and the other with Patient_id and
Doctors_ID, we can eliminate this partial dependency.
Bill: The Bill table has a partial dependency on the composite primary key of
Patients table (PatientId) because it has attributes (patient_type, medicine_charges,
doctor_charges, nursing_charges, lab_charges, total_Bill) that depend only on
PatientId and not on the entire primary key (ID). If we decompose this table into two
tables, one with PatientId and patient_type, and the other with PatientId, bill_no,
medicine_charges, doctor_charges, nursing_charges, lab_charges, and total_Bill,
then we can eliminate this partial dependency.

Other tables are already in BCNF.

System Implementation

Introduction:
Implementation is the stage of project when the theoretical design is turned into a
working system. Thus, it can be considered to be the most critical stage in achieving
a successful new system new system and in giving the user, confidence that the new
system will work and be effective. The implementation stage involves careful
planning, investigation of the existing system and its constraints on implementation,
designing of methods to achieve changeover and evaluation of changeover methods.
 Sample Screenshots
Main Screen:

Admin Portal:
Patients Data:

Delete Patients:

Inpatients Data:
Outpatients Data:

Employees Data:
Doctors Data:

Nurse Data:
Labs Data:

Rooms Data:
Bill Data:
Conclusion
Since we are entering details of patients electronically in the “HMS”, data will be
secured. Using this application, we can retrieve patient’s history with a single click.
Thus, processing information will be faster. It guarantees accurate maintenance of
patient details. It easily reduces the book keeping task and thus reduces the human
effort and increases accuracy speed.
HMS is essential for maintaining details about the doctor, patient, hospital staff etc.
we understand that by using Hospital Management System project the work became
very easy and save lot of time. Hospital administrators would be able to significantly
improve the operation control and thus streamline operations. This would enable to
improve the response time to the demands of patient care because it automates the
process of collecting, and retrieving patient information. Accounting sometimes
becomes awfully pathetic and complex. This product will eliminate any such
complexity.