Requirements
Overview
Requirements represent a series of steps that researchers must complete before they can work with data. They also provide administrators with a mechanism to collect various information, attestations, and documentation 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 users, 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.
Creating requirements
Create a new requirement using the + New requirement button in the Requirements section of the administrator panel. All requirements must have a name that is unique within the organization.
Applicant type
Requirements are either fulfilled on behalf of a user or study. When creating a requirement, you must select the applicant type:
User: a requirement that can be fulfilled by each member in your organization. This is useful for collecting researcher-specific information, e.g., demographics, signed DUAs, and proof of data training.
Study: a requirement that can be fulfilled by each study in your 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 uses study requirements, all workflows that use that dataset must be assigned to an approved study.
Scope
Requirements apply either across all datasets or to specific datasets on a case-by-case basis. When creating a requirement, you must select the corresponding "scope":
Global: a requirement that applies to all datasets for which that requirement is assigned in your organization. For example, a researcher would only need to complete a HIPAA training requirement once, after which it would be checked off for all datasets that enforce the HIPAA training requirement.
Per dataset: a requirement that must be approved 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 configuring the requirement's scope as "per-dataset" , researchers must select specific datasets when submitting their requirement application; once approved, they will only have access to this subset of datasets.
The applicant type and scope of a requirement is permanent and cannot be changed. If you've created a requirement with the wrong configuration, consider duplicating the requirement (Settings > Duplicate), which will allow you to copy the requirement's contents while choosing a new configuration.
Editing the requirement form
Requirements can contain instructions as well as an associated form. Instructions provide additional context for users completing the requirement, and the form provides a mechanism to collect rich information from users as part of the access application process.
Form fields
Requirement forms are made up of individual fields. Fields can be marked as optional or required.
Each field is assigned a name, which is visible only to administrators and is referenced in administrative reports. The field also has a label, which will be shown to users, alongside corresponding inputs based on the field type:
Short answer
A short input field. Limited to 100 characters.
Paragraph answer
A long input field (text box). Limited to 2000 characters.
Date
A date input.
Multiple Choice / Dropdown
A user may select one and only one option. Will be displayed as radio buttons if there are 5 or fewer options; otherwise, will be displayed as a dropdown.
You may 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 choose to allow an "other" response to allow the user to create their own option.
File upload
A file upload, 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.
Viewing approvals
The Approvals tab displays all applicants and the status of their submissions (approved, expired, pending or rejected). Click on any item to view the approval, or download this content as a CSV file by clicking the three dot menu at the top-right.
Viewing responses
The Responses tab displays the individual responses for each field in the requirement, across all submissions. You can filter this list by field, field type, status, or user / study, depending on the type of requirement.
Click on any item to view the corresponding, or download this content as a CSV file by clicking the three dot menu at the top-right.
Settings
The Settings tab of the requirement page allows configuration of various settings, including:
Administrator notes
These notes are only visible to administrators. They can be used to provide context or instructions for administrators reviewing submissions.
Automation
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 a particular auto-approved requirement is revoked, all re-submissions of that requirement will need manual approval.
Expiration
By default, requirement submissions cannot be assigned a date of expiration – once approved, they will remain approved indefinitely, unless revoked by an administrator.
If expiration is turned on, all approvals of the requirement must include an expiration date. You can optionally choose a default expiration, calculated either from the requirement submission date or based on a date field in the requirement's form. Administrators can always override expiration defaults when approving the requirement.
Duplicate
Duplicate the contents of a requirement (but not any associated approvals). When duplicating a requirement, you can choose new options for the applicant type and scope.
Assigning requirements to datasets
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 updated
Was this helpful?