Page Comparison

View as PDF

Table of Contents

...

1. AD Knowledge Portal is managed by the Sage Alzheimer’s Disease Translational Research (ADTR) group, which is led by Anna Greenwood.

2. ELITE portal, PsychENCODE (PEC) Portal, CommonMind Consortium (CMC) are all separate and use different access request systems.

3. AddNeuroMed/ANMerge are AD-related datasets (the Alzheimer’s Disease – Community Portal), but are not part of the AD Knowledge Portal. These data are accessed using v.6 of the “AMP-AD Knowledge Portal” DUC, but this will be updated to be a separate DUC in the future.

4. DCC operations on the AD Knowledge Portal, including Governance activities, are funded in part by a DCC-specific grant (which has been submitted for renewal in Spring 2023), but additional support comes from other active grants. As of summer 2023, these include the AGMP and “Exposome” grants and supplements, the AMP-AD 2.0 “Diverse Cohorts” supplement, and the “Mayo Exposome” supplement.

5. The AD Knowledge Portal has a “front end” and a “back end.”

   1. The front end is the portal itself which allows any anonymous user to explore the data held within the portal. Data in the front end are organized first by large-scale research Programs (such as the “AMP-AD” program), which are subdivided into many Projects, and then subdivided further into individual Studies. Data can also be further divided by Publications. The Explore function of the front end allows users to search, sort, filter and interact with all of these views of information to find data suitable for a new secondary-use project. The front end also houses Portal Docs specific to using and navigating the AD Knowledge Portal.

   2. The back end is the standard Synapse navigation where most files and folders are stored. This is where Governance will spend the majority of time. The back end is stored in the NIA-funded STRIDES AWS S3 bucket. While most data is stored in the back end, there are some freestanding projects searchable in the AD Knowledge Portal, yet placed in previously private projects and using the AD Knowledge Portal AR. Examples are:

      1. syn20933797 (uses AD Portal ARs)

      2. syn525258800 (data appears to be open access for registered users)

6. The Community Data Contribution Program (CDCP) is a part of the AD Knowledge Portal. See IV.D for more information on AD CDCP Hub governance.

7. Governance Activities Include:

   1. Data ingress (intake analysis and agreements)

   2. Data access (review of requests in Synapse)

   3. User Support (primarily through Jira tickets). User support includes both contributors and data accessors.

   4. Management of the AD Knowledge Portal AR and Click Wrap.

   5. Management of the AD Knowledge Portal Data Use Certificate (DUC).

...

1. Open Access Tier: Nonhuman data or data with little to no risk of re-identification will follow open access. Users must be registered Synapse users and must accept the AD Knowledge Portal Click Wrap (AR ID: 5592528)

2. Standard Controlled Access Tier Using the ADKP Umbrella AR: Sensitive data including -omics data or data from vulnerable populations will follow controlled access tier governance procedures outlined below.

   1. Signed Agreement: AD Knowledge Portal Data Use Certificate (DUC) (AR ID: 9603055)

   2. Intended Data Use statement required

   3. Approved statements will be publicly available on Synapse

   4. IRB/Ethics Approval or Waiver (required for highly sensitive Data or HIPAA-limited Data only)

   5. Disposition Requirement: delete locally stored Data upon conclusion of research or expiration of Data Access

   6. Data access expiration/renewal period is 1 year

   7. Default is General Research Use (commercial, non-commercial, and for any research use)

...

1. Background: The AD CDCP Hub is a separate project (syn52798627) housed on the NIA-funded STRIDES S3 data bucket. The purpose of the Hub is to provide a temporary space for data to be uploaded and accessible for data contributions that are approved for inclusion in the CDCP but data curation has not been completed yet. This is to accommodate data sharing while ADTR experiences data curation delays.

2. Governance Features

   1. AD CDCP Hub utilizes the AD Knowledge Portal DUC and instructions (AR ID: 5592528). This is applied to each controlled access folder.

   2. The Hub also utilizes an AD CDCP Hub template Click Wrap. Each Click Wrap is customized for each data set (so users will have to accept the Click Wrap each time they wish to access a CDCP dataset). This differs from the AD Knowledge Portal Click Wrap, which users only have to accept once and then it is applied across the portal. Key components of the Click Wrap:

      1. Data has not been curated.

      2. Data is provided as-is.

      3. Data may be migrated to the AD Knowledge Portal at any time and without notice.

      4. Data accessor agrees that publications generated using data accessed from the AD CDCP Hub must acknowledge and cite both the AD Knowledge Portal Community Data Contribution Program (CDCP) and the data contributor as described in the study specific acknowledgement statement.

3. Template Click Wrap:

...

1. Onboarding New Programs. Key Components:

   1. Introductory meeting between ADTR, Governance, and the data contributors. These introductory meetings can provide a brief explanation of the governance process, questions asked, a mention of whether agreements will be necessary, and some time for questions.

   2. Additional discussion during the initial onboarding to answer questions about topics such as data sensitivity, data types, contract restrictions, data use limitations due to consent form requirements, or authority to contribute the data. Each of these topics may have significant impacts on the shareability of the data and may affect access requirements.

2. New AD Programs Data Ingress. Components:

   1. Contributor completes a data landscape survey. This is initiated by ADTR through an ADEL ticket in Jira. Once a data contributor is ready to bring data into Synapse, the data contributor must fill out an ADEL ticket.

   2. ADTR will initiate an SG Jira ticket. The ticket will link to the ADEL ticket and will generally ask that an AR is added to an existing Data folder in the AD Knowledge Portal. The Data folder will be created by ADTR along with a Staging folder. The Staging folder does not need to have ARs applied to it since ADTR will use folder sharing settings to control access. (Data is initially added to Synapse by data contributors using the Staging folder. Once the curation process is complete, the data is then moved to the Data folder. Once the Data is ready, ADTR will make the Data folder public.)

   3. Governance conducts an assessment. Documented through the SG ticket, data provided through the ADEL ticket, and in combination with any other data, information, conversations or other factors, the Governance Analyst should assess the appropriate access restrictions to be applied on a data-specific basis. See additional guidance below in IV.E.4 and IV.E.5.

   4. Governance applies file restrictions. Based on the sensitivity of the data, and any use restrictions, Governance will apply restrictions to the data file created by ADTR as appropriate and document the rationale in the SG ticket. This may include no restrictions (if the data has no risks such as open-access animal data) with click-wrap only, the standard AD Knowledge Portal AR (see IV.B.2), or a different/additional AR if the data requires additional restrictions such as an IRB letter or restriction from commercial use (see IV.C).

3. Agreements

   1. If the project is covered through a “portal grant,” institutional signoff is not required. A “portal grant” refers to a grant or similar funding mechanism where the funding documents specifically state that data will be stored in Synapse and the AD Knowledge Portal. The reason additional institutional signoff is not required (i.e., through an additional agreement document) is because the institutions are required to have formal institutional signoff on the grant to receive funds. This mechanism is considered to be the institution’s agreement that the data will go into the AD Knowledge Portal.

      1. Depending on the PI and situation, it may still be beneficial to obtain a PI’s signoff that the data is going to be provided to the portal in a manner that meets our standards. These generally include (but are not limited to) the following concepts:

         1. Data is appropriately de-identified,

         2. The provider has the authority to provide the data,

         3. Data sharing conforms with with subject informed consent and IRB approvals,

         4. No conflicting contracts exist,

         5. Provider agrees to make any necessary quality corrections as soon as possible.

      2. Depending on the project, in order to determine the appropriate governance structure, it is likely still necessary to have a full understanding of the data. For example, the Duke AGMP (Alzheimer’s Gut Microbiome Project) and the “exposome” component represent data types, or a combination of linked data types, that may be more sensitive or increase the risk of re-identification. Having an understanding of this data and any restrictions placed on the data from their originating sources is important to understand in order to determine whether the typical AD Knowledge Portal umbrella AR is adequate.

      3. In some cases, it may be adequate to have the PI sign a shorter attestation if the data is additive and aligned with an original portal grant. For example, see the “Diverse Cohorts” agreement signed by Richard Mayeux at Columbia University. This was considered to be an “expansion” of an original agreement signed by the lead site PI, Philip De Jager.

   2. If the project is not covered under a portal grant, then a full agreement may be necessary. This full agreement includes signatures from Sage (VP of Research Governance and Ethics) and (typically) a grants and contracts official at the contributing institution. A PI does not typically need to sign the agreement because responsibility and authority lies with the institution.

4. General Governance Assessments of Data

   1. (To be added in a future revision.)

5. Data Ingress Adaptations for Existing Programs. This generally refers to a situation where a PI who is already covered under an existing agreement or portal grant is contributing additional data from another collaborator. In this case, the assumption is that the main PI of the program does NOT have authority to provide the data. There are a few paths through which this can be negotiated.

   1. The PI verifies an agreement is in place (or establishes a new agreement independent of Sage, especially if the collaborator is at a different institution) between the originating source institution or collaborator such that data can be shared. In this case, the PI would have the authority to share data in the AD Knowledge Portal if there is an existing agreement stating that data sharing or placing the data into a repository is allowed.

   2. The originating source collaborator signs an agreement with Sage. This is ideal when the other collaborator is at the same institution. Depending on the circumstances, this could involve a shortened “Data Sharing Permissions” type of agreement, or the full agreement template can be used. The benefit of the shorter agreement is that it may be possible to expedite signing from an institutional signing official. For an example, see Data Sharing Permissions form signed by Richard Mayeux. Required signatures for the shortened agreement:

      1. Originating Source PI

      2. Signing official

6. Community Data Contribution Program (CDCP) Data Ingress

   1. Overall process:

      1. A ticket is created in the AD+EL (ADEL) Service Desk

         1. ADTR may instruct CDCP contributors to initiate a ticket in the AD+EL Service Desk (ADEL). This process ensures that contributors answer several preliminary questions about the data. ADTR will communicate with the contributor and will assign the ADEL ticket to the AD Knowledge Portal Governance Lead once the stopping point is initiation of an agreement.

         2. In some cases, the contributor may initiate a ticket in the ACT Service Desk. In these cases, where Governance Lead has confirmed that the ticket should be transferred and evaluated by the ADTR, the ticket should be transferred to ADEL. Use SOP03-RM02

      2. ADTR will also create an SG ticket in Jira and assign it to the AD Knowledge Portal Governance Lead. ADTR will provide details about the study in the ticket, but the Governance analyst should also review the original responses captured within the original, linked ADEL ticket.

      3. The Governance Lead initiates an agreement with the CDCP institution.

         1. Prepare a full template in Microsoft Word format.

            1. Create a folder in the file, CFS-AD-Governance in the “_PENDING” folder.

            2. Name the folder “AD-CDCP-[Institution]-[PI Last Name]

            3. Create a copy of the template (v.5.3 in .docx format). Note: use Microsoft Word only. Opening the document in Google Docs will break the formatting during conversion.

            4. Fill out as much of the template for the PI as possible. Assume the data will meet the typical standards unless otherwise noted in the SG or ADEL tickets. (Since CDCP contributions must use the AD Knowledge Portal DUC, the data should not require additional governance structures.)

         2. Using the ADEL ticket, send a message to the Institution’s point of contact. Be instructive about what needs to happen next. See below for Canned Language.

         3. The template will require signatures from:

            1. The Institutional Signing Official (a grants and contracts specialist, typically)

            2. Sage Institutional Signing Official (VP of Research Governance and Ethics)

      4. Once the document is fully executed:

         1. Save the PDF copy in the folder created in step 1.a., then move the whole folder out of the _PENDING folder.

         2. Close the SG ticket as Done.

         3. Reassign the ADEL ticket(s) to the Project Manager (or similar role).

...

1. Prepare web browser tools.

   1. Navigate to the Synapse Data Access Management Page. The page defaults to the “Submissions” view.

   2. Open a 2^nd browser tab for the “User Access History” view.

   3. Open a 3^rd browser tab for the Smartsheet Data Access Requests form. No login to Smartsheet is required to fill out forms. (If revisions to the Smartsheet are required, the full sheet can be accessed with login HERE.)

2. Identify a requester’s Synapse username from the “Submissions” view and enter it into the “User Access History” view. Use the access history view to determine:

   1. Whether this is the user’s first submission, an update, an annual renewal, or a correction after a rejection. This information is used for metrics purposes.

      1. A “First Submission” represents the first time a particular user attempts to gain access to AD Knowledge Portal data. This includes any rejections and subsequent resubmissions to gain initial access.

      2. An “Update” is when the user makes a change at any time during their current approval period. Updates are often used to add or remove data requesters, but may also include updates to the IDU statement or other components of the submission process.

      3. A “Renewal” is specifically an updated access request required each year. The main indicator that a submission is an annual renewal is that it is being submitted approximately 1 year from the initial approval. See additional information below in section VI.1.A.

   2. The User Access History view is also used to review the reasons for the last rejection. This information can streamline review of the current submission.

3. Navigate to the current access request.

4. Review the Intended Data Use (IDU) statement using the following criteria:

   1. The IDU must include objectives, study design and the analysis plan. This is usually rephrased as needing to include the following points: “What do you want to do? Why are you doing it? How do you want to do it?”

   2. The IDU must include the names of the AD Knowledge Portal studies from which the requester wishes to access data.

      1. Researchers may include any number of studies in their IDU statement. At least one study should be named in the IDU statement.

      2. If the researcher needs to use multiple studies, per Anna Greenwood, the requester should at least address their top three used studies. This is not a publicized clarification but can be noted if the requester pushes back on the request to list study names (for example, if the researcher complains that naming all the studies they will use is too difficult).

      3. The purpose of asking for the names of the studies to be used is so data contributors can perform a search of public IDU statements to understand when and how people are using their data.

      4. This is also a “newer” requirement, so some previously approved requests may not have included this information and will need to be rejected on that basis if this content is missing.

      5. The IDU statement must include “Studies” and not Programs. If “AMP-AD” is listed only, for example, the submitter should be notified that AMP-AD is a program that represents many studies. They should be directed to provide the list of studies from AMP-AD that they plan to use and use this link (see example VI.B.2 below): https://adknowledgeportal.synapse.org/Explore/Studies

      6. For now, if the submitter included a study’s synID, this is also acceptable, but the reviewer should spot check to make sure they are AD Portal studies.

   3. If the submission is an annual renewal, it may be appropriate to prompt the study team for updated information, but this is generally rare.

      1. There currently are no reliable cues in the Submissions view to identify annual renewals, but the information the User Access History view can provide indicators (e.g., it has been almost exactly 1 year since the original approval). However, if the data requester updated their request frequently, it may be more difficult to determine using dates.

   4. ACT does not review for scientific content, but if there are any obvious scientific issues, contact Anna or other members of ADTR with questions.

5. Review the Data Use Certificate for the following criteria:

   1. The DUC must be the current version (v.7.3 OR v.7.3.1). The currently posted version is v.7.3.1, but changes to this version were to instructions and formatting only, so v.7.3 should still be accepted. Check the document footers for consistency. If needed, compare the document against the posted version. Previous versions can be found here: https://drive.google.com/drive/folders/10pE3vyITc8o7shq_4pR-ThqzATarTZjL

      1. Note: There were two versions of v.7.3 available for download and use. One was found at the Synapse link, https://www.synapse.org/#!Synapse:syn25441378. The other version was available directly from the data access request tool. Since the documents are not substantively different, either should be accepted, but there are some appearance and formatting differences.

   2. The DUC content must not be modified. Users (or contract offices) cannot add or line out content.

   3. Signature blocks (general):

      1. All fields should be completed. A possible exception is if data is embedded in an electronic signature and is not repeated directly into the signature block fields.

      2. Electronic signatures are generally acceptable regardless of how they were executed. For example: Docusign, Adobe Sign, images.

      3. As long as all elements are complete and documented on the correct DUC version, past signatures and dates are currently accepted.

   4. Signing Official is complete.

      1. Signing Official criteria: (a) Has oversight over the data requestors, (b) Is responsible for ensuring appropriate and ethical use of the Data by the data requestor, and (c) Is not a member of the study team.

      2. The Signing Official must not be the Principal Investigator and must not be a data requester.

      3. Some previously approved DUCs have been approved with the same person signing as Signing Official and PI. These must be corrected.

      4. The “Title” field is sometimes not completed properly (e.g., populated with a study title). Some entries may be acceptable (e.g., if it is completed with “Dr.”), but if more information is needed to determine whether the Signing Official is appropriate, corrections may be required.

      5. It is common for institutional sponsored projects, contracts offices, or similar offices to sign as Signing Official. This is generally accepted, but technically, the preferred signatory is someone who has greater oversight over the data requesters, such as a department head.

   5. Principal Investigator signature block is complete.

      1. There are no predefined requirements for who can be a Principal Investigator.

      2. A Synapse username is required and the PI should be listed as a data requester regardless of who submitted the access request.

   6. Other Data Requesters:

      1. All data requesters must be from the same institution.

      2. All fields must be complete, including signature.

      3. There are no specified limits on the number of additional requesters.

6. Review Access Request Details.

   1. Data Requesters listed must exactly match the Synapse usernames listed on the DUC. Any inconsistencies must be corrected.

   2. Institution name must be unabbreviated.

   3. Project Lead must be a person’s First and Last name. Sometimes this field is populated with a study title, which must be corrected.

7. Rejection. If any revisions are required, click the Reject button. If no revisions are required, skip to step 8.

   

   1. If any revisions are required to the access request, click on the “Reject” button.

   2. In the following pop-up dialog box, select the applicable Reasons for rejecting, then select “Generate Email”. These selections are not AD Knowledge Portal, but are used to automate a rejection email.

      

   3. Revise the generated email as needed. Use Example Rejection language, if helpful to communicate additional instructions and context.

      

8. Approval. Click the “Approve” button and the following confirmation pop-up if no revisions are required.

9. Complete the Smartsheet Data Access Requests form.

   

   1. Analyst: Select the name of the person who completed the review.

   2. Program/Project: Select AD Knowledge Portal

   3. Submitter: enter the username of the submitter, including the @ symbol.

   4. Number of Requesters: Include the number of requesters associated with the request. Note that the numeric value shown in the left margin will show an absolute value of the people listed regardless of whether they are “Gain,” “Renew” or “Revoke.” Include only “Gain” or “Renew” data requesters. Regardless of their intent, for the purposes of filling out the form, only include the number of requesters that were included in the electronic request form. In other words, if the DUC includes 5 requesters but only the submitter is listed in the electronic request form, the number of requesters entered into Smartsheet should be 1. (This example results in a rejection.)

   5. Date Received: Select the date the request was submitted.

   6. Type: Select whether the submission was a “New” request, an “Update” to an existing submission, an “Annual” renewal or “Other.” This information should be determined using the User Access History view as mentioned in step 4.iii.a above. “Other” is rarely used, but if used, explain in the Notes field.

   7. Attempt: Using the User Access History, note the number of attempts the user has made to get an approval on the current submission.

   8. Status: Mark whether the determination was “Approved” or “Rejected.”

   9. Date Complete: Select the date when the current submission was Approved or Rejected.

   10. Link to Submission: For ease of accessing the submission again from Smartsheet, copy and paste the URL to the submission from the browser.

   11. Reason for Rejection: This field is hidden until the Status is changed to “Rejected.” Select all reasons for rejection applicable to the current review.

       

   12. Time: Enter the time it took to complete the review if a time study is being conducted or coverage time is being tracked. Otherwise, this may be left blank.

   13. Notes: Enter a note about the review, if desired. This is optional.

   14. Click the “Submit” button. The data will automatically be added to the bottom of the main Smartsheet. A new form will automatically refresh.

   15. For Approved “Update” submissions only, previously-approved requester counts will need to be suppressed so they do not get added to the Dashboard. Access the Data Access Requests Smartsheet, and using the Find function (Command-F), search for the Update submitter’s username. Locate the previously-approved submission, then click the checkbox in the “Suppress From Total” column. Save the changes.

...

1. Navigate to the AD Knowledge Portal umbrella AR (AR ID: 9603055) or Click Wrap (AR ID: 5592528).

2. Click the “Edit Access Requirement” button.

3. Skip to the next screen by clicking the “Next” button.

4. If editing the instructions, click the “Edit Instructions” button mid-way down the page. Instructions should be written in wiki markup.

5. If editing other requirements, click the corresponding checkboxes, or update the DUC template, if needed.

...

1. Navigate to the Google Docs version of the AD Knowledge Portal DUC. Check to see if a Draft is already started. Drafts should be saved to the folder: SBGov/Governance Documentation on Projects/AD/AD Knowledge Portal DUCs/Draft Version

2. If a draft is not started:

   1. Navigate to the Google Docs version of the AD Knowledge Portal DUC. The current copy of the AD Knowledge Portal DUC is located in the folder: SBGov/Governance Documentation on Projects/AD/AD Knowledge Portal DUCs/Current Version

   2. Make a copy of the current version and save it to the aforementioned Drafts folder.

3. Make changes as needed. Be sure to update the version date in the footer and the document title.

4. Get sign-off from key stakeholders including Christine and Anna.

5. Finalize the Google Doc.

6. Convert to PDF.

7. Post on the AR using the instructions in IV.D. Upload an update to the Synapse page (syn2580853).

8. Rename and move files. Move the current version to the Archived folder. Move the finalized version to the Current Version folder.

Anchor
_heading=h.cyklbutc5ik _heading=h.cyklbutc5ik

I. Manually Revoking Access

In certain cases, users may directly request that access is revoked. For example, a user may leave their current institution and their request may need to be initiated by another user. (Example Requests: SYNSD-280, SG-4315)

Access revocation may also need to occur for other compliance reasons.

...

1. Confirm the revocation should take place. This may involve documented confirmations from an appropriate requester such as the data requester directly, a qualified institutional official or representative (e.g., a legal office or contracts administrator), or from Sage Governance leadership.

2. Locate the AD Knowledge Portal AR (AR ID: 9603055). Access it either by searching for it on the Access Requirements tab of the ACT Data Access Management dashboard, or by navigating directly to the AR using this link.

3. Click on the “Review Data Requestors” button (or use this link).

4. In the “Accessor Filter,” search for the submitter.

5. In the results, click on the red “Revoke” button.

6. Confirm the revocation in the pop-up dialog box.

...

1. More about “Annual Renewals”

   1. The DUC includes statements regarding annual renewal requirements:

      1. “Submit an annual progress report describing the research performed with these data by the approved users in the past year as well as the intended use of the data for the next year (1-3 paragraphs).

      2. Provide an updated list of collaborators (including name and Synapse username) who will be accessing these data to perform the proposed research.

      3. Confirm continued agreement with all Data Access Terms and Conditions, and any specific data use limitations.

   2. There is a disconnect between these instructions, the responsibilities of ACT review, and the content prompted in the Data Access Request tool.

      1. Governance is not currently enforcing a progress report. However, when users are prompted by the system to submit an annual renewal, they receive additional questions on the access request screen as shown below.

         

      2. Currently, these questions are likely being answered by the community but are not visible to ACT. It is unclear whether the information is being stored.

   3. In resolution, for annual renewals, ACT can request that the submitter updates the general IDU statement if it seems necessary, but the reviewer should be aware that the submitter may have provided progress report information that is not visible.

2. Alterations to the DUC by the Submitter or Signing Official

   1. Reference Access Requests: User @mfernandes. The DUC should not be altered and the reviewer needs to inform the submitter that an unaltered DUC is required. In some cases, a signing official may try to cross out sections of the DUC, which seems to be related to signing officials who are contracts agents for their institutions but cannot attest to having oversight authority over the data requester. Generally, the DUC is not meant to be a contract to be routed through a grants & contracts office; however, this is a common and accepted practice. The Signing Official must meet the basic criteria described on the DUC, and the role is typically more appropriate for a Department Head or similar position.

3. Duplicate Access Requests

   1. Reference Access Requests: user @knho and user @filsilva. Users can have multiple access requests if they have more than one IDU statement. It is possible for the user to provide the same DUC if they are conducting the work on behalf of the same affiliation in both cases. Additional considerations:

      1. What if the DUC includes a list of multiple data accessors, but the full list is not applicable to each request?

         1. It is acceptable to allow the list of access requesters on the DUC to be longer than the list requested for the specific IDU statement in this case.

4. IDU Statement to Replicate a Published Study

   1. Reference Access Request: user @naf1zh. If a user’s IDU is to replicate a published study, the IDU must still contain the required IDU elements.

5. Independent/Individual Researchers

   1. Individual researchers who are not affiliated with an institution and do not have a signing official are unable to meet the terms of the AD Knowledge Portal Access Requirements. While other studies will have other access models (for example, independent researchers who wish to participate in Challenges and who do not want the work to be associated with their employer), affiliation with an institution and the presence of a valid Signing Official is required.

...

...

Submitter: @chiara.cabrelle

...