Skip to main content
Once records are linked and consent is in place, the PHR app’s job is to show them. An ABHA address can carry thousands of documents across dozens of providers, so listing is deliberately two-stage: providers first, then care contexts within a provider.

​
Step 1 — List linked providers

​
Step 2 — List care contexts for a provider

Care Contexts overview →

​
Step 3 — Get the actual data

Listing gives you metadata. To read a document, the patient must have granted consent — then the FHIR bundle reaches you one of two ways, depending on how your integration stores data.

You store the data

You receive abha.hiu_data_push with the encrypted FHIR bundle and the key_information needed to decrypt it.Register your public keyset first with PATCH /abdm/v1/hiu/keyset — EKA shares it with the HIP so they can encrypt for you.Acknowledge parsing status via POST /abdm/v1/hiu/care-context/data/on-push.

EKA stores the data

Nothing to decrypt. Call GET /health/api/v1/fhir/retrieve with the care_context_id as the identifier.Get the care_context_id from Consent Details after approval.
ECDH encryption explained →

​
Patient-uploaded records (health locker)

A PHR app is also a HIP for anything the patient uploads themselves — a scanned prescription, an old lab report. Uploading through the Medical Records APIs automatically creates a care context, so the document becomes discoverable and shareable like any facility record. Medical Records — Add → · Read →
Storing records on EKA has a second benefit: when an HIU later requests that care context, EKA serves the data automatically and you never receive the abha.hip_data_fetch webhook.