Page Comparison

...

In the new consent system, you would model this as two studies that shared the same protocols, and enrollment state, where one had a consent assigned to it and one did not. (There’s no use of criteria to select which one a user should enroll in…creating an external ID for an account is one way to enroll someone in a study.)

1. Refactor subpopulations to use a single String guid, so an account’s consent signatures can continue to work to persist consents under the new consent system;

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

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

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

...

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 reportingWhen consent is withdrawn, the enrollment record will be set a flag and behave like a logically deleted record. These records allow us to quickly determine the participant’s status, and they answer two questions for governance: how many people have we enrolled in the study, and how many have been withdrawn from the study? (Note that the questions I received from Vanessa also include “how many people have you removed from the study” which we’ll need to consider.)

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;
  // behaves similarly to logical deletion
  boolean withdrawn;
}

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.

...