DHIS2 Tracker Konfiguration: Eine Schritt-für-Schritt-Anleitung

Die meisten Fehler bei der Ausbruchsüberwachung sind keine Fehler bei der Datenerfassung. Es sind Fehler im Systemdesign in Situationen, in denen erfasste Daten nie die Personen erreichen, die darauf reagieren müssen, und das in der Form, in der sie sie benötigen, und zum richtigen Zeitpunkt.

DHIS2 Tracker ist eines der leistungsfähigsten Tools zur Nachverfolgung einzelner Fälle, die nationalen Gesundheitssystemen zur Verfügung stehen. Richtig eingesetzt, schließt es die Lücke zwischen einem Verdachtsfall in einer primären Gesundheitseinrichtung und einer koordinierten Reaktion auf Landes- oder nationaler Ebene. Falsch eingesetzt, wird es zu einem weiteren System, das Berichte generiert, die niemand liest.

Warum Nachverfolgen statt Aggregieren?

Bevor etwas konfiguriert wird, lohnt es sich zu fragen, ob DHIS2 Tracker überhaupt das richtige Modul ist. DHIS2 verfügt über zwei primäre Datenmodelle: Aggregat (periodische Zusammenfassungsdaten) und Tracker (längsschnittliche Falldaten auf individueller Ebene). Für die routinemäßige Berichterstattung zur Krankheitsüberwachung sind wöchentliche Fallzahlen pro Einrichtung im Aggregat ausreichend und viel einfacher zu verwalten.

Tracker wird notwendig, wenn Sie:

Einen einzelnen Fall über mehrere klinische Kontakte hinweg verfolgen müssen
Kontaktverfolgungszusammenhänge (Quellfall zu Kontakten) erfassen müssen
Automatische Warnungen auslösen müssen, wenn Fallschwellenwerte überschritten werden
Ergebnisse nach individuellen Attributen (Alter, Geschlecht, Impfstatus, Reiseanamnese) aufschlüsseln müssen
Den Untersuchungsstatus und den Abschluss für jeden bestätigten Fall verfolgen müssen

Speziell für die Ausbruchsüberwachung macht die Fähigkeit von Tracker, Fälle mit Kontakten zu verknüpfen, Untersuchungszeitpläne aufzuzeichnen und individuelle Fallberichte zu erstellen, die in nationale Meldesysteme einfließen, die zusätzliche Investition in die Konfiguration lohnenswert.

Schritt 1: Programmdesign vor der Konfiguration

Der häufigste Fehler bei der Tracker-Implementierung besteht darin, DHIS2 zu öffnen und mit dem Aufbau zu beginnen, bevor das Programmdesign abgeschlossen ist. Bevor ein einziges Datenelement erstellt wird, klären Sie:

Wer erfasst was, und wann? Bilden Sie den Falllebenszyklus von der Identifizierung eines Verdachtsfalls bis zum Fallabschluss ab. Jede Phase im Untersuchungsablauf wird einer Tracker-Programmphase zugeordnet.
Welche Entscheidungen sollen die Daten beeinflussen? Arbeiten Sie rückwärts von den Entscheidungen, die wichtig sind. Wenn der Warnschwellenwert drei Fälle in einer einzigen Woche in einer einzigen Einrichtung beträgt, muss dieser Schwellenwert in die Programmlogik integriert werden und nicht an einen Vorgesetzten gemeldet werden, der manuell entscheidet.
Was ist der minimal brauchbare Datensatz? Tracker-Implementierungen brechen häufig unter der Last der Datenerfassung zusammen. Definieren Sie den minimalen Satz von Datenelementen, der die erforderlichen Entscheidungen ermöglicht, und widerstehen Sie der Versuchung, mehr hinzuzufügen, nur weil das System es zulässt.

Schritt 2: Konfiguration der Programmphasen

Für die Ausbruchsüberwachung verwendet ein gut gestaltetes Tracker-Programm typischerweise vier Phasen:

Phase 1: Fallregistrierung und Erstbenachrichtigung

Erfasst Informationen, die beim ersten Kontakt verfügbar sind. Erforderliche Datenelemente umfassen das Datum des Beginns, das Datum der ersten Konsultation, die meldende Einrichtung, Patientenidentifikatoren, die primäre Symptomkonstellation und die anfängliche Fallklassifikation. Halten Sie diese Phase kurz – Außendienstteams sollten sie in weniger als fünf Minuten abschließen. Ziel ist die frühe Signaldetektion, nicht die klinische Dokumentation.

Phase 2: Falluntersuchung

Die detaillierte epidemiologische Untersuchung, durchgeführt von einem geschulten Beamten. Erfasst den vollständigen Symptomzeitplan, die Expositionsgeschichte, den Impfstatus, die Kontaktliste, Details zur Probenentnahme und das klinische Ergebnis zum Zeitpunkt der Untersuchung.

Phase 3: Laborergebnisse

Entwickelt, um Ergebnisse direkt vom Laborinformationssystem zu empfangen, wo eine Integration besteht, oder über manuelle Eingabe, wo dies nicht der Fall ist. Das Schlüsselfeld ist der Probenstatus (ausstehend, empfangen, getestet, Ergebnis vorhanden), der die Aktualisierung der Fallklassifikation steuert.

Phase 4: Fallabschluss

Erfasst die endgültige Klassifikation, das Ergebnis (genesen, gestorben, Nachverfolgung verloren) und eine narrative Untersuchungszusammenfassung. Diese Phase löst die Entfernung des Falls aus dem aktiven Überwachungs-Dashboard aus. Kein Fall sollte unbegrenzt offen bleiben.

Schritt 3: Datenelement-Konfiguration

Drei Eigenschaften sind für die Überwachung am wichtigsten: Werttyp, Optionssatz und Aggregationstyp.

Werttypen: Verwenden Sie TEXT nur, wenn Freitext wirklich notwendig ist. Bevorzugen Sie INTEGER, DATE, BOOLEAN oder OPTION_SET für alle strukturierten Daten. Freitextfelder können nicht aggregiert, gefiltert oder in Programmregeln verwendet werden.
Optionssätze: Erstellen Sie Optionssätze sorgfältig und verwenden Sie sie programmübergreifend wieder. Ein Fallklassifikation-Optionssatz, der konsistent in jedem Krankheitsprogramm verwendet wird, ermöglicht eine krankheitsübergreifende Analyse. Inkonsistente Optionssätze machen dies unmöglich.
Aggregationstyp: Setzen Sie die meisten Datenelemente auf COUNT oder SUM. Setzen Sie NONE für Bezeichnungsfelder, die nicht aggregiert werden sollen.

Schritt 4: Programmregeln für die Datenqualität am Erfassungspunkt

Programmregeln sind der Mechanismus von DHIS2 zur Anwendung von Logik auf Formularebene. Für die Ausbruchsüberwachung sind sie nicht optional. Wesentliche Programmregeln umfassen:

Datumslogik: Verhindern Sie, dass das Datum des Beginns nach dem Datum des Fallabschlusses erfasst wird. Verhindern Sie, dass das Untersuchungsdatum vor dem Registrierungsdatum erfasst wird.
Validierung der Falldefinition: Berechnen Sie, ob die eingegebenen Symptome die epidemiologische Falldefinition erfüllen, und zeigen Sie das Ergebnis dem Datenerfassungsbeauftragten an.
Erzwingung obligatorischer Felder: Machen Sie das Datum der Probenentnahme obligatorisch, wenn der Probentyp eingegeben wird. Machen Sie das Datum des Laborergebnisses obligatorisch, wenn das Ergebnis eingegeben wird.
Doppelte Warnung: Aktivieren Sie die integrierte Duplikaterkennung von DHIS2 für übereinstimmende Namen, Geburtsdaten und Einrichtungen.

Schritt 5: Dashboards, die für die Entscheidungsfindung konzipiert sind

Eine DHIS2-Implementierung ohne funktionales Dashboard ist ein Data Warehouse. Für die Ausbruchsüberwachung sollte das Kerndashboard in Echtzeit anzeigen:

Aktive Fallzahlen nach Distrikt: Eine thematische Karte mit Fällen, farbcodiert nach Dichte
Fallstatus-Pipeline: Wie viele Fälle sich in jeder Untersuchungsphase befinden
Zeit bis zur Untersuchung: Durchschnittliche Tage zwischen Fallregistrierung und Abschluss der Untersuchung, nach LGA
Epi-Kurve: Fälle nach Beginn Datum, Anzeige der Epidemietrajektorie
Warnindikator: Distrikte, die den Schwellenwert für einen vermuteten Ausbruch erreichen

Entwerfen Sie Dashboards für die Person, die am Montagmorgen um 7 Uhr eine Entscheidung treffen muss, nicht für die Person, die das System erstellt hat. Den vollständigen Rahmen für das Dashboard-Design finden Sie unter DHIS2 Dashboard Best Practices.

Schritt 6: Zugriffskontrolle und Zuordnung von Organisationseinheiten

Tracker-Daten sind individuell identifizierbar. Der Zugriff muss nach Organisationseinheit und Benutzerrolle eingeschränkt werden. Die empfohlene Struktur:

Benutzer auf Einrichtungsebene: Können Fälle registrieren und Daten der Phase 1 nur für ihre eigene Einrichtung eingeben
LGA-Überwachungsbeauftragte: Können alle Fälle in ihrer LGA anzeigen und Daten der Phase 2 eingeben
Staatliche Epidemiologen: Können alle Fälle im gesamten Bundesstaat anzeigen und auf Epi-Kurven-Dashboards zugreifen
Nationale Programmbeauftragte: Können aggregierte Daten anzeigen, aber keine individuellen Falldatensätze unterhalb der Landesebene abrufen.

Schritt 7: Praktische Überlegungen zur Bereitstellung

Geringe Bandbreite: Konfigurieren und testen Sie den PWA-Modus von DHIS2 Tracker für die Offline-Datenerfassung vor der Bereitstellung, nicht erst nach dem ersten Ausbruch.

Schulung: Gestalten Sie Schulungen rund um den minimal brauchbaren Workflow – Registrierung bis Abschluss – und bauen Sie darauf auf Kompetenzen auf, bevor Sie Komplexität einführen.

Feedbackschleifen zur Datenqualität: Bauen Sie eine monatliche Überprüfung der Datenqualität in den Programmkalender ein, die Vollständigkeit, Aktualität und Genauigkeit abdeckt. Ohne eine Feedbackschleife verschlechtert sich die Datenqualität unbemerkt.

Integration mit nationalen Systemen: Stellen Sie sicher, dass Ihre staatlichen Programmdatenelemente mit der Hierarchie der nationalen DHIS2-Instanz übereinstimmen. Eine Fehlausrichtung unterbricht den nationalen Datenfluss.

Die Architektur ist die Intervention

Die 40%ige Verbesserung der Polio-Überwachungssensitivität in den WHO-Programmen in Nigeria resultierte nicht aus besseren Datenerfassungsformularen. Sie entstand durch die Neugestaltung der Architektur – des Datenflusses, der Auslöser für Maßnahmen, der Dashboards, die die richtigen Informationen für die richtige Person im richtigen Moment sichtbar machten. Das ist es, was DHIS2 Tracker, gut konfiguriert, ermöglicht.

Weiterlesen

Häufig gestellte Fragen

Wofür wird DHIS2 Tracker verwendet?

DHIS2 Tracker wird für die fallbezogene Nachverfolgung, Kontaktverfolgung und longitudinale Verfolgung in Gesundheitsprogrammen eingesetzt. Im Gegensatz zur DHIS2-Aggregatberichterstattung, die periodische Zusammenfassungen nach Einrichtung erfasst, zeichnet Tracker Daten für jeden einzelnen Patienten über mehrere klinische Kontakte hinweg auf. Es wird für die Ausbruchsüberwachung, Impfnachverfolgung, HIV-Fallmanagement und jedes Programm verwendet, bei dem individuelle Daten klinische oder öffentliche Gesundheitsentscheidungen beeinflussen.

Was ist der Unterschied zwischen DHIS2 Aggregat und Tracker?

DHIS2 Aggregat sammelt zusammenfassende Daten: wie viele Fälle in einer Einrichtung in einer bestimmten Woche gemeldet wurden. DHIS2 Tracker sammelt individuelle Falldaten: den spezifischen Patienten, seinen Untersuchungszeitplan, Laborergebnisse, Kontakte und das Ergebnis. Aggregat ist einfacher zu konfigurieren und ausreichend für die routinemäßige Überwachungsberichterstattung. Tracker ist geeignet, wenn Sie einen Fall über mehrere Begegnungen hinweg verfolgen, Fälle mit Kontakten verknüpfen oder Ergebnisse nach individuellen Attributen aufschlüsseln müssen.

Wie konfiguriert man Programmphasen in DHIS2 Tracker?

Programmphasen stellen Schritte im Lebenszyklus eines Falls dar. Für die Ausbruchsüberwachung wird eine Standardkonfiguration mit vier Phasen verwendet: Fallregistrierung und Erstbenachrichtigung, Falluntersuchung, Laborergebnisse und Fallabschluss. Jede Phase enthält die minimalen Datenelemente, die für diesen Schritt erforderlich sind, Programmregeln, die die Datenqualität bei der Eingabe durchsetzen, und Zugriffskontrollen, die einschränken, wer Daten in jeder Phase eingeben oder anzeigen kann.

Was sind DHIS2-Programmregeln?

DHIS2-Programmregeln wenden Logik am Punkt der Dateneingabe an. Sie können Felder basierend auf zuvor eingegebenen Werten anzeigen oder ausblenden, Ergebnisse automatisch berechnen, obligatorische Felder bedingt durchsetzen, Warnungen anzeigen, wenn Eingaben inkonsistent erscheinen, und Alarme auslösen, wenn Falldefinitionen erfüllt sind. Für die Ausbruchsüberwachung erzwingen Programmregeln die Datumslogik, validieren Falldefinitionen und verhindern Datenqualitätsprobleme, die sich ansammeln, wenn Daten unter operativer Belastung gesammelt werden.

DHIS2 Tracker-Konfiguration für die Ausbruchsüberwachung