The Digital Health Incentive Scheme: What ABDM Will Actually Pay a Hospital

Most hospitals meet ABDM as an obligation. A letter arrives from a state health authority, the word compliance appears in it, and the IT head starts pricing work that produces no revenue. That framing is incomplete, and expensively so, because there is a National Health Authority scheme that pays health facilities for the same digital records the compliance letter is asking them to create.

The Digital Health Incentive Scheme is the part of ABDM that most purchase committees discover late, usually from a vendor slide rather than from the circular. It does not turn digitisation into a profit centre. For a hospital that was going to do the work anyway, it changes the payback arithmetic enough to be worth understanding properly before the budget is set.

What is the Digital Health Incentive Scheme?

The Digital Health Incentive Scheme, usually written DHIS, is a National Health Authority scheme that pays eligible health facilities and digital solution companies for creating health records and linking them to a patient's ABHA. The National Health Authority announced it to accelerate ABDM adoption, and has extended and revised it more than once since.

The mechanism is transaction-based rather than a grant. A facility does not apply for a sum and receive it; it earns against volume of ABHA-linked records above a baseline calculated from its own size. That design is deliberate — it pays for the behaviour continuing, not for a one-off integration project that goes quiet after go-live.

Two things follow from that shape, and both matter more than the headline number. The incentive rewards records that are actually linked, which means it rewards a registration counter that creates and links ABHA reliably every day rather than an integration that technically works. And because it is volume-linked, the same scheme is worth very different amounts to a 30-bed nursing home and a 300-bed hospital.

Which hospitals are eligible for DHIS?

Eligibility runs through the Health Facility Registry rather than through any separate application, and the published criteria have centred on facilities with ten or more beds registered on the HFR, transacting above a monthly baseline expressed per bed.

In practice that gives a hospital three prerequisites before the scheme is even reachable. It must be registered on the Health Facility Registry and hold a valid facility ID. Its software must be an ABDM-certified health information provider, capable of creating and linking care contexts rather than merely generating an ABHA number. And it must be doing enough volume for the baseline to be cleared in a month, because incentives accrue on transactions above that line and not on the first ones.

That third condition is the one that quietly disqualifies people. A hospital that links ABHA for the handful of patients who ask about it will never cross a per-bed monthly baseline. The scheme is designed to reward a counter where ABHA creation is the default path through registration, not the exception a clerk offers when the queue is short. If your registration workflow makes ABHA an extra screen someone can skip, you have built the version of compliance that costs money and earns none.

The HFR and HPR registration guide covers the registry step, which is the prerequisite people most often discover they have not completed.

How much can a hospital earn?

As the scheme has been published, a health facility earns a fixed amount per ABHA-linked transaction above a monthly baseline, subject to an overall ceiling that National Health Authority material has stated as up to four crore rupees.

The figures that have circulated most consistently are these. Health facilities earn in the region of twenty rupees per eligible transaction above the baseline. The baseline for hospitals was originally set at fifty transactions per bed per month for facilities with ten or more beds; relaxations introduced from April 2023 reduced it, and a flat hundred-transactions-per-month baseline for health facilities has been widely reported since. Laboratories and smaller clinics have carried their own thresholds — commonly quoted at five hundred and two hundred transactions a month respectively — at lower per-transaction rates. Digital solution companies earn separately, at a lower per-transaction rate or a percentage of the facility's incentive.

Treat every one of those numbers as indicative. The scheme has been revised repeatedly by corrigendum, and later corrigendum periods have been reported with materially different terms — lower per-record rates distinguishing a discharge summary or diagnostic report from other record types, a requirement that the ABHA be KYC-verified, and per-ABHA caps limiting how many transactions one patient can generate in a day or a month. Any of those changes the answer substantially. Take the operative corrigendum from the National Health Authority's own DHIS page before you put a number in a board paper.

How should a hospital model it?

With the arithmetic rather than with a headline figure, because the arithmetic survives the next corrigendum and the headline figure does not.

The calculation has the same four terms whatever the current rates are. Take your monthly volume of records that would qualify — OPD and IPD encounters, discharge summaries, diagnostic reports — and be honest that this is the count that gets linked, not the count you generate. Subtract the baseline. Multiply by the current per-transaction rate for that record type. Apply the per-ABHA caps, which matter more than they look for a hospital with a large repeat-visit population, since a dialysis or oncology patient attending three times a week cannot generate three times the incentive.

Run it twice: once at the current published rate, and once at half. If the business case only works at the higher number, it is not a business case, it is a hope. And run it against your linked volume rather than your registration volume, because the gap between those two is where most facilities discover their integration is thinner than the certificate suggested.

The sensible use of DHIS in a software business case is as a reduction in the net cost of an integration you had already decided to do. A hospital that buys a system because of the incentive has the reasoning backwards; a hospital that ignores the incentive while budgeting the same purchase is leaving a recurring credit uncounted.

Does the scheme pay for insurance claims too?

There is a separate incentive on the claims side, and it is commonly misread as money the hospital receives.

National Health Authority material has described an incentive of five hundred rupees per claim, or ten per cent of the claim amount, whichever is lower — but that arrangement accrues to the payer, the insurer or TPA processing the claim, rather than to the hospital submitting it. Hospitals reading a vendor slide about "five hundred rupees per claim" and modelling it as revenue are modelling somebody else's incentive.

What the claims side does for a hospital is indirect and still worth having: payers with an incentive to process digitally are payers with a reason to onboard to NHCX and to accept your structured submissions. The benefit reaches you as faster settlement rather than as a payment.

What has to be true in the software?

The scheme pays for linked records, so the software has to make linking a by-product of ordinary work rather than a separate task somebody remembers to do.

Concretely, ask a vendor to demonstrate the following on live ABDM sandbox or production endpoints, not on slides.

• ABHA creation and verification at registration, including the Aadhaar and mobile routes, with the failure paths shown
• ABHA address linking for a patient who already has one, without creating a duplicate
• Care context linking on OPD registration, IPD admission, and diagnostic report publication
• Consent request handling, including a denied and an expired consent
• The facility's own DHIS-relevant transaction count, visible to the hospital rather than only to the vendor
• Retry behaviour when the ABDM gateway is unavailable mid-registration

That last two are what separate a certified integration from a system that will actually earn. If the hospital cannot see its own linked-record count without asking the vendor, nobody in the hospital can tell whether this month cleared the baseline, and a scheme nobody can measure is a scheme nobody manages. If a gateway timeout loses the link silently, the counter clerk moves on and the record is never linked — and no error was raised, so no one investigates.

The ABDM milestone certification guide sets out what M1, M2 and M3 each require, and ABHA at the registration counter covers what the workflow has to survive when there are eleven people waiting.

Does DHIS change the business case for new software?

It changes the arithmetic at the margin, and it changes the sequencing more than the decision. A hospital already replacing its HMS should require ABDM certification and self-visible transaction counts as contract terms; a hospital not replacing anything should not start a procurement because of an incentive.

The more useful reframe is that DHIS, NHCX and PM-JAY now point the same direction. All three reward a hospital whose records are structured, whose identity resolution is clean, and whose transactions can be evidenced. A system bought for one of them tends to serve the others. A system bought for none of them will be retrofitted for all three, at a cost that never appears in the original quotation. The five-year cost article works through where those retrofits land.

What should a hospital do first?

Check the registry, then check the counter, then read the current circular. In that order, because the first two are prerequisites the third assumes.

Confirm the facility ID on the Health Facility Registry is current and the bed count on it is right, since the baseline is computed from it. Stand at your own registration desk for an hour and count how many patients leave with a linked ABHA — that number, not the vendor's certification certificate, is what the scheme pays on. Then take the current terms from the National Health Authority's DHIS page and model a conservative month.

Where Kōami fits

Kōami is built as an ABDM-aware system rather than one with an ABDM module bolted to the side: ABHA creation and verification sit inside the registration flow, care contexts are linked from OPD registration, IPD admission and report publication as those events happen, and consent artefacts are held against the patient record rather than in a separate log.

The part worth asking us about directly is the measurement. A hospital should be able to see its own linked-record volume, its failure reasons and its month-to-date position against the baseline without raising a ticket, because that is the difference between an integration that is certified and one that earns. Bring a week of your registration volume to a demo and ask to see those counts, the gateway-failure path and the duplicate-ABHA case. Those three are where most ABDM integrations turn out to be thinner than the certificate suggests.