Table of Contents

1. Introduction ......................................................................................................................... 1
1.1. Objective ..................................................................................................................... 1
1.1.1. General objectives ................................................................................................ 1
1.1.2. Specific objectives ............................................................................................... 1
Chapter two................................................................................................................................. 2
2. Methodology and Tools ....................................................................................................... 2
2.1. Methodology ............................................................................................................... 2
2.2. Tools........................................................................................................................ 2
Chapter Three ............................................................................................................................. 3
3. System Requirement Specification ....................................................................................... 3
3.1. Overview ..................................................................................................................... 3
3.2. Feasibility Study .......................................................................................................... 3
3.2.1. Cultural Feasibility ............................................................................................... 3
3.2.2. Economic Feasibility ............................................................................................ 3
3.2.3. Operational Feasibility ......................................................................................... 3
3.2.4. Technical Feasibility ............................................................................................ 4
3.3. Functional Requirements.............................................................................................. 4
3.3.1. Register the Data of patients ................................................................................. 4
3.3.2. Searching for the Data of Patients ......................................................................... 4
3.3.3. Checking if a patient requires Emergency treatment ............................................. 4
3.3.4. Checking if Doctors are available ......................................................................... 5
3.3.5. Sending lab form requests for the Laboratories ..................................................... 5
3.3.6. Sending lab form results to the doctors ................................................................. 5
3.3.7. Managing appointments ....................................................................................... 5
3.3.8. Sending patient's data to Doctors/ IPD department ................................................ 6
3.3.9. Sending patient's data to the Operation Room ....................................................... 6
3.3.10. Prescribing medicine for patients and keeping stock of Medicine .......................... 6
3.3.11. Checking if Beds are available.............................................................................. 6
3.3.12. Authentication sub-system.................................................................................... 7
3.4. Non-Functional Requirements ...................................................................................... 7

i
 3.4.1. Performance Requirements ................................................................................... 7
3.4.2. Safety Requirements ............................................................................................ 7
3.4.3. Security Requirements ......................................................................................... 7
Chapter Four ............................................................................................................................... 8
4. System Analysis and Modeling ............................................................................................ 8
4.1. Overview ..................................................................................................................... 8
4.2. Scenario Based Modeling ............................................................................................. 8
4.2.1. Use case identification .......................................................................................... 8
4.2.2. Actors List ........................................................................................................... 8
4.2.3. Use case Diagram................................................................................................. 9
4.2.4. Use case Description .......................................................................................... 14
4.2.5. Activity Diagram................................................................................................ 28
4.2.5.1. Searching patient data diagram ....................................................................... 28
4.2.5.2. Registering Patient data .................................................................................. 28
4.2.5.3. Doctor Laboratory interaction ......................................................................... 29
4.2.5.4. Acquiring beds for patients ............................................................................. 30
4.2.5.5. Prescribing medicine for patients .................................................................... 31
4.3. Behavioral Modeling ................................................................................................. 32
4.3.1. Sequence diagram .............................................................................................. 32
4.3.1.1. Authentication Diagram.................................................................................. 32
4.3.1.2. Patient Data registration diagram .................................................................... 33
4.3.1.3. Ward and Lab Inter Communication ............................................................... 33
4.3.1.4. Acquiring bed for patients .............................................................................. 34
4.3.1.5. Patient forwarding to specialists diagrams ...................................................... 34
4.4. State Diagram ........................................................................................................ 35
4.4.1. Searching patient data ........................................................................................ 35
4.4.2. Register patient .................................................................................................. 36
4.4.3. Laboratory services ............................................................................................ 36
4.4.4. Bed treatment ..................................................................................................... 37
4.4.5. Pharmacy services .............................................................................................. 37
4.5. Class-Based Modeling ............................................................................................... 38
4.5.1. Class Diagram .................................................................................................... 38
Chapter Five ............................................................................................................................. 39

ii
5. System Design................................................................................................................... 39
5.1. System Decomposition............................................................................................... 39
5.2. Module Description ................................................................................................... 39
5.3. Architecture of the system .......................................................................................... 41
5.3.1. Component Diagram .......................................................................................... 41
5.3.2. Deployment Diagram ......................................................................................... 42
5.4. Database design ......................................................................................................... 42

iii
 List of figures
Figure 1 ....................................................................................................................................... 9
Figure 2 Main system use-case diagram .................................................................................... 10
Figure 3 Admin’s Main Operations ............................................................................................ 10
Figure 4 Authentication system ................................................................................................. 11
Figure 5 Patient data registration and Management .................................................................. 11
Figure 6 Interaction of departments with OPD doctors .............................................................. 12
Figure 7 OPD doctor’s interaction with another department ..................................................... 12
Figure 8 Departments interaction with the pharmacy................................................................ 13
Figure 9 Searching patient data diagram ................................................................................... 28
Figure 10 Registering Patient data ............................................................................................. 28
Figure 11 Doctor Laboratory interaction .................................................................................... 29
Figure 12 Acquiring beds for patients ........................................................................................ 30
Figure 13 Prescribing medicine for patients ............................................................................... 31
Figure 14 Authentication sequence diagram ............................................................................ 32
Figure 15 Registering Data of patients ....................................................................................... 33
Figure 16 Acquiring bed for patients .......................................................................................... 34
Figure 17 Patient forwarding to specialists diagrams ................................................................. 34
Figure 18 Searching patient data ............................................................................................... 35
Figure 19 Register patient ........................................................................................................ 36
Figure 20 Laboratory services ................................................................................................... 36
Figure 21 Bed treatment .......................................................................................................... 37
Figure 22 Pharmacy services ..................................................................................................... 37
Figure 23 Class diagram ............................................................................................................ 38
Figure 24 System decomposition ............................................................................................ 39
Figure 25 Component Diagram .................................................................................................. 41
Figure 26 Deployment Diagram .............................................................................................. 42
Figure 27 Users Database ........................................................................................................ 42
Figure 28 Laboratory database ................................................................................................ 43
Figure 29 Pharmacy Database.................................................................................................. 44
Figure 30 Appointment Database ............................................................................................. 44
Figure 31 IPD Department database .......................................................................................... 45
Figure 32 OR Database ............................................................................................................. 45
Figure 33 prototype screen shot ................................................................................................ 46

iv
 List of Table’s
Table 1 Authentication .............................................................................................................. 15
Table 2 Register Patient Data .................................................................................................... 16
Table 3 Display patient information........................................................................................... 16
Table 4 Search data ................................................................................................................... 17
Table 5 Handle appointments .................................................................................................... 18
Table 6 Check availability of doctors ........................................................................................ 19
Table 7 Check availability of beds ............................................................................................ 20
Table 8 Send laboratory test request .......................................................................................... 21
Table 9 Send laboratory test results ........................................................................................... 22
Table 10 Track ICU patients ..................................................................................................... 23
Table 11 Send patient’s data to specialist ................................................................................... 24
Table 12 Send patient’s data to OR............................................................................................ 25
Table 13 Send patient’s data to IPD ........................................................................................... 26
Table 14 Prescribe medicine ..................................................................................................... 26
Table 15 Check for availability of Medicine ............................................................................ 27

v
 Chapter one
1. Introduction
Our day to day life is very dependent on medical services. And thus, Hospitals are
one of the biggest service providers. In order to deliver an effective service to whom
in need, it is necessary for the hospitals to keep track of their day-to-day activities &
records of its patients, doctors, nurses, financial works and other staff personals that
keep the hospitals running smoothly & successfully. But, recording all these data’s
and searching on paper work is considered to drag down the effective service delivery
that the hospital and its workers are committed to do. It is also inefficient and a time-
consuming process including economical coast and wastage.
The project we are going to discuss will use digital data system instead of manual
work, and it will solve many problems related to what is stated earlier. It also aims at
providing low-cost reliable automation of the existing systems, with an increased
security and administration settings. As over all, this management system
will offer to have an effective output and service delivery for the entire section.
1.1.Objective
1.1.1. General objectives

1.1.2. Specific objectives

• Increasing in processing speed and results
• Cost effectiveness
• Reduction in errors
• Data security and retrieving ability
• Better patient care

1
 Chapter two
2. Methodology and Tools
2.1. Methodology
In the development phase of the project we are planning to do by classifying the system
into different components and by sharing the work amongst group members. The
software life cycle method that we will use is the Water fall model because we need to
test each component and subsystem before going to other sub system development and
this helps in having a well-organized and efficient system component that will make the
final testing phase much easier. In the development we will specifically use different
structural design patterns to use to classify and coordinate the sub-systems.
2.2.Tools
The various system tools that have been used in developing both the front end, back end
and other tools of the project are being discussed in this section.
Front end
HTML, CSS, Bootstrap, JAVA SCRIPTS are utilized to implement the frontend.
• HTML (Hyper Text Mark-up Language): HTML is a syntax used to format a
text document on the web.
• CSS (Cascading Style Sheets): CSS is a style sheet language used for describing
the look and formatting of a document written in a mark-up language.
• Bootstrap: includes HTML and CSS based design templates for typography,
forms, buttons, tables, navigation, modals, image carousels and many other, as
well as optional JavaScript plugins.
• Java Script: JS is a dynamic computer programming language. It is most
commonly used as part of web browsers, whose implementations allow client-
side scripts to interact with the user, control the browser, communicate
asynchronously, and alter the document content that is displayed.
BACK END
The back end is implemented using MYSQL which is used to design the databases.

• MYSQL: MySQL is the world’s second most widely used open source relational
database management system (RDMS). The SQL phrase stands for structured query.
• PHP: PHP is a server-side scripting language designed for web development but
also used as a general purpose programming language. PHP code is interpreted by a
web server with a PHP processor module, which generates the resulting web page:
PHP commands can be embedded directly into an HTML source document rather
than calling an external file to process data.

2
 Chapter Three
3. System Requirement Specification
3.1. Overview
This hospital management is a platform that can connect the entire elements
with a web based application. This helps the professionals by simplifying their
work and reducing complicated tasks. It has also a direct benefit for patients to get
fast and efficient service.

3.2.Feasibility Study
The feasibility study is used to determine the viability of the system. It seeks
to identify potential problems and to determine whether the system can work
efficiently or not. The study assesses the following feasibility studies on the
proposed system to determine whether the system is feasible. These are:

3.2.1. Cultural Feasibility

The System won’t face any cultural barriers as the community is open to any
technological advancement in the hospital environment that can decrease the
tiresome paper work in the hospital. And also, the system does not have any bad
impact on the environment.

3.2.2. Economic Feasibility

The system development requires testing and deployment cost. As the
hospital has shown willingness for the system and have its own server and enough
computers to use the system. Therefore it would be easier and effective according
to economic feasibility.

3.2.3. Operational Feasibility

As the system is used by the professionals mostly, it won’t be that much
difficult to let them get used to it. This system changes the existing manual system
which is to be considered less effective when compared to digital systems then the
professionals would be happy to use it as it helps them in different aspects.

3
 3.2.4. Technical Feasibility
After the system is deployed the only things that are needed to get started are
networked Computers. The system is going to be built to be used by computers as
it is a common way, and internet won’t be mandatory if the system is all
connected by its own. What is need is, the hospital to have enough computers and
network access to accommodate the system, as long as the system is problem
solving and relevant to their hospital.

3.3. Functional Requirements

In this part of the Document, it is tried to organize the functional
requirements of the system as features and are numbered.

3.3.1. Register the Data of patients

Description and priority

Recording patients’ primary data like name and age etc.. all the relevant
information about a patient and store in a database system.

3.3.2. Searching for the Data of Patients

Description and Priority

Finding a patients detail that is already recorded by different elements of the

system easily. This ensures fastness and quality work as it is very effective.

3.3.3. Checking if a patient requires Emergency treatment

Description and priority

This part of the system will be after checking if a patient requires emergency
care and registering the information of the patient. This function will link the
already existing data of the patient with the results of the check-up and will also
notify the department the patient needs to be forwarded to. This function also is
also highly prioritized.

4
 3.3.4. Checking if Doctors are availabl
Description and priority

When patients are registered in the system the next step in the process will be
looking if the Doctors that generally examine the patients are available or not.
This phase will save the time of both patients and the porters because the system
will check the available doctors and display them. This function will make the
patient experience in the hospital accurate and precise. This phase will be given a
medium priority.

3.3.5. Sending lab form requests for the Laboratories

Description and priority

The existing system uses a paper form that is to be sent from the doctor to lab
in order to obtain results. But in this system the system will generate a digital form
request to the lab. . This will send a message to the lab-technicians and will help
them get the necessary materials ready until the patient arrives and will fasten the
process.

3.3.6. Sending lab form results to the doctors

Description and priority

This is a continued step form sending lab-test. From the existing system, it was
manually brought back to the doctor as it is written in a piece of paper. But now, it
is going to be fully a digital response to be sent back to the specific doctor who
requested it.

3.3.7. Managing appointments

Description and priority

Patients might be appointed for another time when their progress needs to be
checked after some medicine or some treatment is given to them. This part of the
system will be used to record the appointment that patient has and look for the
appointment when the patient comes to attend that appointment and this part must
be related to other data of a patient. This phase will be given a medium priority.

5
 3.3.8. Sending patient's data to Doctors/ IPD department
Description and priority

When patients require treatments while resting or beds to receive some kind of
treatments this function of the system will allow the wards to check for available
beds and share their medical records with IPD department. And also reporting of
medical information to the department that sent the patients to the IPD.

3.3.9. Sending patient's data to the Operation Room

Description and priority

If an operation is suggested by the subjected part, all required information of the

patient will be sent to the Operation Room. This process will make sure the
available schedule and will help the ward book the time and date of a surgery.

3.3.10. Prescribing medicine for patients and keeping stock of Medicine

Description and priority

When a decision is made to what a patient has been sick with, the Doctors will
prescribe medicine for the patient and this service will be checking the available
medicine and make the choices of the Doctor easier. The service will also replace
the paper work required previously for prescribing medicine by sending message
to the Pharmacies by including each and every detail about the prescription. The
pharmacists will also be tasked with receiving the messages and selling the
medicine for the patients. They will also be responsible checking medicine as
available or not. This service will be crucial because is a major part of the medical
system. This will be included in the mobile application.

3.3.11. Checking if Beds are available

Description and priority

When patients are required to be taken care of while getting beds which is
called the IPD, patients need to get beds with the minimum of time and this
service will be used to forward the patients to the available rooms and also save
the time of the doctors or other wards by making the checking of the beds
digitally.

6
 3.3.12. Authentication sub-system
Description and priority

When new doctors are hired in the hospital new account is created for them
by the administrator. It checks if one doctor registered before when they start to
create new account. User after being registered to the system by the administrator
can login to the account. System authenticates the given data for any errors and
displays error message if found any. The administrator is the one who can help to reset
the password if any lost.

3.4.Non-Functional Requirements
3.4.1. Performance Requirements
The system must be fast enough to let the data shared be viewed
instantaneously at the ward's office the data is sent to and also the system must be.
The system must also be accurate in saving the different types of data in order to
use the data when looked upon and to perform different operations. The system
should not create ambiguity since it is aimed at simplifying the job of the wards in
the hospital. The system must have help sections that create a better
understanding of the system.

3.4.2. Safety Requirements

Data should be checked by forms and the application that it is in appropriate
format for the database. It should be checked the system is efficient enough that it
won’t be a reason for patient’s life to be in danger in any way.

3.4.3. Security Requirements

The system should allow only the appropriate person with a correct log in to
obtain and make decisions only its part. The password of a user should not be
visible in any way for any one.

7
 Chapter Four
4. System Analysis and Modeling
4.1. Overview
In this part of the proposal, we will discuss the requirements and models of the system.
We will define the requirements and relations based on diagrams and descriptions. The
objective of this section is to clarify how the actual system will be implemented.

4.2. Scenario Based Modeling

4.2.1. Use case identification
• Create Account
• Login to Account
• Authenticate
• Display incorrect login
• Register Data
• Display patients that exist
• Search Data
• Display patient information
• Handle appointments
• Check availability of doctors
• Check availability of beds
• Send laboratory test request
• Send laboratory test results
• Track ICU patients
• Send patient’s data to specialist
• Send patient’s data to OR
• Send patient’s data to IPD
• Prescribe medicine

4.2.2. Actors List

• Administrators: personnel that oversee the activities and create new
accounts.
• OPD Doctors: use the system to perform major functionalities and
interact with other departments.

8
 • Cashiers and Card registering personnel: register the patient and their
data and send them to available doctors.
• Laboratory Technicians: send the lab tests to perform from the doctors
and return the results.
• Pharmacists: check for prescriptions from doctors and sell medicine to
patients.
• Surgeons: view and check surgery schedules and report the results to
doctors.
• Medical Director and Other Management Personnel: view stored data
and other operations in a specific amount of time.
• X-ray and Ultra-sound specialists: set schedules for these activities and
report the result to patients.
• Nurses: Check patient Vital and assist doctors

4.2.3. Use case Diagram

Figure 1

9
Figure 2 Main system use-case diagram

Figure 3 Admin’s Main Operations

10
 Figure 4 Authentication system

Figure 5 Patient data registration and Management

11
Figure 6 Interaction of departments with OPD doctors

Figure 7 OPD doctor’s interaction with another department

12
Figure 8 Departments interaction with the pharmacy

13
 4.2.4. Use case Description
Authentication

Use Case Name: Priority: High

Authentication

Actor: Administrator, User

Description: When new wards are hired in the hospital a new account is created for them by
the administrator. It checks for previously recorded data maybe if that doctor was that
hospital’s employee before. User/doctors after being registered to the system by the
administrator can login to the account. System authenticates the given data for any errors and
displays error message if found any.

Trigger: The user must be staff member of the hospital. When new employees of the
hospital that uses the system are hired. And when the registered users try to access their
account.

Related Use Cases: Check Existing user (extend relationship)

Pre-conditions: User must be employee of the hospital and have to be registered in the system.

Normal Course: 1. Actor opens system Information for Steps:

2. Actor presses “Create 1. Actor can Administrator trying to
Account” button register new employee or an already
registered user trying to log in.
3. Actor inputs information 2. A form will appear to be filled with
needed employee’s information
3. Employee will be registered in the
system

Alternative Courses:A1. Actor log into Account

Post-conditions: User will be able to use the system and access allowed functionalities.

Exceptions:1. Incorrect name and/or password.

2. Account doesn’t exist (Will create new account).

3. Actor forgets password (Send new password by Email).

Summary
Input Destination: Source: Output:

Employee’s data Create user Data will be saved on database

14
 Table 1 Authentication
Register Patient Data

Use Case Name: Register Priority: High

Patient data

Actor: Receptionist, Medical Wards

Description: This part of the system will try to replace the already existing way of data
registration and will register all the relevant information about a patient and store in a
database system. It is prioritized highly since this process will be crucial to all the other
processes that will be part of the system. This process will save the time, money and space
of the hospital by replacing the manual way of storage

Trigger: A patient comes to the hospital and wants to get the services by the hospital.

Related Use Cases: Display patient not found (extend relationship),

Pre-conditions: That specific patient must not be already registered.

Normal Course: Information for Steps:

1. Actor initiates system and input 1. Actor chooses to add data of patient
patient’s data. and inputs it and then the input data is
2. The input data is verified. validated and if the validation succeeds
3. The actor is notified of the successful data is added successfully and actor is
data registration. notified.

Alternative Courses: Display that data is not in correct format.

Post-conditions:

• The patient will be added to the database.

• The patient will have a digital Card number that identifies him/her.
• The patient will be forwarded to the Triage.

Exceptions: If the patient is already registered they will be made to pay the price of the
card if they come after a month of being registered.

Summary
Input Destination: Source: Output:
Patient information Register data of patient Data storage

15
 Table 2 Register Patient Data
Display patient information
Use Case Name: Display Priority: High
patient information

Actor: Receptionist, OPD doctors, Specialist Doctor

Description: When any actor of the use case searches for patient information and have
access to that patient’s data, the system displays the information required by the actor.

Trigger: Searching for patient’s information

Related Use Cases: Search data (include)

Pre-conditions: Patient must be registered and look for by the actor.

Normal Course: Information for Steps:

1. Actor initiated system and searches for 1. Patient will be checked in the
patient. database.
2. Information is displayed on screen. 2. The fetched information is displayed

Alternative Courses:A1. If patient is not registered, the system displays notification and
alternative to register the user as new.
Post-conditions: Information is displayed and manipulated as needed.

Exceptions: The patient’s information doesn’t exist:

1. Doesn’t exist message is seen

2. Send to Register user’s data

Summary
Input Destination: Source: Output:

Name or Phone number of Display patient information Information about the patient
patients

Table 3 Display patient information

Search data
Use Case Name: Search data Priority: High
Actor: Receptionist

Description: When any information about the patient is required it is looked up and displayed. It
will be sent to the needed doctor.

16
Trigger: When already registered patients come back again and their data is required.

Related Use Cases: Display patient information (include relationship)

Pre-conditions: Patient must be registered.

Normal Course: Information for Steps:
1. Actor initiates the Application 1. The attributes entered to search for will be
2. Actor goes to the searching bar and checked if they are valid.
enters the name or phone number of the
person they he/she wants. 2. Information is fetched from the database.
3. Information on the user is displayed if it 3. Notification will be sent that the
is in the database. information about the person is not found and
4. If information is not found, system will if they want it to be registered as a new
notify a message patient or user
Alternative Courses: A1. The needed information is not found and is to be registered as new.
A1.1. The data is entered and save in the database.
Post-conditions: Patient information is sent to the needed department

Exceptions: Patient is not registered so system goes to Register data and process continues.

Summary
Input Destination: Source: Output:
Name and phone number of Search data Information is displayed
patients

Table 4 Search data

Handle appointments
Use Case Name: Handle appointments Priority: Medium

Actor: Receptionist, Doctors and specialists.

Description: This use case will be used to record the appointment that patient has and look for
the appointment when the patient comes to attend that appointment and this part must be related
to other data of a patient.

17
Trigger: When a ward appoints a patient for some time.

Related Use Cases: Check availability of doctors

Pre-conditions: A diagnosis has been made and there's a need to monitor progress or when
some type of health service is given for a patient (like acupunctures and others).

Normal Course: Information for Steps:

1. Actor initiates system and presses 1. Receptionist registers patient’s data to
“Register data”. the system.
2. According to OPD doctor schedule, 2. Checks the doctor’s schedule and give
patient is given an appointment an appointment accordingly.
Alternative Courses:

Post-conditions: An addition will be made to the medical information of the patient.

Exceptions: If a patient comes after the appointment date, there will be mechanisms to
handle the particular situation and reschedule that appointment.

Summary
Input Destination: Source: Output:

Appointment date Handle appointment Date of appointment

Table 5 Handle appointments

Check availability of doctors

Use Case Name: Check Priority: High
availability of doctors

Actor: Receptionist, Liaison, Doctors

Description: The major task of this use case will be looking if the Doctors that generally
examine the patients are available or not by checking the available doctors and displaying
them. This function will make the patient experience in the hospital accurate and precise.

18
Trigger: After a patient is registered and ready for the next step.

Related Use Cases: Handle appointments

Pre-conditions: The patient must be previously registered in the system or refereed from
another health facility.

Normal Course: Information for Steps:

1. Actor initiates system 1. Receptionist registers patient in the
2. Doctors availability is checked system
3. Patient is sent to the available doctor. 2. Doctor’s availability is checked by the
(A1) receptionist from the system.

Alternative Courses:
A1. Actor initiates “Handle appointment” button and gives an appointment

Post-conditions: The patient is told the room number of the Doctor and taken there with the help
of the porters.

Exceptions: If one doctor is not available other doctors are checked if available and if no doctors
are available the patient will be told to wait.

Summary
Input Destination: Source: Output:

Doctor’s information Check availability of doctor Patient is directed to the doctor

Table 6 Check availability of doctors

Check availability of beds

Use Case Name: Check Priority: High
availability of beds
Actor: Liaisons, OPD Doctors

Description: This service will be used to forward the patients to the available rooms and also
save the time of the doctors or other wards by making the checking of the beds automatic.
This will be mainly involving the liaisons that will register as available or not .

Trigger: When a doctor orders the patient is best cared for by acquiring a bed.

19
Related Use Cases:

Pre-conditions: A patient must be examined by doctor.

Normal Course: Information for Steps:

1. Doctor registers the patient to be 1. Patient should be named inpatient by
inpatient the doctor.
2. check availability of beds 2. Nurses will check for availability of
3. Assign patient in available bed beds and sends the information back to
the doctors
Alternative Courses: If there is no available bed, schedule is set.

Post-conditions: The progress of the patient of will be closely monitored and will be forwarded
to other wards if necessary.

Exceptions: If beds aren't available the patient will be given a specific amount of time to wait or
if the patient's situation is critical referred to another hospital

Summary
Input Destination: Source: Output:

Doctor asks for availability of Check availability of bed If available, Assign bed to
bed. patient
If not available, appoint for
another time

Table 7 Check availability of beds

End laboratory test request

Use Case Name: Send Priority: High
laboratory test request

Actor: Doctors, Laboratory specialists, specialist doctors

Description: This system will aim to decrease the time taken during that laboratory process
by sending the types of lab-tests issued by the doctor and forwarding the patient to the
laboratory by the help of the porters. This will send a message to the lab-technicians and will
help them get the necessary materials ready until the patient arrives and will fasten the
process.

20
Trigger: When a doctor or specialist issues this lab-tests.

Related Use Cases:

Pre-conditions: The patient must be examined by some type of ward before this phase.
Normal Course: Information for Steps: Doctor fills the
patients form for tests that needs to be taken
1. Patient goes to appointed doctor.
and send to Laboratory
2. Doctor requests laboratory request to be
done
3. Send lab test request and patient’s
information to the Laboratory
Alternative Courses:

Post-conditions: The lab-tests will be returned by the laboratory.

Exceptions: Patients might not lab-tests and will not be having lab-tests.

Summary
Input Destination: Source: Output:

Patient’s test information Send laboratory test request Laboratory result of patients

Table 8 Send laboratory test request

Send laboratory test results

Use Case Name: Send Priority: High
laboratory test results

Actor: Laboratory, Doctors or specialists

Description: This use case will return the results of the lab-tests issued by the Doctors or
specialists or other wards. This will decrease the time taken to treat the patients and will lead to
the Wards to quickly diagnose the patient.
Trigger: When the lab-technicians finish the lab-tests issued by the wards.

Related Use Cases: Send Laboratory test request

Pre-conditions: Wards must issue a laboratory test.

Normal Course: Information for Steps: The Doctor requests a

lab test request so the laboratory makes the
1. Laboratory receives the Lab test request necessary tests and sends back the result to the
from doctor
doctor
2. Make the necessary tests
3. Sends Laboratory test results back to the

21
 doctor

Alternative Courses:

Post-conditions: The wards will analyze the results and will decide if further testing is
required or will prescribe medicine. And also, this phase might be followed by recording the
results of that patient.

Exceptions: No exceptions in this case.

Summary
Input Destination: Source: Output:

Patients test results Send lab test results Sending patients results to
doctor

Table 9 Send laboratory test results

Track ICU patients
Use Case Name: Track ICU Priority: Medium
patients

Actor: ICU wards, OPD doctor that follows up the patient

Description: When a patient requires intensive care the ward that is examining them will forward
the particular patient to the ICU and this function will inform The ICU team that a patient is on
his/her way to this department and will let them prepare the required items that will be used in
this phase. They will also be sending reports to the wards that are responsible for the patients by
always reporting the condition of the patient. Reports will be attached to the patient's file and can
be easily accessed.
Trigger: When a doctor analyzes the case of the patient and orders the patient requires
Intensive Care Unit (ICU).

Related Use Cases:

Pre-conditions: A patient must be examined by a doctor.

Normal Course: Information for Steps: Patient must be
registered in the system database as an ICU
1. Doctor directs patient to ICU ward
patient.
2. Patient is registered as an ICU patient
3. Keep track of medical information of
the patient
Alternative Courses:

Post-conditions: Will be monitored in a period of time and will be discharged if the patient's

22
situation improves.

Exceptions: No exception cases in this service.

Summary
Input Destination: Source: Output:
Patient information registered Track ICU patients Tracking patients progress in
as ICU patient ICU.
Discharging patient from the
ICU.

Table 10 Track ICU patients

Send patient’s data to specialist

Use Case Name: Send ID:UC-13 Priority: Medium
patient’s data to specialist

Actor: OPD Doctor, Specialist Ward

Description: When a patient’s case is typified as one category and is believed to better deal with
specialist wards or wards that use equipment that will further examine the patient the patient will
be forwarded to these wards. This function will record the sending of the patients in the
traceability report and will return results.

Trigger: When a ward issues that the patient requires these services.

Related Use Cases:

Pre-conditions: A patient is diagnosed by a ward and needs further examinations.

Normal Course: Information for Steps:

1. Patient is registered and appointed to 1. Patient will be assigned a specialist
an OPD doctor and registered on the system.
2. Patient is then diagnosed and sent to 2. All data with the ward doctor will
specialist for further treatment be sent to the specialist
Alternative Courses:

Post-conditions: Using the system returns of the results will be made to the ward that issued the
examinations or if possible, the ward will issue other examinations or prescribe medicine for the
patients.

Exceptions: Exceptions don't exist in this function.

Summary

23
Input Destination: Source: Output:

Patient’s information Send patient’s data to Specialist receives patient’s

specialist data

Table 11 Send patient’s data to specialist

Send patient’s data to OR

Use Case Name: Send patient’s data to OR Priority: High
Actor: OPD Doctor, Surgical wards

Description: This use case will make sure the available schedule and will help the ward book the
time and date of a surgery. This function must also help the surgery department receive the
request that a patient will require surgery and share the booked times, dates and rooms. The
department will also interact with the wards that ordered the surgery by passing on medical
information.

Trigger: When a doctor examines a patient and orders the patient to be operated upon.

Related Use Cases:

Pre-conditions: The patient must be examined by a Doctor and surgery rooms must be available
and the schedule must be set.

Normal Course: Information for Steps:

1. Request surgery ward for availability 1. Check if there are any available
operation rooms and doctors
2. Book time and date of surgery on
doctors’ schedule
3. Send medical history to the appointed
surgeon
4. Set appointment

Alternative Courses:
Post-conditions: The patients will be monitored and will be provided with other type of
medication if required.

24
Exceptions: No exceptions in this case.

Summary
Input Destination: Source: Output:

Patient medical history Send patient’s OR section

data to OR

Table 12 Send patient’s data to OR

Send patient’s data to IPD

Use Case Name: Send patient’s data to ID:UC-15 Priority: High
IPD
Actor: IPD wards, OPD Doctor
Description: This function of the system will allow the wards share the In patient’s medical
records with IPD department and also reporting of medical information to the department
that sent the patients to the IPD.

Trigger: When a doctor examines a patient and orders the patient to be cared for while
acquiring a bed,

Related Use Cases: Check availability of beds

Pre-conditions: The patient must be examined by a Doctor and beds must be available.
Normal Course: Information for Steps: Checking available
bed and admit patient in order of their situation
1. Patient is registered and appointed to an
IPD ward.
2. Patient will be admitted to the available
bed.
Alternative Courses:

Post-conditions: The patient will be monitored from the IPD department and will be given
additional services if required.
Exceptions: No Exception cases in this service

Summary
Input Destination: Source: Output:

25
Patient medical history Send patient’s Monitored and additional
data to IPD treatment will be given if
required

Table 13 Send patient’s data to IPD

Prescribe medicine
Use Case Name: Prescribe Medicine Priority: High

Actor: Pharmacies, OPD doctors, IPD Doctors and other specialists

Description: The service will also replace the paper work required previously for prescribing
medicine by sending message to the Pharmacies by including each and every detail about the
prescription. The pharmacists will also be tasked with receiving the messages and selling the
medicine for the patients. They will also be responsible checking medicine as available or not.

Trigger: When a patient is prescribed with medicine or when a medicine arrives to the hospital or
checkup of medicine is performed.
Related Use Cases: Check for availability of Medicine

Pre-conditions: The patient is diagnosed with a doctor or when check ups need to be
performed.

Normal Course: Information for Steps:

1. Actor refer laboratory result
2. Click “prescribe medicine” button
3. Insert the name of medicine.
4. Send to pharmacy ward
Alternative Courses: A1. If medicine is not available in the hospital pharmacy, prescribe
through paper for external pharmacy use.

Post-conditions: The patient will buy the medicine or the total number of medicines will be
updated.

Exceptions: If the medicine doesn’t exist the customer will be sent to an external pharmacy.

Summary
Input Destination: Source: Output:

Actor will insert medicine name Prescribe medicine Prescription send to laboratory

Table 14 Prescribe medicine

26
Check for availability of Medicine
Use Case Name: Check for Priority: High
availability of Medicine

Actor: Pharmacies, Doctors or specialists that prescribed the medicine

Description: This use case will allow the pharmacy tell or inform the ward that prescribed the
medicine if the specific medicine exists or not
Trigger: When a patient is prescribed with medicine or when a medicine arrives to the hospital or
checkup of medicine is performed.

Related Use Cases: Prescribe medicine

Pre-conditions: A patient is prescribed with medicine.

Normal Course: Information for Steps:

1. Search for medicine
2. Check for availability
Alternative Courses:
Post-conditions: The ward that issued the medicine will be informed.

Exceptions: If the medicine doesn’t exist the customer will be sent to an external pharmacy.

Summary
Input Destination: Source: Output:
Search for medicine Check for availability of Show if there is any needed
Medicine medicine in the stock or not
Add new arrived medicine in
the stock

Table 15 Check for availability of Medicine

27
4.2.5. Activity Diagram

4.2.5.1.Searching patient data diagram

Figure 9 Searching patient data diagram

4.2.5.2.Registering Patient data

Figure 10 Registering Patient data

28
4.2.5.3.Doctor Laboratory interaction

Figure 11 Doctor Laboratory interaction

29
4.2.5.4.Acquiring beds for patients

Figure 12 Acquiring beds for patients

30
4.2.5.5.Prescribing medicine for patients

Figure 13 Prescribing medicine for patients

31
 4.3. Behavioral Modeling
4.3.1. Sequence diagram
4.3.1.1. Authentication Diagram
The actor denoted as system user can be any ward that will use the system.

Figure 14 Authentication sequence diagram

32
 4.3.1.2.Patient Data registration diagram
The actor denoted by user can represent any ward that can add patient data.

Figure 15 Registering Data of patients

4.3.1.3.Ward and Lab Inter Communication
In this diagram major wards are wards that are able to share data with the laboratory.

Ward and Lab Inter Communication

33
4.3.1.4.Acquiring bed for patients

Figure 16 Acquiring bed for patients

4.3.1.5.Patient forwarding to specialists diagrams

Figure 17 Patient forwarding to specialists diagrams

34
4.4.State Diagram

4.4.1. Searching patient data

Figure 18 Searching patient data

35
4.4.2. Register patient

Figure 19 Register patient

4.4.3. Laboratory services

Figure 20 Laboratory services

36
4.4.4. Bed treatment

Figure 21 Bed treatment

4.4.5. Pharmacy services

Figure 22 Pharmacy services

37
4.5.Class-Based Modeling

4.5.1. Class Diagram

Figure 23 Class diagram

38
Chapter Five
5. System Design
5.1.System Decomposition

Figure 24 System decomposition

5.2. Module Description

Manage User

• Manage user account creation, update and removal

• Allows user to login
• Display incorrect login
• Retrieve user information when needed
• Module interface:
o Registration form
o Login form and authenticate user information
• Module Requirement:
o Valid input when user authentication and new account creation is required
from user

Registration

• Register all information of the patients when the patients come for first time.
Example: Name, Age, Sex , phone number, address
• Generate a unique card number for each patient after registration and send SMS
text for patient’s phone number.

• Module interface:

39
 o Patient registration form
o Interface for sending SMS
• Module requirement:
o Valid input information and save the information.
o Generate unique card number and send SMS.
o Forward the information and card number for required doctor.

Patient Management

• Manage patient data interaction among different wards.

• Module interface:
o Interface to write medical history
o Interface to refer for other wards
o Search patient’s previous data
o Display all patient information including medical history
• Module requirement:
o Sending data for other wards
o Adding and updating medical history
o Retrieve patient’s previous data

Laboratory

• Receive lab test request from doctors, generate the result and send to doctor
• Retrieve previous lab results according to patient card number.
• Module interface:
o Display lab test request
o Interface for adding the result
o Display Notification
• Module requirement:
o Receiving lab test from all wards
o Adding the result
Reception
• Handle patient appointments
• Check available doctors
• Module interface:
o Interface for searching and checking available doctors
o Interface for updating and adding appointment
• Module requirement:
o Properly add and update the appointment
o Listing available doctors

40
Pharmacy

• Receiving prescription from doctors

• Notify available medicine on the stock
• Module interface:
o Display for prescription
o Interface to notify available medicine
• Module Requirement:
o Listing available medicine on the stock
o Receiving prescription

5.3.Architecture of the system

5.3.1. Component Diagram

Figure 25 Component Diagram

41
 5.3.2. Deployment Diagram

Figure 26 Deployment Diagram

5.4.Database design

The users or wards of the hospital need to be registered and therefore the system
has a database called users and this database has two collections called Wards and Admin
.Most of the attributes in these collections are the same but the need to separate wards
and admins into two collections arises from the fact that wards are medical personnel and
they log-in based on their medical roles and admins are tech personnel that control
overall activities. The detail is described in the below diagram.

Figure 27 Users Database

42
The following diagram shows after a lab test request is sent a lab result sent back is
stored in a collection called lab result in a database called Laboratory.

Figure 28 Laboratory database

43
 The Medicine that is to be prescribed by a ward to the patients will be stored in a
database and the medicine will be stored in a data base called Medicine and in a
collection called prescription and in a collection called prescription.

Figure 29 Pharmacy Database

The following table contains the storage of appointments in the appointment database and
in the appointment collection.

Figure 30 Appointment Database

44
 The following diagram contains a diagram that describes how beds and how IPD
Department Data is stored and it is stored in a database called IPD and has two
collections namely beds and IPD.

Figure 31 IPD Department database

The below diagram describes how The Operation room data and schedule is handled and thus has
a database named OR and a collection named Rooms that represent each OR Room in the
department.

Figure 32 OR Database

45
Final Prototype

Figure 33 prototype screen shot

46