Skip to end of banner
Go to start of banner

Governance Glossary

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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.
HIPAA Definition: The living individual about whom an investigator conducting research obtains information or biospecimens through intervention or interaction with the individual, and uses, studies, or analyzes the information or biospecimens; or obtains, uses, studies, analyzes, or generates identifiable private information or identifiable biospecimens.

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:

  • dates such as admission, discharge, service, DOB, DOD;

  • city, state, five digit or more zip code; and

  • ages in years, months or days or hours.

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

  • No labels