Brief demo video of the DHIS Connector Module

Hi all,

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.

cc: @grace @jennifer @ibacher @dkayiwa @k.joseph


great work @jayasanka

1 Like

Thanks @jayasanka. Great job.

1 Like

You’re welcome. @achilep and @gracebish! :hugs:


awesome, could you move this to youtube?

1 Like

Welldone @jayasanka keep up

Uploaded to YouTube here - please share widely :smiley:

@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!

CC @burke @ssmusoke @paulamendola @ddesimone I think you/your teams will want to check this out - we’d love to hear your feedback!

1 Like

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?

For example:

OpenMRS is running a HIV/TB program, NCD and Mental health in multiple facilities and hosted in a cloud instance:

  • 5 Locations
    • 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.
  • HIV/TB
  • NCD
  • Mental Health

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.

THank you,


1 Like

Hi @jesplana,

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.

In that case, we can implement an UI to map OMRS locations with DHIS2 org units. So, we don’t need to do the mappings again and again.

Now the module knows how locations map with org units. Then we can add a new selector to select the relevant Org Unit Group.


1 Like

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).

1 Like

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.

1 Like

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)


I like this even better!


Much better! :100:

1 Like

@jayasanka How do I create the Period Indicator Reports on the OpenMRS side? i.e The report that you use to map with the one of DHIS2

If you could give a demo, that will be great

1 Like

Hello @kwebihaf

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.

You can follow this step by step guide on wiki Building Reports (Step By Step Guide) - Documentation - OpenMRS Wiki

Have fun :blush:

1 Like

Anyone hear about ONA’s use of FHIR to transmit aggregated data to DHIS2? Powering interoperability with a FHIR to DHIS2 adapter - Ona

1 Like

I hadn’t but that’s really great to see!