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

@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


Hi @raff, @ssmusoke,

This is my current state of almost the end of 2nd week. :neutral_face:

We were discussed in our last meeting to create the New Patient Registrations reports using cohorts. I spent many days trying to create this report through the reporting module UI. It seems that date_created of a patient is not possible to retrieve through the existing data definitions.

When I look at the rest of the reports, they are moreover to metadata than patient specific data. For all those reports, the default cohort which is All Patients is good enough.

Last week objective:

For the moment, I have these reports which were implemented through SQL definitions inside the referenceApplication module. Here is the Pull Request I made with the suggested modifications.

I will be so happy to see, if there is another possible way to get date_created attribute in the patient table as a data definition.

Regards, Jude Niroshan


Hi @raff, @ssmusoke,

Last Tuesday (13th-June-2017) we had the weekly meeting. We were discussed on the the work which I was doing in the 2nd week. Rafal had a look on the half-baked report which I created. He tried to help me to setup the demoreporting module in my local machine, but we couldn’t set it up as the provided metadata SQL file wasn’t compatible with the code.

Week 3 tasks:

  • Finish the New Patient Registrations report.
  • Write Unit Test coverage for that report. (I have already created that report through reporting module, currently I’m implementing it in java code)

Regards, Jude Niroshan

Hi @raff, @ssmusoke,

I have implemented the New Patient Registrations report using cohorts inside the referenceApplication module. I have also written the test coverage for that report. I made slight changes for package structure (may be new way would bring more clarity) . Appreciate your feedback. :grinning:

Here is the Pull Request -> https://github.com/openmrs/openmrs-module-referenceapplication/pull/43

Now I’m working on 'Number of visits’ report to implement it through cohorts (encounter) and write unit test coverage.

Regards, Jude Niroshan

1 Like

Hi Everyone!

It’s almost end of 3rd week of GSoC 2017 coding phase timeline (9 weeks left :grimacing: ). I have been working on this project since the day it was announced. @raff and @ssmusoke gave me immense support in many ways. Up to now, I have implemented the following reports (or rather components as @mseaton called it :wink:)

  • Number or Visits
  • Number of Patient Registrations
  • Number of Admissions/Transfers/Discharges per service area
  • Number of Visit Notes
  • List of Diagnosis’s made and quantity
  • List of Providers (grouped by active/retired)
  • List of Users (grouped by active/retired)
  • List of new Patient Registrations
  • Patient Visit Report (This has not done)

All these reports have implemented inside the referenceApplication module. All cohorts definitions, libraries and everything resides inside this module at the moment. We had a discussion over this few weeks back whether we need to move some potion of this to referencemetadata module or not. If we are going to move to referencemetadata module what sort of things needs to be take in there?

@mseaton @darius Appreciate any of your valuable inputs. :slight_smile:

Kind Regards, Jude Niroshan

@judeniroshan, moving all your changes so far to referencemetadata will be all what is needed. It should be quick.

I’m sorry for misguiding you about putting the code in the referenceapplication module, whereas it should go to the referencemetadata module as it was discussed in this thread above.

1 Like