Why Decision Rights Need to Be Explicit
A platform trial creates decisions at more than one level. A proposed eligibility change might affect one treatment arm or every arm. A site might need a temporary operational pause before a routine review can occur. A simulation-based recommendation might inform a design decision without itself authorizing a change. If people involved cannot tell who recommends, who approves, and who executes, the same decision can be delayed, duplicated, or put into effect without proper authorization.
A decision-rights matrix is a practical way to clarify those boundaries. It does not determine which scientific choice is correct, replace a protocol, or create authority that an organization does not otherwise possess. It records a planned delegation: for a defined decision, which role develops or recommends an option, which role authorizes it, and which role carries it out. This complements the distinctions between platform-wide and arm-specific documents established in the earlier material on master protocols and arm-specific protocols.
Three Authority Stages and Three Scopes
The three authority stages should be treated as distinct functions, even when one role performs more than one of them. Recommendation means assessing information and proposing an action to the approving authority; it does not authorize implementation. Approval means authorizing a specified action within the approver’s delegated remit; it does not automatically mean that the approver carries out the action. Execution means implementing an approved action, or carrying out a separately preauthorized action, in the manner and timeframe specified.
For mapping purposes, classify decisions by their scope. Scientific decisions concern the trial’s scientific design or interpretation, such as a proposed change to an analysis method. Operational decisions concern conduct within an approved design, such as scheduling a review or coordinating an already authorized site procedure. Platform-wide decisions affect shared rules, documents, or processes across multiple arms or the platform as a whole. Some decisions have more than one consequence. A change proposed for one arm, for example, may also affect shared control or platform-wide interpretation. The matrix should flag such cross-scope decisions for the required additional review, rather than forcing them into a single category.
A basic matrix can use one row per decision type and separate columns for scope, recommendation, approval, and execution. Use roles rather than individuals’ names so the assignment survives staff turnover. The role descriptions and delegation documents should make the named roles identifiable in practice. If a stage is not applicable, say so and explain why; an empty cell is ambiguous.
| Decision type | Scope | Recommend | Approve | Execute |
|---|---|---|---|---|
| Change to an arm-specific analysis specification | Scientific; arm-specific | Designated scientific review role | Role authorized under the applicable protocol and delegation | Authorized document-control and analysis personnel |
| Routine scheduling within approved procedures | Operational | Trial operations role | Delegated operational role, if approval is required | Site or coordinating staff assigned to the task |
| Change to a shared platform process | Platform-wide | Roles responsible for affected functions | Platform-level authority specified by the governing documents | Assigned platform implementation role |
The entries above are illustrative, not a universal allocation of authority. A matrix is useful only when its role labels match the trial’s actual governing arrangements. In particular, a recommendation from a scientific role should not be treated as approval simply because that role has expertise; execution staff should not infer approval from a request to prepare a change.
Building a Matrix That Can Be Used
Begin by listing decision types at a level that permits a clear assignment. “Scientific decisions” is too broad: a proposed analysis change, a result interpretation, and a design modification may require different paths. At the other extreme, a separate row for every minor task makes the map difficult to maintain. A useful row identifies a decision that has a distinct approving authority, trigger, or implementation route.
State the action in concrete terms, including what may change and what must remain unchanged. Identify whether the decision is scientific, operational, platform-wide, or cross-scope.
Name the role responsible for evaluating the relevant evidence and putting forward an option. Specify who must be consulted when other functions or arms are affected.
Name the role that can authorize the action under the governing documents. State any limits, such as a need for additional approval when a change affects shared procedures.
Name the role that implements the decision, the record that documents approval, and how completion or implementation failure is reported back.
This sequence follows from the functions being assigned: an action cannot be implemented as an approved change until an authorized approval exists, while a recommendation supplies the basis for that approval but does not substitute for it. A separate execution assignment then identifies who is accountable for putting the decision into effect. Keeping the stages distinct exposes missing authority: if a row has a recommender and an executor but no approver, it is unclear who may authorize the action; if it has an approver but no executor, authorization may never become an operational change.
Worked Example: A Proposed Change to One Arm’s Analysis
In a hypothetical platform, one treatment arm has 180 enrolled participants. The analysis team proposes changing the arm-specific method for handling a particular endpoint. The change would not alter the shared control or the analyses for other arms. The governing documents require the change to be authorized before the analysis specification is updated.
Classify the decision. It is scientific because it changes an analysis method, and arm-specific because the stated effects are confined to one arm. The 180 participants describe the setting; they do not decide who holds authority.
Map the stages. The designated scientific review role assesses the rationale and recommends whether to proceed. The role authorized by the applicable protocol or delegation approves or declines the change. The assigned document-control role updates the specification only after approval, and the analysis team uses the version identified as current.
Check the boundary. If review shows that the change would also affect shared control interpretation, the decision is no longer confined to the arm. The map must route that cross-scope consequence to the relevant platform-level approval path before implementation. A recommendation to revise the method is not itself permission to revise it.
Urgency, Delegation, and the Record
Some operational situations require prompt action, but urgency does not erase the distinction between immediate protective action and approval of a lasting change. A governance map should describe any actions that a role is already authorized to take under a protocol or procedure, who must be notified, and who reviews the situation afterward. It should separately identify who can approve a continuing change to the trial. Do not use a general phrase such as “the operations team may act as needed” where the boundaries of that authority matter.
Delegation also needs a defined route when the designated approver is unavailable or has a conflict. A sound map names an authorized alternate or an escalation route, not an informal substitute chosen at the moment. If no alternate can lawfully or procedurally act, the map should say that the decision waits or follows another established process. It should not imply that a recommendation becomes approval by default.
For each consequential decision, the record should let a reviewer reconstruct the chain: what was proposed, by whom, on what basis, who approved or declined it, and who implemented it. The record should also identify the effective date or version where relevant and note any required notifications. This is not a demand for unnecessary paperwork for every routine task; it is a way to make authority and implementation auditable in proportion to the decision’s consequences.
Worked Example: A Temporary Operational Pause
In a hypothetical trial, a procedure states that a site must pause a specified enrollment activity if a safety-monitoring value exceeds 12 units. At one site, the recorded value is 13.4 units. Assume the procedure explicitly authorizes the site lead to pause that activity when the threshold is exceeded and requires prompt notification of the designated review role.
Apply the stated rule. Since \(13.4 > 12\), the condition for the preauthorized pause is met. The site lead executes the temporary pause under the procedure; this is not a discretionary approval of a permanent protocol change.
Route the follow-up. The designated review role evaluates the information and recommends whether the pause should continue or whether another action is warranted. Any lasting change is approved only by the role with authority for that change. The site documents the measured value, the time of the pause, the notification, and the subsequent authorized direction.
The conclusion depends on the hypothetical procedure explicitly granting this limited authority. Without that preauthorization, the numeric threshold alone would not establish who may act. A matrix should reflect the actual rule rather than infer authority from the urgency of the situation.
Comparing Decision Maps and Finding Failure Modes
A decision-rights matrix is more specific than a simple list of participants and responsibilities. A responsibility list can show who contributes, but may not distinguish a person who advises from one who can authorize a change. A generic responsibility-assignment chart can be adapted to include these distinctions, but the labels must be defined and the approval path must be explicit. The matrix is also not a substitute for a committee structure or a governance charter: it records the allocation of authority for decision types, while other documents may establish membership, operating procedures, or broader mandates.
Several signs indicate that a map needs revision or clarification:
- Approval is missing. A row names who proposes and implements an action but not who authorizes it.
- Recommendation is treated as a decision. Meeting notes or email describe a proposal as approved even though the named approver has not acted.
- Two roles appear to have final authority. The row does not specify whether both approvals are required, whether one is primary, or how disagreement is escalated.
- Scope is understated. A change described as arm-specific alters a shared process or affects another arm, but no cross-scope route is specified.
- Execution precedes authorization. Staff implement a proposed change before the required approval or document update is complete.
- The named role is not operationally identifiable. Staff cannot determine who currently holds the role, who serves as an alternate, or where a decision must be sent.
A matrix also has limits. It cannot settle a scientific disagreement merely by assigning an approver, guarantee that a decision is well informed, or replace required review and documentation. It may become outdated when the protocol, platform structure, or delegation changes. Periodic review and change control help keep its assignments aligned with current governing documents; apparent conflicts should be resolved through the documented escalation route rather than an improvised reassignment.
Worked Example: A Shared Review Schedule
A hypothetical platform has four active treatment arms and one shared review process. A proposed scheduling change would move the review from every 6 weeks to every 4 weeks for all arms. The operations group estimates that the change requires 2 additional staff-hours per week. The figures describe the operational impact but do not determine the authority assignment.
Classify the decision. Although scheduling is operational, the proposed change applies to all four arms and therefore has platform-wide scope. The matrix should not route it as an ordinary local scheduling adjustment.
Assign the stages. The operational role assesses feasibility and recommends a schedule. The designated platform-level authority approves or declines the shared change under the governing documents. The assigned coordination role then updates the schedule and communicates the effective date to affected sites.
Check implementation. The coordination role should not begin using the 4-week schedule merely because it has been proposed or because the staffing estimate is acceptable. The recorded approval and the implementation instruction establish when the revised schedule takes effect.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions below.
- A scientific reviewer recommends an analysis change, and an analyst updates the specification immediately. What authority step may be missing?
- A site’s procedure preauthorizes a temporary pause when a stated threshold is crossed. Does executing that pause necessarily approve a permanent change? Explain.
- A scheduling change affects every arm in a platform. Which scope should the matrix flag, and why?
- Name two pieces of information that make an approval record useful for reconstructing a decision.
Solutions. (1) Approval by the role authorized under the governing documents may be missing; recommendation and execution do not by themselves establish approval. (2) No. The pause is an execution of a limited preauthorized action, whereas a permanent change requires the applicable approval. (3) Platform-wide, because the change affects a shared process across all arms; it should follow the relevant platform-level path. (4) Examples include what action was proposed and by whom, the approver’s decision, the basis considered, the implementation role, and the effective date or document version.