00:00:00 Introduction

Welcome to everybody joining today. We are going to go through three major things today regarding information management systems for case management. First, we will look at data modeling and how we understand the data involved in a case management system. We will look at some templates available to help you get started. Then, we will look at customizing roles and access to data, as data security for a case management system is very important. Finally, we will look at some of ActivityInfo's built-in reporting and analysis tools that will help you drive more impact for the people you are working with.

00:00:56 Data modeling

Let's talk about data modeling. This refers to the information we need to support our caseworkers and how we structure the relationships between those pieces of information. ActivityInfo uses a standard case model where each new case—whether an individual or an incident—is represented as a form. We then have subforms for different types of incidents, repeating information, or specific information, followed by a case closure form. These are one-to-many relationships; for example, one case could have several general protection incidents, case updates, or referrals. The case form brings all that information together in one line so you can see the status of the case.

This is not the only way to structure case management. In some contexts, you might have many teams providing services to the same group of people. In this structure, you might have a single individual and then one team doing an assessment, another team providing distributions, and an education program with its own structure of classes linked to teachers and schools. The structure is driven by what information you need for monitoring and evaluation and for administering your work.

A final example is an incident referral structure. I recently saw a structure where the user needed to identify the needs of survivors and follow up on them. They created four levels of subforms: an incident (e.g., a violent attack) at the top, followed by survivors of that attack, then the specific needs of each survivor (housing, health, cash), and finally, referrals for each need. This structure allows you to ensure each need is met for each survivor.

00:07:10 Demo: Protection case management template

Let's go to ActivityInfo and look at how this plays out in practice. In the documentation site under templates, you can find the Protection Case Management database, which follows the standard case management model. In this database, the key form is the "Case" form. Within this top-level form, you have several subforms that provide more detail.

A caseworker would start by adding a new record. In this template, cases are organized by region. There is a separate form for confidential biodata, which is a nice way to keep personal information separate from the rest of the form. This allows you to give your M&E team access to statistical data without exposing personal information. You can collect registration numbers, names, and contact details here.

Inside a specific case record, you can see details about the individual, upload documents (including scans), and view demographic information like age and risk rating. There are separate subforms for specific issues, such as Gender-Based Violence (GBV). ActivityInfo also has a mobile app that allows caseworkers to work in the field. The app provides a complete replica of the database, allowing caseworkers to not only submit new records but also review case details and make updates from their phones.

Back on the desktop view, you can summarize subform information in the main case file. For example, we can have a calculated field that computes the status. If a closure record exists, the case is considered closed; otherwise, it is open. You can modify form settings to add new fields, such as nationality, or create calculated values, such as the age of the person when the case was opened. You can also summarize subforms, for example, by adding a calculated field to find the date of the last referral or follow-up.

00:16:27 Demo: Multi-team case management template

Now let's look at the second template, the Intensive Multi-case Team Management. In this structure, rather than nesting all details, we split them out as forms that reference the original case. We still have a backwards link to see case details from the main form.

When adding a new case, you add the biographical information and registration date. Once a person is added to the registry, other teams providing services, like distribution, can reference that case ID. For example, a distribution team can record providing non-food items to case 001. Similarly, a health team can reference case 001 to record a home visit and medical notes.

If you go back to the main case record for 001, you can see a full list of all services provided, including distributions and medical care. This approach is useful if you have completely different teams working with the same beneficiaries. You can give each team access only to the information they need. For instance, an education team can record classes and progress scores, and all these references remain visible in the main case file.

00:21:40 Customizing roles and access

Now I want to talk about customizing roles and access to data. Information in case management is generally sensitive, so we want to limit access as much as possible. Common permission schemes include limiting caseworkers to see only their own records, limiting teams to specific types of cases (e.g., GBV team vs. Child Protection team), or limiting partners to see only records belonging to their organization.

Let's look at how to apply these roles in ActivityInfo. To define a caseworker role that can only see records they are assigned to, we grant resources to the protection cases form. We specify permissions to view, add, and edit, but we add a condition: the record must be assigned to the user. This is done via a "User" field in the form design. We can also grant view-only access to reference data like position codes.

You might also want to limit access based on the type of incident. For a GBV team, we can create a role that allows them to view, add, and edit records only when the protection category is "Gender-Based Violence." You can also explicitly take away permissions for specific subforms, such as ensuring the GBV team cannot see the Child Protection subform.

For working with different partners, we can add a "Partner" form and link it to the case form via a reference field. In the database settings, we can create a "Partner Caseworker" role using a parameter. This allows us to define one role that applies differently depending on the user's assigned partner. We set a condition that the user can only view or edit cases where the partner field matches their assigned partner parameter. You can combine these conditions, for example, creating a "Child Protection Partner Caseworker" who can only see records related to their partner and where the category is Child Protection.

00:38:33 Reporting and analysis

The final section is reporting and analysis. While caseworkers need specific details, managers need an overview to ensure services are provided on time and to measure program effectiveness. We can use the dashboard editor to create visualizations.

For example, we can create a pivot table to count open cases per caseworker to monitor caseloads. We can filter this by case status to ensure we are only counting open cases. We might also be interested in whether a case is overdue. We can add a calculated field to the form to determine the number of days a case has been open using the DAYS function combined with the TODAY function. We can then visualize the average number of days cases have been open, broken down by risk level, to identify if medium or high-risk cases are remaining open too long.

00:45:30 Q&A session

Question: In a project working with GBV, a single individual might have different situations reported over time. Can we close a report within a case while keeping the individual case open? Answer: Yes, that is a common scenario. You can structure the database so that the protection case remains open, but you have subforms for specific incidents. You can track a status for each incident separately. For example, you might close a specific incident because you provided medical attention or mitigation, even though the case is ongoing. You can add a "Reason for closing" field to the incident subform that only appears when the status is changed to closed.

Question: I don't see the "Roles" option in my database. Answer: You likely do not have the "Manage Roles" permission. Even if you are an administrator, the database owner must explicitly grant the "Manage Roles" permission for you to see and change roles.

Question: How do we insert data when a case receives the same service twice during a period, such as two home visits? Answer: In the multi-team template, we have a "Home Visit" form. To allow repeating services, you ensure your key fields are set correctly. If you set "Case" and "Date" as key fields, you can record multiple visits for the same case as long as they are on different dates. You can then summarize this data in the main case form, for example, using a calculated field to find the last glucose measurement taken during a home visit.

Question: How do we handle duplicates? Answer: You can use Key Fields in the form settings to prevent duplicate entries based on specific criteria (e.g., preventing the same home visit on the same date). For preventing identity fraud or duplicate registration of people, you can use barcode or QR code fields. You can issue cards with QR codes to beneficiaries and scan them within the mobile app when services are provided to ensure the correct record is accessed.