PROJECT REPORT

ON
INTEGRATED DISEASE SURVEILLANCE PROJECT

Undertaken at

NATIONAL INFORMATICS CENTRE

DEPARTMENT OF INFORMATION TECHNOLOGY

NEW DELHI

UNDER THE GUIDENCE OF

INTERNAL GUIDE EXTERNAL GUIDE

Mr. SUBHRAJYOTI BORDOLOI J.R.D KAILAY

Lecturer (Sr. Technical Director)
Deptt. Of Computer Application TRAINING DIVISION
Assam Engineering College National Informatics Centre
Guwahati New Delhi

SUBMITTED BY

JAYANTA BAISHYA
6th SEMESTER
ROLL NO. 05/21
MASTER OF COMPUTER APPLICATION
ASSAM ENGINEERING COLLEGE
ASSAM
GAUHATI UNIVERSIT
 GOVERNMENT OF INDIA
MINISTRY OF COMMUNICATIONS & INFORMATION TECHNOLOGY
DEPARTMENT OF INFORMATION TECHNOLOGY

National Informatics
Centre
This is to certify that Mr. Jayanta Baishya ID.N0 10039 a student of
Master of Computer Application from Assam Engineering College
(Gauhati University) has done his full-semester project training at
Training Division , NIC, New Delhi, from 2nd July to 14th November. The
project work entitled “Integrated Disease Surveillance Project”
embodies the original work done by Mr. Jayanta Baishya during his above
full semester project training period.

Project Guide/HOD Head, Training Division

 Declaration

I, Jayanta Baishya, hereby declare that the project entitled

“Integrated Disease Surveillance Project” which is being submitted in
partial fulfillment of the requirements for the awards of degree of Master
of computer application from the Assam Engineering College, Guwahati
is an own record carried out by me under the supervision of J.R.D Kailay,
Project Head and Sr. Technical Director of National Informatics Centre.
The matter embodied in this project has not been submitted so far for
the award of any degree or diploma.

Jayanta Baishya
Assam Engineering College
Gauhati University
 ASSAM ENGINEERING COLLEGE
DEPERTMENT OF COMPUTER APPLICATIONS
GUWAHATI 781013

CERTIFICATE

This is to certify that the project work entitled “ Integrated Disease Surveillance
Project: Implementation of Form S” for NIC, Delhi is a excellent work carried out by Mr.
Jayanta Baishya, a student of Assam Engineering College, Guwahati.

This project work has been prepared as a fulfillment of the requirement for the
degree of MCA to be awarded by Gauhati University. This work has not been presented
earlier for any other academic activity.

I wish him all success in life.

Mr. Jyotiprakash Goswami

Assistant Professor In-charge,
Department of Computer Application,
Assam Engineering College,
Guwahati-781013.
 ASSAM ENGINEERING COLLEGE
DEPERTMENT OF COMPUTER APPLICATIONS
GUWAHATI 781013

CERTIFICATE

This is to certify that the project work entitled “ Integrated Disease Surveillance
Project: Implementation of Form S” for NIC, Delhi is a excellent work carried out by Mr.
Jayanta Baishya, a student of Assam Engineering College, Guwahati. He has done this
project under my supervision and guidance to the best of my knowledge.

This project work has been prepared as a fulfillment of the requirement for the
degree of MCA to be awarded by Gauhati University. This work has not been presented
earlier for any other academic activity.

I wish him all success in life.

Mr. Subhrajyoti Bordoloi

Lecturer,
Department of Computer Application,
Assam Engineering College,
Guwahati-781013.
 Acknowledgements

The ability to help and patience to exercise diligence and provide support is a quality
admonished by very few .No job in this world, however trivial or tough cannot be
accomplished without the assistance of the others. I would hereby take the opportunity to
express my indebtedness to people who have helped me to accomplish this task. The
present line of accomplishment is not a formality but an honest word of appreciation that
has exactly been felt by during my Training.

First and foremost I would like to thanks J.R.D Kailay (HOD/GUIDE) Sr. Technical
Director, Training Division Group NIC,Delhi for providing unwavering support and the
opportunity to work in this organization and also to Mr. Sanjay Kumar, Scientist of NIC for
his great advice and support throughout this project.

I am immensely thankful to my internal supervisor Mr S. Bordoloi, Lecturer of CA

Department, Assam Engineering College, for his incessant and perpetual cooperation and
encouragement, and Mr J P Goswami, Assistant Professor, Assam Engineering College, for
his constant guidance and inspiration throughout MCA.

I am also wish to express my sincere gratitude and thanks to Maushumi Barooah

madam for providing unwavering support throughout my MCA life.

I also take this opportunity to express my indebtedness to all my respected teachers and
worker of Assam Engineering College for their kind consent, expert guidance, valuable
suggestions and affectionate encouragement.

Jayanta Baishya
MCA,6th Semester
Assam Engineering College
 ABSTRACT OF THE PROJECT

Project Title: Integrated Disease Surveillance Project (IDSP)

Abstract: IDSP developing task is carries by training division at NIC under the Health
ministry. As we know India is currently passing through epidemiological transition. Many
states in India have good health delivery systems while other states are lagging far behind.
Health problems of some states are predominantly due to communicable diseases while in
others it is due to Non communicable diseases. Any system that intends to the futuristic
will need to take this variability into account and cater to the differential needs of the
country and will need to be decentralized and state specific. The program will take into
account the wide geo-political and socio-economic differences in the country and tailor its
implementation to levels suitable for the given region of the country. In the first phase of
IDSP, in those states with advanced health delivery the implementation will be to improve
the functions further while in those states with poor health delivery the program will
establish a basic and essential module of surveillance Equity in health delivery is one of the
emphases for the government. Through an effective disease surveillance program health of
vulnerable populations in underdeveloped regions in India will be better understood and
corrective steps will be taken to improve their conditions.
As a project by WHO, India Health Ministry implementing this surveillance
project in various level. I am doing my project which is mainly based on FORM S, which is
the SYNDROMIC SURVILLANCE. In this project I am going to develop a system in
which a registered user can submit all the syndromic surveillance details for a particular
reporting unit. The user is a district level user and details are collected from various
reporting unit. Reports are submitted to central server each week. After all the syndromic
data are properly submitted to the central server my next task is to generate various reports
which are again based on FORM S.
As a front end I will use three tier architecture to develop the system. I will use
Jsp/Servlet and PostgreSQL as back end.

Tools and Technologies used:

JDK 1.5
MyEcllipse 6.0
PostgreSQL 8.2
Tomcat 6.0
Windows XP

NIC Division Allotted: Training Division (Health Ministry of India)

Module Name: Implementation of Form S (Syndromic Surveillance).

 CONTENTS

Chapter 1: Organizational Profile

1.1 About National Informatics Centre

Chapter 2: System Study

2.1 Problem Definition
2.2 Existing System
2.3 Proposed System
2.3.1 Purpose
2.3.2 Scope
2.3.3 Objective

Chapter 3: Project Description

Chapter 4: Feasibility Study

4.1 Introduction
4.2 Economic Feasibility
4.3 Technical Feasibility
4.4 Behavioral Feasibility

Chapter 5: Requirement Specification

5.1 Introduction
5.2 Requirement Specification
5.3 System Specification

Chapter 6: System Analysis

6.1 Introduction
6.2 Tools used for system analysis
6.3 Data Flow Diagram
6.4 Data Dictionary

Chapter 7: System Environment

7.1 Client-Server Paradigm

7.2 Technology Used
7.3 Tomcat 6.0
7.4 PostgreSQL 8.2
Chapter 8: System Design

8.1 Introduction
8.2 Structured Design
8.3 Database Design

Chapter 9: Testing and Implementation

9.1 Overview
9.2 Introduction
9.3 Types of System Testing
9.4 System Implementation

Chapter 10: System Security

Chapter 11: Future Enhancement

Chapter 12: Conclusion

Chapter 13: Project Snap Shots

Appendix A: Bibliography
ABOUT THE ORGANIZATION
1.1 About NIC:

National Informatics Centre (NIC) of the Department of Information Technology is

providing network backbone and e-Governance support to Central Government, State
Governments, UT Administrations, Districts and other Government bodies. It offers a wide
range of ICT services including Nationwide Communication Network for decentralized
planning, improvement in Government services and wider transparency of national and
local Governments. NIC assists in implementing Information Technology Projects, in close
collaboration with Central and State Governments, in the areas of (a) Centrally sponsored
schemes and Central sector schemes, (b) State sector and State sponsored projects, and (c)
District Administration sponsored projects. NIC endeavors to ensure that the latest
technology in all areas of IT is available to its users. NIC Headquarters is based in New
Delhi. At NIC Headquarters, a large number of Application Divisions exist which provide
total Informatics Support to the Ministries and Departments of the Central Government.
NIC computer cells are located in almost all the Ministry Bhawans of the Central
Government and Apex Offices including the Prime Minister’s Office, the Rashtrapati
Bhawan and the Parliament House. Apart from this, NIC has various Resource Divisions at
the Headquarters, which specialize into different areas of IT and facilitate the Application
Divisions as well as other NIC Centres in providing state-of-the-art services to the Govt. At
the State level, NICs State/UTs Units provide informatics support to their respective State
Government and at the District level lie the NIC District Informatics Offices.
NIC has conceptualised, developed and implemented a very large number of projects for
various Central and State Government Ministries, Departments and Organisations. Many of
these projects are continuing projects being carried out by various divisions of NIC at New
Delhi Headquarters and State/District centres throughout the country. Some of the most
important note worthy projects, which offer a glimpse of the multifaceted, diverse activities
of NIC, touching upon all spheres of e-governance and thereby influencing the lives of
millions of citizens of India are given below:

 Agricultural Marketing Information Network (AGMARKNET)

 Central Passport System
 Community Information Centres (CICs)
 Computerized Rural Information Systems Project (CRISP)
 Court Information System (COURTIS)
 Department of Agriculture Network (DACNET)
 Examination Results Portal
 India Image
 Land Records Information System (LRIS)
 National Hazardous Waste Information System (NHWIS)
 Public Grievance Redress and Monitoring System (PGRAMS)
 Spatial Data Infrastructure (SDI)
 Training
 Video Conferencing
SYSTEM STUDY
2.1 PROBLEM DEFINITION:

To make a system in which a registered user can submit the Syndrominc

Surveillance details of a week for a particular reporting unit. The user will be district level
user and only he/she can submit the details to central server. Additionally the user can also
update the details that he already submitted and also he/she can delete an entry. The next
problem is to generate various types of reports which are also base on FORM S. The
various reports mainly contains “Form Submission Report” i.e. this reports shows which
reporting unit submitted the Syndromic data in time or late.
Then the other reports are like, weekly Form S report, Comparison Report, Progressive
report. There will also be a graphical format of report for various types of report.
The next main problem I have to implement in this project is to sending the data that
submitted in a local server to the central server. For there will be a process by which a
district level user can create a text file which contains the data of FORM S in a local server,
then this user will upload the file to the central server machine and there the data of the
FORM S from the text file is restored into the database.

2.2 EXISTING SYSTEM:

As India is a big country it is very difficult to monitor the health status of the people
in different region. There is no any direct source by which the central health ministry
becomes aware about the condition in any part of the country in time. The existing system
is indirect one. i.e. the state government has to give the details about the condition to the
central ministry. But on the other hand for a big state, it is also become quite difficult to
collect the data form different parts of the state such they can give the details to the central
government in time.
2.3 PROPOSED SYSTEM

2.3.1 Purpose:

The proposed system aims at making the above system automated and online. This
online system gives the central ministry a direct source by which it can able to get the all
health status in different region in the country at any time. As mentioned earlier there is no
any direct source by which the central government can get the details about the health
condition in different parts of the country. Again as mentioned by world health
organization (WHO) the number of people infected or died by the communicable disease is
become very large in India. So there should be quick steps to prevent this. Now with the
proposed system the government can get the details about the people that are affected by
the communicable disease and take necessary steps in time.

2.3.2 Scope:

The system will provide the user interfaces such that the record keeping and
retrieval of the relevant information becomes matter of just few clicks without any hassle.
The proposed system will give a direct way by which government can get full
details about the affect of communicable disease in the country. So it gives an excellent
support to prevent the communicable disease.
In the proposed system each reporting unit has to submit the report to main server in
every week, so government will get the current status at any time.
In the proposed system there will be a facility by which it gives an alert to the
government about highly affection by communicable disease in a particular region.

2.3.3 Objective:

The underlying objective of the system is to be able to give the health support to the
people of that region who are affected by the communicable disease.
The primary aim of development of current phase of the program is to introduce a
uniform and systematic approach towards monitoring of the affect of communicable
disease in the country and to help the government to give a health support and moral
support to the people of the country.
 The program was initiated with a goal of help reduce the burden of morbidity and
mortality due to various communicable diseases in the country by:

Establishing a sustainable decentralized system of disease surveillance

for timely and effective public health action.

Integrating disease surveillance activities. To avoid duplication and facilitate

sharing of information across all disease control programs so that valid data are available
for appropriate health decision.

Under this program a weekly web-based reporting system has been established in all
districts.

***************************************
PROJECT DESCRIPTION
3.1 PROJECT DESCRIPTION

The system to be developed will be referred as Integrated Disease

Surveillance Project (IDSP). Integrated Disease Surveillance Program is intended to be
the back bone of public health programs in the country. IDSP will provide essential data to
monitor progress of on going disease control program and help in allocation of resources
and will be crucial in obtaining political and public support for the health programs. It will
help to identify areas of health priority where more inputs are necessary.
The Integrated Disease Surveillance Project (IDSP) covering all states in
India seeks to assist the central and state governments to shift from a centrally driven,
vertically organized disease surveillance system to one which is coordinated by the center
and implemented by the states, districts and communities.
India is currently passing through epidemiological transition. Many states in
India have good health delivery systems while other states are lagging far behind. Health
problems of some states are predominantly due to communicable diseases while in others it
is due to Non communicable diseases. Any system that intends to the futuristic will need to
take this variability into account and cater to the differential needs of the country and will
need to be decentralized and state specific. The program will take into account the wide
geo-political and socio-economic differences in the country and tailor its implementation to
levels suitable for the given region of the country. In the first phase of IDSP, in those states
with advanced health delivery the implementation will be to improve the functions further
while in those states with poor health delivery the program will establish a basic and
essential module of surveillance Equity in health delivery is one of the emphasis for the
government. Through an effective disease surveillance program health of vulnerable
populations in underdeveloped regions and tribal populations in India will be better
understood and corrective steps will be taken to improve their conditions.
Surveillance is particularly important for the early detection of outbreaks of
diseases. In the absence of surveillance, disease may spread unrecognized by the
responsible health care or public health agency, because sick people would be seen in small
numbers by many individual health care workers. By the time the outbreak is recognized,
the best opportunity to take intervention measures might have been over. Surveillance is
essential for the early for the early detection of emerging (new) or re-emerging
(resurgent) infectious diseases. In the absence of surveillance, individual health care
workers may not recognize the new disease. The continuous monitoring is essential for the
‘early signals’ of any outbreak of any endemic, new or resurgent disease and the action
loop to take effective public health action should be short and effective if disease
surveillance were to prevent emerging epidemics.
Surveillance data can be effectively used for the purpose of social
mobilization and make public participate more effectively in control of important diseases.
This is an important step in reducing the burden of disease in the community.
In recent years, Indian people facing a lot of trouble due to the
communicable diseases and non communicable diseases . So Indian government tries to
take necessary actions for prevention of those diseases in the specific affected area in time
with the help of the data comes from different regions in India. Integrated Disease
Surveillance Project (IDSP) is a decentralized, state based surveillance program in the
country. It is intended to detect early warning signals of impending outbreaks and help
initiate an effective response in a timely manner. It is also expected to provide essential
data to monitor progress of on-going disease control programs and help allocate health
resources more efficiently.

The IDSP proposes a comprehensive strategy for improving disease surveillance and
response through an integrated approach. This approach provides for a rational use of
resources for disease control and prevention.
In the integrated disease surveillance system:

 The district level is the focus for integrating surveillance functions.

 All surveillance activities are coordinated and streamlined. Rather than
using scarce resources to maintain vertical activities, resources are combined
to collect information from a single focal point at each level.
 Several activities are combined into one integral activity to take advantage
of similar surveillance functions, skills, resources and target populations.
 The IDSP integrates both public and private sector by involving the private
practitioners, private hospitals, private labs, NGOs, etc and also emphasis on
community participation.
 The IDSP integrates communicable and non-communicable diseases.
Common to both of them are their purpose in describing the health problem,
monitoring trends, estimating the health burden and evaluating programs for
prevention and control.
 Integration of both rural and urban health systems as rapid urbanization has
resulted in the health services not keeping pace with the growing needs of
the urban populace.
  The gaps in receiving health information from the urban areas needs to be
bridged urgently.
 Integration with the medical colleges (both private and public) would also
qualitatively improve the disease surveillance especially through better
coverage.

The overall general objective of the IDSP is to provide a rational basis for decision-making
and implementing public health interventions that are efficacious in responding to priority
diseases. Keeping this in mind the main objectives of the IDSP are:

 To establish a decentralized district-based system of surveillance for

communicable and non-communicable diseases so that timely and effective
public health actions can be initiated in response to health challenges in the
urban and rural areas
 To integrate existing surveillance activities (to the extent possible without
having a negative impact on their activities) so as to avoid duplication and
facilitate sharing of information across all disease control programs and
other stake holders, so that valid data are available for decision making at
district, state and national levels.

Types of Surveillance in IDSP:

Depending on the level of expertise and specificity, disease surveillance in IDSP will be of
following three categories:

i. Syndromic – Diagnosis made on the basis of symptoms/clinical pattern by

paramedical personnel and members of the community.
ii. Presumptive – Diagnosis made on typical history and clinical examination by
Medical Officers.
iii. Confirmed – Clinical diagnosis confirmed by an appropriate laboratory test.

The cases that have been detected and recorded need to be compiled and transmitted
to the next level on a regular basis. This should be done every Monday from each type of
reporting unit. Reports from sub- centers, PHC/CHC, Medical Colleges, SPPs, Private
Hospitals etc
should be sent to the district surveillance unit of each district on Monday of every week.
All reporting centers will provide zero reporting if no cases were detected.

There are five steps in the surveillance procedure, which must be carried out at each level,
starting from the Primary Health Centre (PHC). Each level must have the capacity for
analyzing and using surveillance data for early detection, prevention and control of
outbreaks. The five recommended steps are:
 Collection of data
 Compilation of data
 Analysis and interpretation
 Follow up action
 Feedback

My work in this project is based on the first type of surveillance in IDSP. i.e . on
Syndromic Surveillance . I have to maintain the syndromic surveillance details in form s .
So in this project my overall task is to maintain the Form S.
The main function to perform in this project are like ..

1. Implementation of Form S.
In this project the user in the district level will submit the Form S fields weekly.
The user is also able to edit and delete an entry.

2. To generate various reports that based on Form S.

2. Create a backup file of Form S entry in database, upload that file to central server
And then restore that backup file in the database of central server.
FEASIBILITY STUDY
4. FEASIBILTY STUDY

4.1 Introduction to System Design Development Life Cycle

System development, a process consisting of two major steps of System Analysis and
Design, starts when Management or sometimes system development personnel realize that
a particular business system needs improvement.

The System Development Life Cycle (SDLC) method is thought of as the set of
activities that analysts, designers and users carry out to develop and implement an
information system The Systems Development Life Cycle method consist of the following
activities: -
1. Preliminary investigation, which comprises of Feasibility Study.
2. Determination of system requirements.
3. System Design.
4. System testing.
5. Implementation.

4.2 Feasibility Study

Preliminary investigation examine project feasibility; the likelihood the system will
be useful to the organization .The main objective of the feasibility study is to test the
technical, Operational and Economical feasibility of the development computerized
system .All system are feasible if they are unlimited resources and infinite time. There are
three aspects in the feasibility study portion of the preliminary investigation:

1. Technical Feasibility.
2. Operational Feasibility.
3. Economical feasibility.
4.2.1 Technical Feasibility

It involves determining whether or not a system can actually be constructed to solve the
problem at hand. The technical issues raised during the feasibility stage of the investigation
were:
1. N.I.C. has well equipped Labs where all the H/W and S/W tools are available that
are needed to run the application. So it doesn’t require extra investment to run the
proposed application.

2. The proposed application will provide all the necessary information to all the users,
inside and outside the organization, and across the world also if loaded on web.

3. Expandability will be maintained in the new system. New modules can be added
later on the application, if required in the future.

4. The application will have User-friendly Forms and Screens, all validation checks.
So the new system guarantees accuracy, reliability, ease of access and data security

4.2.2 Operational Feasibility

Proposed projects are of course beneficial only if can be turned into information
systems that will meet the organization’s operating requirements. Operational feasibility
aspects of the project are to be to be taken as an important part of the project
implementation. Following questions helped us to test the operational feasibility of system:

I. Is there sufficient support for the project for management? From user?

II. Will the system be used and work properly if it is being developed and
implemented?

III. Will there be any resistance from the users that will undetermined the possible
Application benefits?
 The system is targeted to be in accordance with the above-mentioned issues.
Beforehand , the management issues and user requirements has been taken into
consideration. So there is no question of resistance from the users that can undetermined
the possible application benefits. The well-planned design would ensure the optimal
utilization of the computer resources and would help in the improvement of performance
status.

4.2.3 Economical Feasibility

A system that can be developed technically and that will be used if installed must
still be a good investment for the organization. In the economical feasibility, the
development cost in creating the system is evaluated against the ultimate benefit derived
from the new systems. Financial benefits must equal or exceed the cost.

The system is economically feasible. Since the interface for Integrated Diseases and
Surveillances Program is very new and resources such as tools and technology are freely
available.

****************************************
 REQUIREMENT
SPECIFICATION
5. REQUIREMENT SPECIFICATION

5.1 Introduction:

Requirement Specification is the most important phase of the SDLC. During this
phase our Project Manager is in constant contact with the Customer to find out
requirements of the project in detail (A rough estimation is made during the first phase of
SDLC, i.e. before the feasibility study). Main tasks in this phase include Requirement
Determination, Risk Analysis, Setting up Schedules, and deciding Deliverables.
Communication with the Customer is carried out using any of the following means of
communication, such as Instant Messenger, Email, Phone, Voice Chat or personal meeting.
A System Requirement Specification Document is prepared at the end of this phase.

5.2 Functional Requirements:

R1: Title: IDSP Form module.

Description: User will log into the system and after successful login it can go to the
IDSP Form S process. User will enter the name of the BLOCK and its corresponding
reporting unit name for whom Form S will be going to submit by the user also user
will enter the reporting week (the week no for reporting) then user can go to any of the
following three module. i.e. it contain three sub module.

R1.1: Title: Form S submission module.

Description: In this process user will submit all necessary details that necessary
in the Form S and submit it to the server.
Input: Name of the health worker, name of supervisor and user will submit all
details about the seek people (number of people affected and died by a
particular diseases give in the Form S) under the given reporting unit.
Output: After successfully submitting the Form S, the system will give a
feedback to the user as he/she successfully submitted or not.

R1.2: Title: Form S edit module.

Description: In this process user will edit all necessary details that already
submitted in the Form S.
Input: Updated details about the seek people (number of people affected and
died by a particular diseases give in the Form S) under the given reporting
 unit.
Output: After updating the Form S, the system will give a feedback to the
user as he/she successfully updated or not.

R1.3: Title: Form S delete module.

Description: In this process user will delete all necessary details that already
submitted in the Form S.
Input: Name of the block, reporting unit and reporting week no.
Output: After updating the Form S, the system will give a feedback to the
user as he/she successfully deleted or not.

R2: Title: Form S report generation module.

Description: This module will give the all-necessary report that needed by user about
Form S. In the report generation module various types of reports are to display
according to user selection.
Input: User will select the type of report that he/she wants to see.
Output: According to the types of report, the different module will display the
different reports.

R2.1: Title: Form S form submission report module.

Description: This report should display, how many reporting unit is delay or
in time for a particular reporting week under a particular block and then it
should display which reporting unit under that given block is in time or late.
Input: Name of the block, reporting unit, reporting week no and year.
Output: Firstly it should display the report as block wise i.e. how many
reporting unit is in time or delay in a given reporting week and then it
should display which reporting unit is delay or in time.

R2.2: Title: Form S syndromic surveillance report module.

Description: This report should give the details about the Form S. In this report
the user will give the details about the diseases and type of report that he/she
want and according to that different report should display. Each report should
display in hierarchal order. i.e. first it should display the report district wise,
then block wise under the selected district and then reporting unit wise under the
selected block.
Input: Type of diseases, type of report (Weekly, Comparison,
Progressive, Line Chart and Bar Chart), Name of the state and week
number.
Output: Type wise it should display the report to the user.

R2.2.1: Title: Form S weekly syndromic surveillance report module.

Description: It should generate the reports according to the week as
entered by user. i.e. it should give the details of the entry in Form S
according to the week as entered by the user.
Input: Week number, state name.
Output: Report as district wise, then block wise and finally
reporting unit wise.

R2.2.2: Title: Form S progressive report module.

Description: It should generate the reports according to the
week as entered by user but the report should be a progressive
one. i.e it should give the details of the entry in Form S about
the effected people in a particular week number and should
show the progressive status with respect to the previous week.
Input: Week number, state name.
Output: Report as district wise, then block wise and finally
reporting unit wise.

R2.2.3: Title: Form S comparison report module.

Description: It should generate the reports according to the
year as entered by user but the report should be a comparable
one with respect to the previous year of the entered year. i.e. it
should display the number of the diseases effected people in
two successive year in comparable way.
Input: Year, state name.
Output: Report as district wise, then block wise and finally
reporting unit wise.
5.3 Nonfunctional Requirements:

1.Maintainabilty: Back up of database should be taken periodically.

2.Portability: This application will run on both WINDOWS and UNIX

platform.

3.Usability: The system should be easy to use and should have a very easy to use
user interface.

4.Reliabilty: The system will be highly reliable and cannot be fooled.

5.Extensibilty: The system could be extended to integrate with the main IDSP
system.

6.Security: The whole system is about security and that’s why security is must. It
must be highly secure and difficult to break without detection.

*********************************************
SYSTEM ANALYSIS
6. ANALYSIS OF THE SYSTEM

6.1 Introduction:

System analysis is a detailed study of various operation performed by a system. The

aim of the system analysis is to deliver system in line with the user requirements. It is
activity that encompasses most of the task that we can collectively call Computer System
Engineering. Analysis of PIS is performed by the following object-oriented methodologies.
The purpose of the object-oriented analysis is to model the real world system so that it can
be understood. To do this we have to abstract important real world system features first and
defer small; details until later. The successful analysis model states that what we must
done, without restricting, how it done and avoid implementation decisions. The result of the
analysis should understand the problem as a preparation of design.

The real world model consists object, dynamic and functional models but during
analysis of PIS we have skipped the object and dynamic model as the activities and actions
are clearly defined.

6.2 Structured System Analysis:

Structured System Analysis is asset of techniques and graphical tools that allow the
analysis to develop a new kind of specification that are easily understandable to the user. It
is an ordered approach that works from the high level views to lower level details in which
the user needs are presented through the use of dataflow diagram. Structured analysis aids
in defining the requirements the new system so that the user has a system they need.

The goal of structured analysis: -

1. Use graphics whenever possible.

2. Differentiate between logical and physical entity.
3. Begin with an examination of the board picture of the system.
4. Build a logical system model of the proposed system from the physical model to
express the building blocks of the system to programmer analyst.
 Characteristics of the structured analysis: -

1. It depicts a picture of what is being specified and easy to understand

presentation of the application.
2. The process is portioned, so that a clear picture about the system flow from
general to specific can be made.
3. The element of the system specify in the precise, concise and highly readable
manner. It calls for rigorous study of the user area.

6.3 Tools for Structured Analysis:

A number of structured tools are used for analysis for the candidate system.

Some basic tools are: -

1. Context diagram.
2. Dataflow diagram.
3. Data dictionary.

Context Diagram:

The model, which represents the whole system in a single process showing the
external entities that, interacts with the system, is called Context Diagram. It shows all
external entities that interact with the system and dataflow between these entities and the
system. It contains a single process. But it plays a very important role studying the current
system.

System flowchart is the graphical representation of the system operational sequences

within the system. It shows the system flow sequence among the process of the system.
Dataflow Diagram:

Dataflow diagram is a graphical representation of a system that indicates the flow of

data to and run from the system. DFD also provide an overview of data that a system
process, what transformation of the data are done, what files are used and where the results
flow. It clarifies system requirements and identifies major transformation that will become
programs in a system design.

DFDs are nothing more than a network of related system functions and indicate from
where information is received and to where it is sent. It is the starting point in the system
that decomposes the requirement specifications down to the lowest level detail.

The four symbols in DFD, each of which has its meaning. They are given below: -

1. External entities are outside to system but they either supply input data in
the system or use the system output. These are represented by square of
rectangle. External entities that supply data into a system are sometimes
called Sources. External entities that use system data are sometimes called
sinks.
2. Dataflow models that passages of data in the system and are represented
by line by joining system components. An arrow indicates the direction of
the flow and the line is labeled by the name of the dataflow.
3. Process show that the systems do. Each process has one or more data
inputs and one or data outputs. Circles in DFD represent them. Each high
level process may be consisting of more than one lower level processes.
Process will be expanded in sequent level DFD. A circle or a bubble
represents a process that transforms incoming data flow into outgoing
dataflow.

The high level processes in a system are: -

o Receivable process.
o Verifiable process.
o Disposal process.
 4. File or data store is a repository of data. They contain data that is retained
in the system. Process can enter data into data store or retrieved data from
the data store. An open rectangle is a data store, data at rest.

The following diagrams illustrate the notation and the symbols used to create the DFDs.

: A Process.

: The external entities i.e. user.

: The arrowhead shows the flow of information.

: The table in which information will be stored.

: Database.
DFD for the proposed System:

The Data Flow Diagram (DFD) for the proposed system is shown in the following pages in
order of their process from the highest level to the lowest level of procedures.

Context Diagram IDSP System:

Level 1 DFD for IDSP System:

NOTE: (a) No. Of Infected People, No. Of People Died, Late Entry.
Level 2 DFD for Report Generation Process:
Level 3 DFD for Form Submission Report Process:
Level DFD for Syndromic Surveillance Process:

Level 4 DFD for Weekly Report:

Level 4 DFD for Bar Chart Generation Process:

Level 4 DFD for Line Chart Generation:

Level 2 DFD for Form S Process:
Level 2 DFD for Form S Process: (Cont…)
Level 2 DFD for Create New User Process:
Data Dictionary:

It is a structured place to keep details of the contents of data flows, processes and
data store, a data dictionary is a structured respiratory of data about data. It is a set of
rigorous definition of all DFD data elements and data structures and serves as a valuable
document to the organization at the time of future enhancement.
There are three classes of items to be defined in the data dictionary.

1. Data Element: The smallest unit of data that provides for no further
decomposition is called data element.

2. Data Structures: It consists of a group of data elements handled as a unit.

3. Data Flows and Data Stores: Data Flows are data structures in motion,
whereas data stores are data structures at rest. A data stores is a location
where data structures are temporarily located.
SL. FIELD NAME DATA TYPE FIELD DESCRIPTION SOURCE
No LENGTH
1 statecode character 2 State Code State, District,
varying Block, Reporting
Unit,
Disease_threshold,
form_s, User_table
2 statename character 50 State Name State
varying
3 districtcode character 3 District Code District, Block,
varying Reporting Unit,
Disease_threshold,
form_s, User_table
4 districtname character 50 District Name District
varying
5 blockcode character 3 Block Code Block, Reporting
varying Unit, form_s,
6 blockname character 50 Block Name Block
varying
7 reporting_code character 5 Reporting Unit Reporting Unit,
varying Code form_s
8 reporting_name character 50 Reporting Unit Reporting Unit
varying Name
9 district_pop Long Int - District Population District
10 block_pop Long Int - Block Population Block
11 reporting_pop Long Int - Reporting Unit Reporting Unit
Population
12 disease_code character 5 Disease Code Disease,
varying Disease_threshold
13 disease_name character 50 Disease Name Disease
varying
14 threshold_value Integer - Threshold value of Disease_threshold
Diseases
15 myear Integer - Year of reporting form_s
16 name_worker character 30 Name of the form_s
varying health worker
17 supervisor_name character 30 Name of the form_s
varying supervisor
18 dt_week_from Date - Date of reporting form_s
19 Id_dsu character 3 DSU ID form_s
20 fever_c_m Integer - No of male for form_s
fever case
21 fever_c_f Integer - No of female for form_s
fever case
22 fever_d_m Integer - No of male died form_s
for fever case
23 fever_d_f Integer - No of female form_s
died for fever
case
24 wtrystool_c_m Integer - No of male died form_s
for fever case
25 wtrystool_c_f Integer - No of male for form_s
Loose Watery
Stool case
26 wtrystool_d_m Integer - No of female for form_s
Loose Watery
Stool case
27 wtrystool_d_f Integer - No of male died form_s
for Loose Watery
Stool
28 Jaundice_c_m Integer - No of female form_s
died for Loose
Watery Stool
29 Jaundice_c_f Integer - No of female for form_s
Jaundice case
30 Jaundice_d_m Integer - No of male died form_s
for Jaundice
31 Jaundice_d_f Integer - No of female form_s
died for Jaundice
32 paralysis_c_m Integer - No of male for form_s
Paralysis case
33 paralysis_c_f Integer - No of female for form_s
Paralysis case
34 paralysis_d_m Integer - No of male died form_s
for Paralysis
35 paralysis_d_f Integer - No of female form_s
died for Paralysis
36 unusualsympt_c_m Integer - No of male for form_s
Unusual
Symptom
37 unusualsympt_c_f Integer - No of female for form_s
Unusual
Symptom
38 unusualsympt_d_m Integer - No of male died form_s
for Unusual
Symptom
39 unusualsympt_d_f Integer - No of female form_s
died for Unusual
Symptom
40 weekno Integer - Reporting week form_s
41 late Character 1 Late entry for form_s
reporting
42 mdate Timestamp - Time of reporting form_s
43 u_id Character 10 User ID User Table
varying
44 pwd Character 10 Password User Table
varying
45 add Character 50 User Address Master Table
varying
46 remarks Character 50 User Remark Master Table
varying
47 permission_frm Character 50 From where Master Table
varying permission is
given
48 permission_to Character 50 To whom Master Table
varying permission is
given
49 user_status Character 50 User Status Master Table
varying
50 date Date - Date of login Master Table
Flow Charts:

A flow chart is a graphical or symbolic representation of a process. Each step in the

process flow is represented by a different symbol and contains a short text description of
the process step in the flow chart symbol. The flow chart symbols are linked together with
arrow connectors (also known as flow lines).

IDSP FORM SUBMISSION STATUS (WEEKLY REPORT)

DATA ENTRY PROCEDURE FOR SYNDROMIC SURVEILLANCE
GENERATION OF SYNDROMIC SURVEILLANCE REPORT
SYSTEM ENVIRONMENT
7. System Environment

7.1 Tool and Technology Used:

The following tools and technology are used to develop the system

Hardware:

Intel Pentium® processor at 500 MHz

Minimum 512 MB memory

Software:

Component Software Name and Version Availability

Windows XP
Operating System Shareware
Web Server Tomcat 6.0 Freeware
Database PostgreSQL 8.2 Freeware
Browser Mozila Firefox, IE explorer Licensed
Database PstgreSQL Driver 8.2 Freeware
Connectivity
Java Development J2SDK1.5.2_05 Freeware
Kit
Client script Java Script Freeware
language
Application Servlet Servlet 2.4 or higher Freeware
Java Server Pages JSP 2.0 or higher Freeware

7.2 Architectural Fundamentals

Client-Server Paradigm

The paradigm of arranging for one application program to wait passively for
another application to initiate communication pervades so much of distributed computing it
has been given a name:
The Client - Server paradigm of interaction.

The term Client and Server refer to the two application involved in a
communication. The application that actively initiates contact is called a client, while the
application that passively waits for contact is called server.

Multiple Services on One Computer

A single, server – class computer can offer multiple services at the same time. On such
system, one server program runs for each service being offered. Although a computer can
operate multiple servers, the computer needs only a single physical connection to the
Internet. Running many servers on a single computer is practical because a server does not
consume computational resources while waiting for a request.

Client/Server Database System

Client/Server system are constructed so that the database can reside on a central
computer, known as a server, and be shared among several users. Users access the server
through a client or Server application:

♦ In a two-tier Client/Server system, user runs an application on their local computer,

known as a client that connects over a network to the server running SQL Server.
The client application runs both business logic and the code to display output to the
user, and is also known as a thick client.
 ♦ In multi-tier client/server system, the client application logic is run in two locations:
• The thin client is run on the user’s local computer and is focused on
displaying results to the user.
• The business logic is located in server application running on a server. Thin
clients request functions from the server application. Which is itself a
multithread application capable of working with many concurrent users .The
server application is the one that opens connections to the database server
and can be running on the same server as the database, or it can connect
across the network to a separate server operating as a database server.

To develop this system we used three-tier architecture, where presentations are done
with JSP and all business logics are performed in JSP bean and servlet.
Also we used JavaServer Pages Model 2 architecture that is also known as MVC
architecture , where models are created with the JSP bean and controlling is done by servlet
and view is done by JSP.

7.2 Technology Used

7.2.1 Java

Java is an object-oriented language. Java was designed to be easy for professional

programmer to learn and use efficiently. Java inherits the C/C++ syntax and the object-
oriented features of C++. Java can be used to create two types of programs-applications and
applets.

An output of a Java compiler is not executable code. Rather, it is a byte code. Byte
code is a highly optimized set of instruction that is designed to be executing by the Java
Run-time system, which is called the java virtual machine. Translating a java program into
bytecode helps makes it much easier to run a program in a wide variety of environments.
Because the execution of every java program is under the control of JVM, the JVM can
contain program and prevent it from generating side effects outside of the system. The use
of bytecode enables the java run-time system to execute programs much faster.

Benefits of using Java

• Java is Secure. Java achieves the protection by confining a java program to the java
execution environment and not allowing it to places extraordinary demands on a page,
 because the programs must execute reliably in a variety of system. The hard-to-track-
down bugs are simply impossible to create in Java.
• Java is multithreaded. Java was designed to meet the real-world requirement of
creating interactive, networked pages. To accomplish this, Java supports multithreading
programming, which allows you to write pages that perform multiple tasks
simultaneously.
• Java is dynamic. Java programs carry with them substantial amount of run-time type
information that is used to verify and resolve accesses to objects at run time. This
makes is possible to dynamically link code in a safe and expedient manner.
• Java’s exception handling. Java’s exception handling avoids the problem of checking
errors and handling them manually and brings run time error management into object-
oriented world. Access to other parts of the computer. Java programs can be
dynamically downloaded to all the various types of platform. Thus, it is portable.
• Java is robust. It is a strictly typed language; it checks your code at compile time.
However, it also checks your code at run time. Thus the ability to create robust program
was given high priority in the design of java. The multi-platform environment of the
web

Introduction to JSP :

JavaServer Pages (JSP) is a technology based on the Java language and enables the
development of dynamic web sites. JSP was developed by Sun Microsystems to allow
server side development. JSP files are HTML files with special Tags containing Java
source code that provide the dynamic content.

Introduction to Java Servlets:

Java Servlets provide the means through which Web Applications can be written in
Java. Web Applications allow a web site to be dynamic rather than straight static pages. In
other words, Servlets transform a web site with plain text and images into a rich interactive
environment for the user. In the beginning, Web Servers were made to just serve basic text
content and images. However, in order to provide an interactive environment, the web
server had to be extended to allow programs or scripts to be executed. This interface was
standardized as CGI.
 The browser would load an HTML page consisting of some form elements such as
text boxes or check boxes. Then, the user would fill in the form and submit it to the web
server. The Web Server would take the form data and submit the data to the CGI program.
When the CGI program runs, it outputs the relevant HTML or other data back to the Web
Server, which acts as a middleman and sends the data back to the browser. The diagram
below illustrates the life cycle of a browser getting results from a CGI program.

Why Use Servlets?

Servlets have a variety of enhancements over plain CGI. The most fundamental
advantage of Servlets is that they are tightly coupled to the Web Server. If you recall from
the diagram above, the web server whose lifetime exists only during the particular user
request typically launches CGI scripts as a separate process. It turns out that the CGI model
is extremely inefficient and slow especially with interpreted languages such as Perl or Java.
First, operating systems typically incur some overhead in simply launching another
process. When you think about it, an operating system really has to do quite a bit. It has to:

• Allocate memory for the process.

• Copy information about the environment that the parent process was running in so that
there is a security context.
• And the web server (parent process) must be constantly aware of the child process in
order to send the CGI output back to the user's web browser.

Second, an interpreted language typically has to load an entire program to interpret the
script before the program can even execute. In the case of Perl, this is the Perl executable.
In the case of Java, it is the Java binary. Even on a small program and a relatively fast
machine, a Java program can take a second or more to start.
Moreover we use Java Servlet because of the following reasons:

• Efficient: As compared with the CGI. Java Servlet provides a much more efficient
method of handling user request. A CGI program needs to create a separate process for
each user request. When a Servlet receives a user request it simply spawns another
thread within the same process and handles the request. This makes it possible for
hundred and thousand of users to access the same servlet simultaneously without
bringing down the server. This was appositively impact on performance, generate
multiple request do not generate processes, as does a CGI program. Good server
implementations use thread pools to constrains the number of thread that can be used to
services the client request, and prevent the machine grinding to halt. Servlets also have
more alternatives than do regular CGI programs for optimization such as catching
previous computations, keeping database connection open, and the like.
• Access to enterprise java APIs: Since Servlets are the extension of the java platform;
they can access all the java APIs. A java servlet can send and receive emails, invoke
method of remote objects using RMI or COBRA, obtain directory information using the
JNDI package, make use of Java Beans (EJB) or any other parts of java platform.
• Platform Independence: The servlet code is compiled into byte code that are
interpreted by a platform-specific Java Virtual Machine (JVM) on the web server. Since
the Servlets themselves are made up of machine independent byte code, you can freely
move your Servlets to any other platform that supports Java.
• Reusability: Creating component parts to an application is one-way to achieve reuse,
using object-oriented to encapsulate shared functionality is another Java uses both. It is
a completely object-oriented language and as such provides mechanism for reuse.
Modularity: When developing a complete server-side application, your program can large
and complex. It is always better to break down an application into discrete modules that are
responsible for specific task. When you do this, this makes your application very easy to
maintain and understand. Java Servlets, JSPs and Java Beans provide a way to modularize
your application-breaking application down into tiers and tasks.

7.2.2 Tomcat 6.0

Tomcat is a server container responsible for handling client request, passing the
request on to a servlet, and returning the request to a client. It includes many additional
features that makes it useful platform for developing and deploying web application and
web services.
Tomcat Directory Structure
Directory Name Description

bin Contains start-up/shutdown Scripts.

config Contains various configuration files including server.xml

(Tomcat’s main configuration file) and web.xml that sets
the default values for the various web application deployed
Tomcat.

doc Contains miscellaneous documents regarding Tomcat.

lib Additional class libraries and support files required by the

Development tools.

logs This is where the Tomcat places its log and output files.

src The servlet APIs source files. These are only the empty
interfaces and abstract classes that should be implemented
by any servlet container.

webapps Contains sample web application.

7.2.3 PostgreSQL 8.2

PostgreSQL is an object-relational database system that has the features of traditional

commercial database systems with enhancements to be found in next-generation DBMS
systems. PostgreSQL is free and the complete source code is available.

There are several ways of measuring Postgresql8.2: features, performance, reliability,

support, and price.
Features :

PostgreSQL has most features present in large commercial DBMSs, like transactions,
subselects, triggers, views, foreign key referential integrity, and sophisticated
locking. We have some features they do not have, like user-defined types,
inheritance, rules, and multi-version concurrency control to reduce lock contention.

Performance :

PostgreSQL's performance is comparable to other commercial and open source

databases. It is faster for some things, slower for others. Our performance is usually
+/-10% compared to other databases.

Reliability :

We realize that a DBMS must be reliable, or it is worthless. We strive to release

well-tested, stable code that has a minimum of bugs. Each release has at least one
month of beta testing, and our release history shows that we can provide stable,
solid releases that are ready for production use. We believe we compare favorably
to other database software in this area.

Support :

Our mailing lists provide contact with a large group of developers and users to help
resolve any problems encountered. While we cannot guarantee a fix, commercial
DBMSs do not always supply a fix either. Direct access to developers, the user
community, manuals, and the source code often make PostgreSQL support superior
to other DBMSs. There is commercial per-incident support available for those who
need it.

Price :
We are free for all use, both commercial and non-commercial. You can add our
code to your product with no limitations, except those outlined in our BSD-style
license stated above.

*********************************************
 SYSTEM DESIGN

8.1 Introduction
 The system design is a solution, a “how to” approach to the creation of a new
System. The design phase focuses on the detailed information of the system recommended
in the feasibility study. Emphasis is on translation of performance specification into design
specification. The design phase is a transition from a user-oriented document to a document
oriented to programmers or database personnel. System design goes through two phases of
development: -
1. Logical Design and
2. Physical Design

Logical design review the present system; prepare input and output specification;
make edit security, and control specification; detail the implementation plan, and prepare a
Logical design walkthrough. The physical design maps out details of physical system plan,
the system implementation, device a test and implementation plan, and specify any new
hardware and software.

8.1.1 Logical Design

A Data Flow Diagram shows the logical flow of system and defines the boundaries
of the system. Logical design specify the user specify the user needs a level of detail that
virtually determines the information flow into and out of the system and require data
resources. Logically design describes the, outputs, databases and procedures. All in a
format that meets user requirements.

8.1.2 Physical Design

The physical design produces the working system by defining the system
specification that tells the programmers exactly what the candidate system must do. The
physical design consist of the following steps:

1. Design of the physical system

• Design the database and specify backup procedures.
• Specify input/output media.
• Design physical information flow through the system and physical design
walkthrough.

2. Plan system implementation

• Prepare a conversion schedule and a target date.
 • Determine the training procedure, courses and timetable.

3. Devise a test and implementations plan and specify any new hardware and
software.

8.2 Structured Design:

Structured design is flow methodology. It is an attempt to minimize the complexity

and makes a problem manageable by subdividing it into smaller segments or module.
Structured design begins with system specification that identifies inputs and outputs
describe the functional aspects of the system.

Designing of project consist of number of steps. The design of the Integrated

Disease Surveillance Program (IDSP) consists of the following steps:

• DATABASE DESIGN
• INPUT /OUTPUT DESIGN

8.3 Database Design

The design of database describes how data should be organized around the user
requirements. It should be organized around the user requirements. It should be designed in
the line with the activity and volatility of the information and the nature of the storage
media and devices. One of the important steps in designing the database is normalization.
Normalization is the process of refining the data model and making the data more efficient.
This technique logically groups the data over the number of tables, which are independent
and contain no unnecessary or redundant data.

E R Diagram:
 An entity-relationship (ER) diagram is a specialized graphic that illustrates the
interrelationships between entities in a database. ER diagrams often use symbols to
represent three different types of information. Boxes are commonly used to represent
entities. Diamonds are normally used to represent relationships and ovals are used to
represent attributes.

There are three basic elements in ER models:

Entities are the "things" about which we seek information.

Attributes are the data we collect about the entities.
Relationships provide the structure needed to draw information from multiple entities.
Table Design:

Normalization:

Basically database normalization is the process of efficiently organizing data in a

database. There are two goals of the normalization process: eliminate redundant data and
ensure data dependencies make sense. Both of these are worthy goals as they reduce the
amount of space a database consumes and ensure that data is logically stored.

First Normal Form:

The normalization process involves getting our data to conform to three progressive
normal forms, and a higher level of normalization cannot be achieved until the previous
levels have been achieved(there are actually five normal forms, but the last two are mainly
academic and will not be discussed). The first normal form or 1NF involves removal of
redundant data from horizontal rows. We want to ensure that there is no duplication of data
in a given row, and that every column stores the least amount of information
possible(making the field atomic).

In our case database has been normalized in 1NF, since there is not any non-atomic
field.

Second Normal Form:

Where the 1NF deals with redundancy of data across a horizontal row, second
normal form deals with redundancy of data in vertical columns. As stated earlier, the
normal forms are progressive, so to achieve 2NF, tables must already be in 1NF and there
must be a primary key in each table.

In our case database has been normalized in 2NF, since there is primary key in
every table upon which other key is dependant.

Third Normal Form:

In 3NF we are looking for data in our tables that is not fully dependant on primary
key, but dependant on other value in the table. In other words there must not be any
transitive dependency in out tables.
 In our case database has been normalized in 3NF, since there is not any transitive
dependency in our tables.

Considering by various records regarding the IDSP (Form S) system, the design of
the database is developed so that it can satisfy the entire requirement and should be
efficient enough. The database consisting of 9 tables. All the tables are interrelated using
the key code that is unique in each case entity.

State (TABLE)

This is the table containing data about the states. In this project this table contain
data as state_code and state_name.

District (TABLE)

This is the table containing the data about the districts. In this project this table
contain data as district_code, district_name, district_population.

Block (TABLE)

This is the table containing the data about the blocks. In this project this table
contain data as block_code, block_name, block_population.

Reporting Unit (TABLE)

This is the table containing the data about the Reporting Units. In this project this
table contain data as reporting_code, reporting_name, reporting_population.
 Disease (TABLE)

This is the table containing the data about the Diseases. In this project this table
contain data as disease_code, disease_name.

Disease_Threshold (TABLE)

This is the table containing the data about the disease threshold. As each district
has different threshold values ,to maintain those value this table is used. In this project
this table contain data as disease_code, threshold_value, district_code, state_code .

Patient_info (TABLE)

This is one of the important table in this project. As main issue of IDSP is to
maintain the details about the effected people by different disease in the country. So
this table maintain the those details . The different data contains in this table are nos of
effected people in different disease, state_code, district_code, block_code, ru_code,
week_no, year.

User (TABLE)

This table contain the user information of IDSP. The data contain in this table as
user_ID, password,district_code, state_code.

Master_table (TABLE)

This table contain the user information that are used for official purpose, like the
name of the supervisor under whom the user worked, who gave the permission to the
user etc. The data contain in this table as user_ID, address, permission_from,
permission_to etc.
1.Table Name: State

FIELD NAME DATA TYPE FIELD LENGTH

state_code character varying 2
state_name character varying 50

Constrains: Primary Key (state_code)

2.Table Name: District

FIELD NAME DATA TYPE FIELD LENGTH

district_code character varying 3
state_code character varying 2
district_name character varying 50
district_pop bigint -

Constrains: Primary Key (state_code, district_code)

Foreign Key (state_code)

3.Table Name: Block

FIELD NAME DATA TYPE FIELD LENGTH

block_code character varying 3
district_code character varying 3
state_code character varying 2
block_name character varying 50
block_pop bigint -

Constrains: Primary Key (state_code, district_code, block_code)

Foreign Key (state_code, district_code)

4.Table Name: Reporting Unit

FIELD NAME DATA TYPE FIELD LENGTH

reporting_code character varying 5
block_code character varying 3
district_code character varying 3
 state_code character varying 2
reporting_name character varying 50
reporting_pop bigint -

Constrains: Primary Key (state_code, district_code, block_code, reporting_code

Foreign Key (state_code, district_code, block_code)

5.Table Name: Disease

FIELD NAME DATA TYPE FIELD LENGTH

disease_code character varying 5
disease_name character varying 50

Constrains: Primary Key (disease_code)

6.Table Name: Disease_threshold

FIELD NAME DATA TYPE FIELD LENGTH

disease_code character varying 5
state_code character varying 2
district_code character varying 3
threshold_value integer -

Constrains: Primary Key (state_code, district_code, disease_code)

Foreign Key (state_code, district_code)

7.Table Name: patient_info

FIELD NAME DATA TYPE FIELD LENGTH

state_code character varying 2
district_code character varying 3
block_code character varying 3
myear integer -
name_worker character varying 30
supervisor_na character varying 30
me
reporting_unit character varying 30
dt_week_from date -
id_dsu character 3
fever_c_m integer
fever_c_f integer
 fever_d_m integer
fever_d_f integer
wtrystools integer
_c_m
wtrystools _c_f integer
wtrystools integer
_d_m
wtrystools _d_f integer
Jaundice_c_m integer
Jaundice_c_f integer
Jaundice_d_m integer
Jaundice_d_f integer
paralysis_c_m integer
paralysis_c_f integer
paralysis_d_m integer
paralysis_d_f integer
unusualsympt_ integer
c_m
unusualsympt_ integer
c_f
unusualsympt_ integer
d_m
unusualsympt_ integer
d_f
weekno integer
late character 1
mdate Timestamp without
time zone

Constrains: Primary Key (state_code, district_code, block_code, reporting_unit, myear,

weekno)
Foreign Key (state_code, district_code, block_code, reporting_unit)

8.Table Name: User_Table

FIELD NAME DATA TYPE FIELD LENGTH

u_id character varying 10
pwd character varying 10
district_code character varying 3
state_code character varying 2

Constrains: Primary Key (u_id)

Foreign Key (state_code, district_code)
9.Table Name: Master_Table

FIELD NAME DATA TYPE FIELD LENGTH

u_id character varying 10
add character varying 50
remarks character varying 30
permission_frm character varying 30
permission_to character varying 30
user_status character varying 30
date Date -

Constrains: Primary Key (u_id)

Foreign Key (u_id)
 SYSTEM TESTING
AND
IMPLEMENTATION

9. SYSTEM TESTING:

9.1 Overview:
 Once source code has been generated, software must be tested to uncover and
correct as many errors as possible before delivering to the customer. Thus the goal is to
design a series of test cases that have a high like hood of finding errors. Testing begins in
the small and progresses to the large. This means that early testing focuses on a single
component to uncover errors in program logic and function. After individual components
are tested, they must be integrated. Testing continues as the software be constructed.
Finally, a series of high order tests are executed once the full software is operational.

9.2 Introduction:

During the system testing, the system is used experimentally to ensure that the
software does not fail, that is, it run according to its specifications and in the way user
expect.
System testing is vital to the success of the system. The idea behind testing is to
come up with the errors that otherwise may become an obstacle during the functioning of
the project. Test cases are devised with this purpose in mind. A test case is a set of data that
the system will process as normal input. However, the data are created with the express
intent of determining whether the system will process them correctly.

The importance of software testing and its limitations with respect to software
quality cannot be over emphasized. Because of its importance and the large amount of
project effort associated with it, it becomes necessary to the test the system before its
implementation.

Necessity of system testing:

Some of the necessities of testing process include the following:

1. Once a system has been designed, it is necessary to undergo an exhaustive testing

before installing the system. This is important because in some cases a small system
error, not detected and corrected before installation, may explode into much larger
problem later on.
2. Inadequate testing or non-testing may lead to errors that may be costly when they
appear months later on.
3. Another necessity for the system testing is its utility as a user oriented vehicle
before implementation, since even the best program is worthless if it does not meet
the user requirement.
9.3 Types of testing:

Some types of testing that are used in the system are:

String testing (Input Validation)

In this type of testing, the input data are tested to examine whether they confirm to
the given standards. Client-side and Server-side Validation codes are written to catch my
invalid input data.

Unit Testing:

Unit testing focuses verification effort on the smallest unit of software design- the
software component or module. In unit testing, each module are taken and tested
extensively to uncover as many errors as possible.

Integration Testing:

Integration testing is a systematic technique for constructing the program structure

while at the same time conducting tests to uncover errors associated with interfacing. The
objective is to take unit tested components and build a program structure that has been
dictated by design.

Regression Testing:

Regression testing is type of integration testing. In this testing, some subset of tests
that have already been conducted is re-executed to ensure that changes have not been
propagated unintended side effects.

Validation Testing:

Validation Testing is successful when a software functions in a manner that can be

reasonably expected by the customer. Reasonable expectations are defined in the system
Requirement Specification that describes all user- visible attributes of the software. Test
cases are designed to ensure that all the functional requirements are satisfied, all the
behavioral characteristics are achieved and all the performance requirements are attained.
Various modules are tested thoroughly to see whether all the requirements that were
specified in SRS are met.

System Testing:

System Testing is series of different tests whose primary purpose is to fully exercise
the web-based system. The some essential tests that are done are:

Recovery Testing:

Recovery testing is system test that forces the system to fail in a variety of
ways and verifies that recovery is performed either automatically or manually. Test
has been conducted to put an array out of bound and check weather the system is
able to handle this situation or stops functioning all together.

Security Testing:

Security testing attempt to verify that protection mechanism built into the
system will, in fact protect it from improper penetration. During testing, the tester
plays the role of the individual desires to penetrate the system. As the system being
developed in web based system and is a project undertaken by the Health Ministry
of India, it needs to be fool proof as far as security is concerned.

1. Anybody who does not have a Login ID and Password cannot enter to the
system to add, delete and update the data.
2. A user can register him/herself into the system if he/she is a valid health worker.
He has to submit all necessary details at the time of registration.
3. The connectivity to the database is secure, so that only authorized user can
access the database.
9.4 System Implementation:

A crucial phase in the systems life cycle is successful implementation of new

system. The new design implementation simply means converting a new system design into
an operational one. This involve creating compatible files , training and operating staff and
installing hardware and terminal etc. before the system is up and running. The objective of
implementation is to put the tested system into operation while holding costs and risks.

After a through testing of the system as described above, the system is ready for
implementation. The system has been demonstrated recently to the WHO person and
officers related to IDSP.

10. SYSTEM SECURITY

Every candidate system must provide built in features for security and integrity of data. Without
safeguard against unauthorized access, fraud, embezzlement, fire and natural disaster, a system
could be so vulnerable as to threaten the survival of the organization. The end user is always
concerned about security along with increased dependence on the computer. In the system
development, the developer and the system analyst must consider measures for maintaining data
integrity and controlling security at all times. This involves built-in hardware features, programs
and procedure to protect candidate system from unauthorized access.
 Physical Security

The most costly loss in software is program error. It is possible to eliminate such error proper
testing routines. Parallel runs should be implemented whenever possible. Physical security
provides safeguards against the destruction of hardware, databases and documentation; fire,
flood, theft, sabotage and cave dropping; and loss of power through proper backup.

Database Security

The proper use of the file library is another important security features. This involves
adequate file backup and reliable personal to handle file documentation when needed.
File backup means keeping duplicates copies of the master and the other key files and
storing them in suitable environmental conditions.

Application Security

The complexity of the system makes auditing necessary. Neither the auditor nor the user can
verify the system check itself. The internal controls required means that the programmer and
analyst build controls into every system. Developing a corporate auditing policy will ensure
that future system meet the minimum requirements for security and control against fraud and
embezzlement.

Transaction Entry

A logical failure occurs when activity to the database is interrupted with no chance of
completing the currently executing transactions. When the system is and running again it is
not known whether or not modification are still in memory or were made to the actual data.
Through still readable, the database may be inaccurate.

11. FUTURE ENHANCEMENT:

In this module I developed the system only for Form S and also on creation of
backup file, uploading the file and restore it on the central server.
Moreover there are various tasks are there in the IDSP system. This module can be
integrated with the other module in the IDSP system, like Form P, Form L, and Form W etc
also with IDSP GSI system.
 This system being web- based and an undertaking of Health Ministry, needs to be
thoroughly tested and hence better encrypted facility and be developed to enhance the
security of the system. Only after the system is fool proof then the system be uploaded to
Internet.

13. PROJECT SCREEN SHOTS:

IDSP Home Page:
IDSP select form type page:

In this page appears after successfully logged in by the authenticated user. Here user will
select the form type he/she going to submit/update or delete.
Form S Detail selection page:

In this page the user will select the necessary option for Form S submission.
The user will select mainly Block Name, Reporting Unit Name, Week No (From and To).
Form S Submit Form:

In this form the user will submit all details of Form S. After submitting all details the user
will click submit button to stored datas into server.
Form Submit validation:

After successfully inserting the datas unto server, this validation will appear.
Form S update form:
Form S update validation:
Form S update/delete validation if data is not available:

Form S delete form:

IDSP Form S report menu page:

In this menu the user will select the diseases types and report types for which he/she wants
to view the report.
IDSP report view district wise:
Form S district wise bar chart view:
Form S district wise bar chart view( weekly):
Form S district wise line chart view:
Form S district wise line chart view (weekly):
Back up file upload page:

12. CONCLUSION:

The objective of the project was to develop IDSP (Form S) system, which helps to
perform the function, related to health status to the people of India.
 It was a good experience developing this project. Working together in a team helped
me to communicate better. I understand the importance of planning and designing as a part
of software development. The concept of peer-review helped to rectify the problems as and
when they occurred and also helped me to get some valuable suggestions that were
incorporated by me.

Developing the project has helped me to gain some experience on real-time development
procedures.

Bibliography:

Books:
  Complete Reference in JAVA

By Herbert Schildt

 Java for the Web with Servlets, JSP, and EJB

By Budi Kurniawan

 System Analysis and Design

By Elias M. Awad

 Database System Concepts, Fifth Edition

By A. Silberschatz, H. F. Korth, and S. Sudarshan.

 Mastering Java Script

By James Jaworski

Websites:

 www.java.sun.com
 www.devguru.com
 www.w3school.com
 www.roseindia.com
 www.javaworld.com