Requirements
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.
When users submit requirements, these submissions will show up on the member and study sections of the administrator panel.
Learn more about responding to access requests.
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.
If a dataset contains study requirements, all projects that use that dataset must be assigned to the approved study.
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.
Automatic approval
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.
Require expiration
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.
Per-dataset specification
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.
Type | Description |
Short input | A short input field. Limited to 100 characters. |
Long input | A long input field (text box). Limited to 2000 characters. |
Date input | A date input. Must be in the form YYYY-MM-DD |
Radio / Dropdown | A user may select one and only one option. Will render as a dropdown if there are more than three options. You may also choose to allow an "other" response to allow the user to create their own option. |
Checkbox | A user may select any number of options. You may also choose to allow an "other"response to allow the user to create their own option. |
File upload | A file upload input, allowing the user to upload any number of files (up to 50MB) from their computer. |
PDF read & accept | Provides the ability to upload a file that requires a user's signature as acknowledgement. This field can be configured to expect either an e-signature or an uploaded, signed document. |
Requirements are applied to datasets by assigning them to different access levels on a permission group. In order for a user to access data at a particular level, they must be approved for all requirements up to and including that level.
Users will then see (and be able to submit) requirements when they apply for access to your organization's datasets.
Last modified 5d ago