user linking
On Discovery, HIP responds with found care contexts
Async Callback: After receiving a discovery request at the HIP bridge URL ({bridgeUrl}/v0.5/care-contexts/discover), the HIP calls this Gateway endpoint to return the list of care contexts found for the patient.
Certification cases USER_INIT_LINK_602, USER_INIT_LINK_603, USER_INIT_LINK_604, USER_INIT_LINK_605, USER_INIT_LINK_606, USER_INIT_LINK_607
The HIP matches the patient using the demographics provided (name, gender, DOB, verified identifiers) and returns matching records. Bearer token obtained from POST /hiecm/gateway/v3/sessions A fresh UUID that you generate for this request. The callback that answers it carries the same value, so this is how you match an asynchronous reply to the call that caused it. Store it before you send the request, not after. The current time in ISO 8601, UTC, with milliseconds and a Which consent manager you are talking to. Same transactionId from the discover request received at HIP bridge HIP's internal patient reference number Patient display name Total number of care contexts in this entry Echo of the requestId from the original Gateway-to-HIP request requestId received in the original Gateway request to HIP bridgeAuthorizations
Authorizationbearer tokenRequiredHeaders
REQUEST-IDstringRequiredTIMESTAMPstringRequiredZ suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC.X-CM-IDstringRequiredsbx on the sandbox and abdm in production. A dedicated error code exists for an invalid value here, which tells you how often it is wrong.Body
transactionIdstringRequiredpatientobject[]Requiredpatient.referenceNumberstringRequiredpatient.displaystringRequiredpatient.careContextsobject[]Requiredpatient.hiTypeobject[]Requiredpatient.countintegerRequiredresponseobjectRequiredresponse.requestIdstringRequiredResponses
Callbacks
- You make this call in reply to A discovery request for a patient you may hold records for, which ABDM posts to
/api/v3/hip/patient/care-context/discover. Open the callback.