Privacy-preserving discovery for retrospective medical research. EU/EEA-first. The data never moves.
Everything shown here was produced against a synthetic development environment. No real patient data was used, at any point, in any asset in this repository. MedBridge has no approved real-data path today.
MedBridge is a research discovery platform. It is not a medical device, not clinical decision support, not a patient-recruitment tool, and not certified against GDPR, EHDS, or any other regulation. It supports governance; it does not certify it.
A researcher wants to know whether a question is even answerable: are there enough people, across enough hospitals, with this combination of conditions, to make this study worth designing?
Today, finding out takes months. Each hospital holds its own records. There is no lawful, practical way to ask all of them one question. So the researcher writes to each site, negotiates separately, waits — and often discovers at the end that the answer was no. The study never happens. Not because the method was wrong, but because access is the bottleneck, and the feasibility question is gated behind the same process as the full study.
The instinct is to build a central database. That instinct is the problem. Pooling patient records from many hospitals into one system creates exactly the concentration of risk that data-protection law exists to prevent — and it makes every hospital's lawyers, correctly, say no.
Send the question to the data. Never bring the data to the question.
MedBridge coordinates a network of institution-controlled nodes. Each hospital keeps its own records, inside its own network, under its own policy. A query travels outward as a signed, replay-resistant envelope. What comes back is a disclosure-controlled aggregate — and only if that hospital's own policy engine agreed, independently, to answer.
The central control plane holds organizations, users, public dataset metadata, research projects, versioned cohort definitions, applications, decisions, permits, and privacy-protected aggregates.
It holds no direct patient identifiers, no raw clinical documents, no patient-level candidate lists, no document snippets, no clinical embeddings, and no re-identification keys. Not "by policy" — by architecture, enforced in code, in the database, in the network topology, and in a test suite that fails the build if a control-plane service can so much as resolve the institution's search index.
Most systems treat an approval as a key: once you hold it, the door opens. Here, a central authorization decision is only the first of two. The institution node evaluates its own local policy independently and can refuse what the centre allowed. Rights are the intersection of the permit, the dataset terms, the purpose, and the node's own rules — never their union.
Revocation, expiry, loss of affiliation and failed attestation all fail closed, and propagate within a bounded time the test suite asserts.
An AI can turn "adults admitted with heart failure who were on a beta blocker" into a computable cohort definition — and that is genuinely useful, because writing one by hand is slow and error-prone.
But the model emits only a closed grammar: a vendor-neutral cohort DSL, compiled to bound parameters. It never emits SQL. It never emits code. Nothing the model produced executes until an authorized human confirms it, and the confirmation is what creates the versioned definition. What the model guessed is recorded next to what it was told.
Real patient text is never sent to an external model API.
This is the detail that most systems get wrong, and it matters more than it looks.
If a hospital suppresses a count because it was too small to release safely, and the
interface renders that as 0 or an empty cell, the researcher records a false negative —
and the platform caused it. So MedBridge keeps four states distinct, in four different words:
an approximate figure, withheld — too small to release, no figure returned, and did
not answer.
And it refuses to show a combined total. With per-site figures on the page, a subset total puts every withheld cell exactly one subtraction away. Withholding the total is what makes showing the per-site figures safe at all.
Here is what that actually looks like in the product — five sites, five outcomes, no blanks and no zeros:
Suppression and rounding are called suppression and rounding — never "differential privacy", and never "anonymised". Where a formal mechanism is specified, it carries its neighbouring relation, privacy unit, contribution bounds, epsilon, delta and an accountant, and the design note lists the proof obligations that remain open rather than claiming they are closed.
A count is meaningless without knowing which definition version produced it, which terminology release it was bound to, which sites answered, and what disclosure control was applied. All four travel with the number, in the same frame — because a caveat in a footnote is a different reading task, and the reader who skips it is the reader who subtracts two figures.
Custodians, coordinators, reviewers, decision bodies, output reviewers and auditors work in a separate application, on a separate origin, with its own session cookie, its own content security policy and its own form secret. A token minted on the researcher origin is useless there. The separation is architectural, not a role check on a shared page.
Access is layered into four tiers. Each is a separate authorization decision — nothing is inherited by seniority, and a lower tier may never return a higher-tier object.
| Layer | Choice |
|---|---|
| Web | TypeScript · Next.js · two separate origins · WCAG 2.2 AA target |
| Control plane | TypeScript · NestJS-style modular monolith — not a microservice per entity |
| Institution services | Python · FastAPI — OMOP CDM v5.4 research store, read-only query role |
| Authoritative data | PostgreSQL · append-only, versioned domain records |
| Policy | OPA / Rego · signed, versioned bundles · deny by default |
| Workflows | Temporal · durable application and provisioning flows |
| Identity | OIDC federation · server-side sessions · phishing-resistant step-up |
| Audit | Append-only, hash-chained, with signed Merkle anchors |
| Telemetry | OpenTelemetry with strict attribute allowlists |
| Deployment | OCI · Kubernetes · Helm · OpenTofu — topology enforced as a contract |
32 architecture decision records. 31 operational runbooks. A threat model covering trust zones, adversaries and abuse cases — plus dedicated threat models for disclosure, for narrative text, for the assistant, and for the frontend. A traceability register in which every requirement is a claim that must resolve against the working tree, so a deleted test that a governance document still cites becomes a build failure rather than a stale sentence.
| Not this | Why that matters |
|---|---|
| A clinical decision-support system or medical device | No output is intended to inform the care of an identified patient |
| A diagnosis, triage, or treatment tool | Out of intended use; it would change the regulatory class |
| A patient-recruitment or trial-matching tool | Requires a different legal basis and consent model entirely |
| A data broker or bulk export service | No tier permits unrestricted download. Not even Tier 3. |
| An autonomous ethics or access-approval decider | Permits and decisions come from authorized humans, always |
| A compliance certification | It supports governance. It does not certify it. |
There is one more, and it is the honest one: no phenotype in this system is clinically validated. The single model card describes one narrow synthetic phenotype, with its metrics, its uncertainty intervals, its scope and its limitations stated outright. Presenting it as a clinical capability would be false.
| Asset | What it is |
|---|---|
| Trust boundary | The three planes and what may cross between them |
| Discovery tiers | Tiers 0–3, what each returns, what gates it |
| Researcher journey | Question to released output, with the human decisions marked |
| Federated query | Four kinds of answer, and the total that is withheld |
| Screenshots | Eight interface states, annotated — including the four the product refuses to collapse |
| Video storyboard | Shot list, timings, and the narration script |
| How it works | The technical overview behind this page |
Diagram sources are committed beside their output. Everything here is reproducible from the main repository.
An advanced, working prototype developed against a synthetic environment, with the trust boundary enforced and tested end to end.
Built and tested: the dataset catalogue with EHDS alignment · reproducible terminology and concept sets · the cohort DSL, typed IR and compiler · the federated query protocol · local disclosure control and a composing privacy ledger · narrative extraction with source-span provenance · the research-question assistant · the governed access application workflow · signed permits and entitlements · the secure-environment boundary and output release · both web origins · the infrastructure contract · the verification register.
Deliberately not built: provisioning against a real cloud, and any real-data ingestion path. Both stop at the boundary on purpose.
The implementation repository is private. For access, a technical walkthrough, or a conversation about deploying this in a research network:
Manuel Dellabona — manuel.db02@gmail.com
© 2026 Manuel Dellabona. All rights reserved.
Synthetic data only — no real patient data was used in any asset in this repository.