Page Comparison

...

In an alternative universe where we don’t intend to provide #1 (in particular), we could refactor Subpopulation to be this new top-level Consent object, and reuse almost all of our existing consent infrastructure with a new association between Study (originally Substudy) and Consent (originally Subpopulation). So it’s worth checking again that we really want to perform this refactor.

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 languagesA study can be associated to zero or more consents, defined globally within an app context. Only one consent in a given language can be marked as the required consent. (Another alternative would be to push this down into the model and filter things like DocumentElements by language). 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 {
    // Consents are owned by organizations that have write permissions,
    // but other organizations can use the consent if needed.
    String ownerId;
    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 requiresReconsent;
    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; 
}

[TODO: Is this all just submitted in one graph, a little like Account, or will there be separate endpoints to work with these component parts?]

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

...

Study Consent APIs (devs and researchers)

These calls need to work with a StudyConsent associative record. This record will record if the consent is the required one for this study. (Because StudyConsent is already taken internal to the system, we should rename those first to ConsentDocuments).

...