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

@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

2 Likes

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

2 Likes

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

3 Likes

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

Hi @raff,

I made the PR to openmrs-module-referencemetadata. I have a minor change to be done for 3 or 4 test cases. Apart from that the reports which we were discussed have completed. I think it’s now time start working on exposing these reports to outside. Can you please point me where to start off with that? :slight_smile:

Kind Regards, Jude Niroshan

@judeniroshan, as discussed let’s try to expose a simple metric with one number e.g. NumberOfAdmissions by writing a react component communicating with reporting REST. Since there’s no OWA generator for React yet, please create a regular React project by following https://facebook.github.io/react/docs/installation.html Next add manifest.webapp e.g. https://github.com/openmrs/openmrs-module-metadatamapping/blob/master/owa/app/manifest.webapp to make it an OWA, which you can upload as a zip to be served by OpenMRS via the advanced administration page as explained here https://wiki.openmrs.org/display/docs/Open+Web+Apps+Module.

Do not worry about styling yet. The goal is to run the report and fetch the result via REST.

1 Like

Thank you @raff for your support.:blush: I have made another PR for reference metadata module. That includes the remained test coverage.

I have created a new OWA in my github account. I am currently working on fetching a report through Reporting REST.

Regards, Jude Niroshan