Bridge
Contact Us Terms of Use

Consenting Participants

All participants in your mHealth study must consent to participate in your research before you can collect their data. The United States requires this informed consent, along with approval of your research by an Institutional Review Board. Once you have approval to do the research, Bridge can help you collect and manage these consents.

If you are managing consents through Bridge, an authenticated user will receive back a 412 HTTP response from the server when calling a participant-facing API ("Precondition Required"). This response will include the user's session in the body of the response. The user is authenticated, but not authorized to send or to receive data from Bridge.

To consent, the user must send a consent record to the API (the subpopulation GUID for the default consent is the study identifier, the same used to authenticate with the correct study when contacting the Bridge server). The call returns the user's session updated with the new consent status. Thereafter, participant-facing calls will work as expected.

Bridge can support multiple consent groups (initially, a Bridge study will have one default consent group that is required, but this is configurable). It will determine all the consent groups that apply to a user (see customizing content), and the user will need to consent to all required consent groups before accessing Bridge services. Users do not need to agree to optional consents to use Bridge services. If you update the contents of a consent document after a user hask signed it, this will be noted in the user's session, but they will not be required to consent again.

At the time of consent, a signed version of the document will sent via email or SMS link to the user for their records (this feature can be disabled). You can update the consent document contents and save new versions of this document; when you wish to do so, you can publish a new version as the approved version of the consent to present to users.

If you are consenting your users in a clinical or similar setting, and that consent includes use of your mHealth app, you may not need Bridge's consent support at all. Simply navigate to the default consent group in the Bridge Study Manager and deselect "User must consent to this agreement." Then save. Now that this consent is optional, users will never receive a 412 response after signing in.

In some scenarios you may wish for users to consent before downloading your app. For example, Sage Bionetwork's mPower app has a web-based consent process that users can complete before downloading the app. In this scenario, users do not make an account before they give consent. To support this, Bridge has the intent to participate API.

The workflow is as follows:

  1. The user navigates to a consent web site, and agrees to consent. This consent includes a credential that will be used to sign in the user, either an email address or a telephone number;
  2. The website detects it is not embedded in an app, and sends the consent to the intent to participate API;
  3. The Bridge server responds by sending either an email or SMS message to the user with a link to download the app (the message content is configurable in the Bridge Study Manager);
  4. The user clicks on the link, downloads and installs the app, and then opens it;
  5. When the app is opened, it asks again for the same email address or phone number;
  6. The app takes that credential and signs up for an account, then immediately triggers a sign in request via email or SMS;
  7. The user gets an email message or SMS message with a link that they click on. This link is intercepted by the host operating system and opens the app (this requires some additional configuration on Android or iOS to give the operating system permission to intercept the link; Bridge can be configured to serve as the host domain by setting the App.appleAppLinks and App.androidAppLinks through the Bridge App APIs;
  8. The app extracts a token in the link to complete sign in via email address or phone number;
  9. On sign in, the system detects that the user has already submitted an intent to participate under that credential, and completes the consent process without further intervention by the user. The sign in request thus returns a 200 HTTP status response and a consented session.

This sequence of events can also support cases where the user downloads and installs your app without visiting your consent website... as is possible once you publish your app in a public app store.

  1. The user downloads your app from the app store;
  2. When the app is opened, it asks for an email address or phone number (as in step #5 above);
  3. The app takes the user's credential and signs up for an account, then requests an email or SMS link at that address or phone number in order to sign in to the app (as in step #6 above);
  4. The user clicks on the link which opens up the app. The app extracts a token in the link to complete sign in via a email address or phone number (steps #7 and #8);
  5. On sign in, the app receives a 412 response and goes into the same consent workflow, embedded in the app;
  6. This consent is submitted through the normal consent to research API.

In Sage Bionetworks applications, we use the same consent website for both scenarios. The key component is the Sign.vue file, where we test the computed property isEmbedded. When the website is accessed on the desktop, it submits the consent to the ITP service. When the website detects that it is being displayed in a WebView, it passes the consent back to the client through a JavaScript bridge, so the native client can call the consent service, record the updated session state, and if everything is successful, close the WebView. The user is now consented and can use all of the Bridge APIs.