Dear DHIS2 Case-Based Surveillance Community,
DHIS version 2.27 was released this June 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. You can access it here (many of the links will direct you here as well; login instructions are on the sign-in page):
https://cbs-academy.dhis2.org/demo
|
DHIS2 Feature/Improvement |
Use case/Application for CBS |
|
EPI weeks: The system now supports various weekly period types, with Monday, Wednesday, Thursday, Saturday and Sunday as the first day of the week. Data can be collected through data sets configured to use the desired weekly period type. The analytics engine will attribute weekly data to the month which contains four days or more of the week. Demo | Screenshot 1 - Pivot Tables | Screenshot 2 - Data Set Maintenance | Docs |
An epidemiological week, commonly referred to as an epi week, is a standardized method of counting weeks to allow for the comparison of data year after year. This are used throughout the world by epidemiological teams in different countries.
Why is epi week important - Many times, particularly for mosquito surveillance, notifiable diseases surveillance or epidemiological studies, daily increments are too frequent and too varied to be able to be managed and analyzed, or there are many factors that make it impossible to compare daily results. On the other hand, the monthly time interval is too great, and data interpretation is needed at more frequent intervals. Therefore, week becomes an intermediary and important period to analyze the data. |
|
Program rule improvements: A completely new user interface for managing program rules has been introduced in the Maintenance app. A range of new program rule actions is now supported in the new user interface:
Other improvements include the ability to delete and change program rule variables(source fields), and the ability to include one data element in several program rule variables. For all warning and error messages it will now be possible to include a dynamic/calculated part at the end of the static error message. Configuration in Maintenance| Screenshot - Setup |Screenshot - Rule expression | Rule action | Tracker capture | Docs |
A number of new program rule actions as well as a re-designed user-interface has made creating these rules more intuitive within DHIS2. Using program rules allows you to make a variety of logical rules that will make both data entry and patient monitoring a more user-friendly experience. Within a generic surveillance program, this allows you to only show items that are related to the disease that has been identified. You can also use these rules to display/calculate a variety of information as you enter new data directly on the patient’s dashboard in order to keep track of the patient’s status (for example, displaying the the initial diagnosis, lab results, and confirmed diagnosis as individual feedback as this information is collected). Additionally, these rules can be used to create validation checks.These can assist you to ensure that lab test data is entered as being performed only after the case has been reported, or that results are within an expected range based on certain criteria. |
|
Notification modes: Validation rule notifications can now be sent as individual messages or as message summaries. This is useful e.g. when you want to send individual messages for high-priority disease outbreaks, and summaries for low-priority routine data validation errors. |
When sending validation notifications, the notification mode allows you to determine if you would like to send out notifications in a large group/batch within one message or would like each notification that meets the criteria you have set to be sent out as an individual message. As an example, if you are in a malaria control setting it may not be useful to receive an individual message for each malaria case; it may be better to receive these as a summary. If, however, you have a priority disease that you need to identify immediately (such as polio or ebola for example) you may want to receive each case as a separate message. |
|
Sliding windows in validation: Validation rules can now calculate data based on sliding time windows. This implies that data is evaluated not just for fixed periods, such as weeks, but also for sliding intervals of the same duration, e.g. Wednesday to Thursday. |
Sliding windows allow you to define a moving period in which you can compare data to identify outbreaks. This is particularly useful with cased based surveillance data as the data you report is not constrained to a defined period but is based on the actual date it was collected. As an example if I have a threshold of 5 cases within a 7-day period, this may not be captured if I do not use a sliding window. I could have data from 2 weeks (but within a 7 day period) that actually is above this threshold, but looked at separately is not. As an example if I have the following: Week 1 (July 2 -8): 3 cases Week 2 (July 9-15): 3 cases Individually, the weeks do not break the threshold of 5; however if I were to look at them within a 7 day block: July 6: 1 case July 7: 2 cases July 11: 3 cases I can see that together, I have more than my threshold of 5. This would allow me to correctly identify that the threshold has been surpassed in this particular case. |
|
Predictor: Using current and previous data, expressions can be used to generate data to be compared against. This is useful for creating outbreak thresholds for example. Several types of expressions are supported to create these predicted values. In the CBS-Demo you can review several examples of the predictor in action. Configuration in Maintenance| Comparison In Data Visualizer| Docs |
Often in disease surveillance, alerts are triggered when newly captured data exceeds certain thresholds that have been calculated using historical data. Various formulae/methodologies are now supported in order to use the historical data that is in DHIS2 to generate these thresholds for previous, current and future periods. This allows you to compare your data with the system-generated thresholds in order to determine if action is required as well as continuously update your threshold values over time as new data is entered into DHIS2. |
|
Program Indicator Improvements: A new user interface for program indicators has been introduced. This new interface streamlines the the logic of adding in program indicators with a stepwise approach to adding these within DHIS2. |
In case-based surveillance programs, program indicators can be used to count the number of cases of confirmed notifiable disease by type, create various disaggregations (such as age, sex) based on the information collected in your surveillance program, calculate on-the-fly information directly as it is entered into your surveillance program and support the creation of population based indicators including incidence rates and proportions. These types of indicators are critical in analyzing case based based surveillance data, and the new user interface simplifies the logic of creating them in DHIS2. |
|
Program Notification Improvements: Specific attributes and data elements of phone number/e-mail type can now be selected in the program notifications dialog. Rather than sending out one notification to all attributes of phone number/e-mail type, this will allow you to create separate notifications and specify the recipient(s) based on the information collected within the same enrollment/program stage. |
Using specific attributes or data elements of phone number type allows you to send out multiple notifications based on data collected within the same program. As an example, if you are collecting phone numbers of both the identified case and the referring physician you can create different messages for each of these individuals based on the information you have collected within your surveillance program. These will be automatically sent based on how you have defined the triggering action, with customized messages for both the patient and the provider. |
You can read the full 2.27 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