|
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.
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 :
Assumptions:
Designer is an engineer.
Routine reporting applies typically to more than one implementation.
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:
Assumptions:
Designer is an engineer.
A dashboard applies typically to more than one implementation.
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 :
Assumptions:
Designer needs to be technically inclined to their BI&A tool of choice (e.g. Excel, DHIS2, Tableau, etc). Per-seat licensing for report designer and consumer may apply depending on tool choice.
Typically more implementation specific, less re-use across implementations.
Above definitions were taken and adapted from a DashboardInsights article.
User | Tech aptitude | Scope of supervision | Kind of Reports | Access (how/when) | Frequency** | Report Types |
---|---|---|---|---|---|---|
Store Manager Facility in-charge/administrator | Low | Only responsible for one geographic facility but may have multiple storerooms | Routine reporting |
| Monthly or more (if available) |
|
Intermediate Store Manager (could be district, regional, province) District/regional/provincial health officer, program coordinators, pharmacist |
| Supervises a subset of facilities or specific zone. Facilities must be mapped to zones. | Routine reporting |
| Monthly or weekly depending on replenishment schedules Daily around due dates for requisitions. |
|
Central Personnel or Central Program personnel |
| National supervision of all geographic facilities OR national supervision of one program. | Routine Some ad-hoc (where VAN is rolled out) |
|
|
|
Technical Administrator (can be from the MIS department of the MOH; sometimes there is both a Technical Administrator and a Managerial Administrator) |
| Create new reports, templates and conduct ad-hoc reporting. | Ad-hoc requests from MOH, stakeholders ("I want to see...") | Upon request |
| |
Implementer (most likely a contractor/vendor supporting the system) |
| May create new reports or customize and alter existing reports based on requests from stakeholders | Ad-hoc Routine (help running or troubleshooting/ |
| (Would use and customize all of the above) | |
Stakeholders outside OpenLMIS | Varies | May represent directorates (public health, any interest programs), stakeholders, partners and donors like UNICEF, GAVI, etc. | Ad-hoc | Reports may be shared with these users outside OpenLMIS as needed, whether on paper or by forwarding an email containing a PDF |
**If the implementer is using stock management, frequency of reports would increase.
Short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.
# | Title | User Story | Label | Importance | Notes |
---|---|---|---|---|---|
1 | Short identifier for the story | Describe the user and what they are trying to achieve As a ______ I want/need to ________ so that I _______. - High level acceptance criteria | Relevant labels to distinguish source. From which system, or which country? | Must Have, Nice to Have |
|
2 |
Include any business process mapping, mockups, diagrams or visual designs relating to these requirements. Describes the tasks and the personas who perform those activities. The diagram provides the context for the user stories and serves as a focal point for achieving clarity and agreement among stakeholders. Looks like a standard flow chart.
Identify initial dependencies that are on the critical path for this functionality and may affect the delivery time and serving of business goals. Include links to stories.
Description | Link |
---|---|
Create user personas and outline objectives | |
Research of technical approach/options |
Initial communication between stakeholders and the development team to help understand scope and estimates.
Below is a list of questions to be addressed as a result of this requirements document:
# | Question | Outcome | Status |
---|---|---|---|
1 | How much money does a MOH want to spend on resources to support creating report templates? We want to figure out guardrails on what types of budgets MOHs have to support the creation of reports. This will help us assess reporting tool options. For example, if one solution only allows for highly-specialized resources which cost a lot, we may not go with it. FYI, Josh Zamor. | In progress. | |
2 | What type of skill sets can we expect implementers to have to create the report templates for routine reporting? | In progress. |
Community members are encouraged to share key reports and examples for the team to review and keep in mind as moving forward. Assuming the perspective of a national-level program manager who wants visibility into the activity of their program by region/district, but who would also like the option to get granular-level visibility into facility-by-facility data as well.
1 - Stockout days
2- Stock levels/Consumption (these are two different indicators)
3 -Timeliness and completeness of reporting
4 - On Time and full deliveries
5 - Inventory aging
6 - Expiry/wastage/Loss (based on reason codes)
7 - Stocked according to plan (traffic light or similar indicator)--this is similar to but distinct from #2
8 - Forecast accuracy
9 - Emergency order rate
10 - Performance Score Card
Some other ideas we tossed around but didn’t discuss as thoroughly were:
Financial Reports
A program manager would use this report to measure how much money a facility should have (relating to cost recovery)
A program manager could also see a graph depicting the total costs of requisitions for their area (get a clearer picture of where their money is going)
Could see whether facility is in the red/black based on cost recovery analysis
Should show value of inventory, value of good sold/issued/dispensed, value of goods lost
Emergency Orders
Good to show on a map - district level making emergency orders to provincial level, potential risk of stockouts.