---
title: 'Safe Contact by Gray Wolf Analytics'
---

Safe Contact by Gray Wolf Analytics

## Table of Contents
[TOC]

## Introduction
"test trace isolate" is the mantra of what has proven to be one of the most effective approaches to slowing down a pandemic for a disease that has no vaccine or suitable treatment. This approach can be summarized into 3 steps:
1. Perform high volume **Testing** to identify people who are infected and are at risk of spreading the illness
2. **Trace** all of the people this person has been in contact with who are at risk of being ill and contagious
3. **Isolate** everyone who is at risk of being contagious and spreading the infection more.

The goal of `Safe Contact` is to help reduce the spread and impact of COVID-19. Our approach is by making step two, tracing everyone that an infected person has been in contact with, easier and more efficient. This step can be referred to as `Contact Tracing` which the article "[What is Contact Tracing?](https://www.cbc.ca/news/canada/coronavirus-covid-19-contact-tracing-app-1.5558512)" by CBC describes as:

> Contact tracing is about identifying, informing and monitoring people who might have come in contact with a person who has been diagnosed with an infectious disease, such as COVID-19.

Currently tracing in Canada is a very manual job and involves interviewing the patient and trying to get them to remember every place they've been and who they've been in contact with for the past 14 days.`Safe Contact` is a mobile application that helps people keep track of where they've been and who they have been in contact with, so if the time comes that you need to trace back in your head all your steps for the past 14 days, you can use Safe Contact to help! Building a mobile application to facilitate and aid contact tracing involves implementing features that exist on a gradient from completely manual processes to an automatic process. The ideal contact tracing mobile app is one that users download once that automatically and privately keeps track of everyone a user has been in contact with and every place they've been. However, building an application that does that is very difficult. With Safe Contact we are taking the approach of first building a system that does everything manually, acting as a guided digital notepad for the user. Once we have the manual features put in place, we'll start building automation on top. This way if the automated features fail work, the user can always fall back to a manual approach.

Currently Safe Contact has two methods for aiding contact tracing

1. [Manually Logging Visited Locations](#Manually-Logging-Visited-Locations)
2. [Background Geolocation Logging](#Background-Geolocation-Logging)

## Introduction Sequence
I didn't know if this merited it's own section but in the end I decided that it did. This will briefly describe the "intro" sequence that happens when you first open the app. I suppose the best way to describe this sequence is in a list?
1. Always go to the loading screen first.
2. Check if `"AID"` (Anonymous ID) exists in storage. Right now, the way we determine if a user has gone through the introduction is if the `"AID"` can be found in storage (we previously used this `AID` value but it isn't really being used at the moment). If the `AID` is defined, we send the user to the dashboard. If it hasn't been defined yet, we create an "introdcuer" (an object which contains the navigation logic for the introduction) and tell it to navigate to the first screen.
3. The "introducer" kinda takes over from here. When created, it first checks the motion permission status and location permission status (check out [this documentation](https://github.com/react-native-community/react-native-permissions#ios-flow) to find our more about a permission "status"). It will use this information while navigating to determine the next screen to go to. It also creates a `step` variable which holds the value of the current step. When someone calls `next()`, it uses the current step along with the permission information to determine the next step to go to. For example, if the `step` is null, immediately go to `intro`. If the current step is `"enable-motion"` and the location permission is currently `"denied"`, it navigates the user to the location enabler screen.
4. Once all of the intro screens have been traversed, it navigates the user to the dashboard.

:::warning
Right now, if a user completely closes the app while midway through the setup process, they will be redirected to the dashboard upon opening the app the next time.
:::

## Manually Logging Visited Locations
This system is pretty intuitive! There are known locations (locations you've found using the google nearby search) and visited locations (your actual visits). There is a one-to-many relationship between a known location and visited locations. There is also the concept of a current location which is basically just a visited location without an end time.

## Background Geolocation Logging
We currently do background geolocation logging using GPS data (although this data could come from other sources such as Wifi or a cell tower). If you're working on this system, you should be familiar with is how each OS does location services. For example, iOS has multiple location services (including the `Standard Location Service` and the `Significant-Change Location Service`) which both use a geofence to send updates. Currently, our system uses the `Standard Location Service` from iOS to measure the distance every `10m`. Another example is that on Android you can ask to receive a location every `X` minutes whereas on iOS that's not possible.

We currently use [`react-native-background-geolocation`](https://github.com/transistorsoft/react-native-background-geolocation) which, according to their README, gives us "sophisticated, battery-conscious background-geolocation with motion-detection". The [docs](https://transistorsoft.github.io/react-native-background-geolocation/classes/_react_native_background_geolocation_.backgroundgeolocation.html) are well done and a great reference for learning about how the system works under the hood! To give a quick overview, we configure the library to take a location every `10m` with high accuracy (ie. use GPS) and to store the data for 3 weeks (note that the library automatically stores the data in the native `SQL` database). Another few important things we do is tell it to start on boot and to keep running after the user puts the app in the background.

Other than exporting their data, a user can also use the timeline tool to view their location history over the past 3 weeks (or a subset of that time using filtering tools). This uses a clustering library and Google Maps!

## Daily Questions
The daily questions are a pretty simple concept but are actually a bit confusing under the hood. There are a lot of things you need to think about during development:
1. Language support. The title *and* the options need to support English and French.
2. Being able to review your answers later (ie. after finishing a daily update).
3. Being able to go back if a user need to change an answer.
4. Conditional rendering of questions (e.g. only ask for a temperature iff they answer yes to having a fever).
5. Supporting custom questions. Most questions are just simple "yes" and "no" questions but some are more complex (e.g. the temperature input).
6. TypeScript support. It would probably be much easier to do this in vanilla JavaScript but we would lose TS support.

Ideally, we have a very nice declarative system where we can use some kind of object to define the structure of our questions. I've experimented with this before and I think it would be a good idea to return to it later. How does it work right now though?

First, we have a type union of all of the steps and the `DailyQuestionsType` defined using [io-ts](https://github.com/gcanti/io-ts). I've recently added a section in the "Getting Started" guide about `io-ts` which you should look at first! The `DailyQuestionsType` type basically defined *how* we store responses and allows us to confirm the structure of the data at runtime!

// storage.ts
export type DailyQuestionsStep = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11;

export const YesNo = t.union([t.literal("yes"), t.literal("no")]);

export const DailyQuestionsType = t.type({
  tested: YesNo,
  feel: t.union([t.literal("normal"), t.literal("not-right")]),
  description: t.string,
  fever: YesNo,
  temperature: t.union([t.number, t.literal("no-fever"), t.literal("skipped")]),
  cough: YesNo,
  fatigue: YesNo,
  shortnessOfBreath: YesNo,
  diarrhea: YesNo,
  location: t.union([
    t.literal("home"),
    t.literal("hospital"),
    t.literal("back-at-hospital-want-to-tell"),
    t.literal("back-at-hospital-already-told"),
  ]),
  treatment: t.union([
    t.literal("none"),
    t.literal("oxygen-and-fluids"),
    t.literal("non-invasive-ventilation"),
    t.literal("invasive-ventilation"),
    t.literal("other-treatment"),
  ]),
});

:::warning
Note that the location of types/interfaces will not always make sense and please feel free to reorganize. I think "DailyQuestionsStep" is a good example as I think it could be moved to a better location.
:::

This is important to ensure that we didn't miss any steps. I'll try to explain this more later. Next, we define the labels of all of the questions and the multiple choice questions options.

// questions.ts
export const updateQuestionsLabels: { [K in UpdateQuestionsKeys]: string } = {
  tested: languages.t("testedLabel"),
  feel: languages.t("feelLabel"),
  description: languages.t("descriptionLabel"),
  fever: languages.t("feverLabel"),
  temperature: languages.t("temperatureLabel"),
  cough: languages.t("coughLabel"),
  fatigue: languages.t("fatigueLabel"),
  shortnessOfBreath: languages.t("shortnessOfBreathLabel"),
  diarrhea: languages.t("diarrheaLabel"),
  location: languages.t("locationLabel"),
  treatment: languages.t("treatmentLabel"),
};

// This is just one example (it's the most used) but there are more for other questions which
// aren't just "Yes" and "No"
export const YES_NO = [
  { label: languages.t("yes"), value: "yes" },
  { label: languages.t("no"), value: "no" },
] as const; // Note the "as const" here. This is very important!

Finally, there is `DailyQuestions.tsx` which contains the bread & butter of this system. The first thing to note is that this screen actually expects data to be passed in as props.

data?: {
  step: DailyQuestionsStep; // ie. 1 | 2 | 3 ...
  answers: DailyQuestions; // the answers
};

These are then initialized in the body of the component.

const { step, answers } = props.route.params.data ?? { step: 0, answers: DEFAULT_ANSWERS };

A `getQuestion` function is defined which takes in the `step` value and spits out `JSX` representing the question for that particular step.

case 3:
  return (
    <DailyQuestionSelectTemplate
      type="select"
      options={YES_NO}
      label={updateQuestionsLabels.fever}
      onInput={(value) => goTo(value === "yes" ? 4 : 5, "fever", value)}
    />
  );

In the example above, note that the `updateQuestionsLabels.fever` is given as a label, the `YES_NO` options are given and `onInput` conditionally goes to step 4 or step 5 depending on the answer. The `"fever"` string is the object key and `value` is the `"yes" | "no"` value. Because this is `TypeScript`, all of this is completely typed. If I put `"fever"` instead of `"fever"` or `value` wasn't just `"yes"` or `"no"`, TypeScript would complain!

Anyway this code is *ok* IMO but kinda messy and could easily be improved!

Talk about how location logging works (known locations, visits, current location).

Discuss introduction briefly. Note the different permission states, how we need to check before we actually navigate to a screen. Also discuss the AID which is now we know a user has gone through the introduction phase.

## Conclusion
Hopefully all of this information helps! Try to use the TypeScript types to your advantage. I always find data structures really help be understand someone elses code. There will certainly be things in the code that shouldn't be the way they are so don't be scared to refactor things since we can help validate your changes during peer reviews!

## Appendix and FAQ

:::info
**Find this document incomplete?** Leave a comment!
:::

###### tags: `Gray Wolf` `Safe Contact`