Overview
Reports and analysis is an important part of the DHIS application. The main features needed of a DHIS report module are:
- Support for design and generic report generation (with parameters) of exact replications of the paper-based reporting forms
- Support for flexible report design and generic generation (with parameters) of any kind of report combining the data available in the database (data elements, indicators, various groups, orgunits, periods etc.)
- Support for charts in the reports in 2) above
Detailed requirements
Replications of the paper-based reporting forms
This requirement comes from the demand of being able to exactly replicate the paper-based reporting forms used in the health services. This requires detailed design features where the exact position of the data and text fields in the report layout is of great importance, as well as an export to a printable format keeping the exact layout.
Background note: In some HISP countries the computerisation of the health information system and the introduction of the DHIS to support an integrated system is being carried out in a step-by-step manner, and a common first step is to computerise the paper-based report system for some selected health programs. In the paper-based system the paper form serves both as 1) a data entry form where the health workers fill in their numbers and 2) as a report that is sent to the health authorities at the level above. In a computerised system there is no need to have the same forms for data entry (input) and reports (output) as the data is being stored and processed in a database system. However, as a gradual change towards computerisation this user-requirement to replicate the paper forms both for data entry and for reports is quite common as must be addressed.
Some examples:
1. A monthly district-level report for one orgunit and one period
This is the simplest type of these replicated reports. This example report will be used generically by all orgunits at the district level for every month. The report will have two "run-time" parameters that must be submitted by the user upon report generation, the name of the orgunit and the name of the month. The layout of the report must be an exact replication of the layout of the paper form. The layout is a mix of header fields, text fields, data fields, and possibly some summarised fields (subtotals or totals of a selection of data fields). The header fields will in this example be the orgunit name and the name of the month, both fields should be populated based on the user's parameter values. The text field are mostly data element names and netx to them is a data field with a Data Value for that data element + orgunit + period. So the Data Values must be retrieved based on the report parameters.
2. A monthly district report for one orgunit and several periods
This is quite similar to the example above the only difference is that this report requires data from several periods. This is often required as the reports should not only provide the data for a specific month (or quarter), but also the subtotal (accumulated value) so far in the year up to that month. Some reports also requires the values of the same month of the previous year as well as the accumulated values for the previous year. Apart from these additional values for related periods the reports are the same. These reports should also be generic and regenerated for all orgunits and periods with report parameters.
Flexible reports with any kind of data
These reports are more useful for analysis and should leverage the possibilities of having an integrated database with both raw and aggregated data values for many health programs, indicators, and also make use of the user-defined groups for data elements, indicators and orgunits. What is common for these kind of reports is that they must allow for a flexible mix of "data" from the database.
In these cases there are often need to make use of the orgunit hierarchy to make a generic report for all health facilities in a district, or all districts in a province. Similarly the need to generically generate reports based on groups and their members is also important here; e.g. list all orgunits member of the group "hospitals with international funding", or all data elements and indicators in the "immunisation" group. These kind of reports would also need a mix of table information and chart information, so integrated support for charts is important here.
The layout requirements will vary from the more simple table form to more detailed design like in the "paper replication" reports described above. These reports will typically be used more for web viewing than for print-outs on paper, but should support both.
The core idea of these kind of reports is that anything should be possible, meaning that the user can select any "element" from the database and define the report parameters that should be submitted upon report generation.
General requirements for the report designer
Roughly there are two main sections/windows here; 1) the report layout/design and 2) the design toolbox.
The Layout/design window
The layout screen should intuitively show the user what the final report layout will look like, and as a minimum show how the different "objects" of the report are positioned relatively to one another (above, below, right, left). A preview option should also give the users a view of what the generated report will look like in a printable format like .pdf as well as on an online format on a web page.
Design toolbox
Data fields:
These fields are variables, and they will be populated upon report generation.
The most common data fields to be used are Data Value and Indicator Value. Both values are linked to an orgunit and a period in addition to a data element or an indicator. These data fields must be displayed to the user as the data element name or indicator name in the design tool box. These names should be possible to filter by groups. When used in a report, when the data element/indicator name is "in some way" moved to the report layout screen, it must be attached to an orgunit and a period to represent a data/indicator value. The orgunit and period should be either fixed, provided directly as a report parameter, or provided through a "formula" based on the parameter value. The "formula" can then be used to e.g. represent the same month of previous year or accumulated yearly values up to the current month (see report example 2 above).
Text fields:
These fields are used to represent text in the report layout/design. The text should be in different sizes, colour and style. Often the text is representing a name of an element in the database, like a data element name, data element group, or an orgunit name. These fields are static and e.g. much used in the report example 1 above. It should be possible to use the text already available in the database so that the user e.g. does not have to write in the data element names. A way to retrieve these names, display them to the user, and then make use of them in the report layout's text fields is wanted.
Special fields:
Here are some examples of special fields:
Summarised/formula fields:
To provide a field with a value based on a "formula", like a total of selected values in the report.
- Expandable columns/rows in tables
This is very useful when the report includes a generic listing of e.g. the children of an orgunit or the data elements that are members of a group.
- Table/list etc.
Some fixed layouts that give a table view or a list view of the data, often with generic content, e.g. a new row or list item for each data value for the given combination of orgunit and period.
General requirements for the report generator
The report generator must be an integrated module in the DHIS 2.0 application.
The typical use case should be something like this:
1. Select a report design (available on the server as well as a "browse" option to upload and use a design file located on the local computer)
2. Fill in the necessary parameter values for that specific design
3. Generate the report and export to the desired formats, saved in a user-defined folder
4. Display a web version of the report in the browser
Period handling and aggregation of values
All data values are stored in the database for a given period. The period is represented as a StartDate and an EndDate. E.g. data values for routine health data represents the actual number of services given of a specific type (e.g. BCG vaccines) within a given period, e.g. between the first and the last day of a month if its monthly data. The period (or interval if you like) to use for data entry is totally flexible and up to the user to define, but most of the data follows the standard periods like daily, weekly, monthly, quarterly, semesterly and yearly.
While the data entered and stored in the database has to follow the defined periods for data entry (defined in the datasets) the report module should allow flexible reports for any possible period. E.g. data captured on a monthly basis should be possible to display in reports as quarterly or yearly aggregates. However this aggregation is not allowed the other way around, e.g. data captured on a monthly basis should not be possible to display in a report as weekly estimates, as these are only estimates and not the true values. If the user wants weekly reports, the data entry frequency must be changed to reflect this so that weekly values are made available in the database. There are some cases that estimation must be allowed, as e.g. as weeks and days do not easily add up to months, but these are standard period estimations/calculations that we cannot get around.
One important point here is how the periods are displayed to the user. As mentioned, the periods are represented as StartDates and EndDates in the database, but the users would like to see "names" like January 2005, Q3 2005, Week 3 2005 etc.
More importantly, to avoid estimations of e.g. monthly values the StartDate and EndDate used in the report module e.g. to represent the month January 2005, must be the same as the start and end dates used by the data entry module (and hence what is stored in the database). A user cannot request a report from January 15 to February 15 if the values in the database are stored with January 1 - January 31, February 1 - February 28. Then the only possible monthly reports are January 1-31 and February 1-28. This challenge applies to all periods whether weeks, months or quarters ++.
