India Has 834 Million Digital Health IDs. America Has TEFCA. Here's What the US Can Learn.

In 2021, India launched a national digital health infrastructure called ABDM — Ayushman Bharat Digital Mission. Three years later, 834 million citizens have a digital health ID, 438,000 healthcare facilities are linked, and 787 million health records flow across the system with patient-controlled consent.

In the same period, the United States finalized TEFCA — the Trusted Exchange Framework and Common Agreement — a framework designed to enable nationwide health data exchange. As of 2024, participation remains voluntary, there is no universal patient identifier, and interoperability depends on which EHR vendor your hospital uses.

This is not a criticism of either system. It is a technical comparison of two fundamentally different approaches to the same problem: how do you make a patient's health data available wherever they seek care? And it matters because Nirmitee.io is one of the very few engineering teams in the world that has built production systems on both — ABDM integrations for Indian healthcare providers and FHIR-based interoperability systems for the US market.

No one has published this comparison before. We checked.

India's ABDM: The Numbers Are Not Hype

Let these numbers sink in. India built a nationwide digital health identity system covering 60% of its 1.4 billion population in three years. For context, the US has been working toward health data interoperability since HIPAA passed in 1996 — twenty-eight years ago — and still does not have a universal patient identifier.

ABDM is not a single application. It is a set of open, interoperable building blocks — what India calls a Digital Public Infrastructure (DPI) approach. The same philosophy that built UPI (India's instant payment system that now processes 12 billion transactions per month) was applied to healthcare:

• ABHA (Ayushman Bharat Health Account) — a unique 14-digit health ID for every citizen, generated via Aadhaar (biometric ID) or mobile number. Free. Instant. No paperwork.
• Health Facility Registry (HFR) — a national registry of every hospital, clinic, lab, and pharmacy. Each facility gets a unique identifier.
• Health Professional Registry (HPR) — a registry of every licensed doctor, nurse, and health worker with verified credentials.
• Health Information Exchange (HIE) — the protocol layer that enables records to flow between providers, with patient consent.
• Consent Manager — a dedicated service that gives patients granular control over who sees their data, for what purpose, and for how long.

The genius of ABDM is that the government built the rails — identity, registry, consent, exchange protocols — and then opened it up for private companies to build applications on top. The government is the platform; the private sector builds the products.

TEFCA: The American Approach

TEFCA, finalized by the Office of the National Coordinator for Health IT (ONC) in 2022, takes a fundamentally different approach. Instead of building infrastructure, it creates a trust framework — a legal and technical agreement that enables existing health information networks to exchange data with each other.

The key components:

• RCE (Recognized Coordinating Entity) — The Sequoia Project, a nonprofit designated by ONC to manage TEFCA. It sets the rules but does not build the pipes.
• QHINs (Qualified Health Information Networks) — organizations like eHealth Exchange, KONZA, Epic Nexus, Kno2, MedAllies, and Health Gorilla that apply to become certified exchange networks. As of early 2024, there are approximately 12 designated QHINs.
• Exchange Purposes — TEFCA defines specific use cases: Treatment, Payment, Healthcare Operations, Public Health, Government Benefits, and Individual Access. Data can only be exchanged for approved purposes.
• Standard Operating Procedures — technical specifications for how QHINs connect, authenticate, and exchange data.

TEFCA made significant progress in its first year of operation. The number of records exchanged through TEFCA-designated QHINs grew from roughly 10 million to over 500 million in 2023-2024. That is real momentum. But the fundamental limitation remains: participation is voluntary.

The Architecture Gap: Platform vs. Framework

This is where the technical differences become stark. ABDM and TEFCA represent two philosophically different approaches to the same problem:

ABDM: Government-Built Platform

India built a vertically integrated stack. The government provides:

1. The identity layer (ABHA)
2. The registry layer (HFR, HPR)
3. The consent layer (Consent Manager)
4. The exchange layer (HIE protocols)
5. The sandbox and testing environment
6. Open APIs for private developers

Every layer talks to every other layer through standardized APIs. There is one consent model. One identity system. One set of APIs. If you are a hospital management software company in India, you integrate with ABDM once and you can exchange data with every other ABDM-connected facility in the country.

TEFCA: Federated Trust Network

The US chose a federated model. The government does not build infrastructure — it defines rules that existing networks must follow to participate. Each QHIN maintains its own infrastructure, its own connections, and its own business model. The RCE (Sequoia Project) coordinates but does not operate the exchange.

The result: if you are a hospital connecting to TEFCA, your experience depends on which QHIN you join. Different QHINs have different technical requirements, different onboarding processes, different pricing, and different network reach. A hospital connected to eHealth Exchange can reach other eHealth Exchange participants easily — but reaching a hospital on a different QHIN requires cross-QHIN routing that is still being built out.

The Timeline Tells the Story

India's trajectory is not just faster — it is a fundamentally different velocity:

• 2020: National Digital Health Mission announced by PM Modi
• 2021: ABHA health ID system launched. Sandbox environment opened for developers.
• 2022: 100 million ABHA IDs created. First ABDM-integrated applications go live. V1 consent framework operational.
• 2023: 500 million ABHA IDs. Insurance companies, pharmacies, and diagnostic labs joining the ecosystem. V3 APIs launched with improved gateway architecture.
• 2024: 834 million ABHA IDs. 438,000 healthcare facilities linked. Ayushman Bharat insurance claims flowing through ABDM.

The US timeline for comparison:

• 1996: HIPAA enacted — first federal health data standards
• 2009: HITECH Act and Meaningful Use — incentivized EHR adoption ($36 billion spent)
• 2016: 21st Century Cures Act — mandated information blocking rules
• 2022: TEFCA framework finalized, first QHINs designated
• 2024: 12 QHINs operational, participation still voluntary, no universal patient ID

Twenty-eight years of US policy versus three years of Indian execution. The US spent $36 billion on Meaningful Use alone — India built ABDM for a fraction of that cost using cloud-native, API-first architecture.

Feature-by-Feature: ABDM vs. TEFCA

The comparison reveals a pattern: India chose standardization and mandate at every decision point where the US chose flexibility and voluntary participation.

Patient Identity

This is the most consequential difference. ABDM has a universal patient identifier (ABHA). TEFCA does not — the US Congress has actively blocked funding for a national patient ID since 1998 (the appropriations rider has been renewed every year). Without a universal ID, patient matching across systems relies on probabilistic algorithms using name, date of birth, and address. Studies show a 7-20% mismatch rate in cross-system patient matching in the US.

Consent Architecture

ABDM built consent as infrastructure — a dedicated Consent Manager service that mediates every data exchange. A patient grants or revokes access through a consent artifact that specifies: which records, which requester, for what purpose, and for how long. The consent is digitally signed, time-bound, and auditable.

TEFCA relies on HIPAA consent rules — which broadly allow data sharing for treatment, payment, and healthcare operations without explicit patient consent. There is no equivalent of ABDM's granular, patient-controlled consent infrastructure. The US approach is simpler to implement but gives patients far less control.

Data Standards

Both systems reference FHIR (Fast Healthcare Interoperability Resources), but with different levels of commitment:

• ABDM: FHIR R4 is mandated. All Health Information Providers (HIPs) must expose FHIR-compliant APIs. The ABDM sandbox provides FHIR validation tools.
• TEFCA: FHIR is encouraged but not exclusively mandated. QHINs can exchange data in C-CDA (Consolidated Clinical Document Architecture), HL7v2, or FHIR formats. This flexibility means receiving systems must handle multiple formats.

Why India Moved Faster (It Is Not Just Political Will)

It is tempting to say India moved faster because of a top-down government mandate. That is partly true — but the real reasons are architectural:

1. No legacy burden. India did not have a $36 billion installed base of EHR systems to protect. Most Indian healthcare facilities were either paper-based or on lightweight hospital management systems. ABDM was greenfield infrastructure, not a retrofit.
2. UPI proved the model. India had already built UPI (Unified Payments Interface) using the same Digital Public Infrastructure approach — government builds the rails, private sector builds the apps. UPI processes 12 billion transactions per month. The DPI playbook was battle-tested before ABDM started.
3. Aadhaar as the identity foundation. India already had 1.3 billion biometric IDs through Aadhaar. Creating a health ID linked to Aadhaar was an extension, not a new system. The US has no equivalent biometric identity layer.
4. API-first architecture. ABDM was designed as a set of APIs from day one — not a monolithic application. Private developers could start building on the sandbox within weeks of launch. The entire V3 API gateway is publicly documented.
5. Mandate as an adoption mechanism. The Indian government tied ABDM adoption to Ayushman Bharat — a health insurance scheme covering 500 million citizens. If you want to process insurance claims under the largest government health scheme, you must integrate with ABDM. This created an economic forcing function that voluntary frameworks cannot replicate.

What the US Can Learn: Five Concrete Lessons

Lesson 1: Start with Identity

The lack of a universal patient identifier is the single biggest obstacle to US health data interoperability. Every workaround — probabilistic matching, record locator services, enterprise MPI — adds cost, complexity, and error. India solved this first, and everything else became easier. The US will not achieve true interoperability without solving patient identity.

Lesson 2: Consent Is Infrastructure, Not Policy

HIPAA treats consent as a legal framework — rules about when you can and cannot share data. ABDM treats consent as infrastructure — a technical service that mediates every exchange in real time. Building consent into the protocol layer, not just the policy layer, gives patients actual control and gives providers clear, auditable authorization for every data access.

Lesson 3: Government as Platform, Not Regulator

The US approach has been to regulate: set rules, then let the market figure out implementation. India's approach was to build: create the platform, open the APIs, then let the market build applications. The DPI model — government builds rails, private sector builds trains — produced faster adoption, lower cost, and more innovation than the regulatory-only approach.

Lesson 4: Voluntary Frameworks Stay Fragmented

TEFCA participation is voluntary. ABDM participation is tied to economic incentives (insurance reimbursement). Twenty-eight years of voluntary approaches in the US have not achieved universal interoperability. India achieved 60% population coverage in three years with mandate-driven adoption. At some point, the US will need to decide whether interoperability is optional or essential.

Lesson 5: Design for Scale from Day One

ABDM was architected for 1.4 billion people from the first design document. The API gateway, identity service, and consent manager were built to handle national scale — not retrofitted after a successful pilot. Too many US health IT initiatives start as pilots, succeed in controlled environments, and then struggle to scale because the architecture was not designed for it.

The Uncomfortable Truth

The comparison between ABDM and TEFCA reveals an uncomfortable truth for the US health IT ecosystem: a developing country with lower per-capita healthcare spending built a more comprehensive, more interoperable, more patient-controlled health data infrastructure than the richest country in the world — in a fraction of the time and cost.

This is not about technology. India did not use exotic or proprietary technology — ABDM is built on FHIR, OAuth 2.0, REST APIs, and standard cloud infrastructure. The same building blocks available to every US health IT organization.

The difference is architecture philosophy: platform vs. framework, mandate vs. voluntary, unified vs. federated, build vs. regulate.

The US has advantages India does not — a massive installed base of sophisticated EHR systems, deep clinical data standards expertise, and the financial resources to invest at scale. The question is whether those advantages will be leveraged to build true interoperability, or whether they will continue to be barriers to it.

Where Nirmitee Stands

Nirmitee.io is one of the very few engineering teams in the world that has built production systems on both ABDM and FHIR/US interoperability standards. We have implemented ABDM's HIP/HIU protocols, consent manager integrations, and ABHA ID verification for Indian healthcare providers. Simultaneously, we have built SMART on FHIR authorization servers, FHIR R4 resource APIs, and clinical data pipelines for US-market healthcare applications.

This dual expertise gives us a unique perspective that no purely US or purely Indian health IT company possesses. We understand both architectures at the protocol level — not just the marketing level.

Building health data infrastructure? Talk to our interoperability engineering team. Whether you are integrating with ABDM in India or building FHIR-based systems for the US market, we have done both — in production, at scale.