On 5 May 2026, supportive supervision shipped inside DHIS2 Core v43 and Android Capture 3.4. It is no longer something each programme has to build. If you run supervision through DHIS2, this changes what you have to maintain.

What programmes were doing before

Structured supervision has never fitted neatly into a standard DHIS2 form. A supervision visit is not a data entry exercise: it is scored, it is weighted, it produces a conversation, and it has to leave the supervisee with something actionable. Programmes solved this by building around the platform rather than inside it.

That produced a familiar pattern: a custom app, maintained by whoever built it, pinned to a DHIS2 version, and quietly at risk from the moment the funding cycle that paid for it ended.

A supervision tool that only one team can maintain is a supervision tool with an expiry date.

What shipped

  • Colour-coded scoring. Scores render against thresholds, so a supervisor sees where a facility stands without doing arithmetic on paper.
  • Markdown in feedback. Supervisory notes can carry structure and emphasis, rather than arriving as one undifferentiated paragraph.
  • Side-by-side key and value display. Findings sit next to what they refer to, which is how people read a checklist on a small screen.
  • Offline-first behaviour through Android Capture 3.4, because supervision happens where connectivity does not.
Supportive supervision feedback in DHIS2 Android Capture: section scores rendered against colour thresholds, with formatted feedback appearing inline beneath each question.
Android Capture 3.4, showing scored sections and inline feedback during a malaria supervision visit.

Why the design choices went that way

Colour coding exists because supervisors were mentally converting numbers into judgements and getting it wrong under time pressure. Markdown exists because feedback written as a wall of text does not get read by the person who has to act on it next month.

Configuring it without starting over

  1. Keep your existing programme structure. Supervision tools are still event programmes. The core feature reads them, it does not replace them.
  2. Map your scoring model onto the thresholds. Most programmes already have a red, amber and green band written into a manual somewhere; that manual is your configuration input.
  3. Migrate the feedback step last. Data capture and scoring are straightforward. Feedback is where local practice varies most.
  4. Pilot with one region before a national rollout. The failure mode is never technical, it is a scoring band nobody agreed to.

What this means for sustainability

The argument for moving features into core is not elegance, it is who is left holding the system. A custom app is a dependency on the organisation that wrote it. A core feature is maintained by the DHIS2 community, upgraded with the platform, and documented in a place a ministry can reach without asking a partner for help.

That is the difference between a programme owning its supervision process and renting it.

If you are adopting it

Start from the manual, not the software. The programmes that struggled with digital supervision were rarely blocked by tooling; they were blocked by not having agreed what a score means, who reviews it, and what happens when a facility scores badly twice in a row. The platform can now carry all of that. It cannot decide it for you.