Health Information Request & Data Transfer
Validate consent, package FHIR bundles, encrypt data, and push health information to an HIU.
Handle a health information request only after HIE-CM validates consent. Then push encrypted health data directly to the HIU data push URL.
OCR-derived examples
The source stores some payload examples as OCR text from screenshots. The examples below fix obvious OCR errors and show valid JSON. Verify each payload against the current sandbox Swagger before certification.
Three stages
Initiate the request
The HIU sends a health information request through HIE-CM.
HIE-CM generates a transactionId for the exchange.
HIE-CM sends the request to the HIP bridge.
Validate and transfer data
Validate the consent ID, date range, and encryption parameters.
Prepare the matching records as FHIR bundles.
Encrypt each bundle with the HIU key material.
Push the encrypted data to the HIU dataPushUrl.
Notify completion
Notify HIE-CM after the HIP sends data. The HIU also notifies HIE-CM after it receives and processes data.
Flow
sequenceDiagram participant HIU participant CM as HIE-CM participant HIP HIU->>CM: Health information request with consentId and key material CM->>HIP: POST /api/v3/hip/health-information/request HIP->>HIP: Validate consent and date range HIP->>CM: POST /api/hiecm/data-flow/v3/health-information/hip/on-request HIP->>HIP: Build FHIR bundles HIP->>HIP: Encrypt bundles with ECDH and AES-GCM HIP->>HIU: POST <dataPushUrl>/health-information/transfer HIP->>CM: POST /api/hiecm/data-flow/v3/health-information/notify HIU->>CM: POST /api/hiecm/data-flow/v3/health-information/notify
Consent notification
HIE-CM sends consent status changes to the HIP.
The source states that HIP receives GRANTED, REVOKED, and EXPIRED.
Reject any data request for an expired or revoked consent artefact.
{
"notification": {
"status": "GRANTED",
"consentId": "<consent-id>",
"consentDetail": {
"schemaVersion": "v3",
"consentId": "<consent-id>",
"createdAt": "2026-08-11T08:36:33.000Z",
"patient": {
"id": "kiran.kumar@sbx"
},
"careContexts": [
{
"patientReference": "MRN-2026-00042",
"careContextReference": "OPD-2026-08-11-001"
}
],
"hiTypes": ["OPConsultation"],
"permission": {
"dateRange": {
"from": "2026-08-01T00:00:00.000Z",
"to": "2026-08-11T23:59:59.000Z"
},
"dataEraseAt": "2026-09-10T23:59:59.000Z"
}
}
}
}Acknowledge the consent notification.
curl -X POST "https://dev.abdm.gov.in/api/hiecm/consent/v3/request/hip/on-notify" \
-H "Authorization: Bearer <your-access-token>" \
-H "REQUEST-ID: <uuid>" \
-H "TIMESTAMP: <iso-8601-timestamp>" \
-H "X-CM-ID: sbx" \
-H "Content-Type: application/json" \
-d '{
"acknowledgement": {
"status": "OK",
"consentId": "<consent-id>"
},
"response": {
"requestId": "<notify-request-id>"
}
}'{
"status": "ACCEPTED"
}Health information request
HIE-CM sends the request to the HIP after consent validation. The request contains the HIU data push URL and key material.
{
"transactionId": "<transaction-id>",
"hiRequest": {
"consent": {
"id": "<consent-id>"
},
"dateRange": {
"from": "2026-08-01T00:00:00.000Z",
"to": "2026-08-11T23:59:59.000Z"
},
"dataPushUrl": "https://hiu.example.org/health-information/transfer",
"keyMaterial": {
"cryptoAlg": "ECDH",
"curve": "Curve25519",
"dhPublicKey": {
"expiry": "2026-08-11T15:06:33.000Z",
"parameters": "Curve25519/32byte random key",
"keyValue": "<base64-hiu-public-key>"
},
"nonce": "<base64-32-byte-nonce>"
}
}
}Acknowledge the data request before data preparation starts.
curl -X POST "https://dev.abdm.gov.in/api/hiecm/data-flow/v3/health-information/hip/on-request" \
-H "Authorization: Bearer <your-access-token>" \
-H "REQUEST-ID: <uuid>" \
-H "TIMESTAMP: <iso-8601-timestamp>" \
-H "X-CM-ID: sbx" \
-H "Content-Type: application/json" \
-d '{
"hiRequest": {
"transactionId": "<transaction-id>",
"sessionStatus": "ACKNOWLEDGED"
},
"response": {
"requestId": "<health-information-request-id>"
}
}'{
"status": "ACCEPTED"
}HIP validation checklist
Validate each request before you fetch data.
| Check | Required result |
|---|---|
| Consent status | Consent is active. It is not expired, paused, or revoked. |
| Consent ID | Consent ID matches a stored consent artefact. |
| Date range | Requested dates fit inside the consent date range. |
| Care contexts | Requested contexts belong to the consent artefact. |
| HI types | Requested HI types match the consent artefact. |
| Key material | cryptoAlg, curve, public key, and nonce are valid. |
Package FHIR bundles
Build a FHIR Bundle of type document for each health record.
Put the Composition resource first.
Include every resource referenced by the Composition.
Do not use absolute URLs for bundle references.
See FHIR & Data Standards for bundle rules and document types.
Validate the FHIR bundle
Validate each bundle before encryption. Use the NRCeS implementation guide with the FHIR validator CLI.
java -jar validator_cli.jar sample-bundle.json -ig https://nrces.in/ndhm/fhir/r4The validator checks structure, profile conformance, required fields, and constraints. Fix all errors before you encrypt the bundle.
Encrypt data at the HIP
Encrypt the bundle before you send it to the HIU. Use ECDH with Curve25519 and AES-GCM. The source states that the HIP must digitally sign the encrypted payload with its long-term private key.
See Data Encryption for the key agreement steps.
Push data to the HIU
The HIP calls the HIU dataPushUrl directly.
HIE-CM does not mediate this data-plane call.
The source states a current timeout limit of 20 minutes from request initiation.
For large data, split records into multiple pages. For very large files, use a streaming approach.
{dataPushUrl}/health-information/transferPush encrypted health information directly to the HIU.
curl -X POST "https://hiu.example.org/health-information/transfer" \
-H "Authorization: Bearer <hiu-data-push-token>" \
-H "Content-Type: application/json" \
-d '{
"pageNumber": 0,
"pageCount": 1,
"transactionId": "<transaction-id>",
"entries": [
{
"content": "<base64-encrypted-fhir-bundle>",
"media": "application/fhir+json",
"checksum": "<md5-checksum-before-encryption>",
"careContextReference": "OPD-2026-08-11-001"
}
],
"keyMaterial": {
"cryptoAlg": "ECDH",
"curve": "Curve25519",
"dhPublicKey": {
"expiry": "2026-08-11T15:06:33.000Z",
"parameters": "Curve25519/32byte random key",
"keyValue": "<base64-hip-public-key>"
},
"nonce": "<base64-hip-32-byte-nonce>"
}
}'{
"status": "ACCEPTED"
}Checksum rule
The source states that the checksum is the MD5 checksum of the data content before encryption.
Notify HIE-CM
Send a notification after the HIP transfers data.
Use TRANSFERRED or FAILED for HIP sessionStatus.
Use DELIVERED or ERRORED for each HIP hiStatus.
curl -X POST "https://dev.abdm.gov.in/api/hiecm/data-flow/v3/health-information/notify" \
-H "Authorization: Bearer <your-access-token>" \
-H "REQUEST-ID: <uuid>" \
-H "TIMESTAMP: <iso-8601-timestamp>" \
-H "X-CM-ID: sbx" \
-H "Content-Type: application/json" \
-d '{
"notification": {
"consentId": "<consent-id>",
"transactionId": "<transaction-id>",
"doneAt": "2026-08-11T08:46:33.000Z",
"notifier": {
"type": "HIP",
"id": "<hip-id>"
},
"statusNotification": {
"sessionStatus": "TRANSFERRED",
"hipId": "<hip-id>",
"statusResponses": [
{
"careContextReference": "OPD-2026-08-11-001",
"hiStatus": "DELIVERED",
"description": "Transferred"
}
]
}
}
}'{
"status": "ACCEPTED"
}Test and verify
Use a sandbox PHR app to test the full path.
- Sign in with a sandbox ABHA address.
- Register the same ABHA address in the HIP system.
- Create a health record for the patient.
- Link the care context with HIP-initiated linking.
- Grant consent from the PHR app.
- Receive the health information request at the HIP bridge.
- Encrypt and push the FHIR bundle to the HIU data push URL.
- Confirm that the PHR app displays the record.
Production base URL
The source states this production base URL for the HIE-CM APIs.
https://apis.abdm.gov.inSources
- ABDM Proposed Simplified Milestone 2 (DOCX→MD, 2026-08)