> ## 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.

# Glossary

> The terms used in the ABDM Connect docs, what each one means, and the page where you meet it.

The terms you meet in the ABDM Connect docs. Follow the link in the last column to see a term in context.

## Ecosystem and roles

| Term | What it means | Where it is used |
| - | - | - |
| ABDM | Ayushman Bharat Digital Mission, India's national digital health infrastructure. Patients, hospitals, labs, insurers and health apps exchange health data through it, with the patient's consent driving every exchange. | [ABDM overview](https://developer.eka.care/docs/hie-cm/about.md) |
| ABDM Connect | Eka's REST API over the ABDM gateway. You call Eka, and Eka handles ABDM's gateway protocol, encryption and callbacks for you. | [ABDM Connect overview](https://developer.eka.care/api-sdk/hie-cm/overview.md) |
| CARE | How these docs name the four ABDM milestones: Create (M1, the patient's ABHA), Attach (M2, records to the ABHA), Retrieve (M3, records with consent), Enrol (M4, doctors and facilities in HPR and HFR). | [What is ABDM Connect](https://developer.eka.care/docs/hie-cm/about.md#care-the-four-milestones) |
| HIE-CM | The ABDM family that covers ABHA, care contexts, consent and records. Its specification also sets the ECDH scheme used to encrypt records in transit. | [Encryption](https://developer.eka.care/docs/hie-cm/care-contexts/ecdh-encryption.md) |
| Consent Manager | The ABDM registry that manages consent between the parties that hold data and the parties that want it. The ABDM gateway itself acts as the Consent Manager. | [ABDM overview](https://developer.eka.care/docs/hie-cm/about.md#core-registries) |
| HIP | Health Information Provider. A hospital, lab, clinic or pharmacy that holds patient records and links them to the patient's ABHA address so they can be found and shared. | [Link a care context as a HIP](https://developer.eka.care/docs/hie-cm/workflows/link-care-context-hip.md) |
| HIU | Health Information User. Any party, such as an insurer or referral system, that requests a patient's records with consent and receives them from the HIPs. | [Request a patient's consent as a HIU](https://developer.eka.care/docs/hie-cm/workflows/hiu-request-consent.md) |
| PHR app | A personal health record app, the patient-facing side of ABDM. It usually acts as both a HIP for records the patient uploads and a HIU for records it fetches. | [Gather every health record in a PHR app](https://developer.eka.care/docs/hie-cm/journeys/phr-patient-aggregates-records.md) |
| Milestone | One of the four stages, M1 to M4, in which ABDM certifies hospital and lab software. They cover identity, linking, consent and registries. | [ABDM overview](https://developer.eka.care/docs/hie-cm/about.md#abdm-milestones) |
| HPR | Healthcare Professionals Registry. Each doctor, nurse or practitioner on it gets a unique HPR ID as a verified digital identity. | [Create an HPR ID with Aadhaar OTP](https://developer.eka.care/docs/hie-cm/workflows/create-hpr-id.md) |
| HFR | Health Facility Registry. Each government or private facility on it gets a unique HFR ID, used for record linking and patient discovery. | [Register and onboard a facility](https://developer.eka.care/docs/hie-cm/workflows/register-hfr.md) |

## Patient identity

| Term | What it means | Where it is used |
| - | - | - |
| ABHA | Ayushman Bharat Health Account, the patient's health identity. Every health transaction in ABDM is anchored to it. It takes the form of an ABHA number or an ABHA address. | [ABDM overview](https://developer.eka.care/docs/hie-cm/about.md#core-registries) |
| ABHA number | The 14-digit, KYC-verified form of an ABHA. You create one from an Aadhaar OTP, with Aadhaar as the KYC. | [Create an ABHA with Aadhaar OTP](https://developer.eka.care/docs/hie-cm/workflows/create-abha-aadhaar-otp.md) |
| ABHA address | The patient's ABHA handle, such as `shyam@abdm`. A HIP links records to it. You can create one without KYC from a mobile OTP. | [Create an ABHA address with mobile OTP](https://developer.eka.care/docs/hie-cm/workflows/create-abha-mobile-otp.md) |
| ABHA Gateway session | The patient's session with the ABHA Gateway, separate from your client token. Creating or registering an ABHA opens it, and patient-scoped calls without a live session return HTTP `491`. | [Hold the ABHA Gateway session](https://developer.eka.care/docs/hie-cm/workflows/hold-gateway-session.md) |
| Scan & Share | The patient scans your facility's QR code with a PHR app to share their ABHA profile. Eka sends you the profile on a webhook, and you reply with an OPD token. | [Receive a scanned profile as a HIP](https://developer.eka.care/docs/hie-cm/workflows/hip-scan-and-share.md) |

## Records and consent

| Term | What it means | Where it is used |
| - | - | - |
| Care context | A visit, test or admission at your facility, linked to the patient's ABHA address. Once linked, it is registered with ABDM, and any HIU the patient consents to can request it. | [Link a care context as a HIP](https://developer.eka.care/docs/hie-cm/workflows/link-care-context-hip.md) |
| Linking | Registering a care context under the patient's ABHA. You link new records yourself; the patient links older records through discovery. Linking returns `202 Accepted` and confirms on the `abha.link_care_context` webhook. | [Link a care context as a HIP](https://developer.eka.care/docs/hie-cm/workflows/link-care-context-hip.md) |
| Discovery | A patient searches your facility from a PHR app for records that were never linked to their ABHA. You answer three webhooks: return the matches, send an OTP, then confirm the link. | [Answer discovery and link old records](https://developer.eka.care/docs/hie-cm/workflows/hip-discovery-and-link.md) |
| FHIR bundle | The record format a HIP sends for a care context. If Eka stores your data, you send it base64-encoded in the `data` field when you link. Otherwise you build and encrypt it on each fetch request. | [Serve records on a fetch request](https://developer.eka.care/docs/hie-cm/workflows/serve-data-on-fetch.md) |
| HI type | Health information type, the kind of record in a care context, for example `OPConsultation` or `Prescription`. You send it as `hi_type` when you link, and a fetch request lists the `hi_types` the HIU wants. | [Link a care context as a HIP](https://developer.eka.care/docs/hie-cm/workflows/link-care-context-hip.md) |
| Consent request | A HIU's request for a patient's records. It appears in the patient's PHR app, where they approve or deny it, and its status changes arrive on the `abha.consent_update` webhook. | [Request a patient's consent as a HIU](https://developer.eka.care/docs/hie-cm/workflows/hiu-request-consent.md) |
| Consent artefact | The record ABDM generates when a patient approves a consent request, one per HIP. An expired artefact returns `ABDM-1061`, and you raise a new consent. | [Approve, deny or revoke a consent in a PHR app](https://developer.eka.care/docs/hie-cm/workflows/phr-act-on-consent.md) |
| Consent PIN | The PIN a patient sets in a PHR app and verifies when they approve, deny or revoke a consent. | [Approve, deny or revoke a consent in a PHR app](https://developer.eka.care/docs/hie-cm/workflows/phr-act-on-consent.md) |
| Auto-approval | A policy that lets the patient authorise a class of consent requests once, instead of approving each one. | [Set up the patient's health locker](https://developer.eka.care/docs/hie-cm/workflows/set-up-health-locker.md) |
| Health locker | Storage the patient controls for their own records. When auto-approval is on, your PHR app is the locker, and Eka tells it each time a HIP links a new record. | [Set up the patient's health locker](https://developer.eka.care/docs/hie-cm/workflows/set-up-health-locker.md) |
| Subscription | The standing arrangement Eka sets up with auto-approval. It sends `abha.subscription_notify` when a provider links a new record for the patient, and `abha.subscription_modified` when it changes. | [Set up the patient's health locker](https://developer.eka.care/docs/hie-cm/workflows/set-up-health-locker.md) |
| ECDH | The encryption scheme for records sent between HIPs and HIUs: ECDH key agreement on Curve25519, with HKDF-SHA256 and AES-256-GCM. If Eka stores your records, Eka encrypts and decrypts them for you. | [Encryption](https://developer.eka.care/docs/hie-cm/care-contexts/ecdh-encryption.md) |

## Identifiers and fields

| Term | What it means | Where it is used |
| - | - | - |
| OID (Eka user ID) | Eka's ID for a patient, returned as `eka.oid` when an ABHA is created or the patient logs in. You send it in the `X-Pt-Id` header or the `oid` query parameter on later calls. | [ABDM Connect overview](https://developer.eka.care/api-sdk/hie-cm/overview.md#common-headers) |
| Partner patient ID | Your own ID for the patient, sent in the `X-Partner-Pt-Id` header. | [ABDM Connect overview](https://developer.eka.care/api-sdk/hie-cm/overview.md#common-headers) |
| HIP ID | The ID of the facility a call is made from, sent in the `X-Hip-Id` header. On NHCX calls it selects the facility that raises the claim. | [ABDM Connect overview](https://developer.eka.care/api-sdk/hie-cm/overview.md#common-headers) |
| `txn_id` | The transaction ID that the first call of an OTP or linking flow returns. You send it back on every later step of that flow. | [ABDM Connect overview](https://developer.eka.care/api-sdk/hie-cm/overview.md#multi-step-flows) |
| `skip_state` | A field in the Aadhaar OTP verify response that tells you the next call. Its values are `confirm_mobile_otp`, `abha_create` and `abha_select`. | [Create an ABHA with Aadhaar OTP](https://developer.eka.care/docs/hie-cm/workflows/create-abha-aadhaar-otp.md) |
| `source_error` | The part of an ABDM Connect error body that carries ABDM's own code when the gateway refuses a call, such as `ABDM-1010`. | [Errors](https://developer.eka.care/docs/hie-cm/errors.md) |

For terms from every Eka product, see the [Eka glossary](https://developer.eka.care/docs/get-started/glossary.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.