Scenario Name Diagnosis

Participating Actor  Receptionist-Kidist

 Doctor/Specialist- Dr. Mengesha

Entry Condition The patient enters to the diagnosis room where

he/she meets the doctor

Flow of Event 1. The patients’ document is received based on

order from reception class.

2. Disease diagnoses takes place here.

3. Based on the diagnoses the doctor orders

the patient to the laboratory orders the
medicine for the patient or give advice to
the patient.

4. Note for laboratory is prepared.

Scenario name Write Prescription

Participation actor Doctor-Dr.Mengesha

Patient-Tariku

Entry condition The doctor receives laboratory result

Flow event 1. The doctors tell the result to the patient

2. The doctor take out the prescription form

and writes medicine to the form and tell the
patient how to use the medicine

3. The doctor writes the patient history in to the

patient card.

Table 4.as-is scenario for diagnosis

1
 Scenario Name LaboratoryTestResult

Participating Actors  Doctor/Specialist- Dr. Mengesha

 Laboratory Technician-Biruk, Cashier-Selam

Entry Condition The Cashier sends filled Test order form written by the
doctor to the laboratory class after laboratory payment
takes place.

Flow of Event 1. The patient comes to the laboratory class.

2. The tests take place based on the test request from

the doctor.

3. The filled test result form sends to the doctor.

Table 5.as-is scenario for Laboratory test result

2
Table 7.as-is scenario for Write Prescription

3.4.2 Use case model

Use case name Addpatient

Participating actors Receptionist , patient
Entry condition The receptionists logged to the system
Flow of event 1. The receptionist click on “New” button
2. The system responds by displaying a “new patient
registration form(card)”
3. The receptionist fill all data(name, age, address, sub
city, Kebele, H.NO ,TEL ,occupation, marital status )
4. The receptionist ask to what diagnosis room wants to
go
5. The receptionist fill data in the provided place in the
form
Exit condition The receptionist send the card to the cashier
Quality requirement The patient must be capable of communicating with the
receptionist or the patient must be with another person who
knows his profile.

Table 8.add patient use case

3
 <<Uses>> Adduser

Receptionists

Fig 1 add patient use case model

Use case name Renew patient
Participating actor Receptionist , patient
Entry condition The patient comes to receptionist desk ,The receptionists
logged to the system
Flow of event 1. HMS respond by displaying the reception form
which contain list of menus (renew patient, new
patient).
2. The receptionist open renew patient.
3. HMS respond by displaying renew patient form
which contain search fields by card number and
name
4. The receptionist asks the card number and enters in
to the search field and submitted by pressing the
search button.
5. The system responds by displaying the search result
6. The receptionist activates the patient card

Alternativeflow  The patient doesn’t know the card number

The search will held by Name
 The search result not found
Exitcondition The receptionist send the card to the cashier
4
Quality The patient must know his/her card number.
requirement
Table 9. renew patient use case

<<Uses>> Renewpatient

Receptionists

Fig 2.renew patient use case model

Use case Name WritePrescription
Participating actor Doctor
Entry condition The doctor logged to the HMS
Flow of Event 1. HMS responds by displaying “diagnosis window”
with list of menu (prescription, laboratory request…)
2. The doctor opens the prescription form
3. The HMS responds by displaying the prescription
form which contain view lab result menu, text fields
for (patient name, age, sex, card number, doctor
name, date) and text box to write list of medicines.
4. The doctor press view result button.
5. HMS display laboratory result form.
6. By looking on the test result the doctor typed the
information listed above and press save button.
7. The HMS respond by display conformation message
alert with yes and no button
8. The doctor press “YES” button
9. The HMS saves the prescription as patient’s history to
the database.

5
 Alternative flow  The patient has no laboratory test.
go to step 6
 The doctor press the “NO” button
The HMS backs to the prescription form.
Exit condition The doctor presses yes button after saving the information.
Quality The doctor must carefully press the buttons available.
requirement
Table 10.write prescription use case

Writeperscription

Doctor

Fig 3.write prescription use case model

Use case name LaboratoryRequest
Participating Doctor
Actor
Entry condition The doctor logged to HMS
Flow of Event 1. HMS responds by displaying “diagnosis window” with
list of menu (prescription, laboratory request, orders, lab
result )
2. The doctor opens the laboratory request form.
3. The HMS responds by displaying the laboratory “request
form” which contain text field for patient information
(name, card Number, age, sex, and date), doctor name
which make the request and list of tests.
4. The doctor types the information and select test by
clicking on the check box and press the send button.
5.The HMS sends the form to the casher and display the
conformation whether the form is properly delivered to the
cashier.
6
Exit condition The doctor presses send button.
Quality The doctor must have information about what kind of service
requirement are still available in the laboratory.

Table 11.laboratory request use case

Laboratory Request

Doctor
Fig 4.Laboratory Requestuse case model
Use case Name ViewOrder
Participating actor Doctor
Entry condition The doctor logged to the system, the receptionist send the order
to the doctor
Flow of event 1. HMS responds by displaying “diagnosis window” with
list of menu (prescription, laboratory request, orders, lab
result )
2. The doctor selects the orders menu.
3. HMS displays a form with list of patient orders.
4. The doctor selects the first order in the list.
5. HMS displays selected patient information.

Exit condition The doctor gets the information of the patient.

Quality requirement The doctor must carefully see the order.

7
Table 12.view order use case

Vieworder

Doctor Fig 5 write prescription use case model

Use Case Name LaboratoryTestResult

Participating Actor Lab Technician, Cashier
Entry condition Lab Technician and Cashier login to the system.
The patient pay for laboratory payment
Flow of event 1. HMS display the “view”, ”send” button
2. Lab technician clicks on “viewOrder” button.
3. HMS responds the “list of patient order”.
4. Lab technician select on one of the “list of
patients order”.
5. HMS open “Lab test order form”.
6. Lab Technician fills on the “test result form” the
value field, unit field and abnormality field based
on test measure range for every ordered test.
7. Lab Technician clicks on “send” button and
sends “test result form” to the doctor.
8. HMS send delivery report by sending message
“delivered”.
Alternative Scenario  The system does not send delivery report in 30
seconds.
 The lab technician resend the “test result form ”
Exit condition The “test result form” is delivered to the doctor.
Quality requirement The lab technician must be careful while filling the
“test result form”

Table13 Laboratory Test result use case

8
 <<Uses>> Test result

<<extends>>

View order
Lab Technician

Fig 6. test result

Use Case Name ChargePayment

Participating Actor Cashier, Patient
Entry Condition Cashier log to the system.
Orders from Receptionist and order from doctor
come to payment center.
Flow of Event 1. The system display “prepayment”, ”Payment”,
”inpatient”, ”outpatient” buttons.
2. The patient comes with order from receptionist
for card or from doctor for laboratory.
3. The cashier asks for what service the patient
wants to pay.
4. The cashier clicks on “payment” button.
5. The HMS displays the “payment form”
6. The cashier fills on the selected field and
clicks on “paid” button.
7. The HMS sends info to corresponding
department.
8. HMS responds delivery report.
Alternative scenario  HMS doesn’t respond in 30 seconds.
 The cashier clicks on “resend” button
Exit condition The data sent to the next party.
Quality requirement The payment must include legal receipts and the
patient must have the required amount of money
Table 14. charge payment Use case

9
Fig 7 charge payment use case model

Use Case AdvancedPayment

Participating Actor Cashier, doctor
Entry Condition The doctor identified that the patient is identified.
The patient pays prepayment.
Flow of Event 1. The system display “Payment”, “view”,
”prepayment” in the cashier side.
2. The cashier clicks on “Payment” button.
3. The system display “prepaymentForm”.
4. The cashier fills in the “amount” field.
5. HMS displays “advancedPayment form”,
“prepayment” buttons in the doctor side.
6. The doctor clicks on “prepayment”.
7. The HMS display the left amount for the patient
using patient ID
8. The doctor checks that the payment is enough for
payment.
9. The doctor fills on “medicineName”, “quantity”,
“unitPrice”, “TotalPrice”, “procedure” fields in
the “advancedPaymentform”.
10.The HMS discounts the total price from
prepayment.
Alternate Scenario  Doctor checks that the payment is not enough for
ordered medicine.
 Doctor tell the patient to pay additional payment.

Exit condition The patient pays the total price and the cashier gives
receipt
10
Quality requirement The patient must have the money.
The cashier must provide receipt.
Table 15.advanced payment use case

Fig 8. advance payment use case model

Use Case Name Login

Participating Actor Staff
Entry Condition Manager has user name and password
Flow of Event 1. System display “username” and
“password” field.
2. Staff enters in “username and password”
in the field.
3. System authenticates that the username
and password are correct.
4. System log to the system.

Alternative Event  System authenticates that the user name

and password are incorrect.
 System ask the staff to re-enters the fields.
Exit condition When Staff logs in.
Quality requirement The staff must not forget their username and
password.
Table 16.login use case

11
Fig 9.login use case model
Use Case Name AddAccount
Participating Actor Manager, user
Entry Condition Manager gets user’s name
Flow of Control 1. System display “create”, “remove” buttons.
2. Manager clicks on “create” button.
3. HMS display “AccountCreate form” that contains
“UserName”, “PassWord”, fields .
4. Manager fills in this fields and clicks on “create”
button.
Exit condition When create button is clicked.
Quality requirement It must contain different user name and password.
Table 17 add account use case

Fig 10 add account

Use Case Name RemoveAccount
Participating Actor Manager, user
Entry Condition Manager gets user’s name and password from user
Flow of Control 1. System display “create”, “remove” buttons.
2. Manager clicks on “remove” button.
3. HMS display “RemoveAccount form” that
contains “UserName”, “PassWord”, fields .
4. Manager fills in this fields and clicks on
“remove” button.
Exit condition When remove button is clicked.
Quality requirement The must be sure that the user will no longer have
access to the system.
Table 18 remove account use case

12
Fig 11 add account use case mode
General Use Case Model

fig 12 Generalized use case model

3.4.3 Object model

When we implement the hospital management system we will have Patient,
Employee, Doctor, LaboratoryTechnician, Receptionist, Cashier, Manager,
Account and Department classes.The Doctor, LaboratoryTechnician, Receptionist,
Casher, Manager classes will inherit from the Manager class. There description is
shown below.

13
 Class Patient

This class is used to store patients’ information. It contains Full name, age,
address, sub city, kebele, House number, telephone number, occupation and
marital status as attribute. Also will have set and get method for those attributes.

Class Employee

This is a generic class other class like Doctor, LaboratoryTechnician,

Receptionist, Casher and Manger will inherit from this. This class will contain
Name, Id, Account, and department as an attribute. Also will have set and get
method for those attributes.

Class Doctor, LabratoryTechnician, Receptionist, Casher and Manager

This classes inherits from the Employee class and will have a method related to
their jobs this methods are shown in the class diagram.

Class Account

This class is used to manage the user accounts and is only created by the
manager. But all users can change their own user name and password. It will have
username and password as an attribute and changeuname() and changepass() as a
method.

Class Department

This class is used to store the information of department having dname,

description, numofemployee, as an attribute and addemp() and removemp() as a method.

3.4.3.1 Data dictionary

14
3.4.3.2 Class diagrams
Fig 12 class diagram

fig 13.class diagrams

15
3.4.4 Dynamic models
Sequence Diagrams

Fig 14 sequence diagram for new patient registration

16
Fig 15 sequence diagram for renew patient registration

17
Fig 16 sequence diagram for adding account

18
Fig 17 sequence diagram for remove account

19
Fig 18 sequence diagram for lab test order

20
Fig 19 sequence diagram for login

21
Fig 20 sequence diagram for charge payment

22
Fig 21 sequence diagram for advanced payment

23
Fig 22 sequence diagram for writing prescription

24
Fig 23 sequence diagram for view order

25
 Fig 24 sequence diagram for lab result form

3.4.5 User interface—navigational paths and screen mock-ups

4. Glossary

26