Authentication, roles and access

Review status

Proposed Core. This page defines the shared access model that EDC and eTMF use. The products still decide what their features and clinical actions mean.

The operational questions

Platform must let an access administrator answer five different questions without confusing them:

Who is trying to act? — the authenticated human or connected system.
Which product feature is involved? — for example, EDC queries or eTMF quality control.
What action are they requesting? — view, create, change, remove, sign, close, approve, lock, finalize, export, or another named product action.
Where may they act? — the workspace, one study, country, site, or another product-defined area.
Are there additional restrictions? — effective dates, blinding, privacy, separation of duties, product state, or a record-specific rule.

A job title, study-team responsibility, training record, or organization type may be a prerequisite, but none of them grants product access by itself.

Shared access model

Person Profile, when needed for business responsibility
          │
          └── may be linked to ── Principal ── Authentication Binding
                                      │
                                      └── Access Assignment
                                             ├── exact Role Revision
                                             ├── Product
                                             ├── Study/Country/Site area
                                             └── effective period

Product Feature Catalogue
└── Feature
    └── permitted actions
           │
           └── selected by Role Revision

Principal + active assignment + role actions + requested area + restrictions
→ Access Decision: Allowed or Denied with a specific reason

Authentication records

Authentication establishes the acting identity. Authorization decides what that identity may do.

Record	What it means	Key information	Familiar actions
Principal	Stable identity that may act in the suite	human, service, or product connection; display identity; invited/active/disabled	invite, activate, disable, restore
Authentication Provider	Approved sign-in authority for a workspace	provider identity, accepted issuer, assurance rules, effective period, status	register, revise, suspend, retire
Authentication Binding	Link between one Principal and one external sign-in identity	provider, external subject, verified time, state, last confirmation	bind, verify, revoke, replace
Authenticator Enrollment	Evidence that an accepted authentication method is enrolled	method class, enrollment state, assurance level, verified and revoked times	enroll, verify, revoke
Authentication Policy	Workspace requirements for sign-in and sensitive actions	accepted providers, assurance, reauthentication, recovery and session rules	approve revision, make effective, retire
Authentication Session	Time-bounded authenticated use	Principal, provider/binding, assurance achieved, issued/expiry time, termination	start, refresh under policy, terminate
Authentication Attempt	Evidence of a successful or failed sign-in/recovery attempt	claimed identity, provider, time, outcome, reason, risk response	review; never edit outcome
Recovery Decision	Controlled account-recovery conclusion	requester, verified evidence, reviewers, result, conditions, expiry	request, approve, reject, complete

Authentication rules that must always hold

A human Principal represents one accountable person; shared human identities are not permitted.
Disabling a Principal stops new authenticated use but preserves historical attribution.
Replacing a sign-in binding does not create a new person or rewrite earlier actions.
A service or connection Principal never impersonates a human. If work was initiated by a person, both the initiating person and executing system remain visible.
Sensitive actions may require recent reauthentication or higher assurance without changing the Role.
Authentication success never implies permission to use EDC, eTMF, a study, or a site.
Recovery, provider change, authenticator change, and Principal restoration are retained access events.

Product feature and action catalogue

Each product publishes the features it protects. Platform maintains the approved catalogue and prevents Roles from referring to unknown or retired action meanings.

Product Feature

Information	Meaning
Stable feature key	Never reused, for example `edc.query` or `etmf.quality-review`
Product	Platform, EDC, or eTMF
Clinical name and explanation	Wording an access administrator understands
Protected record types	Records whose visibility or actions are controlled
Permitted area types	Workspace, Study, Study Country, Study Site, or a declared product area
Visibility classifications	Blinded/unblinded, privacy, inspection, archive, or other applicable restrictions
Current catalogue version	Exact definitions against which a Role was reviewed
Status	Draft, Published, Retired for new Roles; historical use remains resolvable

Base maintenance actions

Every feature declares which of these actions actually make sense:

In conventional CRUD language, View = Read, Create = Write a new record, Change = Update, and Remove = Delete where deletion is clinically and regulatorily permitted.

Action	Product meaning
View	See the permitted record, its place in lists, and permitted fields
Create	Establish a new record of that type
Change	Correct or progress the permitted parts of an existing record
Remove	Remove an unused draft or mistaken uncommitted item only where the product explicitly permits it

“Remove” is not a universal hard delete. Regulated or historically used records are normally cancelled, retired, withdrawn, superseded, or marked as entered in error through named actions.

Named clinical and controlled actions

CRUD-style maintenance is not precise enough for high-impact work. Products therefore publish separate actions such as:

approve and publish a study design;
answer or close a data query;
perform source data verification (SDV);
sign subject data;
freeze, lock, reopen, or database-lock EDC data;
approve a Filing Plan Revision;
pass a quality-control round;
finalize and file a TMF Document Version;
provide inspection access; and
approve archive destruction.

A Role allowed to “Change TMF Document” cannot infer permission to finalize it. A Role allowed to “Change Casebook” cannot infer permission to sign or lock it.

Role Definition and Role Revision

A Role is a named bundle of product actions. It is not a job title and does not itself identify a user.

Information	Meaning
Role identity	Stable reference, such as “EDC Site Data Entry”
Home product	Exactly one of Platform, EDC, or eTMF
Clinical description	What work the Role is intended to support
Role Revision	Immutable version containing the exact feature/action selections
Allowed access areas	Area types compatible with all selected actions
Constraints	Separation of duties, prerequisite responsibility, blinding or other declared rules
Effective and retired status	Whether new assignments may use the Role

Role maintenance

Action	When allowed	Result and retained evidence
Define Role	Product actions exist and area types are compatible	Role Revision 1 with author, reviewer and exact action list
Revise Role	Impact on current assignments has been reviewed	New immutable revision; previous revision remains visible
Retire Role	Replacement and access-continuity impact are known	No new assignments; historical decisions remain reconstructable
Copy Role	Source revision is identified	New Role identity; later changes do not affect the source
Compare revisions	Always for permitted administrators/auditors	Added/removed actions, affected assignments and effective policy

An organization may use approved Role templates, but copying a template creates an organization-owned Role that must be reviewed when the product action catalogue changes.

Access Assignment

An Access Assignment gives one Principal one Role within one product and access area for an effective period.

Information	Meaning
Principal and product	Who receives access and in which product
Role	Stable Role identity and the revision policy applied
Access area	Workspace, Study, Study Country, Study Site, or supported product area
Effective period	Scheduled start and end; access is not silently permanent
Reason and request source	Why access was granted
Granted by	Administrator and the assignment/delegation permitting the grant
Prerequisites	Required business responsibility, training or approval, when product policy declares it
State	Scheduled, Active, Ended, Revoked, or Expired
Review history	Periodic confirmations, changes, and reviewer conclusions

Changing the Principal, Role, product, or access area creates a new Assignment. Ending an Assignment does not erase the earlier permission or the actions taken while it was active.

Delegated access administration

Platform may allow a sponsor administrator to delegate EDC or eTMF access maintenance to another qualified administrator.

The delegation states:

which product may be administered;
the broadest Study/Country/Site area;
which Roles or actions may be assigned;
start and expiry times;
whether further delegation is prohibited;
separation-of-duty restrictions; and
the accountable grantor.

A delegated administrator cannot grant an action or access area broader than their delegation. The system must also prevent removal of the final qualified access administrator unless an approved emergency path exists.

How visibility and actions are decided

For every request, Platform evaluates identity and permissions before the product evaluates its clinical rules.

Authenticated Principal is active
AND Authentication Session meets the action's assurance requirement
AND Product is available for the workspace/study when required
AND an effective Access Assignment covers the requested product and area
AND its Role Revision contains the exact Feature Action
AND blinding, privacy and separation-of-duty restrictions pass
→ Platform permission result is Allowed

Then EDC or eTMF evaluates whether the requested clinical action is valid now.

Examples:

A data manager may be permitted to close a query, but EDC refuses because it is already cancelled.
A TMF reviewer may be permitted to perform QC, but eTMF refuses because the reviewer submitted the document and independent review is required.
An investigator may have the business responsibility of Principal Investigator but cannot sign until an EDC Role with the signing action is assigned.

Visibility is applied before search and totals

Permission must be applied before filtering, sorting, counting, pagination, worklist generation, or export. A user must not learn that a restricted subject, unblinded record, site, or inspection package exists from totals, search suggestions, error messages, or identifiers.

The decision distinguishes:

feature visibility;
record visibility within the assigned access area;
field or content visibility based on product classifications;
permission to perform the requested action; and
permission to export or inspect audit history, which are separate actions.

Access Decision and audit evidence

Each material permission decision retains:

Principal and authenticated session/assurance;
product, feature, exact requested action and access area;
allowed or denied outcome and understandable reason;
Role Revision and Access Assignments evaluated;
catalogue and policy versions;
blinding/privacy/separation checks applied;
evaluation time; and
product action attempted and its later accepted/refused outcome where applicable.

Routine page rendering may retain decision evidence according to a proportional policy; every access grant, change, revocation, sensitive denial, signature, approval, lock, inspection, archive, export, and administrator action must remain attributable and reviewable.

Platform Role templates

These are reviewable starting templates, not universal job titles.

Template	Typical permitted work	Explicitly excluded
Workspace Security Administrator	authentication providers/policies, Principal disable/restore, security review	EDC/eTMF clinical actions unless separately assigned
Identity Administrator	invite Principals, manage authentication bindings, resolve identity issues	define product Roles or grant clinical access
Product Access Administrator	define/revise product Roles and assign them within delegated areas	exceed delegation; perform product actions automatically
Access Reviewer	inspect assignments and complete periodic access reviews	grant access unless separately assigned
Platform Auditor	read access history and approved evidence exports	change identity, Role or Assignment records
Connection Administrator	register and suspend connected-system identities	act as a human or inherit human product permissions

Rules that must always hold

Roles contain exact feature actions, not free-text permission names.
A Role belongs to one product. Cross-product access requires separate assignments.
Role revisions are immutable; changing permissions creates another revision.
Every current permission can be traced to an effective Assignment and the administrator who granted it.
Access area containment is explicit; Study access does not imply Workspace administration.
View, export, inspect audit history, sign, approve, finalize and lock are separate permissions.
Remove is permitted only where the owning product defines a safe removal action.
Business responsibility and application access remain separate.
Authentication and authorization remain separate.
A permission result cannot override an EDC/eTMF clinical rule, lock, finality rule, or separation-of-duty rule.
Role retirement or Assignment revocation never destroys historical access evidence.
A product action-catalogue change identifies affected Roles for review; it never silently expands access.

Verification scenarios

A role gains a new action

The EDC product publishes a new “Approve database reopen” action. Existing Data Manager Roles do not receive it automatically. An access administrator reviews the change, publishes a new Role Revision, and decides which Assignments follow it. Earlier access decisions still resolve to the prior revision.

Site user searches outside their site

A site coordinator has EDC data-entry access only for Site 101. Search, totals, subject lists, query counts and exports are restricted to Site 101 before any result is calculated. Site 102 is not hinted at.

Blinded TMF reviewer encounters unblinded content

The reviewer can use the eTMF quality feature for the Study, but the Document is classified unblinded. The record is excluded from ordinary worklists. A separate unblinded assignment is required; a direct URL does not bypass the restriction.

Assignment expires during an open session

The user authenticated successfully before expiry. A later sensitive action is denied because access is evaluated at action time. The session may remain authenticated while product authorization ends.

Role permits change but product refuses it

An eTMF document specialist has permission to change metadata. The Document Version is in an active inspection disclosure set. eTMF requires the governed correction path and refuses an ordinary edit. The access decision and clinical refusal are retained separately.