Version | Summary |
---|---|
12/28/2021 | Updated format to align with policy version tables |
12/15/2021 | Current version |
12/15/2021 | Created version tracking table |
Audience
Synapse Access & Compliance Team (ACT). Note: make sure you have consulted the Developing Access Requirement Content SOP before implementing Access Requirements.
Table of Contents
Overview
Public sensitive data often requires that ACT set up Access Requirements for Synapse users to satisfy before they can download data in the respective Synapse entity. Two types of Access Requirements are click-wraps and Managed Access Requirements.
A. Managing Data through a “Click-wrap” Agreement
Often, data contributors require Synapse users to agree to specific terms and conditions for data use before obtaining data access. These terms and conditions can include: restrictions on the type of research people can conduct using the data; specific acknowledgement or citation statements that must be stated in publications resulting from data use; and reaffirmation that data accessors will not attempt to re-identify research participants. Click-wrap agreements consist of a pop-up screen listing such terms of data use. Users must click an “agree” button before they are able to obtain access to the data.
The “click-wrap” can be programmed so that users must be registered, certified, or validated to be able to view the agreement and obtain data access. Registered users must set up a Synapse account and agree to the Synapse Pledge, which ensures users will behave responsibly. Certified users must be registered in Synapse, and must also pass a Synapse Certification quiz, which tests data ethics and general understanding of how Synapse works. Validated users must be certified, and must also have their identity verified by the Sage Bionetworks Access & Compliance Team (ACT).
B. Managing Data through a Managed Access Requirement
Our highest level of protection for public data hosted in Synapse is a Managed Access Requirement. Users must complete a data access application, and then the ACT (or other Data Access Committee, or DAC) must review the application before granting data access. This data governance option essentially transfers data management to the ACT, and enables further selectivity into who is able to receive data access via the data access application.
The data access application may consist of an intended data use statement, an IRB approval letter, a signed data use certificate, among other options. Within the application, users must indicate their institution, any collaborators, and the project lead. Typically, applications are valid for a finite period, and users are prompted to renew their access and submit a progress report after a specified time interval.
Managed access requirements can also require users to be registered, certified, or validated before submitting their data access application.
Setting up Access Requirements
Note: run through the below steps in a sandbox space before implementing the Access Requirement in any live projects.
Note: we do not add ARs to staging folders.
Navigate to the respective SynID, and ensure you have access to the entity. If you are not able to access the entity, ask the project administrator to add either your Synapse username or the ACT team to the project via the sharing settings toolbar.
Access requirements can be set up on the project, folder, or table level, and will require you to navigate to Project Settings, Folder Tools, or Table Tools, respectively.
Click the dropdown menu, and select “Manage Access Requirements”
4. Select “Create New Access Requirement”
5. By default, the entity where you initiated this project will be included in the Access Requirement window. Add additional entities via their SynIDs in this area if applicable.
6. Select either “Controlled” or “Click-wrap” based on the type of Access Requirement you are setting up.
7. Add the data access or click-wrap content, and set all applicable Access Requirement fields.
Adding non- ACT reviewers:
In the managed access window navigate to the page “Access Requirement Permissions”
Search for a username or team to add. You can search by username, first or last names, or team name
Once you have added the username or team select “save”
Complete
Once you have set up the Access Requirement, be sure to do the following:
For Managed Access Requirements, create a Data Access wiki page within the project space. See the ElevateMS project for an example.
Create a new wiki subpage in the Conditions for Use project, which stores a log of all Synapse Access Requirements. Include the Access Requirement and project link within the new wiki page. Nest the new wiki page under one of the pre-existing pages if applicable.
If required, set up a new wiki subpage for IDU statements to be posted. Please reference the Publicly Posting Intended Data Use Statements SOP.
Test the setup
Test access using a validated & certified account. The AR you just set up should now appear.
Test access using an unvalidated & uncertified test account. The AR you just set up should now appear.
Resolve any Jira tickets filed for the request if applicable.
Adding/Removing an Entity to an Existing Access Requirement
Navigate to the respective SynID, and ensure you have access to the entity. If you are not able to access the entity, ask the project administrator to add either your Synapse username or the ACT team to the project via the sharing settings toolbar.
Access requirements can be set up on the project, folder, or table level, and will require you to navigate to Project Settings, Folder Tools, or Table Tools, respectively.
Click the dropdown menu, and select “Manage Access Requirements”
4. Locate the AR, and click “Edit Access Requirement” as shown in the screenshot below.
5. To add entities to the AR, paste the respective synIDs into the search box and click “+Add Entities.” Click “Next” and then “Finish.”
6. To remove entities, click the red “X” next to the entity name in the screenshot above. If you are not sure if the entity is correct, click the hyperlinked entity and open it in a new window to double check before saving. Click “Next” and then “Finish.”
Note: Before removing an entity, ensure that the reasoning is legitimate and the entity does not require the AR
Editing Click-wrap or managed AR content
*Note: always verify that you have the data contributor’s acknowledgement when making a click-wrap or managed AR requirement more lax. Evaluate AR change requests critically.
Navigate to the respective SynID, and ensure you have access to the entity. If you are not able to access the entity, ask the project administrator to add either your Synapse username or the ACT team to the project via the sharing settings toolbar.
Access requirements can be set up on the project, folder, or table level, and will require you to navigate to Project Settings, Folder Tools, or Table Tools, respectively.
Click the dropdown menu, and select “Manage Access Requirements”
Locate the AR, and click “Edit Access Requirement.”
Make the corresponding updates. Note that users will not automatically be prompted to re-accept click-wrap terms once they are updated. Users will also not be prompted to reapply for data access if they have already been granted access before the updates were made.
You can revoke users from the AR to force them to re-accept terms or reapply for access. You can also delete/archive the AR instead of modifying it (see Deleting ARs section).
Deleting ARs
There are 3 types of AR’s that can be deleted by ACT
Click wraps
Managed ARs
Dummy ARs
“Dummy” ARs are applied automatically by Synapse whenever a user clicks “add conditions for use”. A Dummy AR can be thought of as an “Empty” AR, as it does not include any instructions for the user.
Dummy ARs can be distinguished from Managed ARs and Clickwraps by ACT by viewing the options available in ARs toolbar. Managed ARs and Clickwraps contain a toolbar with the option to “edit access requirement” whereas Dummy ARs will have the “edit access requirement” field omitted and the “Delete Access Requirement” field is the only field visible in the toolbar (screenshot below).
Submit a Jira issue to request deletion of a clickwrap or managed AR:
File Jira ticket in the Governance (SG) queue and comment:
Project name
Syn ID related to AR
Ensure you have access to Syn ID
Provide history and entities associated with the AR in ticket description
Tag Project Lead for awareness (Spreadsheet is located at Sage Intranet > Science > Sage Projects > Current Project Descriptions)
Include any information received from emails, Slack, or other correspondence
Tag Governance Manager for review
Follow instructions on Retired Conditions for Use Wiki page for updating retired ARs.
Note, for sensitive human data, ensure that deleting the AR is consistent with ACT governance recommendations, compliant with any signed agreements and you have permission from the data contributors to remove the AR.
Follow the instructions below to delete a clickwrap or managed AR:
(Note, there are 2 options for deleting an AR. Please see both options below.)
Option 1:
Go to the Data Access Management dashboard in Synapse
Click the “Access Requirements” tab
Type AR name in “Filter by Access Requirement Name” field or manually search for AR ID
Click on AR ID
Click “Delete Access Requirement”
You will see the “Are you sure?” prompt; click OK
OR
Option 2:
Navigate to the respective SynID, and ensure you have access to the entity. If you are not able to access the entity, ask the project administrator to add the ACT team to the project via the Project Sharing Settings toolbar.
Access requirements can be set up on the project, folder, or table level, and will require you to navigate to Project Settings, Folder Tools, or Table Tools, respectively.
4. Click the dropdown menu, and select “Manage Access Requirements”
5. Locate the AR, and click “Delete Access Requirement.”
You will see the “Are you sure?” prompt; click OK
Instructions on the deletion of a “Dummy” ARs:
Dummy ARs should ONLY be deleted AFTER one of the following has occurred:
A managed AR or Clickwrap has been applied to the data or,
The data contributor has confirmed the “add conditions for use” request was submitted inadvertently.
Note, this will delete the AR from all linked entities if there is no associated request history. If there is an associated request history, the AR will not be deleted.