🔗 DAC2026 Summary & Wiki/AI: Interoperability, Extensions & System Design

Gassim · 31 July 2026 15:54

The Architect’s Guide to DHIS2 Extensibility, Interoperability, and System Design

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, API integration patterns, extension point contracts, and system design frameworks presented at the DHIS2 2026 Annual Conference.

1. The Extension Point Menu: Platform Integration Options

The following table outlines the technical specifications, availability, and documented system boundaries of the native extension points in the DHIS2 platform. [Extensibility Session]

Extension Point	Primary Purpose	Available From	Technical Constraint / Boundary
Web API	REST endpoints for data and metadata operations; utilizes OpenAPI specifications and published TypeScript type libraries.	All versions	High-frequency bulk extractions require client-side throttling and caching to prevent server resource degradation.
Custom Web Apps	Standalone custom user interfaces hosted within the DHIS2 environment; built using the DHIS2 App Platform.	All versions	Must conform to App Platform build conventions; direct DOM manipulation of core applications is not supported.
Capture Form Field Plugins	Custom fields injected into standard Tracker or Event data entry forms.	v40+	Operates within a defined plugin contract; cannot modify the layout or CSS properties of surrounding core form containers.
Capture Enrollment Plugins	Custom widgets embedded inside the Capture enrollment dashboard (e.g., custom graphs, relationship maps).	v40+	Confined to the dashboard widget slot; cannot reopen completed enrollments directly.
Capture Bulk Data Entry Plugin	Specialized interface for entering clinical or program data across multiple enrollments simultaneously.	New in v43	API contract and core interface components are currently under active definition.
Dashboard Plugins	Custom data visualizations or analytical widgets embedded in the standard Dashboard application.	Long-standing	Layout is constrained by the grid boundaries of the Dashboard application.
Routes API	Server-side proxy for executing requests to external APIs; handles authentication credentials securely (HTTP Basic, Token, OAuth2).	v40 (basic); v42/v43 (OAuth2)	Destination hosts must be whitelisted in `dhis.conf`; core v42+ defaults permit `https://*`.
Data Store	Key-value JSON storage for persisting application configurations, states, and user preferences.	All versions	Does not enforce backend schema validation; access controls must be managed explicitly via namespace sharing settings.
SQL Views	Read-only SQL query execution exposed as a Web API endpoint.	Long-standing	Restricts direct write operations and limits access to core patient-identifiable tables.
Event Hooks	System notifications triggered by metadata mutations or scheduler tasks; targets include Webhooks, Kafka, and Apache ActiveMQ Artemis.	Experimental	Operates on a best-effort delivery model; does not guarantee transaction delivery.
Android Custom Intents	Triggers third-party Android applications from within DHIS2 Capture to execute an external task and return a data value.	Android Capture	The specified external application package must be locally installed on the physical device.
Deep Links	Navigational shortcuts mapping command palette search strings to specific application routes.	Recent	Mapping rules must be declared in the application manifest.

2. Technical Architectures: Documented Plugin Implementations

The following database and application configurations were demonstrated at DAC2026 to resolve specific data validation, data entry, and deduplication requirements. [Plugins Session]

Civil Registry Integration (Uzbekistan)

Configuration: Form field plugin within the Capture app using the Routes API to securely query a national civil registry [Plugins Session].
Workflow:
1. Operator inputs a national ID into a secure form field.
2. The plugin routes the request through the Routes API to an Apache Camel integration layer.
3. The returned JSON payload programmatically populates 18 tracked entity attributes in the active enrollment.
4. The system validates whether the national ID is already bound to an active Tracked Entity Instance (TEI) to block duplicate registration.
5. If an existing record was previously entered manually, authorized supervisors can trigger the registry query to overwrite and update the 18 attributes from the authoritative government registry [Plugins Session].
Code Repository: github.com/dhis2/reference-civil-registry-lookup

Relationship Visualization Plugin (Uzbekistan)

Configuration: Capture enrollment dashboard widget [Plugins Session].
Workflow: Queries the DHIS2 relationship API endpoints for a given TB patient. It renders the matching contact-tracing records as an interactive, node-based network diagram, resolving the lack of native relationship graph rendering in the standard enrollment view [Plugins Session].

Cross-Program Lab Sync Widget (Uzbekistan)

Configuration: Capture enrollment dashboard plugin [Plugins Session].
Workflow: Executes background queries across discrete Tracker programs (matching TB clinical surveillance cases to molecular diagnostic records on the patient’s national ID). Upon matching and operator confirmation, the plugin imports the diagnostic event data directly into the active case record [Plugins Session].

Headless Validation (ICT / EyeSeeTea)

Configuration: Headless form field plugin [Plugins Session].
Workflow: Intercepts date-of-birth input strings, normalizes formatting variations (resolving DD/MM/YYYY and MM/DD/YYYY variations), and returns either the validated date object or an API error. The plugin contains no UI components and operates solely within the form logic layer [Plugins Session].

Embedded Core App Plugin (ICT / EyeSeeTea)

Configuration: Native application containerization [Plugins Session].
Workflow: Embeds the standard DHIS2 aggregate data entry app as an integrated plugin within a custom clinical portal. The parent application automatically passes state parameters (pre-selecting the organizational unit and data set context) to prevent manual navigation [Plugins Session].

Barcode Reader Integration (Ghana Health Service)

Configuration: Capture form field plugin utilizing the browser/device camera API [Plugins Session].
Workflow: Allows laptop, tablet, and desktop operators to capture sample barcodes. The plugin performs formatting checks, verifies if the captured ID is already assigned within the database to prevent duplicate sample registration, and generates structured IDs for specimens in HIV and TB workflows [Plugins Session].

Growth Standards Visualization (Sri Lanka / HISP Sri Lanka)

Configuration: Capture enrollment dashboard widget [Plugins Session].
Workflow: Extracts historical anthropometric measurements from a child’s Tracker events and plots the data points against WHO growth standard reference curves (height-for-age, weight-for-age, BMI-for-age) directly inside the enrollment dashboard [Plugins Session].

3. Native Integration: Android Custom Intents and Simprints

DHIS2 Android Capture supports custom intents to delegate tasks (such as biometric capture) to external mobile applications, returning output data directly to DHIS2 fields. [Extensibility Session]

+------------------------------------+
|        DHIS2 Android Capture       |
|                                    |
|   1. User taps Biometric Field     |
|   4. Receives GUID string          |
+------------------------------------+
       ||                    /\
       || Intent             || Returns
       \/                    || GUID
+------------------------------------+
|          Simprints App             |
|                                    |
|   2. Captures Biometric Scan       |
|   3. Resolves and matches GUID     |
+------------------------------------+

Operational Constraints

Field Locking: When a field is configured with a custom intent, manual text entry is locked. The field only accepts data returned by the registered third-party package [Extensibility Session].
Data Types: Custom intents are strictly limited to attributes or data elements configured with TEXT or LONG_TEXT value types [Extensibility Session].

The South Sudan CMAM Implementation

Simprints configured two discrete intent parameters for a community-based management of acute malnutrition (CMAM) program in South Sudan [Extensibility Session]:

DATA_ENTRY: Executes a biometric scan, registers the template in the local Simprints database, and returns a unique Global Unique Identifier (GUID) stored in DHIS2 as a Tracked Entity Attribute [Extensibility Session].
SEARCH: Executes a biometric scan, queries the Simprints database, and returns an array of matching GUIDs. DHIS2 searches its local database and displays candidate Tracked Entity Instances matching those IDs for clinical verification [Extensibility Session].

Configuration Variables

Custom intents are mapped within the Android Settings Web App, defining: [Extensibility Session]

Target Element: The specific Tracked Entity Attribute or Data Element UID.
Intent Action: Mapped to either SEARCH or DATA_ENTRY.
Package Details: The unique Android package name and target activity class (e.g., com.simprints.id.REGISTER).
Request & Response Parameters: Explicit key-value pairs and JSON property paths to pass to and extract from the external application.

4. Multi-System Digital Public Infrastructure (DPI)

Technical sessions presented reference implementations linking DHIS2 with external Digital Public Goods (DPGs) [DPGs in Practice].

Birth Registration: DHIS2 + OpenFN + OpenCRVS

Integration Flow:
1. A birth event is recorded as a Tracked Entity Instance in DHIS2 Capture.
2. OpenFN (Open Function), acting as the interoperability layer, detects the creation event.
3. OpenFN maps the DHIS2 payload schema to the OpenCRVS schema and transmits the notification.
4. Upon successful registration in OpenCRVS, the civil registry generates a birth certificate number.
5. OpenFN writes the birth certificate number back to the original DHIS2 Tracker record. [DPGs in Practice]

Identity and Consent: DHIS2 + MOSIP + e-Signet + FHIR

Integration Components:
- MOSIP: National identity platform storing demographic records [DPGs in Practice].
- e-Signet: OpenID Connect (OIDC) provider managing user authentication and clinical consent [DPGs in Practice].
- DHIS2 Capture: Custom plugin handles e-Signet authentication directly in the DHIS2 mobile interface, querying the registry securely via the Routes API [DPGs in Practice].
- FHIR Server: Synchronizes patient clinical records. An integration agent converts DHIS2 Tracker records to FHIR resources to maintain a centralized, shared health record [DPGs in Practice].

5. Routine Workflows and Administrative Decision-Making

Architectural decisions regarding system integration are designed to support structured, subnational administrative routines.

Dashboard Ownership and Subnational Use

Sri Lanka: MCH records are validated and managed at the Medical Officer of Health (MOH) level, with local teams configuring custom local dashboards. Review of this model shows that local data use is directly linked to the users’ capacity to define and customize their own analytical parameters [Subnational Data Use].
Indonesia: In Jakarta, public health centers use a weekly meeting routine called LockMin (Locaria Mini) [Subnational Data Use]. Rather than utilizing fragmented paper reports, coordinators use a unified DHIS2 dashboard to establish a single source of truth, removing discrepancies in Excel sheets and focusing meeting time on intervention planning and monitoring [Subnational Data Use].

6. Geospatial Architecture: Denominators and Catchments

The DHIS2 Maps application supports the integration of external demographic and geographic datasets to resolve target-setting and coverage-denominator calculations.

Gridded Population Estimates: WorldPop

To address census limitations, DHIS2 can pull WorldPop gridded population estimates [Geospatial Session].

Methodology: WorldPop maps building footprints from satellite imagery and combines this with local geospatial datasets (road networks, electrification, land cover) to estimate population distribution down to 100-meter grid squares [Geospatial Session; Maps and Population].
Integration: WorldPop datasets are accessible as “Population Age Groups” layers inside the DHIS2 Maps app, calculating population estimates on-the-fly for any displayed area [Maps and Population].

Accessibility Boundaries: Crosscut Catchments

DHIS2 does not calculate catchment shapes internally, but it support importing them as Associated Geometries mapped to specific health facilities [v2.38 Analytics; Campaigns Features].

+------------------------------------+
|             Crosscut               |
|                                    |
|   1. Pulls facility coordinates    |
|   2. Calculates travel time buffers|
+------------------------------------+
                  ||
                  || Push GeoJSON
                  \/
+------------------------------------+
|            DHIS2 API               |
|                                    |
|   3. Saves Catchment Area as       |
|      Associated Geometry           |
+------------------------------------+
                  ||
                  \/ Maps App
+------------------------------------+
|          DHIS2 Maps App            |
|                                    |
|   4. Overlays Catchment Geometry   |
|   5. Sums WorldPop population      |
+------------------------------------+

Boundary Calculation: The external Crosscut application consumes DHIS2 facility coordinates and calculates boundaries based on walking or driving travel time, factoring in geographic barriers (rivers, slope, land cover) [Geospatial Session; Campaigns Features].
Data Import: Catchment polygons are pushed into DHIS2 via the Web API. In the Maps application, operators can overlay these Associated Geometries to automatically sum and display the WorldPop estimated target population residing within that clinic’s specific service boundary [v2.38 Analytics].

CrossCut generated facility catchment boundaries displayed on a DHIS2 Map. [Campaigns Use]

7. Documented Architectural Gaps and Tensions

Plugin API Boundaries: Form field and enrollment plugins cannot bypass the core React application state. For example, plugins cannot programmatically reopen a completed Tracker enrollment to write retrospective data; this operation requires custom application development or core schema adjustments [Plugins Session].
Multi-system Integration Maintenance: While integrations between DHIS2, MOSIP, OpenCRVS, and OpenFN are technically operational, they increase system maintenance overhead. Each added system introduces independent release cycles, security credential management, and distinct support requirements [Plugins Session].
Android Device Management (MDM): Implementing custom intents requires deploying and maintaining the external APK (e.g., the Simprints biometric scanner app) on every physical mobile device [Plugins Session]. This increases mobile device management (MDM) overhead in large-scale field deployments.
Model-Based Denominators: WorldPop estimates are statistical models built on historical census data and environmental covariates [Maps and Population]. In areas experiencing rapid, unstructured migration, the statistical error boundaries of these denominators increase.

8. What to Watch

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

Extensibility and Interoperability Features — Extensions in Action
Integration in Practice
Lightning Talks: Interoperability, Architecture & System Design
Plug-ins for DHIS2 Apps: How to Build Them, and Examples in Context
DPGs in Practice: Integrating Open Digital Solutions for Country Use Cases
Data Use for Decision Making: A Focus on Subnational Level (Search Day 1 parallel sessions)
Maps, GIS & Population Data (Search Day 3 parallel sessions)

12. Community Call to Action

The extensibility and GIS teams at DAC2026 explicitly stated they want to hear from the community about use cases where existing configuration and extension points are not sufficient:

Share your plugin implementations: If you have built a form field, enrollment, or bulk data entry plugin that others could reuse, publish it to the App Hub and share the link in this thread.
Report extension point gaps: If you hit a wall where no current extension point covers your use case — particularly around enrollment state management or layout modifications — describe it below.
Geospatial and Catchment Feedback: Share your experiences establishing workflows with WorldPop or Crosscut. How are you handling the coordination of catchment boundaries and population layers in your country programs?
DPG integrations: If you are working on a DHIS2 integration with MOSIP, OpenCRVS, or other digital public goods, the reference implementations at mosip.integration.dhis2.org are starting points — share what you adapt.