Hospital Management Srs
Hospital Management Srs
Hospital Management Srs
Table of Contents
1. Introduction
2. General Description
3. Special Requirements
1. Introduction Top
1.1 Purpose of this Document
This SRS describes the function and the performance requirements allocated to
our product. This product will be a subsystem of the Care 2002 Integrated
Hospital Information System program requiring an Internet browser (i.e. Internet
Explorer 5.0 or higher/ Netscape Communicator 4.0 or higher/ Mozilla 1+, and
Opera).
The user will have to be familiar with the billing module. If needed, the user
should be trained up to use this module.The user may be an administrator, nurse
or a cashier. It depends upon the particular hospital.
The product requires a browser .It will support IE 5.0+, N 4+, Mozilla 1+, and
Opera. External interfaces include keyboard and mouse, enabling navigation
across screens.
Input from the user will be via keyboard input and mouse point and click. The
user will navigate through the software by clicking on icons and links. The icons
will give appropriate responses to the given input
This section provides a requirement overview of the product. The project will be
on PHP and the backend will be Mysql.
The requirements are described below:
The user will be able to search a patient either by his name (given name or family
name) or patient /visit no. If the search result yields more than one patient�s
data, then information (already stored in the database through �Admission�
module) of all those patients will be displayed. The user then will be able to select
the particular patient he is looking for.
The informations that are to be displayed automatically are:
1) The patient�s name
2) Address
3) Date of Birth
4) Marital Status
5) Sex (M/F)
6) Patient no.
7) Admitted By
8) Date of Admission
9) Patient�s type (inpatient/outpatient)
10) Diagnosis
Following functionality will be present:
� The user will select the type of the patient (corporate/individual). If the patient is a
corporate, the name/code of the corresponding organization should be entered.
� For inpatient the mode of payment will be postpaid by default and for
outpatient it should be prepaid. However the user will be able to change it if
he wants.
� If the patient is a corporate, his bill will be sent to the concerned
organization and the payment will be postpaid irrespective of whether he is an
indoor or outdoor patient.
� The billing information also includes the bill for each type of service. A
patient�s total bill should be shown in slabs:
The slabs are:
Hospital Service Pharmacy Billing Laboratory Billing
1) Brand Name of the 1) Type of Lab
1) Bill for consultation
Medicine test/service
2) Bill for Laboratory
Tests or
2) Batch No. 2) Brief description
Investigations (e.g. X-
ray, CT-scan)
3) Bill at the time of
3) Date of Expiry 3) Price per unit
Admission
4) Bill for Bed
4) Price Per Unit 4) Quantity (no.of.pcs)
Allocation
5) Bill at the time of 5) Quantity (No.
5) Total Price
Discharge of pieces)
6) Total Price
� In case of Hospital services, there will be an interface for the user to input
the name of the services and its cost. Hospital services can include services by
department (e.g. radiology, cardiology, and orthopedics). Also it may include
costs of equipment used when a patient is operated upon.
� In the case of Laboratory Tests, there will be an interface to input the name of the
tests available (in the particular hospital), its �item/test no.�(if there is any) and
its cost /unit since the names of the tests and the corresponding costs per unit may
vary from hospital to hospital. All the available tests will be displayed with
checkboxes in the �select laboratory test� form. The user will select the tests done
by a particular patient. He will also enter how many times a particular test is done
by the patient. In the final billing report, only the selected tests will be displayed
with corresponding �costs per unit�, �Total cost of the particular test� and
�item no�. The total costs of all the tests will be calculated automatically.
� A part of the bill may have to be paid in advance at the time of admission. There
will be a provision to enter the amount paid in advance. If this condition does not
arise, the user will simply leave it blank and in the final bill this amount will be
displayed as 0.00
� The �Total amount� and �Final amount to be paid� by the patient will be
displayed at the bottom of the final bill. The final amount to be paid is actually the
�Total amount� � �Amount paid in advance�. In case of no advance payment,
the �Total amount� and the �Final amount to be paid� will be same. If
somehow the �Amount paid in advance� is more than the �Total Amount�, the
patient will get back an amount of �Amount paid in advance� � �Total
amount�.
� The patient may be offered an amount of discount on his total amount of bill. The
user, in that case, will enter the amount of �discount in percentage�. Otherwise he
will simply leave it blank.
� The patient will pay either in cash or by credit card. The user will select it from a
combo-box.
� There will be provision to display and print the final billing report. It should be
formatted in a way that it can be simply folded and inserted in a windowed envelope
and ready for mailing
� There will be provision to email the billing report to a patient or to its insurance
company.
� There will be provision to batch print a batch of billing reports. The user should be
able to list a group of patients and just select via checkboxes the billing reports to be
batch printed.
If the user leaves a mandatory field blank, he will be prompted to enter valid data in that
particular field.
In the interface to input new bill items, when the item number is not auto-generated, the
number that the user enters should be checked against possible duplication. Once a
possible duplication is detected, the interface should prompt the user to select one of the
suggested numbers (smartly auto-generated basing on the user's initial entry). A list of
alternatives immediately will be given to the user
It will be possible to detect that a certain service is billed twice which should not occur
in normal cases, or a certain drug is prescribed beyond a certain dosage or frequency (or
worse in deadly amounts).
The performance of our product is at its best if stored locally, as the response time
will be much faster. If the product accessed via Internet, the performance is
limited by the connection speed. The only foreseen limitation is that of web-
server response.
This product will be maintained through code comments and user documentation.
Added support will be provided through the README.TXT, and installation
procedure and user manual. Product will be thoroughly tested and documented for
reliability by different team members. The product requires any one of the
following browsers:
1) MSIE 5+
2) Mozilla 1+
3) Netscape 4+
4) Opera