> 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-hiu.md).
# Building HIU
API Documentation for building the HIU is available here:\
[HIU APIs](https://sandbox.abdm.gov.in/swagger/ndhm-hiu.yaml)
[**Link to HIU Document**](https://sandbox.abdm.gov.in/static/media/Building%20HIU%20System%20_%20API%20Flow_M3_Documentation.5327c6f3.pdf)
The flows which have to be built are:
#### 1. Creation of consent request and notifying it to the patient
From an HIU perspective, the flow begins when the HIU (e.g. a Doctor at a Hospital) requests consent to view patient’s data. Upon receipt of such a request from Gateway, CM acknowledges and sends back a *consent request ID* to the HIU via the gateway. The CM then notifies the patient that a HIU has made a consent request. The patient can view the request details, and choose to either grant consent or deny it.
Subsequently, the CM notifies the HIU requester of the patient’s consent or denial status via the gateway.
* If the request is granted, the CM sends across the Ids of the consent artefacts that were created against the request, to the HIU.
* If the request is denied, the CM simply notifies the HIU of the denial of the request;
The following diagram explains the consent request creation flow of forwarding the request to the gateway so that gateway can forward it to respective CM
Consent Request by HIU
#### 2. Patient Consent notification from CM to HIU
Consent Notification from CM to HIU
#### 3. Fetching the consent artefact
Once the patient grants consent to the HIU, the CM notifies the HIU system of the consent grant via the gateway. If the patient grants for multiple HIPs, then multiple consent artefacts are generated - one for each HIP. The HIU now first fetches all the consent-artefacts that were generated for his request.
Fetching Consent Artefact
#### 4. Data request and transfer
The data request and transfer process between the HIU, CM and HIP passes through the following three stages:
**First Stage**
* The HIU system initiates data request for a patient’s health information to the HIP against the relevant consent-artefact, through the CM.
* As part of the data request, the HIU’s health repository embeds three key elements within the health information request:
* * The consent ID corresponding to the consent artefact against which the information request is being made.
* A data push URL, which is a callback URL that indicators where the information can be pushed by the HIP’s health repository. This URL can be different from the HIU’s access URL, provided at the time of registration with the gateway. The HIU can specify a different URL for the data flow, in order to keep its identity secret to the extent possible.
* Several parameters such as the date-time range for the requested and a set of encryption parameters for the HIP repository to encrypt the information. The Elliptic-curve Diffie–Hellman based encryption standard is used for encrypting health information.
* Upon receipt of the data-request, CM assigns a transaction ID (txn-id) for the entire data flow and communicates this Id to the health repositories of the HIU and the HIP.
The HIU’s health repository relays all this information to the CM through the gateway. From the CM, the information is relayed to the HIP’s health repository (via the gateway).
**Second Stage**
Once the HIP repository receives the information, it first validates the information request, as follows:
* The HIP finds out if the consent ID corresponds to an expired, paused or revoked artefact.
* It then checks if the request’s date-time range will correspond to the range for which the consent artefact allows information access. It also ensures that the encryption parameters are correctly defined.
* Once the above checks are made and validated, the HIP health repository encrypts the requested health records and forwards it along with the transaction ID to the HIU’s data push URL, after signing the encrypted data with its long-term private key.
**Third Stage**
Finally, the CM receives notifications from both the HIP and the HIU. The HIP’s health repository notifies the CM that the requested information was transmitted to the HIU. The HIU’s health repository sends a notification that the requested information was successfully received, or that the request failed.
All above 3 stages that pertains to HIU are shown in the following diagram:
Health Data Request and Transfer
Please note:
* For more details on data transfer, please refer [Webinar](https://www.youtube.com/watch?v=oZ9Z2JtO21Q\&feature=youtu.be)
#### Meta Codes
While requesting and exchanging health information, there are meta codes that are relevant to you if you are a HIU.
* Purpose of Use - defines what is the purpose of use of the health information that a HIU is requesting for. The following are subset from
| Code | Display |
| ------- | ------------------------------------ |
| CAREMGT | Care Management |
| BTG | Break the Glass |
| PUBHLTH | Public Health |
| HPAYMT | Healthcare Payment |
| DSRCH | Disease Specific Healthcare Research |
| PATRQT | Self Requested |
* Health Information (HI) Types - defines what types of information a requester is asking for. As of now, the following types are supported.
| Code | Display |
| -------------------- | ------------------- |
| Prescription | Prescription |
| DiagnosticReport | Diagnostic Report |
| OPConsultation | OP Consultation |
| DischargeSummary | Discharge Summary |
| ImmunizationRecord | Immunization Record |
| HealthDocumentRecord | Record artifact |
| WellnessRecord | Wellness Record |
