HEALTHCARE HOSPITAL MANAGEMENT SYSTEM PROJECT REPORT
Project Overview
The main purpose of this project entitled as “HealthCare Hospital Management Systems” is to computerize the Front Office Management of Hospital and helps to reduce manual labour of collecting and piling up data for later references, which is very often difficult to maintain, because of overwork or misplace of collected information. This system also figures out the human engineering considerations (ergonomics) which, in turn, has resulted in a user friendly, menu-driven Graphical User Interface.This system simplifies the upholding of large amount of data and the speed of processing is off the capacity of any manual system. It minimizes the time and efforts of the user with efficiency. It is possible at any point of time to extend the software to stand at ceremony. This project is developed in such a way that any implementation or extension can be done easily.
Download Code
Contents
I. Project Synopsis
1. Title of the Project………………………………………………… i
2. Introduction……………………………………………………….. i
3. Objectives of the Project…………………………………………. i
4. Project Category………………………………………………….. ii
5. Inputs to the Project……………………………………………… ii
6. Output of the Project……………………………………………… v
7. Process Logic……………………………………………………… vi
8. System DFDs……………………………………………………… ix
9. Data Structure.…………………………………………………… xvi
10. Tools/Environment……………………………………………… xxiv
11. H/W & S/W Requirements……………………………………… xxv
12. Future Scope of Application……………………………………… xxvi
II. Project Report
1. Title of the Project………………………………………………… 1
2. Introduction……………………………………………………….. 1
3. Objectives of the Project…………………………………………. 1
4. System Analysis…………………………………………………… 2
Preliminary Investigation------------------------------------------ 2
Requirement Analysis---------------------------------------------- 6
5. S/W Engineering Paradigm Applied……………………………. 13
6. H/W & S/W Requirements………………………………………. 14
7. System Design…………………………………………………….. 15
Table Definitions---------------------------------------------------- 15
E-R Diagram--------------------------------------------------------- 24
Form Design--------------------------------------------------------- 25
8. Coding……………………………………………………………… 36
9. Code Efficiency……………………………………………………. 209
10. Testing……………………………………………………………. 210
11. Security Mechanism……………………………………………… 215
12. Cost Estimation of the Project…………………………………. 216
13. Reports…………………………………………………………… 217
14. PERT CHART…………………………………………………. 221
15. Future Scope of Application…………………………………… 222
16. Further Enhancements………………………………………… 223
17. Bibliography……………………………………………………. 224
1. Title of the Project
HealthCare Hospital Management Systems
2. Introduction
The hospital maintains the records of its patients, doctors, nurses,
and the treatment given to the patients. It also keeps record of the
availability of rooms, beds, etc. The manual system which is currently working
there has already become overburden and a situation has arose which is
demanding an automatic and computerized data processing system. The board of
directors has decided to replace the manually operated office with its computerized
counterpart. Speedy and efficient information processing is crucial to the
hospital and its patients because it is the lifeline of a patient. Computers
can help in sorting out the intolerable burden of ever increasing amount of
information with which public services (hospitals) are expected to contend. The
HealthCare Information System is designed to shoot out the problem of
overcrowding of voluminous amount of paper work, delay in getting results and
the preparation of bills and receipts. This project (HealthCare Information
System) is an effort in simplifying and organizing the various tasks in the
hospital.
3. Objectives of the Project
The HealthCare Information
Systems is designed to achieve the following objectives:
i. It should take less than 30 seconds to establish whether a patient
is already on file and should take less than one minute to trace any past
treatment.
ii.
The main menu should be
displayed automatically when the database is loaded, and the whole system
should be menu driven.
iii. Proper receipt and bill generation facilities should be incorporated
in the software.
iv. The software must have a user-friendly interface and appealing
appearance to ease the work of the end users.
v. The software must be able to show the actual status of the beds and
wards, i.e., it must be able to say how many rooms there are in a ward and how
many of them are presently not booked.
vi. The new system must be
designed to allow the Hospital to record the details of its doctor’s and
nurse’s timings, full name, address, phone no., etc.
vii. The system should be able to generate daily reports of patients,
beds available expenditure heads, etc. so that they could be used by the
management authorities of the hospital for making decisions and deciding
guidelines.
viii. It should have the function to maintain records of advances made
time to time and expenses incurred by the patient on each day including test
charges.
ix. Above all, the software system should be able to eliminate all the
paper work required in implementing the task of data maintenance.
4. Project Category
This project can be put into the category of Relational Database
Management System (RDBMS).
5. Inputs to the Project
The main input to the project is the records of those patients who
visit hospital for treatment. The patients are broadly divided into two
categories:
The record details of these two kinds of patients also differ. For
that reason, two separate modules are defined to take the input. These modules
are:-
a). Outdoor Patient Module
b). Indoor Patient Module:
a). Outdoor Patient
Module:-
Outdoor patients come into the hospital for a very short period and
generally suffer minor problems. Therefore, only general information about
these patients is stored. As soon as a new patient comes, it is added up into
the outdoor patient module. This module facilitates a user to search old
patients, along with deletion and/or updating of records.
b). Indoor Patient Module: -
An indoor patient is admitted into the hospital. So, not only the personal
information of such patients is recorded, but also some extra information is
stored on them. The extra information includes information like doctor(s)
looking after the patient, diagnosis, ward and bed allotted, date and time of
admission, advance money deposited (if any). Once again an indoor patient is
classified into a general patient or a patient coming through the panel. If a
patient is of later category then in that case some extra information is stored
(including name of organization thereof he has come, staff number, book number,
reference number and the Doctor who has referred him. Finally, the expense
incurred by the hospital is calculated and the balance is calculated by
differentiating it from the advance paid by the patient.
Doctor Module: - This module keeps the records of the Doctors /Physicians of the
Hospital. A doctor record contains doctor’s residence address, phone number,
specialization etc.
Nurse Module: - Like the doctor module, nurse module stores the records of the
nurses working in the hospital, which consist of similar types of fields as
that of doctors, with minor differences.
Bed detail Module: - A bed exists in a room and a room is found in a ward. Thus, this
module keeps the bed information and in turn also stores room and ward details.
It also shows the status of a bed (vacant or occupied).
Expenses detail Module: - Many types of expenses are made on a patient by the hospital.
Expenses can be sub-classed. The expenses detail module holds the information
of all these expenses along with their sub classes.
Daily Vital Module: - A patient is checked for its blood pressure, body temperature, etc.
time to time. A daily vital chart of each patient is prepared which maintains
this information. A daily vital chart is prepared by the Doctor/nurse with a
mention of time. The main objective of this module is to keep this information
so that the health condition of a patient can be monitored on a regular basis.
Continuation Sheet Module:
- In this module, records of date and time of each
drug given to a patient are maintained.
Daily Advances Module: - This module records the daily advances paid by the patient to
hospital so that the balance between the total expenses and total advances can
be computed.
Outdoor Patient Billing
Module: - It deals with the billing of Outdoor
Patient... Here OPD expenses are
recorded and a receipt is generated on the basis of expenses incurred on an
Outdoor patient.
Indoor Billing Module: - When an indoor patient is discharged from the hospital a bill is
generated in which the total amount to be paid (if any) by the patient is
mentioned. This amount is actually the difference of the advances made by the
patient and the expenses incurred on it by the hospital. All billing is done
automatically.
Employee Module:
- This module is
where employees’ information is kept and maintained. This module is concerned
with Employee’s addition, deletion, updating, leave application
acceptance/rejection etc. Employee type, grade, designation, currently assigned
duty, and all other personal information of the employee including Date of
Joining the Hospital is maintained by this module. The leave and absence
information of this module is fed as input to the Payroll Generation Module.
Payroll
Generation Module: -This module is responsible for
generating the salary of all the employees of the hospital. There are many
kinds of Employees working in the hospital. It is the responsibility of this
module to calculate their salary as per their grade and designation. This
module keeps track of employee’s absence/leave information which comes useful
while calculating the salary of the employees.
6. Output of the Project
The outputs of the HealthCare Information Systems are in the form of
reports which are generated on the basis of the inputs given to them. Reports
are the major part of software therefore the given software produces various
types of reports according to the need of the user. Hospital needs the report
of both Outdoor and Indoor Patients. Some of the important reports are
mentioned below:-
OPD Register: - The OPD register reflects date wise report of the indoor patients.
It states that which tests are performed on a day. For each test a receipt is
generated. There is a provision of separate reports for General and Panel
patients.
Daily Report: - This report outputs the records of all those patients who are
treated by same doctor on a particular day. This report also contains the
receipt information and tests performed.
Patient Admission
Register- In this report, the records of all those
patients are shown who have been admitted on a particular day. If the patient
comes through panel all the related information is shown, else for a general
patient, patient’s general information is shown in the report.
Daily Advance Register- This report presents the picture of advances made by the Indoor
Patients on a particular date. It shows the receipt number, case number, name
and advance amount .It also shows the total cash collected on that particular
date.
Patient Attendance List- This report represents the status of each patient on a particular
date. It shows the admission date, date of discharge (if discharged), received
amount and refunded or adjusted amount on the patient with the balance
calculated. Debit (Dr.) and Credit (Cr.) amount is shown on the basis of
balance. It also shows the grand total and net balance on that date. Beside all
these report some general reports having some selected data are also generated.
Patient’s vital report- This report is very significant as it gives insight of the current
status of a patient’s condition. It is the monitor of patient’s physical
condition.
Beds available- A very vital report output by the HealthCare Information Systems
which gives the information of available rooms/beds in the hospital wards.
Treatment Report- In this report it is showed that which drugs have been given to a
patient and when.
Besides these reports, the system also outputs the following bills
and receipts:
- OPD Receipt,
- Indoor patient Bill
- Advances Receipt generation
- Daily Refunds
Employee Register: - This report outputs the information of all the employees in the hospital.
This report can be classified as per need and may be used to generate Employees
list according to their grade, type or designation.
7. Process Logic
Employee Module Details:
It receives update, delete, and add requests from the
valid user and performs the same action on the Employee. It also registers
employees under categories and subcategories. It also process leave
applications of the employee and all the valid applications are accepted while
the infeasible requests are denied. It also tracks Employees’ regularity by
recording their absence. For all those a day (except holidays) for which
employee is not marked absent, he is considered present. This method reduces the
need to record the daily attendance and hence reduce memory requirements of the
system.
OUTDOOR PATIENT DETAILS:
The OPD form automatically generates the new patient
number and the current date as soon as a new patient is added. After keying in
all the relevant information about the patient, such as nature of the patient
(General or Panel), organization name, staff no, Book no. etc. (if the patient
comes from Panel) and name, address, sex, age, doctor attending, save the
patient record. The record of an outdoor patient can be deleted or edited in
future, if required.
INDOOR PATIENT DETAILS:
Like the OPD form, the indoor form used to record the
inputs of an indoor patient’s record automatically generates the indoor
patient’s case no. Again, information similar to that of an outdoor patient is
keyed in. But this time additional information like bed allotted to the patient
is also put into the database. Any expense made on the patient at the time of
admission is also filled from choosing it from the expenses module. All
calculation of rate of discount, net amount on that expense is automatically
outputted by the system.
An indoor patient record can also be deleted, modified
or altered at a future date if it is required.
Payroll Generation Module:
Payroll statement is based upon employees Grade, Status,
Designation etc. The user can define as many provisions for salary which may
either be added to the salary (D.A., HRA, CCA, etc) or are deducted from the
Gross salary (Tax, Provident Fund, etc.). The basic pay of each employee is a
function of its designation and grade (category and subcategory). There may be
miscellaneous provisions viz. Fine, Bonus, Overtime, PM relief fund etc. which
may be added/subtracted from the salary.
DOCTOR DETAILS:
A doctor’s record consisting of fields like Doctor Id, name,
address, phone no., email address specialization, consultant fee and Timing are
inputted into this module. If a doctor leaves the hospital his record can be
deleted or if a new doctor joins in his records are added. An alteration is
also possible in case of a change in information such as doctor’s timing and/or
his consultation fees.
NURSE DETAILS:
A nurse record is made of fields
like name, address, phone no. and duty timing. A nurse detail can be added,
deleted or modified in the database.
BED DETAIL:
A bed can exist in a room and a
room is a smaller unit of a ward. In the bed detail module, a bed details is
stored. A bed detail obviously contains information like room no, ward no,
floor no, etc.
A bed detail can’t be deleted;
however, its non-availability can be shown by marking the concerned field with
negation.
EXPENSES DETAIL:
In this module, details of an expense are stored. An
expense is identified by its unique code and description. An expense head can
be sub-divided into smaller heads of expenses called expense sub-heads.
DAILY VITAL DETAILS:
A daily vital report is associated with a patient, so a
patient case no is first of all inputted. After that, the id of the doctor who
has examined the patient is entered and then the findings of the examination
are inputted. The time is also mandatory to be entered.
CONTINUATION SHEET
DETAILS:
In this module the
information of drug given to a patient is stored along with the time. The
Patient case no., which uniquely identifies a patient is the required input
with which nurse id who has given the drug is also a compulsory field.
Obviously, the drug name, time and the date also need to be supplied.
In this module addition of
new records is allowed. Records are also allowed to be deleted but editing is
not at all allowed for maintaining the integrity of the continuation sheet.
DAILY ADVANCES DETAILS:
Whenever an advance is made
by a patient, a receipt against that advance is generated. The advance made is
credited to the case no of the patient. The receipt no is generated
automatically.
OUTDOOR PATIENT BILLING
DETAILS:
The OPD BILLING form, as
suggested from the name, generates the billing information. On selecting a
patient’s case number, nature and referred doctor name are inserted
automatically. On selecting the expense and its related subheads for which the
payment is going to be made the rates are listed automatically. On entering the
rate of discount (if any) on each expense the net amount is automatically
displayed. New receipts can be generated; old receipts can be deleted and/or
updated if conditions arise.
INDOOR BILLING DETAILS:
The BILL CUM RECEIPT form is
used to generate billing details. Whenever a new record is added bill no is
generated automatically. Current date and time are also filled by the system.
On selecting the Patient case number whose bill is to be generated all related
information is displayed. Bills thus generated can be viewed, deleted, or
edited in future.
8. System DFDs
DFD FOR HealthCare
Information Systems
0 Level Employee Information System
1
Level Employee Information System (For Deletion)
1
Level Employee Information System (Update)
1
Level Grant System
0
Level Payroll Information System
1
Level Payroll Information System
2
Level Payroll Information System
E-R
Diagram
9. Data Structure
Table Definition:
Table
Name : OPD_Master
Primary
Key : Case_no
Foreign Key :
Field Name
|
Null?
|
Type
|
Description
|
Book_no
|
Not Null
|
Number(6)
|
Book number
|
Case_no
|
Not Null
|
Varchar2(14)
|
Patient Identification number
|
Date1
|
Not Null
|
SmallDate
|
Current Date
|
Doc_name
|
Not Null
|
Varchar(25)
|
Outdoor Doctor name
|
Fees
|
-
|
Number(3)
|
Fees of outdoor card
|
Nature
|
Not Null
|
Varchar2(5)
|
Mode via which patient has arrived
|
Org_name
|
Not Null
|
Varchar2(25)
|
Referred Organisation name
|
Pat_add
|
Not Null
|
Varchar2(50)
|
Patient Address
|
Pat_age
|
Not Null
|
Number(3)
|
Patient Age
|
Pat_name
|
Not Null
|
Varchar2(25)
|
Patient Name
|
Pat_sex
|
Not Null
|
Varchar(6)
|
Patient Sex
|
Phone_no
|
-
|
Number(12)
|
Patient Phone no.
|
Procedure
|
-
|
Varchar(25)
|
|
Ref_doctor
|
Not Null
|
Varchar2(25)
|
Doctor referred
|
Ref_no
|
Not Null
|
Number(6)
|
Reference number
|
Staff_no
|
-
|
Number(6)
|
Staff no. of referred Organisation
|
Table Definition:
Table
Name : Doctor_Master
Primary
Key : Docid
Foreign
Key :
Field Name
|
Null?
|
Type
|
Description
|
Docfees
|
-
|
Number(6)
|
Doctor consultant
fees
|
Dochomeadd
|
Not_Null
|
Varchar2(50)
|
Doctor home address
|
Dochomephone
|
-
|
Number(12)
|
Doctor home phone number
|
Docid
|
Not_Null
|
Varchar2(5)
|
Doctor identification number
|
Docname
|
Not_Null
|
Varchar2(25)
|
Doctor name
|
Docspec
|
Not_Null
|
Varchar2(25)
|
Doctor specialisation
|
Doctime
|
Not_Null
|
varchar2(10)
|
Timing of Doctor in Hospital
|
Doctoroffadd
|
Not_Null
|
Varchar2(50)
|
Doctor office address
|
Doctoroffphone
|
-
|
Number(12)
|
Doctor office phone number
|
Email
|
-
|
Varchar2(40)
|
Email address of Doctor
|
Table Definition:
Table
Name : Ward_Type
Primary
Key : Ward_id
Foreign
Key :
Field Name
|
Null?
|
Type
|
Description
|
Ward_id
|
Not
Null
|
Varchar2(2)
|
Ward identification number
|
Ward_type
|
Not Null
|
Varchar2(25)
|
Type of Ward
|
Table Definition:
Table
Name : Indoor_Master
Primary
Key : Case_no
Foreign
Key :
Field Name
|
Null?
|
Type
|
Description
|
Ad_dep
|
-
|
Number(5)
|
Advance deposid money
|
Bed_desc
|
Not Null
|
Varchar(6)
|
Ward , and room description
|
Book_no
|
Not Null
|
Number(6)
|
Book number
|
Case_no
|
Not Null
|
Varchar2(14)
|
Patient Identification number
|
Clinical_pre
|
-
|
Varchar2(70)
|
Details of treatment given
|
Date
|
Not Null
|
SmallDate
|
Current date
|
Date_ad
|
Not Null
|
SmallDate
|
Date of admission
|
Date_dis
|
-
|
varchar2(10)
|
Date of discharge
|
Diagnosis
|
-
|
Varchar2(25)
|
Disease detected
|
Doc_id
|
Not Null
|
Varchar2(5)
|
Name of Doctor attending
|
Dr_referred
|
Not Null
|
Varchar(25)
|
Doctor referred
|
Nature
|
Not Null
|
Varchar2(6)
|
Mode via which patient arrived
|
Org_name
|
Not Null
|
Varchar2(25)
|
Referred Organisation name
|
Pat_add
|
Not Null
|
Varchar2(50)
|
Patient Address
|
Pat_age
|
Not Null
|
Number(3)
|
Patient Age
|
Pat_name
|
Not Null
|
Varchar2(25)
|
Patient Name
|
Pat_sex
|
Not Null
|
Varchar(6)
|
Patient Sex
|
Ref_no
|
Not Null
|
Number(6)
|
Reference number
|
Staff_no
|
-
|
Number(6)
|
Staff no. of referred Organisation
|
Tel_no
|
-
|
Number(12)
|
Book number
|
Time_ad
|
Not Null
|
Varchar2(8)
|
Time of admission
|
time_dis
|
-
|
Varchar2(8)
|
Time of discharge
|
Table Definition:
Table
Name : Nurse_Master
Primary
Key : Case_no
Foreign
Key :
Field Name
|
Null?
|
Type
|
Description
|
Add
|
Not Null
|
Varchar2(50)
|
Nurse Address
|
Duty_time
|
Not Null
|
Varchar2(12)_
|
Duty timing of nurse in Hospital
|
Name
|
Not Null
|
Varchar2(25)
|
Nurse name
|
Nurse_id
|
Not Null
|
Varchar2(5)
|
Identification of Nurse
|
Phno
|
-
|
Number(12)
|
Nurse phone number
|
Table Definition:
Table
Name : Room_detail
Primary
Key :
Foreign
Key : Ward_id
Composite
Ket : Ward_id +Room_number
Ward_id
|
Not Null
|
Varchar2(2)
|
Ward identification number
|
Room_descrip
|
Not Null
|
Varchar2(4)
|
Wardno and room number
|
Room_number
|
Not Null
|
Varchar2(2)
|
Room Number
|
Floor
|
Not Null
|
Varchar2(2)
|
Floor on which room is located
|
Multiple_bed
|
Not Null
|
Varchar2(3)
|
Whether room has multiple bed or not
|
Table Definition:
Table
Name : Bed_detail
Primary
Key :
Foreign
Key : Ward_id
Composite
Key : Room_Number + Bed_no
Field Name
|
Null?
|
Type
|
Description
|
Ward_id
|
Not Null
|
Varchar2(2)
|
Ward identification number
|
Bed_descrip
|
Not Null
|
Varchar2(6)
|
Ward,room.bed number
|
Bed_no
|
Not Null
|
Varchar2(2)
|
Bed number
|
Room_number
|
Not Null
|
Varchar2(2)
|
Room Number
|
Staus
|
Not Null
|
Varchar2(1)
|
Whether bed is booked or not
|
Table Definition:
Table
Name : Exp_Heads
Primary
Key : Code
Foreign
Key :
Field Name
|
Null?
|
Type
|
Description
|
Code
|
Not Null
|
Varchar2(3)
|
Expenses identificaton number
|
Descrip
|
-
|
Varchar2(30)
|
Type of Expenses
|
Table Definition:
Table
Name : Exp_subheads
Primary
Key : Sub_code
Foreign
Key : Code
Field Name
|
Null?
|
Type
|
Description
|
Code
|
Not Null
|
Varchar2(3)
|
Expenses identificaton number
|
Sub_code
|
Not Null
|
Varhar2(4)
|
Exp. Subhead identification no.
|
Descrip
|
Not Null
|
Varchar2(40)
|
Type of expenses subheads
|
Rate
|
Not Null
|
Number(3,2)
|
Rate of expenses subheads
|
Table Definition:
Table
Name : Bed_record
Primary
Key :
Foreign
Key : P_case_no
Field Name
|
Null?
|
Type
|
Description
|
Bed_descrip
|
Not Null
|
Varchar2(6)
|
Ward,Room and bed no alloted
|
P_case_no
|
Not Null
|
Varchar2(14)
|
Identification no. of Patient
|
From
|
Not Null
|
SmallDate
|
Date of alloting bed
|
To
|
Not Null
|
SmallDate
|
Date of leaving bed on discharge
|
Table Definition:
Table
Name : Con_Sheet
Primary
Key :
Foreign
Key : Nurse_id, P_case
Field Name
|
Null?
|
Type
|
Description
|
P_case
|
Not Null
|
Varchar2(14)
|
Patient Identification number
|
Nurse_id
|
Not Null
|
Varchar2(5)
|
Nurse identification number
|
Date
|
Not Null
|
SmallDate
|
Date of drug given
|
Time
|
Not Null
|
varchar2(10)
|
Time of drug given
|
Drug_used
|
Not Null
|
Varchar2(30)
|
Names
of drugs given
|
Table Definition:
Table
Name : Vital_Chart
Primary
Key :
Foreign
Key : D_id, P_case
Field Name
|
Null?
|
Type
|
Description
|
Date
|
Not Null
|
SmallDate
|
Date of Test performed
|
Time
|
Not Null
|
SmallDate
|
Time of Test performed
|
P_case
|
Not Null
|
Varchar2(14)
|
Patient Identification number
|
D_id
|
Not Null
|
Varchar(5)
|
Doctor idenfication number
|
B_P
|
Not Null
|
Varchar2(15)
|
Blood pressure
|
P_R
|
Not Null
|
Varchar2(15)
|
P_R
test
|
Chest
|
Not Null
|
Varchar2(15)
|
Hospital test
|
R_R
|
Not Null
|
Varchar2(15)
|
Hospital test
|
I/O
|
Not Null
|
Varchar2(15)
|
Hospital test
|
Remark
|
Not Null
|
Varchar2(50)
|
Remark given by Doctor
|
Table Definition:
Table
Name : Daily_transaction
Primary
Key : Receipt_no
Foreign
Key : Case_no, Dr_id
Field Name
|
Null?
|
Type
|
Description
|
Date
|
Not_Null
|
SmallDate
|
Current date
|
Case_no
|
Not Null
|
Varchar2(14)
|
Patient Identification number
|
Dr_id
|
Not Null
|
Varchar2(5)
|
Doctor idenfication number
|
Amount
|
Not Null
|
Number(6,2)
|
Amount deposited by patient
|
Receipt_no
|
Not Null
|
varchar2(10)
|
Receipt number of receipt
|
Table Definition:
Table
Name : OPD_Expense
Primary
Key : Receipt_no
Foreign
Key :
Field Name
|
Null?
|
Type
|
Description
|
Date
|
Not Null
|
SmallDate
|
Current date
|
Nature
|
Not Null
|
Varchar2(5)
|
Mode via which patient has arrived
|
Receipt_no
|
Not Null
|
varchar2(10)
|
Receipt number of receipt
|
Descrip
|
Not Null
|
Varchar2(40)
|
Description of expenses
|
Rate
|
Not Null
|
Number(3,2)
|
Rate of Expenses
|
Discount
|
Not Null
|
Number(3,2)
|
Discount on expenses
|
Unit
|
Not Null
|
Number(5)
|
Unit of expenses made
|
Value
|
Not Null
|
Number(6,2)
|
Amount of expenses
|
Table Definition:
Table
Name : Expenses
Primary
Key :
Foreign
Key : Case_No
Field Name
|
Null?
|
Type
|
Description
|
Case_no
|
Not Null
|
Varchar2(14)
|
Patient Identification number
|
Descrip
|
Not Null
|
Varchar2(40)
|
Description of expenses
|
Rate
|
Not Null
|
Number(3,2)
|
Rate of Expenses
|
Discount
|
Not Null
|
Number(3,2)
|
Discount on expenses
|
Unit
|
Not Null
|
Number(5)
|
Unit of expenses made
|
Value
|
Not Null
|
Number(6,2)
|
Amount of expenses
|
Date
|
Not Null
|
SmallDate
|
Date of Expenses made
|
Table Definition:
Table
Name : OPD_Billing
Primary
Key : Receipt_no
Foreign
Key : Case_no
Field Name
|
Null?
|
Type
|
Description
|
Receipt_no
|
Not Null
|
varchar2(10)
|
Receipt number of receipt
|
Case_no
|
Not Null
|
Varchar2(14)
|
Patient Identification number
|
Date
|
Not Null
|
SmallDate
|
Date of billing
|
Nature
|
Not Null
|
Varchar2(5)
|
Mode via which patient has arrived
|
Pat_name
|
Not Null
|
Varchar(25)
|
Patient Name
|
Doc_name
|
Not Null
|
Varchar(25)
|
Doctor consultant name
|
Dis
|
Not Null
|
Number(5,2)
|
Discount on expenses
|
Total
|
Not Null
|
Number(7,2)
|
Total Expenses
|
Table Definition:
Table
Name : Bill_Detail
Primary
Key :
Foreign
Key : D_id, P_case
Field Name
|
Null?
|
Type
|
Description
|
Bill_no
|
Not Null
|
Number(8)
|
Bill number of receipt
|
Bill_date
|
Not Null
|
SmallDate
|
Date of billing
|
Case_no
|
Not Null
|
Varchar2(14)
|
Patient Identification number
|
Time
|
Not Null
|
varchar2(10)
|
Time of billing
|
10. Tools/Environment
Back-End
Commercial Applications require that business data is stored using
any system that can both store and locate the data quickly on demand. The
project is concerned with the collection, display and storage of information.
The system to be developed is intended to enhance the current system of
database management; therefore, a relational database management system (RDBMS)
is chosen which is specifically designed to manage business data at very high
speed and great efficiency as well. “MS SQL SERVER 2000 Enterprise Edition” is
one such data base management system and is the back-end of the project (Life
Line Information System). An RDBMS system like the “MS SQL SERVER 2000
Enterprise Edition” follows the relational model and is highly efficient. By
using this, one can save disk storage, reduce the data redundancy, and perform
efficient data retrieval queries. Despite, a few facts that helped in
successfully selecting the “MS SQL SERVER 2000 Enterprise Edition” as the
back–end are as follows:
v Windowed Interface and compatibility with MS Windows NT/2000 Server.
v Inexpensive.
v Fast on small to medium systems.
v Internet Support.
v Easy to manage and use.
v Network-Enabled.
v Availability at the consumer’s end.
Front-End
In this project “MS Visual Basic 6.0” is used as a tool to design
the front-end. As clearly indicated in the objective of this system, the
front-end needs to be very interactive, user friendly and should preferably
have a Graphical User Interface (GUI) application. MS Visual Basic 6.0 is the
fastest and the easiest way to create an application with above said
attributes. MS Visual Basic 6.0 is bundled with a complete set of modern tools
to simplify application development and is extremely powerful with its state of
the art technology at one hand and easy to use programming environment, which
enables to develop windows applications, at the other. This environment
includes everything needed to successfully create, modify, test and compile the
proposed project. Besides, the new data access technology features a simpler
object model, better integration with MS SQL SERVER 2000 Enterprise Edition, a
user-accessible data binding interface, enhanced data binding, and hierarchical
record sets.
11. H/W & S/W Requirements
The H/W requirements of the proposed system are as
follows:
Hardware
|
Minimum requirements
|
Computer
|
Intel® or compatible Pentium
166 MHz or higher.
|
Memory (RAM)
|
Standard Edition: 64 MB
minimum
Personal Edition: 64 MB
minimum on Windows 2000, 32 MB minimum on all other operating systems
Developer Edition: 64 MB
minimum
Desktop Engine: 64 MB
minimum on Windows 2000, 32 MB minimum on all other operating systems
|
Hard
disk space
|
SQL
Server database components: 95 to 270 MB, 250 MB typical
Analysis Services: 50 MB
minimum, 130 MB typical
English Query: 80 MB
Desktop Engine only: 44 MB
|
Monitor
|
VGA or higher resolution.
800x600 or higher resolution required for the SQL Server graphical tools
|
Pointing
device
|
Microsoft
Mouse or compatible
|
CD-ROM
drive
|
Required
|
S/W Requirements
The proposed system supports a large number
of operating systems coming from Microsoft family. This s/w is tested to run on
the following operating systems:
Microsoft Windows NT Server 4.0, Windows 2000 Server,
Microsoft Windows NT Server Enterprise Edition, Windows 2000 Advanced Server,
and Windows 2000 Data Centre Server.
12. Future
Scope of application
In a country like India
A big hospital, like one dealt in this
project, faces a large number of problems involving data maintenance, storage
and mining. The manual system of data processing and record keeping is error
prone, labour intensive and thus costly. It requires a lot of paper handling
which further requires proper storage facilities. Moreover, this modus operandi
adversely affects the smooth functioning of the organization. The HealthCare
Information system helps in a great deal, to reduce manual labour of collecting
and piling up data for later references, which is very often difficult to
maintain, because of overwork or misplace of collected information. This system
also figures out the human engineering considerations (ergonomics) which, in turn,
has resulted in a user friendly, menu-driven Graphical User Interface. This
system simplifies the upholding of large amount of data and the speed of
processing is off the capacity of any manual system. It minimizes the time and
efforts of the user with efficiency. It is possible at any point of time to
extend the software to stand at ceremony. This project is developed in such a
way that any implementation or extension can be done easily.
With so many outstanding features, it is
expected that the proposed system (HealthCare Information System) would find
its use in hospitals.
Helpful.
ReplyDelete