Why Transfer Is Part of the Interim Review
An interim dataset or report can contain confidential trial information, including treatment assignments or safety details that could compromise blinding if disclosed to the wrong person. Preparing a correct DMC package is not enough: the transfer must also preserve confidentiality, prevent unnoticed alteration or substitution, reach the intended recipients, and leave a usable record of what was sent and received. A secure process reduces preventable exposure and helps the committee work from the intended materials.
This tutorial treats transfer as a controlled sequence, not as a single act of attaching a file to a message. The workflow begins with an approved, validated package and ends only after receipt and package identity have been reconciled. The transfer plan should fit the study’s protocol, data-management plan, committee charter, sponsor procedures, and applicable privacy and records requirements. No single technology or retention period is appropriate for every trial.
Set the Transfer Conditions Before Release
Start by identifying the information being transferred, its sensitivity, who is authorized to see it, and what could go wrong. For DMC materials, the recipient list may differ for open and closed materials. Access should follow the assigned role and the committee’s established confidentiality arrangements; a recipient’s general involvement in the trial does not by itself establish permission to receive every file. Confirm that the package is the approved version and that no unnecessary identifiers or files have been included.
The workflow depends on several practical conditions: the sender can distinguish authorized recipients from others; the transfer service is approved for the material’s sensitivity; the recipient can authenticate to that service; and the responsible team can retain transfer records. If any condition is uncertain—for example, an account is shared, a recipient’s identity cannot be confirmed, or the approved service is unavailable—pause and resolve it through the study’s designated process rather than improvising with a less controlled channel.
Encryption protects information from being read by an unauthorized party, but encryption alone does not establish that the right person received it, that the file is the intended version, or that the recipient is allowed to view it. Use a sponsor- or institution-approved mechanism with access controls and authentication. Where files are encrypted separately from the transfer service, communicate the decryption secret through a separately verified channel, not in the same message or location as the file. Avoid personal email, consumer file-sharing accounts, or removable media unless explicitly approved for the study and controlled under its procedures.
Identify the package, its intended audience, the approved version, and the person responsible for release. Check that each recipient’s role permits access to these specific materials.
Use a trusted, maintained contact directory or another established identity check. For a changed address or unfamiliar recipient, confirm through a previously verified contact route, not by replying only to the request that supplied the new details.
Use the approved encrypted transfer service, authenticated recipient access, and the minimum permissions needed. Set an appropriate expiry or access window when supported and consistent with the study plan.
Assign a unique package identifier and record its contents and version. Use a trusted manifest or integrity check so that sender and recipient can establish they are referring to the same package.
Obtain confirmation from the intended recipient, then reconcile the package identifier and integrity information. A delivery notification alone does not show that the intended person accessed the correct package.
Keep required records in the designated repository, review permissions after the transfer, and remove access or temporary copies according to the approved retention and destruction plan.
Version Control and Integrity Checks
A package identifier should distinguish one release from another without exposing sensitive contents in a filename or notification. A controlled naming convention might include the study code, meeting or review identifier, audience designation, package sequence, and date in an approved format. Do not rely on a filename alone to prove that two files are identical. Record the source snapshot or package version, the included files, the release time, and who authorized the release in a controlled transfer log.
A cryptographic hash, such as a hash generated by an approved tool, produces a fixed-length value from a file. Matching hashes provide strong evidence that the compared files have not changed between the two hash calculations, assuming the hash method is appropriate and the values themselves have not been substituted. A hash does not prove who created a file or whether its contents were authorized. For authenticity, use a trusted authenticated channel for the manifest or an approved digital signature or message-authentication mechanism. Do not treat an emailed hash sent alongside an untrusted file as independent proof of provenance.
Worked Example: Releasing a Closed DMC Package
Suppose a fictional trial team is releasing a closed-session package labelled “Trial Q, review 04, closed, package 02.” It contains a validated data snapshot, safety listings, and an interim efficacy report. The authorized recipient list contains five committee members and one statistician. The sponsor’s procedure requires an approved secure portal and a transfer log.
Before upload, the release coordinator compares the recipient list with the approved closed-session access list and confirms that all six accounts are active and individually assigned. One address differs from the controlled directory. The coordinator does not send the package to that address merely because it appears in a recent email; instead, the coordinator confirms the change through the established contact route and records the verification.
The coordinator uploads package 02 to the approved portal, grants access only to the six verified accounts, and checks the portal’s access settings before release. The transfer log records the package identifier, included files, authorizer, release time, recipient group, and the manifest’s trusted integrity information. The coordinator sends a brief notification that a package is available, without attaching the files or including confidential results.
Each recipient confirms access and the package identifier. The statistician compares the received files with the trusted manifest and finds that all expected files are present and their integrity values match. The coordinator records the confirmations and closes the release task. This sequence supports the conclusion that the intended accounts were given access to the identified package and that the received files match the recorded files; it does not establish that recipients have read or interpreted them correctly.
Receipt, Mismatches, and Recovery
Receipt confirmation should be specific enough to resolve practical uncertainty. Ask the recipient to confirm access to the identified package, not to repeat confidential findings in an unsecured reply. Reconcile acknowledgments against the intended recipient list: an automated “delivered” or “uploaded” message may indicate only that a service accepted a file, not that the intended recipient authenticated, obtained the complete package, or received the correct version.
If a recipient reports a missing file, an unreadable archive, or a mismatch, mark the package as not cleared for use. Preserve the relevant transfer record, check whether the discrepancy affects one recipient or the released package, and investigate through the designated data or security contact. If a package may have gone to an unauthorized person, or a credential or link may have been exposed, stop further access where possible and escalate promptly under the study’s incident procedures. Do not silently replace a file while leaving the original release record unchanged.
Worked Example: A Manifest Does Not Match
For a fictional package, the sender’s trusted manifest lists four files. After download, a committee member sees only three. The member also reports that the integrity value for one downloaded file differs from the value in the manifest. The package is therefore not reconciled: both the file count and one integrity comparison fail.
The member does not use the incomplete package or forward it to another recipient. The member reports the package identifier and discrepancy through the approved support route. The coordinator checks the release record and confirms that the manifest lists four files, then investigates whether the portal upload was incomplete or whether the wrong version was selected. Once the cause is resolved, the coordinator authorizes a clearly identified replacement release, provides a corrected manifest through a trusted channel, and obtains fresh confirmations.
The original release record remains intact and is linked to the replacement record. This distinction matters: overwriting the original log would obscure what recipients initially received and when. If the investigation instead suggested unauthorized access or alteration, the coordinator would follow the incident escalation process rather than treating the problem as a routine upload error.
Why the Checks Work Together
Each control addresses a different failure mode. Recipient verification reduces the chance of releasing to the wrong person. Encryption limits disclosure to parties who lack the necessary access or key. Version identifiers and manifests reduce confusion between releases. Receipt reconciliation detects incomplete delivery. Retention controls reduce unnecessary persistence of sensitive copies. None can substitute for the others.
The integrity logic is straightforward. Let the sender’s recorded integrity value for an authorized file be \(h_s\), and let the recipient’s value for the received file be \(h_r\). If the specified hash procedure is applied consistently and \(h_s=h_r\), that comparison supports the claim that the received bytes match the bytes represented by the sender’s recorded value. It does not establish that the sender’s file was the correct or authorized file; authorization and version control must establish that separately. Nor does a match prove that no unauthorized person saw the file during transfer. Thus the workflow first establishes which package is authorized, then protects its transmission, and finally checks whether the received package corresponds to that release.
This is why a checksum alone is not a security workflow. If an attacker can replace both the file and an unauthenticated checksum, the recipient may compare two matching values for an unauthorized replacement. A manifest protected by a trusted authenticated channel or signature binds the integrity information to an accountable source; access controls and recipient verification address who can obtain the materials.
Worked Example: Choosing What to Do When a Recipient Is Unavailable
A fictional coordinator is scheduled to send a package to six authorized recipients. Five have confirmed access; the sixth is temporarily unavailable, and the portal’s access log shows no successful authentication for that account. The package is encrypted in the portal, but the coordinator should not infer that the sixth person has received it just because the upload succeeded.
The coordinator records five confirmed receipts and one outstanding receipt. The coordinator checks that the sixth account remains authorized and active, then uses the established contact route to notify that recipient that access is pending. The coordinator does not send the file to a colleague as a workaround unless that person is independently authorized for this package and the change is approved. If the review timetable requires a decision about the outstanding receipt, the issue is raised through the responsible study process; the transfer log is not altered to imply six confirmations.
The relevant counts are five confirmed recipients out of six intended recipients, so one confirmation remains outstanding. This arithmetic describes the status of the transfer only; it does not justify a conclusion about whether the recipient has viewed the materials. The log should distinguish “access granted,” “download recorded” if available, and “recipient confirmation received.”
Retention and Common Failure Modes
Define retention before release: identify which transfer records, manifests, and package copies must remain in the official repository, who may access them, and how long they must be retained under the applicable study requirements. Temporary portal copies, local downloads, and working files should be addressed explicitly. At the end of an authorized period, access should be removed and eligible temporary copies securely deleted or otherwise disposed of according to policy. Preserve records when a legal, regulatory, audit, or investigation hold applies; do not delete them merely because routine access has expired.
A practical retention record can include the package identifier and version, sender and authorizer, intended recipients, release and confirmation times, transfer method, manifest or integrity-check reference, exceptions, corrective actions, and access closure. Keep sensitive payloads in the controlled repository rather than duplicating them in an informal email archive. Access should be reviewed when roles change, a committee member leaves, or a temporary link is no longer needed.
| Failure mode | Why it is insufficient or risky | Correction |
|---|---|---|
| Sending to an address copied from an unverified request | A plausible address does not establish identity or authorization. | Verify independently against a trusted directory or established contact route. |
| Using encryption but sharing the password in the same message | Anyone who obtains the message may obtain both the file and its secret. | Use approved recipient authentication or communicate secrets through a separately verified channel. |
| Relying on a filename such as “final” | It does not distinguish authorized versions or confirm contents. | Use unique package identifiers, a controlled manifest, and release records. |
| Treating a matching checksum as proof of authorization | A checksum can show a byte-level match to a value, not who authorized the file. | Authenticate the manifest and verify package approval separately. |
| Assuming a delivery notice confirms complete receipt | A service notification may not show recipient access or package completeness. | Reconcile recipient confirmations and package identity against the release record. |
| Keeping access indefinitely “just in case” | Unneeded access and copies increase exposure over time. | Apply the approved retention plan, review permissions, and document closure. |
A common mistake is to treat a secure platform as sufficient by itself: “The portal is encrypted, so the transfer is secure.” The correction is to ask what the portal does and what the workflow still must establish. Encryption protects data under specified conditions, but recipient authorization, correct version selection, authenticated integrity information, receipt reconciliation, incident handling, and retention remain operational responsibilities. A second mistake is to delete every copy immediately after confirmation; the correction is to distinguish unnecessary working copies from records that the approved retention plan requires the study to preserve.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions.
- A recipient’s email address changes shortly before release. What should the coordinator do before granting access?
- A recipient’s downloaded file has an integrity value that does not match the trusted manifest. May the recipient use the file while the team investigates? Explain.
- Why is a matching hash not sufficient evidence that a package was authorized and sent by the correct person?
- A portal reports that a package upload succeeded, but one of four intended recipients has not confirmed access. What should the transfer log say?
- After the routine access period ends, should all records and copies be deleted? State the distinction that governs the decision.
Solutions. (1) Verify the new address through a previously trusted contact route, confirm the person’s identity and authorization for the specific materials, and record the verification before granting access. (2) No. The mismatch means the package is not reconciled; the recipient should not use or forward it and should report the discrepancy through the approved route while the team investigates. (3) A hash comparison supports a byte-level match to the value compared, but an unauthenticated value can be substituted, and even an authentic hash does not establish that the file was the authorized version. Authorization and source authenticity require separate controls. (4) Record that the upload succeeded, three recipients confirmed access, and one confirmation is outstanding; do not mark all four as confirmed. (5) No. Remove unnecessary access and dispose of temporary copies according to the approved plan, but preserve required records and any material subject to a hold. Document what was retained, access closure, and any authorized destruction.