ndhm.gov.in – ndhm-hiu

Tools (34)

Extracted live via the executor SDK.

• consentFlow.postV05ConsentRequestsOnInit

  Result of consent request creation for a patient. id represents the consentrequest id created by CM. The result must contain either id or the error caused.
  Reasons for error may be

  • Invalid references (e.g patient id, hiu id), purpose, hiTypes, ranges, persmission
• consentFlow.postV05ConsentRequestsOnStatus

  Result of consent request done previously. Status of request can be GRANTED, DENIED, EXPIRED. If the request was GRANTED, then

• consentFlow.postV05ConsentsHiuNotify

  Health information user will get notified about the consent request granted or denied, consent revoked, consent expired.

  1. For consent request grant, status=GRANTED, consentRequestId=, and consentArtefacts is an array of generated consent artefact Ids.
  2. For consent request expiry, status=EXPIRED, consentRequestId=
  3. For consent request denied, status=DENIED, consentRequestId=
  4. For consent revocation, status=REVOKED, consentArtefacts is an array of revoked consent artefact ids
• consentFlow.postV05ConsentsOnFetch

  Must contain either consent or error. Possible reason of errors are

  1. consentId passed through /fetch is invalid
• dataFlow.postV05HealthInformationHiuOnRequest

  Callback API for acknowledgement of Health information request made by HIU. Gateway calls this API when request has validated for the specified consent id. Either the hiRequest or error would be specified. If the health info request was valid, then the hiRequest.transactionId specifies the transaction context against which HIP would send over the data. Possible cases of errors are

  1. Invalid consent artefact id
  2. Consent has expired
  3. Date ranges are invalid
• dataFlow.postV05HealthInformationTransfer

  NOTE: This API is actually the callback URL that is passed as dataPushUrl in the data request API - /v0.5/health-information/hip/request. This API is directly called by HIP Data Bridge and is not mediated via CM, and hence not routed through the Gateway.

  1. This API should be implemented at HIU side. It maybe implemented by the Data Bridge representing the HIU.
  2. Entry elements maybe content or link, although for version 1, entry content is preferred.
  3. Entry content (or even link reference content) must be encrypted by means of Elliptic-curve Diffie–Hellman Key Exchange, utilizing the HIU keymaterials that are passed through the data request API - /v0.5/health-information/hip/request.
  4. Media contains the mimetype of content, and for v1, it is "application/fhir+json"
  5. checksum is Md5 checksum of the data conent, before encryption
  6. Please refer to the NDHM Sandbox documentation for the format of FHIR bundle that is passed through content
• gateway.getV05Certs

  Get certs for JWT verification

• gateway.getV05WellKnownOpenidConfiguration

  Get openid configuration

• gateway.postV05ConsentRequestsInit

  Creates a consent request to get data about a patient by HIU user.

• gateway.postV05ConsentRequestsStatus

  Get status of consent request done previously

• gateway.postV05ConsentsFetch

  Get consent artefact

• gateway.postV05ConsentsHiuOnNotify

  This API is called by HIU as acknowledgement to consent notifications, specifically for cases when consent is REVOKED or EXPIRED.

• gateway.postV05HealthInformationCmRequest

  Request for Health information against a consent id. CM would generate a transactionId against each consent and pass it as trnasaction context / correlation id to the HIP and also return the same to HIU via /on-request.

• gateway.postV05HealthInformationNotify

  API called by HIU and HIP during data-transfer.

  1. HIP on transfer of data would send sessionStatus - one of [TRANSFERRED, FAILED]
  2. HIP would also send hiStatus for each careContextReference - on of [DELIVERED, ERRORED]
  3. HIU on receipt of data would send sessionStatus - one of [TRANSFERRED, FAILED]. For example, FAILED when if data was not sent or if invalid data was sent
  4. HIU would also send hiStatus for each careContextReference - one of [OK, ERRORED]
• gateway.postV05PatientsFind

  This API is meant for identify to patient given her consent-manager-user-id

• gateway.postV05Sessions

  Get access token

• gateway.postV05SubscriptionRequestsCmInit

  creates a request for subscription. The subscription categories can be for care-contexts linkages or availability of data against existing care-contexts. Note that the requester must have HIU role

• gateway.postV05SubscriptionRequestsHiuOnNotify

  This API is called by HIU as acknowledgement to subscription request relevant notifications.

• gateway.postV05SubscriptionsHiuOnNotify

  This API is called by HIU as acknowledgement to consent notifications, specifically for cases when consent is REVOKED or EXPIRED.

• gateway.postV05UsersAuthConfirm

  This API is called by HIP/HIUs to confirm authentication of users. The transactionId returned by the previous callback API /users/auth/on-init must be sent. If Authentication is successful the callback API will send an "access token" for subsequent purpose specific API calls. Note only credential.authCode or credential.demographic should be sent

  1. demographic details are only required for demographic auth as of now.
  2. demographic details are required only in MEDIATED cases and if the auth.mode so demands. e.g. if auth.mode is DEMOGRAPHICS. Usually for demographic authentication, the name, gender and DOB must be exactly as specified in User Account.
  3. demographic.identifier is optional, however maybe required if authentication so mandates.
  4. credential.authCode is required for other MEDIATED authentication like MOBILE_OTP, AADHAAR_OTP.
• gateway.postV05UsersAuthFetchModes

  This API is meant for identify supported authentication modes for a patient given a specific purpose

• gateway.postV05UsersAuthInit

  This API is called by HIPs to initiate authentication of users. A transactionId is retuned by the corresponding callback API for confirmation of user auth.

  1. NOTE, only KYC purpose is applicable for HIU. Hence HIU should only sent KYC in query.authMode in the request
• gateway.postV05UsersAuthOnNotify

  This API is called by HIU/HIPs to confirm acknowledgement for receipt of auth notification is case of DIRECT authentication.

• identification.postV05PatientsOnFind

  If a patient is found then patient.name contains the patients name. Otherwise, patient is not provided, and possibly error is raised for invalid requests Note in addition to the "Authorization" header, one of the following headers must be specified

  1. specify X-HIU-ID if the requester is HIU (identified from /find requester.id)
  2. specify X-HIP-ID if the requester is HIP (identified from /find requester.id)
• monitoring.getV05Heartbeat

  Get consent request status

• subscriptions.postV05SubscriptionRequestsHiuNotify

  This API is used by CM to notify a HIU to grant or deny a request for subscription, and also to notify that in case an existing subscription is revoked or expired. For notifying that a particular subscription request was GRANTED or DENIED, the subscriptionRequestId is passed.

• subscriptions.postV05SubscriptionRequestsHiuOnInit

  This callback API acknowledges the request for subscription from a HIU, and sends back a "id" that will be used when the patient/user approves or denies the subscription.

• subscriptions.postV05SubscriptionsHiuNotify

  This API is used by CM to notify a HIU for notification relevant to subscription. Notifications are sent to subscribed HIUs whenever a new care-context is linked or new data is available on an existing linked care-context.

  1. if event.category = LINK, then only care-contexts are passed when new care-contexts are linked for patient.
  2. If event.category = DATA, then hiTypes are passed. Care-context is passed only if the subscribed HIU has any valid consent for that care-context
• userAuth.postV05UsersAuthNotify

  This API is called by CM to confirm authentication of users. The transactionId returned is same as that passed in /auth/on-init. The "auth.status" conveys whether the request was GRANTED or DENIED.

  1. auth.accessToken - is specific to the purpose mentioned in the /auth/init. This token needs to be used for initiating the intended action. For example for HIP initiated linking of care-contexts
  2. NOTE, only one of X-HIP-ID or X-HIU-ID will be sent as part of header, not both.
  3. The payload is conditional to the purpose of auth. If purpose specified in /auth/init is KYC or KYC_AND_LINK, then patient details are passed. auth.accessToken is passed only if the purpose is LINK or KYC_AND_LINK.
• userAuth.postV05UsersAuthOnConfirm

  This API is called by CM to confirm authentication of users.

  1. auth.accessToken - is specific to the purpose mentioned in the /auth/init. This token needs to be used for initiating the intended action. For example for HIP initiated linking of care-contexts
  2. NOTE, only one of X-HIP-ID or X-HIU-ID will be sent as part of header, not both.
• userAuth.postV05UsersAuthOnFetchModes

  If a patient is found then auth attribute contains the supported modes for the specified purpose. Otherwise, error is raised for invalid requests or for non-existent id. Note in addition to the "Authorization" header, one of the following headers must be specified

  1. X-HIU-ID if the requester is HIU (identified from /auth/fetch-modes requester.id)
  2. X-HIP-ID if the requester is HIP (identified from /auth/fetch-modes requester.id)
• userAuth.postV05UsersAuthOnInit

  If the patient's id is valid, CM will return a transactionId as initialization of user auth. If the request is valid, then 'auth.mode' will convey how the authentication should be done. The authentication can be mediated or direct. For mediated authentication modes, HIP or HIU is epected to send over relevant code (OTP/token) or demographic info via subsequent API call to /auth/confirm. for direct authentication case, CM will notify requester through/users/auth/notify API.

  1. auth.mode conveys whats the mode of authentication is, and what is expected from HIP/HIU in the subsequent /auth/confirm API call. Possible values
     1. MOBILE_OTP - auth via OTP to registered mobile. Mediated.
     2. AADHAAR_OTP - auth initiated with Aadhaar with OTP. Mediated.
     3. DEMOGRAPHICS - auth initiated with demographic verification
     4. DIRECT - for authentication directly with the patient. e.g. Mobile App, SMS. In this case, the HIP/HIU is not expected to call subsequent /auth/confirm call. CM will do direct authentication with the User (e.g. Mobile App, SMS etc) and will notify requester
  2. meta.expiry conveys the expiry time of the token and the authentication session
  3. NOTE, only one of X-HIP-ID or X-HIU-ID will be sent as part of header, not both.
  4. NOTE, only KYC purpose is applicable for HIU

  The error section in the body, represents the potential errors that may have occurred. Possible reasons:

  1. Patient id is invalid
• openapi.previewSpec

  Preview an OpenAPI document before adding it as a source

• openapi.addSource

  Add an OpenAPI source and register its operations as tools