TABLE OF CONTENTS

1ABSTRACT
…………………………………………………………………………..6
2INTRODUCTION TO THE PROJECT REPORT
………………………………..6
3BREIF OVERVIEW OF THE ORGANISATION
………………………………..7
4SYSTEM REQUIREMENT
…..…………………………………………….……...8Proposed System……………………………………………………………..10Feasibility
Study……………………………………………………………..12Effort estimation …………………………………………………………….14Time
Estimation ….….……………………………………… ……………...18Cost/Benefit
analysis………………………………………………………....18Schedule…………………………………………….......................
................20Programming Languages and Development Tools…………………………..20
5

SOFTWARE
SPECIFIC REQUIREMENTS
…….
…………………………….…21
Functionality ………………………………………………………..................31Reliability
…………………………………………………………….…. ....32Performance ……………………………………………………………..…….32Security
……………………………………………………….……..……33System security ………………………………………………….….………… 33Data
Security …………………………………………………..….……........33Maintainability and Portability
…………………………………..………........33Interfaces ……………………………...………………………...……………..33Hardware
Interfaces…………………………..……………………………..…33Software Interfaces ………………………….…………………………….
…..33Communication Interfaces ………………….……………………………........33
6 HIGH LEVEL DESIGN SPECIFICATION
……………………………………...34Introduction…..………………………………………………………….........34Design
considerations……………………………………………….…...........34Design ………………………………………………………………..
……….340 level data flow diagram……………………………………………..………351st level data flow diagram
………………………………………………….352nd level data flow diagram………………………………………...……..….36Entity
relationship diagram………………………………………………. ….37Data dictionary
…………………………………………………………...…..40Design constraints………………………………………………………...…..41
7 TEST PLAN
………………………………….……………………………………41
1

Purpose …………………………………………………………………
41Objective…………………………………………………..........................42Scope………………………………………………….
.…………………..42Test Approach………………………………………………………..........42Test
Phases………………………………………………………………...43Scope of Testing…………………………………………………………...44Entry
and Exit Criteria…………………………………………..................44Requirement of
testing…………………………………………………….
45
8 LIMITATION OF PROJECT
………………………...………………………….45
9 BIBLOGRAPHY
…………………………………… …………………………...46
2

ABSTRACT
Application that could use by the customer to manage Best Practice with respect
toClient’s Project , Project’s Site and Site’s Workshop. Customizable repository is
to be created for the maintenance of the document via internet. It’s a multi-user
system and provides an interface between the user and the application. The System
will be responsible for the fallowing activities
Admin Module
•
Planning Module
•
Statistics Module
•
Document
•
Helps
3

INTRODUCTION OF PROJECT
There are number of ways in which computer affect human lives which are
uncountable.Computer process the function with much faster speed and greater
accuracy. So among thevarious information system of data processing my project
“PATIENT BILLING SYSTEM ” oneof the data processing system, which mainly concerns
with the customer billing record of thehospital made the entire performed are
computerized.The main objective of the project is to hail a fully computerized
system for main fining patient detail, patient bills, and ward details.The project
has the following features:
•
Effectiveness
•
Easy to use
•
Consistency
•
Simplicity
•
AccuracyThe purpose of the Patient Billing System (PBS) is to capture necessary
data elementsfrom the agencies' internal bills/personnel systems, validate the
information before bills are processed, and post the validated bills and personnel
information. This new system is beingdeveloped to support the client server
efforts. . The main aim of the project is tocreate automated software which is
purely used for billing operation in a hospital. Thisapplication would be
facilitating the particular authorities of a hospital to generate and update the
bills of a patient and store them. This will later be retrieved by the
administrator at the time of discharge.Developing a local patient billing software
system would benefit the hospital management.This system basically works for the
hospital management, helping them to generate bills and preserve patient’s details
in a well-organized approach. Since it is Software driven the quality of services
can be enhanced considerably.
4

A BRIEF OVERVIEW OF THE ORGANIZATION

The purpose of this section is to obtain agreement regarding objectives the system
mustmeet. Ultimately, this segment defines the boundaries of the effort.
Customer:
The target people are the hospital management people. The authorities are
providedwith a user id and they maintain their own accounts. The authorities can
even changetheir passwords.
Purpose:
The purpose of this application is to provide complete convenience to the
managementof the hospital, in order to make Billing, an effortless task to perform.
This project helpsthe administrator to overcome the difficulty in tracking and
maintaining records of the patients. It saves his time because the tasks are sub-
divided and assigned to respectiveauthorities. So, every authority has only some
degree of job to accomplish and henceavoids overload.
Scope:
Release 1 focuses on :Particular Authorities in a hospital.
5

SYSTEM REQUIREMENTS:
Problem formulation:-
The first step in the system development life cycle is the identification of a
need. This is arequest to change. Improve or enhance an existing system. The main
purpose of this phase problem becomes easy to understand.
Initial Investigation:-
First we went in the hospitals where we done the initial investigation about the
hospital.As we have described earlier in the phase of problem relation that there
are several types of problem in present working of manual working therefore in the
phase of initial investigation wetry to find those problems and there solution.
•
TOO LATE:
In the hospital all the working was manual. Due to themanual working there was too
late.
•
Being the all process in manual all the process was very low.
Future scope:-
In future this may work for the manufacture by making some modification in the
projectmodels by developing some extra networking feature this “PATINET BILLING
SYSTEM” willwork in interact very efficiency.This system would be much more helpful
for the near future because it is developedaccording to the all condition which
happened in the future. Like as add new features .it canmodify of all record, it is
also helpful for updating account of patient record and detail.
6

ADVANTAGE OF THE SYSTEM:

•
The main advantage of the system is the process is very simple like billing of
patient.
•
We can easily search any record of available patient.
•
We have low chances of errors in this system thus it is more accurate. Various
constructscan be applied on the software.
•
It will be more reliable with incensed throughput capacity and Economy.
•
It will save our lots of time because of feat processing as compared to human

We can easily maintain patient record.

We can easily search the information about particular record with helpof various
options.We can easily search the patient information by giving their name or
patient id.
HARDWARE/SOFTWARE REQUIREMENT:-
Server configuration:Minimum 100MB Hard Disk P-III processor or equivalentRAM 128
MBWindows or LinuxOperating System – Linux, MicrosoftLanguage -- visual
basic6.0,Database --Ms Access
ACCEPTANCE CRITERIA:-
The main aim of the project is to develop a feature-rich, practical Patient Billing
Software(PBS) for a hospital. The authorities of a hospital can login into their
respective accounts andthen update the bills consequently. The main aim of the
project is to develop a feature-rich, practical Patient Billing Software (PBS) for
a hospital. The authorities of a hospital can logininto their respective accounts
and then update the bills consequently.
•
PBS will Provide a repository for detailed patients’ bills and personnel data
•
Have a standard input format that is not patient specific
•
Validate, through edits, the information reported is properly authorized
•
Generate proper & valid transactions to initiate the payment processPBS is needed
to get rid of difficult and tiring conventional model. As we can take a look
intoconventional model.
7

CONVENTIONAL MODEL :-
The traditional way of maintaining details of a patient in a hospital was to record
themUsing case sheets manually. It was difficult to manually retrieve data whenever
needed andalmost next to impossible to maintain such capacious data as the years
passed by. And the billinghad become a hard-hitting task for the data
operators.Hence to prevent losing of data and enhance the maintainability, various
computerizedapproaches have been evolved.
NEED FOR AUTOMATION:-

The operations in the manual process are very time consuming and is an overhead
process. And through the manual process of maintaining records, it became a chaotic
operation for the authorities whenever they wanted to refer any patient’sdetails.At
that point of time, it was really essential to have an automated system which would
makework easier and proficient.
PROPOSED SYSTEM:-
With time and growth of programming capabilities, more and more
sophisticated,automated patient billing systems have evolved. The proposed Patient
Billing System hasrectified almost all disadvantages of the existing system. By
making this system as automated,the hospital management’s are benefited the most.An
Automated computerized Billing Software System provides greater enhancedtechniques
for maintaining data in a hospital and also helps in easy retrieval and updating of
data, which results in efficient billing.The PATIENT BILLING SYSTEM method aims at
improving the human behaviours atwork (to improve safety and reduce manual
work).The process is the following:To initiate the project, a visual basic
consultant helps Workshop workers to identify the best practises to follow. This is
done for all the workshops. Then, every Workshop involved in the project has a list
of best practises to respect.The BV consultant setups the application by entering
the configuration (sites definition,workshops definition, shifts definition for all
the workshops, list of best practises by workshop).At a defined frequency (daily,
weekly…), for each shift of the workshop, a user uses theapplication to generate
the list of best practises to follow for his workshop.
8

The user assesses the best practises respect in the workshop and enters the result
into theapplication.The application is able to generate graphs showing the result
of the assessments ( rate of respectfor all the best practises and trend of this
result during a period)The graphs generated by this application is used during
periodic meetings debrief of the resultwith the workshop workers and to define
which best practises can be added and which practisescan be removed.
ADMIN MODULE:-
Through this module user could create update modify and delete in different sub
module asfollows:Patient detailWard detailBill detail
PLANNING MODULE:-
Here user Planning for best practice for a workshop to improving working standard.
STATISTICS MODULE:-
Statistics showing the status which displays the status of bills the within a time
period.
ADVANTAGES OF THE PROPOSED SYSTEM:-
The advantages of proposed system can be summarized as below:(1) The new system
will developed in MS Access concept making it compatible with the user requirement.
As a result there will be minimum redundancy of data and large amount of data can
be stored in the database without any storage problem.(2) The response time
information retrieval will reduced to negligible and the processing timerequire for
retrieving, the desired information from different table is less.(3) Reports can be
generated quickly for effective decision making and up-to-date informationare
available and answers to queries are also provided instantly.
9

FEASIBILITY STUDY:-
A feasibility study is defined as an evaluation or analysis of the potential impact
of a proposed project or program. A feasibility study is conducted to assist
decision-makers indetermining whether or not to implement a particular project or
program. The feasibility study is based on extensive research on both the current
practices and the proposed project and its impacton the school foodservice
operation. The feasibility study will contain extensive data related tofinancial
and operational impact and will include advantages and disadvantages of both
thecurrent situation and the proposed plan.The feasibility study is conducted to
assist the decision-makers in making the decision that will be in the best interest
of the school foodservice operation. The extensive research, conducted in anon-
biased manner, will provide data upon which to base a decision. The Feasibility
study could be used because:Main characteristics of the system:
•
Manage the information of client, project, site, workshop and shift.
•
Setting and improve working standard.
•
Provide Graphical representation of data..
•
User Access privilege (Profile).Within a feasibility study, six areas must be
reviewed, including those of Economics, Technical,Schedule, Organizational,
Cultural, and Legal.
Economic Feasibility Study:-
This involves questions such as whether the firm can afford to build the system,
whether its benefits should substantially exceed its costs, and whether the
projecthas higher priority and profits than other projects that might use the same
resources. This alsoincludes whether the project is in the condition to fulfill all
the eligibility criteria and theresponsibility of both sides in case there are two
parties involved in performing any project.
Technical Feasibility Study:-
This involves questions such as whether the technology needed for the system
exists, howdifficult it will be to build, and whether the firm has enough
experience using that technology.The assessment is based on an outline design of
system requirements in terms of Input, Output,Fields, Programs, and Procedures.
This can be qualified in terms of volumes of data, trends,frequency of updating,
etc. In order to give an introduction to the technical system.
10
Schedule Feasibility Study:-
This involves questions such as how much time is available to build the new
system,when it can be built (i.e. during holidays), whether it interferes with
normal business operation,etc.
Organizational Feasibility Study:-
This involves questions such as whether the system has enough support to
beimplemented successfully, whether it brings an excessive amount of change, and
whether theorganization is changing too rapidly to absorb it.
Cultural Feasibility Study:-
In this stage, the project's alternatives are evaluated for their impact on the
local andgeneral culture. For example, environmental factors need to be considered.
Legal Feasibility Study:-
Not necessarily last, but all projects must face legal scrutiny. When an
organization either has legal council on staff or on retainer, such reviews are
typically standard. However, any project may face legal issues after completion too
Marketing Feasibility Study:-
This will include analysis of single and multi-dimensional market forces that could
affectthe commercial.So, before developing this system our team will generate some
document related to feasibilitystudy, which include all such feasibility analysis
as describe above.
EFFORT ESTIMATION:-
The project estimate is only as good as the estimate of the size of work to
beaccomplished; choosing a right software sizing metric is an important task.
11

In the context of project planning, size refers to a comfortable outcome of the

software project. If a direct approach is taken, size can be measured in LOC. If an
indirect approach is chosenfunctional measures are considered.The LOC is an
artifact of all software development projects and can be easily counted.Even
though, it is not universally accepted as the best way to measure the process of
softwaredevelopment.Loc measures are programming language independent.They penalize
well designed but shorter programsThey cannot easily accommodate non procedural
languages.Their use in estimation requires a level of detail that may be difficult
to achieve.(i.e., the planner must estimate the LOC to be produced long before
analysis and design have been completed)The functional Point Metrics on the other
hand measures the functionality delivered by softwareand a measure about the
functionality that an application delivers to the users.Functional points stay
constant regardless of the programming languages used.Functional points can be
developed relatively easily by consulting the users at an early stage of the
development process.The steps taken to arrive at the functional point count for a
software product are:The information processing size , is determined by identifying
the system components perceived by the end users and then classify and count the
five user function types (known as unadjustedfunction points) delivered by the
development process.Unadjusted Function PointsThese are classified as follows:
Data Function
Number of Internal Logical Files (ILF): Logical grouping of data in a system,
maintained by anend user, are referred to as internal logical files. Number of
External Interface Files (EIF): All machine readable interfaces that are used
totransmit information to another system.Transactional Function: Number of External
Inputs (EI): An external Input gives the user capability to maintain the data in
ILFs through adding, changing and deleting its contents. Number of External Outputs
(EO): Each user output that provides application orientedinformation to the user.
In this context output refers to reports, error messages, and so on.Individual data
items within a report are not counted separately.Number of External Inquiries (EQ):
An inquiry is defined as an online input that results in thegeneration of some
immediate software response in the form of an online output.
12

These components are further categorized as simple, average or complex, depending

on thenumber of data elements in each type and other factors.Degree of influence
(DI) of fourteen components called ‘general application characteristics’
isdetermined. The degree of influence of each of these factors takes a value from
0-5 to signifynone to essential. The sum of the scores of the fourteen
characteristics, that is the total degrees of influence, is converted to the
‘technical complexity factor’ by using the following formula:
TCF = 0.65 + 0.01 x DI
The relative system size expressed in function points (FPs) is computed as:
FP’s = UPF x TCF
For the Proposed Project the details are as stated-below:(Note: The below stated
numbers have been concluded with reference to the Requirementsdocument, described
earlier) Number of External Inputs: 22 Number of External Outputs: 40 Number of
External Queries: 18Internal Logical Files: 4 FilesExternal Interface Files: 1 File
COMPUTATIONS:
MeasurementsParameterscountweighing factor simpleaverage complexEI22 x3
x4
x6 =88EO40
x4
x5 x7=160EQ18 x3
x4
x6=72ILF4
x7
x10 x15=28EIF1
x5
x7 x10=5COUNT UFP TOTAL=353
COMPUTING TECHNICAL COMPLEXITY FACTOR(TCF)
13

CICHARACTERISTIC DICOMMENTC1Data communication2Client/server

architectureC2Distributed functions3Client/server
ArchitectureC3Performance2Client/server architectureC4Heavily used
configuration1Application designC5Transaction rate5Strong influence for transaction
handlingC6Online data entry4Majority operationsdepends on online entries
C7
End user efficiency
3
Exclusivity is sprawledover user friendlymenu
C8
Online update
2
Moderateinfluence
C9
Complex processing
4
Databasefunctions.
C10
Re-usability
3
Modules must bere-usable for further enhancements
C11
Installation Ease
3C12
Operational Ease
5C13
Multiple Ease
5C14
Facilitate Change
3TOTAL DI45Degree of InfluenceValuesDegree of InfluenceValues
Not
Present0AverageInfluence3InsignificantInfluence1SignificantInfluence4ModerateInflue
nce2StrongInfluence,Throughout5
Technical complexity as defined above:TCF = 0.65 + 0.01 x DI
Computed as:TCF = 0.65 + 0.01 x 45
TCF = 1.1
14

Function point defined as:FP = UPF x TCF

i.e. FP = 353 x 1.1
FP = 388For Object Oriented Technologies LOC/FP = 30
LOC = FP x 30LOC = 388 x 30
LOC = 11649 DLOC

Expected lines of code to be developed: 12 KDLOC Approx.

Expected scheduled delivery time: 1.8 * man-months period.(From company’s empirical
data, the similar projects based on Visual Basic and MSAccess it is assumed that
the project must complete within above specified period of time.)
TIME ESTIMATION-
According to COCOMO Model-
Estimation of Development Effort-Organic : Effort=2.4(KLOC)
1.05
PM
In this project KLOC as estimated above=11649Therefore, Effort = 2.4*(11649)
1.05
Effort = 15.181
Estimation of Development Time--Organic :
T
dev
=2.5(Effort)
0.38
Months As estimated above, Effort = 15.181Therefore, T
dev
= 2.5*(15.181)
0.38
Estimated Time = 5 Months Approx.(From company’s empirical data, the similar
projects based on Visual Basic and MSAccess it is assumed that the project must
complete within above specified period of time.)
COST BENEFITS ANALYSIS:-
15

The costs associated with the system are expenses outlay or losses arising
fromdeveloping and using a system. But the benefits are the advantage received from
installing andusing. Cost and benefits can tangible or intangible, fixed or
variable, direct or indirect.
Tangible or Intangible cost:-
Tangible cost is that which value can be measured. The outlay of cash for any
specific item or activity is referred to as a tangible cost. These costs are known
and be estimated accurately. Costthat are known to exist but their financial value
can not be exactly measured are referred to asintangible cost.
Cost of the system
One PC core 2 due 36000/RsOne inkjet printer4500/Rs
Total Hardware costs 40500/RsCost of the SOFTWARE
Visual basic 6.010000/RSMs Access5000/RS
Total software cost 15000/RSDevelopment cost:
Programming 20000/RsFor Analyst5000/Rs
Total development cost 25000/Rs
Intermediate printouts 150/RsElectricity cost 500/RSOthers 100/Rs
Total cost 650/Rs
COST ESTIMATION OF PROJECT:-
This is the full-fledged industrial project containing database handling, active
documents,good designing, validation checks, good security and easy to use
interface etc.In this project I have used latest s/w technologies. Visual basics
6.0 is the front end and used, msaccess is used as database (back end), operating
system windows vista ultimate.Total Effort Estimation = 15.181 Nominal Development
Time =5 MonthsSalary of Programmer =12,000
Cost required developed the product=60,000 Approx
DIRECT AND INDIRECT COSTS:-
Direct costs are those which are directly associated with a system. Its are applied
directly tooperator of the site.
16

Indirect costs are not directly associated with a specific activity in a system. It
is often refers toas overhead expenses
.
DIRECT OR INDIRECT BENEFITS:-
Direct benefits also can be specially attributes to a given project.Saving of time
is writing the record and transforming the old data from the store.Saving man
power.Indirect benefits are realized as a byproduct of another system for example:
o
Easy entry of record
o
Easy to modify any record
o
Easy to calculate feedback and determine weak points of any system.
o
Easy access of information with specific requirements.
o
Information can access from any other site of same objective.
Request Period:-
It is not necessary that all the required projects are desirable or feasible,
becauserequested projects only initialize when they are feasible in each and every
aspect. If the cost ismore than the cost of benefits after the project release then
the project request are dropped.Under this feasibility study the user system
“Patient Billing System” are feasible in each andevery aspects. In other words we
can say that the end user system is technically feasibleeconomically feasible
operational feasible and legally and time feasible.
SCHEDULE:
Development Schedule

MODULESSTART DATEEND DATEA. Documentation

15-sep-20114-oct-20111. SRS7-oct-201115-oct-20112. HLD29-oct-201130-oct-20113.
LLD20-oct-201121-oct-20114.Test Plan20-nov-201128-Nov-20115.Test Case Report for
all modules28-Nov-201129-nov-2011
17

PROGRAMMING LANGUAGE AND DEVELOPMENT TOOL

:-
Programming language:
Visual basic 6.0,Ms Access. Operating system:windows vista,etc.
Patient Billing System :-
Product Perspective:-
PBS collects and stores bills and personnel data in a database on the Comptroller's
mainframe.The system applies edits to validate data before accepting a transaction.
The following diagramdepicts the processes contained within PBS:-
Class Diagram :
18
Ward detailWard noBed noPatient idICUBill detailWard billsICU billsMedical
billsTotal bills

PRODUCT FUNCTIONS
:-
The PBS functional architecture is shown in the figure below. There are 6 major
functions inSPRS. The specifics of these components are detailed in Section 3.0,
RequirementsSpecifications
.
19

SEQUENCE DIAGRAM FOR PATIENT MANAGEMENT:-

20

SEQUENCE DIAGRAM FOR PATIENTBILLING MANAGEMENT:

21

System Feature

ID:
SRS_PBS _REG_01
System Feature Name:
Patient
Registration
22

Description:
Patient registration feature enables the registration process of the patient. The
feature stores the data in a database and retrieve usingregistration ID. Updates
the Patient data whenever necessary.
Activity Diagrams,Sequence Diagrams,Class Diagrams:
List the graphical models used to analyze the features and to better understand
what needs to happen in the system. This can helpidentify issues such as omissions
in the requirements. Remember that this is an analysis activity and not yet a
design activity. Proceedonly to a level of detail that allows you to understand the
problemdomain.The diagrams are defined as delineated in the Unified
ModelingLanguage (UML):Activity diagrams that show the user-system interactions:
Use thistype of diagram to better understand the flow of the work, and, in
particular, the branching.Sequence diagrams that show object interactions: Use this
type of diagram to identify the key concepts of the domain, i.e., the objectsthat
will implement the behavior.Class diagrams that summarize the classes of objects
that appear inthe sequence diagram: Use this type of diagram as a complement tothe
previous diagram.
System Feature

ID:
SRS_PBS_WARD_01
System Feature

Name:WARD
Management
Description:
This feature enable to maintain the wards(General/ICU) and abouttheir Patients
information .
Activity Diagrams,Sequence Diagrams,Class Diagrams:
<List the graphical models used to analyze the features and to better understand
what needs to happen in the system. This can helpidentify issues such as omissions
in the requirements. Remember that this is an analysis activity and not yet a
design activity. Proceedonly to a level of detail that allows you to understand the
problemdomain.
23

The diagrams are defined as delineated in the Unified ModelingLanguage (UML):

Activity diagrams that show the user-system interactions: Use thistype of diagram
to better understand the flow of the work, and, in particular, the
branching.Sequence diagrams that show object interactions: Use this type of diagram
to identify the key concepts of the domain, i.e., the objectsthat will implement
the behavior.Class diagrams that summarize the classes of objects that appear inthe
sequence diagram: Use this type of diagram as a complement tothe previous diagram.
>
System Feature

ID:
SRS_PBS _BS_01
System Feature

Name:
BILLING SYSTEM
Description:
This feature enable to give billing information so that patient billlscan be
calculated easily.
Activity Diagrams,Sequence Diagrams,Class Diagrams:
<List the graphical models used to analyze the features and to better understand
what needs to happen in the system. This can helpidentify issues such as omissions
in the requirements. Remember that this is an analysis activity and not yet a
design activity. Proceedonly to a level of detail that allows you to understand the
problemdomain.The diagrams are defined as delineated in the Unified
ModelingLanguage (UML):Activity diagrams that show the user-system interactions:
Use thistype of diagram to better understand the flow of the work, and, in
particular, the branching.Sequence diagrams that show object interactions: Use this
type of diagram to identify the key concepts of the domain, i.e., the objectsthat
will implement the behavior.
24

Class diagrams that summarize the classes of objects that appear inthe sequence
diagram: Use this type of diagram as a complement tothe previous diagram. >
S. No. Class NameResponsibility
Persistent (Y / N)
S1PATIENTThe patient must enter all the personal detailsPermanent DatabaseS2
ADMINISTRATORReceptionist: He has theresponsibilities to take the patient details
and to assign todoctor concern for the diseasesuffering by the patient .Permanent
DatabaseS3BILLSBills class has responsibility tomaintain bills of each
patient.S4MEDICINEThis class has the responsibilityto maintain the medicine
detailswhich are given to the patients..S5DOCTOR DETAILSThis class has the
responsibilityto maintain Doctor‘s schedule,and allotted the respectivedoctor to
the patient.S6WARD DETAILSThis class has the responsibilitythat should maintain the
WARD
25

details of patients and fee detailsof patient for General/ICU andalso shifting of
ward details.
State Analysis
Administrator (Receptionist) will be provided with a login name and password. When
a valid user enters the system, a list of services will bedisplayed as hyper links.
User can select any option and perform desiredoperations like master updating,
deletions, insertions, taking reports etc.Data updating service will be provided to
only designated user. Higher officials can see the reports. User can select logout
option and exit fromthe system.
State Transition Diagram
-
iiiii

USER CHARACTERISTICS:-
The following agencies are expected to submit bills/personnel transactions to the
PBSfrom internal billing and personnel systems:
26

idleActiveLoginRegestrationUpadatedetailViewReportLogout

End Users:

Hospital management officials, which include:

•
Lab Authority
•
Ward Authority
•
Pharmacy Authority
•
Administrator Users have update access to PBS through batch processing and can
perform online changes toPBS data. A limited number of inquiry screens are
available to these agencies and Comptroller staff. The heaviest use of the data is
among Lab Authority, Ward Authority, Pharmacy Authority,and Administrator Only
authorized people sign in to the system, others cannot sign in and update the
dailytransactions.
ASSUMPTIONS AND DEPENDENCIES:-

The details related to the product, customer, payment and service
transactionProvided manually.

Administrator is created in the system already.

Roles and tasks are predefined.

Only authorized users can access the system.
FUNCTIONALITY
:-
Functional Requirements
:-

Feature AnalysisThe PBS project module consists of following sub modulesAdmission

of new patients.Search/view details of existing patients.
•
Transfer of patients.
•
Billing
27

System Feature

ID:
SRS_REG_01
System Feature

Name:

Patient Billing System.

Description:
Enables the hospital authorities to perform billing efficiently andmaintain patient
details without any discrepancies.
Activity Diagrams,Sequence Diagrams,Class Diagrams:
The diagrams are defined as delineated in the Unified ModelingLanguage
(UML):Activity diagrams that show the user-system interactions: Use this typeof
diagram to better understand the flow of the work, and, in particular,the
branching.Sequence diagrams that show object interactions: Use this type of diagram
to identify the key concepts of the domain, i.e., the objects thatwill implement
the behavior.Class diagrams that summarize the classes of objects that appear in
thesequence diagram: Use this type of diagram as a complement to the previous
diagram.
Operations:
Register new patients.Keep track of all the facilities used by the patients and
charge themaccordingly.Provide Bill to the patient.
R

ELIABILITY

:-
The factors used to determine system reliability are:
•
System should complete processing during the processing window.
•
System shall provide a data check-point that saves all completed transactions.
•
System shall retain historical records as follows:

System will archive to tape (tapes will be maintained for a period of sevenyears):

Patients’ transactions with an effective date prior to the current fiscal year
plus two prior fiscal years.

Patients’ transactions with a payment date prior to the current calendar year plus
two prior calendar years.
28

o
System will archive to disc:

Data extract files, until the next time the extract program is run. The System
Input/OutputSection within the Comptroller's office maintains 255 back-up versions
of all data extractfiles transmitted to agencies.

255 back-up versions of all print extract files transmitted to agencies. After 255
versionsare created, the System Input/Output Section moves them to tape and
maintains them for an additional four years.Safety and reliabilityRequirementsBy
incorporating a robust and proven RDBMS (MYSQL) into the system,reliable
performance and integrity of data is ensured.There must be a power backup for
server system

PERFORMANCE
:-
PBS performs overnight batch processing. A batch queuing process ensures that
batchesare processed in the correct order. Batches are queued for processing by the
date/time stamp of the batch on a first in, first out basis. Batches are submitted
to the queue by the agency .All PBS batches received before the specified time are
processed that night. Batches receivedafter the specified are processed the next
night.PerformanceRequirementsSystem can withstand even though all the authorities
try to update thedata in the database tables at the same time. Access is given to
theonly authenticated employees of a hospital who are assignedrespective tasks.
SECURITY
:-
SYSTEM SECURITY
:-PBS Security is managed through existing procedures within the Comptroller's
officeusing system Security. A user identification (User ID) consisting of the
users first name, userslast name and the users’ designation in hospital/department
shall be assigned to all usersaccessing the system. In some cases, to avoid
duplicate User IDs, the convention may vary. Onlyusers’ with a needed designation
in hospital/department will be provided authorized logon privileges. Should an
attempt to logon fail after three times, the User ID shall be locked out of the
system until the user contacts a Security Coordinator to resolve the problem.
DATA SECURITY:-
SPRS will be backed up as part of the scheduled backups.
29

MAINTAINABILITY AND PORTABILITY:-

PBS is a mainframe system to be developed using software currently supported
withinthe Comptroller's office.
INTERFACES
:-
1. Login screen.2. User id and Password screen3. Update database details screen.5.
Delete database Details screen.6. Billing screen.
HARDWARE INTERFACES
:-

Server configuration:Minimum 1GB Hard Disk P-III processor or equivalentRAM 128

MBWindows or Linux
SOFTWARE INTERFACES
:-
Operating System – Linux, MicrosoftLanguage -- visual basic6.0,Database --Ms Access
COMMUNICATIONS INTERFACES
:-

LAN protocols and TCP/IP

Mozilla web browser or equivalent

HIGH LEVEL DESIGN SPECIFICATION:-PURPOSE
This document provides the detailed system design of Document Management System.
Itdescribes the high-level design that explains the functionality of the system.
The purpose of thisdocument defines the architecture, implementation, database
design details of the system to thedevelopment team.
SCOPE
The Scope of this document includes the design details for the functioning of
different modulesof the system, database details are also included that is required
for the storage of information.
DESIGN CONSIDERATIONS
30

•
The issues that measure the design are:
•
User-friendly interface.
•
Authorized users can only access the application.
•
Access is limited by the authorization level.
•
The new version replaces the older version when the document uploads
•
Ms Access is the database manager and visual basics as a front end.
DESIGN:-
DFDs showing Patient Billing System
-

0 Level DFD
-
1 Level DFD
-
31

LoginBill
patient

case paper data storepayment data store

report
Patient data store
patient detail
patient
payment advicecase paperreport
payment reciptl
admission process system
patient detail
bills
2 Level DFD
-
32

Patient data storepatient data storeCase paper data storePatient payment data store
billsupdateupdateupdate
patient reg.& paymentSyatempayment process systempatient
requestpayment reg idpayment advicecase paper updatereportpatient detail
E-R DIAGRAM: -
33

Data models are tools used in analysis to describe the data requirements &
Assumptions in thesystem from a top-down perspective .They also set stage for the
design of databases.There are three basic elements in E-R Models:
•
Entities are “things” about which we seek information
•
Attributes are the data we collect about the entities.
•
Relationships provide the structure needed to draw information from multiple
entities.
DEVELOPING AN E-R DIAGRAM: -

Developing an E-R Diagram require an understanding of the system & itscomponents

before discussing the procedure, let’s look at a narrative created by us.

34

RELATIONSHIP DI
AGRAM

35
LOGICAL DATA ANALYSIS OF THE SYSTEM
Patient_DetailsPatient_id

NameSexFather’s nameAddressContact No
Doctor_id
Disease
Ward_No
AgeDate
StatusIsa
Doctor_DetailsDoctor_id

NameSexDepartmentAddressContact_No

Ward_Details
Ward_No

Total_DaysWardCost_Per_BedPatient_idTotal_BillStatus
Transaction_Details

Patient_id
Transaction id

Date_of_AddmissionDate_of_Discharge
Ward_No
Final_Bill_DetailsBill_id

Patient_id
Patient_NameWard_BillOther_BillTotal
Ward_No Bill_id
Other_Bill_DetailsBill_id

Patient_idICU_BillMessage_Bill

DATA DICTIONARY: -
The classification of the Total Number, Types & Names of Databases & Tables used in
the project are shown below here:1.Patient_idText2.Patient_Name
Text3.SexText4.Father’s_NameText5.AddressText6.Contact_NoNumber
7.Doctor_idText8.DiseaseText9.Ward_NoNumber 10.AgeNumber 11.DateDate/Time12.Status
Text13.Doctor_Name Text14.DepartmentText15.Total_DaysNumber
16.WardText17.Cost_Per_BedCurrency18.Total_BillCurrency19.TransactionText20.Date_of
_AdmitDate/Time21.Date_of_Discharge Date/Time22.ICU_BillCurrency23.Medicine Bill
Currency24.TotalCurrency25.Other_BillCurrency26.User_NameText
36

27.PasswordText28.TypeText
DESIGN CONSTRAINTS:-

GUI is only in English.

Login and password is used for identification of users and there is no facility for
guest.

This system can be accessed by the authorized users only.

There is no maintainability of back up so availability will get effected.
TEST PLAN:-
PURPOSE:-
This document is a high-level overview defining our testing strategy for the
patient billing system. This document will address the different standards that
will apply to the unit and
37

functional testing of the application, to achieve correct code and ensure all
functional and designrequirements are implemented as specified in the SRS
documentation.
The purpose of the Test Plan document is to:
•
Specify the approach that Testing will use to test the application.
•
Break the product down into distinct areas and identify features that are to
betested.
•
Specify the procedures to be used for testing sign-off and product release.
•
Indicate the tools used to test the product.
•
List the resource and scheduling plans.
•
Identify risks and contingency plans that may impact the testing.
•
Specify bug management procedures for the project.
OBJECTIVE:-
The objective of our test plan is to find and report as many bugs as possible to
improvethe integrity of our program. Although exhaustive testing is not possible,
we will exercise a broad range of tests to achieve our goal.
SCOPE:-
Testing will be conducted at the different level. The scope of testing will be
limited to thetop-level panels of the design. Both the functional aspect, i.e.
validity of the reports generated, aswell as compliance to the GUI guidelines will
be verified, the look and feel of the screens, theoverall functionality of the
application. The Test Plan identifies the details of the test approach,identifying
the associated test case areas within the specific product for this release cycle.
TESTING APPROACH:
Testing is the process of executing programs with the Intent of finding errors,
rather than (amisconception) of showing the correct functioning of the programs.
The distinction may soundlike a matter of semantic, but it has been observed to
have profound effect on testing success.Testing should bear the following
objectives:
•
to reveal design errors
•
to reveal logic errors
•
to reveal performance bottlenecks
•
to reveal security loopholes
•
to reveal operational deficienciesThe Test Approach sets the scope of system
testing, the overall strategy to be adopted, theactivities to be completed, the
general resources required and the methods and processes to beused to test the
release. It also details the activities, dependencies and effort required to
conductthe System Test. The test approach should reveal the following details:
•
New & revised Transaction Processing
38

•
New Query Processes
•
Revised Audit process
•
Relocate Exceptions
•
Revised Query Management process
•
Revised Retrievals process A successful testing approach is one that detects an
undiscovered error.A necessary part of a testing approach is a definition of the
expected outputs or results. Do not plan testing effort on assumption that no
errors will be found.The probability of the existence of more errors in a section
of a program is proportional to thenumber of errors already found in that
section.Testing libraries should be set up allowing Regression test to be performed
at the time of systemmaintenance and enhancement. The later in the development life
cycle a fault is discovered, thehigher is the cost of correction. Successful
testing relies on complete and unambiguousspecification.
TEST PHASES:-
Test PhasesTesting StrategyApplied
39

Unit Testing-
Testing of the program modules in isolation with theobjective to find discrepancy
between the programs and the program specifications.White box testingin LLD
Integration Testing-
Testing of the linkages between testing program modules withthe objective to find
discrepancy between the programs andsystem specifications.White box testingin LLD
Function Testing-
Testing of the integrated software on a function-by-function basis with the
objective to find discrepancy between the programs and the function
specifications.Black box testing
Systems Testing-
Testing of the integrated software with the objective to finddiscrepancy between
the programs and the original objectiveswith regard to the operating environment of
the system (e.g.Recovery, Security, Performance, Storage, etc.).Black box testing
Acceptance Testing-
Testing of the integrated software by the end-users (or their proxy) with the
objective to find discrepancy between the programs and the end-user needs.Black box
testing
SCOPE OF TESTING:-
System testing is the process of testing the integrated software with regard to
theoperating environment of the system.( i.e. Recovery, Security, Performance,
storage, etc)
40

It’s worthwhile to note that the term has been used with different environments. In
its widestdefinition especially for the small scale projects, it also covers the
scope of integration testingand the function testing.For our application which
combines the integration testing, functional testing, system testing inone set.
All the testing done at the customers site are hopefully well and are similarto
those are shown in the description of design phase of these software. Theentire
input screens are same. All output screen are same ,because we usedthe technique
provided by MICROSOFT in our program so that if a computercan satisfy a minimum set
of hardware and software requirement then outprogram behave equally well on both
computer that on development site orcustomer’s site.
Therefore if you want to see any data, input screen, output screen reports and
printouts then youcan see them in the previous description of design phase.
ENTRY CRITERIA:-
The Entrance Criteria specified by the system test controller, should be fulfilled
beforeSystem Test can commence. In the event, that any criterion has not been
achieved, the SystemTest may commence if Business Team and Test Controller are in
full agreement that the risk ismanageable.All developed code must be unit tested.
Unit and Link Testing must be completed and signed off by development team.System
Test plans must be signed off by Business Analyst and Test Controller.All human
resources must be assigned and in place.All test hardware and environments must be
in place, and free for System test use.
EXIT CRITERIA:-
All High Priority errors from System Test must be fixed and testedIf any medium or
low-priority errors are outstanding - the implementation risk must be signedoff as
acceptable by Business Analyst and Business ExpertProject Integration Test must be
signed off by Test Controller and Business Analyst.Business Acceptance Test must be
signed off by Business Expert.
REQUIREMENT OF SYSTEM TESTING:-
41

Testing is vital to the system. System testing makes a logical assumption that if
all the partsof the system are correct, the goal be successfully achieved.
Contesting leads to errors that create problems.The time lag between the cause and
the appearance of the problem The effect of systemerrors on files and records
within the system. A small system error can conceivably explode intoa much problem.
Effective testing early the process translate directly into term cost saving from
areduced number of error.System testing is usable as a user oriented vehicle before
implementation. It is helpful to asystem tester to bridge the communicate barrier.
LIMITATION OF THE PROJECT:-
This project will not work for all hospitals. The project I am making is a real
life project. Stillthere are few loopholes, which should be taken care in the long
term. The project I am making isused in fewer organizations because it is a
traditional system of maintaining the patient billingmanagement. So as and when
time changes few more details may be required in this project,hence we have update
it at regular interval of time. Few limitations that I can oversee at this point of
time are as under:-
o
This application is for standalone machine.
o
Typical (or as told by the clients).
42

BIBLIOGRAPHYReferences
Steven Holzner, Visual Basic 6 Programming Black Book, Dream Tech
Press,2007Evangelos Petroutsos, Mastering Visual Basic 6, BPB Publication,
2006Rajib Mall, Fundamentals of Software Engineering, PHI Learning Private
Limited,2008Sajan Mathew, Software Engineering, S.Chand & Company Ltd,
2007Prabhakar Gupta, Software Engineering, Pragati Prakashan, 2007Roger S Pressman,
Software Engineering a Practitioner’s Approach, Mcgraw HillInternational Edition,
2005Zultner R, Quality Function Deployment for software satisfying
customers,American Programmer, 1992Gilb T, Principles of Software Engineering
Management, Addison Wesley, 1998Budd T, fundamental of data base management,
Addison-Wesley, 1996
43

Reward Your Curiosity

Everything you want to read.
Anytime. Anywhere. Any device.
Read free for 30 days
No Commitment. Cancel anytime.

Share this document

Share or Embed Document
Sharing Options
Share on Facebook, opens a new windowShare on Twitter, opens a new windowShare on
LinkedIn, opens a new windowShare with Email, opens mail clientCopy Link

You might also like

Hospital Management System
Hospital Management System
Document
66 pages
Hospital Management System
kiasap
76% (17)
patient billing system
patient billing system
Document
44 pages
patient billing system
Yogesh Joshi
73% (11)
140745811 Patient Billing System
140745811 Patient Billing System
Document
44 pages
140745811 Patient Billing System
Anonymous eUAII6Mhz
No ratings yet

Project-Report-on-Hospital-Management-System (1).doc
Project-Report-on-Hospital-Management-System (1).doc
Document
42 pages
Project-Report-on-Hospital-Management-System (1).doc
rocketspeed
No ratings yet
145353629-Project-Report-on-Hospital-Management-System.doc
145353629-Project-Report-on-Hospital-Management-System.doc
Document
42 pages
145353629-Project-Report-on-Hospital-Management-System.doc
Jaya Shukla
67% (3)
project
project
Document
76 pages
project
Ms Rawat
No ratings yet

Hospital Management System Project Report

Hospital Management System Project Report
Document
161 pages
Hospital Management System Project Report
FreeProjectz.com
92% (106)
Hospital Management System Srs
Hospital Management System Srs
Document
71 pages
Hospital Management System Srs
Yash Kapoor
73% (11)
Final Hospital Management System
Final Hospital Management System
Document
23 pages
Final Hospital Management System
Sumit Tembhare
0% (1)
PHP And MySQL Project On Clinic Appointment System
PHP And MySQL Project On Clinic Appointment System
Document
191 pages
PHP And MySQL Project On Clinic Appointment System
FreeProjectz.com
87% (15)
computer science project file for class XII CBSE on the topic : Bank Customer
Management System
computer science project file for class XII CBSE on the topic : Bank Customer
Management System
Document
75 pages
computer science project file for class XII CBSE on the topic : Bank Customer
Management System
JYOTI DOGRA
66% (29)
Clinic Management System
Clinic Management System
Document
25 pages
Clinic Management System
mayank
100% (1)