Why Map Roles Against Information?
An interim access plan can name the right people and still leave an important question unanswered: which information can each person actually see, and what can they do with it? A role-by-information matrix makes those permissions visible in one place. It is especially useful when an adaptation depends on interim results, because a role may need some information to perform its task without needing every detail collected in the trial.
The matrix is a planning representation, not proof that access controls work as intended. It describes a specified point in the trial and should distinguish planned access from information that is actually available. The earlier material on information tiers and interim results workflows provides useful context: a matrix complements a workflow by showing the relationship between roles and information objects, rather than the order in which information moves.
Define the Matrix Before Filling It In
A useful matrix begins with a clear scope. State which interim period it covers, which adaptation is under consideration, and which people are grouped under each role. “Sponsor” may include employees with different responsibilities; if their access differs, use separate rows rather than treating them as one undifferentiated group.
For a two-arm trial, begin with the four information categories central to this matrix:
- Participant-level data: interim analytical records about individual participants, such as participant-level outcomes or follow-up status. Specify whether records are coded, whether treatment assignment is visible, and which fields are included. This category does not automatically include routine clinical records used to care for an individual participant.
- Arm-specific summaries: interim summaries reported separately for the two trial arms, such as response counts or outcome summaries. State whether the arms are identified only by codes, such as A and B, or by their treatment names.
- Treatment identities: the information that maps each arm code to its treatment, such as the key establishing whether A is the investigational treatment or the comparator. Seeing results for A and B is not by itself the same as seeing that mapping.
- Recommendations: recommendations about a trial adaptation, such as whether to change recruitment or continue as planned. Record whether the role receives, authors, or transmits the recommendation, and whether it receives the rationale or only the action to implement.
Access is not always simply “yes” or “no.” A cell may say “coded participant records,” “receives arm summaries by A/B,” or “authors a recommendation; does not receive the identity key.” A blank cell is ambiguous: it could mean no access, not assessed, or not applicable. Use an explicit entry such as “No access,” or define a symbol and apply it consistently.
Worked Example: Building a Matrix for a Two-Arm Interim Review
Hypothetical trial. A two-arm trial uses codes A and B for interim reporting. An independent statistician prepares the interim analysis. A data monitoring committee (DMC) reviews the arm results and recommends whether a prespecified adaptation should proceed. The sponsor receives the committee’s recommendation, and site staff receive any operational instruction. The DMC has the identity key; the independent statistician does not.
For this example, participant-level data means the interim analytical file, not a site’s routine clinical record. The table records permitted access and recommendation responsibilities for this interim review.
| Role | Participant-level data | Arm-specific summaries | Treatment identities | Recommendations |
|---|---|---|---|---|
| Independent statistician | Coded interim records, by participant | Prepares summaries for A and B | No access to the key | Authors a coded-results recommendation for the DMC |
| DMC | No participant-level file | Receives summaries for A and B | Receives the key | Reviews the evidence and issues a recommendation |
| Sponsor decision team | No access | No access | No access | Receives the DMC recommendation and makes the sponsor’s operational response |
| Site staff | No access to the interim analytical file | No access | No access to the key through the interim process | Receives an operational instruction if one is required |
The entries distinguish the statistician’s ability to compare coded arms from the DMC’s access to treatment identities. They also distinguish a recommendation’s path: the statistician authors material for the DMC, the DMC issues its recommendation, and the sponsor and sites receive different downstream communications. If, for example, sites also need a pooled enrollment update, that additional information should be described rather than hidden inside the word “instruction.”
A Justification for the Matrix Structure
The matrix can be understood as a record of an access relation. Let \(R\) be the set of roles in scope, and let \(I\) be the set of specified information objects. For a given stage of the trial, the planned access relation \(A\) contains a role–information pair when that role is permitted to access that information. The table represents these pairs in a form that can be inspected row by row and column by column.
This representation is useful because permissions can be checked against task requirements. For role \(r\), let \(N(r)\) be the information needed for its assigned task, and let \(A(r)\) be the information it can access under the plan. A basic adequacy condition is that the role has access to the information it needs:
A complementary minimization principle is to avoid granting information that the task does not require. In this planning sense, a proposed assignment is least-privilege when it provides the needed information without unnecessary additions:
This equality is a design goal, not a claim that every task has one uniquely determined information set. Tasks may require different information under different procedures, and a role may need more than one information object. The practical test is to justify each access entry by a defined responsibility and to check that the information remains sufficient for that responsibility.
Name the interim stage, adaptation, and roles. Split a role into separate rows when its members have different access.
Define what counts as participant-level data, arm-specific summaries, treatment identities, and recommendations in this trial.
Record no access, coded access, access to an identity key, or a recommendation responsibility. Avoid ambiguous blanks and broad labels such as “interim data.”
For each role, ask whether its assigned task requires every listed permission and whether it can be done with the information granted.
Worked Example: Separating Coded Results From Treatment Identities
Hypothetical task. A blinded independent statistician is asked to prepare arm-specific response summaries for 120 participants in each coded arm. The response counts are 48 in A and 39 in B. The statistician’s task is to report those coded summaries to the DMC, which holds the key mapping A and B to treatments.
The summaries can be calculated directly from the coded participant-level records. The response proportion in A is \(48/120=0.400\), or 40.0%; in B it is \(39/120=0.325\), or 32.5%. Thus the statistician can report an observed difference of \(0.400-0.325=0.075\), or 7.50 percentage points, between coded arms A and B.
The calculation identifies which coded arm has the higher observed response proportion, but it does not identify which treatment corresponds to that arm. The matrix should therefore show participant-level coded records and preparation of coded arm summaries for the statistician, while showing no access to the treatment-identity key. The DMC’s row can show access to the key if that access is part of the committee’s assigned review.
This separation is only meaningful if the statistician’s other available information does not independently reveal the key. For example, a report that labels A as “active treatment” would disclose the mapping even if the formal key were withheld. The matrix should describe the information as it is actually presented, not just the storage location of the key.
Use the Matrix to Test Whether Access Fits the Task
A matrix is most informative when each permission can be explained by the role’s task. Suppose the independent statistician is asked to calculate a pooled measure for a blinded operational decision, while the DMC is responsible for reviewing arm-specific outcomes. The statistician’s task may require a pooled summary without requiring either arm-specific results or the identity key. The DMC’s task may require arm-specific summaries and, depending on the review procedure, treatment identities.
When a task requires information not represented in the current columns, add a column or define the object explicitly. For instance, pooled summaries are not the same information object as arm-specific summaries. Treating both as “summary data” can conceal a meaningful difference in access. Similarly, receiving a final recommendation is not equivalent to receiving the analysis or rationale used to create it.
Worked Example: Expanding the Matrix for a Pooled-Information Task
Hypothetical task. An independent statistician is assigned to calculate a pooled standard deviation for an operational sample-size review. The review procedure uses pooled variability, not a comparison of outcomes by arm. The sponsor is to receive only the resulting operational recommendation.
The original four columns do not precisely record pooled variability. Add a “Pooled interim summaries” column rather than marking the statistician as having arm-specific summary access. For the statistician, record “Receives coded participant records; calculates pooled variability.” For the sponsor, record “No access.” Keep the arm-specific-summary and treatment-identity cells separate, for example “No arm-specific summaries” and “No key.”
If the statistician’s procedure can calculate the required pooled measure without separating results by arm, access to arm-specific summaries is not justified by this task as stated. Conversely, if the calculation requires arm labels or arm-specific components, the information requirement must be described accurately; calling the output “pooled” does not make every input pooled. The matrix therefore depends on the actual analytical procedure, not only on the name of the adaptation.
Interpretation, Comparisons, and Failure Modes
A role-by-information matrix and a workflow answer different questions. A workflow traces how interim results move or in what order decisions occur; the matrix records which roles can access each information category. A narrative access plan can explain reasons, exceptions, and governance in greater detail, but readers may have to infer permissions across several paragraphs. A matrix makes those permissions easier to compare, while relying on definitions and accompanying text to explain context.
The matrix also has limits. It can oversimplify when a role has access only during a defined window, when permissions differ between team members, or when access depends on the output format. A cell that says “arm-specific summaries” may conceal whether results are coded, named, numerical, graphical, or accompanied by an interpretation. Specify these distinctions when they affect the trial’s information boundaries. The matrix cannot, on its own, show that a technical restriction was enforced or capture every way a person might infer information from other sources.
A useful diagnostic is to read across each row and ask, “Can this role do its stated task with these permissions, and is every permission needed?” Then read down each information column and ask, “Which roles receive this information, and is that distribution intentional?” An unexplained entry or vague cell is a signal to clarify the plan, not evidence that access is safe or unsafe by itself.
- Confusing coded arms with treatment identities. The wrong reasoning is, “The statistician sees results for A and B, so the statistician knows which treatment is which.” The correction is that coded arm-specific results disclose a comparison between A and B, but the treatment mapping is a separate information object unless it is revealed elsewhere.
- Equating a recommendation with no information. The wrong reasoning is, “The sponsor sees no interim data, so it receives no interim information.” A recommendation can itself convey information. Record who receives it and whether the rationale or supporting results are also available.
- Using one row for people with different permissions. The wrong reasoning is, “All sponsor staff have the same access because they work for the sponsor.” The correction is to define the role narrowly enough to reflect actual responsibilities and permissions.
- Treating an unspecified cell as no access. A blank does not state a permission. Enter “No access,” “Not applicable,” or another defined status explicitly.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions below.
- A statistician receives response summaries for coded arms A and B but not the key mapping the codes to treatments. Which information categories should the matrix record as accessible, and which as unavailable?
- A sponsor receives only a recommendation to continue recruitment. Why should the recommendation still appear in the matrix?
- A committee needs arm-specific summaries, but its row says only “interim data.” What is missing from the entry?
- A role is assigned to calculate a pooled summary, and the matrix has no column for pooled information. What is a clear way to represent this access?
Solutions. (1) Record access to arm-specific summaries for A and B, and no access to the treatment-identity key. If the statistician also receives participant-level records, record that separately; it does not follow automatically from receiving summaries. (2) A recommendation is an information object that can convey the outcome of an interim review even when supporting data are withheld. Record that the sponsor receives the recommendation and specify whether it receives the rationale. (3) The entry should state whether the summaries are coded or treatment-named, whether both arms are shown separately, and whether the committee has access to participant-level data or the identity key. (4) Add a distinct pooled-summary column, define the pooled information it covers, and record the role’s permission there rather than treating pooled and arm-specific summaries as interchangeable.