Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Some examples and ideas and notes from real-life reports done with the Reporting module.

Examples

Program enrollment outcome (PIH Malawi)

Program enrollments together with Workflows can indicate the current status of a patient for a specific medical problem like HIV or TB. Using this information to provide a regular feedback to the medical staff can help increasing the use of OpenMRS and improve the medical care. E.g. presented on a weekly basis enables to see how and where the clinic is likely to be going. The following example is renderer by Excel.

This reports can be created using the UI of the Reporting Module 0.4.1.9+. To simply the setup, testing and deployment, the creation of all report elements is done via a Java script (Source in SVN).

Note: Even though this report depends to some extends on the Concept Dictionary of PIH Malawi, it should be easy to adopt or to generalize. It also depends on the Program Location Module.

Missed appointments (PIH Malawi)

If OpenMRS is used to keep track of patient appointments, a status overview of missed appointments is useful.

This reports can be created using the UI of the Reporting Module 0.4.1.9+. To simply the setup, testing and deployment, the creation of all report elements is done via a Java script ([Source in SVN|http://svn.openmrs.org/openmrs-modules/pihmalawi/]).

Best practices

Scripting setup of Reports

The Reporting module already provides a generic UI to define and to view reports. Even though this is good for an adhoc approach, to get familiar with the Reporting module in general and specific requirements for reports, this is also "click-intense". Besides this for now these reports are bound to a specific OpenMRS database installation (unless clever ways of myqldump and -load are used). If reports need to be

  • version controlled,
  • shared between different installation (like test and production env), or
  • adopted for slightly different usecases while maintaining the general structure,

then it might make sense to externalize the creation of the various report elements. Besides the UI everything is accessible through the Java-API. With some Java knowledge, the creation of Cohort queries, Indicators and Report Definition can be scripted.

The "deployment" of reports can be done in 2 different ways:

  1. Through a module, which provides the Administration feature to set up (and remove) persisted report elements (good for production systems).
  2. Through a (misused) Junit testcase, which can easily be invoked from the local development environment (good for development and testing).

An example can be found in the PIH Malawi module ([Source in SVN|http://svn.openmrs.org/openmrs-modules/pihmalawi/]). Please note that this is tailored to the needs of PIH Malawi, but it can serve as a blueprint for other installations.

  • No labels