When the idea of this piece came about, I struggled a lot with what to call it - an article, an internal memo or an open letter to the DHIS2 Community of Practice at large. I ended up in an infinite loop of paralysis, just from deciding what to call this. So as a consequence, I ended up just crunching my keyboard. So whatever this is, it’s nothing but an effort to share my thoughts on the direction that I wish DHIS2 could take, nothing too technical - just random musings.
I believe there must be a document somewhere that does justice to providing this type of direction. So, by all means, this is nothing serious; I just felt like sharing my thoughts with the community at large, hopefully to ignite conversation around the “strategic direction” DHIS2 should take, inspired by what I believe will be the next frontier for DHIS2.
Humble Beginnings
To share a bit about myself and where I come from with the system, I’m relatively new to DHIS2; I first started implementing DHIS2 in early 2018 - the version that was used at the time was 2.24, if I got my timeline correct. Having implemented and customised iHRIS for about 3 years, I just fell in love with how easy DHIS2 was to implement; from designing data elements, datasets that easily mimicked paper reports, to dynamic dashboards that were interactive and intuitive. I’ve been hooked to the system ever since, and even when I was transferred to other roles where I led the implementation of different systems, I’ve always kept a close eye on what is happening in and around DHIS2.
So, let’s get to it. I’d like to touch on areas that I’d like to see looked into for the next shape of DHIS2. I’ll keep it simple and straight to the point:
1. Tracker Should Have Been a Standalone Module
Over the years, DHIS2 has grown so large, and it’s bloated - no offence. When the second version of the system was rewritten from the ground up, inspired by the first version, which was “open source” too and heavily relied on Microsoft Access, this system was intended to be a reporting system, that is, to collect aggregate data. I don’t know the history of what prompted the need for Tracker and Tracker Capture, but it’s evident that there was a need to collect granular patient-level data. It’s also no denying that there was a gap for an EMRish system that was not fully-fledged, which is why it is so popular to this day. However, from the first time I saw it, I was like, “More great ideas like this are surely going to emerge, and this should have been introduced as a module.”
Over the years, we have failed to modularise DHIS2’s functionality in a way that allows implementations to create their own custom flavours. The core of DHIS2 should strip off many functionalities and keep the core lean; with apps like the Aggregate app, the dashboard app and a few ( and very few) core functionalities as candidates to make it to the core. Of course, this is debatable; the point here is that we should keep it lean and have the rest of the functionalities as standalone modules that can be installed when needed, much like what the OpenMRS community has done. This approach will also allow the Docker setup to follow a true microservice architecture.
I do nonetheless acknowledge that the current architecture follows loose coupling between components; I just feel like we should have avoided bloating the default setup by shipping every piece of functionality. Tracker and Tracker Capture (now combined and simply called Capture) should have been modules we installed only when needed.
I can also see a future where the DHIS2 core lives beyond the health sector to the rest of the world as a web framework for building beautiful web APIs because let’s say it like it is - the DHIS2 web API is bea-u-ti-ful!!
2. It’s high time we strengthen backend development
At the time when DHIS2 was moving away from a legacy UI that heavily utilised libraries like JQuery, I was delighted to notice that frontend apps were taking on lives of their own. New releases focused more on bug fixes and less on apps. Yes, apps were being updated too, but it was possible to have a line listing app that is updated on an earlier version of the underlying version. That was profound; the release cycles of the DHIS2 core and accompanying apps were no longer synced. I loved that.
In addition, we released the frontend development SDK and developers competed in frontend app contests, all in an effort to bolster the system’s frontend stack. The frontend stack is now mature enough - kudos to the frontend team and the community at large for taking on the challenge. It’s about time we do to the backend what we did for the frontend. Who knows, maybe the CHAP Core App could have been a DHIS2, Java-based module, had the backend development been easier in DHIS2. If we don’t strengthen backend development, I fear that we’re going to fragment DHIS2 - knowledge of it is going to be siloed pretty quickly.
We need tools to empower backend development; the first is the backend SDK, others will follow. With a lean core and a wide range of modules to add, countries can create their own flavours of DHIS2.
3. DHIS2 X GenAI
Imbuing DHIS2 with human-like AI capabilities is a code-red priority in this day and age, as we are starting to fall behind.
Just as barriers to programming have been eased by AI, barriers to data analytics should be relaxed, too, with the help of AI. A non-technical user of DHIS2 should be able to prompt the system with a simple prompt like “How many babies were born this month?” and the system should be able to produce that type of table, without being a Data Visualizer ninja. Additional features for chat-baiting, such as “Would you like me to generate a graph for you?” will also make it fun for program heads to spend more time with the system, much like what Push Analysis sought to achieve.
Still on AI capabilities of DHIS2, I’ve seen proofs of concept in other systems (like OpenMRS) using OpenAI models. This is OK as a proof of concept, but the final solution should be based on open-source models. There are plenty of them.
Last but not least, we need to start thinking deeply about how we enable developers to start building GenAI apps; LangChain and Copilot Studio are good examples of where to draw inspiration to empower GenAI developers.
Just like we were busy with frontend development, I hope we ignite a frenzy on backend and GenAI development. With DHIS2 the sky has never been the limit.
