Use Cases for this Workflow can be found here.

Current Work Flow

Setting up Access Requirement

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.

Requesting Access

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.

Each request may request n number of users to access the data. A request normally includes information about the institution, the signing official at the institution and the research statement for the project that the list of accessors are working on. Some request requires accessors' signatures, some requires other certificates. For human sensitive data, the request requires that accessors have their Synapse profile validated.

Granting Access

After the users meets all requirements given by the ACT (via emails), an ACT member would go to the dataset and manually enter the user(s) and run an R script to give the user(s) access to the dataset.

Updating Information

When someone leaves an institution, a requestor will email the ACT about removing a member from their request. The ACT will manually remove this user access.

When a new member join a lab, a requestor will email the ACT about adding a new member to their request (and their signatures in some cases). The ACT will manually grant the new user access.

Renewal

Every month, an ACT member will loop over all requests to see which one will expire in a month and send an email to the requestor to remind them about updating their request. If s/he does not response, the ACT member will email other members in their request.

Exporting Information

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.

Since the request information is kept in a spreadsheet, a script is run that gathers public information from this spreadsheet and publishes to a wiki: Principal Investigator, Institution, Date, and Intended Data Use Statement.

Example form:

Link to instructions: https://www.synapse.org/#!Synapse:syn2954404

Disadvantages:

• 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.
• 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 managing AccessRequirement and DataAccessSubmission.

From an entity page, an ACT member can choose 'Manage Access Requirement' from Tools:

From this page, there they can create a new Access Requirement, selecting entities to associate with it. Once the Access Requirement is created, they can create a form for accepting access requests.

For existing Access 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:

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, the ACT may specify that accessors must be certified and/or have validated profiles.

The ACT member can add existing fields:

• 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.

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:

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.

A requestor can save their form without submitting, in case they realize they need to gather other information or have their accessors become certified while they are filling out the form.  To load the data they save, they will visit the dataset as they did to create the request, and click "Create Request"; the information they saved will automatically be loaded into the form upon opening.

Sample email message to ACT after a user requests access (with links to the page that has the table storing access requests - this link will have the Access Requirement and Access Request ID parameterized so that visiting the page will automatically filter the table to only show that request):

____________________________________________________________________________________________________________________________________

Hello,

Karen Altergott (kmaltergott) has requested access to Dataset MayoLOADGWAS. 

For further information, please visit the page for managing that Access Requirement.

Sincerely,

 Synapse Administration

____________________________________________________________________________________________________________________________________

User B can see the status of their request on the dataset.

Possible statuses for a request include: SUBMITTED, APPROVED, REJECTED, EXPIRED.  

The user can cancel their request while it is awaiting approval from the ACT (status=SUBMITTED), but they may not update it.

After the request has been approved/rejected/expired, 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 page for managing the Access Requirement associated with that dataset and inspect the table of requests.

Features of the table view:

Users that have been certified or had their profile validated will have a symbol next to their synapse id (in this case a trophy, though will likely be a shield) as an indicator.  Users who have previously been approved for access to the dataset will have a check mark next to their name.  

The ACT member can query the table to only show requests that are awaiting approval, or only ones that were approved or rejected.  The latter requests will have their approve/reject buttons disabled.

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.  The ACT member viewing the table will be able to view all previous versions of the request by clicking the "View Versions" button.  Doing so will open a dialog with the previous versions of a request:

After the set expiration length of time has passed, 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>

Now the ACT member can view the user request and their submitted form before approving their request with the approval button. Approval may grant access to one user, or to many (ACT will decide based on request).  Clicking approve will open a dialog with a summary for the ACT member to double-check before approving, including the ability to edit the email being sent out upon approval:

Sample email message to researcher after their request has been approved:

____________________________________________________________________________________________________________________________________

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

____________________________________________________________________________________________________________________________________

The data contributor wants to know who has access to their data. Sage has been given report about approved requests including the following information: Principal Investigator, Institution, Date, and Intended Data Use Statement.

Brian has a script that update this wiki: https://www.synapse.org/#!Synapse:syn4993293/wiki/392026

For auditing purposes, ACT member could query requests (find requests that need to be processed, find requests that have been approved and see when they were approved, etc). ACT member could export set of files (associated with the dataset requests) as zip file, to be sent to data contributor.