Hospital Management System

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
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.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.
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
System displays ward availability status as-Available
System displays ward availability status as-Not available
3. Use-Case Name: Admit the patient
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.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.
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.5 Preconditions

receptionist must have successfully completed the login
3.6 Post-conditions
System keeps a record of the ward and the details of patient who reserved in the database.
No changes has been made in data base
4. Use-Case Name: Generate Discharge Ticket
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.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
ticket for patient.
Receptionist enters an invalid tracking id.
Use case ends.
4.3.2.3 Receptionist enters an incorrect tracking id
ticket for patient.
Receptionist enters an incorrect tracking id.
System fetches the details of another patient from data base.
Receptionist closes the window.
Use case ends.
4.5 Preconditions

4.6 Post-conditions
System generates a tracking id and keep a record of that in database.
No changes have been made to the state of the database
5 Use-Case Name: fee collection
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.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.
4.5 Preconditions
5.6 Post-conditions
CBS route consolidated bills to receptionist.
System fails to fetch consolidated bill of a patient from CBS
6 Use-Case Name: Maintains doctors time sheets
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.
NA
The system must support only one admin users
6.5 Preconditions
6.6 Post-conditions
Changes in time sheet will reflect in data base.
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.
*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.5 Preconditions
Preconditions
7.6 Post-conditions
System keeps a record of the ward and the details of patient who reserved in the database.
No changes has been made in data base
The use case ends.
8.Use-Case Name: Prescribe test

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.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.
Use case ends.

The system must support 10 or more simultaneous Doctor users.
8.5 Preconditions
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
System has recorded prescription in database.
Use case ends.
9.Use-Case Name: Prescribe Medicine

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.1 Doctors enters invalid tracking id
The use case begins when the doctor signals that he/she wants to prescribe lab test
Doctor enters an invalid id.
Use case ends.

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
System has recorded prescription in database.
Use case ends.
10.Use-Case Name: View Reports

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
Doctor enters the tracking id.
System displays the report
Use case ends.

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..
Doctor enters an invalid tracking id
Use case ends.

10.4 Preconditions
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
Test results are stored in data base
No changes have been made to the state of the database
Use case ends.
11.Use-Case Name: Enter medicine deatails

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.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.
Pharmacy in-charge enters an invalid id.
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.

The system must support 10 or more simultaneous pharma in - charge users.
11.5 Preconditions
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
Pharmacy in-charge uploads medicine bills
Use case ends.
12 Use-Case Name: generate bills

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.
Use case ends.

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.
pharma in-charge enters an invalid id.
Use case ends.

The system must support 10 or more simultaneous pharma in - charge users.
12.7 Preconditions
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.
pharma in charge will generate bills

Use case ends.
13 Use-Case Name: Upload lab fee details

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.
Use case ends.

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.
Lab in-charge enters an invalid id.

Use case ends.

The system must support 10 or more simultaneous lab in - charge users.
13.7 Preconditions
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.
Lab in charge uploads lab charges

Use case ends.
14 Use-Case Name: upload reports

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.
Use case ends.

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

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
Pharmacy in-charge uploads medicine bills

Use case ends.

Hospital Management System

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Hospital Management System

Caricato da

Copyright:

Formati disponibili

Hospital Management System

1.1 Brief Description

1.3 Flow of Events

1.3.1 Basic Flow

System displays the registration form.

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

The use case ends.

1.3.2.2 Patient not registered/wrong tacking id

System displays an error message.

The use case ends.

1.4 Special Requirements

The system must support 10 or more simultaneous receptionist users.

There is a active network to the hospital.

Receptionist should have proper logins.

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

2.3 Flow of Events

2.3.1 Basic Flow

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)

System displays field to enter admission date .

System displays an error 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 .

There is a active network to the hospital

Patient must done the registration.

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

3.3 Flow of Events

3.3.1 Basic Flow

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

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

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

Receptionist enters correct tracking id.

System displays the ward availability status as –Not available.

Use case ends.