Hospital Management System

Hospital Management System The hospital has several specialized departments like
Cardiology, Gynecologic, Orthopedics, Pediatrics, ENT etc. OPD is another independent
department. A doctor is only associated with one specialized department at a time though
he/she can be a member of the OPD(Outside Patients Department) department. Each
doctor has a visiting time and day in a week. At reception the patient details are entered
and the fees are also taken and the patient is tracked on the basis of the Id generated. In
routine a patient can visit the doctors either directly selecting a doctor manually or by
getting admitted to the hospital and then a doctor visits the patients. A doctor can prescribe
tests for the patient to perform . The patient visits the lab to get done the tests prescribed
by the doctor. The reports are given to the patient. The payments pertaining to the tests are
done at the reception. Referring the reports, the doctor prescribes the patient medicines or
further tests or is asked to get admitted. A patient is admitted into a ward of a specialized
department (if available) as per the doctor’s prescription. The number of wards is limited
and if there is no vacant ward the admission of the patient is rescheduled. As per the
prescription of the doctor the patient is operated on a specified date and time as decided by
the doctor who is doing the operation. After the completion of the treatment a patient may
get discharged on an advice of a doctor and upon the complete payment of all due charges
at the reception. On payment of full dues, the reception generates a discharge ticket for the
patient
Valid considerations:
Inclusions
• Admin – Maintains the doctor time sheets,
• Lab in charge – upload fee details, upload reports.
• Pharma in charge – enter medicine payment details. And generating bills
• Every payment is routed to reception by maintaining CBS (centralized billing system)
• Patient is restricted to access the system
Exclusions – Not applicable
USE CASE DIAGRAM
ACTIVITY DIAGRAM
 USE CASE SPECIFICATIONS

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 1.1 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. 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. 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 recheck 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 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 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 1.1 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”. The Use case resumes at Step 2 & 3
6. Exceptional Flow Valid error condition is displayed if there is any error.
7. Post –Conditions Receptionist can check Doctor’s availability ‘N’ number of times.

Use Case Name: Receives 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 patient’s account.

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.
Forward 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”.
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 ward availability status ‘N’ number of times

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 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.
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 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 Unable to upload Test Due to some reason, If the doctor is not able to
upload the list of prescribed tests, 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 upload the test details.

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
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 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 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 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 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 Name: Upload Test Details

1. Use Case Description In this use case the lab in charge, after collecting test samples from
the patient 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 Flow 1.1 Unable to upload test reports 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 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
in charge
must have valid Patient ID and list of tests.
4. Basic Flow
Step 1: Lab In-charge opens HMS
Step 2: Inserts 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 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 in charge must have valid Patient ID and list of prescribed medicine.
4. Basic Flow
Step 1: Pharma In-charge opens HMS
Step 2: Inserts Patient ID.
Step 3: Check’s list of prescribed medicine.
Step 4: Update medicine payment details.
5. Alternative Flow 1.1 Unable to update medicine payment. If the pharma in-charge is not
able to update the medicine payment details, the system should through error saying
“Submit 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 Pharma in-charge is able to successfully update the medicine payment
detail.