Page Comparison

Each study has one (and only one) required consent that must be signed to enroll in the study (with the caveat that the required consent may be in multiple languages). The consent can also be flagged if the client should force the user to reconsent (the user enrolled with a prior consent). There can be any number of optional, supplemental consents that can be presented to the user.

...

The enrollment record which indicates that a participant has been enrolled in a study, will include the GUID of the consent that was used when the participant consented. It may be the same or different as the current required consent guid. If it’s different and the current consent requires re-consent, the app should act like the user has never consented and consent the user again (however, the user is consented and nothing will fail while this is happening, like pending uploads). If it’s not required, no action needs to be taken by the client. (Maybe we show somewhere that there’s a newer version of the consent document, I don’t know).

Candidates API

Candidate {
    String anonymousId;
    DateTime firstContactOn;
    DateTime mostRecentContactOn;
    String anonSessionToken;
    // should map 1:1 with a consent, but we can include consentGuid
    String studyId; 
    String userId;
    String stepCompleted; // eligibility, comprehension, consented, demographics
    Enum eligibility; // eligible, ineligible
    List<RejectedAnswer> eligibilityRejections;
    JsonNode clientState;
}

Users engage in some important activities before they create an account in Bridge, such as checking their eligibility to participate in a study, or agreeing to join a study before they create an account.

Currently we have an “intent to participate” API to help cover some of these cases, but it is lacking insofar as we would like the following information for governance and recruiting:

1. What eligibility criteria are causing candidates to be rejected?

2. What aspect of informed consent are people not understanding?

3. Do we have people who consented, but never created an account?

The candidate history APIs is a proposal to track this domain-specific information. It is intended to track the required consent for a study (if we need to track more than this, the API should change). Each API will look for the Bridge-Session header to recover a session, or if it doesn’t exist, a token in a cookie. If neither exists, it will set a new token in a cookie and use it to track a record during anonymous consent. This should allow browser applications to save consent while working.

On sign up, the candidate session token can be included, and we will associate this candidate record with the user.