Three regimes, three sponsors, one hospital
A hospital in India now answers to three distinct programmes at once. NABH sets accreditation standards for quality and safety, the Ayushman Bharat Digital Mission sets requirements for participating in the national health data network, and the Digital Personal Data Protection Act, 2023 sets statutory obligations for handling personal data. They come from different bodies, use different vocabulary, and arrive on different timetables.
The common response is three separate projects with three owners, three evidence collections, and three sets of meetings. That duplicates a great deal of work and, worse, produces contradictions: an access policy written for accreditation that does not match the one written for data protection. Assessors and auditors find those contradictions quickly.
The alternative is one compliance programme with a single control set, mapped to whichever obligations each control satisfies. This costs more to design and considerably less to run. It also produces a hospital that behaves consistently, which is the actual objective.
Where the obligations genuinely overlap
The overlap is larger than it first appears, because all three care about the same underlying behaviours. Each expects records to be accurate, attributable, and retained appropriately. Each expects access to be limited to those who need it, consent to be obtained and recorded, and incidents to be identified and acted upon.
One well-designed control therefore satisfies several requirements at once. Role-based access with logging supports the accreditation expectation on information security, the network's requirement that disclosure be authorised and traceable, and the statutory expectation of reasonable safeguards. Building it three times produces three partial versions of the same thing.
Start by listing behaviours rather than requirements. Identity, access, consent, record quality, retention, logging, incident handling, and training cover most of the shared ground. Then map each behaviour to the obligations it addresses.
Controls that serve all three
- Role-based access with logging
- Accurate, attributable clinical records
- Recorded and revocable patient consent
- Defined retention and disposal schedule
- Incident identification and response
Where they diverge and cannot be merged
The differences matter as much as the overlaps, and they are where a merged programme goes wrong. Accreditation is something a hospital chooses to seek, and it is assessed periodically against standards covering clinical process far beyond data handling. The statute is not optional and applies whether or not anyone comes to assess you.
Network participation is different again: it is largely technical conformance, proved in a sandbox and maintained through operation, and it concerns records and identities rather than clinical quality. Its requirements are prescriptive where the others are principle-based. You cannot satisfy it with a policy document, however well written.
The practical consequence is that one control set needs several evidence forms. The same access control might be evidenced by a policy and a sample review for one audience, a technical conformance result for another, and an incident record for the third. Design the control once, then plan the evidence separately for each audience.
One control set, several owners
Build a register in which each row is a control rather than a requirement. Every control needs a description, an owner, an operating frequency, an evidence source, and a mapping to each obligation it addresses. When a standard changes you update the mapping instead of rebuilding the control.
Ownership should follow function rather than programme. The person who owns access management owns it for all three regimes, the medical records officer owns record quality and retention, the privacy lead owns consent and rights handling, and the quality lead coordinates. Nobody should own a regime end to end, because that structure recreates the three silos inside one programme.
Governance becomes a single forum on a single calendar, reviewing the register. Add regime-specific preparation as agenda items ahead of an assessment or a submission rather than as parallel workstreams. The register is then the one source of truth about what the hospital actually does.
What each control row should record
- Control description and purpose
- Named functional owner
- Operating frequency and method
- Evidence source in live systems
- Mapping to each obligation addressed
Produce evidence once and reuse it
The most wasteful part of a three-programme approach is evidence collection, because the same facts are gathered three times in three formats. An access review, a consent capture rate, a disposal log, an incident record, and a training completion list are each relevant to more than one audience. Collect them once, from live systems, on a schedule.
Evidence pulled from operational records is also more credible than evidence assembled for an assessment. An assessor can tell the difference between a log showing a control operating monthly for a year and a folder of screenshots dated last week. HealUDoc's compliance tooling and activity trail are built to make the former retrievable, though what the evidence shows still depends on whether the control actually ran.
Separate pages on this site cover each regime in depth: NABH readiness (/nabh-compliance), network participation (/abdm-compliance), and data protection (/dpdp-act-compliance). Reading them together makes the shared foundation obvious. The overlap in their content mirrors the overlap in the obligations themselves.
Run it as one programme with one plan
Sequence the work by dependency rather than by whichever deadline feels closest. Identity and access come first because nearly everything else assumes them, followed by record quality and structure, then consent, then retention and disposal, then incident response and training. A hospital that jumps to the most urgent-seeming deadline usually rebuilds the earlier layers later at greater cost.
Review the register quarterly, and specifically after any change to systems, suppliers, branches, or organisation structure. Compliance debt accumulates through ordinary operational change rather than through neglect, and it stays invisible until something is assessed. A control that quietly stopped operating three months ago looks identical on paper to one that never stopped.
No software makes a hospital compliant with any of these, and a vendor claiming otherwise should be asked to be specific about what the product does and what remains yours. This article is a planning framework rather than legal advice, and the statutory questions in particular belong with your own counsel. What a platform can do is make the controls easier to operate and the evidence easier to retrieve.
“We stopped calling them three projects the day we noticed the same access review was being done three times by three people who had never met.”