Hospital Management System

 Use-Case Specifications :
 1. Use-Case Name: Enter Patient Details

1.1 Brief Description

The receptionist enters the details of a patient in to the system at the time of registration.

1.2 Actors

1.Receptionist

1.3 Flow of Events

1.3.1 Basic Flow

The use case begins when the receptionist signals that he/she wants to log patients details.

System displays the registration form.

Receptionist enters patient’s details by giving generated ID(old patients) or by giving other
details(new patients).

System records the details in the data base

The use case ends.

1.3.2 Alternative Flows

1.3.2.1 Receptionist cancels the registration

At any time during the use case prior to receptionist making payment, he/she may signal
system that he/she wishes to cancel this registration.

The use case ends.

1.3.2.2 Patient not registered/wrong tacking id

This flow begins when receptionist signals that he/she wishes to log patent’s tracking id and
there are no registrations for the patient in the system.

System displays an error message.

The use case ends.

1.4 Special Requirements

The system must support 10 or more simultaneous receptionist users.

1.5 Preconditions

There is a active network to the hospital.

Receptionist should have proper logins.

1.6 Post-conditions

1.6.1 Successful Post – conditions

System has logged patient details in the hospital DB.

1.6.2 UnSuccessful Post-condition

No changes have been made to the state of the database.

 2 Use-Case Name :Check ward Availability

2.1 Brief Description

The receptionist performs’ search ‘ for ward availability by entering admission date

2.2 Actors

1.Receptionist

2.3 Flow of Events

2.3.1 Basic Flow

The use case begins when the receptionist signals that he/she wants to check the ward
availability.

System displays fields to enter admission date

Receptionist enters the admission date.

System displays the ward availability as available

The Use case ends.

2.1.2 Alternative Flows

2.3.2.1 Receptionist enters an incorrect date (Not within time limit)

This flow begins when receptionist signals that he/she wishes to search the ward availability.

System displays field to enter admission date .

Receptionist enters date which is not within the time limit.

System displays an error message .

If wards are not available system should prompt to show error an message.

Receptionist enters date which is within the time limit.

The use case ends.

2.2 Special Requirements

The system must support 10 or more simultaneous receptionist users.

The system shall keep a record of all successful reservations .

2.3 Preconditions

There is a active network to the hospital

Patient must done the registration.

2.4 Post-conditions

2.4.1 Successful Post – conditions

System displays ward availability status as-Available

2.4.2 UnSuccessful Post-condition

System displays ward availability status as-Not available

3. Use-Case Name: Admit the patient

3.1 Brief Description

The receptionist enters the details of a patient in to the system at the time of Inpatient
admission

3.2 Actors

1.Receptionist

2.System clock

3.3 Flow of Events

3.3.1 Basic Flow

The use case begins when the receptionist signals that he/she wants to admit a patient.
System displays the form to enter patient details.

Receptionist enters the patient tracking id.

System displays an admission note and prompts for user confirmation.

Receptionist confirms the note.

System displays booking status.

Use case ends.

3.3.2 Alternative Flows

3.3.2.1 Receptionist enters wrong tracking id

The use case begins when the receptionist signals that he/she wants to admit a patient.

System displays the form to enter patient’s tracking id.

Receptionist enters incorrect tracking id.

System displays an error message.

Use case ends.

3.3.2.2 Ward is not available

This flow begins when receptionist signals that he/she wishes to admit the patient.

System displays the form to enter patient’s tracking id.

Receptionist enters correct tracking id.

System performs a ward availability check in data base and find that wards are not available, so

System displays the ward availability status as –Not available.

Use case ends.

3.4 Special Requirements

The system must support 10 or more simultaneous receptionist users.

3.5 Preconditions

There is a active network to the hospital

receptionist must have successfully completed the login

3.6 Post-conditions

3.6.1 Successful Post – conditions

System keeps a record of the ward and the details of patient who reserved in the database.

3.6.2 UnSuccessful Post-condition

No changes has been made in data base

4. Use-Case Name: Generate Discharge Ticket

4.1 Brief Description

The receptionist generate a discharge ticket for patient on doctors advice

4.2 Actors

1.Receptionist

2.System clock

3.Doctor

4.3 Flow of Events

4.3.1 Basic Flow

The use case begins when the receptionist signals that he/she wants to generate a discharge

ticket for patient.

System prompts to enter patient’s tracking id.

Receptionist enters the tracking id.

System displays the payment dues of the patient and prompts to make that payment.

Receptionist makes that payment.

System displays the discharge ticket.

The use case ends.

4.3.2 Alternative Flows

4.3.2.1 Receptionist cancels the registration

At any time during the use case prior to receptionist making payment, he/she may signal
system that

he/she wishes to cancel this registration.

The use case ends.

4.3.2.2 Receptionist enters an invalid tracking id

The use case begins when the receptionist signals that he/she wants to generate a discharge

ticket for patient.

System prompts to enter patient’s tracking id.

Receptionist enters an invalid tracking id.

System displays an error message.

Use case ends.

4.3.2.3 Receptionist enters an incorrect tracking id

The use case begins when the receptionist signals that he/she wants to generate a discharge

ticket for patient.

System prompts to enter patient’s tracking id.

Receptionist enters an incorrect tracking id.

System fetches the details of another patient from data base.

Receptionist closes the window.

Use case ends.

4.4 Special Requirements

The system must support 10 or more simultaneous receptionist users.

4.5 Preconditions

There is a active network to the hospital

receptionist must have successfully completed the login

4.6 Post-conditions

4.6.1 Successful Post – conditions

System generates a tracking id and keep a record of that in database.

4.6.2 UnSuccessful Post-condition

No changes have been made to the state of the database

5 Use-Case Name: fee collection

5.1 Brief Description

Every payment is routed to reception by maintaining a CBS(centralized billing system)

5.2 Actors

1.CBS

2 receptionist

5.3 Flow of Events

5.3.1 Basic Flow

The use flow begins when any of the facility updates bills for the services

CBS consolidates these bills based on “tracking id.”

Receptionist requests for consolidated bills for a particular tracking id.

CBS route these consolidated bill to the receptionist.

*patient can able to pay consultation fee

* patient can able to pay medicine fee

* patient can able to pay lab fee

* patient can able to pay pharma fee

* patient can able to pay discharge fee(including dues).

Use case ends.

5.3.2 Alternative Flows

5.3.2.1 Facilities failed to update bills

This flow begins when receptionist signals that he/she wishes to make payment on behalf of
a patient.

CBS throw an error message.

Use case ends.

5.4 Special Requirements

The system must support 10 or more simultaneous receptionist users.

4.5 Preconditions

There is a active network to the hospital

receptionist must have successfully completed the login

5.6 Post-conditions

5.6.1 Successful Post – conditions

CBS route consolidated bills to receptionist.

5.6.2 UnSuccessful Post-condition

System fails to fetch consolidated bill of a patient from CBS

6 Use-Case Name: Maintains doctors time sheets

6.1 Brief Description

The Admin maintains doctors time sheets

6.2 Actors

1.Admin

6.3 Flow of Events

6.3.1 Basic Flow

The use flow begins when the admin signals that he/she want to make changes in doctors
time sheets

System displays the time sheets.

Admin make changes in time sheets.

Use case ends.

6.3.2 Alternative Flows

NA

6.4 Special Requirements

The system must support only one admin users

6.5 Preconditions

There is a active network to the hospital

receptionist must have successfully completed the login

6.6 Post-conditions

6.6.1 Successful Post – conditions

Changes in time sheet will reflect in data base.

6.6.2 UnSuccessful Post-condition

No changes have been made to the state of the database.

7 Use-Case Name: generate ID

7.1 Brief description

The use case describes how to generate id. This step begins with after registration and
payment step

7.2 Actors

1 system clock

7.3 Flow of Events

7.3.1 Basic flow

The use case begins when paymet is done

System will generate id and it stored in hospital DB

Use case ends.

7.3.2 Alternative Flows

*IF receptionist gives wrong deails system should promt to show a error message

*if use case 5 step failed , system should give a error message ”kidly do paymet”.

7.4 Special Requirements

The system must support 10 or more simultaneous receptionist users.

7.5 Preconditions

Preconditions

There is a active network to the hospital

receptionist must have successfully completed the login

7.6 Post-conditions

7.6.1 Successful Post – conditions

System keeps a record of the ward and the details of patient who reserved in the database.

7.6.2 UnSuccessful Post-condition

No changes has been made in data base

The use case ends.

8.Use-Case Name: Prescribe test

8.1 Brief Description
The Doctor enters lab test prescription in system.
8.2 Actors
1.Doctor
8.3 Flow of Events
8.3.1 Basic Flow
The use case begins when the Doctor signals that he/she wants to prescribe lab test for patient.
System prompts to enter patient’s tracking id
Doctor enters patient tracking id.
System displays field to enter prescription.
Doctor enters the prescription.
 Use case ends.
8.3.2 Alternative Flows
8.3.2.1 Doctors enters invalid tracking id
The use case begins when the doctor signals that he/she wants to prescribe lab test

System prompts to enter tracking id

Doctor enters an invalid id.

System displays an error message.

Use case ends.

8.4 Special Requirements

The system must support 10 or more simultaneous Doctor users.

8.5 Preconditions
There is a active network to the hospital

Before starting this use case , doctor s must have successfully completed the login use case resulting in
permission being granted for the role of Doctor.

8.6 Post-conditions
8.6.1 Successful Post – conditions
System has recorded prescription in database.

8.6.2 UnSuccessful Post-condition

No changes have been made to the state of the database.

Use case ends.

9.Use-Case Name: Prescribe Medicine

9.1 Brief Description
The Doctor enters medicine prescription in system.
9.2 Actors
1.Doctor
9.3 Flow of Events
9.3.1 Basic Flow
The use case begins when the Doctor signals that he/she wants to prescribe medicine for patient.
System prompts to enter patient’s tracking id
Doctor enters patient tracking id.
System displays field to enter prescription.
 Doctor enters the prescription.
Use case ends.
9.3.2 Alternative Flows
9.3.2.1 Doctors enters invalid tracking id
The use case begins when the doctor signals that he/she wants to prescribe lab test

System prompts to enter tracking id

Doctor enters an invalid id.

System displays an error message.

Use case ends.

9.4 Special Requirements

The system must support 10 or more simultaneous Doctor users.

9.5 Preconditions
9.5.1 Successful Login
Before starting this use case , doctor s must have successfully completed the login use case resulting in
permission being granted for the role of Doctor.

9.6 Post-conditions
9.6.1 Successful Post – conditions
System has recorded prescription in database.

9.6.2 UnSuccessful Post-condition

No changes have been made to the state of the database.

Use case ends.

10.Use-Case Name: View Reports

10.1 Brief Description
The Doctor views the lab reports of his /her patient
10.2 Actors
1.Doctor

10.3 Flow of Events

10.3.1 Basic Flow
The use case begins when the Doctor signals that he/she wants to view the lab report

System prompts to enter tracking id

Doctor enters the tracking id.

System displays the report

Use case ends.

10.3.2 Alternative Flows

10.2.3.1 Doctor enters invalid tracking id

The use case begins when the Doctor signals that he/she wants to view lab test result..

System prompts to enter tracking id

Doctor enters an invalid tracking id

System displays an error message.

Use case ends.

10.4 Special Requirements

The system must support 10 or more simultaneous Doctor users.
10.4 Preconditions
10.4.2 Successful Login
Before starting this use case , Doctor must have successfully completed the login use case resulting in
permission being granted for the role of Doctor
10.5 Post-conditions
10.5.2 Successful Post – conditions
Test results are stored in data base

10.5.3 UnSuccessful Post-condition

No changes have been made to the state of the database

Use case ends.

11.Use-Case Name: Enter medicine deatails

11.1 Brief Description
The Pharmacy in-charge upload medicine bills
11.2 Actors
.. 1 .Pharmacy in-charge

11.3 Flow of Events

11.3.1 Basic Flow
The use case begins when the Pharmacy in-charge signals that he/she wants to enter medicine
details

.System displays fields to enter tracking id, medicine description and bill amount.

Pharma in-charge enters the required information.

System displays an upload confirmation page.

Use case ends.

11.3.2 Alternative Flows

11.3.2.1 Pharmacy in-charge enters invalid tracking id
*The use case begins when the Pharmacy in-charge signals that he/she wants to upload lab
charges.

System prompts to enter tracking id

Pharmacy in-charge enters an invalid id.

System displays an error message.

Use case ends.

11.3.2.2 f
ailed to provide medicine

This flow begins when pharmacist enter medicine details ,if particular medicine not available
then system should prompt the error message “medicine not available”.

And flow should continue for remaining medicine.

11.4 Special Requirements

The system must support 10 or more simultaneous pharma in - charge users.
11.5 Preconditions
11.5.2 Successful Login
Before starting this use case , Pharmacy in-charge must have successfully completed the login use
case resulting in permission being granted for the role of Pharmacy in-charge
11.6 Post-conditions
11.6.2 Successful Post – conditions
Pharmacy in-charge uploads medicine bills
11.6.3 UnSuccessful Post-condition
No changes have been made to the state of the database.

Use case ends.

12 Use-Case Name: generate bills

12.3 Brief Description
The pharma in – charge generate the bills

12.4 Actors
.. 1.pharma in-charge

12.5 Flow of Events

12.5.2 Basic Flow
The use case begins when the lab in-charge signals that he/she wants to generate medicine
charges.

System displays fields to enter tracking id, medicie description and bill amount.

Pharma in-charge enters the required information.

System displays an upload confirmation page.

Use case ends.

12.5.3 Alternative Flows

12.5.3.1 Lab in-charge enters invalid tracking id
The use case begins when the pharma in-charge signals that he/she wants to upload lab
charges.

System prompts to enter tracking id

pharma in-charge enters an invalid id.

System displays an error message.

Use case ends.

12.6 Special Requirements
The system must support 10 or more simultaneous pharma in - charge users.
12.7 Preconditions
12.7.2 Successful Login
Before starting this use case , lab in - charge must have successfully completed the login use case
resulting in permission being granted for the role of pharma in - charge.
12.8 Post-conditions
12.8.2 Successful Post – conditions
pharma in charge will generate bills

12.8.3 UnSuccessful Post-condition

No changes have been made to the state of the database.

Use case ends.

13 Use-Case Name: Upload lab fee details

13.3 Brief Description
The lab in – charge upload lab charges.

13.4 Actors
.. 1.Lab in-charge

13.5 Flow of Events

13.5.2 Basic Flow
The use case begins when the lab in-charge signals that he/she wants to upload lab charges.

System displays fields to enter tracking id, test description and bill amount.

Lab in-charge enters the required information.

System displays an upload confirmation page.

Use case ends.

13.5.3 Alternative Flows

13.5.3.1 Lab in-charge enters invalid tracking id
The use case begins when the lab in-charge signals that he/she wants to upload lab charges.

System prompts to enter tracking id

Lab in-charge enters an invalid id.

System displays an error message.

 Use case ends.

13.6 Special Requirements

The system must support 10 or more simultaneous lab in - charge users.
13.7 Preconditions
13.7.2 Successful Login
Before starting this use case , lab in - charge must have successfully completed the login use case
resulting in permission being granted for the role of lab in - charge.
13.8 Post-conditions
13.8.2 Successful Post – conditions
Lab in charge uploads lab charges

13.8.3 UnSuccessful Post-condition

No changes have been made to the state of the database.

Use case ends.

14 Use-Case Name: upload reports

14.1 Brief Description
The lab in-charge upload reports

14.2 Actors
.. 1 .lab in-charge

14.3 Flow of Events

14.3.1 Basic Flow
The use case begins when the lab in-charge signals that once reports has been geerated

.System displays fields to enter tracking id, test details and results

lab in-charge enters the required information.

System displays an upload confirmation page.

Use case ends.

14.3.2 Alternative Flows

* Lab in-charge enters invalid tracking id
*The use case begins when the lab in-charge signals that he/she wants to upload reports

System prompts to enter tracking id

Pharmacy in-charge enters an invalid id.

System displays an error message.

Use case ends.

14.4 Special Requirements
The system must support 10 or more simultaneous lab in - charge users.
14.5 Preconditions
15 There is a active network to the hospital
16 Lab I charge must have successfully completed the login

14.6 Post-conditions
14.6.1 Successful Post – conditions
Pharmacy in-charge uploads medicine bills

14.6.2 UnSuccessful Post-condition

No changes have been made to the state of the database.

Use case ends.