...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Use Cases for this Workflow can be found here.
Current Work Flow
ACT has been using an R script to create Access Requirement on a set of entities (data set). On some data set, there will be multiple Access Requirements: ACTAccessRequirement, and SelfSignAccessRequirement.
Dataset A has ACTAccessRequirement. User B wants to download dataset A, s/he needs to email the ACT to request access to data set A. Via emails, an ACT member would ask the user to complete some forms. The forms are different for each dataset. A form includes the information that Sage and data contributors requires. It is an agreement between Sage and data contributors, so it will not change after it's established for a data set. When there is updated on the data set, we have the data in a different project/ folder and have a new set of Access Requirements on that data.
...
Every few months, an ACT member will download all DUC forms and Intended Data use Statement in that period and send them to the data contributor.
...
Manually entering the detailed information (in a spreadsheet) about the request for access (including approval status) is a burden for the ACT.
- User's handwriting is hard to read.
- Since requests are submitted via email, there is no ways to prevent requests coming in with missing information.
Proposed Work Flow
The ACT setup the necessary form for dataset A. This will look similar to setting the schema for a table in Synapse, with certain fields included by default.
...
- Keeping track of which request is about to expire and emailing reminding users about their expired request takes a lot of time.
Proposed Work Flow
Setting up the Access Requirement:
The ACT member will navigate to a page specifically for Access Requirements and Access Requests.
There to a page specifically for Access Requirements and Access Requests. (They can enter the URL directly or clicking on a link from the entity page.)
From this page, there they can create a new Access Requirement, selecting entities to associate with it, and creating . Once the Access Requirement is created, they can create a form for accepting access requests.
They can also open an For existing Access Request, which opens a dialog for Requirement, the ACT can open it by entering/selecting an entity associated with that Access Requirement. They would be able to see the preview of the Access Requirement before opening it.
The ACT member will be able to update any part of the Access Requirement, including adding a form for accepting access requests.
(Please see the process of creating a form below.)
Once a form has been created, the table of requests will be shown on the page, and there will be a button for viewing the form as a requestor would see it.
The form creation process is as follows:
Certain fields are always included, such as Every form contains an instruction given by the ACT, and the following fields:
- Project Lead
- Intended Data Use Statement
- List of Accessors
For each form, the ACT will determine the expiration period (number of months or NONE.)
For the list of accessors and the time until the request expires.The creator , the ACT may specify that accessors must be certified and/or have validated profiles.
...
The ACT member can add existing fields (from the template outline by the governance team) to the form.They can specify a description for a field, which will be displayed to the user in order to clarify what that field requires.:
- DUC
- IRB
They can remove fields using the "x" to the right of the field.
...
The ACT member can also add a custom new field to the form.
Each form includes a brief instruction given by the ACT.
Each valid request includes the following fields and additional fields:
...
The ACT can preview the form before creating it.
Creating a request:
User B goes to any entity A with an ACTAccessRequirement associated with it, and clicks on "show unmet conditions" to get to the data access request form (if one has been set up. If not, the process will be the same as it is currently for requesting access). If they are not logged in, then they will be met with this view:
...
____________________________________________________________________________________________________________________________________
Hi:
The Synapse Access and Compliance Team has approved your application for use of the MayoGWAS data distributed through Synapse.
To use this data you must adhere to the Terms of Use as described in the MayoGWAS DUC: https://www.synapse.org/#!Synapse:syn2910256
The MayoGWAS data can be accessed through the following Synapse project:https://www.synapse.org/#!Synapse:syn3219045
Please note that the first time you download a datafile you will also be asked to agree to acknowledge the AMP-AD Partnership in publications derived from any of the AMP-AD data. This approval must be performed through the website.
For a review of the AMP-AD Data Terms of Use, please see here: https://www.synapse.org/#!Synapse:syn2580853/wiki/78604.
Please note, this email is sent from an unmonitored account. Send any questions to act@sagebase.org.
Sincerely,
The Synapse Access and Compliance Team
...
____________________________________________________________________________________________________________________________________
Hi:
The Synapse Access and Compliance Team has rejected your application for use of the MayoGWAS data distributed through Synapse, because you did not sign the DUC.
To submit another request, please visit the MayoGWAS dataset at: https://www.synapse.org/#!Synapse:syn2910256.
Please note, this email is sent from an unmonitored account. Send any questions to act@sagebase.org.
Sincerely,
The Synapse Access and Compliance Team
____________________________________________________________________________________________________________________________________
...