Real-world data / real-world evidence marketplace mechanics — immutable query logging, FDA RWE-grade data lineage, and read-only regulator access for detecting policy-violating secondary use
Real-world data (RWD) is health information collected outside the controlled setting of a randomized clinical trial: electronic health records (EHR), medical claims, pharmacy dispensing records, disease registries, and increasingly patient-generated data from wearables and mobile apps. An RWD marketplace aggregates these heterogeneous sources under a common access layer — but auditability begins at the very first ingestion step, where each incoming record must be tagged with a persistent lineage identifier before any transformation touches it.
Real-world data marketplaces typically aggregate four categories of source data, each with distinct structure and provenance risk:
1. Electronic health record (EHR) extracts: • Delivered via HL7 FHIR (Fast Healthcare Interoperability Resources) API extraction or bulk export • Contains clinical notes, diagnosis codes (ICD-10-CM), procedure codes (CPT/HCPCS), lab results (LOINC-coded), medication orders (RxNorm-coded) • Highest richness, highest re-identification risk given free-text clinical notes
2. Medical claims data: • X12 837 institutional/professional claim format, or payer-proprietary extracts • Diagnosis and procedure codes plus billing/payment data; broader population coverage than any single EHR system, but lower clinical granularity (no lab values, no notes)
3. Disease registries: • Curated, condition-specific longitudinal datasets (e.g., oncology tumor registries, rare-disease natural history registries) • Often already partially structured and consented for research use at collection time
4. Patient-generated / wearable data: • Continuous glucose monitors, activity trackers, patient-reported outcome (PRO) instruments • Newest category with least-standardized provenance tooling
Lineage identifier assignment: • At the moment of ingestion, each incoming record (or record batch) is assigned an immutable lineage ID — a UUID or content-derived hash — that will be carried through every downstream transformation, never reused, never reassigned • A lineage manifest records: source system identifier, ingestion timestamp, record count, source data format/version, and a cryptographic hash of the raw payload as ingested (before any transformation) — this raw-ingestion hash becomes the anchor against which every later claim about the record's history can be verified • Critically, the lineage ID is distinct from any patient identifier: it identifies the DATA RECORD'S JOURNEY through the pipeline, not the patient — patient identifiers are stripped or pseudonymized starting at the very next stage
De-identification is the pivotal transformation that converts protected health information into data eligible for broader marketplace distribution — but a marketplace built for auditability treats de-identification itself as an event to be logged and verified, not a black box. Downstream licensees and regulators need to know not just THAT data was de-identified, but WHICH standard was applied, by WHOM, and WHETHER the transformation can be independently checked against the applicable methodology.
HIPAA (45 CFR §164.514) recognizes two distinct de-identification methodologies, and a marketplace's audit log must record which one was applied to any given dataset, because they carry materially different residual re-identification risk profiles:
1. Safe Harbor method (§164.514(b)(2)): • Removes 18 specified identifier categories: names, geographic subdivisions smaller than state (with a partial ZIP-code exception for areas >20,000 population), all elements of dates (except year) directly related to an individual including birth date and admission/discharge dates, telephone/fax numbers, email addresses, SSNs, medical record numbers, health plan beneficiary numbers, account numbers, certificate/license numbers, vehicle identifiers, device identifiers, URLs, IP addresses, biometric identifiers, full-face photos, and any other unique identifying number/code • Mechanical, rule-based — easy to audit: the log can record exactly which fields were nulled, truncated, or generalized • Known limitation: does not address re-identification risk from unusual combinations of remaining fields (e.g., a rare diagnosis + rural ZIP3 + unusual age)
2. Expert determination method (§164.514(b)(1)): • A qualified statistical expert applies generally accepted methods to conclude the risk that the information could be used, alone or in combination with other reasonably available information, to identify an individual is "very small" • Requires a documented risk assessment: the expert's methodology, the reference population used to estimate re-identification risk, and the resulting risk figure (commonly targeting <0.04% re-identification probability) must all be attached to the lineage record • More flexible — permits retaining more granular fields (e.g., full dates, finer geography) when statistically justified, valuable for RWE studies needing temporal precision
Audit log entry for a de-identification event records: • Method applied (Safe Harbor or expert determination) and, for expert determination, a reference to the signed statistical certification • Pre-transformation schema hash and post-transformation schema hash — allows any auditor to confirm exactly which fields were altered without needing access to the underlying PHI itself • Identity of the de-identification pipeline/service version that performed the transformation (supports reproducibility and later methodology audits) • This event becomes lineage hop #2 in the chain first anchored at ingestion (Stage 1)
The defining auditability feature of a well-built RWD marketplace is granularity: it logs not merely "Company X licensed Dataset Y," but every individual query executed against that dataset — the specific filter criteria, the fields requested, the timestamp, and a cryptographic hash chaining that event to the one before it. This query-level granularity is what makes retroactive detection of policy-violating secondary use possible.
Each query submitted to the marketplace's governed access interface generates a log entry containing:
• Requester identity: the licensed analyst or institution account, authenticated via the marketplace's identity provider — never anonymous access • Query specification: the exact filter/cohort criteria, requested fields, and any statistical operation (count, mean, regression) — for query-based (not raw-export) access models, the actual SQL/API call is captured verbatim • Dataset and license reference: which licensed dataset was queried and under which specific license agreement (purpose, indication scope, expiration date) • Timestamp: to millisecond precision • Result cardinality: how many underlying records contributed to the returned result (supports minimum-cell-size / small-cell suppression enforcement, typically n≥5 or n≥11 depending on data sensitivity) • Entry hash: SHA-256 hash of the above fields concatenated with the hash of the PRECEDING log entry — this hash-chaining (the same structural pattern used in blockchain block-linking) means altering or deleting any historical entry breaks the chain's internal consistency in a way any auditor can detect by recomputing hashes forward from a known-good anchor point
Why per-query (not per-checkout) logging matters: • A per-dataset-checkout log only tells you a license was granted; it cannot distinguish appropriate use from scope creep • Per-query logging lets pattern-analysis tools detect, for example, an analyst licensed for "oncology indications only" submitting queries that filter on cardiovascular diagnosis codes — a scope violation invisible at the checkout level • It also supports precise usage-based billing common in RWD marketplace commercial models, where fees scale with query volume/complexity rather than flat dataset access fees
License scoping is itself a machine-readable object attached to each dataset listing: purpose limitation (e.g., "post-marketing safety surveillance"), therapeutic area restriction, permitted output types (aggregate statistics only vs. patient-level extract), and a hard expiration date after which further queries are automatically rejected by the access layer rather than merely being a contractual violation to be discovered later.
When RWD-derived analysis is intended to support an FDA regulatory decision — a new indication, a label expansion, or post-marketing safety commitment — the bar for lineage documentation rises substantially. FDA's Real-World Evidence (RWE) Framework, mandated by the 21st Century Cures Act (2016) and issued in December 2018, requires sponsors to demonstrate both the RELIABILITY (data quality, completeness, provenance) and RELEVANCE (fitness of the data for the specific regulatory question) of any RWD source — and both depend directly on the completeness of the lineage chain built in Stages 1-3.
FDA's RWE Framework (Dec 2018), building on the mandate in the 21st Century Cures Act §3022, articulates the standard sponsors must meet when submitting RWE to support a regulatory decision:
Data reliability assessment addresses: • Data accrual: how the data was collected, including whether collection methods were consistent and complete across sites/time • Assurance of data quality: whether the source system had adequate quality-control processes (e.g., structured EHR fields with validation vs. unstructured free text requiring NLP extraction, which carries higher error risk) • Provenance: FDA explicitly expects sponsors to be able to trace data from original collection through any curation, linkage, or transformation step to the analysis dataset — this is precisely the lineage chain built starting at Stage 1 ingestion
Data relevance assessment addresses: • Availability of key data elements needed to answer the specific study question (e.g., exposure timing, outcome ascertainment, relevant confounders) • Adequate representation of the population and clinical setting relevant to the intended labeling change • Sufficient sample size and follow-up duration for the endpoint being evaluated
Reconstructing the full lineage chain for a submission dossier: • Every lineage hop recorded since Stage 1 (raw ingestion hash) through Stage 2 (de-identification method and schema-hash pair) through every Stage 3 query/extraction/linkage event that contributed to the final analysis dataset must be assembled into a single, auditable provenance record • Record linkage steps (e.g., probabilistic matching of a patient across an EHR source and a claims source using non-identifying quasi-identifiers) are especially scrutinized: FDA reviewers want documented match rates, false-linkage risk estimates, and the specific linkage algorithm/parameters used • Any manual curation or data-cleaning step (e.g., outlier exclusion, unit standardization) must be logged with the rule applied and the number of records affected — undocumented manual edits are a common cause of FDA information requests during RWE-supported submission review • The complete package allows an FDA reviewer to trace any single value in the final analysis dataset backward through every transformation to its original source record — the same tamper-evident hash-chain structure built for commercial marketplace auditability (Stage 3) directly satisfies this regulatory traceability requirement
Because the query-level, hash-chained access log (Stage 3) and the transformation-level lineage manifest (Stage 2) are both immutable and independently verifiable, a marketplace built for commercial auditability largely already satisfies FDA's RWE reliability/provenance documentation burden — regulatory-grade lineage is not a separate system, it is the same audit infrastructure examined at finer grain and assembled into a submission-ready package.
The final safeguard in an auditable RWD marketplace is independent oversight: regulators, institutional compliance officers, and third-party auditors are granted structural read-only access to the complete hash-chained log — never write access to either the underlying data or the log itself, preventing even a well-intentioned administrator from retroactively editing history. Automated pattern-detection continuously scans this log for the signatures of policy-violating secondary use.
Structural read-only access: • Regulators and auditors authenticate through a distinct credential class that is architecturally restricted to read/query operations against the log store — the permission model enforces this at the infrastructure level (e.g., a database role with SELECT-only grants, or a separate read-replica with no write endpoint exposed), not merely through application-level UI restrictions that a determined actor could bypass • This separation matters specifically because it means no single actor — including the marketplace operator itself — can unilaterally alter historical log entries without the tamper-evidence of the hash chain (Stage 3) immediately surfacing the inconsistency to every auditor with read access • Auditors can independently recompute the hash chain from a known-good anchor (e.g., the ingestion hash from Stage 1) forward through every logged event to verify no entry has been altered or deleted
Detecting policy-violating secondary use — common signatures:
1. Re-identification attempt patterns: • A sequence of queries that progressively narrows a cohort filter (e.g., repeated queries adding one more quasi-identifying field each time — age, then ZIP3, then rare diagnosis) until the returned cell size approaches 1, suggesting an attempt to isolate a specific individual • Automated detection: flag any query sequence from a single requester where result cardinality trends toward the minimum-cell-size floor across successive related queries
2. Purpose/scope creep: • Queries filtering on data fields or clinical domains outside the license's stated therapeutic area or purpose (the oncology-license-querying-cardiovascular-codes example from Stage 3) • Automated detection: cross-reference each query's field/diagnosis-code filters against the license's declared scope taxonomy; flag mismatches for compliance review
3. Post-expiration access: • Any query timestamp falling after a license's recorded expiration date should be structurally impossible (the access layer should reject it), but logging the attempt itself — including rejected attempts — is essential audit evidence distinguishing an honest oversight from a deliberate circumvention attempt
4. Volume/velocity anomalies: • A sudden spike in query volume or a shift toward bulk/patient-level extraction from an account previously making only aggregate-statistic queries can indicate credential compromise or an undisclosed change in intended use
Investigation workflow: flagged events generate a case record visible to both the marketplace compliance team and the relevant regulator/auditor account; typical governance policies commit to initial triage within 24-72 hours, with confirmed violations resulting in license suspension, mandatory data destruction attestation from the offending party, and — for the most serious cases such as confirmed re-identification attempts — referral to the applicable regulator (e.g., HHS Office for Civil Rights for HIPAA violations).
The core design principle is separation of duties enforced by architecture, not policy alone: the party being audited (marketplace operator, data licensee) structurally cannot write to or erase the record an independent regulator relies on, and the hash chain makes any attempted tampering mathematically detectable rather than merely against the rules.