🤖 DAC2026 Summary & Wiki/AI: AI, Machine Learning & Innovation

Resources - Ressources
1

Practical AI, Machine Learning, and Innovation in the DHIS2 Ecosystem

:warning: Note: This summary was generated and reviewed by the dhis2 docs Ask AI tool and may contain errors. As this is a Wiki post, we encourage you to edit and improve this content with your own expertise, or reply with your questions for discussion!

This document compiles the technical specifications, architectural designs, deployment frameworks, and pilot outcomes for artificial intelligence (AI) and machine learning (ML) implementations presented at the DHIS2 2026 Annual Conference.

1. Technical Classification: Four AI Paradigms in DHIS2

The integration of artificial intelligence within DHIS2-based health information systems is structurally classified into four distinct technical paradigms based on data requirements, system interfaces, and operational maturity. [AI, ML, Innovation]

Paradigm Technical Focus Infrastructure Interfaces Operational Status
Classic Machine Learning Statistical forecasting, anomaly detection, and predictive modeling using structured aggregate or tracker data. Native DHIS2 analytics, R/Python modeling engines, and external processing APIs. Production-ready; actively deployed for climate-sensitive disease forecasting.
Generative AI for Data Entry Multimodal translation of structured images (photos of paper forms) or voice records into JSON data payloads. Web APIs, mobile app extensions, and localized LLM runtimes (e.g., Ollama). Pilot stage; requires manual verification steps before database commits.
Generative AI for Querying Natural language processing of metadata tables and analytics databases via conversational interfaces. Model Context Protocol (MCP) servers, OpenAPI contracts, and external chatbot APIs. Experimental proof-of-concept stage.
AI-Assisted Software Development Generative code generation and agentic orchestration to build custom web applications and configuration scripts. TypeScript API contracts, App Platform builders, and local developer environments. Operational; supported by official developer tooling packages.

2. Classic Machine Learning: The Climate Health Analytics Platform (CHAP)

Developed by the HISP Centre at the University of Oslo, the Climate Health Analytics Platform (CHAP) is an open-source framework designed to model and forecast infectious disease trends by integrating historical health records with environmental covariates [AI, ML, Innovation].

System Scope and Interoperability

While primarily utilized for climate-sensitive vector-borne diseases such as malaria and dengue, CHAP’s modeling pipeline is disease-agnostic. The platform has been configured and tested to support:

In February 2026, a technical workshop in Kigali brought together representatives from 15 countries—including regional HISP nodes and academic disease-modeling networks—to standardize model exchange formats and promote collaborative code sharing.

Architectural Model: Local Execution over Central Extraction

To comply with national data sovereignty regulations, CHAP utilizes a containerized architecture designed to run models locally on country-managed infrastructure rather than extracting sensitive health records to external cloud servers.

  • Model Packaging: ML models are bundled into standardized, containerized environments.
  • Integration: Models interface with the DHIS2 modeling application as modular plugins. This allows domain experts and epidemiologists to select and weight local environmental variables (e.g., rainfall, humidity) without manually modifying the core DHIS2 source code.

3. Infrastructure Models for Generative AI Deployment

Implementers deploying Large Language Model (LLM) interfaces within health systems must evaluate three distinct hosting architectures: [AI, ML, Innovation]

Hosting Architectures for LLMs in DHIS2

Hosting Model Data Location API Dependencies Infrastructure Cost Operational Considerations
Proprietary APIs (e.g., OpenAI, Anthropic) External (Off-premise) Continuous dependency on external service availability. Transaction-based subscription costs. Subject to geographic service restrictions and external data privacy policies.
On-Premise (Local LLMs) Internal (Local servers) None; operates in offline or air-gapped environments. High up-front hardware cost (dedicated GPU/RAM). Requires local server maintenance, container management, and cooling infrastructure.
Private Cloud VMs (e.g., AWS, Azure) Selected Cloud Region Dependent on cloud provider SLAs and regional endpoints. Ongoing compute and storage resource rental costs. Requires cloud engineering expertise and strict virtual network configuration.

Technical demonstrations of local generative AI workflows during the sessions utilized private cloud virtual machines running Ollama to serve local models [AI, ML, Innovation]. In these environments, processing times and throughput rates were lower than those achieved via proprietary APIs, which is a key planning variable for real-time workflows [AI, ML, Innovation].

4. Generative AI for Data Entry: Multimodal pay-loading

Two separate workflows for automated paper-to-digital data translation were demonstrated, both employing multimodal LLMs to parse physical images and generate structured DHIS2 Tracker payloads.

Multimodal Web Application Pipeline

A prototype DHIS2 web application was shown running a six-step integration pipeline: [AI, ML, Innovation]

  1. Metadata Ingestion: The app loads the target program’s data element and attribute metadata directly from DHIS2 on startup.
  2. Prompt Generation: The app automatically generates an LLM prompt structured to match the metadata schema.
  3. Image Capture: The user uploads a photo of a completed paper clinical form.
  4. Local Processing: The app transmits the image and generated prompt to a local LLM instance (hosted via Ollama on private cloud infrastructure).
  5. User Verification: The model returns a structured payload that populates an editable, on-screen verification form.
  6. DHIS2 Commit: Once reviewed and manually verified by the operator, the application submits the event payload to the DHIS2 Web API.

The demonstration used a handwritten form for a patient named “Mary James, 35 years old, female, positive PF with chills and fever.” The model successfully extracted demographic attributes and diagnostic outcomes, but failed to accurately check program checkbox fields. A manual review step remains a core component of this pipeline. [AI, ML, Innovation]

5. Metadata Querying and Data Quality Automation

The UNICEF AHEAD Initiative

The Actionable Health Analytics for Decision Making (AHEAD) initiative by UNICEF utilizes automated analytical tools to identify complex data quality anomalies that fall outside the scope of standard, row-level DHIS2 validation rules [Lightning Talks: AI]. The tool scans national data extracts to flag:

  • Logical Sequence Violations: For example, tracking patients recorded as receiving DTP3 vaccines without an accompanying historical record of a DTP1 dose [Lightning Talks: AI].
  • Same-Age Dose Discrepancies: Identifying statistical variation in reporting rates between different antigens recommended for administration at the same chronological age (e.g., DTP3, PCV3, OPV3, RV2) [Lightning Talks: AI].
  • Identical Value Repetition: Detecting instances where a health facility submits identical immunization figures month-after-month over multiple reporting cycles [Lightning Talks: AI].
  • Contextual Outliers: Highlighting values that deviate significantly from a specific facility’s historical trends [Lightning Talks: AI].

The output engine generates compiled diagnostic reports and PowerPoint presentations categorized by national, provincial, and facility level to support local data-review meetings [Lightning Talks: AI].

LangChain and Observability in FHI 360 Pilots

FHI 360 presented a multi-country pilot program employing orchestrated AI agents to interact directly with DHIS2 instance data [Lightning Talks: AI].

  • Technology Stack: The implementation built its orchestration layers using LangChain, hosted on Azure enterprise virtual networks [Lightning Talks: AI].
  • Evaluation Framework: To systematically assess model outputs, the project utilized RAGAS (Retrieval-Augmented Generation Assessment) to evaluate performance across four dimensions: model performance, product usability, user experience, and overall programmatic impact [Lightning Talks: AI].
  • Observability: To monitor LLM API behavior and token costs at scale, the team transitioned from manual human evaluations to automated logging using LangFuse [Lightning Talks: AI].

Model Context Protocol (MCP) for Metadata Governance

A technical demonstration showed a Model Context Protocol (MCP) server configured to allow an LLM to query and correct metadata directly on a DHIS2 instance [AI, ML, Innovation].

Through defined API tool schemas, the LLM was able to:

  • Identify schema inconsistencies, such as a data element with the label “Date of Birth” configured with a value type of COORDINATE instead of DATE [AI, ML, Innovation].
  • Draft and execute an API update payload to correct the value type [AI, ML, Innovation].
  • Extract metadata translations and query schema differences between a development and a production instance [AI, ML, Innovation].

6. DHIS2 AI Core Objectives: Developer Tooling

The DHIS2 core software team has structured its AI roadmap to focus on improving the developer experience for AI-assisted application building, rather than integrating native AI data entry or clinical analysis engines into the core DHIS2 software platform [AI Core].

To make DHIS2 core packages easily readable by AI models and coding agents, the team has implemented the following features: [AI Core]

  • LLMs.txt File: A standardized index hosted on the DHIS2 documentation site to allow AI web crawlers to cleanly ingest technical documentation.
  • Documentation MCP Server: A hosted server that allows developers to point their coding assistants directly to an authoritative, structured reference repository of DHIS2 APIs.
  • Source Code Bundling: Node packages (such as the @dhis2/ui library) are compiled to bundle their underlying source code. This allows AI code completion engines to read the exact component parameters rather than guessing based on minified files.
  • TypeScript API Types: Auto-generated TypeScript interfaces compiled from the DHIS2 OpenAPI specifications are published as the dhis2-api-types package, providing developers and AI agents with real-time schema validation when writing API requests.
  • Official Developer Agent Skills: The core team published a command-line utility to install official, vetted app development skills directly into AI development agents:
# General developer tools installation
npx skills add dhis2/ai-devtools

# Direct installation of the DHIS2 app-building skill
npx skills add dhis2/ai-devtools --skill dhis2-apps

This skill restricts the AI engine to a modern, supported stack: TypeScript, pnpm workspace management, Vite, React Router, and TanStack Query v4. This prevents the model from generating code with deprecated core libraries. [AI Core]

7. Practical Guidelines for AI-Assisted App Development

The developer workshop on “Vibe Coding” highlighted five practical constraints for developers using generative AI to write DHIS2 web applications: [Vibe Coding]

  1. Work in Isolated Environments: If allowing autonomous AI agents to write and execute code, run the development environment within containerized workspaces (e.g., Docker Dev Containers) to prevent local file-system or system-configuration damage.
  2. Maintain Short Context Windows: LLM generation accuracy degrades as chat histories grow. Developers should complete specific, modular features, save their progress, and open a fresh session for the next task.
  3. Use Local Version Control: Do not allow AI agents to manage Git repositories or push commits directly to production. Developers must manually review, stage, and commit changes to maintain clean branch histories.
  4. Enforce Small File Architectures: LLMs must read code files from top to bottom. Restructure large classes into small, modular helper files. Large files often lead to the model dropping or corrupting functions at the bottom of the file.
  5. Utilize Verification Prompts: Before asking an agent to write code, prompt it to interrogate the requirements. Using a pre-generation framework (such as “Grill Me”) to ask developers clarifying questions about edge cases and data validation helps ensure the generated schema is correct.

8. What to Watch

The technical presentations are available for review on the DHIS2 YouTube channel:

Community Call to Action

Are you experimenting with AI in your DHIS2 implementation — whether for data entry, metadata auditing, disease forecasting, or app development? Share your experience in the thread below, including what worked, what did not, and what questions remain open for you.

  • Developers: Explore the dhis2/ai-devtools repository and share feedback on the agent skill — the core extensibility team is actively seeking community input on what works and what gaps remain.
  • Implementers: If you are evaluating on-premise AI infrastructure or CHAP for disease forecasting, flag your context and questions below — others in the community are likely navigating the same decisions.
  • Everyone: What guidance or architectural support do you need most from the core team? The team has explicitly stated that data collection and analytics AI initiatives will be shaped by community direction — this thread is a good place to start that conversation.
🗓️DAC2026 Thematic Summaries & Wikis/AI