Content
- General requirements
- Practical information
- Case background
- Case 1 - Working list
- Case 2 - Cluster management
Some updates and clarifications
A clarification regarding test users and choosing a municipality.
You only have the possibility of testing the app with your own accounts, which are assigned to “Norway” rather than a single municipality (as a typical user of your app would be). To get around limitation, you can do the following in your app:
- if the user is assigned to one organisation unit and the case/contact/cluster programmes are assigned/available to that organisation unit, that organisation unit should be used
- otherwise, use a municipality that you choose (hardcode) for testing purposes
If you have developed or plan to develop a UI component for choosing an organisation unit as part of the app, you can of course just use that rather than having the hardcoding as a fallback. But this is not part of the fundamental requirements.
General requirements
- The basis for your application should be generated using the App Shell/Platform using the command d2 app scripts init <appname> (description here).
- The DHIS2 Headerbar (available through the dhis2 ui-widgets) must be included in the application. The Headerbar is integrated in the App Shell/Platform.
- The DHIS2 ui-core component library must be used in the design of user interfaces in your solution. If the library does not have the needed components, you can use other libraries or pure html/css, but follow the dhis2 design principles
- The application must be runnable as an internal app in dhis2
Keep in mind
- Using the App Shell/Platform, make sure not to add your file into a folder hierarchy with naming conventions using spacing
Practicalities
- The deadline for the project is HARD, as it is considered a home exam (rules about home exam).
Grading
For each case, a set of fundamental requirements and potential additional features are listed. For the group to receive a C grade on the project, all the fundamental requirements must be met. Beyond C, it is expected that your solution incorporates functionality beyond the fundamental requirements. The additional features listed serve as suggestions of such functionality, not meaning that you have to implement all of them in order to achieve a top grade. The amount of functionality is only one aspect of the evaluation of your projects. See the evaluation form for more details on how the projects will be evaluated (will be published soon).
Practical information and getting started
Each student will be provided with an account in a development server https://course.dhis2.org. You will receive an invitation by email (UiO account) with a link to an account registration page. Here, you will be asked to create a password, and enter additional account details (you do not need to provide your real name, phone number etc - feel free to make something up).
The development server will be backed up regularly, and if something goes wrong (i.e. someone mistakenly messing up some part of the configuration), we may have to restore a backup of the database and some test data may be lost. This will not affect the source code for your apps, which is hosted in a repository elsewhere.
Test data
For both the two cases described below, you will be responsible for entering test data (cases with contacts, and clusters). You should enter enough data to have a realistic environment to work with during development, and also during the final presentation. Doing this at the beginning of the project will also help you get familiar with the work flow and configuration. We suggest a minimum of 20 cases with 2-20 contacts each (Case 1) or at least 5 clusters with 2-20 linked cases (Case 2). Be prepared that you will probably have to add (or move) data over the course of the project as well, to have data both in the past, present and future.
Test data should be entered at the municipality level of the organisation unit hierarchy (i.e. select a “kommune” before entering data), which is where data entry happens in reality. If you want to have a (relatively) isolated testing environment, try to find a different 'kommune' than the other groups. Please avoid real people’s names, ID numbers, phone numbers etc when creating test data.
The video below is demonstrating how data is entered.
Case background
Managing the ongoing COVID-19 pandemic requires tools for registering positive cases, tracing the contacts of these cases, and identifying and managing clusters of cases. The DHIS2 platform is currently used for these purposes in over 30 countries around the world, and in more than 50 municipalities in Norway.
The DHIS2 platform includes core applications that support these activities, however, because these core apps are generic, there are aspects of the user experience around the recording of data on COVID-19 cases, contacts and clusters that are not optimal. The two cases both involve making DHIS2 apps to improve the work flows of managing COVID-19 data. Often, the users of these apps will be transferred from other tasks and have no previous experience with DHIS2 and receive little training in advance. User friendliness is therefore important.
COVID-19 in DHIS2
The use of DHIS2 for COVID-19 covers three cases, all using the part of DHIS2 referred to as “Tracker”, which is for data on individual events and cases. First, registering confirmed (also called “index” cases). These are cases that have a positive lab result, which are registered so that they can be follow-up on and advised about rules on isolation etc. Second, all contacts of a confirmed case are registered, so that they can be contacted, informed of potential exposure to COVID-19 and advised to go into quarantine. Finally, “clusters” can be registered. Clusters are used to relate confirmed cases to each other for analytical or management purposes. For example cases that have been infected as part of the same cruise or the same student party.
The part of DHIS2 related to aggregate data (i.e. weekly or monthly data) is not described here, as it is not relevant for the cases.
Important elements of the DHIS2 data model
When developing your application you will be interacting with DHIS2 and the DHIS2 data model through the API. Here are some important concepts of the data model used in the COVID-19 system:
Tracked entity types
Tracked entities are, as the name implies, the “entities” that are being tracked, and they are enrolled in programmes in which information is recorded. For COVID-19, there are two types of tracked entities:
- Person
- Cluster - an epidemiological entity, loosely defined as a time/space that links two or more cases
Programmes
Information in DHIS2 is recorded through pre-defined programmes, that have one or more program stages containing variables (data elements) for data collection. Programmes can be thought of as a predefined workflow, where each program stage is a data collection form related to an event. Examples of program stages could be “Lab results”, “Follow-up”, “Health Status” for example.
For COVID-19, there are primarily three programmes:
- Index case surveillance - programme where confirmed/positive cases (persons) are recorded
- Contact registration and follow-up - programme where contacts of a index case are recorded
- Cluster registration - programme for recording clusters, including geographical boundaries where applicable (note: does not have any program stages).
Relationships
Relationships define a relationship between tracked entities. This is used to link one or more contacts to an index (positive) case (“Member of same household”, “Social interaction”, “Work/university colleagues” etc), and to link cases to clusters.
End-user workflow
The primary end-user in both cases are health workers or contact tracers. Typically, health workers are responsible for registering and following up on the confirmed (index) cases, including obtaining a list of possible contacts, since this involves giving medical advice and assessing medical symptoms. Contact tracing, on the other hand, can be done by personnel that is not medically trained. Contact tracers are responsible for reaching out to contacts of confirmed cases, advising them to quarantine. In some municipalities, the same person or persons fills both roles.
The starting point is a confirmed positive COVID-19 case. The case is registered in DHIS2, and enrolled in the “Index case” programme. In the index case programme, information is recorded about symptoms, underlying diseases etc. All close contacts of the case are also registered, with at least name and phone number. The contact and the index case is linked with a relationship in DHIS2, and the relationship type defines the type of contact (household member, work colleague etc). A follow-up is scheduled for the index case, so that health workers can follow up on the case after a number of days (depending on the severity of the disease). When the case has recovered, the enrollment into the programme is closed and no further action is taken.
All close contacts registered based on information provided by the index case are contacted by health workers or “contact tracers”, and given advice on how to behave (quarantine, schedule COVID-19 test etc). If a contact is later confirmed with COVID-19, they are registered as index cases as described above.
When there is a suspicion that several people have been infected in the same time/place, health workers/contact tracers can define a cluster, and link individual cases to this cluster. This helps monitoring and analysis of disease patterns, and the information can, for example, be used to identify additional contacts (based on being somewhere at a specific time/place), guide decisions to close e.g. a gym, school etc.
Case 1 - Working list
The first case is to develop an app that helps the health workers and/or contact tracers keep track of the cases and contacts they need to follow up on. Some places, the same user registers index cases and follows up on cases, in other places these are different roles (e.g. health personnel might contact index cases and other personnel might work as contact tracers). However, whether it is the same or different persons, they need an app that lists the persons they should contact at any given time. The date for follow-up calls are based on the “Due dates” of the program stages, i.e. cases with a “Health status” or “Follow-up” program stage with due date today should be included in the list for today, those with a “due date” tomorrow should be included in the list for tomorrow etc. There is some support for this in the DHIS2 core app, but this has limited functionality.
Fundamental requirements:
- Show an overview of index cases and contacts to be contacted on a particular day (default = today), both cases and contacts together in the same list and separately.
- From the list, it should be possible to go directly to the data entry form for a specific case (by opening the Tracker Capture app for that particular case).
- It should be possible to generate an overview of the workload for the coming days, i.e. number of follow-up calls to be made by day in the next e.g. 5,7,14 days (based on scheduled events in the index and contact programmes)
Non-exclusive list of potential features:
- Show useful additional information in the list, for example:
- total number of contacts per case
- contacts that have been follow-up on so far
- showing a “sub-view” with contacts linked to the same case
Keep in mind that the purpose of this app is to simplify the work process of the workers following up on index cases and contacts. The listing should include all the cases/contacts a particular user has access to.
Some fundamental APIs to work with
- Getting a list of index cases and contacts:
- /api/trackedEntityInstances
- Getting a list of required and optional attributes:
- /api/trackedEntityAttributes/
- Tracker Capture App URLs:
- /dhis-web-tracker-capture/index.html#/?program=<programId>
- /dhis-web-tracker-capture/index.html#/dashboard?tei=<trackedEntityInstanceId>&program=<programId>&ou=<organisationUnitId>
Case 2: Cluster management
The second case is to make an app for showing information about clusters. As explained in the background section, when there is a suspicion that several people have been infected in the same time/place, health workers/contact tracers can define a cluster, and link individual cases to this cluster. This helps monitoring and analysis of disease patterns, and the information can, for example, be used to identify additional contacts (based on being somewhere at a specific time/place), or guide decisions to close e.g. a gym or school. In DHIS2 clusters are stored as tracked entities enrolled in a programme. Only a limited amount of information (attributes) are recorded for each cluster, however, the cases linked to a particular cluster are also highly relevant information. Note that the Cluster tracker programme does not have any program stages (or data elements). Clusters and cases are linked using the relationship functionality.
Fundamental requirements:
- Showing an overview of all clusters, with key information.
- Show details for one cluster, including cases and contacts linked to the cluster.
- For clusters that have geographical coordinates, it should be shown on a map.
Non-exclusive list of potential features:
- Summary of information about cases/contacts linked to a cluster.
- Map showing all clusters accessible to the user, potentially with information on number of cases linked to each.
The listing should include all the cases/contacts a particular user has access to.
Some fundamental APIs to work with
- Getting a list of clusters or details for a specific cluster
- /api/trackedEntityInstances
- Getting relationships between cases and clusters
- /api/relationships?tei=<trackedEntityInstanceId>
- /api/relationships?enrollment=<enrollmentId>