Case management
By default, SurveyCTO Collect is set for the most standard workflow: users click Fill Blank Form and Edit Saved Form to fill out and edit forms. But you can instead organize the filling out and editing of your forms around cases in order to shift the workflow to be centered not on the forms themselves, but instead on the households, schools, health centers, patients, or other subjects of your data-collection efforts.
Organizing your data collection around case management may be appropriate when (a) you can pre-define a specific set of cases, and (b) you want one or more forms filled out for each case. As noted above, these "cases" might be households, schools, health centers, patients, or any other subject of data collection.
Click here for a video overview of case management.Here's how it works. First, you create a "cases" dataset on your server, to hold your list of cases. To do this, navigate to the Design tab, scroll down to the Your forms and datasets section, and click + and then Add server dataset; switch to the New dataset for cases tab, leave the title and ID alone, and click Create dataset. Next, click the Edit button to start adding cases to the dataset, or upload a .csv or .xlsx file that contains details for each of your cases. (For multi-team servers, you can configure different cases datasets for different teams. See below for details.)
In your cases dataset, each case should be a row with columns for each of the following details. And if you're uploading a .csv or .xlsx file, the bolded names below are exactly what should appear in your file's first row (as the names of the columns):
id. This is the unique ID that identifies each case. It might be a household ID, a clinic ID, a patient ID, a student ID, etc. It can be in any format, but each case must have a unique value, and your case list should only include a single row for each unique id.
label. This is the label that will be used to identify each case when shown in Collect's user interface. While the id is the unique identifier behind the scenes, the label is what users will see.
formids. This is the comma-separated list of unique form ID's that are associated with a case. In other words, for each case, this is the list of forms that the user can fill out. If you only have one form for a case, just include that form's unique ID here (which is the ID on its settings worksheet); if you have multiple forms, separate each ID with a comma (as in "formid1, formid2, formid3").
users (optional). If present, this is the comma-separated list of users for whom the case should be listed; the entire column can be omitted to show all cases to all users, or individual rows can have blank entries for a subset of cases that you want all users to see. Most often, you will either not specify any user names (so that the case will be listed for all users), or you will list just one user name (to list the case only for devices configured with that user name or web users logging in with that user name). If you want to list a case for more than one user (but not all of them), separate the user names with a comma (as in "user1, user2, user3").
roles (optional). If present, this is the comma-separated list of role IDs for which the case should be listed. This column helps you to filter the case list – but instead of filtering by individual user (just above), this filters by user role. If you list one or more unique role IDs for a row, then only users in those roles will see the corresponding case.
enumerators (optional). If present, this is the comma-separated list of enumerator IDs for which the case should be listed. This column helps you to filter the case list – but instead of filtering by individual user or role (just above), this filters by enumerator. If you list one or more unique enumerator IDs for a row, then only those enumerators will see the corresponding case. Note that when you use the enumerators column to filter cases by enumerator, you need to link the appropriate enumerator dataset in the cases dataset's settings. See here to learn more about linking cases and enumerators.
sortby (optional). If present, cases will be listed in the order indicated by the numeric values you enter in the sortby column (from low to high); if not present, cases will be sorted by their id values.
Please note that values in the users, roles and enumerators columns are optional (not the columns themselves).
When you first create your "cases" dataset, you can also choose how the case list should appear to users: as a "tree list" in which all cases appear with all relevant forms indented underneath, or as a more compact "table" that summarizes information about each case and allows the user to click to see the relevant forms for each. If you select the table view, you can choose which columns, from your cases dataset, to display, in which order; you can include the standard columns listed above – or other custom columns if you've included them in your dataset – and users can scroll to find the appropriate cases, click column headings to sort, and enter text to filter the list as needed. If you want to change how your case list displays, you can always go back to edit the Settings for your cases dataset.
Once you have a cases dataset on your server, logged-in web users will automatically see a Manage Cases button, and the case list shown will always be the latest one. For users of SurveyCTO Collect on mobile devices, you will need to manually enable the Manage Cases button: from the main Collect menu, open the three-dot menu in the upper-right, choose Admin Settings, and then enable the checkbox next to Manage Cases; when you return to the main menu, you should see a Manage Cases button at the top. Once mobile users click into Manage Cases, they can click Refresh to load the latest cases from the server.
The list of cases shown to the user will be filtered based on the current user, role, and/or enumerator, according to the users, roles, and enumerators columns in the cases list (if any). If you filter based on enumerator, then you need to link the appropriate enumerator dataset in the cases dataset's settings, and the Manage Cases interface will require that the current enumerator identify themselves. See here to learn more about enumerator support in case management.
For each listed case, the user will have the opportunity to fill out any of the forms listed in the case, edit saved forms, and (on a mobile device) see a list of finalized forms; if a mobile user hasn't already used Get Blank Form to download all of those forms to the device, they might see some errors about missing forms. If all of your forms will be filled out via Manage Cases, you can disable the Fill Blank Form and Edit Saved Form buttons in Admin Settings of the mobile app.
If you have enabled auto-downloading of form updates in the mobile app's General Settings, then updates to the case list will be automatically downloaded as well (with Collect checking for updates roughly once per hour when connected); alternatively, you can always re-download the latest cases by clicking Manage Cases and then Refresh.
Finally, you can automatically store the unique case ID as part of your form data – and even use that ID to, e.g., pre-load data for the case – by including a caseid field in your survey. Actually, new forms begun with SurveyCTO automatically include such a field, just in case you're using case management; in the online form designer, you can check to make sure that it's included as a meta-data field in the Form settings. The caseid field will be automatically populated with the unique id of the case for which the user filled out the form (if they filled out the form using the Manage Cases interface; otherwise it will be blank). You can then use that field to pre-load data and/or track data associated with the case.
You can use this case-management interface to customize your data-collection workflow. See also Designing workflow for more options available to you.
Case list as server dataset
In SurveyCTO, the case list is always stored in a server dataset – so you can also attach that list to any form as pre-loaded data, publish form data directly into the case list, publish the case list to Google Sheets, and more. For example, form data that is published into the case list can update existing cases and generate new cases.
See Advanced publishing with datasets and Pre-loading data into a form for more about your options for working with server datasets.
Offline case creation and transfers
As discussed above, dataset publishing can be used to generate new cases, but this can also work offline using offline dataset publishing. A single form submission can also populate one or more dataset rows (including those of a cases dataset) when you pick long format publishing, as discussed in Publishing form data into server datasets, generating new cases.
Pre-existing and newly generated cases can also be transferred offline, between devices, adding a great deal of flexibility to data-collection workflows, which you can learn about in Offline case transfers.
Learn more about such possibilities in Designing advanced workflows.
Different case lists for different teams
By default, all users share a single case list, in the server dataset with the unique ID "cases". This is fine for single-team servers, but on multi-team servers each team should be allowed to independently manage their own case list. Otherwise, a single shared case list might quickly become too large and unwieldy to manage.
When you add a new team and create new roles for that team, those roles are automatically assigned a cases dataset ID like "cases_teamid", where "teamid" is the unique ID of the team. Just click to edit any user role to view or edit that role's cases dataset ID. When users in that role login, they will see that role's case list, within the role's cases dataset, instead of seeing the case list in the global "cases" dataset. Meanwhile, users in global roles – or in custom roles that don't have any cases dataset ID specified – will continue to see the global case list in the "cases" dataset.
So when you set up a new team on your SurveyCTO server, you should (a) ensure that the team's user roles all have an appropriate cases dataset ID configured, and (b) communicate that ID to the team manager so that he or she can create and manage the cases dataset with that ID.
Different case lists on a single-team server
Even on a SurveyCTO server with only one team (and inside a team), it is possible to create more than one server dataset for case management. If you have already created a case management dataset with the global ID "cases", simply create a new server dataset for cases and give it another ID.
In order for a user to see and use this non-default case list, they must be assigned a custom user role which is assigned a different cases dataset. In the user role creation process, look for the option to provide the dataset ID for case management. There, specify the ID of the new cases dataset.
