Hospdocument 1

Hospital Management systems
CONTENTS
1. Abstract
2.Introduction
2.1 About Organization.
2.2 About Project.
3. Problem Definition
3.1 Existing System
3.2 Proposed System
4. System Analysis
4.1 UML Diagrams
4.2 Modules
4.3 Module Description
4.4 Feasibility Analysis
5.Software Requirement Specification
5.1 Definition Of SRS
5.2 Role of SRS
6.Document Design
6.1 System Design
6.2 Database Design
7.About Software
7.1 Overview Of HTML
7.2 Overview Of POSTGRESQL
7.3 Overview Of LINUX
7.4 Overview Of JAVASCRIPT
7.5 Overview of PHP
8.Testing
8.1 Unit Testing
8.2 Black box Testing
8.3 White box Testing
8.4 Integrating Testing
8.5 System Testing

8.6 Acceptance Testing
8.7 Test Approach
8.8 Test Cases
9. Screens
10.Maintenance
10.1 User
11. Conclusion
12. Bibliography
ABSTRACT
The main motto of the computerization of Hospital

Management System is to make the workflow flexible. This would
improve the services provided by the government to the people. Lot of
manual work is reduced and would result in increase in the number of
patients treated per day.
Implementation of this project would completely change the
existing system. The services provided are described for every module in
the Hospital.
The first and foremost module is the registration. In this
module the provided service would store all the details of patients and
other treatment details such as type of diagnosis, type of medicines
prescribed, reports of the tests performed and so on.
For every patient a unique id is generated. If the patient
looses his id, the system can generate his previous id on the basis of his
other details. In brief the system can generate any sort of report
regarding patients. It also provides all the statistics studies such as a
number of patients visited, number of deaths, number of admissions in
the ward etc.
In the case of Doctor’s module, he can verify any previous
reports of his patients. He can also find the total number of frequent
cases attended by him and thus can take preventive measures by
creating awareness among the rural people. He can be informed about an
emergency case much faster through the system. Thus reduces the
existing complications.
Labs module comprises of five sub departments. Lab

technician is the end user of this module. The technician can view the
request from sent by doctor upon giving OPNO. He can submit reports on
test done to doctor. Record maintenance, census generation in labs is
made easier. One of the most complicated issues comes in the case of
ward module. The non-availability in the number of beds would be
problematic. To avoid this tedious problem we have a service through
which the availability of total number of vacant beds can be known prior
To the above mentioned case. Huge number of record maintenance will
Be reduced.
In the case of Operations, the doctor will be informed about
the number of operations to be performed much earlier. He through his
system can have a glance at the number of operations he has to perform.
Further arrangements can be don prior to the operation itself.
The system provided at the medical store will yield in many
advantages. The pharmacist can know the exact number of available
stock. Thus there will never be lack of medicines and the patient need
not go out of the hospital premises for medicines. The expiry date of the
medicines can also be known.
Another system provided at the Blood bank will prove to be
very much efficient. In worst case it may happen that a particular blood
group may not be in the Blood bank, which is needed by a patient in an
emergency case.
To overcome such type of problems a service is provided to
the operator in the Blood bank such that the number and type of blood
group will be known in advance. The number of manual records
maintained will be zero.
System provided at the Diet section will maintain the stock
availability. Through these statistics the diet service can be maintained
properly.
Thus, this computerization concept of the hospital will prove

to be the best and the finest way of providing all the services of the
government to the poorest of the poor.
By providing IT solutions to every problem identified in the
existing system the implementation will yield in excellent and efficient
benefits.
INTRODUCTION
ORIGIN:
Since the formation of the A.P state, the Medical care
facilities are provided through General Hospitals, District Hospitals,
Dispensaries, and Primary Health Centres under the control of Medical
and Health Services.
The strengthening and upgrading the Secondary Level
Health Care System will have a direct impact of improving the Health
Status of the people particularly the rural poor and tribals who wholly
depend on the public sector.
In order to strengthen the Secondary Level Health Care
System, the GoAP, brought in legislation for establishment of APVVP with
effect from 01/11/1986 enacting an act No.29 of 1986,by restructuring
the existing Government Health Organization.
EVOLUTION:
The Commisionerate of A.P.V.V.P an autonomous
organization founded by the GoAP started functioning from 01-03-1987,
as per G.O Ms No. 139, HM & FW (CI) Department, dt.27-02-1987.
ABOUT PROJECT
The main aim of this program is to reduce the manual

work of the staff thus increasing the efficiency of the existing workflow.
The redundancy is largely reduced by normalization. Our project helps
the patient in reducing his risk of remembering his previous Diagnosis
details. If he forgets his Id, it can be generated on the basis if his unique
details .The patient need not move in such a large hospital in lot of
confusion. He just can take his OP Form and can go to the Doctor; the
Doctor can view any of the patient’s reports on the basis of the unique id.
The doctor has been provided with efficient services such
as he can view the previous details of the patients .He can also check the
number of patients he has treated on the basis of date.
Any patient’s details can be retrieved when required. All
the details of the available drugs mainly the expiry date and stock
availability is made known. Stock of blood is also known in advance.
Statistics on number of patients visited as OP, number of
patients as IP, number of admissions, number of discharges, number
and type of operations performed, number of births, number of deaths
and so on… are generated dynamically.
Diet supplied to each and every patient is maintained in
records. Crosschecking is made easier.
Thus we are able to reach our goal of “SYNCHRONIZING

SERVICES”.
EXISTING SCENARIO
The process in the Headquarter Hospital starts with the registration
counter. The Patient’s details which includes his OPnumber, name, age,
gender, address, caste, religion, referral doctor if any, his initial health
condition, doctor's diagnosis, test reports, ward details if any – date of
admission, name of the allotted ward and bed number, medicines and diet
given to him, if he is operated – type of operation, pre-condition and post-
condition of that patient, date of discharge are maintained in this module.
Registration of the patient is carried out at two different windows -

. Male
. Female
An OP form is given to the patient, which consists of the patient's OP
number, age, gender and his initial condition along with the concerned doctor's
room number.
Doctor:
The doctor signs in his attendance register present in the R.M.O room
as soon as he/she arrives. The patient visits the doctor along with his OP form.
The Doctor treats the patient and may prescribe the following:
Medicines, tests/investigations, admission as in patient or he may refer to
another doctor.
There are several departments present in this module such as

Orthopedic, Gyaenic, ENT, Paediatrics, Surgical, Ophthalmic, Dental and
Medical.
Each department consists of doctors with the designations:
CSS: Civil Surgeon Specialist
DCS: Deputy Civil Surgeon
CAS: Civil Assistant Surgeon
Note: Some posts are vacant.
The working hours of the doctors are from 9:00 am to 12:00noon.
Functions of CSS:
Every CSS starts his daily work from wards. He visits the In patients
of his concerned ward and gives the diet and treatment instructions to Head
Nurse. As soon as he finishes his round he gets back to his OP room. He is the
supreme power of his department.
He is responsible for the post-condition of the patient after operation.
The duty doctor in the case of emergency calls him after 2:00 p.m.
Functions of DCS:
He is the next authority after CSS. He, in his OP room attends the
patient. In rare cases, if he has to operate a patient he should take the
approval of CSS. This is the promotion post to CAS.
Functions of CAS:
He is next to CSS or DCS. He, in his OP room attends the patient.
Any tests recommended by him must be acknowledged by the R.M.O. 33 types
of diseases and 141 types of medicines are recognized by A.P.V.V.P. Each
disease is given a code. His prescription is written on the OP form. He sends
the requisition forms for the tests through patients. If the prescribed medicine
is not available the doctor writes it on separate slip.
Costly drugs prescribed by the doctor must be acknowledged by the
R.M.O.
Doctors in every department maintain a common Prelisted. This

register includes:
Opnumber
Date
Gender/Age
Name of the Disease
Diagnosis
Old Opnumber (if the patient has already visited before)
Note: Codes assigned to the disease are not in implementation.
The doctor counts the total number of old and new patients for
every day and enters it in this register. The register is submitted to the
administration department for every month.
The following are the extra caders given to the CAS.
C.M.O works at Casuality. Description of his functions is continued in IP
Registration module.
D.M.O (works after 2:00 pm.)He is responsible for Inpatient after CSS.
Labs:
The labs department consists of three sections :
Pathological laboratory
Biochemical laboratory
Urine Analysis laboratory
Medical Officer is the incharge of lab. Two junior analysts work
under the supervision of MO one for Biochemistry another for Microbiology.
There are four lab technicians and two lab attendants.
MO:
The job of the MO is to supervise the lab.
Junior Analyst:
The job of Junior Analyst is to supervise the Lab Technician and
lab attendants.
Record maintenance and advising lab technicians are also his

jobs.
Lab Technician:
The jobs of Lab Technician are sample collection, doing test. One
Lab Technician Is working at reception.
Lab Attendant:
His job is to assist Lab Technician and clean the lab.
Process:
The patient along with the request form, which is given by a
doctor, visits the registration counter where his general details along with the
ip/op number and the test to be done are noted .The patient is given a serial
No. The Registration counter is the same for all labs. The samples are collected
and sent to the concerned section. Next day the patient is given his report
based on serial number.
Records:
The three investigations record each for a section, stock
register, Expenditure, census Registers are maintained.
The investigations record consists general details and test details.
The stock record consists of fields
Date | Received | Qty | Expenditure | Balance
The Expenditure register consists of fields

Date | given to | Qty | Expenditure | Balance
The Census register consists of fields

CBP | ESR | HB | MP | BTCT | Stool | Semen Analysis | Blood Sugar |
Blood Urea | Serum Creatinine | Widal | VDRL | Urine

Each field consists of two sub fields ip and op.
X_RAY:
The Radiologist is the incharge of X_RAY department.
Three Radiographers work under his supervision. One dark room
assistant and two attenders also work under the supervision of Radiologist.
Radiologist:
The duty of the Radiologist is to supervise the work of
X_RAY lab .He also writes his diagnosis on every X_RAY film taken. He is
responsible for taking scanning also.
Radiographer:
Radiographer is the person who is responsible for taking
X_RAYS. Among the three Radiographers present one will be the incharge, who
is responsible for maintenance of various records of X_RAY lab.
Darkroom Assistant:
He is responsible for the development of X_RAYS.
Attenders:
The at tender’s duty is to deliver the X_RAYS to wards and
doctors concerned and to get back the same after usage.
Process:
The patient along with the request form which is given by
a CSS or which is acknowledged by the R.M.O visits the registration counter
where his general details along with the ip/op number and the body part that
is to be tested are noted .The patient is given a serial No. The Registration
counter is the same for X_RAY and E.C.G.
For OP:
The patient attends the test and visits the registration
counter the next day. The patient must submit his OP form on which his serial
No is written. The patient is given his X_RAY .The patient must return his
X_RAY after showing it to the doctor. After returning of X_RAY the Patient is
given his OP form, which was taken before.
For IP:
In case of IP the X_RAYS are sent to concerned ward
through attender. The Head nurse will take care of the X_RAYS in ward and
return them back after usage.
Records Maintenance:
Apart from record mentioned above several records such as
Stock Register, Daily Expenditure Register, Census Registers are maintained.
The stock register is maintained for stock received such as X_RAY films of
different size; chemicals used.
The stock register consists of fields such as
Date | Received/Expenditure | Indent Book NO | Qty | Balance
The Daily Expenditure Register consists of fields such as

Date | No Of Cases | No Of Films | Total
OP | IP | Total OP | IP | Total
Repairs:
In case of repair to the m/c a letter is addressed to MS
requesting for repair .A file of m/c repairs is maintained.
E.C.G:
A Radiographer is responsible for E.C.G
Process:
The patient along with the request form visits the registration
counter. The patient's general details are noted and he/she is sent for test. The
test is conducted and the E.C.G paper is given to the patient immediately.
Records:
Radiographer Incharge maintains records regarding E.C.G.
Records similar to X_RAY such as Stock, Census, and Daily Expenditure
Register are maintained.
The expenditure register consists of fields such as

Date | No Of Cases | No Of rolls | Total
Scanning:
The Scanning is done by trained Radiologist .The Radiologist
maintains a record in which the general details of patient along with the report
are entered.
Process:
The Patient along with the request form visits the Radiologist
.The Radiologist conducts Scanning and writes the report on OP slip or Case
Sheet.
Blood Bank:
Blood collected from the donor are sent for preliminary tests.
According to the results the blood is stored in bags. Whenever patient requires
blood, his blood group is checked and the bag, which gets matched with that
particular patient, is given.
Diet Section:
As the name indicates it consists of records, which consists of
information such as stock availability, Number of patients to be feeded and
type of food.
PROPOSED SYSTEM
To computerize all department offices to the fullest extent, the following

solutions are suggested.
(i) Doctors:
Basic details are automatically generated. His prescriptions are
entered in the system and are sent to the departments concerned like
pharmacy etc.
(ii) Labs:
Request forms send by Doctor is automatically seen at labs on
submission of OP id. Details are generated on the basis of id. Test results
are entered. The results are sent back to the doctor concerned or wards
concerned. The doctor must send request forms to labs. General registers
such as stock, expenditure, census are updated daily. Search procedure
is made easier.
All the above registers are updated.
(iii) Blood Bank:
A system is maintained which informs about the available

stock. This is utilized for the inpatients and for emergency cases.
(iv) Diet Section:
A system is maintained which informs about the available
stock. According to the instructions given by the doctor diet is provided
to the inpatients.
(v) Admin Module:
A new module by name Admin has been proposed in our
project, which performs the following functions:
The operator can perform three functionalities named Add (), Modify () and
Delete ().These three operations are common for the existing four items
belonging to four individual modules.
Thus the operator can add, modify or delete a doctor, a drug name, a ward
and/or a lab test. Whatever the modifications made can be updated in the
database regularly.
Use case diagrams of doctor

Use case diagram of lab technician
Record maintenance
Test Report generation
Search
Use case diagram of dietician and blood bank operator

Use case diagram of admin

Use-Case ID Use-Case Name Priority1 Stability2 Verifiability3
1.1 Prescription
1.2 View Reports
1.3 Admissions
1.4 References
1.5 Investigations
Use-Case ID: 1.1 Use Case Name:

PRESCRIPTION
Description: In this use-case the patient is treated and he is then
decided as Inpatient or Outpatient.
The Doctor prescribes the medicines to the patients.
Preconditions: The Doctor should know his login id.
Post conditions: The Doctor must verify the previous reports of patient if
existed.
He then prescribes required medicines.
Frequency of Use: Whenever the patient enters into his cabin.
Normal Course of The Doctor enters the medicines prescribed to the patient.
Events:
Includes: PATIENTS DETAILS MANAGEMENT use-case.
Alternative No other alternative exists for this use-case.

Courses:
1
Priority: High, Medium or Low
2
Stability: Stable / Unstable
3
Verifiability: Verifiable / Not Verifiable

VIEW REPORTS
Description: In this use-case the Doctor views different reports of
patients whenever required..
Preconditions: The Doctor should know the patient's id.
Post conditions: The Doctor must verify the reports after any investigations.
Frequency of Use: Whenever the patient enters into his cabin.
Normal Course of All the reports are generated and everything is updated in
Events: the database.

Courses:

REFERENCES
Description: In this use-case the Doctor may send the patient to another
Doctor.
Post conditions: If he was his patient he verifies all his previous reports.
Frequency of Use: Whenever the Doctor wishes to do so.
Normal Course of He refers to other Doctor if necessary.

Events: All the reports are generated and everything is updated in
the database.

Courses:

ADMISSIONS
Description: In this use-case the patient can be admitted to any ward
according to his condition.
Post conditions: The Doctor must check the condition of the admitted
patient frequently.
Frequency of Use: Whenever the Doctor wishes to do so.
Normal Course of He checks the condition of the Inpatients frequently.

Events: All these reports are generated and everything is updated in
the database.

Courses:

INVESTIGATIONS
Description: In this use-case the Doctor prescribes the medicines or he
may send the patient for further investigation.
Post conditions: The Doctor must verify the reports after any investigations.
Frequency of Use: Whenever the Doctor feels to do so.
Normal Course of The Doctor prescribes the type of tests to be performed.

Events:

Courses:
Use-Case ID Use-Case Name Priority Stability Verifiability
1.1 Record maintenance

1.2 Test report generations
1.3 Search

Record maintenance
Description: In this use-case the patients test details must be stored in
records. Statistics are also generated.
Preconditions: Lab technician must submit test reports for each test
conducted.
Post conditions: The Records are updated.
Frequency of Use: Once for a day.
Normal Course of The operator adds results of tests.
Events: The system updates the database.
Courses:
Includes: Use-case.
Associated No additional Requirement is needed for managing petition
Requirements: details.

TEST RESULT GENERATIONS
Description: In this use-case the result of test is generated and send to
the doctor.
reconditions: Test must be completed.
Post conditions: The results are generated and send to the doctor.
Frequency of Use: Whenever test is completed.
Normal Course of Database is updated with results and report is sent to the
Events: doctor.
Courses:
Includes:
Associated
Requirements:

Search
Description: In this use-case the lab technician is able to view the
previous results of the patient if necessary.
Preconditions: The patient should have a previous record.
Post conditions: The patient's record is updated

Frequency of Use: For some special cases where a view of previous result is
needed.
Normal Course of User request for search,
Events: System displays the required record.
Courses:
Includes:
Associated Requires patient's previous details.
Requirements:
1.1 Record Keeping in Diet

section

RECORDKEEPING IN DIETSECTION
Description: In this use-case the dietist must enter the details of the
how much quantity of the food given to the patient into
the record.
Preconditions: The Dietist takes the inpatient list from the ward in
charge.
Post conditions: Depending upon the diet record, dietist gives the food for
the inpatient.
Frequency of Use: For every doctors prescription of inpatient on diet this use
case is used.
Normal Course of After giving the food, the dietist maintained the attendance
Events: register for the inpatient.
Alternative Courses:No other alternative exists for this use-case.
Includes: This use case includes DIETSECTION.
Associated No other associated requirements are needed for this use

Requirements: case.
4
5
6
1.1 Data Entry

1.2 Report generation
1.3 Get Stock
1.4 Record Keeping in
Blood bank

DATA ENTRY
Description: If any person wants to give blood voluntarily or by replace-
ment then the operator enters his details.
Preconditions: Whether the Donor is eligible to give Blood or not is found

by testing the Hemoglobin percentage and weight of the
Donor.
Post conditions: Blood bank staff takes the blood from the Donors and
give Donors certificate.
Frequency of Use: Each time the donors giving blood voluntarily or

replacement, this use case is executed.
Normal Course of After taking the Blood from the Donor, the lab technician
Events: tests the Blood for further use. These tests include HIV,
HCV and HBSAG .
Alternative Courses: No other alternative exists for this use-case.
Includes: Blood Grouping use case.
Associated The Id of the patients is needed.

Requirements:

REPORT GENERATION
7
8
9
Description: Various reports like statistics of patients are generated.
Preconditions: Verify the existing data.
Post conditions: Cross checking.
Frequency of Use For each and every entry.
Normal Course of Blood Group will be determined by tile method.

Events:
Alternative No other alternatives are exists for this use-case.
Courses:
Includes: Details of patients and donors.
Associated No other Associated Requirements are required for this use

Requirements: case.

GET STOCK
Description If the inpatient in a situation that he needed Blood

whether he is in the ward or OT then this use case is
used..
Preconditions: 1.The patient must be inpatient.

2.Checking will be done to know that particular Blood
Group of Blood is available or not.
3.cross matching will be done if the Blood of that group is
available.
Post conditions: The newly brought bags are added in the database.
Frequency of Use: For every doctor’s prescription of blood ,this use case is
used.
Normal Course of Blood Transfusion takes place.

Events:

Courses:
Includes: Blood Grouping use case.
Associated No other associated requirements are needed.

Requirements:

RECORD MAINTAINANCE
Description: Here the details about the stock of the blood in the blood
bank ,types of Blood available, which Group of blood is
supplied to which patient and the Donor records are
maintained.
Preconditions: The Doctor prescription must be needed.
In these Records, signature of the Medical Officer is

Post conditions: necessary.
Frequency of Use: For every patient Blood Grouping,
Normal Course of
Events:
Courses:
Includes: Login use-case.
`
1.1 ADD
1.2 DELETE
1.3 MODIFY
Use-Cases Specifications

ADD
Description: In this use-case new drug ,doctor ,ward or test along with
details can be added .
Preconditions: Whether the particular entry is already exist or not.
Post conditions: New id generated for that particular entry.

Frequency of Use: Whenever new entry is required.
Normal Course of New entry will be added along with unique id.
Events:
Courses:

DELETE
Description: In this use-case drugs ,doctor ,ward or test can be deleted .
Preconditions: Whether the particular entry should be exist and it should

10
11
12
not be inter related with other entities
Post conditions: That particular entity will be deleted.

Frequency of Use: Whenever deletion is required.
Normal Course of That particular entity will be deleted.
Events:
Courses:

MODIFY
Description: In this use-case drugs ,doctor ,ward or test details can be
modified .
Preconditions: Whether the particular entry is already exist or not.
Post conditions: Details should be updated for that particular entity.

Frequency of Use: Whenever modifications are required.
Normal Course of Details for that particular entity will be changed.
Events:
Courses:
Blood bank Dietician

Userid- varchar Admin
Password- varchar Userid -varchar
Donorid- varchar Password -varchar Userid- varchar
… Ward number numeric Password- varchar
Address varchar Type of diet varchar Doctor reg.no- numeric
Bagnumber- varchar CLASS DIAGRAMS
Drugcode- varchar
Patientid- varchar Test id- varchar
Wardno- numeric Ward number numeric
Doctor reg.no- varchar
Add ()
Modify ()
Get requisition () Maintaining stats ()
Delete ()
Put indent ()
Get quantity ()
Blood avilability()
Doctor
Userid-
- varchar Labs
Password- varchar
Doctor reg.no- numeric Userid -varchar
Wardno.- numeric Password -varchar
Testid- numeric Patient id- varchar
Drug code- varchar Drugcode -varchar
Diagnosis - varchar Testid- varchar
Patientid- varchar Departmentid -varchar
Doctor reg.no- varchar
Admission ()
References () Get requisition ()
Lab request () Report generation ()
Lab reports Record maintenance ()
Prescription Stats maintenance ()
Stats Putindent ()
Put expenditure ()
Getstock ()
Activity diagram of doctor

Prescription
If he is Refer to
concerned Another doctor
Diagnosis
If If If If If If
necessary necessary necessary necessary
Medicines
Refer to Admit to Send for Send for View
Doctor Investigations bloodgrouping
edit delete
Update record
Activity diagram of lab technician
Stock check by
Lab technician
Yes
Is stock
Get stock
available
No
Update
Apply indent expenditure
No
If stock
received
Yes
Update stock
Submit report No Update

Update
census
Activity diagram of lab technician
After doctor diagnosis
patient comes
Lab technician
Gets patient and
Is patient fit for test

test
Conducting test
yes
Need to
Check analysis
Check
No
Submit report Update analysis
Update census
Activity diagram of dietician
Receiving
indent from ward
Giving food
Updating indent
Activity diacram of blood bank
Donor comes to hospital Conducting camps
Check with%
yes
Collecting blood
Do tests Donor register
yes
If test
Result is +ve
no
no
If donation
voluntary
yes
Donor
Supply another
Blood group
Storing of
Giving certificate
blood Master record Testing record
Activity diagram of blood donation
Patient with request form

Patient
Lab technician receives form mmmmreceivesform
Check for
Type of test
grouping testing transfusion
Do blood test
Do gouping test Find correct group
available
Giving results Giving results Do cross match
If in- no
patient If test=ok
yes
refuse
OP reg
Inpatient register Give bag
ADMIN PATIENT DOCTOR LABS BLOOD BANK DIET
Diet Instructions()
Arrival()
Tests()
Investigations()
Reports()
Reports()
Add(),Modify() and Delete()

MODULES
1. Admin Module.
2. Doctor Diagnosis Module
3. Lab Module
4. Blood Bank Module
5. Diet Section Module
MODULE DESCRIPTION
1. Admin module:
This module does not exist in the existing scenario. It
has been proposed by us to improve the flexibility of our software. In this the
operator can append, modify or delete some entities whenever required from
the Database, thus reducing the memory space required. The provided entities
are Doctor’s details, Drug details, Ward details and Lab test details. Any
modifications done are updated in time.
2. Doctor module:
The doctor signs in his attendance register present in
the R.M.O room as soon as he arrives. The patient visits the doctor along with
his OP form. The Doctor treats the patient and may prescribe the following:
(i) Medicines
(ii) Test or investigations
(iii) Admission as in patient
(iv)Refer to another doctor.
There are several departments present in this module such as
Orthopedic, Gyaenic, ENT, Pediatrics, Surgical, Ophthalmic, Dental and
Medical.
Each department consists of doctors with the designations
CSS: Civil Surgeon Specialist

DCS: Deputy Civil Surgeon
CAS: Civil Assistant Surgeon
Note: Some posts are vacant.
The working hours of the doctors are from 9:00 am to 2:00pm.

Functions of CSS:
Every CSS starts his daily work from wards. He visits the In
patients of his concerned ward and gives the diet and treatment instructions to
Head Nurse. As soon as he finishes his round he gets back to his OP room. He
is the supreme power of his department.
He is responsible for the post-condition of the patient after operation.
The duty doctor in the case of emergency calls him after 2:00 p.m.
Functions of DCS:
He is the next authority after CSS. He, in his OP room
attends the patient. In rare cases, if he has to operate a patient he should take
the approval of CSS. This is the promotionary post to CAS.
Functions of CAS:
He is next to CSS or DCS. He, in his OP room attends the
patient; any tests recommended by him must be acknowledged by the R.M.O.
33 types of diseases and 141 types of medicines are recognized by A.P.V.V.P.
Each disease is given a code. His prescription is written on the OP form.
He sends the requisition forms for the tests through patients. If the prescribed
medicine is not available the doctor writes it on separate slip.
Costly drugs prescribed by the doctor must be acknowledged by the
R.M.O.
Doctors in every department maintain a common OPregister. This
register includes:
Opnumber
Date
Gender/Age
Name of the Disease
Diagnosis
Old Opnumber (if the patient has already visited before)
Note: Codes assigned to the disease are not in implementation.
The doctor counts the total number of old and new patients for every day
and enters it in this register.
The register is submitted to the administration department for every
month.
The following are the extra caders given to the CAS.

C.M.O works at Casualty. Description of his functions is continued in IP
Registration module.
D.M.O (works after 2:00 pm.)He is responsible for Inpatient after CSS.
Note: C.M.O – Casualty Medical Officer

D.M.O – Duty Medical Officer
3. Labs module:
The labs department consists of three sections:
Pathological laboratory.
Biochemical laboratory.
Urine Analysis laboratory
Medical Officer is the incharge of lab. Two junior analysts work under
the supervision of MO one for Biochemistry another for Microbiology. There are
four lab technicians and two lab attendants.
MO:
The job of MO is to supervise the lab.
Junior Analyst:
The job of Junior Analyst is to supervise the Lab Technician and Lab
attendants. Record maintenance and advising lab technicians are also his jobs.
Lab Technician:
The jobs of Lab Technician are sample collection, doing test. One Lab
Technician is working at reception.
Lab Attendant:
His job is to assist Lab Technician and clean the lab.
Process:
The patient along with the request form, which is given by a
doctor, visits the registration counter where his general details along with the
ip/op number and the test to be done are noted .The patient is given a serial
No. The Registration counter is the same for all labs. The samples are collected
and sent to the concerned section. Next day the patient is given his report
based on serial number.
Records:
Three investigations record each for a section ,stock register,
Expenditure ,census Register is maintained.
The investigations record consists general details and test details.

The stock record consists of fields
Date | Received | Qty | Expenditure | Balance
The Expenditure register consists of fields

Date | given to | Qty | Expenditure | Balance
The Census register consists of fields
CBP | ESR | HB | MP | BTCT | Stool | Seman Analysis | Blood Sugar | Blood

Urea | Serum Creatinin | Widal | VDRL | Urine
Each field consists of two sub fields ip and op.
Radiology:
The Radiology department consists of three sections:
X_RAY
E.C.G
Scanning
(1) X_RAY:
The Radiologist is the head of X_RAY department.
Three Radiographers work under his supervision. one dark room assistant and
two at tenders also work under the supervision of Radiologist.
(2)Radiologist:
The duty of the Radiologist is to supervise the work of X_RAY
lab .He also writes his diagnosis on every X_RAY film taken. He is responsible
for taking scanning also.
Radiographer:
Radiographer is the person who is responsible for taking X_RAYS.
Among the three Radiographers present one will be the incharge, who is
responsible for maintanance of various records of X_RAY lab.
Darkroom Assistant:
He is responsible for the development of X_RAYS.
Attenders:
The attenders’ duty is to deliver the X_RAYS to wards and doctors
concerned and to get back the same after usage.
Process:
The patient along with the request form which is given by a CSS or
which is acknowledged by the R.M.O visits the registration counter where his
general details along with the ip/op number and the body part that is to be
tested are noted .The patient is given a serial No. The Registration counter is
the same for X_RAY and E.C.G.
For OP:
The patient attends the test and visits the registration counter the next
day. The patient must submit his OP form on which his serial No is written.
The patient is given his X_RAY .The patient must return his X_RAY after
showing it to the doctor. After returning of X_RAY the Patient is given his OP
form, which was taken before.
For IP:
In case of IP the X_RAYS are sent to concerned ward through attender. The
Head nurse will take care of the X_RAYS in ward and return them back after
usage.
Records Maintanance:
Apart from record mentioned above several records such as Stock
Register, Daily Expenditure Register, Census Register is maintained. The stock
register is maintained for stock received such as X_RAY films of different size;
chemicals used .the stock register consists of fields such as
The Daily Expenditure Register consists of fields such as
Date | No Of Cases | No Of Films | Total

Repairs:
In case of repair to the m/c a letter is addressed to MS requesting for repair
.A file of m/c repairs is maintained.
(2) E.C.G:
A Radiographer is responsible for E.C.G process. The patient along
with the request form visits the registration counter. The patient's general
details are noted and he/she is sent for test. The test is conducted and the
E.C.G paper is given to the patient immediately.
Records:
Radiographer Incharge maintains records regarding E.C.G.
Records similar to X_RAY such as Stock, Census, and Daily Expenditure
Register are maintained.
The expenditure register consists of fields such as
Date | No Of Cases | No Of rolls | Total

(3)Scanning:
The Scanning is done by trained Radiologist .The Radiologist
maintains a record in which the general details of patient along with the report
are entered.
Process:
The Patient along with the request form visits the Radiologist .The
Radiologist conducts Scanning and writes the report on OP slip or Case Sheet.
4. Blood Bank module:

Blood collected from the donor are sent for preliminary tests.
According to the results the blood is stored in bags. Whenever patient requires
blood, his blood group is checked and the bag that gets matched with that
particular patient is given.
5. Diet Section module:
As the name indicates it consists of records that
consists of information such as stock availability, Number of patients to be
feeded and type of food.
FEASIBILITY ANALYSIS
Feasibility study is an important phase in the software development

process. It enables the developer to have an assessment of the product
being developed. It refers to the feasibility study of the product in terms of
outcomes of the product, operational use and technical support required for
implementing it.
Feasibility study should be performed on the basis of various criteria

and parameters. The various feasibility studies are:
• Economic Feasibility
• Operational Feasibility
• Technical Feasibility
1. Economic feasibility:
It refers to the benefits or outcomes we are deriving from the product
as compared to the total cost we are spending for developing the product. If
the benefits are more or less the same as the older system, then it is not
feasible to develop the product.
The software used in the proposed system is from open source and hence it
is feasible economically.
2. Operational Feasibility:
It refers to the feasibility of the product to be operational. Some
products may work very well at design and implementation but may fail in the
real time environment. It includes the study of additional human resource

required and their technical expertise.
Proposed system is user friendly in nature. Knave users can also
use the system and hence it is feasible at operations.
3. Technical Feasibility:
It refers to whether the software that is available in the market fully
supports the present application. It studies the pros and cons of using
particular software for the development and its feasibility. It also studies the
additional training needed to be given to the people to make the application
work.
Technical feasibility can be achieved with the extensions of open source
development in a wide area.
Overview:
The Software Requirements Specification (SRS) begins the
translation process that converts the software requirements into the language
the developers will use. The SRS draws on the use-cases from the User
Requirement Document (URD) and analyzes the situations from a number of
perspectives to discover and eliminate inconsistencies, ambiguities, and
omissions before development progresses significantly under mistaken
assumptions.
Problem Frame Existing:

Doctor Module As soon as the patient enters the doctor’s
room, he is treated by doctor.
Doctor then does his diagnosis and prescribes one or
many of the following:
Medicines
Tests
Reference to another doctor or specialist
Admission into wards
Diagnosis details along with patient’s id and few
personal details are maintained by him in a register...
Proposed System:
Patient’s few details and OP id is visible

to the doctor concerned on his screen. He enters his
diagnosis details in his system.
His prescriptions are directly sent to departments
concerned through his system.
References:
Dr.S.Chandra Prakash (CSS & DCHS)
Dr.G.Papalal (MS & CSS)
Dr.Sudarshan (Dy.CS)
Dr.Madanmohan (CSS)
Dr. Anil (CAS)
Dr. Prabhavati (CAS)
Dr.G.Subbhaiah (CSS)

Blood Bank Donor has to fill a form and then his blood
Module is further tested. If all the results are well his blood is
taken into a bag and is given a bag number.
Else it is dispatched.
Proposed System:
Stock availability is known in
advance. Blood bag that is near to the expiry date is
highlighted.
References:
Staff Nurse and Lab Assistant.

Diet Section According to the request indent sent by
Module the nurse in wards the diet is sent to the wards

concerned.
Records are maintained in the diet section, which
includes type of diet and quantity of diet given to each
ward.
Proposed System:
All these details are stored in the
database. The stock is automatically generated.
References:
Dietician in that Diet Section

Lab Module The patient attends the test when
prescribed by the doctor. In case of investigations,
doctor gives patient a request form, which he must
submit at labs.
The lab technician upon receiving request
form performs test and gives test result to patient the
next day.
Lab technician in addition to above work
maintains some records and registers.
Proposed System:
Patient details are automatically generated
at labs upon submission of OP id. Test reports are
directly sent to doctor instead of patient. Reports can
be submitted easily. Registers are updated
automatically. Record maintenance is made easier.
References:
Lab technician at blood lab and x-ray

department.
Interface Requirements:
This section defines the parameters that the software product must follow
while interacting with the outside world.
User Interfaces Fonts: Black, 12,Times New Roman

Button: Default size.
Alert messages: Java script alert messages.
Links using HTML tags.
Login Screen
Doctor login form
Doctor diagnosis form
Medicines form
Tests form
Refer to another doctor
Admit form
Test Reports
Previous Diagnosis Reports
Donor form
Indent Form
Expenditure Form
Stock Register Form
Diet Register Form
Hardware Interfaces Clients:

Processor : P4.
RAM : 128/256MB
Operating System : Linux
Database server : Postgres 7.3.2
Hard Disk required : above
40GB
Hosting Server Configuration :
Processor : P4
RAM : 512MB
Database server : Postgres 7.3.2
CD-Writer : 52X32X52X
Software Linux, PHP 5.0, Postgresql 7.3.2, Apache server

Interfaces
Communications Internet, HTTP protocols

Interfaces Message Formats : Cookies, Sessions.
Functional Requirements
1. Details of the job charts of entire hospital staff.

2. Working hours of the hospital staff.
3. Workflow of the hospital.
4. Type of records maintained.

5. Type of reports generated.
Feature Analysis 1.Master Updating.

2.Generation of OP Id.
3.Reports.
System Feature ID: System Feature Name:

SF-01 Workflow module of proposed system
Description: This would describe about the entire procedure prevailing

in the Hospital.
Operations: DOCTOR:
He does the diagnosis and these details are
stored in the database.
LABS:
The operator in the Labs concerned accesses
lab tests prescribed by the doctor.
BLOOD BANK:
Blood for the needy is supplied. Availability of
stock is known.
DIET:
Diet is supplied to the wards concerned.
SUBMIT():
Details entered in any form are stored or updated
in the database.
S. No. Class Name Responsibility Persistent (Y / N)

1 Doctor Diagnosis Treats patients, Y
gives directions or
prescriptions and
performs
operations.
2 Labs Receives Y
requisition form
of patients from
Doctors and
submits reports
to the Doctor
concerned.
Maintains records
with all stock
details.
3 Blood bank Collects the blood Y
from donor, sends
to the operation
theater or wards
as required by the
patient.
4 Diet Section Records are Y
maintained which
includes the
details of the
amount of diet
supplied on ward
and patient basis.
5 Admin Can add, modify Y

or delete any of
the details related
to Doctor, Ward,
Drug and Test.
Nonfunctional Requirements:
Performance Band Width : 256KBps

Requirements Kind of Fire Wall : Norton, Mc. Afee Fire Walls
Speed of Lines : 100MBps
Connection Pooling : 30 Connections
Safety & By incorporating a robust and proven RDBMS

Reliability (postgreSQL) into the system,
Requirements Reliable performance and integrity of data is ensured.
Security Sensitive data is protected from unwanted access by

Requirements employing appropriate technology and implementing strict
user access criteria.
Software Quality Menu driven programs with user-friendly interface with

Attributes simpler hyperlinks.
It is very easy to use. Backup mechanism is considered for
maintainability of the software as well as database. As it is
object oriented, reusability exists. As project is based on
MVC architecture, testability exists.
DOCUMENT DESIGN
1.system Design:
Software Requirements:
1. Operating System ---------- Red Hat Linux 9, Windows

98, 2000
XP, NT
2. Languages ------------------- PHP4, Javascript1.4
3. Database --------------------- Postgresql 7.3.2
4. Network ---------------------- LAN
5. Fully Functional Html Editor
6. Apache server .
Hardware Requirements:
1. Personal computers with P-IV processor
Table No.: 2
Table Name: 1.Service Mappings
table Description: Table to assign different services to users.
Seq. # Column Column Column Type PK/FK? Null/ Remarks
Name Description Not Null
1. loginid Login id of Varchar FK Not null No

the user
2. Services Services
for user. Varchar - Not null No
Constraints: Foreign key loginid refers login.

Table No.: 3
Table Name: 2. op_registration
Table Description: Table to register the patient as out patient.
Unique PK No
Identity to
the patient.
Name of the - No
patient.
Gender of - No
opid
1. the patient. Varchar Not null
Guardian - No
name of the
name
2. patient. Varchar - Not null No
Mandals/M
gender
3. unicipality. Varchar - Not null No
Mandal/Mu
Guardian
4. nicipality Varchar - Not null No
name.
Locality
5. Panchayithi Varchar - Not null No
name. - No
Addr1
6. Village Varchar Not null
name. - No
Addr2
7. Habitation Varchar Not null
Caste of the - No
Addr3
8. patient. Varchar Not null
Addr4
9. Religion of Varchar - Not null No
the patient.
Addr5
10. complaint Varchar - Not null No
Caste
11. Varchar - Not null No
Religion
12. Varchar Not null
Complaint
13. Varchar Not null
15. Economic Economic Varchar - Not null No

Status status of
Patient
16. Day Daily date Date - Not null No
17. Time Current Varchar - Not null No

time
18. Doctor Room Numeric - Not null No
room number
19. Type of Type of Varchar - Not null No
Case case
20. Dob Date of Date - Not null No
birth
21. Phone Phonr Numeric - Not null No
number
22. age Age of the Numeric - Not null No
patient
Constraints: Primary key: opid
Table No.: 4
Table Name: 2.wards master
Table Description: Table listing the details of all the wards
Seq. # Column Name Column Column PK/FK? Null/ Remarks
Description Type Not Null
1. Ward_number Ward Numeric PK Not null No
Number
2. Ward_name Name of the Varchar - No
ward
3. Ward_incharge In charge of Varchar - No
particular
ward
4. head nurse Head Nurse Varchar - No
of particular
ward
5. no_of_beds Total Number Numeric - No
of beds in a
ward
6. availablebeds Total number Numeric - No
of available
beds
Constraints:
Primary Keys: ward_number
Table No.: 5
Table Name: 3.drugs_master
Table Description: Table listing details of all the operations
1. drug_code Unique id to Varchar PK Not null No
each drug
2. drug_type Type of the Varchar - No
3. drug_name drug Varchar
Name of - No
the drug
Constraints:
Primary Key: drug_code

Table No.: 6
Table Name: 4.indent
Table Description: Table listing details list of items placed in indent
1. drug_code Unique id to Varchar FK Not null No
each drug
2. date Date date - No
3. indentfrom Indent From Varchar - No
4. indentto Indent to Varchar - No
5. quantity_re Requested Varchar - No

quested Quantity
6. amount
7. quantity Received Numeric - No
received Quantity
8. vochure_nu Vochure Numeric - No
mber number
CConstraints:
Foreign Key: drug_code references drugs_master (drug_code)

Table No.: 7
Table Name: 5.expenditure
Table Description: Table listing details of expenditure
1. drug_code Unique id to Varchar FK Not null No
each drug
3. issued by Expenditure Varchar - No
issued by
4. issuedtto Expenditure Varchar - No
issued by
5. quantity Quantity Numeric - No
issued
6. vochure_nu Vochure Numeric - No
7. mber number
8. balance Balance Numeric - No

amount
C
Constraints: Foreign key drug_code refers drugs_master[drug_code]

Table No.: 8
Table Name: 6.prescribed_medicines
Table Description: Table details list of voucher numbers issued
1. opid Unique id Varchar FK Not null No
for
Each
outpatient
2. drug_code Unique code Varchar FK No
to every
drug
3 quantity Quantity of numeric - No
prescribed
medicines
4. doctors_re Regn No. of Varchar FK No
g_number the doctor
5. dosage Medicine Numeric No
dosage
6. Remarks Remarks Varchar No
Constraints:
Foreign Keys: opid references op_registration;

Drug_code references drugs_master;
Doctors_reg_number references Doctor master;
Table No.: 9
Table Name: 7.diet
Table Description: Describes the daily treatment of the patient in wards
1. sago Quantity of Numeric - No
sago
2. cmb Quantity of Numeric - No
cmb
3. hpd Quantity of Numeric - No
hpd
4. pm Quantity of Numeric - No
pm
5. date Current Date - No
date
6. na New Numeric - No
admissions
7. total Total Numeric - No
quantity of
diet
Table No.: 10
Table Name: 3.doctors_master
Table Description: Describes the daily treatment of the patient in wards
1. doctors_re Unique varchar PK Not Null No

g_number number
to each
doctor
2. doctors Name of the varchar - No

name doctor
3. designatio Doctor varchar - No
n designation
4. departme Department varchar - No
nt of doctor
5. doctor_roo Room Numeric No
m_no number of
doctor
6. Specializa Specializati varchar No
tion on of doctor
Constraints:
Primary Keys: doctors_reg_number
Table No.: 11
Table Name: 4.department
Table Description: Details of the departments in the hospital
1. Departmenti Unique id Numeric PK Not null No

d to each
department -
2. Department Name of Varchar No
name the -
department
Constraints: Primary Keys: departmentid
Table No.: 12
Table Name: 5.Test_master
Table Description: Details of the different tests of various departments in the
hospital
Are specified here.
1. testid Unique id Numeric PK Not null No

to each test
2 testname Used to Varchar - No
specify the
test names
3 departmenti Unique id Numeric - No
d to
Each
department
4 department Name of Varchar FK No

name the
department
Constraints:
Primary Keys:
Foreign Keys: departmentid references department;
Table No.: 13
Table Name: 6.patient_test
Table Description: Details of the different tests prescribed by the doctor.
1. opid opid of the varchar FK Not Null No

patient
2. day Current date - No
date to
3 testid Test Numeric
prescribed FK No
by the
doctor
4 departmenti Departmen Numeric FK No
d t id of that
particular
test
Constraints:
Foreign Keys: departmentid references department(departmentid)
testid references tests (testid)
Table No.: 14
Table Name: 7.uanalysis
Table Description: Details of the urine report.
1. opid opid of the varchar FK Not Null No
patient
2. day Date of date - No
issue
3 app_color Appearance varchar - No

and color
4 albumin Albumin varchar - No

content
5. sugar Sugar varchar - No
content
6. bilesalts Bile salts varchar - No
content
7. bilepigments Bilepigmen varchar - No
ts
Content
8. ph Ph content varchar - No
9. spgravity Specific varchar - No
gravity
10. puscells Puscells varchar - No
11. erythrocytes Erythrocyte varchar - No
s count
epithelialcel
12. ls Epithelialce varchar - No
lls
casts Count
13. crystals Casts varchar - No
14. other Crystals varchar - No
15. findings Other
varchar
heamoglobin findings - No
varchar
16. Hemoglobin - No
inpatient %
17. Checks if - No
varchar
patient is
Inpatient
Constraints: Foreign key opid refers op_registration[opid]
Table No.: 15
Table Name: 8.scanning
Table Description: Details of the scanning report.
Name Description
1. Opid Opid of the Varchar FK Not Null No
patient
2. Day Date Varchar - No
4. Test done Test done Varchar - No
3 Result Result Varchar - No
4.. Inpatient Checks if Varchar - No

patient is
Inpatient
Constraints: Foreign Keys: opid references op_registration (opid)

Table No.: 16
Table Name: 9.Xray
Table Description: Details of the x-ray report.
1. Opid Opid of the Varchar FK Not Null No
patient
2. Day Date Varchar No
3 Part Part to be Varchar No

examined
4.. Size of film Size of film Varchar No
to be taken
5. Result Result Varchar No
6. Inpatient Checks if Varchar No

patient is
Inpatient
Constraints: Foreign Keys: opid references op_registration(opid)
Table No.: 17
Table Name: 10.btests
Table Description: Details of blood tests
1. donorid Unique id varchar FK Not Null No
assigned to
donor -
2. hiv HIV varchar No
3. hcv HCV varchar No
4. hbsag HBSAG varchar No
5. vdrl VDRL varchar No
6. malaria Malaria varchar No
7. date Date date No
Constraints:
FK donarid refers donar - donarid

Table No.: 18
Table Name: 11.bagtable
Table Description: Details of bags containing blood donated.
1. bagno Unique id varchar PK Not Null No
assigned to
each bag
2. hiv HIV varchar - No
3. hcv HCV varchar - No
4. hbsag HBSAG varchar - No
5. vdrl VDRL varchar - No
6. malaria Malaria varchar - No
8. utilization No. of bags varchar - No
utilized -
9. irregular Irregular varchar
antibodies Antibodies - No
10. bgroups Blood varchar
11. delete Group boolean - No
Used to - No
check if a
bag is
deleted
Constraints:
Primary Keys: bagno

Table No.: 19
Table Name: 12.biochemistry
Table Description: Details of bags containing blood donated.
Seq. Column Name Column Description Column PK/FK Null/ Remarks
# Type ? Not Null
1. opid Unique id assigned Varchar FK Not Null No
to each outpatient
2. Date Date date - No
3. bs_fasting Blood sugar Fasting varchar - No
Value
4. bs_postlunch Blood Sugar varchar - No
postlunch Value
5. bs_random Blood sugar Random varchar - No
Value
6. us_fasting Urine Sugar Fasting varchar - No
Value
7. us_postlunch Urine Sugar varchar - No
postlunch Value
8. us_random Urine sugar random varchar - No
value
9. bloodurea Blood Urea Value varchar - No
10. serumcreatinine Serumcreatinine varchar - No
Value
11 serumbilirubin Serum bilirubin varchar - No
12. widal Widal varchar - No
13. vdrl Vdrl varchar - No
14. inpatiet Inpatient status varchar - No
Constraints:
Foreign Keys: opid refers op_registration opid.
Table No.: 20
Table Name: 8.Donor
Table Description: Details of donors
Seq. # Column Column Description Column PK/FK Null/ Remark

Name Type ? Not s
Null
1. donor_id unique id for each donor varchar PK Not No
2. name donor name varchar - Null No
3. age donor age numeric - - No
4. blood_group blood group of donor varchar - - No
5. weight donor weight numeric - - No

6. hb hemoglobin percentage of numeric - - No
donor No
7. bag_no bag number in which numeric - - No
blood is stored
8 qty quantity of the blood numeric - - No
stored
9 blood blood pressure of donor numeric - - No
pressure
10. medical the result of the medical varchar - - No
exam exam
11 date_of_colle date on which the blood is date - - No
ction collected
12.. date_of_expir date on which the blood is date - - No
ing to be expired
13. category_of_ category of donation varchar - - No
donation
14. patient_detai patient details in case of varchar - - No
ls replacement donation
15. telephone_n telephone number of the numeric - - No
umber donor
16. mobile mobile number of the numeric - - No
number donor
17. e_mail e_mail id of donor varchar - - No

18. fax_number fax number of donor numeric - - No
19. occupation donor’s occupation varchar - - No
20. address address of the donor varchar - - No
21. fathersname donor’s father name varchar - - No
22. dateofbirth donor’s date of birth date - - No
23. date current date date - - No
24. location location of the donor varchar - - No
25. gender gender of donor varchar - - No
26. organization organization of donor varchar - -
Constraints:
Primary Key : donor_id
Table No.: 21
Table Name: 9.In_patient
Table Description: Details of in patients
Seq. Column Name Column Description Column PK/FK?Null/ Remarks
# Type Not
Null
1. ip_no Unique ip no for each Varchar FK Not No
patient
2. ipbloodgroup In patient’s blood varchar - Null No
3. donor_id group varchar -
Id of donor from whom No
this patient is taking
4. saline_immediateblood varchar - No
This is one type of test
5. saline_37deg in transfusion varchar - No
6. albumin_37 One type of test varchar - No

7. compatability One type of test varchar - No
Checks for
8. prescribed_by compatibility varchar - No
9. hiv Doctor’s name Varchar - No

10 hcv varchar - No
11. vdrl Hiv varchar - No
12. hbsag Hcv varchar - No
13 malaria Vdrl varchar - No
14. testresult Hbsag Varchar - No
15. coombs Malaria varchar - No
16. date Results of the test date - No
17. tests One type of test boolean - No
18. trans Current date boolean - No
19. groups Boolean expression boolean - No
Boolean expression
Boolean expression
constraints:
Foreign Key : ip_no references ip_registation(ipno)

Table No.: 22
Table Name: 13.Out_patient
Table Description: Details of all out patients
Seq. # Column Column Column PK/FK? Null/ Remarks
Name Description Type Not Null
1. op_id Unique id for each Varchar FK Not Null No
patient
2. Opblood_gro Blood group of the Varchar - No
up patient
3. Prescribed Prescribed by Varchar - No
by whom
4. hiv HIV varchar - No
5. hcv HCV varchar - No
6. vdrl VDRL varchar - No
7. hbsag HBSAG varchar - No

8 malaria MALARIA varchar - No
9 testresult TESTREULT varchar - No
date
10 date Current date -
11 groups Boolean expression boolean - NO
No
12 teste Boolean expression boolean -
constraints:
Foreign Key : op id references op_registation(opid)

Table No.: 23
Table Name: 14.pathalogy
Table Description: Details of all out patients
Seq. # Column Name Column Column PK/FK?Null/ Remarks
Description Type Not
Null
1. Opid Unique id given Varchar FK Not -
to a patient Null
2. Day Date Date
Hb Varchar
3. Test reading
4. Rbc Test reading Varchar
Wbc Varchar
5. Test reading
6. Neutrophills Test reading Varchar
7. Test reading
Lymphocytes Varchar
eosinophills varchar
8. Test reading
9. Monocytes Test reading Varchar

Basophills Varchar
10. Test reading
11. Bloodpicture Test reading Varchar
Esr_1 Varchar
12. Test reading
13. Esr_2 Test reading Varchar
14. Bleedingtime Test reading
Varchar
15. Clottingtime Test reading Varchar
16. Mp Test reading
Varchar
17. Udrl Test reading Varchar
varchar
18. inpatient Inpatient Status
of
Patient
constraints:
FK opid refers Op_registration
Opid.
ABOUT SOFTWARE
7. SOFTWARE DEVELOPMENT ENVIRONMENT
7.1 PHP TECHNOLOGY:
PHP recursive acronym for PHP: Hypertext Preprocessor is a widely used

Open Source general-purpose scripting language that is especially suited for
Web development and can be embedded into HTML.
The best things in using PHP: Are that it is extremely simple for a newcomer,
but offers many advanced features for a professional programmer.
PHP's features: PHP is mainly focused on server-side scripting, so you can do

anything any other CGI program can do, such as collect form data, generate
dynamic page content, or send and receive cookies. But PHP can do much
more.
There are three main areas where PHP scripts are used.
Server-side scripting: This is the most traditional and main target field for
PHP. You need three things to make this work:
The PHP parser (CGI or server module)

A web server
A web browser
You need to run the web server, with a connected PHP installation. You can
access the PHP program output with a web browser, viewing the PHP page
through the server.
Command line scripting: You can make a PHP script to run it without any
server or browser. You only need the PHP parser to use it this way scripts can
also be used for simple text processing tasks.
Writing desktop applications: PHP is probably not the very best language to
create a desktop application with a graphical user interface, but if you know
PHP very well, and would like to use some advanced PHP features in your
client-side applications you can also use PHP-GTK to write such programs. You
also have the ability to write cross-platform applications this way. PHP-GTK is
an extension to PHP, not available in the main distribution
With PHP you have the freedom of choosing an operating system

and a web server. Furthermore, you also have the choice of using procedural
programming or object oriented programming, or a mixture of them. Although
not every standard OOP feature is implemented in PHP 4, many code libraries
and large applications (including the PEAR library) are written only using OOP
code. PHP 5 fixes the OOP related weaknesses of PHP 4, and introduces a
complete object model.
With PHP you are not limited to output HTML. PHP's abilities
include outputting images; PDF files and even flash movies (using labs and
Ming) generated on the fly. You can also output easily any text, such as XHTML
and any other XML file. PHP can auto generate these files, and save them in
the file system, instead of printing it out, forming a server-side cache for your
dynamic content.
--One of the strongest and most significant features in PHP is its

support for a wide range of databases.-- PHP also has support for talking to
other services using protocols such as LDAP, IMAP, SNMP, NNTP, POP3, and
HTTP
Smarty : Smarty is a template engine for PHP. It facilitates a manageable

way to separate application logic and content from its representation. This is
best described in a situation where the programmer and the template designer
play different roles. They are passed into Smarty by the application, and then
the template designer edits the templates and uses a combination of HTML
tags and template tags to format the presentation of these elements (HTML
tables, background colors, font sizes, style sheets, etc.) If the programmer
needs to change the way the article content is retrieved (a change in application
logic.) This change does not affect the template designer; the content will still
arrive in the template exactly the same. Likewise, if the template designer
wants to completely redesign the templates, this requires no changes to the
application logic. Therefore, the programmer can make changes to the
application logic without the need to restructure templates, and the template
designer can make changes to templates without breaking application logic
.
One design goal of Smarty is the separation of business logic and
presentation logic. This means templates can certainly contain logic under the
condition that it is for presentation only. Things such as including other
templates, altering table row colors, uppercasing a variable, looping over an
array of data and displaying it, etc. are all examples of presentation logic.
This does not mean that Smarty forces a separation of business and
presentation logic.
One of the unique aspects about Smarty is the template compiling.

This means Smarty reads the template files and creates PHP scripts from them.
Once they are created, they are executed from then on. Therefore there is no
costly template file parsing for each request, and each template can take full
advantage of PHP compiler cache solutions such as Send Accelerator
Some of Smarty's features:
• It is extremely fast.
• It is efficient since the PHP parser does the dirty work.
• No template-parsing overhead, only compiles once.
• It is smart about recompiling only the template files that have changed.
• It is possible to embed PHP code right in your template files, although
this may not be needed since the engine is so customizable.
• Built-in caching support
• Plug in architecture
Requirements:
Smarty requires a web server running PHP 4.0.6 or later.
HTML : HTML is platform independent, meaning it can be written and viewed

on any type of computer (Windows, Mac, UNIX/Linux, whatever!) Because
HTML is platform independent, you'll need to save your HTML files in standard
text format, sometimes known as ASCII.
Start with a title
Every HTML document needs a title.
<title>Hospital Management System</title>

The title text is preceded by the start tag <title> and ends with the
matching end tag </title>. The title should be placed at the beginning of your
document
Adding interest to your pages with images : Images can be used to make
your Web pages distinctive and greatly help to get your message across. The
simple way to add an image is using the <img> tag.
Adding links to other pages : What makes the Web so effective is the
ability to define links from one page to another, and to follow links at the click
of a button. A single click can take you right across the world!
Links are defined with the <a> tag. The text between the <a>
and the </a> is used as the caption for the link.
Preformatted Text : One of the advantages of the Web is that text is

automatically wrapped into lines fitting within the current window size.
Sometimes though, you will want to disable this behavior. You do this using
the pre element
<pre>
Preformatted text
</pre>
Preformatted text is generally rendered using a monospaced font

where each character has the same width. If you define a style rule for the pre
element, some browsers forget to use the monospace font, necessitating the
use of the font-family property.
Flowing text around images : With HTML, you can choose whether any
given image is treated as part of the current text line or is floated to the left or
right margins. You control this via the align attribute. If the align attribute is set
to left the image floats to the left margin. If it is set to right the image floats to
the right margin.
JavaScript : JavaScript is a compact, object-based scripting language for

developing client and server Internet applications. JavaScript statements can
be embedded directly in an HTML page. These statements can recognize and
respond to user events such as mouse clicks, form input, and page navigation.
For example, you can write a JavaScript function to verify that users enter
valid information into a form. Without any network transmission, an HTML
page with embedded JavaScript can interpret the entered text and alert the
user with a message dialog if the input is invalid. Or you can use JavaScript to
perform an action (such as play an audio file, execute an applet, or
communicate with a plug-in) in response to the user opening or exiting a page.
JavaScript is a programmable API that allows cross-platform

scripting of events, objects, and actions. It allows the page designer to access
events such as startups, exits, and users' mouse clicks. JavaScript extends the
programmatic capabilities of most browsers to a wide range of authors, and is
easy enough for anyone who can compose HTML.
Using JavaScript, even less-experienced developers will be able to

direct responses from a variety of events, objects, and actions. It provides
anyone who can compose HTML with the ability to change images and play
different sounds in response to specified events, such as a users' mouse click
or screen exit and entry.
JavaScript code is typically embedded into an HTML document

using the SCRIPT tag. You are free to embed as many scripts into a single
document as you like, using multiple SCRIPT tags. A script embedded in HTML
with the SCRIPT tag uses the format:
<script language="JavaScript">

</script>
Scripts can be placed inside comment fields to ensure that old
browsers that do not recognize JavaScript do not display your JavaScript code.
The markup to begin a comment field is .
JavaScript code, much like other programming languages, is made up of

statements, which serve to make assignments, compare values, and execute
other sections of code.
POSTGRESQL : PostgreSQL is a highly scalable, SQL compliant, open source

object-relational database management system (ORDBMS) based on
POSTGRES, Version 4.2, developed at the University of California at Berkeley
Computer Science Department. It supports SQL92 and SQL99
It offers many modern features:

complex queries
foreign keys
triggers
views
transactional integrity
multiversion concurrency control
Additionally, PostgreSQL can be extended by the user in many ways: By adding

new
data types
functions
operators
aggregate functions
index methods
procedural languages
Advantages: PostgreSQL offers many advantages for your company or

business over other database systems.
Immunity to over-deployment : Over-deployment is what some proprietary
database vendor’s regard as their #1 licence compliance problem. With
PostgreSQL, no-one can sue you for breaking licensing agreements, as there is
no associated licensing cost for the software.
This has several additional advantages:
More profitable business models with wide-scale deployment.
No possibility of being audited for license compliance at any stage.
Flexibility to do concept research and trial deployments without

needing to include additional licensing costs.
Better support than the proprietary vendors : In addition to our strong

support offerings, we have a vibrant community of PostgreSQL professionals
and enthusiasts that your staff can draw upon and contribute to.
Significant saving on staffing costs : Our software has been designed and
created to have much lower maintenance and tuning requirements than the
leading proprietary databases, yet still retain all of the features, stability, and
performance.
In addition to this our training programs are generally regarded as

being far more cost effective, manageable, and practical in the real world than
that of the leading proprietary database vendors.
Legendary reliability and stability : Unlike many proprietary databases,

it is extremely common for companies to report that PostgreSQL has never,
ever crashed for them in several years of high activity operation. Not even
once. It just works.
Extensible : The source code is available to all at no charge. If your staff have
a need to customise or extend PostgreSQL in any way then they are able to do
so with a minimum of effort, and with no attached costs. This is
complemented by the community of PostgreSQL professionals and enthusiasts
around the globe that also actively extend PostgreSQL on a daily basis.
Cross platform : PostgreSQL is available for almost every brand of Unix (34
platforms with the latest stable release), and Windows compatibility is available
via the Cygwin framework. Native Windows compatibility is also available with
version 8.0 and above.
Designed for high volume environments : We use a multiple row data

storage strategy called MVCC to make PostgreSQL extremely responsive in high
volume environments. The leading proprietary database vendor uses this
technology as well, for the same reasons.
GUI database design and administration tools : Several high quality GUI
tools exist to both administer the database and do database design .
TESTING
Testing is a process, which reveals errors in the program. It is

the major quality measure employed during software development.
During software development. During testing, the program is executed
with a set of test cases and the output of the program for the test cases
is evaluated to determine if the program is performing as it is expected to
perform.
TESTING STRATAGIES
In order to make sure that the system does not have errors, the different
levels of testing strategies that are applied at differing phases of software
development are:
1. Unit Testing:
Unit Testing is done on individual modules as they are completed

and become
executable. It is confined only to the designer's requirements.
Each module can be tested using the following two Strategies:
2. Black Box Testing:

In this strategy some test cases are generated as input conditions

that fully execute all functional requirements for the program. This
testing has been uses to find errors in the following categories:
a) Incorrect or missing functions

b) Interface errors
c) Errors in data structure or external database access
d) Performance errors
e) Initialization and termination errors.
In this testing only the output is checked for correctness. he logical

flow of the data is not checked.
3. White Box testing :
In this the test cases are generated on the logic of each module by
drawing flow graphs of that module and logical decisions are tested on all
the cases. It has been uses to generate the test cases in the following
cases:
• Guarantee that all independent paths have been executed.

• Execute all logical decisions on their true and false Sides.
• Execute all loops at their boundaries and within their operational
bounds
• Execute internal data structures to ensure their validity.
4. Integrating Testing :
Integration testing ensures that software and subsystems work

together a whole. It tests the interface of all the modules to make sure
that the modules behave properly when integrated together.
5. System Testing :
Involves in-house testing of the entire system before delivery to the

user. It's
aim is to satisfy the user the system meets all requirements of the
client's specifications.
6. Acceptance Testing :
It is a pre-delivery testing in which entire system is tested at

client's site on real world data to find errors.
Test Approach: Testing can be done in two

ways:
• Bottom up approach
• Top down approach
Bottom up Approach:
Testing can be performed starting from smallest and lowest level

modules and proceeding one at a time. For each module in bottom up testing a
short program executes the module and provides the needed data so that the
module is asked to perform the way it will when embedded with in the larger
system. When bottom level modules are tested attention turns to those on the
next level that use the lower level ones they are tested individually and then
linked with the previously examined lower level modules.
Top down approach:
This type of testing starts from upper level modules. Since the
detailed activities usually performed in the lower level routines are not provided
stubs are written. A stub is a module shell called by upper level module and
that when reached properly will return a message to the calling module
indicating that proper interaction occurred. No attempt is made to verify the
correctness of the lower level module.
Validation:
The system has been tested and implemented successfully and thus
ensured that all the requirements as listed in the software requirements
specification are completely fulfilled. In case of erroneous input corresponding
error messages are displayed.
TESTCASES:
S.no Test case Actual result Expected Status(s/f)
result
1 User name Invalid user Invalid user Success
wrong
2 Leaves Leaves Leaves Success
validation expired expired

3 Mapping Actual Actual Success
validations services services
4 Report Actual Actual Success
generation reports reports
DOCTOR FORM:
LABS FORM:
BLOOD BANK FORM:

ADMIN FORM
DIET FORM
MAINTENANCE
10. User Manual:
Login:
If you(end user) want to enter into the form , then if you are existing
user then you should enter through login form which checks for authorized
users . If you are new user then you have to register your details through
registration form with your own identification name and password , which gives
you a unique identification to you and firm.
Maintenance
Maintenance, the last phase in the software engineering process. As

more programs are developed, a distributing trend has emerged-the amount of
effort and resources expended on software maintenance is growing. In total
project development maintenance takes 65% of effort. In Software maintenance
there are 4 types. They are
1.Adaptive Maintenance
2.Coorective Maintenance
3.Perfective Maintenance
4.preventive Maintenance
Adaptive maintenance is applied when changes in the external environment

precipitate modifications to software.
Perfective maintenance incorporates enhancements that are requested
by user community. Corrective maintenance acts to correct errors that are
uncovered after the software is in use.
Preventive maintenance improves future maintainability and reliability
and provides a basis for future enhancement.
Tasks performed during the software engineering process define
maintainability and have an important impact n the success of any
maintenance approach. Reverse Engineering and Reengineering are the tools
and techniques used to maintain the project.
CONCLUSION
The conventional system requires manual labour and lot of time

for updating reports. Implementation of this project would ultimately improve
The efficiency in the allocation and use of Health Resources to the
Complete extent. E can thus better serve the neediest section of
the society.
FUTURE ENHANCEMENTS:
• The complete project is to be made Web-based.

• The Doctor can receive alert messages in his Mobile.
• All the services are provided in Online.
BIBLIOGRAPHY
S. PAPER/BOOK PUBLISHER Vol.

AUTHOR Year
No. NAME MAGAZINE No
Chunk HTML,
01 Musciano&Bill Definitive O’REILLY 3 1998
Kennedy Guide
UML,
02 Joseph Schmuller Electronic SAMS 3 2004
Book
Software
03 Ian Sommerville LANCASTER 7 1982
Engineering
Clark Morgan, WILEY
04 PHP 1 2004
Joyce Park
Roger Software MC-GRAW-HILL-
05 3 1992
S.Pressman Engineering INTERNATIONAL
WILEY
06 Allan Kent PHP 2 2004
PUBLISHING INC
WEBSITES:
www.w3schools.com
www.intelinfo.com
www.php.com
www.whatis.com

Hospdocument 1

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Hospdocument 1

Hochgeladen von

Copyright:

Verfügbare Formate

Hospital Management systems

Hospital Management systems

8.5 System Testing

The main motto of the computerization of Hospital

Labs module comprises of five sub departments. Lab

Thus, this computerization concept of the hospital will prove

The main aim of this program is to reduce the manual

Thus we are able to reach our goal of “SYNCHRONIZING

Registration of the patient is carried out at two different windows -

There are several departments present in this module such as

Doctors in every department maintain a common Prelisted. This

Record maintenance and advising lab technicians are also his

The Expenditure register consists of fields

The Census register consists of fields

Blood Urea | Serum Creatinine | Widal | VDRL | Urine

The Daily Expenditure Register consists of fields such as

Date | Received/Expenditure | Indent Book NO | Qty | Balance

The expenditure register consists of fields such as

To computerize all department offices to the fullest extent, the following

A system is maintained which informs about the available

Use case diagrams of doctor

Use case diagram of lab technician

Test Report generation

Use case diagram of dietician and blood bank operator

Use case diagram of admin

Use-Case ID Use-Case Name Priority1 Stability2 Verifiability3

Use-Case ID: 1.1 Use Case Name:

Preconditions: The Doctor should know his login id.

Frequency of Use: Whenever the patient enters into his cabin.

Alternative No other alternative exists for this use-case.

Use-Case ID: 1.2 Use Case Name:

Preconditions: The Doctor should know the patient's id.

Frequency of Use: Whenever the patient enters into his cabin.

Includes: PATIENTS DETAILS MANAGEMENT use-case.

Alternative No other alternative exists for this use-case.

Use-Case ID: 1.4 Use Case Name:

Preconditions: The Doctor should know the patient's id.

Frequency of Use: Whenever the Doctor wishes to do so.

Normal Course of He refers to other Doctor if necessary.

Includes: PATIENTS DETAILS MANAGEMENT use-case.

Alternative No other alternative exists for this use-case.

Use-Case ID: 1.3 Use Case Name:

Preconditions: The Doctor should know the patient's id.

Frequency of Use: Whenever the Doctor wishes to do so.

Normal Course of He checks the condition of the Inpatients frequently.

Includes: PATIENTS DETAILS MANAGEMENT use-case.

Alternative No other alternative exists for this use-case.

Use-Case ID: 1.5 Use Case Name:

Preconditions: The Doctor should know the patient's id.

Frequency of Use: Whenever the Doctor feels to do so.

Normal Course of The Doctor prescribes the type of tests to be performed.

Alternative No other alternative exists for this use-case.

Use-Case ID Use-Case Name Priority Stability Verifiability

1.1 Record maintenance

Use-Case ID: 1.1 Use Case Name:

Use-Case ID: 1.2 Use Case Name:

Use-Case ID: 1.3 Use Case Name:

Post conditions: The patient's record is updated

Use-Case ID Use-Case Name Priority4 Stability5 Verifiability6

1.1 Record Keeping in Diet

Use-Case ID: 1.3 Use Case Name:

Alternative Courses:No other alternative exists for this use-case.