I am trying to configure a DHIS2 instance to be able to ingest data from a financial report. I am having a problem on creating the appropriate Category and Category options because of a grouping problem in the data.
To illustrate:
Level 1 - each expenditure item will have an “Economic Item” name as a spending type. There are at least 32 possible Economic Items
Level 2 - each Economic Item can map to at least 10 Programmes
Level 3 - each Programme can map to at least 2 Main Programmes
Does this mean that to accommodate every possible combination of spending type, I have to create at least 640 Category Combinations?
I would appreciate any inputs or ideas on how I might do this differently.
Perhaps there’s a way that I can ingest the data so that it will take on different Categories (without using Category Combinations) so I can just keep the levels separate?
Thank you for your post. Designing a Tracker Program requires a number of steps and knowing how to configure the metadata as well as keeping the final objective in mind which is both how the data is going to be captured and how it will be analyzed.
For your unique use case handling ‘financial data’, it might also help to include further explanation to the scenario as well.
By Levels, do you mean Organization Unit levels? For instance, National > …> District > … > Facility. What do you mean by mapping these? Are you aggregating the data captured in the Tracker stage? It will help if you’d explain the scenario in more details please.
For these items, are they predefined? Would using an option set work?
Looking forward to your input so we can have a further look at this. Thanks!
I am not totally convinced that the category model is going to work well for you here. I think it really depends on whether the “at least 10 programmes” for each economic item are different for each programme. If they are different, then you need some sort of “cascading drop down” where you first select the “Economic item” and then git a listing of only the relevant “programmes” for that economic item. The issue with DHIS2 is that basically ALL possible combinations of category options within a category combination will be used to generate category option combos. Thus it is very likely that you will end up with many “Economic item/Programme” combinations which are not valid. You could also end up with a huge number of category option combos which will greatly complicate data entry and analysis.
I would almost be tempted to use anonymous events to enter this type of data (instead of aggregate).
That way you could instead create an event for to register each expenditure
Expenditure amount (Number)
Economic item (Option set)
Program (Option set)
Main program (Option set)
You would still have to deal with the issue of which programs are valid for which Economic items, but that could potentially be dealt with with custom forms or program validation rules.
Expenditures feels to me to be more event type of data, rather than aggregate. If you are getting your data from a financial system and need to get it into DHIS2, that is a bit of a different story though, and we might could consider some other approach.
So the way we’ve tried to make it work so far is basically what you described, each Economic Item is an event in an “Expenditure Tracking Program”. At this point, because of the number of Economic Items that can be assigned to different Activities, which can be assigned to different Programmes, and ultimately a Main Programme, we have at least 4,800 category option combinations. Obviously because each option combo has its own ID, we “pre-process” the data in a spreadsheet such that we are looking up a master list of category option combos (exported from DHIS2) and assigning the right one based on the combination of 4 columns. Only then can we send that data into DHIS2.
I just feel like there should be a better way. Otherwise, it doesn’t look like we should be tracking this kind of information on DHIS2 at all.
If only there were a way to embed an external page into the DHIS2 dashboard app.
I am not totally convinced that you should be tracking it as aggregate data, at least not at the level of granularity which you propose. I think tracking each expenditure with a single-event program could work just fine.
