OpenMRS DHIS2 Integration Progress

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

This specific talk thread is to coordinate the OpenMRS DHIS2 integration efforts on keeping up with the progress on work corresponding to the requirements. Anyone having any progress regarding the regarding OpenMRS DHIS2 integration corresponding to the requirements can post their updates as a reply to this thread.

2 Likes

I want to give an update on the work happening on the community recommended module and the progress:

I am working with Bob Joliffe and James Kariuki to work on Requirements 1 and 2 and 3.

This is the :Module Github Repo

Progress on Requirement 1: Should be able to generate ADX messages

  • [Done] We were able to generate and send basic(without disaggregations) ADX to DHIS2 successfully and this was even presented in the IHE connectathon by James and Bob.
  • [In Progress] We are working on a plan to implement the diaggregations. The main blocker being in ADX every disaggregation name needs to be an attribute name.

Progress on Requirement 2 and 3: Should use OpenMRS reporting module and Should Reduce the technical dependence on Implementations

  • [In Progress] We are working on consuming the reporting modules reports directly and to provide a mapping between the complete reporting module report to dhisreport. As we believe this will help implementations already having reports in reporting module can directly use them. Also this helps people not comfortable with SQL.

I’m excited to see that there is ongoing progress on this! Please do continue to share updates and ask questions here, and on OpenMRS design and developer calls. This is a big priority for the OpenMRS ecosystem!

One thing: please don’t only make the module work with using the reporting module, but create some more general interface to which the reporting module is one solution.

1 Like

@maurya, @vsingh, @vinay and myself were having a discussion about how to make the integration of OpenMRS and DHIS2 more simpler from the perspective of implementers. For ex:

  • Can the SQL queries be moved to a different level. As of now, it is in the template. If the SQL queries can be moved to another level, the implementers need not write SQL queries.
  • Can the queries be reduced or merged into few so that we have the data (reports) to be integrated to DHIS2 ready in lesser time

Also, the ways in which the current template can be made simpler taking into account that the data elements can be obtained using DHIS apis for mapping purposes, instead of putting them in the template beforehand. The idea is to make this module very generic for usage.

@maurya will be giving a short demo of the current work on 25th Feb. Any ideas around this topic would be really helpful.

Well done @maurya and team. Uganda cant wait to pre-test this integration. As a country we are using DHIS2 as the national reporting system and OpenMRS as the national EMR system, so this integration will enable automatic generation of reports in OpenMRS and have them pushed into DHIS2. This will be a great achievement and it will solve lots of issues at our Ministry of Health.

Thanks and am looking forward for more updates.

We are looking into an approach to OpenMRS - DHIS2 integration in Bahmni. We have looked into the current approach being followed in the module being developed in OpenMRS. There are few things where we would like to have a different approach with respect to the current module. Namely-

  • Having lesser number of SQL queries
  • Using output from the pre-packaged aka canned reports and transforming it to the data elements used in DHIS2 (these pre-packaged reports can be configured per deployment and they are tested for performance, correctness)
  • Reduce effort needed per implementation
  • We want it to be flexible too, so that people can plugin there own queries but we would like to reduce them to minimum

We are considering of below approach. Request to share your opinions or suggestions on this.

Consider the case where it is required to report HIV data (HIV tests, HIV tests positive, HIV tests negative based on age groups and gender)

Consider simple data for example-

encounter_id | encounter_datetime | concept_name |  obs_id | value_coded | age | gender
1                     2015-01-01                 ANC HIV Tested  1           YES                40     M
2                     2015-01-01                 ANC HIV Tested  1           NO                  50     F
3                     2015-01-01                 ANC HIV Tested  1           NO                  28     M
4                     2015-01-01                 ANC HIV Tested  1           NOT TESTED  38     M
5                     2015-01-01                 ANC HIV Tested  1           YES                 27     F
6                     2015-01-01                 ANC HIV Tested  1           YES                 39     M

The DHIS2 data model is represented below (also this represents the format for posting to DHIS2) -

{
  "dataSet": "dataSetID",
  "completeDate": "date",
  "period": "period",
  "orgUnit": "orgUnitID",
  "attributeOptionCombo", "aocID",
  "dataValues": [
    { "dataElement": "dataElementID", "categoryOptionCombo": "cocID", "value": "1", "comment": "comment1" },
    { "dataElement": "dataElementID", "categoryOptionCombo": "cocID", "value": "2", "comment": "comment2" },
    { "dataElement": "dataElementID", "categoryOptionCombo": "cocID", "value": "3", "comment": "comment3" }
  ]
}

So, we need to post the data in the above format. In the example we are considering, the data to be posted would look like -

{
  "dataSet": "pBOMPrpg1QX",
  "completeDate": "2014-02-03",
  "period": "201401",
  "orgUnit": "DiszpKrYNg8",
  "attributeOptionCombo", "aocID",
  "dataValues": [
    // repeated for : number of times = genders * number of age group
    { "dataElement": "ANC8153", "categoryOptionCombo": "g10n391n", value: "12"},
    { "dataElement": "ANC8153", "categoryOptionCombo": "h167n2", value: "1"},
    { "dataElement": "ANC8153", "categoryOptionCombo": "a199b2", value: "2"},
    { "dataElement": "ANC8153", "categoryOptionCombo": "m167n2", value: "1"},
    { "dataElement": "ANC8153", "categoryOptionCombo": "p267n2", value: "1"},
    { "dataElement": "ANC8154", "categoryOptionCombo": "g10n391n", value: "12"},
    { "dataElement": "ANC8154", "categoryOptionCombo": "h167n2", value: "0"},
    { "dataElement": "ANC8154", "categoryOptionCombo": "a199b2", value: "2"},
    { "dataElement": "ANC8154", "categoryOptionCombo": "m167n2", value: "1"},
    { "dataElement": "ANC8154", "categoryOptionCombo": "p267n2", value: "0"},
  ]
}

Query output from DB would look like this-

Number of tests done, Age Group (Code), Gender
6, 56, M
2, 56, F
4, 57, M
11, 57, F

To achieve this output we need to know the relations between DHIS2 data model and the data we obtained by querying. And, also the types of reports/forms to be submitted to DHIS2 need to be known. This is explained in brief below-

To map the data which we obtained by querying OpenMRS DB to data model of DHIS2, we need to know the mapping between elements in DHIS2 with Bahmni names. An example of this mapping would look as shown below-

type="category", id="f8n3o2n", maps_to="Gender"
type="category option", id="g10n391n", maps_to="M"

Also, we need to have a configuration for the kind of reports that need to be generated. An example of this configuration would be like-

{
	"data set": "pBOMPrpg1QX"
	"value column": "Number of tests done" //optional
	"canned report config" : {
		"type" : "Obs Count",
		"concept name" : "EILSA"
		"age group name" : "general"
	}
}

This is a simple example, but given that DHIS2 has fact/dimensions model, this can be applied for complex examples too.

1 Like

Hello @vvinay,

Thank you for taking the time to design a model for the features you mentioned. Though I could not completely follow your approach the main points I can see different from the current module are below

  • JSON : the current module does not support JSON, it supports DXF2 and ADX (Currently being developed).
  • Mapping to Bahmni Names: This need not be specific to Bahmni rather can be used for any names (I guess this is your suggestion as well)
  • Configuration: Why do you need the configuration file for the kind of reports?
  • DB Queries: How do you plan to get the DB Queries?(meaning will this be from the module or internally?)
  • Less Number of Queries: I did not understand how you are achieving this, can you explain it more in detail.
  • Flexible: I guess this ties in with less number of queries but, can you explain it more in detail of how this will make it more flexible.

So for these changes, do you plan to enhance the current module or do you plan to create a new module?

Hi @maurya,

To answer the questions you have -

Yes, it can be generic.

The idea is to have a configuration to identify the reports (or forms in DHIS) and the contents of them which needs to be populated. This is helpful in packaging the json which would be exported to DHIS.

This can be either from the module itself or from the reporting module.

Here, the thought is to reduce the queries and a have few composite queries which would give out all the data we want and subsequently extract the required items in the module.

It would be really useful and preferable if an approach can be taken to have a generic way forward in the existing module itself if it is agreeable. Please let us know your thoughts.

:thumbsup:

:thumbsup:

:thumbsup:

:thumbsup: I would encourage we have continuos design calls to further discuss how we can achieve this.

Excellent @vvinay, Looks good. And they really align well with what everyone wants to see this module at.

March update regarding this module development progress:

  1. Should be able to generate ADX messages (the module generated DHIS2 specific dxf2 messages, ADX is a more generic exchange format) 1.1 [DONE] Generate Basic ADX 1.2 [DONE] Submit ADX using DHIS2 Web API 1.3 [In Progress] Capability to express disaggregation explicitly as attributes (e.g. AGE_GROUP and SEX)

  2. 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 [DONE] Automate submission of reports created in OpenMRS reporting module

  3. Should Reduce the technical dependence on Implementations (the module requires users to write SQL queries) 3.2 [Done] Should be able to map an entire DHIS2 report to Reporting Module report

2 Likes

@maurya Is the module repo still https://github.com/hispindia/dhisreport/tree/shr?

Could it be this? https://github.com/openmrs/openmrs-module-dhisreport

as @dkayiwa mentioned it is https://github.com/openmrs/openmrs-module-dhisreport

@maurya I will be pinging you in 3-4 weeks to integrate the approval/edit workflow that we discussed at OpenMRS 2016 - I will flesh it out a bit more

1 Like

@maurya, @jamesm, hey, I’m sitting here with one of my ThoughtWorks colleagues, and we were wondering whether we can get some more regular updates about what’s going on.

Hi Darius, In the last few weeks we have been focusing on ADX Profile specification update, which will inform the next steps in updating the DHIS2 reporting module. I will touch base with @maurya to plan for a demo during one of the OpenMRS forums and also seek additional input. We are also updating the existing step by step guides that we will share soon. Regards, James

CC:

CC:

OpenMRS and DHIS2 integration and interoperability is very crucial. Thus it need an expert to give a clear step by step explanation in how it is being done between these two open source systems as well as in Bahmni-OpenMRS.

can any one exhaust this areas clearly