# Setup

A REST channel and an API key per monitoring vendor, the outgoing connections and the appliance mapping.

This page is the first of the [Supply chain](https://zato.io/docs/dev/healthcare/dhis2/supply-chain/index.html) series. It covers the endpoint the vendors send to, the connections the services use and the configuration they read.

## A channel per vendor {#a-channel-per-vendor}

Each vendor gets credentials of its own, so that one vendor's access can be revoked or rotated without touching the others. For every vendor, there is an API key definition, created in the Dashboard under **Security** ▹ **API keys**, with the header the vendor sends the key in:

![API key for a vendor](https://zatosource-production.b-cdn.net/docs/gfx/dhis2/cold-chain-apikey-create.webp?v=1791212084)

Dashboard menu: Security > API keys

and a REST channel with that definition as its security. All the channels invoke the same service, because every vendor sends the same PQS E006 format:

| Name | URL path | Security |
| --- | --- | --- |
| `Cold Chain Vendor A` | `/cold-chain/telemetry/vendor-a` | `Cold Chain Vendor A` |
| `Cold Chain Vendor B` | `/cold-chain/telemetry/vendor-b` | `Cold Chain Vendor B` |

[Video: Channel for a vendor](https://zatosource-production.b-cdn.net/docs/gfx/dhis2/cold-chain-channel-create.webm?v=1791212156)

Dashboard menu: Connections > Channels > REST

The vendor is given the full address of its channel, such as `https://zato.example.com/cold-chain/telemetry/vendor-a`, together with its key.

## The outgoing connections {#the-outgoing-connections}

The services reach DHIS2 through REST outgoing connections using the `DHIS2` security definition from [DHIS2 security](https://zato.io/docs/dev/healthcare/dhis2/security.html):

| Name | URL path | Used by |
| --- | --- | --- |
| `DHIS2 Data Values` | `/api/dataValueSets` | Writing temperature readings |
| `DHIS2 Events` | `/api/tracker/events` | Reading consignment receipts |

Alarms reach the district through the `District Alerts` SMTP connection and the `SMS Gateway` REST connection, created as in [Outbreak alerts](https://zato.io/docs/dev/healthcare/dhis2/outbreak-alerts/setup.html#the-notification-channels), and the addresses of each district come from `districts.ini` described there. Receipts go to the warehouse system through a REST outgoing connection named `Central Store`, pointing to the endpoint of its API that records receipts.

## The appliances {#the-appliances}

`cold_chain.ini` has a section per appliance, named after its serial number, the `ASER` field of each report. Each appliance has the facility it is in, its data element in the Temperature Monitoring Tool, the district notified of its alarms, and the label it has in messages:

```ini
# config/user-conf/cold_chain.ini

[appliances]

[[RF-0001-7734]]
label = Health Centre 12 - Vaccine refrigerator 1
org_unit = DiszpKrYNg8
data_element = Tv3nH8qLw2B
district = O6uvpzGd5pu

[[RF-0002-1185]]
label = Health Centre 12 - Vaccine refrigerator 2
org_unit = DiszpKrYNg8
data_element = Pk6xD1sRm9F
district = O6uvpzGd5pu
```

The same file has the six category option combinations of the Temperature Monitoring Tool, one per half of the day and measurement, and the time zone of the facilities, as hours from UTC:

```ini
[combos]
morning_minimum = Qa1bC2dE3fG
morning_current = Hi4jK5lM6nO
morning_maximum = Pq7rS8tU9vW
afternoon_minimum = Xy0zA1bC2dE
afternoon_current = Fg3hI4jK5lM
afternoon_maximum = No6pQ7rS8tU

[tmt]
utc_offset_hours = 2
afternoon_from_hour = 12
cache_seconds = 172800
```

## Next {#next}

[Temperature readings](https://zato.io/docs/dev/healthcare/dhis2/supply-chain/readings.html) writes the readings of each report to the Temperature Monitoring Tool.

## See also {#see-also}

- [REST channels](https://zato.io/docs/dev/rest/channels.html) - Endpoints that external systems call
- [REST authentication](https://zato.io/docs/dev/rest/authentication.html) - API keys and other security definitions

## Learn more {#learn-more}

- [Healthcare interface engine](https://zato.io/docs/dev/healthcare/) - Clinical messages, FHIR, conversion and operations
- [HL7 v2 parsing](https://zato.io/docs/dev/healthcare/hl7/v2/parsing/) - Messages as typed objects, with field access and validation
- [MLLP channels](https://zato.io/docs/dev/healthcare/hl7v2/mllp/) - Receiving and sending HL7 v2 over MLLP sockets
- [FHIR integrations](https://zato.io/docs/dev/healthcare/hl7/fhir/) - Read and write FHIR resources, with paths, bundles and extensions
- [HL7 v2 to FHIR](https://zato.io/docs/dev/healthcare/hl7/to-fhir/) - Converting v2 messages into FHIR bundles, codes and references included
- [EDIFACT](https://zato.io/docs/dev/healthcare/edifact/) - Parsing interchanges, dialects and the transports they arrive on
- [Transformation](https://zato.io/docs/dev/healthcare/transformation/) - One message in, another standard out, in ordinary Python
- [Audit log](https://zato.io/docs/dev/healthcare/audit-log.html) - Every message with its acknowledgment, searchable by patient identifier
- [AI in clinical interfaces](https://zato.io/docs/dev/healthcare/ai/) - Services calling LLMs and AI agents calling clinical services as tools