Current Work Flow
...
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.
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.
The fields that are included by default will be determined by the ACT.
Rudimentary mockups for setting up the Access Requirement and Form:
The ACT member will navigate to the Dataset page with an Access Requirement, and open the "Create Form" dialog from the tools dropdown menu.
The ACT member can add existing fields (from the template outline by the governance team) to the form.
When the creator adds a UserList to the form, they may specify that accessors must be certified and/or have validated profiles.
They can also 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:
- Data Requestor - the user who is making the request
- Study Lead
- Additional Users - the users who would also have access to the data is the request is granted.
User B goes to dataset A and clicks on "show unmet conditions" to get to the data access request form. If they are not logged in, then they will be met with this view:
Once they log in, then they will have the option to "Create Request":
Upon clicking Request Access, the user will be shown a form to fill out, and upon submitting the form, an email will be set to notify the ACT.
The person requesting access is automatically included in the list of accessors. They can remove themselves using the "x" next to their name.
The requestor can add multiple users for the access request by clicking "Add Accessor"
The requestor then will input the synapse id in order to add the user to the request.
Additionally, if there exists a restriction on what kind of users can be added (i.e. they must be certified users or have a validated profile), then an error will be shown if the requestor tries to add a user that does not meet the requirements, and the user will not be added to the list of accessors.
Finally, all fields are required. The requestor will be shown an error if they try to submit the form without filling in every field.
Sample email message to ACT after a user requests access (with links to the dataset):
_______________________________________________________________________________________a page specifically for Access Requirements and Access Requests
There they can open an existing Access Request, which may not have a form associated with it. They will have the ability to create a form.
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.
Finally, the ACT member could create a new Access Requirement, selecting entities to associate with it, and creating a form for accepting access requests.
The form creation process is as follows:
The ACT member can add existing fields (from the template outline by the governance team) to the form.
When the creator adds a UserList to the form, they may specify that accessors must be certified and/or have validated profiles.
They can also 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:
- Data Requestor - the user who is making the request
- Study Lead
- Additional Users - the users who would also have access to the data is the request is granted.
User B goes to dataset A and clicks on "show unmet conditions" to get to the data access request form. If they are not logged in, then they will be met with this view:
Once they log in, then they will have the option to "Create Request":
Upon clicking Request Access, the user will be shown a form to fill out, and upon submitting the form, an email will be set to notify the ACT.
The person requesting access is automatically included in the list of accessors. They can remove themselves using the "x" next to their name.
The requestor can add multiple users for the access request by clicking "Add Accessor"
The requestor then will input the synapse id in order to add the user to the request.
Additionally, if there exists a restriction on what kind of users can be added (i.e. they must be certified users or have a validated profile), then an error will be shown if the requestor tries to add a user that does not meet the requirements, and the user will not be added to the list of accessors.
Finally, all fields are required. The requestor will be shown an error if they try to submit the form without filling in every field.
Sample email message to ACT after a user requests access (with links to the dataset):
_______________________________________________
Hello,
Karen Altergott (kmaltergott) has requested access to Dataset MayoLOADGWAS.
For further information, please visit the dataset.
Sincerely,
Synapse Administration
_____________________________________________________________________________________
Hello,
Karen Altergott (kmaltergott) has requested access to Dataset MayoLOADGWAS.
For further information, please visit the dataset.
Sincerely,
Synapse Administration
_________________________________________________________
User B can see the status of their request on the dataset, and can cancel their request while it is pending.
After the request has been approved, the requestor can opt to update their request:
The requestor will be able to edit all submitted fields:
On clicking Update, if anything is not filled in, the user will be shown an error message instructing them to fill in any fields they left blank.
To view all requests made on the dataset, an ACT member can navigate to the dataset and select "View Requests" from the tools menu. This will open a table:
Features of the table view:
Users that have been certified and verified (?) will have a symbol next to their synapse id (in this case a trophy) as an indicator. Users who have previously been approved for access to the dataset will have a check mark next to their name.
If the requestor updates their request, the fields they change will be highlighted for the ACT to more easily see. The version of the request will be incremented. _____________________________________________________________________________________
User B can see the status of their request on the dataset, and can cancel their request while it is pending.
After the request has been approved, the requestor can opt to update their request:
The requestor will be able to edit all submitted fields:
On clicking Update, if anything is not filled in, the user will be shown an error message instructing them to fill in any fields they left blank.
To view all requests made on the dataset, an ACT member can navigate to the dataset and select "View Requests" from the tools menu. This will open a table:
Features of the table view:
Users that have been certified and verified (?) will have a symbol next to their synapse id (in this case a trophy) as an indicator. Users who have previously been approved for access to the dataset will have a check mark next to their name.
If the requestor updates their request, the fields they change will be highlighted for the ACT to more easily see. The version of the request will be incremented.
After a year, an access request will need to be renewed. An email will be sent out to the list of accessors one month before the expiration date.
<TODO: add sample email for one month before expiration>
If the request is not updated, then it will expire. The version in the table will be incremented, access for all accessors will be revoked, and the status will change to EXPIRED:
An email will be sent to the accessors (and ACT) notifying them of the revocation of their access.
<TODO: add sample email for revocation of access due to expiration>
After a year, an access request will need to be renewed. An email will be sent out to the list of accessors one month before the expiration date.
...
____________________________________________________________________________________________________________________________________
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
____________________________________________________________________________________________________________________________________
...