Overview
The Reporting Module was designed to provide a feature-rich and user-friendly web interface for managing reports within OpenMRS. In addition, the Reporting Module provides a flexible and extensible API that module developers can develop against to build their own reports and tools. The core idea behind the Reporting Module is to provide a solid foundation so that other developers can use the framework to implement new features.
Difference with Reporting Compatibility.
Right now reporting compatibility is used to bridge the gap between the old and new e.g. cohort builder, data exports. This reporting module has a lot of the core features for evaluating parts of a report but doesn't have a good UI yet for designing a full report. Cohort builder is probably best for adhoc querying unless there's something in there that isn't supported then you'd have to use the cohort query editor in the reporting module. Data exports can only be designed/exported using reporting compatibility. There's a feature in this module that let's you define some simple dataset definitions like a SQL-based dataset but we ripped out a lot of the other ones we were working on. So this module and the reporting compatibility are complementary at the moment.
Release Notes
Getting Started
Downloads
We encourage all OpenMRS users and developers to download the module, use it frequently over the next few weeks, create new tickets for bug fixes and feature requests, and send us feedback.
Download Now
reporting-0.4.1.3.omod (2.2MB)
Requires
OpenMRS 1.5.2 or higher
Required Modules:
HTML Widgets 1.5.5
Serialization XStream 0.1.8.1
Recommended Modules:
Reporting Compatibility 1.5.0.3
Disclaimer
The Reporting Module uses the OpenMRS Serialization API to serialize/deserialize reporting objects to/from the database. One disadvantage of using the Serialization API is that it can lead to incompatibility issues (e.g. broken reports) if the API classes are changed in a certain way.
Therefore, we cannot guarantee that all reports that you create with the Reporting Module will continue to work in subsequent releases of the module. However, we will do our best to mitigate the risk and avoid compatibility issues, or provide means to upgrade/migrate your reports gracefully.
Javadocs: javadoc-reporting-0.4.2.zip
View source code: http://source.openmrs.org/browse/Modules/reporting/trunk
Download source code: http://svn.openmrs.org/openmrs-modules/reporting/trunk/
Installation
To install the Reporting Module 0.4.x, download the Reporting Module .omod (above), along with its dependencies (see box above) and upload them into your system.
Upgrade
To upgrade from Reporting Module 0.3.x:
- Check to make sure that you have all of the Required Modules installed on your system.
- Double-check to make sure that you have all of the Required Modules installed on your system.
- Log into OpenMRS
- Navigate to Admin > Manage Modules.
- Click the trash icon next to Reporting 0.3.x to remove the module from your system.
- Click Upload the Reporting Module 0.4.1.x.omod to your system.
Privileges
In order for users to be able to run most reports, you need to put them in a group with the privileges:
(this is accurate as of 0.4.1.2)
- View Reports
- Run Reports
- View Patient Cohorts
- technically this is only required if you want to be able to run reports including cohorts of patients, which is basically all reports
- (up until 0.4.1.1) Manage Scheduler
To be able to edit and configure reports, you need:
(this is accurate as of 0.4.1.3)
- Manage Reports (this just enables you to see the menu items)
- Manage Report Definitions
- Manage Data Set Definitions
- Manage Indicator Definitions
- Manage Dimension Definitions
- Manage Cohort Definitions
- Manage Report Designs
You also need to grant View privileges related to the base objects your reporting definitions use. For example you need "View Programs" to create and use an "In Program" Cohort Query
Tutorials
To help get you started with the Reporting Module, we have put together a few screencasts.
- How to define a new Simple Report
- How to define a new Cohort Query with a parameter
- How to define a new Cohort Indicator (and map it to the underlying Cohort Query)
- How to break indicators down by dimensions like sex and age
We have also put together a few How-To guides:
Parameters
Pre-defined parameters:startDate, endDate, and location.
Self-defined parameters: you can include the parameters in sql queries by using the notation of :parameterName. For example, you can set up enrollment date by using :enrollmentDate in your sql statement. Remember to choose the correct data type. In this example, the data type should be date instead of string. If not, the program will treat it as a string instead of date. You won't get a date picker for this field as well. Also, those parameters *cannot* be part of the SELECT statement. Instead, they should be used in the WHERE clause.
Developers
This release is our first stable release of the Reporting API. We have designed what we consider to be the basis for all of the APIs needed for the reporting. We feel very confident that the classes and interfaces designed will allow you to use and extend the API to:
- Define new cohort queries to allow users to calculate a custom metric that is specific to your organization.
- Define new data set definitions to expose data sets that are important to your users.
- Define new custom data set definitions that can be used in any implementation.
- Define a custom report based on your own data set definition.
- Build new reporting tools and user interfaces (e.g. a custom Reporting Dashboard for clinicians or an interactive data quality tool for data managers).
- Render reports in a standard format (e.g. SDMX-HD).
- Render reports in a proprietary format (e.g. .docx).
- Define custom logic rules to be used in indicators and cohort queries.
- Define new data quality rules to allow data managers to identify problems areas within your form entry process.
Support
We welcome and encourage user comments, new feature requests, and bug reports. In fact, we can't continue development without your feedback. So please play around with the module and let us know what you think. We're aware of that this release of the Reporting Module does not do everything you want, but we're hoping that your feedback will help us to develop a module that does meet your needs. Again, this is an alpha release, so you should expect to encounter a few bumps along the way in the form of bugs, usability issues, performance bottlenecks, and missing features. If you find a bug or want to suggest a new feature, create a bug report, or send feedback please choose one of the options below. If you have other suggestions or feedback, please send an email to dev@openmrs.org.