OpenMRS as a community to help implementations around the world recognizes the need to have a common/generic DHIS2 integration module. There have been lots of DHIS2 integration efforts in the community and there are many new ongoing efforts. In an effort “to do it right”, we have decided to focus on improving a preexisting working Dhisreport module.
DHISReport Module is the Community recommended DHIS2 integration module. But, we do not discourage other efforts to integrate OpenMRS and DHIS2.
People interested in knowing/contributing to these topics can refer to these threads.
This specific talk thread is to coordinate the OpenMRS DHIS2 integration efforts on coming up with requirements. Anyone having any requirements regarding OpenMRS DHIS2 integration can post their requirements as a reply to this thread. Please try to continue the Requirement Number for future reference.
The requirements are for this module are as follows:
Should be able to generate ADX messages (the module generated DHIS2 specific dxf2 messages, ADX is a more generic exchange format)
Should use OpenMRS reporting module (So that many implementations using OpenMRS reporting module could directly use this module to send their data to DHIS2)
Should Reduce the technical dependence on Implementations (the module requires users to write SQL queries)
Should Integrate with DHIS2 Web API (the module presently uses an XML import to learn about the indicators in the DHIS2 system)
@pascal, Yes I am aware of the module and it is one of the reason I started this talk thread series. But I am not familiar about it’s goal, plan or roadmap. If you or @k_joseph could post them here it would be really helpful:
The Jembi’s DHISConnector module posts OpenMRS Period Indicator Report data to DHIS2 using the Reporting Rest module, Mappings between Period Indicator Reports and DHIS2 Data Sets can be generated via a drag and drop UI. Currently the module only generates DXF files but there’s a TODO to get it to generate ADX as well
Including a little more granularity in the requirements to make them seem like tasks and track them:
Should be able to generate ADX messages (the module generated DHIS2 specific dxf2 messages, ADX is a more generic exchange format)
1.1 Generate Basic ADX
1.2 Submit ADX using DHIS2 Web API
1.3 Capability to express disaggregation explicitly as attributes (e.g. AGE_GROUP and SEX)
Should use OpenMRS reporting module (So that many implementations using OpenMRS reporting module could directly use this module to send their data to DHIS2)
2.1 Automate submission of reports created in OpenMRS reporting module
2.2 Have a Rest EndPoint in DHIS2 Report Module to output results generated by Reporting module
Should Reduce the technical dependence on Implementations (the module requires users to write SQL queries)
3.1 Should be able to reuse SQL statements
3.2 Should be able to map an entire DHIS2 report to Reporting Module report
3.3 Should be able to map elements of DHIS2 report to elements(indicators and dimensions) of Reporting Module report
3.4 Should be able to mix SQL statements with Reporting module Elements with SQL elements
Should Integrate with DHIS2 Web API (the module presently uses an XML import to learn about the indicators in the DHIS2 system)
4.1 Able to Consume DHIS2 report metadata using DHIS2 WebAPI.
4.2 Should be able to test the connection of DHIS2 server details
4.3 Should be able to verify if Locations (OpenMRS) are mapped properly with Org Units (DHIS2)
4.4 Provide an Option to choose between Dxf or ADX while trying to export data to DHIS2 in UI
I’m late to this conversation, but have some ideas:
I would focus on sending data across in ADX format. Most importantly, I would make sure to get the metadata for the ADX standard using the DSD or schematron template (see Readme).
One way to use the OpenMRS reporting module would be to provide a user interface to map the reporting module’s headers to the DSD template. So, the user imports the DSD template from DHIS2, creates their report in the OpenMRS reporting module and would be able to map the columns between the report and the DSD template.
I’m working on the MOTECH platform now. We have been supporting posting DHIS2 datasets since DHIS2 v2.15. They have restructured their WebAPI numerous times since then, requiring that we modify our module code each time they release a new version. For example, there was a breaking change in 2.19, 2.21, 2.22 and now 2.23. Make sure the module is flexible to be able to account for changes as DHIS2 changes their webAPI.
Is this requirement something different than requirements 3.2 and 3.3 listed above? Just the explicit statement that there should be a UI to do this? Hopefully we can improve on my initial attempt here.
to