Tools (24)

Extracted live via the executor SDK.

• consent.postV05ConsentRequestsInit

  Creates a consent request to get data about a patient by HIU user. CM should call Gateway - /v0.5/consent-requests/on-init API with the consent-request-id

• consent.postV05ConsentRequestsStatus

  Get status of consent request done previously. CM responds by calling Gateway API - /v0.5/consent-requests/on-status

• consent.postV05ConsentsFetch

  This API is called when a HIU makes a request to get a consent artefact. For response please refer to the Gateway /v0.5/consents/on-fetch

• consent.postV05ConsentsHipOnNotify

  This API is called by HIP as acknowledgement to notification of consents, in cases of consent revocation and expiration, notified by CM earlier via Gateway API - /v0.5/consents/hip/notify.

• consent.postV05ConsentsHiuOnNotify

  This API is called by HIU as acknowledgement to consent notifications, specifically for cases when consent is REVOKED or EXPIRED, notified by CM earlier via Gateway API - /v0.5/consents/hiu/notify.

• dataFlow.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]
• dataFlow.postV05HealthInformationOnRequest

  This API is called by HIP to acknowledge Health information request receipt. When HIU requests health information, CM generates a transactionId and makes a health information request to the HIP(s). HIPs acknowledgement to the health-information request is coveyed by this API. Either the hiRequest or error must be specified. hiRequest element returns the same transactionId as before with a status indicating that the request is acknowledged.

• dataFlow.postV05HealthInformationRequest

  HIU 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 Gateway API - /v0.5/health-information/cm/on-request.

• discovery.postV05CareContextsOnDiscover

  Result of patient care-context discovery request at HIP end. If a matching patient found with zero or more care contexts associated, it is specified as result attribute. If the prior discovery request, resulted in errors then it is specified in the error attribute. Reasons of errors can be

  1. more than one definitive match for the given request
  2. no verified identifer was specified
• identification.postV05PatientsFind

  This API is meant for identify to patient given her consent-manager-user-id. CM subsequently makes the /on-find Gateway API call with results.

• link.postV05LinksLinkAddContexts

  API to submit care-context to CM for HIP initiated linking. The API must accompany the "accessToken" fetched in the users/auth process.

  1. subsequent usage for accessToken may be invalid if it was meant for one-time usage or if it expired
• link.postV05LinksLinkOnConfirm

  Returns a list of linked care contexts with patient reference number.

  1. Validated and linked account reference number
  2. Validated that the token sent from Consent Manager is same as the one generated by HIP
  3. Verified that same Consent Manager which made the link request is sending the token
  4. Results of unmasked linked care contexts with patient reference number
• link.postV05LinksLinkOnInit

  Result of patient care-context link request from HIP end. This happens in context of previous discovery of patient found at HIP end, therefore the link requests ought to be in reference to the patient reference and care-context references previously returned by the HIP. The correlation of discovery and link request is maintained through the transactionId. HIP should have

  1. Validated transactionId in the request to check whether there was a discovery done previously, and the link request corresponds to returned patient care care context references
  2. Before returning the response, HIP should have sent an authentication request to the patient(eg: OTP verification)
  3. HIP should communicate the mode of authentication of a successful request
  4. HIP subsequently should expect the token passed via /link/confirm against the link.referenceNumber passed in this call

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

  1. Patient reference number is invalid
  2. Care context reference numbers are invalid
• monitoring.getV05Heartbeat

  Get consent request status

• profile.postV05PatientsProfileOnShare

  Result of patient share profile request at HIP end.

• subscriptions.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

• subscriptions.postV05SubscriptionRequestsHiuOnNotify

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

• subscriptions.postV05SubscriptionsHiuOnNotify

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

• userAuth.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.
• userAuth.postV05UsersAuthFetchModes

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

• userAuth.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.

• userAuth.postV05UsersAuthOnNotify

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

• openapi.previewSpec

  Preview an OpenAPI document before adding it as a source

• openapi.addSource

  Add an OpenAPI source and register its operations as tools