> ## Documentation Index > Fetch the complete documentation index at: https://developer.eka.care/llms.txt > Use this file to discover all available pages before exploring further. # ABDM > What ABDM is, who takes part in it, and what you can build with Eka's ABDM Connect. ## ABDM Connect **Ayushman Bharat Digital Mission (ABDM)** is India's national digital health infrastructure. It creates a shared ecosystem where patients, hospitals, labs, insurers, and health apps can exchange health data securely, with patient consent driving every transaction. Eka's **ABDM Connect** is a plug-and-play API and SDK suite that handles the ABDM gateway complexity for you, so your team can focus on the product rather than the plumbing. ## The ABDM Ecosystem ### Core Registries ABDM is built on four registries. Every entity gets a unique, verifiable identity through one of these. > **ABHA** > > **Ayushman Bharat Health Account** > > The patient's health identity. Can be a 14-digit **ABHA Number** (KYC-verified via Aadhaar) or an **ABHA Address** like `nisha@abdm`. All health transactions in ABDM are anchored to this. > **HPR** > > **Healthcare Professionals Registry** > > A national registry of licensed healthcare professionals. Each doctor, nurse, or practitioner gets a unique **HPR ID** for verified digital identity. > **HFR** > > **Health Facility Registry** > > A national registry of health facilities, both government and private. Each facility gets a unique **HFR ID** used for record linking and patient discovery. > **Consent Manager** > > **Consent Manager** > > Manages the consent flow between HIPs (who hold data) and HIUs (who want access). The ABDM Gateway itself acts as the Consent Manager. ### Roles in the Ecosystem There are two roles in ABDM. A product can play both. > **HIP** > > **Health Information Provider** > > Hospitals, labs, clinics, and pharmacies that generate and hold patient health records. After a visit or test, a HIP links the records to the patient's ABHA address so they're discoverable and shareable. > > *Examples: hospital HMS, diagnostic lab system, pharmacy software* > **HIU** > > **Health Information User** > > Any entity that requests access to a patient's health records with the patient's consent. After consent is granted, the HIU receives the records from the relevant HIPs. > > *Examples: insurance company, specialist referral system, wellness platform* ## CARE: the four milestones ABDM certifies hospital and lab software (HMIS/LMIS) in four milestones. Read them as CARE: **C**reate, **A**ttach, **R**etrieve, **E**nrol. Eka's ABDM Connect covers all four. **1. Create (M1): the patient's ABHA** Needed by every integration. Before any record can be linked or shared, the patient needs an ABHA. Your product lets patients create an ABHA or log in with an existing one, view and update their profile, download their ABHA card, and check in at your facility by scanning a QR code. **2. Attach (M2): records to the ABHA** Needed by hospitals, labs, clinics, and pharmacies (HIPs). After each visit or test, the records are linked to the patient's ABHA address. Patients can also find records you hold and link them themselves. When the patient consents to share them, your records are sent to whoever asked. Eka can store the records and handle sharing for you. **3. Retrieve (M3): records, with consent** Needed by anyone who wants to view a patient's records (HIUs). You ask the patient for consent, the patient approves or denies it in their app, and once approved you receive the records from every provider they chose. Patients can revoke consent at any time. **4. Enrol (M4): doctors and facilities** Needed by every hospital and lab software integration. Doctors and nurses get an HPR ID and facilities get an HFR ID, so they can take part in digital health transactions. Eka also links your facilities to Eka's bridge so records can flow. ## Journeys One patient, all of CARE. Meera walks into a clinic without an ABHA; the receptionist creates one with her Aadhaar OTP (Create) and attaches the visit to it (Attach). A month later her insurer asks for the records. She approves the request in her PHR app, and the insurer retrieves the FHIR bundle from the clinic (Retrieve). None of this works until the clinic and its doctors are enrolled in HFR and HPR (Enrol). The same story told from Meera's own app is the PHR track. Each journey below is one person's story, in product terms, linking the workflows that implement each step. | Your role | Journeys | | - | - | | Health facility software (HIP) | [Register a walk-in patient and link the visit](https://developer.eka.care/docs/hie-cm/journeys/hip-register-patient-and-link-visit.md), [Let a patient claim their old records](https://developer.eka.care/docs/hie-cm/journeys/hip-answer-discovery.md) | | Insurer, referral or analytics platform (HIU) | [Fetch a patient's records with consent](https://developer.eka.care/docs/hie-cm/journeys/hiu-fetch-records-with-consent.md) | | Patient app (PHR) | [Gather every health record in a PHR app](https://developer.eka.care/docs/hie-cm/journeys/phr-patient-aggregates-records.md) | | Facility admin or HMS vendor | [Onboard a facility and its professionals to ABDM](https://developer.eka.care/docs/hie-cm/journeys/facility-onboard-to-abdm.md) | | Consumer app on UHI | [Book an in-person doctor visit over UHI](https://developer.eka.care/docs/uhi/journeys/uhi-book-physical-consultation.md), [Pay an open bill by scanning the counter QR](https://developer.eka.care/docs/uhi/journeys/uhi-scan-and-pay.md) | ## PHR App A PHR (Personal Health Record) app is a separate ABDM track, distinct from the milestones above. It is the patient-facing side of ABDM: patients create their ABHA, see records from every provider they've visited, manage consent, and share their profile at health facilities. A PHR app typically acts as both a HIP (storing records the patient uploads) and a HIU (fetching records from other providers on the patient's behalf). It covers: * ABHA creation and patient login * A single view of every linked record * Approving or denying consent requests * **Scan & Share**: the patient scans a QR code at a facility to share their profile for registration * **Health locker**: storage the patient controls for their own documents * **Notifications** when a provider links a new record ## What You Can Build > **Hospital / Clinic Product (HMS)** > > If you run a hospital or clinic system, you need to be a HIP. After every visit or test, link the patient's records to their ABHA address. When a patient later consents to share them with another entity (like an insurer), your system serves those records automatically. > **Consumer Health App (PHR)** > > If you're building a patient-facing app, you need the PHR track on top of the milestones. Patients can bring together their entire health history from every facility they've visited, manage consent, and check in at facilities by scanning a QR code. > **Insurance / Analytics Platform (HIU)** > > If you need to access a patient's health records from any ABDM-connected provider, you need to be an HIU. You request consent from the patient and, once it is granted, receive their records directly. > **Integrated Health Platform** > > Large hospital networks and health platforms often need to be HIP, HIU, and PHR at once. Your HMS links records (HIP), doctors can pull history from outside (HIU), and patients have a portal to manage everything (PHR). ## Ready to Build? > **[ABDM Connect API Reference](https://developer.eka.care/api-sdk/hie-cm/overview.md)** > > Environments, authentication, the Postman collection, and every API and callback by milestone. > **[Onboarding & Credentials](https://developer.eka.care/api-sdk/auth/getting-started.md#overview)** > > Get your credentials and onboard into ABDM through Eka Connect. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.