Project Report

On

HealthCare System

…………………………………………………..

Submitted By

…………………RANJANA CHANDRA

0609010082

Submitted to:

B. TECH CS DEPARTMENTIEC COLLEGE OF ENGINEERING & TECHNOLOGY

C E R T I F I C A T E

This is certify that Ranjana Chandra has carried out the work embodies in this

project in entitled “HealthCare System” under my guidance and supervision

during the academic session 2008-2008 in fulfillment of the requirement for b.tech

Final Year from IEC-CET. The Work in this project is original and I am

completely satisfied with this work, and wish her all success in future life.

A C K N O W L E D G E M E N T

Many persons have contributed to make this software on HEALTHCARE SYSTEM a reality. I would especially like to express my appreciation to for his unstinted support, encouragement and his painstakingly and meticulous effort towards developing this software.

I acknowledge the help and cooperation received from all the faculty members of ducat Academy Noida. Several colleagues and students have contributed directly and indirectly to the contents this software, as they had given me numerous ideas. Their criticism gave me the much-needed hints about the areas that needed elaboration and amendments and also to present them with greater clarity.

I sincerely express my gratitude to Mr. Tushar Giri , the present hod of cs department,iec-cet for his support and help in the final preparation of this Report.

Finally, I wish to express my sincere thanks to all my family members, especially my Parents for their constant moral support and Encouragement.

I would Welcome Constructive Suggestions to improve this software, which can be implemented in my further attempts. Thanking you! Ranjana chandra roll No. 0609010082

C O N T E N T

S.NO TOPIC PAGE NO.1. Preface 52. Objective & Scope of the Project 73. Definition of Problem 104. System Analysis & Design

i) Input Requirements 12ii) Output Requirementsiii) Functional Requirements

5.System Maintenance & Evaluation

19

6. Life Cycle of the Project 22i) Entity-Relationship Diagramii) Data Flow Diagramiii) Structure Chart

7. Input & Output Screens 308. Process Involved 41

Data Dictionary 45Limitations 53Future Applications 55

9. References 58i) Bibliography

P R E F A C E

When A Computer Software succeeds-when it meets the needs of the people who use it, when it performs flawlessly over along period of time, when it is easy to modify and even easier to use-it can and does change things for the better. But when software fails-when its users are dissatisfied, when it is error prone, when it is difficult to change and even harder to use-bad things can and do happen.

We all want to build software that makes things better, avoiding the bad things that lurk in the shadow of failed efforts. To succeed we need discipline when software is designed and built. Many individuals and companies still develop software haphazardly, even as they build systems to service the most advanced technologies of the day. As a result, the quality of the software that we produce suffers and bad things happen. This project report is intended to serve as a guide to the software developed on HEALTHCARE SYSTEM . I have tried to follow the principles and rules as suggested by the software engineers as far as possible, in order to make this software a Successful one. The report starts with a comprehensive introduction to the project undertaken as its very First Section. It includes objectives and scope of the project; about the front-end tool used i.e. ASP.Net with C# and the back-end tool i.e. SQL Server. The second part presents and discusses the theoretical background of the project. The third section encompasses all the problems of the software that includes what is expected from the software, the demands and the requirements of the end-users. The fourth part is the System analysis and design section. This part focuses on

requirements analysis and specification, analysis issues, detailed procedures and the database designs. In The fifth section, different approaches to formal evaluation and review techniques are explored. The sixth section highlights the methodology adopted for this project. The seventh part suggests the steps required to implement the software on the user machine. The eighth part discusses the hardware and software requirements of the user machines. The ninth part deals with the cost benefit analysis. The tenth section contains the data flow diagrams. The next section is the flowchart part. The next section is for the entity relationship diagram of the project. The thirteenth part explains the methodology used for testing. The fourteenth section is the test report. The fifteenth part is the most important part of the project i.e. the code for the software. The sixteenth part is the user manual section. The seventeenth part is the annexure for the topic that includes some details about the organization, the data dictionary, definitions, acronyms and abbreviations used in the report. The final section is the reference part that contains a list of the books and reports that were referred during the development of the project and the report as well.

The emphasis in this report is to document the important concepts and techniques used for the successful development of this project.

I do hope fervently that, through this report, the readers will get a real picture of what the project is all about. I also wish that may this software satisfies all the needs and requirements of the organization, for which it is meant.

O B J E C T I V E S & S C O P EO F T H E P R O J E C T

The objective of this software is to completely automate the following process:

This software provides the health card for the patient. It will display a set of information related to a patient regarding blood, urine, others.

Provides information related to health and socio-economic data associated with location wise so that these inputs can further be used to decide about the effectiveness of the recommendations given to the patient.

Provides different kinds of reports and analysis for the scientists, planners, doctor so as to enable them for better decision making on different occasions.

Provides excellent and easy to access means of communication medium between doctors and its patients.

To maintain and store diseases information for past few months.

Provides as a comparison chart among different reports at different stages.

This system is providing different types of tests reports

Blood test Urine test Other tests

P R O B L E M D E F I N I T I O N

PROBLEM STATEMENT: A Health Care System is an online facility by which user/doctor can view the diagnose information of a person related to his/her health for better analyzed medicine and medical treatments.

This system helps in disease management and preventive services. It provides very vital information like patients without an exam for certain time, patient with certain levels BP, patients who are taking a certain class of medication, patients who are suffering from a certain type of disease, screening and immunization information, Lab tests Results, etc.

Rules can be created for various time frames like a certain time period, last visit to the hospital, latest Data available Visit, across all visits. The system is completely dynamic in the sense; each user can have his own rule and his own conditions and can decide if he wants to be alerted for the patient meeting the rule or for not .

NEED OF THE SOFTWARE: This software is developed keeping in mind the above-mentioned problems. The needs and requirements of the end users are also kept in mind while designing this software. This software will enable its users to maintain, retrieve and generate reports quickly and requiring minimum effort. Thus, HEALTHCARE SYSTEM is developed in order to facilitate it users to keep a track of case history regarding health status of Indian citizens. It also helps them to save their time and energy when they want to retrieve some kind of information for their specific purposes and needs.

S Y S T E M A N A L Y S I S

Requirements analysis is a software engineering task that bridges the gap between system level requirements engineering and software design. Requirements engineering activities result in the specification of software’s operational characteristics (function, data and behavior), indicate software’s interface with other system elements, and establish constraints that software must meet. The most commonly used requirements technique is to conduct a meeting or interview. The first meeting between a software engineer (the analyst) and the customer can be likened to the awkwardness of a first date between two adolescents. Neither person knows what to say or ask; both are worried that they do say will be misinterpreted; both are thinking about where it might lead (both likely have radically different expectations here); both want to get the thing over with, but at the same time, both want it to be a success.

Gause and Weinberg suggest that the analyst start by asking CONTEXT-FREE QUESTIONS. That is, a set of questions that will lead to a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired, and the effectiveness of the first encounter itself.

The goal of the requirements gathering activity is to collect all relevant information from the customer regarding the product to be developed with a view to clearly understanding the customer requirements and weeding out the incompleteness and inconsistencies in these requirements. The requirements analysis activity is begun by collecting all relevant data regarding the product to be developed from the users of the product and from the customer through interviews and discussions.

Data collection is done by taking the copies of the documents involved in its working from the organization.

Design Pattern:

This software based on concept of the Model View Controller (MVC) design pattern.

View renders the data from the Model in response to the request made to the model by controlled events made by user interaction.

Model View Controller is a design approach to separate the application object model from GUI, originally invented around 80s. Then later on it has become a widely accepted common design pattern. The main objective behind this pattern is to decouple the view of the data (presentation layer) from the actual data processing so that the same model can be used for various views. This is achieved by using three different types of objects that interact with each other in loosely coupled manner with their discreet set of tasks.

These three objects are known as Model, View and Controller.

VIEW:

View is the graphical data presentation (outputting) irrespective of the real data processing. View is the responsible for look and feel, some custom formatting, sorting etc. View is completely isolated from actual complex data operations. For example, Online product catalog view is completely separated from database connection, query, tables etc. It simply gets final row-data from the model and puts some cosmetics and formatting before displaying it in browser. View provides interface to interact with the system. The beauty of MVC approach is that it supports any kind of view, which is challenging in today’s distributed and multi-platform environment.

A MVC model can have multiple views, which are controlled by controller. View interface can be of WEB-FORMS, HTML, XML/XSLT, XTML, and WML or can be Windows forms etc.

MODEL:

Model is responsible for actual data processing, like database connection, querying database, implementing business rules etc. It feeds data to the view without worrying about the actual formatting and look and feel. Data provided by Model is display-neutral so it can be interfaced with as many views without code redundancy; this eases your code maintenance and reduces bugs and allows code -reuse at good extent. Model responds to the request made by controllers and notifies the registered views to update their display with new data.

CONTROLLER:

Controller is responsible for Notice of action. Controller responds to the mouse or keyboard input to command model and view to change. Controllers are associated with views. User interaction triggers the events to change the model, which in turn calls some methods of model to update its state to notify other registered views to refresh their display.

Benefits:

Following are the few of the benefits of MVC design pattern.

• Since MVC handles the multiple views using the same enterprise model it is easier to maintain, test and upgrade the multiple system.

• It will be easier to add new clients just by adding their views and controllers. • Since the Model is completely decoupled from view it allows lot of flexibilities to

design and implement the model considering reusability and modularity. This model also can be extended for further distributed application.

• It is possible to have development process in parallel for model, view and controller.

I N P U T R E Q U I R E M E N T S

For Medical Tests: - Blood Test details such as WBC, RBC, Platelates , Heomoglobin,

Glucose, Blood_Urea, Serium Creatinine, ESR, TLC, DLC, etc.

- Urine Test Details such as Color, Sendiments, Specific, Gravity,

Proteins, etc.

- General Blood Details such as Blood Group, HIV Status, RH-Type.

- Other Test Details such as X-Ray, ECG, CT-Scan, etc.

For viewing the HealthCard of an individual his/her voter idno will be required as an input.

A legal citizen of India can Login on this site by entering his/her name as the username and his/her voter idno as the password.

For uploading the advertisements, the required information is: Add Position(i.e. the page on which a/an company/organization wants to place its add) , Width and Height for the Adds are reserved in advance which cannot be changed by an individual. On entering the location page, the width and height will automatically gets reflected. Other details which are needed for uploading an advertisement are – Add Picture, Navigation Url, Alternate Text, and Impressions of an Add.

O U T P U T R E Q U I R E M E N T S

Person should have a Voter id .

There must be a net connection and browser to view the web pages of respective site.

F U N C T I O N A L R E Q U I R E M E N T S

Person should have a Voter id .There must be a net connection and browser to view the web pages of

respective site

S Y S T E M M A I N T E N A N C E

System maintenance denotes any changes made to a software product after it has been delivered to the customer. Maintenance is inevitable for almost any

kind of product. However, most products need maintenance due to the wear and tear caused by use. On the other hand, software products do not need maintenance on this count, but need maintenance to correct errors, enhance features, port to new platforms, etc.

Software maintenance is becoming an important activity of large number of organizations. This is no surprise, given the rate of hardware obsolescence, the immortality of a software product per se, and the demand of the user community to see the existing software products run on newer platforms, run in newer environments, and/or with enhanced features. When the hardware platform changes and a software product perform some low-level functions, maintenance is necessary. Also, whenever the support environment of a software changes, the software product requires re-work to cope with the newer interface. Thus, every software product continues to evolve after its development through maintenance efforts.

Maintenance covers a wide range of activities including correcting, coding and designing errors, updating documentation and test data and upgrading user support. Enhancement means adding, modifying or re-developing the code to support changes in the specifications. It is necessary to keep up with the changing user needs and the operational environment. The software is designed with the view of easy updating to the software. Future advancements can be done easily through the review of product. The software architecture is strong enough to provide enhancement in functionality, performance and reliability. Functions in the software are designed in such away that they dynamically update on addition of new and revised modules. To append new features in this software, the databases for student details, examination details are sufficient enough for the task. Thus the software is capable enough of being enhanced easily whenever requires by the user.

MAINTENANCE PROCESS MODEL

GATHER CHANGE REQUIREMENTS

ANALYZE CHANGE REQUIREMENTS

DEVISE CODE CHANGE STRATEGIES

APPLY CODE CHANGE STRATEGIES TO THE OLD ONE

UPDATE DOCUMENTS INTEGRATE AND TEST

E N T I T Y R E L A T I O N S H I P D I A G R A M

C O N T E X T D I A G R A M

The context diagram is the most abstract data flow representation of a system. It represents the entire system as a single bubble. This bubble is labeled according to the main function of the system. The various external entities with

which the system interacts and the data flows occurring between the system and the external entities are also represented.

F I R S T L E V E L D F D

To develop the level 1 DFD, examine the high-level functional requirements. If there are between three to seven high-level functional requirements, then these can be directly represented as bubbles in the level 1 DFD.

We can then examine the input data to these functions and the data output by these functions, and represent them approximately in the diagram.

LEVEL–1 DFD :

S T R U C T U R E C H A R T

MAIN MENU SUBMENU

ENTRY FORM

PERSON DETAILS FORM

BLOOD TEST DETAILS

URINE TEST DETAILS

OTHER TEST DETAILS

VIEW

PERSON TEST DETAILS

REPORTSPERSON BLOOD DETAILSPERSON URINE DETAILSSTATEWISE REPORTPERSON GROWTH CHART REPORTBLOOD GROUP REPORTHIV STATUS REPORTRHS STATUS REPORTPERSON BLOOD GRAPH REPORTPERSON URINE GRAPH REPORT

REGISTRATION

HOSPITAL REGISTRATION FORM

ADVERTISEMENT

ADD ADVERTISEMENT FORMDISPLAY ADVERTISEMENT

FORM

Home.Aspx

SiteMap.Aspx

Add_Details.Aspx

Admin_Page.Aspx

Blood_Entry.Aspx

General_Details_Entry.Aspx

Hospital_Details_Entry.Aspx

Person_Detail_Page.Aspx

Person_Entry.Aspx

Staff_Page.Aspx

LOGIN PROCESS :

START

NO

YES

SEARCHING TEST DETAILS PROCESS:

Enter Voter ID

START

Input Voter ID/Hospital ID

If ID

is correct

Option for page

Generate Output

STOP

NO

YES

HEALTHC ARD PROCESS:

If Voter ID

IsCorrect

STOP

Error Message

Display Coresponding Test Details

Input Voter ID

START

NO

YES

If ID

is correct

Generate HealthCard

STOP

D A T A B A S E D E S I G N

Database: health_info

Table1-User_Login_Details

Field name Data Type Size Constraintsuserid varchar 20 not nullpassword varchar 15 primary keyrole varchar 15 not null

Table2-Person_Details

Field name Data Type Size ConstraintsVoter_idno varchar 15 primary keyFname varchar 15 not nullmname varchar 15 allow nullLname varchar 15 not nullFather_name varchar 25 not nullMother_name varchar 25 not nullAddress1 varchar 30 not nullAddress2 varchar 30 allow nullCity varchar 20 not nullState varchar 25 not nullSex char 8 not nullDob datetime - not nullEmail_id varchar 50 allow nullContact_no varchar 15 allow nullImage varchar 50 not null

Table3-Person_Gen_Blood_Details

Field name Data Type Size ConstraintsVoter_idno varchar 15 primary keyBlood_group varchar 10 Not nullRh_type varchar 10 Not nullHiv_status varchar 10 not null

Table4-Urine_Std_Values

Field name Data Type Size ConstraintsColor varchar 15 not nullConsistancy varchar 15 not nullSendiments varchar 15 not nullSpf_gravity varchar 15 not nullAcidic varchar 15 not nullUrine_sugar varchar 15 not nullAlbumin varchar 15 not nullPhosphate varchar 15 not nullAcetone_bodies varchar 15 not nullBile_salt varchar 15 not nullBile_pigment varchar 15 not nullUrobilinogen varchar 15 not nullLuecocytes varchar 15 not nullErthyocytes varchar 15 not nullEpithelial_cells varchar 15 not nullCasts varchar 15 not nullketones varchar 15 not nullProteins varchar 15 not nullOthers varchar 15 not null

Table5-Urine_Person_Details

Field name Data Type Size ConstraintsVoter_idno varchar 15 Primary keyColor varchar 15 nullConsistancy float - nullSendiments float - nullSpf_gravity float - null

Acidic float - nullUrine_sugar float - nullAlbumin float - nullPhosphate float - nullAcetone_bodies float - nullBile_salt float - nullBile_pigment float - nullUrobilinogen float - nullLuecocytes float - nullErthyocytes float - nullEpithelial_cells float - nullCasts varchar 15 nullketones varchar 15 nullProteins varchar 15 nullOthers varchar 15 nullTest_date datetime - not nullClinic_name varchar 50 not nullClinic_address varchar 50 not null

Table6-Blood_Std_Values

Field name Data Type Size ConstraintsWBC varchar 15 not nullRBC varchar 15 not nullPlatelates varchar 15 not nullHemoglobin varchar 15 not nullGlucose varchar 15 not nullBlood_urea varchar 15 not nullSerium_creatinine varchar 15 not nullEsr varchar 15 not nullTlc varchar 15 not nullDlc varchar 15 not nullPolymorphs varchar 15 not nullLymphocyte varchar 15 not nullEsinophills varchar 15 not nullBasophills varchar 15 not nullMonocytes varchar 15 not null

Adnormal_cells varchar 15 not nullMalaria varchar 15 not nullParasite varchar 15 not nullOthers varchar 15 not null

Table7-Blood_Person_Test_Details

Field name Data Type Size ConstraintsVoter_idno varchar 15 Primary keyWbc float - allow nullRbc float - allow nullPlatelates float - allow nullHemoglobin float - allow nullGlucose float - allow nullBlood_urea float - allow nullSerium_creatinine float - allow nullEsr float - allow nullTlc float - allow nullDlc float - allow nullPolymorphs float - allow nullLymphocyte float - allow nullEsinophills float - allow nullBasophills float - allow nullMonocytes float - allow nullAdnormal_cells float - allow nullMalaria float - allow nullParasite float - allow nullOthers float - allow nullTest_date datetime - not nullClinic_name varchar 50 not nullClinic_address varchar 50 not null

Table8-Others_Test_Details

Field name Data Type Size ConstraintsVoter_idno varchar 15 Primary keyOther_type varchar 25 not nullDescription varchar 50 not nullTest_date vatetime - Not nullClinic_name varchar 50 not nullClinic_address varchar 50 not null

Table5-Hospital_Details

Field name Data Type Size ConstraintsHospital_id varchar 15 Primary keyHospital_name varchar 50 not nullHospital_address varchar 50 not nullCity varchar 25 not nullDistt varchar 25 not nullState varchar 25 not nullHead_of_incharge varchar 25 not null

Table9-Add_Details

Field name Data Type Size Constraintsid int - identityImageUrl varchar 50 not nullWidth int - not nullHeight int - not nullNavigateUrl varchar 50 not nullAlternateText varchar 50 not null

keyword varchar 50 not nullImpression varchar 50 not nulladditiondate datetime - not null

DEFINITIONS, ACRONYMS AND ABBREVIATIONS

The following definitions and abbreviations may be used in this document:

Analysis The requirements gathering process is intensified and focused specifically on software.

Coding The design must be translated into machine readable form. The code generation step performs this task.

Data store: A logical construct used to depict data that is being recorded during manual and automated processes. Data stores are organized by logical data groupings without regard to the

storage mediumDFD Data Flow Diagram-A diagram that shows the inputs and

outputs of a process and the data stores that store the data.

Design The software design actually a multi-step process that focuses on four distinct attributes of a program: the data structure, software architecture, interface representations and procedural details.

Input Data provided to a processOutput Data produced by a processPERT Project Evaluation and Review Technique.Process A series of steps taken to accomplish a specific action or

produce a specific result based on the input to those steps and the state of the system at the time of that input.

RAM Random Access MemorySIO System Input/Output SelectionSRS Software Requirements SpecificationsTesting It focuses on the logical internals of the software.Unit Testing The project is divided into small units and then the testing is

done on each unit separately.White-Box Testing

It is a test case design method that uses the control the structure of the procedural design to derive test cases.

L I M I T A T I O N

Provides no facility for Online Payment.

No Online Chat or voice chats to doctors.

The site only maintain records of people above 18 years of age,since in Login process an individual is required to enter his/her name and voter id.

F U T U R E A P P L I C A T I O N S

Providing the On-Line Chat facility to users to concern the doctor for immediate response.

Providing the community for specialize doctors for specific dieses, and share the information in the form of Blogs, Photos, Videos, discussions in various new researches in medical science.

Nurturing the dream of providing Email account facility to users so they can feel the independence of mail account at the same site.

In future it will provide information of doctors with their specialization in the local area of user/patient.

In future we would provide the facility for online payment and implement Secure Socket Layer (SSL).

D E P E N D E N C I E S

It doesn’t matter how efficiently the application works, if the bandwidth is not sufficient the transaction will take more time then expected.

.Net Framework for execution environment and Ado.Net Provides for database connectivity.

IIS server is required for the application.

Although this software is architecturally independent but following hardware resources are required. For i.e. any IBM compatible PC or any other workstation with mouse support and relevant software.

B I B L I O G R A P H Y

BOOKS:

ASP .Net By Peter Norton

Mastering ASP.Net TECHMEDIA

Learn ASP.Net in 21 days TMH

Black book ASP.Net.

LIBRARY:

MSDN

MSDN Library Visual Studio .Net release

The MSDN Library is the essential reference for developers, with more than a gigabyte of technical programming information; including sample code, documentation, technical articles, the Microsoft Developer Knowledge Base, and anything else we might need to develop solutions that implement Microsoft technology.

WEBSITE:

www.apollohospital.comwww.ducatindia.comwww.ministryofhealth.com