Term | Definition | Details | |
---|---|---|---|
1 | Access Approval/Rejection | When a Synapse user submits an access request to a Managed AR, their request can either be approved or rejected by ACT. | Once ACT approves or rejects an access request, an email is generated to the access request submitter. The rejection email links the submitter to the AR in Synapse so that they can resubmit their access request, and it also explains what they need to update in their access application to become approved. Note that approval and rejection automatic emails are only sent to the request submitters and not to everyone included within the access request. |
2 | Access Renewal | Some Managed ARs require request submitters to renew their data access after a specified time interval. | Automated Synapse emails are sent to request submitters before their access is set to expire, and if the user does not resubmit an access request application by the expiration date they will lose access to the respective data. Most access renewal periods are yearly, but this field can be customized by ACT during the Access Requirement setup. During the renewal, users should update their Intended Data Use statement and their list of Data Requestors from their institution that need access to the data (note: Data Requestors should be updated in both the access application and in the DUC if applicable). |
3 | Access Requirement (AR) | An Access Requirement (AR) is a data use restriction set up by ACT that defines conditions for access to a Synapse entity. | Managed ARs require a Data Access Committee (DAC) to approve the access request before users can obtain access to the Synapse entity. Other ARs include "click-wraps" which do not require DAC approval, and only require users to read data use conditions and click "I accept" before obtaining acccess. ARs can be set up for projects, folders, tables, and teams. |
4 | Access Request | An access request is when a Synapse user submits a data access application to a Data Access Committee (DAC). | Once an access request is approved, the user will gain access to one or more Synapse entities. A user can submit one access request on behalf of several collaborating Synapse users at their institution |
5 | Access Request Submitter | An Access Request Submitter is a Synapse user that submits an access request. | Multiple data requestors can be included within an access request, but each request can only have one submitter via Synapse. This person is the only user that receives approval/rejection emails generated from a request. |
6 | Acknowledgement Statement (Attribution) | A statement that a Data Contributor requires data recipients to include in publications, talks, presentations, etc. Its purpose is to ensure the Data Contributor (and any other relevant bodies, such as participants or funders) are recognized for their efforts surrounding the data. | Acknowledgement Statements are often included within the project wiki page or within a click-wrap agreement. |
7 | ACT (ACT Team) | The Access and Compliance Team (ACT) is a governance subteam that has special governance administration related privledges on Synapse, allowing it to process access requests, create and manage ARs, validate user profiles, etc. | Current ACT members are Emily Lang and Hayley Sanchez. |
8 | AD Umbrella AR | This is an AR that governs most data within the AD Knowledge Portal. | When users gain access to this AR, they are able to access most data within the AD Knowledge Portal (exceptions: AddNeuroMed data, Exceptional Longevity data) |
9 | Anonymous Access Tier | A category of Synapse data that is available for anyone on the web without requiring them to fulfill Conditions for Use. | This data must be made available for anonymous download by Sage Engineering. |
10 | Anonymous Journal Review | A process by which journal reviewers anonymously access manuscript data in Synapse in order to evaluate it for publication. | Please file a Governance Jira ticket using the "Request Anonymous Reviewer Accounts" component if you wish to generate anonymous accounts for a journal review. |
11 | Certified User | Synapse users that have registered for an account and completed the certification quiz. | Certified users have access to full Synapse functionality, including the ability to upload files and tables as well as create folders. To become certified, users must take a short quiz about the Synapse Commons Data Use Procedure. |
12 | Click-wrap | A type of AR that can be satisfied by a user by selecting "I accept the terms of use". | Click-wraps generally contain Terms and Conditions of data use and often contain an Acknowledgement Statement. |
13 | Conditions of Use | A set of expectations and/or terms for data access applied to Synapse content. | Conditions of Use typically are structured to comply with the terms under which the data were collected or with other human subjects regulations. Data Contributors collaborate with ACT to set up Conditions for Use. |
14 | Controlled Access Data Tier | A category of Synapse data that is available to registered, certified, or validated users that fulfill specific requirements for data access, such as submitting an Intended Data Use statement, obtaining IRB approval, agreeing to data use limitations, or other prerequisites. | Please file a Governance Jira ticket using the "Add, Edit, or Remove Synapse Access Requirement/Click-wrap" component if you wish to categorize your data in the Controlled Access Data Tier |
15 | Creative Commons Licensing | A Creative Commons license is one of several public copyright licenses that enable the free distribution of an otherwise copyrighted "work". | This is required for most data in the Open Access Data Tier. |
16 | Data Access Committee (DAC) | An individual or group that approves or rejects data access applications. | The ACT serves as the DAC at Sage. |
17 | Data Contributor | The individual or group that provides data to Synapse. | For Synapse communities, a DTA or other agreement is required before a Data Contributor can upload their data. |
18 | Data Requestors | All users listed on a data access request, including the request submitter. | The list of Data Requestors within a Data Access Application should exactly match the list of Data Requestors within the submitted DUC, if applicable for the specific AR. |
19 | Data Transfer Agreement (DTA) | An agreement that permits a Data Contributor to provide data to Synapse. | DTAs are required for institutions contributing data to a Synapse community, or for institutions that are having Sage manage data access for them. Note that a grant or other agreement such as a Data Use Agreement (DUA) can take the place of a DTA as long as it is signed by an institutional signing official and mentions that data will be stored in a repository. |
20 | Data Subject/Human Subject/Research Participant | GDPR Definition: Identified or identifiable living individual to whom personal data relates. | |
21 | Data Use Certificate (DUC) | DUC is a physical agreement that the data requestor needs to sign. The agreement outlines terms of use for accessing the dataset on Synapse, and it's usually signed by a Signing Official. | Managed ARs can be set up so that a DUC is required for data access. |
22 | Federated Query Governance Structure | Data are housed in a variety of locations, and users are able to query to those local data simultaneously. Typically restricted to pre-configured queries (rather than data exploration) and may require registration before use | |
23 | General Data Protection Regulation (GDPR) | Rules and privacy regulations governing European data | |
24 | Health Information Portability & Accountability Act (HIPAA) | US health information privacy regulations | |
25 | HIPAA Limited Data Set | Data that |
excludes all PHI (as defined by HIPPA) except for at least one of the following:
| HIPAA-limited data should always be categorized in the Controlled Access Data Tier | ||
26 | Informed Consent | An agreement that data subjects must sign before participating in a research study | Informed consents often help to establish Conditions for Data Use within Synapse |
27 | Intended Data Use Statement (IDU) | A description of the research purpose for using requested Synapse data. | IDUs can be required to access certain data via a Managed AR. They are often posted publicly on Synapse wiki pages. |
28 | Institutional Review Board (IRB) | A committee that applies research ethics by reviewing the methods proposed for research to ensure that they are ethical. | IRB approval can be required to access certain data via a Managed AR. |
29 | Managed Access Requirement | An Access Requirement that requires data access to be granted via a Data Access Committee (DAC). | ACT often implements Managed ARs on data categorized in the Controlled Access Tier |
30 | Model-to-Data Governance Structure | Data are held by a steward who is responsible for running algorithms on the behalf of researchers. In some cases, a synthetic version of the data may be released openly to facilitate model training. Researchers develop algorithms, send them to the steward, and receive back output of their analysis as run on the real dataset. The variety of analyses that may be performed is restricted by this structure, because the data steward must ensure data are specifically curated for any analytical question at hand | |
31 | Open Access Data Tier | A category of Synapse data available to all registered Synapse users without use limitations | Sensitive data should not be included in this category. |
32 | Open Source Governance Structure | Data are distributed for reuse with a license defining reuse rights and conditions. The creator is in charge of the negotiation at first (choice of license), but then rights to analyze and redistribute are permanently transferred to the user. | This governance structure is typical of a centralized project in the sciences, i.e., the Human Genome Project |
33 | Pairwise Governance Structure | Two parties agree to work together on and/or share a data set in some fashion, typically with a closed contract or an informal agreement. The negotiation terms depend on the relative status of the parties and/or the value of the data and knowledge. | |
34 | Private Access Tier | A category of Synapse data only available to the Data Contributor (i.e. Project Administrator) and other users that they specify in the entity's Sharing Settings. | Often, Private Data is managed via sharing through Synapse Teams. |
35 | Registered User | Synapse users that have successfully created an account and agreed to the Synapse Pledge. | Registered users can create projects and wikis. They can collaborate with other registered users and create Synapse teams. Registered users can also download publicly available data and, if they fulfill the Conditions for Use, they can also access controlled data. |
36 | Sensitive Data | Data that must be protected from unauthorized access to safeguard the privacy or security of an individual or organization. | “De-identified” data (maintained in a way that does not allow association with a specific person) is not considered sensitive. |
37 | Sharing Settings | A setting on the Synapse platform that enables a Project Administrator to define with whom a project or entity may be shared | Within Sharing Settings, Project Administrators can grant users view, download, edit, edit/delete, and administrator access |
38 | Signing Official | An employee affiliated with the respective organization who has oversight authority over the research study or data collaboration | A DUC or DTA may require an Instiutional Signing Offical's signature to validate the document. |
39 | Teams | Multiple Synapse users accepted into a group | Teams can be used to share Synapse entities to multiple users at once. Access Requirements can be implemented on Synapse teams or directly on Synapse entities |
40 | Validated User | Synapse users that have submitted identity attestation information to the ACT and have had their identities confirmed | Users are required to be validated in order to access certain data in the Controlled Access Data Tier (ex: mHealth data). |