Consolidated TO-BE & Functional Requirement Specifications ...

`1

Consolidated TO-BE & Functional Requirement

Specifications Report

State Mission Mode Project, Uttar Pradesh

Department of Information Technology

Government of India

17th

October 2008

DOCUMENT CONTROL

Document Title: Consolidated Updated TO-BE & Functional Requirement Specifications

report for e-District, Uttar Pradesh

Document Status: Yet to be submitted to the MoIT, Govt of India & DoIT, Govt of Uttar

Pradesh

Abstract: This document is a final consolidation of the BPR report, To-Be & FRS for all

10 services along with the proposed technological architecture and includes the suggested

changes in the document after reviews at various levels.

Document Publication History

(All revisions made to this document must be listed in chronological order, with the most

recent revision at the top.)

Date Author Version Remark

17th

Oct,

2008

Project Team Wipro,

PWC & 3i Infotech

4.0 Fourth Release Version (Consolidated

Updated report for all ten services)

7th

Jan,

2008

Project Team Wipro,

PWC & 3i Infotech

3.0 Third Release Version (Consolidated report

for all ten services)

14th

Dec,

2007

Project Team Wipro,

PWC & 3i Infotech

2.0 Second Release Version (For six services)

29th

Nov,

2007

Project Team Wipro,

PWC & 3i Infotech

1.0 First Release Version (For four services)

Reviewers

Date Reviewer Remarks

10th

Oct, 2008

Naveen Prakash, Wipro

Rakesh Kaul, PWC

Nitin Thakur, 3i Infotech

2nd

Jan, 2008


Rakesh Kaul, PWC


10th

Dec, 2007


Rakesh Kaul, PWC


25th

Nov, 2007


Rakesh Kaul, PWC


Distribution

Version Name Location

4.0 MoIT, GOI

DoIT, GoUP

N.Delhi

Lucknow

3.0 DoIT, GoUP Lucknow



NOTE to Holders:

If you receive an electronic copy of this document and you print it out, you should write

your name on the front cover (for document control purpose).

If you receive a hard copy of this document, please, write your name on the front cover

(for document control purposes).

LE OF CONTENTS

Executive Summary ............................................................................. 6

1.0 Background and Introduction ............................................................ 8

1.1 Project Objective .............................................................................................. 10

1.2 Scope of Work ...................................................................................................... 11

1.3 Overall Approach ................................................................................................. 13

2.0 Business Process Re-engineering ....................................................... 16

2.0 Business Process Re-engineering ....................................................... 17

2.1 Service Framework .............................................................................................. 17

2.2 Component Based Approach .............................................................................. 19

2.3 Service Levels ...................................................................................................... 26

3.0 Service components ....................................................................... 33

3.1 Information Dissemination component............................................................ 33

3.2 Forms availability component ........................................................................... 40

3.3 Application receipt Component ........................................................................ 46

3.4 Payment component ........................................................................................... 55

3.5 Verification Component ..................................................................................... 66

3.6 Rejection Component ......................................................................................... 73

3.7 Approval component ........................................................................................... 80

3.8 Delivery component ............................................................................................ 86

3.9 Status ..................................................................................................................... 91

3.10 Monitoring (MIS) ................................................................................................. 97

3.11 Workflow Component ..................................................................................... 104

4.0 Workflow – To-Be & FRS ................................................................ 107

4.1 Certificates .................................................................................................... 125

4.2 RTI & Grievance Services ............................................................................ 219

4.3 Election Related Services ........................................................................... 248

4.4 Pension Related Services ............................................................................ 264

4.5 Utility Services .............................................................................................. 322

4.6 Police Related Services ............................................................................... 336

4.7 Due& Recovery Related Services ............................................................... 355

4.8 Employment Related Services.................................................................... 370

4.9 Public Distribution System .......................................................................... 438

4.10 Revenue Court service ................................................................................ 495

5.0 Technical and Application Architecture ............................................. 506

5.1 Architecture Framework & Principles ...................................................... 506

5.2 Architecture Vision ...................................................................................... 509

5.3 Constraints .................................................................................................... 511

5.4 Information Systems Architecture ............................................................ 514

5.5 Technology Architecture .............................................................................. 519

5.6 Quality of Service Considerations ............................................................. 524

6.0 Way Forward .............................................................................. 536

Executive Summary

E-district is a State Mission Mode Project under the National e-Governance Plan. The

project aims to target high volume services currently not covered by any MMP under

NeGP and undertake backend computerization to e-enable the delivery of these

services through Common Service Centers.

e-District has been envisaged by Government of Uttar Pradesh (GoUP) as automation

of workflow and internal processes of District Administration with the possibility of

seamless integration of various services covered under the project like Certificates,

Police, and Public Grievances & Right to Information, Public Distribution System,

Pension, Utilities, Dues and Recoveries from Land Revenue Perspective, Electoral,

Revenue Court and Employment services.

The objective of this program is to implement Pilot e-district model in 6 districts of

Uttar Pradesh and provide integrated citizen centric services in the district. The

identified districts are: Gautambudh Nagar, Ghaziabad, Gorakhpur, Sitapur, Rae Bareli

and Sultanpur.

An “As Is Study” report for 10 categories of services under e-District project was

submitted to the state on 22nd October 2007. This was followed by the submission of

Business Process Re-engineering requirements report to the state government on

November 23, 2007. Further to this, „To-Be & FRS‟ report for 4 services was submitted

on 29th November and for remaining 6 services on 14th December, 2007. A working

draft of consolidated „To-Be & FRS‟ report of 10 services was submitted to UPDESCO

on 27th December, 2007.

This report is a final consolidation of the BPR report, To-Be & FRS for all 10 services

along with the proposed technological architecture and includes the suggested

changes in the document after reviews at various levels. This report includes the

recommendation of review committee (held on 22nd December & 26th December),

incorporation of feedback given by National Informatics Center and also the

recommendation of State level Review Committee on 28th December.

The report has been structured in way to cover the architectural framework to support

the e district application and then it explains the service components which serve as

the building block for defining the „To Be‟ processes which has been re engineered

using the components. The service components will be linked with the „To-Be‟

processes so as to provide for consolidated delivery of the services under the e-District

Project. The streamlining of the front end, channels of delivery, service components

and „To-Be‟ process will provide a comprehensive service delivery mechanism for

better delivery of services to the citizen.

The proposed service flows have been explained with the help of TO BE process maps.

These process maps capture the roles of various stakeholders as well as the flow of

information and documents from one level to another. It also explains how the

different components interact with the system for delivering the requested service in

a timely and an efficient manner. Further, it details out on information about its

starting and completion conditions, constituent activities and rules for players and non

players, process holders and participating entities, user tasks to be undertaken,

references to applications which may to be invoked in the process, definition of any

workflow relevant data which may need to be referenced, etc.

The proposed Functional Requirements Specifications (FRS) in this document deals

with the application‟s intended capabilities and interactions with the users. The

proposed FRS also mentions the functional aspects that the application needs to have

to support the various requests that the users might require from the system. The FRS

takes into account the various scenarios that the application might have to encounter

during service request reprisal and also it specifies how the system will integrate with

the various components specified in the BPR report.

A overview of the technology architecture has been presented that the proposed

application would be built upon. It about various technology layers of the application

that the user would interact while accessing the database. The standard technical

specifications of the components that serve as the building block of the architecture

have been provided. During the preparation of application architecture standards

specified in the e District guidelines have been strictly adhered.

Lastly, the way forward for the e-District project has been mentioned where

development of e-district application by NIC, development of Government Orders for

the selected services, initiation of data digitization, procurement of hardware and

initiation of change management activities along with training and capacity building

activities are listed.

1.0 Background and Introduction

Background

The National e-Governance Plan (NeGP) of Indian Government seeks to lay foundation

and provide the long term impetus for long term growth of e-Governance within the

country. The focus of the NeGP is on delivery of services to citizens in an efficient and

transparent manner at affordable cost to the citizens. The NeGP envisages the

creation of certain core and support infrastructure which would web enable services

for anytime anywhere access and thereby radically change the way Government

delivers services.

NeGP vision

“All Government services accessible to the common man in his locality through a

one stop shop ensuring convenience, efficiency, transparency and reliability at an

affordable cost to meet the basic needs of the common man.”

E-district is a State Mission Mode Project under the National e-Governance Plan. The

project aims to target high volume services currently not covered by any MMP under

NeGP and undertake backend computerization to e-enable the delivery of these

services through Common Service Centers. Districts are the primary delivery channels

for government administration which deliver a large number of services to the

citizens; therefore e-governance can significantly improve government service

delivery. E-district is defined as “delivering more than 75% of the services of

Collectorate electronically”

UP is surging forward with a motto of „reaching the un-reached and ‘bridging the

digital divide‟

Government of Uttar Pradesh envisages e-district that delivers majority of services

through the district administration with the use of Information Technology and

Communication (ICT). e-District has been envisaged by Government of Uttar Pradesh

(GoUP) as automation of workflow and internal processes of District Administration

with the possibility of seamless integration of various departments like Revenue, Food,

Basic Education, Social Welfare, Minorities, Forests, Panchayati Raj, Rural

Development, Agriculture, Election, Home, Minor Irrigation, Passport, Irrigation,

Excise, Finance & Treasuries, Family Welfare, Horticulture, Cooperatives, Transport,

Health, Land Records, and Registration etc. for providing services to the citizens. This

project is of paramount importance to the State as it would help in creating an

automated workflow system for the district administration and help in providing

efficient individual department services through Common Service Centers (CSCs) which

would be the primary front end channels envisaged under the NeGP program by

Department of Information Technology (DIT), Ministry of Communication and

Information Technology (MCIT), Government of India (GoI).

The objective of this program is to implement Pilot e-district model in 6 districts of

Uttar Pradesh and provide integrated citizen centric services in the district. The

identified districts are:

Gautambudh Nagar

Ghaziabad

Gorakhpur

Sitapur

Rae Bareli

Sultanpur

According to the guidelines framed by the Department of Information Technology (MIT)

10 core services were to be implemented under the e-District mission mode project

(MMP) out of which 6 core service were identified at the national level and the State

could add 4 more services at its discretion. Keeping in view the NeGP vision and DIT

guidelines, 4 services were identified by the State in a meeting held on 19th September

2007 in Lucknow.

6 core categories of services as identified at the national level:

Certificates

Pension

Revenue court

Dues and recovery

Ration card (PDS)

Right to information (RTI)

4 additional categories of services as identified at the state level:

Social welfare

Electoral

Utility

Police

Following the identification of 10 categories of services and the sub-service under

each category, an As-Is study was conducted for each of the 10 identified services to

evaluate and understand the current ground situation keeping in perspective the

people, process and the technology involved. Specific inputs were taken to understand

the current scenario with respect to the mandated process vis-à-vis the process being

followed, transaction volume, revenue generated, dependency on other departments,

relevant Government Orders, Administrative Orders and Acts etc., existent digitization

level and current IT capability of the service owners.

An “As Is Study” report on our understanding of the AS-Is scenario for all the 10

categories of services under e-District MMP was submitted to the state on 22nd October

2007.

1.1 Project Objective

The main objective of the e-district project is to computerize the workflow system

and internal processes of the administration of the pilot districts with the help of

Information & Communications Technologies (ICT). The state envisages meeting the

following objectives with the implementation of e -Districts project:

Implementation of an efficient electronic workflow system for District

Administration.

Infusion of transparency and accountability in operations

Reduction of workload of department personnel

Ensuring longevity of the data / protection from damage from moisture and

other climatic factors

Electronic security and control of confidential data

Fast processing of public cases/appeals/grievances dissemination of

information as per public requirement

To create an efficient delivery mechanism from the Government that brings

citizens to the district administration

To disseminate the information required by citizen

To proactively provide an efficient system of disseminating information on the

Government schemes planned developmental activities and status of current activities

1.2 Scope of Work

The scope of the project is limited to implementing the model e-District of Uttar

Pradesh. The scope of work as defined in the project document is being enlisted below

–

To cover maximum G2C and G2B services provided in the district through the

use of ICT. Services in the district that are delivered from sub-division / Tehsil

and block level are to be brought under the ambit of e-District. It is pertinent

to mention that emphasis of this initiative is on the services and not on mere

computerization of Collectorate along with its Tehsils and Blocks.

To integrate with ongoing initiatives of the Government under NeGP such as

SWAN, Capacity Building, Common Service Centres, State Data Centers (SDCs)

etc.

To integrate the state‟s ongoing e-Governance initiatives in the areas of Land

Records, Registration, Treasury, Agriculture, Transport, Election, Food,

Revenue etc.

The scope of the program is limited to implementing the model e-District in 6

pilot districts of Uttar Pradesh and providing assistance in development of a

Request for Proposal (RFP) for statewide roll out based on the success of pilot

e-Districts implementation. Thereafter, the rollout of the implementation

across the state, based on this RFP, would be the responsibility of the state

Government.

The specific activities in the e-District project includes

1) Requirement Analysis

i. Planning

ii. „As –Is‟ Assessment

iii. Target Envisioning

iv. „To –Be‟ Processes

2) Development of software application systems

3) Data entry / digitization of manual records

4) Provisioning of IT Hardware, Licensed Software and Networking (Local Area

Network)

5) Refurbishment of Administration Offices

6) Implementation of the e-district applications

7) Training of the departmental personnel and users

The detailed scope of work is:

1) Requirement Analysis: In order to benefit from this initiative it is necessary to

analyze and then redesign the current district administration system and its

components to bring in effectiveness, efficiency and added value contribution to

the objective of district administration. The BPR would comprise of following

steps:

2) Planning: This step would entail planning activities that would include the

selection of core implementation team with representatives of pilot district

administration, the creation of a project scope document, and an examination of

existing workflow system.

a) As-Is Assessment: This assessment would primarily comprise of examining the

existing workflow processes and system used by the district administration. A

business process map for the current process has been prepared. Subsequently,

similar activities would be grouped for process normalization and redundant

activities would be proposed for removal.

b) Target Envisioning: The target state would be envisioned after benchmarking of

the normalized processes by comparison of both the performance of the district

administration‟s processes and the way those processes are conducted with those

relevant to best practices in the industry to obtain ideas for improvement.

c) To-Be Process: After the identification of potential improvements to the existing

processes, the development of the To-Be workflow system would be build on the

research from the benchmarking and best practices activities. It would also be

required to identify and document risks associated with implementation of the

automated workflow processes. The resultant To-Be processes would be validated

by the district administration officials and duly approved by the government before

implementation.

Report Purpose

This report consists of the redesigned process framework for the 10 services

undertaken as part of the UP e-District Project. The areas for improvement have been

identified after scrutinizing the bottlenecks; inefficiencies and non value add activities

observed during the course of As Is Study. New processes have been designed after

deliberations with the District Administration and are in line with the guidelines laid

down by the Department of Information Technology for the e-District Project.

1.3 Overall Approach

For each identified services, the project team adopted the methodology

illustrated in figure given below for designing new processes. The process re-

design methodology broadly involves three phases - Understanding of “As-Is”

processes, Analysis of the “As-Is” process and design of the “To-Be” processes.

Phase I – Understanding the As Is Processes

This phase was initiated with identifying process owners and other stakeholders

involved in the workflow for the identified processes. Project Team visited all

the offices involved in service delivery of the identified services. After

gathering the information available across all the offices the team had iterative

discussions with the process owners. In all cases the first meeting was held

with senior level staff (ADMs, SDMs, and Tehsildar) and subsequent discussions

were held with the operational staff (Computer Operators, Clerks etc.).

Reference material (such as GOs, Service manuals, Application forms, records)

was also collected by the team to supplement their understanding of the

process. After gathering data and supporting material for each process, the

processes were documented by the team in the form of flow charts and

presentations. Subsequently, these were collectively reviewed by District

Project Team.

Phase II – Analysis of the As Is Process

The purpose of this task was to conduct analysis at the macro (process) and the

micro (sub-processes) level of the selected processes to identify bottlenecks

and suggest opportunities for the improvement thereof. Processes were

mapped to the sub-process level and Value Analysis was done to categorize

each sub-process as Value-Adding or Non Value-Adding. This framework was

found suitable for key process analysis in the current scenario as the number of

Non Value-Added components was high and further analysis was required

before eliminating or minimizing them. The shortcomings of each of the

processes / services were compiled as „Issues and concerns in current

processes‟. Additional inputs obtained during one-to-one discussions with the

staff are also used to identify the limitations of current processes.

Phase III – Design of To Be Process

In this phase, five key activities were undertaken, as detailed below:

a. Review the process objectives

The purpose of this step is to determine whether the desired end result of the

process:

is consistent with the objectives

addresses customer needs and expectations

is measurable

can be implemented

b. Develop and Analyze Alternative Process Design

The purpose of this step is to identify and explore the possibilities of

alternative procedures that can be adopted to accomplish the desired

outcome. Each activity of the „As-Is‟ Process was analyzed to re-assess

limitations and explore alternate processes that would result more efficient

and innovative processes. The national / international Best Practices compiled

in the previous steps were also used to identify the re-usable procedures

wherever applicable. Finally, alternate processes were designed incorporating

the process objectives and best practices adopted elsewhere.

c. Discussions with the Stakeholders

The purpose of this step is to present the redesigned process to stakeholders

and obtain their feedback on the recommendations. This step involves iterative

discussions with the stakeholders, to ensure that required clarifications are

provided along with supporting documentation and perceived benefits of the

redesigned process.

d. Develop the performance measures

The purpose of this step is to develop measurable indicators for each of the

redesigned process, as they help decision makers examine the outcome of

various measured processes and strategies

Part II Business Process Re-engineering

2.0 Business Process Re-engineering

2.1 Service Framework

Overview of the component based approach

As a part of the business process re-engineering, similar activities have been grouped

for process normalization and redundant activities have been proposed for removal.

Aspects that needed prime attention include:

Service definitions, service organisation, service personnel;

Effectiveness and efficiency of provided services;

Service Levels

This component based approach was discussed on 7th Nov 2007 workshop, wherein 11

components were identified. These 11 components are the basic building blocks of the

entire BPR framework and the proposed “To Be” envisioning. These components are

listed as follows:

Information

Forms availability

Application receipt

Payments

Verification (physical)

Verification (non-physical)

Rejection

Approval/signing of approver

Delivery / collection

Status

Monitoring (MIS)

Workflow

Process Flow

The revised process flow has been explained below:

The citizen goes to the nearest CSC/ e-District centre

The citizen validates his identity to the kiosk owner

The citizen makes a request for a service to the operator

Kiosk operator will login to the e-District portal

The kiosk operator will access the relevant department‟s application on the

portal.

The operator will fill up the online form, take a print out of the filled up form

and asks the citizen to verify the details

The citizen examines the printed form and verifies the details.

The citizen then manually signs or puts his thumb impression on the printed out

form

The operator digitally signs the online application and submits it.

The operator also issues a copy of the application to the citizen and an

acknowledgement receipt which will include the date of delivery and a unique

receipt number

The operator then dispatches all the citizen signed printed out forms to the

District Administration office

The process owner receives the online application and starts processing it.

The process owner will first verify the details in the e-District database.

If the details are found to be correct, he approves the application by digitally

signing it and submits it back to the e-District Application.

If the details are not found in the e-District database, he orders a physical

verification.

The field officer assigned for physical verification will verify and record

all the details required in the e-District database for all the family

members in one visit

The field officer then visits a computer centre at the tehsil or block

office, updates the data in the e-District database and digitally signs it

The process owner revalidates the details in the database against the

application and either approves or rejects the request.

The process owner also issues the relevant document or a reason for rejection

using his digital signature

The citizen visits the kiosk on the specified date of delivery and requests for

the document

The operator logs into the e-District portal and retrieves the digitally signed

document, prints it out and stamps it with his seal

The printed out document will have a unique ID and a website address to verify

its authenticity

The applicant proves his identity and receives the document

Major Challenges for process improvement

Based on the proposed process flow, certain key challenges have been identified which

need to be discussed and finalized before the final TO-BE processes are defined in

detail. Suggested solutions for each of the identified challenges have been presented

in the report.

Authentication mechanism for service delivery Kiosk and Citizen

Digital signing of applicant on the online application form/ usage of kiosk

operator‟s digital signature for submission of the digital form

Provision for allowing decisions to be made based on the databases of other

departments. Databases that can be used

o Parivar Register

o Ration Card

o Scholarship Database

o BPL list

o Electoral Database

o Land Records

o Employment Exchange Database

o CMO data base

Delivery of service based on e-district database (No supporting document to be

submitted at the time of application)

Self declaration to be substituted for affidavits

100% verification of all the fields of the e-district database for the first time

Delivery Mechanism, digitally signed document with a unique number and mentioning

the URL where the contents can be verified will be issued. (Can this certificate be

physically signed by a gazzeted officer/ process owner/CSC)

2.2 Component Based Approach

In the current scenario, the service delivery framework of the District Administration

is tightly coupled with the core administration because of which any changes

introduced into the service delivery mechanism trigger several more changes within

the Administration making the implementation of the change difficult. Moreover, due

to the lack of inter-linking between the departments each service has its own manual

or digital database which leads to repeated verification of the citizen based on the

service requested and generation of duplicate and redundant data. In essence, the

current service delivery mechanism is department centric wherein the citizen

approaches various departments to avail services.

A schematic representation of the current scenario is:

A service oriented architecture based approach has been adopted for developing the

framework for e-district to introduce flexibility in the service delivery mechanism.

This architecture decouples the core administration, decision making and each aspect

of the service delivery mechanism into distinct components. Based on this approach,

the proposed e-District service delivery mechanism has been divided into 11

components. These 11 components form the basic building blocks of the entire BPR

framework and the proposed “To Be” envisioning.

Further, the 11 components have been broadly categorized into customer centric

elements if the components require citizen interface and department centric elements

if the components define the departmental processes.

The customer centric elements include the following service components:

Information

Various

ServicesCore

Administration

Multiple Data

stores

Tehsil

BDO

Collectorate

OthersGovt. Rules,

Laws, Acts,

Orders etc.

Form availability

Application receipt

Payment

Delivery / collection

The Department centric element includes the following service components:

Verification (physical and non physical)

Rejection

Approval

Monitoring

Workflow

The framework is proposed to include front end for the e-District application,

enterprise application layer, service components, channels of delivery, integrated „To-

Be‟ processes, application layer and back end as the critical elements of the model.

These elements provides for allow comprehensive functionality to proposed solution

for the e-District.

A schematic overview of the overall BPR framework is shown below:

Streamlining of the front end, channels of delivery, service components and the „To-

Be‟ process will ensure a comprehensive service delivery mechanism for a more

efficient delivery of services to the citizens. Further, it will improve the efficiency of

the service delivery at the departmental level but also aid and assist in monitoring and

reporting of the services. The proposed architecture has been detailed below.

Front End

In the framework, front end has been envisaged to provide a single window service

delivery channel for the citizen from where the citizen can request for a service and

also receive the deliverable duly signed by the respective authority.

To facilitate „Anytime Anywhere‟ accessibility and to ensure convenience to the

citizen, two delivery channels have been proposed –

1. Online / Web Based

2. Service Delivery Centers (Common Service Center, BDO, Tehsil Office etc.)

Enterprise Application Layer

The enterprise application layer is proposed to integrate the front end with the service

delivery components through a secured gateway. The gateway will ensure standard

based interoperability between various departmental applications at the back end and

connect the CSCs and other channels of delivery at the front end. Acting as the nerve

centre, the gateways would handle a large number of transactions across the entire

network; provide a common set of specifications and a single point access for

departments. Such an infrastructure would also facilitate inter-departmental working

in a coordinated and synchronized manner.

This enterprise application layer will grant free access to the citizens for information

related services, form availability, status tracking and authentication of the issued

documents as defined under the application. A central message processing mechanism

would also help in tracking all the transactions of the Government.

Service Components

The service components are the critical elements of the proposed model. These

elements define the way the way in which the service request will be entertained,

processed and finally delivered back to the applicant. The service components include

the the 11 service components which have been proposed for the e-district

application.

These components are envisaged to handle all functionalities of the proposed e-

District application.

Detailing of all the components has been done in the later section of the report where

the definition, purpose and objective, citizen and departmental significance, proposed

channel of delivery, etc have been discussed.

Channels of delivery

The proposed e-district framework has channel of delivery as an essential element

which will enable the component to take up the defined route for input as well as

output from the application. Some of the envisaged channels of delivery include the

following –

1. Common Service Centers

2. Block Development Office

3. Tehsil Office

4. Integrated Voice Response System (IVRS)

5. Short Messaging Service (SMS)

6. Online (web based service)

7. Others – external entities like bank, etc

It is envisaged that multiple channels of delivery will help in providing accessibility to

the citizens for availing various services.

To-Be Processes

The proposed e-district application will have embedded improved To-Be processes as

the core mechanism to processing the service requests. These processes will detail out

the optimum way by which the service request will be processed and finally delivered

to the applicant. The proposed „To-Be‟ processes will define the work flow, the roles

and responsibilities of the service personnel – process owners, main and participating

actors, information and data flow, decision points, starting and completion criteria,

constituent activities, rules and regulations for the actors, workflow , service levels

etc.

Application Layer

Application layer will be the technology within which the To-Be processes will be

embedded. This layer would define all the functionality and work flow of service

delivery and contains all the possible logics based on acts, rules, government orders,

departmental orders, etc. This layer will contain the defined way through which the

user can interact with the application – provide required input to the system and get

output from the system. Also, this backend supports an intelligent Management

Information System (MIS) so as to perform the defined functionality for monitoring and

reporting associated with the selected services.

Additionally, this layer would interact directly with the application process and

perform common application services based on the service request. It will also ensure

that effective communication between all the components in a network is possible.

Back End

The back end of the proposed e-district application is the core decision making body of

the service delivery mechanism. It includes the District Administration and the State

Government. The decision making body shall only focus on the decision making ability

of the concerned department head and other government officers in performance of

their delegated responsibilities.

The data storage and handling will also be a backend task as defined by the system in

specified structure.

Advantages of proposed service component based architecture:

Decouples the services from the Core Administration allowing the service

delivery mechanisms to incorporate changes without triggering changes in Core

Processes and the District Administration.

Introduces one comprehensive data repository ensuring :

Reduced duplication of effort

Removal of redundancy from the processes

Cross verification of information

Easy access to inter-departmental data

Reduced requirements for verifications

Facilitates independent focus on Core Administration and the Services

introducing the following features in the administration organization :

Scope for innovations

Reform friendly

2.3 Service Levels

Service levels define the common understanding about the time taken for the delivery

of services. They may also specify the assigned priorities, levels of availability,

serviceability, performance and operations for each service. Along with an

understanding of the Business Process Reengineering, design of To-Be processes and

the BPR framework requires the proposed service levels to be defined clearly.

The e-District Guidelines clearly stress on establishing the service levels:

“The State shall prescribe the service levels for each of the services identified under

the project”.

The service levels have been proposed for each of the services within all the category

of services under e-District based on the envisaged business process re-engineering

framework and the overall technology architecture of the proposed service delivery

mechanism. As a way forward, the current processes have been benchmarked against

the relevant best practices and the existing service levels are compared with the

targeted ones. These studies help in identifying the gap between the targeted service

delivery envisaged and the existing scenario. This analysis will guide the redesign or

re-engineering of the pertinent processes.

The factors and dependencies that have been taken into consideration for proposing these

service levels are:

Type of verification required

Modes of authentication of the deliverable

Process Re-Engineering

Verification

The verification process can be classified into two categories based on the sources and

modes of verification:

Physical Verification

Physical verification involves the traditional method of verification which is currently in

practice. However, no service levels have been assured to the citizens for the completion

of physical verification.

As a way forward, the verification process has been defined and outlined to meet the

targeted service level of 5 days. The Lekhpal would visit the CSC twice a week, implying

that the collection of request would take 2 days at best, the field verification would

require 2 more days and the verification report can be submitted in another 2 days. Since

physical verification would be required for only those applications which cannot be

verified through databases or critical documents, the relative number of request would be

fewer which would also help in meeting the target service levels.

Non-Physical Verification

Non-physical verification would involve verification through vital databases like the

digitized Parivar register, the Electoral database, PAN card database, driving license

database, CIPA etc. This would reduce the verification time to 1 day.

Modes of Authentication of Deliverable

The service levels vary based on the modes of authentication of the end deliverable. For

instance, a digitally signed document, if made acceptable can be delivered to the citizen

within 1 day. However, a manually authenticated document would require 2 days taking

into account the time taken for the physical movement of the document.

Process Re-Engineering

Once the processes are re-engineered and workflows are defined, significant time can be

reduced for the delivery of the service. For instance, a payment gateway at the CSC for

the payment of Taxes etc. would significantly save the taxpayer the time and effort

involved in the payment of taxes.

The below mentioned service levels have been finalized based on the Annexure III of the

e-District Guidelines and the discussion held with the State Government representatives at

Lucknow on November 7, 2007, in concurrence with the District Administration

representatives.

COMPONENTS SERVICE SERVICE LEVEL MODE OF VERIFICATION

Caste Certificate Obtaining Caste Certificate

2 Days Digitized Parivar Register, Automated

workflow

7 Days Physical Verification

Birth Certificate Obtaining Birth Certificate

2 Days

Digitized Parivar Register, Automated

workflow, Certificate from the Medical

Institution


Death Certificate Obtaining Death Certificate

2 Days

Digitized Parivar Register, Automated

workflow, Certificate from the Medical

Institution


Income Certificate Obtaining Income Certificate

2 Days Digitized BPL List, Access to PAN data


Domicile Certificate Obtaining Domicile Certificate


workflow



Old Age, Widow,

Handicapped Pension

Sanctioning & Approval 2 Month Increased Gram Sabha and Gram

Panchayat meetings

Disbursement 2 Month None

Property Tax Payment Online Payment Gateway

Khatauni Issuing of Khatauni

Online Unsigned

2 Days Signed

Employment Exchange Registration Online Online Access

PMRY

Registration Online None

Information Dissemination Online Online Access

Interview 2 Days Availability of te interview panel

SGSY

Information Dissemination Online Online Access

Request for Appraisal Online Online Access

Revenue Court Daily Cause list Online Will include details upto previous

working day


Copy of final order Online Online Access

Case Status Tracking Online Online Access

Ration Card

Issue of Ration Card

1 Day Digitized Parivar Register, Automated

workflow


Updating/Modification on Ration

Card


workflow


Grievance

Information dissemination Online Online Access

Filling of Grievance Online Online Access

Status Tracking Online Online Access

RTI Filling fo RTI Application Online Online Access

Police Department

Status tracking of a case Online Online Access

Character Certificate 7 Days Physical Verification


Recovery Certificate

Issue of RC Online Digital Signature, Online Access

Monitoring of RC Online Online Access

Status Tracking Online Online Access

Electoral Services Application for addition on name

on the Voter list 1 Day

Applicant DB supporting Barcode,

Election Commission

Application for modification of

details on voter list 1 Day


Election Commission

Application for deletion of name

from voter list 1 Day


Election Commission

Part III Service Components

BPR, „To-Be‟ & FRS Report UP e-district

33

3.0 Service components

3.1 Information Dissemination component

The information component is envisaged for handling the dissemination of

information only since the lack of information was found to be a key

impediment in availing of services on time and with minimum effort. It has

been observed that lack of information regarding the processes and the

supporting documents that needed to be submitted along with the application

are two of the prime factors stalling the submission of application. Similarly,

lack of awareness about the defined service levels among the citizens results in

no appropriate action being initiated even in case of deviation.

Citizen Relevance

Expedite the application procedure since all the requirements would be

clearly indicated to the applicant.

Reduce the effort required for an applicant to avail a service by

eliminating the need for making multiple visits to the service centers for

collecting information regarding the service owners, the supporting

documents etc.

Aids in disseminating information regarding any citizen welfare centric

government schemes.

The channels of delivery for this component and the centres of responsibility

for each of those channels are as enumerated below:

Channel of Delivery Description

Online All the relevant information will be posted

online on the website which can be

accessed from anywhere

Interactive Voice Response System

(IVRS)

A telephonic service which would give all

the details regarding each service


34

Public Display Boards with all the information painted on

them will be displayed at the village,

block, CSC and Tehsil levels

The key challenges seen for this component relates to information originating at both

state level and district level and their integration so as to account for consolidated

view of service delivery of the component. A responsibility center for updating,

validating and authenticating information needs to be stated. It also means that

provision for updating and uploading the information from the district level needs to

be made in the e-district application.

Legal challenges:

Legality of information provided on the website?

Process related challenges:

Who will be responsible for the content?

How will the updates to the content be managed?

Technology related challenges:

None

The NIC Office or the District Information Officer will accept only duly signed

documents from the authorized persons in various departments for updating on the

website. We can also have an appropriate disclaimer on the home page of the

website.

The various head of departments or the authorized persons in those departments will

draft the content and be responsible for the same.

The following process flow demonstrates how the updates to the content would be

managed.


35

Information Dissemination Component C

itize

n D

istr

ict P

ublic

Info

rmat

ion

Offi

cer

NIC

E

Dis

tric

t App

licat

ion

Dep

artm

ent (

Dep

t. H

ead)

No

Yes

Presents

information

update to the

Dept. Head

Receives notification for

verifying the updated

information and

approving the same

Forwards the

document to NIC and

District Information

Officer - Physically

Stop

Allows NIC official to

update information over

the application and

notifies Department

Head for approval

Start

Rejects updation and

updates e district

application about rejection

details

Hosts information

digitally signed by

the Dept. Head

Updates the

information on e-District

application

Logs in to the e

district

application

Reviews

information

update

Ensures dissemination of

information through the

identified channels

Receives the

document with

required updates

Receives Information

updates

Approves updations by

digitally signing them

Prepares

document on

information to be

spread amongst

the citizens

Satisfied

Receives the document

with required updates

Updates rejection

details and notifies

NIC

Makes necessary

changes


36

Sr. Process Detail Responsibility

1.

The department head of the department which wants to

disseminate information prepares a base document

containing the relevant information.

Department

2.

Department identifies the source through which it wants to

disseminate information which can be either :

e-District website

Public Display

Both

The department then sends the document prepared by its

officials to NIC officials if they identify e district website

as a source of information dissemination.

Or to the District Information Officer if the department

identifies public display as the medium of information

dissemination.

The department can also identify both the above methods

as sources of information dissemination.

Department

3

In case when the department identifies e district or other

government website as source of information dissemination

then the NIC officials receive the documentation regarding

the information dissemination from the particular

department.

NIC Officials

4

The NIC official then updates the information over the e

district application and puts his digital signature on the

updation

NIC Officials

5

e District application hosts the information updated by the

NIC officials and automatically generates an email

notifying the Department Head of the particular

department to review the information

E District

Application

6 Department head receives notification from the e District

application about the information updation Department Head

7

Department head logs in to the e district application

through his user id and password and looks for particular

update on the e district application.

Department Head


37

8 E District application presents the particular piece of

information to the Department Head.

E District

Application

9

The Department head reviews the information updated

over the e district application and takes the following

decision:

i) If the Department Head finds that the information

updated over the e District application is correct in

all manners and can be catered to the citizens then

he approves the information update by using his

digital signature.

ii) If the Department Head feels that the information

hosted over the e District application is not

sufficient, incomplete or not passing on the message

clearly. Then he can reject the information update

and ask the NIC to revise the information update

along with providing changes required in the current

information update.

Department Head

10

i) In case of acceptance of Department Head e District

application hosts the information over it digitally

signed by the Department Head.

ii) In case of rejection the e district application

notifies rejection details to NIC

E District

Application

11

In case of rejection NIC officials receives the notification

and makes the necessary changes and updates the e

district application

NIC Officials

12

In case the department wants to disseminate information

through public display then the District Information Officer

receives information document from the department head.

The District Information officer then identifies the location

as well as sources of information dissemination of public

display. The DIO then disseminates the information through

the identified sources.

District

Information Officer

13

The Citizen can then obtain the information through which

ever medium he wants to obtain such as i.e. either through

public display or through the e district portal or both.

Citizen


38

S. No. Functional Requirements - Information Dissemination Component

1. Should allow only the NIC / Department officials to update information

obtained from the departments

2.

Should provide detailed information on the following to the user:

Scheme Name:

Eligibility Criteria:

Nodes of obtaining service:

Application Fees:

Grievance filing procedure:

Authorities to contact:

Forms and documents required:

Other locations for obtaining detailed information

3. Should be able to add new information components besides the above

4. Should be accessible to citizens, department officials, other

government officials, e district centre operators, SCA

5.

The NIC should be able to update the document over the e district

application but this information would not be viewable to the end user

until the department head puts his digital signature verifying its

authenticity and correctness

6. Should not allow any un authorized user to upload information besides

NIC officials

7. Should have different presentation layer for each set of users i.e.

Information seekers, updaters, approvers etc.

8. Should notify the Department Head once the information is updated

over the e application

9. Should allow the Department Head to either approve or reject the

information update

10.

Should update information over the e district application only after

digital signatures of the department head has been put up on the

information update

11. Should ask for digital signature of the department head in case of

rejection also

12. Should ask for changes from the Dept Head desired in case of rejection

by the department head

13. Should notify the NIC officials both in case of acceptance or rejection

of the information update

14. Should allow only the NIC officials to make changes in the updated

information hosted over the e district application


39

15. Should request NIC official to put his digital signature after each

updation

16.

Should have a counter at the bottom of the page to record the number

of people hitting the website, this would prove beneficial in capturing

the usefulness of information

17. Should auto generate grievances in case of Department Head or NIC

officials are not performing against their set SLAs

18.

The system should support multi-lingual interface (minimum Hindi and

English) as per localization and language technology standards for

National e-Governance plan defined in the e-District guidelines


40

3.2 Forms availability component

Service inputs are accumulated with the aid of various Forms. Forms could be in

physical or non-physical format. Forms in both formats consist of various fields of

required information, which would be the basis for any process to be initiated. In

physical format, form availability becomes an important consideration as this can

depend on a variety of external factors. Lack of availability of forms would impede the

process. Non-physical or electronic forms would address the lack of availability issue

and would standardize the fields using a system approach.

Form availability would ensure that the services can be accessed. Forms once

available with the appropriate fields will not only form the basis for accessing any

particular service, but would also be used in creating an incremental database.

The purpose of the element as envisaged in the proposed BPR framework has been

listed below –

1. To make available the relevant form available for making service request for

the selected services

2. To standardize the format for the form pertaining to selected services

Citizen Relevance

Easy availability of form at multiple locations and through multiple channels

Standardized format of forms removing confusion of applicability and

genuineness of form

Channels of Delivery

The channels of delivery for this service are:

Channels of Delivery Description

Service Delivery Point

(CSC / Block office /Tehsil office)

As defined in the CSC TOR

Online Software application should

integrate features for capturing

required information for such

transactions


41

The key challenges seen for this component relate to form availability and their

integration so as to account for consolidated view of service delivery of the

component.

Legal challenges:

None


How will it be ensured that only the latest forms are available?

Technology challenges:

None

Various head of departments or authorized persons of those departments will

make sure that any change in the Performa of the form is immediately notified to

the NIC DIO and the District Information Officer, who will then manage the

updation of the form.


42

Form Availability Component

Citi

zen

N

IC

E D

istr

ict A

pp

lica

tion

D

ep

art

me

nt (D

ep

t. H

ea

d)

No

Yes

Displays the

updated Form to

the Dept. Head

Receives notification

for verifying the

updated Form and

approving the same

Forwards the

document to NIC

Physically

Stop

Saves the online

Form and its PDF

version and notifies

Department Head for

approval

Start

Rejects the updates

and provide comments.

Makes the new

Form available

online

Updates the online

Form and the PDF

version on the e-

District application

and website

Logs in to the

e district

application

Reviews

information

update

Form can be

downloaded

Approves the

updated Forms by

digitally signing

them

Prepares required

performa of the form

to be made available

to the citizens

If

Satisfied

Receives the

document with

required updates

Updates rejection

details and notifies

NIC

Makes necessary

changes


43


1 Performa of the required form is prepared

Respective department

(Head of department,

HoD)

2 Prepared performa is forwarded to the NIC

office

Respective department

(HoD)

3

The received performa and detail is updated

on the e-District application (eDA) and portal

in the PDF format

NIC Officials

4 Updated performa and details are saved in the

system eDA

5

e District application hosts the information

updated by the NIC officials and automatically

generates notification to the Department Head

of the particular department to review the

information

eDA

6

Department head receives notification from

the e District application about the information

update

Department Head

7

Department head logs in to the e district

application through his/her user id and

password and looks for particular update on

the e district application

Department Head

8 e-District application presents the particular

updated performa to the Department Head E District Application

9

The Department head reviews the performa

updated over the e district application and

takes the following decision:

iii) If the Department Head finds that the

performa updated over the e District

application is correct in all manners,

approval of the performa update is done

and is digitally signed

iv) If the Department Head feels that the

performa hosted over the e District

application is not sufficient, incomplete

or ambiguous, he/she can reject the

Department Head


44

updated performa and ask the NIC to

revise the format along with providing

changes required in the current updated

format

10

i) In case of acceptance of the updated

form by Department Head, the same is

hosted over the eDA portal

ii) In case of rejection the e district

application notifies rejection details to

NIC

E District Application

11

In case of rejection NIC officials receives the

notification and makes the necessary changes

in the performa and updates the e district

application

NIC Officials

12 Latest form can be obtained through the eDA

portal or at the CSC Citizen


45

S.No Functional Requirement Specification – Form Availability

1 The system should store all the service request form at predefined location for

the selected services

2 The system should be able to retrieve service request form from the predefined

location

3 The system should allow for service request form to be easily downloadable

both through HTML and word format

4 The system should provide for printable version of the service request form

5 The system should give an error message in case it is not able to retrieve the

application from the given location

6 The system should have a provision for uploading new version of the forms as

and when it is required to change the version

7 The system should maintain the version control for the service request form

8

The system should have a security feature embedded for changing the version

of the form and should allow only predefined process owners to change the

form version

9 The system should maintain log for all version change with the details of the

process owner making version change

10 The system should not allow to change the content of the form and should be in

read only version

11

The system should be able to make available service request form should be

through

Online / website

CSC

12 The system should allow for easy searching of the service request form

13 The system should allow for easy and user friendly layout for locating the

service request form

14 The system should be able to export forms in multiple formats so as to ensure

compatibility of forms

15 The system should have a life counter feature to keep track of number of forms

being downloaded from the application

16

The system should support multi-lingual interface (minimum Hindi and English)

as per localization and language technology standards for National e-

Governance plan defined in the e-District guidelines


46

3.3 Application receipt Component

This Component will handle submission of the application. As the component exits

operation, an acknowledgement would be generated for the applicant containing a

unique reference ID for status tracking, date of application, department responsible,

date of delivery, information about delivery channels, service fee receipt etc. The

receipt also helps the applicant to track the status of the application with the help of

the unique registration number provided with the receipt besides enabling the system

to uniquely identify each and every application along with the candidate. According

to BPR framework this receipt would be automatically generated by the system thus

minimizing the duplication of effort and redundancy in the process.

Citizen Significance

Proof for service request being made by the citizen getting established


The channel of delivery as envisaged for the service component is listed below in the

table –

Channel of Delivery



(CSC / Block office /tehsil office)

Service delivery point to register

service request and provide a

unique service request number

against the service request made

The key challenges seen for this component relate to application receipt and their

integration so as to account for consolidated view of service delivery of the

component.

Legal challenges:

Legal requirement of applicant‟s signature on the application form

This challenge can be managed by taking the applicant‟s signature or his thumb

impression on a filled-up printed hard copy of the application form and then

dispatching it to the district office.


47

Legal issues in the Kiosk operator digitally signing the application on behalf of

the applicant.

Legal validity of acceptance of e-Forms

Process and Technology related challenges:

Authentication mechanism for the kiosk operator

Changes to the State IT Act may be enacted to authorize the Kiosk operator to

digitally sign the application on behalf of the applicant.

The draft policy on e-Forms is currently in its initial stage as the e-District

guidelines. More information on the same is sought from the State.

The Kiosk operator would be required to establish his identity to the e-District

Application by using strong authentication mechanism. The operator would

require a UserID, Password and his Biometric information. The same is illustrated

as a process flow below:


48

Application receipt

e-D

istr

ict

Ap

plic

atio

nA

pp

lica

tio

nC

SC

/ S

uvid

ha

Ce

nte

r

Travels to the

CSC / Suvidha

center.

Submits his

request to the

Operator

Receives the

request and opens

the relevant

departments

application

Fills up the

online form for

the request and

takes a Photo of

the Applicant

Takes out a printout

of the completed

application form, and

asks the applicant to

verify the details

If all details

correct

Signs the form

using his digital

signature, and

submits it to the e-


Issues a copy of

submitted

application

along with a

receipt to the

applicant

Signs or Puts the

Thumb impression on

the hard copy and

gives it back to

operator along with

required fees

Schedules the

Hardcopy for

daily dispatch

to Tehsil or

BDO.

No YesReceives a

copy of

application and

a receipt

Loads the online

application form and

assigns it a Unique

Application number.

Sends the Application

to the selected authority

and generates a receipt

Proves his

Identity using

any ID Proof

with a Photo

Operator logs

into the e-

District

Application

using

Username,

Password and

Biometric

identity

StartStop

Imprints the Unique

Application number and

the ID details of the CSC

operator on the form and

saves it in the database


49

Sr. Process Description Responsibility Centre

1 The Applicant travels to the CSC or any e-District center/kiosk. Applicant

2

The Applicant submits his request to the operator sitting at the CSC

or the e-District kiosk. He may do this either by filling out a

hardcopy of the form himself or by verbally requesting for a

particular service and provided all details to the operator as he fills

up the form on the applicant‟s behalf.

Applicant

3

The Applicant will prove his identity using any of the valid ID proofs

issued by any Governmental agency, for example Voter ID card,

PAN card etc.

Applicant

4 The operator Would log into the system using his username and

password and authenticating his biometric identity to the system. Center operator

5 The operator will check the ID proof provided by the applicant to

ensure the identity of the applicant Center operator

6 The operator will receive the application request and select the

relevant department‟s section on the application. Center operator

7

The e-District Application (eDA) would then load the requested

service‟s Application Form and assigns it a Unique Application

number

e-District Application

(eDA)

8

The operator then fills up the online form on behalf of the

applicant and takes a photograph of the applicant by a Webcam.

This photo is attached to the Application Form.

Center operator

9 The operator then takes out a printout of the filled up Application

form and asks the Applicant to verify the details mentioned on it. Center operator

10 The Applicant inspects the details printed on the Form, and points

out if there is any discrepancy Applicant

11

If the Applicant wants something to be changed in the form, the

operator will discard the Printed form and make the changes on the

online form and repeat the process until the Applicant agrees with

the printed copy.

Center operator

12

The Applicant, when satisfied with the contents of the printed

Application Form, signs on it or puts his thumb impression on it,

and hands it back to the operator along with copies of any required

Applicant


50

Sr. Process Description Responsibility Centre

documents

13

The operator on receiving a manually signed printed copy of the

form and the copies of the documents, digitally signs the online

form and submits the same

Center operator

14 The eDA Imprints the Unique Application number and the ID details

of the CSC operator on the form and saves it in the database. eDA

15 The eDA then sends or forwards the Application to the selected

authority and generates a receipt for the Applicant eDA

16 The operator takes a printout of the receipt and issues the same

along with a copy of the application to the Applicant Center operator

17 The Applicant receives the receipt and the printed copy of his

application Applicant

18

The operator schedules a Daily dispatch of the hard copies of the

Application forms and the associated documents‟ copies to the

respective department‟s office

Center operator


51

Service Request Form – Application Receipt Component

The „Home‟ page or the Main page after logging in will have multiple options for the

operator / applicant to select. The operator should be able to load the Application Forms

for any of the services being offered under the e-District project.

The operator / applicant will have the following Links and Sub-Links to choose from:

S.No Fields Description of the form

1. Certificates

Caste Certificate

Domicile Certificate

Income Certificate

Handicapped Certificate

Birth Certificate

Death Certificate

2. Revenue Court

Status of a case

Cause list

Final orders

3. Utilities

Payment of Property Tax

4. Copy of Khatauni

5. Ration Card

New APL Ration Card

o Urban

o Rural

New BPL/Antodaya Ration Card

o Urban

o Rural

Modification in existing Ration Card

o Urban

o Rural


52

Surrender of existing Unit/Ration card

o Urban

o Rural

Duplicate Ration Card

o Urban

o Rural

6. Pensions

Old age pensions

Widow pensions

Handicapped pension

7. Dues and Recovery

Issuance a Recovery Certificate

Status tracking of an Recovery Certificate

8. Election Related services

Add a new name to electoral rolls

Update existing information

9. Employment related services

Employment Exchange

SGSY

PMRY

NREGA

10. Grievances

Register a New Grievance

Status of Grievance

11. RTI Application

12. Police

FIR Status tracking

Character Certificate


53

S. No. Functional Requirements – Application Receipt component

1. The System should enforce secure login as per the Login process, where

the CSC or e-District center operator will have to authenticate his

Username, Password and Biometric identity to access the Application

home page.

2. The System, on successful login, should display the Main page or the

Hoe page of the Applications Services Request with links to various

services as per the Service Request Form mentioned above.

3. The System should be able to retrieve and load the online Application

Form for the service as selected by the Applicant / Operator.

4. The System should assign a Unique Application Number to every form.

5. The System should allow the Operator / Applicant to take a printout of

the form before submitting it.

6. The System should allow editing of the details in the online Application

form even after a printout has been taken.

7. The System should allow the Operator / Applicant to attached any

scanned documents, a photograph, or any other supplementary

attachments as required with the Application Form

8. The System should imprint the Unique Application Number and the ID

details of the operator on the Application Form.

9. The System should allow the operator to submit the Application Form online

10. The System should enforce that the operator digitally signs the Application

Form and all its associated attachments before accepting it for submission.

11. The System must display a message for Successful or Unsuccessful

submissions and it should log all such events.

12. The System must refresh the page and Load a new Application form in

case the previous submission attempt was unsuccessful.

13. The System should save the Application Form and all attached

documents into a Database.

14. The System should be able to immediately electronically forward the


54


Application Form and the attachments and notify to the Process Owner, as

identified in respective processes.

15. The System should be able to generate a Receipt for the Applicant, and allow

it to be printed.

16. The system should support multilingual interface (minimum Hindi and English)

as per Localization and Language Technology Standards for National e-

Governance Plan defined in e-district guidelines.

17. The e-District Application must support Digital Signatures of any of the

Certifying Authorities registered under the Controller of Certifying

Authorities, and must be modifiable as per the changes made by the

respective Certifying Authorities on the structure of the Digital Signatures

issued by them.

18. The Digital Signatures used and the e-District Application must provide the

Time Stamping of the act of Digitally Signing a document as mandated by the

IT Act 2000.

19. The Smart Card reader or the USB Token, carrying the Private/Secret Key,

must be activated by Biometric identification instead of a PIN / Password

based system.


55

3.4 Payment component

Payment element of the proposed framework will define the overall process of

payment for the selected services under the e-district project. It will account for the

flow of funds from the collection points (i.e. CSC) to the concerned departments

where the payment needs to be deposited.


listed below –

1. Provide secured and trusted process of payment collection and deposit in the

concerned departmental head for the selected services

2. Ensure exact payment by the citizen as defined for the service


Ease of payment through location in proximity

Allow payment of prescribed amount by the citizen for which receipt is provided

against the service request made at the service delivery centers (eg. CSC)

allow citizen provision of including the payments made at other financial

institution through the application


The channels of delivery for payment elements as envisaged in the framework is given

in the matrix below –

Channel of Delivery



(CSC / Block office

/Tehsil office)


Banks Software application should integrate features for

capturing required information for such transactions

Online Software application should integrate features for


The key challenges seen for this component relate to payments and their integration

so as to account for consolidated view of service delivery of the component.


56

Legal challenges:

Authorization of Kiosk operator to collect fees for various services.


Revenue sharing model for chargeable and non-chargeable services.


A payment gateway would be required for online transfer of collected fees or

charges.

An agreement may have to be signed between the Kiosk operator/owner and the

State Government which would have details of revenue sharing model. Utility

services covered under e-District fall under the purview of Municipalities and the

CSCs will need to be empowered to collect dues on their behalf

Case studies of other such projects are being researched to develop a revenue

sharing model, which would incorporate such conditions. The process for such a

payment mechanism may be divided into two categories. One would be for

privately owned centers and the other would government own centers:

NIC already has a payment gateway developed. Tie-ups with a bank with CBS can

also be explored.


57

Payment Mechanism e District Centre

Cen

treD

epar

tmen

t E

Dis

trict

App

licat

ion

App

lican

t

Issues daily report for

the number of

transactions

Issues

Acknowledgement

Receipt

Receives payment

against the

transaction from the

SCAReceives daily transaction

details

Registers

transaction

Receives payment

fees from the

citizen

Makes transaction

Deposits collection

charges after reaching a

particular amount in

various department heads

Prints

Acknowledgement

Receipt

Issues receipt to

applicant

Requests service

Receives

Acknowledgement

receipt and makes

payment

Start

Stop


58

Payment Mechanism (Via cards) D

ep

art

me

nt

Pa

yme

nt G

ate

wa

yE

Dis

tric

t A

pp

lica

tion

A

pp

lica

nt

Start

Stop

Enters registered

user id and

password onto

payment module

System returns

payment details

against the

particular record no.

Views the payment

details and enters

the payment

gateway option

Select particular

service for which

payment to be

made

Matches

payment details

with the amount

deposited

Search for particular

payment record based

on unique registration

id

Process applicant

query and returns

e district website

Registers the payment

details and money

gets transferred in

departments accounts

System

authenticates

user and allows

to enter

System registers

applicant user id

and password

and sends

confirmation

Logs on to

payment module

and applies for

user id and

password

Makes online

payment through

debit card or credit

card

System returns

payment

gateway optionSystem returns

the particular

service request

Receives bill

and logs on to

internet and

requests for e-

district website

System updates

transaction details and

forwards to concerned

department

Receives payment in

the bank account

against the

outstanding amount

Receives

notification about

the payment

details

Issues utility bill

to the applicantBill generation


59


Payment Mechanism through e-district centre

1. Applicant makes a service request at any of the e district centres

Applicant

2.

Centre operator receives the application request and makes the transaction at the e district application

Centre Operator

3. The e District application registers the transaction E District Application

4.

E district application issues an acknowledgement receipt against the transaction made specifying the applicant‟s name, registration number, details of service requested, date of issuance of receipt, expected date of receiving the service


5.

The centre operator takes a printout of the acknowledgment receipt and request for payment from the citizen in lieu of the service

Centre Operator

6. The Citizen makes the payment against the service availed to the centre operator Applicant

7. The Centre operator collects the service fees from the applicant Centre Operator

8.

The centre operator deposits the collected amount under the different department heads in the department‟s accounts

Centre Operator

9.

The e district application sends the details of the daily transactions of each and every centre to the department

E District application

10.

Department receives payment from the e district centre and matches the transaction details with the collected amount deposited by the kiosk operator

Department

Payment Mechanism through Financial Instrument (Credit/Debit cards)

1 Department issues utility bill to the applicant Department

2 Applicant receives utility bill and logs onto internet and request for e-district website Applicant

3 EDA process applicant query and returns e-district website

E-district application


60

4 Applicant logs onto payment module section and applies for UserID and password Applicant

5

E-district application registers applicant details and

creates new UserID and password. Upon creation,

the EDA sends confirmation to user for successful

creation of UserID


6 Applicant enters registered UserID and password

onto payment module section Applicant

7

E-district application verifies user id and password.

Upon verification, system allows authenticate user

to enter into individual payment service record.


8 Applicant would select payment details for which

payment is due Applicant

9

Upon receiving applicant request, e-district

application would return the payment details for

which payment is due


10 Applicant would search his transaction details based

on his unique bill no printed on his utility bill Applicant

11 E-district application shows the payment details

based on the applicant query (utility bill no) E-district

application

12

The payment details are shown onto e-district

application based on the bill generation by

concerned department. The department would

update individual payment service utility record

with following details

Utility bill no

Name

Amount

department

13

Applicant view the payment details generated for

the particular bill and click to enter into payment

gateway option Applicant

14 E-district application returns the particular payment

gateway option selected by the applicant E-district

application


61

15

Applicant fills the detail of financial instrument

(credit or debit card) being used for making the

payment Applicant

16

Payment gateway registers the payment details

submitted by applicant. The applicant account is

debited and simultaneously credited into

government account. Upon successful transaction,

e-district application is updated

Payment gateway

17

E-district application updates individual payment

service record and notifies concerned department

about transaction details


18

The concerned department receives notification and

payment amount. The department verifies the

transaction details submitted by applicant Department


62

Sr. Functional Requirement Specifications – Payment through e-district

centre

1 The system should provide for and allow financial transaction functions

2 The system should check for all details of the service request form before

initiating the payment

3 The system should enable the payment option only when all the fields of

service request forms are filled

4 The system should return back and highlight the field which have

inconsistencies / error for user to rectify the error

5 The system should retain all the information of the service request form

besides those having inconsistencies

6 The system should return back after successful checking of the fields with

the prompt of confirmation to open the payment page

7 The system should open a new page for recording payment details against

the service request

8 The system should allow payment to be registered on the service

application request against the following –

Payment against the service

Payment against the dues / payments as defined under service charter

of the specific service

9 The system should record and maintain all details of payment against a

unique service application number

10 The system should be able to maintain all the payment records in a

database and retrieve the same as and when record

11 The system should be able to open a page with declaration on successful

payment output

12 The system should able to record specific payment details on the service

request form after successful payment has been made

13 The system should be such that it should allow for part payment function

14 The system should be able to retrieve information of first part payment

during the final delivery of service output for final payment as per the

overall payment specified for service request

Unique application number for requested service

CSC details and unique number for CSC

15 The system should be able follow the payment cycle as mentioned above


63

for the final payment also

16 The system should be able to maintain all records of part payments as well

as consolidated payment amount against the service request

17 The system should support multi-lingual interface (minimum Hindi and

English) as per localization and language technology standards for National

e-Governance plan defined in the e-District guidelines

Only for utility services (bill payments, etc.)

1 The system should allow transaction through approved financial instruments

Credit cards

Debit cards

2 On-line payment – The System should support online payment, including the

following fields:

Facilitate payment against dues and recoveries online through a payment

gateway interface with a bank.

Allow the user / customer to make payment only till the last date of

payment has not passed.

Facilitate automatic updation of the information on the applicant

record, upon realization of the submitted money

3 The payment function should be against specific invoice / bills for the given

services

4 The system should ask for the final confirmation from user before initiating

payments function

5 The system should allow for user re-verification before initiating payment

function through transaction unique ID allocated to the user

6 The system should provide for migration to a secure payment gateways from

the portal in a secured manner

7 The system should allow predefined data / information to be provided to

payment gateways

8 The system should be able to generate unique ID codes for every transaction

9 The system should be able to correlate and confirm

User data / information through unique ID code generated

Payment gateway data information through Unique ID code

10 The system should provide for confirmation of transaction to the use

11 The system should provide for payment receipt against the payment


64

12 The system should provide printable version of receipt

13 The system should not store any critical information of the user provided on

the secured payment gateway

14 The system should allow for data / information transfer / flow to e-district

application

15 The system should facilitate automatic updation of the information on the

applicant record on successful payments made

16 The system should not allow any initiation of payment function beyond

prescribed days limit for transaction

The system should be able to provide user friendly information for such

transactions

17 The system should not allow for initiation of payment in case of non

availability of records of invoice / bills against which payment function is

initiated

The system should be able to provide user friendly information for

such transactions

18 The system should provide for database security

19 The system should provide for application security

20 The system should provide user friendly information wherever required

21 The system should produce alphanumeric code for confirmation and

verification for manual user Vs. computerized payments

22 The system should follow predefined payment rules and regulation as

defined from time to time in the e-District application

23 The confirmatory receipt issued should have a unique registration number

against the transaction

24 The system should maintain records of such transaction for users accounts

respectively

25 The system should allow for printable version of the confirmatory receipt

for all such successful transactions.

25 The system should be able to send emails on registry value of the user

account on the payments.

26 The system should maintain all information and records of user transaction

tagged to the user account and also provide for viewing of such information

as and when required by the user

27 The system should not allow any changes to be made by the user into the

following –


65

Past records

Ongoing transaction once confirmation on initiation of such a

transaction is given by the user

Any values maintained for such transaction

28 The system should be compatible for easy integration with accounting and

financial application either inbuilt at a later stage into the portal or

external with a interface with the portal





66

3.5 Verification Component

Verification component of the BPR is going to deal with the authentication of a

particular service request. Verification process would ensure that no counterfeit or

frivolous applications are lodged in to the system also it will help to identify and

validate the right beneficiary availing the services. Verification also helps to establish

that the application meets the regulatory and the service requirements.

The verification components envisaged in the BPR report can be broadly categorized

under two categories:

a. Physical Verification

b. Non Physical Verification


There are certain cases where documentary proof doesn‟t suffices the requirement of

proving an applicant genuine for availing the benefits of a particular service. In these

cases physical verification is the only medium to prove the genuineness of the

individual and to validate the information supplied by him in the application. Though

physical verification is a costly and time consuming mechanism for proving the

genuineness of a particular individual but it also helps to capture the correct

information at the particular moment of time. Whereas the non physical verification

does not guarantees any change of information from date of last updation.

Non Physical Verification

Non physical verification component is going to deal with all such components that

help to validate applicant‟s genuineness and the benefits accrued by him by

presenting the same. This kind of verification facilitates the non-presence of the

applicant at the time of service avail ness. It also saves applicant time, money and

efforts to be present at the location for physical verification.

Non physical verification can be carried out with the help of the following means:

a. Database

b. Documents proof


67

Using Database: The non-physical verification can be carried out using validated

databases; these databases can help to validate the applicant by matching the details

provided with the information stored in the database. These databases eliminate the

need of physical verification that was previously carried out to validate the

information provided by the citizen. The information that would be fed into the

database would be validated, cross checked and entered by the department officials

that are managing the database.

Documents Proof: Authentic documents / copy of authentic documents signed by

authority holding important designations can also work as proofs against the physical

verification. These documents prove that the applicant is genuine and he is the same

person as proved in the documents.

Department Significance

Non Physical Verification

This kind of verification removes the necessity of physical presence of applicant which

was considered previously sacrosanct for availing services. Non physical verification

also saves a lot of time, money and other resources both for the applicant as well as

the decision making authority.


Physical verification helps to capture the correct information at the particular

instance of time thus justifying the time and efforts put in to carry out the verification

process. Also helps as an input for creating tools to carry out non physical verification.


The channels of delivery for this service are:



providing and capturing required information for

physical verification and also allow for non physical

verification against authenticated database


68

The key challenges seen for this component relate to verification and their integration


Legal challenges:

Provision for allowing decisions to be made based on Databases.


Any physical verification by a field officer must ensure that he verifies and

records all information for e-District Database for all family members in one

visit.


Interconnectivity and accessibility between various databases of different

departments

Backups and security of the master database

A change in the State IT Act would be required to recognize digitally signed databases

as legally admissible sources of information.

The field officer will be provided with a checklist of the details he needs to verify and record. These details will then be committed to the e-District Database and digitally signed by the field officer. The same is demonstrated, highlighted by blue

dotted lines, in a draft To-Be Process as below:

A gateway or an interface can be developed which would facilitate retrieval and

saving from and to these separate legacy databases.

The database server would be maintained in a secure environment and automatic

backups would be scheduled.


69

Verification

e-D

istr

ict

App

licat

ion

Fie

ld O

ffice

rP

roce

ss O

wne

r

Returns the

results of the

query

System notifies the

Field Officer of a

Pending Inquiry

Checks the details

of the applicant in

the relevant

databse

Details FoundApproves the

application

Orders a physical

verification

Yes

No

Submits the

application back

with the verified

details

Physically visits and

verifies details. Enters

these details into the

Department’s Database

Receives the

application.

Details

Correct?

Yes

No

Saves the

details in the DB

and Notifies the

Process Owner

Start

Stop

Rejects the

application


70

Sr. Process Description Responsibility

Centre

The Process Owner, on receiving the Application, queries the e-

District Application (eDA) to verify the claim of the Applicant. Process Owner

The eDA then queries the respective Database(s) and displays the

results to the Process Owner.


(eDA)

If the details of the Applicant are found, then the Process Owner

inspects the details in the Database against the details provided

in the Application.

Process Owner

If the details are correct, the Process Owner approves the

application, as per the Approval Component Process Owner

If the details of the Applicant are not found in the Database, then

the Process Owner orders a Physical Verification and

electronically, using his digital signature, forwards the

Application to a Field Officer.

Process Owner

The Field Officer then conducts a Physical Verification and saves

his findings in the Database and digitally signs the entry. Field Officer

The Field Officer then forwards the Application back to the

Process Owner electronically. Field Officer

The Process Owner then checks the Database again and either

approves or rejects the application as per the Approval or

Rejection components.

Process Owner


71


20. The System should be able to allow the Process Owner to enter query

parameters to search any Database connected with the System.

21. The System should be able to query the specified Database with the

specified parameters and return the result of the same to the Process

Owner.

22. The System should be able to retrieve various information from the

individual databases and aggregate it before displaying it.

23. The System should allow the Process Owner to electronically, using his

digital signature, forward / delegate the Application to a Field Officer

or any other Officer registered with the System.

24. The System should be able decode the digital signed data and display

the details of the signatory.

25. The System should allow the Field Officer to modify the Database as

per the Access rights defined in the CRUD Matrix for every service.

26. The System should allow the Field Officer to electronically forward the

Application back to the Process Owner after the details in the Database

have been updated.

27. The System should notify the Process Owner after the Field Officer has

marked the Application back to him.

28. The System should allow the Process Owner to either Approve or Reject

the application as per the Approval or Rejection component, using his

digital signature.

29. The System should ensure that a Reason for Rejection is entered by the

Process Owner if he selects to reject an application before accepting

the Rejection.

30. The System should log all the electronic movements of the application with

date and time details along with the sender‟s and receiver‟s information.




72







issued by them.



IT Act 2000.



based system.


73

3.6 Rejection Component

Rejection element of the proposed BPR framework is envisaged to meet all the

rejection related functions of concerned departments for the selected services under

the e-district project. This element allows for rejection of the service request at the

defined designated levels on the basis of the following reasons

(1) Pre-defined requirement/eligibility not being met in the service request

(2) Other reasons based on the discretion of the designated authority.

This element will also act as a precursor for providing stated reason for rejection to

the applicant. It will be mandatory for the department/designated authority to

provide a valid reason for rejection of the service request to the applicant. This will

ensure accountability and ownership in the system and will result increased

transparency.

The approving authority will use the established verification process for deciding about

the authenticity of the credentials given in the service request. It is envisaged that

once all the relevant citizen data is captured, verified and digitized, rejection process

will be linked through the database. The approving authority will use the databases to

decide whether the claim made in the application is correct or not. In case the claim

is found to be verified by the database, the authority would approve the application

using his digital signature.

The purpose of the rejection element as envisaged in the proposed BPR framework is

listed below:

1. Allow designated government official to reject service request in case prerequisite

conditions are not met along with the service request

2. Allow designated government officials to reject service request subject to their

best judgment and interest of the power vested in them by the government

3. Allow rejecting authority to provide reasons for rejection of the service request

(mandatory)

4. Allow requesting applicant / citizen to have valid reason for rejection of their

service request (mandatory)


74


The significance of the rejection element relates to the vested power of the

government on the concerned department for rejecting service requested based on

described qualifying criteria‟s relating to the selected services under the e-district

project.


The channels of delivery for monitoring and reporting elements as envisaged in the

framework is given in the matrix below –

Channel of Delivery

Channels of Delivery Remarks



The key challenges seen for this component relate to rejection and their integration so

as to account for consolidated view of service delivery of the component.

Legal challenges

Acceptance of Digitally signed rejections


To ensure that reason for rejection is provided before the process ends


None

A change to the State IT Act may be required to make the digitally signed rejections

legally valid.

The application will this feature where an application process will be considered

complete only if its approved or rejected with a reason.


75

Application Rejection

E-D

istr

ict

Applicati

on

Auth

ori

ty

Fie

ld O

ffic

er

Receives the

application

Checks the details in

the DataBase Details verified

Marks the application for

verification to Field officer

N

Details Found?

System registers the

change and notifies

Authority

Physically visits the

applicant to verify the

details

Updates the Department

Data Base with all the

recorded details.

Receives request from

authority to notify

Field Officer for field

verification

N

Receives the

application.

Returns the Query

results

YDetails

Incorrect

Y

Approval ApprovalN Y

Proposed online verification & rejection process

Rejects the

application

online using

digital sign

Start

Stop


76

S.No. Process detail Responsibility

1. The Approving official receives the application

requesting for a service

e-District

application (eDA)

2. As per the proposed online rejection and verification

process, details are checked in the database for

verification of credentials

Approving official

3. If details are correctly verified from the database,

the service request is approved Approving official

4. If the details are found but not verified from the

database, the service request is rejected Approving official

5. Rejected application is digitally signed along-with the

reason of rejection Approving official

6. If the details are not found in the database then the

copy is marked to the field official for verification

through the eDA

Approving official

7. eDA notifies the field officer about the pending

verification eDA

8. Physical verification is conducted Field official

9. Verification details are updated in the eDA Field official

10. The approving Authority/Official is notified about the

physical verification update eDA

11. Details are again checked from the eDA database Approving official

12. If details are still not verified then the service

request is rejected Approving official

13. Rejected application is digitally signed along-with the

reason of rejection Approving official


77

S.No. Functional Requirements Specifications - Rejection

1. The system should support multi-lingual interface (minimum Hindi and



2. The system should allow defined users to login to the system for reject the

service request based on rejection criteria as mentioned for the service

through a valid user ID and password

3. The system should show a login failure screen in case the user name and

password are not verified by the e-district application

4. The system should intimate the users through predefined channels for

pending service request application on a daily basis

5. The pending service request application should be highlighted for the

predefined process owners on entering the application

6. The pending applications should be intimated to the predefined process

owners through SMS on pre-defined intervals until the same is addressed

and closed by the respective process owner

7. The system should have a provision to mark the rejection of service

request

8. The system should have a provision where the predefined process owner

states the reason for rejection of the service request

9. The system should open a page with marked rejected application form and

text entry provision against all the rejected application form

10. The system should close the service request only and only once the text

box is filled

11. The system should be able to retrieve the closed rejected service request

on the new page for digitally signing it

12. The system should allow the user to digitally sign the document one by one

13. The system should also allow the user the digitally sign all the closed

rejected service request at one go

14. The system should open a page for all rejected service request with a

prompt of digital signature in form a button to initiate the process of

digital signing

15. The system should reconfirm from the user for initiating the digital signing

before actually initiating the process

16. Upon digitally signing the document, digitally signed document should be

saved in the given repository for future references and a hard copy of the

same document will be provided to the applicant

17. System should print the unique encrypted key/code on the hard copy of


78

the digitally signed document such that the same printed unique encrypted

key/code can be used to check the authenticity of the document. The

unique encrypted key/code will be information of the authority who

digitally signed the document in the encoded form

18. System should provide a link to the page where the user can enter the

unique encrypted key/code printed on the hard copy of the document to

check for the authenticity of the document

19. System should retrieve and display the digitally signed document on the

user screen once the user enters the unique encrypted key/code printed

on the document

20. System should not allow the user to make any alteration in the digitally

signed document or access the database only on entering the unique

encrypted key/code

21. System should display an appropriate message in case of retrieval failure

or any other communication failure or in case the document could not be

found due to any reason

22. The system should allow the user to terminate the rejection process at any

point of time during rejection

23. The system should keep and maintain the data in a data repository

(database) for all the rejection made

24. The system should be able to keep the records of all transaction performed

and link it to the unique code of digital signature

25. The system should open a page informing the user of successful completion

of rejection function

26. The system should open page at any point of process in case the process

termination with the request to restart the process

27. The system should not allow the user to initiate the process of digital

signature in case of no selection of pending service request for rejection

28. The system should not allow the user to modify the rejection once it has

been digitally signed

29. The system should not allow the user to delete any service request pending

for approval at his end


79

Document retrieval form – Rejection

The following fields would be displayed on the form:


1. Unique application reference id

2. Name of Applicant

3. S/o, D/o, w/o

4. Address

5. Caste (SC/ ST/ OBC/ General)

6. Date of birth

7. Service sought

8. Unique encrypted key/code


80

3.7 Approval component

Approval service component of the framework is envisaged to provide for mechanism

for approval of service request. It allows the concerned responsibility center to

approve the service request through a secured method. The approving authority will

use the established verification process for deciding about the authenticity of the

credentials given in the service request.

It is envisaged that once all the relevant citizen data is captured, verified and

digitized, approval process will be linked through the database. The approving

authority will use the databases to decide whether the claim made in the application

is correct or not. In case the claim is found to be verified by the database, the

authority would approve the application using his digital signature.

The purpose of the approval service component are enumerated below –

To allow the responsibility center to approve the service request

To integrate and embed secured process through which approval will happen

Departmental Significance

authority for accept service request and provide relevant output to the citizen as

required under the service request

allow only authorized person to use this feature thus maintaining sanctity of

authority to approve service request


The channels of delivery envisaged for the service component are –


Online Software application should integrate features

for allowing and authority for approving service

request


81

The key challenges seen for this component relate to approval and their integration so


Legal challenges

Acceptance of Digitally signed approvals


None


None

A change to the State IT Act may be required to make the digitally signed approvals

legally valid.


82

Application Approval

Fie

ld O

ffic

er

Au

tho

rity

E

-Dis

tric

t A

pp

lica

tio

n

Y

N

Y

NN

Y


change and notifies

Authority

Approves the

application

online using

digital sign

Rejection

Receives the

application.

Receives request

from authority to

notify Field Officer

for field verification

Details

verified

Physically visits the

applicant to verify the

details

Start

Proposed online verification & approval process

Stop

Updates the Department

Data Base with all the

recorded details.

RejectionMarks the application

for verification to Field

officer

Returns the

Query results

Details

Found?

Details

Correct

Checks the details

in the DataBase

Receives the

application


83

S.No. Process Detail Responsibility

1. The Approving official receives the application

requesting for a service eDA

2.

As per the proposed online approval and

verification process, details are checked in the

database for verification of credentials

Approving

official

3. If details are correctly verified from the database,

the service request is approved

Approving

official

4. Approved application is digitally signed Approving

official

5. If the details are found but not verified from the

database, the service request is rejected

Approving

official

6.

If the details are not found in the database then the

copy is marked to the field official for physical

verification through the eDA

Approving

official

7. eDA notifies the field officer about the pending

verification eDA

8. Physical verification is conducted Field official

9. Verification details are updated in the eDA Field official

10. The approving Authority/Official is notified about

the physical verification update eDA

11. Details are again checked from the eDA database Approving

official

12. If details are still not verified then the service

request is rejected

Approving

official

13. If details are verified, the service request is

approved

Approving

official

14. Approved application is digitally signed Approving

official


84

S.No. Functional Requirements Specifications - Approval

1. The system should support multi-lingual interface (minimum Hindi and

English) as per localization and language technology standards for

National e-Governance plan defined in the e-District guidelines

2. The system should allow defined users to login to the system for

approving the service request through a valid user ID and password

3. The system should show a login failure screen in case the user name and

password are not verified by the application

4. The system should intimate the users through predefined channels for

pending approval on a daily basis

5. The pending approvals should highlighted for the users on entering the

application

6. The pending approvals should be intimated to the users through SMS on

pre-defined intervals until the same is addressed and closed by the

respective process owner

7. The system should have a provision to mark the approval of service

request

8. The system should allow the user to digitally sign the documents one by

one

9. The system should also allow the user the digitally sign all the selected

approved service request at one go

10. The system should open a page for all approved service request with a

prompt of digital signature in form a button to initiate the process of

digital signing

11. The system should reconfirm from the user for initiating the digital signing

before actually initiating the process

12. Upon digitally signing the document, digitally signed document should be

saved in the given repository for future references and a hard copy of the

same document will be provided to the applicant

13. System should print the unique encrypted key/code on the hard copy of

the digitally signed document such that the same printed unique

encrypted key/code can be used to check the authenticity of the

document. The unique encrypted key/code will be information of the

authority who digitally signed the document in the encoded form

14. System should provide a link to the page where the user can enter the

unique encrypted key/code printed on the hard copy of the document to

check for the authenticity of the document


85

15. On clicking the link, system should display the fields as described in the

section Document retrieval form such that the user can retrieve the

required information

16. System should retrieve and display the digitally signed document on the

user screen once the user enters the unique encrypted key/code printed

on the document

17. System should not allow the user to make any alteration in the digitally

signed document or access the database on entering the unique encrypted

key/code

18. System should display an appropriate message in case of retrieval failure

or any other communication failure or in case the document could not be

found due to any reason

19. The system should allow the user to terminate the approval process at any

point of time during approval

20. The system should keep and maintain the data in a data repository

(database) for all the approval made

21. The system should be able to keep the records of all transaction

performed and link it to the unique code of digital signature

22. The system should open a page informing the user of successful

completion of approval

23. The system should open a page at any point of process in case the process

termination with the request to restart the process

24. The system should not allow the user to initiate the process of digital

signature in case of no selection of pending service request for approval

25. The system should not allow the user to modify the approval once it has

been digitally signed

26. The system should not allow the user to delete any service request

pending for approval at his end

Document retrieval form – Approval

The following fields would be displayed on the form:


1. Unique application reference id


3. S/o, D/o, w/o

4. Address


6. Date of birth

7. Service sought


86

3.8 Delivery component

The delivery service component of the proposed BPR framework relates to the delivery

/ collection of the service output for the service request made by the applicant. It is

envisaged that this component will detail out the specifics involved for service

delivery of the listed service under the e-District project. This will involve the use of

security features like digital signatures, passwords, etc to be employed for service

delivery at the front end where the citizen receives the output for the service request.


listed below –

1. To provide output against the service request by the citizen through a defined

and secured process

Citizen Relevance

Ease of delivery to citizen at doorstep

Easy availability of multiple copies of output

Authenticity & acceptance of document through secured way


The channels of delivery as envisaged for the service component is tabulated below –


Service Delivery Centre (eg.

CSC)

All delivery of service output will be done

through the Service Delivery Centres

8. Unique encrypted key/code


87

The key challenges seen for this component relate to delivery and their integration so


Legal challenges:

Validity of the printed form of a digitally signed document

Process related challenges

Delivery of the digitally signed document to the applicant

The printed form will have a Unique ID and a website address where the authenticity of

the document can be verified. Any Gazetted officer or a Kiosk operator can attest the

printed copy by verifying from the mentioned website. The Kiosk where this document

would be attested will have its owner‟s name or ID also printed on the copy along with

their seal and signature.

The Process flow is demonstrated as below:


88

Delivery Mechanism

e-D

istr

ict

Ap

plic

atio

nA

pp

lica

tio

nC

SC

/ S

uvid

ha

Ce

nte

r

Travels to any

CSC / Suvidha

center.

Notifies the CSC

& applicant that

his delivery is

due

Quotes the

Receipt Number

and requests

delivery of

document

Receives

notification of

pending delivery

Enters the

Receipt No. into

the e-District

application

Retrieves the

digitally signed

document saved

against the

Receipt No.

Displays the

document along

with the

Signatory’s

information

Prints out the

document and

stamps it with his

seal and signs it

Receives the

signed and

stamped document

Receives

notification of

pending delivery


89


1. Notification is sent to the respective

CSC/Suvidha centre and applicant about the

pending delivery

e-District application

(eDA)

2. CSC/Suvidha centre receives the notification eDA

3. Applicant receives the notification eDA

4. CSC/Suvidha centre is approached at the date

specified on the application receipt

Applicant

5. CSC/Suvidha centre is presented with unique

application reference id

Applicant

6. Unique application reference id is entered in the

eDA

CSC/Suvidha centre

7. Information is retrieved and the digitally signed

document is displayed on the screen

eDA

8. Printout of the digitally signed document is taken CSC/Suvidha centre

9. Document is physically signed CSC / Suvidha centre

10. Final delivery is made to the applicant CSC / Suvidha centre


90

S.No Functional Requirement Specifications – Delivery Mechanism

1 The system should be able to provide delivery against all service

request made

2 The system should be able to link delivery against specific service

request through unique service application request number

3 The system should allow delivery only when the service request

has been either approved / rejected

4 The system should allow only validated predefined users to log

into the e-district application for retrieving the delivery against

the service request

5 The system should ask for unique service request number /

unique application number to retrieve specific service delivery

6 The system should ask for the digital verification from the

authenticated predefined users

7 The system should allow downloading of the service delivery

output only after matching the digital verification

8 The system should provide for the printable version of the service

output

9 The system should be able to print the unique kiosk number,

unique application number on the every service output generated

through it

10 The system should be able to print the <url> of the site from

where the content of the service delivery could be verified

11 The system should open new page specifying error in case of

incorrect digital verification

12 The system should be able to maintain the database of the all the

service delivery output in a logical manner to ease the retrieval

of the same as and when required

13 The system should have a life counter to keep log of all delivery

made with specific association of unique service application

number and unique CSC number

14 The system should support multi-lingual interface (minimum Hindi

and English) as per localization and language technology

standards for National e-Governance plan defined in the e-District

guidelines


91

3.9 Status

The objective of this component is to keep track of the service levels of the various

processes involved in a given service. This component is solely related with status

tracking from the consumer‟s perspective as well as the department/administration

perspective.

Each application by a consumer will be logged against a unique reference number

generated at the time of application submission and given to the consumer for future

references and status tracking.

The purpose of having the status component is to ensure the following facets of good

governance in day to day working of the government services:

1. To ensure transparency in service processing by the government to the citizen

for the service request made

2. To establish the validity and sanctity of the well defined service level

3. To ensure and define responsibility and ownership of the actors towards service

delivery


Informs about registration of service request by the citizen which act as a proof for

service request

Enable applicant to keep a constant track of the application at various levels of

service processing

Citizen can check the status of his/her application right from the time of

application submission till the time final service is delivered.

Grievance process could be initiated by the citizen immediately if the service level

is not maintained


The channels of delivery are:



(CSC / Block office /Tehsil

office)


Online (Web portal) Software application should integrate features for

providing required information for such requests

Telephony (SMS/IVRS) System should integrate features for providing

required information for such requests


92

The key challenges seen for this component relate to status and their integration so as

to account for consolidated view of service delivery of the component.

Legal challenges:

None


Whenever the e-District Application detects an SLA being exceeded, it should

automatically escalate the issue to a higher authority.

The e-District application will detect changes in the status of the application and notify the

applicant on mobile or email. The e-District Application will continually monitor the time

every application stays with a owner. If the time exceeds the specified limits, it would

escalate the application to a higher authority and also notify the applicant. The proposed

process flow for the component is as follows:


93

Status Trackinge-D

istr

ict

Applicati

on (

eD

A)

Applicant

Receives notification of

status of one‟s

application

Detects changes

in status of

application

Retrieves the Status

information associated

with the unique

application reference

id

Updates the Status

information mapped

against the unique

application reference id

If any mobile or

email is registered

Notifies the

Applicant about

one‟s application

status

Y

Accesses the e-District

Portal through internet

Enters the unique

application

reference id of

his/her application

Receives the Status

of his application

Sends SMS to the e-

District application with

the unique application

reference id

Stop

Start

Start

Application

receipt

component

(Mobile/Email id)


94


1. Each service request is monitored and in case of any change

in the status of the application, the same is updated against

the status information of the respective service request


(eDA)

2. Details against the respective unique application reference

id are checked to see if any mobile or Email is registered


(eDA)

3. If any mobile or Email is registered against the service

request application, a system generated notification is sent

on the registered mobile or Email about the latest status of

the application


(eDA)

4. If the applicant has access to mobile, one has to register the

same with eDA to receive the system generated notifications

on the registered mobile

Applicant

5. If the applicant has access to Email, one has to register the

same with eDA to receive the system generated notifications

on the registered Email

Applicant

6. If the applicant has access to mobile but has not registered

the same with eDA, one can send SMS to eDA with the unique

application reference id to retrieve status information

Applicant

7. If the applicant has access to Email but has not registered

the same with eDA, one can access the eDA portal and enter

the unique application reference id to retrieve status

information

Applicant

8. If the applicant does not has access to mobile or Email, one

can access the eDA portal and enter the unique application

reference id to retrieve status information

Applicant


95

S.No Functional Requirement Specifications – Status Component




2 The system should have integrated auto status tracking features

embedded in the overall architecture of the system

3 The system should keep track of all the service requests from the citizens

along with the respective unique application reference id generated at the

time of the application receipt

4 The system should be available in public and administrative view

5 The system should be able to keep track of the status of all the service

requests with the help of the respective unique application reference id

(application id) and map the current status with the pre-defined service

level against each process

6 The system should be able to detect any change in the status of a given

unique application reference id

7 In case there is a change in the status of a unique application reference id

, the system should update the status information in the database

8 The system should have provisions for intimating the applicant about the

current status of his/her application through SMS and/or Email especially

if there is a change in the status with respect to the final delivery of the

service

9 The system should not provide details about the internal SLAs to the

applicant and only provide update about the status with respect to the

final delivery. This feature should also allow the system to update the

applicant if there is any change in the service level of the final delivery

10 System should display the link for eDA portal from where the applicant can

retrieve the status information by entering the unique application

reference id

11 The system should also allow the applicant to retrieve update about

his/her service request through the web portal by entering the reference

id in the link provided on the portal

12 System should display the number from where the applicant can retrieve

the status information by sending SMS along-with the unique application

reference id

13 The system should also allow the applicant to retrieve update about

his/her service request by sending a SMS containing the unique application

reference id to the eDA


96

14 The system should display an appropriate message if the system is unable

to retrieve the details due to any reason like connectivity issues,

maintenance issues, etc and also provide contact details of the system

administrator and alternate link (if available)

15 The System should have Side Menu on each page so as to reflect the

contents of the containing directory, making it easier to navigate the site

and locate the link for retrieving update against a given reference id

16 The system should be adequate security features built in the architecture

of the system to ensure that it cannot be hacked or manipulated

17 The system should not allow the users to edit the details of the application

upon retrieving the status update against a given reference id

18 The System should allow the end user to print the status update

information if the applicant is retrieving the status through the portal or

email

19 The System should have provision for Calendar System, which displays the

dates and time of schedule events on a page formatted as a standard

monthly calendar

20 The system should have additional capability to integrate and extend

portals to support a vast array of mobile devices in addition to PCs (WAP

enabled)

21 The system should have provisions such that the System Administrator can

add/remove/modify the hierarchy of the Government officials with

adequate authentication mechanism

22 If there is any modification in the hierarchy of the relevant authority

against a given service (in the system), system should automatically map

the escalation levels with the new hierarchy of Government officials


97

3.10 Monitoring (MIS)

Monitoring and reporting element of the proposed BPR framework is envisaged to meet

all the monitoring and reporting requirement of concerned departments for the

selected services under the e-district project. The element will capture relevant

information from service perspective (as defined in the proposed e-district

application) at predefined points of the To-Be processes in predefined format and

consolidate the same across the district for the defined user to see and take necessary

action as deemed necessary. The monitoring element will have the “drill down”

feature to locate the base information from which it has been consolidated.

The reporting element of the proposed BPR framework will be based on the

departmental requirement. The element will have 2 types of reporting features –

Physical reporting

Financial reporting

The physical reporting will include reporting on department achievements on physical

units while the financial reporting will include the fund utilization against the

budgeted amount for the service.

The purpose of the monitoring and reporting element as envisaged in the proposed

BPR framework has been listed below –

1 Provide real time information on the all aspect of service – request, processing, delivery, etc, to the defined actors for the given service

2 Progress tracking of work at defined levels on given time referential and help identifying any slack in the same.

3 Help to develop mid term correction strategies by brining out deficiency in any aspect of service delivery

4 Generate required report for concerned departments basis physical and financial reporting requirement


98


The significance of the monitoring and reporting element relates to the concerned

department owning the selected services under the e-district project. The aim is to

not only automate the workflow so as to ease the functioning of the district

administration but also to provide for adequate window for the administration to

monitor all aspects of the service and meet the reporting requirement at all levels of

the department pertaining to the service under question.


The channels of delivery for monitoring and reporting elements as envisaged in the

framework is given in the matrix below –

Channel of Delivery


Online Software application should integrate

features for capturing required

information for such transactions

The key challenges seen for this component relate to monitoring and their integration


Legal challenges:

None


The e-District Application will gather data and aggregate it into a report


Implementation of a Business Intelligence layer to capture information from data

Some Data analytics software might be required for this. We can approach a few vendors

for pilot phase.


99

Monitoring – When authorities initiate an event

Au

tho

ritie

s r

eg

iste

red

to

rece

ive

re

po

rts

e-D

istr

ict A

pp

lica

tio

n

Search the information

according to query

Retrieve

information

According to query

Takes cognizance of the

reports and acts as

necessary

Print all the

information

Aggregates all the

information as per

Report Generation

rules

Logins to the e-District

Application using his user

ID and password


100

Monitoring – Automatic System generated at regular time intervals

Au

tho

ritie

s r

eg

iste

red

to r

ece

ive

re

po

rts

e-D

istr

ict A

pp

lica

tio

n

Retrieves

information about

status of applications

Notifies the

authorities and

sends the reports

on a regular time

interval to them

Aggregates all the

information as per

Report Generation

rules

Takes cognizance of the

reports and acts as

necessary


101

S.No Process details Responsibility

Case 1: Event based monitoring

1 Authority who has to monitor some process is

provided with a login id and password e-District application (eDA)

2 Monitoring authority logs in to the e-District

application using his/her login id and password Monitoring authority

3 Required details are queried for through the eDA Monitoring authority

4 Information is retrieved according to the search

query eDA

5 The retrieved information is aggregated according

to the report generation rules and in the pre-

defined format

eDA

6 Report is generated and displayed for the

monitoring authority eDA

Case II: Time based monitoring

1 At pre-defined intervals, a system trigger is fired

which initiates the auto information retrieval

process within the system

eDA

2 The retrieved information is aggregated according

to the report generation rules and in the pre-

defined format

eDA

3 Report is generated and displayed for the

monitoring authority eDA


102

S. No. Functional Requirement Specifications

1

The Process Owner should be able to use the e-District Application (eDA) to

query the Departmental Databases using the name or other details of the

applicant.

2 Should allow the eDA to retrieve various information from the individual

databases and aggregate it.

3 The application should support the monitoring in both the occurrence, when

an event or time driven activity is triggered.

4 Should be able to retrieve all information about the status of the application

form of the citizen.

5 Should be able to automatically generate the following reports to the

concerned authorities at regular time interval.

6 Should be able to generate Service Report on a regular time interval, this

report should include the no of application received, no of application

processed, no of application rejected and the no of application under

process.

7 Should able to generate SLA Report on regular time interval, this report

should give information related to centre wise details of no of SLA met and

centre wise details of no of SLA breached.

8 Should be able to generate Performance Report on regular time interval, this

report should give information related to centre wise details of no of

application processed against the no of application received.

9 Should be able to generate Payment Report on regular time interval, this

report should give information related to centre wise transaction, money

collected and money deposited along with date and time.

10 Should be able to generate Inventory Report on regular time interval, this

report should give information related to pre-printed stationary used and

issued to each centre.

11 Should be able to generate Attendance Report on regular time interval, this

report should give information related to centre wise attendance.

12 Should provide a search option to the authorized stakeholder so that he can

search the information which should be sorted according to Date,

Department, Service, District, Block and Tehsil.


103

13 Should allow the stakeholder to review the progress report and give his

comments online.

14 Should provide the facility to print and e-mail the report.

15 Should provide a printer – friendly version automatically for all pages.


English) as per localization and language technology standards for National e-

Governance plan defined in the e-District guidelines


104

3.11 Workflow Component

Workflow is the base component of the indicative framework where the „As Is

processes‟ will be mapped against the „To Be envisioning‟. Workflow is the automation

of a complex process, in whole or part, during which resources, information, tasks and

data a passed from one participant to another for action, according to a set of rules.

Workflow management system will link all the components of a given service and will

provide a common platform to work and interact to all the stakeholders. Workflow

management system is a mechanism that defines, creates and manages the execution

of workflow through the use of software, running on one or more workflow engines,

which is able to interpret the process definition, interact with workflow participants

and, where required, invoke the use of tools and applications. This system will also

allow people to specify and manage working processes, which are distributed in time

and across different domains and actors.

Technologies such as work flow and document management can help cut the corporate

paper mountain down to size while improving the efficiency of basic operations. The

key attraction of such technologies lies in their ability to help organizations and

departments improve their existing working practices. Some of the key benefits of a

good workflow management system are listed below:

Improved efficiency

Improved productivity

Reduced service levels

Better quality of service

Reduced operational costs

Increased transparency

Significance (Citizen/administration)

Workflow will not only ensure smooth and on-time delivery of services but this will

also result in more transparency, responsibility and increased productivity in the

organization.


The channels of delivery for the service are:

Sr. Channels of Delivery Description

1. Online Workflow features should be embedded in the system


105

Detailed work flow for all 10 selected services and 32 sub services has been provided

in Part IV of the report.

architecture such that automated workflow is in place


106

Part IV Workflow – TO- BE & FRS


107

4.0 Workflow – To-Be & FRS

General Specification

Sr. Requirements

1 All applications must be fully integrated including enhancements and

updates – no duplicate data entry at any level

2 The system should exist in an open environment providing enough

flexibility in selecting the hardware as well as operating environment

3 The system must be capable of presenting usages service wise in a

tabular and graphical form for easy understanding and analytical

purposes

4 The system should be modular in nature.

Each activity must be handled by a specific module so that it

could help in gradual implementation of the system.

Each module should have the capability of running as a stand

alone as well as an integrated environment if other modules

are installed and implemented

5 The system should operate in a full on-line / interactive environment

with instant reflections of the missing or erroneous input

6 The system should be able to recover with rollback capability to the

data in case of any system or communication failure (visualize last

transaction)

7 System shall provide for ad-hoc spreadsheet and database functions or

support the import and export of spreadsheets and databases, such as

MS Excel and MS Access

8 On-line maintenance is posted “real time” and immediately reflected

in information provided by the system

9 Checks for duplicate numbers prior to accepting new e.g.:

Application number

Kiosk ID

Service code

10 System shall provide the ability to scan images and documents and

make them available by item number for review

11 System should be user friendly with ease of navigation through various

systems modules

12 Applications should be consistent in format and screen design


108

Sr. Requirements

Function keys should be consistent within and across

applications for maintenance and screen switching

13 Full editing and validation for data entry must be standard. In case of

data in error a descriptive message with corrective action is displayed

14 Provides abbreviations or wild card characters in search mode

15 Provides help functions at the screen and field level for all screens and

menus

16 Screens are capable of reverse as well as forward scrolling

17 Purging, backups, restores, etc. are performed at System

Administrator level not at user level

18 The system must be fully documented to reflect the latest software

revisions and provides future update information

19 List of error code information and messages must be present

20 Must generate full audit trails

21 System must provide the ability to generate user-defined reports using

a report generation tool that directly accesses the business system

data to develop executive level reports

22 Facility to access the application should be role based

23 The e-District Application must support Digital Signatures of any of the



respective Certifying Authorities on the structure of the Digital

Signatures issued by them.

The Digital Signatures used and the e-District Application must

provide the Time Stamping of the act of Digitally Signing a

document as mandated by the IT Act 2000

The Smart Card reader or the USB Token, carrying the

Private/Secret Key, must be activated by Biometric

identification instead of a PIN / Password based system


109

a. Common Service Center e-District Project, U.P. aims to bridge the gap between government and citizen by

providing select Government-to-Citizen (G2C) services as defined in the scope of the

project. For this, Common Services Center is envisaged as a medium to provide easy

access to essential services to common man in the rural region by enabling electronic

delivery of information and services. CSC is expected to reduce the time and cost

involved in obtaining services - public grievance redressal, government to citizen

information & services etc.

CSC as a front end of service delivery will help ease the complex process of obtaining

government services by the citizens. Also, at the same time, it will streamline the

service delivery and hence has been accepted by the State of Uttar Pradesh as a front

end for the e-District project.

Hence, it is imperative to integrate CSC with the overall model of e-district project.

The functional requirement specification to be included in the proposed e-District

application keeping roles and responsibilities of CSC in perspective are detailed in the

table below –

S. No. Functionality

1 e-District application should have provision for and allow the Common Service

Center operator to login in to the e-District application after following defined

authentication check –

using User Login and password

thumb Impression registration via using bio-metric device

2 e-district application should have provision of a database for Common Service

Center with the following details –

Unique Kiosk ID

Name of SCA

Location of common service center

3 e-district application should have provision of a database for operators of

Common Service Center with the following details –

User name and password

Biometric impression database

Name of SCA

Employee ID (as assigned by the SCA)

4 e-district application should have provision of a database for all operations /

transaction performed by Common Service Center with the following details –

transaction ID for service request


110


unique Kiosk ID

details of operator

date and time of transaction

5 e-district application should have separate section for SCA for logging into the

application

6 e-district application should have the provision for SCA to update records

(add, delete and modify) as mentioned in point (3)

the updation function should be allowed only through prescribed

authentication mechanism through login by user name and

password

confirmation of updation should happen only through transaction ID

and password

final submission of updation request should happen only though

signing by digital signature of SCA

all such transaction done by SCA should be saved and stored by e-


7 e-district application should not allow the Common service center operator to

modify the system login password through their user ID and password

8 e-District application should have mandatory provision for changing of

Common service Center operator password every 30 working days by the SCA

the e-district application should send reminders for change in

password from the 25th day of password setting

last 3 password should not be used

alphanumeric codification should be made mandatory with

minimum of 8 characters

9 e-district application should block the system login in case of wrong user ID

and password provided for login for 3 consecutive attempts

the system should allow the SCA to reset the password for such

instances where login is blocked and re-activate the login once the

password has been reset

10 the system should allow Common Service Center operator to access the online

application form, download it and fill the details in the form on behalf of

citizen at the e district application

11 The system should allow Common Service Center operator to submit the form

on behalf of citizen at the e district application only by using transaction ID

and password assigned for the purpose

12 The system should allow Common Service Centre operator to issue the

acknowledgement receipt generated by the e district application on successful


111


service request registration

13 The system should allow Common Service Centre operator to log in to the e

district application to track the status of service request application whether

the application has been accepted, rejected or sent for verification

14 The system should allow Common Service Centre Operator to view timely

alerts generated against the service request in case of any clarifications

required or in the case of delay in the service delivery

15 The system should allow the Common Service Center operator to provide final

service delivery at the kiosk to the applicant by downloading / viewing and

further printing of the output against the service request made

16 The system should allow the Common Service Center operator to access the e

district portal and help citizen obtain information on various aspects related

to services offered at the e district centre and other government services

17 The system should allow the Common Service Center operator to generate a

daily transaction record at the end of the day and print it is required

18 The system should allow the Common Service Center operator to generate a

periodical money deposition report against the money collection at the centre

19 The system should allow the SCA to generate a periodical money deposition

report against the money collection by all centres under it

20 The system should not allow the Common Service Center operator / SCA to

make any changes in the service request / delivery against the service request

at any point after the service request has been successfully registered with

the system

any changes in the service request

any changes in the service output

any changes which comes in conflict with FIFO (First – In- First Out)

logic

any other changes which is deemed unlawful on the part of

Common Service Center operator / SCA

21 The system should not allow the Common Service Center operator / SCA to

enter / view the departmental database or make any changes in the same at

any point of time

22 The system should have a provision for making service complaint request by

the Common Service Center operator / SCA in case any module of the e-

district application is not working properly

the system should route such request to system administrator

defined for the e-District application

23 The system should automatically log of the Common Service Center operator


112


from the e-District application in case of „inactivity‟ for more than 30 minutes

from

The system should automatically log off the Common Service

Center operator in case of a continuous session for 2 hours and

reload the login page for new session

24 The system should maintain all the transaction record session wise for all the

common service center under the e-district application

25 The system should have a provision to store all „Machine ID‟ with the e-District

application and should allow the Common Service Center operator / SCA to

enter the application only through the registered machine with the defined

„Machine ID‟

the system should allow the SCA to register the Machine ID on the e-district

application

the system should save the „Machine ID‟ entered by the SCA only after

providing the digital signature for the purpose


113

b. Database Summary Table for the effort estimate and the digitization required for the e-district database:

Sr. No. Database Name Owner Form Status

1. Bhu-lekh database Revenue Department

100% Digitized

Partially updated

2. Pension database District Social Welfare Office

Manual 100% updated

3. Parivar register Panchayati Raj Officer

Manual Partially updated

4. CMO database Chief Medical Officer

Manual 100% updated

5. Court Cases database Revenue Department

Manual 100% updated

6. BPL List District Supply Office

Manual Partially updated

7. Physical Verification (Supporting Documents)

Lekhpal (Revenue Department)

Manual -


114

The databases have been mapped onto the respective e-District database fields as follows:

Sr. No. Db Verification Fields Sources

1 Name Parivar Register

2 Maiden Name (if applicable) Physical Verification

3 Gender Parivar Register

4 Occupation Parivar Register

5 Income(Self/Family) Assessed based on land held, occupation, assets owned, occupation of family members, dependants

6 Local Address, Occupancy Period Parivar Register

7 Permanent Address Physical Verification

8 Land Held Bhu-Lekh Database

9 Nationality Parivar Register

10 Family Members Details

Gender

Occupation

Name

Age

Dependant (Yes/No)

Parivar Register, BPL List

11 Caste (SC/ST/OBC/General) Parivar Register for ST and SC

12 Marital Status Parivar Register

13 Spouse‟s Name, age, Date of Birth, place of birth, maiden name (if applicable)

Parivar Register


115


14 Date, Time, Place of Birth CMO Database

15 Date, time, place, cause of death CMO Database

16 Mother & Father name, Occupation, date & place of birth

Parivar Register

17 APL/BPL/Antodaya BPL List

18 % Handicap Medical Certificate (Supporting Document)

19 Pensioner (O – old age, H – Handicap, W – widow) Pension database

20 Qualification Physical Verification (Supporting Document)

21 Reservation (Defense) Physical Verification (Supporting Document)

22 Registration with Govt. Societies (District Industry Centre, ITI training)

Physical Verification (Supporting Document)

23 Government Schemes Availed Physical Verification (Supporting Document)

24 Bank Account Number Pension Schemes Database

25 RC certificate

Yes/No

Amount

Department

Amount Recovered

Amount Pending

Date of recovery

26 Land Records details Bhu-lekh database


116


27 Pending Court Cases Details Digitization of details of the pending court cases


117

The e-District database fields have been iterated based on the fields of verification for the categories of services are listed below:

Sr. No. Services Db Verification Fields

1 Income Certificate Income(Self/Family), Address, nationality, family details, affidavit, land held, occupation, name of the applicant

2 Caste Certificate Caste, Local Address, Father‟s name, name of the applicant

3 Domicile Certificate Local Address, Occupancy Proof, Father‟s name, name of the applicant

4 Birth Certificate Date of Birth, Gender, Place, Time, Address, Mother & Father name, Occupation, date & place of birth

5 Death Certificate Date and place of death, Name and surname of deceased, gender, Maiden name of a deceased woman who had married, Date and place of birth of the deceased , Occupation and usual address of the deceased , Name and surname of informant b) Qualifications c) Usual address , Cause of death, Certification and signature of informant, Date of Registration, Signature of Registrar

6 Old Age Pension Sanction & Approval

Income(Family), Age, Land Held, Occupation (Self/ Family), name of the applicant, bank account no., bank account no., family member(dependants not in govt. job), local address,

7 Widow Pension Sanction & Approval Date of Demise of Husband, Income(Family, Self), Land Held, Age, Occupation(Family, Self), name of the applicant, bank account no., family member income details(dependants not in govt. job), local address

8 Handicap Pension Sanction & Approval

Medical Certificate, Income(Family/Self), Age, name of the applicant, bank account no.,

9 Payment of Property Tax & Submission of Application

-

10 Issue of Khatauni Land Record Data


118

11 Employment Exchange Registration qualification, name, local address, Date of Birth ( High school certificate/Xth Mark sheet), Caste Certificate ( OBC /SC/ST and others), All relevant original Mark sheets, School leaving/Transfer certificate (In case of school drop out)

12 PMRY Registration Family income, name, local address, education, registration proof with district industry centre(dic), gender, handicap, defense, caste, ITI training certificate, occupancy, The candidate should not be a defaulter of any bank or any other financial institution, Not receiving financial benefits from any other state or central scheme, Project cost less than Rs. 2 lakhs , Should possess 5-12.5 % margin money to pay to the back

13 PMRY Information Dissemination -

14 PMRY Interview Project proposal,

15 SGSY Information Dissemination -

16 SGSY Request for appraisal Group Composition(name, age, handicap certificate(if any), APL/BPL status, income(family), Only one member of family have membership in group, Beneficiary can be member of only one group)

17 Revenue Court Daily Case List Pending Court Cases Details

18 Revenue Court Copy of Final Order No verification

19 Revenue Court Case Status Tracking Stages of Court Cases

20 Ration Card – Issue of new card Nationality, Identification, Income(family/self), Land Held, Family Members (name, age, gender), Local & permanent Address, father‟s name,

21 Ration Card – Duplicate, Cancel, Add a unit, delete a unit

Proof of the modification requested for

22 Grievance – Information Dissemination

-


119

23 Filing of grievance -

24 Status Tracking of grievance -

25 RTI – filing an application No verification

26 Police Department – Status Tracking Stages of an FIR

27 Police Deptt. - Character Certificate (Apply, Delivery & Status)

Stages of issue of certificate

28 Recovery Certificate – Issue of RC No verification

29 Recovery Certificate – Monitoring of RC

-

30 Recovery Certificate – Status tracking

Stages of RC

31 Electoral Service – Addition to voter list

Local address, occupancy, identification, age,

32 Electoral Service – modification to voter list

33 Electoral Service – deletion from voter list

Identification proof


120

c. Access Rights Management

The Access to the databases, which will store all the information related to the

applications, the verified details, and the digitally signed deliverables, should be

tightly governed and monitored. The integrity and security of these databases is of

paramount importance.

These databases will accessed by various stakeholders at different stages of processes.

We would define the access parameters based on the CRUD Model for access

management. The acronym CRUD refers to all of the major functions that need to be

implemented in a relational database application or Restful web application to

consider it complete. An indicative mapping of each letter in the acronym to a

standard SQL statement is demonstrated below:

Operation SQL

Create INSERT

Read (Retrieve) SELECT

Update UPDATE

Delete (Destroy) DELETE

Although a relational database is a common persistence layer in software applications,

there are numerous others. CRUD can be implemented with an object database, an

XML database, flat text files, custom file formats, tape, or card, for example. The

CRUD Matrix is a two-dimensional chart that summarizes the Access Rights

combinations for a particular designation. Some globally valid Access Rights applicable

to all Databases are indicated in the CRUD Matrix provided below:

Designation Create Read Update Delete

District Magistrate

■ ■ ■ ■

Additional District

Magistrate ■ ■ ■ ■

SDM ■ ■ ■ ■ Tehsildar ■ ■ ■ X

Every service detailed in the Report has an independent section of the CRUD Matrix for

the Database envisaged to be used for that Service.

http://en.wikipedia.org/wiki/Application_software

http://en.wikipedia.org/wiki/RESTful

http://en.wikipedia.org/wiki/SQL

http://en.wikipedia.org/wiki/Insert_%28SQL%29

http://en.wikipedia.org/wiki/Select_%28SQL%29

http://en.wikipedia.org/wiki/Update_%28SQL%29

http://en.wikipedia.org/wiki/Delete_%28SQL%29

http://en.wikipedia.org/wiki/Object_database

http://en.wikipedia.org/wiki/XML_database

http://en.wikipedia.org/wiki/Flat_file_database


121

d. Login Login is the process of gaining access or signing into a computer system. If access is restricted, the log on requires users to identify themselves by entering an ID number and/or password. A login, logging in or logging on is the entering of identifier information into a system by a user in order to access that system (e.g., a computer or a website). It is an integral part of computer security procedures. The degree of protection that can be provided for a system and its data by a login procedure varies according to the system and how it is administered In addition to restricting access, logins also provide an audit trail in the form of data that is automatically entered into system log files (i.e., automatically updated files that contain records of events that have occurred on a system). Following process map depicts the proposed login system for e-District application -

Login

Use

r e-

Dis

trict

App

licat

ion

If Login info correct/

thumb impression

correct

Connects to

the e-District

application Enters the UserID and

Password to login / Enters his

finger impression using the

bio-metric device

Loads the

Login page

No

Displays an error and

reloads the login page

Yes

Logs on the user and

displays a Login

Success message

Starts

transactions

Stop

Start


122

Process Description


1. Kiosk operator connects to the application portal. CSC / Suvidha

Center

2. The e district loads the login page of the e district

application. Application

3.

Kiosk operator enters either the kiosk id & the

password to authenticate his kiosk at the e district

application or he can also put his thumb impression

on the bio metric device at the kiosk to register

himself with the application. (The SCA needs to

register all the kiosk operator as well all the back

office operators who might act as backup operators

in case of regular kiosk operator being absent from

the kiosk with the application)

Centre operator

4.

If the login information provided by the operator /

the thumb impression of the kiosk operator

matches with the stored information in the

database then he is authenticated to join the

application and he receives a login success

message.

If the combination of user name and password or /

and thumb impression is found out to be wrong by

the application then an error message is shown to

the operator and he asked to re login the entry

information.

Application

5.

Once the kiosk operator is able to login to the

application he can then serve the requests he

receives from the applicants.

Kiosk Operator


123

S. No. Functional Requirements - Login Component

1

Should allow only the authentic users (Kiosk Operators, Department Officials)

to login to the system through the use of:

Bio metric device using the thumb impression

User id and Password combination

Both

2 Should display the login page as the first page when the user enters the e

district application.

Thumb Impression Based Biometric Device

1 Should map the thumb impression of all the users to the application database

and only these users should be allowed to enter the e District application. In

case of any irregularities the combination of thumb impression and digital

signature put on the document would be used to mark responsibility.

2 Should give a welcome message once the user is able to successfully login to

the e district application.

3 Should give an error message once the user provides wrong login information

and ask the user to re log in.

User id & Password Combination

1 The user login and password both should be a combination of following:

Alphabets (at least 1)

Symbols

Numeric

2 The user name and password should have a minimum of 8 characters each

3 Should not create duplicate user ids or passwords

4 Should not allow the user to have the same password for more than 30 days

5 Should generate alerts for password expiry from two days of actual expiry

6 Should not allow same user id and password

7 Should not allow blank spaces while setting user id or password

8 Should notify the user in case the Caps Lock is on

9 Should notify the use if Num Lock is on

10 Should generate user id based on the criteria of - Zone, district, Tehsil an SCA

name, kiosk number

11 Should not allow a user who forgets the password to access the password

retrieval mechanism

12 Should allow only the machines whose mach id is registered with the


124

e. Digital Signature The e-District Application must support Digital Signatures of any of the Certifying

Authorities registered under the Controller of Certifying Authorities, and must be

modifiable as per the changes made by the respective Certifying Authorities on the

structure of the Digital Signatures issued by them.

The Digital Signatures used and the e-District Application must provide the Time

Stamping of the act of Digitally Signing a document as mandated by the IT Act 2000

The Smart Card reader or the USB Token, carrying the Private/Secret Key, must be

activated by Biometric identification instead of a PIN / Password based system

application enter the e district application

13 Should prompt the user to change the password in case of first login at the

client side i.e. after imaging

14 Should give a welcome message once the user is able to successfully login to

the e district application.

15 Should give an error message once the user provides wrong login information

and ask the user to re log in.

16 Should block the user to enter into the e district application if he puts in

wrong login info continuously thrice.

17 Should support multilingual interface (minimum Hindi and English) as per

Localization and Language Technology Standards for National e-Governance

Plan defined in e-district guidelines


125

4.1 Certificates

i. Caste Certificate

Select Prerequisites for the ToBe Process

The department should accept the provision of Common Service Centre / e

District Centres accepting service request application from the applicants.

The department should accept the provision of forwarding service request

through e-District application to Tehsildar without being manually forwarded as

a noting on service request file.

The department should also accept provision of delegating or marking of an

application to another official electronically through digital signing and

electronic mode of transfer.

The department should accept validity of a secure, digitally signed database as

an authentic and trustable source for verification.

The frequency of visits to the Tehsil / BDO by the Field Officer responsible for

Physical Verification must be increased to twice a week.

Mandated acceptance of Digitally Signed certificates across various

departments.

Availability of a public website, where authenticity of a printed copy of a

Digitally Signed certificate can be established.

Mandatory entry into the DB before any certificate is issued.

Value Addition on AS IS

The new To Be process provides many additional features such as:

Service delivery at village level. The citizens would be able to avail of the

service close to their homes and would not need to travel to Tehsil office


126

Quicker service. Automated workflow and digital signature would speed up

the service delivery time and improve the service levels for the service.

Status Tracking of an application. Citizens will now have up to date

information about the status of their applications

Monitoring of performance and service delivery quality. The Process owners

would be able to better monitor the performance and service delivery

quality through MIS reports.


127

Caste certificate

Caste Certificate

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nT

eh

sild

ar

Te

hsi

lda

rL

ekh

pa

l / R

IL

ekh

pa

l / R

IA

pp

lica

nt

Ap

plic

an

t


application and

issues a Receipt

Receives the

application

Checks the details

in the Revenue

Department’s

Caste certificate

DataBase

Details

Correct?

System saves the

certificate in a DB

and notifies the

applicant

Applicant receives

the certificate

Marks the application

for verification to RI /

Lekhpal

System saves the

rejection in a DB

and notifies the

applicant

Applicant receives

the reason for

rejection

Yes

No

Details

Found?

No

Yes


change and notifies

Tehsildar




Revenue Department’s

Caste certificate

Database

Submits the application

back with the verified

details

System notifies RI /

Lekhpal and

provides application

details

Receives the

application.

Returns the Query

results

Links the Citizen

Database with the


Caste certificate

database

Start

Payment

component

Application

Receipt

component

Form

Availability

component

Stop

On receiving the hard

copy of the

application, Approves

the application online

using digital sign as

per Approval

Component Rejects the

application online

using digital sign

as per Rejection

Component


128

Caste Certificate - Status

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nT

eh

sild

ar

Te

hsild

ar

Le

kh

pa

l / R

IL

ekh

pa

l / R

IA

pp

lica

nt

Ap

plic

an

t


application and

issues a Receipt

Receives the

application

Checks the details

in the Revenue

Department’s

Caste certificate

DataBase

Details

Correct?

System saves the

certificate in a DB

and notifies the

applicant



Lekhpal

System saves the

rejection in a DB

and notifies the

applicant

Yes

No

Details

Found?

No

Yes


change and notifies

Tehsildar





Caste certificate

Database



details


Lekhpal and


details

Receives the

application.

Returns the Query

results

Links the Citizen

Database with the


Caste certificate

database

Status

Tracking

Component


copy of the




per Approval


application online

using digital sign

as per Rejection

Component

Status

Tracking

Component

Status

Tracking

Component

Status

Tracking

Component


129

Caste Certificate - MIS

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nT

eh

sild

ar

Te

hsild

ar

Le

kh

pa

l / R

IL

ekh

pa

l / R

IR

ece

ivin

g A

uth

ority

Re

ce

ivin

g A

uth

ority


application and

issues a Receipt

Receives the

application

Checks the details

in the Revenue

Department’s

Caste certificate

DataBase

Details

Correct?

System saves the

certificate in a DB

and notifies the

applicant



Lekhpal

System saves the

rejection in a DB

and notifies the

applicant

Yes

No

Details

Found?

No

Yes


change and notifies

Tehsildar





Caste certificate

Database



details


Lekhpal and


details

Receives the

application.

Returns the Query

results

Links the Citizen

Database with the


Caste certificate

database

MIS


copy of the




per Approval


application online

using digital sign

as per Rejection

Component

MIS MIS MISMIS


130

Sr. Process Details Responsibility Centre

1 The Form Availability component ensures availability of the

application form Revenue Department

2 The Application and Payment is received at CSC or other centre as

per the Application Receipt and Payment component.


(eDA)

3 The Applicant is provided with a Receipt which includes a unique

Application Number and prospective date of delivery eDA

4 The eDA then routes the application to the Tehsildar and notifies

him about the new application eDA

5 The Tehsildar receives the application. Tehsildar

6 The Tehsildar queries the eDA for details in the Revenue

Department‟s Caste certificate Database Tehsildar

7

The eDA searches for the details in the Database and if found,

retrieves the Caste details from the Database and displays it to the

Tehsildar

eDA

8

The Tehsildar inspects the details and if the details provided are

correct, approves the application and digitally signs the certificate

and submits the same back to eDA

Tehsildar

9 The eDA saves the digitally signed copy in a Database and notifies

the Applicant eDA

10 The Applicant goes to any CSC and requests for the copy Applicant

11 The CSC operator delivers the document as per the Delivery

Mechanism component CSC

12

If the Caste details are not found in the Database, the Tehsildar

forwards the Application to the Revenue Inspector (RI)/ Lekhpal

through eDA to conduct verification ad update the Database.

Tehsildar

13 The RI / Lekhpal receives the application RI / Lekhpal

14 Physically visits the applicant and verifies the details. RI / Lekhpal

15 Enters the Caste details in the database RI / Lekhpal

16 Forwards the application back to the Tehsildar through eDA RI / Lekhpal

17 If the details are found to be incorrect, Tehsildar rejects the

application using digital sign, stating the reason for rejection, as Tehsildar


131

per the Rejection component

18 The eDA notifies the Applicant about Approval or Rejection. eDA

19 The Applicant collects the digitally signed certificate or the reason

for rejection. Applicant

Sr. Caste Certificate Status Tracking details Responsibility Centre

1 The Status Tracking and Escalation would be handled by the Status

Tracking component. eDA

2 The Applicant will be notified of acceptance and delivery of his

Application to the concerned officer eDA

3 The Applicant will be notified whenever the application is approved

and Digitally signed certificate is ready. eDA

4 The Applicant will be notified if his application is rejected. eDA

5 The Applicant will be notified if and when his application is

forwarded for Physical verification eDA

Databases required

S. No. Database Remarks OPTIONAL

1 Parivar Register Database

The Parivar Register database in manual form already exists, but is not updated. It needs to be digitized.

Y

2 Caste certificate database

This database will save all the application related information, the caste information for a citizen, and the Digitally signed certificate issued to any citizen.

N

3 Scholarship DB This is a recently digitized database which has fileds like Caste, Caste Category, Father‟s name etc.

Y


132

CRUD Matrix for Caste Certificate


District Magistrate ■ ■ ■ ■ Additional District


SDM ■ ■ ■ ■

Tehsildar ■ ■ ■ X

Revenue Inspector ■ ■ ■ X

Lekhpal ■ ■ ■ X

General Anonymous Access

X ■ X X

Service Request Form – Caste Certificate

The fields required in the request form for Caste certificate are as follows


1 Name

2 Father‟s or Husband‟s Name

3 Permanent Address (Optional)

4 Pargana

5 Tehsil

6 District

7 Caste

8 Current Address

9 Applicant‟s Photo

An indicative snapshot of the User Interface is presented as follows:


133

Records view for a Logged in officer

New Applications View

S.No Fields Description of the view

1 Application Number

2 Name of the Applicant

3 Father‟s / Husband‟s Name

4 Address

5 Target Date

6 Lekhpal assigned

7 Search box

An indicative snapshot for the User Interface is as follows:

The Logged in Authorized user (Tehsildar) should be able to assign a Lekhpal to the

application for verification. The Records for this action would be:



2 Selection of Area

3 Selection of Lekhpal


134

Internal Service Levels – Caste Certificate

The following table specifies the internal Activity-wise service levels:

S.No Activity Service Level in

days

Service Level from day of Application

1. Application Receipt and Forward to Tehsildar

1 day 1st day

2. Tehsildar checks details in the Database

1 day

2nd day

3. Tehsildar Approves or Rejects the application using his digital sign

2nd day

4. Tehsildar forwards the Application for physical verification

2nd day

5. Physical verification and Updation of the database by RI /Lekhpal

3 days 5th day

6. Tehsildar Approves or Rejects the application using his digital sign ( Already part of point no. 3

2 days 7TH day

Digital Signature requirement

The following table specifies the designations that need to receive the Digital Signatures:

S.No Designation Details (Nos.)

1. DM 1

2. Tehsildar All

3. Registrar Inspector All

4. Lekhpal All


135

Monitoring Report

The following table specifies the fields required in the MIS Report 1

S.No Name of the Tehsil

Number of Applications received

Number of certificates Issued

Number of Applications pending

Amount of application fees collected

1.

2.

3.

4.

5.



Application requiring Physical verifications

Total number of application received

%age of the application requiring physical verifications

1

2

3


136

Auto Escalation Matrix – Caste Certificate

The following table specifies the automatic escalations matrix:

S.No Activity Activity Owner

Service Level

L1

L2

L3

Designation Time Designation Time Designation Time

1.

Tehsildar checks details in the Database and either approves / rejects the application or forwards it for physical verification

Tehsildar 2 days SDM 1 day DM 2 days - -

2.

Physical verification and Updation of the database by RI /Lekhpal

RI / Lekhpal 5 days Tehsildar 1 day SDM 1 day DM 2 days


137

Functional Requirement Specification – Caste certificate

Sr. Description

1.

The system should be able to display Application for Caste certificate related

page through multiple routes

Service links

Information links

District Links

2. The system should be able to identify user login into the system as defined

by the login component

3.

The system should be able to provide information to the citizens about

application for Caste Certificate both in public as well as restricted domain

as per the „Information component‟

Web access to information content in public domain

e-District application access to information content

4. The System should make available the latest copy of the Application Form

online (24x7) as per the Form Availability component.

5. The System should enable receiving of the application as per the Application

Receipt component.

6. The System should generate a Unique Application Number and should be able

to identify the applicant based on this Number.

7. The System should display a message regarding successful or unsuccessful

completion of any transaction.

8. The system should refresh the page in case of failure in submission of service

request

9. The System should be able to record the payment made by the applicant

against the Application as per the Payment Component

10. The System should be able to save the application data and route it to the

Tehsildar of the Tehsil.

11.

The System should be able to notify the Tehsildar about the new application

and this date and time must be logged.

through e-District application

through SMS

through e-mail


138

12. The system should allow concerned officials to view the service request only

on authenticated login as per login process.

13. The system should allow Tehsildar to accept or reject any service request

application

14. The system should request the Tehsildar to compulsorily provide comments

in case of rejection

15. The system should save the acceptance / rejection only after digital

signature of the Tehsildar

16. The Tehsildar must be able to download the application from the System

17. The System should enable the Tehsildar to conduct verification as per the

Verification component.

18. The System should allow the Tehsildar to enter query parameters for the

Database and then display the results for the query to Tehsildar.

19.

The System should allow the Tehsildar to either approve or reject the

application using his digital signature as per the Approval and Rejection

component.

20. The System should log the Approval or Rejection and the date and time of

the action.

21. The System should save the digitally signed copy of the Caste certificate

issued as a soft copy in a Database

22. The System should be able to notify the Applicant and deliver the Caste

certificate as per the Delivery Mechanism component.

23. The System should log the details of who accessed the online soft copy and

took a printout of the same.

24.

The System should allow the Tehsildar to electronically forward the

application to a Revenue Inspector (RI) or a Lekhpal for physical verification,

using his digital signature.

25. The System should be able to notify the RI / Lekhpal of the new verification

request.

26. The System should enable the RI / Lekhpal to download the application

details.

27. The System should allow the RI / Lekhpal to create or update the caste

details in Database.


139

28. The System should allow the RI / Lekhpal to electronically forward the

application to the Tehsildar using his digital signature

29. The System should be able to notify the Tehsildar of the updates status of

the application.

30. The System should be able to detect changes in status and send status

updates to the citizen as per the Status Tracking component.

31.

The System should be able escalate the application as per the Auto

Escalation matrix defined in Auto Escalation Matrix table, by notifying the

next level of authority and sending him a copy of the application.

32. The Points in Process where status would be updated have been marked in

the Caste Certificate Status process map.

33. The System should be able to generate MIS reports as per the format

specified in the table Monitoring Report.

34. The Points in Process where inputs to the MIS would be saved have been

marked in the Caste Certificate MIS process map.

35.

The System should have a facility for forwarding of the application, with

remarks and digital sign of the sender, to any person in District

administration registered with the System.

36.

The system should support multilingual interface (minimum Hindi and

English) as per Localization and Language Technology Standards for National

e-Governance Plan defined in e-district guidelines.

37.

The e-District Application must support Digital Signatures of any of the




issued by them.

38.

The Digital Signatures used and the e-District Application must provide the


IT Act 2000.

39.

The Smart Card reader or the USB Token, carrying the Private/Secret Key,


based system.


140

ii. Domicile Certificate





through e-District application to SDM without being manually forwarded as a

noting on service request file.









departments.











141







142

Domicile certificate

Domicile Certificate

E-D

istr

ict

Ap

plic

atio

nS

DM

Le

khp

al /

RI

Ap

plic

an

t


application and

issues a Receipt

Receives the

application

Checks the details

in the Revenue

Department’s

Domicile

certificate

DataBase

Details

Correct?

System saves the

certificate in a DB

and notifies the

applicant

Applicant receives

the certificate



Lekhpal

System saves the

rejection in a DB

and notifies the

applicant

Applicant receives

the reason for

rejection

Yes

No

Details

Found?

No

Yes


change and notifies

SDM






Database



details


Lekhpal and


details

Receives the

application.

Returns the Query

results

Links the Citizen

Database with the



database

Start

Payment

component

Application

Receipt

component

Form

Availability

component

Stop


copy of the




per Approval


application online

using digital sign

as per Rejection

Component


143

Domicile Certificate - Status

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nS

DM

SD

ML

ekh

pa

l / R

IL

ekh

pa

l / R

IA

pp

lica

nt

Ap

plic

an

t


application and

issues a Receipt

Receives the

application

Checks the details

in the Revenue

Department’s

Domicile

certificate

DataBase

Details

Correct?

System saves the

certificate in a DB

and notifies the

applicant



Lekhpal

System saves the

rejection in a DB

and notifies the

applicant

Yes

No

Details

Found?

No

Yes


change and notifies

SDM






Database



details


Lekhpal and


details

Receives the

application.

Returns the Query

results

Links the Citizen

Database with the



database

Status

Tracking

Component


copy of the




per Approval


application online

using digital sign

as per Rejection

Component

Status

Tracking

Component

Status

Tracking

Component

Status

Tracking

Component


144

Domicile Certificate - MIS

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nS

DM

SD

ML

ekh

pa

l / R

IL

ekh

pa

l / R

IR

ece

ivin

g A

uth

ority

Re

ce

ivin

g A

uth

ority


application and

issues a Receipt

Receives the

application

Checks the details

in the Revenue

Department’s

Domicile

certificate

DataBase

Details

Correct?

System saves the

certificate in a DB

and notifies the

applicant



Lekhpal

System saves the

rejection in a DB

and notifies the

applicant

Yes

No

Details

Found?

No

Yes


change and notifies

SDM






Database



details


Lekhpal and


details

Receives the

application.

Returns the Query

results

Links the Citizen

Database with the



database

MIS


copy of the




per Approval


application online

using digital sign

as per Rejection

Component

MIS MIS MISMIS


145







(eDA)



4 The eDA then routes the application to the SDM and notifies him

about the new application eDA

5 The SDM receives the application. SDM

6 The SDM queries the eDA for details in the Revenue Department‟s

Domicile certificate Database SDM

7


retrieves the Domicile details from the Database and displays it to

the SDM

eDA

8

The SDM inspects the details and if the details provided in the

application are correct, approves the application and digitally signs

the certificate and submits the same back to eDA

SDM

9 The eDA saves the digitally signed certificate in a Database and

notifies the Applicant eDA




12

If the Domicile details are not found in the Database, the SDM



SDM

13 The RI / Lekhpal receives the application RI / Lekhpal

14 Physically visits the applicant and verifies the details. RI / Lekhpal

15 Enters the Domicile details in the database RI / Lekhpal

16 Forwards the application back to the SDM through eDA RI / Lekhpal

17 The eDA notifies the SDM, who then checks the details in the

database and If details are correct approves the application using SDM


146

digital sign as per the Approval component

18

If the details are found to be incorrect, SDM rejects the application

using digital sign, stating the reason for rejection, as per the

Rejection component

SDM

19 The eDA notifies the Applicant about Approval or Rejection. eDA


for rejection from the CSC as per the Delivery Mechanism Applicant

Sr. Domicile Certificate Status Tracking details Responsibility Centre









forwarded for Physical verification eDA

Databases required

S. No. Database Remarks

1 Domicile certificate database

This database will save all the application related information, the domicile information for a citizen, and the Digitally signed certificate issued to any citizen

2 Parivar Register Database

The Parivar Register database in manual form already exists, but is not updated. It needs to be digitized.


147

CRUD Matrix for Domicile Certificate




SDM ■ ■ ■ ■





X ■ X X

Service Request Form – Domicile Certificate

The fields required in the request form for Domicile certificate are as follows


1 Name


3 Village Name

4 Pargana

5 Tehsil

6 District



New Applications View for SDM





4 Address

5 Target Date

6 Lekhpal assigned

7 Search box

The Logged in Authorized user (SDM) should be able to assign a Lekhpal to the application

for verification. The Records for this action would be:



2 Selection of Area



148

Internal Service Levels – Domicile Certificate



days


1. Application Receipt and Forward to SDM

1 day 1st day

2. SDM checks details in the Database

1 day

2nd day

3. SDM Approves or Rejects the application and using his hid digital sign

2nd day

4. SDM forwards the Application for physical verification

2nd day

5. Physical verification and Updation of the database by RI /Lekhpal

3 days 5th day

6. Tehsildar Approves or Rejects the application using his digital sign already part of point no 3

2 days 7th day




1. DM 1

2. SDM All


4. Lekhpal All


149

Monitoring Report




Number of certificates issued



1.

2.

3.

4.

5.






1

2

3


150

Auto Escalation Matrix – Domicile Certificate



Service Level

L1

L2

L3


1.

SDM checks details in the Database and either approves/rejects the application or forwards for verification

SDM 2 days DM 2 days - - - -

2.


RI / Lekhpal

5 days Tehsildar 1 day SDM 1 day DM 2 days


151

Functional Requirement Specification – Domicile certificate

Sr. Description

1.

The system should be able to display Application for Domicile certificate

related page through multiple routes

Service links

Information links

District Links



3.


application for Domicile Certificate both in public as well as restricted

domain as per the „Information component‟






Receipt component.






request




SDM of the Tehsil.

11.

The System should be able to notify the SDM about the new application and

this date and time must be logged.


through SMS

through e-mail


152



13. The system should allow SDM to accept or reject any service request

application

14. The system should request the SDM to compulsorily provide comments in case

of rejection


signature of the SDM

16. The SDM must be able to download the application from the System

17. The System should enable the SDM to conduct verification as per the


18. The System should allow the SDM to enter query parameters for the Database

and then display the results for the query to SDM.

19. The System should allow the SDM to either approve or reject the application

using his digital signature as per the Approval and Rejection component.


the action.

21. The System should save the digitally signed copy of the Domicile certificate


22. The System should be able to notify the Applicant and deliver the Domicile




24.

The System should allow the SDM to electronically forward the application to

a Revenue Inspector (RI) or a Lekhpal for physical verification, using his

digital signature.


request.

26. The System should enable the RI / Lekhpal to download the application

details.

27. The System should allow the RI / Lekhpal to create or update the caste

details in Database.


153


application to the SDM using his digital signature

29. The System should be able to notify the SDM of the updates status of the

application.



31.





the Domicile Certificate Status process map.




marked in the Domicile MIS process map.

35.




36.




37.





issued by them.

38.



IT Act 2000.

39.



based system.


154

iii. Income Certificate



District Centers accepting service request application from the applicants.


through e-District application to Tehsildar without being manually forwarded as

a noting on service request file.









departments.











155







156

Income certificate

Income Certificate

RI / L

ekh

pa

lR

I / L

ekh

pa

lE

-Dis

tric

t

Ap

plic

atio

nT

eh

sild

ar

Ap

plic

an

t


application and

issues a Receipt

Receives the

application

Applicant receives

the certificate

System registers

the certificate in a

DB and notifies

the applicant

Conducts subjective evaluation

based on documents submitted and /

or orders Physical Verification.

If Original Salary

bank account statement or

Letter from Gram Pradhan

provided

Yes

Yes Establishes income

of the applicant

List of Documents to be submitted

along with the application:

Form 16

Salary Bank Acct statement

Attested Salary slip

Signed Khatauni

Letter by Gram Pradhan

No

No



details

Receives the

application.

Links the Citizen

Database with the


Income certificate

database

Physically visits and verifies

details. Enters these details

into the Revenue

Department’s Income

certificate Database


Lekhpal and


details

Start

Application

Receipt

component

Form

Availability

component

Payment

component

Stop


copy of the

application, Mentions

the Income on

certificate and

authenticates using

digital sign


157

Income Certificate - StatusR

I / L

ekh

pa

lR

I / L

ekh

pa

lE

-Dis

tric

t

Ap

plic

atio

nT

eh

sild

ar

Ap

plic

an

t


application and

issues a Receipt

Receives the

application

System registers


DB and notifies

the applicant




If Original Salary



provided

Yes

YesIf Access

available to IT

Database

Verifies the income

details in the IT DB

Establishes income

of the applicant

No

No



details

Receives the

application.

Links the Citizen

Database with the


Income certificate

database



into the Revenue




Lekhpal and


details

Status

Tracking

Component


copy of the


the Income on

certificate and

authenticates using

digital sign

Status

Tracking

Component

Status

Tracking

Component


158

Income Certificate - MISR

I / L

ekh

pa

lR

I / L

ekh

pa

lE

-Dis

tric

t

Ap

plic

atio

nT

eh

sild

ar

Ap

plic

an

t


application and

issues a Receipt

Receives the

application

System registers


DB and notifies

the applicant




If Original Salary



provided

Yes

YesIf Access

available to IT

Database

Verifies the income

details in the IT DB

Establishes income

of the applicant

No

No



details

Receives the

application.

Links the Citizen

Database with the


Income certificate

database



into the Revenue




Lekhpal and


details

MIS


copy of the


the Income on

certificate and

authenticates using

digital sign

MIS MIS


159







(eDA)

3

The application is submitted along with either supporting

documents, if possible, to establish the current income of the

applicant

Applicant



5 The eDA then routes the application and the supporting documents

to the Tehsildar and notifies him about the new application eDA

6 The Tehsildar receives the application and the supporting

documents Tehsildar

7 The Tehsildar evaluates the supporting documents to evaluate the

income of the applicant. Tehsildar

8


retrieves the Income details from the Database and displays it to

the Tehsildar

eDA

9

The Tehsildar inspects the details and if the details provided in the

application are correct, approves the application and digitally signs

the certificate and submits the same back to eDA

Tehsildar

10 The eDA saves the digitally signed certificate in a Database and

notifies the Applicant eDA




13

If the Income details are not found in the Database, the Tehsildar



Tehsildar

14 The RI/ Lekhpal receive the application RI/ Lekhpal

15 Physically visits the applicant and verifies the details. RI/ Lekhpal


160

16 Forwards the application back to the Tehsildar through eDA RI/ Lekhpal

17 The eDA notifies the Tehsildar, who then checks the details in the

database and establishes the applicant‟s approximate income. Tehsildar

18 Tehsildar then creates an income certificate with states the

established income and digitally signs it. Tehsildar

19

The eDA notifies the Applicant about the ready certificate and

saves the electronically signed copy of the same in the Income

Certificate Database.

eDA


for rejection from the CSC as per the Delivery Mechanism Applicant

Sr. Income Certificate Status Tracking details Responsibility Centre




Application to the concerned officer. eDA




forwarded for Physical verification. eDA

Databases required


1 Income Certificate Database

The Database will store the application data and the Income Certificates issued.


161

CRUD Matrix for Income Certificate




SDM ■ ■ ■ ■





X ■ X X


162

Service Request Form – Income Certificate

The fields required in the request form for Income certificate are as follows


1. Name

2. Father‟s or Husband‟s Name

3. Applicant‟s Photo

4. Current Address

5. Permanent Address

6. Village

7. Tehsil

8. District

9. Occupation

10. Income from farming

11. Income from any other Scheme

12. Income from other sources

13. Father‟s / Husband‟s Monthly income

14. Is applicant a Scheduled Caste (Yes/No)

15. Source of Daily wage, if any

16. Average number of days doing labour work in a month

17. Any other details

An indicative snapshot of the User Interface for the form is as follows:


163


New Applications View for the Tehsildar





4 Address

5 Target Date

6 Lekhpal assigned

7 Search box

The Logged in Authorized user (Tehsildar) should be able to assign a Lekhpal to the

application for verification. The Records for this action would be:



2 Selection of Area



164

Internal Service Levels – Income Certificate



days


1. Application Receipt and Forward to Tehsildar

1 day 1st day

2. Tehsildar checks the documents and/or details in the IT Database

1 day

2nd day

3. Tehsildar Approves or Rejects the application and using his hid digital sign

2nd day

4. Tehsildar forwards the Application for physical verification

2nd day

5. Physical verification and Updation of the application with details of income by RI /Lekhpal

5 days 7th day




1. DM 1

2. SDM All

3. Tehsildar All


5. Lekhpal All


165

Monitoring Report







1.

2.

3.

4.

5.


S.No Name / Designation of the Officer

Applications Completed within defined SLAs

Number of Application exceeding SLAs

Current owner of the application after escalation

1

2

3






1

2

3


166

Auto Escalation Matrix – Income Certificate



Service Level

L1

L2

L3


1.

Tehsildar checks details in the Database and either approves / rejects the application or forwards it for physical verification

Tehsildar 2 days SDM 1 day DM 2 days - -

2.


RI / Lekhpal 5 days Tehsildar 1 day SDM 1 day DM 2 days


167

Functional Requirement Specification – Income certificate

Sr. Description

1.

The system should be able to display Application for Income certificate related

page through multiple routes

Service links

Information links

District Links

2. The system should be able to identify user login into the system as defined by

the login component

3.


application for Income Certificate both in public as well as restricted domain as

per the „Information component‟






Receipt component.

6. The System should generate a Unique Application Number and should be able to

identify the applicant based on this Number.




request

9. The System should be able to record the payment made by the applicant against

the Application as per the Payment Component


Tehsildar of the Tehsil.

11.

The System should be able to notify the Tehsildar about the new application

and this date and time must be logged.


through SMS

through e-mail


168

12. The system should allow concerned officials to view the service request only on

authenticated login as per login process.

13. The system should allow Tehsildar to accept or reject any service request

application

14. The system should request the Tehsildar to compulsorily provide comments in

case of rejection

15. The system should save the acceptance / rejection only after digital signature

of the Tehsildar

16. The Tehsildar must be able to download the application from the System

17. The System should enable the Tehsildar to conduct verification as per the


18.

The System should allow the Tehsildar to enter query parameters for the IT

Database, if access is available, and then display the results for the query to

Tehsildar.

19.

The System should allow the Tehsildar to either approve or reject the

application using his digital signature as per the Approval and Rejection

component.

20. The System should log the Approval or Rejection and the date and time of the

action.

21. The System should save the digitally signed copy of the Income certificate


22. The System should be able to notify the Applicant and deliver the Income


23. The System should log the details of who accessed the online soft copy and took

a printout of the same.

24.

The System should allow the Tehsildar to electronically forward the application

to a Revenue Inspector (RI) or a Lekhpal for physical verification, using his

digital signature.


request.

26. The System should enable the RI / Lekhpal to download the application details.

27. The System should allow the RI / Lekhpal to create or update the Income


169

details in the application.


application to the Tehsildar using his digital signature

29. The System should be able to notify the Tehsildar of the updates status of the

application.

30. The System should be able to detect changes in status and send status updates

to the citizen as per the Status Tracking component.

31.

The System should be able escalate the application as per the Auto Escalation

matrix defined in Auto Escalation Matrix table, by notifying the next level of

authority and sending him a copy of the application.

32. The Points in Process where status would be updated have been marked in the

Income Certificate Status process map.

33. The System should be able to generate MIS reports as per the format specified

in the table Monitoring Report.

34. The Points in Process where inputs to the MIS would be saved have been marked

in the Income Certificate MIS process map.

35.


remarks and digital sign of the sender, to any person in District administration

registered with the System.

36.

The system should support multilingual interface (minimum Hindi and English)



37.


Certifying Authorities registered under the Controller of Certifying Authorities,

and must be modifiable as per the changes made by the respective Certifying

Authorities on the structure of the Digital Signatures issued by them.

38.


Stamping of the act of Digitally Signing a document as mandated by the IT Act

2000.

39.

The Smart Card reader or the USB Token, carrying the Private/Secret Key, must

be activated by Biometric identification instead of a PIN / Password based

system.


170

iv. Handicapped Certificate





through e-District application to CMO without being manually forwarded as a










departments.






Easier application process. The Disabled need not travel to CMO to apply,

additionally in case of duplicate certificate request the applicant need not

travel to CMO at all.


171

Status tracking of an application. Citizens will now have up to date






172

Handicap certificate

Handicapped Certificate

CM

O O

ffice

C

MO

Offi

ce

E-D

istr

ict A

pplic

atio

nE

-Dis

tric

t App

licat

ion

App

lican

tA

pplic

ant

Refers application

to Medical Panel

Medical panel examines

the applicant and

ascertains the disability

percentage

CMO Updates

database about the

new disability

percentage of

applicant


application, issues a

Receipt and

forwards to CMO

Receives

application

Checks the

details in the

DataBase

Yes

Applicant receives

the certificate

Details

Found?

System saves the

certificate in a DB

and notifies the

applicant

No

Database is updated

about the applicants

disability percentage

Application

Receipt

component

Payment

component

Form

Availability

component

Start

Stop

Approves the

application using

Approval

component

Claimed %age

is same as in DBYes


173

Handicapped Certificate - StatusC

MO

Offic

e

CM

O O

ffic

e

E-D

istr

ict A

pp

lica

tion

E-D

istr

ict A

pp

lica

tion

Ap

plic

an

tA

pp

lica

nt

Refers application

to Medical Panel


the applicant and


percentage

CMO Updates

database about the

new disability

percentage of

applicant



Receipt and

forwards to CMO

Receives

application

Checks the

details in the

DataBase

YesDetails

Found?

System saves the

certificate in a DB

and notifies the

applicant

No

Database is updated



Status

Tracking

component

Approves the

application using

Approval

component

Claimed %age

is same as in DBYes

Status

Tracking

component


174

Handicapped Certificate - StatusC

MO

Offic

e

CM

O O

ffic

e

E-D

istr

ict A

pp

lica

tion

E-D

istr

ict A

pp

lica

tion

Ap

plic

an

tA

pp

lica

nt

Refers application

to Medical Panel


the applicant and


percentage

CMO Updates

database about the

new disability

percentage of

applicant



Receipt and

forwards to CMO

Receives

application

Checks the

details in the

DataBase

YesDetails

Found?

System saves the

certificate in a DB

and notifies the

applicant

No

Database is updated



MIS

Approves the

application using

Approval

component

Claimed %age

is same as in DBYes

MIS MIS


175



application form Medical Department




(eDA)



4 The eDA then routes the application to the CMO and notifies him

about the new application eDA

5 The CMO receives the application. CMO

6 The CMO queries the eDA for details in the Medical Department‟s

Handicap certificate Database CMO

7


retrieves the Handicap details from the Database and displays it to

the CMO

eDA

8

The CMO inspects the details and if the %age of disability

mentioned on application is same as that in DB, approves the

application and digitally signs the certificate and submits the same

back to eDA

CMO


the Applicant eDA




12

If the %age of disability mentioned on the Application form is

different from that in the DB, then this is treated as a Revision

case, and the application is referred to a Medical Panel for a

Medical examination by Panel of Doctors

CMO

13

If the Handicap details are not found in the Database, the

application is referred to a Medical Panel for a Medical

examination by Panel of Doctors

CMO

14 The medical panel receives the application Medical Panel


176

15 The applicant physically visits the medical panel for medical tests

to help ascertain the percentage handicap. Applicant

16 The %age of disability is determined, a photo is clicked and both

are pasted on the certificate and saved in the DB. CMO

17 The eDA notifies the Applicant when the certificate is ready to be

collected. eDA

18 The Applicant collects the digitally signed certificate. Applicant

Sr. Handicap Certificate Status Tracking details Responsibility Centre







4

The Applicant will be notified the date, place and time for when

the applicant will be required to meet the medical panel for

medical tests

eDA

Databases required


1 Handicap certificate database

This database will save all the application related

information, the findings of the Medical Panel, and

the digitally signed Handicapped Certificate.


177

CRUD Matrix for Handicapped Certificate


District Magistrate ■ ■ ■ ■ Chief Medical

Officer ■ ■ ■ X

Medical Panel members

X ■ ■ X


X ■ X X

Service Request Form – Handicap Certificate

The fields required in the request form for Handicap certificate are as follows


1 Name


3 Village Name

4 Pargana

5 Tehsil

6 District

7 Age

8 Claimed %age of Disability (Approximate)


10 Type of handicap


New Applications View




3 Subject of the Application

4 Tehsil

5 Search box


178

Internal Service Levels – Handicap Certificate



days


1. Application Receipt and Forward to CMO

1 day 1st day

2. CMO checks details in the Database

1 day

2nd day

3. CMO Approves the application using his digital sign

2nd day

4. CMO refers the Application for physical medical examination

2nd day

5. Medical Examination by a Panel of doctors

5 days 7th day




1. DM 1

2. CMO 1


179

Monitoring Report







1.

2.

3.

4.

5.






1

2

3



Number of Applications which resulted in revision of Disability %age

Total number of Disability certificates issued

1

2

3


180

Auto Escalation Matrix – Handicap Certificate



Service Level

L1

L2

L3


1.

CMO receives the application and checks details in the Database and either approves the application or refers it to Medical Panel

CMO 1 day DM 2 day - - - -

2. CMO updates the database.

CMO 1 day DM 2 day - - - -

3.

Medical examination by the Medical Panel

Medical Panel

5 days CMO 1 day DM 2 day - -


181

Functional Requirement Specification – Handicap certificate

Sr. Description

1.

The system should be able to display Application for Handicap certificate

related page through multiple routes

Service links

Information links

District Links



3.


application for Handicap Certificate both in public as well as restricted







Receipt component.






request




CMO.

11.

The System should be able to notify the CMO about the new application and



through SMS

through e-mail


182



13. The system should allow the CMO to accept or reject any service request

application

14. The system should request the CMO to compulsorily provide comments in

case of rejection


signature of the CMO

16. The CMO must be able to download the application from the System

17. The System should allow the CMO to enter query parameters for the

Database and then display the results for the query to CMO.

18. The System should allow the CMO to either approve or reject the application



the action.

20. The System should save the digitally signed copy of the Handicap certificate


21. The System should be able to notify the Applicant and deliver the Handicap




23. The System should enable the Medical Panel to download the application

details.

24. The System should allow attaching a photograph with the certificate.

25. The System should allow the CMO to create or update the Handicap details in

Database.



27.






183

the Handicap Certificate Status process map.




marked in the Handicap Certificate MIS process map.

31.




32.




33.





issued by them.

34.



IT Act 2000.

35.



based system.


v. Birth Certificate


The Registration mechanism in the District should allow for the provision of

a database for use in verification process in rural areas

The department should agree to accept service request application from the

applicants through Common Service Centers


through e-District application to Registrar and Additional Registrar




The department should accept validity of a secure, digitally signed database

as an authentic and trustable source for verification.

The frequency of visits to the Tehsil / BDO / CMO by the Field Officer

responsible for Physical Verification must be increased to twice a week.


departments.




Acceptance of Self Declaration with Revenue Stamps affixed on it as a

replacement of Affidavit in Applications for Birth / Death Certificates after

1 year.

Revenue stamps need to be made available at the CSC / e-District Centers.

CSC or e-District centers should be provided with the license to sell Revenue

Stamps

‘T0-Be’ & FRS Report – Pilot e-District, U.P.

185


The new To Be process envisages to provide additional benefits such as:

Accepting applications at the e district centers/CSCs would provide one

more avenue for the applicant to request for Birth Certificates

o Currently, the applicant has to submit the application at the

Municipalities for Urban areas and to the GPAs for rural areas

o For this, applicant needs to physically visits to the Municipality

office along with Medical Certificate for obtaining the certificate

o Hence, the proposed approach would save citizen time and

inconvenience caused in applying for the service at the

Municipalities

Citizen could track the status of application and reason for delay and of

rejection through nearby CSC

The Process owners would be able to better monitor the performance and

service delivery quality through MIS reports.


Birth Certificate within 1 yearG

VP

A (

For

rur

al a

reas

)R

egis

trar

e-D

istr

ict A

pplic

atio

nA

pplic

ant

Yes

Applicant receives

the reason for

rejection

System savesBirth

Certificate in a DB and

notifies the applicant

Applicant receives

the Birth

Certificate

Registrar receives

the application

System saves the rejection

in a DB and notifies the

applicant

Payment

Receipt

System registers the Birth

Certificate and marks to

concerned Registrar


copy of the application,

issues the Birth

Certificate online using

digital sign as per the

Approval compnent

Start

Application

Receipt

Stop

Form

AvailabilityDelivery

Component

Rejects the application

online using digital

sign as per the

Rejection Component

Returns the query result

Details found ?

Checks details in

the database

No

Is Medical

Certificate

provided

Convinced about

the details

Yes

No

Marks the application for a

physical verification by the

Lekhpal

No



into the Birth Certificate

Database

Links the Citizen Database with

the Birth certificate database


change and notifies

Tehsildar

Submits the application back

with the verified detailsReceives the application.

Within 21 days

No

Yes


187


VP

A (

For

rur

al a

reas

)R

egis

trar

e-D

istr

ict A

pplic

atio

nA

pplic

ant

Yes

No

Yes

No

No

Is Medical

Certificate

provided

Registrar receives

the application




Database

Details found ?



concerned Registrar

System savesBirth




Convinced about

the details


with the verified details




change and notifies

Tehsildar



sign as per the

Rejection Component

Receives the application.



Lekhpal



issues the Birth



Approval compnent

Checks details in

the database



applicant

Status Update Status Update Status UpdateStatus Update


188


VP

A (

For

rur

al a

reas

)R

egis

trar

e-D

istr

ict A

pplic

atio

nA

pplic

ant

Yes

No

Yes

No

No



applicant

MIS Component 3

Details found ?



concerned Registrar

MIS Component 1

System savesBirth



Registrar receives

the application


Is Medical

Certificate

provided





Lekhpal







Database



sign as per the

Rejection Component

Checks details in

the database


change and notifies

Tehsildar

Convinced about

the details On receiving the hard


issues the Birth



Approval compnent

MIS Component 2


189

Birth Certificate Beyond 1 yearG

VP

A (

Fo

r ru

ral a

rea

s)A

dd

itio

na

l Re

gis

tra

re-D

istr

ict A

pp

lica

tion

Ap

plic

an

t

Yes

No

Yes

No

No



sign as per the

Rejection Component

Applicant receives

the reason for

rejection



Lekhpal



Stop

Convinced about

the details



change and notifies

Tehsildar

System savesBirth



Is Medical

Certificate

provided



issues the Birth



Approval compnent

Registrar receives

the application



concerned Registrar

Start





applicant

Checks details in

the database

Delivery

Component




Database

Payment

Receipt

Applicant receives

the Birth

CertificateApplication

Receipt

Form

Availability


Details found ?

The Applicant attaches a

Self Declaration with

Revenue Stamps affixed on

it.


190


VP

A (

Fo

r ru

ral a

rea

s)A

dd

itio

na

l Re

gis

tra

re-D

istr

ict A

pp

lica

tion

Ap

plic

an

t

Yes

No

Yes

No

No

Registrar receives

the application



Convinced about

the details


change and notifies

Tehsildar



Lekhpal




Is Medical

Certificate

provided

Details found ?On receiving the hard


issues the Birth



Approval compnent



concerned Registrar

System savesBirth





sign as per the

Rejection Component




Database

Checks details in

the database



applicant

Status UpdateStatus UpdateStatus UpdateStatus Update


191


VP

A (

Fo

r ru

ral a

rea

s)A

dd

itio

na

l Re

gis

tra

re-D

istr

ict A

pp

lica

tion

Ap

plic

an

t

Yes

No

Yes

No

No



applicant



Lekhpal

MIS Component 1



MIS Component 2



issues the Birth



Approval compnent



sign as per the

Rejection Component

System savesBirth



MIS Component 3

Convinced about

the details




Database



Details found ?

Checks details in

the database


Registrar receives

the application

Is Medical

Certificate

provided



concerned Registrar


change and notifies

Tehsildar



S.No Process Details Responsibility Centre

The Applicant writes and signs a Self Declaration

affixed with Revenue Stamps of requisite value. The

Revenue Stamps would be available at CSC.

Applicant

Following application receipt and payment component

the e district application would register the Birth

Certificate for a particular applicant

e District

Application

The kiosk operator would fill in the online form for

Birth Certificate.

e District

Application

E district application forwards the online application to

Registrar for action.

E District

Application

Kiosk operator forwards physical documents and

application form printout to the Registrar Kiosk Operator

Registrar receives the Birth Certificate request for the

applicant generated by the e district application.

Registrar/Additional

Registrar

Registrar checks the documents provided with the

application if convinced he issues the digitally signed

certificate to the applicant, otherwise he forwards the

application to the concerned Lekhpal for field

verification.


Registrar

E district application registers the response of the

Registrar and notifies the Lekhpal (Lekhpal) about the

orders to initiate field verification and RI for

monitoring the Lekhpal working.


GVPA receives notification from the e district

application about the orders updated by the Registrar

to carry out the physical verification.

GVPA

GVPA verifies the veracity of the details provided by

the applicant in the application and he updates the

database based on his physical verification report

GVPA

System registers the change in the database made by

the Lekhpal and notifies the Registrar to review the

report to Lekhpal for information that verification has

been carried out.


Registrar reviews the changes in the Database made by

the Lekhpal on the e district application database.

Registrar can then :

a) If he finds the Lekhpal report favoring the

applicant‟s request then the he approves the

Birth Certificate request and updates it over the

e district application using his digital signature

on receiving the physical documents.


Registrar


193

b) If he finds Lekhpal report stating that the

information submitted by the applicant is false

then the he rejects the application and updates

his rejection over the e district application

stating the reason.

The e district application would host the action taken

by the department head and will notify the relevant

stakeholders.


Birth Certificate Urban– Status Tracking


1

The applicant is notified at the time of application

submission whether his application has been submitted

by the kiosk operator to the e district application and

that e district application has registered his service

request

E District

Application

2 The application would also notify the applicant

whether his application has been rejected or accepted

E District

Application

Database required


1 Birth Certificate database

This database will store all the information about the

application, birth certificates issued and other related

details.

Service Request Form – Birth Certificate

The format of Birth Certificate Form will be same as Form no 1 in Registration of Birth and Death Act 1969.

Records view for a Logged in user

The Records view for the Registrar is as follows:




3 Address

4 Date of Application Submission at CSC/e District Center

5 Due date for decision on application


194

Records view of Registrar for delegating field verification task to Lekhpal.



2 Forward to: (Area-wise list of Lekhpals)

3 Due date for field Verification


195

Monitoring Report

MIS Component 1

The following fields will be required for showing status to Registrar is as follows:

Name of

Verifying

officer

(lekhpal)

Number of

Application

waiting for his

action

Number of

Application

with in Service

Level

Number of

Application

crossed

services level

Number of

Application

Rejected

MIS Component 2

The following fields will be required for showing status to Additional Registrar/SDM

is as follows:

Responsibility

Centre

(Registrar)

Number of

Application

waiting for

action

Number of

Application

with in

Service Level

Number of

Application

crossed

services level

Number of

Application

Rejected

MIS Component 3

The following fields will be required for showing status to DM is as follows:

Responsibility

Centre (SDM)

Number of

Application

waiting for his

action

Number of

Application

with in

Service Level

Number of

Application

crossed

services level

Number of

Application

Rejected


196

Service Level – Birth Certificate Urban


days


1. Application Receipt and Forward to Registrar/Additional Registrar

1 day 1st day

2. Registrar/Additional Registrar checks details in the Database

1 day

2nd day

3. Registrar/Additional Registrar Approves or Rejects the application using his digital sign

2nd day

4. Registrar/Additional Registrar forwards the Application for physical verification

2nd day

5. Physical verification and Updation of the database by Lekhpal

5 days 7th day


Auto Escalation Matrix – Birth Certificate


Service Level

L1

L2

L3


1.

Registrar checks

details in the

Database and either

approves/rejects the

application or

forwards for

verification

Registrar 2 days Additional Registrar

1 day District

Registrar 1 day D.M. 1 day

2.

Additional Registrar

checks details in the

Database and either


application or

forwards for

verification


2 days District

Registrar 1 day D.M. 1 day - -

3.

Physical verification

and Updation of the

database by Lekhpal

Lekhpal 5 days Registrar 1 day Additional Registrar

2 days District

Registrar 2 days


Number of Digital Signature required

S.No Designation officer Number of Digital Signature Used (In – Number)

1 Registrar (Health

Officers and GVAs)

All

2 Additional Registrar

(SDMs)

All SDMs

Functional Requirement Specification: Birth Certificate

S. No. Functional Requirements – Birth Certificate

1. The system should be able to display Birth Certificate related page through

multiple routes

Service links

Information links

District links

2. Should be able to identify the user logging into the system using the login

component.

3. The system should be able to provide information to the citizens about

Electoral related services both in public as well as private domain as per the

„Information component‟


E-District application access to information content

4. The system should be able to channel as per the process map and description

for the service



6. The system should allow the operator to fill in the online application on

behalf of citizen availing the service as per the „application receipt‟

component

7. The System should be able to generate a unique registration number during

registering an applicant with the application.

8. The System should be able to identify the applicant uniquely based on this

registration number.







199

request

12. The System should be able to notify the Registrar / Additional Registrar about

the new application and this date and time must be logged.–


through SMS

through e-mail

13. Should be able to route the application to the Additional Registrar /

Registrar.

14. The system should allow concerned officials to view the service request on

authenticated login

15. The system should allow Registrar/Additional Registrar to accept or reject

any service request application

16. The system should request Registrar/Additional Registrar to provide

comments in case of rejection


of the Registrar /Additional Registrar

18. The system should show service request to concerned Registrar/Additional

Registrar as pending for approval till it is marked for further action

by default the system should be able to auto escalate within the

service level as per the escalation matrix defined

19. The system should load a page to enable Registrar/Additional Registrar to

assign verification responsibility to Lekhpal urban service request

20. The system should auto generate notification to concerned official once the

Registrar/Additional Registrar has assigned officer for physical verification

21. The system should allow the concerned Lekhpal to view the service request

after authentication of username and password

22. The system should allow Lekhpal to print the details of service request

application form to have a hard copy of the same

23. The System should allow the Lekhpal to update the verification details in

relevant database (Birth Certificate Database / Parivar Register database).

24. The System should allow the Lekhpal to electronically forward the application

to the Registrar/Additional Registrar using his digital signature

25. The system should allow concerned Registrar/Additional Registrar to view

changes made in the database by the Lekhpal

26. The system should be able to auto generate MIS reports for the following

officials –

District Magistrate

SDM

Registrar

27. The system should be able to support the status tracking component as

defined in the process map for status tracking


200

28. The system should be able to support the monitoring and reporting

component as defined in the process map for monitoring and reporting



30. The System should be able escalate the application as per the Auto Escalation



31. The system should be able to maintain all records for the login sessions with

date and time

32. The system should be able to provide date and time stamping for all

transactions done with digital signature

33. The System should have a facility for forwarding of the application, with










issued by them.



IT Act 2000.



based system.


201

vi. Death Certificate


The Registration mechanism in the District should allow for the provision of

a database for use in verification process in rural areas

The department should agree to accept service request application from the

applicants through Common Service Centers


through e-District application to Registrar and Additional Registrar




The department should accept validity of a secure, digitally signed database

as an authentic and trustable source for verification.

The frequency of visits to the Tehsil / BDO / CMO by the Field Officer

responsible for Physical Verification must be increased to twice a week.


departments.




Acceptance of Self Declaration with Revenue Stamps affixed on it as a

replacement of Affidavit in Applications for Birth / Death Certificates after

1 year.

Revenue stamps need to be made available at the CSC / e-District Centers.

CSC or e-District centers should be provided with the license to sell Revenue

Stamps


202



Accepting applications at the e district centers/CSCs would provide one

more avenue for the applicant to request for Death Certificates

o Currently, the applicant has to submit the application at the

Municipalities for Urban areas and to the GPAs for rural areas

o For this, applicant needs to physically visits to the Municipality

office along with Medical Certificate for obtaining the certificate


inconvenience caused in applying for the service at the

Municipalities


rejection through nearby CSC

The Process owners would be able to better monitor the performance and

service delivery quality through MIS reports.


Death Certificate within 1 year

GV

PA

(F

or

rura

l are

as)

Re

gis

tra

re-D

istr

ict A

pp

lica

tion

Ap

plic

an

t

Yes

Applicant receives

the reason for

rejection

System savesBirth



Applicant receives

the Birth

Certificate

Registrar receives

the application



applicant

Payment

Receipt

System registers the Death

Certificate application and

marks to concerned Registrar



issues the Birth



Approval compnent

Start

Application

Receipt

Stop

Form

AvailabilityDelivery

Component



sign as per the

Rejection Component


Details found ?

Checks details in

the database

No

Is Medical

Certificate

provided

Convinced about

the details

Yes

No



Lekhpal

No




Database




change and notifies

Tehsildar



Within 21 days

No

Yes


204


GV

PA

(fo

r ru

ral a

rea

s)R

eg

istr

ar

e-D

istr

ict A

pp

lica

tion

Ap

plic

an

t

Yes

No

Yes

No

No

Is Medical

Certificate

provided

Registrar receives

the application




Database

Details found ?


Certificate Application and


System savesBirth




Convinced about

the details






change and notifies

Tehsildar



sign as per the

Rejection Component




Lekhpal



issues the Birth



Approval compnent

Checks details in

the database



applicant

Status Update Status Update Status UpdateStatus Update


205


GV

PA

(F

or

rura

l are

as)

Re

gis

tra

re-D

istr

ict A

pp

lica

tion

Ap

plic

an

t

Yes

No

Yes

No

No



applicant

MIS Component 3

Details found ?

System registers theBirth

Certifictae and marks to

concerned Registrar

MIS Component 1

System savesBirth



Registrar receives

the application


Is Medical

Certificate

provided





Lekhpal







Database



sign as per the

Rejection Component

Checks details in

the database


change and notifies

Tehsildar

Convinced about

the details On receiving the hard


issues the Birth



Approval compnent

MIS Component 2


206

Death Certificate Beyond 1 yearG

VP

A (

Fo

r ru

ral a

rea

s)A

dd

itio

na

l Re

gis

tra

re-D

istr

ict A

pp

lica

tion

Ap

plic

an

t

Yes

No

Yes

No

No



sign as per the

Rejection Component

Applicant receives

the reason for

rejection



Lekhpal



Stop

Convinced about

the details



change and notifies

Tehsildar

System savesBirth



Is Medical

Certificate

provided



issues the Birth



Approval compnent

Registrar receives

the application




Start





applicant

Checks details in

the database

Delivery

Component




Database

Payment

Receipt

Applicant receives

the Birth

CertificateApplication

Receipt

Form

Availability


Details found ?

The Applicant attaches a

Self Declaration with

Revenue Stamps affixed on

it.


207


VP

A (

Fo

r ru

ral a

rea

s)A

dd

itio

na

l Re

gis

tra

re-D

istr

ict A

pp

lica

tion

Ap

plic

an

t

Yes

No

Yes

No

No

Registrar receives

the application



Convinced about

the details


change and notifies

Tehsildar



Lekhpal




Is Medical

Certificate

provided

Details found ?On receiving the hard


issues the Birth



Approval compnent




System savesBirth





sign as per the

Rejection Component




Database

Checks details in

the database



applicant

Status UpdateStatus UpdateStatus UpdateStatus Update


208


VP

A (

For

rur

al a

reas

)A

dditi

onal

Reg

istr

are-

Dis

tric

t App

licat

ion

App

lican

t

Yes

No

Yes

No

No



applicant



Lekhpal

MIS Component 1



MIS Component 2



issues the Birth



Approval compnent



sign as per the

Rejection Component

System savesBirth



MIS Component 3

Convinced about

the details




Database



Details found ?

Checks details in

the database


Registrar receives

the application

Is Medical

Certificate

provided





change and notifies

Tehsildar




The Applicant writes and signs a Self Declaration

affixed with Revenue Stamps of requisite value. The

Revenue Stamps would be available at CSC.

Applicant


the e district application would register the Death

Certificate for a particular applicant

e District

Application

The kiosk operator would fill in the online form for

Death Certificate.

e District

Application


Registrar for action.

E District

Application

Kiosk operator forwards physical documents and

application form printout to the Registrar Kiosk Operator

Registrar receives the Death Certificate request for the

applicant generated by the e district application.


Registrar

Registrar checks the documents provided with the

application if convinced he issues the digitally signed

certificate to the applicant, otherwise he forwards the

application to the concerned Lekhpal for field

verification.


Registrar


Registrar and notifies the Lekhpal (Lekhpal) about the

orders to initiate field verification and RI for

monitoring the Lekhpal working.


GVPA receives notification from the e district

application about the orders updated by the Registrar

to carry out the physical verification.

GVPA

GVPA verifies the veracity of the details provided by


database based on his physical verification report

GVPA

System registers the change in the database made by

the GVPA and notifies the Registrar to review the

report to GVPA for information that verification has

been carried out.


Registrar reviews the changes in the Database made by

the Lekhpal on the e district application database.

Registrar can then :

a) If he finds the Lekhpal report favoring the

applicant‟s request then the he approves the

Death Certificate request and updates it over

the e district application using his digital

signature on receiving the physical documents.


Registrar


210

b) If he finds Lekhpal report stating that the


then the he rejects the application and updates

his rejection over the e district application

stating the reason.



stakeholders.


Death Certificate Urban– Status Tracking


1





request

E District

Application



E District

Application

Database required


1 Death Certificate database

This database will store all the information about the

application, Death certificates issued and other related

details.

Service Request Form – Death Certificate

The format of Death Certificate Form will be same as Form no 4 in Registration of Birth and Death Act 1969.The Medical certificate will be as per Form 4 A in Registration of Birth and Death Act 1969.


The Records view for the Registrar is as follows:




3 Address

4 Date of Application Submission at CSC/e District Center



211

Records view of Registrar for delegating field verification task to Lekhpal.



2 Forward to: (Area-wise list of Lekhpals)



212

Monitoring Report

MIS Component 1

The following fields will be required for showing status to Registrar is as follows:

Name of

Verifying

officer

(lekhpal)

Number of

Application

waiting for his

action

Number of

Application

with in Service

Level

Number of

Application

crossed

services level

Number of

Application

Rejected

MIS Component 2

The following fields will be required for showing status to Additional Registrar/SDM

is as follows:

Responsibility

Centre

(Registrar)

Number of

Application

waiting for

action

Number of

Application

with in

Service Level

Number of

Application

crossed

services level

Number of

Application

Rejected

MIS Component 3


Responsibility

Centre (SDM)

Number of

Application

waiting for his

action

Number of

Application

with in

Service Level

Number of

Application

crossed

services level

Number of

Application

Rejected


213

Service Level – Death Certificate


days


1. Application Receipt and Forward to Registrar/Additional Registrar

1 day 1st day

2. Registrar/Additional Registrar checks details in the Database

1 day

2nd day

3. Registrar/Additional Registrar Approves or Rejects the application using his digital sign

2nd day

4. Registrar/Additional Registrar forwards the Application for physical verification

2nd day

5. Physical verification and Updation of the database by Lekhpal

5 days 7th day


Auto Escalation Matrix – Death Certificate


Service Level

L1

L2

L3


1.

Registrar checks

details in the

Database and either


application or

forwards for

verification

Registrar 2 days Additional Registrar

1 day District

Registrar 1 day D.M. 1 day

2.


checks details in the

Database and either


application or

forwards for

verification


2 days District

Registrar 1 day D.M. 1 day - -

3.

Physical verification

and Updation of the

database by Lekhpal

Lekhpal 5 days Registrar 1 day Additional Registrar

2 days District

Registrar 2 days




1 Registrar (Health

Officers and GVAs)

All

2 Additional Registrar

(SDMs)

All SDMs

Functional Requirement Specification: Death Certificate Urban

S. No. Functional Requirements – Death Certificate

35. The system should be able to display Death Certificate related page through

multiple routes

Service links

Information links

District links

36. Should be able to identify the user logging into the system using the login

component.






38. The system should be able to channel as per the process map and description

for the service





component

41. The System should be able to generate a unique registration number during

registering an applicant with the application.

42. The System should be able to identify the applicant uniquely based on this

registration number.




216




request

46. The System should be able to notify the Registrar / Additional Registrar about

the new application and this date and time must be logged.–


through SMS

through e-mail

47. Should be able to route the application to the Additional Registrar /

Registrar.

48. The system should allow concerned officials to view the service request on

authenticated login

49. The system should allow Registrar/Additional Registrar to accept or reject

any service request application

50. The system should request Registrar/Additional Registrar to provide

comments in case of rejection


of the Registrar /Additional Registrar

52. The system should show service request to concerned Registrar/Additional

Registrar as pending for approval till it is marked for further action

by default the system should be able to auto escalate within the

service level as per the escalation matrix defined

53. The system should load a page to enable Registrar/Additional Registrar to

assign verification responsibility to Lekhpal urban service request

54. The system should auto generate notification to concerned official once the

Registrar/Additional Registrar has assigned officer for physical verification

55. The system should allow the concerned Lekhpal to view the service request


56. The system should allow Lekhpal to print the details of service request


57. The System should allow the Lekhpal to update the verification details in

relevant database (Death Certificate Database / Parivar Register database).

58. The System should allow the Lekhpal to electronically forward the application

to the Registrar/Additional Registrar using his digital signature

59. The system should allow concerned Registrar/Additional Registrar to view

changes made in the database by the Lekhpal

60. The system should be able to auto generate MIS reports for the following


217

officials –

District Magistrate

SDM

Registrar







64. The System should be able escalate the application as per the Auto Escalation




date and time



67. The System should have a facility for forwarding of the application, with










issued by them.



IT Act 2000.



based system.


218

Note: Because of the legal complications involved in the process of registration of an

event of death/birth the decision taken by the State level steering committee will be

the final process to be referred for software design. In this case the Consultant will

be submitting the GOs to be issued by respective authorities and same should be

followed while revising the design of software.


4.2 RTI & Grievance Services

i. RTI

Select Prerequisites for Qualification of Proposed To-Be Process

The PIO for the district (District Magistrate) should accept the provision of

forwarding the applications which could not be marked to any particular

department under the “others category”. All these applications would be then

marked to the DM Office from where it would be routed to concern PIO.

All concerned department should accept the provision of e-District front end

for accepting payment for information material produced basis the service

request at the CSC.

The acknowledgement receipt issued by the front end (CSC) of e-District

should be considered as an authentic document by the department through

which information could be furnished to the applicant.


The new To Be process envisages to provides additional benefits such as:

Accepting payments at the e district centres would provide one more avenue

for the applicant to submit the RTI application fees as well as additional

charges for the information material.

o Currently, the applicant has to submit application fees at the Treasury

Office and gets challan copy.

o For this, applicant needs to physically visits to the PIO office along with

challan copy for obtaining the required information.


inconvenience caused in obtaining Challan from the treasury office.


220

RTI Process

RTI Process

AD

M O

ffic

eD

istr

ict/

Te

hsil/

Blo

ck L

eve

le

-Dis

tric

t A

pp

lica

tio

nA

pp

lica

nt

Form

AvailabilityApplication

Receipt

System registers the RTI

application and marks to

concerned PIO officer

based on RTI request

PIO receives

RTI application

request

PIO officer delegates

work to APIO for

furnishing information

APIO logs in

and checks

work pendency

APIO prepares

information copy &

report

APIO upload scanned

pages and PIO is notified

about the report and

information copy

Check - under

purview of RTI

Act?

PIO approves

the application

Yes

PIO Update

approval and

rejection status

PIO logs in and

verifies APIO

report and

information copy

Rejects application

with stated reasons

No

Payment

Receipt

PIO update

final status

ADM receives

RTI application

request

System registers

work delegation &

notifies to APIO

Delivery

Component

Payment

Component

System registers

payment details

PIO arranges

courier of copy

of Information

to CSC

ADM forwards to

concern PIO for

action

Is application for

his department ?Yes

Route application to

ADM

No

Is info. < 6

pages?

Yes

APIO update report &

PIO is notified about the

report

N

PIO digitally sign the

scanned copy of

information

Applicant gets the payment info – no.

of pages & option for reading or copy

of information through CSC

Is info. <5

pages?Yes

No

Is copy

required from

CSC?

Y

Applicant visits

department – reads & take

copies of desired pages

by making payment

N

No

Sends

physical

copy

Applicant

receives

information

Start Stop

Stop


221

RTI Status Tracking

Status Tracking

RTI Process

AD

M O

ffic

eD

istr

ict/

Te

hsil/

Blo

ck L

eve

le

-Dis

tric

t A

pp

lica

tio

nA

pp

lica

nt

Yes

No

Yes

No

Yes

N

Y

N

No

Sends

physical

copy



report

PIO approves

the application

APIO prepares

information copy &

report

PIO update

final status

PIO arranges

courier of copy

of Information

to CSC

Applicant visits



by making payment

Is copy

required from

CSC?

APIO upload scanned



information copy

PIO receives

RTI application

request

PIO Update

approval and

rejection status

ADM forwards to

concern PIO for

action

ADM receives

RTI application

request

PIO logs in and

verifies APIO

report and

information copy

Check - under

purview of RTI

Act?





System registers

work delegation &

notifies to APIO

Rejects application

with stated reasons

Is application for

his department ?


scanned copy of

information

Is info. < 6

pages?

System registers

payment details


ADM


work to APIO for


APIO logs in

and checks

work pendency

Status

Tracking

Status

Tracking

Status

Tracking


222

RTI Monitoring

MIS

RTI Process

AD

M O

ffic

eD

istr

ict/T

eh

sil/

Blo

ck L

eve

le

-Dis

tric

t A

pp

lica

tio

nA

pp

lica

nt

Yes

No

Yes

No

Yes

N

Y

N

No

Sends

physical

copy

PIO update

final status

APIO upload scanned



information copy

ADM forwards to

concern PIO for

action

Is info. < 6

pages?



report

Rejects application

with stated reasons

PIO receives

RTI application

request

ADM receives

RTI application

request

Is application for

his department ?

APIO logs in

and checks

work pendency

PIO approves

the application

System registers

payment details

PIO arranges

courier of copy

of Information

to CSC


scanned copy of

information

System registers

work delegation &

notifies to APIO

Check - under

purview of RTI

Act?

PIO Update

approval and

rejection status


ADM

PIO logs in and

verifies APIO

report and

information copy


work to APIO for


Applicant visits



by making payment

Is copy

required from

CSC?





APIO prepares

information copy &

report

MIS

Component 1

MIS

Component 2

MIS

Component 3


223

S. No Process Description Responsibility Centre

RTI Process

1

Form availability, application receipt and payment

receipt component are pre-defined process. The output

of the pre-defined process is the input of e-district

application

e-district application

2 The e-district application registers the RTI application. e-district application

3

Once the RTI application has been registered, the e-

district application would notify the concerned PIO

office about the RTI request located at District / Tehsil

/ Block office respectively depending on the service

request.

If the service request is not directed to any of

the above, the e-district application would route

the service request to ADM under “others

categories” section


4

PIO officer at District/Tehsil/ Block level logs into

account and receives and view the RTI application

request

PIO officer

5

PIO officer at District/Tehsil/Block level checks the RTI

request

If the service request qualifies under RTI ACT ,

then PIO officer update “Accepted request”

status into e-district application using digital

signature

If the service request does not comes under the

purview of RTI act, then PIO officer rejects the

service request and updates rejection status into

e-district application using digital signature

If the service request not belongs to his

departmet, then he send to ADM office for

marking of the RTI requet to concer department

PIO officer

6

ADM logs into the e-district application and receive

service request that falls under other categories section

or forwarded from Department. Upon receiving the

request, DM re-routes the service request to concern

PIO for further action

ADM office

7 Upon approval of service request, PIO officer delegates PIO officer


224


service request to APIO for furnishing information within

stipulated timeframe

8

The e-district application registers decision of PIO on

service request and updates approval or rejection status

e-district application notifies APIO for furnishing

information after PIO has delegated the service

request


9 APIO logs into e-district application and receives

notification from PIO

APIO

(District/Tehsil/Block)

10 APIO prepares <action taken report> on the service

request.

APIO


11

APIO uploads <action taken report> into e-district

application and scanned copy of information if it is less

than or equal to 5 pages using his digital signature. APIO

sends the copy of information physically to PIO if it is of

more than 5 pages.

The e-district application would give notification

to the PIO officer about the report.


12

PIO logs into e-district application and verifies the APIO

report.

PIO also checks the copy of information sent by

APIO digitally or physically and give his decision

accordingly

PIO officer


13

PIO on basis of APIO report updates availability of

information of less than 5 pages. He also updates the

number of pages if information is of more than 5 pages

and reading date, time and contact information.


14

Applicant visits CSC and gets the digitally signed

information if pages are less than or equal to 5 by

making payment.

If pages are more than 5 than he gets the option of

making the payment @ Rs 2 per page for all the pages

and courier charges for sending the information

physically or accepting reading request by paying @ Rs

15 per hour.

Applicant

15

PIO on confirmation of receipt of applicant request for

complete information furnishes the information and

send through courier to requesting CSC. PIO update this

PIO


225


on e-District Application.

If applicant has requested for reading than he locks the

reading time and date for applicant in the system.

16

Applicant visits the department on given date and time

and reads the information.

If applicant needs copy of pages than he pays @ Rs 2 per

page and gets the information.

Applicant and PIO

RTI Status Tracking

1.

Upon registration of application, the applicant would

receive communication of approval/rejection of

application through SMS.

If application is rejected then applicant

would be able to view the rejection with

stated reasons through online and CSC/e-

Suvidha centre


2.

Upon final confirmation of service delivery, citizen

would get the final status SMS (ready to collect)

The applicant can check the final status

through Online as well as by visiting to

CSC/e-Suvidha centre which would check

status online.


Database required


1 RTI Database The RTI database will contain RTI application details like

Name, Age, Address, requested information details, etc.

The database would also maintain the status of

approved/rejected applications and status and decision

of PIO. The database would also maintain the work

completion report of APIO along with his comments.

CRUD Matrix for RTI


District Magistrate ■ ■ ■ ■

Additional District Magistrate

■ ■ ■ ■

PIO ■ ■ ■ ■ APIO ■ ■ ■ X


226



X ■ X X

Service Request Form – Right to Information

The format of RTI request form would comprise of following fields:


1 Name of Applicant:

2 Father‟s Name:

3 Village:

4 Block:

5 Tehsil:

6 District:

7 Requested Information details:

8 Date:

9 Applicant‟s Signature


227


PIO / DM record view

The fields required in delegating of service request to APIO under MIS component 1

are as follows:



2 Name of department

3 Requested Information details

4 Date of Service Registration

5 Date of delivery

The fields required in showing the status of approved/rejection application under MIS

component 1 (PIO for approval/rejection of service request) are as follows:

PIO record view



2 Status ( Approved/Rejected)

3 PIO officer details

4 Reasons of rejections, if any

The fields required in delegating of service request to APIO under MIS component 2

are as follows:

PIO/APIO record view



2 Name of APIO

3 Date of service delivery

The fields required for updating service request by APIO under MIS component 2 are

as follows:




2 Subject details

3 Availability of Information (Yes/No)


228

The fields required in showing the final status under MIS component 3 are as follows:

PIO record view




3 Status (Work in progress/Ready to collect)

4 PIO officer details

Monitoring Report

The following table specifies the fields required in the MIS Report (MIS component 1)

generated for the DM

S.

No

Name of the

Department

Number of

Applications

received by

PIO

Number of

Applications

for which

affirmative

action taken

by PIO

Number of

Applications

for which

action taken by

PIO is delayed

Number of

rejection

applications

by PIO with

stated

reasons


generated for the PIO

S.

No

Name of

the

department

Number of

Applications

processed by

APIO

Number of Applications

for which action taken

by APIO is delayed

Number of

Applications for which

information was not

available with APIO



S.

No

Name of

the

department

Number of

Applications

successfully

processed and

final information

updated by PIO

Number of


action taken by PIO is

delayed

Number of


information was not

available with PIO


229

Internal Service Level – RTI

S. No. Activities Time required Service Level ( from date of service request)

1. Filling of application

2 Day

Day 0

2. Submission of

Application

Day 0

3. Online filling of

application

Day 0

4. Generation of Receipt Day 0

5. PIO approval of

application and

updating status onto e-


2nd day

6. ADM forwards to PIO 2nd day

7. PIO delegating

information to APIO for

further action 2 day

4th day

8. APIO logs in and receive

communication from PIO

4th day

9. APIO furnish information

and prepares report 7 days

11th day

10. APIO Uploads work

completion report and

status onto e-district

application

2 day

13th day

11. PIO logs onto e-district

application and verifies

report and information

copy provided physically

by APIO

3 days

16th day

12. PIO updates final status 2 day 18th day

13. Confirmation on

readiness and

availability of

information against

service request

2 days

20th day


230

Auto Escalation Matrix – RTI


Service Level

L1

L2

L3


1. Approving/Rejecting

RTI request PIO 2nd day ADM 1 day DM

2. Routing

RTI request ADM 2nd day DM 2 days

3. Action on RTI

request APIO 13th day PIO 2 days ADM 2 days DM

4. Updation on final

status PIO 20th day ADM 2 days DM


231



1 District Magistrate 1

2 Public Information

Officer

All PIOs (District, Tehsil and Block)

3 Assistant Public

Information Officer

All APIOs (District, Tehsil and Block)

Functional Requirement Specification – (RTI)

Sr. Description

1. The system should be able to display RTI related page through multiple

routes

Service links

Information links

District links


by the security guidelines

3. The system should be able to provide information to the citizens about RTI

related services both in public as well as restricted domain as per the




4. The system should prompt the user to mention whether it‟s a fresh grievance

or an escalation of the existing grievance. If its an escalation of the existing

grievance it should prompt the user to mention the old grievance registration

number along the grievant details. As soon as the grievant provides the

registration number of the old grievance all the related fields in the

grievance registration form should be auto filled with the help of entries

made in the database.

5. The system should provide all services under RTI under a single category

6. The system should be able to channel as well as handle different RTI as per

the process map and relevant description for the service mentioned

7. The system should be able to retrieve relevant service request form using


232

Sr. Description

„form availability‟ component

8. The system should be able to retrieve service request form



component

CSC operator

Suvidha Kendra Operator

10. The system should be able to generate a unique registration number during

registering an applicant with the system as per the „application receipt‟

component

11. The system should be able to identify the applicant uniquely based on this

registration number for all future references

12. The system should be able to issue an acknowledgement receipt once the

applicant is registered with the system as per „application receipt‟

component

13. The system should be able to come up with final confirmation screen

indicating successful submission of service request

14. The system should be able to allow service fees payments for the RTI service

as per the „Payment Component‟

15. The system should be able to route the service request to concerned officer

(Public Information Officer - PIO) at the following levels –

Block

Tehsil

District

16. The system should be able to route service request basis following criteria –

Name of Block / Tehsil

Name of Department (in case of district)

17. The system should have the functionality to accept service request even if

the service request is not directed to block, Tehsil or department under

“others categories”

18. The system should be able to route such application to DM office for further


233

Sr. Description

re – routing

19. The system should be allow DM to allocate service request to concerned PIO

for service request under “other categories”

20. The system should save re-routing only when the DM digitally signs the re-

routing of the service request

21. The system should auto generate notification of pending service delivery

request to concerned PIO on successful submission of service request

through CSC / e-Suvidha Kendra

through DM office

22. The system should allow the concerned PIO to accept / reject the service

request as per the guidelines of the RTI act

23. In case of rejection, the system should allow the concerned PIO to state the

reason of rejection

24. In case of acceptance, the system should open a new page with all the

accepted service request by the concerned PIO

25. The system should allow the PIO to allocate service request to Assistant

Public Information Officer (APIO)

26. The system should save the acceptance / rejection only on digital signature

of the PIO

27. The system should auto generate notification to concerned APIO about

service request allocation by the concerned APIO

28. The system should allow APIO to view service request as assigned by the PIO

29. The system should allow APIO to print the individual service request

The system should be allow printer friendly version of service request

30. The system should allow the APIO to submit report on the service request on

defined values as given in the process description

31. The system should submit the report only when it is digitally signed by the

APIO

32. The system should auto generate email to concerned PIO about the report

submission against the service request by the APIO

33. The system should open a page for PIO to fill in specific details on documents


234

Sr. Description

pertaining to the service request as defined in the process description

34. The system should ask for digital signature of PIO for submission of the final

delivery against the service request

35. The system should ask for re-confirmation of PIO before actually submitting

the form

36. The system should show a successful submission screen on completion of the

submission





39. The system should be able to auto escalate the service request if the service

levels are not met as defined in the service level description for the process

40. The system should follow the escalation matrix as defined for the process


date and time




235

ii. Grievance Process

Grievance Redressal System

E-D

istr

ict

Ap

plic

atio

nD

M O

ffic

eD

epar

tmen

tC

lien

t /

Cit

izen

NO

Yes

Comes on the

prescribed

date to CSC

Officer login and

checks complaints

assigned to him

Receives Status

of Grievance

Assigns officer for redressal of

complaints with deadline and

instruction

Is grievance

redressed

Officer resolves the

complaint in 15 days


Grievance and sends to

District MagistrateATR is updated and

trigger is generated

for the applicant

Form

Availability

Application

Receipt

Payment

Receipt

text

HoD receives

grievance

Receives

Grievance

Officer fills Action taken

report using his login ID

Check?

HoD assign IO

(Investigation Officer)

for redressal

Rejects application

with stated reasons

Update status as

marked with IO

Update status

as rejected

HoD approves

Action taken

report

Delivery

Component

Payment

ComponentPayment

Component

Applicant gives feedback on

redressal of Grievance on scale

of 5 with defined reason if

option is highly unsatisfied

CSC operator

records feedback


236

Grievance Redressal System- Status Tracking

Grievance Redressal System – Status Tracking

DM

Off

ice

Dep

artm

ent

E-D

istr

ict

Ap

plic

atio

nC

lien

t /

Cit

izen


Grievance and marks to

concerned HoD based on

Name of Department

Officer login and

checks complaints

assigned to him

Receives

Grievance

Check?

HoD assign IO


for redressal

Officer fills Action

taken report using

his login ID

Update status as

marked with IO



instruction on same day

HoD approves

Action taken

reportHoD receives

grievance



Update status

as rejected

Rejects

application with

stated reasons

ATR is updated and


for the applicant

Status Tracking

component

Status Tracking

component

Status Tracking

component


237

Grievance Redressal System - Monitoring

Grievance Redressal System - Monitoring

DM

Off

ice

Dep

artm

ent

E-D

istr

ict

Ap

plic

atio

nC

lien

t /

Cit

izen

Officer login and

checks complaints

assigned to him

ATR is updated and


for the applicant

Receives

Grievance

HoD assign IO


for redressal

Payment

Receipt

Rejects

application with

stated reasons


Grievance and marks to

concerned HoD based on

Name of Department

Check?

HoD receives

grievance

Officer fills Action taken

report using his login ID

Update status

as rejected



Update status as

marked with IO



instruction on same day

Application

Receipt

HoD approves

Action taken

report

Form

Availability

MIS

Component 1

MIS

Component 2

MIS

Component 3


238


RTI Process

1

Form availability, application receipt and payment receipt

component are pre-defined process. The output of the

pre-defined process is the input of e-district application


2 The e-district application registers the Grievance from

citizen. e-district application

3 Once the Grievance has been registered, the e-district

application would notify DM for marking to department e-district application

4

DM logs onto e-district application and receive service

request. Upon receiving, DM checks the service request

and marks to HoD of relevant department

DM office

5 HoD officer at District/Tehsil/ Block level logs into

account and receives Grievance HoD

6

HoD officer at District/Tehsil/Block level checks the

Grievance

HoD update approval status and assigns

Investigation Officer (IO) onto e-district application

using his digital signature

If the grievance is not genuine, then HoD officer

update rejection status with reason onto e-district

application using his digital signature

HoD

7 The e-district application registers service request of HoD

and notifies to IO e-District application

8 IO logs onto e-district application and receive notification

from HoD

IO


9

IO upload action taken report onto e-district application

using digital signature. The e-district application would

give notification to the HoD about the report.

IO


10 HoD logs onto e-district application and verifies the action

taken report.

HoD


11 HoD on basis of IO report updates his decision and final

status. e-district application

12

The applicant visits CSC with application receipt issued by

CSC during grievance registration and gets the copy of

Action taken Report after payment of service charges

Applicant

13

Applicant gives feedback on scale of 1 to 5 (Highly

Unsatisfied, Unsatisfied, Neutral, Satisfied, and Highly

Satisfied). If applicant selects option Highly unsatisfied

Citizen


239

than he has to select the reason from one of the following

options

Investigation is not conducted at field

Discussion with applicant has been not done

Investigation was biased

Grievance Status Tracking

3. The applicant would be able to know the status of the

grievance through SMS, Online and CSC/e-Suvidha centre. e-district application

4.



application through SMS. If application is rejected then

applicant would be able to view the rejection with stated

reasons through online and CSC/e-Suvidha centre.


5.

The applicant would check the final status through Online

or visiting to CSC/e-Suvidha centre. Through SMS the

applicant would get the final status (work in progress/

ATR ready to collect).


S.No Process Description Monitoring Centre

Grievance Monitoring

1.

The monitoring component <MIS 1> relates to monitor the

processing of service request for grievance at the

following intermittent point –

When the grievance is rejected by the HoD

When the Investigation Officer appointed by HoD

MIS Component 1

2.

<MIS 1> component will monitor and track the following

on the defined service levels –

Successful receival of the application form

Action taken by the DM/HoD on the Grievance

MIS Component 1

3.

<MIS 1> component will auto generate daily report for

the DM and provide the information given in subsequent

section Monitoring report

MIS Component 1

4. The monitoring component <MIS 2> relates to monitor the

successful completing the service request by the HoD MIS Component 2

5.



Disposal of the grievance and submission of

ATR by IO

Authentication and verification of disposal by

HoD

MIS Component 2


240

6.

<MIS 2> component will auto generate daily report for

the HoD and provide the information given in subsequent

section Monitoring report

MIS Component 2

7.


successful completing the overall activity against the

grievance

MIS Component 3

8.


service delivery on the defined service levels –

Grievance is redressed by HoD

Effectiveness and efficiency of Department in

redressal of grievance

MIS Component 3

9.

<MIS 3> component will auto generate weekly report for

the DM/Secretary and Chief Secretary to provide the

information given in subsequent section Monitoring

report

MIS Component 3

Database required


1 Lokvani Grievance Database

The Lokvani Grievance database will contain existing

details with additional details like escalation matrix, and

feedback from citizen.

Service Request Form – Grievance

The format of Grievance redressal form would comprise of following fields:


Name of Applicant:

Father‟s Name:

Village:

Block:

Tehsil:

District:

Subject of Grievance:

Details:

Name of department (if Known):

Self declaration:

Date:

Applicant Signature


241


DM record view



2 Name of department ( to be selected by PA to DM)

3 Grievance details

4 Date of filling of Grievance

5 Date of disposal

The fields required in showing the status of approved/rejection application under MIS

component 1 (HoD for approval/rejection of service request) are as follows:

HoD record view




3 HoD officer details

4 Reasons of rejections, if any

The fields required in delegating of service request to Investigation Officer (HoD can

appoint himself also as IO) under MIS component 2 are as follows:

HoD/IO record view



2 Name of IO

3 Date of Action Taken Report (ATR) submission

The fields required for updating service request by IO under MIS component 2 are as

follows:

HoD/IO record view



2 Action Taken Report (ATR)

3 Date of ATR submission (Locked Field)


242


DM record view


1 Name of HoD

2 Number of grievances assigned

3 Number of grievances disposed

4 Number of grievance delayed in redressal by less than or equal to 3 days

5 Number of grievance delayed in redressal by more than 3 days

6 HoD officer details


243

Monitoring Report



S.No Name of the HoD

Number of Grievances received by HoD

Number of Grievance for which IO has been appointed

Number of Grievances for which appointment of IO is delayed by HoD

Number of Grievances rejected by HoD with stated reasons

1.

2.


generated for the PIO

S.No Name of the Investigation Officer

Number of Grievances processed by Investigation Officer

Number of Applications for which action taken by IO is delayed by 5 days

Number of Applications for which action is delayed by IO by more than 5 days

1.

2.



S.No Name of the HoD

Number of Grievances redressed and ATR approved by HoD with marks*

Number of Grievances for which action taken report by HoD is delayed by less than or equal to 3 days

Number of Grievances for which action taken report by HoD is delayed by more than 3 days

1.

2.

*Note: Marks will be represented as {<Efficiency> & <Effectiveness>}

Efficiency will ratio of Number of complaints disposed and number of complaints arrived

Effectiveness will be average of feedback points received from citizen. In case of no feedback from citizen highest marks i.e 5 will be given to officer.


244

Service Level - RTI


14. Filling of grievance

1Day

Day 0

15. Generation of Receipt

Day 0

16. Marking of grievance to HoD

1st day

17. Appointment of Investigation Officer (IO) by HoD

2 day

3rd day

18. IO logs in and receive communication from HoD

3rd day

19. IO does redressal of grievance

9 days 12th day

20. IO Uploads Action Take Report (ATR) on e-district application

1 day

13th day

21. HoD logs onto e-district application and verifies ATR submitted by IO & Availability of ATR against grievance

2 days

15th day


245

Auto Escalation Matrix


Service Level

L1

L2

L3


5. Approving/Rejecting/Marking

Grievance DM 1st day Commissioner

2 day

Chief Secretary

6. Approving/Rejecting/Appointing

Investigation Officer by HoD HoD 3rd day DM

2 day

Commissioner 2

day Chief

Secretary

7. Action on Grievance Investigation

Officer 12th day

HoD 2

day DM

3 day

Commissioner

8. Verification and release of redressal on e-District site

HoD 15th day

DM 3

day Commissioner

5 day

Chief Secretary


246



1 District Magistrate 1

2 ADM 2

3 HoD of all 10

Departments

10

4 SDM All SDM

5 Tahsildar All Tahsildar

6 BDO All BDO

Functional Requirement Specification – (Grievance)

Sr. Description

43.

E district Application is the application meant for maintaining all the

transactions related to e district services. With regard to filing grievance

the application i.e. the Lokvani Grievance Redressal System deals right

from grievance filing to obtaining Action Taken Report by the applicant.

44. Should be able to identify the user logging into the system as per the login

component

45. Should be able to provide information to the citizens about details related

to grievance filing.

46. Should be able to generate a unique registration number during registering

an applicant with the application. Should be able to identify the applicant

uniquely based on this registration number.

47. Should be able to issue an acknowledgement receipt once the applicant is

registered with the system.

48. Should be able to map the payment details of the transaction with the

kiosk

49. Should be able to mark the application to the District Magistrate for

grievance redressal

50. Should maintain records of all the grievances filed through the Lokvani

Kendras for a particular period of time.


247

Sr. Description

51. Should allow the DM to reject any frivolous grievances using the rejection

component.

52. Should be able to help the District Magistrate to assign officials to take

action on the filed grievance

53. Should allow the stakeholders to track the application status at different

stages as per the status tracking component.

54. Should allow the assigned officer the Action Taken Report over the system

duly digitally signed by him

55. Should be able to store soft copy of Action Taken Report (ATR) in database

and generate trigger for CSC / Applicant that the certificate has been

prepared and he can take a printout of the same.

56. Should be able to auto generate grievance to higher authorities in case

specified SLAs are not met by the officials as per the auto escalation

mechanism of monitoring component.

57. Should generate monitoring reports on specified time intervals and send it

to relevant authorities

58. Should provide access to authorities to monitor Application Status /

Performance / SLAs for a particular period by logging onto the system

59. Should allow the user to take a print out of the soft copy of the Action

Taken Report as per the delivery component

60. Should provide a site map at the opening page of the application

61. Should be able to deliver the output (ATR – Printout) from any of the

registered centres

62. Should be able to send SMS to applicant in case of missing of final SLAs and

status tracking.


248

4.2 Election Related Services

Select Prerequisites for qualification for To-Be Process

The district administration should agree to the service charter of Election

Commission of India mentioning that processing of service request for updation

of electoral roll should happen throughout the year. However, the updation of

records would happen only on receiving notification from Election Commission

of India.

The government should agree to accept service request application from the

applicants through Common Service Centres. Also, if any approval /

confirmation from Election Commission of India is required for receiving service

request at Common service center needs to be taken before initiating the

service through e-District application.


through e-District application to RI from SDM without being manually forwarded

by him as a noting on service request file.

The department should accept the validity of digital signature instead of

physical signing and stamping by concerned SDM and the ADEO who would be

responsible for updation in Electoral Database.

The government and Election Commission of India should agree to the provision

of SCA / Delivering agency charging a „convenience fees‟ for service either

from the citizen to make the service request process self sustainable.

Alternatively government should have arrangement with SCA / delivering

agency for payments against the services rendered for election related issues.



Citizen would be able to make service request through Common Service

centers for updation in electoral rolls as compared to „As-Is‟ scenario when

camps, etc were organized.

Better front ending for receiving service request from the citizen in terms

of multiple common service center in proximity


249

ADEO would approve digitally signed electronic database for making

updation in electoral database on the direction of Election Commission


rejection through near by CSC


250

Electoral Roll Updation Process

Updation in Electoral Roll

Electoral Services

Dis

tric

t le

ve

l A

cto

rsT

eh

sil

Le

ve

l A

cto

rsE

-Dis

tric

t A

pp

lica

tio

nC

lien

t / C

itiz

en

ADEO office receives

the application

electronically only

SDM office receives

application electronically

and marks for processing

ADEO office cross

verifies application

ADEO office updates

service request

SDM marks

application to RI

RI and Lekhpal

receives work

delegation order

Electoral

Database

System notifies

SDM

ADEO office receives records

electronically and waits for

election notification

Citizen reads electoral

modification from public display

including CSC/suvidha kendra

System gets

updated on

verification

ADEO office displays at

public notice board

modified electoral Roll

Form

AvailabilityApplication

Receipt

Application registered &


SDM office

After Notification

copies record in

election database

Lekhpal

submits

report online

SDM approve /rejects

verification report and

digitally signs

System gets

updated on

approval / rejection

Electoral

Database

System notifies

ADEO

Start

Stop


251

Electoral Roll Updation Request - Status Tracking


Status Tracking

Te

hsi

l Le

vel A

cto

rsD

istr

ict le

vel A

cto

rsE

-Dis

tric

t A

pp

lica

tion

Clie

nt

/ C

itize

n

RI and Lekhpal

receives work

delegation order

ADEO office updates

service request System gets

updated on

verification

System notifies

ADEO


public notice board

modified electoral Roll

SDM office receives





digitally signs

Status

Tracking

component


the application

electronically onlyADEO office receives records



Electoral

Database

System notifies

SDM

Electoral

Database

SDM marks

application to RI

System gets

updated on

approval / rejection

After Notification

copies record in

election database

Citizen reads electoral

modification from

public display

including CSC/

suvidha kendra

ADEO office cross


Lekhpal

submits

report online



SDM office

Status

Tracking

component


252

Electoral Roll Updation- Monitoring


Monitoring

Te

hsi

l Le

vel A

cto

rsD

istr

ict le

vel A

cto

rsE

-Dis

tric

t A

pp

lica

tion

Re

ceiv

ing

Au

tho

rity

System notifies

ADEO

System notifies

SDM

MIS

Component

3

System gets

updated on

approval / rejectionSDM marks

application to RI

Electoral

Database

SDM office receives



MIS

component

1

Lekhpal

submits

report online

System gets

updated on

verification

ADEO office updates

service request


public notice board

modified electoral RollElectoral

Database

ADEO office cross


After Notification

copies record in

election database

ADEO office receives records



RI and Lekhpal

receives work

delegation order


the application

electronically only



digitally signs



SDM office

MIS

component

2


253

S. No Process Description Responsibility

Electoral Roll Updation Process

1


receipt component are pre-defined processes. The

outputs of the pre-defined process are input to e-



2 The e-district application registers the Application for

Updation in forms 6, 7, 8 and 8 A format e-district application

3

Once the Electoral application has been registered, the

e-district application would notify concerned SDM office

and ADEO about the Updation request.


4 SDM will log into his / her account, digitally Signs and

forward it for conducting field verification to the RI SDM

5

ADEO checks service details against electoral database

to establish authenticity of service request and

undertakes following action by digitally signing it –

marks discrepancy in the service request to SDM

recommend for further action to SDM

ADEO

6

SDM updates approval / rejection on service request in

the e-district application

SDM approves the recommended service request

and marks it for felid verification to RI

SDM rejects service request having discrepancy

as noted by the ADEO

SDM

7

RI logs into his account and views all job listed for his

action and allocates the field verification work to

concerned Lekhpal

Revenue Inspector

8

Lekhpal views task for his action, conducts field

verification and upload Field verification report in

system using his Log in ID and Password.

Lekhpal

9

RI verifies the field verification report gives their

comments and submits using their Log in ID and

Password

RI

10 SDM approves/disapprove/asks for re-verification by

using his digital signature SDM

11

ADEO gets the digitally signed record for updation in

electoral database from SDM.

ADEO cross verifies record for duplicity in

database and digitally signs all records

ADEO


254


12 ADEO updates records in electoral database on direction

received from Election Commission of India ADEO

13

The updation details will be displayed at public places

and CSCs for applicant information. SMS will be sent to

Applicant informing acceptance and rejection of his

application.

SDM/e-District Application

Electoral Roll Updation Status Tracking

1.

The applicant would be able to know the status of

registered Electoral Roll Updation application through

SMS, Online and CSC/e-Suvidha centre.


2.



application through SMS.

If application is rejected then applicant

would be able to view the rejection with

stated reasons through online and CSC/e-

Suvidha centre.


3.

Upon final confirmation of service delivery, citizen

would get the final status SMS (ready to collect)

The applicant can check the final status

through Online as well as by visiting to

CSC/e-Suvidha centre which would check

status online.


Database required


1 Electoral Database

The Electoral database will contain Electoral application

details like Name, Age on 1st January <current year> in dd

mm yy format, Date of Birth, Gender, Place of Birth,

Village/city, District, State, Local Address, Section

number of Election Area and its Serial Number and other

details. The database would also maintain the status of

approved/rejected applications and final status/decision.

Service Request Form – 6, 7, 8, 8 A (For Electoral Roll Updation)

The format of request forms has following fields:


255


1 Details of Applicant


3 Nick Name (If any):

4 Age on 1st January of current year (in mm, yyy format):

5 Sex:

6 Date of Birth:

7 Place of Birth:

Village/City-

District-

State-

8 Father‟s Name:

9 Mother‟s Name:

10 Husband‟s Name:

2 Details of temporary Residence

1 House No.:

2 Area/ Sub Area/ Colony/ Road/ Lane:

3 City/Village:

4 Post Office:

5 PIN Code:

6 Tehsil/Taluka /Mandal/Police Station:

7 District:

3 Details of the family member of applicant who has been already part

of present voter list of election area

1 Name

2 Relationship with applicant

3 Section No. of Voter List

4 Sr. No. under Section

5 Electoral Photo ID Card Number

4 Receipt of Application

1 Name

2 Residence

3 Signature of officer signing on behalf of ERO


256


The fields required in showing the status of registered application to CSC/e-Suvidha

for applicant are as follows:




3 Address

4 Date of Application Submission at CSC/Suvidha Kendra


6 Date of display of revised electoral roll

The fields required in showing the status of approved/rejection application to CSC/e-

Suvidha for citizen are as follows:





4 Reason of rejection (In case of rejection)

5 Contact information of SDM

The fields required in showing the final status to the applicant are as follows:




3 Status (Work in progress/Confirmation of updation in Electoral Roll)

4 SDM details

The fields required for SDM for delegating of service request to ADEO under MIS

component 1 are as follows:

SDM record view



2 Date of reverting back after verification from Electoral Database

3 Date of service delivery


257

The fields required for updating service request by SDM for delegating task to RI:

SDM record view



2 Responsibility Centre ( RI)


Similar functionality would be given to RI for delegating field verification task to Lekhpal respectively The fields required in updating reason of rejection are as follows:

RI record view




3 Reason of Rejection

4 Verification officer details

Monitoring Report

MIS Component 1

The following fields will be required for showing status to SDM is as follows:

Responsibility

Centre (ADEO)

Number of

Application

waiting for his

action

Number of

Application

with in Service

Level

Number of

Application

crossed

services level

Number of

Application

Rejected

MIS Component 2

The following fields will be required for showing status to SDM is as follows:

Responsibility

Centre (RI)

Number of

Application

waiting for

action

Number of

Application

with in Service

Level

Number of

Application

crossed

services level

Number of

Application

Rejected


258

MIS Component 3


Responsibility

Centre (SDM)

Number of

Application

waiting for his

action

Number of

Application

with in Service

Level

Number of

Application

crossed

services level

Number of

Application

Rejected


259

Service Level – Electoral Roll Updation


1. Filling of application

1Day

Day 0

2. Submission of

Application

Day 0

3. Online filling of

application

Day 0

4. Generation of Receipt Day 0

5. SDM approval of

application and

updating status onto e-


1st day

6. SDM delegating

verification task to RI

for further action 1 day

2nd day

7. RI logs in and receive

communication

2nd day

8. RI conduct field

verification and

prepares report

7 days

9th day

9. RI Uploads work

completion report and

status onto e-district

application

1 day

10th day

10. SDM logs onto e-district

application and verifies

report

3 days

13th day

11 ADEO receives request

for updation in electoral

rolls and approves for

updation

2 day

15th day


260

Auto Escalation Matrix – Electoral Roll


Service Level

L1

L2

L3


1. Approving/Rejecting

Updation request SDM 1st day DM 1 day

2.

Delegating field

verification work to

RI

SDM 2nd day DM 1 day

3. Field Verification RI 10th day SDM 2 day DM 2 day

4.

Verification and

approval of SDM &

sending request to

ERO

SDM 13th day DM 1 day

5.

Acceptance of

application and

listing up for

updation

ADEO 15th day DM 1day


261



1 SDM All SDMs

2 ADEO 1

Functional Requirement Specification – (Electoral Roll Updation)

Sr. Description

1 The system should be able to display Electoral Service related page through

multiple routes

Service links

Information links

District links

2 The system should be able to identify user login into the system as defined


3 The system should be able to provide information to the citizens about





4 The system should provide Updation of Electoral Roll services at single

location

5 The system should be able to channel as per the process map and description

for the service

6 The system should be able to retrieve relevant service request form using


7 The system should be able to retrieve service request form when requested

through appropriate links on the e-district application

8 The system should allow the operator to fill in the online application on


component

9 The system should be able to generate a unique registration number while


component

10 The system should be able to identify the applicant uniquely based on this


11 The system should be able to issue an acknowledgement receipt once the

service application is registered with the system as per „application receipt‟


262

component

12 The system should be able to come up with final confirmation screen


13 The system should refresh the page in case of failure in submission of service

request

14 The system auto generate notification to the concerned officials – SDM /

ADEO about service request –


through SMS

through e-mail

15 The system should be able to route the service request to concerned SDM

office immediately on successful service request submission and should

reflect to following officials –

Concerned SDM

Assistant District Electoral Officer

16 The system should allow concerned officials to view the service request on

authenticated login

17 The system should allow SDM to accept or reject any service request

application

18 The system should allow SDM to provide comments in case of rejection

19 The system should save the acceptance / rejection only after digital

signature of the SDM

20 The system should show service request to concerned SDM as pending for

approval till it is marked for further action

by default the system should be able to auto escalate non approval

within the service level as per the escalation matrix defined

21 The system should load a page to enable SDM to assign verification

responsibility to Revenue Inspector service request

22 The system should auto generate email notification to concerned official

once the Revenue Inspector has assigned officer for physical verification

23 The system should allow the concerned Lekhpal to view the service request


24 The system should allow Lekhpal to print the details service request


25 The system should allow the Lekhpal to upload „Verification Report‟ by

logging into e-District Application

the system should allow encoding of verification request using digital

signatures


263

26 The system should allow concerned Revenue Inspector / Block Development

Officer to view „Verification Report‟

27 The system should allow the Revenue Inspector to do either of the following –

recommend for approval and forward the service application request

to SDM

recommend for rejection and forward service request application

with stated reason

28 The system should allow concerned SDM to digitally sign the approval and

rejection

29 The system should auto generate notification for ADEO on submission of

approval / rejection of service request

30 The system should allow ADEO to view the approval / rejection marked by

SDM on the service request

31 The system should allow ADEO to download the fields of approved service

request application from e-district application and save it in compatible

format as that of election database

32 The system should allow to download only on authentication through digital

signature

33 The system should be able to auto generate MIS reports for the following

officials –

District Magistrate

SDM

ADEO

34 The system should allow the concerned department head to log into the e-

district application using the authenticated login and password as defined in

the login process

35 The system should be able to support the status tracking component as


36 The system should be able to support the monitoring and reporting


37 The system should be able to auto escalate the service request if the service


38 The system should follow the escalation matrix as defined for the process

39 The system should be able to maintain all records for the login sessions with

date and time

40 The system should be able to provide date and time stamping for all



264

4.2 Pension Related Services

Pension Rural

Pension Urban

Select Prerequisites for qualification for To-Be Process (Rural)

The department should accept the provision for acceptance of service request

throughout the year instead of application acceptance during a particular period of

year.

The department should accept the provision of Common Service Centre / e District

Centres accepting service request application from the applicants.

The department should accept the provision of providing digital signature to

concerned BDOs, GVAs, DM and the Department Heads who would be involved in

processing of service request.

The department should accept the provision of forwarding service request to GVA

and BDO simultaneously through e-District application without being manually

forwarded by BDO as a noting on service request file.

The department should accept the GVA forwarding digitally the beneficiary List and

the Anumodan details over the e District application to the BDO.

The department should accept the provision for review and approval of Anumodan

by the BDO in the electronic form over the e district application.

The department should accept the provision of Gram Sabha preparing waitlist of

beneficiaries after allocated quota of pension is full for the concerned village. This

would allow auto selection of waitlisted candidates in case of removal of any

beneficiary from the current list.

The department should accept the provision of SCA / Delivering agency charging a

convenience fees from either the citizen or department to make the process self

sustainable.


265



Preparation of Anumodan database based on the Anumodan passed during the

Khuli Baithak conducted by the Gram Sabha would help in proper monitoring and

maintenance of records as well as bring in transparency in the local governance

system.

Preparation of beneficiary waitlist in order of priority leading to auto selection of

waitlisted applicant in case of removal of any current beneficiary from the

pensioners list. The reasons for the removal of beneficiary from the current list

might be death, qualifying for any other pension, disqualification due to status

upgradation, change of location etc.

Preconditions for qualification for To-Be Process (Urban)

The department should accept the provision of forwarding the service request to

Concerned SDM, Tehsildar, Revenue Inspector and Lekhpal simultaneously. Though

the action would be initiated at the end of Lekhpal only on receiving orders from

Tehsildar.

The department should allow the provision for initiating work on service request, as

soon as service request is registered and the processing of service request will be

initiated without receival of physical documents. The proposed system would

however issue the final delivery of service only on receiving the service request and

the required documents in physical form.

The department should accept revision of roles and responsibilities of Revenue

Inspector with key focus on monitoring the work of Lekhpal.

The Department should accept providing of reasons for rejection of a particular

service request to the applicant.


The new To Be process will add value to service delivery in following way –

Improvement in service levels for service level as now the service request will be

accepted through out the year. Provision for creation of waitlist for approved service


266

request in case of no quota availability for the pension request has been envisaged

in the process

De-funneling of “routing” of service request in the proposed To Be Process as

service Request would be routed to all the concern authorities simultaneously


267

Pension Disbursement – Rural

Pensions – Rural

Dep

t.Hea

d G

ram

Sab

ha

GV

AE

-Dis

tric

t App

licat

ion

BD

O /

AD

O (

GP

) A

pplic

ant

Receives report

about the pension

applications

Generates reports

for BDO and marks

to GVA based on

requests received

Matches it with quota

availability and

allocates village wise

pension targets

Gram Sabha approves

beneficiary list (current

and waiting) through

anumodan & hands over

anumodan + list + forms

to GVA

GVA in presence of ADO

conducts khuli baithak and

puts forward the received

application for discussion

Database gets

updated and BDO

is notified about

the list

Approves & forwards

beneficiary list and

updates DB on

receiving filled forms

from GVA

Verifies

anumodanOk

No

Receives approved

beneficiary list

Matches applications

against the fund

availability

Availability

Approves pension

disbursal and updates

DB

Puts name in waitlist

and updates DB

Yes

No

Database gets

updated and Dept.

Head is notified

about the list

Database gets

updated

Quota

Payment

Component

Application

Receipt

Component

Receives report about

the pension

applications

On receiving Filled

forms from CSC,

applicant’s request and

BDOs orders conducts

khuli baithak

GVA can also take

new applications in

the Khuli Baithak

Updates village wise

pension details

against quota

availability and

notifies GVA

Feeds in the details of

anumodan in Anumodan

Database and applicants

details in the Pension

Database

Forwards filled

forms to BDO

Form Filling

Component

Start

Stop


268

Quota Allocation

Pensions – Quota

E D

istr

ict A

pplic

atio

n D

ept.

Hea

d D

istr

ict M

agis

trat

e S

tate

Gov

ernm

ent

Fixes pension for particular

district, forwards this figure

to DM along with guidelines

Receives and updates

the allocated district wise

figures over the e district

application

Receives district

wise figures

along with

guidelines

Allocates overall

pension on a block

wise (Rural) and ward

wise – Municipality

wise (Urban) basis

Updates proposed

allocated figures

over the application


from the application

Receives and

reviews notification

Hosts proposed block

and ward wise figures,

notifies DM

Hosts district wise

allocated pension quota

and auto generates email

notifying allocated quota

to Dept. Head

Quota

Hosts DMs Approval /

Disproval along with

comments and notifies

Dept Head

Updates decision on e


database

Approval?

Updates Application

Database

Work on DMs orders

and revises allocation

Yes

No

Logs in to the application

and verifies allocated

quota

Hosts final allocated

figures and notifies

concerned officials


269

Parallel Process Map

Parallel Process – For New Application Received in Khuli Baithak G

VA

Gra

m S

ab

ha

E

-Dis

tric

t A

pp

lica

tio

nA

pp

lica

nt

Submits pension

application request in

khuli baithak

Discusses particular

case in the Khuli Case Discussion

Rejects

Application

Approves

application

No

Yes

Receives

Rejection

Adds name to

anumodan and

beneficiary list

(Current / waiting)

Hands over the new

applications to the GVA

whose names have

been added

Fills physical forms on

behalf of applicant and

hands over the ack.

Receipt to applicant

Updates details for the

new applicants details

in pension database

Registers new

applicants details,

issues unique

registration number and

ack. receipt

Records unique

registration number for

all new applicants

Issues ack. receipt

specifying the unique

registration number to

applicant

Start

Stop

Stop


270

Status Tracking

Pensions – Urban Status Tracking Rural

Dep

t.Hea

d G

VA

Gra

m S

abha

B

DO

/ A

DO

(G

P)

E-D

istr

ict A

pplic

atio

nA

pplic

ant

Ok

No

Yes

No


availability and


pension targets

Generates reports for

BDO and marks to

GVA based on

requests received


pension details against

quota availability and

notifies GVA

Approves & forwards


updates DB


the pension

applications

Database gets updated

and BDO is notified

about the list


and Dept. Head is

notified about the list

GVA can also take new

applications in the Khuli

Baithak

Availability

Approves pension


DB

Gram Sabha approves

beneficiary list (current and

waiting) through anumodan &

hands over to GVA

Quota


anumodan in

Anumodan Database

Receives approved

beneficiary list

Verifies

anumodan



conducts khuli baithak and

puts forward the received

application for discussion

Receives report

about the

pension

applications

On receiving

applicant’s request

and BDOs orders

conducts khuli

baithak

Matches

applications

against the fund

availability


and updates DB

Status Tracking

Component

Status Tracking

Component

Status Tracking

Component


271

Monitoring Component

MIS Component

Pensions – Rural D

ep

t.H

ea

d

De

pt.H

ea

d

Gra

m S

ab

ha

G

ram

Sa

bh

a

GV

AG

VA

E-D

istr

ict A

pp

lica

tion

E-D

istr

ict A

pp

lica

tion

BD

O / A

DO

(G

P)

BD

O / A

DO

(G

P)

Re

ceiv

ing

Au

tho

rity

R

ece

ivin

g A

uth

ority


the pension

applications

Generates reports for

BDO and marks to

GVA based on

requests received


availability and


pension targets

Gram Sabha approves

beneficiary list (current and

waiting) through anumodan &

hands over anumodan + list +

forms to GVA


conducts khuli baithak and puts

forward the received application

for discussion


and BDO is notified

about the list

Approves & forwards


updates DB on

receiving filled forms

from GVA

Verifies

anumodanOk

No

Receives approved

beneficiary list


against the fund

availability

Availability

Approves pension


DB


and updates DB

Yes

No


and Dept. Head is

notified about the list


Quota


the pension

applications

On receiving Filled

forms from CSC,

applicant’s request and

BDOs orders conducts

khuli baithak

GVA can also take

new applications in

the Khuli Baithak


pension details against

quota availability and

notifies GVA


anumodan in Anumodan

Database and applicants

details in the Pension

Database

Forwards filled

forms to BDO

<MIS 1> <MIS 2> <MIS 3>


272

Sr. Process Details Process Details Responsibility

Centre

Pension Disbursement – Rural

1 Following application receipt and payment

component the e district application would

register the pension request for a particular

applicant

e District

Application

2. Once the pension request has been registered

the e district application would collate the

information on an event basis and generate an

online report. The request report would be

forwarded to the BDO and the GVA. (Refer

Pension Request Form Section – Old Age, Widow

and Handicapped)

e District

Application

3. Kiosk operator forwards physical documents

and form pritnout to the GVA Kiosk Operator

4. Generates gram Panchayat wise reports for

BDO and marks a copy to the GVA. (Refer View

Record Section –BDO / GVA Record View)

E District

Application

5. BDO on receiving the system generated report

reviews the targets received from the

Department head and distributes the allocated

pension quota on the basis of gram Panchayats

falling under the block.

BDO

6. BDO then updates the village wise pension

quota over the e district application and orders

GVA to start the process for form filling.

BDO

7. The e District application hosts the village wise

targets over it and notifies the GVA about the

assigned quota by the BDO and also delivers

BDO‟s orders to GVA to initiate the pension

process.

E District

Application

8. GVA on receiving the village wise quota from

(Refer View Record Section – GVA Record view)

application and filled application form from the

e District centre consolidates them for the

gram Panchayat and informs Pradhan to hold a

Khuli Baithak for finalizing the pension

GVA / Pradhan


273

beneficiaries. The Pradhan will in turn inform

the villagers about the agenda, date and venue

of the Khuli Baithak

9. On the prescribed time and location GVA along

with ADO (GP) holds Khuli Baithak in which he

reads out the agenda of the meeting once

again. GVA then enquires whether any other

applicant who was unable to submit his

application at the CSC wants to apply. If yes

refer Parallel Process – For New Application

Received in Khuli Baithak

GVA

10. The GVA then puts forward all the application

new and old in front of gram sabha for

discussion and he also puts forward the quota

allocated for the gram Panchayat.

GVA

11. The Gram Sabha then discusses each and every

case in the Khuli Baithak and identifies

beneficiaries (Current) and a waitlisted (

priority wise)

Gram Sabha

12. a) GVA then updates the anumodan listing the

meeting proceeding and also the list of

identified beneficiaries (current and waiting) in

the anumodan database.

The format for the anumodan in the case of

pension that the GVA would be filling (Refer

Database Section - Anumodan Database) The

GVA would also be filling the above details of

the proposed pensioners in the pension

database.

b) Simultaneously the GVA also forwards the

filled application forms to the BDO for his

physical verification and signature.

GVA

13. The e District application hosts the then

updated databases and notifies the BDO to

login and check the information updated by the

GVA.

E District

application

14. The BDO then logs in to the application and

verifies the Anumodan veracity against the BDO


274

pension database and physical forms received.

a) If the BDO find the Anumodan

fraudulent he can cancel the Khuli

Baithak and recall the Khuli Baithak

updating the system about his decision.

b) If the BDO finds no irregularities with

the Anumodan he approves the

beneficiary list against the physical

application he had received from the

GVA and updates the system about his

decision.

15. The system then hosts the BDO‟s response to

the submitted anumodan:

a) In case of rejection the GVA is notified

by the system for the recalling of Khuli

Baithak, intimation for the same would

also be delivered to the DM, CDO and

Concerned Department Head.

b) In case of acceptance the final

beneficiary list is updated over the

application and forwarded to the

department head for the pension

disbursal.

E District

Application

16. Department head receives the final beneficiary

list for the block Dept. Head

17. Dept. Head then reviews the fund status

available with him

a) If fund is available then the Dept. Head

approves the beneficiary list, updates it

over the e district application and

approves pension disbursal.

b) If fund is not available then also the

beneficiary list is updated and added to

wait list

Dept. Head

18. The e district application would host the action

taken by the department head and will notify

the relevant stakeholders.

E District

Application


275

Quota Allocation

Sr. Process Details

Responsibility

Centre

1 The state government fixes quota of pensions

that has to be distributed in rural and urban

areas. The money allocation is also done as per

the quota allocation. Once the quota is fixed

the quota is forwarded to the District

Magistrate for further bifurcation in the rural

and urban areas of the district. The State

Government also forwards a set of guidelines

that the DM / Dept. Head needs to follow while

quota allocation between urban and rural

areas.

State Government

2. DM receives the quota allocated by the State

Government and he uploads the received quota

over the e district application and marks it to

Department Head o allocate the quota.

District Magistrate

3. E District application hosts the received

pension quota by the DM and generates an auto

generated e mail to Department Head notifying

him to allocate quota as per the guidelines

amongst the Rural and Urban areas.

E District

Application

4. Department head then receives the e mail

notification requesting him to allocate quota. Department Head

5. The Department Head then allocates the

received quota under two categories (Urban

and Rural) and uploads it over the e district

application duly digitally signed by him.

Department Head

6. The Department head then updates the

allocated quota over the e district application Department Head

7. E District application then hosts the allocated

quota over it and notifies the District

Magistrate to review the quota allocation

E District

Application

8. DM logs in to the e district application and

reviews the allocated quota by the Department

Head (Refer Record View Section – DM Record

View)

District Magistrate

9. DM loads his decision over the e district

application along with his comments District Magistrate


276

10. E District application hosts DM‟s decision and

notifies the Department Head to review the

order of DM

E District

Application

11. Department head reviews DM‟s order:

In case of approval Department Head uploads

the allocated quota over the e district

application and marks it to the concerned

officials.

In case of disproval Department Head is asked

to revise the targets and update the e district

application which would be again reviewed by

the DM as per the above process.

Department Head

Pension – Status Tracking

Sr. Process Details Responsibility

Centre

1. The applicant, who was not able to submit his

application at the CSC, submits his application

in the Khuli Baithak conducted by the Gram

Panchayat.

Applicant

2. Gram sabha in the Khuli Baithak discusses the

particular case Gram Sabha

3. a. In case of Rejection the application is

rejected and the applicant is informed about

the decision.

b. In case of approval the Gram Sabha

approves the applicant‟s request and adds his

name to the beneficiary list (Current / Waiting)

as per the availability.

Gram Sabha

4. Gram sabha then hands over the new

applications received to the GVA who is present

during the Khuli Baithak

Gram Sabha

5. GVA then fills the form on the behalf of the

applicant and hands over the acknowledgement

receipt to the applicant

GVA

6. GVA then enters the details of the new

applicant whose application was received in

the Khuli Baithak in the e district application‟s

pension database.

GVA

7. E District Application then registers the

particular application and issues an auto

E District

Application


277

generated unique registration number in the

same series as those issued to the applicants

who registered at the CSC.

8. GVA records the new registration number for

all new applications GVA

9. GVA then issues the unique registration number

to the applicant if requested GVA

Sr. Process Details Responsibility

Centre

10.

The applicant is notified at the time of

application submission whether his application

has been submitted by the kiosk operator to

the e district application and that e district

application has registered his service request

E District

Application

11.

The application would notify the applicant

whether his name has been added in the

anumodan list (Current / Waiting)

E District

Application

12.

The application would notify the applicant

about the status of this request with the

department head whether his application has

been added to the beneficiary list i.e. the

current list or waiting list

E District

Application

Database required

The Anumodan Database that would be viewed by the BDO and filled up by GVA would have

the following details:


1 Anumodan

Database

The anumodan database would contain minute wise details of

Khuli bethak. This would contain the final approved beneficiary

list made during Khuli bethak. The database would maintain

records of ADO, GVA, Pradhan


278

CRUD Matrix for Pension


District Magistrate ■ ■ ■ ■ Add. Dist. Magistrate ■ ■ ■ ■

SDM(For Urban)/BDO (For Rural)

■ ■ ■ ■

Tehsildar (For Urban) ■ ■ ■ X

Revenue Inspector (For Urban)

■ ■ ■ X

Lekhpal (For Urban) ■ ■ ■ X

Gram Panchayat/Gram Vikas Adhikari

■ ■ ■ X


X ■ X X

Note: Officer should specify the reason in case of deletion/modification of saved record


279

Service Request Form – Pension

Old Age Pension Form

Widow Pension Form

Handicapped Pension Form

Old Age Pension Service Request Form would have the following details:


1. Registration No


3. S/o, D/o, w/o

4. Address:


6. Address

7. Village

8. Block

9. Tehsil

10. District

12. Duration of Stay in Uttar Pradesh

13. Age as on date of application submission

14. Documents attached

15. Details of family members:

16. Identification Mark


280

Widow Pension Service Request Form would have the following details:


1 Registration No.:


3 W/o: Late Expired on :

4 Date and location of death:

5 Before death his occupation and income

6 Address:

7 Gram Panchayat: Block:

8 Tehsil: District:

9 Age as on date of application submission:

10 Caste and sub caste:

11 Documents attached:

12 Details of dependants:

13 If have any earning son / grandson his occupation …….. and monthly

income ……….

14 Whether applicant is working then her occupation and monthly income

……………………

15 Whether applicant is having and movable / immovable properties if yes

please provide total income from all the sources…………….

16 Whether applicant is owner for such a property which serves free

lodging and fooding if yes provide details……………….

17 Whether applicant is receiving aids /help from any source is yes please

provide details ……………

18 Duration of residence in Uttar Pradesh………………

19 Whether applicant is staying in a rented / self owned

accommodation………………

20 Whether applicant is staying with some one then name of

supporter………………


281

Handicapped Pension Request Form would have the following details:


1 Registration No.:


3 S/o, D/o, W/o:


5 Address:


7 Tehsil: District:



10 S/o, D/o, w/o:

11 Handicap details/Disability Percentage:

12 Whether applicant is working then her occupation and monthly

income……………………

13 Whether applicant is having and movable / immovable properties if yes

please provide total income from all the sources…………….

14 Whether applicant is receiving aids /help from any national / state /

non government source if yes please provide details ……………



accommodation………………………


282


BDO / GVA Record View

The e district application would show the BDO and GVA the service request in the following

form:

GVA Record View

Once the BDO allocates the quota for different villages he forwards the format of quota to

GVA and he would view the details in the following format:

S.No Fields Description of the Record View

1. Block Name

2. Gram Panchayat

3. GVAs Name

4. Quota for the GP


1. Service Name

2. Pension Category

3. Applicant‟s name

4. S/o, W/o, D/o

Gram Panchayat Name

5. Block Name

6. Documents Attached


283

BDO Record View

The BDO would view the Anumodan record details submitted by the GVA in the following

form:

Record View for Applicant

The applicant would view the following fields updated by the Department Head to know the

status of his application I the following form:

Sr. Fields Description of the Record View

1 Registration No.

2 Name:

3 Block Village Tehsil

4 Status (Current / Waitlisted)

5 Waitlist No. (If waitlisted)

6 Date of Last Updation


1 Gram Panchayat

2 Block

3 Date of Submission

4 Date of Khuli Baithak

5 Pradhan‟s Name

6 ADO (GP)‟s Name

7 GVA‟s Name

8 Number of gram sabha members attending the meeting

9 Quorum for meeting

10.

Applicants‟ Details

S.No.

Registration No.

Applicant‟s Name

s/o, w/o, d/o

Category (Current / wait list no.)


284

Record view for DM

The DM would view the allocated quota proposed by the Department Head in the following

format:

District Name:

No.

Urban Rural

Municipality

Name

Ward

Name

No. of

Pensioners

to be

benefited

Block Village

No. of

Pensioners

to be

benefited

1.

2.

3

4.

Total Urban Total Rural

Total Pensioners

Department: Dept Head Name:

Digital Signature of Dept. Head: Date of Submission:


285

Monitoring Report

The following table specifies the fields required in the MIS Report (MIS component 1) generated for DDO

Sr.

Block name Name of

department

BDO‟s

Name

Total number of

application received

by BDO

Total

number of application for

which affirmative action

taken by the BDO within

the defined service level

Total

number of application for

which action by the BDO is

delayed beyond the defined

service level


286


Sr.

Block

name

Name of

department

BDO‟s

Name

Total number

of

“Anumodan”

approved by

the BDO

against the

number of

“Anumodan”

submitted by

GVA

Total number

of

“Anumodan”

rejected by

the BDO

against the

number of

“Anumodan”

submitted by

GVA

Total number

of service

request

approved by

gram sabha

against the

total number

of service

request

made

Total number

of service

request

rejected by

gram sabha

against the

total number

of service

request made

Total number of

service request

made at the

gram sabha

level and

updated by GVA

in the system

“Anumodan”

approved by

the BDO

against the

number of

“Anumodan”

submitted by

GVA


287


S.

No

Block

name

Name of

departme

nt

BDO‟s

Name

Total number of

application

successfully

forwarded by

BDO to

concerned

departmental

head (pension)

within the

defined service

levels against

the total number

of application

mentioned in

“Anumodan”

Total number

of application

not forwarded

by BDO to

concerned

departmental

head (pension)

within the

defined

service levels

against the

total number

of application

mentioned in

“Anumodan”

Total

number of

application

processed

and

approved

for pension

by the

concerned

departmen

tal head

(pension)

against

Total number

of application

received

from BDO

Total number

of application

not processed

and approved

for pension by

the concerned

departmental

head (pension)

against the

total number of

application

received from

BDO

Total

number of

service

request

application

confirmed

for

payment

and

waitlisted

for

payment


288

Internal Service Level – Pension Rural

S. No. Activities Time Required

Service Level ( from date of service request)

1. Submission of application from

kiosk to application

1 day Day 0

2. Issuance of order to GVA to

conduct Khuli Baithak by BDO

1 Day 1st day

3. GVA notifying the Pradhan to

conduct Khuli Baithak

2 Days 3rd day

4. Gram Pradhan calling for Khuli

Baithak

28 Days 31st day

5. GVA digitizing the anumodan

and updating the anumodan

database

5 Days 36th day

6. BDO Reviewing the anumodan 2 Days 38th day

7. BDO Forwarding the beneficiary

list to Dept Head

2 Days 40th day

8. Updation of pension status on

the system (with beneficiary

names , waitlisted candidates,

quota availability or not)

10 Days 50th day


289

Auto Escalation Matrix – Pension Rural


Service Level

L1

L2

L3


1 Updates village wise pension details against quota availability and notifies GVA

BDO 1st Day DDO 3 Days CDO 5 Days

2 Database gets updated and BDO is notified about the list

GVA 36th Day

BDO 2 Days DDO 2 Days CDO 3 Days

3 Database gets updated and Dept. Head is notified about the list

BDO 40th Day

DDO 3 Days CDO 3 Days

4 Database gets updated

Dept. Head

50th Day

CDO 2 Days DM 3 Days


290



1 BDO All

2 GVA All

4 DSWO One

5 DPO One

6 DHWO One

7 DM One

Function Requirement Specification – Pension Rural

Sr. Description

1

The system should be able to display pension related page through multiple

routes

Service links

Information links

District links

2 The system should be able to identify user login into the system as defined by

the login component

3

The system should be able to provide information to the citizens about pension

related services both in public as well as restricted domain as per the




4

The system should provide all services under various pension schemes under a

single category “Pension” with following sub categories –

Old age pension

Widow pension

Handicap pension

5

Should prompt the user to obtain service under two options:

i. Applying for fresh pensioner‟s card

ii. Applying for re-issuance pensioner‟s card

6

The system should be able to channel as well as handle different pension

schemes as per the process map and relevant description for the service

mentioned




291

8

The system should be able to retrieve service request form through following

channels

Direct access through service request form link

Direct access through pension service link

9

The system should allow the operator to fill in the online application on behalf

of citizen availing the service as per the „application receipt‟

component

CSC operator


10

The system should be able to generate a unique registration number during


component




applicant is registered with the system as per „application receipt‟ component

13 The system should be able to come up with final confirmation screen indicating

successful submission of service request

14 The system should be able to allow service fees payments (if any – as decided

by the state) for the pension related service as per the „Payment Component‟

15 The system should allow District Magistrate to enter allocated quota for the

district into the system

16 The system should save quota details for the district only after District

Magistrate digitally signs the entries

17 The system should auto generate email notification to concerned departmental

heads about updation of quota details

18

The system should allow concerned departmental head to allocate total quota

into following heads –

Blocks

Municipality – ward wise

19 The system should save the quota entries only when signed digitally by the

concerned departmental head

20

The system should not allow for any changes in the quota allocation by the

concerned departmental heads once it has been submitted using digital

signature by them

21 The system should auto generate email notification to District Magistrate about

updation of quota details

22 The system should allow the DM to either accept / reject allocation of the

pension quota to blocks and municipality – ward wise

23 The system should allow DM to provide suggestion / comments for re allocation


292

in case of rejection

24 The system should save the acceptance / rejection only on digital signature of

the DM

25 The system should auto generate email notification to concerned departmental

head about approval / rejection by the DM

26 The system should allow for modification in the quota allocation by the

concerned departmental head in case of rejection

the system should follow the same process flow as discussed above till the

quota allocation by the concerned departmental head is not approved by the

DM

27 The system should auto generate email to concerned block officer about the

pension quota allocation for their respective block

28 Should provide BDO the option to check the BPL status of the applicant (Right

now BDO is unable to check the details of the applicant in the BPL List at the

time of approval)

29 Should provide BDO the option to Reject application before sending it to the

field officer for checking also (Right now the BDO can reject the application

only after obtaining the field verification report. If the BDO can check from the

available databases that the Applicant is not fit to obtain pensions under a

particular head he / she should not be allowed to obtain the pension facility.

E.g. If a widow lady is 62 years old and she is opting for a widow pension then

her application should be rejected at the BDO level only as she is not eligible

for Widow Pension however she is eligible for old age pension)

30 The system should be able to route the service request to concerned block

office immediately on successful service request submission and should reflect

to following officials –

Concerned Block Development officer

Concerned Gram Vikas Adhikari

31 The System should auto generate email notification about service request to

the following officials –

Concerned Block Development officer

Concerned Gram Vikas Adhikari

32 The system should show service request to concerned Gram Vikas Adhikari as

pending for approval till it is marked for further action by concerned Block

Development Officer

by default the system should be able to auto escalate non approval

within the service level as per the escalation matrix defined

33 The system should load a page to enable BDO to allocate pension quota village


293

wise based on the total allocation for the block

34 The system should allow the BDO to save allocated village wise quota only

through digital signature

35 The system should allow the concerned BDO to mark and allocate service

request to concerned GVA for initiating action and processing of service

request

36 The system should auto generate email notification once the BDO has uploaded

the allocation details for pension (village wise)

37 The system should show the allocated village wise quota to GVA

38 The system should allow the GVA to upload „Anumodan‟ by logging into e-

District Application

the system should allow encoding of verification request using

digital signatures

39 The system should store and update “Anumodan” in the Anumodan database in

the predefined format (given in process description)

40 The system should give access to GVA to fill up additional service request form

received at the Gram Sabha meeting through authenticated login ID and

password

41 The system should allow the GVA to load the fresh application form submitted

at gram sabha (as defined in the parallel process map) for all the fields (same

as that of CSC centers)

42 The system should ask for digital signature of GVA for submission of the

additional service request form

43 The system should ask for re-confirmation of GVA before actually submitting

the form

44 The system should check for all the mandatory entries in the application form

before submission of application form

45 The system should follow all the steps of application receipt component for

form submission by the GVA

46 The system should be able to update the information in the specified database

where all service request are stored

47 The system should notify concerned Block Development Officer about

uploading of „Anumodan‟

48 The system should allow concerned Block Development Officer to view

„Anumodan‟

49 The system should be able to link respective service application with the

„Anumodan‟

50 The system should allow the BDO to do either of the following –

approve and forward the service application request to concerned


294

line department

rejects the service request application (specifically based on

„Anumodan‟) with stated reason

51 The system should allow concerned BDO to digitally sign the approval /

rejection

52 The system should be able to auto generate notification e-mail to concerned

GVA for again calling Gram Sabha Meeting for approval of service application

request in case of rejection of service request by the BDO

53 The system should be able to auto generate report of cancellation of Gram

Sabha Meeting to the following officials for information–

District Magistrate

Chief Development Officer

Concerned Head of Department (pension)

54 The System should be able to reschedule the service level in case of

cancellation as per the service level matrix

55 The system should not auto escalate the service request as per the original

service levels in case of cancellation of the „Anumodan‟ of Gram Sabha


pension departmental head about the approval of service request of pension

57 The system should allow the concerned departmental head to log into the e-


the login process

58 The system should display the approved service request in order of priority to

the concerned departmental head

59 The system should be able to map the quota allocation details Village wise (as

approved by BDO) against the approved service request

60 The system should be able to differentiate between the approved service

request application as following –

approved and confirmed

approved and waitlisted

61 The system should not allow in any change in priority of the service request

application form for the following



62 The system should be able to support the status tracking component as defined

in the process map for status tracking

63 The system should be able to support the monitoring and reporting component

as defined in the process map for monitoring and reporting




295

The system should follow the escalation matrix as defined for the process


296

Pension Disbursement – Urban

Pensions - Urban

Te

hsi

lda

r L

ekh

pa

l R

I D

ep

t. H

ea

d

SD

ME

-Dis

tric

t A

pp

lica

tion

Ap

plic

an

t

System saves the

rejection in a DB and


Updates the decision over

the system on receiving

physical documents


application, and forwards

application to SDM,

Tehsildar, RI and Lekhpal

System registers Lekhpal

report and notifies

Tehsildar / RI

Receives the

service request

Applicant receives

the reason for

rejection

Conducts physical

verification. Submits

verification report online

Receives notification and

checks lekhpal’s report

Report

Satisfactory

No

System registers

Tehsildar’s Decision and

notifies SDM

Yes

No

Availability


against the fund and

quota availability

Approves pension


DB


and updates DB

Receives approved

beneficiary application


and stakeholders are

notified

Application

Receipt

Component

Application

Rejection

Component

Payment

Component

Application DB gets updated

and notifies Lekhpal for

action and RI for monitoring

Receives the

service request and

waits for order


from system to conduct

verification

Receives the service

request and updates

system “for action”

Receives the

service request

Receives notification from

system to monitor

verification process


that Lekhpal has

submitted the report


about application

approval / disproval

Updates approval

over the

application

Yes

Updates approval

and forwards

application to dept

head

Form Filling

Component

Start

Stop

Stop

Quota


297

Quota Allocation

Pensions – Quota

E D

istr

ict A

pp

lica

tio

n

De

pt. H

ea

d

Dis

tric

t M

ag

istr

ate

S

tate

Go

ve

rnm

en

t

Fixes pension for particular

district, forwards this figure

to DM along with guidelines




application

Receives district wise

figures along with

guidelines

Allocates overall pension

on a block wise (Rural)

and ward wise –

Municipality wise (Urban)

basis

Updates proposed

allocated figures over the

application

Receives

notification from

the application

Receives and reviews

notification



notifies DM

Hosts district wise

allocated pension quota

and auto generates email

notifying allocated quota

to Dept. Head

Quota




Dept Head



database

Approval?

Updates Application

Database

Work on DMs orders


Yes

No



quota



concerned officials


298

Status Tracking

Pension - Urban

De

pt. H

ea

d

Le

khp

al

RI

Te

hsi

lda

r S

DM

E-D

istr

ict A

pp

lica

tion

Ap

plic

an

t

No

Yes

No

Yes

Availability

Receives the

service request

and waits for order

System registers

Lekhpal report and

notifies Tehsildar / RI

Report

Satisfactory

Receives the

service request


about application


Approves pension


DBMatches

applications against

the fund and quota

availability


and checks lekhpal’s

report

Receives the

service request

System saves the

rejection in a DB

and notifies the

applicant



notified



application to SDM,

Tehsildar, RI and Lekhpal


request and updates


Application DB gets updated

and notifies Lekhpal for

action and RI for monitoring


from system to

conduct verification

Updates the

decision over the

system on receiving

physical documents

Updates approval

and forwards

application to dept

head


from system to

monitor verification

process

Receives

approved

beneficiary

application Puts name in waitlist

and updates DB

System registers

Tehsildar’s Decision

and notifies SDM

Updates approval

over the

application


that Lekhpal has


Conducts physical


verification report online

Status

Tracking

Component Status Tracking

Component

Status Tracking

Component

Status Tracking

Component


299

Pension Monitoring

Pension - Urban

Te

hsi

lda

r L

ekh

pa

l R

I D

ep

t. H

ea

d

SD

ME

-Dis

tric

t A

pp

lica

tion

Re

ceiv

ing

Au

tho

rity

System saves the



Updates the decision

over the system on

receiving physical

documents



application to SDM,

Tehsildar, RI and Lekhpal System registers

Lekhpal report and

notifies Tehsildar / RI

Receives the

service request

Conducts physical


verification report

online


and checks lekhpal’s

report

Report

Satisfactory

No

System registers

Tehsildar’s Decision

and notifies SDM

Yes

No

Availability


against the fund and

quota availability

Approves pension


DB


and updates DB

Receives approved

beneficiary application



notified

Application DB gets

updated and notifies

Lekhpal for action and RI

for monitoring

Receives the

service request and

waits for order


from system to

conduct verification


request and updates



request


from system to

monitor verification

process


that Lekhpal has



about application


Updates approval

over the application Yes

Updates approval

and forwards

application to dept

head

MIS

Component 2

MIS

Component 3

MIS

Component 1


300


1


the e district application would register the pension

request for a particular applicant

e District

Application

2 The kiosk operator would fill in the following

information in the form submission component:

e District

Application

3


SDM for information / Tehsildar for action / RI for

information and Lekhpal initimation that the service

request is going to come.

E District

Application

4 Kiosk operator forwards physical documents and

application form printout to the Tehsildar Kiosk Operator

5 SDM receives the pension request for the applicant

generated by the e district application. SDM

6

Tehsildar receives the pension request for the applicant

generated by the e district application. As soon as he

receives the pension request he updates the system for

the Lekhpal to initiate action and RI for monitoring

purpose only.

Tehsildar

7

Receives the service application request through the e

district application and he waits for the order of

Tehsildar to initiate monitoring of Lekhpal.

Revenue Inspector

8

Receives the service application request through the e

district application and he waits for the order of

Tehsildar to initiate action.

Lekhpal

9


decision making authority and notifies the Lekhpal

(Lekhpal) about the orders to initiate field verification

and RI for monitoring the Lekhpal working.


10

RI receives notification from the e district application

about the orders updated by the Tehsildar to monitor

the physical verification.

Revenue Inspector

11

Lekhpal receives notification from the e district

application about the orders updated by the SDM to

carry out the physical verification.

Lekhpal

12

Lekhpal verifies the veracity of the details provided by


physical verification report over the system duly

digitally signed by Lekhpal

Lekhpal


301

13

System registers the physical verification report

submitted by the Lekhpal and notifies the Tehsildar to

review the report to RI for information that verification

has been carried out.

e District Application

14

Tehsildar reviews the verification report submitted by

the Lekhpal on the e district application database. SDM

can then :

c) If Tehsildar finds the Lekhpal report favoring the

applicant‟s request then the Tehsildar approves

the pension request and updates it over the e

district application using his digital signature on

receiving the physical documents.

d) If Tehsildar finds Lekhpal report stating that the


then the Tehsildar rejects the application and

updates his rejection over the e district

application stating the reason.

Tehsildar

15 e District application hosts the Tehsildar decision and

notifies SDM . E District Application

16

SDM reviews the Tehsildar decision hosted over the e


a) If the result is favorable then updates the e

district application for forwarding the applicant‟s

request and SDMs approval to the department head

along with the application form.

b) If the result is not favorable then the SDM updates

the e district application to host his decision and

notify the applicant about the application

rejection as per the rejection component.

SDM

17

The system will host SDM‟s decision and take the

following decisions:

a) If the result is favorable then forwards the

applicant‟s request and SDMs approval to the

department head along with the application form.

b) If the result is not favorable then the e district

application will host the SDM‟s decision and notify

the applicant about the application rejection as

per the rejection component.

e-District

Application


302

18. The Department Head receives the approved

application request from the SDM Dept. Head

19. The Department head matches the received approved

application with the fund / quota availability. Dept. Head

20.

Dept. Head then reviews the fund status available with

him

a) If fund is available then the Dept. Head

approves the beneficiary list, updates it over

the e district application and approves pension

disbursal.

b) If fund is not available then also the beneficiary

list is updated and added to wait list

Dept. Head

21.



stakeholders.


Quota Allocation


1.

The state government fixes quota of pensions that has to

be distributed in rural and urban areas. The money

allocation is also done as per the quota allocation. Once

the quota is fixed the quota is forwarded to the District

Magistrate for further bifurcation in the rural and urban

areas of the district. The State Government also

forwards a set of guidelines that the DM / Dept. Head

needs to follow while quota allocation between urban

and rural areas.

State

Government

2

DM receives the quota allocated by the State

Government and he uploads the received quota over the

e district application and marks it to Department Head o

allocate the quota.

District Magistrate

3

E District application hosts the received pension quota

by the DM and generates an auto generated e mail to

Department Head notifying him to allocate quota as per

the guidelines amongst the Rural and Urban areas.

E District

Application

4 Department head then receives the e mail notification

requesting him to allocate quota. Department Head

5 The Department Head then allocates the received quota

under two categories (Urban and Rural) and uploads it Department Head


303

over the e district application duly digitally signed by

him.

6 The Department head then updates the allocated quota

over the e district application

Department

Head

7

E District application then hosts the allocated quota over

it and notifies the District Magistrate to review the

quota allocation

E District

Application

8 The Department head then updates the allocated quota

over the e district application Department Head

9

E District application then hosts the allocated quota over

it and notifies the District Magistrate to review the

quota allocation


10 DM logs in to the e district application and reviews the

allocated quota by the Department Head District Magistrate

11 DM loads his decision over the e district application

along with his comments District Magistrate

12 E District application hosts DM‟s decision and notifies the

Department Head to review the order of DM E District Application

13

Department head reviews DM‟s order:

i. In case of approval Department Head uploads the

allocated quota over the e district application and

marks it to the concerned officials.

ii. In case of disproval Department Head is asked to

revise the targets and update the e district

application which would be again reviewed by the

DM as per the above process.

Department Head

Pension – Status Tracking


1





request

E District

Application



E District

Application

3

The application would notify the applicant about the

status of this request with the department head

whether his application is in the current list or waiting

list

E District

Application


304

Database required


1 Pension database

The Pension database will contain pension application

details like Name, Age, Date of Birth and other details.

The database would also maintain the status of

approved/rejected applications and final status/decision.

The database would also maintain approved as well as

wait listed status in lieu of service request.

Service Request Form – Pension Urban

Old Age Pension

Widow Pension

Handicapped Pension

Old Age Pension The format of Old Age Pension would comprise of following fields:


1. Registration No


3. S/o, D/o, w/o

4. Address:


6. Address

7. Village

8. Block

9. Tehsil

10. District

12. Duration of Stay in Uttar Pradesh

13. Age as on date of application submission

14. Documents attached

15. Details of family members:

16. Identification Mark


305

Widow Pension

The format of Widow Pension would comprise of following fields:


1 Registration No


3 W/o: Late Expired on :

4 Date and location of death:


6 Address:


8 Tehsil: District:



11 Documents attached:

12 Details of dependants:

13 If have any earning son / grandson his occupation …….. and

monthly income…

14 Whether applicant is working then her occupation and

monthly income ……

15 Whether applicant is having and movable / immovable

properties if yes please provide total income from all the

sources…………….

16 Whether applicant is owner for such a property which serves

free lodging and fooding if yes provide details……………….

17 Whether applicant is receiving aids /help from any source is

yes please provide details ……………



accommodation………………

20 Whether applicant is staying with some one then name of

supporter………………


306

Handicapped Pension

The format of Widow Pension would comprise of following fields:


S.No Registration No.:


2 S/o, D/o, W/o:


4 Address:


6 Tehsil: District:



9 S/o, D/o, w/o:

10 Whether applicant is working then her occupation and monthly income……………………

11 Whether applicant is having and movable / immovable properties if yes please provide total income from all the sources…………….

12 Whether applicant is receiving aids /help from any national / state / non government source if yes please provide details ……………


14 Whether applicant is staying in a rented / self owned accommodation……………………….


307


SDM/Tehsildar/ RI / Lekhpal Record View

The e district application would show the SDM, Tehsildar, RI and Lekhpal the service

request in the following form:


1. Applicants Name:

2. Registration No.

3. Service Requested

4. Caste

5. Address (Locality, Village, Tehsil)

6. Date of application submission

7. Documents Attached

Tehsildar Record View

Once the Lekhpal submits his verification report the Tehsildar can view the record in

the following form:


1. Applicants Name:

2. Registration No.


4. Caste (SC / ST / OBC / General)

5. Address (Locality, Village, Tehsil)

6. Date of application submission

7. Date of Verification

8. Result of Verification (Positive / Negative)

8. Comments (in case of rejection of request)

9. Date of submission of verification report

10. Name of Lekhpal

11. Digital Signature of Lekhpal


308

SDM Record View

When Tehsildar submits his Approval / Rejection report the SDM would view it in the

following format:


1. Applicants Name:

2. Registration No.


4. Tehsildar Decision ( Approval / Rejection)

5. Date of Submission

6. Tehsildar Name

7. Tehsildar Digital Signature

Department Head View

When the SDM submits the consolidated list of beneficiaries for a particular duration

for time for his Sub – Division the Department Head would view it n the following

format:


1. Tehsil Name

2. Date of Submission

3. Applicants Details

S.No. Applicant‟s

Name

Registration

No.

Caste

(SC/ ST/

OBC /

Gen)

Current /

Waitlisted

4. Date of Submission by SDM

5. Digital Signature of SDM


309

Record View for Applicant (whose applications have been approved)

The applicant whose application has been accepted would view the following fields

updated by the Department Head to know the status of his application:


1 Registration No.

2 Name:

3 Block Village Tehsil

4 Status (Current / Waitlisted)

5 Waitlist No. (If waitlisted)

6 Date of Last Updation

Record view for DM

The DM would view the allocated quota proposed by the Department Head in the

following format:

District Name:

No.

Urban Rural

Municipality

Name

Ward

Name

No. of

Pensioners

to be

benefited

Block Village

No. of

Pensioners

to be

benefited

1.

2.

3

4.

Total Urban Total Rural

Total Pensioners

Department: Dept Head Name:

Digital Signature of Dept. Head: Date of Submission:


310

Monitoring Report

The following table specifies the fields required in the MIS Report (MIS component 1) generated for head

S.No Name of the

Department

Number of

Applications

received by

Tehsildar

Number of

Applications

for which

affirmative

action

taken by

Tehsildar

Number of

Application

s for which

action

taken by

Tehsildar is

delayed

Total

number of

service

request for

verification

completed

Total

number of

service

request for

verification

not

completed

Total

number of

physical

verification

report

approved

against the

total

number

submitted

Total number

of physical

verification

report not

approved and

send for re-

verification

against the

total number

submitted

3.

4.

The following table specifies the fields required in the MIS Report (MIS component 2) generated for DDO/Concerned departmental

heads

S.No Name of the

department

Total number of service request

approved by the SDM against the

number of service request

Total number of service request rejected by

the SDM against the number of service request

3.

4.


311

The following table specifies the fields required in the MIS Report (MIS component 3) generated for CDO and DM

S.No Name of the

department

Total number of

application

successfully

forwarded by SDM

to concerned

departmental

head (pension)

Total number of

application not

forwarded by SDM

to concerned

departmental head

(pension)

Total number of

application

processed and

approved for

pension by the

concerned

departmental

head (pension)

Total number of

application not

processed and

approved for

pension by the

concerned

departmental

head (pension)

against the total

number of

application

received from SDM

Total number

of service

request

application

confirmed

for payment

and

waitlisted for

payment

1

2


312

Internal Service Level Matrix – Pension Urban

S. No. Activities Time Required Service Level ( from date of service request)

1. Submission of

application form 1 day Day 0

2. Issuance of order to

Lekhpal to conduct

enquiry

1 day 1st day

3. Receiving of order by

Lekhpal 1 day 2nd day

4. Field Verification

report updation by

Lekhpal

7 day 9th day

5. Decision making on

field verification

report by Tehsildar

1 day 10th day

6. Forwarding of approval

or disproval by SDM 2 day 12th day

7. Updation of receiving

of application by Dept.

Head

1 day 13th day

8. Updation of pension

status on the system

(with beneficiary

names , waitlisted

candidates, quota

availability or not)

2 day 15th day


313

Auto Escalation Matrix – Pension Urban

S. No. Activity Activity

Owner

Service

Level

L1

L2

L3


1. Application DB gets

updated and notifies

Lekhpal for action

and RI for monitoring

Tehsildar 1st Day SDM 2nd

Day

2. System registers

Lekhpal report and

notifies Tehsildar /

RI

Lekhpal 13th

Day

RI 1 Day Tehsildar 3rd

Day

3. System saves the



SDM 12th day Dept Head 1 Day

4. Updates approval

and forwards

application to dept

head

SDM 13th day Dept Head 2 day

5. Database gets

updated and

stakeholders are

notified

Dept.

Head

15th Day DM 1 day


314



1 SDM All

2 Tehsildar All

3 Lekhpal All

4 DSWO One

5 DPO One

6 DHWO One

7 DM One


315

Function Requirement Specification –Pension Urban

Sr. Description

1 The system should be able to display pension related page through multiple

routes

Service links

Information links

District links




pension related services both in public as well as restricted domain as per

the „Information component‟



4 The system should provide all services under various pension schemes under

a single category “Pension” with following sub categories –

Old age pension

Widow pension

Handicap pension

5 Should prompt the user to obtain service under two options:

i. Applying for fresh pensioner‟s card

ii. Applying for re-issuance pensioner‟s card

6 The system should be able to channel as well as handle different pension

schemes as per the process map and relevant description for the service

mentioned



8 The system should be able to retrieve service request form through following

channels

direct access through service request form link

direct access through pension service link


316

9 The system should allow the operator to fill in the online application on


component

CSC operator


10 The system should be able to generate a unique registration number during


component





component



14 The system should be able to allow service fees payments (if any – as decided

by the state) for the pension related service as per the „Payment

Component‟

15 The system should allow District Magistrate to enter allocated quota for the

district into the system



17 The system should auto generate email notification to concerned

departmental heads about updation of quota details

18 The system should allow concerned departmental head to allocate total

quota into following heads –

Blocks



concerned departmental head (pension department)

20 The system should not allow for any changes in the quota allocation by the


signature by them


317

21 The system should auto generate email notification to District Magistrate

about updation of quota details


pension quota to blocks and municipality – ward wise

23 The system should allow DM to provide suggestion / comments for re

allocation in case of rejection

24 The system should save the acceptance / rejection only on digital signature

of the DM


departmental head about approval / rejection by the DM


concerned departmental head (pension) in case of rejection

the system should follow the same process flow as discussed

above till the quota allocation by the concerned departmental

head is not approved by the DM

27 The system should auto generate email to concerned Sub Divisional

Magistrate about the pension quota allocation for their respective Tehsils

28 The system should be able to route the service request to concerned Tehsil

office immediately on successful service request submission and should

reflect to following officials –

Sub Divisional Magistrate

Tehsildar

Concerned Revenue Inspector

Concerned Lekhpal

29 The System should auto generate email notification about service request to


Tehsildar

Concerned Revenue Inspector

Concerned Lekhpal

30 The system should show service request to concerned Lekhpal as pending for

approval till it is marked for further action by concerned Revenue Inspector

by default the system should be able to auto escalate non

approval within the service level as per the escalation matrix


318

defined

31 The system should load a page to enable SDM to allocate pension quota

Municipality ward wise based on the total allocation for the Tehsil

32 The system should allow the SDM to save allocated municipality ward wise

quota only through digital signature

33 The system should reflect the quota allocation to municipality ward wise to


Tehsildar

Revenue Inspector

Lekhpal

34 The system should allow the concerned Revenue Inspector to mark and

allocate service request to concerned Lekhpal for initiating action and

processing of service request

The system should intimate Tehsildar about work allocation to

Lekhpal

35 The system should allow the Lekhpal to upload „Physical Verification Report‟

by logging into e-District Application

the system should allow encoding of verification request using

digital signatures

36 The system should store “Physical Verification Report” in the predefined

format (given in process description)

37 The system should not allow any changes in the „Physical Verification Report‟

at any level once submitted and digitally signed by the Lekhpal

38 The system should notify concerned Tehsildar about uploading of „Physical

Verification Report‟

39 The system should notify the concerned Revenue Inspector about work

completion on successful submission of „Physical Verification Report‟ by the

Lekhpal

40 The system should allow concerned Tehsildar to view „Physical Verification

Report‟


„Physical Verification Report‟ for Tehsildar to view


319

42 The system should allow Tehsildar to recommend / not recommend / re-

verify the „Physical Verification Report‟

43 The system should allow Tehsildar to mark service application request for

re-verification

In case of re-verification the system should follow the same

functionalities as specified for new application request

The system should generate notification on re-verification to SDM

The system should follow the escalation matrix even in case of

re-verification

44 In case of acceptance, the system should allow Tehsildar to recommend

service request to be accepted by SDM

The system should allow Tehsildar to submit recommendation

only after digital signing

45 The system should notify SDM on successful submission of service request by

the Tehsildar

46 The system should show the recommendation / non recommendation against

the service request by the Tehsildar to the SDM


„Physical Verification Report‟ for SDM to view

48 The system should allow SDM to approve / reject service request

49 The system should not allow recommendation for approval by the SDM in case

all the mandatory documents are not marked as received

50 In case of acceptance, the system should open a page where system should

allow the SDM to confirm the receipt of required documents in physical form

51 The system should allow SDM to mark received hard copies of supporting

documents

52 The system should allow the SDM to do either of the following –

approve and forward the service application request to concerned

line department

rejects the service request application with stated reason

53 The system should allow concerned SDM to digitally sign the approval and

rejection


320

54 The system should be able to do following –

In case of approval, the details of the service request should be

forwarded to the concerned department head without saving the

soft copy of the physical verification report

In case of rejection, the system should save the soft copy of

application rejection document as per the rejection component

and also a soft copy of physical verification report for future

reference


pension departmental head about the approval of service request of pension

56 The system should allow the concerned departmental head to log into the e-


the login process

57 The system should display the approved service request in order of priority to

the concerned departmental head

58 The system should be able to map the quota allocation details Village wise

(as approved by BDO) against the approved service request





60 The system should not allow in any change in priority of the service request

application form for the following



61 The system should be able to support the status tracking component as


62 The system should be able to support the monitoring and reporting




64 The system should follow the escalation matrix as defined for the process


321

65 The system should be able to maintain all records for the login sessions with

date and time

The system should be able to provide date and time stamping for all



322

4.2 Utility Services

i. Payment of Property tax (Removed from e-District Project)

ii. Issue of Khatauni

Select Prerequisites for the ToBe processes




through e-District application to RK without being manually forwarded as a





The department should accept the validity of Signed Khataunis across various

departments on par with any physically signed document.




Digitally Signed khatauni can be established.

Mandatory entry into the DB before any khatauni is issued.






323









324

Issue of Khatauni copy

Issue of Copy of Khatauni

Re

gis

tra

r K

an

un

go

E-D

istr

ict

Ap

plic

atio

nA

pp

lica

nt

Yes

No

Details Found?

Checks the

details in the

Land Records

database

Applicant receives

the authenticated

khatauni

Returns the

query resultSystem saves the

khatauni in a DB and


System saves the



Application

Receipt

component

Form

Availability

component

Payment

component

Applicant receives the

reason for rejection


application and issues an

Application Number. Notifies

the Registrar Kanungo

Receives the

application

Start Stop



Approves the

application online using


Approval compnent


online using digital sign

as per the Rejection

Component


325

Issue of Khatauni copy – Status Tracking

Issue of Copy of Khatauni - Status

Re

gis

tra

r K

an

un

go

E-D

istr

ict

Ap

plic

atio

nA

pp

lica

nt

Yes

No

Status Tracking

Component





System saves the



Details Found?

Status Tracking

Component

Status Tracking

Component


the Land Records

database

Receives the

application

Returns the query

resultSystem saves the





Approves the



Approval compnent




Component


326

Issue of Khatauni copy – Monitoring

Issue of Copy of Khatauni - Monitoring

Re

gis

tra

r K

an

un

go

E-D

istr

ict

Ap

plic

atio

nA

pp

lica

nt

Yes

No

Returns the query

result





System saves the



Receives the

applicationDetails Found?

System saves the



MIS Component 1 MIS component 3


the Land Records

database

MIS component 2




Component



Approves the



Approval compnent


327







(eDA)



4 The eDA then routes the application to the Registrar Kanungo (RK)

and notifies him about the new application eDA

5 The RK receives the application. Registrar Kanungo

(RK)

6 The RK queries the eDA for details in the Land Records Database RK

7

The eDA searches for the details in the Land Records Database and

if found, retrieves the khatauni from the Land Records Database

and displays it to the RK

eDA

8 The RK inspects the khatauni and digitally signs it and submits the

same back to eDA RK


the Applicant eDA




Sr. Issue of Khatauni Status Tracking details Responsibility Centre






and Digitally signed Khatauni is ready. eDA



328

Databases required


1 Land Records Database The Land Records database already exists. It is known as Bhulekh and is currently operational.

CRUD Matrix for Khatauni.




SDM ■ ■ ■ ■ Tehsildar ■ ■ ■ X

Revenue Kanungo ■ ■ ■ X



X ■ X X


329

Service Request Form – Khatauni copy

The fields required in the Khatauni copy request form are as follows


1 Name


3 Village Name

4 Pargana

5 Tehsil

6 District

7 Village Code (Optional)

8 Khata Number (Optional)


New and Pending Applications View





4 Status of Application

5 Search box

Completed Applications View





4 Status of Application

5 Search box


330

Internal Service Levels - Khatauni



days


7. Application Receipt and Forward to Registrar Kanungo (RK)

1 day 1st day

8. Checking of details in Land Records DB by RK

1 day

2nd day

9. Approval or Rejection by RK 2nd day

10. Delivery of Copy of Khatauni 2nd day




5. DM 1

6. SDM All

7. Tehsildar All

8. Registrar Kanungo All

9. Naib Tehsildar All

10. Lekhpal All


331

Monitoring Reports




Number of Khataunis issued



6.

7.

8.

9.

10.






1

2

3


332

Auto Escalation Matrix - Khatauni



Service Level

L1

L2

L3


3.

Checking of details in the Land Records Database

RK 1 day Tehsildar 1 day SDM 1 day DM 2 days

4. Approval or rejection

RK 1 day Tehsildar 1 day SDM 1 day DM 2 days


333

Functional Requirement Specification – Issue of of Khatauni

Sr. Description

1.

The system should be able to display Issue of Khatauni related page through

multiple routes

Service links

Information links

District Links



3.

The system should be able to provide information to the citizens about Issue

of Khatauni related services both in public as well as restricted domain as







Receipt component.








Registrar Kanungo (RK) of the Tehsil.

10.

The System should be able to notify the RK about the new application and



through SMS

through e-mail

11. The RK must be able to download the application from the System


334

12. The System should enable RK to conduct verification as per the Verification

component.

13. The System should allow the RK to enter query parameters for the Land

Records Database and then display the results for the query to RK.

14. The System should allow the RK to either approve or reject the application



the action.

16. The System should save the digitally signed copy of the khatauni issued as a

soft copy in a Database

17. The System should be able to notify the Applicant and deliver the khatauni as

per the Delivery Mechanism component.





20.





the Issue of Copy of Khatauni Status process map.




marked in the Issue of Copy of Khatauni MIS process map.

24.




25.







335



issued by them.

27.



IT Act 2000.

28.



based system.


336

4.2 Police Related Services

Key issues:

1. Police department as an MMP: The Proposed processes have not been signed off by the Police

department. Since Police is a separate MMP under the NeGP, workflow

automation of the internal processes would need to be taken up after

the requisite Departmental consent at the State and Central level is

obtained

2. CIPA related issues:

Implementation of CIPA is underway in some of the Police stations of the

Pilot District. The extent to which CIPA will be implemented across all

the police stations of the State is not clear.

3. Financial cost involved: In the proposed model, there is a financial implication for setting up an

infrastructure at the Circle offices and office Superintendent of Police.

Subsequently, a private agency may need to be engaged for Data entry

and maintenance of Infrastructure. Creation of a financial model may

not be feasible and this will mean a cost implication for the Department.

4. Security concerns:

In case private operators are hired for data entry purposes, Police

department would need to share basic information like FIR number, date

of FIR registration, etc related to a given case. There may be security

concerns raised from the Police officials. Further, Police department

would need to allow for sharing of the information like FIR details, etc

from the respective database with the e-District application (eDA).

Security issues may arise out of this.


337

Assumptions:

1. Following processes are only illustrative

2. CIPA is not considered while designing these processes

3. Infrastructure setup at the respective CO offices and SP offices is done

4. Respective Circle officers update the eDA with the status of the FIR complaint

5. The service levels defined have been accepted by the Police department

6. It is accepted and agreed upon by the Police department that the a list

containing all the new FIR lodged during the day is forwarded to the respective

CO to updated in the eDA

7. It is accepted and agreed upon by the Police department that details about the

appointment of Investigating officer are forwarded to the respective CO office

to be updated in the eDA

8. It is accepted and agreed upon by the Police department that status about

Charge-sheet preparation and Final report preparation are updated in the eDA

by the CO

9. It is accepted and agreed upon by the Police department that status about

filing of Charge-sheet is updated in the eDA by the respective CO

10. It is accepted and agreed upon by the Police department that once final

decision is given by the court, status about the same is updated in the eDA by

the respective CO

Select Prerequisites for qualification for To-Be Process (FIR

Process)

Issues related to acceptance by Police department:

There is still no confirmatory word or letter from the Police department regarding the acceptance of the processes proposed by the consultants. It is not clear if Police department will give consent for workflow automation of the internal processes.


338

CIPA related issues:

Implementation of CIPA is still at pilot level in some of the identified Police stations. It is not clear when and if CIPA will be implemented across all the police stations.

Whether Police department will allow for sharing of the information like FIR details, etc from the respective database with the e-District application (eDA)

Financial cost involved:

Financial cost is involved in the following model since this will require setting up infrastructure at the offices of the Circle officer and Superintendent of Police. Private computer operators may also have to be hired for data entry purposes.

Security concerns:

In case private operators are hired for data entry purposes, whether Police department will be willing to share basic information like FIR number, date of FIR registration, etc related to a given case with the private operators. There may be security concerns raised from the Police officials.



Providing the current status of the FIR lodged, to the citizen. The proposed

process also gives a status tracking tool to the citizen so that he can find

out at what stage is his FIR at any given time, whether an investigating

officer has been appointed or charge sheet has been filed etc.

Preconditions for qualification for To-Be Process (Character

Verification)

Issues related to acceptance by Police department:

There is still no confirmatory word or letter from the Police department regarding the acceptance of the processes proposed by the consultants. It is not clear if Police department will give consent for workflow automation of the internal processes.


339

CIPA related issues:

Implementation of CIPA is still at pilot level in some of the identified Police stations. It is not clear when and if CIPA will be implemented across all the police stations.

Whether Police department will allow for sharing of the information like FIR details, etc from the respective database with the e-District application (eDA)

Financial cost involved:

Financial cost is involved in the following model since this will require setting up infrastructure at the offices of the Circle officer and Superintendent of Police. Private computer operators may also have to be hired for data entry purposes.

Security concerns:

In case private operators are hired for data entry purposes, whether Police department will be willing to share basic information like FIR number, date of FIR registration, etc related to a given case with the private operators. There may be security concerns raised from the Police officials.



Providing the current status of the FIR lodged, to the citizen. The proposed

process also gives a status tracking tool to the citizen so that he can find

out at what stage is his FIR at any given time, whether an investigating

officer has been appointed or charge sheet has been filed etc.


340

First Information Report (FIR) - Workflow

Judi

ciar

y

Cou

rt C

ircle

Offi

cer

Sup

erin

tend

ant

Offi

ceP

olic

e S

tatio

n C

ompl

aina

ntE

-Dis

trict

App

licat

ion

Y

Y

NN

Investigating Officer

investigate case and

updates case diary

Does case

requires more

Investigation

Investigation Officer arrests

accused if Police Station In

Charge has instructed

Receives periodic

case diary within 24

hours

One Carbon copy

is handed over to

the complainant

Munshi Registers FIR in FIR

register and informs the CO

office about FIR details

Updates Crime

Register

CO prepares

Final Report

Makes Decision

Submits “Tahrir” to

“Munshi”

Receives the result of

investigation along with

all supportings

Stamps and signs all

copies of FIR

Crime is recorded in

Case Diary (CD) along

with copy of FIR

(CHIK)

Final Report prepared by

Circle Officer

Original FIR is

sent to the

Judiciary court

Case

Proceedings

Receives FIR from

Police Dept.

The e-District Application

registers the details of

the FIR

Inform court

result of

investigation

1. Gram Crime Register

2. Woman Crime register

3. SC/ST Crime register

Etc.

Chargesheet has been

prepared by the IO

IO submits

charge sheet with

evidences

Munshi writes case in

predefine Performa in three

copies (FIR)

Police Station In charge reads case and

appoint Investigation Officer and informs

the CO

Judicial Court receives

the result of investigation

Judicial Court gives decision

and the applicant intimated

about the final order

IO Prepares

charge sheet Investigating Officer

makes final entry in the

case diary

Is claim valid in

light of evidence?

Investigation Officers is

appointed in the case

1

2

3

4

5

6

Receives court

decision in hard

copy

StartStop

Stop

FIR Process (Workflow)


341

FIR – Status Tracking

First Information Report (FIR) - Status

Jud

icia

ry C

ou

rt

Circl

e O

ffic

er

Su

pe

rin

ten

da

nt O

ffic

eP

olic

e S

tatio

n

E-D

istr

ict A

pp

lica

tion

Co

mp

lain

an

t

Final Report prepared by

Circle Officer

Chargesheet has been

prepared by the IO

Judicial Court receives

the result of investigation

Investigation Officers is

appointed in the case

Judicial Court gives decision

and the applicant intimated

about the final order


registers the details of

the FIR

Enters FIR details

in e-District

application

Sends list of all

new FIR EoD to

CO office

Informs CO office

about appointment

of Investigating

officers (IO)

against

corresponding FIR

Enters IO details

against

corresponding FIR

in e-District

application

Enters charge-sheet

details against

corresponding FIR in


Enters Final Report

details against

corresponding FIR

in e-District

application

Enters charge-sheet

filing details against

corresponding FIR

in e-District

application

Enters decision

details against

corresponding FIR

in e-District

application

Status

Tracking

Component

Status

Tracking

Component

Status

Tracking

Component

Status

Tracking

Component

Status

Tracking

Component

Status

Tracking

Component

1

2

3 4 5 6


342


FIR Process

1

Once the complainant‟s FIR is registered, all the

information about the FIR is forwarded to the Circle

officer (CO)

Station officer/Station

in-charge

2 CO logs into the e-District application (eDA) and

updates the FIR information in the eDA CO

3

Once the FIR details are updated in the eDA, system

fires a trigger and an auto generated SMS/Email is

sent to the complainant with the following details:

a. FIR no

b. Date of FIR registration

c. Police station where FIR is lodged

d. Complainant name

eDA

4

An investigation officer is appointed by the station

in-charge/station officer and this information is

forwarded to the CO office

Station in-

charge/station officer

5

CO updates the eDA about the appointment of

Investigation officer against the relevant FIR

number

CO

6

Once the FIR details are updated in the eDA, system

fires a trigger and an auto generated SMS/Email is

sent to the complainant informing him/her that an

investigation officer has been appointed against the

FIR number

eDA

7 Investigation is conducted and charge-sheet is

prepared and forwarded to the CO Investigation officer

8 Information about preparation of charge-sheet is

updated in eDA CO

9

Once the charge-sheet details are updated in the

eDA, system fires a trigger and an auto generated

SMS/Email is sent to the complainant informing

him/her about preparation of charge-sheet against

the corresponding FIR number

eDA

10 CO studies the charge-sheet and FIR details. CO CO


343

may take one of the three decision:

a. Reject the complaint: Prepares the

final report and update the eDA about

the preparation of final report and

rejection of complaint

b. Ask the investigation officer to

conduct more inquiries and

investigation

c. Approve the charge-sheet and prepare

the final report

11 eDA is updated about the preparation of Final

report CO

12

Once the Final report details are updated in the



him/her about the preparation of the final report

against the corresponding FIR number

In case the complaint is rejected, this information is

also provided to the complainant

eDA

13 Final Charge-sheet is filed in the court CO

14 Detail about the filing of charge-sheet is updated in

eDA CO

15

Once the charge-sheet details are updated in the



him/her about the filing of the charge-sheet against

the corresponding FIR number

eDA

16

Court announces the decision against the charge-

sheet based on the court proceedings. Information

about court decision is updated in the eDA against

the corresponding FIR

CO

17

Once the Court decision details are updated in the



him/her that decision has been announced by the

court against the corresponding FIR number

eDA


344

Databases required S. No. Database Remarks

1 FIR details database This database will contain details of all the

registered FIR like FIR number, date of FIR,

Police station details, Complainant name

Internal Service Levels S. No. Activities Service Level ( from date of completion of

activity) 1. Update of FIR registration details

in e-District application (eDA)

48 hours

2. Update of information of

appointment of Investigation

officer in eDA

48 hours

3. Update about preparation of

charge-sheet in eDA

48 hours

4. Update about preparation of Final

report in eDA

24 hours

5. Update about filing of charge-

sheet in eDA

24 hours

6. Update of court decision in eDA 24 hours


Auto escalation and monitoring will be done manually based the current processes.


The following table specifies the designations that need to have the Digital Signatures:

S.No. Designation Number of digital signature required

1. Circle officer All the relevant circle officers (zonal CO)


345

Function Requirement Specification – FIR status

S.No. Description

1. The system should be able to identify user login into the system as

defined by the login component

2. The system should be able to channel as well as handle different FIR

complaints as per the process map and relevant description for the

service mentioned

3. The system should allow update of details against a given FIR

complaint at the respective Circle office (CO office) at six different

pre-defined stages:

FIR registration

Appointment of investigation officer (IO)

Preparation of Charge-sheet

Preparation of Final report

Filing of charge-sheet

Final decision from court

4. The system should be able to retrieve relevant form using „form

availability‟ component for update of FIR details for a new/existing FIR

complaint

5. Form will have the following fields:

1) FIR number

2) Date of FIR registration

3) Police station where FIR is lodged

4) Name of complainant

5) Appointment of IO

6) Preparation of Charge-sheet

7) Preparation of Final report

8) Filing of charge-sheet

9) Date of filing of charge-sheet

10) Final decision from court

11) Date of final decision

6. Fields 5,6,7,8 and 10 as mentioned in point 5 will be check box where

as fields 1,2,3,4,9 and 11 will be text/input box which will enable user

to fill the required details

7. System form for update of details against a given FIR at the time of


346

registration of a new FIR should show and allow the user to fill the

following fields as mandatory:

1) FIR number

2) Date of FIR

3) Police station where FIR is lodged

4) Name of complainant

8. System should send a notification (SMS/Email) to the complainant

about FIR registration details with the as mentioned in point 7

9. System should allow the user to check the field against the

Appointment of IO field and send a system generated notification

(SMS/Email) to the user with the following details:

1) FIR number

2) Appointment of IO


Preparation of Charge-sheet field and send a system generated

notification (SMS/Email) to the user with the following details:

1) FIR number

2) Preparation of charge-sheet


Preparation of Final report field and send a system generated

notification (SMS/Email) to the user with the following details:

1) FIR number


12. System should allow the user to check the field against the Filing of

Charge-sheet field, enter the date of filing of Charge-sheet and send a

system generated notification (SMS/Email) to the user with the

following details:

1) FIR number

2) Filing of Charge-sheet

3) Date of Filing of Charge-sheet

13. System should allow the user to check the field against the Final

decision by the court field, enter the Date of Final decision and send a

system generated notification (SMS/Email) to the user with the

following details:

1) FIR number

2) Final decision given by the court


347

3) Date of Final decision by court

14. The system should be able to retrieve required form through following

channels

direct access through FIR details link

15. The system should be able to map, retrieve, update and save the FIR

details through the unique FIR number against a given FIR complaint

16. The system should be able to identify the FIR complaint uniquely

based on this FIR number for all future references

17. The system should auto generate email notification to concerned

officers as defined in the auto escalation matrix about the update

against a given FIR

18. The system should not allow for any changes in the following fields of

FIR once it has been submitted:

1) FIR number

2) Date of FIR registration

3) Police station where FIR complaint is registered

4) Complainant name

19. The system should ask for digital signature of Circle officer (CO) for

submission of the following updates against a given FIR:

1) Preparation of Charge-sheet


3) Filing of Charge-sheet

4) Final decision given by court

20. The system should ask for re-confirmation of CO before actually

submitting the form

21. The system should check for all the mandatory entries in the

application form before submission of application form

22. The system should be able to update the information in the specified

database where all FIR details are stored

23. The System should be able to reschedule the service level in case of

cancellation as per the service level matrix



25. The system should be able to auto escalate the service request if the

service levels are not met as defined in the service level description

for the process


348

26. The system should follow the escalation matrix as defined for the

process

27. The system should be able to maintain an audit trail for the updates

done with date and time along with the login id/user id




349

Character Verification (Citizen) - Workflow

Po

lice

de

pa

rtm

en

t (S

P

offic

e/P

olic

e s

tatio

n)

E-D

istr

ict A

pp

lica

tio

nS

erv

ice

de

live

ry c

en

tre

(CS

C)

Ap

plic

an

t

Payment

Component

Application

Receipt

Component

Application

submission

Component

Enters the service

request details in e-


(eDA)

Notification is sent to

the SP office for the

service request

The details against the

request for verification

certificate are stored

in the database

Application

Delivery

Component

Verification is done as per the process

defined

StopStop

Start

Character Verification process (Workflow)


350

Character Verification (Citizen) – Status tracking

Po

lice

de

pa

rtm

en

t (S

P

offic

e/P

olic

e s

tatio

n)

Se

rvic

e d

eliv

ery

ce

ntr

e

(CS

C)

E-D

istr

ict A

pp

lica

tio

nA

pp

lica

nt

The details against the

request for verification

certificate are stored

in the database

Verification is done as per the

process defined

Notification is sent to

the SP office for the

service request

Enters the service

request details in e-


(eDA)

Status

tracking

component

Status

tracking

component

Character Verification (Status Tracking)

351


I. Character Verification process

1


receipt component are pre-defined process. The

output of the pre-defined process is the input of e-


eDA

2 eDA registers service request for character

verification eDA

3

Notification is sent to the respective office of

Superintendent of Police about the service

request for character verification

eDA

4

Service request application is sent to the

corresponding office of the Superintendent of

Police for processing of the service request

CSC

5

System generated SMS/Email is sent to the

applicant informing about the registration of the

service request along-with the unique application

reference id

eDA

6

Once the verification process is completed at the

Police end, the verification result is updated at

the eDA

SP office

7

System generated SMS/Email is sent to the

applicant about the delivery status when the

verification update is done at the police end

eDA

8 Citizen can collect the character certificate at

the respective SP office Citizen

Databases required


1 Citizen database Will contain fields as in the parivar register and

ration card like name, age, caste, address, sex,

religion, education, etc. This will help in

mapping applicant‟s details in the application

and also keep track of future certificate

issuance

352

Internal Service Levels – Character Verification

S. No. Activities Service Level ( from date of

completion of activity) i. 1. Submission of application 1st day

ii. 2. Online registration of application 1st day

iii. 3. Notification to Police department about the service request

1st day

Auto Escalation Matrix – Character Verification

Auto escalation and monitoring will be done manually as per the current processes.


The following table specifies the designations that need to have the Digital Signatures:

S.No. Designation Details (Nos.)

1. Superintendent of Police (SP) All relevant SP

353

Function Requirement Specification – Character Verification

Sr. Description

1. The system should be able to identify user login into the system as


2. The system should be able to display relevant service related page through

multiple routes

Service links

Information links

District links


Character Verification (CV) certificate related services both in public as well

as restricted domain as per the „Information component‟



4. The system should provide all services related to certificates under a single

category

5. The system should be able to channel as well as handle different CV service

request as per the process map and relevant description for the service

mentioned

6. The system should be able to retrieve relevant service request form using


7. The system should be able to retrieve service request form



component

CSC operator


9. The system should be able to generate a unique registration number during


component

10. The system should be able to identify the applicant uniquely based on this




component



354

13. The system should be able to allow service fees payments for the CV service

as per the „Payment Component‟

14. The system should be able to route the service request to concerned SP

office

15. The system should auto generate notification of pending service delivery

request to concerned SP on successful submission of service request

through CSC / e-Suvidha Kendra




date and time



19. System should allow the update of the delivery status at the SP office against

the given service request mapped by the unique application reference id

355

4.2 Due& Recovery Related Services

Select Prerequisites for qualification for To-Be Process


District Centers accepting payment request from the citizens.


through e-District application to Tehsildar and Nayab Tehsildar simultaneously

without being manually forwarded by DM office to ADM (F&R), CRA as a noting

on service request file.

The department should accept the validity of digital signature instead of

physical signing and stamping by concerned Tehsildar and Nayab Tehsildar to

be issued to the citizens.

The department should accept the provision for SCA / Delivering agency charge

a convenience fees from either the citizen or department to make the process

self sustainable.



The facility to the various stakeholders to check the status of the dues on

the citizen, it also helps the citizen to check the status from the e-District

application, in case an notice/ arrest warrant is issued against the citizen.

The facility to the citizen to make payment from CSC, and also giving him

information of his dues through the list which may be put up on the CSC.

356

Dues & Recovery Process Flow -1.

Dues & Recovery – Process Flow

Citi

zen

Am

inN

aya

b

Te

hsi

lda

rW

BN

/AW

BN

Te

hsi

l

da

rD

M\ C

RA

Offic

eE

-Dis

tric

t

Ap

plic

atio

n

Yes

Issues the notices to all

the Defaulters and

forwards to Nayab

Tehsildar

If notice valid?

Clerk enters the RC details in the

eDistrict application, the DM gets

intimated and forwards it to

respective Tehsil

Receives the amount

gives a receipts and

informs to WBN about

the collection made and

deposited challan no.

NT distributes all the

RCs amongs th Amins

for recovery

Verifies all the Notices

and updates to Nayab

Tehsildar

Now eDistrict Application reflects

this information to ADM, CRA,

SDM, Tehsildar and Nayab

Tehsildar

Start

The e-District

Application is updated

about the status

The e-District

Application gets updated

about the notices issued

and generate notice No.

Amin handover the notice to

citizen takes the

acknowledgment and gives

him 15 days time for

submitting his dues

Informs to WBN with

resion

No

NT updates about the

Notices which are not

verified to the AWBN

Informs to NT date of

notice acknowledgment

Gets the Notice and gives

the acknowledgment to

Amin

If Amount Deposits

to Amin?

Yes

No

System receives the amount

against notice no. and issues a

receipt to citizen and gets

Updated about the status and

informed to WBN

Deposits the amount at

CSC/ e-District centerCollects the receipt

Application

Receipt

Payment

Component

Application

Rejection

Component

Application

Receipt

ComponentPayment

Component

WBN updates the e

Distric Application

357

Dues & Recovery Process Flow -2

Dues & Recovery – Process Flow (If Dues more then Rs. 1 Lacs and not deposit within 15 days after receiving of Notice)

Am

inN

aya

b

Te

hsild

ar

WB

N/

AW

BN

Te

hsild

ar

E-D

istr

ict

Ap

plic

atio

n

Start

E-District application generates a trigger

against those defaulter whose pending

amount is more than 1 Lacs and they

have not deposited their dues after

receiving of notice given by Amin

NT takes the print out of the

Warrants and distributes to

concerned Amin

Amin informs

to the defaulter and start assessment

for the defaulter moveable and

immovable property for the auction

NT Updates the

information and forwards

to AWBN

The e-District


about the status

Issues the Warrant to all the

Defaulters and forwards to

WBN

Informs the WBN about the

amount deposited details with

challan no. of treasury


gets updated about the

warrants issued and

generate warrent No.

After auction he collects

the amount and deposits

the amount against the RC

in treasury

WBN takes the print out of

the Warrants and distributes

to concerned Amin

WBN updates the e

Distric Application

358

Dues & Recovery Status Tracking

Dues & Recovery – Status Tracking

Citi

zen

Am

inN

aya

b

Te

hsi

lda

rA

WB

NT

eh

sild

ar

E-D

istr

ict

Ap

plic

atio

nD

M\ C

RA

Offic

e

Yes

Start

No

Yes

No

Receives the amount





Collects the receipt


the Defaulters and

forwards to NT

Informs NT date of


If notice valid?Amin verifies the Notices

and updates to WBN




Tehsildar




respective Tehsil

NT updates to AWBN


citizen takes the



submitting his dues

The e-District




Application

Receipt





informed to WBN

The e-District


about the status

NT forwards all the

notices to respective

Amins of that Area

If Amount Deposits

to Amin?Deposits the amount at

CSC/ e-District center

Status

Tracking

Component



Amin

Informs to NT with

reason

Status

Tracking

Component

WBN updates the e

Distric Application

359

Dues & Recovery Monitoring

Dues & Recovery – Monitoring

Citiz

en

Am

inN

aya

b

Te

hsild

ar

AW

BN

/

WB

N

Te

hsil

da

r

<MIS 2>

E-D

istr

ict

Ap

plic

atio

nD

M\ C

RA

Offic

e

Yes

Start

No

Yes

No

Informs NT with reason

The e-District


about the status

Collects the receipt

The e-District




MIS




Tehsildar

Informs to WBN date of


If notice valid?

If Amount Deposits

to Amin?


citizen takes the



submitting his dues

Amin verifies the Notices

and updates to NT



Amin

Deposits the amount at

CSC/ e-District center

MIS


the Defaulters and

forwards to Nayab

Tehsildar





informed to WBN

Application

Receipt

NT Updates and

forwards to AWBN

Receives the amount








respective Tehsil

NT distributes the

notices to concerned

Amin

MIS

WBN updates the e

Distric Application

360


Dues & Recovery Process

1.

Recovery Certificates comes from different Departments

to CRA office which is entered by CRA office in eDistrict

application.

CRA Office

2. CRA issues the notices to all defaulters and forwards to

concerned AWBN/WBN. CRA

3. E District Application gets the complete information about

each recovery to be made . e-district application

4. AWBN then fills the information and forward to respective

Nayab Tehsildars AWBN

5. NT forwards the respective Area Amins for recovery Nayab Tehsildar

6.

Once the notice is issued by the Nayab Tehsildar, a list of

all the notices issued is updated at the e- district

application for the citizen to verify, when received from

Amin for recovery. The list can also be made available at

the CSC.


7.

Upon receiving the notice from the NT, the respective

Amin of the area, will give the notice to the citizen and is

responsible for the recovery of the money. He will give 15

days of time to the citizen to recover the amount

Amin

8. If there is any non deliverable notice i.e(wrong Address,

Name, stay on RC etc) will be return to NT with reason. Amin

9. Updated the all non deliverable notices return by Amin in

eDistrict application with reason. NT

10. NT then forwards such notices to AWBN. NT

11. AWBN updates all such non deliverable info in e District

application. AWBN

12.

Amin recovers the amount and gives a receipt to the

Citizen. Amin updates about the payment to the AWBN,

who using his digital signature updates the e-district

application.

Amin

13.

eDistrict application triggers a flag to Tehsildar for those

whose dues are more that Rupees 1 lacs and they have not

deposited the money after the time given by amin.


14. Tehsildar issues the warrant and forwards to WBN . Tehsildar

15. WBN forwards the warrant to Amin. WBN

361

16.

Amin informs the citizen and starts assessment of

defaulter movable/nonmovable property for auction.

After auction Amin collects the money and deposits in

treasury against the RC and takes the challan which he

further provides to WBN and updates him.

Amin

17. WBN updates the eDistrict application. WBN

18.

The e-district application then notifies the details

regarding the updated status of the RC to DM, Tehsildar,

Nayab Tehsildar.

eDistrict Application.

Dues & Recovery Status Tracking

6.

The citizen would be able to know the status of details of

the RC against him through SMS, Online and CSC/e-Suvidha

centre, once the RC are verified by Amin on issued notice.

The fields required for the citizen is the details of RC.


7.

The citizen can get the final status through Online or

visiting to CSC/e-Suvidha centre or through SMS after

submitting his dues at CSC center or to Amin.



Dues & Recovery Monitoring

10.


processing of RC given by various departments to the DM

office.

MIS Component 1

11.



Department wise RC issued.

Complete detail of Dues i.e Arrears, Returned for

correction, stayed by court/Admin order/dept,

irrecoverable dues & collection detail etc. (refer to

monitoring report mentioned below)

MIS Component 1

12.

<MIS 1> component will auto generate weekly/

monthly/yearly report for the DM, ADM, CRA, Tehsildar,

Nayab Tehsildar to provide the following information

(refer to monitoring report mentioned below)

MIS Component 1

13. The monitoring component <MIS 2> relates to monitor the

successful completing the overall activity MIS Component 2

14. <MIS 2> component will monitor and track the following MIS Component 2

362


All details as described in process details has been

updated by the WBN

Confirmation of information for ready delivery of the

RC

15.

<MIS 2> component will auto generate weekly report and

provide the following information –

Total number of RC successfully processed and

recovered for which final information has been

updated by the WBN.

Total number of application for which recovery is

delayed by the Amin beyond the defined service level

MIS Component 2

Database required


1 RC Database This database will contain details of a citizen like Name, Age and Address. It should also contain details regarding due to be paid by the citizen (amount), the department to which the amount is due. The database will also maintain record of all Form 69 Notices issued to the citizen from Nayab Tehsildar for recovering the dues.

363


The fields required in showing the status of registered application are as follows:


1 Serial Number

2 Tehsil Name

3 RC Issuing Department Name

4 Department Number/Code

5 RC Issuance Date

6 RC Receiving Date

7 Defaulter Name

8 Defaulter Address

9 Amount Balance

10 Amount balance with Applicable Interest

11 Collection Charges Applicable

12 Capital Amount to be Recovered

13 Total Amount to be recovered from defaulter

14 Collection charges

15 Collection charges – Treasury Challan No.

16 Capital Amount deposited - Bank Challan No.

364

Service Level – Dues & Recovery

S. No. Activities Service Level ( from date of service request)

1. Entry of RC details in the e-District Application by the Clerk at the DM Office.

1st day

DM forwards to respective officials 2nd day

2. Nayab Tehsil digitally signs the RC

and issues the notices on FORM 69

for recovery

3rd day

3. WBN gives the notice to Amin for recovery

4th day

4 WBN updates the e-District Application, upon receiving of money from Amin(who collect it from citizen)

24 hours from receiving of payment

365



Service Level

L1

L2

L3

Name Time Name Time Name Time

1 DM forwards the RC DM 1st Day DM 2nd Day

2 After the notification by

the e-District

application, digitally

signs the RC and issues

the notices for recovery

Nayab Tehsildar

1st Day SDM/Tehsildar

2nd Day ADM(F&R) / CRA

3rd Day DM 4h Day

3 E-District application

generates a trigger

against those defaulter

whose pending amount is

more than 1 Lacs and

they have not deposited

their dues after receiving

of notice given by Amin

Tehsildar 1st Day SDM 2nd Day ADM 2nd Day DM 3rd Day

366

CRUD Matrix for Dues and Recovery



Magistrate ■ ■ ■ X

CRA ■ ■ ■ X

SDM ■ ■ ■ X


Nayab Tehsildar X ■ ■ X

WBN\ AWBN X ■ ■ X


X ■ X X


The following table specifies the designations that need to receive the Digital

Signatures:


11. DM 1

12. ADM(FR) 1

13. CRA 1

14. SDM All

15. Tehsildar All

16. Nayab Tehsildar All

17. WBN & AWBN All

367

Monitoring Report

The following table specifies the fields required in the MIS-1 Report

PART 1:

Sl. NO

DUES NAME

DEMAND AS ON FIRST APRIL(ARREAR)

INCREASE IN DEMAND

DEMAND SENT BACK REVISED OR RETURN IN APPEAL

DEMAND OF UPTT RETU. DURING THE MONTH

OTHER DEMAND DURING THE MONTH

IRRECOV-ERABLE DEMAND

REVISED DEMAND

STAYED BY COMPETANT COURT

STAYED BY ADMINIS. ORDER

1.

2.

CONT..

IRRECOV-ERABLE DEMAND WHICH HAS BEEN RETURN

DEMAND RECIVED AFTER 15th FEB.

NET DEMA-ND

MONTHLY

COLLECTION

AMT. DEPOSIT UPTO THE PREVIOUS MONTH

PROGRES-SIVE ARREAR

PROGRESSIVE COLLECTION

BALANCE OF NET DEMAND

BALANCE OF REVISED DEMAND

PERCENTAGE (%)

ARREAR

CURRENT

ARREAR

CURRENT

The following table specifies the fields required in the MIS-2 Report

S. NO

DUES NAME

DEPT. NAME

BRANCH NAME

TEHSIL DATE OF RC

DEPT. CODE

NAME OF RC HOLDER

ADDRESS AMOUNT OF RC

RECIVED AMOUNT

BALANCE

1.

2.

368

Functional Requirement Specification – (Dues & Recovery)

Sr. Description

1. The system should be able to display RC related page through multiple

routes

Service links

Information links

District links




Dues & Recovery related services both in public as well as restricted




4. The system should provide all services under Dues & Recovery under a

single category

5. The system should be able to channel as well as handle different Dues &

Recovery as per the process map and relevant description for the service

mentioned

6. The system should allow the operator – Clerk at DM office to fill in the

online RC application onto the e-district application.



component.



9. The system should be able to allow service fees payments for the Dues &

Recovery service as per the „Payment Component‟

10. The system should be able to route the RC details to concerned officer at

the following levels –

ADM (F&R)

CRA

369

Sr. Description

Tehsildar

Nayab Tehsildar

11. The system should be allow the head clerk at the DM Office, to allocate

service request to concerned Nayab Tehsildar for processing and recovery

of certain pending due.



13. The system should auto generate notification of arrest warrants issued

against the citizen, for the recovery of his dues. The list should be auto

generated and made available date wise, so as the citizen can verify from

the e-district application , whether an arrest warrant has been issued

against him or not.

14. The system should save the record details only on digital signature of the

WBN, since he is updating the system on receiving of payment by the Amin

15. The system should notify all the respective stakeholders mentioned – DM,

Tehsildar, Nayab Tehsildar about the status of final completion.

16. The system should show a successful submission screen on completion of

the due.






service levels are not met as defined in the service level description for the

process


21. The system should be able to maintain all records for the login sessions

with date and time



370

4.2 Employment Related Services

SGSY Employment Exchange PMRY NREGP

SGSY





through e-District application to BDO without being manually forwarded as a





The department should accept the validity of digitally signed document on par

with any physically signed document.



Mandatory status update by the GPVA at various stages of SGSY scheme.




service close to their homes and would not need to travel to Block or Tehsil

office

371




information about the status of their applications.




372

SGSY

Gra

m V

ika

s A

dh

ika

riG

ram

Vik

as A

dh

ika

riE

-Dis

tric

t

Ap

plica

tio

n

E-D

istr

ict

Ap

plica

tio

nB

DO

BD

OA

pp

lica

nt

Ap

plica

nt

System saves the

application and Issues

a Receipt with a

Unique Application

Number.

Notifies the BDO

Form Availability

component

Applies to express intent of

forming a Self Help Group.

The Application includes the

tentative group members list

Receives the

application

Assignes the

Application to any

Local Gram Vikas

Adhikari

Visits the Group in

their village and

Explains the

scheme to them

Receives the

application

Saves the Assignment

of the GVA against an

application.

Notifies the GVA ad

the Applicant

Helps the group

open a Bank

Account and Fill

up the Application

form for SGSY

scheme

Updates the Status manually

specifying dates when:

1. Scheme explained in details

2. Bank Account opened

3. Group members finalized

Saves and Updates

the Status input by the

GVA.

Notifies the Applicant

Receives the

Assignment of GVA

Receives the

notification

Start

Stop

373

SGSY – Status Tracking

Gra

m V

ika

s A

dh

ika

riG

ram

Vik

as A

dh

ika

riE

-Dis

tric

t

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nB

DO

BD

OA

pp

lica

nt

Ap

plic

an

t

System saves the


a Receipt with a

Unique Application

Number.

Notifies the BDO

Status Tracking

component

Receives the

application

Assignes the

Application to any

Local Gram Vikas

Adhikari

Receives the

application



application.

Notifies the GVA ad

the Applicant






Saves and Updates


GVA

Status Tracking

component

Status Tracking

component

Helps the group

open a Bank

Account and Fill

up the Application

form for SGSY

scheme

Visits the Group in

their village and

Explains the

scheme to them

374

SGSY - MonitoringG

ram

Vik

as A

dh

ika

riG

ram

Vik

as A

dh

ika

riE

-Dis

tric

t

Ap

plica

tio

n

E-D

istr

ict

Ap

plica

tio

nB

DO

BD

OR

ece

ivin

g A

uth

ority

Re

ce

ivin

g A

uth

ority

System saves the


a Receipt with a

Unique Application

Number.

Notifies the BDO

MIS

Component 1

Receives the

application

Assignes the

Application to any

Local Gram Vikas

Adhikari

Receives the

application



application.

Notifies the GVA ad

the Applicant






Saves and Updates


GVA

MIS

Component 2

MIS

Component 3

Helps the group

open a Bank

Account and Fill

up the Application

form for SGSY

scheme

Visits the Group in

their village and

Explains the

scheme to them

375

SGSY – Grading RequestG

ram

Vik

as A

dh

ika

riG

ram

Vik

as A

dh

ika

riE

-Dis

tric

t

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nB

DO

BD

OA

pp

lica

nt

Ap

plic

an

t

System saves the


a Receipt with a

Unique Application

Number.

Notifies the BDO

Form Availability

component

Applies to request for

Grading of his Self Help

Group.

Receives the

application

Assignes the

Application to any

Local Gram Vikas

Adhikari

Receives the

application



application.

Notifies the GVA ad

the Applicant

Schedules the Grading process

by the Banks for the Self Help

group



1. Grading completed

2. Result of the Grading process

Saves and Updates


GVA.


Receives the

Assignment of GVA

Receives the

notification

Stop

Start

376

SGSY – Grading Request (Status Tracking)G

ram

Vik

as A

dh

ika

riG

ram

Vik

as A

dh

ika

riE

-Dis

tric

t

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nB

DO

BD

OA

pp

lica

nt

Ap

plic

an

t

System saves the


a Receipt with a

Unique Application

Number.

Notifies the BDO

Status Tracking

component

Receives the

application

Assignes the

Application to any

Local Gram Vikas

Adhikari

Receives the

application



application.

Notifies the GVA ad

the Applicant



group





Saves and Updates


GVA.


Status Tracking

component

Status Tracking

component

377

SGSY – Grading Request (Monitoring)G

ram

Vik

as A

dh

ika

riG

ram

Vik

as A

dh

ika

riE

-Dis

tric

t

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nB

DO

BD

OR

ece

ivin

g A

uth

ority

Re

ce

ivin

g A

uth

ority

System saves the


a Receipt with a

Unique Application

Number.

Notifies the BDO

MIS Component 1

Receives the

application

Assignes the

Application to any

Local Gram Vikas

Adhikari

Receives the

application



application.

Notifies the GVA ad

the Applicant



group





Saves and Updates


GVA.


MIS Component 2 MIS Component 3

378


SGSY Process

1 The Form for expression of interest in forming a Self Help group

would be made available by the Forms Availability component. BDO

2

The Applicant files his application expressing interest to form a

Self Help group. The Application will include a tentative list of

group members

Applicant

3 The e-District Application (eDA) saves the application and issues a

Receipt with a unique Application number


(eDA)

4 The eDA then notifies the BDO of the new Application eDA

5 The BDO receives the Application and Assigns a local Gram Vikas

Adhikari (GVA) to the application. BDO

6 The eDA saves the assignment of the GVA to the application and

notifies the GVA and the Applicant eDA

7 The GVA receives the Application and downloads it from the eDA Gram Vikas Adhikari

(GVA)

8 The GVA visits the group in the village and explains the scheme to

them in details GVA

9 The GVA helps the group open a Bank Account and helps them in

filling up the SGSY Application form GVA

10

The GVA then updates the status manually in the eDA specifying

the dates when:

b. Scheme explained in detail

c. Bank Account opened

d. Group members finalized

GVA

11 The eDA saves and updates the Status inputs by the GVA and

notifies the BDO and Applicant about the same. eDA

Sr. SGSY Application Status Tracking details Responsibility Centre

1 The Status Tracking and Escalation would be handled by the

Status Tracking component. eDA



3 The Applicant will be notified about assignment of a Gram Vikas

Adhikari (GVA) for his application eDA

4

The Applicant will be notified whenever GVA updates the status

of:

a. Scheme explained in detail

b. Bank Account opened

eDA

379

c. Group members finalized


Application to request Grading of the Self Help group

1 The Form for requesting Grading of the Self Help group would be

made available by the Forms Availability component. BDO

2 The Applicant files his application requesting Grading of his Self

Help Group. Applicant

3 The e-District Application (eDA) saves the application and issues a

Receipt with a unique Application number.


(eDA)

4 The eDA then notifies the BDO of the new Application eDA

5 The BDO receives the Application and Assigns a local Gram Vikas

Adhikari (GVA) to the application. BDO

6 The eDA saves the assignment of the GVA to the application and

notifies the GVA and the Applicant eDA

7 The GVA receives the Application and downloads it from the eDA Gram Vikas Adhikari

(GVA)

8 The GVA schedules the grading process by the banks for the Self

Help group. GVA

9

The GVA then updates the status manually in the eDA specifying

the dates when:

a. Grading process completed

b. Result of the Grading process

GVA

10 The eDA saves and updates the Status inputs by the GVA and

notifies the BDO and Applicant about the same. eDA

Sr. SGSY Grading Request Status Tracking details Responsibility Centre


Tracking component. 1


Application to the concerned officer 2

3 The Applicant will be notified about assignment of a Gram Vikas

Adhikari (GVA) for his application 3

4

The Applicant will be notified whenever GVA updates the status of:

a. Grading process completed

b. Result of the Grading process

4

380

Databases required


1 SGSY Database The Database will store the application details of

request for new Self Help group and request for

grading and the status of the application as updated

manually by the GVA.

CRUD Matrix for SGSY



CDO ■ ■ ■ ■ DDO ■ ■ ■ ■ BDO ■ ■ ■ X

ADO ■ ■ ■ X

GVA ■ ■ ■ X


X ■ X X

Service Request Forms - SGSY

The fields required in the online form for every requesting a grading are as follows:


1 Names of members of the Self Help Group

2 Address

3 Nature of Business




2 Address of the Applicants


Internal Service Levels – SGSY


Requesting for a new Self Help group

381

S.No Activity Time required Service Level in days

1. Form Availability

1 day

Online / Immediate

2. Submission of Online Form and Payment

1st Day

3. Assigning a Gram Vikas Adhikari (GVA) by the BDO

2nd Day

4. GVA visiting the village and explaining the scheme in detail to the Group

3 days 5th day

5. GVA helping in finalizing the group members and opening a Bank account.

5 days 10th day

6. Updating the status manually on the e-District Application

1 days 11th day

Requesting for Grading of the Self Help group

S.No Activity Time required Service Level in days (from date

of service request)

1. Form Availability Online / Immediate Online / Immediate

2. Submission of Online

Form and Payment Immediate 1st Day

3. Assigning a Gram Vikas

Adhikari (GVA) by the

BDO

1 day 2nd Day

4. GVA visiting the village

and scheduling the

Grading Process

3 days 5th day

5. GVA helping in finalizing

the group members and

opening a Bank account.

5 days 10th day

6. Updating the status

manually on the e-


1 day 11th day

382

Monitoring Report

The following table specifies the fields required in the MIS Reports

MIS Report 1 for New Self Help group applications

S.No Name of the Block

Number of New Self Help Group Applications received

Number of Self Help groups successfully started

Number of Applications rejected – with reasons

5.

6.

7.

MIS Report 2 for grading of Self Help groups requests

S.No Name of the Block Number of Grading requests received

Number of Groups graded successfully

Number of groups graded unsuccessfully

1.

2.

3.

MIS Report 3





1

2

3

383




Service Level

L1

L2

L3


1. Assigning a Gram Vikas Adhikari (GVA) by the BDO

BDO 1 day DDO 1 day CDO 2 days DM 3 days

2. GVA visiting the village explaining the scheme, and opening bank account and updating this status on the eDA

GVA 9 days DDO 1 day CDO 2 days DM 3 days

3. GVA scheduling the Grading process and updating the status on eDA

GVA 9 days DDO 1 day CDO 2 days DM 3 days

384



S.No Designation Number of Digital Signature required

1. CDO 1

2. DDO 1

3. BDO All

4. GVA All

Functional Requirement Specification – SGSY

Sr. Description

1.

The system should be able to display Employment related service page through

multiple routes

Service links

Information links

District links


the login component

3.

The Information regarding the requirements for forming a Self Help group and

other details of the scheme should be made available as per Information

Dissemination component both in public as well as restricted domain.



4.

The system should provide all services under various Employment schemes under

a single category “Employment Related Schemes” with following sub categories –

SGSY

Employment Exchange

PMRY

5.

The System should ensure availability of Forms for requesting a new Self Help

group and requesting Grading of their Self Help group as per the Form

Availability component.

6. The System should allow the Applications for new Self Help group and Grading of

a Self Help group to be submitted online.

7. The System should be able to generate a receipt with a Unique Application

Number.

8. The System should be able to identify the Applicant on the basis of this Unique

Application Number.

385

Sr. Description



10.

The System should be able to notify the BDO of the new application and allow

him to view the Application details as per the „Records View for the Logged in

Officer‟

11. The System should be able to retrieve and display the complete Application to

the BDO on clicking on any one of the records.

12. The System should enable the BDO to assign a GVA to the application and

forward the application to him.

13. The System should save the assignment of the GVA to an application and notify

the assigned GVA of the new application.

14. The System should also notify the applicant about the assignment of GVA.

15. The System should allow the GVA to download the complete application.

16.

The System should allow the GVA to manually update the Status of Application


Scheme explained in details

Bank Account opened

Group members finalized

Grading completed

Result of Grading



18.





Issue of Copy of Khatauni Status process map.

20. The System should be able to generate MIS reports as per the format specified in

the table Monitoring Report.


in the Issue of Copy of Khatauni MIS process map.

22.

The System should have a facility for forwarding of the application, with remarks

and digital sign of the sender, to any person in District administration registered

with the System.

386

Sr. Description

23.

The system should support multilingual interface (minimum Hindi and English) as

per Localization and Language Technology Standards for National e-Governance

Plan defined in e-district guidelines.

24.

The e-District Application must support Digital Signatures of any of the Certifying


modifiable as per the changes made by the respective Certifying Authorities on

the structure of the Digital Signatures issued by them.

25.



2000.

26.



system.

387

Employment Exchange





through e-District application to Employment Exchange Office without being

manually forwarded as a noting on service request file.




The department should accept that no original documents will be required for

registration, only photocopies would be submitted.

The department should accept that the Registration Number would be

automatically generated at time of application itself without any approval. This

Registration Number can be canceled / deleted by the DEO on later inspection

of documents.



Adequate IT Infrastructure will be provided and maintained at the Employment

Exchange.







388






389

Employment exchange

Employment Exchange

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nE

mp

loym

en

t E

xch

an

ge

Offic

eE

mp

loym

en

t E

xch

an

ge

Offic

eA

pp

lica

nt

Ap

plic

an

t

System saves the

application and generates

a Job Card with a Unique

Registration Number.

Notifies the DEO

Form Availability

component makes

the registration

form available

Receives the

application along with

the assigned

Registration Number

The clerk assigns an

NCO Code to the

application and makes

the entry in the Register

X 63

Application Received

as per Application

Receipt component

with Mandatory Photo

The clerk makes an entry

into the Database against

the Registration number

specifying NCO Code and

mentioning completion of

registration process

System saves the NCO Number and

the Completion of Registration

process status against the

Registration number.

Notifies the Applicant of the NCO

Code and Completion of process

Receives the NCO

Code and Registration

process status.

If all particulars correct

Yes

DEO Deletes the Entry

from the database and

provides a reason

No

System deletes the

application and the


Notifies the Applicant of

the reason

Receives the Deletion

Notification and the

reasonStop

Start

390

Employment exchange - Status

Employment Exchange - Status

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nE

mp

loym

en

t E

xch

an

ge

Offic

eE

mp

loym

en

t E

xch

an

ge

Offic

eA

pp

lica

nt

Ap

plic

an

t

System saves the




Notifies the DEO

Receives the


the assigned

Registration Number


NCO Code to the



X 63

Status Tracking

component














Yes



provides a reason

No

System deletes the

application and the



the reason

Status Tracking

component

Status Tracking

component

391

Employment exchange - Monitoring

Employment Exchange - Monitoring

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nE

mp

loym

en

t E

xch

an

ge

Offic

eE

mp

loym

en

t E

xch

an

ge

Offic

eR

ece

ivin

g A

uth

ority

Re

ceiv

ing

Au

tho

rity

System saves the




Notifies the DEO

Receives the


the assigned

Registration Number


NCO Code to the



X 63

MIS

Component 1














Yes



provides a reason

No

System deletes the

application and the



the reason

MIS

Component 3

MIS Component

2

392


Registration of candidates

1 The Form for Registering on the Employment Exchange should be

made available as per the Forms Availability component.

District Employment

Officer (DEO)

2 The Application is received along with required documents as per

the Application Receipt component with Mandatory Photo


(eDA)

3 The eDA saves the application data and generates a Unique

Registration Number. eDA

4 The eDA notifies the DEO eDA

5

The DEO or any other authorized Officer at the Employment

Exchange Office receives the Application along with the assigned

Registration Number

Employment Exchange

Office

6 The authorized officer inspects the application and if he finds

anything incorrect he informs the DEO of the same.

Authorized officer /

clerk

7 The DEO deletes the Entry from the database and provides a

reason for the same DEO

8 The eDA deletes the application and the Registration Number,

and notifies the applicant of the deletion and the reason provided eDA

9 The Applicant receives the notification of deletion and the reason

for the same Applicant

10

If everything is correct with the application, the authorized

officer / Registration Clerk assigns a NCO Code to the application

and makes the entry into the Register X 63


clerk

11

The authorized officer / Registration Clerk makes an entry in the

Database against the Registration number specifying the NCO

Code and date of completion of Registration process


Clerk

12 The eDA saves the NCO Code and the Registration completion

status against the Registration Number. eDA

13 The eDA notifies the Applicant of the NCO Code and the

Registration completion status eDA

14 The Applicant receives the NCO Code and the Registration

completion status Applicant

Sr Employment Exchange Status tracking Responsibility Centre

The Status Tracking and Escalation would be handled by the

Status Tracking component. eDA

The Applicant will be notified of acceptance and delivery of his eDA

393

Application to the concerned officer

The Applicant will be notified if his application being rejected

and Registration Number being deleted. eDA

The Applicant will be notified when his NCO Code has been

assigned and the Registration process is complete. eDA

394

Databases required


1 Employment Exchange Database

The Database will store the Registration application

details and associated Unique Registration Number

and the NCO Code. The Database will also have

provision to display the status of the Registration

process.

CRUD Matrix for Employment Exchange


District Magistrate ■ ■ ■ ■ GM DIC ■ ■ ■ ■

Other DIC Staff X ■ ■ X


X ■ X X

Service Request Forms – Employment Exchange

The fields required in the online form for registering on the Employment Exchange are as

follows:


1. Name

2. Father‟s / Husband‟s Name

3. Religion

4. Caste

5. Date of Birth

6. Date of Registration

7. Qualifications (Highest Exam passed, Subjects taken, Rank,

Institute‟s Name, Year of passing, Remarks)

8. Identification mark

9. Address

10. Marital Status (Married/Widow/Widower/Divorced/Single)

11. Main Business

12. Any other business

395


13. Any preference for place of job

14. Special Talent

15. Previous job details (Employer‟s details, Job description, Date of

employment, Last drawn salary, Remarks)

16. Languages known and proficiency (Written, spoken, reading)

17. Eyesight, Height, Weight, Chest, Any physical weakness

18. Do you want to work in army (Yes/No)

19. Only for people who have previously served in the army (Name

of the employer, Position, Regiment, Date of joining, date of

leaving, Character, reason for leaving)

The Documents (Photocopy) required along with the Application are:

1. Education Proof

2. Caste certificate

3. Age Proof

4. Four Self-Addressed postcards.

Field Description of the Job card


1. Name

2. Registration Number

3. Father‟s / Husband‟s Name

4. Religion

5. Caste

6. Date of Birth

7. Date of Registration

8. Qualifications (Highest Exam passed, Subjects taken, Rank, Institute‟s Name,

Year of passing, Remarks)

9. Identification mark

10. Address

11. Languages known and proficiency (Written, spoken, reading)

396



1 Registration Number


3 Address

4 Qualifications in brief

Internal Service Levels


S.No Activity Time Required Service Level (From date

of service request

1. Form Availability

Online / Immediate

Day 0

2. Submission of Online Form Immediate Day 0

3. Deletion of entry and providing a reason

1 day

1st Day

4. Assigning a NCO Code and entry into the X 63 Register.

1st Day

5. Updating the NCO Code and Registration completion status in the Database

1st Day

6. Notification to Applicant regarding NCO Code and Registration process status or of Deletion of entry and reason.

1st Day

Monitoring Report

The following table specifies the fields required in the MIS Reports

S.No Number of Registration requests received

Number of Registrations completed successfully

Number of Registrations deleted

1.

2.

3.

397




Service Level

L1

L2

L3


1. Evaluation of the submitted application

Any authorized

officer at the Employment

Exchange

1 day ADEO 1 day DEO 2 days DM 3 days

2. Deletion of Entry and providing a reason

DEO 1 day DM 2 days - - - -

3. Assigning of NCO Code and Entry into the X 63 Register and Entry into the database of NCO code and Registration status

Any authorized

officer at the Employment

Exchange

1 day ADEO 1 day DEO 2 days DM 3 days

398




1. CDO 1

2. DEO 1

3. ADEO All

Functional Requirement Specification – Employment Exchange

Sr. Description

1.


multiple routes

Service links

Information links

District links


the login component

3.

The Information regarding the requirements for registering on the Employment

Exchange and other details should be made available as per Information

Dissemination component both in public as well as restricted domain.



4.

The system should provide all services under various Employment schemes under

a single category “Employment Related Schemes” with following sub categories –

SGSY

Employment Exchange

PMRY

5.


multiple routes

Service links

Information links

District links

6. The System should ensure availability of Forms for registration on Employment

Exchange as per the Form Availability component.

399

Sr. Description

7. The System should allow the Applications for registration on Employment

Exchange to be submitted online as per the Application Receipt component.

8. The System should ensure that the photo of the Applicant is captured and

attached with the Application before it can be submitted.

9. The System should be able to generate a Job Card with a Unique Registration

Number, Name, Photo, Address, NCO Code, Qualifications and Address.

10. The System should be able to identify the applicant based on this Registration

Number.



12.

The System should be able to notify the ADEO or any authorized officer at the

Employment Exchange office of the new application and allow him to view the

Application details as per the „Records View for the Logged in Officer‟

13. The System should be able to retrieve and display the complete Application to

the authorized officer on clicking on any one of the records.

14. The System should allow Only the DEO to delete / cancel a Registration Number.

15. The System should ensure that a reason is provided for any deletion and that the

DEO signs it using his digital signature

16.

The System should allow the authorized officer or clerk to update the

application with the NCO Code against a Registration Number and also update

the Status of Registration process as complete.

17. The System should be able to notify the Applicant of the assigned NCO Code and

the Status of the Registration process whenever it is updated.



19.





Issue of Employment Exchange Status process map.

21. The System should be able to generate MIS reports as per the format specified in

the table Monitoring Report.

400

Sr. Description


in the Issue of Copy of Khatauni MIS process map.

23.

The System should have a facility for forwarding of the application, with remarks

and digital sign of the sender, to any person in District administration registered

with the System.

24.

The system should support multilingual interface (minimum Hindi and English) as

per Localization and Language Technology Standards for National e-Governance

Plan defined in e-district guidelines.

25.

The e-District Application must support Digital Signatures of any of the Certifying


modifiable as per the changes made by the respective Certifying Authorities on

the structure of the Digital Signatures issued by them.

26.



2000.

27.



system.

401

PMRY Select Prerequisites for the ToBe processes

The department should accept the provision of Common Service Centre / e District

Centres accepting service request application from the applicants.

The department should accept the provision of forwarding service request through e-

District application to DIC without being manually forwarded as a noting on service

request file.


application to another official electronically through digital signing and electronic

mode of transfer.

The department should accept the validity of digitally signed document on par with

any physically signed document.

The department should accept validity of a secure, digitally signed database as an

authentic and trustable source for verification.

Mandatory status update by the GPVA at various stages of PMRY scheme.



Service delivery at village level. The citizens would be able to avail of the service

close to their homes and would not need to travel to Tehsil office

Quicker service. Automated workflow and digital signature would speed up the

service delivery time and improve the service levels for the service.

Status Tracking of an application. Citizens will now have up to date information

about the status of their applications

402

Monitoring of interviews, training and subsequent performance. The Process

owners would be able to better monitor the process of interviews, trainings and

subsequent performance through MIS reports.

403

Pradhan Mantri Rozgar Yojna

Pradhan Mantri Rozgar Yojna – Registration ProcessD

ICDIC

E-D

istr

ict

Ap

plic

atio

nE

-Dis

tric

t A

pp

lica

tio

nA

pp

lica

nt

Ap

plic

an

t

The system forwards the

application to the DIC

office/DIC staff.

Payment

Component

Form

Availability

Component

Application

Receipt

Component

The DIC verifies the

documents submitted along

with the application form.

The interview date gets

updated in the database

The job card containing the

interview date is made

available to the applicant

Documents to be submitted

at the time of registration

Education Proof

Caste Certificate

Address Proof

Experience Certificate

4 self addressed envelopes

Yes

Is the application form

accepted?

No

The decision is updated

in the database

Receives the rejection

Start

Stop

Application

rejected as per

the Rejection

component

404

Pradhan Mantri Rozgar Yojna – Declaration of Interview ResultD

ICDIC

E-D

istr

ict

Ap

plic

atio

nE

-Dis

tric

t A

pp

lica

tio

nA

pp

lica

nt

Ap

plic

an

t

The DIC staff updates the

result of the interview in the

database

The decision is updated in the

database

The decision is made

available to the applicant

405

Pradhan Mantri Rozgar Yojna – Training Date Availability ProcessB

an

kB

an

kE

-Dis

tric

t A

pp

lica

tio

nE

-Dis

tric

t A

pp

lica

tio

nD

ICDIC

Ap

plic

an

tA

pp

lica

nt

Once the applicant clears

the bank interview, DIC

arranges for the training

process

The DIC provides

a training date for

each applicant

The training date

is updated in the

database

The training date

is made available

to the applicant

The applicant

undergoes the

training process

Was the training

successful

Yes

The application is

forwarded to the bank

The status of the training

is updates in the database

The status is updates in

the database

No

Bank receives the

application from

DIC

Approves the loan

amount and

informs to DIC

The database is

updated by the

DIC

The applicant can

approach the bank

to collect the loan

amlount

406

Pradhan Mantri Rozgar Yojna – Status

DICDIC

E-D

istr

ict

Ap

plic

atio

nE

-Dis

tric

t A

pp

lica

tio

nA

pp

lica

nt

Ap

plic

an

t



office/DIC staff.

Status Tracking

component






Documents to be submitted at the time of

registration

Education Proof

Caste Certificate

Address Proof



Yes


accepted?

No


in the database

Application

rejected as per

the Rejection

component

Status Tracking

component

Status Tracking

component

407

Pradhan Mantri Rozgar Yojna – Declaration of Interview Result – Status TrackingD

ICDIC

E-D

istr

ict

Ap

plic

atio

nE

-Dis

tric

t A

pp

lica

tio

nA

pp

lica

nt

Ap

plic

an

t



database

The decision is updated in the

database

Status Tracking

Component

408

Pradhan Mantri Rozgar Yojna – Training Date Availability Process – Status TrackingB

an

kB

an

kE

-Dis

tric

t A

pp

lica

tio

nE

-Dis

tric

t A

pp

lica

tio

nD

ICDIC

Ap

plic

an

tA

pp

lica

nt




process

The DIC provides

a training date for

each applicant

The training date

is updated in the

database

Was the training

successful

Yes

The application is





the database

No

Bank receives the

application from

DIC

Approves the loan

amount and

informs to DIC

The database is

updated by the

DIC

Status Tracking

ComponentStatus Tracking

Component

409

Pradhan Mantri Rozgar Yojna – MIS

DICDIC

E-D

istr

ict

Ap

plic

atio

nE

-Dis

tric

t A

pp

lica

tio

nR

ece

ivin

g A

uth

ori

tyR

ece

ivin

g A

uth

ori

ty



office/DIC staff.

MIS Component






Documents to be submitted at the time of

registration

Education Proof

Caste Certificate

Address Proof



Yes


accepted?

No


in the database

Application

rejected as per

the Rejection

component

MIS Component MIS Component

410

Pradhan Mantri Rozgar Yojna – Declaration of Interview Result – MISD

ICDIC

E-D

istr

ict A

pp

lica

tio

nE

-Dis

tric

t A

pp

lica

tio

nR

ece

ivin

g A

uth

ority

Re

ce

ivin

g A

uth

ority



database

The decision is updated in

the database

MIS Component

411

Pradhan Mantri Rozgar Yojna – Training Date Availability Process - MISB

an

kB

an

kE

-Dis

tric

t A

pp

lica

tio

nE

-Dis

tric

t A

pp

lica

tio

nD

ICDIC

Re

ce

ivin

g

Au

tho

rity

Re

ce

ivin

g

Au

tho

rity




process

The DIC provides

a training date for

each applicant

The training date

is updated in the

database

Was the training

successful

Yes

The application is





the database

No

Bank receives the

application from

DIC

Approves the loan

amount and

informs to DIC

The database is

updated by the

DIC

MIS ComponentMIS Component

412

S.No. Process Details Responsibility Centre

1. The applicant approaches the CSC/e-district center for the registration purpose. The applicant has to pay the requisite application fee for the registration purpose. The applicant requires the following documents for the registration purpose:

Education Proof

Caste Certificate

Address Proof


Business Proposal

4 self-addressed postcards These self-addressed postcards will be used to inform the applicant of the interview date

Applicant

2. The application is received by the CSC as per the application receipt component along with the following documents:

Education Proof

Caste Certificate

Address Proof


Business Proposal

4 self-addressed postcards

CSC

3. The system generates an acknowledgement confirming the registration process


4. The system forwards the application to the DIC office.


5. The information in the application form is verified against the documents submitted by the applicant

DIC

6. Depending on the interview date availability, an interview date for each applicant is updated in the database

DIC

7. The system generates a receipt for each applicant. The receipt contains each applicant‟s registration number and the interview date.


413

8. The result for each applicant‟s interview is updated in the database

DIC

9. A training date for each applicant is chosen which is updated in the database

DIC

10. Trainings are conducted for all the applicants DIC

11. The status of training completion for each applicant is updated in the database

DIC

12. After successful completion of the training process, the application is forwarded to the bank

DIC

13. The loan amount is approved and the status is informed to DIC

Bank

14. The status of the loan approval is updated in the database

DIC

15. The loan amount is collected from the bank Applicant

Database Required S. No. Database Remarks

1 PMRY Database

The PMRY database will contain the PMRY application

details like Name, Age, Address and information details.

The database would also maintain a record of the bank

interview dates as well as the training dates of each

applicant. The database would also maintain a record of the

status for each applicant.

CRUD Matrix for PMRY



CDO ■ ■ ■ ■

DDO ■ ■ ■ ■

BDO ■ ■ ■ X

ADO ■ ■ ■ X

GVA ■ ■ ■ X


X ■ X X

414

Service Request form

S.No. Field Description of the form

1. Name

2. Father‟s/Husband‟s Name

3. Father‟s/Husband‟s Occupation

4. Permanent Address

5. Interview Date (To be filled in by the DIC staff)

6. Have you been residing in the place for the past 3 years from where you have applied for a loan (Yes/No)

7. Date of Birth

8. Age at the time of applying for loan

9. Qualification

10. Any Technical Qualification obtained? If yes, then give details

11. Are you registered with the employment exchange? If yes, then give details

12. Caste

13. Handicapped/Women

14. Business details

15. Any previous experience related to the business

16.

17. Family‟s annual income

18. Cost of business

19. Contribution by applicant

20. Prior to this, have you taken any loan from any agency? If yes, then give details

21. Loan amount

22. Name of the bank from where the loan is applied

23. I hereby confirm that the information provided by me is true to the best of my knowledge.

24. I --------------- son/daughter/wife of Mr. …………, resident of ---------------------------------- declare that:

i. I am unemployed ii. I am unable to put in the entire amount for the business iii. I am a resident of -------------- for the past ----------- years iv. Neither my Husband/Wife nor my Mother/Father earn more

than Rs. 24000 per annum v. I have not defaulted in any previous case vi. I agree to abide by all the rules of Pradhan Mantri Rozgar

Yojna (PMRY) Signature of the Applicant

Name of the Applicant

415

Records view for logged in User (DIC staff)

S.No. Field Description of the View

1 Name

2 Permanent Address

3 Qualification

4 Subject

Performa of the job card

S.No. Field Description of the view

1 Name

2 Date of Birth

3 Date of Registration

4 Registration Number

5 Qualification

6 Caste Address

7 Business Details

8 Loan Amount

9 Bank Name

10 Date of Interview

11 Self-Addressed Postcards (Yes/No)

12 Signature of Applicant

13 Signature of CSC

416

Monitoring reports MIS Report 1

S.No Number of Applications

received

Number of Interviews scheduled

Number of interviews conducted

Number of successful candidates

Number of candidates

approved by Banks

1.

2.

3.

MIS Report 2

S.No Number of people who participated

in training

Number of people who successfully

completed training

%age of attendance of

training programs

Number of people who have been

given loan amount by banks

1.

2.

3.

MIS Report 3





1.

2.

3.

417

Auto Escalation Matrix - PMRY



Service Level

L1

L2

L3


5.

Verification of application form against the documents submitted by the applicant

DIC staff 1 day GM DIC 1 day DM 2 days -

-

6.

Providing an interview date for each applicant

DIC staff 1 day GM DIC 1 day DM 2 days - -

7.

Updating the interview date for each applicant in the database

DIC staff 1 day GM DIC 1 day DM 2 days - -

8.

Updating the interview result for each

DIC Staff 1 day GM DIC 1 day DM 2 days - -

418

applicant in the database

9.

Completing the training process for each applicant

DIC staff 30 days GM DIC 30

days DM 2 days - -

10.

Updating the training result for each applicant in the database

DIC Staff 1 day GM DIC 1 day DM 2 days - -

11.

Forwarding the application to the bank

DIC Staff 2 day GM DIC 2 days DM 2 days - -

419

Internal Service Level – PMRY (Registration Process) S.No. Activities Service Level in

days Service Level (from date of

service request)

1. Filing of Application

1 day

1st day

2. Payment for the Application Form

1st day

3. Submission of Application 1st day

4. Generation of Receipt 1st day

5. Forwarding of Application Form to the DIC office

1st day

6. Verifying the documents submitted along with the application

1 day

2nd day

7. Providing an interview date to the applicant

2nd day

8. Updating the interview date in the database

2nd day

9. Interview date available to the applicant

1 day 3rd day

Interview Result Availability + Training Information Availability S.No. Activities

Service level in days

Service Level (from date of

result availability with DIC)

1. Updation of the interview result in the database

1 day 1st day

2. Completing the training process for each applicant

30 days 31st day

420

Training Result Availability S.No. Activities Service level in

days Service Level (from

date of result availability with DIC)

1. Updation of the training result in the database

1 day 1st day

2. Forwarding the application to the bank

3 day 4th day

Digital Signature Details

S.No. Authority Digital Signature Required

1. GM DIC 1

2. DIC Staff (Project Manager PMRY etc.) 2

421

Function Requirement Specification – Pradhan Mantri Rozgar Yojna (PMRY)

Sr. Description

1 The system should be able to display PMRY related page through

multiple routes

Service links

Information links

District links

2 The system should be able to identify user login into the system as



PMRY scheme both in public as well as restricted domain as per the




4 The system should provide the registration service for the PMRY

5 The system should be able to retrieve relevant service request form

using „form availability‟ component

6 The system should allow the operator to fill in the online application

on behalf of citizen availing the service as per the „application

receipt‟ component

7 The system should be able to generate the acknowledgement during

registering an applicant with the system as per the „application

receipt‟ component

8 The system should be able to identify the applicant uniquely based on

this registration number for all future references

9 The system should be able to generate a receipt containing the

registration number once the applicant is registered with the system


422


11 Status will be available to the citizen through the following channels:

i. SMS

ii. E-mail

iii. CSC/e-District center

12 The system should check for all the mandatory entries in the

application form before submission of application form

13 The system should be able to maintain all records for the login sessions

with date and time



15 The system should be able to forward the application request to the

concerned DIC staff

16 The system should be able to provide the interview date to the

applicant once the same has been updated in the database by the DIC

staff

17 The applicant should be able to track the status of his application

through the system, using the registration number provided to him

18 The system should be able to monitor the progress of each applicant‟s

request

19 The system should be able to provide the training details for each

applicant

20 The system should be able to forward the application to the respective

bank for loan approval

21 The system should be able to provide the approved loan amount

details to each applicant

22 The system should support multilingual interface (minimum Hindi and



23 The e-District Application must support Digital Signatures of any of the

423




issued by them.

24



IT Act 2000.

25



based system.

424

NREGP Process

NREGP Process flow

DR

DA

/ C

DO

DR

DA

/ C

DO

Gra

m P

anch

ayat

Vik

as

Adh

ikar

i

Gra

m P

anch

ayat

Vik

as

Adh

ikar

iB

DO

BD

OE

-Dis

tric

t

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nA

pp

lican

tA

pp

lican

t Start

Application

Receipt

Component

Application

Submission

Component

Applicant submits

application form with

req. documents

The eDistrict

Application registers

the application and

issue a receipt

Logs into the system

and looks for

particular request

Checks the

details in the

DataBase

Yes

No



Reject Particular

Application

Approved and digitally

signs the Job Card after

receiving the hard copy

of the application form

Particular records

gets updated Details checked

Applicant has

Job Card?

Application

Rejection

ComponentStop

Receives Job Card

Particular records

gets updated

GVPA prepares the

Project Design and

estimation of the Job

and sends it to BDO

for his approval

BDO receives the list

of applicant who

have been issued job

card

BDO approves the

Project Design and

releases the fund for

the plan

Details get updated

regarding the release

of funds in the e-


CDO is updated

about the release of

funds for the project

The citizen can find

out from the e-District

application, whether

work is allocated

against his job card

425

NREGP Status Tracking


DR

DA

/ C

DO

DR

DA

/ C

DO

BD

OB

DO

Gra

m P

an

cha

yat V

ika

s

Ad

hik

ari

Gra

m P

an

cha

yat V

ika

s

Ad

hik

ari

E-D

istr

ict

Ap

plic

ati

on

E-D

istr

ict

Ap

plic

ati

on

Ap

plic

an

tA

pp

lic

an

t

Yes

No

Receives Job CardApplicant submits

application form with

req. documents

Reject Particular

Application

The citizen can find out

from the e-District

application, whether work

is allocated against his job

card

Details get updated


of funds in the e-


Checks the

details in the

DataBase

The eDistrict


the application and

issue a receipt





Particular records

gets updated

Applicant has

Job Card?

GVPA prepares the

Project Design and


and sends it to BDO

for his approval

Details checked

BDO approves the

Project Design and


the plan




and looks for

particular request

CDO is updated




of applicant who


card

Particular records

gets updated

Status

ComponentsStatus

Components

Status

Components

Status

Components

426

NREGP Monitoring

NREGP Monitoring Process

DR

DA

/ C

DO

DR

DA

/ C

DO

BD

OB

DO

Gra

m P

anch

ayat

Vik

as

Adh

ikar

i

Gra

m P

anch

ayat

Vik

as

Adh

ikar

iE

-Dis

tric

t

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nR

ecei

vin

g A

uth

ori

tyR

ecei

vin

g A

uth

ori

ty

Yes

NoGVPA prepares the

Project Design and


and sends it to BDO

for his approval

Reject Particular

Application

Receives Job Card

Particular records

gets updated

CDO is updated



Details checked

Checks the

details in the

DataBase






and looks for

particular request

Details get updated


of funds in the e-


BDO approves the

Project Design and


the plan

Particular records

gets updated

Applicant has

Job Card?

The citizen can find out

from the e-District

application, whether work

is allocated against his job

card


of applicant who


card



The eDistrict


the application and

issue a receipt

MIS

Component 1

MIS

Component 2

MIS

Component 2

427


NREGP Process

1

Form availability, application receipt component are pre-

defined process. The output of the pre-defined process is

the input of e-district application


2 Citizen having JOB CARD can also be able to request for a

work through the CSC CSC

3 If the citizen does not have the Job Card then he will

request to the Gram Panchayat Citizen

4

Job card is issuance shall be approved by the Gram

panchayat; GPVA will enter the job card details in the e-

District application.

GPVA

5

Once the applications is filled in the e-District application,

the e-District application will generate the UIN and saves

the digital copy of the job card which can be printed from

the csc by the citizen and also checks for the available

work as per the qualification criteria.


6

Simultaneously, the details of the entire Job card can be

viewed by the DM, CDO, BDO, DRDA Office, Gram Pradhan,

and Gram Panchayat Adhikari.


7

On receiving of the notification by the e-district

application that the job card has been entered into the

system and which needs to be allocated a work, the GPVA

chooses from the work made available by the application

and assigns to the citizen.

GPVA

8

Once the work is issued by the GPVA, a list of all the

issued work is updated at the e- district application for

the citizen to verify available at the CSC.


9 Upon receiving of the work, citizen accepts the work and

gives his approval in the system through the GPVA login id. Citizen

10

Upon receiving the acceptance the GPVA will prepare the

estimate and the drawing for the work and enters in the

application.

GPVA

11 BDO after verifying the attached document and the work

gives his financial approval through the application. BDO

12 Citizen will start working after the financial approval

which will be entered in the application e-district application

13 Application will start counting the day of work and the day

assigned to work for completing the work. e-district application

428

14 Once the work is finished GPVA submits the utilization

certificate into the application. GPVA

15 Application will intimate the BDO for releasing the fund

and also shows the amount to be paid to the citizen. e-district application

16 BDO will release the fund through the application which

will be transferred into the Gram Panchyat account. BDO

17

Gram panchayat with the help of GPVA take the printout

of the wages of the workers for their Panchayat generated

by the system and accordingly pay to the citizen.

GPVA/ Gram Panchayat

18 GPVA will verify the payment in the system and also takes

scannes and attached the payment receipt in the system. GPVA

19

If application does not found any work then application

will sends this particular job request to the GPVA and BDO

login id for further process.


20

Upon receiving such request GPVA shall take decision on

the request along with the Gram Panchayat and sends a

report to the BDO

GPVA / Gram Panchayat

21 BDO will approve the report and enters in the application. BDO

429


8.

The citizen would be able to know the status of details of

the Job Card through SMS, Online and CSC/e-Suvidha

centre. The fields required in showing the status of

registered application are shown in table. Please refer to

the section 5 below ( Database fields available for the

citizen)


9.

Upon issuance of Job card and the work to the citizen, he

would receive communication of through SMS. The fields

required in showing the status of approved/rejection

application are shown in table. Please refer to the section

5 below (Database fields available for the citizen)


10.

The applicant would check the final status through Online

or visiting to CSC/e-Suvidha centre. Through SMS the

citizen would get the final status. The fields required in

showing the final status to the applicant are shown in

table. Please refer to the section 5 below (Database fields

available for the citizen)


11.

Any upper authority can also be able to check the status

of an individual application through their login id

(Database fields available for the Officials).


12. Citizen will be able to register his complaint or grievances

through the CSC or GPVA CSC / GPVA


NREGP Monitoring

1 The monitoring component <MIS 1> relates to monitor the

processing of JOB CARD. MIS Component 1

2



No of JOB CARD issued by which Panchayat.

Action taken by the Gram Vikas Adhikari

MIS Component 1

3 <MIS 1> component will auto generate weekly report for MIS Component 1

430

the DM, the ADM , CDO, BDO and Gram Vikas Adhikari

also provides the following information –

Total number of JOB CARD issued by date,

Panchayat wise.

Total number of JOB CARD to be allocated

work wise.

Total number of along with the stated reasons

for rejection

4 The monitoring component <MIS 2> relates to monitor the

successful completing the overall activity MIS Component 2

5



All details as described in process details has

been updated by the GRAM VIKAS ADHIKARI

Confirmation of information for ready delivery

of the JOB CARD and the Work

MIS Component 2

6

<MIS 2> component will auto generate weekly report and

provide the following information –

Total number of JOB CARD successfully

processed and Allocated work for which final

information has been updated by the GRAM

VIKAS ADHIKARI.

Total number of application for which work

allocation is delayed by the GPVA beyond the

defined service level

MIS Component 2

Database required


1

NREGP Database

This database will contain details of a citizen like Name, job card number, unique identification number of the job card, Age, Address and work assigned.

2 It should also contain details regarding the work sanctioned for the concerned district by the government, the status of the wages payment and the allocated work status.

431

3 The database will also maintain record of all Forms and the scanned documents attached with the work assigned.

4 It should also calculate the wages as per the qualification criteria and the allocated work.

5 It should be able to escalate the application if not disposed on the time and after the assigned timeline should ask for explanation from the concerned official.

6 System shall take the acceptance of work from the citizen

Service Request Form – NREGP

The format of job card request form would comprise of following fields:



2 Father‟s Name

3 Applicant Age

4 Address

5 Applicant‟s Qualification

6 Village Name

7 Tehsil Name

8 Panchayat Name/ Code


GVPA/ BDO/ CDO record view



2 Name of Applicant

3 Tehsil Name

4 Panchayat Code

5 Panchayat Name

432

6 Job Card No

7 Applicant Age


9 Work Allocated

10 Wages per day

11 Total Days of work assigned

12 Total days worked

13 Total Amount allocated for work

14 Work Status

15 Wages Paid

16 Balance Amount to be paid

The fields required in delegating of service request for issuance of job card (to the

citizen) to BDO under MIS component 1 are as follows:




2 Name of Applicant

3 Tehsil Name

4 Panchayat Code

5 Panchayat Name

6 Job Card No

7 Applicant Age


The fields required for updating the application, when the payment has been made to

the applicant by BDO under MIS component 2 are as follows:




2 Name of Applicant

3 Tehsil Name

4 Panchayat Code

5 Panchayat Name

6 Job Card No

433

7 Applicant Age


9 Work Allocated

10 Wages per day

11 Total Days of work assigned

12 Total days worked

13 Total Amount allocated for work

14 Work Status

15 Wages Paid

16 Balance Amount to be paid




1 Serial Number

2 Tehsil Name

3 Name of the panchayat

4 Gram Vikas Adhikari Name

5 Gram panchayt code

6 Job Card Number

7 Unique identification number

8 Job Card holder name

9 Age

10 Father‟s Name

11 Address

12 Qualification

13 Work allocated

14 Wages per day

15 Total day of work assigned

16 Working day

17 Total amount allocated for the work

18 Work status

19 Wages paid

20 Wages balance

21 Remarks

22 Documents attached with the work

23 Citizen acceptance for the assigned work

434

Monitoring Report


generated for the GVPA/ BDO/CDO/ DRDA

S.No Number of Job Card Applications received by GVPA

Number of Job Card issued/rejected by GVPA

Number of Job Card delivered to the citizen.

Work Allocated against the no of job card issued by GVPA

8.

9.


generated for the GVPA/ BDO/ CDO/DRDA

S.No Total number of work allocated

Total number of wages paid per day

Total number of days of assigned work

Total number of working days

Total amount disbursed for the work against issued job card

Number of application for work allocated delayed by GVPA beyond service level

5.

6.

Internal Service Level – NREGP S. No. Activities Time Required Service Level

( from date of service request)

1. Entry of Job card details in the e-District Application by GPVA.

1 Day 0th day

2. GPVA digitally signs the Job Card and allocates the work

1 Day 1st day

3. GRAM VIKAS ADHIKARI gives the work permission

1 Day 1st day

4 GPVA provides the drawing to the citizen.

1 Day 3rd Day

435

Auto Escalation Matrix - NREGP


Service Level

L1

L2

L3


1 CSC or GPVA enters all the JOB CARD details in the E-District Application and the application notifies the CDO, BDO and GPVA

CSC/GPVA

1st Day CSC Clerk, GPVA

3rd Day

GPVA 5th Day

2 After the notification by

the e-District application,

digitally signs the JOB

CARD and allocates the

work

GPVA 1st Day GPVA 3rd Day

GPVA 5th Day DM 7th Day

3 GRAM VIKAS ADHIKARI gives the work order to the concern citizen.

GRAM VIKAS

ADHIKARI

2nd Day GPVA 4th Day

GPVA 6th Day

4 GRAM VIKAS ADHIKARI updates the E-District Application about the status of the JOB CARD, that the work has been allocated or not.

GRAM VIKAS

ADHIKARI



S. No Designation officer Number of Digital Signature Used (In – Number)

1 DM One

2 ADM All

4 CDO One

5 BDO All

6 GRAM VIKAS ADHIKARI

All

Functional Requirement Specification – (NREGP)

Sr. Description

1. The system should be able to display JOB CARD related page through

multiple routes

Service links

Information links

District links




NREGP related services both in public as well as restricted domain as per

the „Information component‟



4. The system should provide all services under NREGP under a single category

5. The system should be able to use the different channels as well as handle

different works and citizen qualification criteria as per the process map

and relevant description for the service mentioned

6. The system should allow the operator –GPVA to fill in the online Job Card

application into the e-district application.



component.



9. The system should be able to route the JOB CARD details to concerned

officer at the following levels –

ADM

437

Sr. Description

CDO

BDO

GPVA

10. The system should be allowing DM to allocate service request to concerned

GPVA for processing certain pending Application for work.



12. The system should auto generate notification of work issued to the citizen.

The list should be auto generated and made available date wise.

13. The system should save the record details only on digital signature of the

GRAM VIKAS ADHIKARI.

14. The system should notify all the respective stakeholders mentioned – DM,

ADM, CDO, BDO and the GPVA about the status of final completion.

15. The system should show a successful submission screen on completion of

the work assigned and completion.






service levels are not met as defined in the service level description for the

process


20. The system should be able to maintain all records for the login sessions

with date and time



438

4.2 Public Distribution System

We are covering following 4 sub-services are as followes:

1. New Ration Card (APL\ BPL and Antodhya)

2. Modification in Ration Card

3. Duplicate Ration Card

4. Surrender of Ration Card

Select Perquisites for qualification for To-Be Process (Rural\

Urban)

The Department should accept the provision for acceptance of service request

throughout the year instead of application acceptance during a particular

period of year.

The Department should acceptance of service request for BPL ration card at

CSC prior to „Anumodan‟.

The Department should accept the provision of Common Service Centre / e


The Department should accept the provision of providing digital signature to

concerned DSO, ARO‟s, SI‟s, BDO‟s, DM and the Department Heads who would

be involved in processing of service request.

The Department should accept the provision of forwarding service request to

GVPA/SI and BDO/ARO simultaneously through e-District application without

being manually forwarded by BDO/ARO as a noting on service request file.

The Department should accept the GVPA forwarding digitally the beneficiary

List and the Anumodan details over the e District application to the BDO.

The Department should accept the provision for review and approval of

Anumodan by the BDO in the electronic form over the e district application.

The Department should accept the provision of Gram Sabha preparing waitlist

of beneficiaries after allocated quota of BPL\ Antodhya Ration Card is full for

the concerned village. This would allow auto selection of waitlisted candidates

in case of removal of any beneficiary from the current list.

439

The Department should accept the provision of SCA / Delivering agency

charging a convenience fees from either the citizen or department to make the

process self sustainable.



Preparation of Anumodan database based on the Anumodan passed during the

Khuli Baithak conducted by the Gram Sabha would help in proper monitoring

and maintenance of records as well as bring in transparency in the local

governance system.

Preparation of beneficiary waitlist in order of priority leading to auto selection

of waitlisted applicant in case of removal of any current beneficiary from the

pensioners list. The reasons for the removal of beneficiary from the current list

might be death, disqualification due to status upgradation, change of location

etc.

Improvement in service levels for service level as now the service request will

be accepted through out the year. Provision for creation of waitlist for

approved service request in case of no quota availability for the New BPL

Ration card request has been envisaged in the process

De-funneling of “routing” of service request in the proposed To Be Process as

service Request would be routed to all the concern authorities simultaneously

440

New Ration Card (Rural/ Urban) APL – Process Flow

New Ration Card (APL in Rural\ Urban) - Process Flow

GV

PA

(R

ura

l)

SI (U

rba

n)

GV

PA

(R

ura

l)

SI (U

rba

n)

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nB

DO

/ A

DO

(U

rba

n)

DS

O/ A

RO

(R

ura

l)

BD

O / A

DO

(U

rba

n)

DS

O/ A

RO

(R

ura

l)A

pp

lica

nt

Ap

plic

an

t

Applicant submits


receives a receipt


application and

issues a Receipt

Logs into the

system and

checks for

particular ration

card application No


verification of details to

GVPA\ SI

Physically Verifies the

applicant details

Details

Found?Checks the

details in the

DataBase

Updates the Database


details

Details checkedDatabase is

updated and

trigger generated

StartApplication

Receipt

Component

Form

Availability

Component

Application

Receipt

Component

YesDetails

Correct?



as per Rejection

Component

No

Applicant receives

the reason for

rejection

System saves the

rejection in a Database

and notifies the

applicant

Stop

Applicant receives

the Ration Card

Database is updated

about the date of New

Ration Card issued

Stop

Yes

Approves the application

online using digital sign as

per Approval Component



Issued New Ration Card

Delivery

Component

Database is

updated

441

New Ration Card (Rural/ Urban) APL – Status Tracking

New Ration Card (APL in Rural\ Urban) – Status Tracking

GV

PA

(R

ura

l)

SI (U

rba

n)

GV

PA

(R

ura

l)

SI (U

rba

n)

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nB

DO

/ A

DO

(U

rba

n)

DS

O/ A

RO

(R

ura

l)

BD

O / A

DO

(U

rba

n)

DS

O/ A

RO

(R

ura

l)A

pp

lica

nt

Ap

plic

an

t

Applicant submits


receives a receipt


application and

issues a Receipt

Logs into the

system and

checks for

particular ration

card application No



GVPA\ SI


applicant details

Details

Found?Checks the

details in the

DataBase



details


updated and

trigger generated

YesDetails

Correct?



as per Rejection

Component

No

System saves the


and notifies the

applicant

Database is updated


Ration Card issued

Yes







Status

Tracking

Component

Database is

updated

Status

Tracking

Component Status

Tracking

Component

Status

Tracking

Component

442

New Ration Card (Rural/ Urban) APL – Monitoring

New Ration Card (APL in Rural\ Urban) – Monitoring

GV

PA

(R

ura

l)

SI (U

rba

n)

GV

PA

(R

ura

l)

SI (U

rba

n)

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nB

DO

/ A

DO

(U

rba

n)

DS

O/ A

RO

(R

ura

l)

BD

O / A

DO

(U

rba

n)

DS

O/ A

RO

(R

ura

l)A

pp

lica

nt

Ap

plic

an

t

Applicant submits


receives a receipt


application and

issues a Receipt

Logs into the

system and

checks for

particular ration

card application No



GVPA\ SI


applicant details

Details

Found?Checks the

details in the

DataBase



details


updated and

trigger generated

YesDetails

Correct?



as per Rejection

Component

No

System saves the


and notifies the

applicant

Database is updated


Ration Card issued

Yes







MIS

Database is

updated

MIS

MISMIS

443


Ration Card Process-APL

1.





2.

Once the system registers a new application a notification

will go to the BDO/ADO/DSO/ARO/SI who will log onto the

e-District application and check for the details of request

of new Ration card for APL.


3. If details are found and correct then mark the application

to SI/ GVPA for issuance of New Ration card.

BDO/ADO (Rural)

DSO/ARO(Urban)

4. If the details are not found in the database then marks to

SI/GVPA for physical verification.

BDO/ADO (Rural)

DSO/ARO(Urban)

5. After physical verification updates the detail in eDistrict

application. SI/GVPA

6. Then the database is updated and a trigger is generated

for the BDO/ARO for final approval. e-district application

7.

Checks the verification report, if found correct then

approves the application using digital signature and marks

to SI/ GVPA for issuance of New Ration Card.

BDO/ADO (Rural)

DSO/ARO(Urban)

8.

After receiving the hardcopy of application, New Ration

Card will be issued to the citizen and update the date of

Ration Card issued.

SI/ GVPA

9. If application rejected then give the resion for rejection BDO/ADO (Rural)

DSO/ARO(Urban)

10. The e-district application is updated the detail of New

Ration card issued or Reject. e-district application

Ration Card Status Tracking-APL

1.

The citizen would be able to know the status of their

application after the submission of application at CSC/e-

Suvidha centre.


2.

Citizen will get the status of his application whether its

been approved/rejected after final verification, he would

receive communication through SMS. The fields required in

showing the status of approval/rejection application are

shown in table.


3. The applicant would also get the status through Online or

visiting to CSC/e-Suvidha centre or through SMS that his e-district application

444

New Ration Card has been prepared and he can collect

from the respective office.

Records view for a Logged in user- New Ration card APL (Urban/ rural)


DSO/ ARO/ SI/ BDO/ ADO/ GVPA record view


1 Service Request for: New Ration Card- APL (Urban/Rural)

2 Registration No.

3 Name of City\ Village:

4 Name of Block:

5 Name of District:

6 Name of the Karta of the Family:

7 S/0, W/0, D/0:

8 Address (House No, Place and Ward No):

9 Name of his Family members

10 Age of each member of the family

11 Relation with Karta of the family

12 Monthly income of Karta

13 Occupation

14 Electricity Connection: (Yes or No)

15 Cooking Gas Connection: (Yes or No)

16 Residing Period of above Address:

17 Receipt of house tax if own a house or Electricity bill:

18 Surrender Certificate if migrated:

19 Others:c(list of Attachments)

20 Applicant Signature

445

Monitoring Report- New Ration Card APL (Urban/ Rural)

The following table specifies the fields required in the MIS Report (MIS component) generated for the DSO/BDO/ADO/GVPA

(Rural)

S.No

Name of Block

Application Registration No.

BDO Name

Ration Card Number

Name of Owner

Name of Village

Date of App. Received

Application Accepted/ Rejected (Y/N)

Date of Accepted/ Rejected

Date of New Ration card(APL) Issued

Resion for Rejection

1

2

The following table specifies the fields required in the MIS Report (MIS component) generated for the DSO/ARO/SI (Urbal)

S.No

Name of city sub area


ARO/ SI Name

Ration Card Number

Name of Owner

Address Date of App. Received



Date of New Ration card (APL)s Issued


1

2

446

The following table specifies the fields required in the MIS Report (MIS component) generated for the DSO/ARO/SI/ BDO/ ADO/

GVPA (Urban/ Rural)

Master Register:

S.No City Sub Area

District House Number

Address Ration Card Number

Unit Total No. of Unit (Adult + Minor)

Ration Shop No.

Adult Minor

1.

2.

Shop Register:

S.No Master Register No.

Applicant Name Father/ Guardian Name



Others

Adult Minor

1.

2.

447

Service Level – New Ration Card APL (Urban / Rural)

SNo. Activities Time required Service Level ( from date of service request)

1. Submission of Application 1 Day 1st day

2. Issuance of order to SI/GVPA to conduct

inquiry

1 Day 2nd day

4 Field verification report updating by SI/GVPA

7 Day 09th Day

5 Decision making on field verification report by ARO/BDO

1 Day 10th Day

6 Issuance of New Ration Card 2 Day 12th Day

Auto Escalation Matrix - APL (Urban / Rural)

S.No

Activity Activity Owner

Service Level

L1

L2

L3


1 Issuance of order to SI/GVPA to conduct inquiry

ARO/BDO 1 Day DSO 2 Day DM 2 Day


SI/GVPA 7 Day ARO/BDO 2 Day DSO 1 Day DM 1 Day

3 Decision making on field verification report by SI/ GVPA


4 Prepare and Issuance of New Ration Card

SI/GVPA 2 Day ARO/BDO 1 Day DSO 1 Day

448

New Ration Card BPL & Antyodya (Urban)– Process Flow

New Ration Card (BPL & Anthodya in Urban) - Process

SISI

DS

O / A

RO

DS

O / A

RO

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nA

pp

lica

nt

Ap

plic

an

t

No

Yes

No

Logs into the

system and

checks for

particular ration

card application

Is Quota

Available?


application and

issues a Receipt

Applicant receives

the Ration Card

Checks the

details in the

BPL DataBase

Applicant submits


receives a receipt

Applicant receives

the reason for

rejection

Details

Found?

Application entered

in queue in the

waiting list databse

Details checked

Check citizen has

any Ration Card

issued to him?

No

Yes

Database is

updated

Database is

updated

On receiving of Hard

copy, updates the

database and issue a

New Ration Card

Start Application

Receipt

Comp.

Application

Submission

Comp.

Delivery

Component

Stop

Rejects the application online

using digital sign as per

Rejection Component




Stop

Yes

Waiting

database is

updated

449

Process of Quota

BPL & Antyoday – Quota

De

pt. H

ea

d

E D

istr

ict A

pp

lica

tio

n

Dis

tric

t M

ag

istr

ate

S

tate

Go

ve

rnm

en

t

Yes

No

Quota

Updates proposed

allocated figures

over the application



quota



concerned officials

Approval? Receives and

reviews notification




application




Dept Head

Work on DMs orders




database



notifies DM

Receives district

wise figures

along with

guidelines

Hosts district wise

allocated quota and auto

generates email notifying

allocated quota to Dept.

Head

Updates Application

Database

Fixes BPL and Antodhya

for particular district,

forwards this figure to DM

along with guidelines


from the application

Allocates overall Quota

on a block wise (Rural)

and ward wise –

Municipality wise

(Urban) basis

450

New Ration Card BPL & Antyodya (Urban)– Status Tracking

New Ration Card (BPL & Anthodya in Urban) – Status Tracking

SISI

DS

O / A

RO

DS

O / A

RO

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nA

pp

lica

nt

Ap

plic

an

t

No

Yes

No

No

Yes

Yes Approves the application



Applicant submits


receives a receipt


copy, updates the


New Ration Card

Waiting

database is

updated

Is Quota

Available?Rejects the application online


Rejection Component

Database is

updated


application and

issues a Receipt

Application entered

in queue in the

waiting list databseChecks the

details in the

BPL DataBase

Check citizen has

any Ration Card

issued to him?

Details checked

Logs into the

system and

checks for

particular ration

card application

Database is

updated

Status

Tracking

Component

Details

Found?

Status

Tracking

Component

Status

Tracking

Component

Status

Tracking

Component

451

New Ration Card BPL & Antyodya (Urban)– Monitoring

New Ration Card (BPL & Anthodya in Urban) – Monitoring

SISI

DS

O / A

RO

DS

O / A

RO

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nA

pp

lica

nt

Ap

plic

an

t

No

Yes

No

No

Yes

Yes Approves the application



Database is

updated

Details

Found?

Waiting

database is

updated

MIS

Logs into the

system and

checks for

particular ration

card application

Applicant submits


receives a receipt

Details checked

Check citizen has

any Ration Card

issued to him?

MIS

Application entered

in queue in the

waiting list databse

MIS


copy, updates the


New Ration Card


application and

issues a Receipt

Checks the

details in the

BPL DataBase

Database is

updated

Is Quota

Available?Rejects the application online


Rejection Component

MIS

452


Ration Card Process- BPL & Anthodya in Urban Area

1.





2.


will go to the DSO/ARO/SI who will log onto the e-District

application and check for the details of request of new

Ration card for BPL.


3. Details are checked whether he has any Ration Card issued

earlier or not, if found yes , Application rejected. DSO/ARO

4. If the details are not found in the database then checked

in BPL Database. DSO/ARO

5. If no Details found in BPL Database , application rejected. DSO/ARO

6. IF details found in BPL Database then checked for the

quota whether it is available or not. DSO/ARO

7. IF Quota is available then marks the application to SI for

issuance the new BPL/Antyodya Ration Card. DSO/ARO

8. If quota is not available then application will issue a

waitlist number. e-district application

9.

After receiving the hardcopy of application, New

BPL/Antyodya Ration Card will be issued to the citizen

and update the date of Ration Card issued.

SI

10. If application rejected then give the reason for rejection DSO/ARO

11. The e-district application is updated the detail of New

Ration card issued or Reject. e-district application

Ration Card Status Tracking-BPL/Anyodya

1.



Suvidha centre.


2.


been approved/rejected after verification, he would



shown in table.


3. Citizen will get the status of application if his application

has been kept in waiting list. e-district application

453

4.

The applicant would also get the status through Online or

visiting to CSC/e-Suvidha centre or through SMS that his




Records view for a Logged in user- New Ration card BPL & Antyodya (Urban)


DSO/ ARO/ SI record view


1 Service Request for: New Ration Card- BPL\ Antyodya (Urban)

2 Registration No.


4 Name of Block:

5 Name of District:


7 S/0, W/0, D/0:






13 Occupation








454

Monitoring Report- New Ration Card BPL & Antyodya (Urban)

The following table specifies the fields required in the MIS Report (MIS component) generated for the DSO/ARO/SI (Urbal)

S.No



ARO/ SI Name

Ration Card Number

Name of Owner




Date of New Ration card (BPL/ Antyodya) Issued


1

2

The following table specifies the fields required in the MIS Report (MIS component) generated for the DSO/ARO/SI(Urban)

Master Register:

S.No City Sub Area




Ration Shop No.

Adult Minor

1.

2.

Shop Register:





Others

Adult Minor

1.

2.

455

Service Level – New Ration Card BPL (Urban)

SNo. Activities Time required Service Level ( from date of service request)


2 Decision making ration card issued or not 2 Day 3th Day


Auto Escalation Matrix – New Ration Card BPL (Urban)

S.No


Service Level

L1

L2

L3


1 Decision on the application accept or reject for Issuance of Ration card

ARO 2 Day DSO 2 Day DM 2 Day


SI 2 Day ARO 2 Day DSO 2 Day DM 2 Day

456

New Ration Card (BPL & Antyodaya) in Rural - Process

New Ration Card (BPL & Antyodya in Rural) - Process

GVPA

GVPA

BDO/

ADO

BDO/

ADO

E-Di

strict

Appli

catio

n

E-Di

strict

Appli

catio

nAp

plica

ntAp

plica

nt

No

Yes

StartStop Stop

Database is

updated

Applicant receives

the reason for

rejection

Check citizen has

any Ration Card

issued to him?

Database is

updated




Applicant receives

the Ration Card

Logs into the

system and

checks for

particular ration

card application

Delivery

Component

Application

Submission

Comp.

Application

Receipt

Comp.


the BPL and

Anumodan DataBase


copy, updates the


New Ration Card

Details checked

Applicant submits


receives a receipt


application and

issues a Receipt

Details

Found?



as per Rejection

Component

Yes

No

Send for

AnumodanQuota Check Yes

No

Waitlist Database

457

Process Flow of Anumodan Database

Parallel Process – For New Application Received in Khuli Baithak and Update Anumodan Database in Rural Areas

BD

OB

DO

E-D

istr

ict

Ap

plic

atio

nG

VP

AG

ram

Sa

bh

a

Ap

plic

an

t

No

Yes

Fills physical forms on

behalf of applicant and

hands over the ack.

Receipt to applicant

Stop

Adds name to

anumodan and

beneficiary list

(Current / waiting)

Registers new applicants

details, update Anumodan

List and issues receipt for

new application registered

Updates details for the new applicants details,

Anumodan list and update the reason for

rejection for those applications which come

from BDO office

Approves

application

Start

Discusses on application

received in khuli baithak

and list provided by BDO

office

Submits BPL and

Antyoday application

request in khuli baithak

Case

Discussion

Receives

Rejection

Rejects

Application

Hands over the new

applications to the GVPA

whose names have been

added

Issues ack. Receipt to

the new registered

applicant.Stop

Trigger generated

to BDO for Final

approval of

Anumodan List

Approval?

No

Update the

reason for

rejection

Yes

Update the Anumodan

list into Anumodan

Database

Received from

New Ration

Card (BPL &

Antyodaya )

Rural Process

Flow Rejected applicant will be

added for next Khuli

Baithak

458

New Ration Card (BPL & Antyodaya in Rural)-Status Tracking

New Ration Card (BPL & Antyodya in Rural) – Status Tracking G

VPA

GVP

ABD

O/ A

DO

BDO

/ AD

OE-

Dis

trict

Appl

icat

ion

E-D

istri

ct

Appl

icat

ion

Appl

ican

tAp

plic

ant

No

Yes

Database is

updated

Check citizen has

any Ration Card

issued to him?

Database is

updated




Logs into the

system and

checks for

particular ration

card application

Status

Tracking

Status

Tracking


the BPL and

Anumodan DataBase


copy, updates the


New Ration Card

Details checked

Applicant submits


receives a receipt


application and

issues a Receipt

Details

Found?



as per Rejection

Component

Yes

No

Send for

AnumodanQuota Check

Waitlist

Database is

updated

Status Trackin. Status Trackin. Status

Tracking

Yes

No

459

New Ration Card BPL & Antyodya (Rural)– Monitoring

New Ration Card (BPL & Antyodya in Rural) – Monitoring

GVP

AG

VPA

BDO

/ AD

OBD

O/ A

DO

E-D

istri

ct

Appl

icat

ion

E-D

istri

ct

Appl

icat

ion

Appl

ican

tAp

plic

ant

No

Yes

Database is

updated

Check citizen has

any Ration Card

issued to him?

Database is

updated




Logs into the

system and

checks for

particular ration

card application

MIS

MIS


the BPL and

Anumodan DataBase


copy, updates the


New Ration Card

Details checked

Applicant submits


receives a receipt


application and

issues a Receipt

Details

Found?



as per Rejection

Component

Yes

No

Send for

AnumodanQuota Check

No

Waitlist

Database is

updated

MISMISMIS

Yes

460


Ration Card Process- BPL & Anthodya in Rural Area

1.





2.


will go to the BDO/ ADO who will log onto the e-District

application and check for the details of request of new

Ration card for BPL or Anthodya.


3. Details are checked whether he has any Ration Card issued

earlier or not, if found yes, Application rejected. BDO/ ADO

4. If the details are not found in the database then checked

in BPL Database and Anumodan Database. BDO/ ADO

5. If no Details found in BPL Database, application will be

send for anumodan. BDO/ ADO

6. IF details found in BPL and Anumodan Database then

application will be approved and marked to GVPA. BDO/ ADO

7.

After receiving the hardcopy of application, New

BPL/Antyodya Ration Card will be issued to the citizen

and update the date of Ration Card issued details.

GVPA

8. Those who were send for anumodan, after anumodan

quota will be checked. BDO/ADO

9. If quota is available then the application will be forwarded

to GVPA BDO/ADO

10. If quota is not available then the applicant will be added BDO/ ADO

461

in waitlist database.

11. The e-district application is updated for the waitlist and

the detail of New Ration card issued or Reject. e-district application

Ration Card Status Tracking-BPL/Anyodya

1.



Suvidha centre.


2.


been approved/rejected after verification, he would



shown in table.


3. Citizen will get the status of application if his application

has been kept in waiting list. e-district application

4.

The applicant would also get the status through Online or

visiting to CSC/e-Suvidha centre or through SMS that his




462

Records view for a Logged in user- New Ration card BPL & Antyodya (Rural)


DSO/ BDO/ ADO/ GVPA record view


1 Service Request for: New Ration Card- BPL\ Antyodya (Rural)

2 Registration No.


4 Name of Block:

5 Name of District:


7 S/0, W/0, D/0:






13 Occupation








463

Monitoring Report- New Ration Card BPL & Antyodya (Rural)

The following table specifies the fields required in the MIS Report (MIS component) generated for the DSO/BDO/GVPA (Rural)

S.No

Name of Block


BDO Name

Ration Card Number

Name of Owner

Name of Village




Type of ration card Issued (BPL/ Antodhya)

Date of New Ration card Issued


1

2

The following table specifies the fields required in the MIS Report (MIS component) generated for the DSO/BDO/GVPA(Rural)

Master Register:

S.No City Sub Area




Ration Shop No.

Adult Minor

1.

2.

Shop Register:





Others

Adult Minor

1.

2.

464

Service Level – New Ration Card BPL (Rural)

SNo. Activities Time required Service Level ( from date of

service request)


2 Decision making ration card issued or not

2 Day 3th Day


Auto Escalation Matrix – New Ration Card BPL (Rural)

S.No


Service Level

L1

L2

L3


1 Decision on the application accept or reject for Issuance of Ration card

BDO 2 Day DSO 2 Day DM 2 Day


GVPA 2 Day BDO 2 Day DSO 2 Day DM 2 Day

465

Modification of Ration Card (Rural/ Urban) – Process

Modification of Ration Card (Rural\ Urban) – Process Flow

GV

PA

(R

ura

l)

SI (U

rba

n)

GV

PA

(R

ura

l)

SI (U

rba

n)

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

n

BD

O/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

BD

O/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

Ap

plic

an

tA

pp

lica

nt

Applicant submits


receives a receipt


application and

issues a Receipt

Logs into the

system and

checks for

particular ration

card application



GVPA\ SI


applicant details

On receiving the hard copy

of the application, Issued

Modified Ration Card and

Surrender Certificate(if

required)

Details

Found?

Checks the

details in the

DataBase

Yes

Applicant receives

the modified

Ration Card



modified details

Database is updated

about physically

verification details

Details checked

Database is updated about

Date of Modified Ration

Card and Surrender

Certificate issued

Yes

No

Stop

Delivery

Component

Database is updated

about the modified

details

Details

Correct?






per Rejection Component

No

Applicant receives

the reason for

rejection

System saves the



StopStart

Application

Receipt

Comp.

Payment

Component

Form

Availability

Component

Issues the surrender

certificates to the member in

case he/she married/ split

466

Modification of Ration Card (Rural/ Urban) – Status Tracking

Modification of Ration Card (Rural\ Urban) – Status Tracking

GV

PA

(R

ura

l)

SI (U

rba

n)

GV

PA

(R

ura

l)

SI (U

rba

n)

BD

O/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

BD

O/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

n

Ap

plic

an

tA

pp

lica

nt

Yes

Yes

No

No




Details checked

Details

Found?



GVPA\ SI





applicant details

Database is updated

about the modified

details




Database is updated

about physically


Applicant submits


receives a receipt

Details

Correct?

Checks the

details in the

DataBase

System saves the



Logs into the

system and

checks for

particular ration

card application


application and

issues a Receipt



modified details



Card and Surrender

Certificate issued





required)

Status

Tracking

Component

Status

Tracking

Component

Status

Tracking

Component

467

Modification of Ration Card (Rural/ Urban) – MIS

Modification of Ration Card (Rural\ Urban) – Monitoring

GV

PA

(R

ura

l)

SI (U

rba

n)

GV

PA

(R

ura

l)

SI (U

rba

n)

BD

O/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

BD

O/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

n

Ap

plic

an

tA

pp

lica

nt

Yes

Yes

No

No








required)

MIS

System saves the





Card and Surrender

Certificate issued

MIS




MIS

Database is updated

about physically


Checks the

details in the

DataBaseDetails

Correct?

Applicant submits


receives a receipt



modified details


application and

issues a Receipt

Details

Found?

Logs into the

system and

checks for

particular ration

card application



GVPA\ SI


applicant details

Database is updated

about the modified

details

Details checked




468


Modification Ration Card Process

1

Form availability, application receipt and

payment receipt component are pre-defined

process. Once the system registers a new

application, a notification will go to the

BDO/ADO/ DSO/ARO. The output of the pre-

defined process is the input of e-district

application


2

BDO/ADO DSO/ARO will log onto the e-District

application and check for the details of the

Request for Modification in Ration card.

BDO/ADO (Rural)

DSO/ARO(Urban)

3 If details are found, marks the application to

GVPA/ SI for modification in Ration Card.

BDO/ADO (Rural)

DSO/ARO(Urban)

4

If the details are not found in the database then

marks the application to GVPA/SI for physical

verification

BDO/ADO (Rural)

DSO/ARO(Urban)

5 After physical verification, the details are

updated in the database . SI/GVPA

6

Then the database is updated and a trigger is

generated for the BDO/ADO/ARO/DSO for final

approval of modification done by SI/GVPA.


7 After physical verification application approved

or rejected for modification in ration card.

BDO/ADO (Rural)

DSO/ARO(Urban)

8

If approved then marks to GVPA/SI to issue the

modified Ration Card and accordingly if

required issue a surrender certificate.

BDO/ADO (Rural)

DSO/ARO(Urban)

9

After receiving the hardcopy of application,

modified Ration Card will be issued to the

citizen and update the date of modified ration

card issued.

GVPA/SI

Modified Ration Card Status Tracking

1

The citizen would be able to know the status of

their application after the submission of

application at CSC/e-Suvidha centre.

e-district

application

2

Citizen will get the status of his application

whether its been approved/rejected after final

verification, he would receive communication

through SMS. The fields required in showing the

e-district

application

469

Records view for a Logged in user (Modification of Ration Card)


DSO/ ARO/ SI/ BDO/ ADO/ GVPA record view


1 Service Request for: Modification(Urban/Rural)

2 Registration No.

3 Ration Card No.


5 Name of Block:

6 Name of District:


8 S/0, W/0, D/0:






14 Occupation





status of approval/rejection application are

shown in table.

3

The applicant would also get the status through

Online or visiting to CSC/e-Suvidha centre or

through SMS that his modified Ration Card has

been prepared and he can collect from the

respective office.

e-district

application

470

Monitoring Report (Modification of Ration Card)


(Rural)

S.No

Name of Block

BDO Name

Ration Card Number

Name of Owner

Name of Village




Date of Modified Ration card Issued


1

2


(Rural)

S.No

Name of Block

Ration Card Number

Name of Owner

Name of Village

Ration Shop No.

Present Unit After Modification

Total No. of Unit (Adult + Minor)

Total No. of Surrender Certificate issued

Remarks

Adult Minor Adult Minor

1 Adult Minor

2

471


S.No


ARO/ SI Name

Ration Card Number

Name of Owner




Date of Modified Ration card Issued


1

2


S.No


Ration Card Number

Name of Owner

Address Ration Shop No.

Present Unit After Modification

Total No. of Unit (Adult + Minor)


Remarks

Adult Minor Adult Minor

1 Adult Minor

2

472

Service Level – Modification (Urban / Rural)

S No. Activities Time required Service Level ( from date of service

request)


2. Issuance of order to

GVPA/SI for conducting

physical verification

1 Day 2nd day

3. Updating record by SI/GVPA

7Day 9th day

4 Final Approval by BDO/DSO/ADO/ARO

1 Day 10th Day

5 GVPA/SI issues the Ration Card on receiving the Hardcopy

2 Day 12th Day

Auto Escalation Matrix (Modification of Ration Card)

S. No


Service Level

L1

L2

L3

Name

Time Name

Time Name Time

1 Issuance of order to SI/GVPA to conduct inquiry

ARO/ BDO

1 Day DSO 2 Day DM 2 Day


SI/GVPA 7 Day ARO/BDO


3 Decision making on field verification report.


4 Approval on making of Modified Ration Card

ARO/BDO 1 Day DSO 2 Day DM 2 Days

5 Making of modified Ration Card after receiving hard copy

GVPA/SI 2 Days ARO/BDO

2 Day DSO 1 Day

473

Duplicate Ration Card (Rural/ Urban) - Process Duplicate Ration Card (Rural\ Urban) - Process Flows

GV

PA

(R

ura

l)

SI (U

rba

n)

GV

PA

(R

ura

l)

SI (U

rba

n)

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nB

DO

/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

BD

O / A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

Ap

plic

an

tA

pp

lica

nt

Applicant submits


receives a receipt


and checks for

particular ration card

application

No



GVPA\ SI


applicant details

Details

Found?

Checks the

details in the

DataBase

Yes


and a trigger is generated

about the updation for

final approval

He entries the applicant

details in the Database

System registers

the application

and issues a

Receipt

Details checked

No

Start

Form

Availability

Component

Application

Receipt

Comp. Stop

Payment

Component

Details

Correct?



as per Rejection

Component

Applicant receives

the reason for

rejection

System saves the



Stop

Yes

Applicant receives

the duplicate Ration

Card

Database is updated

about the date of


issued



as per Approval

Component



Issued Duplicate Ration

Card

Database is

updated

474

Duplicate Ration Card (Rural/ Urban) – Status Tracking

Duplicate Ration Card (Rural\ Urban) – Status Tracking

GV

PA

(R

ura

l)

SI (U

rba

n)

GV

PA

(R

ura

l)

SI (U

rba

n)

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nB

DO

/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

BD

O / A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

Ap

plic

an

tA

pp

lica

nt

Applicant submits


receives a receipt


and checks for


application

No



GVPA\ SI


applicant details

Details

Found?

Checks the

details in the

DataBase

Yes




final approval



System registers

the application

and issues a

Receipt

Details checked

NoDetails

Correct?



as per Rejection

Component

System saves the



Yes

Database is updated

about the date of


issued



as per Approval

Component




Card

Database is

updated

Status

Tracking Status

Tracking

Status

Tracking

Status

Tracking

475

Duplicate Ration Card (Rural/ Urban) – MIS

Duplicate Ration Card (Rural\ Urban) – Monitoring

GV

PA

(R

ura

l)

SI (U

rba

n)

GV

PA

(R

ura

l)

SI (U

rba

n)

E-D

istr

ict

Ap

plic

atio

n

E-D

istr

ict

Ap

plic

atio

nB

DO

/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

BD

O / A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

Ap

plic

an

tA

pp

lica

nt

Applicant submits


receives a receipt


and checks for


application

No



GVPA\ SI


applicant details

Details

Found?

Checks the

details in the

DataBase

Yes




final approval



System registers

the application

and issues a

Receipt

Details checked

NoDetails

Correct?



as per Rejection

Component

System saves the



Yes

Database is updated

about the date of


issued



as per Approval

Component




Card

Database is

updated

MISMIS MIS MIS

476


Duplicate Ration Card – Process

1


receipt component are pre-defined process. Once the

system registers a new application, a notification will

go to the BDO/ ADO/ DSO/ ARO.The output of the

pre-defined process is the input of e-district

application


2 log onto the e-District application and check for the

details of the Duplicate Ration card request.

BDO/ADO (Rural)

DSO/ARO(Urban)

3

If the details are matched or found in the Database,

then the details are updated in the application, for

issuance of duplicate Ration Card to the applicant.

BDO/ADO (Rural)

DSO/ARO(Urban)

4

If details are found, the application approves and

marks the application to GVPA/SI for issuance of

Duplicate Ration card.

BDO/ADO (Rural)

DSO/ARO(Urban)

5 On receiving of physical hard copy of the application

form issues the duplicate Ration Card to the citizen. GVPA(Rural)/SI(Urban)

6 If the details are not found in the database marks the

application to GVPA/SI for physical verification

BDO/ADO (Rural)

DSO/ARO(Urban)

7 After physical verification, the details are updated in

the database. GVPA(Rural)/SI(Urban)

8

Then the database is updated and a trigger is

generated for the BDO/ADO/ARO/DSO for final

approval of issuance of duplicate ration card done by

SI/GVPA.


9 Database is finally approved / rejected and updated

accordingly.

BDO/ADO (Rural)

DSO/ARO(Urban)

10

If approved then GVPA/SI will get a system generated

trigger for respective applications to issue the

duplicate Ration Card.


11 After receiving the hardcopy of application, duplicate

Ration Card will be issued. GVPA(Rural)/SI(Urban)

12 If application reject then mentioned the reason for

rejection in eDistrict application

BDO/ADO (Rural)

DSO/ARO(Urban)

Duplicate Ration Card - Status Tracking

1 The citizen would be able to know the status of their e-district application

477

application after the submission of application at

CSC/e-Suvidha centre.

2

Citizen will get the status of his application whether

its been approved/rejected after final verification by

BDO/DSO/ARO/ADO and updation in database of the

application of the citizen, he would receive

communication through SMS. The fields required in

showing the status of approval/rejection application

are shown in table.


3

The applicant would also get the status through

Online or visiting to CSC/e-Suvidha centre or through

SMS that his duplicate Ration Card has been prepared

and he can collect from respective office.


478

Records view for a Logged in user (Duplicate Ration Card)


ARO/SI/BDO/GVPA record view


1 Service Request for: Duplicate(Urban/Rural)

2 Registration No.

3 Ration Card No.


5 Name of Block:

6 Name of District:


8 S/0, W/0, D/0:






14 Occupation





479

Monitoring Report (Duplicate Ration Card)

The following table specifies the fields required in the MIS Report (MIS component) generated for the DSO/ BDO/ ADO (Rural)

S.No

Name of Block

BDO Name

Ration Card Number

Name of Owner




Date of Duplicate Ration card Issued


1

2

The following table specifies the fields required in the MIS Report (MIS component) generated for the DSO/ ARO/ SI (Urban)

S.No

Name of City Sub Area

ARO/ SI Name

Ration Card Number

Name of Owner




Date of Duplicate Ration card Issued


1

2

480

Service Level – Duplicate Ration Card (Urban / Rural)

S No. Activities Time required Service Level ( from date of service request)

1. Submission of Application 1 Day 1st Day

2. Physical verification of the record by GVPA/SI

7 Day 8th Day

3. Approvel/ Rejection of Duplicate Ration Card by ARO/ BDO

1 Day 9th Day

4. Issuance of Ration card by GVPA/ SI 2 Day 11th Day

Auto Escalation Matrix- Duplicate Ration Card (Urban/ Rural)


Service Level

L1

L2

L3

Name Time Name Time Name Time 1 Submission of

Application ARO/BDO 1st Day DSO 3 Day DM 5 Day

2 Physical verification of the record by GVPA/SI

GVPA/SI 7th Day BDO/ ARO


3 Approval for duplicate ration card

ARO/ BDO


4 Issuance of Duplicate Ration Card

GVPA/ SI 1 Day BDO/ ARO

2 Day DSO 2 Day

481

Surrender of Ration Card (Rural/ Urban) – Process

Surrender Certificate (Rural\ Urban) - Process

BD

O/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

BD

O/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

E-D

istr

ict A

pp

lica

tio

n

E-D

istr

ict A

pp

lica

tio

n

Ap

plic

an

tA

pp

lica

nt

System registers

the application and

issue a receipt

Checks the

details in the

DataBase

Applicant submits

application, req.

documents and ration

card

Logs into the

system and looks

for particular

ration card record

Opens particular

record

Cancels

particular record

Particular records

gets updated

Receives surrender

certificate

Details found

Yes

Start

Application

Receipt

Comp.

Form

Availability

Component

Details get updated

and issued Digital

sign Surrender

Certificate

Stop

Details checked

Updates

database for old

information

No

Database is updated

about the Ration Card

Details

Cancels

particular record


of the application,




482

Surrender of Ration Card (Rural/ Urban) – Status Tracking

Surrender Certificate (Rural\ Urban) – Status Tracking

BD

O/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

BD

O/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

E-D

istr

ict A

pp

lica

tio

n

E-D

istr

ict A

pp

lica

tio

n

Ap

plic

an

tA

pp

lica

nt

Yes

No

Details get updated

and issued Digital

sign Surrender

Certificate


of the application,




Details checked

Checks the

details in the

DataBase

Cancels

particular record

Status

Tracking

Component

Updates

database for old

information

Database is updated


Details

Applicant submits

application, req.


card

Logs into the

system and looks

for particular

ration card record

Particular records

gets updated

System registers

the application and

issue a receipt

Details found

Opens particular

record

Cancels

particular record

Status

Tracking

Component

483

Surrender of Ration Card (Rural) – MIS

Surrender Certificate (Rural\ Urban) - Monitoring

BD

O/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

BD

O/ A

DO

(R

ura

l)

DS

O/ A

RO

(U

rba

n)

E-D

istr

ict A

pp

lica

tio

n

E-D

istr

ict A

pp

lica

tio

n

Ap

plic

an

tA

pp

lica

nt

Yes

No

Details checked

System registers

the application and

issue a receipt


of the application,




Details foundCancels

particular record

Applicant submits

application, req.


card

Details get updated

and issued Digital

sign Surrender

Certificate

Opens particular

record

Cancels

particular record

MIS

Updates

database for old

information

Logs into the

system and looks

for particular

ration card record

Database is updated


Details

Particular records

gets updated

Checks the

details in the

DataBase

MIS

484


Surrender of Ration Card Process

1

Form availability, application receipt and

payment receipt component are pre-defined

process. Once the system registers a new

application a notification will go to the

BDO/ADO/ARO/SI.The output of the pre-defined

process is the input of e-district application

e-district

application

2 log onto the e-District application and check for

the details of the ration card surrender request.

BDO/ADO (Rural)

DSO/ARO(Urban)

3

If the details are matched or found in the e-

District application, then the details are updated

in the application ,and surrender certificate is

issued to the applicant.

BDO/ADO (Rural)

DSO/ARO(Urban)

4

If details are not found, then update the details of

ration card in database and issued surrender

certificate.

BDO/ADO (Rural)

DSO/ARO(Urban)

5 eDistrict Application / database gets updated . e-district

application

6

On receiving the hard copy of application digitally

approves the application so that applicant can get

the surrender certificate from eDistrict/CSC/e

Suvidha.

BDO/ADO (Rural)

DSO/ARO(Urban)

Surrender of Ration Card Status Tracking

1.

The citizen would be able to know the status of

their application once they submit their

application through SMS, Online and CSC/e-

Suvidha centre.

e-district

application

2.

Citizen would be able to get the status after his

application is finally approved and digitally signed

by ADO/BDO/ARO/DSO through Online or visiting

to CSC/e-Suvidha/SMS.

e-district

application

485

Records view for a Logged in user (Surrender of Ration Card)


DSO /ARO/ BDO record view


1 Service Request for: Duplicate(Urban/Rural)

2 Registration No.

3 Ration Card No.

4 Ration Shop No.


6 Name of Block:

7 Name of District:


9 S/0, W/0, D/0:





486

Monitoring Report - Surrender of Ration Card(Urban/ Rural)

The following table specifies the fields required in the MIS Report (MIS component) generated for the DSO/ BDO/ ADO (Rural)

S.No

Name of Block

BDO Name

Ration Card Number

Name of Owner

Name of Village




Date of Surrender Certificate Issued


1

2

The following table specifies the fields required in the MIS Report (MIS component) generated for the DSO/ BDO/ ADO/ GVPA

(Rural)

S.No

Name of Block

Ration Card Number

Name of Owner

Name of Village

Ration Shop No.


Date of Surrender Certificate issued

Remarks

Adult Minor

1 Adult

2

487

The following table specifies the fields required in the MIS Report (MIS component) generated for the DSO/ARO(Urban)

S.No


ARO Name

Ration Card Number

Name of Owner




Date of surrender Certificate Issued


1

2


S.No


Ration Card Number

Name of Owner

Address Ration Shop No.



Remarks

Adult Minor

1 Adult

2


Service Level – Surrender of Ration Card (Urban / Rural)

S No. Activities Time required Service Level ( from date of service

request)

1. Submission of Application

1 Day 1st Day

3. Updating record by ARO/BDO

2 Day 3nd Day

4 Issuance of Surrender Certificate

1 Day 4rd Day

Auto Escalation Matrix - Surrender of Ration Card(Urban/ Rural)


Service Level

L1

L2

Name Time Name Time

1 Submission of Application ARO/BDO 1 Day DSO 1 Day

2 Updating the record ARO/BDO 2 Day DSO 2 Day DM 1 Day

3 Issuance of Surrender Certificate


489

Database Required- Public Distribution System


1. Ration Card Database This database will contain details of a citizen like Name, Age and Address, Family members details, Age, Relation, Unit Issued, Ration card No. and Shop Number. It contains details of issued ration card.

2. BPL Database This database will contain details of a citizen

like Name, Age and Address. It also contain

details regarding BPL ID No, Panchayat

name, Family id, block name, village name,

Name of head of family, father‟s name,

caste, income and it also contains total

score.

Without using this database we would not be

able to issue new BPL Ration Card.

3. Anumodan Database Anumodan database would contain the final

approved beneficiary list made during Khuli

bethak.

4. Quota Database Available Block wise and Ward wise quota

detail with status of usages.

5. Wait List List available Block, Village, City and ward

wise.

Number of Digital Signature required- Public Distribution System

S.No Designation officer Number of Digital Signature Used

1 DM 1

2 District Supply Office 1

3 Area Rationing Officer All (District)

4 BDO All (Block)

5 ADO(Panchayat) All (Block)

6 Supply Inspector All (District)

490

CRUD Matrix for Public Distribution System


District Magistrate ■ ■ ■ ■ District Supply Officer ■ ■ ■ ■

Area Rationing Officer ■ ■ ■ X

Block Development Officer

■ ■ ■ X

Supply Inspector ■ ■ ■ X

Gram Panchayat Vikas Adhikari

■ ■ ■ X


X ■ X X

Functional Requirement Specification – (Public Distribution

System)

Sr. Description

1 The system should be able to display Ration Card related page through

multiple routes

Service links

Information links

District links




Ration Card related services both in public as well as restricted domain as




4 The system should provide all services under Ration Card under a single

category

5 The system should be able to channel as well as handle different Ration

Card as per the process map and relevant description for the service

mentioned



component.



491

Sr. Description

8 The system should be able to allow service fees payments for the Ration

card service as per the „Payment Component‟

9 The system should be able to route the Ration Card details to concerned

officer at the following levels –

DM

DSO

ARO/BDO

ADO/SI

GVPA

10 The system should be able to mark the application to the BDO/ADO and

GVPA in Rural and ARO and SI in Urban areas.

11 The system should maintain records of all the Ration Card Holders in the

district along with their complete details, whether issued in Urban or Rural

areas in the database.

12 The system should be able to help the ARO/BDO to enter into the database

and check for particular applications in the case of non physical

verification of the applicant.

13 The system should allow the stakeholders to track the application status at

different stages

14 The system should allow the ARO/BDO to either accept / reject the

application.

15 The system should allow the SI/GVPA to enter/update the result of

physical verification of applicant in the Ration Card Database of Public

Distribution Supply Department.

16 The system should allow the ARO/BDO to update the result of physical

verification of applicant in the Ration Card Database of Public Distribution

Supply Department

17 The system should allow the ARO/BDO to digitally sign the Modify

Database.


transactions done with digital signature.

19 The system should be able to generate a unique registration number during

registering an applicant with the application. Should be able to identify

the applicant uniquely based on this registration number.


492

Sr. Description

applicant is registered with the system.

21 The system should allow the user to search the database on pre set query

set.

22 The system should allow the stakeholders to track the application status at

different stages as per the status tracking component.

23 The system should be able to disable old record which should trigger auto

generation of surrender certificate.

24 The system should allow the DSO\ ARO\ BDO to put his digital signature on

the approved surrender certificate as defined in the approval component.

25 The system should be able to store soft copy of surrender certificate in

database.

26 The system should be able to auto generate grievance to higher authorities

in case specified SLAs are not met by the officials.

27 The system should generate monitoring reports on specified time intervals

and send it to relevant authorities

28 The system should provide access to authorities to monitor Application

Status / Performance / SLAs for a particular period by logging onto the

system

29 The system should allow the DSO/ARO/BDO to take a print out of the

Surrender Certificate.

30 The system should be able to maintain all records for the login sessions

with date and time

31 The system should allow the GVPA to upload „Anumodan‟ by logging into e-


32 The system should store and update “Anumodan” in the Anumodan

database.

33 The system should give access to GVPA to fill up additional service request

form received at the Gram Sabha meeting through authenticated login ID

and password

34 The system should allow the GVPA to load the fresh application form

submitted at gram sabha (as defined in the parallel process map) for all

the fields (same as that of CSC centers)

35 The system should ask for re-confirmation of GVPA before actually

submitting the form

36 The system should check for all the mandatory entries in the application

form before submission of application form

37 The system should follow all the steps of application receipt component

for form submission by the GVPA

38 The system should be able to update the information in the specified

database where all service request are stored

493

Sr. Description

39 The system should notify concerned Block Development Officer about

uploading of „Anumodan‟

40 The system should allow concerned Block Development Officer to view

„Anumodan‟


„Anumodan‟

42 The system should allow the BDO to do either of the following –

approve and forward the service application request to

concerned line department

rejects the service request application (specifically based on

„Anumodan‟) with stated reason

43 The system should allow concerned BDO to digitally sign the approval /

rejection

44 The system should be able to auto generate notification e-mail to

concerned GVPA for again calling Gram Sabha Meeting for approval of

service application request in case of rejection of service request by the

BDO

45 The system should be able to auto generate report of cancellation of Gram

Sabha Meeting to the following officials for information–

District Magistrate

District Supply Officer





47 The system should not allow in any change in priority of the service

request application form for the following



48 The system should allow District Magistrate to enter allocated quota for

the district into the system.




departmental heads about updation of quota details

51 The system should allow concerned departmental head to allocate total

quota into following heads –

Blocks



concerned departmental head

494

Sr. Description

53 The system should not allow for any changes in the quota allocation by the


signature by them

54 The system should auto generate email notification to District Magistrate

about updation of quota details


BPL and Antyodya quota to blocks and municipality – ward wise

56 The system should allow DM to provide suggestion / comments for re

allocation in case of rejection

57 The system should save the acceptance / rejection only on digital

signature of the DM


departmental head about approval / rejection by the DM


concerned departmental head in case of rejection

the system should follow the same process flow as discussed above till the

quota allocation by the concerned departmental head is not approved by

the DM

60 The system should auto generate email to concerned block officer about

the BPL and Antyodya quota allocation for their respective block

495

4.2 Revenue Court service

Select Prerequisites for the ToBe Processes

The District Administration should accept the provision of Peshkars entering

the details of the cases into the Revenue Court Database using the e District

application

The District Administration should accept the provision of displaying the

Daily Cause List on the e District Website.

The District Administration should accept the provision of displaying and

downloading the Final Order PDF from the e District Website.

Adequate IT infrastructure must be made available to Peshkars of all

Revenue Courts.

Availability of a public website, where Cause List, Status of a case, and

Copy of Final Orders may be viewed and downloaded.

Mandatory entry of case details into the Revenue Court DB after every

hearing by the Peshkar.



Citizens will be able to access the Daily Cause List from the e District

Website and would not have to travel to the Revenue Courts for the same.

Citizens will be able to track the status of any case without needing to

physically visit the court.

Citizens will be able to access and obtain a copy of the Final Order for a

case without the current necessary visit to the Court.


Revenue Court – Daily Cause List

Citiz

en

Pe

sh

ka

re

-Dis

tric

t A

pp

lica

tio

nP

resid

ing

Offic

er

PO accepts the case

and assigns a hearing

date

Adjournment declared

to continue the case

hearing at another

specified date

Logs into the eDA and

Makes an entry into

Revenue Court

Database using the

eDA

The Database will store

following details:

1. Court Details

2. Case Number

3. Applicant

4. Defendant

5. Section

6. Discussion subject

7. Next Hearing Date

8. Remarks

9. Status of Case

System saves the

details of the case in

the Revenue Court

Database

Generates a dynamic

Daily cause list for

Prospective dates

Takes a printout of the

daily cause list

generated for the next

day and displays it

outside the courtroom

Citizen logs on to the e

District Website and

clicks on the link for

Revenue Court

The eDA displays the

Daily Cause List for

that date

Citizen selects the

court and enter a date

497

Revenue Court – Online Status Tracking

Citiz

en

e-D

istr

ict A

pp

lica

tio

n




Revenue Court

The e District

Application displays

the status of the case

along with a summary

Citizen selects the

court and enter the

case number

498

Revenue Court – Copy of Final Order

Citiz

en

e-D

istr

ict

Ap

plic

atio

nP

esh

ka

r

The e District

Application displays

the final order PDF,

which may be

downloaded

Peshakr Logs into the

application and opens

the Revenue Court

section.

Peshkar scans the

Final Order and

uploads the same

against the Case

Number

Citizen selects the

court and enter the

case number




Revenue Court

The e District

Application saves the

final order PDF,

against a Case

Number.



Revenue Court Service – Daily Cause List, Status Tracking and Final Orders

1

PO accepts the case and assigns a hearing date for the

same or will adjourn a running case and assign a hearing

date

Presiding Officer

2

The Peshkar of the presiding officer will log into the e-

District Application and make a Data entry into the

Revenue Court Database

Peshkar

3 Peshkar will scan the Final Order and save the PDF in

the Revenue Court Database Peshkar

4 System will save the details of the case(Summary, next

hearing and final orders if any) in the database E District Application

5 System will generate a Daily Cause List based in the

database E District Application

6 Peshkar will take out a printout of the daily cause list

and display it outside the respective court Peshkar

7

The cause list, Case Summary and a copy of Final Order

will also be available on the e District Website from

where a citizen can access it


Database required


1 Revenue Court Database

The Revenue Court database will contain Case details like Case

Number, Name, Age, Address, requested information details,

etc of both the applicant and the Defendant. The database

would also maintain a case summary, next hearing date and a

copy of the final orders if any.

500

CRUD Matrix for Revenue Courts




SDM ■ ■ ■ ■

Tehsildar ■ ■ ■ ■ Court Peshkar ■ ■ ■ X


X ■ X X

501

Records view for a Logged in Officer

Peshkar record view

The fields required in entering the details of the case are as follows:


1. Court Details

2. Case Number

3. Name of the Applicant(s)

4. Name of the Defendant(s)

5. Section(s) under trial

6. Discussion subject(s) for next hearing

7. Next Hearing Date

8. Remarks / Summary of the trial

9. Status of the Case (Registered, under progress / Interim Order

/ Final Order passed)

The fields required in uploading a copy of Final Order are as follows:


1. Court Details

2. Case Number

3. Today‟s Date

4. „Browse‟ button to attach the PDF

5. Remarks

Service Request Form

The citizen will have to provide the court details and the case number to view status

of a case or get the Final Order copy.


1 Court details

2 Case number

502

sThe Citizen will have various options in terms of viewing the cause list:


1 Selection of court

2 Listing date

3 View Criteria

An indicative snapshot of the User Interface is as follows:

As per the option selected, the e-District Application should query the Revenue Court

database and display the result as text or convert it to a PDF and then display.

Monitoring Report

The following table specifies the fields required in the MIS Report generated for the

DM Presiding Officer wise

S.No Name of

the

Presiding

Officer

Number of New Cases Number of Cases

Decided or

Disposed

Number of Cases

pending

503

Internal Service Level – Revenue Court Services

S. No. Activities Time required Service Level ( from

date of service request)

22. Data entry into the

Revenue Court Database

Same Day (When the Case details are

updated)

1st Day

23. Uploading of the copy of

Final Order 1 Day

2nd Day



NA NA NA

Functional Requirement Specification– Revenue Court Service

Sr. Description

1. The System should be able to display Revenue Court related page through

multiple routes

Service links

Information links

District links

2. The System should be able to channel as well as handle different Revenue

Court Services as per the process map and relevant description for the

service mentioned

3. The System should provide Information on Revenue Courts as per the

Information Dissemination component defined previously

4. The System should make Application Form for filing and application of a

case available online as per the Form Availability component defined

previously.

5. The System should allow the Peshkar to Log into the Application and access

the Revenue Court section.

504

Sr. Description

6. The System should enable a Peshkar to enter the case details for his court

as per the Form details given in the Service Request Form section.

7. The System should be able to generate dynamic Daily Cause Lists

8. The System should enable the Peshkar of the revenue court to take a

Printout of the specified date‟s Cause List.

9. The System should provide a printer-friendly version automatically for all

pages

10. The System should have provision for Calendar System, which displays the

dates and time of schedule revenue cases on a standard monthly calendar.

11. Under Court Case Status System:

Select Court from Multilayered Menu (District Name -> List of

Revenue Courts)

Provision for accepting Case number from user

Retrieval of Court case status with summary

Option for searching Court case with help of name of “Vaadi or

prativadi”

12. Under Copy of Final Order system should provide the following information:

Select of Court from Multilayered Menu (District Name -> List of

Revenue Courts)

Provision for accepting Case number from user

Retrieval and Downloading of Copy of final Order of Court Case

Option for searching Court case with help of name of “Vaadi or

prativadi”

Option for uploading scanned/Digitally signed soft copy of Final

505

Sr. Description

Order of court case.

The Copy of the Final Order must be Non-Editable.

13. Under Cause List system should generate the following information:

Select of Court from Multilayered Menu (District Name -> List of

Revenue Courts)

Provision for entering Case details by the Peshkar.

Date-wise list of cases should be available for view and print out

Court-wise list of cases should be available for view and print out

14. The system should support multilingual interface (minimum Hindi and

English) as per Localization and Language Technology Standards for

National e-Governance Plan defined in e-district guidelines.

506

5.0 Technical and Application Architecture

Government of Uttar Pradesh has undertaken multiple initiatives using Information

Technology as a strategic tool to provide improved service to citizens. However, to

drive both the integration between specific Government functions („vertical‟

applications) and shared Government functions („horizontal‟ applications) and data

sharing between applications, overall eDistrict application architecture requires to be

defined. In this context, the Government of Uttar Pradesh requires eDistrict

Architecture and Standards to be drawn-up. This will facilitate the State government

for cohesive and regulated growth of e-Governance interventions in the State.

5.1 Architecture Framework & Principles

Department of Information Technology, India has prescribed a framework for e-District

Applications which will aid the various States Stakeholders, application vendor in the

development of interoperable and good quality software. It is of prime and utmost

importance for the vendor to follow various standards like IEEE standards for

development prescribed by the IEEE Standard Association to ensure adherence to best

practices and standards at every stage of the software development and

implementation process; ANSI SQL 2003 standard for RDBMS; and Open standards.

e-District is a mission critical application which has to interact in an environment

where silos of frozen assets are maintained in heterogeneous formats in multiple

departments situated at varying geographical locations. The envisioned E-District

solution aims at bridging the gaps between people, processes, applications and

systems.

The ensuing write up on Open Standard is based on a thorough study of the e-District

guidelines and the Technical Standards and Application Architecture prescribed

therein.

An open standard is a standard that is publicly available and has various rights to use

associated with it.

Open standards are meant to ensure interoperability between products from

different vendors so that customers have the flexibility to put together best of

http://en.wikipedia.org/wiki/Standardization

507

breed solutions and, at least in theory, can swap out one vendor‟s products for

another‟s on account of product quality or price. The technology should adhere

to the open standards but should allow for seamless integration with a host of

various applications

Support for web services platform1 to ensure rapid application development.

This enables developers to write and maintain code quickly, lowering

development time.

Support for existing systems: At present there is a significant level of

heterogeneity in the existing applications and databases; existing code is

written in a variety of languages, and has a number of legacy systems, such as

CICS/COBOL, C++, Siebel etc. This legacy integration often is one of the most

challenging tasks to overcome when building a web service.

Open Standard support follow of process in the development of mission critical

business problems

Portability of the solution is the key issue which needs to be addressed while

deciding upon the development and deployment technologies. Follow of Open

Standards ensure Portability of the Application developed

Development Cost :Cost involved should also be factored while deciding upon

the platform. Dependencies on other technologies, if any, will increase the

cost involved and may hamper the quality of the final product/application to

be deployed

1 Web services are building blocks for creating open distributed systems. With web

services, any departmental application can be integrated in a cost effective manner so

long as it is Internet-enabled. The detailed description of the standards and specifications

of the various domains of the application architecture has been specified in the

Interoperability framework for e-Governance published in e-Disrict guidelines issued by

DIT. The same includes the interoperability areas and specifications for the web services

also.

508

Scalability: Application architecture should be such that the proposed

application is scalable . Open Standards ensures application scalability

Availability: Open Standards are available for all to read and implement.

No Royalty: Open Standards are free for all to implement, with no royalty or

fee. Certification of compliance by the standards organization may involve a

fee.

Open Interface - supports migration and allows proprietary advantage but

standardized interfaces are not hidden or controlled.

On-going Support - Open standards are supported until user interest ceases

rather than when implementer interest declines (use).

509

5.2 Architecture Vision

Having a strong architecture framework is akin to having a good foundation. The

objective of this exercise is to define this framework which would be inline with the

overall vision and also define standards and guidelines that shall act as a beacon of

light for all its future ventures on eDistrict of overall e-Governance initiative.

The eDistrict Vision and Strategy of GoUP were then effectively collaborated with

environmental and technical factors and the following sub goals have been identified

Increase the use of electronic forms and workflow as replacements for current

paper based processes (e.g., applications for permits and licenses) for faster

and better service.

Increase the sharing of data/ information among State, local bodies, other

agencies, citizens, and business groups.

Increase the use of third parties to deliver some department / agency services

and develop appropriate systems for quality management and oversight.

Build common IT infrastructure through consolidation, centralization, and

standardization.

Develop the policies and procedures for secure and appropriate access to State

information by various constituents (e.g., citizens, other agencies, and the

Central government).

Move toward electronic collection and distribution of data and information.

Establish a single entry point for multiple services both within and between

departments / agencies

Increase the variety of ways that citizens can interact with the departments /

agencies (e.g., license renewal via the web, kiosks, or in person).

Automate the core applications (e.g., accounting, personnel, payroll, and

procurement etc) used by most departments.

510

Increase data consolidation and analysis of department / agency information

for multiple purposes (e.g., performance measures, policy enhancement).

Add geographical references to data and information so that location or

proximity can be used in analysis and reporting.

Training of users and technical staff to keep up with changes in technology and

systems, and to promote more effective use of technology resources

Deliver individualized services as close as possible to the location of a client or

customer to improve accessibility and acceptable outcomes (e.g., using third

party providers, neighbourhood facilities or remote access).

Architecture Scope

The proposed architecture is for the eDistrict initiative for government of Uttar

Pradesh. Specifically, the architecture focuses on the below mentioned ten (10)

services.

Certificates

Pensions

Ration Card

Utilities

Electoral Services

Dues and Recovery

Employment related services

Grievance

Police Department

Revenue Court

Henceforth, the word “enterprise” would be used to refer the government of Uttar

Pradesh; “Enterprise architecture” refers to the eDistrict architecture for the state of

Uttar Pradesh.

In terms of architecture domains, the document focuses on Business architecture,

Application architecture and platform architecture. This report does not aim to define

the low level or individual application specific architecture. The description is

generally at a level of abstraction wherein the enterprise at a whole is addressed

rather than specific sub-instances. The aim is not to develop a fully detailed

description at this stage. Future iterations during implementation will build on the

511

artefacts created. However the report also describes the various industry standards

and guidelines that should be adhered to realize the overall vision of the project.

5.3 Constraints

The overall vision of the government is to automate and E-enable the services of all

the government departments. However, currently ten departments have been

identified to be part of the eDistrict initiatives. Although the overall enterprise

architecture needs to be scalable to accommodate future inclusions of other

departments and services, currently system and service information pertaining to the

identified set of departments will only be available. There is a need to perform some

extrapolation to meet the scalability requirements. Consequently the actual

infrastructure needs to be buffered to meet the additional load that is likely to come

in during subsequent stages.

Business Architecture

The Sub Services decided for the 10 broad categories:

Selected Services under e-District project, U.P. S.No. Service 1 Police 1.1 FIR Status 1.2 Character Verification

2 Certificates

2.1 Caste

2.2 Income

2.3 Residence

2.4 Birth

2.5 Death

2.6 Handicap

3 RTI & Grievance

3.1 RTI Applications for all departments

3.2 Grievance (Limited to 10 Selected Services only)

4 Public Distribution System

4.1 Issuance of new ration cards

4.2 Surrender Certificate

4.3 Modification in ration card

4.4 Issuance of duplicate ration cards

5 Pensions

5.1 Old age

5.2 Widow

5.3 Handicap

6 Utilities

512

6.1 House Tax

6.2 Property Tax

6.3 Issuance of RTC (khatauni)

7 Dues and recovery from land revenue perspective

7.1 Issue of CITATION

7.2 Modifications in the RC

7.3 Generation of RC

7.4 Tracking of RC

8 Electoral Services

8.1 Updation of electoral rolls

9 Revenue Court Services

9.1 Case Listing

9.2 Cause list generation

9.3 Final issuance of order

9.4 Progress tracking

10 Employment Services

10.1 NREGA

10.2 SGSY

10.3 PMRY

10.4 Registration in employment exchange

513

High Level Use Case model for eDistrict

514

5.4 Information Systems Architecture

Data Architecture

The following diagram is a sample Data Architecture covering Pension Department to

design eDistrcit Data Model.

As depicted in the above diagram, we recommend a layered data architecture. At the

minimum, the data architecture should comprise of the following layers

1. Base / Foundation data store

515

This layer should have the core information that is required for the operation of

the department. This would include information about the various Regional

Pension Offices across the state, working rules, guidelines, application forms,

master data and configuration information for the IT systems to function.

2. Pension data store

It is recommended that all the information directly related to vehicle be grouped

together. This includes information such as Citizen Data Contribution Fund,

Regular Payments etc. Such a logical grouping would result in a more cohesive

system.

3. External Agency data store

Apart from end users (citizen), the Pension department also interfaces with several

external agencies such as Banks (Payments data), Post Offices (Payments Data),

and Government Accounting Data. It is advisable to store these set of information

in a separate data store so that software integration and maintenance can be done

in an efficient manner.

4. Internal Agency data store

Apart from interfacing with external agencies, the Pension department also works

with other government agencies and departments. These include the pollution

control board, police / legal agencies, tax collection centres and commercial tax

department.

5. Transaction data store

The transactional data store will hold the day to day transactions including

application processing, receipt generation, approvals etc. As part of transaction

processing, the system will also generate data logs and application logs that would

be stored for maintaining transaction history, legal and repudiation purposes. It is

also advisable to have a separate data cache specifically for reporting purpose to

improve the overall system performance and maintenance.

516

Access to each set of information should be through secured data access channels.

This channel would provide required security features such as authentication and data

encryption / decryption.

The entire data would be protected from direct access from regular users (except

administrators). The functionality should be encapsulated and specific interfaces

should be exposed to the external world (includes portal, kiosks and service centres).

These service interfaces would be invoked by clients directly via end-user interface or

by other systems via system interface mechanisms.

Data exchange and integration should be handled by a dedicated integration layer

(discussed in the overall enterprise architecture). All data transfers between the

Payment department data store (s) and external agencies or other government

agencies will happen through this integration layer only.

Storage Requirements

The following table summarizes the storage requirements. The storage requirements

have been calculated based on the assumptions regarding the transaction and size of

the data.

Storage Requirement in Gbs

Total Data

Storage Required

(TB) (Planned

for 5 years) Services

Approximate Data

Involved (KB) 1st Year 2nd Year 3rd year 4th year 5th year

Pension 20.00 17.47579384 20.09716291 23.11173735 26.57849795 30.56527265 0.030

Police 18.00 17.90565319 20.59150117 23.68022634 27.2322603 31.31709934 0.031

Certificate 18.00 10.53657274 12.11705865 13.93461745 16.02481007 18.42853158 0.018

Utilities 19.00 2.3549613 2.708205495 3.114436319 3.581601767 4.118842032 0.004

Total 0.082

517

Access Rights Management

The Access to the databases, which will store all the information related to the

applications, the verified details, and the digitally signed deliverables, should be

tightly governed and monitored. The integrity and security of these databases is of

paramount importance.

These databases will accessed by various stakeholders at different stages of processes.

We would define the access parameters based on the CRUD Model for access

management. The acronym CRUD refers to all of the major functions that need to be

implemented in a relational database application or RESTful web application to

consider it complete. An indicative mapping of each letter in the acronym to a

standard SQL statement is demonstrated below:

Operation SQL

Create INSERT

Read (Retrieve) SELECT

Update UPDATE

Delete (Destroy) DELETE

Although a relational database is a common persistence layer in software applications,

there are numerous others. CRUD can be implemented with an object database, an

XML database, flat text files, custom file formats, tape, or card, for example.

The CRUD Matrix is a two-dimensional chart that summarizes the Access Rights

combinations for a particular designation.

Some globally valid Access Rights applicable to all Databases are indicated in the CRUD

Matrix provided below:


District Magistrate ■ ■ ■ ■ Additional District Magistrate ■ ■ ■ ■

SDM ■ ■ ■ ■


Every service detailed in the Report has an independent section of the CRUD Matrix for

the Database envisaged to be used for that Service.

http://en.wikipedia.org/wiki/Relational_database

http://en.wikipedia.org/wiki/Application_software

http://en.wikipedia.org/wiki/RESTful

http://en.wikipedia.org/wiki/SQL

http://en.wikipedia.org/wiki/Insert_%28SQL%29

http://en.wikipedia.org/wiki/Select_%28SQL%29

http://en.wikipedia.org/wiki/Update_%28SQL%29

http://en.wikipedia.org/wiki/Delete_%28SQL%29

http://en.wikipedia.org/wiki/Object_database

http://en.wikipedia.org/wiki/XML_database

http://en.wikipedia.org/wiki/Flat_file_database

518

Application Architecture

The primary IT enhancements that can be taken up in the payment department are:

1. Integration with external agencies

a. This would typically involve interaction with a common integration layer

and development of required adaptors. The integration layer will

handle integration with banks, driving schools, vehicle dealers,

insurance companies (non-government) as well as other government

departments

2. Service enablement

a. This would typically involve wrapping critical functionality and exposing

them as web services. The applications themselves have to be modified

to support integration with a centralized eDistrict portal.

519

5.5 Technology Architecture

There are two approaches for implementing the e-District solution across the state,

which can be understood in terms of immediate and long term approach.

A. Immediate (Point to Point or in absence of State and NSDG)

B. Log term (Integration with the State / National gateway)

(A) Immediate approach – under this approach we can define the strategy

to be adopted for starting the e-district application deployment in the absence of

NSDG and state gateway. The concept of an enterprise service bus (ESB) is used for

this purpose. It is a pattern of middleware that unifies and connects services,

applications and resources within a business. Also, it is the framework within which

the capabilities of a business' applications are made available for reuse by other

applications throughout the organization and beyond. With the help of we can now

integrate applications, coordinate resources and manipulate information. An

enterprise service bus can optimize information distribution within an enterprise and

beyond and may be built with integration middleware products available.

An enterprise service bus:

Is standards-based

Can enable all parts of a business to react instantly to new information

Minimizes risk by using industry standard interfaces and protocols

Overcomes differences in platform, software architecture and network

protocols

Assures delivery of transactions, even when systems and networks go off-line

Re-routes, logs and enriches information without rewriting applications

Provides an infrastructure that is highly distributed and yet can be managed

centrally

Can distribute data throughout your business and beyond to your customers

and business partners

Spans different operating systems, programming models, application types

and locations

Can be deployed incrementally, project by project, to better manage expense

May combine new and existing technologies and standards

Supports message, service and event oriented architecture

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi?CTY=US&FNC=SRX&PBL=G325-2390

http://www-306.ibm.com/software/info/openenvironment/soa/

http://www-306.ibm.com/software/info1/websphere/index.jsp?tab=offers/wbieventbroker&S_TACT=103BGW01&S_CMP=campaign

520

The deployment of ESB in e-district architecture can be depicted through this

diagram

522

(B) Long Term approach – Under this approach, the strategy is to integrate the

e-district application deployment of point –to- point approach with NSDG and state

gateway as envisaged under National e-Governance Plan (NeGP) of the Govt. of India.

The figure below depicts the positioning of the state gateway in the State Data Center

and the external entities (like district ESB at district level and NSDG at the central

level) interacting with the state gateway for exchange of data using IIS/IIP message

formats and protocols. These gateways thus enable interaction between various

departments /external entities using standard interfaces/connectors. The gateway

acts as the single point of access to backend departments for all external entities. The

state level gateway interacts with the e-district ESB at district level and NSDG at the

central level for exchange of data with central MMPs.

Interoperability - As the State Gateway requires that all applications interacting with

it need to convert data to IIS/IIP XML and SOAP based format the applications being

developed by departments need to include the gateway interfaces in their application

architecture. The ESB as depicted in point –to point approach diagram for each e-

523

district application will be used in integration with state gateway as it is and encircled

with red color. When State gateway will resume all the services and stable enough to

handle the requests the ESB role will be reduced and eliminated in due course of time,

hence in long term the scenario would become as depicted in diagram.

524

Quality of Service Considerations

Scalability

This factor can be understood with the help of scalability Pyramid. It is evident that a

good design is the foundation of a highly scalable application. At no other point in the

lifecycle of an application can a decision have a greater impact on the scalability of an

application than during the design and conceptualization phase.

As the scalability pyramid indicates, fast hardware, software, and tuning are only a

small part of the scalability equation. At the base of the pyramid is design, which has

the greatest influence on scalability. As you move up the pyramid through decreasingly

important factors, the ability to impact scalability decreases. What the pyramid

illustrates is that smart design can add more scalability to an application than

hardware. Hence there is need to design the application in such a way that it can

cater the smooth roll-out from 6 districts to 70 districts.

When designing for scalability the primary goal is to ensure efficient resource

management. Designing for scalability is not limited to any particular tier or

component of an application. Application architects must consider scalability at all

levels, from the user interface to the data store. Following are the factors which need

to be considered when designing for Scalability.

1) Prioritization of services- Generally systems like e-district envisaged to

provide a large number of services to be provided. In initial roll out the main

services or the services which are immediately required are introduced with

525

the system rollout and remaining services will be plugged in to system in

phased manner as and when required. The Architectural framework should be

designed to cater this aspect.

2) Classes of service - as stated above the Architecture should also accommodate

to increase or decrease the number of classes, in order to achieve more

services.

3) Dynamic change support- The system architecture should capable to support

the dynamic change in to the system.

4) Transparent resource addition - The system architecture should capable to

support the transport resource addition with the system.

5) Commutability - The application design should try to incorporate the principle

of Designing for commutability. Two or more operations are said to be

commutative if they can be applied in any order and still obtain the same

result. Typically, operations that you can perform in the absence of transaction

are likely candidates. The less transaction oriented the operations are, easy it

is to scale up the application.

6) Interchangeability:- The idea here is to move the state out of the

components. As we add more state to the components, they become less

interchangeable. Requiring components to maintain state between method

calls defeats interchangeability and, ultimately, scalability is adversely

impacted. Instead, each method call should be self-contained. Store state

outside the component when it is needed across method calls. When calling a

method of a stateless component, any state required by that method can either

be passed in as a parameter or read from the storage. At the end of the

method call, preserve any state by returning it to the method caller or writing

it back to the storage. Interchangeability extends beyond resource pooling.

Server-side page caching for a Web application will most likely increase its

scalability.

526

7) Logical versus physical tiers consideration - When designing application,

logical separation should always be considered. Always logically partition the

application between the user interface layer, business logic layer, and the data

layer. Although logical separation does not mandate physical separation, it

makes physical separation possible. By partitioning the application to enable

physical separation, we can achieve scalability by scaling out the application

across several machines.

8) Isolate transactional methods - Separate transactional methods from non-

transactional methods. Placing non-transactional methods in a component that

requires a transaction for its transactional methods will negatively impact the

scalability of that component because calls to either class of method incurs the

overhead of a transaction.

9) Eliminate business logic layer state when possible - By making the business

logic layer as stateless as possible, the scalability of the layer can be

increased.

Maintainability

Following are the factors which need to be considered while require time to add a

Component /Service / Module to an Existing Application

Architecture and Component Framework - The Architecture is based on open

standards take less time to add the Component / Service / Module to an Existing

Application.

Classes and services- It is very important to understand how the classes and services

has been developed and configured in the application framework. These should be

created in such a way that any future requirement or addition of services etc helps to

introduce new services easily.

Access and Roles- The roles and responsibilities are assigned to new users through

LDAP or equivalent service. This service must be compatible enough to take care of

527

the whole hierarchy of the departments which are going to be included. Incase the

flexibility in design has not been taken in cognizance it may create the problem at

later stage and take longer time to add the service into the architecture.

Master data Management- This aspect take care of the master data which would

be used by each department. If this factor is considered and system architecture

addressed respective issues, then any service can be plugged easily in to the

framework and used instantly.

Integration-The following integration issues will determine the ease and time required

to add the Component /Service/Module to an Existing Application.

o Integration across disparate platforms and data sources

o Integration of legacy data and applications with distributed systems

o Applications or data that use proprietary APIs, making it difficult to take

advantage of them from reporting, analysis, integration, and development tool

Communication Protocols – There is need to define the interaction relationships with

facilities for synchronous and asynchronous communication by message . These can

be Exchange on the one hand and shared data elements on the other hand.

Data Accessibility & Handling – The proprietary data and its accessibility and handling

etc are the factors which defines the require time to add a Component /Service /

Module to an Existing Application.

Implementation and Deployment - Deployment of frameworks introduces many

challenges in the area of interoperability between different communication and

control protocols. There are implementation and vendor interoperability issues related

with deployment which needs to be dealt.

528

Extendibility

Since the e-district application will be rolled out from 1 district to 70 districts with

covering all the villages and Tehsils of that district. Hence e-district implementation

can be organized into horizontal and vertical planes.

Vertically, it consists of different units like Districts, Tehsil, block and villages

whereas horizontally it has number of districts, tehsils and villages. The state has

approximate 70 Districts, 303 Tehsils, 812 blocks and 1.09 lacs villages. This data

indicates that a District would be to fully functional when all the tehsils and villages

under its jurisdiction are have implemented the e-district concept. Same has been

depicted in diagram with an example.

Looking in to the quantum of tasks for application roll out in horizontal and vertical

plane following points need to be considered.

A) Vertical Extendibility - When application is rolled out in a district across Tehsil and

villages, the following factors can be important.

Architecture and Component Framework - The Architecture should be based

on open standards and interoperable industry standards so that inherent

flexibility would be there is system to make any changes from the district level

529

to village level. Once this stabilized in vertical plane then minimum changes

will be required when rolled out in horizontal plane.

Classes and services- The classes and services should be developed and

configured in the application framework in such a way that any future

requirement or addition of services etc helps to introduce new services easily.

This will be frequent when changes required from the district level to village

level. Once this stabilized in vertical plane then minimum changes will be

required when rolled out in horizontal plane.

Access and Roles- The roles and responsibilities are assigned to new users

through LDAP or equivalent service. This service must be compatible enough

and ensured to take care of the whole hierarchy of the departments which are

going to be included. Incase the flexibility in design has not been taken in

cognizance it may create the problem at later stage and can severely impact

the services of framework. Once this stabilized n vertical plane then minimum

changes will be required when rolled out in horizontal plane.

Master data Management- This aspect take care of the master data which

would be used by each department. If this factor is considered and system

architecture addressed respective issues, then any service can be plugged

easily in to the framework and used instantly. This would be once at any

vertical plane and will be changed on each implementation in Horizontal plane.

Configuration Management – There may be instances where the same

application as developed for a vertical plane can be used as it is or minimum

changes required. But there may be circumstances when whole of new type of

service is required. At that time configuration management would be must to

take care of both the requirements. Hence this would remain approximately

same in both the horizontal and vertical plane.

Addition of services – There may be change in addition of services to be added

in to the application in the horizontal and vertical plane.

530

Standards and Protocols – There is need to define the interaction relationships

with facilities for synchronous and asynchronous communication by message

. These can be exchange on the one hand and shared data elements on

the other hand. This would remain same in both the horizontal and vertical

plane.

Integration and interoperability - Deployment of framework in vertical plane

introduces challenges in the area of integration and interoperability. This

would be severe in case of horizontal plane for integration.

Implementation and Deployment - Deployment of frameworks introduces

many challenges in the area of interoperability between different

communication and control protocols. There are implementation and vendor

interoperability issues related with deployment which needs to be dealt.

Data standardization and Management– Data must be standardize to form a

unique nomenclature and format so that each district and its vertical plane

data would be different in style. This will help in collating the data at state

level at later stage. Also Data backup and recovery should be defined to take

care the vertical plane of district, tehsils and villages.

Hardware- The hardware at district would be sufficient enough to take care

the requirements of number of users its vertical plane which includes district,

tehsils and villages.

Security – There should be vertical propagation of security configurations in

the framework to enable the extendibility in that direction.

B) Horizontal Extendibility- Most of the aspect has already been discussed in vertical

extendibility. Some points which help in rolling out application in this plane.

531

Synchronization – There would be capability to synchronize various horizontal

rollouts at state level. At later stage the state portal will be connected with

state gateway to all the horizontal rollouts and produce the required result.

Integration – There would be cases when departmental/organizational

boundaries are not the same as of district boundary in that case the master

data would be available in both the e-district systems that are under that

organization‟s boundary. This can introduce some challenges when

consolidating the data at state level and hence need to be properly

investigated and addressed

532

Security

Public Key Infrastructure

Digital Signature

The e-District application should have PKI infrastructure, digital signatures as the

measure for ensuring high degree of user authentication and security. For e.g. the

online approval of the an application for issuance of birth certificate shall require

approval of the concerned departmental officer using his digital signature. An exercise

has already been carried out to identify such sensitive and critical transactions

requiring digital signature based authentication and approvals, which are detailed in

the functional requirements of the services.

Following outlines certain guidelines with respect to implementation of PKI Services.

i. The security solution implemented for e-District application shall support usage

of Digital Certificates authentication for all the personnel performing critical

transactions in the system

ii. The eForms must support PKI Digital Certificate based signatures. All the eForms

are expected to have the capability to be signed digitally by concerned

departmental staff, depending on the service.

iii. The integrity of the original eForm and its data content must be verifiable using

the PKI digital signatures even after notes/comments/water marks are added by

the employees

iv. For ensuring full integrity of transaction, one service application comprising both

data and documents should be treated as one whole package that will be signed

digitally and stored in the database

v. The solution should support digital certificates issued by all (or chosen one)

licensed CA in India and should accept digital certificates based on criteria

(Issuer, Class, Policy Identifiers)

vi. The digital signatures used in for the portal must be compliant to RSA standards

as required by IT-Act 2000 and any further amendments, if any.

vii. Automatic validation of digital certificates used for authentication and digital

signatures is required. The validation must include check for acceptance criteria

(Issuer, Class and Policy Identifiers), validity period, and current CRL based

revocation checking.

viii. Digital signatures to be used shall be compatible with all platforms without any

limitation

533

ix. Digital signing and encryption of attachments (documents) compliant to PKCS

standards is required.

x. Database server shall support PKI based authentication for administrative access

to the server as a measure for database security

xi. Access management and privileges for content management should be secured

and advanced authentication technologies such as PKI shall be used for

controlling access to the content management.

xii. The system design should be extensible to support newer authentication

mechanisms

Digital Certificates: Indicative Costs

The following table gives the indicative costs for procuring digital certificates:

Class of Digital Certificates Cost of Digital Certificates

Class IIIa for individuals INR 2,000 per year

Class IIIb for Enterprises/ Government

organizations or Agencies

INR 2,000 per year

Source: Directorate General of Foreign Trade

Website : www.dgft.delhi.nic.in

http://www.dgft.delhi.nic.in/

534

It may be noted that the actual prices are subject to market conditions as well as terms offered by

vendors upon bulk procurement of digital signatures.

Services

Digital Signature

Required

District

Officials Number

Pensions

Rural Yes BDO All

GVA All

DSWO 1

DPO 1

DHWO 1

DM 1

Urban Yes SDM All

Tehsildar All

Lekhpal All

DSWO 1

DPO 1

DHWO 1

DM 1

Electoral Rolls

updated Yes SDM All

ADEO 1

RTI Yes DM

PIO

Dist.,Tehsil,

Block

APIO

Dist.,Tehsil,

Block

Dues & Recovery Yes DM 1

CRA All

Tehsildar All

Nayab

Tehsildar All

WBN All

Police

FIR Status Yes

Zonal Circle

Officer All

Character Verifcation Yes SP 1

Utilities No No

Property Tax

Employment

Exchange Yes CDO 1

DEO 1

ADEO All

SGSY Yes CDO 1

DDO 1

535

BDO All

GVA All

PMRY Yes GMDIC 1

DIC STAFF 2

NREGP Yes DM 1

ADM All

CDO 1

BDO All

GVA All

Public Distribution

Supply Yes BDO All

DSO 1

ARO All

SI All

Revenue Court Yes

DM 1

ADM All

Certificates Yes

DM 1

SDM All

Tehsildar All

RI/ Lekhpal All

CMO 1

536

6.0 Way Forward

The following are the next steps to be conducted for developing framework of process

improvement for the selected services covered under e-District MMP

Comprehensive RFP for Data Digitization and Hardware Procurement

RFP would be prepared covering amount of data to be digitized, service level

parameters and metrics for vendor

Change Management Plan

Change management plan would be developed to address the training

requirements of the government staff identified during the subsequent phase

Site Preparation Monitoring

Preparation of site lay out plan for office renovation and monitoring of renovation

works would also be carried out by consultants.

Application Development

Application development for selected services would be carried out by NIC.

Implementation of application at field level

Application would be implemented at the district and field level department

offices.

Consolidated TO-BE & Functional Requirement Specifications ...

Documents

Transcript of Consolidated TO-BE & Functional Requirement Specifications ...