The same platform serves a hospital in Delhi under India’s Digital Personal Data Protection Act and a behavioral health agency in Houston under HIPAA and, for substance use records, 42 CFR Part 2. Add ABDM’s consent rules on the Indian side and state medical record retention on the American side, and a reasonable engineering team might conclude that this is two products.
We concluded the opposite, and the reason is simple. Every privacy regulation we have read asks for the same six things: tell people what you collect, store it safely, use it only for the reason you said, share it only with permission, keep it only as long as needed, and get rid of it properly. The regulations differ in the details of each. They do not differ in the shape.
So HealthPlex has one privacy architecture and two jurisdiction packs. The components do not change between Delhi and Houston. The rules loaded into them do.
Every request passes one decision point
Every read and every write, with no exceptions for internal callers, batch jobs or administrators, passes through a policy decision point. It evaluates five things: the role, scoped to tenant and facility; the consent registry, which holds purpose-bound consents, ABDM consent artefacts and Part 2 disclosure consents with their expiries; the declared purpose of use; the minimum-necessary rule for that role and request; and, when a clinician invokes break-glass access, a required reason that goes straight to the audit ledger.
A request that cannot state its purpose is refused. A read outside a consent’s scope is refused. The refusal is itself logged. This is the same decision point that enforces the ABDM consent artefact on every read, described in the interoperability post, because there is only one.
Identifiers live apart from clinical facts
No clinical table in HealthPlex holds a name, a phone number, an address, an ABHA number or a Social Security number. Those live in a PII vault with its own service, its own storage and per-tenant keys held in a key management service. The clinical tables carry tokens.
A service that needs to display a name asks the vault, and the vault asks the decision point. A report over ten thousand encounters never touches the vault at all. A developer with read access to the clinical database sees tokens and diagnoses, which is bad enough to guard but is not a list of names with conditions attached.
The vault also makes erasure real. When a data principal exercises the right to erasure under the DPDP Act, we do not run a delete across forty tables and hope we found every copy. We destroy the key. Every identifier encrypted under it becomes unrecoverable, the clinical facts stay for the retention the law requires, and the ledger keeps the entry recording that erasure happened and when.
Documents and images sit in encrypted object storage in a residency region fixed per tenant. Indian tenants’ data stays in the Indian region; American tenants’ in the American one. Residency is a tenant property. Data does not cross it.
The same lifecycle, two rulebooks
The clearest way to see the architecture is to walk one record through its life and watch which rule fires at each stage.
Collect. The mechanism is notice and consent capture at first contact, in the registration flow. Under HIPAA, that means the Notice of Privacy Practices and a signed authorization for any use beyond treatment, payment and operations. Under the DPDP Act, it means an itemised notice per purpose, a separate consent per purpose, and verifiable parental consent for a minor. Same screen, same registry, different fields required before the registration can complete.
Store. The mechanism is the vault, field-level encryption and residency. HIPAA’s Security Rule treats encryption as addressable but every auditor expects it; the DPDP Act asks for reasonable security safeguards and, in practice, for the data to stay where the tenant is.
Use. The mechanism is the purpose check at the decision point. HIPAA calls it minimum necessary. The DPDP Act calls it purpose limitation. The code path is the same; the rule that populates it is loaded from the pack.
Share. The mechanism is a consent artefact, a Business Associate Agreement or a processor contract, recorded in the registry and checked before any disclosure. HIPAA requires the BAA with every vendor who touches PHI and a specific consent for Part 2 records. The DPDP Act requires the processor contract and governs cross-border transfer; ABDM adds the consent artefact for provider-to-provider exchange.
Retain. The mechanism is a retention schedule per record type and regime. HIPAA requires six years for compliance documentation and defers to state law for medical records. The DPDP Act requires erasure once the purpose is served, unless another law requires retention, which for medical records it generally does.
Erase. The mechanism is crypto-shredding with the ledger entry preserved. HIPAA asks for secure disposal of ePHI and media. The DPDP Act grants a right to erasure and a grievance path with statutory timelines.
Adding a third regime, and there will be one, is a new pack: new required fields at collection, new retention schedule, new disclosure rules. Not a new vault, not a new registry, not a new ledger.
Data subject rights are a queue, not a project
A request for access, correction, erasure or portability arrives through the patient portal or the front desk and lands in the data subject rights module as a ticket with a clock. The clock is set by the pack: HIPAA’s thirty days for access, the DPDP Act’s timelines for grievance redressal through the grievance officer the tenant has named.
The module knows which vault entries, clinical records and documents belong to the principal, because the tokens tie them together, and it assembles the response or executes the erasure without an engineer running SQL. An earlier version of this platform handled these requests as a project each time. That does not scale past the third hospital.
Breach is a workflow before it is an emergency
When something goes wrong, the platform already knows what to do. A suspected breach opens a case. Under HIPAA, the case walks the four-factor risk assessment in 164.402: what was involved, who received it, whether it was actually acquired or viewed, and how far the risk has been mitigated. Under the DPDP Act, it prepares the notification to the Data Protection Board and to the affected data principals.
The evidence comes from the ledger. Who accessed what, from where, under which purpose, in the window in question, answered in seconds and immune to edits after the fact. A breach response that starts by asking engineering to grep logs has already lost a day.
Evidence, not assurance
An auditor does not want to be told the platform is compliant. They want to see it. The evidence pack is generated, not written: a control register with a named owner for each control, mapped to the regulation’s clauses; automated hardening checks run against the live environment with their results; penetration test findings with the retest that closed them; the tamper drill on the ledger, run live.
We ship a reusable security assurance walkthrough with every prospect engagement for exactly this reason. It is faster to show than to describe.
The principle
A regulation is a set of rules loaded into components that already exist. If compliance needs new components, the architecture was wrong.
If you are evaluating a platform for a hospital in one country and a subsidiary in another, ask the vendor to show you the request path for a chart read and point to where consent is checked. Then ask where the name is stored. Then ask what happens when a patient asks to be forgotten. If those three answers involve three different systems, the platform has a compliance problem it has not met yet.
CTO and ChiefArchitect, RatnaGlobalTech.