Health Privacy / Patient Data

Healthcare Startup Privacy

CA Nikhil Gupta·June 2026·3 min readHealth Privacy / Patient Data

Govern patient records, diagnostics, telemedicine and app access through clinical purpose, consent, emergency use, role controls, vendors, security and retention.

A healthcare app can become a diagnostic archive, communication tool and identity repository without the product team realising the cumulative risk.

Quick View

Decision

Map clinical, administrative, research and marketing purposes separately before collecting or sharing patient data.

First action

Map patient-data flows.

Core evidence

Patient notice and consent.

Main warning

Public report URLs.

Why It Matters

The Digital Personal Data Protection Act, 2023 and the final Rules notified in November 2025 follow phased commencement. As of 25 June 2026, organisations should separate duties already operative from consent, grievance, rights, children, Significant Data Fiduciary and other operational provisions scheduled for later commencement, while continuing to comply with the IT Act, CERT-In directions and sector-specific rules already in force.

The DPDP Act recognises specified medical-emergency and public-health uses, but those provisions do not create a general permission for unlimited secondary use.

CERT-In cyber directions already apply to covered body corporates, making incident triage, time-synchronised logs and 180-day log retention important.

Control Framework

AreaWhat to establishOperating rule
PurposeTreatment, diagnosis, billing, research or marketing.Separate clearly.
AccessClinician, support, laboratory and admin.Use role controls.
SharingHospital, lab, cloud and insurer.Secure and document.
EmergencyUrgent care versus routine use.Record basis.

Action Checklist

  1. Map patient-data flows.
  2. Separate clinical and support access.
  3. Review laboratory and cloud vendors.
  4. Secure image and report links.
  5. Create emergency-access logging.
  6. Test breach and patient-request workflows.

Practical Example

A diagnostics app sends public report links by SMS that remain accessible for months without authentication.

Evidence to Keep

  • Patient notice and consent.
  • Clinical-system access matrix.
  • Vendor contracts.
  • Link and authentication settings.
  • Incident logs.
  • Retention and deletion evidence.

Warning Signs

  • Public report URLs.
  • Support staff editing clinical data.
  • Research reuse without review.
  • Shared clinician accounts.
  • Medical records on personal devices.

Detailed Review

A reliable control should connect the individual, data field, purpose, notice or sector disclosure, system, employee access, vendor access, retention rule and closure evidence. A policy statement that cannot be traced through this chain is difficult to operate.

Maintain a legal-timing matrix. Record the DPDP provision, phased commencement status, current IT Act or sectoral duty, business owner, system dependency and implementation deadline. Avoid one blanket label such as compliant or not compliant.

Build controls into technology and workflow. A written instruction cannot stop an SDK from collecting contacts, a campaign tool from re-importing suppressed users or an agent from downloading medical records unless the system enforces the decision.

Use proportionate verification. Weak checks can expose another person’s information; excessive checks create more Aadhaar, health, payroll or bank data that must be protected and deleted later.

Generate evidence during ordinary operations: versioned screens, event logs, access approvals, vendor tickets, complaint chronology, deletion reports, test recordings and management decisions.

Segment access by role and lifecycle. Sales, support, teachers, clinicians, claims staff and external agents do not need the same information.

High-risk data should not move through personal messaging, unprotected links or shared credentials merely because those channels are convenient.

Control Test

Select one real user or transaction journey and trace it from collection through sharing, access, retention, withdrawal, complaint or closure. Capture the evidence at each stage.

Test the control on production-like systems rather than screenshots alone. Review network traffic, event logs, suppression status, vendor responses, role access and deletion output.

Run an adverse scenario: the vendor is breached, the user is a child, the borrower alleges harassment, the employee leaves or the app permission is revoked. Record the response and gaps.

Compare public wording with actual behaviour. Product forms, call scripts, privacy notices, contracts, SDKs and support tools should tell the same story.

Assign a named owner, funded action and closure date to each gap. Retain the reason when management accepts residual risk or chooses a less intrusive alternative.

Escalation Route

Start with the privacy, security, product or regulated-business owner and preserve system evidence before changing configuration or deleting records. Separate current sector and CERT-In obligations from future DPDP readiness.

For serious complaints, children’s data, financial harassment, medical exposure or suspected cybercrime, involve qualified legal, privacy, cyber, banking, insurance or healthcare specialists and use the applicable official channel.

Frequently Asked Questions

Can emergency data be processed without ordinary consent? â–¼
The Act recognises specified emergency and public-health uses, subject to the legal framework.
Should support teams see diagnoses? â–¼
Only where needed for a defined service task.
How should diagnostic links work? â–¼
Use authentication, expiry and access logging.
What should a breach plan include? â–¼
Clinical continuity, containment, evidence, CERT-In review, user impact and regulator coordination.