Hospital Management Srs

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 6

 

 Software Requirement Specification


      Version 2.1

        Hospital Management System-Billing Module  


        A subsystem of Care 2002 Integrated Hospital Information System
 

  October 27, 2002

Table of Contents

1. Introduction

1.1 Purpose of this Document


1.2 Scope of the Development Project
1.3 Definitions, Acronyms, and
Abbreviations
1.4 Overview of Document

2. General Description

2.1 User Characteristics


2.2 Product Perspective
2.3 Overview of Data Requirements
2.4 General Constraints, Assumptions,
Dependencies, Guidelines
2.5 License Type

3. Special Requirements

3.1 External Interface Requirements


3.2 Detailed Description of Functional Requirements
3.3 User Input Validation
3.4 Performance Requirements
3.5 Quality Attributes

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).

1.2 Scope of the Development Project

The name of our product will be "Hospital Management System-Billing Module"


and its function is to control the billing system of a hospital. This product will
provide separate billing method for indoor and outdoor patient, corporate and
individual patient.

1.3 Definitions, Acronyms, and Abbreviations

Browser Internet Browser


IE 5.0+ Microsoft Internet Explorer 5.0 or higher
N 4.08+ Netscape Communicator/ Navigator 4.08 or higher
N/A Not Applicable

1.4 Overview of Document

This document provides a description of the requirements of the product.  Section


2 of the Software Requirement Specification gives the detailed descriptions of the
product including the data requirements.  Section 3 provides specific functional
requirements of the different components of the product and the performance
criteria.

2. General Description Top

2.1 User Characteristics

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.

2.2 Product Perspective

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.

2.3 Overview of Data Requirements


The user will enter all the billing information for a particular patient. This will
include the type of the patient (inpatient/outpatient and corporate/individual), type of
billing (for inpatient the mode of bill payment may be postpaid but for outpatient it
should be prepaid). The user will also have to select the laboratory tests done by the
patient, the date of discharge of the patient and the amount of discount if there is
any.

2.4 General Constraints, Assumptions, Dependencies, Guidelines

This application depends on client-server architecture. It will require an


internet (http) server that is able to run PHP applications.

2.5 License type

Once this module is applied as a separate stand-alone product outside the


framework of Care 2002, this module is still licensed with the GNU GPL
license type.

3. Specific Requirements Top

3.1 External Interface Requirements

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

3.2 Detailed Description of Functional Requirements

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.

A "select all" button will also be there. 

3.3 User Input Validation

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). 

3.4 Performance Requirements

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.

3.5 Quality Attributes

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
 

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy