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 t his 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 t he 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 o f 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 IE 5.0+ N 4.08+ N/A
Internet Browser Microsoft Internet Explorer 5.0 or higher Netscape Communicator/ Navigator 4.08 or higher Not Applicable
1.4 Overview of Document
This document provides a description description of the requirements of the product. Section 2 of the Software So ftware Requirement Specification gives the detailed descriptions of the product including the data requirements. requirements. Section 3 provides 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 upo n the particular hospital. 2.2 Product Perspective
The product requires a browser bro wser .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 p atient (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 test s done by the patient, the date of discharge d ischarge of the patient and the a mount of discount if there is any. 2.4 General Constraints, Assumptions, Dependencies, Guidelines
This application depends on client-server architecture. It I t 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 ke yboard input and mouse po int and click. The user will navigate through the software software by clicking on icons and and links. The icons will give appropriate responses to the given g iven input 3.2 Detailed Description of Functional Requirements
This section provides a requirem requ irement ent overview o verview of the product. The project will be on PHP and the t he backend will be Mysql. The requirements are described below: The user will be able to search a patient either by his name (given na me or family name) or patient /visit no. If the search result yields more than one patients 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 select the particular patient he is looking for. The informations that are to be displayed automatically are: 1) The patients 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) Patients type (inpatient/outpatient) 10) Diagnosis Following functionality will be present: ¿ The user will w ill 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 o f payment will be postpaid by default and for outpatient it should be prepaid. However Ho wever the user will be able to change it if he wants. ¿ If the patient is a corporate, his bill will be sent to the t he 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 patients total bill should be shown in slabs: The slabs are: Hospital Service
1) Bill for consultation 2) Bill for Laboratory Tests or Investigations (e.g. Xray, CT-scan) 3) Bill at the time of Admission 4) Bill for Bed Allocation 5) Bill at the time of Discharge
Pharmacy Billing 1) Brand Name of the Medicine
Laboratory Billing 1) Type of Lab test/service
2) Batch No.
2) Brief description
3) Date of Expiry
3) Price per unit
4) Price Per Unit
4) Quantity (no.of.pcs)
5) Quantity (No. of pieces) 6) Total Price
5) Total Price
¿
In case of o f 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 o rthopedics). 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 w ith 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 se lected 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 t he 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. 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 w ill pay either in cash or by credit cred it 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 provisi pro vision on to t o email the billing report to a patient or to its insurance company.
¿
There will be provisi pro vision on to t o batch print a batch o f billing reports. The user should be able to list a group o f patients and just select via checkboxes the billing repo rts to be batch printed. A "select all" button will also be there. t here.
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 against possible duplication. Once a possible duplication is detected, the interface interface should prompt the user u ser 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 o ccur 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 accessed via Internet, the performance performance is limited by the connection speed. The only foreseen foreseen limitation is that of webserver response. 3.5 Quality Attributes
This product will be maintained through thro ugh code comments and user documentation. Added support will be provided through the README.TXT, and installation procedure and user manual. Product Pro duct will be thoroughly tested and documented for reliability 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