GSoC 2021: Improving functionalities of DHIS Connector module

Hi, I’m interested in the “Improving functionalities of DHIS Connector module” project listed under GSOC 2021 project ideas.

The objectives and goals of the project were not mentioned on the wiki page. Some objectives were discussed in the previous covid squad meetings and separate threads. So this thread will be used to gather information and also for further discussions on the project.

First of all, it’s better if we can find out how many users we have for this module currently. I checked the module details in the openmrs add-ons page 2021-02-04T18:30:00Z and it showed that there are 11 downloads in past 30 days. Maybe all those are just our developers.

If we have any users, we can use a questionnaire to gather the new objective. So please let me know if there’s a way to find how many users that use the DHIS connector module.


As I found from the previous discussions, most required functionalities are as follows:

  1. Location mapping feature
    I found a very detailed description for this done by @jayasanka here: Implementing functionality to map Org Units in DHIS Connector module. Basically, we need a way to map the openmrs org units with the DHIS 2 org units. In the current version, we have to map it manually every time.

  2. Controlling User Access
    We need to add role-based permissions for the module. (Ex: allowing only data manager/data assistant roles to push data). In the current version, any user with any role can push data to the dhis2 instance.

  3. Extending period support
    We need to support all the period types available in DHIS2

  4. Fixing UX issues
    In the dhis connector module pages, there are some buttons and checkboxes that users may not understand properly. (Ex: Automation view). Those issues needed to be fixed.


The following requirements were also discussed in the previous covid squad meeting.

  1. Optimizing the Module
    Need to increase the performance of the module by optimizing the processes.
    Todo: do further research on this

We can optimize the process if we can use the relative period types in DHIS2. But have to find a way to use the API with relative datatypes. In the documention, it says that relative datatypes can be used with analysis modules. I couldn’t find enough details on that. So i posted in the the dhis2 community telling my issue.

I hope someone will respond soon and I’ll put the updates on that here.

Still have no update on relative period types.

Here are some UX issues i found in the dhisconnector module. Some are minor issues. I have added the solutions i thought, along with the descriptions.

Automation UI

  1. In the Automation UI, a tick box is used to enable/disable Automation option. But after changing that, the user always have to click the submit button with the data table to save it. Users may confuse with this. (If someone has accidentally changed something in the data table, the submit button will save those also.)
    Solution: adding a separate button for the toggle automation option with a label to show the status

  2. The mapping table in automation UI has 2 run options. One for the first run and the another one for the “Re-run” option. The “Run” option only works in the first time.
    Todo: Find if there’s a specific reason for use 2 options to run and re-run

  3. Delete mapping option is also given as a tickbox. So the user has to click it and click the submit button again to delete successfully.

    Solution: add a feature to remove mapping one by one

  4. Users have to select org units every time
    Solution: Integrate with the location mapping feature

Configure DHIS server UI:

  1. In Configure DHIS server interface, there is no way to find out whether the server is configured(and connected) correctly. It automatically saves the configuration in the first time. But if the DHIS2 instance is not accessible afterwards, the module will throw errors.
    Solution: adding a label to display the status of server

Hello @akshika47 , Would you like to mentor this project?

1 Like

@piumal1999 yes, I would like to. Thank you for the tag.

1 Like

I checked the existing database used in the DHIS connector module to design the location mapping feature and the rough sketch of it (existing DB) is as follows: dhis (Location table is already in the main DB of OpenMRS)

For the new location mapping feature, we need to update this to store the mapping of location and org_unit. So I designed a rough sketch for the DB we need for the new feature. We have an one-to-one relationship between the orgunit and the openmrs location. Even if we could add the org_unit_uid column to the location table, it’s better to use a different table since this is a different module.

PS: Seems like my idea was completely wrong. I found that the db i mentioned was only used to store the scheduled mappings with their org units and location. We don’t need to update it in the first phase of introducing the location mapping feature. I couldn’t find the way they use to store the mappings with data sets yet.

UPDATE: It just saves the mappings as JSON file without keeping it in the database and stores just the name of mapping in the database

1 Like

the mapping and api json files are stored on the file system and the database just tracks mappings.

Do you have any reasons for changing this arrangement at this point in time?

1 Like

Hello @k.joseph

Yeah. The dataset mappings are saved in the file system itself. So we can just keep this arrangement as it is. The mapping and api json files won’t be changed.

What I thought was, we can use either the file system or the database to store location mappings (mapping between openmrs locations and dhis2 org units, which is to be implemented during this project).

If we use the json file to save those, we can keep the omrs locations and dhis2 org units same as in dataset mappings.

If we use a extra table to save location mappings, we can set the 1-to-1 location relationships as in here and anything else won’t be changed:

Which one do you prefer?

Hi everyone,

I have submitted my draft proposal for this project (Improving functionalities of DHIS Connector module) via the GSoC dashboard. So, please take a look and let me know what you think of this draft. I’d be glad to receive your comments & suggestions.

Thank you!

cc: @akshika47 @k.joseph @jayasanka @grace


Thanks Piumal! Are you comfortable sharing your draft here on Talk? That way others who don’t have access to the GSOC dashboard will be able to review :slight_smile:


Oh right.

Link for the proposal: Improving Functionalities of DHIS Connecter module - GSOC Student Application and Proposal - Google Docs

Thank you

1 Like

I noticed that contains the current implementors of OpenMRS and their contact details of OpenMRS. I hope to contact them and gather information about their demand for DHIS Connector Module.

And @grace could you please let me know if there’s any other way to find the openmrs implementors who might not have been listed in the OpenMRS Atlas.

In the meantime I’ll try to contact the local health institutes to check if there’s a possibility to test the module using their data.

Does this critically affect your GSoC project?

It’s not a critical thing. But i think it’s better to have. What do you think @akshika47 ?

Finding OpenMRS-DHIS2 deployments or ones who wish to deploy/use is not a critical segment of the project (was not in the proposal as well). But I think it is a good way for us to contextualize the development of the module and even to find out the nuance requirements of real deployments.

We tried this last time as well but was not that successful as far as I know (correct me if I am wrong @jayasanka, @grace).

Considering @k.joseph’s comment, I think we should do this carefully staying within the original project’s scope. Having said that, for us to have a discussion with one of the implementors later down the project timeline, we need to start early. Hence putting the word out early as possible is a pragmatic approach.

I am open to suggestions/counterarguments.

1 Like