...
Delegation - For projects with an equivalent governing body as ACT, ACT needs to be able to delegate the restriction management to that governing body.
Set levels without micromanagement - For projects that do not have an equivalent governing body, ACT will need to continue to set the appropriate levels. However, we need to minimize the amount of micromanagement needed apply the set levels to files within the project.
New Automatic Approval Types - For some cases a user might gain approval via an independent 3rd party. For such chases Synapse would need to communitate with the third party’s system to validate a user’s approval. We will cover this in more detail in the next section.
New Automatic Approval Type
Consider the following example: A file has the DUO attribute “Institution Specific Requirement ” = “true” and “Institution” = “Stanford“. For this project, ACT determines that it is not sufficient for data consumers to simply “agree” that they are part of the institution. Instead, data consumers must provide proof they they are indeed part of that institution. To setup this type of AR today, an ACT member would need to create a managed AR. Potential data consumers would then need to submit documents that prove they are part of the institution. A member of the ACT would then need to manually process the submission in order to approve it.
...
Sources of Metadata
In the main governance story, metadata is originating from multiple sources:
...
However, there is a downside to normalization. When a user inspects the Entity page for a single file, how can they see all of the related metadata?see all of the related metadata?
Data Examples
The Patients table is a data gathered by the clinician. It provides basic information about each patient involved in the study.
Patients
patientId | birthDate | country | … |
|---|---|---|---|
1 | 04/24/55 | USA | … |
2 | 08/12/49 | Germany | … |
3 | 01/01/41 | USA | … |
4 | 11/11/62 | Germany | .. |
The Treatment table is also gathered by the clinician. It maps bio samples gathered before and after a treatment for each patient.
Treatment
patientId | treatment | sampleId |
|---|---|---|
4 | before | 1 |
4 | after | 2 |
2 | before | 3 |
2 | after | 4 |
1 | before | 5 |
1 | after | 6 |
3 | before | 7 |
3 | after | 8 |
The assay results are files upload to Synapse by the Lab Technicians. Each file represents the results of a single assay run on a batch of bio samples. When uploading each file the lab technician will be able annotate each file with two annotations: samplesIds and assayType.
Note: The Lab technicians have no knowledge of patients or treatments.
Assay Files
Synapse ID | sampleIds | assayType |
|---|---|---|
syn1 | 1,2,3,4 | genomic |
syn2 | 1,2,34 | imaging |
syn3 | 1,2,3,4 | clinical |
syn4 | 5,6,7,8 | genomic |
syn5 | 5,6,7,8 | imaging |
syn6 | 5,6,7,8 | clinical |
According to the governance team’s evaluation of this project, all files should be under a click-wrap data embargo AR (AR.id = 1). In addition, any file with an assayType= genomic and patient country = Germany, should be under a click-wrap that informs the user that the data file cannot leave Germany (AR.Id = 2). According to these rule syn1 should be under AR.ID = 2, while all files should be under AR.ID = 1.
Implementation Phases
There are a lot of areas that will need changes/improvements. Therefore, we will break up the implementation work into phases:
Phase One - Delegation of AR approval to non-ACT Synapse users.
Phase Two - Make progress towards the integration of DUO metadata on individual files.
Phase Three - TBD.
Phase One
Goal
The goal of phase one is to expand the permissions of Synapse Governance systems to enable members of the ACT to grant non-ACT users permissions to both review and approve managed access for specific cases. Items that are considered out-of-scope for this phase:
...
Creating/updating ACLs on ARs - This would be a new feature that would allow a member of the ACT to create an ACL on an existing AR. Only a member of the ACT would be allowed to create/update these ACLs. The ACT member would grant a non-ACT user permission, to “REVIEW” submissions to this by updating this ACL. Note: ACT members will automatically retain the “REVIEW” permission for all ARs even if not explicitly listed in the ACL of that AR. Any AR that does not have an ACL will still be fully accessible by members of the ACT.
GET /dataAccessSubmission/openSubmissions - This services would need to be changed to list open submission for any user that has been granted the “REVIEW” permission. Should an ACT member also see listings for submissions to ARs that have granted non-ACT members “REVIEW”?
POST /accessRequirement/{requirementId}/submissions - This service would need to be changed similar to the above.
PUT /dataAccessSubmission/{submissionId} - This service would need to be changed similar to the above.
DELETE /dataAccessSubmission/{submissionId} - This service would need to be changed similar to the above.
Phase Two
Goal
The goal for phase two will be to expand the use of DUO metadata to individual data files. Ideally, the