Requirements
These were collected from a meeting we held with Larsson, Abhi, Mike, Brian, and Thaneer, and from a follow-up interview with Dan.
...
GET /v3/substudies/:subStudyId/externalids [list]
POST /v3/substudies/:subStudyId/externalids [create] <-- could take a list for batch creates
GET /v3/substudies/:subStudyId/externalids/:id [read]
POST /v3/substudies/:subStudyId/externalids/:id [update]
DELETE /v3/substudies/:subStudyId/externalids/:id [delete]
Add sub-study to existing exernal IDs API. Make it possible to associate external ID record with sub-study
Write to both external ID systemstables, and read first from the new external ID database. In this period, user can new table before old one. However at this time, you can only belong in one sub-study/only have one external identifier:
- Add subStudyId to the existing ExternalIdService APIs; to use them, a sub-study will need to be provided (this may not be functional at first)
- Write to both the new and old tables when assigning or changing external ID.
- Backfill sub-study from the new to the old table
- Add method to ExternalIdService to find external ID by health code. Use this in preference to the value stored in the Accounts table, so you can first look at the join with new table.
AccountDao - mostly calls through to the ExternalIdService
- sub-study association needs to be restricted to the caller's sub-studies. For example, the set of sub-studies need to be passed in, or the StudyParticipant needs to be "tainted" with the caller's identity when it is constructed so permissions can be checked. Submitted record can participate in a set of sub-studies and then these are checked against membership of caller.
- constructAccount: set up eventual persistence of associative record
- Iterator/List calls should specify a sub-study (or perhaps a list, if we want BSM users to see all users they can see, across all studies)
Account, AccountSummary, StudyParticipant, UserSession
- The construction of all three of these arguments should return their sub-studies. It's conceivable we don't include in AccountSummary.
Migrate external IDs
...
ID.
Backfill the older external ID table with sub-study IDs
Switch to looking up users via external ID by quering for the record (not looking in Accounts table)
Join tables when retrieving user to get external IDs
- at this point the externalId column in the Accounts table should not be in use
Add substudies to AccountSummary, StudyParticipant, add substudies to UserSession
Add sub-study filtering to the getAccountSummaries() and Iterator calls. A sub-study must be selected if the user has sub-studies, and it must belong in their set of sub-studies, or the request is an error. Otherwise, the records are filtered only to those accounts that have the sub-study ID.
Remove older external IDs API (maintaining it would be very difficult, if it has to be maintained, switch it over to be a special case of calling the new API)
Update sub-populations so that signing the consent of a sub-population will assign a user to one ore more sub-studies, without an external ID (additional behaviors can be implemented as needed).
...