Why Record Decisions, Not Just Permissions
A trial may have a carefully designed information firewall and role-based permissions, yet later reviewers still need to understand how those controls operated in practice. A list showing that a statistician was approved for interim outputs does not, by itself, establish when approval began, what outputs were authorized, whether access was changed, or who received a particular result. These details matter when reconstructing the trial’s information pathway.
The purpose of a traceable record is not to imply that documentation prevents every disclosure. It is to preserve a reliable account of decisions and events, so the trial team can distinguish the planned arrangement from what was authorized, enabled, and communicated. This extends the earlier material on role-based access, information firewalls, audit logs, emergency unblinding, and staff training: the focus here is the record that connects decisions and exceptions over time.
These distinctions are essential. A request is not an approval; an approval is not proof that a system permission was enabled; an enabled permission is not proof that the person viewed a particular output; and a disclosure to one recipient does not establish that others received it. Records should state what is known and identify the source of that knowledge, rather than silently treating these different events as equivalent.
What a Traceable Record Needs
A useful record allows a reviewer who was not involved in the original decision to answer three questions: who had what information, under which decision, and during what period? The record should identify a person using a stable identifier, not only a job title, since people may change roles. It should identify the information or system at issue with enough specificity to distinguish, for example, a masked enrollment summary from a treatment-arm interim table.
At minimum, a decision or exception entry should include the following:
- Identity and accountability: the requester, decision-maker, record author, and any person responsible for implementation, with role or organizational affiliation where relevant.
- Time and sequence: date and time of the request, decision, implementation, communication, and closure, with the time zone or a clearly stated common time standard.
- Information scope: the system, report, data fields, trial period, participant scope, or other information covered, and any explicit exclusions.
- Decision and rationale: approval, denial, deferral, or conditional approval, and the operational reason for it.
- Boundaries: start and end conditions, duration, permitted purpose, onward-sharing restrictions, and any required safeguards.
- Implementation and evidence: the change made, the responsible person, a reference to the relevant system record or ticket, and confirmation of completion where available.
- Follow-up: review date, revocation or expiry, notification of affected roles, and links to any related exception or disclosure records.
These fields do not require every system to use the same form. They do require enough consistent identifiers to link a request to a decision, an implementation event, and any later change. If the decision spans multiple systems, record the scope in each system or link to a controlled record that unambiguously lists them.
Worked Example: A Time-Limited Interim Output Approval
Suppose, hypothetically, that a data monitoring committee statistician requests access to a masked recruitment summary for a scheduled review. The request is received at 08:40 UTC on 14 May. The designated unblinded data lead approves access at 08:52 UTC, limited to that summary and that review. A system administrator enables the permission at 09:05 UTC, and the statistician confirms receipt of the report at 09:18 UTC. The permission is removed at 11:00 UTC.
A traceable entry links these events by a request ID and records the specific report, the statistician’s identifier, the decision-maker, the reason, the approval time, and the permitted purpose. It then links the implementation ticket and records the administrator and completion time. The receipt entry names the report and its recipient. Finally, the revocation entry records the administrator, time, and confirmation that the temporary permission was removed.
The interval from approval to permission removal is \(11{:}00-08{:}52=2\) hours and 8 minutes. The interval from permission enablement to removal is \(11{:}00-09{:}05=1\) hour and 55 minutes. These are different durations: approval began before the technical permission was enabled. The record should preserve that distinction rather than reporting a single ambiguous “access time.”
Because the report was masked, the entry should describe it as a masked recruitment summary, not merely “interim data.” The record establishes what was approved and that the statistician confirmed receipt. It does not, by itself, establish whether the statistician opened the report at 09:18 or how long they reviewed it; that would require separate evidence.
Preserve the Sequence and the Evidence
The core justification for recording events separately is temporal. A later reviewer needs to distinguish when a decision was made from when a permission changed and when information was received. If these are collapsed into one entry, it may be impossible to tell whether access was implemented before authorization, whether an approval was delayed, or whether a disclosure occurred outside its approved scope.
A time-stamped sequence provides an ordered account, provided that the clocks and time-zone conventions are interpretable. For an enabled permission, the time between enablement and removal can be calculated as an outer window during which access may have been technically possible:
For example, if a permission was enabled at 09:05 UTC and removed at 11:00 UTC, the window is \(11{:}00-09{:}05=1\) hour and 55 minutes. This calculation describes the duration of the recorded permission, not the duration of viewing or the amount of information understood. The inference is limited because system permission is only one part of exposure: the person may not have accessed the material, or information may have been communicated through another route. The record should therefore label the quantity precisely.
A practical sequence for routine decisions is:
Assign a stable reference and record who requested what information, for what purpose, and when.
Name the authorized decision-maker, outcome, rationale, boundaries, and conditions before implementation where feasible.
Record who changed the relevant permission or delivered the output, when it occurred, and the evidence or system reference.
Document known recipients, any required acknowledgment, expiry or revocation, and completion of follow-up actions.
A record should be attributable and preserve its history. If an entry is wrong, correct it through the approved recordkeeping process so the original entry and the correction remain distinguishable. Do not silently overwrite a time, recipient, or scope after the fact. If the event is documented retrospectively, label it as retrospective, state when it was recorded, identify the source used to reconstruct the event, and explain any remaining uncertainty.
Worked Example: Recording a Change in Approved Scope
Imagine, hypothetically, that an analyst is approved at 13:00 UTC on 3 June to view a masked site-enrollment report. At 14:10 UTC, the team determines that the analyst also needs a masked query-status summary. The original approval does not cover this second report. A project coordinator adds both reports to a shared note at 14:20, but the note does not identify who authorized the addition.
The shared note is not enough to establish that the scope change was approved. A complete record should preserve the original scope and create a linked change entry. Suppose the designated decision-maker confirms approval of the query-status summary at 14:30 UTC, limited to the same review purpose. The system administrator adds that report at 14:45 UTC, and the analyst confirms receipt at 14:50 UTC. The change entry records all four times, the additional report, the decision-maker, the rationale, and the related implementation and receipt references.
The extra report was technically available from 14:45 until the original permission was removed at 16:00 UTC, so its recorded permission window is \(16{:}00-14{:}45=1\) hour and 15 minutes. The original report’s permission window, enabled at 13:05 and removed at 16:00, is \(16{:}00-13{:}05=2\) hours and 55 minutes. These calculations must be reported separately because the two information scopes had different start times.
If the administrator had already enabled the additional report before the 14:30 approval, the record must show that sequence as it occurred; it must not backdate the authorization. The team can then document the facts and follow its established escalation process. Accurate timing is more useful than a superficially tidy chronology.
Emergency Exceptions and Disclosures
An emergency exception may require action before the usual approval sequence can be completed. The record should still identify the trigger, the person who initiated the exception, the minimum information needed, the recipient, the time, and the reason ordinary steps could not be followed. It should also capture the decision or review that followed, any additional disclosure, and when access was stopped or narrowed. Urgency may change the order of actions; it does not make the record optional.
Keep the information scope as narrow as the situation permits. If a person needs participant-specific treatment information for an urgent safety decision, document the relevant participant or case identifier in the appropriate protected record, who received the information, and the communication channel. Avoid recording unnecessary sensitive details in a general access log. Link to the designated clinical or safety record when that is the controlled location for the detailed clinical rationale.
Worked Example: A Hypothetical Emergency Unblinding Record
Suppose, hypothetically, that at 02:14 local time on 18 July a treating clinician determines that knowledge of a participant’s assigned treatment is necessary for an urgent care decision. The clinician requests emergency unblinding through the approved channel. A person authorized under the emergency procedure verifies the participant identifier and releases the treatment assignment to that clinician at 02:19. The clinician acknowledges receipt at 02:21. The case is reviewed by the designated trial contact at 08:30, and the record is completed at 09:05.
The exception record states the event time zone, participant reference, requester, authorizing or releasing person, recipient, reason that the information was needed, information disclosed, channel, and each event time. It links to the relevant clinical record without copying unnecessary clinical detail. It also records the 08:30 follow-up and explains that the entry was finalized at 09:05, after the event.
The interval from request to disclosure is \(02{:}19-02{:}14=5\) minutes. The interval from disclosure to recipient acknowledgment is \(02{:}21-02{:}19=2\) minutes. These durations describe the recorded communication process; they do not establish whether the treatment information changed care or affected later assessments. The record should not claim more than its evidence supports.
Comparing Record Types and Checking Their Quality
Different records answer different questions. A decision register explains why access was approved or denied and under what conditions. A system permission history can show when technical access was enabled or removed. A communication or disclosure record can identify information actually sent and its recipients. A meeting minute may provide context for a decision, but it can be too general to establish exact scope or timing. These records should be linked, not treated as substitutes for one another.
| Record type | What it can support | What it does not establish alone |
|---|---|---|
| Access decision record | Who decided, the authorized scope, purpose, conditions, and rationale | That a technical permission was implemented or the information was viewed |
| System permission history | When a recorded system permission changed, subject to that system’s logging and clock controls | Why it changed, whether the person viewed a report, or what they understood |
| Disclosure record | Known sender, recipient, information, channel, and communication time | That access was properly authorized or that no other route of disclosure existed |
| Meeting minutes | Discussion and decisions in a meeting, if recorded with adequate specificity | Complete implementation history or precise timing unless those details are captured |
A record is easier to rely on when its entries agree across sources. Reviewers should be able to resolve who a role label refers to, what a report name means, which time zone was used, and how a decision connects to a system change. A missing approver, an unclear scope such as “interim results,” inconsistent time zones, or a later edit with no explanation weakens reconstruction. The appropriate response is to preserve the uncertainty and seek corroborating evidence, not to infer a cleaner sequence than the records support.
Structured forms make routine requests easier to compare and less likely to omit essential fields. Free-text notes can capture unusual circumstances but may be ambiguous or difficult to link. A sound approach uses consistent fields for identity, scope, decision, and timing, with a narrative area for context. Neither a database nor a signed form guarantees accuracy; accountable review, controlled correction, and linkage to source evidence remain important.
Common Mistakes and Limits
- Equating authorization with exposure. “Approved for access” does not mean “viewed the result.” Record the approval, technical permission, and known receipt as distinct events.
- Using vague scope labels. “Trial data” or “interim information” may cover very different outputs. Name the report, fields, masking state, period, and relevant participant scope as specifically as needed.
- Writing only the final state. A current access list cannot show when a person was added or removed. Preserve the change sequence and references to the relevant records.
- Backdating to make events appear compliant. A retrospective record should state when it was made and what source supports it. Do not replace the observed chronology with the intended chronology.
- Assuming no recorded disclosure means no disclosure occurred. Records can be incomplete, and some communication may occur outside logged systems. State the limits of available evidence.
Documentation supports reconstruction and accountability, but it cannot prove a person’s comprehension, intent, or lack of exposure through every possible route. It can also create privacy risks if sensitive details are copied unnecessarily. Keep records access-controlled, retain only the detail needed for the operational purpose, and follow the trial’s approved retention and correction processes.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions below.
- A system log shows that a user’s permission was enabled from 10:00 to 10:40 UTC. What can this establish, and what can it not establish by itself?
- A reviewer finds an access approval entered at 16:00, although the associated report was sent at 15:45. What should a traceable record preserve?
- A trial team’s form says “approved for interim data.” Name two ways to make the scope more interpretable.
- In a hypothetical emergency, information was disclosed at 03:12, acknowledged at 03:14, and the record was completed at 07:00. Calculate the disclosure-to-acknowledgment interval and state how the later entry should be labeled.
Solutions. (1) It supports a 40-minute recorded permission window, \(10{:}40-10{:}00=40\) minutes. It does not establish that the user viewed a report, what they understood, or that no other disclosure occurred. (2) Preserve the actual sequence and times, identify the source for each event, and document that the report was sent before the recorded approval; do not backdate the decision. (3) Identify the specific report or output, its masking state, and the relevant data period or participant scope, as applicable. (4) The interval is \(03{:}14-03{:}12=2\) minutes. The entry should show that it was completed retrospectively at 07:00 and identify the evidence used to record the earlier events.