# Setup

The connections and the configuration files the outbreak alert services use.

This page is the first of the [Outbreak alerts](https://zato.io/docs/dev/healthcare/dhis2/outbreak-alerts/index.html) series. It covers what is configured once, before any service is written.

## The DHIS2 connections {#the-dhis2-connections}

The services reach DHIS2 through two REST outgoing connections. Both use the `DHIS2` security definition from [DHIS2 security](https://zato.io/docs/dev/healthcare/dhis2/security.html) and `JSON` as the data format:

| Name | URL path | Used by |
| --- | --- | --- |
| `DHIS2 Analytics` | `/api/analytics` | Reading the weekly counts per district |
| `DHIS2 Tracker` | `/api/tracker` | Writing alerts and 7-1-7 register events |

## The notification channels {#the-notification-channels}

Districts are notified by email and by SMS:

1. **Email.** An [SMTP connection](https://zato.io/docs/dev/examples/smtp.html) named `District Alerts`, created under **Connections** ▹ **Outgoing** ▹ **E-mail** ▹ **SMTP**.
2. **SMS.** A REST outgoing connection named `SMS Gateway`, pointing to the endpoint of the SMS provider's API that sends a message, with the security definition the provider's credentials call for.

[Video: SMTP for district alerts](https://zatosource-production.b-cdn.net/docs/gfx/dhis2/alerts-smtp-create.webm?v=1791212174)

Dashboard menu: Connections > Outgoing > E-mail > SMTP

## The EMS connection {#the-ems-connection}

When alerts are managed in an emergency management system built on Odoo, the services reach it through an [Odoo connection](https://zato.io/docs/dev/odoo/index.html) named `EMS`, created under **Connections** ▹ **Outgoing** ▹ **Odoo** with the address, database and user of the EMS.

[Video: Odoo-based EMS](https://zatosource-production.b-cdn.net/docs/gfx/dhis2/alerts-odoo-create.webm?v=1791212175)

Dashboard menu: Connections > Outgoing > Odoo

## The configuration files {#the-configuration-files}

`alerts.ini` holds the level of the organisation unit hierarchy that districts are on, the service that records alerts, the sender of the emails, and one section per disease with the data element its counts are reported under and the rule it is checked with:

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

[analytics]
district_level = 2

[record]
service = dhis2.alerts.record-alert

[email]
sender = surveillance@example.com

[diseases]

[[cholera]]
data_element = UsSUX0cpKsH
rule = single_case

[[malaria]]
data_element = vq2qO3eTrNi
rule = baseline
baseline_weeks = 8
deviations = 2
minimum = 5
```

`districts.ini` has one section per district, named after the district's UID, with the name used in messages and the addresses the district is notified at. Phone numbers are quoted so they are read as text:

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

[O6uvpzGd5pu]
name = North
email = surveillance.north@example.com
phone = '+15555550104'

[fdc6uOvgoji]
name = East
email = surveillance.east@example.com
phone = '+15555550107'
```

`alert_programs.ini` holds the identifiers of the alert program and the 7-1-7 register:

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

[alert]
id = Xb4mT0vQd8L
tracked_entity_type = Gq2LpZ7cW1n
stage_signal = Rk8vN3sYd5H
element_disease = Ua6tP9wKe2J
element_week = Hc1zS4oBm7Q
element_cases = Wd3rF8jLn0T

[register]
id = Jm5yC2gXa9V
stage = Pe7kD1uRt4Z
element_disease = Tn9bV6hQs3M
element_detected = Lf2wE8cYp6K
element_notified = Zs4qA7nJv1D
```

`ems.ini` is described on [Alerts in an EMS](https://zato.io/docs/dev/healthcare/dhis2/outbreak-alerts/ems.html).

## Next {#next}

[Weekly data](https://zato.io/docs/dev/healthcare/dhis2/outbreak-alerts/weekly-data.html) reads twelve weeks of counts per district from DHIS2 analytics.

## See also {#see-also}

`see-also-table
columns: [Feature, What it does]
rows:
  - page: docs/dev/examples/smtp
    text: SMTP
    note: Sending email from services
  - page: docs/dev/odoo/index
    text: Odoo
    note: Connections to Odoo and its models
  - page: docs/dev/examples/config
    text: Config files
    note: Nested sections and values read through self.config`

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