ABDM is the identity and records layer — ABHA, consent, FHIR R4. NHCX is the claims exchange. DPDP is the data protection obligation that sits over both. Software can build and validate; it cannot complete your registry onboarding or discharge your fiduciary duty.
Three regimes, often conflated
| What it is | Software can | Only you can | |
|---|---|---|---|
| ABDM | Identity and records — ABHA, consent, FHIR R4 | Link ABHA, emit valid FHIR, capture consent | Register in HFR and HPR |
| NHCX | Standardised claims exchange | Build and validate claim bundles | Complete NHA onboarding |
| DPDP | Data protection obligation | Minimise, redact, log, localise | Be the data fiduciary |
The distinction that matters commercially
When a vendor says "NHCX submission," ask which half they mean. Generating and validating a claim bundle is an engineering problem and a solved one. Transmitting it requires your NHA onboarding, which is an institutional process involving your registration and approvals.
If a vendor claims to transmit, ask to see a transmission that went through your onboarding. It cannot have, if your onboarding is not done. A hospital that buys on that promise and discovers the gap at go-live has lost months.
The six things that usually block onboarding
- Facility registration in the Health Facility Registry, current and verified
- Practitioners registered in the Healthcare Professionals Registry
- A working ABHA linkage flow with consent capture your front desk can actually complete in a queue
- Records emitted as valid FHIR R4 — which most legacy HMIS exports are not
- Payer-side readiness: your insurers and TPAs must themselves be on NHCX for a given path to exist
- Internal process ownership, because the technical work finishes long before the paperwork does
The blocking item is usually organisational rather than technical. A readiness check naming which of the six applies to you is more useful than any claim of compliance.
DPDP in practice
The Digital Personal Data Protection Act makes the hospital the data fiduciary. Software choices affect how large that obligation is, but they do not transfer it.
Three things reduce the surface meaningfully: keeping data on Indian infrastructure, minimising what is collected in the first place, and stripping identifiers before data reaches any system that does not need them. A claims tool that never sees a patient name has a much smaller breach story than one that stores them.
Consent under ABDM is not the same as consent under DPDP. The first governs record sharing; the second governs processing purpose. Both need capturing, and they are not interchangeable.
What is worth doing before NHCX matters to you
ABHA linking and clean FHIR R4 records are worth having regardless, because they are the substrate everything else sits on. A hospital with clean FHIR is a short step from NHCX when its payers arrive. A hospital with records locked in a proprietary schema has the same work ahead whenever it starts — only later, and under time pressure.
More in this cluster: ABDM, NHCX & compliance — every article we have on it.
Questions we get asked
Does Drapto submit claims to NHCX?
No. We build and validate the FHIR R4 bundles. Transmission runs through your own NHA onboarding, which no software can complete for you.
Is ABDM compliance mandatory?
ABHA linking is not universally mandatory for every provider today, but it is the substrate NHCX and record sharing depend on, so the practical answer for a hospital planning ahead is yes.
Does DPDP require data to stay in India?
The Act permits transfer to notified territories but the simplest compliance position for an Indian hospital is Indian infrastructure with no cross-border transfer at all.
Read next
See Drapto on your own workflow
A free 30-minute demo: your payers, your room categories and the deductions you see most, walked through live. Then a written proposal.