Skip to content
ARION
Audit, RBAC & signatures

Thirteen roles, one audit trail, a lock workflow built for change control

Organization- and center-scoped role definitions enforced identically in the API and the UI, append-only audit entries with before/after values, and password-confirmed PI signatures.

Request a demo
How it works

Access scoped to what a role actually needs

Study design, patient data, queries and SDV, reports, and PI signature are each gated independently — and center-scoped roles never see beyond their assigned center.

Role-based access, by capability areaA matrix of six representative roles (of thirteen total) against five capability areas, showing which roles can access study design, patient data, queries and SDV, reports and export, and PI signature. Site PI and Site coordinator are marked as center-scoped -- limited to their single assigned center.Study designPatient dataQueries & SDVReports/exportPI signaturePlatform adminStudy builderData managerCRA / monitorSite PISite coordinatorcenter-scoped6 of 13 seeded roles shown, each org- and center-scoped identically in the API and the UI.

The same permission map drives both the API authorization checks and what the UI shows.

One permission map, two enforcement points

Permissions are derived entirely from the role definition — no per-route role-name checks to drift out of sync between backend and frontend.

Append-only audit trail

Every study and study-value mutation is tracked with actor, timestamp and before/after JSON — organization membership changes included.

Password-confirmed PI signature

When a study requires PI eligibility confirmation, enrolment requires a password-confirmed signature interaction, not a checkbox.

See it on your protocol

Bring a protocol or an existing study and we'll show you what this looks like in Arion.

Request a demo