HMS

Roll No. : 65, 70, 71 Date of Submission :

Sem : V Subject : ISDL Lab

“Hospital Management System”

Mini Project ReportSubmitted in partial Requirement for the degree of

BACHELOR OF ENGINEERINGIn

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)

1

(Head of the Department)

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

3

INDEX

1. Introduction

1.1) Purpose The Software is for the automation of Hospital Management. It maintains two levels of users:-

Administrator Level User Level

The Software includes:-

4

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

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

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.

5

2. Overall Description

2.1) Goals of proposed system1. 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) BackgroundA 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 systemThe 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 lowsystem resources and the system will work in almost all configurations.The main objectives of the proposed system can be enumerated as follows:

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

6

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.1The 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 specificdatabase.

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.

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.

9

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 theholdings or a single database. More advanced data dictionaries can contain database schema withreference 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) mustalso be populated when another related field is populated (e.g. if a city name is required a ZipCode 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

reference to other documents: Explanation of coding (code tables, etc.) and validationrules.

Related data elements: List of closely related data element names when the relationshipis important.

Security classification of the data element: Organization-specific security classificationlevel or possible restrictions on use.

10

Database table references: Reference to tables where the element is used and the role ofthe element in each table. Indication when the data element is a primary or secondary keyfor the table.

Definitions and references needed to understand the meaning of the data element:Short application domain definitions and references to other documents needed tounderstand 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

Second Normal Form Elimination of redundant data

● Example data in Class Information:Use: To get Class Information:

11

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: Revised student table:

College Name college Location

Student ID Student Name

12

9 ) Data Flow Diagrams

13

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()EndEnd Sub

Private Sub LO_Click()If Text1.Text = "aim" And Text2.Text = "aim" ThenForm3.ShowMe.HideElseMsgBox "wrong username or password"End IfEnd Sub

MAIN MENU

Private Sub Command1_Click()Form1.ShowMe.HideEnd Sub





Private Sub Command7_Click()End

23

End Sub

DOCTAR FORM CODING


Private Sub Command2_Click()Adodc1.Recordset.AddNewEnd Sub

Private Sub Command3_Click()Adodc1.Recordset.UpdateEnd Sub

Private Sub Command4_Click()Adodc1.Recordset.DeleteEnd Sub

PATIENT FORM

Private Sub Command1_Click()Form3.ShowMe.HideEnd SubPrivate Sub Command2_Click()Adodc1.Recordset.AddNewEnd Sub



STAFF FORM CODING


24

Private Sub Command2_Click()Adodc1.Recordset.AddNewEnd Sub



INFO FORM CODING


ROOMS FORM CODING

Private Sub Command1_Click()Form3.ShowMe.HideEnd SubPrivate Sub Command2_Click()Adodc1.Recordset.AddNewEnd Sub



25

12 ) Testing DocumentA 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 selectionAn 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 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.

26

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.02) Black book of SQL3) www.google.com 4) www.rediff.com

28

http://www.google.com/

Documents

HMS