Page Comparison

...

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; 
}

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

Researcher Consent APIs (devs and researchers)

A consent cannot be physically deleted if it is referenced by a study. Consents are owned by an organization, and only developers or researchers from that organization can edit or delete consents. However, any organization can associate a consent to a study they sponsor.

Study Consent APIs (devs and researchers)

Participant consent APIs

Finally, users have APIs to sign these consents, which creates (or removes) enrollment records and signatures. All these APIs are from the perspective of the authenticated caller.

Enrollments

Rather than loading and examining consent signatures to determine active enrollees in a study, there will be an enrollment record when an account is actively enrolled in a study. Note that this does not capture withdrawals or more complicated scenarios where people enroll and withdraw multiple times. It is still necessary to examine the history of signatures for an account to find withdrawals.

(I am noodling with the idea of “withdrawal” being something like a logical delete of an enrollment… the advantage of this would be governance reporting.)

class Enrollment {
  String studyId;
  // optional
  String externalId; 
  // the consent signed to enrollment
  String consentGuid; 
  // true if consentGuid != the study's required consent GUID, and the required consent requires reconsent
  // user is still considered to be enrolled in study, e.g. uploads will not fail.
  boolean reconsentRequired; 
}

SQL

The consent signatures table may be able to store signatures for the v2 version of consent, if the consent GUID can be stored in the subpopulation GUID column (the values are in fact globally unique). If a new Hibernate model can be associated to to the same table, it may reduce confusion.

...