Packaging OpenMRS reports

We continued this discussion on how to share report definitions (e.g., for packaging) in an OHRI call today and I thought it would be good to surface for the community:

This specific use case for OHRI could be solved with the ability to share cohort definitions; however, given that’s a work in progress, it would help if we had a shared vision on how to package reports to be shared across deployments.

What do we think are the best approaches for short & long-term approaches for sharing report definitions? Are PIH or other implementations already sharing reports across systems in a way other than bespoke modules?

/cc @mseaton @mogoodrich @ibacher @samuel34 @eudson @mksd

1 Like

I can tell you what we did, and this is clearly a technologically disappointing situation coming from Mekom :roll_eyes: but that happens to work well enough.

We decided to bundle all reports into one module, named Common Reports, and those reports can be entirely ignored if they are irrelevant for a given implementation, see here.

This works of course, since it’s all bundled in its own module. The “vision”, if any, is that this module could become a shared repository of reports over time, maybe beyond Mekom. Most of those reports would never be toggled on at the same time on a given OpenMRS instance since they are too specialised (for example Cambodia MOH reports vs Haiti MSPP reports).

This was our quick and dirty way to not handle over the years what this thread aims at addressing.

To be honest, at Mekom we rather focus on efforts on doing ETL analytics in a reusable and scalable fashion (with Apache Flink and Apache Superset for example). The Reporting module’s reports are very often context-specific for super narrow use cases and we didn’t feel so far that we would invest otherwise than on keeping expanding Common Reports.

Happy to open a new chapter if it’s worthwhile of course.


@burke the thread you copied in from Slack has links that I provided to Github that show how PIH is doing this via standard reporting module capabilities and configuration installed in to the application data directory, not via a bespoke module. It’s just that this functionality is currently still somewhat limited and not well documented. But it’s not bespoke.