Health Data in AI: DPDP Requirements for Indian Healthcare Tech

Health Data Categories in Indian Context

India-specific health identifiers: ABHA (Ayushman Bharat Health Account) number — a 14-digit health ID. Health insurance IDs: Ayushman Bharat (PM-JAY) card numbers, private health insurance policy numbers. Hospital MRD numbers, lab report IDs, prescription IDs.

Health data content: diagnosis codes (ICD-10/11), procedure codes (CPT), medication names and dosages, lab values, vitals, imaging reports (DICOM metadata), discharge summaries, clinical notes.

ABHA Number Detection

ABHA format: 14 digits, created by the ABDM (Ayushman Bharat Digital Mission). Links all health records for an individual across hospitals. Example: 12-3456-7890-1234 (displayed with hyphens). Detection: 14-digit sequences, optionally with hyphens, adjacent to health keywords or in health API contexts.

ABHA is a high-sensitivity identifier — it's the key to an individual's complete health record. Access to an ABHA number + authentication allows retrieval of lifetime health records from the ABDM network. Treat with same sensitivity as Aadhaar.

AI in Healthcare: LLM Governance

LLM use cases in Indian healthcare: clinical note summarisation, diagnostic support, patient Q&A chatbots, drug interaction checking, health document parsing. All involve health personal data.

Redaction requirements before LLM API calls: patient name, ABHA number, hospital MRD number, Aadhaar (often included in patient records), mobile and email, diagnosis if not needed for the specific AI task. The test: would a reasonable clinician share this specific data with a third-party AI provider to accomplish this task? If no, redact it.

Data Types operational checklist

Health Data in AI: DPDP Requirements for Indian Healthcare Tech should be reviewed as an operating control, not only as a reference article. The minimum checklist is a data inventory, a stated processing purpose, owner approval, PII detection at the AI boundary, redaction or tokenisation where possible, retention limits, vendor transfer records, and a tested user-rights workflow. This checklist gives engineering and compliance teams a shared language for deciding what must be blocked, what can be allowed in shadow mode, and what needs human review before production release.

For AI systems, the review should include prompts, retrieved context, tool call arguments, model responses, logs, traces, analytics events, exports, and support attachments. Many incidents happen because teams scan only the visible form field while sensitive data moves through background context or observability tooling. CrewCheck's recommended pattern is to place the scanner at the request boundary, record the policy version, and keep audit evidence that shows which identifiers were detected and what action was taken.

A practical rollout starts with representative samples from production-like traffic. Run a DPDP scan, sort findings by identifier sensitivity and blast radius, fix Aadhaar, PAN, financial, health, children's, and precise-location exposure first, then move to consent wording, retention, deletion, and vendor review. Use shadow mode when false positives could disrupt users, and promote to enforcement only after the exceptions have owners and expiry dates.

This page is educational and should be paired with legal review for final policy interpretation. The operational proof should still come from repeatable evidence: scanner results, audit exports, pull-request checks, policy configuration, and a documented owner for the workflow. That combination is what makes the content useful during buyer diligence, board review, regulatory questions, or an incident investigation.