Granting, Revoking, & Troubleshooting Synapse Data Access

Audience: Sage ACT

Table of Contents

Granting Data Access Through Synapse

Overview

ACT must monitor all ACT-managed Access Requirement (AR) applications so that qualified users are able to gain access to controlled datasets. ACT is expected to check access requests daily on weekdays, with the exception of Sage holidays. For any vacation or sick days where you will be out of office for more than one consecutive day, arrange for a backup data access application reviewer.

Instructing Users to Apply For or Renew Data Access

1. Navigate to the dataset the user would like to access. 

   1. For the AD Knowledge Portal, a user can request access to the entire Portal by requesting access to any dataset contained in the Portal. For example, a user can request access here.

2. Click the “Request Access” button.

3. Each entity will have its own data access instructions. The user will be prompted to complete the dataset-specific instructions to “Request Access” (for new applications) or “Update Request” (for renewals). Note that users are also automatically emailed prior to access requirement expiration to renew their access.

   Open

   

How to Review Data Access Applications (Access Requests)

1. ACT navigates to the Access Requests Dashboard in Synapse. The dashboard displays all ARs with pending data access requests. 

2. ACT clicks the “Review Requests” button for the first AR.

3. Before reviewing requests, ACT can double check what is required in the data access submission by clicking the “Show Access Requirement” button on the top right corner of the page

   Open

   

4. Filter the dashboard to “SUBMITTED” and click “Show” to view the data access application

   1. Note: you can filter to “Rejected” to view applications that have not been approved, and you can filter to “Cancelled” to view applications that a user has withdrawn

5. Review the respective application components

   1. Institution: Ensure that any abbreviations are obvious (for example, you should reject “UW” since this could be University of Washington or Wisconsin)

   2. Project Lead: Ensure this is a person’s first and last name, not the project name

   3. Publication/summary: Not mandatory for any AR

   4. Variable Components (check the specific AR to see what’s required)

      • Intended Data Use statement (IDU): The IDU should answer the following questions in 1-3 paragraphs: What do you want to do? Why are you doing it? How do you want to do it? ACT should review this for completion only.

      • Data Use Certificate (DUC): 

        1. Ensure the correct DUC template and version were used by cross checking the submitted DUC with the template in the AR application. 

        2. Ensure all pages of the DUC have been uploaded, not just the signature page.

        3. If there is only one person requesting data access, the Signing Official section must be signed by someone else; a DUC must always have at least 2 signatures to validate the document

        4. Requestor Information:

           1. Signed or typed initials are not acceptable; full signatures must be present within the DUC. Electronic signatures are acceptable.

           2. All requestors listed within the AR application must sign the DUC, and their Synapse usernames must be spelled correctly. Usernames are not case sensitive. 

           3. All requestors must be from the same institution. Any collaborators from different institutions need to submit their own DUC and AR application.

           4. Any “extra” requestors listed in the DUC but not in the AR application must be removed.

           5. For data access renewals, it is ok if requestor signature dates have not been updated.

      • IRB Letter: Ensure the IRB letter is current (i.e. approval date is from the past year), and ensure the letter mentions the requested dataset by name. If the letter does not mention the dataset by name, the requestor can also merge their protocol and IRB letter into one document and submit that.

6. If all required fields are completed properly, click the “Approve” button.

7. Users will receive an email stating they have access to the dataset. Access will be valid for the time period stated within the AR.

   1. If any required fields are not filled out correctly, click the “Reject” button.

      1. A window will appear prompting you to preselect rejection reasons to be sent to the user.

      2. Click “Generate Response” and send the rejection email.

Data Access Process Exceptions

1. PsychENCODE: 

   1. Public data is only available to people who have been pre-approved by the NIMH DAC. Once requestors are pre-approved, the Sage Systems Biology Team will file a Jira ticket to ACT to manually grant access to the user(s). 

   2. To manually grant data access: 

      1. Navigate to the PsychENCODE HumanStudies folder and click “Folder Tools” -> “Change User Access.”

      2. Type in the person’s Synapse username, add an approval email message, and click “Approve.”

      3. Resolve the Jira ticket once you have completed the above steps.

2. AstraZeneca Data Access Requests (AR ID: 9604916) require that Intended Data Use statements are evaluated for scientific validity instead of for completion only. Therefore, requests are not approved by ACT. The designated person from the Computational Oncology Team (Jake Albrecht) will be notified through the dashboard submission. If there’s no response to the access request within a week, ACT should email the designated person on the Computational Oncology Team to review and approve/reject the request. 

Revoking Data Access Through Synapse

Overview

If a user no longer requires data access or if a user violates the Synapse or dataset-specific terms of use, ACT may need to revoke access from the user. For ARs containing expiration dates, data access will automatically be revoked from all accounts included in an access request if the submitter does not renew prior to the expiration date.

How to Revoke Access

1. Navigate to the Access Requirement

2. Click on the “Review Data Requestors” button at the bottom of the AR

3. Type in the person’s username within the “Submitter Filter” section 

4. Click the red “Revoke” button next to the person’s name

5. Clear the filter and expand the page to show all results (or export CSV). Control F the person’s username to ensure that they are not also included as an accessor in a different submitter’s access request. If you revoke access from the submitter, but they are still included as an “accessor” for someone else’s request, they may still have data access. 

   1. If you find the person’s username under a different submitter, reach out to the submitter before revoking access. You can ask the submitter to update their request or submit a new request without the person from whom you are revoking access.

Considerations

• If you click “Revoke” next to a submitter’s username, everyone included under the “Accessors” column will also have their access revoked. 

• If the username appears twice in the submitter column and there is no expiration for one of them (i.e. old system request), revoking access to one of these copies will remove access from both copies. Duplicate submitters exist in some cases due to a system update. 

• If the username appears twice in the submitter column and there is an expiration date for both of them (i.e. both are requests from the new system), revoking access to one of these copies will not remove access from both copies.

Troubleshooting Synapse Data Access

Synapse users, and occasionally Community Liaisons at Sage, file a Governance Jira ticket to ACT if a user is experiencing trouble accessing data. Please reference the troubleshooting steps below to assist.

How to Find Out Whether a User has Access

1. Collect the following information: 

   1. What synapse entity (i.e. synID) is the user trying to access? 

   2. What’s the person’s Synapse username?

      1. If you are only given a person’s name, you can search Synapse here to try to find the username

   3. Date of access request submission (if applicable)

2. To see whether the user currently has access, go to the entity AR and select the “Review Data Requestors” button

3. Select “Export CSV” so the entire list loads

4. Use the “Find” function to search the username

5. If you find the username, this means the user currently has access

   1. The user issue may be:

      1. They might be logged in using the wrong username or not logged in to Synapse at all. If the person has two Synapse accounts, make sure they are logged in on the account that was granted access to the data.

      2. They might not have accepted the terms and conditions of use for the dataset (i.e. the click-wrap). You can check the entity or the Conditions for Use page to see whether this applies.

6. If you do not find the username, the user does not currently have access

   1. Check whether a request was submitted, canceled, or rejected in the AR dashboard and offer guidance accordingly. You can do this by clicking the “Review Requests” button within the AR and filtering to the person’s username. You may also want to export the full list of requests and search for the username in the “Accessors” column in case the user in mention was not the submitter.

   2. If you are able to locate the approved request, ensure that the access expiration date has not already passed. If it has already passed, the user will need to renew their access.

Considerations

1. Often, users believe they should have access to AddNeuroMed data and PsychEncode data when they receive access to the AD Knowledge Portal. These projects have their own access requirements, which can be found here.

2. Always check the Conditions for Use page if you are unsure whether a dataset has an ACT-managed AR.

3. Reference this ACT User Support Q&A for common responses to user support emails