> ## 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 across Eka's AI, Integrations, ABDM and Platform docs, what each one means, and the page where you meet it.

This page defines the terms you meet across Eka's developer docs, grouped by product family.

## AI

### EkaScribe

| Term | What it means | Where it is used |
| - | - | - |
| EkaScribe | Eka's AI medical scribe. You record or stream a consultation or dictation and get back a transcript and structured clinical notes in the format you define. | [EkaScribe overview](https://developer.eka.care/docs/scribe/overview) |
| EkaScribe session | One unit of work in EkaScribe, identified by a `session_id`. It ties audio capture, processing and results together: you create it, send audio, end it, then read the notes. | [Sessions overview](https://developer.eka.care/api-sdk/scribe/sessions/overview.md) |
| Template | A note format you describe in plain markdown, such as a SOAP note or a discharge summary. You name templates when you create a session, and EkaScribe returns one structured note per template. | [Create template](https://developer.eka.care/api-sdk/scribe/templates/create-template.md) |
| `pro` and `lite` | The two EkaScribe models. `pro` adds speaker diarization, custom templates and 60-minute sessions; `lite` is fast and built for dictation. | [EkaScribe overview](https://developer.eka.care/docs/scribe/overview) |

### Agents and Models

| Term | What it means | Where it is used |
| - | - | - |
| MedAssist | Eka's agentic medical assistant. Your users talk to Eka's medical LLM in real time over a session you create with your API key and then join over WebSocket. | [MedAssist](https://developer.eka.care/docs/agents/medassist.md) |
| Medical Document Parsing | The Eka API that extracts structured data from clinical documents. | [Medical Document Parsing](https://developer.eka.care/docs/models/medical-document-parsing.md) |

## Integrations

### EMR

| Term | What it means | Where it is used |
| - | - | - |
| Doctor Tool | Eka's set of APIs for clinical workflows: appointment management, digital prescriptions and access to patient records, including records linked through ABDM. | [Before you begin](https://developer.eka.care/api-sdk/emr/instructions/before-you-begin.md) |
| EMR | The Integrations product for patients, appointments and prescriptions. | [API Reference](https://developer.eka.care/api-sdk/index.md#integrations) |

### IPD, Billing and Health Records

| Term | What it means | Where it is used |
| - | - | - |
| IPD | Inpatient department. The IPD APIs cover admission, beds, nursing and discharge for patients admitted to a facility. | [IPD setup data](https://developer.eka.care/api-sdk/ipd/configuration/setup/get-ipd-setup-data.md) |
| Billing | The Integrations product for charges, deposits, invoices and payments. | [Payments](https://developer.eka.care/docs/billing/payments.md) |
| Health Records | Records, cases and vitals held on the patient's side. | [Create overview](https://developer.eka.care/api-sdk/health-records/create-overview.md) |

## ABDM

### HIE-CM: 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) |

### HIE-CM: 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) |

### HIE-CM: 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) |

### HIE-CM: 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) |

### NHCX

| Term | What it means | Where it is used |
| - | - | - |
| NHCX | National Health Claims Exchange. It carries cashless insurance claims, including PMJAY, between your hospital and the payer. ABDM Connect builds, signs and encrypts the FHIR bundles for you. | [NHCX overview](https://developer.eka.care/docs/nhcx/getting-started.md) |
| Claim | The NHCX case that every call after setup hangs off. You create one per hospitalisation and keep its `claim_id` against your admission. | [NHCX overview](https://developer.eka.care/docs/nhcx/getting-started.md) |
| Pre-auth | The NHCX request for approval you submit with the treating doctor, diagnosis, documents and answers. The payer rejects a pre-auth above the policy's wallet balance. | [NHCX overview](https://developer.eka.care/docs/nhcx/getting-started.md) |

### UHI

| Term | What it means | Where it is used |
| - | - | - |
| UHI | Unified Health Interface. You use it to search blood banks and to book in-person doctor visits for your users. | [Search blood banks over UHI](https://developer.eka.care/docs/uhi/workflows/blood-bank-search.md) |

## Platform

### Auth

| Term | What it means | Where it is used |
| - | - | - |
| Client credentials | The `client_id` and `client_secret` you create in the Eka Developer Console. You exchange them for an access token, and you keep them secret at all times. | [Authorization](https://developer.eka.care/api-sdk/auth/getting-started.md) |
| Access token | The token you get from Connect Login and send on every API request. A `401 Unauthorized` means it has expired. | [Connect Login](https://developer.eka.care/api-sdk/auth/client-login.md) |
| Refresh token | The token Connect Login returns with the access token. You use it to get a new access token after a `401`. | [Connect Refresh](https://developer.eka.care/api-sdk/auth/refresh-token-v2.md) |
| Long-lived access token | An access token for server-to-server calls between trusted systems. You use it when you do not want to manage token refresh. | [Authorization](https://developer.eka.care/api-sdk/auth/getting-started.md#long-lived-access-token) |

### Webhooks

| Term | What it means | Where it is used |
| - | - | - |
| Webhook | An HTTP callback Eka sends to your endpoint when something happens, so you do not poll. The payload carries the resource ID and the action, and you call the API for full details. | [Webhooks](https://developer.eka.care/api-sdk/webhooks/getting-started.md) |
| Webhook signature | The `Eka-Webhook-Signature` header Eka adds when you give a signing key at registration. You verify it to confirm the event came from Eka unchanged. | [Webhook signature](https://developer.eka.care/docs/webhooks/webhook-signature.md) |


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