DPDP Act 2023 Compliance for Indian Clinic PMS: 8 Architecture Checks Every Owner Should Run

The Digital Personal Data Protection Act 2023 came into force in 2024 without a healthcare-specific carve-out. Patient data is personal data under the Act, and Indian clinics are Data Fiduciaries with statutory obligations. Most PMS systems installed at Indian clinics today were built before DPDP and bolted on consent capture afterwards — which is not the same as being architecturally compliant.

This article is the 8-check architecture audit every clinic owner should run on their current PMS — and the remediation steps when checks fail.

Why architecture compliance matters more than policy compliance

A PMS that has a "DPDP-compliant" checkbox on its marketing page but stores data outside India, lacks deletion workflow, or has weak access controls is exposing the clinic to:

1. Statutory fines. Up to ₹250 crore per breach under DPDP.
2. Breach notification obligation. 72-hour notification to the Data Protection Board for any data breach. If the PMS lacks access logging, you cannot meet this.
3. Patient deletion rights. Patients can request deletion. If the PMS lacks deletion workflow, you cannot honour the request — itself a violation.
4. Cross-border data flow restrictions. Patient data leaving India without explicit consent is a violation. Many global cloud-hosted PMSs run afoul of this.

The 8 architecture checks

Check 1: India-based hosting

The check: Where is the patient data physically stored?

The standard: India-based servers (Mumbai, Hyderabad, Bangalore, Chennai availability zones). Patient data does not cross borders by default. International patient records require explicit cross-border consent stored at the record level.

Common failure: Cloud-hosted PMS using US or EU regions for cost reasons. The clinic owner often doesn't know.

Remediation: Ask your PMS vendor for written confirmation of data hosting region. If outside India, request migration to India region (most vendors support this) or migrate to a DPDP-compliant alternative like HealthPro 360.

Check 2: Consent capture at every entry point

The check: Is patient consent captured at lead form submission, WhatsApp first message, IVR call, walk-in registration, AND with explicit purpose + retention duration + data sensitivity class?

The standard: Every data entry point has consent capture with purpose specified, retention duration disclosed, and sensitive data class flagged (DPDP defines health data as "sensitive personal data" with higher protection requirements).

Common failure: Generic "I agree to privacy policy" checkbox without purpose-specific consent. Or no consent at all on WhatsApp + IVR.

Remediation: Update lead forms with purpose-specific consent. Implement WhatsApp first-message template that captures consent before any clinical data exchange. IVR consent prompt before recording continues.

Check 3: Deletion workflow (not anonymisation)

The check: When a patient requests deletion, does the PMS support cryptographic deletion of the record + all referenced communications + WhatsApp history within 30 days?

The standard: True deletion, not anonymisation. The record is unrecoverable. An audit trail of the deletion event is retained for 7 years for regulatory verification.

Common failure: "Marking as inactive" instead of deleting. Anonymising the name but retaining all clinical and contact data. Inability to delete WhatsApp message history.

Remediation: Confirm with PMS vendor that deletion workflow exists and runs cryptographically. If not, the clinic is structurally non-compliant with DPDP deletion rights.

Check 4: Access logging

The check: Does the PMS log every read, write, export, and view of every patient record with user ID, IP, timestamp, and reason?

The standard: Full access logging retained for the patient's data retention period + 7 years thereafter. Required for breach notification within 72 hours — you cannot determine breach scope without access logs.

Common failure: PMS only logs writes, not reads. Or only logs the application user, not the underlying database user. Or logs are retained 30 days and overwritten.

Remediation: Ask the PMS vendor for a sample access log export. If it doesn't include reads + reason codes, escalate or migrate.

Check 5: AES-256 encryption at rest + TLS 1.3 in transit

The check: Is patient data encrypted at the database column level for sensitive fields (phone, email, address, clinical notes) at rest? Are all in-transit connections TLS 1.3 minimum?

The standard: Column-level encryption with key rotation. TLS 1.3 minimum for all client connections and API calls. Database backups also encrypted.

Common failure: Database is not encrypted at column level — only at disk level (which is weaker). API connections still using TLS 1.2 or below.

Remediation: Database-level review. May require PMS vendor patch or major upgrade.

Check 6: Signed Data Processing Agreement

The check: Has your PMS vendor signed a DPDP-compliant Data Processing Agreement with the clinic?

The standard: Written DPA covering data flow, retention, breach response, sub-processor disclosure, cross-border transfer terms, and liability allocation.

Common failure: No DPA. Or generic "Terms of Service" passed off as DPA.

Remediation: Request DPA from PMS vendor. If vendor refuses or has no DPDP-compliant template, this is a serious compliance gap. ICG signs DPDP DPAs with every clinic client by default.

Check 7: Role-based access at field level

The check: Does reception see only name + phone + appointment, while doctor sees clinical notes, billing sees payment data, and admin sees access logs?

The standard: Role-based access enforced at the database/field level, not just the UI. No user has full database access by default. Even the system administrator's access is logged.

Common failure: UI-layer role restrictions only — if a user copies a SQL query or uses the API, they see everything. Or single admin role with full access.

Remediation: Database-level review with vendor. May require significant rework if PMS was designed without role-based access primitive.

Check 8: Breach notification protocol

The check: Is there a documented protocol for 72-hour breach notification to the Data Protection Board, including: detection method, scope determination, affected patient notification, vendor coordination?

The standard: Written protocol with named responsibilities, contact information, decision tree for breach scope, and patient notification template.

Common failure: No protocol. Or protocol exists but PMS vendor's incident response is not aligned with it.

Remediation: Document the protocol. Confirm PMS vendor's incident response SLAs in writing. Test annually.

Where ICG fits

HealthPro 360 was built post-DPDP and meets all 8 checks by architecture. Nexus CRM is similarly DPDP-built. Phoenix overlay maintains DPDP compliance even when sitting above a legacy PMS.

ICG operates as a DPDP Data Processor with signed Data Processing Agreements for every clinic client.

Related reads

• Practice Management Software India pillar
• Healthcare CRM India 2026 guide
• HealthApex OS ecosystem
• Client Alleviation Programme — includes DPDP training for clinic team