We, the COVID Squad of OpenMRS have fixed the incompatibilities of the Connector module and decided to come up with a brief demo video to send around implementors to show that the DHIS Connector module is working again and to demo its core functionalities.
Here’s a video I’ve created as an initial step. Please have a look and let me know your suggestions.
@jayasanka this is so awesome!! Fantastic work. You made this video so fun, told a clear story, and showed how we’re addressing the real pain-points of implementers. We can’t wait to share this with the community at the Squad Showcase this week!
Hi @jayasanka, great work and thanks for the demo. I see that you’re manually assigning an org unit to a dataset. What happens if you have hundreds of org units assigned to a data set?
Can you assign it to an org unit group that automatically maps the location in OpenMRS to an org unit in DHIS2?
OpenMRS is running a HIV/TB program, NCD and Mental health in multiple facilities and hosted in a cloud instance:
Location 1 is running all 3 programs
Location 2 is running HIV/TB only
Location 3 is running NCD and Mental Health
Location 4 is running Mental health only
Location 5 is running HIV/TB and NCD
In DHIS2, you have 3 Datasets:
HIV/TB - assigned to Location 1, 2, 5
NCD - assigned to Location 1, 3, 5
Mental Health - assigned to Location 1, 3, 4
Normally in DHIS2, the org unit hierarchy would be setup this way:
Location # - [Type of facility]
Location # - [HIV/TB]
Location # - [NCD]
Location # - [Mental Health]
Then we’d create an org unit group for:
Type of Facility - i.e. Hospital, PHC, etc.
The when creating a data set in DHIS2, the implementer can assign it to the HIV/TB group and all locations in the HIV/TB group will have this data set assignment.
Extremely sorry about the delayed reply. I think your suggestion is a valid point. It’s painful to select org units again and again, and potentially leads to unexpected results because there’s no validation.
This is how I understood your example, correct me if I’m wrong.
I would rather have an explicit option for All Org Units rather than just implicitly assuming it. Also, it might be worth looking into if we can make the org group a multiselect box (assuming it isn’t already).
This is a really nice solution proposal @jayasanka, and sounds like it will address @jesplana’s pain points above. Thank you @jesplana for pointing out this pain of having to map the locations - that does indeed sound painful!! Do you have any questions or feedback on Jayasanka’s proposal above, to effectively give you a mapping UI for locations, so that you don’t have to map them manually every time you generate the report data?
@ibacher I think you’re describing something like this, right? (Forgive my terrible mockup.) That would address some of the pain, but I don’t think that fully addresses the problem, because the user would still have to click through these mapping options every single time they generate the data.
I don’t think that’s exactly what I meant. First, I really like Jayasanka’s proposal. I think it solves a real problem in a pretty elegant way. My only real problem is on the “Create Mapping” screen having a box with no selected org unit automatically meaning “All org units are selected”. I think that that behaviour violates expected behaviour. I suppose the other way to work around my objection is to relabel that box “Limit to DHIS2 Org Group” or something along those lines.
I went through the DHIS2 Dataset API, the payload contains the orgunits list of a dataset. So we don’t need the following option to have org unit groups.
Since we have the mapping (the proposed map UI page), now we know what OMRS locations should be run in the report and no need to bother user to manually pick them. If the dataset mapped with multiple locations, it will run reports for each location and send data to DHIS2 once. So, the run report UI could be changed like this, (same can be applied to schedule option too)
There are actually a few ways to create period indicator reports but the easiest way would be to just create a cohort query first and then creating the period indicator report on top of that. But if you wanna learn the entire thing inside out you can even create an indicator and a dimension for the cohort query by yourself and then build the report with those metadata.