- Reporting Module Examples
- Building Reports (Step By Step Guide)
- Reporting Release Notes
- Getting Started with Reporting
- Designing Reports
- Reporting Module Support
- Reporting Analysis
- Background and Terminology
- Building customized reports inside modules (For Developers)
- Running Reports (Step-By-Step Guide)
- Running and Scheduling Reports
- Reporting Module 101 Screencasts
- Report Processors
- Using the Reporting Module in other modules
- Reporting Module Technical Documentation
- Patient Data Definitions
- Person Data Definitions
- Reporting Module Parameters
- Liquibase error when upgrading the module
- Quality Report
- Reporting Module privileges
- How to create a Patient Clinical Summary using Reporting Module
- How to run a Reporting Module report through a URL
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.
- Download omod from module repo: https://addons.openmrs.org/#/show/org.openmrs.module.reporting
- View/download source code from github: https://github.com/OpenMRS/openmrs-module-reporting
There are many different types of reports but these can be categorized into two main types.
Row-Per-Domain Object Reports
These reports export data in a multi-column format where each row represents the object and each column represents an attribute associated with the object. Currently, only Row-Per-Patient reports are natively supported but more objects (for example Row-Per-Encounter and Row-Per-Program) are in planning.
Indicator reports aggregate groups of people for each question. Below is a Period Indicator Report. Each row contains a question and the corresponding column contains the answer. The answer to each question is a link to the members of the group that fulfills the question.
Currently, reporting compatibility is being used to bridge the gap between the old and new (e.g., combining cohort builder and data exports). This reporting module has many core features for evaluating parts of a report but does not have a good UI for designing a full report. Cohort builder is best for adhoc querying, though for unsupported data entry, you must use the cohort query editor in the reporting module. Data exports can only be designed/exported using reporting compatibility. This module contains a feature that allows you to define simple dataset definitions, such as a SQL-based dataset, but other definitions are not available.