Hospital Management Sysem Proposal Cosc - 2012 - Special

DESIGN AND IMPLEMENT WEB BASED HOSPITAL
MANAGEMENT SYSTEM
BY:
DEME TEMESGEN
MINTESENOT
SAMUEL MISIKIR
SOLOMON YOHANNIS
AKLILU YOSEF
ASHAGIRE
UNITY UNIVERSITY, ADAMA CAMPUS

UNDER GRADUATE STUDIES
DEPARTMENT OF COMPUTER SCIENCE
October, 2023
Adama, Ethiopia
MANAGEMENT SYSTEM
BY:
DEME TEMESGEN
MINTESENOT
SAMUEL MISIKIR
SOLOMON YOHANNIS
AKLILU YOSEF
ASHAGIRE
A FINAL PROJECT SUBMITTED TO DEPARTMENT OF

COMPUTER SCIENCE OF UNITY UNIVERSITY, ADAMA CAMPUS
IN PARTIAL FULFILLMENT OF THE REQUIREMENT OF THE

AWARD OF BACHELOR OF SCIENCE DEGREE IN
COMPUTER SCIENCE
October, 2023
Adama, Ethiopia
MANAGEMENT SYSTEM
BY:
DEME TEMESGEN
MINTESENOT
SAMUEL MISIKIR
SOLOMON YOHANNIS
AKLILU YOSEF
ASHAGIRE
UNITY UNIVERSITY ADAMA CAMPUS

DEPARTMENT OF COMPUTER SCIENCE
Approved By Board of Examiners:
1.
Chairman, Dept. Graduate Committee Signature Date
2.
Advisor Signature Date
3.
Internal Examiner Signature Date
October, 2023
Adama, Ethiopia
DECLARATION
We certify that the project entitled “ DESIGN AND IMPLEMENT COMPUTER BASED HOSPITAL MANAGEMENT
SYSTEM” in partial fulfillment of the requirements for the award of BACHELOR OF SCIENCE DEGREE IN
COMPUTER SCIENCE is the result of our group work under the supervision of Mr. Nigussie Teferi
Lake, Lecturer Unity University Adama Campus, Department of Computer Science. The work
has not been presented elsewhere for assessment where material has been used from other
sources it has been properly referred.
Name of Candidate Groups Signature Date
1. Deme Temesgen
2. Mintesenot Samuel
3. Misikir Solomon
4. Yohannis Aklilu
5. Yosef Ashagire
I hereby declare that I have read this project and in my opinion this project is sufficient in terms
of scope and quality. This project has been submitted for examination with my approval.
Advisor Name Signature Date
ACKNOWLEDGEMENT
Above all, we would like to thank the Omniscient, Omnipotent, and Almighty God. He gave us
courage, strength, and impatience to finish this project. Next to God, our special gratitude goes to
our advisor, Nigussie Teferi (MSc), for his invaluable support and smooth communication
throughout the preparation of this project. We are also indebted to our honorable families for
their moral and financial support. Finally, we would like to thank the entire staff who
participated in this project and our friends for their suggestions.
I
List of Tables
Table 1 Project Cost Estimate Management....................................................................................7

Table 2: Players of the existing system.........................................................................................11
Table 3: Register patient use case documentation.........................................................................14
Table 4: Prescribe medicine use case documentation....................................................................14
Table 5 : Buy medicine use case documentation...........................................................................15
Table 6: Generate report use case documentation.........................................................................15
Table 7: Sell medicine use case documentation............................................................................16
Table 8: Functional Requirement..................................................................................................20
Table 9 : Non-Functional Requirements........................................................................................21
Table 10: Hardware Requirements................................................................................................21
Table 11: Software Requirements..................................................................................................22
Table 12: Business Rule 1 (User Login)........................................................................................22
Table 13: Business Rule 2 (Book Appointment)...........................................................................22
Table 14: Business Rule 3 (Inpatient Admission).........................................................................22
Table 15: Business Rule 4(Patient Discharge)..............................................................................22
Table 16: Actors of the proposed system.......................................................................................23
Table 17: Identification of Use Case.............................................................................................24
Table 18: Login Use Case Documentation....................................................................................32
Table 19: Book Appointment Use Case Documentation...............................................................33
Table 20: Manage Patient’s detail Use Case Documentation........................................................34
Table 21: Manage Staff Details Use case Documentation............................................................35
Table 22: View Medicine prescription Use case Documentation..................................................35
Table 23: Subsystem Description..................................................................................................53
Table 24: admin_user table............................................................................................................61
Table 25: attendance table.............................................................................................................61
Table 26: attendance_tran table.....................................................................................................62
Table 27: balance_master table......................................................................................................62
Table 28: canteen_menu table.......................................................................................................62
Table 29: demolition_item table....................................................................................................62
Table 30: distribution_of_item table..............................................................................................63
Table 31: doctor table....................................................................................................................63
Table 32: doctor_indoor table........................................................................................................63
Table 33: doctor_outdoor table......................................................................................................64
Table 34: doctor_appointment_list table.......................................................................................64
Table 35: electricity_bill table.......................................................................................................64
Table 36: employee_master table..................................................................................................65
Table 37: illness_sugestion table...................................................................................................65
II
Table 38: illness_complaint table..................................................................................................66
Table 39: treatment table...............................................................................................................66
Table 40: incomeexpense table......................................................................................................67
Table 41: invoice table...................................................................................................................67
Table 42: item table.......................................................................................................................67
Table 43: issue_stock table............................................................................................................68
Table 44: item_master table...........................................................................................................68
Table 45: lab_master table.............................................................................................................68
Table 46: lab_test_data table.........................................................................................................69
Table 47: leave_from table............................................................................................................69
Table 48: leave_master table.........................................................................................................69
Table 49: maintenance_of_item table............................................................................................70
Table 50: medicine table................................................................................................................70
Table 51: medicine_expiry_report table........................................................................................70
Table 52: operative_schedule table................................................................................................71
Table 53: patient_allergy table......................................................................................................71
Table 54: patient table....................................................................................................................72
Table 55: patient_canteen_bill table..............................................................................................72
Table 56: patient_bill table............................................................................................................73
Table 57: patient_history table......................................................................................................73
Table 58: patient_canteen_order table...........................................................................................74
Table 59: patient_illness_pasthistory table....................................................................................74
Table 60: payment table.................................................................................................................75
Table 61: purchase_order table......................................................................................................75
Table 62: room_master table.........................................................................................................76
Table 63: supplier_master table.....................................................................................................76
Table 64: treatment_doctor_note table..........................................................................................76
Table 65: treatment_clinical_handover table.................................................................................77
Table 66: treatment_investigation table.........................................................................................78
Table 67: treatment_outpatient table.............................................................................................79
Table 68: treatment_patient_dailytreatment table.........................................................................79
Table 69: treatment_patient_dailymedication table.......................................................................80
Table 70: treatment_patient_assesment.........................................................................................80
Table 71: treatment_surgery tableadd............................................................................................82
Table 72: patient_allergy table......................................................................................................82
Table 73: patient_addiction table...................................................................................................83
Table 74: patient_admission table.................................................................................................83
III
List of Figures
Figure 1: Project Time Schedule Management...............................................................................8
Figure 2: Essential Use Case Diagram for Hospital Management System...................................13
Figure 3: CRC Model for Existing Hospital Management System...............................................17
Figure 4: Essential UI for Medicine Prescription..........................................................................18
Figure 5: Essential UI for X-ray Examination Request Form.......................................................19
Figure 6: General Use Case Diagram............................................................................................25
Figure 7: Patient Management Use Case.......................................................................................26
Figure 8: Staff Management Use Case..........................................................................................27
Figure 9: Doctor Management Use Case.......................................................................................28
Figure 10: Room Management Use Case......................................................................................29
Figure 11: Laboratory Management Use Case..............................................................................30
Figure 12: Supplier’s Management Use Case...............................................................................31
Figure 13: Conceptual Class Diagram...........................................................................................36
Figure 14: Sequence Diagram for Patient Registration Use Case.................................................37
Figure 15: Sequence Diagram for Update Doctor Use Case.........................................................38
Figure 16: Sequence Diagram for Register Doctor Use Case.......................................................39
Figure 17: Sequence Diagram for Update Patient Details Use Case.............................................40
Figure 18: Sequence Diagram for Book Appointment Use Case..................................................41
Figure 19: Sequence Diagram for Insert Invoice Details Use case...............................................42
Figure 20: Sequence Diagram for Report Management................................................................43
Figure 21: Activity Diagram for login Use Case...........................................................................44
Figure 22: Activity Diagram for Add Doctor Use Case...............................................................45
Figure 23: Activity Diagram for Manage Appointment Use Case................................................46
Figure 24: Activity Diagram for update Patient Detail Use Case..................................................47
Figure 25: Activity Diagram for update Canteen Food Price Use Case........................................48
Figure 26: System Architecture Design Diagram..........................................................................50
Figure 27: HMS System Decomposition.......................................................................................52
Figure 28: Hardware/ Software mapping for the proposed HMS..................................................54
Figure 29: Object Oriented class Diagram....................................................................................56
Figure 30: Component diagram.....................................................................................................57
Figure 31: Deployment Diagram...................................................................................................58
Figure 32: Entity Relation Diagram..............................................................................................60
Figure 33: login page Screen UI....................................................................................................84
Figure 34: Patient Registration Screen UI.....................................................................................85
Figure 35: Doctor Registration Screen UI.....................................................................................86
Figure 36: Services Screen UI.......................................................................................................87
Figure 37: Cleaning Service Screen UI.........................................................................................88
Figure 38: Staff Management Screen UI.......................................................................................89
Figure 39: Register Employee Screen UI......................................................................................90
IV
Figure 40: Daily Attendance Screen UI.........................................................................................91
Figure 41: Departments Screen UI................................................................................................92
Figure 42: Reports Management Screen UI..................................................................................93
Figure 43: Medicine Report Screen UI..........................................................................................94
V
Table of Contents
ACKNOWLEDGEMENT................................................................................................................I
List of Tables..................................................................................................................................II
List of Figures................................................................................................................................IV
Acronyms......................................................................................................................................IX
Abstract...........................................................................................................................................X
CHAPTER ONE: INTRODUCTION..............................................................................................1
1.1. Background of the Project.................................................................................................1
1.2. Statement of the problem..................................................................................................2
1.3. Purpose of the Project.......................................................................................................3
1.4. Objectives of the Project...................................................................................................3
1.4.1. General Objectives.....................................................................................................3
1.4.2. Specific Objective......................................................................................................3
1.5. Scope of the project...........................................................................................................4
1.6. Limitation of the Project...................................................................................................4
1.7. Feasibility Study...............................................................................................................4
1.7.1. Economic Feasibility.................................................................................................4
1.7.2. Technical Feasibility..................................................................................................5
1.7.3. Operational Feasibility...............................................................................................5
1.8. Significance of the Project................................................................................................5
1.9. Methodology.....................................................................................................................6
1.9.1. Fact Finding Methodology........................................................................................6
1.9.2. System Development Process Model........................................................................6
1.9.3. System Design and Development Tools....................................................................6
1.10. Testing Plan...................................................................................................................6
1.10.1. Unit Testing............................................................................................................6
1.10.2. Integration Testing.................................................................................................7
1.11. Project Management......................................................................................................7
1.11.1. Cost Management..................................................................................................7
1.11.2. Project Schedule.....................................................................................................8
CHAPTER TWO: ANALYSIS OF EXISTING SYSTEM.............................................................9
VI
2.1. Overview of Existing System...........................................................................................9
2.2. Function of Existing System.............................................................................................9
2.3. Problems of the Existing System....................................................................................10
2.4. Players of Existing System.............................................................................................11
2.5. Supplementary Specification..........................................................................................11
2.5.1. Business Rule...........................................................................................................11
2.6. Modeling the Existing System........................................................................................12
2.6.1. Use Cases.................................................................................................................12
2.6.2. Essential Use Case Modeling..................................................................................13
2.6.3. Essential Use Case Documentation.........................................................................14
2.6.4. CRC Model..............................................................................................................17
2.6.5. Essential User Interface (UI) Flow Diagram...........................................................18
CHAPTER THREE: ANALYSIS OF PROPOSED SYSTEM.....................................................20
3.1. Overview of Proposed System........................................................................................20
3.2. Requirement Determination............................................................................................20
3.2.1. Functional Requirement...........................................................................................20
3.2.2. Non-Functional Requirements.................................................................................21
3.2.3. System Requirements..............................................................................................21
3.3. Supplementary Specification..........................................................................................22
3.3.1. Business Rule...........................................................................................................22
3.3.2. Constraints...............................................................................................................23
3.4. Modeling Proposed System............................................................................................23
3.4.1 System Use case Model................................................................................................23
3.4.2. Conceptual Class Diagram......................................................................................36
3.4.3. Sequence Diagram...................................................................................................37
3.4.4. Activity Diagram.....................................................................................................44
CHAPTER FOUR: SYSTEM DESIGN........................................................................................49
4.1. Overview of System Design...........................................................................................49
4.2. Design Goals...................................................................................................................49
4.3. Architecture of System Design.......................................................................................50
4.3.1. System Architecture.................................................................................................50
VI
4.3.2. System Process........................................................................................................51
4.3.3. System Decomposition............................................................................................52
4.3.3.1. Subsystem Decomposition...................................................................................52
4.3.4. Hardware/Software Mapping...................................................................................54
4.4. Object Oriented Class Diagram......................................................................................55
4.5. Component Diagram.......................................................................................................57
4.6. Deployment Diagram......................................................................................................58
4.7. Database Design..............................................................................................................59
4.7.1. Conceptual Database Design...................................................................................59
4.7.2. Physical Database Design........................................................................................61
4.8. User Interface Design......................................................................................................84
4.9. Access Control................................................................................................................95
CHAPTER FIVE: IMPLIMENTATION AND TESTING...........................................................96
5.1. Introduction.....................................................................................................................96
5.2. Coding.............................................................................................................................96
5.3. Software Testing and Procedures....................................................................................97
5.3.1. Software Testing......................................................................................................97
5.3.2. Testing Procedures...................................................................................................97
CHAPTER SIX: CONCLUSION AND RECOMMENDATIONS..............................................99
6.1. Summary and Conclusion...................................................................................................99
6.2. Recommendation..............................................................................................................101
I. REFERENCES....................................................................................................................102
II. APPENDIX..........................................................................................................................103
APPENDIX A: Sample code for database connection........................................................103
APPENDIX B: Sample script code for Surgery Consent....................................................104
APPENDIX C: Sample script code for Add Surgery Consent............................................107
VI
Acronyms
CPU Central Processing Unit
CRC Class Responsibility Collaborator
CSS Cascading style sheet
EMR Electronic Medical Record
ETB Ethiopian birr
GB Giga Byte
HMS Hospital Management System
HTML Hyper text markup language
MYSQL Structured Query Language
NO. Number
PHP Hypertext Pre-processor
Qty Quantity
TB Terabyte
UML Unified Modeling Language
UI User Interface
XAMPP Cross-platform, Apache, MYSQL, PHP and Perl
IX
Abstract
An organized computerized system called a "hospital management system" was designed and
developed to handle day-to-day operations and management of hospital activities. In many
hospitals, the Existing System has many problems such as lack of immediate retrievals, lack of
immediate information storage, lack of prompt updating, managing record, generating reports is
difficult and takes a lot of time and is highly error-prone as it is manual. The major goal of this
project is to computerize paper-based task and to develop a user-friendly, quick, and affordable
hospital management system. Information about the patient, doctors, and other staff’s, and more
are performed through the system. The system's primary purpose is to register, store, and
retrieve, patient, doctor and other staff’s information as needed, as well as to change this
information in a useful way. The methodology used to model and develop this system is Iterative
and Incremental Model, which allows room for scalability as time goes on and this model helps
to start development with a simple implementation of a small set of the software requirements
and iteratively enhances the evolving versions until the complete system is implemented. This
Project benefits doctors, patients, finance departments, HR departments and many other hospital
authorities improving the day to day activities.
X
CHAPTER ONE: INTRODUCTION
1.1. Background of the Project

Hospital management system is a computer system that helps manage the information related to
health care and aids in the job completion of health care providers effectively. This Hospital
Management System project is a computerized hospital front desk management that produces
[1]
user-friendly, quick, and cost-effective software . It handles and secures patient information,
diagnosis data, and so on. It used to manage the data related to all departments of healthcare such
as, clinical, financial, laboratory, inpatient, outpatient, nursing, pharmaceutical etc. HMS was
introduced to solve the complications coming from managing all the paper works of every
[2]
patient associated with the various departments of hospitalization with confidentiality . HMS
provides the ability to manage all the paperwork in one place, reducing the work of staff in
arranging and analyzing the paperwork of the patients. HMS does many works like maintain the
medical records of the patient, maintain contact detail of patient, keep track of appointment
dates, medicine prescription and soon. HMS has many advantages. Some of these advantages are
it is time-saving Technology, Improved Efficiency by avoiding human errors, Reduces scope for
Error, Data security and correct data retrieval made possible, Cost effective and easily
manageable, Easy access to patient data with correct patient history, improved patient care made
possible, Easy monitoring of supplies in inventory, Reduces the work of documentation,
Electronic Medical Record (EMR) and so on. HMS have feature such as Appointment
Management, Billing Management, Prescription Management, Discharge Summary, Pharmacy
Management, Lab Management etc.
Our project, named "Hospital Management System," is powerful, flexible, and easy to use and is
designed and developed to deliver real, conceivable benefits to hospitals. The main purpose of
this project is to address the issues faced by hospitals and to develop a web-based hospital
management system that will replace an old paper-based management system. This project has
many modules like patient management, doctor/physician management, medicine and
prescription management, online appointment management, laboratory management, nurse
management, etc.
1
Our project Hospital Management System (HMS) includes registration of patients, storing their
details into the system, making appointments, having doctors assign nurses for treatments,
prescribing a laboratory for detail tests, viewing treatment details, prescribing medicine to
patients without writing on paper, and also having patients download their details and
prescription. The software has the facility to create a unique ID for every patient and member of
staff and stores the details of every patient and member of staff automatically. It includes a
search facility to determine the current status of each room. The user can search for the
availability of a doctor and the details of a patient using the ID or username.
1.2. Statement of the problem

[3]
Health care is one of the most essential and in-demand services for everyone . It requires a lot
of attention and high-quality service, which also causes health care workers to put in a lot of
effort. These issues also add to the situations where there’s a need for physical attendant for
every patient when it could be automated and handled with technology. Since HMS is associated
with the lives of people and their day-to-day routines, we decided to work on this project. In this
digital world, we don’t have the time to wait in infamously long hospital queues. The problem is
that queuing at hospitals is often managed manually by administrative staff. You take a token
there and then wait for your turn, then ask for the doctor, and the most frustrating thing is that
you traveled a long distance to get there, and then you find out the doctor is on leave or can’t
take appointments. HMS will help us overcome all these problems because now patients can
book their appointments at home and check whether the doctor they want to meet is available or
not. Doctors can also confirm or decline appointments; this helps both the patient and the doctor
because, as the doctor declines an appointment, the patient will know this in advance and will
only visit the hospital when the doctor confirms the appointment, saving both time and money.
HMS is essential for all healthcare establishments, be in hospitals, nursing homes, health clinics,
rehabilitation centers, dispensaries, or clinics. The main goal of this project is to computerize
details regarding to the hospital. The installation of this healthcare software results in
improvements in administrative functions and, hence, better patient care, which is the prime
focus of any healthcare unit [4].
2
1.3. Purpose of the Project
The purpose of this project is to develop a computerized hospital management system that
replaces the current paper-based hospital management system. By employing this software,
hospitals will be able to register patients more efficiently and manage appointments, patient
records, medical prescriptions, laboratory results, as well as other tasks.
1.4. Objectives of the Project
1.4.1. General Objectives

The general objective of this project is to design and develop web-based hospital management
system that provides reliable, efficient, and on time services to users.
1.4.2. Specific Objective

The specific objective of this project is listed as follow:
 Determine the issues with the current system.

 Identify the major features of the current system.
 Determine the system's functional and non-functional requirements.
 Analyze and model the proposed system
 Design and implement database
 To design and implement user interface prototype
 to design various modules
 to design a system that can be utilized to control patients and staff
 to design a system that can take attendance of employees
 to design a system that can generate reports
 to design a system that can calculate salary
 to design a system that can detect medicine expiry date
 to design a system that used to manage hospital’s In house activities
 to design a system that provide canteen services
 to design a system that improve a better co-ordination among different departments.
 to design a system that provide laboratory service
 to test main modules of the system
3
1.5. Scope of the project
Our software intends to develop a hospital management system which is a web based
application. This project is suitable for any hospital that needs a web based system. The scope of
this project includes:
 Maintaining Patient Details

 Maintaining Patient Treatment Details
 Maintaining Patient Schedule Details
 Maintaining Doctor Details
 Materials Inventory
 Generate a Bill
 Generate Reports
 In-House Activities
 Canteen Services
 Staff Management
1.6. Limitation of the Project

 Limited development time will be a major difficulty for us because we will only have a
limited amount of time to construct a system this large. As a result, we may not be able to
supply the system’s full functionality.
 The system does not support online transaction due to time
1.7. Feasibility Study

A feasibility study is an analysis that takes all of a project's relevant factors into account
including economic, technical, and operational considerations to ascertain the likelihood of
completing the project successfully. We assessed the feasibility of our project from the following
perspectives; Economic, technical, and operational feasibility.
1.7.1. Economic Feasibility

This study is carried out to check the economic impact will have on the system will have on the
organization. The amount of fund that the company can pour into the research and development
of the system is limited. The expenditures must be justified. Thus the developed system as well
4
within the budget and this was achieved because most of the technologies used are freely
available. Only the customized products have to be purchased.
1.7.2. Technical Feasibility

This study is carried out to check the technical feasibility, that is, the technical requirements of
the system. Any system developed must not have a high demand on the available technical
resources. This will lead to high demands being placed on the client. The developed system must
have a modest requirement, as only minimal or null changes for the implementing this system.
1.7.3. Operational Feasibility

The aspect of study is to check the level of acceptance of the system by the user. This includes
the process of training the user to use the system efficiently. The user must not feel threatened by
the system, instead must accept it as a necessity. The level of acceptance by the users solely
depends on the methods that are employed to educate the user about the system and to make
him/her familiar with it. His/her level of confidence must be raised so that he/she is also able to
make some constructive criticism, which is welcomed, as they are the final user of the system.
1.8. Significance of the Project
 The system improves patients' experiences.

 Since the system is automated, it reduces costs.
 The system improves the efficacy of the hospital management system.
 The system will reduce different types of errors that are made through interventions like
missing billing, operational failure, clinical errors, missing appointments, and much
more.
 The system allows easy patient data retrieval.
 The system is time-saving technology.
 The system helps reduce the work of documentation.
 The System helps the HR department by improving the way to manage employees.
 The system helps the finance department by improving tasks like bill management,
inventory management, salary and more.
 The system also allows generating report’s between days.
5
1.9. Methodology
1.9.1. Fact Finding Methodology

The following fact findings techniques are used to collect, store, gather, analyze and present
information. These are:
 Direct observation
 Existing document Analysis
1.9.2. System Development Process Model

The system development process model is a process or series of process used in software
development. For this project, we decided to use the Iterative and Incremental Model for
development model which allows room for scalability as time goes on, as the model is suitable to
starts with a simple implementation of a small set of the software requirements and iteratively
enhances the evolving versions until the complete system is implemented and ready to be
deployed.
1.9.3. System Design and Development Tools

The following tools are used to develop Hospital Management System software. These are:
 Ms-Word – It is used to write documentation of the project.

 MySQL – used to create database for the system.
 EdrawMax and Draw.io - used for modeling UML diagrams.
 Vistual Studio Code – used to write codes for html, css, JavaScript and php.
 Xampp- used as a local server for our project.
 Microsoft Project management- To create time management plan
1.10. Testing Plan
1.10.1. Unit Testing

Unit testing is testing the smallest testable unit of an application. It is done during the coding
phase by the developers. To perform unit testing, a developer writes a piece of code (unit tests)
to verify the code to be tested (unit) is correct.
6
1.10.2. Integration Testing
After the unit testing, the integration testing of the system is carried out. In integration testing,
we check if there is any error or bug present in the system after combining the different modules
that may have been developed by the different stakeholders. This type of testing is heavily
dependent on the behavior of the system that it exhibits after the interaction of the different
modules and whether they are providing the correct and accurate output of indented inputs.
1.11. Project Management

1.11.1. Cost Management
The following table shows the costs required for the development of the proposed project.
No Types of equipment, Specification Measurement Qty unit Total cost

materials and tools
1 Laptop Computer Core i5, 4GB pcs 2 24000 48000

RAM,2.3GHz CPU
speed and 1TB
Hard Disk
2 Internet MB 2 500 2000
3 Transportation Cost birr 90days 30 2700
4 Printing and laminating A4 size paper pcs 300 5 1500
cost
5 USB Flash drive SanDisk(32GB) pcs 1 400 400
6 Other Costs Hardware and - - - 1400
Software costs
Total cost
56,000ETB
Table 1 Project Cost Estimate Management
7
1.11.2. Project Schedule
Once we examine that the project is feasible, we undertake project planning. The figure shown
below describes how we planned our project.
Figure 1: Project Time Schedule Management
8
CHAPTER TWO: ANALYSIS OF EXISTING SYSTEM
2.1. Overview of Existing System
This part of the project describes the major functionality of the current or existing hospital
management system, problems with the existing system, identification of players in the existing
system, supplementary specification (i.e., business rule), and modeling the existing system
through an essential use case diagram, a CRC model, and an essential user interface prototype
flow diagram.
There is a lot of paperwork in the current HMS. To maintain or retrieve patient medical records
manually is a time-consuming task. With the increase in records, it will become a massive task to
maintain the medical records. It requires large quantities of file cabinets, which are huge and
require quite a bit of space in the office which is used for storing records of previous details. The
retrieval of records of previously registered patients will be a tedious task. The lack of record
security allows anyone to disassemble your system's records. All this work is done manually by
the receptionist and other operational staff, and a lot of papers need to be handled and taken care
of. Also, doctors have to remember various medicines available for diagnosis and sometimes
miss better alternatives as they can't remember them at that time. If someone wants to check the
details of the available doctors, the existing system does not provide any necessary details of this
type.
2.2. Function of Existing System

Through direct observation and existing document analysis, we determine the following major
functions of the current HMS:
 Register new patients.

 Record patient’s information.
 Treatment and management of patients by a team.
 Patient care with nursing, therapy, pharmacy and laboratory services.
 A medical prescription.
 Arrange the medicine in its category.
9
 Generate lab test report.
 Locate available bed rooms.
 Identify the medicines in the store.
 Record expire dates of the medicine.
 Receive Payment
 Make Receipt
 Hire Staff’s
 Manage employee
2.3. Problems of the Existing System

Our study of the current hospital management system identifies the following key problems:
 It requires a lot of paper work.

 It is difficult to handle data easily.
 It is difficult to store detailed records.
 Require a lot of space, and this result in document loss.
 Registration and booking appointments are time-consuming.

 It's challenging to quickly retrieve patient records.
 There is a lot of data redundancy.
 To carry out day-to-day operations, more labor is needed.
 The patient must go back to the doctor if a prescription is lost.
 There are a number of casualties in the case of an unreadable prescription.
 It is very prone to errors, and fixing them is difficult and takes more time.
 It is less secure.
 Lab reports are not delivered on time and require another man power to present for
doctor.
 It is difficult to determine the availability of bed rooms.

 It is also challenging to manage in patient and out patients.
 The pharmacy services available in the hospital are difficult to manage.
10
2.4. Players of Existing System
The following table shows players of the existing system and their corresponding responsibility.
NO Players Descriptions of roles of the players

1 Receptionist A person who communicates with patients, registers them, and books
appointments with doctors.
2 Doctors A doctor is a person with extensive knowledge in the field of medicine who
applies and dedicates his knowledge to figuring out the patient's medical issue
and uses his skill to prevent or treat it.
3 Nurses A person responsible for treating and caring for individuals and supporting
them through health and illness.
4 Laboratory A person responsible for collecting, receiving, labeling, and/or analyzing
technicians patient samples using the correct testing equipment.
5 Pharmacist A person in charge of verifying doctor's prescriptions before giving patients
medication and making sure they receive the right medication.
6 HR Responsible for management of all Employees
7 Finance Responsible for Managing all financial issues
8 Patient A person who requires a medical treatment.
Table 2: Players of the existing system
2.5. Supplementary Specification
2.5.1. Business Rule

1. Business Rule 1: The patient must be registered and have a card before he/she is presents
to the doctor.
2. Business Rule 2: Before presenting the patient to the doctor, nurses must perform a
physical examination, including measuring blood pressure, heart rate, and respiratory
rate, as well as recording the patient's height and weight.
3. Business Rule 3: To request laboratory and pharmacy services, the patient must obtain a
prescription from the doctor.
4. Business Rule 4: A patient's status as an inpatient or outpatient is determined by the
doctor.
11
2.6. Modeling the Existing System
In order to model the current HMS, we employ the essential use case model as well as the CRC
model.
2.6.1. Use Cases

 Register patients
 Booking appointment
 Collect cash
 Take physical examination
 Check room availability
 Check in and out patients
 Caring patients
 Consulting patients
 Prescribe medicine
 Prescribe laboratory
 Take samples
 Generate result report
 Accept prescription
 Verify prescription
 Sell medicine
 Request appointment
 Buy medicine
 Hire employee
 Manage employee
 Manage bill
 Financial report
 Material Management
 Control Cost
12
2.6.2. Essential Use Case Modeling
The essential use case diagram of the current hospital management system is shown in the figure
below: It shows how the players interact with the manual systems.
Figure 2: Essential Use Case Diagram for Hospital Management System
13
2.6.3. Essential Use Case Documentation
The following tables shows an essential use case documentation
Name Register patient

Identifier None
Description Register new patients
Actor Receptionist
Pre-Condition The receptionist will register the patient if the requested doctor is
available.
Post Condition None
Extends None
Includes None
Basic Course of Action
1. The receptionist ask patients information
2. Check whether the doctor is available or not.
3. If the doctor is available, the receptionist books an appointment.
Alternative Course of Action
Table 3: Register patient use case documentation
Name Prescribe medicine

Identifier None
Description Prescribe a medicine for patients
Actor Doctors
Pre-Condition The patient must be registered
Post Condition None
Extends None
Includes None
1. The doctor consults patients.
2. If the patient needs medicine, the doctor creates a prescription.
3) If the patient does not need medicine, the doctor makes only suggestions.
Table 4: Prescribe medicine use case documentation
14
Name Buy medicine
Identifier None
Description A patient buys medicine from the pharmacy.
Actor Patient
Post Condition The patient must have a prescription to buy the medicine.
Extends None
Includes None
1. This is discussed with the patient by the doctor.

2. The doctor writes a prescription for medicine for the patient.
3. The patient takes the prescription and goes to the pharmacy to buy a medicine.

2) If he or she is fine, they only take suggestions from the doctor.
Table 5 : Buy medicine use case documentation
Name Generate report

Identifier None
Description A laboratory technician generates a test result report after taking a
sample
Actor Laboratory technician
Pre-Condition The patient must give his or her sample.
Post Condition The patient must have a laboratory prescription from the doctor.
Extends None
Includes None
1. The patient takes his or her prescription and goes to the laboratory.
2. The laboratory technician accepts the prescription and verifies it.
3. The lab technician takes a sample from the patient.
4. The lab technician generates the test result report.

Table 6: Generate report use case documentation
15
Name Sell Medicine
Identifier None
Description Sell available medicine in the store to the customer
Actor Pharmacist
Pre-Condition The pharmacist checks prescription
Post Condition The pharmacist will sell medicine if the it is available on the shelf
Extends None
Includes None
1. The pharmacist accept prescription from the patient
2. The pharmacist find or search the medicine on the shelf
3. The pharmacist collect medicine from the shelf and identify according to its type
4. The pharmacist give the medicine to the customer
3. The medicine is not available on the shelf
4. The pharmacist informs to the customer the medicine type is not available
Table 7: Sell medicine use case documentation
16
2.6.4. CRC Model
CRC, which stands for Class-Responsibility-Collaboration, is an index card on which one
records the responsibilities and collaborators of classes. The CRC model of the current hospital
management system is shown in the following figure:
Figure 3: CRC Model for Existing Hospital Management System
17
2.6.5. Essential User Interface (UI) Flow Diagram
Figure 4: Essential UI for Medicine Prescription
18
Figure 5: Essential UI for X-ray Examination Request Form
19
CHAPTER THREE: ANALYSIS OF PROPOSED SYSTEM
3.1. Overview of Proposed System
The proposed project named “Hospital Management System” is a web based application. An
interactive application for managing details of Patients, doctors, Staff, doctors schedule, Bill,
Appointment, Canteen Services, Laboratory services and Reports.
This part of the project describe requirement determination (functional requirement, non-
functional requirement and system requirement), supplementary specification, identification of
actors and use cases and modeling the proposed system through system use case diagram,
conceptual class diagram, sequence diagram, and activity diagram.
3.2. Requirement Determination

3.2.1. Functional Requirement
 Adding Patients: The Hospital Management enables the staff in the front desk to
include new patients to the system.
 Assigning an ID to the patients: The HMS enables the staff in the front desk to
provide a unique ID for each patient and then add them to the record sheet of the
patient. The patients can utilize the ID throughout their hospital stay.
 Information of the Patient: The Hospital Management System generates a
report on every patient regarding various information like patient’s name, Phone
number, bed number; the doctor's name whom its assigns, ward name, and more.
 Appointments: Scheduling and managing appointments
 Operation Schedule: Scheduling and managing operation schedules to make the
task of doctor and staff easy.
 Transaction details: Storing the basic transaction details like records of income
and expense to make the task of creating the balance easier for the accounting
personnel.
 Report Generation: Maintaining all data and generating report of the specified
time can give a big support to the decision making
 Manage Staff: The details of staff such as personal, assigned duties, salary
details, etc. can be helpful to ease the operations with the staff.
Table 8: Functional Requirement
20
3.2.2. Non-Functional Requirements
Table 9 : Non-Functional Requirements
 Security:
3.2.3. System Requirements
 Login Credential: Any users who make use of the system need to hold a Logon credential.
3.2.3.1. Hardware Requirements
 Front Desk Staff Rights: The staff at the front desk can view any data in the Hospital
No Hardware Devices Specification
Management system, and add new patients record to the HMS but they don't have any rights to
1 Laptop/Desktop PC Core-i5, 2.5GHZ, 4GB RAM, 1TB hard disk
alter any data in it.
2 Printer HP, LaserJet Printer that is shared by more than
 Administrator rights: The administrator can view as well as alter any information in the
users in LAN
Hospital Management System.
3 Hard Disk 1 Terabyte
4  Wi-Fi-router For internet
Usability: This Hospital Management System work
has a operations inside
good looking useroffriendly
hospitalinterface.
Table 10: Hardware Requirements
 Serviceability: If issue arises in the Hospital Management System, then the project must be
programmed in such a way that developer can service it again.
 Availability The system will be available for 24/7.
21
3.2.3.2. Software Requirements
No Software Specification
1 Windows Operating System Windows 10 64-bits
2 Xampp Server Local Server installed in a computer
3 MSQL For database Management
4 PHP To develop Backend of the system
5 Visual Studio Code To write code
6 Web browser Google Chrome, Mozilla Firefox etc.
Table 11: Software Requirements
3.3. Supplementary Specification

3.3.1. Business Rule
ID BR-1
Name User login/Sign in
Description User of the system must enter their user name and password exactly as they did when
registered. The user will be unable to login if the username, password or both are
incorrect. The user will be instructed to input the right username and password by the
system.
Table 12: Business Rule 1 (User Login)
ID BR-2
Name Book Appointment
Description Only registered user can book an appointment
Table 13: Business Rule 2 (Book Appointment)
ID BR-3
Name Inpatient Admission
Description The Inpatient admission form must be filled by the doctor and admin rather than other
staffs.
Table 14: Business Rule 3 (Inpatient Admission)
ID BR-4
Name Patient Discharge
Description Patients must need to have discharge report and payment receipt before leaving the
hospital.
Table 15: Business Rule 4(Patient Discharge)
22
3.3.2. Constraints
 Computer skilled person needed for smooth operation.
 The system performs only basic accounting facilities (classified transactions into
Income, Expense, Asset and Liability).
 The system does not consider any governmental Tax’s.
3.4. Modeling Proposed System

3.4.1 System Use case Model
3.4.1.1. Identification of Actors

NO Actor Description
1 System Admin A person who controls the whole system
2 admin A person who manages the hospital that can manage the system
3 HR Responsible of Hiring and Managing of Employee
4 Finance Department Responsible for management of financial activity and inventory.
5 Doctor A person who manages treats patients and adds treatment detail to the
system.
6 Pharmacist A person who receives prescription and provide the prescribed medicine
to the correct patient.
7 Laboratorist A person who receives Test request from the doctor and based in that
take a sample from patients then send the result back to the doctor.
8 Reception The Person who is responsible in the front desk of the hospital.
9 Patient A person who needs medical consultation and treatment.
10 Canteen Staff A person who works in the canteen and that receives service order from
inpatients and deliver order.
Table 16: Actors of the proposed system
3.4.1.2. Identification of Use Cases

NO Use Case Id Use Case Type
1 UC-01 Login
2 UC-02 Book Appointment
3 UC-03 Manage Appointment
4 UC-04 Manage Patient’s Data
5 UC-05 View Doctors and staff Schedule
6 UC-06 Manage Doctor Detail
23
7 UC-07 Manage Bill
8 UC-08 Receive Payment
9 UC-09 Pay Bill
10 UC-10 Manage staff details
11 UC-11 Room Service
12 UC-12 Manage Reports
13 UC-13 Take Order
14 UC-14 View Order
15 UC-15 Manage Material
16 UC-16 Manage Supplier Details
17 UC-17 View Test Prescription
18 UC-18 Patient Discharge
19 UC-19 Treatment Details
20 UC-20 Manage hospital activities data
21 UC-21 Order food
22 UC-22 View Own Medical History
23 UC-23 Staff Report
24 UC-24 Medicine Expiry Report
25 UC-25 Patients Report
26 UC-26 Income Expense Report
27 UC-27 Material Reports
28 UC-28 View Medicine Prescription
29 UC-29 Print Prescription Details
30 UC-30 Calculate salary
31 UC-31 Take attendance
32 UC-32 Medicine
33 UC-33 Room Materials
34 UC-34 Prepare test Result
35 UC-35 Calculate Salary
36 UC-36 Canteen
37 UC-37 Laboratory
38 UC-40 Food materials
Table 17: Identification of Use Case
24
3.4.1.3. System Use Case Diagram
The following figures show the General and Specific System use case diagram:
Figure 6: General Use Case Diagram
25
The Following Use Case Diagrams are created for the purpose of simplicity, understandability
and mainly to reduce complexity. They are the detail definition of some use cases.
Figure 7: Patient Management Use Case
26
Figure 8: Staff Management Use Case
27
Figure 9: Doctor Management Use Case
28
Figure 10: Room Management Use Case
29
Figure 11: Laboratory Management Use Case
30
Figure 12: Supplier’s Management Use Case
31
3.4.1.4. System Use Case Documentation
Name Login
Identifier UC-01
Description log in to the system
Actor System Admin
Pre-Condition None
Post Condition The system admin log in to the system to perform admin tasks
Extends None
Includes None

1. The admin wants to log in to the system
2. The admin open the browser and locate the address of the system
3. The system displays the Log In page
4. The user input user name and password and click on Login button
5. The system displays a Home Page

1. The system displays a wrong message called user name or password is incorrect
2. The system go to step 4
Table 18: Login Use Case Documentation
32
Name Book Appointment
Identifier UC-02
Description It shows users a list of available doctors, timings and enables patients
to select the most suitable appointment date and doctor.
Actor Patient
Post Condition Patient details are displayed and a new appointment is fix or a existing
appointment is cancelled.
Extends None
Includes Patient’s Registration

1. The patient first logs in to the system
2. View his/her record
3. Create a new appointment or cancel the appointment
Table 19: Book Appointment Use Case Documentation
33
Name Manage Patient’s Detail
Identifier UC-04
Description The doctor can view patients appointment, record, past History and
other patient related issues
Actor Doctor
Pre-Condition The Doctor Must be registered doctor and system does not allow doctor
to modify some of his details.
Post Condition patient detail is updated

Extends None
Includes Patient Admission, Treatment
1 The doctor logs in to the system
2 Doctor may select view patient
3 Patient Medical details is displayed
4 Doctor add treatment

Table 20: Manage Patient’s detail Use Case Documentation
34
Name Manage Staff Details
Identifier UC-10
Description The HR can manage staffs
Actor HR
Pre-Condition The HR Must be registered
Post Condition None
Extends None
Includes None
1. The HR person enter his/her login credential and enters into the system
2. After successfully login his select Staffs link from the navigation bar
3. The system displays links related to staffs i.e. Attendance Salary, Leave

Table 21: Manage Staff Details Use case Documentation
Name View medicine prescription

Identifier UC-28
Description The can view the prescribe medicine by the doctor
Actor Pharmacist
Pre-Condition The Pharmacist Must be registered and system does not allow Pharmacist
to modify prescriptions.
Post Condition Patients prescription detail is updated
Extends None
Includes Patient Admission
1. The pharmacist enter his/her login credential and enters into the system
2. After successfully login his select view prescriptions
3. The system displays all prescribed medicine lists
Table 22: View Medicine prescription Use case Documentation
35
3.4.2. Conceptual Class Diagram
A Conceptual Class diagram is a visual representation in the unified modeling language (UML)
that illustrates the high level, abstract relationships and entities in a system or software
application. It focuses on the key concepts, classes and their association without getting into
detailed attributes or methods. The figure below shows the conceptual class diagram of the
proposed hospital management system.
Figure 13: Conceptual Class Diagram
36
3.4.3. Sequence Diagram
A sequence diagram or system sequence diagram (SSD) shows process interactions arranged in
time. It depicts the processes and objects involved and the sequence of messages exchanged
between the processes and objects needed to carry out the functionality. The following figures
represent sequence diagram of different use case.
Figure 14: Sequence Diagram for Patient Registration Use Case
37
Figure 15: Sequence Diagram for Update Doctor Use Case
38
Figure 16: Sequence Diagram for Register Doctor Use Case
39
Figure 17: Sequence Diagram for Update Patient Details Use Case
40
Figure 18: Sequence Diagram for Book Appointment Use Case
41
Figure 19: Sequence Diagram for Insert Invoice Details Use case
42
Figure 20: Sequence Diagram for Report Management
43
3.4.4. Activity Diagram
We use Activity Diagrams to illustrate the flow of control in a system and refer to the steps
involved in the execution of a use case. We model sequential and concurrent activities using
activity diagrams. So, we basically depict workflows visually using an activity diagram. An
activity diagram focuses on condition of flow and the sequence in which it happens. We
describe or depict what causes a particular event using an activity diagram. The following
figures shows Activity diagram of different use cases.
Figure 21: Activity Diagram for login Use Case
44
Figure 22: Activity Diagram for Add Doctor Use Case
45
Figure 23: Activity Diagram for Manage Appointment Use Case
46
Figure 24: Activity Diagram for update Patient Detail Use Case
47
Figure 25: Activity Diagram for update Canteen Food Price Use Case
48
CHAPTER FOUR: SYSTEM DESIGN
4.1. Overview of System Design

System design can be described as a process of defining the hardware and software architecture,
components, modules, interfaces and data for a system to satisfy specified requirement. The
preparation of an assembly of methods, procedures, or techniques united by regulated interaction
to form an organized whole. In other wards we described the hardware and the software we used
to develop the system.
This part of the project includes: Design Goals, System Architecture such as Architectural Style,
System Process, System Decomposition and system design models such as Object Oriented
Class diagram, Collaboration Modeling, Component Modeling, Deployment Modeling, Database
Design, and User Interface Design. It is also include the Access control and Design of the
Algorithm.
4.2. Design Goals

The goal of system design is to create a scalable, efficient, and reliable software system that can
effectively handle the increasing complexity and demands of modern businesses. This process
involves a series of steps, including the identification of system requirements, the selection of
appropriate technologies, the design of the system architecture, and the implementation of the
system. By following a systematic approach to system design, developers can effectively manage
complexity, adapt to changing requirements, and ensure the delivery of high-quality software.
Hospital management systems must be designed with the specific needs and requirements of the
healthcare facility in mind. This may involve incorporating features such as electronic health
records (EHRs), which enable the secure and efficient exchange of patient information between
healthcare providers and facilities. To ensure the successful implementation of the hospital
management system, it is crucial to conduct a thorough needs assessment and involve relevant
stakeholders in the design process. This will help to identify any potential challenges or
constraints and develop a system that can effectively address these issues.
49
4.3. Architecture of System Design
4.3.1. System Architecture

In this project we are using the Three-tier architecture, which separates applications into three
logical and physical computing tiers: the presentation tier, or user interface; the application tier,
where data is processed; and the data tier, where the data associated with the application is stored
and managed.
Figure 26: System Architecture Design Diagram
We are using this architecture because each tier can run on a separate operating system and
server platform and this gives us benefits like:
 Faster development: Because each tier can be developed simultaneously by different

team members.
 Improved scalability: Any tier can be scaled independently of the others as needed.
 Improved reliability: An outage in one tier is less likely to impact the availability or
performance of the other tiers.
50
4.3.2. System Process
A hospital management system (HMS) is a software application that helps healthcare
organizations manages their operations. HMSs can be used to manage a variety of tasks,
including patient records, appointments, billing, scheduling, staff management, canteen services
material inventory and so on. The system process at the system design level for an HMS
typically involves the following steps:
 Define the system requirements: This step involves gathering the requirements from the
stakeholders, such as the hospital administrators, doctors, nurses, and patients. The
requirements should include the functional requirements (what the system should do) and
the non-functional requirements (how the system should perform).
 Design the system architecture: This step involves designing the overall architecture of
the system, including the hardware, software, and network components. The architecture
should be designed to meet the system requirements and to be scalable and reliable.
 Develop the system: This step involves developing the software code for the system. The
code should be developed in a modular and maintainable way.
 Test the system: This step involves testing the system to ensure that it meets the
requirements. The testing should include functional testing, performance testing, and
security testing.
 Deploy the system: This step involves deploying the system to the production
environment. The deployment should be done in a controlled and orderly manner.
 Maintain the system: This step involves maintaining the system to ensure that it
continues to meet the requirements. The maintenance should include bug fixes, security
patches, and new features.
51
4.3.3. System Decomposition
System decomposition is the process of breaking down a complex system into smaller, more
manageable components. This can be done for a variety of reasons, such as to make the system
easier to understand, to improve its performance, or to make it more scalable.
4.3.3.1. Subsystem Decomposition

The following figure is subsystem decomposition for hospital management system
Figure 27: HMS System Decomposition
52
4.3.3.2. Subsystem Description
No Subsystem Description
1 Patient Management This subsystem is responsible for tracking patient information,
such as their medical history, current medications, and
allergies. It also allows scheduling appointments, track patient
progress.
2 Doctor Management This subsystem is responsible for tracking doctor information,
such as their schedules, availability, and specialties.
3 Staff Management This subsystem is responsible for tracking staff information,

such as their roles, details, attendance and leaves
4 Pharmacy Management This subsystem is responsible for managing prescription expiry
dates of medicines.
5 Laboratory Management This subsystem is responsible for managing laboratory tests,
and tracking patient laboratory results.
6 Inventory Management This subsystem is responsible for tracking the hospital's
inventory.
7 Report Management This subsystem provides data about the hospital work flow.
8 Bills Management This subsystem allows patients to view and pay their bills. It
would also allow healthcare providers to track patient
payments and manage billing disputes.
9 Canteen Management This subsystem allows patients and staff to order food and
drinks from the hospital canteen.
10 Room Management This subsystem allows healthcare providers to add details of
room and also to view details and status of rooms.
Table 23: Subsystem Description
53
4.3.4. Hardware/Software Mapping
One of the major tasks in system design deals with hardware/software mapping which deals with
which components would be part in which hardware and so on. The HMS is a broad system that
performs many functions. The web based part is expected to run on a networked environment on
different Operating System platforms. The client/server architecture of the system enables
different clients to connect to the server remotely through Internet connection. The applications
of the system will run on the web server connected to the database server by MYSQL. Users
merely need to start their browsers and enter the URL of the application Web site. The server
hosting the Web site is responsible for allocating all the resources the Web application requires.
The following figure is the hardware/software mapping of the proposed Hospital Management
System.
Figure 28: Hardware/ Software mapping for the proposed HMS
54
4.4. Object Oriented Class Diagram
At the design phase, an object-oriented class diagram serves as a blueprint for implementing a
system. It goes beyond the conceptual representation provided by the class diagram at the
analysis phase. In this context, the class diagram at the design phase delves into the specifics of
how the software components will be organized and structured in the code. This phase
emphasizes the internal structure of classes, including their methods, attributes, and
relationships, while considering implementation details such as data types, access modifiers, and
method signatures. Additionally, the design phase class diagram may also include details
regarding interfaces, abstract classes, and specific design decisions, which are not typically
present in the analysis phase diagram. The following figure is the object Oriented class Diagram
of the proposed Hospital Management System.
55
Figure 29: Object Oriented class Diagram
56
4.5. Component Diagram
A Component Model describes the hierarchy of functional components, their responsibilities,
static. Relationships and the way components collaborate to deliver required functionality.
The following figure is a Component diagram for the proposed Hospital management system.
Figure 30: Component diagram
57
4.6. Deployment Diagram
A deployment diagram is a diagram that shows the configuration of run time processing nodes
and the components that live on them. Deployment diagrams are a kind of structure diagram used
[6]
in modeling the physical aspects of an object-oriented system . They are often be used to
model the static deployment view of a system. For the Hospital management system, the
deployment model should be designed to ensure maximum efficiency and reliability in managing
the overall activity of the hospital.
Figure 31: Deployment Diagram
58
4.7. Database Design
Database design is the process of producing a detailed data model of a database. It involves
identifying the data to be stored and organizing it in a way that reflects the relationships between
different data elements. A well-designed database ensures data integrity, efficiency, and ease of
use for the end-users.
4.7.1. Conceptual Database Design

A conceptual database is an abstract representation of the overall structure and organization of a
database. It provides a high-level view of the relationships between different data elements
without getting into the specific technical details of how the data is stored or manipulated. The
conceptual database model typically focuses on defining the entities, their attributes, and the
relationships between these entities. It serves as a foundation for the logical and physical design
of the database, providing a conceptual framework that guides the development and
implementation of the actual database system. The following figure below shows the ER-
Diagram of Hospital Management System.
59
Figure 32: Entity Relation Diagram
60
4.7.2. Physical Database Design
Physical database design is the process of transforming a data model into the physical data
structure of a particular database management system (DBMS). This part of the design shows the
physical realization of the data in the database. Accordingly, the following table shows the
physical database design of hospital management system.
Table 24: admin_user table
Table 25: attendance table
61
Table 26: attendance_tran table
Table 27: balance_master table
Table 28: canteen_menu table
Table 29: demolition_item table
62
Table 30: distribution_of_item table
Table 31: doctor table
Table 32: doctor_indoor table
63
Table 33: doctor_outdoor table
Table 34: doctor_appointment_list table
Table 35: electricity_bill table
64
Table 36: employee_master table
Table 37: illness_sugestion table
65
Table 38: illness_complaint table
Table 39: treatment table
66
Table 40: incomeexpense table
Table 41: invoice table
Table 42: item table
67
Table 43: issue_stock table
Table 44: item_master table
Table 45: lab_master table
68
Table 46: lab_test_data table
Table 47: leave_from table
Table 48: leave_master table
69
Table 49: maintenance_of_item table
Table 50: medicine table
Table 51: medicine_expiry_report table
70
Table 52: operative_schedule table
Table 53: patient_allergy table
71
Table 54: patient table
Table 55: patient_canteen_bill table
72
Table 56: patient_bill table
Table 57: patient_history table
73
Table 58: patient_canteen_order table
Table 59: patient_illness_pasthistory table
74
Table 60: payment table
Table 61: purchase_order table
75
Table 62: room_master table
Table 63: supplier_master table
Table 64: treatment_doctor_note table
76
Table 65: treatment_clinical_handover table
77
Table 66: treatment_investigation table
78
Table 67: treatment_outpatient table
Table 68: treatment_patient_dailytreatment table
79
Table 69: treatment_patient_dailymedication table
Table 70: treatment_patient_assesment
80
81
Table 71: treatment_surgery tableadd
Table 72: patient_allergy table
82
Table 73: patient_addiction table
Table 74: patient_admission table
83
4.8. User Interface Design
User interface (UI) design focuses on creating easy-to-use visual or audio interface elements to
help users interact with a site, app, or other computer systems in a user-friendly manner.
Figure 33: login page Screen UI
On this page the user needs to enter the USERNAME and PASSWORD and press on LOGIN
button which gets the user to the HOME page.
84
Figure 34: Patient Registration Screen UI
85
Figure 35: Doctor Registration Screen UI
86
Figure 36: Services Screen UI
87
Figure 37: Cleaning Service Screen UI
88
Figure 38: Staff Management Screen UI
89
Figure 39: Register Employee Screen UI
90
Figure 40: Daily Attendance Screen UI
91
Figure 41: Departments Screen UI
92
Figure 42: Reports Management Screen UI
93
Figure 43: Medicine Report Screen UI
94
4.9. Access Control
Access control is a data security process that enables organizations to manage who is authorized
to access corporate data and resources. Secure access control uses policies that verify users are
who they claim to be and ensures appropriate control access levels are granted to users.[7]
Implementing access control is a crucial component of web application security, ensuring only
the right users have the right level of access to the right resources. The process is critical to
helping organizations avoid data breaches.
For this project we decided to use role-based access control. Role-based access control or role-
based security is an approach to restricting system access to authorized users. It is suitable for
our project because our system has different type of user which has different level access and
authority. Each role in the system has privileges and restrictions.
95
CHAPTER FIVE: IMPLIMENTATION AND TESTING
5.1. Introduction
The implementation phase is the practical realization of the software design. It involves writing
the actual code based on the design specifications, integrating different modules or components,
and ensuring that the entire system is configured properly. This phase includes utilizing
configuration management tools and practices to effectively manage changes and control the
software development process. Testing is also critical phase that runs in parallel with
implementation. It includes several types of tests.
This part of the project contains Coding, Software testing and testing procedures like Unit testing,
Integration testing and System testing.
5.2. Coding
Coding refers to the process of translating design specifications into a computer program. It is a
crucial phase in the software development lifecycle that involves writing precise, structured, and
readable code based on the requirements and design specifications identified during earlier stages
of development. We use different tools to develop this project. Some of them are:
Front End HTML CSS JavaScript
Back End PHP
Database MYSQL
Server Apache
96
5.3. Software Testing and Procedures
5.3.1. Software Testing

Software testing is recognized as an important part of quality assurance. Testing as shown below
proceeds in parallel with system development, here a test plan is developed in parallel with system
design. The test plan is then used in system testing. Testing proceeds through a number of steps. First
individual programs modules are tested by their developers. Once Individual modules are tested, the
next step is to test whether they can be combined. This is known as integral testing; groups of modules
are combined into test modules and tested together. The goal is to determine whether the interfaces
between modules work properly. Then the entire system is tested.
The testing process has two goals
 To demonstrate to the developer and the customer that the software meets its requirements.
 To discover situations in which the behavior of the software is incorrect, undesirable, or does
not conform to its specification.
We test the software process activities such as Design, Implementation, and Requirement Engineering
using unit testing, integration testing because design errors are very costly to repair once system has
been started to operate. Therefore, it is quite obvious to repair them at early stage of the system.
5.3.2. Testing Procedures
5.3.2.1. Unit testing

Unit testing is the first level of testing and is often performed by the developers themselves. It is
the process of ensuring individual components of a piece of software at the code level are
functional and work as they were designed to. Unit testing can be conducted manually, but
automating the process will speed up delivery cycles and expand test coverage. Unit testing will
also make debugging easier because finding issues earlier means they take less time to fix than if
they were discovered later in the testing process.
97
5.3.2.2. Integration Testing
After our individual module was tested out, we go to the integrated to create a complete system.
This integration process involves building the system and testing the resultant system for
problems that arise from component interactions. We have applied top-down strategy to validate
high-level components of a system before design and implementations have been completed.
Because, our development process started with high-level components and we worked down the
component hierarchy.
5.3.2.3. Condition Testing

Condition testing is a test case design method that exercises the logical conditions contained in a
program module. If the condition is incorrect, then as least one component of the condition is
incorrect. It may include:
 Boolean operator error

 Boolean variable error
 Boolean parenthesis error
 Relational operator error
5.3.2.4. System Testing

This stage focuses on validating and analyzing that the software and all its sub-systems comply with
the requirements as specified by the client. It’s at this stage the software is tested as a whole.
98
CHAPTER SIX: CONCLUSION AND RECOMMENDATIONS
6.1. Summary and Conclusion
The hospital management system is a comprehensive software solution designed to streamline
and optimize various administrative and operational tasks within a healthcare facility. Through
its user-friendly interface and robust features, the system facilitates efficient management of
patient records, appointments, billing, and inventory. It enables seamless communication
between different departments, allowing for coordinated and timely patient care. Moreover, the
system ensures compliance with regulatory standards and data security protocols, safeguarding
sensitive patient information. Overall, the hospital management system significantly enhances
the overall efficiency and quality of healthcare services, leading to improved patient experiences
and better healthcare outcomes.
In conclusion, the implementation of the hospital management system represents a significant

milestone in improving the healthcare services offered by our facility. The system's integrated
approach has enabled us to centralize and manage patient data more effectively, leading to
streamlined operations and enhanced decision-making. The automation of administrative tasks
has reduced the likelihood of errors and inefficiencies, allowing staff's to focus more on
delivering high-quality patient care. Furthermore, the system's reporting and analytics
capabilities have provided valuable insights for improving resource allocation and optimizing
service delivery. With its user-friendly interface and comprehensive features, the hospital
management system stands as a cornerstone in our commitment to providing efficient,
accessible, and high-quality healthcare services.
EXPERIENCE AND LEARNING

 First of all, taking a huge system like HMS (Hospital Management System) and build it
from the scratch is with considering all aspects of Software Engineering from gathering
requirements to planning, designing, proposing the project plan, defining the scope,
modeling, analyzing the design, coding, building a database for the whole system, testing
is a lifetime experience in itself.
99
 Whenever we have shown our vision and work about the project to anyone like our
teachers, friends, they always told us that we have taken a very big task to get completed
in very short time and to do that it takes courage and also they all given best wishes and
support and believed in us that we can do it.
 Building a software application for a hospital to cover all the aspects and putting the
whole manual system into a computer based system with a proper and user-friendly view
and generating a proper output taught us how different is the real world.
 Working in a team made us realize the importance of team spirit, unity and patience. It
taught us how to utilize the strengths of every individual in a team and also how to
support each other in weak areas of one.
 We faced many difficulties but having a good advisor makes everything much easier,
every time we were stuck somewhere our guide was there to help us, challenged us to
solve the queries on our own and in the end always used to give us the finest solutions.
 We learned to solve real problems, learned lot of new techniques and technologies
during this period. This project helped us to get out of our comfort zone, learn new
technologies and their implementations.
 We have strengthened our knowledge about the languages such as PHP and HTML.We
have learned that little changes in the basic syntax can do a lot of complex tasks.
 The last 4 months were a roller coaster ride for us consisting of knowledge gain,
experience, life lessons, team work, real time dealing. We are grateful to our department
for such an amazing experience.
10
6.2. Recommendation
Efficient utilization of the hospital management system can be ensured through a multifaceted
approach. Providing continuous training sessions and support for the staff members will
empower them to navigate the system seamlessly. Regular system updates and maintenance
checks are imperative to keep the software robust and aligned with the latest industry standards.
Exploring the possibilities of integrating the hospital management system with other healthcare
systems, such as electronic health records and diagnostic systems, can streamline data
management and enhance the overall operational efficiency of the hospital. Prioritizing
flexibility and scalability in the system architecture will enable the hospital to adapt to the
changing needs of the healthcare environment. Rigorous implementation of data security
measures and compliance with privacy regulations will be instrumental in safeguarding patient
data and maintaining the trust of the patients. Creating a systematic feedback loop to gather
inputs from stakeholders and incorporating these insights into system enhancements will foster
continuous improvement. Establishing comprehensive disaster recovery plans and regularly
testing backup systems will ensure data integrity and minimize the impact of potential system
failures. Regular cost-benefit analyses will aid in evaluating the return on investment and the
overall impact of the system on the hospital's operations and patient care services.
10
I. REFERENCES
1. National Academies of Sciences, Engineering, and Medicine. 2021. Implementing High-
Quality Primary Care: Rebuilding the Foundation of Health Care. Washington, DC: The
National Academies Press. https://doi.org/10.17226/25983.
2. Griffith, J. R., & White, K. R. (2005, May). The revolution in hospital management.
In CASES (Vol. 39, No. 1, p. 239).
3. Balaraman, P., & Kosalram, K. (2013). E-hospital management & hospital information
systems-changing trends. International Journal of Information Engineering and Electronic
Business, 5(1), 50.
4. Cohen, H. J., Feussner, J. R., Weinberger, M., Carnes, M., Hamdy, R. C., Hsieh, F., ... &
Lavori, P. (2002). A controlled trial of inpatient and outpatient geriatric evaluation and
management. New England Journal of Medicine, 346(12), 905-912.
5. Booch, G., Maksimchuk, R. A., Engle, M. W., Young, B. J., Connallen, J., & Houston,
K. A. (2008). Object-oriented analysis and design with applications. ACM SIGSOFT
software engineering notes, 33(5), 29-29.
6. Torre, D., Labiche, Y., Genero, M., & Elaasar, M. (2018). A systematic identification of
consistency rules for UML diagrams. J. Syst. Softw., 144, 121-142.
7. https://www.fortinet.com/resources/cyberglossary/access-control
10
II. APPENDIX
APPENDIX A: Sample code for database connection
<?php
$con_servername = "localhost";
$con_username = "root";
$con_password = "";
$database = "hospital_management_system";
$connection = mysqli_connect($con_servername, $con_username, $con_password, $database);
?>
10
APPENDIX B: Sample script code for Surgery Consent
<?php
// A form to be filled before Surgery
include('connect.php');
$current_date = date("Y-m-d");
$current_time = date("H:i");
$patient_id = $_GET["patient_id"];
$treatment_id = $_GET["treatment_id"];
$view_patient = "SELECT * FROM patient WHERE Patient_id = $patient_id";
$result_patient = mysqli_query($connection, $view_patient);
if(mysqli_num_rows($result_patient) > 0)
{
while ($row_patient = mysqli_fetch_assoc($result_patient))
{
$patient_name = $row_patient["Patient_Name"];
$patient_relative_name = $row_patient["Patient_Relative_name"];
$patient_relative_rel = $row_patient["Patient_Relative_Relation"];
}
}
?>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Surgery Consent</title>
</head>
<body class="container" style="font-family: Times New Roman; font-size: 16px;">
<img src="../images/background.jpg" align='right'>
<h2>
<span style="padding-left: 15px; padding-right: 15px;">
CONSENT FOR SURGERY
</span>
</h2>
<br><br>
<form action="../Surgery_Consent_Add.php" method="POST">
<input type="hidden" value="<?php echo $treatment_id;?>" name="treatment_id">
<input type="hidden" value="<?php echo $patient_id;?>" name="patient_id">
<input type="hidden" value="<?php echo $login_name;?>" name="admin_name">
<textarea rows="10" cols="40"><?php echo $patient_name;?></textarea>
<div class="justify-content-center" style="padding-top: 12%">
Hereby I/my relative<input type="text" value="<?php echo $patient_name;?>" readonly="">
(Patient Name), give my full consent as an act of my own free will to undergo the following
surgery<input type="text" name="surgery_name" required="" >(Surgery name) at <b>HMS
10
Hospital</b> under the supervision and guidance ofDr.<input type="text" name="doctor_name"
required=""> and his team of assistants, nurses and hospital staff as deemed necessary.<br><br>
I have been explained in the language known & understood by me about the nature of the
surgery being performed, its benefits and costs, risks associated with, other alternatives and its
prognosis.<br>
Risks: <input type="text" name="surgery_risks"><br>
Benefit: <input type="text" name="surgery_benefit"><br>
Alternatives: <input type="text" name="surgery_alt"><br>
<ul><li> I have been explained clearly that my Surgery is not totally safe and that Surgery can
be risk to life of healthy person, despite the necessary & proper steps are taken.
</li><li>
I understand my doctors have explained to me that excessive bleeding, infection, cardiac
arrest,pulmonary embolism and complication like this can arise suddenly and unexpectedly while
undergoing any investigation/Surgery.
</li>
<li>
I give consent and agree to the removal & disposal of body parts/tissues by the hospital
Authority that may be above - mentioned surgery.
</li>
<li>
I have read the above writing has been explained in detail to me. I have understood that foresaid
and I am willingly giving my consent without any pressure & taking every necessary precaution
& giving adequate care & treatment, above mentioned outcome occurs in the hospital, respective
Surgeon or Staff member are not held responsible</li> </ul>
<table>
<tbody>
<tr>
<td>
Name of Patient/Relative/Witness
<input type="text" value="<?php echo $patient_relative_name;?>">
</td>
<td>Name of Surgeon:<input type="text" name="surgeon_name" required="" ></td>
</tr>
<tr>
<td colspan="2"> Sign of:Patient/Relative/Witness<input type="text" readonly="" >
</td>
</tr>
<tr>
<td>Relation with Patient:
<input type="text" value="<?php echo $patient_relative_rel;?>">
10
</td>
<td>Sign of Surgeon:<input type="text" readonly=""></td>
</tr>
<tr>
<td>Date:<input type="text" readonly=""></td>
<td>Date:<input type="date" value="<?php echo $current_date;?>"></td>
</tr>
<tr>
<td>Time:<input type="text" readonly=""></td>
<td>Time:<input type="time" value="<?php echo $current_time;?>"></td>
</tr>
</tbody>
</table>
</div>
<input type="submit" value="Next">
</form>
</body>
</html>
10
APPENDIX C: Sample script code for Add Surgery Consent
<?php
// To insert the surgery form into database
include('connect.php');
if($_POST)
{
$login_name = $_POST["admin_name"];
$treatment_id = $_POST["treatment_id"];
$patient_id = $_POST["patient_id"];
$surgery_name = $_POST["surgery_name"];
$doctor_name = $_POST["doctor_name"];
$surgery_risks = $_POST["surgery_risks"];
$surgery_benefit = $_POST["surgery_benefit"];
$surgery_alt = $_POST["surgery_alt"];
$surgeon_name = $_POST["surgeon_name"];
$add_surgery_consent = "INSERT INTO treatment_surgery "
. "(Treatment_id , Doctor_name , Surgery_name , Surgeon_name , "
. "Surgery_Risks , Surgery_Benefits , Surgery_Alternatives) VALUES "
. "($treatment_id , '$doctor_name' , '$surgery_name' , '$surgeon_name' , "
. "'$surgery_risks' , '$surgery_benefit' , '$surgery_alt')";
if(mysqli_query($connection, $add_surgery_consent))
{
header("Location:Inpatient_Treatment.php?patient_id=$patient_id&admin_name=$login_name);
}
else
{
echo "<script>alert('Surgery Consent details Not Inserted');"</script>";
}
}
10

Hospital Management Sysem Proposal Cosc - 2012 - Special

Uploaded by

Document Information

Original Title

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 Sysem Proposal Cosc - 2012 - Special

Uploaded by

Copyright:

Available Formats

DESIGN AND IMPLEMENT WEB BASED HOSPITAL

UNITY UNIVERSITY, ADAMA CAMPUS

DEPARTMENT OF COMPUTER SCIENCE

A FINAL PROJECT SUBMITTED TO DEPARTMENT OF

IN PARTIAL FULFILLMENT OF THE REQUIREMENT OF THE

UNITY UNIVERSITY ADAMA CAMPUS

Approved By Board of Examiners:

Chairman, Dept. Graduate Committee Signature Date

Advisor Signature Date

Internal Examiner Signature Date

Name of Candidate Groups Signature Date

Table 1 Project Cost Estimate Management....................................................................................7

CPU Central Processing Unit

CRC Class Responsibility Collaborator

CSS Cascading style sheet

EMR Electronic Medical Record

ETB Ethiopian birr

HMS Hospital Management System

HTML Hyper text markup language

MYSQL Structured Query Language

PHP Hypertext Pre-processor

UML Unified Modeling Language

XAMPP Cross-platform, Apache, MYSQL, PHP and Perl

1.1. Background of the Project

1.2. Statement of the problem

1.4. Objectives of the Project

1.4.1. General Objectives

1.4.2. Specific Objective

 Determine the issues with the current system.

 Maintaining Patient Details

1.6. Limitation of the Project

1.7. Feasibility Study

1.7.1. Economic Feasibility

1.7.2. Technical Feasibility

1.7.3. Operational Feasibility

1.8. Significance of the Project

 The system improves patients' experiences.

1.9.1. Fact Finding Methodology

1.9.2. System Development Process Model

1.9.3. System Design and Development Tools

 Ms-Word – It is used to write documentation of the project.

1.10. Testing Plan

1.10.1. Unit Testing

1.11. Project Management

No Types of equipment, Specification Measurement Qty unit Total cost

1 Laptop Computer Core i5, 4GB pcs 2 24000 48000

Figure 1: Project Time Schedule Management

2.2. Function of Existing System

 Register new patients.

2.3. Problems of the Existing System

 It requires a lot of paper work.

 Registration and booking appointments are time-consuming.

 It is difficult to determine the availability of bed rooms.

 The pharmacy services available in the hospital are difficult to manage.

NO Players Descriptions of roles of the players

7 Finance Responsible for Managing all financial issues

8 Patient A person who requires a medical treatment.

Table 2: Players of the existing system

2.5. Supplementary Specification

2.5.1. Business Rule

2.6.1. Use Cases

Figure 2: Essential Use Case Diagram for Hospital Management System

Name Register patient