ASHA Supervisor Incentive Verification Module

Revision Summary  (Please click here for clickable prototype: ASHA Supervisor module prototype)

1. Document Overview

Utprerona is a unified application used by multiple health system actors such as ASHA Supervisors, CHOs, and ANMs, with access governed through role-based user authentication. Based on the logged-in user’s role and mapped geography, the application provides access to relevant ASHAs, their performance indicators, and incentive claim data. This document defines the requirements for a mobile-first ASHA Supervisor Incentive Verification module within the Utprerona application, aimed at digitising the monthly incentive verification process that is currently carried out through paper-based workflows. 

1. Background & Context

Utprerona is used by ASHAs to digitally capture health care activities and generate monthly incentive claims, with incentive amounts auto calculated based on predefined NHM logic. 

Currently, ASHA Supervisors: 

• Manage multiple sub-centres (often 3–5+) 

• Verify ASHA incentive using paper registers (Master claim form) 

This manual process is time-consuming, error-prone, and lacks transparency and auditability. 

1. Problem Statement

• No digital interface for supervisors to review incentive claims 

• Heavy dependency on paper records 

• Delays in verifications and payments 

• No system-level audit trail 

1. Product Vision & Goals

Vision 

Provide ASHA Supervisors with a simple, mobile-first digital interface to review and verify ASHA incentive claims efficiently and transparently. 

1. User Persona

Primary User: ASHA Supervisor 

• Oversees multiple ASHAs mapped across sub-centres 

• Responsible for monthly incentive validations further is validated by CHO/ANM 

• Uses smartphone as primary device 

• High workload, limited time 

1. In-Scope / Out-of-Scope

In-Scope (Phase 1) 

• Role based login for Supervisor/ CHO/ ANM using FLW App 

• Supervisor Dashboard 

• ASHA Monthly incentive summary 

• Activity-level review 

• Single Verify action 

• Audit logging 

Out-of-Scope 

• Block/District approvals 

• Incentive recalculation or edits 

• Payment disbursement 

• Web portal 

1. State Specific Configuration

Certain configurations must be applied differently for the Mitanin and Utprerona application build variants based on Statespecific requirements. The following functional behaviors distinguish the two builds: 

1. Supporting Document Verification 

• Not applicable in the Mitanin app. 

• Applicable in the Utprerona app. 

1. Incentive Amount Calculation 

• Not applicable in the Mitanin app. 

• Applicable in the Utprerona app. 

1. Verification Workflow 

• In the Mitanin app, only ASHA Supervisor verification is required. 

• Additional verification layers (CHO or ANM) apply only to the Utprerona app. 

1. Cutoff Dates 

• Cutoff dates are different for each State-specific build, and the configuration must be maintained separately for the Mitanin and Utprerona app variants. 

• Cutoff dates are configurable per app variant by the program admin team and are applied uniformly across all Supervisors mapped to that variant. Two cut-off windows are maintained: (a) the ASHA submission and re-submission window, and (b) the verification deadline for ASHA Supervisor, CHO and ANM. The defaults below apply at first rollout and can be overridden by the program team without a code change. 

• Utprerona (Assam) defaults: 

1. ASHA submission and re-submission of monthly incentive claims: 1st to 12th of every month. 

1. Verification of submitted claims by ASHA Supervisor, CHO and ANM: by the 12th of every month. 

• Mitanin (Chhattisgarh) defaults: 

1. ASHA submission and re-submission of monthly incentive claims: 1st to 3rd of every month. 

1. Verification of submitted claims by ASHA Supervisor, CHO and ANM: by the 5th of every month. 

• Overdue derivation: an ASHA-month claim is flagged Overdue once the configured verification cut-off date for the active state has elapsed and the claim is still Pending with the verifying actor (Supervisor, CHO or ANM). The Overdue state therefore depends on the dates configured above and on the system clock; it is not based on any fixed day-count threshold. 

1. Verification Model

Verification Granularity 

Every month all ASHAs incentive claimed activities are verified by respective ASHA supervisor; and if required, followed by other actors like CHO or ANM, further post verification claims are processed to the SSD portal for approval actions. Hence the two roles of ASHA supervisor broadly are 

1. Validate individual incentive-linked activities of ASHAs 

1. Verify all pending claimed activities of ASHA for that particular month 

Incentive amounts are read-only and system-calculated. 

1. User Journey (High-Level)

1. Functional Requirements

9.1 Supervisor Dashboard (KPIs will be shared separately later) 

Features 

• Login Screen for Supervisor- Role based access- mapped with facility 

• The dashboard header shall display the logged-in Supervisor’s name and Supervisor ID 

• Dashboard should display overall status of how many ASHAs verification is pending vs completed so that supervisor can approach them for completion 

• Month selector (default: current month) 

• Smart search: 

• ASHA name 

• Sub-centre name (shows all ASHAs under it) 

• Sub-centre filter dropdown beside the Month selector. The list includes all sub-centres mapped to the logged-in Supervisor plus an “All” option (default: All sub-centres). When “All” is selected, all tile counts aggregate across every sub-centre mapped to the Supervisor. 

• Option to Verify or Reject each ASHA claims globally- Each ASHA’s verification will be done only ONCE unless it is rejected, if rejected then post resubmission of ASHA, it can be verified again  

• Notification Alerts to Supervisor after submission by ASHAs 

• Supervisor profile 

• Report generation of Incentives PDF 

Dashboard Tiles (Incentive Dashboard) 

• Total ASHAs tile: displays the count of ASHAs mapped to the logged-in Supervisor (across all selected sub-centres). The tile is clickable and navigates to the ASHA Monthly Detail drill-down screen described in §9.1.1, where ASHAs are listed under their respective sub-centres with their individual claim status. 

• Primary status tiles: Verified, Pending, Overdue. These three tiles represent activities for which the ASHA Supervisor is directly responsible. Counts are derived from the active Month and Sub-centre filter selection. Overdue follows the rule in §11, which depends on the configured verification cut-off date for the active state (see §7). 

• Secondary status tiles: Rejected and ASHA Unclaimed. Rejected reflects claims sent back to the ASHA awaiting correction. ASHA Unclaimed reflects ASHAs mapped to this Supervisor who have not yet submitted their monthly claim for the selected month. 

• Tile visual treatment: Primary status tiles in the first row and secondary in the next. Each status tile shall use a status-appropriate filled colour per the design system (replacing the current white-background treatment), so the five statuses are visually distinct at a glance. Exact colour tokens are owned by UI/UX and will be applied consistently across the Supervisor, CHO, and ANM dashboards. 

Sub-Center Under You (Sub-Centre List) 

• The dashboard shall list all sub-centres mapped to the logged-in Supervisor, along with the count of ASHAs in each sub-centre. 

• Each sub-centre row is clickable. On tap, the Supervisor is navigated to the ASHA Monthly Detail drill-down screen (§9.1.1), scoped to that single sub-centre. The sub-centre name appears as the section header and the ASHAs mapped to that sub-centre are listed with their respective claim status. 

9.1.1 ASHA Monthly Detail (Drill-down Screen) 

The ASHA Monthly Detail drill-down is a list-style screen that classifies ASHAs by sub-centre and shows the claim status of each ASHA for the selected month. It is reached from two entry points on the Supervisor Incentive Dashboard. 

Entry Points 

• Tap on the Total ASHAs tile: the screen lists every ASHA mapped to the Supervisor, grouped by their respective sub-centre (sub-centre name appears as a section header above each group). 

• Tap on any row in the “Sub-Center Under You” list: the screen is scoped to that single sub-centre. Only the sub-centre name and the ASHAs mapped to it are shown. 

Screen Elements 

• Screen title: “Incentive Verification”. Search bar at the top with placeholder “Search ASHA…”. 

• Sub-centre group header (e.g., “Sub-centre: XYZ”) followed by an ordered list of ASHAs mapped to that sub-centre. The header repeats for each sub-centre when entered from the Total ASHAs tile. 

• Each ASHA row shows: ASHA Full Name and a Claim Status chip showing one of: Verified, Pending, Rejected, Overdue, or Unclaimed, using the same colour vocabulary as the dashboard tiles. 

• Tapping an ASHA row navigates to the existing single-ASHA Monthly Detail screen (§9.2) for activity-level review and verification. 

• The screen respects the Month and Sub-centre selections active on the Supervisor Dashboard at the time of navigation. 

ASHA Card Fields 

• ASHA’s Full Name 

• ASHA Emp ID 

• Sub-centre Name 

• Total incentive amount 

• Activity count 

• Verification Status: verified by / Pending 

9.2 ASHA Monthly Detail Screen 

Header 

• ASHA Name, Emp ID 

• Sub-centre Name 

• Month & Year 

• Overall status 

Summary Card 

• Total activities 

• Total incentive (read-only) 

• Approved amount 

• Pending amount 

Primary Action 

• Global Verify / Reject for the ASHA-month: the Supervisor performs verification once for the entire ASHA-month claim package, not per individual activity. The screen footer pins a single mandatory document-verification checkbox (“I have verified supporting documents on ASHA’s device”) followed by two actions: Verify and Reject. Both actions are disabled until the checkbox is ticked. Verify transitions every claimed activity for that ASHA-month to “Verified by Supervisor” in one transaction; Reject opens the eight-reason multi-select (Other → mandatory remarks) and applies the rejection to the whole ASHA-month, returning all activities to the ASHA as Pending for correction. 

• No per-activity Verify/Reject buttons are shown on this screen. Status chips per activity row are not shown either; the ASHA-month claim package is implicitly a verification queue, and aggregate status is reflected only on the upstream ASHA-listing drill-down (§9.1.1). 

• Each ASHA’s verification is performed only ONCE per month unless the ASHA-month claim is rejected; on rejection-and-resubmission by the ASHA, the Supervisor can verify again. (Reaffirms the “done once unless rejected” rule already stated in §9.1.) 

9.3 Activity Display & Grouping (Category Accordion) 

All incentive-linked activities claimed by the ASHA for the selected month are grouped under nine program categories aligned to the Assam Incentive Claims master sheet. Categories are always rendered in master-sheet S.No order so the layout matches the paper claim form and is predictable across ASHAs. 

The nine program categories (master-sheet order) 

• Child Health 

• Immunization 

• Maternal Health 

• ASHA Incentive under JSY 

• Family Planning 

• Adolescent Health 

• Umbrella Programmes (TB, leprosy, NPCB / cataract, etc.) 

• NCD (Non-Communicable Diseases) 

• Other Incentives (ABHA, mobile-bill reimbursement, state additional incentive, etc.) 

Default state & safeguards against missed review 

Because every incentive claim raised by the ASHA for the month must be verified by the Supervisor (all claimed activities are mandatory and the single Verify action commits the entire ASHA-month), the following safeguards apply to prevent any claim from being silently missed during review: 

• Default open: on first load of an ASHA Monthly Detail screen, all non-empty categories are rendered in their expanded state so every claimed activity row is immediately visible without further taps. The Supervisor may collapse a category once they have reviewed it; collapsing serves as an informal “reviewed” affordance. 

• Counts always visible: the No. of Claims and Total Amount Claimed on each category header strip are visible in both expanded and collapsed states. Collapsing a category never hides the fact that claims exist under it. 

• Empty categories shown: every one of the nine categories is rendered even when the ASHA has zero claims under it (labelled “No claims this month”). This proves to the Supervisor that no category has been silently filtered out. 

• Scope reminder banner: a one-line informational banner immediately above the first category strip shall read “Verify will commit all claims listed below in one action.” This sets correct expectations before the Supervisor reaches the footer Verify / Reject buttons. 

Category accordion header (collapsed state) 

Each category is presented as a collapsible accordion section. The collapsed header strip shall display, left to right: (a) the category name; (b) the aggregate number of activity claims raised by the ASHA under that category for the selected month; (c) the total claimed amount in INR aggregated across all activities of that category; (d) an expand/collapse chevron. Tapping anywhere on the strip toggles the expanded state. Empty categories — where the ASHA has not claimed any activity under that category for the selected month — are always rendered (so the layout is consistent across ASHAs) but display the label “No claims this month” in place of counts/amount, and are not expandable. 

Category accordion (expanded state) 

Expanded, the section reveals one row per claimed activity within the category, listed strictly in Assam master-sheet S.No order. Each activity row shall present the following four columns: 

• S.No : the Assam master-sheet serial number for that activity (1–84), preserved across categories so it matches the paper claim form. 

• Activity Name : the full activity description from the master sheet (e.g., “ASHA incentive for ANC registration within 1st Trimester”). The category name (e.g., “MATERNAL HEALTH”) is NOT repeated as a subtitle on each row; it is implicit from the parent accordion. This is the core space-saving change introduced in this revision. 

• No. of Claims : aggregated count of individual beneficiary-level claims rolled up to this activity for the selected month (e.g., “2” if the ASHA registered 2 ANC cases). 

• Amount Claimed (₹) : aggregated amount system-calculated using the master-sheet rate × No. of Claims (e.g., ₹50 × 2 = ₹100). Read-only. 

The activity row contains no status chip and no Verify/Reject affordances; verification is performed once at the screen level (§9.2). Tapping anywhere on an activity row opens the read-only Beneficiary-Level Detail sub-screen described in §9.3.2. 

9.3.2 Beneficiary-Level Detail (Read-only sub-screen) 

Reached by tapping an activity row in the category accordion. This screen lists the individual beneficiary-level / case-level claims rolled up under that activity for the selected month. It is strictly view-only, with no actions available here. The Supervisor returns to the ASHA Monthly Detail screen via the standard back affordance to perform verification at the ASHA-month level (§9.2). 

Column layout: the screen renders a sticky yellow header band at the top showing three column captions: S.No (left), the full Activity description carried over from the parent activity row (centre, so the Supervisor sees the same long-form text from the master sheet, e.g., “ASHA incentive Rs.50 per case for ANC registration within 1st Trimester.”), and Amount claimed (Rs.) (right). Below the header, each beneficiary appears as one row containing: S.No (left); a beneficiary metadata block stacked vertically — Ben ID, Name, RCH ID, ABHA Number (centre, with N/A shown for any field the ASHA app has not populated); and Amount Claimed in ₹ (right, aligned). Rows are separated by a thin divider. The screen is strictly read-only — no buttons, checkboxes, or status chips on this view. Back navigation returns the Supervisor to the parent ASHA Monthly Detail screen with the same accordion state preserved. 

9.3.1 Activity Colour Coding  

Activity cards in the Supervisor application shall follow the same colour coding used in the Utprerona ASHA application to maintain visual consistency and improve verification efficiency. 

Colour Categories 

Implementation Notes 

• Colour must be driven from backend activity metadata. 

• Supervisor app must not hardcode colour mapping. 

• Colour should be applied to activity card background/header. 

9.4 Hamburger / Navigation Drawer 

A side navigation drawer is invoked by tapping the hamburger (☰) icon in the application header on the Home / Supervisor Dashboard. The drawer slides in from the left, covers approximately 75% of the screen width, and dims the underlying content with a translucent scrim. Tapping outside the drawer or the system back gesture dismisses it. 

Drawer header (top, fixed) 

• Profile avatar (circular, system-default illustration when no custom photo is set), aligned left. 

• “Name : <Full Name> <Role>” — for example, “Name : Preeti  ANM”. The role suffix (ASHA Supervisor / CHO / ANM) is appended to the name and is determined by the logged-in user’s role mapping. 

• “Username : <10-digit mobile number>” — the registered FLW mobile number used at login. 

• “User ID : <numeric system ID>” — the internal Utprerona / FLW user identifier (e.g., 4206). 

Menu items (grouped, in order, separated by a thin divider between groups) 

Group 1 — Primary navigation 

• Home — dismisses the drawer and navigates to the Supervisor Dashboard (Incentive Dashboard tab). 

• Profile — opens the read-only Supervisor profile screen (Name, Role, Employee ID, Mobile, Mapped sub-centres, ASHA count under this Supervisor). 

Group 2 — Utilities 

• Sync Records — triggers a manual sync of locally-cached incentive verification data with the server (used when the device has been offline). Shows a progress indicator and a success / failure toast on completion. 

• Create ABHA Number — deep link into the existing ABHA creation flow of the FLW application (out of scope for this module; entry point preserved here for parity with the wider FLW app menu). 

• Help & Support — opens a static help / FAQ screen with the support helpline number and email; content is owned by the program team. 

Group 3 — Account 

• Request to delete my account — opens a confirmation flow that submits an account-deletion request to the program admin team in compliance with DPDP / data-rights requirements. Deletion is not immediate; the request is routed for administrative action and the Supervisor is shown a tracking acknowledgement. 

• Logout — clears the session and returns the user to the FLW App login screen. Any unsynced local actions trigger a confirmation dialog before logout to prevent data loss. 

Footer: the bottom of the drawer shall display the current APK build version (e.g., “APK Version 2.9.17”) centred, in a muted style. The version string is read from the build manifest and is used for triage during support calls. 

1. Status Lifecycle

10.1 Activity-Level Status (Role-based) 

Each incentive-linked activity shall move through the following role-based verification statuses, which are visible to ASHA users: 

Note: Either CHO or ANM verification is required / applicable. 

10.2 Monthly ASHA Status (Derived) 

The monthly status for an ASHA shall be system-derived based on the verification state of all activities submitted for the selected month. 

Note: Monthly status is read-only and updated automatically by the system. 

1. Business & SystemLogic

1. Data & Audit Requirements

Audit Logging (Next phase/update can include the  

1. Security & Access Control

1. Supervisor can view only mapped ASHAs and sub-centres 

1. Role & geography enforced at API level 

1. Along with incentive claim data, the system shall transmit verifier metadata, including ASHA Supervisor, CHO, and ANM identifiers, as part of the API integration with the SSD portal to support auditability and downstream processing. 

1. Access to the module (Important):  

• Role-Based Access to Applications 

• Users with roles CHO, Medical Officer (MO/Doctor), Nurse, Pharmacist, Lab Technician, Registrar, or any combination of these roles, should have access to the HWC application. 

• Users with the CHO role must be able to log in to both FLW and HWC applications. 

• FLW App Access Control 

• Users with roles ASHA, ASHA Supervisor, or ANM should have access only to the FLW application. 

• In the FLW app: 

• Users with roles CHO, ASHA Supervisor, or ANM should have access only to Supervisor modules, and must not access ASHA comprehensive modules. 

• Users with the ASHA role should have access to all ASHA comprehensive modules, but not to Supervisor modules. 

1. Escalation & Reminder Mechanism (Please refer to User Journey on Page 3 for reference)

To ensure timely completion of incentive verification and prevent delays in downstream processing, the system shall implement an automated reminder and escalation mechanism. 

Please note: In Utprerona for ASHAs they should get reminder to fill out the claim information in accordance with the monthly set date set up by the Supervisor 

14.1 Supervisor Reminder Notifications 

Notification content (indicative): 
“X ASHAs have pending incentive verifications for Month YYYY. Please complete verification to avoid delays in payment processing.” 

14.2 Escalation to Medical Officer/Reporting Manager 

Escalation message (indicative): 
“Incentive verification for X ASHAs under Supervisor [Name] is pending for Month YYYY beyond the defined timeline. Kindly review and follow up.” 

Appendix A — End-to-End App Workflow (Revised) 

The diagram below shows the full Supervisor flow as specified in this revision of the BRD. It supersedes any earlier high-level user journey image in the document. Authentication and downstream CHO/ANM stages are shown for context; this BRD scopes only the Supervisor screens.