Part 2 research data-linkage review

Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.

The IRB reviews the linkage component

42 CFR 2.52 requires review and approval by an IRB registered with the HHS Office for Human Research Protections. Preserve the approved protocol, linkage description, data elements, repositories, privacy analysis, justification for identifiable data, approval dates, conditions, and amendments.

Verify the IRB's registration and match the linkage approval to protocol, investigator, repository, source data, comparison data, identifiers, matching method, population, purpose, output, sites, dates, and conditions. An approval for the study's analysis does not necessarily show that the linkage component itself was reviewed.

Document why patient-identifying information is needed to perform the match and why less identifiable methods are insufficient. Limit direct identifiers, quasi-identifiers, dates, geography, and free text to the approved logic. Preserve field-level justification and match-quality plan.

Law-enforcement separation is explicit

The researcher must ensure that Part 2 patient-identifying information is not provided to law-enforcement agencies or officials and is not redisclosed for other linkage purposes. Build recipient and destination controls that apply to people, interfaces, exports, vendors, and later reuse.

Screen repository ownership, governance, funders, users, clients, mandatory feeds, shared platforms, and downstream tools for law-enforcement access or incompatible use. Put prohibitions into agreements, access roles, routing rules, data-loss controls, monitoring, and legal-demand procedures. A promise from the immediate analyst is insufficient if an administrator or parent organization can retrieve the data.

Reject reuse of the received Part 2 data or keys to link another dataset, expand the cohort, validate identities for operations, develop a product, or support another project without current qualified review. Preserve every proposed secondary use and decision.

The repository becomes bound by Part 2

Upon receiving patient-identifying data, the repository is fully bound by Part 2. After providing linked data to the researcher, it destroys or deletes the linked data from its records and sanitizes associated media so the information is non-retrievable, consistent with 42 CFR 2.16. It also prevents law-enforcement disclosure.

Before transfer, inventory staging tables, source files, linkage keys, temporary outputs, caches, logs, snapshots, backups, queues, test copies, local devices, vendor systems, and disaster-recovery replicas. Define which artifacts the repository receives or creates, who owns them, when the linked data is provided, and which destruction or sanitization evidence closes each copy.

Automate deletion where supportable while preserving a human reconciliation. A database row deletion may leave snapshots, object versions, indexes, logs, or removable media. Resolve necessary operational logs and required records through qualified policy without keeping patient-identifying linkage data beyond the permitted lifecycle.

Validate the linked output

Compare source and linked populations, match rates, false matches, missed matches, duplicate people, fields, dates, exclusions, and identifiers. Keep linkage-quality review separate from permission to release. Remove repository-only identifiers and confirm the output sent to the researcher matches IRB-approved scope.

Preserve transfer manifests, checksums, recipient, environment, date, and delivery confirmation. The researcher's subsequent use, reporting, redisclosure, security, retention, and destruction duties continue after receipt.

Manage amendments and failures

Re-review a new dataset, repository, match method, variable, cohort, purpose, user, site, retention period, or output. Pause scheduled linkage when IRB approval, agreement, security review, or repository qualification expires.

If the repository retains data, exposes it to law enforcement, links it for another purpose, or sends an incorrect output, contain access, preserve evidence, and route privacy, security, research, legal, clinical, and patient communication decisions. Review other projects using the same platform.

Example with linkage packets

Seven linkage packets are evaluated. Five have registered-IRB approval, justified fields, repository duties, and law-enforcement controls; two lack linkage-specific approval. Readiness is 5 of 7 packets.

The program holds the two packets until the IRB addresses the linkage component. One later receives approval for a narrower field set; the other moves to a nonidentifying design. The five approved projects proceed with copy inventories and deletion evidence.

Linkage checklist

• Verify registered-IRB approval for the linkage component.
• Justify each patient-identifying field and matching method.
• Screen repository governance and block law-enforcement access.
• Prohibit unrelated linkage, reuse, recipients, and destinations.
• Inventory staging, keys, caches, backups, logs, and temporary copies.
• Validate linked output and prove repository deletion or sanitization.
• Re-review changes and contain retention, access, or output failures.

Owner controls

The 2024 final rule provides current context. Use protocol versioning, repository contracts, transfer manifests, field minimization, environment separation, output review, deletion evidence, and continuing IRB oversight.

Monitor linkage approvals, identifiers, match results, repositories, secondary-use requests, output transfers, deletion timing, backups, legal demands, and incidents. Audit from linked data back to approved fields and from repository environments into non-retrievable closure evidence. Retest after protocol, method, platform, vendor, governance, or law-enforcement-access changes.