Campaign Monitoring – Analyst Handover Guide#

Overview#

This document provides a full technical and operational handover to manage and interpret ODK data used in polio vaccination campaigns. It covers the five key forms:

Cold Chain Management (CDF)
Vaccine Stock Monitoring (Stock Type 2)
Form A (Administrative Reporting)
LQAS (Cluster-based Coverage Validation)
Independent Monitoring (IM)

Responsibilities Across the Campaign Lifecycle#

Phase	Responsibilities
Before	Run pre-checks on ODK configurations (Day -15 to Day -1), align pyramids, send alerts
During	Monitor submissions, match campaign & facility IDs for each odk form with poliooutbreaks IDs, generate Power BI dashboards
After	Process late submissions, apply hotfixes on incorrect submissions

These tests are automated and are run in OpenHexa(an ETL platform that allows to schedule the execution of codes or notebooks), as well as store files and expose a database that can be accessed by BI tools like powerBI to feed dashboards with data. Openhexa is the platform that treats data that is shown in the different dashboards: AFRO RRT hub.

In order to access all these codes one must create an OpenHexa account and ask Bluesquare to be added to the Polio workspace.

Campaign Timeline#

Key Milestones:#

Day -15: CDF : Start internal checks for pyramid alignment (odk forms and poliooutbreak georegistry) and odk config.
Day -10: Stock Type II : Start internal checks for pyramid alignment (odk forms and poliooutbreak georegistry) and odk config.
Day -8 to Day -1:
Automatic alerts sent to UNICEF colleagues in charge of regions on odk forms configuration issues.
Mails to WHO AFRO on health pyramid issues (new districts, etc.).
Day -1:
Limit the scope of the campaign (validate only health facilities defined as choice in the odk form: stock type II)
FormA : Start internal checks for pyramid alignment (odk forms and poliooutbreak georegistry) and odk config.
Day 0 onwards: Monitor live submission dashboards and alert on issues (wrong odk form version reveived, etc.)
Months later: Monitor LQAS/ IM submissions received.

Form-by-Form Handover#

WHO AFRO – ODK Form Checks & Processing Guide#

This guide outlines the main actions and processes for validating and processing ODK submissions across the four key forms used in WHO AFRO polio campaign monitoring.

Overview Table#

Form	Config Check	Column Name and value Validation	Pyramid Match	Submission Processing	Common Issues
CDF	Yes (Day -15)	`odk_format_check`	Yes (`match_pyramid_from_form`)	cold chain management/`get_cold_chain_forms.ipynb`	Column name for facility (aliases: wards, etc.)
Stock 2	Yes (Day -10)	`odk_format_check`	Yes (`match_pyramid_from_form`)	TASK1# - stock type 2 - data extraction	Incorrect `response_ID`, `roundNumber`
Form A	Yes (from Day -1)	`odk_format_check`	Yes (`match_pyramid_from_form`)	TASK2# - formA - data extraction	Missing `Admin_LvL_Rpt`, wrong equation definition in column "relevant"
LQAS	No (manual post-campaign)	Manual	Yes (post-hoc)	TASK4# - LQAS - data extraction	Districts not in scope, wrong `response_ID` or `roundNumber`
IM	No (manual post-campaign)	Manual	Yes (post-hoc)	TASK5# - im - data extraction	Districts not in scope, wrong `response_ID` or `roundNumber`
---

1. Cold Chain Management (CDF)#

Link:#

Vaccine management - Cold chain management

Purpose#

Track cold chain infrastructure and temperature compliance.

Actions#

Ensure facility names match poliooutbreaks' geo-registry.
Identify correctly columns representing: Region, District, Facility (save aliases per country. eg.: Kenya's facilities are wards)
Compute reporting rate based on the scope definition (list of facilities expected to submit)
compare_pyramid_length_across_forms.ipynb : compare the number of health facilities defined in the odk form for CDF, stock type ii and form A to verify the consistency of the pyramid/scope definition.

2. Stock Type 2 – Vaccine Monitoring#

Link:#

Vaccine management - stock monitoring

Purpose#

Monitor stock levels, vial usage and children vaccinated daily during the campaign.

Pre-Campaign#

Validate:
Pipeline : odk_format_check_pipeline for stock ii:
- response_ID, roundNumber are matching poliooutbreaks values.
- Required columns ( Country, Region, District, facility,Campaign_Day) exists (or an alias for it that is known)
Pyramid matching:
- Pipeline : match_pyramid_from_form for “stock type 2”. Provides the results in OpenHexa's Polio workspace.
- Unmatched districts with best match provided : Polio (stock2&formA) supervision/ONA Matching results/missing_DS/{form_name}_{country_id}.json
- Unmatched health facilities with best match provided : Polio (stock2&formA) supervision/ONA Matching results/missing_FOSA/{form_name}_{country_id}.json
- Script to add aliases or create new orgunits in poliooutbreaks.com based on the unmatched districts or health facilities mentionned above : Polio (stock2&formA) supervision/ONA Matching results/Update_iaso_pyramide.ipynb
check_pyramid_for_each_language.ipynb: verify that the definition of the health pyramid is the same for each language (French, English, Portuguese) in the sheet choices of the odk form. For instance, Ivory Coast has had several forms where they copied the pyramid and paste it only in the French column, which is unaligned then with the other language: it created a wrong pyramid and health facilities could not be found in the right district after district's selection when users were submitting the form.
check_relevant_conditions_odk_form: verify that the equations in the column named "relevant" is correctly defined (using the right variables defined in the odkforms as well as if they are compared to the right values defined the sheet choices. Sends a mail to Caleb or Gael that explains what to correct in the equation to make it valid.
compare_pyramid_length_across_forms.ipynb : compare the number of health facilities defined in the odk form for CDF, stock type ii and form A to verify the consistency of the pyramid/scope definition.

During Campaign#

TASK1# - stock type 2 - data extraction:
Match facility & campaign IDs
Clean data, apply hotfixes
Only unmatched rows processed, then added to the matched rows
Compute the risk of out of stock situation at center based on doses_used, vials in stock and number of days left for the round.
Drop duplicates (keep last in date) based on the reponse_ID, roundNumber, facility_id, Campaign_Day (one submission per facility, per day of campaign's round).
Send_mail_wrong_form_used.ipynb: Send a mail summarizing per district how many facilities did submit a form from an previous version (old and probably not fit for the current campaing)

3. Form A – Vaccine stocks through administrative levels - Tracking#

Link:#

Vaccine management - formA

Purpose#

Track reverse logistics, vial usage, doses administered and stock between administrative levels.

Actions#

Validate:
Pipeline : odk_format_check_pipeline for formA:
- response_ID, roundNumber are matching poliooutbreaks values.
- Required columns ( Country, Region, District, facility,Admin_LvL_Rpt) exists (or an alias for it that is known)
Pyramid matching:
- Pipeline : match_pyramid_from_form for “formA”. Provides the results in OpenHexa's Polio workspace, exactly as for stock type ii.
check_pyramid_for_each_language.ipynb
check_relevant_conditions_odk_form: verify that the equations in the column named "relevant" is correctly defined (using the right variables defined in the odkforms as well as if they are compared to the right values defined the sheet choices. Sends a mail to UNICEF colleague that explains what to correct in the equation to make it valid. Many errors happened in the past with this form: Admin_LvL_Rpt has choices defined for instance: "Regional", "District", "Sub-district". Then, in order to ask the right pyramid information (say the level is Regional, the form should not ask District, neither Sub-district during the submission), an equation is set in the column relevant. But it happened many times that the condition was not adequate with regards to the choices of Admin_LvL_Rpt. For instance, the condition set to ask for the region name was if Admin_LvL_Rpt == "Region" which is never true because the choices of Admin_LvL_Rpt do not contain "Region" but "Regional".
compare_pyramid_length_across_forms.ipynb : compare the number of health facilities defined in the odk form for CDF, stock type ii and form A to verify the consistency of the pyramid/scope definition.

During Campaign#

TASK2# - formA - data extraction:
Match facility & campaign IDs
Clean data, apply hotfixes
Only unmatched rows processed, then added to the matched rows
Drop duplicates (keep last in date) based on the reponse_ID, roundNumber, report_org_unit_id, Admin_LvL_Rpt (one submission per orgunit per administrative level per campaign's round).
Send_mail_wrong_form_used.ipynb: Send a mail summarizing per district how many facilities did submit a form from an previous version (old and probably not fit for the current campaing)

4. LQAS – Lot Quality Assurance Sampling and IM (HH - OHH)#

Purpose#

Post-campaign coverage validation via sampled clusters.

⚠️ Unlike other forms, LQAS, IM are not yet pre-supervised before the campaign starts.

Actions#

No automated check

After Campaign#

TASK4# - LQAS - data extraction TASK4# - LQAS - data extraction or TASK5# - im- data extraction:
Match district & campaign IDs
Clean data, apply hotfixes
IMpipeline (parameter: HH, OHH or HH & OHH):
Match district & campaign IDs
Clean data, apply hotfixes
Manual launch pipeline match_pyramid_from_form for LQAS or IM to see if all districts are known in poliooutbreaks
Manual aliasing or shapefile request if mismatch found between districts

Pyramid Matching Process#

Matching the geographic hierarchy between the ODK forms and the poliooutbreaks geo-registry is a multi-level, iterative process, and must be done in the following strict order:

Matching Hierarchy#

Regions
All Region names from the ODK form must first be matched to IASO regions.
If even one region is unmatched, district matching does not start.
Unmatched regions are found in OpenHexa's workspace: Polio (stock2&formA) supervision/ONA Matching results/missing_REGION/{form_type}{poliooutbreaks_country_id}.json An example of the json file is presented here (with the best matched region (_best match) for each unmatched region's name in the odk form, and the parent_id being the country_id (29720) representing Chad in poliooutbreaks for this example:

Districts
Once all regions are aligned, District values are matched under their respective regions.
Similarly, matching halts here if district alignment is incomplete.
Unmatched districts are found in OpenHexa's workspace: Polio (stock2&formA) supervision/ONA Matching results/missing_DS/{form_type}_{poliooutbreaks_country_id}.json
Health Facilities (FOSAs)
Only once both region and district matching are complete, facility-level matching begins.
Facilities are matched using fuzzy logic (cleaning accents, spacing, etc.).
Unmatched facilities are found in OpenHexa's workspace: Polio (stock2&formA) supervision/ONA Matching results/missing_FOSA/{form_type}{poliooutbreaks_country_id}.json An example is provided below. It shows that for facilities, there are a bit more information. First, the unmatched facilities are sorted by the matching score (from the highest to the lowest). Different matches are found: when taking into account the type of health facility (Poste de santé is not the same as Centre de santé for instance), or not, when taking into account the status of the health center in poliooutbreaks: is it validated or rejected (see the part on rejecting health facilities when they are not in the scope of the campaing). Ultimately, _best_match is the name with the highest score of all 4 matches found below. For Wageta, it is Wagela for instance.

Each level must be fully matched before descending to the next.

Adding aliases/ creating new orgunits#

If a best match is confirmed as a real match then an alias must be added. Otherwise, the unit is added as new in poliooutbreaks (note that regions/districts require WHO AFRO approval and shapefiles!). This is the subject of next section.

Updating IASO Pyramid – Add Aliases or Create New OrgUnits#

During pyramid alignment before each campaign, some geographic names from ODK forms (Region, District, Facility) may not match the IASO georegistry exactly. To correct this and ensure submissions are properly matched in dashboards, you must either:

Add an alias to an existing unit in IASO when the name is slightly different (e.g., “Wageta” vs “Wagela”).
Create a new orgunit (district or facility) if no suitable match exists in IASO.

When Do You Update the Pyramid?#

After running the match_pyramid_from_form pipeline (done automatically for Stock Type 2 and Form A but can be ran manually for all forms), unmatched names are listed:
📁 missing_REGION/{form_type}_{country_id}.json
📁 missing_DS/{form_type}_{country_id}.json
📁 missing_FOSA/{form_type}_{country_id}.json

These files provide: - name: value found in the odk form - best_match: closest matching name in IASO - score: fuzzy match similarity score - parent_id: required for hierarchy (country → region → district)

Step-by-Step: Add Aliases or Create New Units#

You’ll use the Update_iaso_pyramide.ipynb notebook for this process. It’s available in OpenHexa: Polio (stock2&formA) supervision/ONA Matching results/Update_iaso_pyramide.ipynb

Steps to Follow#

Run the Prelude Cells
Load the helper functions and required modules.
Select the Right JSON File
Choose a file from:
missing_DS/ if you’re dealing with districts
missing_FOSA/ for health facilities
Set the Country to Work On
Define the correct file paths with the right {form_type}_{country_id}. This configures the notebook to work on a single country’s unmatched pyramid entries.
Choose to Add District or FOSA
Scroll to the section titled Add missing districts or Add missing facilities.
Review Each Entry:

Strategy 1: Alias First N Facilities, Create the Rest#

If early matches are accurate (high fuzzy score) but later ones are ambiguous or invalid:

import json
from iaso_tools import iaso, add_alias, add_missing_ou

f = open(f"{missing_fosa_path}{suffixe}.json")
iaso.create_country_pyramid(suffixe[-5:])
missing_FOSA = json.load(f)

N = 55  # first 55 elements will be aliased
count = 0

for i, elem in enumerate(missing_FOSA["data"]):
    if i < N:
        closest_id = iaso.get_id_from_name(
            "FOSA", elem["best_match"], elem["parent_id"]
        )
        add_alias(iaso.IASO["FOSA"][closest_id], elem["name"], iaso)
    else:
        count += add_missing_ou(
            elem["name"], "FOSA", elem["parent_id"], iaso, action="NOpreview"
        )

print(count, "FOSA added!")

Strategy 2: Manual Control – Alias Some, Add the Rest#

You can use a predefined list of indexes for aliasing:

alias_indexes = [0, 1, 2, 4, 5, 6, 7, 10]  # update this as needed

count = 0
for i, elem in enumerate(missing_FOSA["data"]):
    if i in alias_indexes:
        closest_id = iaso.get_id_from_name("FOSA", elem["best_match"], elem["parent_id"])
        add_alias(iaso.IASO["FOSA"][closest_id], elem["name"], iaso)
    else:
        count += add_missing_ou(elem["name"], "FOSA", elem["parent_id"], iaso, action="NOpreview")

print(count, "FOSA created")

❗ Important Notes#

New districts or regions require validation by WHO AFRO, including geographic shapes (shapefiles). Do not add them without approval.
New health facilities (FOSAs) can be added easily since no shape is required.
The system applies some fuzzy logic to suggest matches (accents, abbreviations, etc.). Only high-confidence (>85%) aliases are added automatically by pipelines. Manual review is required for the rest.

Result#

After running the notebook: - Updates are applied to the IASO (poliooutbreaks) georegistry - Pyramid matching can be re-run for the same country to validate the new or aliased entries (and therefore is the pyramids are aligned now).

Limiting the scope (health facility list) for the round#

Purpose#

ODK form (choices tab) contains a list of Health Facilities that the country wants to include during the campaign.
But in IASO, scopes are defined at the region or district level, which might include more facilities than actually listed in the form.
This creates a mismatch: not all facilities in IASO scope are meant to be shown in dashboards during the campaign.
Reject facilities in the district in scope that are not found in the odk form choices of health facilities and create a file with the rejected facilities as well as those kept in the scope (for tracing back, logging purpose).

Files Generated#

File	Description
`scope_odk_{obr}.csv`	✅ Facilities both in the form’s choices tab and in IASO. These are validated and shown in the dashboard.
`rejected_{obr}.csv`	❌ Facilities in IASO scope but not present in the odk form. These are temporarily rejected and excluded from the dashboard view.

These files are auto-generated by the validate_only_odk_Facilities.ipynb notebook and serve a critical role in scoping the Power BI dashboards.

This ensures dashboards reflect only the facilities that actually submitted or were expected to submit data based on the form.

Email Alerts Workflow#

Summary Table – Jupyter Notebooks & Email Alerts#

Notebook Name	Timeline	Purpose	Problem Detected	Example Email Alert Summary
`Send_mail_statuts_odk.ipynb`	8 days up to campaign start	Check ODK form configuration	Bad `roundNumber` or `response_ID`	Alert on form misconfiguration with actual vs expected values
`round_starts_soon.ipynb`	10 days before campaign start	Pre-campaign readiness reminder	Missing pyramid alignment or config errors	Reminder that campaign starts in 10 days, with Power BI link
`first_submission.ipynb`	After campaign start up to 10 days	Monitor initial submissions	Wrong or unexpected `response_ID` used	Submissions received but don’t match expected ID
`Send_mail_wrong_form_used.ipynb`	After campaign start up to 10 days	Identify wrong config in actual data	Wrong `roundNumber` or `response_ID` in submissions	Notify team about live data using wrong config
`check_pyramid_for_each_language.ipynb`	8 days up to campaign start	Check consistency across languages in XLSForm	Discrepancy between language columns	% mismatch detected between labels and names
`check_relevant_conditions_odk_form.ipynb`	8 days up to campaign start	Validate `relevant` conditions in XLSForm	Syntax errors, invalid references	Point to invalid logic and suggest valid values
`compare_pyramid_length_across_forms.ipynb`	8 days up to campaign start	Compare pyramid coverage across forms	Mismatch between Form A and Stock2 pyramids	(No email provided – assumed internal visual report)

Email Examples by Notebook#

`Send_mail_statuts_odk.ipynb`#

Purpose: Check if the roundNumber and response_ID are correctly set in the form (e.g., VM tool type 2).

Problem Detected: Config mismatch between form values and SIA platform.

Email Example:

Hello,

We have noticed a configuration error in the form VM tool type 2 on ONA's server, for the campaign in ETHIOPIA, starting on the 2025-02-21 according to our SIA platform.

Please verify the default value for response_ID. The current value in the odk form is RND1 whereas the expected value in our platform is ETH-2024-11-nOPV2.

Please verify the default value for roundNumber. The current value in the odk form is ETH-2025-02-01_nOPV whereas the expected value in our platform is Rnd1.

Their level of national preparedness is equal to 86.6 %

Thanks,  
The poliooutbreaks-Bluesquare team

`round_starts_soon.ipynb`#

Purpose: Trigger a pre-campaign check reminder on Day -10.

Problem Detected: Not a technical error per se—just ensures action is taken.

Email Example:

Bonjour,

Petit rappel que la campagne NIE-Test-NID-06-2025 commence dans 10 jours.
Vérifier la configuration odk et l'alignement des pyramides sanitaires serait utile!

Résultat ici: https://app.powerbi.com/groups/e85bec77-b764-4b32-b24a-8cf279ab7929/reports/91e72ff2-e353-4c59-af08-8c76611e430e/ReportSection?language=fr-be&experience=power-bi&clientSideAuth=0.
Leur score de preparedness est de nan

`first_submission.ipynb`#

Purpose: Review actual incoming response_ID values after campaign starts.

Problem Detected: Unexpected or multiple response_IDs used.

Email Example:

Bonjour,

Nous recevons des soumissions pour la campagne de CÔTE D’IVOIRE qui commence le 2025-02-28 selon notre plateforme SIA.

Les responses_IDs recues depuis le début de la campagne sont CIV-2024-04-01_NOPV& CIV-2024-11-01_NOPV& CIV-2023-06-01_NOPV& CIV-2025-02-01_NOPV_NIDS& CIV-2023-09-01_NOPV. La response ID attendue est CIV-2025-02-01_NOPV_NIDS (insensible à la casse).

Bien à vous,  
L'équipe poliooutbreaks-Bluesquare

`Send_mail_wrong_form_used.ipynb`#

Purpose: Detect submissions that use the wrong version of the form.

Problem Detected: Submissions during campaign don’t match expected config.

Email Example (inferred):

Subject: ❌ Wrong Form Configuration Used in Nigeria Campaign

Dear Gael,

Several submissions received for NGA-29822 used:
- roundNumber = 2 (expected 1)
- response_ID = "NGA_polio_March_2024_test" (expected "NGA_polio_March_2024")

Please communicate with field teams to correct immediately.

Regards,  
Polio Alert System

`check_pyramid_for_each_language.ipynb`#

Purpose: Validate that multi-language pyramids are internally consistent.

Problem Detected: High mismatch rate between label::French and name.

Email Example:

Bonjour,

Nous avons détecté une erreur de configuration dans le formulaire form A sur le serveur ONA, pour la campagne de CÔTE D’IVOIRE qui commence le 2025-02-28 selon notre plateforme SIA.

De facon générale, les formations sanitaires pour les colonnes label::French doivent être mises à jour de facon cohérente avec la colonne 'name' dans l'onglet 'choices' du formulaire.
Nous avons repéré que 97.82% des valeurs de la colonne 'label::French' diffèrent des valeurs de la colonne 'name'.
Veuillez vérifier le formulaire et uniformiser les valeurs de choix pour les formations sanitaires dans toutes les langues avec les valeurs correctes pour toutes les colonnes.

Merci d'avance,  
L'équipe poliooutbreaks-Bluesquare

`check_relevant_conditions_odk_form.ipynb`#

Purpose: Validate skip logic (relevant column) for syntax or logic issues.

Problem Detected: Reference to invalid option in skip condition.

Email Example:

Hello,

We have noticed a configuration error in the form form A on ONA's server, for the campaign in KENYA, starting on the 2025-02-21 according to our SIA platform.

In the tab 'survey', at the row 15 associated to the name 'select_one Ward', the condition written under the column 'relevant' is not correct: ${Admin_LvL_Rpt} = 'Sub-District'. Indeed:
the variable Admin_LvL_Rpt is limited to the following choices (see the tab 'choices'): ['National' 'Regional' 'District' 'Facility']. Please replace the value 'Sub-District' with one of the valid choices.

Thanks,  
The poliooutbreaks-Bluesquare team

`compare_pyramid_length_across_forms.ipynb`#

Purpose: Compare pyramid (Region > District > Facility) structures between Form A and Stock Type 2.

Problem Detected: One form has a broader or narrower scope than the other.

Email Example:
(No automated email—used as a visual/manual dashboard or Power BI alert)

Applying Hot Fixes After Campaign Launch#

After a polio vaccination campaign has started, it's sometimes necessary to correct key values in already-submitted ODK data—especially if initial warnings sent before Day 0 (e.g., for incorrect response_ID or roundNumber) were not acted upon. These corrections are called hot fixes, and they are applied using the HOT_FIXES pipeline in OpenHexa.

Step-by-Step: How to Apply a Hot Fix#

Go to the OpenHexa HOT_FIXES pipeline
🔗 Open pipeline
Fill in the Required Parameters:

Parameter	Description	Example
`form_type`	Select the form to fix	`stock_ii` or `formA`
`country_id`	IASO country ID for the form	`29691` (for Côte d'Ivoire)
`start_date`	Start of the campaign fix window	`2023-12-01`
`end_date`	End of the campaign fix window	`2023-12-06`
`campaign_id`	Correct campaign ID as per SIA platform	`ghdsjkh54684sdfse`

Optional Corrections:

Parameter	Description	Example
`correct_round_number`	The correct round number	`2`
`initial_round_number`	The incorrect round number in submissions	`1`
`response_ID_in_odk`	Incorrect response ID to be replaced	`round2_2023`

Enable Direct Modification:
Set the flag to true if you want the changes applied directly to stock_ii_{country_id}.csv.

Where the Fixes Are Logged#

Corrected rows: workspace/stock_ii/rows_fixed_ghdsjkh54684sdfse_2023-12-01.csv
All hot fixes log: workspace/stock_ii/HOT_FIXES.csv

Sample HOT_FIXES.csv Template#

Below is a sample of how the hotfix file should be structured:

form_type	country_id	start_date	end_date	campaign_id	correct_round_number	initial_round_number	response_ID_in_odk
stock_ii	29691	2023-12-01	2023-12-06	ghdsjkh54684sdfse	2	RND 1	DRC_2023_10_NOPV2
formA	29691	2023-12-01	2023-12-06	ghdsjkh54684sdfse	2	RND 1	DRC_2023_10_NOPV2
stock_ii	12345	2024-01-10	2024-01-14	zerge84fe7e7ss8ss	3	RND2	NIG_2024_01_NOPV2
formA	12345	2024-01-10	2024-01-14	zerge84fe7e7ss8ss	3	Rnd 2	NIG_2024_01_NOPV2
stock_ii	67890	2024-02-01	2024-02-05	ezfho8897zez8e8ee	1	Rnd3	MLI_2024_02_NOPV2

Confirming That Fixes Worked#

Inspect the rows_fixed_...csv log file for modified records.
Re-run the stock/formA extraction pipeline.
Check Power BI dashboard updates.

How to Read the Polio Supervision Power BI Dashboard#

The Polio Supervision Dashboard provides a near-real-time overview of all polio vaccination campaigns starting from 15 days before to 15 days after the current date. It highlights the status and data quality of each country campaign, focusing on:

ODK configuration : round number, response_ID, presence and default values for important columns for each form
Pyramid alignment between ODK forms and IASO
Submission received for each form
Unmatched facilities or incorrect response_IDs per form and campaign

Purpose#

This dashboard helps WHO AFRO analysts, partners (e.g. UNICEF), and Bluesquare track critical pre-campaign issues and early-stage campaign performance at a glance, enabling quick intervention.

Key Sections of the Dashboard#

An screenshot of the main page of the dashboard is shown below. It shows that a campaign for Nigeria will start in 9 days with many green indicators.

Campaign Table (Top View)#

Each row represents a campaign. Columns indicate validation status on: - Round number & Response_ID consistency with the SIA platform - Pyramid alignment of Form A and Stock Type 2 (region/district/facility level) - Credential availability for downloading ODK forms - alerts: error of equation definition in the column 'relevant', error of pyramid alignment through languages, error of pyramid alignement through forms coverage, first submissions received.

🟥 Red cells indicate an issue that requires action (e.g., incorrect form ID, unmatched pyramid, or missing credentials). Always investigate red cells first.

Click on a red campaign row to filter other charts and tables—this allows you to isolate and investigate errors specific to that country/campaign.
Hover over table values or warning symbols to get explanations.
Use the date slider or filters to zoom into campaigns starting within the desired date window.

Data Refresh and Scope Logic#

The dashboard refreshes daily and reflects: - Submissions retrieved from the ONA server - Facilities matched via the latest IASO pyramid - submissions not shown in the dashboard:

How Issues Are Detected#

Issue Type	Example	Dashboard Indication
ODK config	Wrong response_ID or roundNumber	❗ "Problem config odk" warning
Pyramid mismatch	District name not aligned between form and IASO	🟥 Cell in "Pyramid aligned" column
No credentials	Form not downloadable	🟥 Cell in "Credential" column
Submission incorrectly treated	Health facility submitted but not in form	Listed in "Stock_ii : Post début de campagne"

The image below shows the incorrect submission(s) with an indication as why it was not correctly treated (missing facility_ID -> could not match the facility with IASO's health pyramid; missing obr name (outbreak name) -> if the submission is before the starting date of the campaign it is normal that is not treated because tests data are not shown in the dashboard. So it is not associated with a campaign_id or obr name. It can also be that the odk form was not well configured so the round number does not correspond to the round number expected in poliooutbreaks and therefore the submission is flagged as an error). On this example, the only incorrect submission for Nigeria is incorrect because the submission date is before the start date of the campaign (starting in 9 days). Therefore the obr name is not associated.

Note that these errors can also found per country in the OH workspace as well in stock_ii/stock_ii_errors_{country_id}.csv or formA/vaccine_forma_errors_{country_id}.csv

Notes for Analysts#

Form A issues may only appear after Day 0, since that form starts collecting data only during campaign days.
Scope validation is done using only the ODK choices tab and the IASO pyramid—if a facility is missing or misnamed, it will not appear unless corrected or aliased.
The pyramid matching algorithm applies a fuzzy match logic, but human verification may still be required for low-score matches (especially new districts or abbreviations).

Links#

Dashboard Link: Polio Supervision Dashboard (Power BI)
Form status & pyramid overview: status_matrice.csv in the workspace
Scope files available at day 0:
✅ Polio (stock2&formA) supervision/Define scope for facilities/scope_odk_{obr}.csv
❌ Polio (stock2&formA) supervision/Define scope for facilities/rejected_{obr}.csv
Form download or fix scripts: See workspace/stock_ii/ or workspace/formA/

Campaign Monitoring – Analyst Handover Guide#

Overview#

Responsibilities Across the Campaign Lifecycle#

Campaign Timeline#

Key Milestones:#

Form-by-Form Handover#

WHO AFRO – ODK Form Checks & Processing Guide#

Overview Table#

1. Cold Chain Management (CDF)#

Link:#

Purpose#

Actions#

2. Stock Type 2 – Vaccine Monitoring#

Link:#

Purpose#

Pre-Campaign#

During Campaign#

3. Form A – Vaccine stocks through administrative levels - Tracking#

Link:#

Purpose#

Actions#

During Campaign#

4. LQAS – Lot Quality Assurance Sampling and IM (HH - OHH)#

Purpose#

Actions#

After Campaign#

Pyramid Matching Process#

Matching Hierarchy#

Adding aliases/ creating new orgunits#

Updating IASO Pyramid – Add Aliases or Create New OrgUnits#

When Do You Update the Pyramid?#

Step-by-Step: Add Aliases or Create New Units#

Steps to Follow#

Strategy 1: Alias First N Facilities, Create the Rest#

Strategy 2: Manual Control – Alias Some, Add the Rest#

❗ Important Notes#

Result#

Limiting the scope (health facility list) for the round#

Purpose#

Files Generated#

Email Alerts Workflow#

Summary Table – Jupyter Notebooks & Email Alerts#

Email Examples by Notebook#

Send_mail_statuts_odk.ipynb#

round_starts_soon.ipynb#

first_submission.ipynb#

Send_mail_wrong_form_used.ipynb#

check_pyramid_for_each_language.ipynb#

check_relevant_conditions_odk_form.ipynb#

compare_pyramid_length_across_forms.ipynb#

Applying Hot Fixes After Campaign Launch#

Step-by-Step: How to Apply a Hot Fix#

Where the Fixes Are Logged#

Sample HOT_FIXES.csv Template#

Confirming That Fixes Worked#

How to Read the Polio Supervision Power BI Dashboard#

Purpose#

Key Sections of the Dashboard#

Campaign Table (Top View)#

Navigation Tips#

Data Refresh and Scope Logic#

How Issues Are Detected#

Notes for Analysts#

Links#

`Send_mail_statuts_odk.ipynb`#

`round_starts_soon.ipynb`#

`first_submission.ipynb`#

`Send_mail_wrong_form_used.ipynb`#

`check_pyramid_for_each_language.ipynb`#

`check_relevant_conditions_odk_form.ipynb`#

`compare_pyramid_length_across_forms.ipynb`#