Solution

From the use cases that listed in this document, we list the summary of the solution below:

1. The ACT has a way to manage requests for datasets under ACTAccessRequirement. We need to support the following:
   1. Ability to view Submitted requests for a particular dataset. Allowing the ACT to see all information and quickly decide if the request contains the required information.
   2. Ability to approve a request and grant access to all accessors.
   3. Ability to reject a request, provide the instructions on how to correct/provide the missing information, and send email to requestor.
2. The ACT has a way to configure the ACTAccessRequirement to indicate the required information, if the data set requires annual renewal, and if the intended data use statement should be public. 
3. A requestor has a way to create a request, save it, and submit it to ask for access to a dataset under ACTAccessRequirement. 
4. A requestor will be able to correct the old request and submit it after the old submission was rejected. They would not need to type/ provide any correct information that they already provided in the old submission.
5. A requestor will be able to remove an accessor from his/her approved request. This action takes away the accessor's access to the dataset.
6. The system automatically sends annual review reminder emails to accessors.
7. An accessor will be able to provide the required information for the annual review process to keep their access to the dataset.
8. An accessor will be able to provide the final statement of use when they no longer need to access the controlled data.
9. The system will automatically remove AccessApproval from users who have not submitted a renewal request within a year for dataset that requires renewal.

We recognize the needs to support #1 - #7 in the first phase. From the ACT, we haven't had users come back to us with a final statement of use, so #8 would have low priority. We are not very strict about removing access, so not sure if #9 is necessary. 

Object Models

Any user can create a ResearchProject. To create a ResearchProject, the following information are required: accessRequirementId, institution, projectLead, intendedDataUseStatement, ownerId, and createdBy. The following fields: id, createdOn, and modifiedOn are set by the system. A user will not be able to change these values.

After a ResearchProject is created, only the creator can make changes to a ResearchProject. The owner can also change the ownership of a ResearchProject by changing the ownerId value to another userId that has been granted access to the dataset under the same ResearchProject. After taking over the ResearchProject, a user would have the same permissions with the DataAccessRequest's creator.

Any user can create a Request to a given AccessRequirement. To create a Request, the following fields are required: accessRequirementId, and createdBy. The following fields: id, createdOn, and modifiedOn are set by the system. A user cannot change these values.

Only creator of Request can update, and submit the request. To submit a request, it has to meet the requirements specified in the associated AccessRequirement.

Once a request is submitted, a Submission object is created. While there is an Submission with status SUBMITTED, it's associated Request no longer available for update & submit. 

Once a Submission is approved and requestor wants to add/ remove accessors, he/she needs to update the request with a Renewal, given the publication and summaryOfUse in addition to editing the existing information from the original Request. 

Submitting a Renewal will also result in a Submission being created with status SUBMITTED. 

Once a Submission is created, it will have state SUBMITTED until a reviewer (ACT member) review and update its status. 

After a submission is Rejected and a reason is provided, the submission is closed for modification.

When an ACT member approves a submission, multiple AccessApproval are created for each accessor. 

When a requestor adds/removes a user, he/she will also need to update the request and create a new submission. An ACT member will review the new submission and make decision to grant/revoke access to the accessor. 

Services

Notification

May Summary

By May 2017, we have completed #1-4, #7 & #8 under Solution. We have implemented all APIs listed under Services. The feature is under alpha in stack-180.

From user's feedback, we still need to provide the following:

1. Need notifications for ACT when there is a new submission - may only get 1-2 requests a week for old dataset.
2. Revoking access - when user is removed in an updated request, revoke user access.  System should send a message to the people removed (Amy to help with messaging).
3. Bundle submission together (like Brian suggested) to see latest + history.  May be able to work around if we have ability to sort by institution, and filter by Submitted By.
4. RENEWAL SUPPORT.  ACT currently manually revokes user access.  We need to help support the existing process in the new system, or automate it. To help support, they need ability to filter by the date granted access, and ability to get the list of emails.  Alternatively, system could automatically send out emails at specific reminder dates, and auto-revoke access after expiration.  

As a path moving forward, we decided that when we bring the feature out of alpha, an ACT member can continue managing access outside of Synapse, or switch to use the new system. To be able to achieve this, SWC needs to know if an ACTAccessRequirement was configured to use Synapse to keep track of Submission. 

After a discussion, we conclude on:

1. Making AccessRequirement version-able. 
2. An access approval grants a user access to a specific access requirement version.
3. On download, if a user have access approval for any version of the access requirement, the user meets the conditions specified by that access requirement.
4. A new API need to be added to retrieve a version of an access requirement.
5. Retrieving restriction information API needs to be generic (taking an ID and subject type instead of being specific for entity only)
6. A submission points to a particular access requirement version. 
7. Retrieving Access Requirement Status always include information about whether or not a user have met the conditions specified by the access requirement regardless of version.