3.

Proposed system
3.1 Overview
The proposed system is aimed at providing simple, efficient, and effective
means by which the hospital management system increases accuracy and increase
client satisfaction. The system will try to solve many problems related to the card
management in the hospital which are listed above and also try to facilitate the jobs
in the hospital.

3.2 Functional requirements

Functional requirements describe the interactions between the system and its
environment independent of its implementation. The environment includes the user
and any external system with which the system interacts.

The functional requirements - activities and services that this system provide
are listed below:

R1: The receptionist shall Register Patient’s Full name, age, address, sub
city, kebele, House number, telephone number, occupation and marital status

R2. The system shall generate card number automatically in order starting
from 001

R3: The system shall store all patients’ information including the new
generated card number as an identifier consistently.

R4: The reception shall send full name, card number, age, occupation and
marital status of the patient to the respected diagnostic departments.

R5: If the patient is not new for the hospital the Doctor shall get patients
history from the database.
R6: The Doctor shall send patient’s full name card number the name of tests
that are required to the casher

R7: The cashier shall get the card number, full name and name of the testes
from the doctor

R8: The casher shall calculate the total payment for the testes automatically
and generate receipt.

R9: The casher shall send the full name, card number and name of tests to
the laboratory technician.

R10: The Laboratory Technician shall send to the doctor patient’s full name
card number, name of tests and the respective results gotten from the test.

R11: The Doctor shall store the name and amount of medicine ordered for
inpatients.

R12: The system shall calculate the payments for outpatients.

R13: The system shall calculate advanced payment for inpatients by

reducing the amount of service charge from the prepaid amount.

R14: A Receptionist, Doctor, Laboratory Technician shall search the patient

in their name and card number.
3.3 Nonfunctional requirements
Nonfunctional requirements of the system are as follows:

3.3.1. Usability
NFR1: The user should understand the basic computer skills.

NFR2: Receptionist shall provide instructions to the system using mouse and
keyboard by clicking on the menu items and typing into the fields
provided by the system.

3.3.2. Reliability

NFR3: The system shall keep patients history and it doesn’t give any
information without the patient permission. And patient history will not be lost
or duplicated.

: Data should be backed up once a week.

3.3.3.Performance
NFR4: The system shall have the following mandatory and minimum
requirements:

• The response time of registering, transferring patient record depends on the

internet connection speed the user is using.

• HMS must be available if the user have an access to the internet.

 3.3.4.Supportability
NFR5: HMS is device dependent. Meaning it cannot be accessed any device
that supports internet like mobile and tablet. It should be the hospital
computer.

3.3.5.Implementation
NFR6: HMS is web based application soit uses internet programming
language such as HTML, CSS, javascript, php.

3.3.6.Interface
NFR7: Since users of the hospital management system are the employees of
the hospital starting from the general manager of the hospital down to
the payment service, all of them shall use their own workstation
computers to interact with the system.

: Data shall be imported or exported using the internet connection.

3.3.7.Packaging

NFR8: The system can only installed on a web server.

3.3.8.Legal
NFR9: The hospital should have a license.
3.4 System models
3.4.1 Scenarios
Here are the scenarios that will describe the existing system as as-is scenario
Scenario name New patient registration
Participating actors  Receptionist- Kidist
 Patient-Tariku
Entry condition New patient comes to receptionist to register
Flow of event 1. The receptionist asks the patient info about (name,
age, address, sub city, kebele,
H.NO ,TEL ,occupation, marital status)
2. The patient responds.
3. Kidist fill date and card no in the patient card
4. Kidist ask to what diagnosis room wants to go
5. The patient responds.
6. Kidist gives ID card and tells the patient to wait and
transfer the card to the casher.
Table 1 as-is scenario for new patient registration

Scenario Name RenewPatientRegistration

 Participating Actor  Receptionist-Kidist

 Patient- Tariku

Entry condition The patient come to the receptionist with the patient
ID card that given to him/her past visitation.

Flow of Events 1. Patient comes to the reception desk.

2. Receptionist asks for patient’s card number.

3. Kidist search for Patient’s history document

using patient’s card number.

4. Receptionist asks what department the patient

wants to visit.

5. Kidist sends form for department.

Table 2. as-is scenario for renewing patient

Scenario name Payment

Participation actor  Cashier-Selam
 Patient-Tariku
Entry condition The cashier receives card from receptionist or the
receptionist receives lab test order from the doctor
Flow of event 1. The cashier calls the next person in order
2. The cashier tells to the patient how much to pay
3. The patient pay the requested amount
4. Kidist send the order to Selam
5. The cashier will print a receipt with attachment or
 without attachment
6. Selam will send the card to the diagnosis room or
test form to the laboratory room
Table 3.as-is scenario for payment system