As some of you might know there are multiple implementation to integrate DHIS with OpenMRS and luckily, I was able to work with most of them. Presently, the most current working model is the DhisReport module. Originally developed by HispIndia, I had the opportunity to work with Bob Jolliffe last fall and was able to add new functionality including web services and update it for the current OpenMRS.
One of the major issues for having a solid DHIS Integration module is multiple disjoint efforts.
There is an interest to further improve this module in future as suggested by @darius. So, I would like to suggest that this module be included in the coming releases[Probably by including this in technical RoadMap] encouraging it’s adoption and streamline the efforts in our community towards DHIS Integration to this module.
If @paul , @burke , @sunbiz , @surangak, Bob Jolliffe, @r_friedman, @jamesm, @darius , Bangladesh Implementation Team and Philippines Implementation team (The people I am aware in the OpenMRS Community interested in DHIS integration, apologies If I forgot anyone) can comment on whether this sounds as a good way to move forward on our DHIS integration efforts.
I released the module recently and is available in the maven repository and also in openmrs modulus.
–Thanks and Regards,
Sri Maurya Kummamuru
I think integration with DHIS2 is important and relevant to a number of implementations. But I also think that it is not among the necessary functionality for an EMR distribution. I am assuming that you want it to be part of the 2.x reference application distribution, which is an out-of-the-box EMR and not necessarily a component of an HIE out-of-the-box.
Keeping it updated to work with latest OpenMRS platform and DHIS2 web API is required, but I think that can be done outside of it being bundled as part of the 2.x distribution
@sunbiz, I do agree that OpenMRS is an out-of-the-box EMR and not an HIE, but the modules that we bundle are not exclusive to an EMR functionality. They are the modules recommended by the OpenMRS community.
Like for example the Atlas module, Data Exchange module and Metadata modules and so on. These modules are not something that an EMR needs to have. The modules included are usually the ones that the community might believe beneficial and agree its adoption will help implementions not aware of the module.
Moreover, HIE is becoming an integral part of an EMR system and will soon be a requirement for EMR’s. And as per my understanding data exchange module is bundled for the same reason. Having a recommended DHIS2 module will help many implementation copying data manually as DHIS2 is implemented simultaneously with OpenMRS in multiple implementations around the world. This will ensure the module to stay current and updated.
I kind of see the dhis module as different from the Atlas, Data Exchange,
and Metadata modules.
They are more generic than a module that is specifically dealing with DHIS.
And my impressions of the reference app are the basic functionality one
expects in an EMR. Not necessarily every nice to have.
Every bundled module increases the size of the reference app, may affect
performance, or even introduce unforeseen bugs.
So there is a tendency to be extra careful at which modules we bundle.
May be in the future, but at the moment, i lean towards @sunbiz’s view.
But in the meantime, as you continue to push for bundling it, keep on doing
your best to ensure that it is under active development and support.
The good news is that, even if it is not bundled, one can always install it.
I agree with @sunbiz and @dkayiwa that we should not bundle the dhisreport module in the standard distro of OpenMRS.
But we need to get away from the assumption that “important modules,” “modules that we try to focus the community’s effort on,” and “modules bundled with the reference application” are exactly the same thing.
We should definitely spend design call time on the dhisreport module, and we should highlight tickets from it to get people to work on them. And @maurya, we’re counting on you to guide us in this.
Basically, we should include it in the technical roadmap, even though it won’t come out-of-the-box with a standard download.
Thanks @sunbiz, @dkayiwa and @darius for taking the time to make me understand. My intention was to get this into focus so that everyone interested on DHIS Integration can focus their efforts on this module. That is the reason for my request to include it in the bundled modules. In a way as @darius mentioned getting this into the technical roadmap might do the trick.
Oh hey! looks like i’m finally catching up on my email!
BTW, I don’t have a lot to add, other than we should probably try to determine how we’re going to encourage uptake of this approach among users. For example, if I google “OpenMRS DHIS2 module” I get quite a number of different pages. It might make sense to build a landing page (etc. “Connecting OpenMRS with DHIS2”) that introduces each option that’s currently in use, links to them, and explains why we’re now advocating this new module?
And also, we should probably starting using a JIRA project to make sure that more community members can get involved with the work?
Good suggestions as always thanks @surangak
It does make sense to have a common landing page and I will create the new landing page soon and there is a JIRA project request for dhisreport pending that I need to follow up on.
First of all, thanks a lot to @maurya for trying to push this good work forward.
I might have a unique vantage point into what is likely to emerge around DHIS2 and related applications in the standards space.
Currently, the module that @maurya is referring to connects to DHIS2 with a specification called DXF (DHIS exchange format), which is bespoke.
Many folks, including some of the original DHIS team, are participating in a IHE-endorsed, standards-based new specification called ADX (Aggregate Data Exchange). DHIS2 will have ADX support quickly after this specification becomes “real”.
My advice would be that we evolve the good work done in the DHIS2 export module into an “ADX export” module, which is by it’s very nature more generic and will support export of aggregate data to external systems.
This is the best of both worlds and a good strategic direction for the OpenMRS platform, IMO.
Just my $0.02.
@maurya to move this discussion forward would you be available to join a design call on any of the following days?
- Wednesday, June 3 @ 6-7pm UTC
- Wednesday, June 10 @ 6-7pm UTC
Both work for me @jthomas. June 3 might work best if I had to choose
I’ll put you down for June 3rd then.