# Find Bridge Service by Service ID `GET /api/hiecm/gateway/v3/bridge-service/serviceId/{serviceId}` Look up a specific registered HIP/HIU service by its service ID. ```bash curl --request GET \ --url https://dev.abdm.gov.in/api/hiecm/gateway/v3/bridge-service/serviceId/{serviceId} \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` returned by `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. It is how you and the gateway correlate a call with its callback and with a support ticket, so log it. Reusing one across requests makes both impossible. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. Sending the wrong one against the right host is a common first-day failure and reads as an authorisation error. ## Path parameters - `serviceId` (string, required): Service identifier ## Responses - `200`: Service details Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "id": 0, "bridgeId": "", "serviceId": "", "name": "", "isHip": false, "isHiu": false, "isHealthLocker": false, "isPhr": false, "active": false, "registerTime": "2026-08-24T10:15:30.000Z", "dateCreated": "2026-08-24T10:15:30.000Z", "dateModified": "2026-08-24T10:15:30.000Z" } ``` --- # Get Gateway JWKS Certificates `GET /api/hiecm/gateway/v3/certs` Get the JSON Web Key Set (JWKS) to verify JWT signatures in gateway callbacks. ```bash curl --request GET \ --url https://dev.abdm.gov.in/api/hiecm/gateway/v3/certs \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' ``` ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. It is how you and the gateway correlate a call with its callback and with a support ticket, so log it. Reusing one across requests makes both impossible. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. ## Responses - `200`: JWKS response Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "keys": [ { "kid": "", "kty": "", "alg": "", "use": "", "n": "", "e": "", "x5c": [ "" ], "x5t": "", "x5t2": "" } ] } ``` --- # Get OIDC Discovery Document `GET /api/hiecm/gateway/v3/.well-known/openid-configuration` OIDC discovery endpoint for the ABDM Gateway. ```bash curl --request GET \ --url https://dev.abdm.gov.in/api/hiecm/gateway/v3/.well-known/openid-configuration \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' ``` ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. It is how you and the gateway correlate a call with its callback and with a support ticket, so log it. Reusing one across requests makes both impossible. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. ## Responses - `200`: OpenID Connect configuration Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "issuer": "", "authorization_endpoint": "", "token_endpoint": "", "jwks_uri": "", "response_types_supported": [ "" ], "subject_types_supported": [ "" ], "id_token_signing_alg_values_supported": [ "" ] } ``` --- # Get a provider by id `GET /api/hiecm/gateway/v3/providers/{provider-id}` Look up one provider by its provider id. ```bash curl --request GET \ --url https://dev.abdm.gov.in/api/hiecm/gateway/v3/providers/{provider-id} \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` returned by `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. It is how you and the gateway correlate a call with its callback and with a support ticket, so log it. Reusing one across requests makes both impossible. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. Sending the wrong one against the right host is a common first-day failure and reads as an authorisation error. ## Path parameters - `provider-id` (string, required): Provider identifier. ## Responses - `200`: Provider details. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "identifier": { "name": "", "id": "" }, "facilityType": [ "HIP" ], "isHIP": false } ``` --- # List All Bridge Services `GET /api/hiecm/gateway/v3/bridge-services` List all HIP/HIU services registered under the authenticated bridge. ```bash curl --request GET \ --url https://dev.abdm.gov.in/api/hiecm/gateway/v3/bridge-services \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` returned by `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. It is how you and the gateway correlate a call with its callback and with a support ticket, so log it. Reusing one across requests makes both impossible. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. Sending the wrong one against the right host is a common first-day failure and reads as an authorisation error. ## Responses - `200`: List of registered bridge services Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "bridge": { "id": "", "name": "", "url": "", "active": false, "blocklisted": false }, "services": [ "" ] } ``` --- # List government programs `GET /api/hiecm/gateway/v3/govt-programs` List government programs registered with the gateway. The response items share the same shape, field for field, as the provider-by-id response. That shape has not been observed against the sandbox. ```bash curl --request GET \ --url https://dev.abdm.gov.in/api/hiecm/gateway/v3/govt-programs \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` returned by `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. It is how you and the gateway correlate a call with its callback and with a support ticket, so log it. Reusing one across requests makes both impossible. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. Sending the wrong one against the right host is a common first-day failure and reads as an authorisation error. ## Responses - `200`: Government programs. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "identifier": "", "facilityType": [ "HIP" ], "isHIP": false } ] ``` --- # List health-locker-enabled providers `GET /api/hiecm/gateway/v3/health-lockers` List providers with health locker functionality enabled, optionally filtered by name. ```bash curl --request GET \ --url https://dev.abdm.gov.in/api/hiecm/gateway/v3/health-lockers \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` returned by `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. It is how you and the gateway correlate a call with its callback and with a support ticket, so log it. Reusing one across requests makes both impossible. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. Sending the wrong one against the right host is a common first-day failure and reads as an authorisation error. ## Query parameters - `name` (string): Filter by locker name. ## Responses - `200`: Health-locker-enabled providers. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "identifier": "", "facilityType": [ "HIP" ], "isHip": false, "isGovtEntity": false, "endpoints": { "healthLockerEndpoints": [ "" ] } } ] ``` --- # List providers by name `GET /api/hiecm/gateway/v3/providers` List ABDM-registered providers, optionally filtered by name. ```bash curl --request GET \ --url https://dev.abdm.gov.in/api/hiecm/gateway/v3/providers \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` returned by `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. It is how you and the gateway correlate a call with its callback and with a support ticket, so log it. Reusing one across requests makes both impossible. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. Sending the wrong one against the right host is a common first-day failure and reads as an authorisation error. ## Query parameters - `name` (string): Filter providers by name. ## Responses - `200`: Matching providers. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "identifier": "", "facilityType": [ "HIP" ], "isHIP": false, "isHiu": false, "isHealthLocker": false, "isPhr": false, "isGovtEntity": false, "endpoints": { "healthLockerEndpoints": [ "" ] } } ] ``` --- # Register / Update Bridge Services (HIU) `POST /v4/int/v1/bridges/MutipleHRPAddUpdateServices` Registers or updates one or more HIU service entries under a facility in the HSP Registry. Set `type` to `"HIU"` for Health Information User registration. **Base URL:** `https://apihspsbx.abdm.gov.in` ```bash curl --request POST \ --url https://dev.abdm.gov.in/v4/int/v1/bridges/MutipleHRPAddUpdateServices \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "facilityId": "IN07100XXXXX", "facilityName": "City Health HIU", "HRP": [ { "bridgeId": "BRIDGE_HIU_001", "hipName": "City Health HIU", "type": "HIU", "active": true } ] }' ``` ## Authorization - `Authorization` (bearer token, required): JWT Bearer token from `POST /api/hiecm/gateway/v3/sessions`. Header: `Authorization: Bearer {accessToken}` ## Body - `facilityId` (string, required) - `facilityName` (string, required) - `HRP` (object[], required) - `HRP.bridgeId` (string, required) - `HRP.hipName` (string, required) - `HRP.type` (string, required) One of: HIP, HIU. - `HRP.active` (boolean, required) ## Responses - `200`: HIU service registered/updated successfully - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/gateway/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 --- # Create a session and get an access token `POST /api/hiecm/gateway/v3/sessions` Send the client id and client secret from your ABDM sandbox registration. The response carries a bearer token that every module API accepts in the `Authorization` header. This is the one call that does not itself need a bearer token, which is why `security` is empty here. The token is short lived. Read `expiresIn` from the response rather than assuming a duration, and refresh before it runs out instead of waiting for a 401. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/gateway/v3/sessions \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' \ --header 'Content-Type: application/json' \ --data '{ "clientId": "", "clientSecret": "", "grantType": "client_credentials" }' ``` ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. It is how you and the gateway correlate a call with its callback and with a support ticket, so log it. Reusing one across requests makes both impossible. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. Sending the wrong one against the right host is a common first-day failure and reads as an authorisation error. ## Body - `clientId` (string, required): The client id issued when you registered on the ABDM sandbox. - `clientSecret` (string, required): The client secret issued alongside the client id. It is a credential. Keep it server side, never in a mobile or browser build. - `grantType` (string, required): The only accepted value is `client_credentials`. ## Responses - `200`: A session was created and a bearer token was issued. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "accessToken": "", "expiresIn": 0, "refreshExpiresIn": 0, "refreshToken": "", "tokenType": "bearer" } ``` --- # Update HIP/HIU Bridge Callback URL `PATCH /api/hiecm/gateway/v3/bridge/url` Register the HIP/HIU callback URL with the ABDM Gateway. All gateway push notifications (e.g. patient-share) are delivered to this URL. ```bash curl --request PATCH \ --url https://dev.abdm.gov.in/api/hiecm/gateway/v3/bridge/url \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' \ --header 'Content-Type: application/json' \ --data '{ "url": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` returned by `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. It is how you and the gateway correlate a call with its callback and with a support ticket, so log it. Reusing one across requests makes both impossible. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. Sending the wrong one against the right host is a common first-day failure and reads as an authorisation error. ## Body - `url` (string, required): HTTPS callback URL for the HIP/HIU ## Responses - `200`: Bridge URL updated successfully Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "" } ``` --- # Gateway session errors Seeing a symptom rather than a code? Start at [Troubleshooting](/docs/hiecm/v3/troubleshooting/). ## Codes Code, message and error name are as published. The action column reads the message text by a documented rule, and says Unclassified where the rule could not classify one. | Code | Message | What to do | | ----------- | ----------------------------------------------------------------------------------------------------------------------- | -------------- | | `ABDM-1053` | Problem occurred while loading overlay image | Unclassified | | `ABDM-1068` | Both Patient and Error details cannot be null | Fix request | | `ABDM-1069` | Invalid Authentication type | Fix request | | `ABDM-1073` | if is applicable for all HIP's is true;then HIP object must be null | Unclassified | | `ABDM-1076` | One or more invalid HIP is exist in the request | Fix request | | `ABDM-1088` | Captcha verification failed, Please enter valid code. | Unclassified | | `ABDM-1089` | Payment information cannot be null | Fix request | | `ABDM-1096` | Duplicate Gateway Consent Manager request | Cannot proceed | | `ABDM-1097` | Duplicate Gateway Consent Manager patch request | Cannot proceed | | `ABDM-1098` | Duplicate Gateway Government Program request | Fix request | | `ABDM-1123` | User authentication failed | Unclassified | | `ABDM-1125` | ABHA number and ABHA address cannot be null | Fix request | | `ABDM-1128` | T-Token Expired | Fix request | | `ABDM-1129` | Invalid T-Token | Fix request | | `ABDM-1130` | Invalid X-Token | Fix request | | `ABDM-1131` | X-Token Expired | Fix request | | `ABDM-1208` | Abha Profile Gateway is unavailable | Retry | | `ABDM-1209` | PHR DB service unavailable | Retry | | `ABDM-1210` | Login via Email Address OTP is not allowed | Fix request | | `ABDM-1212` | Email address not found. | Fix request | | `ABDM-1213` | User not active. | Unclassified | | `ABDM-1214` | Mobile/Email verification is pending. | Unclassified | | `ABDM-1215` | Login via Mobile Number OTP is not allowed | Fix request | | `ABDM-1216` | The ABHA Address is deactivated. | Cannot proceed | | `ABDM-1217` | Login is not allowed | Fix request | | `ABDM-1221` | Face verification has been failed, please try again. | Retry | | `ABDM-1222` | Fingerprint verification has been failed, please try again. | Retry | | `ABDM-1223` | IRIS verification has been failed, please try again. | Retry | | `ABDM-1300` | Provided emailId doesn't match with existing emailId | Unclassified | | `ABDM-1301` | The mobile number you have entered has already been verified. Please provide an alternate mobile number. | Fix request | | `ABDM-1302` | The emailId you have entered has already been verified. Please provide an alternate emailId. | Fix request | | `ABDM-1303` | Your mobile number is not linked to the ABHA number. Please update your mobile number in ABHA or try using Aadhaar OTP. | Unclassified | | `ABDM-1304` | Mobile number is not linked to your ABHA address. Please update your mobile number in ABHA. | Unclassified | | `ABDM-1305` | Mobile number is missing for this ABHA address. Please update your mobile number. | Fix request | | `ABDM-1308` | This account is deactivated. Please reactivate it from ABHA portal. | Cannot proceed | | `ABDM-1506` | Invalid callback resp id | Fix request | | `ABDM-1919` | Invalid Refresh token | Fix request | | `ABDM-1920` | Invalid grant type | Fix request | | `ABDM-1921` | Invalid client id | Fix request | | `ABDM-1922` | Invalid client secret | Fix request | | `ABDM-1923` | Invalid client id and secret | Fix request | | `ABDM-1931` | Service-Id= (.\*?) is already exists | Fix request | | `ABDM-1932` | HFR request failed, rollback successful for hfr-id= (\S+)\s\* | Unclassified | | `ABDM-1933` | Bridge registry request is invalid | Fix request | | `ABDM-1935` | All the provided service IDs do not match with the client ID | Unclassified | | `ABDM-9008` | No CR Mapped with Abha Address | Unclassified | Every code above is recorded in the specification that owns it. The aggregated list across modules is at [error codes](/docs/hiecm/v3/reference/error-codes). [Next Still stuck? Ask for help Where to file what you hit, so the answer lands back in these pages.](/docs/support) --- # Gateway session Session and token calls, certificate endpoints for verifying tokens, and bridge registration calls that tell ABDM which URL your callbacks arrive on. The full operation list is in the [Gateway session API reference](/reference/hiecm-gateway). New to this? Start with [Milestones](/docs/hiecm/v3/milestones). --- # API references Every endpoint below is generated from the specification that declares it. Each one has its own page with the headers, the body and a request you can send. This page lists every module, including any that the role you have chosen does not use. The sidebar shows only yours. In M2 and M3 a call is acknowledged now and answered later. The answer arrives as a callback, a POST from ABDM to the URL you registered, declared in the specification as a webhook. Each callback is shown on the call it belongs to, and has a page of its own under that module. A page carries a Mandatory or Conditional badge where a certification case names that call, with the case ids beside it. No badge means no published certification requirement for that module, which is not the same as optional. ## Gateway session 11 endpoints across 4 use cases: Session and tokens, Gateway & Bridge, Bridge, Provider directory. Each endpoint has its own page in the sidebar. [Read the whole specification](/reference/hiecm-gateway) ## M1 ABHA identity 44 endpoints across 14 use cases: ABHA creation, ABHA verification, Share patient profile, Profile update, ABHA QR code, Session and tokens, Fetch ABHA by mobile number, Fetch ABHA by Aadhaar number, Authentication, Login & Verification, ABHA Profile, PHR & ABHA Address, Gateway & Bridge, Scan & Share. Each endpoint has its own page in the sidebar. [Read the whole specification](/reference/hiecm-m1) ## M2 Linking and sharing 20 endpoints across 5 use cases: Hip linking, Deep linking, User linking, Data transfer, Webhooks. Each endpoint has its own page in the sidebar. [Read the whole specification](/reference/hiecm-m2) ## M3 Consent and fetching 14 endpoints across 3 use cases: Consent, Data retrieval, Webhooks. Each endpoint has its own page in the sidebar. [Read the whole specification](/reference/hiecm-m3) ## M4 HPR and HFR 2 endpoints across 2 use cases: HPR login, HFR master data. Each endpoint has its own page in the sidebar. [Read the whole specification](/reference/hiecm-m4) ## P1 PHR identity and profile 63 endpoints across 6 use cases: Login, Family\_management, Global\_collection, Profile, Registration, Digilocker\_apis. Each endpoint has its own page in the sidebar. [Read the whole specification](/reference/hiecm-p1) ## P2 PHR linking and records 49 endpoints across 4 use cases: Care\_context\_link, Health\_locker, Scan\_and\_share, User\_initiated\_linking. Each endpoint has its own page in the sidebar. [Read the whole specification](/reference/hiecm-p2) ## P3 PHR consent and notifications 35 endpoints across 2 use cases: Consent\_management, Notification\_collection. Each endpoint has its own page in the sidebar. [Read the whole specification](/reference/hiecm-p3) ## PHR application services 61 endpoints across 7 use cases: Ambulance, Blood\_bank, Nearby\_health\_search, Pmjay\_panel\_facility\_discovery, Teleconsulting, Nhcx, Scan\_and\_pay. Each endpoint has its own page in the sidebar. [Read the whole specification](/reference/hiecm-phr-services) ## Callbacks with no documented trigger 3 callbacks are declared at module level with no call named against them. Which call produces each one is not documented, so this page does not say. | Module | Method | Arrives at | What it carries | | ----------------------- | ------ | -------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | M2 Linking and sharing | POST | [`/api-hiu/data/notification`](/docs/hiecm/v3/api/m2/endpoints/m2-on-data-notification) | The provider pushes encrypted health information to the URL named in the request. | | M3 Consent and fetching | POST | [`/api/v3/consent/request/hip/notify`](/docs/hiecm/v3/api/m3/endpoints/m3-on-consent-request-notify-hip) | The patient's decision, sent to the record holder | | M3 Consent and fetching | POST | [`/health-information/transfer`](/docs/hiecm/v3/api/m3/endpoints/m3-on-health-information-transfer) | The encrypted health data itself, pushed to the URL you supplied | --- # M1 APIs Every Milestone 1 ([M1](/docs/hiecm/v3/api/m1)) endpoint of [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) has its own page, carrying its method, path, headers, body fields, responses and a curl sample. This page carries what those pages cannot: the rules that hold across all of them. The detail comes from [NHA](/docs/hiecm/v3/getting-started/glossary#nha)'s M1 [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) Postman collection, the only M1 source with real request text. ## Base URLs | Environment | Base URL | | ------------------------------ | -------------------------------------- | | ABHA Server, Sandbox (primary) | `https://abhasbx.abdm.gov.in/abha/api` | | ABDM Gateway, Dev | `https://dev.abdm.gov.in/api/hiecm` | The session call lives on the gateway host. Every other M1 call lives on the ABHA service. A few login routes sit on v3.1 instead of v3, at `https://abhasbx.abdm.gov.in/abha/api/v3.1/`, and their own pages say so. ## The scope array picks the job About twenty paths cover the whole M1 surface. Most are reused for several jobs, and the `scope` array picks which. The same `POST enrollment/request/otp` sends the Aadhaar [OTP](/docs/hiecm/v3/getting-started/glossary#otp), the mobile OTP and the email OTP. `POST profile/account/request/otp` covers mobile update, email update, password change, re-[KYC](/docs/hiecm/v3/getting-started/glossary#kyc), delete and deactivate. Read the `scope` values on an endpoint page before you assume the path does one thing. ## Sensitive fields travel encrypted Aadhaar numbers, mobile numbers, email addresses, OTP values and passwords are RSA encrypted with the ABDM public certificate before they go in the body. Placeholders are named for it, for example ``. Encrypt locally. The [encrypt endpoint](/docs/hiecm/v3/api/m1/endpoints/m1-encrypt-value) does it for you. That helps when you are trying a flow by hand, and it is wrong in production, because it sends the raw value to a remote host. M1 names a `public/certificate` API for fetching the public key. Its URL, headers and response body are not yet published. ## Two tokens, not interchangeable The gateway access token from the [session call](/docs/hiecm/v3/api/gateway/endpoints/gateway-sessions-create) goes in `Authorization`. It says your system may call. The user token from an enrolment or a login goes in `X-token`. It says whose account to act on. Profile endpoints need both. That is every path under `profile/account`, including the card, the quick response (QR) code and logout. The refresh token is a third value with its own header: it goes in `R-token` on the token refresh call only, never in `X-token` and never in the body. ## The benefit endpoints are government only The benefit programme APIs under `profile/benefit/` are government integrator only. A private integrator calling them receives `ABDM-1094`. See [errors](/docs/hiecm/v3/api/m1/errors). Child ABHA creation is restricted further, to specific government integrators on leadership approval. ## The BENEFIT\_NAME header is spelled four ways NHA's own files write this header four different ways across requests: `BENEFIT_NAME` on most, `Benefit-Name` on demographic authentication and the child ABHA calls, `BENEFIT-NAME` on child update and state district search, and `Benefit_Name` once. An underscore and a hyphen are different header names on the wire, so these are not the same header, and which spelling each endpoint actually accepts has not been confirmed against the sandbox. Send the spelling the endpoint's own page shows, and if a call is rejected for a reason you cannot place, try the other spellings before looking elsewhere. The value is usually `healthid api` or `healthid`, but benefit programme calls use others: `COVIN` on an IRIS enrolment and a profile photo update, and a `PAN` value that is present but disabled. ## Every endpoint has its own page Each M1 endpoint is listed in the sidebar under its group, with its request fields, its recorded responses, and a request you can send from the page. Start at [the endpoint index](/docs/hiecm/v3/api), or read [the call order](/reference/hiecm-m1) first if you have not built the flow yet. --- # Find the Aadhaar number behind an ABHA number `GET /v3/profile/benefit/search/aadhaarByAbha` The reverse lookup. It returns a national identity number, so treat both the request and the response as sensitive and log neither. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/benefit/search/aadhaarByAbha \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'BENEFIT_NAME: healthid api' \ --header 'healthIdNumber: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `BENEFIT_NAME` (string): The benefit scheme an enrolment belongs to. Send `healthid api` on the enrol and search calls, and `healthid` on the login OTP and verify calls under Find ABHA. On the enrolment OTP request the header is present but explicitly disabled, so it is not sent there. A login OTP request sent with `healthid api` rather than `healthid` was accepted on the sandbox on 2026-09-11, so the login calls may take either. NHA's files spell this header four different ways and use scheme values beyond healthid. Which spelling each endpoint accepts is not confirmed against the sandbox. The Conventions page for this module lists all four. - `healthIdNumber` (string, required): The 14 digit ABHA number, sent plain in the recorded request, in the dashed `91-XXXX-XXXX-XXXX` form. ## Responses - `200`: The specification does not describe this body. Send the call with Try it to see what comes back. --- # Find an ABHA number from an Aadhaar number `GET /v3/profile/benefit/search/abhaByAadhaar` A benefit scheme lookup, not a general search. The Aadhaar value is encrypted. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/benefit/search/abhaByAadhaar \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'BENEFIT_NAME: healthid api' \ --header 'aadhaarNumber: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `BENEFIT_NAME` (string): The benefit scheme an enrolment belongs to. Send `healthid api` on the enrol and search calls, and `healthid` on the login OTP and verify calls under Find ABHA. On the enrolment OTP request the header is present but explicitly disabled, so it is not sent there. A login OTP request sent with `healthid api` rather than `healthid` was accepted on the sandbox on 2026-09-11, so the login calls may take either. NHA's files spell this header four different ways and use scheme values beyond healthid. Which spelling each endpoint accepts is not confirmed against the sandbox. The Conventions page for this module lists all four. - `aadhaarNumber` (string, required): The person's Aadhaar number, RSA encrypted against the ABDM public key and sent as a header rather than in a body. The recorded value is an encrypted blob, never the raw number: encrypt it the same way as an enrolment `loginId`. See the input encryption concept atom for the padding rules. ## Responses - `200`: The specification does not describe this body. Send the call with Try it to see what comes back. --- # Get the benefit record for an ABHA number `GET /v3/profile/benefit/abha/{abhaNumber}` Reads the benefit record attached to one ABHA number. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/benefit/abha/{abhaNumber} \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'BENEFIT_NAME: healthid api' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `BENEFIT_NAME` (string): The benefit scheme an enrolment belongs to. Send `healthid api` on the enrol and search calls, and `healthid` on the login OTP and verify calls under Find ABHA. On the enrolment OTP request the header is present but explicitly disabled, so it is not sent there. A login OTP request sent with `healthid api` rather than `healthid` was accepted on the sandbox on 2026-09-11, so the login calls may take either. NHA's files spell this header four different ways and use scheme values beyond healthid. Which spelling each endpoint accepts is not confirmed against the sandbox. The Conventions page for this module lists all four. ## Path parameters - `abhaNumber` (string, required): A fourteen digit ABHA number, written in the hyphenated form NHA uses, for example 91-1234-5678-9012. ## Responses - `200`: The benefit programmes recorded against the ABHA. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "abhaNumber": "", "programme": [ { "benefitName": "" } ] } ``` --- # Get the state and district recorded against an ABHA number `GET /v3/profile/benefit/abha/statedistrict/{abhaNumber}` Used to route a person to the right scheme, since eligibility is often decided by where they live. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/benefit/abha/statedistrict/{abhaNumber} \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Path parameters - `abhaNumber` (string, required): A fourteen digit ABHA number, written in the hyphenated form NHA uses, for example 91-1234-5678-9012. ## Responses - `200`: The state and district codes recorded against the ABHA. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "abhaNumber": "", "stateCode": 0, "districtCode": 0, "status": "" } ``` --- # Link or unlink a benefit record from an ABHA `POST /v3/profile/benefit/linkAndDelink` One call does both directions. The success response names the scheme and confirms the link in a human readable `status` string rather than a code, so match on the HTTP status and the scheme, not on that text. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/benefit/linkAndDelink \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'BENEFIT_NAME: healthid api' \ --header 'X-token: ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "link" ], "loginHint": "abha-number", "loginId": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `BENEFIT_NAME` (string): The benefit scheme an enrolment belongs to. Send `healthid api` on the enrol and search calls, and `healthid` on the login OTP and verify calls under Find ABHA. On the enrolment OTP request the header is present but explicitly disabled, so it is not sent there. A login OTP request sent with `healthid api` rather than `healthid` was accepted on the sandbox on 2026-09-11, so the login calls may take either. NHA's files spell this header four different ways and use scheme values beyond healthid. Which spelling each endpoint accepts is not confirmed against the sandbox. The Conventions page for this module lists all four. - `X-token` (string): The user scoped token returned when a person logs in or verifies an OTP. Profile calls act on one account, so they need this in addition to the gateway token. Required on the calls that read or change a specific person's account. Send the bare token. Unlike the Authorization header this one carries no `Bearer ` prefix, and adding one is refused as `ABDM-1094` with the message `X-token expired`. That message names the wrong thing: a token rejected one second after it was issued has not expired, it was malformed. Check the prefix before the lifetime. ## Body - `scope` (string[], required): The direction. Send `["de-link"]` to de-link and `["link"]` to link. Note the hyphen in `de-link`. - `loginHint` (string): How the account is identified when the call is not made with an X-token: the recorded variants send `abha-number` or `xmlUid`. Absent on the X-token variant. - `loginId` (string): The identifier named by `loginHint`, RSA encrypted against the ABDM public key, never raw. Present only alongside `loginHint`. ## Responses - `200`: The benefit link status for the ABHA. - `400`: The error returned, with its code and message. See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: The error returned, with its code and message. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "benefitName": "healthid api", "healthId": "", "status": "Benefit record has been linked successfully" } ``` --- # Find insurance cover recorded against an ABHA number `GET /v3/profile/benefit/abha/search/insurance/{abhaNumber}` Documented responses include 400, 401 and 500 as well as 200. Handle all four. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/benefit/abha/search/insurance/{abhaNumber} \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Path parameters - `abhaNumber` (string, required): A fourteen digit ABHA number, written in the hyphenated form NHA uses, for example 91-1234-5678-9012. ## Responses - `200`: The insurance programmes linked to the ABHA. - `400`: The error returned, with its code and message. See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: The error returned, with its code and message. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `404`: Resource not found See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: The error returned, with its code and message. See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "abhaNumber": "", "entityType": "Insurance", "insuranceProgramsLinked": [ "Health ID Test" ] } ``` --- # Search benefit records for a person `POST /v3/profile/benefit/search` Searches by encrypted XML UID or by ABHA number, depending on `loginHint`. Returns an array, one entry per benefit scheme, each with the scheme name, its identifier and a status. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/benefit/search \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'BENEFIT_NAME: healthid api' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "search" ], "loginHint": "xmlUid", "loginId": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `BENEFIT_NAME` (string): The benefit scheme an enrolment belongs to. Send `healthid api` on the enrol and search calls, and `healthid` on the login OTP and verify calls under Find ABHA. On the enrolment OTP request the header is present but explicitly disabled, so it is not sent there. A login OTP request sent with `healthid api` rather than `healthid` was accepted on the sandbox on 2026-09-11, so the login calls may take either. NHA's files spell this header four different ways and use scheme values beyond healthid. Which spelling each endpoint accepts is not confirmed against the sandbox. The Conventions page for this module lists all four. ## Body - `scope` (string[], required) - `loginHint` (string, required) - `loginId` (string, required) ## Responses - `200`: The response. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `404`: Resource not found See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "stateCode": null, "benefitName": "COVIN", "benefitId": "", "abhaNumber": "", "status": 0 } ] ``` --- # Download PHR Card `GET /phr/web/login/profile/abha/phr-card` Download the PHR / ABHA Address card image. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/phr/web/login/profile/abha/phr-card \ --header 'Authorization: Bearer ' \ --header 'X-Token: ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' ``` ## Authorization - `Authorization` (bearer token, required): JWT Bearer token from `POST /api/hiecm/gateway/v3/sessions`. Header: `Authorization: Bearer {accessToken}` - `X-Token` (apiKey, required): Short-lived session token returned in login/verify responses. Required for all `/profile/account/*` operations. Header: `X-Token: {token}` ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Responses - `200`: PHR Card image (PNG) - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors --- # Download PHR QR Code `GET /phr/web/login/profile/abha/qr-code` Download the PHR QR code image. Schema and examples are in this specification. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/phr/web/login/profile/abha/qr-code \ --header 'Authorization: Bearer ' \ --header 'X-Token: ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' ``` ## Authorization - `Authorization` (bearer token, required): JWT Bearer token from `POST /api/hiecm/gateway/v3/sessions`. Header: `Authorization: Bearer {accessToken}` - `X-Token` (apiKey, required): Short-lived session token returned in login/verify responses. Required for all `/profile/account/*` operations. Header: `X-Token: {token}` ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Responses - `200`: QR Code image - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors --- # Encrypt a value with the ABDM public key `POST /v3/phr/app/enrollment/encrypt` Every `loginId` in M1 is encrypted rather than sent raw, and this is the hosted helper for doing it. It is convenient for trying a flow by hand. Do not put it in a production path. Sending an Aadhaar or mobile number to a remote endpoint so that it can be encrypted defeats the point of encrypting it. Encrypt locally against NHA's published public key instead. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/phr/app/enrollment/encrypt \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'KEY_TYPE: ' \ --header 'Content-Type: application/json' \ --data '{ "data": "1" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `KEY_TYPE` (string): Which ABDM public key the encryption helper should use. ## Body - `data` (string, required) ## Responses - `200`: The specification does not describe this body. Send the call with Try it to see what comes back. --- # Get suggested ABHA addresses for a new account `GET /v3/enrollment/enrol/suggestion` Returns a handful of available ABHA addresses built from the person's name and date of birth. Offer them as a choice. The person may type their own instead, subject to the address policy: at least four characters, letters, numbers and dots only, and it may not begin with a number or begin or end with a dot. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/v3/enrollment/enrol/suggestion \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'TRANSACTION_ID: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `TRANSACTION_ID` (string): The enrolment transaction this call belongs to, when the transaction is not carried in the body. ## Responses - `200`: ABHA address suggestions for the transaction. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "abhaAddressList": [ "" ] } ``` --- # Create an ABHA from a verified Aadhaar OTP `POST /v3/enrollment/enrol/byAadhaar` Exchanges the OTP you just received for a real ABHA number. Send the `txnId` from the OTP request, the encrypted OTP value, and the consent block recording that the person agreed. This is the call that creates the account, so treat a success as a permanent side effect. If you retry it blindly after a timeout you may be enrolling somebody twice. `BENEFIT_NAME` is sent on this call when the enrolment belongs to a benefit scheme. The demographic authentication variant reads the user token from a different place: `token` at the top level, while the OTP, face and fingerprint variants take `tokens.token`. Check which one you get before parsing. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/enrollment/enrol/byAadhaar \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'BENEFIT_NAME: healthid api' \ --header 'X-token: ' \ --header 'Content-Type: application/json' \ --data '{ "authData": { "authMethods": [ "otp" ], "otp": { "txnId": "", "otpValue": "", "mobile": "" } }, "consent": { "code": "abha-enrollment", "version": "1.4" } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `BENEFIT_NAME` (string): The benefit scheme an enrolment belongs to. Send `healthid api` on the enrol and search calls, and `healthid` on the login OTP and verify calls under Find ABHA. On the enrolment OTP request the header is present but explicitly disabled, so it is not sent there. A login OTP request sent with `healthid api` rather than `healthid` was accepted on the sandbox on 2026-09-11, so the login calls may take either. NHA's files spell this header four different ways and use scheme values beyond healthid. Which spelling each endpoint accepts is not confirmed against the sandbox. The Conventions page for this module lists all four. - `X-token` (string): The user scoped token returned when a person logs in or verifies an OTP. Profile calls act on one account, so they need this in addition to the gateway token. Required on the calls that read or change a specific person's account. Send the bare token. Unlike the Authorization header this one carries no `Bearer ` prefix, and adding one is refused as `ABDM-1094` with the message `X-token expired`. That message names the wrong thing: a token rejected one second after it was issued has not expired, it was malformed. Check the prefix before the lifetime. ## Body - `authData` (object, required) - `authData.authMethods` (string[], required) - `authData.otp` (object) - `authData.otp.txnId` (string, required) - `authData.otp.otpValue` (string) - `authData.otp.mobile` (string, required) - `authData.otp.fingerPrintAuthPid` (string) - `authData.otp.timeStamp` (string) - `authData.face` (object) - `authData.face.txnId` (string, required) - `authData.face.aadhaar` (string, required) - `authData.iris` (object) - `authData.iris.aadhaar` (string, required) - `authData.iris.Pid` (string, required) - `authData.iris.mobile` (string, required) - `authData.bio` (object) - `authData.bio.aadhaar` (string, required) - `authData.bio.fingerPrintAuthPid` (string, required) - `authData.bio.mobile` (string, required) - `consent` (object, required) - `consent.code` (string, required) - `consent.version` (string, required) ## Responses - `200`: The specification does not describe this body. Send the call with Try it to see what comes back. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `422`: Unprocessable, the request parsed but failed validation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors --- # Create an ABHA from an identity document `POST /v3/enrollment/enrol/byDocument` The route for somebody who cannot complete Aadhaar authentication. A driving licence is one accepted document. The account created this way is restricted until it is upgraded through Aadhaar KYC, so tell the person that rather than letting them discover it later. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/enrollment/enrol/byDocument \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "txnId": "", "documentType": "DRIVING_LICENCE", "documentId": "DL0820****858", "firstName": "", "middleName": "", "lastName": "", "dob": "", "gender": "M", "frontSidePhoto": "", "backSidePhoto": "", "address": "
", "state": "", "district": "", "pinCode": "", "consent": { "code": "abha-enrollment", "version": "1.4" } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `txnId` (string, required) - `documentType` (string, required) - `documentId` (string, required) - `firstName` (string, required) - `middleName` (string, required) - `lastName` (string, required) - `dob` (string, required) - `gender` (string, required) - `frontSidePhoto` (string, required) - `backSidePhoto` (string, required) - `address` (string, required) - `state` (string, required) - `district` (string, required) - `pinCode` (string, required) - `consent` (object, required) - `consent.code` (string, required) - `consent.version` (string, required) ## Responses - `200`: The specification does not describe this body. Send the call with Try it to see what comes back. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `422`: Unprocessable, the request parsed but failed validation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors --- # Submit a captured biometric or face authentication block `POST /v3/enrollment/enrol/capturePID` Hands over the PID block produced by the Aadhaar RD service. The block is encrypted by the device and is time limited, so send it as soon as the capture returns rather than storing it. This is a polling loop. All three states come back as HTTP 200, so branch on `status` and not on the status code. `PENDING` and `VERIFIED` both mean the capture has not landed yet and carry the same message, `Awaiting PID capture`. Only `COMPLETE` carries the `txnId` you take into the next call. Keep polling until you see it. One caveat about where these came from. NHA saved the `COMPLETE` example against `enrollment/enrol/capturePID`, and saved the `PENDING` and `VERIFIED` examples against `enrollment/enrol/internal/capturePID`, a path that appears nowhere else in the collection and that NHA's M1 document never mentions. Whether the two paths are one endpoint is unresolved here. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/enrollment/enrol/capturePID \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-enrol", "face-verify" ], "txnId": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `scope` (string[], required) - `txnId` (string, required) ## Responses - `200`: The capture status, a message, and the transaction id. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "status": "VERIFIED", "message": "Awaiting PID capture" } ``` --- # Claim a chosen ABHA address `POST /v3/enrollment/enrol/abha-address` Attaches the address the person picked to the ABHA number created earlier. `preferred: 1` marks it as the one to show. Until this succeeds the account has only the default address that the service issues automatically, which is the fourteen digit number followed by `@sbx` or `@abdm` and which nobody can remember. The ABHA number comes back from this call as `healthIdNumber`, not as `ABHANumber`. The enrol response spells the same value `ABHANumber`, so a client that reuses its enrol parsing here reads nothing. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/enrollment/enrol/abha-address \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "txnId": "", "abhaAddress": "", "preferred": 1 }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `txnId` (string, required) - `abhaAddress` (string, required) - `preferred` (integer, required) ## Responses - `200`: Response body not fully documented. `healthIdNumber` is confirmed; the rest of the shape is not. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "healthIdNumber": "" } ``` --- # Start face or biometric authentication and get a transaction id `POST /v3/enrollment/enrol/auth/init` Returns the `txnId` that a QR code is built from. The person scans that QR with the ABHA app, completes face authentication through the Aadhaar RD service, and you then continue with the captured result. The same call starts the face authentication login flow, not only enrolment. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/enrollment/enrol/auth/init \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-enrol", "face-auth" ] }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `scope` (string[], required): The recorded request sends `["abha-enrol", "face-auth"]`. The collection's own comments name the variant: `face-auth` starts the flow without a PID block, `face-verify` is the route with one. Confirm against sandbox before relying on either. ## Responses - `200`: The transaction id to carry into the next step, with a message. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "message": "" } ``` --- # List the child ABHA accounts linked to this account `GET /v3/enrollment/profile/children` A parent or guardian can hold ABHA accounts for children under their own account. This returns them. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/v3/enrollment/profile/children \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'X-token: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `X-token` (string, required): The user scoped token returned when a person logs in or verifies an OTP. Required on this operation. See the shared `XToken` parameter, and note that this header takes the bare token with no prefix. ## Responses - `200`: The children linked to the parent ABHA, with their count. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "parentAbhaNumber": "", "mobileNumber": "", "childrenCount": 0, "children": [ "" ] } ``` --- # Send an OTP to begin or continue an enrolment `POST /v3/enrollment/request/otp` The first call of most enrolment flows, and the one people reuse without noticing. What it does depends on `scope` and `loginHint`. Starting an enrolment: `scope` is `["abha-enrol"]`, `loginHint` is `aadhaar`, `loginId` is the encrypted Aadhaar number and `otpSystem` is `aadhaar`. The OTP goes to the mobile registered with Aadhaar. Verifying a mobile or email afterwards: `scope` gains `mobile-verify` or `email-verify`, `otpSystem` becomes `abdm`, and you pass the `txnId` from the enrolment you are continuing. `loginId` is encrypted, never the raw value. Encrypt it against the ABDM public key first. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/enrollment/request/otp \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-enrol" ], "loginHint": "aadhaar", "loginId": "_encrypted_12_digit_aadhaar_no_", "otpSystem": "aadhaar" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `scope` (string[], required) - `loginHint` (string, required) - `loginId` (string, required) - `otpSystem` (string, required) - `txnId` (string) ## Responses - `200`: The transaction id to carry into the next step, with a message. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "message": "" } ``` --- # Verify an OTP that ABDM sent, during enrolment `POST /v3/enrollment/auth/byAbdm` Confirms the mobile number or email address the person gave during enrolment. The OTP here came from ABDM rather than from Aadhaar, which is why the call is separate from the Aadhaar verification. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/enrollment/auth/byAbdm \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-enrol", "mobile-verify" ], "authData": { "authMethods": [ "otp" ], "otp": { "txnId": "", "otpValue": "" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `scope` (string[], required) - `authData` (object, required) - `authData.authMethods` (string[], required) - `authData.otp` (object, required) - `authData.otp.txnId` (string, required) - `authData.otp.otpValue` (string, required) - `authData.otp.timeStamp` (string) ## Responses - `200`: Whether the OTP verified, the transaction id, and the ABHA accounts the person may pick from. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "authResult": "", "message": "", "accounts": [ "" ] } ``` --- # Find an ABHA for somebody who does not know theirs `POST /v3/profile/account/abha/search` Takes an encrypted mobile number, Aadhaar number or biometric result and sends an OTP to the mobile on record. The response carries a `txnId` and a message naming the masked mobile the OTP went to, so the person can confirm it is theirs before waiting for it. Two shapes are documented for the response: an array, which fits one mobile number mapping to several accounts, and a single object. The single-object example carries a URL of `profile/login/request/otp`, so it likely describes a different endpoint. Expect an array, and treat the single object as unconfirmed. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/account/abha/search \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'BENEFIT_NAME: healthid api' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "search-abha" ], "mobile": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `BENEFIT_NAME` (string): The benefit scheme an enrolment belongs to. Send `healthid api` on the enrol and search calls, and `healthid` on the login OTP and verify calls under Find ABHA. On the enrolment OTP request the header is present but explicitly disabled, so it is not sent there. A login OTP request sent with `healthid api` rather than `healthid` was accepted on the sandbox on 2026-09-11, so the login calls may take either. NHA's files spell this header four different ways and use scheme values beyond healthid. Which spelling each endpoint accepts is not confirmed against the sandbox. The Conventions page for this module lists all four. ## Body - `scope` (string[], required) - `mobile` (string, required) ## Responses - `200`: Two shapes are documented; the array is the more likely of the two. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `404`: Resource not found See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "txnId": "", "message": "OTP is sent to Mobile number ending with ******0161" } ] ``` --- # Get PHR Profile `GET /phr/web/login/profile/abha-profile` Retrieve the authenticated user's PHR profile after ABHA Address login. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/phr/web/login/profile/abha-profile \ --header 'Authorization: Bearer ' \ --header 'X-Token: ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' ``` ## Authorization - `Authorization` (bearer token, required): JWT Bearer token from `POST /api/hiecm/gateway/v3/sessions`. Header: `Authorization: Bearer {accessToken}` - `X-Token` (apiKey, required): Short-lived session token returned in login/verify responses. Required for all `/profile/account/*` operations. Header: `X-Token: {token}` ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Responses - `200`: PHR profile details - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "ABHAAddress": "", "ABHANumber": "", "name": "", "gender": "M", "dob": "2026-08-24", "mobile": "", "email": "", "profilePhoto": "" } ``` --- # Get RSA Public Certificate `GET /profile/public/certificate` Fetch the RSA public key used to encrypt all sensitive fields before transmission. Fields requiring encryption: Aadhaar, Mobile, OTP, Password, ABHA Number, Email, Photo. **Server:** `https://abhasbx.abdm.gov.in/abha/api` ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/profile/public/certificate \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Responses - `200`: RSA public key retrieved - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "publicKey": "" } ``` --- # Send a login OTP, v3.1 `POST /v3.1/profile/login/request/otp` The v3.1 variant of the login OTP request. It sits on a different base path from the rest of M1, `/abha/api/v3.1` rather than `/abha/api/v3`, which is why the version appears in the path here. Use v3 by default. v3.1 is used for Aadhaar OTP and biometric login. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3.1/profile/login/request/otp \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-login", "aadhaar-verify", "aadhaar-otp-verify" ], "loginHint": "aadhaar", "loginId": "", "otpSystem": "aadhaar" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `scope` (string[], required) - `loginHint` (string, required) - `loginId` (string, required) - `otpSystem` (string, required) ## Responses - `200`: The specification does not describe this body. Send the call with Try it to see what comes back. --- # Send a login OTP `POST /v3/profile/login/request/otp` Starts a login. `loginHint` selects what the person is identifying themselves with: `mobile`, `aadhaar` or `abha-number`. As everywhere in M1, `loginId` is encrypted rather than raw. The shape you encrypt matters, because the service validates the plaintext after it decrypts. On `abha-number` that is the fourteen digits with their dashes, `NN-NNNN-NNNN-NNNN`, for example `91-1234-5678-9015`. The bare digits are refused with `400 {"loginId": "LoginId is invalid"}`, observed on the sandbox on 11 September 2026. On `mobile` the plaintext is ten digits with no country code, and on `aadhaar` twelve digits with no spaces. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/login/request/otp \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'BENEFIT_NAME: healthid api' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-login", "mobile-verify" ], "loginHint": "mobile", "loginId": "", "otpSystem": "abdm" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `BENEFIT_NAME` (string): The benefit scheme an enrolment belongs to. Send `healthid api` on the enrol and search calls, and `healthid` on the login OTP and verify calls under Find ABHA. On the enrolment OTP request the header is present but explicitly disabled, so it is not sent there. A login OTP request sent with `healthid api` rather than `healthid` was accepted on the sandbox on 2026-09-11, so the login calls may take either. NHA's files spell this header four different ways and use scheme values beyond healthid. Which spelling each endpoint accepts is not confirmed against the sandbox. The Conventions page for this module lists all four. ## Body - `scope` (string[], required) - `loginHint` (string, required): What the person is identifying themselves with. One of: mobile, aadhaar, abha-number. - `loginId` (string, required): The identifier for that `loginHint`, RSA encrypted against the ABDM public certificate and base64 encoded. The plaintext shape is checked after decryption: an ABHA number is `NN-NNNN-NNNN-NNNN` with its dashes, a mobile number is ten digits with no country code, an Aadhaar number is twelve digits with no spaces. - `otpSystem` (string, required) - `txnId` (string) ## Responses - `200`: The transaction id to carry into the next step, with a message. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: The error returned, with its code and message. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `404`: Resource not found See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "message": "Transaction Id generated Successfully" } ``` --- # Search ABHA Profile (for Password Login) `POST /profile/login/search` Look up a profile by ABHA Number as the first step of the password login flow. Returns basic profile info to confirm the correct account before requesting password. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/profile/login/search \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "ABHANumber": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `ABHANumber` (string, required): 14-digit ABHA number (with or without hyphens) ## Responses - `200`: Profile found - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `404`: Resource not found See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "ABHANumber": "", "name": "", "kycStatus": "VERIFIED", "gender": "M", "mobile": "" } ``` --- # Choose which ABHA to sign in to `POST /v3/profile/login/verify/user` Used when one mobile number carries several ABHA accounts, which is common in a family. Send the `txnId` from the verify call and the ABHA number the person picked. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/login/verify/user \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'T-token: ' \ --header 'Content-Type: application/json' \ --data '{ "ABHANumber": "", "txnId": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `T-token` (string, required): The transaction token that carries state between the two halves of a login. Required for account selection. See the shared `TToken` parameter for the general description. ## Body - `ABHANumber` (string, required) - `txnId` (string, required) ## Responses - `200`: The user token and refresh token, with their expiries. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "token": "", "expiresIn": 0, "refreshToken": "", "refreshExpiresIn": 0 } ``` --- # Verify a login OTP, v3.1 `POST /v3.1/profile/login/verify` The v3.1 counterpart of the login verification, on the `/abha/api/v3.1` base path. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3.1/profile/login/verify \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-login", "aadhaar-verify", "aadhaar-otp-verify" ], "authData": { "authMethods": [ "otp" ], "otp": { "txnId": "", "otpValue": "" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `scope` (string[], required) - `authData` (object, required) - `authData.authMethods` (string[], required) - `authData.otp` (object) - `authData.otp.txnId` (string, required) - `authData.otp.otpValue` (string, required) - `authData.face_login` (object) - `authData.face_login.aadhaar` (string, required) - `authData.face_login.faceAuthPid` (string) - `authData.face_login.txnId` (string) - `authData.bio_login` (object) - `authData.bio_login.aadhaar` (string, required) - `authData.bio_login.fingerPrintAuthPid` (string, required) - `authData.iris_login` (object) - `authData.iris_login.aadhaar` (string, required) - `authData.iris_login.irisAuthPid` (string, required) ## Responses - `200`: Whether the login verified, with the user token and its expiry. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "authResult": "success", "message": "FACE verified successfully", "token": "", "expiresIn": 1800, "refreshToken": "", "refreshExpiresIn": 1296000, "accounts": [ { "ABHANumber": "", "preferredAbhaAddress": "", "name": "", "status": "ACTIVE", "profilePhoto": "" } ] } ``` --- # Verify a login OTP and get a user token `POST /v3/profile/login/verify` Returns the user scoped token that profile calls need, sent afterwards as the `X-token` header. That token identifies one person, so it is not interchangeable with the gateway session token, which identifies your application. If the identifier the person used maps to more than one ABHA, this responds with the list instead of a token, and you continue with the user selection call. Documented responses cover 400, 401, 404 and 422 as well as 200, so read the body rather than only the status. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/login/verify \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'BENEFIT_NAME: healthid api' \ --header 'T-token: ' \ --header 'X-token: ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-login", "mobile-verify" ], "authData": { "authMethods": [ "otp" ], "otp": { "txnId": "", "otpValue": "" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `BENEFIT_NAME` (string): The benefit scheme an enrolment belongs to. Send `healthid api` on the enrol and search calls, and `healthid` on the login OTP and verify calls under Find ABHA. On the enrolment OTP request the header is present but explicitly disabled, so it is not sent there. A login OTP request sent with `healthid api` rather than `healthid` was accepted on the sandbox on 2026-09-11, so the login calls may take either. NHA's files spell this header four different ways and use scheme values beyond healthid. Which spelling each endpoint accepts is not confirmed against the sandbox. The Conventions page for this module lists all four. - `T-token` (string): The transaction token that carries state between the two halves of a login. Returned by the verify call and sent back on the account selection call. Like X-token, the value carries a `Bearer ` prefix in every one of the recorded requests. - `X-token` (string): The user scoped token returned when a person logs in or verifies an OTP. Profile calls act on one account, so they need this in addition to the gateway token. Required on the calls that read or change a specific person's account. Send the bare token. Unlike the Authorization header this one carries no `Bearer ` prefix, and adding one is refused as `ABDM-1094` with the message `X-token expired`. That message names the wrong thing: a token rejected one second after it was issued has not expired, it was malformed. Check the prefix before the lifetime. ## Body - `scope` (string[], required) - `authData` (object, required) - `authData.authMethods` (string[], required) - `authData.otp` (object) - `authData.otp.txnId` (string, required) - `authData.otp.otpValue` (string, required) - `authData.password` (object) - `authData.password.ABHANumber` (string, required) - `authData.password.password` (string, required) - `authData.face` (object) - `authData.face.txnId` (string, required) - `authData.bio` (object) - `authData.bio.txnId` (string, required) - `authData.bio.fingerPrintAuthPid` (string, required) ## Responses - `200`: Whether the login verified, with the user token and its expiry. - `400`: The response. See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: The error returned, with its code and message. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `404`: The error returned, with its code and message. See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `422`: The error returned, with its code and message. See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "authResult": "success", "message": "Aadhaar Face Authentication Success", "token": "", "expiresIn": 1800, "refreshToken": "", "refreshExpiresIn": 1296000, "accounts": [ { "ABHANumber": "", "preferredAbhaAddress": "", "name": "", "status": "ACTIVE", "profilePhoto": "", "mobileVerified": false } ] } ``` --- # Send Share Acknowledgement (HIP → Gateway) `POST /patient-share/v3/on-share` HIP sends an acknowledgement back to the ABDM Gateway after receiving and processing the patient's shared profile. Typically includes a token/queue number assigned to the patient. **Server:** `https://dev.abdm.gov.in/api/hiecm` ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/patient-share/v3/on-share \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "acknowledgement": { "status": "SUCCESS", "abhaAddress": "johnkumar@sbx", "profile": { "context": "123", "tokenNumber": "TKN-0042" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `acknowledgement` (object, required) - `acknowledgement.status` (string, required): Processing result One of: SUCCESS, FAILURE. - `acknowledgement.abhaAddress` (string, required): ABHA Address of the patient who shared their profile - `acknowledgement.profile` (object): Present on SUCCESS, echoes context and provides assigned token - `acknowledgement.profile.context` (string): Context value from the original share request - `acknowledgement.profile.tokenNumber` (string): Queue/token number assigned to the patient by the HIP - `acknowledgement.error` (object): Present on FAILURE - `acknowledgement.error.code` (string) - `acknowledgement.error.message` (string) ## Responses - `200`: Acknowledgement accepted by Gateway --- # Send OTP for ABHA Address Login `POST /phr/web/login/abha/request/otp` Send OTP to login via ABHA Address. | scope | loginHint | Method | |-------|-----------|--------| | `["abha-address-login","mobile-verify"]` | `abha-address` | Mobile OTP | | `["abha-address-login","aadhaar-verify"]` | `abha-address` | Aadhaar OTP | | `["abha-login","aadhaar-bio-verify"]` | `abha-address` | Fingerprint | | `["abha-login","aadhaar-face-verify"]` | `abha-address` | Face | | `["abha-login","aadhaar-iris-verify"]` | `abha-address` | Iris | ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/phr/web/login/abha/request/otp \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-address-login", "mobile-verify" ], "loginHint": "abha-address", "loginId": "{{RSA_encrypted_abha_address}}", "otpSystem": "abdm, aadhaar" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `scope` (string[], required) - `loginHint` (string, required) One of: abha-address. - `loginId` (string, required): RSA-encrypted ABHA Address - `otpSystem` (string, required): Which identity system the loginId is encrypted for. Example values include `abdm` and `aadhaar`. ## Responses - `200`: OTP sent - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "message": "" } ``` --- # Search ABHA Address, Get Auth Methods `POST /phr/web/login/abha/search` Look up available authentication methods for a given ABHA Address before login. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/phr/web/login/abha/search \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "abhaAddress": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `abhaAddress` (string, required) ## Responses - `200`: Available authentication methods - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `404`: Resource not found See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "authMethods": [ "MOBILE_OTP" ] } ``` --- # Verify OTP / Biometric for ABHA Address Login `POST /phr/web/login/abha/verify` Complete the ABHA Address login with OTP or biometric. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/phr/web/login/abha/verify \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-address-login", "mobile-verify" ], "authData": { "authMethods": [ "otp" ], "otp": { "txnId": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "otpValue": "{{RSA_encrypted_otp}}" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `scope` (string[], required) - `authData` (object, required) - `authData.authMethods` (string[], required) - `authData.otp` (object) - `authData.bio` (object) - `authData.bio.txnId` (string) - `authData.bio.bioType` (string) One of: FMR. - `authData.bio.pid` (string) - `authData.face` (object) - `authData.face.txnId` (string) - `authData.face.pid` (string) - `authData.iris` (object) - `authData.iris.txnId` (string) - `authData.iris.pid` (string) ## Responses - `200`: Login successful - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "token": "", "refreshToken": "", "expiresIn": 0, "refreshExpiresIn": 0, "accounts": "" } ``` --- # Download the ABHA card as a file `GET /v3/profile/account/download-abha-card` The same card, delivered as a downloadable file rather than for inline display. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/account/download-abha-card \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'X-token: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `X-token` (string): The user scoped token returned when a person logs in or verifies an OTP. Profile calls act on one account, so they need this in addition to the gateway token. Required on the calls that read or change a specific person's account. Send the bare token. Unlike the Authorization header this one carries no `Bearer ` prefix, and adding one is refused as `ABDM-1094` with the message `X-token expired`. That message names the wrong thing: a token rejected one second after it was issued has not expired, it was malformed. Check the prefix before the lifetime. ## Responses - `200`: The specification does not describe this body. Send the call with Try it to see what comes back. --- # Get the ABHA card `GET /v3/profile/account/abha-card` The card as an image, for display inside your application. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/account/abha-card \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'X-token: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `X-token` (string, required): The user scoped token returned when a person logs in or verifies an OTP. Required on this operation. See the shared `XToken` parameter, and note that this header takes the bare token with no prefix. ## Responses - `200`: The specification does not describe this body. Send the call with Try it to see what comes back. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors --- # Read the signed in person's ABHA profile `GET /v3/profile/account` Needs the `X-token` from login, because it reads one person's account rather than anything about your application. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/account \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'X-token: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `X-token` (string, required): The user scoped token returned when a person logs in or verifies an OTP. Required on this operation. See the shared `XToken` parameter, and note that this header takes the bare token with no prefix. ## Responses - `200`: The response. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "ABHANumber": "", "preferredAbhaAddress": "", "mobile": "", "firstName": "", "middleName": "", "lastName": "", "name": "", "yearOfBirth": "", "dayOfBirth": "", "monthOfBirth": "", "gender": "", "profilePhoto": "", "status": "", "stateCode": "", "districtCode": "", "pincode": "", "address": "
", "kycPhoto": "", "stateName": "", "districtName": "", "subdistrictName": "", "authMethods": [ "" ], "kycVerified": false, "verificationStatus": "", "verificationType": "", "createdDate": "" } ``` --- # Get the ABHA QR code `GET /v3/profile/account/qrCode` The QR a person shows at a facility so their ABHA address can be read without typing. Returns the image payload for the signed in account. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/account/qrCode \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'X-token: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `X-token` (string, required): The user scoped token returned when a person logs in or verifies an OTP. Required on this operation. See the shared `XToken` parameter, and note that this header takes the bare token with no prefix. ## Responses - `200`: The specification does not describe this body. Send the call with Try it to see what comes back. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors --- # Log the person out and invalidate their user token `GET /v3/profile/account/request/logout` Invalidates the `X-token`. Call it when the person signs out, and when your session ends, so a token cannot outlive the session that produced it. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/account/request/logout \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'X-token: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `X-token` (string, required): The user scoped token returned when a person logs in or verifies an OTP. Required on this operation. See the shared `XToken` parameter, and note that this header takes the bare token with no prefix. ## Responses - `200`: Confirmation that the session ended. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "You have been logged out", "timestamp": "2025-01-31 20:03:49" } ``` --- # Send an OTP to change something on the profile `POST /v3/profile/account/request/otp` Raise this before updating a mobile number, an email address or a password. `scope` names both the area and the action, for example `["abha-profile", "mobile-verify"]`. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/account/request/otp \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'X-token: ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-profile", "mobile-verify" ], "loginHint": "mobile", "loginId": "", "otpSystem": "abdm" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `X-token` (string, required): The user scoped token returned when a person logs in or verifies an OTP. Required on this operation. See the shared `XToken` parameter, and note that this header takes the bare token with no prefix. ## Body - `scope` (string[], required) - `loginHint` (string, required) - `loginId` (string, required) - `otpSystem` (string, required) ## Responses - `200`: The transaction id to carry into the next step, with a message. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "message": "" } ``` --- # Update fields on an ABHA profile `PATCH /v3/profile/account` Changes self declared profile details. Changing a mobile number or an email address is not done here: those need the OTP pair below, because NHA verifies the new value before accepting it. ```bash curl --request PATCH \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/account \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'BENEFIT_NAME: healthid api' \ --header 'X-token: ' \ --header 'Content-Type: application/json' \ --data '{ "abhaNumber": "", "name": "", "dob": "", "gender": "M" }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `BENEFIT_NAME` (string): The benefit scheme an enrolment belongs to. Send `healthid api` on the enrol and search calls, and `healthid` on the login OTP and verify calls under Find ABHA. On the enrolment OTP request the header is present but explicitly disabled, so it is not sent there. A login OTP request sent with `healthid api` rather than `healthid` was accepted on the sandbox on 2026-09-11, so the login calls may take either. NHA's files spell this header four different ways and use scheme values beyond healthid. Which spelling each endpoint accepts is not confirmed against the sandbox. The Conventions page for this module lists all four. - `X-token` (string): The user scoped token returned when a person logs in or verifies an OTP. Profile calls act on one account, so they need this in addition to the gateway token. Required on the calls that read or change a specific person's account. Send the bare token. Unlike the Authorization header this one carries no `Bearer ` prefix, and adding one is refused as `ABDM-1094` with the message `X-token expired`. That message names the wrong thing: a token rejected one second after it was issued has not expired, it was malformed. Check the prefix before the lifetime. ## Body - `abhaNumber` (string) - `name` (string) - `dob` (string) - `gender` (string) - `profilePhoto` (string) - `mobile` (string) - `accountStatus` (string) ## Responses - `200`: The ABHA profile as held by NHA. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "ABHANumber": "", "preferredAbhaAddress": "", "mobile": "", "firstName": "", "middleName": "", "lastName": "", "name": "", "yearOfBirth": 1999, "dayOfBirth": 26, "monthOfBirth": 6, "gender": "M", "email": "", "profilePhoto": "", "status": "ACTIVE", "stateCode": 32, "districtCode": 563, "subDistrictCode": null, "villageCode": null, "townCode": null, "wardCode": null, "pincode": "", "address": "
", "kycPhoto": "", "stateName": "", "districtName": "", "subdistrictName": "", "villageName": null, "townName": null, "wardName": null, "authMethods": [ "EMAIL_OTP", "MOBILE_OTP" ], "tags": {}, "kycVerified": true, "verificationStatus": "VERIFIED", "verificationType": "DRIVING_LICENCE", "emailVerified": "" } ``` --- # Verify the OTP for a profile change `POST /v3/profile/account/verify` Completes the change the OTP was raised for. Send the same `scope` you used when requesting it, along with the `txnId` and the encrypted OTP. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/account/verify \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'X-token: ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-profile", "mobile-verify" ], "authData": { "authMethods": [ "otp" ], "otp": { "txnId": "", "otpValue": "" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `X-token` (string, required): The user scoped token returned when a person logs in or verifies an OTP. Required on this operation. See the shared `XToken` parameter, and note that this header takes the bare token with no prefix. ## Body - `scope` (string[], required) - `authData` (object, required) - `authData.authMethods` (string[], required) - `authData.otp` (object) - `authData.otp.txnId` (string, required) - `authData.otp.otpValue` (string, required) - `authData.password` (object) - `authData.password.newPassword` (string, required) - `authData.password.oldPassword` (string, required) - `reasons` (string[]) ## Responses - `200`: Whether the OTP verified, the transaction id, and the ABHA accounts the person may pick from. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `422`: Unprocessable, the request parsed but failed validation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "authResult": "", "message": "", "accounts": [ "" ] } ``` --- # Receive a patient's shared profile `POST /patient-share/v3/share` Also known as: [HIP Callback] Receive Patient Profile Share. **This endpoint is implemented by the HIP**, the ABDM Gateway forwards the patient's profile to the HIP's registered callback URL when the patient scans the HIP's QR code and consents to share their profile. The HIP must respond with a 2xx status and subsequently call `POST /patient-share/v3/on-share`. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/patient-share/v3/share \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "intent": "PROFILE_SHARE", "metaData": { "hipId": "CityGeneralHospital_HIP", "context": "123", "hprId": "testhpr@hpr.abdm" }, "profile": { "patient": { "abhaNumber": "91-1234-5678-9012", "abhaAddress": "johnkumar@sbx", "name": "John Kumar", "gender": "M", "dob": "1990-01-15", "mobile": "9876543210", "kycPhoto": "{{base64_photo}}", "address": { "line": "123 Main Street", "district": "Mumbai", "state": "Maharashtra", "pinCode": "400001" } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `intent` (string, required): Always `PROFILE_SHARE` for scan-and-share flows One of: PROFILE_SHARE. - `metaData` (object, required) - `metaData.hipId` (string, required): HIP identifier embedded in the QR code - `metaData.context` (string, required): Counter or context value from the QR code - `metaData.hprId` (string): Health Professional Registry ID of the scanning clinician - `profile` (object, required) - `profile.patient` (object) ## Responses - `200`: Profile received by HIP --- # Register / Update HIP-HIU Services (Facility Registry) `POST /v1/bridges/MutipleHRPAddUpdateServices` Register or update HIP/HIU services in the Facility Registry. Must be called after updating the bridge URL. **Server:** `https://facilitysbx.abdm.gov.in` ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/v1/bridges/MutipleHRPAddUpdateServices \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "facilityId": "IN0710000001", "facilityName": "City General Hospital", "HRP": [ { "bridgeId": "your-client-id", "hipName": "City General Hospital", "hipId": "CityGeneralHospital_HIP", "hipType": "HOSPITAL", "facilityName": "City General Hospital" } ] }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `facilityId` (string, required): Facility identifier from the Health Facility Registry - `facilityName` (string, required): Name of the healthcare facility - `HRP` (object[], required): List of HIP/HIU/HRP services to register - `HRP.bridgeId` (string, required): Your client ID (bridge identifier) - `HRP.hipName` (string, required): Display name of the HIP - `HRP.hipId` (string, required): Unique HIP service identifier - `HRP.hipType` (string, required) One of: HOSPITAL, CLINIC, LAB, PHARMACY, WELLNESS, DIAGNOSTIC, OTHER. - `HRP.facilityName` (string, required) ## Responses - `200`: Services registered / updated successfully Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "" } ``` --- # Send Email Verification Link `POST /profile/account/request/emailVerificationLink` Send a one-click email verification link. The user clicks it to verify their email, no OTP required. ```bash curl --request POST \ --url https://abhasbx.abdm.gov.in/abha/api/profile/account/request/emailVerificationLink \ --header 'Authorization: Bearer ' \ --header 'X-Token: ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-profile", "email-link-verify" ], "loginHint": "email", "loginId": "{{RSA_encrypted_email}}", "otpSystem": "abdm, aadhaar" }' ``` ## Authorization - `Authorization` (bearer token, required): JWT Bearer token from `POST /api/hiecm/gateway/v3/sessions`. Header: `Authorization: Bearer {accessToken}` - `X-Token` (apiKey, required): Short-lived session token returned in login/verify responses. Required for all `/profile/account/*` operations. Header: `X-Token: {token}` ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. ## Body - `scope` (string[], required) - `loginHint` (string, required) One of: email. - `loginId` (string, required): RSA-encrypted email address - `otpSystem` (string, required): Which identity system the loginId is encrypted for. Example values include `abdm` and `aadhaar`. ## Responses - `200`: Verification link sent to email - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "" } ``` --- # Get a new user token from a refresh token `GET /v3/profile/account/request/token` Refreshes the `X-token` without making the person log in again. Read the expiry from the response rather than assuming one. ```bash curl --request GET \ --url https://abhasbx.abdm.gov.in/abha/api/v3/profile/account/request/token \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: ' \ --header 'TIMESTAMP: ' \ --header 'R-token: ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Headers - `REQUEST-ID` (string, required): Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. - `TIMESTAMP` (string, required): ISO 8601 UTC timestamp of the request. - `R-token` (string, required): The refresh token, sent when asking for a new user token without making the person log in again. Required for token refresh. See the shared `RToken` parameter for the general description. ## Responses - `200`: The user token and refresh token, with their expiries. - `400`: Bad Request, invalid scope, loginHint, or encrypted field See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `401`: Unauthorized, missing, invalid, or expired Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden, the token is valid but not permitted for this operation See Error codes for this module: /docs/hiecm/v3/api/m1/errors - `500`: Server error, retry See Error codes for this module: /docs/hiecm/v3/api/m1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "token": "", "expiresIn": 0, "refreshToken": "", "refreshExpiresIn": 0 } ``` --- # M1 ABHA identity errors Seeing a symptom rather than a code? Start at [Troubleshooting](/docs/hiecm/v3/troubleshooting/). ## Six error shapes, not one Do not write a parser that expects a single shape. Four come from the ABHA service and its gateway. The fifth is an empty body. The sixth comes from the registries and hides its real code one level down. ### Shape 1: the wrapped ABDM error ```json { "error": { "code": "ABDM-1204", "message": "UIDAI Error code : 300 : Biometric data did not match." }} ``` The code lives at `error.code`. This comes from the ABHA service's own business logic. Do not compare that code with string equality. It is not always a clean token: a failed session call returned `{"error":{"code":"ABDM-9999: ", "message":"Invalid user credentials"}}`, with a trailing colon and space inside the code. Trim it and match on the `ABDM-nnnn` prefix, or the branch you wrote for that code never runs. ### Shape 2: the flat ABDM error ```json { "code": "ABDM-1094", "message": "Access to this feature is restricted. Please contact NHA to enable it.", "timestamp": "2024-10-25 15:02:34"} ``` Same family of codes, no `error` wrapper, plus a `timestamp`. The collection shows `ABDM-1094` in both shapes on different calls, so the wrapper is not tied to the code. Read `error.code` first and fall back to a top level `code`. ### Shape 3: field validation ```json { "txnId": "Invalid Transaction Id", "timestamp": "2025-01-15 13:21:16"} ``` No code at all. The key names the field you got wrong. Several bad fields produce several keys: ```json { "scope": "Invalid Scope", "authData": "Invalid Auth Data", "timestamp": "2025-01-15 13:39:03"} ``` Treat every key except `timestamp` as a field name. These always arrive as HTTP 400. Two of these read almost the same. Only one of them tells you anything. | Body | What it tells you | | ----------------------------------- | ------------------------------------------------ | | `{"loginId": "LoginId is invalid"}` | It decrypted. The plaintext failed a format rule | | `{"loginId": "Invalid LoginId"}` | On the enrolment endpoint, nothing at all | The first is the one that costs an afternoon, because the value really was encrypted and really was the right number. An ABHA number keeps its dashes, `NN-NNNN-NNNN-NNNN`. The second carries no diagnostic value on `/v3/enrollment/request/otp`. That endpoint returns it for plaintext, for an empty string, for base64 that is not ciphertext, and for a correctly encrypted value alike. A padding matrix run against it returns the same refusal for every row, the correct row included, which is how a wrong padding survives a test that looks thorough. Test encryption against `POST /v3/profile/login/request/otp` with `loginHint: "mobile"` instead, and with a number that is registered against an ABHA account. The 200 is the signal: a right padding returns it with a `txnId`, a wrong one returns `Invalid Mobile Number`. The number has to be a real one. A correctly encrypted `9999999999` returns that same `Invalid Mobile Number`, because the value decrypted fine and named nobody. With an unregistered number this endpoint is as uninformative as the enrolment one. The algorithm is published: read `encryptionAlgorithm` from the certificate response. The plaintext shape for every encrypted field is in [encryption](/docs/hiecm/v3/concepts/encryption). ### Shape 4: the API gateway error ```json { "code": "900901", "message": "Invalid Credentials", "description": "Invalid JWT token. Make sure you have provided the correct security credentials"} ``` A numeric code, not an `ABDM-` code, plus a `description` field the other shapes lack. This comes from the API gateway in front of the ABHA service, before your request reaches the business logic. It almost always means the `Authorization` header is wrong or expired. `900901` is a bad token. `900902` is no token at all, observed on the NHPR host. Match the family, not the single code. ### Shape 5: the empty body An HTTP 401 with a zero length body and no JSON at all, observed on `/v3/phr/web/login/profile/abha-profile` when no user token was sent. There is nothing to parse and nothing to match. Code that assumes every failure carries a body throws here, on a response that means something simple. ### Shape 6: the registry error, with the real code nested ```json { "code": "HIS-422", "message": "Unable to process the current request due to some wrong data entered.", "details": [ {"message": "You are not allowed to access this API", "code": "HIS-403", "attribute": null} ]} ``` The registries return a `HIS-` family rather than `ABDM-`, and the top level code is not the cause. `HIS-422` and its message say the data was wrong. The real reason is in `details[0]`: `HIS-403`, not permitted. The HTTP status disagrees with the nested code too, arriving as 422 for what is an authorisation failure. Read `details[0].code` before the top level one on any `HIS-` response, and show `details[0].message` to whoever is debugging. Acting on the outer code sends you to check your payload for a problem that is not there. ## Codes Code, message and error name are as published. The action column reads the message text by a documented rule, and says Unclassified where the rule could not classify one. | Code | Message | What to do | | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | `ABDM-1001` | Subscription source update returned empty | Unclassified | | `ABDM-1002` | Invalid frequency unit, it must be in HOUR, WEEK, DAY, MONTH, YEAR | Fix request | | `ABDM-1006` | Invalid HIType, it must be in Prescription,DiagnosticReport,OPConsultation,DischargeSummary,ImmunizationRecord,HealthDocumentRecord,WellnessRecord,Invoice | Fix request | | `ABDM-1008` | SMS service currently disabled | Unclassified | | `ABDM-1009` | Email service currently disabled | Unclassified | | `ABDM-1010` | No pending care context found for this abha address | Unclassified | | `ABDM-1013` | Invalid ABHA Number | Fix request | | `ABDM-1016` | Invalid Timestamp | Fix request | | `ABDM-1017` | Invalid Transaction Id | Fix request | | `ABDM-1019` | Dependent Service Unavailable | Retry | | `ABDM-1021` | Lack of required priviledges | Fix request | | `ABDM-1022` | Too many requests | Retry | | `ABDM-1029` | Redis server is unavailable | Retry | | `ABDM-1030` | Request id not found | Fix request | | `ABDM-1034` | Notification service unavailable | Retry | | `ABDM-1045` | Database Access is restricted | Unclassified | | `ABDM-1047` | Purpose does not exist | Fix request | | `ABDM-1048` | Timeout | Retry | | `ABDM-1065` | Health facility does not exist | Fix request | | `ABDM-1066` | Please enter a valid Password | Unclassified | | `ABDM-1094` | Access to this feature is restricted. Please contact NHA to enable it. | Fix auth | | `ABDM-1094` | Invalid Benefit Name | Fix auth | | `ABDM-1100` | You have requested multiple OTPs Or Exceeded maximum number of attempts for OTP match in this transaction. Please try again in 30 minutes. | Retry | | `ABDM-1101` | This ABHA Address already exists. Please create with unique ABHA address | Fix request | | `ABDM-1102` | Mobile number verification is pending. | Unclassified | | `ABDM-1103` | Cannot link with CHILD ABHA Number | Unclassified | | `ABDM-1104` | Cannot link with same ABHA Number | Unclassified | | `ABDM-1105` | Invalid request for parent linking | Fix request | | `ABDM-1107` | Invalid combinations of scopes | Fix request | | `ABDM-1108` | Notification DB service unavailable | Retry | | `ABDM-1109` | Invalid On discovery response | Fix request | | `ABDM-1110` | Your new password must be different from your old password. Please enter a unique new password. | Unclassified | | `ABDM-1111` | Invalid old password, please try with valid password. | Fix request | | `ABDM-1112` | The provided gender does not match the gender in DigiLocker records | Unclassified | | `ABDM-1113` | Duplicate health information provider data flow response data flow resoponse | Fix request | | `ABDM-1114` | The provided name does not match the name in DigiLocker records | Unclassified | | `ABDM-1115` | Invalid patient information. At least one patient information is required. | Fix request | | `ABDM-1116` | generate\_and\_save\_link\_token : 'NoneType' object has no attribute 'get' | Unclassified | | `ABDM-1117` | Auto approval id is already active | Fix request | | `ABDM-1118` | Login via ABHA Number OTP is not allowed | Fix request | | `ABDM-1119` | Login via Aadhaar OTP is not allowed | Fix request | | `ABDM-1121` | Invalid Enrolment Number | Fix request | | `ABDM-1122` | Request can not be processed | Unclassified | | `ABDM-1124` | The mobile number provided by you is already linked to 6 ABHA Numbers. Please provide a different Mobile Number. | Fix request | | `ABDM-1126` | F-Token Expired | Fix request | | `ABDM-1127` | Invalid F-Token | Fix request | | `ABDM-1132` | Kindly enter valid linked ABHA Address | Unclassified | | `ABDM-1133` | Please enter a valid captcha result. Entered captcha result is incorrect. | Fix request | | `ABDM-1134` | Deactivated ABHA Account | Cannot proceed | | `ABDM-1135` | The email address provided by you is already linked to 6 ABHA Numbers. Please provide a different email Id. | Fix request | | `ABDM-1136` | message should not be null or empty. | Unclassified | | `ABDM-1137` | Benefit Name Not Found | Fix request | | `ABDM-1138` | The benefit record has already been de-linked | Treat as success | | `ABDM-1139` | Benefit record not found | Fix request | | `ABDM-1140` | The benefit record has already been linked | Treat as success | | `ABDM-1141` | An existing ABHA number created using this Aadhaar number has been found. It is advisable to delete this account and use ABHA number ((\[0-9]{2}(?:-\[0-9]{4}){3})) for future purpose. | Unclassified | | `ABDM-1142` | Please enter a valid captcha. Entered captcha is expired. | Fix request | | `ABDM-1143` | Captcha limit exceeded. | Unclassified | | `ABDM-1144` | Incorrect facility ID or password. | Fix request | | `ABDM-1155` | Parents must be 18 years of age or older to create a Child ABHA Account | Unclassified | | `ABDM-1156` | Please ensure that the mobile number is mapped to the parent's ABHA number | Unclassified | | `ABDM-1157` | Child ABHA’s account limit has been exceeded for the requested Abha ID number ‘(.\*?) | Unclassified | | `ABDM-1158` | Invalid X-Token | Fix request | | `ABDM-1159` | Children’s ages should be below '(.\*?)' years as of the current date | Unclassified | | `ABDM-1160` | Non KYC CHILD ABHA is allowed to update their profile only once | Unclassified | | `ABDM-1200` | LGD Gateway is unavailable | Retry | | `ABDM-1201` | IDP Gateway is unavailable | Retry | | `ABDM-1202` | Document Gateway is unavailable | Retry | | `ABDM-1203` | TEST | Unclassified | | `ABDM-1204` | A UIDAI failure passed through. The UIDAI code and text sit inside the message string | Fix request | | `ABDM-1205` | Document DB Gateway is unavailable | Retry | | `ABDM-1206` | Aadhaar Gateway is unavailable | Retry | | `ABDM-1207` | The information you provided does not match the details on record with Aadhaar. Please verify and provide accurate information. | Fix request | | `ABDM-1211` | Email Sending Limit Exceeded | Unclassified | | `ABDM-1218` | Role for the user does not exist. | Fix request | | `ABDM-1219` | Your ABHA is linked with govt benefit programme, so it can not be deleted- ABDM, National Health Authority. | Unclassified | | `ABDM-1220` | Sorry, Unable to process your request at this time. Please try again later. | Retry | | `ABDM-1224` | Login via Biometric is not allowed. | Fix auth | | `ABDM-1226` | Vault service unavailable | Retry | | `ABDM-1227` | This client ID has reached the maximum limit of 100 ABHA account creations. | Unclassified | | `ABDM-1228` | Your ABHA is linked with govt benefit programme, so it can not be deactivated- ABDM, National Health Authority. | Cannot proceed | | `ABDM-9999` | Recorded as `ABDM-9999: `with an `ABDM-1094` message stuck to the front of the text | Fix auth | ## Untagged codes The same collection, and the only source that recorded HTTP statuses. | Code | HTTP | Message | What to do | | -------- | ---- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | `900901` | 401 | Invalid Credentials, invalid JWT token. From the API gateway in front of the ABHA service, before your request reaches the business logic | Fix auth | | `900900` | 500 | Unclassified authentication failure. The one saved example had a bad path and a bad token together, so read it as a client error first | Fix auth | | `404` | 404 | No matching resource found for given API Request\`. A wrong path, not a missing record | Fix request | ## UIDAI codes Codes from the Unique Identification Authority of India, passed through inside the message of ABDM-1204. More codes pass through than are listed here, so parse the message. | Code | Message | What to do | | ----- | ---------------------- | ---------- | | `300` | Biometric mismatch | | | `561` | Request expired | | | `563` | Duplicate request | | | `810` | Missing biometric data | | Every code above is recorded in the specification that owns it. The aggregated list across modules is at [error codes](/docs/hiecm/v3/reference/error-codes). [Next Still stuck? Ask for help Where to file what you hit, so the answer lands back in these pages.](/docs/support) --- # M1 ABHA identity Create an ABHA, authenticate a holder, and read or update the profile, QR code and linked mobile number. ## Base URLs | Environment | Base URL | | ----------- | ------------------------------------------ | | Sandbox | `https://abhasbx.abdm.gov.in/abha/api/v3/` | | Production | `https://abha.abdm.gov.in/api/abha/v3/` | Login by Aadhaar number using fingerprint or IRIS uses v3.1 instead: `https://abhasbx.abdm.gov.in/abha/api/v3.1/` in sandbox. No production v3.1 URL is published. [See the user journeyWhat the person experiences, screen by screen, before you write any code.](/docs/hiecm/v3/milestones/m1)[Let's buildThe rules that hold across every call, and the exact order to make them.](/docs/hiecm/v3/api/m1/apis)[When it goes wrongThe recorded error shapes and codes, and what to do about each.](/docs/hiecm/v3/api/m1/errors) New to this? Start with [M1 Create](/docs/hiecm/v3/milestones/m1). --- # Acknowledge a consent notification, as the HIP `POST /hiecm/consent/v3/request/hip/on-notify` Also known as: Consent HIP On-Notify. **Async Callback:** After ABDM Gateway sends a consent grant notification to the HIP bridge URL (`{bridgeUrl}/v0.5/consents/hip/notify`), the HIP calls this Gateway endpoint to acknowledge receipt of the consent artefact. The consent notification contains the full consent details including care contexts, HI types, date range, and digital signature for validation. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/consent/v3/request/hip/on-notify \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "acknowledgement": { "status": "OK", "consentId": "consent-art-uuid-001" }, "response": { "requestId": "req-uuid-from-hip-notify" } }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Body - `acknowledgement` (object, required) - `acknowledgement.status` (string, required) One of: OK, ERROR. - `acknowledgement.consentId` (string, required): The consent artefact ID being acknowledged - `response` (object, required): Echo of the requestId from the original Gateway-to-HIP request - `response.requestId` (string, required): requestId received in the original Gateway request to HIP bridge ## Responses - `202`: Consent acknowledgement accepted See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 --- # Generate Link Token `POST /hiecm/v3/token/generate-token` Generates a short-lived link token for a specific patient identified by their ABHA number/address. The link token is passed as `X-Link-Token` header when calling the care context linking API. Must be called immediately before the linking call, tokens expire quickly. This call is accepted with `202` and carries no token. The token itself arrives on the `m2_on_generate_token_result` callback, at the callback URL registered for your bridge. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/v3/token/generate-token \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2022-10-06T15:10:00.587Z' \ --header 'X-CM-ID: ' \ --header 'X-HIP-ID: IN2810014366' \ --header 'Content-Type: application/json' \ --data '{ "abhaNumber": 91234567890123, "abhaAddress": "patient@sbx", "name": "Ramesh Kumar", "gender": "M", "yearOfBirth": 1985 }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Headers - `REQUEST-ID` (string, required): 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. - `TIMESTAMP` (string, required): The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` 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. - `X-HIP-ID` (string, required): Identifier of the Health Information Provider the request or callback belongs to. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. ## Body - `abhaNumber` (integer): 14-digit ABHA number (optional if abhaAddress provided) - `abhaAddress` (string, required): ABHA address (PHR address) e.g. user@sbx - `name` (string, required) - `gender` (string, required) One of: M, F, O. - `yearOfBirth` (integer, required) ## Responses - `202`: Accepted. No body. The token arrives on the m2_on_generate_token_result callback. See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden. Returned as plain text ("Access Denied"), not JSON. See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `404`: Resource not found See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `500`: Internal server error. See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `503`: Service unavailable. Returned by the link token generation operation. See Error codes for this module: /docs/hiecm/v3/api/m2/errors --- # Notify the gateway that a data transfer finished `POST /hiecm/data-flow/v3/health-information/notify` Also known as: HIP Data Flow Notification. After successfully pushing all encrypted FHIR health data to the HIU's `dataPushUrl`, the HIP calls this endpoint to notify the ABDM Gateway that the data transfer session is complete. The Gateway relays this status to the HIU. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/data-flow/v3/health-information/notify \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "notification": { "consentId": "consent-art-uuid-001", "transactionId": "txn-uuid-data-001", "doneAt": "2024-01-15T10:30:00.000Z", "notifier": { "type": "HIP", "id": "HIP_SERVICE_ID" }, "statusNotification": { "sessionStatus": "TRANSFERRED", "hipId": "HIP_SERVICE_ID", "statusResponses": [ { "careContextReference": "VISIT-2024-001", "hiStatus": "OK", "description": "Successfully transferred" } ] } } }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Body - `notification` (object, required) - `notification.consentId` (string, required) - `notification.transactionId` (string, required) - `notification.doneAt` (string, required) - `notification.notifier` (object, required) - `notification.notifier.type` (string) One of: HIP, HIU. - `notification.notifier.id` (string) - `notification.statusNotification` (object, required) - `notification.statusNotification.sessionStatus` (string) One of: TRANSFERRED, FAILED. - `notification.statusNotification.hipId` (string) - `notification.statusNotification.statusResponses` (object[]) - `notification.statusNotification.statusResponses.careContextReference` (string) - `notification.statusNotification.statusResponses.hiStatus` (string) One of: OK, ERRORED. - `notification.statusNotification.statusResponses.description` (string) ## Responses - `202`: Notification accepted See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 --- # Acknowledge a health information data request `POST /hiecm/data-flow/v3/health-information/hip/on-request` Also known as: HIP Health Information Response. **Async Callback:** After ABDM Gateway sends a health information request to the HIP bridge URL (`{bridgeUrl}/v0.5/health-information/hip/request`), the HIP calls this Gateway endpoint to acknowledge receipt and indicate it will begin processing (ACKNOWLEDGED). After this, the HIP prepares and encrypts FHIR records, then pushes them to the HIU's `dataPushUrl`. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/data-flow/v3/health-information/hip/on-request \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "hiRequest": { "transactionId": "txn-uuid-data-001", "sessionStatus": "ACKNOWLEDGED" }, "response": { "requestId": "req-uuid-from-hi-request" } }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Body - `hiRequest` (object, required) - `hiRequest.transactionId` (string, required): Transaction ID from the original data request - `hiRequest.sessionStatus` (string, required) One of: ACKNOWLEDGED, ERRORED. - `response` (object, required): Echo of the requestId from the original Gateway-to-HIP request - `response.requestId` (string, required): requestId received in the original Gateway request to HIP bridge ## Responses - `202`: Health information request acknowledgement accepted See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 --- # Link care contexts to an ABHA address `POST /hiecm/hip/v3/link/carecontext` Also known as: HIP Initiated Care Context Linking (Single or Multiple). Links one or more care contexts (health records) to a patient's ABHA address. Use the same endpoint for both single and multiple care context linking, the `careContexts` array can contain one or many entries. Requires the `X-Link-Token` header with a freshly generated link token. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/hip/v3/link/carecontext \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2022-10-06T15:10:00.587Z' \ --header 'X-CM-ID: ' \ --header 'X-HIP-ID: IN2810014366' \ --header 'X-Link-Token: ' \ --header 'Content-Type: application/json' \ --data '{ "abhaNumber": "91234567890123", "abhaAddress": "patient@sbx", "patient": [ { "referenceNumber": "PAT-REF-001", "display": "Ramesh Kumar", "careContexts": [ { "referenceNumber": "VISIT-2024-001", "display": "OPD Visit 10-Jan-2024" } ], "hiType": [ "Prescription" ], "count": 1 } ] }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Headers - `REQUEST-ID` (string, required): 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. - `TIMESTAMP` (string, required): The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` 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. - `X-HIP-ID` (string, required): Identifier of the Health Information Provider the request or callback belongs to. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. - `X-Link-Token` (string, required): Short-lived link token generated via POST /hiecm/v3/token/generate-token ## Body - `abhaNumber` (string): 14-digit ABHA number (optional) - `abhaAddress` (string, required): ABHA address of the patient - `patient` (object[], required) - `patient.referenceNumber` (string, required): HIP's internal patient reference number - `patient.display` (string, required): Patient display name - `patient.careContexts` (object[], required) - `patient.hiType` (object[], required) - `patient.count` (integer, required): Total number of care contexts in this entry ## Responses - `202`: Care context linking accepted and queued See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden. Returned as plain text ("Access Denied"), not JSON. See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `404`: Resource not found See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `500`: Internal server error. See Error codes for this module: /docs/hiecm/v3/api/m2/errors --- # Link Care Context Notify `POST /hiecm/hip/v3/link/context/notify` Sends an explicit notification to the ABDM Gateway about a newly linked care context. This is called after successful care context linking to ensure the patient's ABHA App receives a timely notification with the care context details. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/hip/v3/link/context/notify \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2022-10-06T15:10:00.587Z' \ --header 'X-CM-ID: ' \ --header 'X-HIP-ID: IN2810014366' \ --header 'Content-Type: application/json' \ --data '{ "notification": { "patient": { "id": "patient@sbx" }, "careContext": { "patientReference": "patient@sbx", "careContextReference": "VISIT-2024-001" }, "hiTypes": [ "Prescription" ], "date": "2024-01-10T12:00:00.000Z", "hip": { "id": "HIP_SERVICE_ID", "name": "S Y Hospital", "type": "HIP" } } }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Headers - `REQUEST-ID` (string, required): 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. - `TIMESTAMP` (string, required): The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` 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. - `X-HIP-ID` (string, required): Identifier of the Health Information Provider the request or callback belongs to. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. ## Body - `notification` (object, required) - `notification.patient` (object, required) - `notification.patient.id` (string): Patient ABHA address - `notification.careContext` (object, required) - `notification.careContext.patientReference` (string) - `notification.careContext.careContextReference` (string) - `notification.hiTypes` (object[], required) - `notification.date` (string, required) - `notification.hip` (object, required): `id`, `name` and `type` are all required. What `name` and `type` contain beyond a string is not documented. - `notification.hip.id` (string, required) - `notification.hip.name` (string, required) - `notification.hip.type` (string, required) ## Responses - `202`: Notification accepted See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden. Returned as plain text ("Access Denied"), not JSON. See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `404`: Resource not found See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `500`: Internal server error. See Error codes for this module: /docs/hiecm/v3/api/m2/errors --- # The outcome of a care context linking call you made `POST /v3/link/on_carecontext` Hosted by your bridge, not by ABDM. The gateway calls this endpoint at the callback URL registered for your bridge, so the path above is relative to that URL. This is the result leg for `m2_hip_link_care_context`. `response.requestId` echoes the REQUEST-ID you sent to m2_hip_link_care_context. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/v3/link/on_carecontext \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2022-10-06T15:10:00.587Z' \ --header 'X-HIP-ID: IN2810014366' \ --header 'Content-Type: application/json' \ --data '{ "abhaAddress": "", "status": "", "error": { "code": "", "message": "" }, "response": { "requestId": "" } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. M2 also uses per flow tokens, a link token for linking and an authorisation token for patient scoped calls. Their header names are not yet published. ## Headers - `REQUEST-ID` (string, required): 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. - `TIMESTAMP` (string, required): The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. - `X-HIP-ID` (string, required): Identifier of the Health Information Provider the request or callback belongs to. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. ## Body - `abhaAddress` (string): Present on success. - `status` (string): Present on success. Kept as free text rather than a closed enum, since one observed value, "invalid [invalid request]", reads as malformed prose rather than a clean wire value. - `error` (object): The error code and message on a failed callback delivery. - `error.code` (string, required) - `error.message` (string, required) - `response` (object, required): Echo of the requestId from the original Gateway-to-HIP request - `response.requestId` (string, required): requestId received in the original Gateway request to HIP bridge ## Responses - `200`: Your bridge accepted the callback. The gateway validates the body you send back, so a 200 carrying the wrong body is still a failure. --- # A consent notification to an HIU bridge `POST /v0.5/consents/hiu/notify` Inbound to the HIU bridge, at the bridge URL you registered. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/v0.5/consents/hiu/notify \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. M2 also uses per flow tokens, a link token for linking and an authorisation token for patient scoped calls. Their header names are not yet published. ## Responses - `202`: Your bridge accepted the callback. The gateway validates the body you send back, so a 202 carrying the wrong body is still a failure. See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives --- # The outcome of a care context notify call you made `POST /v3/links/context/on-notify` Hosted by your bridge, not by ABDM. The gateway calls this endpoint at the callback URL registered for your bridge, so the path above is relative to that URL. This is the result leg for `m2_link_care_context_notify`. `response.requestId` echoes the REQUEST-ID you sent to m2_link_care_context_notify. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/v3/links/context/on-notify \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2022-10-06T15:10:00.587Z' \ --header 'X-HIP-ID: IN2810014366' \ --header 'Content-Type: application/json' \ --data '{ "acknowledgement": { "status": "SUCCESS" }, "error": { "code": "", "message": "" }, "response": { "requestId": "" } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. M2 also uses per flow tokens, a link token for linking and an authorisation token for patient scoped calls. Their header names are not yet published. ## Headers - `REQUEST-ID` (string, required): 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. - `TIMESTAMP` (string, required): The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. - `X-HIP-ID` (string, required): Identifier of the Health Information Provider the request or callback belongs to. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. ## Body - `acknowledgement` (object, required) - `acknowledgement.status` (string, required) One of: SUCCESS, ERRORED. - `error` (object): The error code and message on a failed callback delivery. - `error.code` (string, required) - `error.message` (string, required) - `response` (object, required): Echo of the requestId from the original Gateway-to-HIP request - `response.requestId` (string, required): requestId received in the original Gateway request to HIP bridge ## Responses - `200`: Your bridge accepted the callback. The gateway validates the body you send back, so a 200 carrying the wrong body is still a failure. --- # The provider pushes encrypted health information to the URL named in the request. `POST /api-hiu/data/notification` The provider pushes encrypted health information to the URL named in the request. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/api-hiu/data/notification \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. M2 also uses per flow tokens, a link token for linking and an authorisation token for patient scoped calls. Their header names are not yet published. ## Responses - `202`: Accepted. Acknowledge quickly, then process asynchronously. See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives --- # On Discovery, HIP responds with found care contexts `POST /hiecm/user-initiated-linking/v3/patient/care-context/on-discover` **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. The HIP matches the patient using the demographics provided (name, gender, DOB, verified identifiers) and returns matching records. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/user-initiated-linking/v3/patient/care-context/on-discover \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2022-10-06T15:10:00.587Z' \ --header 'X-CM-ID: ' \ --header 'Content-Type: application/json' \ --data '{ "transactionId": "txn-uuid-001", "patient": [ { "referenceNumber": "PAT-REF-001", "display": "Ramesh Kumar", "careContexts": [ { "referenceNumber": "VISIT-2024-001", "display": "OPD Visit 10-Jan-2024" }, { "referenceNumber": "LAB-2024-001", "display": "Lab Report 10-Jan-2024" } ], "hiType": [ "DiagnosticReport" ], "count": 2 } ], "response": { "requestId": "req-uuid-from-discover" } }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Headers - `REQUEST-ID` (string, required): 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. - `TIMESTAMP` (string, required): The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` 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 - `transactionId` (string, required): Same transactionId from the discover request received at HIP bridge - `patient` (object[], required) - `patient.referenceNumber` (string, required): HIP's internal patient reference number - `patient.display` (string, required): Patient display name - `patient.careContexts` (object[], required) - `patient.hiType` (object[], required) - `patient.count` (integer, required): Total number of care contexts in this entry - `response` (object, required): Echo of the requestId from the original Gateway-to-HIP request - `response.requestId` (string, required): requestId received in the original Gateway request to HIP bridge ## Responses - `202`: Discovery response accepted by Gateway See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden. Returned as plain text ("Access Denied"), not JSON. See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `500`: Internal server error. See Error codes for this module: /docs/hiecm/v3/api/m2/errors --- # A discovery request for a patient you may hold records for `POST /api/v3/hip/patient/care-context/discover` Inbound to every HIP. Answer with care context metadata only: a discovery response carries no clinical or sensitive data. A rejected answer is reported as ABDM-1109. Retry count, backoff and timeout for this callback are not stated in NHA's material, so treat them as unknown. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/api/v3/hip/patient/care-context/discover \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2022-10-06T15:10:00.587Z' \ --header 'X-HIP-ID: IN2810014366' \ --header 'Content-Type: application/json' \ --data '{ "transactionId": "", "patient": { "id": "", "verifiedIdentifiers": [ "" ], "unverifiedIdentifiers": [ "" ], "name": "", "gender": "M", "yearOfBirth": 0 } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. M2 also uses per flow tokens, a link token for linking and an authorisation token for patient scoped calls. Their header names are not yet published. ## Headers - `REQUEST-ID` (string, required): 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. - `TIMESTAMP` (string, required): The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. - `X-HIP-ID` (string, required): Identifier of the Health Information Provider the request or callback belongs to. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. ## Body - `transactionId` (string, required): A fresh identifier for this discovery flow. Echo it back as response.requestId when you answer on m2_on_discover_care_contexts. - `patient` (object, required) - `patient.id` (string, required): A patient identifier to search your records by. - `patient.verifiedIdentifiers` (object[], required) - `patient.unverifiedIdentifiers` (object[]): Identifiers to search your own records by, not verified by ABDM. - `patient.name` (string, required) - `patient.gender` (string, required) One of: M, F, O, D, T, U. - `patient.yearOfBirth` (integer, required) ## Responses - `202`: Your bridge accepted the callback. The gateway validates the body you send back, so a 202 carrying the wrong body is still a failure. See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives --- # The link token m2_generate_link_token generated, or why it failed `POST /v3/hip/token/on-generate-token` Hosted by your bridge, not by ABDM. The gateway calls this endpoint at the callback URL registered for your bridge, so the path above is relative to that URL. `response.requestId` echoes the REQUEST-ID you sent to m2_generate_link_token, so match this callback to that call before reading `abhaAddress` or `linkToken`. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/v3/hip/token/on-generate-token \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2022-10-06T15:10:00.587Z' \ --header 'X-HIP-ID: IN2810014366' \ --header 'Content-Type: application/json' \ --data '{ "abhaAddress": "", "linkToken": "", "error": { "code": "", "message": "" }, "response": { "requestId": "" } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. M2 also uses per flow tokens, a link token for linking and an authorisation token for patient scoped calls. Their header names are not yet published. ## Headers - `REQUEST-ID` (string, required): 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. - `TIMESTAMP` (string, required): The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. - `X-HIP-ID` (string, required): Identifier of the Health Information Provider the request or callback belongs to. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. ## Body - `abhaAddress` (string): Present on success. - `linkToken` (string): The generated link token, present on success. Pass it as X-Link-Token on the next m2_hip_link_care_context call. - `error` (object): The error code and message on a failed callback delivery. - `error.code` (string, required) - `error.message` (string, required) - `response` (object, required): Echo of the requestId from the original Gateway-to-HIP request - `response.requestId` (string, required): requestId received in the original Gateway request to HIP bridge ## Responses - `200`: Your bridge accepted the callback. The gateway validates the body you send back, so a 200 carrying the wrong body is still a failure. --- # A request for the records a consent covers `POST /api/v3/hip/health-information/request` Inbound to the HIP, carrying the consent id, the date range, the data push URL and the encryption parameters. You have 20 minutes from this request to the data push. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/api/v3/hip/health-information/request \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. M2 also uses per flow tokens, a link token for linking and an authorisation token for patient scoped calls. Their header names are not yet published. ## Responses - `202`: Your bridge accepted the callback. The gateway validates the body you send back, so a 202 carrying the wrong body is still a failure. See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives --- # Confirmation of a link, carrying the token the patient approved `POST /api/v3/hip/link/care-context/confirm` Inbound to the HIP. A duplicate arrives as ABDM-1105, and a rejected answer as ABDM-1111. Retry count, backoff and timeout for this callback are not stated in NHA's material, so treat them as unknown. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/api/v3/hip/link/care-context/confirm \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2022-10-06T15:10:00.587Z' \ --header 'X-HIP-ID: IN2810014366' \ --header 'Content-Type: application/json' \ --data '{ "confirmation": { "token": 0, "linkRefNumber": "5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11" } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. M2 also uses per flow tokens, a link token for linking and an authorisation token for patient scoped calls. Their header names are not yet published. ## Headers - `REQUEST-ID` (string, required): 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. - `TIMESTAMP` (string, required): The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. - `X-HIP-ID` (string, required): Identifier of the Health Information Provider the request or callback belongs to. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. ## Body - `confirmation` (object, required) - `confirmation.token` (integer, required): The 6-digit OTP the patient entered. - `confirmation.linkRefNumber` (string, required): The link reference number from the earlier init step. ## Responses - `202`: Your bridge accepted the callback. The gateway validates the body you send back, so a 202 carrying the wrong body is still a failure. See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives --- # A request to start linking a care context `POST /api/v3/hip/link/care-context/init` Inbound to the HIP. A duplicate arrives as ABDM-1104, and a rejected answer as ABDM-1110. Retry count, backoff and timeout for this callback are not stated in NHA's material, so treat them as unknown. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/api/v3/hip/link/care-context/init \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2022-10-06T15:10:00.587Z' \ --header 'X-HIP-ID: IN2810014366' \ --header 'Content-Type: application/json' \ --data '{ "transactionId": "", "abhaAddress": "", "patient": [ { "referenceNumber": "", "display": "", "careContexts": [ "" ], "hiType": "", "count": 0 } ] }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. M2 also uses per flow tokens, a link token for linking and an authorisation token for patient scoped calls. Their header names are not yet published. ## Headers - `REQUEST-ID` (string, required): 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. - `TIMESTAMP` (string, required): The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. - `X-HIP-ID` (string, required): Identifier of the Health Information Provider the request or callback belongs to. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. ## Body - `transactionId` (string, required) - `abhaAddress` (string, required) - `patient` (object[], required) - `patient.referenceNumber` (string, required) - `patient.display` (string, required) - `patient.careContexts` (object[], required) - `patient.hiType` (object, required) - `patient.count` (integer) ## Responses - `202`: Your bridge accepted the callback. The gateway validates the body you send back, so a 202 carrying the wrong body is still a failure. See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives --- # The outcome of an SMS deep link notify call you made `POST /v3/patients/sms/on-notify` Hosted by your bridge, not by ABDM. The gateway calls this endpoint at the callback URL registered for your bridge, so the path above is relative to that URL. This is the result leg for `m2_sms_deep_link_notify`. `response.requestId` echoes the REQUEST-ID you sent to m2_sms_deep_link_notify. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/v3/patients/sms/on-notify \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2022-10-06T15:10:00.587Z' \ --header 'X-HIP-ID: IN2810014366' \ --header 'Content-Type: application/json' \ --data '{ "acknowledgement": { "status": "SUCCESS" }, "error": { "code": "", "message": "" }, "response": { "requestId": "" } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. M2 also uses per flow tokens, a link token for linking and an authorisation token for patient scoped calls. Their header names are not yet published. ## Headers - `REQUEST-ID` (string, required): 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. - `TIMESTAMP` (string, required): The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. - `X-HIP-ID` (string, required): Identifier of the Health Information Provider the request or callback belongs to. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. ## Body - `acknowledgement` (object, required) - `acknowledgement.status` (string, required) One of: SUCCESS, ERRORED. - `error` (object): The error code and message on a failed callback delivery. - `error.code` (string, required) - `error.message` (string, required) - `response` (object, required): Echo of the requestId from the original Gateway-to-HIP request - `response.requestId` (string, required): requestId received in the original Gateway request to HIP bridge ## Responses - `200`: Your bridge accepted the callback. The gateway validates the body you send back, so a 200 carrying the wrong body is still a failure. --- # Link On-Confirm, HIP confirms linked care contexts `POST /hiecm/user-initiated-linking/v3/link/care-context/on-confirm` **Async Callback:** After receiving a link confirm request at the HIP bridge URL (`{bridgeUrl}/v0.5/links/link/confirm`) with the patient's OTP, the HIP validates the OTP and calls this Gateway endpoint to confirm the linked care contexts. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/user-initiated-linking/v3/link/care-context/on-confirm \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2022-10-06T15:10:00.587Z' \ --header 'X-CM-ID: ' \ --header 'Content-Type: application/json' \ --data '{ "patient": [ { "referenceNumber": "PAT-REF-001", "display": "Ramesh Kumar", "careContexts": [ { "referenceNumber": "VISIT-2024-001", "display": "OPD Visit 10-Jan-2024" } ], "hiType": [ "Prescription" ], "count": 1 } ], "response": { "requestId": "req-uuid-from-link-confirm" } }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Headers - `REQUEST-ID` (string, required): 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. - `TIMESTAMP` (string, required): The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` 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 - `patient` (object[], required) - `patient.referenceNumber` (string, required): HIP's internal patient reference number - `patient.display` (string, required): Patient display name - `patient.careContexts` (object[], required) - `patient.hiType` (object[], required) - `patient.count` (integer, required): Total number of care contexts in this entry - `response` (object, required): Echo of the requestId from the original Gateway-to-HIP request - `response.requestId` (string, required): requestId received in the original Gateway request to HIP bridge ## Responses - `202`: Link confirm response accepted by Gateway See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden. Returned as plain text ("Access Denied"), not JSON. See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `500`: Internal server error. See Error codes for this module: /docs/hiecm/v3/api/m2/errors --- # Link On-Init, HIP responds with OTP communication details `POST /hiecm/user-initiated-linking/v3/link/care-context/on-init` **Async Callback:** After receiving a link init request at the HIP bridge URL (`{bridgeUrl}/v0.5/links/link/init`), the HIP calls this Gateway endpoint to return the authentication details (OTP communication medium and expiry). The Gateway uses this to prompt the patient to enter the OTP for link confirmation. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/user-initiated-linking/v3/link/care-context/on-init \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2022-10-06T15:10:00.587Z' \ --header 'X-CM-ID: ' \ --header 'Content-Type: application/json' \ --data '{ "transactionId": "txn-uuid-001", "link": { "referenceNumber": "link-ref-uuid-001", "authenticationType": "DIRECT", "meta": { "communicationMedium": "MOBILE", "communicationHint": "OTP", "communicationExpiry": "2024-01-10T12:10:00.000Z" } }, "response": { "requestId": "req-uuid-from-link-init" } }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Headers - `REQUEST-ID` (string, required): 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. - `TIMESTAMP` (string, required): The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` 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 - `transactionId` (string, required) - `link` (object, required) - `link.referenceNumber` (string, required): HIP-generated link reference (UUIDv4) - `link.authenticationType` (string, required) One of: DIRECT, MEDIATED. - `link.meta` (object, required) - `link.meta.communicationMedium` (string) One of: MOBILE, EMAIL. - `link.meta.communicationHint` (string): Masked hint (e.g. mobile ending digits) - `link.meta.communicationExpiry` (string) - `response` (object, required): Echo of the requestId from the original Gateway-to-HIP request - `response.requestId` (string, required): requestId received in the original Gateway request to HIP bridge ## Responses - `202`: Link init response accepted by Gateway See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden. Returned as plain text ("Access Denied"), not JSON. See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `500`: Internal server error. See Error codes for this module: /docs/hiecm/v3/api/m2/errors --- # Send an SMS with a deep link to the ABHA App `POST /hiecm/hip/v3/link/patient/links/sms/notify2` Also known as: SMS Deep Link Notify. Requests ABDM to send an SMS to a patient's mobile number containing a deep link to download/open the ABHA App. Used when a patient is not yet on ABDM and the HIP wants to invite them to link their health records. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/hip/v3/link/patient/links/sms/notify2 \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2022-10-06T15:10:00.587Z' \ --header 'X-CM-ID: ' \ --header 'Content-Type: application/json' \ --data '{ "requestId": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "timestamp": "2024-01-10T12:00:00.000Z", "notification": { "phoneNo": "917812345678", "hip": { "name": "S Y Hospital", "id": "HIP_SERVICE_ID" } } }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Headers - `REQUEST-ID` (string, required): 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. - `TIMESTAMP` (string, required): The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` 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 - `requestId` (string, required): Unique request ID (UUIDv4) - `timestamp` (string, required) - `notification` (object, required) - `notification.phoneNo` (string, required): Patient mobile number with country code (e.g. 917812345678) - `notification.hip` (object, required) - `notification.hip.name` (string, required) - `notification.hip.id` (string, required) ## Responses - `202`: SMS notification queued See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `403`: Forbidden. Returned as plain text ("Access Denied"), not JSON. See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `404`: Resource not found See Error codes for this module: /docs/hiecm/v3/api/m2/errors - `500`: Internal server error. See Error codes for this module: /docs/hiecm/v3/api/m2/errors --- # M2 Linking and sharing errors Seeing a symptom rather than a code? Start at [Troubleshooting](/docs/hiecm/v3/troubleshooting/). ## Codes Code, message and error name are as published. The action column reads the message text by a documented rule, and says Unclassified rather than guessing. | Code | Message | What to do | | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | `ABDM-1000` | Unable to connect the database | Retry | | `ABDM-1001` | No data found | Fix request | | `ABDM-1004` | SMS Gateway is unavailable | Retry | | `ABDM-1006` | Invalid HIType, it must be in Prescription,DiagnosticReport,OPConsultation,DischargeSummary,ImmunizationRecord,HealthDocumentRecord,WellnessRecord,Invoice | Fix request | | `ABDM-1006` | Bad Request, invalid request Body | Fix request | | `ABDM-1006` | Invalid combinations of scopes | Fix request | | `ABDM-1006` | Invalid count, must be 2 digit and ranges between 1 to 20 | Fix request | | `ABDM-1007` | Connection failed due to timeout | Retry | | `ABDM-1008` | SMS service currently disabled | Retry | | `ABDM-1010` | Validation failed | Fix request | | `ABDM-1011` | Gateway database unavailable | Retry | | `ABDM-1012` | No records found against the ABHA Address | Fix request | | `ABDM-1013` | Invalid ABHA Number | Fix request | | `ABDM-1015` | Invalid Response | Fix request | | `ABDM-1016` | Invalid TimeStamp | Fix request | | `ABDM-1017` | Invalid TransactionId | Fix request | | `ABDM-1018` | Share Profile database unavailable | Retry | | `ABDM-1019` | Dependent Service Unavailable | Retry | | `ABDM-1020` | Unknown database | Retry | | `ABDM-1022` | Too many requests | Back off | | `ABDM-1023` | Invalid User | Fix request | | `ABDM-1024` | Dependent service unavailable | Retry | | `ABDM-1025` | Invalid ServiceId | Fix request | | `ABDM-1026` | Invalid Link Token | Fix auth | | `ABDM-1027` | You are blocked. Please try again after 24 hours. | Blocked, no retry | | `ABDM-1028` | HIP is unavailable | Chase the [HIP](/docs/hiecm/v3/getting-started/glossary#hip) | | `ABDM-1029` | Redis server is unavailable | Retry | | `ABDM-1030` | Invalid request ID | Fix request | | `ABDM-1030` | Request id not found | Fix request | | `ABDM-1031` | Invalid request | Fix request | | `ABDM-1032` | Invalid header | Fix request | | `ABDM-1033` | HIU is unavailable | Chase the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) | | `ABDM-1034` | Notification service unavailable | Retry | | `ABDM-1035` | Invalid HIP ID | Fix request | | `ABDM-1036` | Data does not matched | Fix request | | `ABDM-1037` | Counter and Care context count mismatch | Fix request | | `ABDM-1038` | ABHA address and Link token mismatch | Fix auth | | `ABDM-1040` | Invalid HIU ID | Fix request | | `ABDM-1041` | Invalid Acknowledgement | Fix request | | `ABDM-1042` | Provider Mandatory | Fix request | | `ABDM-1043` | ABHA Address does not match with KYC details. | Fix request | | `ABDM-1044` | Broadcast Failed | Retry | | `ABDM-1045` | Database Access is restricted | Retry | | `ABDM-1046` | Invalid Purpose | New consent | | `ABDM-1047` | Purpose does not exist | New consent | | `ABDM-1048` | Timeout | Retry | | `ABDM-1049` | Invalid Profile Share Intent Keys | Ask support | | `ABDM-1050` | Invalid Profile Share Metadata Keys | Ask support | | `ABDM-1051` | Invalid ABHA Number or ABHA Address | Fix request | | `ABDM-1052` | Invalid TransactionId or response's requestId | Fix request | | `ABDM-1055` | Invalid HIP Id or PHR Id | Fix request | | `ABDM-1056` | This care contexts has been already linked | Treat as success | | `ABDM-1056` | Invalid Link Reference Number | Fix request | | `ABDM-1057` | Invalid Care Contexts | Fix request | | `ABDM-1059` | Invalid Care Contexts count | Fix request | | `ABDM-1060` | Invalid Patient Reference Number | Fix request | | `ABDM-1061` | Invalid Patient Display | Fix request | | `ABDM-1061` | Consent artefact expired | New consent | | `ABDM-1062` | ABHA number mismatch with Link token | Fix auth | | `ABDM-1062` | Consent Not granted | New consent | | `ABDM-1063` | HIP Id mismatch with Link token | Fix auth | | `ABDM-1063` | Date Range given is invalid | New consent | | `ABDM-1064` | request with this request id already exists | New request id | | `ABDM-1064` | Request body was missing | Fix request | | `ABDM-1065` | Invalid X Auth token | Fix auth | | `ABDM-1066` | Invalid JWT token | Fix auth | | `ABDM-1067` | Request body not required | Fix request | | `ABDM-1084` | ABHA address mismatch with X Auth token | Fix auth | | `ABDM-1085` | ABHA number mismatch with X Auth token | Fix auth | | `ABDM-1086` | Patient profile mismatch with X Auth token | Fix auth | | `ABDM-1087` | Duplicate patient share request | New request id | | `ABDM-1090` | Duplicate HIP link request | New request id | | `ABDM-1091` | Duplicate Get links request | New request id | | `ABDM-1092` | Duplicate Link token request | New request id | | `ABDM-1093` | Duplicate Bridge request | New request id | | `ABDM-1094` | Duplicate bridge patch request | New request id | | `ABDM-1095` | Duplicate Bridge service request | New request id | | `ABDM-1102` | Profile information cannot be null | Ask support | | `ABDM-1103` | Duplicate Discovery request | New request id | | `ABDM-1104` | Duplicate Init request | New request id | | `ABDM-1105` | Duplicate Confirm request | New request id | | `ABDM-1106` | Duplicate On discovery request | New request id | | `ABDM-1107` | Duplicate On init request | New request id | | `ABDM-1108` | Duplicate On confirm request | New request id | | `ABDM-1108` | Notification DB service unavailable | Retry | | `ABDM-1109` | Invalid On discovery response | Fix request | | `ABDM-1109` | ABHA DB service unavailable | Retry | | `ABDM-1110` | Invalid On init response | Fix request | | `ABDM-1111` | Invalid On confirm response | Fix request | | `ABDM-1112` | Invalid or already expired consent artefact id | New consent | | `ABDM-1113` | Duplicate health information provider data flow response | New request id | | `ABDM-1149` | Intent type is not supported at HIP end | Fix request | | `ABDM-1150` | Bridge API version cannot be null | Ask support | | `ABDM-1170` | Invalid ABHA address | Fix request | | `ABDM-1201` | IDP Gateway is unavailable | Retry | | `ABDM-1401` | HIP is not available | Chase the HIP | | `ABDM-1402` | Acknowledgement is not received from HIP | Chase the HIP | | `ABDM-1407` | The ABHA Number associated with this ABHA Address is currently deactivated. Please reactivate it. | Fix request | | `ABDM-2401` | The X Auth token is invalid. | Fix auth | | `ABDM-2402` | Invalid Timestamp | Fix request | | `ABDM-2403` | Invalid X-CM-ID | Fix request | | `ABDM-2404` | Invalid Request Id | Fix request | | `ABDM-2406` | Invalid API sequence flow, please follow logical flow | Fix request | | `ABDM-2406` | The status is invalid. Please follow the logical status flow or transition. | Fix request | | `ABDM-2429` | Too many requests found | Back off | | `ABDM-2500` | Authorization header is missing | Fix auth | | `ABDM-2500` | No mapping found for | Fix request | | `ABDM-2501` | Payment status should be : \`SUCCESS,CANCELED,PENDING,FAIL,REFUND\_INITIATED,REFUND\_SUCCESS | Ask support | | `ABDM-9001` | No open order against ABHA. Please ensure a minimum of one open order | Ask support | | `ABDM-9002` | No registration found at `<>`. Contact counter support | Ask support | | `ABDM-9003` | Hospital services temporarily unavailable. Please try again after some time. | Retry | | `ABDM-9004` | Services disrupted, please try again. | Retry | | `ABDM-9005` | Bank server not responding. Please try again later | Ask support | | `ABDM-9006` | Service details mismatch. Please ensure original service ID from HMIS | Ask support | | `ABDM-9007` | The Scan and Pay functionality is not enabled at this facility. Kindly contact the hospital administration. | Ask support | | `ABDM-9999` | HIP is unable to generate a token at this time. Please try again later. | Chase the HIP | | `ABDM-9999` | HIP is unable to process at this time. Please try again later. | Chase the HIP | | `ABDM-9999` | Unknown exception | Retry | | `ABDM-9999` | Cannot process the request at the moment, please try later. | Retry | | `ABDM-9999` | User not found | Retry | Every code above is recorded in the specification that owns it. The aggregated list across modules is at [error codes](/docs/hiecm/v3/reference/error-codes). [Next Still stuck? Ask for help Where to file what you hit, so the answer lands back in these pages.](/docs/support) --- # M2 linking and sharing Link care contexts to a patient's ABHA address, answer discovery requests, and share encrypted health records with consent. ## Base URLs | Environment | Base URL | | ----------- | -------------------------- | | Sandbox | `https://dev.abdm.gov.in` | | Production | `https://apis.abdm.gov.in` | The full operation list is in the [M2 API reference](/reference/hiecm-m2). New to this? Start with [M2 Attach](/docs/hiecm/v3/milestones/m2). --- # Fetch the full consent artefact `POST /hiecm/consent/v3/fetch` Also known as: Consent Fetch. Fetches the full consent artefact for a given consent artefact ID. Should be called after receiving the `on-notify` callback with status `GRANTED`. The artefact contains: - Exact care contexts approved - HI types permitted - Date range for data access - Data erase date - Digital signature for validation - HIP and HIU identifiers Store the artefact securely, it is required for the health information request. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/consent/v3/fetch \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' \ --header 'X-HIU-ID: IN2810014366' \ --header 'Content-Type: application/json' \ --data '{ "consentId": "consent-art-uuid-001" }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. The callback that answers it carries the same value. In M3 a single consent can produce several callbacks, so keep the mapping from request id to consent request id rather than relying on ordering. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. - `X-HIU-ID` (string, required): Identifier of the health information user the request or callback is intended for. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. ## Body - `consentId` (string, required): Consent artefact ID (from consentArtefacts array in on-notify or status) ## Responses - `200`: Consent artefact details. - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m3/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Resource not found See Error codes for this module: /docs/hiecm/v3/api/m3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "consent": { "status": "GRANTED", "consentDetail": { "consentId": "", "createdAt": "2026-08-24T10:15:30.000Z", "purpose": { "text": "", "code": "" }, "patient": { "id": "" }, "careContexts": [ { "patientReference": "", "careContextReference": "" } ], "hiTypes": [ "" ], "permission": "", "hiu": { "id": "" }, "hip": { "id": "" } }, "signature": "" } } ``` --- # Acknowledge a consent notification, as the HIU `POST /hiecm/consent/v3/request/hiu/on-notify` Also known as: Consent HIU On-Notify. **Async Callback:** After ABDM Gateway sends a consent grant/deny notification to the HIU bridge URL (`{bridgeUrl}/v0.5/consents/hiu/notify`), the HIU calls this Gateway endpoint to acknowledge receipt. The Gateway sends this notification when: - Patient grants the consent - Patient denies the consent - A previously granted consent is revoked ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/consent/v3/request/hiu/on-notify \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' \ --header 'Content-Type: application/json' \ --data '{ "acknowledgement": [ { "status": "OK", "consentId": "consent-art-uuid-001" } ], "response": { "requestId": "req-uuid-from-hiu-notify" } }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. The callback that answers it carries the same value. In M3 a single consent can produce several callbacks, so keep the mapping from request id to consent request id rather than relying on ordering. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. ## Body - `acknowledgement` (object[], required) - `acknowledgement.status` (string, required) One of: OK, ERROR. - `acknowledgement.consentId` (string, required) - `response` (object, required): Echo of the requestId from the original Gateway-to-HIU request - `response.requestId` (string, required): requestId received in the original Gateway notification to HIU bridge ## Responses - `202`: Acknowledgement accepted See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m3/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 --- # Initiate a consent request `POST /hiecm/consent/v3/request/init` Also known as: Consent Init Request. Initiates a new consent request for a patient's health records. The Gateway notifies the patient via the ABHA App. The patient can approve or deny. The HIU receives the patient's decision via a callback to `{hiuBridgeUrl}/v0.5/consents/hiu/notify`. **Key fields:** - `purpose.code`, ABDM-defined purpose codes (e.g. `CAREMGT`, `BTG`, `PUBHLTH`, `HPAYMT`, `DSRCH`, `PATRQST`) - `hiTypes`, Health Information types requested - `permission.accessMode`, `VIEW` (read-only) or `STORE` - `permission.dataEraseAt`, Consent expiry after which data access is revoked ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/consent/v3/request/init \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' \ --header 'Content-Type: application/json' \ --data '{ "consent": { "purpose": { "text": "Care Management", "code": "CAREMGT", "refUri": "http://terminology.hl7.org/CodeSystem/v3-ActReason" }, "patient": { "id": "patient@sbx" }, "hiu": { "id": "HIU_SERVICE_ID", "name": "City Health HIU" }, "hip": null, "careContexts": null, "requester": { "name": "Dr. Sharma", "identifier": { "type": "REGNO", "value": "MCI-12345", "system": "https://www.mciindia.org" } }, "hiTypes": [ "Prescription", "DiagnosticReport" ], "permission": { "accessMode": "VIEW", "dateRange": { "from": "2023-01-01T00:00:00.000Z", "to": "2024-01-01T00:00:00.000Z" }, "dataEraseAt": "2025-01-01T00:00:00.000Z", "frequency": { "unit": "HOUR", "value": 1, "repeats": 0 } } } }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. The callback that answers it carries the same value. In M3 a single consent can produce several callbacks, so keep the mapping from request id to consent request id rather than relying on ordering. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. ## Body - `consent` (object, required) - `consent.purpose` (object, required) - `consent.purpose.text` (string, required) - `consent.purpose.code` (string, required): ABDM consent purpose codes: - CAREMGT: Care Management - BTG: Break the Glass (emergency) - PUBHLTH: Public Health - HPAYMT: Health Payment - DSRCH: Disease Specific Healthcare Research - PATRQST: Patient Requested One of: CAREMGT, BTG, PUBHLTH, HPAYMT, DSRCH, PATRQST. - `consent.purpose.refUri` (string) - `consent.patient` (object, required) - `consent.patient.id` (string, required): Patient's ABHA address - `consent.hiu` (object, required) - `consent.hiu.id` (string, required): HIU service ID - `consent.hiu.name` (string, required): HIU display name. - `consent.hiu.type` (string): Not otherwise constrained. - `consent.hip` (object,null): Specific HIP to request from (null = any HIP) - `consent.hip.id` (string, required) - `consent.hip.name` (string, required): HIP display name. - `consent.hip.type` (string): Not otherwise constrained. - `consent.careContexts` (array,null): Specific care contexts (null = all matching contexts) - `consent.requester` (object, required) - `consent.requester.name` (string, required): Doctor / requester name - `consent.requester.identifier` (object, required) - `consent.requester.identifier.type` (string) One of: REGNO, NMC, MCI, AYUSH. - `consent.requester.identifier.value` (string) - `consent.requester.identifier.system` (string) - `consent.hiTypes` (object[], required): Health Information types being requested - `consent.permission` (object, required) ## Responses - `202`: Consent request initiated successfully See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m3/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 Shape of the 202 response, generated from the schema. The values are placeholders, not a captured response: ```json { "consentRequestId": "" } ``` --- # Check the status of a consent request `POST /hiecm/consent/v3/request/status` Also known as: Consent Request Status. Checks the current status of a previously initiated consent request. Can be polled periodically while awaiting patient action. **Status values:** - `REQUESTED`, Awaiting patient action - `GRANTED`, Patient approved; `consentArtefacts` array will contain artefact IDs - `DENIED`, Patient denied the request - `EXPIRED`, Request timed out without patient action - `REVOKED`, Previously granted consent was revoked by the patient ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/consent/v3/request/status \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' \ --header 'X-HIU-ID: IN2810014366' \ --header 'Content-Type: application/json' \ --data '{ "consentRequestId": "req-uuid-001" }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. The callback that answers it carries the same value. In M3 a single consent can produce several callbacks, so keep the mapping from request id to consent request id rather than relying on ordering. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. - `X-HIU-ID` (string, required): Identifier of the health information user the request or callback is intended for. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. ## Body - `consentRequestId` (string, required): ID returned from the consent init call ## Responses - `200`: Consent request status - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m3/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "consentRequestId": "req-uuid-001", "status": "GRANTED", "consentArtefacts": [ { "id": "consent-art-uuid-001" } ] } ``` --- # Health Information Request Status `GET /hiecm/data-flow/v3/health-information/request/status/{transaction-id}` Polls the current status of a previously made health information request, by transaction id. An alternative to waiting for the `on-request` and data flow notify callbacks: useful if a callback was missed, or if the integration prefers to poll rather than depend on inbound delivery. ```bash curl --request GET \ --url https://dev.abdm.gov.in/api/hiecm/data-flow/v3/health-information/request/status/{transaction-id} \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. The callback that answers it carries the same value. In M3 a single consent can produce several callbacks, so keep the mapping from request id to consent request id rather than relying on ordering. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. ## Path parameters - `transaction-id` (string, required): The health information request transaction id, from the original request. ## Responses - `200`: Current status of the health information request. - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m3/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Resource not found See Error codes for this module: /docs/hiecm/v3/api/m3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "transactionId": "", "status": "" } ``` --- # Notify the gateway that data was received `POST /hiecm/data-flow/v3/health-information/notify` Also known as: HIU Data Flow Notification. After receiving all FHIR health data at the `dataPushUrl`, the HIU calls this endpoint to notify the ABDM Gateway that the data transfer session is complete. The `statusNotification.sessionStatus` should be: - `RECEIVED`, All data received successfully - `FAILED`, Data receipt failed (with details in `statusResponses`) The `notifier.type` must be `HIU` (contrast with M2 where the HIP sends the same endpoint with `notifier.type: HIP`, and the value it sends is `TRANSFERRED` rather than `RECEIVED`; the two milestones report the same event with different values because they are the two ends of the same transfer). ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/data-flow/v3/health-information/notify \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' \ --header 'Content-Type: application/json' \ --data '{ "notification": { "consentId": "consent-art-uuid-001", "transactionId": "txn-uuid-data-001", "doneAt": "2024-01-15T10:30:00.000Z", "notifier": { "type": "HIU", "id": "HIU_SERVICE_ID" }, "statusNotification": { "sessionStatus": "RECEIVED", "hipId": "HIP_SERVICE_ID", "statusResponses": [ { "careContextReference": "VISIT-2024-001", "hiStatus": "OK", "description": "Data received and decrypted successfully" }, { "careContextReference": "LAB-2024-001", "hiStatus": "OK", "description": "Data received and decrypted successfully" } ] } } }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. The callback that answers it carries the same value. In M3 a single consent can produce several callbacks, so keep the mapping from request id to consent request id rather than relying on ordering. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. ## Body - `notification` (object, required) - `notification.consentId` (string, required) - `notification.transactionId` (string, required) - `notification.doneAt` (string, required) - `notification.notifier` (object, required) - `notification.notifier.type` (string, required): Must be "HIU" for M3 (vs "HIP" for M2) One of: HIP, HIU. - `notification.notifier.id` (string, required) - `notification.statusNotification` (object, required) - `notification.statusNotification.sessionStatus` (string, required): HIU-side value, this is the M3 half of the exchange. RECEIVED on success, not TRANSFERRED, which is what the HIP sends on the M2 side of the same event. One of: RECEIVED, FAILED. - `notification.statusNotification.hipId` (string, required) - `notification.statusNotification.statusResponses` (object[], required) - `notification.statusNotification.statusResponses.careContextReference` (string) - `notification.statusNotification.statusResponses.hiStatus` (string) One of: OK, ERRORED. - `notification.statusNotification.statusResponses.description` (string) ## Responses - `202`: Notification accepted See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m3/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 --- # Request a patient's health information `POST /hiecm/data-flow/v3/health-information/request` Also known as: HIU Health Information Request. Requests health data from the HIP for a specific consent artefact. The HIU must: 1. Generate an ECDH key pair before this call 2. Pass the ECDH public key in `keyMaterial.dhPublicKey` 3. Expose a `dataPushUrl` endpoint that can receive encrypted FHIR data from the HIP The HIP encrypts data using the HIU's public key (ECDH shared secret) and pushes it to `dataPushUrl`. The HIU decrypts using its private key + HIP's public key from the push request's `keyMaterial`. **Supported ECDH curves:** `Curve25519` **Supported crypto algorithms:** `ECDH` ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/hiecm/data-flow/v3/health-information/request \ --header 'Authorization: Bearer ' \ --header 'REQUEST-ID: 5f7a4a1e-59ba-4c0c-9e0c-8e6b3b6e2f11' \ --header 'TIMESTAMP: 2026-08-25T15:51:15.339Z' \ --header 'X-CM-ID: ' \ --header 'X-HIU-ID: IN2810014366' \ --header 'Content-Type: application/json' \ --data '{ "hiRequest": { "consent": { "id": "consent-art-uuid-001" }, "dateRange": { "from": "2023-01-01T00:00:00.000Z", "to": "2024-01-01T00:00:00.000Z" }, "dataPushUrl": "https://your-hiu-server.com/abdm/data/push", "keyMaterial": { "cryptoAlg": "ECDH", "curve": "Curve25519", "dhPublicKey": { "expiry": "2024-12-31T00:00:00.000Z", "parameters": "Curve25519/32byte", "keyValue": "base64-encoded-hiu-ecdh-public-key" }, "nonce": "base64-encoded-random-nonce-32bytes" } } }' ``` ## Authorization - `Authorization` (bearer token, required): Bearer token obtained from POST /hiecm/gateway/v3/sessions ## Headers - `REQUEST-ID` (string, required): A fresh UUID that you generate for this request. The callback that answers it carries the same value. In M3 a single consent can produce several callbacks, so keep the mapping from request id to consent request id rather than relying on ordering. - `TIMESTAMP` (string, required): The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. - `X-CM-ID` (string, required): Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. - `X-HIU-ID` (string, required): Identifier of the health information user the request or callback is intended for. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. ## Body - `hiRequest` (object, required) - `hiRequest.consent` (object, required) - `hiRequest.consent.id` (string, required): Consent artefact ID from the granted consent - `hiRequest.dateRange` (object, required) - `hiRequest.dateRange.from` (string, required): Must be within the consent's permitted date range - `hiRequest.dateRange.to` (string, required) - `hiRequest.dataPushUrl` (string, required): HTTPS endpoint on the HIU server to receive encrypted FHIR data - `hiRequest.keyMaterial` (object, required) ## Responses - `202`: Health information request accepted See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Bad request, invalid parameters or missing fields See Error codes for this module: /docs/hiecm/v3/api/m3/errors - `401`: Unauthorized, missing or invalid Bearer token See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 Shape of the 202 response, generated from the schema. The values are placeholders, not a captured response: ```json { "transactionId": "" } ``` --- # The consent artefact detail, fetched by artefact id `POST /api/v3/hiu/consent/on-fetch` The artefact itself, in answer to a fetch by artefact id. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/api/v3/hiu/consent/on-fetch \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "consent": { "status": "GRANTED", "consentDetail": { "consentId": "28ef6ae8-ad03-488d-b26e-940e27154cc0", "hip": { "id": "HIP_ID", "name": "", "type": "HIP" }, "hiu": { "id": "MANISH_HIU" }, "hiTypes": [ "Prescription", "DiagnosticReport", "DischargeSummary", "ImmunizationRecord", "HealthDocumentRecord", "WellnessRecord", "OPConsultation" ], "patient": { "id": "abha@sbx" }, "purpose": { "text": "Care Management", "code": "CAREMGT", "refUri": "www.abdm.gov.in" }, "createdAt": "2026-07-21T10:51:32.000Z", "requester": { "name": "", "identifier": { "value": "MH1001", "type": "REGNO", "system": "https://www.mciindia.org" } }, "permission": { "accessMode": "VIEW", "dateRange": { "from": "1995-09-13T17:18:44.408Z", "to": "2026-02-11T10:08:44.408Z" }, "dataEraseAt": "2026-08-20T06:16:54.710Z", "frequency": { "unit": "DAY", "value": 0, "repeats": 0 } }, "lastUpdated": "2026-07-21T10:51:32.001Z", "careContexts": [ { "patientReference": "manishk@abdm", "careContextReference": "manishk@abdm-02" } ], "schemaVersion": "v3", "consentManager": { "id": "sbx" } }, "signature": "a6aukWvKlwH1myRXb/liHAwKCCFGcKbqGKrEQL+ZE4Ie8RssNAcyF6mwQAZ/DkpeSHrqV4SEMDcEeQB/RmK67R5lpC2t/s09Kpy2KkbHlZmb4EUgl/RBDa1o1V02YeivxSSsgNFbJa7EQuQujYoSVGAACsZP/04lhgOUibUq0rzo1wilO7O+BAeDpezUhs0216GFJnOebbR72tZQSUUPee5TPRJBpGdmjh8p8bmxRAIUSEp1ntLDi7TQOv0AqprcbM6uJbMZ8qBJJYizxri9W3NoEdPU/sdzWKjyth02TCzzE4mv5/DUpzzpUa2KyHZTrju7jhhmGL8ABcpriSuyhA==" }, "error": null, "response": { "requestId": "e1ff8798-53c1-4d1c-8443-e38589c7ac98" }, "resp": null }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Body - `consent` (object, required) - `consent.status` (string, required): Matches ConsentFetchResponse.consent.status. One of: GRANTED, DENIED, REVOKED, EXPIRED. - `consent.consentDetail` (object, required) - `consent.consentDetail.consentId` (string, required) - `consent.consentDetail.hip` (object, required) - `consent.consentDetail.hip.id` (string, required) - `consent.consentDetail.hip.name` (string, required) - `consent.consentDetail.hip.type` (string, required) - `consent.consentDetail.hiu` (object, required) - `consent.consentDetail.hiu.id` (string, required) - `consent.consentDetail.hiTypes` (string[], required) - `consent.consentDetail.patient` (object, required) - `consent.consentDetail.patient.id` (string, required) - `consent.consentDetail.purpose` (object, required) - `consent.consentDetail.purpose.text` (string, required) - `consent.consentDetail.purpose.code` (string, required) - `consent.consentDetail.purpose.refUri` (string, required) - `consent.consentDetail.createdAt` (string, required) - `consent.consentDetail.requester` (object, required) - `consent.consentDetail.requester.name` (string, required) - `consent.consentDetail.requester.identifier` (object, required) - `consent.consentDetail.permission` (object, required) - `consent.consentDetail.permission.accessMode` (string, required) - `consent.consentDetail.permission.dateRange` (object, required) - `consent.consentDetail.permission.dataEraseAt` (string, required) - `consent.consentDetail.permission.frequency` (object, required) - `consent.consentDetail.lastUpdated` (string, required) - `consent.consentDetail.careContexts` (object[], required) - `consent.consentDetail.careContexts.patientReference` (string, required) - `consent.consentDetail.careContexts.careContextReference` (string, required) - `consent.consentDetail.schemaVersion` (string, required) - `consent.consentDetail.consentManager` (object, required) - `consent.consentDetail.consentManager.id` (string, required) - `consent.signature` (string, required) - `error` (null, required) - `response` (object, required) - `response.requestId` (string, required) - `resp` (null, required) ## Responses - `200`: Your bridge acknowledged the callback with 200 OK. The gateway validates the body you send back, so a 200 carrying the wrong body is still a failure. --- # The consent request was accepted, with its request id `POST /api/v3/hiu/consent/request/on-init` Carries the consent request and the request id. Store the request id: it is how a later notification is tied back to the request you made. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/api/v3/hiu/consent/request/on-init \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "consentRequest": { "id": "77969467-5a92-44bb-9d6c-4caf24907ea5" }, "error": null, "response": { "requestId": "6cb80f71-49fa-4f8c-93d5-de9916a708e8" } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Body - `consentRequest` (object, required) - `consentRequest.id` (string, required) - `error` (null, required) - `response` (object, required) - `response.requestId` (string, required) ## Responses - `200`: Your bridge acknowledged the callback with 200 OK. The gateway validates the body you send back, so a 200 carrying the wrong body is still a failure. --- # The patient's decision, sent to the record holder `POST /api/v3/consent/request/hip/notify` The same decision sent to the system that holds the records, with all care context references. `status` only ever carries `GRANTED`, `REVOKED` or `EXPIRED` on this callback. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/api/v3/consent/request/hip/notify \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "status": "GRANTED", "consentId": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "consentDetail": { "schemaVersion": "v3", "consentId": "3fa85f64-5717-4562-b3fc-2c963f66afa6", "createdAt": "2024-05-01T05:10:20.123Z", "patient": { "id": "abdulkalam@abdm" }, "careContexts": [ { "patientReference": "batman@tmh", "careContextReference": "Episode1" } ], "purpose": { "text": "Care Management", "code": "CAREMGT", "refUri": "www.abc.com" }, "hip": { "id": "cowin_hip_01", "name": "Cowin", "type": "HIP" }, "hiu": { "id": "cowin_hiu_01", "name": "Cowin", "type": "HIU" }, "consentManager": { "id": "abdm" }, "requester": { "name": "abdulkalam@abdm", "identifier": { "value": "REG1", "type": "MH1001", "system": "https://www.sample.com" } }, "hiTypes": [ "Prescription" ], "permission": { "accessMode": "VIEW", "dateRange": { "from": "2021-09-28T12:30:08.573Z", "to": "2021-09-28T12:30:08.573Z" }, "dataEraseAt": "2021-09-28T12:30:08.573Z", "frequency": { "unit": "HOUR", "value": 1, "repeats": 0 } } }, "signature": "scrubbed-base64-signature", "grantAcknowledgement": false }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Body - `status` (string, required): The values actually sent to a HIP on this callback. One of: GRANTED, REVOKED, EXPIRED. - `consentId` (string, required) - `consentDetail` (object, required) - `consentDetail.schemaVersion` (string, required) - `consentDetail.consentId` (string, required) - `consentDetail.createdAt` (string, required) - `consentDetail.patient` (object, required) - `consentDetail.patient.id` (string, required) - `consentDetail.careContexts` (object[], required) - `consentDetail.careContexts.patientReference` (string, required) - `consentDetail.careContexts.careContextReference` (string, required) - `consentDetail.purpose` (object, required) - `consentDetail.purpose.text` (string, required) - `consentDetail.purpose.code` (string, required) - `consentDetail.purpose.refUri` (string, required) - `consentDetail.hip` (object, required) - `consentDetail.hip.id` (string, required) - `consentDetail.hip.name` (string, required) - `consentDetail.hip.type` (string) - `consentDetail.hiu` (object, required) - `consentDetail.hiu.id` (string, required) - `consentDetail.hiu.name` (string, required) - `consentDetail.hiu.type` (string) - `consentDetail.consentManager` (object, required) - `consentDetail.consentManager.id` (string, required) - `consentDetail.requester` (object, required) - `consentDetail.requester.name` (string, required) - `consentDetail.requester.identifier` (object, required) - `consentDetail.requester.identifier.value` (string, required) - `consentDetail.requester.identifier.type` (string, required) - `consentDetail.requester.identifier.system` (string, required) - `consentDetail.hiTypes` (object[], required) - `consentDetail.permission` (object, required) - `consentDetail.permission.accessMode` (string, required) One of: VIEW, STORE, QUERY, STREAM. - `consentDetail.permission.dateRange` (object, required) - `consentDetail.permission.dateRange.from` (string): Start of the data access window - `consentDetail.permission.dateRange.to` (string): End of the data access window - `consentDetail.permission.dataEraseAt` (string, required): Consent expiry, after this the HIU must delete the data - `consentDetail.permission.frequency` (object, required) - `consentDetail.permission.frequency.unit` (string) One of: HOUR, DAY, WEEK, MONTH, YEAR. - `consentDetail.permission.frequency.value` (integer): Frequency value - `consentDetail.permission.frequency.repeats` (integer): Number of repeats (0 = unlimited during consent period) - `signature` (string, required): Base64-encoded digital signature of the consent artefact. - `grantAcknowledgement` (boolean, required): Required; no further semantics are documented for this field beyond the boolean value. ## Responses - `200`: Your bridge acknowledged the callback with 200 OK. The gateway validates the body you send back, so a 200 carrying the wrong body is still a failure. --- # The patient's decision, sent to the requester `POST /api/v3/hiu/consent/request/notify` On a grant, carries every consent artefact id created against the request, with the request id. On a denial, carries the denial, with `reason` set if the gateway supplied one. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/api/v3/hiu/consent/request/notify \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "notification": { "consentRequestId": "77969467-5a92-44bb-9d6c-4caf24907ea5", "status": "GRANTED", "reason": null, "consentArtefacts": [ { "id": "28ef6ae8-ad03-488d-b26e-940e27154cc0" } ] } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Body - `notification` (object, required) - `notification.consentRequestId` (string, required) - `notification.status` (string, required) - `notification.reason` (string,null, required): Set when the request was denied; null otherwise. - `notification.consentArtefacts` (object[], required) - `notification.consentArtefacts.id` (string, required) ## Responses - `200`: Your bridge acknowledged the callback with 200 OK. The gateway validates the body you send back, so a 200 carrying the wrong body is still a failure. --- # The consent manager reports the state of a consent request you asked about. `POST /api/v3/hiu/consent/request/on-status` The consent manager reports the state of a consent request you asked about. GRANTED is absent from `status`'s enum here on purpose: a grant is communicated through the notify callback with `consentArtefacts`, not through this status callback. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/api/v3/hiu/consent/request/on-status \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "consentRequest": { "id": "77969467-5a92-44bb-9d6c-4caf24907ea5", "status": "REQUESTED" }, "error": null, "response": { "requestId": "68b099de-f7ba-4a92-9bd5-97de2e397f31" }, "resp": null }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Body - `consentRequest` (object, required) - `consentRequest.id` (string, required) - `consentRequest.status` (string, required): GRANTED is not one of these values; see the operation description for why. One of: REQUESTED, DENIED, EXPIRED, REVOKED. - `error` (null, required) - `response` (object, required) - `response.requestId` (string, required) - `resp` (null, required) ## Responses - `200`: OK. Acknowledge quickly, then process asynchronously. --- # Acknowledgement of a health information request `POST /api/v3/hiu/health-information/on-request` Carries the transaction id, the request id and the current status. This is an acknowledgement, not the records. The records arrive at the data push URL you supplied. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/api/v3/hiu/health-information/on-request \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "hiRequest": { "transactionId": "8376a2b0-3fc9-4bb5-8af5-54a49a3910f4", "sessionStatus": "REQUESTED" }, "error": null, "response": { "requestId": "e492d2b5-5f0a-4406-8a5d-5b4351e2ff2c" } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Body - `hiRequest` (object, required) - `hiRequest.transactionId` (string, required) - `hiRequest.sessionStatus` (string, required) - `error` (null, required) - `response` (object, required) - `response.requestId` (string, required) ## Responses - `200`: Your bridge acknowledged the callback with 200 OK. The gateway validates the body you send back, so a 200 carrying the wrong body is still a failure. --- # The encrypted health data itself, pushed to the URL you supplied `POST /health-information/transfer` The actual encrypted FHIR bundle. The HIP Data Bridge posts this directly to the `dataPushUrl` you supplied in the health information request; it is not routed through the Gateway, and this literal path is illustrative rather than fixed, because `dataPushUrl` is a URL you host and register yourself. Decrypt `entries[].content` with the ECDH shared secret derived from your private key and `keyMaterial`. `entries[].checksum` is the MD5 of the content before encryption, so verify it after decrypting. Large payloads arrive across several calls, paginated by `pageNumber` and `pageCount`. ```bash curl --request POST \ --url https://dev.abdm.gov.in/api/health-information/transfer \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "pageNumber": 1, "pageCount": 1, "transactionId": "8376a2b0-3fc9-4bb5-8af5-54a49a3910f4", "entries": [ { "content": "encrypted-fhir-bundle-content", "media": "application/fhir+json", "checksum": "d41d8cd98f00b204e9800998ecf8427e", "careContextReference": "manishk@abdm-02" } ], "keyMaterial": { "cryptoAlg": "ECDH", "curve": "Curve25519", "dhPublicKey": { "expiry": "2024-12-31T00:00:00.000Z", "parameters": "Curve25519/32byte", "keyValue": "base64-encoded-hip-ecdh-public-key" }, "nonce": "base64-encoded-random-nonce-32bytes" } }' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Body - `pageNumber` (integer, required): Current page number, for a multi-page transfer. - `pageCount` (integer, required): Total number of pages in this transfer. - `transactionId` (string, required): The transaction id issued when the health information was requested. - `entries` (object[], required) - `entries.content` (string, required): Encrypted FHIR bundle content. - `entries.media` (string, required) One of: application/fhir+json. - `entries.checksum` (string, required): MD5 checksum of the content, taken before encryption. - `entries.careContextReference` (string, required): The care context this entry's data belongs to. - `keyMaterial` (object, required): ECDH key material for end-to-end encryption of health data - `keyMaterial.cryptoAlg` (string, required) One of: ECDH. - `keyMaterial.curve` (string, required) One of: Curve25519. - `keyMaterial.dhPublicKey` (object, required) - `keyMaterial.dhPublicKey.expiry` (string, required): Key expiry time - `keyMaterial.dhPublicKey.parameters` (string, required) - `keyMaterial.dhPublicKey.keyValue` (string, required): Base64-encoded ECDH public key (32 bytes for Curve25519) - `keyMaterial.nonce` (string, required): Base64-encoded random nonce (32 bytes), unique per request ## Responses - `202`: Accepted. Verify the checksum after decrypting before treating the transfer as complete. See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives --- # M3 Consent and fetching errors Seeing a symptom rather than a code? Start at [Troubleshooting](/docs/hiecm/v3/troubleshooting/). ## Codes Code, message and error name are as published. The action column reads the message text by a documented rule, and says Unclassified where the rule could not classify one. | Code | Message | What to do | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | | `ABDM-1000` | Unable to connect the database | Retry | | `ABDM-1001` | Subscription source update returned empty | Unclassified | | `ABDM-1002` | Invalid frequency unit, it must be in HOUR, WEEK, DAY, MONTH, YEAR | Fix request | | `ABDM-1003` | Email Gateway is unavailable | Retry | | `ABDM-1004` | SMS Gateway is unavailable | Retry | | `ABDM-1005` | Invalid receiver | Fix request | | `ABDM-1006` | Invalid HIType, it must be in Prescription,DiagnosticReport,OPConsultation,DischargeSummary,ImmunizationRecord,HealthDocumentRecord,WellnessRecord,Invoice | Fix request | | `ABDM-1007` | Connection failed due to timeout | Retry | | `ABDM-1008` | SMS service currently disabled | Unclassified | | `ABDM-1009` | Email service currently disabled | Unclassified | | `ABDM-1010` | No pending care context found for this abha address | Unclassified | | `ABDM-1011` | Gateway database unavailable | Retry | | `ABDM-1012` | No records found against the ABHA Address | Unclassified | | `ABDM-1013` | Invalid ABHA Number | Fix request | | `ABDM-1014` | Invalid Mobile Email | Fix request | | `ABDM-1015` | Invalid Response | Fix request | | `ABDM-1016` | Invalid Timestamp | Fix request | | `ABDM-1017` | Invalid Transaction Id | Fix request | | `ABDM-1018` | Share Profile database unavailable | Retry | | `ABDM-1019` | Dependent Service Unavailable | Retry | | `ABDM-1020` | Unknown database | Unclassified | | `ABDM-1021` | Lack of required priviledges | Fix request | | `ABDM-1022` | Too many requests | Retry | | `ABDM-1023` | Invalid User | Fix request | | `ABDM-1024` | Dependent service unavailable | Retry | | `ABDM-1025` | Invalid ServiceId | Fix request | | `ABDM-1026` | Bridge Id not found | Fix request | | `ABDM-1027` | You are blocked. Please try again after 24 hours. | Cannot proceed | | `ABDM-1028` | HIP is unavailable | Retry | | `ABDM-1029` | Redis server is unavailable | Retry | | `ABDM-1030` | Request id not found | Fix request | | `ABDM-1031` | Invalid reason. Reason should not be null or empty and should contains only alphabets, dot(.) and comma(,) | Fix request | | `ABDM-1032` | Invalid header | Fix request | | `ABDM-1033` | HIU is unavailable | Retry | | `ABDM-1034` | Notification service unavailable | Retry | | `ABDM-1035` | OTP does not matched | Unclassified | | `ABDM-1039` | Invalid Consent request id | Cannot proceed | | `ABDM-1040` | Invalid Locker ID | Fix request | | `ABDM-1041` | Invalid Acknowledgement | Fix request | | `ABDM-1046` | Invalid Purpose | Fix request | | `ABDM-1047` | Purpose does not exist | Fix request | | `ABDM-1048` | Timeout | Retry | | `ABDM-1051` | Invalid ABHA Number or ABHA Address | Fix request | | `ABDM-1054` | Invalid Subscription Request Id | Fix request | | `ABDM-1057` | Invalid Care Contexts | Fix request | | `ABDM-1058` | Invalid HI Types | Fix request | | `ABDM-1060` | Invalid Patient Reference Number | Fix request | | `ABDM-1061` | Consent artefact expired | Cannot proceed | | `ABDM-1062` | ABHA number mismatch with Link token), | Fix request | | `ABDM-1063` | HIP Id mismatch with Link token | Fix request | | `ABDM-1064` | request with this request id already exists | Fix request | | `ABDM-1065` | Health facility does not exist | Fix request | | `ABDM-1070` | Duplicate consent request | Cannot proceed | | `ABDM-1071` | User doesn't belongs to same organisation | Unclassified | | `ABDM-1072` | Included source size must be at least 1 | Unclassified | | `ABDM-1074` | HIP object cannot be null in excluded sources | Fix request | | `ABDM-1075` | HIP object cannot be null in included sources | Fix request | | `ABDM-1077` | Auto approval policy id doesn't exist. | Unclassified | | `ABDM-1078` | Failed to upload documents | Unclassified | | `ABDM-1079` | Auto approval id is already disabled | Fix request | | `ABDM-1080` | Subscription request may be already approved or denied | Fix request | | `ABDM-1081` | Please upload registration certificate of your organisation | Unclassified | | `ABDM-1082` | Please upload authority letter from your organisation | Unclassified | | `ABDM-1083` | User doesn't belongs to same organisation | Unclassified | | `ABDM-1084` | The Details fetched from Aadhaar is not matching with our database. Please select the correct details to proceed | Unclassified | | `ABDM-1085` | ABHA number mismatch with X Auth token | Fix request | | `ABDM-1099` | Invalid event Id, it cannot be null | Fix request | | `ABDM-1100` | You have requested multiple OTPs Or Exceeded maximum number of attempts for OTP match in this transaction. Please try again in 30 minutes. | Retry | | `ABDM-1112` | The provided gender does not match the gender in DigiLocker records | Unclassified | | `ABDM-1113` | Duplicate health information provider data flow response data flow resoponse | Fix request | | `ABDM-1116` | generate\_and\_save\_link\_token : 'NoneType' object has no attribute 'get' | Unclassified | | `ABDM-1117` | Auto approval id is already active | Fix request | | `ABDM-1118` | Login via ABHA Number OTP is not allowed | Fix request | | `ABDM-1119` | Login via Aadhaar OTP is not allowed | Fix request | | `ABDM-1120` | No care context is available for this patient. | Unclassified | | `ABDM-1144` | Incorrect facility ID or password. | Fix request | | `ABDM-1145` | Subscription is already disabled | Fix request | | `ABDM-1146` | Subscription is not in revoked state | Unclassified | | `ABDM-1147` | Subscription is not in granted state | Unclassified | | `ABDM-1148` | Subscription id does not belong to the patient | Unclassified | | `ABDM-1151` | Health locker is already setup for the user | Fix request | | `ABDM-1152` | Subscription not found for the locker | Fix request | | `ABDM-1153` | Unable to create Consent Auto Approval for the health locker | Cannot proceed | | `ABDM-1154` | Unable to save user health locker | Unclassified | | `ABDM-1170` | Invalid ABHA address | Fix request | | `ABDM-1401` | Your mobile number is not linked to the ABHA number. Please update your mobile number in ABHA or try to register using Aadhaar OTP | Unclassified | | `ABDM-1402` | Transaction Id is not matching with response | Unclassified | | `ABDM-1403` | As per NHA policy, you have exceeded ABHA address creation limit, please link your ABHA address to ABHA number. | Unclassified | | `ABDM-1404` | Patient record share detail not found | Fix request | | `ABDM-1405` | Invalid health information status | Fix request | | `ABDM-1406` | Invalid session status, Status should be TRANSFERRED, PARTIAL\_TRANSFERRED or FAILED | Fix request | | `ABDM-1407` | The ABHA Number associated with this ABHA Address is currently deactivated. Please reactivate it. | Cannot proceed | | `ABDM-1408` | Invalid API sequence flow, please follow logical flow | Fix request | | `ABDM-8877` | HIP did not acknowledge the HIP consent notify. Please try again after some time | Cannot proceed | | `ABDM-9999` | Invalid purpose text, it must be in Care Management, Break the Glass, Public Health, Healthcare Payment, Disease Specific Healthcare Research, Self Requested | Fix request | Every code above is recorded in the specification that owns it. The aggregated list across modules is at [error codes](/docs/hiecm/v3/reference/error-codes). [Next Still stuck? Ask for help Where to file what you hit, so the answer lands back in these pages.](/docs/support) --- # M3 consent and fetching Request patient consent, track its status, and fetch the health records a granted consent artefact covers. The full operation list is in the [M3 API reference](/reference/hiecm-m3). New to this? Start with [M3 Retrieve](/docs/hiecm/v3/milestones/m3). --- # List the specialities a facility can declare `GET /v1.5/facility/get-specialities` One of the two HFR master data calls whose path appears in text. Not run against the ABDM sandbox, so the response shape is unconfirmed. ```bash curl --request GET \ --url https://apihspsbx.abdm.gov.in/v4/int/v1.5/facility/get-specialities \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Responses - `200`: The speciality list. NHA's document carries the response as a screenshot, so the field list is not transcribed. --- # Log in to the HPR with a username and password `POST /v4/int/api/v1/auth/authPassword` One of the five HPR login routes, and the only one with a published path. Returns the `hprToken` that the HFR create call carries in its header. The password is encrypted with the ABDM public certificate before it goes in the body. Not run against the ABDM sandbox, so the request and response shapes are unconfirmed. ```bash curl --request POST \ --url https://apihspsbx.abdm.gov.in/v4/int/v4/int/api/v1/auth/authPassword \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer `. ## Responses - `200`: A token for the professional. NHA's document shows the response as a screenshot, so the field list is not transcribed. --- # M4 HPR and HFR errors Seeing a symptom rather than a code? Start at [Troubleshooting](/docs/hiecm/v3/troubleshooting/). ## Codes The ranges below, with examples. The full list is in the sandbox documentation for the healthcare professional registry. Code, message and error name are as published. The action column reads the message text by a documented rule, and says Unclassified where the rule could not classify one. | Code | Message | What to do | | ---------- | ----------------------------------------------------------------------- | -------------- | | `HIS-400` | Request is invalid. Please enter the correct data. | Fix request | | `HIS-401` | User is not authorized. | Cannot proceed | | `HIS-403` | Forbidden. | Cannot proceed | | `HIS-422` | Unable to process the current request due to wrong data. | Unclassified | | `HIS-500` | An unexpected error has occurred. Please try again in some time {0}{1}. | Retry | | `HIS-503` | Requested service is unavailable. | Retry | | `HIS-504` | Database exception occurred while processing request. | Unclassified | | `HIS-1001` | Doctor info not found for healthProfessionalId: (.\*) | Fix request | | `HIS-1002` | The field value should not be empty. | Unclassified | | `HIS-1003` | Invalid pattern found. | Fix request | | `HIS-1004` | Type mismatched. Please send the correct type. | Fix request | | `HIS-1005` | Please try logging in with the correct details. | Unclassified | | `HIS-1006` | Authentication is not initiated with provided method. | Unclassified | | `HIS-1007` | The user is disabled. | Unclassified | | `HIS-1008` | Invalid HPID/USERID. | Fix request | | `HIS-1009` | Error while connecting to UIDAI service. | Unclassified | | `HIS-1010` | Password must follow required format. | Fix request | | `HIS-1011` | Please enter valid mobile number. | Unclassified | | `HIS-1012` | Please enter valid Aadhaar number. | Unclassified | | `HIS-1013` | Incorrect OTP entered. | Fix request | | `HIS-1014` | Field contains only alphabets. | Unclassified | | `HIS-1015` | HPID already exists. | Fix request | | `HIS-1016` | HPID not available. | Unclassified | | `HIS-1018` | HPID creation allowed only for specific regions. | Unclassified | | `HIS-1019` | HP Facility ID not available. | Unclassified | | `HIS-1020` | Facility already registered with HPID. | Fix request | | `HIS-1021` | Current and new password cannot be same. | Unclassified | | `HIS-1022` | Please verify captcha. | Unclassified | | `HIS-1023` | Please wait before sending another OTP. | Unclassified | | `HIS-1024` | Invalid state. | Fix request | | `HIS-1025` | Invalid district. | Fix request | | `HIS-1026` | Transaction not found. | Fix request | | `HIS-1027` | Benefit not integrated. | Unclassified | | `HIS-1028` | Aadhaar required for KYC. | Fix request | | `HIS-1029` | HPID already linked with Aadhaar. | Fix request | | `HIS-1030` | Name mismatch with Aadhaar records. | Fix request | | `HIS-1031` | Password not set for HPID. | Unclassified | | `HIS-1032` | Integrated program not found. | Fix request | | `HIS-1033` | Authentication failed. | Unclassified | | `HIS-1034` | Invalid date format. | Fix request | | `HIS-1035` | Invalid Healthcare Professional ID. | Fix request | | `HIS-1036` | ID type and domain not configured. | Unclassified | | `HIS-1039` | Max login attempts exceeded. | Unclassified | | `HIS-1040` | File size exceeds limit. | Unclassified | | `HIS-1041` | Max OTP attempts reached. | Unclassified | | `HIS-1042` | Invalid OIDC transition. | Fix request | | `HIS-1043` | Redirect URL mismatch. | Fix request | | `HIS-1044` | Access code expired. | Fix request | | `HIS-1045` | Mobile update failed. | Unclassified | | `HIS-1046` | Same mobile number not allowed. | Fix request | | `HIS-1047` | Input must be encrypted. | Unclassified | | `HIS-1048` | Unable to fetch document details. | Unclassified | | `HIS-1054` | Invalid document type. | Fix request | | `HIS-1055` | Invalid gender code. | Fix request | | `HIS-1056` | HPID not created via driving licence. | Unclassified | | `HIS-1057` | Document details not available. | Unclassified | | `HIS-1059` | Invalid data provided. | Fix request | | `HIS-1060` | OTP expired or invalid. | Fix request | | `HIS-1061` | Invalid category ID. | Fix request | | `HIS-1062` | Invalid sub category ID. | Fix request | | `HIS-1063` | Invalid image uploaded. | Fix request | | `HIS-1064` | Invalid image size. | Fix request | | `HIS-1065` | Consent required. | Cannot proceed | | `HIS-1066` | Incorrect captcha. | Fix request | | `HIS-1067` | Invalid credentials. | Fix request | | `HIS-1068` | Mobile verification required. | Fix request | | `HIS-1069` | No HPID found for Aadhaar. | Unclassified | | `HIS-1070` | Required field is empty. | Fix request | | `HIS-1071` | Old password does not match. | Unclassified | | `HIS-1072` | Mobile number not registered. | Cannot proceed | | `HIS-1073` | New password cannot be same as old password. | Unclassified | | `HIS-1100` | Invalid Bridge ID. | Fix request | | `HIS-1101` | Bridge ID already registered. | Fix request | | `HIS-1102` | Self transfer not allowed. | Fix request | | `HIS-1103` | Facility transfer request already initiated. | Fix request | | `HIS-1104` | Linked program already in use. | Fix request | | `HIS-1105` | Operation not allowed. | Fix request | | `HIS-1106` | Required fields missing. | Fix request | | `HIS-1107` | Reassign to same manager not allowed. | Fix request | | `HIS-1108` | Invalid attempt. | Fix request | | `HIS-1109` | Professional type mismatch. | Fix request | | `HIS-1110` | Not a Central Government facility. | Unclassified | | `HIS-1111` | Not a State facility. | Unclassified | | `HIS-1112` | Not a Government facility. | Unclassified | | `HIS-1113` | Invalid facility ID format. | Fix request | | `HIS-1114` | Invalid pin code. | Fix request | | `HIS-1115` | Invalid ownership code. | Fix request | | `HIS-1116` | HPR ID required. | Fix request | | `HIS-1117` | Transaction ID required. | Fix request | | `HIS-1118` | Invalid password format. | Fix request | | `HIS-1119` | Invalid token. | Fix request | | `HIS-1120` | Invalid facility ID or name. | Fix request | | `HIS-1121` | Invalid facility details. | Fix request | | `HIS-1122` | User not government type. | Unclassified | | `HIS-1123` | Request body missing fields. | Fix request | | `HIS-1124` | Bridge not linked. | Unclassified | | `HIS-1125` | Invalid HIP name. | Fix request | | `HIS-1126` | Invalid Bridge ID. | Fix request | | `HIS-1127` | Invalid HIP ID. | Fix request | | `HIS-1128` | HIP name already exists. | Fix request | | `HIS-1129` | Invalid HIP name format. | Fix request | | `HIS-1130` | Bridge request failed. | Unclassified | | `HIS-1131` | Geolocation limit exceeded. | Unclassified | | `HIS-1132` | Duplicate facility detected. | Fix request | | `HIS-1148` | Not a government facility. | Unclassified | | `HIS-1149` | Not a private facility. | Unclassified | | `HIS-1150` | Invalid private facility. | Fix request | | `HIS-1151` | Facility ministry mismatch. | Fix request | | `HIS-1152` | Mobile number not found. | Fix request | | `HIS-1153` | PSU mismatch. | Fix request | | `HIS-2001` | Invalid Aadhaar number. | Fix request | | `HIS-2004` | OTP system error. | Unclassified | | `HIS-2022` | Invalid OTP. | Fix request | | `HIS-2031` | Request expired. | Fix request | | `HIS-2045` | Session expired. | Fix request | | `HIS-2055` | Invalid gender. | Fix request | | `HIS-2057` | Invalid category. | Fix request | | `HIS-2062` | Invalid medical council. | Fix request | | `HIS-2075` | Invalid reason of not working. | Fix request | | `HIS-2076` | Invalid work status. | Fix request | | `HIS-2081` | Invalid boolean value. | Fix request | | `HIS-2082` | Invalid reason of not working. | Fix request | | `HIS-2083` | Invalid ministry. | Fix request | | `HIS-2084` | Invalid category. | Fix request | | `HIS-2085` | Validation / verification failure. | Unclassified | | `HIS-2094` | Work status not required. | Fix request | | `HIS-2095` | Facility declaration not required. | Fix request | | `HIS-2096` | Select State Govt facility. | Unclassified | | `HIS-2097` | Select Central Govt facility. | Unclassified | | `HIS-3001` | Resident data not available. | Unclassified | | `HIS-3006` | Document mismatch. | Fix request | | `HIS-3015` | Server timeout. | Retry | | `HIS-3021` | HPRID already exists. | Fix request | | `HIS-3031` | Invalid token. | Fix request | | `HIS-4003` | Facility already exists. | Fix request | | `HIS-4015` | Invalid ownership subtype. | Fix request | | `HIS-4020` | Invalid longitude. | Fix request | | `HIS-4032` | Invalid state code. | Fix request | | `HIS-4044` | Invalid page number. | Fix request | | `HIS-4055` | Invalid image format. | Fix request | | `HIS-4061` | Facility status change not allowed. | Fix request | | `HIS-5001` | Workflow not defined. | Unclassified | | `HIS-5002` | Qualification missing. | Fix request | | `HIS-5005` | Already registered. | Fix request | | `HIS-5006` | Invalid practitioner DTO. | Fix request | | `HIS-5007` | Invalid personal DTO. | Fix request | | `HIS-5008` | Invalid academic DTO. | Fix request | | `HIS-5009` | Invalid registration DTO. | Fix request | | `HIS-5010` | Invalid work DTO. | Fix request | | `HIS-5011` | Token expired. | Fix request | ## Code ranges | Range | What it covers | Examples | | -------------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | `HIS-400 to HIS-504` | The HTTP level failures | HIS-401 user is not authorized, HIS-403 forbidden, HIS-503 requested service is unavailable | | `HIS-1xxx` | Validation and facility errors, 103 of them | HIS-1002 the field value should not be empty, HIS-1124 bridge not linked, HIS-1128 HIP name already exists, HIS-1132 duplicate facility detected | | `HIS-2xxx` | Aadhaar, OTP and session errors | HIS-2022 invalid OTP, HIS-2031 request expired, HIS-2045 session expired | | `HIS-3xxx` | Aadhaar data and HPID state | HIS-3001 resident data not available, HIS-3021 HPRID already exists, HIS-3031 invalid token | | `HIS-4xxx` | Facility record errors | HIS-4003 facility already exists, HIS-4032 invalid state code, HIS-4055 invalid image format | | `HIS-5xxx` | Registration workflow errors | HIS-5005 already registered, HIS-5011 token expired | Every code above is recorded in the specification that owns it. The aggregated list across modules is at [error codes](/docs/hiecm/v3/reference/error-codes). [Next Still stuck? Ask for help Where to file what you hit, so the answer lands back in these pages.](/docs/support) --- # M4 HPR and HFR Register a healthcare professional on the HPR, onboard a facility to the HFR, and link the facility to its bridges. ## Base URLs | Purpose | Environment | Base URL | | ----------------- | ----------- | -------------------------------------------------------- | | HPR and HFR calls | Sandbox | `https://apihspsbx.abdm.gov.in/v4/int/` | | HPR and HFR calls | Production | `https://apinhpr.abdm.gov.in/v4/int/` | | Session token | Sandbox | `https://dev.abdm.gov.in/api/hiecm/gateway/v3/sessions` | | Session token | Production | `https://live.abdm.gov.in/api/hiecm/gateway/v3/sessions` | The full operation list is in the [M4 API reference](/reference/hiecm-m4). New to this? Start with [M4 Enrol](/docs/hiecm/v3/milestones/m4). --- # M4 operations and fields Every Milestone 4 call for the [HPR](/docs/hiecm/v3/getting-started/glossary#hpr) and the [HFR](/docs/hiecm/v3/getting-started/glossary#hfr), with its parameters, its codes and the rules that apply to it. Two operations carry a published path and have their own pages under APIs. The rest are here. Where do I get the paths this page does not give? Method and path are not yet published for most calls below. Take them from the sandbox documentation, and use this page for the fields, codes and rules. ## Session token The first call you make. Same session pattern as [M1](/docs/hiecm/v3/api/m1), issued by the [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) gateway. | | | | ---------------- | -------------------------------------------------------- | | Method | `POST` | | URL | `https://dev.abdm.gov.in/api/hiecm/gateway/v3/sessions` | | URL, second host | `https://live.abdm.gov.in/api/hiecm/gateway/v3/sessions` | Both hosts are listed under [Base URLs](/docs/hiecm/v3/api/m4#base-urls). Headers: | Header | Value | | ------------ | -------------------------------------------------- | | `REQUEST-ID` | A fresh UUID for each call, for end to end tracing | | `TIMESTAMP` | The time the request was made, ISO 8601 | | `X-CM-ID` | `sbx` in sandbox, `abdm` in production | Request body: ```json { "clientId": "", "clientSecret": "", "grantType": "client_credentials"} ``` Response shape: ```json { "accessToken": "", "expiresIn": 1200, "refreshExpiresIn": 1800, "refreshToken": "", "tokenType": "bearer"} ``` Read `expiresIn` from your own response rather than hard coding a value. Every later call carries this token. The `Authorization` header value is the word `Bearer`, one space, then the access token. ## Encryption Three fields below are sent encrypted: the mobile number in mobile match, the [OTP](/docs/hiecm/v3/getting-started/glossary#otp) in the HPR mobile login, and the email and password in create HPID. All use the same public certificate, so fetch it once. | | | | -------------- | ------------------------------------------------------- | | Method | `GET` | | Sandbox URL | `https://apihspsbx.abdm.gov.in/v4/int/api/v1/auth/cert` | | Production URL | `https://apinhpr.abdm.gov.in/v4/int/api/v1/auth/cert` | The cipher is `RSA/ECB/PKCS1Padding`, under this certificate and no other. M1 uses RSA-OAEP with SHA-1 under the ABHA certificate, so an M1 encryption path reused here produces a value the NHPR cannot read. Check the response format before you parse it. Where it arrives as bare base64 rather than beginning `-----BEGIN PUBLIC KEY-----`, add the PEM armour yourself, wrapping at 64 characters per line, as the ABHA certificate call requires. ## HPID creation Nine calls, in order. Method and path are not yet published for these. | Step | Call | What it does | Detail we have | | ---- | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | | 1 | Generate Aadhaar link | Returns a `txnId` and a temporary URL for the professional to complete Aadhaar authentication on. The URL expires after 5 minutes | Behaviour only | | 2 | Check Aadhaar authentication status | Optional polling. Takes the `txnId`. Returns a bare boolean, not an object | Behaviour only | | 3 | Verify OTP and fetch user details | Takes the `txnId`. Returns demographic and address details from Aadhaar, with the mobile number masked | Behaviour only | | 4 | Check HPID exists by Aadhaar | Returns the [HPID](/docs/hiecm/v3/getting-started/glossary#hpid) already registered for this Aadhaar, if there is one | Behaviour only | | 5 | Mobile match | Checks whether the mobile number is the one on the Aadhaar record. The mobile number is encrypted. The response field is `demographicAuthViaMobile` | Behaviour only | | 6 | Generate mobile OTP | Only if `demographicAuthViaMobile` is false. Takes the mobile number and the `txnId` | Behaviour only | | 7 | Verify mobile OTP | Takes the OTP and the `txnId` | Behaviour only | | 8 | Username suggestions | Takes the `txnId`. Returns suggested HPR usernames | Behaviour only | | 9 | Create HPID | Takes the professional's details. Email and password are encrypted with the public certificate. Returns the HPID and an `hprToken` | Code tables below | ### Codes for create HPID Category: | Code | Name | | ---- | ---------- | | 1 | Doctor | | 2 | Nurse | | 6 | Pharmacist | Subcategory, as used by create HPID: | Code | Name | HPR type | | ---- | --------------------------------------------------- | ---------- | | 1 | Modern Medicine | doctor | | 2 | Dentist | doctor | | 3 | Ayurveda | doctor | | 4 | Unani | doctor | | 5 | Siddha | doctor | | 6 | Homoeopathy | doctor | | 89 | Sowa-Rigpa | doctor | | 220 | Yoga and Naturopathy | doctor | | 7 | Registered Auxiliary Nurse Midwife (RANM) | nurse | | 8 | Registered Nurse (RN) | nurse | | 9 | Registered Nurse and Registered Midwife (RN and RM) | nurse | | 10 | Registered Lady Health Visitor (RLHV) | nurse | | 33 | Pharmacist | pharmacist | Role: | Code | Name | | ---- | -------------------------------------------- | | 1 | Healthcare Professional | | 2 | Facility Manager | | 3 | Healthcare Professional and Facility Manager | The subcategory codes differ between calls Register professional and update professional use a second subcategory table, and its codes differ from the create HPID table above. | Subcategory | Code | | -------------------- | ------- | | Dentistry | 2 | | Homoeopathy | 3 | | Ayurveda | 4 | | Unani | 5 | | Siddha | 6 | | Sowa-Rigpa | 7 | | Nurse categories | 8 to 11 | | Pharmacist | 13 | | Yoga and Naturopathy | 14 | Fetch the codes from the HPRID subcategories master API rather than hard coding either table. See [HPR master data](#hpr-master-data). ## Getting an HPR token The HPR token is not the gateway access token: it represents the professional, not your client. There are three ways to get one, and all three carry the gateway access token in the `Authorization` header as well. ### Login by password One call. The professional supplies their HPR ID and password. | | | | ------ | ---------------------------------- | | Method | `POST` | | Path | `/v4/int/api/v1/auth/authPassword` | ```json { "idType": "hpr_id", "domainName": "@hpr.abdm", "hprId": "@hpr.abdm", "password": ""} ``` The `token` in the response is the HPR token. The HPR Swagger page at `https://apihspsbx.abdm.gov.in/v4/int/swagger-ui/index.html?urls.primaryName=HPR` lets you try the call in a browser. The sample `expiresIn` is `1739710198`, which reads as a Unix timestamp rather than seconds. The other two login flows return `1800`. The call has not been run, so which reading is right is unknown. ### Login by mobile OTP Four calls. | Step | Method and path | Body | | ------------------------- | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | 1. Send OTP | `POST /v4/int/api/v2/auth/loginViaMobileSendOTP` | `{ "mobile": "9999999999" }` | | 2. Get public certificate | `GET /v4/int/api/v1/auth/cert` | None | | 3. Verify OTP | Path not confirmed, see below | `{ "txnId": "", "otp": "", "mobile": "" }` | | 4. Login with HPR ID | `POST /v4/int/api/v2/auth/login/userAuthorizedToken` | `{ "hpId": "", "txnId": "" }` | The verify OTP path is not yet published: the published value repeats the send OTP path, `loginViaMobileSendOTP`. Take the verify endpoint from the HPR Swagger page. Step 1 response: ```json { "txnId": "061c660d-8752-4639-945d-e77a7ea6f564", "mobileNumber": null} ``` Step 3 response, listing the HPR IDs linked to that mobile number: ```json { "txnId": "fc6d879c-e535-4ff1-9443-5dc6031efcc1", "mobileLinkedHpIdDTO": [ { "hprIdNumber": "**-****-0326-3829", "name": "Test", "hprId": "*****@hpr.abdm" } ]} ``` Step 4 response, which is the HPR token: ```json { "token": "", "expiresIn": 1800, "refreshToken": "", "refreshExpiresIn": 10800} ``` ### Login by Aadhaar OTP Two calls. | Step | Method and path | Body | | ------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------- | | 1. Send OTP | `POST /v4/int/api/v1/auth/init` | `{ "idType": "hpr_id", "domainName": "@hpr.abdm", "authMethod": "AADHAAR_OTP", "hprId": "" }` | | 2. Verify OTP | `POST /v4/int/api/v1/auth/confirmWithAadhaarOtp` | `{ "otp": "", "txnId": "" }` | Step 1 returns `{ "txnId": "..." }`. Step 2 returns the same token object as step 4 of the mobile flow. ## Register professional The one HPR write call with a published path. | | | | ----------- | -------------------------------------------------------------------------------- | | Method | `POST` | | Sandbox URL | `https://apihspsbx.abdm.gov.in/v4/int/apis/v1/doctors/register-professional-new` | The `hprToken` from create HPID goes in the payload, not the header. The gateway access token goes in the `Authorization` header. The payload is grouped into personal information, communication address, registration data, qualification data and current work details. Selected fields and their rules: | Field | Mandatory | Notes | | --------------------------------------------- | ----------- | ------------------------------------------------------------------------------------------------- | | `hprToken` | Yes | From create HPID, or from a login call | | `healthProfessionalType` | Yes | `doctor`, `nurse` or `pharmacist`. An empty or wrong value makes the whole request invalid | | `salutation`, `firstName` | Yes | `middleName` and `lastName` are optional | | `nationality` | Yes | ID from the countries master | | `languagesSpoken` | Yes | Comma separated master codes, for example `1,5` | | `isCommunicationAddressAsPerKYC` | No | `0` means the communication address fields below become mandatory. `1` means they do not | | `category` | Yes | Category code, for example `1` for doctor | | `categoryId` | Yes | Subcategory code, for example `1` for Modern Medicine | | `registeredWithCouncil`, `registrationNumber` | Yes | Council ID comes from the councils master | | `nameOfDegreeOrDiplomaObtained` | Yes | ID from the courses master | | `college`, `university` | Yes | IDs from the master data. Send `0` for "Any Other" | | `yearOfAwardingDegreeDiploma` | Yes | `monthOfAwardingDegreeDiploma` is optional | | `currentlyWorking` | Yes | `0` or `1`. If `0`, `reasonForNotWorking` becomes mandatory | | `chooseWorkStatus` | Yes | `0` private, `1` government, `2` both | | `ministry` | Conditional | Mandatory when `chooseWorkStatus` is `1` or `2`. Values from the get all ministry master | | `isPermanentOrRenewable` | Conditional | Mandatory for a doctor. If `Renewable`, `renewableDueDate` is mandatory. Not required for a nurse | Three conditional rules apply separately: - When `chooseWorkStatus` is `1` or `2`, `category` inside `personalInformation` must be `C` for central government or `S` for state. When it is `0`, send an empty string. Mandatory either way. - When `chooseWorkStatus` is `1` or `2`, `facilityDeclarationData` is mandatory. - Without `facilityId`, then `facilityName`, `facilityAddress`, `facilityPincode`, state, district and `facilityType` are mandatory. With it, `facilityDepartment` and `facilityDesignation` are mandatory. ### Degree codes | Code | Degree | System of medicine | | ---- | ------ | ------------------ | | 4060 | MBBS | Modern Medicine | | 4074 | BDS | Dentistry | | 4079 | BAMS | Ayurvedic | | 4082 | BUMS | Unani | | 61 | BSMS | Siddha | | 74 | BTMS | Sowa-Rigpa | | 40 | BHMS | Homoeopathy | | 9568 | BPharm | Pharmacist | ### Attachments Every attachment in the payload uses the same shape: ```json { "fileType": "image/jpeg", "data": ""} ``` Accepted file types are JPEG, PNG and PDF, sent in `fileType`. Read the exact value back from your own response rather than hard coding one. ### A note on nurses The SMD ID identifies doctors only. Searching nurse colleges by SMD returns a null college or university name. That is expected, not a failure. For nurses, SMD is always null. ## The other professional calls | Call | Published parameters | Path | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | Retrieve professional document list | `hprid` | Not in text | | Upload documents | `hpr_token`, `document_id`, `document_type`, `data` (base64) | Not in text | | Update professional | The same field table as register professional, with `hprToken` from a login call | Not in text | | Fetch professional details | `id` (HPR ID, mandatory), `name` (minimum 3 letters), `contactNumber`, `state`, `registrationNumber`, `stateCouncilName` | Not in text | | Search facility from HPR | `ownershipCode`, `stateLGDCode`, `districtLGDCode`, `subdistrictLGDCode`, `pincode`, `facilityName`, `facilityId`, `page`, `resultsPerPage` | Not in text | Upload rules: profile photo 1 MB or smaller, other documents 5 MB or smaller, accepted types png, jpeg, jpg and PDF. The document types are `profilePhoto`, `degreeCertificate`, `registrationCertificate`, `proofOfWorkCertificate`, `proofOfNameChangeRegCertificate` and `proofOfNameChangeQualCertificate`. Which identifier you send as `document_id` depends on the type: | Document type | Identifier to use | | ---------------------------------- | ------------------------------ | | `profilePhoto` | Parent identifier | | `degreeCertificate` | Qualification block identifier | | `registrationCertificate` | Registration block identifier | | `proofOfWorkCertificate` | Parent identifier | | `proofOfNameChangeRegCertificate` | Registration block identifier | | `proofOfNameChangeQualCertificate` | Qualification block identifier | ## HFR onboarding Five calls, in order. Method and path are not yet published; the parameter tables are. ### 1. Deduplicate search Run this before you create anything, so you do not create a second record for a facility that already exists. | Param | Required | Notes | | ------------- | -------- | --------------------------------------------- | | `facilityId` | No | 6 digit numeric facility unique ID | | `name` | Yes | Alphanumeric, one space between words | | `address` | No | Alphanumeric plus `-_.(),/` | | `district` | Yes | District LGD code | | `subDistrict` | Yes | Sub district LGD code | | `village` | No | Village LGD code | | `geolocation` | No | Latitude and longitude, 1 to 6 decimal places | LGD codes come from the Local Government Directory at [lgdirectory.gov.in](https://lgdirectory.gov.in/), and from the LGD lookup calls below. ### 2. Basic facility information Creates the record and returns a tracking ID that acts as the facility ID for every later call. Needs an HPR token in the header, generated from an HPR ID and password. Mandatory fields: | Param | Notes | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | `facilityName` | First character must be a letter or a digit | | `ownershipCode` | `G` government, `P` private, `PP` public private | | `ownershipSubTypeCode` | `C` or `S` when ownership is `G`. `P` or `NP` when ownership is `P` or `PP` | | `ownershipSubTypeCode2` | From the ownership subtype call | | `workingInPsu`, `facPsuName` | Only when ownership is `G` and subtype is `C` | | `systemOfMedicineCode` | From master data with `type=MEDICINE`. Comma separate for several | | `facilityTypeCode`, `facilitySubType` | From the facility type and facility subtype calls | | `specialityTypeCode` | From master data with `type=SPECIALITY-TYPE` | | `facilityOperationalStatus` | From master data with `type=FACSTATUS` | | `typeOfServiceCode` | From master data with `type=TYPESERVICE`. Not required for diagnostic laboratory, imaging centre, cath laboratory, dialysis centre, blood bank or pharmacy | | `facilityAddressDetails` | Country, state, district and sub district LGD codes, address line 1, pincode, latitude and longitude | | `facilityUploads` | `facilityBoardPhoto` and `facilityBuildingPhoto`, each as a `name` and a base64 `value`, maximum 5 MB, extension in the name matching the file | | `timingsOfFacility` | `workingDays` and `openingHours`, mandatory when the facility is functional. Hours accept `10:00 AM-2:00 PM` or `24*7` | Optional fields include `facilityRegion` (`R` rural or `U` urban), the contact block, the address proof block and `abdmCompliantSoftware`. ### 3. Additional information The tracking ID plus yes or no flags, each answered with a code from master data `type=GENERAL-INFO-OPTIONS`: `hasDialysisCenter`, `hasPharmacy`, `hasBloodBank`, `hasCathLab`, `hasDiagnosticLab`, `hasImagingCenter`. With an imaging centre, `servicesByImagingCenter` carries a service code and equipment count per service. It also carries the facility's existing scheme identifiers, all optional: `nhrrId`, `nin`, `abpmjayId`, `rohiniId`, `echsId`, `cghsId`, `ceaRegistration` and `stateInsuranceSchemeId`. ### 4. Detailed information The tracking ID plus the sections that apply, which depends on the facility type, the type of service and the system of medicine. The rules: - Specialities are required for most facility types, but not for blood bank, cath laboratory, diagnostic laboratory, dialysis centre, imaging centre or pharmacy. - Medical infrastructure is mandatory for IPD and day care. For IPD at least one bed count must be greater than zero; for day care at least one day care bed count must be. - For OPD where the system of medicine is dentistry, `countDentalChairs` is mandatory. - For imaging centre, diagnostic laboratory, blood bank and pharmacy, medical infrastructure is not required. - `totalNumberOfBeds` must be equal to or greater than the sum of the individual bed counts. - The pharmacy, blood bank, diagnostic and imaging sections are each required when the facility is of that type or offers that service. ### 5. Submit facility | Param | Required | Notes | | --------------------- | -------- | ------------------------------------------------------------- | | `trackingId` | Yes | From the basic information call | | `sourceOfInformation` | No | Leave empty and the facility is treated as a submitted entity | | `sourceUniqueID` | No | The facility's ID in your own source system | Needs an `x-hpird-auth` token in the header. Until you make this call the facility stays in draft. ## Bridge linkage Links one facility to one or more bridges. Path not in text. | Param | Required | Notes | | -------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `facilityId` | Yes | Starts with `IN`, 12 characters in total | | `facilityName` | Yes | Alphanumeric plus `-_.(),/` | | `bridgeId` | Yes | Alphanumeric | | `hipName` | Yes | The name a patient sees in their [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) or [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app. 15 characters or fewer, no special characters, unique for every bridge on a facility | | `type` | Yes | `HIP` or `HIU` | | `active` | Yes | `true` or `false` | ## HFR search and master data Paths are not yet published. Two appear inside other parameter descriptions: `v1.5/facility/fetchfacilitytype` and `/v1.5/facility/get-specialities`. | Call | Parameters | Notes | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | Master types | None | A GET. Returns the list of master data set types | | Master data | `type` | The type comes from master types | | LGD states | None | A GET. Returns states with their districts nested | | LGD districts | `stateCode` | | | LGD sub districts | `districtCode` | | | Facility type | `ownershipCode`, `systemOfMedicineCode` | Ownership accepts `G` or `P` here | | Facility subtype | `facilityTypeCode` | | | Ownership subtype | `ownershipCode`, `ownerSubtypeCode` | | | Get specialities | `systemOfMedicineCode` | One system of medicine per call | | PSU details by ministry | Ministry code from ownership subtype | | | Search facility | Either `facilityId`, or `ownershipCode` with `stateLGDCode` and `facilityName`. Plus `page` (minimum 1) and `resultsPerPage` (minimum 10) | Fuzzy match on name, exact match on everything else | | Nearby search | `centerLat`, `centerLon`, `radiusInKm`, `from`, `size` are mandatory. `abdmSoftware`, `facilityOwnership`, `hospitalSpecialityType`, `speciality` and `facilityName` are optional filters | Results are ordered by distance, nearest first | | Send OTP to contact | `facilityId` | Returns a transaction ID and sends an OTP to the facility's registered mobile | | Validate OTP | `facilityId`, `sourceId`, `otp`, `source`, `transactionId` | `source` accepts `Government programs` | ## HPR master data There are 17 master data calls, in four groups: - Qualifications: system of medicine, medical councils, languages, universities, courses, colleges - Geography: countries, states, districts, sub districts - Nursing bodies: nurse affiliated boards, nurse councils, nurse college by state, affiliated board by state councils - Classification: get all ministry, HPRID categories, HPRID subcategories The only master data paths the document carries in text: | Call | Method and path | | ----------------------- | --------------------------------------------------------- | | Countries | `GET /v4/int/apis/v1/masters/countries/{country_id}` | | States | `GET /v4/int/apis/v1/masters/states/{state_id}` | | Districts | `GET /v4/int/apis/v1/masters/district/{state_id}` | | Sub districts | `GET /v4/int/apis/v1/masters/sub-districts/{district_id}` | | Languages | `GET /v4/int/apis/v1/masters/languages/{language_id}` | | Courses | `GET /v4/int/apis/v1/masters/courses` | | Nurse affiliated boards | `GET /v4/int/apis/v1/masters/affiliated-board` | Three appear as complete URLs: countries, states and nurse affiliated boards. The other four appear only as path fragments inside field descriptions, so the `/v4/int/` prefix on those is our reading of the base URL, not a quote. Path variables are optional. Drop one and you get the full list. Countries returns: ```json { "id": 356, "alpha_2_code": "IN", "alpha_3_code": "IND", "enShortName": "India", "nationality": "Indian"} ``` Two calls take parameters: | Call | Parameters | | ------------------- | ------------------------------------------------------------------- | | HPRID categories | `role`: `1` healthcare professional, `2` facility manager, `3` both | | HPRID subcategories | `role` as above, plus `categoryCode` from the categories call | A published system of medicine table carries a twelfth row, `12 Registered Pharmacist`, filed under `nurse`. Fetch the list from the master API rather than copying either table. ## Error codes There are 150 error codes, all prefixed `HIS-`, in six groups. | Range | What it covers | Examples | | ---------------------- | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | `HIS-400` to `HIS-504` | The HTTP level failures | `HIS-401` user is not authorized, `HIS-403` forbidden, `HIS-503` requested service is unavailable | | `HIS-1xxx` | Validation and facility errors, 103 of them | `HIS-1002` the field value should not be empty, `HIS-1124` bridge not linked, `HIS-1128` HIP name already exists, `HIS-1132` duplicate facility detected | | `HIS-2xxx` | Aadhaar, OTP and session errors | `HIS-2022` invalid OTP, `HIS-2031` request expired, `HIS-2045` session expired | | `HIS-3xxx` | Aadhaar data and HPID state | `HIS-3001` resident data not available, `HIS-3021` HPRID already exists, `HIS-3031` invalid token | | `HIS-4xxx` | Facility record errors | `HIS-4003` facility already exists, `HIS-4032` invalid state code, `HIS-4055` invalid image format | | `HIS-5xxx` | Registration workflow errors | `HIS-5005` already registered, `HIS-5011` token expired | The full list is in the sandbox documentation for the [healthcare professional registry](https://sandbox.abdm.gov.in/sandbox/v3/new-documentation?doc=healthcare-professional-registry). ## Where to go next - The interactive reference: [M4 API reference](/reference/hiecm-m4). - The order of calls, as diagrams: [M4 user journeys](/docs/hiecm/v3/milestones/m4). - A path missing here that you need now: ask on [support](/docs/support). --- # 01 - Get Health Records List [GET] `GET /digi-locker/records/list` Lists the health records held in the person's DigiLocker. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/digi-locker/records/list \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # 02 - Get DigiLocker Account [GET] `GET /digi-locker/account` Returns the DigiLocker account linked to the signed-in ABHA address, if one has been connected. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/digi-locker/account \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # 03 - Get Access Token / OAuth Callback [GET] `GET /digi-locker/getCode` Completes the DigiLocker OAuth flow: exchanges the authorisation code DigiLocker redirected back with for an access token. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/digi-locker/getCode \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # 04 - Get Account Status [GET] `GET /digi-locker/status` Reports whether the person's DigiLocker account is connected and ready to receive records. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/digi-locker/status \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # 05 - Upload Record [POST] `POST /digi-locker/upload` Uploads a file the person holds into their DigiLocker as a health record. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/digi-locker/upload \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "attachment": "base64_encoded_file_content_here", "fileName": "sample_report.pdf" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `attachment` (string, required) - `fileName` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 06 - Read Uploaded Record [GET] `GET /digi-locker/records/read` Returns the content of one record the person uploaded to DigiLocker. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/digi-locker/records/read \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # 07 - Fetch Incoming Records List [POST] `POST /digi-locker/incoming/records/list` Lists the records a HIP has sent to the person's DigiLocker within a date range. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/digi-locker/incoming/records/list \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "hipId": "IN0710000700", "fromDate": "2026-01-01T00:00:00.000Z", "toDate": "2026-06-17T23:59:59.000Z" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `hipId` (string, required) - `fromDate` (string, required) - `toDate` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 08 - Fetch Incoming Records Bundle [POST] `POST /digi-locker/incoming/records` Fetches the FHIR bundle for one care context that a HIP has sent to the person's DigiLocker. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/digi-locker/incoming/records \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "hipId": "IN0710000700", "careContextReference": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `hipId` (string, required) - `careContextReference` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 09 - Pull / Refresh Records [POST] `POST /digi-locker/pull/records` Asks a HIP to send the person's latest records to DigiLocker. The records arrive later; poll the refresh endpoint for them. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/digi-locker/pull/records \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "hipId": "IN0710000700" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `hipId` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 1. Get All States `GET /api/registration/phr/lgd/state` Lists every state with its LGD code, for the address section of registration. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/registration/phr/lgd/state \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # 1. Request OTP for a PHR registration `POST /api/registration/phr/request/otp` Starts ABHA address registration for a person with no ABHA number, by sending an OTP to their mobile. `loginId` is the encrypted mobile number. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/registration/phr/request/otp \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-address-enroll", "mobile-verify" ], "loginHint": "mobile-number", "loginId": "xHu0gDObXVpar+WN4yvTqpIswFtJmdbufWPlqp==", "otpSystem": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `scope` (string[], required) - `loginHint` (string, required) - `loginId` (string, required) - `otpSystem` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 1. Request OTP for an ABHA registration `POST /api/registration/abha/request/otp` Starts ABHA address registration for a person who already holds an ABHA number, by sending an OTP. `loginId` is the encrypted ABHA number or Aadhaar. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/registration/abha/request/otp \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-login", "mobile-verify" ], "loginHint": "abha-number", "loginId": "B8Vk8rrl0chMaDK5vGV3hae0/2epXDJZujwD7Rfo8Uwx==", "otpSystem": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `scope` (string[], required) - `loginHint` (string, required) - `loginId` (string, required) - `otpSystem` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 10 - Get HIP Refresh Records [GET] `GET /digi-locker/hip/pull/records` Returns the records a refresh pulled from a HIP into DigiLocker, once the pull has completed. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/digi-locker/hip/pull/records \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # 2. Get Districts by State Code `GET /api/registration/phr/lgd/district` Lists the districts of a state, keyed by LGD code, for the address section of registration. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/registration/phr/lgd/district \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # 2. Verify Aadhaar `POST /api/registration/abha/verify/aadhaar` Verifies the Aadhaar OTP for a registration transaction and records the person's consent to use Aadhaar for ABHA. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/registration/abha/verify/aadhaar \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "authData": { "authMethods": [ "aadhaar-gateway" ], "gateway": { "txnId": "" } }, "consent": { "code": "abha-enrollment", "version": "1.4" } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `authData` (object, required) - `authData.authMethods` (string[], required) - `authData.gateway` (object, required) - `authData.gateway.txnId` (string, required) - `consent` (object, required) - `consent.code` (string, required) - `consent.version` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 2. Verify OTP `POST /api/registration/phr/verify/otp` Verifies the mobile OTP for a registration transaction. `authData` carries the transaction id and the encrypted OTP. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/registration/phr/verify/otp \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-address-enroll", "mobile-verify" ], "authData": { "authMethods": [ "otp" ], "otp": { "txnId": "", "otpValue": "" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `scope` (string[], required) - `authData` (object, required) - `authData.authMethods` (string[], required) - `authData.otp` (object, required) - `authData.otp.txnId` (string, required) - `authData.otp.otpValue` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 3. PHR Address Suggestion `POST /api/registration/phr/suggestion` Suggests available ABHA addresses from the person's name and date of birth, for a mobile-based registration transaction. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/registration/phr/suggestion \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "txnId": "", "firstName": "", "lastName": "", "dayOfBirth": "14", "monthOfBirth": "10", "yearOfBirth": "1999" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `txnId` (string, required) - `firstName` (string, required) - `lastName` (string, required) - `dayOfBirth` (string, required) - `monthOfBirth` (string, required) - `yearOfBirth` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 3. Search LGD by Pin Code `GET /api/registration/phr/lgd/search` Resolves a PIN code to its state and district LGD codes, so the address can be filled from the PIN alone. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/registration/phr/lgd/search \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # 3. Verify Auth `POST /api/registration/abha/verify/auth` Verifies the OTP for a registration transaction started against an ABHA number. `authData` carries the transaction id and the encrypted OTP. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/registration/abha/verify/auth \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-address-enroll", "mobile-verify" ], "authData": { "authMethods": [ "otp" ], "otp": { "txnId": "", "otpValue": "" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `scope` (string[], required) - `authData` (object, required) - `authData.authMethods` (string[], required) - `authData.otp` (object, required) - `authData.otp.txnId` (string, required) - `authData.otp.otpValue` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 4. Check PHR Address Existence `GET /api/registration/phr/exists` Checks whether an ABHA address is already taken before the person tries to register it. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/registration/phr/exists \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # 4. Create Custom PHR Address `POST /api/registration/abha/custom/phr/create` Creates an ABHA address of the person's own choosing, once the registration transaction has been verified. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/registration/abha/custom/phr/create \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "txnId": "", "abhaAddress": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `txnId` (string, required) - `abhaAddress` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 5. Get PHR Suggestions `GET /api/registration/abha/suggestion` Suggests available ABHA addresses for the registration transaction, built from the person's verified profile. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/registration/abha/suggestion \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # 5. Register Details `POST /api/registration/phr/register/details` Completes mobile-based registration by submitting the person's profile details against the verified transaction, and creates the ABHA address. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/registration/phr/register/details \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "txnId": "", "phrDetails": { "mobile": "", "firstName": "", "middleName": "", "lastName": "", "yearOfBirth": "1999", "dayOfBirth": "14", "monthOfBirth": "10", "gender": "M", "email": "", "profilePhoto": "", "address": "
", "stateName": "Tamil Nadu", "stateCode": "33", "districtName": "Thiruvallur", "districtCode": "601", "pinCode": "", "abhaAddress": "", "password": "" } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `txnId` (string, required) - `phrDetails` (object, required) - `phrDetails.mobile` (string, required) - `phrDetails.firstName` (string, required) - `phrDetails.middleName` (string, required) - `phrDetails.lastName` (string, required) - `phrDetails.yearOfBirth` (string, required) - `phrDetails.dayOfBirth` (string, required) - `phrDetails.monthOfBirth` (string, required) - `phrDetails.gender` (string, required) - `phrDetails.email` (string, required) - `phrDetails.profilePhoto` (string, required) - `phrDetails.address` (string, required) - `phrDetails.stateName` (string, required) - `phrDetails.stateCode` (string, required) - `phrDetails.districtName` (string, required) - `phrDetails.districtCode` (string, required) - `phrDetails.pinCode` (string, required) - `phrDetails.abhaAddress` (string, required) - `phrDetails.password` (string, required) ## Responses - `200`: No response body is documented for this request. --- # assign `POST /api/family-management/assign` Links another ABHA address to the signed-in person's address under a relationship type, so the two profiles are managed as a family. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/family-management/assign \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "relatedAbhaAddress": "nithishnov@sbx", "relationshipTypeId": 2 }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `relatedAbhaAddress` (string, required) - `relationshipTypeId` (integer, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "Relationship assigned successfully", "success": true, "relationshipId": null } ``` --- # Certificate `GET /api/global/phr/public-certificate` Returns the ABDM public key and the encryption algorithm to apply with it. Fetch it before encrypting any value for the PHR application services. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/global/phr/public-certificate \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "publicKey": "", "encryptionAlgorithm": "RSA/ECB/OAEPWithSHA-1AndMGF1Padding", "abhaPublicKey": "" } ``` --- # De-Link Request `POST /login/profile/abha/de-link` Removes the link between the signed-in ABHA address and an ABHA number, against a verified transaction. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/login/profile/abha/de-link \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "action": "", "transactionId": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `action` (string, required) - `transactionId` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "", "authResult": "" } ``` --- # delink `PUT /api/family-management/delink` Removes the family link between the signed-in person's ABHA address and the related address given. ```bash curl --request PUT \ --url https://phrsbx.abdm.gov.in/api/family-management/delink \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "relatedAbhaAddress": "nithishnov@sbx" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `relatedAbhaAddress` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "Relationship delinked successfully", "success": true, "relationshipId": null } ``` --- # ENCRYPTION `POST /abha/api/v3/phr/app/enrollment/encrypt` Encrypts a value with the ABDM public key so it can be sent in the fields that only accept ciphertext, such as `loginId` and OTP values. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/abha/api/v3/phr/app/enrollment/encrypt \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "data": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `data` (string, required) ## Responses - `200`: No response body is documented for this request. --- # Get District with stateCode `GET /global/lgd/district` Lists the districts of a state with their LGD codes. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/global/lgd/district \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `403`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "districtCode": 610, "districtName": "ARIYALUR" }, { "districtCode": 730, "districtName": "CHENGALPATTU" }, "... 36 more of the same shape" ] ``` --- # Get lgd with pincode `GET /global/lgd/search` Resolves a PIN code to its state and district LGD codes. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/global/lgd/search \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `403`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ "" ] ``` --- # Get notifications `GET /notification/get-notification` Lists the notifications delivered to the signed-in ABHA address. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/notification/get-notification \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # Get PHR Card `GET /profile/phr/card` Returns the person's ABHA card as an image for display or download. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/profile/phr/card \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 --- # Get Profile `GET /profile/phr` Returns the signed-in person's ABHA profile: name, date of birth, gender and contact details. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/profile/phr \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "abhaAddress": "", "fullName": "Hemant Bodhai", "firstName": "", "middleName": "", "lastName": "", "dayOfBirth": "14", "monthOfBirth": "11", "yearOfBirth": "1995", "dateOfBirth": "14-11-1995", "gender": "M", "email": "", "mobile": "", "abhaNumber": "", "address": "
", "stateName": "Maharashtra", "districtName": "Nashik", "pinCode": "", "stateCode": "27", "districtCode": "123", "authMethods": [ "MOBILE_OTP", "PASSWORD", "... 1 more of the same shape" ], "status": "ACTIVE", "emailVerified": "true", "mobileVerified": "true", "kycStatus": "VERIFIED", "abhaLinkedCount": "3" } ``` --- # Get QR Code `GET /profile/phr/qr-code` Returns the QR code that encodes the person's ABHA address, for scanning at a facility. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/profile/phr/qr-code \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 --- # Get Relationship Types `GET /api/family-management/get-relationship-types` Lists the relationship types an address can be assigned under, each with the id `assign` takes. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/family-management/get-relationship-types \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "id": 3, "typeName": "Self" }, { "id": 6, "typeName": "Father" }, "... 13 more of the same shape" ] ``` --- # Get States `GET /global/lgd/state` Lists every state with its LGD code. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/global/lgd/state \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `403`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "stateCode": 35, "stateName": "ANDAMAN AND NICOBAR ISLANDS" }, { "stateCode": 28, "stateName": "ANDHRA PRADESH" }, "... 34 more of the same shape" ] ``` --- # getProvidersByID `GET /global/providers/000` Returns one provider's registry entry: its identifier, facility type, whether it is registered in the HIP role, and whether it supports scan and pay. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/global/providers/000 \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `403`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "identifier": { "name": "", "id": "37913" }, "facilityType": [ "HIP", "HIU" ], "isHIP": true, "isPaymentShare": true, "scanPayVersion": "V3" } ``` --- # IsKycVerified `POST /login/phr/isKycVerified` Reports whether the ABHA address given has completed KYC verification. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/login/phr/isKycVerified \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "abhaAddress": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `abhaAddress` (string, required) ## Responses - `200`: No response body is documented for this request. --- # Link Request `POST /profile/phr/link` Links an ABHA number to the signed-in ABHA address, against a verified transaction. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/profile/phr/link \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "action": "", "transactionId": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `action` (string, required) - `transactionId` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "", "authResult": "" } ``` --- # linked-by-me `GET /api/family-management/linked-by-me` Lists the ABHA addresses the signed-in person has linked to their own as family members. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/family-management/linked-by-me \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `202`: Example values, scrubbed. See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 202 response, generated from the schema. The values are placeholders, not a captured response: ```json { "linkedUsers": "array", "linkedUsersFromOtherAccount": "array" } ``` --- # linked-to-me `GET /api/family-management/linked-to-me` Lists the ABHA addresses that have linked the signed-in person's address as a family member. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/family-management/linked-to-me \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `202`: Example values, scrubbed. See The callback never arrives: /docs/hiecm/v3/troubleshooting/callback-never-arrives - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 202 response, generated from the schema. The values are placeholders, not a captured response: ```json "array" ``` --- # Login OTP Verify - AADHAR `POST /login/phr/verify` Verifies the login OTP. On success the response carries the accounts linked to the identifier and a token for each, or a transaction to pick one with. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/login/phr/verify \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "" ], "authData": { "authMethods": [ "" ], "otp": { "txnId": "", "otpValue": "" }, "face": { "txnId": "", "faceAuthPid": "" }, "password": { "abhaAddress": "", "password": "" }, "face_login": { "aadhaar": "", "faceAuthPid": "" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `scope` (string[], required) - `authData` (object, required) - `authData.authMethods` (string[], required) - `authData.otp` (object) - `authData.otp.txnId` (string, required) - `authData.otp.otpValue` (string, required) - `authData.face` (object) - `authData.face.txnId` (string, required) - `authData.face.faceAuthPid` (string, required) - `authData.password` (object) - `authData.password.abhaAddress` (string, required) - `authData.password.password` (string, required) - `authData.face_login` (object) - `authData.face_login.aadhaar` (string, required) - `authData.face_login.faceAuthPid` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "message": "", "authResult": "", "users": [ { "abhaAddress": "", "fullName": "", "abhaNumber": "", "status": "", "kycStatus": "", "profilePhoto": "" } ], "accounts": [ { "mobile": "", "firstName": "", "middleName": "", "lastName": "", "name": "", "yearOfBirth": "", "dayOfBirth": "", "monthOfBirth": "", "gender": "", "email": "", "profilePhoto": "", "status": "", "stateCode": "", "districtCode": "", "subDistrictCode": "", "villageCode": "", "townCode": "", "wardCode": "", "pincode": "", "address": "
", "kycPhoto": "", "stateName": "", "districtName": "", "subdistrictName": "", "villageName": "", "townName": "", "wardName": "", "authMethods": [ "" ], "kycVerified": false, "verificationStatus": "", "verificationType": "", "emailVerified": "", "ABHANumber": "", "preferredAbhaAddress": "" } ], "tokens": { "token": "", "expiresIn": 0, "refreshToken": "", "refreshExpiresIn": "", "switchProfileEnabled": false }, "preferredAbhaAddress": "" } ``` --- # Logout `GET /profile/phr/request/logout` Ends the session and invalidates its tokens. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/profile/phr/request/logout \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "You have been logged out", "timestamp": "2023-07-27 13:36:28" } ``` --- # OTP Request - AADHAR OTP `POST /login/phr/request/otp` Starts a login by sending an OTP. `loginHint` names what the person is identifying with, and `loginId` is that value encrypted. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/login/phr/request/otp \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "" ], "loginHint": "", "loginId": "", "otpSystem": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `scope` (string[], required) - `loginHint` (string, required) - `loginId` (string, required) - `otpSystem` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "message": "" } ``` --- # reassign `PUT /api/family-management/reassign` Moves an existing family link to a different relationship type without delinking and assigning again. ```bash curl --request PUT \ --url https://phrsbx.abdm.gov.in/api/family-management/reassign \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "Relationship type changed successfully", "success": true } ``` --- # Refresh Token `GET /profile/phr/request/token` Exchanges a refresh token for a new access token, so the session continues without signing in again. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/profile/phr/request/token \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "tokens": { "token": "", "expiresIn": 1800, "refreshToken": "", "refreshExpiresIn": 1296000 } } ``` --- # Search Auth Methods - ABHAAddress `POST /login/phr/search` Returns the authentication methods available for an ABHA address, so the login can offer only the ones that will work. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/login/phr/search \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "abhaAddress": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `abhaAddress` (string, required) ## Responses - `200`: No response body is documented for this request. --- # Send AADHAAR Otp - Link-DeLink `POST /login/profile/request/otp` Sends an Aadhaar OTP to authorise linking or delinking an ABHA number with the signed-in address. `loginId` is the encrypted Aadhaar. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/login/profile/request/otp \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "" ], "loginHint": "", "loginId": "", "otpSystem": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `scope` (string[], required) - `loginHint` (string, required) - `loginId` (string, required) - `otpSystem` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "message": "OTP is sent to Aadhaar registered mobile number ending with *******2425" } ``` --- # Send ABHA Otp - Link-DeLink `POST /api/login/profile/request/otp` Sends an OTP to the ABHA number's registered contact to authorise linking or delinking an ABHA address. `loginId` is encrypted. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/login/profile/request/otp \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-login", "mobile-verify" ], "loginHint": "abha-number", "loginId": "Dl3zAX8xvneRfB2KKkEt3KTTVs1PK7LXSMODQsu3VWnksnnHLmNJDtD2yuLZnRvrjySf79n3LFLjedxFF6f5PELEts2yNYo+oL80cjS+Zw1ODyrc/ziHiJAlCzhN6XM2FxlfVQc/VeF9MdXCMrEq5AY6b3xj1VxiWcCmN/pyUk/VtxABvCMYGswq6/cEBc3jI90/srM02BwuavWj5H9sudMGfs1q4sIx0b9l05COEOjq+R4v+OArf2ohsedmTBR/dL9ZZqS5/pSSyD/6TJ3UvvmC2tRNEDwHYwH7mWnzJii+3sj00rLjPwPOSSxfkX07NCS5LTDCJ4hjJt5AVUyqv/kRBJ+hLvfo/HXtaCbebyYVfYd3QE3AGIat/ZO6pecjH+cx+ZJNKmULS8HigaiVav+3Plbe6tomfJyRVFhQIsWAk6wt/EqOKzKrzvs2MpMdpfNfaNscU24PdPSO3XpohmHkekJbwzLsVLmzLZfBlqluCPN49MxLfU/6lyntaz5XenmM1q06Ut3dCgWaQWe5fTm+mKRYftHGXNjCgmh5EOmNmBWzWjRBCREE1mSelUXtpR0dK9MUykA30tTs1LWL/h7myy/oqovTTfsYkkIvWpGTCqnWPclgELrExaDrbmpyLmqEo+KCw5m8vPiksp2f8vWo9Xj+8S3HmCGCBxldrwA=", "otpSystem": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `scope` (string[], required) - `loginHint` (string, required) - `loginId` (string, required) - `otpSystem` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "message": "OTP sent to mobile number ending with ******6282" } ``` --- # Send ABHA OTP `POST /profile/phr/request/otp` Sends an OTP to the contact registered on the signed-in ABHA address, to authorise a profile change. `loginId` is encrypted. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/profile/phr/request/otp \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "" ], "loginHint": "", "loginId": "", "otpSystem": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `scope` (string[], required) - `loginHint` (string, required) - `loginId` (string, required) - `otpSystem` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "message": "" } ``` --- # Session API `POST /api/hiecm/gateway/v3/sessions` Issues a gateway session token from a client id and secret. The token is the bearer credential for calls on the gateway host. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/hiecm/gateway/v3/sessions \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "clientId": "", "clientSecret": "", "grantType": "client_credentials" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `clientId` (string, required) - `clientSecret` (string, required) - `grantType` (string, required) ## Responses - `200`: No response body is documented for this request. --- # Session-Token `POST /api/global/get/session` Issues the access token every PHR application call carries as a bearer token, with its refresh token and both expiry windows. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/global/get/session \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `403`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "accessToken": "", "expiresIn": 1200, "refreshExpiresIn": 1800, "refreshToken": "", "tokenType": "" } ``` --- # Set the preferred ABHA address `POST /profile/phr/set-preferred/abha-address` Marks one of the person's ABHA addresses as the preferred one, against a verified transaction. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/profile/phr/set-preferred/abha-address \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "transactionId": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `transactionId` (string, required) ## Responses - `200`: No response body is documented for this request. --- # Switch Profile `GET /profile/phr/switch-profile` Lists the other accounts the signed-in person can switch to and opens a transaction for the switch. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/profile/phr/switch-profile \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "users": [ { "abhaAddress": "", "fullName": "manish", "status": "ACTIVE", "kycStatus": "PENDING" }, { "abhaAddress": "", "fullName": "test", "status": "ACTIVE", "kycStatus": "PENDING" }, "... 70 more of the same shape" ], "tokens": { "token": "", "expiresIn": 300, "refreshToken": null, "refreshExpiresIn": null } } ``` --- # unassign `PUT /api/family-management/unassign` Ends the family relationship with the related ABHA address given, on the signed-in person's side. ```bash curl --request PUT \ --url https://phrsbx.abdm.gov.in/api/family-management/unassign \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "relatedAbhaAddress": "nithishnov@sbx" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `relatedAbhaAddress` (string, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "Relationship unassigned successfully", "success": true } ``` --- # Update mobile request OTP `POST /profile/abha/request/otp` Sends an OTP to a new mobile number so it can replace the one on the signed-in ABHA address. `loginId` is the encrypted new number. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/profile/abha/request/otp \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "txnId": "", "scope": [ "abha-profile", "mobile-verify" ], "loginHint": "mobile", "loginId": "", "otpSystem": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `txnId` (string, required) - `scope` (string[], required) - `loginHint` (string, required) - `loginId` (string, required) - `otpSystem` (string, required) ## Responses - `200`: No response body is documented for this request. --- # Update mobile verify OTP `POST /abha/api/v3/phr/app/login/profile/abha/verify` Verifies the OTP sent for a mobile number update on an ABHA address. `authData` carries the transaction id and the encrypted OTP. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/abha/api/v3/phr/app/login/profile/abha/verify \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "abha-profile", "mobile-verify" ], "authData": { "authMethods": [ "otp" ], "otp": { "txnId": "", "otpValue": "" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `scope` (string[], required) - `authData` (object, required) - `authData.authMethods` (string[], required) - `authData.otp` (object, required) - `authData.otp.txnId` (string, required) - `authData.otp.otpValue` (string, required) ## Responses - `200`: No response body is documented for this request. --- # Update Profile `POST /profile/phr/update` Updates the signed-in person's profile fields: name, date of birth, gender, contact details and photo. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/profile/phr/update \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "profilePhoto": "/9j/4QBqRXhpZgAATU0AKgAAAAgABAEAAAQAAAABAAAEsAEBAAQAAAABAAADhIdpAAQAAAABAAAAPgESAAMAAAABAAEAAAAAAAAAAZIIAAQAAAABAAAAAAAAAAAAAQESAAMAAAABAAEAAAAAAAD/4AAQSkZJRgABAQEAyADIAAD/2wBDABsSFBcUERsXFhceHBsgKEIrKCUlKFE6PTBCYFVlZF9VXVtqeJmBanGQc1tdhbWGkJ6jq62rZ4C8ybqmx5moq6T/2wBDARweHigjKE4rK06kbl1upKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKT/wAARCAOEBLADASIAAhEBAxEB/8QAGwAAAgMBAQEAAAAAAAAAAAAAAQIAAwQFBgf/xABIEAABAwIFAQYDBwIFAwMDAgcBAAIRAyEEEjFBUWEFEyJxgZEyUqEUI0KxwdHwYuEGM3KS8RVTgiQ0Q0RjorLSFjVUwiVz4v/EABkBAQEBAQEBAAAAAAAAAAAAAAABAgMEBf/EACQRAQEBAQADAAMAAgMBAQAAAAABEQISITEDQVETIgQyYVJx/9oADAMBAAIRAxEAPwDO+r3rQ2tE7OVT2Fp5CJAIggQfYotljQJJjYrKq1FYWBwzMPoq9LFVEUUUQRRRRUREFBRASOEAYUBRsfNAwMopNEwKgZFKighAhKQnUhUUOaqyFoc1VlqClzZVRBBhaCEjmyoKkESIMFRRQUUUQRRRRBFFFEAUUUQRRRRURFBFBFbRbYu9FUtFAA0xOygsa0au9uUxMnoECTGyAJBmUUxAjqlI6okyhbcIB+aN91LQpdBNAi26BHVTRARwoQIQkFQC07IDtEoOUmLogoEmOqMnexRPRTVBBG5UMShEGxRKCI/ClGqKCeiEo7zKkboBbcqZZFoUPkiLIhYLRCAHRPdQiNCgqLA6+h6KotI1WggjWyWATceaooUTvp5Ta4/JIoIooogCiiiCKKKIIooogiCKiAIqKKgt1VgVbdVYFBY1MUrUyAFKUyVyCzDi7kmMqMpkAgkkWsrMP+JZcd48Yxo4A+qotfk+10qeWXAC6Vj6bq1Z4bGUGTyowz2m4n8I/RU0TGFxD+YCIsa6kMK92QhrnAQhUNMYak0tPiJICSt4cFRbyS5PUbmxVCl8rRKCxwpuxdOnBzMAv9UtF9M1K1YAgAGT5paTpr4mqfwgwqx4MA4/9x8eiC6k2l9nOzXu3MaLTSaGU2gCAAslRn3mGoxoJPqtdZwbTJJjZKKG+JxcdytLR4VRRa53wsJHJsFeaZjxvk8N0WasK8gN5WYq+rAsqTqrClRHCLGOeYA9VspUmsFrnlVFVLDF16lhwtTWtaIa0AKKxtJxvoEUo80wYSeArA0DQeqKgUNaNp6lMpCPRFLHSEdFDKiCIxIQARQQKRCg1RKBUYlRRBIU3RHmgUBlQ3QR1UAjqiEIRVBhDdQSiihChtdFSyCASojPCAREhTdGJQjlQGAgpKKqgjsoNEFBIUjhFRAEVFAgkKQDqjPRCSgkBKRFwmhSERzcW2K5I3EqpaMd/nD/AErOqIoojCIiigUQRSFFEEUURQNtNr+ykHT6ceSE7/X9wj0j0/ZBBrIMHkfqicr7OEHY7FDW9/PdToYg+xQK9hZrpylVoJFiC4bg6hB1IEZqZkcJphEFEVUBRRRURRRRA0zqhEIJgVBAeUyWFAYQOjKWeEUBSOamR1QUOakIWghVOaqKSAVWRGqvISOaCoKkEzgQUFFBRRRBFFEEEUUUQRRRRURRRRBFrw/+SPNZFpwxzUiOCoLLzupZG17KCN0UNuig8kc0GENEE6ooBGwNkEIKARKHVBIGxU0URQSQp6KQhfQoIeqGuiKM2jRAoupeUfVBBJ6I26hSPVQoJopJ9ECofdARfVQzsVJEaIC+iAjhQ67qTAUnRBIslLSmk9VNpBRC+khU1KeXxDT8lfHW6ERYiZsgyqJntLHQlQRRRRBFFEEERQUQFBRRURFBRAzdVYFW1WBQWNTFK1EoAgUSgUF2H+E+ayVfF2m0cELXRnL6rO0T2g0nXxE+5CoWmfvsVU4a5V/D2f8A6qilIkYXEO+YgI1Gzh8NT+Yk+5QHEN++w9LhoBTtM4+q/ZgJ9kPj7Tvo39Aq6ZPcYiru63uiAw5cDUdu9wCeo2W4aiNxJ9UtQHuMPS+a/urQQ7tBzvw02/kEDM+8x9R2zRCurn4QPNVYEE03POrincM1byspVW0WnUp36pqbbJKu6is1Qy49EKVM1LmwTNbnPRaGt2CqCxoaAAICtZTLhaw5T06Qjx+ytkbIFaxrdJ800QNVEZjQIoIqC+yiAalGFApqgiBRUhAAipqpZBLKTAU3upF0EhE7KKBAIKkQmKkFQKj7qGyhugiKgUVEUU3UhFQnhRTRTZBNQoFFFEFBQyoEUVEOqiA6qQgigiljoopugiMoaqICohJRPmgiNkFAEHPxxnEkcBZ1ZiXZsQ89YVaqIigoiCopKEoCooogiiiiBy0tMmT1Gv8AdC0bR9P7JaOJbU8L4a4+xVlVjqRMgg8wgEX3ke4U26c7eqQF0NkDqJ/Ioy7xfQxceYQNG0eQ39FAYOYGDz+6HikREHVux8ih4iD4jIOsXHmN0DkNqWd4X7HlVuBaYIRc3N8UFp22J6HYpqZcAW1PvG//AJD90CKJ3U4GZhzN/JJqqgKIqIAoiggMphfRKogImbJgZSN8NgLJgUBRlBRAUCFJRQVOaqyFeQkIQUOE2KqcC03WkhI4TYhBUWENk+yVW1CCAeiqKioooggiiiiCKKKKiKIIoIrMO/JVE6OsVWog3EFBJQq52wT4m/VWbqKmykSYUjqp5IDZA3UlCyCGVPNQweVLeiCIJkDOqCDSyh4U10UQBGB5KHqp+SApSQjKg90EBjyUknVRCUEPkiD5IeakIIj1shI4RKAHzU8lAjF9CgA6o76+iXUlEeSAqG5iLhCJUsDI18kCV2yzNwVnWqvei4rIiCogogiiiCAqIIoIogoqCogpKB2aqwKtmpVgUFjUVGolApSlPCXlBfQ/ywslOrmxFV8fCx0e62UrUh5LnYf/ACMQ7+kD3VE+Hs//AFVFcWzi8PT+VoVT2n7Ph2DVxKtn/wBdVf8AIw/kiK6LpqYmqflMeqUiMEwDV75QZ4cFUd8zg39VaWTUwtLgZkDETj2N2ptH0Cqpu+4xFU6vOUeqLXXxNbpA9UC3/wBPQpRd7sxQbcO3JQYNLSUKRBdOpOwTvMMPWybDtjRSqt8QZs0fVZ6pl2UepWjEO7un10Cz0aZeYFyVIp6TCYDRJWynSFPq7lGkwUmwNdyn1uFQLqWKnVSUBHRBSVNUB9VFD7qRKA6IIIhBNFFFLoIoop5oIVEdkEEJRAQlFBJUChU0QRRRRQRRRTSyAypsgjCqpNlFIU1UEUNkEQgigUUlAZgIbaKIwgCKF1EBUhTRQoCNFOqmyEoJ5o6qKbIILbpatQUqbnnYWTi652Pr53920+FuvUojMTNyogoqgyjKVSUBlFKSpKB1EoKhKBpUlLKkoMa1YbF92Q2vmqU4gCbt8lRUpPpnxCRyNCkQdTIx7c9J2en+XmEmWOT+YWCnUfSdmpuLSuhhsVh64yV/uqmzh8J/ZAvJt149QjF7TO3Ppyrq2HfSd4hHDhuqSCLECPp/ZAbO1hpPsUCC0wQenPoVNbGf1/uiDAgwWnb9kABI8QMddj5piG1Dplf+aETdpJjXkefKFjaBfQbHyUCuBaYIhBWBxIc14zAbxcJXMIGZviarphVFFFURRRRAYUURhRpAUUFAUQVJUUVRECLKI6oKyEhCtISEIKnNnVUlpaY1B0K0kJHNkIKFEzhafdKooKIoIIoooqIgoogiiiiAglpBBghaqVUVBBs7jlZFEG8yFBpIVFPEWy1PdXC9x9FFERCkDZTzUQA2UCm0ao20AQS0aoE2hEgofWEE80bbaITCG+iAmd1ICiA80Eg8IqKBAERbhCL3RMAfqgGqOUqaKaoBfRTa6OhQFzJlABrZGDKm6gk6IIBF0T7IEReQpc6oJwpodVPZQG97oFrn7g9SFklacSC5gAIF1n7t3IRqcW+wUlHu3cqd27kJq/46EqSjkdyFO7dyE0/x0JUlHuj8w91O6PzD3TT/AB0JUlHuz8zfdTuz8zfdNP8AHQlSUe7PzNU7s/O1NP8AHRp6lWtVbG5T8QM8K1qMWZ6WN0RKDUUQFIHCKGyC4f5OseFYm0g3D1Wh4guAlaq5LcK8ixDVhe4nBMBMlz5ViLzSmphhmHhAtKjWEnEOzNlw14kqSBjydqbP0VExgTy56Cx1D/01JgcLuJN9Vb3Z+1veCPC3wj0VeUHFUKfyNE/mqw7/ANPXqbvfH6oG7l4wZaNXPk32CtFInFs+VjIH89VXlBrYals1uY/mrsI7vDUqREmAgtqbBaaDYErPrU0Jha2NdlkkAcBZrUZcS7vK+UaNH1WujSyM/qOsLPhWZ6z6h0DrLbJVE9VOiimyCSPNS02Cm2qiCKaqKdUBU1KCPmgEHlQa3Rm6EIGOiCiiAqKKIAojNlEARQUlAdlEEVBEUFEEUhQSigCIUCiKk3U1UUQQBSyikIDCCOiCCIqC2qnRBNVIUUMoIjCCkIJKMeqkKIIopBKy47GjDDIwZqn5ISaOMxIpN7th8Z34XOhVHEvcSTTkneUO/d/2/qi+HS0gqQVX37v+39VO/d/2/qqeHSy6DzALjoEnfn/t/VCpVL2FvdkTvKHh0qe95tNui0tu0EcLMZJ0VraxawDuyYGso1eLi66l1X35/wC0fdTv3f8AaPujHhT3Uuk74690VO/P/aKL4VqOkESDqCs1XDb0v9v7LXCUhRlzuhsVFuq0m1R4rHZwWOrSfS+ISNiNFUWUcZXpG1QuadWuMgrdQezFCGENfE5T+65SZri0gtJBGhBQdJzC0xEdCkn33t+arZjy4BuIGaPxDX1C0ANqtzUzmHTZQJNwRY7X/JGQ74rHmLHzCBBE8HW35qDbnbn+6AmWm89P7KAxdpjrsfNQGBtHXT+yhF5bM7jf+6KJaHmwyv45VRBaYIgp+kW429E0giHeIDfcK6ipRO+i9rQ8CWHRwSaqocaKIDRFZaRBFRAJRQKgVQUEUCqIgQooiEcEhCtKUhBVl16qlzSPJaQLpCNUFCCdzY8kiioooogCiKCoiiiiCKKKICpTe5lwd9EEG/CEGtlZjrO8JVqwJ2VHs+F1uFBsUmFQ3ENPxNg8hWtIddplFNPVS0Sl0KMlBDdQlAFEoIohMI+SAeaKnsggkXRJtCEIygDfUomFP5ZC6CCdipG5MKKA+iCDkIxZA+iLddkEnooQNlDCAcgGyI66BSwBOnJKz1aubwts380ArPzvtoLBIoomL5WJJUkoKJh50ZUkoKJh5dDJQlRRMPKopdRRMPKoooimHlTMFp6q1qRnwBO1Gd1a1FAIoAoioBcIFxxjCuHMBZYlmFZySfqtGO8WHI4MqponEYdvDAVUCfHin8DL7pXtmhh6e7iSfdKD/wClquP43gfqrso+10WnRjBKAZv/AFGIqfK0gfkkLfuKFPd7pKUH/wBNVfu94H6q4WxbBFqTL+yCZvv8RVizW5R56K/CNyYdg5usYn7N1qvXQAgADYQgei2XTytT/DThVUYaJJARrPkaQOqy0bCtDaA5N1boko/5bPJOqCb6KEoBTZAQOVNUNUUERBS2RQFRCVEE1KKkwoTwglyohcKboCooogikKKboDZAC5RUFgigigioiKIRuiioVFIRQRRRRBFFAogKEoxdBBFN0VEE2UAUUCAxuooogEIwVFDdBFISVKrKQl5jgblYq+JfVkDws45RF9fGBpLaYk7ulY8zSfhJ/8kqiLOrPh8zfkP8AuUzM+Q/7kiiq/wCTo+ZnyH3KmZnyfUpUFD/J0fM35D7lHM35fSUiip/k6EObcuaZOsaBMHsgDu/qkQUP8lWd4z/t/VHvGfJ9VUoh/kqzvG/J9VO8b/2/qqkVV/yVdCCaEIUYKQgdCCJB1CaEIQZauG3pf7SsxkEgiCNQV0SEtSm2oIcL7EahVGBPSqPpPD6bi0hSrRdSubt5CSUHVpYuhihFWKNb5vwu/ZLWpvpOh0ATM6grmLRh8Y+iMjh3lP5Tt5INPive50O/90fWBoOnkdkjsRhdGtqRrpulOKoX+7cZ16oq0ibudcDxW18whHwjMeRe/od1V9rpzIok2jVT7Y0AAYcW6ojThaww7y4Br6dQw5p09OCnxFLDuJdh6gB3YRCxHG8UAOboHHVNRTaPRFWh4DsjhldsDumWWpiX1BlcGx/pRo4g/DUM9YQalEAbTqFFAUFJUQRFBRVEIQKKhCAIFQhTeBqqgAalVkK90Nbl3VRCCshUubHktBCQhBQomc2LjRKoqIIqKgKKKIIooogiDfhCKDfhCAooKICoJBkGCoogsbWeNfEOqsGIZHiBH1WdRQa21GOsHNM9U0HhYIRBLdCR5Irb1U2WQV6g/FPmFfQc6oCTkEHckShPazbVEKsVQXlpEEdZUFZo59lGvGrCepQgcpO+p7u+infUjbOPYqpZh+uqIjSEneM1zhDvGA/EERZ5oE9EnfU+fYIGuzYFBYTdT0VJrmIDQPNIarzvHkg0nK0S4gKp1do+ESqFEBc9z/iPogooiIgoogiiiiCKKKIIoooqIooogiKiiCynen5FO1JQ+ItOhVgEGCoLG6IoDRFBAmGoQRbqEFGPflY1kfECPqFW4gYqoR+Cnb2VmLZnrUriJ0m+qQs8WIOdsmwM6XVRVlnD0WfO8p3O++xL+G5f0Ttpk1MOMwhrZiUndO+z1DmEudcz6oFDZZh2fM7MUS8xianPhCtFNwrtIj7unA9v7qvuHfZ2N+Z8n8kDMb95h6fytzH1WsXMKik0/aKryIGgWmkJKlGmhTAvqeSqq5JJWkQ1nBWHEvDjkGm6kVowjw+iORZXrl4ar3VbMbNdr0XT6i6pEi8KBEqBFTRSeVEN0BRKAU6IJoj5aJUZQRH1QRQRT0lTRCUDIaKXUjrKAhRREBBIsoFOigQTZS+wUUUVBMoqCyiCaC6hlTVSEEUURQRBFRBAoopKCKaqKICpCEKQUERSvc2mJe4BZqmO2pN9SiNTnNaMziAOqyVcaZikP/IrM976hl7iT1QhBHEuJc4knkqKKKoiiiigiiiiCKKKIIooggiiiiCKKKKqiBUKiDUlKcoQoEhCExQQKlKeEECFUVcMDenY/KtBQKo55BBgiCNiotr6baghw9dwstSi6nfVvKIRRRRAVEFEB6/qpf8AhUU9vZBL9fdT3Q9vZS3SEF9KpFi7KeTofNaJI+JpHlcLBbQxKenWfT+FwjgmyDZnaNTHmp3jD+Ie6rp4oOMPa0HkK+R8oQLI5CkpiWn8P1QhnyoBKmYCxKMM+VSWj8P1QC7rNBHUo2pi13KFxPQdEIQL1U1RIQVQCEhCsQcNkFJCqc2LjRaCEhCChRM9kXGiVFBRRRBFFFEEQb8I8kUG/CEBUQUQFFKSlLyNkFiirNSAIvyi2oHGIgoGKCZKUAVtJri2QSNfVVqBzm6Ej1QNm8ZI5lWO0BGiom6tpmRCxXp462FISEXlWEJSElO+dgBMkBunWnnRRRRBFFFEEUUUQRBFBERRRRBFFEEBUQUQFRRRURRRRBEUEUDMWkDO2R8Q1WditYSDI1UFjUURD9LO+hQILTDgQgITNsUkjlTO0fiHugDqbn12vnwjaVV9lf3Lm2lzpN1bmHzD3Uzj5h7qhXUXd65w0yZWpPsx7umyLAkuVucfMPdTODo76oit1Goe+IaZfp5Ju4cKlMhhhjbeafMeVJQLQYWMId8RN5Wqi1xOuVUBwB0lWsqVH+Gk0z0Uqr8Q9lJuUXcdf7rn1SQYOpuVpfS7q7jLvyWJ5l5SFSVpwmL7uGVLt2PCyqQqjtg7i45Ci5NHE1KFh4m/KV0KOIZXbLZBmIKjS5SJvKVRA11EJCA5QMpbRCbIAoGUlBSYQNqFNEoMpggkopQigPqihNkUEU9VFEUYQARhRQDTRG6h0U4QRRGUIQFSFFLoIpZQKIIpHVQkASYA5KqfiqLN8x/pQW72U0WN+NcfgaB5qh9R7/jcSiNz8TSZ+LMeiz1MZUcIaA0fVZ1EEJJMkknqoooiIooogiiiiCKKKIIooogiiiioiCiiCKSogiopKiCCKKIIjcUCmIQUUpCUhOUCgQoJkCgQhApylIQKUEyCDPVw4Pip2PCzXBgiDwVvSvY2oIcPXcKoxqJ6lF1O/wATeQq0BUQUQNKl9LoKIJfqp6lRT9EE/mitp1yyAZLfJU9VP5qg6DXBwkGQjKwsqOpmQR1BNlpp1W1LaO4RVsoKKeqCIygp6ogpSE0qIF0QRIQVQCEhCsQIQVEKp7YuFeQlIQZ1E727hIiogiggh0Kg0CB0PkjsgiiiiCIOaCEUUFJY4JmMIdJCsOo80U1EhQhGVFFIUExCCAItMFBRGublW63SkKNMhEhYeqe4rcN0wuoRKULcefvnKdRRBGBUUUQRBRRASCADygpwoiIooggiiiiCSooogiiiiAn4RYIKKKgohBQILGK1qqYrWqBwna5wtMjgpAmCBvCdW+xQhvBUCMIJI4PupI4PuoogEjj6qen1RUQD0CgE7BFEBAzWDcSttEBreFmpC61mG04KlGDGVIJ5WFXVy6q9zhpMDyCQU3fwLUQqITBjuEch4QIQraI/9NU/1j9UhYVZRj7NVg/iCBmYmowROYcFXsxjTZwLT7hY1FFdJr2u+FwPkmmFzAnbVqN0efW6DfKma8FZBiX7gFN9pbaWkeSDX6qKkYinyiKzD+Ie6KtCiXODoQfVGbIHaikBTahAw80d0sJgEBUU8ygXNGrh7qKiKQ1aQH+Y33SnE0B+OfQoLRoos5xtIaNeUhxx/DT9yiNd1PJYXYyqdMrfIJHV6rtajvSyo6JIaJcQB1VbsTRafjB6Bc43Mkyooa2OxrfwsJ8zCqdi6rrAhvkFQoqC5znGXOJPVRRRERRRRBFFFEEUUUUEUUUQRRRRBFFFEEUQRVAUUQQFCVFEElBRRBJUlBFAFFEEHRKBTFBRSoFMQhCBUCmIQVCEJVYQlIQIUCE5CUhQIgmIuggCpqUGuuzwnjYq5RUYHAtMOEFRbHtDhDhIWepQc27fEPqERWogogMqSoggPT9VJ8vdSVJ6qgoSdiVEPRBppV5OV/oVoXO/misp1nU7HxN44UGxRK17XiW3RQGUUqMoCUCFJUQKVExSlVAISEJ5QN0FZVbm7hXEJSgoUTubuEiKDtCoo74SogiiiiCIoKIIdR5pkp1CKAqKKKCJSEyhugRRRRBAYKsBlVJ2lSx3/H1+hISuEGU+yUhSN987EBUSg3TLTzIooogiiiiCcKInZBERBRRBFFFEEUQRQRRRRUQnTooobeyiCIhBEILGaq1qpYrmqBwmCUJggZRGEEEURhRAFEVEATtSgKxoQXUBfhLjHEup0Guyh8lx3gaq2kIEmypxDhmeQB8oPQa/WyDMbk2jpwiAiAmAQABEhRzmM+JwHmq3YqkLDM7yCAVnZGHnZEs7miyl+I+J/mVnNcl7XZQcpmDoVHVqj3Fxdc3NkFsKR0VEv+Z3uhE63VGi3RSR8w91ny9FMvRBolvzD3R8JI8Q91my9FMvRBqiTZHKeCsmXomD3gQHuA81BohTTRZxVqD8U+acVzu0HyQX5ncn3Rzv+Z3uqhWpnWR5hWCHCQQR0QHO/wCZ3uhmd8x90YQhANdVEUEEUURQBFRRBFFFEERUUQRSFFEEUUUQRRRRAZQRQQFBFRAFFFFBFFFEEUQUQRRRRBFFFFQFFFEAUUUQRBFRAFFEUHRURhCFFKUE6UhApCEJihCBUExSwqFIQITQgQoEISqwhKQgSEE8IFAiiJCCoqfRa+/wu5Wd7HMMOHqtqUwRBEjgojEorqlA6079FT0VEQRUQCVJUtPVSBwgllFICmUcIC1xY6WmFqpVm1LaO4WPKFMo6oOgos9OuRAffqrwZ0UDKSgogMoIKIAQhKZKQqJqlIUmEUQhSObNxqrSECEGd2hRVjwMrjF4VR10RUUUQQFRCVJQHhFLN1JQMillK4mLILFFQHkSnY8kwUwOQlTJSFAFBYqIKrLlWtKhSNKsNwsV6ubsVutdEGVHCQkaYK1HDuZViiCKMIooogh2UtGnqpwoiIgiggiiiiCKIKIIigoqCdUETqUEBRCCKB2K4KmmrQoHCsCrCsCBlFFEEUUUQRRRRAWhWsF1W1X0mSZNkDvd3VNzyJgW6rNUIYAHEDLYnSTv9UMVjmiGYe5Bu7ULCc1Q5nkuPVBe/FNHwNzdSqXVqr/xEDgWRFIlXU8LUebNKozNb0TBkrq4fsiu+CWEBb6XYTR8bkHnRSnZWCg46NK9TT7Kw7NRKuGGw1L8LR5lB5NuDqu0YfZWN7Oru/AV6g1sLS+X0CR3aOHboSUHAb2RiXfgKf8A6NiPlXZPalIfh+qH/Vafy/VT0OP/ANFxHypXdj4gfgK7P/VafyfVEdrUd2n0T0e3n39m12/gKpdhKrTdh9l6gdp4Y6kjzCduJwlUfEw+dk9DyRw7hq0pTRPC9j9nw1USGNI5CrqdmYd+ghB5E0ylDS0yCQei9LW7GBnIQufiOy6tO+UoMFOqZyv91bCR9EtMEKxrYYJQAhKnKQoIogogKiCKCIoKSgKiCKCKKKIIooooIooogiKCiCKKIKgqIKKAqIIoIgiggiiiiCKKKIIgioqBCBRUQBTZGFEAhRFSEHSKCKiigUEUEASpigUClAhMQggVApoQIQIUsJyEIQKUpTlAhBWQgnISkIFQTIFAqR7Gv1F+U6Coy1KTmX1HISLboqalEG7LHjZEUKKEFpgiCoqIooggKF1FEBTMquYbXHCRQoNrKjXiQUywglpkarRSrB1nWKguUUUQRAlRCEAIQRc8MHJVJeSqi0vA1Sl4VRkoILHuzNgfVRwDlVJRlFBwgwgnkHW6BZu2/RAiiiiAboobqIDKKVRBC0FM1oGiHCKBkCFFEClRMUqABWNMhVotKldfx9Z6WFVPEGVadEjhKkb7mxGmyKraU6rgZRBREH9kFP2UQRRBFBFEFEEUUUQRFuo80EVQFFFEERQRQWU9FaFVT09VaEDtVjVU1XNUBhSEVEAhSEVEAhEBFFqB2NWbGYgkmjTMNHxHnottIS4LBh8O6tUgAkkoK6dIu0C6OE7Lq1vwwF1sB2Uyk0Oqi/C6Jcyiy8NCo5+H7HpUwC+5W1tKhQHwtb1Ky4jHkWZYcrn1sU5xkmfNTTHWq4+jTE3KzV+1CwwAAfyXGNbNULyZZTEngnYLO6o5xJJJJumrjq1e1KjvxFZX4153WLMgSoNLsS47qs1TyqZUlUXd4eVO8PKplSUF3eHlTvDyqZRlBaKh5TNqkbqmVC7L7qDbSxLmmxK3UO0qgiXSOq4ffAG7XeiZuIE2Dgg9ZQxrKkB1jzstJAIuJXlaGJcXCLBegwFY1KcHZWVLC4rAUqzSWthy4dal3RynZeoXnO169NuJeJ04SwjC5ISqnYmnyfZIcRT5KC8lSVn79nKYV6XzILpRVQxFL51PtFH5wgtRVX2ij84U7+l/3AgtRVXf0v8AuBTv6XzhBZKir7+l84U76l84QWIqrvqXzhTv6Z0ePdBahKTvqfzj3SmtT2ePdBbKkqrvWfOPdAVGn8QQXSpKrDm/MPdHM35h7oHlRLLfmHupmb8w90DKJczfmHujmHI91AZUQtyPdS3IQFRD1RQRRSEFVFRC6hKAoJcwQzIh5USypKBlEJUQdRRRRRQQTIIFQhMggUoFMUIQKUExQQKlTkIQgUhKU5QIRCFKQnIQIRSQlITlAhBWgmIQQKgmQhAjgHCHCQqH0i0yLtWkoFUY1E+IAFUgCBA/JVqoKiEqSiCNUFAb+ikoqKKKILqVYiztOVpBBEhYUzKjqZsbcKDake/J5oNqhzZnRUPcXGSgDnEqApUQqhpUiVGiStNCgXkABS1ZGbKgQuoez3xOUrJVw7mGC0pKuMqgJCZzYKRVDkZ/P81WQiDCZ3iE77oK90E0XQhAEVEEB4RQ4RCIiKCKKKBCKBQKhMFE2SkoataZChSMcrFmvRzditwgyiCi4SlbZVy7mUyiiirCKKKKCKIKIIoogghMJ2UatS7RA5STC6tN4DRkjLFlRibgqhIl8eis+wuabPnrC1947kqd46ZzO900xhOBq7P9wqKjH0nQ8RwV1e9cPxH1MqquO/plrgJ2PVNMc4FEJAmBRF7LNHunCrGjfIKwIp2q5iparmaKB1EEUEUQUQFO1IFY1BfQb4gul2Pgm0qQquHiOi5+HjMNgu7g3B2HZG1ikFlV4pUy47LgYzHOe8+JdrG03VMO4N11XmMTSe1xBSkJUqudqSVUTKR0t0S94dxKKtNQ92GAAAHN5lKk7wbyFM7fmRDoFLmb8w90cw5HugKiGYcj3QL2j8Q90DKJO8Z830QNVvBKCxFU99w33KBq1DoQPIINHmldVYBEyeizwXfESfMpmsJ0CAl+Y2aBbzTMBlXUMHVqkANK7OC7EcIdVt5oMWCwlSq4QCvSYXDjD0g3fdRrKOFp7NHJ1Kx4rtMNBFO3VPh9X47GNoMLQfH+S81iC2o8kiSeqtxGIdUJJMrK5yKQ0qZ/D9Sqq9FgpOc0EEX1VxKqxFQspEjU2RGZrS4S1pKvo0Bkmo0yTyqqL6gbla6B5LRSeXMl2sqon2enwfcqfZ6fX3TypKik+z0+vuoMPT6+6eUZQJ3FPhTuKfH0CeVJQJ9np/wD9kDhqfX2H7KyVJTRV9np8fRT7NT4VqiaKfsrFPsrFdKkoMWIpCm8AGxEqvIdgT6LTjCMrBHilAV3TLabY4haQwwjS0EuIMXU+xs+Y+yuY/O0OyxOyaVlVH2NvzH2Q+xt2f8AT+60SpKDP9kHz/T+6n2QfN9P7rRKEq6KPsg+Yex/dD7IPmHsf3WmVJUGb7H/AFj2Kn2Q/OFplAlNGb7KfnU+yu/7gWlBNGb7M/5/qp9nqn/5PqtKKujBVa+m7KXyfNLmcPxH3V+My5265ouo11ERFI25KIehSecr3VDGsLQkpvD2ggQE8qKKiEqSg6pURUUUEEyEIAgiogVBMggVApiggUoJigUCkIFMgUQqUhMgUCEIQnKCKQhKQrISkIEISkKwhKQgQoFOQhCDHW/zXearT1f81/8AqKVaZBRFBBB+iCbYoIIooogKHqp1UQb+zeza+ODjTAawWLnaLs0v8O4Zt6tR9Q9LBL/hvG0nYX7KSG1GkkD5guyuXXVlbkYG9jdntv3E+bj+6uHZ2CH/ANNT9lphSFjyrWRmPZ2C/wD6ZnoFKeBwtJ+anSDT5laFE2riwMpPHwhZcZgaNdsA5T5K4BRa82fF5/E9h4m5p5H9A6D9VzMRgcVh71aD2jmLe69oiCk7Ly8AVGuIK9piezcHiZ7yg0OP4m2K4+M/w7UZL8K/vB8jrH+63O5WbHEIh3RKrX03McWVGlrm2IIuFW4ELbJVEUEEUUUQFRRRAVFFEAKVMQgVQL6q1plIy4TgFSxvjrKhSkXVkFKVI33ZhUVN1FXFOFEdghFkAlRFBBEPRFBBD5K2jiDSGUiW/kqlIQbBi6f9Q9EftTIJkxposUIx4D5pi61fa2CYLr2MbpXYsAeFpnqs0KQmGgAmCCKIuZdg/psnCqpOynkHUK4jLcXB0KB2q9vwrOxXjRRTKIIqoiiCIUUQrGpAmkASTA6oLqZi5MBbcJj+7qZfcLm1H93SNQiPlB3WRlUgzN0Hs6VenVHhcJ4VGKwFPEAmIcvPYfGOZuuhR7Wc0QTPmmmM+L7JrMJLWyFzqmEqs1YV6Sn2tTPxD2KuGJwlX4ovyEHkHUiNQkNM8L2Bw2BqfL7pD2Zg3aR7oPHuYQhlXrX9iYZ2joSf9Aof9w+yo8rlUyL1Q7Bw41emHY+Db8VQe4QeV7s8IimTsvVjs/s9urm/7ke77MpfKUHlm4ao7RpK00ey8RVMCmV6D7fgaXwUxPkFXU7baPgYPUoMeH7AqG9Qhq6NLsjC0fE8z52WCr21VcIBjyWKrj6j9XEqD0JxOEww8GWf6QsWI7ZNwyGj6rhuruOpVRfKDoVca58y6fMrM6rOpWcuSkphq4vHISlw5HuqiggtzdQs+LdIa31TqirerHCqLKQhpKup2YFU21PzTQgtlSVVCkIq2VJVMIwmC5BVQpATBbKMqmFEwXKSqpPJ91JPJUwWyiqZPJ91MxAJJNuqCmu7NXPAsnbZnUqpgJMnUq8i4A2VRcBAAGwRlUy7k+6knk+6KtlSVVJ5Kku5KgulSVTmdyVMzuUFsqSqszuUc7ufogtlRVZ3c/RTO7n6ILJUlV53c/RTO5BZKkqvO7oiHGdkGfEHNXPSyn4Us5nk8lOBJAVRpZ4WNHATSq854Cmc8BRVkqApM54CneHgIO4gUUEVFFFFAEEVEAQRQQBApkpQBKUyEKhYQKZKUQqBRKCgCCBQlFFRCVEAKCKCAEJYToboMFX/ADX/AOopE9W1V/8AqKVaZBRFBARoUEdj5oIAoiodEE2KWQhsgqLGOLXAtkEbhdfBf4gr0YbiG983mYcuLf8AgUUslWXHs8P2vgsRpVFN3FS39luFxIuF8/BW7A4itSYTTqPYZ2K538f8a8ns0IXnaXbGLZq5r/8AU39lqp9umPvMOCeWuhZ8Kvk7Ci5ze28KfjZUb6Aph21gDrWI82FTxq63wjCxt7UwDv8A6lo8wQmPamAAk4pnpKmU1qUWB3bXZ7f/AJyfJh/ZZq3+I8Mz/KpVKh6+EK+NNWf4gwtKrgn4ggNqU4h3InReWnY3WvtHtXEY/wALyG0wZDG6LBK68yye2KYt3F0C0i8GFA4hMfHvdaQiiB1RCIKiiiAqKKKgoESiogjRFkyARlAZ6IHyUlGUCxdRFRBNghsjsFNkAQhMgoFU3TQl3QRRRRAUSPux1J/RKiT4QOpVAUUUQRBRRA7Cr6byLQC06grMxXMUGhrWn4XR0d+6syv2DT/5KlqhJgoq+Dvl91CHfMxSOg9lI8lUCHf9xnt/dET8zfZRFtiT0UDNB3PsE7RcEC/JSt0TeaDPjaklrJPJWcGEKr89RzuTZCUFgemDyqZRlFXiqeU4xDhoSs0qShrYMW/5im+2P5WGVMyYa2nGPP4ioMZUH4isWZTMmGtv2x/zFKcU/wCYrJKkqYa1HFP+Yqs1nHdUyhKuC01DyhnPKrUQOXIEpVEBlCVFERFFFEAURQQQLOPFUJ6rSl7tsyBCA/KOFEd5UQBFRGECqJoRAQLCkJwFIU1SQpBT5UYTQkKJoUhNCQkrGKccmFdCWpTDwNiNEFNIXVo3KDaZbumywIVQFEYQQRBFAoIigigCiKiAKIqIIooogiDjDSeiKDm5mkTEoKGK1o8SjaUfi+iZrYKAqIqKKCiKiDvwgsTMRUZ+KRwbq5uKYfiaW9RcLOtYuRUaWvEtId5KKoCCKiBVEUEAQITIIFKCZSECEJSrCEpCoqKUq0hVkIEKVMQgoBKkqEIICooogCg1ChLRq4D1QD2SPG3XlVGCpeq88uKVEgkmyEHgqoiikHhRBPw+qCb8I8z+iVBEDoUVDofJAn4UE34UqoiKiiCcrVhP8s+ayjda6Falkymm1ruZMKC1RK5xBgtASlzunsimqHwnyWZp34Vpc7kewW7DdjYnFtFQBtGm4SC7fyClI5ZclJK9Ez/DVMf5mJcejWq0f4cwm9Wr9P2U8o1leYkpZJXqT/hzB/8Acq+4/ZI7/DWGPw1qg8wCr5Q8a8yovQVP8Mj/AOPE/wC5v91nqf4cxbLsfTf0Bj802JlcdEGFrrdk46j8WHeerfF+SyOY5hIc0gjYqofKH+aWIMFBhIMqypqCNwiFURUQBFRRURFBFBFFEUEUURRcRRRRMMqbBDZNaFICuL40qibKEcg6ph40iB1Vndjkqd2NZKYeNVQgru66/RA0XchTKZVSZ3ws8j+aJov2E+qDmPES024TEykUUNtVEREEUEDMVzFUzRXMCgtalcbFHZI74SorYNFFB8I8lFpERGhUR2KAquu/LScdzZMs2KdLg3i6goRQRQRRRRAZUQRQRRRRBFFFEEUUUQRFRRBFEUYQLCMIgJw1BXllENVzaZKtbRJ2QZchRyHhbhQ6IGjGyDCWHhDKtbqUKsshBRlQhXFqXKgrhSE8KQoEhEBNlTBqapIUDhEz7hWFhMCJkH9EuGBLiGguPA/5U1cAGxNyBqYNk7AXiWtJ8grgwE3aZ9P/ANyYYdzj4WVJ8/8A/tTVxSWOABLXAHSRqltMbhXvw9SmwuNN4EXJ0/8A1qhoMP00+fr/AKlYlQthxBsRqEcqtp05IJg+HYz+qd1NQZsqBarixKWoKSFFaQlLVdRUVITkJYVClBPCBCoWFEYUhRCoowpCoCkqQVIQRQKKICogioIoooioooogiiikEkACSdAEGyFEZB0KkLm6ACQZEg8q5mKqNsSHDqqVIQxsbiabtZYeuisF7ggjkLnItcWmWktPRXUx0FFlbi3ADM0O5MxKtZXpv/FlPDldZxYgmQVAKCKiAIEIoFAsJS1OggqLEharyEC1BQQlV5akLUFazVHPLjeADotZas9Wk4EuAkFUUZSdwpk6ooohch5QyHlPKiaFynlDKeE6iaEy2uECwcQrFE0Ulg5QLDFir7cBAtBV0Z3NIFxskg/wLVk6pHM5Caij+aIKxzNwlyiJlULsU7dAhsbpm6BBZTqllj4m8K5uV4lhv8p1CzIiQZBghRVxgrt9m9tMZSZQxIIDRlDwJt1XDbVzWqCf6gmLd2kEdFLNWV7KlWpV25qVRrx0KeF4prnMIcxxaRoQtdHtXGUrCuXD+rxfmseLXk9TCkLg0+368eKgx8cSCr6X+IaDh95Re0/0mf2U8auuvCkLnt7cwbte8aOS3+6cdtdnH/6kDzY79kymtqSrRpVhFWmx4/qbKzf9Y7O//qm/7T+yU9s9nD/6kf7XfsmU1nxX+HsLVBNAmi73C4OOwdbA1RTrt1+Fw0K79X/EOCYSG95U6hsD6rh9q9qv7RcwFgZTZMCZPut87+2bjJCiRriFYCCtMAoioqIooogKgk2AlNTbndHutAAAgCEb5igUnnWB5phR5d7K1RVvCCi0bko90zj6plEUAxg2Ryt+UKIoBA+UeymUfKEVEAyjhQMbwjKiAZAplHJRUV0DL1UynlMomhS0kXEhIaVM6tHpZWqJqZGZ2GH4XEeaqdRe3aRyFugIZVPSXmMbFexF9IG+h5QaIMFSxizDxZI5roiJVoV2HtWaRFp1ErKFa4ZRY+yYHofZbO8qf9x/+4qZ3/O7/crpjLBjQ+ygDjoxxB3AWrO46ud7pHuIaSTPmmmM0rFUM1HHqthOUFx0bdYv3REUUUQRRFRAEVFEEUURQBFRRBFEVIQRRGFIQQBNCgCYBBGtlXMYgxq00mTsgNKjK1Mo9EaNNa2MUVSKAhI+j0W3LZI9qDm1KXRZ3shdKoxZnsVGBzUpatLmXVZaoKC1CFcQlhAmVOxqICupslZqwGU5qN6An6hTs2O8cS9ptu4H8yVrpMGYeR/RVdnF5L/C7Tdzv3Km+msbmVAPkPq390xrD5G+7f8A9yUB5Pwu/wB7kxa7dp/3H9lzaZsS8Gk6GAHoW/oVzSCc8tOnzH911sQwmkQQfr+yxihDKjspJNrtP/7VrlKSkJcYtYfmVY5qNIE1XG+jdo56BM8K6jOQlIVpCQhVFTmpCFcQlIVRSQhlVpaoGKinIiKRK0tpTsr6dAcJqMQoqGjC6fcCNEjqATVxzTThKWrc+nCqcyNlUZS1AtKvLEMqCnKhlVpagWoK4QhWZUMqIQhCE5CEIAooiilIWrs1hfXcAJdFuizq/A4n7LXzFuZrhBjVAJRD3BVypK5ui4VOQmsdCqJUlBdCCQOI3TCpygKCNipCAte+n8LiOmyuZiz+Ns9Qs6iqNzKtN/wuE8FPC5sJ2VqjLBxgbG4V1MbkCqWYoGz2+rVc17H/AAuB6bqpgIQmKEIAooigUhKQnQKCshIQrSlIQUuptf8AE2VU7DNPwuI+q0kIRr5Kjm5x5Ihw5VaiuJq2VJVSknlMNWypKrzHlTOeimGrJUVec8I5zwmB0ZVecoZymB3Aa6Kr0RJJ1UVA9AoioiAoiogCenUdTJLYvqCJBSqIH7wF0lgjgFHvKe1N3+/+yrURThzJnK4Rw7+yL3tdBDSHb31VaKAVHnKAFVK9Pg/8PUH0m1MRVc8uAIDLAeq3M7G7PZphwfNxKmxXitVF7kdm4Ef/AEtL/ao7s3AnXC0/ZTyg8KovbP7H7PeL4Zo8iR+qpf8A4fwD/wANRvk5PKGPHotMFelqf4YpH/KxLm9HNlYa/wDhzG0wSzJVH9Jv9VdiY5molRO+hWw7yytTcw8OEJVUBFRRUFri0yFoa4O014WdRGpcakFUKjhqZ804eDrZG51DKIAg6FFVpFFEEBUQRQRFBRAVEEUEUUUQRFBFBFFFEBVT4a8eSY1Gt3vwFAS4ypWOqLVfh/8AMJ6KprRGgV2H1cYUYi9FLKkqNGVdWSABunlVVHS6OESqMVallHOvKyBacUbNCzjQKsooiogCiKiAIqKIIoiogCKiKCKKIoIEYUTAIIE7Qg0K1oQPSbotlNogKikFpYitNIBaGwqGCytBUFsqt10S6yQlBW8WVDwtDlU4IMr2qpzVqcFU5qDMWpS1XuakLVFI1qvpBIArWBZqxa2x9Dp6JOzaeTMTTLZ4ab//AIhMBLi0iQQj2dQbDs1PL07sf/tCz+mm4dAf9rv2RBdsD/tP/wC1QUKXyj/YP2TCgyLNH+wLAoxOd9LKWyJ3BP8A/aVhNEinU+6Zcj8Hn/Qt2LY1tMZgyJ3aFkYymabwG03S4AQBrB6LpzPRRoUoqvGUN8LbARz0CZ9NX0mQ8nfK2fqi5qiMLmKpzYW17FS5iqMpCWFc5qXKtBA1O1iYBO3REMxgWhgAVTVa3zUDGFW+5VlkhIuiqHhVOYVoN0pCqMrmFJkK0ualLVRmLOQlLVoISlqIohAhXFolI5qoqISkK0hKQgrhCE5UQIoiggWXDcHzRD+WkfVRRTF0wcDoQUZVZAOoQgjRxUxdXBSVXmcNpUFQbyPNMXVoKYOVYdOhRlQWB6MgquVEVYoqgSDqnD+QoCp9VAQUUDtxFRu8jh11c3Esd8QLfqFlQhXUx0GkOu0g+RUXPBIMj3VrcS9uvi81dTGsoFVtxFN2stKtsRIII6KoQpSnISlAqUizvIpkHfC7/SfyVRyVEVFUBSEVEAUhFRAIUhRFAIUhFRAIUhFRAIQTKIAoiogCiKiAKIqIAoiog24LtXFYNuRjw5nyuEgLrUP8RUXWrUXs6tMrziiZF16+l2tgaulcNPDgQtFPE4eqYp16TjwHgrxMqSs+K695BUheF7xw0cR6phiKo0qPH/knia9wQhoJNgvEfaK3/df/ALikL3O1JPqnia9Zj8b2f3LmYh9OqPkb4jP6LyB1siSgtSYlBFRRERFRRURFRRAQUwclUQPnRzKtRF2rZCirlMHJq+VNKkjkISl3KavnVkjkKSOVWiE08zooBOE086WVE2VTKU1PKkJPASkk6lW5UC1RLaoFMTIV7YGpSwoqizO3lFtXIIEeyqQUF/2g8j2Q+0O5HsqUENaPtDuR7Je9GpklUqII9xe6Skb8I8k0XQA8I8kARhFRAFFFEEURUQBFRFAEVEUARURhBAmAUAThBGhXNCRoVrRCC2kLrQ1VUwrmBFXMJVoVbArmhBAFC1MAmhTRSWpHNWghIWpoyuaqnBa3NVL2oM7gqyFe4KshSqSE7AhCsYFmqPdCpILQ5pEEEq2lhWsbDKTGjo4osCvYFFK3DwIDWgcZymbQIMhjPV5P6K0JgoKHUS4QabfSoR+ijaIYwtDDB/8AuEn3K0QgU0VNbFspFokmUHBWpSEFDmql7FqIVbgqMjmqstWl7VU4KoqAThAqBBYCmBVYlMEQ8lA6KCUSqpQOihCZQoEISlqcoIipzUharykIQZy1IQtDmqtwVFJCQhWlqQhVFZCVWEJYQIpCKBQIooogiiiiCBBEb+SiBco1iD0U8Y0dPmioioKhHxN9QmbUabTfhKgQDqAfNTIatmyALouWTxdVZY+EkeqOZw1APkmLq1pJ1bHqiCQqhUG9vNNKzYurQ/lHMCqpRlFWoQlaU0oIoHFplpIPRSyiItbiXj4gHeasGIpuFyW+YWUoFNMbbG4II5CSp/l1P9B/JZAS0yCQeic135HNMOlpH0VlZsY1E2TTKZnbdI4gD+y2yKiAIMAapzTIJEixhAqiJBDQ4xB0UymBydk0BREAk7eavGEe5uZr6Z8igzqK0YeoZgC2t0opVDENmTGqBFFY6jUa1riyztLhJldwUAURII1CmVxMBp9kAUVgo1SJFN59EppvGrHDzaUCqJix41Y4ebShlPB9kAURhCyCKIqIAoiogiikIwgCCaFIQKpCcBHKgrhSFbkUydEFUIwrMiGVAkKQmyqQqAoihCCKIwpCAKIqIAioiggUG/mooN/NAUQgEwUFjQrAxLTgrQ1llBVlhSArSwpC0hAuUIFqeFIQVFqQhaCEjmqimEIVhagQqK4UhNCkIFQTIIAoNAobAqKCKKKIAoiogiiiKAKIqIIpCKiCQiAoigITiEo1TtCB2q1hCraArqbUFtPyWhnkVUxq0Maoqxp6Kxp6JWhWAKKIPQpggEyBSEpCcoFBU4KpwWghVuCDK9qqcFqcFS4IKoTtSxdO0KC1iuaRyqgnasNLQUwPRIEwU0PmRlKiEESlMUCgQhI4KwpHKipwVLwtDgqnhWIzkIaKxyRUSUwKSYUkqiyVJSiUYRBCOqgCYBFJCEKzKgQiKyEpVhCUhBWQkIVhCQqiohI4KwpCgrISFWFIQiEKCYhAqipRFBBFFFEEGp8lIRA/JGEAhHKmATAIKi2EqvLVW4IEURKCCQlyja3kmUQCXDcHzUzncH0RUUxdMx0hPKlEeE+atWcaVZkZ6q0KcoqqeqllbupA4CClB1mk9CrnAZTYJGgFwmImUSs2IpljmDQhg90hM/GJ67rXjBJDhBG8GVmhbc0azu3l3xZZgdQgS4uDL+f5lWakjYz+SltT/SfPlFV5g6pP4GDTyTtl2phz7k/KEa9AsyuaPA8T5dFXe8jXWEDkggQIb+FvPVWseQJpugHRUhhcSJg7SmAcNfC7SCLFQXMqOhzyLixCIBzECyVp0zDURHKte25y6GyB2mXOYRLQA09FWWtyyJjZXUHZWPcRJcbqogMLi1wLDqJuEFTmNcSWx1CtYA1snUj9EgYxw8LgT0RqOaWlo+IgR7qBqDqjDJcSDsU1dpewPa3wagzdQuBDgNhAT0Zu0nwxBHBQPn7xozMeQRwCqq7JILWuHMhW4Zwa0sNspt5JqrRWpOa0w4iyoxlu5I90mad9LJGsyVn2iFLupzpmFvMIA8zrccINMdW8o/EyfQoNYS6GkA8HQqixuQwHtEHcKw4ekGlzXH2lVNljsrmlvQ7rTTbmZZpy6HhQVta1tQtcwGNbKNp03NL4tm+hWz7LAFQb2cmp0QM7HSYvJ3CmrjCylSJMsNhyUraLc4zA5dTddGnQIzHL4PK58kRhZl7rGNzYKauMLGUTIdTLY3zFAMaXQGkDzV2Io5Wtc3xNk3UpUnPEgQN3GwV1MI3DCo2aZcDOllPslQTOa3ABW5lKiBl/zCTqlbRokDLTc47xKauMIom4JcD1aqiAAJJH/j/ddJ9GCSGAAbkqo0znNjl1smpjIaYie8b0lpU7mSAHtcTsAtQZT3ztjlqrIpOswuJ6hXTGRwif1RdTLSRIMawVprUWkCAQDoSqGNMZXCBJgdVdRV5+aZrC4wLniVc9gdHBv6BBlMltQxYUzPmU0UQdIMzCEjlHO42eMwjXceqHdWlhkTobFXUEAkEgWGqORwIBaZOiYOFNjWnbxO6nYKNqQHVTqLN8ypoWDmyxfhO2k50wWcwXgFCnIaAPjfp0CpcwVcYKbXWdAzR0V0Xik+YGQ+T2/umFGpwP9wU/6X/9/wD/AA/uj/0o6CsP9qbFyrGUK2zfqFop06/yH3Cx/wDSqn/db7I/9Jrf9yn9VNhldAMqgS6mY5hK51IGH1GNPBcFh/6TXNs9L3P7KDsnEgZRUpwTMZj+ynpcrYe5OlWmf/IJfu9qjD/5BZx2NidO8pf7j+yYdiYo/wDyUf8Acf2V2JlXeD5m+6Ba0/iHus9fsbFUaZqF1IgG8OP7LI7C1hs33T0ZXRNMcj3SOprlkOa4gi4Qk8fVVHSLEC0rneiLHuY6RY7EbKjcWngoEHhCj/1DEMz0n1XNmJ7yL+6c0e0xqatv/uf3U0xW4HK62yiqFfEd93dSo8wTILpXcrU6DBmFKnGVxHh8oQchRbq2Fz1CKTB4QBGmYrK6nlEEeLfomitBM1hc4AXV1FtEACrTLiDchxTRnUXVZhMJUYHMYSD/AFH90KvZ9K3dsMb+Mpo5ii0twzC10ggtIGp3/wCCmbhqZAlp0LtTp/JU0ZEYWoYZkTB6380ThmAAXzGIv0TYMoTAK1tFrnGxABg3VgoMvd0JopATgK0U6Ux3hHmE4w7olozjkOH7JoRgC0MCVtMtPip1B/5D9lppMpnU1h5gfspqjTCuaE7KLHHwPqR6fsrO5DY8b/p+yz5RQaE4CIpjao/yMT+Sfuf63fT9ldCCEwhHuv8A7jvUD9kMnD3RzlCnlADCBT90Zg1D7Imi7/uf/iqikpHBWuY8TLx/tS928iz2nyb/AHTYrO4KpwV9RlRomWkT8v8AdVtY54kOEf6Df6psGci6ZoVvcuMkvaI1OT+6lKkXtMPE/Lk/upbBAE7UA0AfH/8Ah/dFpB3P+3+6xa0sCYIBpmAWkzGm6hzDTIfUrOhwmCT735Wf7j+yOWrlnLTj/Wf2V2BigoG1SPhZ/vP7Kd3U+Vn+/wDsmhSkIVpY8aho/wDL+yBo1Pl+qqaocFW5XupvFi0j1CrqNLdWm/UK6M7gqyrXE/I73H7pAypUkMpOJAnVv7rQrKgTuw9cCTRd7j91BTqASabo9P3TQAE7QoGOBgsdI8lY1p+V3sqgAJwEQ08O9iiG9Hf7SpqgQlLVblcdGu/2lAtcNWP/ANhQUlqrcFeQflf/ALCq3Do7/aVRSQqnBXuiJv7FUucz5gqiopSmJB0IKUgjUIhSEhCYkcj3Skjke6BSlITEjkIKilRFRAFEVEEAsUYUAt6pmhAWiVc1koMC0029EVQ6nZUPbC6D29FlrNQZCEqsISQiIooogCiKCC6j8PqrFXQ+H1VqzW4gU2KKmxUE3UU3RQK74Sjh2h1SCARB1Qf8JRw5h5PAVhVr6dINnu2ey59bI2plAiNei1VaoGpk6DosBBJqHUkwtMGBlvBuSid/RO0925waASRF9lWQXHxXnjZQdCi6lXwwpTMCD0SnAtm1QjpCqotboDlnYbrWwuLcrqZI5cgxuw5bYug8kWTtYYglpPEytMB2hf6GQqqjQCBFydhCBGsYDEET+EpqgiXDe+kIhtrTHW8oEeEiwUEpODy5h3H8/NU5YMtBvtsVaxoY5tQ/DOnTdCrSykSA2bgoIBeTRI/qsqxma6AI4lXXpiXPJEWAFkhpvaDUiOkIFaTYNMEnX9Va5zaZa1p8IN4QplrC4uIHHVRxJe5rpaW/CJlFVF1Rznw4h2rYP0TU31HRDzJ6/wA/gKao0tcHt81MjfjbdrxED2j8/dAXNFeZcGPjUizv2TvwwZTDHlrbyL3CADRDnQZOg/GenRLUqF7iGw+odTsEFlPs6oZLHsLT1THsmqSILWje8qmkXYd0ioc7tRyuhRx5LfvQAeiaskL9lZkFNxzO5IgKynlazu3ARuOEKpD3B9IzGoFymY+nVEEXHus1o/hZbVsXSvOWCG3It0VZeWOguAO0iUplpBJEnadlkO6u4DwjKIgA7qQ99P7+Y62HsrA6oTZmg1mfqmBY12Yshx3Op/VBjrPexjSJABi1lWYrAEuhwsDNv7LTjjmYBlgzN1kZSqC5ETstQNTqmi9zXiCRlM6hbcuQkx8IgzuVhgPYGPIB0a47efT8lbh6rszMNVbBaYklKi8y43v6KurSzNBv6HZOCXBzjBM+yL3BzS2IadRyorO6kxskOdHkqy9swxp8yU1VjqbZdUdGlkKZaSAwEnkrSHcM7MrhJNvJUvpNdcXcLR+yvqHumyTcpGiYMltgQUQlOi+qTlaYIAur6dE/ZqxLHNc4kmQlOUv0txvH8H1WxmFaKYBLg6LwU0xxMiLWwRb8QXQxWFpjM4OIIuSViAFr6kmegVTFbmju9J8H5H9kTh87KgbJNOSGjcI6t01ED3WnA2xJ4IIVRz51NwSItsEtG/aLIECbey6lfAl1QupZcpvErnU2Fvaoa4QQT+So6iZpEhCLogXWHQwKcFVBMNFA83KYHRV7lMEFma5TB5Cqm5TTdMNXZw9ha8S06hY8RgJvQM/0kq4GysZUykQp8X64T+z8UXE/Z6hnokOAxI1w9T/avRiqUc4IWvOs+EeVdSLCA5paToCE/wBkqkx3Th5iF6V7KdRzS+m1+UyMwmES85gr5ngxdlUHU8Llc2DmJ/JaKjIY48D9FYXoVCDSqeR/JYt2tZ6eXfftHzqLuVQHU+7Mgt/KVxWtzdqAWg1d/NeibSD2kyS4CPMcrp1XJnaXBznxpJHmdFHU2Pa1/wCKL2+LqnqMcWltwCACfzVuIpZ25adns0UlGJ9JozAmLKoUcrwHbiB1Wio11VoEZXjUGyDKeV8OMiLKAPHdNaGWMq6lWc6nD5D76DVUsh1bNIc1rdeqf8bCAZibbK6BTd3eIJcC0PFw4K77kmc7R4cvolqFzmU6xb4gbgLTIgGRGyowkAOIF2+aUjIMxmByrcc2o1uZjnBoE+HlZGuLWNLyXSbk3lTBc7LqdNVUXHvJa6H7cFCq/K9vF2n0SPZciDZWI1U6vefExpdxF/RaKNGlUu12Qj5bLCzMQHOGZo/ENR5rbRqMfdxvpmGqlVrpsq0bCsCODqrabwabpO0A9UlM5iIvG4Vgow11O17iRMrFqmpeGmJ3BKsa4ZXHfaUrcrqYJRbAZdu9uSVhRYXB3iNgrGvDgTBHKQMgFxgHnhV1HFr2iLQtSovzTIMgQjMt8MEcFVtJdYCfPZOA0DUkncIIQY0I+qLXnQ+90ngj4nE+aEcNM9U+Bn1mfiB4SPAElrhz4hCJcZgNkdEPBpJHTKU3QmZxFzTPUOWcipSqDIMsmPFoJWh5pad4J4SvY0sOpI1QUMYcoJdIdaOeqV4hwLSfD/Ai0Fr3XtF3cDWysyhokAW8XrslUJFSQ4gOFs2zrXlKwPpuAIiobNHHVHIQ3LuYb76/ojUe9lZ4jMwk2P6LKmLw1st3GVvlufVGmQPEY6KvKKjpYbxAa79E9LMHZqjS1rBJka8KDQNcu+pQtmJ1DfzVYqZbavOvmVHHxCk06WJ67lTEOwuLpGg3TTnIFgDz+irzjLYHILAD8XRQi8GDUi52amDQKLQ4EyTtKAdct9UrahaLy4DjhKHtL84NhYyrofPIg/1T5BYn5y6Y8R0Wlwu7iPzKkgtDDoTrwArujBVENygzyVXTqmnUDxJy6jotr6AuCL7RoVW6m5tOG2adU0aGVGuMBwlF1MG2g1WSnSJAExB1/JaTV7t+V0nyV1SublMTcHxHmf4FG2a3ef4Ve8gsvAabSSq6LWuYQZBadvdMEvE8Cf59FI1PsfJP3ZyujcyPJCZbAtB05UvpEDizNpBNkod3jpmw4KZoMeLSISNaAAQNldCuaHFpP4TP1SuDsoABF5Jj+bomoGkBw8OzmlAsv93VcCbwbygQ1KM3e0WiHGP0RY+lInKeIMhRwqxLqTao5FlSaWHqNJdSc1w6D81ZBsNQRAA8gVXUeJLSW21Wc0G06LnsqOttJ/dMwBrPESSOequiSSYD3t4GqQuJdLXteTqdIhCs1uU1HCALAKUarajy27mi4kaJEFx+amw+RVbmU3Anuvor3gC2UTyCqXh0eGR5iUHGQhFRdQIUhFGEEA1TtCVo1VjRKC2k2St1KmIVFBi20xZRVdRktWKs2JBXTcFixDNUK5zwqVpqBURZVCwgmQhEBRFRBbQ+H1VqroDwjzVsLNbiKbFFSNVAN0YupCaLoK3/AAFVZzTa4g7Qrnjw+qpc2WlIVUNidSoGxcbmVHGBqPPhAOafC9ni5BWnMdJLmm52EoirSFz7FpCDWTZjyD1VvdVmXfTY4dNUVfRxlOIGUdFYa4iQRJ2CysbSdUh9OJtqmptDajyBYHKgdzmzJBhHKHNzU81t5BhQQ8wTYJKbyKjQ0RexUVcMwaIcY6tUl2hDT5K1tVj7McCR+GFUXtc7KCCeQFApImCQeQDC00Wh9PI4aXCqDGBvwyORdDM6ZadN9CEBqUa4f4abTw5Usc7xB13mwHC3U8QCwyPEPqqqrcPWGYPY0m+tiqrJiGh4AggjoqQ8io0VLhojzC2OFWmMpaakceKyqqNztvTe0jcthEDMTOU+E2CWl90CHiabtRx1UbVIY5mQOcQIcNgP+ExzGm0PAA+IeSBa7HMu05s+jxuFWz7ppjUq2lULXd24ZqZIEH81KtId2KlM5mfUeaBcM0vfJ+I6StWQHpaZOwVNAtY2DuJeeBx6pq1UtGT8TvE/pwPRSqO8Cx/Jb8LWdUBaXGRrKwUWlxDfxOVwBnMw2Bt1UsWND2zW+8Ms1hBtOo4l1p1IiVS+o8Na9zzmOnkrKGJdl8Z00KmKubTqEatM7HdO2m8XLAHiwAmFGU6lVpLDkB5uD5K1jDQYSXFzt5/JMVkHifLzJGs7olveSJMdFvJDsoIDg42kdJWHFuyNGQQHomMlZzA7KxoganlXYN1J1UMrNDpENJ26LPlmTo0anlICZ/JVHYrsEWEgaNAtKzOa4Ntd0xPVaMJiBWpAu+IWPmrH0hJcBcqY055AkZrgj+BIxoaYa2J6aLVUoZR4iNCG+esqlolxO2qIqdSz1CSZH5I5A2wEEq4N9STH8/m6rIzbED9/7KolBueq0XgmfTX9ltfUgQ3jVY6bzTcXFpAiDflLUrOqHIywCoTH1MzMrTab9VkLJL9g0Bo8ytJYHZQPmm6reQAAIEukyqzQrOpmBSZ/5E6qunTFR2Yukg2hXAU3aPYRGmYK2iygHeOSeJt7hBdTe5lnkAcRdcpvi7aN58R//Su0O5sGME+641K/bbz/AFO/JWDpRupGqcjwlCLrDZYRCYhCEECYbeSUaIjUICR4iiUD8SJQQGyINwl2UOkoHlEGyVQ6BBYHGUQ4ZlWNfRAfEmGrTBCox0jDOPDp+ismyox7v/S1P5sknsrh4PM7tGle5fqvTNDWsMEB0a6CV5rA/wD8xpf616MyDxHB1WunOI97ZIcIEfuhi25wHgxmb6Kqo1xMAQToCIlMCe6DZdLCRY7fyfZZgpdkJBrAktsHNBP1CFaDSBY6oBOjgT+auYajQSwZpuCXIVXS3KSC865LIMoIy5A2ATt+Stpg1CZ+BsTfVK5nhLSACI+E+6sqNbTpDYdBM+aorqYg93UDddAqziKjcsXY5stsm7uZNjmbI6JKTczTTPxtu0lUXis4sLaniYdYsfRVnDvc5p+JmrS1BugGg/n6QPdWsJpBwFnHW/wjqqK62Fc9xytMm5HXlM3C1SAH03yBYgKoPc533Mzu9baGNeyG1BnO5CBMNhMQypmgNZvJWv7NTDs0AibxYK9tRj/DmEngyq2ONN5a+wJWaq8AOiIBHGhCcEWBmRoqi0ABzD6bIteS3QE9Ddc/qnLmtMEReT1RNYxaLncpWyCQQTzFz7JmuFzkLTzCgLszmgv220CV7iC0EAAjSFY3ILmfN0yqa5uIB09lYguDiZBJ4b+yanUkEblVsDg3xD0J0Uc0vAOjtuqovBLSelkCSbFLSqd5ladRqf1RBLhfZZqg+S2QSPJAgjWoI6j+6cm0D1Kpd3jbmpDeSNPokEL2tNpLt4EBHPaDMBI0siQ4uPkmuBmcPRVCPphzcsmdhOqFOCWtEm97KD7wyLzIT5so6jUzE/z9UUaYBqjMYIGYzyUtWO9KtpNc4E53DZSpSzXL78woqprbtIFwR+aIkMMbNkA9D+yGUsfBItcwVB8MTJLONLrIYMa2rIABzRPmJBVZaKeduY5jaSNlYfjNrZvyVzqeakwx4g0eqsRQHAeJpByiGAn3JlKczW2Ew6D1PX9k5YfkPsjOSXXBI41RQDyGh0Oc35hchM3LMiC19jGnmFGhh8TDlMzbRTu3aAAAmZGhWUHKWZMx0EFBvjqNmzQ2T5/wpnT8JvZBkEyDaI/JJ9UrnZKuV3wu0KrdnFSAJA5CL6haQHtlumijRUaLOaR1aVqgszFoMQSdEKfiDnu5gIPLg6BLBMyi1wBa1p8LdfNILAWhzg8AtBAuiGBtYtJIkWgwkp+Ik2ynUxqU7qgPdmYLtPZaiLclvid7qirVFKYpkgQNd+EwxANxmmYjqpULaohtnTfnzCt9gOPhBtLb+HdVvf43MzQR4gVGjvKwI+ANAAVNUPp1GPIuzwnqFMAc5wcYALTq1RpBENOdmuU6jyTVG6uaJH1CVradc5X+GoNHBUXU3Pbdrs7euv8AdSqXOmDMttB3VbaNRrg0ut839leWFlSQZB0JUGMgigJcQC7xWmU1ZrokCRlHuP8AlaHsDpgeFw9lUQ5zGNLrkXI36oM5Y40wMwN5I/RZ7tpuMEA+7lre2g1oa5wa0HRx1PVVVqugptEbvcIHorEZTXNP7oOsg2pGaLTwkxFOm+uS14a4nfT0KDKzaT4FMl43ft6LYzqIqLQEIgKJgEEA1V1NslVgWWikFRpothamWCz09Fc0qNHKzVgryVVV+FEc2qIJWeFsrjUrKQqiuEIToIFUhFSEF1AeAeZViSgPAFbCzWoEa+ahR3RhRSwmi6kaoxdAjx4fVUv+Ajc2C0PHhVFVmakbgGxCJfjHmziR5EJQbQRI6bJg3K4gix2UyuBBbfiFpgzHAxLp4I1C1NeSwtc6RykGFNRmcsyOAnifRX0KFPuiHTmOjv0SivuznDyLOG3smo0yWPZoQRvPULQ0Q3u3QJ52KQ5WkunVseayqpjQHuBJmNtkoYXXb8MRbdXd5TYwgAOkeKN0vfF7YYMk76kIM1VzqUbEoseSba7QjVe3K0FuYA/iKGZzGzRsIvA8X88lRtosdTpnM/ISZAiU0vIBdXZfbICsdCt4iXOMgeGeVewCm4ZhNpIImFASQHkSCeWsCqcynnLTAM6kwrDULrDwjokqZhGWBsZCCxtIubDSD1DgiadRkOzAxoJlVd08G4aeYKgbTpu1BPAMoJVokQQ4Enj8krHl4IJ8UyXH2ACvOV9OBAIsLalVvpOhrhAbN+J6qgPokNsJJ8IHU6/smogtd4T+FxHoICcOB0vlaT6n+BasLQDu9I47sfr+iiue2qx3xtyOmSRofMKpzHtJc4ZgT8QuCrSwGE9EZA++wPsQgOHltJzvxPORv6lWNe2o4U2nwak/0j+fVB9ORGpAe0R0v9QlbRcKVQUzqAST8sSgIcK1R1Rwhjbx+QVgDnFoABe+4GwHJWdsQ1kyweJwBu48fzqrS85TMy+9RwGg2aEVfh6zqTz3bi9v4idCtjq9N7SCQ10aEwuYyqe9AbDS34QdPL15V7XMqgtuCNjq39wpVlag8iiwiZaY+hUbDntBaCMoZET1/dVsa5xYRYgQ6+trFMw5GydbqaFq4drhmpg92TYDbaVT9kh2hdAsI1WwB1PCh8CSJIHH/CSo/wC6FRpt1slGRrS6pYAZzp1/krZSfUp0h3hkTvsq2nMWtLSDr5pqkvy0o1n6Jo0NfTrMzAZxxGizsYO9fTJLQ4SP57oj7twyGxdClRlNrWVKJLWzcjUKgmkQ4XB8JuOVREAtNnLbkd/3Xew/ZZMURRdJDnuN7QLBMFdy4SIA29FQKYaSWkxKfvO8YMrcsm15VdR5DspMEiR5qxkhqAO8UhuxCJBzSytM7EKl7iHG0g6jlBpBs05m8bhXEWOa4iX0GuB/E1RtPDFpID2u4KuoVXs0dmafdPXmpJFzFo2/gQUupd1SD2VXOkx5fVZcGJ7WdvE/ktQBy0xNibiN1m7Pv2pV/wDL80h+3VOihF0SLBFZdCHdGESFEQo09EYUGiKAbondTdEjVABopFgiAjsEA5UOyOxUOqADVTdRHdBCqsRT72jUZMSIlWnZK74Cqjg4ER2iyIMOOq9CXk602+hXA7Lg9o05IFzqu8/KJJEDzWumAzNzSGkRvwhSeG1MwjW4j+fwpMue0nL+aYQ34XZhxJkLIsq0mUgXsYSOgmFl70suymQXfidutFLE5SGvkN2nZWVm06sgi4MgwrgzlzC+9zGu6xZ3US4gSxwghanMqUTbxMmdJA/ZVF1B3hsORdIFoVB3WYHxAwB/PVSrLywtGUt0hVPikZbDhFoOl1f3rHVyKYLmT7jdVBMvb3jPC/8AENx1CyuzOOQWZN+vmrnONN/eAw7aE5Y2sM1OGv3Zyd4RVbqpa0MprRQpQzk7nkrIxpdVyix67LewgtAaYaZAJ2b+JylDBtpBsbCN1dRqOzXhzf6hKzd73j4aIboOgWljQGdAs1W1p8Eta3TbdVtJAzkS4mAISMe9kAXnQFMKrqbos691kO1rhMtb58qwZ4EtMDh0ICoC3Qx01Cb70xlAjlTFQyxpcLuO5iyjQJza8Kxpghrrzv1UIYZlsQJV8UJlzjWB0VLizNDRYbndWVHZfux6qsAEkgeEfVQW0msc85pzdN07wGjaOANVla82Is6ZC2MeHtDhvda+ikyBpJlA3sd1c5g1HsqnMOmkT6lZsVWAxl2jylJWa5zoJlo1jdWTLvO8ocu046fz9FAgphlyTAFgCpJHp/P2RebwRYajoFG2e0ON5153QaGgMYGnYJXOOu+wVb6wAtck2SS45i43y6DZFUtJcM0majo9FoblDXFziLwI3gJKTAzJm/AD/P5ymaJYHEXI9lLUDM4iGWk2J1KvpF7Gw52Y9Sq8oLx4r7bAK5lMAAF5Un/gskkWIB4KQggyGuHUFQNYLoEkaCfWFr/9AkgG4d6QhJHI87hF0kDM0gAySbpQ9gGpHVZsEmRbjY2VObLUadQPqFdAJs4H0S5QGloMyf4EVXWDm5jF5Mw7ZKO4sCDmOgBJ/JXBpewQYe3c7oEOa2AWg9LKoqrANeL30mf0UAl0MIAI1OwVjBTkNnO46lKWOYzO2CWlFWOkMyAGNBA1VRvSB1I06JO9zszkxUB0lXSIl1puFrEB4A+8BgP16cprmALOHG3Ptoqw9rahpn/LOh4KYk03FuXM47TY+Z/m6C0PbkzOaM7jbr1VT67GODX0w4k/C0aKo1XOdkYfE6xfx0CLjToNOUZnnWdStDXTZQddrQD5pnNbTbLGgeQWNrTIe74x9Fb3z2zmAPRNDNIe0EHxDdKXlhIc2PyStILzkfk6ESnqgZCXOB8lgVOeB4ptuAbqnIav4iJuR0TSCC5zQWjSwEqsZSSSR7lWBe4Jgl0jYMEn3QNAuGgaOpn3KtbTbHgc48kEfqkzHLme5zRxNyiOXjW5K8CbCL7pA9r2ZagJA0jUeX7LRUw5r1S5xgKurQDRDBJ6LpEUqIoLSomCCYIGaLeq0U1S0fmr2IrQwwFYCqmmydpRTkpHlElI4oM1YWPkshC2VvhPkshCIrKCchKqgQgmVdZ/dsndBppQ2kCSAOSj39GJ71nuuU6s+pZxsNkpFgphrrjEUD/8rfdEYigTaqz3XGAg9OqLDleCRbgq+K+TuNc12jmmeqYi5XIpFrXOF8vC6GCrd9TIJlzbLNiyrn/CqariykSHZb3KvqCGjyWXEhpY0u0BWZ9W/Aw+NqNNxmZydV0aOKo1m+HUaiNFxsxqPyizRqrcpAW3NuxLiyo1zbg8JcveeJhgnXhZu9qNBaTI0gqxlbD02yRlPGZRTZyTDmuIGsXSF8kSBAtpr5qqri6dR2Wmz1hQ1y4iQ6OiYLw2hIEz5aK1tNhMZgB8rbf3VdKs1+uYk+pCsDR8QnINRlyk+ygz41rGsaGRrsstMuBkTbQjVbHt754zAADbhF1ORDQFYMrmd60loh41A0Pl1WmjWFdrWaPcfFbVUvYKbgA4lwvbZacHQbXrZhU7t4EwBr1QAakgQAfdWPy5S0XPPCvq4dtIGBDdyTc2WciGgkanRRWdxqEQ6my+5CLGtbdzgTwE1eo0jK/zO0KmlWpMO7vVBqFhmcNdkoJJkX3jlVvrCqQC7I3rurmshsh4IAAEILmE0nRTgE2NhqtdBlQszs7uHGbtj1WNrS5wbyY6X/hXUltNoHGyLHPr4J7DLQ3/AEgrNBEg2khq246uadIuHxEW6LnU8xLGzP4yhV4d4o3lxPsrcKSMVSB+UNVZYGUWOc8Alslu90rX1u9BpCHC8m8IL8ZgxSqS0EtdcRt0WZrGg9DYrrUq5MB4OYqyoCWkEEg8G6GOYyHsFOoTpZwN1aaRd/8AcymW7OCvdTbsGk/1shRxuPARwWrKloh+Yu2M6iE1nSY1A/NM15mQc3kYKrqyIMdbCFBa95Yxjm3EZfb/AIWZtTNBota1x+ISYVlNxdRLdSHagqnV57wubYXD1RcXPazMWeIWAaZ/RVtcZNRxl0Q1scogMLHFlR7hpdxKpEFpgiRpBmFEXl0hgjM4aCdzurC5jabmGBFyVVQkA1BBJ0DdlWZL3Akw7kRKsF7cWAGtJIsDMbJalWniKeUiHkQ2d1la3NTt8dMkx0RbGWNvL+cgehWjVTwfDTAIIMu6WSYprw6Y0OZp81sY4X74AhgjMNfKd1TVxDWXfSYQdG8ojK8ZhmaJEXCFMMqnI+ztnDVdOh9irR92GHg2WjuabRNJjQeQLqpjlMw9RtQNLoGsx+i2Cn3VQEHMIsVGPFVvDxugXupzmEA7jRZtVKlMODsohrvouZ2ZftKqejvzC6BqtbcHN/SDcLn9kf8Avqh/pd+YWon7djYIBHYKLLoBQGqJ0UCICMKBBzo9kEJum2JSIlxIsgZRJmKZpk+iA7InX0UUOvogH7KblRFADqEHfAUxCQ/5aqPPYITimjoV0ftBfAJsBAWHs0gYsF2gadlraymTLQ4n5J19VuubRRe9z2hmo/LqtVTMTl7oPOuuywMxbmjK0CmOIV7nHRrjYS4zqVlVzw8CMmToH/3VVUNIa5zoy+ahNPK3NJPBKUkObBAA2AQFlN4BAe9zeJMJiKr/AIhn/wDAFUNc+PDTewC/hJ/RODWd8L6gPqiGdTdUBHdglup0sq2OdT8LjAjKHRoJV1Mt/ES63uUr6cuIIktuIOv8/RAMhcJyw2Jjc3slFM54Fi209d/1VlFxAlw3kforAzw2Hii3mf7Iquo9j2NNQEF4MvaLxO/spVzCmSyHNdbM3QAaBX4yiGCnT+VuWfJUMplsFpLTpIKAUCANy47BdH4SGyPBqeXFU06bTUa4MaHS3S0SP3Uewua0h1ozEu6mCVL7Ve2pZ1WbDws89ypTAADnau+EbxyqnMcajWEFtNg+m59VYx7nOkWe+zB8o5WRa2c5ykAt+J2zei0UqxLfF7rJmblAbPds+ET8R5VlN9pJgbOj6RwnxWmqbBw5BUe6HAbGPzVMZXBwsJ8Q/VMZ8Q1DSIPSFLQ+Vj3HNvJmdAkNMmGztYcpnw1jtzYQncSwAONtyn2IzimAczrgcItkEgSB8WqtqOLQTFiNUoDXOEFZ1TtqOyDOPVM7I5sk26Kqoc+VoFzdFv3UBumaFry/oTKTUcwEeIWJ/nmjkIc0EauJKlRpZldmzX1Ksh4/Cw+4TBQBJh2plLMgxYusfdPVhsueWtASZ2OnKcxFjb6LNgRzCHlwNosCi54a6XSJj6IZ4yzqZBVT6kTInYjlJBcRUIlrWP8AVK4jV7atPq11voqmuyjM0lzPO7VdTqEHNGdp1MX9R+qYCxpqWp4kkcEynaMQHQHNcB0j9UXCkW58gnnhKxxbVcBPhk+agsa57yWmwbxyi8W8JkykaYbmIIOefKVKb3STlMBSqLbfFe8EgxCsIIEF59VlIAqNLgZmY3JTjEOaTnIyzstRFhHAaUhDnizRl66lL3pLgSfCdkzKgIIJykbgqYp2uy3Bk7iTKY06dWH2PUKp2Vxg1Gu81A4scYuDrJViI+kaRLmAAEIA5gRJbF4d+6ne1GSWsDgNI3QlrvFkLDEHKbq4Er0C4ZhAcPqmpS5waToS0Dyv+qLZEnvKnkWhJVYQ7vGuuLyOFUOWtJIcRpOqDKgczJVIbPwnjolptp5vizGTHl1UqQfEL5TP8+iKjmGkHS3xfmqWHNWBjMQbDkq+m63dP8TBDZ66kpBRfTvTOYusHfIDyqL50DYJmAeTufIKt7wIDL7Dr1SPqhjJbuMrBw3n1VdJwDS4m6mC2C0yNRurnVabqdzHmkymQzcDM7zOgS+HO50S1n1PCggyPygvgiYB/nQIvpUwJAganos+U1CXTYGJ5KPemWlxLRNiNf7q4HqNww1i3CNTD96zM0w4c7K9tKiQHsDTwYSOdlqgE/FIP6K4Mr8PUY2MsjkFZ6tQUmf1HRdAulxaNXOA9In9FzsRRqPJqtaXNMkRsJVRhUUUWwUwShO0Ip2q0Oa1pc4wBuVVmDGlzjAFyuVicS7EVL2YNAqmui/tagyQxrnn2CrPbFT8FFo8yua0DVS5104VxNdQdtnQ0B6OV9PtPD1BBJpnrouLIagXzyEw133Oa9kscHDkLO4QuTTqOYZDiCteHxZc7JUMzoVMXWgpU5SqBTYErBVqueblb3WaVzHfEYVhUfrZSHHYq3DMD3+Jb20wNAEtwnOucKVR/wCEqGhV+VdUNACYMGqnk34OQA9h8TSrcJiDRqZudQuzTNINyvYCDusGNwtEYhrqVmO1HCeWl5xvqGWtPIWPGf5bfNayIpsHAVVUZmtYQC17ssdbLE+l+MWHAu4iQNuTsFe94YC4m4MA8ncqpjQTNJ0los06g89VlxVSXBjfhaIC6fXMauJLrMsOVRKAQWkOHRorGVnDU+yoUTF1uZXIMteb9VuwOOzVAyqAQfouNTEuFpWvEUhTp06tN0TZzeCsWNO99louHhBaTwVjxA+zyAcxOhRwOOFWg0kjPTNxzY3VppNr5GvcRDWgRyVKjmFpc7knVNTqOY8PZYtNlpq4Z1MmmLgmzo+JUig7N4rAalB2KT6eIptfAM3jhZsT3VAuc8ktBkjg/wAhZaL3UnFtMnLOYSqO16pqMpPcIJP5J9VhxNc1KriDaVVPUq3D0+8eSdFvbh2FoGUFW2QnNrn06pHhEQeVY2tXp3YR6QtpwFI3ykHosuJwr2SWkkdU2VbzY6HZeMZUe01Dle2ZnQrdWxAaAG+JxXl6dQteHXkbrs4ep3w70XvluPdSzElWVs9Wm8EyZH6IhoaKrtyA0R7IgtDy2RmJmDboi4PaZdSkG8hygnd6SRJvf6Kyhh3OcS14vqZ0VOcNMCtVonhydtPEP8Ta7XxvZQdFtGGkd6Mv9IhQsZTZDDcrGx+KazNUYHNG4Kta99RveOOUHZGl4qOJIh58rqpxAdBJYLQCI87JHZhdpEDWdFdT8Tolwc086+Sn0Qlj4GcGNJEpXMFjmbI3lO5o3c0+aRwyWLJnSNFBIy1JHw6GyDqBa6QGGmdMwmyjQ4GXiJ4Nlc2o133dSDOl9VRmfcgPeAwaDn9kHMa8McwQ02vur6mCplpDRfUSsxLmuyvDhGhG3omIqNVzaoo1LU9JCNF/hgmQ0m/Q/wA+qapRFQnxAg7LMGGk4szAA7npf9FqIsqPyEVKZ8U3HREloaKrJyHjUHj+clSo0MDSY8TQ4eqXN3VQhsOZo4bOQV1a5FsoBHwtGjf3KSWsb3j5c88q19NpHe0zmYd9x5rLU8RudFUWMBqDM4dQOFobXqs3mBulaMjfEJcIJHU6NQqvDPADJBueSoLGvbUqASaZ6XCvqhvdy55PBhYgCBbUXlaPtDTSy1AZ/NRVc+HM6CPwyPqsfY//ALyp/oP5hbW1KRgPlpEx/PZYux//AHlT/QfzC1Pift2TsrKbGGnmc1xM7Sq3K1uXuJcCfFaCR+SkbpSxhdAa8ebSlcwjRWvaxrWmHC0AZioQGkN8Rm9zKsmVm30qp0yT4hbzVT4DyOCR9VraQH5YKxv/AMx3+o/mr1n6OdW0MO6uXQSA3WFb/wBPd8z/AGTdnTFWDFx+q1y4fiW+eZY59dWVh+wP+d3q0rmV+0qOHe5mVznC3SfNdLtnHOweCcWvIqP8LOnVeSp0n1jb6qdcxeba3v7arE+FjAJ4lX4bthryG12ZSfxN0XP+xP8AmCrqYZ9NuYwR0U9N+49QIIkGQdwovO4DGvw9ZoJJYTBEr0SzZiy6JSO/yymOiy9ouLcI6DuPzUg5XZbBUxLgdIVjnEOJ52VPZxIrPj5VvZQaBLrlbrmqJbUs8wYs4/kf3VVPHsog03NLxN4KoxlbM802WaLHqUaOHZlBLSSiya0ntGg50kOvew0Wyg9lZuZrgWrn/ZqbhDmBqopVH4PEEXIBuOQp9+LZjq1Hik4gBwY4zblVlzqhhuYjeVcx7XtDmnMHBVup1HOnOcpvc6KILGQQN9wryYAAN9ZVctosMCTyo1ryCS3UR5Ii1jGvLnOJBna0q9jmue1uTxAggB2sDqq7x+YGy1YJvxO9Le5/nRFDEU31QD3bwW8wZWeC10OBBXSc6BA1K59etmrhjYyMEnqirWAgixs5sniFAZbJ0LX/AFS0Q+oQ2JJl/wCSZ33fhda0Rusi7uftGHB1eyw6iFSGuiM7h0lX4WvbLkLWnQndaMlJ4kMB8hdBlptjLZp/CbahWNZrkghwux3KcspzbKOhJBRawMmWuAPWQs1SNhpgS2RIadj0KuaZZBBF4QBBEAhzeqJIIgj0KyJAzB3WfyUquF2vkjoq6jiMw1TVXtcwOkQRMkWVnwAmCJa54izgLhNna1wdoTaCIKrZJnI5gB2LSUz8zaZLy2eQ1QRriPvHtyw2APVRxgNOkXNt1WZADiYg7j6pmEA946QNGygsyjuyzc38lG1QWgSC6OdVSXOL3j5oGsqkMljSLlhynyWoNbslWIILm3gXWEzSpEg3mw9Va3xDUzt5n+H2UaG1niZD+QLH0QU15yEHUjMPMapTL6bX7RdaKhYYaSTG4bohSwzCM1KsIJ4/ugzMDc8Zix2zh+qcGtSfLwI+YaFaTgGF0ucf/GyfwnwCxjVKFaamQPLcoJiVYWgQ8aixSh+XwuETqOUxOX4RI3CwBTAphzMoyi7Y44UaHCXyACLNnXzSPeS7K0gyJPklcaxsWkE7NCmKsIbTYX1HAGLuiFmr0y+m00gRJ0I1VjWwYc7M8bTmI/ZU4lrm0wXc2laiIyQB3jgzz19lop1GDw0xc7u3WIObVEP1A1Go/dRtR2HMky0ixGhHRawbQ5pJAptJmxMXRIIJPgaOQEjY7trwQGgTPJKEkmXHXlZDOLi5pa6AbeI6phUEwWjzD5SOZna4RM7cqNY3KC1rvRysFhewHL3Tz1TAAsPg9VQakAhrDI3JVjXmZI/uqiotyuJBDWR4j+iuaQWBwFiM0fkEpDYyutN9NCowH4A0XN4NkCuYQwgTmiPU/wACXEse3FF1NxaYAB9Fqaw963MJuXGOUmIEVhItG6v6GVzRUjvG5XG2ZunspSpGnUl0Oa2/h1MHSE5JjKmcA55HOf6j91NVS6uQS3V5MmPmOgS1Cc7MOwgkanlx1KtcfxmMwaxwMaTYpK9IUiSxpc14s6b9VYhS5tyB90zwtG7jx66oPzNcWmDWcJe7Zg4QDwwtIB8I8IIsDykcxzmFjSCT4rz4j1QXUXljAWOMHc8/ooaxqVAC0tc28E6qilnBdljvAYcHfiVrXZjMFr2c6j9wgL3hz87DYmPpCjXGmx3Bho6DUn6pu7Bbmafidm8koBqPY0zlzZvT+BJRx1E2QzEIZXcFdBAnalAI2TiyKzdoPc1jWAwHTK5p6aLodpteckMdlAuYWJjb3C1GbEaCZVlOk6o4Bq10MI3KC4m+y1sYKYhlMkDgLN6anLAcG8D4ST5pHYKsT8IC6bajCYcch/qTlhiQQ4dFPKteMcZ2EqtF1WA5jgYEg8LtOpl9gFixlLu2ExcKzpLx/FtN2em106hFVYP/ACT0cVajIESCDuuY9hbVLSLyuos1ak57w9o2jzV1c0lBhDgQtJqBpuQEtMtyWY4Hfxf2VtKs1hltNrXbnWVOZ5XF3J6RlWkbOqgLS1gI8LmkcysZjJJIB2gTKvDzZrGNBLRPEp1zizqne6i3w1Hhp5lZq7S8tY1wcHGARomrhjxTc1gaC0ZibnW6mFyjM8sAi4V/xpe9bKghrRwEjaRfVp8NlxVtaJEBNRcGAyDBtZsrnPq345NSlFR0WglYa8966TJnVdbEMiq51y1xmYIWDEUS6sIgZhK6RzZU7KZcdE78O+mMzhIWmgAWgHQq2rOWEAk5RdasPhC4yYPRaXUwwSGA9EHDMwkw0jRo3U1qc4tZhjTaBlHEqVKLTTcx7gC4WBUpvLW5GuEnc6BZ303967vPjGnmsN34q7OzjFZQDoZHou3T+edBInoFTgaQpOd4LuEk8/yVeWXyg2jbzS3XI7TlwrS9vg2J2vr+qWplpw7KCCPdWue0UWNf8Bbb2WfMxrQ3MXsOkAyFKpWtZLS25kW42VXa7WOwQ+ZpEfz1WlppiKjdBYyIWPGubWEOBDQDb1SfSTWWgwMYDIAN5K2UHMfZlVpPCzCmS0NAFgLpXUtCYJG41V+tzY6eV4sWyVVVBA8QVbX1RhviIlZTTe50mXdSSpjVrNjKIa7M2wOy6OBYaGGDXDxOlyoNNxdSAklrgeVfiHERsWnMPIha31jlZ+0e9pgEeE8ahO17mWLjB0cN1XUFg4fC5Ck3MSGPDXcHRyI3UqjYiswFp0I0Kd9Gk0/dtykg2B1ssuH71tdlN7YzOAjY3XTxdTA4Jp70idmCSfaVMVkZVd9ndYuzHKI2Tk93TaBuwfQ/3WKt2ph3Asp4bK06y43T/wDW6Wdodg2Op/iLTdPG01rLy6jlIIDjcqunU7sPLfi0v+FbcJiOz8aSygQXASWkEFXuwmGa2DStIEAE3KYuuf8AbCWw6O8StrENkkGDvwuj9gwpdekJ8z+6812vXDcbVo0DFNhix33Tx01063aFCnEVHCRpss//AFTDkyfDO91xwys5khpIlRjamhYZHIV8Ynt6A9o0zSBbUYSIjMfzsm+0vcctWk1zNo2/NeaIdSdIJutvZ+OLHNpOgyYEiyWGuqWtDpPeNMXLHCEtRrXtPiJjZ26f7Q3LPcgn/WjTeXPDu6a3YAmyyMrQxrh3hJAn1GoHumqtmGAS4jTiyfEMzEtEZjpG6oOKZRBbcu2PJO5WkFj3UiMp8+oH7ovpNzh7CA+YDDoSI091hrY+oKhIpMjSLmwSf9QztDajBAJMt6/8K5Rve91IXnM3Sd3Hf0VLTEFSnWFWnYiowbO1H6q0UG5mkE5TFiOVBYGwxrTqRnd5bBCRmc+BlZbzKqq1KkyGmXmZHsAlffJQadLuPU6+yAgFzTUcYB06qvsck4uo46lhn3CtLwQXBvhHhpt56/qq+xP8+of6P1V/RPrsOJV1MxhxM3OypOyuaQMO3NMTsVnn63T1HgNaSTc7FCoQXgEmY5Re4ZWk5tJsUKhaHtBJB2vqt1kCW99F5HRY6nxu/wBS1OeBV1MwudjMbRw7yHEl5vlasZVljpdn/A/zH6rXsvNM7f7kEUqEzu5yvp/4lZ/8uGI6tdK783I49Taf/FFFz8PSqAiGOII8/wDhctrhTa1ktBA3XS7TxdHHYVr6NSWaPZoZ2kLCe7ySQM3MrHd9uv456FtWmaRLgJ6aKoVASLtM7BOKlMUywsOvxbItFIzuRwbLDdVdn4RtbF1G1JhlxHmu9N1zezY757gdbH6QuiEtZzEJsVk7TP8A6Q+Y/NbCFlx7A/CVJJsM3tdSF+Ob2LRFbEvaSRDZXSxFJ1GmahcHNAmQsPYFsTUP9P6ro1H95Qcw3+7DffX6LdYebZd155WygXZxlze8qnDMy1nBzZLbQVrpve+t90AwN66pW+Z+yVWxWM059EmMaO7ZUAI2IK0PqVWPZmyvBO2vqrcXT7+jGkHZTcWzVXZRLqdRs+EXW0tIIkXGyTsDDua2sajJYXDKTvErTiKTqcF9wdSN/wCXSuasNloE2/n89FbGW0RGqbJlqER8M2O4CDmmA0k3bPusgNHMneFtpHLSaOkkrLlBJDtN42v+yV7nQC0WP0TRe6vmOVnMErOGZnVYGsNCdnhDRBndPIDbyObIGjK4ta6IbBveNf2QFM3LR5nhQPue7qMkmTmkfqmDq41otJ2LXFRWii15E5LRsYVdXtDC4dxbUxdJhGob4iFxe1u2apa7C0pYQSHum/kFxWU3v+EErU4/o9pT7WwNU5W4qn/5Aj81pp1KVRuek9rhywrwvc1GCXNMBX4XGVcM8OpVIvol5HtGgmMwExOiJa4aT7qjCVWYrDsrUxLXidxHKtiPmHkuVipkl0O01nRRmYgtFiNP2UL4IvJOgF0GTAPGhhSABuYEEVByJgKAEiGtyMG/KucM7Za7KVRVpvABc4kbhXApZDsrLgjVQVg/7ttnx+LcpxUl1okCINvVUVWOMugh43CSf0Fjg4i3iuD1Qce5d3hEsNj1VVGo9uZr2y429v7J3tlsG4WsQ0BsAGWnQjcfz9UrqjRJDraF0WHQKNIYO6eTlPT4VXWpnvAHGGgWOyKBzVpA8FMa8lBjg12WjII1PCSq/RrfhVlBoaz1v1PCI0U8UQAHSTuUHOD3ZqZ8R/DoqzAuYsYHU7pJBnoYnqorYC57YdTI6FVF3duglwJ4Kag/M0gmDxyhlIe/d0WPH8/RZCEZXABwJJuQFbNSZLmhsbpBQdrnII1CZlJwE95E87oGFQiBlBnQNuqMYXOAbAzTtsr2036yC+PigaKlrS272kRuQkgzNwz2+ImD+SDXDK5tSS0m4G3VbAA+ZuFmq1G5sjAA0cbrWolIvpOFEkFhOYO6crSAXve4XadDsqsNUax4ztBadyPhK31GgwYJjYJYrPmlsCQPzVbqQEuEgm5AVhDmh8nxC5SkEane/RZFdJ9PRrDPUq+7Glzjf8ksgEkNAP5oVKeYgFxMajZaADw92bYmPorZAbANt/57pQxrYJGiF4uPMIL6NMOlz2/87p302ZYIMcSUWeCmAbui/mke+ATN9gtDO4MZVDc87kcDVJmzNBAOYtJJ4F1Q4OcKjrkvfkBWloYwvDml2jQBv/JWQrhIcP8AS1amMbUwoa7UyR0WJ5LmkzkDja+qtw9PugchJnUx9eEnoB+FqcNPkVWaD2mC24BsIlbRUBADnQ7QZf5CVzc3yOA5sVRkDTUae9pnNEEkQfdTuidHBzdIdqPVXluXQub6yAkgm5AJ5BhQDJkaA0kwb35SNeGuaeCB9f7pyfmNhu4R9VmqNLiYkydkR3SAdQlNKmdabT5hYf8ArGCc4MbXGYmB4Tr7Kir2/Rp1HMNKpLTBuFrKjpnD0DrRpn/xCoxeFoNw9R7aDMzWkiAuef8AENLalV9wtWG7Xwlel43ZJOXK4cq5SOeXBzCIEHWVzsTh2d9TLBAJgrp4ig6lVfTFnRYkahZawl7J1ao7fYDWmbKVjUMBphXUxZO6kHDUIuOe5ry054JnQK/DtgSHEW0VjmBuplSmCCYbCupjLVxtQPLWhtubKmvUq1qRztaTGytrUC6u6ATfnla+zMJmxhNW8eOE2SantVR7NxVOi0d1c3PiCY4HE/8Aa/8AyC7rhdKRdc/8lTxcI4TEDWk70us9Rj6cMexzd72XpCFVWw9KvAqNnLor5rJjgACSObq2lTaTx1UxlJtHFPa3QGfdFp3la1Yeo0NsDmIHskoAZxLgN1RWZUNb4iKfQrTSwVNzSW4inflxC19ApimKhAIIJ1iYVhZnrNZIgm8DYLnvY6lXDabpFiYJhdHANz13PN8ot6/wqW2C2sIcFfhv8on+pU4uz2+SjKgZQJJgZlOUvxZiajQwz8I1XGe8PIflDbmOIi/86LVia3eUnAfCAqqdMAybtYzTlbc9JlaScwdBkG1lVS8Iy7gwi1xp1DRLc0aEnbqg6z5nVRvdbKYa4XUdSHzW4VTJyyFKr6jWRTEuJUaWimBJcct+CnqupBzXSHOAgFZ2se4B1Q3GxcqnZhUIAsTsmGuvhng0gTvN9EH+Atyz5J6dE0qTG3BAgwg9uaBFtIiFlzod4KmHaTEgxdUUpDyKZaOjnSFpptDHlh+F0ST/ADzVRpEVXB2cO3LRqqGeKmR3eCmYuDt9VjrtLqebiwIWsC3d0w6PxOcZVVZjaMB1QAOEElyQjFhHzTZmvsr62IpEEMBdGwEyseGOUupnUXWhlJrnAgkQOVpuX0f7bT7prHsy3vIIWhgpubM3jUbqjupkBxHrKryd2Sc2xlStbVlMmpisrNY/n5LTUFBxDXPMNEZg235rFh3tAfVu0OMTyOArINYSfBTG25THO3W6l2exzQaeIBaf6Z/VMOzKdN3eF7jlvAsFgpVHMP3Di0DcLbTx5Ah7SbX3RPQYqsyhQdXbAdSPh6mV5upVc95e5xc5xkk6ldXtgsdhw6m6QXyRwuMATYBa5npKdr4GiY1HHQR5KChVMDL9Vuw3ZzjBqOEcC61bISWsA7wfeCQQZzDVel7H7VbiqHdYku71gjMCfEPTdYa9FrKcEBo6mFn7Nb3PaTcpEEG52ss7rV5x6V3aGFa8h1aCNiD+y8bVLquKqECS55Meq7GJaa1R7tgJJ0sAuXTBp4l28iUlT66eHEEQFfVYypPeNBK5suDpDql+CtVKvVYcmY1LwJWfF0nc+BUw1JjSQ3VYadIUcfSsHNJ0K11cRVqMnO5rYmGtVeGYKmIp53F2uoutTYz1ZW5z2U4LQwn/AFT9EGue45pCrqAUnS1gcOVbTl8F/hHCwyGLruo4Z1TUtEN81wS59V0zeV1O0356Dw3RpBKx4GlmOZ2i3PU1M24uo4M1Wgvlx81cezKcaH3Wqm6m0gGoATpI1V8EDUecrF6rtOY41Sj9jcKjJgGCOQug18ta5txDSPeVR2iQaDoIPkZQwjiMOxu8D0C19jn1MvpeYMjbxgfmFMQwHDDEMhoHhf8Az1Sk28gfqsvaGI/9PTotMguLj7ABIyzPxD3fCcoAgZVUyo9hljnNPQwmpMdVflbZbaXZwf8AETJWtkWS34qo9o4miRNTO3h913+zsZSxuH8IILfiadlzD2XSYwk38yqKE4HtCkWEim8hpA3EqbL8Wyz69IHNe2SD4ROpUcWkZiDa2pVYrsB0eJ/nKIr0wIhwHkrsZxnxVRtKk+sTYCdV5Z7n1ahcbucZK9H21WY/s+o1p426hcXB0JAqO026q3r0Tn2ymm4fhKhY5urSF16LQTbKT5o1aLcpOUknVZ8mvByKLiHxJvZau9YQ1jzv7KjF0203jLYFCowuaKjbg6+at9szZ6dQS1oa0DKB8ot9FlNSnTe4D4t1lbWrNblDjClJpzd44SG3g7pjV6dKniaWApQfHWcJLRt5qv8A61W2pU/WVgpsfXqWGYk3XSpdlsLfETPIUuT6SW/D0O2WuOWvTy/1N09lrxT2vwNRzHBzSwwR5LC7sxjNHO8ysYq1cOKlEmWkFsJ6vwss+r+x3FlSq8CcrbhdJusgTJB+i5nZRDXPJ8o5XVqDLenpEDopWHMxhbQxuWAJaCTyVndiLkTHULZ2nQY6m+u58VAQAOdVzSwiHDQ3WpFlq9uLyMi7jO6L8fVe3KA1oO41WVxT0qL6xhjSUyG11cF2qaeUVJgCDF5XTqHvqQdTaXMInNK8zUpVaRGZhHVdHsbF1W1O5u9jtW8dQpiOzSqh9FofmNoJykypVa0gZQSdPhOiOHIYX0zAvITV69JjHZqrGkC0uAUFGVxuWm28IZhdvy/qucMbhu+B72QNzOu5V9LGUKzS1r2yQRe2sqYL6jhERIG3PVNRqOpiA8uYfoszHF9OTq2xTUswJyw2djoVcGouY6O8aC0/i2/sr24Zoh1Oq5gnRYhUNJ8OYWk6gixWuhUZNrRqNgFkeapU3VHuqOGZzjJJWhlBxMBqzBjmmWyCPNaqjalXDi3iVrrDFky0geS5tagadQiCuhQa9seAEj+mD7qzG0jVptywDO+yS4WbG7/DtbL2cWvBI7wx0sF1X1MpIEk73XK7MpmhhKrGODi3xSN5A/ZXUahIgzqpfbGY3sIL9fEQDcInNrl9WrBV7QwuGINesMwuKbblZz/iDBudpiAOkfus+NR1QXMMyOsghM+uBEzld0sPNZaGOwuJEUK7nu+UmD+StecrZi40k3V+KD3UagJY8gjoo51QOMBjxOgfce6ANMeJwyH/AE/qFPu9TUaJ3URVVDjDsoaQdQZjzSTVq5GmBHhF+OVe0MkxU8OtlnxDQ0OIJ4PVWBzJGYnMTqq6dXKwteMzLW6nhOwB0FwiL5J0AQew5uSLn/UUFdWkcwcw5mH8XHmmpuMDLb8LJ53cmMspPcwxlcGjyAP7qrvGvEEd24iJAtH6KhatSXBrPhFmq2lEH5WiSs9RjqYBiR8wuFe0inTa123jf+gUwO4FoLtClrHIQJl+5QFWSarrin9XFLTdANZxkkw3qdypgvZWc1oD3X54V7KTqrS7NknYGQskEktmC0S93y9B1T0HlhLqdmcHdFawwUGeGSbkk7qzP4gJkONvaVQ+uxzS0nK6NCpJ7lvLZH0KorxToaMsDOPosrWzc2aNeq3M+MWkENb6apX0m1BnYPCZgDbqgwScxJ3XRwlfPSyuN22nnhU/ZhnsCY0nQoXNSSAAbEAKaN7mg+K07Kt1ODLoLZk9TokpF9OmSTYbcK5lRlRpA8UWIhPVGYAlwA1iP57pmkXIi38H6e6Z4Da7TBaHWP5fsi6llENIdJE+UJgRwmGzuL9NVAJMEakEj6pj4ahLrguQJcCbCTN1Az60AkalJ8LxmMwCZ9kHsGcOB2sEHOyASM0CDCv1CsYKeRpiWmb/AM81GuDgS5zQXbToCUc2doNOvl6EJanefjpsqj2KBzTbYkH/AFCDCuYyjGhcddVhy4ZzrsfT/JWNw5zxTruI66FVWyWCSGqp7r2Ik7aqoZxUyPdma2JndO5ogtEk6KWguBe0tmkJEWMFIHTJ7smTskLm0nEFwJB0dcK4Na5uYNN7wNk+iouYDo9pS+EOJBmRdOQBo4j0VcOebODQPWfdBxAcHmk4R/QCqdfZTGk/ae9Y4UxVaH3cfIj3Vr2nczupiQThGvbINJ8W4P8AcLpL7LGI1qkxn9Q4rf2KyhUq1KddrXS3M0k6ELPQpvrlrnF5dfLlFwmo1KuGxdKpUcS1rvLzCtv6Zd/tee7Y4GDMLlZQHBau0MV31UUwAAzruuZXxPd1ACJG6xI6z1G20Qs2OxRowxouRKlLEhwlZK9XPiQ9ws20KyFvpaMc/J/lj0KdvaAaCSHdQbqd9S7vMA2dwqO/p1mkBsKmr8Pim1KlyJOy6vZcPqVX8AN/nsvPUqY78FhkNXp+zqBw+FAcIe45iuffqEutLkp1hFxsl/EuMaA7qbqrEvLQGtdBO65+JqVabCalR2Xkmy6c86Ke0x/6x3UD8llY/LYpWVDUeSebLR3Yc24XTMSFFQTEiVb8Wkg72Wd2EB0cQplrUR8YPoqHqBrd5cbAbrqYSh9noQfidcrDhzhaTxVqGpVqbeEQFvp4unXdlAcDtKzRTjv8xv8ApWOqTDRtqfda8d/mt/0/qVlqxlbO4Tlnr4VsTfS0qS2Moe3i5hVF5zS10Hbgpn1z3ZJpszjlq25q6tGqMQaroLSIkbKl7STIWrCYqnnIdTazMImbFNWwzqZztE0z9Fnyy5W5PTIyt3bodYK1mLY0/qi6m13xBVOwrDcCPJb9L7aalek9uo9VMG0V8S0BuZrbmFnoYNj3OlxIEWncro4MswzXENAbpAHxKektrWQW/Dmb6oF8Nu/TVQ4hjmZwXAaAG5VYqsfDnWg7hYxBY7O4kBvIkGR9FqtVpwHQ4b8Kiq8UwC+AIsQYKx1Md3b81MkkblWQaa9Gu1he6poJlq4der9qcdgLNHAVmKxdbFn7xxLdgNFkc11N4nzB5XSTCr203FktMPaI80KeLqUTD2T5p6NTfTlbO7ZVbdoPIIS+lnv4yntMH/4hKlB5xNT74ltM2kK84Wg1s92C5Zq7nMrMA0AhSZfi3Z9aa1FzXgOsALRpHRCo4kZRomoVhkFN4LmmAGzcE7hGpRIIewzTInMNh1UYW4dvgEDeBO/JRfDWzz8PlylY8Obfwhwj/SwfuqX1DVqkmwO3AUUcQ3vcO8dJCw4SmC9xcDLdAV0gM1InaQ1o5Kztc3vzAgEfkrqyftWWMzQ9jnuP0WnDE4atkB8JMSDKupUqdWTMFV1WtbUHigAa8qa3mKsS3vq0uAIBgAk+6bA4cPxPhbBynK3af+FY+rh+/Dc13C4I0Wmh3dPGUS0/Fb3TSw7qT6bSHUyJ1K5NZnd4kXPwxML0LqhgtBknKBPX/hcDtR4+0FzXA5SZHSUjG400KjG03TBGsEboUq1I1wS9rSDAA0hZMPFZjmG7YlXMFBtqwaeCQf0VblXB9PvHMBZUYTzoo1rRiJEeFhs3zCpdTY12dohrLtAWvsmiarald/4vC23G/v8AkolEy0uFpGvohqDIkRACuxFMssASBcmNZ1P84VQEMB+b/j8/yWWVVWkDRyRZwjX+cqjCYeaIpg5SttRzWtLiJDfDbYn+FZKNTI4lX23MF+EexniM+ZKatRdkpszF1r3iUauK+8ylpJGh2Udihlbnvl3AuE9r6UPo1Szu3aEQNFfS+4LCBLw38/4VY+pnaCABF7qokh2aC4AQIV1jotVz6hLnku4AWbHUwaTHMbduq1d+wHKWvHQs/upVr067AwAAtB0CazJrLgabWBrnEBztzsF0GOGWS1hGlnrPQyCGuFohXVKLGMsdedk+t5Z8aGmi8OzuLQ2x/Fz+yxMDaz25i0Fr2uDTOit+7hga4EGxEwiaTab2uaZk8ot2tRcJvwhJN1W52W54QFRrtCCoKe0Mpw5Dpg3WdrHGi1rLEBWdoPim2mbOJmOiqp1YaC3UIegbTqBzS6cwOpT4io8uguIA4QY7EVyXU8s6mSDbyRdUfTrluIpgEnSNVpNjBizIYd7quhU7t1/hOqsxzga0NsIWZbnxzvquiaTSMwAIO4VVY5WlsXKqoYg0jBu07K/BVQ/EPL922H6LOY1sqzs1oAEnXjZdZlRgHxhvmudQo5mZWgWNgtFLDltZgiI2UuVubPTRUhzJzgjyXGxTf/VPMQMpPnYrd3D22aw7iVVWpsp06z3AZskT1/hCsyfE62qey6lKm2qazgG2sd1or9p0pJpNc4nmwXKidVIXTw/bhqzEYipiX5nnTQAWCjfFQLdwq4kdUaby0wdDqln8WVvw2Ew8jO4SNiV0T3dCmT4Wt6BYG0X1myy7SL3hWPol1DK4kw7XVca7z0IrsqO0GU8kSqYdhcW6tTbLRDo81a3DU8ufODCXFuHcug3yx53Vn1Op69hX7WdlL2AteYDROi5dSo+q8ve4ucdyo8kxwr8LRBOZwkLpcjjzLWeDwmDstiF12U6YbOU+iz4ig2ppIKx5N3hTgsbVo1A0S4G2UrvswtSo0OYwtHDjovLOHd1LHQr1fZOONTBg1IbrEK1leyhlpCnVcHEWCWsBSwWJaBDu7dI5sVbWl+WpTOlyox9Oq2HQTwVzqvNvq+AAQPNaBVbUYA8sFosFTi6LsLiDSqDw/hcRqEWVADGceqrrKvw1aSWGHAfiVzpN9OFlY5rXSDMq9tQGCdlKuuhhWGjhyGgAuvIXN7Rx9ZxGGoS17rueLEhdt9ai+m9tJ0w2PCvONqM+31qlQhoDso9E5/rn9qUezBEuMlDEdnVACaYBjaLrpU6rDSc9gJy7REqn7U97vG+lSHGpTa3ZHHAfScHHM0tvOhBXpOysUcVhQ4mag8LuSsWKoDFU/CWuI/E0/oqew3to4qrScQQ4fUFW+452ZXaa13imqQBtCBLMsVHtPkJTVRUJzNcGnccKky9wFSq220LKLadUWyiADayL4cQSTp4p3SsH4WSeSVHuAIaNSbdUCNYKdSXOmdxoQrJ8JftJdMeyFMDKCRLYkg7qwOefCHGDbX+dUEqMDcIACJ1PmswYOFvNJ2SDUbl6sXnu0e0mtcaWEqB/L4/Ja+jdUrUqDYdUDYnfS37rNU7QwbyQ5x1BkDpdcdtOpiKt5c46kpq2GdQdBA9FfGHt1nYrDVKTGtxDWgHQzM8rQHgOzMLTlEUxOnVecgEGBdbez8X3J7qsDk2PypeTXZJiGQXU23JH43JWVXd5JgOFoI1HHkkr1aGHpZqhs7SN1zsR2o+o4dzTAANnO1Wc0doOZVGUSCNt2/2VwBe4O0OUtdf6rzX27FkAl+mhyiVZQ7WxNN0S0zrI/ZPCmvRggNk6wf2/VOA5mHDrEkSVzcJ2pQrODagNJ5sJuDfldJxLGscL2g+yzmfVK54NIPaYGl0GuktDm+Lk7wkY/NDqIaHfiaTCszOyy5oBGmU5lnAah0ZGro9kSO7Bg3EC3Kra45jUeQA2S0eaJdLAHjeSBqeiB6lNhY5zLOnxX3VrQ8tBFQ35ASshtnAB7xJCSnXaxuXMIk5VuBq3hGd7iQBsNVSys1xc1rXDLrJiCr+9puGVzhHKyVGin3xIhxmB57pYHLyxrs0SHXPEqqq87G+rSpUa7uhmJOYZXHjhVU/vKOQ/E0xB3CSILHS7M0hr927OV1NzgRkOUj8BP5H9FnlpdlqNlu/IVL8VQoPEYoOYNBqQrg63eF7ScvjjcXVBBOIbaAb6Rt+6zYftGhVkF5B2karax1Kqz7t4JbcQbrNlVWwue2q6QXkRbkKNzGqYsNSrWgipI0c2/QpQ0PcHvdpcALIzVWy4Zxdx0Gvkg6u9ry4vgN1A0Wk5aQJqVOv/AAFlxDRVoOlvdaROvqFqAOrmoZDiJ0AKsZWL6mUiQRpwsTGd0JqPhp0jxT5LRSxDB4aTNdCTJK1iMbg6G2MwFZQq0G52Vnthwgt1UYcjJebjQLLVotJLmg0z0uEd+fx7NrX3mGY9+U0wxzYEDQqqtiGnKKQGYCC6FnbSiJurWsCjN5mmog7qjFU7+K7T9FrpiSpXZmbYKyljkvpuZ4mm3RVmpOpXQ7otCrfRY4kuC3rGMWaRYqNkuAAknhbuz8Lhq+MFOq4huw5PEr0FDAYXDOBpUWh3JuVnr8k5JzWLsnszuWCviB49WtOy6pKVzgGEuIA5KzvxrJim0v8AoF5/9u66SY0GTZU1MUxrob4z00WapUqVviMN+VqjGtFs0ei6c/j/AKC55fUlwgnQKyA5pY5ocDqCgKGbUgpw0ssfddMac+v2b3ZNSgLfJx5Kpp2K67nNpiXanQBZMQylVrMY6adV85SBIMcpiYywOVRVf42k7EBWuBY91N3xNsUlKkKuIyESA0k/z1Ug0YvDTQdWpjxEXHVY8LiGteHOacwuBMLsGWYd8ahpjquGynkBdWaYGkBaSxvr1m18j2/LccFZcU/KxhGrdfKSqW1MlZodadQpi6rXENp3IEE+qkntz6volRzWjmbgKhxc90kyUcpJujC25hELr9k4tpc3D1ovZpO/RcoHkBG2wjyWeuZ1MWXG7tPCuwdaWE90+7enRZQ+8Akjqurhaze08G7DVT980S1x34P7rjvpuY8tMte0wR1WeLfla3Pa/C1wzEd0WznFo5W51BwZOYGTqfyC5lFgfi2EnKZB6WErp1sxIc+7hYDb2VqMlWo6nVcHSA1IMS+o7Kyw3JSYqqa9c0ySWtOyrqg0y1jd7HqtyDRmJMkmTp0CrqMcAHSqw573eEaaKxtTMC12sLWLpGHK6NirHsD2kESBcSq3QDGxTMed9QiVnGZjjrb6qxuKqMIIbbg3lGrqHNStiYG+iDfRr97SLiCMpghc7EvL6ttj7q0OdQz5btdchVZHZM+0rMmVq3YtaXBgPstlOqThczHRUzgGOIWKmCaZbwVZRdlJP4UsRoNRr2kPGQn8TdD6JO6eACBmB0IVhaONEzTFOP6THvKyguqtpgAGe7GUdXHUrDjHOHd1QIBJjyW57GPfBiC+AfMSFnx1MNY1rzD4gt+VIqUMUMhic0bJGUS5wdiiSN76LJlfQIdEhXjHfdFrhM8q5/F3+tNWlhaoDaMTuQZt7JcLUecTSpgyacyfRZaNZ8mnRbd3C6OFpDD04B8Z+Jy1ObWO/wAk5a8XVgBwnQemv7rlvpAPe83zn6LTXa+JklVNIezKddlvw9ZHnn5v9trKaNSmc1IkK1mNr0wQ6nPWFppcEXTOa2IDbrjv9eyT9xidVqVnN7wZaZMZRqV121xRawURmZlEAaLl4gTWpNGoKjyGkrc58o49/kvPWO7VqtdRJJAaRBG6pw/dupltSCWmxmLLmYXFVKFQFnw7gmxRxFd1SoSSACZgaLF4yt89eU1sxuX7LnY/M11W5G0yueHEEui24W3s+K7KuFqSA8Zgf56LGGmnVIcLg5XrPN92V0XUqlN0S6CrazmEXcHDmFkqUQDIVYqCniGtF41m60bjR3oB8TQ5p3UhhIgFhOkHXyTMmqxmaHOOo6Kp7TSs67SYgqM2fteKNePC9r28FPSb3tVjHMbTG7m7dUMJTfVnKTki5O37rofY/CGU3ZSBJJEzqriOTVovw1Y06tnDQ8jlEkOfIcdNF020W4n/ANLiZFQCab9/LquZjMJVwb4qwBs7Yq4s6DO0yIe2OWiPyTUHZgDBIbcws7qpc2CbdF1eyK+Hq0BTa0NqDUHV3UKWL5M7jleO8zAE3gX8oK1YSrgvhpuy1DaH2JWqth2VLkeLSRwsD+z+7c0g2bvv5rMatZO0Wh+OeDrkH5rEx2QkP9CurjcO77R9oF2uAB6LLWoAjzV1MLSlolj2eRVVRzWEucRmPCR2Gi+eANV1cDg2U6Yc5sEi+bVaZteeqOL3lx3Sro9sUKFGq3uRlLpkDT+apsJ2Jia7BUeRSadJufZbYcxW0A8PFRgs03K6/wD/AA48XOIt/o/urh2U5tMgPa0jYNsVLVkZ6RgyLFOX5nAlpzDQhPiMMMN3bReW/X+FVte1oh7Z9FzdZVjK3gIErBj6htTBsfEf0Wtzg4+EQmx3Y1UxVpPBcQA5p56Fa5+6z3fTjgWUV1bC18MPvqTmjnUe6rXoeakUTIEIa3YOs40DTY4B4FpTAViS2pV7ts6Bc9pLXS0wQtJxbw0CowO4PK4dc5Xo569LmsynO57iBpJ1Weu9zm6eGbnqkfVq4h4A20CtrBtOkKOpNypPVL/t6ZnNMhsaLSA8fC4t9bK3G0adMUXEhtTIQ4c2sj3jG0rgSbApevL3Cc4grVe6jMJmFV4y6XOc485lYMT92WimyJ1JTU8Q0y2Jt7LLTJVomriWMbq8gSvQ0aLabG02aaD9SuThAKmNaJjeeIuuq+qA2wguFhw3YK2udns1gbG+3VaKOIERUc2QLly4+JxZo0y4ElzrNAK5T31Kzs1RzndE8dHosbisFXZkqVKdRuvhN/RcEA5vC2RNpVRpu1ymOiNOoWHXMFZzixrY134rLo4fs+tWAzfd0zqTrHQLT2U+j9kY6kPER4uZWt9UmBYDaNUxdDIyjh3UqQAMQJ381wa1OocXUAp+MmSHAWXdgRYErHigadYVTYOsb+ylJ9Z8NQcxwD3SSNG2j+foi3D0qdXxy1+0jXyVVR5NcZc4f0WgAlndimwno7T6LLpkau7blzHYQCuFiMRTw+KqupQ97j6A6rbi8Q+jgnCfHosuA7ObUYKlUkk7Kz+1m+/UZqlTF4oZqj3ENuBsFS1z2EZXFrhxZehbhWMbDbLmY/Clri5osrOol4sPhe2MRRGSqBUbzoQutQArMbWY+ZFiNl5YOsQV2Owa5zPoEy1wzDod/wCdE6n7YddoygBpmBb9Fbh25nzwPzVYvBjUzH5fqraL2imL6n8liK5v+IcW8ZMHSMGpd0ccKjCdn0WAZhJ3JQ7Wy/8AVKNY/Blj1E/urqWLonwgw7giFet/TfEn7aWYek1pygCVmxeGbVZA15Vzq9Ng8TgAqftdB5s833gwszXS44dem6jVylQHMNrLrY7BivTz0yHEcLi1AWAjrBXaXXDqZWljamOqNzOORgyjoF1KWCpMHwyeqz9n08tJsC5W8uIbLrQufVdeeZil9FmzQFgxWFHxNC6ZGYJCADDnN8iVJatkri30Oy7HY+Pc6MJVJP8A2zN/Jc/H0TSqZgIaVmpVDTqse3VpBXS+44X1Xq9ahzl7TyICsAaWOyVnPEX8UwgxmbKQ1rmOu09ES1x8BysYNgIn0XGqqbF73GgJuFZSBtUc2wFhuoabSGmncSR5pO+7p4pOBbf4ggZznGttcEKoNzZ6Y1nMy+/RM1xBNN1y10z9P2UrQJqNcJb9f5/IVEpm7hl0m3N4/b2KduVxaxwD2zDXbjy6JAQ9netByk+IDY/w/VB1YAWMACC/9GhVF73sksaC4bybLDjMbg8NTLsrjUOjQUmKxYZQc8+FgFmjUrz73vr1C92p+i1ILcVj62KPidlbwFQ0x8IVowrnwYN9FdTwrm6iFrZF8bWXNBkyVfSrOzh4L2OGhabqVcORsqu6qMu0q7qWV16Pa1VsNrDM3TMBBC6LC+vSa+m4PadL2C8wHzY2K2dmV30sS1gcQ1xghZvP8TXbpUgz4ZcTrkFvdVYikW0nvdAkbbrR3jpFyZ0GW/1KqxbnFhYXAuOuXZc5rTnMqZZa6CDqDoVHtLJfSLobctJu39x1VowZjM4344SAFlQlsnLa36raELy7ZFrgdvRQiFAsvooQBoLI5dxcIhTyRLzKemREbpiVVIJ0hS4Rzv4v4DoVFUgNKuAkyZPmkqUwWkJqT8d/bNRbBncFdul2gwUJqn7xtgPmXKYyyaM1ekToQZSydNdc+myauIl9Q+EaAK5lMACyLGyAOFcB4j5reY44UU+DCbSzwPNPEXRIBEIE7pp+Ex5I5Hj8U+aABCbMQigDGrI8kCN2GEe9O4UlrtoKDDiMK81HVh4s2oU7PaHVan+kLoARoZHVUCj3dWq5lu8i3Ef8qKWsLRoJ23WDFwWEEeQXSqNgSdVz8YQ2mTAPKsY6rlV5dVngRpCEQITanMd1Fp57dQBTKiEURWRdEIm9ko36aoLaFR9Gs2pTMOaZC39p02VWU8bSHhqCHjh38/Jc4Ld2dUa8PwlU/d1hAPDtj/Oix169tT+MVN2StTdtMHyXRo1qbHOpPZ94LDfNC59am5mZjhD2HTqE1VxmnVafwgjzFlr7E3KzYdxfWLnXLjJ901cnvh0EpcIZqzpqVKzpqnoLLaxdhm+IE6F35JKsNyuBufiVtBv3ZjUg/wBlle7M8jYILzDqcnVtkgsQTF07GzQaDqRKT8JHCKugOEQYIgrOW5SRxcK6ndk7i49EtYDOCNChEJzUHHopllrmifmUpjwO3Tg3Y+fiEFAlF0Eg+arqPyZm9Uw8FWeCpVAFdpOiK6AyFrC1xMtBMjdXU6YLc0A9CsdEh7rmFua6wb4hwY1XKukkKAwuHhg5pgHhX1aWHxg7uqCyo0eF42/cKurkMAQGj8XCtoYV9QtqlxIjQ6qSX7C4xVcHUw9qjZbs4aFVHC0iZyNXfaCBlItNwVmxOCpOcBRJa9wJDY8Jj8lqf7TYx5Zc6c7BYam7EBnwiDdq1VOz61MnJFQexVeDplzq1QyA1sN8xc/kF12OFSm1w3EhdedkcfyczquGS4S1wIjnUKl7crszdDwu7Xw7K7YIh2zhsuO7wucxzYc0wYXSXXl74vIVG1KRbmblkTJVjKrXUjNnDVaCBi8ASL1Kfuuc82F4K5T/AHl37HadX8VmfKVwGfORcaXVJPekOFh1TXzFwvHJTNA38I5Wrc9Rrjnyvl0BYQfFPumIgAzZWNtqbaH9VW4gSJJ6cLLsNN7qVZlRpAcw2vY9Fo7Vpl7mYqkXd3VF42I2/nVZ23bJtNpnVasK8PDsK4wKl2Hh391z6mXyWfxTh396O7eMrmj3CyuYW4h82kq5zd2nK5txKoeXPl5FzytSey3YnevoPLqZF9QV0MLh34sCpXblpxIB3WfD0BiO6NQgjPBBtIXoWNIc1rQJIg2+EWT6bgU6QaC1ggBunutHdkVAb/Cf0UY2JDSSCY9v4VCBmcQ1zTIbM9J/VE1S9ghuZslptA0RxFZr2mg6kagi5I1Vzg0CSBAs7qkLSbGxGjil39DhVcNRo1mOILsO83BOg81pZ2OykWPFdzQ2CREmZ2K2nDtq56b9Iu0/mi+iXYYskF0iHN34upLsKsF1CARBCrpPnWxFiOCrVnGmepSDRIu06hY30gCWn0XT+HqFRiMP3lMtYfELt/ZLNWXHObhe+xDKZHhmXeQXTqCXjjYLL2c4vzvDdYaJWvKRvLjqUh19UPw1I1BUDG5xoSFfScHty6FqmSEGDxOj4gBH1WoytIMSCfdLEuM/CLpxBFt072Ny3Eqox46kytQ8JDns8Qhczus1wbLtGneW2KzV6Ba8Gk2zzGXgrNjfNn7UYDDg1wSJDbz12XUeJEKqjQNFpGhOp3VjGXgOdHUyrGer79K3QRBbMrHX7MwlcOIaKbzuLR+i21G5XcwEpA8I5KsuM48riqD8NWdSqCCNDyOVUGPdECAdCd13e3aHe4dtTenJPUFceiPFQIiHOLT+3sVvz9JzxtDumhr48TgY0T4ZuYCmbg6JGuc2i9ukEfz6Jw0faKgFhlcTFtBP5rFdZFtVvcyG2tLnD6BHs/Dms8VnmQ2/7fqs2Vww4OYw50EeQH7rois6k7C4UWcXNL/fRY63MjeMFZ32jEOcTYTboAgys0gNPKWiJNQgSQw/t+qUtIaGO5JHmtyemOrje3Ll1HsFlqVgHEAhVd26IB+qDaEm5spiWr8JXbTqZ3tLgTFtV0qznl0u/EbELlZZOVovoratUtpFo8MaLVn7Yl24Fd/f4ptMGQ20rp4egxrQA2fRcfBn78u0AGvC6DcTWD/A5xAixjf0XPqOvON7qQyxlXKx+HDfvGiOVvxT6vhyOLQRc8LKXmq3IWmSL+KZUjVY8JiHYas17Db8Q5C9JSqCowPBBBFl5Oow06pbwut2Pi5HcPO/hW3J2oJEkoPptqUyxwkFMRBjQ/mpB1F+iDk4nDvpHM8d5RBjMNW+aejiaDBFNpK6kMNNwdBDpJB3C85Upd3Wcw7FSxrno/aTzXDGgxLxotlCtQYG0+9BIEQFn7kOpaaXUNGs4BuUAbQ1T1Y18ut1Ss2m2YLjsAqW1w8HNShvGYFHuA7Dsa43G5S0+z2mCXAgbgrMxq6wY/AgNNWifDqRwq+ynOZimvABay7vLRdirTa1paOFkwVAtcO7Bh1nca2W5fTnefbtOgNGsEa+iV8vY4t8MWAVdJ7KdPJUqg5TAm8hO4+INiWnUrmyzYyh3lEN0cDY76Fc77DVNQOktEhdSs+WAibFUvrOEVA2Q3ZXa3xJYXG4V1QAU7QsjcHXDxkLmgC+8lbe+78AtaRexlWCvoCCSrtjeSpQbUDIqR5wuH2jRc1z3xbNsvQZpaei5GPBc3IQDmfAKvNZ6hG16rKbQ14pgDiT6p6GLeTlc8unQq04APGYOAm3iTU8I2k5vizO+gU2LJVeLcQMrvaVkDmNN6Qve66WIpZ32GZVtw9EwRmjzSVLKrYW16RpkGIsDsuY5pp1XMOxXcLWMbDRC52JpTiXOi0Ala5rPUei7Lqtr4FjTq0ZSNNFbUwgyGCXG+65XZoeM1RhABdYei6vfnuw+CT5xKxUxXnywCcobpaQpUpl8lwDhqi7EU3uyvY8E6O0SOlpEVQD8rmn81MRQxtShUyxObwjrNlcWS0O2O5RqA1GG7HEX8Mgj3VDRVMU8+joaPNVFl8O4QJDxdvIS4ik1wD2kml/+lPlbllrpE2dyFnNT7NLhpEkHQ8Kjl9sVYyUW6alZMKCSLIV3nFYlztifYLXhsrJd3RdxeFu+o1PrZTGVml9ymiVU3FNNjSLfWVdmAbmiyxjqrdSDlVkaypp4Tr0VpxdMWLH+gQz06p8Mh22YRKsZrFi6QZU8O91XScBUa68A3utGMYYDxtYrMGg3Butz45V6qiGuAy1C4kSCTolOHqNeTlLmi+syk7Ke2rgGFtnTled5C1CoXU2uNiYn3uueKyEFzvECOhCyYqqJ7umPCNY3W/FFzmHIJcXEADgC65+QmQfCBclRCEJSFY+A1I26PpoijCigBCEE2TQiBZAAIQdcQEykIKg2B6o0x94zoUz9FGWcD1VjPU9OhS0Vhs4EJKVwVZEthdHmGfqVNAUAbR1UqODQTqeBuoCRKU6wLlRjXFtzE6wnDQBACBWtjUypEJgpYXQCABLlWHffkkatVmtzsq3C4O91FB9wYXNx9qMHddQC11x+1AGuaJcSZN3ErUc+/jAoiVFXBFFFERN0jBDr8QnSNMuPQoH0KYEhwIMHYpBJvsnalVu7QHeso4to/zWw/8A1BYviw3+h5HoR/ZbMO4VOz8RRIksio3pz9PzWWjDqeJG4yuH5fqs8fuFZsN/nVOn7pKoIe/kfur6IAfV/qIVT/HnPr9V0WL6d6YaTZ0C2yyOnvHAC8rTScG02u3IjyWZxklwteUGxrmhob/T9f4FQXDvIDTfnqrqTYy/+X5Kl5+89QqRZQkmBuUa5DgHDdDDkAz1CeuAKYA2EIqukYcQL8KOMsaC0wB/AhT+P0VpBaHtH4HWQVVx483zCVXXMtpnqtFbxUmu3VnZtLvsZRBEhhLiFC/GzA9mPhtSqS3N+Ea+q2U8CYgVCG6kRK2MgPvqByrIv13V8Yx51mZg6dNtpJ1klW0zHijTUJ0tK9MSLiQribv09RsjOPVKOhgncJ6cgQfRKW5TAtuFyv8ArfKNfZjE3BiliSGVHCm9haWEyB1HurcCT3BadWGFc++Uu2Kowwy4qs3rP1/uuznfrQefdcftC2Mf1AP0XZNlx+1LYpp5YPzKvP1j8s/1JgqppYgSYa6xVGOY2lWc1pEaiEspcTU7xjSYkW8/5+qlmdeTHF8ufGqKYJHJVzWgE224tdJTgRMWuf56K0wy4IkHYRoFi/XqnwZ4BJ/OVXUEuaREEzCfUWkHYD2VTnDvRIH7oqwCBJ1/JQg6TB87/wA0RZBIgTIBk31R/CA61rSY2QDO6qDUfMuPi8/4VSzLlge/0WmjWFN5zjMx2snb+FWPwLajS/CuDgdlZPXpm9ZfZezKfhNXTK6R6f8AIXeoQxgfnMluYkBcLsuqcPUqUarSHFwLAeTY/ou6y1OBfRpAH85XObLY36zVzWWYDJIEmDF/5KjR4ASSCTIvPl9ExMB7gSS0afVQNgsbm+EcLSK/ipFwh0GCPoUT4hGpbv8Az+aqUwWBos4OcTPnJSsNmbwYPkf4EC1GmRUbd7PYjhVNxLHOayS3YtdtH9ifZaQJNxpGm+qor4anVaA8eIeGRqkKyYqs3DVw8gyRBDbz1K2NMqUKDKFNzabCTuTqY/slpXErNiyrECAPFxdGEH/A4HhRSUWNYyGwJJJHmnMjZSLaT0QjiUCkkGfzUcYqNI3sQo+XNy7myrafGGzOW5tGv8KsGho8UhXCHghJTHhncpgI0VZJBBgpmyX+SeeRKgAkwIRVUkm1yna3KOpR0FhCCIrqDxHqFRULmOHQLU5sm26qMVHwbdIRVOLYKlIt1zNLfovNUGHPTpEwe8Medo+q9O9pDCOACFwX0w3EtLTOWuPYn9wVWuFFFhfhawAklwPsCUYnGVY3a/8A/SVb2eBIa7d4H/4uQ7uO1CzQOmPItt+axvvHT+qwA3AZzIIqeHzIH7K2lSc6rh60iGNaTJuYV+Ko0yWUmnw4fKCOZn9gmY4TGy6eLjfyKRhWUm+HfUkrNUpfdtdEAmAeFveQ5tnAW3TU8OK+FqsF3DxCNz/Ap1fGazP9q5lNs6iCpUcW2y2TBpYQZjzQDTmOYGeq1OfZe/S7BUgc9V+g3WXGEEwLbkLp1QMPhW09Cblcms/O4lOv4zx/V3ZUd+Q7QhdeoymylNNoLl5+jWNKoD+Gb2XWLy9oNNxjeN1y6j0cWY1NqFz2nuobG5T1DRDZGqyZXuFmFvUEpa1RtKmS7UDUrGN65eJfNdxjoph6hZVa8agyqnOLnEne6LNV1/Tjr11Kq3EUWE6xYhXB2VmZzh4dzuuH2fiu5wxJ8QBjKVpFc4mowZnl+02HVIlW4nFxm7sOLcoAcRwuexlR7y55LnHUldCpSOQFji5p/EXa9Y9VU2G1S2CREkwlnpJf9i5XZCAEzsUO5y6E2UfWa1kxsudhMUxz306jQZJiVzx28o106teqctMyJ1YEXPfQIaA8O3BGqspNqNZloPDaZMxMQrIZTBcXBzjqnpokuJ8Rus9bFOwdZkRkdchOarQZ32Cy9pU3VqTXt1ZqOis+sdX065yVW0qlEi5LvI9fJHO41KjW3DRIPkFx+ycaKTu5rXputr8K79OmymzvM9juW3KWY5seYOrOA+GoJCzmmWkj7yQbhpW8UKVZwy1MjpkAt/urHYCp8TKrM3UWKjXNxzKTTcNfUb0dBT0Q5jiHOLupT4l9bCODa7AZ0c3Qqg4lzrhuVR11ta5rRcrldoVclaiDxJ81qoOL3y5J2jQbWtMOGisS+1bcS4uDYVlUODJ70CdVkZmY0Zx4hYqxrQ05xDieRKYbUzkmXVHA8gkJ2uAYcrwSOqU1S8xlDf8AS0BKQAfCIVQ5e91kzsmfxkA5ZE9FW0kXWXH1A57Nw0KyM2u72dVw9Whkoy9zfikxJWphLbHLMaASSvMYHE/ZsQyoDANnX1C9NTOcZgZJ35WepjM9ixzw3xtLtvCQmz0spc4vbGoIVZpN7yXZgDu3T6qeGmJLnRxlWQzTReQWlxbvIS4imDJDXC0wfyUbWJccrTAuJKd3ji0OBzSgppNDg0VIBiw4G/qsPbb8mHm2Z/HX+y3vYwP7xskHW9x0XF7dqZqjW6QJj+eS1z7qM/Z1LO9xiYV9Si9pOZzoItA0VfZDw11QHousajS3QK9XK6czY5NOlUMCDM6rpOpu7khlyAqn1xIzA5Z2CvZWpwXAwT0sputSY5dRr5cSXB02Gyuo1KlNjQDnJ1aVqNRjnkEAjYwrqdKnMiArqeKkMNVl2wY0K5FUGhVc38IMeS9G5gYyRsvPY53/AKuo0jdXms9xt7Ixv2fEupu+CoJ9V22uHdls3dcdV5Kk4texwPwlepoDvKbAI8JzCeOE7Ygh7oEatn6/8qyqxtdxiMzLDrGqDYpm/wA30CaiyaTnOMOcbX2WJVcmtcgeqLR4iEgOaoSrWo+mJCEJkFAAmQJDQSVT3xLODKIuQJAMHVZn1YY+ZeWGfJVuxBdTeRZzQIOtir4s3qRpe6YARpkF4E7qjFFzTIcQJExsNE+FcXVzPzH0Vxm9fp1aNnRyFdEFVAHKCNQrmmRK04FcN+qqZ4qjnROwMq17g2SdIlV02ZWACDZBaCmSCflCcdUEQ6o6oEoAdFXVLgwljQ54Bgcpyg+2TzUA2kj0XK7WZ8FTgwV1XaLHjqYqU6jZ1H1Wox17ji7KKRAg7IquCKKKFERUU9/NXqinv5qi0JhYIDqhMoNGGqBlYSYa4Fh8jZUUXQ6t1p/qED8JjVWOp93UrTEZZHkSFM/a/wDhGnxO9FUzQ+StFgPNVN+ErUWHicO6P5eFnZcAbkrVphXCNR/dZqP+Y0H5gg2MMFsf1fks7pNTSLhaqTRNO3zfks9S1RqpDYcXPmE+JIDYG6SiYnzCNZmVrQTJhFJRu+ei0T4qo65lnYYdHIVsHvTeMwsed1CmInDlx3J/Jaewv/cknb+fqszLscJmLxwtPY5DX1Cdoj3VjN+O5Tu8nrCtPxA8hVU/CGzrMlXO1C0wU6+iTDkGmSPmKscNPNVYdnd0g0GYm5RFyjpPmFAiNVLN9VZSRmFtxZVNblxrnD8TZVtm1Iv4tFUZGKAj8P7rPGyZTv8Aqwt8WaTa0bLkdrWrU/8AT+pXaG45XG7atWpnlq3PrHf/AFYCVRUNiFcTZUu2W+vjlx6qyBlj9YVhAIN/ikazwkpkgt2Fp24VjnGIImDYHTVcXsIBEgHQxKqaC9xMa6dNVZWIa2RrYfz6pBlyiDJAGyC8SMpkfC2ZOl0wDQ4Nk6AAgRoqA4kWNt7xYFNJgE3knbqgaA0Qdut4/gSB1ShULqT3NPTeFaHvcQATBFrhVVAQRLYzCBI1J/5Qvs1bH1KlSmHBstcDI1N16emTLRmGpm3T/heNdLqrWxckL2VKZbdoMSZHP/CVJMWEEtOUmXOvbrf6KOcRnLXXFrjf+FASe7Ae21/pH6oy45RAdLvy/gUVACCBlBDRYg3VVOC2GEkEgg/VWGcjhlIzGLbfzVKHWhjZJfbgIHcILc1tWkDj+QkAtcfFE2mQmcTlMlo8QsPMKRrJgz6wgVhMNMTIB4vos1G1uFeDmgAEwN/50+qz0yO8dGklSrGgXCD/AIHeSGl/dHXX/lZVJF7oEqAQwcwkdOrfZBVXcS7K0nMBPmq8GJM3lxJMqVqgmYGm5U7PgUmwRBAAK1EroApwVW3ROFUMoJ+qGiI0UAB6IZzAEaJgq3WKCZjqstXMHFwcZButJFvVUvhxcNIBuqI4jupmS7debxINHtCoBYFweJ916NzQKbo2C892uT9qzH8Jyj2B/VF5uJScKMuFhTrtP5/sujWw7aXaAqxIFMBvnp+n1XMbDs7ZBFRms6OF/r//AHJsRjXvFIXBAbPos5/tK33tmQKVRzm1KpsajphWtqCLqnEDu3Opt/C50e6DnjIHTAK7T44dX21Cq2IhW4KuG4po0D/D+ywtIc2fomBIcHNMOBkHgqd8eXNic3Lq7G0u5xNRkED4h5FJh2mpiGkyY8RWrGgVqDKzW9LcG/0MhVYb7vD1K0dAs/iu8zT8npn7QrF9UgaCy5zyRf6LTWdGhWV7pOiX66czIXVbMFUe1stOh0Kxha+zz94WnQqdfF5+t3f18kCAFgxZfYONiuq2nEWWLtNsFvhMbFc59devjnjVEG6WVZhxTdWaKpIYTcjZdHI1OoAIJsuxhQyoBUIa4NbEm1/4EHdj4YXFR2RwhrxcSkoUanZ9eXOa6ncTtm6qaWVsL3ueKbmkAGScsAmL+aY0s1MuMjxQOv8ALqoEmrLYyAWEaLZh2gUszbEG5Gp6K76Tni2sT6NSrTLaFIl5sHT4TysTuxKlOiatSqA4GwaJ+q9IBlaDMykrtD2kAF2YacLNuNzlwG97SaGl5JiZUBcTBK2YjCVKlUOptnKIN1WMPVJjIZXPi+U10+elLRH7rTSZFIuI10RGEqC7wAJ51WqnQaYdUcCAbt6LrzM91x7u3xjNR7No1KjXOo+RFh6roOpSWjRoEAcKykZboBB2RcYBdwN1ltidgnueXOeHkaDRPRxFWmT3hIYNQRdWOc6rSLG/EReOFx+0MTAdQok5RYkmZUa5/HbT47tRuMrik1gyNnK7clU7WVeGwj23e2CVe6kWugKVcSm8tuEK1UtGvjd9FaWto0y9223JWF7y9xc7Uo7/AIuNu1CbQnl9FrXOacrrhCjSNas2mNzc8DdW9o4p1Sq2jADG6K/U/wCReZfSs4lqQ1wbAEpW5Z8QVgLR8ICPOqcajrfCFmrmSANtVoxFXKdbrEXEklbjHVDU3XQ7OxdTD1Q0uJpmxaTosJEAFXiLO5VvtI9UT37GkOi0gjZUPblOWrUf5JOz6xfQaA2wH8/nVaSWOBD2k332XD40jIdZgPUlGrUFMZZ1so14AythsdFW1onM4ydZRDtECSYykz1XmO0qvfYl7+TA8l6bwtZAJ3ndeTrXeei3wlWYBwFYtJjMF03NIZIMriBxY4OFiF1MNXFUAzfcK9T9tcX9LqbqtYZQxrQLQ/dW/Y6zPFDI/wBSUsqfFTnrCDRVzeJn0UdAxDqdIhjhlf0Mgq6jmsQbKVGCowAjTlSmcggnRBqJIpy4rzeMqCpiHuF5K6HaGO8JpsN+VygAXLXMc+7+ltFkgA7lej7McalMOmC0wRqvOgwF1+zqpp1ADEPE3TqMR1iQdeCJjVEuPdEt1abfQquo6QBNybSUtB0942fiBidlxjTl0fhvqrhOgSNAFt1aCAJ2Wn0wdYAKITmMwm0HmoqqvMED81kFQ1XubUIbfLlWypqAs1VhbiGVKbcxNiAPqtRy/Jv2K6GanVFOoJaZZP8AP5dClTJpgAauEydQFoqtgZ3H4ot1SNqWsLggR6q6xOf6lQOeSHwNBb6qzAsd3r3G0rPUquJBJAnWB0W7A3cba8hFuY6dP4UQINkKYjyTlVxVvGdzQPNEWOkKtoLqpqA6eFXzKKW/CYdQVJ6KQXaoiAyYGiEQLpwALKsAvPDUEBk2EqVB4hOouVa0AaJHAEOndBU6Qs1Uy1wVzQ8OeXVMzSZaI+EbhU4hvxHkKxnpxXiHEdUEXklxJ1lFriGuaIutPOCBRQKICqpiVY60lKyzYQMeAiG2UAhMgB0XRxdFp7OFXd1JrfqP7rAICuo03DC1aj3eEthgJ/qH91Z8xL9lY8xyNO8XS6U3eY/VFwNwNj+aRhAcA8T0G6RuL3ENpBhi4j3WZwLHTuLhPILi+Br7KVBmcIOoQa6DgQw8T+n7qmqPG3mP1QwzjYdRPkjVs8FUiYe7r8hW1ATTvc6H81VSMPIGyvMw6Tec3vf9kGXSDwVe4hoY8XcDEchVFpbmbMwVYP8AKkC4IhFp2wKhBFtJ5V3ZV8Zk+YqjMHuEbESm7Pdlx9M/1Il+PRnRXa+qrePEmafCOi05CdFXTGVobxZWnRVA3lWJVrUyRidSrFGJcRlI2KH/ANXP9P7KwtzhyomMSwHQ2U+e1/8AGk2g9Vye3W3pOjldRrhUph4mDe4XO7dH3NJ0fihWM9fHIOiqPxt81YdFW3/MW78cuPq2iJc3r06Ji2YIgkgbJaUl1tmzyrCQybSQbCY0C4vWpqPaA0HSdrhQloJBIJvADfZU1jFSDOg2V7IF2yb2MHhAfEYc7TiVGXLSSTxIRYZcJBO2+kIsEwbQI1CCxrGiLOsAdBuqzlhsx7cAKwED8Ldvw8FJWA2Ab5N80FVNg+2UJmRUbIjqvWUmHK6wBLcuvn+68tg25+06AuQXEjraV6dkjPAHxDX0QXjMa0SLN45/4SEmRYGGymBLjUAAlttek/qlcCHGwHw6HqoI6A4WMMG/P8n3RYCA0ACQJMXSZnmAxs5nHNOw/gCMu8JcCYMEzr/CiGMRDiHAzfYJS5obMyQJ8I1hMRDmgD8WvooCC4OzA6tt/OiKrPxRBMz9Ij81lIiq4DmVqMviARoZI6H+yyvtXdaNPyUqxewyEYhI2x6FWKKUEx6wkeYGkqw7hKRKDBjgwNLgB49eZTdmwcM2dLg+RKxdrYprMQ2jpaT6rd2bfCsds6R+q1Ga3tnfWb+asCqadD6HqrQiGRGiATDRQKleJGiZAqip7ixkRc6DlUuENIN7X8yrXmXyqnOIO0zuio6e6cIXne1iTiawgkZgQfJsH9F6WqW9y6o4EQ0zBXlCWtbM52E3BNwf5ulb4mpQZ3rabmAgg5XfoVKzXChTLrOMi4i1oVvZ9cUKzTctLoE7dfqVu7YLatCm9urKl77FRbcc57i5+YmSdSqYl4nTYK0/EPJIL1h7Ls8zS0CESQiBTLR44PCQwNJKqNmBeatGrhi50wXME/T3/NUV35KNKkNhmPqqqb3UqrKjZBaRt7pXONZ5dBl2gXOc+PVrVuyJXwrqOHbXqts/4B+qwkBdjtmpTdRpMYc2UCT5CFxlnddsxCNhK6eAwbsgcWmYm3CzYLDuxFYNDc0G4Xo6jS4BjACWMgiLyFnqtcz2qZh6hElobpqq6tJrmw9pDrCSf0XSdULMOARLogAixP8AAsw8ZDnOBcTJkafyyx8dOfc9uHi8E77Q5lBucf03Wjszs5xe8VGiC3U9V16ZBdU7sHPFp0AS13Fjfs9MGQ2SeVrWPH2poUa+EmhSPe0ZzNuJb5hTtA0wxzbS8yW/zyVofU+Gm4yYm2nRZajKLHEF5e8zciykOpgYJoDA4EluoldSkxppttqFgpDKyAugxwLGwku1b6no+QGGiwAQcYcWwZy6pnkhvhInkhUVJY2ZJJdoFb8Z5mpcGANQmazLJIg8qt2Zzm5CAevonqCrq5wgawuX4P8ApGuvSt4awuf00VlBpdTGYgiBEKrLmcGwYGqvpMIacxu5ejr+OfH/ANUKVUVJIuAdUXkHwEZugSB3cEh1+AEucPeCJg7BZbxViapoYR1Vk5oieq4tCgcTUyAwYmV0e1nFtAMzSXO0Gy51NlSmA8uLTq0hHfjqczP66LQ7IGuFxr5okAXMADcpMNX75hLhDmm4FlbQHesFSo0X0adlzz2x1fH6wVWVsTUljCWDQ7J29nviajg3yXRmdFixWIzPNMCWN+KDE9FuRL/yOsyLMNh6dOXsmXCASdlz8S3PjTAsAt2FxrazcrwGVONj5Kx1BtnAAOIuUvqOUt662uZG8JKtUtbYCdgt1Wm1oJIlc6u4tcRAGZTn2116Y3Oc9xJuVMpyzyrjReGzBAO6qiJuurkLtEWOsAVAZ1Qyy4BRXY7Jxb6MsLc7DeBqF3KOIZVHgM8g6rh4FrfEQLwAFvyCA4WdsQufXOtTrHRDjwUcx4Ky0sQ5tqunzBa531C42WNyys+MqmnRcZvFl5PFtis7lei7Uc7K1otmn+ey83XcHVXEEGb2Xb8cY7Z1bRdlDoMOJEFIRDUGgm/C6ubo08c5stNwDEhXN7RANwSubRtUII1CvLBrCxZHSdVrqdpZhDWwstTFVH6WCpe5reFUahOhgJIXpHmXXTMi5KrguJgK1rIb4iAFtzMyTsteHxLGFufM7JpCzMYaggQG8lb6XZbnUwQ6HxOXKpVdbDhlai18EZhKt7lpIMut1WHD4qrhQKeKokNFhUaPzC6VN7KrA6mWuHIXDqWV1mVyWNawXdmKjnZj0SMhwhgEp20nb2VfREGNkDJMlOGQplO6gpqZicw23UBgyVY+QBlgbXWSu9xORgPhsSrPbPXU5hXvL3gOExuEzW3mBlFzKrLAXzmjY3vCR1QNfDSSAIlacL3hyQXuBaCAJBW3s4GBm1Ilc+tVfkAdo7garpdnwHNBuMsBCXddNmiLiGgkmwQbAGqox9Qsw5A1d4R6quZ8LDqDTubn1V0dfoqcO0spgdArgQUEE8hMJ5+iEKR0QE6GSEGifLZSL3ueEScrZKCOgCSlbJIJEDYKNaXGXIv4QVDnRUVgahjQK8RAbIJi4QrRTpuqHRolIleerNy1XN4KVCXOe8v1c7MitvNfqIHRFQoit/wnyQabIv8AhUYgYJggEUAVrADSIJ8ZGZtvwiZH5+yqNgu/2U1gwNMva2cpOYjS5Qk155w8V9HCCqBJq+GZ2j6Luf4hLcuFLYguJsI4XEcIMlWNQzQ3uXyCCd0urmp6bQXEbETCTRzPOFQ9JuaR1CeoSQ0kaoUPi9QnqtzMPQx9AgVoHeCP5ZXgE32yT9Vla4DKeFrbmsNjIP6fmgzn4nA7p6ZPduI1An6pXjx+aegQATxKimABNI7u1SUDlxdM/wBSZhtTOwcq9MUzo8Kp+nrH3vyi0c6FBvip0zy0Jvy5W3IQbX1CyUM2QHm8LRWdlpOcOISUwHMDmhIlNTdDoO6uOioPKtmWSlIjVTiwGFrpA/dXt0S1vEG5CM2aLmFFzRF2rD2xTz4Aun4HB36fquhlcNWkCdVRiKfe4SqzlhA89kLPTzGyQHxJtkn4/Navxy4+r2AioQeOYVriZjrOs7KqjPfWEz081YBMC8EDjhcnqUPDTVaXtmBsPNFgyxJiDuOnmiJLovpB31VgDQLhu5uzhAMzXZQ3KTDROU6hCCYIAA101k2VmUNMZRrs07hK2wAM3hBMoi5aNfwlF8hhLjJzTYdVIiSSdt+So9zcxbY3n4vNFDBOFLtPD2sHZfcQvStNz4Sb/uvLsdGMoPEf5jd+q9LTcHF5BN4/ZGV4kNJDR4nX94QcCS6QBFhdQEmmAGE3mSR8yD2w45oguB16QoqUyx5JAENGnE3/AGTEAFgLQSBMjnT9VUGtlxYWmXaeVj+Stsc5gWb9bqoUCXtHhbq4k/l9fomaZ7uXajN/PdWEgE3AsqwQKlMBwgMP6KBXEFtp9uoWKr/7h3p+S2Fw7uJMgDbqFjrf5xPl+Slai5kObBTtJ0OoVTCrCCQCNVFDVzr/AMsg62qgILnef6BBw4uOEHnP8QUy3GNqRZ7deo/gXX7JBPZzQNmtcFi/xGAaNEwZzG639guBwdHgsIPoVqM1tYQVa0qhzTTeRxceSuYVUWBEJQiFBEriilcqK3GZVRMOBmLhW7pCIcL7oFxpLsJVAknIY32XnKFJrmvc4GxygH+dF6mqA+mQWey8rVnB4h1N4cGEy2VmxvmttGhTIJDQI4CNSiHnJDocLwACqqFVrm5g7wnRV4msGkBrnB2uqzJdbtkgYjD5GZm5pBgghZTOdpbaCIVhzPnM4meSq3eKq1g2uV6JLJ7efqy306DXHJL6cHnYqp0ZiYVtQh1Mag8KjUdUjItOVwJMA6+StwVNr8aB+CSdPZaMP2cK+FFbvPEZhsK7D4J2DeK+aXmxYRYSsddRvnm7FGJ7KqV8z6b2wXGzgZEFZG9i1mtD3OGtwNl3aVcVC/K4ZiASB/PJRveOrPdlBa5s5ToQueu+e/bFgez20GZw4vLrmLH23XTc5tMOcxoFQ2idEGMDmmrUOXLGUjYeSpJcWmYg30lZWr3CHjvIGeWtgWE8qruHU6jRAED4jZoSw7Elrw8ANfYnXUK6pRaGgueBm2LumyYfPSpjhdwqOabnKTMql1UVe9cwHM92WZjT/hacRVa4UgzxtHv5KqlSaGl4eBlvAEkEmUal/pqTamUFo+HWYk+ax4iO+IDGdYHwrQ+s2mCxmcPcLuFz6qmqxzWnOJM2dynxL99jTs1W0qxljW3ymD5Hf81UPhT4eWMD7eJ24U5X63B2YmNRpKVzBTzG19bKtj8tS5MONlW5zalV1MuzXJJ/ILdnpmcr2y10qttUPYcvwzrOqFWtlD9o+E+kqURlpsvNpIhc/wDjTOWfy+4vpsAaJuZlM52VpdsLqp7w2l4gRKV7oZ3YP4ZzOldCcqMQ8ik54dOmn84KNMtD2tYXOaGiwGqzufms0GCforKBJzE5zeCGo69TIvr0WViD3YaW/UKluHaXQ05ejtFoZSzNnvSPNWOlrdGO8gjDnVKBpY5oAaW1GHNGllYw3A0glXVCC8eFoIGyzus8czdRjvrUrVBSpmLuVbMHNI3h7tSUD48UwbC5WwK/HNlZgmMAJu+ZnhWVXGWNaNbq191nqEh7J6hSt8/VVXxXIJA2XLrT3hcRciT7rrGXaf8AKwY1ga/Lvupy13WWpXJGRp8BF1nPA1VjwM4G0pS4NEAXXRzBoymS6E8tBBmVTBIR0sg7WAINLP0ha+80A9AFz+zpNEALe1mVpLjflRDOeALrXgq4qUchN2fULm1SQsxxJo1mOBMA3HIUvOxZcq/tXES8gHwi2i4kyVqxlY1CTOt1jV5mLbqPKegzvDl5VRWnBRnOYwI1WmW7EUqTMBmIioyMp3WN7pZK0Y4vfTY0EhpNgdTCy3FEg6rLcUEeJHKAoT4kpK0wYvIESpTbmdE3SLXRpANDzpF0HR7NwRqOY51mTYHddwNiB4fKFyeycWS8UCZyjwyuu10iN1mtQS0vEFrel1S/Bwc9E9zU/p0PmFqa9OCHRyEHnhTBTjO3Qz5p1FxfVL3g/EITSNigQCLqu82CKNee5drouXUrNNR8zBOgGq3Y0uZhHTvZc1viIIEEaQt8x5PzdXcXNeMpinHqVKUSAWjVTui2c5ubhOKWUS4yY1m4WnOSq61TvH2s2YXQ7KcfCLkjlZBRAaZsTyt/Z0CoAREKVvmX3XU1bCy4toIbJuXaLUI4CzVSKmLibNEKI0kXUhSZJKYBVEGiNzooAibWCAWFh6lCMxvoiRATAIJolI1TIG6CgUaYqurBvjIyk9EmPl1NtMbmStIsFW5odLnaIlcHG0wypbYx9FnV+LeXlxPz/oqFqPP19FBFRVlVUMe6LYIQq6DzQagsCIUCKAO+EruYR+XCU2saS4sgDzXDd8JXYw9Wizug6qABTbMO6Ba5kv1LbPjL26X9zhxUblc1rpHt+y5dQZ/CLldXtqvSxFSmKTw9rWkEgrk03EV2AXkRHKjSS4P0gtHuhUbAbUGk36KyplFQGPD+ilOIdTddFHD6+oVpHgd/r/QKjDnxEA6FaD8L/wD/AGH8gqM0SwnqtLHkMHQh30WeRlN9x+q0MM03Do38wi0lYZKvUH9UMOAXwdCLp8UA5xdvKSi4CrpZQGQWtZGjiJ9lXWdlrF3BlWGRUe20i/qFXiAMxvrdEerw5z0KROkK4gDUrNgf/aNDvw2C0AyLD3W3IYa+W6gi6qwzctPKb5SQrjmiPyWfB1A/vGmZDzqNiUguLZQEgEbJzcwEDcwFQzQqqdJlSoM0+F8j6K0LLUeadU5d3c+Sl58vUJ1nutZcH0M2UNJcJA80rReDwmqlxoy4ASW6Gdwl/EPJZaryVZndVX0/lcW+yrnxjzV+OGXHVx/WT9VmJhwK6fpxkytNKO8aZ+vmrMzQWkiBA0tsq2iwbEifJWupthsQZzTfquT0qGhveOMjXhOC7QFx0390jyGVABckRefJWTuA0anXiyBrEeJwPUuPoVCGAyHN5+IoDKDHWDDulkC+nsXXAnT1QNIbpUBjh3CVzpbBdM2nNr/LpM7Ym4G2lkpfJ1i3KBXuJLGgwAZBtZeiwVXvGGo4/EAYG0Gf1XnWDPWABgC5JXd7P8PhkZSYHkf+FUdKmSGPEON5AHEf8ovPj20Ee/8AdCi4ZwZJzNvHT/lMbhtuWknb+QoAzLUp05I5I5t/dRraZDjDbuiPp+ijHCbkeEfz8kzdGB2UOiT/AD1QCQ1zy2NAAP55qOqQ51x4WyOuv7ItjKDnBDnTP5fogHzPiF3een/CBagDib6kDTi6xPc3vnSd+VscZg65iTffaf5yvNvxrqfaWIa6tkYHkAEKLHdbli0phmGjRHquUe0PD4KpJ81WzFV6jKpLgC1sghs7j9JUxddkTmdYXvf+dEj6lNgl72NHOaF5uvjMUXOa2o8NOwtKoxBpipUDHSJMeSYa6/a+LwdbBVKbKoL7EQDqquwsaxtNuHccr2kls7yuM92baFKbHuktBOXjZX4n17Zzm1mAtMvbtyEWGF5bC9pYimAHk1AND+ILsYXtNtUXBJGtrhNMdUFHN6ysrMTTdo5P3zdZEKouBSuKrFVtzKqqYhjR8QQWl2ySpBBE3XOr9q0aZgOzO4CowXaFat2kyiYDHgyPQlB3hm7mzSLbrzXbVJ5cxxqAtkjLFwvUs8VJeR7aL6eOIBMDZBdhsaaNIUXYek9rSQ0uF+VmqVjXq97lyz4co0CzsxDmuYXCcrs389lbQdLTGgNlefq9Z4+lsEMOX3VVEjvr7hWuEiJ+qoA8ZXRxbHutG6QFJmJib9UQdwg7nZzw3BsBImXfmVZi58ABiToFzcNj6NGmGVGuJE6AcrpitmdTe1k03s1Bvf8A5XHuY9H4rtK2llquY1oBqCY6fwq05qQDGv0b4i3iVRWzUQKrHF+UmTuPNWsqZaToF3AQ6NyLBYdb9WOoOIDxVc4Gzgf2RpPY1oY1sd5q436JaIeWmqXHvA4h4NlGVadPDtJaHPbaIuLonu+jOYaNO77mmQG87qphY0Nz0yYGZx6bQlbUc+l32ZxfmywDHVGtTfVHfGJbYxcHqi/+UappU2mpQMTAjcFNQyU8KH5S57m3Am8qjFMaMjWNyvcAS2bC0/urnN7sMpeLu4kgalE+m+GkHGjDpsDqfNY69c1gDlLQTZaauJrRLB4Zhxi4XPN8QA0y3LIjaVL8SffbQPgTUHg0oOrHJSLQs1NxZioBs7X0Tluuo912FsSbQNSpWow1zqYgmCfRZmOJaCW/A4nyK3AgsnUFbYtsZntBpmTq0WnQq1oGciNGge6WoGimIFxZSgSS8nc8LP4pnNcu7vchi2XZje+k8Iuc1p4/n901j+azYgEggOA81pue1VR47wnIBbxAHb+SlwQ1u4S7UaKVbDKSJIi26OG8LIgyduVK6NReSfFTPoqnNEw1tRwPWAtDCGtgPI6FspSYdna4l2njsEZZS6CTEAFJVMVGnlP/API4G8qp4c4hoEuajlUwomo958gtSqoMNNkHU3KsSkAmFmrx3rS6YP7LTZYce4+Ag7wgNWuKeaNQPZcytVAJJNyrK7g2SblYqjS5wi5KsgJMwRyg4S5FzDTaGzJQ1f0VAa380HDfomFr+qDjEoOngHZCBs4fkug4gDM6/AXNwpAZTlbbuuSiK6ri4knVc/EAk5RvAXQqWssj2h1YX+EShGbEiHQNFmK0Yt2atYQIWcqgRK3dmUy9+kxdZWttpddXs9go061V2lMWncqVVWKf32NgCAwRH5qmtTLgYM8wtWC7PrViajhlYd3b+QWjHURQwrqbG66k6lZbcEmDCVO5hDjIS2BW3MWtM3C3YYOdAEEAaHdYmy49F1cPDKAJEliAUC3D45jgDBtG4XeaTF9d1wiBW7SpholrLuK7tASM77AmwQXMAy+KxCdh1GnCrbLnElMz4tdRCiuVCKii4PrptdK54AkkAKEz5cqtwz6ieAiM9djsWQGkZQbCdUzKbMwa0ARaRymeMjclPKNBmA0Sy1jQA0lac/H3tLWpB9QwJg3JT5czZMyNJMgJS54hsROqYMkg5jYoeMI8jMJIceIWnB+HEMHQqlzWh5gSrMO6MRT80hZ6dc/CQd1ioNIqFpudJWyZEQT6LOGubipymCReFXnXgeKytFlXEOsrNVURRSEUEhFCROqhcB/dEQpVCS7QGFNLanhArnNa8Nc4DMYEnVCr8BGjQpUph1RrngEtu22hQqHwGdghXCrtllU8OkewWZa6rgRWAOn7LIrHDtEUEVpglUeGeEjVa4S0joqmhBYCigEQgiiiiCLIDlqNdFhH7rWdOqyGGxmGoSKvqFr2CoBebxujSdFW+toVLGkuyg2Ov7rU17KYhouB6rSkfT7msHt+FxuDaFYQMrv9Z/RVVHOeL2EIteDTyzfNdDCScptuFpo3Z6D8wsrHfd9SRC0U2OcyXOgRcD1/ZFTEm3qPyVLPj1vCFQN7zxEki90+Gax1SL3IQM+RWqHgQFXWEVIPQJ3ZiTe5GYpas97r5KI73Y+KGIZlLYgRPULo20C892O0uZULTBZUkdLLu08zgDABGsFbjn1MW201VBDmYwOdOV4yjzF1c1znG5aeioxTXPfTqMBPdm4A/nCI03iyjRF+VEb8wqCEj6TDd3MphPI9kepiyhiqo0wGtJk8uMTBhMZETEwo4w2dwQT7qO1+iivN9rNjtGsPI/QLC+wW/tc//wCRq+TfyCwOE6rf6cv20Uj4Qd9dPJXVH+EyTIB+LrCz4RwcQwjMJiFe0uyTcC17arnXpnxU6TWJbmtwnD6g0m/Jj9EHOip4jM7yVYCyNB5F3soFOZ93vaQOD/PJSdYIvYwfUougfL7pfi108+qCE7fqVnLs1R9xAOs8rUSC0hoiJHxegWKgSe8e6JeZ180F2Ek4prSdV3KAcxzXSAJE9JN1wqFQUsQHul0bASStDe2agefuWGmbFsmfdVl6MPbmEvAIfBy9f+QrXk5XSDbxX/nmsWDxba+FFSB4gbE3kW/QLcCCfCC4OGvH8lRVbpbmaDM2KsLnAkgEmwEg7/wKuLU7iRBIHlCcvBgXu6B6f8KAOzMpGHO8LYAAPCJcynmIaTlbOn84QL9riXRp/OFHTlkhxOYb8FUV1pa9roJMZRdeNx7y/FOcbZrr1+KeG4vDtMtDy/6BeS7Ubl7Rrj+pFZ0zHupnNTcWuiJBhKFEQXvc90ucXeZSlRBBF1OxgwMe4jxF0LlldPskwwjkqdfFn1034ShVnNTbJ3FiqDgmNZVpsc7xgC94vK1lzWNLnEAC5Kx08fRNZ0mGuNi62y5TXS4oOBxVJv3NRw6MfAWZ/wBrpPJLqwcNTM/Vd4EROyjmteLgEdU8jHAGMxRdBqOI8tVow4e7C1++c5x8OUO11XVFKm0yKbQRoQ1MROt1fJPFwSx0QKJ9klDvKeKY9gPeNOh4XeLGnULPXwzA5tUfELE9FZ0YZ/aFWnTzVKjm2sBYLz9etUruzVHl55Oq3Y6rLMoOq50LXMO+t9DstGEIDXCN1nK00MuQFog7rpz9cevi9zgG9FnaSahMWVzgSCbmOFUAYMG8rpWDjoE4F1W114KsBhwnlQSrBghsWvddjsysTgabQGgmRmI1AXFc/wDJdXsol3Z7xBJbUgRtoVjuenT8f1txuWg3vc4JcMrhyjhK7HYcEtk5QAOf5CauSaEOyveBcOvP7LF2e9/32HrMDCzTKYsSuTtHQhz8O4tEHMTHqqqVFtTDiXNziSQRbVPVmlhiWgvzGXB2yQd2+lLi5jg0ZhFio3+vSUXmnSM0wW5yNLhO+q9zmuojUQW8AKvvC5r2F8gmxG8q2nQJDC1xgeI8IXPqqpSP2o4rMXd3qwCdoS4OqKjnAh7hpbbzWkUCSYADIhreiqr93SqAU3AVNDJ0CuMzqYpxDqdIGmDIAv1KxYEBwc+ZBMA9Ak7SqENhma9gdj1WnCUgzDtZpAU6XmHJvAQoMDqzyRMAC/VBzXNM6rVhWfdA/N4jZZi1UwvZMNm4B6raATTbmsYuqWHKyTrPsnrOJZlEzqIXRm+6rdmeXBoJkyE+GBFIA66lVB76eVwBPpP81VtBpawk6ECPZX5HOyeVqzMJAVNRrwYEFqtLRBMTN1WZm4sDA3UajNUDXOsDI06hLTMNE3jXqtEBlW2rtisv/wAfms9Ok9ukCYjNU9AqK9QZgJY6NMzoIVtNxNJrvvTI2Kz1iXPAJdro5sqs1To4H0Qe8B7ag1Bgp3C5HIWfEDwy2xSOTUHD3UJ4WahVztaedVe6UwR7wGklYsRfJOtz9FoqiQByqKnjaMpB1E+io5mKeM0KumYkkpsYwsq+aOGpy64ndUV1HRc6nlLmGnuhWJNZw4MIaaIHc6ZhoCrIsnkRJUa0uFtUHSwzQGMC1EkBZ6EFrCNIV7rBGWTF1XtADVnaX0mF5LQ5xtNyr69N9Sm7IbzYcrFWouZldmzAjUn6IsVuJJncogDdLTDnvDW6ldzB9nMAYXDM4kX4VGDC4SrWeCGkMnWF6GhhWUqQa9rdiQduFdRptYZAsEwaS4FwndZ1rAc8wYnz0XM7Qbu4QDzqurUgbLjdruc17c2pCkVyMU7Mbf8AKzAXhXPfJJnyStaXGANVthfhaYe4iJBV+GFWs3uWfidEq3CYKuWQ1sE78D9F18LhG4cNsBlGo+qBMJgqdGGgZiLvcd1sdcgDQFIHANkauMlWNs2SgY+ERuUwEFpQptLnT9US4OqtA0EqK5QNlCqqbiDlOoVwXB9chIPXole/I3+o/RWOIaJi6RzPAdyiKAIH1RaLokKOJDTGsWWgrZc4n2T6JGmLFpEC6LngN0291E0Nbo4d8V2O2zWSta58AggbQmADXiLRsjN9u20gpKhhwG0p6dwFzO3sVUw1KmaRhznaxK39eS3HSDrWCMuOy8r/ANXxzrGuQOjQP0VtPFVKo+9qPeeritTli/kj0medHT/pEohpO3uVwG4hzSA172eTlrp4pwaAaxJ5IBTxT/JHWg6CPMBENjQCeSuFie08RRADXMN9cqLO2qkeKiwne5H7pi+cdwg7uslzsbYOE+a5VDtfvarKZw7RmdEgyhju1AwvpU6TpEgkwIP1UxfKOo55doB5ys+JrU6TPvKjGk6SV5//AKpiKbcjXAADVwDisuIqvrubUqOJJH6q4ze26tWYKjzTcH5hFjokItKwsfl91ra7M0Fu4Vxyt026KWDMzcIyjIqoQCVbr0SVAGkECZRUBCMk9Eok62TAAIDCik8KBBFmxA+6af6nLQ8hoJOype4PwOkOa9RYrbVIZAF0zHkEHVyRt2jorHNbmBbfNsNVpY6NDACo0OqON9QNkMVhKbWtDRlfO31WvDVu8oZgQ0AeJzjH9yhUcHBwY4kEXcRE+XRc7a7zmOQaT6LwSLA6i60U6oLSbEZdvP8AutVcMFCYkhYs4ptcBq4yQFvm659TKpcQ6s6OP0VlGGNLtDylY0vJMW36qYh4YzIBqqwGHfnqVH9E9QeNvkFXghaqOgVlWz56BBu7EMVcQzloPtK7VIlgDxJG64fZj+6x7SSAHtLTPv8Aou5TcMloI0mVefuM9/GggE6z7IGQ0hmsJKbwGhusfkrGXW3MmHfnotIuRY+iczqSB6qpzS2o4TZ5n13/AEVjWNNw0epUUWyTaEHGTlG2qBeBZok9NkWyLRB2Cio8RTIiJQZcy7hU9oVTQwVWoLkQPcgK9wIJLfZKPOdrhrcXJcBmErA57B+Ie66P+Jmhow8/GS6fouEnkeH7dChlgDXMDEGFpBGQloFoMxMeqyYM1AWZRMXAELdSp1XUyAx0iPit9FLW+YpIcKoNxaTPkma6LEjQaK51B9Mte7KA3YBWhgeN0klOrYojwzJItuLeJV5zYBwFhN1pdh2xMH8lTVoEAm/ur4p5EbOYy+S0Sfb91SyMjLiIlM92WmZJk2H6p6dLOJcbcJhrJVcAcwMkX4QfPcsLh4nEuzci391px1AMogjkLGJIv+SmGtHZ2OOCrTllhPi5IXraNQPY0tqggW8PittovEECSvWdhYg1+zWS8TT8Jnpp9IRW5zS1sAZRMmd90tN7HZcrg6HmYMwbqvFY6hRBhxqv2gry+KDvtLqswahLrbFZ2LlzXr9Mp8VnH8PmoDL2iHG5On85XjxVrNHhqvaP9RCQ4mtIDa1SRoQ8qo9NjHB3aOEpwZDHucOJEfuvK4+oKuPr1BoXmFdWxeIDM/fPc9wyFzjJy8XWEICTZSYEKJUBlG/koICligUro9lzmaBuuedF0uyLOFpEFTr4s+tvaLvuQCYaXDMemq5+YOBcSIK7OQPaQRIOxCzHAYcukMjoCYWOepGrzo9muPcFpNg4hs8LUXQIF1S9gY3wiIAiBolbUcSbgRqs321PTQ10iUcwVdN0l0GU5CyoqusW904ONiITRyPosnaLj3DwCYAv6qye0tchzzVeT7JHNTtEGVHjdd3JSrcK8tqZdlUo12R4cNlUdJzjkdvZZmB0fFfdasPUa4AkC6StTDKoIb4XKzuW4XiyaqLHndNTDmkAuETug5oDiBPS6gdYg6ro5jWDbROl5K6PYFQtfUYAIJBM8XXPrXmNVd2NVazF5XEjM0jWL6/osdT03zfb0jHU3jxATfUaKinhgK1Wq54OZ1v0/VBh8BcBNiTbRZXVXtMBwM3sdCuFr0zltbLqxD/gg29f7KitVyVn5MpLpBvoFU6rVflYSA2wJmCgQG8WspasBngeHkBx6rWWFwbUpVchveYBCwPrRZqmFxGV4Y+XMcTBucp/n5pC+22uapY1gdmcL5pWPEkNolpLAW/EW6rS2q6pXNNhIYBsqMbTayuCA6QONVtiX9OcaL6zw4mGgiy61PQLP3ZBaXROhhaWaLHTXBK7stMkLQHtpZaRmSIHoFlxANQtptklxgxwtDQX40NiRTCcxqrqTCPi0Vj5ALh+EWVQrAkkaB2UK2qXClI6LbnWWqXMb99lBJgdRZapaWjadEuUVAA4Ajqi+JpNBFid+hSe4l+m0Fwq3CxLT0Vj5y8qisD3cAwCOUSKaucNbmO2w3VNWGMVtWZDSZOYkqjEtmCFz6vt15+NFGTQaMhNtnX14RAOsPA4OiWgM1Fvhadd76qwwPD4p3kytxnpW66z1zlBtqtToWauJBCscWbBklzmnZ0roarl4Iu+2uGwbfzXS70NCUPklsbrNUY2m4ZBEySrRXBdBskc0vrtEggN1CDHiMEarSWxKy0jUpAsdSJI0IXdOUCAFlxFIfEqOJiG5aznRE3SN+AnlaMYyXkhZZMgIqEq3DvHegbGypgk3soyA8ESYKo7NFuVuUbaKx8kQLk6LNQrZjYEuWuA1tjJO6jJ8CwOxYbNqYzHqUO1cICx9VgGVwJcOvKPZzc9au0GCWAD6q2pi6X2Co2u8NqNaWuYdZUajhdnsP2iSPhXpaTYgwAAFzOx6Rc01ct3kkDou1hqRAyuHhO2yUiwxlAHEqAQFJkk8qTso0VwtMLj9t0zUGdt8gXaJOyzVqLXEtIBDhHmkHk8NROJxDKYsXFeowfZtDDMENzONi43XGxHZ2IwlXvKIc5rTILdQt+C7Xrv8DqTKjgNnZT7FaYdVrA1tmwBoFHtlpCrp4ovgHDVWdSAr/IIMVPMT3ZEERKvJzEMG6rryysHySIgjhPR8LDUPoirnuyjI3m5S0mk1B6pNTPVWs8ABO/7IORUp5vE34gpSfIg2I2Ua5wN7FR0E+MQeQuD6xol0nZNCQNMWdKILuiCtwBI9oVdQERwDstEXkgJHXuCAQqEg6i6UySOqskWgX6JgDMwgWHFgGkJWtA1uVY6Q3VINVGazU69YsE1ah/8isfaLnOLC5ziOpWmiZHqqsayaRPF11n14OvcYWt3Csa9zDoD6JGwQIACOU7FdHFa3EkGXNB+ib7T0PkCqsoQLeUQ763eOGsDlXtqUXWJM+wWWIUiUHR7Py/b8Plc34xuqMeXnEVGugw4y4b31WVuZjg5ji0jQhRznOMucXHqZTFVu+J0C3CjrwOBCe3CBhMRWdVopOLWW0VDgrabgKd1KLu8tcJmuELOak6CFrwTszI3ClWTUBB0BSVXXAhboWbEstmA0U1u8ZFQ0TQq21BF3NCJqMFy8KuaxRVitT+b3R71nzD0QJiHZWRu6yBZkw1YHZwH1VVR/e1G2tMBdDFUO8pEMOW+Y9VjrqTJWuY5rAXNMTG5/JBwyujhGkcpc60gWnlKdV0R0KOJa0RUMEc3Vh7QpD4QXFcyOpU91PGN+daauJqVXSTAGwQpxUIG516qkIhvurjG1uJFOQbQsT353E8myOZ2XKSSOpVZFyqa0YG/e+X7qys3e3Cz4eoaLiQJmyZ1Wo8ESADsAiytVINc5pLgMsEhdXAl2QlpkTouDhvDUcB8q1ux1bDUwKRAk7hSX2lmx3hUyuGa3C0tdpBsvJ/9UxRe1z3h4BnKWgD6Lps7aD6QZRZFTfNo1b8oxOLbkdt4BLZ5lRzS7Xwjheab2xiKGKc4O70Gzg79OF1cN27g6o+8Jou4cJHuFN1bznp0Q20AQOd1A0AWt1SU61GrHd12Pn5XApy2bTZEYu12F+Bc4ODGMOc9QNveFrJ23XP/AMRYhlPs19MEZnkNA9Z/RV9odr06FDLRIOIeAbfhlRY5f+I62fHCmDIptg+Zv+y5KsrOLnZnEkkySd1Wo06vZBEhxOghdgG40uuH2U6M8/CunTIcKYm+pWOo7cWYurtzNhV0bgS76IyJmd4umoAgDZb/ABsfm/RnACxnRZsRmY6IBB0WtzfEVy8W4uxMXgDldHBW1gdULj6Dhb6TC2mNCVRRA3MLWwTeRHkqMvaQPcwR/IXKA1hdrHt8LfNcl7csgWXO326T4pIK2dl1AzElh0eLeaylFhLKjXDUEFSkuV2X2JnbVZsQ0Fp5F1oL2ue4E6NuqXloYIElzPzXKfXe+4xV/C2PmCVjEKpL6x4FlYxsBdXBVigRTb5rNstOLd4Gjkysx0QAqDVQohAQioFJVAdYLp9lWYZXMALnBo1JhdnCgNcWiwACx01HQp2aiepCDHA0wUM3VcnQtUS02CzUvEXkjR0LU4Wm/uViwdQVG1uO8ICsStVE3deLq06TKopEK1zgIF0ElYe0HAUHDdxC3EiFye0KmeqGDRt1eZ7Tq+mUCymxCcQAgRLhHK6uShzS0weAfdIVqxzMr6ZH4qbT+iylWK0UK+RoBE7K6liMx7p9mk2PCwt1TJ4xfKtz25ajgSDG4SELJLm3BI8kzcQ8aw4dVvXO8tLgdUtMhmJpvNgHgn3S9+zKJzTwNErq7RGVpkcqWrI7nemoZBtwVA6/VY8PXcQKkSHC8rYHMDM8gheax65dE1A0zDjI0iVBSfUcc7sg+XdLg3CvVqjNl8JDV0qGStSYHxmLdY02W58cr99MRwjW4RtRzSSTJPTyQpjWoKcAjw2W7E1qWfu6kBhHEQl7nLQac7QwkCRcwpXSfPapzYrNgilm/Dp6p8VVp5g0th0SCQmc81a47qo0kjSNPdU4zPVfJAhsNMcqs2KXtcHtl2YX20VrbNlVhxc5s6tbH1V9FzW12Z2lw6bdVi+61PUPh6OVxqVB4zoDsEWDI9zy34jYo1qk1LRyEz3EMyUxL4m62z7U+IVQGyAdOq0Yi1L6qmi3IMpM+X4U2LIFEEjy81qHU31Ew7y4gGdU9URXYOhI+iy06z2hga1niE3TtrufUD3huVrYkSlZnNn1qOiqyhzg/Ui0ypWqHIIbcnbZSgPuwNYsomYzVyO/aOAkqiWp64/9SPJB/wAJXLr67c/DYZg7lktabTc8ouJzSQ4DYOP6KW7mmQDmyiA0qFoDQCGjyMro59fAfkiXFZ6z2Nb4XE9Cr3FotBPkFTWYwML7gDoq5M2FgPquGpj9VqawO1VWE7uo0uboTYrWGwITQjmANIDMxiySmCXSRlOXQ+qvLg1IwAOe4kSSgJEBZ674Cuc+VRVYSFYjn1nsJIJAKxVgNQPVb6uF8RcGzPGqy1aLhYtceiKztuAStVCi5zbiB9SrMPhZEuAnYcLRToVGEAOGVBZSwzBBAiFbU0TNsAEH/CUQOzT/AOujkLpYnB0K7w+pTa5w3IXP7KAOMc75WrqzdRqKqbAwWEei0tIbTJBvEKsCSmqEGkcpm8KKJ0CUkSD7JmnMGlAtMhUAHNYKOBcOqS7X3VzTI80FYAc29juq6uDoVgC+i15HofdXubERummFUUYTDvo5pc7JHhDjJCu2Rc/ZDVBnxbS6nb1TPiGsGgT1BNNypY7NJQWD4vVNUdJA4slHxA9UdXIOZmaRe6kl2gMJWwrAVwfWKMw0TAmLiEyRxm02QKSXeSgYDsiI2ULgNAgYABQ6JAXONkzvC2SUCVDJAQ3UO5OpUHwowwYf4ArXtDmEHdU4c/djyV02XR43KgscWnUGE4CsxjIqh/NiqZn+y6y689mU5KB+qAB8kQIVRIUhFAhAI6oRdEhCEBIQITFBAjkgTuSBRTBbOzgXVTlgCBMndYwtOAJGIs4iQZhSrz9dV9F7YEsk9f0SVGPYwgMIkQXOt9EMoSvaLQFzd3IcL8qQtGMo5Hd40WOqzrpHCzKgCYR7IBGYCIDBNVoHIXWzhcqkD3rYBJnQLbNXamfUrj+TnbG+XOI8RjSVN0zhlcWkXBhAGDIXeMILaSmU1UhEECUxOUSUWNS4gABoRSveCRlJSgElKFY0DqEQzQU4YgwdVaNCUC0RFU+SsrM7xkDWZCFK7nFWTdYv1ufGDzRY8035hqi+1Rw6lKtsiCigigMBPUrVXU8jqr3N4LjCSUhcTIUAsmCACYBAlT4vRInqAh5BSINfZx+/cOWmF0Gl7XBzXX0j2XMwBjFN8j+S6DTDwZtwt8zWbcraxoNzOu60ssNAsrXCZEq4VQB1WsZ3TOMAlxXL+Kq52smbrTjapbhzeC4wFngSCIuApFq5jQVqpwBCzNHGpV7Ja29yqirGkGAOZXNriCd1squ7yo47AwsuJs4eS4bvTtmcsxlM0hrgeDKEIgLbK9taZmYIvvJ/ZHvJaXmxAk8FVtapWOWmG7uP5KYu1XTBAV7b6qpgjRXNBOqIx4t01o+UQqU9YzWf5pEATBKmQFTS6gUKofDDNiGztddehq48Lm4Jsue7iy6NMQwlc+vrc+NeHvQHqnmEmG/9u1PqsNKsQ/LTc+fhBK5vZbvu6jZ3la+1CWYN+2awXN7OMVXDlq3J6Zt9uxTNpQq7O9EGJ3DNTI3WGlcrk1HZ67yNCdSupTOaByuU3WdLrfLHR2CdQT5KyizPXa0EATJSNF7ErRQZmrNmLXlarMVdpNhuHPLIWErqdqNH2Sg7gx7j+y5bk5+L19KNU5CTdWbLcZoQkTx5JChBQKCiivRYXDkYahAGdtMOEm1/4UaVAPzF9nA6BaHMhtNosWMAPsq6QABl0Endcup+3bm/otFooYtrtneE+q1OcGUGwJOmnX+6x4gZ6ZANz0XQwgOIoNqEgEshw4KT4vqXS4qn39EOzEFrdCLzutBpUm0y4PAb9JQewASakOc3I0HdI1pp4YPcM0izSJhU3YgNGhSdXb4iLRGpWauR3LfEC599rTyr6leW06TWtqAHxFtwlxj2vLQ+mWkNkefCJvv2ztEPPizdeVk7RxL6Jaaboe0yCtNEkgnquV2m8948Hosz6vXqOr2f2pRxmVlRkVh+EfiA4XQqFhOcZm82Xj8LiamErCtSIDha4ldej29TcAK9BzYETTMz6FdMc507dJjQO8ZkdN3EFDvMxLZEk/D0WTA4mjiab30WlwmDNiFHtqMdnp/GNjumNy/0waA8ODhlkgBWMpE588NYYCqc9zmtBa2mdRl2VlZhpU2sL3GeqLesWta11INYYOv89FXSrMY2HPAjWVU6iws0RofAWm0FMZntW+qytXzMMgWKXEOyU3FVYec9Wdc5Uxxii5cr9b+Q+DxAqYZjahggAQbA+q1PIcYEQ21tFz6bQzDMBBmPRNQxVKk+qyq8N8Qi3QBdbHHy302QQbR7pKwDmEO0OqDcXh3aVWlE1qR/+QLKYzYOkKdACbBxj3V/eFV5g6QwgiTonaOVUO1wjQylJHuSkeHuAyHKQUzHAucC06m6AQj5pi4bBIXDUqoV5aAqWM755IgAHdOGurvyt+EanhX90GtAaIA2QUZA0wmAMaeyaOQQU0CLIFaOUlU2ViqqAucAN0FvZLYdWcegXRkLHgmljXTEkra2IUbgt+JM5gBDQNTmKVgl4Vhu4lSLVdPwvLeqtVT/AAlrlaBLVUqt4lI10W4VpCqeIuqjS3xBvQKt0F1lZhnZhHH7qo2JQQCVJUkAJZ+qqBUB7uAs+Hs1wOoK1ZhsJVFhUeB5lRVg6JmiSlG0K6k2XAHdSkeea8tdBKta9zvhlCrTkTN1UKpp/FAHK54+hx+SftqLrblVl5mAAqvtFKJcW+j1ZTfQcJAsd+fVMdJ1Ka51fCYAdXFFrmfhyoEuO6i6aY+IgdAq3OLjMWGihHRKRyUS1Jk8o1z3eHe7hqem2BJCzdoPmg5jd9Un1nr1zWTBumkPZaoWXBCKHqtTSt1458UYilnYQsEFjsrtQusRKy4miXXHxDRa5uMdc77ZZUuoPJEyujkUyp5opSgIQJulDo1RBCA6oqTOgRAO5QVuSBWP3SNUDDRX4EgYkHkFUC6fDuyVmH0Uqz66/wCFBLnBdCneNGoPmub0BWaHUnAiRC5BOi6znksdbZcmoIqObwYWuXPswQKF5RWnNp7PYH4ymCLXJ9ltZ95ioBOQSY6LL2dZ9R/DIHqtmEb8b+TA9Fjr63z8c/HU3Cu5xaGhxMX1hZmxNytnaQIqgzqP1KxBbnxi/VgTAJWhOAqhm6KrFNcytlcIMAx5iVpoUi+sxnzOAVn+IGZe0M3zMB/T9FFc0KxoSAKxt1UWM8k8Q1I0QrbBqA0RZ3mm3QZZgChWK3GSr/mutF0oT1/80+SRq1GRUCim6oM2SNTGwKgCgIRJyiVAlqaQgsxTLNqDQrOunVo/+lLSLhn1C5iC7B/+6Z6/kukL8/EPyK5uEa52IZl2MrpyG8fz/ldOWOmllwngSAFVScYV7GmZKtSMXaDrsb6/z6ogGBIvGiz4l2fE1CDMEDyWkgHKRwLJCrKQP4tVc6wnbZLSGYiQjXEU3OGwslIxU7tJ6qnG6M5urqHwkKnGnwsEa3leafXovxmCZuqUA9E7dV1clrQqazg6rA0AhaBZs8LFTkkk67qKvYDzKvERKppp6rstF56IOcUFFEETouZlosO5JQCApXJkDdwCo3YNsUCY1K1McQSNQVnwl8OI5K0N1J4XK/W58a8NbDK0WbKoomKOXrKtcRlvoFlpzu2Xg0WN5d+QWHAmMUzrZae2XAvpNAiAT7rLgv8A3NP+bLrzP9XO/XYaIcVcxUOkPMze6dlTkaLm2Wm0txRGwuFyGhd0R3gcLyIXDp3C3yz0sGq04YfeTw0n6LMAQd1rww/zDwwq34zPp+0GE4Ek/hykfl+q4xXoMQzvMJUZyy3ovPkpw10Qp8wSFELbCwxCqKfZIUpEV9XDmk+kJnOAVRsuliiKldhj4WNP1lZrTt4k5KlhIIk9Fmp1WOblJu3WVZiKDvE5pIpkCSfdYixwqCm4eIuuegWL7dpJGp2UaESFXgMQ9he3QukCbKunevFyyYJ4T4Smyo4l1xRcXAE78D0SQ3a6TZdSpuaTniAJ2uVa5zzRNIwCRDSdxysuGe9kOLSQ0S6ytzfaKb6gBDm6X06ItmUaWGdSFJzSIBkwpinhlIzcu5Cowtd2bNUzOa3QAWlX4vK6iZ4lE6mX2yUBYlc/tWgHxUBjY+a3teG0C4HZY8Y8vwokXcJ+ik+nXxxUFZXZkf5iVWujgLXOY4Oa4tI0IMQtLe0sY0z37if6r/msqCGunR7arsI7xjKnWIPurndu5iHGgSf9f9lx1EXa7zO3MMWy+lUa7gQQmPbmEa0ZKNUu4MBcCEChLj0GDr08RnqUw4S4yHI9p2w56rN2MxzaLnOBDXOsTuui9rag8bQ4dVxvrp3nvlgqYoYemKdLxGPE12gTChSxTA8GHEA20us/azCx4c1vxiLcp8A2tRpMc5pcLwBxr+/uuluzY5SSXKNOn3NRzDqCrlRUqPdVzuaWk7ERZXtIcFiukw2FeBXdTI+IZgfJbBDh4fVcyoe7qsqfK6/luttNwDzGhuFqOfc9r5yqnOWggDUklJUrCfEYHmlGIAzNcJINrKsI+rl1VLqrqlm2HKLxnMmw4RAAsFL06c8f1KU0jLTB/Nam4hrh4vCfoshKRzwFJWrzK6Gu6BaNVzm4ipT+B1uDcK1uOc6mfu4fFjsVuOVmNOcOLmi5bY+ayHFlmIBYQGi0xMqYUmnhapLiXl+u8rM5qMu5TqZzOXKdCAVpmy5nZtR1SmM2rbTyukpjenokF8dFYSR1WemCXgj8Jk+SvIMkjlChUEtiE1IywpC4xdKw5XEbIi8jQJHtJHmnmyDrqoqpuNN4KsIm/qle0GUGPix4RT5RZDKN0dRIQ381UI/wnNtuqXyK7uCBCucbFZg7x5OBbyUVa0rTR/zAeDH0Wdoi+6bM4aGN0HOcJVb6TXAgq02Q10XN6HExVMU3d20ag24uEneHDtyscc+5BWvtKnBztmRqFz5/pC68+44der6bqPaZ0rUg4ctWunXoVvgrZTw7+640nhSeil/HK6c/8jqfXf7t27gfNFrI1hcSlVeyYe4ADYqGvXywar5P9RsFn/HXWf8AJn8dx72tbLjAHK5+JxDKjXspeIgEkjRYC4u+JxJ6lW4chragv4hCvhjHX5716jRhGltATuJCuZ8UJ3UiynRG/dgH0SgeGdwVOplY4uw5FkjgA9sqxxhmYi2pS1BYFRtzqwjEP80qtxjCzEQeFUus+PPfoQFXU6K1U1NEQsFMANwlarGoCA1NsgodFRZg2d5jKTTpmlV4miKGJqU2uBDTYrV2XTL8WHDRgJP5fqsVQFlV7SZIcQTys/tf0A3TNJa4OaSCDIIShM0qjfTrU6r25WgFoJOqs1zRsYXNkzYx1TAkA3N9brPi3O2zvqYoHxDNe26w4isK9TPkDZEW3UdZpVQukiXrRamQCZVlpwhy0qp5I/n1XQpNNOm1u4F1hwbMzWN2c6T6LogZnQud+uk+OZ2nIqt6t/UrG0Ld2qL0nRqD/PqsTRZdOfjF+naVawSqmhaKIvdVlpwWVuLY5xAa0FxlU9t1GVsUx7HZvBHldXUqRql5yyNNVh7QZ3dcNgDwjRZ321npQFYyyQbKxghaZWtEp8ubwi6DLp2VG0qjC7QmJ4UUrvDrbzWV9YmpmGg0C047EQwUWHbxfssKki2rarsziRuAlAsha0JlpECm6g1ROqBXbIhKfiTtQMAmoNzYhk3EyUqejIeYiY3UG97gQRyuMtT++DpcSGzsFRVblqHrcQmmLsAYrn/Sulq4TpBXP7PZNUu2AXRnxQJJg7D+brrz8c+vpqBgwtotTMnRY6dOTYEeq01P8l8kWalI48TiXHY1Jv1K3ES4HgbLng/eETcOXQa7K4CJI2SFaaYOpVOOqAUwwan8lc1zsvwABZsXBaJiZWevi8/VFLQ9VTjSe8aNgFfT2WTEOzV3nrC48z27dX0UQiAZkKMi6saOB9V0cy1HkUX+yopqzFPcA1k63Krpm26KuZdDFkdyBJklMwSs2KM1iNhZQUqKKIL64inS8lWNFbitWDoqgUi00ID4iUHOjRBphVHRwH/t/UrXSaDUhwkXWXBty4dvUkrZQ+Mjc2XK/W58WU2ljrXG45CaPFBvxKdrH/hgIOvYkZhuorg49/e4t5mQPCPRTBf+5Z6/kpjWhmLqtAi8+6GFMYin/qXafHO/XcY3wCfNMG5jYR15SUXQwNdJJAgKwtqRAGUc8ri6E8IeGs0FyVxaa7ndlviJF7LiMOV0kSFrlnpc28XutlIAUKruR+iyjXUQtTBGHqeR/JXr4nP1rptzb9F5sgiQdQvR0z+a4WNZ3eMqt/qn3unC9MzkG6ouUbqujBzoqyncdksIQDoFteSKgk28AJ9AsR2XSwLTUqUyRIMk+0LNaj0NQCqxuWqQNC3lY6uHL6NNwAeZAEWJstGFZnh+YaTZGk/7PRykgmTAJ6rDr8vpkdTNOi9pp5Y/RXUMMKNJtN7S15Gcnz2Rr1muOQiCRqtfesGKDQBAGUJfaTZWY1JeKQBMXJbaVsHfNe1okscDcxZEGmzNn+I+IpamapUDqR+FswUW+/ZMMG5c5ADgfFI3WbEEYgvmpDdAPmWrF1WUmEQC5xkgqh1LI/N8LRpOwVZlk+udSApk06h+Ieyz1g50UpHgEAlb6jKD6wGUOzamSqKjS2c7bNFnEwQmLu/XO7Qoup06YdqCfaywrqY856YbGjNvRctajnfqIIoIhgLKKIoAU1EgVmZm5hmEt5SlCYNkHp2tLgLaaAaBPGxIMcLn4XE1H02AvGUCXH9Fe7EVHN+6ZlC5WPRL6W1+7azxEQOVz6mLe50U9OSqcSXFwLnEg7FGiC52Wm0uPkuvPPpw762tOGourBwcdruKFJ0SDqDddBre5wpBIEi9lhGV1Uv0We2vxjWGZhtdU0azmmHTmHhHVaHPAFlzqmJY2rIMmZkKctdtwpkjxnXYJ7N0SUqrarZGqLio1JP0MjdI54CQuLjDQSUzcM913GEkS9SEdUJQax9T4QStbMPTbtJ6q1oA2Wsc73/GVmFi7zJ4TupgCwV5SOVYt1QRZVVAtDoVL7qjV2V8DvNdNpC43ZlTLiDTJ+IW8wuuQRdStRdRAyEneydhkAJB4abQNz+ienp1KQoOHisq3WMq7cnhKW2IQRrphPEwqgIhPm08lUTKZjqqy20q4OE+iJaDpwgqDomVMwITFvISZRFuiojxaQsZfkr5jotZJaFmxDR4XATB05UF7fEJBlNfRKG6EMIPRWMJNRsg6jZRXJdUkkAKpziwkmQAE7XirQbVpmMwsoxwr0cxEEWcOqw76prUhWpEgzmGq5BBaS06jVdOg51J7sPqNW+Sy4ullrSbSFvn65d+5rNKIlzg1oknQIlo5KDTkJjUiPJdHJY8Np+GznDjlVgFxkmEBE2urQ072SFoBjR1VlNsmBMkwlg+QWjAtzYmkP6pStcf10e0nMp0w82yugHzWRjix7mvBBmbiFO3q1qdEbnMf57qvtNxjCVgSHupSSs9+6n4rkWteHNLZ0sVWx5c0sJ8TbGVlbiHB2aLnW6apWaKgezxSPFsseLr5QtapUqVIqEHJYWSoOeXvLiACdghJW4527ROioqaq4mdQqH/ABmUQWqwKtqsCoIUOigKhQdHslhDXOt4vy/krn4xuXF1R/WVrw9d9FgDYFo0WTFuL673nUx+SzPrV+K2ohRoUCrKBMlGqZAtT4fNI1NUMWStEqKcBGEBwmjZB08BRJbLYGUAXIF91sZRfJPg1+cLLh6obRALTLjJI6rQ2rT4+ixjeuV2o8Z2UfxMHivOqyBB5c6o4u+Ikz5oAbrcmMX2tZdaGFZ2eSvpyZKo6WCBFCQNSSub2u2MQw8s/Vdig6g2gxveMBDRPj3XI7XIfiGuGkQFnPa76Yxsr2iQqIur6d1pk7LKrFmzAVe1srNizNWOAiq2MdUqBrblxW3EYUCgGsHiaCfPlY6FU0arXgaa+S7f3Pc99n8MTKyrhtTBFxBc5zRAJJA4QWkQ6onlGJQNh5IEPxHzTtSBWtUEcDaFowrMwe7iAqCdlq7PaXNqXgSLJViC1xHlysuMphlQOb8DhI6dF0jhxyubjjFcsBkNUkwtaez2FtPN8xW5kghxlw4jcf8AKzYRmXDtB4mVqa0TDgZFui7z4436vp5Hm7QCpiTTZTLG7osa2IaSPILJj6jW1KdNpvqT/PVZ6uRrme2BtqpcD4pXRp5i7MYH0WCmDnkQTJst7AO8k3PmrPiVoaJaMpbJ5uVhrx3hgzyVuDrQfCOAshaHVCeSsd/G+PpKcBslYASSTJuZXSr02Nw9QgunKVzAsczGuqeXDTdO0u5+ir9FY3SeFpGesc1U9LJmyNBZVtuZOpVw9UD0hLgOVlxP/uKn+pb8MB3knYLBiv8A3NT/AFKb7X9K0EQhuiNOLEPZ5KnQq3FmajQPlVeqT4tK4TdPQpmrUDWi+p6IHQq7An/1LI4P5IjpBoa1rRoBCsoiXESWnYpeE9EZnEzdcnRpaA7wvnN52KPcU+FMxsmJJFlFcPtkAYtpbpk/UrNhAHYqmDYZgtvbTYdSdGsj8lkwdM1KzSDAaQSu0/6ud+u2aVRh8IEdFbSqE+F1iNinBskqVBpYri6JVO/C4LATJFwF3KhzUyuJly1S0OEgwVvljpcwhwtqNlsYZwhPLSsjW/ikBa2QMLER4Sr0nP1oYYMLjdp/+9eeQPyXWa6x81zO1WffMeD8TfyU5+tdMJUaREKJYuurmYzygjslQE6wut2QMxJj4WR7n+y5J+JdrsURh3uPzR/PdY6+Nc/XUpVIw9NrBDnAAR1VWJE1C2ZDLBv89VZgC00G5gJa3MPVDEN71/esFt4281m/HXj6obSzYgF3xHUQuk7usvekgCCPXosIzNeADYOEmdFtbRLsINj8SRevsZhnqZmCSSLWEwnZUfTYSLHT1QpvIbGSTuSkpPbGXL4RoTqst07g2i41qri9zrhoVj3Nfhy5/hBG5VdY52FxZD2nUzBARblqUW06r5c64G4XSOFn7Z6DASHG5EwRsSkxbxUoyGi7sv6rS8GmGhjPCDsbhVVKB+yBv4visn6Tdrm4lgYWZm20JnVchwLSQdRZdfGMJbaTcW5XNxTcuIfaLykOvqlQaqKDVVkyiKCAFKmKVB2eyadN9BtwXAkkcLouc1uGcWgaSuV2KzM2udxEH3W//MwlZoNyCufU9u3F9MeMAdhKdUDXUpuycM81+9dmYA3wxaZSkz2YxhBtv6rpYNtRmFYKgBIbtqt831jn3PepinB2Sk6pBebECCVzswEtOosUO1aufEhrSRkH1VJxOdwNQDNoSN065/Zz1npcXSufiaJpuzAeE/RdOk1tQy3RPUZTDT3gBb1WJcdLNcnC1nU3RBIF/JbKNbv6vib4Boq3jxzTGQDQBM0kNDXNibWW9jnZY6NJgY6APCdFYQAstN72AHUDZaQQ9oIVc0FyjopARhApSlWQlciqXNVTwFcVRUMXJsgTDhwxbC3YyfJd1j8zdN1y+yg2qXvF4dB8l1qbMrm8ErNai6Ip6bkBFphoKQuLmyd3GETOUqwpiYCGaRASwmMNueVULrCjp52Sl02HCMElVBggm+iMkFCJk9UY8XqgYPkmUCBcAoAA+6AsUCuEhUvOUgkAxytH4VRVEtulVT/1MU3lr6Jt8pWmj2lhnmXZm+Y/ZcvEtghwVbFztx0k2KcA53dmho5psrRmpYju3GG1dD1VFV7PtBq0AWjW6vqNfiqHeAhuW4JO61eac9S+leNYaDqdRpkg3VWLGZjXFzS47BaHA18Pne5rRG53WGCRwrzGe6pqSGzKrF02IEOAmUGW0W3NYwEXIMKwS7SAOSkAm5Ep5AVQYvEyraFTua7KkSGlUtu5MVmu/wCOeh7QcK+MNTO3u4ABm8eSrxVf7RVDgMrGtDWN4AVdYXaUNlMc7MuIEyVONFWQiCoooios5MuJV50VClDBOEgTgKhkWtlwHJQCtoNl8nZQW5Qs+JbBB5WsrNi3CGjdZjVUBRCUdStMmaEyA0RRVL7vRASkyZTtv5oGHVOxuao1vKVX4RuaqTHwhSkag0wPF9QiGn5v/wAgmElVYx+SgYA8Vlzn10c6q8PqOcBqUAYgJcpTxJXVyWNEq5h0A3KrY2y0U2AGdwpasWN8lkxsudbRuvqtmYwZJjzWQu/9PUfEl5n0XOfW78UNgtui2WlVtJlWgjeF1c14cGszGyyODqpdUi0q+A5kRMdUaUGg4WgGyluLGMgtMFN3j+7yZjl4VtVmZgcNQFQ0FxhIHGgTgJU7VQBYou+EokBI/YdVArQrBZLEIwdtUDTNlZQrVKWYMIAJ3SNEKNIlwQaBi627h7BYKjzUqOcdSVeSA0noswUi13aDAWtYCQbAGYVrXjPJEk3NlQDY+Rj2V7Q8HXW0ru4LcxHIXHrPJqkSIDjC6b3zvouRUADncyufbrw04UhtRpI8oW5kCfCRJ9SsWEg1GTv+4W12QO+IyFufHOjUfIiw6LGK7g42HsrnuGQ1NYCwgnlY7rpxNaKtdz6TwQBIKwhaDJab7LOFjmtU3CYmGnoEoUqGKTo4WkU0xdXBVU52VqIup5g2Q6J6LDXnvnyZM6rcJAiVgrf5z/MrE+t34UKbqSgtMrcQCKxBMxvCCNY5nydwD9EuyQE/CVdhszKrS0CYVBNiteGYWszbkKWrGnvKvyha8IHGk95b+KFikjUrf2a6abxaxlc62slWNMhMWA6JYLbnTdRXN7aANOmTsViwALcSwNMhxAKftTEd9VyN+Fv5qrAOyYhjiJAcJXSfGP277iXWbpyiKQAuPUpg6RLSIQ6vPouTanFBtPDPc0EkiAuVicmIwzS0HvGn3C6GOcXU29XgfQrFSph7QAQJXXiOXdZm4CoYOZt+Fvw7pqPaQchF+isecogAzEdSmpsZRoPcXAuBhwGx4XTqSMc21Zlg2JXP7WEOpX2KsGJqj8X0CyY+q6pUaXXhtliY6XWUpd0xJ3SjVaQ6UpkpWmUdqu32Qc2CAEWcQuI74iup2ViRRw7mlpMvm3kFizW5cdXCTSqMY8AjJltvb+xT0+9oYgiCAbls2VWGq08RmIlrmm0/zqtRcadE1Kkd4Wx5rLrKq+7qV2/FIfLmuW6tWNNocCCCOLFYPtHeNeQ2HRMLXlNXDBjiafzE7+Shn9BlKlVM03bSAdkndVGNPhJJsCTYdUuGwxhxdJuQQdDwrzQIaWZyWHY7JhesuKcQ9xptpgtfsbyT6JXFraLKhYQRYdFG4dpc6oXC3xAHRV1qrnsAZcE2IOq1GbP4grFtNpdJgf2S4x5ZTp1Gx0tdJiA4gtMMjxEBWvy+Gi4hzyIzEaCCiZ+3Px1c1BR8ESfi/nmuZjAcwed5E8wutjQ1rGMyglhGnkZXNxQmkYjwnXn+StT4z19YlG6oJm6KIbZRRQoFKVEq3CUu+xDGEWJug6/Y9A0aL3O+J4Do4F1oqSwlzYv8Q5V8RUdHAVdUCLC6ZsJcrLSp5nilAc1xmTsF1DoIWTAU/E58W0H6rRUeGAnhJFt1wMS81MRUcd3FZ3jfhWTIkoFdMc2phbRaC0yTpfVGHVDLzPRYAe7qNdwV1B4SHj4XHVcOpj0cdajaDS2YQfSAbyN04GV/RyIHic0nqPJZaLQd4g06haKfhkRusbsXToPyVafiboeUlTtJ2eaVMZf6l0m1x6kjpxOyYBcr/qVc/K3yakdiq79azvQwt+NY113EN1cB5lZquMw7AfFnPDVy3XMm5SlXxTWmt2g42psAHJ1WKo9z3S9xKYpDaT0TMJXQ7HrHDPDifA8w5ela4ZmxcG4K8rQH3TfJb8L2hUwsNeO8p7CbhZvOtTrHaoAuo09Jyq0NJbEbBY8Hi6GIbDXgOEw11itu2qilcxwFgkNN7nX0V7tkPVNCiiRwi2m6dQj3jWjxOA8yi17Htlj2u8jKCvu3CJCIBB0KtkwhPRBULAJfwnyWieUpDTsFUUHRV1AtRptIVdSkNig59Sj3ge1usSPRYWarssaRWaQRK5eMo/Z8XUZsDI8lz6duKwDfRHZRReh5iPCTUap3mSqyorPXINS3CZjYCR13kq1jbKLTNBAujqUJnyCICqGaLSoU2gSOcBqVl6p6hKvwpPwpiS7QQFPwo5d/SbpglITDRHMdkEVEUj7NKpCsqmwCrCgcJwkCcKhgFpothk7m6ztGYhvJWwCLCYUrUAgrBVdmqE+i6C5z2FjiDspClTN+IoAbJmKsmCjjDSUQhVswqKpAlO0JRY2ThwVDBbsLSLaWYkjMs2DbTqVgKjoG3VdYxEAiP9IWOr+muZ+2cMHzOWPHuAimL7noug4gbt/2hcrGQcS7T+BTn6vXxSOlk7B7pWiVY0QIhdHM48OuuwV7DDBOupVFNrc0K/K2NPqsdfxvlKr4oEjU2CqeIpFvAT1oL2MiwuUHBpaYbta6zFrIDIIlO1oKRo3JTN+i6ua5kDSAnpjMx49VU0jhXYf8QWevjXP1W34UhY1jHRurANb7pKo8BupFqkJrxZKmabQtsp4jvCVx8QEzCcmPNUu+IyoLAJTGxA5SsNolMbuHRBZsqx8Z8lYSqp8VkBqWYVTGieoZGXeUhSFdwCKZjWD+RVl8xaDCVj81AGPiaQPUJ3hgcdR5Ls4qqpyNc42gWAXNrC7SNwulif8ALd5LmvecwbHwmZ5XLv668fGuiO7fTPBWwOix91jHjc0Dc6haKjsoymei6xzqvEEFjgOFiC1YiTTcGggfmsoPRcvyfXXj4ZsyJVMQYV4VREucOqxy10nuhV/yj6I+sIVv8uPVbZVsECRqrWeKPqqmEgdCraY8RhS/CLJIWOuIqu63WxZsU05g7myxz9b6UoIhFol4HVbYNU18gJ9kiepeq5SECgSVppPIJAMiFQ0eNs6K+m25gQpVizvDwFpwOIayoWvgB26ylqeiPvmT8wWWnZhwuAT6wqcS57qLmtIE26pmF7Hd2xwyj5tkanjZmlrwDoB+qzjTz72FryHtgjaU1JxpumJ6K/HuZ9oBFjlEhZxUa17SLkOBW3N2KFWoDAFvcLUCXfFTIPEpKOWowObYEJ3Umx4ZBG4KxW4ydpOOWiGiIJMEKnDS10OuXbzqnxVVjqrKT3HMBIlWtwdSBlZlPJMLtxJjl37qiq5wY+qLGcrTwf8AhZaYLaYZMiZ8ytmPdTZTp4dhDi05nEcrH6LPV2rzMgqvEslgcPwp1HvDG5onopGqwmSoNUXGZncoDVdGTbIDUKSiqyQ/EVswZ+6PmsjcubxTHRbqTmhgyfCudbjTh3kPt7TqutScWPaS6RUBJhcnDwXHWzV06DsuGzQC4SJ4lZjpmw1DuiwtbaTpP5LZUo5qTRnLcmjljd3WQ1WwIByiIvumwr3VAWyQCIcSbIuW+2rEEupHuwHNN3OB0VTJ7ouqEimZMzcphU7qm8jZ2UEhNnFamWBpDg34Y04V/aS+iUxSGGPeAszc78LI9rGsmm8xHwzyrAKrA5j3SODdVvZTFBpALSdLqpZlXVX0s7iRdognm+nuqn4jwNNMbXJGizVHOqlzhYEz5K2jBpwYIa4E8lNLzkJjQw4UvbEmoJlc6rTccO9wDYfMk6lb8cxtKkzLcuN97KhxzUILRe440Ksc+vrhpholTDRAyBUQKoBXS7MpgZXEeJzhHlK5q7mH8LcOC4T4QWzwoOgP8146BVVJiBqbJ6ZkuPQfkjTGar0F1YlW02d3SA6KmuD3TzoA0n6K95DRe5WPF1XGhVn5SISDioKKBdGFb2rZgntqUX0nkAkQObaLM4JRLXBzTBG4Weuda56yunTqd5Ryus9p+qD6mZge3Vt/TdYvtD82cgE86K1mKZnmYzag7dVyvNjtO5S41mem2qCDH5LOwrQ2pRYytSeS63gLbhZ2iF04c+zgooAqLbkMpSilKKBVb7BWHzVdTVSrG2jakzyVoIIgqnDmaTfJW7eSQqtzATZQZmmxPoU7xN/yVTnkWN0Q1TE1YjO+DtmKVtN7rmUtMGo7yWptMgeEhFSjSA1BBT5DxKjHQIdAKfXoqyZlfEUwA2tUA2GYq9naOKaLva7/AFNWe4GqGyuQ1ub2vWHx0mEdJCsHa43oH0d/Zc1SLaKeMXa6ze1cORdr2+if7bhXi1YDzkLihplBwmoxvmVLzDyegw/dVKrS2ox29nBZO3aeXEU6g0c2PZXYRgZhqbTF7qntZh+zsePwu/NY659N8d71jipSE0pDqujJDqkf4WlxV1vNZ8S7whu8qUUM1VwuIVdMSrgLWUi0bAWRsEAEZSk+g5zndAkyhOboNBcYaCVNdr0CXlXtoH8SpeRnOXTQKSudAhAWTAqQtMpqgUQIQKiqqpkgcJQFHHxFRRTBOFXJTAkbKo0YcTUnhaVThx4J5KsmTlaC5x2CzWohIF1hqPLnFx3XQq0HMw76lYkECzR+q51ikKCZqEJmhVk4SVvhA5KcBVVTLwOFFKAmCG6YWVGnB0c78xnKzjdbiB/UPRZsA0904hsglaYPyLl19dOfhXZeXey5lck13nW8XXTIPylcup4qj3Tq5XhnpGp9rpWCExXRg1FsvJtYbq8yNIVVIw0wN08+a5363PhCHOqSSSUtZ3dt1MnRMTFyTAWSo81HyfRWQtMLEwmGqm5Cg1lbYOFfhbVDws4V2H+P1Kz18an0HSHkJKk5DKsqiKzlXUnIVmNVSobXCiPmujAi4lIQC4+aYWNku581AwaEW3MoOMMJRb8IQM82VW6d1tVWSUCtN1ZSaHVmNOhcAVWAUzGOe9rQLkwFR3qZIpOAMQJ9ITADNMRB3VdDwi5mNZ6KwZiyHC/RdXFnxL/u3E6E6+qwVHDNYytuNaX0XbZbwucFy7+uvHxswJd3gkwtZbD+b6lY21Gy2B5LW8gREkHpoukYpMQZa4DUrFm6LU52V27iszGmoXOMBo1cTAC5/kjp+MQ8cKtxipmG6se3IRNwRIINiFWSM0EQOu6xz9a6+CYk2SuMttsDKJHAQqGKZANyFtlW0l2gKspkB8E7bKum4zESIUzHPmjQypSNUt6quvBpwnble2WuVVTUidFzjr9VtpAiSjRaA+YVjS0MgEyq3EtmFoyK3gl5I3KIa47IBOJV1PGJTaQ+TGmivYFXEwVbTEiyzpmCUoOUyNRdWZUopy5QXHFVi3NmieAlp13srS95yuuQNLqBoGt4S1m+EFuyQU1CXuLjukDROiYTumAlVF9DEVadPLTMAHi6FVz3gVC4u8yqHHI8E6K4GRfTZSrFT2d4A66ZtOBGd0cSmkA6BQGOqsqWBkDRZECdkZHCINkRMnVZ8UcoDQTO6sfiWtswZjzsspBc4uc6dySrIWkALjA1RICdpEFrW9QSmpUXPcxumcgA7SVtlSjp5lX1MJVpl4qNylms2VLhADldQg+Iea6FMFrAMoK54BcYAkrbh6hIyus4fVYrUXMcabg8gwNQN116DnfZyGhpDjEmxgrjuPhXQ7OrBlANqNzsO24MrLcXObNM5AJg3G6sp5hWDSB6mxUbRHcksqBzS4eh3CsoNa5tMXc2II3bKOkuL3VmNqFhbAvLeTKdjmB2VpDjF3cqhz6dWpmDRa0O3QDBngvLW9G2VYsiDFBj3Cq28QbLPiGTTBAg6Bv6K3E0m1XscwzP5C1lVWbUZSyMJMeImfoqevWKu7DAabjD4ExoN0TTLaUGAJEEbp2iq2kXPaHZbG2ghLimhrG1BLW5ZlzoDUPL9M2K8TmszAAb6pTTc1pIeDlbcxZwVdRtSrVa8N0i8q0MMVC5oAgkSStRyv1wUUEVAUFFFQWxmEmBN12aNdpFBjYjvQJ4C4i7GEY9+HouaGgtMidDCg6bPDIIuP2Ctotys81RVYW4p8btErQTlEdEhSOmd52VGPw7m9n1qrraQPMhbKFMF+YmeiTt+W9lQbS8BVl5kIhKEwC6RlCgUSgqgKo/ErSq3fEpVgpwkCcKAqKKKgFAlFKgkxdVm9kzlZQpyc5FhosdXI1IvpAsYGnZWSEikpzdhZ7QuOxHug1hqm+nKZjS8xtuVoaABAELSAym1jYbYJgCEUZRAIB1E+amUatsiBN0YEKoUl4i4UDiNWn0CM8KSB1VA7y3wuv0UDjwUdeigGw0QGSShh2Oq1hE+Ix6IxmtEj8108Bho+9cPJGbWxoDQBxZVdpAf9PqT0/NXgGYVXaAccJUAAIyz9Vjr4vH15kypB3RRAMLTRDYSsdYy7rK1VTsPJZHmXA9Pzus1qGphW9AlpgQn3sqhhYaXSgFxgCUXWHmr2MyiAVm1qQjaM3cfRWgACIhHopPRYaJVdkpudOgt1WBui1Y18BrYgG6yg2WolMEZShEKsmlK6wRNlXUMNRVWpTNASynCgYItu4BCQtGBaDXnWBN0qybV7KLnAAy1o9ytdINpiGtjqhBRDTwFyt11kxT2nU/9MGjd11yoJ0XS7SH3LHEfihc5q3z8Y7+oAnahvqjHVaYPoLrM67yUalhAQbYKKYCEVJUAmw1KDpUWhtBgA2lPYbfVKBAgaBQrk6pI4PuuZqF0bTuuedTZb4Y6RqeLJBqn2W2F9IHuxBMJodz9EKTW922SfZCvUbTZYnMdLLl9rp+mbE1CTkBkDVTDUi45zoNFXTb3lQNmJ1K3tDWtAD2wFq+vST2yO+N3mgE1QfeOSArcYpwrcOYI/1KpPSnUCYKz18an1diG/ezyFU4S1wg6cqyvUa9wyzPkqhMguaSN4CzGqoHCPmho5NY6rowEDUJRymlI2dAFAXzl9UaRtBRi0FILTIlBY4SkICjDeTcaX0Qc0tcW8IADckKzDuy1mOJ3VZEW3QuqO9hnNdUaIGYuggmLKxsFoM34N5WPBsGdlOpUkWkOGhV7Kb6kuDJvJJdN/eF11ywtYEUqhIgZTc72XMXXdhX1qbhU8JcIa0ndcegc1Zg/qEhcu/rpz6aaTxSqy9httC1GHwcrsx0BK0Pw7cRWbVoVWB4guDvaVqo4EvaM5bTZEOymSf4VqVmxjw2GzvaTGW5dfS6zYzCgZW03NA8RDDbf9oXeFGg1rmsBGafFoReVir4JxZ4MzpdIM/D1WOrrfMxx35RkYCDkbBPWSf1VAeC514vZaq2Hq03AkCHbt0E/ks1TDOqN72i0uH4mjVp3UjVLIc43LRFlWZBMFM14Ig6qZYstMq2EtPVXB82IBRw9BlasGPeWA/iibrW7sasATRqMqRsbEqDIPCZaY6FIXHMSramFxFH/NoPb1i3uqoCYsuDAAkEFRozWlXUMFiK/wDlUnOHOg909RjKVQspuDgIBcNzus2Y15ay9y4GzhCA1trutXslczNtfkKaT0QEOb1b+SjXwbSpkc3b2QJG5bzojWxcHO1lQPLalzAI2SDu8wFNxJ4TPbmGiMtFNtN5jvI9UKzWsaQHTZZB3rdHe6ZpqE+J1uITDUn+kJmkcKWlEQgDwDqEGkNAadtFYRKUtngoHp1GC7wCNrpDUD3+GPIFVOogn4QmpsDdAgt8wlfTdVAa0A/0zBKISVm5gBMKoqqUjTJEERsVU6TbVbKeIrUxD+7rNGgqCYS1cS6r8NOnSHDGgH3WmcLQw7z43SPYR7rZQJZmZmzRfMRFlibVeGluYwREHRV949staSJ1HKmC/F1+/qOEA5dDueVmJD/CBYK6jhMS8yyi+CDqI1C1Ybsqow58QQ1sTA1lX4OY0wUSYuJB2utMYQ/5hqMdvlEgpS/CsHhFVx8wEFlOoH0pPxDVdHstwqYOXASJMLmipSePu6ZYRreZWzst+UuYDaVlvn611XuYwkHLIlb6YyUmYixDbeHcaBYcUSaLoAjT+e6OCaXYWJMF2kpG7NdCth3VKeZlRzpILbp6NCo133js1t91lZVqAENeQA68FI6rWe4gVHwRaD1Q930006bHNHduyuY6YJWao4txMk52jYG3SUjmjKSRIFwIj1SZ4c+SAQTHVVM/ZK2JrU3y10F2tlxsc+oasPe4jgmy6OIfJbHC52OIL28xdSfWa6uDPeUGOOpCuqt+5qf6T+SydlOzYcD5SQt5Ac1w5C2w8sihuioIooogC9R2Kxn2Gi7K2crrx/UvLr1HZLSexB5OHu5BY+ux+IsPid+QV9GKlUMO6xsoZHtdIMFawx9Kq17hAN2kaFVLW+mwMOXhc3/ExjAUwP8AufoV02ObUbmbeOFyf8TSMHSH/wBz9EZecCZKEV0iCgUUCiBqq3fHCsVTjLzHKlahgU4SNTBCmQKiiqASgoUDooqMbneBtutYEWCZuFqUKbc7SM10IXl/J1tdeZgFKUz9AjQbmdmOg/NduPjHX1dSbkaBvunURAXRkQOqMKBOxmbUKoTdQzyrTSLRIFkhEqorA6ogTqmjZHQwLnhEKGWkmAiZLbAeX7o2Is6/P7IBoGgQXUWF7w2JcV2WtDQAIsud2cQKrhEkjXhdJondKzRF9FZAiDfZZqmNoUcQ2g53jIk9FoBBEgyCvn/8n8l3xjv+Pn9vJQo45WqaBI7Re9hTVOg3uVQY7wxpKvd/mAnQD+/6KhtystLW3CcAA6pG6Jx1VQ4GZw81o21+qoo/HpsrysdN8pveR1UIm6kBEdVlplxx8LGjzKzDRPi3zXI2bZVtK3GKZNIAulmNVILvJESS7yVdU6BWkwICpfqlWFTtI0lKGymDQoGEDRbuzmiXvjoFhDQNF1sJTa3DM5IlTq+muZ7XCCopA5RAHzLi7M3aIBwonZy5Ykrrdof+1MHcSuRuunHxy7+nGsooNRW2SPEtKUaBO74SqyVAwVuGbmrMHWfZVBbez2eF1TUzlUtyLJ7aoHCDgNI+qa/CFxwuToXIOCufVZFV44K6M9AsOKH35PK3x9Z6+KYKebIKLo5tlIHumW25VdagKjy52afNXtkNa0DQQoZ3XHfbrnplZh2NIIlWhgGyJF90R5JpjNWbFU7KmFqxInK70Kzkgarpz8Yv0Ar8PdrrbqiY0CuwrpzNMzqnXwn0+UTp9USBwmnaVLLGtslZozmEgMiDqrsSAHgjhVwCF0nxi/S6ghK0lp6J4i5NkrgCJF0Q8yNUrhmgbnRWMouLZywo0mm8EzY7KKNJ4dhzScJcDLf1CVzZIMygahLsxMk+5Uzj5b8lVCvBLyXayplJGoHRSoZuEASoO02o3C1KVUh7zVpBwaBaTt/OVs+z1e5Y+nSh2UZQ7SmTdxPX+3Cuwje5psZqABElamuOYuhoJ1jUrVpPTHlY7DiXl4DfjGoPT81yndkGi9tanU7yjOu67dSgQS/DA5j8TdonUdVKWG7xtRrYZMFwDoJJ3/mqjVxSwsqMaBLXN+EgaJ2vqD/MaZG4uFRii7AgZ6b6jBYVGbdCqv8Aq9MMltOoXeSazjc6qSIYNBNoknYI06tQuzUmuqhpu5oEf3WGj2nhsQctUGkT82h9V1KdcBgLMuQWEGIQVufQqtcHsN9dx6hY29lAv73D1Mh31grqzTqEZ6d/6gqsbjaODoFxc0GPC3lBw8XhG4l1QCnlxFPUtHxHquQHAjxT5rsdlVGmq7M6HuMy46pMV2FiRUc/Dhr2OMhswQg5JqAafVX4fG1Wujvng7SZH1Vv/RscTBwzgfMfutmE7D7p+fHFraYF257koHo9rV2gBzab/orH9r1CJGGpZtiXT+iwYttD7Q77MPujpFwFUAeqmtYuxmOxmLGWq/Kz5WWBWUCLK0zz9EhbfVQCVFMvVTKoqKEA63RhTKUAa0AyAnJKABHKMFAFJITZT1QLPNAslQEowiAUElSeikIwgBjhARwmhLCBswH4fqoS06t+qCg8ggrrRbYK2lgn1m5qL6ZB2LoISuE7BMKdPWAD0V3Exe3smoT95VpNHQyrQ3C4JuWiO+q7unT12WXLT1yg+aMjayaY2DH4iLMY3yWWtVr1gQ95AOwQD+qDnmFFUmmCIKQ0QrilKBWsAFlfhC4VSwARAJPXZUEwtHZwLqlYzYNHqqT614mzXgcc6q/BMmiQ6A0mVXiBnqwbkO4V+EOVsG6Og5iARB2/n1SklhcBsNP0Vti4jUE2d/PJVmA8uBgEXQCoDEuJINvJZqrgHuJsN1qqw5oLZkEeHlZ8TR76kR+IQQiMFWrmeSBA2XPruLqzp2MLS+eIIVFYMdL2ugnVpVjnW3sZ96jJ4IXXHC4PZzg3EtIOtiF36ZWmXld1EXfE7zQUEUUUQBer7JEdhNO8H/8AUV5Rev7Ebn7FptGpa6PdyCu0yungnirhQ1wmLLl3PqtGExHcyAJWma29yabs1KC0rnf4mB+w0iQbVIv5FbDic4zMaGkm4OhXN7arurYHK78Lg79P1RHARUUW0HZKmKWERASJI2uqNyrzOUqkfEpWocIoAIygKhKkoFVA3TUg3vGlwloMkcpVpwdHvarQRY3PkFjq5GuZtX18biarTADWHbLP5qllUGz7HnZanhznim2xcY8kmJwo75zKTScrQSFw9V2+KqjTAA1lX02ZWgcKrDscGyTbYHZXgELrxMjl1fZgJRhQWsiASurBmNklaWMBACSkyy0MsOqrNQMVOKjvoGwWum2bgLDiDme85vDOvKoq3sbbn9kpEngIGZvfjoogO6LUu6do5QdLs+kWtNQ/i0WnEV24dk2LzoFk+3N7sNosh2hnRv7rMS5zi5xJJ1JXl/N+ac+p9dPx/it91ixgIxXekk57k9VrwePqUIHxM3BVWMZmo5vlKz09F5d8p7eizKRxVRMmFYd1W7VfRryxnL5NRI1Bl3+/5IvJDzFlGlg8inkgbD81U15IgpmENqNcRIBvKDZTaBTlpN9097XRO0Ia7rm6JcKb7oeqhIAJ4EoOfUINV8/MULDRKEwW3MQJuUSYQlQBAOpVRMuJVjzYgKoKKYJwEAiqC0Fzg0amy64hsAWAsudhG5sQ3cC66Jjhc+66cQZUlCRwVLdVzbVYy+Gd6fmuYV1MUJwzwJ0lcsrpz8c+vo7lFBqaFtkr/hKrVj9AqxCgIVtKu6jU8JMbhVTsNU9ENFRpqCRN0I6cui5d7oFx+Y+6aWEAgAg7oHLwFxdS5o/EVgrv7yqXC45XQkToFzSIcR7rfDHSB1k7CBUBcbApAoZldGHRDnG4gjkJS53H0VWFcQw+atmVxsx1lIXOSZnDhXJXDogre4mmRA5VBiFrY3NUaL3ICqZg8RWrd1TpOc7mLecrfNZ6Z54W3s/BPrsNXNDc2S2q6+A7BosZ3mKc2q/YAy1vnytHc0sO0sw7AxriSQLHRarMefqtdQqup1AQ5pSZx1XbxNBlaiKZYHOA8IJuR0PK49agaUEEOYdHfoeD0XOxvVGI8QDp0VIMK2s2aZCoFuq3z8Zp4BuUrjNhtdGCdTAVlKi5wJaLDVxVQ7C/KMzSDE34VdRpnMJWmoS4lrm+IxCUsDnS3i6y1jMGNcbOjoVY2jGrgUz2QbsbKDaOb4Wn0V1MWOo08kZZPKy5HAmLwbLSaDWOgi8JgwE6qaY7eExTMXhgWiarRdkwU/eNqCQ+A3UG2U9RyFx+4bAIJBG4TUsRUo4oVKhfUZo4EyYWtTHdpOq025m0nlhESTJPpqrBXfVBa3DkTqZgJaGOp1b06jXgdYKvfiqVK73MYIm7tURW+jQw1A1qjLNEmFwMRVpVapeynkB2mVp7T7XbiWGhRJLD8TuViaAQLeizWohax2oHsiyi1l2VHMP9JhPkb8oTDLu1RQca5bAxVWP9aoNCHZnHMeSVoLhwg4gjT6opKYZpb1Wltaowfd1yw+crIGjooYCDRUr4wiPtRjpCzvovq3q1HVPMyiD/ACU3v7qCvug3ojl/koOF9SoJ5coqQBuES0HYJbblQxtAVE7tpNh9VDRtuoJ5CJnkIELGgwT9Ewaz5vohkJMyEQw8hBA1vzD2RyD5h7IZD0TZD0QDu/6ggWdQmyO6IFp4QIWFQMdwoWnhQA/wohsjuFMp4RGbn6o5nclFKQRqEpF9E+d/8CmZ52+iBCCgGkqzM4fhRD+WhAmVAgjhWd43hAvagQDoplKfO3y9EQ5uub6IK8jtglIO6vDmzYhSRyEFEdPqlIPBWqGdPdTK3+n3TTGJ0i8WW/BPoEVe61NyD1VLmA7tVIBo1RUZEhNHZY1pcXTObSNk9NrcxAgAaArFTx+HEGoCwzpG3C10qrKju8pOkG0j6rTa0gAgA2ktMeyR4sAY69P5Kep4XeECD/LJCQGOc7UcIFqETAmY19EogG5uQCZ8v7J3N+4JvaUkAAv2Eyg5mOaGYuo1ukz9FmMHUAqys41KjqhnxGVSjnT0wxrg4NEgyu3RdIErhBbftrmUmtYBmjfZWVnHKd8TvNKifiM8qKoCiiioC9h/h/8A/lVLyd/+orx69j/h8T2TRt+F3/6ioKGmwPIsoww+fdLTu0DkInwm50W4xVzSZzDbUKnGUxXwtRuhy289VYTaWmOnKV5a9jmnwkiJQedBUlKZa4g2IMFNqtRKkqKIIgvPgy7yqRqVa7UKrcqVqHAnUp44SiyMID6QlciSEpMoCxpe9rBq4wupgwA6o8DwjwtWDCx3jiROVpI810sOMtFg+a5XH8ldeIegz78v4FkgqZMRXfvYBaWQNxKwu/zHnlxKzzNXq4YXuUyVqJXojhTNueVcxsearpDdaGtstIZgiwV7RNkGNAN7Kxo2Jg7nj+6rIvLabC6PANep4XLquzHSFux1UhraQAEcadFzyLqRSo3KICMEmAluLhZhO2mTd1hwnY0N80wXj/L+e/OXfj8f7oiAIAiEySQNSAl76mDHeCel147uu6xzc7HN5ELnMMWXUbAaHDxDdc2q0NrvA0mV15lk9s1U6wkqh7vA5ysfLzwFmrPDjA0C+jXlhaTZfbj+yD7uJ6pqctGf2SQo0ZphM2aj2s2JiyXRXYNs1S75QiRu02SlEv4Sue1okrm6CVTXeBTcAbkaLRTo1KozH7tnXVDHUqVDBkM1cQCdymwyuWmF0EQFtzTKFCVFIQK/4Sqwrag+7B2Lj9P+VUoqxuiZK1G6o6HZlP46hH9I/X9FvLWxoFRSp9zTbTG3RWBx4XDq7XfmZBLGoZRsgXHhS42UUKjAabmjcELjkbrs5vNcqu3JUc3g28lvhz7Um1wmBnzQIUAi66OZXmSEjrOVmVK8aEKKDZ2sna0ndKHbKxr8jw4D4TKqOjTYWU2tvYcIlqLKrX0w5tgdApm6hcK7FjqsXc1a2Ic2nTc9xJs1p5W9oL3BrSJJgLudnYcUWucXZi6AYERGy3wz28xh+z8ViKjmUqDyW2dNgPdXYTsypiK1SnUmj3diSJvwvQ1Kz6VSoGNyl8E3FjpA6pqEVGFxECTEfyVvWHnauFfhCGEhwM3CS/C39qMc7ECps5u50I2WQU3dFyv10nxWgR5qzu3fwoFjxq0opaLc1ZjZyy4XK9FhagALKjMjt7RK86IDhmBhdfBYppc1j6gNM2h2y3yx1HTqguaXNBz6GPxBShSa28meuoKUfdnM0kt2vYJqtcMaDbO63kFuucV1aWV0AkSdBNvZcztLAvrO72i097o9mUgHqF1KdZrWzDi7d03TivTIg5h5rDpHjKri1+R4II1BU7sG4+i7vbOCZiWGrSH3jRY89F59j4sZ9Ugvw9Kn3k1iS3gbrXWezO1tMAsaLAaLI17Turg7MAWgHYiUUtUONyCTN5GiRrA0y0aakq11LMfxCPUJe4fpnFuUAa8smGgidtk/2g6NaBO6X7M4CZCYhoIaJdyUoEgkk3JN0zYJ0CENBuFJE2CyLxBEQEcgnSEtM2Eq1vqqFfRpv1H1VD8I3Yn3W8GBqmDp5hDHK7oNNla02W5zZ2B9FbRpkiO7n0UtWTXPz2UzfyV1zg6L/ipweiqqdliJpv8AQrPlF8a5hclLgtNbB1ad3UzHIWcsE6Fa1MJIKhI5RLQDohlb/AiJI5RkFTIEA1u/0QSQjZQtbtPrZLAndFHwqQOVCwa/qoWDn6oJlbyjltr9Epb1KGXqgfKeUcp5CqBg7ph5qCwA8BEAxoFXflMHHkIG9EZHylAFrrFxaeYkJzQrZczAKjeWmUFZI6+ygjlKS6YLSCiCePqga3RQBDNyFJHyn2QGEsXUkcFQnqUBgjhQzwgD/UUZ6j2QT0SmOE0nkIeLoqK46FT0PsnPVoS+D5UCkjdxHohM6PTzT+VKcmwQCDs4H1RAdyp4dgiI4QAh3BVZa5xyxqrpHVEOggt1CBXYQggNiSFdga7cPUdTrWaTrGiu+2tFMA0XEjflc6s576jnFoGbrojWvQCpSqlvd1G5heA6Qg91BrSx7mgEbncrzBp3lANlwE+q0mvSuxFNjS0PzW2ustbEd5TfSaIa6RKwU8wEh7p81YKpA8YnqNVnWsZTU08gqy66tqU/GYNjcJMirmUPhX0jMEjM0GbGCFTklEsLGuIJFlUZyZJKiCK2yiCiiAL1/YNTJ2Ln+Rrj9SvIr1XYrc3YFUDXK/8AVShKY8I8kX+aFMwW+SscCWiy6RigDMTwiQPiF50Cr04urWyadtRoiOF2lQNHElxiKnjAG0rMCut2xhzUotxIN2ANcP55rjhIqzVRKJU87KoapGWRcoVWsyth0ui6DgC2RslJBa21xZStQwJ0KJukURDXQ0UU2QXYU5g5gF3EXXVi4A2EBc/s2nNTNwJXTFr8CV5+/rvx8QxNtFjHiMrU5xDHHosbNVv8bn2t0UCXXRGbFdnJooarXTELFQcA6CV0KUFpfqBqFUpwLgN+I38hyradgBFgd0tIFoLiRnPxj9PRWjLGYwB+SI52NGWu4HdZgJV+MqNq1i4GW6BZ3PDRJMBFMYaJNglovNVzg14ZG5WerVNToOFZgrPdPCx38b5+upRw7XME5Xnch8J/sdD8THt6h0pKDgG7arWyqNwF5sehlPZmEqf/ACP/ANw/Zc3HYE4OqIJdTd8JK7/3bvwgqjGYZlfDPY0Q4CWwd1By8HXc1wg3CHajYxDKg0qMn2VFF1wVpxxD8PSdF2uIWb8VyqjiRAtKyviYCse5ztUjWy8Dkr2V54euYdlGgn81WCnqCXegSwEEWzCtDaGb5isR4XRwuGLqLHPMg3DQp1V5m0Wh1V2WkJ6kwFpo4TuzmJzP5I08kwbls1pHkCiHECFxt12kPkeNwfOVj7VBGHaDu/8AQrSHO6e6xdqVCW0weSnP06+OeNUUAjouzgiikqFA+JAbQw7d8pcfUqjKr8d/7nLsxoaPZUypGqIBTDbzS+I6J6d3tB5CJHccL6oeqUk/MhLzuFwdzlp5QkjYJSXDhDMflQPnPC53aAHfgg3Iutuc8LFjzNRoy7arXP1nr4zKeiAg2FkQ0m4EBdXJIJ4UgmwaXRrAlOG2RNVzGllN5E6wgqgG9vRNlOitpsbiGtbTphkXdUcUDlY9zczXgaOAsVYJQeGOyEyHaX0WnNwshZTPzKxtUNtBIWOud9xrnr9VqwxP2ml/qC9HTdlL7ExBgeX9l5rDOYcTSg/jC9I17GOkuAkCx1spx8OvrO6nU7zM+A3ZrRutGFBymZPiNz4o9UTlrPBaPCL5rpyyDIcR/wCIhVI4XaFRwrupx4QZFlmD+QtPari7ENcL+GJjWCsXmubotzCf7oEg8qv0TAHWyA5Z3Csp0hmBkR5pAL2AV7W9QrEp2CpRdmovy9AbH0W/D4qjVyivDKg2Oh8lhiLWUIBEGPVa1Mb6dek7Wm9v+l0q3vKOzah84XGmowQysfVVvqYgiHV3EdDH5KauOxWxLKbCSGUxyTK885rXPc60EkhWCnLszzJ5JlMGxMKCnuWHYI9wBo4j1VuTynopHT0TRW1lVpltQhNNf/ufRPl5jyRiba+qaYryvd8RJ9UQCLBsBO0NbcAE7g3RhuoaZTVVx0UAM2aFYNbwmBANgUAYHbtVwLgN0mbglHM7m/mgfM4dFA5x3KSXHcqynN8yBmFxK10geFQxwZ/cLVSrUogkD0WOmotZI0BTgnhFjqZ0cPSE8Dlc61pJnYqmphaNUGWQTwFpUj+QmjlVuy3a0nz0KxVcPVomH0yOq9DB3H0QLQbEfRanVTI83lPBQgwBcrt1uz6NS7fAegssNbAVqZloDx01Wp1rOMMeSkXmYVrmltiIPVAtPC0K4G5UgbpywqFh/hRFe6hPUlNlKGU9fdAhjMVI8kXNcXGB9VMruEARuUcruCjldGhQBFrnMdLXFp5CEHgqX4PsqNAxhdavTbVHJF07WYOt8JdSPBKyKBQa34CoL03B49is76VSn8dNzfMJqVepTMtcfIrVT7QH/wAjfUFBgkcoHzXQq1MHUHwewhY3spychcPNBXKMoZTsUbqgIFx5RKU+SIkzupbol9FPRATHCgDePqgpPRAYbx9VA0cIW6o+hQSAEwhIJTDyRT2VdRrSrNUpCCh1MbEo4ek1tdveO8JtPCsIQyTYoNjqVI1Hhr2kZbEmFRWYxpLg4ZZ4QBqNblbVcBxqkezNdzi7zKLqvNnOYabI36IluyEDlVkNeEuIBFExBVgaJgG5WvC4dtXw56ZqfI8EAjzQxxVF3MT2dQrSWsNCsNWj4SuRUw9VhILZjWFuVmxVCBTTFiISlVEXquw3uZ2UxoAIdM2/qK8qu72bXrU8KwAgtAkA+ax18WNZEVbCLq2LGdlU05nAndXRDQZMTddefjn19UOHi19VZbu3bjQXSvaSSBeeUQJpmZjcBWoZ9LvsLWpckgdF5e4MGxC9dTblAA3JJ915/tjDfZ8c4geGp4h+qzvtYwooIhaBaJMHdIB4iE4S6uJ6oRAoQUUUCJhoVCFNkHT7KbloPfy6PZayYpj+orN2eIwg6kn9FfUPiA4ELzX/ALO8/wCpKpljhyFnAN1oefDuqafxELrw59lDoVgAckqNyu6Isdl8iurkIORy6GGJc4Op3axuYjrssVRhLSYRpVKlPxUzvceX8KqO3TqtqABzYd5LN2kXBwY1wDYmFXh8Z3jKhs2q0WB3WGtXGYurEud8qJIWrVFPTxOhZ3Oc58uJKDsznkv1KI0BUaEBasI3xHyWdui14dh7p1TaQ1Z7+Nc/WymIarmrPTeY0VrX9F53oWwmb0fHQqsOCIf0UHKxNLuMZUZoCcw9U9Tx4R3SCre1gD3VYC48J/nukw/iaWfMIWa1HMxDWU8OGjWbFZ6Yl9th/ZXYoy4DpKrpWDnfz+aL1R51dQhz3OGhKUnYKOM22UhVAXdpsLKTGB48LQNVyMLT7yu0ESBc+S6ZIndc+3ThYc272pb8tKWAdygANAVzdNMcx3asXaM/dzG61xfVY+0NaYmbFa5+s9fGS42TCCoDIgqZb6rq4plCLAHVWN5cECYtKswYnEtnaT9EqxXjHB2KqEXgwqx0UqAtqODwQ6bgqAhSLTX6JqYLqjWjUmERSqESKbyOYXQw3Zz2sFd7wCG58saBLSLYKn81RIc1uYQW/MDISy48FcXYdTrHRGwSQ7gIGeAoHkdVmxrgQ0DXcq6eknyVGMpvbUIeCDqtc/WevjKAZj6hN8IIAkA2XQotwJbFGjXxNQjSNFTXwdahTD6tMsY4wLgkea7OLHM9fySubMq57DJIFp05SRNgFoVnvn07XaNglpu2Wlv3QBP0VgpYeu+Zg9DBWNxr6zgphdbG9mNdcV4HUSi7C4WiJqY1pjZrZP5q7EysbczTmbq267+BqONFlUkhzx8XK4NSs0SKLXETYuXV7PxTm0g1j5EXa66zasjr08Q/8QzeSNVxcwgDLO5Kz08S6P8ALpj0S1caKfxVadOdhAWdaxj7TpEU2E2INp3XPynlasViRXMMLnSZLjKoDXcH2WVDKdZCmUnhHK8CII9EpDtSCgdtMg3lXNELKG30TiQg1AqOlZ5KBJVFrp2CUz/Cqy4qZnckKKc5oShp3/NDOY1PuhndyUDgQf7qRfZKHu5KgcRclA+UnWIUgC1kuc8ps56KA5bWlENI/VDM7gKZj8oQMQ2Zv7IjXeEmcbgj0UL2/L7qhyAdlCfMpM4+X6ohwOyAydQPqrAYACqJFhpH1TdUFofAiQhnG8Ku/AQvwFFXNqFt2mD0Kup46ozW6xyeEskWhMNden2gw/GCFpZWY8eFy8/m5RFXKbEg+azeV16IEqAuXDZjqrLZpHUrXS7UBs8Eeqzeaux0ZPKBLuQqGYum8WcnzyPC6VnFLVpNqCHNYfMLJUwDHGWnL5LUXEf8Jc7uPotTUrnVMFXZJDcw6FZyx7TBBBXaFTYpagpvEOYCtamON4hyhJ/qXQq4NjpNMweCstSjUp6tkchXUU5z1UzX1RD0cw6oJI3eiDP4kMwOyMhUPPBRidwq/D0UMcj3QOQfPyQKSAdCU0GLOKAwDwoWhCXfMpLuh9EEyjgeykD5R7IZncBTOdwUBLR8v0Qyt+VTPfceiPeDdApZTSljdh9U+dp4U8PIQV92zqgaTeSrPDyoQ0ixRFJYJ+JKWx+IeyucAR8P0S2+QeyoqhSCOE8t+VA5flQKCeE7XdChDflRAaNkBBvp9UwAOySGpxlQK4CdEJaNinOVCQigIOkqOapm6oEjlEIfNSPNQnqoI5QasFh3PLqgvltHmrK1PM8NDSHf1W+qxCvWoOD6DoO45Wyn2zSqjLiKWV2/CLKdlY1KOV896zQnUrO2kK9Uu2/NXM+zVn5qb4bubrdRrsZDKdSlwGFpaVRhfhaZZlIB8xKpGAoT46YIJAMGIuus/unGKrDRcdHbH1WfE03UaNS0mIbG8pEuVhr9mYaniBTaHkluaCfNaaVOnkyiWiOFupMDy2o8ePKAuY1xMCdbKstLbkLQwgNgqkCCPPRXNG4XXly6IWEGdlD4YgecKw2t1SOGZ4A21hVGgNOoiwj1XL7Zp16+GzVGAmkZzA7brp4io6jSLmUzUM/CFmb2jh6gLarHMmxBMhce7ZXXienmRHVS3P0VmJpCjiHsa7M0HwnkbKtdpdc7MQxCDRaVCVG6ICEVLHaCjCAFTZRPQZ3lZjdiUpHWw1MilSpxBMArrPbScL0AVz6DHvqSwhrmiQStXeYpnxMDx/SV5XoCphKTh4Wub6yuZiqX2evE2IkLp/bWgw8OYdwVk7Scyqab2vDrEGP55rfFus9fFALXtgqtzI8kActwrWuD28r0POfDYlrabqNZstPwngpyxoF43/NZ3MCdjiAR138lQC0TY35RzT8UHzTRrICXIJ+EIhMRlIYW9Qs4MbWla6zQxrCd5CzvpjxECxuoosg+a20Ae6c2TlkH1WCnPmun2b3b3lr7yNOqz38a5+mYBGqsA6rUcM2PCyfNIaDRyF59ehSjKZ1MjSCk01CCvEt7yg9s7SPRZsI7Q8Lb6LAwd1iHs2BUsWMOKo1GMa98SbQFQ0xRPJn8x+y1do1hApzMGSsRP3I/m5Xfn449eqVQoAqOWmXQ7OpN7t1R8+Kw8lsys5Krb4GtaBDQLIl8aLhfddp6g5W8lSG7T7pSTujPVRRgTqsXaMd4wdFsvOq5+OdOJ8gAtc/WeviiFJ2lCVADyurkJC0YEeJ7uAAfI6rP0WjDSMPUjVzgFK1GntDDuLg9rSfLhHs/COrvDWjXeF1MMCMOxtWCWi6QVG0zAu/gKSatuNo7OotYGlocYuSUr6WUVQNqeW3Q/wB1WKz6bS6uQJuG/iV7amcX/E20i5urYzLrMcK2oJa8B4tIsfIhc+vTDPxAEGHNNo8ui7rqTXtNQlsfF06rNiKIePG2CBuJB/ZZsalcX1UmN1rqYIuuxwA6hZa2Fq0rlocOWrGN6lB4FdpebA7rqvo0sTTDXgH1v6LhESIjVNSq16Ed1UMDY3CsqVpqUMX2Y95o1HCg4jM4AHKPJNUq4Bji57quLqC0uNkKHatXvmtxAGU2JGyuxvZgq/e4RoDtXMFgeoXSVixzHVGlzsrIYTIbMx0lKanAARcx1N2WoxzDw4QlgLTJSSTJSloOoBVkIhpdslVV3I4PunbTbwjlc0jT3Vgnlq5VuA0AfhBVpaHC7R7pR5hPntt7qKGQcSPNFoA+FoHndEPH8KcFsTBUEDnbkqSeT7oSD+E+6kIFLgLG580Wuy/hB9EMsum0IuRR72/wD2RNUfKPZVG3CgM9UFwqN3Ypmp/JHqqp4H0Un1QWF1M7Kfd9VWXN0spI5QOcnKmVp0ISSPNCQgs7scj3TClOhB8lTblH/wAlBaaJBuIRFEqoZhcFMHvG5QP3buIU7s7od5UGpU75/KA5HcKBnIUFZ24B8wj33QBUQNhHLOwR75vH1U71vBQQMGzQiG8hTO2Jm3kh3lOdR7f2UU2TNJuIUa0EEXnojI5b7o2I+JqBe7IP7hAscTbThP8A+YHqmzNiJHuFBQWD5SEuQGNfZaJHzD3Skg//ACfUIKsgH/ChY3qPRWBhJmZ8lO7P8BRVeTgn2TNqOZo8+qbu+o902Ui1/dA7cQ86kH1VrXzuAqIjY/REHgqYrWA7zUzOCzh72iRBVjcW8EAx6hQWZun1RzGIKZtSm8/C0eVlY2mw6D2KgqdhKFVgLmwSNQFnf2aBdkOHC1snI3yVjXGNFdMcapQaww5sHzKU06fl6rs1Ax4hzSQstTAtN6cjoVdTHOyM5Pupkby5W1KD6Z8YIVZWkAsby5DIOT7JsyEkboBlI0d9FIPzfRGT0QkoJB+YeyMHkITOyhJ4QSHdESHcBJJ4KIJ6oCQeAhH9IQLyBuhmO5+iIYNG4UDRyUM5/gUzclqKmU3ABhKQRsU4qDopnPAKIrk8lCXKySdmogngIKxm4PsoZ4PsrwOgTAdAgy3TNJHC0QOFIHAVVQTPCFlflHAUyDgIKCRwlJ6BaDTHA9khY0fhRFHoEZHAVpayNISw3+FAtuAkc1uuUK7KECwFBtpYM0KeXuswI1bYhVZRlJdDXPf+I3CzU8bjMKYa7vKY/C660t7bouEV6BB3Lbpi6toVxQBa9+ekXQWkg5VbnLKj2PbNGmM4cdoWduMw2IOWlTDjE6GytpVACAQIPTRPh9ZmdqV6lJze7DahOvAT0abszXZZA2K3VaAc3PAzN+qrJGXomkkLnaXAb7Aq2mfEQHD1ssGIqUxaVXSxtUODWgVBOjguk6c+uP49CMMC3SSqW0Syuxtr7ShRxdWqA52De0ggyHfvCubiKNSuKkua9gMtcI1V8ox4Vj7Vtg3EfMPzXJzlwguJ8yuzjmfaA4RlaQfDyTouC1pjRYt1vmYTGMzMDxq2x8ljXRykggix1XPqNNN5Ydit8X9J1COThJqVYFpkVFIsoqgCCVs7PZNR1Q6NCyBdTC08lFrdzcrHdyNcTa34Sm51M1BVLCTxMq+cQ0asf/PRZqOM7od2WNLRpdaWY2kfiYR6yvO7A7EjL97Rfl3tIWTF/Y6lBxpQ2oLgRErpNq0X/CRPEwg+nTfZ9IGeRKsuVLNcAQVBIMgqEZKjmfKSEV6o89WgggIt3B3H5f8AKrBTtMx6hVDEQTGkaIi50UEGIRCqFxTc+FP9JlZKLyRldcTqtzhmoVG/0lYgIpz1Cii0QVpw0OeBIBO6oiDPUrRhj4xdL8J9be7xFLQmOiYYmqww9o9oKIp4mndjpH9Jn6IjFVm+Go0O8xC8r0nbiWus63mFC0PEtLT5Je8pP1bkPQIGiTem5jlFI5rm6tCx4sZazKgEAiCtzjXYIcyR5SsuLd3tBwyAObeyo8/UuSSSZTZfuR6fmUpT/wDwgdf3XocCQAhZFRoc92VoklB0MK81aet220V2Ug6qvDUe5ZBMuNyrlxv12nwsGVLppRWVSlSdWdDbACSVzccwsxTiQYOnVduk7u8DVfoSYCVuEqPpAmlLR8wXTmY59XXBtytWDwT678z6bu5YMzjBuBsF26WFw9GHCk1z+cq0v8LLb/GAdOFrWceUZh6j4OXI06ErfTwwpsawjW89Vs7SaKdKjUkEjdosRqq6NWnUPhqNPQrn1bfTcmNNJ2ZsEiRunFF3iezKHnR0KMbTIE5WnkK0OpNHirtA8wn+36ZsZoNGHGm6rUP4iLBX4ajUc4Vqj5JsAj9rwjdcQw/+SM06rS6lVDov4TK676Z8cbWVKTSWCwH1WOu973+IECdFY2mBUzXkaK/vQXDM3TdTFYmubo6SVDTzuAaxwncroh7JOvSySrUp02F74AbuVMXXA7Tp0KTg1p+91MfqsAcZRxWJFfEVHNHxuJnhIJ3Wa1DHxaha8Jj6uEGRzTUpbDcLKCmzkboOuztfBvblrNcBw5kqqriexX3NNk/0sI/Jc4PnUKZm8JpjQ/Fdlt/ysHUqHqSB+axVqz6ryW0mUm7NaNFZ4TeEJvYD2TTCMFrySmHqiHFMCVFKjmCaTwPZDNe4CggcmB6Ieg9kZ6IJMKEnhC3H1RtwihH8lAnyTHIlIG0ogCZ1/RQ+kJsvX2QAOghAI4lHKePooARsiJ/CCihG0D3Qgj+yeHcJS1xN59kA/EDuESSefQKBvMqZRwggA+Uespg4i0AeQQaxHIdoUEm9/wAkJE6Jwxv4j7Qj3bdo90FcmNPZNm5EeabIOY9QjlaPxEqism37XUBkfCfyTQ0nQn1U8ExllAI6fVCCnAGaMgnqrBQgat90FInlEq7uj8w90ponofVBUZH/AAiDyrO5cdFO5cOPdAmfp9UZ4EI927hTu3DYqKXN/IUzfyFCw8KZT1QDN0ciHnYkIR0UgoLBUcBGefOVO9IOocPJIAYUE8ILDVEXbCAezghLspbgKCz4tHKWHxEe6rLW9UMugCC7vBESVBiC0S1zvdU5OSiGA6EoNLMU8AAglaKeJa4XBHoudldoI8+Ewb6pi66veBw+Ioh8blc5pcLgx5K5mJqtNzIlTDWpzrRNuCFRVwzH3achVjcUCBmBVjXMeYDoP5ormVMPUp7ZhyFTm8l2Q0OtJngqqthGPEuZfkJqY5RcBwhn6BbH9nnWm+ehCzVMNVp/E0ha1CZ+ihclyHohlKIcOCOYKvKUCPNBbmBQJHKrA6qT1QPI5QkJSDyoAeUDjKplbrCSPJSIEygsDBt+aOTr9UkHhEFw2QWBp+YowfmKrl3X3RDnToirJdyp4twEmZyOZ3BQMCR+H6o5v6Sq853B9lDU6IGLuZUztKQ1Gpc45QWZhyEPb3SEh3CHh6Ii0MYd481BRLjDS0/+QCqhux+qPk5A5w1X5H/7VUaU6lWNe9vw1SPIqOLnmXOk8lBbgGMBe22cwQtIoZZDabpmdrLn5XZgQ6CNCDotLcZiWCHNZU66KrLjcHPawFzC0xBEysmJzOsx2UnchVuxtRwtSA/8v7KkVK9V4BaGtJuRdVCPo02m7zUctmEoCmRUyieFpwwo0oYLE7OGqvNKmdPDO40Uqz19W4ap3h4jZDtCh3lIuZIcNCNQkpfdVBmtO+y26MnUnQcrHxq1ycHUNTBGrWBztdEjeOi5+Iovp1btjN4onRdoUu5phmhEk+Z1XN7Qu+mQYsV0c2TK7grDjWkVpI1EroCfmWfHUnGmH6lp+ivNypfjA0XnhWJaXxEHhMLGF2jnRUUhQAkqodjbiBO91tZinZhNMDyKz0Zu4DorQ4z8I9lx791059RaCeU2Z3KQVDplHsm7z+gLDRg5xIuujQL2ts76lcvvR8n1V9LHPpwA0EcElSxYoxoy4yp1M+6Vjp1TYyr31UVMoaSIMKkGF34vpx6+rgEzLGeDKRplOBMxuFtha2BxZTlBpBcTGt0SIMzZVFlMbchYHHwR5fmuhSu4LngS54RROqvw93tVLrOPotOHs8KDVEaEJs7hbNI4JlQtOYwB7hHuydgvLXphddh6FTKNiR6pu5PylA0nDY+yKIfWZo8kdbpjWDwW1aUyNQq8rxsVJO4QeZKseIY0eX5BVlNVmw0A/wCP0XocCXcYC1YF7WVDTLfE7QhZJV2Eq9y8vyBwIiTt5KX4s+unBUgoNrtcA4AEHRN3jTqI9VxdghGDCYVGJmFr6jWi91BspNbTp08zfhuZ2WsPa9kzYaAnVYKwb3hdUecn4WjVX0SXEU2tyjLe+krtnpx32sYxwgky52nTkoszSXwINoO4Ct/EMkhkRPQJaTPAXHQn0UVix9Fr8IXUzLWnT5VyDRYblsr0QaHl8XYRD4/4XGr0u5rPpm8Gx5CxY1Ky9xT+UJhQp/KPZWeSgCmqTuGbNCgo5HZqbixw3bZWR0TtFtCOZVFtLHYynYllSPmEH6K7/quJH/09M+pWZvlPqmELWph6namOc3w06TPIElc+ucRiTmxFR7+hNh6LaQErmg7qWmMHdlugT5SrzTaD8V0IjcqauKsp5UyHn6q6DG/uoZ5PummKchQynhXx5oR19wppimOikHhXxzH1RDQflHqmrigBEW4Wg0hslNMc+6aKpG6hidAnNJ2wBSd24fhKCA9EzRm2QFM2sbq1jS0QLoF7snT81O5PzNVuV3qhJlTRUaDuQfVTuHdPdWEnhQvPITTFRovGke6XuqgPw/VXySjrummKMj+Ch3b92/RaLcoGOUGfK4H4D7KQ75T7K8+aEHlBQQd2kKZRrCv9keqozeiMDp7LSHEaSgXDeVBRA4ajlAOyuJbuPcKeDgeyop6gqSeVd4Ts1SBuAgpuDMI5jwrSBtHuoGjp7poqbJPCe/VNlbP90creT7oEk8lT1TZByR6oZOCUAk8qSRoj3Z5ULY/F9EBzv5Kge4KBn9X0UynZyghqE8eyHeEbBSHTqPdQNO5b7oo95/Sp3jR+H6oZTy1AtcNgfVA/eUzqCiH0+Cq4Py/VTLyCguHdnePRTKzZypyngo5TwVBblb8w9VO74hVEGLyhKDR3Y3hAtGipzxofZE1Xcn3VFuUaI5Rptwqe9O5Hsm747ZT5hBbaIH5oiwIg9LhVCrbQehU73lv1UFrSRrMeabPF7hVB7T+E+gTZ2T8J9gir2VnjQkhXU8U0G8grF3jdg4KCqyb5lMNdMVqbh/mkI5mxIdPssuDw7sUZbmawauKGINXC1CHEvaDZwEhPE2L30KdS72X5FlnqYCb06hHQosx7PxD6f3WiniKL/hePqp7i+nNqYWuzVpI5AlUlhBvB8wV3A5pHxD0ci+lTqDxNzekq+SY4WQcD6oGm07hdV+BpE+F7mnhZauEqsk5S4chWUxiNLqh3R5CtIGhnySlwB0n0VRX3L/l+qnduMiD7K8ZDdSw0JhDFDXSEwNtUr2xUMGxvqpDuEQQUUsEKXRTT0T5rXkquShmugtsRolsEA5TN1QAweiWI0ITyOiByoFy+SXIOPqnIB3QiN0QMtkC22x9EbzqgZ5QCYUk/wIETsUbqh2kTYSnDtiPqqhPJRDiN/ZBYQNYPut2DZNFtmuvMOGiwAlRtWvRJNKoI+V1whroilVbUe/KWk2GW4hKXVqQJa0gBukQCqWdqvE97QPmwyrm9qYci7ng9WlMXya6FQVWCQRImCt7IbTzvMADU7Dlcqn2jh8whziTvlXQ7zvhYjJwDqs30n1zMd2owucKNN7zsdAuZUrVazs1QC2gGy71TD0nEgsbHks1Xs+i74SW/l9UnRjlB3RMQHNggEHVaqnZr2k5XtcNs1ifRZ34LGu8FKi4k6uG3qtT2l9OVlNN7gdjCeAV06f8Ah7Gv+N1Nnm6T9FrZ/hqwz4m/9LP7rvK5VwBbdM07r0bf8NYf8VWqfKArG/4dwY/FV/3D9k1McGk0tpjrdMCV6A9h4X5qnuP2SHsKhtUqesFc7HSVxAUZXZd2G38Ndw82/wB1S/sSt+GrTPmCFMXXLlQHyW1/ZGLbo1rv9LlQ/B4mnd9B4HMSphsUVTLQlGid7SGmZkKsbrpz8Y6+rGcK9l4KzhXUzBjldI5rKdgBB+GP0TagJWwI11I+qsYBE8FUWUviAXPP+ZUPUro0v8yFzm+J1Tm6BnCXArRhtfJUgZSZ4Ctoi3UlBeQJuVMo5+qre7xm+6GZy8t+vRPi8Dh31R8XJ91SM3ITyI1UU8v+Y+6kv+Y+6TN1CDqmVpJIsg86HEK6tDmBwPVVgB2jHmOCr6AewEloYNnHULvXKKcmT4wQdm7lOKRfd1hwNkwY3NLZPUq0EDVApGVoaJgcq2k8OaATcKpzggLGxClmrLjWYhacOGtoEjXWVhbUcIE+hVtKq+mTey5+Le66GZzshZTDnm0nb+StTMPWa59UnUyAT9FzsNjGsrN2bK3YOpUqVKlWcxi3TotT4xjaQasFrcoAtI0SwxvxvzRoAsTnVz4ntN9yEok6lUaatcZS1oDQdhqVz69HOPD8Ww4WynTc74WmeVY3DPaczjcaAKVY8/3h3Cgq3+H6qzGgNxlQACJlVNAn4VnGloeDqCna5vX2VQA4KYZevuguzNHKGdvX2Vfh+YowPmKCzO3+r2QL2j5kscP+ihYT+IFRRL2nc+yI7sjUeyTI/YhQ0nncKBoGgLT6o5DwUndVOnuhkqg6D3QPljVyhHX6ITVH/KnjP/xoqB9yCSmslg703R7oQR+Fw9EDEDYqAAm/5oA30P8AtRDgNnFA2VvP1QMNEzZKX8geyTMHGSI42QODuSJTWO4VYPnCM9D7oizTcKa7qvMOqhIRT35Ujoq56n2QLupQWGeqFzskm+6YOPP0QGDCkdEufqpn6ogwpCmeyGeyCQeVIPIR7zlHPIRQDSdCpkO4BKOdTMDsiBldNvzQyO4E+abOOFM44QLlI29ipl6Ep846KZ2zr9UVXpYN+qk9CnzDn6ohw0RFdp1TeGNE4j+BGBwqKwB0RgIkCbwhlCCQE2XZKWDqplPKgfKQh5lL4tnI+Pn6oox1+qEdVJeNRKmc7tQSFLhTOOCjmbpKBbqQeE8g6EIX5CBZPCM+ia3qpbdAshSVIB2UhBLIEDWLpoCDmwwnhAIkoZRtZEOhTNKgEDp5qR5qEqIDFoAuiAIvMoW0/VX4XB1cU7wAhu7joFRSGOc4NYCSdALrq4PskNipij1yfuteHw1DBNhozVDqTqVcGOqGahts0KyM2lzFzclEBrBadPZMKTO7NMtBadQd1DVYHhgPsnWkrjY7st1OamGks3buFzGlw3XqpL7NsOVy+1sJQp0u+ZZ8wQPxLNiyuaytVp3aSPRXsx7xdwnqsshHM0kCQT1WWnTp41rx8R91YyqXXGWNyuQ4jVRlR7XeEkBTF113Np1RFRjSDoZWep2e03pOy9CqKeMe0ZT4o42WhmLpvAzGSdhqnuL6ZKuFr0pmmXDkXVIzbADpC64e02LmidBuhVw9N8FzB1MwmpjjPa4kHKFMrhsug/Ak/wCVUno5ZqlGrS+NvqrqYognZSDsFYSW3ghEG0wRKorAJ5UgixBVojcqGxvogqj+QhAVsAGSCfLVSBNteiCm235oHzVps6NfK6h4B9UFVxuEPFyFZILomfqgADoAfREJJ4QzHgpw1pPwh30UysBgwD/UgTMP4UsnaysLdw2x0hRoadpKBLlETCcho1EKFtpAMeaoW8bqCeCpY6E+6AjlAyMDhKSBqCi0g7QiLGa2C6TKuWmDAlc+kxz3BrJJOwC6+F7OsDXMn5Qmau4y0q2Kqvik0uHUWC6FPC1HQarhPDVqYxrGgNAAGwTLU4jN7qttCm0aT53TmBsihZaxgZUQUVBlSUFNEBlBCVEDIIAooiXUnoooikqMp1BFSm1w/qErLU7LwdS/dZD/AEmFtQQcqp2GNaVb0cP1WWp2bi6URTz9W3XfUkq6mPNhrmmD4Tm39FYH2jhd57GVBD2B3mFlq9mUH/ASw+4Wp0z4sVAaTqT9FzabT3lQ7XXaODrUnAiHgcLl1WmmagIIObT1V1EddxVlATVYNgqwbu81bhpDwd0AzgnUo5uqqzdEwd0C8z0LA5GSkDuicEHZRQlV1nSQ31VpIAJMQOiroM72rJ01Qjl5YMgeoTWc29yOV3QcM4RloweIVVD7K3EPbSa0OG8zK6+TGOO082HPCh01DgdwvQVaWHe3NVps8wsdbseJdhjI3boVZUxywAfiuobf8LS/Dvpj7ym5pncWKQNaYBmSYsqhM07+iJzOFhCtFFubQzwtlDsurVAdU+6Zy7U+ig59Kk+o8MYCSV2+znuFBsjUbLLXxFDAsdSwrc1U2Ljc+v7KrBYvF4amGua14HWCs61jvMeIOg9Uwc123suSe2KgH/tBPUqip2vi3AinSZT6gSVdTHS7UxjqDG06TgKjtY2C4jsW+lWFU1czxyZnoqan2is8uqVDLtUGYaLwpsWRc6cTVdVgNzbSnGGfrb3SNouA0RyOCy0fuKg/CgKVT5ShLhyERUqj8RUByPH4T7IEH5UwrVdMxTd+/e/ooqoD+lSOhVvfvOzfZA1zuxvsiq79fdKZ5crTVafwBTvG70wiKpI3IQzH5irc9I/hI9Uc1E7OCCiXfMVC53zfRWzR/qUikdC5BVLt3fRTM4bq4Cju5ygbQ+dyKplx3Ul3IV4bRP8A8h9Wo93S1Fb/APFEZy53RSXkLR3LCbVW+yJotAP3jCis+Z41AUD3fKFf9nnRzDPVTuIvmYUFWc/KFM52aVb9nJ3Z7lT7K86QfIoKg4jUFEuHyqz7LUH4T7hA4eo2+U+l0FZc0fhQzM6pzTeDcP8A9qGR3UeYQCW7Sj4N5RLHAXAQgfK1AcrDoYQyN+YeyYMn8I90Msfh+qBcg+YIinO4Uj+k+6mXo5Ae6P8AClNF3T3TQRuQpJ+ZAvdu4UNN/wApTS4/iQkjeUQmR3BUyOVgJRk8KimDpKgkbhXgkAkW20S951PsmmK9eE3qPdN3h4d7JS8nWR6ICCevupmdsfqlloMmSlc4Hn2QWBxO30UzkahUhw6+yma9yY/0oLg+dQjngf3VUt/qUMDZx9EFmcIhw5VVuCPQqTOx9lFW5hyEZGllQS/YFSKs/wDCIvgDZX4OgyqXEiYWNrXD4j+S6fZrfunHkpVhnYak95LmOB6FL9hYZh9QdNVti6Nlkc84ERao8dCEpwJmG1hHULpoRyqOWcFWHwua8eaU4PEFjhlEbwV1i0Hb6JCAmjkOw1UD4HegSZHCxBB8l2g0FqD22EzZTRxS0jUKBpJAbcnQBde2rmgnkiVIDTmYQx3IaqEwXZJIFTFGG65J/NdEPJHd4doa0WmLBYnVqrm5e89Sm7+s0AMqCFrUxvaxtJuY3PKV571paJb5rH39Um+V3mrGV6zadmNhNiYuHd0BJu7TzQJqVdfC3hUCq/MXloJ67J/tcRNI+hSWLZV94gaLkdsVc9ZtEaUxfzK3nFmbUj7rmPwJe9z31HS4yTlS2fpJLvtkgclGAf8AlaTgSNKp6S1L9ieDHetnyWWmUs6geqIbf4pWluBe50d6yeoSvwFWSRVY6OFRTYboiD19YTjBVcslzfKUwwVXbIfVAjXFmjsvSVazGFm4UGDqnQs/3KfYqpkyz3UGmljabrOAnkhaW1qTgYLSVzPsVa3wnpKZuFrg2gHoVMXW5+GpVLhgaeQs1XBPA8Lg4cEIM+1MFrgeSdmLvDzlITKMjmmmYewt8wlLZvC6oqNePjaZ2KrqYWk+4GU/0mFdHNNtlDYafVaH4KoPgh3rCz1KdSmYfTIV1Cl7YS2m952Rg/L6oAEaxCARGugUJvMbIwRpA8ghB3+qBZv4riNDspJmBAHkmDTGyDuP0RC67lQwLhNtqfZS0QgUguUjqExg6x5BEEfhsgTKT1UkzdONIH0SxeYKoFuFdhsO/E1Q2mPMpaNJ1aqKbBJP0Xo8HhWYekGtHmeVZGbcDCYOnhmQ0S7dx1K0Ka2UW4whUQJUlUFBCVJUBUSypKBlCllGVREUpKkoCillSUBRSypKBlJSypKBlEJUlAUFJQlAZKWpTp1m5arA4dQiogw1eyqZJdQeWk7OuFl+zVcPVHeMIE67LsIyYvcK6mOAe5OrCPJQspnR3uutWwNCtdv3bumiw1sFWo6jM3kLlZXWWMpZHKAPVXBjxsfZSLS9ojqFlWeo+waDqteFZkpSdSstNne17CAugBcCFnqtSOQabeEmRueIUUXRgXTky5nRxJWrB9oV2vDCWuA3IuootI6mBxD8Thw+oGkmZACvOGoVG+KiyecqiiMoKdOhelTY08wuN2p2hiDiO4Dg1pFyNT6qKKKy02NzaK8CFFEVMoOyR4AUUUoWINifdRhM6lRRRVmd0aoZzGyiiioKhnZEOKiiBtpRCiiKkAnRQgcBRRBMjTslc0AGyiiABjY0SlonRRRBCxv8KBaAooiFc0IFoUURUIshAlRRAVOFFEER9SooghJFgVA48qKKA53DRxCYVHz8bteVFFQRWqD8Z90wxFX5lFFFT7TV+f6KDE1CbkH0UUQP3xOrWH/xRDg7Wmz2UUUBDWE/A3ZOKbIHh+pUUVD9ww8j1Suw7fmf7qKIFNBojxO90CxolRRAjgBsPZKYA0CiiIDZDGw46DYISeVFFQwI4CGa8ZW+yiiBCZGg9khH8hRREQNEf2RDAooggaJ0HsjlE6D2UURQgcD2QEToPZRRBABwPZSBwPYKKIBlH8C6vZv/ALUeaiilGtu6gUUUADjdMoogh0KUXYooig3ROLi6iiBC0CVS8mFFECuJgKMJLbqKKoNO4utU/dKKKAbhQ6GwUUQO34Qlf8JUUQZ6jiGmClc4lgBKiioSt8GqNIkKKKi6ZcLBEaiyiigcASbK2lZugUUQPrsFIHAUUQALiYwluJqAaToookFYqOHHsrqeKqtAgj2UUSrGuniXuiQ32VziHC7QZUUWVVVcHRcCcuUj5VzqtNrHZRfzUUWozVZA4CBUUVAGoQOkqKIJA4CO6iiIDb6qEeLhRRApF9SoooqOz2HSZ3TqkeImJXVNoUUW4xWGpVqOquGYgAwIQbXqNI8U+d1FF87y6/yfXbJ4tWYkBSSoovpPOElSVFEAJUlRRAQVJUUQAkqSooqIpKiiCSpKiiCSVAVFEBUlRRAUJUUQSbKSoogkqAqKICgHkGNlFEFWKw9M0jUaCxwE+ExK49aq/uy3MSDZRRcq6Rbgmjuy7daRaT0UUXK/XSP/2Q==", "firstName": "", "middleName": "Pravin", "lastName": "", "dayOfBirth": "11", "monthOfBirth": "05", "yearOfBirth": "1997", "gender": "M", "email": "", "mobile": "", "address": "
", "stateName": "Maharashtra", "districtName": "Nashik", "pinCode": "", "stateCode": "27", "districtCode": "12" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `profilePhoto` (string, required) - `firstName` (string, required) - `middleName` (string, required) - `lastName` (string, required) - `dayOfBirth` (string, required) - `monthOfBirth` (string, required) - `yearOfBirth` (string, required) - `gender` (string, required) - `email` (string, required) - `mobile` (string, required) - `address` (string, required) - `stateName` (string, required) - `districtName` (string, required) - `pinCode` (string, required) - `stateCode` (string, required) - `districtCode` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "abhaAddress": "", "fullName": "Hemant Bodhai", "firstName": "", "middleName": "", "lastName": "", "dayOfBirth": "14", "monthOfBirth": "11", "yearOfBirth": "1995", "dateOfBirth": "14-11-1995", "gender": "M", "email": "", "mobile": "", "abhaNumber": "", "address": "
", "stateName": "Maharashtra", "districtName": "Nashik", "pinCode": "", "stateCode": "27", "districtCode": "123", "authMethods": [ "MOBILE_OTP", "AADHAAR_OTP" ], "status": "ACTIVE", "emailVerified": "false", "mobileVerified": "true", "kycStatus": "VERIFIED", "abhaLinkedCount": "3" } ``` --- # Verify AADHAAR Otp - Link-DeLink `POST /login/profile/verify` Verifies the Aadhaar OTP for a link or delink transaction and returns the accounts it applies to. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/login/profile/verify \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "" ], "authData": { "authMethods": [ "" ], "otp": { "txnId": "", "otpValue": "" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `scope` (string[], required) - `authData` (object, required) - `authData.authMethods` (string[], required) - `authData.otp` (object, required) - `authData.otp.txnId` (string, required) - `authData.otp.otpValue` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "message": "", "authResult": "", "users": [ { "abhaAddress": "", "fullName": "", "abhaNumber": "", "status": "", "kycStatus": "" } ], "accounts": [ { "mobile": "", "firstName": "", "middleName": "", "lastName": "", "name": "", "yearOfBirth": "", "dayOfBirth": "", "monthOfBirth": "", "gender": "", "email": "", "profilePhoto": "", "status": "", "stateCode": "", "districtCode": "", "subDistrictCode": "", "villageCode": "", "townCode": "", "wardCode": "", "pincode": "", "address": "
", "kycPhoto": "", "stateName": "", "districtName": "", "subdistrictName": "", "villageName": "", "townName": "", "wardName": "", "authMethods": [ "" ], "kycVerified": false, "verificationStatus": "", "verificationType": "", "emailVerified": "", "ABHANumber": "", "preferredAbhaAddress": "" } ], "tokens": { "token": "", "expiresIn": 0, "refreshToken": "", "refreshExpiresIn": 0 } } ``` --- # Verify ABHA OTP `POST /profile/phr/verify` Verifies the OTP sent for a profile change and returns the accounts and tokens it applies to. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/profile/phr/verify \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "scope": [ "" ], "authData": { "authMethods": [ "" ], "otp": { "txnId": "", "otpValue": "" }, "password": { "abhaAddress": "", "password": "" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `scope` (string[], required) - `authData` (object, required) - `authData.authMethods` (string[], required) - `authData.otp` (object) - `authData.otp.txnId` (string, required) - `authData.otp.otpValue` (string, required) - `authData.password` (object) - `authData.password.abhaAddress` (string, required) - `authData.password.password` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "txnId": "", "message": "", "authResult": "", "users": [ { "abhaAddress": "", "fullName": "", "abhaNumber": "", "status": "", "kycStatus": "" } ], "accounts": [ { "mobile": "", "firstName": "", "middleName": "", "lastName": "", "name": "", "yearOfBirth": "", "dayOfBirth": "", "monthOfBirth": "", "gender": "", "email": "", "profilePhoto": "", "status": "", "stateCode": "", "districtCode": "", "subDistrictCode": "", "villageCode": "", "townCode": "", "wardCode": "", "pincode": "", "address": "
", "kycPhoto": "", "stateName": "", "districtName": "", "subdistrictName": "", "villageName": "", "townName": "", "wardName": "", "authMethods": [ "" ], "kycVerified": false, "verificationStatus": "", "verificationType": "", "emailVerified": "", "ABHANumber": "", "preferredAbhaAddress": "" } ], "tokens": { "token": "", "expiresIn": 0, "refreshToken": "", "refreshExpiresIn": 0 } } ``` --- # verify and assign `POST /family-management/verify-and-assign` Verifies the OTP for a family link transaction and, in the same step, links the given ABHA address under the relationship type. May also unassign a previous address. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/family-management/verify-and-assign \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "abhaAddressToLink": "", "txnId": "", "relationshipTypeId": 0, "abhaAddressToUnassign": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `abhaAddressToLink` (string) - `txnId` (string, required) - `relationshipTypeId` (integer, required) - `abhaAddressToUnassign` (string) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "", "success": false, "relationshipId": "" } ``` --- # Verify User Switch Profile `POST /profile/phr/verify/switch-profile/user` Completes a profile switch: selects the ABHA address to continue as and returns its session tokens. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/profile/phr/verify/switch-profile/user \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "abhaAddress": "", "txnId": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `abhaAddress` (string, required) - `txnId` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "token": "", "expiresIn": 1800, "refreshToken": "", "refreshExpiresIn": 1296000 } ``` --- # Verify - User `POST /login/phr/verify/user` Completes a login that matched more than one account: selects the ABHA address to sign in as and returns its session tokens. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/login/phr/verify/user \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "abhaAddress": "", "txnId": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `abhaAddress` (string, required) - `txnId` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p1/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "token": "", "expiresIn": 0, "refreshToken": "", "refreshExpiresIn": 0 } ``` --- # P1 PHR identity and profile errors Seeing a symptom rather than a code? Start at [Troubleshooting](/docs/hiecm/v3/troubleshooting/). ## Codes Code and message are as published. The action column reads the message text by a documented rule. These codes are the PHR facing wording of the core ABDM codes, row for row. | Code | Message | What to do | | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | | `AS-1001` | Database connection failed. Please try again later. | Retry | | `AS-1002` | No results found for the given input. | Fix request | | `AS-1003` | There seems to be a data integrity issue. Please contact support team. | Unclassified | | `AS-1004` | Email gateway is temporarily unavailable. | Retry | | `AS-1005` | SMS gateway is temporarily unavailable. | Retry | | `AS-1006` | The recipient information is invalid. Please check and try again. | Retry | | `AS-1007` | Request could not be processed due to invalid data format. Please review and try again. | Retry | | `AS-1008` | Timeout error: Unable to connect to the server. | Retry | | `AS-1009` | SMS service is temporarily unavailable. | Retry | | `AS-1010` | Email service is temporarily unavailable. | Retry | | `AS-1011` | Validation failed. | Unclassified | | `AS-1012` | Gateway database unavailable | Retry | | `AS-1013` | No records found against the entered ABHA Address | Fix request | | `AS-1014` | Please enter a valid ABHA number. | Fix request | | `AS-1015` | Please enter a valid mobile number and email address . | Fix request | | `AS-1016` | Invalid Response | Fix request | | `AS-1017` | The timestamp format is incorrect. | Fix request | | `AS-1018` | Transaction ID is incorrect or has expired. | Cannot proceed | | `AS-1019` | Share Profile database unavailable | Retry | | `AS-1020` | Dependent Service is unavailable. | Retry | | `AS-1021` | Unknown database | Unclassified | | `AS-1022` | Permission denied - required privileges are missing. | Cannot proceed | | `AS-1023` | You have made too many requests. Please wait a moment and try again. | Retry | | `AS-1024` | Please enter a valid and registered user ID. | Fix request | | `AS-1025` | Dependent Service is unavailable. | Retry | | `AS-1026` | The selected service is invalid. Please check and try again. | Retry | | `AS-1027` | The entered Bridge ID does not exist. Please verify and try again. | Retry | | `AS-1028` | Link token is incorrect or has expired. | Cannot proceed | | `AS-1029` | Your account is currently blocked. Please try again after 24 hours. | Cannot proceed | | `AS-1030` | The requested HIP service is currently not accessible. Please try again later. | Retry | | `AS-1031` | Redis server is temporarily unavailable. | Retry | | `AS-1032` | The request ID is invalid. Please check and try again. | Retry | | `AS-1033` | Invalid request. Please check and try again. | Retry | | `AS-1034` | The request header is invalid or missing required information. Please try again. | Retry | | `AS-1035` | The requested HIU service is currently not accessible. Please try again later. | Retry | | `AS-1036` | Notification service is temporarily unavailable | Retry | | `AS-1037` | Please enter a valid and registered HIP Id. | Fix request | | `AS-1038` | The entered OTP is incorrect or has expired. Please re-enter the correct OTP. | Cannot proceed | | `AS-1039` | The entered information doesn’t match our records. Please verify and try again. | Retry | | `AS-1040` | The number of care contexts does not match the expected count. Please verify the data. | Unclassified | | `AS-1041` | ABHA address does not match the linked token. Please check and try again. | Retry | | `AS-1042` | The consent request ID is invalid . Please verify and try again. | Cannot proceed | | `AS-1043` | Please enter a valid and registered HIU Id. | Fix request | | `AS-1044` | Please enter a valid and registered Locker Id. | Fix request | | `AS-1045` | Acknowledgement is invalid or not properly formatted. Please try again. | Retry | | `AS-1046` | Provider is Mandatory | Unclassified | | `AS-1047` | Please enter a valid and registered provider Id. | Fix request | | `AS-1048` | The ABHA address you entered doesn’t match the KYC details. Please verify and try again. | Retry | | `AS-1049` | Failed to send the broadcast message. Please try again later. | Retry | | `AS-1050` | You do not have permission to access the database. Please contact your administrator. | Unclassified | | `AS-1051` | The selected purpose is invalid. Please verify and try again | Retry | | `AS-1052` | The selected purpose is does not exist. Please verify and try again | Retry | | `AS-1053` | Validation failed | Unclassified | | `AS-1054` | Request timed out. Please try again. | Retry | | `AS-1055` | The profile share intent keys are invalid. Please check and try again. | Retry | | `AS-1056` | The profile share metadata keys are invalid. Please review the shared data. | Fix request | | `AS-1057` | The ABHA number or ABHA address entered is invalid. Please check and try again. | Retry | | `AS-1058` | There was an issue while encoding the content. Please try again. | Retry | | `AS-1059` | The Transaction ID or response’s Request ID is invalid. Please verify and retry. | Fix request | | `AS-1060` | Unable to load overlay image. Please refresh or try again later. | Retry | | `AS-1061` | The entered data already exists in the system. | Fix request | | `AS-1062` | We couldn’t convert the file to PNG format. Please try again or check the file type. | Retry | | `AS-1063` | The subscription request ID is invalid. Please check and try again. | Retry | | `AS-1064` | An error occurred while generating the QR code. Please retry after some time. | Unclassified | | `AS-1065` | The HIP ID or PHR address is invalid. Please check and try again. | Retry | | `AS-1066` | The selected care context is already associated with your ABHA address. | Fix request | | `AS-1067` | The link reference number is invalid. Please check and try again. | Retry | | `AS-1068` | The care context information provided is invalid. Please verify and retry. | Fix request | | `AS-1069` | The health information types provided are invalid. | Fix request | | `AS-1070` | The number of care contexts does not match the expected count. Please review the request. | Unclassified | | `AS-1071` | The patient reference number is invalid. Please check and try again. | Retry | | `AS-1072` | Patient display information is invalid or missing. | Fix request | | `AS-1073` | The consent artefact has expired. Please generate a new one to proceed. | Cannot proceed | | `AS-1074` | The ABHA number you entered doesn’t match the linked token. Please verify and try again. | Retry | | `AS-1075` | The ABHA number you entered doesn’t match the linked token. Please verify and try again. | Retry | | `AS-1076` | Consent has not been granted. | Cannot proceed | | `AS-1077` | The ABHA number you entered doesn’t match the linked token. Please verify and try again. | Retry | | `AS-1078` | The HIP Id doesn’t match the linked token. Please verify and try again. | Retry | | `AS-1079` | The selected date range is invalid. | Fix request | | `AS-1080` | The request could not be processed because the request body is missing. | Fix request | | `AS-1081` | A request with this request ID already exists. | Fix request | | `AS-1082` | Invalid X Auth token | Fix request | | `AS-1083` | Health facility does not exist. Please check and try again. | Retry | | `AS-1084` | JWT token is invalid | Fix request | | `AS-1085` | Please enter a valid password. | Fix request | | `AS-1086` | Request body is not required. | Fix request | | `AS-1087` | Both patient details and error information are missing. Please provide at least one. | Fix request | | `AS-1088` | The authentication type provided is invalid. Please check and try again. | Retry | | `AS-1089` | A consent request with the same details already exists. | Cannot proceed | | `AS-1090` | The login credentials provided are incorrect. Please try again. | Retry | | `AS-1091` | At least one source must be included in the request. | Unclassified | | `AS-1092` | This user is not part of your organisation. Access denied. | Cannot proceed | | `AS-1093` | The consent PIN entered is invalid. Please check and try again. | Cannot proceed | | `AS-1094` | At least one source must be included in the request. | Unclassified | | `AS-1095` | User not found. Please verify and try again. | Retry | | `AS-1096` | The provided consent PIN does not exist. | Cannot proceed | | `AS-1097` | HIP object must be empty when consent is applicable to all HIPs. | Cannot proceed | | `AS-1098` | Your user or manager profile is not e signed. | Unclassified | | `AS-1099` | HIP object cannot be null in excluded sources | Unclassified | | `AS-1100` | Organisation was not found | Fix request | | `AS-1101` | Included sources must contain a valid HIP object. | Unclassified | | `AS-1102` | User ID already exist | Fix request | | `AS-1103` | One or more HIPs provided in the request are invalid. | Fix request | | `AS-1104` | The registration number provided is incorrect. | Fix request | | `AS-1105` | Auto approval policy id doesn't exist. | Unclassified | | `AS-1106` | The uploaded file format is not supported. Please upload a valid format. | Fix request | | `AS-1107` | The auto-approval ID provided is invalid. | Fix request | | `AS-1108` | Document upload failed. Please try again. | Retry | | `AS-1109` | This auto-approval ID has already been disabled. | Fix request | | `AS-1110` | Failed to update user status. Please try again later. | Retry | | `AS-1111` | This subscription request has already been processed. | Fix request | | `AS-1112` | Upload your organisation ID card image to proceed. | Unclassified | | `AS-1113` | The consent artefact ID is invalid. Please verify and try again. | Cannot proceed | | `AS-1114` | Upload your organisation ID card image to proceed. | Unclassified | | `AS-1115` | Subscription approval data is invalid in payload. Please check and try again. | Retry | | `AS-1116` | Upload your organisation’s registration certificate to continue. | Unclassified | | `AS-1117` | A care context exists without an associated HIP ID. Please correct the request. | Unclassified | | `AS-1118` | Duplicate consent approve request | Cannot proceed | | `AS-1119` | Upload an official authority letter from your organisation. | Unclassified | | `AS-1120` | The subscription ID is invalid. Please check and try again. | Retry | | `AS-1121` | The user is not associated with your organisation. Access denied. | Cannot proceed | | `AS-1122` | ABHA number does not match the X Auth token. Please verify your session. | Unclassified | | `AS-1123` | Aadhaar details do not match our records. Please review and select the correct information. | Fix request | | `AS-1124` | Aadhaar details do not match our records. Please review and select the correct information. | Fix request | | `AS-1125` | ABHA number does not match the X Auth token. Please verify your session. | Unclassified | | `AS-1126` | User not found. Please verify and try again. | Retry | | `AS-1127` | Patient profile does not match the X Auth token. Please verify your session. | Unclassified | | `AS-1128` | No transaction found for the provided UUID. | Unclassified | | `AS-1129` | A patient share request with the same details already exists. | Fix request | | `AS-1130` | Sorry, your session is expired. Please login to continue. | Cannot proceed | | `AS-1131` | Health information cannot be null | Fix request | | `AS-1132` | Captcha verification failed. Please enter the correct code to continue. | Fix request | | `AS-1133` | Payment information cannot be null | Fix request | | `AS-1134` | Captcha expired or not loaded. Please reload and try again. | Cannot proceed | | `AS-1135` | Duplicate HIP link request | Unclassified | | `AS-1136` | You can export up to 500 records at a time. | Unclassified | | `AS-1137` | A similar request to get links already exists. Please try again later. | Retry | | `AS-1138` | The ABHA number must be 14 digits. Please correct it and try again. | Retry | | `AS-1139` | Duplicate Link token request | Unclassified | | `AS-1140` | A valid consent was not found for this request. | Cannot proceed | | `AS-1141` | A bridge request with these details already exists. | Fix request | | `AS-1142` | The transaction ID or consent artefact ID provided is invalid. Please verify and try again. | Cannot proceed | | `AS-1143` | A bridge patch request for this transaction already exists. | Fix request | | `AS-1144` | You are not authorized to update the status | Cannot proceed | | `AS-1145` | A bridge service request with the same details already exists. | Fix request | | `AS-1146` | Please enter a valid registered email address. | Fix request | | `AS-1147` | Duplicate Gateway Consent Manager request | Cannot proceed | | `AS-1148` | Duplicate Gateway Consent Manager patch request | Cannot proceed | | `AS-1149` | Duplicate Gateway Government Program request | Unclassified | | `AS-1150` | Duplicate Subscription request | Unclassified | | `AS-1151` | Duplicate Subscription Approve request | Unclassified | | `AS-1152` | You've reached the maximum number of OTP attempts or the OTP wasn’t generated. Please wait 30 minutes and try again with a new OTP. | Retry | | `AS-1153` | Duplicate Health Information request | Fix request | | `AS-1154` | This ABHA Address already exists. Please create with unique ABHA address. | Fix request | | `AS-1155` | Profile information cannot be empty | Fix request | | `AS-1156` | Mobile number verification is pending. | Unclassified | | `AS-1157` | Duplicate Discovery request | Unclassified | | `AS-1158` | Linking with CHILD ABHA Number is not allowed. | Unclassified | | `AS-1159` | Duplicate Init request | Unclassified | | `AS-1160` | You cannot link with sameABHA Number.Please use a different ABHA Number. | Unclassified | | `AS-1161` | Duplicate Confirm request | Unclassified | | `AS-1162` | The request for linking a parent profile is invalid. Please check the details and try again. | Retry | | `AS-1163` | Duplicate On discovery request | Unclassified | | `AS-1164` | Duplicate On init request | Unclassified | | `AS-1165` | The selected scopes combination are not valid together. | Unclassified | | `AS-1166` | Duplicate On confirm request | Unclassified | | `AS-1167` | Notification service is currently unavailable. Please try again later. | Retry | | `AS-1168` | The On-Discovery response received is invalid. Please try again. | Retry | | `AS-1169` | ABHA database is currently unavailable. Please try again later. | Retry | | `AS-1170` | Invalid On init response | Fix request | | `AS-1171` | Your new password must be different from your old password. Please enter a unique new password. | Fix request | | `AS-1172` | Invalid On confirm response | Fix request | | `AS-1173` | The old password entered is incorrect. Please try again with a valid password. | Retry | | `AS-1174` | The consent artefact ID is either invalid or has expired. | Cannot proceed | | `AS-1175` | Please ensure both old and new passwords are encrypted | Unclassified | | `AS-1176` | Duplicate health information provider data flow response | Fix request | | `AS-1177` | Please enter a valid Captcha | Fix request | | `AS-1178` | Duplicate health information notification request | Fix request | | `AS-1179` | User not found. Please verify and try again. | Retry | | `AS-1180` | Patient information is invalid. Please provide at least one valid patient detail. | Fix request | | `AS-1181` | Mobile number not found. | Fix request | | `AS-1182` | The Auto approval request is invalid | Fix request | | `AS-1183` | Aadhaar details not found in the system. | Fix request | | `AS-1184` | This auto approval id is already active | Fix request | | `AS-1185` | Login using password is not allowed. Please use other login methods. | Unclassified | | `AS-1186` | Duplicate auto approval request | Unclassified | | `AS-1187` | Login via ABHA Number OTP is not allowed. Please use other login methods. | Unclassified | | `AS-1188` | Invalid subscription edit payload | Fix request | | `AS-1189` | Login via Aadhaar OTP is not allowed. Please use other login methods. | Unclassified | | `AS-1190` | No care context is available for this patient. | Unclassified | | `AS-1191` | Missing or invalid request ID header. Please ensure a valid REQUEST\_ID is provided. | Fix request | | `AS-1192` | The enrolment number entered is invalid. Please verify and try again. | Retry | | `AS-1193` | Your request could not be processed at the moment. Please try again later. | Retry | | `AS-1194` | User authentication failed | Unclassified | | `AS-1195` | The mobile number provided by you is already linked to 6 ABHA numbers. Please provide a different mobile number. | Fix request | | `AS-1196` | The mobile number provided by you is already linked to 6 ABHA numbers. Please provide a different mobile number. | Fix request | | `AS-1197` | Both ABHA number and ABHA address cannot be null | Unclassified | | `AS-1198` | Sorry, your session is expired. Please login to continue. | Cannot proceed | | `AS-1199` | Invalid F-Token | Fix request | | `AS-1200` | Sorry, your session is expired. Please try again. | Cannot proceed | | `AS-1201` | Invalid T-Token | Fix request | | `AS-1202` | Invalid X-Token | Fix request | | `AS-1203` | X-Token Expired | Cannot proceed | | `AS-1204` | Kindly enter valid linked ABHA Address | Fix request | | `AS-1205` | The captcha result entered is incorrect. Please try again with the correct value. | Retry | | `AS-1206` | This ABHA account has been deactivated. | Cannot proceed | | `AS-1207` | The email address provided by you is already linked to 6 ABHA Numbers. Please provide a different email address. | Fix request | | `AS-1208` | Message cannot be null or empty. | Unclassified | | `AS-1209` | Benefit name not found. Please check the entered details. | Fix request | | `AS-1210` | This benefit record has already been de-linked. | Fix request | | `AS-1211` | No benefit record found for the given details. | Unclassified | | `AS-1212` | The benefit record has already been linked | Fix request | | `AS-1213` | This account already exist | Fix request | | `AS-1214` | Captcha has expired. Please enter a new captcha. | Cannot proceed | | `AS-1215` | Captcha attempts exceeded. | Unclassified | | `AS-1216` | Captcha attempts exceeded. | Unclassified | | `AS-1217` | This subscription is already enabled | Fix request | | `AS-1218` | The facility ID or password is incorrect. Please check and try again. | Retry | | `AS-1219` | This subscription is already disabled. | Fix request | | `AS-1220` | Subscription is not in revoked state | Unclassified | | `AS-1221` | Subscription is not in granted stat | Unclassified | | `AS-1222` | This subscription ID does not belong to the patient. | Unclassified | | `AS-1223` | The requested intent type is not supported at the HIP. | Unclassified | | `AS-1224` | Bridge API version cannot be null | Unclassified | | `AS-1225` | Health locker has already been set up for this user. | Fix request | | `AS-1226` | No active subscription found for the selected health locker. | Unclassified | | `AS-1227` | Unable to create auto-approval consent for the health locker. Please try again later. | Cannot proceed | | `AS-1228` | Unable to save user health locker details. | Unclassified | | `AS-1229` | Parents must be 18 years of age or older to create a Child ABHA Account | Unclassified | | `AS-1230` | Please ensure that the mobile number is mapped to the parent’s ABHA number | Unclassified | | `AS-1231` | Maximum number of Child ABHA accounts reached for the given ABHA number ‘%s’ | Unclassified | | `AS-1232` | Invalid X-Token | Fix request | | `AS-1233` | Children must be under '%s' years of age as of today to create a Child ABHA. | Unclassified | | `AS-1234` | Non KYC CHILD ABHA is allowed to update their profile only once | Unclassified | | `AS-1235` | The ABHA address entered is invalid. Please verify and try again. | Retry | | `AS-1236` | LGD Gateway is currently unavailable. Please try again later. | Retry | | `AS-1237` | IDP Gateway is currently unavailable. Please try again later. | Retry | | `AS-1238` | Document Gateway is currently unavailable. Please try again later. | Retry | | `AS-1239` | TEST | Unclassified | | `AS-1240` | TEST | Unclassified | | `AS-1241` | Document DB Gateway is currently unavailable. Please try again later. | Retry | | `AS-1242` | Aadhaar Gateway is currently unavailable. Please try again later. | Retry | | `AS-1243` | The information you provided does not match the details on record with Aadhaar. Please verify and provide accurate information. | Fix request | | `AS-1244` | The information you provided does not match the details on record with Aadhaar. Please verify and provide accurate information. | Fix request | | `AS-1245` | ABHA profile gateway is currently unavailable.Please try again later. | Retry | | `AS-1246` | PHR DB service is currently unavailable. Please try again later. | Retry | | `AS-1247` | Duplicate Notification request | Unclassified | | `AS-1248` | Login via Email Address OTP is not allowed. Please use other login methods. | Unclassified | | `AS-1249` | You have exceeded the email sending limit. Please wait before trying again. | Unclassified | | `AS-1250` | User not found. Please verify and try again. | Retry | | `AS-1251` | Email address not found. | Fix request | | `AS-1252` | User not active. | Unclassified | | `AS-1253` | Mobile/Email verification is pending. | Unclassified | | `AS-1254` | Login via Mobile Number OTP is not allowed. Please use other login methods. | Unclassified | | `AS-1255` | The ABHA Address is deactivated. | Cannot proceed | | `AS-1256` | Login is not allowed | Unclassified | | `AS-1257` | No role has been assigned to this user. | Unclassified | | `AS-1258` | Notification templates not found | Fix request | | `AS-1259` | Your ABHA is linked with govt benefit programme, so it can not be deleted- ABDM, National Health Authority. | Unclassified | | `AS-1260` | Sorry, Unable to process your request at this time. Please try again later. | Retry | | `AS-1261` | Face verification has been failed, please try again. | Retry | | `AS-1262` | Fingerprint verification has been failed, please try again. | Retry | | `AS-1263` | IRIS verification has been failed, please try again. | Retry | | `AS-1264` | Biometric login is currently not allowed. Please use an alternate login method. | Unclassified | | `AS-1265` | The email ID provided does not match the one registered. Please check and try again. | Retry | | `AS-1266` | Mobile number is not linked to your ABHA address. Please update your mobile number in ABHA. | Unclassified | | `AS-1267` | HIP is currently unavailable. Please try again later. | Retry | | `AS-1268` | Your mobile number is not linked to the ABHA number. Please update your mobile number in ABHA or try to register using Aadhaar OTP | Unclassified | | `AS-1269` | No acknowledgement was received from the HIP. Please try again later. | Retry | | `AS-1270` | Invalid callback resp id | Fix request | | `AS-1271` | Invalid Refresh token | Fix request | | `AS-1272` | The grant type is invalid. Please check the request and try again. | Retry | | `AS-1273` | The client ID is invalid. Please verify and try again. | Retry | | `AS-1274` | The client secret is invalid. Please verify and try again. | Retry | | `AS-1275` | Both client ID and secret are invalid. Please verify and try again. | Retry | | `AS-1276` | Service ID ‘%s’ already exists. Please use a different service ID. | Fix request | | `AS-1277` | HFR request failed, but rollback was successful for HFR ID ‘%s’. | Unclassified | | `AS-1278` | The bridge registry request is invalid. Please verify and try again. | Retry | | `AS-1279` | All the provided service IDs do not match with the client ID | Unclassified | | `AS-1280` | HIP did not acknowledge the HIP consent notify. Please try again after some time | Cannot proceed | | `AS-1281` | An unknown error occurred. Please try again later | Retry | | `AS-1282` | Invalid X Auth token | Fix request | | `AS-1283` | Patient profile mismatch with X Auth token | Fix request | | `AS-1284` | Access Denied | Cannot proceed | | `AS-1285` | Cannot process the request at the moment, please try later. | Retry | | `AS-1286` | Open order not found | Fix request | | `AS-1287` | Error in making call to target system Content type 'text/html' not supported for bodyType=java.util.HashMap | Unclassified | | `AS-1288` | Cannot find any linked ABHA address. Please create ABHA address first. | Unclassified | | `AS-1289` | OTP is not verified for this transaction | Unclassified | | `AS-1290` | User is not kyc verified | Unclassified | | `AS-1291` | Self-relationship not allowed | Unclassified | | `AS-1292` | Duplicate relationship not allowed.A relationship already exists between %s and %s | Fix request | | `AS-1293` | We are facing some issue in server connectivity. Please try again | Retry | | `AS-1294` | UIDAI Error code : 300 : Biometric data did not match. | Unclassified | | `AS-1295` | The mobile number you have entered does not match with any of the records Please enter a different number | Fix request | | `AS-1296` | You can request for new OTP after 30 seconds timestamp %s | Unclassified | | `AS-1297` | This account is deactivated Please continue to reactivate abhaNumber %s | Cannot proceed | | `AS-1298` | It appears that you are either not connected to the internet or experiencing a slow connection. please try again. | Retry | | `AS-1299` | UIDAI Error code : 953 : You have requested multiple OTPs in this transaction. Please try again in 30 minutes. | Retry | | `AS-1300` | The mobile number you have entered has already been verified. Please provide an alternate mobile number. | Fix request | | `AS-1301` | Old and New Passwords are same | Unclassified | | `AS-1302` | This account is deactivated. Please reactivate it from ABHA portal. | Cannot proceed | | `AS-1303` | No ABHA user registered with this Aadhaar number | Unclassified | | `AS-1304` | UIDAI Error code : 400 :OTP validation failed | Unclassified | | `AS-1305` | Please provide a photo featuring only one individual and not a group photo. | Unclassified | | `AS-1306` | Invalid photo. Please upload a file with a human face. | Fix request | | `AS-1307` | Your mobile number is not linked to the ABHA number. Please update your mobile number in ABHA or try using Aadhaar OTP. | Unclassified | | `AS-1308` | You can request for new OTP after 30 seconds | Unclassified | | `AS-1309` | As per NHA policy, your mobile number has reached the limit of 6 self-declared ABHA addresses. Please link your existing ABHA addresses to your ABHA number. | Unclassified | | `AS-1310` | User not found. Please verify and try again. | Retry | | `AS-1311` | No password is set for this profile. Please log in using other login modes. | Unclassified | | `AS-1312` | Mobile number is missing for this ABHA address. Please update your mobile number. | Fix request | | `AS-1313` | The ABHA address entered is invalid. Please verify and try again. | Retry | | `AS-1314` | Required header 'X-token' is not present. | Fix request | | `AS-1315` | T-token expired | Cannot proceed | | `AS-1316` | Doctor info not found for healthProfessionalId :'%s' | Fix request | | `AS-1317` | An unexpected error has occurred. Please try again in some time. | Retry | | `AS-1318` | Login via Password is not allowed | Unclassified | | `AS-1319` | Invalid Password Request, Please enter valid ABHA Address or valid password | Fix request | | `AS-1320` | Invalid OTP Value | Fix request | | `AS-1321` | External service is temporarily unavailable | Retry | | `AS-1322` | User not found. Please verify and try again. | Retry | | `AS-1323` | User not found. Please verify and try again. | Retry | | `AS-1324` | The mobile number you have entered does not match with any of the records. Please enter a different number | Fix request | | `AS-1325` | Invalid Mobile Number | Fix request | | `AS-1326` | UIDAI Error code : 400 : OTP validation failed | Unclassified | | `AS-1327` | Mobile number is missing for this ABHA address. Please update your mobile number. | Fix request | | `AS-1328` | Transaction is not found for UUID. | Fix request | | `AS-1329` | You can request for new OTP after 30 seconds | Unclassified | | `AS-1330` | T-token expired | Cannot proceed | | `AS-1331` | The ABHA address entered is invalid. Please verify and try again. | Retry | | `AS-1332` | Please enter a valid and registered provider Id. | Fix request | | `AS-1333` | You can request for new OTP after 30 seconds | Unclassified | | `AS-1334` | This account is deactivated. Please reactivate it from ABHA portal. | Cannot proceed | | `AS-1335` | Login via Password is not allowed | Unclassified | | `AS-1336` | No open order against ABHA. Please ensure a minimum of one open order | Unclassified | | `AS-1337` | No CR Mapped with Abha Address | Unclassified | | `AS-1338` | No pending care context found for this abha address | Unclassified | | `AS-1339` | The provided gender does not match the gender in DigiLocker records | Unclassified | | `AS-1340` | The provided DOB does not match the DOB in DigiLocker records | Unclassified | | `AS-1341` | The provided name does not match the name in DigiLocker records | Unclassified | | `AS-1342` | Invalid Face Auth PID | Fix request | | `AS-1343` | No open order against ABHA. Please ensure a minimum of one open order | Unclassified | | `AS-1344` | No registration found at %s. Contact counter support | Unclassified | | `AS-1345` | Hospital services temporarily unavailable. Please try again after some time | Retry | | `AS-1346` | Services disrupted, please try again. | Retry | | `AS-1347` | Bank server not responding. Please try again later | Retry | | `AS-1348` | Service details mismatch. Please ensure original service ID from HMIS | Fix request | | `AS-1349` | The HIMS service is currently unavailable. Please try again after some time | Retry | | `AS-1350` | Cannot process the request at the moment, please try later | Retry | | `AS-1351` | No user profile found. | Unclassified | | `AS-1352` | Cannot process the request at the moment, please try later. | Retry | | `AS-1353` | Invalid OTP Request | Fix request | | `AS-1354` | X-token expired | Cannot proceed | | `AS-1355` | Invalid Mobile number. | Fix request | | `AS-1356` | No pending care context found for this abha address | Unclassified | | `AS-1357` | Invalid Password | Fix request | | `AS-1358` | Invalid R-token | Fix request | | `AS-1359` | Required header 'T-token' is not present. Please provide a valid T-token. | Fix request | | `AS-1360` | Required header 'R-token' is not present. Please provide a valid R-token. | Fix request | | `AS-1361` | Required header 'X-token' is not present. Please provide a valid X-token. | Fix request | | `AS-1362` | Requested URL or resource is not available | Unclassified | | `AS-1363` | Invalid X-token | Fix request | | `AS-1364` | Invalid T-token | Fix request | | `AS-1365` | The Scan and Pay functionality is not enabled at this facility. Kindly contact the hospital administration. | Unclassified | | `AS-1366` | No CR Mapped with Abha Address | Unclassified | | `AS-1367` | No care context is available for this patient. | Unclassified | | `AS-1368` | No registration found at %s. Contact counter support | Unclassified | | `AS-1369` | Invalid address line. It must be alphanumeric and can include the following special characters: ,.'/()- | Fix request | | `AS-1370` | External service error | Unclassified | | `AS-1371` | External service is temporarily unavailable | Retry | | `AS-1372` | External Service Unavailable | Retry | | `AS-1373` | Invalid Credentials. Make sure your API invocation call has a header: 'Authorization : Bearer ACCESS\_TOKEN' or 'Authorization : Basic ACCESS\_TOKEN' or 'apikey: API\_KEY' | Fix request | | `AS-1374` | Invalid Credentials. Make sure you have provided the correct security credentials | Fix request | | `AS-1375` | Invalid Login Hint | Fix request | | `AS-1376` | Invalid Scope | Fix request | | `AS-1377` | Patient not found | Fix request | | `AS-1378` | This account is deactivated. Please reactivate it from ABHA portal. | Cannot proceed | | `AS-1379` | Digilocker account creation fail. | Unclassified | | `AS-1380` | Too many request attempted in short period of time. This method is blocked for next 30 minutes | Cannot proceed | | `AS-1381` | The email Id you have entered has already been verified. Please provide an alternate email Id | Fix request | | `AS-1382` | Please avoid trying to generate the OTP multiple times within short time. | Unclassified | | `AS-1383` | Sorry you have exceeded your feedback submission limit | Unclassified | | `AS-1384` | Invalid KYC XML | Fix request | | `AS-1385` | R-token expired | Cannot proceed | | `AS-1386` | Invalid Email Id | Fix request | | `AS-1387` | You have exceeded the maximum limit of failed attempts Please try to login using other modes or try again in 24 hours | Retry | | `AS-1388` | Health Locker is Already Unsubscribed | Fix request | | `AS-1389` | Beneficiary is not a covered member for requested policy. Please enroll beneficiary for the policy and try again. | Retry | | `AS-1390` | No Claim History with requested Details | Unclassified | | `AS-1391` | External Service Unavailable | Retry | | `AS-1392` | Duplicate Link token request | Unclassified | | `AS-1393` | Digilocker Service Unavailable | Retry | | `AS-1394` | You have exceeded the maximum limit of failed attempts Please try to login using other modes or try again in 30 mins | Retry | | `AS-1395` | You have exceeded the maximum limit of failed attempts Please try to login using other modes or try again in 24 hours | Retry | | `AS-1396` | Aadhaar number is incorrect.Please use correct Aadhaar. | Fix request | | `AS-1397` | FileName can not be null or empty | Unclassified | | `AS-1398` | You have exceeded the maximum limit of failed attempts. Please try to login using other modes or try again in 12 hours. | Retry | | `AS-1399` | Duplicate patient record share request. | Unclassified | | `AS-1400` | Invalid HEALTHLOCKER Id or PHR Id. | Fix request | | `AS-1401` | Invalid Service ID, it must be Alpha numeric and @, \_ or - in middle. | Fix request | | `AS-1402` | Care context cannot be null or empty. | Unclassified | | `AS-1403` | Invalid data erase date. Date must be a future date. | Fix request | | `AS-1404` | Data erase date cannot be null or empty. | Unclassified | | `AS-1405` | Transaction Id is not matching with response. | Unclassified | | `AS-1406` | Request Timed out. | Unclassified | | `AS-1407` | expiry should be in future date. | Unclassified | | `AS-1408` | Invalid API sequence flow, please follow logical flow. | Fix request | | `AS-1409` | Invalid session status, Status should be TRANSFERRED, PARTIAL\_TRANSFERRED or FAILED. | Fix request | | `AS-1410` | Invalid health information status. | Fix request | | `AS-1411` | endDate should be after startDate and before currentDate. | Unclassified | | `AS-1412` | Invalid Mobile Number. | Fix request | | `AS-1413` | LoginId is invalid. | Fix request | | `AS-1414` | Invalid Transaction Id. | Fix request | | `AS-1415` | Unable to fetch the file details. | Unclassified | | `AS-1416` | Invalid PinCode, it must be only numbers and maximum length of 6. | Fix request | | `AS-1417` | NHCX service is temporarily unavailable. | Retry | | `AS-1418` | Maximum number of attempts for OTP match is exceeded or OTP is not generated. Please generate a fresh OTP and try to authenticate again. | Unclassified | | `AS-1419` | LoginId is invalid. | Fix request | | `AS-1420` | Invalid Otp System. | Fix request | | `AS-1421` | Invalid Auth Methods. | Fix request | | `AS-1422` | This Aadhaar number is already linked to the ABHA Number %s. Please re-login and try using another Aadhaar Number. | Fix request | Every code above is recorded in the specification that owns it. The aggregated list across modules is at [error codes](/docs/hiecm/v3/reference/error-codes). [Next Still stuck? Ask for help Where to file what you hit, so the answer lands back in these pages.](/docs/support) --- # P1 PHR identity and profile P1 is the patient side of [M1](/docs/hiecm/v3/api/m1). M1 is how a hospital system creates an [ABHA](/docs/hiecm/v3/getting-started/glossary#abha); P1 is how the patient's own application does it, and how it maintains the account afterwards. ## What is in it Registration and login, the profile the patient reads and edits, family members they manage on one account, and DigiLocker documents they pull in. The full operation list is in the [P1 PHR identity and profile API reference](/reference/hiecm-p1). --- # 01 discovery `POST /user-initiated-linking/link/discover` Discovers the person's care contexts at a HIP using their demographics and any identifiers they hold there. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/user-initiated-linking/link/discover \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "hip": { "id": "", "name": "" }, "unverifiedIdentifiers": [ { "type": "MR", "value": "" } ] }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `hip` (object, required) - `hip.id` (string, required) - `hip.name` (string, required) - `unverifiedIdentifiers` (object[], required) - `unverifiedIdentifiers.type` (string, required) - `unverifiedIdentifiers.value` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 02 link-init `POST /user-initiated-linking/link/init` Initiates linking of the care contexts discovered at a HIP. The HIP replies with how the person will authenticate. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/user-initiated-linking/link/init \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "transactionId": "", "patient": [ { "referenceNumber": "", "display": "Test", "careContexts": [ { "referenceNumber": "Test 1", "display": "Sugar Test" } ], "hiType": "Invoice", "count": 1 } ] }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `transactionId` (string, required) - `patient` (object[], required) - `patient.referenceNumber` (string, required) - `patient.display` (string, required) - `patient.careContexts` (object[], required) - `patient.careContexts.referenceNumber` (string, required) - `patient.careContexts.display` (string, required) - `patient.hiType` (string, required) - `patient.count` (integer, required) ## Responses - `200`: No response body is documented for this request. --- # 03 link-confirm `POST /user-initiated-linking/link/confirm` Confirms a user-initiated link with the OTP the HIP sent, completing the link of the discovered care contexts. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/user-initiated-linking/link/confirm \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "token": 123456, "linkRefNumber": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `token` (integer, required) - `linkRefNumber` (string, required) ## Responses - `200`: No response body is documented for this request. --- # Add My Record Bookmark `POST /api/care-context-link/my-record/bookmark` Bookmarks a self-uploaded record by its care context reference. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/my-record/bookmark \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "careContextReference": "care-context-ref-001", "abhaAddress": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `careContextReference` (string, required) - `abhaAddress` (string, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "id": 254, "patientId": "", "careContextReference": "25ac532f-178d-5885-9bcb-b82052f345eb_20260604190956854815", "dateCreated": "2026-06-13T19:01:35.955" } ``` --- # AS - Record On Share `POST /scan-share/record-share/on-share` Callback the gateway sends with the outcome of a record share request. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/scan-share/record-share/on-share \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "hiRequest": { "transactionId": "", "dataPushUrl": "https://webhook.site//health-information/transfer", "keyMaterial": { "cryptoAlg": "ECDH.", "curve": "curve25519", "dhPublicKey": { "expiry": "2026-12-28T13:18:20.742Z", "parameters": "Ephemeral public key.", "keyValue": "" }, "nonce": "H5EG5X61tTJ2ctjs3ByenbMvUezrf1VCRHZukspooaY=" } }, "response": { "requestId": "" } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `hiRequest` (object, required) - `hiRequest.transactionId` (string, required) - `hiRequest.dataPushUrl` (string, required) - `hiRequest.keyMaterial` (object, required) - `hiRequest.keyMaterial.cryptoAlg` (string, required) - `hiRequest.keyMaterial.curve` (string, required) - `hiRequest.keyMaterial.dhPublicKey` (object, required) - `hiRequest.keyMaterial.dhPublicKey.expiry` (string, required) - `hiRequest.keyMaterial.dhPublicKey.parameters` (string, required) - `hiRequest.keyMaterial.dhPublicKey.keyValue` (string, required) - `hiRequest.keyMaterial.nonce` (string, required) - `response` (object, required) - `response.requestId` (string, required) ## Responses - `200`: No response body is documented for this request. --- # AS - RecordShare History `GET /scan-share/share-record/audit-history` Lists the record shares the person has made, with the sending and receiving facilities and the counter they were shared at. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/scan-share/share-record/audit-history \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "requestId": "", "abhaAddress": "", "senderFacilityId": "sbx_aaroga_setu_aws", "senderFacilityName": "Sandbox Aaroga-Setu-Aws", "receiverFacilityId": "IN2810001317", "receiverFacilityName": "MEDIPLUS HOSPITAL ", "counterCode": "1", "transactionId": "", "status": "TRANSFERRED", "sharedRecordCount": 2, "consent": { "accessMode": "VIEW", "dataEraseAt": "2026-05-30T11:54:00.000Z", "careContexts": [ { "patientReference": "manish_191@sbx", "careContextReference": "03dc029b-f580-5b19-baff-47a707221658_20260518134701945848" }, { "patientReference": "manish_191@sbx", "careContextReference": "03dc029b-f580-5b19-baff-47a707221658_20260518130702309469" } ] }, "dateCreated": "2026-05-29T11:54:54.528Z", "dateModified": "2026-05-29T11:54:56.315Z" }, { "requestId": "", "abhaAddress": "", "senderFacilityId": "sbx_aaroga_setu_aws", "senderFacilityName": "Sandbox Aaroga-Setu-Aws", "receiverFacilityId": "IN2810001317", "receiverFacilityName": "MEDIPLUS HOSPITAL ", "counterCode": "1", "transactionId": "", "status": "TRANSFERRED", "sharedRecordCount": 3, "consent": { "accessMode": "VIEW", "dataEraseAt": "2026-05-30T11:22:00.000Z", "careContexts": [ { "patientReference": "manish_191@sbx", "careContextReference": "03dc029b-f580-5b19-baff-47a707221658_20260518134701945848" }, { "patientReference": "manish_191@sbx", "careContextReference": "03dc029b-f580-5b19-baff-47a707221658_20260518130702309469" }, "... 1 more of the same shape" ] }, "dateCreated": "2026-05-29T11:22:41.680Z", "dateModified": "2026-05-29T11:22:45.987Z" }, "... 1 more of the same shape" ] ``` --- # AS - RecordShare on-notify `POST /scan-share/record-share/on-notify` Callback the gateway sends to notify the PHR that a record share has been acted on. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/scan-share/record-share/on-notify \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "notification": { "transactionId": "", "doneAt": "2026-06-24T06:35:44.167Z", "statusNotification": { "sessionStatus": "TRANSFERRED", "statusResponses": [ { "careContextReference": "74538", "hiStatus": "DELIVERED", "description": "Data received successfully" } ] } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `notification` (object, required) - `notification.transactionId` (string, required) - `notification.doneAt` (string, required) - `notification.statusNotification` (object, required) - `notification.statusNotification.sessionStatus` (string, required) - `notification.statusNotification.statusResponses` (object[], required) - `notification.statusNotification.statusResponses.careContextReference` (string, required) - `notification.statusNotification.statusResponses.hiStatus` (string, required) - `notification.statusNotification.statusResponses.description` (string, required) ## Responses - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors --- # AS - RecordShare `POST /scan-share/record-share/share` Shares selected records with a facility after scanning its counter QR code. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/scan-share/record-share/share \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors --- # Bookmark Care Context `POST /api/care-context-link/bookmark/{careContextLinkId}` Bookmarks a linked care context so it is easy to find again in the person's records. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/bookmark/{careContextLinkId} \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `careContextLinkId` (string, required): Passed as a path segment. ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors --- # call-back link-on-confirm `POST /api/hiecm/user-initiated-linking/v3/link/care-context/on-confirm` Callback the gateway sends after a link confirmation: the patient's linked care contexts, or the error that stopped it. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/hiecm/user-initiated-linking/v3/link/care-context/on-confirm \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "patient": [ { "referenceNumber": "", "display": "Test", "careContexts": [ { "referenceNumber": "Test 4", "display": "Sugar Test" } ], "hiType": "Invoice", "count": 1 } ], "response": { "requestId": "" } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `patient` (object[], required) - `patient.referenceNumber` (string, required) - `patient.display` (string, required) - `patient.careContexts` (object[], required) - `patient.careContexts.referenceNumber` (string, required) - `patient.careContexts.display` (string, required) - `patient.hiType` (string, required) - `patient.count` (integer, required) - `response` (object, required) - `response.requestId` (string, required) ## Responses - `200`: No response body is documented for this request. --- # call-back on-discovery `POST /user-initiated-linking/link/on-discover` Callback the gateway sends with the care contexts discovered at the HIP, or the error that stopped discovery. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/user-initiated-linking/link/on-discover \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "transactionId": "", "error": { "code": "ABDM-1010", "message": "Patient not found" }, "response": { "requestId": "" } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `transactionId` (string, required) - `error` (object, required) - `error.code` (string, required) - `error.message` (string, required) - `response` (object, required) - `response.requestId` (string, required) ## Responses - `200`: No response body is documented for this request. --- # call-back on-init `POST /api/hiecm/user-initiated-linking/v3/link/care-context/on-init` Callback the gateway sends after a link is initiated: the link reference and how the person will authenticate, or the error that stopped it. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/hiecm/user-initiated-linking/v3/link/care-context/on-init \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # Delete My Record Bookmark `DELETE /api/care-context-link/my-record/bookmark` Removes a bookmark from a self-uploaded record. ```bash curl --request DELETE \ --url https://phrsbx.abdm.gov.in/api/care-context-link/my-record/bookmark \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors --- # Download File Chunk `GET /api/care-context-link/file/download` Downloads one chunk of a record file. Use the metadata call for the chunk size. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/file/download \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # Fetch Care Context Bundle URL `GET /api/care-context-link/care-context/bundle-url/{careContextLinkId}` Returns the download URLs for the FHIR bundles of one linked care context, with the fetch status. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/care-context/bundle-url/{careContextLinkId} \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `careContextLinkId` (string, required): Passed as a path segment. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "lockerView": null, "fetchRecordStatus": "SUCCESS", "bundleUrls": [ { "id": 843312, "careContextLinkId": 481116, "bundleUrl": "nithishjanithi@sbx/DigiLocker_NEGD/25ac532f-178d-5885-9bcb-b82052f345eb_20260523161857599891/.json", "transactionId": "", "dateCreated": "2026-05-23 16:19:03.193", "dateModified": "2026-05-23 16:19:03.193" } ] } ``` --- # Fetch Health Information Status `POST /api/care-context-link/patient/health-information/status` Returns the transfer status for the transaction ids given. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/patient/health-information/status \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "transactionIds": [ "txn-001", "txn-002" ] }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `transactionIds` (string[], required) ## Responses - `200`: No response body is documented for this request. --- # Fetch Patient Health Information `POST /api/care-context-link/patient/health-information/fetch` Fetches the health information received for the request ids given, with paging. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/patient/health-information/fetch \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "requestIds": [ "req-001", "req-002" ], "limit": 10, "offset": 0 }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `requestIds` (string[], required) - `limit` (integer, required) - `offset` (integer, required) ## Responses - `200`: No response body is documented for this request. --- # Get All Care Context Links for ABHA Address `POST /api/care-context-link/my-records/fetch/all` Lists the care context links for an ABHA address with paging and filters: HIP, record type, bookmarked, self-uploaded and date range. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/my-records/fetch/all \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "abhaAddress": "", "limit": 10, "offset": 0, "hipId": "", "hiType": "", "bookmarked": null, "selfUploaded": null, "dateRange": null, "sortHipName": null }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `abhaAddress` (string, required) - `limit` (integer, required) - `offset` (integer, required) - `hipId` (string, required) - `hiType` (string, required) - `bookmarked` (null, required) - `selfUploaded` (null, required) - `dateRange` (null, required) - `sortHipName` (null, required) ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors --- # Get All Linked Care Contexts `GET /api/care-context-link/link/patient/links` Lists every care context linked to the signed-in person, grouped by HIP. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/link/patient/links \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "patient": { "id": "nithishjanithi1@sbx", "links": [ { "hip": { "id": "IN0002222", "name": "", "type": "HIP" }, "referenceNumber": "nithishjanithi1@sbx", "display": "Blood Test", "hiType": "OPConsultation", "careContexts": [ { "referenceNumber": "Blood test1-28May", "display": "Blood Test" } ], "dateCreated": "2026-01-22T09:09:37.817Z", "new": false }, { "hip": { "id": "DigiLocker_NEGD", "name": "", "type": "HIP" }, "referenceNumber": "nithishjanithi1@sbx", "display": "Health Document", "hiType": "DiagnosticReport", "careContexts": [ { "referenceNumber": "25ac532f-178d-5885-9bcb-b82052f345eb_20260612153648199758", "display": "DigiLocker_2026-06-12-15:36:51" } ], "dateCreated": "2026-06-12T10:06:51.884Z", "new": false }, "... 1 more of the same shape" ] } } ``` --- # Get Care Context Links `GET /api/care-context-link/care-context-link/fetch` Lists the care contexts linked to the signed-in person's ABHA address, with the HIP each came from. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/care-context-link/fetch \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "lockerView": "", "id": 0, "hipId": "", "hipName": "", "patientId": "", "careContext": { "patientReference": "", "careContextReference": "", "hiTypes": [ "" ] }, "dateCreated": "", "dateModified": "", "resourceDate": "", "dataTransferStatus": "", "dataReceived": false, "bookmarked": false } ] ``` --- # Get Data Flow Part Status `GET /api/care-context-link/get/data-flow-part/{transactionId}` Returns the status of one part of a health information transfer, by its transaction id. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/get/data-flow-part/{transactionId} \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `transactionId` (string, required): Passed as a path segment. ## Responses - `200`: No response body is documented for this request. --- # Get File Metadata `GET /api/care-context-link/file/details` Returns a record file's name, size and chunk size, so it can be downloaded in parts. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/file/details \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "fileName": "nithishjanithi@sbx/DigiLocker_NEGD/25ac532f-178d-5885-9bcb-b82052f345eb_20260604192056317009/.json", "fileSize": 27636, "chunkSize": 5242880 } ``` --- # Get Health Information by Transaction ID `GET /api/care-context-link/get/health-information/{transactionId}` Returns the health information received for a transfer, by its transaction id. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/get/health-information/{transactionId} \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `transactionId` (string, required): Passed as a path segment. ## Responses - `200`: No response body is documented for this request. --- # Get HIP IDs `GET /api/care-context-link/get-hip-ids` Lists the HIPs whose records have been transferred for the person, with the base URL to download from. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/get-hip-ids \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "downloadBaseUrl": "https://abhasbx.abdm.gov.in/fetchFile/disk4/phrpullrecord/", "transferredHipIds": [ { "id": "DigiLocker_NEGD", "name": "" } ], "lockerView": "PHR" } ``` --- # Get Linked HIPs `GET /api/care-context-link/fetch/hips` Lists the HIPs linked to the person whose records have not yet been transferred, with the base URL to download from. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/fetch/hips \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "downloadBaseUrl": "https://abhasbx.abdm.gov.in/abha/api/v3/fetchFile/phrpullrecord/", "unTransferredHipIds": [ { "id": "LTIM_HIP_1", "name": "" }, { "id": "LTIM_HIP", "name": "" }, "... 1 more of the same shape" ] } ``` --- # Get Links by HIP `POST /api/care-context-link/link/get-links` Lists the person's linked care contexts grouped by HIP. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/link/get-links \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{}' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "patient": { "id": "nithishjanithi@sbx", "links": [ { "id": 496112, "smartData": { "dataProcessed": true, "status": "APPROVED", "documentId": "", "enabledForProcessing": true, "isAarogyaSetuProcessed": true }, "hip": { "id": "DigiLocker_NEGD", "name": "", "type": "HIP" }, "referenceNumber": "nithishjanithi@sbx", "careContexts": [ { "referenceNumber": "25ac532f-178d-5885-9bcb-b82052f345eb_20260604192056317009", "patientReference": "nithishjanithi@sbx", "hiTypes": [ "OPConsultation" ] } ], "dateCreated": "2026-06-04 19:00:00.0", "isBookmarked": false }, { "id": 481118, "smartData": { "dataProcessed": false, "enabledForProcessing": true, "isAarogyaSetuProcessed": false }, "hip": { "id": "DigiLocker_NEGD", "name": "", "type": "HIP" }, "referenceNumber": "nithishjanithi@sbx", "careContexts": [ { "referenceNumber": "25ac532f-178d-5885-9bcb-b82052f345eb_20260523161917547707", "patientReference": "nithishjanithi@sbx", "hiTypes": [ "OPConsultation" ] } ], "dateCreated": "2026-05-23 16:06:14.614", "isBookmarked": false }, "... 8 more of the same shape" ] } } ] ``` --- # Get Patient Transaction IDs by HIPs `POST /api/care-context-link/patient/transaction-ids` Returns the transfer transaction ids for a person's records at the HIPs given, under the consent artefacts given. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/patient/transaction-ids \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "abhaAddress": "", "hipIds": [ "HIP001", "HIP002" ], "consentArtefactIds": [ "consent-001", "consent-002" ] }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `abhaAddress` (string, required) - `hipIds` (string[], required) - `consentArtefactIds` (string[], required) ## Responses - `200`: No response body is documented for this request. --- # Health Information Data Transfer (HIP to HIU) `POST /api/care-context-link/v0.5/health-information/transfer` Receives a page of encrypted health information from a HIP, with the key material needed to decrypt it. Pages arrive in sequence under one transaction id. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/v0.5/health-information/transfer \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "pageNumber": 1, "pageCount": 1, "transactionId": "txn-001", "entries": [ { "content": "", "media": "application/fhir+json", "checksum": "checksum-value", "careContextReference": "care-context-ref-001" } ], "keyMaterial": { "cryptoAlg": "ECDH", "curve": "curve25519", "dhPublicKey": { "expiry": "2026-12-31T00:00:00.000Z", "parameters": "Ephemeral public key", "keyValue": "" }, "nonce": "" } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `pageNumber` (integer, required) - `pageCount` (integer, required) - `transactionId` (string, required) - `entries` (object[], required) - `entries.content` (string, required) - `entries.media` (string, required) - `entries.checksum` (string, required) - `entries.careContextReference` (string, required) - `keyMaterial` (object, required) - `keyMaterial.cryptoAlg` (string, required) - `keyMaterial.curve` (string, required) - `keyMaterial.dhPublicKey` (object, required) - `keyMaterial.dhPublicKey.expiry` (string, required) - `keyMaterial.dhPublicKey.parameters` (string, required) - `keyMaterial.dhPublicKey.keyValue` (string, required) - `keyMaterial.nonce` (string, required) ## Responses - `200`: No response body is documented for this request. --- # Health Information On-Request Callback `POST /api/care-context-link/health-information/on-request` Callback the gateway sends after a health information request: the transaction id for the transfer, or the error that stopped it. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/health-information/on-request \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "requestId": "", "timestamp": "2026-06-12T00:00:00.000Z", "hiRequest": { "transactionId": "txn-001", "sessionStatus": "ACKNOWLEDGED" }, "error": null, "resp": { "requestId": "" } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `requestId` (string, required) - `timestamp` (string, required) - `hiRequest` (object, required) - `hiRequest.transactionId` (string, required) - `hiRequest.sessionStatus` (string, required) - `error` (null, required) - `resp` (object, required) - `resp.requestId` (string, required) ## Responses - `200`: No response body is documented for this request. --- # Mark Linked Facility as Read `DELETE /api/care-context-link/read/link/patient/links/{hipId}` Marks the records from one HIP as seen, clearing the unread indicator for that facility. ```bash curl --request DELETE \ --url https://phrsbx.abdm.gov.in/api/care-context-link/read/link/patient/links/{hipId} \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `hipId` (string, required): Passed as a path segment. ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors --- # onpatientshare `POST /api/hiecm/patient-share/v3/on-share` Callback the gateway sends after a profile share at a facility, acknowledging the share request. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/hiecm/patient-share/v3/on-share \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "acknowledgement": { "status": "SUCCESS", "abhaAddress": "", "profile": { "context": "5", "tokenNumber": "", "expiry": "1800" } }, "response": { "requestId": "" } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `acknowledgement` (object, required) - `acknowledgement.status` (string, required) - `acknowledgement.abhaAddress` (string, required) - `acknowledgement.profile` (object, required) - `acknowledgement.profile.context` (string, required) - `acknowledgement.profile.tokenNumber` (string, required) - `acknowledgement.profile.expiry` (string, required) - `response` (object, required) - `response.requestId` (string, required) ## Responses - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors --- # PHR - Download File Chunk `GET /api/care-context-link/phr/file/download` Downloads one chunk of a record file. Use the metadata call for the chunk size. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/phr/file/download \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors --- # PHR - Fetch Care Context Bundle URL `GET /api/care-context-link/phr/care-context/bundle-url/{careContextLinkId}` Returns the download URLs for the FHIR bundles of one linked care context, with the fetch status. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/phr/care-context/bundle-url/{careContextLinkId} \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `careContextLinkId` (string, required): Passed as a path segment. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "lockerView": null, "fetchRecordStatus": "SUCCESS", "bundleUrls": [ { "id": 873302, "careContextLinkId": 496112, "bundleUrl": "nithishjanithi@sbx/DigiLocker_NEGD/25ac532f-178d-5885-9bcb-b82052f345eb_20260604192056317009/.json", "transactionId": "", "dateCreated": "2026-06-12 15:32:34.231", "dateModified": "2026-06-12 15:32:34.231" } ] } ``` --- # PHR - Get All Care Context Links `GET /api/care-context-link/phr/care-context-link/fetch/all` Lists every care context linked to the signed-in person, grouped by HIP. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/phr/care-context-link/fetch/all \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "patient": { "id": "nithishjanithi@sbx", "links": [ { "id": 496112, "smartData": { "dataProcessed": true, "status": "APPROVED", "documentId": "", "enabledForProcessing": true, "isAarogyaSetuProcessed": true }, "hip": { "id": "DigiLocker_NEGD", "name": "", "type": "HIP" }, "referenceNumber": "nithishjanithi@sbx", "careContexts": [ { "referenceNumber": "25ac532f-178d-5885-9bcb-b82052f345eb_20260604192056317009", "patientReference": "nithishjanithi@sbx", "hiTypes": [ "OPConsultation" ] } ], "dateCreated": "2026-06-04 19:00:00.0", "isBookmarked": false }, { "id": 481118, "smartData": { "dataProcessed": false, "enabledForProcessing": true, "isAarogyaSetuProcessed": false }, "hip": { "id": "DigiLocker_NEGD", "name": "", "type": "HIP" }, "referenceNumber": "nithishjanithi@sbx", "careContexts": [ { "referenceNumber": "25ac532f-178d-5885-9bcb-b82052f345eb_20260523161917547707", "patientReference": "nithishjanithi@sbx", "hiTypes": [ "OPConsultation" ] } ], "dateCreated": "2026-05-23 16:06:14.614", "isBookmarked": false }, "... 8 more of the same shape" ] } } ] ``` --- # PHR - Get Care Context Links `GET /api/care-context-link/phr/fetch` Lists the care contexts linked to the signed-in person's ABHA address, with the HIP each came from. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/phr/fetch \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "lockerView": "PHR", "id": 496112, "hipId": "DigiLocker_NEGD", "hipName": "DigiLocker_NEGD", "patientId": "", "careContext": { "patientReference": "nithishjanithi@sbx", "careContextReference": "25ac532f-178d-5885-9bcb-b82052f345eb_20260604192056317009", "hiTypes": [ "OPConsultation" ] }, "dateCreated": "2026-06-04 19:03:46.346", "dateModified": "2026-06-12 15:32:34.231", "resourceDate": "2026-06-04 19:00:00.000", "dataTransferStatus": "RECEIVED", "dataReceived": true, "bookmarked": false }, { "lockerView": "PHR", "id": 481118, "hipId": "DigiLocker_NEGD", "hipName": "DigiLocker_NEGD", "patientId": "", "careContext": { "patientReference": "nithishjanithi@sbx", "careContextReference": "25ac532f-178d-5885-9bcb-b82052f345eb_20260523161917547707", "hiTypes": [ "OPConsultation" ] }, "dateCreated": "2026-05-23 16:06:14.614", "dateModified": "2026-05-23 16:19:23.922", "resourceDate": "2026-05-23 16:06:14.614", "dataTransferStatus": "RECEIVED", "dataReceived": true, "bookmarked": false }, "... 8 more of the same shape" ] ``` --- # PHR - Get File Metadata `GET /api/care-context-link/phr/file/details` Returns a record file's name, size and chunk size, so it can be downloaded in parts. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/phr/file/details \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "fileName": "nithishjanithi@sbx/DigiLocker_NEGD/25ac532f-178d-5885-9bcb-b82052f345eb_20260604192056317009/.json", "fileSize": 27636, "chunkSize": 5242880 } ``` --- # PHR - Get Linked HIPs `GET /api/care-context-link/phr/fetch/hips` Lists the HIPs whose records have been transferred for the person, with the base URL to download from. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/phr/fetch/hips \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "downloadBaseUrl": "https://abhasbx.abdm.gov.in/fetchFile/disk4/phrpullrecord/", "transferredHipIds": [ { "id": "DigiLocker_NEGD", "name": "" } ], "lockerView": "PHR" } ``` --- # PHR - Pull Health Information for Care Context `POST /api/care-context-link/phr/patient/health-information/pull` Asks a HIP to send the records for one care context. The data arrives later through the transfer endpoint. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/phr/patient/health-information/pull \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "careContextReference": "care-context-ref-001", "hipId": "HIP001" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `careContextReference` (string, required) - `hipId` (string, required) ## Responses - `200`: No response body is documented for this request. --- # PHR - Refresh Patient Health Information `POST /api/care-context-link/phr/patient/health-information/refresh` Asks the HIPs given to send any records added since the last transfer. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/phr/patient/health-information/refresh \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "hipIds": [ "HIP001", "HIP002" ] }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `hipIds` (string[], required) ## Responses - `200`: No response body is documented for this request. --- # PHR - Save Care Context Bundle URL `POST /api/care-context-link/phr/care-context/bundle-url` Records where the FHIR bundle for a care context was stored, with its fetch status. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/phr/care-context/bundle-url \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "careContextLinkId": 12345, "bundleUrl": "https://example.com/bundle/url", "status": "RECEIVED" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `careContextLinkId` (integer, required) - `bundleUrl` (string, required) - `status` (string, required) ## Responses - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors --- # Post Patient Consent Request `POST /api/care-context-link/patient/consent-request` Raises a consent request from the person's own PHR for records at the HIPs given, so they can be fetched into the app. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/patient/consent-request \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "abhaAddress": "", "hipIds": [ "HIP001", "HIP002" ], "consentArtefactIds": [ "consent-001", "consent-002" ] }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `abhaAddress` (string, required) - `hipIds` (string[], required) - `consentArtefactIds` (string[], required) ## Responses - `200`: No response body is documented for this request. --- # profile share `POST /scan-share/profile/share` Shares the person's profile with a facility after scanning its counter QR code, so the facility can register them without typing details. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/scan-share/profile/share \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors --- # Public -Get-Subscribed-Lockers-By-PatientId `GET /health-locker/subscription-requests/patients/lockers` Lists the health lockers a person is subscribed to. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/health-locker/subscription-requests/patients/lockers \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "id": 9720, "lockerId": "Harish4_lti", "lockerName": "Testing", "patientId": "", "dateCreated": "2025-05-22T12:22:28.454Z", "dateModified": "2025-06-11T06:13:58.645Z", "healthIdNumber": "", "isActive": true }, { "id": 8726, "lockerId": "driefcasehl", "lockerName": "DRiefcase Health Locker", "patientId": "", "dateCreated": "2025-03-11T12:00:27.982Z", "dateModified": "2025-06-11T06:13:47.713Z", "healthIdNumber": "", "isActive": true }, "... 4 more of the same shape" ] ``` --- # Public-Health-Lockers-Subscribe `POST /health-locker/lockers/subscribe` Subscribes the person to a health locker, so their new records are shared with it automatically. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/health-locker/lockers/subscribe \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "consentAutoApprovalId": "" } ``` --- # Public-Health-Lockers-Unsubscribe `POST /api/health-locker/lockers/unsubscribe` Ends the person's subscription to a health locker, so it stops receiving their new records. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/health-locker/lockers/unsubscribe \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `403`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "patientId": "", "lockerId": "Priyanka_Health_Locker", "isActive": false } ``` --- # Pull Patient Health Information `POST /api/care-context-link/patient/health-information/pull` Asks the HIPs given to send the person's records. The data arrives later through the transfer endpoint. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/patient/health-information/pull \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "hipIds": [ "HIP001" ], "abhaAddress": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `hipIds` (string[], required) - `abhaAddress` (string, required) ## Responses - `200`: No response body is documented for this request. --- # Refresh Patient Health Information `POST /api/care-context-link/patient/health-information/refresh` Asks the HIPs given to send any records added since the last transfer. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/patient/health-information/refresh \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "hipIds": [ "HIP001", "HIP002" ] }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `hipIds` (string[], required) ## Responses - `200`: No response body is documented for this request. --- # Save Care Context Link `POST /api/care-context-link/save` Records a care context link for a person, with the HIP it came from and whether its data has been transferred. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/care-context-link/save \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "hipId": "IN0002222", "patientId": "", "careContext": { "patientReference": "NITHISH_1999", "careContextReference": "Prescription566", "hiTypes": [ "Prescription", "WellnessRecord", "Invoice", "OPConsultation", "HealthDocumentRecord" ] }, "dataTransferred": true }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `hipId` (string, required) - `patientId` (string, required) - `careContext` (object, required) - `careContext.patientReference` (string, required) - `careContext.careContextReference` (string, required) - `careContext.hiTypes` (string[], required) - `dataTransferred` (boolean, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p2/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "id": 1018, "hipId": "IN0002222", "patientId": "", "careContext": { "patientReference": "NITHISH_1999", "careContextReference": "Prescription566", "hiTypes": [ "Prescription", "WellnessRecord", "... 3 more of the same shape" ] }, "dateCreated": "2026-06-13 17:51:19.114", "dateModified": "2026-06-13 17:51:19.114", "resourceDate": "2026-06-13 17:51:19.114", "dataTransferStatus": "NEW", "dataReceived": false, "bookmarked": false } ``` --- # Search Care Context Links `GET /api/care-context-link/search/care-context-link` Searches the person's care context links by the query parameters given. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/care-context-link/search/care-context-link \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # P2 PHR linking and records errors Seeing a symptom rather than a code? Start at [Troubleshooting](/docs/hiecm/v3/troubleshooting/). The P2 PHR linking and records specification records no error code yet. That is a gap in the specification, not a promise that this module cannot fail. Every code above is recorded in the specification that owns it. The aggregated list across modules is at [error codes](/docs/hiecm/v3/reference/error-codes). [Next Still stuck? Ask for help Where to file what you hit, so the answer lands back in these pages.](/docs/support) --- # P2 PHR linking and records P2 is the mirror of [M2](/docs/hiecm/v3/api/m2). M2 is a provider publishing a record; P2 is the patient discovering it and linking it. ## What is in it Care context linking, user initiated linking, scan and share at a facility, and health locker subscriptions. The full operation list is in the [P2 PHR linking and records API reference](/reference/hiecm-p2). --- # Add Feedback `POST /api/notification/feedback` Records feedback from the person, with a title and body, against their ABHA. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/notification/feedback \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "healthId": "", "emailId": "", "title": "feedback", "body": "AarogyaSethu feedback test-1" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `healthId` (string, required) - `emailId` (string, required) - `title` (string, required) - `body` (string, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "id": 71, "healthId": "", "emailId": "", "title": "feedback", "body": "AarogyaSethu feedback test-1", "dateCreated": "2026-06-01T08:15:27.682Z" } ``` --- # Add new Notification `POST /api/notification/new-app-push-notification` Creates a push notification for a person. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/notification/new-app-push-notification \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '[ { "id": 515459874, "patientId": "", "pushNotificationData": { "healthId": "", "target": "in.projecteka.jataayu.consent.ui.activity.ConsentDetailsActivity", "title": "Dr. ManishTEST_HIU", "body": "Wants to access your records\nPurpose : Care Management", "timestamp": 1743788382266, "params": { "consentRequestId": "" } }, "dateCreated": "2025-04-04T17:39:42.268Z", "dateModified": "2025-04-04T17:39:42.270Z", "isNotificationRead": false, "unreadCount": 3 } ]' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "id": 13295, "patientId": "", "pushNotificationData": { "healthId": "", "target": "familyManagementId", "title": "Notification", "body": "You have a new notification", "timestamp": "2026-06-01T08:06:55.128Z", "params": {} }, "dateCreated": "2026-06-01T08:06:55.131Z", "dateModified": "2026-06-01T08:06:55.131Z", "isNotificationRead": false, "isDeleted": false } ``` --- # App Notification Token `GET /api/notification/request/app-notification-token` Returns the device token registered for push notifications to the signed-in person. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/notification/request/app-notification-token \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "id": 48, "healthId": "", "appToken": "", "dateCreated": "2025-08-11 18:20:41.039", "dateModified": "2026-05-27 16:12:16.215", "osType": "android" } ``` --- # Approve Consent Request `POST /api/consent-management/consent-requests/{consentRequestId}/approve` Approves a consent request. `consents` names the HIPs and care contexts the person is granting, and the artefact ids come back. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/consent-requests/{consentRequestId}/approve \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "consents": [ { "hiTypes": [ "OPConsultation" ], "hip": { "id": "wdwsd" }, "careContexts": [ { "patientReference": "nithishjanithi@sbx", "careContextReference": "25ac532f-178d-5885-9bcb-b82052f345eb_20260428112424637418" } ], "permission": { "accessMode": "VIEW", "dateRange": { "from": "2023-05-09T08:58:09.738Z", "to": "2025-04-12T09:00:00.738Z" }, "dataEraseAt": "2026-09-12T13:26:00.738Z", "frequency": { "unit": "HOUR", "value": 0, "repeats": 0 } } } ] }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `consentRequestId` (string, required): Passed as a path segment. ## Body - `consents` (object[], required) - `consents.hiTypes` (string[], required) - `consents.hip` (object, required) - `consents.hip.id` (string, required) - `consents.careContexts` (object[], required) - `consents.careContexts.patientReference` (string, required) - `consents.careContexts.careContextReference` (string, required) - `consents.permission` (object, required) - `consents.permission.accessMode` (string, required) - `consents.permission.dateRange` (object, required) - `consents.permission.dateRange.from` (string, required) - `consents.permission.dateRange.to` (string, required) - `consents.permission.dataEraseAt` (string, required) - `consents.permission.frequency` (object, required) - `consents.permission.frequency.unit` (string, required) - `consents.permission.frequency.value` (integer, required) - `consents.permission.frequency.repeats` (integer, required) ## Responses - `200`: Example values, scrubbed. - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "", "consentIds": [ { "id": "" } ], "error": { "code": "", "message": "" } } ``` --- # Approve Subscription Request `POST /api/consent-management/subscription-requests/{subscriptionRequestId}/approve` Approves a subscription request for the sources included and not the ones excluded, or for every HIP. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/subscription-requests/{subscriptionRequestId}/approve \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "isApplicableForAllHIPs": true, "includedSources": [ { "hiTypes": [ "Invoice", "HealthDocumentRecord" ], "purpose": { "text": "Care Management", "code": "CAREMGT", "refUri": "www.abdm.gov.in" }, "categories": [ "LINK", "DATA" ], "period": { "from": "2025-05-22T13:12:55.297Z", "to": "2125-05-22T13:11:55.300Z" } } ], "excludedSources": [] }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `subscriptionRequestId` (string, required): Passed as a path segment. ## Body - `isApplicableForAllHIPs` (boolean, required) - `includedSources` (object[], required) - `includedSources.hiTypes` (string[], required) - `includedSources.purpose` (object, required) - `includedSources.purpose.text` (string, required) - `includedSources.purpose.code` (string, required) - `includedSources.purpose.refUri` (string, required) - `includedSources.categories` (string[], required) - `includedSources.period` (object, required) - `includedSources.period.from` (string, required) - `includedSources.period.to` (string, required) - `excludedSources` (object[], required) ## Responses - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors --- # Clear Notification `PATCH /api/notification/app-push-notification/clear-notification` Clears the push notifications given from the person's list. ```bash curl --request PATCH \ --url https://phrsbx.abdm.gov.in/api/notification/app-push-notification/clear-notification \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '[ { "id": 515459874, "patientId": "", "pushNotificationData": { "healthId": "", "target": "in.projecteka.jataayu.consent.ui.activity.ConsentDetailsActivity", "title": "Dr. ManishTEST_HIU", "body": "Wants to access your records\nPurpose : Care Management", "timestamp": 1743788382266, "params": { "consentRequestId": "" } }, "dateCreated": "2025-04-04T17:39:42.268Z", "dateModified": "2025-04-04T17:39:42.270Z", "isNotificationRead": false, "unreadCount": 3 } ]' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [] ``` --- # Consent Auto Approve `POST /api/consent-management/consents/auto-approve` Creates an auto-approval policy: consent requests from the HIU named are approved without asking, for the sources included and not the ones excluded. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/consents/auto-approve \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "isApplicableForAllHIPs": true, "hiu": { "id": "IN0002222", "name": "" }, "includedSources": [ { "hiTypes": [ "OPCONSULTATION" ], "purpose": { "text": "Care Management", "code": "CAREMGT", "refUri": "string" }, "hip": null, "period": { "from": "2025-09-30T16:51:40.617Z", "to": "2026-07-09T16:51:40.617Z" } } ], "excludedSources": null }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `isApplicableForAllHIPs` (boolean, required) - `hiu` (object, required) - `hiu.id` (string, required) - `hiu.name` (string, required) - `includedSources` (object[], required) - `includedSources.hiTypes` (string[], required) - `includedSources.purpose` (object, required) - `includedSources.purpose.text` (string, required) - `includedSources.purpose.code` (string, required) - `includedSources.purpose.refUri` (string, required) - `includedSources.hip` (null, required) - `includedSources.period` (object, required) - `includedSources.period.from` (string, required) - `includedSources.period.to` (string, required) - `excludedSources` (null, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "autoApprovalId": "", "message": "", "supportedHITypes": [ "" ] } ``` --- # Delete push notification `DELETE /api/notification/schedule-push-notification/0eg` Deletes a scheduled push notification by its id. ```bash curl --request DELETE \ --url https://phrsbx.abdm.gov.in/api/notification/schedule-push-notification/0eg \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # Deny Consent Request `POST /api/consent-management/consent-requests/{consentRequestId}/deny` Denies a consent request, with the reason the person gave. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/consent-requests/{consentRequestId}/deny \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "reason": "Not required" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `consentRequestId` (string, required): Passed as a path segment. ## Body - `reason` (string, required) ## Responses - `200`: Example values, scrubbed. - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "status": "", "error": { "code": "", "message": "" } } ``` --- # Deny Subscription Request `POST /api/consent-management/subscription-requests/{subscriptionRequestId}/deny` Denies a subscription request, so the HIU is not notified of the person's new care contexts. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/subscription-requests/{subscriptionRequestId}/deny \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{}' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `subscriptionRequestId` (string, required): Passed as a path segment. ## Responses - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 --- # Disable Auto Approval `POST /api/consent-management/consents/auto-approval-policy/{autoApprovalId}/disable` Turns off an auto-approval policy, so later consent requests it would have matched wait for the person again. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/consents/auto-approval-policy/{autoApprovalId}/disable \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `autoApprovalId` (string, required): Passed as a path segment. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "error": { "code": "", "message": "" }, "message": "" } ``` --- # Edit Subscription `PUT /api/consent-management/patients/subscription-requests/{subscriptionId}` Edits a subscription and approves it in the same step, changing which HIPs and categories the HIU is subscribed to. ```bash curl --request PUT \ --url https://phrsbx.abdm.gov.in/api/consent-management/patients/subscription-requests/{subscriptionId} \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "hiuId": "", "subscriptionEditAndApprovalRequest": { "isApplicableForAllHIPs": true, "includedSources": [ { "hiTypes": [ "DiagnosticReport", "Prescription", "ImmunizationRecord", "DischargeSummary", "OPConsultation", "HealthDocumentRecord", "WellnessRecord" ], "purpose": { "text": "Care Management", "code": "CAREMGT", "refUri": "www.abdm.gov.in" }, "categories": [ "DATA", "LINK" ], "period": { "from": "2024-01-09T09:00:00.000Z", "to": "2123-12-31T09:00:00.000Z" } } ], "excludedSources": [] } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `subscriptionId` (string, required): Passed as a path segment. ## Body - `hiuId` (string, required) - `subscriptionEditAndApprovalRequest` (object, required) - `subscriptionEditAndApprovalRequest.isApplicableForAllHIPs` (boolean, required) - `subscriptionEditAndApprovalRequest.includedSources` (object[], required) - `subscriptionEditAndApprovalRequest.includedSources.hiTypes` (string[], required) - `subscriptionEditAndApprovalRequest.includedSources.purpose` (object, required) - `subscriptionEditAndApprovalRequest.includedSources.purpose.text` (string, required) - `subscriptionEditAndApprovalRequest.includedSources.purpose.code` (string, required) - `subscriptionEditAndApprovalRequest.includedSources.purpose.refUri` (string, required) - `subscriptionEditAndApprovalRequest.includedSources.categories` (string[], required) - `subscriptionEditAndApprovalRequest.includedSources.period` (object, required) - `subscriptionEditAndApprovalRequest.includedSources.period.from` (string, required) - `subscriptionEditAndApprovalRequest.includedSources.period.to` (string, required) - `subscriptionEditAndApprovalRequest.excludedSources` (object[], required) ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors --- # Enable Auto Approval `POST /api/consent-management/consents/auto-approval-policy/{autoApprovalId}/enable` Turns an auto-approval policy back on. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/consents/auto-approval-policy/{autoApprovalId}/enable \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `autoApprovalId` (string, required): Passed as a path segment. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "", "error": { "code": "", "message": "" } } ``` --- # Get All Consent Artefacts by ABHA Address `GET /api/consent-management/consent-artefacts` Lists the consent artefacts granted by the signed-in ABHA address, with paging. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/consent-management/consent-artefacts \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "size": 10, "limit": 10, "offset": 0, "consentArtefacts": [ { "status": "REVOKED", "consentDetail": { "schemaVersion": "v3", "consentId": "", "createdAt": "2026-06-05T05:49:30.893Z", "lastUpdated": "2026-06-05T05:59:33.037Z", "patient": { "id": "nithishjanithi@sbx" }, "careContexts": [ { "patientReference": "nithishjanithi@sbx", "careContextReference": "25ac532f-178d-5885-9bcb-b82052f345eb_20260428112424637418" } ], "purpose": { "text": "Care management", "code": "CAREMGT", "refUri": "www.abdm.gov.in" }, "hip": { "id": "wdwsd" }, "hiu": { "id": "IN0002222" }, "consentManager": { "id": "sbx" }, "requester": { "name": "", "identifier": { "value": "MH1001", "type": "REGNO1", "system": "https://www.mciindia.9985" } }, "hiTypes": [ "OPConsultation" ], "permission": { "accessMode": "VIEW", "dateRange": { "from": "2023-05-09T08:58:09.738Z", "to": "2025-04-12T09:00:00.738Z" }, "dataEraseAt": "2026-09-12T13:26:00.738Z", "frequency": { "unit": "HOUR", "value": 0, "repeats": 0 } } }, "signature": "tY9rOuZomDEo3ihjgjiOl92dgQ1wjzBQa4ogJYlLl7BZFAO3IiR6k8p9qcd30eYgBc1xyPEPied6nDrdPwT6oD2mAso/ny6Ykcto3uU/1nViYH7K/H9/XVEoo4hyOPKb62aGUqMn69QpWNhPM9HTnhtj3CXOjB6TA2eFkHYYbaniX02W/6ALtuPb0OsUchlImVbjj1EBlCK4Xs8GrtAnneU2esnMWR7N0ra9bnyR6zF5Bi2ng/pDLTIeKC3wfVKg4AGUC6obC7FCRrykAUlpgWMM4wBbiV7Y1oLPcJ4VFL7DSUdtilGbW53ez0Av4cKlVizRxZ9gWvw2kWQBa2iL/w==" }, { "status": "GRANTED", "consentDetail": { "schemaVersion": "v3", "consentId": "", "createdAt": "2026-06-05T05:39:45.177Z", "lastUpdated": "2026-06-05T05:39:45.177Z", "patient": { "id": "nithishjanithi@sbx" }, "careContexts": [ { "patientReference": "nithishjanithi@sbx", "careContextReference": "25ac532f-178d-5885-9bcb-b82052f345eb_20260428112424637418" } ], "purpose": { "text": "Care management", "code": "CAREMGT", "refUri": "www.abdm.gov.in" }, "hip": { "id": "wdwsd" }, "hiu": { "id": "IN0002222" }, "consentManager": { "id": "sbx" }, "requester": { "name": "", "identifier": { "value": "MH1001", "type": "REGNO1", "system": "https://www.mciindia.9985" } }, "hiTypes": [ "OPConsultation" ], "permission": { "accessMode": "VIEW", "dateRange": { "from": "2023-05-09T08:58:09.738Z", "to": "2025-04-12T09:00:00.738Z" }, "dataEraseAt": "2026-09-10T13:26:00.738Z", "frequency": { "unit": "HOUR", "value": 0, "repeats": 0 } } }, "signature": "Rk4JZGhdRdrmNldhcM7tmsZOhKwNyN4FEER8O8WAl2GkqRqNQz79pOeBmBZAFi61HY3X3scKoBEC+o2fl4/F33n3QHoXKuP/5cDhamUMPq0FO8YrbUwzwoeMn46trIB8qEHE+aTdtH/09T8fIY+I1bMTlRaOeebAbhff8JC1v+w51l5Mw+MFnchxY8ulO1U/gGKsYUl+JCC/2+nVpw2OS/7nEv8Dv7Xl4Ttgdcel7cbVkAoy2h+eYNeOLLrCC7UbMvXds2e0Ng64mgNO6Iw8UJ/0FG4W+a9bk2TfOhvYIbJ6XOG+qiIeZDhqT3IddSntjMRsNeGubdsQZmHqKsh0ww==" }, "... 2 more of the same shape" ] } ``` --- # Get All Consent Artefacts by Request ID `GET /api/consent-management/consent-requests/{consentRequestId}/consent-artefacts` Lists the consent artefacts created when a request was approved, one per HIP. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/consent-management/consent-requests/{consentRequestId}/consent-artefacts \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `consentRequestId` (string, required): Passed as a path segment. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "status": "REVOKED", "consentDetail": { "schemaVersion": "v3", "consentId": "", "createdAt": "2026-06-05T05:49:30.893Z", "lastUpdated": "2026-06-05T05:59:33.037Z", "patient": { "id": "nithishjanithi@sbx" }, "careContexts": [ { "patientReference": "nithishjanithi@sbx", "careContextReference": "25ac532f-178d-5885-9bcb-b82052f345eb_20260428112424637418" } ], "purpose": { "text": "Care management", "code": "CAREMGT", "refUri": "www.abdm.gov.in" }, "hip": { "id": "wdwsd" }, "hiu": { "id": "IN0002222" }, "consentManager": { "id": "sbx" }, "requester": { "name": "", "identifier": { "value": "MH1001", "type": "REGNO1", "system": "https://www.mciindia.9985" } }, "hiTypes": [ "OPConsultation" ], "permission": { "accessMode": "VIEW", "dateRange": { "from": "2023-05-09T08:58:09.738Z", "to": "2025-04-12T09:00:00.738Z" }, "dataEraseAt": "2026-09-12T13:26:00.738Z", "frequency": { "unit": "HOUR", "value": 0, "repeats": 0 } } }, "signature": "tY9rOuZomDEo3ihjgjiOl92dgQ1wjzBQa4ogJYlLl7BZFAO3IiR6k8p9qcd30eYgBc1xyPEPied6nDrdPwT6oD2mAso/ny6Ykcto3uU/1nViYH7K/H9/XVEoo4hyOPKb62aGUqMn69QpWNhPM9HTnhtj3CXOjB6TA2eFkHYYbaniX02W/6ALtuPb0OsUchlImVbjj1EBlCK4Xs8GrtAnneU2esnMWR7N0ra9bnyR6zF5Bi2ng/pDLTIeKC3wfVKg4AGUC6obC7FCRrykAUlpgWMM4wBbiV7Y1oLPcJ4VFL7DSUdtilGbW53ez0Av4cKlVizRxZ9gWvw2kWQBa2iL/w==" } ] ``` --- # Get All HIU Subscription Requests `GET /api/consent-management/subscription-requests` Lists the subscription requests HIUs have raised against the signed-in ABHA address, with paging. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/consent-management/subscription-requests \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "size": 5, "limit": 5, "offset": 0, "requests": [ { "requestId": "", "createdAt": "2026-05-29T09:18:26.944Z", "lastUpdated": "2026-05-29T09:20:41.769Z", "purpose": { "text": "Self Requested", "code": "PATRQT", "refUri": "www.abdm.gov.in" }, "patient": { "id": "nithishjanithi@sbx" }, "hiu": { "id": "Priyanka_Health_Locker", "name": "", "type": "HEALTH LOCKER" }, "hips": [], "categories": [ "DATA", "LINK" ], "period": { "from": "2026-05-29T09:19:26.699Z", "to": "2126-05-29T09:18:26.699Z" }, "status": "UNSUBSCRIBED", "requesterType": "HEALTH_LOCKER" }, { "requestId": "", "createdAt": "2025-06-15T14:53:24.437Z", "lastUpdated": "2026-05-29T09:20:41.769Z", "purpose": { "text": "Care Management", "code": "CAREMGT", "refUri": "www.abdm.gov.in" }, "patient": { "id": "nithishjanithi@sbx" }, "hiu": { "id": "Priyanka_Health_Locker", "name": "", "type": "HEALTH LOCKER" }, "hips": [], "categories": [ "LINK", "DATA" ], "period": { "from": "2024-01-01T09:00:00.000Z", "to": "2124-12-31T09:00:00.000Z" }, "status": "UNSUBSCRIBED", "requesterType": "HEALTH_LOCKER", "subscriptionId": "" }, "... 2 more of the same shape" ] } ``` --- # Get all notification details `GET /api/notification/get-notification` Lists the person's push notifications with their read state and the unread count. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/notification/get-notification \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `403`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "id": 13192, "patientId": "", "pushNotificationData": { "healthId": "", "target": "selfUpload", "title": "File Processed Successfully", "body": "Your record PreviousMedicalprescription-ParveenSharma1.pdf has been processed and is ready for review.", "timestamp": "2026-05-27T10:44:29.657Z", "params": {} }, "dateCreated": "2026-05-27T10:44:29.660Z", "dateModified": "2026-05-27T10:44:29.660Z", "isNotificationRead": false, "isDeleted": false, "unreadCount": 5, "totalNotificationCount": 298 }, { "id": 13172, "patientId": "", "pushNotificationData": { "healthId": "", "target": "selfUpload", "title": "File Processed Successfully", "body": "Your record IN0110000034-Consultation_VISIT-18199008-.pdf has been processed and is ready for review.", "timestamp": "2026-05-27T05:41:50.162Z", "params": {} }, "dateCreated": "2026-05-27T05:41:50.165Z", "dateModified": "2026-05-27T05:41:50.165Z", "isNotificationRead": false, "isDeleted": false, "unreadCount": 5, "totalNotificationCount": 298 }, "... 18 more of the same shape" ] ``` --- # Get Consent Artefact by Artefact ID `GET /api/consent-management/consents/{consentArtefactId}` Returns one consent artefact with its signature and current status. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/consent-management/consents/{consentArtefactId} \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `consentArtefactId` (string, required): Passed as a path segment. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "status": "REVOKED", "consentDetail": { "schemaVersion": "v3", "consentId": "", "createdAt": "2026-06-05T05:49:30.893Z", "lastUpdated": "2026-06-05T05:59:33.037Z", "patient": { "id": "nithishjanithi@sbx" }, "careContexts": [ { "patientReference": "nithishjanithi@sbx", "careContextReference": "25ac532f-178d-5885-9bcb-b82052f345eb_20260428112424637418" } ], "purpose": { "text": "Care management", "code": "CAREMGT", "refUri": "www.abdm.gov.in" }, "hip": { "id": "wdwsd" }, "hiu": { "id": "IN0002222" }, "consentManager": { "id": "sbx" }, "requester": { "name": "", "identifier": { "value": "MH1001", "type": "REGNO1", "system": "https://www.mciindia.9985" } }, "hiTypes": [ "OPConsultation" ], "permission": { "accessMode": "VIEW", "dateRange": { "from": "2023-05-09T08:58:09.738Z", "to": "2025-04-12T09:00:00.738Z" }, "dataEraseAt": "2026-09-12T13:26:00.738Z", "frequency": { "unit": "HOUR", "value": 0, "repeats": 0 } } }, "signature": "tY9rOuZomDEo3ihjgjiOl92dgQ1wjzBQa4ogJYlLl7BZFAO3IiR6k8p9qcd30eYgBc1xyPEPied6nDrdPwT6oD2mAso/ny6Ykcto3uU/1nViYH7K/H9/XVEoo4hyOPKb62aGUqMn69QpWNhPM9HTnhtj3CXOjB6TA2eFkHYYbaniX02W/6ALtuPb0OsUchlImVbjj1EBlCK4Xs8GrtAnneU2esnMWR7N0ra9bnyR6zF5Bi2ng/pDLTIeKC3wfVKg4AGUC6obC7FCRrykAUlpgWMM4wBbiV7Y1oLPcJ4VFL7DSUdtilGbW53ez0Av4cKlVizRxZ9gWvw2kWQBa2iL/w==" } ``` --- # Get Consent Request by Request ID `GET /api/consent-management/consent-requests/{consentRequestId}` Returns one consent request: who is asking, for what purpose, which record types, and its current status. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/consent-management/consent-requests/{consentRequestId} \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `consentRequestId` (string, required): Passed as a path segment. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "requestId": "", "createdAt": "2026-04-28T05:54:26.374Z", "lastUpdated": "2026-04-28T05:54:26.449Z", "status": "GRANTED", "purpose": { "text": "Care Management", "code": "CAREMGT", "refUri": "www.abdm.gov.in" }, "patient": { "id": "nithishjanithi@sbx" }, "hip": { "id": "DigiLocker_NEGD" }, "hiu": { "id": "DigiLocker_NEGD" }, "requester": { "name": "", "identifier": { "value": "SELF", "type": "SELF", "system": "nithishjanithi@sbx" } }, "hiTypes": [ "DiagnosticReport" ], "careContexts": [ { "patientReference": "nithishjanithi@sbx", "careContextReference": "25ac532f-178d-5885-9bcb-b82052f345eb_20260428112424637418" } ], "permission": { "accessMode": "VIEW", "dateRange": { "from": "2026-04-27T09:54:25.533Z", "to": "2026-04-28T05:54:25.533Z" }, "dataEraseAt": "2036-04-28T11:24:25.533Z", "frequency": { "unit": "YEAR", "value": 1, "repeats": 1 } } } ``` --- # Get Consent Request List `GET /api/consent-management/consent-requests` Lists the consent requests raised against the signed-in ABHA address, with paging. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/consent-management/consent-requests \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "size": 10, "limit": 10, "offset": 0, "requests": [ { "requestId": "", "createdAt": "2026-04-28T05:54:26.374Z", "lastUpdated": "2026-04-28T05:54:26.449Z", "status": "GRANTED", "purpose": { "text": "Care Management", "code": "CAREMGT", "refUri": "www.abdm.gov.in" }, "patient": { "id": "nithishjanithi@sbx" }, "hip": { "id": "DigiLocker_NEGD" }, "hiu": { "id": "DigiLocker_NEGD" }, "requester": { "name": "", "identifier": { "value": "SELF", "type": "SELF", "system": "nithishjanithi@sbx" } }, "hiTypes": [ "DiagnosticReport" ], "careContexts": [ { "patientReference": "nithishjanithi@sbx", "careContextReference": "25ac532f-178d-5885-9bcb-b82052f345eb_20260428112424637418" } ], "permission": { "accessMode": "VIEW", "dateRange": { "from": "2026-04-27T09:54:25.533Z", "to": "2026-04-28T05:54:25.533Z" }, "dataEraseAt": "2036-04-28T11:24:25.533Z", "frequency": { "unit": "YEAR", "value": 1, "repeats": 1 } } }, { "requestId": "", "createdAt": "2026-04-28T05:51:02.270Z", "lastUpdated": "2026-04-28T05:51:02.335Z", "status": "GRANTED", "purpose": { "text": "Care Management", "code": "CAREMGT", "refUri": "www.abdm.gov.in" }, "patient": { "id": "nithishjanithi@sbx" }, "hip": { "id": "DigiLocker_NEGD" }, "hiu": { "id": "DigiLocker_NEGD" }, "requester": { "name": "", "identifier": { "value": "SELF", "type": "SELF", "system": "nithishjanithi@sbx" } }, "hiTypes": [ "DiagnosticReport" ], "careContexts": [ { "patientReference": "nithishjanithi@sbx", "careContextReference": "25ac532f-178d-5885-9bcb-b82052f345eb_20260428112100337536" } ], "permission": { "accessMode": "VIEW", "dateRange": { "from": "2026-04-27T09:51:01.358Z", "to": "2026-04-28T05:51:01.358Z" }, "dataEraseAt": "2036-04-28T11:21:01.358Z", "frequency": { "unit": "YEAR", "value": 1, "repeats": 1 } } }, "... 8 more of the same shape" ] } ``` --- # Get Links `POST /api/consent-management/link/get-links` Lists the person's linked care contexts at the HIPs given, for choosing what to grant in a consent. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/link/get-links \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "patientId": "", "hipIds": [ "", "" ] }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `patientId` (string, required) - `hipIds` (string[], required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "patient": { "id": "nithishjanithi@sbx", "links": [ { "hip": { "id": "DigiLocker_NEGD", "name": "", "type": "HIP" }, "referenceNumber": "nithishjanithi@sbx", "display": "Health Document", "careContexts": [ { "referenceNumber": "25ac532f-178d-5885-9bcb-b82052f345eb_20260604192056317009", "display": "DigiLocker_2026-06-04-19:20:57", "hiTypes": [ "OPConsultation" ] } ], "dateCreated": "2026-06-04T13:50:57.157Z" }, { "hip": { "id": "DigiLocker_NEGD", "name": "", "type": "HIP" }, "referenceNumber": "nithishjanithi@sbx", "display": "Health Document", "careContexts": [ { "referenceNumber": "25ac532f-178d-5885-9bcb-b82052f345eb_20260604191949954362", "display": "DigiLocker_2026-06-04-19:19:51", "hiTypes": [ "OPConsultation" ] } ], "dateCreated": "2026-06-04T13:49:51.549Z" }, "... 3 more of the same shape" ] } } ] ``` --- # GET-scheduled push Notifications `GET /api/notification/schedule-push-notification` Lists the push notifications scheduled for later delivery, with their processing state. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/notification/schedule-push-notification \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "id": 682, "patient_id": "", "push_notification_data": { "body": "Don't forget to take your medicine today.", "title": "Medical remainder", "params": { "medicalRemainderId": "279" }, "target": "MEDICATION_REMINDER", "healthId": "", "timestamp": "2026-04-20T09:44:32.878501204Z" }, "date_created": "2026-04-20T15:14:32", "timestamp_to_push": "2026-04-21T17:14:00", "is_processed": true, "processing_started_at": "2026-04-21T17:15:50", "processing_pod_id": "aarogya-setu-notification-app-service-7db645d7f9-pzbvz", "medical_remainder_id": null } ``` --- # Get Subscription Details by Request ID `GET /api/consent-management/subscription-requests/request/{subscriptionRequestId}` Returns one subscription request with its status and details, by the request id. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/consent-management/subscription-requests/request/{subscriptionRequestId} \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `subscriptionRequestId` (string, required): Passed as a path segment. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "requestId": "", "patientId": "", "requesterType": "HEALTH_LOCKER", "status": "UNSUBSCRIBED", "details": { "subscriptionRequestId": "", "purpose": { "text": "Self Requested", "code": "PATRQT", "refUri": "www.abdm.gov.in" }, "patient": { "id": "nithishjanithi@sbx" }, "hiu": { "id": "Priyanka_Health_Locker", "name": "", "type": "HEALTH LOCKER" }, "hips": [], "categories": [ "DATA", "LINK" ], "period": { "from": "2026-05-29T09:19:26.699Z", "to": "2126-05-29T09:18:26.699Z" } }, "dateCreated": "2026-05-29T09:18:26.944Z", "dateModified": "2026-05-29T09:20:41.769Z", "healthIdNumber": "" } ``` --- # Get Subscription Details by Subscription ID `GET /api/consent-management/subscription-requests/{subscriptionId}` Returns one subscription with its details, by the subscription id. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/consent-management/subscription-requests/{subscriptionId} \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `subscriptionId` (string, required): Passed as a path segment. ## Responses - `200`: No response body is documented for this request. --- # HIU Consent Notification `POST /api/consent-management/consent/request/notify` Notification the gateway sends a HIU when a consent request is granted, denied, revoked or expires. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/consent/request/notify \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "notification": { "consentRequestId": "", "status": "DENIED", "consentArtefacts": [ { "id": "" } ] } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `notification` (object, required) - `notification.consentRequestId` (string, required) - `notification.status` (string, required) - `notification.consentArtefacts` (object[], required) - `notification.consentArtefacts.id` (string, required) ## Responses - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors --- # HIU Consent Request On-Init (Callback) `POST /api/consent-management/consent/request/on-init` Callback the gateway sends after a consent request is raised: the request id to track it by, or the error that stopped it. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/consent/request/on-init \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "requestId": "", "timestamp": "", "consentRequest": { "id": "" }, "resp": { "requestId": "" } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `requestId` (string, required) - `timestamp` (string, required) - `consentRequest` (object, required) - `consentRequest.id` (string, required) - `resp` (object, required) - `resp.requestId` (string, required) ## Responses - `200`: No response body is documented for this request. --- # HIU On-Fetch (Consent Artefact Fetch Callback) `POST /api/consent-management/consent/on-fetch` Callback the gateway sends with a consent artefact the HIU asked to fetch, or the error that stopped it. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/consent/on-fetch \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "requestId": "", "timestamp": "", "consent": { "status": "GRANTED", "consentDetail": { "consentId": "", "createdAt": "", "patient": { "id": "@abdm" }, "careContexts": [], "purpose": { "text": "Care Management", "code": "CAREMGT" }, "hip": { "id": "" }, "hiu": { "id": "" }, "consentManager": { "id": "sbx.abdm.gov.in" }, "hiTypes": [ "OPConsultation" ], "permission": { "accessMode": "VIEW", "dateRange": { "from": "2021-01-01T00:00:00.000Z", "to": "2023-12-31T23:59:59.999Z" }, "dataEraseAt": "2024-12-31T23:59:59.999Z", "frequency": { "unit": "HOUR", "value": 1, "repeats": 0 } } }, "signature": "" }, "resp": { "requestId": "" } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `requestId` (string, required) - `timestamp` (string, required) - `consent` (object, required) - `consent.status` (string, required) - `consent.consentDetail` (object, required) - `consent.consentDetail.consentId` (string, required) - `consent.consentDetail.createdAt` (string, required) - `consent.consentDetail.patient` (object, required) - `consent.consentDetail.patient.id` (string, required) - `consent.consentDetail.careContexts` (object[], required) - `consent.consentDetail.purpose` (object, required) - `consent.consentDetail.purpose.text` (string, required) - `consent.consentDetail.purpose.code` (string, required) - `consent.consentDetail.hip` (object, required) - `consent.consentDetail.hip.id` (string, required) - `consent.consentDetail.hiu` (object, required) - `consent.consentDetail.hiu.id` (string, required) - `consent.consentDetail.consentManager` (object, required) - `consent.consentDetail.consentManager.id` (string, required) - `consent.consentDetail.hiTypes` (string[], required) - `consent.consentDetail.permission` (object, required) - `consent.consentDetail.permission.accessMode` (string, required) - `consent.consentDetail.permission.dateRange` (object, required) - `consent.consentDetail.permission.dataEraseAt` (string, required) - `consent.consentDetail.permission.frequency` (object, required) - `consent.signature` (string, required) - `resp` (object, required) - `resp.requestId` (string, required) ## Responses - `200`: No response body is documented for this request. --- # Init Consent Request `POST /api/consent-management/consent/request/init` Raises a consent request as a HIU: names the patient, the purpose, the record types and the period of care wanted. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/consent/request/init \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "consent": { "purpose": { "text": "Care management", "code": "CAREMGT", "refUri": "www.abdm.gov.in" }, "patient": { "id": "nithishjanithi@sbx" }, "hiu": { "id": "IN0002222" }, "hip": { "id": "wdwsd" }, "careContexts": null, "requester": { "name": "", "identifier": { "type": "REGNO1", "value": "MH1001", "system": "https://www.mciindia.9985" } }, "hiTypes": [ "Prescription" ], "permission": { "accessMode": "VIEW", "dateRange": { "from": "2023-05-09T08:58:09.738Z", "to": "2025-04-12T09:00:00.738Z" }, "dataEraseAt": "2026-09-10T12:26:00.738Z", "frequency": { "unit": "HOUR", "value": 0, "repeats": 0 } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `consent` (object, required) - `consent.purpose` (object, required) - `consent.purpose.text` (string, required) - `consent.purpose.code` (string, required) - `consent.purpose.refUri` (string, required) - `consent.patient` (object, required) - `consent.patient.id` (string, required) - `consent.hiu` (object, required) - `consent.hiu.id` (string, required) - `consent.hip` (object, required) - `consent.hip.id` (string, required) - `consent.careContexts` (null, required) - `consent.requester` (object, required) - `consent.requester.name` (string, required) - `consent.requester.identifier` (object, required) - `consent.requester.identifier.type` (string, required) - `consent.requester.identifier.value` (string, required) - `consent.requester.identifier.system` (string, required) - `consent.hiTypes` (string[], required) - `consent.permission` (object, required) - `consent.permission.accessMode` (string, required) - `consent.permission.dateRange` (object, required) - `consent.permission.dateRange.from` (string, required) - `consent.permission.dateRange.to` (string, required) - `consent.permission.dataEraseAt` (string, required) - `consent.permission.frequency` (object, required) - `consent.permission.frequency.unit` (string, required) - `consent.permission.frequency.value` (integer, required) - `consent.permission.frequency.repeats` (integer, required) ## Responses - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 --- # Initiate Subscription Request `POST /api/consent-management/subscription-requests/init` Raises a subscription request as a HIU: asks to be notified when the patient links new care contexts at the HIPs and categories named, for a period. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/subscription-requests/init \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "hiu": { "id": "" }, "patient": { "id": "@abdm" }, "purpose": { "text": "Care Management", "code": "CAREMGT", "refUri": "www.abdm.gov.in" }, "hips": [ { "id": "" } ], "categories": [ "LINK", "DATA" ], "period": { "from": "2021-01-01T00:00:00.000Z", "to": "2023-12-31T23:59:59.999Z" } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `hiu` (object, required) - `hiu.id` (string, required) - `patient` (object, required) - `patient.id` (string, required) - `purpose` (object, required) - `purpose.text` (string, required) - `purpose.code` (string, required) - `purpose.refUri` (string, required) - `hips` (object[], required) - `hips.id` (string, required) - `categories` (string[], required) - `period` (object, required) - `period.from` (string, required) - `period.to` (string, required) ## Responses - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 --- # Post - add App Notification Token `POST /notification/app-notification-token` Registers a device token for push notifications, with the operating system it belongs to. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/notification/app-notification-token \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "healthId": "", "appToken": "", "osType": "android" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `healthId` (string, required) - `appToken` (string, required) - `osType` (string, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "stateCode": 35, "stateName": "ANDAMAN AND NICOBAR ISLANDS" }, { "stateCode": 28, "stateName": "ANDHRA PRADESH" }, "... 34 more of the same shape" ] ``` --- # Revoke Consent `POST /api/consent-management/consents/revoke` Revokes the consent artefacts given, so the HIUs holding them can no longer fetch under them. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/consents/revoke \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "consents": [ "" ] }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `consents` (string[], required) ## Responses - `200`: Example values, scrubbed. - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": "", "error": { "code": "", "message": "" } } ``` --- # Schedule-push-notification - internal `POST /api/notification/schedule-push-notification` Schedules a push notification to a person for a given time, for example a medication reminder. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/notification/schedule-push-notification \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '{ "patient_id": "", "push_notification_data": { "healthId": "", "target": "TELECONSULTATION", "title": "Doctor Consultation", "body": "You have a doctor booking for Dr Nithish at 09.00 am today.", "timestamp": "2026-04-15T12:30:45.123Z", "params": { "orderId": "001" } }, "timestamp_to_push": "2026-04-15T18:30:00", "medical_remainder_id": "01" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `patient_id` (string, required) - `push_notification_data` (object, required) - `push_notification_data.healthId` (string, required) - `push_notification_data.target` (string, required) - `push_notification_data.title` (string, required) - `push_notification_data.body` (string, required) - `push_notification_data.timestamp` (string, required) - `push_notification_data.params` (object, required) - `push_notification_data.params.orderId` (string, required) - `timestamp_to_push` (string, required) - `medical_remainder_id` (string, required) ## Responses - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors --- # Set Up Subscription for Aarogya Setu `POST /api/consent-management/subscription/setup` Sets up the PHR application's own subscription, so it is notified when the person links new care contexts. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/consent-management/subscription/setup \ --header 'Authorization: Bearer ' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: No response body is documented for this request. --- # Single/Multiple Notification read `POST /api/notification/app-push-notification/all` Marks one or more push notifications as read. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/notification/app-push-notification/all \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data '[ { "id": 515459874, "patientId": "", "pushNotificationData": { "healthId": "", "target": "in.projecteka.jataayu.consent.ui.activity.ConsentDetailsActivity", "title": "Dr. ManishTEST_HIU", "body": "Wants to access your records\nPurpose : Care Management", "timestamp": 1743788382266, "params": { "consentRequestId": "" } }, "dateCreated": "2025-04-04T17:39:42.268Z", "dateModified": "2025-04-04T17:39:42.270Z", "isNotificationRead": false, "unreadCount": 3 } ]' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "stateCode": 0, "stateName": "", "id": 0, "patientId": "", "pushNotificationData": { "healthId": "", "title": "", "body": "<BODY>", "timestamp": "<TIMESTAMP>", "params": { "orderId": "<ORDER_ID>" }, "target": "<TARGET>" }, "dateCreated": "<DATE_CREATED>", "dateModified": "<DATE_MODIFIED>", "isNotificationRead": false, "isDeleted": false } ] ``` --- # Update-scheduled push notification `PUT /api/notification/schedule-push-notification` Changes the delivery time of a scheduled push notification. ```bash curl --request PUT \ --url https://phrsbx.abdm.gov.in/api/notification/schedule-push-notification \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "patient_id": "<PATIENT_ID>", "id": 42, "timestamp_to_push": "2025-08-25 15:00:00", "medical_remainder_id": "MED-NEW-001" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `patient_id` (string, required) - `id` (integer, required) - `timestamp_to_push` (string, required) - `medical_remainder_id` (string, required) ## Responses - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/p3/errors --- # P3 PHR consent and notifications errors Seeing a symptom rather than a code? Start at [Troubleshooting](/docs/hiecm/v3/troubleshooting/). The P3 PHR consent and notifications specification records no error code yet. That is a gap in the specification, not a promise that this module cannot fail. Every code above is recorded in the specification that owns it. The aggregated list across modules is at [error codes](/docs/hiecm/v3/reference/error-codes). [Next Still stuck? Ask for help Where to file what you hit, so the answer lands back in these pages.](/docs/support) --- # P3 PHR consent and notifications P3 is the other side of [M3](/docs/hiecm/v3/api/m3). M3 is a requester asking for records; P3 is the patient deciding. ## What is in it Consent requests received, artefacts granted, revocation, and the notification feed that surfaces all of it. Build for revocation from the start. A consent that worked yesterday can be withdrawn today, and that is the system working correctly. The full operation list is in the [P3 PHR consent and notifications API reference](/reference/hiecm-p3). --- # 1. First Search `POST /api/teleconsulting/search` Searches for teleconsultation services by category. Beckn `search` action; results arrive at `on_search`. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/teleconsulting/search \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:011", "action": "search", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu-sandbox.abdm.gov.in/aarogyasetu/api/v3/app/api/teleconsulting", "message_id": "<TXN_ID>", "timestamp": "2022-07-05T15:24:35", "transaction_id": "<TXN_ID>" }, "message": { "intent": { "category": { "descriptor": { "code": "CARDIOLOGY", "name": "<NAME>" } }, "fulfillment": { "agent": { "name": "<NAME>" }, "type": "Online", "start": { "time": { "timestamp": "2022-07-15T00:00:00" } }, "end": { "time": { "timestamp": "2022-07-16T00:00:00" } } }, "item": { "descriptor": { "code": "Consultation", "name": "<NAME>" } } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.message_id` (string, required) - `context.timestamp` (string, required) - `context.transaction_id` (string, required) - `message` (object, required) - `message.intent` (object, required) - `message.intent.category` (object, required) - `message.intent.category.descriptor` (object, required) - `message.intent.fulfillment` (object, required) - `message.intent.fulfillment.agent` (object, required) - `message.intent.fulfillment.type` (string, required) - `message.intent.fulfillment.start` (object, required) - `message.intent.fulfillment.end` (object, required) - `message.intent.item` (object, required) - `message.intent.item.descriptor` (object, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": { "ack": { "status": "ACK" } } } ``` --- # 1. on_search `POST /api/teleconsulting/on_search` Callback carrying the teleconsultation providers and services that matched a search. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/teleconsulting/on_search \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:080", "action": "on_search", "timestamp": "2022-07-05T15:24:35", "core_version": "0.7.1", "consumer_id": "eua-nha", "consumer_uri": "http://100.65.158.41:8901/api/v1/euaService", "provider_id": "hspa-nha", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1", "transaction_id": "<TXN_ID>", "message_id": "e9" }, "message": { "catalog": { "descriptor": { "name": "<NAME>", "images": "HSPA IMAGE", "short_desc": "Reference HSPA Test hospital", "long_desc": "Expert institution providing patient treatment with specialized health science and auxiliary healthcare staff and extraordinary medical equipments." }, "providers": [ { "id": "1", "descriptor": { "name": "<NAME>", "short_desc": "Expertise in every field with renowned staff.", "long_desc": "We are Test hospital. We have established a very profound name in the healthcare industry by providing expert services in every healthcare fields that we have." }, "categories": [ { "id": "1", "parent_category_id": "101", "descriptor": { "name": "<NAME>", "code": "CARDIOLOGY" } }, { "id": "101", "descriptor": { "name": "<NAME>", "code": "ALLOPATHY" } }, { "id": "0", "parent_category_id": "101", "descriptor": { "name": "<NAME>", "code": "GENERAL MEDICINE, PHARMACY, DENTAL SURGERY" } } ], "fulfillments": [ { "id": "0", "type": "Online", "agent": { "id": "<EMAIL>", "name": "<NAME>", "gender": "M", "tags": { "@abdm/gov/in/experience": "10.0", "@abdm/gov/in/languages": "Hindi, English", "@abdm/gov/in/education": "MBBS, BDS", "@abdm/gov/in/hpr_id": "<ABHA_NUMBER>" } } }, { "id": "1", "type": "Online", "agent": { "id": "<EMAIL>", "name": "<NAME>", "gender": "M", "tags": { "@abdm/gov/in/experience": "5.0", "@abdm/gov/in/languages": "Eng, Hin", "@abdm/gov/in/education": "MBBS", "@abdm/gov/in/hpr_id": "<ABHA_NUMBER>" } } } ], "items": [ { "id": "0", "descriptor": { "name": "<NAME>" }, "price": { "currency": "INR", "value": "20.0" }, "category_id": "0", "fulfillment_id": "0" }, { "id": "1", "descriptor": { "name": "<NAME>" }, "price": { "currency": "INR", "value": "300.0" }, "category_id": "1", "fulfillment_id": "1" } ], "location": { "id": "1", "descriptor": { "name": "<NAME>", "short_desc": "Expertise in every field with renowned staff.", "long_desc": "We are Test hospital. We have established a very profound name in the healthcare industry by providing expert services in every healthcare fields that we have." }, "city": { "name": "<NAME>", "code": "011" }, "country": { "name": "<NAME>", "code": "+91" }, "gps": "18.5246036,73.792927", "address": "<ADDRESS>" } } ] } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.timestamp` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.provider_id` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `context.message_id` (string, required) - `message` (object, required) - `message.catalog` (object, required) - `message.catalog.descriptor` (object, required) - `message.catalog.descriptor.name` (string, required) - `message.catalog.descriptor.images` (string, required) - `message.catalog.descriptor.short_desc` (string, required) - `message.catalog.descriptor.long_desc` (string, required) - `message.catalog.providers` (object[], required) - `message.catalog.providers.id` (string, required) - `message.catalog.providers.descriptor` (object, required) - `message.catalog.providers.categories` (object[], required) - `message.catalog.providers.fulfillments` (object[], required) - `message.catalog.providers.items` (object[], required) - `message.catalog.providers.location` (object, required) ## Responses - `200`: No response body is documented for this request. --- # 1. POST /api/blood-bank/search `POST /api/blood-bank/search` Searches for blood banks and blood availability. Beckn `search` action; results arrive at `on_search`. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/blood-bank/search \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85110", "country": "IND", "city": "std:011", "action": "search", "core_version": "0.9.1", "consumer_id": "aarogya.setu", "consumer_uri": "<BASE_URL>", "transaction_id": "<TRANSACTION_ID>", "message_id": "<MESSAGE_ID>", "timestamp": "<TIMESTAMP>", "ttl": "PT30S" }, "message": { "intent": { "item": { "descriptor": { "name": "<NAME>" }, "category_id": "BLOOD_GROUP" }, "fulfillment": { "type": "BLOOD_BANK" }, "location": { "gps": "28.6139,77.2090", "radius": { "type": "CIRCULAR", "value": "10", "unit": "km" }, "city": { "name": "<NAME>", "code": "std:011" } } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.transaction_id` (string, required) - `context.message_id` (string, required) - `context.timestamp` (string, required) - `context.ttl` (string, required) - `message` (object, required) - `message.intent` (object, required) - `message.intent.item` (object, required) - `message.intent.item.descriptor` (object, required) - `message.intent.item.category_id` (string, required) - `message.intent.fulfillment` (object, required) - `message.intent.fulfillment.type` (string, required) - `message.intent.location` (object, required) - `message.intent.location.gps` (string, required) - `message.intent.location.radius` (object, required) - `message.intent.location.city` (object, required) ## Responses - `200`: No response body is documented for this request. --- # 2. on_search `POST /teleconsulting/on_search` Callback carrying the teleconsultation providers and services that matched a search. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/teleconsulting/on_search \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:080", "action": "on_search", "timestamp": "2022-07-05T15:24:35", "core_version": "0.7.1", "consumer_id": "eua-nha", "consumer_uri": "https://uhieuasandbox.abdm.gov.in/api/v1/euaService", "provider_id": "hspa-nha", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1", "transaction_id": "<TXN_ID>", "message_id": "e9" }, "message": { "catalog": { "descriptor": { "name": "<NAME>", "images": "HSPA IMAGE", "short_desc": "Reference HSPA Test hospital", "long_desc": "Expert institution providing patient treatment with specialized health science and auxiliary healthcare staff and extraordinary medical equipments." }, "providers": [ { "id": "1", "descriptor": { "name": "<NAME>", "short_desc": "Expertise in every field with renowned staff.", "long_desc": "We are Test hospital. We have established a very profound name in the healthcare industry by providing expert services in every healthcare fields that we have." }, "categories": [ { "id": "1", "parent_category_id": "101", "descriptor": { "name": "<NAME>", "code": "CARDIOLOGY" } }, { "id": "101", "descriptor": { "name": "<NAME>", "code": "ALLOPATHY" } }, { "id": "0", "parent_category_id": "101", "descriptor": { "name": "<NAME>", "code": "GENERAL MEDICINE, PHARMACY, DENTAL SURGERY" } } ], "fulfillments": [ { "id": "0", "type": "Physical", "agent": { "id": "<EMAIL>", "image": "/9j/4AAQSkZJRgABAgAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCADIAKADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCU8cZppp559KaV61TERnOaTJ9aeRzSbeaQCDPrQGoC0dPTFIBR1p4NZep61aaVAZJn3N0Cr1NcNqvi++vmZbd2t4SB8qHn8TQkB6VLe29tgyzIgPdmwKjj8U6bbhX/ALQh5OMBwTXjUk8krF2ZmYnJLHJNNDN71XKGp79Z/EPQ48CXUE646GujsfFmg34j8nV7ItIcKjTKrk/7pOf0r5f3HnOaljl29x+dHKhH1uuGGQRz0INPAr5k0jxhrmjBVsdUmjjAwImO9APZWyB+Fet+E/ihY6uiW+rCOyvC2AwyIpPoT909sE+mCeglxYHoGMUpFJFLHOqvE6ujAEMpyCCMg/SpdlSBFtpcVLso2UAQFeKaARU5U56UmznmgDzDGO/NNxTzz60jHjn+daDImB9aaR61IR7UxgBUjEP41mavq9vpVsZJmO48Io6san1S/XTdOlumAIReBnqew/OvJtU1K51C6e4uJNx6AdgPQUIQ7U9Tk1G6a4nbn+FR0X2rP8704qNmZjnH40EY64NUA8Pk5qQBs5HFRRu2QAo49qmaQbjk8jjFAxC5yQevrUoQYyxH401FIJc4HpSEF2+bnjigLEwMajoc/WrCMNmFPP8AOqcYBwPTuanDbQpzxjGaYrHdeDPHd74buIoJy01iWw0ZOdoPcfzx/LJz7/pt7b6nYxXltIrxSDIZTkV8kxOZCc/UV0Xh7xLe6LdiazmZGH38fxD39fxocbiPp/bRsqroupJq+kW18gG2aMOMH1/r2/CtDFZ2EQlMdKTbU2KNtAHkWfwpCR/+umBuOv40m/8AKrKHGmM3r+dIX56/rUZk681IzkvHepGOyjsl+/IdzfQf/X/lXnsr5QAfjXV+Oj/xNEwCT5I5/E1yKo0hCjrVdAJItg4PX27VOLJpOUT86kgthGMsMmta3ZeBispTa2NYwvuYb2VwpOQce1CQ7DwpZu5PaulCIT0zmporaEvuK81Htmty/Y32Miz0qa55cfKOnatGPw8rZMkgX0x2rU3YwBhR6AVLGgJz+tZyqy6GsaUepgSeGwD+7kO33qtPosqLw2SOldccbearvHuz3pKrMHRicTskt5MNnNTW8jpMGXOf51f1a32yBscZ5qnG+WATHFdkJcyucc42dj6Q+FhY+BbRWBG15AATn+In+ZNdrxXF/CtNvgGybP3nkP8A4+R/Su0pPchCcUuKQ4pRikB4lu59KN3cio9+cn+tN3cVRQ8nI9Pem7qaWGCc0zcKQHG+PIG321wB8uChP6/41y1km4lscCu68ZW/n6GZB1idW+ueP61y3lRWsezOAo5NJvQqK1GYJPAq3bR56iq0V7b5wRx61pWtxaMRiVc+nSsJtnRBLuWooCQOOKnjjZelWbdUdRtYEH0qyYB2Fc0qh1qmuhSETE561MkbCrkVvu4Aq+lgNmSwqXUK9mjH8s45pGTA61ozQomf3ikj0NUGljZ9oYZqoybIkl3MnUo12EuCR6isCNAJTiu0eBZIyrruU9ciqmi+Hk1DxjY6V/yymkBbPBKAbmwfXAbFdtCfQ4q8LanvXgazax8E6RA+N32dZCAMY3fNz7810GajQKiKigBVGAB2FPFWcwopaQUUAeGE8Uh9/wCdO68U0jNUUNbB55pp4oOSe+PemnPUYxSGZ+uN/wASqXG08qDn03DP6Vw9wqyH5zxXe6igewmBGeM/lXGS2/mqyAcmok7FwVzNj+yg4WF5CPQkVetLOHUFP2WOZmVlUhUZsE5wMgdTg/kaZb20trMGUFWHGcZrV0pY9Ovftlv+7nwQGCqQM9cAg4rNyRootlWCZ9OuCsjFSDtIPFdJZ3qTgAMDXKaxm5mZy8kkjdWds8Z6VoaDE6j5ieKxqxTVzelJp2OpkLKgCsVHqK57U5isuDeS5P8AAuTWxL5vlgrWY1rcpeLcqfmBzgqKypNI2qpspWtzayP5ctzIrA42kc5/GtIWVjNjbM4PTJbvTrDTok1Fr5jtZm3tDtJjdvcbgevPWrV5C93ftezNunf7zBQoP4Ct5TXRnPGm+qFt7doFKby6dieorT8NTz2XjSxubeGGR3CwDzR03NgkHscHGeevQ1SjLhNpFa/hyF5vEmlpEhdhco5A/uqck/gMn8KinN8xc4R5bM9s+tKBRilA4rsPNFoopaYjw4rntikxUjDBI5pmPzqiyJ1z15pv4YHpTm46Uc0gKmo/8g+fA/gOa5CIgPk12N9n7BP6bGz+VcUrAGs6mxtSepqoiTrnFO+xrzg5plkw4GOataiZYtJuJ4Qd6L1HUepribd7HoKKtc567K/bDEuDt61uaNbkoTnk1j2FsgtBM3zO3zMTXW6HbCQoqsoB7npV1HaNiKUW5DzG0eQw4p5tt0YK4OfStS401/MKF0PbKsCD+NZtxbS2TDn5SexrjTOxplb7O2cfNViG1Tgux+laGmLHdN5bjk9zVq5s44QQKpyYuVXMiaNQuVFdZ8PLMS65NcsissEGFJ/hZjjI/AMPxrl5htGAciu4+GynOon+HEfbr96unDbnFi9InfUtJTwPau08wSnAZoxihaYHi99AYZTxVJmwK6/VNPEqEgZrkLqEwyEEEGqTKImb16e1N3H1NRs2M03f60AOuB5ttLGDjcpHr2rgXYh29jXe7xXF6nB9n1CRMYUnK/SoktC4PUtWE3OSK2hfpBD8xGDwQa5yzYAgE49KvPGPJPOWx3rjlC8jvjUajoR3N0mx4rZQiN1VVGP/AK1aWiie1si+49ehPSubjlmWYx+WMjuDW3aSXKqEdDsP+e1OcHaw6Tu7nQ+d9qhG6Rwp4JB5FSNLEtv5OWb0LHJrKhuhGuxRgZ6YqR7qR8KsKluxPasXTZu52Jra8a3uR1wK1Jb4zIOcmudhNw0uJ1Qem3Na0fCgDk1MopExqN7jySVNelfDuFV0S4lwdzz7ST3AUY/ma82YrjOOa9m0CxbTNDtLRxiREy4JBwx5IyOuCSPwrow8epx4qWljS705TTO9KDXWcJJkeoxThg/SoyAy4IBB9RThjjFMDjpArDBrn9WtLdlLFlB+tZF94luZiRGdgrFlu5ZSS8hOfWqsCC4CLKQpyM1Fn1phcetRTXMNtHvmlRF/2jjNA7k+T61ieI7XzbQXKcPF156rTbrxJbRIfs4MpHc5Arl9Q1C71BSzsfmYKFHRafL1Yc2uhYtbrJB6VfF2SRg9RzXOKzIqtnINWre9+ba351hKHVHRGobQj8x93Q+tbdvLsjVSCe3ArHtZQ6HB6VrQSbkGBtFc8nY66ba2L1vKqlgU5PGStSMygZA5PWooAHTqM05kCjLEVm3c0bfUdwx57U9Zdg5P0qjJeIG2LzUaXBnbaoO0dWzT5LmTqWO+8C6K+p6kNSuF/wBEtG+TnG+XqPwHB+uOvNepbq8j8M/EW30zT00+6tv3Vt+7WSEAHGT94Z65ySRycgkZNeg6P4n0nXEQ2N9DI7gkR7sPgdflPP6V2xhaOh59STlLU3Vb3p4NVw3pT1aqIJwaXdUQPIp+aAPnKe+t4CRLOinuuefyrOn8QWseREryt2/hH+P6VzZBNMK47Ct+QnmNWbxBdykhFSJe23k1mSTGaUySMXc9WPNMCEg9BSqCT1qkkhXGsgZGcnlT079KbaKrAZGQsyHHtmnSKuGU5yeQR2plrgyPGQCHXHtmpmrocXqQFP3YHbJFM+zMTgVoi1L2ZfB4kbt71JBEGwCK43Ox1qNyta3EtqcHOPRq149Sk8vaqJk991KlkSp24Yehp8enJn5o2X3FZucXuaKMlsOhvriMjgYz605r26uGEak49FGau29jAAAU3n3FaMUGB8qBR+VZupFbI0UJPdmVBp8r/NM20H+Edfxq95YjQKgAA7Crfl4FU7tySLeJsSuM5/uL3b/D1P41CqOTLcFFGMsrGF14wbidv0jH9KppKUldM8Vcl2h2RPlSKIAf8C5H/joWqKFRNuODxivUoO8LnmVfisdZZfEDxLYRJHHqUrxo2dsqrJuHoWYFsewI9q9C8LfFKz1NltdZRLO4J+WZM+U3PQ5yV7ckkcEkjpXiik45PNKpK4II49a0cEzO59Xg465qQHivnnQ/H+uaOkUEV15ltHwIZgHXGMAZ+8AOMAEDivRtI+KmmXbBb61mtCWI3qfNQDHU4AP4AGsnTaHc8A6ngUhDE+tBPHU/lTycjuc81uSM9qao+bPank89PzoUH+FRTAY2chux4P8A9eq7Axy8ZHOau9QwIGDwaiZN2QwwQMj3FJoDb06ZL228kqAwByAMULYMH6YrDt5ntpdyHBHH+f8AP9a63T9Qgu1CyMqSD14rgxFKS96J20KifuyFtYCvDCr6WwbkLUpg2dafH8tedKTO9JDFgYdjUoiNTqfeqVzcySStBagM68PI33I/r6n2/lSV2xtpFa/vPs7i3hXzbpx8qDsPVvQVl3MgsIjE7Ga5nOZcdWHp7DsPrVieW105pPKJnu5PvtnJJ9+w+grILMsrSyNvmfrjt9K7KFBz9DkrVeX1GyuYomV2BldjJIQOCx5qtEAFLEfMeBnt/nmkLGWTDYxnk+v+f8+pftJAweP4Qf516iSSsjzm76sAvHuaXBAFLgjjOfwpDnJwaoQDIP8A9bpU6SOhyCfwqvtJOeKepJzgnH6UAU93cc0gcnj+tNJXPfNOJx+FAAWPTI6UFj1x+VJkY+7n6U0MOfl5oAmDEEds0pIcbehHIb0qNW78gU4jcvGOOlADNuTzwR/n/P8A9enxs0bAhtpB4IP+f/1GgfOcbsEcZFKEOQuMjvj/AD9PypAb+iTz32p2loVllV5QHSIMzbQctgLk9Aa9K0vwBBrD3EsWpmFFnkjWJ4n3AKxHILg9u9eeeBZIbfxlYyzMVjxOhI7FoXA/U4/GvZTr58M+C11R40aa8kMkanO3fJuk5IHQDcffGMjOa468E5aI6adRqO5HJ8LdN8ooZS4zjLGXPT1WQe35Vjn4faYtxPpys8UKpGUcQTnYXLDPL4wCAefx9ao+Hvilqtz4qjtNTED29zMsIWFdoibdgMDnkZPOSeOQeMHv/Ek6RaBrN8Ig72lq0xAPJKAuMeh44OOKzdOxaqa6nzpJKscC+Vhc9SByeaoMWfOOB6/0/GrbRZRRySqAADj1zz+VV5isXBwW9B0H+RXopWRxuV2Qg/dRQMfzqXLdMg81FGQW3HipGcgbhnng0CHfePX60jHIx3PWhWJB4Ge5zTWYg8DmgBQSF6Z59acp565pnUf/AFqXkAfSgZR3Z745pRu3AEn1qPdgY459aercd+uKQD/mORk+tNUFuuf6Up9D/OhCd2cfgTQA8LT19wOexNNzkcrz6Uu5dvGaYhvIPNSBSeQ1JwRjH04oAKNyDg/hQFzuPhnbpceJpoJ4i6S2kiKw6q2VOfrgNXq154YXxP8AD/TrAzeRJHBFLDIckBgmOQMZBVmHtnOOK8y+Hwg+wa/NI+2SCBGjOOu5ZVI/UV7RoMKv4c048jdaxnr/ALIrlq/Fc1Wx5x4a+F97puvWt5ql9ayx2zLKsdsWYs4OQCWUYAPPv0rtdbVv+Eb8TqUA3204U5ycfZuv510iwxqo24A9a5fxZdJZeGddlfAX5oskAcvAFH15YD1qL3aGj58uJ2CqMljj1rPkJdsValcknJzntmq643HBGScV2mKHIML8uM/nQSCwycD6UrqoI4PvTFBbgH9OaAHkgKc8+4ppIJ4BqXcMDnI75qMHJPOaYARlgduRSkEHBGKAfYkelAIxnbjHSkBnJ8w+Y/nSrx0x6UUUkMfjP3uffNKpGf50UUAPGWH04pD2HGaKKYh6nB6+9SnkEkkg9s80UUDO78DWtufDmvXtzvxsjiUj1zn8sla9r8PGWPQbSG5jEUiRhAo7ADAoorjqfEzRbIuMrB8AmuK+J2oGDwRLbXKIVvpgkbxcjKyK6fiUQ/jRRSgveQ+jPBpctwQT/SmhfmBOPxFFFdpiNfcRnPTgClQHbn27UUUwEycYwRRgryBxRRSAcNxGC3HvSHOMY/H1oopgf//Z", "name": "<NAME>", "gender": "M", "tags": { "@abdm/gov/in/experience": "10.0", "@abdm/gov/in/languages": "Hindi, English", "@abdm/gov/in/education": "MBBS, BDS", "@abdm/gov/in/hpr_id": "<ABHA_NUMBER>" } }, "start": { "time": { "timestamp": "2023-01-03T12:30:00" } }, "end": { "time": { "timestamp": "2023-01-03T12:45:00" } } }, { "id": "1", "type": "Physical", "agent": { "id": "<EMAIL>", "name": "<NAME>", "gender": "M", "tags": { "@abdm/gov/in/experience": "5.0", "@abdm/gov/in/languages": "Eng, Hin", "@abdm/gov/in/education": "MBBS", "@abdm/gov/in/hpr_id": "<ABHA_NUMBER>" } }, "start": { "time": { "timestamp": "2023-01-03T12:30:00" } }, "end": { "time": { "timestamp": "2023-01-03T12:45:00" } } } ], "items": [ { "id": "0", "descriptor": { "name": "<NAME>" }, "price": { "currency": "INR", "value": "20.0" }, "category_id": "0", "fulfillment_id": "0" }, { "id": "1", "descriptor": { "name": "<NAME>" }, "price": { "currency": "INR", "value": "300.0" }, "category_id": "1", "fulfillment_id": "1" } ], "location": { "id": "1", "descriptor": { "name": "<NAME>", "short_desc": "Expertise in every field with renowned staff.", "long_desc": "We are Test hospital. We have established a very profound name in the healthcare industry by providing expert services in every healthcare fields that we have." }, "city": { "name": "<NAME>", "code": "011" }, "country": { "name": "<NAME>", "code": "+91" }, "gps": "18.5246036,73.792927", "address": "<ADDRESS>" } } ] } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.timestamp` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.provider_id` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `context.message_id` (string, required) - `message` (object, required) - `message.catalog` (object, required) - `message.catalog.descriptor` (object, required) - `message.catalog.descriptor.name` (string, required) - `message.catalog.descriptor.images` (string, required) - `message.catalog.descriptor.short_desc` (string, required) - `message.catalog.descriptor.long_desc` (string, required) - `message.catalog.providers` (object[], required) - `message.catalog.providers.id` (string, required) - `message.catalog.providers.descriptor` (object, required) - `message.catalog.providers.categories` (object[], required) - `message.catalog.providers.fulfillments` (object[], required) - `message.catalog.providers.items` (object[], required) - `message.catalog.providers.location` (object, required) ## Responses - `200`: No response body is documented for this request. --- # 2. POST /api/blood-bank/on_search `POST /api/blood-bank/on_search` Callback carrying the blood banks and stock that matched a search. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/blood-bank/on_search \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85110", "country": "IND", "city": "std:011", "action": "on_search", "core_version": "0.9.1", "consumer_id": "aarogya.setu", "consumer_uri": "<BASE_URL>", "provider_id": "bloodbank.provider.in", "provider_uri": "https://bloodbank-provider.example.in/api", "transaction_id": "<TRANSACTION_ID>", "message_id": "<MESSAGE_ID>", "timestamp": "<TIMESTAMP>" }, "message": { "catalog": { "descriptor": { "name": "<NAME>" }, "providers": [ { "id": "BB_AIIMS_001", "descriptor": { "name": "<NAME>", "short_desc": "All India Institute of Medical Sciences Blood Bank" }, "location": { "id": "LOC001", "gps": "28.5672,77.2100", "address": "<ADDRESS>", "city": { "name": "<NAME>", "code": "std:011" }, "state": { "name": "<NAME>" }, "country": { "name": "<NAME>", "code": "IND" } }, "contact": { "phone": "<MOBILE>", "email": "<EMAIL>" }, "categories": [ { "id": "BLOOD_GROUP", "descriptor": { "name": "<NAME>", "code": "BG" } } ], "items": [ { "id": "ITEM_O_POS_001", "descriptor": { "name": "<NAME>", "code": "O_POSITIVE" }, "category_id": "BLOOD_GROUP", "quantity": { "count": 15 }, "provider_id": "BB_AIIMS_001" }, { "id": "ITEM_A_POS_001", "descriptor": { "name": "<NAME>", "code": "A_POSITIVE" }, "category_id": "BLOOD_GROUP", "quantity": { "count": 8 }, "provider_id": "BB_AIIMS_001" } ], "fulfillments": [ { "id": "FF001", "type": "BLOOD_BANK", "tracking": false } ] } ] } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.provider_id` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `context.message_id` (string, required) - `context.timestamp` (string, required) - `message` (object, required) - `message.catalog` (object, required) - `message.catalog.descriptor` (object, required) - `message.catalog.descriptor.name` (string, required) - `message.catalog.providers` (object[], required) - `message.catalog.providers.id` (string, required) - `message.catalog.providers.descriptor` (object, required) - `message.catalog.providers.location` (object, required) - `message.catalog.providers.contact` (object, required) - `message.catalog.providers.categories` (object[], required) - `message.catalog.providers.items` (object[], required) - `message.catalog.providers.fulfillments` (object[], required) ## Responses - `200`: No response body is documented for this request. --- # 2. Second Search `POST /teleconsulting/search` Refines a teleconsultation search, for example by provider or time slot. Beckn `search` action; results arrive at `on_search`. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/teleconsulting/search \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:011", "action": "search", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu-sandbox.abdm.gov.in/aarogyasetu/api/v3/app/api/teleconsulting", "provider_id": "hspa-nha", "message_id": "<TXN_ID>", "timestamp": "<TXN_ID>", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1", "transaction_id": "<TXN_ID>" }, "message": { "intent": { "provider": { "id": "1", "categories": [ { "id": "201", "parent_category_id": "101", "descriptor": { "name": "<NAME>", "code": "CARDIOLOGY" } }, { "id": "101", "descriptor": { "name": "<NAME>", "code": "ALLOPATHY" } } ], "fulfillments": [ { "type": "Online", "agent": { "id": "<EMAIL>", "image": null }, "start": { "time": { "timestamp": "2024-06-25T10:30:27" } }, "end": { "time": { "timestamp": "2024-06-25T23:59:59" } } } ], "items": [ { "id": "1", "descriptor": { "name": "<NAME>", "code": "CONSULTATION" }, "price": { "currency": "INR", "value": "0.0" }, "fulfillment_id": "1", "category_id": "201" } ] } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.provider_id` (string, required) - `context.message_id` (string, required) - `context.timestamp` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `message` (object, required) - `message.intent` (object, required) - `message.intent.provider` (object, required) - `message.intent.provider.id` (string, required) - `message.intent.provider.categories` (object[], required) - `message.intent.provider.fulfillments` (object[], required) - `message.intent.provider.items` (object[], required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": { "ack": { "status": "ACK" } } } ``` --- # 3. Init `POST /teleconsulting/init` Initialises a teleconsultation booking for the service selected. Beckn `init` action; the reply arrives at `on_init`. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/teleconsulting/init \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:011", "action": "init", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu-sandbox.abdm.gov.in/aarogyasetu/api/v3/app/api/teleconsulting", "provider_id": "hspa-nha", "message_id": "<TXN_ID>", "timestamp": "2024-06-25T05:09:45.791121Z", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1", "transaction_id": "<TXN_ID>" }, "message": { "order": { "provider": { "id": "1" }, "item": { "id": "0", "descriptor": { "name": "<NAME>", "code": "CONSULTATION" }, "price": { "currency": "INR", "value": "0.0" }, "fulfillment_id": "<TXN_ID>" }, "fulfillment": { "id": "<TXN_ID>", "type": "Online", "agent": { "id": "<EMAIL>", "name": "<NAME>", "image": "/9j/4AAQSkZJRgABAgAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCADIAKADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCU8cZppp559KaV61TERnOaTJ9aeRzSbeaQCDPrQGoC0dPTFIBR1p4NZep61aaVAZJn3N0Cr1NcNqvi++vmZbd2t4SB8qHn8TQkB6VLe29tgyzIgPdmwKjj8U6bbhX/ALQh5OMBwTXjUk8krF2ZmYnJLHJNNDN71XKGp79Z/EPQ48CXUE646GujsfFmg34j8nV7ItIcKjTKrk/7pOf0r5f3HnOaljl29x+dHKhH1uuGGQRz0INPAr5k0jxhrmjBVsdUmjjAwImO9APZWyB+Fet+E/ihY6uiW+rCOyvC2AwyIpPoT909sE+mCeglxYHoGMUpFJFLHOqvE6ujAEMpyCCMg/SpdlSBFtpcVLso2UAQFeKaARU5U56UmznmgDzDGO/NNxTzz60jHjn+daDImB9aaR61IR7UxgBUjEP41mavq9vpVsZJmO48Io6san1S/XTdOlumAIReBnqew/OvJtU1K51C6e4uJNx6AdgPQUIQ7U9Tk1G6a4nbn+FR0X2rP8704qNmZjnH40EY64NUA8Pk5qQBs5HFRRu2QAo49qmaQbjk8jjFAxC5yQevrUoQYyxH401FIJc4HpSEF2+bnjigLEwMajoc/WrCMNmFPP8AOqcYBwPTuanDbQpzxjGaYrHdeDPHd74buIoJy01iWw0ZOdoPcfzx/LJz7/pt7b6nYxXltIrxSDIZTkV8kxOZCc/UV0Xh7xLe6LdiazmZGH38fxD39fxocbiPp/bRsqroupJq+kW18gG2aMOMH1/r2/CtDFZ2EQlMdKTbU2KNtAHkWfwpCR/+umBuOv40m/8AKrKHGmM3r+dIX56/rUZk681IzkvHepGOyjsl+/IdzfQf/X/lXnsr5QAfjXV+Oj/xNEwCT5I5/E1yKo0hCjrVdAJItg4PX27VOLJpOUT86kgthGMsMmta3ZeBispTa2NYwvuYb2VwpOQce1CQ7DwpZu5PaulCIT0zmporaEvuK81Htmty/Y32Miz0qa55cfKOnatGPw8rZMkgX0x2rU3YwBhR6AVLGgJz+tZyqy6GsaUepgSeGwD+7kO33qtPosqLw2SOldccbearvHuz3pKrMHRicTskt5MNnNTW8jpMGXOf51f1a32yBscZ5qnG+WATHFdkJcyucc42dj6Q+FhY+BbRWBG15AATn+In+ZNdrxXF/CtNvgGybP3nkP8A4+R/Su0pPchCcUuKQ4pRikB4lu59KN3cio9+cn+tN3cVRQ8nI9Pem7qaWGCc0zcKQHG+PIG321wB8uChP6/41y1km4lscCu68ZW/n6GZB1idW+ueP61y3lRWsezOAo5NJvQqK1GYJPAq3bR56iq0V7b5wRx61pWtxaMRiVc+nSsJtnRBLuWooCQOOKnjjZelWbdUdRtYEH0qyYB2Fc0qh1qmuhSETE561MkbCrkVvu4Aq+lgNmSwqXUK9mjH8s45pGTA61ozQomf3ikj0NUGljZ9oYZqoybIkl3MnUo12EuCR6isCNAJTiu0eBZIyrruU9ciqmi+Hk1DxjY6V/yymkBbPBKAbmwfXAbFdtCfQ4q8LanvXgazax8E6RA+N32dZCAMY3fNz7810GajQKiKigBVGAB2FPFWcwopaQUUAeGE8Uh9/wCdO68U0jNUUNbB55pp4oOSe+PemnPUYxSGZ+uN/wASqXG08qDn03DP6Vw9wqyH5zxXe6igewmBGeM/lXGS2/mqyAcmok7FwVzNj+yg4WF5CPQkVetLOHUFP2WOZmVlUhUZsE5wMgdTg/kaZb20trMGUFWHGcZrV0pY9Ovftlv+7nwQGCqQM9cAg4rNyRootlWCZ9OuCsjFSDtIPFdJZ3qTgAMDXKaxm5mZy8kkjdWds8Z6VoaDE6j5ieKxqxTVzelJp2OpkLKgCsVHqK57U5isuDeS5P8AAuTWxL5vlgrWY1rcpeLcqfmBzgqKypNI2qpspWtzayP5ctzIrA42kc5/GtIWVjNjbM4PTJbvTrDTok1Fr5jtZm3tDtJjdvcbgevPWrV5C93ftezNunf7zBQoP4Ct5TXRnPGm+qFt7doFKby6dieorT8NTz2XjSxubeGGR3CwDzR03NgkHscHGeevQ1SjLhNpFa/hyF5vEmlpEhdhco5A/uqck/gMn8KinN8xc4R5bM9s+tKBRilA4rsPNFoopaYjw4rntikxUjDBI5pmPzqiyJ1z15pv4YHpTm46Uc0gKmo/8g+fA/gOa5CIgPk12N9n7BP6bGz+VcUrAGs6mxtSepqoiTrnFO+xrzg5plkw4GOataiZYtJuJ4Qd6L1HUepribd7HoKKtc567K/bDEuDt61uaNbkoTnk1j2FsgtBM3zO3zMTXW6HbCQoqsoB7npV1HaNiKUW5DzG0eQw4p5tt0YK4OfStS401/MKF0PbKsCD+NZtxbS2TDn5SexrjTOxplb7O2cfNViG1Tgux+laGmLHdN5bjk9zVq5s44QQKpyYuVXMiaNQuVFdZ8PLMS65NcsissEGFJ/hZjjI/AMPxrl5htGAciu4+GynOon+HEfbr96unDbnFi9InfUtJTwPau08wSnAZoxihaYHi99AYZTxVJmwK6/VNPEqEgZrkLqEwyEEEGqTKImb16e1N3H1NRs2M03f60AOuB5ttLGDjcpHr2rgXYh29jXe7xXF6nB9n1CRMYUnK/SoktC4PUtWE3OSK2hfpBD8xGDwQa5yzYAgE49KvPGPJPOWx3rjlC8jvjUajoR3N0mx4rZQiN1VVGP/AK1aWiie1si+49ehPSubjlmWYx+WMjuDW3aSXKqEdDsP+e1OcHaw6Tu7nQ+d9qhG6Rwp4JB5FSNLEtv5OWb0LHJrKhuhGuxRgZ6YqR7qR8KsKluxPasXTZu52Jra8a3uR1wK1Jb4zIOcmudhNw0uJ1Qem3Na0fCgDk1MopExqN7jySVNelfDuFV0S4lwdzz7ST3AUY/ma82YrjOOa9m0CxbTNDtLRxiREy4JBwx5IyOuCSPwrow8epx4qWljS705TTO9KDXWcJJkeoxThg/SoyAy4IBB9RThjjFMDjpArDBrn9WtLdlLFlB+tZF94luZiRGdgrFlu5ZSS8hOfWqsCC4CLKQpyM1Fn1phcetRTXMNtHvmlRF/2jjNA7k+T61ieI7XzbQXKcPF156rTbrxJbRIfs4MpHc5Arl9Q1C71BSzsfmYKFHRafL1Yc2uhYtbrJB6VfF2SRg9RzXOKzIqtnINWre9+ba351hKHVHRGobQj8x93Q+tbdvLsjVSCe3ArHtZQ6HB6VrQSbkGBtFc8nY66ba2L1vKqlgU5PGStSMygZA5PWooAHTqM05kCjLEVm3c0bfUdwx57U9Zdg5P0qjJeIG2LzUaXBnbaoO0dWzT5LmTqWO+8C6K+p6kNSuF/wBEtG+TnG+XqPwHB+uOvNepbq8j8M/EW30zT00+6tv3Vt+7WSEAHGT94Z65ySRycgkZNeg6P4n0nXEQ2N9DI7gkR7sPgdflPP6V2xhaOh59STlLU3Vb3p4NVw3pT1aqIJwaXdUQPIp+aAPnKe+t4CRLOinuuefyrOn8QWseREryt2/hH+P6VzZBNMK47Ct+QnmNWbxBdykhFSJe23k1mSTGaUySMXc9WPNMCEg9BSqCT1qkkhXGsgZGcnlT079KbaKrAZGQsyHHtmnSKuGU5yeQR2plrgyPGQCHXHtmpmrocXqQFP3YHbJFM+zMTgVoi1L2ZfB4kbt71JBEGwCK43Ox1qNyta3EtqcHOPRq149Sk8vaqJk991KlkSp24Yehp8enJn5o2X3FZucXuaKMlsOhvriMjgYz605r26uGEak49FGau29jAAAU3n3FaMUGB8qBR+VZupFbI0UJPdmVBp8r/NM20H+Edfxq95YjQKgAA7Crfl4FU7tySLeJsSuM5/uL3b/D1P41CqOTLcFFGMsrGF14wbidv0jH9KppKUldM8Vcl2h2RPlSKIAf8C5H/joWqKFRNuODxivUoO8LnmVfisdZZfEDxLYRJHHqUrxo2dsqrJuHoWYFsewI9q9C8LfFKz1NltdZRLO4J+WZM+U3PQ5yV7ckkcEkjpXiik45PNKpK4II49a0cEzO59Xg465qQHivnnQ/H+uaOkUEV15ltHwIZgHXGMAZ+8AOMAEDivRtI+KmmXbBb61mtCWI3qfNQDHU4AP4AGsnTaHc8A6ngUhDE+tBPHU/lTycjuc81uSM9qao+bPank89PzoUH+FRTAY2chux4P8A9eq7Axy8ZHOau9QwIGDwaiZN2QwwQMj3FJoDb06ZL228kqAwByAMULYMH6YrDt5ntpdyHBHH+f8AP9a63T9Qgu1CyMqSD14rgxFKS96J20KifuyFtYCvDCr6WwbkLUpg2dafH8tedKTO9JDFgYdjUoiNTqfeqVzcySStBagM68PI33I/r6n2/lSV2xtpFa/vPs7i3hXzbpx8qDsPVvQVl3MgsIjE7Ga5nOZcdWHp7DsPrVieW105pPKJnu5PvtnJJ9+w+grILMsrSyNvmfrjt9K7KFBz9DkrVeX1GyuYomV2BldjJIQOCx5qtEAFLEfMeBnt/nmkLGWTDYxnk+v+f8+pftJAweP4Qf516iSSsjzm76sAvHuaXBAFLgjjOfwpDnJwaoQDIP8A9bpU6SOhyCfwqvtJOeKepJzgnH6UAU93cc0gcnj+tNJXPfNOJx+FAAWPTI6UFj1x+VJkY+7n6U0MOfl5oAmDEEds0pIcbehHIb0qNW78gU4jcvGOOlADNuTzwR/n/P8A9enxs0bAhtpB4IP+f/1GgfOcbsEcZFKEOQuMjvj/AD9PypAb+iTz32p2loVllV5QHSIMzbQctgLk9Aa9K0vwBBrD3EsWpmFFnkjWJ4n3AKxHILg9u9eeeBZIbfxlYyzMVjxOhI7FoXA/U4/GvZTr58M+C11R40aa8kMkanO3fJuk5IHQDcffGMjOa468E5aI6adRqO5HJ8LdN8ooZS4zjLGXPT1WQe35Vjn4faYtxPpys8UKpGUcQTnYXLDPL4wCAefx9ao+Hvilqtz4qjtNTED29zMsIWFdoibdgMDnkZPOSeOQeMHv/Ek6RaBrN8Ig72lq0xAPJKAuMeh44OOKzdOxaqa6nzpJKscC+Vhc9SByeaoMWfOOB6/0/GrbRZRRySqAADj1zz+VV5isXBwW9B0H+RXopWRxuV2Qg/dRQMfzqXLdMg81FGQW3HipGcgbhnng0CHfePX60jHIx3PWhWJB4Ge5zTWYg8DmgBQSF6Z59acp565pnUf/AFqXkAfSgZR3Z745pRu3AEn1qPdgY459aercd+uKQD/mORk+tNUFuuf6Up9D/OhCd2cfgTQA8LT19wOexNNzkcrz6Uu5dvGaYhvIPNSBSeQ1JwRjH04oAKNyDg/hQFzuPhnbpceJpoJ4i6S2kiKw6q2VOfrgNXq154YXxP8AD/TrAzeRJHBFLDIckBgmOQMZBVmHtnOOK8y+Hwg+wa/NI+2SCBGjOOu5ZVI/UV7RoMKv4c048jdaxnr/ALIrlq/Fc1Wx5x4a+F97puvWt5ql9ayx2zLKsdsWYs4OQCWUYAPPv0rtdbVv+Eb8TqUA3204U5ycfZuv510iwxqo24A9a5fxZdJZeGddlfAX5oskAcvAFH15YD1qL3aGj58uJ2CqMljj1rPkJdsValcknJzntmq643HBGScV2mKHIML8uM/nQSCwycD6UrqoI4PvTFBbgH9OaAHkgKc8+4ppIJ4BqXcMDnI75qMHJPOaYARlgduRSkEHBGKAfYkelAIxnbjHSkBnJ8w+Y/nSrx0x6UUUkMfjP3uffNKpGf50UUAPGWH04pD2HGaKKYh6nB6+9SnkEkkg9s80UUDO78DWtufDmvXtzvxsjiUj1zn8sla9r8PGWPQbSG5jEUiRhAo7ADAoorjqfEzRbIuMrB8AmuK+J2oGDwRLbXKIVvpgkbxcjKyK6fiUQ/jRRSgveQ+jPBpctwQT/SmhfmBOPxFFFdpiNfcRnPTgClQHbn27UUUwEycYwRRgryBxRRSAcNxGC3HvSHOMY/H1oopgf//Z", "gender": "M", "tags": { "@abdm/gov.in/experience": "5.0", "@abdm/gov.in/languages": "Eng, Hin", "@abdm/gov.in/education": "MBBS", "@abdm/gov.in/hpr_id": "<ABHA_NUMBER>" } }, "start": { "time": { "timestamp": "2024-06-25T13:00:00" } }, "end": { "time": { "timestamp": "2024-06-25T13:15:00" } }, "tags": { "@abdm/gov.in/slot_id": "<TXN_ID>" } }, "billing": { "name": "<NAME>", "address": { "door": "", "name": "<NAME>", "locality": "13-6-454/36/1, Hiranagar, Gudimalkapur, Asifnagar, Hyderabad, Andhra Pradesh", "city": null, "state": "Telangana", "country": "INDIA", "area_code": "500067" }, "phone": "<MOBILE>", "email": "<EMAIL>" }, "customer": { "person": { "dob": "<DATE_OF_BIRTH>", "gender": "M", "dayOfBirth": 20, "monthOfBirth": 12, "yearOfBirth": 2000 }, "id": "<REDACTED_ID>@sbx" } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.provider_id` (string, required) - `context.message_id` (string, required) - `context.timestamp` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `message` (object, required) - `message.order` (object, required) - `message.order.provider` (object, required) - `message.order.provider.id` (string, required) - `message.order.item` (object, required) - `message.order.item.id` (string, required) - `message.order.item.descriptor` (object, required) - `message.order.item.price` (object, required) - `message.order.item.fulfillment_id` (string, required) - `message.order.fulfillment` (object, required) - `message.order.fulfillment.id` (string, required) - `message.order.fulfillment.type` (string, required) - `message.order.fulfillment.agent` (object, required) - `message.order.fulfillment.start` (object, required) - `message.order.fulfillment.end` (object, required) - `message.order.fulfillment.tags` (object, required) - `message.order.billing` (object, required) - `message.order.billing.name` (string, required) - `message.order.billing.address` (object, required) - `message.order.billing.phone` (string, required) - `message.order.billing.email` (string, required) - `message.order.customer` (object, required) - `message.order.customer.person` (object, required) - `message.order.customer.id` (string, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": { "ack": { "status": "ACK" } } } ``` --- # 3. on_init `POST /teleconsulting/on_init` Callback carrying the provider's reply to a teleconsultation `init`: the quote and the terms to confirm. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/teleconsulting/on_init \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:011", "action": "on_init", "timestamp": "2025-09-10T08:06:14.327Z", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu-sandbox.abdm.gov.in/aarogyasetu/api/v3/app/api/teleconsulting", "provider_id": "hspa-nha", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1", "transaction_id": "<TXN_ID>", "message_id": "<TXN_ID>" }, "message": { "order": { "id": "1944-731810-6639", "provider": { "id": "1" }, "item": { "id": "0", "descriptor": { "name": "<NAME>", "code": "CONSULTATION", "flag": false }, "price": { "currency": "INR", "value": "0.0" }, "fulfillment_id": "<TXN_ID>" }, "fulfillment": { "id": "<TXN_ID>", "type": "Online", "agent": { "id": "<EMAIL>", "name": "<NAME>", "gender": "M", "tags": { "@abdm/gov.in/education": "MBBS", "@abdm/gov.in/experience": "5.0", "@abdm/gov.in/hpr_id": "<EMAIL>", "@abdm/gov.in/languages": "Eng, Hin" } }, "start": { "time": { "timestamp": "2025-09-11T12:00:00" } }, "end": { "time": { "timestamp": "2025-09-11T12:15:00" } }, "tags": { "@abdm/gov.in/slot_id": "<TXN_ID>" } }, "billing": { "name": "<NAME>", "address": { "door": "54", "name": "<NAME>", "locality": "Nethaji subhash chandra bose street, GNT road, Gummidipoondi, Thiruvallur", "state": "Tamil Nadu", "country": "INDIA", "area_code": "601201" }, "email": "<EMAIL>", "phone": "<MOBILE>" }, "quote": { "price": { "currency": "INR", "value": "0.0" }, "breakup": [ { "title": "Consultation", "price": { "currency": "INR", "value": "0.0" } }, { "title": "CGST @ 5%", "price": { "currency": "INR", "value": "0.0" } }, { "title": "SGST @ 5%", "price": { "currency": "INR", "value": "0.0" } }, { "title": "Registration", "price": { "currency": "INR", "value": "0" } } ] }, "customer": { "id": "nithishjaniti@sbx", "person": { "gender": "M", "dayOfBirth": 14, "monthOfBirth": 10, "yearOfBirth": 1999, "dob": "<DATE_OF_BIRTH>" } }, "payment": { "type": "ON-ORDER", "status": "FREE" }, "terms": [ { "type": "Commercial", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of commercial terms", "long_desc": "Long description of commercial terms" }, "reasonRequired": false, "timePeriod": "2025-09-11T12:00:00", "reason": "", "termsState": "INITIATED" }, { "type": "Settlement", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of Settlement terms", "long_desc": "Long description of Settlement terms" }, "reasonRequired": false, "timePeriod": "2025-09-11T12:00:00", "reason": "", "termsState": "INITIATED" }, { "type": "Cancellation", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of Cancellation terms", "long_desc": "Cancellation: Full refund if cancelled 48 hrs before consultation time. \\n Rescheduling: No charges for rescheduling 48 hrs prior to consultation time" }, "reasonRequired": false, "timePeriod": "2025-09-11T12:00:00", "reason": "", "termsState": "INITIATED" }, { "type": "Refund", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of Refund terms", "long_desc": "No Show: If doctor does not show up - full refund. No refund if patient does not turn up for appointment" }, "reasonRequired": false, "timePeriod": "2025-09-11T12:00:00", "reason": "", "termsState": "INITIATED" }, { "type": "Payment", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of Payment terms", "long_desc": "Long description of Payment terms" }, "reasonRequired": false, "timePeriod": "2025-09-11T12:00:00", "reason": "", "termsState": "INITIATED" } ] } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.timestamp` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.provider_id` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `context.message_id` (string, required) - `message` (object, required) - `message.order` (object, required) - `message.order.id` (string, required) - `message.order.provider` (object, required) - `message.order.provider.id` (string, required) - `message.order.item` (object, required) - `message.order.item.id` (string, required) - `message.order.item.descriptor` (object, required) - `message.order.item.price` (object, required) - `message.order.item.fulfillment_id` (string, required) - `message.order.fulfillment` (object, required) - `message.order.fulfillment.id` (string, required) - `message.order.fulfillment.type` (string, required) - `message.order.fulfillment.agent` (object, required) - `message.order.fulfillment.start` (object, required) - `message.order.fulfillment.end` (object, required) - `message.order.fulfillment.tags` (object, required) - `message.order.billing` (object, required) - `message.order.billing.name` (string, required) - `message.order.billing.address` (object, required) - `message.order.billing.email` (string, required) - `message.order.billing.phone` (string, required) - `message.order.quote` (object, required) - `message.order.quote.price` (object, required) - `message.order.quote.breakup` (object[], required) - `message.order.customer` (object, required) - `message.order.customer.id` (string, required) - `message.order.customer.person` (object, required) - `message.order.payment` (object, required) - `message.order.payment.type` (string, required) - `message.order.payment.status` (string, required) - `message.order.terms` (object[], required) - `message.order.terms.type` (string, required) - `message.order.terms.descriptor` (object, required) - `message.order.terms.reasonRequired` (boolean, required) - `message.order.terms.timePeriod` (string, required) - `message.order.terms.reason` (string, required) - `message.order.terms.termsState` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 4. Confirm `POST /teleconsulting/confirm` Confirms a teleconsultation booking. Beckn `confirm` action; the reply arrives at `on_confirm`. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/teleconsulting/confirm \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:011", "action": "confirm", "timestamp": "2024-06-24T09:18:51.128672Z", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu-sandbox.abdm.gov.in/aarogyasetu/api/v3/app/api/teleconsulting", "provider_id": "hspa-nha", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1", "transaction_id": "<TXN_ID>", "message_id": "<TXN_ID>" }, "message": { "order": { "id": "8673-410643-5926", "provider": { "id": "1" }, "item": { "id": "0", "descriptor": { "name": "<NAME>", "code": "CONSULTATION" }, "price": { "currency": "INR", "value": "0.0" }, "fulfillment_id": "<TXN_ID>" }, "fulfillment": { "id": "<TXN_ID>", "type": "Online", "agent": { "id": "<EMAIL>", "name": "<NAME>", "image": "/9j/4AAQSkZJRgABAgAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCADIAKADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCU8cZppp559KaV61TERnOaTJ9aeRzSbeaQCDPrQGoC0dPTFIBR1p4NZep61aaVAZJn3N0Cr1NcNqvi++vmZbd2t4SB8qHn8TQkB6VLe29tgyzIgPdmwKjj8U6bbhX/ALQh5OMBwTXjUk8krF2ZmYnJLHJNNDN71XKGp79Z/EPQ48CXUE646GujsfFmg34j8nV7ItIcKjTKrk/7pOf0r5f3HnOaljl29x+dHKhH1uuGGQRz0INPAr5k0jxhrmjBVsdUmjjAwImO9APZWyB+Fet+E/ihY6uiW+rCOyvC2AwyIpPoT909sE+mCeglxYHoGMUpFJFLHOqvE6ujAEMpyCCMg/SpdlSBFtpcVLso2UAQFeKaARU5U56UmznmgDzDGO/NNxTzz60jHjn+daDImB9aaR61IR7UxgBUjEP41mavq9vpVsZJmO48Io6san1S/XTdOlumAIReBnqew/OvJtU1K51C6e4uJNx6AdgPQUIQ7U9Tk1G6a4nbn+FR0X2rP8704qNmZjnH40EY64NUA8Pk5qQBs5HFRRu2QAo49qmaQbjk8jjFAxC5yQevrUoQYyxH401FIJc4HpSEF2+bnjigLEwMajoc/WrCMNmFPP8AOqcYBwPTuanDbQpzxjGaYrHdeDPHd74buIoJy01iWw0ZOdoPcfzx/LJz7/pt7b6nYxXltIrxSDIZTkV8kxOZCc/UV0Xh7xLe6LdiazmZGH38fxD39fxocbiPp/bRsqroupJq+kW18gG2aMOMH1/r2/CtDFZ2EQlMdKTbU2KNtAHkWfwpCR/+umBuOv40m/8AKrKHGmM3r+dIX56/rUZk681IzkvHepGOyjsl+/IdzfQf/X/lXnsr5QAfjXV+Oj/xNEwCT5I5/E1yKo0hCjrVdAJItg4PX27VOLJpOUT86kgthGMsMmta3ZeBispTa2NYwvuYb2VwpOQce1CQ7DwpZu5PaulCIT0zmporaEvuK81Htmty/Y32Miz0qa55cfKOnatGPw8rZMkgX0x2rU3YwBhR6AVLGgJz+tZyqy6GsaUepgSeGwD+7kO33qtPosqLw2SOldccbearvHuz3pKrMHRicTskt5MNnNTW8jpMGXOf51f1a32yBscZ5qnG+WATHFdkJcyucc42dj6Q+FhY+BbRWBG15AATn+In+ZNdrxXF/CtNvgGybP3nkP8A4+R/Su0pPchCcUuKQ4pRikB4lu59KN3cio9+cn+tN3cVRQ8nI9Pem7qaWGCc0zcKQHG+PIG321wB8uChP6/41y1km4lscCu68ZW/n6GZB1idW+ueP61y3lRWsezOAo5NJvQqK1GYJPAq3bR56iq0V7b5wRx61pWtxaMRiVc+nSsJtnRBLuWooCQOOKnjjZelWbdUdRtYEH0qyYB2Fc0qh1qmuhSETE561MkbCrkVvu4Aq+lgNmSwqXUK9mjH8s45pGTA61ozQomf3ikj0NUGljZ9oYZqoybIkl3MnUo12EuCR6isCNAJTiu0eBZIyrruU9ciqmi+Hk1DxjY6V/yymkBbPBKAbmwfXAbFdtCfQ4q8LanvXgazax8E6RA+N32dZCAMY3fNz7810GajQKiKigBVGAB2FPFWcwopaQUUAeGE8Uh9/wCdO68U0jNUUNbB55pp4oOSe+PemnPUYxSGZ+uN/wASqXG08qDn03DP6Vw9wqyH5zxXe6igewmBGeM/lXGS2/mqyAcmok7FwVzNj+yg4WF5CPQkVetLOHUFP2WOZmVlUhUZsE5wMgdTg/kaZb20trMGUFWHGcZrV0pY9Ovftlv+7nwQGCqQM9cAg4rNyRootlWCZ9OuCsjFSDtIPFdJZ3qTgAMDXKaxm5mZy8kkjdWds8Z6VoaDE6j5ieKxqxTVzelJp2OpkLKgCsVHqK57U5isuDeS5P8AAuTWxL5vlgrWY1rcpeLcqfmBzgqKypNI2qpspWtzayP5ctzIrA42kc5/GtIWVjNjbM4PTJbvTrDTok1Fr5jtZm3tDtJjdvcbgevPWrV5C93ftezNunf7zBQoP4Ct5TXRnPGm+qFt7doFKby6dieorT8NTz2XjSxubeGGR3CwDzR03NgkHscHGeevQ1SjLhNpFa/hyF5vEmlpEhdhco5A/uqck/gMn8KinN8xc4R5bM9s+tKBRilA4rsPNFoopaYjw4rntikxUjDBI5pmPzqiyJ1z15pv4YHpTm46Uc0gKmo/8g+fA/gOa5CIgPk12N9n7BP6bGz+VcUrAGs6mxtSepqoiTrnFO+xrzg5plkw4GOataiZYtJuJ4Qd6L1HUepribd7HoKKtc567K/bDEuDt61uaNbkoTnk1j2FsgtBM3zO3zMTXW6HbCQoqsoB7npV1HaNiKUW5DzG0eQw4p5tt0YK4OfStS401/MKF0PbKsCD+NZtxbS2TDn5SexrjTOxplb7O2cfNViG1Tgux+laGmLHdN5bjk9zVq5s44QQKpyYuVXMiaNQuVFdZ8PLMS65NcsissEGFJ/hZjjI/AMPxrl5htGAciu4+GynOon+HEfbr96unDbnFi9InfUtJTwPau08wSnAZoxihaYHi99AYZTxVJmwK6/VNPEqEgZrkLqEwyEEEGqTKImb16e1N3H1NRs2M03f60AOuB5ttLGDjcpHr2rgXYh29jXe7xXF6nB9n1CRMYUnK/SoktC4PUtWE3OSK2hfpBD8xGDwQa5yzYAgE49KvPGPJPOWx3rjlC8jvjUajoR3N0mx4rZQiN1VVGP/AK1aWiie1si+49ehPSubjlmWYx+WMjuDW3aSXKqEdDsP+e1OcHaw6Tu7nQ+d9qhG6Rwp4JB5FSNLEtv5OWb0LHJrKhuhGuxRgZ6YqR7qR8KsKluxPasXTZu52Jra8a3uR1wK1Jb4zIOcmudhNw0uJ1Qem3Na0fCgDk1MopExqN7jySVNelfDuFV0S4lwdzz7ST3AUY/ma82YrjOOa9m0CxbTNDtLRxiREy4JBwx5IyOuCSPwrow8epx4qWljS705TTO9KDXWcJJkeoxThg/SoyAy4IBB9RThjjFMDjpArDBrn9WtLdlLFlB+tZF94luZiRGdgrFlu5ZSS8hOfWqsCC4CLKQpyM1Fn1phcetRTXMNtHvmlRF/2jjNA7k+T61ieI7XzbQXKcPF156rTbrxJbRIfs4MpHc5Arl9Q1C71BSzsfmYKFHRafL1Yc2uhYtbrJB6VfF2SRg9RzXOKzIqtnINWre9+ba351hKHVHRGobQj8x93Q+tbdvLsjVSCe3ArHtZQ6HB6VrQSbkGBtFc8nY66ba2L1vKqlgU5PGStSMygZA5PWooAHTqM05kCjLEVm3c0bfUdwx57U9Zdg5P0qjJeIG2LzUaXBnbaoO0dWzT5LmTqWO+8C6K+p6kNSuF/wBEtG+TnG+XqPwHB+uOvNepbq8j8M/EW30zT00+6tv3Vt+7WSEAHGT94Z65ySRycgkZNeg6P4n0nXEQ2N9DI7gkR7sPgdflPP6V2xhaOh59STlLU3Vb3p4NVw3pT1aqIJwaXdUQPIp+aAPnKe+t4CRLOinuuefyrOn8QWseREryt2/hH+P6VzZBNMK47Ct+QnmNWbxBdykhFSJe23k1mSTGaUySMXc9WPNMCEg9BSqCT1qkkhXGsgZGcnlT079KbaKrAZGQsyHHtmnSKuGU5yeQR2plrgyPGQCHXHtmpmrocXqQFP3YHbJFM+zMTgVoi1L2ZfB4kbt71JBEGwCK43Ox1qNyta3EtqcHOPRq149Sk8vaqJk991KlkSp24Yehp8enJn5o2X3FZucXuaKMlsOhvriMjgYz605r26uGEak49FGau29jAAAU3n3FaMUGB8qBR+VZupFbI0UJPdmVBp8r/NM20H+Edfxq95YjQKgAA7Crfl4FU7tySLeJsSuM5/uL3b/D1P41CqOTLcFFGMsrGF14wbidv0jH9KppKUldM8Vcl2h2RPlSKIAf8C5H/joWqKFRNuODxivUoO8LnmVfisdZZfEDxLYRJHHqUrxo2dsqrJuHoWYFsewI9q9C8LfFKz1NltdZRLO4J+WZM+U3PQ5yV7ckkcEkjpXiik45PNKpK4II49a0cEzO59Xg465qQHivnnQ/H+uaOkUEV15ltHwIZgHXGMAZ+8AOMAEDivRtI+KmmXbBb61mtCWI3qfNQDHU4AP4AGsnTaHc8A6ngUhDE+tBPHU/lTycjuc81uSM9qao+bPank89PzoUH+FRTAY2chux4P8A9eq7Axy8ZHOau9QwIGDwaiZN2QwwQMj3FJoDb06ZL228kqAwByAMULYMH6YrDt5ntpdyHBHH+f8AP9a63T9Qgu1CyMqSD14rgxFKS96J20KifuyFtYCvDCr6WwbkLUpg2dafH8tedKTO9JDFgYdjUoiNTqfeqVzcySStBagM68PI33I/r6n2/lSV2xtpFa/vPs7i3hXzbpx8qDsPVvQVl3MgsIjE7Ga5nOZcdWHp7DsPrVieW105pPKJnu5PvtnJJ9+w+grILMsrSyNvmfrjt9K7KFBz9DkrVeX1GyuYomV2BldjJIQOCx5qtEAFLEfMeBnt/nmkLGWTDYxnk+v+f8+pftJAweP4Qf516iSSsjzm76sAvHuaXBAFLgjjOfwpDnJwaoQDIP8A9bpU6SOhyCfwqvtJOeKepJzgnH6UAU93cc0gcnj+tNJXPfNOJx+FAAWPTI6UFj1x+VJkY+7n6U0MOfl5oAmDEEds0pIcbehHIb0qNW78gU4jcvGOOlADNuTzwR/n/P8A9enxs0bAhtpB4IP+f/1GgfOcbsEcZFKEOQuMjvj/AD9PypAb+iTz32p2loVllV5QHSIMzbQctgLk9Aa9K0vwBBrD3EsWpmFFnkjWJ4n3AKxHILg9u9eeeBZIbfxlYyzMVjxOhI7FoXA/U4/GvZTr58M+C11R40aa8kMkanO3fJuk5IHQDcffGMjOa468E5aI6adRqO5HJ8LdN8ooZS4zjLGXPT1WQe35Vjn4faYtxPpys8UKpGUcQTnYXLDPL4wCAefx9ao+Hvilqtz4qjtNTED29zMsIWFdoibdgMDnkZPOSeOQeMHv/Ek6RaBrN8Ig72lq0xAPJKAuMeh44OOKzdOxaqa6nzpJKscC+Vhc9SByeaoMWfOOB6/0/GrbRZRRySqAADj1zz+VV5isXBwW9B0H+RXopWRxuV2Qg/dRQMfzqXLdMg81FGQW3HipGcgbhnng0CHfePX60jHIx3PWhWJB4Ge5zTWYg8DmgBQSF6Z59acp565pnUf/AFqXkAfSgZR3Z745pRu3AEn1qPdgY459aercd+uKQD/mORk+tNUFuuf6Up9D/OhCd2cfgTQA8LT19wOexNNzkcrz6Uu5dvGaYhvIPNSBSeQ1JwRjH04oAKNyDg/hQFzuPhnbpceJpoJ4i6S2kiKw6q2VOfrgNXq154YXxP8AD/TrAzeRJHBFLDIckBgmOQMZBVmHtnOOK8y+Hwg+wa/NI+2SCBGjOOu5ZVI/UV7RoMKv4c048jdaxnr/ALIrlq/Fc1Wx5x4a+F97puvWt5ql9ayx2zLKsdsWYs4OQCWUYAPPv0rtdbVv+Eb8TqUA3204U5ycfZuv510iwxqo24A9a5fxZdJZeGddlfAX5oskAcvAFH15YD1qL3aGj58uJ2CqMljj1rPkJdsValcknJzntmq643HBGScV2mKHIML8uM/nQSCwycD6UrqoI4PvTFBbgH9OaAHkgKc8+4ppIJ4BqXcMDnI75qMHJPOaYARlgduRSkEHBGKAfYkelAIxnbjHSkBnJ8w+Y/nSrx0x6UUUkMfjP3uffNKpGf50UUAPGWH04pD2HGaKKYh6nB6+9SnkEkkg9s80UUDO78DWtufDmvXtzvxsjiUj1zn8sla9r8PGWPQbSG5jEUiRhAo7ADAoorjqfEzRbIuMrB8AmuK+J2oGDwRLbXKIVvpgkbxcjKyK6fiUQ/jRRSgveQ+jPBpctwQT/SmhfmBOPxFFFdpiNfcRnPTgClQHbn27UUUwEycYwRRgryBxRRSAcNxGC3HvSHOMY/H1oopgf//Z", "gender": "M", "tags": { "@abdm/gov.in/experience": "5.0", "@abdm/gov.in/languages": "Eng, Hin", "@abdm/gov.in/education": "MBBS", "@abdm/gov.in/hpr_id": "<ABHA_NUMBER>" } }, "start": { "time": { "timestamp": "2024-06-24T16:00:00" } }, "end": { "time": { "timestamp": "2024-06-24T16:15:00" } }, "tags": { "@abdm/gov.in/slot_id": "<TXN_ID>" } }, "terms": [ { "type": "Commercial", "descriptor": { "name": "<NAME>", "short_desc": "Short description of commercial terms", "long_desc": "Long descripiton of commercial terms" }, "reasonRequired": false, "timePeriod": "2024-11-12T09:00:00", "reason": "", "termsState": "AGREED" }, { "type": "Settlement", "descriptor": { "name": "<NAME>", "short_desc": "Short description of settlement terms", "long_desc": "Long descripiton of settlement terms" }, "reasonRequired": false, "timePeriod": "2024-11-12T09:00:00", "reason": "", "termsState": "AGREED" }, { "type": "Cancellation", "descriptor": { "name": "<NAME>", "short_desc": "Short description of cancellation terms", "long_desc": "Long descripiton of cancellation terms" }, "reasonRequired": false, "timePeriod": "2024-11-12T09:00:00", "reason": "", "termsState": "AGREED" }, { "type": "Refund", "descriptor": { "name": "<NAME>", "short_desc": "Short description of refund terms", "long_desc": "Long descripiton of refund terms" }, "reasonRequired": false, "timePeriod": "2024-11-12T09:00:00", "reason": "", "termsState": "AGREED" }, { "type": "Payment", "descriptor": { "name": "<NAME>", "short_desc": "Short description of payment terms", "long_desc": "Long descripiton of payment terms" }, "reasonRequired": false, "timePeriod": "2024-11-12T09:00:00", "reason": "", "termsState": "AGREED" } ], "billing": { "name": "<NAME>", "address": { "door": "", "name": "<NAME>", "locality": "13-6-454/36/1, Hiranagar, Gudimalkapur, Asifnagar, Hyderabad, Andhra Pradesh", "state": "Telangana", "country": "INDIA", "area_code": "500067" }, "email": "<EMAIL>", "phone": "<MOBILE>" }, "quote": { "price": { "currency": "INR", "value": "0.0" }, "breakup": [ { "title": "Consultation", "price": { "currency": "INR", "value": "0.0" } }, { "title": "SGST @ 5%", "price": { "currency": "INR", "value": "0" } }, { "title": "CGST @ 5%", "price": { "currency": "INR", "value": "0" } }, { "title": "Registration", "price": { "currency": "INR", "value": "0" } } ] }, "customer": { "id": "<REDACTED_ID>@sbx", "person": { "gender": "M", "dob": "<DATE_OF_BIRTH>", "dayOfBirth": 20, "monthOfBirth": 12, "yearOfBirth": 2000 } }, "payment": { "status": "NOT_PAID", "type": "PRE-ORDER", "params": { "transaction_id": "", "amount": "1000", "mode": "", "vpa": "", "redirect_url": "https://uhieuasandbox.abdm.gov.in/on_paymentStatus" } } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.timestamp` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.provider_id` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `context.message_id` (string, required) - `message` (object, required) - `message.order` (object, required) - `message.order.id` (string, required) - `message.order.provider` (object, required) - `message.order.provider.id` (string, required) - `message.order.item` (object, required) - `message.order.item.id` (string, required) - `message.order.item.descriptor` (object, required) - `message.order.item.price` (object, required) - `message.order.item.fulfillment_id` (string, required) - `message.order.fulfillment` (object, required) - `message.order.fulfillment.id` (string, required) - `message.order.fulfillment.type` (string, required) - `message.order.fulfillment.agent` (object, required) - `message.order.fulfillment.start` (object, required) - `message.order.fulfillment.end` (object, required) - `message.order.fulfillment.tags` (object, required) - `message.order.terms` (object[], required) - `message.order.terms.type` (string, required) - `message.order.terms.descriptor` (object, required) - `message.order.terms.reasonRequired` (boolean, required) - `message.order.terms.timePeriod` (string, required) - `message.order.terms.reason` (string, required) - `message.order.terms.termsState` (string, required) - `message.order.billing` (object, required) - `message.order.billing.name` (string, required) - `message.order.billing.address` (object, required) - `message.order.billing.email` (string, required) - `message.order.billing.phone` (string, required) - `message.order.quote` (object, required) - `message.order.quote.price` (object, required) - `message.order.quote.breakup` (object[], required) - `message.order.customer` (object, required) - `message.order.customer.id` (string, required) - `message.order.customer.person` (object, required) - `message.order.payment` (object, required) - `message.order.payment.status` (string, required) - `message.order.payment.type` (string, required) - `message.order.payment.params` (object, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": { "ack": { "status": "ACK" } } } ``` --- # 4.on_confirm `POST /teleconsulting/on_confirm` Callback carrying the provider's confirmation of a teleconsultation booking, with the order details. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/teleconsulting/on_confirm \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:011", "action": "on_confirm", "timestamp": "2025-10-13T07:28:07.743822Z", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu-sandbox.abdm.gov.in/aarogyasetu/api/v3/app/api/teleconsulting", "provider_id": "hspa-nha", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1", "transaction_id": "<TXN_ID>", "message_id": "<TXN_ID>" }, "message": { "order": { "id": "4110-329065-7626", "provider": { "id": "1" }, "state": "CONFIRMED", "item": { "id": "0", "descriptor": { "name": "<NAME>", "code": "CONSULTATION", "flag": false }, "price": { "currency": "INR", "value": "0.0" }, "fulfillment_id": "<TXN_ID>" }, "fulfillment": { "id": "<TXN_ID>", "type": "Online", "agent": { "id": "<EMAIL>", "name": "<NAME>", "image": "/9j/4AAQSkZJRgABAgAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCADIAKADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCU8cZppp559KaV61TERnOaTJ9aeRzSbeaQCDPrQGoC0dPTFIBR1p4NZep61aaVAZJn3N0Cr1NcNqvi++vmZbd2t4SB8qHn8TQkB6VLe29tgyzIgPdmwKjj8U6bbhX/ALQh5OMBwTXjUk8krF2ZmYnJLHJNNDN71XKGp79Z/EPQ48CXUE646GujsfFmg34j8nV7ItIcKjTKrk/7pOf0r5f3HnOaljl29x+dHKhH1uuGGQRz0INPAr5k0jxhrmjBVsdUmjjAwImO9APZWyB+Fet+E/ihY6uiW+rCOyvC2AwyIpPoT909sE+mCeglxYHoGMUpFJFLHOqvE6ujAEMpyCCMg/SpdlSBFtpcVLso2UAQFeKaARU5U56UmznmgDzDGO/NNxTzz60jHjn+daDImB9aaR61IR7UxgBUjEP41mavq9vpVsZJmO48Io6san1S/XTdOlumAIReBnqew/OvJtU1K51C6e4uJNx6AdgPQUIQ7U9Tk1G6a4nbn+FR0X2rP8704qNmZjnH40EY64NUA8Pk5qQBs5HFRRu2QAo49qmaQbjk8jjFAxC5yQevrUoQYyxH401FIJc4HpSEF2+bnjigLEwMajoc/WrCMNmFPP8AOqcYBwPTuanDbQpzxjGaYrHdeDPHd74buIoJy01iWw0ZOdoPcfzx/LJz7/pt7b6nYxXltIrxSDIZTkV8kxOZCc/UV0Xh7xLe6LdiazmZGH38fxD39fxocbiPp/bRsqroupJq+kW18gG2aMOMH1/r2/CtDFZ2EQlMdKTbU2KNtAHkWfwpCR/+umBuOv40m/8AKrKHGmM3r+dIX56/rUZk681IzkvHepGOyjsl+/IdzfQf/X/lXnsr5QAfjXV+Oj/xNEwCT5I5/E1yKo0hCjrVdAJItg4PX27VOLJpOUT86kgthGMsMmta3ZeBispTa2NYwvuYb2VwpOQce1CQ7DwpZu5PaulCIT0zmporaEvuK81Htmty/Y32Miz0qa55cfKOnatGPw8rZMkgX0x2rU3YwBhR6AVLGgJz+tZyqy6GsaUepgSeGwD+7kO33qtPosqLw2SOldccbearvHuz3pKrMHRicTskt5MNnNTW8jpMGXOf51f1a32yBscZ5qnG+WATHFdkJcyucc42dj6Q+FhY+BbRWBG15AATn+In+ZNdrxXF/CtNvgGybP3nkP8A4+R/Su0pPchCcUuKQ4pRikB4lu59KN3cio9+cn+tN3cVRQ8nI9Pem7qaWGCc0zcKQHG+PIG321wB8uChP6/41y1km4lscCu68ZW/n6GZB1idW+ueP61y3lRWsezOAo5NJvQqK1GYJPAq3bR56iq0V7b5wRx61pWtxaMRiVc+nSsJtnRBLuWooCQOOKnjjZelWbdUdRtYEH0qyYB2Fc0qh1qmuhSETE561MkbCrkVvu4Aq+lgNmSwqXUK9mjH8s45pGTA61ozQomf3ikj0NUGljZ9oYZqoybIkl3MnUo12EuCR6isCNAJTiu0eBZIyrruU9ciqmi+Hk1DxjY6V/yymkBbPBKAbmwfXAbFdtCfQ4q8LanvXgazax8E6RA+N32dZCAMY3fNz7810GajQKiKigBVGAB2FPFWcwopaQUUAeGE8Uh9/wCdO68U0jNUUNbB55pp4oOSe+PemnPUYxSGZ+uN/wASqXG08qDn03DP6Vw9wqyH5zxXe6igewmBGeM/lXGS2/mqyAcmok7FwVzNj+yg4WF5CPQkVetLOHUFP2WOZmVlUhUZsE5wMgdTg/kaZb20trMGUFWHGcZrV0pY9Ovftlv+7nwQGCqQM9cAg4rNyRootlWCZ9OuCsjFSDtIPFdJZ3qTgAMDXKaxm5mZy8kkjdWds8Z6VoaDE6j5ieKxqxTVzelJp2OpkLKgCsVHqK57U5isuDeS5P8AAuTWxL5vlgrWY1rcpeLcqfmBzgqKypNI2qpspWtzayP5ctzIrA42kc5/GtIWVjNjbM4PTJbvTrDTok1Fr5jtZm3tDtJjdvcbgevPWrV5C93ftezNunf7zBQoP4Ct5TXRnPGm+qFt7doFKby6dieorT8NTz2XjSxubeGGR3CwDzR03NgkHscHGeevQ1SjLhNpFa/hyF5vEmlpEhdhco5A/uqck/gMn8KinN8xc4R5bM9s+tKBRilA4rsPNFoopaYjw4rntikxUjDBI5pmPzqiyJ1z15pv4YHpTm46Uc0gKmo/8g+fA/gOa5CIgPk12N9n7BP6bGz+VcUrAGs6mxtSepqoiTrnFO+xrzg5plkw4GOataiZYtJuJ4Qd6L1HUepribd7HoKKtc567K/bDEuDt61uaNbkoTnk1j2FsgtBM3zO3zMTXW6HbCQoqsoB7npV1HaNiKUW5DzG0eQw4p5tt0YK4OfStS401/MKF0PbKsCD+NZtxbS2TDn5SexrjTOxplb7O2cfNViG1Tgux+laGmLHdN5bjk9zVq5s44QQKpyYuVXMiaNQuVFdZ8PLMS65NcsissEGFJ/hZjjI/AMPxrl5htGAciu4+GynOon+HEfbr96unDbnFi9InfUtJTwPau08wSnAZoxihaYHi99AYZTxVJmwK6/VNPEqEgZrkLqEwyEEEGqTKImb16e1N3H1NRs2M03f60AOuB5ttLGDjcpHr2rgXYh29jXe7xXF6nB9n1CRMYUnK/SoktC4PUtWE3OSK2hfpBD8xGDwQa5yzYAgE49KvPGPJPOWx3rjlC8jvjUajoR3N0mx4rZQiN1VVGP/AK1aWiie1si+49ehPSubjlmWYx+WMjuDW3aSXKqEdDsP+e1OcHaw6Tu7nQ+d9qhG6Rwp4JB5FSNLEtv5OWb0LHJrKhuhGuxRgZ6YqR7qR8KsKluxPasXTZu52Jra8a3uR1wK1Jb4zIOcmudhNw0uJ1Qem3Na0fCgDk1MopExqN7jySVNelfDuFV0S4lwdzz7ST3AUY/ma82YrjOOa9m0CxbTNDtLRxiREy4JBwx5IyOuCSPwrow8epx4qWljS705TTO9KDXWcJJkeoxThg/SoyAy4IBB9RThjjFMDjpArDBrn9WtLdlLFlB+tZF94luZiRGdgrFlu5ZSS8hOfWqsCC4CLKQpyM1Fn1phcetRTXMNtHvmlRF/2jjNA7k+T61ieI7XzbQXKcPF156rTbrxJbRIfs4MpHc5Arl9Q1C71BSzsfmYKFHRafL1Yc2uhYtbrJB6VfF2SRg9RzXOKzIqtnINWre9+ba351hKHVHRGobQj8x93Q+tbdvLsjVSCe3ArHtZQ6HB6VrQSbkGBtFc8nY66ba2L1vKqlgU5PGStSMygZA5PWooAHTqM05kCjLEVm3c0bfUdwx57U9Zdg5P0qjJeIG2LzUaXBnbaoO0dWzT5LmTqWO+8C6K+p6kNSuF/wBEtG+TnG+XqPwHB+uOvNepbq8j8M/EW30zT00+6tv3Vt+7WSEAHGT94Z65ySRycgkZNeg6P4n0nXEQ2N9DI7gkR7sPgdflPP6V2xhaOh59STlLU3Vb3p4NVw3pT1aqIJwaXdUQPIp+aAPnKe+t4CRLOinuuefyrOn8QWseREryt2/hH+P6VzZBNMK47Ct+QnmNWbxBdykhFSJe23k1mSTGaUySMXc9WPNMCEg9BSqCT1qkkhXGsgZGcnlT079KbaKrAZGQsyHHtmnSKuGU5yeQR2plrgyPGQCHXHtmpmrocXqQFP3YHbJFM+zMTgVoi1L2ZfB4kbt71JBEGwCK43Ox1qNyta3EtqcHOPRq149Sk8vaqJk991KlkSp24Yehp8enJn5o2X3FZucXuaKMlsOhvriMjgYz605r26uGEak49FGau29jAAAU3n3FaMUGB8qBR+VZupFbI0UJPdmVBp8r/NM20H+Edfxq95YjQKgAA7Crfl4FU7tySLeJsSuM5/uL3b/D1P41CqOTLcFFGMsrGF14wbidv0jH9KppKUldM8Vcl2h2RPlSKIAf8C5H/joWqKFRNuODxivUoO8LnmVfisdZZfEDxLYRJHHqUrxo2dsqrJuHoWYFsewI9q9C8LfFKz1NltdZRLO4J+WZM+U3PQ5yV7ckkcEkjpXiik45PNKpK4II49a0cEzO59Xg465qQHivnnQ/H+uaOkUEV15ltHwIZgHXGMAZ+8AOMAEDivRtI+KmmXbBb61mtCWI3qfNQDHU4AP4AGsnTaHc8A6ngUhDE+tBPHU/lTycjuc81uSM9qao+bPank89PzoUH+FRTAY2chux4P8A9eq7Axy8ZHOau9QwIGDwaiZN2QwwQMj3FJoDb06ZL228kqAwByAMULYMH6YrDt5ntpdyHBHH+f8AP9a63T9Qgu1CyMqSD14rgxFKS96J20KifuyFtYCvDCr6WwbkLUpg2dafH8tedKTO9JDFgYdjUoiNTqfeqVzcySStBagM68PI33I/r6n2/lSV2xtpFa/vPs7i3hXzbpx8qDsPVvQVl3MgsIjE7Ga5nOZcdWHp7DsPrVieW105pPKJnu5PvtnJJ9+w+grILMsrSyNvmfrjt9K7KFBz9DkrVeX1GyuYomV2BldjJIQOCx5qtEAFLEfMeBnt/nmkLGWTDYxnk+v+f8+pftJAweP4Qf516iSSsjzm76sAvHuaXBAFLgjjOfwpDnJwaoQDIP8A9bpU6SOhyCfwqvtJOeKepJzgnH6UAU93cc0gcnj+tNJXPfNOJx+FAAWPTI6UFj1x+VJkY+7n6U0MOfl5oAmDEEds0pIcbehHIb0qNW78gU4jcvGOOlADNuTzwR/n/P8A9enxs0bAhtpB4IP+f/1GgfOcbsEcZFKEOQuMjvj/AD9PypAb+iTz32p2loVllV5QHSIMzbQctgLk9Aa9K0vwBBrD3EsWpmFFnkjWJ4n3AKxHILg9u9eeeBZIbfxlYyzMVjxOhI7FoXA/U4/GvZTr58M+C11R40aa8kMkanO3fJuk5IHQDcffGMjOa468E5aI6adRqO5HJ8LdN8ooZS4zjLGXPT1WQe35Vjn4faYtxPpys8UKpGUcQTnYXLDPL4wCAefx9ao+Hvilqtz4qjtNTED29zMsIWFdoibdgMDnkZPOSeOQeMHv/Ek6RaBrN8Ig72lq0xAPJKAuMeh44OOKzdOxaqa6nzpJKscC+Vhc9SByeaoMWfOOB6/0/GrbRZRRySqAADj1zz+VV5isXBwW9B0H+RXopWRxuV2Qg/dRQMfzqXLdMg81FGQW3HipGcgbhnng0CHfePX60jHIx3PWhWJB4Ge5zTWYg8DmgBQSF6Z59acp565pnUf/AFqXkAfSgZR3Z745pRu3AEn1qPdgY459aercd+uKQD/mORk+tNUFuuf6Up9D/OhCd2cfgTQA8LT19wOexNNzkcrz6Uu5dvGaYhvIPNSBSeQ1JwRjH04oAKNyDg/hQFzuPhnbpceJpoJ4i6S2kiKw6q2VOfrgNXq154YXxP8AD/TrAzeRJHBFLDIckBgmOQMZBVmHtnOOK8y+Hwg+wa/NI+2SCBGjOOu5ZVI/UV7RoMKv4c048jdaxnr/ALIrlq/Fc1Wx5x4a+F97puvWt5ql9ayx2zLKsdsWYs4OQCWUYAPPv0rtdbVv+Eb8TqUA3204U5ycfZuv510iwxqo24A9a5fxZdJZeGddlfAX5oskAcvAFH15YD1qL3aGj58uJ2CqMljj1rPkJdsValcknJzntmq643HBGScV2mKHIML8uM/nQSCwycD6UrqoI4PvTFBbgH9OaAHkgKc8+4ppIJ4BqXcMDnI75qMHJPOaYARlgduRSkEHBGKAfYkelAIxnbjHSkBnJ8w+Y/nSrx0x6UUUkMfjP3uffNKpGf50UUAPGWH04pD2HGaKKYh6nB6+9SnkEkkg9s80UUDO78DWtufDmvXtzvxsjiUj1zn8sla9r8PGWPQbSG5jEUiRhAo7ADAoorjqfEzRbIuMrB8AmuK+J2oGDwRLbXKIVvpgkbxcjKyK6fiUQ/jRRSgveQ+jPBpctwQT/SmhfmBOPxFFFdpiNfcRnPTgClQHbn27UUUwEycYwRRgryBxRRSAcNxGC3HvSHOMY/H1oopgf//Z", "gender": "M", "tags": { "@abdm/gov.in/experience": "5.0", "@abdm/gov.in/languages": "English, Hindi", "@abdm/gov.in/education": "MBBS", "@abdm/gov.in/hpr_id": "<ABHA_NUMBER>" } }, "start": { "time": { "timestamp": "2025-10-14T12:00:00" } }, "end": { "time": { "timestamp": "2025-10-14T12:15:00" } }, "tags": { "@abdm/gov.in/slot_id": "<TXN_ID>", "@abdm/gov.in/doctors_key": "<@ABDM/GOV.IN/DOCTORS_KEY>", "@abdm/gov.in/teleconsultation/uri": "https://link.aieze.in/WPTGWX" } }, "billing": { "name": "<NAME>", "address": { "name": "<NAME>", "locality": "54, SUBASH CHANDRA BOSS STREET, G N T ROAD WEST GUMMIDIPOONDI, Gummidipoondi, Gummidipoondi, Tiruvallur, Tamil Nadu", "city": "THIRUVALLUR", "state": "TAMIL NADU", "country": "INDIA", "area_code": "601201" }, "phone": "<MOBILE>" }, "quote": { "price": { "currency": "INR", "value": "0.0" }, "breakup": [ { "title": "Consultation", "price": { "currency": "INR", "value": "0.0" } }, { "title": "CGST @ 5%", "price": { "currency": "INR", "value": "0.0" } }, { "title": "SGST @ 5%", "price": { "currency": "INR", "value": "0.0" } }, { "title": "Registration", "price": { "currency": "INR", "value": "0" } } ] }, "customer": { "id": "nithishjanithi@sbx", "person": { "gender": "M", "dayOfBirth": 14, "monthOfBirth": 10, "yearOfBirth": 1999, "dob": "<DATE_OF_BIRTH>" } }, "payment": { "uri": "", "type": "ON-ORDER", "status": "FREE", "params": { "transaction_id": "", "amount": "0.0", "mode": "", "vpa": "", "redirect_url": "" } }, "terms": [ { "type": "Commercial", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of commercial terms", "long_desc": "Long description of commercial terms" }, "reasonRequired": false, "timePeriod": "2025-10-14T12:00:00", "reason": "", "termsState": "AGREED" }, { "type": "Settlement", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of Settlement terms", "long_desc": "Long description of Settlement terms" }, "reasonRequired": false, "timePeriod": "2025-10-14T12:00:00", "reason": "", "termsState": "AGREED" }, { "type": "Cancellation", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of Cancellation terms", "long_desc": "Cancellation: Full refund if cancelled 48 hrs before consultation time. n Rescheduling: No charges for rescheduling 48 hrs prior to consultation time" }, "reasonRequired": false, "timePeriod": "2025-10-14T12:00:00", "reason": "", "termsState": "AGREED" }, { "type": "Refund", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of Refund terms", "long_desc": "No Show: If doctor does not show up - full refund. No refund if patient does not turn up for appointment" }, "reasonRequired": false, "timePeriod": "2025-10-14T12:00:00", "reason": "", "termsState": "AGREED" }, { "type": "Payment", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of Payment terms", "long_desc": "Long description of Payment terms" }, "reasonRequired": false, "timePeriod": "2025-10-14T12:00:00", "reason": "", "termsState": "AGREED" } ] } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.timestamp` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.provider_id` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `context.message_id` (string, required) - `message` (object, required) - `message.order` (object, required) - `message.order.id` (string, required) - `message.order.provider` (object, required) - `message.order.provider.id` (string, required) - `message.order.state` (string, required) - `message.order.item` (object, required) - `message.order.item.id` (string, required) - `message.order.item.descriptor` (object, required) - `message.order.item.price` (object, required) - `message.order.item.fulfillment_id` (string, required) - `message.order.fulfillment` (object, required) - `message.order.fulfillment.id` (string, required) - `message.order.fulfillment.type` (string, required) - `message.order.fulfillment.agent` (object, required) - `message.order.fulfillment.start` (object, required) - `message.order.fulfillment.end` (object, required) - `message.order.fulfillment.tags` (object, required) - `message.order.billing` (object, required) - `message.order.billing.name` (string, required) - `message.order.billing.address` (object, required) - `message.order.billing.phone` (string, required) - `message.order.quote` (object, required) - `message.order.quote.price` (object, required) - `message.order.quote.breakup` (object[], required) - `message.order.customer` (object, required) - `message.order.customer.id` (string, required) - `message.order.customer.person` (object, required) - `message.order.payment` (object, required) - `message.order.payment.uri` (string, required) - `message.order.payment.type` (string, required) - `message.order.payment.status` (string, required) - `message.order.payment.params` (object, required) - `message.order.terms` (object[], required) - `message.order.terms.type` (string, required) - `message.order.terms.descriptor` (object, required) - `message.order.terms.reasonRequired` (boolean, required) - `message.order.terms.timePeriod` (string, required) - `message.order.terms.reason` (string, required) - `message.order.terms.termsState` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 5.On status `POST /teleconsulting/on_status` Callback carrying the current status of a teleconsultation order. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/teleconsulting/on_status \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:011", "action": "on_status", "timestamp": "2025-01-23T08:31:13.622657Z", "core_version": "0.7.1", "consumer_id": "eua-nha", "consumer_uri": "https://uhieuasandbox.abdm.gov.in/api/v1/euaService", "provider_id": "hspa-nha", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1", "transaction_id": "<TXN_ID>", "message_id": "<TXN_ID>" }, "message": { "order": { "id": "<TXN_ID>", "state": "CONFIRMED", "terms": [ { "type": "Cancellation", "descriptor": { "name": "<NAME>", "short_desc": "Short description of cancellation terms", "long_desc": "Cancellation: Full refund if cancelled 48 hrs before consultation time. \n Rescheduling: No charges for rescheduling 48 hrs prior to consultation time." }, "reasonRequired": false, "timePeriod": "2025-01-21T10:37:29.147Z", "reason": "", "termsState": "AGREED" }, { "type": "Refund", "descriptor": { "name": "<NAME>", "short_desc": "Short description of refund terms", "long_desc": "No Show: If doctor does not show up - full refund. No refund if patient does not turn up for appointment" }, "reasonRequired": false, "timePeriod": "2025-01-21T10:37:29.147Z", "reason": "", "termsState": "AGREED" }, { "type": "Payment", "descriptor": { "name": "<NAME>", "short_desc": "Short description of paymet terms", "long_desc": "Long description of payment terms" }, "reasonRequired": false, "timePeriod": "2025-01-21T10:37:29.147Z", "reason": "", "termsState": "AGREED" } ], "item": { "id": "1", "descriptor": { "code": "Consultation", "name": "<NAME>" }, "price": { "currency": "INR", "value": "400" }, "fulfillment_id": "<TXN_ID>" }, "fulfillment": { "id": "<TXN_ID>", "type": "Online", "agent": { "id": "6733141611297598", "name": "<NAME>", "gender": "M", "image": "https://doctorlistingingestionpr.blob.core.windows.net/doctorprofilepic/doctor_male_1.png", "tags": { "@abdm/gov/in/education": "MBBS", "@abdm/gov/in/experience": "null", "@abdm/gov/in/languages": "English,Hindi", "@abdm/gov/in/hpr_id": "<EMAIL>" } }, "start": { "time": { "timestamp": "2025-01-21T21:30:00" } }, "end": { "time": { "timestamp": "2025-01-21T21:45:00" } }, "tags": { "@abdm/gov.in/slot_id": "<TXN_ID>", "@abdm/gov.in/teleconsultation/uri": "https://t.bfhl.me/aXdvTS" } }, "billing": { "name": "<NAME>", "address": { "area_code": "", "city": "", "country": "INDIA", "door": "", "locality": "", "state": "", "name": "<NAME>" }, "phone": "<MOBILE>" }, "quote": { "price": { "currency": "INR", "value": "400" }, "breakup": [ { "title": "Consultation", "price": { "currency": "INR", "value": "400" } }, { "price": { "currency": "INR", "value": "0" }, "title": "SGST @ 5%" }, { "price": { "currency": "INR", "value": "0" }, "title": "CGST @ 5%" }, { "price": { "currency": "INR", "value": "0" }, "title": "Registration" } ] }, "customer": { "person": { "gender": "F", "dob": "<DATE_OF_BIRTH>", "dayOfBirth": 13, "monthOfBirth": 11, "yearOfBirth": 1995 }, "id": "tashu_1995@sbx" }, "payment": { "uri": "https://rzp.io/rzp/37aBZqYa", "type": "ON-ORDER", "status": "PAID", "tl_method": "http/get", "params": { "transaction_id": "", "redirect_url": "https://uhieuasandbox.abdm.gov.in/on_paymentStatus", "amount": "400" } }, "provider": { "id": "6733141613873079" } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.timestamp` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.provider_id` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `context.message_id` (string, required) - `message` (object, required) - `message.order` (object, required) - `message.order.id` (string, required) - `message.order.state` (string, required) - `message.order.terms` (object[], required) - `message.order.terms.type` (string, required) - `message.order.terms.descriptor` (object, required) - `message.order.terms.reasonRequired` (boolean, required) - `message.order.terms.timePeriod` (string, required) - `message.order.terms.reason` (string, required) - `message.order.terms.termsState` (string, required) - `message.order.item` (object, required) - `message.order.item.id` (string, required) - `message.order.item.descriptor` (object, required) - `message.order.item.price` (object, required) - `message.order.item.fulfillment_id` (string, required) - `message.order.fulfillment` (object, required) - `message.order.fulfillment.id` (string, required) - `message.order.fulfillment.type` (string, required) - `message.order.fulfillment.agent` (object, required) - `message.order.fulfillment.start` (object, required) - `message.order.fulfillment.end` (object, required) - `message.order.fulfillment.tags` (object, required) - `message.order.billing` (object, required) - `message.order.billing.name` (string, required) - `message.order.billing.address` (object, required) - `message.order.billing.phone` (string, required) - `message.order.quote` (object, required) - `message.order.quote.price` (object, required) - `message.order.quote.breakup` (object[], required) - `message.order.customer` (object, required) - `message.order.customer.person` (object, required) - `message.order.customer.id` (string, required) - `message.order.payment` (object, required) - `message.order.payment.uri` (string, required) - `message.order.payment.type` (string, required) - `message.order.payment.status` (string, required) - `message.order.payment.tl_method` (string, required) - `message.order.payment.params` (object, required) - `message.order.provider` (object, required) - `message.order.provider.id` (string, required) ## Responses - `200`: No response body is documented for this request. --- # 5. Status `POST /teleconsulting/status` Asks for the current status of a teleconsultation order. Beckn `status` action; the reply arrives at `on_status`. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/teleconsulting/status \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:011", "action": "status", "core_version": "0.7.1", "consumer_id": "phr.euapid.bb", "consumer_uri": "https://d2xk0g5obixbh6.cloudfront.net/aarogyasetu/api/v3/app/api/teleconsulting", "message_id": "<TXN_ID>", "timestamp": "2022-07-05T15:24:35", "provider_id": "hspa-nha", "provider_uri": "http://hspasbx.abdm.gov.in/api/v1", "transaction_id": "<TXN_ID>" }, "message": { "order": { "id": "8441-696786-1042" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.message_id` (string, required) - `context.timestamp` (string, required) - `context.provider_id` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `message` (object, required) - `message.order` (object, required) - `message.order.id` (string, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": { "ack": { "status": "ACK" } } } ``` --- # 6.on_cancel `POST /teleconsulting/on_cancel` Callback carrying the provider's reply to a teleconsultation cancellation. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/teleconsulting/on_cancel \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:011", "action": "on_cancel", "timestamp": "2025-10-17T06:11:24.068345Z", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu-sandbox.abdm.gov.in/aarogyasetu/api/v3/app/api/teleconsulting", "provider_id": "hspa-nha", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1", "transaction_id": "<TXN_ID>", "message_id": "<TXN_ID>" }, "message": { "order": { "id": "1128-796387-3415", "state": "CANCELLED", "fulfillment": { "tags": { "@abdm/gov.in/cancelledby": "doctor", "@abdm/gov.in/teleconsultation/uri": "false" } } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.timestamp` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.provider_id` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `context.message_id` (string, required) - `message` (object, required) - `message.order` (object, required) - `message.order.id` (string, required) - `message.order.state` (string, required) - `message.order.fulfillment` (object, required) - `message.order.fulfillment.tags` (object, required) ## Responses - `200`: No response body is documented for this request. --- # 6. On_update `POST /teleconsulting/update` Updates a teleconsultation order, for example to reschedule. Beckn `update` action; the reply arrives at `on_update`. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/teleconsulting/update \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:011", "action": "on_update", "core_version": "0.7.1", "consumer_id": "phr.euapid.bb", "consumer_uri": "https://d2xk0g5obixbh6.cloudfront.net/aarogyasetu/api/v3/app/api/teleconsulting", "message_id": "<TXN_ID>", "timestamp": "2022-07-05T15:24:35.481906", "provider_id": "hspa-nha", "provider_uri": "http://hspasbx.abdm.gov.in/api/v1", "transaction_id": "<TXN_ID>" }, "message": { "order": { "id": "8441-696786-1042", "state": "DOCTOR_NO_SHOW", "item": { "id": "1", "descriptor": { "code": "Consultation", "name": "<NAME>" } }, "fulfillment": { "id": "<TXN_ID>", "type": "Online", "agent": { "id": "<EMAIL>", "name": "<NAME>", "gender": "F", "tags": { "@abdm/gov.in/education": "MBBS,MS", "@abdm/gov.in/experience": "15.0", "@abdm/gov.in/languages": "English, Hindi, Marathi", "@abdm/gov.in/hpr_id": "<ABHA_NUMBER>,", "@abdm/gov.in/hfr_id": "<ABHA_NUMBER>" } }, "start": { "time": { "timestamp": "2022-09-15T15:00:00" } }, "end": { "time": { "timestamp": "2022-09-15T15:15:00" } }, "tags": { "@abdm/gov.in/teleconsultation/uri": "www.callmyhspa.com/tele" } }, "terms": [ { "type": "Commercial", "descriptor": { "name": "<NAME>", "short_desc": "Short description of commercial terms", "long_desc": "Long descripiton of commercial terms" }, "reasonRequired": false, "timePeriod": "2024-11-12T09:00:00", "reason": "", "termsState": "AGREED" }, { "type": "Settlement", "descriptor": { "name": "<NAME>", "short_desc": "Short description of settlement terms", "long_desc": "Long descripiton of settlement terms" }, "reasonRequired": false, "timePeriod": "2024-11-12T09:00:00", "reason": "", "termsState": "AGREED" }, { "type": "Cancellation", "descriptor": { "name": "<NAME>", "short_desc": "Short description of cancellation terms", "long_desc": "Long descripiton of cancellation terms" }, "reasonRequired": false, "timePeriod": "2024-11-12T09:00:00", "reason": "", "termsState": "AGREED" }, { "type": "Refund", "descriptor": { "name": "<NAME>", "short_desc": "Short description of refund terms", "long_desc": "Long descripiton of refund terms" }, "reasonRequired": false, "timePeriod": "2024-11-12T09:00:00", "reason": "", "termsState": "AGREED" }, { "type": "Payment", "descriptor": { "name": "<NAME>", "short_desc": "Short description of payment terms", "long_desc": "Long descripiton of payment terms" }, "reasonRequired": false, "timePeriod": "2024-11-12T09:00:00", "reason": "", "termsState": "AGREED" } ], "billing": { "name": "<NAME>", "address": { "door": "", "name": "<NAME>", "locality": "", "city": "Pune", "state": "Maharashtra", "country": "INDIA", "area_code": "412115" }, "email": "<EMAIL>", "phone": "<MOBILE>" }, "payment": { "uri": "https://api.bpp.com/pay?amt=1500&txn_id=ksh87yriuro34iyr3p4&mode=upi&vpa=sana.bhatt@upi", "type": "PRE-ORDER", "status": "PAID", "tl_method": "http/get", "params": { "transaction_id": "1", "amount": "1000", "mode": "UPI", "vpa": "xyz@ghh", "redirect_url": "https://uhieuasandbox.abdm.gov.in/on_paymentStatus? transaction_id=1&payment_status=success" } }, "quote": { "price": { "currency": "INR", "value": "1000" }, "breakup": [ { "title": "Consultation", "price": { "currency": "INR", "value": "1000" } }, { "title": "CGST @ 5%", "price": { "currency": "INR", "value": "0" } }, { "title": "SGST @ 5%", "price": { "currency": "INR", "value": "0" } }, { "title": "Registration", "price": { "currency": "INR", "value": "0" } } ] }, "customer": { "person": { "gender": "M", "dob": "<DATE_OF_BIRTH>", "dayOfBirth": 21, "monthOfBirth": 11, "yearOfBirth": 2022 }, "id": "satishc661994@sbx" }, "provider": { "id": "1" } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.message_id` (string, required) - `context.timestamp` (string, required) - `context.provider_id` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `message` (object, required) - `message.order` (object, required) - `message.order.id` (string, required) - `message.order.state` (string, required) - `message.order.item` (object, required) - `message.order.item.id` (string, required) - `message.order.item.descriptor` (object, required) - `message.order.fulfillment` (object, required) - `message.order.fulfillment.id` (string, required) - `message.order.fulfillment.type` (string, required) - `message.order.fulfillment.agent` (object, required) - `message.order.fulfillment.start` (object, required) - `message.order.fulfillment.end` (object, required) - `message.order.fulfillment.tags` (object, required) - `message.order.terms` (object[], required) - `message.order.terms.type` (string, required) - `message.order.terms.descriptor` (object, required) - `message.order.terms.reasonRequired` (boolean, required) - `message.order.terms.timePeriod` (string, required) - `message.order.terms.reason` (string, required) - `message.order.terms.termsState` (string, required) - `message.order.billing` (object, required) - `message.order.billing.name` (string, required) - `message.order.billing.address` (object, required) - `message.order.billing.email` (string, required) - `message.order.billing.phone` (string, required) - `message.order.payment` (object, required) - `message.order.payment.uri` (string, required) - `message.order.payment.type` (string, required) - `message.order.payment.status` (string, required) - `message.order.payment.tl_method` (string, required) - `message.order.payment.params` (object, required) - `message.order.quote` (object, required) - `message.order.quote.price` (object, required) - `message.order.quote.breakup` (object[], required) - `message.order.customer` (object, required) - `message.order.customer.person` (object, required) - `message.order.customer.id` (string, required) - `message.order.provider` (object, required) - `message.order.provider.id` (string, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": { "ack": { "status": "ACK" } } } ``` --- # 7 .On_message `POST /teleconsulting/message` Sends a message within a teleconsultation. Beckn `message` action. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/teleconsulting/message \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:011", "action": "on_message", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu-sandbox.abdm.gov.in/aarogyasetu/api/v3/app/api/teleconsulting", "message_id": "<TXN_ID>", "timestamp": "2022-07-05T15:24:35.481906Z", "provider_id": "hspa-nha", "provider_uri": "http://hspasbx.abdm.gov.in/api/v1", "transaction_id": "<TXN_ID>" }, "message": { "intent": { "chat": { "sender": { "person": { "name": "<NAME>", "gender": "M", "image": "image", "id": "santoshjagtap@sbx" } }, "receiver": { "person": { "name": "<NAME>", "gender": "M", "image": "image hashed base64", "id": "<EMAIL>" } }, "content": { "content_id": "<TXN_ID>", "content_value": "Base64 Encoded text", "content_type": "text" }, "time": { "timestamp": "2022-10-03T11:32:01" } } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.message_id` (string, required) - `context.timestamp` (string, required) - `context.provider_id` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `message` (object, required) - `message.intent` (object, required) - `message.intent.chat` (object, required) - `message.intent.chat.sender` (object, required) - `message.intent.chat.receiver` (object, required) - `message.intent.chat.content` (object, required) - `message.intent.chat.time` (object, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "message": { "ack": { "status": "ACK" } } } ``` --- # 7.on_update `POST /teleconsulting/on_update` Callback carrying the provider's reply to a teleconsultation update. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/teleconsulting/on_update \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:011", "action": "on_update", "timestamp": "2025-10-15T06:31:05.168137Z", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu-sandbox.abdm.gov.in/aarogyasetu/api/v3/app/api/teleconsulting", "provider_id": "hspa-nha", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1", "transaction_id": "<TXN_ID>", "message_id": "<TXN_ID>" }, "message": { "order": { "id": "1481-367013-4819", "provider": { "id": "1", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Expertise in every field with renowned staff.", "long_desc": "We are Test hospital. We have established a very profound name in the healthcare industry by providing expert services in every healthcare fields that we have." }, "categories": [ { "id": "201", "parent_category_id": "101", "descriptor": { "name": "<NAME>", "code": "CARDIOLOGY", "flag": false } }, { "id": "101", "parent_category_id": "", "descriptor": { "name": "<NAME>", "code": "ALLOPATHY", "flag": false } } ], "location": { "id": "1", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Expertise in every field with renowned staff.", "long_desc": "We are Test hospital. We have established a very profound name in the healthcare industry by providing expert services in every healthcare fields that we have." }, "city": { "name": "<NAME>", "code": "011" }, "country": { "name": "<NAME>", "code": "+91" }, "gps": "18.5246036,73.792927", "address": "<ADDRESS>" } }, "state": "COMPLETED", "item": { "id": "0", "descriptor": { "name": "<NAME>", "code": "CONSULTATION", "flag": false }, "price": { "currency": "INR", "value": "0.0" }, "fulfillment_id": "<TXN_ID>" }, "fulfillment": { "id": "<TXN_ID>", "type": "Physical", "agent": { "id": "<EMAIL>", "name": "<NAME>", "image": "/9j/4AAQSkZJRgABAgAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCADIAKADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCU8cZppp559KaV61TERnOaTJ9aeRzSbeaQCDPrQGoC0dPTFIBR1p4NZep61aaVAZJn3N0Cr1NcNqvi++vmZbd2t4SB8qHn8TQkB6VLe29tgyzIgPdmwKjj8U6bbhX/ALQh5OMBwTXjUk8krF2ZmYnJLHJNNDN71XKGp79Z/EPQ48CXUE646GujsfFmg34j8nV7ItIcKjTKrk/7pOf0r5f3HnOaljl29x+dHKhH1uuGGQRz0INPAr5k0jxhrmjBVsdUmjjAwImO9APZWyB+Fet+E/ihY6uiW+rCOyvC2AwyIpPoT909sE+mCeglxYHoGMUpFJFLHOqvE6ujAEMpyCCMg/SpdlSBFtpcVLso2UAQFeKaARU5U56UmznmgDzDGO/NNxTzz60jHjn+daDImB9aaR61IR7UxgBUjEP41mavq9vpVsZJmO48Io6san1S/XTdOlumAIReBnqew/OvJtU1K51C6e4uJNx6AdgPQUIQ7U9Tk1G6a4nbn+FR0X2rP8704qNmZjnH40EY64NUA8Pk5qQBs5HFRRu2QAo49qmaQbjk8jjFAxC5yQevrUoQYyxH401FIJc4HpSEF2+bnjigLEwMajoc/WrCMNmFPP8AOqcYBwPTuanDbQpzxjGaYrHdeDPHd74buIoJy01iWw0ZOdoPcfzx/LJz7/pt7b6nYxXltIrxSDIZTkV8kxOZCc/UV0Xh7xLe6LdiazmZGH38fxD39fxocbiPp/bRsqroupJq+kW18gG2aMOMH1/r2/CtDFZ2EQlMdKTbU2KNtAHkWfwpCR/+umBuOv40m/8AKrKHGmM3r+dIX56/rUZk681IzkvHepGOyjsl+/IdzfQf/X/lXnsr5QAfjXV+Oj/xNEwCT5I5/E1yKo0hCjrVdAJItg4PX27VOLJpOUT86kgthGMsMmta3ZeBispTa2NYwvuYb2VwpOQce1CQ7DwpZu5PaulCIT0zmporaEvuK81Htmty/Y32Miz0qa55cfKOnatGPw8rZMkgX0x2rU3YwBhR6AVLGgJz+tZyqy6GsaUepgSeGwD+7kO33qtPosqLw2SOldccbearvHuz3pKrMHRicTskt5MNnNTW8jpMGXOf51f1a32yBscZ5qnG+WATHFdkJcyucc42dj6Q+FhY+BbRWBG15AATn+In+ZNdrxXF/CtNvgGybP3nkP8A4+R/Su0pPchCcUuKQ4pRikB4lu59KN3cio9+cn+tN3cVRQ8nI9Pem7qaWGCc0zcKQHG+PIG321wB8uChP6/41y1km4lscCu68ZW/n6GZB1idW+ueP61y3lRWsezOAo5NJvQqK1GYJPAq3bR56iq0V7b5wRx61pWtxaMRiVc+nSsJtnRBLuWooCQOOKnjjZelWbdUdRtYEH0qyYB2Fc0qh1qmuhSETE561MkbCrkVvu4Aq+lgNmSwqXUK9mjH8s45pGTA61ozQomf3ikj0NUGljZ9oYZqoybIkl3MnUo12EuCR6isCNAJTiu0eBZIyrruU9ciqmi+Hk1DxjY6V/yymkBbPBKAbmwfXAbFdtCfQ4q8LanvXgazax8E6RA+N32dZCAMY3fNz7810GajQKiKigBVGAB2FPFWcwopaQUUAeGE8Uh9/wCdO68U0jNUUNbB55pp4oOSe+PemnPUYxSGZ+uN/wASqXG08qDn03DP6Vw9wqyH5zxXe6igewmBGeM/lXGS2/mqyAcmok7FwVzNj+yg4WF5CPQkVetLOHUFP2WOZmVlUhUZsE5wMgdTg/kaZb20trMGUFWHGcZrV0pY9Ovftlv+7nwQGCqQM9cAg4rNyRootlWCZ9OuCsjFSDtIPFdJZ3qTgAMDXKaxm5mZy8kkjdWds8Z6VoaDE6j5ieKxqxTVzelJp2OpkLKgCsVHqK57U5isuDeS5P8AAuTWxL5vlgrWY1rcpeLcqfmBzgqKypNI2qpspWtzayP5ctzIrA42kc5/GtIWVjNjbM4PTJbvTrDTok1Fr5jtZm3tDtJjdvcbgevPWrV5C93ftezNunf7zBQoP4Ct5TXRnPGm+qFt7doFKby6dieorT8NTz2XjSxubeGGR3CwDzR03NgkHscHGeevQ1SjLhNpFa/hyF5vEmlpEhdhco5A/uqck/gMn8KinN8xc4R5bM9s+tKBRilA4rsPNFoopaYjw4rntikxUjDBI5pmPzqiyJ1z15pv4YHpTm46Uc0gKmo/8g+fA/gOa5CIgPk12N9n7BP6bGz+VcUrAGs6mxtSepqoiTrnFO+xrzg5plkw4GOataiZYtJuJ4Qd6L1HUepribd7HoKKtc567K/bDEuDt61uaNbkoTnk1j2FsgtBM3zO3zMTXW6HbCQoqsoB7npV1HaNiKUW5DzG0eQw4p5tt0YK4OfStS401/MKF0PbKsCD+NZtxbS2TDn5SexrjTOxplb7O2cfNViG1Tgux+laGmLHdN5bjk9zVq5s44QQKpyYuVXMiaNQuVFdZ8PLMS65NcsissEGFJ/hZjjI/AMPxrl5htGAciu4+GynOon+HEfbr96unDbnFi9InfUtJTwPau08wSnAZoxihaYHi99AYZTxVJmwK6/VNPEqEgZrkLqEwyEEEGqTKImb16e1N3H1NRs2M03f60AOuB5ttLGDjcpHr2rgXYh29jXe7xXF6nB9n1CRMYUnK/SoktC4PUtWE3OSK2hfpBD8xGDwQa5yzYAgE49KvPGPJPOWx3rjlC8jvjUajoR3N0mx4rZQiN1VVGP/AK1aWiie1si+49ehPSubjlmWYx+WMjuDW3aSXKqEdDsP+e1OcHaw6Tu7nQ+d9qhG6Rwp4JB5FSNLEtv5OWb0LHJrKhuhGuxRgZ6YqR7qR8KsKluxPasXTZu52Jra8a3uR1wK1Jb4zIOcmudhNw0uJ1Qem3Na0fCgDk1MopExqN7jySVNelfDuFV0S4lwdzz7ST3AUY/ma82YrjOOa9m0CxbTNDtLRxiREy4JBwx5IyOuCSPwrow8epx4qWljS705TTO9KDXWcJJkeoxThg/SoyAy4IBB9RThjjFMDjpArDBrn9WtLdlLFlB+tZF94luZiRGdgrFlu5ZSS8hOfWqsCC4CLKQpyM1Fn1phcetRTXMNtHvmlRF/2jjNA7k+T61ieI7XzbQXKcPF156rTbrxJbRIfs4MpHc5Arl9Q1C71BSzsfmYKFHRafL1Yc2uhYtbrJB6VfF2SRg9RzXOKzIqtnINWre9+ba351hKHVHRGobQj8x93Q+tbdvLsjVSCe3ArHtZQ6HB6VrQSbkGBtFc8nY66ba2L1vKqlgU5PGStSMygZA5PWooAHTqM05kCjLEVm3c0bfUdwx57U9Zdg5P0qjJeIG2LzUaXBnbaoO0dWzT5LmTqWO+8C6K+p6kNSuF/wBEtG+TnG+XqPwHB+uOvNepbq8j8M/EW30zT00+6tv3Vt+7WSEAHGT94Z65ySRycgkZNeg6P4n0nXEQ2N9DI7gkR7sPgdflPP6V2xhaOh59STlLU3Vb3p4NVw3pT1aqIJwaXdUQPIp+aAPnKe+t4CRLOinuuefyrOn8QWseREryt2/hH+P6VzZBNMK47Ct+QnmNWbxBdykhFSJe23k1mSTGaUySMXc9WPNMCEg9BSqCT1qkkhXGsgZGcnlT079KbaKrAZGQsyHHtmnSKuGU5yeQR2plrgyPGQCHXHtmpmrocXqQFP3YHbJFM+zMTgVoi1L2ZfB4kbt71JBEGwCK43Ox1qNyta3EtqcHOPRq149Sk8vaqJk991KlkSp24Yehp8enJn5o2X3FZucXuaKMlsOhvriMjgYz605r26uGEak49FGau29jAAAU3n3FaMUGB8qBR+VZupFbI0UJPdmVBp8r/NM20H+Edfxq95YjQKgAA7Crfl4FU7tySLeJsSuM5/uL3b/D1P41CqOTLcFFGMsrGF14wbidv0jH9KppKUldM8Vcl2h2RPlSKIAf8C5H/joWqKFRNuODxivUoO8LnmVfisdZZfEDxLYRJHHqUrxo2dsqrJuHoWYFsewI9q9C8LfFKz1NltdZRLO4J+WZM+U3PQ5yV7ckkcEkjpXiik45PNKpK4II49a0cEzO59Xg465qQHivnnQ/H+uaOkUEV15ltHwIZgHXGMAZ+8AOMAEDivRtI+KmmXbBb61mtCWI3qfNQDHU4AP4AGsnTaHc8A6ngUhDE+tBPHU/lTycjuc81uSM9qao+bPank89PzoUH+FRTAY2chux4P8A9eq7Axy8ZHOau9QwIGDwaiZN2QwwQMj3FJoDb06ZL228kqAwByAMULYMH6YrDt5ntpdyHBHH+f8AP9a63T9Qgu1CyMqSD14rgxFKS96J20KifuyFtYCvDCr6WwbkLUpg2dafH8tedKTO9JDFgYdjUoiNTqfeqVzcySStBagM68PI33I/r6n2/lSV2xtpFa/vPs7i3hXzbpx8qDsPVvQVl3MgsIjE7Ga5nOZcdWHp7DsPrVieW105pPKJnu5PvtnJJ9+w+grILMsrSyNvmfrjt9K7KFBz9DkrVeX1GyuYomV2BldjJIQOCx5qtEAFLEfMeBnt/nmkLGWTDYxnk+v+f8+pftJAweP4Qf516iSSsjzm76sAvHuaXBAFLgjjOfwpDnJwaoQDIP8A9bpU6SOhyCfwqvtJOeKepJzgnH6UAU93cc0gcnj+tNJXPfNOJx+FAAWPTI6UFj1x+VJkY+7n6U0MOfl5oAmDEEds0pIcbehHIb0qNW78gU4jcvGOOlADNuTzwR/n/P8A9enxs0bAhtpB4IP+f/1GgfOcbsEcZFKEOQuMjvj/AD9PypAb+iTz32p2loVllV5QHSIMzbQctgLk9Aa9K0vwBBrD3EsWpmFFnkjWJ4n3AKxHILg9u9eeeBZIbfxlYyzMVjxOhI7FoXA/U4/GvZTr58M+C11R40aa8kMkanO3fJuk5IHQDcffGMjOa468E5aI6adRqO5HJ8LdN8ooZS4zjLGXPT1WQe35Vjn4faYtxPpys8UKpGUcQTnYXLDPL4wCAefx9ao+Hvilqtz4qjtNTED29zMsIWFdoibdgMDnkZPOSeOQeMHv/Ek6RaBrN8Ig72lq0xAPJKAuMeh44OOKzdOxaqa6nzpJKscC+Vhc9SByeaoMWfOOB6/0/GrbRZRRySqAADj1zz+VV5isXBwW9B0H+RXopWRxuV2Qg/dRQMfzqXLdMg81FGQW3HipGcgbhnng0CHfePX60jHIx3PWhWJB4Ge5zTWYg8DmgBQSF6Z59acp565pnUf/AFqXkAfSgZR3Z745pRu3AEn1qPdgY459aercd+uKQD/mORk+tNUFuuf6Up9D/OhCd2cfgTQA8LT19wOexNNzkcrz6Uu5dvGaYhvIPNSBSeQ1JwRjH04oAKNyDg/hQFzuPhnbpceJpoJ4i6S2kiKw6q2VOfrgNXq154YXxP8AD/TrAzeRJHBFLDIckBgmOQMZBVmHtnOOK8y+Hwg+wa/NI+2SCBGjOOu5ZVI/UV7RoMKv4c048jdaxnr/ALIrlq/Fc1Wx5x4a+F97puvWt5ql9ayx2zLKsdsWYs4OQCWUYAPPv0rtdbVv+Eb8TqUA3204U5ycfZuv510iwxqo24A9a5fxZdJZeGddlfAX5oskAcvAFH15YD1qL3aGj58uJ2CqMljj1rPkJdsValcknJzntmq643HBGScV2mKHIML8uM/nQSCwycD6UrqoI4PvTFBbgH9OaAHkgKc8+4ppIJ4BqXcMDnI75qMHJPOaYARlgduRSkEHBGKAfYkelAIxnbjHSkBnJ8w+Y/nSrx0x6UUUkMfjP3uffNKpGf50UUAPGWH04pD2HGaKKYh6nB6+9SnkEkkg9s80UUDO78DWtufDmvXtzvxsjiUj1zn8sla9r8PGWPQbSG5jEUiRhAo7ADAoorjqfEzRbIuMrB8AmuK+J2oGDwRLbXKIVvpgkbxcjKyK6fiUQ/jRRSgveQ+jPBpctwQT/SmhfmBOPxFFFdpiNfcRnPTgClQHbn27UUUwEycYwRRgryBxRRSAcNxGC3HvSHOMY/H1oopgf//Z", "gender": "M", "tags": { "@abdm/gov.in/experience": "5.0", "@abdm/gov.in/languages": "English, Hindi", "@abdm/gov.in/education": "MBBS", "@abdm/gov.in/hpr_id": "<ABHA_NUMBER>" } }, "start": { "time": { "timestamp": "2025-10-15T17:50:00" } }, "end": { "time": { "timestamp": "2025-10-15T18:10:00" } }, "tags": { "@abdm/gov.in/slot_id": "<TXN_ID>", "@abdm/gov.in/doctors_key": "<@ABDM/GOV.IN/DOCTORS_KEY>" } }, "billing": { "name": "<NAME>", "address": { "name": "<NAME>", "locality": "bhadgaon road, near new watar tank, sapthshrungi nagar, Chalisgaon, Chalisgaon, Jalgaon, Maharashtra", "city": "JALGAON", "state": "MAHARASHTRA", "country": "INDIA", "area_code": "424101" }, "phone": "<MOBILE>" }, "quote": { "price": { "currency": "INR", "value": "0.0" }, "breakup": [ { "title": "Consultation", "price": { "currency": "INR", "value": "0.0" } }, { "title": "CGST @ 5%", "price": { "currency": "INR", "value": "0.0" } }, { "title": "SGST @ 5%", "price": { "currency": "INR", "value": "0.0" } }, { "title": "Registration", "price": { "currency": "INR", "value": "0" } } ] }, "customer": { "id": "ganesh2305@sbx", "person": { "gender": "M", "dayOfBirth": 23, "monthOfBirth": 5, "yearOfBirth": 1992, "dob": "<DATE_OF_BIRTH>" } }, "payment": { "uri": "", "type": "ON-ORDER", "status": "FREE", "params": { "transaction_id": "", "amount": "0.0", "mode": "", "vpa": "", "redirect_url": "" } }, "terms": [ { "type": "Commercial", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of commercial terms", "long_desc": "Long description of commercial terms" }, "reasonRequired": false, "timePeriod": "2025-10-15T17:50:00", "reason": "", "termsState": "AGREED" }, { "type": "Settlement", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of Settlement terms", "long_desc": "Long description of Settlement terms" }, "reasonRequired": false, "timePeriod": "2025-10-15T17:50:00", "reason": "", "termsState": "AGREED" }, { "type": "Cancellation", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of Cancellation terms", "long_desc": "Cancellation: Full refund if cancelled 48 hrs before consultation time. n Rescheduling: No charges for rescheduling 48 hrs prior to consultation time" }, "reasonRequired": false, "timePeriod": "2025-10-15T17:50:00", "reason": "", "termsState": "AGREED" }, { "type": "Refund", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of Refund terms", "long_desc": "No Show: If doctor does not show up - full refund. No refund if patient does not turn up for appointment" }, "reasonRequired": false, "timePeriod": "2025-10-15T17:50:00", "reason": "", "termsState": "AGREED" }, { "type": "Payment", "descriptor": { "name": "<NAME>", "flag": false, "short_desc": "Short description of Payment terms", "long_desc": "Long description of Payment terms" }, "reasonRequired": false, "timePeriod": "2025-10-15T17:50:00", "reason": "", "termsState": "AGREED" } ], "authorization": { "type": "PIN", "token": "<TOKEN>", "valid_from": "2025-10-15T00:00:00", "valid_to": "2025-10-15T23:59:00", "status": "GENERATED" } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.timestamp` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.provider_id` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `context.message_id` (string, required) - `message` (object, required) - `message.order` (object, required) - `message.order.id` (string, required) - `message.order.provider` (object, required) - `message.order.provider.id` (string, required) - `message.order.provider.descriptor` (object, required) - `message.order.provider.categories` (object[], required) - `message.order.provider.location` (object, required) - `message.order.state` (string, required) - `message.order.item` (object, required) - `message.order.item.id` (string, required) - `message.order.item.descriptor` (object, required) - `message.order.item.price` (object, required) - `message.order.item.fulfillment_id` (string, required) - `message.order.fulfillment` (object, required) - `message.order.fulfillment.id` (string, required) - `message.order.fulfillment.type` (string, required) - `message.order.fulfillment.agent` (object, required) - `message.order.fulfillment.start` (object, required) - `message.order.fulfillment.end` (object, required) - `message.order.fulfillment.tags` (object, required) - `message.order.billing` (object, required) - `message.order.billing.name` (string, required) - `message.order.billing.address` (object, required) - `message.order.billing.phone` (string, required) - `message.order.quote` (object, required) - `message.order.quote.price` (object, required) - `message.order.quote.breakup` (object[], required) - `message.order.customer` (object, required) - `message.order.customer.id` (string, required) - `message.order.customer.person` (object, required) - `message.order.payment` (object, required) - `message.order.payment.uri` (string, required) - `message.order.payment.type` (string, required) - `message.order.payment.status` (string, required) - `message.order.payment.params` (object, required) - `message.order.terms` (object[], required) - `message.order.terms.type` (string, required) - `message.order.terms.descriptor` (object, required) - `message.order.terms.reasonRequired` (boolean, required) - `message.order.terms.timePeriod` (string, required) - `message.order.terms.reason` (string, required) - `message.order.terms.termsState` (string, required) - `message.order.authorization` (object, required) - `message.order.authorization.type` (string, required) - `message.order.authorization.token` (string, required) - `message.order.authorization.valid_from` (string, required) - `message.order.authorization.valid_to` (string, required) - `message.order.authorization.status` (string, required) ## Responses - `200`: No response body is documented for this request. --- # {{aarogya-setu-sandbox-url}}api/health/service/doctor/master/system-of-medicine `GET /health/service/doctor/master/system-of-medicine` Lists the systems of medicine a doctor can be filtered by. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/health/service/doctor/master/system-of-medicine \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "id": 1, "medicalSystem": "Modern Medicine", "code": "modern_medicine", "position": 1, "excludeStates": "[\"1\",\"6\",\"104\",\"17\",\"18\",\"26\",\"32\"]", "hprType": "doctor" }, { "id": 2, "medicalSystem": "Dentistry", "code": "dentist", "position": 2, "excludeStates": "[\"1\",\"17\",\"18\",\"103\",\"32\"]", "hprType": "doctor" }, "... 12 more of the same shape" ] ``` --- # {{aarogya-setu-sandbox-url}}api/health/service/doctor/geo-location/search-within-radius `POST /health/service/doctor/geo-location/search-within-radius` Finds doctors within a radius of a point, filtered by name, speciality, facility ownership and type, with paging. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/health/service/doctor/geo-location/search-within-radius \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "abdmSoftware": "0", "centerLat": "18.<REDACTED_ID>", "centerLon": "73.<REDACTED_ID>", "facilityOwnership": "", "from": "0", "hospitalSpecialityType": "", "radiusInKm": "5000", "size": "100", "speciality": "", "doctorName": "", "gender": "", "doctorSystemOfMedicine": "M", "languages": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `abdmSoftware` (string, required) - `centerLat` (string, required) - `centerLon` (string, required) - `facilityOwnership` (string, required) - `from` (string, required) - `hospitalSpecialityType` (string, required) - `radiusInKm` (string, required) - `size` (string, required) - `speciality` (string, required) - `doctorName` (string, required) - `gender` (string, required) - `doctorSystemOfMedicine` (string, required) - `languages` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "searchCountTotal": 165, "recordList": [ { "name": "<NAME>", "hprProfileId": 31426, "healthIdNumber": "<ABHA_NUMBER>", "mobileOfficial": "<MOBILE>", "emailOfficial": "<EMAIL>", "gender": "Male", "registrationNumber": "1234567890", "systemOfMedicine": "Modern Medicine", "facilityLocation": { "lat": 18.53145937529085, "lon": 73.87545685498799 }, "distances": "0", "facilityId": "IN2710004269", "courseName": "MBBS - Bachelor of Medicine and Bachelor of Surgery, test 12345", "piLanguages": [ "3" ], "facilityName": "Test bhavya <REDACTED_ID>", "facilityAddress": "test 123r", "facilityContact": null, "designationWithOrganisation": "Sr. Doctor", "workExperienceInYear": "5", "facilitySystemOfMedicine": [ "Dentistry, Modern Medicine(Allopathy), Ayurveda, Unani, Physiotherapy", "Modern Medicine" ], "facilityDepartment": "Cardio", "speciality": null }, { "name": "<NAME>", "hprProfileId": 33389, "healthIdNumber": "<ABHA_NUMBER>", "mobileOfficial": "<MOBILE>", "emailOfficial": "<EMAIL>", "gender": "Female", "registrationNumber": "56789", "systemOfMedicine": "Modern Medicine", "facilityLocation": { "lat": 18.504648793596203, "lon": 73.76347481875169 }, "distances": "12.18", "facilityId": "IN2710004268", "courseName": "MBBS - Bachelor of Medicine and Bachelor of Surgery", "piLanguages": [ "1", "2", "... 1 more of the same shape" ], "facilityName": "Manish Test 21 Aug", "facilityAddress": "Test 123456", "facilityContact": "<MOBILE>", "designationWithOrganisation": "fefefjenfejnfejfnejfn", "workExperienceInYear": "6", "facilitySystemOfMedicine": [ "Modern Medicine(Allopathy), Dentistry, Physiotherapy, Ayurveda, Unani", "Modern Medicine" ], "facilityDepartment": "fhfjdfjeff", "speciality": [ "AmrazAtfal (Paediatrics)", "AmrazeJigar wa Mirara (Hepato-biliary System)", "... 9 more of the same shape" ] }, "... 98 more of the same shape" ] } ``` --- # Create `POST /health/service/bookmark/create` Saves a place as a bookmark for the signed-in ABHA address, with a title, address and coordinates. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/health/service/bookmark/create \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "title": "House_05", "address": "<ADDRESS>", "latitude": 40.7128, "longitude": -74.006 }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `title` (string, required) - `address` (string, required) - `latitude` (number, required) - `longitude` (number, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "id": 244, "abhaAddress": "<ABHA_ADDRESS>", "title": "House_05", "address": "<ADDRESS>", "latitude": 40.7128, "longitude": -74.006, "isDeleted": false, "createdTime": "2026-05-29T15:36:43.437326935", "updatedTime": "2026-05-29T15:36:43.437335006" } ``` --- # Delete `DELETE /health/service/bookmark/delete/{id}` Deletes one of the person's saved place bookmarks. ```bash curl --request DELETE \ --url https://phrsbx.abdm.gov.in/health/service/bookmark/delete/{id} \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `id` (string, required): Passed as a path segment. ## Responses - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors --- # Get categories by id `GET /teleconsulting/getCategories/1` Returns one teleconsultation category by its id. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/teleconsulting/getCategories/1 \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "categoryId": 1, "descriptor": "Consultation" } ] ``` --- # Get categories `GET /teleconsulting/getCategories` Lists the teleconsultation categories available to search in. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/teleconsulting/getCategories \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "categoryId": 2, "descriptor": "Consultation" }, { "categoryId": 3, "descriptor": "Consultation" }, "... 782 more of the same shape" ] ``` --- # Get Category List `GET /health/service/facility/categories/list` Lists the facility categories available for filtering a search. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/health/service/facility/categories/list \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "title": "Hospital/Clinic", "somEnable": true }, { "title": "Lab/Radiology", "somEnable": false }, "... 2 more of the same shape" ] ``` --- # get-coverage-eligibility `POST /nhcx/get-coverage-eligibility` Checks whether a person's insurance policy covers them, through the National Health Claims Exchange. The result arrives at `on_check`. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/nhcx/get-coverage-eligibility \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "sno": "200012950", "abhanumber": "<ABHA_NUMBER>", "mobilenumber": "<MOBILE>", "memberid": "PM3T2HSBX", "payerid": "1518@hcx", "productid": "100155", "productname": "PMJAY/HP/S/G", "processingid": "1518@hcx" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `sno` (string, required) - `abhanumber` (string, required) - `mobilenumber` (string, required) - `memberid` (string, required) - `payerid` (string, required) - `productid` (string, required) - `productname` (string, required) - `processingid` (string, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "timestamp": "<TIMESTAMP>", "api_call_id": "<API_CALL_ID>", "correlation_id": "<CORRELATION_ID>", "result": { "sender_code": "<SENDER_CODE>", "recipient_code": "<RECIPIENT_CODE>", "entity_type": "<ENTITY_TYPE>", "protocol_status": "<PROTOCOL_STATUS>" }, "error": "<ERROR>" } ``` --- # get details `GET /scan-pay/get/details` Lists the person's scan and pay requests with the status, order number and transaction id of each. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/scan-pay/get/details \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "id": 0, "abhaAddress": "<ABHA_ADDRESS>", "scanPayRequestId": "<SCAN_PAY_REQUEST_ID>", "status": "<STATUS>", "dateModified": "<DATE_MODIFIED>", "dateCreated": "<DATE_CREATED>", "orderNumber": "<ORDER_NUMBER>", "transactionId": "<TRANSACTION_ID>", "hipId": "<HIP_ID>", "paymentDate": "<PAYMENT_DATE>", "paymentUrl": "<PAYMENT_URL>", "paymentAmount": "<PAYMENT_AMOUNT>", "counterCode": "<COUNTER_CODE>", "facilityName": "<FACILITY_NAME>", "patientSelectRequestId": "<PATIENT_SELECT_REQUEST_ID>", "paymentDesc": [ { "category": "<CATEGORY>", "services": [ { "name": "<NAME>", "description": "<DESCRIPTION>", "amount": 0, "serviceId": "<SERVICE_ID>" } ] } ], "paymentReceiptLink": "<PAYMENT_RECEIPT_LINK>", "scanPayVersion": "<SCAN_PAY_VERSION>" } ] ``` --- # Get Distinct Category List `GET /health/service/facility/categories/distinct` Lists the distinct facility categories, with the care settings each offers. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/health/service/facility/categories/distinct \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "id": { "sno": 9, "systemmedicine": "M" }, "facilityType": "G", "facilityTypeNdhm": "Blood Bank", "opd": "No", "ipd": "No", "dayCare": "No", "other": "No", "activeYN": "Y", "createdBy": "1358478", "createdDate": "2020-07-23T13:55:32.623+00:00", "lastUpdatedUser": "", "lastUpdatedDate": null, "linkToForm": "SubmitForm ", "facilityCode": "NHRR_08 ", "facilityCodeUfid": "blb", "facilityOrder": 8 }, { "id": { "sno": 44, "systemmedicine": "M" }, "facilityType": "P", "facilityTypeNdhm": "Blood Bank", "opd": "No", "ipd": "No", "dayCare": "No", "other": "No", "activeYN": "Y", "createdBy": "1358478", "createdDate": "2020-07-23T13:55:32.623+00:00", "lastUpdatedUser": "", "lastUpdatedDate": null, "linkToForm": "SubmitForm ", "facilityCode": "NHRR_08 ", "facilityCodeUfid": "blb", "facilityOrder": 43 } ] ``` --- # Get Doctor Details `GET /health/service/facility/doctors/{searchId}` Lists the doctors at a facility, by the facility's search id. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/health/service/facility/doctors/{searchId} \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `searchId` (string, required): Passed as a path segment. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "totalCount": 1, "doctorDetails": [ { "id": 80285, "name": "<NAME>", "hprProfileId": 31426, "designationWithOrganisation": "Sr. Doctor", "facilityId": "IN2710004269", "systemOfMedicine": "1", "doctorQualification": [ { "courseName": "MBBS - Bachelor of Medicine and Bachelor of Surgery", "systemOfMedicine": "1" }, { "courseName": " test 12345", "systemOfMedicine": "1" } ], "hospitalId": null, "state": null, "district": null, "facilityTransactionId": null, "digiDoctorId": null, "facilityName": null, "facilityType": null, "facilityAddress": null, "facilityPincode": 0, "status": null, "createdAt": null, "updatedAt": null, "facilityOwnership": null, "facilitySystemOfMedicine": null, "facilityDepartment": null, "facilityStatus": null, "facilityEloc": null, "facilityLat": 0, "facilityLong": 0, "verificationStatus": null, "remark": null, "facilitySuggesstionId": null, "selfDeclared": false, "current": false } ] } ``` --- # Get Facility Details By Search ID `GET /health/service/facility/search/IN3310027864` Returns a facility's registry entry by its search id, including its contact person and address. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/health/service/facility/search/IN3310027864 \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "facUniqueId": "string", "facContactPerPrefix": "null", "facContactPerName": "string", "facContactPerMiddleName": "string", "facContactPerSurname": "string", "facContactPerDesg": "null", "facContactPerCountryCode": "null", "facContactPerMobNo": "string", "facContactPerEmail": "string", "facContactPerStdCode": "null", "facContactPerLandlineNo": "null", "facName": "string", "facOwnership": "string", "facPAN": "null", "facTAN": "null", "facGST": "null", "country": "string", "state": "string", "district": "string", "pincode": "string", "geolocation": "string", "subDistrict": "string", "facRegion": "string", "vilCityTown": "string", "address1": "string", "address2": "string", "landlineNo": "string", "mobileNo": "string", "facEmail": "string", "daysOfOperation": "null", "hoursOfOperation": "null", "aboutUs": "null", "itAvailable": "null", "netAvailable": "null", "emrSystem": "string", "emrSoftware": "string", "powerBackup": "null", "facOperStatus": "string", "typeOfService": "string", "typeOfServiceOth": "null", "facOwnerGovt": "string", "facOwnerPrivate": "string", "ownerSubType": "string", "facCentral": "string", "facCentralOth": "null", "systemOfMedicine": "string", "facilityType": "string", "facilityTypeOth": "null", "hospitalCntLinkColg": "null", "stdCode": "null", "addProofType": "null", "addProofType2": "null", "addProofType3": "null", "facWebsite": "string", "openTime": "null", "closeTime": "null", "crtDt": "string", "crtUsr": "string", "lstUpdDt": "string", "lstUpdUsr": "string", "termsAgreeFlag": "string", "submitFlag": "null", "status": "string", "healthId": "string", "appSubmitDt": "string", "nhrrFacilityId": "null", "nhrrFormId": "null", "hospitalLinkToColg": "null", "colgCntLinkHospital": "null", "altHealthDtls": "null", "healthWellnessCenter": "null", "ufid": "null", "mobileNoPerCountryCode": "null", "activeYn": "string", "alternateId": "string", "alternateContactDtls": "null", "facAltContactPerPrefix": "null", "facAltContactPerName": "null", "facAltContactPerMiddleName": "null", "facAltContactPerSurname": "null", "facAltContactPerDesg": "null", "facAltContactPerCountryCode": "null", "facAltContactPerMobNo": "null", "facAltContactPerEmail": "null", "facAltContactPerStdCode": "null", "facAltContactPerLandlineNo": "null", "mobileNoVerified": "string", "facEmailVerified": "string", "facContactPerEmailVerified": "string", "facAltContactPerEmailVerified": "null", "nameAsInPanCard": "null", "progressValue": "null", "bookAppUrl": "string", "ehospitalid": "null", "identificationNo": "null", "rohiniId": "null", "pmjayHospitalId": "null", "cghsHospitalId": "null", "echsHospitalId": "null", "yearOfEstablish": "null", "hospitalSpecialType": "null", "privateProfitType": "string", "powerBackupIT": "null", "pharmacySoftware": "null", "pharmacySoftwareName": "null", "source": "string", "entityType": "string", "hmisCode": "null", "facilitySubtype": "string", "facilitySubtypeOther": "null", "ceaId": "null", "declaredBy": "string", "hrpSource": "null", "hrpSourceFacilityId": "null", "isStandaloneIS": "null", "standaloneISName": "null", "isLMISorRISSystem": "null", "ifAnyOther": "string", "emrSoftwareOther": "null", "form1": "null", "form2": "null", "form3": "null", "pharmacySoftwareOther": "null", "abdmSoftware": "null", "resubmitted": "boolean", "facilityPassword": "boolean", "facilityStatus": "string", "workDetailslist": "array", "bridgeDetails": "array", "daysOfOperationObject": "array", "stinsid": "null", "esushrutId": "null", "earogya": "null", "lmisorRISSystemName": "null", "sourceId": "null" } ``` --- # Get Languanges `GET /health/service/doctor/master/languages` Lists the languages a doctor can be filtered by. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/health/service/doctor/master/languages \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "id": 1, "name": "<NAME>", "culture": "", "status": true }, { "id": 2, "name": "<NAME>", "culture": "", "status": true }, "... 27 more of the same shape" ] ``` --- # Get Orders by Abha Id and Type `GET /teleconsulting/getOrdersByAbhaIdAndType/kushal.1122000@sbx` Lists the teleconsultation orders of an ABHA address, filtered by order type. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/teleconsulting/getOrdersByAbhaIdAndType/kushal.1122000@sbx \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "pinCode": 0, "districtCode": 589, "districtName": "THIRUVALLUR", "stateCode": 33, "stateName": "TAMIL NADU" } ] ``` --- # Get Orders by ABHA id desc `GET /teleconsulting/getOrdersByAbhaIdDesc` Lists the teleconsultation orders of an ABHA address, newest first. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/teleconsulting/getOrdersByAbhaIdDesc \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json "array" ``` --- # get Orders by ABHA id `GET /api/teleconsulting/getOrdersByAbhaId` Lists the teleconsultation orders placed by an ABHA address. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/teleconsulting/getOrdersByAbhaId \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json "array" ``` --- # get Orders by id `GET /api/teleconsulting/getOrders/6254-172027-4007` Returns one teleconsultation order by its order id, with the service, the professional and the fulfilment time. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/teleconsulting/getOrders/6254-172027-4007 \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "orderId": "string", "categoryId": "string", "healthcareServiceName": "string", "healthcareServiceId": "string", "healthcareProviderUrl": "string", "healthcareProfessionalName": "string", "healthcareProfessionalImage": "string", "healthcareProfessionalId": "string", "healthcareProfessionalGender": "string", "serviceFulfillmentStartTime": "string", "serviceFulfillmentEndTime": "string", "serviceFulfillmentType": "string", "isServiceFulfilled": "string", "message": "string", "slotId": "string", "patientConsumerUrl": "string", "transId": "string", "abhaId": "string" } ``` --- # get-policies `POST /nhcx/get-policies` Lists the insurance policies held against an ABHA number. `encryptedAbhaNumber` is the ABHA number encrypted. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/nhcx/get-policies \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "encryptedAbhaNumber": "<ABHA_NUMBER>", "insuranceType": "pmjay" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `encryptedAbhaNumber` (string, required) - `insuranceType` (string, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "sno": "<SNO>", "abhanumber": "<ABHANUMBER>", "mobilenumber": "<MOBILENUMBER>", "memberid": "<MEMBERID>", "payerid": "<PAYERID>", "productid": "<PRODUCTID>", "productname": "<PRODUCTNAME>", "processingid": "<PROCESSINGID>" } ] ``` --- # Get Specialists Category List `GET /health/service/facility/categories/specialities` Lists the specialities available for filtering a facility search. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/health/service/facility/categories/specialities \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "id": { "id": "S6", "systemMedicine": "M" }, "name": "<NAME>", "activeYN": "Y", "arrangeOrder": null, "createdBy": "1593093", "createdDate": "2020-07-24T18:30:00.000+00:00", "lastUpdatedBy": null, "lastUpdatedDate": null, "specialityOrder": 19, "searchKeywords": "<SEARCHKEYWORDS>" }, { "id": { "id": "S11", "systemMedicine": "M" }, "name": "<NAME>", "activeYN": "Y", "arrangeOrder": null, "createdBy": "1593093", "createdDate": "2020-07-24T18:30:00.000+00:00", "lastUpdatedBy": null, "lastUpdatedDate": null, "specialityOrder": 20, "searchKeywords": "<SEARCHKEYWORDS>" }, "... 40 more of the same shape" ] ``` --- # Get Specialists `GET /api/hem/getSpecialists` Lists the specialities available for filtering a facility search. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/api/hem/getSpecialists \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "specialityid": "100001", "specialitycode": "BM", "specialityname": "Burns Management", "displayorder": "1", "status": "Active" }, { "specialityid": "100002", "specialitycode": "MC", "specialityname": "Cardiology", "displayorder": "2", "status": "Active" }, "... 132 more of the same shape" ] ``` --- # get/summary `GET /health/service/bookmark/summary` Lists the person's bookmarked places in summary form: title, address and coordinates. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/health/service/bookmark/summary \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "title": "Home", "address": "<ADDRESS>", "latitude": 18.511805, "longitude": 73.735285 }, { "title": "office 2", "address": "<ADDRESS>", "latitude": 18.593371, "longitude": 73.73306 }, "... 2 more of the same shape" ] ``` --- # Get System of Medicine List `GET /health/service/facility/master/system-of-medicine` Lists the systems of medicine a facility can be filtered by. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/health/service/facility/master/system-of-medicine \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "id": "M", "value": "Modern Medicine(Allopathy)" }, { "id": "D", "value": "Dentistry" }, "... 7 more of the same shape" ] ``` --- # getByAbhaAddress `GET /health/service/bookmark/getByAbhaAddress` Lists the places the signed-in ABHA address has bookmarked. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/health/service/bookmark/getByAbhaAddress \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json [ { "id": 242, "abhaAddress": "<ABHA_ADDRESS>", "title": "House_05", "address": "<ADDRESS>", "latitude": 40.7128, "longitude": -74.006, "isDeleted": false, "createdTime": "2026-05-29T15:36:08.236642", "updatedTime": "2026-05-29T15:36:08.236654" }, { "id": 244, "abhaAddress": "<ABHA_ADDRESS>", "title": "House_05", "address": "<ADDRESS>", "latitude": 40.7128, "longitude": -74.006, "isDeleted": false, "createdTime": "2026-05-29T15:36:43.437327", "updatedTime": "2026-05-29T15:36:43.437335" }, "... 1 more of the same shape" ] ``` --- # Get HFR Facility Details By Search ID `GET /v4/hfr/facility/search/searchFacility/IN2710002401` Looks up a facility by search ID in the Health Facility Registry (HFR), NHA's national registry of health facilities. This is a different registry from the nearby-health-service facility search elsewhere in this file: it is a separate NHA system with its own host and its own record shape, not an alternate route to the same data. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/v4/hfr/facility/search/searchFacility/IN2710002401 \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "facUniqueId": "string", "facContactPerPrefix": "null", "facContactPerName": "string", "facContactPerMiddleName": "string", "facContactPerSurname": "string", "facContactPerDesg": "null", "facContactPerCountryCode": "null", "facContactPerMobNo": "string", "facContactPerEmail": "string", "facContactPerStdCode": "null", "facContactPerLandlineNo": "null", "facName": "string", "facOwnership": "string", "facPAN": "null", "facTAN": "null", "facGST": "null", "country": "string", "state": "string", "district": "string", "pincode": "string", "geolocation": "string", "subDistrict": "string", "facRegion": "string", "vilCityTown": "string", "address1": "string", "address2": "string", "landlineNo": "string", "mobileNo": "string", "facEmail": "string", "daysOfOperation": "null", "hoursOfOperation": "null", "aboutUs": "null", "itAvailable": "null", "netAvailable": "null", "emrSystem": "string", "emrSoftware": "string", "powerBackup": "null", "facOperStatus": "string", "typeOfService": "string", "typeOfServiceOth": "null", "facOwnerGovt": "string", "facOwnerPrivate": "string", "ownerSubType": "string", "facCentral": "string", "facCentralOth": "null", "systemOfMedicine": "string", "facilityType": "string", "facilityTypeOth": "null", "hospitalCntLinkColg": "null", "stdCode": "null", "addProofType": "null", "addProofType2": "null", "addProofType3": "null", "facWebsite": "string", "openTime": "null", "closeTime": "null", "crtDt": "string", "crtUsr": "string", "lstUpdDt": "string", "lstUpdUsr": "string", "termsAgreeFlag": "string", "submitFlag": "null", "status": "string", "healthId": "string", "appSubmitDt": "string", "nhrrFacilityId": "null", "nhrrFormId": "null", "hospitalLinkToColg": "null", "colgCntLinkHospital": "null", "altHealthDtls": "null", "healthWellnessCenter": "null", "ufid": "null", "mobileNoPerCountryCode": "null", "activeYn": "string", "alternateId": "string", "alternateContactDtls": "null", "facAltContactPerPrefix": "null", "facAltContactPerName": "null", "facAltContactPerMiddleName": "null", "facAltContactPerSurname": "null", "facAltContactPerDesg": "null", "facAltContactPerCountryCode": "null", "facAltContactPerMobNo": "null", "facAltContactPerEmail": "null", "facAltContactPerStdCode": "null", "facAltContactPerLandlineNo": "null", "mobileNoVerified": "string", "facEmailVerified": "string", "facContactPerEmailVerified": "string", "facAltContactPerEmailVerified": "null", "nameAsInPanCard": "null", "progressValue": "null", "bookAppUrl": "string", "ehospitalid": "null", "identificationNo": "null", "rohiniId": "null", "pmjayHospitalId": "null", "cghsHospitalId": "null", "echsHospitalId": "null", "yearOfEstablish": "null", "hospitalSpecialType": "null", "privateProfitType": "string", "powerBackupIT": "null", "pharmacySoftware": "null", "pharmacySoftwareName": "null", "source": "string", "entityType": "string", "hmisCode": "null", "facilitySubtype": "string", "facilitySubtypeOther": "null", "ceaId": "null", "declaredBy": "string", "hrpSource": "null", "hrpSourceFacilityId": "null", "isStandaloneIS": "null", "standaloneISName": "null", "isLMISorRISSystem": "null", "ifAnyOther": "string", "emrSoftwareOther": "null", "form1": "null", "form2": "null", "form3": "null", "pharmacySoftwareOther": "null", "abdmSoftware": "null", "resubmitted": "boolean", "facilityPassword": "boolean", "facilityStatus": "string", "workDetailslist": "array", "bridgeDetails": "array", "daysOfOperationObject": "array", "stinsid": "null", "esushrutId": "null", "earogya": "null", "lmisorRISSystemName": "null", "sourceId": "null" } ``` --- # nhcx-onsubscribe `POST /nhcx/v1/hcx/notification/on_subscribe` Callback confirming a subscription to National Health Claims Exchange notifications. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/nhcx/v1/hcx/notification/on_subscribe \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "payload": "<SUPABASE_SERVICE_ROLE_API_KEY_1A5M>" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `payload` (string, required) ## Responses - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors --- # notify status `GET /scan-pay/notify/status/{id}` Returns the payment status of one scan and pay request, with the receipt link once paid. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/scan-pay/notify/status/{id} \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `id` (string, required): Passed as a path segment. ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "abhaAddress": "<ABHA_ADDRESS>", "scanPayRequestId": "<SCAN_PAY_REQUEST_ID>", "status": "<STATUS>", "orderNumber": "<ORDER_NUMBER>", "transactionId": "<TRANSACTION_ID>", "hipId": "<HIP_ID>", "paymentDate": "<PAYMENT_DATE>", "paymentReceiptLink": "<PAYMENT_RECEIPT_LINK>" } ``` --- # on_check `POST /nhcx/v1/coverageeligibility/on_check` Callback carrying the payer's answer to a coverage eligibility check. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/nhcx/v1/coverageeligibility/on_check \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "type": "JWEPayload", "payload": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `type` (string, required) - `payload` (string, required) ## Responses - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors --- # On Search `POST /v1/on_search` Callback carrying the PM-JAY empanelled facilities that matched a search. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/v1/on_search \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "messageId": "<MESSAGE_ID>", "transactionId": "<TRANSACTION_ID>", "consumerId": "<CONSUMER_ID>", "consumerUri": "<CONSUMER_URI>", "action": "on_search" }, "message": { "catalog": { "providers": [ { "id": "string", "descriptor": { "name": "<NAME>" }, "locations": [], "items": [], "fulfillments": [] } ] } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.messageId` (string, required) - `context.transactionId` (string, required) - `context.consumerId` (string, required) - `context.consumerUri` (string, required) - `context.action` (string, required) - `message` (object, required) - `message.catalog` (object, required) - `message.catalog.providers` (object[], required) - `message.catalog.providers.id` (string, required) - `message.catalog.providers.descriptor` (object, required) - `message.catalog.providers.locations` (object[], required) - `message.catalog.providers.items` (object[], required) - `message.catalog.providers.fulfillments` (object[], required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "context": { "domain": "string", "country": "string", "city": "string", "action": "string", "timestamp": "string", "core_version": "string", "consumer_id": "string", "consumer_uri": "string", "provider_id": "string", "provider_uri": "string", "transaction_id": "string", "message_id": "string" }, "message": { "catalog": { "descriptor": { "name": "string", "images": "string", "flag": "boolean", "short_desc": "string", "long_desc": "string" }, "providers": "array" } } } ``` --- # on_submit `POST /nhcx/v1/search/on_submit` Callback carrying the payer's answer to a policy search. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/nhcx/v1/search/on_submit \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "type": "<TYPE>", "payload": "<PAYLOAD>" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `type` (string, required) - `payload` (string, required) ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors --- # OPENORDER `POST /scan-pay/open-order` Opens a scan and pay order after the person scans a facility's payment counter QR code. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/scan-pay/open-order \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors --- # order-status `POST /scan-pay/order-status` Returns the status of a scan and pay order by its order number. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/scan-pay/order-status \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "orderNumber": "ORD-ABDM-123456", "openOrderRequestId": "<TXN_ID>" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `orderNumber` (string, required) - `openOrderRequestId` (string, required) ## Responses - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors --- # payment-order `POST /scan-pay/payment-order` Creates the payment order for the procedures selected and returns the UPI intent to pay with. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/scan-pay/payment-order \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "intent": "PAYMENT_ORDER", "openOrderRequestId": "<TXN_ID>", "procedures": [ { "category": "OPD consultation", "services": [ { "serviceId": "Resistance 1", "name": "<NAME>", "description": "Consult with a hematology specialist to assess for Protein C resistance, a condition that increases the risk of abnormal blood clotting. Ideal for patients with a history of deep vein thrombosis or unexplained clotting events.", "amount": 629 }, { "serviceId": "Resistance 2", "name": "<NAME>", "description": "989261250000094 1; date:06-May-2025", "amount": 610 }, { "serviceId": "Resistance 3", "name": "<NAME>", "description": "989261250000094 2; date:06-May-2025", "amount": 611 } ] }, { "category": "Laboratory and Diagnostics", "services": [ { "serviceId": "Flowcytometric 1", "name": "<NAME>", "description": "A specialized test using flow cytometry to accurately count CD34+ hematopoietic stem cells in blood or bone marrow. Essential for evaluating stem cell mobilization before transplantation or therapy planning.", "amount": 62 }, { "serviceId": "Flowcytometric 2", "name": "<NAME>", "description": "989261250000094 2; date:06-May-2025", "amount": 629 } ] }, { "category": "Pharmacy", "services": [ { "serviceId": "Tomography 1", "name": "<NAME>", "description": "A high-resolution 3D imaging scan used primarily for dental, ENT, and maxillofacial evaluations. CBCT provides detailed views of bones, teeth, and soft tissues, aiding in accurate diagnosis and treatment planning with minimal radiation exposure", "amount": 629 }, { "serviceId": "Tomography 2", "name": "<NAME>", "description": "Pharmacy Details", "amount": 610 } ] }, { "category": "Miscellaneous/Other", "services": [ { "serviceId": "Computerized 1", "name": "<NAME>", "description": "A high-resolution 3D imaging scan used primarily for dental, ENT, and maxillofacial evaluations. CBCT provides detailed views of bones, teeth, and soft tissues, aiding in accurate diagnosis and treatment planning with minimal radiation exposure", "amount": 629 }, { "serviceId": "Computerized 2", "name": "<NAME>", "description": null, "amount": 129 } ] } ] }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `intent` (string, required) - `openOrderRequestId` (string, required) - `procedures` (object[], required) - `procedures.category` (string, required) - `procedures.services` (object[], required) - `procedures.services.serviceId` (string, required) - `procedures.services.name` (string, required) - `procedures.services.description` (null,string, required) - `procedures.services.amount` (number, required) ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors --- # Rest Search `POST /v1/rest/search` Searches PM-JAY empanelled facilities and returns the results in the same call, without a callback. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/v1/rest/search \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85112", "country": "IND", "city": "std:011", "action": "search", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu.abdm.gov.in/aarogyasetu/api/v3/app/api/hem", "message_id": "<GENERATED>", "timestamp": "<ISO_8601_TIMESTAMP>", "transaction_id": "<GENERATED>" }, "message": { "intent": { "fulfillment": { "start": { "time": { "timestamp": "2022-07-22T13:21:41" } }, "end": { "time": { "timestamp": "2022-07-22T23:59:59" } }, "type": "PMJAYHEM" }, "item": { "descriptor": { "code": "PMJAY", "name": "<NAME>", "flag": false } }, "location": { "state": { "name": "<NAME>", "code": "27" } } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.message_id` (string, required) - `context.timestamp` (string, required) - `context.transaction_id` (string, required) - `message` (object, required) - `message.intent` (object, required) - `message.intent.fulfillment` (object, required) - `message.intent.fulfillment.start` (object, required) - `message.intent.fulfillment.end` (object, required) - `message.intent.fulfillment.type` (string, required) - `message.intent.item` (object, required) - `message.intent.item.descriptor` (object, required) - `message.intent.location` (object, required) - `message.intent.location.state` (object, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "context": { "domain": "string", "country": "string", "city": "string", "action": "string", "timestamp": "string", "core_version": "string", "consumer_id": "string", "consumer_uri": "string", "provider_id": "string", "provider_uri": "string", "transaction_id": "string", "message_id": "string" }, "message": { "catalog": { "descriptor": { "name": "string", "images": "string", "flag": "boolean", "short_desc": "string", "long_desc": "string" }, "providers": "array" } } } ``` --- # Search `POST /v1/search` Searches PM-JAY empanelled facilities. Beckn `search` action; results arrive at `on_search`. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/v1/search \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2004:85112", "country": "IND", "city": "std:011", "action": "search", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu.abdm.gov.in/aarogyasetu/api/v3/app/api/hem", "message_id": "<GENERATED>", "timestamp": "<ISO_8601_TIMESTAMP>", "transaction_id": "<GENERATED>" }, "message": { "intent": { "fulfillment": { "start": { "time": { "timestamp": "2022-07-22T13:21:41" } }, "end": { "time": { "timestamp": "2022-07-22T23:59:59" } }, "type": "PMJAYHEM" }, "item": { "descriptor": { "code": "PMJAY", "name": "<NAME>", "flag": false } }, "location": { "state": { "name": "<NAME>", "code": "27" } } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.message_id` (string, required) - `context.timestamp` (string, required) - `context.transaction_id` (string, required) - `message` (object, required) - `message.intent` (object, required) - `message.intent.fulfillment` (object, required) - `message.intent.fulfillment.start` (object, required) - `message.intent.fulfillment.end` (object, required) - `message.intent.fulfillment.type` (string, required) - `message.intent.item` (object, required) - `message.intent.item.descriptor` (object, required) - `message.intent.location` (object, required) - `message.intent.location.state` (object, required) ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors --- # search-doctor-by-id `GET /health/service/doctor/search/{abhaNumber}` Returns a doctor's registry profile by their ABHA number: registration, qualifications, system of medicine and experience. ```bash curl --request GET \ --url https://phrsbx.abdm.gov.in/health/service/doctor/search/{abhaNumber} \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `abhaNumber` (string, required): Passed as a path segment. ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "doctorName": "Anshul Atul Siddhamshettiwar", "healthIdNumber": "<ABHA_NUMBER>", "mobileOfficial": "<MOBILE>", "emailOfficial": "<EMAIL>", "gender": "Male", "registrationNumber": "1234567890", "systemOfMedicine": "Modern Medicine", "courseName": "MBBS - Bachelor of Medicine and Bachelor of Surgery", "internationalDegree": " test 12345", "workExperienceInYear": "5", "facilityDetails": [ { "facilityId": "IN2710004268", "facilityName": "Manish Test 21 Aug", "facilityAddress": "Test 123456 Pune Maharashtra 412115", "facilityContact": "<MOBILE>", "designationWithFacility": "Sr. Doctor", "distanceInKm": "12.18" }, { "facilityId": "IN2710004269", "facilityName": "Test bhavya <REDACTED_ID>", "facilityAddress": "test 123r", "facilityContact": null, "designationWithFacility": "Sr. Doctor", "distanceInKm": "0" } ], "languages": [ " Bengali " ] } ``` --- # Search Facilities Within Radius `POST /health/service/facility/geo-location/search-within-radius` The same facility-radius search as `phr_services_search_facilities_within_radius` in this file. Request and response are identical. NHA's Postman collection recorded this as a separate request against a second route, without the `/api` prefix the other route carries, so it is kept here as a separate operation rather than merged away. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/health/service/facility/geo-location/search-within-radius \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "abdmSoftware": "0", "centerLat": "11.9601971", "centerLon": "79.812865", "facilityOwnership": "", "hospitalSpecialityType": "", "radiusInKm": "50", "from": "0", "size": "100", "speciality": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `abdmSoftware` (string, required) - `centerLat` (string, required) - `centerLon` (string, required) - `facilityOwnership` (string, required) - `hospitalSpecialityType` (string, required) - `radiusInKm` (string, required) - `from` (string, required) - `size` (string, required) - `speciality` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "searchCountTotal": 9887, "recordList": [ { "mobile_no": "<MOBILE>", "abdm_software": null, "pincode": "<PIN_CODE>", "facility_type": "40", "sub_district": "4192", "book_app_url": "", "facility_website": "", "geolocation": "18.<REDACTED_ID>,73.<REDACTED_ID>", "district": "490", "address2": "<ADDRESS>", "state": "27", "address1": "<ADDRESS>", "facility_subtype_other": null, "facility_name": "Test bhavya <REDACTED_ID>", "facility_ownership": "P", "facility_email": "", "system_of_medicine": "D,M,A,UN,P", "owner_subtype": "", "landline_no": "", "fac_unique_id": "IN2710004269", "alternate_id": "IN2710004269", "distances": "0", "speciality": [ "cardiology", "anorectalcareclinic", "... 12 more of the same shape" ], "systemOfMedicine": [ { "id": "D", "value": "Dentistry" }, { "id": "M", "value": "Modern Medicine(Allopathy)" }, "... 3 more of the same shape" ] }, { "mobile_no": "<MOBILE>", "abdm_software": "1", "pincode": "<PIN_CODE>", "facility_type": "39", "sub_district": "4194", "book_app_url": null, "facility_website": "", "geolocation": "18.5615627,73.9079515", "district": "490", "address2": "<ADDRESS>", "state": "27", "address1": "<ADDRESS>", "facility_subtype_other": null, "facility_name": "Mentell hospital", "facility_ownership": "P", "facility_email": "<EMAIL>", "system_of_medicine": "M", "owner_subtype": "P", "landline_no": "", "fac_unique_id": "IN2710001975", "alternate_id": "IN2710001975", "distances": "4.79", "speciality": null, "systemOfMedicine": [ { "id": "M", "value": "Modern Medicine(Allopathy)" } ] }, "... 98 more of the same shape" ] } ``` --- # Search Facilities Within Radius `POST /api/health/service/facility/geo-location/search-within-radius` Finds health facilities within a radius of a point, filtered by ownership, speciality and facility type, with paging. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/api/health/service/facility/geo-location/search-within-radius \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "abdmSoftware": "0", "centerLat": "11.9601971", "centerLon": "79.812865", "facilityOwnership": "", "hospitalSpecialityType": "", "radiusInKm": "50", "from": "0", "size": "100", "speciality": "" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `abdmSoftware` (string, required) - `centerLat` (string, required) - `centerLon` (string, required) - `facilityOwnership` (string, required) - `hospitalSpecialityType` (string, required) - `radiusInKm` (string, required) - `from` (string, required) - `size` (string, required) - `speciality` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "searchCountTotal": 9887, "recordList": [ { "mobile_no": "<MOBILE>", "abdm_software": null, "pincode": "<PIN_CODE>", "facility_type": "40", "sub_district": "4192", "book_app_url": "", "facility_website": "", "geolocation": "18.<REDACTED_ID>,73.<REDACTED_ID>", "district": "490", "address2": "<ADDRESS>", "state": "27", "address1": "<ADDRESS>", "facility_subtype_other": null, "facility_name": "Test bhavya <REDACTED_ID>", "facility_ownership": "P", "facility_email": "", "system_of_medicine": "D,M,A,UN,P", "owner_subtype": "", "landline_no": "", "fac_unique_id": "IN2710004269", "alternate_id": "IN2710004269", "distances": "0", "speciality": [ "cardiology", "anorectalcareclinic", "... 12 more of the same shape" ], "systemOfMedicine": [ { "id": "D", "value": "Dentistry" }, { "id": "M", "value": "Modern Medicine(Allopathy)" }, "... 3 more of the same shape" ] }, { "mobile_no": "<MOBILE>", "abdm_software": "1", "pincode": "<PIN_CODE>", "facility_type": "39", "sub_district": "4194", "book_app_url": null, "facility_website": "", "geolocation": "18.5615627,73.9079515", "district": "490", "address2": "<ADDRESS>", "state": "27", "address1": "<ADDRESS>", "facility_subtype_other": null, "facility_name": "Mentell hospital", "facility_ownership": "P", "facility_email": "<EMAIL>", "system_of_medicine": "M", "owner_subtype": "P", "landline_no": "", "fac_unique_id": "IN2710001975", "alternate_id": "IN2710001975", "distances": "4.79", "speciality": null, "systemOfMedicine": [ { "id": "M", "value": "Modern Medicine(Allopathy)" } ] }, "... 98 more of the same shape" ] } ``` --- # search `POST /nhcx/search` Searches a payer's records for a member's policy through the National Health Claims Exchange. The result arrives at `on_submit`. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/nhcx/search \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "memberId": "PZ2Q9UZHM", "payerId": "1518@hcx", "productId": "100155", "productName": "PMJAY/HP/S/G", "processingId": "1518@hcx" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `memberId` (string, required) - `payerId` (string, required) - `productId` (string, required) - `productName` (string, required) - `processingId` (string, required) ## Responses - `200`: Example values, scrubbed. - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "timestamp": "12/06/2026 20:59:22", "api_call_id": "<TXN_ID>", "correlation_id": "<TXN_ID>", "result": { "sender_code": "NAS_001@hcx", "recipient_code": "1518@hcx", "entity_type": "preauth", "protocol_status": "request.queued" }, "error": null } ``` --- # STEP 1 - search `POST /ambulance-booking/search` Searches for ambulance services. Beckn `search` action; results arrive at `on_search`. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/ambulance-booking/search \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2008:86909", "country": "IND", "city": "std:011", "action": "search", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu-sandbox.abdm.gov.in/aarogyasetu/api/v3/app/api/ambulance-booking", "message_id": "<TXN_ID>", "timestamp": "2026-06-12T10:00:00", "transaction_id": "<TXN_ID>" }, "message": { "intent": { "category": { "descriptor": { "code": "ALL", "name": "<NAME>" } }, "fulfillment": { "type": "EMERGENCY", "start": { "time": { "timestamp": "2026-06-12T10:00:00" } }, "end": { "time": { "timestamp": "2026-06-12T23:59:59" } } }, "locations": [ { "descriptor": { "code": "SOURCE", "name": "<NAME>" }, "gps": "12.423423,77.325647", "address": "<ADDRESS>" } ], "item": { "descriptor": { "code": "AMBULANCE", "name": "<NAME>" } } } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.message_id` (string, required) - `context.timestamp` (string, required) - `context.transaction_id` (string, required) - `message` (object, required) - `message.intent` (object, required) - `message.intent.category` (object, required) - `message.intent.category.descriptor` (object, required) - `message.intent.fulfillment` (object, required) - `message.intent.fulfillment.type` (string, required) - `message.intent.fulfillment.start` (object, required) - `message.intent.fulfillment.end` (object, required) - `message.intent.locations` (object[], required) - `message.intent.locations.descriptor` (object, required) - `message.intent.locations.gps` (string, required) - `message.intent.locations.address` (string, required) - `message.intent.item` (object, required) - `message.intent.item.descriptor` (object, required) ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors --- # STEP 2 - on_search `POST /ambulance-booking/on_search` Callback carrying the ambulance providers and services that matched a search. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/ambulance-booking/on_search \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2008:86909", "country": "IND", "city": "std:011", "action": "on_search", "timestamp": "2026-06-12T10:00:00", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu-sandbox.abdm.gov.in/aarogyasetu/api/v3/app/api/ambulance-booking", "transaction_id": "<TXN_ID>", "message_id": "<TXN_ID>" }, "message": {} }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.timestamp` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.transaction_id` (string, required) - `context.message_id` (string, required) - `message` (object, required) ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors --- # STEP 3 - init `POST /ambulance-booking/init` Initialises an ambulance booking for the service selected from search results. Beckn `init` action; the reply arrives at `on_init`. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/ambulance-booking/init \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2008:86909", "country": "IND", "city": "std:011", "action": "init", "timestamp": "2026-06-12T10:00:00", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu-sandbox.abdm.gov.in/aarogyasetu/api/v3/app/api/ambulance-booking", "provider_id": "nha.hspa", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1/hspa/ambulance", "transaction_id": "<TXN_ID>", "message_id": "<TXN_ID>" }, "message": { "order": { "id": "<O_R_D_E_R_I_D>" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.timestamp` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.provider_id` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `context.message_id` (string, required) - `message` (object, required) - `message.order` (object, required) - `message.order.id` (string, required) ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors --- # STEP 4 - on_init `POST /ambulance-booking/on_init` Callback carrying the provider's reply to an ambulance booking `init`: the quote and the terms to confirm. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/ambulance-booking/on_init \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "context": { "domain": "nic2008:86909", "country": "IND", "city": "std:011", "action": "on_init", "timestamp": "2026-06-12T10:00:00", "core_version": "0.7.1", "consumer_id": "aarogyaSetu.eua", "consumer_uri": "https://aarogyasetu-sandbox.abdm.gov.in/aarogyasetu/api/v3/app/api/ambulance-booking", "provider_id": "nha.hspa", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1/hspa/ambulance", "transaction_id": "<TXN_ID>", "message_id": "<TXN_ID>" }, "message": { "order": { "id": "<O_R_D_E_R_I_D>", "state": "INITIALIZED" } } }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Body - `context` (object, required) - `context.domain` (string, required) - `context.country` (string, required) - `context.city` (string, required) - `context.action` (string, required) - `context.timestamp` (string, required) - `context.core_version` (string, required) - `context.consumer_id` (string, required) - `context.consumer_uri` (string, required) - `context.provider_id` (string, required) - `context.provider_uri` (string, required) - `context.transaction_id` (string, required) - `context.message_id` (string, required) - `message` (object, required) - `message.order` (object, required) - `message.order.id` (string, required) - `message.order.state` (string, required) ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors --- # subscribe `POST /nhcx/v1/notification/subscribe` Subscribes the PHR to National Health Claims Exchange notifications. Confirmation arrives at `on_subscribe`. ```bash curl --request POST \ --url https://phrsbx.abdm.gov.in/nhcx/v1/notification/subscribe \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Responses - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors --- # update payment `PUT /scan-pay/update/payment/{id}` Records the outcome of a scan and pay payment: the amount, the transaction id and the receipt. ```bash curl --request PUT \ --url https://phrsbx.abdm.gov.in/scan-pay/update/payment/{id} \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "paymentName": "Kidney Function Test(Kft)Panel(Urea+Creat)", "orderNumber": "ORD-ABDM-123456", "transactionId": "", "counterCode": "IN0810000177", "paymentUrl": "https://payit.cc/I4321024287", "amount": "60.00" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `id` (string, required): Passed as a path segment. ## Body - `paymentName` (string, required) - `orderNumber` (string, required) - `transactionId` (string, required) - `counterCode` (string, required) - `paymentUrl` (string, required) - `amount` (string, required) ## Responses - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors --- # Update `PUT /health/service/bookmark/update/{id}` Updates the title or address of a saved place bookmark. ```bash curl --request PUT \ --url https://phrsbx.abdm.gov.in/health/service/bookmark/update/{id} \ --header 'Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>' \ --header 'Content-Type: application/json' \ --data '{ "title": "Happy Family", "address": "<ADDRESS>" }' ``` ## Authorization - `Authorization` (bearer token, required): The access token from `POST /api/hiecm/gateway/v3/sessions`. ## Path parameters - `id` (string, required): Passed as a path segment. ## Body - `title` (string, required) - `address` (string, required) ## Responses - `200`: Example values, scrubbed. - `400`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `401`: Example values, scrubbed. See Everything returns 401: /docs/hiecm/v3/troubleshooting/everything-returns-401 - `404`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors - `500`: Example values, scrubbed. See Error codes for this module: /docs/hiecm/v3/api/phr-services/errors Shape of the 200 response, generated from the schema. The values are placeholders, not a captured response: ```json { "id": 245, "abhaAddress": "<ABHA_ADDRESS>", "title": "Happy Family", "address": "<ADDRESS>", "latitude": null, "longitude": null, "isDeleted": false, "createdTime": "2026-05-29T15:38:17.982575", "updatedTime": "2026-05-29T15:41:49.399205251" } ``` --- # PHR application services errors Seeing a symptom rather than a code? Start at [Troubleshooting](/docs/hiecm/v3/troubleshooting/). The PHR application services specification records no error code yet. That is a gap in the specification, not a promise that this module cannot fail. Every code above is recorded in the specification that owns it. The aggregated list across modules is at [error codes](/docs/hiecm/v3/reference/error-codes). [Next Still stuck? Ask for help Where to file what you hit, so the answer lands back in these pages.](/docs/support) --- # PHR application services **These are not a certification milestone.** Nothing here is required to certify as a [PHR](/docs/hiecm/v3/getting-started/glossary#phr). They are application features a PHR may offer: teleconsultation, nearby facility search, ambulance booking, blood bank search, scan and pay, PMJAY facility discovery and [NHCX](/docs/nhcx/v1) coverage lookups. They sit apart from P1 to P3 so that nothing here implies a PHR must build them. The full operation list is in the [PHR application services API reference](/reference/hiecm-phr-services). --- # Proving a callback came from ABDM ## In short - Your callback URL is a public address. Anything on the internet can post to it, and a POST arriving there tells you nothing about who sent it. - ABDM signs its callbacks. The gateway publishes the public keys at `/api/hiecm/gateway/v3/certs`, as a JSON Web Key Set, and that endpoint needs no token. - Verify every callback before your handler does any work. Pin the algorithm to `RS256` and fail closed. - Which header carries the signed token is not published. Log the headers of your first real callback and confirm it. ## Why this one matters To receive callbacks you register a URL that ABDM can reach. Reachable by ABDM means reachable by everyone, because it is an ordinary address on the public internet. The callbacks you host carry instructions about a named person's health records: a request to discover what you hold, a [consent artefact](/docs/hiecm/v3/concepts/consent) saying somebody agreed, an instruction to transfer records to a given address. A system that acts on whatever arrives will act on whatever an attacker sends. ABDM signs the callbacks it sends, and publishes the public keys that verify those signatures. You fetch the keys once, cache them, and check the signature on every callback before your handler does anything. Two different signatures The signature inside a [consent artefact](/docs/hiecm/v3/concepts/consent) is a different thing. It signs the artefact's contents and proves the artefact was not altered. The one on this page signs the delivery and proves who sent it. Verifying one does not verify the other. ## Before you start You need a callback URL registered with ABDM, and an understanding of why a 200 is not an answer, which is on [how a record travels](/docs/hiecm/v3/concepts/data-flow). You do not need an access token for this. The certificates endpoint declares no security in the specification, which is what you would expect of an endpoint whose whole job is publishing public keys. ## Fetch the key set ```bash curl --request GET \ --url https://dev.abdm.gov.in/api/hiecm/gateway/v3/certs \ --header 'REQUEST-ID: <REQUEST_ID>' \ --header 'TIMESTAMP: <TIMESTAMP>' ``` Each key carries a `kid` that identifies it, `kty: RSA`, `use: sig`, and an `alg` the specification gives as `RS256`. The `n` and `e` fields are the RSA modulus and exponent, Base64URL encoded, and some keys also carry `x5c`, a certificate chain. The same key set is discoverable through the OIDC document at `/api/hiecm/gateway/v3/.well-known/openid-configuration`, which names it in `jwks_uri`. Reading the discovery document first survives the key set moving. Cache the keys rather than fetching them per callback, and key your cache by `kid`. When a callback presents a `kid` you have not seen, refetch once before rejecting it. That is what key rotation looks like from your side. Verification is then the ordinary JWT check your library already does: signature against the key named by `kid`, algorithm pinned to `RS256`, and the expiry and issuer claims if the token carries them. ## What this documentation cannot yet tell you The header is not published The gateway specification says the key set exists and says what it is for. It does not say which header carries the signed token on an inbound callback. None of the webhook definitions in the M2 or M3 specifications declares a header or a security scheme at all. So the transport is documented and the field that carries it is not. Two things follow. Confirm the header name against the sandbox before you write the lookup, by logging the full header set of the first real callback you receive. And treat this page as unconfirmed until somebody has done that. Pin the algorithm to `RS256` when you verify, and reject `none`. A verifier that accepts whatever algorithm the token names accepts a token an attacker signed, and that is a defect in the verifier rather than in ABDM. ## How you know it worked You can fetch the certificates endpoint and get back a `keys` array whose entries carry `kid`, `kty: RSA` and `use: sig`. Then, on your own handler, both of these hold: 1. A callback carrying a valid signature is processed, and the `REQUEST-ID` matches a request you sent. 2. The same callback body, replayed with the signature altered by one character, is rejected before your handler reads the payload, and the rejection is logged. The second is the one worth writing a test for. It is the only one that fails loudly when verification is silently skipped. ## When it goes wrong **The `kid` is not in your cache.** That is key rotation. Refetch the key set once, then reject if it is still absent, rather than refetching on every callback and handing an attacker a way to make you call the gateway. **You cannot find a token on the request.** The header is not declared in any specification here, so log every header of a real callback and read what actually arrives. Do not fall back to processing unverified requests while you work it out. **Verification is skipped under load.** A handler that verifies inside a try block and continues on failure is worse than one that never verified, because it reads as safe. Fail closed. **Nothing arrives at all**, which is a different problem. See [the callback never arrives](/docs/hiecm/v3/troubleshooting/callback-never-arrives). --- # Consent Consent is the permission layer of [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm): a record moves because a patient said yes to a named system, for a named reason, over a date range, for a fixed length of time. The calls that create and read it are in the [M3 guide](/docs/hiecm/v3/api/m3). ## Two objects, not one | Object | What it is | Who creates it | Identifier | | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | ------------------- | | Consent request | The ask. It names the patient by [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) address, the reason, the record types wanted, and the date range wanted. | The [HIU](/docs/hiecm/v3/getting-started/glossary#hiu), through the gateway | Consent request id | | [Consent artefact](/docs/hiecm/v3/getting-started/glossary#consent-artefact) | The permission itself, created only if the patient grants the request. It is what a record holder checks before sending anything. | The [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm), on the patient's decision | Consent artefact id | One request can produce more than one artefact. A granted request returns the ids of the consent artefacts created against it, plural. Store the request id and every artefact id. ## Who holds what - **The patient holds the decision**, in their [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app. - **The HIE-CM holds the artefact.** As [consent manager](/docs/hiecm/v3/getting-started/glossary#consent-manager) it asks the patient, records the answer, and tells requester and record holder. - **The HIU holds an id, not a right.** It can stop working at any time. - **The [HIP](/docs/hiecm/v3/getting-started/glossary#hip) holds the check.** Before sending a record it validates that the artefact is active and that the dates asked for sit inside the dates it allows. ## The states a consent moves through ```mermaid stateDiagram-v2 [*] --> Requested: HIU raises a consent request Requested --> Granted: Patient approves Requested --> Denied: Patient refuses Requested --> Expired: Patient does not act in time Granted --> Revoked: Patient withdraws access Granted --> [*]: Validity period ends ``` There are five states, in the two sections a PHR app shows: Requests holds Requested, Denied and Expired; Approved holds Granted and Revoked. | State | What it means | What your system does | | --------- | --------------------------------------------------------------------- | ---------------------------------------------------------------------- | | Requested | The patient has not acted yet. | Wait. Poll the request status if you need to show progress. | | Granted | The patient approved, and set how long the access lasts. | Fetch the artefact ids, then request the data. | | Denied | The patient refused. | Stop. There is no partial result and no retry that changes the answer. | | Expired | The patient did not act inside the window the HIU set on the request. | Raise a new request if the clinical need is still there. | | Revoked | The patient withdrew a consent they had already granted. | Stop fetching under that artefact from that moment. | Two clocks run here. The **request window** is how long the patient has to answer, set by the HIU, and running out produces Expired. The **consent validity period** is how long access lasts once granted, set by the patient as they grant, with a defined expiry date and time. Neither is the **date range**, which says which records are in scope by when the care happened: a consent granted today can cover records from 2019. ## What the patient sees, and can change A consent request must display the requesting HIU, the purpose of data access, the data types requested, the date range, the consent validity period and the request status. Where permitted, the patient may modify four of those before approving: access duration, record date range, data categories and validity period. The consent you get back can be narrower than the one you asked for, so read the artefact. ## The five things a PHR app must let a person do Consent is granted by a person, and the PHR app is where they do it. NHA sets a floor of five capabilities, and an app missing one leaves a person able to give access they cannot inspect, change or withdraw. 1. **See the request**, with the HIU asking, the purpose, the record types, the date range of records, how long the consent would last, and its status. 2. **Change it before allowing it**, where the request permits: the access duration, the record date range, the categories shared, and the validity period. This is the one most often left out, and the one that turns a consent screen into a negotiation rather than a demand. 3. **Allow or refuse it.** NHA's own flow names three outcomes, not two: approve, reject and ignore. An ignored request expires on the requester's window, and the interface has to show that state. 4. **See what is already allowed**, so the person can tell which organisations hold access right now. A list of past decisions is not the same thing. 5. **Take it back** at any time. Two things follow: the status updates at the consent manager, and sharing under that consent stops immediately, not at the end of the period. ## Purpose of use codes Why you want the records. See [purpose of use](/docs/hiecm/v3/getting-started/glossary#purpose-of-use). These codes are a subset of the HL7 v3 PurposeOfUse value set at [terminology.hl7.org](http://terminology.hl7.org/ValueSet/v3-PurposeOfUse). | Code | Display | | --------- | ------------------------------------ | | `CAREMGT` | Care Management | | `BTG` | Break the Glass | | `PUBHLTH` | Public Health | | `HPAYMT` | Healthcare Payment | | `DSRCH` | Disease Specific Healthcare Research | | `PATRQT` | Self-Requested | The source table prints the header row and the `CAREMGT` row twice. There are six codes. The patient reads this code. ## Health information types What kind of record you are asking for. See [HI type](/docs/hiecm/v3/getting-started/glossary#hi-type). M3 supports these types as of writing: | Code | Display | | ---------------------- | ------------------- | | `Prescription` | Prescription | | `DiagnosticReport` | Diagnostic Report | | `OPConsultation` | OP Consultation | | `DischargeSummary` | Discharge Summary | | `ImmunizationRecord` | Immunization Record | | `HealthDocumentRecord` | Record artifact | | `WellnessRecord` | Wellness Record | The M2 error message for an invalid HI type lists these seven and adds `Invoice`. The two disagree by one value, so check the swagger before you send `Invoice`. What each type carries as a [FHIR](/docs/hiecm/v3/getting-started/glossary#fhir) bundle is on [FHIR and health record formats](/docs/hiecm/v3/concepts/fhir). ## Expiry and revocation **Expiry is predictable.** The artefact carries an end, so you can fetch before it arrives. Past it, the record holder rejects the request: `ABDM-1061` for an expired consent artefact, `ABDM-1112` for an artefact id that is invalid or already expired. **Revocation is not.** The patient can withdraw at any time, including after you have read the data, and future data sharing under that consent must stop immediately. So treat every fetch as a fresh permission check, and handle a mid flow revocation. A consent that was live when you sent the health information request can be dead when the record holder validates it. That returns `ABDM-1062`, consent not granted. Decide your retention policy for data you already hold. Sharing stops. What to do with what you already received is not documented yet. Read every code with the message the gateway returns. The error table lists `ABDM-1061` and `ABDM-1062` against two different messages each, so the code alone does not identify the failure. ## Consent without a person tapping approve An auto approval policy works like this: the patient authorises the app once, the app registers the policy with the HIE-CM, and later requests under that policy are granted immediately. The patient can disable it, after which each record needs its own request again. This changes who taps the button, not the model. An artefact is still created, still carries an expiry, and can still be revoked. Detail is on [PHR applications](/docs/hiecm/v3/concepts/phr). ## Where this is implemented - [Hospital, lab and pharmacy systems](/docs/hiecm/v3/concepts/hip-hiu), the facility taking each role. - [The ABDM gateway](/docs/hiecm/v3/concepts/gateway), which holds every artefact here. - [M3, consent and fetching](/docs/hiecm/v3/api/m3), the requesting side. - [M2, linking and sharing](/docs/hiecm/v3/api/m2), what a record holder validates. - [How a record travels](/docs/hiecm/v3/concepts/data-flow), what happens next. --- # How a record travels In [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) the request goes through the [gateway](/docs/hiecm/v3/getting-started/glossary#gateway) and the [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm), because that is where consent is checked and routing lives. The record itself goes straight from the system that holds it to a URL the requester nominated, encrypted so only the requester can open it. ## The two sides | Role | Who takes it | What it does here | Milestone | | -------------------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | | [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) | The organisation or citizen asking | Holds a granted [consent artefact](/docs/hiecm/v3/getting-started/glossary#consent-artefact), asks for the records it covers, receives them and decrypts them | [M3](/docs/hiecm/v3/api/m3) | | [HIP](/docs/hiecm/v3/getting-started/glossary#hip) | The citizen or facility holding the record | Holds the records, validates the consent, packages, encrypts, signs and pushes | [M2](/docs/hiecm/v3/api/m2) | The HIE-CM sits between them for the request and the notifications, and never sees a record. ## The whole path ```mermaid sequenceDiagram autonumber participant U as HIU participant CM as HIE-CM gateway participant P as HIP Note over U: Generate a short term key pair and a 32 byte nonce U->>CM: Health information request Note over U,CM: Consent artefact id, date range, data push URL, HIU public key, HIU nonce CM->>CM: Generate a transaction id CM-->>U: Transaction id CM->>P: Forward the request with the transaction id P->>P: Validate consent status, date range, encryption parameters P->>P: Assemble the FHIR bundles Note over P: Generate a key pair and nonce, derive the session key P->>P: Encrypt, then sign with its long term private key P->>U: Push the encrypted data to the data push URL Note over P,U: Transaction id, HIP public key, HIP nonce, encrypted bundles P->>CM: health-information/notify, transfer complete U->>U: Derive the same session key, decrypt U->>CM: health-information/notify, success or failure ``` ## Stage 1: the request The HIU sends a health information request through the gateway, quoting a consent artefact the patient granted. It carries four things. - **The consent id**, the artefact that authorises the request. - **The data push URL**, where the HIP sends the records. It may differ from the HIU's registered gateway URL, which improves privacy and anonymity. - **The date and time range** of records wanted. - **The encryption parameters**: the HIU's public key and its nonce. The HIE-CM generates a transaction id and gives it to both sides, which is how you correlate a push arriving later with a request you sent earlier. ## Stage 2: validation, then transfer Before the HIP retrieves anything it runs three checks. 1. **The consent id is valid and active.** Not expired, not paused, not revoked. 2. **The requested date and time range falls inside the range the consent artefact permits.** A wider window is refused, not trimmed. 3. **The encryption parameters are correct and compatible.** Only then does it package the records as [FHIR](/docs/hiecm/v3/getting-started/glossary#fhir) bundles, encrypt, sign with its long term private key, and send with the transaction id to the data push URL. Two failures land here: `ABDM-1062`, consent not granted, and `ABDM-1063`, date range given is invalid. Both codes also appear against a linking message, so read the code with the message. ## Stage 3: the notifications that close it Both sides call `health-information/notify`: the HIP to say the data was transmitted, the HIU to report success or failure on its side. Neither carries the record. They carry the fact that a transfer happened, which is what makes the exchange auditable for the patient. ## Timing and size | Constraint | Rule | | ---------------- | ---------------------------------------------------------------------------------------- | | Timeout | 20 minutes from the start of the request | | Large datasets | Split into multiple parts, for example CT or MRI images running to hundreds of megabytes | | Very large files | Stream rather than sending one payload | Treat retrieval and encryption as a background job, not work inside a web request. ## The encryption The scheme is [Elliptic Curve Diffie-Hellman](/docs/hiecm/v3/getting-started/glossary#ecdh) key exchange on Curve25519, with AES-GCM for the payload and HKDF to derive the session key. Only the HIU holding valid consent can read the data, and the design gives perfect forward secrecy: key material compromised later does not expose data exchanged earlier. ### Who holds which key | Key material | Generated by | Where it goes | | ------------------------------------- | ------------------------------ | -------------------------------------------------- | | Short term private key, DHSK(U) | HIU | Never leaves the HIU | | Short term public key, DHPK(U) | HIU | Sent with the request | | Nonce, RAND(U), 32 bytes | HIU | Sent with the request | | Short term private key, DHSK(P) | HIP | Never leaves the HIP | | Short term public key, DHPK(P) | HIP | Sent with the encrypted data | | Nonce, RAND(P), 32 bytes | HIP | Sent with the encrypted data | | Shared key, DHK(U,P) | Computed independently by both | Never transmitted | | Session key, SK(U,P), 256 bit AES-GCM | Derived independently by both | Never transmitted | | Long term private key | HIP | Never leaves the HIP. Signs the encrypted payload. | A new key pair per exchange is what buys forward secrecy. ### What the HIP does, step by step Six steps, once consent has validated. 1. Generate a key pair, DHSK(P) and DHPK(P), in the group the HIU specified. 2. Generate a 32 byte random value, RAND(P). 3. Compute the shared key DHK(U,P) from the HIU's public key DHPK(U) and the HIP's own private key DHSK(P). 4. Derive the salt and IV by XOR of RAND(P) and RAND(U). The first 20 bytes are the salt for HKDF, the last 12 bytes the IV. 5. Compute a 256 bit AES-GCM session key SK(U,P) with HKDF, from the shared key and that salt. 6. Encrypt the data with that key and that IV. The HIP then sends DHPK(P), RAND(P) and the encrypted data. The HIU derives the same session key from its own private key DHSK(U) and the HIP's public key DHPK(P), with salt and IV from the same XOR. Build the shared key from the HIU's public key and the HIP's private key. That is the pairing that makes the Diffie-Hellman exchange work. ### Do not write this yourself Two reference implementations exist. Fidelius, at [github.com/sukreet/fidelius](https://github.com/sukreet/fidelius), and the Fidelius CLI, which is Java, with worked examples for Node.js, Python, Ruby and PHP at [github.com/mgrmtech/fidelius-cli](https://github.com/mgrmtech/fidelius-cli/tree/main/examples) that run the binary as a subprocess. A webinar covers the CLI from both sides, at [youtu.be/rSir2gbkEmk](https://youtu.be/rSir2gbkEmk?t=9232) from 2:33:52. ## Where this is implemented - [Hospital, lab and pharmacy systems](/docs/hiecm/v3/concepts/hip-hiu), which side the facility you act for is on. - [M2, linking and sharing](/docs/hiecm/v3/api/m2), the sending side. - [M3, consent and fetching](/docs/hiecm/v3/api/m3), the receiving side. - [Consent](/docs/hiecm/v3/concepts/consent), the artefact this flow depends on. - [FHIR and health record formats](/docs/hiecm/v3/concepts/fhir), what is inside the payload. --- # Encryption Several fields in [M1](/docs/hiecm/v3/api/m1) do not carry the value you started with. They carry that value encrypted against the ABDM public key. When an API page shows a placeholder such as `<RSA_ENCRYPTED_AADHAAR_NUMBER>`, the field name tells you what the value is and the placeholder tells you it must already be encrypted. ## What must be encrypted Six kinds of value never travel raw in an M1 request body. | Value | Where it appears | | ---------------------------------------------------------------------------- | ------------------------------------ | | Aadhaar number | Enrolment and login by Aadhaar | | ABHA number | Login and search by ABHA number | | Mobile number | Login, search and mobile update | | Email address | Email verification | | One time password ([OTP](/docs/hiecm/v3/getting-started/glossary#otp)) value | Every call that verifies a challenge | | Password | Password based login | Each is encrypted with RSA using the ABDM public certificate, and the base64 of the ciphertext goes in the field. ## What shape the plaintext must be The service validates the plaintext after it decrypts, so the shape you encrypt matters and a wrong shape is rejected as though the value were wrong. | Value | Plaintext shape | Example | | -------------- | ------------------------------------------ | ------------------- | | ABHA number | 14 digits with dashes, `NN-NNNN-NNNN-NNNN` | `91-1234-5678-9015` | | Aadhaar number | 12 digits, no spaces | `999999990019` | | Mobile number | 10 digits, no country code and no `+` | `9876543210` | | OTP value | The digits as sent, nothing else | `123456` | The ABHA number is the one that catches people, because the number is printed and stored both ways. Encrypting the 14 bare digits is rejected: a login OTP request sent that way on the sandbox on 11 September 2026 returned `400 {"loginId": "LoginId is invalid"}`, and the same number encrypted as `91-1234-5678-9015` passed validation and went on to look the account up. Strip the dashes for display if you like, but put them back before you encrypt. Aadhaar, mobile and OTP shapes are as NHA's validation patterns describe them and have not been failed deliberately from here. ## How the model works ```mermaid graph LR A["Aadhaar or mobile number<br/>inside your system"] -->|RSA with the ABDM public key| B["Encrypted value"] B -->|sent as the field value| C["ABDM"] C -->|the ABDM private key| D["Plain value, inside ABDM"] ``` We publish the public half of a key pair. You encrypt with it. Only our private half can decrypt. Your system never holds a secret to do this, only the current certificate. There is nothing ABDM specific in the mechanics. Your platform's standard RSA library does the work. The two things to confirm are which key you are using and which padding. ## Where to do it **Encrypt inside your own system, against the published ABDM public key.** This is the production path, and it is the only one that keeps the guarantee the encryption exists to provide. A hosted helper that encrypts a value for you also exists, along with two third party encryption websites. Those exist so someone can try a flow by hand. They are not a production path. The reason is worth stating plainly. To use the helper you send the raw Aadhaar or mobile number to a remote endpoint. That hands the value to a party which has no reason to hold it, which is the thing the encryption exists to prevent. With the third party websites it is worse: a patient identifier leaves ABDM entirely. The [encrypt value endpoint](/docs/hiecm/v3/api/m1) documents the helper for completeness. Do not build against it. ## Fetching the public key M1 has a `public/certificate` API for fetching the public key, listed again under developer utilities. Its URL, headers and response shape are not yet published. Take them from the sandbox documentation. ## Where to go next - [Gateway](/docs/hiecm/v3/concepts/gateway) for the session token every call needs, including the key and helper endpoints. - [M1 user journeys](/docs/hiecm/v3/milestones/m1), where the encrypted identifier appears in the search and login steps. --- # FHIR and health record formats Every health record that moves inside [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) travels as a [FHIR](/docs/hiecm/v3/getting-started/glossary#fhir) bundle, not a PDF in an envelope of your own design and not your database rows. This page gives the version, the profiles, the bundle shape and how to validate one; the packaging detail is in the [M2 guide](/docs/hiecm/v3/api/m2). ## R4, with Indian profiles ABDM uses FHIR release 4. Base FHIR is loose: it says a `MedicationRequest` exists, not which fields an Indian prescription must fill. That second layer is a profile, and for ABDM the profiles are published by the National Resource Centre for EHR Standards, NRCES, at [nrces.in/ndhm/fhir/r4](https://nrces.in/ndhm/fhir/r4/index.html). "ABDM compliant FHIR" means R4 conforming to those profiles. Read the NRCES implementation guide for field level questions. It is not restated here. ## Two ways to build any record | Shape | What it is | When you use it | | ----------------- | ---------------------------------------------------------------------- | -------------------------------------------------------- | | Simple bundle | A FHIR bundle wrapping a PDF or image attachment that holds the detail | Your source document is a scan, a signed PDF or an image | | Structured bundle | A FHIR bundle with coded health information in FHIR resources | Your system holds the data as fields, and can code it | Both are compliant. A structured bundle is more useful to the receiver, because it can be searched rather than only displayed. ## The record types There are eight record types. Implementing all of them is mandatory for an [HMIS](/docs/hiecm/v3/getting-started/glossary#hmis). | Record type | What it holds | [HI type](/docs/hiecm/v3/getting-started/glossary#hi-type) code | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | Diagnostic Report Record | Radiology and laboratory reports | `DiagnosticReport` | | Discharge Summary Record | The discharge summary for the ABDM health data set | `DischargeSummary` | | Health Document Record | Unstructured historical records, usually uploaded by patients through a health locker | `HealthDocumentRecord` | | Immunization Record | Immunisations, vaccine certificates and next dose recommendations | `ImmunizationRecord` | | OP Consult Record | Outpatient notes: examinations, procedures, medications and clinical advice | `OPConsultation` | | Prescription Record | Medication advice, following Pharmacy Council of India guidelines | `Prescription` | | Wellness Record | Vitals, physical examination and general health data, often captured in a [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app | `WellnessRecord` | | Invoice Record | Pharmacy invoices, consultation invoices and other billing | `Invoice` | The names come from M2, the codes from the M3 HI type table and the M2 error message for an invalid HI type. The two lists are not published as one table; they are paired here by name, one to one. Two mismatches. The M3 table displays `HealthDocumentRecord` as "Record artifact" rather than as a health document, and omits `Invoice`, which appears only in the M2 error message. Check the swagger before you send `Invoice` in a consent request. ## Which resources a record carries The reference service on the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) side supports these resources inside a bundle. - **Clinical content:** `Observation`, `Condition`, `MedicationRequest`, `DocumentReference`, `DiagnosticReport`, `Procedure`. - **Context and reference entities:** `Medication`, `Practitioner`, `Patient`, `Organization`, `Encounter`. That is the union across record types, not a mapping. Which resources belong to which record type is not documented here. The NRCES profile for each type is the authority. ## The bundle shape Every record is a `Bundle` of `type: document`, and the first entry must be a `Composition`. ```json { "resourceType": "Bundle", "id": "bundle01", "timestamp": "2020-01-01T15:32:26.605+05:30", "type": "document", "entry": [ { "fullUrl": "Composition/1", "resource": { "resourceType": "Composition", "id": "1", "status": "final", "type": { "coding": [ { "system": "https://ndhm.gov.in/sct", "code": "440545006", "display": "Prescription record" } ] } } } ]} ``` That is the skeleton. The full sample, with the Organization, the Encounter and the section entries, is on [M2 use cases](/reference/hiecm-m2). ### Why the Composition comes first A bundle on its own is a bag of resources. The Composition turns it into a document: what this is, who it is about, who wrote it, who attests to it, and which resources make up its sections. Without it, a receiving system has a `MedicationRequest` and no idea whether it belongs to a prescription, a discharge summary or a draft. `Composition.type` carries the SNOMED CT code that answers "what is this". Two are documented: `440545006` for a prescription record and `721981007` for a diagnostic report. The rest have their own codes in the NRCES profiles. ### The rules that fail validation | Field | Rule | | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `id` | Unique per bundle, and resolvable inside your own system for traceability | | `timestamp` | The time the document was issued | | `identifier` | Traces the document back to your system | | `type` | Must be `document` | | `meta.versionId` | Set it on the bundle, so updates can be checked against the latest version | | `entry[].fullUrl` | A logical URL of the form `resource-type/id`, resolvable inside the bundle. Never an absolute URL. | | `Composition.attester.party` | References an `Organization` whose `identifier.value` is the facility's [HIP](/docs/hiecm/v3/getting-started/glossary#hip) id as registered in the facility registry. Mode is `official`. | | `Composition.section.entry[]` | Top level resources only. Referenced resources such as Patient, Encounter and Practitioner belong in the bundle, not in the section entries. | The attester rule has an environment trap. The organization identifier system is the ABDM facility registry at [nhpr.abdm.gov.in](https://nhpr.abdm.gov.in/nhpr/v4/home) for production and [hspsbx.abdm.gov.in](https://hspsbx.abdm.gov.in/nhpr/v4/home) for sandbox. A bundle that passes in sandbox with the sandbox value is not right in production. One more thing to watch. `Composition.type.coding.system` is `https://ndhm.gov.in/sct` in the sample above, while `section.code.coding.system` in the same sample is `https://affinitydomain.in/sct`. The two differ in the sample itself. Take the system values from the NRCES profile, not from the sample. ## Validate before you ship Run this procedure locally. You need JDK 8 or higher. 1. Create a folder and download the FHIR validator CLI, version 6.2.1, from [the HAPI FHIR core release](https://github.com/hapifhir/org.hl7.fhir.core/releases/download/6.2.1/validator_cli.jar). Save `validator_cli.jar` into it. 2. Get a bundle to test: one your own system produced, or an NRCES example from [nrces.in/ndhm/fhir/r4](https://nrces.in/ndhm/fhir/r4/index.html), switching to the JSON tab to download it. 3. Run the validator from that folder: ```shell java -jar validator_cli.jar <YOUR_BUNDLE_FILENAME>.json -ig https://nrces.in/ndhm/fhir/r4 ``` It checks structural correctness, conformance to the NRCES profiles, and required fields and constraints. Editing an NRCES example that already validates towards your own data is faster than starting from an empty file. ## Where this is implemented - [M2 use cases](/reference/hiecm-m2), the full bundle sample and validation in context. - [How a record travels](/docs/hiecm/v3/concepts/data-flow), what happens to the bundle after you build it. - [Care contexts and linking](/docs/hiecm/v3/concepts/linking), how records are grouped and made findable. - [Consent](/docs/hiecm/v3/concepts/consent), where the HI type codes above are chosen and read. --- # The ABDM gateway The gateway is the routing layer for [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm). You never call a hospital, a lab or a [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app directly. The answer to a call arrives later at an endpoint you expose, and the gateway issues the access token every other call carries. ## Gateway and HIE-CM are not the same thing [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) is the service: patient identity, care context links and consent. Its four modules and who builds which are on [Integration milestones](/docs/hiecm/v3/milestones). The gateway is its front door. It authenticates you, validates your headers, and routes each call. Your consent request goes to `/api/hiecm/consent/v3/request/init` on the gateway host, and the gateway puts it in front of the patient's consent manager. ## HIE-CM is data blind It never holds a patient's health record, only identifiers, metadata about where records live, and consent artefacts. Once consent exists the record goes straight from the system that holds it to the system that asked, encrypted. Your system keeps the data. HIE-CM keeps the permission. ## Nothing goes participant to participant Every request is addressed to the gateway, which forwards it. Three things follow. - **You get an acknowledgement, not an answer.** In the [M3](/docs/hiecm/v3/getting-started/glossary#m3) consent flow the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) asks, the HIE-CM acknowledges with a consent request id, and the patient's decision comes back later. Each call's page in the [API reference](/docs/hiecm/v3/api) names the callback it produces. - **You have to be reachable.** Half of [M2](/docs/hiecm/v3/getting-started/glossary#m2) is endpoints the gateway calls on your system. A [HIP](/docs/hiecm/v3/getting-started/glossary#hip) it cannot reach fails on someone else's logs, as `ABDM-1028 HIP is unavailable`. - **Order is enforced.** The M2 error list carries `ABDM-2406 Invalid API sequence flow, please follow logical flow`. One exception. In the health information flow the HIU supplies a data push URL, and the HIP encrypts the records and pushes them there. That URL may differ from the HIU's registered gateway URL, to improve privacy. The permission came through the gateway. The bytes do not. ## What moves through it | Module | What the gateway routes | Reference | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | | [M1](/docs/hiecm/v3/api/m1) | Session tokens, and the calls that create and authenticate an ABHA identity | [M1 API reference](/reference/hiecm-m1) | | [M2](/docs/hiecm/v3/api/m2) | [Discovery](/docs/hiecm/v3/getting-started/glossary#discovery), care context linking, health information requests to a HIP | [M2 API reference](/reference/hiecm-m2) | | [M3](/docs/hiecm/v3/api/m3) | Consent requests, consent notifications, artefact fetches, data flow requests | [M3 API reference](/reference/hiecm-m3) | | [M4](/docs/hiecm/v3/api/m4) | Session tokens for the [HPR](/docs/hiecm/v3/getting-started/glossary#hpr) and [HFR](/docs/hiecm/v3/getting-started/glossary#hfr) registry calls | [M4 API reference](/reference/hiecm-m4) | The gateway holds no health record. It routes the permission and the metadata. ## The session endpoint One endpoint issues the token every other call carries. It is the same call in [M1](/docs/hiecm/v3/getting-started/glossary#m1) and [M4](/docs/hiecm/v3/getting-started/glossary#m4). **POST** `/api/hiecm/gateway/v3/sessions` Headers: | Header | Value in the collection | What it is | | -------------- | ----------------------- | -------------------------------------------------------------------- | | `REQUEST-ID` | `{{$randomUUID}}` | A fresh UUID for this call | | `TIMESTAMP` | `{{$isoTimestamp}}` | The time you made the call, ISO 8601 | | `X-CM-ID` | `sbx` | The consent manager. Use `sbx` for sandbox and `abdm` for production | | `Content-Type` | `application/json` | | No `Authorization` header on this call. It is the one call with no token yet, and the collection marks it `noauth`. Body, transcribed from the collection: ```json { "clientId": "healthid-api", "clientSecret": "<CLIENT_SECRET_FROM_SANDBOX_SIGNUP>", "grantType": "client_credentials"} ``` The collection sends the literal `healthid-api` as the client id. The M4 document shows a per integrator value in the same field. Send whatever you were issued. Response shape, from the M4 document, which prints it as text: ```json { "accessToken": "<JWT>", "expiresIn": 1200, "refreshExpiresIn": 1800, "refreshToken": "<JWT>", "tokenType": "bearer"} ``` The response carries the token in `accessToken`. Send the token back as `Authorization: Bearer <ACCESS_TOKEN_FROM_SESSIONS_CALL>` on every other call. Headers per call, and the second token M1 login issues, are on [authentication](/docs/hiecm/v3/reference/authentication). Interactive: [gateway API reference](/reference/hiecm-gateway). ## Which host Four hosts serve gateway paths. | Host | Environment | | ----------------------------- | ---------------------------------------------- | | `https://dev.abdm.gov.in` | Sandbox | | `https://apissbx.abdm.gov.in` | Sandbox, on the sessions call | | `https://live.abdm.gov.in` | Production, alongside `apis` for the same call | | `https://apis.abdm.gov.in` | Production | Take the host from the sandbox documentation issued at onboarding, and keep it in configuration, not in code. ## Limits to code against - **Callback retries.** Make your endpoint idempotent and assume a repeat. - **Gateway token lifetime.** Read `expiresIn` from your own response rather than hard coding a value. - **Rate limits.** Two codes enforce them: `ABDM-1022 Too many requests` and `ABDM-1027 You are blocked. Please try again after 24 hours.` The thresholds are not published, so back off on both. - **Request signing.** The gateway request itself is not signed. Payload encryption and signing apply to health records, on the [M2](/docs/hiecm/v3/api/m2) side. ## Next - [Authentication](/docs/hiecm/v3/reference/authentication), credentials and headers. - [API references](/docs/hiecm/v3/api), every call and the callback it produces. - [Integration milestones](/docs/hiecm/v3/milestones), the four modules and who builds which. - [Registries](/docs/hiecm/v3/registries), who and what ABDM identifies. - [Error codes](/docs/hiecm/v3/reference/error-codes), what a rejection means. --- # Hospital, lab and pharmacy systems A facility publishing a record through your software is the [HIP](/docs/hiecm/v3/getting-started/glossary#hip), the health information provider in [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm). Your job has two halves. Identify the patient by their [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) address at registration, which is [M1](/docs/hiecm/v3/api/m1). Make the records the facility creates discoverable and shareable, which is [M2](/docs/hiecm/v3/api/m2). ## Before you start - **A valid facility ID, registered in the HIP role.** That authorises the facility to create health records and share them with whoever asks to read them as the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu). Registration lives in the [Health Facility Registry](/docs/hiecm/v3/registries). - **A link to an [HRP](/docs/hiecm/v3/getting-started/glossary#hrp), a health repository provider**, so discovery reaches you. The facility is the HRP in most integrations, and the [HMIS](/docs/hiecm/v3/getting-started/glossary#hmis) or [LMIS](/docs/hiecm/v3/getting-started/glossary#lmis) you run is how it holds the records. Where a facility's records sit with another organisation, that organisation is the HRP. | Purpose | Sandbox | Production | | --------------------------------------------- | -------------------------------------------- | --------------------------------------- | | ABHA identity APIs (M1) | `https://abhasbx.abdm.gov.in/abha/api/v3/` | `https://abha.abdm.gov.in/api/abha/v3/` | | Fingerprint and IRIS login via Aadhaar number | `https://abhasbx.abdm.gov.in/abha/api/v3.1/` | Not yet published | | Gateway and record exchange (M2) | `https://dev.abdm.gov.in` | `https://apis.abdm.gov.in` | ## What you build in M1 M1 is the registration desk: create an ABHA for a patient who does not have one, or verify the one they do have. Each capability is mandatory or optional, differently for private and government integrators. | Capability | Private integrators | Government integrators | | ----------------------------------------------------------------- | ------------------- | -------------------------------------------------- | | ABHA creation by Aadhaar OTP | Mandatory | Mandatory | | ABHA creation by Aadhaar face authentication | Optional | Optional | | ABHA creation by Aadhaar biometrics, fingerprint or IRIS | Optional | Optional | | ABHA creation by Aadhaar demographic authentication | Not required | Mandatory | | Child ABHA | Not available | Specific integrators, with NHA leadership approval | | Login by mobile number, Aadhaar number, ABHA number, ABHA address | Mandatory | Mandatory | | Fetch user profile | Mandatory | Mandatory | | Download ABHA card | Mandatory | Mandatory | | Mobile number management | Optional | Optional | | Re-KYC | Optional | Optional | | Benefit programme search, link and delink | Not available | Government only | | Session and refresh token APIs | Mandatory | Mandatory | Face authentication runs through the ABHA app and the Aadhaar RD service: your portal generates a QR code, the patient scans it in the ABHA app, and you poll for the result. Biometric creation needs an Aadhaar registered device, and UIDAI publishes the device list at <https://uidai.gov.in/en/ecosystem/authentication-devices-documents/biometric-devices.html>. Implement two validation algorithms locally before you spend an API call: Luhn for an ABHA number, Verhoeff for an Aadhaar number. ## What you build in M2 Five things have to work. 1. **Health records in the right format.** A [FHIR](/docs/hiecm/v3/getting-started/glossary#fhir) R4 bundle following the NRCES profiles at <https://nrces.in/ndhm/fhir/r4/index.html>, either simple with a PDF or image attachment or structured with coded information. There are eight record types, all mandatory for an HMIS. See [FHIR and health record formats](/docs/hiecm/v3/concepts/fhir). 2. **Care contexts.** The unit that attaches to an ABHA address. The [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) is data blind and holds two fields per care context: your internal reference ID, and a display name with nothing clinical in it. Use one per outpatient visit and one per inpatient admission. 3. **Linking.** Three routes, depending on what the patient gave you: HIP initiated with their ABHA address, notification to mobile when you hold only a mobile number, name, age and gender, and discovery when the patient comes looking from their [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app. Linking needs a linking token, stored at registration, valid 6 months, regenerated by demographic authentication. See [Care contexts and linking](/docs/hiecm/v3/concepts/linking). 4. **Answering discovery.** Mandatory for every HIP. Match on the verified identifiers the gateway sends, weight them above the patient declared ones, and return reference ID and display name pairs. The response carries no clinical or sensitive information. Metadata only. 5. **Health information request and data transfer.** Validate the consent ID and the date range against the artefact, then retrieve, encrypt with the HIU's key material, sign with your long term private key, push to the data push URL and notify with `health-information/notify`. The timeout is 20 minutes from the start of the request; split large data such as CT or MRI images into parts, streaming rather than sending one payload. See [How a record travels](/docs/hiecm/v3/concepts/data-flow). ## How linking fits a clinical workflow 1. **Registration.** The patient gives an ABHA address, or scans your counter QR code and shares their profile, or gives only name, mobile, age and gender. 2. **Store the linking token** against that patient record. You need it for every visit for 6 months. 3. **Care happens.** Your system produces a prescription, a report, a discharge summary. 4. **Group the records.** One care context per OPD visit, one per IPD admission. 5. **Link when the record is ready to share**, not when the visit opens. 6. **Wait.** The HIE-CM notifies the patient's PHR app, the app raises a consent request, and when consent is granted a health information request arrives. 7. **Validate, encrypt, push, notify.** Inside 20 minutes. Steps 1 and 2 are M1 work in your registration module. Steps 4 to 7 are M2 work, and most of it belongs in a background job, not the clinician's screen. ## Testing the loop in sandbox There is a single end to end check: 1. Log in to a PHR app with a sandbox ABHA address. 2. Register a patient with that same ABHA address in your system. 3. Create a health record for that patient. 4. Link a care context for it using HIP initiated linking. 5. The PHR app requests the record with the appropriate consent. 6. Prepare, encrypt and transfer the record to the data push URL the app supplied. 7. The record appears in the PHR app. Codes that cover its failures: `ABDM-1026` invalid link token, `ABDM-1038` ABHA address and link token mismatch, `ABDM-1056` care context already linked, `ABDM-1062` consent not granted, `ABDM-1063` invalid date range. The same code can arrive with more than one message, so read the message alongside the code. ## What you do not need to build - **Consent screens.** Consent is collected in the patient's PHR app. You validate the artefact. - **Record storage for other facilities.** You share your own records. - **Fetching records as the HIU**, unless the facility also reads records from elsewhere. That is [M3](/docs/hiecm/v3/api/m3), a separate integration. - **[UHI](/docs/hiecm/v3/getting-started/glossary#uhi).** Appointments, ambulances and pharmacy ordering run on a different gateway. - **[NHCX](/docs/hiecm/v3/getting-started/glossary#nhcx).** Claims exchange runs on a different gateway again, and no endpoint on it has been documented here yet. ## What to read next - [M1 overview](/docs/hiecm/v3/api/m1) and the [M1 API reference](/reference/hiecm-m1). - [M2 overview](/docs/hiecm/v3/api/m2) and the [M2 API reference](/reference/hiecm-m2). - [M2 errors](/docs/hiecm/v3/api/m2/errors), the full ABDM error code list. - [M2 steps and calls](/reference/hiecm-m2), what sandbox exit asks you to demonstrate. - [PHR applications](/docs/hiecm/v3/concepts/phr), the other side of every flow here. --- # How the pieces fit [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) has three moving parts: registries that issue identifiers, the [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) gateway that routes requests and holds consent, and the two roles a record moves between. ## In short - Two identities come first: the care seeker's ABHA, and the care provider's HPR and HFR. - There are two integrator roles, IMS or PHR. HIP and HIU are not roles, they are the two ends of one record moving. - Two configuration levels: your integration is one bridge, and every facility it serves links to that bridge. Neither is set inside the other. - Records never move to a centre. A pointer and a consent move, then the record goes point to point. ## Two identities come first Every call carries an identifier issued by a registry, and there are two kinds of entity to identify: the care seeker, and the care provider giving them care. Creating those entries comes before anything else. | Identity | Registry | Who it identifies | Identifier | Written by | | ------------- | ----------------------------------------- | ----------------------------------------------- | ------------------------------------------ | --------------------------- | | Care seeker | [ABHA](/docs/hiecm/v3/registries/abha) | A patient | 14 digit ABHA number, plus an ABHA address | [M1](/docs/hiecm/v3/api/m1) | | Care provider | [HPR](/docs/hiecm/v3/registries/nhpr/hpr) | A doctor, nurse, pharmacist or facility manager | HPR ID | [M4](/docs/hiecm/v3/api/m4) | | Care provider | [HFR](/docs/hiecm/v3/registries/nhpr/hfr) | A hospital, clinic, lab or pharmacy | Facility ID | [M4](/docs/hiecm/v3/api/m4) | [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) is the care seeker's. [HPR](/docs/hiecm/v3/getting-started/glossary#hpr) and [HFR](/docs/hiecm/v3/getting-started/glossary#hfr) sit together under NHPR and are the care provider's: one for the professional, one for the place. [Registries](/docs/hiecm/v3/registries) has what each one holds. ## The gateway sits in the middle Your system never calls another participant directly. You call the gateway, it forwards the request, and the answer arrives at your callback URL as a separate inbound call. That is why every flow here is drawn as a sequence. HIE-CM is data blind. It holds identifiers, metadata about where records live, and consent artefacts, never the record itself. It does not access or store health record content. [The ABDM gateway](/docs/hiecm/v3/concepts/gateway) covers the gateway and the session token every call carries. ## Your role is IMS or PHR There are two integrator roles on HIE-CM, and your product is one of them for its whole life. What decides it is which entity your software acts for. | Role | It acts for | What you build | | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | [IMS](/docs/hiecm/v3/getting-started/glossary#ims) | A care provider. An HMIS in a hospital, an EMR in a clinic, a LIMS in a laboratory, a PMS in a pharmacy | [M1](/docs/hiecm/v3/milestones/m1) to [M4](/docs/hiecm/v3/milestones/m4) | | [PHR](/docs/hiecm/v3/getting-started/glossary#phr) | A care seeker, who holds their own records and gives consent | [P1](/docs/hiecm/v3/milestones/p1) to [P3](/docs/hiecm/v3/milestones/p3) | [HIP](/docs/hiecm/v3/getting-started/glossary#hip) and [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) are not a third and a fourth role, and they are not something you register as. They are the two ends of one record moving: whoever publishes it is the HIP for that exchange, and whoever asks to read one they did not create is the HIU. Both roles are both, and it changes call by call: - A hospital is the HIP when it shares a discharge summary, and the HIU when it pulls an earlier prescription, through the same IMS. - A citizen is the HIP when they push a record from their PHR application, and the HIU when they fetch one. Neither is a thing you can build once and be. See [HIP and HIU](/docs/hiecm/v3/concepts/hip-hiu). ## One bridge, many facilities Two levels of configuration exist and they are easy to confuse. Your integration registers once, as a bridge. The facilities it serves register separately and are linked to that bridge. One bridge serves every facility linked to it, whether that is one facility or a hundred. Decide which level a setting belongs to before you build a settings screen for it. Nothing about your integration is configured per facility, and nothing about a facility is configured in your integration's own credentials. | Setting | Level | Where it is set | | ----------------------------- | ------------------------------------------ | ----------------------------------------------------------------------------------------------- | | Client id and client secret | Your integration, one of each | [Sandbox registration](/docs/hiecm/v3/getting-started/sandbox) | | Bridge callback URL | Your integration, one | [Sandbox registration](/docs/hiecm/v3/getting-started/sandbox#3-register-your-callback-url) | | Facility ID | Each facility | [HFR onboarding](/docs/hiecm/v3/milestones/m4#journey-3-a-facility-onboards-to-the-hfr) | | `hipId`, `hipName`, `hipType` | Each facility, once per bridge it links to | [The bridge linkage call](/docs/hiecm/v3/milestones/m4#journey-4-linking-bridges-to-a-facility) | Every callback for every facility arrives at the one bridge URL. The header says which facility it belongs to: `X-HIP-ID` in [M2](/docs/hiecm/v3/api/m2), and `X-HIU-ID` in M2 and [M3](/docs/hiecm/v3/api/m3). That header is what your handler routes a callback on, and the facility ID is what your records key to. A callback URL kept in a facility's settings is a design error, and so is a client secret. Either survives the first facility and fails on the next. See [the headers](/docs/hiecm/v3/reference/authentication) for what travels on each call. ## Records stay where they were created ABDM has no central store. A record stays in the system that created it. What moves is smaller: - A **care context** is a pointer, not content: a reference number and a display name. Putting a diagnosis or a result in that name is not allowed. See [linking](/docs/hiecm/v3/concepts/linking). - A **consent artefact** is the patient's permission, scoped by purpose, record type and date range. See [consent](/docs/hiecm/v3/concepts/consent). - The **record** goes point to point, encrypted, from the HIP that holds it to the HIU that asked, once a consent artefact exists. It is packaged as a [FHIR](/docs/hiecm/v3/getting-started/glossary#fhir) R4 bundle. See [data flow](/docs/hiecm/v3/concepts/data-flow) and [FHIR](/docs/hiecm/v3/concepts/fhir). ## One path end to end 1. The patient has an ABHA identity. 2. The facility is listed in the HFR and gets a Facility ID. 3. The facility links its software as a bridge, which makes your system resolvable as that facility. 4. Records created there become care contexts, linked to the patient's ABHA address through HIE-CM, and the patient sees them in a PHR app. 5. Another system asks for those records, and the patient decides whether to allow it. The doctor's HPR ID sits alongside. It identifies the professional inside a record and authorises facility registration. ## Next [Your integration path](/docs/hiecm/v3/milestones) for what each role has to build. --- # Care contexts and linking A health record your system creates is invisible to [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) until you link it, which means telling the [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) that a named group of records exists at your facility for a named person. Until that happens no patient can discover the record and no consent request can reach it; the calls that do it are in the [M2 guide](/docs/hiecm/v3/api/m2). ## The unit that gets linked is a care context You do not link a record. You link a [care context](/docs/hiecm/v3/getting-started/glossary#care-context), a group of a patient's records that your system defines. It carries two fields and nothing else. | Field | What it is | Rule | | ---------------- | ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Reference number | Your own internal identifier for that group of records | It has to resolve inside your system, because you will be handed it back later and asked for the records | | Display name | A description the patient reads before they decide anything | No clinical detail. No results, no diagnoses. | ```json { "patient": { "referenceNumber": "TMH-PUID-001", "display": "TMH records for Kiran Kumar", "careContexts": [ { "referenceNumber": "2375639", "display": "OPD records for O3 Oct 2022" } ] }} ``` A good display name is "OPD records (X-Ray, Prescription) from 3rd March 2023": what kind of visit and when, not what was found. Use one care context per outpatient visit and one per inpatient admission. ## Why the record has to be linked first The HIE-CM is data blind. It holds a map: which [ABHA address](/docs/hiecm/v3/getting-started/glossary#abha-address) has care contexts at which facilities. Linking puts an entry on that map, and everything downstream reads it. - A [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app shows a patient their records by reading their linked care contexts. - A consent request names record types and a date range, and the HIE-CM works out which record holders to notify from the links. - A health information request arrives quoting a care context you linked. An unlinked record is not private. It is absent. ## Link when the record is ready to share Link as soon as the health record is ready to be shared, not when the visit opens and not at the end of the month. Whenever a care context is linked, or an existing one gains new records, the HIE-CM notifies every PHR application subscribed to that ABHA address. You do not send those notifications. You trigger them by linking. ## Three routes onto the map Which route applies depends on what the patient gave you at registration. | Route | When it applies | Who starts it | | ----------------------------------------------------------------------- | ------------------------------------------------------------------- | ------------------------- | | [HIP](/docs/hiecm/v3/getting-started/glossary#hip) initiated linking | The patient shared their ABHA address with you | You | | Notification to mobile | You hold a mobile number, name, age and gender, but no ABHA address | You, and then the patient | | [Discovery](/docs/hiecm/v3/getting-started/glossary#discovery) and link | The patient goes looking for old records from their PHR app | The patient | **HIP initiated linking.** You know who the patient is, so you assign each new record to a care context and link it against their ABHA address. **Notification to mobile.** With no ABHA address to link to, you tell ABDM a record is ready. ABDM sends the patient an SMS with a secure deep link, which opens their PHR app or sends them to install one, where they can create an ABHA address, discover the record and link it. This route converts into the third one. **Discovery and link.** The request comes to you. The patient picks the facility they visited in their PHR app, and the HIE-CM forwards a discovery request to the [HRP](/docs/hiecm/v3/getting-started/glossary#hrp) or HIP behind it. You match against your own patients and reply with care contexts, and the patient picks which to link. Implementing discovery is mandatory for every HIP, even if every patient gives you an ABHA address at the counter, because a patient who visited two years ago did not. What you are handed splits in two: - **Verified identifiers**, which you weight higher: ABHA address, mobile number, name, gender and year of birth. - **Unverified, patient declared information**, typically a facility issued identifier such as a patient ID or a medical registration number. Use the unverified value to sharpen a match, not to make one. The response carries care context metadata and nothing else: no diagnosis, no test result, no report content. Somebody who has not yet proved they are the patient reads it. ## The link token Linking is authorised by a [link token](/docs/hiecm/v3/getting-started/glossary#link-token), not by your session token alone. The token ties your facility to one patient's ABHA address. | Property | Rule | | ------------------------------ | ------------------------------------------------------------------------------------------- | | When you get it | Generated and stored at the time the patient registers with you | | Validity | Six months | | Before use | Validate it, for example with a tool like JWT.io. Which check to run is not documented yet. | | If you do not have a valid one | Regenerate it through demographic authentication | Store it against the patient record, not the visit: you need it for every link you make for that patient over six months. Check it before you link, not after the gateway rejects you. ## What links look like when they go wrong From the M2 error table. Read the code with the message the gateway returns, because the table reuses some codes against more than one message. | Code | Message | | ----------- | ------------------------------------------ | | `ABDM-1026` | Invalid Link Token | | `ABDM-1038` | ABHA address and Link token mismatch | | `ABDM-1056` | This care contexts has been already linked | | `ABDM-1057` | Invalid Care Contexts | | `ABDM-1060` | Invalid Patient Reference Number | | `ABDM-1090` | Duplicate HIP link request | The full list is on [M2 errors](/docs/hiecm/v3/api/m2/errors). ## Where this is implemented - [Hospital, lab and pharmacy systems](/docs/hiecm/v3/concepts/hip-hiu), what a facility builds to do the linking. - [M2, linking and sharing](/docs/hiecm/v3/api/m2), the call order for all three routes. - [Consent](/docs/hiecm/v3/concepts/consent), what happens once somebody asks for a linked care context. - [How a record travels](/docs/hiecm/v3/concepts/data-flow), what you do when that request arrives. - [PHR applications](/docs/hiecm/v3/concepts/phr), the patient side of discovery and linking. --- # Citizen You are the person the health records are about. You build nothing and call nothing. You hold an identity, and you decide who sees what. ## Who you are in ABDM Your identity is an [ABHA](/docs/hiecm/v3/getting-started/glossary#abha), the Ayushman Bharat Health Account. It has two parts. | | ABHA number | ABHA address | | -------------- | -------------------------------------------------------------------------------------- | ------------------------------------------ | | What it is | 14 digits, such as `91-XXXX-XXXX-XXXX` | A readable name, such as `name@abdm` | | How you get it | After an Aadhaar based [KYC](/docs/hiecm/v3/getting-started/glossary#kyc) check passes | You choose it, or you are issued a default | | What it does | Anchors one person to one number | Routes records and consent requests to you | You can hold an address without a number, created from a mobile number, name, age and gender. That profile is self declared and carries no KYC. A [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app holds your account and acts for you. Hospitals, laboratories and pharmacies address records to your ABHA address. ## What you can do - Create an ABHA, by Aadhaar [OTP](/docs/hiecm/v3/getting-started/glossary#otp), face authentication, biometrics or a demographic match. - Share your profile at a counter by scanning the facility's QR code, and see what is being shared before you agree. - Search for a facility you visited, find records nobody has linked yet, and link them to your address. - Read a consent request in full: who is asking, why, which record types, which dates, and how long the access lasts. - Narrow it before you approve. You can change the access duration, the record date range, the data categories and the validity period. - Grant, deny, or revoke later. Revoking stops sharing under that consent immediately. ## Why it is worth it Your records stay in the systems that created them. The [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) holds identifiers, pointers and consent, never the record itself. Nothing central collects your health history. One address pulls records from many facilities into one app you choose. A permission you give is scoped and time boxed rather than open ended. Both sides of a transfer report it, so an exchange under your consent leaves a trail you can see. ## Next [Consent](/docs/hiecm/v3/concepts/consent) explains what a request carries and the states it moves through. --- # Doctor You are a registered healthcare professional. Your identity in [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) is personal, it is separate from the facility you work in, and the facility cannot register without someone who holds one. ## Who you are in ABDM You register on the [HPR](/docs/hiecm/v3/getting-started/glossary#hpr), the Healthcare Professionals Registry, and are issued an [HPID](/docs/hiecm/v3/getting-started/glossary#hpid). It is a 14 digit, Aadhaar authenticated identifier, written as both HPID and HPR ID. | Form | Sample | Sent as | | ----------- | ------------------- | ------------------------------------------- | | The number | `71-2665-5777-XXXX` | `hpId` or `hprIdNumber` | | The address | `name@hpr.abdm` | `hprId`, with a `domainName` of `@hpr.abdm` | Three categories can enrol today: doctor, nurse and pharmacist. You also declare a system of medicine. A role code says what you are on the registry: 1 for a healthcare professional, 2 for a facility manager, 3 for both. Your HPR ID identifies you as a professional. It does not put your software on the network, and it is not the [HFR](/docs/hiecm/v3/getting-started/glossary#hfr) facility ID your hospital holds. ## What you can do - Create your HPID through Aadhaar authentication, then register the full profile: personal details, communication address, council registration, qualification and current work. - Upload your degree certificate and registration certificate. Both are mandatory. - Get a fresh HPR token later, by password, by mobile [OTP](/docs/hiecm/v3/getting-started/glossary#otp) or by Aadhaar OTP. - With role 2 or role 3, register your facility on the HFR. The create call takes an HPR token in the header, and the submit call takes an `x-hpird-auth` token. Records themselves carry a `Practitioner` resource inside the [FHIR](/docs/hiecm/v3/getting-started/glossary#fhir) bundle, so the professional behind a record is named in it. ## Why it is worth it Your registration is a verified national identity, checked against Aadhaar and carrying your council registration and qualifications. It is also the thing that unblocks your organisation. Nobody can register a facility, and therefore nobody can share or fetch records, until a person with facility manager rights exists. That person is you or a colleague. No fee, payment or incentive for registering is documented here. ## Next [HPR, the professional registry](/docs/hiecm/v3/registries/nhpr/hpr) has the call order, the profile blocks and the code lists. --- # Hospital You create health records and you want records created elsewhere. That puts you on both sides of every exchange in [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm). ## Who you are in ABDM You enrol on the [HFR](/docs/hiecm/v3/getting-started/glossary#hfr), the Health Facility Registry, and a verified facility is issued a facility ID. Two formats are documented for it: `IN` followed by 10 characters on bridge linkage and search, and a 6 digit value on deduplicate search. Registering the facility gives it an identity. Linking a [bridge](/docs/hiecm/v3/getting-started/glossary#bridge) makes your software resolvable as that facility, in the [HIP](/docs/hiecm/v3/getting-started/glossary#hip) or [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) direction. | Role | When you are it | Milestone | | ---- | ----------------------------------- | --------------------------- | | HIP | You hold the record and send it | [M2](/docs/hiecm/v3/api/m2) | | HIU | You ask for a record held elsewhere | [M3](/docs/hiecm/v3/api/m3) | Your clinicians hold their own [HPR](/docs/hiecm/v3/getting-started/glossary#hpr) IDs, and one of them needs facility manager rights before you can register at all. ## What you can do - Identify the patient at registration by [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) address, or create an ABHA for someone who has none. - Group each visit into a [care context](/docs/hiecm/v3/getting-started/glossary#care-context) and link it, so the patient can find it. - Answer [discovery](/docs/hiecm/v3/getting-started/glossary#discovery) when a patient comes looking from their app. This is mandatory for every HIP. - Validate the consent, then encrypt, sign and push the records inside the 20 minute window. - Ask for a patient's history from another facility, under a consent they grant. ## Why it is worth it Enrolling on the HFR gets your facility a trusted identity, a listing in national search results, less paperwork on licence renewals and insurance empanelment, and access to ABDM's digital services. On the exchange itself, a record you link appears in the patient's own app without you posting anything. Earlier records from other facilities reach your clinicians with the patient's consent instead of arriving as a paper folder. Your records stay in your system throughout. There is no central store to hand them to. ## Next [Hospital, lab and pharmacy systems](/docs/hiecm/v3/concepts/hip-hiu) is the build guide for this role. --- # Ecosystem participants [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) is one network with several kinds of participant on it. Each holds an identifier issued by a registry, and each plays a role in the exchange. This section has one page per participant, and every page answers the same three questions: who you are, what you can do, and why it is worth taking part. Two of the eight do not integrate with anything. A citizen carries an identity and makes decisions. We run the network and issue the identifiers. The other six build software. | Participant | Who they are | | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | [Citizen](/docs/hiecm/v3/concepts/participants/citizen) | The person the records are about, holding an [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) number and address | | [Doctor](/docs/hiecm/v3/concepts/participants/doctor) | A registered professional holding an [HPID](/docs/hiecm/v3/getting-started/glossary#hpid) from the professional registry | | [Hospital](/docs/hiecm/v3/concepts/participants/hospital) | A facility that creates records, shares them, and reads records held elsewhere | | [Diagnostics](/docs/hiecm/v3/concepts/participants/lab) | A laboratory or imaging centre, sharing reports as a facility | | [Pharmacy](/docs/hiecm/v3/concepts/participants/pharmacy) | A pharmacy, sharing prescription and billing records as a facility | | [Insurer](/docs/hiecm/v3/concepts/participants/insurer) | A payer that reads records under consent, and settles claims on a separate gateway | | [PHR app](/docs/hiecm/v3/concepts/participants/phr) | The citizen's own app: identity, linking, consent and records | | [NHA](/docs/hiecm/v3/concepts/participants/nha) | The National Health Authority, which runs the gateways and the registries | ## A role belongs to the entity, not the software [HIP](/docs/hiecm/v3/getting-started/glossary#hip) and [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) are roles an entity takes, not kinds of software and not kinds of company. Whoever holds a record and publishes it is the HIP: a facility publishing through its [HMIS](/docs/hiecm/v3/getting-started/glossary#hmis), or a citizen pushing a record from their PHR app. Whoever asks to read records they did not create is the HIU, and an insurer or a referral service asks while holding neither an ABHA address nor a facility ID. So a hospital, a laboratory and a pharmacy sit in the same position and differ only in the records they hold. ## Next - [How the pieces fit](/docs/hiecm/v3/concepts/how-it-fits), the registries, the gateway and the roles in one page. - [Your integration path](/docs/hiecm/v3/milestones), what each role has to build. --- # Insurer You sit on two gateways, and they share no API surface. Clinical records move on the [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm). Claims move on [NHCX](/docs/hiecm/v3/getting-started/glossary#nhcx). ## Who you are in ABDM On the HIE-CM you take the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) role, health information user. That is a direction, not a category of company. Your organisation is the HIU whenever it asks to read records it did not create, and your software is how it asks. On NHCX you are a payer, which covers an insurer or a third party administrator acting for one. You onboard as a participant, in sandbox first and then in production. ## Confirm at onboarding - **Which registry entry your organisation holds on the HIE-CM.** The [HFR](/docs/hiecm/v3/getting-started/glossary#hfr) lists hospitals, clinics, laboratories, imaging centres, pharmacies and blood banks, and does not list insurers. Do not scope your build around a facility ID. [M4](/docs/hiecm/v3/api/m4) is required for an HIU, so ask which entry you register against before you plan that work. Build M1 and M3 meanwhile. ## What you can do On the HIE-CM you build [M1](/docs/hiecm/v3/api/m1) for identity and [M3](/docs/hiecm/v3/api/m3) for consent and fetching. - Raise a consent request naming the patient's [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) address, the purpose, the record types and the date range. - Use the purpose code `HPAYMT`, Healthcare Payment, where payment is the reason you are asking. The patient reads that code. - Wait. The patient decides, and may narrow the request before granting it, so read the artefact rather than assuming you got what you asked for. - Fetch under the granted artefact and decrypt. - Handle revocation. A consent that was live when you sent the request can be dead when the record holder validates it. ## Why it is worth it You receive structured records from the system that created them, as [FHIR](/docs/hiecm/v3/getting-started/glossary#fhir) bundles, instead of scans collected from the member. The permission behind each one is explicit, scoped and time boxed, and both sides report the transfer. What this does not give you is claim settlement. That is NHCX work, and a separate integration. ## Next [Consent](/docs/hiecm/v3/concepts/consent) covers what you may ask for, and [NHCX](/docs/nhcx/v1) covers the claims gateway. --- # Diagnostics A diagnostic laboratory or imaging centre publishes records as the [HIP](/docs/hiecm/v3/getting-started/glossary#hip), the same role a hospital takes. The machinery is identical. What changes is the records you hold. ## Who you are in ABDM You enrol on the [HFR](/docs/hiecm/v3/getting-started/glossary#hfr), which lists diagnostic laboratories and imaging centres alongside hospitals, clinics and pharmacies. A verified facility is issued a facility ID, and linking a [bridge](/docs/hiecm/v3/getting-started/glossary#bridge) makes your software resolvable as that facility. Two things in the facility record are yours. The additional information layer carries yes or no flags for a diagnostic lab and an imaging centre. The detailed information layer asks for diagnostic and imaging services, and an imaging centre or diagnostic laboratory does not have to submit medical infrastructure or bed counts at all. ## What you can do Everything a hospital does as a HIP, and by the same calls. Group results into a [care context](/docs/hiecm/v3/getting-started/glossary#care-context), link it, answer [discovery](/docs/hiecm/v3/getting-started/glossary#discovery), validate the consent, then encrypt and push. Nothing in [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) gives diagnostics a separate API surface. The difference is the record type. Radiology and laboratory reports are the Diagnostic Report Record, code `DiagnosticReport`. Billing is the Invoice Record. All eight record types are mandatory for an [HMIS](/docs/hiecm/v3/getting-started/glossary#hmis), and which of them a diagnostics only system must implement is not documented here. Large images are the one place your build differs in practice. Split a CT or MRI study into parts and stream it, inside the same 20 minute window. If you also read a patient's earlier results, that is the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) direction and a separate integration. ## Why it is worth it The registry gives your centre a trusted identity, a listing in national search results, less paperwork on licence renewals and insurance empanelment, and access to ABDM's digital services. A report you link reaches the patient's own app. The doctor who ordered it can ask for it under consent rather than waiting for a printout to travel. ## Next [Hospital, lab and pharmacy systems](/docs/hiecm/v3/concepts/hip-hiu) is the build guide, and [FHIR](/docs/hiecm/v3/concepts/fhir) has the record formats. --- # NHA The National Health Authority runs [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm), operates its gateways, and publishes this portal. ## Who NHA is in ABDM The National Health Authority is the government body that runs the network. It publishes the specifications, and it operates both the [sandbox](/docs/hiecm/v3/getting-started/glossary#sandbox) and the production gateways. It is not an integrator. There is no NHA system you exchange records with, and no role you take opposite it. It issues the identifiers you carry, routes your calls, and holds the permission that lets a record move. ## What NHA does | What it runs | What it gives you | | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | [ABHA](/docs/hiecm/v3/registries/abha) | A patient's 14 digit ABHA number and their ABHA address | | [HPR](/docs/hiecm/v3/registries/nhpr/hpr) | An [HPID](/docs/hiecm/v3/getting-started/glossary#hpid) for a doctor, nurse, pharmacist or facility manager | | [HFR](/docs/hiecm/v3/registries/nhpr/hfr) | A facility ID for a hospital, clinic, laboratory, imaging centre or pharmacy | | [The gateway](/docs/hiecm/v3/concepts/gateway) | Your session token, header validation, and routing to every other participant | | [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) | Care context links, consent requests and consent artefacts | | The sandbox | Client credentials, test identities, and the milestone certification you submit | One limit is deliberate. The HIE-CM is data blind. It holds identifiers, metadata about where records live, and consent artefacts. It never holds the record. Once consent exists, the record goes straight from the system that holds it to the system that asked, encrypted. The National Health Authority runs two further gateways alongside the HIE-CM, each with its own specification. [UHI](/docs/hiecm/v3/getting-started/glossary#uhi) carries services such as appointments, and [NHCX](/docs/nhcx/v1) carries insurance claims. ## Why it is worth it Because one authority runs the middle, you do not have to negotiate with every other participant. One identity works at every facility in the country. One consent model governs every transfer, so you implement it once. One certification path covers going live. And because the HIE-CM is data blind, joining the network does not mean handing your patients' records to NHA. They stay where they were created, in your system, and they move only to a system the patient has allowed. ## Next [How the pieces fit](/docs/hiecm/v3/concepts/how-it-fits) puts the registries, the gateway and your role in one page. --- # Pharmacy A pharmacy publishes records as the [HIP](/docs/hiecm/v3/getting-started/glossary#hip), the same role a hospital takes. The calls, the linking and the encryption are identical. What changes is the records you hold, and one thing that is not on this gateway at all. ## Who you are in ABDM You enrol on the [HFR](/docs/hiecm/v3/getting-started/glossary#hfr), which lists pharmacies alongside hospitals, clinics and laboratories. A verified facility is issued a facility ID, and linking a [bridge](/docs/hiecm/v3/getting-started/glossary#bridge) makes your software resolvable as that facility. Pharmacy appears twice in a facility record: as a facility type, and as a yes or no flag in the additional information layer for a facility that runs a pharmacy inside it. A pharmacy does not have to submit medical infrastructure or bed counts. Your pharmacists can register on the [HPR](/docs/hiecm/v3/getting-started/glossary#hpr) as well. Pharmacist is one of the three professional categories open today. ## What you can do Everything a hospital does as a HIP, and by the same calls. Group records into a [care context](/docs/hiecm/v3/getting-started/glossary#care-context), link it, answer [discovery](/docs/hiecm/v3/getting-started/glossary#discovery), validate the consent, then encrypt and push. Two of the eight record types are the ones closest to your work. The Prescription Record holds medication advice and follows Pharmacy Council of India guidelines. The Invoice Record holds pharmacy invoices and other billing. warning Check the swagger before you send `Invoice` `Invoice` appears in the [M2](/docs/hiecm/v3/api/m2) error message for an invalid health information type, and is missing from the [M3](/docs/hiecm/v3/api/m3) list of supported types. The two sources disagree. Whether dispensing has a record type of its own is not documented here. Ordering and fulfilment are not on this gateway: they run on [UHI](/docs/hiecm/v3/getting-started/glossary#uhi), which has a separate specification. ## Why it is worth it The registry gives your pharmacy a trusted identity, a listing in national search results, less paperwork on licence renewals and insurance empanelment, and access to [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm)'s digital services. A record you link reaches the patient's own app, so their medication history sits with the rest of their records instead of in a paper bag. ## Next [Hospital, lab and pharmacy systems](/docs/hiecm/v3/concepts/hip-hiu) is the build guide, and [FHIR](/docs/hiecm/v3/concepts/fhir) has the record formats. --- # PHR app You are the citizen's own app. You hold their identity, show them their records, and are the place where every consent decision is taken. ## Who you are in ABDM A [PHR](/docs/hiecm/v3/getting-started/glossary#phr) application acts for the citizen, and a citizen and a facility sit on opposite sides of the [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm). That position is fixed for the life of your product. You hold no registry identifier of your own. Your users hold the [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) numbers and addresses, and everything routes on the address. Your own credentials are the client id and client secret issued at sandbox signup, which you exchange for a session token. Within that position the citizen takes both directions through your app. Your user is the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) whenever you fetch their records, and the [HIP](/docs/hiecm/v3/getting-started/glossary#hip) the moment they link or push one from your app. To be listed for deep links, submit three things at sandbox exit: your application name, your Play Store URL and your App Store URL. ## What you can do | Build | What it gives the user | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | [P1](/docs/hiecm/v3/milestones/p1) | Create or link an ABHA address, four login routes, profile, card and QR code | | [P2](/docs/hiecm/v3/milestones/p2) | Scan and share at a facility, discover old records, link [care contexts](/docs/hiecm/v3/getting-started/glossary#care-context) | | [P3](/docs/hiecm/v3/milestones/p3) | Subscriptions, notifications, consent decisions, auto approval, fetching and storing records | Accepting uploads makes you a health locker, and that needs [M2](/docs/hiecm/v3/api/m2) as well. ## Why it is worth it You are the only participant the citizen actually sees. Every consent request raised anywhere on the network arrives in your app, and the decision is made there. The [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) tells you when a care context is created or updated for a subscribed address, so records reach your user without them chasing a facility. You then store those records for the long term, which no other participant does on the citizen's behalf. ## Next [PHR applications](/docs/hiecm/v3/concepts/phr) is the build guide, screen by screen. --- # PHR applications A [PHR](/docs/hiecm/v3/getting-started/glossary#phr) application is the patient's app in [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm): it holds a person's [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) address, finds their records, takes consent and shows the records back. You build [M1](/docs/hiecm/v3/api/m1) for identity, [M3](/docs/hiecm/v3/api/m3) for consent and record fetching, and some [M2](/docs/hiecm/v3/api/m2) if users upload their own records. ## What a PHR app does Every user needs an ABHA address, `username@abdm`. Consent, notifications and record sharing hang off it. There are six jobs: | Job | What the user sees | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Create or link an ABHA address | Register with a mobile number, or with an existing 14 digit ABHA number | | Log in | Mobile number, ABHA address, default `14digit@abdm` address, or ABHA number | | Manage a profile | Demographics, photo, password, QR code, downloadable ABHA card | | Share a profile at a facility | Scan the facility QR code, consent, receive a queue token | | Find and link past records | Search a facility, discover [care contexts](/docs/hiecm/v3/getting-started/glossary#care-context), verify by [OTP](/docs/hiecm/v3/getting-started/glossary#otp), link | | Hold records | Receive notifications, request consent, fetch records, store and display them | ## Your app needs a server A PHR app is two parts, whatever it looks like to the user. The app on the phone signs the person in, shows the screens and scans codes. A server you run holds the client ID and secret, mints the [gateway session token](/docs/hiecm/v3/concepts/gateway), and hosts the callback URL registered for your bridge. Every answer to a linking, consent or data request arrives at that URL as a POST, so an app with no server never hears the answer. Never ship the client secret inside the app. ## What you build in M1 ABHA base URLs are `https://abhasbx.abdm.gov.in/abha/api/v3/` for sandbox and `https://abha.abdm.gov.in/api/abha/v3/` for production. PHR enrolment uses `https://abhasbx.abdm.gov.in/abha/api/v3/phr/app/enrollment/request/otp`. ### Creating an ABHA address Build both paths. | Path | Validated by | Profile details | Result | | -------------------- | ------------------------- | --------------------------- | ------------------------------------------------------------------------ | | Mobile number | Mobile OTP | The user types them | **Self-Declared**, no [KYC](/docs/hiecm/v3/getting-started/glossary#kyc) | | 14 digit ABHA number | Aadhaar OTP or mobile OTP | Returned by the ABHA system | **KYC Verified** | On the mobile number path, first name, year of birth, gender, address, state, district and pin code are mandatory; middle name, last name, day and month of birth are optional. After validation on either path, show the ABHA addresses already linked to that mobile number or ABHA number, so the user picks one instead of creating a duplicate. ABDM wants one address per person. Address rules: - Letters, numbers and a dot only. - Cannot begin with a number, and cannot begin or end with a dot. - All numeric is allowed only for the `14digit@abdm` form. - Creating a `10digitmobile@abdm` address is currently blocked. - Creating a `14digit@abdm` address is not allowed, but a user can log in with one. Every 14 digit ABHA number is issued a default address of this shape, written as `14digit@sbx` or `14digit@abdm`. Which environment uses which suffix is not documented yet. - Minimum length is stated twice and the statements disagree: 4 characters in the prose and the ABHA number test cases, 8 in the mobile number test case table. Unresolved against the sandbox, so validate against the API response. - Password, where you collect one: 8 characters or longer, one A to Z, one a to z, one digit, one symbol, no spaces, no more than 2 consecutive characters or keyboard keys. Password validation is now optional. ### Linking an ABHA number to an ABHA address The ABHA number is the KYC verified identity; the ABHA address is what shares records. A user can hold several ABHA addresses but only one ABHA number. A Self-Declared profile needs a "Link ABHA number" action: enter the 14 digit number, validate by Aadhaar OTP or mobile OTP. Profile details then follow the ABHA number, the number becomes visible, and the status changes to KYC Verified. ### Login All four routes are mandatory. | Route | Validated by | | ----------------------------------------------- | ----------------------------------------------------------------------- | | Mobile number | Mobile OTP, then the user picks which linked ABHA address to sign in as | | An easy to remember address such as `name@abdm` | Password, mobile OTP or Aadhaar OTP, by auth mode | | The default `14digit@abdm` address | Mobile OTP or Aadhaar OTP | | The 14 digit ABHA number | Mobile OTP or Aadhaar OTP | Resend OTP unlocks after 60 seconds in every flow. You also need a reset password screen behind login with a confirmation message, secure storage of the refresh token to extend the session, and more than one user profile per install with sign in and sign out. ### Profile, card and QR code | Element | What it holds | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | | Profile screen | Editable demographics. KYC Verified with a green tick when an ABHA number is linked, Self-Declared with an exclamation mark when it is not | | ABHA number | Visible only on a KYC Verified profile | | ABHA address card, a PDF | Profile photo, full name, ABHA number as `91-0098-2416-3421` if one is linked, ABHA address, QR code, date of birth, gender, mobile number | | Editable, KYC Verified | Mobile number, with an OTP to the new number, and address | | Editable, Self-Declared | The same, plus photo, full name, gender and date of birth | ### Scan and share at a facility The facility displays a QR code holding a URL with two parameters: the [HIP](/docs/hiecm/v3/getting-started/glossary#hip) ID and a facility defined context such as a counter code. Your app scans it, then: 1. Shows the user what will be shared. 2. Takes consent in ABDM's specified wording, covering sharing the ABHA address and profile information with that facility for registration, and the facility linking any records it generates. 3. Calls the [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) API to share the details. 4. Waits for the facility, currently expected to respond within 30 seconds. 5. Displays the token number if the facility returned one. Two time limits are in the source and we have tested neither: the functionality overview blocks a second token for 60 minutes, the test cases show the token as valid for the next 30 minutes and configurable. Counter names arrive in the QR code: up to 20 alphanumeric characters, no special characters, examples OPD, OPD1, OPD cardio, IPD1, Pharmacy. A counter name cannot be the [HFR](/docs/hiecm/v3/getting-started/glossary#hfr) facility ID, the [HPID](/docs/hiecm/v3/getting-started/glossary#hpid), the HIP ID or the HIP name. Opened from a third party scanner or the phone camera, go to the share profile screen if the user is signed in, to login first if not. ## What you build in M3 A citizen fetching records is the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu), so every PHR application must implement that side. ### Subscriptions and notifications A subscription is how your app hears about changes to a user's ABHA address. Set one up when you create an ABHA address, and when a user logs in with an address your install has not seen. Ask the user for consent first. An approved subscription notifies your app of a new care context, a modified care context, a new consent request and a new subscription request. Surface these as device notifications, for example through Firebase on Android. You need screens to list subscriptions, approve, deny and edit them, where editing covers health information types, types of visit and the time period. ### Auto approval So the user does not approve a request every time a hospital adds a record: 1. Ask the user to confirm your app may retrieve new linked records automatically. 2. Set up an auto approval policy with the HIE-CM. 3. Save the auto approval ID the HIE-CM returns. While the policy is active, the consent request you raise on a new or updated care context notification is granted immediately and you fetch and store the record. The user must be able to disable a policy. A request then arrives for each record. ### Consent management You build five capabilities: | Capability | What it covers | | -------------------- | -------------------------------------------------------------------- | | View requests | Requesting HIU, purpose, data types, date range, validity, status | | Modify a request | Access duration, record date range, data categories, validity period | | Grant or deny | The decision goes back to the HIE-CM | | View active consents | Who currently has access, and to what | | Revoke | Withdraw at any time. Sharing under that consent stops immediately | The Consents tab and the Subscriptions tab group state the same way: a Requests section holding Requested, Denied and Expired, and an Approved section holding Granted and Revoked. ### Fetching and displaying records Once a care context is linked to the user's ABHA address: 1. Your app receives the notification. 2. It creates a consent request for that record and sends it to the HIE-CM. 3. The consent is granted, automatically if a policy exists, otherwise by the user. 4. It raises a health information request with the approved [consent artefact](/docs/hiecm/v3/getting-started/glossary#consent-artefact). 5. The HIP sends the records across the network. 6. Your app stores them for long term access and displays them, preferably in chronological order. The test cases cover fetching each health information type structured and unstructured: diagnostic report, prescription, discharge summary, consultation note, immunisation record, wellness record and health document record. ## Subscriptions, and why you need one A care context can be linked to a person's address by any facility they visit, without your application being part of it. A subscription is how you find out: a standing watch on one address, delivering to your callback whenever something changes. NHA expects a PHR app to set one up at two moments, when it creates an address and when a person signs in with an address it has not seen before. The person must be asked to consent to it; signing in does not imply it. Once approved, four events arrive: a new care context, a modified care context, a new consent request, and a new subscription request. Showing them on the device is your job, and NHA names a push service as the example rather than a requirement. A request sits in exactly one state, and the same five carry consent requests, subscription requests and health locker requests, so one screen serves all three. | Group | State | What it means | | -------- | --------- | ---------------------------------------------------- | | Requests | Requested | Sent, and the person has not acted | | Requests | Denied | The person refused it | | Requests | Expired | The person did not act inside the requester's window | | Approved | Granted | The person allowed it | | Approved | Revoked | Allowed, then withdrawn | A subscription is not consent and gives nobody a record. It tells you a record exists. Reading it still needs a consent, which is why a subscription usually runs alongside an auto approval policy. ## Discovery and user initiated linking For a facility the user visited without giving an ABHA address, or for old records. The user searches for the facility by name. Only facilities participating in ABDM appear, and the facility must be a HIP linked to an [HRP](/docs/hiecm/v3/getting-started/glossary#hrp). Your app sends a discovery request to the HIE-CM carrying name, year or date of birth, gender, verified mobile number, ABHA address, and optionally a patient registration number issued by that provider. The HIP is expected to respond within 10 seconds. Care contexts already linked must not be shown again. When everything is linked, show the message "All your existing records are linked. No additional records available for linking". The user selects care contexts and confirms, the HIP sends an OTP to the registered mobile number, and on successful verification the care contexts link to the ABHA address. The same flow works for government health programmes such as CoWIN, AB-PMJAY, e-Sanjeevani OPD, e-Sanjeevani HWC and RCH, with a programme specific optional field such as the PMJAY ID or the CoWIN registered mobile number. Three failures have specified copy: | Situation | Message | | ----------------------------------- | --------------------------------------------------------------------------------------------------------- | | The HIP is unreachable | "Couldn't Connect: We are sorry. Unable to contact your hospital. Please try again later" | | The user never visited the facility | "No health records found" | | Everything is already linked | "No new health record to link: Records of all visits are already linked and there is nothing new to link" | Send the data transfer request within 5 minutes of the user tapping Pull Records. Records should arrive within 2 hours. ## Deep links A patient who registers at a facility without an ABHA address gets an SMS carrying a deep link of the form `phr.abdm.gov.in/uhi/(hipcode)`. Tapping it lists approved ABHA mobile applications in random order, filtered to the user's operating system. Your app must accept the HIPCODE parameter. Launched through a deep link, it must skip its normal login or home screen and go straight into discovery for that HIPCODE, guiding the user to enter the same name, date of birth, gender and mobile number they gave the facility. A mismatch stops the records being found. To be listed, you submit three things at sandbox exit: application name, Play Store URL and App Store URL. ## Where the citizen is the HIP A citizen pushing a record into your app is the HIP. A health locker, where users upload their own records, puts you on that publishing side. A PHR app must accept scanned physical records and output from devices such as BP meters, glucose meters, fitness trackers and smartwatches. Your app sets the health information type from the contents or from user input, and uses `HealthDocumentRecord` when it cannot be determined. An uploaded record is shareable once you have three things: a linking token from the M1 APIs, a care context added to the user's ABHA address by HIP initiated linking from [M2](/docs/hiecm/v3/api/m2), and the M2 health information transfer APIs. ## What you do not need to build - **Facility side clinical records.** No [FHIR](/docs/hiecm/v3/getting-started/glossary#fhir) bundles from a hospital or lab system, other than records your users upload. - **[HPR](/docs/hiecm/v3/getting-started/glossary#hpr) and HFR registration.** M4 covers the professional and facility registries. - **[UHI](/docs/hiecm/v3/getting-started/glossary#uhi).** Consultation, ambulance and pharmacy booking runs on a separate gateway. - **[NHCX](/docs/hiecm/v3/getting-started/glossary#nhcx).** Claims and insurance exchange runs on a separate gateway. ## What to read next - [M1 overview](/docs/hiecm/v3/api/m1) for ABHA creation, login and session APIs, and the [M1 API reference](/reference/hiecm-m1). - [M3 overview](/docs/hiecm/v3/api/m3) for consent, subscriptions and data fetch, and the [M3 API reference](/reference/hiecm-m3). - [M2 overview](/docs/hiecm/v3/api/m2) if you are building a health locker, and the [M2 API reference](/reference/hiecm-m2). - [Get started](/docs/hiecm/v3/getting-started/sandbox) for sandbox signup and your first call. - [Hospital, lab and pharmacy systems](/docs/hiecm/v3/concepts/hip-hiu) for the other side of every flow on this page. --- # Build it well Every call on this site can be made correctly and still leave you with an integration that fails at a busy counter. What separates the two is handling: what you check before you call, what you do with what comes back, and what the person in front of you sees while it happens. ## In short - Check locally what can be checked locally. A round trip that fails a format rule costs the person thirty seconds and tells them nothing. - Read the body, not the status. ABDM returns four error shapes and only some carry a code. - Retry only what is safe to retry. Enrolment and one time password calls are not. - Say what failed and what the person can do next. A code on its own is not an error message. - Map every field the profile returns, not the four you need this week. ## Validate before you send These rules are the service's, and it applies them after it decrypts. Checking them in your own form turns a failed call into an inline message. | What | Rule | What it costs to skip | | -------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------- | | ABHA number | 14 digits with dashes, `NN-NNNN-NNNN-NNNN`, before encryption | `400 {"loginId": "LoginId is invalid"}` | | ABHA address | 8 to 18 characters, letters and digits with an optional `.` or `_`, then `@` and the domain | A rejected address after the person has chosen it | | Mobile number | 10 digits, no country code and no `+` | A failed call that reads as a wrong number | | Aadhaar number | 12 digits, no spaces | The same | | `REQUEST-ID` | A fresh UUID version 4 on every call | Two calls you cannot tell apart later | | `TIMESTAMP` | ISO 8601 in UTC, from a synchronised clock. Every header is in [authentication](/docs/hiecm/v3/reference/authentication) | Every call fails at once | One thing you cannot check locally is whether the account exists. A well formed ABHA number that belongs to nobody returns `404 ABDM-1114 User not found`, and that is a different message to the person than a badly formed one. The plaintext shape for every encrypted field is in [encryption](/docs/hiecm/v3/concepts/encryption). ## Read the error, then decide ABDM returns [four different error shapes](/docs/hiecm/v3/api/m1/errors), and only two of them carry a code. Parse for all four before you write any handling, because the shape tells you where the failure came from. Every code in the [error code reference](/docs/hiecm/v3/reference/error-codes) carries an action. Key your handling to that column rather than to a list of codes you maintain by hand. | Action | What your code does | | -------------- | ----------------------------------------------------------------------------- | | Fix request | Do not retry. Something you sent is wrong, and sending it again will not help | | Fix auth | Fetch a fresh token, then retry once | | New request id | Generate a new `REQUEST-ID`, then retry once | | Retry | Back off and retry, with a ceiling on attempts | | Cannot proceed | Stop, and tell the person why in their own terms | | Ask support | Stop, and collect the ids before the context is lost | | Unclassified | Treat as Cannot proceed until you have seen it once and know better | Symptom first debugging, for the failures that produce no useful code at all, is in [troubleshooting](/docs/hiecm/v3/troubleshooting). ## Retries, and the calls you must not repeat A retry is safe when repeating the call cannot create a second thing or burn a single use value. Most of M1 fails that test. | Call | Safe to repeat | Why | | ------------------------------- | -------------- | ------------------------------------------------------------------------------------------------- | | Session token | Yes | It issues a token and changes nothing else | | Profile, card and QR code reads | Yes | Reads | | Request an OTP | No | Rate limited. A retry loop is the usual cause of the lockout it is trying to escape | | Verify an OTP | No | The OTP and the transaction id are both single use | | Enrol, or create an ABHA | No | A success you did not see still created an account | | Your callback handler | It must be | ABDM repeats callbacks, so deduplicate on the id the callback repeats before you apply any effect | `REQUEST-ID` is the idempotency key, one fresh UUID per call, and it is what lets you tell a repeat from a new attempt in your own logs. See [authentication](/docs/hiecm/v3/reference/authentication) for the headers and [the gateway](/docs/hiecm/v3/concepts/gateway) for the limits. ## What the screen says when a call fails The person at the counter cannot act on a code. They can act on what to do next. | What happened | What the screen says | What it must not do | | ---------------------------------------- | -------------------------------------------------- | ---------------------------------------- | | The OTP did not match | Say so, keep the field, offer a resend | Close the form or show a generic failure | | Rate limited or locked out | Name the actual wait, for example thirty minutes | Say something went wrong | | No account found | Show it as a result, not as an error | Turn a normal empty result red | | The address already exists | Offer the login route instead | Report a creation failure | | ABDM or the other party is not answering | Say it is not answering and to try again | Imply the person typed something wrong | | Anything with no code at all | Show the reference the person can quote to support | Print the raw response body | ## The screens themselves | Rule | Why | | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | A step happening on somebody else's device is not a spinner | Face authentication waits on a person. Say that is what you are waiting for | | Show the masked destination before the wait | The search response names the mobile the OTP went to, which stops somebody waiting for a message that will never arrive | | Say upfront when the account will be restricted | Otherwise the person meets the limit later, when something unrelated fails | | Answer scan and share inside thirty seconds | The patient's screen is open for that long, and an acknowledgement after it shows them nothing | | Offer the login methods the account actually has | `authMethods` on the profile says which ones the person can use. A screen offering an Aadhaar OTP to a profile with no Aadhaar behind it fails for a reason nobody can see | | Put a setting at the level it belongs to | Your credentials and your callback URL belong to the integration, the facility ID and the `hipId` belong to each facility. A settings screen that mixes them works for the first facility and fails on the next. See [one bridge, many facilities](/docs/hiecm/v3/concepts/how-it-fits#one-bridge-many-facilities) | | Aadhaar numbers, one time passwords and passwords never reach a log or a database | Encrypting a value and then logging the plain one is the same leak, moved. See [encryption](/docs/hiecm/v3/concepts/encryption) | The first four are journey specific and each is explained where it happens, on [the M1 journeys](/docs/hiecm/v3/milestones/m1). ## Map everything ABHA gives you The most common M1 defect is a registration form wired to four fields when the profile returned thirty. The rest is then either retyped by a person who already gave it to Aadhaar, or lost. `GET /v3/profile/account` returns the fields below. Map all of them, and decide for each whether your form shows it, locks it or lets a receptionist correct it. | Profile field | Goes to | Editable in your form | | -------------------------------------------------------------------------------- | --------------------------------------------------------------------- | -------------------------------------------------------- | | `ABHANumber`, `preferredAbhaAddress` | The patient's ABDM identity, and the key you match on later | Never | | `name`, `firstName`, `middleName`, `lastName` | Patient name. Keep the parts, not only the joined string | Only on a Self-Declared profile | | `dayOfBirth`, `monthOfBirth`, `yearOfBirth` | Date of birth, assembled by you | Only on a Self-Declared profile | | `gender` | Gender, as `M`, `F` or `O` | Only on a Self-Declared profile | | `mobile` | Contact number | Yes, it is the communication number and people change it | | `address`, `pincode`, `stateName`, `districtName`, `subdistrictName`, `townName` | Address. The `*Code` twins are the machine values, keep both | Yes | | `stateCode`, `districtCode`, `subDistrictCode` | Your own reporting, which should key on codes rather than names | Never | | `kycVerified`, `verificationStatus`, `verificationType` | Whether this identity was proved, and by what | Never | | `authMethods` | What the person can log in with next time, so you offer the right one | Never | | `kycPhoto`, `profilePhoto` | Identity photo. Decide whether you store it at all before you do | Never | | `status` | Whether the account is active | Never | | `localizedDetails` | The same details in the person's own language, where NHA holds them | Never | `kycVerified` is the field the form design hangs off. A [KYC verified profile](/docs/hiecm/v3/milestones/m1#abha-with-aadhaar) was proved against Aadhaar, so its demographics are better evidence than anything typed at a desk and your form should lock them. A [Self-Declared profile](/docs/hiecm/v3/milestones/m1#abha-address-with-a-mobile-number) is what the person typed themselves, so it is correctable, and it becomes KYC verified in place if they link an ABHA number later. Two traps. Several of these fields are nullable, and `villageName`, `wardName` and `townName` are commonly null, so a form that renders a blank labelled row for each is worse than one that hides them. And the profile comes back in more than one shape across M1: the update response types `yearOfBirth` as an integer where this one types it as a string, and the patient share payload and the PHR profile carry different names again. Map from one named endpoint and say which, rather than writing one mapper for something called the ABHA profile. ## Where to go next - [Build with AI](/docs/hiecm/v3/getting-started/build-with-ai) for setting an agent up, and for how to prompt it against these rules. - [Troubleshooting](/docs/hiecm/v3/troubleshooting) when something is already broken. - [Go live](/docs/hiecm/v3/getting-started/going-live) for what certification asks of you. --- # Build with AI Every fact on this site is a public URL. There are three ways to put it in front of your agent, and they combine: the plugin is the one command that sets up the other two. [Recommended](#connect-the-docs-mcp-server) [Docs MCP server](#connect-the-docs-mcp-server) [This documentation live, queried a paragraph at a time as your agent works. It cannot go stale, because it is this site answering.](#connect-the-docs-mcp-server) [AI plugin](#install-the-plugin) [One command that sets your agent up with both of the others: the skills as files, the server as a connection.](#install-the-plugin) [Agent skills](#install-a-skill) [One file per job, carrying a whole milestone: every endpoint, header, error code and test. Works offline, and ages until you update it.](#install-a-skill) ## Connect the Docs MCP server A skill is a snapshot. The Docs MCP server is the same catalogue live, queried a paragraph at a time instead of loaded whole. Docs MCP server Your agent queries this catalogue as it works, instead of loading it. - SearchHybrid keyword and semantic search over every page here, so an agent retrieves the paragraph it needs instead of loading the site.`search_docs, get_atom, related_atoms, list_atoms` - DecodeTurn an error code you just received into what it means and what to do, without you finding the right table.`decode_error` - ValidateCheck a request body against the specification before you send it, and list or read any operation.`validate_request, list_operations, get_operation` [Add to Claude Code](claude://code/new?q=Add%20the%20ABDM%20documentation%20MCP%20server%2C%20then%20use%20it%20to%20answer%20my%20ABDM%20questions.%0A%0ARun%20this%3A%0Aclaude%20mcp%20add%20--transport%20http%20abdm-docs%20https%3A%2F%2Fabdm-docs-mcp.dev.eka.care%2Fmcp%20-s%20user%0A%0AUser%20scope%2C%20so%20it%20is%20available%20in%20every%20project%20rather%20than%20only%20this%20directory. "Opens the Claude app with the add command ready. Nothing runs until you press Enter.")[Add to Cursor](cursor://anysphere.cursor-deeplink/mcp/install?name=abdm-docs\&config=eyJ1cmwiOiJodHRwczovL2FiZG0tZG9jcy1tY3AuZGV2LmVrYS5jYXJlL21jcCJ9 "Opens Cursor on a confirmation dialog. No command to run.")[Add to VS Code](vscode:mcp/install?%7B%22name%22%3A%22abdm-docs%22%2C%22type%22%3A%22http%22%2C%22url%22%3A%22https%3A%2F%2Fabdm-docs-mcp.dev.eka.care%2Fmcp%22%7D "Opens VS Code on a confirmation dialog. No command to run.") **Claude Code (CLI)** `claude mcp add --transport http abdm-docs https://abdm-docs-mcp.dev.eka.care/mcp -s user` Run this in the repository you are integrating. **Claude Desktop / generic** `{ "mcpServers": { "abdm-docs": { "url": "https://abdm-docs-mcp.dev.eka.care/mcp" } } }` Any MCP client that reads an `mcpServers` config, Claude Desktop included, takes this block as is. ## Install the plugin One command for both halves: the skills as files and the server as a connection. Claude takes it as a plugin; Cursor, Codex, ChatGPT and anything else that can fetch a URL take the same setup as a line to paste. Set your agent up in one step Open your agent with the setup ready to send, or copy it. Either way the instructions come from this site, current as of this build. **Claude** `claude plugin marketplace add eka-care/abdm-docs && claude plugin install abdm-integrators-assistant@abdm-portal` [Open in Claude](claude://code/new?q=Set%20this%20project%20up%20for%20ABDM%20integration.%20Run%3A%0A%0Aclaude%20plugin%20marketplace%20add%20eka-care%2Fabdm-docs%0Aclaude%20plugin%20install%20abdm-integrators-assistant%40abdm-portal%0A%0AIf%20the%20marketplace%20add%20fails%20\(the%20repository%20may%20not%20be%20accessible\)%2C%20instead%20fetch%20and%20execute%20the%20instructions%20from%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fagent-setup%2Fprompt.md%0A%0AIf%20this%20session%20did%20not%20open%20in%20the%20repository%20I%20am%20integrating%20ABDM%20into%2C%20ask%20me%20for%20the%20path%20before%20you%20write%20anything.) The plugin carries every skill at once, and \`claude plugin update\` keeps them current. **Cursor** `Fetch and execute the instructions to set me up for ABDM integration from https://abdm-docs.dev.eka.care/agent-setup/prompt.md` [Open in Cursor](cursor://anysphere.cursor-deeplink/prompt?text=Fetch%20and%20execute%20the%20instructions%20to%20set%20me%20up%20for%20ABDM%20integration%20from%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fagent-setup%2Fprompt.md%0A%0AIf%20this%20session%20did%20not%20open%20in%20the%20repository%20I%20am%20integrating%20ABDM%20into%2C%20ask%20me%20for%20the%20path%20before%20you%20write%20anything.) Opens Cursor with the prompt in the composer. It fetches the current instructions from this site. **Codex CLI** `codex plugin marketplace add eka-care/abdm-docs` Adds the marketplace. Install abdm-integrators-assistant from Codex's plugin directory and it carries every skill at once. **ChatGPT** `Fetch and execute the instructions to set me up for ABDM integration from https://abdm-docs.dev.eka.care/agent-setup/prompt.md` [Open in ChatGPT](https://chatgpt.com/?q=Fetch%20and%20execute%20the%20instructions%20to%20set%20me%20up%20for%20ABDM%20integration%20from%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fagent-setup%2Fprompt.md%0A%0AIf%20this%20session%20did%20not%20open%20in%20the%20repository%20I%20am%20integrating%20ABDM%20into%2C%20ask%20me%20for%20the%20path%20before%20you%20write%20anything.) Opens ChatGPT with the setup preloaded. It answers from this site, and writes nothing into your project. **Any agent** `Fetch and execute the instructions to set me up for ABDM integration from https://abdm-docs.dev.eka.care/agent-setup/prompt.md` One line, any agent that can fetch a URL. The instructions live on this site and are rebuilt with it. The setup also connects the [Docs MCP server](/docs/hiecm/v3/getting-started/build-with-ai#connect-the-docs-mcp-server): the live version of these docs, queried by your agent as it works. ## Install a skill One file per job, in three shapes. A module skill carries every endpoint, header, error code and test case for that milestone, provider side (M1 to M4) or patient side (P1 to P3). A scaffold or debug skill is a procedure instead: it works against the sandbox in a loop that ends on an observed result, not on a call returning 200. Those exist for M1 to M3, the milestones the catalogue has flows and errors for. The FHIR skills build or audit NRCES compliant bundles. M1 agent skill The whole of M1: the calls, the loop that builds them, every error code and the tests. [SKILL.md](/skills/abdm-m1/SKILL.md "The router. Use the command below to take the references with it.") - ScaffoldThe loop that builds the module flow by flow against the sandbox, ending on an observed result rather than on a call returning 200. - Integrate55 operations, with their hosts, headers and the rules that hold across them. - Debug89 recorded error codes, each with its message and what to do about it. - Test122 test cases, each with the call it makes and what to see when it passes. `mkdir -p .claude/skills/abdm-m1/references && curl -fsSL https://abdm-docs.dev.eka.care/skills/abdm-m1/SKILL.md -o .claude/skills/abdm-m1/SKILL.md && for f in scaffold integrate debug test; do curl -fsSL https://abdm-docs.dev.eka.care/skills/abdm-m1/references/$f.md -o .claude/skills/abdm-m1/references/$f.md; done` [Open in Claude](claude://code/new?q=Install%20the%20ABDM%20M1%20agent%20skill%20into%20this%20project%2C%20then%20help%20me%20use%20it.%0A%0ARun%20this%3A%0Amkdir%20-p%20.claude%2Fskills%2Fabdm-m1%2Freferences%20%26%26%20curl%20-fsSL%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fskills%2Fabdm-m1%2FSKILL.md%20-o%20.claude%2Fskills%2Fabdm-m1%2FSKILL.md%20%26%26%20for%20f%20in%20scaffold%20integrate%20debug%20test%3B%20do%20curl%20-fsSL%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fskills%2Fabdm-m1%2Freferences%2F%24f.md%20-o%20.claude%2Fskills%2Fabdm-m1%2Freferences%2F%24f.md%3B%20done%0A%0AIf%20this%20session%20did%20not%20open%20in%20the%20repository%20I%20am%20integrating%20ABDM%20into%2C%20ask%20me%20for%20the%20path%20before%20you%20write%20anything.) Drops the skill into this project. Claude loads it when a task matches. How to use it 1. Run the command above in the repository you are integrating. 2. Ask your agent for the job in your own words. "Add ABHA creation by Aadhaar OTP to this codebase", "why am I getting ABDM-1001", or "write the M1 tests for this". The skill loads when the task matches it. 3. Check what it writes against these pages. The skill carries the facts, not the sandbox: nothing in it has been run against ABDM. 4. Open in Claude needs that app installed. It fills the composer and waits: nothing runs until you read it and press Enter. Download all skills - [ABHA identity (M1)](https://abdm-docs.dev.eka.care/skills/abdm-m1/SKILL.md) - [Link and share records (M2)](https://abdm-docs.dev.eka.care/skills/abdm-m2/SKILL.md) - [Consent and fetching (M3)](https://abdm-docs.dev.eka.care/skills/abdm-m3/SKILL.md) - [Registries (M4)](https://abdm-docs.dev.eka.care/skills/abdm-m4/SKILL.md) - [PHR identity (P1)](https://abdm-docs.dev.eka.care/skills/abdm-p1/SKILL.md) - [PHR linking (P2)](https://abdm-docs.dev.eka.care/skills/abdm-p2/SKILL.md) - [PHR consent (P3)](https://abdm-docs.dev.eka.care/skills/abdm-p3/SKILL.md) - [PHR extras](https://abdm-docs.dev.eka.care/skills/abdm-phr-services/SKILL.md) - [FHIR bundles](https://abdm-docs.dev.eka.care/skills/abdm-fhir/SKILL.md) ## Prompting an agent to build against ABDM An agent with this site loaded still writes a plausible integration rather than a correct one, because the parts of ABDM that catch people are the parts a model cannot infer. Tell it these, and check its output against them. | Tell it | Because | | --------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Look the operation up here before writing the call | NHA's v3 differs from the v1 and v2 an agent was trained on. The MCP server above is this site answering live, so it cannot be recalling an older shape | | Identifiers are encrypted, and the plaintext has a shape | An agent encrypts what looks like the value. An ABHA number keeps its dashes, and the bare digits are refused. See [encryption](/docs/hiecm/v3/concepts/encryption) | | Callbacks are how the answer arrives, from M2 onward | Left alone, an agent writes a synchronous call and a response handler for a flow where the 202 means accepted and nothing else. See [the gateway](/docs/hiecm/v3/concepts/gateway) | | Do not invent an error code or an endpoint | Both exist here in full. An invented `ABDM-` code is indistinguishable from a real one until somebody hits it | | One bridge serves every facility, so the callback URL and the credentials are not facility settings | Left alone, an agent builds a settings screen per facility and puts them on it. That works for the first facility. See [one bridge, many facilities](/docs/hiecm/v3/concepts/how-it-fits#one-bridge-many-facilities) | | Aadhaar numbers, one time passwords and passwords never reach a log, a fixture or a test | An agent writing test data will otherwise put a real looking Aadhaar number in your repository | Point it at [Build it well](/docs/hiecm/v3/getting-started/build-it-well) for the handling rules themselves: what to validate, what each error means, what is safe to retry, and what the screen should say. ## Read this site as an agent `llms.txt` is a map of every page here; `llms-full.txt` is every page's text in one file. Add `/index.md` to any URL on this site to get that page as plain Markdown, no scraping required. [View llms.txt](/llms.txt)[View llms-full.txt](/llms-full.txt)[This page as Markdown](/docs/hiecm/v3/getting-started/build-with-ai/index.md) ## Ask AI Ask this catalogue a question directly, without setting anything up. The same assistant sits in the search box at the top of every page, labelled "Search or ask AI". --- # Quickstart You create a test [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) here, with your own sandbox credentials, in four calls that run live from this page: create a session, encrypt the Aadhaar number, request an OTP, create the account. ## Before you start Have your `clientId` and `clientSecret` ([get them](/docs/hiecm/v3/getting-started/sandbox)) and a sandbox test identity: an Aadhaar number issued to you for sandbox use, with access to the mobile number registered against it, because that is where the OTP goes. ### Create a gateway session Exchange your sandbox client id and secret for the access token every later call carries. clientIdclientSecret sensitiveHeld in this page only while the tab is open. It is never written to storage and never put in a URL. ### Encrypt the Aadhaar number Fetch NHA's public certificate, then encrypt the number here in your browser. NHA never accepts a raw Aadhaar number. Create a session first. Fetching the certificate needs the access token. ### Request the OTP NHA sends a one time password to the mobile number registered against that Aadhaar, and hands you a transaction id. Encrypt the Aadhaar number first. This call takes the encrypted value, never the raw one. ### Create the ABHA Send the OTP with the transaction id. This call creates a real account on the sandbox, so send it once. Request an OTP first. This call needs the transaction id that came back with it. ## How this fits your product The registration desk is where most of this lands. Your intake screen either finds the patient's existing ABHA or creates one on the spot, which is the flow you just ran. The token from step 1 is not specific to ABHA creation: it is the token every later ABDM call carries, so whatever your system does next starts by getting one. Once the patient has an ABHA, records attach to it, and that is a different module. - **Session, step 1.** Every call in every module carries this token. Mint it once, watch `expiresIn`, refresh it before it lapses. - **Identity, [M1](/docs/hiecm/v3/milestones/m1).** Creating and verifying an ABHA at intake, which is the runner above. - **Linking, [M2](/docs/hiecm/v3/milestones/m2).** Telling ABDM that you hold records for that ABHA, and sending them when they are asked for. - **Reading, [M3](/docs/hiecm/v3/milestones/m3).** Requesting consent and fetching records held by somebody else. [Your integration path](/docs/hiecm/v3/milestones) sets out which of these you need and in what order. ## If a call fails Under the four steps you get the request each call sent and the response it got back, including the error body. A 401 on the session call usually means the credentials or the `X-CM-ID` header, so see [Everything returns 401](/docs/hiecm/v3/troubleshooting/everything-returns-401). A rejected `loginId` may be the encryption rather than the number. The runner uses RSA-OAEP, which is the only RSA encryption a browser offers, and leaves the digest as a control you can change. [Encryption](/docs/hiecm/v3/concepts/encryption) sets out what is confirmed and what is not. ## Next [Your integration path](/docs/hiecm/v3/milestones). --- # Glossary Every term the HIE-CM documentation links to. Each row keeps its own anchor, so a link like `#hip` lands on the right row. The other gateways carry their own terms: [UHI](/docs/uhi/v1/getting-started/glossary), [NHCX](/docs/nhcx/v1/getting-started/glossary). ## Across ABDM These terms mean the same thing on every ABDM gateway. ### ABDM Ayushman Bharat Digital Mission, India's national programme for digital health, run by the [NHA](#nha). ABDM sets the identifiers, the registries and the exchange rules that let a health record move from the system that created it to the person it belongs to. ### ABHA Ayushman Bharat Health Account. It comes in two forms people confuse: the 14 digit [ABHA number](#abha-number) and the readable [ABHA address](#abha-address). When a document says "the patient's ABHA", work out which of the two it means before you write code against it. ### ABHA address A readable name on the [HIE-CM](#hie-cm), such as `name@abdm`, used to reach health records and share them with a provider. Every ABHA number is issued a default address made from the number itself: `14digit@sbx` in [sandbox](#sandbox), `14digit@abdm` in production. A person can also create an ABHA address without holding an ABHA number, using mobile number, name, age and gender. ### ABHA number A 14 digit identifier issued to a person only after a [KYC](#kyc) check passes, and the identity anchor of ABDM: one person, one number. An ABHA number carries a check digit and validates under the Luhn algorithm. See [M1](/docs/hiecm/v3/getting-started/glossary#m1) for how one is created. ### FHIR Fast Healthcare Interoperability Resources, the HL7 standard ABDM uses to carry health records. ABDM uses FHIR R4 with the profiles published by NRCES at [nrces.in/ndhm/fhir/r4](https://nrces.in/ndhm/fhir/r4/index.html). Every record you share travels as a FHIR bundle of type `document` whose first entry is a Composition. ### Gateway The routing layer for ABDM: you do not call another participant directly, you call the gateway, it forwards your request, and the reply arrives at your [bridge](/docs/hiecm/v3/getting-started/glossary#bridge) as a separate inbound call. You get a session token first, by posting your client id and client secret to `/api/hiecm/gateway/v3/sessions`. Two sandbox hosts serve that path, `https://apissbx.abdm.gov.in` and `https://dev.abdm.gov.in`. Take the host from your onboarding documentation and keep it in configuration; see [Choose your gateway](/docs/hiecm/v3). ### Health Tech Committee The committee that reviews your integration at the end of the sandbox exit process, referred to as the HTC. Once your functional testing, security audit and exit form are complete, it is scheduled its own demonstration, separate from the one you give the integration team earlier. Its decision is recorded in four review stages, each carrying its own reviewer, comment and date. See [Go live](/docs/hiecm/v3/getting-started/going-live). ### HFR Health Facility Registry, the national directory of health facilities across modern and traditional systems of medicine, public and private, including hospitals, clinics, diagnostic laboratories, imaging centres and pharmacies. A facility enrols once and receives a facility ID that identifies it everywhere in ABDM. See [registries](/docs/hiecm/v3/registries). ### HIE-CM Health Information Exchange and Consent Manager, the component that routes exchange requests and manages patient consent. It is data blind: it holds identifiers and metadata about [care contexts](/docs/hiecm/v3/getting-started/glossary#care-context), never the content of a record. See [The ABDM gateway](/docs/hiecm/v3/concepts/gateway). ### HPID Healthcare Professional ID: a 14 digit number issued to a healthcare professional or a facility manager after Aadhaar authentication. It is the professional's digital identity across ABDM, and it is created on the [HPR](#hpr). See [M4](/docs/hiecm/v3/getting-started/glossary#m4). ### HPR Healthcare Professionals Registry, the national registry of doctors, nurses, pharmacists and other healthcare professionals. Registering a professional there issues an [HPID](#hpid). The HPR token is also used when onboarding a facility to the [HFR](#hfr). ### KYC Know Your Customer: the identity check that must pass before an [ABHA number](#abha-number) is issued. In ABDM the check runs against Aadhaar, by one of four methods: an [OTP](#otp) to the Aadhaar linked mobile number, face authentication, fingerprint or IRIS capture on a registered device, or a demographic match. Re-KYC repeats the check on an ABHA number that already exists. ### NHA National Health Authority, the government body that runs ABDM, publishes its specifications, and operates both the [sandbox](#sandbox) and the production gateways. ### NHCX National Health Claims Exchange, ABDM's network for insurance claims between providers and payers, with its own sandbox and its own document set at [hcxsbx.abdm.gov.in](https://hcxsbx.abdm.gov.in). See [NHCX](/docs/nhcx/v1). ### OTP One Time Password: a short code sent to a mobile number or an email address to prove the person holds it. ABDM uses OTPs at many points: Aadhaar [KYC](#kyc), mobile number verification during ABHA creation, and login. An OTP is always paired with a transaction id from the call that requested it. ### PHR Personal Health Record, a patient facing application: the person logs in with their [ABHA address](#abha-address), discovers records held by facilities they visited, links them, and reads them. PHR apps subscribe to a patient's ABHA address and are notified when a new [care context](/docs/hiecm/v3/getting-started/glossary#care-context) is linked. See [PHR applications](/docs/hiecm/v3/concepts/phr). ### Safe to Host certificate The certificate a [WASA](#wasa) produces, issued by a CERT-In empanelled auditor, and required before you receive production credentials. It names the application it covers and carries an issue date and an expiry date. A certificate that is in date covers a new module without a fresh audit of the parts already certified. See [Security audit](/docs/hiecm/v3/getting-started/security-audit). ### Sandbox The ABDM test environment, and where every integration starts: you register on the sandbox portal, declare your role and the milestones you plan to complete, and receive a client id and client secret. Sandbox hosts differ from production, so ABHA calls go to `abhasbx.abdm.gov.in` in sandbox and `abha.abdm.gov.in` in production. Everything in sandbox is test data; see [Get started](/docs/hiecm/v3/getting-started/sandbox). ### txnId Transaction id. Most flows take two or three calls, and the first one returns a `txnId` that the calls after it send back, so ABDM knows which attempt they belong to. It is short lived and single purpose. It is not a session and it is not a token: holding a `txnId` does not authenticate you, and it stops working once the flow it belongs to finishes or expires. ### UHI Unified Health Interface, an open protocol network for health services that are not record exchange: physical consultation booking, ambulance booking, blood bank discovery, Jan Aushadhi and pharmacy search. It has two roles, [EUA](/docs/uhi/v1/getting-started/glossary#eua) on the consumer side and [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) on the provider side, and every call is signed with Ed25519. See [UHI](/docs/uhi/v1). ### WASA The security audit of your application, conducted on your staging URL by an auditor from the CERT-In empanelled list. It produces the [Safe to Host certificate](#safe-to-host-certificate), and it is separate from functional testing: passing every milestone still leaves this to do. Each platform you ship is audited on its own. See [Security audit](/docs/hiecm/v3/getting-started/security-audit). ## On HIE-CM These terms belong to HIE-CM: the roles, the consent objects and the four milestones. ### Bridge The set of callback endpoints your system exposes to the [gateway](#gateway). A bridge is your integration, not a facility: one bridge URL is stored for each registered participant, every facility you link to that bridge shares it, and callbacks are posted underneath it. The paths are `POST {hiuBridgeUrl}/v0.5/consents/hiu/notify` for an [HIU](#hiu) and `POST {hipBridgeUrl}/v0.5/health-information/hip/request` for a [HIP](#hip). Registering your bridge URL is part of sandbox onboarding. ### Care context A group of a patient's health records, defined by your system. It carries two fields and nothing else: a reference number, which is your own internal identifier, and a display name a person can read, which must not carry clinical detail such as a diagnosis or a test result because it is shown before consent. Use one care context per outpatient visit and one per inpatient admission. ### Consent artefact The record of a consent the patient granted. It names the patient, the requesting [HIU](#hiu), the [HI types](#hi-type) covered, the [purpose of use](#purpose-of-use), the date range of records allowed and an expiry. An HIU quotes the consent artefact id when it asks for data, and the [HIP](#hip) checks that id, and its date range, before it sends anything. ### Consent manager The component that holds consent on the patient's behalf. In ABDM that component is the [HIE-CM](#hie-cm). It receives consent requests, shows them to the patient, records the grant or the denial, and tells both the requester and the record holder what the patient decided. ### Discovery The step where a patient's [PHR](#phr) app asks a facility whether it holds records for that patient. The [HIE-CM](#hie-cm) forwards the request to the [HIP](#hip) with verified identifiers (ABHA address, mobile number, name, gender, year of birth) and any unverified identifier the patient typed, such as a hospital patient ID. Your system matches those against your own patients and replies with a list of [care contexts](#care-context), carrying no clinical detail. ### ECDH Elliptic Curve Diffie-Hellman key exchange, used so that only the [HIU](#hiu) that holds a valid consent can read the records a [HIP](#hip) sends. Both sides generate a short lived key pair and a random 32 byte nonce, exchange the public halves, and derive the same session key. The exchange uses Curve25519, and the encryption itself uses AES-GCM. ### EMR, EHR Electronic Medical Record and Electronic Health Record: the clinical system a hospital or a clinic records consultations, prescriptions and results in. The distinction drawn is that an EMR holds one provider's record of what happened in their own building and an EHR follows the patient across providers, but vendors use the two words for the same product. A facility uses it to publish records as the [HIP](#hip), linking care contexts in [M2](#m2), and to fetch them as the [HIU](#hiu) in [M3](#m3). ABDM does not build an EHR as a database: the records stay with the facility that created them, and the [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) plus consent is what lets another provider assemble the picture. See [Hospital, lab and pharmacy systems](/docs/hiecm/v3/concepts/hip-hiu). ### HI type Health Information type: the kind of record being asked for or shared, used in consent requests and in data requests. There are seven values: `Prescription`, `DiagnosticReport`, `OPConsultation`, `DischargeSummary`, `ImmunizationRecord`, `HealthDocumentRecord` and `WellnessRecord`. The M2 error message for an invalid HI type also lists `Invoice`. ### HIP Health Information Provider: the role an entity takes when it publishes a health record. A hospital, laboratory or pharmacy takes it through its own software, and a citizen takes it through a [PHR](#phr) app. The HIP links [care contexts](#care-context) to a patient's [ABHA address](#abha-address), answers [discovery](#discovery), and sends encrypted records when a valid [consent artefact](#consent-artefact) exists. [M2](#m2) is the HIP milestone. ### HIU Health Information User: whoever asks to read records they did not create is the HIU. A facility asks through a doctor's console or its [HMIS](#hmis), a citizen asks through a [PHR](#phr) app or a health locker, and an insurer, a referral tool or an analytics product asks while holding neither an [ABHA address](#abha-address) nor a facility ID. The HIU raises a consent request, waits for the patient's decision, and fetches data only under a granted [consent artefact](#consent-artefact). [M3](#m3) is the HIU milestone. ### HMIS, HIS, HIMS The software a hospital runs day to day: registration, visits, orders, results and billing. Three names for it: HMIS is Hospital Management Information System, HIS is Hospital Information System, HIMS is Hospital Information Management System. A facility uses it to publish records as the [HIP](#hip) and to fetch them as the [HIU](#hiu), so the ABDM work is [M2](#m2) and [M3](#m3) either way, and it must implement every [HI type](#hi-type). Note that `HIS-` is also the prefix on every error code the HPR and the HFR return: those are [M4](#m4) registry errors and nothing to do with hospital software. See [Hospital, lab and pharmacy systems](/docs/hiecm/v3/concepts/hip-hiu). ### HRP Health Repository Provider. HRP is whoever holds the records, which is custody rather than a direction of travel. That is the facility in most integrations, and its repository software is how the facility holds them. Where a facility's records sit with another organisation, that organisation is the HRP. HRP and HIP are written together as "HRP/HIP" because the entity holding the records is usually the entity publishing them. If you run an [HMIS](#hmis) or a [LIMS](#lims) for a facility integrating [M2](#m2), that facility is the HRP. One repository can hold the records of many facilities. ### IMS Information Management System, the umbrella term for the software a health facility runs: an [HMIS](#hmis) in a hospital, an [EMR](#emr) in a clinic, a [LIMS](#lims) in a laboratory, a [PMS](#pms) in a pharmacy. IMS is one of the two integrator roles on HIE-CM, the other being [PHR](#phr), and it is fixed for the life of your product. Which of those systems you build does not change the integration: the facility is the [HIP](#hip) when it publishes and the [HIU](#hiu) when it fetches, so the work is [M2](#m2) and [M3](#m3) either way. ### LIMS, LMIS Laboratory Information Management System, also written LMIS: the system a diagnostic lab uses to record orders, samples and results. A laboratory uses it to publish records as the [HIP](#hip), linking each report as a care context in [M2](#m2), which is most of what a lab does, and to fetch them as the [HIU](#hiu) on the rarer occasions it reads a patient's history. See [Hospital, lab and pharmacy systems](/docs/hiecm/v3/concepts/hip-hiu). ### Link token The token that authorises your system to link a [care context](#care-context) to a patient's [ABHA address](#abha-address); your system obtains it when the patient registers and stores it against that patient. A link token is valid for six months. Validate it before use. If you do not hold a valid one, regenerate it through demographic authentication before you link. ### M1 Milestone 1, ABHA identity: creating an [ABHA number](#abha-number), logging a person in, reading and updating their profile, downloading the ABHA card, and the [gateway](#gateway) session and token calls that everything else depends on. Most of these APIs are mandatory for both private and government integrators, with Aadhaar demographic authentication the exception: mandatory for government integrators, not required for private ones. See [M1](/docs/hiecm/v3/api/m1). ### M2 Milestone 2, sharing records as a [HIP](#hip): turning your records into [FHIR](#fhir) bundles, grouping them into [care contexts](#care-context), linking those to a patient's [ABHA address](#abha-address), answering [discovery](#discovery), and encrypting and pushing data when consent allows. See [M2](/docs/hiecm/v3/api/m2). ### M3 Milestone 3, consent and reading records as an [HIU](#hiu): raising a consent request, tracking its status, handling the grant or denial callback, fetching the [consent artefact](#consent-artefact), requesting health information and decrypting what arrives. See [M3](/docs/hiecm/v3/api/m3). ### M4 Milestone 4, the registries: creating an [HPID](#hpid) on the [HPR](#hpr) and onboarding a facility to the [HFR](#hfr). This is also called NHPR. See [M4](/docs/hiecm/v3/api/m4). ### PMS Pharmacy Management System: the software a pharmacy runs to dispense and to keep its stock. A pharmacy uses it to fetch the prescription it is dispensing against as the [HIU](#hiu), and to publish what it dispensed as the [HIP](#hip). See [Hospital, lab and pharmacy systems](/docs/hiecm/v3/concepts/hip-hiu). ### Purpose of use The reason an [HIU](#hiu) gives for asking for records; it travels in the consent request and the patient sees it. The codes are a subset of HL7's v3 PurposeOfUse value set: `CAREMGT` (care management), `BTG` (break the glass), `PUBHLTH` (public health), `HPAYMT` (healthcare payment), `DSRCH` (disease specific healthcare research) and `PATRQT` (self requested). --- # Go live Working in the sandbox is not the same as being live. One exit process sits between the two, and you run it once, at the end. ## In short - There is no per milestone submission. The exit process covers your whole integration, once. - It has four steps, in a fixed order, and it opens with a demonstration. - You demonstrate twice, to two different audiences. - The [security audit](/docs/hiecm/v3/getting-started/security-audit) is separate from functional testing, and both feed the exit form. - Production credentials are issued at the end. They are not your sandbox values. ## Prerequisites Every milestone your integration needs works end to end. [Your integration path](/docs/hiecm/v3/milestones) says which ones apply to a citizen using a [PHR](/docs/hiecm/v3/getting-started/glossary#phr) application, and which to a facility publishing as the [HIP](/docs/hiecm/v3/getting-started/glossary#hip) or fetching as the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu). Start the exit process once all of them are complete, not milestone by milestone. ## 1. Demonstrate what you built You demonstrate the [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) functionality you built to the integration team. This is the first of two demonstrations, and it opens the process rather than closing it. ## 2. Complete functional testing and the security audit Empanelled agencies run both, after the demonstration. They are separate exercises with separate outputs: functional testing produces a report and a certificate, and the security audit produces the [Safe to Host certificate](/docs/hiecm/v3/getting-started/glossary#safe-to-host-certificate). [Security audit](/docs/hiecm/v3/getting-started/security-audit) covers who may audit you, which URL they audit, and how many audits your platforms need. ## 3. Submit the exit form Upload the exit form on the sandbox with four things: | What you upload | Comes from | | --------------------------------------------- | ------------------------------- | | The functional testing report and certificate | Your empanelled testing agency | | The security audit report | Your CERT-In empanelled auditor | | A signed undertaking | You | | Any other supporting document requested | The integration team | Confirm the format of the report and the undertaking with the integration team before you assemble them. ## 4. Demonstrate to the Health Tech Committee Once the earlier steps are complete, a demonstration is scheduled for the [Health Tech Committee](/docs/hiecm/v3/getting-started/glossary#health-tech-committee). Different audience, different demonstration. The committee records its decision in four review stages, each carrying its own reviewer and date, so the outcome arrives as a sequence rather than a single answer. ## 5. Switch to the production base URLs Production credentials are issued once the exit process completes. | What you call | Sandbox | Production | | ---------------------------------------------------------------- | ------------------------------------------ | ------------------------------------------- | | The gateway | `https://dev.abdm.gov.in`, `X-CM-ID: sbx` | `https://apis.abdm.gov.in`, `X-CM-ID: abdm` | | The [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) service | `https://abhasbx.abdm.gov.in/abha/api/v3/` | `https://abha.abdm.gov.in/api/abha/v3/` | A production client id against a sandbox host, or the reverse, fails. ## What you see when it works You hold a production client id and client secret, and a call that worked in the sandbox returns the same result against the production host. ## When it goes wrong If a call that worked in the sandbox fails in production, check the base URL and the `X-CM-ID` header first. See [Everything returns 401](/docs/hiecm/v3/troubleshooting/everything-returns-401). Questions about the exit process itself, including where to submit the form or what counts as a valid supporting document, go to [Support](/docs/support). ## Next steps - Get the audit that feeds step 2: [Security audit](/docs/hiecm/v3/getting-started/security-audit). - Hand your integration to an agent: [Build with AI](/docs/hiecm/v3/getting-started/build-with-ai). --- # Get started Connect your application to India's health data network. ## What ABDM is The Ayushman Bharat Digital Mission is India's national health data network. It identifies the people and the places involved in care, and lets the systems that hold the records exchange them with the person's consent. There is no central store of health records. Records stay in the system that created them. What the network moves is a request, a consent and, once that consent is granted, the records themselves, encrypted between the two systems. The exchange itself is data blind: it works with identifiers and metadata about where records live, and does not read what is in them. Three gateways carry different work, and this section documents the first. | Gateway | What it carries | | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) | Care seeker ([ABHA](/docs/hiecm/v3/getting-started/glossary#abha)) and care provider ([HPR](/docs/hiecm/v3/getting-started/glossary#hpr), [HFR](/docs/hiecm/v3/getting-started/glossary#hfr)) identities, care contexts, consent and health records | | [UHI](/docs/uhi/v1) | Finding and booking a health service | | [NHCX](/docs/nhcx/v1) | Health insurance claims | Your work on HIE-CM is four milestones, and they spell [CARE](/docs/hiecm/v3/milestones): Create the identity, Attach your records to it, Retrieve records held elsewhere, Enrol your facility and your professionals. ## Who are you? This is where you choose your path. Pick the one that fits and the rest of the documentation follows it, in the sidebar and on every page. You can change it whenever you like from the filter at the top of the sidebar. ## Start here: build with AI Your coding agent can read every page, every endpoint and every error code on this site. Set your agent up in one step Open your agent with the setup ready to send, or copy it. Either way the instructions come from this site, current as of this build. **Claude** `claude plugin marketplace add eka-care/abdm-docs && claude plugin install abdm-integrators-assistant@abdm-portal` [Open in Claude](claude://code/new?q=Set%20this%20project%20up%20for%20ABDM%20integration.%20Run%3A%0A%0Aclaude%20plugin%20marketplace%20add%20eka-care%2Fabdm-docs%0Aclaude%20plugin%20install%20abdm-integrators-assistant%40abdm-portal%0A%0AIf%20the%20marketplace%20add%20fails%20\(the%20repository%20may%20not%20be%20accessible\)%2C%20instead%20fetch%20and%20execute%20the%20instructions%20from%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fagent-setup%2Fprompt.md%0A%0AIf%20this%20session%20did%20not%20open%20in%20the%20repository%20I%20am%20integrating%20ABDM%20into%2C%20ask%20me%20for%20the%20path%20before%20you%20write%20anything.) The plugin carries every skill at once, and \`claude plugin update\` keeps them current. **Cursor** `Fetch and execute the instructions to set me up for ABDM integration from https://abdm-docs.dev.eka.care/agent-setup/prompt.md` [Open in Cursor](cursor://anysphere.cursor-deeplink/prompt?text=Fetch%20and%20execute%20the%20instructions%20to%20set%20me%20up%20for%20ABDM%20integration%20from%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fagent-setup%2Fprompt.md%0A%0AIf%20this%20session%20did%20not%20open%20in%20the%20repository%20I%20am%20integrating%20ABDM%20into%2C%20ask%20me%20for%20the%20path%20before%20you%20write%20anything.) Opens Cursor with the prompt in the composer. It fetches the current instructions from this site. **Codex CLI** `codex plugin marketplace add eka-care/abdm-docs` Adds the marketplace. Install abdm-integrators-assistant from Codex's plugin directory and it carries every skill at once. **ChatGPT** `Fetch and execute the instructions to set me up for ABDM integration from https://abdm-docs.dev.eka.care/agent-setup/prompt.md` [Open in ChatGPT](https://chatgpt.com/?q=Fetch%20and%20execute%20the%20instructions%20to%20set%20me%20up%20for%20ABDM%20integration%20from%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fagent-setup%2Fprompt.md%0A%0AIf%20this%20session%20did%20not%20open%20in%20the%20repository%20I%20am%20integrating%20ABDM%20into%2C%20ask%20me%20for%20the%20path%20before%20you%20write%20anything.) Opens ChatGPT with the setup preloaded. It answers from this site, and writes nothing into your project. **Any agent** `Fetch and execute the instructions to set me up for ABDM integration from https://abdm-docs.dev.eka.care/agent-setup/prompt.md` One line, any agent that can fetch a URL. The instructions live on this site and are rebuilt with it. The setup also connects the [Docs MCP server](/docs/hiecm/v3/getting-started/build-with-ai#connect-the-docs-mcp-server): the live version of these docs, queried by your agent as it works. More ways to set one up are on [Build with AI](/docs/hiecm/v3/getting-started/build-with-ai). ## Start building [Get your sandbox credentials](/docs/hiecm/v3/getting-started/sandbox) [Register and get a client id and secret.](/docs/hiecm/v3/getting-started/sandbox) [Quickstart](/docs/hiecm/v3/getting-started/first-fifteen-minutes) [Create your first test ABHA live, with your own credentials.](/docs/hiecm/v3/getting-started/first-fifteen-minutes) [Milestones](/docs/hiecm/v3/milestones) [The four milestones and what each one gets you.](/docs/hiecm/v3/milestones) [Build with AI](/docs/hiecm/v3/getting-started/build-with-ai) [Skills, MCP server and prompts for your coding agent.](/docs/hiecm/v3/getting-started/build-with-ai) [Go live](/docs/hiecm/v3/getting-started/going-live) [What certification and the exit process involve.](/docs/hiecm/v3/getting-started/going-live) [Fix what broke](/docs/hiecm/v3/troubleshooting) [Start from the symptom you are seeing, not the error code.](/docs/hiecm/v3/troubleshooting) ## Common use cases [I want to create an ABHA](/docs/hiecm/v3/milestones/m1) [Identity for every patient, created and verified.](/docs/hiecm/v3/milestones/m1) [I want to share health records](/docs/hiecm/v3/milestones/m2) [Link care contexts and serve them under consent.](/docs/hiecm/v3/milestones/m2) [I want to read records held elsewhere](/docs/hiecm/v3/milestones/m3) [Request consent, fetch and decrypt.](/docs/hiecm/v3/milestones/m3) [I want to build a patient's health app](/docs/hiecm/v3/milestones/p1) [ABHA login, record discovery, consent control.](/docs/hiecm/v3/milestones/p1) [I want to register a facility or professional](/docs/hiecm/v3/milestones/m4) [Get the ids every call needs.](/docs/hiecm/v3/milestones/m4) ## More resources [Explore every API](/docs/hiecm/v3/api) [The full reference, with try-it.](/docs/hiecm/v3/api) [How consent works](/docs/hiecm/v3/concepts/consent) [The one concept you must understand.](/docs/hiecm/v3/concepts/consent) --- # Get your sandbox credentials Every [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) call carries a token, and every token starts with a client id and a client secret. Here is how you get them. ## Before you start You need an organisation to register, and a URL we can post callbacks to. Step 3 says what that URL has to do. ## 1. Register on the sandbox Create an account on the sandbox application and register your organisation. [Register on the sandbox](https://sandbox.abdm.gov.in/sandbox/v3/sandbox-registration) ## 2. Get your client id and client secret Sign in to the sandbox application. Your `clientId` and `clientSecret` are issued there. Store the secret the way you store any other production credential. Never commit it, and never send it to a browser. [Open the sandbox](https://sandbox.abdm.gov.in/) ## 3. Register your callback URL In [M1](/docs/hiecm/v3/api/m1) the answer comes back in the response to your call. In [M2](/docs/hiecm/v3/api/m2) and [M3](/docs/hiecm/v3/api/m3) it does not. The response only acknowledges your request, and the answer arrives afterwards as a POST to a URL you registered. Register one base URL. We post to paths under it, and every callback carries the `REQUEST-ID` you sent on the original call, so you can match the answer to the question. Each path is named on the page of the call it belongs to, in the [API reference](/docs/hiecm/v3/api). One URL covers your whole integration, however many facilities it serves. It belongs to your bridge, never to a facility, and the callback names the facility it is for in its own header. See [one bridge, many facilities](/docs/hiecm/v3/concepts/how-it-fits#one-bridge-many-facilities). [Open the sandbox](https://sandbox.abdm.gov.in/) Two things about that URL decide whether your integration works: - **It has to be reachable from the public internet.** If it is not, the flow appears to hang and nothing tells you why. From our side the call succeeded and the callback was sent. - **It has to be listening whether or not you are ready.** We post when the answer is ready, not when you ask for it. In development that usually means a tunnel, and a tunnel gives you a new URL every restart. Register the new one each time. ## 4. Note the base URLs | What you call | Sandbox | | ---------------------------------------------------------------- | --------------------------------------------------------- | | The gateway, including the session call | `https://dev.abdm.gov.in`, with the header `X-CM-ID: sbx` | | The [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) service | `https://abhasbx.abdm.gov.in/abha/api/v3/` | More than one sandbox host appears across our published documents. [The ABDM gateway](/docs/hiecm/v3/concepts/gateway) lists every host and where each one is written down. ## What you see when it works You hold three things: a `clientId`, a `clientSecret`, and a callback URL registered against them. Nothing has been called yet. ## Next [Make your first call](/docs/hiecm/v3/getting-started/first-fifteen-minutes). --- # Security audit Every application passes a security audit before it reaches production. The audit is called a [WASA](/docs/hiecm/v3/getting-started/glossary#wasa), and it produces the [Safe to Host certificate](/docs/hiecm/v3/getting-started/glossary#safe-to-host-certificate) you upload with your exit form. ## In short - The audit is separate from anything functional. Passing every milestone still leaves this to do. - Your auditor comes from the CERT-In empanelled list. An audit by anyone else does not count. - The audit runs on your staging URL, and the certificate then licenses the same application in production. - Each platform you ship is audited on its own. A website, an Android app and an iOS app need three. - A certificate that is in date covers a new module without re-auditing what it already covers. ## Prerequisites Build the modules you intend to certify before you apply. An audit covering several modules can only cover modules that exist. ## 1. Appoint an auditor Choose an auditor from the [CERT-In empanelled list](https://www.cert-in.org.in/PDF/Empanel_org_2021.pdf). ## 2. Point the auditor at staging The audit is conducted on your staging URL. The certificate it produces then licenses the same application in production. An auditor pointed at a live production URL is working the wrong way round. ## 3. Cover every platform you ship One audit covers one platform. An audit of a shared [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) base URL does not cover the mobile applications that call it. ## What gets audited Scope depends on what you have certified before. | Your situation | What the auditor covers | | --------------------------------------------------- | ------------------------------------------------------------ | | Nothing audited before | The whole application | | Adding a module to an application already certified | The new module alone, subtracting the part already certified | | Website, Android application, iOS application | Three separate audits, one for each | | A valid Safe to Host certificate already in hand | Nothing, until that certificate expires | ## When you audit again A new audit is required when a change is major, and when a change touches your backend. Minor changes do not trigger one. Your certificate also carries an expiry date, and an expired certificate needs a fresh audit whatever has changed since. ## How you know it worked You hold a Safe to Host certificate that is in date, names the application you are about to run in production, and covers every platform you ship. ## When it goes wrong The three that cost integrators the most time, in order: - **One audit, several platforms.** Three platforms need three certificates. A single certificate naming one of them stops the exit form. - **Auditing production instead of staging.** The audit belongs on staging, and the certificate carries into production from there. - **Treating a backend change as minor.** Anything touching your backend needs a new audit, and the exit gate is an expensive place to discover that. ## Next steps - Run the exit process this certificate feeds into: [Go live](/docs/hiecm/v3/getting-started/going-live). - Ask about a certificate or an auditor: [Support](/docs/support). --- # Milestones Four milestones. You certify them one at a time, in order, and together they spell CARE. ## In short [M1Create and verify the patient's ABHA, the identity every record hangs on.](/docs/hiecm/v3/milestones/m1)[M2Attach the records you hold to that identity: care contexts, linking, and sharing as a HIP.](/docs/hiecm/v3/milestones/m2)[M3Retrieve records held elsewhere, with the patient's consent, as an HIU.](/docs/hiecm/v3/milestones/m3)[M4Enrol your facility and your professionals in the registries, so you can go live.](/docs/hiecm/v3/milestones/m4) M2 needs a facility ID and registration in the HIP role before it can share a record. That ID does not have to come from M4. A facility can be registered by hand on the NHPR portal, and many products do exactly that and never build M4. Build M4 when you want to register facilities or professionals from your own software instead. Either way, get the facility ID early, because M2 cannot be tested end to end without one. ## One patient, four milestones Meera arrives at your clinic. Each card below is one thing your system has to be able to do for her, and one milestone that gives you it. 1. Milestone 1 · CreateRegister Meera's ABHA Meera walks in without a health ID. Create her ABHA so every record from today onwards links to one identity. [Build M1 Create](/docs/hiecm/v3/milestones/m1) 2. Milestone 2 · AttachAttach today's visit to her ABHA Her consultation note and her blood test are yours to hold. Group them into care contexts, link them to her ABHA address, and answer when her app comes looking. [Build M2 Attach](/docs/hiecm/v3/milestones/m2) 3. Milestone 3 · RetrieveRetrieve the scan from another hospital Meera mentions a scan done last year, somewhere else. Ask her for consent, wait for her answer, then fetch and decrypt what she granted. [Build M3 Retrieve](/docs/hiecm/v3/milestones/m3) 4. Milestone 4 · EnrolEnrol the clinic and its doctors None of the above leaves sandbox until the clinic is a registered facility and its doctors hold professional IDs. Enrol both, then link your software to the facility. [Build M4 Enrol](/docs/hiecm/v3/milestones/m4) ## The same story from Meera's own app If you are building the patient's app rather than the clinic's system, you are building a [PHR](/docs/hiecm/v3/getting-started/glossary#phr) application. The work splits into three, and each part mirrors a milestone on the provider side. 1. PHR 1 · Identity and profileMeera signs up and holds her own profile She registers with a mobile number or an existing ABHA number, logs in four different ways, and manages her card, her QR code and her family members. [Build P1](/docs/hiecm/v3/milestones/p1) 2. PHR 2 · Linking and recordsShe finds records she never linked She searches for the hospital she visited last year, sees what it holds, verifies by one time password, and pulls those care contexts onto her ABHA address. [Build P2](/docs/hiecm/v3/milestones/p2) 3. PHR 3 · Consent and notificationsShe decides who sees what A clinic asks for her records. She reads the request, narrows it, grants or denies it, and revokes it later. Your app tells her each time. [Build P3](/docs/hiecm/v3/milestones/p3) ## Which milestones you need Each row below is the entity you build for. HIP and HIU are roles that entity takes, not kinds of software: whoever holds a record and publishes it is the HIP, and whoever asks to read records they did not create is the HIU. | Who you build for | M1 | M2 | M3 | M4 | | ------------------------------------------------------ | ---------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------- | | A facility | Required | The bulk of your build | Where it also reads records it did not create | Required | | An insurer, a referral service or an analytics service | Required | Not needed | The bulk of your build | [Confirm at onboarding](/docs/hiecm/v3/concepts/participants/insurer#confirm-at-onboarding) | | A citizen | [P1](/docs/hiecm/v3/milestones/p1), the patient side | [P2](/docs/hiecm/v3/milestones/p2), the patient side | [P3](/docs/hiecm/v3/milestones/p3), the patient side | Not needed | ## What each milestone gets you | Milestone | What you get | Who needs it | | ------------------------------------------- | ------------------------------------------- | -------------------------------------------------------------- | | [M1 Create](/docs/hiecm/v3/milestones/m1) | Identity and the session token | Everyone | | [M2 Attach](/docs/hiecm/v3/milestones/m2) | Linking and sharing records | A facility publishing records, and a citizen pushing their own | | [M3 Retrieve](/docs/hiecm/v3/milestones/m3) | Consent and record fetching | Anyone reading records they did not create, and every PHR app | | [M4 Enrol](/docs/hiecm/v3/milestones/m4) | A facility ID and professional registration | Anyone going live as a facility | These pages give the steps, the order to build them in and the failure modes. Every request URL, header and body sits on the [API reference](/docs/hiecm/v3/api) pages, one page per call. ## Next Start with [M1 Create](/docs/hiecm/v3/milestones/m1), or read [Go live](/docs/hiecm/v3/getting-started/going-live) for what happens after the fourth certificate. --- # M1 Create: ABHA identity Milestone 1 is the identity milestone of [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm). You create an [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) for a person, log that person in, and read or update their profile. An ABHA number is a 14 digit identifier issued after a [KYC](/docs/hiecm/v3/getting-started/glossary#kyc) check. Every other ABDM flow assumes the person already has one, so nobody skips M1. [Try the M1 APIs](/docs/hiecm/v3/api/m1) [Every call in M1, one page each: the headers it needs, the payload it takes, the callback it triggers, and a request builder you can fire at the sandbox.](/docs/hiecm/v3/api/m1) [Error codes](/docs/hiecm/v3/api/m1/errors) [What each code M1 returns actually means, and the first thing to check when you see one.](/docs/hiecm/v3/api/m1/errors) ## In short - M1 is identity only. It creates and authenticates an ABHA. It moves no health records. - Nothing runs until the gateway session call returns an access token. - Two tokens exist and are not interchangeable: the gateway token in `Authorization`, the user token in `X-token`. NHA's recorded login response gives the user token thirty minutes (`expiresIn: 1800`) and its refresh token fifteen days (`refreshExpiresIn: 1296000`). Read both back from the response rather than assuming them, and plan a refresh before the thirty minutes run out. - Aadhaar numbers, mobile numbers, [OTP](/docs/hiecm/v3/getting-started/glossary#otp) values and passwords travel RSA encrypted. ## What M1 gives you | Capability | What your system can do | | ------------------ | ------------------------------------------------------------------------------------ | | Session and tokens | Get an access token, refresh it, fetch the public certificate | | ABHA creation | Verify the person against Aadhaar, attach a mobile number and an ABHA address | | ABHA login | Sign in a holder by mobile number, Aadhaar number, ABHA number or ABHA address | | Profile management | Read the profile, show the ABHA card and QR code, change the mobile number, redo KYC | | Scan and share | Register a patient who scanned your counter QR code, and hand them a queue token | M1 moves no health records. [M2 Attach](/docs/hiecm/v3/milestones/m2) links them. [M3 Retrieve](/docs/hiecm/v3/milestones/m3) fetches them with consent. ## Who needs it Everyone. A facility publishing as the [HIP](/docs/hiecm/v3/getting-started/glossary#hip), an organisation fetching as the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu), and a citizen using a [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app all hold the session token M1 issues and key their work to an ABHA address. ## Building blocks you use - The [ABHA registry](/docs/hiecm/v3/registries), which holds the ABHA number, address and profile. - The [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) gateway, which issues your session token. See [The ABDM gateway](/docs/hiecm/v3/concepts/gateway). Aadhaar is not an ABDM building block. The ABHA service calls it for you. ## Before you start 1. **Sandbox credentials.** A client ID and secret from [Get started](/docs/hiecm/v3/getting-started/sandbox). 2. **An access token.** From the session API, carried on every M1 call. 3. **The public certificate.** The Aadhaar number, the OTP and the mobile number travel encrypted, so fetch the certificate before you encrypt anything. ## What you build, in order 1. **Session and tokens.** Mandatory. Nothing else in M1 runs until this works. 2. **ABHA creation by Aadhaar OTP.** Mandatory. 3. **ABHA login.** Mandatory, on all four entry points. 4. **User profile and ABHA card.** Mandatory. Plain reads against a token you hold. 5. **Demographic authentication.** Mandatory for government integrators, not for private ones. See [creation by demographic authentication](#abha-creation-by-demographic-authentication). Everything else in M1 is optional for both. Skip all of it and you still complete the milestone. The mandatory and optional split, capability by capability, is on the [M1 API reference](/reference/hiecm-m1). ## Build it with an agent Hand M1 to the agent you already use, as one file it loads once. Install it, or open it there in one click. M1 agent skill Every M1 call, its error codes and its certification cases in one file: 55 operations, 89 codes, 122 cases. [SKILL.md](/skills/abdm-m1/SKILL.md "The router. Use the command below to take the references with it.") - ScaffoldThe loop that builds the module flow by flow against the sandbox, ending on an observed result rather than on a call returning 200. - Integrate55 operations, with their hosts, headers and the rules that hold across them. - Debug89 recorded error codes, each with its message and what to do about it. - Test122 test cases, each with the call it makes and what to see when it passes. `mkdir -p .claude/skills/abdm-m1/references && curl -fsSL https://abdm-docs.dev.eka.care/skills/abdm-m1/SKILL.md -o .claude/skills/abdm-m1/SKILL.md && for f in scaffold integrate debug test; do curl -fsSL https://abdm-docs.dev.eka.care/skills/abdm-m1/references/$f.md -o .claude/skills/abdm-m1/references/$f.md; done` [Open in Claude](claude://code/new?q=Install%20the%20ABDM%20M1%20agent%20skill%20into%20this%20project%2C%20then%20help%20me%20use%20it.%0A%0ARun%20this%3A%0Amkdir%20-p%20.claude%2Fskills%2Fabdm-m1%2Freferences%20%26%26%20curl%20-fsSL%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fskills%2Fabdm-m1%2FSKILL.md%20-o%20.claude%2Fskills%2Fabdm-m1%2FSKILL.md%20%26%26%20for%20f%20in%20scaffold%20integrate%20debug%20test%3B%20do%20curl%20-fsSL%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fskills%2Fabdm-m1%2Freferences%2F%24f.md%20-o%20.claude%2Fskills%2Fabdm-m1%2Freferences%2F%24f.md%3B%20done%0A%0AIf%20this%20session%20did%20not%20open%20in%20the%20repository%20I%20am%20integrating%20ABDM%20into%2C%20ask%20me%20for%20the%20path%20before%20you%20write%20anything.) Drops the skill into this project. Claude loads it when a task matches. How to use it 1. Run the command above in the repository you are integrating. 2. Ask your agent for the job in your own words. "Add ABHA creation by Aadhaar OTP to this codebase", "why am I getting ABDM-1001", or "write the M1 tests for this". The skill loads when the task matches it. 3. Check what it writes against these pages. The skill carries the facts, not the sandbox: nothing in it has been run against ABDM. 4. Open in Claude needs that app installed. It fills the composer and waits: nothing runs until you read it and press Enter. ## Certification M1 has no certification step of its own. One exit process covers the whole integration, run once, after every milestone your role needs works end to end. See [Going live](/docs/hiecm/v3/getting-started/going-live) for the four steps and what each one asks of you. Sandbox test data is in the [data dictionary](/docs/hiecm/v3/reference/data-dictionary). [Support](/docs/support) lists the channels. The cases you are certified against are in [M1 testing use cases](/docs/hiecm/v3/resources/testing/m1). ## The page map There are two identities in M1, and which one you are creating decides every call you make after it. | | ABHA with Aadhaar | ABHA address with a mobile number | | -------------------------- | --------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | What the person ends with | A fourteen digit ABHA number and an ABHA address | An ABHA address, and no ABHA number | | How the profile is marked | KYC Verified | Self-Declared | | What proves who they are | Aadhaar, through one of four routes | The mobile number, and nothing beyond it | | Who gives the demographics | Aadhaar does | The person types them | | Create it | [Four creation routes](#which-creation-route-you-must-build) | [Create the address](#create-the-address) | | Log them in | [By mobile number](#abha-login-by-mobile-number), or by Aadhaar number, ABHA number or ABHA address | [By ABHA address](#log-in-with-an-abha-address) | | Read the profile | [Profile, card and QR code](#profile-abha-card-and-quick-response-qr-code) | [The PHR profile](#log-in-with-an-abha-address) | | Build it when | You register people at a desk and their records must be trusted | The person holds your application themselves | The two tracks meet. A Self-Declared profile becomes KYC Verified the moment the person links an ABHA number to it, and from then on it is the first column. Nothing is thrown away in between. The rest of this page is those two tracks, and then the one route belonging to neither: a patient arriving at your counter with an ABHA they already hold. "ABHA service" is the ABHA API at the base URL on the [M1 overview](/docs/hiecm/v3/api/m1). Your system never calls Aadhaar. The ABHA service does that for you. The diagrams follow the published step order for each flow. ### Which person is in front of you ```mermaid flowchart TD A{"Does the person<br/>already hold an ABHA?"} A -- "No" --> B{"What can they<br/>authenticate with?"} B -- "Aadhaar linked mobile" --> J1["Aadhaar OTP"] B -- "Face, through the ABHA app" --> J2["Face authentication"] B -- "Name, date of birth and gender,<br/>government integrators only" --> J3["Demographic authentication"] J1 --> M{"Wants health messages on a<br/>different mobile number?"} J2 --> M J3 --> DEF["Default ABHA address issued,<br/>the person may still pick one"] DEF --> J7 M -- "Yes" --> J4["Attach a communication<br/>mobile number"] M -- "No" --> ADDR["Pick an ABHA address,<br/>ABHA number issued"] J4 --> ADDR A -- "Yes" --> C{"What do they remember?"} C -- "Mobile number" --> J5["Login by mobile,<br/>then pick the account"] C -- "Aadhaar number, ABHA number<br/>or ABHA address" --> L["Request a challenge, verify it"] C -- "Nothing they are sure of" --> J6["Find the ABHA,<br/>then prove it"] A -- "Scanned your counter code" --> J8["Scan and share<br/>at your counter"] ADDR --> J7["Profile, card<br/>and QR code"] J5 --> J7 L --> J7 J6 --> J7 ``` ## ABHA with Aadhaar This track produces the fourteen digit [ABHA number](/docs/hiecm/v3/getting-started/glossary#abha-number). Aadhaar proves who the person is, the ABHA service issues the number, and the person claims an [ABHA address](/docs/hiecm/v3/getting-started/glossary#abha-address) to go with it. Four routes reach it, and they differ only in how Aadhaar is satisfied. ### Which creation route you must build | Creation route | Private integrator | Government integrator | | ---------------------------------- | ------------------ | ------------------------------- | | Aadhaar OTP | Mandatory | Mandatory | | Aadhaar face authentication | Optional | Optional | | Aadhaar fingerprint or iris | Optional | Optional | | Aadhaar demographic authentication | Not required | Mandatory | | Child ABHA | Not available | Only on NHA leadership approval | This table is NHA's, from the proposed simplified M1 flow they supplied with their review of this page on 11 September 2026. Enrolment from an identity document is not in it: NHA does not recommend that route to integrators, and it is described [further down](#create-an-abha-from-a-document-not-recommended) rather than among the routes above, because the call is in the specification and people find it there. ### ABHA creation by an Aadhaar OTP ```mermaid sequenceDiagram autonumber actor P as Person participant S as Your system participant A as ABHA service P->>S: Gives Aadhaar number and consent S->>A: Generate Aadhaar OTP A-->>S: Transaction id A->>P: OTP by SMS to Aadhaar linked mobile P->>S: Enters OTP S->>A: Verify Aadhaar OTP A-->>S: Enrolment result and profile details Note over S,A: Communication mobile number, see below S->>A: Ask for ABHA address suggestions A-->>S: List of suggested addresses P->>S: Picks or types an ABHA address S->>A: Link ABHA address A-->>S: Address linked S->>A: Create ABHA with profile details A-->>S: ABHA number issued ``` The person gives their Aadhaar number. The ABHA service sends a one time password ([OTP](/docs/hiecm/v3/getting-started/glossary#otp)) to the mobile registered against that Aadhaar. Once it checks out, the person picks a communication mobile number and an ABHA address, and the ABHA number is issued. Email verification sits between the mobile step and the address step. It is optional, so it is not drawn. ### ABHA creation by face authentication ```mermaid sequenceDiagram autonumber actor P as Person with the ABHA app participant S as Your system participant R as Aadhaar RD service participant A as ABHA service S->>A: Start enrolment authentication A-->>S: Transaction id S->>P: Show a QR code built from the transaction id P->>R: Scans it, then authenticates by face R-->>P: Captured PID block P->>S: Authentication confirmed S->>A: Send the captured PID block S->>A: Enrol by Aadhaar A-->>S: ABHA number and profile S->>A: Ask for ABHA address suggestions A-->>S: List of suggested addresses S->>A: Link the chosen ABHA address ``` Some people cannot use the OTP route, usually because the mobile registered against their Aadhaar is no longer theirs. Face authentication is the optional alternative. The person authenticates their face through the Aadhaar registered device (RD) service on their own phone, which is how the transaction moves from your screen to theirs. NHA files both calls in this route under the use case "ABHA creation, Aadhaar biometric", and their summaries read "face or biometric". Fingerprint and iris are a real route: NHA's simplified flow names them as a creation route of their own, optional for every integrator, and the enrolment call takes `bio` and `iris` in `authMethods` beside `face`. What nothing here records is a request that uses them. The only request recorded against either call sends the scope `face-auth`, and nothing has been run against the sandbox either way. Build the face route from the diagram above, treat fingerprint and iris as named by NHA and unproven here, and confirm the capture step with NHA before you design around it. The middle of this route happens on someone else's device, so your system is waiting on a person rather than on a network call. Show that state clearly instead of a spinner. The PID block is encrypted by the capture device and it expires. Send it as soon as you receive it rather than storing it. ### ABHA creation by demographic authentication ```mermaid sequenceDiagram autonumber actor P as Person participant S as Your system participant A as ABHA service P->>S: Gives Aadhaar number, name, date of birth, gender and consent S->>S: Encrypts the Aadhaar number S->>A: Enrol by Aadhaar, authMethods demo_auth A-->>S: ABHA number, profile and a default ABHA address S->>A: Fetch user profile ``` Government integrators build this route. Private ones do not. There is no OTP and no capture device: you send the Aadhaar number together with the name, date of birth and gender recorded against it, and Aadhaar either matches them or does not. The call is the same `enrol/byAadhaar` the OTP route ends on, with `authMethods` set to `demo_auth` and a `demo_auth` block carrying the encrypted Aadhaar number, the full name as per Aadhaar, the date of birth and the gender. Two things differ from the OTP route and both bite. The user token comes back as `token` at the top level rather than under `tokens`, so a client that reuses its OTP parsing reads nothing. And the account is issued with a default ABHA address already generated, which is why claiming an address is mandatory on the other routes and optional on this one. The default address is the fourteen digit number followed by `@sbx` or `@abdm`, which nobody can remember, so offer the person a readable address anyway. The specification calls the programmes that use this route integrated programmes. What a demographic mismatch returns, field by field, is not published; `INVALID_DEMOGRAPHIC_DETAILS` is the error the specification names. ### Create a child ABHA A parent or guardian can hold ABHA accounts for their children under their own account. NHA releases this route to specific government integrators on its leadership's approval, so a private integration does not get it. Three calls carry it, and a fourth is named by NHA and is not in the specification this portal holds: - **Create.** The same `enrol/byAadhaar` call, with `authMethods` set to `child` and a `child` block carrying the child's first and last name, day, month and year of birth and gender, and the parent's ABHA number or ABHA address. The parent is authenticated first, and must be 18 or older. - **Update.** `PATCH /v3/profile/account` with the child's ABHA number, name, date of birth and gender. - **List.** `GET /v3/enrollment/profile/children`, which returns the children under the account and their count. - **KYC of a child ABHA** is named in NHA's simplified flow and has no operation in the specification this portal holds. Ask NHA for it rather than designing around a guess. Two refusals are worth handling by name before you meet them: a parent under 18, and an account that has already enrolled as many children as it may. ### Create an ABHA from a document, not recommended ```mermaid sequenceDiagram autonumber actor P as Person participant S as Your system participant A as ABHA service S->>A: Request enrolment OTP A->>P: OTP by SMS P->>S: Enters OTP S->>A: Verify the OTP S->>A: Enrol by document A-->>S: ABHA number, restricted S->>A: Fetch user profile S->>A: Fetch ABHA QR code ``` NHA reviewed this page in September 2026 and asked for this route to come out of the recommended flow. It is not in the simplified M1 flow they supplied, and their words are that it is not recommended for integrators. It is kept here, below the recommended routes rather than among them, because the call is in the specification and people find it there. When neither an Aadhaar OTP nor a face capture is possible, the person can be enrolled from an identity document. NHA's own collection uses a driving licence. The account this produces is restricted until it is upgraded through Aadhaar know your customer (KYC) verification. If you build the route anyway, tell the person that when the account is created, rather than letting them find out when something later fails. ### Attach a communication mobile number ```mermaid sequenceDiagram autonumber actor P as Person participant S as Your system participant A as ABHA service P->>S: Gives communication mobile number S->>A: Request mobile OTP A-->>S: Transaction id A->>P: OTP by SMS to that number P->>S: Enters OTP S->>A: Verify mobile A-->>S: Mobile number verified ``` The Aadhaar linked number is not always the number the person wants health messages on. This flow runs after enrolment on every creation route. A person may give the number already linked to their Aadhaar. Whether that path sends a second OTP is not yet published. ### ABHA login by mobile number ```mermaid sequenceDiagram autonumber actor P as Person participant S as Your system participant A as ABHA service P->>S: Gives mobile number S->>A: Request login OTP A-->>S: Transaction id A->>P: OTP by SMS P->>S: Enters OTP S->>A: Verify mobile OTP A-->>S: Token and list of accounts on this number P->>S: Picks the account to use S->>A: Verify user for that account A-->>S: Access token for the chosen ABHA ``` One mobile number can hold more than one ABHA, so this flow has a third step where the person says which account they mean. Login by Aadhaar number, by ABHA number and by ABHA address follow the same two beats: request a challenge, then verify it. The challenge can be an Aadhaar OTP, a mobile OTP, a fingerprint or IRIS capture, or a face authentication scan. [API reference](/reference/hiecm-m1) lists which routes are mandatory. ### Find an ABHA the person has forgotten ```mermaid sequenceDiagram autonumber actor P as Person participant S as Your system participant A as ABHA service P->>S: Gives the identifier they remember S->>S: Encrypts the identifier S->>A: Search for the account A-->>S: Transaction id and the masked mobile the OTP went to A->>P: OTP by SMS S->>A: Request login OTP P->>S: Enters OTP S->>A: Verify the OTP A-->>S: Account and access token ``` People forget their ABHA. This route finds it from something they do remember, usually a mobile number, then makes them prove the account is theirs before anything is handed over. The proof step is the point, because a search on its own only tells you that an account exists. The search response names the masked mobile the OTP was sent to, for example one ending `0161`. Show that to the person so they can confirm the number is theirs before they sit waiting for a message that will not arrive. Encrypt the identifier inside your own system. Do not send the identifier to a remote encryption helper or a third party site; that hands a patient identifier to a party that has no reason to hold it. See [encryption](/docs/hiecm/v3/concepts/encryption) for how to do it locally. ### Profile, ABHA card and quick response (QR) code ```mermaid sequenceDiagram autonumber participant S as Your system participant A as ABHA service S->>A: Fetch user profile with token A-->>S: Profile details S->>A: Download ABHA card A-->>S: Card image in the response S->>A: Fetch ABHA QR code A-->>S: QR code ``` Once you hold a token for a person, the profile reads are plain calls. Get profile, QR code and card download form one set. The card is returned in the response rather than fetched from a separate link. The content type and encoding of the card and QR code responses are not yet published. See the [APIs](/docs/hiecm/v3/api/m1/apis) page for the fields that are. ## ABHA address with a mobile number A mobile number on its own does not reach an ABHA number. Every creation route above proves the person against Aadhaar, or against an identity document on the route NHA no longer recommends, and the number is issued off the back of that. It does reach an [ABHA address](/docs/hiecm/v3/getting-started/glossary#abha-address). The person verifies a mobile number by [OTP](/docs/hiecm/v3/getting-started/glossary#otp), types their own demographics, and ends with an address, no ABHA number, and a profile marked Self-Declared. Nothing in this track is reserved for one kind of integrator. It takes the same gateway session token as everything else in M1, and nothing in the specification this portal holds says only a [PHR](/docs/hiecm/v3/getting-started/glossary#phr) application may call it. What decides whether you build it is what you are building, not what you are registered as. ### Create the address The calls are the enrolment set in [the P1 reference](/docs/hiecm/v3/api/p1), written up as [creating an ABHA address](/docs/hiecm/v3/milestones/p1#creating-an-abha-address). The person verifies the mobile number by OTP, then types the demographics the ABHA service would otherwise have taken from Aadhaar. First name, year of birth, gender, address, state, district and pin code are mandatory; middle name, last name and the day and month of birth are not. Before creating anything, list the addresses already linked to that mobile number and let the person pick one: a second address for somebody who already has one is the most common thing that goes wrong here. ### Log in with an ABHA address ```mermaid sequenceDiagram autonumber actor P as Person participant S as Your system participant A as ABHA service P->>S: Gives their ABHA address S->>A: Search the address for its authentication methods A-->>S: The methods this address supports S->>A: Request the challenge for the method chosen A->>P: OTP by SMS P->>S: Enters OTP S->>A: Verify A-->>S: Token for this ABHA address S->>A: Fetch the PHR profile ``` Logging in by ABHA address is its own set of calls, under `/v3/phr/web/login/abha`, and it is the way into a profile that has no ABHA number behind it. Ask first and authenticate second: [search the ABHA address](/docs/hiecm/v3/api/m1/endpoints/m1-phr-search-abha-address) returns the authentication methods that address supports, which is what stops you offering an Aadhaar OTP to a profile with no Aadhaar behind it. The [OTP request](/docs/hiecm/v3/api/m1/endpoints/m1-phr-request-otp) carries a `scope` pair naming the method: `abha-address-login` with `mobile-verify` for a mobile OTP, `abha-address-login` with `aadhaar-verify` for an Aadhaar OTP, and `abha-login` with `aadhaar-bio-verify`, `aadhaar-face-verify` or `aadhaar-iris-verify` for the three biometric methods. The ABHA address travels encrypted, the same way every other identifier does. Once it verifies, the [PHR profile](/docs/hiecm/v3/api/m1/endpoints/m1-get-phr-profile) and the PHR card and QR code read against the token it returns. ### What Self-Declared costs, and what ends it A Self-Declared profile carries no [KYC](/docs/hiecm/v3/getting-started/glossary#kyc). Nothing has proved the person is who they say they are, so a facility cannot hang a record it has to trust on one. An [ABHA number](/docs/hiecm/v3/getting-started/glossary#abha-number) appears only when the person links one later, and linking turns the same profile KYC Verified without losing what was already on it. Which is what should decide where you start people. A hospital system registering a walk-in patient wants the KYC verified identity the Aadhaar track produces. An application the person holds themselves can start them on a mobile number and ask for Aadhaar later, which is a much shorter first screen and a much smaller reason to abandon it. ## A patient shares their profile at your counter ```mermaid sequenceDiagram autonumber actor P as Patient participant A as Patient's PHR app participant CM as HIE-CM participant S as Your system P->>A: Scans the counter QR code, agrees to share A->>CM: Share the profile with this HIP and counter CM->>S: POST /patient-share/v3/share on your bridge Note over CM,S: intent PROFILE_SHARE, metaData.hipId, metaData.context, profile.patient S-->>CM: 200, profile received S->>S: Register the patient, assign a queue token S->>CM: POST /patient-share/v3/on-share with status and tokenNumber CM-->>A: Token number to show the patient ``` Your facility prints a QR code at each counter. It holds a URL with two parameters: your HIP id and a counter context such as `OPD1`. The patient scans it in their [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app, agrees to share, and their profile arrives on your bridge. Nobody types a name at the desk, and every record from that visit links to the right ABHA address from the start. Step 3 is a callback on the URL registered for your bridge, not a call you make. Answer it with a 200 at once and do the registration afterwards. Step 7 is your reply: `acknowledgement.status` is `SUCCESS` with `profile.tokenNumber` and the same `context`, or `FAILURE` with an `error` code and message. The patient's app holds its screen open for 30 seconds. Send the acknowledgement inside that window or the patient sees no token. `profile.patient` carries the ABHA number, the ABHA address, name, gender, date of birth, mobile number, address and a KYC photo. Match on the ABHA address. The counter context is yours to define: up to 20 alphanumeric characters, and never the facility id, the HIP id or the HIP name. The two calls: [receive a patient's shared profile](/docs/hiecm/v3/api/m1/endpoints/m1-receive-patient-share) and [send the share acknowledgement](/docs/hiecm/v3/api/m1/endpoints/m1-on-share-acknowledgement). The patient's side is [P2 Linking and records](/docs/hiecm/v3/milestones/p2#scan-and-share-at-a-facility). ## Next - The flows as diagrams: [the page map](#the-page-map). - The calls, base URLs and error shapes: [M1 API reference](/docs/hiecm/v3/api/m1). - The next milestone: [M2 Attach](/docs/hiecm/v3/milestones/m2). --- # M2 Attach: linking and sharing Milestone 2 attaches the health records you hold to a person's [ABHA address](/docs/hiecm/v3/getting-started/glossary#abha-address). After it you can group records into [care contexts](/docs/hiecm/v3/getting-started/glossary#care-context), link them, answer [discovery](/docs/hiecm/v3/getting-started/glossary#discovery) requests from [PHR](/docs/hiecm/v3/getting-started/glossary#phr) apps, and push encrypted records when a consented request arrives. [Try the M2 APIs](/docs/hiecm/v3/api/m2) [Every call in M2, one page each: the headers it needs, the payload it takes, the callback it triggers, and a request builder you can fire at the sandbox.](/docs/hiecm/v3/api/m2) [Error codes](/docs/hiecm/v3/api/m2/errors) [What each code M2 returns actually means, and the first thing to check when you see one.](/docs/hiecm/v3/api/m2/errors) ## In short - Your facility is the [HIP](/docs/hiecm/v3/getting-started/glossary#hip) when it publishes a record, and your software is how it publishes. A valid facility ID and registration in the HIP role come first, either from the NHPR portal by hand or by building [M4 Enrol](/docs/hiecm/v3/milestones/m4). - M2 is keyed to an ABHA address, so [M1 Create](/docs/hiecm/v3/milestones/m1) has to work before M2 can. - Hold a [link token](/docs/hiecm/v3/getting-started/glossary#link-token) per patient. Its validity is six months. - Records go out as [FHIR](/docs/hiecm/v3/getting-started/glossary#fhir) R4 against the ABDM profiles. - Four callbacks name a path and carry no documented payload. Do not assume a body. ## What M2 gives you | Capability | What your system can do | | ------------------------- | ----------------------------------------------------------------------------------------------- | | Care contexts | Group each visit or admission into a named unit that can be linked to an ABHA address | | HIP initiated linking | Link a care context yourself, when the patient gave you their ABHA address at registration | | Notification to mobile | Make a record findable when you hold only a mobile number, a name, an age and a gender | | Discovery | Answer a patient's search for their records at your facility, and let them link what you return | | Data request and transfer | Receive a consented request, package the records, encrypt them, and push them to the requester | Requesting records from other facilities is [M3 Retrieve](/docs/hiecm/v3/milestones/m3). ## Who needs it Hospitals, laboratories, pharmacies and imaging centres, through the software they record care in. A citizen pushing their own records from a PHR app builds [P2 Linking and records](/docs/hiecm/v3/milestones/p2), the patient side of M2. ## Prerequisites 1. A valid facility ID and registration in the HIP role. That authorises your facility to create health records and share them with whoever asks to read them as the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu). It comes from [M4 Enrol](/docs/hiecm/v3/milestones/m4). 2. A working [M1 Create](/docs/hiecm/v3/milestones/m1) integration. Linking is keyed to an ABHA address. 3. A link token per patient, stored when the patient registers. Validate it before use. If you hold no valid one, regenerate it using demographic authentication. 4. FHIR R4 output conforming to the ABDM profiles at [nrces.in](https://nrces.in/ndhm/fhir/r4/index.html). Callback payloads Four callbacks name a path and carry no documented payload: discovery, link init, link confirm, and consent notify. Do not assume a body for them. The data notification callback is documented in full. ## Record types you can link Each type can be a simple bundle wrapping a PDF or image attachment, or a structured bundle with coded clinical data. | Record type | What it holds | | ------------------------ | ------------------------------------------------------------------------- | | Diagnostic Report Record | Radiology and laboratory reports | | Discharge Summary Record | The discharge summary for the ABDM health data set | | Health Document Record | Unstructured historical records, usually uploaded through a health locker | | Immunization Record | Immunisations, vaccine certificates and next dose recommendations | | OP Consult Record | Outpatient notes: examinations, procedures, medications and advice | | Prescription Record | Medication advice, following Pharmacy Council of India guidelines | | Wellness Record | Vitals, physical examination and general health data captured in PHR apps | | Invoice Record | Pharmacy invoices, consultation invoices and other billing records | An [HMIS](/docs/hiecm/v3/getting-started/glossary#hmis) must implement every [HI type](/docs/hiecm/v3/getting-started/glossary#hi-type). ## Build it with an agent Hand M2 to the agent you already use, as one file it loads once. Install it, or open it there in one click. M2 agent skill Every M2 call and callback, its error codes and its certification cases in one file: 31 operations, 120 codes, 46 cases. [SKILL.md](/skills/abdm-m2/SKILL.md "The router. Use the command below to take the references with it.") - ScaffoldThe loop that builds the module flow by flow against the sandbox, ending on an observed result rather than on a call returning 200. - Integrate31 operations, with their hosts, headers and the rules that hold across them. - Debug120 recorded error codes, each with its message and what to do about it. - Test46 test cases, each with the call it makes and what to see when it passes. `mkdir -p .claude/skills/abdm-m2/references && curl -fsSL https://abdm-docs.dev.eka.care/skills/abdm-m2/SKILL.md -o .claude/skills/abdm-m2/SKILL.md && for f in scaffold integrate debug test; do curl -fsSL https://abdm-docs.dev.eka.care/skills/abdm-m2/references/$f.md -o .claude/skills/abdm-m2/references/$f.md; done` [Open in Claude](claude://code/new?q=Install%20the%20ABDM%20M2%20agent%20skill%20into%20this%20project%2C%20then%20help%20me%20use%20it.%0A%0ARun%20this%3A%0Amkdir%20-p%20.claude%2Fskills%2Fabdm-m2%2Freferences%20%26%26%20curl%20-fsSL%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fskills%2Fabdm-m2%2FSKILL.md%20-o%20.claude%2Fskills%2Fabdm-m2%2FSKILL.md%20%26%26%20for%20f%20in%20scaffold%20integrate%20debug%20test%3B%20do%20curl%20-fsSL%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fskills%2Fabdm-m2%2Freferences%2F%24f.md%20-o%20.claude%2Fskills%2Fabdm-m2%2Freferences%2F%24f.md%3B%20done%0A%0AIf%20this%20session%20did%20not%20open%20in%20the%20repository%20I%20am%20integrating%20ABDM%20into%2C%20ask%20me%20for%20the%20path%20before%20you%20write%20anything.) Drops the skill into this project. Claude loads it when a task matches. How to use it 1. Run the command above in the repository you are integrating. 2. Ask your agent for the job in your own words. "Link a care context for this patient", "why am I getting ABDM-1000", or "write the M2 tests for this". The skill loads when the task matches it. 3. Check what it writes against these pages. The skill carries the facts, not the sandbox: nothing in it has been run against ABDM. 4. Open in Claude needs that app installed. It fills the composer and waits: nothing runs until you read it and press Enter. ## Certification M2 has no certification step of its own. One exit process covers the whole integration, run once, after every milestone your role needs works end to end. See [Going live](/docs/hiecm/v3/getting-started/going-live) for the four steps and what each one asks of you. Test data is in the [data dictionary](/docs/hiecm/v3/reference/data-dictionary). [Support](/docs/support) lists the channels. The cases you are certified against are in [M2 testing use cases](/docs/hiecm/v3/resources/testing/m2). ## The journey, one diagram per flow Milestone 2 (M2) of [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) has four flows. This page draws each one, so you can see the round trips before you read the detail. "Your system" is the [HMIS](/docs/hiecm/v3/getting-started/glossary#hmis) or [LMIS](/docs/hiecm/v3/getting-started/glossary#lmis) your facility publishes through. "HIE-CM" is the [Health Information Exchange and Consent Manager](/docs/hiecm/v3/getting-started/glossary#hie-cm) gateway. ## Journey 1: HIP initiated linking ```mermaid sequenceDiagram autonumber actor P as Patient participant S as Your system participant CM as HIE-CM participant A as Patient's PHR apps P->>S: Registers, gives ABHA address S->>CM: Request link token CM-->>S: Link token, valid six months Note over S: Store the token against the patient S->>S: New health record created S->>S: Assign the record to a care context S->>CM: Link the care context, carrying the link token CM-->>S: 202 Accepted, nothing decided yet CM->>S: Callback on your bridge with the outcome Note over S: Match response.requestId to the REQUEST-ID you sent CM->>A: Notify every PHR app subscribed to that ABHA address ``` The patient gave you their [ABHA address](/docs/hiecm/v3/getting-started/glossary#abha-address) at registration. Link the [care context](/docs/hiecm/v3/getting-started/glossary#care-context) as soon as the record is ready: linking is what makes it reachable from [PHR](/docs/hiecm/v3/getting-started/glossary#phr) apps. Step 8 is the acknowledgement. Step 9 is the answer. The link is confirmed only when the callback arrives at `/v3/link/on_carecontext` on your bridge carrying `status`, so do not mark a record as linked on the strength of the 202. See [the outcome of a care context linking call](/docs/hiecm/v3/api/m2/endpoints/m2-on-carecontext-result). Which steps are callbacks? A step drawn from the HIE-CM to your system is a POST to the callback URL registered for your bridge. It arrives on its own. Do not poll for it. - **No valid [link token](/docs/hiecm/v3/getting-started/glossary#link-token).** Validate the stored token before use, with a tool such as JWT.io. If it is expired or missing, regenerate it through demographic authentication. - **An existing care context gains new records.** The step 10 notification fires for that too, not only for a new context. ## Journey 2: Notification to mobile ```mermaid sequenceDiagram autonumber actor P as Patient participant S as Your system participant CM as HIE-CM participant A as PHR app P->>S: Registers with mobile, name, age, gender S->>S: New health record created S->>CM: Notify that a record is ready to share CM->>P: SMS with a secure deep link P->>A: Opens the link, installs a PHR app if needed P->>A: Creates an ABHA address if they do not have one Note over A,S: The patient now runs journey 3 to find and link the record ``` You hold a mobile number, a name, an age and a gender, but no ABHA address. You cannot link, so you ask the HIE-CM to tell the patient a record is waiting. ## Journey 3: Discovery and link ```mermaid sequenceDiagram autonumber actor P as Patient participant A as Patient's PHR app participant CM as HIE-CM participant S as Your system P->>A: Selects the facility they visited A->>CM: Discovery request CM->>S: Discovery request with verified and unverified identifiers S->>S: Match against your patient records S-->>CM: List of care contexts, metadata only CM-->>A: Care contexts to review P->>A: Selects the care contexts to link A->>CM: Link the selected care contexts CM->>S: Link request for those care contexts S-->>CM: Link confirmed CM-->>A: Records now linked to the ABHA address ``` The patient starts [discovery](/docs/hiecm/v3/getting-started/glossary#discovery) from a PHR app and picks the facility they visited. Your system matches them on the identifiers the gateway passes you and answers with care contexts. Step 3 hands you two groups of identifiers. - **Verified.** ABHA address, mobile number, name, gender, year of birth. Weight these higher. - **Unverified, user declared.** Facility issued identifiers such as a medical registration number or patient ID. Step 5 has a hard rule: care context metadata only. No diagnosis, no test result, no report content. Steps 8 to 11 are drawn in words. The error codes name them init, confirm, on-init and on-confirm, so the shape is a gateway request and a callback from you. Their fields are not yet published. ## Journey 4: Health record request and data transfer ```mermaid sequenceDiagram autonumber participant U as HIU participant CM as HIE-CM participant S as Your system U->>CM: Health information request Note over U,CM: Consent ID, data push URL, date range, public key and nonce CM->>CM: Generate a transaction ID CM-->>U: Transaction ID CM->>S: Forward the request with the transaction ID S->>S: Check the consent is valid and active S->>S: Check the date range sits inside the consent S->>S: Check the encryption parameters S->>S: Build the FHIR bundle, encrypt it, sign it S->>U: Push encrypted data to the data push URL S->>CM: Call health-information/notify, transfer complete U->>CM: Notify the outcome, success or failure ``` Another facility, an insurer or a citizen's PHR app asks for records under a [consent artefact](/docs/hiecm/v3/getting-started/glossary#consent-artefact) the patient granted. Whoever asks is the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu). Four constraints apply to step 9, the push. - The HIU supplies the data push URL. It can differ from its registered gateway URL, which keeps the requester harder to identify. - The push has a 20 minute window from the start of the request. Past that, expect failure or timeout. - Large datasets such as CT or MRI images may be split across multiple parts. - Stream very large files rather than sending one whole payload. Encryption uses [ECDH](/docs/hiecm/v3/getting-started/glossary#ecdh), Elliptic Curve Diffie Hellman, over Curve25519. Mechanics: [use cases](/reference/hiecm-m2). Call order: [API reference](/reference/hiecm-m2). ## Next - The four flows as diagrams: [the journey below](#the-journey-one-diagram-per-flow). - The calls, callbacks and error codes: [M2 API reference](/docs/hiecm/v3/api/m2). - The next milestone: [M3 Retrieve](/docs/hiecm/v3/milestones/m3). --- # M3 Retrieve: consent and fetching In Milestone 3 your organisation asks a patient for permission to read health records it did not create, then fetches them. Your organisation is the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu), and your software is how it asks. The [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) holds the consent, asks the patient on your behalf, and on a grant returns a [consent artefact](/docs/hiecm/v3/getting-started/glossary#consent-artefact) id. No artefact, no records. [Try the M3 APIs](/docs/hiecm/v3/api/m3) [Every call in M3, one page each: the headers it needs, the payload it takes, the callback it triggers, and a request builder you can fire at the sandbox.](/docs/hiecm/v3/api/m3) [Error codes](/docs/hiecm/v3/api/m3/errors) [What each code M3 returns actually means, and the first thing to check when you see one.](/docs/hiecm/v3/api/m3/errors) ## In short - The HIE-CM asks the patient. You never ask the patient directly. - The patient must already be known to you by [ABHA address](/docs/hiecm/v3/getting-started/glossary#abha-address). - One request can produce more than one artefact. Store the request id and every artefact id. - Records arrive encrypted on your callback URL. Decrypt them, then acknowledge to the gateway. - `consentId` and `consentRequestId` are declared as UUIDs but the published examples are not. Do not validate them as UUIDs. ## What M3 gives you | Capability | What your system can do | | -------------------------- | ---------------------------------------------------------------------------------- | | Consent request | Ask a patient, by ABHA address, for named record types over a named date range | | Status tracking | Check whether a request is pending, granted or denied | | Consent artefacts | Receive the artefact ids created on a grant, and fetch each artefact | | Health information request | Ask for the records an artefact covers | | Data receipt | Receive encrypted records on your callback URL, decrypt them, and acknowledge them | M3 creates no identities, which is [M1 Create](/docs/hiecm/v3/milestones/m1), and publishes no records, which is [M2 Attach](/docs/hiecm/v3/milestones/m2). A hospital that shares its own records and reads records held elsewhere builds both. ## Who needs it Whoever asks to read records they did not create. A hospital pulling a patient's history, an insurer settling a claim, a referral service, a clinical decision tool, and a citizen whose [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app fetches their records. ## Prerequisites 1. A working [M1 Create](/docs/hiecm/v3/milestones/m1) integration, so you hold a session token and an ABHA address for the patient. 2. Registration in the HIU role, from [M4 Enrol](/docs/hiecm/v3/milestones/m4). A facility registers an HIU bridge against its facility ID. The [HFR](/docs/hiecm/v3/getting-started/glossary#hfr) does not list insurers, so confirm which entry your organisation registers against. M4 blocks production, not your sandbox build. 3. A callback URL the gateway can reach, and a key pair for decryption. The patient must be known to you by ABHA address first. One concrete route: the patient scans the health facility QR code at registration, and a doctor raises a consent request against that address. Identifier format Do not validate `consentId` or `consentRequestId` as UUIDs. Treat both as opaque strings. ## What you build, in order 1. **Raise a consent request.** You get a request id on a callback, not inline. 2. **Track its status.** Pending, granted or denied. 3. **Collect the artefacts.** A grant produces one or more artefact ids. Fetch each artefact. 4. **Raise a health information request** against an artefact. 5. **Receive, decrypt and acknowledge** the records on your callback URL. Build for revocation from the start. A consent that worked yesterday can be withdrawn today, and that is the system working correctly. ## Build it with an agent Hand M3 to the agent you already use, as one file it loads once. Install it, or open it there in one click. M3 agent skill Every M3 call and callback with its error codes in one file: 25 operations, 95 codes. [SKILL.md](/skills/abdm-m3/SKILL.md "The router. Use the command below to take the references with it.") - ScaffoldThe loop that builds the module flow by flow against the sandbox, ending on an observed result rather than on a call returning 200. - Integrate25 operations, with their hosts, headers and the rules that hold across them. - Debug95 recorded error codes, each with its message and what to do about it. - Test32 test cases, each with the call it makes and what to see when it passes. `mkdir -p .claude/skills/abdm-m3/references && curl -fsSL https://abdm-docs.dev.eka.care/skills/abdm-m3/SKILL.md -o .claude/skills/abdm-m3/SKILL.md && for f in scaffold integrate debug test; do curl -fsSL https://abdm-docs.dev.eka.care/skills/abdm-m3/references/$f.md -o .claude/skills/abdm-m3/references/$f.md; done` [Open in Claude](claude://code/new?q=Install%20the%20ABDM%20M3%20agent%20skill%20into%20this%20project%2C%20then%20help%20me%20use%20it.%0A%0ARun%20this%3A%0Amkdir%20-p%20.claude%2Fskills%2Fabdm-m3%2Freferences%20%26%26%20curl%20-fsSL%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fskills%2Fabdm-m3%2FSKILL.md%20-o%20.claude%2Fskills%2Fabdm-m3%2FSKILL.md%20%26%26%20for%20f%20in%20scaffold%20integrate%20debug%20test%3B%20do%20curl%20-fsSL%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fskills%2Fabdm-m3%2Freferences%2F%24f.md%20-o%20.claude%2Fskills%2Fabdm-m3%2Freferences%2F%24f.md%3B%20done%0A%0AIf%20this%20session%20did%20not%20open%20in%20the%20repository%20I%20am%20integrating%20ABDM%20into%2C%20ask%20me%20for%20the%20path%20before%20you%20write%20anything.) Drops the skill into this project. Claude loads it when a task matches. How to use it 1. Run the command above in the repository you are integrating. 2. Ask your agent for the job in your own words. "Raise a consent request and fetch the records it covers", "why am I getting ABDM-1000", or "write the M3 tests for this". The skill loads when the task matches it. 3. Check what it writes against these pages. The skill carries the facts, not the sandbox: nothing in it has been run against ABDM. 4. Open in Claude needs that app installed. It fills the composer and waits: nothing runs until you read it and press Enter. ## Certification M3 has no certification step of its own. One exit process covers the whole integration, run once, after every milestone your role needs works end to end. See [Going live](/docs/hiecm/v3/getting-started/going-live) for the four steps and what each one asks of you. Test data is in the [data dictionary](/docs/hiecm/v3/reference/data-dictionary). [Support](/docs/support) lists the channels. The cases you are certified against are in [M3 testing use cases](/docs/hiecm/v3/resources/testing/m3). ## The journey, one diagram per flow Milestone 3 (M3) of [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) is one story in three parts: a doctor asks for a patient's past records, the patient says yes or no, and if yes the records travel. Each part is drawn below, so you can see the round trips before you read the [API reference](/reference/hiecm-m3). | In the diagram | What it is | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Patient | The person whose records these are, acting in their [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app | | Your system | The software your organisation asks through | | HIE-CM gateway | The [gateway](/docs/hiecm/v3/getting-started/glossary#gateway), which routes every call and callback | | HIE-CM | The [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm), which holds consent and asks the patient | | HIP | The facility holding the records. It is the [HIP](/docs/hiecm/v3/getting-started/glossary#hip) when it publishes them, in journeys 2 and 3 | ## Journey 1: raising a consent request ```mermaid sequenceDiagram autonumber actor D as Doctor participant S as Your system participant G as HIE-CM gateway participant C as HIE-CM actor P as Patient D->>S: Picks the patient and a date range S->>G: Consent request init with ABHA address G->>C: Forwards the request C-->>G: Acknowledges, creates a request id G-->>S: on-init callback with the consent request id C->>P: Notifies the patient of the request Note over S,C: Your system now waits. You may poll request status. ``` A doctor wants the patient's earlier records for a date range. Your system sends the request with the patient's [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) address. Nothing comes back inline: you get a request id on a callback, then wait for the patient. The request id is the handle for everything that follows. Store it against the doctor and the patient. ## Journey 2: the patient grants or denies ```mermaid sequenceDiagram autonumber actor P as Patient participant C as HIE-CM participant G as HIE-CM gateway participant S as Your system participant H as HIP P->>C: Views the request details alt Patient grants P->>C: Grants, with an expiry date and time C->>C: Creates one or more consent artefacts C->>G: Notify granted, with artefact ids and request id G->>S: Consent request notify to your system S-->>G: on-notify acknowledgement C->>G: Notify the HIP with care context references G->>H: Consent request HIP notify else Patient denies P->>C: Denies the request C->>G: Notify denied G->>S: Consent request notify, status denied end ``` The patient sees who is asking, what they want, why, and for how long. The HIE-CM tells both sides what they chose. - A grant carries an expiry. The patient sets when the permission runs out. - A grant can produce more than one consent artefact. Store every id the grant returns. - The patient can revoke a granted consent at any time. Your access ends when they do. ## Journey 3: fetching the records ```mermaid sequenceDiagram autonumber participant S as Your system participant G as HIE-CM gateway participant C as HIE-CM participant H as HIP S->>G: Consent fetch with the consent artefact id G->>C: Forwards C-->>G: Artefact detail G-->>S: on-fetch callback with the artefact S->>S: Generates an ECDH key pair for this exchange S->>G: Health information request with consent id, date range, data push URL and public key G-->>S: on-request callback with transaction id and status G->>H: Health information request to the HIP H->>S: Pushes encrypted records to your data push callback URL S->>S: Decrypts and renders the records S->>G: Health information notify, receipt of the data ``` With an artefact id you fetch the artefact, then ask for the data it covers. The data lands on the data push URL you supplied in that request. The records arrive encrypted, at the data push URL you supplied. Whether that URL must differ from your other registered callback URLs is not yet published. Your side is simple: decrypt the data, then present it in a readable format. The scheme is [ECDH](/docs/hiecm/v3/getting-started/glossary#ecdh) key exchange, specified on the [HIP](/docs/hiecm/v3/getting-started/glossary#hip) side. See [M2](/docs/hiecm/v3/api/m2). ## What the patient sees The patient's screens and expiry screens are not reproduced here. What applies to you is on the [use cases](/reference/hiecm-m3) page under patient rights. ## Next - The request, the decision and the fetch as diagrams: [M3 journey below](#the-journey-one-diagram-per-flow). - The calls, callbacks and error codes: [M3 API reference](/docs/hiecm/v3/api/m3). - The next milestone: [M4 Enrol](/docs/hiecm/v3/milestones/m4). --- # M4 Enrol: facilities and professionals Milestone 4 is the registries milestone, also called the NHPR. A healthcare professional registers on the [HPR](/docs/hiecm/v3/getting-started/glossary#hpr) and is issued an [HPID](/docs/hiecm/v3/getting-started/glossary#hpid). A health facility onboards to the [HFR](/docs/hiecm/v3/getting-started/glossary#hfr) and is issued a facility ID. Neither registry moves a health record. They establish who the professional is and what the facility is, so every record flow has a verified provider behind it. [Try the M4 APIs](/docs/hiecm/v3/api/m4) [Every call in M4, one page each: the headers it needs, the payload it takes, the callback it triggers, and a request builder you can fire at the sandbox.](/docs/hiecm/v3/api/m4) [Error codes](/docs/hiecm/v3/api/m4/errors) [What each code M4 returns actually means, and the first thing to check when you see one.](/docs/hiecm/v3/api/m4/errors) ## In short - M2 and M3 need a facility ID in production. M4 is the API route to one. The NHPR portal is the other, and a product that registers its facilities there by hand never builds M4. - The HPR comes first. Facility onboarding needs an HPR token, which needs a person with an HPID. - A facility ID has the form `IN` plus 10 characters. An HPID is 14 digits. - Expect to correct a host or two. Several published samples show the production host while describing sandbox behaviour. Not a step by step guide These pages cover the shape of M4 and the endpoints that are named. They are not yet a step by step guide to building it. ## What M4 covers | Area | What it produces | Who it is for | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | HPID creation | A 14 digit HPID, issued after Aadhaar authentication | A doctor, nurse, pharmacist or facility manager | | Register professional | A full HPR profile: qualifications, council registration, current work | The same professional, after the HPID exists | | Facility onboarding | A facility ID on the HFR, in the form `IN` plus 10 characters | A hospital, clinic, lab, imaging centre, pharmacy or blood bank | | Bridge linkage | A link between a facility ID and one or more bridges, each marked [HIP](/docs/hiecm/v3/getting-started/glossary#hip) or [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) | A facility whose software is going live | | Search and master data | Facility search, nearby search, and the code lists every other call needs | Anyone building either of the above | ## Who needs it - **Facilities going live.** Without a facility in the HFR and a bridge linked to it, you cannot share as a HIP or fetch as an HIU. If you have built [M2 Attach](/docs/hiecm/v3/milestones/m2) or [M3 Retrieve](/docs/hiecm/v3/milestones/m3), M4 is the step in front of production. - **Professionals registering.** An HPID is a verified identity in ABDM. Three categories are open today: doctor, nurse and pharmacist. Others come later. - **Software acting for others.** An [HMIS](/docs/hiecm/v3/getting-started/glossary#hmis) or practice management product can drive these calls for its own customers. ## How the two halves connect The HPR comes first, twice over. Creating an HPID returns an `hprToken`, which the register professional call carries in its payload. Onboarding a facility needs an HPR token in the header of the create calls, generated from an HPR ID and password. So facility onboarding usually starts with a person getting an HPID. ## Build it with an agent Hand M4 to the agent you already use, as one file it loads once. Install it, or open it there in one click. M4 agent skill Every M4 call, its error codes and its certification cases in one file: 13 operations, 150 codes, 183 cases. [SKILL.md](/skills/abdm-m4/SKILL.md "The router. Use the command below to take the references with it.") - ScaffoldThe loop that builds the module flow by flow against the sandbox, ending on an observed result rather than on a call returning 200. - Integrate13 operations, with their hosts, headers and the rules that hold across them. - Debug150 recorded error codes, each with its message and what to do about it. - Test184 test cases, each with the call it makes and what to see when it passes. `mkdir -p .claude/skills/abdm-m4/references && curl -fsSL https://abdm-docs.dev.eka.care/skills/abdm-m4/SKILL.md -o .claude/skills/abdm-m4/SKILL.md && for f in scaffold integrate debug test; do curl -fsSL https://abdm-docs.dev.eka.care/skills/abdm-m4/references/$f.md -o .claude/skills/abdm-m4/references/$f.md; done` [Open in Claude](claude://code/new?q=Install%20the%20ABDM%20M4%20agent%20skill%20into%20this%20project%2C%20then%20help%20me%20use%20it.%0A%0ARun%20this%3A%0Amkdir%20-p%20.claude%2Fskills%2Fabdm-m4%2Freferences%20%26%26%20curl%20-fsSL%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fskills%2Fabdm-m4%2FSKILL.md%20-o%20.claude%2Fskills%2Fabdm-m4%2FSKILL.md%20%26%26%20for%20f%20in%20scaffold%20integrate%20debug%20test%3B%20do%20curl%20-fsSL%20https%3A%2F%2Fabdm-docs.dev.eka.care%2Fskills%2Fabdm-m4%2Freferences%2F%24f.md%20-o%20.claude%2Fskills%2Fabdm-m4%2Freferences%2F%24f.md%3B%20done%0A%0AIf%20this%20session%20did%20not%20open%20in%20the%20repository%20I%20am%20integrating%20ABDM%20into%2C%20ask%20me%20for%20the%20path%20before%20you%20write%20anything.) Drops the skill into this project. Claude loads it when a task matches. How to use it 1. Run the command above in the repository you are integrating. 2. Ask your agent for the job in your own words. "Onboard this facility to the HFR and link its HIP bridge", "why am I getting HIS-400", or "write the M4 tests for this". The skill loads when the task matches it. 3. Check what it writes against these pages. The skill carries the facts, not the sandbox: nothing in it has been run against ABDM. 4. Open in Claude needs that app installed. It fills the composer and waits: nothing runs until you read it and press Enter. ## Certification M4 has no certification step of its own. One exit process covers the whole integration, run once, after every milestone your role needs works end to end. See [Going live](/docs/hiecm/v3/getting-started/going-live) for the four steps and what each one asks of you. The cases you are certified against are in [M4 testing use cases](/docs/hiecm/v3/resources/testing/m4). ## The journey, one diagram per flow Milestone 4 of [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) has four journeys: - A professional gets an [HPID](/docs/hiecm/v3/getting-started/glossary#hpid). - That professional's [HPR](/docs/hiecm/v3/getting-started/glossary#hpr) profile is registered against the HPID. The identity and the profile are two jobs, not one. - A facility manager onboards a facility to the [HFR](/docs/hiecm/v3/getting-started/glossary#hfr). - A facility links its bridges, so it can publish records as the [HIP](/docs/hiecm/v3/getting-started/glossary#hip) and fetch them as the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) through its software. This page shows the order of calls in each. Field lists are on the [operations and fields](/docs/hiecm/v3/api/m4/undocumented) page. A map, not a runbook These diagrams follow the published order of steps. ## Journey 1: create an HPID for a professional ```mermaid sequenceDiagram autonumber actor P as Professional participant S as Your system participant G as HIE-CM gateway participant H as HPR service S->>G: POST /gateway/v3/sessions with clientId and clientSecret G-->>S: accessToken S->>H: Generate Aadhaar link H-->>S: txnId and a temporary URL, valid 5 minutes S->>P: Redirect to the URL P->>H: Enter Aadhaar details and verify by OTP loop Optional polling S->>H: Check Aadhaar authentication status with txnId H-->>S: true or false, as a bare boolean end S->>H: Verify OTP and fetch user details with txnId H-->>S: Demographic and address details, mobile number masked S->>H: Check whether an HPID already exists for this Aadhaar H-->>S: The existing HPID, or none ``` The professional authenticates against Aadhaar on a hosted page. Your system never handles the Aadhaar number or [OTP](/docs/hiecm/v3/getting-started/glossary#otp): it handles the transaction ID and redirects to a URL the HPR service returns, valid for five minutes. After that, call generate Aadhaar link again. ### Then the mobile number ```mermaid flowchart TD Z{"HPID already exists<br/>for this Aadhaar?"} Z -- "Yes" --> Y["Log the professional in.<br/>Journey 1 is done."] Z -- "No" --> A A["Call the mobile match API<br/>with the encrypted mobile number"] --> B{"demographicAuthViaMobile"} B -- true --> C["Mobile number is already verified.<br/>Skip OTP entirely."] B -- false --> D["Generate mobile OTP<br/>with mobile and txnId"] D --> E["Verify mobile OTP<br/>with otp and txnId"] E --> C C --> F["Get username suggestions"] F --> G["Create HPID"] ``` Step 13 decides what happens next. An existing HPID means the professional is already registered: log them in and skip the rest of this journey. A returning professional can also skip Aadhaar entirely and log in by mobile OTP or by password. Both routes are in [M4 operations and fields](/docs/hiecm/v3/api/m4/undocumented#login-by-mobile-otp). No HPID means you confirm the mobile number before creating one, by a fast path or a slow one. Send it encrypted: fetch the public certificate from `/v4/int/api/v1/auth/cert`, encrypt with `RSA/ECB/PKCS1Padding`, send the encrypted value. Create HPID returns an `hprToken`. Keep it: the register professional call needs it. ## Journey 2: register the professional on the HPR ```mermaid sequenceDiagram autonumber participant S as Your system participant H as HPR service Note over S: Holds accessToken and hprToken S->>H: Fetch master data: councils, courses, colleges, universities, languages H-->>S: Code lists S->>H: Register professional, with hprToken in the payload H-->>S: Registration result S->>H: Retrieve professional document list H-->>S: Document IDs to upload against S->>H: Upload documents, one call per document H-->>S: Upload result ``` The HPID is an identity, not a profile. Registering the professional adds qualifications, council registration and current work. It needs the `hprToken` journey 1 returned. Two documents are mandatory, the degree certificate and the registration certificate. A proof of work certificate is mandatory too when the professional works for government, or for both government and private. Register professional takes codes, not names. Fetch council, course, college, university, state, district and language from the master APIs first. ## Journey 3: a facility onboards to the HFR ```mermaid sequenceDiagram autonumber actor M as Facility manager participant S as Your system participant H as HFR service M->>S: Logs in with their HPR credentials S->>H: Get HPR token H-->>S: HPR token for the header S->>H: Deduplicate search, by name, district and sub district H-->>S: Existing facilities that match, if any Note over S,H: Stop here if the facility already exists S->>H: Basic facility information H-->>S: trackingId S->>H: Additional information, with trackingId S->>H: Detailed information, with trackingId S->>H: Submit facility, with trackingId H-->>S: Facility submitted for verification ``` Onboarding is one search, three writes and a submit, each write adding a layer of detail. Stop before submit and the facility stays in draft, invisible to ABDM. The first write, basic facility information, returns a tracking ID. That is the facility's identity for the rest of the sequence, and what you pass as the facility ID on every later update. ### What each write call carries | Call | What it captures | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Basic facility information | Name, ownership, system of medicine, facility type and subtype, address with LGD codes, contact details, board and building photographs, opening hours | | Additional information | Whether it has a pharmacy, blood bank, dialysis centre, cath lab, diagnostic lab or imaging centre, plus scheme identifiers such as ABPMJAY, Rohini, ECHS and CGHS | | Detailed information | Specialities per system of medicine, bed and ventilator counts, and the pharmacy, blood bank, diagnostic and imaging sections that apply to this facility type | | Submit facility | The tracking ID and an optional source of information. Moves the facility out of draft | Which fields are mandatory in detailed information depends on the facility type, the type of service and the system of medicine. A diagnostic laboratory, imaging centre, blood bank or pharmacy sends no medical infrastructure counts at all. ### A facility can also verify by OTP ```mermaid sequenceDiagram autonumber participant S as Your system participant H as HFR service S->>H: Send OTP to contact, with facilityId H-->>S: transactionId, and an OTP to the facility's mobile S->>H: Validate OTP, with facilityId, sourceId, otp, source and transactionId H-->>S: Validation result ``` A second, shorter path serves government programmes: send an OTP to the contact number registered against a facility ID, then validate it. ## Journey 4: linking bridges to a facility ```mermaid flowchart LR A["Facility ID<br/>IN plus 10 characters"] --> B["Bridge linkage call"] C["Bridge ID"] --> B D["HIP name<br/>15 characters or fewer"] --> B B --> E["Type: HIP or HIU"] B --> F["Active: true or false"] ``` A facility ID alone does not make records flow. The facility has to be linked to a bridge, each link marked HIP or HIU. One facility can have several, and one bridge serves as many facilities as you link to it. What is set once for your integration and what is set per facility is in [one bridge, many facilities](/docs/hiecm/v3/concepts/how-it-fits#one-bridge-many-facilities). The HIP name is what a patient sees in their [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) or [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app when they search for this hospital. Three rules apply: 15 characters or fewer, no special characters, and unique for every bridge on a facility. The worked example builds the name from the hospital name plus the bridge name. A facility with a facility ID and a linked HIP bridge can do the [M2](/docs/hiecm/v3/api/m2) work, linking care contexts and sharing records. With a linked HIU bridge it can do the [M3](/docs/hiecm/v3/api/m3) work, requesting consent and fetching records. M4 is the registration step in front of either flow outside sandbox. Next: [M4 operations and fields](/docs/hiecm/v3/api/m4/undocumented). ## Next - The registration journeys as diagrams: [the journey below](#the-journey-one-diagram-per-flow). - The base URLs and the operation list: [M4 API reference](/docs/hiecm/v3/api/m4). - Every call with its parameters and codes: [M4 operations and fields](/docs/hiecm/v3/api/m4/undocumented). - The patient side of all four: [P1 Identity and profile](/docs/hiecm/v3/milestones/p1). - Take your integration to production: [Go live](/docs/hiecm/v3/getting-started/going-live). --- # P1 Identity and profile P1 is the patient side of [M1 Create](/docs/hiecm/v3/milestones/m1). M1 is how a hospital system creates an [ABHA](/docs/hiecm/v3/getting-started/glossary#abha). P1 is how the patient's own [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app does it, and how it maintains the account afterwards. [Try the P1 APIs](/docs/hiecm/v3/api/p1) [Every call in P1, one page each: the headers it needs, the payload it takes, the callback it triggers, and a request builder you can fire at the sandbox.](/docs/hiecm/v3/api/p1) [Error codes](/docs/hiecm/v3/api/p1/errors) [What each code P1 returns actually means, and the first thing to check when you see one.](/docs/hiecm/v3/api/p1/errors) ## In short - Every user needs an ABHA address, `username@abdm`. Consent, notifications and record sharing all hang off it. - Build both creation paths: by mobile number, and by an existing 14 digit ABHA number. - All four login routes are mandatory. - A user can hold several ABHA addresses but only one ABHA number. ## What you build Registration and login, the profile the patient reads and edits, family members they manage on one account, and DigiLocker documents they pull in. ## Creating an ABHA address ```mermaid flowchart TD A["User picks a path"] --> B{"Mobile number, or 14 digit ABHA number?"} B -- "Mobile number" --> C["Verify by mobile OTP"] C --> D["User types first name, year of birth, gender, address, state, district, pin code"] B -- "ABHA number" --> E["Verify by Aadhaar OTP or mobile OTP"] E --> F["Profile details come back from the ABHA system"] D --> G["Show the ABHA addresses already linked to this mobile or number"] F --> G G --> H{"An address already exists?"} H -- "Yes" --> I["User picks one"] H -- "No" --> J["User creates a new address"] ``` A person does not need an [ABHA number](/docs/hiecm/v3/getting-started/glossary#abha-number), and does not need Aadhaar, to get an ABHA address here. A mobile number and the OTP sent to it are enough. What that buys is a Self-Declared profile: an address the network can route to, with no [KYC](/docs/hiecm/v3/getting-started/glossary#kyc) behind it and no ABHA number until the person links one later. | Path | Validated by | Profile details | Result | | -------------------- | --------------------------------------------------------- | --------------------------- | -------------------------------------------------------------------- | | Mobile number | Mobile [OTP](/docs/hiecm/v3/getting-started/glossary#otp) | The user types them | Self-Declared, no [KYC](/docs/hiecm/v3/getting-started/glossary#kyc) | | 14 digit ABHA number | Aadhaar OTP or mobile OTP | Returned by the ABHA system | KYC Verified | On the mobile number path, first name, year of birth, gender, address, state, district and pin code are mandatory. Middle name, last name, day and month of birth are optional. After validation on either path, show the ABHA addresses already linked to that mobile number or ABHA number. The user then picks one instead of creating a duplicate. A Self-Declared profile needs a "Link ABHA number" action. The user enters the 14 digit number and validates by Aadhaar OTP or mobile OTP. Profile details then follow the ABHA number, and the status changes to KYC Verified. ## Login Sign a user in to a PHR application by any of four routes, all of them mandatory. | Route | Validated by | | ---------------------------------- | ----------------------------------------------------------------------- | | Mobile number | Mobile OTP, then the user picks which linked ABHA address to sign in as | | An address such as `name@abdm` | Password, mobile OTP or Aadhaar OTP, by auth mode | | The default `14digit@abdm` address | Mobile OTP or Aadhaar OTP | | The 14 digit ABHA number | Mobile OTP or Aadhaar OTP | Resend OTP unlocks after 60 seconds in every flow. You also need a reset password screen behind login, secure storage of the refresh token, and more than one user profile per install with sign in and sign out. ## Profile, card and QR code | Element | What it holds | | ------------------------ | ------------------------------------------------------------------------------------------ | | Profile screen | Editable demographics, marked KYC Verified or Self-Declared | | ABHA number | Visible only on a KYC Verified profile | | ABHA address card, a PDF | Photo, full name, ABHA number, ABHA address, QR code, date of birth, gender, mobile number | | Editable, KYC Verified | Mobile number, with an OTP to the new number, and address | | Editable, Self-Declared | The same, plus photo, full name, gender and date of birth | ## Next - The calls and base URLs: [P1 API reference](/docs/hiecm/v3/api/p1). - The next milestone: [P2 Linking and records](/docs/hiecm/v3/milestones/p2). --- # P2 Linking and records P2 is the mirror of [M2 Attach](/docs/hiecm/v3/milestones/m2). M2 is a provider publishing a record. P2 is the patient discovering it and linking it to their own [ABHA address](/docs/hiecm/v3/getting-started/glossary#abha-address). [Try the P2 APIs](/docs/hiecm/v3/api/p2) [Every call in P2, one page each: the headers it needs, the payload it takes, the callback it triggers, and a request builder you can fire at the sandbox.](/docs/hiecm/v3/api/p2) [Error codes](/docs/hiecm/v3/api/p2/errors) [What each code P2 returns actually means, and the first thing to check when you see one.](/docs/hiecm/v3/api/p2/errors) ## In short - Discovery is for facilities the user visited without giving an ABHA address, and for old records. - A [HIP](/docs/hiecm/v3/getting-started/glossary#hip) is expected to answer a discovery request within 10 seconds. - Never show a [care context](/docs/hiecm/v3/getting-started/glossary#care-context) that is already linked. - Send the data transfer request within 5 minutes of the user tapping Pull Records. ## What you build Care context linking, user initiated linking, scan and share at a facility, and health locker subscriptions. ## Scan and share at a facility The facility displays a QR code holding a URL with two parameters: the HIP ID and a facility defined context such as a counter code. Your app scans it, then: 1. Shows the user what will be shared. 2. Takes consent in the specified wording. It covers sharing the ABHA address and profile with that facility for registration, and the facility linking any records it generates. 3. Calls the [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) to share the details. 4. Waits for the facility, currently expected to respond within 30 seconds. 5. Displays the token number if the facility returned one. Counter names arrive in the QR code: up to 20 alphanumeric characters, no special characters. A counter name cannot be the facility ID, the [HPID](/docs/hiecm/v3/getting-started/glossary#hpid), the HIP ID or the HIP name. ## Discovery and user initiated linking The user searches for the facility by name. Only participating facilities appear, and the facility must be a HIP linked to an [HRP](/docs/hiecm/v3/getting-started/glossary#hrp). Your app sends a discovery request carrying name, year or date of birth, gender, verified mobile number and ABHA address. A provider issued registration number is optional. The user selects care contexts and confirms. The HIP sends an [OTP](/docs/hiecm/v3/getting-started/glossary#otp) to the registered mobile number, and on successful verification the care contexts link to the ABHA address. The same flow works for government health programmes such as CoWIN, AB-PMJAY, e-Sanjeevani OPD, e-Sanjeevani HWC and RCH, each with a programme specific optional field. Three failures have specified copy. | Situation | Message | | ----------------------------------- | --------------------------------------------------------------------------------------------------------- | | The HIP is unreachable | "Couldn't Connect: We are sorry. Unable to contact your hospital. Please try again later" | | The user never visited the facility | "No health records found" | | Everything is already linked | "No new health record to link: Records of all visits are already linked and there is nothing new to link" | Records should arrive within 2 hours. ## Where the citizen is the HIP A citizen pushing a record into your app is the HIP. A health locker, where users upload their own records, puts you on that publishing side. An uploaded record is shareable once you hold three things: a link token from the M1 APIs, a care context added by HIP initiated linking from [M2 Attach](/docs/hiecm/v3/milestones/m2), and the M2 health information transfer APIs. Set the health information type from the contents or from user input. Use `HealthDocumentRecord` when it cannot be determined. ## Next - The calls and base URLs: [P2 API reference](/docs/hiecm/v3/api/p2). - The next milestone: [P3 Consent and notifications](/docs/hiecm/v3/milestones/p3). --- # P3 Consent and notifications P3 is the other side of [M3 Retrieve](/docs/hiecm/v3/milestones/m3). M3 is a requester asking for records. P3 is the patient deciding, and being told each time. A citizen fetching records is the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu), so every [PHR](/docs/hiecm/v3/getting-started/glossary#phr) application must implement that side. [Try the P3 APIs](/docs/hiecm/v3/api/p3) [Every call in P3, one page each: the headers it needs, the payload it takes, the callback it triggers, and a request builder you can fire at the sandbox.](/docs/hiecm/v3/api/p3) [Error codes](/docs/hiecm/v3/api/p3/errors) [What each code P3 returns actually means, and the first thing to check when you see one.](/docs/hiecm/v3/api/p3/errors) ## In short - Build for revocation from the start. A consent that worked yesterday can be withdrawn today, and that is the system working correctly. - A subscription is how your app hears about changes to a user's ABHA address. Set one up at address creation and at first login on a new install. - An auto approval policy stops the user approving a request every time a hospital adds a record. - The user must be able to disable a policy at any time. ## Subscriptions and notifications Ask the user for consent before you create a subscription. An approved subscription notifies your app of a new care context, a modified care context, a new consent request and a new subscription request. Surface these as device notifications. You need screens to list subscriptions, approve them, deny them and edit them. Editing covers health information types, types of visit and the time period. ## Auto approval: subscribe once, approve every time 1. Ask the user to confirm your app may retrieve new linked records automatically. 2. Set up an auto approval policy with the [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm). 3. Save the auto approval ID the HIE-CM returns. While the policy is active, the consent request you raise on a new or updated care context notification is granted immediately, and you fetch and store the record. Disable the policy and a request arrives for each record instead. ## Consent management | Capability | What it covers | | -------------------- | -------------------------------------------------------------------- | | View requests | Requesting HIU, purpose, data types, date range, validity, status | | Modify a request | Access duration, record date range, data categories, validity period | | Grant or deny | The decision goes back to the HIE-CM | | View active consents | Who currently has access, and to what | | Revoke | Withdraw at any time. Sharing under that consent stops immediately | The Consents tab and the Subscriptions tab group state the same way: a Requests section holding Requested, Denied and Expired, and an Approved section holding Granted and Revoked. ## Fetching and displaying records Once a care context is linked to the user's ABHA address: 1. Your app receives the notification. 2. It creates a consent request for that record and sends it to the HIE-CM. 3. The consent is granted, automatically if a policy exists, otherwise by the user. 4. It raises a health information request with the approved [consent artefact](/docs/hiecm/v3/getting-started/glossary#consent-artefact). 5. The [HIP](/docs/hiecm/v3/getting-started/glossary#hip) sends the records across the network. 6. Your app stores them for long term access and displays them, preferably in chronological order. The test cases cover every health information type, structured and unstructured: diagnostic report, prescription, discharge summary, consultation note, immunisation record, wellness record and health document record. ## Next - The calls and base URLs: [P3 API reference](/docs/hiecm/v3/api/p3). - Back to the four provider milestones: [Milestones](/docs/hiecm/v3/milestones). - Take your integration to production: [Go live](/docs/hiecm/v3/getting-started/going-live). --- # Authentication Generated from the specifications. Every scheme and header below is declared in one of them. ## Gateway session **gatewaySession**, `http` `bearer`. The `accessToken` returned by `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer <ACCESS_TOKEN>`. **bearerAuth**, `http` `bearer`. JWT Bearer token from `POST /api/hiecm/gateway/v3/sessions`. Header: `Authorization: Bearer {accessToken}` | Header | Required | What it is | | ------------ | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `REQUEST-ID` | yes | A fresh UUID that you generate for this request. It is how you and the gateway correlate a call with its callback and with a support ticket, so log it. Reusing one across requests makes both impossible. | | `TIMESTAMP` | yes | The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. | | `X-CM-ID` | yes | Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. Sending the wrong one against the right host is a common first-day failure and reads as an authorisation error. | ## M1 ABHA identity **gatewaySession**, `http` `bearer`. The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer <ACCESS_TOKEN>`. **bearerAuth**, `http` `bearer`. JWT Bearer token from `POST /api/hiecm/gateway/v3/sessions`. Header: `Authorization: Bearer {accessToken}` **xToken**, `apiKey`. Short-lived session token returned in login/verify responses. Required for all `/profile/account/*` operations. Header: `X-Token: {token}` | Header | Required | What it is | | ---------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `REQUEST-ID` | yes | Unique UUID v4 per request. Used for idempotency and distributed tracing. Generate a fresh UUID for every call. | | `TIMESTAMP` | yes | ISO 8601 UTC timestamp of the request. | | `X-token` | no | The user scoped token returned when a person logs in or verifies an OTP. Profile calls act on one account, so they need this in addition to the gateway token. Required on the calls that read or change a specific person's account. Send the bare token. Unlike the Authorization header this one carries no `Bearer `prefix, and adding one is refused as `ABDM-1094` with the message `X-token expired`. That message names the wrong thing: a token rejected one second after it was issued has not expired, it was malformed. Check the prefix before the lifetime. | | `BENEFIT_NAME` | no | The benefit scheme an enrolment belongs to. Send `healthid api` on the enrol and search calls, and `healthid` on the login OTP and verify calls under Find ABHA. On the enrolment OTP request the header is present but explicitly disabled, so it is not sent there. A login OTP request sent with `healthid api` rather than `healthid` was accepted on the sandbox on 2026-09-11, so the login calls may take either. NHA's files spell this header four different ways and use scheme values beyond healthid. Which spelling each endpoint accepts is not confirmed against the sandbox. The Conventions page for this module lists all four. | | `T-token` | no | The transaction token that carries state between the two halves of a login. Returned by the verify call and sent back on the account selection call. Like X-token, the value carries a `Bearer `prefix in every one of the recorded requests. | | `R-token` | no | The refresh token, sent when asking for a new user token without making the person log in again. Like X-token, the value carries a `Bearer `prefix. | | `aadhaarNumber` | yes | The person's Aadhaar number, RSA encrypted against the ABDM public key and sent as a header rather than in a body. The recorded value is an encrypted blob, never the raw number: encrypt it the same way as an enrolment `loginId`. See the input encryption concept atom for the padding rules. | | `healthIdNumber` | yes | The 14 digit ABHA number, sent plain in the recorded request, in the dashed `91-XXXX-XXXX-XXXX` form. | | `KEY_TYPE` | no | Which ABDM public key the encryption helper should use. | | `TRANSACTION_ID` | no | The enrolment transaction this call belongs to, when the transaction is not carried in the body. | ## M2 Linking and sharing **gatewaySession**, `http` `bearer`. The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer <ACCESS_TOKEN>`. M2 also uses per flow tokens, a link token for linking and an authorisation token for patient scoped calls. Their header names are not yet published. **bearerAuth**, `http` `bearer`. Bearer token obtained from POST /hiecm/gateway/v3/sessions | Header | Required | What it is | | -------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `REQUEST-ID` | yes | 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. | | `TIMESTAMP` | yes | The current time in ISO 8601, UTC, with milliseconds and a `Z` suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC. | | `X-CM-ID` | yes | Which consent manager you are talking to. `sbx` 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. | | `X-Link-Token` | yes | Short-lived link token generated via POST /hiecm/v3/token/generate-token | | `X-HIP-ID` | yes | Identifier of the Health Information Provider the request or callback belongs to. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. | | `X-HIU-ID` | yes | Identifier of the Health Information User the request or callback belongs to. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. | ## M3 Consent and fetching **gatewaySession**, `http` `bearer`. The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer <ACCESS_TOKEN>`. **bearerAuth**, `http` `bearer`. Bearer token obtained from POST /hiecm/gateway/v3/sessions | Header | Required | What it is | | ------------ | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `REQUEST-ID` | yes | A fresh UUID that you generate for this request. The callback that answers it carries the same value. In M3 a single consent can produce several callbacks, so keep the mapping from request id to consent request id rather than relying on ordering. | | `TIMESTAMP` | yes | The current time in ISO 8601 UTC, with milliseconds and the `Z` suffix. The gateway rejects a request whose timestamp has drifted too far from its own clock, so take this from a synchronised clock rather than from a local one. | | `X-CM-ID` | yes | Which consent manager you are talking to. `sbx` on the sandbox and `abdm` in production. | | `X-HIU-ID` | yes | Identifier of the health information user the request or callback is intended for. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. | ## M4 HPR and HFR **gatewaySession**, `http` `bearer`. The `accessToken` from `POST /api/hiecm/gateway/v3/sessions`. Send it as `Authorization: Bearer <ACCESS_TOKEN>`. ## P1 PHR identity and profile **gatewaySession**, `http` `bearer`. The access token from `POST /api/hiecm/gateway/v3/sessions`. ## P2 PHR linking and records **gatewaySession**, `http` `bearer`. The access token from `POST /api/hiecm/gateway/v3/sessions`. ## P3 PHR consent and notifications **gatewaySession**, `http` `bearer`. The access token from `POST /api/hiecm/gateway/v3/sessions`. ## PHR application services **gatewaySession**, `http` `bearer`. The access token from `POST /api/hiecm/gateway/v3/sessions`. --- # Sandbox data dictionary The database behind the sandbox portal, the site where you register your organisation, declare which milestones you will build and apply for sandbox exit. Read it to find what the portal records about your application, and what a status you see on screen is called underneath. It is the portal's own store, not an [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) API, so nothing here is an endpoint you can call. ## What the source contains Three of the portal's five record groups are listed here. | Sheet | What it holds | On this page | | ------------- | -------------------------------------------------------------- | ----------------------------------------------------------- | | Tables | 31 tables in the `public` schema, with the owner of each. | Yes, as the sections below | | Table Columns | 636 columns with type, nullability and a one line description. | Yes | | Indexes | 45 indexes with their definitions. | Yes, in [Indexes](#indexes) | | Sequences | 34 Postgres sequences. | No, see [What is not transcribed](#what-is-not-transcribed) | | Def values | 104 column defaults. | No, see [What is not transcribed](#what-is-not-transcribed) | ## How to read these tables Each section below is one database table. **Field** is the column name, **Type** the Postgres type, **Nullable** `No` for a `NOT NULL` column, and **Meaning** what it records. - `sd_id` is the self declaration identifier and the join key across most tables. `id_public` is a second, public facing identifier many tables carry alongside the primary key. - These names are misspelled in the schema itself and reproduced as they are: `messege`, `previlege`, `redy_for_testing`, `suporting_doc`, `integratin_phase`, `user_jorny`, `admin_coment`, `sare_date`. - Thin descriptions, such as `flag` on `sd_exit`, are reproduced as published, not padded them out with a guess. ### Abbreviations used in the descriptions | Short form | What it means | | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm), NDHM | The programme. NDHM is the former name and both appear in the source. | | [PHR](/docs/hiecm/v3/getting-started/glossary#phr) | Personal health record application. | | [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) | Health information user. | | [UHI](/docs/hiecm/v3/getting-started/glossary#uhi) | Unified Health Interface. | | [NHCX](/docs/hiecm/v3/getting-started/glossary#nhcx) | National Health Claims Exchange. | | [HMIS](/docs/hiecm/v3/getting-started/glossary#hmis) | Hospital management information system. | | [OTP](/docs/hiecm/v3/getting-started/glossary#otp) | One time password. | | SPOC | Single point of contact, the named person on an application. | | [HTC](/docs/hiecm/v3/getting-started/glossary#health-tech-committee) | Health Tech Committee, the body that reviews your integration at the end of the exit process. | | [WASA](/docs/hiecm/v3/getting-started/glossary#wasa) | The security audit that produces your Safe to Host certificate. See [Security audit](/docs/hiecm/v3/getting-started/security-audit). | | DHIS, V3 | Platform terms used inside the sandbox portal's own records. | ## Tables at a glance | Group | Table | What it holds | | ------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | Registration and account | [`sd_login`](#sd_login) | The main registration record for an organisation on the sandbox portal | | Registration and account | [`password`](#password) | Password values and their timestamps, held apart from `sd_login` | | Registration and account | [`ci_sessions`](#ci_sessions) | Web session state for a signed in portal user | | Registration and account | [`address`](#address) | The registered address attached to a self declaration | | Registration and account | [`active_integrator`](#active_integrator) | A short record marking an application as an active integrator | | Self declaration and milestones | [`self_declaration`](#self_declaration) | What an organisation declared it would build, and the start and end dates it gave for each milestone | | Self declaration and milestones | [`sd_status`](#sd_status) | The review trail for an application: administrator decision, four HTC review stages, production access status | | Sandbox exit | [`sd_exit`](#sd_exit) | The sandbox exit application: contacts, integration details, uploaded evidence and every review stage on it | | Sandbox exit | [`sd_exit_docs`](#sd_exit_docs) | Files uploaded with a sandbox exit application | | Sandbox exit | [`sd_doc_type`](#sd_doc_type) | The list of document types an application may upload | | Sandbox exit | [`wasa_dhis_initiation_details`](#wasa_dhis_initiation_details) | WASA issue and expiry dates against a client identifier and a bridge identifier | | Gateway specific registration | [`sd_hiu`](#sd_hiu) | Client identifiers issued for HIU registrations | | Gateway specific registration | [`sd_uhi`](#sd_uhi) | Requests to work on UHI, with the service type and the stated intent | | Gateway specific registration | [`hcx`](#hcx) | Organisation details captured for a health claims exchange registration | | Gateway specific registration | [`hcx_address`](#hcx_address) | The registered address for an `hcx` record | | Gateway specific registration | [`nhcx_exit`](#nhcx_exit) | The NHCX application and its administrative review status | | Portal administration | [`mst_role`](#mst_role) | Roles inside the portal and their landing pages | | Portal administration | [`mst_modules`](#mst_modules) | Portal screens and menu entries | | Portal administration | [`mst_privilege`](#mst_privilege) | Which role may reach which module | | Audit, logs and messages | [`audit_log`](#audit_log) | Before and after values for a changed record, with who changed it | | Audit, logs and messages | [`security_audit_trail`](#security_audit_trail) | Request level audit: endpoint, method, user agent, correlation identifier and payload | | Audit, logs and messages | [`log`](#log) | Token generation and email dispatch events against a client | | Audit, logs and messages | [`notification_audit`](#notification_audit) | Notifications sent, by template, recipient and delivery status | | Audit, logs and messages | [`concern`](#concern) | Support messages raised through the portal | | Reference data and content | [`std_data`](#std_data) | STD dialling codes, with their state, LDCA and SDCA names | | Reference data and content | [`upcoming_session`](#upcoming_session) | Sessions listed on the portal, with joining links | | Replication internals | [`awsdms_apply_exceptions`](#awsdms_apply_exceptions) | Exceptions raised by the portal's AWS Database Migration Service tasks | | Backup copies | [`sd_login_bk`, `sd_login_bk_16062026`, `sd_login_bk_20012026_updt`, `sd_exit_live`](#backup-copies) | Tables that repeat the column lists of `sd_login` and `sd_exit` | ## sd\_login | Field | Type | Nullable | Meaning | | ----------------------- | --------------------------- | -------- | ---------------------------------------------------------------------- | | `sd_id` | integer | No | Primary key and unique identifier of the self-declaration registration | | `role_id` | smallint | Yes | Role identifier assigned to the user | | `name` | character varying | Yes | Name of the registered user | | `email` | character varying | Yes | Email address of the registered user | | `mobile` | character varying | Yes | Mobile number of the registered user | | `password` | character varying | Yes | Encrypted password of the user account | | `application_status` | character varying | Yes | Current application processing status | | `status` | character varying | Yes | Account status of the user | | `statusmessege` | character varying | Yes | Status message associated with the account | | `organization` | character varying | Yes | Organization name | | `gst_no` | character varying | Yes | GST registration number | | `business_type` | text | Yes | Business type of the organization | | `entity_type` | character varying | Yes | Entity type of the organization | | `address` | character varying | Yes | Registered address of the organization | | `register_status` | character varying | Yes | Registration completion status | | `register_india_status` | character varying | Yes | Indicates whether the organization is registered in India | | `field_detail` | text | Yes | Additional business or operational details | | `website` | character varying | Yes | Official website of the organization | | `ecosystem` | text | Yes | Ecosystem services or solutions associated with the organization | | `ip_address` | character varying | Yes | IP address from which registration was performed | | `created_at_old` | character varying | Yes | Legacy creation timestamp stored as text | | `application_type` | character varying | Yes | Type of application submitted | | `updated_at_old` | character varying | Yes | Legacy update timestamp stored as text | | `type_of_application` | character varying | Yes | Detailed classification of the application | | `application_id` | character varying | Yes | Unique application identifier | | `category` | character varying | Yes | Category of the organization or application | | `product_name` | character varying | Yes | Name of the product or solution | | `integration_level` | character varying | Yes | Level of integration achieved by the application | | `certificate` | bytea | Yes | Uploaded certificate document | | `certificate_ext` | character varying | Yes | File extension of the uploaded certificate | | `solution_type` | text | Yes | Type of solution offered by the organization | | `hmis` | character varying | Yes | Hospital Management Information System details | | `service` | text | Yes | Services provided by the organization | | `location_select_all` | character varying | Yes | Indicator for all-location selection | | `state_code` | text | Yes | State codes associated with the organization | | `city_code` | text | Yes | City codes associated with the organization | | `area_code` | text | Yes | Area codes associated with the organization | | `address_state` | character varying | Yes | State name of the organization address | | `address_city` | character varying | Yes | City name of the organization address | | `created_at_old1` | timestamp without time zone | Yes | Legacy creation timestamp | | `updated_at_old1` | timestamp without time zone | Yes | Legacy update timestamp | | `gst_certificate_ext` | character varying | Yes | File extension of the GST certificate | | `gst_certificate` | bytea | Yes | Uploaded GST certificate document | | `production_client_id` | character varying | Yes | Production environment client identifier | | `created_at` | timestamp with time zone | Yes | Timestamp when the record was created | | `updated_at` | timestamp with time zone | Yes | Timestamp when the record was last updated | | `upload_time` | timestamp with time zone | Yes | Timestamp when documents were uploaded | | `transaction_id` | character varying | Yes | Transaction identifier for registration activities | | `otp_status` | character varying | Yes | Status of OTP verification | | `solution_type_others` | character varying | Yes | Additional solution type details | | `payer_category` | character varying | Yes | Payer category associated with the organization | | `dhis_solution_type` | character varying | Yes | DHIS solution type selected by the organization | ## password | Field | Type | Nullable | Meaning | | ------------ | --------------------------- | -------- | --------------------------------------------------- | | `id` | bigint | No | Primary key of the password record | | `created_at` | timestamp with time zone | Yes | Timestamp when the password record was created | | `updated_at` | timestamp with time zone | Yes | Timestamp when the password record was last updated | | `value` | character varying | Yes | Encrypted or hashed password value | | `email_id` | character varying | Yes | Email address associated with the password record | | `createdat` | timestamp without time zone | Yes | Legacy creation timestamp | | `updatedat` | timestamp without time zone | Yes | Legacy update timestamp | | `emailid` | character varying | Yes | Legacy email address field | | `id_public` | bigint | No | Public identifier of the password record | ## ci\_sessions | Field | Type | Nullable | Meaning | | ------------ | ----------------- | -------- | ------------------------------------------------- | | `id` | character varying | No | Primary key | | `ip_address` | character varying | No | IP address associated with the user session | | `data` | text | No | Serialized session data stored by the application | | `timestamp` | integer | Yes | timestamp indicating the last session activity | ## address | Field | Type | Nullable | Meaning | | ------------------ | ----------------- | -------- | --------------------------------- | | `id` | integer | No | Primary key of the address record | | `address_line1` | character varying | Yes | Address line 1 | | `address_line2` | character varying | Yes | Address line 2 | | `state_code` | bigint | Yes | State code | | `state_name` | character varying | Yes | State name | | `district_code` | bigint | Yes | District code | | `district_name` | character varying | Yes | District name | | `village_code` | bigint | Yes | Village code | | `village_name` | character varying | Yes | Village name | | `pin_code` | character varying | Yes | Postal PIN code | | `sd_id` | integer | Yes | Self Declaration identifier | | `complete_address` | character varying | Yes | Complete formatted address | ## active\_integrator | Field | Type | Nullable | Meaning | | ---------------- | ------------------------ | -------- | -------------------------------------------------- | | `id` | integer | No | Unique identifier for the active integrator record | | `application_id` | character varying | Yes | Application identifier | | `added_by` | character varying | Yes | User who added the record | | `created_at` | timestamp with time zone | Yes | Timestamp when the record was created | | `id_public` | bigint | No | Public identifier of the active integrator record | ## self\_declaration | Field | Type | Nullable | Meaning | | -------------------------- | ------------------------ | -------- | ----------------------------------------------------------- | | `id` | integer | No | Primary key of the self declaration record | | `sd_id` | integer | Yes | Self Declaration identifier associated with the application | | `complete_mil` | character varying | Yes | Indicates whether the milestones have been completed | | `will_complete_mil` | character varying | Yes | Expected timeline for milestone completion | | `working_on` | character varying | Yes | Current area or milestone being worked on | | `ip_address` | character varying | Yes | IP address from which the self declaration was submitted | | `created_at` | timestamp with time zone | Yes | Timestamp when the self declaration record was created | | `m1_start_date` | timestamp with time zone | Yes | Start date of Milestone 1 | | `m1_end_date` | timestamp with time zone | Yes | Completion date of Milestone 1 | | `m2_start_date` | timestamp with time zone | Yes | Start date of Milestone 2 | | `m2_end_date` | timestamp with time zone | Yes | Completion date of Milestone 2 | | `m3_start_date` | timestamp with time zone | Yes | Start date of Milestone 3 | | `m3_end_date` | timestamp with time zone | Yes | Completion date of Milestone 3 | | `tentative_date` | timestamp with time zone | Yes | Tentative date for achieving planned milestones | | `phr_start_date` | timestamp with time zone | Yes | Start date for PHR integration activities | | `health_locker_start_date` | timestamp with time zone | Yes | Start date for Health Locker integration activities | | `phr_end_date` | timestamp with time zone | Yes | Completion date for PHR integration activities | | `health_locker_end_date` | timestamp with time zone | Yes | Completion date for Health Locker integration activities | | `m4_start_date` | timestamp with time zone | Yes | Start date of Milestone 4 | | `m4_end_date` | timestamp with time zone | Yes | Completion date of Milestone 4 | | `nhcx_start_date` | timestamp with time zone | Yes | Start date of NHCX integration activities | | `nhcx_end_date` | timestamp with time zone | Yes | Completion date of NHCX integration activities | ## sd\_status | Field | Type | Nullable | Meaning | | --------------------------------- | --------------------------- | -------- | ----------------------------------------------------- | | `id` | integer | No | Primary key of the status  record | | `sd_id` | bigint | Yes | Self Declaration identifier | | `client_id` | character varying | Yes | Client identifier associated with the application | | `admin_id` | smallint | Yes | Administrator identifier who reviewed the application | | `admin_status` | character varying | Yes | Administrative review status | | `admin_comment` | character varying | Yes | Comments provided by the administrator | | `date_old` | character varying | Yes | Legacy date value for administrative review | | `htc1_id` | character varying | Yes | Reviewer identifier for HTC stage 1 | | `htc1_status` | character varying | Yes | Status of HTC review stage 1 | | `htc1_comment` | character varying | Yes | Comments for HTC review stage 1 | | `date1_old` | character varying | Yes | Legacy date value for HTC stage 1 | | `htc2_id` | character varying | Yes | Reviewer identifier for HTC stage 2 | | `htc2_status` | character varying | Yes | Status of HTC review stage 2 | | `htc2_comment` | character varying | Yes | Comments for HTC review stage 2 | | `date2_old` | character varying | Yes | Legacy date value for HTC stage 2 | | `htc3_id` | character varying | Yes | Reviewer identifier for HTC stage 3 | | `htc3_status` | character varying | Yes | Status of HTC review stage 3 | | `htc3_comment` | character varying | Yes | Comments for HTC review stage 3 | | `date3_old` | character varying | Yes | Legacy date value for HTC stage 3 | | `edit_status` | character varying | Yes | Indicates whether the application is editable | | `final_status` | bigint | Yes | Final approval or rejection status | | `user_jorny` | character varying | Yes | Current stage of the user journey | | `production_status` | character varying | Yes | Production access approval status | | `admin_production_reject_comment` | text | Yes | Reason for production access rejection | | `date4_old` | character varying | Yes | Legacy date value for HTC stage 4 | | `htc4_id` | character varying | Yes | Reviewer identifier for HTC stage 4 | | `htc4_status` | character varying | Yes | Status of HTC review stage 4 | | `htc4_comment` | character varying | Yes | Comments for HTC review stage 4 | | `htc4_date` | character varying | Yes | Date of HTC stage 4 review | | `gen_token` | text | Yes | Generated access token details | | `gen_securate` | text | Yes | Generated security credential details | | `email_send` | text | Yes | Email notification details | | `send_date` | character varying | Yes | Date when notification email was sent | | `date` | timestamp without time zone | Yes | Administrative review timestamp | | `date1` | timestamp without time zone | Yes | HTC stage 1 review timestamp | | `date2` | timestamp without time zone | Yes | HTC stage 2 review timestamp | | `date3` | timestamp without time zone | Yes | HTC stage 3 review timestamp | | `date4` | timestamp without time zone | Yes | HTC stage 4 review timestamp | | `date_temp` | timestamp with time zone | Yes | Temporary timestamp for administrative review | | `date1_temp` | timestamp with time zone | Yes | Temporary timestamp for HTC stage 1 review | | `date2_temp` | timestamp with time zone | Yes | Temporary timestamp for HTC stage 2 review | | `date3_temp` | timestamp with time zone | Yes | Temporary timestamp for HTC stage 3 review | | `date4_temp` | timestamp with time zone | Yes | Temporary timestamp for HTC stage 4 review | | `v3_access` | bigint | Yes | Indicates V3 platform access status | ## sd\_exit | Field | Type | Nullable | Meaning | | ---------------------------- | ------------------------ | -------- | -------------------------------------------------------- | | `id` | integer | No | Primary key of the self-declaration exit record | | `sd_id` | integer | Yes | Self Declaration identifier | | `organization` | character varying | Yes | Name of the organization | | `spoc_name` | character varying | Yes | Name of the Single Point of Contact (SPOC) | | `spoc_email` | character varying | Yes | Email address of the SPOC | | `spoc_phone` | character varying | Yes | Mobile number of the SPOC | | `ndhm_role` | character varying | Yes | NDHM/ABDM role selected by the organization | | `milestone_dif` | character varying | Yes | Milestone completion status | | `complete_integration` | character varying | Yes | Indicates whether integration has been completed | | `integration_detail` | text | Yes | Details of the integration completed by the organization | | `redy_for_testing` | character varying | Yes | Indicates whether the application is ready for testing | | `demo_time` | character varying | Yes | Preferred date and time for demo or testing | | `ip_address` | character varying | Yes | IP address from which the form was submitted | | `organization_evaluate` | character varying | Yes | Assessment or evaluation details of the organization | | `closer` | character | Yes | Closure status of the application | | `host_status` | character varying | Yes | Hosting status of the application | | `wasa_file` | bytea | Yes | Uploaded WASA document file | | `host_file` | bytea | Yes | Uploaded hosting document file | | `ext_wasafile` | character varying | Yes | Extension of the WASA file | | `ext_hostfile` | character varying | Yes | Extension of the hosting document file | | `htc1_status` | character varying | Yes | Status of HTC review stage 1 | | `htc1comment` | character varying | Yes | Comments for HTC review stage 1 | | `htc2_status` | character varying | Yes | Status of HTC review stage 2 | | `htc2comment` | character varying | Yes | Comments for HTC review stage 2 | | `htc3status` | character varying | Yes | Status of HTC review stage 3 | | `htc3comment` | character varying | Yes | Comments for HTC review stage 3 | | `admin_status` | character varying | Yes | Administrative review status | | `admin_coment` | character varying | Yes | Administrative review comments | | `integratin_phase` | character varying | Yes | Current integration phase | | `testing_file_ext` | character varying | Yes | Extension of the functional testing report file | | `function_testing_file` | bytea | Yes | Uploaded functional testing report | | `bridge_url` | character varying | Yes | Bridge URL used for integration | | `policy_file` | bytea | Yes | Uploaded policy document | | `policy_file_ext` | character varying | Yes | Extension of the policy document | | `webhook` | character varying | Yes | Webhook URL configured for integration | | `remarks` | character varying | Yes | Additional remarks provided by the applicant | | `app_status` | character varying | Yes | Application status | | `live_aap_status` | character varying | Yes | Live application deployment status | | `app_link` | character varying | Yes | Application access URL | | `suporting_doc_name` | character varying | Yes | Name of the uploaded supporting document | | `suporting_doc` | bytea | Yes | Supporting document file | | `suporting_doc_ext` | character varying | Yes | Extension of the supporting document | | `flag` | character varying | Yes | Flag indicating special processing status | | `created_at` | timestamp with time zone | Yes | Timestamp when the record was created | | `sare_date` | timestamp with time zone | Yes | Date shared with review stakeholders | | `created_date` | timestamp with time zone | Yes | Submission date of the application | | `admin_status_date` | timestamp with time zone | Yes | Date of administrative status update | | `htc1_status_date` | timestamp with time zone | Yes | Date of HTC stage 1 status update | | `htc2_status_date` | timestamp with time zone | Yes | Date of HTC stage 2 status update | | `htc3_status_date` | timestamp with time zone | Yes | Date of HTC stage 3 status update | | `updated_at` | timestamp with time zone | Yes | Timestamp when the record was last updated | | `htc4_status` | character varying | Yes | Status of HTC review stage 4 | | `htc4_comment` | character varying | Yes | Comments for HTC review stage 4 | | `final_status` | bigint | Yes | Final approval status of the application | | `wasa_file_name` | character varying | Yes | Name of the uploaded WASA file | | `host_file_name` | character varying | Yes | Name of the uploaded hosting file | | `function_testing_file_name` | character varying | Yes | Name of the uploaded functional testing report | | `product_name` | character varying | Yes | Name of the product or application | | `organisation_website` | character varying | Yes | Official website of the organization | | `company_logo_url` | character varying | Yes | URL of the organization logo | | `brief_on_organisation` | text | Yes | Brief description of the organization | | `self_declaration_id` | integer | Yes | Reference to the self-declaration record | | `app_name` | character varying | Yes | Application name | | `supporting_doc_type` | character varying | Yes | Type of supporting document uploaded | | `gstn_id` | character varying | Yes | GSTN registration number | | `exempted_gst` | character varying | Yes | Indicates whether GST exemption is applicable | | `final_status_date` | timestamp with time zone | Yes | Date when the final status was assigned | | `htc4_status_date` | timestamp with time zone | Yes | Date of HTC stage 4 status update | ## sd\_exit\_docs | Field | Type | Nullable | Meaning | | --------------------- | ------------------------ | -------- | -------------------------------------------------------- | | `id` | integer | No | Primary key of the SD exit document record | | `exit_id` | bigint | No | Reference to the SD exit application record | | `doc_type_id` | integer | No | Reference to the document type | | `files` | bytea | Yes | Uploaded document file content | | `file_name` | character varying | Yes | Name of the uploaded document | | `file_ext` | character varying | Yes | File extension of the uploaded document | | `supporting_doc_type` | character varying | Yes | Category or type of supporting document | | `created_at` | timestamp with time zone | Yes | Timestamp when the document record was created | | `updated_at` | timestamp with time zone | Yes | Timestamp when the document record was last updated | | `sd_id` | integer | Yes | Self Declaration identifier associated with the document | ## sd\_doc\_type | Field | Type | Nullable | Meaning | | ------------ | ------------------------ | -------- | ------------------------------------------------- | | `id` | integer | No | Primary key of the document type record | | `name` | character varying | Yes | Name of the supported document type | | `created_at` | timestamp with time zone | Yes | Timestamp when the document type was created | | `updated_at` | timestamp with time zone | Yes | Timestamp when the document type was last updated | ## wasa\_dhis\_initiation\_details | Field | Type | Nullable | Meaning | | ------------------ | ------------------------ | -------- | ----------------------------------------------------------- | | `id` | integer | No | Primary key of the WASA DHIS initiation details record | | `sd_id` | integer | Yes | Self Declaration identifier associated with the application | | `client_id` | character varying | Yes | Client identifier assigned to the participant | | `bridge_id` | character varying | Yes | Bridge identifier associated with the integration | | `wasa_issue_date` | timestamp with time zone | Yes | Date when the WASA was issued | | `wasa_expiry_date` | timestamp with time zone | Yes | Date when the WASA expires | | `wasa_status` | character varying | Yes | Current status of the WASA | | `milestone` | character varying | Yes | Current implementation milestone achieved | | `updated_at` | timestamp with time zone | Yes | Timestamp when the record was last updated | ## sd\_HIU | Field | Type | Nullable | Meaning | | -------------- | ------------------------ | -------- | ---------------------------------------------------------------- | | `id` | integer | No | Primary key of the SD HIU record | | `sd_id` | integer | Yes | Self Declaration identifier associated with the HIU registration | | `client_id` | character varying | Yes | Unique client identifier assigned to the HIU | | `organization` | character varying | Yes | Name of the HIU organization | | `created_at` | timestamp with time zone | Yes | Timestamp when the HIU record was created | ## sd\_UHI | Field | Type | Nullable | Meaning | | -------------------- | ------------------------ | -------- | ------------------------------------------------------- | | `id` | bigint | No | Primary key of the SD UHI record | | `client_id` | character varying | Yes | Client identifier associated with the UHI request | | `email_id` | character varying | Yes | Email address of the requester | | `intent_for_request` | character varying | Yes | Purpose or intent of the UHI request | | `created_at` | timestamp with time zone | Yes | Timestamp when the UHI request was created | | `sd_id` | integer | Yes | Self Declaration identifier associated with the request | | `id_public` | bigint | No | Public identifier of the UHI request record | | `type_of_service` | character varying | Yes | Type of service requested under UHI | | `tell_us_about` | character varying | Yes | Description of the requester use case or requirement | | `extra_details` | character varying | Yes | Additional details provided by the requester | ## hcx | Field | Type | Nullable | Meaning | | ---------------------------- | ------------------------ | -------- | ---------------------------------------------------------------- | | `id` | bigint | No | Primary key of the HCX record | | `sd_id` | bigint | Yes | Self Declaration identifier associated with the HCX registration | | `name` | character varying | Yes | Name of the registrant or organization representative | | `organization` | character varying | Yes | Organization name | | `email` | character varying | Yes | Email address of the registrant | | `mobile` | character varying | Yes | Mobile number of the registrant | | `password` | character varying | Yes | Encrypted password for the HCX account | | `solution_type` | text | Yes | Type of solution offered by the organization | | `field_detail` | text | Yes | Additional details about the solution or field of operation | | `entity_type` | character varying | Yes | Type of entity participating in HCX | | `type_of_application` | character varying | Yes | Type of application being registered | | `category` | character varying | Yes | Category of the organization or application | | `business_type` | character varying | Yes | Business classification of the organization | | `registered_in_india_status` | character varying | Yes | Indicates whether the organization is registered in India | | `gst_no` | character varying | Yes | GST registration number | | `product_name` | character varying | Yes | Name of the product or solution | | `website` | character varying | Yes | Official website URL of the organization | | `application_type` | character varying | Yes | Application role or type within HCX | | `created_at` | timestamp with time zone | Yes | Timestamp when the record was created | | `updated_at` | timestamp with time zone | Yes | Timestamp when the record was last updated | | `id_public` | bigint | No | Public identifier of the HCX record | | `payer_category` | character varying | Yes | Category of payer associated with the HCX application | ## hcx\_address | Field | Type | Nullable | Meaning | | -------------------- | ----------------- | -------- | ------------------------------------------------------- | | `id` | bigint | No | Primary key of the HCX address record | | `hcx_id` | bigint | Yes | Reference identifier of the associated HCX registration | | `registered_address` | character varying | Yes | Registered business address of the organization | | `state_code` | bigint | Yes | State code of the registered address | | `state_name` | character varying | Yes | State name of the registered address | | `district_code` | bigint | Yes | District code of the registered address | | `district_name` | character varying | Yes | District name of the registered address | | `pin_code` | character varying | Yes | Postal PIN code of the registered address | | `id_public` | bigint | No | Public identifier of the HCX address record | ## NHCX\_exit | Field | Type | Nullable | Meaning | | ------------------------------ | ------------------------ | -------- | ---------------------------------------------------------------- | | `id` | bigint | No | Primary key of the NHCX exit record | | `sd_id` | bigint | Yes | Self Declaration identifier associated with the NHCX exit record | | `name` | character varying | Yes | Name of the applicant or organization representative | | `organization` | character varying | Yes | Organization name associated with the NHCX registration | | `email` | character varying | Yes | Email address of the applicant | | `mobile` | character varying | Yes | Mobile number of the applicant | | `nhcx_final_status` | bigint | Yes | Final status of the NHCX application | | `nhcx_admin_status` | character varying | Yes | Administrative review status of the NHCX application | | `nhcx_admin_comment` | character varying | Yes | Comments or remarks provided by the administrator | | `nhcx_admin_status_updated_at` | timestamp with time zone | Yes | Timestamp when the administrative status was last updated | | `created_at` | timestamp with time zone | Yes | Timestamp when the NHCX exit record was created | ## mst\_role | Field | Type | Nullable | Meaning | | -------------------- | ------------------------ | -------- | ------------------------------------------------ | | `role_id` | integer | No | Primary key of the role | | `role_name` | character varying | Yes | Name of the role | | `role_description` | character varying | Yes | Description of the role and its responsibilities | | `role_status` | smallint | Yes | Status of the role (e.g., Active or Inactive) | | `role_created_by` | smallint | Yes | Identifier of the user who created the role | | `role_created_ip` | character varying | Yes | IP address from which the role was created | | `role_modified_by` | character varying | Yes | User who last modified the role | | `role_modified_ip` | character varying | Yes | IP address from which the role was last modified | | `role_landing_page` | smallint | Yes | Default landing page assigned to the role | | `is_subrole` | character varying | Yes | Indicates whether the role is a sub-role | | `parentrole_id` | character varying | Yes | Identifier of the parent role | | `role_created_date` | timestamp with time zone | Yes | Timestamp when the role was created | | `role_modified_date` | timestamp with time zone | Yes | Timestamp when the role was last modified | ## mst\_modules | Field | Type | Nullable | Meaning | | ------------------ | ------------------------ | -------- | -------------------------------------------------- | | `module_id` | integer | No | Primary key of the module | | `module_name` | character varying | Yes | Name of the module | | `module_type` | character varying | Yes | Type or category of the module | | `module_desc` | character varying | Yes | Description of the module | | `is_parent` | character varying | Yes | Indicates whether the module is a parent module | | `parent_id` | character varying | Yes | Identifier of the parent module | | `order_appearance` | character varying | Yes | Display order of the module in the application | | `is_display` | character varying | Yes | Indicates whether the module should be displayed | | `delete_status` | character varying | Yes | Logical deletion status of the module | | `link` | character varying | Yes | Navigation URL or link associated with the module | | `image_path` | character varying | Yes | Path of the image associated with the module | | `icon_class` | character varying | Yes | CSS icon class used for module display | | `created_by` | character varying | Yes | User who created the module | | `created_ip` | character varying | Yes | IP address from which the module was created | | `modified_by` | character varying | Yes | User who last modified the module | | `modified_ip` | character varying | Yes | IP address from which the module was last modified | | `created_date` | timestamp with time zone | Yes | Timestamp when the module was created | | `modified_date` | timestamp with time zone | Yes | Timestamp when the module was last modified | ## mst\_privilege | Field | Type | Nullable | Meaning | | ------------------- | --------------------------- | -------- | ------------------------------------------------------------ | | `previlege_id` | integer | No | Primary key of the privilege record | | `role_id` | smallint | Yes | Role identifier associated with the privilege | | `module_id` | character varying | Yes | Module identifier for which access is granted | | `access_id` | character varying | Yes | Access permission identifier | | `created_by` | character varying | Yes | User who created the privilege record | | `created_date_old` | character varying | Yes | Legacy created date value retained for reference | | `created_ip` | character varying | Yes | IP address from which the privilege record was created | | `modified_by` | character varying | Yes | User who last modified the privilege record | | `modified_date_old` | character varying | Yes | Legacy modified date value retained for reference | | `modified_ip` | character varying | Yes | IP address from which the privilege record was last modified | | `created_date` | timestamp without time zone | Yes | Timestamp when the privilege record was created | | `modified_date` | timestamp without time zone | Yes | Timestamp when the privilege record was last modified | | `id_public` | bigint | No | Public identifier of the privilege record | ## audit\_log | Field | Type | Nullable | Meaning | | ---------------- | --------------------------- | -------- | ----------------------------------------------------------- | | `id` | integer | No | Primary key of the audit log record | | `sd_id` | bigint | Yes | Self Declaration identifier associated with the audit entry | | `name` | character varying | Yes | Name of the user whose data was modified | | `application_id` | character varying | Yes | Application identifier associated with the audit entry | | `entity_name` | character varying | Yes | Name of the entity or table being audited | | `updated_at` | timestamp without time zone | Yes | Timestamp when the modification occurred | | `email_id` | character varying | Yes | Email address of the user who performed the action | | `id_public` | bigint | No | Public identifier of the audit log record | | `old_data` | text | Yes | Data before the update operation | | `new_data` | text | Yes | Data after the update operation | | `action_type` | character varying | Yes | Type of action performed (UPDATE) | ## security\_audit\_trail | Field | Type | Nullable | Meaning | | ---------------- | ------------------------ | -------- | ---------------------------------------------------------------- | | `id` | bigint | No | Primary key of the security audit trail record | | `process_id` | character varying | Yes | Unique identifier of the process or transaction being audited | | `ip_address` | character varying | Yes | IP address from which the request originated | | `user_agent` | text | Yes | User agent details of the requesting client | | `http_method` | character varying | Yes | HTTP method used in the request (GET, POST, PUT, DELETE, etc.) | | `endpoint` | character varying | Yes | API endpoint accessed during the request | | `username` | character varying | Yes | Username associated with the request | | `status` | character varying | Yes | Processing status of the request | | `correlation_id` | character varying | Yes | Correlation identifier used for tracing requests across services | | `created_at` | timestamp with time zone | Yes | Timestamp when the audit record was created | | `payload` | text | Yes | Request or response payload captured for auditing purposes | | `updated_at` | timestamp with time zone | Yes | Timestamp when the audit record was last updated | | `id_public` | bigint | No | Public identifier of the security audit trail record | ## log | Field | Type | Nullable | Meaning | | -------------- | ----------------- | -------- | ---------------------------------------------------------- | | `id` | integer | No | Primary key of the log record | | `sd_id` | character varying | Yes | Self Declaration identifier associated with the log entry | | `client_id` | character varying | Yes | Client identifier associated with the log entry | | `signup_date` | character varying | Yes | Date when the user signed up | | `evl_date` | character varying | Yes | Date of evaluation or verification | | `gen_token` | text | Yes | Generated token details | | `gen_securate` | text | Yes | Generated security credentials or secure token information | | `email_send` | text | Yes | Email sending status or details | | `send_date` | character varying | Yes | Date when the email was sent | | `update_at` | character varying | Yes | Date when the log record was last updated | | `email` | character varying | Yes | Email address associated with the log entry | | `response` | text | Yes | Response received from the external system or service | | `status` | character varying | Yes | Current status of the operation | | `id_public` | bigint | No | Public identifier of the log record | ## notification\_audit | Field | Type | Nullable | Meaning | | --------------- | ------------------------ | -------- | ---------------------------------------------------------- | | `id` | bigint | No | Primary key of the notification audit record | | `request_id` | character varying | Yes | Unique request identifier associated with the notification | | `template_id` | character varying | Yes | Identifier of the notification template used | | `template_name` | character varying | Yes | Name of the notification template used | | `message` | character varying | Yes | Notification message content sent to the recipient | | `receiver` | character varying | Yes | Recipient of the notification | | `type` | character varying | Yes | Type of notification (e.g., Email, SMS, Push Notification) | | `status` | character varying | Yes | Delivery status of the notification | | `created_at` | timestamp with time zone | Yes | Timestamp when the notification record was created | | `updated_at` | timestamp with time zone | Yes | Timestamp when the notification record was last updated | | `id_public` | bigint | No | Public identifier of the notification audit record | ## concern | Field | Type | Nullable | Meaning | | -------------- | ----------------- | -------- | ------------------------------------------------------- | | `id` | integer | No | Primary key of the concern record | | `sd_id` | smallint | Yes | Self Declaration identifier associated with the concern | | `clientid` | character varying | Yes | Client identifier associated with the concern | | `concern_type` | character varying | Yes | Type or category of the concern raised | | `name` | character varying | Yes | Name of the person who raised the concern | | `messege` | character varying | Yes | Concern message or details submitted by the user | | `created` | character varying | Yes | Date and time when the concern was created | | `created_ip` | character varying | Yes | IP address from which the concern was submitted | | `id_public` | bigint | No | Public identifier of the concern record | ## std\_data | Field | Type | Nullable | Meaning | | ------------ | ----------------- | -------- | ---------------------------------------------- | | `id` | integer | No | Primary key of the STD data record | | `state_code` | character varying | Yes | Code of the state associated with the STD code | | `ldca_name` | character varying | Yes | Long Distance Charging Area (LDCA) name | | `sdca_name` | character varying | Yes | Short Distance Charging Area (SDCA) name | | `std_code` | character varying | Yes | STD telephone dialing code for the area | ## upcoming\_session | Field | Type | Nullable | Meaning | | -------------- | --------------------------- | -------- | ------------------------------------------------- | | `start_time` | character varying | Yes | Scheduled start time of the session | | `end_time` | character varying | Yes | Scheduled end time of the session | | `session_name` | character varying | Yes | Name or title of the upcoming session | | `link` | character varying | Yes | Meeting or session joining link | | `created_at` | character varying | Yes | Date and time when the session record was created | | `id` | integer | No | Primary key of the upcoming session record | | `date` | timestamp without time zone | Yes | Scheduled date of the session | ## awsdms\_apply\_exceptions Infrastructure, not portal data. | Field | Type | Nullable | Meaning | | ------------- | --------------------------- | -------- | ---------------------------------------------- | | `TASK_NAME` | character varying | No | AWS DMS task name that generated the exception | | `TABLE_OWNER` | character varying | No | Schema owner of the table | | `TABLE_NAME` | character varying | No | Name of the table where the exception occurred | | `ERROR_TIME` | timestamp without time zone | No | Timestamp when the exception was recorded | | `STATEMENT` | text | No | SQL statement that caused the exception | | `ERROR` | text | No | Error message returned by AWS DMS | ## Backup copies Three tables are named as backups of `sd_login`. A fourth, `sd_exit_live`, carries the same column list as `sd_exit`, and the source does not say which of that pair the portal writes to. All four repeat a column list above, so they are summarised rather than listed in full. | Table | Mirrors | Columns | Difference from the table it mirrors | | --------------------------- | ---------- | ------- | --------------------------------------------------------------------------------- | | `sd_login_bk` | `sd_login` | 50 | Same column list, except it does not have `payer_category`, `dhis_solution_type`. | | `sd_login_bk_16062026` | `sd_login` | 52 | Same column list. | | `sd_login_bk_20012026_updt` | `sd_login` | 50 | Same column list, except it does not have `payer_category`, `dhis_solution_type`. | | `sd_exit_live` | `sd_exit` | 68 | Same column list. | The three `sd_login` copies are owned by `sandboxportaluser`, every other table in the schema by `appprdusrsandbox`. The digits in `sd_login_bk_16062026` and `sd_login_bk_20012026_updt` read as dates, and the source does not say what they mark. ## Indexes Every index, with the columns it covers. | Table | Index | Unique | On | | ------------------------------ | ------------------------------------ | ------ | ------------------------------------------------------------------------------------------------------------------------------ | | `active_integrator` | `active_integrator_pkey` | Yes | `id_public` | | `address` | `address_pkey` | Yes | `id` | | `address` | `address_sd_id_uk` | Yes | `sd_id` | | `audit_log` | `audit_log_pkey` | Yes | `id_public` | | `ci_sessions` | `ci_sessions_pkey` | Yes | `id` | | `ci_sessions` | `idx_ci_sessions_data` | No | `data` | | `ci_sessions` | `idx_ci_sessions_ip` | No | `ip_address` | | `ci_sessions` | `idx_ci_sessions_timestamp` | No | `timestamp` | | `concern` | `concern_pkey` | Yes | `id_public` | | `hcx` | `hcx_pkey` | Yes | `id_public` | | `hcx_address` | `hcx_address_pkey` | Yes | `id_public` | | `log` | `log_pkey` | Yes | `id_public` | | `mst_modules` | `mst_modules_pkey` | Yes | `module_id` | | `mst_privilege` | `mst_privilege_pkey` | Yes | `id_public` | | `mst_role` | `idx_role_name_sandbox` | No | `role_name` | | `mst_role` | `mst_role_pkey` | Yes | `role_id` | | `notification_audit` | `notification_audit_pkey` | Yes | `id_public` | | `password` | `password_pkey` | Yes | `id_public` | | `sd_doc_type` | `sd_doc_type_pkey` | Yes | `id` | | `sd_exit` | `idx_sd_exit_final_status` | No | `final_status` | | `sd_exit` | `idx_sd_exit_sd_id` | No | `sd_id` | | `sd_exit` | `sd_exit_pkey1` | Yes | `id` | | `sd_exit_docs` | `idx_sd_exit_docs_exit_id` | No | `exit_id` | | `sd_exit_docs` | `idx_sd_exit_docs_id` | No | `id` | | `sd_exit_docs` | `idx_sd_exit_docs_sd_id` | No | `sd_id` | | `sd_exit_docs` | `sd_exit_docs_pkey` | Yes | `id` | | `sd_exit_live` | `sd_exit_pkey` | Yes | `id` | | `sd_hiu` | `sd_hiu_pkey` | Yes | `id` | | `sd_login` | `idx_sd_login_created_at` | No | `created_at_old` | | `sd_login` | `idx_sd_login_email` | No | `email` | | `sd_login` | `idx_sd_login_role_id` | No | `role_id` | | `sd_login` | `idx_sd_login_sd_id` | No | `sd_id` | | `sd_login` | `idx_sd_login_updated_at` | No | `updated_at` | | `sd_login` | `sd_login_pkey` | Yes | `sd_id` | | `sd_login` | `sd_login_type_of_application_idx` | No | `type_of_application` | | `sd_status` | `idx_sd_status_sd_id` | No | `sd_id` | | `sd_status` | `sd_status_pkey` | Yes | `id` | | `sd_uhi` | `sd_uhi_pkey` | Yes | `id_public` | | `security_audit_trail` | `security_audit_trail_pkey` | Yes | `id_public` | | `self_declaration` | `self_declaration_m1_start_date_idx` | No | `m1_start_date`, `m1_end_date`, `m2_start_date`, `m2_end_date`, `m3_start_date`, `m3_end_date`, `m4_start_date`, `m4_end_date` | | `self_declaration` | `self_declaration_pkey` | Yes | `id` | | `self_declaration` | `self_declaration_sd_id_idx` | No | `sd_id` | | `std_data` | `std_data_pkey` | Yes | `id` | | `upcoming_session` | `upcoming_session_pkey` | Yes | `id` | | `wasa_dhis_initiation_details` | `wasa_dhis_initiation_details_pkey` | Yes | `id` | Every index in the source is a btree. ## What is not transcribed Two sheets are left out, and neither carries anything you act on. - **Sequences**, 34 Postgres sequences, one per auto incrementing key, with start value, minimum, maximum and increment. Every one increments by 1 and does not cycle. - **Def values**, 104 column defaults, of two kinds: `nextval('<sequence>'::regclass)` on identifier columns and `NULL::character varying` on text columns. Both are in the sandbox document pack, data dictionary v1.0. ## What this page does not tell you This dictionary describes the sandbox portal, not the [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) APIs. It carries no request shape, no response shape and no endpoint. Registry identifiers such as [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) numbers do not appear in it at all. For the APIs, start at [choose your gateway](/docs/hiecm/v3). For the sandbox itself and how to sign up, read [get started](/docs/hiecm/v3/getting-started/sandbox). --- # Error codes Seeing a symptom rather than a code? Start at [Troubleshooting](/docs/hiecm/v3/troubleshooting/). Generated from the specifications. A code is on this page because a specification records it. ## Gateway session Code, message and error name are as published. The action column reads the message text by a documented rule, and says Unclassified where the rule could not classify one. | Code | Message | What to do | | ----------- | ----------------------------------------------------------------------------------------------------------------------- | -------------- | | `ABDM-1053` | Problem occurred while loading overlay image | Unclassified | | `ABDM-1068` | Both Patient and Error details cannot be null | Fix request | | `ABDM-1069` | Invalid Authentication type | Fix request | | `ABDM-1073` | if is applicable for all HIP's is true;then HIP object must be null | Unclassified | | `ABDM-1076` | One or more invalid HIP is exist in the request | Fix request | | `ABDM-1088` | Captcha verification failed, Please enter valid code. | Unclassified | | `ABDM-1089` | Payment information cannot be null | Fix request | | `ABDM-1096` | Duplicate Gateway Consent Manager request | Cannot proceed | | `ABDM-1097` | Duplicate Gateway Consent Manager patch request | Cannot proceed | | `ABDM-1098` | Duplicate Gateway Government Program request | Fix request | | `ABDM-1123` | User authentication failed | Unclassified | | `ABDM-1125` | ABHA number and ABHA address cannot be null | Fix request | | `ABDM-1128` | T-Token Expired | Fix request | | `ABDM-1129` | Invalid T-Token | Fix request | | `ABDM-1130` | Invalid X-Token | Fix request | | `ABDM-1131` | X-Token Expired | Fix request | | `ABDM-1208` | Abha Profile Gateway is unavailable | Retry | | `ABDM-1209` | PHR DB service unavailable | Retry | | `ABDM-1210` | Login via Email Address OTP is not allowed | Fix request | | `ABDM-1212` | Email address not found. | Fix request | | `ABDM-1213` | User not active. | Unclassified | | `ABDM-1214` | Mobile/Email verification is pending. | Unclassified | | `ABDM-1215` | Login via Mobile Number OTP is not allowed | Fix request | | `ABDM-1216` | The ABHA Address is deactivated. | Cannot proceed | | `ABDM-1217` | Login is not allowed | Fix request | | `ABDM-1221` | Face verification has been failed, please try again. | Retry | | `ABDM-1222` | Fingerprint verification has been failed, please try again. | Retry | | `ABDM-1223` | IRIS verification has been failed, please try again. | Retry | | `ABDM-1300` | Provided emailId doesn't match with existing emailId | Unclassified | | `ABDM-1301` | The mobile number you have entered has already been verified. Please provide an alternate mobile number. | Fix request | | `ABDM-1302` | The emailId you have entered has already been verified. Please provide an alternate emailId. | Fix request | | `ABDM-1303` | Your mobile number is not linked to the ABHA number. Please update your mobile number in ABHA or try using Aadhaar OTP. | Unclassified | | `ABDM-1304` | Mobile number is not linked to your ABHA address. Please update your mobile number in ABHA. | Unclassified | | `ABDM-1305` | Mobile number is missing for this ABHA address. Please update your mobile number. | Fix request | | `ABDM-1308` | This account is deactivated. Please reactivate it from ABHA portal. | Cannot proceed | | `ABDM-1506` | Invalid callback resp id | Fix request | | `ABDM-1919` | Invalid Refresh token | Fix request | | `ABDM-1920` | Invalid grant type | Fix request | | `ABDM-1921` | Invalid client id | Fix request | | `ABDM-1922` | Invalid client secret | Fix request | | `ABDM-1923` | Invalid client id and secret | Fix request | | `ABDM-1931` | Service-Id= (.\*?) is already exists | Fix request | | `ABDM-1932` | HFR request failed, rollback successful for hfr-id= (\S+)\s\* | Unclassified | | `ABDM-1933` | Bridge registry request is invalid | Fix request | | `ABDM-1935` | All the provided service IDs do not match with the client ID | Unclassified | | `ABDM-9008` | No CR Mapped with Abha Address | Unclassified | ## M1 ABHA identity Code, message and error name are as published. The action column reads the message text by a documented rule, and says Unclassified where the rule could not classify one. | Code | Message | What to do | | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | `ABDM-1001` | Subscription source update returned empty | Unclassified | | `ABDM-1002` | Invalid frequency unit, it must be in HOUR, WEEK, DAY, MONTH, YEAR | Fix request | | `ABDM-1006` | Invalid HIType, it must be in Prescription,DiagnosticReport,OPConsultation,DischargeSummary,ImmunizationRecord,HealthDocumentRecord,WellnessRecord,Invoice | Fix request | | `ABDM-1008` | SMS service currently disabled | Unclassified | | `ABDM-1009` | Email service currently disabled | Unclassified | | `ABDM-1010` | No pending care context found for this abha address | Unclassified | | `ABDM-1013` | Invalid ABHA Number | Fix request | | `ABDM-1016` | Invalid Timestamp | Fix request | | `ABDM-1017` | Invalid Transaction Id | Fix request | | `ABDM-1019` | Dependent Service Unavailable | Retry | | `ABDM-1021` | Lack of required priviledges | Fix request | | `ABDM-1022` | Too many requests | Retry | | `ABDM-1029` | Redis server is unavailable | Retry | | `ABDM-1030` | Request id not found | Fix request | | `ABDM-1034` | Notification service unavailable | Retry | | `ABDM-1045` | Database Access is restricted | Unclassified | | `ABDM-1047` | Purpose does not exist | Fix request | | `ABDM-1048` | Timeout | Retry | | `ABDM-1065` | Health facility does not exist | Fix request | | `ABDM-1066` | Please enter a valid Password | Unclassified | | `ABDM-1094` | Access to this feature is restricted. Please contact NHA to enable it. | Fix auth | | `ABDM-1094` | Invalid Benefit Name | Fix auth | | `ABDM-1100` | You have requested multiple OTPs Or Exceeded maximum number of attempts for OTP match in this transaction. Please try again in 30 minutes. | Retry | | `ABDM-1101` | This ABHA Address already exists. Please create with unique ABHA address | Fix request | | `ABDM-1102` | Mobile number verification is pending. | Unclassified | | `ABDM-1103` | Cannot link with CHILD ABHA Number | Unclassified | | `ABDM-1104` | Cannot link with same ABHA Number | Unclassified | | `ABDM-1105` | Invalid request for parent linking | Fix request | | `ABDM-1107` | Invalid combinations of scopes | Fix request | | `ABDM-1108` | Notification DB service unavailable | Retry | | `ABDM-1109` | Invalid On discovery response | Fix request | | `ABDM-1110` | Your new password must be different from your old password. Please enter a unique new password. | Unclassified | | `ABDM-1111` | Invalid old password, please try with valid password. | Fix request | | `ABDM-1112` | The provided gender does not match the gender in DigiLocker records | Unclassified | | `ABDM-1113` | Duplicate health information provider data flow response data flow resoponse | Fix request | | `ABDM-1114` | The provided name does not match the name in DigiLocker records | Unclassified | | `ABDM-1115` | Invalid patient information. At least one patient information is required. | Fix request | | `ABDM-1116` | generate\_and\_save\_link\_token : 'NoneType' object has no attribute 'get' | Unclassified | | `ABDM-1117` | Auto approval id is already active | Fix request | | `ABDM-1118` | Login via ABHA Number OTP is not allowed | Fix request | | `ABDM-1119` | Login via Aadhaar OTP is not allowed | Fix request | | `ABDM-1121` | Invalid Enrolment Number | Fix request | | `ABDM-1122` | Request can not be processed | Unclassified | | `ABDM-1124` | The mobile number provided by you is already linked to 6 ABHA Numbers. Please provide a different Mobile Number. | Fix request | | `ABDM-1126` | F-Token Expired | Fix request | | `ABDM-1127` | Invalid F-Token | Fix request | | `ABDM-1132` | Kindly enter valid linked ABHA Address | Unclassified | | `ABDM-1133` | Please enter a valid captcha result. Entered captcha result is incorrect. | Fix request | | `ABDM-1134` | Deactivated ABHA Account | Cannot proceed | | `ABDM-1135` | The email address provided by you is already linked to 6 ABHA Numbers. Please provide a different email Id. | Fix request | | `ABDM-1136` | message should not be null or empty. | Unclassified | | `ABDM-1137` | Benefit Name Not Found | Fix request | | `ABDM-1138` | The benefit record has already been de-linked | Treat as success | | `ABDM-1139` | Benefit record not found | Fix request | | `ABDM-1140` | The benefit record has already been linked | Treat as success | | `ABDM-1141` | An existing ABHA number created using this Aadhaar number has been found. It is advisable to delete this account and use ABHA number ((\[0-9]{2}(?:-\[0-9]{4}){3})) for future purpose. | Unclassified | | `ABDM-1142` | Please enter a valid captcha. Entered captcha is expired. | Fix request | | `ABDM-1143` | Captcha limit exceeded. | Unclassified | | `ABDM-1144` | Incorrect facility ID or password. | Fix request | | `ABDM-1155` | Parents must be 18 years of age or older to create a Child ABHA Account | Unclassified | | `ABDM-1156` | Please ensure that the mobile number is mapped to the parent's ABHA number | Unclassified | | `ABDM-1157` | Child ABHA’s account limit has been exceeded for the requested Abha ID number ‘(.\*?) | Unclassified | | `ABDM-1158` | Invalid X-Token | Fix request | | `ABDM-1159` | Children’s ages should be below '(.\*?)' years as of the current date | Unclassified | | `ABDM-1160` | Non KYC CHILD ABHA is allowed to update their profile only once | Unclassified | | `ABDM-1200` | LGD Gateway is unavailable | Retry | | `ABDM-1201` | IDP Gateway is unavailable | Retry | | `ABDM-1202` | Document Gateway is unavailable | Retry | | `ABDM-1203` | TEST | Unclassified | | `ABDM-1204` | A UIDAI failure passed through. The UIDAI code and text sit inside the message string | Fix request | | `ABDM-1205` | Document DB Gateway is unavailable | Retry | | `ABDM-1206` | Aadhaar Gateway is unavailable | Retry | | `ABDM-1207` | The information you provided does not match the details on record with Aadhaar. Please verify and provide accurate information. | Fix request | | `ABDM-1211` | Email Sending Limit Exceeded | Unclassified | | `ABDM-1218` | Role for the user does not exist. | Fix request | | `ABDM-1219` | Your ABHA is linked with govt benefit programme, so it can not be deleted- ABDM, National Health Authority. | Unclassified | | `ABDM-1220` | Sorry, Unable to process your request at this time. Please try again later. | Retry | | `ABDM-1224` | Login via Biometric is not allowed. | Fix auth | | `ABDM-1226` | Vault service unavailable | Retry | | `ABDM-1227` | This client ID has reached the maximum limit of 100 ABHA account creations. | Unclassified | | `ABDM-1228` | Your ABHA is linked with govt benefit programme, so it can not be deactivated- ABDM, National Health Authority. | Cannot proceed | | `ABDM-9999` | Recorded as `ABDM-9999: `with an `ABDM-1094` message stuck to the front of the text | Fix auth | ## M1 ABHA identity, Untagged The same collection, and the only source that recorded HTTP statuses. | Code | HTTP | Message | What to do | | -------- | ---- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | `900901` | 401 | Invalid Credentials, invalid JWT token. From the API gateway in front of the ABHA service, before your request reaches the business logic | Fix auth | | `900900` | 500 | Unclassified authentication failure. The one saved example had a bad path and a bad token together, so read it as a client error first | Fix auth | | `404` | 404 | No matching resource found for given API Request\`. A wrong path, not a missing record | Fix request | ## M1 ABHA identity, UIDAI Codes from the Unique Identification Authority of India, passed through inside the message of ABDM-1204. More codes pass through than are listed here, so parse the message. | Code | Message | What to do | | ----- | ---------------------- | ---------- | | `300` | Biometric mismatch | | | `561` | Request expired | | | `563` | Duplicate request | | | `810` | Missing biometric data | | ## M2 Linking and sharing Code, message and error name are as published. The action column reads the message text by a documented rule, and says Unclassified rather than guessing. | Code | Message | What to do | | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | `ABDM-1000` | Unable to connect the database | Retry | | `ABDM-1001` | No data found | Fix request | | `ABDM-1004` | SMS Gateway is unavailable | Retry | | `ABDM-1006` | Invalid HIType, it must be in Prescription,DiagnosticReport,OPConsultation,DischargeSummary,ImmunizationRecord,HealthDocumentRecord,WellnessRecord,Invoice | Fix request | | `ABDM-1006` | Bad Request, invalid request Body | Fix request | | `ABDM-1006` | Invalid combinations of scopes | Fix request | | `ABDM-1006` | Invalid count, must be 2 digit and ranges between 1 to 20 | Fix request | | `ABDM-1007` | Connection failed due to timeout | Retry | | `ABDM-1008` | SMS service currently disabled | Retry | | `ABDM-1010` | Validation failed | Fix request | | `ABDM-1011` | Gateway database unavailable | Retry | | `ABDM-1012` | No records found against the ABHA Address | Fix request | | `ABDM-1013` | Invalid ABHA Number | Fix request | | `ABDM-1015` | Invalid Response | Fix request | | `ABDM-1016` | Invalid TimeStamp | Fix request | | `ABDM-1017` | Invalid TransactionId | Fix request | | `ABDM-1018` | Share Profile database unavailable | Retry | | `ABDM-1019` | Dependent Service Unavailable | Retry | | `ABDM-1020` | Unknown database | Retry | | `ABDM-1022` | Too many requests | Back off | | `ABDM-1023` | Invalid User | Fix request | | `ABDM-1024` | Dependent service unavailable | Retry | | `ABDM-1025` | Invalid ServiceId | Fix request | | `ABDM-1026` | Invalid Link Token | Fix auth | | `ABDM-1027` | You are blocked. Please try again after 24 hours. | Blocked, no retry | | `ABDM-1028` | HIP is unavailable | Chase the [HIP](/docs/hiecm/v3/getting-started/glossary#hip) | | `ABDM-1029` | Redis server is unavailable | Retry | | `ABDM-1030` | Invalid request ID | Fix request | | `ABDM-1030` | Request id not found | Fix request | | `ABDM-1031` | Invalid request | Fix request | | `ABDM-1032` | Invalid header | Fix request | | `ABDM-1033` | HIU is unavailable | Chase the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) | | `ABDM-1034` | Notification service unavailable | Retry | | `ABDM-1035` | Invalid HIP ID | Fix request | | `ABDM-1036` | Data does not matched | Fix request | | `ABDM-1037` | Counter and Care context count mismatch | Fix request | | `ABDM-1038` | ABHA address and Link token mismatch | Fix auth | | `ABDM-1040` | Invalid HIU ID | Fix request | | `ABDM-1041` | Invalid Acknowledgement | Fix request | | `ABDM-1042` | Provider Mandatory | Fix request | | `ABDM-1043` | ABHA Address does not match with KYC details. | Fix request | | `ABDM-1044` | Broadcast Failed | Retry | | `ABDM-1045` | Database Access is restricted | Retry | | `ABDM-1046` | Invalid Purpose | New consent | | `ABDM-1047` | Purpose does not exist | New consent | | `ABDM-1048` | Timeout | Retry | | `ABDM-1049` | Invalid Profile Share Intent Keys | Ask support | | `ABDM-1050` | Invalid Profile Share Metadata Keys | Ask support | | `ABDM-1051` | Invalid ABHA Number or ABHA Address | Fix request | | `ABDM-1052` | Invalid TransactionId or response's requestId | Fix request | | `ABDM-1055` | Invalid HIP Id or PHR Id | Fix request | | `ABDM-1056` | This care contexts has been already linked | Treat as success | | `ABDM-1056` | Invalid Link Reference Number | Fix request | | `ABDM-1057` | Invalid Care Contexts | Fix request | | `ABDM-1059` | Invalid Care Contexts count | Fix request | | `ABDM-1060` | Invalid Patient Reference Number | Fix request | | `ABDM-1061` | Invalid Patient Display | Fix request | | `ABDM-1061` | Consent artefact expired | New consent | | `ABDM-1062` | ABHA number mismatch with Link token | Fix auth | | `ABDM-1062` | Consent Not granted | New consent | | `ABDM-1063` | HIP Id mismatch with Link token | Fix auth | | `ABDM-1063` | Date Range given is invalid | New consent | | `ABDM-1064` | request with this request id already exists | New request id | | `ABDM-1064` | Request body was missing | Fix request | | `ABDM-1065` | Invalid X Auth token | Fix auth | | `ABDM-1066` | Invalid JWT token | Fix auth | | `ABDM-1067` | Request body not required | Fix request | | `ABDM-1084` | ABHA address mismatch with X Auth token | Fix auth | | `ABDM-1085` | ABHA number mismatch with X Auth token | Fix auth | | `ABDM-1086` | Patient profile mismatch with X Auth token | Fix auth | | `ABDM-1087` | Duplicate patient share request | New request id | | `ABDM-1090` | Duplicate HIP link request | New request id | | `ABDM-1091` | Duplicate Get links request | New request id | | `ABDM-1092` | Duplicate Link token request | New request id | | `ABDM-1093` | Duplicate Bridge request | New request id | | `ABDM-1094` | Duplicate bridge patch request | New request id | | `ABDM-1095` | Duplicate Bridge service request | New request id | | `ABDM-1102` | Profile information cannot be null | Ask support | | `ABDM-1103` | Duplicate Discovery request | New request id | | `ABDM-1104` | Duplicate Init request | New request id | | `ABDM-1105` | Duplicate Confirm request | New request id | | `ABDM-1106` | Duplicate On discovery request | New request id | | `ABDM-1107` | Duplicate On init request | New request id | | `ABDM-1108` | Duplicate On confirm request | New request id | | `ABDM-1108` | Notification DB service unavailable | Retry | | `ABDM-1109` | Invalid On discovery response | Fix request | | `ABDM-1109` | ABHA DB service unavailable | Retry | | `ABDM-1110` | Invalid On init response | Fix request | | `ABDM-1111` | Invalid On confirm response | Fix request | | `ABDM-1112` | Invalid or already expired consent artefact id | New consent | | `ABDM-1113` | Duplicate health information provider data flow response | New request id | | `ABDM-1149` | Intent type is not supported at HIP end | Fix request | | `ABDM-1150` | Bridge API version cannot be null | Ask support | | `ABDM-1170` | Invalid ABHA address | Fix request | | `ABDM-1201` | IDP Gateway is unavailable | Retry | | `ABDM-1401` | HIP is not available | Chase the HIP | | `ABDM-1402` | Acknowledgement is not received from HIP | Chase the HIP | | `ABDM-1407` | The ABHA Number associated with this ABHA Address is currently deactivated. Please reactivate it. | Fix request | | `ABDM-2401` | The X Auth token is invalid. | Fix auth | | `ABDM-2402` | Invalid Timestamp | Fix request | | `ABDM-2403` | Invalid X-CM-ID | Fix request | | `ABDM-2404` | Invalid Request Id | Fix request | | `ABDM-2406` | Invalid API sequence flow, please follow logical flow | Fix request | | `ABDM-2406` | The status is invalid. Please follow the logical status flow or transition. | Fix request | | `ABDM-2429` | Too many requests found | Back off | | `ABDM-2500` | Authorization header is missing | Fix auth | | `ABDM-2500` | No mapping found for | Fix request | | `ABDM-2501` | Payment status should be : \`SUCCESS,CANCELED,PENDING,FAIL,REFUND\_INITIATED,REFUND\_SUCCESS | Ask support | | `ABDM-9001` | No open order against ABHA. Please ensure a minimum of one open order | Ask support | | `ABDM-9002` | No registration found at `<<hospital name>>`. Contact counter support | Ask support | | `ABDM-9003` | Hospital services temporarily unavailable. Please try again after some time. | Retry | | `ABDM-9004` | Services disrupted, please try again. | Retry | | `ABDM-9005` | Bank server not responding. Please try again later | Ask support | | `ABDM-9006` | Service details mismatch. Please ensure original service ID from HMIS | Ask support | | `ABDM-9007` | The Scan and Pay functionality is not enabled at this facility. Kindly contact the hospital administration. | Ask support | | `ABDM-9999` | HIP is unable to generate a token at this time. Please try again later. | Chase the HIP | | `ABDM-9999` | HIP is unable to process at this time. Please try again later. | Chase the HIP | | `ABDM-9999` | Unknown exception | Retry | | `ABDM-9999` | Cannot process the request at the moment, please try later. | Retry | | `ABDM-9999` | User not found | Retry | ## M3 Consent and fetching Code, message and error name are as published. The action column reads the message text by a documented rule, and says Unclassified where the rule could not classify one. | Code | Message | What to do | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | | `ABDM-1000` | Unable to connect the database | Retry | | `ABDM-1001` | Subscription source update returned empty | Unclassified | | `ABDM-1002` | Invalid frequency unit, it must be in HOUR, WEEK, DAY, MONTH, YEAR | Fix request | | `ABDM-1003` | Email Gateway is unavailable | Retry | | `ABDM-1004` | SMS Gateway is unavailable | Retry | | `ABDM-1005` | Invalid receiver | Fix request | | `ABDM-1006` | Invalid HIType, it must be in Prescription,DiagnosticReport,OPConsultation,DischargeSummary,ImmunizationRecord,HealthDocumentRecord,WellnessRecord,Invoice | Fix request | | `ABDM-1007` | Connection failed due to timeout | Retry | | `ABDM-1008` | SMS service currently disabled | Unclassified | | `ABDM-1009` | Email service currently disabled | Unclassified | | `ABDM-1010` | No pending care context found for this abha address | Unclassified | | `ABDM-1011` | Gateway database unavailable | Retry | | `ABDM-1012` | No records found against the ABHA Address | Unclassified | | `ABDM-1013` | Invalid ABHA Number | Fix request | | `ABDM-1014` | Invalid Mobile Email | Fix request | | `ABDM-1015` | Invalid Response | Fix request | | `ABDM-1016` | Invalid Timestamp | Fix request | | `ABDM-1017` | Invalid Transaction Id | Fix request | | `ABDM-1018` | Share Profile database unavailable | Retry | | `ABDM-1019` | Dependent Service Unavailable | Retry | | `ABDM-1020` | Unknown database | Unclassified | | `ABDM-1021` | Lack of required priviledges | Fix request | | `ABDM-1022` | Too many requests | Retry | | `ABDM-1023` | Invalid User | Fix request | | `ABDM-1024` | Dependent service unavailable | Retry | | `ABDM-1025` | Invalid ServiceId | Fix request | | `ABDM-1026` | Bridge Id not found | Fix request | | `ABDM-1027` | You are blocked. Please try again after 24 hours. | Cannot proceed | | `ABDM-1028` | HIP is unavailable | Retry | | `ABDM-1029` | Redis server is unavailable | Retry | | `ABDM-1030` | Request id not found | Fix request | | `ABDM-1031` | Invalid reason. Reason should not be null or empty and should contains only alphabets, dot(.) and comma(,) | Fix request | | `ABDM-1032` | Invalid header | Fix request | | `ABDM-1033` | HIU is unavailable | Retry | | `ABDM-1034` | Notification service unavailable | Retry | | `ABDM-1035` | OTP does not matched | Unclassified | | `ABDM-1039` | Invalid Consent request id | Cannot proceed | | `ABDM-1040` | Invalid Locker ID | Fix request | | `ABDM-1041` | Invalid Acknowledgement | Fix request | | `ABDM-1046` | Invalid Purpose | Fix request | | `ABDM-1047` | Purpose does not exist | Fix request | | `ABDM-1048` | Timeout | Retry | | `ABDM-1051` | Invalid ABHA Number or ABHA Address | Fix request | | `ABDM-1054` | Invalid Subscription Request Id | Fix request | | `ABDM-1057` | Invalid Care Contexts | Fix request | | `ABDM-1058` | Invalid HI Types | Fix request | | `ABDM-1060` | Invalid Patient Reference Number | Fix request | | `ABDM-1061` | Consent artefact expired | Cannot proceed | | `ABDM-1062` | ABHA number mismatch with Link token), | Fix request | | `ABDM-1063` | HIP Id mismatch with Link token | Fix request | | `ABDM-1064` | request with this request id already exists | Fix request | | `ABDM-1065` | Health facility does not exist | Fix request | | `ABDM-1070` | Duplicate consent request | Cannot proceed | | `ABDM-1071` | User doesn't belongs to same organisation | Unclassified | | `ABDM-1072` | Included source size must be at least 1 | Unclassified | | `ABDM-1074` | HIP object cannot be null in excluded sources | Fix request | | `ABDM-1075` | HIP object cannot be null in included sources | Fix request | | `ABDM-1077` | Auto approval policy id doesn't exist. | Unclassified | | `ABDM-1078` | Failed to upload documents | Unclassified | | `ABDM-1079` | Auto approval id is already disabled | Fix request | | `ABDM-1080` | Subscription request may be already approved or denied | Fix request | | `ABDM-1081` | Please upload registration certificate of your organisation | Unclassified | | `ABDM-1082` | Please upload authority letter from your organisation | Unclassified | | `ABDM-1083` | User doesn't belongs to same organisation | Unclassified | | `ABDM-1084` | The Details fetched from Aadhaar is not matching with our database. Please select the correct details to proceed | Unclassified | | `ABDM-1085` | ABHA number mismatch with X Auth token | Fix request | | `ABDM-1099` | Invalid event Id, it cannot be null | Fix request | | `ABDM-1100` | You have requested multiple OTPs Or Exceeded maximum number of attempts for OTP match in this transaction. Please try again in 30 minutes. | Retry | | `ABDM-1112` | The provided gender does not match the gender in DigiLocker records | Unclassified | | `ABDM-1113` | Duplicate health information provider data flow response data flow resoponse | Fix request | | `ABDM-1116` | generate\_and\_save\_link\_token : 'NoneType' object has no attribute 'get' | Unclassified | | `ABDM-1117` | Auto approval id is already active | Fix request | | `ABDM-1118` | Login via ABHA Number OTP is not allowed | Fix request | | `ABDM-1119` | Login via Aadhaar OTP is not allowed | Fix request | | `ABDM-1120` | No care context is available for this patient. | Unclassified | | `ABDM-1144` | Incorrect facility ID or password. | Fix request | | `ABDM-1145` | Subscription is already disabled | Fix request | | `ABDM-1146` | Subscription is not in revoked state | Unclassified | | `ABDM-1147` | Subscription is not in granted state | Unclassified | | `ABDM-1148` | Subscription id does not belong to the patient | Unclassified | | `ABDM-1151` | Health locker is already setup for the user | Fix request | | `ABDM-1152` | Subscription not found for the locker | Fix request | | `ABDM-1153` | Unable to create Consent Auto Approval for the health locker | Cannot proceed | | `ABDM-1154` | Unable to save user health locker | Unclassified | | `ABDM-1170` | Invalid ABHA address | Fix request | | `ABDM-1401` | Your mobile number is not linked to the ABHA number. Please update your mobile number in ABHA or try to register using Aadhaar OTP | Unclassified | | `ABDM-1402` | Transaction Id is not matching with response | Unclassified | | `ABDM-1403` | As per NHA policy, you have exceeded ABHA address creation limit, please link your ABHA address to ABHA number. | Unclassified | | `ABDM-1404` | Patient record share detail not found | Fix request | | `ABDM-1405` | Invalid health information status | Fix request | | `ABDM-1406` | Invalid session status, Status should be TRANSFERRED, PARTIAL\_TRANSFERRED or FAILED | Fix request | | `ABDM-1407` | The ABHA Number associated with this ABHA Address is currently deactivated. Please reactivate it. | Cannot proceed | | `ABDM-1408` | Invalid API sequence flow, please follow logical flow | Fix request | | `ABDM-8877` | HIP did not acknowledge the HIP consent notify. Please try again after some time | Cannot proceed | | `ABDM-9999` | Invalid purpose text, it must be in Care Management, Break the Glass, Public Health, Healthcare Payment, Disease Specific Healthcare Research, Self Requested | Fix request | ## M4 HPR and HFR The ranges below, with examples. The full list is in the sandbox documentation for the healthcare professional registry. Code, message and error name are as published. The action column reads the message text by a documented rule, and says Unclassified where the rule could not classify one. | Range | What it covers | Examples | | -------------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | `HIS-400 to HIS-504` | The HTTP level failures | HIS-401 user is not authorized, HIS-403 forbidden, HIS-503 requested service is unavailable | | `HIS-1xxx` | Validation and facility errors, 103 of them | HIS-1002 the field value should not be empty, HIS-1124 bridge not linked, HIS-1128 HIP name already exists, HIS-1132 duplicate facility detected | | `HIS-2xxx` | Aadhaar, OTP and session errors | HIS-2022 invalid OTP, HIS-2031 request expired, HIS-2045 session expired | | `HIS-3xxx` | Aadhaar data and HPID state | HIS-3001 resident data not available, HIS-3021 HPRID already exists, HIS-3031 invalid token | | `HIS-4xxx` | Facility record errors | HIS-4003 facility already exists, HIS-4032 invalid state code, HIS-4055 invalid image format | | `HIS-5xxx` | Registration workflow errors | HIS-5005 already registered, HIS-5011 token expired | ## M4 HPR and HFR The ranges below, with examples. The full list is in the sandbox documentation for the healthcare professional registry. Code, message and error name are as published. The action column reads the message text by a documented rule, and says Unclassified where the rule could not classify one. | Code | Message | What to do | | ---------- | ----------------------------------------------------------------------- | -------------- | | `HIS-400` | Request is invalid. Please enter the correct data. | Fix request | | `HIS-401` | User is not authorized. | Cannot proceed | | `HIS-403` | Forbidden. | Cannot proceed | | `HIS-422` | Unable to process the current request due to wrong data. | Unclassified | | `HIS-500` | An unexpected error has occurred. Please try again in some time {0}{1}. | Retry | | `HIS-503` | Requested service is unavailable. | Retry | | `HIS-504` | Database exception occurred while processing request. | Unclassified | | `HIS-1001` | Doctor info not found for healthProfessionalId: (.\*) | Fix request | | `HIS-1002` | The field value should not be empty. | Unclassified | | `HIS-1003` | Invalid pattern found. | Fix request | | `HIS-1004` | Type mismatched. Please send the correct type. | Fix request | | `HIS-1005` | Please try logging in with the correct details. | Unclassified | | `HIS-1006` | Authentication is not initiated with provided method. | Unclassified | | `HIS-1007` | The user is disabled. | Unclassified | | `HIS-1008` | Invalid HPID/USERID. | Fix request | | `HIS-1009` | Error while connecting to UIDAI service. | Unclassified | | `HIS-1010` | Password must follow required format. | Fix request | | `HIS-1011` | Please enter valid mobile number. | Unclassified | | `HIS-1012` | Please enter valid Aadhaar number. | Unclassified | | `HIS-1013` | Incorrect OTP entered. | Fix request | | `HIS-1014` | Field contains only alphabets. | Unclassified | | `HIS-1015` | HPID already exists. | Fix request | | `HIS-1016` | HPID not available. | Unclassified | | `HIS-1018` | HPID creation allowed only for specific regions. | Unclassified | | `HIS-1019` | HP Facility ID not available. | Unclassified | | `HIS-1020` | Facility already registered with HPID. | Fix request | | `HIS-1021` | Current and new password cannot be same. | Unclassified | | `HIS-1022` | Please verify captcha. | Unclassified | | `HIS-1023` | Please wait before sending another OTP. | Unclassified | | `HIS-1024` | Invalid state. | Fix request | | `HIS-1025` | Invalid district. | Fix request | | `HIS-1026` | Transaction not found. | Fix request | | `HIS-1027` | Benefit not integrated. | Unclassified | | `HIS-1028` | Aadhaar required for KYC. | Fix request | | `HIS-1029` | HPID already linked with Aadhaar. | Fix request | | `HIS-1030` | Name mismatch with Aadhaar records. | Fix request | | `HIS-1031` | Password not set for HPID. | Unclassified | | `HIS-1032` | Integrated program not found. | Fix request | | `HIS-1033` | Authentication failed. | Unclassified | | `HIS-1034` | Invalid date format. | Fix request | | `HIS-1035` | Invalid Healthcare Professional ID. | Fix request | | `HIS-1036` | ID type and domain not configured. | Unclassified | | `HIS-1039` | Max login attempts exceeded. | Unclassified | | `HIS-1040` | File size exceeds limit. | Unclassified | | `HIS-1041` | Max OTP attempts reached. | Unclassified | | `HIS-1042` | Invalid OIDC transition. | Fix request | | `HIS-1043` | Redirect URL mismatch. | Fix request | | `HIS-1044` | Access code expired. | Fix request | | `HIS-1045` | Mobile update failed. | Unclassified | | `HIS-1046` | Same mobile number not allowed. | Fix request | | `HIS-1047` | Input must be encrypted. | Unclassified | | `HIS-1048` | Unable to fetch document details. | Unclassified | | `HIS-1054` | Invalid document type. | Fix request | | `HIS-1055` | Invalid gender code. | Fix request | | `HIS-1056` | HPID not created via driving licence. | Unclassified | | `HIS-1057` | Document details not available. | Unclassified | | `HIS-1059` | Invalid data provided. | Fix request | | `HIS-1060` | OTP expired or invalid. | Fix request | | `HIS-1061` | Invalid category ID. | Fix request | | `HIS-1062` | Invalid sub category ID. | Fix request | | `HIS-1063` | Invalid image uploaded. | Fix request | | `HIS-1064` | Invalid image size. | Fix request | | `HIS-1065` | Consent required. | Cannot proceed | | `HIS-1066` | Incorrect captcha. | Fix request | | `HIS-1067` | Invalid credentials. | Fix request | | `HIS-1068` | Mobile verification required. | Fix request | | `HIS-1069` | No HPID found for Aadhaar. | Unclassified | | `HIS-1070` | Required field is empty. | Fix request | | `HIS-1071` | Old password does not match. | Unclassified | | `HIS-1072` | Mobile number not registered. | Cannot proceed | | `HIS-1073` | New password cannot be same as old password. | Unclassified | | `HIS-1100` | Invalid Bridge ID. | Fix request | | `HIS-1101` | Bridge ID already registered. | Fix request | | `HIS-1102` | Self transfer not allowed. | Fix request | | `HIS-1103` | Facility transfer request already initiated. | Fix request | | `HIS-1104` | Linked program already in use. | Fix request | | `HIS-1105` | Operation not allowed. | Fix request | | `HIS-1106` | Required fields missing. | Fix request | | `HIS-1107` | Reassign to same manager not allowed. | Fix request | | `HIS-1108` | Invalid attempt. | Fix request | | `HIS-1109` | Professional type mismatch. | Fix request | | `HIS-1110` | Not a Central Government facility. | Unclassified | | `HIS-1111` | Not a State facility. | Unclassified | | `HIS-1112` | Not a Government facility. | Unclassified | | `HIS-1113` | Invalid facility ID format. | Fix request | | `HIS-1114` | Invalid pin code. | Fix request | | `HIS-1115` | Invalid ownership code. | Fix request | | `HIS-1116` | HPR ID required. | Fix request | | `HIS-1117` | Transaction ID required. | Fix request | | `HIS-1118` | Invalid password format. | Fix request | | `HIS-1119` | Invalid token. | Fix request | | `HIS-1120` | Invalid facility ID or name. | Fix request | | `HIS-1121` | Invalid facility details. | Fix request | | `HIS-1122` | User not government type. | Unclassified | | `HIS-1123` | Request body missing fields. | Fix request | | `HIS-1124` | Bridge not linked. | Unclassified | | `HIS-1125` | Invalid HIP name. | Fix request | | `HIS-1126` | Invalid Bridge ID. | Fix request | | `HIS-1127` | Invalid HIP ID. | Fix request | | `HIS-1128` | HIP name already exists. | Fix request | | `HIS-1129` | Invalid HIP name format. | Fix request | | `HIS-1130` | Bridge request failed. | Unclassified | | `HIS-1131` | Geolocation limit exceeded. | Unclassified | | `HIS-1132` | Duplicate facility detected. | Fix request | | `HIS-1148` | Not a government facility. | Unclassified | | `HIS-1149` | Not a private facility. | Unclassified | | `HIS-1150` | Invalid private facility. | Fix request | | `HIS-1151` | Facility ministry mismatch. | Fix request | | `HIS-1152` | Mobile number not found. | Fix request | | `HIS-1153` | PSU mismatch. | Fix request | | `HIS-2001` | Invalid Aadhaar number. | Fix request | | `HIS-2004` | OTP system error. | Unclassified | | `HIS-2022` | Invalid OTP. | Fix request | | `HIS-2031` | Request expired. | Fix request | | `HIS-2045` | Session expired. | Fix request | | `HIS-2055` | Invalid gender. | Fix request | | `HIS-2057` | Invalid category. | Fix request | | `HIS-2062` | Invalid medical council. | Fix request | | `HIS-2075` | Invalid reason of not working. | Fix request | | `HIS-2076` | Invalid work status. | Fix request | | `HIS-2081` | Invalid boolean value. | Fix request | | `HIS-2082` | Invalid reason of not working. | Fix request | | `HIS-2083` | Invalid ministry. | Fix request | | `HIS-2084` | Invalid category. | Fix request | | `HIS-2085` | Validation / verification failure. | Unclassified | | `HIS-2094` | Work status not required. | Fix request | | `HIS-2095` | Facility declaration not required. | Fix request | | `HIS-2096` | Select State Govt facility. | Unclassified | | `HIS-2097` | Select Central Govt facility. | Unclassified | | `HIS-3001` | Resident data not available. | Unclassified | | `HIS-3006` | Document mismatch. | Fix request | | `HIS-3015` | Server timeout. | Retry | | `HIS-3021` | HPRID already exists. | Fix request | | `HIS-3031` | Invalid token. | Fix request | | `HIS-4003` | Facility already exists. | Fix request | | `HIS-4015` | Invalid ownership subtype. | Fix request | | `HIS-4020` | Invalid longitude. | Fix request | | `HIS-4032` | Invalid state code. | Fix request | | `HIS-4044` | Invalid page number. | Fix request | | `HIS-4055` | Invalid image format. | Fix request | | `HIS-4061` | Facility status change not allowed. | Fix request | | `HIS-5001` | Workflow not defined. | Unclassified | | `HIS-5002` | Qualification missing. | Fix request | | `HIS-5005` | Already registered. | Fix request | | `HIS-5006` | Invalid practitioner DTO. | Fix request | | `HIS-5007` | Invalid personal DTO. | Fix request | | `HIS-5008` | Invalid academic DTO. | Fix request | | `HIS-5009` | Invalid registration DTO. | Fix request | | `HIS-5010` | Invalid work DTO. | Fix request | | `HIS-5011` | Token expired. | Fix request | ## P1 PHR identity and profile Code and message are as published. The action column reads the message text by a documented rule. These codes are the PHR facing wording of the core ABDM codes, row for row. | Code | Message | What to do | | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | | `AS-1001` | Database connection failed. Please try again later. | Retry | | `AS-1002` | No results found for the given input. | Fix request | | `AS-1003` | There seems to be a data integrity issue. Please contact support team. | Unclassified | | `AS-1004` | Email gateway is temporarily unavailable. | Retry | | `AS-1005` | SMS gateway is temporarily unavailable. | Retry | | `AS-1006` | The recipient information is invalid. Please check and try again. | Retry | | `AS-1007` | Request could not be processed due to invalid data format. Please review and try again. | Retry | | `AS-1008` | Timeout error: Unable to connect to the server. | Retry | | `AS-1009` | SMS service is temporarily unavailable. | Retry | | `AS-1010` | Email service is temporarily unavailable. | Retry | | `AS-1011` | Validation failed. | Unclassified | | `AS-1012` | Gateway database unavailable | Retry | | `AS-1013` | No records found against the entered ABHA Address | Fix request | | `AS-1014` | Please enter a valid ABHA number. | Fix request | | `AS-1015` | Please enter a valid mobile number and email address . | Fix request | | `AS-1016` | Invalid Response | Fix request | | `AS-1017` | The timestamp format is incorrect. | Fix request | | `AS-1018` | Transaction ID is incorrect or has expired. | Cannot proceed | | `AS-1019` | Share Profile database unavailable | Retry | | `AS-1020` | Dependent Service is unavailable. | Retry | | `AS-1021` | Unknown database | Unclassified | | `AS-1022` | Permission denied - required privileges are missing. | Cannot proceed | | `AS-1023` | You have made too many requests. Please wait a moment and try again. | Retry | | `AS-1024` | Please enter a valid and registered user ID. | Fix request | | `AS-1025` | Dependent Service is unavailable. | Retry | | `AS-1026` | The selected service is invalid. Please check and try again. | Retry | | `AS-1027` | The entered Bridge ID does not exist. Please verify and try again. | Retry | | `AS-1028` | Link token is incorrect or has expired. | Cannot proceed | | `AS-1029` | Your account is currently blocked. Please try again after 24 hours. | Cannot proceed | | `AS-1030` | The requested HIP service is currently not accessible. Please try again later. | Retry | | `AS-1031` | Redis server is temporarily unavailable. | Retry | | `AS-1032` | The request ID is invalid. Please check and try again. | Retry | | `AS-1033` | Invalid request. Please check and try again. | Retry | | `AS-1034` | The request header is invalid or missing required information. Please try again. | Retry | | `AS-1035` | The requested HIU service is currently not accessible. Please try again later. | Retry | | `AS-1036` | Notification service is temporarily unavailable | Retry | | `AS-1037` | Please enter a valid and registered HIP Id. | Fix request | | `AS-1038` | The entered OTP is incorrect or has expired. Please re-enter the correct OTP. | Cannot proceed | | `AS-1039` | The entered information doesn’t match our records. Please verify and try again. | Retry | | `AS-1040` | The number of care contexts does not match the expected count. Please verify the data. | Unclassified | | `AS-1041` | ABHA address does not match the linked token. Please check and try again. | Retry | | `AS-1042` | The consent request ID is invalid . Please verify and try again. | Cannot proceed | | `AS-1043` | Please enter a valid and registered HIU Id. | Fix request | | `AS-1044` | Please enter a valid and registered Locker Id. | Fix request | | `AS-1045` | Acknowledgement is invalid or not properly formatted. Please try again. | Retry | | `AS-1046` | Provider is Mandatory | Unclassified | | `AS-1047` | Please enter a valid and registered provider Id. | Fix request | | `AS-1048` | The ABHA address you entered doesn’t match the KYC details. Please verify and try again. | Retry | | `AS-1049` | Failed to send the broadcast message. Please try again later. | Retry | | `AS-1050` | You do not have permission to access the database. Please contact your administrator. | Unclassified | | `AS-1051` | The selected purpose is invalid. Please verify and try again | Retry | | `AS-1052` | The selected purpose is does not exist. Please verify and try again | Retry | | `AS-1053` | Validation failed | Unclassified | | `AS-1054` | Request timed out. Please try again. | Retry | | `AS-1055` | The profile share intent keys are invalid. Please check and try again. | Retry | | `AS-1056` | The profile share metadata keys are invalid. Please review the shared data. | Fix request | | `AS-1057` | The ABHA number or ABHA address entered is invalid. Please check and try again. | Retry | | `AS-1058` | There was an issue while encoding the content. Please try again. | Retry | | `AS-1059` | The Transaction ID or response’s Request ID is invalid. Please verify and retry. | Fix request | | `AS-1060` | Unable to load overlay image. Please refresh or try again later. | Retry | | `AS-1061` | The entered data already exists in the system. | Fix request | | `AS-1062` | We couldn’t convert the file to PNG format. Please try again or check the file type. | Retry | | `AS-1063` | The subscription request ID is invalid. Please check and try again. | Retry | | `AS-1064` | An error occurred while generating the QR code. Please retry after some time. | Unclassified | | `AS-1065` | The HIP ID or PHR address is invalid. Please check and try again. | Retry | | `AS-1066` | The selected care context is already associated with your ABHA address. | Fix request | | `AS-1067` | The link reference number is invalid. Please check and try again. | Retry | | `AS-1068` | The care context information provided is invalid. Please verify and retry. | Fix request | | `AS-1069` | The health information types provided are invalid. | Fix request | | `AS-1070` | The number of care contexts does not match the expected count. Please review the request. | Unclassified | | `AS-1071` | The patient reference number is invalid. Please check and try again. | Retry | | `AS-1072` | Patient display information is invalid or missing. | Fix request | | `AS-1073` | The consent artefact has expired. Please generate a new one to proceed. | Cannot proceed | | `AS-1074` | The ABHA number you entered doesn’t match the linked token. Please verify and try again. | Retry | | `AS-1075` | The ABHA number you entered doesn’t match the linked token. Please verify and try again. | Retry | | `AS-1076` | Consent has not been granted. | Cannot proceed | | `AS-1077` | The ABHA number you entered doesn’t match the linked token. Please verify and try again. | Retry | | `AS-1078` | The HIP Id doesn’t match the linked token. Please verify and try again. | Retry | | `AS-1079` | The selected date range is invalid. | Fix request | | `AS-1080` | The request could not be processed because the request body is missing. | Fix request | | `AS-1081` | A request with this request ID already exists. | Fix request | | `AS-1082` | Invalid X Auth token | Fix request | | `AS-1083` | Health facility does not exist. Please check and try again. | Retry | | `AS-1084` | JWT token is invalid | Fix request | | `AS-1085` | Please enter a valid password. | Fix request | | `AS-1086` | Request body is not required. | Fix request | | `AS-1087` | Both patient details and error information are missing. Please provide at least one. | Fix request | | `AS-1088` | The authentication type provided is invalid. Please check and try again. | Retry | | `AS-1089` | A consent request with the same details already exists. | Cannot proceed | | `AS-1090` | The login credentials provided are incorrect. Please try again. | Retry | | `AS-1091` | At least one source must be included in the request. | Unclassified | | `AS-1092` | This user is not part of your organisation. Access denied. | Cannot proceed | | `AS-1093` | The consent PIN entered is invalid. Please check and try again. | Cannot proceed | | `AS-1094` | At least one source must be included in the request. | Unclassified | | `AS-1095` | User not found. Please verify and try again. | Retry | | `AS-1096` | The provided consent PIN does not exist. | Cannot proceed | | `AS-1097` | HIP object must be empty when consent is applicable to all HIPs. | Cannot proceed | | `AS-1098` | Your user or manager profile is not e signed. | Unclassified | | `AS-1099` | HIP object cannot be null in excluded sources | Unclassified | | `AS-1100` | Organisation was not found | Fix request | | `AS-1101` | Included sources must contain a valid HIP object. | Unclassified | | `AS-1102` | User ID already exist | Fix request | | `AS-1103` | One or more HIPs provided in the request are invalid. | Fix request | | `AS-1104` | The registration number provided is incorrect. | Fix request | | `AS-1105` | Auto approval policy id doesn't exist. | Unclassified | | `AS-1106` | The uploaded file format is not supported. Please upload a valid format. | Fix request | | `AS-1107` | The auto-approval ID provided is invalid. | Fix request | | `AS-1108` | Document upload failed. Please try again. | Retry | | `AS-1109` | This auto-approval ID has already been disabled. | Fix request | | `AS-1110` | Failed to update user status. Please try again later. | Retry | | `AS-1111` | This subscription request has already been processed. | Fix request | | `AS-1112` | Upload your organisation ID card image to proceed. | Unclassified | | `AS-1113` | The consent artefact ID is invalid. Please verify and try again. | Cannot proceed | | `AS-1114` | Upload your organisation ID card image to proceed. | Unclassified | | `AS-1115` | Subscription approval data is invalid in payload. Please check and try again. | Retry | | `AS-1116` | Upload your organisation’s registration certificate to continue. | Unclassified | | `AS-1117` | A care context exists without an associated HIP ID. Please correct the request. | Unclassified | | `AS-1118` | Duplicate consent approve request | Cannot proceed | | `AS-1119` | Upload an official authority letter from your organisation. | Unclassified | | `AS-1120` | The subscription ID is invalid. Please check and try again. | Retry | | `AS-1121` | The user is not associated with your organisation. Access denied. | Cannot proceed | | `AS-1122` | ABHA number does not match the X Auth token. Please verify your session. | Unclassified | | `AS-1123` | Aadhaar details do not match our records. Please review and select the correct information. | Fix request | | `AS-1124` | Aadhaar details do not match our records. Please review and select the correct information. | Fix request | | `AS-1125` | ABHA number does not match the X Auth token. Please verify your session. | Unclassified | | `AS-1126` | User not found. Please verify and try again. | Retry | | `AS-1127` | Patient profile does not match the X Auth token. Please verify your session. | Unclassified | | `AS-1128` | No transaction found for the provided UUID. | Unclassified | | `AS-1129` | A patient share request with the same details already exists. | Fix request | | `AS-1130` | Sorry, your session is expired. Please login to continue. | Cannot proceed | | `AS-1131` | Health information cannot be null | Fix request | | `AS-1132` | Captcha verification failed. Please enter the correct code to continue. | Fix request | | `AS-1133` | Payment information cannot be null | Fix request | | `AS-1134` | Captcha expired or not loaded. Please reload and try again. | Cannot proceed | | `AS-1135` | Duplicate HIP link request | Unclassified | | `AS-1136` | You can export up to 500 records at a time. | Unclassified | | `AS-1137` | A similar request to get links already exists. Please try again later. | Retry | | `AS-1138` | The ABHA number must be 14 digits. Please correct it and try again. | Retry | | `AS-1139` | Duplicate Link token request | Unclassified | | `AS-1140` | A valid consent was not found for this request. | Cannot proceed | | `AS-1141` | A bridge request with these details already exists. | Fix request | | `AS-1142` | The transaction ID or consent artefact ID provided is invalid. Please verify and try again. | Cannot proceed | | `AS-1143` | A bridge patch request for this transaction already exists. | Fix request | | `AS-1144` | You are not authorized to update the status | Cannot proceed | | `AS-1145` | A bridge service request with the same details already exists. | Fix request | | `AS-1146` | Please enter a valid registered email address. | Fix request | | `AS-1147` | Duplicate Gateway Consent Manager request | Cannot proceed | | `AS-1148` | Duplicate Gateway Consent Manager patch request | Cannot proceed | | `AS-1149` | Duplicate Gateway Government Program request | Unclassified | | `AS-1150` | Duplicate Subscription request | Unclassified | | `AS-1151` | Duplicate Subscription Approve request | Unclassified | | `AS-1152` | You've reached the maximum number of OTP attempts or the OTP wasn’t generated. Please wait 30 minutes and try again with a new OTP. | Retry | | `AS-1153` | Duplicate Health Information request | Fix request | | `AS-1154` | This ABHA Address already exists. Please create with unique ABHA address. | Fix request | | `AS-1155` | Profile information cannot be empty | Fix request | | `AS-1156` | Mobile number verification is pending. | Unclassified | | `AS-1157` | Duplicate Discovery request | Unclassified | | `AS-1158` | Linking with CHILD ABHA Number is not allowed. | Unclassified | | `AS-1159` | Duplicate Init request | Unclassified | | `AS-1160` | You cannot link with sameABHA Number.Please use a different ABHA Number. | Unclassified | | `AS-1161` | Duplicate Confirm request | Unclassified | | `AS-1162` | The request for linking a parent profile is invalid. Please check the details and try again. | Retry | | `AS-1163` | Duplicate On discovery request | Unclassified | | `AS-1164` | Duplicate On init request | Unclassified | | `AS-1165` | The selected scopes combination are not valid together. | Unclassified | | `AS-1166` | Duplicate On confirm request | Unclassified | | `AS-1167` | Notification service is currently unavailable. Please try again later. | Retry | | `AS-1168` | The On-Discovery response received is invalid. Please try again. | Retry | | `AS-1169` | ABHA database is currently unavailable. Please try again later. | Retry | | `AS-1170` | Invalid On init response | Fix request | | `AS-1171` | Your new password must be different from your old password. Please enter a unique new password. | Fix request | | `AS-1172` | Invalid On confirm response | Fix request | | `AS-1173` | The old password entered is incorrect. Please try again with a valid password. | Retry | | `AS-1174` | The consent artefact ID is either invalid or has expired. | Cannot proceed | | `AS-1175` | Please ensure both old and new passwords are encrypted | Unclassified | | `AS-1176` | Duplicate health information provider data flow response | Fix request | | `AS-1177` | Please enter a valid Captcha | Fix request | | `AS-1178` | Duplicate health information notification request | Fix request | | `AS-1179` | User not found. Please verify and try again. | Retry | | `AS-1180` | Patient information is invalid. Please provide at least one valid patient detail. | Fix request | | `AS-1181` | Mobile number not found. | Fix request | | `AS-1182` | The Auto approval request is invalid | Fix request | | `AS-1183` | Aadhaar details not found in the system. | Fix request | | `AS-1184` | This auto approval id is already active | Fix request | | `AS-1185` | Login using password is not allowed. Please use other login methods. | Unclassified | | `AS-1186` | Duplicate auto approval request | Unclassified | | `AS-1187` | Login via ABHA Number OTP is not allowed. Please use other login methods. | Unclassified | | `AS-1188` | Invalid subscription edit payload | Fix request | | `AS-1189` | Login via Aadhaar OTP is not allowed. Please use other login methods. | Unclassified | | `AS-1190` | No care context is available for this patient. | Unclassified | | `AS-1191` | Missing or invalid request ID header. Please ensure a valid REQUEST\_ID is provided. | Fix request | | `AS-1192` | The enrolment number entered is invalid. Please verify and try again. | Retry | | `AS-1193` | Your request could not be processed at the moment. Please try again later. | Retry | | `AS-1194` | User authentication failed | Unclassified | | `AS-1195` | The mobile number provided by you is already linked to 6 ABHA numbers. Please provide a different mobile number. | Fix request | | `AS-1196` | The mobile number provided by you is already linked to 6 ABHA numbers. Please provide a different mobile number. | Fix request | | `AS-1197` | Both ABHA number and ABHA address cannot be null | Unclassified | | `AS-1198` | Sorry, your session is expired. Please login to continue. | Cannot proceed | | `AS-1199` | Invalid F-Token | Fix request | | `AS-1200` | Sorry, your session is expired. Please try again. | Cannot proceed | | `AS-1201` | Invalid T-Token | Fix request | | `AS-1202` | Invalid X-Token | Fix request | | `AS-1203` | X-Token Expired | Cannot proceed | | `AS-1204` | Kindly enter valid linked ABHA Address | Fix request | | `AS-1205` | The captcha result entered is incorrect. Please try again with the correct value. | Retry | | `AS-1206` | This ABHA account has been deactivated. | Cannot proceed | | `AS-1207` | The email address provided by you is already linked to 6 ABHA Numbers. Please provide a different email address. | Fix request | | `AS-1208` | Message cannot be null or empty. | Unclassified | | `AS-1209` | Benefit name not found. Please check the entered details. | Fix request | | `AS-1210` | This benefit record has already been de-linked. | Fix request | | `AS-1211` | No benefit record found for the given details. | Unclassified | | `AS-1212` | The benefit record has already been linked | Fix request | | `AS-1213` | This account already exist | Fix request | | `AS-1214` | Captcha has expired. Please enter a new captcha. | Cannot proceed | | `AS-1215` | Captcha attempts exceeded. | Unclassified | | `AS-1216` | Captcha attempts exceeded. | Unclassified | | `AS-1217` | This subscription is already enabled | Fix request | | `AS-1218` | The facility ID or password is incorrect. Please check and try again. | Retry | | `AS-1219` | This subscription is already disabled. | Fix request | | `AS-1220` | Subscription is not in revoked state | Unclassified | | `AS-1221` | Subscription is not in granted stat | Unclassified | | `AS-1222` | This subscription ID does not belong to the patient. | Unclassified | | `AS-1223` | The requested intent type is not supported at the HIP. | Unclassified | | `AS-1224` | Bridge API version cannot be null | Unclassified | | `AS-1225` | Health locker has already been set up for this user. | Fix request | | `AS-1226` | No active subscription found for the selected health locker. | Unclassified | | `AS-1227` | Unable to create auto-approval consent for the health locker. Please try again later. | Cannot proceed | | `AS-1228` | Unable to save user health locker details. | Unclassified | | `AS-1229` | Parents must be 18 years of age or older to create a Child ABHA Account | Unclassified | | `AS-1230` | Please ensure that the mobile number is mapped to the parent’s ABHA number | Unclassified | | `AS-1231` | Maximum number of Child ABHA accounts reached for the given ABHA number ‘%s’ | Unclassified | | `AS-1232` | Invalid X-Token | Fix request | | `AS-1233` | Children must be under '%s' years of age as of today to create a Child ABHA. | Unclassified | | `AS-1234` | Non KYC CHILD ABHA is allowed to update their profile only once | Unclassified | | `AS-1235` | The ABHA address entered is invalid. Please verify and try again. | Retry | | `AS-1236` | LGD Gateway is currently unavailable. Please try again later. | Retry | | `AS-1237` | IDP Gateway is currently unavailable. Please try again later. | Retry | | `AS-1238` | Document Gateway is currently unavailable. Please try again later. | Retry | | `AS-1239` | TEST | Unclassified | | `AS-1240` | TEST | Unclassified | | `AS-1241` | Document DB Gateway is currently unavailable. Please try again later. | Retry | | `AS-1242` | Aadhaar Gateway is currently unavailable. Please try again later. | Retry | | `AS-1243` | The information you provided does not match the details on record with Aadhaar. Please verify and provide accurate information. | Fix request | | `AS-1244` | The information you provided does not match the details on record with Aadhaar. Please verify and provide accurate information. | Fix request | | `AS-1245` | ABHA profile gateway is currently unavailable.Please try again later. | Retry | | `AS-1246` | PHR DB service is currently unavailable. Please try again later. | Retry | | `AS-1247` | Duplicate Notification request | Unclassified | | `AS-1248` | Login via Email Address OTP is not allowed. Please use other login methods. | Unclassified | | `AS-1249` | You have exceeded the email sending limit. Please wait before trying again. | Unclassified | | `AS-1250` | User not found. Please verify and try again. | Retry | | `AS-1251` | Email address not found. | Fix request | | `AS-1252` | User not active. | Unclassified | | `AS-1253` | Mobile/Email verification is pending. | Unclassified | | `AS-1254` | Login via Mobile Number OTP is not allowed. Please use other login methods. | Unclassified | | `AS-1255` | The ABHA Address is deactivated. | Cannot proceed | | `AS-1256` | Login is not allowed | Unclassified | | `AS-1257` | No role has been assigned to this user. | Unclassified | | `AS-1258` | Notification templates not found | Fix request | | `AS-1259` | Your ABHA is linked with govt benefit programme, so it can not be deleted- ABDM, National Health Authority. | Unclassified | | `AS-1260` | Sorry, Unable to process your request at this time. Please try again later. | Retry | | `AS-1261` | Face verification has been failed, please try again. | Retry | | `AS-1262` | Fingerprint verification has been failed, please try again. | Retry | | `AS-1263` | IRIS verification has been failed, please try again. | Retry | | `AS-1264` | Biometric login is currently not allowed. Please use an alternate login method. | Unclassified | | `AS-1265` | The email ID provided does not match the one registered. Please check and try again. | Retry | | `AS-1266` | Mobile number is not linked to your ABHA address. Please update your mobile number in ABHA. | Unclassified | | `AS-1267` | HIP is currently unavailable. Please try again later. | Retry | | `AS-1268` | Your mobile number is not linked to the ABHA number. Please update your mobile number in ABHA or try to register using Aadhaar OTP | Unclassified | | `AS-1269` | No acknowledgement was received from the HIP. Please try again later. | Retry | | `AS-1270` | Invalid callback resp id | Fix request | | `AS-1271` | Invalid Refresh token | Fix request | | `AS-1272` | The grant type is invalid. Please check the request and try again. | Retry | | `AS-1273` | The client ID is invalid. Please verify and try again. | Retry | | `AS-1274` | The client secret is invalid. Please verify and try again. | Retry | | `AS-1275` | Both client ID and secret are invalid. Please verify and try again. | Retry | | `AS-1276` | Service ID ‘%s’ already exists. Please use a different service ID. | Fix request | | `AS-1277` | HFR request failed, but rollback was successful for HFR ID ‘%s’. | Unclassified | | `AS-1278` | The bridge registry request is invalid. Please verify and try again. | Retry | | `AS-1279` | All the provided service IDs do not match with the client ID | Unclassified | | `AS-1280` | HIP did not acknowledge the HIP consent notify. Please try again after some time | Cannot proceed | | `AS-1281` | An unknown error occurred. Please try again later | Retry | | `AS-1282` | Invalid X Auth token | Fix request | | `AS-1283` | Patient profile mismatch with X Auth token | Fix request | | `AS-1284` | Access Denied | Cannot proceed | | `AS-1285` | Cannot process the request at the moment, please try later. | Retry | | `AS-1286` | Open order not found | Fix request | | `AS-1287` | Error in making call to target system Content type 'text/html' not supported for bodyType=java.util.HashMap | Unclassified | | `AS-1288` | Cannot find any linked ABHA address. Please create ABHA address first. | Unclassified | | `AS-1289` | OTP is not verified for this transaction | Unclassified | | `AS-1290` | User is not kyc verified | Unclassified | | `AS-1291` | Self-relationship not allowed | Unclassified | | `AS-1292` | Duplicate relationship not allowed.A relationship already exists between %s and %s | Fix request | | `AS-1293` | We are facing some issue in server connectivity. Please try again | Retry | | `AS-1294` | UIDAI Error code : 300 : Biometric data did not match. | Unclassified | | `AS-1295` | The mobile number you have entered does not match with any of the records Please enter a different number | Fix request | | `AS-1296` | You can request for new OTP after 30 seconds timestamp %s | Unclassified | | `AS-1297` | This account is deactivated Please continue to reactivate abhaNumber %s | Cannot proceed | | `AS-1298` | It appears that you are either not connected to the internet or experiencing a slow connection. please try again. | Retry | | `AS-1299` | UIDAI Error code : 953 : You have requested multiple OTPs in this transaction. Please try again in 30 minutes. | Retry | | `AS-1300` | The mobile number you have entered has already been verified. Please provide an alternate mobile number. | Fix request | | `AS-1301` | Old and New Passwords are same | Unclassified | | `AS-1302` | This account is deactivated. Please reactivate it from ABHA portal. | Cannot proceed | | `AS-1303` | No ABHA user registered with this Aadhaar number | Unclassified | | `AS-1304` | UIDAI Error code : 400 :OTP validation failed | Unclassified | | `AS-1305` | Please provide a photo featuring only one individual and not a group photo. | Unclassified | | `AS-1306` | Invalid photo. Please upload a file with a human face. | Fix request | | `AS-1307` | Your mobile number is not linked to the ABHA number. Please update your mobile number in ABHA or try using Aadhaar OTP. | Unclassified | | `AS-1308` | You can request for new OTP after 30 seconds | Unclassified | | `AS-1309` | As per NHA policy, your mobile number has reached the limit of 6 self-declared ABHA addresses. Please link your existing ABHA addresses to your ABHA number. | Unclassified | | `AS-1310` | User not found. Please verify and try again. | Retry | | `AS-1311` | No password is set for this profile. Please log in using other login modes. | Unclassified | | `AS-1312` | Mobile number is missing for this ABHA address. Please update your mobile number. | Fix request | | `AS-1313` | The ABHA address entered is invalid. Please verify and try again. | Retry | | `AS-1314` | Required header 'X-token' is not present. | Fix request | | `AS-1315` | T-token expired | Cannot proceed | | `AS-1316` | Doctor info not found for healthProfessionalId :'%s' | Fix request | | `AS-1317` | An unexpected error has occurred. Please try again in some time. | Retry | | `AS-1318` | Login via Password is not allowed | Unclassified | | `AS-1319` | Invalid Password Request, Please enter valid ABHA Address or valid password | Fix request | | `AS-1320` | Invalid OTP Value | Fix request | | `AS-1321` | External service is temporarily unavailable | Retry | | `AS-1322` | User not found. Please verify and try again. | Retry | | `AS-1323` | User not found. Please verify and try again. | Retry | | `AS-1324` | The mobile number you have entered does not match with any of the records. Please enter a different number | Fix request | | `AS-1325` | Invalid Mobile Number | Fix request | | `AS-1326` | UIDAI Error code : 400 : OTP validation failed | Unclassified | | `AS-1327` | Mobile number is missing for this ABHA address. Please update your mobile number. | Fix request | | `AS-1328` | Transaction is not found for UUID. | Fix request | | `AS-1329` | You can request for new OTP after 30 seconds | Unclassified | | `AS-1330` | T-token expired | Cannot proceed | | `AS-1331` | The ABHA address entered is invalid. Please verify and try again. | Retry | | `AS-1332` | Please enter a valid and registered provider Id. | Fix request | | `AS-1333` | You can request for new OTP after 30 seconds | Unclassified | | `AS-1334` | This account is deactivated. Please reactivate it from ABHA portal. | Cannot proceed | | `AS-1335` | Login via Password is not allowed | Unclassified | | `AS-1336` | No open order against ABHA. Please ensure a minimum of one open order | Unclassified | | `AS-1337` | No CR Mapped with Abha Address | Unclassified | | `AS-1338` | No pending care context found for this abha address | Unclassified | | `AS-1339` | The provided gender does not match the gender in DigiLocker records | Unclassified | | `AS-1340` | The provided DOB does not match the DOB in DigiLocker records | Unclassified | | `AS-1341` | The provided name does not match the name in DigiLocker records | Unclassified | | `AS-1342` | Invalid Face Auth PID | Fix request | | `AS-1343` | No open order against ABHA. Please ensure a minimum of one open order | Unclassified | | `AS-1344` | No registration found at %s. Contact counter support | Unclassified | | `AS-1345` | Hospital services temporarily unavailable. Please try again after some time | Retry | | `AS-1346` | Services disrupted, please try again. | Retry | | `AS-1347` | Bank server not responding. Please try again later | Retry | | `AS-1348` | Service details mismatch. Please ensure original service ID from HMIS | Fix request | | `AS-1349` | The HIMS service is currently unavailable. Please try again after some time | Retry | | `AS-1350` | Cannot process the request at the moment, please try later | Retry | | `AS-1351` | No user profile found. | Unclassified | | `AS-1352` | Cannot process the request at the moment, please try later. | Retry | | `AS-1353` | Invalid OTP Request | Fix request | | `AS-1354` | X-token expired | Cannot proceed | | `AS-1355` | Invalid Mobile number. | Fix request | | `AS-1356` | No pending care context found for this abha address | Unclassified | | `AS-1357` | Invalid Password | Fix request | | `AS-1358` | Invalid R-token | Fix request | | `AS-1359` | Required header 'T-token' is not present. Please provide a valid T-token. | Fix request | | `AS-1360` | Required header 'R-token' is not present. Please provide a valid R-token. | Fix request | | `AS-1361` | Required header 'X-token' is not present. Please provide a valid X-token. | Fix request | | `AS-1362` | Requested URL or resource is not available | Unclassified | | `AS-1363` | Invalid X-token | Fix request | | `AS-1364` | Invalid T-token | Fix request | | `AS-1365` | The Scan and Pay functionality is not enabled at this facility. Kindly contact the hospital administration. | Unclassified | | `AS-1366` | No CR Mapped with Abha Address | Unclassified | | `AS-1367` | No care context is available for this patient. | Unclassified | | `AS-1368` | No registration found at %s. Contact counter support | Unclassified | | `AS-1369` | Invalid address line. It must be alphanumeric and can include the following special characters: ,.'/()- | Fix request | | `AS-1370` | External service error | Unclassified | | `AS-1371` | External service is temporarily unavailable | Retry | | `AS-1372` | External Service Unavailable | Retry | | `AS-1373` | Invalid Credentials. Make sure your API invocation call has a header: 'Authorization : Bearer ACCESS\_TOKEN' or 'Authorization : Basic ACCESS\_TOKEN' or 'apikey: API\_KEY' | Fix request | | `AS-1374` | Invalid Credentials. Make sure you have provided the correct security credentials | Fix request | | `AS-1375` | Invalid Login Hint | Fix request | | `AS-1376` | Invalid Scope | Fix request | | `AS-1377` | Patient not found | Fix request | | `AS-1378` | This account is deactivated. Please reactivate it from ABHA portal. | Cannot proceed | | `AS-1379` | Digilocker account creation fail. | Unclassified | | `AS-1380` | Too many request attempted in short period of time. This method is blocked for next 30 minutes | Cannot proceed | | `AS-1381` | The email Id you have entered has already been verified. Please provide an alternate email Id | Fix request | | `AS-1382` | Please avoid trying to generate the OTP multiple times within short time. | Unclassified | | `AS-1383` | Sorry you have exceeded your feedback submission limit | Unclassified | | `AS-1384` | Invalid KYC XML | Fix request | | `AS-1385` | R-token expired | Cannot proceed | | `AS-1386` | Invalid Email Id | Fix request | | `AS-1387` | You have exceeded the maximum limit of failed attempts Please try to login using other modes or try again in 24 hours | Retry | | `AS-1388` | Health Locker is Already Unsubscribed | Fix request | | `AS-1389` | Beneficiary is not a covered member for requested policy. Please enroll beneficiary for the policy and try again. | Retry | | `AS-1390` | No Claim History with requested Details | Unclassified | | `AS-1391` | External Service Unavailable | Retry | | `AS-1392` | Duplicate Link token request | Unclassified | | `AS-1393` | Digilocker Service Unavailable | Retry | | `AS-1394` | You have exceeded the maximum limit of failed attempts Please try to login using other modes or try again in 30 mins | Retry | | `AS-1395` | You have exceeded the maximum limit of failed attempts Please try to login using other modes or try again in 24 hours | Retry | | `AS-1396` | Aadhaar number is incorrect.Please use correct Aadhaar. | Fix request | | `AS-1397` | FileName can not be null or empty | Unclassified | | `AS-1398` | You have exceeded the maximum limit of failed attempts. Please try to login using other modes or try again in 12 hours. | Retry | | `AS-1399` | Duplicate patient record share request. | Unclassified | | `AS-1400` | Invalid HEALTHLOCKER Id or PHR Id. | Fix request | | `AS-1401` | Invalid Service ID, it must be Alpha numeric and @, \_ or - in middle. | Fix request | | `AS-1402` | Care context cannot be null or empty. | Unclassified | | `AS-1403` | Invalid data erase date. Date must be a future date. | Fix request | | `AS-1404` | Data erase date cannot be null or empty. | Unclassified | | `AS-1405` | Transaction Id is not matching with response. | Unclassified | | `AS-1406` | Request Timed out. | Unclassified | | `AS-1407` | expiry should be in future date. | Unclassified | | `AS-1408` | Invalid API sequence flow, please follow logical flow. | Fix request | | `AS-1409` | Invalid session status, Status should be TRANSFERRED, PARTIAL\_TRANSFERRED or FAILED. | Fix request | | `AS-1410` | Invalid health information status. | Fix request | | `AS-1411` | endDate should be after startDate and before currentDate. | Unclassified | | `AS-1412` | Invalid Mobile Number. | Fix request | | `AS-1413` | LoginId is invalid. | Fix request | | `AS-1414` | Invalid Transaction Id. | Fix request | | `AS-1415` | Unable to fetch the file details. | Unclassified | | `AS-1416` | Invalid PinCode, it must be only numbers and maximum length of 6. | Fix request | | `AS-1417` | NHCX service is temporarily unavailable. | Retry | | `AS-1418` | Maximum number of attempts for OTP match is exceeded or OTP is not generated. Please generate a fresh OTP and try to authenticate again. | Unclassified | | `AS-1419` | LoginId is invalid. | Fix request | | `AS-1420` | Invalid Otp System. | Fix request | | `AS-1421` | Invalid Auth Methods. | Fix request | | `AS-1422` | This Aadhaar number is already linked to the ABHA Number %s. Please re-login and try using another Aadhaar Number. | Fix request | 922 codes are recorded. A code you meet that is not here is one the specifications do not carry yet. --- # ABHA, the patient registry [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) is the Ayushman Bharat Health Account, the patient half of [Registries](/docs/hiecm/v3/registries). It answers "who is this patient", and every record flow in [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) starts from that answer. ## One account, two identifiers | | ABHA number | ABHA address | | ------------------ | -------------------------------------------------------------------------------------- | ---------------------------------------------------------- | | What it looks like | 14 digits, hyphenated in samples as `91-XXXX-XXXX-XXXX` | A readable name, such as `name@abdm` | | How it is issued | After an Aadhaar based [KYC](/docs/hiecm/v3/getting-started/glossary#kyc) check passes | Chosen by the person, or issued as a default | | What it is for | The identity anchor. One person, one number | Routing. It is the handle other systems address records to | | Can exist alone | No. It always carries a default address | Yes. A person can hold an address with no number | Store both. You match a patient record against the number, and you send the address when you link a [care context](/docs/hiecm/v3/getting-started/glossary#care-context) or ask for consent. The number is issued only after a strong KYC process completes. ## The check digit Two validation utilities exist: ABHA number validation by the Luhn algorithm, and Aadhaar number validation by the Verhoeff algorithm. Luhn derives the last digit from the ones before it, so you catch a mistyped number locally before spending a call. ## How identity is verified Verification runs against Aadhaar through the ABHA service, so your system never calls Aadhaar directly. There are four routes: | Route | How the person proves identity | Private integrators | Government integrators | | ---------------------------------------------------------- | ----------------------------------------------------------------------------------- | ------------------- | ---------------------- | | Aadhaar [OTP](/docs/hiecm/v3/getting-started/glossary#otp) | A code sent to the Aadhaar linked mobile number | Mandatory | Mandatory | | Face authentication | A QR code scanned in the ABHA app, then face capture through the Aadhaar RD service | Optional | Optional | | Biometrics | Fingerprint or IRIS on a registered device, which returns a signed PID block | Optional | Optional | | Demographic authentication | Name, date of birth and gender matched against Aadhaar | Not required | Mandatory | Build Aadhaar OTP first. It is mandatory for everyone and needs no hardware. ### Child ABHA A child under six has no Aadhaar number. Child ABHA is a 14 digit identifier created with a parent or legal guardian's consent, so a health record exists from birth. It is restricted to specific government integrators approved by NHA leadership, through programmes including UWIN, RCH and POSHAN. Private integrators cannot use it. ## The ABHA address The shape is `name@abdm`. - **Every number gets a default address**, the number with a suffix: `14digit@sbx` in [sandbox](/docs/hiecm/v3/getting-started/glossary#sandbox), `14digit@abdm` in production. The M1 Postman collection shows a `preferredAbhaAddress` field holding the 14 digits with the `@abdm` suffix and no hyphens. - **A person can then create a memorable one.** A suggestion call offers addresses, and a custom address is accepted, linked to the number. - **An address can exist without a number.** One can be created on the [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) from mobile number, name, age and gender, self declared and with no KYC. Expect accounts with no number behind them. ### Address policy These rules apply: - Letters, numbers and a dot are allowed. - It cannot begin with a number. - It cannot begin or end with a dot. - An all numeric address is allowed only in the `14digit@abdm` default form. - A 10 digit mobile number as an address is restricted and not created. Minimum length differs by flow. Validate against the error the endpoint returns rather than assuming one rule across all of them. ## What an address is allowed to be NHA validates the address on creation, so a form that accepts what NHA refuses produces a failure the person cannot act on. Letters, digits and a single dot are allowed, and beyond that: - It cannot begin with a digit. - It cannot begin or end with a dot. - An all digit address is allowed for an ABHA number and nothing else, which is what makes the default `14digit@abdm` legal. Three shapes read as though they should work and do not. A ten digit mobile number as an address is restricted. An ABHA number as an address you create is not allowed, although the default one is issued automatically and signing in with it works on both web and mobile. And anything failing the rules above is refused at creation rather than at submission. The minimum length is stated twice, differently NHA's PHR document gives the minimum as 4 characters in its narrative and as 8 in the test case for creating an address by mobile number. Neither has been run against the sandbox from here. Build to 8, which is the stricter reading. A password is created alongside the address: at least 8 characters, at least one uppercase letter, one lowercase letter, one digit and one symbol, no spaces, and no more than two consecutive characters or keyboard keys. NHA describes enforcing it as optional for the application, not the password itself as optional. Offer suggestions rather than an empty box and a policy. Two calls exist for it, address suggestions and address exists, and NHA asks that suggestions be built from the person's name and the username part of their email. ## What an ABHA record holds The profile response carries: | Field | What it is | | --------------------------------------------- | --------------------------------------------------- | | `ABHANumber` | The 14 digit number, hyphenated | | `preferredAbhaAddress` | The address, with its suffix | | `mobile` | The communication mobile number | | `firstName`, `middleName`, `lastName`, `name` | Name parts and the joined name | | `yearOfBirth`, `monthOfBirth`, `dayOfBirth` | Date of birth as three separate strings | | `gender` | A single letter | | `email` | Present once an email is verified, otherwise `null` | | `profilePhoto` | Base64 image data with no data URI prefix | The communication mobile number need not be the Aadhaar linked one. It is verified separately, by its own OTP, after enrolment. Email is optional throughout. An ABHA also carries a card, downloadable as an image, and a QR code, both M1 calls. Field level detail is on [M1 APIs](/docs/hiecm/v3/api/m1/apis). ## Where the calls go ```text Sandbox https://abhasbx.abdm.gov.in/abha/api/v3/Production https://abha.abdm.gov.in/api/abha/v3/ ``` One exception: login by Aadhaar number using fingerprint or IRIS uses the v3.1 base URL, `https://abhasbx.abdm.gov.in/abha/api/v3.1/`. No production v3.1 URL is given. ## What M1 does with it [M1](/docs/hiecm/v3/api/m1) is the only milestone that writes to this registry. It covers creation, login, profile management and sessions. Login by mobile number, Aadhaar number, ABHA number and ABHA address are all four mandatory for both private and government integrators. ## What every other milestone assumes - **[M2](/docs/hiecm/v3/api/m2)** links a care context to the ABHA address and answers [discovery](/docs/hiecm/v3/getting-started/glossary#discovery) against it. See [Linking records](/docs/hiecm/v3/concepts/linking). - **[M3](/docs/hiecm/v3/api/m3)** raises a consent request against the ABHA address. See [Consent](/docs/hiecm/v3/concepts/consent). - **[PHR applications](/docs/hiecm/v3/concepts/phr)** sign a person in by ABHA address and show the records linked to it. No flow starts without an ABHA, so M1 comes first even when your real goal is M2 or M3. ## Next - [NHPR](/docs/hiecm/v3/registries/nhpr), the professional and facility registries. - [M1, ABHA identity](/docs/hiecm/v3/api/m1), the guide. - [M1 API reference](/reference/hiecm-m1). - [Sandbox data dictionary](/docs/hiecm/v3/reference/data-dictionary), test identities. --- # Registries A registry is a national directory: it issues an identifier, holds the record behind it and answers lookups. Every other [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) API assumes those identifiers already exist, so a registry entry is the first thing your integration creates. There are two, because ABDM separates the person receiving care from the people and places giving it. [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) is the patient side. NHPR is the provider side, and covers two registries of its own: the [HPR](/docs/hiecm/v3/getting-started/glossary#hpr) for professionals and the [HFR](/docs/hiecm/v3/getting-started/glossary#hfr) for facilities. | Registry | Identifies | Identifier | Written by | | ----------------------------------------- | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | --------------------------- | | [ABHA](/docs/hiecm/v3/registries/abha) | A patient | 14 digit ABHA number issued after [KYC](/docs/hiecm/v3/getting-started/glossary#kyc), plus an ABHA address | [M1](/docs/hiecm/v3/api/m1) | | [HPR](/docs/hiecm/v3/registries/nhpr/hpr) | A doctor, nurse, pharmacist or facility manager | HPR ID | [M4](/docs/hiecm/v3/api/m4) | | [HFR](/docs/hiecm/v3/registries/nhpr/hfr) | A hospital, clinic, lab, imaging centre or pharmacy | Facility ID | [M4](/docs/hiecm/v3/api/m4) | ## The order they arrive in The HFR create call takes a professional token in its header, generated from an HPR ID and password. Someone in your organisation needs an HPR ID with facility manager rights before you can register a facility, and a facility has to be in the HFR before it can act as a [HIP](/docs/hiecm/v3/getting-started/glossary#hip) or [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) on [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm). ## Next - [ABHA](/docs/hiecm/v3/registries/abha), the patient registry - [NHPR](/docs/hiecm/v3/registries/nhpr), the provider registries and their shared base URLs - [HIE-CM](/docs/hiecm/v3/), the gateway that uses these identifiers --- # HFR, the facility registry [HFR](/docs/hiecm/v3/getting-started/glossary#hfr) is the Health Facility Registry, the places half of [NHPR](/docs/hiecm/v3/registries/nhpr) alongside the [HPR](/docs/hiecm/v3/registries/nhpr/hpr). It is a national directory of hospitals, clinics, diagnostic laboratories, imaging centres and pharmacies, and a facility has to enrol here before it can do anything else on [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm). ## Why it blocks everything else A facility needs a valid facility ID and registration in the [HIP](/docs/hiecm/v3/getting-started/glossary#hip) role before it can create health records and share them. A product that has finished [M2](/docs/hiecm/v3/api/m2) or [M3](/docs/hiecm/v3/api/m3) against the sandbox cannot go live without this registry. What the facility gets: a trusted identity, a listing in national search results, less paperwork on licence renewals and insurance empanelment, and access to ABDM's digital services. ## What a facility record holds Three layers, one call each. | Layer | What goes in it | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Basic information | Name, ownership and its subtypes, system of medicine, facility type and subtype, speciality type, operational status, type of service, the full address as codes, latitude and longitude, contact details, opening days and hours, and two mandatory photographs of the board and the building | | Additional information | Yes or no flags for a dialysis centre, pharmacy, blood bank, cath lab, diagnostic lab and imaging centre, plus scheme identifiers the facility already holds: NHRR, NIN, AB-PMJAY, Rohini, ECHS, CGHS, CEA registration and a state insurance scheme ID | | Detailed information | Specialities per system of medicine, and the sections that apply to this facility type: medical infrastructure and bed counts, pharmacy details, blood bank details, diagnostic services, imaging services | Which parts of the detailed layer are mandatory depends on the facility type, the type of service and the system of medicine, and the rules are on [the HPR and HFR call list](/docs/hiecm/v3/api/m4/undocumented). Two of them shape your form. An inpatient or day care facility must submit at least one bed count greater than zero. An imaging centre, diagnostic laboratory, blood bank or pharmacy need not submit medical infrastructure at all. ### Codes, not names Ownership, facility type, facility subtype, speciality, system of medicine, operational status and days of operation come from HFR's own master data calls. Demographic fields come from the Local Government Directory at [lgdirectory.gov.in](https://lgdirectory.gov.in/), through the LGD state, district and sub district calls. HFR APIs accept only the code for any field where master data is defined, never the display value, so build the master data fetch first or every write call fails validation. ## The onboarding journey Five calls, in a fixed order. 1. **Deduplicate search.** Check the facility is not already listed. 2. **Basic facility information.** Creates the record and returns a tracking ID. That ID is your facility's unique identification number until you submit. Pass it as the facility ID on every later call in the sequence. 3. **Additional information.** Takes the tracking ID. 4. **Detailed information.** Takes the tracking ID. 5. **Submit facility details.** Sends the facility for verification. Without call five the facility does not exist If you do not make the submit call, the facility stays in draft. A draft facility goes nowhere, and nothing else in ABDM can use it. Running the first four calls and getting a tracking ID back does not mean you are registered. To update a facility later, send the same calls with the facility ID or tracking ID in the payload rather than creating a new record. ## The link to the HPR token Your client credentials are not enough. Basic facility information takes an **HPR token in the header**, generated from an HPR ID and password. Submit facility takes an **`x-hpird-auth` token in the header**. Obtain both from the HPR token flow, and set each header by the name the call asks for. Both come from a person, not from your application. That is why [HPR](/docs/hiecm/v3/registries/nhpr/hpr) comes first in a rollout, and why somebody in your organisation needs an [HPID](/docs/hiecm/v3/getting-started/glossary#hpid) with facility manager rights, role 2 or role 3, before you write a line of HFR code. ## The facility ID A submitted and verified facility carries a facility ID, and that ID identifies it in every record you share. Two formats are documented for it: | Where | Format | | ------------------------------------------------------------------- | ----------------------------------------------------------------- | | Bridge linkage, facility search, nearby search, send OTP to contact | Starts with `IN` and is 12 characters in total | | Deduplicate search | A 6 digit numeric value, labelled there as the facility unique ID | One parameter name carries two different formats. Take the format from the reference page for the call you are making. ## Bridge linkage A bridge is your software's connection to ABDM. Registering a facility gives it an identity; linking a bridge makes your system resolvable as that facility, in the HIP or [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) direction, so records flow to it. The call takes a facility ID, the facility name, a bridge ID, a HIP name, a type of `HIP` or `HIU`, and an active flag. The HIP name is the one field a patient sees. It is the name shown in the [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) or [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app when the patient searches for the hospital. It must be 15 characters or fewer, carry no special characters, and be unique for every bridge within a facility. The suggested pattern is the hospital name plus the bridge name: hospital XYZ on bridge BRIDGE TEST becomes `XYZ BRIDGE`. Fifteen characters is short, so pick what a patient will recognise. ## Finding a facility | Call | What it is for | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Deduplicate search | Name, district and sub district, before creating a record | | Search facility | By facility ID, or by ownership code, state LGD code and facility name. Fuzzy on the name, exact on everything else, paginated | | Nearby search | Latitude, longitude and a radius in kilometres, with optional filters for ownership, speciality and ABDM enabled. Results are ordered nearest first | | Send and validate OTP to contact | Sends an [OTP](/docs/hiecm/v3/getting-started/glossary#otp) to the mobile number registered against a facility, then validates it. This proves control of a facility record you did not create | Base URLs for every call on this page are on [NHPR](/docs/hiecm/v3/registries/nhpr). ## Request and response formats This page gives what a facility record holds and the order the calls go in. Take the request and response shapes from the health facility registry sandbox documentation alongside it. Two paths are fixed here: | Call | Path | | ------------------- | --------------------------------- | | Fetch facility type | `v1.5/facility/fetchfacilitytype` | | Get specialities | `/v1.5/facility/get-specialities` | ## Next - [HPR](/docs/hiecm/v3/registries/nhpr/hpr), which issues the token these calls need. - [NHPR](/docs/hiecm/v3/registries/nhpr), the parent page. - [the HPR and HFR call list](/docs/hiecm/v3/api/m4/undocumented), parameter tables and `HIS-` error codes. - [M2, linking and sharing](/docs/hiecm/v3/api/m2), which needs this facility ID. --- # HPR, the professional registry [HPR](/docs/hiecm/v3/getting-started/glossary#hpr) is the Healthcare Professionals Registry, the people half of [NHPR](/docs/hiecm/v3/registries/nhpr) alongside the [HFR](/docs/hiecm/v3/registries/nhpr/hfr). Registering there issues the professional an [HPID](/docs/hiecm/v3/getting-started/glossary#hpid), their identity everywhere in [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm). ## Who can enrol Three categories today, with more to be added later: doctor, nurse and pharmacist. Each professional also declares a system of medicine, from modern medicine, dentistry, Ayurveda, Unani, Siddha, Homoeopathy, Sowa-Rigpa, and yoga and naturopathy. A person can also enrol as a facility manager instead of a clinician, set by the role code: | Role code | What the person is | | --------- | -------------------------------------------- | | 1 | Healthcare Professional | | 2 | Facility Manager | | 3 | Healthcare Professional and Facility Manager | If nobody in your organisation holds role 2 or role 3, you cannot register a facility. See [HFR](/docs/hiecm/v3/registries/nhpr/hfr). ## The HPID A unique 14 digit, Aadhaar authenticated identifier issued on successful registration to a healthcare professional or facility manager. It is written both ways, HPID and HPR ID. Like an [ABHA](/docs/hiecm/v3/registries/abha), it comes in two forms: | Form | Sample | Where it is used | | ----------- | ------------------- | ------------------------------------------------- | | The number | `71-2665-5777-XXXX` | Sent as `hpId` or `hprIdNumber` | | The address | `name@hpr.abdm` | Sent as `hprId`, with `domainName` of `@hpr.abdm` | The professional chooses the readable part through a username suggestion call, the same pattern as the ABHA address suggestion in [M1](/docs/hiecm/v3/api/m1). ## What identifies a doctor An HPID on its own is an authenticated person; the profile behind it makes them a doctor. The register professional call groups it in five blocks: | Block | What it holds | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Personal information | Salutation and name, date of birth, gender, nationality, languages spoken, profile photo, official mobile and email | | Communication address | Country, state, district, sub district, city and pincode, all as master data codes. Skipped if the address matches the [KYC](/docs/hiecm/v3/getting-started/glossary#kyc) address | | Registration | The council the professional is registered with, the registration number, the registration certificate, and whether the registration is permanent or renewable | | Qualification | Degree or diploma obtained, college, university, year of award, and the degree certificate | | Current work | Whether they are working, the purpose of that work, whether it is private, government or both, and the facility they work at | Three codes decide what the professional may be. **Category** says doctor, nurse or pharmacist. **Subcategory** fixes the system of medicine. The **degree code** must agree with both. The tables for all three are on [the HPR and HFR call list](/docs/hiecm/v3/api/m4/undocumented). The subcategory codes differ between two calls Subcategory codes differ between the create HPID and register professional tables. Fetch the codes from the HPRID subcategories master call rather than hard coding either table. The SMD ID identifies doctors only. Searching for nurse colleges by SMD returns a null college and university name, and this is expected: for nurses, SMD is always null. ## The registration journey Two halves, in order. Nothing in the second works until the first produces a token. **Half one, create the HPID.** Nine calls follow the gateway session token, in this order: 1. Generate Aadhaar link 2. Check Aadhaar authentication status 3. Verify OTP and fetch user details 4. Check whether an HPID already exists for this Aadhaar 5. Mobile match 6. Generate mobile OTP 7. Verify mobile OTP 8. Username suggestions 9. Create HPID The last returns the HPID and an `hprToken`, which the next call needs. **Half two, register the professional.** Register professional writes the full profile, and it is the one HPR write call with a published path: `POST https://apihspsbx.abdm.gov.in/v4/int/apis/v1/doctors/register-professional-new`. Then retrieve professional document list, upload documents, update professional and fetch professional details. Three things to know first: - The Aadhaar link URL is valid for 5 minutes only. Call the API again once it expires. - `degreeCertificate` and `registrationCertificate` are mandatory uploads, and `proofOfWorkCertificate` is mandatory when the professional is government or both. - Call `demographicAuthViaMobile` first, and generate the mobile OTP only when it returns false. Call by call, with the parameters, is on [M4 user journey](/docs/hiecm/v3/milestones/m4) and [the HPR and HFR call list](/docs/hiecm/v3/api/m4/undocumented). ## Getting an HPR token later The `hprToken` from creation does not last. Three ways to get a fresh one, all still carrying the gateway access token in the `Authorization` header, because the HPR token proves who the professional is, not that your client may call. | Route | Path | | ---------------------- | ----------------------------------------------- | | By password | `/v4/int/api/v1/auth/authPassword` | | By mobile OTP, send | `/v4/int/api/v2/auth/loginViaMobileSendOTP` | | By mobile OTP, log in | `/v4/int/api/v2/auth/login/userAuthorizedToken` | | By Aadhaar OTP, send | `/v4/int/api/v1/auth/init` | | By Aadhaar OTP, verify | `/v4/int/api/v1/auth/confirmWithAadhaarOtp` | The bodies are on [M4 operations and fields](/docs/hiecm/v3/api/m4/undocumented). The mobile verify path is not yet published. ## What your system has to hold Per professional, store: - The HPID, in both forms. - The current HPR token, its expiry, and a way to refresh it without re-registering the person. - The transaction id, for one flow only. - The master data ids you sent for council, course, college, university, language, country, state and district. The registry rejects display values. - The certificates you uploaded, with each document slot identifier. Once, for the whole integration: client id and client secret for the gateway session call, and the public certificate from `v4/int/api/v1/auth/cert`. Three fields are encrypted with it, cipher `RSA/ECB/PKCS1Padding`: the mobile number in mobile match, the OTP in mobile login, and the email and password in create HPID. That cipher and that certificate belong to the NHPR. M1 encrypts with RSA-OAEP and SHA-1 under the ABHA certificate, so the two paths are not interchangeable. Upload limits: 1 MB for a profile photo, 5 MB for anything else, png, jpeg, jpg or PDF only. Attachments go as a `fileType` and a base64 `data` string. ## Request and response formats This page gives the behaviour, the call order, the parameter tables and the code lists. Take the request and response shapes from the healthcare professional registry sandbox documentation alongside it. Seven of the 17 master data calls have their path published here: see [the HPR and HFR call list](/docs/hiecm/v3/api/m4/undocumented). ## Next - [HFR](/docs/hiecm/v3/registries/nhpr/hfr), the facility half, which needs a token from this registry. - [NHPR](/docs/hiecm/v3/registries/nhpr), the parent page. - [M4 user journey](/docs/hiecm/v3/milestones/m4), the same order as diagrams. - [the HPR and HFR call list](/docs/hiecm/v3/api/m4/undocumented), the parameter tables and the error codes. --- # NHPR, the provider registries NHPR is the provider half of [Registries](/docs/hiecm/v3/registries), and the name covers the pair underneath it: the [HPR](/docs/hiecm/v3/getting-started/glossary#hpr) for people and the [HFR](/docs/hiecm/v3/getting-started/glossary#hfr) for places. This page carries what they share and forks to each. They are separate because a doctor holds one identity for a career across many facilities, while a facility sees many professionals pass through. Keeping them apart lets each change without rewriting the other, and lets [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) answer two questions: who wrote this, and where was it written. ## Which one you need, and when | You need | When | | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | An [HPID](/docs/hiecm/v3/getting-started/glossary#hpid) on the HPR | Before anything else in NHPR. The HFR create call carries an HPR token in the header, generated from an HPR ID and password | | A facility ID on the HFR | Before the facility goes live as a [HIP](/docs/hiecm/v3/getting-started/glossary#hip) or an [HIU](/docs/hiecm/v3/getting-started/glossary#hiu). A valid facility ID is a prerequisite for sharing records at all | | A bridge linked to the facility | Last. It is what makes your software resolvable as that facility on the network | ## Base URLs Both registries share one set: ```text Sandbox https://apihspsbx.abdm.gov.in/v4/int/Production https://apinhpr.abdm.gov.in/v4/int/ ``` The session token that authorises them comes from the HIE-CM gateway, not from NHPR. [M4](/docs/hiecm/v3/api/m4) is the only milestone in [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) that writes to NHPR, and its endpoints, parameter tables and error codes are on [M4 operations and fields](/docs/hiecm/v3/api/m4/undocumented). ## Next - [HPR](/docs/hiecm/v3/registries/nhpr/hpr): the HPID and the registration journey. - [HFR](/docs/hiecm/v3/registries/nhpr/hfr): the facility record, the five call onboarding sequence, bridge linkage. - [ABHA](/docs/hiecm/v3/registries/abha), the patient side. - [M4 API reference](/reference/hiecm-m4). --- # Developer resources What helps you build against [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm), beside the contract itself. The contract is in [API references](/docs/hiecm/v3/api): the calls, the fields, the errors. ## Testing use cases [Testing use cases](/docs/hiecm/v3/resources/testing/) are what this tab holds today. They are the cases an integration is tested against, one page per module, each keeping the id it carries at certification. More resources land here as they are written. ## Next - [Testing use cases](/docs/hiecm/v3/resources/testing/), starting with [M1](/docs/hiecm/v3/resources/testing/m1). - The calls each case exercises: [API references](/docs/hiecm/v3/api). --- # Testing use cases Every [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) module has a set of cases your integration is tested against. They are listed here, one page per module, and each case keeps the id it carries at certification. ## Where you run them You run these cases against the [sandbox](/docs/hiecm/v3/getting-started/glossary#sandbox), on sandbox credentials. [Get your sandbox credentials](/docs/hiecm/v3/getting-started/sandbox) covers registration, the client id and secret, the callback URL and the base URLs. Three things about the sandbox decide how a case behaves: - **It runs on its own hosts, under its own credentials.** A production client id against a sandbox host fails, and so does the reverse. [Go live](/docs/hiecm/v3/getting-started/going-live) lists both sets. - **Nothing in it is a real person or a real record.** Every identity a case needs is one you create in an earlier case. - **Passing every case is not certification.** Functional testing is run by an empanelled agency as part of the sandbox exit process. Passing here is how you arrive at that ready. ## How to read a case Each case is one row. Open it for the detail and the calls it exercises. | Column | What it holds | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Id | The id you will be asked about at certification, such as `CRT_ABHA_101`. Quote it when you report a result or ask about a case. | | Type | Mandatory, Optional or Conditional. A conditional case names the condition it applies under. A few cases carry no marking at all and read as Unmarked, which is how they arrive. | | Functionality | What the case exercises, in one line. | | Expected result | What your system has to be able to show. | One type is this portal's own: **Portal check**. A case marked Portal check is a suggestion rather than a requirement, and skipping one costs you nothing at certification. Each covers a failure path the mandatory cases leave untested, which is where an integration usually breaks after it is live. ## The four modules | Module | What the cases cover | Certification cases | Portal checks | | ----------------------------------------- | ---------------------------------------------------------------------- | ------------------- | ------------- | | [M1](/docs/hiecm/v3/resources/testing/m1) | ABHA creation, verification, profile and share | 66 | 56 | | [M2](/docs/hiecm/v3/resources/testing/m2) | Care context linking, and sharing the records you hold | 36 | 10 | | [M3](/docs/hiecm/v3/resources/testing/m3) | Consent requests, and fetching records you did not create | 16 | 16 | | [M4](/docs/hiecm/v3/resources/testing/m4) | Facility registration in the HFR, professional registration in the HPR | 184 | None | ## Cases that expect a callback In M1 the answer comes back in the response to your call. In M2 and M3 it does not. The response acknowledges your request, and the answer arrives afterwards as a POST to the callback URL you registered. A case that expects a callback needs that URL reachable from the public internet and listening, whether or not you are ready for the answer. In development that usually means a tunnel, and a tunnel gives you a new URL every restart. Register the new one each time. [Get your sandbox credentials](/docs/hiecm/v3/getting-started/sandbox) covers what the URL has to do. ## Next - Start with [M1](/docs/hiecm/v3/resources/testing/m1). - The calls each case makes: [API references](/docs/hiecm/v3/api). - What happens once they pass: [Go live](/docs/hiecm/v3/getting-started/going-live). --- # M1 testing use cases [M1](/docs/hiecm/v3/milestones/m1) is the identity milestone, so its cases are about creating an [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) and proving it belongs to the person in front of you. Four creation routes are covered end to end: Aadhaar [OTP](/docs/hiecm/v3/getting-started/glossary#otp), Aadhaar biometric, demographic authentication, and driving licence or PAN. Verification, fetching details by Aadhaar number, the ABHA QR code, profile read and update, and profile sharing follow. One case is about your own system rather than ours: one ABHA number resolves to one patient record in it. Demographic authentication is open to trusted entities, so its cases apply only if you are one. 66 are certification cases, and each keeps the id you will be asked about at certification. 56 are Portal checks, which are suggestions rather than requirements. Search cases, endpoints, results M1ABHA identity, registration and login122 cases Use caseEndpointsExpected result ## Next - The calls these cases make: [M1 API reference](/docs/hiecm/v3/api/m1). - The build order behind them: [M1 Create](/docs/hiecm/v3/milestones/m1). - The next module: [M2 testing use cases](/docs/hiecm/v3/resources/testing/m2). --- # M2 testing use cases [M2](/docs/hiecm/v3/milestones/m2) attaches the records you hold to a person's [ABHA](/docs/hiecm/v3/getting-started/glossary#abha), then shares them when a [consent artefact](/docs/hiecm/v3/getting-started/glossary#consent-artefact) allows it. Whoever holds a record and publishes it is the [HIP](/docs/hiecm/v3/getting-started/glossary#hip). The cases cover creating a health record, then linking its [care context](/docs/hiecm/v3/getting-started/glossary#care-context) on five routes: mobile [OTP](/docs/hiecm/v3/getting-started/glossary#otp), Aadhaar OTP, direct authentication, demographic authentication, and linking the person starts themselves. The deep link notification, consent grant, revoke and expiry, and the data transfer close the set. 36 are certification cases, and each keeps the id you will be asked about at certification. 10 are Portal checks, which are suggestions rather than requirements. Cases here expect callbacks. Register a callback URL before you start. Search cases, endpoints, results M2Care context linking and data sharing46 cases Use caseEndpointsCallbacksExpected result ## Next - The calls these cases make: [M2 API reference](/docs/hiecm/v3/api/m2). - The build order behind them: [M2 Attach](/docs/hiecm/v3/milestones/m2). - The next module: [M3 testing use cases](/docs/hiecm/v3/resources/testing/m3). --- # M3 testing use cases [M3](/docs/hiecm/v3/milestones/m3) is about asking for records you did not create. Whoever asks is the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu). The cases follow one consent request through its whole life. You discover the patient, raise the request against their [ABHA address](/docs/hiecm/v3/getting-started/glossary#abha-address), and handle each outcome the person can choose. A granted request is then fetched against, one case per [HI type](/docs/hiecm/v3/getting-started/glossary#hi-type). Revoking the [consent artefact](/docs/hiecm/v3/getting-started/glossary#consent-artefact) and letting it expire close the set. 16 are certification cases, and each keeps the id you will be asked about at certification. 16 are Portal checks, which are suggestions rather than requirements. Most of these cases expect a callback. Register a callback URL before you start. Search cases, endpoints, results M3Consent management and health record fetch32 cases Use caseEndpointsCallbacksExpected result ## Next - The calls these cases make: [M3 API reference](/docs/hiecm/v3/api/m3). - The build order behind them: [M3 Retrieve](/docs/hiecm/v3/milestones/m3). - The next module: [M4 testing use cases](/docs/hiecm/v3/resources/testing/m4). --- # M4 testing use cases [M4](/docs/hiecm/v3/milestones/m4) enrols the facility and the people who work in it. A facility is registered in the [HFR](/docs/hiecm/v3/getting-started/glossary#hfr) and gets a facility id; a professional is registered in the [HPR](/docs/hiecm/v3/getting-started/glossary#hpr). This is the largest set, 184 cases, and it is field level. Search comes first, so an existing facility is found rather than duplicated. Registration then runs in four calls, basic, additional, detailed and submit, and each has its own cases for what every field accepts and rejects. The update calls repeat that set against a facility that already exists. Bridge linkage, professional registration in the HPR, and document upload close it. Every case here is a certification case, and each keeps the id you will be asked about at certification. Search cases, endpoints, results M4HPR and HFR registration184 cases Use caseEndpointsExpected result ## Next - The calls these cases make: [M4 API reference](/docs/hiecm/v3/api/m4). - The build order behind them: [M4 Enrol](/docs/hiecm/v3/milestones/m4). - What happens once every module passes: [Go live](/docs/hiecm/v3/getting-started/going-live). --- # Accepted, then nothing You started an M2 flow, one or more calls came back accepted, and then it stalled. Discovery and care context linking are chains of several calls with a callback between each pair, and the flow looks broken from the outside whichever link in that chain is missing, so you have to find which one. Before working through the checks, know which flow you are in. [Discovery](/docs/hiecm/v3/getting-started/glossary#discovery) is whoever asks to read records, in the [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) direction, looking for what your facility holds: a patient's [PHR](/docs/hiecm/v3/getting-started/glossary#phr) app, another facility, an insurer or a referral service. Linking is you attaching a [care context](/docs/hiecm/v3/concepts/linking) to a patient's [ABHA address](/docs/hiecm/v3/getting-started/glossary#abha-address). You also need the `REQUEST-ID` from the call where the chain started: every callback in the chain should carry it, so it is what lets you find where the chain broke. ## Work through these in order 1. **Discovery request.** Your discovery call should produce an inbound discovery request callback to your bridge. If this never arrives, the problem sits upstream of your system entirely; escalate rather than continuing down this list. 2. **Link initiation.** Starting a link should produce an inbound link init callback. If discovery completed but this never arrives, the stall is at the handoff into linking. 3. **Link confirmation.** Do not treat the synchronous acknowledgement to your link request as success. The confirmation arrives as a separate callback to your registered URL, and the care context only becomes visible in the patient's PHR app once it does. See [linking](/docs/hiecm/v3/concepts/linking) for the full sequence. 4. **`REQUEST-ID` reuse.** If you generated the same `REQUEST-ID` for more than one call in the chain, or reused one from an earlier attempt, responses and callbacks can no longer be told apart. Generate a fresh one per call. Before assuming any step above is genuinely missing, rule out a callback URL problem first: [the callback never arrives](/docs/hiecm/v3/troubleshooting/callback-never-arrives) covers registration and reachability, which is more common than the gateway itself failing to send. ## How you know it worked For linking, the care context appears when the patient's PHR app runs discovery against your facility, after the link confirm callback reports success. For discovery, your system answers the inbound discovery callback with the care contexts you hold for that patient. ## When it goes wrong If you have identified which callback in the chain is missing and ruled out a callback URL problem, escalate on the [NHA dev forum](https://devforum.abdm.gov.in). Report which step of the chain stopped, the `REQUEST-ID` from the call that started it, the `TIMESTAMP`, and every response and callback body you did receive up to the point it stalled. See [Support](/docs/support) for the full report format. This symptom can surface as a duplicate or invalid link reference, or a call made out of the logical sequence, both on the [M2 errors reference](/docs/hiecm/v3/api/m2/errors). [Next Still stuck? Check the M2 user journey Confirm exactly where your call sits in the sequence, and which callback should follow it.](/docs/hiecm/v3/milestones/m2) --- # The callback never arrives You made a call, it came back with a 202 or a 200, and nothing else has happened since. This is a common report in [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) integration. The checks below are in the order we recommend, not a record of how often each has turned out to be the actual cause. That early response only means the [NHA](/docs/hiecm/v3/getting-started/glossary#nha) gateway accepted your request. In M2 and M3 the real answer arrives later, as a POST from the gateway to a URL you registered in advance. See [the gateway](/docs/hiecm/v3/concepts/gateway) for why this is the normal shape of these flows, and the [API reference](/docs/hiecm/v3/api), where each call names the callback it produces. ## Work through these in order 1. **Is the callback URL registered with the gateway?** Confirm it with the [update bridge callback URL](/docs/hiecm/v3/api/gateway/endpoints/gateway-update-bridge-url) call. Setting a URL in a console once is not the same as confirming the gateway has it. 2. **Is that URL reachable from the public internet over HTTPS?** ABDM posts to it from outside your network. A URL that only answers on your local machine or behind a VPN will never receive anything, and the original call gives you no signal that this is wrong. 3. **Did the request expire before the other party answered?** How long a request stays live before ABDM gives up is not documented yet. If you have waited what feels like a long time, say so when you escalate rather than assuming a fixed window. 4. **Is your endpoint returning a non success status?** A handler that errors, times out, or is slow is a real problem. Whether and when delivery attempts stop is not documented yet. Deliveries can repeat, so your handler has to treat every one as possibly a retry of one it already handled. Respond quickly with a success status even before you have finished processing the callback body. ## How you know it worked Your handler receives a POST at your registered URL, carrying the exact `REQUEST-ID` you generated for the original call. Until you have observed that once, the callback path is unproven, even if the registration call itself succeeded. ## When it goes wrong If all four checks pass and the callback still has not arrived, escalate on the [developer forum](https://devforum.abdm.gov.in). Report the API you called, the `REQUEST-ID`, the `TIMESTAMP`, and the response you got. See [Support](/docs/support) for the full report format. This symptom can surface as [ABDM-9999](/docs/hiecm/v3/reference/error-codes), the catch-all for a failure the gateway does not explain further. [Next Still stuck? Check the M2 user journey Confirm which step of the sequence your call sits in, so you know which callback should follow it.](/docs/hiecm/v3/milestones/m2) --- # Consent stuck in Requested You raised a consent request and it has not moved to Granted or Denied. Requested is the starting state of the consent request itself, not of the [consent artefact](/docs/hiecm/v3/getting-started/glossary#consent-artefact) it can produce: the artefact is created only once the patient grants. Nothing has failed yet, the patient has not yet acted, or something kept them from ever seeing it. See [Consent, two objects, not one](/docs/hiecm/v3/concepts/consent#two-objects-not-one) for the full state model. Before working through the checks, confirm the request itself was accepted, and check its current state rather than only waiting: the [M3 API reference](/docs/hiecm/v3/api/m3) documents the consent request status call. ## Work through these in order 1. **Does the patient's app show the request at all?** The gateway notifies the patient through the ABHA App when a consent request is raised. If the patient uses a third party PHR app instead, that app needs an approved subscription with the gateway to be notified of a new consent request; without one, the request can sit unseen even though it was accepted. Whether the ABHA App itself needs anything set up beyond the patient having an address is not something we have confirmed. 2. **Has the request expired?** A consent request carries a window the requester sets for the patient to respond, separate from how long access lasts once granted. See [Consent](/docs/hiecm/v3/concepts/consent#the-states-a-consent-moves-through) for the two clocks. Running out of the request window moves the state to Expired, not Requested, so checking the current status tells you if this has already happened. 3. **Was it raised against the right ABHA address?** An address that is malformed or does not exist produces an error and the request goes nowhere. A syntactically valid address that belongs to a different real patient will not error at all: the request is delivered and seen, just by the wrong person, not the one you meant. Getting the address right matters more than passing validation. ## How you know it worked The consent request status reports Granted or Denied rather than Requested. A Granted result also carries the id of at least one consent artefact, and a granted request can produce more than one. ## When it goes wrong If the patient's app shows the request, it has not expired, and the address is correct, and the state is still Requested after a reasonable wait, this is expected: Requested means the patient has not decided yet, and there is no call that makes them decide faster. If you believe the patient acted and the state did not change, escalate on the [NHA dev forum](https://devforum.abdm.gov.in). Report the consent request id, the `REQUEST-ID` from the init call, the `TIMESTAMP`, and the status response. See [Support](/docs/support) for the full report format. This symptom can surface as an invalid or non-existent ABHA address on the [error codes reference](/docs/hiecm/v3/reference/error-codes). [Next Still stuck? Read Consent end to end The full state model, the two clocks, and who holds what.](/docs/hiecm/v3/concepts/consent) --- # Everything returns 401 Every call fails the same way, on every endpoint, not just one. That pattern points at your session or your headers, not at any single operation. Before working through the checks, confirm more than one endpoint is actually failing. If only one call fails while others succeed, read that call's own error code on the [error codes reference](/docs/hiecm/v3/reference/error-codes) instead. Read the response body too, not only the status: the gateway returns a code that names the real reason. ## Work through these in order 1. **Has your session token expired?** Session tokens are short lived. Read `expiresIn` from the sessions call response rather than assuming a duration, and re-run it for a fresh token instead of retrying the failing call with the old one. See [authentication](/docs/hiecm/v3/reference/authentication). 2. **Are you calling the wrong environment's base URL?** A sandbox token is not valid against a production base URL, or the reverse. Look at the host in the failing request and the host you requested the session token from, side by side. If they differ, point every call at the same host you authenticated against. 3. **Is your clock wrong?** The `TIMESTAMP` header has to be close to the gateway's own clock, in ISO 8601 UTC. A container host that was suspended and resumed is the usual cause, because its clock resumes behind. See [authentication](/docs/hiecm/v3/reference/authentication). 4. **Is `X-CM-ID` missing or wrong for this environment?** Look at the literal value you sent, not the value you meant to send: `sbx` on the sandbox, `abdm` in production. This header names the consent manager you are pointed at, and the wrong value fails every call the same way a missing session token does. ## How you know it worked A call that was returning 401 now returns its normal response, and stays that way across more than one call in a row. A single success right after several failures can be a token that was about to expire anyway; confirm with a second call a minute or more later. ## When it goes wrong If you have re-run the session call, confirmed the environment, fixed the clock, and confirmed `X-CM-ID`, and calls still return 401 with no matching code, escalate on the [NHA dev forum](https://devforum.abdm.gov.in). Report the API you called, the `REQUEST-ID`, the `TIMESTAMP`, and the full response body. See [Support](/docs/support) for the full report format. The codes this symptom can surface are on the [error codes reference](/docs/hiecm/v3/reference/error-codes): an invalid timestamp, the wrong consent manager id, a missing session token, or a required header that is absent or malformed. [Next Still stuck? Read authentication end to end Every header a call needs, and what the gateway does when one is wrong.](/docs/hiecm/v3/reference/authentication) --- # When something breaks Find the symptom you are seeing. Every page here walks the checks in the order this catalogue recommends checking, not a record of how often each has turned out to be the actual cause, so you do not need to know an error code to start. - [The callback never arrives](/docs/hiecm/v3/troubleshooting/callback-never-arrives): a call returned 202, and nothing followed on your registered URL. - [Everything returns 401](/docs/hiecm/v3/troubleshooting/everything-returns-401): every call fails the same way, not just one endpoint. - [The OTP never arrives](/docs/hiecm/v3/troubleshooting/otp-never-arrives): you requested an OTP and nothing reached the phone. - [Accepted, then nothing](/docs/hiecm/v3/troubleshooting/accepted-then-nothing): discovery or linking started and stalled somewhere in the middle. - [Consent stuck in Requested](/docs/hiecm/v3/troubleshooting/consent-stuck-requested): a consent request never moved to Granted or Denied. If your symptom is not here, or you already have an error code in hand, the [error codes reference](/docs/hiecm/v3/reference/error-codes) is organised the other way, by code. --- # The OTP never arrives You called the request OTP operation, got back a `txnId`, and the phone you are watching has not received an [OTP](/docs/hiecm/v3/getting-started/glossary#otp). Before working through the checks, confirm the request call itself succeeded and returned a `txnId`. If it failed, work through [Everything returns 401](/docs/hiecm/v3/troubleshooting/everything-returns-401) or the code the response names on the [error codes reference](/docs/hiecm/v3/reference/error-codes) instead. ## Work through these in order 1. **Is this the Aadhaar mobile, and are you holding it?** In the Aadhaar OTP enrolment flow, only the mobile number registered against that Aadhaar number receives the OTP. That is not necessarily the phone the person is holding while they enrol. See the [M1 user journey](/docs/hiecm/v3/milestones/m1) for the full enrolment sequence, and confirm which number Aadhaar has on file before assuming delivery failed. 2. **Have you requested an OTP for this transaction more than a few times in a short window?** You may have been rate limited. A retry loop that fires the request call again on every failure can trigger this without the failure showing clearly in your own logs, because a rate limit response can read like a plain timeout depending on how your client surfaces it. 3. **Has the transaction expired before you tried to verify it?** How long a `txnId` stays valid is not documented yet. A failed enrolment call should not be retried blindly: start a fresh OTP request rather than reuse an old `txnId` if enough time has passed that you are unsure it is still live. ## How you know it worked The phone registered against the identifier you sent receives an SMS carrying an OTP, and verifying it with that `txnId` succeeds. Receiving a `txnId` from the request call alone does not confirm the SMS was sent. ## When it goes wrong If you have confirmed the receiving number, are not rate limited, and the transaction is fresh, and the OTP still has not arrived, escalate on the [developer forum](https://devforum.abdm.gov.in) rather than requesting again. Report the API you called, the `REQUEST-ID`, the `TIMESTAMP`, and the full response body including the `txnId`. See [Support](/docs/support) for the full report format. This symptom can surface as a rate limit code or the catch-all failure code, both on the [error codes reference](/docs/hiecm/v3/reference/error-codes). [Next Still stuck? Walk the M1 user journey See exactly where the OTP request sits among the calls that create an ABHA.](/docs/hiecm/v3/milestones/m1) --- # NHCX API reference No specification is published here for NHCX, and no endpoint on this gateway has been documented here yet. [The NHCX introduction](/docs/nhcx/v1) lists what the documentation set covers, so you can see what exists and where it lives. --- # Core concepts This page records what the NHCX documentation set covers. An index is not a specification: it names what each document covers without describing it. Nothing here has been read from a payload or run against the exchange, and the rows are cited so you can go to the source. ## A claim is a FHIR bundle [FHIR](/docs/nhcx/v1/getting-started/glossary#fhir) is the format ABDM uses for clinical data, and NHCX uses it for claims. Row 11 of [the index](/docs/nhcx/v1) holds which bundle to use per use case, which value sets to build it from and which values are mandatory, one tab per use case. Row 14 is the FHIR implementation guide covering both ABDM and NHCX. Row 2 introduces the standards. A claim being FHIR does not make it a health record. Records move on [HIE-CM](/docs/nhcx/v1/getting-started/glossary#hie-cm), under a consent artefact, and a claim carries no consent of its own. ## A workflow status travels in the protected header Each message carries a protected header, and in it a workflow status code that says where the request has reached. Row 12 is the sheet of those codes. It is updated when codes change, which means the codes are data your integration should read rather than constants to compile in. ## A request cycle is closed by a protocol response A call is not finished when it is accepted. The sender has to send a protocol response back to close the cycle. Row 15 covers that, together with how to handle error scenarios. Row 18 is the sheet of every error code and scenario, by use case, for the bridge and for NHCX. ## The two ends and the exchange A provider submits, a payer adjudicates, NHCX routes. Rows 9 and 10 hold the use cases each side must cover for sandbox exit: which API, at whose end, which bundle, which status and the callback logic. Row 8 covers policy linking and de-linking for a payer or TPA. Row 19 is the dummy payer implementation, which is what a provider tests against before a real payer exists. ## Tokens and keys Row 3 covers generating a token with the ABDM API for the NHCX APIs, so the session is ABDM's, not a separate one. Row 20 covers generating the encryption certificate, a public and private key pair. ## What is missing No endpoint, no request shape, no response shape and no test case for this gateway is documented in this portal. Row 23 is the Swagger for the use case APIs and the participant service, and it is the first thing to read when this section is filled in. ## Next - [Registries](/docs/nhcx/v1/registries), who is registered on NHCX - [NHCX](/docs/nhcx/v1), the full document index --- # Glossary Every term the NHCX documentation links to. Each row keeps its own anchor. NHCX's own vocabulary, the claim objects and the workflow status codes, is not documented here: no NHCX endpoint has been read yet, so there is nothing to define that would not be a guess. [The introduction](/docs/nhcx/v1) records which documents hold it. ## Across ABDM These terms mean the same thing on every ABDM gateway. ### ABDM Ayushman Bharat Digital Mission, India's national programme for digital health, run by the [NHA](#nha). ABDM sets the identifiers, the registries and the exchange rules that let a health record move from the system that created it to the person it belongs to. ### ABHA Ayushman Bharat Health Account. It comes in two forms people confuse: the 14 digit [ABHA number](#abha-number) and the readable [ABHA address](#abha-address). When a document says "the patient's ABHA", work out which of the two it means before you write code against it. ### ABHA address A readable name on the [HIE-CM](#hie-cm), such as `name@abdm`, used to reach health records and share them with a provider. Every ABHA number is issued a default address made from the number itself: `14digit@sbx` in [sandbox](#sandbox), `14digit@abdm` in production. A person can also create an ABHA address without holding an ABHA number, using mobile number, name, age and gender. ### ABHA number A 14 digit identifier issued to a person only after a [KYC](#kyc) check passes, and the identity anchor of ABDM: one person, one number. An ABHA number carries a check digit and validates under the Luhn algorithm. See [M1](/docs/hiecm/v3/getting-started/glossary#m1) for how one is created. ### FHIR Fast Healthcare Interoperability Resources, the HL7 standard ABDM uses to carry health records. ABDM uses FHIR R4 with the profiles published by NRCES at [nrces.in/ndhm/fhir/r4](https://nrces.in/ndhm/fhir/r4/index.html). Every record you share travels as a FHIR bundle of type `document` whose first entry is a Composition. ### Gateway The routing layer for ABDM: you do not call another participant directly, you call the gateway, it forwards your request, and the reply arrives at your [bridge](/docs/hiecm/v3/getting-started/glossary#bridge) as a separate inbound call. You get a session token first, by posting your client id and client secret to `/api/hiecm/gateway/v3/sessions`. Two sandbox hosts serve that path, `https://apissbx.abdm.gov.in` and `https://dev.abdm.gov.in`. Take the host from your onboarding documentation and keep it in configuration; see [Choose your gateway](/docs/hiecm/v3). ### Health Tech Committee The committee that reviews your integration at the end of the sandbox exit process, referred to as the HTC. Once your functional testing, security audit and exit form are complete, it is scheduled its own demonstration, separate from the one you give the integration team earlier. Its decision is recorded in four review stages, each carrying its own reviewer, comment and date. See [Go live](/docs/hiecm/v3/getting-started/going-live). ### HFR Health Facility Registry, the national directory of health facilities across modern and traditional systems of medicine, public and private, including hospitals, clinics, diagnostic laboratories, imaging centres and pharmacies. A facility enrols once and receives a facility ID that identifies it everywhere in ABDM. See [registries](/docs/hiecm/v3/registries). ### HIE-CM Health Information Exchange and Consent Manager, the component that routes exchange requests and manages patient consent. It is data blind: it holds identifiers and metadata about [care contexts](/docs/hiecm/v3/getting-started/glossary#care-context), never the content of a record. See [The ABDM gateway](/docs/hiecm/v3/concepts/gateway). ### HPID Healthcare Professional ID: a 14 digit number issued to a healthcare professional or a facility manager after Aadhaar authentication. It is the professional's digital identity across ABDM, and it is created on the [HPR](#hpr). See [M4](/docs/hiecm/v3/getting-started/glossary#m4). ### HPR Healthcare Professionals Registry, the national registry of doctors, nurses, pharmacists and other healthcare professionals. Registering a professional there issues an [HPID](#hpid). The HPR token is also used when onboarding a facility to the [HFR](#hfr). ### KYC Know Your Customer: the identity check that must pass before an [ABHA number](#abha-number) is issued. In ABDM the check runs against Aadhaar, by one of four methods: an [OTP](#otp) to the Aadhaar linked mobile number, face authentication, fingerprint or IRIS capture on a registered device, or a demographic match. Re-KYC repeats the check on an ABHA number that already exists. ### NHA National Health Authority, the government body that runs ABDM, publishes its specifications, and operates both the [sandbox](#sandbox) and the production gateways. ### NHCX National Health Claims Exchange, ABDM's network for insurance claims between providers and payers, with its own sandbox and its own document set at [hcxsbx.abdm.gov.in](https://hcxsbx.abdm.gov.in). See [NHCX](/docs/nhcx/v1). ### OTP One Time Password: a short code sent to a mobile number or an email address to prove the person holds it. ABDM uses OTPs at many points: Aadhaar [KYC](#kyc), mobile number verification during ABHA creation, and login. An OTP is always paired with a transaction id from the call that requested it. ### PHR Personal Health Record, a patient facing application: the person logs in with their [ABHA address](#abha-address), discovers records held by facilities they visited, links them, and reads them. PHR apps subscribe to a patient's ABHA address and are notified when a new [care context](/docs/hiecm/v3/getting-started/glossary#care-context) is linked. See [PHR applications](/docs/hiecm/v3/concepts/phr). ### Safe to Host certificate The certificate a [WASA](#wasa) produces, issued by a CERT-In empanelled auditor, and required before you receive production credentials. It names the application it covers and carries an issue date and an expiry date. A certificate that is in date covers a new module without a fresh audit of the parts already certified. See [Security audit](/docs/hiecm/v3/getting-started/security-audit). ### Sandbox The ABDM test environment, and where every integration starts: you register on the sandbox portal, declare your role and the milestones you plan to complete, and receive a client id and client secret. Sandbox hosts differ from production, so ABHA calls go to `abhasbx.abdm.gov.in` in sandbox and `abha.abdm.gov.in` in production. Everything in sandbox is test data; see [Get started](/docs/hiecm/v3/getting-started/sandbox). ### txnId Transaction id. Most flows take two or three calls, and the first one returns a `txnId` that the calls after it send back, so ABDM knows which attempt they belong to. It is short lived and single purpose. It is not a session and it is not a token: holding a `txnId` does not authenticate you, and it stops working once the flow it belongs to finishes or expires. ### UHI Unified Health Interface, an open protocol network for health services that are not record exchange: physical consultation booking, ambulance booking, blood bank discovery, Jan Aushadhi and pharmacy search. It has two roles, [EUA](/docs/uhi/v1/getting-started/glossary#eua) on the consumer side and [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) on the provider side, and every call is signed with Ed25519. See [UHI](/docs/uhi/v1). ### WASA The security audit of your application, conducted on your staging URL by an auditor from the CERT-In empanelled list. It produces the [Safe to Host certificate](#safe-to-host-certificate), and it is separate from functional testing: passing every milestone still leaves this to do. Each platform you ship is audited on its own. See [Security audit](/docs/hiecm/v3/getting-started/security-audit). --- # NHCX The Ayushman Bharat Digital Mission ([ABDM](/docs/nhcx/v1/getting-started/glossary#abdm)) is India's national health data network, run by the National Health Authority ([NHA](/docs/nhcx/v1/getting-started/glossary#nha)). It is three gateways, not one, and this section documents the third of them. [NHCX](/docs/nhcx/v1/getting-started/glossary#nhcx) is the National Health Claims Exchange, the third [ABDM](/docs/nhcx/v1/getting-started/glossary#abdm) gateway, carrying insurance claims and their responses between providers and payers. After this page you will know who is on NHCX and which of [NHA](/docs/nhcx/v1/getting-started/glossary#nha)'s own documents to open next. ## What is not here No endpoint on this gateway has been documented here yet. No endpoint reference, no sequence diagrams, no error tables, no test cases. The [HIE-CM](/docs/nhcx/v1/getting-started/glossary#hie-cm) and [UHI](/docs/nhcx/v1/getting-started/glossary#uhi) gateways are documented at [milestones](/docs/hiecm/v3/milestones) and [UHI](/docs/uhi/v1). NHCX sits outside both, on its own sandbox, with its own onboarding, participant registry and document set. NHCX does appear in the sandbox database. An NHCX application is recorded against your organisation, and the column list for it is the [`nhcx_exit` table](/docs/hiecm/v3/reference/data-dictionary#nhcx_exit). ## HIE-CM or NHCX Claims are not health records. If your product shares or fetches a patient's clinical record, you are on HIE-CM. If it submits or adjudicates an insurance claim, you are on NHCX. A hospital system can end up on both. The two integrations share no API surface. The documentation set shows the shape of a claim without describing it. A claim is a [FHIR](/docs/nhcx/v1/getting-started/glossary#fhir) bundle. It travels with a protected header that carries a workflow status code. A request cycle is closed by sending a protocol response back. Those are rows 11, 12 and 15 below. ## Who is on it | Participant | What it does | | ----------- | --------------------------------------------------------------------------------------------------------- | | Provider | A hospital or clinic. Row 9 below covers the use cases a provider has to implement. | | Payer | An insurer, or a third party administrator acting for one. Row 10 below is the matching list for a payer. | | NHCX | The exchange in the middle. Routes between registered participants. | Both providers and payers onboard as participants, in sandbox first and then in production. The production onboarding document carries the role and registry enums and the validations applied to them. ## What is published The NHCX documentation set has 32 numbered rows, each giving a purpose, a document name and a location. It is an index, not a specification. No row carries a request shape, a response shape or an endpoint. Two rows have no document name in the source, and one row is blank apart from its location. Those gaps are marked below. There is one location per group of documents, not a URL per file. | Location | What is there | | -------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | [hcxsbx.abdm.gov.in/#/documents](https://hcxsbx.abdm.gov.in/#/documents) | Onboarding, use cases, payload references, error handling, Postman collections and FAQs. Rows 1 to 22. | | [hcxsbx.abdm.gov.in/#/technical-specifications/api-specifications](https://hcxsbx.abdm.gov.in/#/technical-specifications/api-specifications) | Swagger for the use case APIs and the participant service. Row 23. | | [hcxsbx.abdm.gov.in/#/hmisdocuments](https://hcxsbx.abdm.gov.in/#/hmisdocuments) | The Supporting Documents section of that page holds the PMJAY and [HMIS](/docs/hiecm/v3/getting-started/glossary#hmis) material. Rows 24 to 32. | ## The document index Row numbers match the published index, so you can match a line here to a line there. ### Onboarding, use cases and specifications | # | Document | What it covers | | -- | ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | NHCX Usecases | High level introduction to the NHCX use cases. | | 2 | Standards for NHCX | Standards followed in NHCX, and an introduction to FHIR. | | 3 | Name not given in the source | How to generate a token using the ABDM API for the NHCX APIs. | | 4 | Onboarding providers and payers in Sandbox | How to onboard participants in sandbox. | | 5 | Onboarding providers and payers in Production | How to onboard participants in production. Includes the role and registry enums, and the validations imposed. | | 6 | AWS(Sandbox)NHCX-OnBoarding APIs Postman Collection | Postman collection for participant onboarding in sandbox. A zip file. | | 7 | AWS(PROD)\_NHCX-OnBoarding APIs Postman Collection | Postman collection for participant onboarding in production. A zip file. | | 8 | Policy Linking and De-Linking Process | Policy linking and de-linking validations, and API implementation detail, for payer and TPA. | | 9 | NHCX Provider Side Use Cases, Sandbox Exit Process | Which use cases a provider must cover: which API, at whose end, which bundle, which status, and the callback logic. | | 10 | NHCX Payer Side Use Cases, Sandbox Exit Process | The same list for a payer. | | 11 | NHCX Requests and Responses for UseCases | Which value sets to use when building FHIR bundles, which bundle to use, and which values are mandatory. One tab per use case. A spreadsheet. | | 12 | Workflow Status Sheets (with Codes) | The workflow codes to send in the protected header. A spreadsheet, updated when codes change. | | 13 | NHCX Code Snippets references for payload preparation | Reference code snippets for preparing use case payloads. | | 14 | Implementation Guide for Adoption of FHIR in ABDM and NHCX | The FHIR implementation guide for both. | | 15 | API Response Handling to avoid Failures | How to handle error scenarios, and how to send the protocol response that closes the request cycle. | | 16 | AWS(Sandbox)-PARTICIPANT SERVICE\_APIs Postman Collection | Postman collection for the participant service APIs in sandbox. A zip file. | | 17 | AWS(Sandbox)-NHCX USECASE Postman Collection | Postman collection for the use case APIs in sandbox. A zip file. | | 18 | Standard Error Codes | Every error code and scenario, by use case, for the bridge and for NHCX. A spreadsheet. | | 19 | NHCX Dummy Payer Implementation | Implementation guide for the dummy payer. | | 20 | Steps to generate encryption Certificate | How to generate the encryption certificate, a public and private key pair. | | 21 | FAQs | Frequently asked questions. | | 22 | Common Mistakes while implementing through NHCX | Mistakes seen at the integrator end, and how they are resolved. | | 23 | Technical Specification, API Specifications | Swagger for the use cases and for the participant service. The source adds a warning: for use case payloads, work from rows 11 and 13 rather than the swagger. The swagger is the relevant source for the participant service APIs. | ### PMJAY and HMIS supporting documents PMJAY is the Ayushman Bharat Pradhan Mantri Jan Arogya Yojana scheme. These rows sit under Supporting Documents on the HMIS documents page. | # | Document | What it covers | | -- | ------------------------------------------------ | ----------------------------------------------------------------- | | 24 | NHCX PMJAY Integration Handbook | The integration handbook for an HMIS. | | 25 | Insurance Plan IG | Implementation guide for the insurance plan bundle. | | 26 | NHCX\_APIs to be called based on scenario | A roadmap for an HMIS: which NHCX APIs to call in which scenario. | | 27 | NHCX-PMJAY-HMIS Integration Overview | Overview of the integration. | | 28 | NHCX-PMJAY-HMIS Integration Guide | The integration guide. | | 29 | Name not given in the source | Sample FHIR. | | 30 | Biometric Authentication APIs Postman Collection | Postman collection for the biometric authentication APIs. | | 31 | NHCX-PMJAY-HMIS Test Cases | Test cases for the integration. | | 32 | Row blank in the source | The source row carries a location and nothing else. | ## What is missing here Everything past the index. This page carries the title and purpose of each document, not the endpoints, payloads, status codes or error codes inside them. No NHCX call is served against a sandbox. ## Next - New to NHCX? Start at row 4 above, the sandbox onboarding document. - [Choose your gateway](/docs/hiecm/v3) - [HIE-CM](/docs/hiecm/v3/) - [UHI services](/docs/uhi/v1) - [Support](/docs/support), for anything about these pages rather than about NHCX itself --- # Registries NHCX has a registry of its own, and it is not a registry of people. After this page you will know what is registered on this gateway and what is not. ## The participant registry Every provider and every payer onboards as a participant, in sandbox first and then in production. The participant is the entry: an organisation with a role, not a doctor and not a patient. The production onboarding document, row 5 of [the index](/docs/nhcx/v1), is where the role and registry enums live, along with the validations applied to them. Row 16 is the Postman collection for the participant service APIs. The enum values live there and are not reproduced here. The participant service is also what a claim is routed by: NHCX sits in the middle and moves messages between registered participants. ## ABDM's three registries [ABHA](/docs/nhcx/v1/getting-started/glossary#abha) identifies a patient, the HPR a practitioner, the HFR a facility. All three are ABDM wide, and a hospital that is on both gateways will already hold the last two from its [HIE-CM](/docs/nhcx/v1/getting-started/glossary#hie-cm) onboarding. How each appears inside a claim is not yet published. No row describes a field, and the two gateways share no API surface, so a mapping copied from HIE-CM would be a guess. The value sets a bundle must use are row 11. If you need the identifiers themselves, they are written on HIE-CM: [registries](/docs/hiecm/v3/registries) has all three, and [M4](/docs/hiecm/v3/api/m4) is the milestone that creates the provider side. ## Next - [Core concepts](/docs/nhcx/v1/concepts), what a claim is made of - [NHCX](/docs/nhcx/v1), the full document index --- # Support Two places to ask, depending on what went wrong. Sandbox behaviour goes to the [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) developer forum; a page here that is wrong, missing or broken goes to whoever maintains it. ## Ask about the sandbox The developer forum is at [devforum.abdm.gov.in](https://devforum.abdm.gov.in). Post there for anything about the sandbox itself: credentials, onboarding, an endpoint returning something the document does not describe, a callback that never arrives, or a certification question. Search the forum first, because the answer is often already on a thread. ## What to put in a report | Include | Example | | -------------------------------- | -------------------------------------- | | The API you called | `POST /api/hiecm/gateway/v3/sessions` | | The `REQUEST-ID` header you sent | `4f8a1c62-6a3b-4d0e-9d7c-2b1f0a5e8d31` | | The `TIMESTAMP` header you sent | `2026-08-24T09:14:07.412Z` | | The response you received | Status code and full body | | What you expected instead | The behaviour the document describes | Add the callback body if the call is asynchronous and a callback arrived. Never post an access token, a client secret, or a real patient's identifiers. Replace them with a placeholder. `REQUEST-ID` is a fresh UUID you generate per request, and the M1 Postman collection sends it on almost every call. It is the one value that names the exact call you made, so log it and quote it. ## Attaching a file to Ask AI Ask AI takes a file with your question: a failing request body, a FHIR bundle, a log, a CSV, a PDF, or a screenshot. The paperclip is on the left of the box. At most 20,000 characters of text, 256KB for a text file and 8MB for a PDF or an image. What happens to it is worth knowing before you attach one. - The file is read in your own browser and only the text it gives up travels with your question. A PDF gives up the text it already carries. A screenshot is read by a text recognition engine your browser downloads once, from this site, and runs on your own machine. The picture itself is never sent, so nothing is uploaded and nothing is stored: the conversation lives in the panel and is gone when you close it. - A PDF that is only pictures of text, a scan, gives up nothing. Screenshot the part you mean instead and that will be read. - Text read from a picture carries reading mistakes. The assistant is told where the text came from, so it can say when an answer turns on a character it cannot trust. - Personal data is removed before the file reaches the model. A file that parses as JSON is masked by its field names, so `name`, `telecom`, `address`, `birthDate` and identifier values in a FHIR bundle are replaced with placeholders such as `<MASKED_NAME>`. Aadhaar, ABHA, PAN, passport, voter, mobile, email and bearer tokens are matched by pattern anywhere in the file, JSON or not. - A file with no field names, a log or the text read from a screenshot, gets the same pattern masking, and a name on a labelled line goes too: `patient: Rakesh Sharma` leaves as `patient: <MASKED_NAME>`. - What none of that catches is a name written in running prose, with nothing marking it as a name. Redact those yourself, the same way you would in a forum post. The panel says so next to any file it read for you. - Your question is logged, masked, to improve the answers. The file is not logged. ## Report a problem with a page here Wrong page, dead link, a payload that does not match what the sandbox returns: report it against the page, not on the developer forum. Say the page URL, and whether you saw the real behaviour yourself. Pages here are written from the source documents and marked `unverified` for that reason, so a report from someone who has run the call is how a page becomes verified. --- # UHI API reference No OpenAPI specification is published for UHI yet. The message shapes for each service are on its own page. - [Network and protocol](/docs/uhi/v1/concepts/network-and-protocol): the search, select, init and confirm pattern every UHI service shares, and the roles on either side of it. - [Onboarding](/docs/uhi/v1/getting-started/onboarding): registration, the signing keys and the callback URL your participant registers. - The service pages: the fields each service adds on top of the shared pattern. --- # UHI gateway [UHI](/docs/uhi/v1/getting-started/glossary#uhi) is the Unified Health Interface, one of [ABDM](/docs/uhi/v1/getting-started/glossary#abdm)'s three gateways. After this page you will know the two roles, the two transports and the signing scheme that every UHI service shares. [HIE-CM](/docs/uhi/v1/getting-started/glossary#hie-cm) moves records that already exist. UHI helps a patient find and book a service before any record exists: a consultation, an ambulance, a unit of blood, a medicine at a pharmacy. Any consumer app on the network can discover any provider on it. ## Prerequisite Your application must have completed ABDM [M2](/docs/hiecm/v3/api/m2) with HIE-CM before it can be onboarded to any UHI service. This is a hard requirement. UHI sits on top of HIE-CM, it is not an alternative to it. ## Two roles | Role | Full name | What it is | | -------------------------------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | [EUA](/docs/uhi/v1/getting-started/glossary#eua) | End User Application | The patient facing app or website. Searches, shows results, books, displays status. | | [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) | Health Service Provider Application | The provider platform. Holds doctor profiles and slot availability, confirms bookings, drives the appointment lifecycle. | The HSP is the hospital, clinic or doctor, and the HSPA is its digital interface. The Gateway is the routing layer, and [NHA](/docs/uhi/v1/getting-started/glossary#nha) is the network operator that governs onboarding and the protocol. ## Two transports in one flow This is the critical architectural point. - **Discovery goes through the gateway.** Your EUA sends one `/search`, and the gateway broadcasts it to every registered HSPA. Responses come back to your callback URL as `/on_search`. - **Everything after discovery is direct.** Booking, fulfilment and post fulfilment are point to point between the EUA and the one HSPA the patient chose. There is no central UHI API for those stages, so both sides expose their own endpoints. The provider URI for those direct calls comes from the context of the `on_search` response. You do not know it before discovery. ## Signing Every UHI call is signed with Ed25519 over a BLAKE-512 hash of the request body, carried in an `Authorization` header. Inbound gateway calls carry the same structure in an `X-Gateway-Authorization` header, with the key ID prefixed `gateway-nha`. A header generator utility is published at [github.com/NHA-ABDM/UHI](https://github.com/NHA-ABDM/UHI/tree/main/header_generator_utility). Generate your Ed25519 key pair with it and send NHA the public key only. ## Sandbox environment ```text Gateway base URI https://uhigatewaysandbox.abdm.gov.inReference EUA http://uhieuasandbox.abdm.gov.in/api/v1/euaServiceReference HSPA https://hspasbx.abdm.gov.in/api/v1/hspa ``` ## Service identity A service is identified by fixed values in the call itself, not by a different endpoint. For physical consultation: | Field | Value | | ------------------------------------- | --------------- | | `context.domain` | `nic2004:85111` | | `context.core_version` | `0.7.1` | | `message.intent.fulfillment.type` | `Physical` | | `message.intent.item.descriptor.code` | `Consultation` | | `message.intent.item.descriptor.name` | `Consultation` | Other services use different values. Check the page for the service you are building. ## Services - [Physical consultation](/docs/uhi/v1/concepts/services/physical-consultation) - [Ambulance booking](/docs/uhi/v1/concepts/services/ambulance-booking) - [Blood bank](/docs/uhi/v1/concepts/services/blood-bank) - [Jan Aushadhi Kendra](/docs/uhi/v1/concepts/services/jan-aushadhi-kendra) - [Jan Aushadhi medicine search](/docs/uhi/v1/concepts/services/jan-aushadhi-medicine-search) - [AMRIT pharmacy](/docs/uhi/v1/concepts/services/amrit-pharmacy) - [PMJAY HEM](/docs/uhi/v1/concepts/services/pmjay-hem) The index for all of them is [UHI in API references](/docs/uhi/v1). ## What is missing here Per stage request and response bodies sit on the [physical consultation](/docs/uhi/v1/concepts/services/physical-consultation) page. The other six services have their own documents and are not covered here. ## Next - [HIE-CM](/docs/hiecm/v3/) - [Milestones, by role](/docs/hiecm/v3/milestones) - [UHI API references](/docs/uhi/v1) --- # Ambulance booking Ambulance booking on [UHI](/docs/uhi/v1/getting-started/glossary#uhi) lets a patient or a caregiver find ambulances near them across every registered provider, see arrival windows and indicative charges, and start a booking with the one they pick. After this page you will know the four calls that are live today, their fields, and what [NHA](/docs/uhi/v1/getting-started/glossary#nha) tests your app for. Read [UHI services](/docs/uhi/v1) first, for the `context` block, the acknowledgement model, signing and the two transports. ## What is live, and what is not This service is released in two phases. | Phase | Calls | Status | | ------ | ---------------------------------------------------------------------------------- | -------- | | First | `search`, `on_search`, `init`, `on_init` | Current | | Second | `confirm`, `on_confirm`, `status`, `on_status`, `cancel`, `on_cancel`, `on_update` | Upcoming | Today the flow ends at a quote. The patient discovers ambulances, picks one, sends their details with `init`, and receives a quote with terms in `on_init`. There is no `confirm`. The outcome is the patient requesting a callback from the provider they chose. Two limits follow from that. - **The `agent` block must not appear in any current-phase payload.** Driver name, vehicle number and driver phone are post-confirmation data. Their absence is tested in `on_search` and `on_init`, and tests that your EUA shows no driver or vehicle UI at any point before confirmation. - **Live tracking and dispatch updates are not available.** They arrive with the second phase. ## Out of scope right now - The `NON_EMERGENCY` flow, which is future scope. Build `EMERGENCY` first. - Booking confirmation and order creation from the EUA. - State-operated ambulance networks. 108, 102 and 112 services are not on UHI today. - Patient transport ambulances. An HSPA may return a `PTA` category in its catalog. Ignore it. ## Service identity | Field | Value | | ------------------------------------- | ------------------------------ | | `context.domain` | `nic2008:86909` | | `context.core_version` | `0.7.1` | | `message.intent.item.descriptor.code` | `AMBULANCE` | | `message.intent.fulfillment.type` | `EMERGENCY` or `NON_EMERGENCY` | ## Who is involved | Role | What it does here | | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | [EUA](/docs/uhi/v1/getting-started/glossary#eua) | The patient or caregiver app. Sends the search, shows options, sends `init`, shows the quote and terms | | [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) | The ambulance operator's platform. Answers searches with live availability, answers `init` with a quote | | [Gateway](/docs/uhi/v1/getting-started/glossary#gateway) | The routing layer. Broadcasts the search. Not involved from `init` onwards | ## The four calls | # | Call | Direction | What happens | | - | ----------- | ----------------------- | ----------------------------------------------------------------------------------------- | | 1 | `search` | EUA to gateway to HSPAs | The patient searches by case type, ambulance class and pickup location | | 2 | `on_search` | HSPA to gateway to EUA | Each HSPA with availability returns a catalog with arrival windows and indicative pricing | | 3 | `init` | EUA to HSPA, direct | The EUA sends patient details, billing and the chosen fulfilment | | 4 | `on_init` | HSPA to EUA, direct | The HSPA returns a quote, payment terms and a cancellation policy | Every one returns an acknowledgement synchronously. The real answer arrives later at the callback URL. Silence is not an error. An HSPA answers only for areas it covers, so no response from a given HSPA tells you nothing about network health. ## Search filters | Case type | Ambulance class codes | Location fields required | | --------------- | --------------------- | ------------------------------------------------ | | `EMERGENCY` | `ALS`, `BLS`, `ALL` | `SOURCE` only: pickup GPS and address | | `NON_EMERGENCY` | `ALS`, `BLS`, `ALL` | `SOURCE` and `DESTINATION`, both GPS and address | `ALS` is advanced life support, `BLS` is basic life support. For an emergency search, set the class to `ALL` so nothing available is filtered out. ## search `context` is the standard UHI block. The service-specific parts live in `message.intent`. | Field | Type | Required | What it is | | -------------------------------------- | -------- | ----------- | ------------------------------------------------------------ | | `category.descriptor.code` | string | Optional | Ambulance class: `ALS`, `BLS`, or `ALL` for every class | | `fulfillment.type` | string | Mandatory | `EMERGENCY` or `NON_EMERGENCY` | | `fulfillment.start.time.timestamp` | ISO 8601 | Mandatory | Requested pickup time. Use the current time for an emergency | | `fulfillment.end.time.timestamp` | ISO 8601 | Optional | End of the acceptable window. Used for non-emergency only | | `fulfillment.tags.additional_services` | string | Optional | Comma-separated extras, for example an oxygen cylinder | | `locations[SOURCE].gps` | string | Mandatory | Pickup coordinates as `latitude,longitude` | | `locations[SOURCE].address` | string | Mandatory | Pickup address text | | `locations[DESTINATION].gps` | string | Conditional | Drop-off coordinates. Non-emergency only | | `locations[DESTINATION].address` | string | Conditional | Drop-off address. Non-emergency only | | `item.descriptor.code` | string | Mandatory | `AMBULANCE` | ### Sample, emergency With your identifiers substituted. ```json { "context": { "domain": "nic2008:86909", "country": "IND", "city": "std:011", "action": "search", "core_version": "0.7.1", "consumer_id": "<YOUR_EUA_ID_FROM_NHA_ONBOARDING>", "consumer_uri": "<YOUR_HTTPS_CALLBACK_URL>", "message_id": "e9a19230-f951-11ec-b135-53aea776f66b", "timestamp": "2026-03-23T15:24:35", "transaction_id": "e9a19230-f951-11ec-b135-53aea776f66b" }, "message": { "intent": { "category": { "descriptor": { "code": "ALS", "name": "ALS" } }, "fulfillment": { "type": "EMERGENCY", "start": { "time": { "timestamp": "2026-01-05T15:24:35" } }, "end": { "time": { "timestamp": "2026-01-05T23:59:59" } }, "tags": { "additional_services": "oxygen cylinder, etc" } }, "locations": [ { "descriptor": { "code": "SOURCE", "name": "SOURCE" }, "gps": "12.423423,77.325647", "address": "SHIVAJI MARG, PUNE" } ], "item": { "descriptor": { "code": "AMBULANCE", "name": "AMBULANCE" } } } }} ``` ## on\_search | Field | Type | Required | What it is | | ----------------------------------------------------- | -------- | --------- | -------------------------------------------------------- | | `context.provider_id` | string | Mandatory | HSPA identifier. You need this for `init` | | `context.provider_uri` | string | Mandatory | HSPA callback URL. You need this for `init` | | `context.transaction_id` | string | Mandatory | Matches your search | | `catalog.descriptor.name` | string | Mandatory | HSPA name | | `catalog.descriptor.images` | string | Optional | HSPA logo, preferably base64 | | `catalog.descriptor.flag` | boolean | Mandatory | `false` means the service is active, `true` means paused | | `providers[].id` | string | Mandatory | Provider identifier | | `providers[].categories[].code` | string | Mandatory | Ambulance class: `ALS` or `BLS` | | `providers[].fulfillments[].id` | string | Mandatory | Fulfilment ID, for example `ML-ALS-01` | | `providers[].fulfillments[].type` | string | Mandatory | Case type. Must match the search | | `providers[].fulfillments[].tracking` | boolean | Mandatory | Whether live tracking is supported for this option | | `providers[].fulfillments[].start.time.timestamp` | ISO 8601 | Mandatory | Earliest estimated arrival | | `providers[].fulfillments[].end.time.timestamp` | ISO 8601 | Mandatory | Latest estimated arrival | | `providers[].fulfillments[].tags.additional_services` | string | Optional | Extras available on this option | | `providers[].fulfillments[].tags.deeplink_url` | string | Optional | Deep link into the HSPA app | | `providers[].items[].id` | string | Mandatory | Item identifier | | `providers[].items[].descriptor.flag` | boolean | Mandatory | `true` means payment is required | | `providers[].items[].price.value` | string | Mandatory | Base indicative price in INR | | `providers[].items[].price.estimated_Value` | string | Optional | Estimated total charge | | `providers[].items[].price.minimum_Value` | string | Optional | Minimum or advance charge | | `providers[].items[].price.maximum_Value` | string | Optional | Maximum expected charge | | `providers[].items[].fulfillment_id` | string | Mandatory | Links this price to a fulfilment | ### How the pieces link Each fulfilment ID appears twice: once where the fulfilment is declared, and once as `items[].fulfillment_id`. The item also carries `category_id`. The chain is category, then fulfilment, then item, joined through the item object. Walk it to show "ALS ambulance, arriving 12:30 to 12:35, around 500 rupees". ### Sample, trimmed ```json { "context": { "domain": "nic2008:86909", "action": "on_search", "core_version": "0.7.1", "consumer_id": "<YOUR_EUA_ID_FROM_NHA_ONBOARDING>", "consumer_uri": "<YOUR_HTTPS_CALLBACK_URL>", "provider_id": "<HSPA_ID_FROM_THIS_RESPONSE>", "provider_uri": "<HSPA_CALLBACK_URL_FROM_THIS_RESPONSE>", "transaction_id": "e9a19230-f951-11ec-b135-53aea776f66b", "message_id": "e9a19230-f951-11ec-b135-53aea776f66b" }, "message": { "catalog": { "descriptor": { "name": "Medulance HSPA", "flag": false, "short_desc": "Medulance: Ambulance Provider HSPA" }, "providers": [ { "id": "1", "descriptor": { "name": "Medulance", "flag": false }, "categories": [ { "id": "1", "descriptor": { "name": "Advanced Life Support (ALS)", "code": "ALS", "flag": false } }, { "id": "2", "descriptor": { "name": "Basic Life Support (BLS)", "code": "BLS", "flag": false } } ], "fulfillments": [ { "id": "ML-ALS-01", "type": "EMERGENCY", "tracking": true, "start": { "time": { "timestamp": "2026-01-05T12:30:00" } }, "end": { "time": { "timestamp": "2026-01-05T12:35:00" } }, "tags": { "additional_services": "oxygen cylinder, etc", "deeplink_url": "https://deeplinkurl.com" } } ], "items": [ { "id": "1", "descriptor": { "name": "Charges", "flag": true }, "price": { "currency": "INR", "value": "500", "estimated_Value": "500", "minimum_Value": "200", "maximum_Value": "1500" }, "category_id": "1", "fulfillment_id": "ML-ALS-01" } ] } ] } }} ``` ## init Direct to the HSPA, at the `provider_uri` you took from `on_search`. | Field | Type | Required | What it is | | -------------------------------------------- | ------- | ----------- | -------------------------------------------------------------------------------------------------- | | `context.provider_id` | string | Mandatory | Carried from `on_search` | | `context.provider_uri` | string | Mandatory | Carried from `on_search` | | `order.provider.id` | string | Mandatory | The provider the user picked | | `order.item.id` | string | Mandatory | The item the user picked | | `order.item.fulfillment_id` | string | Mandatory | The fulfilment the user picked | | `order.fulfillment.id` | string | Mandatory | Matches `item.fulfillment_id` | | `order.fulfillment.type` | string | Mandatory | `EMERGENCY` or `NON_EMERGENCY` | | `order.fulfillment.tracking` | boolean | Mandatory | Carried from `on_search` | | `order.fulfillment.tags.additional_services` | string | Optional | Extras the patient asked for | | `order.fulfillment.tags.deeplink_url` | string | Optional | Carried from `on_search` if present | | `order.billing.name` | string | Mandatory | Patient or responsible person | | `order.billing.address` | object | Mandatory | Pickup address: `locality`, `state`, `country`, `area_code` | | `order.billing.phone` | string | Mandatory | Contact number | | `order.customer.id` | string | Mandatory | Patient [ABHA](/docs/uhi/v1/getting-started/glossary#abha) address, for example `91XXXXXXXXXX@sbx` | | `order.customer.person.dob` | string | Optional | `YYYY-MM-DD` | | `order.customer.person.gender` | string | Optional | `M`, `F` or `O` | | `order.locations[SOURCE]` | object | Mandatory | Pickup GPS and address | | `order.locations[DESTINATION]` | object | Conditional | Required for non-emergency, optional for emergency | ## on\_init The HSPA answers with the order ID, a quote and the terms. | Field | Type | Required | What it is | | ---------------------------------------- | ------------ | ----------- | ----------------------------------------------------------------- | | `order.id` | string | Mandatory | The HSPA's order ID. Carry it into every call in the second phase | | `order.fulfillment.tags.terms_reference` | string (URL) | Mandatory | Link to the HSPA's versioned terms document | | `order.quote.price.value` | string | Mandatory | Total confirmed price in INR | | `order.quote.breakup[].title` | string | Mandatory | Line item name, for example `Ambulance Base Charge` | | `order.quote.breakup[].price.value` | string | Mandatory | Line item amount | | `order.payment.type` | string | Mandatory | `ON-ORDER` at booking, or `PRE-ORDER` in advance | | `order.payment.status` | string | Mandatory | For example `NOT_PAID` | | `order.terms[].type` | string | Mandatory | `Commercial`, `Settlement`, `Cancellation`, `Refund` or `Payment` | | `order.terms[].termsState` | string | Mandatory | `INITIATED`, awaiting EUA review | | `order.locations[SOURCE]` | object | Mandatory | Echoed from `init` | | `order.locations[DESTINATION]` | object | Conditional | Echoed from `init` for non-emergency | Three terms apply in the current phase: `Commercial`, `Cancellation` and `Payment`, each at `INITIATED`. ```json { "quote": { "price": { "currency": "INR", "value": "500.0" }, "breakup": [ { "title": "Ambulance Base Charge", "price": { "currency": "INR", "value": "400.0" } }, { "title": "Consumable Charges", "price": { "currency": "INR", "value": "100.0" } } ] }, "payment": { "type": "ON-ORDER", "status": "NOT_PAID" }} ``` Most of `on_init` exists for the second phase. You may receive these fields now without showing all of them to the user yet. ## What your EUA has to show | ID | Requirement | | ---------- | ---------------------------------------------------------------------------------------------------------- | | `AMB-E-01` | Show the HSPA name and logo from `catalog.descriptor` in the listing, whenever they arrive in the response | | `AMB-E-02` | Show the estimated arrival window from `fulfillment.start` and `fulfillment.end` for each option | | `AMB-E-03` | Show the indicative price from `item.price.value` before the user selects | | `AMB-E-04` | Show the full `on_init` cancellation and payment terms before enabling any confirm action | | `AMB-E-05` | Show no driver or vehicle detail anywhere before confirmation | ## Edge cases to handle | Case | What your system does | | ----------------------------------------------------------------------- | ------------------------------------------------------------------ | | No HSPA answers within your window | Show the user a clear empty result. Do not present it as a failure | | An HSPA returns an empty `providers` array | Handle it without a crash or a display error | | A duplicate `search` with the same `transaction_id` | Expect the gateway or the HSPA to deduplicate | | `on_init` with `payment.type: PRE-ORDER` and a non-zero `minimum_Value` | Show the advance payment requirement to the user | ## Prerequisites For an EUA: - [ABDM](/docs/uhi/v1/getting-started/glossary#abdm) [M2](/docs/hiecm/v3/api/m2) with [HIE-CM](/docs/uhi/v1/getting-started/glossary#hie-cm) completed. This is the hard prerequisite for production access. - A publicly reachable HTTPS `consumer_uri` for `on_search` and `on_init`. - Ed25519 signing with BLAKE-512 body hashing. - Asynchronous handling. Do not block on a synchronous reply to `search` or `init`. - `EMERGENCY` support at minimum. `NON_EMERGENCY` is recommended, not required. For an HSPA: - A publicly reachable HTTPS callback URL for `search` from the gateway and `init` from EUAs. - Ed25519 signing on every outbound response. - Real-time or near real-time availability data. Integrations relying only on manually maintained records are not approved for production. - An `on_init` that carries a confirmed quote, payment terms and a cancellation policy. - No `agent` block in any current-phase payload. ## What is missing here - The calls in the second phase have no field reference yet. - A Postman collection for this service is available from your onboarding contact. - Error codes for this service are not enumerated in the source document. ## Next - [UHI services](/docs/uhi/v1) for the shared protocol - [Physical consultation](/docs/uhi/v1/concepts/services/physical-consultation), the service with the full lifecycle - [Blood bank](/docs/uhi/v1/concepts/services/blood-bank) - [Support](/docs/support) --- # AMRIT Pharmacy discovery AMRIT Pharmacies are the discounted medicine stores run inside government hospitals by HLL Lifecare Limited. After this page you will know the five ways to search for one and every field that comes back. ## Who does what Three parties. Shared roles, signing and onboarding are on [UHI services](/docs/uhi/v1). | Party | Who runs it | What it does here | | -------------------------------------------------------- | ---------------------------------------------------------------- | ---------------------------------------------------------------------- | | [EUA](/docs/uhi/v1/getting-started/glossary#eua) | You, or any [PHR](/docs/uhi/v1/getting-started/glossary#phr) app | Sends the `search`. Receives the `on_search`. Renders the store list. | | [UHI](/docs/uhi/v1/getting-started/glossary#uhi) Gateway | [NHA](/docs/uhi/v1/getting-started/glossary#nha) | Validates and routes the `search`. Relays the `on_search` back to you. | | [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) | HLL Lifecare Limited | Queries the AMRIT store database. Builds the `on_search` catalog. | You do not build a [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) unless you are HLL or their technology partner. ## Message flow Two calls, asynchronous, discovery only. There is no ordering and no reservation. The HTTP 200 from the Gateway is a receipt. The store data arrives afterwards on your callback URL. | Step | Who acts | What happens | | ---- | ----------- | -------------------------------------------------------------------------- | | 1 | Your system | You build a `search` with your filters and POST it to the Gateway. | | 2 | Gateway | Returns HTTP 200 ACK immediately. Forwards the `search` to the AMRIT HSPA. | | 3 | AMRIT HSPA | Queries the store database against your filters. | | 4 | AMRIT HSPA | POSTs an `on_search` to the Gateway with a catalog of matching stores. | | 5 | Gateway | POSTs the `on_search` to your `consumer_uri`. | | 6 | Your system | ACKs the `on_search` and renders the list. | Match a response to its request by `context.transaction_id`. Your `consumer_uri` must be a publicly reachable HTTPS endpoint. ## Service identity | Parameter | Value | Where it goes | | ---------------------------- | --------------------------------------------------------- | -------------------------------------------------------- | | `domain` | `nic2025:477201` | `context.domain` in every call | | `fulfillment.type` | `AMRIT` | `message.intent.fulfillment.type` | | `item.descriptor.code` | `AMRIT_PHARMACY` | `message.intent.item.descriptor.code` | | `item.descriptor.name` | `AMRIT_PHARMACY` | `message.intent.item.descriptor.name` | | Provider ID | Not yet published | Identifies the AMRIT HSPA on the network | | Provider URL | Not yet published | The AMRIT HSPA endpoint registered with NHA | | HSPA public key ID | Not yet published | The Gateway uses it to verify AMRIT's response signature | | Gateway base URL, sandbox | `https://uhigatewaysandbox.abdm.gov.in/api/v1/uhi/search` | Append `/search` or `/on_search` to the base path | | Gateway base URL, production | `https://uhigateway.abdm.gov.in/api/v1/uhi/search` | Append `/search` or `/on_search` to the base path | The last three are issued at onboarding. See [Confirm at onboarding](#confirm-at-onboarding). Ask your contact for the registered values before you go to sandbox. ## Search filters No mandatory location filter. All five filter shapes are independent and they combine. | Search type | Fields used | Use case | | --------------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------- | | By pharmacy code | `category.descriptor.code`, `category.descriptor.name` | Look up one store by its assigned code | | By state and district | `location.state.code`, `location.state.name`, `location.district.code`, `location.district.name` | All AMRIT stores in a district | | By pincode | `address.area_code` | Stores in a 6 digit pincode area | | By GPS and radius | `location.gps`, `location.radius.type`, `location.radius.value`, `location.radius.unit` | Stores near the user | | Combined | state, district and `address.area_code` together | Narrow to a sub area of a district | `address` sits beside `location` inside `message.intent`, not inside it. ## Sample payloads The `context` block is identical across all five variants. Only `message.intent` changes. ### Search by pharmacy code ```json { "context": { "domain": "nic2025:477201", "country": "IND", "city": "std:011", "action": "search", "core_version": "0.7.1", "consumer_id": "<YOUR_EUA_ID_FROM_NHA_ONBOARDING>", "consumer_uri": "<YOUR_HTTPS_CALLBACK_URL>", "message_id": "<FRESH_UUID_PER_CALL>", "timestamp": "2026-06-09T18:24:35", "transaction_id": "<FRESH_UUID_PER_SEARCH_SESSION>" }, "message": { "intent": { "category": { "descriptor": { "code": "Pharmacy Code", "name": "Pharmacy Code" } }, "fulfillment": { "type": "AMRIT", "start": { "time": { "timestamp": "2026-06-09T00:00:00" } }, "end": { "time": { "timestamp": "2026-06-09T23:59:59" } } }, "item": { "descriptor": { "code": "AMRIT_PHARMACY", "name": "AMRIT_PHARMACY" } } } }} ``` Two values are in circulation for `category.descriptor`: the literal string `Pharmacy Code`, and the pharmacy code value itself. Those are two different things. See [Confirm at onboarding](#confirm-at-onboarding). ### Search by state and district ```json { "message": { "intent": { "fulfillment": { "type": "AMRIT", "start": { "time": { "timestamp": "2026-06-09T00:00:00" } }, "end": { "time": { "timestamp": "2026-06-09T23:59:59" } } }, "item": { "descriptor": { "code": "AMRIT_PHARMACY", "name": "AMRIT_PHARMACY" } }, "location": { "district": { "code": "466", "name": "Ahmednagar" }, "state": { "code": "27", "name": "Maharashtra" } } } }} ``` ### Search by pincode ```json { "message": { "intent": { "fulfillment": { "type": "AMRIT", "start": { "time": { "timestamp": "2026-06-09T00:00:00" } }, "end": { "time": { "timestamp": "2026-06-09T23:59:59" } } }, "item": { "descriptor": { "code": "AMRIT_PHARMACY", "name": "AMRIT_PHARMACY" } }, "address": { "area_code": "413736" } } }} ``` ### Search by GPS and radius ```json { "message": { "intent": { "fulfillment": { "type": "AMRIT", "start": { "time": { "timestamp": "2026-06-09T00:00:00" } }, "end": { "time": { "timestamp": "2026-06-09T23:59:59" } } }, "item": { "descriptor": { "code": "AMRIT_PHARMACY", "name": "AMRIT_PHARMACY" } }, "location": { "gps": "19.7126974,74.4833288", "radius": { "type": "CONSTANT", "value": "5", "unit": "km" } } } }} ``` ### Combined filters ```json { "message": { "intent": { "fulfillment": { "type": "AMRIT", "start": { "time": { "timestamp": "2026-06-09T00:00:00" } }, "end": { "time": { "timestamp": "2026-06-09T23:59:59" } } }, "item": { "descriptor": { "code": "AMRIT_PHARMACY", "name": "AMRIT_PHARMACY" } }, "location": { "district": { "code": "466", "name": "Ahmednagar" }, "state": { "code": "27", "name": "Maharashtra" } }, "address": { "area_code": "413736" } } }} ``` ### on\_search response Each `providers[]` entry is one AMRIT store. Three things here do not appear in other UHI services: the pharmacy type on the fulfillment, the store opening and closing times, and the [HFR](/docs/uhi/v1/getting-started/glossary#hfr) ID tag. ```json { "context": { "domain": "nic2025:477201", "country": "IND", "city": "std:011", "action": "on_search", "core_version": "0.7.1", "consumer_id": "eua-nha", "consumer_uri": "https://uhieuasandbox.abdm.gov.in/api/v1/euaService", "provider_id": "amrit-hspa", "provider_uri": "https://amritpharmacy.gov.in/api/v1/admin/store/", "message_id": "e9a19230-f951-11ec-b135-53aea776f66b", "timestamp": "2026-06-09T18:24:35", "transaction_id": "e9a19230-f951-11ec-b135-53aea776f66b" }, "message": { "catalog": { "descriptor": { "name": "AMRIT PHARMACY SERVICE", "images": "<AMRIT_PHARMACY_HSPA_LOGO_URL>", "short_desc": "<HSPA_SHORT_DESCRIPTION_SET_BY_HLL>", "long_desc": "<HSPA_LONG_DESCRIPTION_SET_BY_HLL>" }, "providers": [ { "id": "AMRITST01460", "descriptor": { "name": "ESIS NAGPUR", "code": "", "symbol": "", "short_desc": "AMRIT - ESIS NAGPUR", "long_desc": "" }, "fulfillments": [ { "id": "0", "type": "AMRIT", "agent": { "name": "<CONTACT_PERSON_NAME>" }, "start": { "time": { "timestamp": "<STORE_OPENING_TIME>" } }, "end": { "time": { "timestamp": "<STORE_CLOSING_TIME>" } }, "tags": { "@abdm/gov.in/hfr_id": "<HFR_ID>" } } ], "location": { "id": "1", "descriptor": { "name": "ESIS NAGPUR" }, "city": { "name": "", "code": "" }, "district": { "name": "NAGPUR", "code": "466" }, "state": { "name": "Maharashtra", "code": "27" }, "country": { "name": "INDIA", "code": "+91" }, "gps": "19.7126974,74.4833288", "address": "AMRIT PHARMACY, ESIS HOSPITAL, SOMWARI ROAD, OPP. NURSES HOSTEL, KRIDA CHOWK, SOMWARIPETH, NAGPUR, MAHARASHTRA - 440009", "radius": { "type": "CONSTANT", "value": "12", "unit": "km" } }, "contact": { "phone": "<PHARMACY_CONTACT_NUMBER>", "email": "<PHARMACY_CONTACT_EMAIL>" } } ] } }} ``` The angle bracket values above are placeholders. No filled example is published for the store hours, the contact block or the HFR ID, and no timestamp format for opening and closing times. The two `catalog.descriptor` description fields hold descriptive prose in placeholders rather than real values, so they appear here that way too. The sample also carries a `location.radius` block that the field reference does not list. ## Field reference ### search: context All fields are mandatory and identical across every variant. | Field | Type | Value | | ---------------- | -------- | ---------------------------------------------------- | | `domain` | string | `nic2025:477201`, fixed | | `country` | string | `IND`, fixed | | `city` | string | STD code, for example `std:011` | | `action` | string | `search`, fixed | | `core_version` | string | `0.7.1` | | `consumer_id` | string | Your registered EUA identifier | | `consumer_uri` | string | Your HTTPS callback URL | | `message_id` | UUID | Fresh per call. Never reuse. | | `transaction_id` | UUID | Fresh per search session. The `on_search` copies it. | | `timestamp` | ISO 8601 | Request time | ### search: message.intent | Field path | Type | Mandatory | Description | | ---------------------------------- | --------------- | ----------- | ----------------------------------------------- | | `fulfillment.type` | string | Yes | `AMRIT`, fixed | | `fulfillment.start.time.timestamp` | datetime | Yes | Start of the search window | | `fulfillment.end.time.timestamp` | datetime | Yes | End of the search window | | `item.descriptor.code` | string | Yes | `AMRIT_PHARMACY`, fixed | | `item.descriptor.name` | string | Yes | `AMRIT_PHARMACY`, fixed | | `category.descriptor.code` | string | Conditional | Set when searching by pharmacy code | | `category.descriptor.name` | string | Conditional | Set when searching by pharmacy code | | `location.state.name` | string | No | State name, for example `Maharashtra` | | `location.state.code` | string | No | Numeric state code, for example `27` | | `location.district.name` | string | No | District name, for example `Ahmednagar` | | `location.district.code` | string | No | Numeric district code, for example `466` | | `location.gps` | string | No | `lat,long`, for example `19.7126974,74.4833288` | | `location.radius.type` | string | No | `CONSTANT`. Required with a GPS search. | | `location.radius.value` | string or float | No | Radius in km | | `location.radius.unit` | string | No | `km` | | `address.area_code` | string | No | 6 digit pincode | ### on\_search: provider records | Field path | Type | Description | | ---------------------------------------------------------------- | -------- | ------------------------------------------------------------------------------ | | `catalog.providers[].id` | string | AMRIT store code, for example `AMRITST01460` | | `catalog.providers[].descriptor.name` | string | Name of the hospital that hosts the store | | `catalog.providers[].descriptor.code` | string | Empty. Reserved for future use. | | `catalog.providers[].descriptor.symbol` | string | Empty. Reserved for future use. | | `catalog.providers[].descriptor.short_desc` | string | Pharmacy label, for example `AMRIT - ESIS NAGPUR` | | `catalog.providers[].descriptor.long_desc` | string | May be empty | | `catalog.providers[].fulfillments[].type` | string | Pharmacy type. One of `AMRIT`, `AMRIT_OPTICALS`, `HLL_PNS`, `AMRIT_DEENDAYAL`. | | `catalog.providers[].fulfillments[].agent.name` | string | Contact person at the store | | `catalog.providers[].fulfillments[].start.time.timestamp` | datetime | Store opening time | | `catalog.providers[].fulfillments[].end.time.timestamp` | datetime | Store closing time | | `catalog.providers[].fulfillments[].tags["@abdm/gov.in/hfr_id"]` | string | Health Facility Registry identifier for the store | | `catalog.providers[].location.gps` | string | `lat,long` of the store | | `catalog.providers[].location.address` | string | Full street address | | `catalog.providers[].location.city.name` | string | May be empty | | `catalog.providers[].location.city.code` | string | May be empty | | `catalog.providers[].location.district.name` | string | District name | | `catalog.providers[].location.district.code` | string | District code | | `catalog.providers[].location.state.name` | string | State name | | `catalog.providers[].location.state.code` | string | State code | | `catalog.providers[].location.country.name` | string | `INDIA`, fixed | | `catalog.providers[].location.country.code` | string | `+91`, fixed | | `catalog.providers[].contact.phone` | string | Store phone number | | `catalog.providers[].contact.email` | string | May be empty | Note that `fulfillments[].type` carries the pharmacy type here. In Jan Aushadhi Kendra discovery the same field carries the literal value `contact`. Do not reuse a parser across the two services without checking this field. ## Confirm at onboarding Three values are issued when you onboard. Build the flow and hold these until you have them. - **Your registered provider ID, provider URL and HSPA public key ID.** Responses carry `amrit-hspa` at `https://amritpharmacy.gov.in/api/v1/admin/store/`. The public key ID is issued to you directly. - **What goes in `category.descriptor` for a pharmacy code search.** Both the literal string `Pharmacy Code` and the pharmacy code value are in circulation. Confirm which the HSPA accepts. - **The format of store opening and closing times.** No format is published, so read the values back from your first live response rather than parsing to a fixed pattern. ## Next - The other pharmacy discovery service on UHI: [Jan Aushadhi Kendra discovery](/docs/uhi/v1/concepts/services/jan-aushadhi-kendra) - Shared UHI protocol, signing and onboarding: [UHI services](/docs/uhi/v1) --- # Blood bank discovery Blood bank discovery is the smallest service on [UHI](/docs/uhi/v1/getting-started/glossary#uhi): one call pair. Your app sends a search with a blood group, a component and a location, and gets back blood banks with unit counts, addresses and phone numbers. Read [UHI services](/docs/uhi/v1) first, for the `context` block, the acknowledgement model, signing and the two transports. ## Scope Discovery only: `search` and `on_search`. There is no booking or reservation. Put the blood bank's phone number somewhere the user cannot miss it, because calling is how a unit gets held. ## Service identity | Field | Value | Note | | --------------------------------- | ----------------------- | ------------------------------------------------------ | | `context.domain` | `nic2008:86906` | Fixed. A wrong value means no HSPA answers your search | | `context.core_version` | `0.7.1` | Must match exactly | | `context.action` | `search` or `on_search` | Set by the sender | | `message.intent.fulfillment.type` | `BloodStock` | Fixed for every blood bank search | ## Who is involved Both roles are open here. An organisation can onboard as either or both. | Role | What it does | | -------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | [EUA](/docs/uhi/v1/getting-started/glossary#eua) | A patient or clinician facing app. Sends searches, receives results at its callback URL | | [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) | A blood bank management system or aggregator. Answers searches from its own inventory database | At the time of the document there was one registered blood bank HSPA on the network: e-RaktKosh, the centralised blood bank management system. [NHA](/docs/uhi/v1/getting-started/glossary#nha) sets a bar for the HSPA role. Your blood bank database has to be maintained independently and cover stock at a scope and quality comparable to e-RaktKosh. Integrations built on manually maintained or infrequently updated records will not be approved for production. ## The flow | Step | Who | What happens | | ---- | -------------------------------------------------------- | ---------------------------------------------------------------------- | | 1 | Your EUA | Posts `search` to the gateway with blood group, component and location | | 2 | [Gateway](/docs/uhi/v1/getting-started/glossary#gateway) | Returns HTTP 200 with an acknowledgement. This confirms receipt only | | 3 | Gateway | Routes the search to every registered blood bank HSPA | | 4 | HSPA | Queries its inventory database | | 5 | HSPA | Posts `on_search` to the gateway with availability and unit counts | | 6 | Gateway | Forwards `on_search` to your `consumer_uri` | | 7 | Your EUA | Returns HTTP 200 and aggregates results as they arrive | There is no end signal. Responses land one at a time and nothing tells you the last one has arrived. Use a timeout window of 10 to 15 seconds, and display results as they come in. ## Two search modes Blood group and component filters work with either mode. | Mode | Mandatory | Optional | Behaviour | | ------------------ | --------------------------------------------------------------------- | ---------------------- | ----------------------------------------------------------------------------------------------- | | GPS and radius | `location.gps`, `location.radius` | Blood group, component | Returns matching blood banks within the radius. Group and component default to `All` if omitted | | State and district | `location.state` (name and code), `location.district` (name and code) | Blood group, component | Returns matching blood banks in that district | Support both. GPS returns incomplete results where blood bank density is low, and state and district is the only option when GPS is unavailable. ## search `context` is the standard UHI block, with `domain` fixed to `nic2008:86906` and `action` set to `search`. Set `city` to `std:011` as the default. The filters live in `message.intent`. | Field | Value | What it is | | ---------------------------------- | ------------------------- | -------------------------------------------------------------- | | `item.descriptor.name` | Blood group name or `All` | The group being searched, for example `O+Ve` | | `item.descriptor.code` | Blood group code or `-1` | Numeric code from the master list below. `-1` means all groups | | `category.descriptor.name` | Component name | For example `WholeBlood`, `PlateletConcentrate` | | `category.descriptor.code` | Component code | Numeric code from the master list below | | `fulfillment.type` | `BloodStock` | Fixed | | `fulfillment.start.time.timestamp` | ISO 8601 | Start of the availability window | | `fulfillment.end.time.timestamp` | ISO 8601 | End of the availability window | | `location.gps` | `latitude,longitude` | Search origin, for GPS mode | | `location.radius.type` | `CONSTANT` | Fixed, for GPS mode | | `location.radius.value` | Numeric string | Radius in km, for example `10.0` | | `location.radius.unit` | `km` | Fixed | | `location.state.name` | State name in capitals | For example `DELHI` | | `location.state.code` | Numeric state code | For example `7` | | `location.district.name` | District name in capitals | For example `SOUTH` | | `location.district.code` | Numeric district code | For example `83` | ### Sample, GPS with a specific group and component ```json { "context": { "domain": "nic2008:86906", "country": "IND", "city": "std:011", "action": "search", "core_version": "0.7.1", "consumer_id": "<YOUR_EUA_ID_FROM_NHA_ONBOARDING>", "consumer_uri": "<YOUR_HTTPS_CALLBACK_URL>", "message_id": "5cc46ce0-cd96-11ef-957f-718cff4e4e0a", "timestamp": "2025-01-08T07:58:36.421576Z", "transaction_id": "5cc46ce0-cd96-11ef-957f-718cff4e4e0a" }, "message": { "intent": { "item": { "descriptor": { "name": "O+Ve", "code": "15" } }, "category": { "descriptor": { "name": "WholeBlood", "code": "11" } }, "fulfillment": { "type": "BloodStock", "start": { "time": { "timestamp": "2025-01-08T13:28:36" } }, "end": { "time": { "timestamp": "2025-01-08T23:59:59" } } }, "location": { "gps": "17.3788008,78.4368212", "radius": { "type": "CONSTANT", "value": "10.0", "unit": "km" } } } }} ``` To search every blood group at once, set `item.descriptor.name` to `All` and `item.descriptor.code` to `-1`. ### Sample, state and district Replace the `location` block. Everything else is the same. ```json { "location": { "state": { "name": "DELHI", "code": "7" }, "district": { "name": "SOUTH", "code": "83" } }} ``` ## on\_search | Field | Type | What it is | | ------------------------------------------ | ------- | ----------------------------------------------------------------------- | | `context.action` | string | `on_search` | | `context.provider_id` | string | The responding HSPA | | `context.provider_uri` | string | The HSPA's callback URL | | `context.transaction_id` | string | Echoed from your search. Use it to correlate | | `catalog.descriptor.name` | string | HSPA or data source name, for example `e-RaktKosh` | | `providers[].id` | string | Unique ID for this blood bank record | | `providers[].descriptor.name` | string | Blood bank name | | `providers[].descriptor.short_desc` | string | Blood bank type, for example `Govt.`, `Charitable/Vol` | | `providers[].categories[].descriptor.name` | string | Blood component name | | `providers[].categories[].descriptor.code` | string | Blood component code | | `providers[].fulfillments[].type` | string | `Available` or `NotAvailable` | | `providers[].items[].descriptor.name` | string | Blood group name | | `providers[].items[].descriptor.code` | string | Blood group code | | `providers[].items[].quantity.count` | integer | Units available for this group | | `providers[].items[].fulfillment_id` | string | Points at the fulfilment record that says `Available` or `NotAvailable` | | `providers[].location.gps` | string | Blood bank coordinates | | `providers[].location.address` | string | Full address | | `providers[].location.city.name` | string | City | | `providers[].location.state.name` | string | State | | `providers[].location.district.name` | string | District | | `providers[].contact.phone` | string | Blood bank phone number | | `providers[].contact.email` | string | Blood bank email | ### The part that trips people up Availability is not a field on the item. Each provider declares a small set of `fulfillments`, one meaning `Available` and one meaning `NotAvailable`. Each blood group item points at one of them through `fulfillment_id`. A group with a unit count of 16 can still be unavailable. Resolve the link before you show a number to a user. ### Sample response ```json { "context": { "domain": "nic2008:86906", "action": "on_search", "consumer_id": "<YOUR_EUA_ID_FROM_NHA_ONBOARDING>", "consumer_uri": "<YOUR_HTTPS_CALLBACK_URL>", "provider_id": "nha.hspa", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1/bloodbank", "transaction_id": "c51c2800-cd96-11ef-957f-718cff4e4e0a", "message_id": "c51c2800-cd96-11ef-957f-718cff4e4e0a" }, "message": { "catalog": { "descriptor": { "name": "e-RaktKosh", "short_desc": "e-RaktKosh: A Centralized Blood Bank Management System" }, "providers": [ { "id": "0", "descriptor": { "name": "Janseva Blood Centre", "short_desc": "Charitable/Vol" }, "categories": [ { "id": "0", "descriptor": { "name": "WholeBlood", "code": "11" } } ], "fulfillments": [ { "id": "0", "type": "NotAvailable" }, { "id": "1", "type": "Available" } ], "items": [ { "id": "0", "descriptor": { "name": "O+Ve", "code": "15" }, "quantity": { "count": 2 }, "category_id": "0", "fulfillment_id": "1" }, { "id": "1", "descriptor": { "name": "AB+Ve", "code": "17" }, "quantity": { "count": 16 }, "category_id": "0", "fulfillment_id": "0" } ], "location": { "gps": "18.5246036,73.792927", "address": "Paud Road, Pune, Maharashtra", "city": { "name": "Pune" }, "state": { "name": "Maharashtra", "code": "27" }, "district": { "name": "Pune", "code": "521" } }, "contact": { "phone": "8987628900", "email": "contact@jansevabc.org" } } ] } }} ``` In that response `O+Ve` points at fulfilment `1`, which is `Available`. `AB+Ve` has a count of 16 but points at fulfilment `0`, which is `NotAvailable`. ## Blood group master list Use these in `item.descriptor.code`. | Code | Group | | ---- | ----- | | `-1` | All | | `11` | A+Ve | | `12` | A-Ve | | `13` | B+Ve | | `14` | B-Ve | | `15` | O+Ve | | `16` | O-Ve | | `17` | AB+Ve | | `18` | AB-Ve | | `22` | Oh+Ve | | `23` | Oh-Ve | ## Blood component master list Use these in `category.descriptor.code`. | Code | Component | | ---- | ---------------------------- | | `11` | Whole Blood | | `12` | Packed Red Blood Cells | | `13` | Fresh Frozen Plasma | | `14` | Single Donor Platelet | | `16` | Platelet Rich Plasma | | `17` | Cryoprecipitate | | `18` | Single Donor Plasma | | `19` | Plasma | | `20` | Platelet Concentrate | | `21` | Cryo Poor Plasma | | `23` | Random Donor Platelets | | `24` | Platelets Additive Solutions | | `28` | SAGM Packed Red Blood Cells | | `29` | Irradiated RBC | | `30` | Leukoreduced RBC | ## Known limitations | Limitation | What to do about it | | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | GPS search returns incomplete results where blood bank density is low | Offer state and district as a visible alternative, not a hidden fallback | | Update frequency varies by blood bank. Some update in real time, others daily | Show a disclaimer that counts are indicative and may have changed. Tell users to call before travelling | | Responses arrive asynchronously with no end signal | Use a 10 to 15 second timeout and render results as they arrive | | No pagination on `on_search` | Expect large payloads. Paginate or lazy load on the client | | No booking or reservation | Show the blood bank phone number prominently | ## Prerequisites For an EUA: - [ABDM](/docs/uhi/v1/getting-started/glossary#abdm) [M2](/docs/hiecm/v3/api/m2) with [HIE-CM](/docs/uhi/v1/getting-started/glossary#hie-cm) completed. This is a hard prerequisite for any UHI service. - A publicly reachable HTTPS `consumer_uri`. - Ed25519 signing with BLAKE-512 body hashing. - Asynchronous handling. Do not block on a synchronous reply to `search`. For an HSPA: - An independently maintained blood bank database with real-time or near real-time inventory, comparable in scope and quality to e-RaktKosh. - A publicly reachable HTTPS `provider_uri` to receive searches from the gateway. - Ed25519 signing on every outbound response. - Sandbox integration and written sign-off before production. ## What is missing here - No error code list is published for this service. - No response time SLA is published for HSPAs beyond an acceptable latency window. - State and district codes are issued at onboarding. Delhi is `7` and South district is `83`. ## Next - [UHI services](/docs/uhi/v1) for the shared protocol - [Ambulance booking](/docs/uhi/v1/concepts/services/ambulance-booking) - [Physical consultation](/docs/uhi/v1/concepts/services/physical-consultation) - [Support](/docs/support) --- # Jan Aushadhi Kendra discovery Jan Aushadhi Kendras are the government generic medicine stores run under the Pradhan Mantri Bhartiya Janaushadhi Pariyojana. After this page you will know the five ways to search for one and every field that comes back. ## Who does what Three parties. Shared roles, signing and onboarding are on [UHI services](/docs/uhi/v1). | Party | Who runs it | What it does here | | -------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | [EUA](/docs/uhi/v1/getting-started/glossary#eua) | You, or any [PHR](/docs/uhi/v1/getting-started/glossary#phr) app | Sends the `search`. Receives the `on_search` on your callback URL. Renders the Kendra list. | | [UHI](/docs/uhi/v1/getting-started/glossary#uhi) Gateway | [NHA](/docs/uhi/v1/getting-started/glossary#nha) | Validates and routes the `search`. Relays the `on_search` back to you. | | [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) | PMBI, the Pharmaceuticals and Medical Devices Bureau of India | Queries the PMBI Kendra database. Builds the `on_search` catalog. | You do not build a [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) unless you are PMBI or their technology partner. ## Message flow Two calls, asynchronous, discovery only. There is no booking and no ordering. The HTTP 200 from the Gateway is a receipt, not the result. | Step | Who acts | What happens | | ---- | ----------- | ------------------------------------------------------------------------------------------------------------ | | 1 | Your system | The user taps "Find Jan Aushadhi Kendra". You build a `search` with your filters and POST it to the Gateway. | | 2 | Gateway | Returns HTTP 200 ACK to you straight away. Forwards the `search` to the PMBI HSPA. | | 3 | PMBI HSPA | Queries the Kendra database against your filters. | | 4 | PMBI HSPA | POSTs an `on_search` to the Gateway with a catalog of matching Kendras. | | 5 | Gateway | POSTs the `on_search` to your `consumer_uri`. | | 6 | Your system | ACKs the `on_search` and renders the list. | Match the `on_search` to its request by `context.transaction_id`, which the HSPA copies from your `search`. Your `consumer_uri` must be a publicly reachable HTTPS endpoint. ## Service identity Fixed for this service. These values route your `search` to PMBI rather than to a teleconsultation or ambulance provider. | Parameter | Value | Where it goes | | ---------------------------- | --------------------------------------------------------- | ------------------------------------------------------- | | `domain` | `nic2008:47721` | `context.domain` in every call | | `fulfillment.type` | `JANAUSHADHI` | `message.intent.fulfillment.type` | | `item.descriptor.code` | `JANAUSHADHI` | `message.intent.item.descriptor.code` | | `item.descriptor.name` | `JANAUSHADHI` | `message.intent.item.descriptor.name` | | Provider ID | `pmbi.hspa` | Identifies the PMBI HSPA on the network | | Provider URL | `https://nha-pmbi.pmbi.co.in/api/store` | The PMBI HSPA endpoint registered with NHA | | HSPA public key ID | `pmbi.hspapid.jak` | The Gateway uses it to verify PMBI's response signature | | Gateway base URL, sandbox | `https://uhigatewaysandbox.abdm.gov.in/api/v1/uhi/search` | Append `/search` or `/on_search` to the base path | | Gateway base URL, production | `https://uhigateway.abdm.gov.in/api/v1/uhi/search` | Append `/search` or `/on_search` to the base path | ## Search filters There is no mandatory location filter. All five filter shapes below are independent, and they combine. | Search type | Fields used | Use case | | --------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------ | | By Kendra code | `category.descriptor.code`, `category.descriptor.name` | Look up one Kendra by its PMBJP code | | By state and district | `location.state.code`, `location.state.name`, `location.district.code`, `location.district.name` | All Kendras in a district | | By pincode | `address.area_code` | Kendras in a 6 digit pincode area | | By GPS and radius | `location.gps`, `location.radius.type`, `location.radius.value`, `location.radius.unit` | Kendras near the user | | Combined | state, district and `address.area_code` together | Narrow to a sub area of a district | Note that `address` sits beside `location` inside `message.intent`, not inside it. ## Sample payloads The `context` block is the same in all five variants. Only `message.intent` changes. Fill in your own `consumer_id`, `consumer_uri`, `message_id`, `transaction_id` and `timestamp`. ### Search by Kendra code ```json { "context": { "domain": "nic2008:47721", "country": "IND", "city": "std:011", "action": "search", "core_version": "0.7.1", "consumer_id": "<YOUR_EUA_ID_FROM_NHA_ONBOARDING>", "consumer_uri": "<YOUR_HTTPS_CALLBACK_URL>", "message_id": "<FRESH_UUID_PER_CALL>", "timestamp": "2026-06-09T18:24:35", "transaction_id": "<FRESH_UUID_PER_SEARCH_SESSION>" }, "message": { "intent": { "category": { "descriptor": { "code": "PMBJK02129", "name": "PMBJK02129" } }, "fulfillment": { "type": "JANAUSHADHI", "start": { "time": { "timestamp": "2026-06-19T00:00:00" } }, "end": { "time": { "timestamp": "2026-06-19T23:59:59" } } }, "item": { "descriptor": { "code": "JANAUSHADHI", "name": "JANAUSHADHI" } } } }} ``` Confirm what goes in `category.descriptor` before you build this one. See [Confirm at onboarding](#confirm-at-onboarding) below. ### Search by state and district Replace the `category` block with a `location` block. ```json { "message": { "intent": { "fulfillment": { "type": "JANAUSHADHI", "start": { "time": { "timestamp": "2026-06-09T00:00:00" } }, "end": { "time": { "timestamp": "2026-06-09T23:59:59" } } }, "item": { "descriptor": { "code": "JANAUSHADHI", "name": "JANAUSHADHI" } }, "location": { "district": { "code": "509", "name": "KHAMMAM" }, "state": { "code": "36", "name": "Telangana" } } } }} ``` ### Search by pincode ```json { "message": { "intent": { "fulfillment": { "type": "JANAUSHADHI", "start": { "time": { "timestamp": "2026-06-19T00:00:00" } }, "end": { "time": { "timestamp": "2026-06-19T23:59:59" } } }, "item": { "descriptor": { "code": "JANAUSHADHI", "name": "JANAUSHADHI" } }, "address": { "area_code": "500028" } } }} ``` ### Search by GPS and radius ```json { "message": { "intent": { "fulfillment": { "type": "JANAUSHADHI", "start": { "time": { "timestamp": "2026-06-09T00:00:00" } }, "end": { "time": { "timestamp": "2026-06-09T23:59:59" } } }, "item": { "descriptor": { "code": "JANAUSHADHI", "name": "JANAUSHADHI" } }, "location": { "gps": "17.39916197665472, 78.43400530708318", "radius": { "type": "CONSTANT", "value": "5", "unit": "km" } } } }} ``` ### Combined filters ```json { "message": { "intent": { "fulfillment": { "type": "JANAUSHADHI", "start": { "time": { "timestamp": "2026-06-19T00:00:00" } }, "end": { "time": { "timestamp": "2026-06-19T23:59:59" } } }, "item": { "descriptor": { "code": "JANAUSHADHI", "name": "JANAUSHADHI" } }, "location": { "district": { "code": "507", "name": "HYDERABAD" }, "state": { "code": "36", "name": "Telangana" } }, "address": { "area_code": "500028" } } }} ``` ### on\_search response PMBI sends this to your `consumer_uri` through the Gateway. Each entry in `catalog.providers` is one enrolled Kendra. Shortened here to one record. ```json { "context": { "domain": "nic2008:47721", "country": "IND", "city": "std:011", "action": "on_search", "core_version": "0.7.1", "consumer_id": "nha.eua", "consumer_uri": "https://uhieuasandbox.abdm.gov.in/api/v1/euaService", "provider_id": "pmbi.hspa", "provider_uri": "https://staging-nha-pmbi.pmbi.co.in/api/store", "message_id": "e9a19230-f951-11ec-b135-53aea776f66b", "timestamp": "2026-06-09T18:24:35", "transaction_id": "e9a19230-f951-11ec-b135-53aea776f66b" }, "message": { "catalog": { "descriptor": { "name": "JAN AUSHADHI KENDRA HSPA", "images": "https://janaushadhi.gov.in/img/bhartiya_janaushadhi_priyojna_2.svg", "short_desc": "", "long_desc": "" }, "providers": [ { "id": "PMBJK10844", "descriptor": { "name": "Jan Aushadhi Kendra", "code": "PP", "symbol": "1", "short_desc": "", "long_desc": "" }, "fulfillments": [ { "id": "0", "type": "contact", "agent": { "name": "Sunita Zanwar" }, "start": { "time": { "timestamp": "2023-06-30T00:00:00" } } } ], "location": { "id": "1", "descriptor": { "name": "Jan Aushadhi Kendra" }, "city": { "name": "", "code": "" }, "district": { "name": "PUNE", "code": "490" }, "state": { "name": "Maharashtra", "code": "27" }, "country": { "name": "INDIA", "code": "+91" }, "gps": "18.51996721338908,73.86697649999999", "address": "Shop No.2, CTS No.350, Sai Appartment, Near KEM Hospital Rasta Peth, Pune, Pune, Maharashtra, India - 411011", "radius": { "type": "CONSTANT", "value": "1.19", "unit": "km" } }, "contact": { "phone": "9309534959", "email": "janaushadhikem@gmail.com" } } ] } }} ``` ## Field reference ### search: context All fields are mandatory. The block is identical across every variant. | Field | Type | Value | | ---------------- | -------- | ---------------------------------------------------- | | `domain` | string | `nic2008:47721`, fixed | | `country` | string | `IND`, fixed | | `city` | string | STD code, for example `std:011` | | `action` | string | `search`, fixed | | `core_version` | string | `0.7.1` | | `consumer_id` | string | Your registered EUA identifier | | `consumer_uri` | string | Your HTTPS callback URL | | `message_id` | UUID | Fresh per call. Never reuse. | | `transaction_id` | UUID | Fresh per search session. The `on_search` copies it. | | `timestamp` | ISO 8601 | Request time, for example `2026-06-09T18:24:35` | ### search: message.intent | Field path | Type | Mandatory | Description | | ---------------------------------- | --------------- | ----------- | ----------------------------------------------- | | `fulfillment.type` | string | Yes | `JANAUSHADHI`, fixed | | `fulfillment.start.time.timestamp` | datetime | Yes | Start of the search window | | `fulfillment.end.time.timestamp` | datetime | Yes | End of the search window | | `item.descriptor.code` | string | Yes | `JANAUSHADHI`, fixed | | `item.descriptor.name` | string | Yes | `JANAUSHADHI`, fixed | | `category.descriptor.code` | string | Conditional | Set when searching by Kendra code | | `category.descriptor.name` | string | Conditional | Set when searching by Kendra code | | `location.state.name` | string | No | State name, for example `Maharashtra` | | `location.state.code` | string | No | Numeric state code, for example `27` | | `location.district.name` | string | No | District name, for example `Ahmednagar` | | `location.district.code` | string | No | Numeric district code, for example `466` | | `location.gps` | string | No | `lat,long`, for example `19.7126974,74.4833288` | | `location.radius.type` | string | No | `CONSTANT`. Required with a GPS search. | | `location.radius.value` | string or float | No | Radius in km, for example `5` | | `location.radius.unit` | string | No | `km` | | `address.area_code` | string | No | 6 digit pincode, for example `413736` | ### on\_search: provider records | Field path | Type | Description | | --------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | `catalog.providers[].id` | string | PMBJP Kendra code, for example `PMBJK01460` | | `catalog.providers[].descriptor.name` | string | Kendra name | | `catalog.providers[].descriptor.code` | string | Ownership type: `PP` private-private, `PG` private-government, `GG` government-government. Treat the list as incomplete. | | `catalog.providers[].descriptor.symbol` | string | Serial number assigned by PMBI | | `catalog.providers[].descriptor.short_desc` | string | May be empty | | `catalog.providers[].descriptor.long_desc` | string | May be empty | | `catalog.providers[].fulfillments[].type` | string | `contact`. This block carries the contact person. | | `catalog.providers[].fulfillments[].agent.name` | string | Contact person at the Kendra | | `catalog.providers[].fulfillments[].start.time.timestamp` | datetime | PMBJP enrolment date | | `catalog.providers[].location.gps` | string | `lat,long` of the Kendra | | `catalog.providers[].location.address` | string | Full street address | | `catalog.providers[].location.city.name` | string | May be empty | | `catalog.providers[].location.city.code` | string | May be empty | | `catalog.providers[].location.district.name` | string | District name | | `catalog.providers[].location.district.code` | string | District code | | `catalog.providers[].location.state.name` | string | State name | | `catalog.providers[].location.state.code` | string | State code | | `catalog.providers[].location.radius` | object | A distance with a unit, for example `1.19 km`. Present in responses, absent from the field reference, so what it is measured from is not stated. | | `catalog.providers[].location.country.name` | string | `INDIA`, fixed | | `catalog.providers[].location.country.code` | string | `+91`, fixed | | `catalog.providers[].contact.phone` | string | Kendra phone number | | `catalog.providers[].contact.email` | string | May be empty | ## Confirm at onboarding Two values are settled when you onboard. Build the flow and hold these until your onboarding contact confirms them. - **What goes in `category.descriptor` for a Kendra code search.** Both the Kendra code itself, for example `PMBJK02129`, and the literal string `Jan Aushadhi Kendra Code` are in circulation. Confirm which the HSPA accepts before you ship a Kendra code search. - **The HSPA identity in `on_search`.** Route on `transaction_id`, not on `provider_id`, so a change of provider host does not break your matching. ## Next - Searching for a medicine, then for the Kendras that stock it: [Jan Aushadhi medicine search](/docs/uhi/v1/concepts/services/jan-aushadhi-medicine-search) - Shared UHI protocol, signing and onboarding: [UHI services](/docs/uhi/v1) --- # Jan Aushadhi medicine search This is the two step version of Jan Aushadhi discovery: your user searches for a medicine by name, then you search again for the Kendras that carry it, with a stock flag on each. After this page you will know what changes from [Jan Aushadhi Kendra discovery](/docs/uhi/v1/concepts/services/jan-aushadhi-kendra), which is `fulfillment.type` and `item.descriptor` and nothing else. ## Who does what The same three parties as every [UHI](/docs/uhi/v1/getting-started/glossary#uhi) service. Your app is the [EUA](/docs/uhi/v1/getting-started/glossary#eua). [NHA](/docs/uhi/v1/getting-started/glossary#nha) runs the Gateway. PMBI runs the [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) that holds the medicine and stock data. Signing, onboarding and the Gateway base URLs are on [UHI services](/docs/uhi/v1). ## Message flow Two round trips, four calls in total. Each `search` gets an immediate HTTP 200 ACK from the Gateway, and the real answer arrives later on your `consumer_uri`. | Step | Call | Who acts | What comes back | | ---- | ----------- | --------------------- | -------------------------------------------------------------------------------------- | | 1 | `search` | Your system | ACK. The medicine catalogue arrives separately. | | 2 | `on_search` | PMBI HSPA via Gateway | Matching generic medicines, each with an ID, item code, price and pack size. | | 3 | `search` | Your system | ACK. You send the medicine ID your user picked, plus a location filter. | | 4 | `on_search` | PMBI HSPA via Gateway | Kendras that carry that medicine, each with an `items[]` entry holding the stock flag. | Both `on_search` responses carry the `transaction_id` of the `search` that triggered them. Use two separate `transaction_id` values, one per step, so you can tell the two responses apart. ## Service identity `domain` is the same as Kendra discovery. `fulfillment.type` is not. | Step | `domain` | `fulfillment.type` | `item.descriptor.code` and `.name` | | --------------------------- | --------------- | ---------------------- | ---------------------------------- | | Medicine search | `nic2008:47721` | `JANAUSHADHI_MEDICINE` | The medicine name | | Kendras stocking a medicine | `nic2008:47721` | `JANAUSHADHI_KENDRA` | The `medicineId` from step 1 | A plain Kendra search uses `JANAUSHADHI`. The two values `JANAUSHADHI_MEDICINE` and `JANAUSHADHI_KENDRA` apply to the medicine search document. See [Confirm at onboarding](#confirm-at-onboarding). ## Step 1: search by medicine name Put the medicine name in `item.descriptor`. The code is the name with spaces removed, and the name keeps its spaces. ```json { "context": { "domain": "nic2008:47721", "country": "IND", "city": "std:011", "action": "search", "core_version": "0.7.1", "consumer_id": "<YOUR_EUA_ID_FROM_NHA_ONBOARDING>", "consumer_uri": "<YOUR_HTTPS_CALLBACK_URL>", "message_id": "<FRESH_UUID_PER_CALL>", "timestamp": "2026-06-09T18:24:35", "transaction_id": "<FRESH_UUID_PER_SEARCH_SESSION>" }, "message": { "intent": { "fulfillment": { "type": "JANAUSHADHI_MEDICINE", "start": { "time": { "timestamp": "2026-06-09T00:00:00" } }, "end": { "time": { "timestamp": "2026-06-09T23:59:59" } } }, "item": { "descriptor": { "code": "<MEDICINE_NAME_WITHOUT_SPACES>", "name": "<MEDICINE_NAME>" } } } }} ``` ### on\_search: the medicine catalogue Each `providers[]` entry is one generic medicine, not a store. The `items[]` array inside it carries price and pack size. ```json { "context": { "domain": "nic2008:47721", "country": "IND", "city": "std:011", "action": "on_search", "core_version": "0.7.1", "consumer_id": "eua-nha", "consumer_uri": "http://uhieuasandbox.abdm.gov.in/api/v1/euaService", "provider_id": "janaushadhi-hspa", "provider_uri": "https://janaushadhi.gov.in:8443/api/v1/admin/kendra/", "message_id": "e9a19230-f951-11ec-b135-53aea776f66b", "timestamp": "2026-06-09T18:24:35", "transaction_id": "e9a19230-f951-11ec-b135-53aea776f66b" }, "message": { "catalog": { "descriptor": { "name": "JAN AUSHADHI KENDRA HSPA", "images": "<HSPA_LOGO_IMAGE_URL_SET_BY_PMBI>", "short_desc": "<HSPA_SHORT_DESCRIPTION_SET_BY_PMBI>", "long_desc": "<HSPA_LONG_DESCRIPTION_SET_BY_PMBI>" }, "providers": [ { "id": "78299", "descriptor": { "name": "3-way stopcock with 10 cm extension line", "code": "8150.0", "symbol": "", "short_desc": "", "long_desc": "" }, "items": [ { "id": "0", "price": { "currency": "INR", "value": "20.0" }, "quantity": { "measure": { "value": 10, "unit": "s" } } } ] } ] } }} ``` Sample values appear on this page as the value only, without the annotation pair. The `catalog.descriptor` fields carry descriptive prose rather than real values, so they appear here as written. | Field path | Type | Description | | ---------------------------------------------------- | ------ | --------------------------------------------------------------------- | | `catalog.providers[].id` | string | `medicineId`. This is what you send back in step 2. | | `catalog.providers[].descriptor.name` | string | Generic name of the medicine | | `catalog.providers[].descriptor.code` | string | PMBI item code, for example `8150.0` | | `catalog.providers[].items[].price.currency` | string | `INR` | | `catalog.providers[].items[].price.value` | string | MRP | | `catalog.providers[].items[].quantity.measure.value` | number | Unit size, for example `10` | | `catalog.providers[].items[].quantity.measure.unit` | string | Unit of the pack: `s`, `ml`, `sachet`, `drops`, `mg` or `tetra pack`. | ## Step 2: search for Kendras stocking that medicine Change `fulfillment.type` to `JANAUSHADHI_KENDRA` and put the `medicineId` in `item.descriptor`. Add whichever location filter your user chose: state and district, pincode, or GPS and radius. The filter fields are the same as on [Jan Aushadhi Kendra discovery](/docs/uhi/v1/concepts/services/jan-aushadhi-kendra). ```json { "context": { "domain": "nic2008:47721", "country": "IND", "city": "std:011", "action": "search", "core_version": "0.7.1", "consumer_id": "<YOUR_EUA_ID_FROM_NHA_ONBOARDING>", "consumer_uri": "<YOUR_HTTPS_CALLBACK_URL>", "message_id": "<FRESH_UUID_PER_CALL>", "timestamp": "2026-06-19T18:24:35", "transaction_id": "<FRESH_UUID_PER_SEARCH_SESSION>" }, "message": { "intent": { "fulfillment": { "type": "JANAUSHADHI_KENDRA", "start": { "time": { "timestamp": "2026-06-19T00:00:00" } }, "end": { "time": { "timestamp": "2026-06-19T23:59:59" } } }, "item": { "descriptor": { "code": "78299", "name": "78299" } }, "location": { "district": { "code": "507", "name": "HYDERABAD" }, "state": { "code": "36", "name": "Telangana" } } } }} ``` ### on\_search: Kendras with stock Kendra records, the same shape as Kendra discovery, with one addition: each Kendra carries an `items[]` entry for the medicine you asked about, and that entry has a `flag` for stock. ```json { "context": { "domain": "nic2008:47721", "country": "IND", "city": "std:011", "action": "on_search", "core_version": "0.7.1", "consumer_id": "eua-nha", "consumer_uri": "http://uhieuasandbox.abdm.gov.in/api/v1/euaService", "provider_id": "janaushadhi-hspa", "provider_uri": "https://janaushadhi.gov.in:8443/api/v1/admin/kendra/", "message_id": "e9a19230-f951-11ec-b135-53aea776f66b", "timestamp": "2026-06-09T18:24:35", "transaction_id": "e9a19230-f951-11ec-b135-53aea776f66b" }, "message": { "catalog": { "descriptor": { "name": "JAN AUSHADHI KENDRA HSPA", "images": "<HSPA_LOGO_IMAGE_URL_SET_BY_PMBI>", "short_desc": "<HSPA_SHORT_DESCRIPTION_SET_BY_PMBI>", "long_desc": "<HSPA_LONG_DESCRIPTION_SET_BY_PMBI>" }, "providers": [ { "id": "PMBJK01472", "descriptor": { "name": "Jan Aushadhi Kendra2", "code": "PP", "symbol": "2", "short_desc": "", "long_desc": "" }, "fulfillments": [ { "id": "0", "type": "contact", "agent": { "name": "GOPAL RAMBHAU KARALE" }, "start": { "time": { "timestamp": "2018-03-22T12:00:00" } } } ], "items": [ { "id": "78299", "descriptor": { "name": "3-way stopcock with 10 cm extension line", "code": "8150.0", "symbol": "", "short_desc": "", "flag": false }, "quantity": { "measure": { "value": 10, "unit": "s" } } } ], "location": { "id": "1", "descriptor": { "name": "Jan Aushadhi Kendra2" }, "city": { "name": "", "code": "" }, "district": { "name": "Akola", "code": "467" }, "state": { "name": "Maharashtra", "code": "27" }, "country": { "name": "INDIA", "code": "+91" }, "gps": "20.6838699,77.02622334", "address": "Shop no.1 basement, Radha Krishna complex, behind Harsh sankul, opp. S.A.college", "radius": { "type": "CONSTANT", "value": "0.4", "unit": "km" } }, "contact": { "phone": "9881461949", "email": "" } } ] } }} ``` The fields that are new compared with a plain Kendra record: | Field path | Type | Description | | ---------------------------------------------------- | ------- | ---------------------------------------------------------------------------------------------------- | | `catalog.providers[].items[].id` | string | `medicineId`, matching the one you sent | | `catalog.providers[].items[].descriptor.name` | string | Generic name of the medicine | | `catalog.providers[].items[].descriptor.code` | string | PMBI item code | | `catalog.providers[].items[].descriptor.flag` | boolean | Stock indicator for this medicine at this Kendra | | `catalog.providers[].items[].quantity.measure.value` | number | Unit size | | `catalog.providers[].items[].quantity.measure.unit` | string | Unit of the pack | | `catalog.providers[].location.radius` | object | A distance with a unit, for example `0.4 km`. Present in responses, absent from the field reference. | Every other field on the provider record is documented in the [Kendra discovery field reference](/docs/uhi/v1/concepts/services/jan-aushadhi-kendra#field-reference). `flag` arrives as `false` on both sample records. Confirm its polarity with your onboarding contact before you render "in stock" or "out of stock" to a user. ## Confirm at onboarding Four values are issued or confirmed when you onboard. Build the flow, and hold these until your onboarding contact confirms them. - **The service type value.** Send the value your onboarding pack gives. Both `JANAUSHADHI` and `JANAUSHADHI_MEDICINE` are in circulation for this search. - **The polarity of `descriptor.flag`.** It arrives as `false` on stocked and unstocked records alike. Do not render "in stock" or "out of stock" from it until the polarity is confirmed. - **Whether a location filter is accepted.** The medicine search sends the medicine name in `item.descriptor` and no `location` block. Send the name only. - **The HSPA identity.** Route on `transaction_id`, not on `provider_id`, so a change of provider host does not break your matching. ## Next - Kendra discovery without a medicine filter: [Jan Aushadhi Kendra discovery](/docs/uhi/v1/concepts/services/jan-aushadhi-kendra) - Shared UHI protocol, signing and onboarding: [UHI services](/docs/uhi/v1) --- # Physical consultation Physical consultation is the fullest service on [UHI](/docs/uhi/v1/getting-started/glossary#uhi). A patient searches for a doctor, then sees real slots and fees from clinics they have no prior relationship with. They book one, and receive a 4-digit PIN to present at the clinic. After this page you will know the four stages, the endpoints each role exposes, and the fields on every call, as [NHA](/docs/uhi/v1/getting-started/glossary#nha) documents them. Read [UHI services](/docs/uhi/v1) first, for the `context` block, the acknowledgement model, signing and the two transports. ## Where this service stands The full consultation lifecycle is the first phase, live and open for onboarding. Online payment and refunds are the second phase, in ideation. Today the only payment model is pay on visit. ## Service identity Every call in this service carries these fixed values. | Field | Value | | ------------------------------------- | --------------------------- | | `context.domain` | `nic2004:85111` | | `context.core_version` | `0.7.1` | | `message.intent.fulfillment.type` | `Physical` (case sensitive) | | `message.intent.item.descriptor.code` | `Consultation` | | `message.intent.item.descriptor.name` | `Consultation` | ## Who is involved | Actor | Role here | | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | [EUA](/docs/uhi/v1/getting-started/glossary#eua) | The patient facing app. Searches, books, shows the PIN and the status. | | [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) | The provider platform. Holds doctor profiles and slots, confirms bookings, generates the PIN, drives the lifecycle. | | HSP | The hospital, clinic or doctor. The HSPA is its digital interface. | | [Gateway](/docs/uhi/v1/getting-started/glossary#gateway) | The routing layer. Involved in discovery only. | | NHA | Network operator. Governs onboarding, compliance and the protocol. | ## The flow end to end ```mermaid sequenceDiagram participant P as Patient participant EUA as Your EUA participant GW as HIE-CM gateway participant H as HSPA P->>EUA: Search for a cardiologist EUA->>GW: search (broadcast) GW->>H: search H->>GW: on_search (doctor catalog) GW->>EUA: on_search P->>EUA: Pick Dr Mehra EUA->>H: search (direct, for that doctor's slots) H->>EUA: on_search (slots) P->>EUA: Pick a slot EUA->>H: init H->>EUA: on_init (order id, quote, 5 terms) P->>EUA: Agree to terms EUA->>H: confirm (all terms AGREED) H->>EUA: on_confirm (CONFIRMED, 4-digit PIN) Note over P,H: Patient visits the clinic and shows the PIN H->>EUA: on_update (APPOINTMENT_STARTED) H->>EUA: on_update (COMPLETED) ``` ## Stage by stage | Stage | Calls | Transport | | ------------------ | ------------------------------------------ | ---------------------------------------------- | | 1. Discovery | `search` and `on_search`, twice | First pair via the gateway, second pair direct | | 2. Booking | `init`, `on_init`, `confirm`, `on_confirm` | Direct | | 3. Fulfilment | `status`, `on_status`, `on_update` | Direct | | 4. Post-fulfilment | `cancel`, `on_cancel`, `on_message` | Direct | ## Endpoints you expose An HSPA exposes these. Everything except the first `search` is called by an EUA directly. | Endpoint | Called by | What you do | | ------------------ | ------------------------------------------------- | -------------------------------------------------------- | | `/search` (first) | Gateway broadcast, with `X-Gateway-Authorization` | Query your doctor catalog, answer via `on_search` | | `/search` (second) | EUA, direct | Return slots for the selected doctor | | `/init` | EUA, direct | Hold the slot, answer with terms via `on_init` | | `/confirm` | EUA, direct | Confirm the appointment, return the PIN via `on_confirm` | | `/status` | EUA, direct | Return the current order state via `on_status` | | `/cancel` | EUA, direct | Process the cancellation, answer via `on_cancel` | | `/on_update` | EUA, direct | Receive a `DOCTOR_NO_SHOW` state from the EUA | | `/on_message` | EUA, direct | Receive a chat message or file from the patient | An EUA exposes these. Everything except the first `on_search` is called by the HSPA directly. | Endpoint | Called by | What you do | | --------------------- | --------------------------------------- | -------------------------------------------------------- | | `/on_search` (first) | Gateway, with `X-Gateway-Authorization` | Aggregate catalogs, store each `provider_uri` | | `/on_search` (second) | HSPA, direct | Show the slots for the chosen doctor | | `/on_init` | HSPA, direct | Show all terms to the patient, store `order.id` | | `/on_confirm` | HSPA, direct | Show the PIN, store the order | | `/on_status` | HSPA, direct | Replace your stored order state | | `/on_update` | HSPA, direct | Update state and notify the patient | | `/on_cancel` | HSPA, direct | Mark the appointment cancelled | | `/on_message` | HSPA, direct | Show the message from the provider. Mandatory for an EUA | ## Stage 1: discovery ### First search, broadcast Your EUA posts to the gateway. The gateway validates your signature and the domain, then forwards to every registered HSPA in that domain. Search filters go in `message.intent`. ```http POST https://uhigatewaysandbox.abdm.gov.in/api/v1/uhi/search ``` | Field | Type | Required | What it is | | ---------------------------------- | -------- | ----------- | ----------------------------------------------------------------------------------------------- | | `fulfillment.type` | string | Yes | `Physical`. Case sensitive | | `fulfillment.agent.name` | string | No | Doctor name, for a name search | | `fulfillment.agent.id` | string | No | Doctor [HPR](/docs/uhi/v1/getting-started/glossary#hpr) address, for example `drmehra@hpr.ndhm` | | `fulfillment.start.time.timestamp` | datetime | Yes | Start of the search window | | `fulfillment.end.time.timestamp` | datetime | Yes | End of the search window | | `item.descriptor.code` | string | Yes | `Consultation` | | `item.descriptor.name` | string | Yes | `Consultation` | | `category.descriptor.code` | string | No | Speciality code, for example `CARDIOLOGY` | | `category.descriptor.name` | string | No | Speciality name, for example `Cardiology` | | `location.gps` | string | Conditional | `latitude,longitude` for a proximity search | | `location.radius.type` | string | Conditional | `CONSTANT` when using GPS | | `location.radius.value` | string | Conditional | Radius in km, for example `"10"` | | `location.radius.unit` | string | Conditional | `km` | | `location.city.name` | string | No | City name | | `location.city.code` | string | No | City STD code | | `address.area_code` | string | No | 6-digit pincode | | `provider.descriptor.name` | string | No | Facility name | | `provider.id` | string | No | Provider ID, used in the second search | A search by state and district: ```json { "context": { "action": "search", "city": "std:011", "consumer_id": "<YOUR_EUA_ID_FROM_NHA_ONBOARDING>", "consumer_uri": "<YOUR_HTTPS_CALLBACK_URL>", "core_version": "0.7.1", "country": "IND", "domain": "nic2004:85111", "message_id": "e9a19230-f951-11ec-b135-53aea776f66b", "timestamp": "2026-06-18T06:52:13.969464Z", "transaction_id": "e9a19230-f951-11ec-b135-53aea776f66b" }, "message": { "intent": { "fulfillment": { "type": "Physical", "start": { "time": { "timestamp": "2026-06-18T10:37:32" } }, "end": { "time": { "timestamp": "2026-06-18T23:59:59" } } }, "item": { "descriptor": { "code": "Consultation", "name": "Consultation" } }, "location": { "state": { "name": "MAHARASHTRA", "code": "27" }, "district": { "name": "PUNE", "code": "490" } } } }} ``` Three warnings apply to this call: - A GPS search needs all three radius fields. Omit any one and the GPS filter is ignored without an error. - The `transaction_id` in `search` must match the one in the `on_search` that answers it, or you cannot correlate the response. - More filter combinations exist. The Swagger spec is the list. ### First on\_search, the catalog Each matching HSPA answers independently, so you receive several. Aggregate them on `transaction_id`. | Field | Required | What it is | | --------------------------------------------------------- | -------- | -------------------------------------------------------------------------------------- | | `context.provider_uri` | Yes | The HSPA base URL. Store this. Every later call goes here | | `message.catalog.descriptor.name` | Yes | HSPA name | | `catalog.providers[].id` | Yes | Provider or hospital ID within this HSPA | | `catalog.providers[].descriptor.name` | Yes | Hospital or clinic name | | `catalog.providers[].categories[].descriptor.name` | Yes | Speciality name | | `catalog.providers[].categories[].descriptor.code` | Yes | Speciality code | | `catalog.providers[].fulfillments[].id` | Yes | Slot UUID. This becomes `fulfillment.id` in `init` | | `catalog.providers[].fulfillments[].type` | Yes | `Physical` | | `catalog.providers[].fulfillments[].agent.id` | Yes | Doctor HPR ID | | `catalog.providers[].fulfillments[].agent.name` | Yes | Doctor's registered name | | `catalog.providers[].fulfillments[].agent.gender` | No | `M` or `F` | | `catalog.providers[].fulfillments[].agent.tags` | No | `@abdm/gov.in/experience`, `/languages`, `/education`, `/hpr_id`, `/hfr_id`, `/hip_id` | | `catalog.providers[].fulfillments[].start.time.timestamp` | Yes | Slot start | | `catalog.providers[].fulfillments[].end.time.timestamp` | Yes | Slot end | | `catalog.providers[].items[].id` | Yes | Item ID. This becomes `order.item.id` in `init` | | `catalog.providers[].items[].price.value` | Yes | Fee in INR, as a decimal string | | `catalog.providers[].items[].fulfillment_id` | Yes | Links the item to its slot | | `catalog.providers[].location.gps` | No | Provider coordinates | | `catalog.providers[].location.address` | No | Provider street address | Trimmed to one provider: ```json { "context": { "domain": "nic2004:85111", "action": "on_search", "consumer_id": "<YOUR_EUA_ID_FROM_NHA_ONBOARDING>", "provider_id": "hspa-nha", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1/hspa", "transaction_id": "a1b2c3d4-f951-11ec-b135-53aea776f66b", "message_id": "b2c3d4e5-f951-11ec-b135-53aea776f66b" }, "message": { "catalog": { "descriptor": { "name": "ABDM Reference HSPA" }, "providers": [ { "id": "1", "descriptor": { "name": "Safdarjung Medical Centre" }, "categories": [ { "id": "201", "parent_category_id": "101", "descriptor": { "name": "Cardiology", "code": "CARDIOLOGY" } }, { "id": "101", "descriptor": { "name": "Allopathy", "code": "ALLOPATHY" } } ], "fulfillments": [ { "id": "slot-uuid-a1b2c3d4-abcd-1234-efgh-567890abcdef", "type": "Physical", "agent": { "id": "priyamehra@hpr.ndhm", "name": "Dr. Priya Mehra", "gender": "F", "tags": { "@abdm/gov.in/experience": "8.0", "@abdm/gov.in/languages": "Hindi, English", "@abdm/gov.in/education": "MBBS, MD Cardiology", "@abdm/gov.in/hpr_id": "73-5232-1888-8686" } }, "start": { "time": { "timestamp": "2026-04-16T10:00:00" } }, "end": { "time": { "timestamp": "2026-04-16T10:20:00" } } } ], "items": [ { "id": "0", "descriptor": { "name": "Consultation", "code": "CONSULTATION" }, "price": { "currency": "INR", "value": "500.0" }, "fulfillment_id": "slot-uuid-a1b2c3d4-abcd-1234-efgh-567890abcdef" } ], "location": { "gps": "28.635308,77.224960", "address": "Safdarjung Enclave, New Delhi 110029", "city": { "name": "Delhi", "code": "011" } } } ] } }} ``` An HSPA sends the full `agent.tags` set including `@abdm/gov.in/hip_id`. That ID is what lets records generated at the visit be pulled later. ### Second search, direct After the patient picks a doctor, your EUA sends a second `search` straight to the HSPA's `provider_uri`, asking for that doctor's slots in a time window. It carries `provider_id` and `provider_uri` in the context, and echoes the `provider`, `fulfillments` and `items` blocks from the first `on_search`. The HSPA answers with a second `on_search` scoped to that doctor. ## Stage 2: booking ### init Direct to the HSPA. You send the patient's details and the chosen slot. The HSPA holds the slot temporarily. | Field | Required | What it is | | ---------------------------------------- | ----------- | ------------------------------------------------------------------------------------------------ | | `order.provider.id` | Yes | Provider ID from the catalog | | `order.item.id` | Yes | Item ID from the catalog | | `order.item.descriptor.code` | Yes | `Consultation` | | `order.item.descriptor.name` | Yes | `Consultation` | | `order.item.price.currency` | No | `INR` | | `order.item.price.value` | No | Fee as a decimal string | | `order.item.fulfillment_id` | Yes | Slot UUID from the catalog | | `order.fulfillment.id` | Yes | The same slot UUID | | `order.fulfillment.type` | Yes | `Physical` | | `order.fulfillment.agent.id` | Yes | Doctor HPR ID | | `order.fulfillment.agent.name` | Yes | Doctor's registered name | | `order.fulfillment.start.time.timestamp` | Yes | Slot start | | `order.fulfillment.end.time.timestamp` | Yes | Slot end | | `order.fulfillment.tags` | Conditional | `@abdm/gov.in/slot_id` is mandatory and holds the slot UUID | | `order.billing.name` | Yes | Patient billing name | | `order.billing.address` | Yes | Object with `door`, `name`, `locality`, `city`, `state`, `country`, `area_code` | | `order.billing.phone` | Yes | 10-digit contact number | | `order.billing.email` | No | Patient email | | `order.customer.id` | Yes | Patient [ABHA](/docs/uhi/v1/getting-started/glossary#abha) address, for example `rahul.k001@sbx` | | `order.customer.person.gender` | No | `M` or `F` | | `order.customer.person.dob` | No | `YYYY-MM-DD` | | `order.payment.type` | Yes | `ON-ORDER` for pay on visit. Other values: `PRE-FULFILLMENT`, `ON-FULFILLMENT` | | `order.payment.params.redirect_url` | No | Payment callback URL | ```json { "context": { "domain": "nic2004:85111", "country": "IND", "city": "std:011", "action": "init", "core_version": "0.7.1", "consumer_id": "<YOUR_EUA_ID_FROM_NHA_ONBOARDING>", "consumer_uri": "<YOUR_HTTPS_CALLBACK_URL>", "provider_id": "hspa-nha", "provider_uri": "https://hspasbx.abdm.gov.in/api/v1/hspa", "transaction_id": "a1b2c3d4-f951-11ec-b135-53aea776f66b", "message_id": "d4e5f6a7-32af-11ef-bcbe-590b07ce8c90", "timestamp": "2026-04-15T09:10:00Z" }, "message": { "order": { "provider": { "id": "1" }, "item": { "id": "0", "descriptor": { "name": "Consultation", "code": "CONSULTATION" }, "price": { "currency": "INR", "value": "500.0" }, "fulfillment_id": "slot-uuid-a1b2c3d4-abcd-1234-efgh-567890abcdef" }, "fulfillment": { "id": "slot-uuid-a1b2c3d4-abcd-1234-efgh-567890abcdef", "type": "Physical", "agent": { "id": "priyamehra@hpr.ndhm", "name": "Dr. Priya Mehra" }, "start": { "time": { "timestamp": "2026-04-16T10:00:00" } }, "end": { "time": { "timestamp": "2026-04-16T10:20:00" } } }, "billing": { "name": "Rahul Kumar Sharma", "address": { "door": "B-204", "name": "Rahul Kumar Sharma", "locality": "Rohini Sector 14", "city": "Delhi", "state": "Delhi", "country": "INDIA", "area_code": "110085" }, "phone": "9876543210", "email": "rahul.sharma@email.com" }, "customer": { "id": "rahul.k001@sbx", "person": { "gender": "M", "dob": "1990-05-15", "dayOfBirth": 15, "monthOfBirth": 5, "yearOfBirth": 1990 } }, "payment": { "type": "ON-ORDER", "params": { "redirect_url": "<YOUR_PAYMENT_REDIRECT_URL>" } } } }} ``` Two warnings: - `fulfillment.id` must be exactly the slot UUID from `on_search`. A mismatch makes the HSPA reject the call or fail to hold the slot without telling you. - The hold is short, typically 15 minutes. If `confirm` does not arrive in time the slot is released and you start again at `init`. ### on\_init, the terms The HSPA answers with the order ID, an itemised quote, and five term objects the patient has to accept. | Field added by the HSPA | What it is | | ----------------------- | -------------------------------------------------------------------------------------------------------------------- | | `order.id` | The HSPA's order ID, generated here. Send it in every later call. Use an alphanumeric string, for example `AHS12345` | | `order.terms[]` | Five term objects, each with `termsState: "INITIATED"` | | `order.quote` | Price breakup: consultation, SGST, CGST, registration | | `order.payment.type` | `ON-ORDER`, `FREE` or `PRE-ORDER` | | `order.payment.status` | `NOT_PAID` or `FREE` | Each term object: | Field | Required | What it is | | ------------------------------- | ----------- | ----------------------------------------------------------------- | | `terms[].type` | Yes | `Commercial`, `Settlement`, `Cancellation`, `Refund` or `Payment` | | `terms[].descriptor.name` | Yes | Term title | | `terms[].descriptor.short_desc` | No | Brief description | | `terms[].descriptor.long_desc` | No | Full text. Show this to the patient | | `terms[].reasonRequired` | Yes | If true, a reason is needed when this term is actioned | | `terms[].timePeriod` | Yes | Validity. Copy unchanged into `confirm` | | `terms[].reason` | Conditional | Required in `confirm` when `reasonRequired` is true | | `terms[].termsState` | Yes | `INITIATED` here. You set `AGREED` in `confirm` | Store every term object exactly as received. Change only `termsState`, and `reason` where it is required. ### confirm Send the whole order back with every term at `AGREED`. Any term still at `INITIATED` and the HSPA rejects the call. Use the `order.id` the HSPA assigned in `on_init`, not any ID you generated. ### on\_confirm, the PIN The HSPA sets `order.state` to `CONFIRMED` and returns a 4-digit PIN. | Field | What it is | | --------------------------------------------- | ----------------------------------------------------- | | `order.state` | `CONFIRMED`, or `FAILED` on a payment or system error | | `order.id` | The HSPA's order ID | | `order.authorization.type` | `PIN` | | `order.authorization.token` | The 4-digit PIN | | `order.authorization.valid_from` | PIN validity start | | `order.authorization.valid_to` | PIN validity end, usually end of the appointment day | | `order.authorization.status` | `GENERATED` here | | `order.fulfillment.tags.@abdm/gov.in/slot_id` | The confirmed slot UUID | ```json { "authorization": { "type": "PIN", "token": "3774", "valid_from": "2026-06-18T00:00:00", "valid_to": "2026-06-18T23:59:00", "status": "GENERATED" }} ``` The PIN is security sensitive. Hold it in memory or secure session storage on the EUA. Do not write it to a database or to application logs. The HSPA has two more obligations here. It sends an exact copy of the `on_confirm` payload to the gateway audit endpoint listed under [gateway endpoints](#gateway-endpoints), and it sets the communication tags on the fulfilment: ```json { "tags": { "@abdm/gov.in/slot_id": "79db6b5b-afe4-4297-b9b1-5148ed45372c", "@abdm/gov.in/messaging_support": "true", "@abdm/gov.in/deep_link": "", "@abdm/gov.in/helpline_number": "", "@abdm/gov.in/chatbot_link": "" }} ``` `messaging_support` and a helpline number are mandatory in `on_confirm`. ## Stage 3: fulfilment ### status and on\_status `status` carries only `order.id`. The HSPA answers with the full order object, and you replace your stored state with it. This is reconciliation, not a polling loop. ### Order states | State | Set by | Meaning | | --------------------- | ------------------------------- | ----------------------------------------------- | | `CONFIRMED` | HSPA, in `on_confirm` | Booked. PIN generated | | `APPOINTMENT_STARTED` | HSPA, in `on_update` | The doctor has begun the consultation | | `COMPLETED` | HSPA, in `on_update` | The doctor has marked the consultation complete | | `CANCELLED` | HSPA or EUA | Cancelled under the agreed terms | | `NO_SHOW` | HSPA, in `on_update` | The patient did not appear | | `DOCTOR_NO_SHOW` | EUA, in `on_update` to the HSPA | The doctor did not appear | | `FAILED` | HSPA, in `on_confirm` | Payment or system failure at confirmation | `DOCTOR_NO_SHOW` is the only state an EUA may set. Everything else is the HSPA's. ### PIN states | State | Meaning | | --------------- | ------------------------------------------------------- | | `GENERATED` | Set when the PIN is created at confirmation | | `VERIFIED` | The provider checked the PIN before the consultation | | `HSPA_OVERRIDE` | The PIN was not checked and the HSPA overrode the check | ### on\_update The HSPA pushes state changes to your `/on_update` as they happen. This is the main real-time channel, not `status`. Update your local state and notify the patient. ## Stage 4: post-fulfilment ### cancel and on\_cancel | Field | Required | What it is | | ------------------------------------------------- | -------- | --------------------- | | `order.id` | Yes | The order to cancel | | `order.state` | Yes | `CANCELLED` | | `order.fulfillment.tags.@abdm/gov.in/cancelledby` | Yes | `patient` or `doctor` | ```json { "message": { "order": { "id": "0415-234567-8901", "state": "CANCELLED", "fulfillment": { "tags": { "@abdm/gov.in/cancelledby": "patient" } } } }} ``` The `cancelledby` tag is mandatory. Without it the HSPA cannot tell which set of cancellation terms applies. Your `/on_cancel` handler has to cope with both directions: the HSPA's acknowledgement of a patient cancellation, and an HSPA-initiated cancellation when a doctor cancels. Read the `cancelledby` tag to tell them apart. ### on\_message Optional for an HSPA, mandatory for an EUA. Both sides consume the same shape. Content sits under `message.intent.chat`. | Field | Required | What it is | | ------------------------------- | ----------- | ---------------------------------------------------------------- | | `chat.sender.person.id` | Yes | ABHA address of the sender, or HPR ID when the doctor sends | | `chat.sender.person.name` | Yes | Sender's name | | `chat.receiver.person.id` | Yes | HPR ID of the doctor, or ABHA address of the patient | | `chat.receiver.person.name` | Yes | Receiver's name | | `chat.content.content_id` | Yes | UUID for this message | | `chat.content.content_value` | Yes | Base64-encoded text or file | | `chat.content.content_type` | Yes | `text` or `media` | | `chat.content.content_mimeType` | Conditional | MIME type when `content_type` is `media` | | `chat.content.content_fileName` | Conditional | File name when `content_type` is `media` | | `chat.content.hiType` | Conditional | Health information type, for example `prescription`, `labReport` | | `chat.time.timestamp` | Yes | Message time | ## Gateway endpoints You do not build these. NHA operates them. | Endpoint | Called by | Purpose | | ------------------------------------- | --------- | -------------------------------------------------------------- | | `POST /api/v1/uhi/search` | EUA | Broadcast a search to all registered HSPAs | | `POST /api/v1/uhi/on_search` | HSPA | Deliver a catalog, which the gateway forwards to the EUA | | `POST /api/v1/uhi/on_confirm_audit` | HSPA | Exact copy of every `on_confirm` | | `POST /api/v1/uhi/on_update_audit` | HSPA | Exact copy of every `on_update`. The care context ID goes here | | `POST /api/v1/uhi/on_cancel_audit` | HSPA | Exact copy of every `on_cancel` | | `POST /api/v1/uhi/on_status_audit` | HSPA | Exact copy of every `on_status` | | `POST /api/v1/networkregistry/lookup` | Either | Look up a counterparty's public key | The audit copies are an HSPA obligation for compliance traceability, not optional. ## Cancellation reason codes The reason codes are fixed. You choose the labels your users see. ### Patient-initiated, sent in `cancel` with `cancelledby: patient` | Code | Meaning | | ------------------------------------ | ------------------------------------------------------ | | `PATIENT_PERSONAL_EMERGENCY` | Patient or family emergency | | `PATIENT_HEALTH_IMPROVED` | Condition resolved, consultation no longer needed | | `PATIENT_UNABLE_TO_VISIT_PHYSICALLY` | Scheduling conflict or inability to reach the facility | | `DOCTOR_ASKED_TO_CANCEL` | The doctor asked the patient to cancel | | `PATIENT_BOOKED_IN_ERROR` | Wrong doctor, speciality, date or time | | `PATIENT_SEEKING_ALTERNATIVE` | Patient has decided to see someone else | | `PATIENT_OTHER` | Anything else. Your EUA must capture free text | ### Doctor or facility-initiated, sent in `on_cancel` with `cancelledby: doctor` | Code | Meaning | | --------------------------- | ------------------------------------------------------ | | `DOCTOR_PERSONAL_EMERGENCY` | Unplanned personal or medical emergency | | `DOCTOR_UNAVAILABLE` | Unexpected surgery, patient emergency or high footfall | | `DOCTOR_SCHEDULE_CHANGE` | Session timings changed | | `FACILITY_CLOSURE` | Facility temporarily closed | | `TECHNICAL_SYSTEM_ISSUE` | HSPA platform failure or downtime | | `DOCTOR_OTHER` | Anything else. The HSPA must provide free text | ### PIN override, used by facility staff | Code | When it applies | | --------------------------------- | ---------------------------------------------------------- | | `OVERRIDE_EMERGENCY_CONSULTATION` | Patient arrives in acute distress | | `OVERRIDE_PIN_TECH_FAILURE` | The app cannot show the PIN. Identity verified another way | | `OVERRIDE_PIN_DELIVERY_FAILURE` | The PIN never reached the patient | | `OVERRIDE_VULNERABLE_PATIENT` | Elderly, differently-abled or low digital literacy patient | | `OVERRIDE_EUA_OUTAGE` | The EUA platform is down | | `OVERRIDE_MISMATCH` | PIN could not be validated after three attempts | | `OVERRIDE_OTHER` | Anything else. The HSPA must provide free text | ## Terms and conditions text The `on_init` terms array carries the text the patient reads before confirming. Sample clauses are published. Two points carry through all of them. - UHI is a technology gateway. It does not supervise providers, does not guarantee outcomes, and does not collect, hold or route any payment. - Every payment, refund, cancellation charge and pricing dispute is between the patient and the facility. ## Field and error reference The tables above carry the fields you send and receive most. For the complete order field list, use the [Swagger spec](https://uhigatewaysandbox.abdm.gov.in/swagger-ui/index.html?urls.primaryName=v2.0.2#/). Error codes for this service are not published as a list. The error object carries `type` and `code`, both mandatory, with `path` and `message` optional. ## Next - [UHI services](/docs/uhi/v1) for the shared protocol - [Ambulance booking](/docs/uhi/v1/concepts/services/ambulance-booking) - [Blood bank](/docs/uhi/v1/concepts/services/blood-bank) - [M2](/docs/hiecm/v3/api/m2), the prerequisite - [Support](/docs/support) --- # PM-JAY HEM hospital discovery PM-JAY is India's national health insurance scheme, and HEM is the Hospital Empanelment Management system that knows which hospitals are empanelled right now. After this page you will know the six ways to search HEM over UHI, and every field that comes back. ## Who does what This is an [EUA](/docs/uhi/v1/getting-started/glossary#eua) side integration. [NHA](/docs/uhi/v1/getting-started/glossary#nha) runs the single [HSPA](/docs/uhi/v1/getting-started/glossary#hspa). No third party builds one for this service. | Party | Who runs it | What it does here | | -------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------ | | EUA | You, or any [PHR](/docs/uhi/v1/getting-started/glossary#phr) app | Sends the `search`. Receives the `on_search`. Renders the hospital list. | | [UHI](/docs/uhi/v1/getting-started/glossary#uhi) Gateway | NHA | Validates and routes the `search`. Relays the `on_search` back to you. | | PM-JAY HEM HSPA | NHA | Queries the HEM database. Builds the `on_search` catalog. | Signing, onboarding and Gateway base URLs are shared across UHI. See [UHI services](/docs/uhi/v1). ## Before you onboard Your application must have completed [HIE-CM](/docs/uhi/v1/getting-started/glossary#hie-cm) Milestone 2 as an [ABDM](/docs/uhi/v1/getting-started/glossary#abdm) compliant application. The network's document states that applications without M2 cannot be onboarded onto UHI services, PM-JAY HEM included. If you have not done that, start at [M2](/docs/hiecm/v3/api/m2). You also need: - A publicly reachable HTTPS callback URL for `on_search` responses. - UHI request signing in place, Ed25519 signatures over a BLAKE-512 body hash. - Code that treats `search` as fire and forget. Do not block waiting for a synchronous reply. ## Message flow Two calls, discovery only. Booking and referral are a later phase. The HTTP 200 from the Gateway confirms receipt, nothing more. | Step | Who acts | What happens | | ---- | --------------- | -------------------------------------------------------------------- | | 1 | Your system | POST `/search` to the Gateway with state, plus any optional filters. | | 2 | Gateway | Returns HTTP 200 ACK immediately. | | 3 | Gateway | POSTs the `search` to the PM-JAY HEM HSPA. | | 4 | PM-JAY HEM HSPA | Queries the HEM database. | | 5 | PM-JAY HEM HSPA | POSTs `on_search` to the Gateway with matching hospital records. | | 6 | Gateway | POSTs the `on_search` to your `consumer_uri`. | | 7 | Your system | ACKs the `on_search` and renders the hospital list. | Both calls can return NACK as well as ACK. Match a response to its request by `context.transaction_id`. ## Service identity These values are case sensitive. If any of them is wrong, no HSPA answers your search and you get nothing back. | Parameter | Value | Where it goes | | ---------------------- | --------------- | ------------------------------------- | | `domain` | `nic2004:85112` | `context.domain` in every call | | `fulfillment.type` | `PMJAYHEM` | `message.intent.fulfillment.type` | | `item.descriptor.code` | `PMJAY` | `message.intent.item.descriptor.code` | | `item.descriptor.name` | `PMJAY` | `message.intent.item.descriptor.name` | | `item.descriptor.flag` | `false` | `message.intent.item.descriptor.flag` | ## Search filters State is mandatory in every search. The other five filters are optional and stack on top of it. | Search type | Mandatory | Optional fields added | Use case | | ----------------------- | -------------------------- | ------------------------------------------------------------ | ------------------------------------ | | State only | `state.name`, `state.code` | none | Every empanelled hospital in a state | | State and district | `state.name`, `state.code` | `district.name`, `district.code` | Narrow to one district | | State and speciality | `state.name`, `state.code` | `category.descriptor.name`, `category.descriptor.code` | Filter by clinical speciality | | State and facility name | `state.name`, `state.code` | `provider.descriptor.name` | Find a hospital by name | | State and pincode | `state.name`, `state.code` | `address.area_code` | Search a pincode area | | State and GPS | `state.name`, `state.code` | `location.gps`, `radius.type`, `radius.value`, `radius.unit` | Proximity search | State and district names go in capitals, for example `ANDHRA PRADESH`. Note that `address` is a sibling of `fulfillment` inside `message.intent`, not a child of `location`. To get the speciality codes for `category.descriptor.code`, call the PM-JAY speciality list endpoint. ```bash # Sandboxcurl --location 'https://apisbeta.nha.gov.in/pmjay/payer/hbp/get/scheme/specialities' \ --header 'Accept: application/json' \ --header 'source: internal' \ --header 'Content-Type: application/json' \ --header 'pid: 33222' \ --data '{"schemecode": "PMJAY", "hosptype": "H"}' ``` Swap the host for `https://apisprod.nha.gov.in` in production. The rest of the call is the same. ## Sample payloads These samples use an abbreviated field listing with dotted paths rather than literal JSON request bodies. Build your JSON from the field reference underneath, where the nesting is explicit. The `context` block is identical across all six variants. Only `message.intent` changes. ### context ```yaml context: domain: 'nic2004:85112' # Fixed for PM-JAY HEM country: IND city: 'std:011' action: search core_version: 0.7.1 consumer_id: <YOUR_EUA_ID_FROM_NHA_ONBOARDING> consumer_uri: <YOUR_HTTPS_CALLBACK_URL> message_id: dfa04e10-63ec-11ed-9f98-49dd5c7c4d8a # Fresh UUID per call timestamp: '2022-11-14T07:20:54.005277Z' transaction_id: dfa04e10-63ec-11ed-9f98-49dd5c7c4d8a # Links on_search back to this search ``` ### Search by state The base case. Every other variant adds to this one. ```yaml message: intent: fulfillment: type: 'PMJAYHEM' start.time.timestamp: '2022-07-22T13:21:41' end.time.timestamp: '2022-07-22T23:59:59' item.descriptor: code: 'PMJAY' name: 'PMJAY' flag: false location: state.name: 'ANDHRA PRADESH' state.code: '28' ``` ### Search by state and district ```yaml message: intent: fulfillment: type: 'PMJAYHEM' start.time.timestamp: '2022-07-22T13:21:41' end.time.timestamp: '2022-07-22T23:59:59' item.descriptor: code: 'PMJAY' name: 'PMJAY' flag: false location: state.name: 'ANDHRA PRADESH' state.code: '28' district.name: 'ANAKAPALLI' district.code: 744 ``` ### Search by state and speciality Add a `category` block inside `intent`. ```yaml message: intent: fulfillment: type: 'PMJAYHEM' start.time.timestamp: '2022-07-22T13:21:41' end.time.timestamp: '2022-07-22T23:59:59' category: descriptor.name: Cardiology descriptor.code: 100002 item.descriptor: code: 'PMJAY' name: 'PMJAY' flag: false location: state.name: 'ANDHRA PRADESH' state.code: '28' district.name: 'ANAKAPALLI' district.code: 744 ``` ### Search by state and facility name Add a `provider` block inside `intent`. ```yaml message: intent: provider: descriptor.name: General Hospital fulfillment: type: 'PMJAYHEM' start.time.timestamp: '2022-07-22T13:21:41' end.time.timestamp: '2022-07-22T23:59:59' item.descriptor: code: 'PMJAY' name: 'PMJAY' flag: false location: state.name: 'ANDHRA PRADESH' state.code: '28' ``` ### Search by state and pincode `address` sits beside `fulfillment`, not inside `location`. ```yaml message: intent: fulfillment: type: 'PMJAYHEM' start.time.timestamp: '2022-07-22T13:21:41' end.time.timestamp: '2022-07-22T23:59:59' item.descriptor: code: 'PMJAY' name: 'PMJAY' flag: false location: state.name: 'ANDHRA PRADESH' state.code: '28' address: area_code: 523303 ``` ### Search by state and GPS ```yaml message: intent: fulfillment: type: 'PMJAYHEM' start.time.timestamp: '2022-07-22T13:21:41' end.time.timestamp: '2022-07-22T23:59:59' item.descriptor: code: 'PMJAY' name: 'PMJAY' flag: false location: state.name: 'ANDHRA PRADESH' state.code: '28' gps: 17.3787973,78.4368433 radius.type: CONSTANT radius.value: 13.0 radius.unit: km ``` ### on\_search response One `providers[]` entry per empanelled hospital. Note that the establishment date and the empanelment date both arrive as `fulfillments[]` entries, told apart by their `type`. ```yaml context: domain: 'nic2004:85112' action: on_search consumer_id: eua-nha consumer_uri: <YOUR_HTTPS_CALLBACK_URL> provider_id: hspa-nha provider_uri: https://hspasbx.abdm.gov.in/api/v1/hspa transaction_id: dfa04e10-63ec-11ed-9f98-49dd5c7c4d8a # Matches the originating search message_id: <RESPONSE_MESSAGE_ID>message: catalog: descriptor.name: PMJAY HSPA descriptor.short_desc: Pradhan Mantri Jan Arogya Yojana - Hospital Engagement Module providers: - id: 'HOSP27G13867' descriptor.name: General Hospital Wardha descriptor.code: G # G government, P private descriptor.flag: false # NABH accreditation, may be unpopulated categories: - descriptor.name: Cardiology descriptor.code: 100002 - descriptor.name: General Medicine descriptor.code: 100005 fulfillments: - type: 'Establishment Date' start.time.timestamp: '1915' - type: 'Empaneled Date' start.time.timestamp: '2018-09-14 16:03:16.0' location: gps: '15.497097,80.048688' address: '37-1-382-6' city.name: ONGOLE district.name: PRAKASAM district.code: '517' state.name: Andhra Pradesh state.code: 28 country.name: INDIA contact: phone: 9966753790 email: test@gmail.com tags.nodalOfficerNumber: 9966753790 ``` ## Field reference ### search: context All fields are mandatory. | Field | Type | Value | | ---------------- | -------- | ---------------------------------------------------- | | `domain` | string | `nic2004:85112`, fixed | | `country` | string | `IND`, fixed | | `city` | string | STD code, for example `std:011` | | `action` | string | `search`, fixed | | `core_version` | string | `0.7.1` | | `consumer_id` | string | Your registered EUA identifier | | `consumer_uri` | string | Your HTTPS callback URL | | `message_id` | UUID | Fresh per call. Never reuse. | | `transaction_id` | UUID | Fresh per search session. The `on_search` copies it. | | `timestamp` | ISO 8601 | Request time | ### search: message.intent | Field path | Type | Mandatory | Description | | ---------------------------------- | -------- | --------- | ---------------------------------------------------- | | `fulfillment.type` | string | Yes | `PMJAYHEM`, fixed | | `fulfillment.start.time.timestamp` | datetime | Yes | Start of the search window | | `fulfillment.end.time.timestamp` | datetime | Yes | End of the search window | | `item.descriptor.code` | string | Yes | `PMJAY`, fixed | | `item.descriptor.name` | string | Yes | `PMJAY`, fixed | | `item.descriptor.flag` | boolean | Yes | `false`, fixed | | `location.state.name` | string | Yes | State name in capitals, for example `ANDHRA PRADESH` | | `location.state.code` | string | Yes | Numeric state code, for example `28` | | `location.district.name` | string | No | District name in capitals | | `location.district.code` | integer | No | Numeric district code | | `location.gps` | string | No | `lat,long`, for example `17.378,78.436` | | `location.radius.type` | string | No | `CONSTANT`. Required with a GPS search. | | `location.radius.value` | float | No | Radius in km, for example `13.0` | | `location.radius.unit` | string | No | `km` | | `address.area_code` | integer | No | 6 digit pincode | | `category.descriptor.name` | string | No | Speciality name, for example `Cardiology` | | `category.descriptor.code` | integer | No | Speciality code, for example `100002` | | `provider.descriptor.name` | string | No | Hospital or facility name | ### on\_search: provider records | Field path | Type | Description | | -------------------------------------------------------------------- | ------- | -------------------------------------------------- | | `catalog.providers[].id` | string | PM-JAY HEM hospital ID, for example `HOSP27G13867` | | `catalog.providers[].descriptor.name` | string | Hospital name | | `catalog.providers[].descriptor.code` | string | `G` government, `P` private | | `catalog.providers[].descriptor.flag` | boolean | NABH accreditation. May be unpopulated. | | `catalog.providers[].descriptor.short_desc` | string | State level empanelment context | | `catalog.providers[].descriptor.long_desc` | string | Empanelment status description | | `catalog.providers[].categories[].descriptor.name` | string | Speciality name | | `catalog.providers[].categories[].descriptor.code` | integer | Speciality code | | `catalog.providers[].fulfillments[]` with `type: Establishment Date` | string | Year the hospital was established | | `catalog.providers[].fulfillments[]` with `type: Empaneled Date` | string | Date of PM-JAY empanelment | | `catalog.providers[].location.gps` | string | `lat,long` of the hospital | | `catalog.providers[].location.address` | string | Street address | | `catalog.providers[].location.city.name` | string | City name | | `catalog.providers[].location.district.name` | string | District name | | `catalog.providers[].location.district.code` | string | District code | | `catalog.providers[].location.state.name` | string | State name | | `catalog.providers[].location.state.code` | integer | State code | | `catalog.providers[].contact.phone` | string | Hospital phone number | | `catalog.providers[].contact.email` | string | Hospital email | | `catalog.providers[].contact.tags.nodalOfficerNumber` | string | Nodal officer number for PM-JAY questions | ## Known limitations These apply to the current phase. | Limitation | What to do | | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | GPS search can return incomplete results where hospital density is low | Offer district or pincode search as a fallback next to GPS | | `descriptor.flag`, the NABH accreditation flag, is not consistently populated | Do not filter on it. Show it when present, otherwise say nothing. | | `on_search` responses arrive asynchronously with no end of results signal | Set a timeout window. Show results as they arrive. | | No pagination on `on_search` | Handle large payloads without blocking the UI. Paginate on the client for display. | | No booking or referral | Scope your UI to discovery | | The covered procedure list can lag real package changes | Show a disclaimer and link to pmjay.gov.in for the authoritative package list | ## Testing before go-live There are 29 test cases across five categories, to be run against the UHI sandbox before you request production sign off. | Category | What it checks | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A, context validation | All mandatory `context` fields present. `transaction_id` in `on_search` matches the originating `search`. `domain` mirrors correctly. | | B, search filters | One test per supported filter variant, checking that results honour the filter. | | C, on\_search response | Provider ID present and non null. Core fields present. Empanelment and establishment dates present. GPS parseable. Nodal officer number present. Specialities returned. | | D, user experience | The feature is reachable in three taps or fewer. UHI, PM-JAY and ABDM branding on the search screen. A fallback message when there are no results. A disclaimer on the results screen asking the user to call ahead. | | E, edge cases | A large result set from a high density state renders. An empty `providers[]` array shows a fallback and does not crash. A missing `on_search` times out and offers a retry rather than spinning forever. | Ask for the full test case sheet and the UHI Postman collection when you onboard. ## Phase scope The plan has three phases, and only the first, discovery, is open for onboarding. Booking and referral workflows, provider dashboards and CSC kiosk search are named as the second phase. [ABHA](/docs/uhi/v1/getting-started/glossary#abha) linked discharge summaries and multilingual voice are named as the third. Dates for either are not yet published. ## Next - Shared UHI protocol, signing and onboarding: [UHI services](/docs/uhi/v1) - The M2 prerequisite: [HIE-CM M2](/docs/hiecm/v3/api/m2) --- # Glossary Every term the UHI documentation links to. Each row keeps its own anchor, so a link like `#eua` lands on the right row. HIE-CM's own vocabulary, the roles and the consent objects, is in the [HIE-CM glossary](/docs/hiecm/v3/getting-started/glossary). ## Across ABDM These terms mean the same thing on every ABDM gateway. ### ABDM Ayushman Bharat Digital Mission, India's national programme for digital health, run by the [NHA](#nha). ABDM sets the identifiers, the registries and the exchange rules that let a health record move from the system that created it to the person it belongs to. ### ABHA Ayushman Bharat Health Account. It comes in two forms people confuse: the 14 digit [ABHA number](#abha-number) and the readable [ABHA address](#abha-address). When a document says "the patient's ABHA", work out which of the two it means before you write code against it. ### ABHA address A readable name on the [HIE-CM](#hie-cm), such as `name@abdm`, used to reach health records and share them with a provider. Every ABHA number is issued a default address made from the number itself: `14digit@sbx` in [sandbox](#sandbox), `14digit@abdm` in production. A person can also create an ABHA address without holding an ABHA number, using mobile number, name, age and gender. ### ABHA number A 14 digit identifier issued to a person only after a [KYC](#kyc) check passes, and the identity anchor of ABDM: one person, one number. An ABHA number carries a check digit and validates under the Luhn algorithm. See [M1](/docs/hiecm/v3/getting-started/glossary#m1) for how one is created. ### FHIR Fast Healthcare Interoperability Resources, the HL7 standard ABDM uses to carry health records. ABDM uses FHIR R4 with the profiles published by NRCES at [nrces.in/ndhm/fhir/r4](https://nrces.in/ndhm/fhir/r4/index.html). Every record you share travels as a FHIR bundle of type `document` whose first entry is a Composition. ### Gateway The routing layer for ABDM: you do not call another participant directly, you call the gateway, it forwards your request, and the reply arrives at your [bridge](/docs/hiecm/v3/getting-started/glossary#bridge) as a separate inbound call. You get a session token first, by posting your client id and client secret to `/api/hiecm/gateway/v3/sessions`. Two sandbox hosts serve that path, `https://apissbx.abdm.gov.in` and `https://dev.abdm.gov.in`. Take the host from your onboarding documentation and keep it in configuration; see [Choose your gateway](/docs/hiecm/v3). ### Health Tech Committee The committee that reviews your integration at the end of the sandbox exit process, referred to as the HTC. Once your functional testing, security audit and exit form are complete, it is scheduled its own demonstration, separate from the one you give the integration team earlier. Its decision is recorded in four review stages, each carrying its own reviewer, comment and date. See [Go live](/docs/hiecm/v3/getting-started/going-live). ### HFR Health Facility Registry, the national directory of health facilities across modern and traditional systems of medicine, public and private, including hospitals, clinics, diagnostic laboratories, imaging centres and pharmacies. A facility enrols once and receives a facility ID that identifies it everywhere in ABDM. See [registries](/docs/hiecm/v3/registries). ### HIE-CM Health Information Exchange and Consent Manager, the component that routes exchange requests and manages patient consent. It is data blind: it holds identifiers and metadata about [care contexts](/docs/hiecm/v3/getting-started/glossary#care-context), never the content of a record. See [The ABDM gateway](/docs/hiecm/v3/concepts/gateway). ### HPID Healthcare Professional ID: a 14 digit number issued to a healthcare professional or a facility manager after Aadhaar authentication. It is the professional's digital identity across ABDM, and it is created on the [HPR](#hpr). See [M4](/docs/hiecm/v3/getting-started/glossary#m4). ### HPR Healthcare Professionals Registry, the national registry of doctors, nurses, pharmacists and other healthcare professionals. Registering a professional there issues an [HPID](#hpid). The HPR token is also used when onboarding a facility to the [HFR](#hfr). ### KYC Know Your Customer: the identity check that must pass before an [ABHA number](#abha-number) is issued. In ABDM the check runs against Aadhaar, by one of four methods: an [OTP](#otp) to the Aadhaar linked mobile number, face authentication, fingerprint or IRIS capture on a registered device, or a demographic match. Re-KYC repeats the check on an ABHA number that already exists. ### NHA National Health Authority, the government body that runs ABDM, publishes its specifications, and operates both the [sandbox](#sandbox) and the production gateways. ### NHCX National Health Claims Exchange, ABDM's network for insurance claims between providers and payers, with its own sandbox and its own document set at [hcxsbx.abdm.gov.in](https://hcxsbx.abdm.gov.in). See [NHCX](/docs/nhcx/v1). ### OTP One Time Password: a short code sent to a mobile number or an email address to prove the person holds it. ABDM uses OTPs at many points: Aadhaar [KYC](#kyc), mobile number verification during ABHA creation, and login. An OTP is always paired with a transaction id from the call that requested it. ### PHR Personal Health Record, a patient facing application: the person logs in with their [ABHA address](#abha-address), discovers records held by facilities they visited, links them, and reads them. PHR apps subscribe to a patient's ABHA address and are notified when a new [care context](/docs/hiecm/v3/getting-started/glossary#care-context) is linked. See [PHR applications](/docs/hiecm/v3/concepts/phr). ### Safe to Host certificate The certificate a [WASA](#wasa) produces, issued by a CERT-In empanelled auditor, and required before you receive production credentials. It names the application it covers and carries an issue date and an expiry date. A certificate that is in date covers a new module without a fresh audit of the parts already certified. See [Security audit](/docs/hiecm/v3/getting-started/security-audit). ### Sandbox The ABDM test environment, and where every integration starts: you register on the sandbox portal, declare your role and the milestones you plan to complete, and receive a client id and client secret. Sandbox hosts differ from production, so ABHA calls go to `abhasbx.abdm.gov.in` in sandbox and `abha.abdm.gov.in` in production. Everything in sandbox is test data; see [Get started](/docs/hiecm/v3/getting-started/sandbox). ### txnId Transaction id. Most flows take two or three calls, and the first one returns a `txnId` that the calls after it send back, so ABDM knows which attempt they belong to. It is short lived and single purpose. It is not a session and it is not a token: holding a `txnId` does not authenticate you, and it stops working once the flow it belongs to finishes or expires. ### UHI Unified Health Interface, an open protocol network for health services that are not record exchange: physical consultation booking, ambulance booking, blood bank discovery, Jan Aushadhi and pharmacy search. It has two roles, [EUA](/docs/uhi/v1/getting-started/glossary#eua) on the consumer side and [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) on the provider side, and every call is signed with Ed25519. See [UHI](/docs/uhi/v1). ### WASA The security audit of your application, conducted on your staging URL by an auditor from the CERT-In empanelled list. It produces the [Safe to Host certificate](#safe-to-host-certificate), and it is separate from functional testing: passing every milestone still leaves this to do. Each platform you ship is audited on its own. See [Security audit](/docs/hiecm/v3/getting-started/security-audit). ## On UHI These terms belong to UHI: the two applications on either side of a booking. ### EUA End User Application: in [UHI](#uhi), the consumer facing side, the app a patient or a caregiver uses to search for a service and book it. It sends a signed request to the UHI gateway and receives responses at its own callback URL. See [UHI](/docs/uhi/v1). ### HSPA Health Service Provider Application: in [UHI](#uhi), the provider side system that receives requests and responds to them, such as an ambulance operator's dispatch platform, a blood bank management system or a pharmacy's stock system. It is the counterpart of the [EUA](#eua). --- # Onboarding to UHI Every [UHI](/docs/uhi/v1/getting-started/glossary#uhi) service document repeats the same joining route. After this page you will know the seven steps from the [M2](/docs/hiecm/v3/getting-started/glossary#m2) gate to production go-live, and where one service differs from the rest. Read [Introduction](/docs/uhi/v1) and [UHI gateway](/docs/uhi/v1/concepts/network-and-protocol) first, for the network, the two roles and the message pattern. ## Pick your role first | Role | Full name | What you build | | -------------------------------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | [EUA](/docs/uhi/v1/getting-started/glossary#eua) | End User Application | The citizen facing app. Sends the search, receives results at your callback URL, drives booking where the service supports it. | | [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) | Health Service Provider Application | The provider platform. Answers searches from its own catalogue and, where the service supports it, runs the booking lifecycle. | The HSP is the hospital, clinic, doctor, ambulance operator or blood bank, and the HSPA is its digital interface. The [gateway](/docs/uhi/v1/getting-started/glossary#gateway) is the network's routing layer. ## Which role each service accepts Four of the seven have a single HSPA that someone else already operates, so your work is the EUA side. | Service | EUA | HSPA | Who runs the HSPA | | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | --- | ----- | ----------------------------------------------------------- | | [Physical consultation](/docs/uhi/v1/concepts/services/physical-consultation) | Yes | Yes | Any onboarded provider platform | | [Ambulance booking](/docs/uhi/v1/concepts/services/ambulance-booking) | Yes | Yes | Any onboarded ambulance operator platform | | [Blood bank](/docs/uhi/v1/concepts/services/blood-bank) | Yes | Yes | Open to both roles. e-RaktKosh is the registered HSPA today | | [PM-JAY HEM](/docs/uhi/v1/concepts/services/pmjay-hem) | Yes | No | NHA. There are no third party HSPA integrations | | [Jan Aushadhi Kendra](/docs/uhi/v1/concepts/services/jan-aushadhi-kendra) and [medicine search](/docs/uhi/v1/concepts/services/jan-aushadhi-medicine-search) | Yes | Named | PMBI | | [AMRIT pharmacy](/docs/uhi/v1/concepts/services/amrit-pharmacy) | Yes | Named | HLL Lifecare Limited | Two bars on the HSPA role. For blood bank, your inventory data has to be maintained independently at a standard comparable to e-RaktKosh. For ambulance, availability has to be real time or near real time, and an integration built on manually maintained records will not be approved for production. ## The gate before any of this Your application must have completed ABDM M2 with [HIE-CM](/docs/uhi/v1/getting-started/glossary#hie-cm). An application that has not completed M2 cannot be onboarded onto UHI services. The gate applies to every service on the network. If M2 is not done, start at [M2 linking and sharing](/docs/hiecm/v3/api/m2). ## The steps Steps 1 to 5 are sandbox. Steps 6 and 7 are production. 1. **Express intent.** Reply to NHA's onboarding communication, or contact your NHA point of contact, and name the service you want to integrate. 2. **Generate your key pair.** Clone [github.com/NHA-ABDM/UHI](https://github.com/NHA-ABDM/UHI/tree/main/header_generator_utility) and run `Generator.java` with option 1. Send NHA the public key only. 3. **Fill the onboarding form.** [sandbox.abdm.gov.in](https://sandbox.abdm.gov.in/sandbox/v3/sandbox-registration) asks for your organisation details, your role, your HTTPS sandbox callback URL and your public key. 4. **Get sandbox access.** NHA emails sandbox credentials. Review the Swagger specification, and ask NHA for the UHI Postman collection for your service. 5. **Build and test.** Implement the stages your service covers, then run the test cases for your role. 6. **Get sign-off.** NHA reviews your test evidence and confirms in writing. Physical consultation also asks for a demo video. 7. **Go to production.** NHA promotes your integration. Update `consumer_id`, `consumer_uri`, `provider_id` and `provider_uri` to production values. Two documents order steps 2 and 3 the other way round. The form asks for your public key, so generate the key pair first whichever order your document lists. ## The signing keys Every UHI call is signed with an Ed25519 signature over a BLAKE-512 hash of the request body. The header format is on [UHI gateway](/docs/uhi/v1/concepts/network-and-protocol#signing). Onboarding needs the key pair. | Item | What the documents say | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | How you generate it | NHA's header generator utility, `Generator.java` option 1. It also produces signed headers: feed it your subscriber ID, your public key ID and the exact request payload as a string. | | What you send NHA | The public key only, registered against your subscriber ID during onboarding. | | What you keep | The private key. Keep it out of your repository and out of your client applications. | | Your key ID | Appears inside the `Authorization` header as `<SUBSCRIBER_ID_FROM_NHA_ONBOARDING>\|<YOUR_PUBLIC_KEY_ID>\|ed25519`. | | The gateway's key | Gateway calls to you carry `X-Gateway-Authorization`, key ID prefixed `gateway-nha`. Verify it rather than trusting the source address. | | Finding another party's key | `POST /api/v1/networkregistry/lookup` on the gateway returns a subscriber's registered public key. Both sides use it before a signed point to point call. | ## The callback URL you register It is your `consumer_uri` if you are an EUA, and your `provider_uri` if you are an HSPA. Four rules come out of the documents. - Publicly accessible over HTTPS. The gateway and the other party call it from outside your network. - For an EUA, it must share a domain with your `consumer_id`. - It is where the real answer arrives. The synchronous reply to any UHI call is an ACK receipt, not the business response. Do not block your request thread. - You match the answer to your request on `transaction_id`. Several HSPAs can answer one search, and that field is the only thing tying their calls back to yours. What sits behind that URL depends on your role and how far your service goes. | Service and role | Endpoints you expose | | ------------------------------------- | ------------------------------------------------------------------------------------------------ | | EUA, discovery only services | `/on_search` | | EUA, ambulance booking (first phase) | `/on_search`, `/on_init` | | EUA, physical consultation | `/on_search`, `/on_init`, `/on_confirm`, `/on_status`, `/on_update`, `/on_cancel`, `/on_message` | | HSPA, ambulance booking (first phase) | `/search`, `/init` | | HSPA, physical consultation | `/search`, `/init`, `/confirm`, `/status`, `/cancel`, `/on_update`, `/on_message` | The discovery only services are blood bank, PM-JAY HEM, Jan Aushadhi Kendra, Jan Aushadhi medicine search and AMRIT pharmacy. On physical consultation, `/on_message` is mandatory for an EUA and optional for an HSPA. `/on_update` is consumed by both sides. ## The sandbox path ```text Gateway base URI https://uhigatewaysandbox.abdm.gov.inReference EUA http://uhieuasandbox.abdm.gov.in/api/v1/euaServiceReference HSPA https://hspasbx.abdm.gov.in/api/v1/hspaProduction gateway https://uhigateway.abdm.gov.in ``` Those are NHA's own sandbox applications. If you are building an EUA, the reference HSPA answers your searches until a real one is registered against your test. The Swagger specification sits at [uhigatewaysandbox.abdm.gov.in/swagger-ui](https://uhigatewaysandbox.abdm.gov.in/swagger-ui/index.html?urls.primaryName=v2.0.2#/). The documents do not agree on a version: physical consultation points at `v2.0.2`, PM-JAY HEM at `v2.0.1`. Check which one your onboarding contact expects. The reference EUA and HSPA are also published as APKs, with recordings of the integration support calls. ## Before you ask for sign-off A twenty row readiness checklist applies, whatever your service. - ABDM M2 with HIE-CM is complete. - Your Ed25519 key pair is generated and the public key is submitted. - The onboarding form is submitted and sandbox access is configured. - Your HTTPS callback URL is live and reachable from outside your network. - Request signing is implemented, and you verify inbound signatures. - Every endpoint your role and service requires is exposed and tested. - Discovery is tested across each filter your service supports. - Asynchronous handling is tested, including an empty result set and a response that never arrives. - The test cases for your role pass, and you have the evidence to show. Services that go beyond discovery add their own items. Physical consultation asks for the booking flow, the PIN, status transitions, terms display and a caching policy with a ceiling of 48 hours. ## Where to ask There are two support levels. L1 covers technical integration: API errors, signing problems, sandbox access and endpoint configuration. L2 covers the onboarding form, milestone verification and compliance. The named contacts are in the onboarding communication NHA sends you. Use that rather than a name copied from a document that may have moved on. For anything about these pages rather than about UHI itself, see [support](/docs/support). ## Next - [UHI gateway](/docs/uhi/v1/concepts/network-and-protocol), for the message pattern, the context block and signing - [Introduction](/docs/uhi/v1), for the two roles and how far each service goes - [Physical consultation](/docs/uhi/v1/concepts/services/physical-consultation), the service with the full booking lifecycle - [M2 linking and sharing](/docs/hiecm/v3/api/m2), the prerequisite --- # Introduction The Ayushman Bharat Digital Mission ([ABDM](/docs/uhi/v1/getting-started/glossary#abdm)) is India's national health data network, run by the National Health Authority ([NHA](/docs/uhi/v1/getting-started/glossary#nha)). It is three gateways, not one, and this section documents the second of them. [UHI](/docs/uhi/v1/getting-started/glossary#uhi) is the Unified Health Interface, [ABDM](/docs/uhi/v1/getting-started/glossary#abdm)'s open network for finding and booking a health service. After this page you will know which role to build, how far each service goes, and where the protocol is written down. [HIE-CM](/docs/uhi/v1/getting-started/glossary#hie-cm) moves records that already exist. UHI finds a doctor, an ambulance or a unit of blood before any record exists. ## The gate before anything else Your application must have completed ABDM [M2](/docs/hiecm/v3/api/m2) with HIE-CM before it can be onboarded to any UHI service. This applies to every service on the network. UHI sits on top of HIE-CM, it is not an alternative to it. ## Two roles | Role | Full name | What it does | | -------------------------------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------ | | [EUA](/docs/uhi/v1/getting-started/glossary#eua) | End User Application | The patient facing app. Searches, shows results, books, displays status. | | [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) | Health Service Provider Application | The provider platform. Holds availability, answers searches, drives the booking lifecycle. | The HSP is the hospital, clinic, doctor, ambulance operator or blood bank, and the HSPA is its digital interface. The [gateway](/docs/uhi/v1/getting-started/glossary#gateway) is the network's routing layer. Each service page says which roles it accepts. ## Services A service is identified by fixed values inside the call, not by a different endpoint. All three documents behind this page use `core_version` `0.7.1`. | Service | Domain code | Discovery | Order and quote | Booking and lifecycle | | ----------------------------------------------------------------------------- | --------------- | --------------------- | ------------------- | ------------------------------------------------------------------------------------------------ | | [Physical consultation](/docs/uhi/v1/concepts/services/physical-consultation) | `nic2004:85111` | `search`, `on_search` | `init`, `on_init` | `confirm`, `on_confirm`, `status`, `on_status`, `on_update`, `cancel`, `on_cancel`, `on_message` | | [Ambulance booking](/docs/uhi/v1/concepts/services/ambulance-booking) | `nic2008:86909` | `search`, `on_search` | `init`, `on_init` | Not open for onboarding yet | | [Blood bank](/docs/uhi/v1/concepts/services/blood-bank) | `nic2008:86906` | `search`, `on_search` | Not in this service | Not in this service | Four more services have their own onboarding documents and their own pages: [Jan Aushadhi Kendra](/docs/uhi/v1/concepts/services/jan-aushadhi-kendra), [Jan Aushadhi medicine search](/docs/uhi/v1/concepts/services/jan-aushadhi-medicine-search), [AMRIT pharmacy](/docs/uhi/v1/concepts/services/amrit-pharmacy) and [PMJAY HEM](/docs/uhi/v1/concepts/services/pmjay-hem). ## Two transports in one flow Discovery goes through the gateway, which broadcasts your one `search` to every registered HSPA in that domain, so several `on_search` calls come back. Everything after discovery is point to point between your EUA and the HSPA the patient chose. There is no central UHI API for those stages. Every call is asynchronous and signed. ## Next - [Network and protocol](/docs/uhi/v1/concepts/network-and-protocol), for the message pairs, the `context` block, Ed25519 signing and the network registry lookup - [Onboarding](/docs/uhi/v1/getting-started/onboarding), for the route from M2 to sandbox credentials to production - [Physical consultation](/docs/uhi/v1/concepts/services/physical-consultation), the service with the full booking lifecycle - [Support](/docs/support) --- # ABHA on UHI [ABHA](/docs/uhi/v1/getting-started/glossary#abha) is the patient's account: a 14 digit number and a readable address such as `name@abdm`. UHI uses the address, never the number, and only as a name for the person the booking is for. ## Where it appears | Field | Service | Required | Example | | ------------------------- | ----------------------------------------------------------------------------- | --------- | ----------------------------------------------------------------------------------------------------------- | | `order.customer.id` | [Physical consultation](/docs/uhi/v1/concepts/services/physical-consultation) | Yes | `rahul.k001@sbx` | | `order.customer.id` | [Ambulance booking](/docs/uhi/v1/concepts/services/ambulance-booking) | Mandatory | `91XXXXXXXXXX@sbx` | | `chat.sender.person.id` | Physical consultation | Yes | The ABHA address of the sender, or the doctor's [HPR](/docs/uhi/v1/registries/hpr) ID when the doctor sends | | `chat.receiver.person.id` | Physical consultation | Yes | The other side of the same pair | The `@sbx` suffix in both examples is the sandbox one. Production addresses end `@abdm`, so an address hardcoded from a sandbox test will fail once you are promoted. ## What UHI does not do with it Nothing is verified here. UHI carries the address through the booking; it does not check that it exists, does not authenticate the person behind it, and creates no ABHA of its own. A patient who has no ABHA gets one through [M1](/docs/hiecm/v3/api/m1) on HIE-CM, which is where creation, login and [KYC](/docs/uhi/v1/getting-started/glossary#kyc) live. Nor does an ABHA address in a UHI message give anyone a right to the patient's records. Records move on HIE-CM, under a consent artefact, and never as part of a booking. See [Consent on HIE-CM](/docs/hiecm/v3/concepts/consent) if that is what you are building. ## Next - [HPR on UHI](/docs/uhi/v1/registries/hpr), the practitioner side of the same booking - [Physical consultation](/docs/uhi/v1/concepts/services/physical-consultation), where both appear in full --- # HFR on UHI The [HFR](/docs/uhi/v1/getting-started/glossary#hfr) is the national register of health facilities: hospitals, clinics, labs, imaging centres and pharmacies. On UHI it names the place behind a listing. ## Where it appears | Field | Service | Required | | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ----------------------------- | | `catalog.providers[].fulfillments[].tags["@abdm/gov.in/hfr_id"]` | [AMRIT pharmacy](/docs/uhi/v1/concepts/services/amrit-pharmacy), one tag per store | Listed in the field reference | | `catalog.providers[].fulfillments[].agent.tags` | [Physical consultation](/docs/uhi/v1/concepts/services/physical-consultation), as `/hfr_id` beside the practitioner tags | No | AMRIT pharmacy is the only UHI service in this portal whose catalogue carries the facility identifier as a field of its own. It is one of three things that service adds over the others. ## What the document does not fill in The value appears as the placeholder `<HFR_ID>`, with no filled example published. The AMRIT page records the same gap for the store hours and the contact block. Treat the field's format as whatever the HFR itself issues, and confirm it against a real store entry before you rely on it. ## Where the ID comes from Not from UHI. A facility is enrolled in the HFR through [M4](/docs/hiecm/v3/api/m4) on HIE-CM, and the create call there needs a professional token from an [HPR](/docs/uhi/v1/registries/hpr) ID with facility manager rights. UHI quotes the result. ## Next - [Registries](/docs/uhi/v1/registries), for the four UHI touches and the one it owns - [AMRIT pharmacy](/docs/uhi/v1/concepts/services/amrit-pharmacy), the catalogue this tag sits in --- # HPR on UHI The [HPR](/docs/uhi/v1/getting-started/glossary#hpr) is the national register of health professionals. On UHI it names the person a patient is booking: the doctor in a consultation. ## Where it appears | Field | Stage | Required | | ----------------------------------------------------- | ------------------------------------------------------------------------------------- | -------- | | `catalog.providers[].fulfillments[].agent.id` | The catalogue an [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) returns on search | Yes | | `catalog.providers[].fulfillments[].agent.tags` | The same catalogue entry | No | | `order.fulfillment.agent.id` | The order, from select onward | Yes | | `chat.sender.person.id` and `chat.receiver.person.id` | Chat, when the doctor is one end of it | Yes | ## Two forms of the same identifier The practitioner appears two ways in the same sample. `agent.id` carries the readable address, `priyamehra@hpr.ndhm`. The tag block beside it carries the numeric ID, `@abdm/gov.in/hpr_id`, as `73-5232-1888-8686`. Send the address in `agent.id`. The tag is optional, and it sits with the other practitioner tags The same block also carries: `@abdm/gov.in/experience`, `/languages`, `/education`, `/hpr_id`, `/hfr_id` and `/hip_id`. ## Where the ID comes from Not from UHI. A professional is registered in the HPR through [M4](/docs/hiecm/v3/api/m4) on HIE-CM, and UHI quotes what M4 wrote. If your HSPA lists a doctor who has no HPR ID, the catalogue entry has no valid `agent.id` to carry, and there is no UHI call that will mint one. ## Next - [HFR on UHI](/docs/uhi/v1/registries/hfr), the facility the practitioner works in - [M4 HPR and HFR](/docs/hiecm/v3/api/m4), where both are written --- # Registries UHI touches four registries, and only one of them belongs to UHI. After this page you will know which identifier goes in which field, and which ones onboarding asks you for. | Registry | Identifies | Where it appears in UHI | | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | Network registry | A subscriber on the UHI network: an [EUA](/docs/uhi/v1/getting-started/glossary#eua), an [HSPA](/docs/uhi/v1/getting-started/glossary#hspa) or the gateway | `POST /api/v1/networkregistry/lookup`, to fetch a counterparty's public key before a signed point to point call | | [ABHA](/docs/uhi/v1/registries/abha) | The patient | `order.customer.id`, and the person ids in chat | | [HPR](/docs/uhi/v1/registries/hpr) | The practitioner | `fulfillment.agent.id`, and an `hpr_id` tag | | [HFR](/docs/uhi/v1/registries/hfr) | The facility or store | An `hfr_id` tag on a fulfillment | ## The network registry is UHI's own The other three are ABDM registries that UHI quotes. The network registry is UHI's, and it holds something the others do not: the public key each subscriber registered at onboarding. Both sides of a signed call look the counterparty up in it. [UHI gateway](/docs/uhi/v1/concepts/network-and-protocol) has the lookup and the signing. ## Onboarding does not ask for the other three The onboarding form asks for your organisation details, your role, your callback URL and your public key. It does not ask for an [HPR](/docs/uhi/v1/getting-started/glossary#hpr) ID or an [HFR](/docs/uhi/v1/getting-started/glossary#hfr) entry, and no UHI document in this portal makes either a condition of joining the network. They arrive by the back door instead. Your application must have completed [M2](/docs/hiecm/v3/api/m2) with [HIE-CM](/docs/uhi/v1/getting-started/glossary#hie-cm) before it can be onboarded to any UHI service, and that route does require a facility in the HFR and a professional in the HPR. See [Onboarding](/docs/uhi/v1/getting-started/onboarding) for the gate, and [HIE-CM's registries](/docs/hiecm/v3/registries) for what M4 writes into them. ## What UHI never does UHI creates no registry entry. It issues no ABHA number, registers no professional and enrols no facility. Every identifier in a UHI message was written by a milestone on HIE-CM and is being quoted here, which is why a wrong one fails at the far end rather than at the gateway. --- # 24 August 2026 4 changes ### Read the HIE-CM modules Three modules on the [HIE-CM](/docs/hiecm/v3/getting-started/glossary#hie-cm) gateway: - [M1](/docs/hiecm/v3/api/m1), [ABHA](/docs/hiecm/v3/getting-started/glossary#abha) identity - [M2](/docs/hiecm/v3/api/m2), care context linking and [HIP](/docs/hiecm/v3/getting-started/glossary#hip) data sharing - [M3](/docs/hiecm/v3/api/m3), consent and [HIU](/docs/hiecm/v3/getting-started/glossary#hiu) data fetch Start at [Overview](/docs/hiecm/v3). These pages follow the sandbox document pack. Nothing in them has been run against the ABDM sandbox, so every page carries `verification: unverified`. Where a request or response shape is not yet published, the page says so instead of guessing at a payload. ### Try the session token call The session token call is the first call every module needs, and the one operation with a working interactive reference. Send a request from [/reference/hiecm-gateway](/reference/hiecm-gateway). The four module references exist but carry no operations yet. A callback appears on the module that owns it, as an OpenAPI 3.1 `webhook`, because an [ABDM](/docs/hiecm/v3/getting-started/glossary#abdm) callback is an HTTPS POST to a URL you registered. | Interactive reference | Scope | | ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | [/reference/hiecm-gateway](/reference/hiecm-gateway) | Session token, used by all modules | | [/reference/hiecm-m1](/reference/hiecm-m1) | M1, ABHA identity | | [/reference/hiecm-m2](/reference/hiecm-m2) | M2, care context linking and HIP data sharing | | [/reference/hiecm-m3](/reference/hiecm-m3) | M3, consent and HIU data fetch | | [/reference/hiecm-m4](/reference/hiecm-m4) | M4, [HPR](/docs/hiecm/v3/getting-started/glossary#hpr) and [HFR](/docs/hiecm/v3/getting-started/glossary#hfr) registration | ### Find your way around M4, UHI and NHCX No endpoint is documented yet for [M4](/docs/hiecm/v3/api/m4), for the [UHI](/docs/hiecm/v3/getting-started/glossary#uhi) gateway at [/docs/uhi/v1](/docs/uhi/v1), or for [NHCX](/docs/nhcx/v1). Those pages tell you what is published and where to read it. ### The M1 agent skill The M1 documentation is now published as an agent skill: one file carrying every endpoint, the required headers, the two token rule and the encryption rule. Download it, or install it with one command, from [M1 APIs](/docs/hiecm/v3/api/m1/apis). It is generated from these pages on every build, so a page that changes changes the skill. --- # 25 August 2026 4 changes ### The PHR role has API references Aarogya Setu is the reference PHR, and it is now ingested and split the way the provider milestones are, rather than landing as one file of 208 operations. - [P1](/reference/hiecm-p1), identity and profile, 63 operations - [P2](/reference/hiecm-p2), linking and records, 49 operations - [P3](/reference/hiecm-p3), consent and notifications, 35 operations - [PHR application services](/reference/hiecm-phr-services), 61 operations, which is **not** a certification milestone The same calls and the same 422 PHR error codes apply to any PHR, not only to Aarogya Setu. No OpenAPI file is published for this role yet, so these are derived from the collection rather than from a specification, and every operation says so. ### M2 and M3 have real API references An OpenAPI file now exists for each of M1, M2 and M3, plus Postman collections for all three. They are ingested, and the reference pages are built from them rather than from prose. The catalogue went from 35 documented operations to 69, and from 10 declared callbacks to 12, five of which now carry a real payload. - [M1 API reference](/reference/hiecm-m1), 44 operations, up from 32 - [M2 API reference](/reference/hiecm-m2), 10 operations, up from none - [M3 API reference](/reference/hiecm-m3), 6 operations and 6 callbacks, up from none - [Gateway reference](/reference/hiecm-gateway), 7 operations. The gateway group repeats this group in all three files, so it is described once ### What the new sources do not give you The three specifications describe **no callbacks at all**. What they model as paths is the outbound half, the calls you make, including the `on-init` and `on-notify` responses you send. What the gateway posts to your registered URL is absent from every one of them. For M3 that gap is now filled: the callbacks carry the payloads. For M2 only the data notification is available, so the remaining M2 callbacks name a path and stop. ### Corrections applied to the published files Five, all recorded in `catalogue/openapi/corrections/` rather than applied silently: 52 em dashes rewritten, 8 references to components that were never defined, 26 UUID format assertions the examples contradict, 2 `hiType` examples that disagreed with the schema, and 1 example dropped for violating the schema it illustrates. Nothing in this release has been run against the ABDM sandbox. Every page and every atom says `unverified`. --- # 1 September 2026 5 changes ### Troubleshooting organised by what you see, not by error code A new [Troubleshooting](/docs/hiecm/v3/troubleshooting/) section starts from the symptom in front of you: the callback never arrives, everything returns 401, the OTP never arrives, a call is accepted then nothing happens, a consent stays stuck in `Requested`. Each page works through the checks in order and names what counts as proof the fix worked. The [Error codes](/docs/hiecm/v3/reference/error-codes) reference now points here first for anyone who has a symptom rather than a code. ### A first fifteen minutes that needs nothing but a browser [Your first fifteen minutes](/docs/hiecm/v3/getting-started/first-fifteen-minutes) gives you something to do while your sandbox registration is reviewed: one gateway session call transcribed from this repository's specification, and your own first call assembled with the credential placeholders named for where they come from. The transcribed request is read from the OpenAPI spec in this repository, not invented. The spec carries no captured response body, only the field list, and the page says plainly which parts are observed and which are not yet. ### Going live, in order [Going live](/docs/hiecm/v3/getting-started/going-live) states the sandbox exit process in the order it runs: the demonstration, functional testing and the security audit, the exit form, and the second demonstration to the Health Tech Committee. It names what is not yet published rather than guessing it in. ### Every doc page serves itself as markdown, for agents and people alike Every documentation route now has a "Copy page as Markdown" and "View as Markdown" button, and serves its own `index.md` alongside the rendered page. A repository-wide `llms.txt` and `llms-full.txt`, plus one `llms.txt` per module, are built on every release so an agent can retrieve exactly the page it needs without scraping HTML. See [Build with AI](/docs/hiecm/v3/getting-started/build-with-ai) for the skills and the [Docs MCP server](/docs/hiecm/v3/getting-started/build-with-ai#connect-the-docs-mcp-server) built on the same content. ### Seven PHR operations renamed Seven operations in the P1 through P3 and PHR application services references carried a stray " Copy" suffix. Each was checked against the operation its name implied it duplicated. None turned out to be a true duplicate: five have no other operation to duplicate, and the other two point at a different host or a different API entirely. Every one has been given a name that says what it does instead. The corrections log records the comparison. --- # 2 September 2026 1 change ### Every page can be handed to an agent Each documentation page now offers Copy page, Open in ChatGPT, Open in Claude and Ask AI. Copy page returns the page as Markdown, and the two Open actions hand that Markdown to an assistant with the page as context. This is the same content the [Markdown routes and `llms.txt`](/docs/whats-new/2026-09-01#every-doc-page-serves-itself-as-markdown-for-agents-and-people-alike) serve, reachable from the page you are reading. --- # 3 September 2026 3 changes ### The security audit has a page [Security audit](/docs/hiecm/v3/getting-started/security-audit) covers the WASA and the Safe to Host certificate you need before production: who may audit you, that the audit runs on your staging URL, that each platform you ship is audited separately, and when a code change requires a fresh audit. ### The milestone pages no longer promise a certification step that does not exist M1 to M4 each said to submit functional test cases in the sandbox for review, with a button to a screen that was never there. There is no per milestone submission. One exit process covers the whole integration, and all four pages now point at [Going live](/docs/hiecm/v3/getting-started/going-live) for it. ### The Health Tech Committee review runs in four stages [Going live](/docs/hiecm/v3/getting-started/going-live) records that the committee's decision arrives as four review stages, each with its own reviewer and date, rather than as a single answer after the second demonstration. --- # 10 September 2026 1 change ### A care context is linked when the callback says so, not when the call returns The M2 linking journey showed the link confirmed on the linking call itself. The call returns 202 and decides nothing. The outcome arrives later as a POST to `/v3/link/on_carecontext` on your bridge, carrying `status` and the `REQUEST-ID` you sent. If you marked records as linked on the 202, go back and key that on the callback instead. [M2 Attach, journey 1](/docs/hiecm/v3/milestones/m2#journey-1-hip-initiated-linking). --- # What's new Changes that affect what you can build against, newest first. Each entry links to what you can now read, run or consume. ## 10 September 2026 1 change - [A care context is linked when the callback says so, not when the call returns](/docs/whats-new/2026-09-10#a-care-context-is-linked-when-the-callback-says-so-not-when-the-call-returns) ## 3 September 2026 3 changes - [The security audit has a page](/docs/whats-new/2026-09-03#the-security-audit-has-a-page) - [The milestone pages no longer promise a certification step that does not exist](/docs/whats-new/2026-09-03#the-milestone-pages-no-longer-promise-a-certification-step-that-does-not-exist) - [The Health Tech Committee review runs in four stages](/docs/whats-new/2026-09-03#the-health-tech-committee-review-runs-in-four-stages) ## 2 September 2026 1 change - [Every page can be handed to an agent](/docs/whats-new/2026-09-02#every-page-can-be-handed-to-an-agent) ## 1 September 2026 5 changes - [Troubleshooting organised by what you see, not by error code](/docs/whats-new/2026-09-01#troubleshooting-organised-by-what-you-see-not-by-error-code) - [A first fifteen minutes that needs nothing but a browser](/docs/whats-new/2026-09-01#a-first-fifteen-minutes-that-needs-nothing-but-a-browser) - [Going live, in order](/docs/whats-new/2026-09-01#going-live-in-order) - [Every doc page serves itself as markdown, for agents and people alike](/docs/whats-new/2026-09-01#every-doc-page-serves-itself-as-markdown-for-agents-and-people-alike) - [Seven PHR operations renamed](/docs/whats-new/2026-09-01#seven-phr-operations-renamed) ## 25 August 2026 4 changes - [The PHR role has API references](/docs/whats-new/2026-08-25#the-phr-role-has-api-references) - [M2 and M3 have real API references](/docs/whats-new/2026-08-25#m2-and-m3-have-real-api-references) - [What the new sources do not give you](/docs/whats-new/2026-08-25#what-the-new-sources-do-not-give-you) - [Corrections applied to the published files](/docs/whats-new/2026-08-25#corrections-applied-to-the-published-files) ## 24 August 2026 4 changes - [Read the HIE-CM modules](/docs/whats-new/2026-08-24#read-the-hie-cm-modules) - [Try the session token call](/docs/whats-new/2026-08-24#try-the-session-token-call) - [Find your way around M4, UHI and NHCX](/docs/whats-new/2026-08-24#find-your-way-around-m4-uhi-and-nhcx) - [The M1 agent skill](/docs/whats-new/2026-08-24#the-m1-agent-skill) ## What gets an entry An entry has to change what you build or what you must go back and fix. Six kinds qualify: | Kind | Example | | ----------------------------------------- | ---------------------------------------------------------------------- | | New coverage | A module, role or gateway you can now build against | | A correction | A documented fact was wrong, so what you built against it may be wrong | | A source republished | A specification changed, so a documented behaviour changed | | An operation renamed, added or withdrawn | Your calls have to change | | A new artefact you can consume | An OpenAPI file, an agent skill, an MCP server, the Markdown routes | | A procedure documented for the first time | The sandbox exit process, the security audit | Page layout, navigation, wording and visual changes do not get an entry. They change nothing you have to act on, and a changelog that carries them buries the entries that do.