If you have ever changed hospitals, you probably know the drill. A new clinic means a new file, followed by the same old question: “Do you have your previous reports?” You search through a bag of printouts, scroll through WhatsApp to find a scan, and hope nothing is missing.
However, India’s Ayushman Bharat Digital Mission (ABDM) aims to solve exactly this problem. At the heart of this initiative lies a concept called federated architecture. Although the term sounds technical, the idea behind it is surprisingly simple.
In this blog, we will explain federated architecture in plain language, explore how it works under ABDM, and understand why it matters to patients, doctors, hospitals, and health-tech developers.
What Is ABDM?
The Ayushman Bharat Digital Mission (ABDM) is a national initiative launched by the National Health Authority (NHA). Its primary objective is to create a connected digital healthcare ecosystem where health records can move securely between hospitals, laboratories, pharmacies, and healthcare applications, but only with the patient’s consent.
To achieve this goal, ABDM provides several important building blocks:
- ABHA (Ayushman Bharat Health Account) Number: A unique 14-digit health identification number that individuals can create to participate in India’s digital healthcare ecosystem.
- ABHA Address: A user-friendly digital identifier, similar to an email address, that helps individuals access and share their health records.
- Health Facility Registry (HFR) and Healthcare Professionals Registry (HPR): Verified directories of healthcare facilities, doctors, and other healthcare professionals.
- Consent Manager and ABDM Gateway: These components manage patient consent and facilitate secure communication between different healthcare systems.
Together, these components create the foundation for ABDM’s federated architecture.
What Is Federated Architecture?
To understand federated architecture, let’s first look at how a centralised system works.
In a centralised healthcare system, different hospitals and laboratories send their patient records to one large database. As a result, all the information stays in a common location, and authorised users access it from there.
A federated system, however, follows a different approach. Instead of transferring all health records to one central database, each healthcare provider maintains its own database. The system simply creates a secure network that allows different databases to communicate whenever someone requests information.
For example, imagine a network of libraries. Each library maintains its own collection of books. However, a shared catalogue helps visitors locate books across different branches and request access when needed.
Similarly, ABDM connects healthcare providers while allowing them to maintain control over their own health records. Most importantly, patients decide who can access their information and when.
How Does Federated Architecture Work Under ABDM?
Now that we understand the basic concept, let’s explore how federated architecture works within the ABDM ecosystem.
Here is the typical process, step by step.
1. Healthcare providers create and store records
Whenever a patient visits a hospital, clinic, or laboratory, the healthcare provider creates and stores their medical records in its own information system.
These providers are known as Health Information Providers (HIPs). For example, a laboratory stores its diagnostic reports, while a hospital maintains prescriptions, discharge summaries, and consultation records.
2. Records get linked to the patient’s ABHA
Next, the healthcare provider links the patient’s visit, known as a care context, with their ABHA number or address.
This process helps connect medical records from different healthcare facilities to the same patient. At this stage, the system shares references to the records rather than transferring the complete medical information.
3. A healthcare provider requests access
Suppose a patient visits a new hospital. The treating doctor may need access to previous medical reports to understand the patient’s health history.
In the ABDM ecosystem, the doctor or healthcare application requesting this information acts as a Health Information User (HIU).
The HIU sends a request through the ABDM infrastructure, specifying the information required and the purpose of access.
4. The patient provides consent
Before sharing any health information, the system requests the patient’s permission.
The patient receives a notification through a Personal Health Records (PHR) application, such as the ABHA app. They can review the request and decide whether to approve or reject it.
Furthermore, patients can specify which records they want to share and how long the access should remain valid. Once approved, the system generates a digital consent artefact to record the permission.
5. Health records move securely between systems
Once the patient grants consent, the HIP shares the requested health information with the HIU through secure, encrypted communication channels.
The ABDM infrastructure facilitates communication, routing, and verification between the participating systems. However, the central infrastructure does not maintain a central repository of patients’ medical records.
For healthcare technology providers, an ABDM integration solution such as ABDM Connector can simplify the technical implementation and help connect existing healthcare software with the ABDM ecosystem.
6. Access expires when consent ends
Finally, the HIU can access the shared information only within the permissions granted by the patient.
Once the consent period expires, the access permission ends. Patients can also revoke their consent before the expiry date if they no longer wish to share their records.
Who Are the Key Players in ABDM’s Federated Architecture?
Several participants work together to make federated architecture function effectively. Each has a specific responsibility within the digital healthcare ecosystem.
- Patient: The individual whose health records are shared. Patients decide whether to grant, deny, or revoke access to their medical information.
- HIP (Health Information Provider): Hospitals, laboratories, clinics, and other healthcare organisations that generate and maintain patient health records.
- HIU (Health Information User): Doctors, hospitals, healthcare applications, and other authorised entities that request access to health information with patient consent.
- Consent Manager: The component responsible for managing patient consent and recording permission-related decisions.
- ABDM Gateway: The communication layer that facilitates secure interaction between participating healthcare systems.
- PHR Applications: Digital applications, including the ABHA app, that allow patients to view, manage, and share their health records.
Together, these participants help create a connected healthcare ecosystem without requiring every organisation to store its data in one central location.
Why Did ABDM Choose a Federated Architecture?
There are several important reasons why ABDM follows a federated model instead of a traditional centralised database approach.
1. Better Privacy and Data Security
First of all, federated architecture reduces the need to collect all health records in one central location. Since healthcare providers maintain their own databases, a security incident at one facility does not automatically expose the entire country’s health information.
Moreover, this approach supports privacy by design and encourages healthcare organisations to maintain appropriate security controls.
2. Greater Patient Control
Another major advantage is patient control over health information.
Under ABDM, patients can review access requests, approve or reject them, and manage the duration of consent. Therefore, healthcare providers cannot simply access a patient’s records whenever they want.
This consent-based approach also supports the broader data protection principles reflected in India’s Digital Personal Data Protection Act, 2023.
3. Easier Scalability
India has lakhs of healthcare facilities, ranging from large corporate hospitals to small clinics and diagnostic laboratories.
A centralised system would require extensive data migration and infrastructure changes across these organisations. In contrast, federated architecture allows healthcare providers to retain their existing systems while gradually connecting to the ABDM network.
As a result, different facilities can participate without replacing their entire healthcare IT infrastructure.
4. Better Interoperability Through Common Standards
Healthcare organisations often use different software platforms and data formats. Consequently, exchanging information between two systems can become difficult.
To address this challenge, ABDM promotes interoperability through standards such as HL7 FHIR for healthcare data exchange and terminologies such as SNOMED CT and LOINC.
These standards help different healthcare applications interpret and exchange medical information more consistently.
5. Reduced Data Duplication and Operational Costs
Finally, federated architecture reduces the need to maintain multiple central copies of the same medical records.
Healthcare providers can continue using their existing databases while sharing information when authorised users request it. Similarly, doctors can review previous medical reports instead of repeatedly asking patients to undergo the same investigations.
This can improve operational efficiency and reduce unnecessary healthcare expenses.
What Does Federated Architecture Mean for Different Healthcare Stakeholders?
Federated architecture offers different benefits depending on how someone participates in the healthcare ecosystem.
For Patients
Patients can access health records from multiple participating healthcare providers through connected digital platforms. Consequently, changing hospitals becomes easier because they can share relevant medical information without carrying physical files everywhere.
More importantly, patients retain control over who accesses their records.
For Doctors
Doctors can review a patient’s previous prescriptions, diagnostic reports, and medical history, subject to consent and availability.
As a result, they can make more informed clinical decisions, reduce repeated investigations, and improve continuity of care.
For Hospitals and Diagnostic Laboratories
Hospitals and laboratories can participate in India’s digital healthcare ecosystem without transferring their entire databases to a central repository.
Furthermore, they can retain their existing healthcare management systems while integrating the necessary ABDM functionalities.
For Health-Tech Developers
For healthcare software providers, ABDM creates opportunities to build interoperable applications using standardised APIs and technical specifications.
Developers can use the ABDM sandbox to understand integration requirements, test API workflows, and prepare their applications for the ecosystem.
What Are the Challenges of Federated Architecture Under ABDM?
Although federated architecture offers several advantages, its implementation also comes with practical challenges.
First, healthcare providers need to digitise their existing medical records and establish reliable processes for linking patient information with ABHA.
Second, adoption levels vary across states and healthcare facilities. While larger hospitals may have dedicated IT infrastructure, smaller clinics and rural healthcare centres can face financial and technical limitations.
Additionally, internet connectivity, data quality, and inconsistent record formats can affect information exchange between different systems.
Another important challenge involves technical integration. Healthcare software providers must implement consent workflows, secure data exchange, encryption, callbacks, and interoperability standards correctly.
Therefore, successful ABDM adoption requires more than simply connecting an application to an API. Healthcare organisations also need reliable technology, proper implementation, and ongoing technical support.
Final Thoughts
Federated architecture is one of the most important concepts behind the Ayushman Bharat Digital Mission. Rather than creating one massive database containing everyone’s medical records, ABDM connects different healthcare systems while allowing providers to maintain their own data.
Through consent-based sharing, standardised communication, and interoperability, this approach aims to make healthcare information more accessible and secure.
For patients, it means greater control over medical records. For doctors, it means better access to relevant patient history. Similarly, for hospitals and healthcare technology companies, it creates an opportunity to participate in India’s growing digital healthcare ecosystem.
If you are a patient, creating an ABHA number is a useful first step towards participating in this ecosystem. On the other hand, if you are a hospital, HMIS provider, EMR company, or health-tech developer, exploring ABDM integration and the official sandbox can help you understand the technical requirements.
ABDM Connector helps healthcare software providers simplify ABDM integration by connecting their existing systems with India’s digital health infrastructure.