A consent manager is not a consent form: what DPDP changes about how hospitals hold patient data

A DPDP consent manager for hospitals is not a better consent form. It is an enforcement point that is checked every time patient data is used.

Ask an IT head in a 200-bed hospital whether consent is handled, and the honest answer is usually some version of this: yes, the registration desk takes a signature, it is scanned, it is in the file. Ask the follow-up question — which systems read that patient's record in the last month, and under what purpose — and the answer changes tone. Nobody is lying. The record simply does not exist in a form anyone can query.

That is the gap people are reaching for when they search for a DPDP consent manager for hospitals. The short answer: a consent manager is not a better consent form. It is an enforcement point that sits between a request for personal data and the data itself, and is consulted every time, not once at admission. And there is a second meaning worth separating out, because the two get confused in vendor conversations. Under the Digital Personal Data Protection Act, 2023, Consent Manager is a defined, registered role — an accountable intermediary through which a data principal can give, manage, review and withdraw consent. No hospital information system becomes one by adding a tick box. In the health-data exchange specifically, ABDM operates consent through its own consent-manager flow, which the ABDM FAQ describes for ABHA-linked records.

So a hospital has two separate obligations. One is to participate correctly in the external consent architecture. The other, far more neglected, is to be able to prove internally that every use of personal data inside its own four walls was permitted. The second one is where audits go badly.

Why the gap exists

It is architectural, not negligent. In most hospitals, consent is captured by one system — registration — and data is used by twenty. The lab middleware pulls demographics. The radiology PACS pushes to a teleradiology partner. The TPA desk uploads a discharge summary and an itemised bill. A marketing agency gets a spreadsheet of discharges for a feedback campaign. An analytics dashboard runs an overnight extract. Each of those is a separate interface, written at a separate time, usually by a separate vendor, and not one of them calls back to ask whether this particular patient agreed to this particular purpose.

Consent, in that architecture, is a document. Documents do not enforce anything. They only prove that something was asked once.

There is a second structural problem: purpose. A signature on an admission form covers treatment. It does not obviously cover research, marketing, vendor analytics, or sharing with an entity the patient has never heard of. When purpose is not recorded as a field, every downstream use inherits the same undifferentiated permission, which means nothing is actually scoped.

And a third: withdrawal. If consent can be withdrawn, something has to happen when it is. If your only record of consent is a scanned PDF, withdrawal is an email to the IT head and a hope.

What to do about it without buying anything

Most of the work here is not a procurement. It is a mapping exercise that a competent IT head and a quality manager can do in a few weeks.

• Write down every outbound flow of personal data. Not systems — flows. Who sends what, to whom, how often, triggered by what. Interfaces nobody remembers commissioning are the ones that surface here.
• Attach a purpose to each flow, in plain language. Treatment, claim settlement, statutory reporting, research, service improvement, marketing. If a flow cannot be given an honest purpose, that is your finding.
• Decide where the enforcement point is. There should be exactly one place a system has to pass through to read identifiable patient data. If there are four, you have no enforcement point.
• Turn on read logging before you turn on anything else. Who read which record, when, from where. An access log you cannot query is the same as no log.
• Read your vendor contracts for the data clauses. Processor obligations, breach notification timelines, deletion on exit, sub-processors. Many legacy HMS contracts predate the Act entirely.
• Define the withdrawal path on paper. Who receives the request, what stops, what legitimately continues because a statute requires retention, and how long it takes.

None of that needs a new platform. It does, however, usually reveal that the existing platform cannot do the enforcement part, because consent was never a first-class object in it.

Where Ospia fits

Ospia HOS is an AI-native hospital operating system rather than a hospital management system, and the distinction matters here for an unglamorous reason: consent sits in the data model rather than in a screen. Registration is ABHA-ready, and every use of personal data traces to recorded consent held in a consent ledger that is consulted before use. The compliance surface treats DPDP as by-design rather than as a document exercise — personal data minimised and encrypted at rest, the ledger checked ahead of access.

The architecture makes that enforceable rather than aspirational. The platform is organised as 31 isolated business domains, each owning its own schema and its own data, so there is a defined boundary to police rather than one shared database everything reaches into. The FHIR R4 read surface — Patient, Encounter, Condition, Observation, MedicationRequest, DiagnosticReport — is gated behind a DPDP data-sharing consent check, so interoperability and consent are not separate projects. Teleconsults run peer-to-peer so media never touches the server, with consent gated before the call. Backups are encrypted with a dedicated key family separate from the data-encryption key, so a stolen archive is not a breach of the live database. Residency is the hospital's choice: self-hosted on your own infrastructure, or managed cloud in-region. Where configuration patterns travel between hospitals, only the shape of a rule or workflow moves — never patient data, never anything identifiable — and it is contractual and opt-in.

Ospia HOS is running hospitals in production today. What we do not publish is how many, or which, until each hospital completes hypercare and agrees to be named. We are equally plain about the security gaps: Ospia is not ISO 27001 certified, and no independent penetration test has been conducted yet — it is planned as a recurring engagement, at least annually and after significant change. If you are evaluating vendors on compliance posture, ask every one of them those two questions and compare the answers rather than the brochures. For the same reason we publish no feature-by-feature competitor scorecard — a comparison written by one vendor about another is not evidence. The security page and the migration page state what is in place and what is not.

A platform asking hospitals to trust its audit trail cannot start by overstating itself.

If you want to see the consent ledger being consulted rather than described, ask for the executive demonstration and bring your three hardest data flows.