The problem
Patient privacy keeps training data inside hospital walls, so most clinical models are trained at a single center. A model that has only ever seen one hospital's patients, scanners, and practice patterns may not generalize beyond that institution — and may encode its inequities.
Three questions have no good answer once such a model exists:
- Is it any good? External validation cohorts are hard to reach.
- Is it safe and fair enough to use? No independent review exists, and nobody tells the treating physician, in clinical terms, where the model stops being trustworthy.
- Why start from zero? Another team may already have trained the model, but there is no trusted path to obtain and fine-tune it.
Existing infrastructure addresses parts of this. Model zoos distribute weights but do not review, evaluate, or secure them. Federated benchmarks evaluate but do not govern or track provenance. Federated-learning frameworks orchestrate training but assume every participating site is honest.
Why this has to be a commons
A vendor cannot do it: hospitals will not bet patient care on a registry they are not allowed to inspect. A single hospital cannot do it: none has data from enough sites, and none has the standing to sit in judgment on the others. A federal agency cannot do it: running a shared model repository is daily operational work.
Closing the gap needs three properties at once:
Transparency
The code is open and the review criteria are published, so a decision can be checked rather than trusted.
Neutrality
No single institution controls governance, and no site can certify its own model.
Network effects
Every accepted contribution improves the shared base model for everyone who uses it.
Components
OpenMed is six components: five technical, plus the credit-and-reciprocity mechanism that gives institutions a reason to contribute rather than only consume.
Secure federated co-training
Byzantine-resilient aggregation (coordinate median, trimmed mean, Krum / Multi-Krum, bounded-influence rules) with principled client selection, for sites that choose to train together.
Tamper-evident lineage
An append-only, signed hash chain records every model version, its parent, the attestation of the pipeline that produced it, and the signatures that certified it. Weights and patient data stay on premises. Tamper-evident, not immutable — see scope and limits.
Model registry
Versioned bundles of weights, model card, pipeline attestation, evaluation report, and fine-tuning manual. Derived models auto-link to their parent, so the registry accumulates a lineage graph rather than a flat file list.
Multi-party certification
A model becomes a certified base only when reviewers from more than one institution sign off, enforced as a k-of-n threshold policy over institution-bound keys. Decisions are appended to a signed hash chain, so a retroactive edit is detectable by anyone holding an independent anchor.
Automated quality analysis
A local analysis pass drafts a technical quality report on each submission — model-card completeness, metric sanity, subgroup performance gaps, a membership-inference leakage screen — published alongside the human review. It supplements human review rather than replacing it.
Credit and reciprocity
Citable identifiers and release attribution for accepted models, contributor standing that maps to governance weight, and a reciprocity rule: to receive a multi-site evaluation, a site serves as an evaluator for others.
Threat model
OpenMed assumes mutually distrusting sites, any minority of which may be actively malicious. No site releases raw patient data, and no site is trusted to self-report what code it ran.
| Risk | Control |
|---|---|
| An unapproved or tampered client contributes an update | Attestation gate: every update carries a quote naming the code measurement that produced it. Nonce freshness is available but off by default |
| Poisoned updates from clients that pass attestation | Byzantine-robust aggregation bounds the influence of a malicious minority |
| Version substitution or silent rollback of a published model | Append-only signed chain; verification detects tampering always, and truncation when checked against an anchor |
| A site certifying its own model | Threshold policy requires signatures from distinct institutions; self-certification is refused when the case is opened with the bundle itself |
| A published model leaking its training data | A membership-inference screen in the quality gate — the cheapest known attack, not a privacy guarantee |
Scope and limits
Read this before deploying anything. The reference attestor is a software mock: it demonstrates the protocol and lets the accept/reject logic be tested, but it is not a hardware root of trust and is not a security boundary. Real TEE backends (Intel SGX/TDX, AMD SEV-SNP) plug in behind the same interface.
The ledger shipped in this repository is a local, dependency-free append-only hash
chain. It gives tamper evidence within one deployment; it is not a multi-organization
consensus system, and a permissioned-ledger backend can be added behind the
same LedgerBackend interface but is not shipped. Truncation is detected
only against an anchor, the default signing key is a constant in the source, and a
clean install signs with HMAC rather than Ed25519 — the
security caveats
list every condition in full.
No patient data ships with this project, and none is required to run it. Every example and test generates synthetic cohorts in-process from a fixed seed. See docs/DATA.md for the data policy and the CI check that enforces it.
Where to go next
- Quickstart — install, run the federated demo, publish and certify a model.
- Architecture — how the six components fit together, and the interfaces between them.
- Governance — who decides what, how disputes are resolved, and how the project is licensed.
- Community — how to contribute, what we need help with, and how to reach the maintainers.