Reference Application 2.7 - Simplifying Reporting Module - Documentation, Pre-built Reports, Higher Level Abstractions

Continuing the discussion from Should I use Bahmni Reports or the OpenMRS Reporting module?:

I am opening up this new thread, as the simplification of the reporting module is one of the deliverables in Ref App 2.7.

@mksrom What features, additions to reporting would you like to see to improve your usage experience?

@mseaton What do you see as the key areas for improvement, missing pieces that would improve the usage experience?

@dkayiwa @aolaniran @reddberckley, @fortune, @femi, @ethan, @enahomurphy - what do you see from your Cohort Builder experience?

@k.joseph What do you see from your work with the DHIS2 integration?

@raff @judeniroshan from your work on the pre-built reports for GSOC 17


Hi @ssmusoke, here is some remarks/ideas around the Reporting module and reporting in general. Hope this will be useful.

I havenā€™t gone far in Reporting module at all, I am still at the surface so I hope I wonā€™t sound like criticizing too much. It looks very powerful to me and I am confident I will get the results I want with it. Here is what I could see being improved from a fresh eye.

  • From a developer perspective, a developer documentation :slight_smile:

  • From an implementer perspective, an updated user/implementer documentation. I would like to see as an example how to create a monthly report that shows each visit details: one line per visit, with patient ids, patient attributes, visit type, observations (such as chief complaint, diagnosis). This kind of reports is a requirement we always get from clients. Maybe the examples could be shipped in a module too? And provided by default in the Ref App? There is already step-by-step examples in the current doc but they seem old. The section titles donā€™t match. And the Row per domain example returns an error for me (tried on the demo server). Also the format of the tutorial does not make it easy to follow. The table format displays the screenshots very small, so it forces to click on it and check what is the values to enter.

  • From an implementer perspective again, it would help to have more documentation right into the UI. Something like when I hover or click on a data set definition type for instance, it shows a description of what it is. It is not obvious to know what is ā€˜EvaluatableDataSetDefinitionā€™, ā€˜RepeatPerTimePeriodDataSetDefinitionā€™ and so on. What kind of output it can produce for instance. This could be applied to the sections as well.

  • Also better consistency of the terms. Some dataset definition types are camel case, some are dash separated words, some title case. Also some terms end by ā€œDatasetā€, some other by ā€œDataset Definitionā€. All this can add to the confusion.

  • One thing is also unclear at the very beginning is what can be done through the UI and what has to be done using code and custom modules. This is still unclear to me right now.

Hope it helps.


@mseaton there is someone in the community who would like to take on the role of Documentation Lead. Do you think she can be of help to you in regards to the reporting module documentation? cc @jwnasambu

@dkayiwa, help is always welcome. Just starting to get things better organized and laid out would be a great initial contribution. The actual content would be best filled out by those who have either developed the functionality or who have experience using (or trying to use) the module as an implementer.


I agree a proper documentation and workflow enhancement is critical. I second your suggestions @mksrom.