ABDM, ABHA and consent in hospital systems

Two framings cause most of the difficulty in national health infrastructure integration, and both are reasonable on first reading. The first is that the health identifier is a login, so the work is authentication. The second is that record sharing is an upload, so the work is a nightly export. Neither survives contact with how consent actually operates.

What is being built is closer to a federated query system than a data exchange. Records stay where they were created. A request arrives for information about a patient, carrying a consent artefact granted elsewhere, and your system decides whether to honour it, for what scope, and for how long. That is a different shape of problem from an export.

The identifier is not your primary key

The temptation is to adopt the national identifier as the patient key, on the grounds that it is unique and externally issued. It is a mistake that is painful to undo, for reasons that show up immediately in practice: not every patient has one, a patient may present without it in an emergency, one may be created after a visit has already been recorded, and linkage may later be found incorrect and need unpicking.

Your internal patient identity stays yours. The national identifier is a linked credential with its own record — when it was linked, by what method, by whom, and with what verification. A patient without one must be able to register, be treated and be billed with nothing degraded, because a system that cannot do that will have staff inventing placeholder identifiers within a week.

An identifier issued by someone else, which a patient may not have and may later change, is a foreign key. It is not your primary key.

Consent has a lifetime, and you did not create it

Consent is not a checkbox at registration. It is an artefact with a purpose, a defined scope of information, a validity period, an expiry, and the possibility of revocation at any moment — and it is granted through a manager your hospital does not operate.

That produces requirements a form cannot satisfy. Consent must be stored as its own object with its full attributes, not as a flag on the patient record. Every disclosure must reference the specific artefact that authorised it, so the question of why information left the building has an answer that names the authority. Revocation must take effect on receipt, which means your system needs to accept an event it did not initiate and act on it — not discover the change at the next poll.

Expiry is the routinely missed case. A consent that has lapsed authorises nothing, and a system that checks validity only at the moment of grant will happily serve a request months later against an artefact that is no longer live.

Your internal schema is not the exchange schema

Information is exchanged as structured clinical documents conforming to defined profiles. Your database will not match them, and it should not be reshaped to. The profiles evolve on a national timetable that has nothing to do with your release cycle, and a hospital system whose internal model is the exchange model inherits every external change as a migration.

Build a mapping layer, version it, and test it against published examples rather than against your own assumptions about the specification. Where a field the profile expects does not exist in your data, that is a clinical documentation question to raise with the people who record it, not a gap to fill with a default value — a plausible default in a clinical record is worse than an absent one.

Every access needs to be attributable

In most systems the audit trail records writes. Here reads matter at least as much, because the question that gets asked after an incident is who looked at a record, when, and under what authority. That means logging reads with the acting user, the patient, the time and the consent artefact relied upon, in a store that the application cannot retrospectively alter.

It is worth saying plainly that this is a volume decision as well as a design one. Read logging at a busy hospital produces a lot of rows, and it needs somewhere sensible to go — which is a data engineering question that ought to be settled during design rather than discovered when the primary database slows down.

Where we would start

Not with the integration. The non-clinical spine — a single patient identity, a clean encounter record, an audit trail that captures reads — is the part everything else depends on, and it is usually the part that is weakest. Integration built on top of a patient identity that is duplicated across three modules will reliably expose the duplication to the outside world.

Where hospital policy requires data to remain inside the building, this runs on your own hardware with the same access control, audit trail and pipelines we would build in a cloud. That is a deployment decision and not a compromise in how the system is engineered.

One note on scope: this describes how the requirement shapes system design. It is not legal or regulatory advice, and the specifications, profiles and certification steps that apply to your facility are a question for your compliance adviser — they are actively evolving, which is the argument for a versioned mapping layer rather than a direct implementation.