Chapter One: Introduction

This final year project is done on clinic management system for Kidanemihret clinic. Some of
the problems over look on the system are manual recording, ordering and managing of the some
working system. The way to solve or address such problem is computerizing (automating) a
system.

Background
In Bahir Dar, there are many Clinics which practice manual system for facilitating their service.
Among these Kidanemiret Clinic is one of the Clinics in Bahir Dar. Kidanemiret Clinic is a
private limited company located in Keble 4. Kidanemiret clinic was built in January 1997 E.C.

1.2.1 Mission
Provision of excellent, qualified and ethical hospital, pharmaceutical, educational and public
health services including research activities according the organizational values and principles.
1.2.2 Vision
To see self-reliant, healthy and productive community at one hand and strong outstanding health
institutes which engage in principles.

1.2 Statement of Problem

The paper based system currently in use cause many problems to the users. when the patient first
visit the clinic ,the nurse is require to fill in new medical card for the patient .This includes
some private information that can be obtain from patient’s identity card such name, identity card
number, date of birth, gender and mailing address. The nurse will pass this medical card to the
Doctor. After the doctor sees the patient, some diagnosis information treatment will be written
down on the medical card by the doctor. This medical card is passing to the dispensatory. After
patient getting their medicine, the nurse will keep the medical card on an organized rack based
on index of the card. Usually, this medical card is arranged in alphabetical order according to
patient’s name or reference number for each card. The need to search through the file for the
medical card that match the patient’s name for any subsequence visit of patient. This kind of
paper based system is tedious and plaguing. There are many problem that have been arising by
manual system, these are:

i. Insecure:-the medical card easily exposed unauthorized user.

ii. The can easily get the vital patient information from clinic because the medical card is
just kept on the rack without any security lock.
iii. Time consuming :-by using medical cards ,time are wasted when the medical card need
to pass from nurse to doctor and then to dispensatory be side that clinic also need to
spend time to organize the medical card from time to time.
iv. Space:-clinic needs to provide space to store these medical cards. When quantity of card
increases in every year, they need more and more space to store cards.
v. Redundant information:-sometimes patient can have more than one medical card.
vi. Limited capacity:-doctor can’t include other related information in card; the card just
includes some basic patient information, digenesis and simple treatment information.

1.3 Objectives
The project has both general and specific objectives here are the general objective and then
Specific objectives
1.3.1 General objective
The main objective of this project is to develop web based clinic management system for
Kidanemihret higher clinic.

1.3.2 Specific Objectives

In order to achieve the general objective the specific objectives are the following:-
 Reviewing how the current system works.
 Identify functional and nonfunctional requirement for the new system.
 Develop the system documentation with detailed UML specification.
 Design a new system that can overcome the problem of the current system.
 Implement and test the new system
 Deliver the new system to the user and recommended further work.

1.4 Methodology
1.4.1 Requirement gathering methods
Interview: To get the basic information and background information about the existing clinic
management system, the team had interviewed those who work in the clinic. We had interviewed
with the Kidanemihret clinic manager Doctor Mekonnen on November 12, 15 and 27.we asked
to Doctor Mekonnen about how the existing system works on the clinic and he clarify that the
clinic uses manual system by sending the coming patient to the Receptionist then the
Receptionist gives him/her a card number then the patient goes to the examiner room with his
form. The Doctor either orders a lab test or drug. If the Doctor simply orders a drug, the patient
goes to the pharmacy with the prescription form. If not, Patient goes to the lab technician with
his ordered lab request form then after testing, Patient goes back to the Doctor with its result
form. Then Doctor orders the drug.

Observations: We had used to gather additional data by observing the actual work being done by
the clinic. We observed that the Receptionist is very busy finding the patient card and
This makes time wastage for the patients who wait to be examined next

1.4.2 System Analysis and Design Techniques

Object Oriented Analysis (OOA):-used to model the function of the system (use case modeling),
find and identify the business objects, organize the objects and identify the relationship between
them and finally model the behavior of the objects.
Object Oriented Design (OOD):-Use software to refine the use case model, and to reflect the
implantation environment, model object interactions and behavior that support the use case
scenario, and finally update object model to reflect the implementation environment.

The tools that we have used to accomplish the project are;

Hard ware tools

 Laptop or desktop computers

 Flash disk
 CD

Soft ware

 Microsoft word 2010: it is software that we use to write our system documentation.
 Microsoft PowerPoint 2010: is software that we will use for presentation.
 Microsoft Visio 2007: is software which we used to draw unified modeling diagram.
Such as sequence diagram and state diagram

1.4.3 Implementation Methodology

Programming languages, tools and techniques will used for the development of the system:

 Notepad ++
 PHP (We use PHP language for the system development, and our system (software) `will
be compatable on all hardware platforms such as windows & linux)
 MySql server
 Apache server.
 Database Tool:- MYSQL
 WAMP: - to test each program

1.5. Feasibility analysis

Feasibility study is essential to evaluate the cost and benefits of the new system. On the basis of
the feasibility study decision is taken on whether to proceed or to cancel the project.
Need of the feasibility study:
It determines the potential of the existing system.
It used to determine/finds out the problem of the existing system.

To determine all goals of the new system.

It finds all possible solutions of the problems of the existing system

1.5.1. Economic feasibility

To identify the economic feasibility of the project the team has done cost-benefit analyses which
enable the team to specify the benefits and costs associated with the project. Since this project
already computerizes the existing system, by now the reduction of cost for materials used in
manual operation becomes beneficiary to the organization

1. 5.2.Technical feasibility
In our project the team uses languages such as HTML, PHP, JavaScript, and CSS to develop the
new system. Software we used are free we already have it and hardware such as computers,
network cable, flash, CD so hardware also available and the project is technically feasible.

1.5.3. Time feasibility

The purpose of assessing schedule/time feasibility is for us as system analyst, to gain an
understanding of possibility that all potential time frame and completion date schedule can be
meeting and that meet this date will be sufficient for dealing with the need of the organization.
So we can finish this project with in time that is planned.

1.6. The significance of the project

Some of the significances of the project are:
 Enables the customer’s to get fast access.
 Enables to generate reports periodically
 Protect unauthorized access(by secured the data base , password encryption)
 Avoiding improper resource consumption.
 Avoiding data loss because of improper data storage.
 Reduced overall the work load of the employees and patients in the clinic
 To make management easy to maintain record
 The management will find it useful to them as it help in daily activity in the clinic
1.7. Limitations of the project
At the end of this project the new functionality in each module will be able to solve many of the
problems in the existing system. But, even the proposed system will perform most of the
activities the system will not perform online patient registration, online payment, room
reservation and the system will not allow the clinic to communicate with other clinics and
hospitals.

1.8. The Scope of the project

The target users of the system are doctors, nurses or any office workers in the clinic. This project
is mainly emphasized on developing a system for storing patient record and report generating. It
also include some others functions that can help the target users to improve their performance.
The system will cover the following tasks:-

 Patient Registration: - Patient needs to register before use the facilities at the clinic. All
the information will be keeping in database.
 Employee register :-employee must register in system
 Medicine prescription - This module manages the medicine stock in the clinic. It will
show current quantity of medicine in the clinic. It includes the record search.
 Appointment: - This module manages appointment made by doctor to the patient
 Bill record: - the receptionist must record the payment after the patient treated.

1.9 organization of project

The project document is divided into four chapters for better understanding these are:-
 Chapter one focuses on introductory part as we have seen above.
 Chapter two of the document is all about the features of the system including description
of existing and proposed system, requirements like functional and nonfunctional
requirements, the analysis models like use cases, state chart, sequence, activity diagram,
analysis class model and CRC.
 Chapter three, on this chapter we discussed what the system design should look the user
interface, deployment, design class diagram and algorithm design.
 Chapter four the project document is about the system implementation & coding part of
the project. It clearly shows the interfaces, implementation, testing part of the project.
Chapter Two: System Features
2.1. Existing System Description
The existing system that has been practiced in Kidanemiret clinic is manual system and
registration and recording systems are monitored with paper work. Workers and patients are
moving by carrying documents from one room to another room in the clinic, workers
communicate manually. The major players of the current system are Examiners, Pharmacist, and
lab technician, Manager of the clinic and Patients.

The main role of Examiner is examining patient about their feeling of the pain, prescribing drug,
prescribing for laboratory test, writing refer and making appointment.

The main role of pharmacist is recording when new drugs are entered, view expiration date of
the drug, recording drugs when patients take and view available drugs.

The main role of lab technician is take samples from patients and test according to the order
given by the examiner then recording the lab result which will be sent back to the examiner.
The main role of system admin is register new employee and control activities in the clinic.

2.2. The proposed system

By carefully analyzing and observing the problem of existing system we came up with a solution
that the current manual system should be computerized. The computerized system will
eliminate/reduce the problem on time, work load and complexity on storing drugs information
and patient information. The system will include a database for recording the patients that
facilitate fast information retrieval, modifying, inserting and deleting. It also includes an
attractive user interface that facilitates accessing the database.

The system gives a card number to each of the patient registered in the clinic. So that it is easy to
work with all the processes in the clinic. The user registers the patients so the system will give a
card number to the patient. Based on the card number the Doctor will record the patient
information on to the system .If laboratory test is necessary then the patient goes to the Lab
Technician and tells the card number so that the Lab Technician can see the patient information
on the system that the Doctor fills. So based on the Doctor order to the laboratory, the Lab
Technician test the requested sample. Then fill the patient information on the system so the
doctor sees and prescribe drug so the pharmacist give the drug to the patient based on the order
of the doctor.

2.3. Requirement analysis

2.3.1. Functional Requirement
Functional requirement defines a function of a system and its components. A function is
described as a set of inputs, the behavior, and outputs

Login

The system only can access by the authority user which is an official clinic staff who is
registered. The authority user must use username and password to login to the system. Validation
on username and password that input is required to deny the invalid user login to the system.

Record diagnosis result

The system should allow to the doctor write the examination result to the system.
Order lab result request

The system should allow that the doctor order lab request to the lab technician.

View lab result

The system should allow that the doctor view the lab result which is written by lab technician.

Give appointment

The system should allow that the doctor give an appointment to the receptionist

Prescribe medicine

The system should allow the doctor prescribes the available medicine to the pharmacist and
reception based on his/her examination result.

Create account

The system should allow the system administrator to create account for employee.

Update account

The system should allow update employee account.

Update employee information

The system should allow the system admin update the employee information to the system.

Register employee

The system shall allow to the administrator register the employees to the system.

.Record lab result

The system shall allow the lab technician record all appropriate patients’ lab result information.

View lab request

The system shall allow the lab technician can view the lab order which is sent by doctor..
View prescription

The system shall allow the pharmacist and view prescribed drug which ordered by the doctor.

Add drug

The system shall allow pharmacist to add drug information.

Delete drug

The system shall allow the pharmacist remove the drugs that are expired.

View appointment

The system shall allow the receptionist view the appointment and other information.

Register patient

The system must allow to receptionist to register the new coming patient to the clinic.

Prepare bill

The system also must allow to the receptionist to made payment record after the patient visited or
seen by the doctor so as to go the pharmacist to get the medicine based on doctor order..

Logout

The system should allow to all the actors or system user logout form the system after they
finished their task or activity in order to secure their system from unauthorized user.

1.3.2. System use case

1.3.2.1 Use case diagram

A use case diagram describes how a system interacts with outside actors. It is a graphical
representation of the interaction among the elements and system. Use case identifies the
functionality of a system.
The use case diagram models the user’s expectation for using the system. The people and
systems that interact with the system are called the actors. The features of the system that the
actors use are called the use cases.

 Use cases. A use case describes a sequence of actions that provide something of
measurable value to an actor and is drawn as a horizontal ellipse.
 Actors. An actor is a person, organization, or external system that plays a role in one or
more interactions with your system. Actors are drawn as stick figures.

Identified actors that will be participating in the system are:-

1. Doctor/Examiners
2. Lab technician
3. Receptionist
4. Pharmacist/Dispensary
5. Admin
6. nurse

List of use case

1. Login
2. Create account
3. Register employee
4. Deactivate account
5. Update account
6. View lab request
7. Record lab result
8. Prepare bill
9. update patient info
10. View appointment
11. Prescribe medicine
12. Order lab request
13. Record diagnosis result
14. Give appointment
15. View lab result
16. Add drug
17. View bill
18. Delete drug
19. View prescription
20. Make pre patients diagnosis
21. Logout
22. Update account
 Web based clinic management system
create account

Logout
prescribe medicine Register emloyee
information

<<include>>
order lab request deactivate
<<include>> employee account
<<include>> <<extends>>

<<include>> <<include>>
Record diagnosis
<<include>>
<<include>>
Doctor <<include>>
give appointment Login
<<include>>
<<include>>
view lab result <<include>>
<<include>> <<include>>
View lab request
add drug <<include>>
<<include>>
<<include>>
<<include>> record lab result
delete drug <<include>>
<<include>>
<<include>>
<<include>>
Record patient
la
pharmasist information

update account Prepare Bill

view Bill
Update patient Recie
Nurse information

make pre
patient¶s diagnosis view prescribed
drug view appointment
Figure 1 Use case diagram

1.3.2. System Use-case Documentation

Number UC -1
Use case name Login
Actor All actors or system users
Description All actors login using his/her own user name and Password
Precondition All actors open the system who wants to login.
Basic course of action User Action System response
1. All actors are on the homepage and 2. The system displays
wants login to the system and press the login form.
login link. 5. The system checks
3. All actors should enter their own user validity of user name
name and password. Password.
4. Then the user click login button. 6. If user name and
7. Then the use case end. password correct go to
the required page.
Alternative course of If the user name and password is not correct reenter the correct
Action user name and password.
Post condition Display the required page wanted by system user or actors.

Table 1: use case description for login

 Number UC -2
Use case name Register employee
Actor Admin
Description System admin registers the employees using the system.
Precondition The employee available and System administrator
authenticated to login.
Basic course of action User Action System response
1. System administrator open the 2. The system will
registration page display the form.
3. The System Administrator fill 4. The system
Employee Information on the validates the entries.
displayed form and then click the 5. the system will
add button. record the
4. end use case information into the
database

Alternative course of
Action 5. If the entries are correct, the information recorded
successful to database.
6. if not correct, return user action step 3
Post condition Employee registered and the user logout from the system
Table 2: use case description for register employee

Number Uc-3

Use case name Create account

Actor Admin
 Description The System Administrator creates account to the system users so as
to protect unauthorized system user

Pre-condition The System Administrator is authenticated and login to the system.

Basic course of action User action System response

1. System administrator open 3. The system display and stores the
the create Account page user information.
2. The System Administrator 4. The system validates filled entry
fill the necessary data of the and confirms the account.
user on the displayed form to
the system.
5. System administrator gets
the confirmation.
6.Then end use case

Alternative course of action 1. If Invalid entry will prompt error message.

2. If valid data format will prompt successful message.
.
Post condition The system admin create account for the user and logout from the
system
Table 3: use case description for create account

Number Uc-4

Use case name Update account

 Actor All actors

Description The actors update their account so as to protect unauthorized system user

Pre-condition The accounts should store in the database and users use uc-1.

Basic course of action User action System response

1. System user open the update 2. The system displays the system
Account page update form.
3. The system user fills the 5. The system validate the form filled
necessary data of the user on the entries to check correct or not the
displayed form. user entries
4. System user press the update 6. The system updates the user
button account in to the database.
7. Then end use case.

Alternative course of 1: if Invalid entry will prompt error message.

action 2: valid data format will prompt successful message.
.
Post condition The system user finish his or her own task or info updated and logout
from the system
Number UC -6
Use case name Deactivate employee account
Actor System Administrator
Description Allow System Administrator to deactivate employee account
Precondition The System Administrator must login in to the system.
Basic course of action User Action System response
1.The System Administrator login to the system 3. The system will display user
2. The System Administrator requests to deactivate interface to deactivate
employee account employee account.
4. System Administrator searches the employee id or 6. The system displays that the
the name of the employee employee account is
5. The System Administrator click on deactivate successfully deactivated.
account button.
4. Use case ends.
Alternative course of Invalid data entry
Action 1. The system displays an error message to the user.
2. The system indicates to retry.
Post condition The employee account will be deactivated.

Table 5: use case description for Deactivate employee account

Number UC -6
Use case name View bill
Actor Pharmacist
Description The pharmacist views the patients’ payment using the system.
Precondition Patient payment must store in the system and pharmacist uses
the uc-1(login use case).
Basic course of action User Action System response
1. The pharmacist login to the 2. The system will display or
system. fetch the patients’ bill form.
3. Then the pharmacist clicks 4. The system validates the
the view button. action weather it is in the
5. The pharmacist views the database or not.
displayed or sent information.
6. Then end use case.
 Alternative course of If when the view button clicked is incorrect the system will
Action display error massage.

Post condition Bill payment information viewed successfully by the

pharmacist.
Table 6: use case description for view bill

Number UC -7
Use case name Record lab result
Actor Lab technician
Description The lab technician records his or her own patient’s lab result using the
system.
Precondition The pre lab result available conditions should fulfill and lab technician
uses the uc-1(login use case).
Basic course of User Action System response
action
1. Lab Technician login to the system. 3. The System displays
2. The Lab Technician clicks on the Record lab result record form.
Lab Result button.
4.Lab Technician enters required
information via record result form
5 .The Lab technicians submit the 6. The system checks
information. validation of inputs.
 7. The system displays
that the lab result
8. Then end use case. recorded successfully.
Alternative If there is a mistake in the input. The system displays error message
course of and allow making correction.
Action
Post condition The lab technician done the task and logout from the system so as to
not access by the unauthorized user.
Table 7: use case description for record lab result

Number UC -8
Use case name View lab request
Actor Lab technician
Description The lab technician views patient’s lab request using the
system.
Precondition The doctor sends lab request to lab technician and user
uses login use case view the request.
Basic course of action User Action System response
1. The lab technician opens 2. The system will
the view patient lab request display the doctors
form. request form.
3. The lab technician fill or 4. The system validates
select what he want to view the selection entries.
Patient’s lab result 5. The system fetches
Information on the displayed and shows the required
form and then click the view information or data from
button. the database.
6. Then end use case.
 Alternative course of 1. If the selection entries from the form are correct, the
Action information or data viewed successful from DB or
fetched and showed to form page.
2. if not correct, return user action step 3 correctly
Post condition The lab technician viewed successfully and logout from
the system so as to not access by the unauthorized user.
Table 8: use case description for view lab request

Number UC -9
Use case name make pre patient’s diagnosis
Actor Nurse
Description The nurse gives pre patient’s diagnosis using the system.
Precondition The give pre patient’s diagnosis record should store in
database, and then the nurse uses the uc-1(login use case)
Basic course of action User Action System response
1. The nurse opens the pre 2. The system will
patient diagnosis form. display the patient
3. The nurse fill diagnosis before doctor
Patient’s health form.
Information on the displayed 4. The system validates
form and then click the submit the filled entries.
button. 5. the system save the
information into the
6. Then end use case. database

Alternative course of 1. if the fill entries from the form are correct, the
Action information or data submitted successful to database
2. if not correct, return user action step 3 correctly
 Post condition Nurse done the task and logout from the system so as to not
access by the unauthorized user.
Table 9 use case description for make pre patient diagnosis

Number UC -10
Use case name Register patient
Actor Receptionist
Description The receptionist records or register patient using the system.
Precondition The patient should arrive to the receptionist and the
receptionist uses the uc-1(login use case).
Basic course of action User Action System response
1. The receptionist opens the 2. The system will display
patient registration form. the patient registration
3. The receptionist fill Patient’s form.
information on the displayed 4. The system validates the
form and then click the filled entries.
add/register button. 5.The system should
added or register the
information into the
6. Then end use case. database

Alternative course of 1. if the fill entries from the form are correct, the information
Action or data added successful .
2. if not correct, return user action step 3 correctly

Post condition The receptionist registered the patient successfully and logout
from the system so as to not access by the unauthorized user.
Table 10 use case description for register patient
 Number UC -11
Use case name View appointment
Actor Receptionist
Description The receptionist views the appointment given by the doctors’
using the system.
Precondition Appointment should give by the doctor and use the uc-1(login use
case).
Basic course of action User Action System response
1. The receptionist login to the 2. The system will display or
system. fetch the patients’ appointment
3. Then the receptionist click form.
the view (submit) button. 4. The system validates the
5. The patient views the action weather it is in the
displayed or sent information. database or not.
6. Then end use case.

Alternative course of If when the view button clicked is incorrect the system will display
Action error massage.
Post condition Then the receptionist viewed doctor’s appointment and logout
from the system
Table 11 use case description for view appointment
 Number UC -12
Use case name prepare bill
Actor Receptionist
Description The System allows cashier to insert the cost of the given treatment.
Precondition The patient must be examined or have lab result
Basic course of User Action System response
action
1. The receptionist login to the 3. The system will display
system. payment form.
2. The receptionist clicks on the 4. The system validates the filled
prepare bill button. entries.
5. The receptionist fill the data to 6. The system displays
form preparation is successful.
7. Then end use case.
Alternative course of 1. If the filled entries are incorrect the system will display error
Action massage.
2.If it is not correct go to again step 3
Post condition The receptionist prepares the bill.

Table 12: use case description for prepare bill

 Number Uc-13
Use case name Order lab request
Actor Doctor
Description Informing the lab technician to test the doctor investigation

Precondition The disease must require laboratory examination and

Or the doctor uses use case(1)
Basic course of action User Action System response
1 A doctor opens the system 3. The system sends type of
and order to laboratory form. test to lab. Technician.
2. A doctor fills the form and 4.The system display
click submit button. successful message
5. Use case ends.

Alternative course of If the doctor not filed out the form back to basic course of
Action action 2.

Post condition The patient information sends to the lab technician. And the
doctor logout from the system

Table 13: use case description for order lab request

Number Uc-14
Use case name prescribe medicine
 Actor Doctor
Description The doctor prescribes medicine and the pharmacist view the
prescribed medicine by the doctor.

Precondition The patients treatment result should available and the doctor uses
use case(1)
Basic course of action User Action System response
1 A doctor opens the order 3. The system sends type of
drug page. ordered drug to pharmacist.
2. A doctor fills the form and 4. the system display successful
click submit button. message
5. end use case

Alternative course of If the doctor not filed out the form back to basic course of action
Action
Post condition The drug prescription sent to the pharmacist

Table 14: use case description for prescribe medicine

Number UC -15
Use case name record diagnosis result
Actor Doctor
Description The doctor writes the patient treatment result using the system.
Precondition A doctor writes treatment result situation should available and use
 the uc-1(login use case).
Basic course of action User Action System response
1. The doctor open the patient 2. The system will display
examination result information the form.
form 5. The system validates the
3. The doctor fill Patient treatment entries.
result on the displayed form and 6. the system will record the
then click the submit button. information into the database
7. end use case
Alternative course of 1. if the fill entries are correct, the information recorded successful
Action to database
2. if not correct, return user action step 3
Post condition The doctor recorded the information and logout from the system
so as to not access by the unauthorized user.
Table 15: use case description for record diagnosis

Number UC -16
Use case name Give appointment
Actor Doctor
Description The doctor writes or sends patient appointment to the receptionist
for arriving date using the system.
Precondition A doctor gives appointment conditions should available and user
use the uc-1(login use case).
Basic course of action User Action System response
 1.The doctor open the patient 2. The system will display
appointment information form the form.
3.Doctor fill patient appointment 5. The system validates the
on the displayed from and then entries.
click the submitted button 6. the system will record the
7. then end use case information into the database

Alternative course of 1. if the fill entries are correct, the information recorded successful
Action to database
2. if not correct, return user action step 3

Post condition The doctor recorded give the appointment information

successfully and logout from the system so as to not access by the
unauthorized user.
Table 16: use case description for give appointment

Number UC -17
Use case name View lab result
Actor Doctor
Description The doctor views the lab result of patients’ that send by the lab
technician using the system.
Precondition The lab result should send by the lab technician and user login in
to the system
Basic course of action User Action System response
1. The doctor open the lab 2. The system will display
technicians’ patient lab result the form.
information form 5. The system validates the
 3. The doctor select patient lab entries.
results on the displayed form and 6. The system will fetch the
then clicks the view button. information from the
7. then end use case database.
.

Alternative course of 1. if the fill entries are correct, the information fetch and viewed
Action successful to the user
2. if not correct, return user action step 3
Post condition The doctor views the lab result information successfully and
logout from the system so as to not access by the unauthorized
user.
Table 17: use case description for view lab result

Number UC -18
Use case name Add drug
Actor Pharmacist
Description pharmacist Add drug to the database
.
Precondition The drug must available and pharmacist log in to the system.

Basic course of User Action System response

action
1. Pharmacist open add drug page. 2. The system will display
3. Pharmacist fills and adds the drug by their the available page.
drug name. 4. The system stores the
5. The pharmacist add Drugs drug in to the system.
7. then end use case .
 Alternative 1. If the fill entries are correct, the information added successful to the
course of database.
Action 2. if not correct, return user action step 3
Post condition Pharmacist add drug in to the database and logout from the system

Table 18: use case description for add drug

Number UC -19
Use case name delete drug
Actor Pharmacist
Description pharmacist delete the expired drug in the pharmacy database

Precondition The drug list must store in the database and the actor must login in the
system
basic course of action User Action System response
1. Pharmacist open search drug page. 3. The system will display the
2. Pharmacist searches the drug by available drug.
their drug name. 5. The system will validate the
4. The pharmacist Delete Drugs selection to delete drug.
7. Use case ends. 6. the system delete the drug that
have been store before
Alternative course of If the drug is not available the pharmacist back to basic cores of action 2.
Action
Post condition Pharmacist deletes drug from the database and logout from the system

Table 19: use case description for Delete drug

Number UC -20
Use case name view prescribed drug
Actor Pharmacist
Description The system allows pharmacist or receptionist to View the drug prescribed by the
doctor.
Precondition The doctor must prescribe the drug

Basic course of User Action System response

action
1. The receptionist or pharmacist login to the 3. The System orders to insert Card
system. number or first name of the patient.
2. The receptionist or pharmacist clicks on 5. The system checks validation of
the view prescribed drug button. inputs.
4. The receptionist or pharmacist inserts card 6. The system displays prescribed
number or first name of the Patient. drug.
7. Use case ends.
Alternative If there is a mistake in the input
course of action 1. The system displays error message and allow making correction.
 2. The patient is not registered..
Post condition The Receptionist and pharmacist view the prescribed drug respectively.

Table 20: use case description for view prescribed drug

Business Rules
The business rules works as follow:

BR1: Once a patient visit to the clinic, and registered in to the system.

BR2: the doctor gives patient appointment to the receptionist.

BR3: The patient goes to Examiner room.

BR4: After this the Examiner diagnoses the patient and decides one of the two activities.

 The patient directly goes to pharmacist.

 If the patient requires laboratory examination the patient goes to laboratory
room.

BR5: If the Examiner orders a laboratory test the patient goes to the laboratory test.

BR6: The patient gives sample for laboratory technicians.

R7: The lab technician diagnoses the patient with patient’s blood or urine or other samples, as
the examiner writes a request form.

BR8: Then the patient takes the result of laboratory request to the examiner.
BR9: The examiner prescribes appropriate drug to the disease.

BR10: the receptionist takes money from the patient according to the doctor prescription.

BR11: Finally the patient goes to pharmacist and takes the drug.
2.3.4 User interface prototype

Main menu

Home About as Login Contact as

System
Doctor Receptionist Administrator pharmacist Lab technician Nurse

Prescribe Record patient Create Record lab

Add drug result Make pre patient
medicine information account
diagnosis

Order lab Update patient Register View lab

information Delete drug request
request employee

View lab
result Prepare bill View bill
Deactivate employee
account
Give View
appointment apointment

Record
diagnosis

Figure 2: User interface prototype

2.3.5 State Chart Diagram
State chart diagram is one of the five UML diagrams used to model dynamic nature of a system.
They define different states of an object during its lifetime and changed by events. It describes
the flow of control from one state to another state. States are defined as a condition in which an
object exists and it changes when some event is triggered. Its purpose is to model life time of an
object from creation to termination. It describes different states of a component in a system.

change
use open update account
create
[Login]

[Logout]
create acount
save

save
close

Figure 3: state chart for account

 register
open register patient
update

update patient information

save

patient registered
save

close

Figure 4: state chart for patient registration

 provide prescribe
lab request open medicine
click view
give
Lab result

appointment
sent display lab result info
send
sent
Receiver
close

Figure 5: State
chart for Doctor

2.3.6 Activity Diagram

An activity diagram is used to model a large activity's sequential work flow by focusing on
action sequences and respective action initiating conditions. An activity diagram is represented
by shapes that are connected by arrows. Arrows run from activity start to completion and
represent the sequential order of performed activities.
Activity Diagram 1: Login Login

Display login page

Enter user name and password

verifiy user name and password

[invalid]
prompt error message
[valid]

Display main main menu

Figure 6: Activity Diagram for Login

 Activity 2: Register employee

Open Home page

Login

Display employee registration form

Fill /enter employee information

click submitted button

Check validate

[invalid]
display error massege

[valid]

submit and store to databse

Registered successfully

Figure 7: Activity Diagram for Register Employee

 Create Account

Login Into System

Click Create Employee Account title link

Input the Required

Click Create Employee Account Button

[Invalid]

[Valid]

account created

Figure 8: Activity Diagram for create account

 Deactivate Account

Open Web Page

Login To System

Click Deactivate Account Link

Enter Emp-Id On the Search Box

Click on Search Button

[Not Found]

[Found]

Click Deactivate Button

Figure 9: Activity Diagram for deactivate account

Figure 10: Activity Diagram for Record lab result
 Activity 6:view lab request

Open home page

Login

display view lab lab request page

enter lab result data & click subbmit button

validate/varify

[if lab requist is not sent]

no lab request message response
[if request sent]

display the requested data to destination

Figure 11: Activity Diagram for view lab request

 Activity 7:view lab result

open home page

login

diaplayViewLabResultPage

click or press the view button

display the sended lab result

obserb the diplayed data and take info

Figure 12: Activity Diagram for view lab result

 Activity 9: register patient

open web page system

Login

display patient registeration form

enter /fill patient info_display

click submit button

validate the input(entery)

[invalid]
display error promput message
[valid]

Data stored in DB

display successefully

Figure 13: Activity Diagram for Register patient information

 Give appointment
open home page

Login

Click give appointment button

Display give appointment form

Enter Required information information

Is entered information valid

[Invalid]

[valid]
Appointment successfully

Figure 14: Activity Diagram for appointment

 prescribe medicine
open home page

login

displaydrug prescribe form

enter data & click subbmit/send button

validate or verfy the input data

[invalid]
display error message on the form

[valid input]

display correct message response on the form

prescribe successful

Figure 15: Activity Diagram for Prescribe Medicine

2.3.7 Sequence diagram
Sequence diagram is one kind of interaction diagrams, which shows an interaction among a set
of objects and their relationships. The purpose of the Sequence diagram is to document the
sequence of messages among objects in a time based view. The scope of a typical sequence
diagram includes all the message interactions for a single use case.
 HOME PAGE gotoDifferentPage
LOGIN PAGE
login All actor <<UI>> <<UI>>

open web page

go to login page

go to required

invalid
enter user name and password

clik login button

display required task
create account
Admin Home page Login page Create acccount Database
<<actor>> <<UI>> <<UI>> <<UI>>

open home page

go to login page

enter user name & password

invalid

create account
fill the form

click submit button stired to DB

successfully created
register employee Admin Home page Login Register form DB
<<actor>> <<UI>> <<UI>> <<UI>>

open home page

login

stored to DB
enter user name & password go register form

fill the form invalid

registered

submit the form

successful
register patient

Receptionist Home page Login form Register form

<<actor>> <<UI>> DB
<<UI>> <<UI>>

open home page login go register form stored to DB

invalid
enter user name & password

registered

fill the form

submit the form

successfullyStore
prepare bill
Receptionist Home page Login page Prepare bill form DB/server
<<actor>> <<UI>> <<UI>> <<UI>>

open home page login go prepare form insert to DB

invalid
enter user name & password

fill the form and click submit button

saved

success
makePrepatientDiagonisis

Nurse DB/server
Home page Login form Record form
<<Actor>> <<module>>
<<UI>> <<UI>> <<UI>>

login make record stored to DB

open home page

invalid

enter user name & password

fill the form

saved
click submit the form

successful
 Lab technical
<<actor>> Record lab result
Home page Login form DB
form
<<UI>> <<UI>>
<<UI>>

record lab result

login go register form stored to DB
open home page

invalid

enter user name & password

fill the form

recorded
click submit the form

successful
view lab result Doctor DB
Home View form
<<actor>> Login form <<module>>
<<UI>> <<>>

open home page login go view form/button

fetched info

invalid
enter user name & password

search by key & click vieww button

successfully given
 Doctor DB
Home page Login form Prescribe form
<<actor>> <<module>>
<<UI>> <<UI>> <<UI>>

prescribe medicine/drug

login prescription form sent to db

open home page

invalid

enter user name & password

saved
fill the form

click submit the form

successful
 Pharmacist, recepttionist
Login form DB
<<actors>> Home page
<<UI>> Prescribe page <<module>>
<<UI>>

view drug prescription

open home page

login
go view page fetched info

enter user name & password invalid

search by key/other & click vieww button

fetched
add drug
Pharmacist Home page Login form Add drug form Database
<<actor>> <<UI>> <<UI>> <<UI>>

open home page login go register form stored to DB

invalid
enter user name & password

registered

fill the form & click login button

submit the form

successful
give appointment Doctor Give appointment
Home page Login form Db/server
<<actor>> Form
<<UI>> <<UI>>
<<UI>>

open home page login

stored in

go register form invalid

enter user name & password

ienserted
fill the form and click submit button

successfully given
2.3.8 Analysis class model

Employee
employeeId
firstName Account
lastName firstName
phone lastName
has userName
age
sex age
1 1..* manage
department sex
login() password
1
logout()

1
LabTechnicial reciptionist pharmacist
Doctor
SystemAdmin
addLabOrder() registerPationt() viewDrugPrescription()
giveApointment()
viewLabRequeest() prepareBill() addDrug() createAccount()
recordDiagonsis()
11 updatePatient() 1 viewPaymentResult() registerEmployee()
1 orderLabRequst() add
updateAcccount() deleteDrug() updateEmployee()
viewLab result() 1 1 1..* deleteEmployee()
viewDrugprescription() updateAccount()
prescribeDrug() 1 1
1..* 1 1..* register updateAcount ()
view
1 1 1 1 1
1
nurse diagnoisis views view
p_id manages
prepare
giveNursingservice() prescribes p_f_Name
p_l_Name view
gives
1 1..* 1
view
view
orders Patient drug
1..*
1..* patientId drugId
1..* 1..* 1..* 1..* firstName drugName
Appointment 1..* 1..* lastName quality
p_name Bill age expiredDate
LabRequest
p_id Medicine sex drugType
p_f_Name billNumber
app_date p_name 1..* address totalAmountCost
p_l_Name patientName
app_time p_id 1..*
p_id
medicineName
LabOrderName
LabResult
p_f_Name
1..*
p_l_Name
gives 1..* NursingService p_id
p_f_Name labName
p_l_Name
p_id
p_result

1..*
2.3.9 Logic model
Algorithm/Pseudo code for each process

One common problem-solving technique includes analyzing a problem, outlining the problem
requirements and designing steps called an algorithm. Algorithms used to solve the problem. We
also write algorithm for some basic method using human language (pseudo code) in the
following way.

Register New Patient

Register New Patient ()

Display Register Patient Form

Accept input from the user

If "Insert" button is clicked

Check for validity of data entered

If invalid data is entered prompt the user to correct the error by displaying error message

If valid

Open database

Open patient table

Check the uniqueness of the patient card number entered

Else if the card number is not unique

Prompt the user to enter another card number

 }

Else

Insert the information filled out on the form into the table

Save change made to the table

Close the table

Close the database

Display message "Patient registered successfully"

Else if "clear" button is clicked

Clear all the inputs and refresh the form and display the form

End function

Login in to the system

Login ()

Display Login Form

Accept input from the user

If "Login" button is clicked

{
 Open database

Open account table

Check if user type and password is matched

If the if user type and password matched

Display user’s home page

Else If

Display error message

Close the table

Close the database

Else if "clear" button is clicked

Clear all the inputs and refresh the form and display login form

End function

Logout from the system

Input: user name and password

Output: logout from the system

Begin

Connect to database

If users and password matches database content

Begin if

If login status is on

Begin if

Set login status false

End if

Return true

End if
Else
Begin else
Display error message
Return false
End else

End
2.4 Non-Functional Requirement

Usability Requirement

The system will decrease the amount of text box that input by the user and increase the selection
input method such as combo box and radio button. Within this will eliminate the possibility of
entry error that made by the user when they enter record into the system. The system should very
straight forward to the user and easy to operate by the user.

Efficiency Requirement

The system must allow the staff to search the patient record in an easy and efficient way from a
large amount of data. The system response time must be fast and the system should allow the
user to open several task at one time when they using it.

Reliability Requirement

Make sure there is an additional server to back up the clinic data in case when the server is down,
there is still a backup server to support the system to continue running the daily business. The
error rate of this system must be shrinking. Furthermore, adequacy error message should prompt
to the user when there is any validation error occurred.

Security Requirement

The system must provide a highly security on protecting the patient privacy.

Some confidential data should restrict to only authorize user to access it.

2.5 System Requirement

2.5.1 Hard ware requirement

2.5.2 Software requirement

 2.6 CRC analysis

Pharmacist
Doctor
Id Drug
Id Diagnosis
firstName Bill
firstName Labrequest
lastName medicine
lastName Medicine
phone systemAdmin
phone Appointment
sex account
sex systemAdmin
age doctor
age account
salary
salary
viewDrugOrder()
giveAppointment()
addDrug()
recordDiagnosis()
viewDrug Prescription()
viewLabResult()
deleteDrug()
PrescribeDrug()
 BILL
MEDICINE
B_id Receptionist
PatientId Doctor
P_names Doctor
patientName Pharmacist
AmountCos Pharmacist
medcineName receptionist
t
patient

PATIENT NURSE
Id Receptionist Id Labrequest
firstName Bill firstName Patient
lastName Doctor lastName nursingService
sex Pharmacist phone systemAdmin
age Nurse sex
address medicine age

salary

giveNursingService()

NursingSevice

labRequest
P_name Nurse

Sevice_id Doctor Lab_id Doctor

resultName Patient P_F labTechinicial

name

P_Lname

labresultName
APPOINTMENT

P_Name Doctor
Employee
App_id Receptionist
Employee_Id Account
App_Date Patient
Receptionist
First name
App_time
Id Bill
Last name
firstName Medicine
Phone
lastName Appointment
Age
phone systemAdmin
Sex

department
sex

Login() age

Logout() salary

registerPatient()

prepareBill()

UpdatePatient()

viewPrescription()

viewAppiontment()
Chapter Three: System Design
3.1 Architectural Design

Software architecture is the process of defining a structured solution that meets all of the
technical and operational requirements, while optimizing common quality attributes such as
performance, security, and manageability. It involves a series of decisions based on a wide range
of factors, and each of these decisions can have considerable impact on the quality, performance,
maintainability, and overall success of the application.

Software architecture encompasses the set of significant decisions about the organization of a
software system including the selection of the structural elements and their interfaces by which
the system is composed; behavior as specified in collaboration among those elements;
composition of these structural and behavioral elements into larger subsystems; and an
architectural style that guides this organization

3.1.1 Component modeling

The Component Diagram helps to model the physical aspect of an Object-Oriented software
system. It illustrates the architectures of the software components and the dependencies between
them. Those software components including run-time, executable also the source code
components. The component diagram's main purpose is to show the structural relationships
between the components of a system.
 Data access
Appointment
Appointment

Data access
patient
patient

Data access Encription

Lab result Security<<Infrastructure>>
Lab result Access control

Data access
Lab request
Lab request

Data access
Medicine
Clinic management system Medicine
Peresistence<<Infrastructure>>
Peresistence

Data access
Diagnosis
Diagnosis

Data access
Drug
Drug

Data access
Bill
Bill CMS<<Database>>

Data access
Nursing serviece
Nursing serviece

Data access
User
user

3.1.2. Deployment Diagram

Deployment diagram show how the system is deployed on computers. It is used to show the
hardware of the system, the software that is installed in the hardware and also the middleware
that is used to connect the disparate machines to one and other. It also shows how the software
and the hardware components work together.
It also helps to model the physical aspect of an Object-Oriented software system. It models the
run-time configuration in a static view and visualizes the distribution of components in an
application. In most cases, it involves modeling the hardware configurations together with the
software components that lived on. Our project’s Deployment diagram looks like as follows:
3.2. Detail Design

3.2.1 Design class model

 Employee
#employeeId
#firstName : string Account
#lastName : string -firstName : string
#phone : int -lastName : string
has -userName : string
#age : int
#sex : char -age : int
1 1..* manage
#department : string -sex : char
+login() : void -password : string
1
+logout() : void

1
LabTechnicial reciptionist pharmacist
Doctor
SystemAdmin
+addLabOrder() : void +registerPationt() : void 1 +viewDrugPrescription() : void
+giveApointment() : void
+viewLabRequeest() : void +prepareBill() : void +addDrug() : void +createAccount() : void
+recordDiagonsis() : void
1 11 add +updatePatient() : void +viewPaymentResult() : void +registerEmployee() : void
+orderLabRequst() : void
+updateAcccount() : void +deleteDrug() : void +updateEmployee() : void
+viewLab result() : void 1
+viewDrugprescription() : void +updateAccount() : void +deleteEmployee() : void
+prescribeDrug() : void 1..*
1..* 1 1 +updateAcount () : void
register 11..*
1 1 diagnoisis 1 prepare
1 view
nurse 1 1 1
-p_id : string view manages
prescribes 1
-p_f_Name : string
+giveNursingservice() -p_l_Name : string 1..*
-diognosName : string drug
gives
-drugId : string
1 view view 1..* 1..* Patient
1..* -drugName : String
views view -patientId : string -quality : string
1..* orders -firstName : string
Bill -expiredDate : Date
1..* 1..* -lastName : string
1..* -billNumber : String -drugType : String
Appointment 1..* 1..* -age : int
-patientName : string -totalAmountCost : int
-p_name -amountCost : float -sex : char
LabRequest 1..*
-p_id : string Medicine -address : char
-p_f_Name : string +prepaireBill() : void
-app_date : Date -p_name : string
gives -p_id : string -p_l_Name : string
-app_time : Date LabResult
-p_id : string
- -medicineName : string
-LabOrderName : string -p_f_Name : string
+GiveAppointment() : void - 1..* -p_l_Name : string
-p_id : string
-labName : string

1..* NursingService
-p_f_Name : string
-p_l_Name : string
-p_id : string
-p_result : string
1..*

3.2.2 Persistent model

Persistence models are used to design the schema of your database. You typically need to draw a
Persistence model whenever you are using a relational database to store your objects in. The
strength of Persistence models is that data entities are conceptually the same as the tables of a
relational database and that attributes are the same as table columns.
 ExaminationResult
Column Name Condensed Type Nullable
Bill Doc_name varchar(30) Yes
Column Name Condensed Type Nullable
examRsult varchar(60) Yes
B_id varchar(25) No
p_id varchar(23) No
amoutCost float Yes
E_id varchar(25) Yes
E_id varchar(25) Yes
P_id varchar(25) Yes

Account *
Column Name Condensed Type Nullable
userName varchar(30) Yes

Durg acc_id varchar(22) No

Column Name Condensed Type Nullable password varchar(23) Yes
d_id varchar(15) No role varchar(10) Yes
p_name varchar(23) Yes
d_maufature... varchar(44) Yes
d_expiredDate date Yes DrugPrescription
Column Name Condensed Type Nullable
E_id varchar(25) Yes
P_name varchar(30) Yes
drugName varchar(60) Yes
Employee
Column Name Condensed Type Nullable p_id varchar(23) No
labresult E_id varchar(25) No E_id varchar(25) Yes
Column Name Condensed Type Nullable
firstName varchar(23) Yes
P_name varchar(30) Yes
lastName varchar(24) Yes
labResultNa... varchar(60) Yes
phoneNumb... varchar(33) Yes P_registration
p_id varchar(23) No
age int Yes Column Name Condensed Type Nullable
E_id varchar(25) Yes
sex varchar(4) Yes p_name varchar(23) Yes

salary float Yes lastName varchar(24) Yes

acc_id varchar(22) Yes addres varchar(33) Yes

age int Yes
Appointment
Column Name Condensed Type Nullable sex varchar(4) Yes

app_id varchar(13) No E_id varchar(25) Yes

app_date date Yes Labrequest

app_time time(7) Yes Column Name Condensed Type Nullable NursingService
E_id varchar(25) Yes labOrder_id varchar(15) No Column Name Condensed Type Nullable
p_name varchar(23) Yes N_name varchar(30) Yes
P_id varchar(44) Yes nurseRsult varchar(60) Yes
labOrdername varchar(100) Yes p_name varchar(23) No
E_id varchar(25) Yes E_id varchar(25) Yes
3.2.3. User Interface Design

Login form
KIDANEMIHRET CLINIC
LOGIN PAGE

User Name Admin

password

CANCEL

Forgot password
kidanemihret Higher clinic

Create account form

Fist Name

Last Name
MALE
sex FEMALE

25
DOB
Countery Ethiopia

phone +251

Password

Re-Password

create Cancel
KIDANEMIHRET HIGHER CLINIC MANAGEMENT SYSTEM

PATIENT REGISTRATION PAGE

First Name
Last Name
MALE

sex FEMALE

Age 25

date
woreda
kebele
subcity

Register Reset
Clinic management system
Form Title
Lab reqes
Create account f
Fist Name

Last Name
MA
sex FEM

Age
Orderd by
regNo.

date

TypeOf result
3.4. Access control and security
Access control is a security technique that can be used to regulate who or what can view or use
resources in a computing environment.
In our system, different actors have access to different functionalities and data. Therefore these
privileges put off unauthorized users from accessing data’s which they don’t have privacy to
access.

Authentication: The process of ascertaining that somebody really is who he claims to be. In these
system users before entering into the system they must be authenticated as authorized users. This
takes place by letting users to insert their username and password in the displayed login form.
Authorization: Permission to access a resource, rules that determine who is allowed to do what.
After authentication users are granted for specific tasks. This takes place by preventing users
from participating in specific tasks on which he/she doesn’t have grant to access.
 Class Account Patient diagnosi Lab Lab drug bill medicine Nursing
Actor s request result service
System Create()
Administrato Deactivate()
r Update()
Doctor Record() Order() View() Prescribe()
Receptionist Record() View() Prepare(
Update() )
Lab View() Record()
technician
Pharmacist Add() View
Delete( Prescription(
) )
Nurse Give()
Chapter Five: Testing and Evaluation
Software system testing

Test techniques
Unit testing

Unit testing is to make sure the module that been develop can run smoothly and executable
without any bugs or system error .unit testing basically will test on the particular part or unit such
as function, procedures, or modules. It is ensure that the particular function that that has been
developed can fulfill the requirement of the user and without any error. Unit testing is normally
test by the programmer who writes the code .every time after they had finished writing the code
they will run the debugger and test whether the function of source code run smoothly or not .if
they are bugs or system errors occur the developer will try to solve it and the debugger again.

If the function can run smoothly without error and can meet the required function, the developer
will test the whole module all over again.

Validation testing

Validation testing is one kind of the testing which will test on whether the system is able to
handle the wrong data that entered by the user or not. It also use to ensure that the data entered
by the user is relevant and in the correct format or correct data types. For this testing, we will test
whether the system can handle the data that entered by the users. For example if the user is
required to enter the numeric data but they are enter the string data ,will the system able to track
the data entered by the user and prompt error message to inform the user to enter the correct one.
This testing is very important because the wrong data entered may cause the system error or
accidentally insert the wrong data into the database and misleading the system.

User acceptance testing

User acceptance testing is testing to determine whether the system that had been developed is
satisfied and accepted by the user or not .it will carry out after all testing are done and will test
by user who will use the system.in this testing, the user also can decide whether the acceptance
level to the system or preps the user can provide some feedback to the programmer can make
enhancement on the system..