Below is a lightly edited Q&A from our session yesterday, combining questions from the chat and aloud.
Q: Would attribute combos be suited to represent different “states” of collection—e.g., number of deliveries—claimed by the organisation unit, verified by an auditor, validated as the quantity that is used for official statistics?
A: Yes, you could use it for that. For more guidance, see the Additional Data Dimensions chapter of the DHIS2 user manual.
Q: Do you have any tips on how to capture the collaboration or cost share that might take place between two or more projects. I know this is a tricky challenge. However, various funding streams and projects don’t work in silos. So we’ve run into issues where we’d like to use ACs [attribute categories] to track funding, but some data reflects more than one funding stream.
A: PEPFAR has a complex way of handling “deduplications”, where part of the data is assigned to different projects. Sometimes the total numbers are less than the sum of the amounts claimed by each project (e.g., 100 people served, but one project takes credit for serving 50 of them and another project 75). PEPFAR has a de-duplication category option in which a -25 would be stored, to get the right total over all the category option combinations.
Q: Is it possible to also limit the users that a user administrator can modify?
A: Yes! PEPFAR uses a parallel set of user administrator groups and the “managed by” property of DHIS2 to do that.
Q: What about using the “Complete” button on data entry to indicate approval for that level?
A: The requirement was to implement approvals separately from completion. Form completion is a reported metric to indicate that a form has been fully-filled, whereas approval indicates that the quality of data has been reviewed, and approved by someone who may be different from the person responsible for form completion. It’s up to an implementation to determine at what level (or levels) data approval takes place, and that may not be the same level as data entry. Also, the data from several data sets may be reviewed and approved together.
However, if there is a need for approvals and completion to be related to each other in certain installations, let us know your use case, and we’ll look into it.
Q: I think I noticed that approvals only make data read only, but facilities that haven’t reported yet can still report. Is there a way to prevent that?
A: Actually, approvals lock all data modification and entry for a combination of organisation unit (and all organisation units under it), all data elements belonging to any data set in the approval workflow, a period, and a combination of attribute categories (if you use them). This prevents data from being changed within that selection, and also prevents new data from being entered.
If data is already approved for a regional organisation unit, and a new organisation unit is created under it, data will automatically be locked for that new organisation unit as well.
Q: An important functionality that is missing for us from the Approval app is to be able to see a list of what has been approved and what is pending approval. Has this already been implemented in newer versions of DHIS2? Are there any plans to implement this in the near future?
A: The built-in DHIS2 approvals app should be included in the DHIS 2.37 release in late 2021, but this feature may not appear until 2022. In the meantime, there are several implementations of approvals that could likely be customized for any installation, though that will require gaining access to their source code and also making an investment in modifying them for your installation.
Q: The approvals feature is designed to work with organisation unit structures where organisation units of the same kind are at the same level. However, in our system different districts have different structures. Is there any way we could set up approvals?
A: The traditional DHIS2 advice for creating the organisation unit structure is to keep all organisation units at the same level, but that doesn’t work in some installations. For instance, PEPFAR operates in a variety of countries, and they have different facility hierarchies, so the organisation units of the same type are not at the same level.
It’d be great to have documentation about your use case, and then we could look at possible solutions (perhaps using organisation unit groups?) and consider the level of effort to implement them.
Q: You said that the category option constraints apply to disaggregation categories as well as attribute categories. How does that work?
A: Oops—that was wrong. They just apply to attribute categories.
