New DHIS2 features/improvements in 2.28 for Case-based Surveillance (CBS)

Dear DHIS2 Case-Based Surveillance Community,


DHIS version 2.28 was released last month with many new features, apps and improvements.


In this email we would like to highlight in particular the features that are important in terms of using DHIS2 for case-based surveillance (CBS).


You can review many of these features on the CBS demo. Similar to the DHIS2 demo, it resets every night. Feel free to review how various components are configured and test/modify them. You can access it here (many of the links will direct you here as well; login instructions are on the sign-in page):


DHIS2 Feature/Improvement

Use case/Application for CBS

Remove gaps in bar/column charts: Data visualizer and event visualizer apps now support an option for displaying bar/column charts without gaps between the bars/columns. Can be enabled in the Options dialog.


Demo | Screenshot 1 - Example in Visualizer | Screenshot 2 - Visualizer Options dialog

This feature allows you to create charts without gaps between each bar or column, which is how epidemiologist are requiring so called “Epi-curves” to look like (or in other words, this improvement is purely cosmetic - but it will make epidemiologists happy!)

Daily relative periods in event analytics: Various daily relative periods are now supported in event reports and event visualizer.


Demo | Screenshot 1 - Output and new period types

The daily relative period feature is particularly useful for creating outputs where you are measuring a current, ongoing outbreak or the response measures to a particular outbreak.


This feature was already available for pivot tables and data visualizer, however now it can also be directly applied to event reports and event visualizer. This can be useful if you want to, for example, create a daily line list of the new cases that have been registered for a particular disease through event reports.  

Skip form validation for validation rules: Validation rules can now be configured to not be triggered during data entry. This is particularly useful for surveillance-based validation rules.


Demo | Screenshot 1 - Configuration example

For aggregate data, you can configure validation rules to not trigger during data entry. This will allow you to create validation rules that look at blocks of data together.


As an example, if I am currently collecting surveillance data on malaria every week, and my rule for my threshold is if malaria cases are 50% or more above last 6 month average of cases this may indicate an outbreak, it would not be necessary to trigger this during data entry.


When I run this validation rule manually I can choose a start and end date to define the 6-month period that I am interested in using to review these thresholds and ignore this during my weekly data entry processes. I can also allow it to run during scheduling by defining the rule to run on a six-monthly period basis. Either option will allow me to avoid unnecessary violations appearing during data entry.

Validate specific organisation unit levels: Validation rules can now be assigned to zero, one or more organisation unit levels. During evaluation, the rules will only be evaluated for the selected levels, or all levels if no levels have been specified.


Demo | Screenshot 1 - Configuration example

This type of validation can be useful for both aggregate or case-based data. In particular, if you are collecting data at the lowest level (let's say facility in this example), but only have thresholds for your diseases at a higher level (or only want to review thresholds based on a cluster of units rather than by a single location), you can define the organisation unit level in which to run your validation rules.


In this example, we could say we have District-level thresholds and that the rule should only be evaluated at the District level to see if the threshold has been surpassed.


This would mean that the validation rule is only checked by aggregating the facility data by District, and then comparing the District-level data with the District-level threshold.

Data element support for program stage notifications: Program stage notifications can now use available data elements in their templates.


Demo | Screenshot 1 - Details in tracker capture | Screenshot 2 - Corresponding e-mail notification | Screenshot 3 - Configuration

This feature is useful for cased-based data. It allows you to embed the value of a data element directly into a program notification.


This could, for example, allow you to include the initial diagnosis, lab confirmed diagnosis, vital status, or any other range of data element values collected within a program stage directly in a program notification to a patient, provider, surveillance team, etc.


You can read the full 2.28 release notes here.


Please let us know any feedback you might have to these features and other use cases you see these features being helpful.


All the best,

The DHIS2 CBS Team