Integrated Disease Surveillance aggregate system design¶

Úvod¶

Tento dokument popisuje návrh systému pro balíček digitálních dat souhrnného sledování nemocí. To zahrnuje následující:

1. Nemoc zahrnutá v balíčku
2. Datové Sady
3. Mechanismy výměny dat
4. Ovládací panely
5. Pravidla ověření
6. Oznámení o ověření
7. Prediktory

Metadata souhrnného sledovacího balíčku jsou poskytována v několika různých konfiguracích, aby země ukázaly možnosti konfigurace v jejich vlastním kontextu. To také umožňuje zemím vybrat si možnosti konfigurace, které nejvíce odpovídají jejich kontextu.

Zahrnuté nemoci¶

Nemoci zahrnuté v tomto balíčku jsou následující:

Akutní ochablá ochrnutí	Akutní vodnatý průjem	Cholera	Horečka dengue
Průjem s krví (Shigella)	Záškrt	Spalničky	Meningitida
Novorozenecký tetanus	Ne-novorozenecký tetanus	Černý kašel	Vzteklina
Zarděnky	Virová hemoragická horečka	Žlutá zimnice

Všimněte si, že podle potřeby můžete do návrhu přidat nemoc.

Přehled datové sady¶

Konfigurační balíček dohledu pro souhrnné hlášení obsahuje 4 datové sady popsané níže.

Název	Periodicita	Účel
IDS – Zpráva: Podezření, Potvrzeno, Smrt	Týdně	Hlášení sledovacích činností: podezřelé případy, potvrzené případy a úmrtí. Podezřelé případy a úmrtí jsou rozčleněny, údaje o potvrzených případech nejsou rozčleněny.
IDS – Hlášení: Podezření, smrt	Týdně	Hlášení sledovacích činností: podezřelé případy a úmrtí. Tato data jsou rozčleněna.
IDS - Aggregate Lab Weekly Report	Týdně	Hlášení potvrzených případů přímo z laboratoří. Tato data nejsou členěna.
Populace týdně	Týdně	Týdenní údaje o populaci používané pro výstrahy. Je to týdenní, protože funkce prediktoru DHIS2 se používá ke generování prahových hodnot a v současné době nelze kombinovat data různé periodicity (v tomto případě týdenní data sledování s ročními údaji o populaci).

IDS - Report: Suspected, Confirmed, Death¶

Datový soubor IDS – Zpráva: Podezření, Potvrzeno, Smrt obsahuje informace o podezřelých případech, potvrzených případech a úmrtích na nemoci uvedené v části [pokryté nemoci] (#pokryté nemoci). Řada nemocí má rozdělené podezřelé případy a úmrtí a formulář a používá design vlastního formuláře. Návrh vlastního formuláře je výsledkem kombinace nerozdělených a nerozdělených datových prvků, které patří ke stejnému onemocnění a je nutné je seskupit.

Rozčlenění byly použity pomocí modelu kategorie v DHIS2. Tento model má při používání členění dvě klíčové výhody:

• Snižuje počet jedinečných datových prvků, které je třeba provést.
• V analýze to umožňuje rychlé přidání rozdělení podle věku, které lze podle potřeby řadit. Můžeme také vidět, že součty jsou docela užitečné k určení celkového počtu vztahujícího se k určité proměnné nebo období.

Pokud potřebujete upravit tuto datovou sadu tak, aby nebyla rozčleněna podle věku, můžete tak učinit přímo před nebo po instalaci. Doporučuje se to provést před instalací podle kroků v instalační příručce o úpravě balíčku.

Tato datová sada předpokládá vyspělou konfiguraci, ve které se shromažďují všechny podezřelé případy, potvrzené případy a úmrtí. Rovněž předpokládá, že každý, kdo pracuje s touto datovou sadou, by měl mít přístup k úpravě těchto informací (tj. zadávat data a upravovat existující datové hodnoty). To nemusí platit ve všech implementacích, pokud byste například chtěli oddělit, kdo může upravovat data o podezřelých a potvrzených případech.

In summary, if it is the case where you are not yet collecting data on confirmed cases or you want seperate groups to have the ability to edit suspected and confirmed case data, then this may not be the dataset to implement in your context. If you are collecting data on confirmed cases, and you want equal access for all users to edit the suspected and confirmed case data, then this type of dataset design would be suitable to implement in your own context.

IDS - Report: Suspected, Death¶

The IDS - Report: Suspected, Death dataset contains information on suspected cases and deaths on the diseases outlined in the section diseases covered. Note that it does not contain information on confirmed cases. This was done in the event that lab confirmation was a separate process, or that seperate access needs to be provided for those entering confirmed case data. This dataset therefore links to the IDS - Aggregate Lab Weekly Report in the event that cases are confirmed using a separate process. This form uses the same data elements and structure contained in the IDS - Aggregate Weekly Report dataset for cases and deaths. The custom form design from this dataset was therefore re-used such that a uniform design would be applied between this dataset and the IDS - Aggregate Lab Weekly Report dataset.

Tato datová sada je určena pro nastavení, kde buď

1. Údaje o potvrzených případech se zatím prostřednictvím DHIS2 neshromažďují
2. Údaje o potvrzených případech se shromažďují, ale jedná se buď o samostatný proces, nebo je třeba oddělit přístup k úpravě těchto údajů

IDS - Aggregate Lab Weekly Report¶

Zpráva IDS Aggregate Lab Weekly report obsahuje informace o potvrzených případech onemocnění uvedených v Tabulce 1. Upozorňujeme, že neobsahuje informace o podezřelých případech a úmrtích. Tato zpráva je určena k doplnění datové sady IDS – Zpráva: Podezření, Potvrzeno, Smrt, pokud je proces hlášení laboratorních potvrzených případů oddělen od hlášení podezřelých případů a úmrtí. To zahrnuje scénáře, ve kterých chcete, aby různí uživatelé měli možnost upravovat data potvrzených případů ve srovnání s údaji o podezřelých případech/úmrtích.

Stejně jako datové sady IDS – Zpráva: Podezření, Potvrzeno, Smrt a IDS – Zpráva: Podezření, Smrt tato datová sada používá vlastní návrh formuláře, aby zůstala konzistentní ve svém vzhledu.

Population Weekly¶

The Population weekly dataset is used to collect weekly population data. The main function of this is for thresholds for meningitis. It is a weekly data set as the DHIS2 predictor function is used to generate thresholds and currently can not combine data of different periodicity (in this case, weekly surveillance data with annual population data). The data element that it contains, population weekly, uses the aggregation type of "last value" and is meant to be equal to the estimated population total for a year within a given geographical region.

As an example application of this, if your yearly population within District A is 1000, then the weekly population within District A would also be 1000. By using the "last value" aggregation type, these weekly values will not sum and will consistently be equal to 1000 throughout the year within this district.

Mechanismy výměny dat¶

Kromě přímého použití rozhraní DHIS2 API jsou k dispozici dva mechanismy výměny dat:

1. Pro země, které používají DHIS2, byla vytvořena aplikace pro výměnu dat k odesílání dat přímo z jejich systému DHIS2 do jiných systémů DHIS2
2. Pro země, které nepoužívají DHIS2, byla vytvořena aplikace pro přijímání dat ve formátu Excel

Výměna dat z DHIS2 do DHIS2¶

Jako součást tohoto balíčku byla vyvinuta aplikace s názvem dhis2 transfer, která umožňuje přenášet data z jednoho systému DHIS2 do druhého. Jakmile je tato aplikace nakonfigurována, umožňuje jednomu systému DHIS2 odesílat svá data do jiného systému DHIS2 (například regionální systém shromažďující data z několika zemí). Počáteční konfiguraci je třeba provést pouze jednou a lze ji provést kompletně prostřednictvím dostupného uživatelského rozhraní. Konfigurace musí proběhnout pro dva samostatné prvky:

1. Skutečná odesílaná data (tj. Proměnné / datové položky)
2. Umístění odesílaných dat (tj. v organizačních jednotkách DHIS2)

Tato shoda je nezbytná, protože dva systémy, které si vyměňují data, nemusí být přesně zarovnány, pokud jde o názvy, kódy nebo ID, které používá k identifikaci těchto různých objektů, které jsou synchronizovány mezi těmito dvěma systémy. Aplikace aktuálně odesílá agregovaná data prostřednictvím agregovaných indikátorů ze zdrojového systému do datových prvků v rámci cílového systému, takže relevantní indikátory budou muset být dostupné ze zdrojového systému (tj. ze systému, který data odesílá).

Příklad odpovídajících proměnných je uveden níže:

Jakmile je tato konfigurace uložena, můžete ji podle potřeby volat, vybrat období, za které chcete data odeslat, a data odeslat.

NOTE

This process can also be scheduled if you want to send the data automatically

Další informace o aplikaci pro přenos dat naleznete v příručce k aplikaci.

Výměna dat mezi Excel a DHIS2¶

As part of this package an app called "data import wizard" has been made available in order for a DHIS2 system to receive Excel data. This tool also needs to be configured once with the mapping matching the information in the Excel sheet to the information available in DHIS2. Note that this app can be used beyond surveillance use cases as well.

Můžete si prohlédnout náhled dat přenášených do systému a ověřit správnost mapování ze souboru Excel, jak je uvedeno níže.

Jakmile jsou data zkontrolována a ověřena z listu aplikace Excel, mohou být importována přímo do systému DHIS2.

Další informace o aplikaci Průvodce importem dat naleznete v příručce k aplikaci.

Ovládací panely¶

K dispozici jsou ovládací panely pro každou z nemocí uvedených v části pokryté nemoci. Ovládací panel každého onemocnění má stejné rozložení:

1. Kontingenční tabulka zobrazující oblasti podezřelé z ohniska za posledních 12 týdnů
2. Mapa zobrazující oblasti podezřelé z ohniska za poslední týden
3. Kontingenční tabulka zobrazující oblasti podezřelé z ohniska za posledních 12 týdnů
4. Mapa znázorňující potvrzené oblasti ohniska za poslední týden

   

5. Kontingenční tabulka znázorňující celkový počet týdnů, v nichž byla oblast v posledním roce podezřelá z ohniska
6. Mapa zobrazující oblasti podezřelé z ohniska v posledním roce
7. Kontingenční tabulka ukazující celkový počet týdnů, v nichž se oblasti v posledním roce vyskytly v potvrzeném ohnisku
8. Mapa znázorňující potvrzené oblasti ohniska v posledním roce

   

9. Mapa zobrazující míru výskytu za poslední týden
10. Mapa zobrazující rozložení případů za poslední týden
11. Graf zobrazující počet podezřelých případů a úmrtí za posledních 12 týdnů
12. Kontingenční tabulka zobrazující počet podezřelých případů a úmrtí za posledních 12 týdnů

    

13. Graf znázorňující srovnání případů podle týdnů letošního a loňského roku

    

Pravidla ověření¶

Byla implementována validační pravidla, včetně jak logických kontrol konzistence, tak i detekce podezřelých a potvrzených ohnisek na základě různých kritérií.

Validation Rules - Consistency Checks¶

Validační pravidla, která provádějí kontroly konzistence, porovnávají týdenní potvrzené případy s týdenními podezřelými případy. Předpokladem je, že potvrzené případy by měly být menší nebo rovné suspektním případům v daném týdnu u všech nemocí uvedených v části pokryté nemoci. Úplný seznam těchto pravidel ověřování naleznete v referenčním souboru metadat. Pokud tento předpoklad není ve vaší implementaci správný, budete je chtít upravit, protože se objeví během zadávání dat, kdykoli uživatel dokončí sadu dat a je zjištěno porušení, jak vidíme v příkladu níže.

Validation Rules - Thresholds¶

Pravidla ověření se také používají k určení, zda byl překročen práh. Tato ověřovací pravidla někdy používají výstup prediktoru k porovnání v závislosti na kritériích, která je třeba splnit. Při porušení těchto pravidel je zasláno upozornění.

Spouštějí se následující pravidla ověřování a odesílají oznámení na základě kritérií uvedených níže:

Název	Aktivace popisu / oznámení	Použitý prediktor
Podezření na ne-neonatální tetanus	1 podezřelý případ	Ne
Pravděpodobná žlutá zimnice	1 případ s IgM pozitivní	Ne
Potvrzené zarděnky	1 potvrzený případ	Ne
Cholera RDT pozitivní	1 případ RDT pozitivní	Ne
Podezření na mor	1 podezřelý případ	Ne
Potvrzená vzteklina	1 potvrzený případ	Ne
Podezření na spalničky / zarděnky	5 podezřelých případů v jednom okrese za 30 dní	Yes IDS - Measles Suspected Outbreak
Potvrzen Anthrax	1 potvrzený případ	Ne
Potvrzená horečka dengue	1 potvrzený případ	Ne
Podezření na černý kašel	1 podezřelý případ	Ne
Potvrzené vypuknutí spalniček	3 potvrzené případy v jednom okrese za 30 dní	Yes IDS - Measles Confirmed Outbreak
Dva nebo více akutních vodnatých průjmů (AWD) ve věku 2 let a starších (spojeno časem a místem) s těžkou dehydratací nebo umíráním	2 nebo více AWD ve věku od 2 let (spojené časem a místem) s těžkou dehydratací nebo umíráním	Ne
Podezření na neonatální tetanus	1 podezřelý případ	Ne
Varování proti meningitidě	3 podezřelé případy / 100 000 obyvatel / týden (minimálně 2 případy za jeden týden) pro okresní / okresní populaci nad 30000	Yes IDS - Meningitis alert
Podezření na virovou hemoragickou horečku	1 podezřelý případ	Ne
Akutní smrtelný vodnatý průjem	Jedno úmrtí na těžký akutní vodnatý průjem u osoby ve věku nejméně 5 let	Ne
Vypuknutí meningitidy	10 podezřelých případů / 100 000 obyvatel / týden pro okresní / místní populaci nad 30000 NEBO 5 podezřelých případů za jeden týden NEBO zdvojnásobení počtu případů za období tří týdnů (výstraha epidemie) pro okresní / místní populaci pod 30000	Yes IDS - Meningitis outbreak
Jedno úmrtí na těžký akutní vodnatý průjem u osoby v jakémkoli věku	1 úmrtí na akutní vodnatý průjem u osoby v jakémkoli věku	Ne
Potvrzený AFP (VDPV)	1 potvrzený případ	Ne
Podezření na záškrt	1 podezřelý případ	Ne
Potvrzený AFP (WPV)	1 potvrzený případ	Ne
Podezření na průjem s krví (úplavice)	1 podezřelý případ	Ne

Note the differentiation between suspected cases and confirmed cases. In the context of this surveillance package, suspected cases identify if an area is in alert while confirmed case identify if an area is in outbreak.

These rules can be set to run automatically or can also be run manually. Configuration of the automated process is discussed within the installation guide.

Validation Notifications¶

In response to a threshold being surpassed, notifications can be sent out using any combination of 3 methods:

• The internal messaging service within DHIS2
• SMS
• E-mail

For more information on setting these services up, refer to the documentation on email and SMS.

Níže je uveden příklad e-mailu, který je odeslán, když je zjištěno ohnisko spalniček.

For a full list of validation notifications, consult the metadata reference file. Validation notifications are available for each disease based on the criteria defined in the validation rules thresholds section.

These can be sent out in response to either a manual or automated process of checking your data. Configuration of the automated process is discussed within the installation guide.

Predictors¶

For more information on configuring predictors, please consult the documentation.

Areas in outbreak¶

Outside of predictors being used within validation rules, they are also used to visualize areas that are in outbreak. We can see examples of this in visualizations 1-8 within the dashboards section. While validation rules can be used to trigger validation notifications, the result of these rules is not stored in a data element and thus can not be used for visualization purposes. A full list of predictors can be found in the metadata reference file. Each disease has predictors that are labelled as either an "alert" -- used in situations where suspected cases are being checked; or an "outbreak" -- used in situations where confirmed cases are being checked.

Predictors are defined to store values within companion data elements that can then be used to create visualizations to identify areas in alert or outbreak. The predictors are defined to identify alerts and outbreaks based on the validation rules thresholds section. Let us take two predictors and break them down into its component parts, as each predictor for each disease will need to be understood to be correctly used or altered if needed.

Example 1: A disease where 1 suspected case is the threshold (ie. diptheria)¶

Let us take an example in which 1 suspected case is the threshold to identify if an area is in alert. Note that this same nomenclature would apply to an example in which 1 confirmed case is the threshold to identify if an area is in outbreak.

We can use the example for diptheria; if we review the validation rules thresholds section we will see one suspected case of diptheria is our threshold.

Within the predictor, we have the following fields:

1. Název prediktoru
2. Popis prediktoru
3. The output data element - this is where the result of the predictor is stored
4. Období, ve kterém je prediktor spuštěn
5. The output organisation unit level of the predictor value

After this is defined we have what is referred to as the generator. The generator is essentially the formula used to define the predictor. In this case, using diptheria as our example, we have a logical test stating the following

If the number of suspected diptheria cases is >= 1 within a given org unit, return a value of 1. If this is not the case return a value of 0.

These types of logical if statements are used in all of the predictors within this package. If you are not familiar with boolean logic, a broad overview can be found here.

The last components of the predictor identify which period we will be getting data from to use within our generator. We have defined both the sequential sample count and annual sample count as 0. This means that the generator will only be obtaining data from the same week in which the threshold is being checked.

Example 2: A disease where a specific threshold formula is used (ie. measles)¶

In example 2, we can review the threshold for a confirmed measles outbreak. This threshold is defined as 3 confirmed cases in one district in 30 days. There are some key components that must be considered

1. Celkem 3 případy v rámci okresu
2. Tyto případy mohou nastat po dobu 30 dnů

Pro spuštění našeho prediktoru máme stále stejná pole jako v příkladu 1

1. Název prediktoru
2. Popis prediktoru
3. The output data element - this is where the result of the predictor is stored
4. Období, ve kterém je prediktor spuštěn
5. The output organisation unit level of the predictor value

After this is defined we have what is referred to as the generator. The generator is essentially the formula used to define the predictor. In this case, using measles as our example, we have a logical test stating the following

If the sum of confirmed measles cases is greater then 3, return a value of 1. If this is not the case return a value of 0.

Note that this sum is being taken from the level in which there is data, which in this example would be our facilities. Using the generator alone, we have also not met our second criteria which should examine this over a 30 day period.

The last components of the predictor identifies which period we will be getting data from to use within our generator. We have defined the sequential sample count as 4 and the annual sample count as 0. This means that the generator will be obtaining data from the last 4 weeks (since the predictor period is set to weekly), including the current week, for the current year in which the threshold is being checked. This is to meet the criteria of our 30 day period as defined in our threshold.

Predictor Summary¶

NB: We use predictors to help us test our thresholds and store data values to identify areas in alert or outbreak. Areas in alert are based off thresholds using suspected cases, while areas in outbreak refer to thresholds using confirmed cases. To define these thresholds using a predictor we must consider

1. Datový prvek, do kterého odešlete hodnotu prediktoru
2. Období, ve kterém bude prediktor porovnávat data
3. The organisation unit level you will output the predictor value to
4. The generator formula, which will test our data against a defined threshold
5. The sequential and annual sample counts, which will define which periods the predictor is obtaining data from

Altering these components will allow you to alter the definition of the threshold.

These predictors can be set to run automatically or can also be run manually. Configuration of the automated process is discussed within the installation guide.