ABDM vs TEFCA (2026): How India's and America's National Health Data Networks Compare

ABDM (Ayushman Bharat Digital Mission) is India's government-run digital health platform: one health ID for every person (ABHA), national registries of facilities and professionals, and a gateway with a consent manager through which records move only after the patient approves each request. TEFCA (the Trusted Exchange Framework and Common Agreement) is the US approach: a set of rules under which existing networks, called QHINs, agree to exchange records with each other for defined purposes. ABDM is a platform the government builds and operates; TEFCA is a framework the government governs while private networks operate.

Both are now running at national scale. By May 2026, according to India's Press Information Bureau, more than 100 crore (1 billion) health records were linked to more than 90 crore ABHA accounts. In June 2026, HHS announced that records exchanged through TEFCA had grown from 10 million to more than 1 billion in less than a year. This guide compares the two on architecture, identity, consent, standards and participation, and explains what each means for teams that build health software. Updated September 2026.

ABDM vs TEFCA at a glance

What is ABDM? Meaning and how it works

The ABDM meaning in full is Ayushman Bharat Digital Mission, launched nationally by the National Health Authority in September 2021. It is built as digital public infrastructure: the government provides shared building blocks and private software connects to them.

• ABHA (Ayushman Bharat Health Account): a 14-digit health ID and an ABHA address for each person.
• HFR and HPR: national registries of health facilities and healthcare professionals.
• The ABDM gateway and HIE-CM: the health information exchange and consent manager through which every record request, consent and data transfer is routed.
• PHR apps: patient apps where people see their records, link them and approve or revoke consent.

The gateway and protocols of the ABDM technology stack are the same for every participant: a gateway session token for every call, asynchronous REST APIs that answer through callbacks to your registered bridge URL, FHIR R4 records, and Fidelius encryption for every data transfer. Software joins through three milestones: M1 for ABHA, M2 to share records as a Health Information Provider (HIP), and M3 to fetch records as a Health Information User (HIU). Our ABDM integration step-by-step guide walks through each one, and our ABDM integration services team builds them for hospital software and health apps.

What TEFCA is, and how it works

TEFCA is the US framework for nationwide health information exchange under the 21st Century Cures Act. Instead of building one national platform, it sets common rules that existing networks sign up to:

• ONC (the Office of the National Coordinator for Health IT) sets policy and oversees the framework.
• The Recognized Coordinating Entity, the Sequoia Project, manages the Common Agreement, the standard operating procedures and the designation of networks.
• QHINs (Qualified Health Information Networks) connect to each other and carry the exchange. The RCE lists 11 designated QHINs: CommonWell Alliance, eClinicalWorks/PrismaNet, eHealth Exchange, Epic Nexus, Health Gorilla, Kno2, Konza Health, MedAllies, Netsmart, Oracle Health Information Network and Surescripts Health Information Network.
• Participants and subparticipants (hospitals, practices, health apps) connect through a QHIN.
• Exchange purposes define why data may move: treatment, payment, health care operations, public health, government benefits determination and individual access services.

In June 2026 ONC also announced a new oversight contract and additional reviews of QHINs and their participants to check they follow TEFCA requirements, alongside the one-billion-record milestone.

Platform vs framework: the architecture difference

The core difference is who builds the rails. In India the government operates one gateway and one consent manager, so software that integrates with ABDM once can exchange records with every other ABDM participant. In the US the government defines the rules, and each QHIN runs its own infrastructure, onboarding and pricing; your reach depends on which QHIN you join and how it connects to the others.

For a software team this changes the integration plan. ABDM is one set of APIs, one sandbox and one certification process run by NHA. TEFCA is a contract and technical onboarding with a chosen QHIN, whose APIs and requirements you then implement, usually alongside direct EHR integrations for data TEFCA does not yet carry.

Patient identity: ABHA vs demographic matching

ABDM gives each person an ABHA number and address, so a record can be linked to the right person with certainty. Our ABDM milestones guide covers how ABHA creation and verification work in software.

The US has no national, universal patient identifier; a long-standing appropriations restriction has kept HHS from funding one. TEFCA networks therefore match patients on demographics such as name, date of birth, sex and address, and each network and participant runs its own matching. For builders, this means patient matching and duplicate handling are part of every US exchange project, while in India the ABHA link carries that weight.

Consent: per-request artefacts vs permitted purposes

ABDM treats consent as infrastructure. A doctor or app raises a consent request with a purpose, record types and date range; the patient approves or denies it in a PHR app; approved requests produce a consent artefact that both sides must honour; records travel encrypted; and when consent is revoked or expires, the requester must delete the data. Our ABDM HIU guide shows how software implements that.

TEFCA works through exchange purposes. A request states its purpose, the responding organization checks it against the framework's rules and applicable law (HIPAA and state law), and shares if permitted. Patients can use individual access services to get their own records, but whether a patient can block a particular exchange depends on the organizations and states involved.

Data standards: FHIR mandated vs mixed formats

ABDM records are FHIR R4 bundles built to the NRCeS implementation guide: OP consultation notes, prescriptions, discharge summaries, diagnostic reports and others. Everything that moves through ABDM uses the same profiles, which is why our ABDM FHIR bundles guide matters for every HIP.

TEFCA began with document exchange, mostly C-CDA, and has added FHIR-based exchange. Receivers should expect both, and US software usually also needs FHIR APIs for other programs, such as the ONC certification criteria and CMS interoperability rules.

Why ABDM scaled so quickly

• Identity came first. ABHA builds on Aadhaar and mobile verification, so a health ID could be issued at the registration desk.
• Few legacy systems. Many Indian facilities were on paper or lightweight systems, so ABDM was new infrastructure rather than a retrofit.
• Digital public infrastructure. The government built shared rails and let private software build on them, the same model India used for payments.
• Scheme incentives. ABDM is linked to government health schemes; PMJAY hospitals see incentives tied to ABDM compliance. Our ABDM compliance guide for PMJAY hospitals explains that link.

TEFCA's growth has a different engine: large networks that already connected thousands of organizations (national EHR networks, e-prescribing and HIE networks) became QHINs, so participation arrived in blocks rather than facility by facility.

Timeline: how ABDM and TEFCA got here

How a hospital or software vendor joins each network

For the ABDM side in detail, see our ABDM certification process guide.

What each country can learn from the other

• For the US: a reliable identifier and consent built into the protocol reduce matching errors and make every access auditable; a single operated gateway makes onboarding one process instead of many.
• For India: TEFCA's written operating procedures, designated purposes and formal oversight of networks show how a federated ecosystem stays accountable as private participants multiply, and its individual access services model is a useful reference for PHR apps.
• For both: scale came from linking exchange to things organizations already do every day, from registration desks in India to existing networks in the US.

What it means for teams that build health software

Where we stand

We build on both sides. In India we have taken hospital software through ABDM's HIP and HIU milestones, including an HMIS that has cleared sandbox exit and runs ABDM in production, and a live M3 test in September 2026 in which every value of every test record arrived intact (526 of 526 values, 30 of 30 attachments). In the US we build FHIR APIs and SMART on FHIR applications and servers, tested against ONC's Inferno test kits. The two share more at the protocol level than their policies suggest: FHIR, OAuth-based access and asynchronous exchange.

Building for India, the US or both? Our ABDM integration and FHIR integration teams can plan the integration layer with you. Talk to our team.