Rift Valley University college

Department of computer Science

Final year:-Project

Progect Title:-Hospital Management Information

System
Team Members
Bereket Wolde……………...031/17

2,Minyahl Abera………………023/17

3,Nebyu Kelemsi………….…..032/17

4,Muluken Eshetu…………….024/17

5,Mastewal Argaw……………..10/16

Date:March, 2021

Hawassa, Ethiopia

1
 Chapter one.................................................................................................................................4

1 Abstract.....................................................................................................................................4

1.2 Introduction.....................................................................................................................5

1.2 Background.....................................................................................................................5

1.3 Statement of the Problem.............................................................................................5

1.3 Objective of the Project.................................................................................................7

1.4 General Objective..........................................................................................................7

1.5 Specific Objectives.........................................................................................................7

1.6 Hypothesis......................................................................................................................7

1.7 Feasibility Study.............................................................................................................8

1.8 Developmental cost.......................................................................................................8

1.9 Operational cost.............................................................................................................8

1.1 Scope...............................................................................................................................9

2.1, Introductionss..............................................................................................................11

2.2, Purpose........................................................................................................................11

1.2 Scope.............................................................................................................................11

2.3 Overview.......................................................................................................................11

2.4 General Description.....................................................................................................12

2.5 Product Perspective.....................................................................................................12

2.6 Product Functions........................................................................................................12

2.7 User Characteristics....................................................................................................13

2.8 General Constraints....................................................................................................14

Chapter Three...............................................................................................................................15

Definitions..................................................................................................................................15

Acronyms and Abbreviations............................................................................................15

2
 3. Specific Requirements...................................................................................................15

Figure 3: User administrator’s use case..........................................................................22

Figure 4:Hospital administrator’s use case.....................................................................23

Figure 4:Ward facility’s use case......................................................................................24

Figure 3:Pharmacist’s use case........................................................................................24

4.3.1 Non-Functional Requirements........................................................................................25

Performance...............................................................................................................................25

1, Accuracy and validity:............................................................................................................25

2, Timing:.....................................................................................................................................25

3, Capacity limits:.......................................................................................................................25

4, Failure contingencies:...........................................................................................................25

4.3.2 Reliability...........................................................................................................................25

4.3.3 Availability.........................................................................................................................25

4.3.4 Security..............................................................................................................................26

4.3.5 System security................................................................................................................26

4.3.6 HMIS software application security................................................................................26

4.3.7 Inverse Requirements.....................................................................................................26

4.3.8 Design Constraints...........................................................................................................27

4.3.9 Logical Database Requirements...................................................................................27

4.4.1 Other Requirements.........................................................................................................28

Chapter Four...............................................................................................................................29

4. Introduction.....................................................................................................................29

4.3.2 Purpose.............................................................................................................................29

4.3.3 General Overview.............................................................................................................29

4.3.4 Development Methods & Contingencies.......................................................................29

4.3.5 System Architecture.........................................................................................................30

3
 4.3.6 Subsystem decomposition..............................................................................................30

4.3.7 Hardware/software mapping...........................................................................................31

5.1 Class Diagram..............................................................................................................32

5.2 Sequence Diagram......................................................................................................33

5.3Detailed Design.............................................................................................................35

4
 Chapter one
ACRONYMS

SRS - System Requirement Specification

HMIS - hospital management information system

HSDP - health sector development program

FMOH - federal ministry of health

DBMS - database management system

PAAB - patient administration and billing

CBPR - computer-based patient record

WHO - world health organization

1 Abstract

Why hospital management information systems?

Good management is a prerequisite for increasing the efficiency of health services. Of the
major obstacles to effective management of hospitals, information system support is the one
most frequently cited. Recently there is a greater need of well-designed information
management systems for ensuring that services are delivered according to standards and
data is managed according to manners.

Ethiopia being one of the developing countries, even if it is known theoretically that
Implementing a hospital management information systems (HMIS) which is based on
networked system backbone and as a software is the very effective way of managing
hospital data, but varies studies show that many private and public hospitals in the country
still are working using the old way of paper file system.

Hawassa Adare Hospital is one of the public hospitals which can be mentioned as having a
poorly developed information management system and this hospital is the one which we
choose to work on as our graduation project.

5
 HMIS helps to get the right information at the right time, reducing the time it takes to do those
things in the usual days, helps the hospital manager and administrative members to have a
clear information of what is going on in the hospital daily, monthly and annually so that they
can have a clear understanding of the decisions they will have to make.

Also using the accurate and stable patient/doctor information managed by the HMIS
application, developing statistical information, total health reports of the hospital and
estimating budget and material requirements will be much easier.

1.2 Introduction

Hospital management Information System is an application that provides a common source

of information about a patient/doctor health information.

The system have to keep data in secure place and controls who can reach the data in
certain circumstances.

HMIS may control health organizations, which is Hawassa Adare Hospital in these case,
keeps secure storage of patients doctor information, patients medical history, financial
situation reports, personal data information, medical prescriptions, operations and laboratory
test results.

As we mentioned earlier, most hospitals in Ethiopia including Hawassa Adare Hospital,

equate information systems with filling endless registers with names and addresses of
patients, compiling information on diseases every week or every month, and sending out
reports without adequate feedback.

Furthermore, the data received are often not helpful for management decision making
because they are incomplete, inaccurate, untimely, obsolete, and unrelated to priority tasks
and functions of local health personnel. In other words, information systems tend to be data-
driven instead of action-driven.

Hawassa Adare Hospital tends to provide service to more than 500 patients each day.
Trying to handle these many customers everyday has been the very thing that was leading
the hospital to many problems for many years.

These problems temporary or permanent, have been causing many drawbacks to the
hospitals’ growth. Explore new technology to support the management system is critical
nowadays. HMIS is a new product specifically developed based on is Hawassa Adare
Hospital record management bureau also aiming in reducing the burden of the record
management stuff members in the hospital

1.2Background

1.3Statement of the Problem

6
 Health information can be produced from hospitals in order to be used for sound decision
making and problem solving in the health care status of the country and for the governance
of the health system at regional and national levels.

As a hospital, to deliver such information it is important to use the appropriate record

management system. is also striving to replace the paper-based record management system
with a computer-based patient record management system or .

Hawassa Adare Hospital is also striving to replace the paper-based record management
system with a software-based record management system (a computer-based patient
recordor CBPR).

Even if the hospital tried to use SmartCare as a solution before, it is definite now that the
software cannot handle the problem effectively.

In general it is observed and identified that:

Patient record in Adare hospital are kept using paper-based record system which is prone to
error, difficult for easy access, leading to lack of timely reliable and relevant information as
well as use of information for action.

Smart Care is not effective as it was thought and causes data lose and corruption. The
hospital could not relay on it anymore. Also this software cannot store medical history of
patients.

The hospital uses a storage room to store patient registration forms and medical history, as a
result there is frequent data loss because of many reasons.

There are 24 permanent workers in the registration office, but still there is too much work
load on each of the workers.

Searching for a specific patient/doctor information is very time consuming and tiresome.

Data loss and corruption are very common in the current situation of the hospital, which
leads to many other unfixable problems.

Patients instead of getting an easier time in the hospital, they might find themselves in
obstacles, waste of their time waiting for services in different offices before they can even
see a doctor. A very problematic patient administration and billing (PAAB).

Decision making is very difficult for the hospital Difficult to do health researches which are
based on patient/doctor records .

These problems have been addressed before by different parties, Including the ICT
Department in the hospital, registration department and by patients many times. But even if
the problems are very serious and needs no time waiting to be solved, the governmental
institution of federal ministry of health (FMOH) didn’t do anything that can change the
situation

7
 permanently. But have planned to do projects that can solve the problem in the future.

These all problems have many impacts on the hospital as a whole and on patients

Element Description

The problem of poor record management system Paper-based patient/doctor file recording

Affects the whole institution and customers Adare hospital patients(customers)

And results in data loss, data corruption, waste of Work delay, waste of time, difficult information
time and energy…etc accessing, problems of decision making…etc.

Benefits of a solution is an efficient software-based Work delay, waste of time, difficult information
record management system accessing, problems of decision making…etc.

In general it is identified that:

- Patient record in Adare hospital are kept using paper-based record system which is prone
to error, difficult for easy access, leading to lack of timely reliable and relevant information as
well as use of information for action

- The hospital uses a storage room to store patient registration forms and medical history, as
a result there is frequent data loss because of many reasons.

- Data loss and corruption are very common in the current situation of the hospital, which
leads to many other unfixable problems.

- Decision making is very difficult for the hospital

1.3Objective of the Project

1.4 General Objective

The general objective of this project is to analyze, design, and develop information
management and record system for a hospital.

Also to assess HMIS Design and Implementation, determine the status of HMIS
implementation and the use of HMIS generated information for health care delivery planning
and decision making in a hospital.

1.5 Specific Objectives

To achieve the above general objective of the project, the following specific objectives are
formulated;

8
 To review literature and related works done and understand concepts to design patient
record system

To understand the current patient recording system and identify information requirements of
Adare hospital

Implement a prototype patient record system, that manage patient information and evaluate
the performance of the prototype

1.6 Hypothesis

These are the list of the characteristics of the system we will be working on to creat:

A systematic record management based on a software: data about the patient's profile,
health care needs, and treatment serve as the basis for clinical decision-making and also for
public health researches. Health care records provide the basis for sound individual clinical
care. Problems can arise when health workers are overburdened by excessive data and
reporting demands from multiple and poorly coordinated subsystems

A secure data management system: a software-based data management with a secure

structure, no loss of data and no corruption.A reliable and timely health information.

A management system which can minimize work load of stuff members, easy information
accessing and retrieval.

1.7 Feasibility Study

1.7.1Technical Feasibility

Include budgets for:- Hardware and software costs

- IT personnel costs (DB admin, labour, software developer…etc)

- Maintenance costs

- Backup and recovery costs

These costs are also the responsibilities of the hospital.

1.7.2 Schedule Feasibility

Schedule feasibility includes three major parts, development time, testing time and
deployment time.

9
 Development time:- The time it takes to implement the application

It takes maximum of 8 monthIt takes 2 months for study and plan 6 months to implement
(coding)

Testing time:- The time it takes to test the effectiveness of the application

It takes a maximum of 4 months with partial migrationIt is also our task.

Deployment time:- The time it takes to transfer hospital data into the new system.

It is the responsibility of the hospitalIt takes maximum of 4 months

1.8 Developmental cost

Developmental feasibility includes the cost the project takes when it is under development.

These costs are the responsibilities of Hawassa Adare Hospital

- Hardware cost (server, pc)

- Software license purchase cost (OS, DB)

- Deployment cost

- Connectivity cost (network installation – device, cable, labor)

- IT personnel cost

1.9 Operational cost

These are the costs after the software application is purchased and started working in the
institution. These are also the responsibilities of the hospital.

The costs include:

- Operations Infrastructure Costs

- Cost of Security Breaches (in loss of reputation and recovery cost)

- Cost for electricity and cooling

- Testing costs

- Cost to upgrade or scalability

- Backup and Recovery Process costs

- Costs associated with failure or outage

- Technology training costs of users and IT staff

10
 - Migration costs( from manual to digital)

1.1 Scope

The The current system in use in Hawassa Adare Hospital meany System are paper-based
system. This system is very slow and cannot provide updated lists of patients within a
reasonable time frame.

The intentions of the system are to reduce the frustration of both staff and patients, increase
the satisfaction of patients from the clarity of the processes they go through in the hospital
and reduce over-time pay.

Requirements statement in this document are both functional and non-functional.

The study was focused on evaluating the design of the system used for HMIS in terms of
completeness, user-friendly, layout, report generation, and the status of using information
generated by the system and the likes.

Patient Registration Management system should be able to:

Register a patient under unique Patient ID.

Search Patient details through multiple criteria.

Multiple Categories of Patients.

Multiple addresses/phone numbers related to patient can be stored.

User-friendly, easy-to-use & web-enabled applications.

Data visualization on dashboards & statistical analysis capability.

Patient data status can be activated and deactivated.

Patient data can be set confidential which will be seen only to concerned
department /doctors.

11
 Patient Detail Data should not be visible or editable other than the administration

1.1.2 Methodology

We use water fall Methodology. Water Fall method is a sequential design process in which
progress is seen as flawing steadily downward like a waterfall through the phases of
conception testing the pasese of conseption testing production

Implementation and maintenance. In this model one should move to a phase only when it’s
preceding phase is revised and verified.

We use waterfall methodology instead of AGI or other methodologies because we are not
equipped technically to do all the tasks of developing

the software by the time we analyze the project we will be equipped of all the technical
needs.

2.1.3 Quality Management Plan

Quality management plan insures that:

Products are built to meet the agreed upon standards and requirement;

HMIS will be built to provide Hawassa Adare Hospital record management system in a
way that the Hospital needs it and also the customers recording to the researches and
meetings we have done with the institution members and clients to find out what their real
needs are.

Some of the standard needs are information security and easy information accessing. To
achieve this standard we do many testing techniques to ensure security and integrity of data
record.

Work process are performed efficiently and as documented:

To achieve these needs we built a concrete plan to prevent work load and delay.

We record weekly work done according to the plan created and analyze pros and cons.We
maintain a documented progress of what we did.

Non-conformances found are identified and appropriate corrective action is taken:As we do

our work according to our plan something might go out of order or errors might happen so
we will have a strategies to apply appropriate checking and corrections.

12
 We will make sure that the qualities of the deliverables according to our plan and also the
needs of the Hospital and Customers. Some of main deliverables are:-

- Project plan

- Web application or HMIS

- System Desig

Chapter Two

2.1, Introductionss

This section gives a scope description and overview of everything included in this SRS
document. This specification describes what the proposed system should do and the
complete external behavior of the system.

The function and performance allocated to software as part of the system engineering and
refined by establishing a complete information description, a detailed functional description,
a representation of system behavior, indication of performance requirements and design
constrains, appropriate validation criteria and the other information related to requirements.

13
 2.2, Purpose

The purpose of this document is to describe the requirements for the Hospital Management
Information System (HMIS). All the external interfaces and the dependencies are also
identified in this document. The intended audience includes all stakeholders of the potential
system. These include, but are not necessarily limited to, the following:

- Receptionist

- Doctors

- Bed ward nurses

- Laboratory technicians

- Hospital administrators

- IT administrators

1.2 Scope

The current system in use in Hawassa Adare hospital is a paper-based system. This system
is very slow and cannot provide updated lists of patients within a reasonable time frame.

The intentions of the system are to reduce the frustration of both staff and patients, increase
the satisfaction of patients from the clarity of the processes they go through in the hospital
and reduce over-time pay. Requirements statement in this document are both functional and
non-functional.

2.3 Overview

This Software Requirements Specification (SRS) is the requirements work product that
formally specifies Hospital Management Information System (HMIS). The SRS defines and
illustrates the overall project and its requirements both functional and non-functional. In
addition, the SRS will define the users and their respective characteristics as well as any
constraints and business rules. It also addresses about the software interfaces and every
face of the components design.

The detail structure of this document is organized as follows:

- General description

- Specific requirement

- Change management process

14
 2.4 General Description

This section will give an overview of the whole system. The system will be explained in its
context to show the basic functionality of it. It will also describe what type of stakeholders
that will use the system and what functionality is available for every user. At last, the
constraints and assumptions for the system will be presented. The whole system will need
large storage capabilities and a process to archive outdated data.

2.5 Product Perspective

This Hospital Management Information System is a self-contained system that manages

activities of the hospital as Patient Information. Various stakeholders are involved in the
hospital system. This system will be a windo application and it is going to be used for
managing the information system of the hospital. The application will need an input of data
from the end users.

2.6 Product Functions

The system performs the following major functions:

Registration: When a patient is admitted, the front-desk staff checks to see if the patient is
already registered at the hospital. If his/hers Personal Health Number (PHN) is entered into
the computer or not.

If the PHN for that specific patient is found, then there will be no registration. But if the PHN
is not found, the patient is new to the system and so a new Personal Health Number will be
given to this patient.

At this level, the general information of the patient will be entered in to the system. Including:

Full name

Age

Gender

Marital status

Date-of-birth

Nationality

Address

15
 Basic examination results recording: after the patient is registered he/she will further go to
see the proper doctor.

The assigned doctor examines the patient with their problem and he/she will enter all the
results of the examination to the system. Examination results, such as:- Symptoms of the
patient

- If the patient should further undergoes laboratory examination and their types

- If the patient should take medical treatment immediately and their types

- If the patient should get a bed in the hospitalOther specific details which must be included

Laboratory examination results recording: if the doctor responsible orders the patient to
be examined in the laboratory, then the laboratory technician will be responsible for the
examination and the recording of the results of each test the doctor ordered for that specific
patient.

These whole laboratory examination results will also be send back to the doctor.

Hospital report recording: the hospital administrator is the one who is responsible in
organizing the general reports for the hospital and entering them into the HMIS. These
information’s include:

The number of patients that get services per day

The number of patients that get services annually

The number of patients that are in treatment with bed services

The number of patients that are done with their treatment

The number of patients that are dead in a day and annually

Other necessary reports according to the performance of the hospital

Ward facility recording: if the doctor responsible order bed for a patient, then information
concerning this will be entered to the system by the ward nurse assigned. The room number
and the bed number assigned are the main contents of the information.

2.7 User Characteristics

There are few types of users that interact with the system:

16
 Receptionists

Doctors

Ward nurses

Laboratory technicians

Hospital administrators

IT administrators

Pharmacists

Each of these types of users has different use of the system so each of them has their own
requirements.

Receptionist: can only use the application to register the patient by entering the patients’
general information like full name, age, gender, address, date-of-birth, etc.

Ward nurse: the only job that can be done at this page is to assign a patient to an available
bed.

Laboratory technician: after the patient provides the inputs that are required by the
laboratory technician, the test will undertake and the technician enters the test results and
also send the results back to the doctor.

Hospital administrator: is the Hospital CEO, who is responsible of performing tasks like
preparing reports on the daily customers of the hospital, annual reports on the number of
customers and services provided and other general reports about the hospital and entering
those reports to the system.

Pharmacist: the only thing pharmacists responsible are to retrieve medical prescription data
that came from a doctor and provide the patient with the proper services.

IT administrators: also interact with the web portal. They are managing the overall system
so that there is no incorrect information within it. The IT administrator also manages the
privilege given for each user depending on their tasks.

But in general, all the users must be comfortable with using computers and basic knowledge
of the software is a must in order to use the HMIS. The system is also designed to be user-
friendly. It uses a Graphical User Interface (GUI).

17
 2.8General Constraints

Since Adare Hospital attend over 500 patients per day, the HMIS will need large storage
capabilities and a process to archive outdated data. The Internet connection is also a
constraint for the application. Since the application fetches data from the database over the
Internet, it is crucial that there is an Internet connection for the application to function.

Chapter Three

Definitions
Fit for use: deals with the system’s task support that the user has in the real life.

Ease of use: how user friendly the system is.

Ease of learning: lack of difficulty during learning.

Task efficiency: the ability to do tasks without wasting resource and time.

Ease to remember: making things easier to remember.

Subjective satisfaction: satisfying one’s desire.

Acronyms and Abbreviations

# Item Description

18
 1 HMIS Hospital Management Information System

2 PHN Patient Health Number

3 GUI Graphical User Interface

4 EDM Entity Data Model

5 SRS System Requirement Specification

6 SQL Structured Query Language

3. Specific Requirements
This section contains all of the functional and quality requirements of the system. It gives a
detailed description of the system and all its features.

3.1 External Interface Requirements

3.1.1 User Interfaces
There are many factors that must be considered when designing the user interface of a
software because the user must be able to interact with the system in a way that the system
will understand whatever the input given by the user. Therefore, the quality of the interface
and software in general must pass the usability testing standard. Some usability factors,
such as fit for use, ease of learning, task efficiency, ease to remember, subjective
satisfaction and understandability but all be put into consideration when we design the user
interface.

Visibility of the system status: The user interface design should make sure the interface is
able to inform the user what is going on at every point in time with appropriate feedback.

Match between the system and the real world: The system should be able to
communicate to the user in the language the user understands rather than computer
language that is, making information appear in natural and logical order.

19
 User control and freedom: User often make mistake by clicking buttons which are not
relevant to his/her current task, therefore a clearly mark “exit” button should be designed on
the interface.

Consistency and standard: Platform conventions are important part of user interface
design because user should be able to know that a word that is redden before still means the
same thing when the same is encountered on another line.

Error prevention: It is better to eliminate error prone conditions or check for them and
present users with a confirmation option before they commit to the action.

Flexibility and efficiency of use: To use accelerators, unseen by the user, to speed up the
interaction and that the system can cater to both inexperienced and experienced users.

Help users recognize, diagnose, and recover from errors: Error messages will be
expressed in plain language (no code), precisely indicate the problem and constructively
suggest a solution.

Aesthetic and minimalist design: Information which is not relevant to the dialogue should
not be placed on the design because all other dialogue with relevant information thereby
diminishing their visibility.

The followings are the interfaces that are designed for this software. Few of the interfaces
are listed and explained in details below:

3.1.1.1. User Administration interface (IT Administrator)

Every user who wants to use this software is authenticated by means of username and
password which is already created by the administrator and is stored in the database. All
entered parameter of the password are matched with information stored in the database,
therefore only authenticated users can log on to the program with limited access. The

20
 administrator is the only one who can access to the entire modules and interfaces of the
software.

3.1.1.2. Patient Registration interface (Reception or Clerk)

Any person who visits the hospital for the very first time either for consultancy, treatment,
diagnoses or emergency is required to register as a patient of the hospital. At the time of
registration, a patient identification number will be assigned to the patient.

In this interface:

 Patient general information are recorded.

These are as follows:

- Full name

- Age

- Gender

- Marital status

- Date-of-birth

- Address…etc

3.1.1.3. General examination and Treatment information interface

(Doctor/Nurse)
This module entails the general examination and the treatment a patient receives by the
assigned doctor while being admitted to the hospital. The doctor uses this interface to
manage and store information in which he/she is responsible for as we described under the
user characteristics of a doctor.

The main features of this module are:

 patient general examination results and treatments information

 information of the doctor who is responsible

 the information of the stuff who contributed in the process of examination

21
 3.1.1.4. Ward Management interface
This module is used by the ward nurses to store information about the rooms in the hospital,
including the occupied and the available ones. When a patient is brought to the hospital and
he/she is in need of a bed, the responsible member of the nurses in the hospital checks if
there is any available room and if there is one, assign it to patient. And also enter these
information of the assignment into the system. Each room has its own allocated number and
contains a certain number of beds which are numbered too.

Main feature of this module is:

 room allocation

 bed allocation

3.1.1.5. Laboratory examination interface (Lab Technician)

This interface will be used by the lab technician to:

 Check what the doctor orders for a laboratory examination for a specific
patient.

 After the examination has taken place, the lab technician will enter the
laboratory examination results of the patient into the database.

3.1.1.6. Pharmacy interface (Pharmacist)

This interface will be used by the pharmacist to:

 Check what medical prescriptions the doctor order for a specific patient.

 After providing the right medicines to the right patient, update the database with
this information.

3.1.1.7. Hospital Administration interface (Hospital Administrator)

This interface will be used by the Hospital Administrator to:

 Keep record of all staff members: All the staff that works in the hospital has their
information stored here. All general information about the stuff members will be
included.

22
  Keep record of number of patients per day and also annually.

 Keep record of services provided and materials used by the hospital annually.

3.1.2Hardware Interfaces
This project will have a server that’s going to be used as a database server, an
authentication server and web server. It also involves some personal computers.

3.1.3Softwarse Interface

 Database Server: we use a free open source database server MySQL.

 Web Server: we use a free open source web server Apache. As we use PHP as
server-side scripting language, the web server is PHP-enabled.

 Authentication Service: we use LDAP authentication service provided by Linux.

 Operating System: we use a free open source operating system Linux (preferable
Ubuntu as it is friendly and an African product).

3.1.4Communications Interfaces
To interconnect all the departments, we use TCP/IP based network authentication in order to
avoid an unauthorized user access.

3.2.1 Functional Requirements

The HMIS software must request username and password for access to data, only after
authentication will allow access to the system. The software must require high levels of error
correction and input validation. Also the softwaremust allow only the right doctor (with the
right username and password) to access the patient history document of only his/her patient.

23
 The software must identify each patient by a unique numeric identifier. TheHMIS software to
be developed must operate without interruption twenty-four hours a day and with a good
performance.

3.2.2 Functional Requirement of Registration

1 Introduction Registration by the Receptionist

2 Inputs General information of patient

3 Processing Assign patient-ID: the HMIS shall allow front-desk staff to give each
patient an ID and add it to the patient’s record. This ID shall be used
by the patient throughout his/her stay in the hospital.

Figure 1:Registration’s use case

24
25
 3.2.2 Functional Requirement of general examination

1 Introduction General examination by Doctor

2 Input Symptoms of the patient

General examination results

If laboratory examinations are needed(input) or not

If ward facilities are needed(input) or not

If immediate medical prescriptions are needed(input) or not

If other patient specific suggestions are required(input)

3 Processing Recording of the whole results of the general examination of a

patient by his/her specific doctor to the system

Recording of medical prescriptions by the doctor, if any is ordered

Recording of ward facility orders by the doctor, if any is ordered

Recording of other patient specific suggestions by the doctor, if any

is important

4 Output Patient general examination results can be retrieved by the

Specific doctor who records it and only by him/her.

Medical prescription orders for patient by the doctor can be retrieved

by the proper pharmacist.

Laboratory examination orders for patient by the doctor can be

retrieved by the proper laboratory technician.

26
 Ward facility orders for a patient by the doctor can be retrieved by
the proper ward nurse.

Figure 2: General examination’s use case

DOCTOR

General examination-Laboratory

27
 3.2.3 Functional Requirement of Laboratory examination

1 Introduction Laboratory examination by Laboratory technician

2 Input Laboratory examination test results of a patient(tests as order

by the doctor)

3 Processing Recording the laboratory examination test results of a patient

Sending those test results to the appropriate doctor

4 Output The laboratory examination test results of a patient can be

retrieved anytime by the right doctor

Also the laboratory technician can retrieve the test results of

his/her assigned patients

28
 Figure 3:Laboratory examination’s use case

29
LABORATORY
TECHNICIAN
DOCTOR

30
 3.2.4 Functional Requirement of User Administrator

1 Introduction Authentication and Authorization by user administrator

2 Input The general information of the whole staff members with their
department and specialties

3 Processing Assigning each staff member with a unique username and

passwords to access the system according to their
departmentProvide and control privileges of
staffmembers(users)depending on their department.

4 Output Unauthorized attempt to access the system will fail

All the staff members will have a unique username and

password to access the system

Figure 3: User administrator’s use case

31
ADMINISTRATOR
USER

32
 3.2.5 Functional Requirement of Hospital Administrator

1 Introduction Hospital report making by hospital administrator

2 Input Number of patients registered each day with their general

information from the reception Amount of materials consumed by
the hospital in a year

Types of materials used by the hospitalother general information

about the hospital

3 Processing Collecting all hospital general information

Collecting all patient general information

Preparing organized reports

4 Output Daily, monthlyand annual hospital reportsClear management and

decision making will be possible for the hospital

Figure 4:Hospital administrator’s use case

33
 HOSPITAL
ADMINISTRATOR

34
 3.2.6 Functional Requirement of Ward facility

1 Introduction Bed and room allocation by Ward nurse

2 Input Information about available and unavailable rooms and beds

3 Processing Checking rooms and beds for patients

Assigning rooms and beds for patients

4 Output Rooms and Beds assigned to the right patient

Figure 4:Ward facility’s use case

35
WARD NURSE

36
 3.2.7 Functional Requirement of Pharmacist

1 Introduction Medical prescription retrieving by Pharmacist

2 Input Doctor’s medicine prescription for a patient

3 Processing Retrieving medical prescription information for a patient from the

doctor

Providing it to the right patient

Update the database with new record of medicine given to the

patient

4 Output Patient satisfied

database updated with new record of medicine given to the

appropriate patient

Figure 3:Pharmacist’s use case

Check medicine prescription PHARMACY

PHARMACIST

4.3.1Non-Functional Requirements

37
 Performance

The product shall be based on web and has to be run from a web server. The number of
clerks at the reception should be at least three for maximum efficiency. The software can
take any number of input provided, when the database size is large enough. This would
depend on the available memory space.The system will employ numerous data quality
assurance techniques, including but not limited to:

1, Accuracy and validity:

drop down lists with standard responses

Record data completeness

Basic data logic warning

2, Timing:

The system will be available 24 hours per day with the exception of scheduled and pre-
notified system maintenance downtimes.

Data will be available for use in time of need depending on authorization specified

Ensure that system updates, software updates and regular system maintenance is not
completed during peak operation periods.

3, Capacity limits:

The daily users input must be handled, also annual inputs with theseusers utilizing the
system concurrently.

4, Failure contingencies:

There will be recovery protocols and solutions in place that will facilitatesystem availability in
case of failures.

Ensure completion and validation of daily backups of both the client records and system
structure.

4.3.2 Reliability

The additional desired functionality of the software is reliability. A reliable and flexible data
transfer tool must be applied in the software to facilitate the secure and reliable transfer of

38
 data between multiple and diverse parts of the system. All users will be required to
participate in a serious of trainings prior to access the software HMIS, ethics, client privacy
and confidentiality, and data security.

4.3.3 Availability

All the computers should be connected to an ‘UPS’ and there should be adata center for
protecting all the hardware equipments. The system shall provide storage of all databases
on redundant computers. Since this application is going to be applied on a hospital the
system must be on service for 24 hours and 7 days a week (24/7).

4.3.4 Security

The HMIS software and hardware maintained by the hospital must all meet a few security
requirements and technical standards.

These requirements include:

4.3.5 System security

User authentication: We use LPAD authentication for every user to identify the correct
personnel is accessing the appropriate information.Inputerrors will be returned in red with
appropriate message box. More than three attempts at login and failure will produce a red
flag to system administrator.

Virus protection: using anti-virus protection for the system.

Disaster protection and recoverySystem monitoring

4.3.6 HMIS software application security

User authentication: which is part of our HMIS

Electronic data storage: which is not part of our HMIS

Hard copy security

Protection of any hard copy generated by or for HMIS that contains personal protected
information when the hard copy is in a public area

Maintainability

The system must be gullible enough for future modifications or even removal of unnecessary
features. The software will be flexible and customized to suit future needs as they appear.

39
 However, to ensure growth ability, flexibility is required for both input and output modes to the
system.

Portability

If a hospital other than Adare Hospital wants this software to be applied on his/her hospital,
the system must be portable enough and be available for those hospital users too.

4.3.7 Inverse Requirements

The HMIS application’s main aim is to manage patient health information effectively
throughout Adare Hospital The application HMIS doesn’t do:

It does not allow access to it other than from the privileged staff members

The privileges are dependent on the departments in the hospital so it doesn’t allow a staff
member from one department to access the system through the name of another
department.

The system does not give internal access to patients or there is nousername and password
to patients.

Patient medical history is only visible to the doctor responsible.

The system does not provide security system other than authentication.

The system does not support online patient-doctor appointment making (without the
involvement of a receptionist).

4.3.8 Design Constraints

Creating a user interface which is both effective and easily navigable will pose a difficult
challenge. The software meant to be quick and responsive, even when dealing with large
work load, so each feature must be designed and implemented with care.

Hardware, software and data communication elements must be sourced within budgetary
constraints. Like knowing if the stakeholder can afford a server and being insured that the
server will be ready at the time of deployment.

40
 4.3.9 Logical Database Requirements

Relational database will be used as a data storage system. And a logical data model will be
created to help design the physical database. Preparing a data model is the first thing to do
for us because it will help us to have a better

understanding of the data to be stored in our database. Our data model will mainly include
entities and relationships. Data normalization will be a big part in our data modeling and
database design to reduce data redundancy and inconsistencies.

To achieve data integrity in our relational database, we use:

Entity integrity: concerned with every table must have its own primary key and that each has
to be unique and not null.

Referential integrity: this is the concept of foreign keys.

The above two will also help make the data retrieval and management easier.In our
database values, we will enforce planning about the data to be stored by:

Data types:

Integer

Decimal

Datatime

Varchar

Scale

Missing data(null values)

Even though we will need extensive knowledge of SQL for effectively designing our
database. And in time we think we will acquire that.

The system’s back-end databases shall be encrypted. Only an authenticated user can
access the database

41
 .

4.4.1 Other Requirements

Training-related Requirements

The end users will be provided with a training session in order to make them familiarized with
the system and to avoid unwanted errors.

Packaging Requirements

The system is going to be packed in two ways:

User (operational) manual: is a book-like communication document intended to give

assistance to people who are going to be using the HMIS system. It will contain a written
guide and if important associated images and screenshots of interfaces to help people
understand about the system in an easier way. It will be prepared by all our group members
together.

Technical manual: is also a document that describes in detail the HMIS system architecture
and its functionalities. Also it includes a step-by-step guidance on how to handle the system.
It helps users to understand complicated and abbreviated processes into more readable
ones. The whole team member will participate in this too.

42
 Chapter Four

4.Introduction

The system design document is a document to provide documentation which will be used to
aid in software development. Our hospital management information web application software
will provide the details for how the software should be built. Within this document are
narrative and graphical documentation of the software design for the project including
deployment methods and contingencies, system architecture, hardware/software mappings
and object model.

43
 4.3.2 Purpose

The purpose of this system design document is to provide a full description of the Hospital
Management Information System (HMIS) design implementation to allow for its development
to proceed with an understanding of what is to be built and how it is expected to build. This
document provides a detailed description of the software system to be done as we progress
into the next stage of our project.

4.3.3 General Overview

This system design document presents the technical details of the Hospital Management
Information System design and the document starts with an introduction to the architecture
and the design goals to be considered. Then it will present the proposed system architecture
by describing the subsystem decompositions and the subsystem services. The
hardware/software mapping will also be defined and addressed.

4.3.4 Development Methods & Contingencies

The software application HMIS is based on an architecture with MySQL database version 4.5
and PHP version 5.0. The application will be developed in the Netbeans Integrated
Development Environment with the use of libraries and code segments from phpbuilders,
phpclasses, jquery and ajax. The solution will be implemented in one database due to the
reason that Adare Hospital is going to implement only one server.

The database will include:

Patient records

Human resource data

Accounting data

For all errors and exceptions the same page format is displayed with the error specification
information, providing the users a consistent view. Moreover a java script dialogue box is
also generated to prompt the user for additional information or comments.

We use waterfall methodology, since we need to adopt to the software development skills
over time. The hospital CEO, the IT department of the hospital and our team will manage a
joint meeting and discuss issues concerning the development of the HMIS software.

Our HMIS is designed considering the following design goals:

Multiple users: the system should support tasks that are performed by multiple users in
mind, supplying each with the necessary information at the appropriate time.

Availability: the users should have access to the HMIS system whenever they need it.

Usability: the system should be user friendly for end users.

44
 Scalability: the system should accommodate growth in case the Hospital needs to expand
its system.

For future contingencies,

The possibilities include lack of interface agreements with the users: in this case, we will
have other alternate plans to figure out what will be the

solution to fulfill these disagreements and correct them in the way that satisfies the end
users.

Unstable architectures: the system design architecture we consider now might change in
some ways according to new user needs which will be known and addressed in time.

Size of database increases day by day: This will be addressed by adding additional storage
space to the system.

4.3.5 System Architecture

4.3.6 Subsystem decomposition

The system is divided into several subsystems. These multiple distinct components are:

The application: provides the core functionality of the system.

Interfaces: provides a graphical user interfaces. Which are;

User Administration interface: which includes the authentication of a user with password
and username.

Reception interface: in which the patients’ general information is recorded as he/she

comes to the hospital for a treatment.

Doctor interface: in this interface all patient/doctor information will be recorded.

Ward management interface: room and bed allocation for a patient will take place here.

Laboratory interface: to check what the doctor orders for a patient as a laboratory
checkup and record the results of the checkup.

Pharmacy interface: to check what medicines the doctor orders for a patient and record
the information.

Hospital administration: to keep records of all the stuff members and patients who get
services from the hospital per day.

Network: provides the communication platform for the other subsystems.

Storage: provides data storage and management.

45
 4.3.7 Hardware/software mapping

The hardware and software requirements for the system implementation and deployment
would be defined here according to the software system and hospital needs.

The main hardware components needed are:

One server which works as both web and database server

Network connectivity material (which are physical and wireless requirements for the
software implementation).

Computers

Input Devices: Keyboard, Mouse

Output Devices: Monitor

RAM:521MB or above

CAT 5 cables and connectors

Power input devices

Hard Disk: 40GB or above

The main software requirements are:

Database:mysql

Operating system: windows

Other helpful applications

Figure 1. UML deployment diagram5 Object Model

46
 5.1 Class Diagram

Figure 2. Class Diagram

5.2 Sequence Diagram

47
 Figure 4. UML sequence diagram 1

Figure 5. UML sequence diagram 2

48
 Figure 6. UML sequence diagram 3

Figure 7. UML sequence diagram 4

5.3Detailed Design

Data Model for HMIS

49
 Receptionist

Name Type Description

Receptionist-ID Integer Not null,Primary key

Receptionist-name Varchar

Table 1. Receptionist

Registration

Name Type Description

Patient-ID Integer Not null,Primary key

Patient-name Varchar

Doctor-ID Integer Foreign key references to

examination by doctor

Age Integer

Gender Varchar

Status Varchar

nationality Varchar

Date-of-birth Datetime

Address varchar

Date Datetime

Table 2. Registration

Examination by doctor

Name Type Description

Doctor-ID Integer Not null, Primary key

Doctor-name Varchar

Patient-ID Integer

50
 Diagnosis-description Varchar

Diagnosis-date Datetime

Lab-examination-type-ID Integer Foreign key references to lab

examination

Ward-requirement-ID Integer Foreign key references to

ward facility

Medical-prescrption-ID Integer Foreign key references to

prescription

Table 3. Examination by doctor

Ward facility

Name Type Description

Ward-nurse-ID Integer Not null, Primary key

Ward-nurse-name Varchar

Ward-requirement-ID Integer

Bed-No Integer

Room-No integer

Table 4. Ward facility

Pharmacist

Name Type Description

Pharmacist-ID Integer Not null, primary key

Pharmacist-name Varchar

Patient-ID Integer Foreign key references to

prescription

Table 5. Pharmacist

51
 Prescription

Name Type Description

Medical-prescription-ID Integer Not null, primary key

Doctor-ID Integer

Patient-ID Integer

Table 6. Prescription

Laboratory examination

Name Type Description

Lab-technician-ID Integer Not null, Primary key

Lab-technician-name Varchar

Lab-examination-type-ID Integer

Patient-ID Integer

Lab-examination-result Varchar

Date Datetime

Table 7. Laboratory examination

Hospital report

Name Type Description

Hospital-admin-ID Integer Not null, primary key

Hospital-admin-name Varchar

Daily-report Varchar

Monthly-report Varchar

Annual-report Varchar

Patient-ID Integer Foreign key references to

registration

Table 8. Hospital report

52
 User administration

Name Type Description

User-admin-ID Integer Not null, primary key

User-admin-name Varchar

Stuff-No. Integer Foreign key references to

stuff identification

Table 9. User administration

Stuff identification

Name Type Description

Department Varchar

Stuff-username Varchar

Stuff-password Integer

Stuff-No. Integer Not null, primary key

Table 10. Stuff identification

53
 Chapter Five

Conclusion and Recommendation

Hospital management Information System is an application that provides a common source

of information about a patient/doctor health information. The system have to keep data in
secure place and controls who can reach the data in certain circumstances.

54