When to apply When a project record needs to carry — and gate downstream actions on — IRB/REC, IACUC, biosafety, GDPR, MTA, or export-control determinations as structured, queryable metadata.
Before you start
Prerequisites
What needs to be in place before you operationalise Compliance and regulatory terminology in your CRIS or repository.
- An authoritative source for ethics and biosafety determinations (IRB office system, IACUC tracker, biosafety committee minutes)
- A controlled vocabulary for determination outcomes (approved, exempt, not human-subjects, conditional, withdrawn, expired)
- Mapping from each determination to the workflow steps it gates (data collection, recruitment, publication, sharing)
- A data-protection officer or equivalent who can sign off on the GDPR / HIPAA / equivalent classification of the project
- Clarity on retention requirements — most compliance fields have multi-year statutory retention that outlives the project
Deployment
Five steps to deploy
Each step is small enough to land in a single sprint or a single sitting with the relevant CRIS administrator. Follow in order.
Inventory the determinations you actually need to capture
List every approval body whose decision changes what a project may legally do. Typical baseline: IRB/REC, IACUC for animal work, IBC for biosafety, DPIA / IRB for GDPR Special Category data, export-control review for EAR/ITAR, MTA inbound/outbound.
Define a compliance record schema
Each determination gets: body, jurisdiction, reference_number, decision, decision_date, expiry_date, conditions_free_text, linked_protocol_id, linked_project_id. Keep "decision" closed-list — never freeform.
Wire bidirectional links to projects, datasets, and outputs
A determination must be reachable from the artefacts it permits, and an artefact must surface every active determination that authorises it. Enforce at the schema level — do not rely on librarians remembering.
Add expiry and renewal monitoring
Most approvals expire. Add a scheduled report (DSpace cron, Pure scheduled task, custom CRIS job) that flags determinations expiring inside 60 days and locks downstream actions when they pass expiry.
Test with a real multi-determination project
Pick a clinical study with IRB + IBC + GDPR DPIA + an inbound MTA. Verify every artefact (protocol, consent form, dataset, manuscript) traces back to the right four determinations, and that revoking one cascades the right warnings without breaking the record.
Worked example
Sample workflow
A realistic walk-through of a single record passing through the Compliance and regulatory pipeline once the checklist is in production.
Integration points
CRIS and repository systems
Vendor-specific notes on where this vocabulary fits in real research-information systems. Names appear here only where there is public field evidence — they are not vendor partnerships.
Use the Ethical review module and the Application/Award compliance fields. Pure can store determination numbers and expiry dates but does not natively enforce expiry gating — bolt on via Pure API or scheduled report.
Add a Compliance entity via the Elements configuration; link to Grant and Publication entities through the standard relationship model.
Native Ethics module covers IRB/REC and animal-work approvals; export-control gating typically needs a custom checklist.
The Ethics & Approvals module supports multi-body determinations; integrate with the project lifecycle gates so milestones cannot pass without an in-date approval.
Compliance is not native; model determinations as a custom entity type via configurable-entities, then add metadata field validation on dataset and publication deposit.
What goes wrong in the field
Common pitfalls
The patterns that show up repeatedly when this checklist is skipped or misapplied. Address these before they become entrenched.
- Storing IRB numbers as freeform text on the project record instead of as their own determination entity
- Letting determination decisions drift into freeform language ("approved with comments" versus "conditional") and losing closed-list discipline
- Failing to set expiry-driven workflow gates, so artefacts get deposited under approvals that lapsed two years ago
- Mixing GDPR lawful-basis with consent-status — they are independent fields and both matter
- Treating MTAs as legal paperwork rather than as determinations that constrain downstream dataset reuse
Frequently asked
Implementation FAQ
- Who maintains this checklist?
- The Compliance and regulatory working group maintains the checklist alongside the dictionary terms in the same domain. It is reviewed each release cycle (March and September) and updated when a working-group consultation, a vendor product change, or a federation-partner schema update materially changes the operational guidance.
- What if my CRIS or repository is not listed?
- The integration points listed name the systems CASRAI has direct field experience with — Pure, Symplectic Elements, Worktribe, Converis, DSpace and DSpace-CRIS, EPrints, VIVO, Dataverse, Invenio-RDM. The CERIF mapping in the checklist is vendor-neutral and applies equally to other CRIS or repository products. If your system supports the underlying entities (Person, Project, Output, Funding, plus the domain-specific extensions), the steps transfer.
- How do I validate my implementation?
- Three validation surfaces. First, the deposit form should refuse a record missing required fields rather than warn and accept. Second, the resulting metadata should round-trip through the federation layer your institution uses (OpenAIRE Guidelines 4.0 for European federation, DataCite Commons for DOI-anchored discovery, Crossref for article-anchored discovery) without upstream errors. Third, walk a real-world record through the sample-workflow path on this page and confirm the structured fields capture what the prose describes.
- Where do I report errors in the checklist?
- Open a comment via the dictionary-feedback flow at /dictionary/contribute. Editorial corrections — wrong vendor module names, deprecated standards, broken integration paths — are queued into the next release cycle. Substantive disagreements on the operational guidance are routed to the working group for review and may motivate a checklist revision.
- Is this checklist enough to certify my implementation?
- No. The checklist gives you the operational baseline; certification against federation profiles (CoreTrustSeal, OpenAIRE-compliant, COAR-aligned) is a separate process with its own audit. Treat the checklist as the engineering scaffolding and the certification as the institutional sign-off that the scaffolding is being used.
