Haramaya university

Collage of computing and informatics

Department of Information Technology
Documentation for hospital management system
Group member Id
1. Abdu endris 2229/04
2. Habib shafi 2343/04
3. Tamirat ergado 2452/04
4. Tariku kebede 2454/04
5. Tekiya mifta 2460/04

ACKNOWLEDGMENT

1
 First and for most we would like to thank GOD for giving us the power and the strength
to accomplish this project. Our next deepest gratitude goes to Mr.Getahun for giving us this
project to acquire more knowledge on the course we are taking. In addition we would like to
thank Dr.Mohammed a person who works at Haramaya university hospital system, for giving us
the required information in our project. Finally we would like to thank all the people who helped
us to accomplish this project successfully.

2
Table of contents page
Abstract………………………………………………………………………………………………………………………………..…………… 6

Chapter1……………………………………………………………………………………………………………..…………….7
Introduction…………………………………………………………………………………………………………………………7

1.1 Background of the organization………………………………………………………………………………………7

1.1 Organization structure…………………………………………………………………………………………..….……8
1.2 Statement of the problem……………………………………………………………………………………………..8
1.3 Objectives of the project………………………………………………………………………………………..........9
1.3.1 general objective…………………………………………………………………………………………………….9
1.3.2 specific objective…………………………………………………………………………………………………….9
1.4 Methodology and tools…………………………………………………………………………………………………..10
1.4.1 System development methodology…………………………………………………………………………10
1.4.2 Data collection Methodology………………………………………………………………………………….11

1.5 Scope of the proposed System………………………………………………………………………………………..12

1.5.1 Scope in…………………………………………………………………………………………………………………….12

1.5.2 Scope out…………………………………………………………………………………………………………………..12

1.6 Significance of the project ……………………………………………………………………………………………..13

1.7 Feasibility Study……………………………………………………………………………………………………………….14

1.7.1 Operational feasibility……………………………………………………………………………………………….14

1.7.2 Technical feasibility……………………………………………………………………………………………………14

1.7.3 Schedule feasibility…………………………………………………………………………………………………….15

1.7.4 Economic Feasibility/cost benefit analysis…………………………………………………………………….15

CHATER 2………………………………………………………………………………………………………………………………..18

System Requirement Specification and Analysis modeling (SRS)…………………………………………….18

2.1 ACTORS……………………………………………………………………………………………………………………………………………18

2.2 Use case………………………………………………………………………………………………………………………………..…………18

3
2.3 Essential use case diagram……………………………………………………………………………………………………….………20

2.4 Essential use case description……………………………………………………………………………………………………….…22

2.5 Essential user interface prototyping………………………………………………………………………………………………..24

2.6 Supplementary specification……………………………………………………………………………………………………………33

2.6.1 Business Rules Identification…………………………………………………………………………………………………..33

2.6.2 Functional Requirements………………………………………………………………………………………………………..34

2.6.3 Nonfunctional Requirements …………………………………………………………………………………………………34

2.7 Activity diagram……………………………………………………………………………………………………………………………..36

Chapter 3………………………………………………………………………………………………………………………………………..37
DESIGN DOCUMENT……………………………………………………………………………………………………………………………………………37

3.1 Domain modeling with class responsibility collaborator (crc) cards…………………………………………………………….37

3.2 Sequence diagram……………………………………………………………………………………………………………………….38

3.3 User interface _flow diagram.…………………………………………………………………………………………………………………39

3.4colaburation……………………………………………………………………………………………………………………………………..40

3.5 user interface diagram………………………………………………………………………………………………………………..42

3.6 State chart…………………………………………………………………………………………………………………………………..45

3.8 Database diagram……………………………………………………………………………………………………………………….46

Chapter 4……….………………………………………………………………………………………………………………………………..48
4.1 sample code…………………………………………………………………………………………………………………………………….48

4.1.1 sample code home page……………………………………………………………………………………………………………….48

4.1.2 sample code for patient………………………………………………………………………………………………………………..49

4.1.3 sample code for drug…………………………………………………………………………………………………………………….50

4.1.4 sample code for patient registration…………………………………………………………………………………………….51

4.1.5 Registration…………………………………………………………………………………………………………………………………..52

4.1.5sample code for bed information…………………………………………………………………………………………………..53

4.2 testing and deployment…………………………………………………………………………………………………………………..53

4
4.3 user manual…………………………………………………………………………………………………………………………………….53

5
1. Abstract

The team has planned to develop Health Center Automation System for Haramaya University.
Currently this health center depends on a large amount of manual work. Development of a new
system will help this organization to minimize the work load they handle manually and to
eliminate the faults and problems of the existing system. This proposed system handles the
entire health center work load under different major functions namely; OPD Out Patient Door,
(Emphasize the meaning of this abbreviation), Medical laboratory, Pharmacy and stores,
(patient) report generation and Record Office. The new system will be having key benefits over
existing system such as; high performance due to the immediate updating service provided by
the system, access to fully detailed description about the patient regarding their medical
reports, reduce human effort. To do this project we use different methodologies to gather the
necessary information that are needed to develop our project. The methodologies that we are
used to gather the requirements are interview and the existing system documentation.

The project Haramaya University Health Center Automation System is for computerizing
the working in a health center. The software takes care of all the requirements of an average
hospital and is capable to provide easy and effective storage of information related to
patients that come up to the health center.

6
Chapter one
Introduction

1.1 Background of organization

Haramaya University (formerly known as Alemaya University) is one of the oldest universities in
Ethiopia. It is located in Haramaya, a town in the East Hararghe Zone, about 20 kilometers from
the city of Harar and 40 kilometers from Dire Dawa. The university was founded with the help
of Oklahoma State University (OSU), accepting its first students in 1954, and the new campus
was opened in January 1958 by Emperor Haile Selassie. Haramaya University was promoted
from a college within Addis Ababa University on May 27, 1985 to an independent university.
For many years the university had been limited to only an agricultural curriculum, but in 1996
the university was given permission to open other faculties and departments.

Presently, the university has three branches. These are the main campus which is found in
Haramaya town, Harar campus which is found in Harar town and Chiro campus which is located
in Chiro town. Among these branches our project is done on the main campus health center.
The health center was established by the university to provide health service to the community
of the university. Currently this health center depends on a large amount of manual work.
Development of a new system will help this organization to minimize the work load they handle
manually and to eliminate the faults and problems of the existing system. The new system will
be having key benefits over existing system such as; high performance due to the immediate
updating service provided by the system, access to fully detailed description about the patient
regarding their medical reports, reduce human effort .

7
1.2 Organization structure

The Haramaya university health center management system structure looks like the following.

Manager

Dental room OPD 1 and

Delivery Night duty
OPD 2
room

MCH

Dentist physician Nurse and

midwifery Doctor

Doctor or
nurse labratory
Laboratory
technician

TB Doctor
X-ray X-ray office
specialist
Counseling
and guidance nurse
doctor Emergency
room
Environmental Doctor or
health nerse

Fig 1.1 Organizational structure

1.3 Statement of the problem

Haramaya University health center faces different problems in services the community which
affect the efficiency of the center. These Problems are

 Lack of immediate retrievals:-The information is very difficult to retrieve

and to find particular information (e.g. To find out about the patient’s history,
the user has to go through various registers). This results in inconvenience and
wastage of time.
 Lack of immediate information storage: - The information generated by various
transactions takes time and efforts to be stored at right place.
 Lack of prompt updating: - Various changes to information like patient
details or immunization details of child are difficult to make as paper work
is involved.

8
  Error prone manual calculation: - Manual calculations are error prone and
take a lot of time this may result in incorrect information. For example
calculation of patient’s bill based on various treatments.
 Preparation of accurate and prompt reports: - This becomes a difficult task as
information is difficult to collect from various regist

1.4 objective of the project

1.4.1 General objective of the project

The overall objective of this project is developing automated system for the
existing system by changing the entire manual system into automated system and
increasing the activity of the health center in providing its service for patients.

1.4.2 Specific objective of the project

The specific objectives of this project are of the following:

 Planned approach towards working: - The data will be stored properly in

data stores, which will help in retrieval of information as well as its storage.

 Accuracy: - The level of accuracy in the proposed system will be

higher. All operation would be done correctly and it ensures that
whatever information is coming from the center is accurate.

 Reliability: - The reliability of the proposed system will be high due

the above stated reasons. The reason for the increased reliability of the
system is that now there would be proper storage of information.

 Reduce Redundancy: - In the proposed system no information is

repeated anywhere, in storage or otherwise. This would assure economic
use of storage space and consistency in the data stored.

9
  Immediate retrieval of information: - The main objective of proposed
system is to provide for a quick and efficient retrieval of information.
Any type of information would be available whenever the user requires.

 Easy to Operate: - The system should be easy to operate and should

be such that it can be developed within a short period of time and fit in the
limited budget of the user.

1.4 Methodology and tools

1.4.1 System development methodology

Many methodologies have been developed and introduced in order to implement SDLC (System
Development Life Cycle). Although each method follows certain different techniques and steps,
they are all must go into the same development phases (planning, analyzing, designing,
implementation) .There are many system development methods known today, but the
methodology we use is the structured Design one. Design

This method follows a step-by-step approach which moves logically from one phase to the next.
The works done in each phase need to be approved by the project sponsor (this is usually the
customer or the business analyst in an organization) before it can proceed to the next
development phase.

Structured design methodology has some advantages in that this method forces the developers
(analyst and his/her team) to well identify and understand system requirements long time
before the implementation phase begins. At least it should have been approved by the sponsor
before the developers start coding any programs.

10
1.4.2 Data collection Methodology
To do this project we use different methodologies to gather the necessary information that are
needed to develop our project. The methodologies that we are used to gather the
requirements are interview and the existing system documentation.

Interview
Interviewing is one of the essential methods used for gathering information; hence in our
proposed system we use this methodology. The main reason why we prefer this methodology is
that it has many advantages. For instance we can get face to face communication with the
interviewee as a result we can get the real information not only from its conversation but also
from his /her facial expression and emotion . The other thing that why we are using this
methodology is that it is less coasty since the interviewee are located near to us.

Documentation
The other methodology that we used is the documentation of the existing system. During our
requirement gathering we looked at the documents that have been written before, which
describe the former system.

Development environment/programming tools and other tools

We used different programming tools to develop this project. These are:

11
  MYSQL
 Windows 7
 PHP
 Uniform Server
 Microsoft Visio 2010

Why we have preferred these programming tools are described as follows:

 MYSQL:-To store patient information on database and access the patient information at
the time we need.
 Window 7:- To proceed the over all of our project activity and to install the necessary
software.
 PHP: - Used to Designing, coding the project interfaces and connects to the database.
 Uniform Server: - used to test web applications on Windows, and can also be set up on
removable media for a portable web server. Because it is also designed for security, it is
also usable for actual websites.

1.5 Scope of the proposed System

1.5.1 Scope in
The user of the existing system faces lot of difficulties because of the existing system has some
problems. So the solution is a modifying a system that can solve their problem. We are aimed
to develop a system which is easily understandable to non IT professionals as well as to IT
professionals. We also need to make the patient information more secured and easily
accessible whenever needed. Not only the patient information but also we need to introduce
an automation system that can manage medical laboratory (does it include facilities?). And
finally we need to change the manual existing system into automated system.

1.5.2 Scope out

The activities that we cannot accomplish in our project are handling doctor information, alert
system, report generation (You have mention that you will generate report above, pls check)
and Billing system. These are some of the major functions of this health center automation
system; which consists of several sub functions such as Add new doctor, Update doctor details,
Search for a doctor, and SMS Reminders to the doctors.

Will it run on the Web or on Local Area Network Only? Pls include here.

12
1.6 Significance of the project
Currently, client is working with a system which is having lot of errors which has to maintain
series of books to handle their data and records. Its very time consuming because maintains a
system and manual process together is a very difficult task. By automating this health center
management system they will be having lot of benefits. This will reduce human effort and also
the cost they spend to train a member for the system will be reduced. And also system provides
some more benefits to the health center such as;

 Administration can take summary reports whenever they need from the system.
 Medical store can have high performance due to the immediate updating service
provided by the system when the drug quantity is reduced.

Laboratory staff can get a fully detailed description about the patient regarding to his /her
report the patient information can be easily get whenever needed

 By the new system.

 This automated system reduce the load of the workers
 The workers can serve many patients in a short period of time

Beneficiaries of the project ((Some of that you have mentioned here belongs to significance. As
defined in the outline, this section describes the various beneficiaries of the project including
but not limited to the users of the system, the customers, the management teamed. What you
going do is to list of the beneficiaries of the project provide a brief description how this entities
benefited)

Management

Doctor

Patient

 The level of accuracy for the patient information will be higher.

 All operation would be done correctly and it ensures that whatever information
about the patient coming from the system is accurate.
 The manager can be easily managing the employees.
 There is no need for the record officer to record patient redundantly.
 Enable patient to get immediate service.
 The patient can sit at home or be at work or anywhere and can contact the health
center through internet without waiting for long turns. So they come to the health
center physically only for some required purposes.

13
  The employees can request information from other computers with a mouse click
instead of using letters.
 If the customers can share some of the tasks through the internet then it is a huge relief
for the employees.
 If we accomplish this project as desired surely we will gain an indispensable knowledge
in information Systems Software Development.

1.7 Feasibility Study

1.7.1 Operational feasibility

The new system can provide sufficient service for the patient, because in an existing system
there was bulky process in giving service. This implies that the patient cannot be satisfied for
the service they get. But this proposed system is automated consequently the patient can get
sufficient service.

Therefore the organizational management may not be fully support this project because of the
new proposed system contains new things that may difficult for the application of this project.
Even though they not support when this project is implemented the end user and the whole
organization can be benefitted. The system is operationally feasible as it very easy for the End
users to operate it. It only needs basic information about Windows platform.

1.7.2 Technical feasibility

A study of resource availability that may affects the ability to achieve an acceptable system.
This evaluation determines whether the technology needed for the proposed system is
available or not.

This is concerned with specifying equipment and software that will successfully satisfy the user
requirement. The technical needs of the system may include:When we decided to develop the
project we went through an extensive study to determine the most suitable platform that suits
the needs of the organization as well as helps in development of the project. The aspects of our
study included the following factors.

 It must have a graphical user interface that assists employees that are not from IT back
ground.

 Flexibility

 Platform independent.

 Easy to debug and maintain.

14
  Efficient data handling

 Provide inherent features for security

 Efficient data retrieval and maintenance

 Operating System compatible.

 Easy to install

The technical feasibility is frequently the most difficult area encountered at this stage. It is
essential that the process of analysis and definition be conducted in parallel with an assessment
to technical feasibility. It centers on the existing computer system (hardware, software etc.) and
to what extent it can support the proposed system.

1.7.3 Schedule feasibility

Time evaluation is the most important consideration in the development of project. The time
schedule required for the developed of this project is very important. Generally the time that
take to accomplish this system is summarized by table as follows:-

The following table shows the time schedule for the project.

Task Date Duration

Gathering requirement 29-11-2012 to 19-12-2012 20 days

Analysis 21-12-2012 to 1-1-2013 11 days

Design 10-1-2013 to 25-1-2013 15 days

Implementation 30-1-2013 to 1-3-2013 30 days

Presentation 5-3-2013 to 15-3-2013 10 days

1.7.4 Economic Feasibility/cost benefit analysis

Economic justification is generally the cornerstone consideration for most systems. Economic
justification includes a broad range of concerns that includes cost benefit analysis. The financial

15
and the economic questions during the preliminary investigation are verified to estimate the
following:

 The cost to conduct a full system investigation.

 The cost of hardware and software of application being considered.

 The benefits in the form of reduced cost.

 The proposed system will give the minute information, as a result the performance is
improved which in turn may be expected to provide increased profits.

 This feasibility checks whether the system can be developed with the available funds.

Tangible benefit worksheet

Cost reduction or avoidance 3500

Error reduction 3000

Increase speed of activity 5555

Other 150

Total tangible benefit 12205

Intangible benefit worksheet

More timely information

Faster decision making

Information processing efficiency

Improved resource control

One-Time cost worksheet

Development cost 15000

New hardware 10000

16
New (purchased )software 3000

User training 2000

Total one time 300000

Recurring costs worksheet

Application software maintenance 20000

Incremental data storage required: 1000

estimated cost/MB

Incremental communication(lines, message) 3500

Total recurring cost 24500

Chapter two
System Requirement Specification and Analysis modeling (SRS)

17
2.1 ACTORS:
Doctor

Nurse

Hospital manager

Lab technician

Pharmacist

H. Clerk

Patient

2.2 Use case:

Doctor:
 T3aking the history of the patient.
 Give treatment for the patient.
 Order the patient to laboratory examination.
 Order the nurse to maintain the patient.
 If the patient problem is impossible to treat to another hospital.
 Order the drug to the patient.
 Give a result to the patient.

Patient:
 Registered in the hospital.
 Taking information.
 Pay the payment.
 Taking card from card issuers.
 Taking Treatment by the doctor.
 Taking drug in paper manner ordered.
 Taking result and report the result.

18
Nurse:

 Care the patient.

 Giving the ordered medication.
 Report the patient current result.

Lab. Technician:
 Examination the case of patient by using lab.
 Report the result.

Pharmacist:
 Giving drug to the patient.
 See the drug to the patient.
 Order the patient in what way the drug she/ he use.

Hospital manager:
 Control all activity in the hospital.
 Enforce the hospital rule and regulation.
 Give the shift to the hospital worker.

H. Clerk:
 Register the patient.
 Give card to the patient &keeping file order.

2.3

2.4 Essential use case description

19
Name giving card

Description: giving card for patient in Hospital.

Precondition: Patient Registered at the card issuing room.

Post condition: Patient Received card from card issuing room.

Basic course of action:

1. Patient wants to take card from the system.
2. Patient input his /her name, age, sex and address into the system.
3. The system informs the patient name is legible to take card.
4. The system informs the patient amount of fees required to take card based on Business
rule of hospital BR453.
5. The Patient pays fees based on the Business rule of hospital BR453.
6. The system verifies that the patient is legal to take card.
7. The system writes receipt of payment to the patient.
8. The system sees the receipt and gives the card with receipt to patient.
9. The patient takes receipt and card from the system.
10. The use case end.

Alternative course of actions A the patient cannot pay fees:

A5. The patient tells to the system the amount of money currently in his /her hands.

A6.the system determines that the patient cannot pay the fees.

A7.The systems inform the patient that his/her money cannot pay the fees.

A8.The the patient turns to back and full the required Money and returns to hospital.

A9.The alternative course of action returns to back basic course of action at step 5.

Name treatment:

Description: giving treatment for patient.

Precondition: the patient affected by disease.

Post condition: the patient diagnosed from the disease.

Basic course of actions:

20
 1. The patient want cure from the disease.
2. The patients inform his/her problem for the doctor.
3. The doctors Assigns an appointment for the patients treatment day.
4. The patient goes to hospital at the appointment day.
5. The doctor work physical treatment for the patient.
6. The doctors order the patient to laboratory Examination.
7. The laboratory technician Examine case of patient by lab and write the result to patient.
8. The patients receive his/her result from lab technician and returns to the doctors.
9. The doctor treats the patient by all necessary mechanisms.
10. The doctors give the result of treatment to the patient.
11.The use case end.
Alternative course of actions A an appointment day passed to another day.

A6. The doctors inform the patient that as his/her appointment passed to another day.

A7. The patients ask the doctor the next appointment day.

A8. The doctors inform the patient the next appointment date.

A9. The alternative course of action returns back to basic course of action step6.

Alternative course actions B the patient does not cure from disease.

B10.the patient inform the system as he/she does not cured from the disease.

B11.the doctors checkup the patient problem.

B12. The alternative course action returns to back Basic course of action step2.

Alternative course of action C the patient problem does not under control of hospital.

C10.the doctors determine that the patient problem does not under control of the system.

C11.the doctors inform the patient that his/her problem is not under control of the system.

C12.the doctors write the referral paper to the patient at another specialized hospital.

C13. The patients take the referral paper from the doctor.

C14. The use case end.

Name giving drug

Description: giving drug to the patient according to doctor prescription

21
Precondition: the patient case is known so the doctor order the patient to take a drug

Post condition: the patient take a drug from the pharmacy

.
1 the patient wants to take drug that doctor order for his/her case

2 .the patient show to the pharmacist the prescription paper of drug

3 .the pharmacists take the paper from the patient see the prescription

4. The pharmacist sees the drug list to search the prescript drug

5 .the pharmacist calculate the payment the patient have to pay to the drug based on the rule of
business BR423

4 .the pharmacist inform the patient the amount of payment he/she have to pay

7 .the patient pay the payment required to the drug

8 .the pharmacist inform the patient that he/she is legible to take the drug

9 .the pharmacists write a recite to the payment and give to the patient

10 .the patients take the recite from the pharmacist

11. The pharmacists give the drug to the patient

12. The patients take the drug from the pharmacist

13. The use case ends

ALTERNATIVE COURSE OF ACTION: A there is no drug prescript in the pharmacy

store
A5 .the inform the patient that there is no drug prescript in the pharmacy store

A6 .the pharmacist advice the patient to by from another pharmacy

A7 .the patient goes another pharmacy

A8 .the use case end

ALTERNATIVE COURSE OF ACTION: B if the patient can’t pay payment

B7 .the pharmacist determine that patient cannot pay the payment

B8 .the pharmacist inform the patient the amount of money required to the drug

22
B9 .the patient turns to back and add the amount of money required

B10 .the patient to back pharmacy

B11 .the alternative course of action returns to basic course of action on step 5

Alternative course action b the patient does not cure from disease .

B10.the patient inform the system as he/she does not cured from the disease.

B11.the doctors checkup the patient problem.

B12. The alternative course action returns to back Basic course of action step2.

Alternative course of action C the patient problem does not under control of
hospital.

C10.the doctors determine that the patient problem does not under control of the system.

C11.the doctors inform the patient that his/her problem is not under control of the system.

C12.the doctors write the referral paper to the patient at another specialized hospital.

C13. The patients take the referral paper from the doctor.

C14.The use case end.

2.5 essential user interface prototyping

An essential UI prototype is a low-fidelity model, or prototype, of the UI for your system. It
represents the general ideas behind the UI, but not the exact details. Essential UI prototypes
represent UI requirements in a technology-independent manner, just as essential use case
models do for behavioral requirements. An essential UI prototype is effectively the initial state
—the beginning point—of the UI prototype for the system. So, now we don’t need to use
technology-based prototyping tool in order to understand and solve the problem.

23
Patient record form prototype:

Full name
Input field Sex
Fist name, middle List box
name, last name Used to specify the
sex of the patient
Id no
Input field Job
To identify List box
one patient To specify
from the patient
another jobs

24
Drug record form prototype:

Drug name categories

Input field List box
To specify the drugs Used to specify the
name category of the drug

Manufacture date Expiry date

Input field Input field
To specify To specify the
manufactured date of expiry date of
drug the drug

Quantity Price
Input field Input field
To specify the amount To specify the
of drug payment of drug

Log in form prototype:

User name Password

Input field Input field
To specify the user To specify the user
name password

25
Blood test form prototype:

Id no Test date Sex

Input field Input field Input field
To specify the To specify the To specify the gender
patient tasted date

Patient name Age

Input field Input field
To specify the To specify the
patient name age of the
patient

Create account form prototype:

Password User name

Input field Input field
Identify the correct Identify the right user
user name

Full name
Input field
Fname, Lname

26
Update account form prototype:

Password User name

Input field Input field
Identify the correct Identify the right user
user name

Full name
Input field
Fname, Lname

Prescription form prototype:

Registration number Diagnosis date

Input field Input field
Identify the patient Identify the diagnosis
date of the patient

Test
Name List box
Input field Identify the test performed
Fname, Lname

27
Patient diagnosis history form prototype:

Diagnosis date Age

Registration number Input field
Input field Input field
Identify the diagnosis Specify the age
Identify the patient of the patient
date of the patient

Sex
Name Input field
Input field Identify the gender of the
Fname, Lname patient

X-Ray Form prototype:

Registration number Test date Age

Input field Input field Input field
Identify the patient Identify the Test date Specify the age of the
of the patient patient

X-ray name
Patient name Sex Input field
Input field Input field Identify the type of
Fname, Lname Identify the gender of the x-ray taken
patient

28
 Essential user inter face prototype for treatment

Patient information giving treatment

Patient Name Help requester

Treatment currently patient
has taking
Patient Age

Patient Sex

Patient Address

Treatment
requester

Doctor information

Doctor Name Display only

Treatment Name Display only

Doctor ID Display only

Treatment type display only
Treatment
Doctor Email Display only Treatmentlist display only
requester

Dr phone no Display only Treatment availability display

only

29
 Essential user inter face prototype for treatment

s
Patient information giving card

Patient Name Help requester

Card currently patient has
taking
Patient Age

Patient Sex

Patient Address

Treatment
requester

Clerk information

Clerk r Name Display only

Card type Display only

Clerk ID Display only

Card list display only
Card requester
Clerk Email Display only Card expiration display only

Card availability display only

Clerk phone no Display only

30
Essential Use Case prototypes

31
 Patient information
Give drug for patient
2.6 Supplementary
Patient name specification Drug patient has Help
taking or is currently requester
2.6.1 Business Rules Identification taking
Patient age
Business rules are statements about the enterprise’s way of doing business. They reflect
business polices. Organizations have policies in order to: satisfy the business objectives, satisfy
customers,Patient
makesex
good use of resource, and conform to laws or general business conventions.
Business rules become requirements, that is, they may be implemented in Software as a means
of requirement of this software system.
Patient address

BR1. Patient detail registration

Display requester
 All the necessary patient information is registered.
 BR2.patient diagnosis registration
 The patient’s diagnosis information is registered.
Drug
searcher Drug details
 BR3. Blood testing
 Drug name
Information Drug
needed for list
conducting blood Drug
testing is recorded.
amount Drug Expiry
 BR4. Stool testing display only date display
 Information needed for conducting stool test is recorded first. only
Drug amount
 BR5. Urine testing Drug detail Drug name
Requester
Drug
 Information needed for conducting Urine
display onlytest is recorded first. Drug requester
for drug
location
BR6. X-Ray testing
Drug type  Information needed for conducting Drug X-Ray
type test is recorded first.
BR7. Test result reporting display only
 Test result is given to the intended person.
BR8. Recording drugs Doctor info
display only
 Drugs are recorded in to the store.
BR9. Updating drugs
 Drugs in the store are updated from time to time whenever necessary.

BR10. Monitoring drugs

 Monitors the overall aspects of drugs in the store.

32
2.6.2 Functional Requirements
The users via local area network (LAN), the system will be used to manage and process data
according to the rule & regulations of the organization. The database of the system provides
the following functionality.

 Data entry:
This is the functionality that data is entered to the systems. The system
serves different interface that can manage data entry mechanisms in the
health center.
The main data entries are the following:
 Registration
 Data update
 Login
 Search information
 Data processing
The system on input data will provide the following data processing:
•Patient and employee registration
•drug record
•Report generation
•Validate user
 Report generation
•Produce daily report for top managers.
•Total number of patient in the get service in the health center.
•Total number of female and male in specific health center
•Monthly reports
•Annually reports

2.6.3 Nonfunctional Requirements

Non-functional requirements of the system are requirements that are not directly related to
the functional aspect of the system. Instead, they describe user-visible features of the system.
The non-functional requirements of this system include features such as security,
maintainability and expandability and user friendliness.

Security: Security is one of the important features of any computerized system. In this
project, due attention is given to the security of the administration part of the system. Hence,
administrators are required to enter valid credential in order to access the system for inserting,
editing and deleting information regarding health center.

33
Maintainability and Expandability: The system should be designed in such a way
that it can be easily maintained by the system developer or any authorized professional.
Moreover, the system should be flexible enough to accommodate the future needs of
expansion of the shopping center.

User Friendliness: The consistent user interfaces to be developed will help the system to be
user friendly. For this reason, the interfaces and components of the interfaces should be
designed in a user friendly fashion to help users interact easily with the system.

34
2.7 ACTIVITY DIAGRAM

Giving
Registering patient
information
need from
his/she self

Registration in
hospital

Ac Make patient payment Giving card

Fill out
drugtakingform Obtain help
[Incorrect giving drug
to fill out
form
f

Giving drug in

Hospital

Attend hospital
check over view
[Accepted]

Taking Make
treatment payment
Reject

35
 Chapter 3
3.0 design document

3.1 class model

Room Diagnosis Nurse

Room no Diagnosis name
Name

Room type Diagnosis type

Sex
Building number Diagnosis symptoms
Age
Get room () Get checked ()
Salary
Get building no() Get result ()
Get information()

Assigned (0…* 1…*)

0…* 0...* 1...* livesat1 1…* lives at 1…*

Appointment Patient Address Doctor

Appointment date Name Name

Country

Appointment time Address E-mail address

Street

Appointment meet Sex age City Salary

Get meeting () Get (name age sex State Age
address)
Validate Get information ()

1…* 1…*

Doctor diagnosis
Drug
Doctor room no
Name
Doctor
Doctorbuilding
ty[eno
Code

Get room no ()
Expirdatedate Amount

Get full name() Get room type()

Get drug()

1…*

3.2 Sequence diagram

Registration of 36
patient uc
 Patient Security log Payment Patient Time Card
registration on display
display
<<controller>>
<<UI>> <<UI>>

1. Patient wants to take cardwish to register

2. Patient inputs name, sex <<create>>
Age and address p .name
3. System displays fees p .age
4. System affirm patient p .sex legible ( name,age,sex,address))
5. System display time of
Treatment

Patient the patient

6. System verifies patient

Wishes to register address<< create>>

7. Patient says yes time of treatment

8. System gives card to the eligible to register

(registered)

Patient

3.3 user interface _flow diagram

Well come to hospital

information system
37

Name
 See patient requester

See H .manager Patient

Requesters see doctor requester see info s

H .manager doctor Patient info

Patient
see H See
role
Role of H H .manager Taking
see doctor role requester see doctor info
.manager info card
S requester see
Give
Role of doctor Doctor info Pharmacist
Shifting sympto
Taking
Control all employe Searcher result
activity e
see nurse Pharmacist
Enforce
rule Give treat Order drug Order
Nurse nurse
Pharma Pharmacy
cy info role
see nurse info searcher see lab technician requester
Nurse role Nurse
info Lab technician
See Sell drug Order way
drug
Maintena Give Lab technical Che Lab technician
nce medicine info ck role
Examine

38
3.4 collaboration diagram

Patient <<ACTOR>> Giving drug<<UI>>

Provide information Diagnosis result See the prototype Patient

about self registration
Display drug list Drug
Taking treatment <<UI>>
Request result Display doctor info Doctor

Enable drug search

Report result

Doctor <<ACTOR>> Treatment<<UI>>

Treating patient Treatment See the prototype Patient
Ordering maintenance <<UI>> Display treatment result Treatment
Writing referral order Giving Get patient info Patient
the drug drug<<UI>> treatment
Get treatment patient record
take
Pharmacist<<ACTOR>>

Giving card<<UI>>

See the drug Giving

Patient<<ACT
drug<<UI>>
Order what way the drug OR>>
See prototype
use
Treatment
Display card info

39
 Doctor Treatment

Name Treatment Name

diagnosis
Address Treatment name Patient

Phone number Treatment giver

E-mail Waiting list Doctor

Salary Admit patient check result

Provide information
treatment giving

Patient Pharmacist

Name
Name
Address
Address
Email
Age Treatment record
Phone no Drug order<<ui>>
Sex
Give drug to patient
Result received
Sell drug
Validate checking info
provide treatment taker Order what way drug
taken

40
3.5 user interface design

Home page

Patient Information

41
Drug Details

Patient registration

42
Doctor registration

Bed Information

43
3.6 States Chart

Drug order

Pharmacist

Assign to other
Check the availability

Telling the way to use Patient came back

the drug

Giving the drug

44
3.7 Database diagram

In order to create database relationship, the class that is identified after the
requirement of the system should be mapped into tables. In addition to this the
attributes of the class are mapped into table fields. The following figure shows the
list of tables, attributes together with data type and the relationships among
tables.

45
Normalization
Normalization is the process of removing redundant data from your tables in order to improve
storage efficiency, data integrity and scalability. This improvement is balanced against an
increase in complexity and potential performance losses from the joining of the normalized
tables at query-time. There are two goals of the normalization process: eliminating redundant
data (for example, storing the same data in more than one table) and ensuring data dependencies
make sense (only storing related data in a table). Both of these are worthy goals as they reduce
the amount of space a database consumes and ensure that data is logically stored.

First Normal Form:

Tables are said to be in first normal form when:

 The table has a primary key

 No single attribute (column) has multiple values
 The non-key attributes (columns) depend on the primary key
Second Normal Form:
Tables are said to be in second normal form when:

 The tables meet the criteria for first normal form.

 If the primary key is a composite of attributes (contains multiple columns), the non key
attributes (columns) must depend on the whole key.
Note: Any table with a primary key that is composed of a single attribute (column) is
automatically in second normal form.

Third Normal Form:

Tables are said to be in third normal form when:

 The tables meet the criteria for second normal form.

 Each non-key attribute in a row does not depend on the entry in another key column

46
Chapter four
4.1 sample code

4.1.1 Sample code for home page

47
4.1.2 sample code for Patient Information

48
4.1.3 Sample code for Drug Details

49
4.1.4 Sample code for Patient registration

50
4.1.5 Sample code for registration

51
4.1.6 Sample coded for Bed Information

4.2 Test and Deployment

Unit testing
Testing of individual software components or modules. Typically done by the programmer and not by testers, as it
requires detailed knowledge of the internal program design and code. May require developing test drive modules or
test harnesses.

Integration and system testing

Integration Testing is a level of the software testing process where individual units are combined and tested as a
group. The purpose of this level of testing is to expose faults in the interaction between integrated units.

Conclusion
Deployment is methodical procedure of introducing an activity, process, program, or system to all applicable
areas of an organization. And the developed software is going to be installed on the project supervisor’s
computers. We will prepare user manual for the developed system to how to install and use the system.

4.3 user manual

To login the user should have his/her user name, password and choose his/her profession Then user clicks the
login link after the user clicks the Login link the system will displays the page depend on the user type.
There are seven types of user types, namely administrator, registration, doctors lab technician, pharmacist, bed
Worker and radiologist.
52