[GSoC-2017] : Built-In Reports for Reference Application

You can also look at https://issues.openmrs.org/browse/RA-1257 which is where a number of predefined reports have been described based on demo data. I am collecting more sample reports and I am happy to add to this list.

This would also be an opportunity to define “starting” infrastructure for users to build both patient dataset and indicator reports.

Thanks @judeniroshan for your interest in the project!

As Darius said we are evaluating Kibana, but it is not intended to be used for the GSoC project. Kibana is a tool, which could be interesting for bigger implementations, but it is an overkill for simple reporting, which we want to introduce in the GSoC project. We will use the reporting module, which is perfect for that.

We will create a new module, which will contain reports for the reporting module and provide a homepage app (implemented as OWA) to display results in Reference Application UI. The app will use the reportingrest module to fetch results.

@ssmusoke, thanks for sharing RA-1257. Please do add to that issue your suggestions. We will try to implement as much as possible of what is outlined there as part of the GSoC project.

I’ve updated the GSoC project page to include that issue.

@raff I know that this is lot to ask, but will you also be looking at using the pre-configured reports as the best practices for setting up the reporting functionality for an implementation? If so a combination of a patient data export and indicator report would be sufficient so illustrate how to start.

Hi @raff,

I have submitted the proposal through the GSoC official page. Please have a look at it. I know it might not be perfect. Highly appreciate your feedback. :slight_smile:

Kind Regards, Jude Niroshan

Hi @raff,

Do you have any finalized UI mockups? So that I can include those in my proposal to make it more clear. I couldn’t find anything on talk or wiki. Sorry if I have missed them.

Regards, Jude Niroshan

@raff This is to inform you that I have submitted a proposal for this project . I’m sorry I couldn’t create the proposal soon enough for you to review and give me feedback. Actually I hadn’t noticed this project until recently. I remember being part of the discussion where this project was being chosen for Gsoc here and was interested but it slipped my mind as it was not part of the Gsoc wiki page initially. Moreover I also had my exams going on so I was a little short on time :slight_smile:

Hi @raff, @ssmusoke,

It is my great pleasure to work on this GSoC project. :blush: I have started from the setting up my local environment and writing blog posts since last week. I will be continue to using this thread to communicate with regard to any project related questions and clarifications .

I have few questions for you:

  1. Do we have any finalized user interfaces for reports? (Please share it with me, so that I can start working on those.)

  2. Are there any similar OWA modules which I can have a look at?

  3. What is the most preferable front-end framework for OWA module of this project?

Regards, Jude Niroshan

  1. No, there are no UI mockups yet. I imagine we will want to have a customizable dashboard with a number of widgets presenting different report results.

  2. Let’s clarify our conventions. OpenMRS Open Web App (OWA) is not an OpenMRS module (OMOD). The easiest way to distinguish the two is that a module contains Java classes, whereas OpenMRS Open Web App does not and consists of htmls, css, js files, basically only front-end stack.

To answer your question we have a few OWAs already: https://github.com/openmrs/openmrs-module-metadatamapping/tree/master/owa (this one is embedded within a module) https://github.com/rkorytkowski/openmrs-owa-conceptdictionary (this one stands on its own) https://github.com/openmrs/openmrs-owa-cohortbuilder (same as conceptdictionary but in React)

We’ll follow the metadatamapping approach i.e. embed OWA within a module, because we’ll need to write some logic in java as well.

  1. The easiest way is to use AngularJS 1.x or React, because others have used it already in OpenMRS. For AngularJS there’s the openmrs-contrib-uicommons library available with basic OpenMRS components like header, translation, authentication and web services. I’m okay with going with that or React. I wouldn’t go with Angular 2+, because we do not have any OpenMRS code using that yet and we would have to figure out everything ourselves.

@raff i like your strategy! :smile:

Regarding writing some logic in Java, how about doing that in the reportingrest and webservices rest modules such that you have a fully standalone OWA? :slight_smile:

@dkayiwa, we will still need to create and distribute some sample reports somehow. I think it would be easiest to do that using a reporting java api. My understanding is that reportingrest module is capable of running reports, but not creating them. It seems to be a rather significant undertake for us to add such a capability to reportingrest. @mseaton, @darius, am I right?

Hi @raff, @ssmusoke,

Thanks for answering and clarifying those questions. So, let’s stick our weekly project update meeting on every Tuesday at 13:00 UTC.

I have actually saw those 2 owa projects and these two are written 2 different JS frameworks. openmrs-owa-conceptdictionary - AngularJS 1.x openmrs-owa-cohortbuilder - ReactJS

I actually started to write a new owa with ReactJS following openmrs-owa-cohortbuilder then I found that they haven’t used the openmrs-contrib-uicommons UI library which is available on npm repository. I had a problem where owa generator has a bug on AngularJS owa creation. That’s why I shifted to ReactJS. I will move back to AngularJS and appreciate if you could tell me how to resolve this issue. :grimacing:

@raff The reportingui module already provides a way to show different reports on its home page which is done through an app definition - so why would one build a different OWA? If the reports are built in code then its just a matter of displaying them.

My understanding of this project is to get sample reports built within the reference application module.

@raff, it’s a good question. One thought is to consider whether the reports themselves actually might be suitable for inclusion in the referencemetadata module, since they will likely depend on metadata defined there, and would be specific to the refapp. Then, build out the UI components that are able to provide certain rendering capabilities, given a certain type of report definition. This would allow implementations who want to add their own reports in to leverage all of the great UI capabilities, even if they don’t want to use the built-in reports as-is.

Another thought is to piggy-back on the already existing reportingui module, which is presumably where we always intended to build out more extensive refapp reporting functionality. @darius?

Thanks, Mike

1 Like

The approach we’ve been taking in cohort builder is that all of the underlying queries should actually be generic and therefore we are defining them in the reporting module, and we’re defining them in these (new) “definition libraries” that I haven’t had a chance to really write much about yet. See example.

So, we might be able to define the underlying queries for these reports in a module like emrapi. For example if we were going to have a “top 10 diagnoses during time period” report, this definition could go in emrapi. If it does require specific reference application metadata it could go in the referencemetadata module (but since the refapp is really a base, rather than an actual implementation, I hope we can avoid this).

The other thing is that you don’t need to create a “report definition” in the database, but instead we can put dataset definitions in a definition library (which is defined in code).

And +1 to Mike’s suggestion that instead of a “report” per se you focus on building individual UI components that can be reused across different distributions.

First meeting with the mentors went well. So, as @raff asked me to first try out to create those intended reports through reporting module UI, I have created a report.

Inputs: Start Date, End Date, Location Output: Number of visits

@raff Am I doing what you have asked me to tryout in this week? (I’m afraid that if not, I am not on track)

There are 8 more reports that needs to be created. I am working on those right now.

Regards, Jude Niroshan

Yes, it’s precisely what we want to start from. Once you are done with that let’s set them up in java code in the referenceapplication module.

1 Like

@judeniroshan - now that the SQL works, how about using one report of the Cohort Definitions to achieve the same, this will speed up your transition to Java Code

1 Like

I tried but I couldn’t make any reports with cohort definitions. I was not able to complete the Patient Visit Report. Rafal told that it was okay, and let’s keep it to the end. Today we had the weekly meeting for GSoC project.

This week task is to implement those reports through java code. inside the referenceApplication module.

Hi @raff & @ssmusoke,

Here is my current status in brief.:slight_smile:

Things completed:

  1. I have created the reports through the reporting module user interfaces using the SQL data definitions.
  2. I have implemented those reports inside referenceApplication module still using the SQL data definitions. (github fork repo: modifications)

Things not completed:

  1. Implement reports using cohort definitions.
  2. Implement the Patient Visit Report (last report in the planned report-list)
  3. Couldn’t resolve the test failure.

Best Regards, Jude Niroshan


Hi @raff, @ssmusoke,

Thanks for coming for the weekly meeting yesterday.:grinning: I was able to solve the above mentioned test failure. Now the module builds without no exceptions. Here is the Pull Request I made for my last week work:

This week task: Implement the selected reports using cohorts. Try to write test overages for already implemented reports

Best Regards, Jude Niroshan