India has spent five years laying rails for health data. The Ayushman Bharat Digital Mission (ABDM), launched in September 2021, now reports more than 93 crore ABHA numbers and over 104 crore health records linked to them, with 23.21 crore Scan and Share tokens issued at facility counters, according to the Press Information Bureau backgrounder of 6 July 2026. Those are large numbers for an identity and consent layer that did not exist when most Indian hospital software was written.
For anyone building health AI on ABDM, the question is not whether the rails matter but what they actually supply. The rails were designed to move records between a hospital and a patient's app with consent. They were not designed to train models, to label data, or to validate a diagnostic algorithm. An AI builder who reads the ABDM architecture as a data lake will be disappointed; one who reads it as a plumbing standard with a consent contract attached will find it useful in ways that most other countries cannot offer.
This piece sets out, for CIOs of hospital groups, founders of health AI ventures and policymakers, what the ABDM building blocks give an AI product, what they withhold, and what an interoperability checklist for ABDM, AI and healthcare should contain before a model is placed anywhere near a clinical workflow. It draws on the National Health Authority's own guidance documents, the Health Data Management Policy and the ICMR's 2023 ethical guidelines for AI in healthcare, and it treats the practice examples as illustrative rather than evidential.
The building blocks, and what each one actually is
The NHA's own brief guide to the building blocks (version 1.1, December 2021) describes a federated design. The ABHA number is "a unique 14-digit number assigned to individuals", and the ABHA address is "a unique address similar to a virtual payment address or email ID" that the user chooses. The Health Facility Registry is "the single digital source of truth for health facilities registered on ABDM platform". The Healthcare Professionals Registry is "a comprehensive repository of healthcare professionals" and, the guide is careful to add, "will not replace existing registration issued by respective councils".
The piece that matters most for AI is the Health Information Exchange and Consent Manager (HIE-CM). The guide says it "acts as a gateway" so that a patient's linked health data is shared by a Health Information Provider (HIP) with a Health Information User (HIU) only when the ABHA owner consents. Consent can be granular, covering only selected records, and time-limited; the guide gives "48 hours or 7 days" as examples. The design statement that every AI architect should underline is this: "There is no centralized repository of healthcare records." Patient data "will be held at the Point of Care". Only registry data (ABHA, HPR, HFR) is stored centrally. The HIE-CM holds links and consent artefacts, not the records themselves.
The NHA's guidelines for HIPs, Health Repository Providers, HIUs and PHR apps (version dated 24 October 2022) add the operational detail. An HIP is "any healthcare provider who creates, stores, or distributes health information" and agrees to share it under the consent framework. An HIU is "any permitted entity that would like to access health records of an individual with their informed consent". The guidelines state that "sharing of any health records is only possible after validating the patient's consent", that "no records will be accessible to HIUs without the consent of the patient", and that HIU-held data "is bound by the rules in its consent artefact", including purpose of use and retention period. Patients can revoke consent at any time, and HIUs must be certified to honour revocation.
On format, the 2022 guidelines are specific: "All health records will use FHIR R4 resource bundles" profiled for India with NRCeS, using SNOMED-CT, LOINC and ICD-11 terminologies, across document types including diagnostic reports, discharge summaries, prescriptions, OPD consultation notes, immunisation records and wellness records. Two further lines carry consequences for AI. "HIPs must start sharing fully structured data within one year of obtaining ABDM certification." And: "Full DICOM images (Imaging studies) are not yet supported."
What ABDM gives AI in healthcare, and what it does not
Read against the needs of a model builder, the rails divide cleanly into what they supply and what they leave to the builder. The table is an original reading of the NHA documents, not an NHA statement.
Three of these rows deserve comment.
First, the consent artefact is purpose-bound. The Health Data Management Policy states that "All personal data collected and processed by the data fiduciaries should be for a specific, lawful and clear purpose", and that HIUs may not use data for other purposes. A hospital that pulls a patient's history through the HIE-CM to inform a consultation has consent for the consultation. It does not thereby acquire training data. If a venture wants records for model development, it needs either de-identified data under Clause 29, which allows anonymised or de-identified data in aggregated form "for the purpose of facilitating health and clinical research, academic research" and diagnostic solutions, subject to approval and a prohibition on any step that re-identifies a data principal, "knowingly or unknowingly"; or a separate research consent reviewed by an ethics committee. The policy does not mention artificial intelligence at all. Any AI use sits under its general research, analytics and anonymisation provisions.
Second, the absence of imaging is not a footnote. A large share of the health AI that has reached clinical use globally is radiology and pathology. In India, that work has to run on a pipeline the builder assembles with each hospital, with its own consent language and storage, and it cannot borrow ABDM's interoperability for the pixels. ABDM can still carry the report, the prescription and the discharge summary that give the image its clinical context.
Third, the structured-data window matters for timing. An HIP has a year after certification to move from documents to fully structured bundles. A model that expects coded fields will meet, in the early months of any facility's ABDM life, a mix of PDFs rendered as health document records and partially coded bundles. The practical consequence is that extraction and normalisation remain part of the AI stack even on standardised rails.
The certification path for health AI on ABDM
The NHA sandbox organises integration into milestones. As integrators describe them, M1 covers ABHA creation and verification, including the ABHA card, QR and Scan and Share at registration; M2 makes the software an HIP, linking care contexts to an ABHA, answering discovery and link callbacks, storing consents and pushing encrypted FHIR R4 bundles on request; M3 makes it an HIU, raising consent requests, fetching and decrypting records from other HIPs and purging them on revocation or expiry. One integrator's write-up notes that purging on revocation is "one of the most common certification failures", and quotes NHA Integration Support as stating that exit criteria "require any 2 milestones to be completed to exit sandbox and get the credentials for production environment". The same write-up stresses that certification is per software while deployment is per facility: each facility is registered in the HFR and configured with its own HIP identifier. The NHA developer forum confirms that test-case spreadsheets and milestone documentation are supplied on the sandbox site. These descriptions come from integrator and forum material rather than a single NHA specification page, and a builder should treat the sandbox documentation as authoritative.
For an AI venture the point is that certification tests plumbing, not intelligence. It checks that a record can be linked, consented, fetched, decrypted and purged. It says nothing about whether a triage model is safe. The two assurance regimes run in parallel, and a team that has passed M1 to M3 has demonstrated interoperability, not clinical validity.
Where the clinical assurance comes from
The ICMR's Ethical Guidelines for Application of Artificial Intelligence in Biomedical Research and Healthcare (2023) supply the other half. They set out ten principles: autonomy; safety and risk minimisation; trustworthiness; data privacy; accountability and liability; optimisation of data quality; accessibility, equity and inclusiveness; collaboration; non-discrimination and fairness; and validity. On validation, the guidelines state that "independently collected datasets other than the training dataset should be used", that "Clinical validation verifies the clinical accuracy of the AI-based solutions for a specific clinical condition", that validation should preferably be prospective and should assess usability, and that there should be local validation at each deployment site before use. They also expect the sources of training and testing data to be documented and reviewed by organisational ethics committees, and suggest that committees handling AI projects "should consider including legal experts".
Put the two regimes side by side and a sequence emerges. ABDM certification answers: can this system participate lawfully in the exchange? ICMR validation answers: does this model work, here, for these patients? A separate PanScience Research piece covers evaluation harnesses for enterprise AI in general; in health the harness has to include a prospective local arm, because the ICMR guidance asks for one and because Indian patient populations, equipment and documentation habits differ from the datasets most published models were trained on.
The economics the rails change, and the economics they do not
ABDM has altered the cost of two things. Identity resolution across facilities, once a bespoke matching exercise, is now a 14-digit number captured at registration; the PIB backgrounder cites an IIHMR study finding that Scan and Share cut registration waits from "approximately one hour" to "2 to 5 minutes". Consent, once a paper form filed in a cupboard, is now a machine-readable artefact with a retention period, which is exactly what a data protection officer needs when an AI vendor asks what the hospital is allowed to share.
The Digital Health Incentive Scheme has also moved money towards digitisation. The backgrounder reports payouts, as of 18 June 2026, of over ₹107 crore to hospitals, ₹2.95 crore to diagnostics, labs and pharmacies, and over ₹26 crore to digital solution companies, for creating interoperable records. For an HMIS vendor this is a direct subsidy for the behaviour that makes downstream AI possible: structured, linked records.
What the rails have not changed is the cost of ground truth. A record that is linked and coded is still only as good as the clinician who entered it, and a model still needs adjudicated labels, which ABDM neither produces nor pays for. Nor have they changed the cost of clinical validation, which remains a per-site, per-condition exercise. A venture's budget should therefore treat ABDM integration as a fixed engineering cost that falls with each facility, and treat labelling and validation as recurring costs that scale with each new condition and population.
A practice example
PanScience Innovations reports that one of its ventures, Parchaa, is an ABDM-compliant healthtech platform providing an HMIS and a PHR. The detail is company-reported and offered only to illustrate how the layers in this piece stack in practice: the HMIS sits as an HIP generating FHIR bundles at the point of care, the PHR sits as the consent interface for the patient, and any AI feature sits above both, consuming records only within the purpose and period of a consent artefact. A separate PanScience Research piece covers how a venture studio sequences such a build; this piece is concerned with the architecture, not the venture model.
An interoperability checklist for ABDM, AI and healthcare
The following checklist is an original synthesis of the NHA guidelines, the HDM Policy and the ICMR guidelines, written for the moment a hospital or a venture decides to put a model into an ABDM-connected workflow. It is a framework, not a regulatory text, and should be read alongside the source documents.
A team that can answer all twelve has done something more than integrate. It has aligned the exchange layer, the privacy layer and the clinical layer, which are governed by three different documents from two different bodies and are rarely read together.
What policymakers could still add
Three gaps are visible from the builder's side. The first is imaging transport, which the 2022 guidelines acknowledge is unsupported; until it arrives, the most mature class of medical AI runs outside the rails. The second is an explicit AI chapter in the Health Data Management Policy, which currently governs model development only by implication through its research and anonymisation clauses. The third is a published route from ABDM certification to clinical validation, so that a hospital procuring an AI feature from an HMIS vendor can see both attestations in one place rather than inferring the second from the first.
None of these gaps undermines the achievement. A country of India's size now has a working identity, consent and format standard for health records, and a federated design that keeps data at the point of care. That is a better foundation for health AI than a central lake would have been, because it forces every model to answer the consent question before it answers any other. The builders who do best on these rails will be the ones who accept that the rails carry records, not intelligence, and who budget for the labelling, validation and governance that turn one into the other.
Methodology and sources
This article is an analytical reading of primary ABDM documents rather than a survey. Headline ABDM figures (over 93 crore ABHA numbers, over 104 crore linked health records, 23.21 crore Scan and Share tokens as of 18 June 2026, DHIS payouts, and the IIHMR waiting-time finding) are from the Press Information Bureau backgrounder "Ayushman Bharat Digital Mission: India's Digital Health Backbone", dated 6 July 2026 (https://static.pib.gov.in/WriteReadData/specificdocs/documents/2026/jul/doc202676912801.pdf). Building-block definitions and the federated design statements are from the National Health Authority's "A brief guide on Ayushman Bharat Digital Mission (ABDM) and its various building blocks", version 1.1, 21 December 2021 (https://abdm.gov.in:8081/uploads/ABDM_Building_Blocks_v8_3_External_Version_eabbc5c0f3_4_a96f40c645.pdf). HIP and HIU definitions, consent rules, the FHIR R4 and terminology requirements, the one-year structured-data obligation and the DICOM limitation are from the NHA "Guidelines for Health Information Providers, Health Repository Providers, Health Information Users and Personal Health Records Apps", version dated 24 October 2022 (https://abdm.gov.in:8081/uploads/HIP_HIU_Guidelines_f85df336ec.pdf). Purpose limitation, data minimisation, anonymisation and research provisions are from the NDHM Health Data Management Policy (https://abdm.gov.in:8081/uploads/health_management_policy_bac9429a79.pdf). Validation and ethics-committee expectations are from the ICMR "Ethical Guidelines for Application of Artificial Intelligence in Biomedical Research and Healthcare", 2023 (https://www.icmr.gov.in/icmrobject/custom_data/pdf/Ethical- guidelines/Ethical_Guidelines_AI_Healthcare_2023.pdf). The description of sandbox milestones and the two- milestone exit criterion is drawn from an integrator's published guide (https://nirmitee.io/blog/abdm-integration- milestones-m1-m2-m3-m4-multi-software-guide) and the NHA developer forum (https://devforum.abdm.gov.in/t/mandatory-features-for-m1-m2-certification/6616); these are secondary descriptions and the sandbox documentation remains authoritative. The two tables are original frameworks derived from those documents and are illustrative. Information about Parchaa is company-reported by PanScience Innovations (https://panscience.xyz) and is used as an illustration of architecture, not as evidence of outcomes.