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

Dear DHIS2 Case-Based Surveillance Community,

DHIS version 2.29 was released in March 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 using the “Notifiable Medical Conditions” program. 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):

https://cbs-academy.dhis2.org/demo 

DHIS2 Feature/Improvement

Use case/Application for CBS

Data capture and data view sharing levels: The sharing solution has been extended with two new levels for “data capture” and “data view” access for users and user groups. These levels apply to programs, program stages, data sets and category options, and replaces the link between user roles and data sets/programs. This offers a simplified and more flexible access control solution.

Demo | Docs | Spotlight Video 1 - Program Stage Sharing Overview and Spotlight Video 2 - Data Level Sharing : Tracked Entity Types, Programs and Program Stages

This feature allows you to control the level of access individual users/groups have to a program. Note that these settings apply both in event/tracker capture as well as in analysis applications. As an example scenario for disease surveillance you may have several groups with different access to your program:

  1. Group 1 registers your cases and potentially performs the initial diagnosis
  2. Group 2 performs the lab specimen tracking and and records the results
  3. Group 3 performs contact tracing and case investigations

As each of these groups has specific functions, you may only want them to be able to edit the parts of the program that they are responsible for. You could choose to have them see data from the other stages (or not) but not be able to edit/alter/add data to any of the other stages.

You can try this out in our demo by having the following users access the notifiable medical conditions program at org unit level 4 (facility level):

Username: cbsdemo

Password: District1#

A superuser which can see and edit registration and all program stages.

Username : casereg

Password: District1#

This user can register a new case and add/edit data to the clinical examination and diagnosis stage. They can view the data from the other stages.

Username: lab

Password: District1#

A lab user which can edit the data from stages 2/3, specimen tracking/lab results. They can view the registration details and data from other stages but can not alter the data in the other stages.

Tracker programs in maintenance app: You can now create and modify tracker programs in the maintenance app. The workflow for creating programs have been made more intuitive and effective, where stages, sections, data entry forms and notifications can be created from within the main page.

Demo | Spotlight Video - Event and Tracker Maintenance

Managing programs has been streamlined in 2.29, with the previous programs/attributes app being replaced with the ability to manage both event and tracker programs within the maintenance app.

These additions allow for easier management of surveillance programs. In particular, operations such as managing which attributes belong to a program, the definition of program stages and the data elements which belong to them are all performed within the one section of maintenance. This makes it easier than previous versions, as there is no need to go to separate areas of DHIS2 in order to manage data elements within different program stages for example. A stepwise approach has been integrated within this app as well, following the general flow one needs to perform when creating a new event or tracker program.  

Integrated search and registration: The steps for searching and registering new tracked entities are now integrated. When registering a new tracked entity instance, the registration form will automatically search for possible duplicates and alert the user in case of suspected duplicates. When a search comes back with no hits, the searched values are carried over to the registration form.

Demo | Docs | Screenshot 1 - Search during registration | Screenshot 2 - Duplicates found | Screenshot 3 - Integrated search | Screenshot 4 - Moving searched attributes to registration | Spotlight Video - Tracker Capture

Integrated search and registration allows you to ensure there are no new duplicates during the registration process when looking for cases within your surveillance system. This can be particularly important when trying to update an existing case and/or eliminating duplicate cases at specific points in time in the event of a notifiable disease or outbreak.

In addition, when a search does not return any results, you are able to automatically carry over any details you searched for in the registration page.

You can try this out in the CBS demo by selecting any organisation unit at level 4 (facility level) and trying to register a person into the notifiable medical conditions program:

  • Local Case ID: 3698753
  • First Name: Homer
  • Surname: Simpson

This should automatically return a duplicate result

ID-generation based on functional patterns: Unique IDs can now be generated based on a configured pattern. The patterns can contain various components such as org unit code, year and sequential numbers.

Demo | Tutorial | Docs | Spotlight Video - Tracker Capture

Pattern-based IDs using metadata and inputs from a user’s own DHIS2 system are now supported. This can allow you to integrate system-generated IDs that support sequences, dates and organisation unit codes as an example.

You can have a look at an example configuration by reviewing the “System Case ID” tracked entity attribute in the demo. You can also see how this works in practice by registering a new case in the “Notifiable Medical Conditions Program”

Fixed information in top menu for tracked entities: You can now configure a fixed information bar containing key attributes or calculated values for individual tracked entities. The information bar will always be visible at the top of the screen while capturing data for a single tracked entity.

Demo | Screenshot 1 |

Spotlight Video - Tracker Capture

As you work within your surveillance program in tracker capture, you will be able to keep key details persisting at the top of the dashboard as your scroll through you program. This includes any information you may have previously put in the “indicators” or “feedback” widgets in tracker, which means you can have program indicators and program rules populate this top menu bar as information is collected within your program.

You can have a look at this by reviewing an existing record or creating a new record within the notifiable medical conditions program.

Image type attributes: Images can now be stored as tracked entity attributes and be displayed in lists and the profile widget in tracker capture. When the image value type is used for a data element, the image will be visible in data entry forms.

Demo | Screenshot | Docs user guide | Docs API | Spotlight Video - Tracker Capture

The image attribute allows you to upload images directly during registration and see these images when searching for individuals. It can assist in correctly identifying cases when searching for them by providing another unique method of identifying the case.

Have a look at this by registering a new person into the notifiable medical conditions program.

Sending of messages based on program rules: You can now create program rules which trigger messages to be sent to designated recipients (through SMS, email or DHIS 2 messages) from a notification template. Messages are triggered when data is received by the DHIS 2 API based on events or tracked entity instances. This is useful e.g. for disease surveillance, where certain conditions would trigger an immediate message to a case investigator to follow up a notifiable case.

Demo | Docs

These messages can currently be sent upon event completion. This differs from sending out a program stage notification upon event completion as you will be able to create criteria that needs to be met in order for a message to be sent out (for a normal program stage notification, it is always triggered upon event completion, there are no other criteria that need to be met). This could eliminate the need for receiving messages for all events that have been completed within a program stage and instead create specific conditions for messages that need to be acted upon immediately.

Maps app: A new maps app (previously GIS) is available, offering a new, intuitive and user-friendly interface for creating map layers. It lets you arrange the order of map layers in a simple way, and view the map data in a data table. Any number of map layers can be added to a map, even layers of the same type. The contents and order of map layers can be viewed in the left side menu.

Screenshot 1 | 2 | Demo | Docs

For surveillance, the new maps apps offers a number of new functionality on top of its streamlined interface. This includes the ability to add multiple event layers, which was previously not possible. This means you are able to create maps using event locations from multiple stages and/or registration within a program. As an example you could perform a comparison of where a person is from with where they obtained a certain disease.

You are also able to rearrange the order of layers by dragging and dropping them within the new interface, eliminating the need to remember how you should add layers to the map in DHIS2. There are a number of new improvements that you can review in either the play or CBS demos.

Compare forms when entering tracker data: Individual program stages can be configured to display previous events side-by-side with the current event for ease of comparison.

Demo | Screenshot | Docs

You can compare information for repeatable program stages directly in data entry. This allows you to see what was entered for previous events within a program stage in tracker capture while entering.

Note that this feature only works in timeline data entry (where boxes for the program stages appear at the top). This does not work in tabular data entry (where boxes for the program stages appear at the left side).

Job scheduler: A new solution for scheduling of background jobs is now available. With the new scheduling system you can configure exactly when and how often a job should run, job-specific parameters for how the job should be performed and more. Multiple background jobs of the same type can now run simultaneously and provide notifications independently.

Demo | Screenshot | Docs user guide | Docs API

This new app provides a user interface for customising a variety of system-specific jobs along with the frequency they are run. This can include, for example, how often to perform validation and send out notifications, running predictors on a regular schedule, etc.

As an example, you could create a job (or multiple jobs) to control the frequency of when validation notifications are sent out. Lower priority notifications could be sent every week as a summary, where higher priority notifications may need to be sent every hour for example.

Validation message tickets: Similar to ticket/feedback messages, validation messages now have access to status, priority and user assignment. The messages will inherit the priority based on the importance of the validation result.

Demo | Screenshot |  Docs

In a surveillance context, this will allow you to automatically set the priority of validation messages/warnings that appear as these are detected in your system. As an example, detection of malaria cases in a control setting could be a low priority while detection of ebola would be high priority; this would be set when creating the validation rule and could be changed by the user when the notification is received if required.

In addition, the ticketing system allows you to assign someone to follow up with the issue directly. You can also have a dialogue regarding the identified validation violation/threshold in order to confirm an outbreak and/or clarify next steps to take.

You can have a look by accessing the “messaging” app in the CBS demo

You can read the full 2.29 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,

Karoline and team

1 Like

This is so super cool! When will other communities be included?

2 Likes

:kissing_heart: this is more characters

2 Likes