Reporting and Analytics

Table of Contents

The reporting and analytics vision is to support OpenLMIS users with both routine reporting and ad-hoc analysis. Users need a way to extract and visualize data. This specification is not defining the exact list of reports needed but rather what types of reports (map, offline, etc.) and functionality is desired. Please see the Scope Out section for a clear explanation of what pieces this spec does not include like alerts (via email/sms) and integrations to systems like DHIS2.

This wiki page is an attempt to define the reporting and analysis needs for OpenLMIS users based on the following generalized user personas identified by the community.  

Open

Background

In an attempt to gain buy-in and agreement by the OpenLMIS community on what the needs, requirements and definitions are for reporting and analytics within OpenLMIS.  Do not focus on the technical solution as there may be multiple approaches to meeting the desired behaviors. Focus of this spec is to outline what the end users will need and want.  This spec will support the decision making process for implementing reporting and analytics within OpenLMIS.  

To support this conversation, we define reporting, dashboards and analytics in the following ways:

Reports, routine reporting and sometimes called built-in reporting contain detailed data in a tabular format and typically display numbers and text only, but they can use visualizations to highlight key data. Some key characteristics of a report include :

• It presents numbers and text in a table.

• It can contain visualizations (like a map, chart, graph) but only used to highlight findings in the data.

• It is optimized for printing and exporting to a digital document format such as CSV, Word or PDF.

• It is geared towards people who prefer to read data, for example, lawyers, who would rather read text over interpreting visualizations, and accountants, who are comfortable working with raw numbers.

• Rendered from a defined query/template.

• Does not require high technical capacity to run or access the report

• Usually viewed or run on a routine bases (more than once a year)

• Usually drives users to an action

Dashboards are a data visualization tool that displays the current status of metrics and key performance indicators (KPIs) for OpenLMIS end users. Dashboards consolidate and arrange numbers, metrics and sometimes performance scorecards on a single screen. Some key characteristics of a dashboard:

• All the visualizations fit on a single computer screen — scrolling to see more violates the definition of a dashboard.

• It shows the most important performance indicators / performance measures to be monitored.

• Interactivity such as filtering and drill-down can be used in a dashboard; however, those types of actions should not be required to see which performance indicators are under performing.

• It is not designed exclusively for high-level decision makers or but rather should be used by the general workforce as effective dashboards are easy to understand and use.

• The displayed data automatically updated without any assistance from the user. The frequency of the update will vary by organization and by purpose. The most effective dashboards have data updated at least on a daily basis.

• Does not require high technical capacity to access

Analytics and Ad-hoc analysis leverages tools that offer the ability to select ad-hoc date ranges, pick different products, or drill down to more detailed data to be dashboards and my dynamic than reports. Some key characteristics of data analytics include : 

• user can define desired data element combinations (via a programming language or wizard).

• Not routine and the combination of data elements is run infrequently (once year).

• It fits on one screen, but there may be scroll bars for tables with too many rows or charts with too many data points.

• It is highly interactive and usually provides functionality like filtering and drill downs.

• It is primarily used to find correlations, trends, outliers (anomalies), patterns, and business conditions in data.

• The data used in a ad-hoc analysis is generally historical data. However, there are some cases where real-time data is analyzed.

• An outcome of ad-hoc analysis might be to define/identify performance indicators for use in reporting and/or dashboards.

• It is typically relied on by technically savvy users like data analysts and researchers with knowledge of and experience with report programming languages.

Above definitions were taken and adapted from a DashboardInsights article.

**If the implementer is using stock management, frequency of reports would increase.

Assumptions

• If the implementer is using stock management, frequency of reports would increase with transaction data. 

Phase 1 Scope: DISC Indicators 1 and 2 (Full Stock Availability and Closed Vial Wastage) - Last Update 1/16

Stock cards - each record / "row" in the database is a stock card line item, and will have the following data elements / fields / "columns" ("row" and "column" are used to show analogous terms to relational databases, whose structure is more familiar, although in this particular database we store the data as .json records)

• Stock card line item id ("id")

• Stock card id

• Occurred date

• Orderable name

• Orderable id

• Orderable code

• Commodity type

• Trade item

• Lot #

• Program name

• Program id

• Program status

• Facility supported programs

• Quantity

• Stock on hand

• Reason type

• Reason category

• Reason name

• Source

• Facility id

• Facility name

• Facility type

• District

• Region

• Region code - ISO code

• Country

• Ideal stock amount - value is added for all orderables within the corresponding commodity type + facility pair

Additional detail can be found in the initial design document: DISC Indicators.PDF

The following items will need to be reviewed and potentially customized for your particular implementation's configuration

1. Product model hierarchy

   • Based upon the Commodity Types your instance uses, you may need to ensure the data model includes the proper tiers for your instance.

2. Geo Zone hierarchy

   • By default, we used the following Geo Zone hierarchy, but you may need to adjust this based upon the hierarchy in place at your instance:

     • Facility

     • District

     • Province / region

     • Country

3. Closed Vial Wastage

   • You should review the definition of line items that count as "closed vial wastage" ("numerator" column for Closed Vial Wastage in business logic table above) to ensure this definition comprehensively applies at your instance.

   • You should review the definition of "receipts" ("denominator" column for Closed Vial Wastage in business logic table above) to ensure this definition comprehensively applies at your instance.

4. Consumption

   • You should review the definition of "consumption" ("numerator' column for Forecasted Demand Ratio in business logic table above) to ensure this definition comprehensively applies at your instance.