Patient Data Privacy in India: What DISHA Means for Your Clinic

If you run a clinic or hospital in India, patient data privacy is no longer just "a good practice" — it's becoming a legal obligation. The Digital Information Security in Healthcare Act (DISHA) is India's healthcare-specific data protection framework, and it fundamentally changes how you must handle patient information.

But here's the problem: most resources about DISHA are either 80-page legal documents or vague vendor marketing pages that say "we're DISHA-compliant" without explaining what that means for your daily operations. This article bridges that gap.

What is DISHA?

DISHA — the Digital Information Security in Healthcare Act — is India's proposed legislation governing digital health data. While the full act is still evolving through parliamentary process (alongside the broader Digital Personal Data Protection Act, 2023), the National Health Authority (NHA) has already incorporated many DISHA principles into ABDM guidelines that healthcare facilities must follow today.

Think of DISHA as the healthcare-specific layer on top of India's general data protection framework. Just as HIPAA in the US goes beyond general privacy law to address healthcare-specific concerns, DISHA goes beyond the IT Act 2000 and SPDI Rules to address the unique sensitivity of health records.

Why it matters now: Even before full legislative enactment, ABDM compliance requirements, CERT-In healthcare guidelines, and the Digital Personal Data Protection Act (DPDPA) 2023 together create a framework that closely mirrors DISHA's intent. If you're handling digital patient records — which you are if you use any HMS, EHR, or even a computerized billing system — these rules apply to you today.

The core principles of DISHA

1. Patient consent is mandatory

You cannot collect, store, or share patient health data without explicit consent. This isn't the "implied consent" of a patient walking into your clinic. This is documented, specific consent for digital data handling.

What this means practically: - At registration, inform the patient what data you collect and why - Get consent before sharing records with other providers (even for referrals) - Allow patients to revoke consent and request data deletion - Maintain a consent log — who consented, when, for what purpose

How ABDM implements this: The ABDM consent manager handles consent for health record sharing on the network. When another provider requests a patient's records, the patient receives a consent request and must explicitly approve it. Your HMS needs to support this workflow.

2. Purpose limitation

You can only use patient data for the purpose it was collected. If a patient shares data for treatment, you cannot use it for marketing, research, or sale to third parties without separate consent.

Common violations clinics don't realize they're committing: - Sending promotional WhatsApp messages to patients who consented only to appointment reminders - Sharing patient data with pharmaceutical representatives - Using patient data for social media testimonials without written permission - Allowing non-clinical staff to browse patient records out of curiosity

3. Data minimisation

Collect only the data you need. A general OPD consultation doesn't require the patient's Aadhaar number, income details, or emergency contact's occupation. Collect what's clinically necessary and nothing more.

Practical tip: Review your patient registration form. If there are fields that don't serve a clinical or billing purpose, remove them. Every unnecessary data field is a liability.

4. Security safeguards

DISHA requires "reasonable security practices" for digital health data. The IT Act 2000 and SPDI Rules define these as:

• **Encryption:** Patient data must be encrypted in transit (HTTPS) and at rest (AES-256 or equivalent)
• **Access control:** Role-based access — a receptionist shouldn't see clinical notes, a lab technician shouldn't see billing records
• **Audit trails:** Every access to patient data must be logged — who viewed what, when
• **Auto-logoff:** Sessions on shared devices must time out after inactivity
• **Unique user IDs:** No shared logins. Every staff member must have their own credentials

The shared computer problem: Many clinics use shared logins — one "reception" password for the front desk, one "doctor" password for the consultation room. Under DISHA, this is a violation. Every individual who accesses patient data needs their own login and every access must be attributable to a specific person.

5. Breach notification

If patient data is compromised — whether by hacking, accidental exposure, or staff misconduct — you must:

1. Notify CERT-In (Indian Computer Emergency Response Team) within 6 hours of discovering the breach 2. Notify affected patients "without unreasonable delay" 3. Document the breach, its scope, and the remediation steps taken

Sobering reality: A "breach" includes a staff member accessing a patient's records without authorization, a laptop with patient data being stolen, or patient records being accidentally visible on a screen in a public area. It's not just hacking.

What this means for your clinic — a practical checklist

Here's a plain-language checklist every Indian clinic and hospital should work through:

Access control - [ ] Every staff member has their own login (no shared "reception" or "doctor" passwords) - [ ] Access is role-based: reception sees registration + billing, doctors see clinical records, lab staff sees lab orders - [ ] Former employees' access is deactivated on their last working day - [ ] Audit log shows who accessed which patient record and when

Consent - [ ] Patient registration includes a consent statement for digital data storage - [ ] Separate consent for WhatsApp/SMS communication - [ ] ABDM consent manager integrated for health record sharing - [ ] Process exists for patients to request their data or ask for deletion

Data storage & security - [ ] Patient data encrypted at rest and in transit - [ ] Data stored in India (AWS Mumbai, Azure Central India, or equivalent) - [ ] Regular backups with tested recovery procedures - [ ] Session timeout on shared devices (30-60 minutes of inactivity) - [ ] No patient data on personal devices unless the device has PIN/biometric lock

Physical security - [ ] Screens at reception not visible to other waiting patients - [ ] Printouts with patient data shredded, not thrown in regular trash - [ ] Server room / computer area access restricted - [ ] No patient data written on whiteboards visible from public areas

Breach readiness - [ ] Designated person responsible for data security (even in a small clinic, assign someone) - [ ] CERT-In reporting procedure documented - [ ] Contact details for CERT-In incident reporting accessible to the designated person - [ ] Annual review of security practices

Common misconceptions

"DISHA only applies to digital records. We're safe because we also keep paper files."

Wrong. If you have any digital patient data — even just a computerized billing system with patient names — DISHA-equivalent rules apply to that digital data. Paper records have separate handling requirements under the Clinical Establishments Act.

"We're a small clinic. Nobody will audit us."

Possibly true today. But patient complaints trigger investigations, and all it takes is one disgruntled patient filing a complaint about unauthorized data sharing. Also, as ABDM adoption grows, compliance requirements will be enforced through the network.

"Our HMS vendor says they're DISHA-compliant, so we're covered."

Your vendor's compliance covers their infrastructure — encryption, server security, data hosting. But compliance with DISHA also depends on how you use the system. If you share logins, access records without purpose, or use patient data for unauthorized marketing, your vendor's compliance doesn't protect you.

"WhatsApp is encrypted, so sending patient data via WhatsApp is fine."

WhatsApp is end-to-end encrypted, but sending patient data via personal WhatsApp (not through a WhatsApp Business API integration with consent management) doesn't meet the audit trail and consent requirements. You need to track what was sent, to whom, when, and with what consent.

How MedOS helps with DISHA compliance

MedOS is built with Indian data privacy requirements at its core:

• **Role-based access control (RBAC):** Each staff member has individual login with access limited to their role
• **OTP-based authentication:** No shared passwords; each login is tied to a personal mobile number
• **Complete audit trail:** Every patient record access is logged with user ID, timestamp, and action
• **Encryption:** AES-256 at rest, TLS 1.3 in transit
• **Data hosted on AWS Mumbai (ap-south-1):** Patient data never leaves India
• **Session management:** Configurable auto-logoff on shared devices
• **ABDM consent manager integration:** Patient consent for record sharing handled through the ABDM framework
• **Data export and deletion:** Patients (and clinics) can export or request deletion of records

DISHA compliance isn't just about software — it's about processes and people. But having an HMS that enforces the right technical controls makes it significantly easier to stay compliant.

Start preparing now

DISHA in its final form may still be a year or two away. But the underlying principles — consent, access control, encryption, audit trails — are already enforceable under CERT-In guidelines, the DPDPA 2023, and ABDM requirements. Start now, and full DISHA compliance will be an incremental step rather than a scramble.

Try MedOS free for 14 days at [med-os.in](https://med-os.in) — built for Indian data privacy requirements from day one. No credit card needed.