We have developed a tracker program for use in multiple countries. However, we have run into the problem that arises where each of the countries have one or 2 specific data elements or attributes that they would like removed/included in addition to the standard program.
I want to ask whether it is possible in any way to keep the same core program (with the majority of the DEs being the same) and simply have minor variations for each country? Would this require us to build a new tracker program for each country, despite them being 99% the same? Some of the minor differences could simply be down to what the various administrative levels are named when asking for a street address.
Any discussion or input/advice would be appreciated on the best practice going forward as I am hesitant to build a new tracker program for every country we work in.
The “core package with country variations” is basically what is being done with those WHO standard packages you might have come across.
I have predominantly used copies of existing databases - whether from the same or other countries - since the very first DHIS 1.0 databases designed back in 1997. Off hand, I cannot even recall the last time I created a database completely from scratch.
So the general answer to your question is YES, you should create one (or more) standard databases and use them as templates for all the country instances. Certain things will obviously have to be replaced more or less fully - like the orghierarchy - but everything else can be tinkered with.
There are various ways of designing the basic template(s), though:
1.
You can design it as a sort of generic “model” of what you perceive as an ideal instance (disregarding local customs and “idiosyncrasies”), which is fundamentally what WHO has done for their standard packages (fundamentally a sort of top-down approach, although many of those “ideal” design components obviously build on country input and/or feedback);
2.
You can analyse the requirements for a cross-section of potential user countries and then design a “minimalist” template, which different countries then would copy and ADD to (more of a bottom-up approach);
3.
You can design the system for one pioneer country WHILE OPTING FOR STANDARD DESIGN AND NOMENCLATURE (as you perceive it), implement and refine it, and then expect other countries to ADD/MODIFY/DELETE components from that pioneer system (this is the traditional prototyping approach we have used for most DHIS systems over the years).
We do not(yet) have an official endorsed best practise on this, but have been discussing a somewhat similar context lately. In that context we think we will end up writing the changes into program rules, and use contstants for configuration. In that manner we can have the exact same metadata package imported everywhere, and let smaller changes follow the constants. An example of a program rule that would change the user interface based on constant config could be defined with the expression(constant oisd22ssad2 represents wether a data element is shown or not: C{oisd22ssad2} == false
Using constants is only one option, other constructs like user group membership could have been used.
Thanks @Calle_Hedberg and @Markus for your inputs. I appreciate the advice and think that we will then proceed with developing a new tracker program as Calle mentioned for Option 2. This seems to fit our needs best, as we aim for a standardised core set of data being collected, but each country would want other country-specific data included into their program.
Markus, the use of program rules is a good idea and I will look further into how we could possibly use it to streamline the development of our programs for the various countries.
For small/modest variations, I think the approach suggested by Markus makes a lot of sense - in particular if technical support from a more centralised team will continue to all these countries in the foreseeable future.
If the variations are more significant and/or “central” technical support won’t continue beyond the initial establishment phase, then a slight “forking” of country instances might be a better option and easier to manage. Because if country X have to maintain an instance with let us say 100 data elements they use themselves and 200 data elements they do not use originating from 90 other countries (1-2-3-4 extra data elements per country) AND you expect the meta-data of all these 91 country instances to be kept in synch at all times - then I would expect a lot of challenges.
Another complicating factor is that if these instances are COUNTRY instances (run by the Ministry of Health or similar), then you cannot expect that all of them will decide to keep any “package” or “proposed instance” focusing on this or that area as a standalone instance - many might prefer to integrate such “packages” into a larger and more comprehensive instance.
Nuff’ said - cannot really say much more with the limited info available.
The consideration of integration into the various Country National Instances is something that we will have to take into consideration and something that I hadn’t considered before. As you mentioned, this would likely complicate the synching of the instances (which is something that we are hoping to move towards also) as well as the uptake from the country’s with regards to transferring metadata to the National instance.
Thanks again to everyone for their help and input!
I’m coming to this discussion a little late, but I just wanted to chime in with our experience of building similar-but-different Event Capture programs across 40+ countries (https://equitytool.org). Our scenario was that the core program structure and indicator algorithms were the same across all countries, but things like the number of data elements, the data element names and the weightings differed significantly from country-to-country. The way we got around this was to create a dynamic Excel workbook which provided an area for easy user input of variables for each country, such as data element names and weightings, and a worksheet that used a master template plus these inputs to construct an XML metadata file for that specific country’s Event Capture program.
This was a lot of work to set up, but it has ensured very consistent quality of configurations across countries, and has made maintenance a lot easier. When we need to make corrections or updates to our core program, or we have to modify our programs to work with new versions of DHIS2, all we have to do is make the necessary adjustments once in the master Excel template, then re-generate all of the specific country XML metadata files (which can be re-imported to update existing deployments, since we also generate UIDs for all elements).
The effort involved in setting this up initially probably only makes it viable in a scenario where you have a lot of variation between countries, and need to provide ongoing management of updates etc; if you only have minor variation between countries, then I think Markus’ approach with constants + program rules to hide data elements etc would be much quicker and simpler to implement.
Regardless of the way forward you choose, I’d definitely recommend carefully thinking through how you will manage corrections and updates once all of these variations of the program are out there - eg the inevitable correction to the core program that needs to be sent out after deployment, or sharing an enhancement that a number of different countries have requested…
Thanks @SamuelJohnson - that is certainly something that we will take into consideration. I like the way that you have developed the data workbook that then adjusts each of the country requirements as necessary.
Thanks again to everyone for all of their inputs. I appreciate it and it has really helped us to think about the various things that we wouldn’t have considered previously.
