As part of Compass Pathway’s mission to bring evidence-based care to people suffering from mental illness, we’re using a custom phone app as part of our phase 3 trial. This app, in addition to providing patient education about the COMP360 treatment, collects (with the patient’s consent), longitudinal participant behavioral data (for example, number of minutes spent exercising). Such information can later be analyzed to identify differences over the course of the trial. In short, this data may tell a story and assuming the patient is willing, we want to be able to analyze it in order to potentially help future patients.
However, collecting health data in a clinical trial can be challenging due to several reasons. The first and most critical issue is that we need to be able to collect information on a per-participant basis anonymously until the trial completes and we can look at the data. Second, we need to make this as easy as possible on the participant so that it doesn’t have a significant impact on the patient’s daily life and fades into the background.
In this blog post we’ll look at how we solved this issue while allowing a participant to still authenticate in a mobile application and thus provide us with a unique anonymized token that is associated with a specific, but unknown, individual.
At this point, it’s important to note that participant actively consents for every type of data that is collected by the app during the onboarding process in the trial. Moreover, the user can disable the collection of each data type at any point in time in the application as well. Finally, the mobile app does not have access to any data on the device that can be used to identify the user. For example, any location data is obfuscated immediately and Compass never receives it.
Authentication and signup flow
Obviously, we can’t use an email + password combination as that can be used to identify a specific person. Of course, this also disables any social login as all these methods pass back some information about the user. Instead, we use a one time code that is generated on-the-fly during the onboarding process when the participant is having their first visit. To make the user experience easier we use that code to also generate a QR code so that the patient could simply scan a graphic rather than manually type the combination. As mentioned above, this is all conditional on the patient consenting to share their data.
Once the QR code is scanned, the phone automatically opens the relevant Apple or Google app store and brings the participant to the Compass myPathfinder application. Upon downloading the app, the participant gets logged in automatically, and in case this doesn’t happen, they simply scan the QR code again. There are no passwords or usernames for the participant to enter (or any other information for that matter). All of this happens completely behind the scenes and is invisible to the participant. Further, once the participant is logged in, the code can never be used again. Should the user switch phones (due to loss, upgrades, etc), the site coordinator would generate a new QR code and provide it to the participant.
App Onboarding
As part of onboarding in the app, once the participant is logged in, they are provided with rationale for how and why personal data is collected and used. They are also provided with a clear and actionable way to take control over which data sources are shared via permission settings on the device.
Architecture
Before diving into the core implementation, lets first take a look at the architecture diagram and the relevant services. We’ve implemented all these services in our AWS cloud infrastructure.
Services running in AWS
Below is the architecture diagram that we use for managing the mobile app. Note that we only show the subset of services relevant for this post.
Architecture diagram of services used to support the mobile app
API Gateway
Access point for the backend services where the initial authentication of users is performed.
AWS Cognito
AWS Service for management of users and user pools. All users and their passwords are stored in Cognito. Different client (mobile app, web app) settings of how long an access token and refresh token persist are also configured here.
Admin Web UI
Custom user interface developed by Compass for managing its clinical trials. Each clinical trial can be configured differently. These differences include settings for location, app features, data points to collect and participant data sharing preferences. Basic information about app usage and last data collection by participant can be viewed here as well.
Auth Service API
Micro-service that exposes an API to the Admin UI. The Admin UI then uses this micro-service to create the participant entry in Cognito as well as the one-time-code.
Device Data Service API
Micro-service that exposes an API to the mobile app allowing the device to upload its data to the Compass AWS cloud.
Content Management System (CMS)
This system manages the patient information content that is presented to the participant in the mobile app during the course of the trial. Both the content and language might be different and is based on the study that the individual is participating in as well as their preferred language settings.
Sequence
Now that we’ve looked at the flow from a user perspective, let’s dig deeper into what happens on the backend. We can break the process down into two main parts:
1) Administration: This is where all the user settings are generated by the site coordinator and stored in our systems. These settings include the one-time-code that is specific to the user. All these settings are controlled in the Admin Web UI.
2) Participant Login Flow: This is the set of services that authenticate the user, pull the correct settings and configure the app on the fly to adhere to these settings.
User and One-Time-Code Creation
Sequence of generating a participant and the one-time-code
Participant Login Flow
Sequence of the one-time-code flow used by the mobile application
For HTTP requests where the login fails or other unexpected errors happens, the auth service returns a 404 status code. It returns this code to prevent any data leaks to clients — this way absolutely no information is returned that can be mined or reverse engineered. More meaningful logs are stored in the Compass AWS logging system with alerts setup for the engineering team.
Difficulties with no login information
In many clinical trials, participants are followed for a prolonged period of time, sometimes upwards of a year. This presents unique challenges on both the device (client) side as well as the server side. We explore some of them below:
Client Side
As the user doesn’t have a login username/password, it’s critical that the app store the access tokens received from AWS Cognito for a prolonged period of time. On the iOS side we, we use the the Apple Keychain to store and back up the tokens to iCloud. On Android devices, the SDK allows us to store the tokens via the SharedPreferences interface which is backed up by default.
Server Side
Now that we have looked the client side, let’s consider how to configure the server side of the equation in order for things to work smoothly.
First, we need to go into AWS Cognito and change the refresh token expiration time for our participant user pool. We want to set the expiration to be long enough for the participant to finish the trial (six months, 1 year, etc) — the details will depend upon the trial set up. AWS Cognito allows for up to 10 years! Remember, the goal is to let the user get through the clinical trial without getting logged out but no longer.
However, if for some reason the participant does have to login again, they will have to get a new code generated by the site coordinator. To help with this, we have dashboards and alerts setup to inform coordinators in the case where we stop receiving data from the participant after 5 days. The coordinator can use this information to then reach out to the participant and figure out why we stopped receiving data (and determine if a new login code needs to be generated).
Finally, when a participant completes the trial, their access needs to be revoked. Therefore, when setting up the client token in Cognito, be sure that the revocation option is enabled. This allows us to remove access for a participant when they complete the trial even though the refresh token hasn’t expired yet. This functionality is also relevant when a user for some reasons has to drop out of the trial or wants to opt out. We can use the token to immediately stop collecting data.
Final words
In this post, we outlined the infrastructure Compass created to allow participants in a clinical trial to log into a mobile app while completely preserving their anonymity. Hopefully, as more digital tools enter the market and precision medicine becomes ever more common place, this post can serve as a reference to future biotechs looking to help patients with digital tools.