Skip to content
How-toAdministratorQA & inspection

Give an inspector access

A regulatory inspector or a sponsor auditor needs access to the data and the audit trail — but strictly view-only and for a limited time. There is no special “inspector mode”: an inspector is an ordinary account with the ready-made Auditor (read-only) role assigned with an end date.

Administrator — the access administrator or whoever runs the study team: you need the right to grant access (access.grant) on the study, and principal.manage to create a new account. QA & inspection usually agrees the period and scope with the inspection.

The task comes up before a regulatory inspection or a sponsor audit — as soon as the dates are known.

  • The inspection dates are known: access must expire on its own, without reminders to the administrator.
  • The scope is known: the whole study or a specific site.
  • The Auditor (read-only) role exists in Admin → Roles (it ships with the platform; you can check its contents there).
  • If the inspection needs copies of materials, agree in advance who will assemble the inspection packet — the inspector does not export files.
  1. Open the study → Team and click Add to team.

  2. Pick the person. If there is no account yet — Invite new (or create it in Admin → Users, or connect it via SSO).

  3. Choose the Auditor (read-only) role and the scope: Whole study or the site needed.

  4. Set Valid until — the end date of the inspection. This is the key step: without it the access stays open-ended.

  5. Click Add.

0:000:00
The main thing for an inspector: reading the audit trail and verifying the hash chain on their own

The period is changed only by a new assignment, not by editing the old one: grant history is immutable and cannot be extended retroactively. Assign the role again with a new Valid until date.

  • The inspector sees the study data, value history, queries, signatures, SDV and lock statuses, the audit trail — and can verify chain integrity on their own. They have no write actions at all.
  • The assignment is recorded in the audit trail; all of the inspector’s actions are audited like any user’s.
  • When the period ends, access stops on its own: the next request simply fails the permission check.
  • No Add to team button — you do not hold access.grant on the study.
  • “The user list is unavailable” — the organization-level “Read access” permission (access.read) is required; or invite a new person.
  • No Auditor (read-only) role — it was renamed or deleted; create a role from the “inspector” template (Manage team access).
  • The inspector does not see a site — the role is assigned on another site; assign it on the right one or on the whole study.
  • The inspector asks for a file or unblinded values — the role lacks export.run and data.unblinded.read on purpose; see “If an inspection needs unblinding or an export” below.

The role ships with the platform — there is nothing to assemble from permissions. It suits a sponsor auditor and a regulatory inspector alike: viewing data and value history, queries, signatures, SDV and lock statuses, the audit trail, and verifying its integrity on their own. It has no permission to change anything, export study data or unblind. The same access rules apply as for everyone: default deny and “deny always wins”.

Navigation is the same as for an ordinary user, but without a single write action.

  • Study data — subject casebooks, forms, values — read-only.
  • The history of every value — all versions of a field: what it was, what it became, who changed it and when, with the stated reason for change (RfC).
  • Audit trail — the full chain of events with filters by period, user and action; each event shows before/after and its causal link.
  • Self-service integrity check — the Verify trail integrity button recomputes the cryptographic audit chain and gives the verdict Chain intact or Chain broken with the number of the first broken record. The check is a direct answer to the inspection’s key question “how do you prove the audit trail was not edited?”: the inspector does not have to take it on trust. A break found is a critical incident, and the system never quietly “fixes” it.

A typical subject review: the auditor opens the subject, reads its casebook and the audit tab — the history of every value with the reasons for change. They see SDV, signature and lock statuses on the same screens as the team, in view mode. They have no files or printed copies (152-FZ — minimizing copies of personal data): copies for the inspection are issued by the data manager as an inspection packet (the Inspection packet tab in the study’s Exports; the packet is always blinded and verifiable offline).

The restrictions are not interface cosmetics: the inspector simply has not been given the corresponding permissions. Even bypassing the interface directly ends in a server refusal.

Action Why it is unavailable
Any edit to data, statuses, queries no permission to change — view-only access
Generating documents (exporting files) no export.run permission; no buttons, a direct call is refused
Unblinding no data.unblinded.read permission; blinded values are masked (•••) everywhere, incl. audit
Extending their own access the period is changed only by a new grant, never retroactively