0% found this document useful (0 votes)
347 views

Hospital Management System UML and Specification Document

The document outlines the UML diagram for a hospital management system. The diagram shows the interactions between key entities like Patient, Doctor, Reception and Lab Assistant. It shows the workflow from a patient visiting reception to get registered, paying fees, being allocated a ward, undergoing treatment and tests, getting discharged after completing the process.

Uploaded by

Manish Pareek
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
347 views

Hospital Management System UML and Specification Document

The document outlines the UML diagram for a hospital management system. The diagram shows the interactions between key entities like Patient, Doctor, Reception and Lab Assistant. It shows the workflow from a patient visiting reception to get registered, paying fees, being allocated a ward, undergoing treatment and tests, getting discharged after completing the process.

Uploaded by

Manish Pareek
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 16

Hospital Management System UML and Specification document

Hospital Management System

-End2 «extends»
Register for
Generate ID
treatment
* «extends»
-End1
-End3 -End33 -End34
-End4 Test Fees
**
Pay fees * *
* «extends» * -End35

Reception
Settle Account

* «extends»
Admit To Ward

-End5

* *
-End21
-End9 *
-End11
-End6 Discharge
-End8
* **-End13
* -End7

Patient

-End10 -End22
-End16 -End23 -End24
Piscribe Test Visit Lab For test
* *
* * *
* -End25
-End12
-End18 «extends»
-End15
-End17 Refer Report Pricribe medicine
-End19 *
*
** * -End14
-End20
*
Perform Operation
Doctor *

-End32
-End31
Generate Report
*
-End30
-End40 ** *

LAB Assitent

-End39 ** * * -End36

-End29 *-End38
* -End37
* * -End26

-End28
-End27
Patient Reception

Visit Reception

* -End3

* -End4

Provide Details Enter Details

Generate ID

Pay Fees
Patient Doctor

Visit Patient

Provide Report

Check Report

-End1

*
-End3*
* -End2
-End4

*
Treatment start Dischsrge

-End7

* -End5*
* * -End13
-End6 -End8

Pricrice Test *
Pricribe Medicine

* -End14

*
* Operation
Confirm operation
-End11 -End9
-End10
* -End12
Perform Operation
*
Patient Reception

-End8 *-End7 *
Ward Availablity

* *-End2
-End3 -End1
* -End10
* -End9
* -End11

* -End4 *
-End13 * -End12
-End5 -End6
New Dates -End14
Ask new dates Ward Allocation
*
* *

* -End15
* -End16

Details of patient

* -End17

* -End18

Upgrade ward

* -End19

* -End20
Reception Lab assitent Patient

Check priscription Visit lab for test

* *
ask for sample Provide sample
-End2 -End1
* -End5

* ** -End6
Perform Test
-End8 -End7
* -End3

* -End4

Generate Bills

* -End11

Issue Reciept Pay Bill


* -End12

* -End13
-End10 -End9
Generate Report

* *
* -End21

* -End14
-End15 -End16
Show Reciept
*
*
* -End17

* -End22

-End19 -End20 * -End18


Deliver report
* *
* -End23

* -End24
Patient Reception

* -End1
* -End2
-End7 -End8
Discharge documents Check Details
* *
** -End3
-End4

Generate discharge Ticket

** -End5
-End6

Billing

* -End9

* -End10

* -End13
-End11
*

*
-End12
* *
Pending Bills
* -End16
-End17 -End15
* -End14
-End18 *
-End19 -End20
Pay Pending amount Discharge
* *
* -End21

* -End22
Use Case Specifications

[Use Case Specifications for each Use Case diagrams mentioned above]

Use Case ID : UC001 Use Case Name: Enter Patient Details


   
1. Use Case Description The given use case will enter patient details.
2. Actor Receptionist
3. Pre-Conditions Active network connection should be available
Receptionist should have valid Patient ID before
search.
4. Basic Flow Step 1: Receptionist will open Hospital Management
System.
Step 2 : Receptionist can search Patient by option
Step 3 : Search Patient By Patient ID
Step 4: Receptionist can also register patient.
5. Alternative Flow            No Response from HMS

         If in step 1 of basic flow fails, if


the Receptionist is not able to open HMS then the
use case ends with a failure condition or User
(Receptionist) can take help of the concerned
department, if not able to find the Patient details
with patient ID in search option.

         The Use case Resumes at Step 1


           Unable to Search Patient Details

         If in step 2 of basic flow fails, if


Receptionist are not able to search patient details
from search option then . The use case ends
showing the system prompt error message “unable
display patient” and use case ends with failure note.

         The Use Case resumes at Step 2. 1.3 Wrong


Patient name or ID
         If in step 3 of basic flow fails, if
Receptionist may have entered the Patient name or
ID wrongly. The use case ends showing the system
prompt
error message “unable display
patient
   
  details” and use case ends with
failure note.
         The Use Case resumes at Step 3. 1.4 Not able to
register new patient
         If in step 4 of basic flow fails, if
the Receptionist is not available to register new
patient then the system will display a message “
Patient details not accepted” and ask Receptionist
to re- check the patient detail.

         The use case resumes at Step 4


6. Exceptional Flow Valid error condition is displayed if there is any error

7. Post –Conditions Receptionist is able to successfully view the patient


information needed

Use Case ID : UC002 Use Case Name: Doctors Allocation


   
1. Use Case Description In this use case after Receptionist search patient ID,
can now check the doctor availability for doctor
consultation.
2. Actor Receptionist
3. Pre-Conditions 1.       Active network connection should be available

Receptionist should be able to check doctor


availability as well as fixes appoint with OPD & in-
patients.
4. Basic Flow Step 1 :Receptionist Checks Doctors availability
Step 2 : Fix doctors appoint with OPD
Step 3: Fix doctors appoint with In-patient
5. Alternative Flow             Unable to Checks Doctors Availability

         Receptionist can take assistance from the IT


department, if not able to check the doctor’s
availability.
If the required Doctor availability information is not
loading, Receptionist can contact IT department.

         The use case resumes at Step 1


            Unable to Fix Doctors Appointment
         User (Receptionist) may not able to fix
appointment with the concerned doctor, the system
should through error” Valid error while fixing the
appointment with doctor.”
Receptionist may not be able to re-schedule the
appoint with doctor, the system should through
error that “Appointment Re-scheduling failed”
6. Exceptional Flow Valid error condition is displayed if there is any error
in
7. Post –Conditions Receptionist can check Doctors availability ‘N’
number of times.

Use Case ID : UC003 Use Case Name: Receiving Payment


   
1. Use Case Description In this use case the Receptionist, can receive
payment with regard to consultation fee, lab fee &
pharmacy fee with the help of payment
functionality.
2. Actor Receptionist
3. Pre-Conditions There is an active net connection and Receptionist is
able to successfully receives payment with the help
of payment button
4. Basic Flow Step 1 : Receptionist can receive payment for
consultation fee, lab fee & pharmacy fee.
Step 2: Receptionist can click on the payment
gateway.
Step 3: Receptionist can choose the mode of
payment.
Step 4: Receive the payment
5. Alternative Flow   Unable to receive payment

The Receptionist may not able to receive payment


for patients by any of the source:• If payment
button is not working.
• If the payment gateway session timed out.
• If payment gateway session expires.
the system should through error that “Try Again”
The Use case resumes to Step 2

6. Exceptional Flow Valid error condition is displayed if there is any error


in accessing the information
7. Post –Conditions The payment is being deducted from the patients
account.

Use Case ID : UC004 Use Case Name: ward Allotment


   
1. Use Case Description In this use case the Receptionist can allot ward
to patients as per ward availability and doctor’s
advice.

2. Actor Receptionist
3. Pre-Conditions

Active network connection should be available


For allotment of ward, Receptionist should have
valid patient ID to search.
For ward allotment, the patient must have
reference from doctors that need to be submitted
to Receptionist.
4. Basic Flow
Step 1 :Receptionist Searches patient with patient ID
Step 2 : Checks ward Availability
Step 3: Receptionist can update ward allotment
status to patient.
5. Alternative Flow            Ward List not visible

If the receptionist may not be able to view the ward


availability list, the system should through error that
“Try Again”.
  The Use case resumes to Step 2.

Unable to update Ward Availability Receptionist


may not be able to edit details
related to ward allotment; the system should
  through error that “Try Again”.
6. Exceptional Flow The use case resumes to Step 3.
Valid error condition is displayed if there is any error
  in
7. Post –Conditions Receptionist can check ward availability status ‘N’
number of times

Use Case ID : UC005 Use Case Name: Patient Discharge


   
1. Use Case Description In this use case Receptionist can access the Patient
Discharge formality as per doctor advice and part
due’s

2. Actor Receptionist
3. Pre-Conditions Active network connection should be available
For discharge certificate, Receptionist should have
valid patient ID to search.
For discharge certificate, the patient must have
reference from doctors that need to be submitted
to Receptionist.

4. Basic Flow Step 1 :Receptionist Searches patient with patient ID

Step 2 : Checks Patient Discharge formality


Step 3: Receptionist can update discharge status to
  patient.
5. Alternative Flow

1.1 Patient Discharge Formality not visible


If the receptionist may not be able to view the
patient discharge formality, the system should
through error that “Try Again”.
The Use case resumes to Step 2.
1.3 Unable to update Discharge Formality
Receptionist may not be able to edit details related
to discharge; the system should through error that
“Try Again”.
The use case resumes to Step 3.
6. Exceptional Flow Valid error condition is displayed if there is any error
in
   
7. Post –Conditions Receptionist can check discharge status of patient
‘N’ number of times.

Use Case ID : UC006 Use Case Name: Practice Test


   
1. Use Case Description In this use case the Doctors can prescribe test to the
patient after check up.
2. Actor Doctor
3. Pre-Conditions There is an active net connection and
Doctor must have required patient information
before check up.

4. Basic Flow Step 1 : Doctor can check up patient


Step 2: Doctor can prescribe test
5. Alternative Flow

1.1 Unable to upload Test


Due to some reason, If the doctor is not able to
upload the list of prescribed test, the system should
through error saying “Upload Test Details Again”
The use case will resume step 2.
6. Exceptional Flow Valid error condition is displayed if there is any error
in
7. Post –Conditions Doctor can successfully uploads the test details.

Use Case ID : UC007 Use Case Name: Prescribe Medicine


1. Use Case Description In this use case the Doctors can prescribe
medicine to the patient after check up.
2. Actor Doctor
3. Pre-Conditions There is an active net connection and
Doctor must have required patient information
before check up.
4. Basic Flow Step 1 : Doctor can check up patient
Step 2: Doctor can prescribe test
5. Alternative Flow 1 Unable to upload Medicine
Due to some reason, If the doctor is not able to
upload the list of prescribed medicine, the
system should through error saying “Upload
Medicine Details Again”
The use case will resume step 2.
6. Exceptional Flow Valid error condition is displayed if there is any
error in submission of the request
7. Post –Conditions Doctor can successfully upload the medicine
details
Use Case ID : UC008 Use Case Name: Review Reports
1. Use Case Description In this use case the Doctors can review patient
reports.
2. Actor Doctor
3. Pre-Conditions Active network connection should be available

For viewing reports, doctor should have patient ID.


4. Basic Flow Step 1 :Doctors opens HMS Step 2 : Inserts Patient
ID.
Step 2: Doctor can prescribe test
Step 3: Checks the test reports published by lab.
Step 4: Doctor can further update patient.
 
5. Alternative Flow 1.1 Unable to view Test report
If the doctor is not able to view prescribed test of
patient, the system should through error saying
“Re-fresh Browser ”
The use case will resume step 3.
6. Exceptional Flow Valid error condition is displayed at the time of form
submission
7. Post –Conditions
Doctor is able to successfully review patient report.

Use Case ID : UC009 Use Case Name: Doctors Time Slot


1. Use Case Description In this use case the Admin can maintain doctor’s
time slot.
2. Actor Admin
3. Pre-Conditions Active network connection should be available
For maintaining doctor’s time slot, the admin must
have valid Doctor schedule.
4. Basic Flow
Step 1 :Admin opens HMS Step 2 : Inserts Doctor ID.
Step 2: Inserts Doctor ID.
Step 3: Checks the Doctors Schedule.

Step 4: Admin can further update doctor’s time slot.


Step 5: Admin submits the schedule.
 
5. Alternative Flow             Doctor Schedule not visible
If the Admin is not able to view doctors schedule by
entering the Doctor ID, the system should
through error saying “Re-fresh Browser ” The use
case will resume step 3.
           Not able to update doctors time

If the Admin is not able to update doctors schedule,


  the system should through error saying “Try Again ”
   
  The use case will resume step 4.
6. Exceptional Flow Valid error condition is displayed if there is any
error in
   
7.Post –Conditions Admin is able to successfully update & maintain
doctor schedule.

Use Case ID : Use Case Name: Upload Test Details


UC010
1. Use Case In this use case the lab in charge, after collecting test samples from the patient
Description must update system
2. Actor Lab In charge
3. Pre-Conditions There is an active net connection

For updating patient test details, the lab in- charge must have valid Patient ID.
4. Basic Flow Step 1 :Lab In-charge opens HMS
Step 2: Inserts Patient ID.

Step 3: Checks the prescribed test as per doctor’s advice.


Step 4: Lab in charge upload the test reports.
Step 5: Lab in charge submit the report.
 
5. Alternative 1.1 Unable to upload test reports
Flow Due to some reason, If the lab in-charge is not able to upload the test reports, the
system should through error saying “Upload Reports Details Again”
The use case will resume step 4.
   
   
   
   
6. Exceptional
Flow Valid error condition is displayed if there is any error in the data entered
   
7.Post –
Conditions Lab in-charge is able to successfully upload the patient test report.

Use Case ID : UC011 Use Case Name: Lab Fee Details


1. Use Case Description
In this use case the lab in charge must have to update lab
fee details depending upon the test taken by the patient.
2. Actor Lab In charge
3. Pre-Conditions There is an active net connection
For updating patient fee details, the lab incharge must
have valid Patient ID and list of test.
4. Basic Flow Step 1 : Lab In-charge opens HMS Step 2 : Inserts Patient
ID.
Step 2: Insert Patient ID
Step 3: Update lab fee details
 
 
 
5. Alternative Flow 1.1 Unable to update Lab Fee
If the lab in-charge is not able to update the lab fee
details, the system should through error saying “Submit
Again”
The use case will resume step 3.
6. Exceptional Flow Valid error condition is displayed if there is any error in
the data entered
   
7.Post –Conditions Lab in-charge is able to successfully update the lab fee
detail.

Use Case ID : UC012 Use Case Name: Enter Medicine Payment


1. Use Case Description In this use case the Pharma in charge must have to update
medicine payment details depending upon doctor’s
prescription.
2. Actor Pharma In charge
3. Pre-Conditions There is an active net connection
For updating medicine payment details, the pharma incharge
must have valid Patient ID and list of prescribed medicine.

 
4. Basic Flow Step 1 : Pharma In-charge opens HMS
Step 2: Insert Patient ID
Step 3: Checks list of prescribed medicine.
Step 4: Update medicine payment details.
 
 
5. Alternative Flow 1.       1.1 Unable to update medicine payment
 

If the pharma in-charge is not able to update the medicine


payment details, the system should
6. Exceptional Flow Valid error condition is displayed if there is any error in the
data entered
   
7.Post –Conditions Pharma in-charge is able to successfully update the medicine
payment detail

You might also like