DPDP Patient Consent & Care Communications

Consent in healthcare isn’t a one-time checkbox. It’s a patient trust workflow—across registration, clinical care, diagnostics, billing, telemedicine, and follow-ups.

The Compliance Requirement

Bridging the Compliance Gap

Healthcare organisations collect and use personal data across many touchpoints—front desk registration, EMR/EHR, lab and radiology, pharmacy, TPAs/insurers, and patient engagement tools. Under DPDP Rules, your notice must be understandable on its own and written in clear, plain language, and it must enable patients to give specific and informed consent by clearly stating (at minimum) the itemised personal data you process and the specified purposes of processing. It must also provide an easy way to withdraw consent, exercise rights, and complain to the Board.

Who this page is for

This guide is relevant for:

  • Hospitals & clinics (OPD/IPD, diagnostics, billing, patient portals)
  • Telemedicine platforms (video consults, chat, prescriptions, follow-ups)
  • Labs & imaging centres (collection, reporting, sharing with doctors/hospitals)
  • Healthcare SaaS vendors serving hospitals (HIS/LIS/PACS/CRM/call center tools)

What DPDP expects

Before asking for any consent, show a DPDP notice that:

  • stands alone (not buried inside long terms)
  • is in clear, plain language
  • includes itemised personal data and specified purposes
  • tells the patient how to withdraw consent, exercise rights, and complain to the Board

Consent withdrawal must be as easy as giving consent—not a call-center-only process and not “email us and wait.” Build a visible withdrawal method in the app/portal or a comparable offline mechanism (like a simple form + tracking).

To enable rights requests, you should prominently publish the means of making requests and what identifiers are needed to identify the patient. Also publish a grievance response timeline not exceeding 90 days, supported by operational measures to actually meet it.

Practical consent flows for Healthcare

Case 1: Patient registers at OPD front desk (walk-in)

  • Show a short notice at registration (QR + poster + tablet screen) stating what data is collected and why.
  • Capture consent for non-clinical optional purposes separately (e.g., marketing/health tips).
  • Provide a simple withdrawal method (QR link + reception support) that is as easy as the registration capture.

Case 2: Patient books online + teleconsultation

  • Show a “just-in-time” notice at:
    • account creation / OTP verification
    • before video consult starts
    • before storing recordings (if any)
    • before sharing prescription/lab orders
  • Provide a patient dashboard for withdrawing optional consents and managing communication preferences.

Case 3: Doctor orders lab tests / imaging (lab is a separate entity)

  • Inform the patient that data will be shared with the lab/imaging provider for the diagnostic purpose.
  • Capture consent if it’s beyond what the patient would reasonably expect for care coordination (e.g., using lab data for analytics/marketing).
  • Ensure the lab/vendor is covered in your vendor map and contracts (security safeguards).

Case 4: Billing + TPA/Insurance processing

  • Clearly explain what data is shared with TPAs/insurers, and why (claims processing, authorisation).
  • Provide a clear contact point for patient questions about processing (DPO or authorised person).

Case 5: Follow-ups, reminders, WhatsApp/SMS

  • Treat WhatsApp/SMS reminders as a communication channel choice.
  • Allow patients to opt-in/opt-out of:
    • appointment reminders (service)
    • health education content (optional)
    • offers/camps/promotions (optional)
  • Make opt-out fast (link + “STOP” flow + portal toggle), comparable to opt-in.

UX design: what your consent screen must include

A) Give a clear DPDP notice before asking for consent

Your notice should include:

  • an itemised list of personal data you collect/process (at least at a category level)
  • specific purposes (treatment, diagnostics, billing, records access, etc.)
  • how to withdraw consent, exercise rights, and complain to the Board
  • the link to your app/portal page where these actions can be taken

B) Best practice for healthcare: “just-in-time” notices

Show short, contextual notices at the moment of processing:

  • before video consult starts
  • before sharing data with a lab/TPA
  • before collecting government ID details (if applicable)
  • before enabling marketing/health campaigns
  • before storing recordings (if used)

What to store (for each patient record / consent event)

  • Patient identifier (MRN / patient ID)
  • Timestamp + channel (front desk / app / web / call center)
  • Notice version shown (version ID)
  • Consent choices (treatment coordination vs optional communications)
  • Withdrawal history (if changed later)
  • Purpose tags for each consent
  • Source of data sharing (lab/TPA/vendor name, if relevant)
  • Audit trail/log reference (for accountability + investigations)

Technical Implementation Blueprint

Data Model (suggested)

  • Patient (patient_id, identifiers, contact_methods)
  • ConsentNotice (notice_id, version, language, published_at)
  • ConsentEvent (event_id, patient_id, notice_id, purpose_tags, choices, channel, timestamp, actor)
  • CommunicationPreference (patient_id, sms_opt_in, whatsapp_opt_in, email_opt_in)
  • DisclosureRecord (patient_id, vendor_id, purpose, timestamp, reference)
  • AuditLogPointer (event_id, log_ref, retained_until)

API Endpoints (sample)

POST /patient/consent (capture consent event)

POST /patient/consent/withdraw (withdraw/update)

GET /patient/consent/status

GET /privacy/notices/current

POST /rights/request (rights portal integration)

POST /grievance (ticket + SLA tracking)

Operational controls (must-have)

  • Role-based access for staff and vendors
  • Logging + monitoring for detection and investigation of unauthorised access
  • Vendor contracts with security safeguard obligations
  • Backup/availability planning for continuity DPDP Rules
  • Prominent publishing of rights request mechanisms and grievance SLA (≤ 90 days)

Compliance checklist

Consent & notice

  • Notice is plain-language, standalone, and purpose-specific
  • Withdrawal is as easy as giving consent
  • “Just-in-time” notices exist for high-impact moments (telemedicine, lab sharing, outreach)

Rights & grievance

  • Rights request mechanism is prominently published
  • Grievance response timeline is published (≤ 90 days)
  • Contact info for patient queries is clear (DPO/authorised person)

Security & vendor controls

  • Encryption / access controls / monitoring in place
  • Logs retained and reviewed; vendor contracts include safeguards
  • Breach playbook exists (patient + Board intimation readiness)

FAQ

Usually not. Use layered notices and separate optional communications from core care coordination to keep consent meaningful and defensible.

Reminders tied to service delivery are different from promotional outreach. Keep patient communication preferences clear and offer easy opt-out for optional content.

Support caregiver-managed access carefully, and document who performed consent actions and why (with clear audit trails).

You need a clear mechanism to submit rights requests and a grievance system with a published timeline (≤ 90 days). A portal is the cleanest approach for scale.

Treat them as processors/sub-processors in your map and ensure contracts include security safeguard obligations and incident cooperation.

Need this flow built quickly?

We can design your patient notices, consent screens, preference controls, and consent ledger schema—aligned to DPDP Rules.

Get the Tech Specs