| Table of Contents |
|---|
...
Migration
The biggest change in the system will be that participant-facing APIs will no longer throw a 412 if the user is enrolled in any study in the app. This is different than the Subpopulation model where some subpopulations require consent, and some do not.
In the first version of consent, we matched subpopulations based on criteria, and then returned 412 if any of the required consents were not signed. To disable consent, you created a new, optional subpopulation, the only purpose of which was to turn off the 412 responses without having to sign consent.
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.)
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.)
Migrate all existing accounts with consents by adding enrollment records for these.
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, 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.
...