This article is accompanied by sample forms, dataset definitions and sample data saved in this folder.
Contact tracing is a public health intervention to limit the spread of infectious diseases like COVID-19. It involves identifying close contacts of confirmed cases and monitoring their health status closely. These are the key elements of contact tracing (Center for disease control and prevention):
- Communicate to people that they may have been exposed to an infectious disease and should monitor their health for signs and symptoms.
- Helping people who may have been exposed to an infectious disease get tested.
- Asking people to self-isolate if they have an infectious disease or to self-quarantine if they are a close contact.
In this article, we will talk you through a sample workflow for implementing a contact tracing workflow in SurveyCTO. Here’s what you can expect from this workflow:
|Track suspected cases, confirmed cases and contacts from confirmed cases.|
|For confirmed cases and their contacts, fill out an Initial and follow-up report(s).|
|For each of the above, keep up to date records with key indicators, including personal information, health information and test results.|
|Close or convert cases (e.g. from contact to confirmed case) automatically in response to virological test results.|
Note that SurveyCTO example workflows are highly customizable according to your project’s requirements. This workflow can be adapted to serve more specific needs.
|Note: This use case was designed prior to the release of SurveyCTO version 2.80. Newer features like long format publishing into server datasets and offline dataset publishing allow users to design systems like this one with fewer compromises. See Customization and improvements below for more details.|
2. Workflow components
Below you can find the names of the files you need to deploy on your server to test this workflow (download them from here):
|Form definition||- Suspected cases,
- Case Initial Report,
- Contact listing,
- Case follow-up,
- Contact follow-up,
- Symptom Diary,
- Virological Tests
|Field plug-ins||- table-list.fieldplugin.zip (Virological Tests),
- launch-sms.fieldplugin.zip (Suspected cases, Virological Tests, Contact follow-up),
-extrabuttons.fieldplugin.zip (Case Follow-up)
|Server dataset definition||- suspected_cases_definition.xml,
Follow these instructions to deploy them on your server console.
3. Understanding the workflow
4. Workflow path
Below, you can find the typical order of forms to be filled-out. If you’re getting started and want to test the workflow, follow these steps:
|1. Fill out the "0. Suspected Cases" form: this is where you register any suspected case and direct them to testing.|
|Publishing: Adds a new row to the "Suspected Cases" dataset.|
|2. Fill out a "*Virological Test*" form to communicate the results of the suspected case. If their test came back positive, a new case is created.|
|Publishing: Updates the "Suspected Case" dataset. If positive, adds a new row to the "cases" dataset.|
|3. Fill out the "CM: 1.Case Initial Report" form first, and then "CM: 2.Contact Listing" form. Both forms should be opened via the "Manage Cases" menu.|
|Publishing: Updates the cases dataset, and adds a new row to the "Cases and Contacts" dataset.|
At this point, there are two distinct paths happening simultaneously. You should follow-up with two different groups of cases: i) Confirmed cases, and ii) Contacts:
|1. Fill out the "*Virological Test*" form to communicate the results of the confirmed case, after their initial report. If their test came back negative, the case will close.||1. Fill out the "1. Contact Follow-up" to reach out all contacts that were registered in the contact listing.|
|Publishing: Updates the cases dataset.||Publishing: Updates the "cases and contacts" dataset, and adds a new row to the "contacts" dataset.|
|2. If the result above came back positive, fill out the "1. Case Follow-up" form for a second follow-up. The case will only be closed if the status is "Recovered", "Dead" or "Lost to follow-up".||2. Each contact should fill out the "Symptom Diary" form, on a daily basis, via Web forms.|
|Publishing: Updates the cases dataset.||Publishing: Updates the "contacts" dataset.|
|3. Fill out the "*Virological Test*" form to communicate the results of the suspected case. If their test came back positive, a new case is created.|
|Publishing: Updates the "contacts" dataset. If positive, adds a new row to the cases dataset.|
|4. If their test came back negative, fill out the "1. Contact Follow-up" form for a second and final follow-up. This form should direct patients to get a second and final virological test.|
|Publishing: Updates the "contacts" dataset.|
In a usual scenario, the above includes several different agents. For some guidelines on which agent should be responsible for which form/action, please see The First Few X (FFX) Cases and contact investigation protocol for 2019-novel coronavirus (2019-nCoV) infection (pages 63-64).
5. Video overview
6. Features that enable this workflow
This use case uses the following features of SurveyCTO:
|Pre-loading using pulldata()|
|Pre-loading choice lists using search()|
|Server dataset publishing
7. Key elements
In this section, you can find a summary of the key elements for this workflow. It might ease your understanding of how the data flows across forms and datasets. Whenever we mention "cases" below, we are referring to all types of cases in this workflow: suspected cases, confirmed cases, and contacts of confirmed cases:
- The Form Titles represent the order of the forms. However, as mentioned above, there are two parallel data collection paths, one for confirmed cases and another for close contacts:
- The confirmed cases are dealt with using our case management system, under the Manage Cases menu of SurveyCTO Collect, or the logged in web form user interface. As soon as they are downloaded, they will also appear under the Fill Blank Forms menu, so 1) we are preventing users from opening it in the wrong menu with a required note field, and 2) all case-related forms start with "CM:" to indicate "Case Management".
- The closed cases have only one form, "1. Contact follow-up", that should be filled-out for all follow-ups.
- The "*Virological Tests*" form should be filled for all cases, potentially by a laboratory facility whenever there is a new test result.
- This flow is dynamic in a way that cases can change their status (from suspected to confirmed, for example), which has an implication on which dataset they are supposed to be, and which forms they need to fill out. Given this, all datasets have a "status" column that will be the source for many actions in the workflow:
- Suspected cases:
- Confirmed cases:
Lost to followup
- Contacts of confirmed cases:
Not a case
Confirmed secondary case
Lost to follow-up
- Suspected cases:
- For each case we are always collecting the following primary personal information:
- Phone number
- Relationship to the case (for contacts)
Once this information is submitted to the server in the first form submission ("Suspected cases", "Contact listing"), it will be pre-populated into subsequent forms, updated and published into the relevant datasets.
- As this workflow starts generating data, the number of cases starts growing, and enumerators should have some guidelines on which case to follow-up and when. For that, the variable "followup" includes the date for the next follow-up. This date appears on the table view of the Manage Cases menu, and sorts your cases accordingly.
- Considering that we are listing all close contacts using a repeat group in the "Contact Listing" form, we have created a "cases and contacts" dataset as an intermediary dataset, before new contacts are registered in the "Contacts" dataset. In order to ensure that this intermediary dataset is not forgotten somewhere in the workflow (i.e., no contact is forgotten), and keeps up to date as well, there are a group of key variables to help:
- "total_contacts": this field contains the total number of contacts for each confirmed case.
- "total_followup1": this field contains the total number of contacts that were followed-up (first follow-up).
- "total_followup2": this field contains the total number of contacts that were followed-up (second follow-up).
- "general status": this field tells us when all contacts registered for a confirmed case were followed-up ("total_followup2" is equal to "total_contacts") and we don’t need to worry about that anymore. It returns "Completed" in that case, and "Monitoring" otherwise.
8. Things you may want to customize (improvements)
- Long format publishing. You can use long format publishing to add or update multiple server dataset rows at once. For example, you can set up the Contact listing form so that every contact in the repeat group "contacts" is added as a new row in the "contacts" server dataset, so it is easier to add new contacts.
- Offline dataset publishing. With advanced offline workflows, enumerators do not have to submit data to the server in order to use the data in another form. They can simply finalize the form on their device, and the data will be available for pre-loading immediately.
- Data security is key in contact tracing interventions. As most of the information we are collecting should be confidential, we highly recommend encryption for all forms. Note, however, that encrypted fields cannot be published into datasets. Our advice is to encrypt your form and make relevant (non-PII) fields publishable. If you are concerned about data security on mobile devices, learn more about how you can store data in app-specific storage.
- Customize cases/contacts unique identifier. We are creating the case unique identifier using the uuid() function to return 7 random characters. On the other hand, a contact unique identifier is the concatenation of the case id and a suffix "_*". There are plenty of other methods you can use to create unique identifiers.
- Ensuring good communication and timely follow-ups. In such a workflow, it’s key that the communication between agents is simplified and clear. Additionally, it should be combined with mechanisms to ensure that cases or contacts are followed-up on a timely manner. Take a look at our integration with Zapier, which triggers actions in third-party software (e.g. to send email), or our Google calendar field plug-in. In the same way, these mechanisms might be helpful to alert contacts that they need to fill out the "Symptom Diary" every day.
- For timely follow-ups, it is also useful that cases should have a priority hierarchy and are assigned to specific users. Case management allows you to do this using the "users" column.
- If your agents are going to use SurveyCTO Collect, make sure you configure their devices properly. Creating device default configurations will make it easier to allocate specific forms to specific user roles.
- The language used when speaking to patients or potential patients should take into account a set of principles to respect the patient, ease interaction, and minimize misunderstandings. In SurveyCTO, you can use note fields to share detailed instructions on language for those that are filling-out the form.
- Depending on the contact tracing context, these can be phone surveys. To learn more about SurveyCTO in the context of computer-assisted telephone interviewing (CATI), see our CATI starter kit guide.
- Expand on data analysis and quality control. SurveyCTO allows you to integrate with powerful analytical tools to keep track of what’s happening (e.g. Google Sheets, Power BI).
Do you have thoughts on this guide? We'd love to hear them! Feel free to fill out this feedback form.