On this page · 14 sections
- Why ABDM stopped being optional
- The six building blocks you are integrating with
- The four milestones, and which one is hard
- What FHIR R4 actually demands
- Certification is a security audit with an API attached
- Where the money actually goes
- The consent artefact is a lifecycle, not a checkbox
- Adoption is the metric that ABDM certification does not measure
- India-specific considerations: DPDP runs on a separate clock
- What eCorpIT builds
- Who should not build this yet
- FAQ
- How eCorpIT can help
- References
Summary. On 22 May 2026 the National Health Authority announced that over 100 crore health records are now linked to Ayushman Bharat Health Accounts, doubled from 50 crore in February 2025 in just 15 months. More than 450 public and private health technology solutions have integrated with the Ayushman Bharat Digital Mission. Uttar Pradesh alone accounts for over 15.03 crore linked records, Andhra Pradesh 11.95 crore. Roughly 10 crore records are now linked every two to three months. That changes what "healthcare app" means commercially in India: ABDM certification across milestones M1 to M4 is the entry ticket to the network, not a feature you add in year two. The technical bar is HL7 FHIR R4 with India-specific profiles, consent artefacts, encrypted record transfer, and a CERT-In or STQC empanelled security audit before the NHA grants production access. The compliance bar is the DPDP Act, where failure to maintain reasonable security safeguards carries a penalty of up to ₹250 crore. Vendor estimates put a lean healthcare MVP at ₹20 lakh to ₹50 lakh, with Indian engineering at ₹1,500 to ₹3,000 per hour. Here is what actually drives that number.
Why ABDM stopped being optional
Dr. Sunil Kumar Barnwal, CEO of the National Health Authority, framed the milestone in citizen terms:
"The linking of over 100 crore health records with ABHA is an important milestone in the journey of Ayushman Bharat Digital Mission. It reflects the increasing adoption of digital health services across Government programmes, States, health facilities and private technology partners."
The commercial reading is different from the policy reading. A network with 100 crore records and 450 integrated solutions has crossed the point where sitting outside it is a product decision with a cost. If a patient's prescriptions, lab reports and discharge summaries live in ABHA-linked records at every other facility they visit, an app that cannot read or write to that network is asking them to maintain a parallel medical history by hand.
The growth curve is the part worth planning against. ABDM went from fewer than 1,000 linked records in its initial phase to over 100 crore, doubling in the last 15 months. State-level distribution as of 22 May 2026:
| State | ABHA-linked health records | Note |
|---|---|---|
| Uttar Pradesh | Over 15.03 crore | Leading contributor; eKavach platform |
| Andhra Pradesh | Over 11.95 crore | State health programmes |
| Bihar | Over 7.37 crore | Substantial progress recorded |
| Rajasthan | Over 6.32 crore | iHMS platform |
| Gujarat | Over 4.77 crore | TeCHO platform |
If your addressable market is UP, Andhra Pradesh or Bihar, the network effect has already arrived. Building a non-ABDM app for those states in 2026 is building for a market that has moved.
The six building blocks you are integrating with
ABDM is not one API. It is digital public infrastructure with distinct components, and most scoping errors come from treating them as interchangeable.
| Building block | What it does | When your app needs it |
|---|---|---|
| ABHA | Unique digital health identity for citizens | Any app that identifies a patient |
| HPR (Healthcare Professionals Registry) | Registry of verified practitioners | Apps with clinician accounts or e-prescribing |
| HFR (Health Facility Registry) | Registry of health facilities | Multi-facility or network apps |
| HIE-CM (Health Information Exchange and Consent Manager) | Consent-based record exchange | Any app reading or writing records |
| UHI (Unified Health Interface) | Open network for health services | Discovery and booking use cases |
| NHCX (National Health Claims Exchange) | Digital insurance claims | Payer integration and claims |
The consent manager is the one teams underestimate. ABDM's model is consent-based exchange by design, which means consent artefacts are not a checkbox in your UI. They are objects with lifecycles that your data layer has to honour.
The four milestones, and which one is hard
NHA certification runs through progressive milestones. They are not difficulty tiers of the same work; they are different systems.
| Milestone | Role your system takes | Core capability | Relative difficulty |
|---|---|---|---|
| M1 | Identity provider | ABHA creation, OTP or QR verification, patient discovery and linking | Foundational |
| M2 | Health Information Provider (HIP) | Create care contexts, respond to discovery, handle consent artefacts, transfer encrypted FHIR records | Hardest |
| M3 | Health Information User (HIU) | Request consent, aggregate records across facilities, present clinical data | Moderate |
| M4 | Claims participant | Digital insurance claims via NHCX | Payer-dependent |
M1 flatters everyone. Creating an ABHA number and verifying a patient by OTP is a week of work, and it produces a demo that looks like ABDM compliance. It is not.
M2 is where budgets die. To act as a Health Information Provider you build a full FHIR R4 record-sharing system: care contexts created after each consultation, discovery requests answered from the Consent Manager, consent artefacts validated and honoured, records serialised and encrypted, and every access logged. Each of those is a distinct subsystem with its own failure modes.
Our experience of these builds is blunt: teams that scope M1 and M2 as one line item are usually off by a factor of three on M2 alone.
What FHIR R4 actually demands
ABDM uses HL7 FHIR R4 with India-specific profiles. Every ABDM-compliant facility must serialise clinical documents as FHIR resources so that any other compliant system can parse them. The resources you will implement, at minimum:
Patient // demographics, ABHA linkage
Practitioner // HPR-verified clinician
Organization // HFR-registered facility
Encounter // the visit
Observation // vitals, lab results
Condition // diagnoses
MedicationRequest // prescriptions
DiagnosticReport // lab and imaging reports
DocumentReference // discharge summaries, scanned docs
AllergyIntolerance // allergies
Procedure // procedures performed
The trap here is not the resource list. It is that most Indian hospital systems store clinical data as free text or PDFs, and FHIR wants structure. A discharge summary that exists as a scanned image satisfies nobody: it can be wrapped in a DocumentReference, but the Condition and MedicationRequest resources inside it stay invisible to the network. Retrofitting structure onto years of unstructured records is the single largest hidden cost in ABDM projects, and it is a data problem, not an API problem.
The real cost is usually the migration, not the integration.
Certification is a security audit with an API attached
Before the NHA grants production access, your web application needs a security audit from a CERT-In or STQC empanelled agency. Certification agencies then review your M1, M2 and M3 workflows against NHA's official test case templates, covering ABHA creation, verification, discovery, consent handling and data transfer.
Two scheduling consequences follow, and they are why ABDM projects slip.
First, the audit is a dependency you do not control. Empanelled agencies have queues, and a failed audit means a remediation cycle plus a re-audit, not a same-week fix.
Second, sandbox success does not predict production success. The sandbox validates your workflows. The audit validates your security posture. Teams routinely pass one and fail the other, because they were built by different people to different standards.
Budget the audit at project start, not at the end. It is the item most likely to be discovered late and cost a quarter.
Where the money actually goes
Published Indian cost estimates vary widely enough that any single number should be treated with suspicion. Vendor guides put a lean healthcare MVP at roughly ₹20 lakh to ₹50 lakh, a telemedicine or patient portal platform at ₹1.25 crore to ₹2.5 crore, and a full custom EHR or hospital management system at ₹1.65 crore to ₹4.15 crore. Other India-focused guides quote materially lower domestic ranges for equivalent scope. Indian engineering rates cluster more consistently at ₹1,500 to ₹3,000 per hour.
The spread tells you something useful: these figures price feature lists, and feature lists are not what drives healthcare app cost. The drivers are:
| Cost driver | Why it dominates | Typical underestimate |
|---|---|---|
| Unstructured data migration | FHIR needs structure; legacy records are PDFs and free text | Largest single overrun |
| M2 HIP subsystems | Consent, encryption, audit, care contexts are four systems | Scoped as one |
| CERT-In / STQC audit cycle | External queue plus remediation and re-audit | Scoped at zero |
| DPDP alignment | Consent architecture touches every data path | Retrofitted, not designed |
| Clinical workflow fidelity | An app clinicians route around has failed regardless of certification | Treated as UI polish |
Compliance and data architecture are the major cost drivers in Indian healthcare builds, and retrofitting compliance later adds substantial cost. That is the one point on which the vendor guides agree with our own experience.
The consent artefact is a lifecycle, not a checkbox
Worth its own section, because it is where most M2 implementations go wrong.
In ABDM's model, a patient grants consent through the Health Information Exchange and Consent Manager, and your system receives a consent artefact. Teams tend to read that artefact once, decide the request is authorised, and serve the data. That is the bug.
A consent artefact carries scope and time boundaries. It names which care contexts are covered, what data types are permitted, and for how long. It can be revoked. It expires. Your data layer has to check it at the moment of access rather than at the moment of receipt, which means consent state has to be queryable from wherever records are served, not cached in the session that first saw it.
The discovery step has a matching subtlety. When a Consent Manager sends a discovery request, your system answers whether it holds records for that patient. Answer too loosely and you leak the existence of a care relationship to a request that was never authorised. Patient discovery is an information disclosure surface, and it deserves the same care as the record transfer itself.
None of this is exotic engineering. It is the sort of thing that gets built correctly when someone scopes it as a subsystem and gets built wrong when it appears as a ticket titled "handle consent".
Adoption is the metric that ABDM certification does not measure
A certified app that clinicians route around has consumed a budget and produced a compliance artefact.
The pattern to watch for: an outpatient department where the doctor writes on paper during the consultation and a data-entry operator keys it into the system afterwards. The facility is ABDM-compliant. The records reaching the network are a transcription of a transcription, entered by someone who was not in the room, hours later. The structure is real and the clinical fidelity is not.
This is why we put clinical workflow design alongside the milestone work rather than after it. FHIR resources are only as good as the moment of capture. If your Observation resources are typed in at 6pm from a paper chit, ABDM will accept them and no clinician will trust them.
India-specific considerations: DPDP runs on a separate clock
ABDM certification does not discharge your DPDP obligations. They are different regimes with different deadlines.
Under the Digital Personal Data Protection Act 2023, failure to maintain reasonable security safeguards attracts a penalty of up to ₹250 crore, and breach notification failures up to ₹200 crore. The Data Protection Board of India was established and the penalty framework became active in November 2025. The Consent Manager Framework becomes operational on 13 November 2026, and full compliance for data fiduciaries lands on 13 May 2027.
Health data is the highest-stakes category in that regime, and the timing is awkward in a specific way: teams building ABDM consent flows through 2026 are building consent architecture twice if they do not design for both regimes at once. ABDM's HIE-CM consent artefact and DPDP's Consent Manager obligations are related but not identical, and the sensible engineering call is one consent layer that satisfies both rather than two that argue.
We design applications aligned with DPDP Act and ABDM requirements. We do not claim to certify you; the CERT-In or STQC audit and the NHA review are independent gates, and any vendor promising to guarantee that outcome is telling you something untrue.
For the broader picture see our guides to DPDP compliance costs for Indian startups, healthcare AI deployment mistakes in Indian hospitals, and clinical AI under CDSCO and DPDP.
What eCorpIT builds
eCorpIT is a Gurugram technology consultancy founded in 2021, CMMI Level 5 assessed and MSME certified. Our healthcare engagements are structured around the milestones rather than around screens.
Data readiness first. Before any ABDM work, we assess how much of your clinical data is structured and how much is PDFs and free text. This determines your real timeline more than any other factor, and it is the assessment most vendors skip because the answer is usually unwelcome.
M1 to M3 implementation. ABHA identity and linking, then the HIP subsystems (care contexts, discovery, consent artefacts, encrypted FHIR transfer, audit logging) as separately scoped work, then HIU aggregation.
Audit preparation. Security posture built for the CERT-In or STQC review from the first sprint, not remediated after a failure.
Consent architecture that serves both regimes. One consent layer designed against ABDM's HIE-CM model and the DPDP Consent Manager timeline, ahead of the 13 November 2026 date.
Clinical workflow design. Apps that clinicians use rather than route around. Certification with no adoption is an expensive compliance artefact.
Who should not build this yet
If you run a single clinic with fewer than 20 daily consultations and paper records, ABDM certification is not your first problem. Structure your data first; the network will still be there.
If your product does not read or write clinical records, you may need M1 and nothing else. Do not let a vendor sell you M2.
If you want a fixed-price quote before anyone has looked at your data structure, no honest answer exists. The migration is the project.
FAQ
How eCorpIT can help
eCorpIT builds clinical and patient applications for Indian hospital groups and healthtech founders, scoped around the ABDM milestones and the state of your existing clinical data rather than around a feature list. Our senior engineering teams handle ABHA identity, HIP and HIU implementation on FHIR R4, and consent architecture designed against both ABDM's HIE-CM model and the DPDP Consent Manager timeline. We design applications aligned with DPDP Act and ABDM requirements, and we will tell you honestly if data structuring should come before certification. Talk to us about a data readiness assessment before you commit to a milestone plan.
References
- 100 Crore Health Records Linked with ABHA under ABDM — Press Information Bureau, Ministry of Health and Family Welfare, 22 May 2026.
- Health Data Management Policy — Ayushman Bharat Digital Mission, National Health Authority.
- Health Data Management Policy of Ayushman Bharat Digital Mission — National Portal of India.
- ABDM Integration Milestones M1 M2 M3 M4 — Nirmitee.
- ABDM FHIR Integration Guide 2026 — Adrine.
- ABDM Sandbox Integration and Exit process — CoronaSafe Network ABDM documentation.
- Milestone One (M1): ABHA and Identity Layer — AMRIT, Piramal Swasthya.
- The Ayushman Bharat Digital Mission (ABDM) — PubMed Central, National Institutes of Health.
- Healthcare App Development Cost in US, India 2026 Guide — Lunar Web Solution.
- India's DPDP Timeline: Critical Compliance Deadlines for 2026-27 — India Briefing.
Last updated: 16 July 2026.
