Requirements
Requirements represent conceptual rules that a researchers must fulfill 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 forward 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.
All requirements are either fulfilled on behalf of a member or study. When creating a requirement, you must select the requirement type — this selection is permanent and cannot be changed in the future.
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.
Requirements are created and managed within the requirements tab of the administrator panel. All requirements must have a name that is unique within the organization.
Requirements can also have optional instructions and/or a form associated with them. The form provides an interface to collect both structured and unstructured user input, as well as signatures and uploaded files.
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 |
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. |
Signature | 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. |
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. If an auto-approved requirement is revoked, future submission will require approval.
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.
When turned off, administrators will not be able to assign an expiration to requirements — once approved, they will remain approved until revoked by an administrator.
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 the specific datasets that their requirement application applies to; once approved, they will only have access to this subset.
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 that level.
Users will then see (and be able to submit) requirements when they apply for access to your organization's datasets.
