# Outbreak alerts

Check weekly surveillance data against alert thresholds, notify districts and record each alert with its 7-1-7 dates.

Health facilities report weekly counts of notifiable diseases to DHIS2. Zato reads the counts of each district once a week, checks them against an alert threshold per disease, notifies the district when a threshold is crossed, and records the alert where the emergency response is managed - in a DHIS2 tracker program or in an emergency management system built on Odoo. The dates on which each alert was detected and notified are kept in a 7-1-7 register in DHIS2.

This section describes each stage of the integration. The pages build on one another and are read in order.

## Processing flow {#processing-flow}

```yaml
name: Weekly surveillance data to outbreak alert
actors:
  - id: zato
    label: Zato
  - id: dhis2
    label: DHIS2
  - id: district
    label: District
  - id: ems
    label: EMS
steps:
  - from: zato
    to: dhis2
    label: GET /api/analytics - twelve weeks of counts per district
  - from: dhis2
    to: zato
    kind: return
    label: Counts per disease, week and district
  - from: zato
    to: zato
    label: The week just ended checked against each threshold
  - from: zato
    to: district
    label: Email and SMS
  - from: zato
    to: dhis2
    label: POST /api/tracker - the alert in the alert program
  - from: zato
    to: ems
    label: The alert as an Odoo record, in place of the alert program
  - from: zato
    to: dhis2
    label: POST /api/tracker - dates in the 7-1-7 register
```

## Where Python thresholds start {#where-python-thresholds-start}

DHIS2 raises alerts of its own through predictors and validation rules, which compare a value to a fixed number or to a figure computed from earlier periods of the same data element. The integration on these pages is for what comes after that - rules written in Python that can combine diseases, districts and periods in any way, and alerts that reach people and systems outside DHIS2.

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

The integration assumes a DHIS2 instance with:

- A **weekly surveillance data set** to which facilities report their counts, with analytics tables updated after each reporting deadline.
- An **alert program**, a tracker program in which each alert is a tracked entity with one event holding the disease, the week and the number of cases. It is used when alerts are managed in DHIS2.
- A **7-1-7 register**, an event program with one data element per 7-1-7 milestone date.

## Pages in this section {#pages-in-this-section}

- [Setup](https://zato.io/docs/dev/healthcare/dhis2/outbreak-alerts/setup.html) - The connections and the configuration files
- [Weekly data](https://zato.io/docs/dev/healthcare/dhis2/outbreak-alerts/weekly-data.html) - Read twelve weeks of counts per district, and DHIS2 periods
- [Thresholds](https://zato.io/docs/dev/healthcare/dhis2/outbreak-alerts/thresholds.html) - Check each district against its disease's rule
- [District notifications](https://zato.io/docs/dev/healthcare/dhis2/outbreak-alerts/notify.html) - Email and SMS to the district
- [Alerts in DHIS2](https://zato.io/docs/dev/healthcare/dhis2/outbreak-alerts/dhis2-alert.html) - Each alert as a tracked entity in the alert program
- [Alerts in an EMS](https://zato.io/docs/dev/healthcare/dhis2/outbreak-alerts/ems.html) - Each alert as a record in an Odoo-based emergency management system
- [7-1-7 register](https://zato.io/docs/dev/healthcare/dhis2/outbreak-alerts/register.html) - Detection and notification dates for the 7-1-7 targets

## See also {#see-also}

`see-also-table
columns: [Feature, What it does]
rows:
  - page: docs/dev/healthcare/dhis2/index
    text: DHIS2 overview
    note: All DHIS2 integration pages
  - page: docs/dev/examples/scheduler
    text: Scheduler
    note: Interval-based jobs
  - page: docs/dev/odoo/index
    text: Odoo
    note: Connections to Odoo and its models`

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