Fact-level provenance in healthcare AI: the 42 capabilities behind an FDA-ready clinical data platform

Every clinical assertion in a regulatory-grade healthcare AI platform must preserve its source document, the exact span it came from, the model and configuration that extracted it, the confidence assigned at extraction, the conflicts detected against other sources, and the rule or reviewer that resolved them. That is fact-level provenance. Building it takes 42 distinct capabilities across ingestion, extraction, privacy, reasoning, audit, and versioning. Retrofitting it onto an existing warehouse is far harder than carrying it through from the first parse.

The FDA’s December 2025 final guidance on real-world evidence for medical devices, operational since February 2026, treats relevance and reliability as per-fact properties of a submission, not per-dataset attributes. When a reviewer asks where a value came from, the answer should be given in a click, not a forensic project.

The clinical fact as the unit of governance

Most data warehouses govern at the level of the file or the table: access controls per dataset, versioned snapshots, dataset-level data dictionaries. That granularity is sufficient when the regulatory question is about a study population. It is not sufficient when the question is about a specific value for a specific patient.

When a reviewer asks “where did this come from?” about a single comorbidity, date, or medication dose, an auditable answer has to include the source document, the exact span in that document where the value appeared, the model and prompt version used to extract it, the confidence assigned at extraction, the normalization decisions that followed, the conflicts detected with other sources, and the rule or human reviewer that resolved them. That is the unit of governance.

Every clinical fact in the system carries six categories of attributes:

These attributes are native columns on the fact record, not entries in a separate lineage table, and they propagate into every derived measure, cohort, and agent answer. Once facts are stored without them, adding them requires re-processing the full corpus against models and documents that may no longer exist in the same state. That is the design decision the rest of the architecture rests on, and it must be made before the first data pipeline runs.

Three re-derivable tiers from raw bytes to OMOP

A monolithic pipeline that parses, extracts, normalizes, and reasons in one pass is the most natural thing to build. It is also impossible to reproduce months later. The version of the parser, the prompt to the extraction model, the terminology mapping table, the conflict resolution rule: all of these change. Without a structural separation between layers, point-in-time reproduction means standing up the entire stack at its earlier state, which is rarely feasible. Instead, the pattern that holds up under audit is a tiered one.

Bronze: lossless parsing. Every file and message format ingested without information loss. Free-text notes, FHIR R4 resources, HL7 v2 messages, DICOM headers, scanned PDFs with OCR, structured warehouse extracts. Nothing dropped, nothing normalized. This tier is immutable: it records exactly what arrived. When a downstream extraction model is retrained two years later, you can re-run extraction against the original Bronze records and reproduce or improve on the earlier result.

Silver: extraction with provenance. Clinical facts pulled from every modality, tagged with source coordinates, scored for extraction confidence, and mapped to standard terminologies. Each fact is independently traceable to a Bronze record. Silver can be re-derived from Bronze without touching anything upstream.

Gold: reasoning and standardization. Duplicates merged, conflicts reconciled across documents, measures and risk scores computed, and the result emitted in a shared analytic format, most commonly OMOP CDM or FHIR. Gold can be re-derived from Silver, and ultimately from Bronze.

Each tier can be validated, re-run, and audited independently. From any value in Gold, an auditor can walk all the way down to the raw bytes. The 21 CFR Part 11 expectation of reproducibility, first codified in 1997 for electronic records and now extended into a per-fact requirement under the new FDA RWE guidance, only holds when every layer is versioned and the dependencies between layers are explicit.

The 42-capability inventory

No single component in this inventory is exotic. The difficulty is that the platform needs 42 distinct capabilities, which must be planned from the first day, and which interact with one another to add complexity. Grouped by domain:

Multimodal ingestion (Bronze)

• Free-text clinical-note parsing with structure preservation (section headers, list semantics, table extraction)

• FHIR R4/R5 resource ingestion with reference traversal

• HL7 v2 message parsing with segment and field-level access

• DICOM header parsing across all standard SOP classes

• DICOM pixel-level PHI detection for text burned into images

• PDF text extraction for both digital and OCR-required scanned documents

• Connector framework for SQL warehouses, claims feeds, and CSV imports

• An immutable Bronze record store with content-addressed identifiers