Skip to content

Role-Specific Visibility Matrix

Legend

  • RW = Read / Write
  • R = Read only
  • A = Approve / Sign / Lock authority
  • = Hidden

1. Study (Run-time)

Study Section CRC PI Data Manager (DM) Monitor (CRA) Safety Officer
Dashboard R R R R R
Participants RW R R R R
Data Entry RW R
Assessments (jsPsych) RW (ops) R R R
eConsent (execution) RW A R R R
Visits / Schedule RW R R R
Queries & Safety RW (queries) R RW (queries) RW (queries) RW (safety)
Data Review R R RW R R
Reports & Exports R R RW R R
Audit Trail R R R R R

Key clarifications

  • CRC
  • Owns day-to-day execution: enrollment, entry, assessments, consent operations.
  • No data lock or export authority.
  • PI
  • Oversight and attestation role.
  • Explicit approval authority for consent and data lock.
  • DM
  • Quality owner: discrepancies, coding, freeze/lock, exports.
  • Monitor
  • Read-only data + active query management.
  • No direct data modification.
  • Safety Officer
  • Focused on AE/SAE; no routine data entry or review.

2. Configure (Authoring & Governance)

Configure Section CRC PI DM Monitor Safety
Study Design R RW
Assessments Designer R RW
eConsent Designer A RW R
Metadata Versions A RW
Data Standards R RW
└ Standards & Terminology R RW
└ Rules & Derivations R RW
└ Mappings R RW

Key clarifications

  • Only DM (and system admin) can author metadata.
  • PI approval is required for:
  • Metadata publication
  • Consent activation
  • Safety Officer may review consent language but cannot modify it.

3. Operations (Platform & Study Ops)

Operations Section CRC PI DM Monitor Safety
Sites R R RW R R
Users & Roles R RW
Integrations R RW
Settings RW
Help R R R R R

4. Special authority rules (important)

These are not just UI toggles — they should map to explicit backend permissions and audit events.

Electronic signatures

  • PI
  • Required for:
    • Consent approval
    • Metadata publication
    • Data lock
  • CRC
  • Can trigger consent workflows
  • Cannot finalize or approve

Data lock / freeze

  • DM → initiate freeze
  • PI → approve lock
  • CRC / Monitor → read-only once frozen

Assessments (jsPsych)

  • CRC
  • Resend / remind
  • Flag issues
  • DM
  • Review raw signals
  • Adjudicate anomalies
  • Monitor
  • Read-only compliance visibility
  • PI
  • Summary oversight only

Safety workflows

  • Safety Officer
  • SAE creation, review, submission
  • Access to narratives and expedited reporting
  • CRC
  • Initial AE entry
  • Monitor
  • Review safety completeness only

5. Sidebar rendering (what each role actually sees)

CRC sidebar

Dashboard
Participants
Data Entry
Assessments
eConsent
Visits / Schedule
Queries & Safety
Help

PI sidebar

Dashboard
Participants
Assessments
eConsent
Data Review
Reports & Exports
Study Design (read-only)
Help

Data Manager sidebar

Dashboard
Data Review
Queries & Safety
Assessments
Reports & Exports
Study Design
Assessments Designer
eConsent Designer
Metadata Versions
Data Standards
Sites
Users & Roles
Integrations
Settings
Help

Monitor (CRA) sidebar

Dashboard
Participants (read-only)
Assessments (read-only)
Visits / Schedule
Queries & Safety
Reports
Audit Trail
Help

Safety Officer sidebar

Dashboard
Safety
Participants (limited)
Reports
Audit Trail
Help

6. Design principle (why this works)

  • CRC UI = task-driven
  • PI UI = oversight + attestation
  • DM UI = governance + quality
  • Monitor UI = verification without mutation
  • Safety UI = isolated, defensible, inspection-ready

This structure will pass inspection conversations naturally because it mirrors how regulators already think about responsibility and authority.


If you want next steps, I would recommend one of:

  1. Translating this into a formal RBAC policy (YAML/JSON)
  2. Mapping each role to API scopes (especially for mobile assessments)
  3. Stress-testing against mid-study amendment + re-consent + data lock

Tell me which one you want to tackle next.