Comment on page
Requirements represent conceptual steps that a researchers must complete before they can work with data. They also provide administrators with a mechanism to collect various information, attestations, and documentation from researchers as part of the access application process. You can create, edit, and audit requirements on the Requirements section of the administrator panel.
Requirements provide researchers with a clear path to gain access to your organization's datasets, while providing administrators with the peace of mind that all researchers with access are abiding with the rules outlined by various data providers and use agreements.
Requirements are essential to managing access as your organization scales. They allow you to define access rules based on processes, rather than relationships. For smaller organizations or datasets with a limited number of investigators, you may prefer to utilize the direct access paradigm for granting access.
A member requirement is fulfilled by a member once in their relationship with the organization. This is useful for collecting researcher-specific information, e.g., demographics, signed DUAs, and proof of data training.
A study requirement is fulfilled by a study once in its relationship with the organization. Studies represent a group of collaborators working on a common investigative effort. Study requirements are useful for collecting information that is relevant within the scope of a study, e.g., IRB approval, grant funding status.
Create a new requirement using the + New button in the Requirements tab of the administrator panel. All requirements must have a name that is unique within the organization.
The grey box at the top of the requirement page allows configuration of the following settings, specifying manual or automatic approval, expiration defaults, and organization-wide or per-dataset scope.
By default, all requirement submissions will be marked as "pending" until an administrator from your organization approves (or rejects) the submission.
You can also configure all submissions of a requirement to be automatically approved. This is helpful when you want to collect optional, user-provided information that doesn't need to be audited before users access data. Note that if an auto-approved requirement is revoked, all future submission will require manual approval.
By default, requirement submissions cannot be assigned a date of expiration – once approved, they will remain approved indefinitely, unless revoked by an administrator.
When turned on, all approvals of this requirement must include an expiration date. You can optionally choose a default expiration, calculated either from the requirement submission date or based on a field in the requirement's form. Administrators can override any expiration defaults when approving the requirement.
By default, requirements apply to all datasets for which that requirement is assigned in your organization. For example, a researcher would only need to complete their HIPAA training once.
However, in some cases you may want to approve a requirement in the context of specific datasets. For example, you may have a requirement mandating IRB approval for many of the organization's datasets, though particular IRBs will likely only apply to a subset of those datasets. By turning this option on, researchers must select specific datasets when submitting their requirement application; once approved, they will only have access to this subset.
Per-dataset requirements allow requirements to apply to a subset of specified datasets
Requirements may also have instructions and/or a form associated with them. Instructions provide additional context at the top of the requirement submission modal, and form provides an interface to collect information for users, in the formats specified below.
Last modified 4d ago