In brief: Lilly researcher will sign in to researcher portal and select a valid PIN to enroll a user (creating an account). Then on the phone, they'll enter the pin to initialize the application (sign in).
Study
Add flag, isExternalIdValidated. At the very least it should toggle between current behavior (any string can be set) and a stricter set of rules.
...
- should ID be validated?
- should ID be assigned?
- is the ID required at sign up (that is, don't create an account until you've validated the external ID you're going to use for it)
- can the ID be unassigned or re-assigned?
- can the ID be deleted once assigned?
ExternalId Table
- String studyId (key)
- String externalId (range)
- String healthCode
- long reservation
To assign healthCode to an ID is to assign it, but I propose a reservation design so that during sign up, we can validate and hold an ID until we have an account with a healthCode that we can register in the first place. The reservation would only be for 30 seconds or so.
ExternalIdDao
Follows the external ID service. The service might assume methods for FPHS and the FPHS Dao as well, not sure.
ExternalIdService
// With optional filter to return only unassigned IDs, useful for Lilly, and an idFilter to filter down to an ID. I imagine
// a scenario where a researcher is searching for a particular ID in order to create an account from it.
getExternalIds(StudyIdentifier studyId, int offsetBy, int pageSize, String idFilter, Boolean assignmentFilter);
...
// Returns true if there's no healthCode and the reservation timestamp minus time of request is
// less than some timeout value (or zero/unset). If it is going to return true, it sets the reservation
// field to current timestamp, preventing other callers from proceeding to use the ID. If the call that
// reserved the ID fails, it will become available again after the timeout.
boolean reserveExternalId(StudyIdentifier studyId, String externalIdentifier);
// Assigns the ID once you have the healthCode. If reservation failed, the caller should not
// proceed to call this method. After this of course, any attempts to assign or reserve should fail.
assignExternalId(StudyIdentifier studyId, String externalIdentifier, String healthCode);
// Call as part of deleting a user.
unassignExternalId(StudyIdentifier studyId, String externalIdentifier);
ExternalIdController / Other controllers
GET /v3/studies/self/externalIds?offsetBy=n&pageSize=n&idFilter=<string>&assignmentFilter=<boolean>
get paged list of identifiers, should be able to filter on assigned/unassigned for Lilly. Would basically just return the IDs and assignment status
...
We should create a Lilly-specific screen in researcher UI that simplifies creating a user down to selecting a free external ID. Then they can then enter the code on the device. Actually creating a user off of an externalID might be generically useful.
SignUp
Can provide an externalId at sign up and sign up will be rejected if the ID is invalid or assigned. This does allow for enumeration of the IDs, unfortunately, but meets some researcher needs (FPHS). This is not needed for Lilly but will almost certainly be needed in the future.
...