The 2026 DHIS2 Annual Conference App Competition is now open for submissions!
The DHIS2 App Competition is an opportunity to highlight some of the many amazing innovations created by members of the DHIS2 community, which extend the core functionality of the DHIS2 platform.
As in 2025, the App Competition notably includes any extension of DHIS2 including web apps, Android apps, integration tooling, dashboard or capture plugins, and more. To be eligible, any extension must simply meet the following requirements:
1. It must be generic and reusable.
2. It must be available to the public (for example, on the app hub), and be open-source.
3. It must ensure responsible data use.
4. It should be useful and have the potential for impact.
5. (Optional but recommended) It should make use of the extensibility tools provided by the DHIS2 core team, such as the App Platform, the Android SDK, the DHIS2 Camel Component, and DHIS2 REST API, and more.
The DHIS2 development team will review the submissions and choose a few finalists based on the extension's potential impact, technical quality, and design. As always, the finalists selected from all submissions will be invited to present their extensions live at the Annual Conference, where the audience will select this year's winner.
Finalists will receive the App Competition Finalist badge on the Community of Practice, and winners will receive the prestigious App Competition Winner badge. Last year, FlexiPortal won the competition; see the other finalists here!
How to Submit Extensions
For each extension you want to submit to the competition, fill out this simple form with some information about your extension! Each participating organization may submit up to three. Submissions will be open until the final deadline on Friday, May 1.
Please Note: We have recently updated the App Hub Submission Guidelines, which will be relevant if you want to submit an app to the App Hub. Have a look at the change here.
We are excited to see what great innovations you will share with the community this year! To learn more about submission requirements and evaluation criteria, or to see frequently asked questions, continue reading below.
Submission requirements and evaluation criteria
These subjects were covered to some extent in March's Developer Community Meetup, which you can watch here. Some other notes are included below.
Requirements
These must be met for submissions to be considered:
Generic:
The extension should work on any DHIS2 instance with any metadata. In practice, this means not depending on any preassumed metadata, for example by hard-coding IDs of objects used by the extension.
If the extension depends on some metadata, there should be interfaces or tools to map the instance's metadata to what the extension expects. The datastore can be useful for storing these mappings.
Public, open source:
The extension must be freely available, and the source code must be open and up-to-date.
Responsible data use:
We welcome the use of AI tools for development assistance, as well as being integrated in products. When integrated in products, we expect the developers to thoroughly consider and document the ethical implications of using AI. This includes aspects such as:
AI use disclaimer: The use of AI should be clearly documented and shared in the app description (on AppHub) and the documentation. Ideally, this should also be made clear for end-users of the app. This should include both what services and models are integrated with the app, and how they are used (what functionality they provide).
Security and Data sovereignty: ensuring that - by default - users' data is not shared to external entities in a way that contradicts local regulations. In practice, this means to, at least, have the option for running the product with self-hosted local models, and to encourage that option as the default. Any integrations with external models and services should be clearly documented and kept up-to-date.
Trust: AI-generated content is clearly labeled as such for admins and end-users.
This is not an exhaustive list, and it should be approached with the general spirit of being as transparent as possible with the DHIS2 community; from the core team reviewing the apps to end-users and administrators installing and using it.
Evaluation criteria
These are things we look for when selecting finalists from the submissions:
Impact
What does this extension enable for DHIS2 users?
What kind of problem does this solve?
What kind of use cases does it apply to?
What kind of users would use this extension?
Technical quality
Code quality and maintainability
Use of available tools and technology, especially DHIS2 utilities
Security
Design and usability
Ease of use
Documentation
Visual design
Ease of deployment (Bonus points for App Hub)
Accessibility (a11y)
The DHIS2 App Hub Guidelines also express some of these criteria, if you want to read more.
Frequently asked questions
Where can we get help/advice about development?
For existing guidance and reference, there's a wealth of information in the DHIS2 docs, Developer Portal and Community of Practice. The AI search on the Docs site and Developer Portal can be a useful resource.
For questions, the Community of Practice is the best place to start! The core team will be watching discussions here, and other developers can contribute as well. This also helps answer the question for others who might be wondering the same thing!
For things that don't make sense to share publicly, you can contact the core team at apps@dhis2.org.
What testing data is available/What are recommended ways for testing?
Some testing can be done on the "Playground" instances hosted for testing out DHIS2. It's recommended to make a new user if you will change user settings, and be courteous about changing too much metadata or running computationally heavy processes. These systems reset each night.
The best development experience will probably come from running DHIS2 locally with Docker. The DHIS2 core repository has a useful Docker Compose setup and good guidance on how to use it, as a place to start.
Remember to set the DB_USERNAME and DB_PASSWORD environment variables.
There are also demo databases available that can be used: databases.dhis2.org
Remember the generic criteria – your extension should work on any instance (of versions that your extension supports) with any metadata. This may involve using configuration interfaces or tools to map the instance's metadata to metadata that the extension expects.
Does the extension need to be complete?
Yes, the extension needs to be complete by the time of submission, since we need to be able to evaluate the functional feature set. It should be usable by users and implementers who see your extension and think it'd be useful for their use case.
Can multiple components be included in an extension, like a custom backend service? How should that be categorized?
Yes, multi-component submissions are absolutely welcome. An example of that might be a DHIS2 app that uses a Route to talk to a standalone backend service that handles computationally intensive work, or an external "Patient portal" with a frontend and backend that fetches data from DHIS2, with a DHIS2 app to configure the portal frontend.
Don't worry too much about the categorization.
Remember though that the extension should be generic and shareable, and that ease of deployment factors into the usability criterion by which apps will be evaluated.
As an example, the FlexiPortal extension that won last year has a one-click deploy option to Vercel and good documentation around it, which won it points in this category.
In contrast, an elaborate interdependent multi-service setup with high configuration needs and no documentation would not be considered "easy to deploy."
Are there resources for getting started with DHIS2 app development?
Yes, glad you're interested in getting started! There's some guidance for getting started on the Developer Portal, and videos of past DHIS2 development academies linked on this page with the type "Workshop."