DHIS2 Software Development Roadmap Process
On this page, you can find an overview of the prioritization and development process and schedule for DHIS2 software
Jump to a section on this page
Overview: DHIS2 software roadmap and prioritization process
Requirements for new versions of DHIS2 are collected from the global user community, and priority is given to generic improvements that can have an impact across implementations, rather than those that are specific to one place. A dedicated team at UiO leads the development and maintenance of the DHIS2 software platform, including web and Android applications. DHIS2 software is developed in 6-month cycles of backend releases, plus periodic patch releases and continuous app releases, according to a collaboratively planned roadmap. The annual prioritization process for this roadmap is an iterative, flexible, and continuously evolving process that broadly follows the following stages or steps:
- Initial prioritization: Annually in early September, key stakeholders present their high-level requirements, for example their top 5 priorities per product (Analytics, Tracker, Android, and Platform) and overall. The key stakeholders are: Ministries of Health / country governments (represented by the regional HISP network, divided into 3 geographical regions), HISP UiO / global project leads (who cover specific project deliverables to donors), and HISP UiO management (who represent the HISP UiO strategy and direction).
- Compile and analyze requests: Product managers and technical leads compile all requests, combine similar features or divide up larger ones, resulting in a consolidated list of requests.
- Final Platform Prioritization: A meeting is then held to reconvene the stakeholder groups to rank (prioritize) the high-level tasks in the consolidated list of requests. This enables a chance for each stakeholder to adjust their own priorities and to rank inputs from other groups. This list then guides the feature prioritization for upcoming releases.
- Assessing the priorities along the way: For each individual release, product managers meet with stakeholders to assess progress against prioritizations and add specific features to the next release to continue to work towards those priorities.
How do you contribute to the roadmap? The most effective way to have a request included in the roadmap is for a Ministry of Health to request features through their collaboration with a HISP group. Another option is to communicate with the HISP UiO software team through the DHIS2 Community of Practice (CoP). You can learn more about this process in the “Explore & Share Input” section further down on this page. Requests submitted in this way can often be addressed if multiple DHIS2 implementers request the same thing, even if there is not a Ministry connected to the request.
DHIS2 software release cycle diagram
The DHIS2 core and Android software teams release new software versions on a 6-month cycle, with patch releases for supported versions released on a periodic basis. In the diagram below, you can see a visual overview of our annual software release cycle, including the timeline for prioritization, requirements gathering, design, development and testing.
Current roadmap for upcoming DHIS2 software releases
Visit the Software Roadmap page for an interactive diagram showing the software features planned for upcoming DHIS2 core and Android software releases.
Share input and explore the software roadmap in more detail
The DHIS2 software development team uses
Jira to manage the DHIS2 roadmap and development process. On the DHIS2 Jira project, you can explore upcoming releases in more detail. You can also use
Jira to report bugs and request features for upcoming versions of the software, as well as vote for and track the progress of specific features and fixes. However, for complicated bugs or feature requests, we ask that you first post a description and explanation of why it is important on the DHIS2 Community of Practice (CoP), where the UiO team and other developers can review and provide feedback on the approach and use-case before you write the specification on