Document Revision History

Business Requirements Document

Document type: Business Requirements Document — one BR per proposed solution from the DPDP Gap Analysis tracker.
Companion documents: TBMJA DPDP Compliance Gap Analysis Report (evidence base); TBMJA DPDP Gap Analysis tracker, with Proposed Solution / Example columns (source for this BRD);
TBMJA Consent Evidence Options Review (detail on the "Set A" options referenced in BR-04, BR-05, BR-19).

Document Overview

This document sets out the business requirements for bringing the TB Screening mobile application, developed under TB Mukt Janjati Abhiyan (TBMJA), into compliance with the Digital Personal Data Protection (DPDP) Act, 2023 and the DPDP Rules. Each requirement (BR-01 to BR-21) matches one gap in the DPDP Gap Analysis tracker (GAP-01 to GAP-21), so the two documents can be read side by side.

Document Control

Problem Statement

TBMJA currently collects beneficiary name, gender, address, mobile number, and diagnostic/health details in TB screening camps without a proper DPDP-compliant consent mechanism — no itemised notice, no verifiable consent evidence, and no consent for minors' guardians. This exposes the live application to non-compliance under the Digital Personal Data Protection Act, 2023, which our Gap Analysis and BRD address with a phased plan to fix.

Abbrevations

1.1 Purpose

TBMJA collects beneficiaries' personal and health data during screening, testing, treatment tracking, contact investigation and reporting to Nikshay. This document exists to make sure that data is processed lawfully, transparently and securely. For each gap, it describes:

• the current state
• the proposed solution
• an illustrative example
• the confirmations still needed from Legal/Privacy, the Data Protection Officer (DPO), Security and the Programme team"

1.2 About feature

Adds DPDP-compliant consent capture to TBMJA — an itemised notice, verifiable consent evidence (Set A options), and guardian consent for minors — before any beneficiary data (name, gender, address, mobile, diagnostics) is collected. Ensures every beneficiary record has provable, auditable consent as required under the Digital Personal Data Protection Act, 2023.

Gap Analysis on TBMJA app vs consent process as per DPDP policy 

Summary Table

Detailed Business Requirements

BR-01 (GAP-01) Redesign Consent Notice to Itemise Data & Purpose

DPDP Reference: Rule 3(a)-(c) 
Current State (Gap): Single generic consent sentence with no itemisation of data/purpose and no rights/withdrawal/Board-complaint information (PRD §4.1).
Proposed Solution:
Add a dedicated "Notice" step to the existing multi-step registration flow, immediately before Personal Details, presenting itemised bullets of each data category collected and its specific purpose, in the language already selected at login. Include a static line covering the beneficiary's rights, the withdrawal path, and the route to complain to the Data Protection Board.
This is a content/UI change only — no new data model or backend logic — making it the fastest gap to close and a prerequisite for BR-04 (consent evidence) and BR-02 (consent scope) to be meaningful.
Given the application operates across multiple states, the notice content must be available in each state's primary language rather than English/Hindi alone (see BR-20). The notice must also state the consent-evidence data that may be collected — signature/thumb image, beneficiary photo, voice clip, video clip, and mobile number for OTP (see BR-04).
Illustrative Example: Instead of one generic sentence, the beneficiary sees:
"We collect your name, age, health symptoms, and location to

1. Screen you for TB,
2. Treat you if confirmed,
3. Report your case to the government TB programme (Nikshay)."

The same Agree/Disagree action follows.
Confirmation Needed: Legal/Privacy confirmation on final notice text

BR-02 (GAP-02) Define Consent Scope / Purpose-Level Consent

DPDP Reference: Act §6(1)-(3) 
Current State (Gap): A single blanket consent covers all downstream purposes (screening, treatment, counselling, contact tracing, dashboard reporting) with no purpose-level separation.
Proposed Solution:
Do not build purpose-segmented consent screens until Legal confirms whether TBMJA's processing basis is Data Principal consent (Act §6) or a "certain legitimate use" under Act §7(b)/(c) for the NTEP public-health programme — building the wrong architecture first would require rework. As a low-risk interim step, ensure the redesigned notice (BR-01) itemises every purpose clearly, so the consent instrument remains defensible under either basis pending that legal determination.
Illustrative Example: If Legal confirms a consent-based approach requiring purpose-level granularity, a beneficiary would see separate toggles — "screen me for TB," "treat me if I test positive," "share my case with Nikshay" — rather than one blanket consent.
Confirmation Needed: Legal basis confirmation (consent vs §7 legitimate use)

BR-03 (GAP-03) Implement Consent Withdrawal Mechanism

DPDP Reference: Act §6(4)-(6) 
Current State (Gap): No withdrawal mechanism exists anywhere in the application.
Proposed Solution:
Implement a staff-assisted "Withdraw Consent" action on the Beneficiary Card (available to Registration Officer, Counselling Officer, Admin) that sets a consent_status = Withdrawn flag with a timestamp on the existing record. Downstream modules check this flag and block new non-exempt data entry, while data already collected for active treatment continuity is retained under the applicable legal-retention exception. A full beneficiary-facing self-service withdrawal flow is deferred to a later phase; the staff-assisted version already satisfies the Act §6(4) right.
Illustrative Example: A beneficiary tells the Counselling Officer she no longer wishes to continue. The Officer opens her record, taps "Withdraw Consent," and the record displays "Consent Withdrawn — 12 Oct"; no further screening data can be entered against it. We need to take withdraw reason while deleting the data and only keeping the beneficiary id and with consent details.

Confirmation Needed: Confirm operational meaning of withdrawal for a public-health screening record

BR-04 (GAP-04) Consent Evidence Capture ("Set A" Options)

*DPDP Reference:* Act §6(10) *Priority:* High | *Change Type:* Database/Backend change | *Owner:* Engineering
*Current State (Gap):* No consent metadata (timestamp, version, evidence type, language, device ID) is stored; the Fiduciary cannot currently prove notice and consent were given, per Act §6(10).
*Proposed Solution:*
Once the beneficiary selects "Agree" on the consent notice (BR-01), capture consent evidence using any ONE of the options below. The Registration/Counselling Officer selects the option based on the beneficiary's ability and preference and on ground availability (network, device camera, beneficiary mobile phone). Only one option is required per consent.
*Option A2 — Signature/Thumb mark + photo:* The app enables signature or thumb-impression capture on the device screen and enables the camera to take a photo/image of the beneficiary alongside it.
*Option A3 — Voice consent clip:* The notice is read aloud and the beneficiary records a short voice clip stating that he/she agrees/acknowledges. The clip is stored in the backend against the consent_record with its metadata (fields below).
*Option A4 — Opportunistic OTP:* When network is available and the beneficiary has a mobile phone, an OTP is sent to the beneficiary's mobile number; entering it authenticates the consent.
*Option A5 — Short video clip (last resort):* Used for consent only when none of A2–A4 is possible. The app enables the camera to record a short video (~1–3MB) in which the beneficiary states his/her name and agrees to data sharing. A5 is not used for routine registrations or other moments such as treatment initiation.
*Fallback — Option A1 (Assisted Acknowledgement):* If none of A2–A5 can be completed (e.g., no camera, no network or device constraint), the beneficiary personally taps "I agree". A1 introduces no new data type and works fully offline.
*consent_record fields:* One consent_record per consent, with the same structure whichever option is used:
*Identity & notice —* consent_id, beneficiary_id, consenting_party (Beneficiary/Guardian), guardian_name, guardian_relationship, notice_version, language, consent_decision (Agree/Disagree).
*Evidence —* evidence_type (A1–A5), signature_image_ref, photo_ref, voice_clip_ref, voice_duration_sec, video_ref, video_duration_sec, artefact_hash (SHA-256 per file), artefact_size.
*OTP —* mobile_number_masked, mobile_ownership (Own/Shared), otp_sent_at, otp_verified_at, otp_status (Verified/Failed/Skipped – no network), otp_attempts.
*Audit & sync —* captured_by_user_id, device_id, camp_facility_id, captured_at (device timestamp), synced_at, sync_status, retention_until (BR-09), withdrawal_status (BR-03).
Media artefacts (signature/thumb image, photo, voice clip, video) are stored encrypted on the device until sync and then in backend storage referenced from the consent_record, not embedded in it (see BR-08, BR-09). Because Options A1 and A3 involve the notice being read aloud or spoken, the underlying script must be available in each relevant state language (see BR-20).
*Illustrative Example:* At a village camp with no network, a beneficiary who cannot sign legibly chooses A3: she records "I, \[na<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="6d94d11d-4d73-4f28-82c0-6f2c06a6ff30"><ac:parameter ac:name="">_GoBack</ac:parameter></ac:structured-macro>me\], agree to share my data" and the clip is saved with timestamp and device ID, syncing later. At a better-connected camp, a beneficiary with her own phone completes A4 (OTP) instead. Only if none of A2–A4 is workable is a short video (A5) recorded; if even that is not possible, she taps "I agree" (A1).
*Confirmation Needed:* Legal confirmation that any one option (A1–A5) is sufficient evidence under Act §6(10); Security/Legal confirmation of storage, encryption and retention of photo, signature, voice and video artefacts (BR-08, BR-09)

BR-05 (GAP-05) Verifiable Guardian Consent for Child Beneficiaries

DPDP Reference: Rule 10(1)-(2) 
Current State (Gap): Beneficiaries under 18 are screened (paediatric-specific TB symptom questions exist in the PRD) with no guardian identification or verifiable-consent workflow.
Proposed Solution:
Reuse the Set A pattern (BR-04) rather than building a second consent mechanism. Add a "Who is consenting: Beneficiary / Guardian" field to the consent_record; when beneficiary age is under 18, the same A1–A5 options are performed by the guardian instead of the child.
Phase 1 — Guardian completes any one of the BR-04 options on the child's behalf (A2–A4 as per availability, A5 only as last resort, A1 as fallback) plus a simple guardian-identity field (name, relationship to child). For A2 the signature/thumb and photo are the guardian's; for A4 the OTP goes to the guardian's mobile number.
Phase 2 — Add guardian-ID due-diligence verification (Rule 10(1)(a) reliable existing ID, or Rule 10(1)(b) virtual token/DigiLocker) once Legal confirms which pathway is operationally realistic in a field-camp setting.
Illustrative Example: A 14-year-old beneficiary is brought in by her mother. The app asks "Is this beneficiary under 18?" — Yes — and then prompts the mother, not the child, to give consent using one BR-04 option (e.g., signing and being photographed — A2) and to provide her name and relationship, before screening proceeds.
Confirmation Needed: Legal/DPO confirmation on which Rule 10(1)(a)/(b) pathway is operationally feasible in a field-camp setting

BR-06 (GAP-06) Guardian Consent for Persons with Disability (Conditional)

DPDP Reference: Rule 11 
Current State (Gap): No disability-status field or lawful-guardian workflow is documented anywhere in the PRD.
Proposed Solution:
Confirm with Product/Clinical whether disability status is captured, or planned to be captured, at all. If not currently in scope, document that fact and take no further action. If disability status is introduced in a future release, reuse the same guardian-consent pattern established in BR-05 rather than building a separate mechanism.
Illustrative Example: If a future release adds a "does this beneficiary have a disability requiring a lawful guardian" question and the answer is yes, the same guardian-consent screen used for children (BR-05) would apply.
Confirmation Needed: Confirm whether disability data is in scope at all

BR-07 (GAP-07) Breach Response SOP & Notification Workflow

DPDP Reference: Act §8(6); Rule 7 
Current State (Gap): No breach-detection, escalation, or notification workflow is documented.
Proposed Solution:
Treat this as an organisational-process deliverable before any product build. Security and Legal jointly draft a breach-response runbook covering: what is communicated to affected Data Principals ("without delay," per Rule 7(1)), and what is reported to the Data Protection Board within 72 hours of becoming aware of the breach (Rule 7(2)), including the specific content each notification must contain. Only once the runbook exists should a supporting in-app or Admin-panel "report a suspected incident" capability be scoped.
Illustrative Example: If a camp laptop containing beneficiary records is lost, the runbook specifies exactly who must be notified (affected beneficiaries and the Data Protection Board) and within what timeline — a gap that exists today with no defined process at all.
Confirmation Needed: DPO/Legal confirmation of breach-response ownership

BR-08 (GAP-08) Security Safeguards Encryption, Access Control, Transport

DPDP Reference: Rule 6(1) 
Current State (Gap): Device binding, PIN/OTP authentication, and offline-sync queuing are documented; encryption at rest, and encryption in transit on the local camp Wi-Fi/LAN segment (documented as HTTP in the architecture diagram), are not confirmed.
Proposed Solution:
Before any build, obtain two factual confirmations from Infra/Engineering: (1) whether the local camp Wi-Fi/LAN is a closed/isolated network that may serve as a compensating control, or requires a TLS/encryption upgrade; (2) the current at-rest encryption status of the Local Server and AMRIT. Where either confirmation reveals an actual gap, scope the remediation (e.g., TLS certificate management for offline camp infrastructure) as a discrete Security/Infra ticket rather than a blanket redesign. Consent-evidence media from BR-04 (signature/thumb image, beneficiary photo, voice clip, video) must be encrypted at rest on the device and server and in transit during sync, with access restricted to authorised roles.
Illustrative Example: If IT confirms the camp laptop's Wi-Fi is genuinely closed and isolated from external access, that can be documented as the compensating control instead of requiring a costly encryption retrofit across every camp.
Confirmation Needed: Security team confirmation of current encryption posture

BR-09 (GAP-09) Define a Data Retention Schedule

DPDP Reference: Rule 8; 
Current State (Gap): No retention period is defined for any TBMJA data category.
Proposed Solution:
Treat this primarily as a policy exercise, not an engineering task, at the outset. Legal and Product jointly produce a single retention table mapping each data category (per the Gap Analysis's Data Inventory) to a proposed retention period, cross-checked against any minimum retention already mandated by other applicable health-record laws for TB/NTEP data. Once that table is approved, the technical enforcement (scheduled erasure job, Rule 8(2) 48-hour pre-erasure notice where applicable) is a comparatively simple build. The retention table must include separate entries for consent-evidence media (signature/thumb image, photo, voice clip, video) captured under BR-04.
Illustrative Example: The finalised table might specify "TB treatment records — retain 3 years after treatment ends" but "consent-evidence clips — retain only 1 year," reflecting that different data categories warrant different retention.
Confirmation Needed: Legal/DPO confirmation of legally mandated minimum retention (health records under other laws may override)

BR-10 (GAP-10) Build a Functioning Erasure-Request Workflow

DPDP Reference: Act §12(3) 
Current State (Gap): "Request to delete account" exists only as a menu label with no underlying workflow.
Proposed Solution:
Convert the existing label into a functioning, manually-processed workflow in the first instance: a request lands in an Admin queue; Admin verifies the request and checks it against the retention exceptions defined in BR-09 before erasing the record and logging the decision either way. Full automation of this workflow can follow once the retention schedule (BR-09) is finalised.
Illustrative Example: A beneficiary requests erasure. Admin confirms she is not currently under active TB treatment (which would need to be retained) and deletes her record, logging the outcome.
Confirmation Needed: Legal confirmation on exceptions applicable to public-health data

BR-11 (GAP-11) Provide a Data Principal Access-Request Channel

DPDP Reference: Act §11 
Current State (Gap): No in-app or documented manual channel exists for a Data Principal to request a summary of their data or processing activity.
Proposed Solution:
Given beneficiaries are unlikely to have ongoing digital access to TBMJA after a camp concludes, start with a manual/offline channel — a published phone number or email that a beneficiary or their family can use to request a data summary — rather than building in-app self-service. Revisit an in-app feature only if request volume through the manual channel justifies the investment.
Illustrative Example: A beneficiary's family calls the published helpdesk number months later to ask what data was recorded about her; staff retrieve the record and provide a summary over the call.
Confirmation Needed: Confirm channel (in-app vs. manual/offline SOP) appropriate for beneficiary population

BR-12 (GAP-12) Publish DPO Contact & Build Grievance Tracking

*DPDP Reference:* Act §13; Rule 9 *Priority:* High | *Change Type:* Product + Governance | *Owner:* Product + Legal
*Current State (Gap):* A generic "Support" menu label exists with no DPO/contact-person publication and no grievance logging, tracking, or SLA.
*Proposed Solution:*
Once a DPO or responsible contact person is named, replace the generic "Support" label with their published name and contact details on the notice screen and in the persistent menu location (a content-only change, deployable immediately). In parallel, add a basic grievance-submission form that logs to a shared inbox/tracking sheet and returns the submitter a unique reference number; a fuller ticketing system can be layered on later once volume justifies it.
*Illustrative Example:* Instead of tapping "Support" and finding no useful information, a user sees "Contact our Data Protection Officer: \[Name\], \[phone/email\]" and can submit a grievance that returns "Reference #GRV-00042."
*Confirmation Needed:* Confirm appointed DPO/contact-person identity

BR-13 (GAP-13) Evaluate the Right to Nominate

DPDP Reference: Act §14 
Current State (Gap): No nomination capability exists; the PRD does not document this right at all.
Proposed Solution:
Confirm operational relevance with the NTEP/Programme team before building anything — specifically, whether allowing a beneficiary to nominate someone to exercise their rights on death/incapacity is a meaningful need for this beneficiary population. If not considered relevant, document that rationale and defer the feature; build only if the programme team indicates genuine need.
Illustrative Example: This would let a beneficiary state, "if something happens to me, let my son handle my TB records" — plausible but not confirmed as a common need in this context, warranting a quick check with the field team before investing engineering effort.
Confirmation Needed: Confirm relevance for the beneficiary population/context

BR-14 (GAP-14) Confirm Data Processor Contracts (DPAs)

DPDP Reference: Act §8(2); Rule 6(1)(f) 
Current State (Gap): No evidence of signed Data Processor Agreements with AMRIT, Nikshay, ABDM, or the X-ray/NAAT device vendors, nor of Rule 6(1)(f) security-safeguard clauses within them.
Proposed Solution:
Treat this as a document-retrieval and review exercise for Legal/Programme, not an engineering task. Obtain copies of existing contracts with each integration partner and check each against the Rule 6(1)(f) security-clause requirement. Where a contract already contains adequate clauses, this item can be closed on paper; where one is missing or silent, escalate as a contract-remediation action.
Illustrative Example: If the existing AMRIT contract is found to already include an adequate data-security clause, this gap may close immediately with no further action required.
Confirmation Needed: Confirm existence and content of current contracts

BR-15 (GAP-15) Confirm Hosting Location / Cross-Border Position

*DPDP Reference:* Act §16 *Priority:* Medium | *Change Type:* Governance Change | *Owner:* Engineering/Legal
*Current State (Gap):* The hosting location of the AMRIT central server is not documented.
*Proposed Solution:*
Resolve with a single factual question to the team owning AMRIT infrastructure — where is the central server physically hosted? If confirmed as India-hosted, this item likely closes without further action; if hosted elsewhere, escalate to Legal for an Act §16 cross-border assessment.
*Illustrative Example:* A confirmation such as "AMRIT is hosted on \[cloud provider\], India region" would close this item with no further action needed.
*Confirmation Needed:* Confirm hosting jurisdiction

BR-16 (GAP-16) Determine Significant Data Fiduciary (SDF) Status

DPDP Reference: Act §10; Rule 13 
Current State (Gap): SDF status of TBMJA's operating entity or NTEP is undetermined from available documentation.
Proposed Solution:
Resolve with a single confirmation question to Legal/Programme — has the Central Government notified TBMJA's operating entity, or the NTEP programme, as a Significant Data Fiduciary? If not, no DPIA/annual-audit process needs to be built at this time; revisit if beneficiary volume or programme scale grows materially.
Illustrative Example: Legal checks the MeitY-notified list and confirms the entity is not on it; this is documented and the item is closed, subject to periodic re-review.
Confirmation Needed: Central Government SDF notification status

BR-17 (GAP-17) Implement User-Level Access & Audit Logging

DPDP Reference: Rule 6(1)(c),(e) 
Current State (Gap): Only a sync-status indicator (Pending/Synced/Failed) is documented; no user-level record-access logging exists.
Proposed Solution:
Implement logging incrementally rather than for every read event, to protect offline-sync performance.
Phase 1 — Log only the highest-risk actions: editing a health-record field, exporting to Nikshay, and any full-record view by an Admin user, capturing user ID, action, record ID, and timestamp.
Phase 2 — Expand coverage once the performance impact of Phase 1 logging is measured and understood.
Illustrative Example: If a user edits a beneficiary's TB test result, the system logs who made the change and when — without logging every incidental scroll past a beneficiary's name in a list view.
Confirmation Needed: None beyond implementation confirmation

BR-18 (GAP-18) Review and Scope Admin Role Access

DPDP Reference: Act §8(4) / data minimisation principle 
Current State (Gap): The Admin/NTEP/STOP TB role is documented as having "full access… all data — district and national level," with no further scoping described.
Proposed Solution:
Before any RBAC re-engineering, conduct a short structured conversation with two or three actual Admin users to establish whether unscoped, all-India access is genuinely used in practice, or whether Admins only ever operate within their own district/state. If usage is confirmed to be regionally bounded, scope the role accordingly (e.g., separate "State Admin" and "National Admin" roles); if genuinely necessary, document the operational justification instead of restricting access unnecessarily.
Illustrative Example: If a State-level Admin confirms she never views data outside her own state in practice, the role could be split into "State Admin" and "National Admin" with correspondingly different data scopes.
Confirmation Needed: Confirm operational necessity of unscoped Admin access

BR-19 (GAP-19) Notice/Acknowledgement for Contact-Tracing Subjects

DPDP Reference: Act §8; general fair-processing principle 
Current State (Gap): Household, community, and occupational contact-tracing data is captured with no notice or acknowledgement mechanism for the contact individual.
Proposed Solution:
Extend the Set A pattern (BR-04) to this touchpoint, but restrict it to Option A1 only — the Counselling Officer delivers a brief spoken notice to the contact and records an "Acknowledged" tap before saving the contact record. Signature, voice, and video evidence are deliberately excluded here to avoid slowing down a time-sensitive, already-multi-question field workflow for an individual who is not the primary beneficiary.
Illustrative Example: The Counselling Officer tells a household contact, "We're noting your details because you may have been exposed to TB," and taps "Acknowledged" before saving — a fast, low-friction step.
Confirmation Needed: Legal confirmation on applicable basis (consent vs. public-health legitimate use under §7(g)/(h))

BR-20 (GAP-20) Expand Multi-Language Notice & Consent Coverage

DPDP Reference: Act §5(3) 
Current State (Gap): Login and registration are documented as English/Hindi only, with broader Indian-language support noted as "configurable… as required in future." TBMJA's actual deployment footprint spans 11 states, meaning English/Hindi coverage is very likely insufficient for a material share of beneficiaries.
Proposed Solution:
Obtain the confirmed list of the 11 operating states from the Programme team and derive the corresponding set of primary languages required. Prioritise translation of the notice (BR-01) and consent-evidence scripts (BR-04's A1/A3 options) for the languages of states where camps are currently live, and add further Eighth Schedule languages incrementally as the programme expands to new states, rather than attempting to localise all languages upfront. This finding should also be flagged to Legal, since "Hindi/English only, more later" is a materially weaker position once the actual 11-state footprint is accounted for.
Illustrative Example: If the 11 states include, for instance, Bihar, West Bengal, and Tamil Nadu, then Hindi, Bengali, and Tamil would be required at minimum for consent/notice screens to be genuinely understandable to beneficiaries in those states — not English/Hindi alone.
Confirmation Needed: Legal confirmation on minimum acceptable language coverage at present rollout

BR-21 (GAP-21) Add an Accuracy-Confirmation Step Before Export

DPDP Reference: Act §8(3) 
Current State (Gap): Most fields are editable, but no explicit accuracy-confirmation checkpoint exists immediately prior to the Nikshay export step.
Proposed Solution:
Add a lightweight "Review & Confirm" screen immediately before the "Generate Nikshay ID" action, displaying a read-only summary of the key fields being exported (name, age, test results) and requiring an explicit confirmation tap from the Registration Officer/Camp Coordinator before the export proceeds.
Illustrative Example: Before hitting "Generate Nikshay ID," the Camp Coordinator sees a summary screen and taps "Confirm & Send," rather than the export happening silently in the background.
Confirmation Needed: None