Page Comparison

...

1. For every required subpopulation, create a study, and change the subpopulation to enroll the user in that study when the subpopulation consent is signed. (Possibly require this going forward.)

2. Migrate all existing accounts with consents by adding enrollment records for these.

3. Going forward, consents will merge with the presence of an enrollment record, in many cases (if a study enrolled people but didn’t require them to consent or use an external ID, the reality is, we don’t know that they are enrolled).

I think it’s likely I will break something if I try and carry over the existing consent system further than this, including subpopulations, The App object should include a consent version number, and existing studies should be marked as v1. Subpopulations, consents, and study consents . I propose to leave these as a v1 model of consent, and create a new v2 version of consent. An app should include a flag indicating whether or not it uses v1 or v2 of the consent system. I don’t propose to go back and migrate existing studies, copying the relevant information from an App to a new Study, as it’s a large and risky undertaking.should continue to work for v1 applications. The v2 consent system is described below.

Consent v2

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 consent includes a model for presenting the consent, and a model for verifying comprehension of the consent. The consent document will be assembled through the use of the content fields of all the document sections, with a signature block at the end of the consent which can be tailored for individual consents. Finally, any functionality we want to maintain from Subpopulations, like adding a data group to a participant when they consent, should be carried over to this new Consent record.

class Consent {
    String name;
    String description;
    String language;
    // more than one consent can be marked required, 
    // but only if they all have different languages
    boolean required;
    boolean reconsentRequiredrequiresReconsent;
    String appId;
    // if you sign this consent, you will be enrolled in this study.
    String studyId;
    String guid; 
    // subpopulation functionality maintained
    Set<String> dataGroupsAssignedWhileConsented
    // Name of the approving IRB
    String approvedBy;
    DateTime approvedOn;
    DateTime approvalExpiresOn;
    ComprehensionType type; // summative, formative
    List<DocumentSection> sections;
    // timestamps, deleted, version
}

class DocumentSection {
    int order;
    String title;
    String content; // markdown or HTML
    String summary; // markdown or HTML
    ComprehensionQuestion question; // optional
}

class ComprehensionQuestion {
    String question;
    List<Answer> answers;
}

class Answer {
    String text;
    boolean correct;
    // assuming it was either selected correctly, or in error, the
    // response will be an affirmation or a correction/further explanation
    String response; 
}

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 requiresReconsent, 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).

...