I’m looking for a way to create charts for reports produced by the reporting module. Would you create charts on the server side using JFreeChart (or any other open-source library) by implementing a report renderer or create them on the client side using some javascript library?
Do you have any preference for choosing one over the other?
Hey @raff,
If your requirement is to use the reporting module to produce data, and then render this data using charts to the web, then I think a WebRenderer that has it’s rendering logic in the html/javascript would be the best, particularly given there are some really good javascript libraries out there for this from what I understand. You could also elimintate the “Report” aspect entirely, and just use reportingrest web services to evaluate data sets, and then render that in your custom control.
Obviously, if your reports are Excel or PDF or some other similar format, then it would make sense to use a library that works within those particular formats.
Mike
Dump the data in ElasticSearch and use Kibana 
@raff I’d like to point out that the main advantage of client side generation of the chart is that it will not affect the loading time of a page to a great extent whereas server side generation might
IMHO this can be disadvantage because all the data must be downloaded to the client and take up a lot of bandwith. If the network is slow … Regarding CPU you’re right, it’s better in the client.
How about tooling, what open-source licensed products are available that are easy to use both for techies and non-techies, probably one that does not need to go to Google’s servers to bring back a chart. Interactive charts would be fun, though static ones are good to start
Assuming this is related to https://wiki.openmrs.org/display/projects/Built-In+Reports+for+Reference+Application, my gut is that we might want to provide some configurable widgets/controls that can be added to the reference application, where one of the configuration options is the dataset/report to run, and other configuration options are the type of chart, and dataset elements to use, etc. But this would be something different from the typical report rendering architecture. Other widgets would just allow for configuring one or more reports to expose (eg. display name and url), which would then either run the report synchronously and download the rendered report, or redirect the user to another page…
Mike
I also would do this client-side, using some charting library that’s built for the whichever JS framework is chosen for the project.
If you’re generating numbers as a dataset in the reporting module, the reportingrest module is perfectly capable of exposing them to a JS app.
Thank you all for suggestions! We’ll go with a javascript library and reporting rest to do the job.
@mseaton, yes, it’s the related project, which I should have mentioned.
@lluismf, I haven’t seen Kibana before, thanks! It’s not the best fit for the project I was thinking about, because we want something simple running within OpenMRS, but it’s a great suggestion for OpenMRS data mining. It seems like a decent alternative to Pentaho. Do you have any experience with that tool? Would you be interested in setting up some basic demo for OpenMRS? I’m very interested in pairing on that.
No, I don’t have any experience but a colleague from work is evaluating it and so far he’s very happy. In a couple of days he’s loaded milions of rows in ElasticSearch (from Oracle) using LogStash with no coding (just defining SQL queries to extract the info). Then he created several graphics with Kibana (maps included because the original data has geolocation). On top of that, searching is ultra-fast thanks of Lucene magic.
I don’t have much time but yes, I would be interested but I will need some assistance. As a minimum, an OpenMRS big enough, the data to be extracted (observations?) and graphs that make most sense.
@raff Would like hear what JS library you are using for charting and experiences with it to use as a baseline for a number of planned sections on the patient and clinician facing dashboards
I’m waiting 
This is a very exciting development. Will this be designed to be distribution agnostic, or is this intended for the Ref App?
@lluismf, let’s catch up early next week.
@mksd, the Built In Reports will be a GSoC project. We’ll do it as OWA so it will be distribution agnostic.
So I guess you would first provide a new REST API, some sort of ChartResource? … that would hold series of plottable data or tables of non-plottable data that could easily be consumed by front-end libraries?
@mksd, the plan is to use https://wiki.openmrs.org/display/docs/Reporting+REST+Web+Services to feed the charts.
@mseaton am wondering how far this has gone? we need to implement something similar in UgandaEMR, that is, displaying charts on a dashboard widget using data from the reporting module.
@solemabrothers I’m not aware of the current status of this. Perhaps @dkayiwa knows if this was completed?
@solemabrothers, many sites have moved from this approach to an approach of flattening data within a secondary datastore and performing analytics there. Some have created bespoke SQL queries to do the flattening (can require some large & hard to maintain queries) and, more recently, people have been looking to existing open source tooling (e.g., debezium and Apache tools) to flatten data. There have been successes, but many are implementation-specific solutions.
PIH created petl as an extensible approach to defining flattening & reporting queries in SQL in a standard way that can be run by an engine.
The Analytics Engine Squad was created by groups trying to solve this problem in a way that could benefit others and be extended by the community. AMPATH and Google built openmrs-fhir-analytics to extract data into a FHIR schema and use Apache parquet (columnar datastore) to tackle the calculation of indicators.
@mseaton, @allan, @bashir, and myself have been trying to move our community reporting discussions in 2022 toward sharing approaches across four areas: CDC, ETL, data store, and analytics. For example, most approaches have found debezium to be the best tool for CDC.
We’d love to get folks from UgandaEMR, NigeriaMRS, KenyaEMR, PIH, AMPATH, Mekom, etc. (all of whom are trying to solve this problem in different ways) to share approaches & coordinate efforts on reporting & analytics to reduce unnecessary duplication of efforts, increase awareness & adoption of new tools (debezium, Apache tools, etc.), and (hopefully) begin discovering the parts of reporting that can benefit from shared tooling in place of bespoke solutions.