Role-Based Access in Clinical Platforms: A Plain-English Guide
Arjun Kapoor
April 03, 2026 · 5 min read
Role-based access is the unglamorous backbone of any serious clinical platform. Here is what each role should actually be able to do, and what it should not.
Most clinical platforms talk about 'role-based access' as a feature checkbox. In practice, it is the boundary between a tool that an IRB will sign off on and a tool that gets quietly banned after one near-miss. Get the roles wrong and everything else you build sits on sand.
The minimum viable model has three layers. Platform admins (rare, audited heavily) can do anything across all hospitals. Hospital admins manage everything within their hospital: users, studies, sharing rules. Researchers and coordinators can only see studies they own or that have been shared with them.
Two principles separate good access control from bad. First, defaults deny: a new user sees nothing until someone with authority grants access. Second, access is data, not code, so IT changing a role should not require a deploy.
Finally, every access change is an event worth logging. When the auditor asks why a particular researcher had visibility into a particular cohort in March, the answer should not require a forensic dig. It should be a query.
Run your studies on Unity
Unity is the clinical research platform built around how hospitals actually work: multi-tenant, role-based, and audit-safe by default.
Sign in to Platform