in an integration work (openIMIS-DHIS2) I have a program where the product used for an event is defined as an optionSet. I’d like to create visualizations per product but I populate this optionSet via the API (could be more than 100 products) so I cannot create 1 program indicator per option. (Also I don’t really want to have all indicators X 100 )
Is there a possibility to add a “disaggregation” of a program indicator based on the optionSet of the event ?
Hi @pmpdelcroix,
Would you send me the API request you are using to populate this optionSet? I would like to see if we could filter it right there, please!
Additionally, I think it’s possible to create a program indicator and use the filter to choose only one option from the option set.
I am using python code to push the data, I guess “could” create indicator via API too (by setting the filter event.product=“code1” etc) but it will make the analytics really painfull because almost all reports need disaggregation and the total: with the solution 1 indicator = 1 code I would need n+1 indicators for n product but I won’t have the capabilities of cherry picking product in the filters, or did I miss something ?
The only solution would be to use PDAC to make dataset out of program but PDAC still miss a scheduler to update the data (DHIS2 module limitation) so not really user friendly … (my module will be part of openIMIS therefore I won’t configure all the DHIS2 instances myself)
Thanks for sharing! In my opinion, I think it’s always better to experiment in the browser with the endpoints /api/ before using code!
You can at the time of creating a Program Indicator to filter the results to be only for a certain option which I think is the best way, but since you can also get the filtered results from the Event Reports app directly from the OptionSet (even if you don’t create an indicator).
Here’s an example where I created an option set: Products with options Product_One , Product_Two , and Product_Three, and then used the Event Reports app to filter. The interesting part is that you can check the API requests and use them in your code:
Thanks you for the reply but I don’t think I could use the event reports to do averages, max, min, (all but count) or indicators that don’t require access to the Program, can I ?
Creating the indicator via the API is not the issue, I already created models for a lots of DHIS2 endpoints I could create one more, but it is more about the freindlyness of usage, with indicators from the API the user will still have to play with hundreds of indicators if not thousand (nb product x nb indicator that need product disagregation)
if program indicators could have a disagregation using event/enrollment optionset that would be great (cat/cat combo would sync with optionset selected for disagregation), and I am sure it would make the life of other better.
In the mean time, thanks to you replies,I think we will drop the program approach and sync dataset directly enven if I loose data granularity.
Pleased to confirm that, with the advice Calle, DHIS2 does support Program Indicators which use Options from Option sets in filters.
This particular Tracker Program has one stage with several Data elements and one of the Data element allows selecting from one of 17 options of an option set. For each TEI (in this case an item or healthcare product) one Program Indicator is needed for each of the Options (which represent “Deliver to” places such as the paediatric ward or the operating theatre).
Item code == ‘DASDCHLC5S1’ && Stock on Hand.Deliver to == ‘diagn_imag’
TEI = “DASDCHLC5S1” (Chlorhexidin)
Program stage = “Stock on hand”
“Deliver to” = Option set
“diagn_imag” (Diagnostic Imaging (X-Ray) = option from the Option set
Important notices:
use “==” (and not “=”)
use ’ (and not ")
make sure to use the Option code (“diagn_imag” and not the Option name)
note that the Program Indicators seem not to be calculated retroactively and after creating a new Program Indicator, make sure to record at least one Event which invokes the specific Program indicator
Program Indicators which do not use Options in the filter are permanently displayed in the header of the Tracker Capture, but
Program Indicators which do use Options in the filter, will only be displayed immediately after an Event invoking that specific Program indicator. In this case an Event with the Option “Sterilization Department” was entered:
But, as soon as an Event with another Option is entered, that Program indicator disappears and instead the Program indicator (only) of the last event, in this case “Operating theatre”, appears:
However, the “hidden” Program indicators are stored in DHIS2 and can be used, for example in a Predictor for “transferring” Tracker Program values to a Data Entry form.
Thank you for the feedback but the issue is not the unability to use option from optionSet BUT the inability to have the optionSet as a disagregator
the difference lies on the number of indicator to create,
in my example I have one option per product, I have 50 product and 20 indicators ( thousands events per months)
unless I misunderstood, following you approach to have all my indicators by product I would need to created 1000 indicators but if DHIS2 was able to disagregate indicator per option from selected optionSet then I would need only 20 indicators
I completely I agree: in this case I have to (and I am) creating 1,000 Program Indicators so being able to disaggregate “automatically” by all options in an option set would be great.
Hi Patrick
Please Finally, did you get a solution to your problem? on the use of option sets as a disaggregation dimension to avoid creating the same problem indicator multiple times?
Thanks
I knew this approach, there is also a app (DHIS2 App Hub) that could help. (need a external server to call that app and send the resulting dataset, worst case it helps generating the indicators)
but this is for advanced users; my work was to have a plug and play ETL and dashboard between openIMIS and DHIS2 (we are not in favor to develop to much reports inside openIMIS, there is better solution existing as DHIS2) therefore I could not expect advanced DHIS2 level
