🌐 Federated Health Data Marketplace Pricing Model

Compute-to-Data — Selling Query Access, Not Datasets

The dominant failure mode of health-data marketplaces has always been the same: to sell data, you first have to copy it, and copying protected health information across institutional and jurisdictional boundaries triggers HIPAA, GDPR, and local health-data-sovereignty law simultaneously. Compute-to-data inverts the transaction: the buyer never receives a row of patient data. Instead, an approved analysis — a SQL aggregate, a federated model training round, a statistical test — is shipped to the data, executed inside the custodian's own trusted research environment (TRE), and only the output (an averaged, disclosure-checked result) leaves the perimeter.

• Compute-to-data: Model (query travels, data does not)
• OWKIN, Health-RI: Reference platforms (federated oncology / NL national TRE)
• GDPR Art.6/9 + TRE: Legal basis (no personal data export event)
• Minutes–hours: Typical query latency (batched against TRE compute queue)

Architecture of a compute-to-data health marketplace

Core components:

1. Data custodian nodes: hospitals, biobanks, national registries. Each runs a Trusted Research Environment (TRE) — an isolated compute enclave (e.g. UK Secure Data Environments, French Health Data Hub, Dutch Health-RI federated node) where analysis code executes against local data but cannot exfiltrate it directly.

2. Federated query broker: a marketplace layer that catalogs available datasets (schema, cohort size, coverage — NOT the underlying records), receives buyer requests, translates them into containerized analysis jobs, and routes them to the relevant custodian nodes.

3. Output disclosure control: before any result leaves the TRE, an automated statistical disclosure control (SDC) step checks it against small-cell suppression rules (e.g. any cell/count <5 patients is suppressed or noised), preventing re-identification via query result inspection even though no raw data crossed the boundary.

4. Buyer-side consumption: buyers (pharma R&D, academic researchers, payers) receive only the aggregate statistic, trained model weights, or model gradient — never patient-level extracts.

Why this matters economically: Traditional data-licensing deals require a one-time bulk transfer priced as a lump sum, heavily discounted for legal risk and requiring years of DUA (data use agreement) negotiation. Compute-to-data converts data access into a metered SERVICE — priced per query, per model-training round, or per unit of statistical utility extracted — enabling far more granular, repeatable, and legally tractable monetization aligned with actual usage rather than one-off bulk risk transfer. OWKIN's federated oncology network and Health-RI's national health data infrastructure in the Netherlands are both built on this compute-to-data premise, coordinating dozens of hospital nodes without ever centralizing patient records.

Shapley-Value Pricing — Paying Each Institution Its Fair Marginal Contribution

When a federated model or aggregate statistic is built jointly from several hospitals' data, a hard fairness question arises: how should the resulting revenue be split among contributors whose datasets differ wildly in size, quality, and rarity of covered conditions? The Shapley value, a solution concept from cooperative game theory (Lloyd Shapley, 1953), answers this rigorously — it is the unique allocation satisfying efficiency, symmetry, and additivity, and in data marketplaces it is computed as each participant's average marginal contribution to model performance across all possible orderings in which participants could join the coalition.

• Shapley 1953: Origin (cooperative game theory, Nobel 2012)
• Efficiency, symmetry, null player, additivity: Fairness axioms (uniquely satisfying allocation)
• O(2ⁿ): Exact computation cost (n = number of data-holding nodes)
• Monte Carlo / TMC-Shapley: Practical approximation (sampled coalition permutations)

Computing Shapley values for federated data contribution

Formal definition: For a set N of n data-holding institutions and a value function v(S) — e.g., validation accuracy (or log-likelihood, C-index, AUROC) of a model trained on the union of data from coalition S ⊆ N — the Shapley value for institution i is:

φ_i = Σ_{S⊆N\{i}} [ |S|!·(n−|S|−1)! / n! ] · [ v(S∪{i}) − v(S) ]

In plain terms: average, over every possible order in which institutions could sequentially contribute their data, the marginal improvement institution i's data adds at the moment it joins.

Why exact computation is intractable: Evaluating v(S) requires actually retraining/evaluating the model on every subset S — 2ⁿ subsets for n institutions. Beyond n≈15–20 nodes this is computationally infeasible, so practical federated marketplaces use:

• Monte Carlo Shapley: randomly sample permutations of institutions, compute marginal contributions along each sampled order, average — converges to true Shapley value with enough samples (typically a few thousand permutations for stable estimates).

• TMC-Shapley (truncated Monte Carlo): stop evaluating a permutation early once marginal contributions become negligible (model performance plateaus), cutting compute substantially — the method used in Ghorbani & Zou's "Data Shapley" (ICML 2019), the foundational paper applying Shapley values to data valuation.

• Group testing / gradient-based Shapley approximations: for federated learning specifically, contribution can be approximated from each client's gradient norm and update direction each training round rather than full retraining — much cheaper, used in production federated systems.

Interpretation in a health-data marketplace: A large general hospital contributing a common-condition cohort might have LOW marginal Shapley value (redundant with other large contributors), while a small specialist center holding a rare-disease registry can have disproportionately HIGH Shapley value — its data is irreplaceable for that query, even though its raw row count is small. This is precisely the pricing signal a naive "pay per row" or "pay per patient" model misses, and why Shapley-based marketplaces route more revenue to rare, non-redundant cohorts than volume alone would suggest.

The Privacy Budget as a Metered, Priced Resource

Differential privacy (Dwork et al., 2006) guarantees that the presence or absence of any single patient's record changes a query's output distribution by at most a bounded factor governed by the parameter ε (epsilon) — smaller ε means stronger privacy but noisier answers. Because the DP composition theorem states that privacy loss accumulates across successive queries on the same dataset, every institution's dataset effectively has a finite, depletable privacy budget. A federated marketplace must price ε consumption explicitly, or it will be exhausted by the first few buyers, locking out everyone else.

• Dwork et al. 2006: DP origin (foundational cryptography/TCS paper)
• ε = 1 – 10: Typical health ε budgets (per dataset per release cycle (e.g. annual))
• ε_total = Σ εᵢ: Composition (basic) (sequential composition theorem)
• √(2k ln(1/δ))·ε: Composition (advanced) (tighter bound, Dwork-Rothblum-Vadhan)

Pricing mechanics for a depleting differential-privacy budget

Mechanism basics: A differentially private mechanism M satisfies (ε, δ)-DP if for any two datasets D, D′ differing in one record, and any output set S: Pr[M(D) ∈ S] ≤ e^ε · Pr[M(D′) ∈ S] + δ

Smaller ε → stronger indistinguishability → more injected noise (typically Laplace or Gaussian mechanism, calibrated to query sensitivity Δf) → lower statistical utility per query.

Why ε must be priced, not given away free: Each dataset custodian sets a total privacy budget ε_total (e.g., ε=10 per year) reflecting their institutional risk tolerance. Basic sequential composition means every released query with privacy loss εᵢ consumes from this pool irreversibly: ε_total = Σ εᵢ. Once exhausted, NO further queries can be answered on that dataset until the budget resets (e.g., annually) — a hard technical constraint, not a policy suggestion. This scarcity is precisely what makes ε an economic good requiring market pricing rather than free allocation.

Pricing dimensions: • Query "cost" in ε is proportional to sensitivity Δf (how much one record can change the output) divided into the noise scale — a simple COUNT query has low sensitivity (cheap in ε); a MAX or a fine-grained subgroup query on a rare condition has high sensitivity (expensive in ε). • The marketplace converts ε-cost into a monetary price via a posted tariff or dynamic auction (Stage 4): price(query) = base_rate × ε_consumed × scarcity_multiplier(remaining_budget). • A scarcity multiplier rises as remaining ε_total falls — the last 10% of a dataset's annual privacy budget is priced far higher than the first 10%, reflecting its true opportunity cost to all FUTURE buyers who will be locked out.

Advanced composition and budget stretching: Using the advanced composition theorem (Dwork, Rothblum, Vadhan 2010) or Rényi differential privacy (RDP) accounting, a curator can answer more queries for the same total privacy loss than naive linear summation would allow, because worst-case linear composition is pessimistic. Production systems (e.g., Google's RAPPOR, Apple's differential privacy deployments, and academic health-DP platforms) use RDP or zero-concentrated DP (zCDP) accountants to track budget more precisely — directly increasing the number of billable queries a dataset can sustain before exhaustion, which is itself a revenue-relevant engineering choice.

Auction Mechanisms for Scarce Compute-to-Data Query Slots

With a hard privacy budget constraint and multiple competing buyers, the marketplace faces a classic mechanism-design problem: allocate scarce ε (and compute) to the buyers who value it most, without giving anyone an incentive to misrepresent their true valuation. Sealed-bid, incentive-compatible auctions — most notably the Vickrey-Clarke-Groves (VCG) mechanism — are the standard theoretical tool, adapted here so that the "good" being allocated is a bundle of statistical utility per unit of consumed privacy budget rather than a physical item.

• VCG / 2nd-price sealed-bid: Mechanism family (dominant-strategy truthful)
• ε-slot × compute slot: Allocated good (bundled scarce resource)
• Continuous double auction: Alternative (buyers & sellers both post orders)
• Incentive compatibility: Design goal (truthful bidding is optimal strategy)

Designing a truthful auction over privacy-budget-constrained queries

Why a naive posted-price tariff underperforms: A fixed price-per-ε tariff either underprices scarce budget near depletion (leaving value on the table, first-come-first-served favoring fast/automated buyers over high-value ones) or overprices it early (deterring legitimate low-budget academic use). An auction lets the market discover the true clearing price dynamically as remaining ε_total shrinks.

VCG mechanism applied to compute-to-data: 1. Each buyer j submits a sealed bid bⱼ representing willingness-to-pay for a specific query bundle (query type, target dataset(s), required ε consumption εⱼ). 2. The auctioneer (marketplace broker) selects the allocation maximizing total reported value subject to the constraint Σ εⱼ ≤ ε_remaining for each dataset — a knapsack-style optimization since ε is now the constrained "capacity." 3. Each winning buyer pays not their own bid but the externality they impose on others — the VCG payment rule — which makes truthful bidding a dominant strategy: no buyer benefits from bidding above or below their true value. 4. Losing bidders pay nothing and can resubmit against the next epoch's refreshed ε budget.

Practical variant — continuous double auction (CDA): Some federated marketplaces instead run a CDA: data custodians post ASK prices for slices of their remaining ε budget, buyers post BID prices for queries, and the exchange matches compatible bid/ask pairs continuously, similar to a stock exchange order book. This is computationally simpler than full VCG and more transparent to institutional data-governance boards, at some cost to strict incentive-compatibility guarantees.

Revenue split back to Shapley shares: Once a query bundle clears (Stage 4) and later executes and settles (Stage 5), the clearing price is NOT simply handed to a single "data owner" — for multi-institution federated queries, it is split among contributing nodes according to their Shapley value computed for that specific query (Stage 2), so the auction sets the TOTAL price and Shapley valuation sets its INTERNAL distribution.

Settlement, Disclosure Control, and the Provenance Ledger

A cleared, auctioned query is not yet a completed transaction — it must still execute safely inside the custodian's TRE, pass output disclosure checks, and settle payment to potentially several institutions simultaneously via their Shapley allocations, all while producing an audit trail regulators can inspect under GDPR's accountability principle (Article 5(2)) and equivalent national health-data governance frameworks such as Health-RI's federated consortium rules.

• Small-cell suppression: Disclosure control (typically n<5 masked/noised)
• Hours – days: Settlement latency (post query execution + SDC check)
• GDPR Art. 5(2): Audit requirement (accountability principle)
• Query + ε debit + payout log: Ledger function (immutable, regulator-inspectable)

From cleared auction to settled, auditable transaction

Execution and output airlock: Once a bid clears, the query container executes inside the custodian TRE against local data. Before any number crosses the boundary, an automated statistical disclosure control (SDC) layer applies rules such as: minimum cell size (suppress any subgroup count below a threshold, typically 5–10 patients), rounding/noise injection consistent with the query's allocated ε, and dominance checks (preventing one patient from dominating an aggregate, e.g. in a mean of very few records). Only after passing SDC does the result leave the TRE to the buyer.

Multi-party settlement: For queries spanning several institutions, payment settles as: total_clearing_price × Shapley_share_i for each contributing institution i, net of marketplace operating fees. This requires the settlement layer to hold both the auction outcome (Stage 4) and the Shapley computation (Stage 2) for the SAME query instance, since contribution shares can differ query-to-query depending on which institutions' data was actually informative for that specific analysis.

Provenance ledger and regulatory audit: Every transaction — query specification, dataset(s) touched, ε consumed per dataset, disclosure-control decisions, clearing price, and per-institution payout — is appended to an immutable provenance ledger (a permissioned blockchain or an append-only signed log, architecturally similar to the audit-trail pattern used in patient-controlled-record systems). This log satisfies GDPR Article 5(2) accountability obligations and gives national infrastructure bodies like Health-RI, or consortium governance boards like OWKIN's federated network, the ability to demonstrate — on demand — exactly which analyses ever touched which datasets, how much privacy budget was spent, and where every euro of resulting revenue went.

The key economic property of this pipeline is that price signals flow in BOTH directions: the auction (Stage 4) discovers how much a query is worth to buyers given scarce ε, while Shapley valuation (Stage 2) discovers how much each byte of that value is worth to each contributing institution. Neither number is derivable from the other — a marketplace needs both a demand-side clearing mechanism and a supply-side fairness allocation to be economically viable and legally defensible at once.