Roll No.

: 65, 70, 71
Date of Submission :
Sem : V
Subject : ISDL Lab

“Hospital Management System”

Mini Project Report

Submitted in partial Requirement for the degree of

BACHELOR OF ENGINEERING
In
INFORMATION TECHNOLOGY

By

ms

“Hospital Management System”

Submitted in partial requirement for the degree of Bachelor of Engineering in Information
Technology by,

Examiners

1)
2)

(Head of the Department)

1
 ACKNOWLEDGEMENT

The satisfaction that accompanies that the successful completion of any task would be incomplete
without the mention of people whose ceaseless cooperation made it possible, whose constant guidance
and encouragement crown all efforts with success.
We are grateful to our project guide Prof .Bhushan Chaudhari. & Prof. N. S.Ujgare. for the guidance,
inspiration and constructive suggestions that helpful us in the preparation of this project.
We also thank our colleagues who have helped in successful completion of the project.

2
 ABSTRACT

Hospital Management System

Our project Hospital Management system includes registration of patients, storing their details into the
system, and also computerized billing in the pharmacy, and labs. Our software has the facility to give a
unique id for every patient and stores the details of every patient and the staff automatically. It includes a
search facility to know the current status of each room. User can search availability of a doctor and the
details of a patient using the id.
The Hospital Management System can be entered using a user name and password. It is accessible either
by an administrator or receptionist. Only they can add data into the database. The data can be retrieved
easily. The interface is very user-friendly. The data are well protected for personal use and makes the
data processing very fast.

Groups members

INDEX
3
 Sr.No Contents Page no.

1. Introduction
2. Scope & References

3. Requirements: (Software and Hardware)

4. Entity Relationship Diagram with EER features

5. Data Dictionary

6. Relational Database Design

7. Database Normalization & Data Flow Diagram

8. Graphical User Interface & Source Code

VB Forms and Data Reports

9. Testing document
Conclusion

10. References

1. Introduction

1.1) Purpose
• The Software is for the automation of Hospital Management.
• It maintains two levels of users:-
4
  Administrator Level
 User Level

The Software includes:-

• Maintaining Patient details.
• Providing Prescription, Precautions and Diet advice.
• Providing and maintaining all kinds of tests for a patient.
• Billing and Report generation.

1.2) Scope
• It can be used in any Hospital, Clinic, Dispensary or Pathology labs for maintaining patient
details and their test results.

1.3) Technologies to be used

• This project will be a desktop application to be developed in VB 6.0
• SQL as backend.

 Database Design (SQL)

• Form Design (VB 6.0)
• Coding (VB 6.0)
• Testing (VB 6.0)
• Reporting Tool (Data Report)

1.4) Overview
• Project is related to Hospital Management System.
• The project maintains two levels of users:-
 Administrator Level-Doctor
 User Level-Data Entry Operator
• Main facilities available in this project are:-
• Maintaining records of indoor/outdoor patients.
• Maintaining patients diagnosis details, advised tests to be done.
• Providing different test facilities to a doctor for diagnosis of patients.
• Maintaining patient’s injection entry records.
• Maintaining patient’s prescription, medicine and diet advice details.
• Providing billing details for indoor/outdoor patients.
• Maintaining backup of data as per user requirements (between mentioned dates).
• If user forgets his/her password then it can be retrieved by hint question.
• In this project collection of data is from different pathology labs.
• Results of tests, prescription, precautions and diet advice will be
5
 automatically updated in the database.
• Related test reports, patient details report, prescription and billing reports can be generated as per
user requirements.
• User or Administrator can search a patient’s record by his/her name or their
registration date.
• Patient’s diet advice can be provided in Hindi.

2. Overall Description

2.1) Goals of proposed system

1. Planned approach towards working: - The working in the organization will be well planned and
organized. The data will be stored properly in data stores, which will help in retrieval of information as
well as its storage.
2. Accuracy: - The level of accuracy in the proposed system will be higher. All operation would be done
correctly and it ensures that whatever information is coming from the center is accurate.
3. Reliability: - The reliability of the proposed system will be high due to the above stated reasons. The
reason for the increased reliability of the system is that now there would be proper storage of
information.
4. No Redundancy: - In the proposed system utmost care would be that no information is repeated
anywhere, in storage or otherwise. This would assure economic use of storage space and consistency in
the data stored.
5. Immediate retrieval of information: - The main objective of proposed system is to provide for a
quick and efficient retrieval of information. Any type of information would be available whenever the
user requires.
6. Immediate storage of information: - In manual system there are many problems to store the largest
amount of information.
7. Easy to Operate: - The system should be easy to operate and should be such that it can be developed
within a short period of time and fit in the limited budget of the user.

2.2) Background
A Hospital is a place where Patients come up for general diseases. Hospitals provide facilities like:-
• Consultation by Doctors on Diseases.
• Diagnosis for diseases.
• Provides medicines & advices regarding food.

3 ) Objectives of proposed system

The Hospital management system software is user-friendly software. The main objectives of the system
is which shows and helps you to collect most of the information about Hospitality and Medical Services
The system is very simple in design and to implement. The system requires very low
system resources and the system will work in almost all configurations.
The main objectives of the proposed system can be enumerated as follows:
6
 • Patients are easily allocated to the doctors.
• Doctors Search is possible.
• Today’s patient list help doctors to search their patients

3.1 ) Advantages of proposed system

The system is very simple in design and to implement. The system requires very low system resources
and the system will work in almost all configurations.
• Security of data.
• Ensure data accuracy’s.
• Administrator controls the entire system.
• Reduce the damages of the machines.
• Minimize manual data entry.
• Greater efficiency.
• User friendly and interactive.
• Minimum time required.

4 ) Software requirement specifications

• Software specifications
Operating System : Windows 2000/XP
Font end : Visual Basic 6.0
Back end : SQL
Design Tool : Data Flow Diagram
• Hardware specifications
Processor : X86 Compatible processor with 1.7 GHz Clock speed
RAM : 512 MB or more
Hard disk : 20 GB or more
Monitor : VGA/SVGA
Keyboard : 104 Keys
Mouse : 2 buttons/ 3 buttons

5. Entity Relationship Diagram

7
 ER Diagram For Hospital Management System

6 ) ER Features

8
Entity-Relationship (ER) schemata are a popular conceptual model introduced by Chen [Chen:1976],
and later extended in several ways; the more common extensions are usually termed Extended ER
(EER). ERW is a framework that, essentially, lets users modify instances of an EER schema. More in
detail, one defines an EER schema using ERL, an XML-based language. Then, a Java TM tool reifies
the schema into a set of SQL tables using a standard algorithm, and produces related documentation and
diagrams. Moreover, it produces a set of definition files used by a run-time environment written in PHP.
The run-time environment creates forms that let the user interact with the schema instance, with natural
operations such as “associate this entity to this entity”, and so on. In particular, the ontological data
contained in the schema is used to offer different interfaces for types with a different ontological status
(e.g., identification functions).
There are of course several tools that let you edit SQL databases using a browser. However, ERW does
not let you edit SQL databases: rather, it defines a very precise mathematical semantics (based on
bicategory theory) of EER schemata with a type system [Vigna:2002b], and it lets you edit an instance
of a schema, as defined by the semantics.1
The design of ERW started from a number of major requirements, which were not available in any
existing system we were aware of.
• Support for a wide range of EER features. A tool based on conceptual modelling is of no use
if a sufficient number of sophisticated features is not available. Relationship types with attributes,
weak entities with multiple owners, multiple inheritance, abstract (noninstantiable) entities
should be part of the basic modelling capabilities.
• Maintenance of referential and logical integrity of the database. All cardinality constraints
imposed at the EER level should be automatically enforced.
• Built-in authorization mechanisms. Content management systems are routinely access
concurrently by many users with different (possibly fine-grained) permission levels.
• Rich, intuitive user interface. The powerful features offered by the W3C DOM should make it
possible to build a rich and intuitive user interface.
• Internationalization. ERW should provide language-dependent forms based on content
negotiation, and full UTF-8 support.
• DBMS independent. A generic tool for content management should not be tied to any specific
database.
• Multimedia content. A content management system is likely to contain multimedia data; it
should provide a simple way to associate files to entities.
• Scalability. Both the size of the schema and the size of an schema instance should not be
limited. Whereas scalability w.r.t. the schema size is usually not a problem, several efforts in the
domain of web-based editing assume that the database will be small.
• Clean semantics. The notion of schema instance should be clearly defined by a mathematical
model, and the SQL database data should closely reflect the model.
• Open-source software based on open standards. ERW should be entirely based on
international standards and open-source tools.

9
 • Customisable, but not hardwired. The editing forms should be largely customisable, but in a
way that does not keep from continuing to extend and update the conceptual model. Vendor-
provided tools often fail to support customized user-interface requirements.

7 ) Data Dictionary

Data dictionary – what can be in it?

A simple data dictionary is an organized collection of data element names and definitions,
arranged in a table. It may describe all the data holdings of an organization, a part of the
holdings or a single database. More advanced data dictionaries can contain database schema with
reference keys and entity relationship diagrams3. The following sections, 3.1 through 3.5,
provide a description of the possible contents of data dictionaries.
Descriptions of Data Elements
• Data Element Domain: The context within which the data element exists. For example
information about a participant (the domain) could include data element information about the
address, phone number, title, and e-mail.
• Data Element Number: A unique number for the data element used in technical documents.
• Data Element Name: Commonly agreed, unique data element name.
• Data Element Field Name(s): Names used for this data element in computer programs and
database schemas.
• Data Element Definition: Description of the meaning of the data element.
• Data Element Unit of Measure: Scientific or other unit of measure that applies to the data value.
• Data Element Value: The reported value.
• Data Element Precision: The level to which the data element value will be reported (e.g. miles
to 2 decimal places).
• Data Element Data Type: Data type (characters, numeric, etc.), size and, if needed, any special
hat applies to the data element.
• Data Element Size: The maximum field length as measured in characters and the number of
decimal places that must be maintained in the database.
• Data Element Field Constraints: Data Element is a required field (Y/N); Conditional
field (c); or a null field: Required fields (Y) must be populated. Conditional fields (C) must
also be populated when another related field is populated (e.g. if a city name is required a Zip
Code may also be required). “Not null” also describes fields that must contain data. “Null”
means the data type is undefined (note: a null value is not the same as a blank or zero value).
• Data Element Default Value: A value that is predetermined -it may be fixed or a variable,
like current date and time of the day.
• Data Element Edit Mask: An example of the actual data layout required (e.g. yyyy/mm/dd)

 Data Element Business Rules (Could include any of the material below):
• Data Element coding (allowed values) and intra-element validation details or
10
 reference to other documents: Explanation of coding (code tables, etc.) and validation
rules.
• Related data elements: List of closely related data element names when the relationship
is important.
• Security classification of the data element: Organization-specific security classification
level or possible restrictions on use.
• Database table references: Reference to tables where the element is used and the role of
the element in each table. Indication when the data element is a primary or secondary key
for the table.
• Definitions and references needed to understand the meaning of the data element:
Short application domain definitions and references to other documents needed to
understand the meaning and use of the data element.

8 ) Data Normalization
• Definition

 Optimizing table structures

 Removing duplicate data entries
 Accomplished by thoroughly investigating the various data types and their relationships with
one another
• Follows a series of normalization “forms” or states
• Why Normalize?
• Improved speed
• More efficient use of space
• Increased data integrity (decreased chance that data can get messed up due
to maintenance)

 First Normal Form

 calls for the elimination of repeated groups of data by creating separate tables of related data
 Student information:
 Class information:
 Professor Information:

Student ID Student Name College Name College Location

Student ID Class ID Class Name

Professor ID Professor Name

11
  Second Normal Form
 Elimination of redundant data
● Example data in Class Information:
Use: To get Class Information:

StudentID ClassID Class Name

123-45-7894 P113 Physics 113

134-56-7890 M148 Math 148

534-98-9009 H151 History 151

134-56-7890 H151 History 151

ClassID Class Name

M148 Math 148

P113 Physics 113

H151 History 151

StudentID ClassID

134-56-7890 M148

123-45-7894 P113

534-98-9009 H151

134-56-7890 H151

 Third Normal Form

• eliminate all attributes(column headers) from a table that are not directly dependent upon the
primary key college and college Location attributes are less dependent upon the studentID than
they are on the major attribute
• New college table:

12
• Revised student table:

College Name college Location

Student ID Student Name

13
9 ) Data Flow Diagrams

Data Flow Diagram 1

14
Data Flow Diagram 2

15
10 ) Graphical User Interface

LOGIN FORM

16
Main Menu

17
Doctor Information Form

18
Patient Information Form

19
Staff Information Form

20
Discharge Form

21
Rooms Information Form

22
11 ) Source Code

LOG IN FORM

Private Sub Command2_Click()

End
End Sub

Private Sub LO_Click()

If Text1.Text = "aim" And Text2.Text = "aim" Then
Form3.Show
Me.Hide
Else
MsgBox "wrong username or password"
End If
End Sub

MAIN MENU

Private Sub Command1_Click()

Form1.Show
Me.Hide
End Sub

Private Sub Command2_Click()

Form2.Show
Me.Hide
End Sub

Private Sub Command3_Click()

Form4.Show
Me.Hide
End Sub

Private Sub Command4_Click()

Form5.Show
Me.Hide
End Sub

Private Sub Command5_Click()

Form6.Show
Me.Hide
End Sub

Private Sub Command7_Click()

End
23
End Sub

DOCTAR FORM CODING

Private Sub Command1_Click()

Form3.Show
Me.Hide
End Sub

Private Sub Command2_Click()

Adodc1.Recordset.AddNew
End Sub

Private Sub Command3_Click()

Adodc1.Recordset.Update
End Sub

Private Sub Command4_Click()

Adodc1.Recordset.Delete
End Sub

PATIENT FORM

Private Sub Command1_Click()

Form3.Show
Me.Hide
End Sub
Private Sub Command2_Click()
Adodc1.Recordset.AddNew
End Sub

Private Sub Command3_Click()

Adodc1.Recordset.Update
End Sub

Private Sub Command4_Click()

Adodc1.Recordset.Delete
End Sub

STAFF FORM CODING

Private Sub Command1_Click()

Form3.Show
Me.Hide
End Sub
24
Private Sub Command2_Click()
Adodc1.Recordset.AddNew
End Sub

Private Sub Command3_Click()

Adodc1.Recordset.Update
End Sub

Private Sub Command4_Click()

Adodc1.Recordset.Delete
End Sub

INFO FORM CODING

Private Sub Command1_Click()

Form3.Show
Me.Hide
End Sub

ROOMS FORM CODING

Private Sub Command1_Click()

Form3.Show
Me.Hide
End Sub
Private Sub Command2_Click()
Adodc1.Recordset.AddNew
End Sub

Private Sub Command3_Click()

Adodc1.Recordset.Update
End Sub

Private Sub Command4_Click()

Adodc1.Recordset.Delete
End Sub

25
12 ) Testing Document
A study of resource availability that may affect the ability to achieve an acceptable system. This
evaluation determines whether the technology needed for the proposed system is available or not.
• Can the work for the project be done with current equipment existing software technology &
available personal?
• Can the system be upgraded if developed?
• If new technology is needed then what can be developed?
This is concerned with specifying equipment and software that will successfully satisfy the user
requirement. The technical needs of the system may include:
Front-end and back-end selection
An important issue for the development of a project is the selection of suitable front-end and back-end.
When we decided to develop the project we went through an extensive study to determine the most
suitable platform that suits the needs of the organization as well as helps in development of the project.
The aspects of our study included the following factors.

Front-end selection:
 It must have a graphical user interface that assists employees that are not from IT background.
 Scalability and extensibility.
 Flexibility.
 Robustness.
 According to the organization requirement and the culture.
 Must provide excellent reporting features with good printing support.
 Platform independent.
 Easy to debug and maintain.
 Event driven programming facility.
Front end must support some popular back end like Ms Access.According to the above stated features
we selected VB6.0 as the front-end for developing our project.
Back-end Selection:
 Multiple user support.
 Efficient data handling.
 Provide inherent features for security.
 Efficient data retrieval and maintenance.
 Stored procedures.
 Popularity.
 Operating System compatible.
 Easy to install.
 Various drivers must be available.
 Easy to implant with the Front-end.
According to above stated features we selected Ms-Access as the backend. The technical feasibility is
frequently the most difficult area encountered at this stage. It is essential that the process of analysis and

26
definition be conducted in parallel with an assessment to technical feasibility. It centers on the existing
computer system (hardware, software etc.) and to what extent it can support the proposed system.
13 ) Conclusion
The project Hospital Management System (HMS) is for computerizing the working in a hospital. The
software takes care of all the requirements of an average hospital and is capable to provide easy and
effective storage of information related to patients that come up to the hospital.
It generates test reports; provide prescription details including various tests, diet advice, and medicines
prescribed to patient and doctor. It also provides injection details and billing facility on the basis of
patient’s status whether it is an indoor or outdoor patient.
The system also provides the facility of backup as per the requirement.

27
References ::
1) Black Book of Visual Basic 6.0
2) Black book of SQL
3) www.google.com
4) www.rediff.com

28