Reporting Project


Contents

Reporting Project

Next Actions

  1. Create product backlog
    • Darius/Paul/Burke/Ben: Please make sure this product backlog is relatively complete.
    • Darius/someone: Could you go through Trac/Jira and find any other reporting related tickets that should be added here.
  2. Prioritize product backlog (must have, should have, etc).
    • Please move features from the backlog into the Release Backlog under the appropriate Priority section.
  3. Estimate product backlog
    • Next week we need to estimate the features in the backlog to figure out the number of features we can fit into the release.
    • Once we have estimates for all of the user stories, we should have a better idea of the number of developer hours we're committing to this release.
    • Ask Mike about time commitment per week: 15, 20, 30, 40 hours?
  4. Plan iteration
  5. Shoutout: Need someone to help mockup some high priority user stories. Is anyone available or interested?
  6. Task out user stories
  7. Initiate sprint and hold scrum meetings EVERY day for 15 minutes.

Risks

  • We don't have a product owner yet -- someone to give us feedback on features implemented and prioritize the features to implement.
    • We need to find one before the end of the first iteration.
  • We have way a lot of features to implement.
  • We only have have two developers.
  • We don't have a good estimate on the features in the current backlog.
  • We need someone to manage this project. Justin is playing the role of Developer AND Project Manager.

Overview

This is the portal for all reporting projects (past, present, and future).

Information

  • Release Backlog: Reporting Release Backlog v1.0
  • Burndown Chart: TBD
  • Release Date: July 1, 2009
  • Product Owner: TBD
  • Scrum Master: Justin Miranda
  • Velocity: unknown (will know after first iteration)
  • User Story Points: using ideal days (when estimating a user story, think about how many days it would take to implement if you were left in a room by yourself, uninterrupted).
  • Iteration Length: 2 weeks

Developers

    • Justin Miranda (25 developer hours per week x 2 weeks per iteration x 7 iterations = 280 developer hours)
    • Mike Seaton (30 developer hours per week x 2 weeks per iteration x 7 iterations = 420 developer hours)
      • PLEASE HELP: We need more developers

Iterations

The following iterations have NOT been planned yet. This is just a quick sketch.

  • Iteration 1 (Mar 30 - Apr 10)
  • Iteration 2 (Apr 13 - Apr 24)
    • Report API Refactoring
    • Dataset Builder
    • Cohort Builder
  • Iteration 3 (Apr 27 - May 8)
    • Dataset Builder
    • Cohort Report Builder
    • BIRT Module
  • Iteration 4 (May 11 - May 22)
    • Dataset Builder
    • Cohort Report Builder
  • Iteration 5 (May 25 - June 5)
    • Cohort Report Builder
    • BIRT Module
  • Iteration 6 (June 8 - June 19)
    • BIRT Module
    • Cohort Builder
  • Iteration 7 (June 22 - July 3)
    • Documentation Sprint?

High Level Components

Components in bold will be prioritized first unless otherwise specified by stakeholders.

  • BIRT Report Module - Allows users to generate and manage reports
  • Core Reporting Framework - Represents the core reporting API for OpenMRS. This is a moving target and still requires substantial work to complete.
  • Data Export Manager - Allows users to export datasets in various formats.
  • Dataset Builder - Allows users to build datasets around encounters, patients, observations, programs, cohorts.
  • Dataset Viewer - Allows users to view a dataset given a cohort definition and dataset definition.
  • Dataset Manager - Allows users to manage datasets (CRUD operations).
  • Cohort Builder - Allows users to build cohort queries (cohort definitions) to be used in reports.
  • Cohort Manager - Allows users to manage cohorts (CRUD operations).
  • Cohort Report Designer - Allows users to create cohort reports.
  • Indicator Builder - Allows users to specify an indicator definition.
  • Indicator Manager - Allows users to manage all existing indicators in the system.
  • Report Dashboard - Allows users to view a portal-like dashboard containing pre-defined reports (like monthly enrollment graph).
  • Report Manager - Allows users to manage reports (CRUD operations). Should also allow users to schedule/email reports.

Release Backlog

This is actually more of a "general backlog", meaning it includes all reporting deliverables that we'd like to have in the next release. However, given our limited time and resources, we're going to need to be strategic about what we can get done. The current breakdown (Must Haves, Should Haves, Could Haves, Won't Haves) is based on my own views of what's important.

Must Haves

Add all features that must be completed by the end of this release. The release cannot be consider "complete" until these features are implemented and approved by product owner. These features should be completed as soon as possible (within the first few iterations if possible).

  • Add user stories / requirements here

Should Haves

Add all features that should be completed by the end of the release. These issues must also be included in the final release, but a few of them can be pushed back to a later release if estimation or prioritization of user stories goes awry.

  • Add user stories / requirements here

Could Haves

Add all features that could be completed by the end of the release. It would be really nice to include these features in the release. However, these issues can be moved to a later release if necessary.

  • Add user stories / requirements here

Won't Haves

Add all features that we know won't be completed by the end of the release. These features will most likely be added to the next release unless there's a lot of time left in the final iterations.

  • Add user stories / requirements here


Product Backlog

These are all/most of the backlog issues that currently exist. We need to move these features from the following list to the Release Backlog by priority (Must, Should, Could, Won't)

Refactoring

These are refactoring changes that may (or may not need to happen). The underlying tasks for these are located in a Google Doc Report Refactoring Tasks.

  • Core capabilities for persisting instances of open-ended implementation classes (XML serialization).
  • Implement new reporting framework API.
  • Refactor new reporting framework to create logic package structure (see new package design).
  • Refactor CohortDefinition
  • Deprecate PatientSearch, and PatientFilter
  • Refactor DatasetDefinition
  • Refactor ReportSchema
  • Refactor DataExport tools to fit into this framework
  • Support simple "patient list" reports
  • Support "indicator" reports
  • Support "Rendering" ReportSchemas across a range of parameters
  • Scheduled Tasks that allow users to configure long-processing reports to run periodically
    • We might be able to fit this into the Quartz Scheduler GSoC project.
  • Deprecate "Macros" and find a suitable replacement in the above framework
  • Provide a means for users to configure which ReportRenderers support which ReportSchemas
  • Support Indicator Breakdown Reports
  • Support BIRT reports (see features below)
  • Scheduled email utility
    • Again, this might fit into the Quartz Scheduler project.
  • Add locationization support to reporting framework
  • Add FieldGenerator-like framework for defining dataset definitions and cohort definition

Epics

These are requirements that are larger than stories. They need to be broken into smaller user stories and added to the appropriate section below.

  • Implement a simple dataset viewer tool (takes a cohort and dataset definition and spits out a dataset).
  • Refactor existing tools (Cohort Builder, Data Export Tool) to use new reporting API.
  • Improve existing tools to support parameters specified by users at runtime.
  • Design a more intuitive interface for defining data exports (aka dataset definitions).
  • Integrate Data Export into new reporting framework as dataset definition
  • Integrate Logic Dataset into reporting framework as dataset definition
  • Integrate Form Data Export into reporting framework as dataset definition
  • Dataset viewer (choose cohort/dataset)
  • Implement a reporting dashboard for users to view high level country, region, or clinic information
  • Implement feature to create reports based on excel templates
  • Export data in multiple format (CSV, TSV, XML)
  • Implement simple user interface for the logic service

User Stories

These are relatively high level epics that may need to be broken down into smaller user stories.

General
  • Allow user to define datasets around any entity (patient, program, observation, encounter, cohort)
  • Allow user to browse cohorts more easily (see dataset viewer).
  • Allow user to drill-down into a cohort to view patient specific information (columns) that show why a user is in that cohort. For instance, a "All male adults" cohort dataset would display (at a minimum) columns for the patient's MRN, age, and gender.
  • Allow user to define complex indictors (like TB culture conversion). This needs more of a description
  • Allow user to upload a report template designed in Excel or Open Office.
  • Allow user to export data for use in SAS and other third-party tools.
  • Allow user to add logic columns (i.e. LAST CD4 COUNT) to datasets.
  • Allow user to view a dataset given a cohort and dataset definition.


BIRT Report Module

These are specific to BIRT. These probably don't need to be broken out into a separate section, but it makes it easier to organize this way.

  • Allow user to design basic BIRT reports (and report elements) within OpenMRS.
    • Allow user to create a report that displays a table of data.
    • Allow user to create a report that displays a pie chart.
    • Allow user to create a report that displays a crosstab or pivot table.
    • Allow user to add a report element to an existing report.
  • Implement new features within the BIRT Module
    • Upgrade BIRT to the latest version of the BIRT Runtime Engine v2.3.2
    • Upgrade BIRT to the latest version of the OpenMRS API v.1.4.1
    • Support multiple datasets in BIRT
    • Integrate BIRT Report renderer into the reporting framework.
  • Implement wizard to allow users to create new reports
  • Logic web service user interface (for testing logic statements)
  • Allow BIRT reports to be sync'd between servers (requires concept/dataset syncing)
  • Allow BIRT report designs to be downloaded with sample dataset.
  • Allow users to generate reports.
  • Allow users to schedule reports.
  • Allow users to email reports.
  • Allow users to specify a chain of actions to execute over reports (schedule -> email).
Core Reporting Framework
Data Export Manager
Dataset Viewer
  • View a cohort of patients with a set of columns of my choosing (dataset definition).
  • Preview the first 25 rows of a dataset definition.
  • Apply a filter to dataset (apply a dynamic cohort).
  • Save filters on my dataset definition (essentially like chaining cohorts).
  • Apply a sort by operator over a selected column (i.e. Family Name).
  • Apply a group by operator over a selected column (i.e. Gender).
  • Apply an aggregation operator over a selected column (i.e. COUNT [STATUS = ON ARV]).
  • Apply a cohort to my dataset definition so that I can view patient data for my HC.
  • Export datasets from the system to use with an external reporting tool.
  • Pivot a patient-per-row dataset on Health Center and Enrollment Date to get total count of patients enrolled at each Health Center for a given month over the past year.
Dataset Builder
  • Create a new encounter-per-row dataset.
  • Create a new obs-per-row dataset
  • Create a new patient-per-row dataset.
  • Create a new program-per-row dataset.
  • Create a new data warehouse dataset.
  • Create a new web service dataset definition.
  • Create a new SQL dataset definition.
  • Create a new static aggregate dataset definition (user-entered numbers).
  • Add a new concept column to my dataset definition.
  • Add a new metadata column to my dataset definition (depends on dataset orientation).
  • Add a new cohort column to my dataset definition.
  • Add a new logic column to my datset definition.
  • Add a merged column that allows me to display HIV PROGRAM STATUS regardless of which PROGRAM the patient is in (i.e. HIV, PMTCT, etc). Similar to IFNULL.
  • Format the values in a field to display on certain values (address1, address2).
  • Rename a column in my dataset definition.
  • Move a column to the right or left of another column.
  • Move a column to the beginning or end.
  • Delete a column from my dataset definition.
  • Transform birthdate column to age.
  • Transform birthdate column to age range.
  • Save a dataset for future use.
Dataset Manager
  • Allow user to delete a dataset definition.
  • Allow user to rename a dataset definition.
  • Allow user to prereview first 25 rows of a dataset by selecting a cohort.
  • Need more requirements
Cohort Builder
  • Query "male adult" to see all male adult patients.
  • Query "weight < 50" to see all patients with weight less than 50 kg.
  • Query "cd4 < 250" to see all patients with CD4 less than 250.
  • Query the system to find out:
    • How many patients have TREATMENT STATUS = ON ARV asof ${date}?
    • How many patients are enrolled in HIV PROGRAM in ${period}?
      • given: two dates, week, month, period, year
      • patient just needs to be in HIV PROGRAM
    • How many patients started HIV PROGRAM in ${Period}
      • given: two dates, week, month, quarter, year
      • patient needs to have started in given period
    • [many many more of these need to be specified]
  • Select query that I've run in the recent past.
  • need more requirements (trawl through Trac/Jira)
Cohort Manager
  • Allow a user to create a new cohort definition.
  • Allow a user to delete an existing cohort definitions.
  • Allow a user to update an existing cohort definitions.
  • need more requirements
Cohort Report Designer
  • Need to collect user stories from users.
Indicator Builder
  • Allow user to define an indicator so that he can see how many MALE ADULT patients are ON ARVs.
  • need more user stories
Indicator Manager
  • Need to collect user stories users/developers.
Report Dashboard
  • Configure a dashboard of reporting widgets.
  • Add a table dashboard widget.
  • Add a graph dashboard widget.
  • Add a crosstab dashboard widget.
  • View dashboard of summary information about programs within the current clinic.
  • Choose a different clinic or program to view in order to view other statistics.
  • Remove a widget from the dashboard.
  • [Admin] Create a customized dashboard for any clinician/user.
Report Manager
  • Create a new folder for your reports.
  • Show me everyone's reports.
  • Show me only reports that I have authored.
  • Design a report by adding a single report element.
  • Edit a report design by adding a new report element.
  • Create a report model by selecting an existing data set definition and cohort definition.
  • Import a report model from another implementation.
  • Schedule a report to be run daily/weekly/monthly/annually.
  • Upload a report designed in the BIRT Designer.
  • Run batch reports to output a single PDF for every site.
  • Email report links (or output) to myself and other stakeholders.
  • Schedule a report to be emailed daily/weekly/monthly.
  • Generate a PEPFAR report for June 2008.
  • Send email notification to author whenever a report has been automatically generated.
  • Send email notification to author when a report design has been modified.
  • Download a BIRT report design.
  • Create a sample BIRT report design.
  • Configure my notification and other reporting preferences.
  • Restrict access to my reports, datasets, cohorts, etc.
  • Render report output as PDF, Word Doc, Excel, PostScript, PowerPoint.
  • Print report output.
  • Run a report with uploaded datasets.

Mockups