Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

An in-progress list of tasks...

Clean up accounts to remove GenericAccount and HibernateAccount, and the copying between the two classes (subsequent changes heavily involve the AccountsDao, so it would help to simplify first).

Create Sub-Studies

SQL:

CREATE TABLE `SubStudies` (
    `identifier` VARCHAR(60) NOT NULL,
    `studyId` VARCHAR(60) NOT NULL,
    `label` VARCHAR(255) NULL,
    `createdOn` BIGINT NOT NULL,
    `modifiedOn` BIGINT NOT NULL,
    `deleted` BOOLEAN NOT NULL DEFAULT false,
    PRIMARY KEY (`studyid`, `identifier`)
)

SubStudiesService {
    listSubStudies(studyId, includeDeleted)
    createSubStudy(subStudy)
    getStubStudy(studyId, id)
    updateSubStudy(subStudy)
    deleteStubStudy(studyId, id)
    deleteStubStudyPermanently(studyId, id)
    // These would add an associate record between Account and SubStudy without assigning an external ID
    addUserToSubStudy(studyId, id, participant)
    removeUserFromSubStudy(studyId, id, userId)
}

API (always in the study of the caller, unless we need worker APIs eventually):

    GET /v3/substudies?includeDeleted=boolean [list]
    POST /v3/substudies [create]
    GET /v3/substudies/:id [read]
    POST /v3/substudies/:id [update]
    DELETE /v3/substudies/:id?physical=boolen [delete]

Create new ExternalIds

// Either or both of accountId and externalId need to be filled out. Would probably use ID column to avoid composite keys, but then would need to verify the results conform to the caller's study and sub-study.
CREATE TABLE `ExternalIds` {
    `id` VARCHAR(60) NOT NULL,
    `studyId` VARCHAR(60) NOT NULL,
    `subStudyId` VARCHAR(60) NOT NULL,
    `accountId` VARCHAR(255) NULL,
    `externalId` VARCHAR(255) NULL,
    PRIMARY KEY (`id`)
    UNIQUE INDEX `StudyId-SubStudyId-Index` (`studyId` ASC, `subStudyId` ASC),
    UNIQUE INDEX `StudyId-ExternalId-Index` (`studyId` ASC, `externalId` ASC),
    UNIQUE INDEX `StudyId-AccountId-Index` (`studyId` ASC, `accountId` ASC)
}

ExternalIdsServiceV2 {
    listExternalIds(studyId, subStudyId, offsetBy, pageSize, includeDeleted)
    createExternalId(externalIdObj)
    getExternalId(studyId, subStudyId, externalId)
    updateExternalId(externalIdObj)
    deleteExternalId(studyId, subStudyId, externalId)
    deleteExternalIdPermanently(studyId, subStudyId, externalId)
    // These would update an add an associate record between Account and SubStudy with an account ID
    assignExternalId(studyId, subStudyId, externalId, accountId)
    unassignExternalId(studyId, subStudyId, externalId)
}

API (always in the study of the caller, unless we need worker APIs)

    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]

Note: in Hibernate, for this to be an entity, it'll need a primary composite key based on the foreign keys in the table. Or actually I like @IdClass for this purpose.Not sure how, in this case, we can leave accountId empty.

Further tasks in no particular order:

Migrate all the existing external IDs from DynamoDb to SQL tables and adjust all the existing APIs to use the new external Ids table. This means adjusting some APIs to look up users through this association rather than the DDB table.

Add a user's sub-study association to AccountSummary, StudyParticipant, and the UserSession.

Participant APIs should only include sub-studies that the caller belongs to. Admins might break this rule.

Users can be associated to a sub-study in one of several ways:

  • devs/researchers can create an association without an external ID
  • normal users can be associated by providing an external ID during create/update
  • Signing the consent for a subpopulation can associate a user to a sub-study, without an external ID (other behaviors can be implemented as needed).

Uploads need to be tagged with the ID of a user's sub-studies (all of them). Hence the need to have this available in the StudyParticipant record and the UserSession.

Consider removing "unmanaged" external IDs as this adds some complexity to the logic of external IDs and I'm not sure this is used at all at this point, or will be.

Add the ability to filter by sub-studies using the Criteria object. Like tags, you should be able to add a set of sub-studies, at least one of which should match, or a set where none may match. The main use for this would be to schedule different sub-studies differently, in the context of an overarching multi-study design.

I would also start by cleaning up accounts to remove GenericAccount and HibernateAccount and the copying between the two of them (subsequent changes will heavily involve the AccountsDao so it would help to simplify first).

  • No labels