Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
This is superseded by work on a Cohort Builder OWA
Lead: Darius Jazayeri
Participating Devs: Soldevelo Team
Past Participants: Glauber Ramos
When you want to get data out of an OpenMRS system, it is sometimes worthwhile to have programmers or advanced administrators design a very specific report or data export, such as might be run "monthly, for each clinic." But sometimes mid-level want to be able to do "ad hoc" analyses and exports, where they explore data and export it on the fly.
The Reporting Module provides powerful and flexible tools for Row-Per-(Patient, Visit, Encounter, etc) exports, however this functionality only has an administrative UI that is unsuitable for an end user.
The Reporting Compatibility Module has two key tools (Cohort Builder and Data Export) with friendlier UIs (though they are quite dated). Though these are used by many implementations, they are built on top of a deprecated query and export framework, and they are really past what should be the end of their useful lifetime.
The goal of this project is to build a tool that can be used by doctors and data analysts to do Ad Hoc queries and exports of data. These queries may happen in response to an on-the-fly question from a hospital manager, or in response to a specific suspicion or need that a clinician has to analyze certain data. We want to allow people to access the necessary data without needing a developer or advanced sysadmin to be a bottleneck in the process.
Specifically, we want to build a UI around row-per-domain-object exports for key domain objects (primarily Patient, Visit, Encounter, and Obs) that is suitable for users of medium sophistication.
We want to design the tool in a way that it can be used to query for domain objects matching certain criteria (like the Cohort Builder), and also to export details of the matching objects (like the Data Export tool).
The Reporting Module has a RowPerObjectDataSetDefinition base class (with implemantations for Patient, Encounter, etc), and under the hood we should be building instances of this.
The Reporting Module also supports the idea of "definition libraries" (see the AllDefinitionLibraries class) which include built-in and implementation-configured queries and data definitions. Rather than trying to give users full access to all of the primitive queries in the reporting module, we will focus on letting them access definitions encapsulated in these libraries.
Considerable initial work has been done on this tool already, in the reportingui module, but there is much left to do.
Further work is captured under the following JIRA epics:
The code is at https://github.com/openmrs/openmrs-module-reportingui. See all files and packages that have "adhoc" in the name.
The easiest way to test out this code is to: