1.

Title of the Project

2. Introduction

HealthCare Hospital is a big hospital. It is run and governed by a board of directors

which comprises of senior doctors, influential persons of society and the members of
hospital trust. The hospital is only one of its kinds in its area and is always seen crowded
by patients.
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.

Page i
 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:

Page ii
 Patients

Indoor Patients Outdoor Patients

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.

Page iii
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,

Page iv
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.

Page v
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:
1. OPD Receipt,

2. Indoor patient Bill

3. Advances Receipt generation

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

Page vi
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:

Page vii
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

Page viii
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

Context Level DFD
Provide service

Hospital Staff
Se

Bill
ek

Patient
s
se
rv

n
ic

io
e

at
er
en
G
ll
Bi

Provide service
Doctor HealthCare Service accepted Patient
Information Systems
Provide service Roo
Nurse m Det
Employee Detail

ai l
il
eta
rD
Pa

c to
Room
yR

Do
o
ll D
eta
l i

Doctor Master Pay Roll

Employee

Page ix
1st Level DFD

OPD Master
Doctor Master

OPD card
Issue

Disease diagnose
Patient and treatment
adviced

Emergency
service

Indoor
Patient

Room Master
Doctor Master

Indoor Master

2nd level DFD for OPD

OPD Card
Generation

Doctor
Patient
OPD Master
Primilinary
Diagnosis
and Pathological
test advised

Final Diagnosis
made and Test Performed
treatment advised and Expenses
Calculated

Exp_Heads

OPD_Expenses

Indoor
Patient

Page x
2nd Level DFD for Indoor

Emergency
Indoor Master
Doctor Indoor
Patient Decision
Bed Detail

OPD Generation
of Admit card

Treatment
administered
Pathological and progress Exp_heads
test checked
performed
Day to day
treatment
and Expenses
Con_Sheet Detail calculated
Expenses

Vital_Chart Detail
Indoor Master
Discharge
Procedure
& Patient
Billing Bill

Page xi
0 Level Employee Information System

1 Level Employee Information System (For Deletion)

1 Level Employee Information System (Update)

Page xii
1 Level Grant System

0 Level Payroll Information System

Page xiii
1 Level Payroll Information System

Page xiv
2 Level Payroll Information System

Page xv
E-R Diagram

Page xvi
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

Page xvii
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 :

Page xviii
 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

Page xix
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

Page xx
 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

Page xxi
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

Page xxii
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

Page xxiii
 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

Page xxiv
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:
 Windowed Interface and compatibility with MS Windows NT/2000 Server.
 Inexpensive.
 Fast on small to medium systems.
 Internet Support.
 Easy to manage and use.
 Network-Enabled.
 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

Page xxv
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) Enterprise Edition: 64 MB minimum, 128 MB or more recommended

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

Page xxvi
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 hospitals are a common sight. There are at least 5-10 good
hospitals in every city which are rushed by patients. These hospitals are better
accustomed to treat patients and fight diseases, than to handle a voluminous amount of
patients’ data and a lot of papers.
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.

Page xxvii