Digital health registries promise real-world evidence at scale, yet a surprising number of submissions stall or receive Refuse to Accept (RTA) letters because regulators cannot trace the data back to its source. If you are preparing a registry-based submission for 2026, the gap is rarely the size of the dataset; it is the lack of verifiable data provenance. This article breaks down the recurring reasons registries fail FDA scrutiny and the concrete steps sponsors can take to fix provenance before a submission lands in the agency’s queue.
The 2026 Reality Check: Registries Are No Longer a Shortcut
Over the past two review cycles, the FDA has tightened expectations for real-world data under its Real-World Evidence Program. Reviewers now treat registry-derived evidence with the same skepticism they apply to pivotal trial datasets. The shift was signaled in updated guidance on data standards and in the increasing number of Information Requests that ask sponsors to reconstruct the life of a single data point—from collection at a clinical site to its appearance in the analysis dataset.
In practice, this means a registry that aggregates EHR extracts, patient-reported outcomes, and device telemetry must demonstrate a chain of custody for every variable. When that chain has weak links, reviewers default to caution, and caution usually looks like a clinical hold or a request for additional confirmatory evidence.
Three Provenance Gaps That Trigger FDA Pushback
Across recent submissions, three failure modes appear repeatedly. None of them are exotic technical issues; they are operational blind spots that compound during the months-long process of cleaning and analyzing registry data.
1. Untracked Transformations Between Source and Submission
Most registries are not born analysis-ready. Site data passes through extraction scripts, a centralized data warehouse, a curation pipeline, and finally an analysis dataset. Each step introduces transformations—unit conversions, date shifts, derived flags, imputation rules. When sponsors cannot produce a precise record of what changed and why, reviewers must either reconstruct the logic themselves or reject the analysis entirely.
The fix is a machine-readable transformation log, not a PDF flowchart. Every derivation rule should be expressed as code with a version, an author, and an input-output example that can be re-executed against the source data.
2. Inconsistent Identity Management Across Sites
Patient identity in a registry is harder than in a clinical trial because there is no single enrolling site. Records arrive from health systems using different MRNs, from app-based consented users with email addresses, and from claims feeds with payer-assigned IDs. Without a deterministic or probabilistically validated crosswalk, the same individual can appear as two patients, or two individuals can be merged.
Reviewers know this and look for evidence of a documented identity resolution process with measured error rates. Sponsors who treat identity management as a downstream data quality task, rather than a foundational design decision, tend to discover the problem only after a data lock.
3. Missing Audit Trails for Manual Curation
Even in highly automated pipelines, registry data requires human review—flagging outliers, reconciling conflicting values, and adjudicating source documents. Those decisions must leave a trace. A query that lives only in an analyst’s notebook, or a correction made in a spreadsheet that overwrites the original value, breaks provenance irrecoverably.
How to Engineer Provenance That Survives Review
Fixing provenance is less about buying new tools and more about adopting three engineering disciplines borrowed from software supply-chain security: immutability, reproducibility, and signed lineage.
Make Source Data Immutable and Addressable
Every raw record that enters the registry should be stored write-once and addressed by a content hash. This sounds heavy, but modern object storage makes it cheap. Once data is content-addressed, you can prove that a value in the analysis dataset is byte-identical to the value that arrived from the site. If a transformation later changes that value, the original remains accessible and auditable.
Treat Analysis-Ready Datasets as Built Artifacts
The final analysis dataset should never be hand-edited. It should be the output of a versioned build process that takes raw inputs, applies every transformation in code, and produces a dataset with an attached manifest. The manifest lists every input file, every script version, and a checksum of the output. When the FDA asks how a variable was derived, you answer by pointing to a specific commit in a repository, not to a person’s memory.
Sign and Timestamp Every Human Decision
Manual curation is unavoidable, but it should be channeled through tooling that records who made a change, what the original value was, what the new value is, and why. A lightweight annotation system linked back to the content-addressed source makes human decisions first-class citizens of the provenance graph rather than invisible corrections.
Mapping Provenance to FDA Expectations in 2026
The FDA’s expectations cluster around three documents that reviewers will request or that you should pre-emptively include in a submission package:
- Data Management Plan updated to describe registry architecture, identity resolution, and curation workflows
- Data Dictionary that traces each variable back to its source field, transformation, and clinical definition
- Audit Trail Summary that describes how changes are recorded, who can make them, and how reviewers can independently verify them
When these documents reference the same artifacts as the build pipeline, reviewers can move from skepticism to confidence quickly. When they do not, the back-and-forth begins, and timelines slip.
A Pre-Submission Provenance Audit You Can Run This Quarter
Before your next FDA interaction, run a focused internal audit using the following checklist. It is designed to surface the same gaps reviewers look for, and it takes days rather than months.
- Pick ten random patient records from the locked analysis dataset and reconstruct their complete history from source to submission variable
- Verify that every transformation between source and analysis is represented in versioned code that can be re-executed
- Confirm that identity resolution decisions are logged with documented confidence scores
- Ensure that manual overrides preserve the original value and record the rationale
- Test whether your data dictionary can be regenerated automatically from the same code that built the dataset
If any step fails, you have a prioritized remediation list. If all steps pass, you can answer reviewer questions with evidence rather than reassurance.
The Competitive Angle: Provenance as a Submission Advantage
Sponsors who treat data provenance as a regulatory hygiene task leave value on the table. The same infrastructure that satisfies reviewers also accelerates internal reuse: the same pipeline that produces a submission dataset can produce a safety monitoring dataset, a health economics dataset, or a label-expansion dataset with minimal rework. In a year when the FDA is signaling faster pathways for submissions with robust real-world evidence, that reusability compounds into earlier approvals and lower per-indication evidence costs.
Conclusion
Digital health registries will play a growing role in regulatory submissions, but only when sponsors can prove that the evidence is trustworthy end to end. The recurring reason these submissions fail is not poor science or weak clinical signal; it is the absence of a verifiable chain of custody for the data itself. By making source data immutable, treating analysis datasets as buildable artifacts, and recording every human decision, sponsors can move from hoping reviewers accept the registry to demonstrating that they should.
