# Setup

Two DHIS2 instances, their connections, and the files that map one instance's org units and codes to the other's.

This page is the first of the [One Health](https://zato.io/docs/dev/healthcare/dhis2/one-health/index.html) series. It covers the connections to both DHIS2 instances and the files that translate between them, which every later page uses.

## A token per instance {#a-token-per-instance}

Each instance issues its own personal access token to its own integration user, so there are two bearer token definitions, `DHIS2 Animal Health` and `DHIS2 Public Health`, each created as in [DHIS2 security](https://zato.io/docs/dev/healthcare/dhis2/security.html) with the token of its instance:

![Token for animal health](https://zatosource-production.b-cdn.net/docs/gfx/dhis2/one-health-bearer-token-create.webp?v=1791212101)

Dashboard menu: Security > Bearer tokens

## The connections {#the-connections}

The services reach both instances through REST outgoing connections with `JSON` as the data format:

| Name | Host | URL path | Security |
| --- | --- | --- | --- |
| `Animal Health Events` | `https://animal-health.example.com` | `/api/tracker/events` | `DHIS2 Animal Health` |
| `Animal Health Analytics` | `https://animal-health.example.com` | `/api/analytics` | `DHIS2 Animal Health` |
| `Public Health Tracker` | `https://public-health.example.com` | `/api/tracker` | `DHIS2 Public Health` |
| `Public Health Data Values` | `https://public-health.example.com` | `/api/dataValueSets` | `DHIS2 Public Health` |

[Video: Animal health events](https://zatosource-production.b-cdn.net/docs/gfx/dhis2/one-health-rest-events-create.webm?v=1791212186)

Dashboard menu: Connections > Outgoing > REST

The AMR data sets and programs are in the public health instance in these pages. When they are in an instance of their own, the AMR services use two more connections pointing to it.

## Two hierarchies {#two-hierarchies}

The two instances divide the country differently. Veterinary units rarely follow the borders of health districts, and the same place has a different UID in each instance. `org_units.ini` is a [config table](https://zato.io/docs/dev/examples/config-tables.html) with one section per instance - each line is a UID of that instance and the district it belongs to, under a name the file itself uses:

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

[ANIMAL_HEALTH]
Vk3mQ8tRz2L = DISTRICT_01
Pa7nX4cWb9E = DISTRICT_01
Ts5hD2yGu8N = DISTRICT_02

[PUBLIC_HEALTH]
O6uvpzGd5pu = DISTRICT_01
fdc6uOvgoji = DISTRICT_02
```

Two veterinary units belong to `DISTRICT_01`, and both translate to the one public health district:

```python
org_units = self.config.org_units
org_unit = org_units.translate(source='ANIMAL_HEALTH', code=uid, target='PUBLIC_HEALTH')
```

`translate` returns None for a UID the file does not list, and raises `AmbiguousTarget` from `zato.common.user_config` when a district appears twice under `PUBLIC_HEALTH`, because there is then no single UID to send.

## Disease codes {#disease-codes}

The option sets that name diseases differ too, and `diseases.ini` maps them the same way:

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

[ANIMAL_HEALTH]
RABV = RABIES
ANTH = ANTHRAX

[PUBLIC_HEALTH]
A82 = RABIES
A22 = ANTHRAX
```

## The programs {#the-programs}

`one_health.ini` holds the UIDs of the notification programs on both sides, the cache key under which the notifications service keeps its place, and the time its first run starts reading from:

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

[notifications]
marker_key = dhis2.one-health.notifications.updated-after
start = 2026-10-01T00:00:00

[animal_program]
id = Qm4vB8nTx2R
element_disease = Kc7pW1sLa5D

[public_program]
id = Ht2xN6jQe9F
stage = Yb8rC3kVm1S
element_disease = Ew5zA9gUp4T
```

## Next {#next}

[Zoonotic notifications](https://zato.io/docs/dev/healthcare/dhis2/one-health/notifications.html) carries notifications from the animal health instance to public health.

## See also {#see-also}

- [Config tables](https://zato.io/docs/dev/examples/config-tables.html) - Translate the codes of one party into another's
- [DHIS2 security](https://zato.io/docs/dev/healthcare/dhis2/security.html) - Personal access tokens and their rotation

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