Why Data Rights Need Explicit Allocation
A multi-arm platform may use shared infrastructure while involving sponsors with different responsibilities and interests. Some information supports the platform as a whole, such as screening logs or common control-arm outcomes; other information arises from one treatment arm, such as drug-specific exposure or manufacturing data. Analyses may combine both. If the governance documents do not say who may hold, access, and authorize use of each data type, a scientifically straightforward analysis can become an unresolved authority dispute.
The word ownership is often used loosely. It can refer to legal rights in records or datasets, responsibility for keeping them, authority to grant access, or responsibility for deciding how they are used. These are not automatically held by the same party. Their allocation depends on applicable law, participant permissions, contracts, protocol commitments, and the platform’s governance documents. A committee’s approval is not, by itself, a substitute for rights or permissions that the committee was never granted.
Classify the Data Before Assigning Rights
Rights are easier to allocate when the data are classified by origin and purpose, rather than treated as one undifferentiated platform dataset. A practical inventory should identify at least the source records, the parties contributing them, the party maintaining them, and the data products created through linkage or analysis.
- Platform-wide data are collected under common platform processes or support platform-level functions. Examples may include common eligibility variables, screening records, or outcomes in a shared control group. “Platform-wide” describes their operational role; it does not establish who owns them.
- Arm-specific data arise from an individual treatment arm or its sponsor-specific procedures. Examples may include treatment exposure, product handling, or arm-specific outcomes. A sponsor may have rights or responsibilities defined by its agreement, but those do not automatically extend to common platform data.
- Derived or linked data are created by combining, transforming, or analyzing source data. A pooled analysis dataset that joins platform-wide records with outcomes from several arms is a distinct data product. The documents should specify who may create it, retain it, access it, and authorize its later use.
- Operational and administrative records may include access logs, data-management records, or audit trails. These can have their own custodians and permitted uses, even when they relate to other datasets.
The inventory should also distinguish a data set from the results of an analysis. Access to row-level records does not necessarily imply authority to share every derived data product, and permission to review aggregate results does not necessarily permit access to source records. The allocation should state the level of data covered: identifiable or coded records, individual-level analysis files, or aggregate outputs.
Worked Example: Separating Platform and Arm Data
Consider a hypothetical platform with a shared screening process and a common control group. Sponsor North funds Arm N, and Sponsor South funds Arm S. The platform data center maintains the screening and outcome database. The master agreement names the platform sponsor as steward of common records, while each arm agreement assigns its sponsor defined rights to arm-specific records. The charter permits a data access committee to approve analysis requests within delegated limits.
A researcher proposes comparing outcomes in Arm N, Arm S, and the common control group. The proposed analysis uses three components: platform screening and eligibility records; Arm N outcomes; and Arm S outcomes. The data center’s custody of all three components does not, on its own, give it authority to approve their use. Nor does the platform sponsor’s stewardship of common records automatically confer authority over both sponsors’ arm-specific records.
The request therefore needs review against each source’s allocation. The delegated committee can decide whether the proposed scientific use meets the charter’s criteria, but only if its authority covers the relevant data. Before access is granted, the platform sponsor must have authority over the common records, and the agreement or an explicit delegation must cover each arm’s data. Participant permissions and applicable requirements must also permit the proposed analysis. If one necessary authorization is missing, the committee should seek it or narrow the request; it should not treat the pooled file as freely usable because it has already been assembled.
This allocation preserves both levels of responsibility: platform governance can coordinate a platform-wide analysis, while sponsors retain only the rights actually granted to them for their own contributions. The decision and any limits on the analysis should be recorded before access is provided.
Who Can Authorize a Pooled Analysis?
A pooled analysis draws on records from more than one source, arm, or sponsor. A sound authorization pathway asks two separate questions. First, is the proposed use scientifically and operationally acceptable under platform governance? Second, does the approving party have permission to authorize use of every required data component? A positive answer to the first question cannot repair a negative answer to the second.
The charter and agreements should state whether a platform body may approve analyses using only platform-wide data, analyses using one arm’s data, or analyses combining data across sponsors. Where authority is delegated, define its scope and limits: eligible requestors, data types, permitted purposes, required consultations, and any decisions reserved to a sponsor or another accountable party. A sponsor may delegate specific decisions without transferring every right or responsibility associated with its data.
A useful justification follows from the composition of the analysis file. If an analysis requires components \(D_1, D_2, \ldots, D_k\), then permission to use the combined file must cover every component required for that use. Approval for \(D_1\) alone cannot authorize use of \(D_2\). Thus, the effective permission is bounded by the permissions applicable to all required components, as well as any additional participant or regulatory conditions.
This is a governance principle, not a formula that overrides a contract or legal rule. It highlights a practical check: for each data component, identify the source of permission and confirm that the proposed purpose falls within it. If a component is not needed, removing it may make the request permissible under a narrower set of permissions.
Worked Example: Testing a Pooled-Analysis Approval Route
In a hypothetical platform, the charter delegates to a data access committee approval of analyses using common-control data and arm data when the relevant arm sponsor has given written delegation. Sponsor Cedar has delegated authority for Arm C. Sponsor Elm has not delegated authority for Arm E. A proposal compares both arms with common control, using all three groups.
The committee has authority over the common-control data under the charter. Its delegation also covers Arm C. It does not cover Arm E, because Sponsor Elm has not delegated the relevant decision. Therefore the committee cannot authorize the proposed three-group analysis on its own, even if it judges the scientific plan worthwhile.
There are two valid next steps. The committee can seek Sponsor Elm’s authorization, then consider the complete pooled request under the applicable conditions. Alternatively, the researcher can revise the analysis to use only Arm C and common control, if that revised question is scientifically coherent and all other permissions allow it. The committee must not describe the second option as evidence about Arm E, because Arm E data were not included.
The route is justified by matching authority to the data used: common control and Arm C are covered by existing delegations; Arm E is not. Recording this component-by-component assessment makes clear why the original request could not be approved and what change would make a review possible.
Secondary Use: A New Purpose Requires a New Check
Secondary use means using data for a purpose different from the one for which they were originally collected or made available. Examples might include a new methodological analysis, a validation study, or a question outside the original arm-specific objective. A prior approval for the primary trial analysis should not be treated as blanket permission for every later question.
A secondary-use review should check whether the new purpose fits the applicable agreement, participant permissions, protocol commitments, and relevant requirements. It should also establish who can authorize the use, which records are necessary, and whether the proposed user may access the requested level of detail. If a platform committee has delegated authority only for platform operations or specified analyses, it cannot infer broader authority from its general governance role.
These checks are also important when data have been transformed or pooled. A derived file does not necessarily lose restrictions attached to its source data. The agreements should address whether derived data may be retained or reused, whether a new request is required, and who decides. The appropriate answer may differ across data sources in the same analysis file.
Worked Example: Reviewing a Secondary Data Request
Suppose, hypothetically, an analysis of a platform trial is complete. A research group asks to reuse coded individual-level records from two arms to study a different clinical outcome. The initial analysis plan covered the primary outcome only. The platform agreement allows secondary use after review by a delegated committee and consultation with each contributing sponsor. The consent materials permit further research subject to applicable review and governance conditions.
The request is not automatically approved because the records are coded or because the primary analysis was authorized. The committee first checks that its delegation covers secondary use. It then identifies the two contributing arm sponsors and consults them as required. It confirms that the new outcome and proposed analysis fall within the participant permissions and other applicable conditions. It also checks that the requested individual-level detail is necessary rather than assuming that the original access level remains justified.
If both sponsors’ required permissions are obtained and the proposed use fits the governing conditions, the committee may authorize access within its delegated scope, with limits recorded in the decision. If one sponsor’s agreement excludes the new purpose, or the participant permissions do not cover it, the committee cannot cure that restriction simply by voting to approve. The request must be revised, further authorization obtained where valid, or declined.
Documenting the Allocation and Detecting Failure
A workable allocation is specific enough that staff can apply it without guessing. For each data category or product, record the owner or rights-holder where defined, custodian, steward, authorized users, approval authority, permitted purposes, and route for exceptions. Identify how rights apply when data are linked, pooled, or transferred during a sponsor handoff. The allocation should be consistent across the master protocol, platform agreements, arm agreements, and relevant procedures.
A review can use a short sequence of checks:
List the source records and derived products needed for the request, and identify which are platform-wide, arm-specific, or jointly created.
For every component, identify the relevant agreement, permission, or delegated authority. Do not infer authority from custody or technical access.
Check that the requested analysis, data level, users, and retention are within the permissions and responsibilities that apply.
Seek missing authorization, remove unnecessary data, or revise the request. Document the decision and its limits before release.
Warning signs include a data center described as “owner” without defining whether that means custody or decision authority; a committee approving a pooled analysis without identifying all contributing sources; silence about derived data; and secondary-use clauses that say only “subject to approval” without naming the approver or scope. Another warning sign is a sponsor transition that transfers operational custody but does not clarify who retains decision rights or what happens to previously created pooled files.
Do not confuse this allocation exercise with a complete information-security or confidentiality plan. Data access rights establish who may use which data and for what authorized purpose; separate safeguards govern how permitted access is protected. Likewise, scientific merit review and legal permission are complementary checks, not alternatives.
Choosing Among Governance Approaches
| Approach | Strength | Limitation to address |
|---|---|---|
| Central platform approval | Provides one coordinated route for platform-wide requests and pooled analyses. | Works only within authority delegated by relevant rights-holders and compatible participant permissions. |
| Separate sponsor approvals | Makes each sponsor’s decision over its defined arm data explicit. | Can create delay or inconsistent decisions unless timelines, criteria, and escalation routes are agreed. |
| Joint or delegated approval | Allows a committee to decide across data sources under written delegations and specified limits. | Requires precise delegation, clear scope, and a process for sources or uses outside that scope. |
No approach is universally best. Central approval can be efficient for genuinely shared data, but it should not be presented as ownership of every arm’s records. Separate approvals can protect defined sponsor responsibilities, but a platform that relies on them should plan for timely coordination. Joint or delegated approval can balance consistency and source-specific rights when the agreements spell out exactly what has been delegated and what remains reserved.
Common Pitfall
Wrong reasoning: “The platform data center holds the combined dataset, so the platform committee can approve any analysis using it.” This confuses custody with authority and ignores restrictions that may attach to individual components or to a new purpose.
Correction: Identify the source and applicable permission for every necessary component. Confirm that the approving body has delegated authority for the proposed use, and check participant and other applicable conditions. Technical ability to provide data is not permission to use them.
Check Your Understanding
Answer each question by applying the distinction between rights, custody, stewardship, and access.
- A data center stores platform screening records and one sponsor’s arm outcomes. Does storage alone authorize the data center to approve a pooled analysis? Explain.
- A committee is delegated authority for common-control data and Arm A, but not Arm B. A request uses all three. What should happen before access is granted?
- Why should a secondary-use request be checked separately from the original primary analysis approval?
- Name two details that an agreement should specify about derived or pooled data.
- A proposed analysis needs data from two arms, but one arm’s records are unnecessary for a scientifically coherent revised question. What governance option might be considered?
Solutions. (1) No. Custody is responsibility for maintaining records, not necessarily authority to approve their use; the relevant rights and delegations must be checked. (2) The committee should obtain the missing Arm B authorization or narrow the request to data within its authority, then confirm all other applicable permissions. (3) The new purpose may fall outside the original analysis plan, agreement, delegation, or participant permissions, so the previous approval may not cover it. (4) The agreement should specify who may create and retain the pooled product, who may access it, and who can authorize its later use; any two of these are sufficient. (5) The request may be revised to exclude the unnecessary arm data, provided the revised scientific question remains valid and the permissions for the remaining data cover that use.