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 |
| 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 |
| 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 |
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 |
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 |
| Medical Document Parsing | The Eka API that extracts structured data from clinical documents. | Medical Document Parsing |
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 |
| EMR | The Integrations product for patients, appointments and prescriptions. | API Reference |
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 |
| Billing | The Integrations product for charges, deposits, invoices and payments. | Payments |
| Health Records | Records, cases and vitals held on the patient’s side. | Create overview |
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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
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 |
| 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 |
| 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 |
| 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 |
| 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 |
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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
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 |
| Partner patient ID | Your own ID for the patient, sent in the X-Partner-Pt-Id header. | ABDM Connect overview |
| 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 |
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 |
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 |
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 |
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 |
| 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 |
| 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 |
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 |
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 |
| Access token | The token you get from Connect Login and send on every API request. A 401 Unauthorized means it has expired. | Connect Login |
| 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 |
| 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 |
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 |
| 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 |

