← Back to catalog

Other

Health Data Consent Manager

auto-generated
swirls add ndhm
actionPOSTv1.0.0

API for HIP initiated care-context linking for patient

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

Source
actionPOSTv1.0.0

Consent notification

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***.

Source
actionPOSTv1.0.0

Consent notification

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***.

Source
actionPOSTv1.0.0

Create consent request

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

Source
actionPOSTv1.0.0

Get consent artefact

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***

Source
actionPOSTv1.0.0

Get consent request status

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

Source
actionPOSTv1.0.0

Initialize authentication from HIP

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.

Source
actionPOSTv1.0.0

Request for subscription

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

Source
actionPOSTv1.0.0

Response to patient's account discovery request

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**

Source
actionPOSTv1.0.0

Response to patient's care context link request

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**

Source
Beyond the catalog

Any provider, on request.

01

Request it

Tell us which provider you need, and we will ship it in the registry.

02

Generate it

Point swirls add at an OpenAPI or GraphQL spec. Typed actions for any API you hold credentials for, today.

acme · integrations
terminal
~/acme $swirls add linear
✓ 12 typed actions · scopes and schemas included
 
~/acme $swirls add https://api.acme.dev/openapi.json
◆ Fetched spec · 38 operations
✓ 6 typed actions · generated from spec