Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

...

...

...

...

...

...

Dataset A has ACT Restriction. User

Table of Contents
outlinetrue

Current Workflow

Use Cases for this Workflow can be found here.

Setting up the 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.

Example form:

View file
nameROS.MAP_DataUseCertificate_July24.2015.pdf
height250

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

Requesting Access

Dataset A has ACTAccessRequirement. User B wants to download dataset A, s/he /she 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 user 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.A script is run (Brian Bot in mPower?) .

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 the this spreadsheet and publishes to a wiki: Principal Investigator, Institution, Date, and Intended Data Use Statement

Example form:

View file
nameROS.MAP_DataUseCertificate_July24.2015.pdf
height250

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.

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 (like a template)

Image Removed

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:

Image Removed

Once they log in, then they will have the option to "Request Access":

Image Removed

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.

Image Removed

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,

Image Removed Synapse Administration

____________________________________________________________________________________________________________________________________

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

____________________________________________________________________________________________________________________________________

...

____________________________________________________________________________________________________________________________________
  
Sample email message to researcher after their request has been rejected:

____________________________________________________________________________________________________________________________________

...

____________________________________________________________________________________________________________________________________

User B can see the status of request on the dataset with the ability to cancel own request.

Image Removed

An ACT member could go to the dataset link provided in the email. There, they will use a new command only visible to the ACT to show the pending access requests table:

Image Removed  

They will see a queryable table of access requests for the given dataset (since each will have it's own schema).

Image Removed

After querying for only requests that are awaiting approval/rejection:

Image Removed

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:

Image Removed

When the ACT chooses to reject a request, he/she will given a reason for rejection. An email will be sent to the requestor about the rejection. The email will include the reason and a link for user to create a new request based on the previous (rejected) one.

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

...

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

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:

If there is no existing AccessRequirement associated with the entity, an ACT member will be asked to create one.

If there is one or more AccessRequirements associated with the entity, an ACT member will see the following view:

An ACT member can also enter the Access Requirement Manager with a fix URL. 

From there, an ACT member can Create a New Access Requirement, Search for one, and Manage access request.

An ACT member can search for Access Requirements that applies to an entity or a team:

An ACT member can see all ACT Access Requirements that have submissions that need to be reviewed:

When an ACT member choose to create a new Access Requirement, they will be asked to provide the necessary information: 

For PostMessageContentAccessRequirement:


For TermsOfUseAccessRequirement:


For ACTAcessRequirement:


Requesting Access

From a controlled entity page, a user will see the "Show unmet conditions" button:

Clicking on "Show unmet conditions" takes user to a page that shows all AccessRequirements applied to the entity. For a TermsOfUse Access Requirement, user will be asked to sign:

For ACT Access Requirement, user will be asked to create a request:

If someone has submitted a request on the user behalf, they will see the status of the request:

If the user has submitted a request and awaiting for an ACT member to review, they can also cancel their submission.

After the submission is approved, a user will be able to update (add/remove user):

After a submission is rejected, a user will be asked to update information to complete the request:

Clicking on "Create Request," a dialog will ask the user to provide information about their project:

After entering the information about the research project and clicking "Next", user will be prompt to enter the list of accessors and upload required documents:

Once user provided all required information & document, they will be able to submit their request.

If a user choose to Cancel, we will ask if they want to save their changes:

Granting Access

After a user submits a request, an email will be sent to the ACT team:

An ACT member can click on the link provided in the email to go to the Access Requirement Manager page, or navigating to this page from other options described above. The link in the email take an ACT member directly to a location that manages submissions for a particular Access Requirement.

From here, an ACT member can use the provided tools to view the requirements:

After reviewing a submission, an ACT member would click "Approve" to approve the request. This action will create an AccessApproval for each accessors in the approved request.

If the ACT member decides that the request does not meet the required conditions for any reason, he/she would choose "Reject." The ACT member will be asked to provide instructions on how to complete the request.

Updating Information & Renewal

After a request has been approved, the requestor will receive an email from Synapse:

After a request has been rejected, the requestor will receive an email from Synapse:

The requestor can use the provided link to navigate to his/her request and start making changes.

For renewal request, user will be prompt to provide summary of use after they update the existing info:


Exporting Information

ACT member could export set of files associated with the requests as zip file, to be sent to data contributor.

...