Receive the encrypted records at the data push URL, as the HIU
Hosted by the HIU at the dataPushUrl it supplied in on-share, not by ABDM. The PHR application posts here directly; the path is whatever the data push URL names.
The PHR app sends the records covered by the share, one entry per care context, each an encrypted FHIR bundle with its checksum, along with the PHR app's own ECDH key material so the HIU can derive the shared key and decrypt. The shape below is the placeholder body in NHA's Postman collection; it follows the M2 and M3 health information transfer. JWT access token issued by the ABDM session API after successful validation of client id and secret. Random UUID, a v4 style guid, unique per callback. ISO 8601 timestamp of when the callback was sent. This page, counting from 0. How many pages the transfer has. The transfer's identifier, from the share request. One entry per care context shared. Encrypted content of data packaged in a FHIR bundle. MIME type of the content. Checksum of the content. ECDH key material for encrypting the records. The public key, base64. A 32 byte random nonce for this transfer. Accepted. Decrypt, then call notify with RECEIVED, PARTIAL_RECEIVED or FAILED.Authorizations
Authorizationbearer tokenRequiredHeaders
request-idstringRequiredtimestampstringRequiredBody
pageNumberintegerRequiredpageCountintegerRequiredtransactionIdstringRequiredentriesobject[]Requiredentries.contentstringentries.mediastringentries.checksumstringentries.careContextReferencestringkeyMaterialobjectRequiredkeyMaterial.cryptoAlgstringRequiredkeyMaterial.curvestringRequiredkeyMaterial.dhPublicKeyobjectRequiredkeyMaterial.dhPublicKey.expirystringRequiredkeyMaterial.dhPublicKey.parametersstringRequiredkeyMaterial.dhPublicKey.keyValuestringRequiredkeyMaterial.noncestringRequiredResponses
202
Where this fits
You produce this callback by calling Reply to a share request with the data push URL and the encryption key..