> For the complete documentation index, see [llms.txt](https://docs.coronasafe.network/abdm-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coronasafe.network/abdm-documentation/implementers-guide/building-health-locker.md). # Building Health Locker The health locker APIs are essentially the same as that for Health Repository Provider (HRP), since a digital health locker play the role of HIP to provide health information as well as the role of HIU to retrieve health information from other HIPs. Please refer below link for API Documentation:\ [HRP APIs![](data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABACAYAAACqaXHeAAAACXBIWXMAACxLAAAsSwGlPZapAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAIDSURBVHgB7dpBUsIwFAbgPxH3HkFvoCeQDc648wbgQRBwvIf1BrpidFzUG3gEjsBeJPbBMCIgCSVJX8r7Zlyohen/Q9KmLSCEEEKIQ6Wct+wPmzhq9IqXnAPmBL50W+v7MHjNoHUbPmx6/yUNuHh4b8OYbP6LQZ1o6xb94elv+PqxF9A47qHG7AUYc4Mac5kD1ic8pTJMpx8IReusKD7fuo1SNEk2sSe3SXAVhb+7yhBKt5Vv/f98Um7CA/sQ4ObPEWl/aRXgOTxJpwB7+GeUkEYBtvDG3BY/LyiBfwEu4feYkHkXEDg84VtAhPCEZwGRwhN+BUQMT3gVEDk84VNABeFJubWAbz7CKzWaLdJ2VH0Bvj75+QIqx46qHQIVfe2XVVcAg/CkmgKYhCfxC2AUnsSdBEOGv3/rFEeBx7W/W+4LxPsGMPvkF+IUwDQ8CV8A4/AkbAHMw5NwBSQQnoQpIJHwxH8BtpupjMKTAAVcj2YhN2EWnoQZAhRytQSG4Um4SXC5BKbhSdjDIIX+npxxDU/CnwjRnMBYeneHPZMCcOCkABy4cleEtL4srsCAFdons/tDnC4FjLH6pJgxdPmpA042hx9bXuU0BD6RKqWsj824FDBAqiZf1n23F0C3nP5b3XFG++xwFup2FFic08M8wWFcVYj2LYc2F5zXH0IIIYTg4Qf5mSgwxEiacwAAAABJRU5ErkJggg==)](https://sandbox.abdm.gov.in/swagger/ndhm-bridge.yaml) #### Prerequisites/Setup * Should have applied to ABDM as a **health locker** * A Locker should also mention endpoints for below functions: * * **Registration** - either a HTTPS URL that will take the user to the registration/signup page on browser or a android intent invocation URL that can be used to launch the locker app * **Upload documents** - either HTTPs URL that will take the user to upload page on browser Or android intent invocation URL that can be used to upload document to the locker * While applying, please mention whether the url is a HTTP URL or an android URL. * Once approved, the entity will be registered with the FHR Gateway as **HEALTH\_LOCKER** type having HIU, HIP and additional HEALTH\_LOCKER roles. #### Integration of Capabilities with ABDM FHR architecture Digital Health Lockers, while connected with the ABDM network, plays the role of a HIU and HIP and needs to adhere to the specifications so defined. * While requesting data from HIPs (in case of synchronization of data from HIPs), it plays the role of HIU * While providing data to a HIU, it plays the role of a HIP. * ABDM ABHA Mobile Application provides users with options to specify special accesses to a Locker Service at their discretion. * * Long-term **Link Token** for Lockers to establish care-context linkages in future. * Auto approval for consent requests, so that the user does not need to explicitly grant consent for data transfer. #### Essential integration of locker with ABDM network in brief **Registration with FHR gateway** * Each Locker will be registered with the FHR Gateway as **HEALTH\_LOCKER** type along with **HIU** and **HIP** type. * Lockers must mention how their sign-up and document-upload can be invoked. Current means are through launching URL on browsers or invocation of android app intent. * Lockers must be able to validate the healthId and keep a linkage with the healthId (hinapatel\@ndhm or 11-2222-3333-4444\@ndhm) Following curl command can be used to register as HEALTH\_LOCKER on the sandbox. The endpoints ``` curl --location --request PUT 'https://dev.abdm.gov.in/devservice/v1/bridges/services' --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Authorization: Bearer your-access-token-from-gateway-session' --data-raw '{ "id": , "name": , "type": "", "active": true, "alias": [ ], "endpoints": [{"address":,"connectionType":,"use":}] }' ``` * The `endpoints` field is only needed when the `type` is `HEALTH_LOCKER`. * Every locker needs to provide two endpoint to be able to register the user and to enable user to upload their documents. This is mentioned by the `use` field under specific `endpoint`. * The addresses could be a webpage URL([www.example.com/register](http://www.example.com/register)) or a package-name of an android app(in.ndhm.phr/register).This is mentioned by the `connectionType` field under specific `endpoint`. **User sign-up with locker** User sign-up happens independently using the locker interfaces (app or browser). Upon user sing-up, Locker should immediately initiate * Authorization request * Subscription request **Authorization** * Locker should initiate authorization request to get long-term linking token from the user so that it can link records with CM account. The process of getting such linking token is the same as HIP initiated linking with the auth-mode as DIRECT. * Lockers can leverage the Gateway Auth APIs to get this linking token and identifying themselves as HIP for purpose of LINK. * If Locker wishes, it can also do a KYC\_AND\_LINK(Gateway Auth API with purpose=KCY\_AND\_LINK) to verify the requesting patient along with getting the linking token. **Data upload** * On direct upload of a document by the patient, Lockers should define one or more **care-contexts** under which documents are grouped. * Note, whenever any new information is available at the locker, it must use the Linking Token to establish the care-context linkage with CM. Without this linkages know to the CM, user will not be able to share her records to any HIU. * If any health document is grouped under an existing and linked care-context, Locker must notify the CM of data availability against an existing care-context. **Subscription** * Locker should initiate subscription request so that it receives notifications/alerts whenever new information is available for following categories. 1. LINK - linking of a new Care-context from HIPs 2. DATA - availability against an existing care-context from HIP. * While seeking subscription Locker needs to use the Gateway Subscription APIs identifying itself as HIU. * Upon grant of such subscription, Lockers will be notified against the subscribed categories. * If the event category is **LINK** - Lockers should subsequently make a request for consent for the notified contents or leverage any existing consent applicable for the notification. And upon approval of consent, initiate data-request. * In case, event category is **DATA** - then the locker should check if any existing consent applies (HIType and duration etc) and use the same to initiate data-request instead. **Data transfer** * When a HIU requests data and patient provides consent for access of consented data from his/her locker, the Locker must be able to validate the consent, and send relevant health Information, and notify CM subsequently of such transfer * Health Documents (either self uploaded or synchronized from other HIPs) should be sent as per ABDM FHIR profiles standard with content Encrypted as per FHR Gateway specification.

Health Locker flows

Subscription notification upon data availability