I’m interested to work on Built-In Reports for Reference Application project which has listed as a GSoC-2017 project. I have went through the OpenMRS architecture and understood the basics of it. I have setup the local environment to do the development.
I noticed that this project has added to GSoC-2017 recently. I have been working with the OpenMRS-core and fixed few issues.
I have setup the platform in my local machine both ways.
Using my own Tomcat Server
Reference module platform (SDK)
I think for this project platform specific changes would not take place. As the project title itself says, this is related to reference modules. So, I created a basicmodule following this tutorial. (https://wiki.openmrs.org/display/docs/OpenMRS+SDK)
Question: I want to know whether this is going to be a new reference module or are we going to add new reports to the existing reporting module. If we are going to create a new module, what’s the reason that we do not want to improve the existing reporting module?
Question: Do I want to study on openmrs-module-webservices.rest thoroughly? If that so, I might need to allocate sometime on my timeline for the project as I’m not quite familiar with that module.
When we talk about fetching the data for these reports, we can use the existing module Reporting REST API module. Here is my approach,
Create some mockups and get verify the new reports
Study the reporting REST API module while keep an idea about the data structures I need for those verified reports.
If any development needs to be done from the REST API module, I will implement them.(obviously there would be new queries to be write)
Once the API is completed, I can complete the reports as mentioned in the project introduction.
Please advice me, if I need to look further on any other modules which I have not mentioned here. I’m almost done with my proposal. I will send it to you soon. @raff
In this thread, It has been communicated that ELS + Logstash will be used to collect and index the data. Then Kibana will be used to visualize the data.
By looking at this below thread, contributors have decided to write a OWA instead of using Kibana dashboard.
Is that correct?
However the data flow comes from the ELS and will be provided through Reporting REST API module. Therefore, necessary arrangements has to make from the Reporting REST API module to serve the data.
The reporting module is more of a framework module, so it defined
underlying queries but specific reports go in other modules.
They are evaluating kibana for reports, but that doesn’t mean it had
been chosen as the only way forwards, and the reporting module is also an
option for this project. (Right @raff?)
See also the documentation for the reportingrest module. (It’s on the wiki
of the github repo.)
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.
@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.
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.
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.
@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
It is my great pleasure to work on this GSoC project. 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:
Do we have any finalized user interfaces for reports? (Please share it with me, so that I can start working on those.)
Are there any similar OWA modules which I can have a look at?
What is the most preferable front-end framework for OWA module of this project?
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.
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.
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.
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.
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?
@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?
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.xopenmrs-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.
@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?
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.
@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
I have started from the setting up my local environment and 
