Table of Contents

I. Description

This RM identifies and describes the processes used by Sage Governance to support the AD Knowledge Portal. Key sections include:

• Data Ingress Processes

• Data Access Review Processes

• Updating AD Knowledge Portal ARs and Click Wrap

• Updating the AD Knowledge Portal Data Use Certificate (DUC)

• Revoking access

II. Scope

Processes described in this RM are specific to the AD Knowledge Portal. Governance models and procedures should be generalized to other projects with caution.

III. Definitions & Acronyms

Acronyms

AD - Alzheimer’s Disease

ADTR - Alzheimer’s Disease Translational Research

AR - Access Requirement

DUC – Data Use Certificate

IDU Statement – Intended Data Use Statement

IV. Governance on the AD Knowledge Portal

A. Overview

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 were accessed using v.6 of the “AMP-AD Knowledge Portal” DUC until 02/22/2024. The DUC was updated to be project-specific and can be found in the project’s Documents folder.

4. DCC operations on the AD Knowledge Portal, including Governance activities, are funded in part by a DCC-specific grant, but additional support comes from other active grants. Project descriptions can be found in the Sage Project Index.

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

B. AD Knowledge Portal Governance Model - Standard Features

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 (would be required for highly sensitive Data or HIPAA-limited Data only). As of August 2024, this has not been required for any AD Portal data.

   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)

C. AD Knowledge Portal Governance Model - Data-Dependent Features

1. At this time, all data in the AD Knowledge Portal is governed by the two standard access requirements described in VI.B. above. However, it is important to note that while the standard approach is preferable for many reasons, new data intake with higher levels of sensitivity or other features such as use limitations based on informed consent might require additional ARs to be created and used. An example of this might be data that is required by NIA to be added to the AD Knowledge Portal but the subjects consented to only allowing data to be used by non-profit organizations. A new AR or other verification process would be required to account for these limitations on the particular dataset.

D. AD CDCP Hub Governance Model

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: 9603055). 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 folder (so users will have to accept the Click Wrap each time they wish to access a different CDCP study). 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:

E. Data Ingress Processes

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.

   3. A determination whether a private consortium space will be needed/desired. Private consortium spaces can be used to compile AD Knowledge Portal datasets using the Dataset feature, and/or can house data and analyses that are available only to internal members.

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. Alternatively, if the contributor does not fill out an ADEL ticket and the agreement process should be initiated, ADTR can provide key information using the PCO Service Desk “Establish a Data Ingress Agreement” issue type. If this alternative step is taken, skip step b. below.

   2. ADTR will initiate an PCO Service Desk ticket Jira ticket. The PCO ticket will link to the ADEL ticket. The Community Governance Strategy team member will be assigned to the ADEL ticket and will engage the external collaborator through the ADEL ticket.

   3. If an ADEL ticket has not been created, communication with the external collaborator can be completed through the PCO Service Desk ticket by adding the external collaborator’s email to the “Request Participant” field.

   4. Community Governance Strategy conducts an assessment of the data using the information entered into the ADEL ticket or the PCO Service Desk form. This assessment may also include a combination of any other supplemental data, information, conversations, or other factors. The Analyst should assess the appropriate access restrictions to be applied on a data-specific basis. If the standard AD Knowledge Portal governance model applies, no further analyses are generally needed. If special terms apply, such as Data Use Limitations or HIPAA Limited Data Sets, the governance model will need to be re-evaluated and negotiated on a case-by-case basis. This deviation from the standard governance model will be documented in the See additional guidance below in IV.E.4 and IV.E.5.

   5. After an ingress agreement is established, an AR is added to an existing Data folder in the AD Knowledge Portal by the Governane Innovation team. ADTR should initiate a ticket in the GAE software project. 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, which will be kept private.) 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. Access controls may include no restrictions (if the data has no risks such as open-access animal data) with an acknowledgement click-wrap only (see IV.B.1), 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 and Template Selection in Detail

   Open

   

   Data Ingress Agreement Decision Chart (08/2024)

   1. The preferred mechanism for ingress agreements will be use of the the Umbrella Agreement. This agreement is meant to cover all present and future data contributions for the institution. Exhibit A is completed for each project and is functionally an attachment to the original agreement. The desired approach is for Exhibit A to only be signed by an investigator, not the institution, to accommodate the most nimble approach. However, institutions may insist upon an institutional signature being included on Exhibit A. This approach should only be used for projects that can conform to the standard AD Knowledge Portal governance model (IV.B.). If the Umbrella Agreement is accepted and signed by the Institution and a non-standard governance model is required (e.g., data use limitations such as IRB letter), an addendum agreement may be used.

   2. The Data Sharing Permissions template is an older approach used when a nimble approach is desired (or demanded) and if the project is covered through a “portal grant”. A “portal grant” is an NIH grant that explicitly includes a statement that data will be placed in the AD Knowledge Portal. The thought here is that the institution has already signed off on data being transferred to the AD Knowledge Portal, so additional institutional sign off is not required.

      1. Depending on the PI and situation, the PI’s sign off that the data is going to be provided to the portal in a manner that meets our standards will still be required. 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, the PI should sign a Data Sharing Permissions template when 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. However, this approach should ideally be replaced altogether with the Umbrella Agreement approach.

   3. Full Master DTA: If the project is not covered under a portal grant, and the Umbrella Agreement approach is either not accepted or the timeline is too restrictive, then a full project-specific agreement may be necessary. This full agreement includes signatures from Sage (VP of Research Governance and Ethics) and 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. Data Sharing Permissions for ROSMAP Data is used when the data contribution is either reprocessed ROSMAP data from the portal, or new analyses of ROSMAP samples obtained directly from Rush. The basis for this approach is that the Director of the RADC at Rush, David Bennett, confirmed via email that “Each site can share the data with a DUA. Sage has a RUSH approved DUA for RADC data.”

   Open

   

5. Community Data Contribution Program (CDCP) Data Ingress Agreements

   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 a PCO Service Desk ticket in Jira and it will be assigned to the AD Knowledge Portal Governance Lead. ADTR will provide details about the study in the ticket, but the Community Governance Strategy 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 an Umbrella Agreement, Exhibit A (if an Umbrella Agreement has already been signed with the institution), or a Full Master DTA 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. 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 PCO or ADEL tickets. (Since CDCP contributions must use the AD Knowledge Portal DUC, the data should not require additional governance structures.) Add the Unique Identifier from the SageBase Agreement Library for Governance in Airtable.

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

      4. Negotiate the content of the Agreement as needed.

      5. 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. Resolve the PCO ticket as Done.

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

F. Data Access Review Process

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. It is often difficult to identify when this occurs, but may be referenced in the “Institution” fields or in the Intended

      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 Data Access Requests Google Sheet.

   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.

   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 Google sheet should be 1. (This example results in a rejection.)

   5. Date Received: Enter 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.

   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: Enter the date when the current submission was Approved or Rejected.

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

   11. Reason for Rejection: Not currently collected.

G. Updating the AD Knowledge Portal AR or Click Wrap

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.

H. Updating the AD Knowledge Portal DUC

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.

I. Manually Revoking Access

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.

V. User Support (in Jira)

1. AD Knowledge Portal users often submit questions or support requests that make their way to two Jira Service Desks: ACT SD or SYNSD. Governance Innovation is responsible for answering these questions. Common topics include:

   1. Questions or issues with filling out the DUC. For example, who can sign as Signing Official, or institutional concerns leading to the creation of a Side Letter.

   2. Questions or issues with providing an Intended Data Use statement, including issues with providing a list of AD Knowledge Portal studies that accessors wish to use.

   3. Questions or issues with access renewal. For example, many groups tend to turn in their renewals late and may panic once they receive a revocation email.

   4. Issues with access. For example, a common issue is that the team completed the DUC process but all team members might not have accepted the click-wrap.

VI. Reference Material

A. Data Access Review Issues

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. 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. 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. If a user’s IDU is to replicate a published study, the IDU must still contain the required IDU elements.

5. Independent/Individual Researchers (No Institution)

   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.

B. Example Edited Rejection Language

VII. Revision History