A child presents with an undiagnosed condition. Whole-exome sequencing returns a candidate variant of uncertain significance in a gene with no published phenotype. The institution's clinical team has seen this variant once before — in a patient whose outcome is sitting in a records system with no mechanism to reach anyone else working the same problem.
Two institutions in different countries have each independently identified three patients with this variant. Their treatment responses are documented. Neither institution knows the other exists in this context. The gap between them is not a privacy problem and not a regulatory problem. It is an architecture problem.
The Matchmaker Exchange (MME) was built to solve the first half of this problem: finding institutions that have seen the same phenotype, so the diagnostic question can be resolved. It is a serious, deployed, GA4GH-standardized system, and it works. What it was not designed to solve is what happens next: routing the treatment outcome intelligence — what those matched patients' care trajectories looked like — back to every similar case in real time, without centralizing patient records.
Christopher Thomas Trevethan discovered an architecture for that second problem on June 16, 2025, now called the Quadratic Intelligence Swarm (QIS) protocol, with 39 provisional patents filed. This article examines the MME architecture honestly, identifies its structural scope, and then explains what QIS does in the space MME was not designed to cover.
Section 1: What Matchmaker Exchange Does (and Why It Matters)
The Matchmaker Exchange is not a single database. It is a federated network of rare disease patient matching platforms connected by a standardized API — the MME API, developed under the Global Alliance for Genomics and Health (GA4GH). The participating nodes include PhenomeCentral, MyGene2, DECIPHER, GeneMatcher, ClinVar, and more than a dozen other institutional repositories.
The canonical paper is Philippakis et al. (2015), "The Matchmaker Exchange: A Platform for Rare Disease Gene Discovery," Human Mutation 36(10). The core architecture: a clinician submits a phenotype-genotype query — typically a set of HPO (Human Phenotype Ontology) terms plus candidate gene identifiers — and MME routes that query to participating nodes. Nodes return potential matches: patients with similar phenotypic profiles and overlapping genetic variants. The matching clinicians then connect directly to discuss the case.
MME has been operationally successful. A 2020 survey of MME participating teams found that cross-institutional matches via the network contributed to the discovery or confirmation of novel disease-gene associations in over 180 publications. For ultra-rare conditions where a single institution may see one or two qualifying patients per decade, the ability to find a clinician on another continent who has seen the same presentation is not incremental improvement — it is the difference between a diagnosis and a lifetime of uncertainty.
The architecture that makes this work:
- Phenotype standardization via HPO. The Human Phenotype Ontology gives clinicians a controlled vocabulary to describe presentations. This makes cross-institutional phenotype queries possible — a symptom described in Boston maps to the same ontology term as the same symptom described in Amsterdam.
- Federated query routing. MME does not centralize patient records. Queries travel to nodes; nodes return controlled match responses. The architecture respects institutional data governance.
- Clinician-to-clinician match confirmation. After a potential match is surfaced, the two clinical teams connect directly. The system facilitates the introduction; it does not automate the clinical judgment.
- GA4GH standardization. The MME API is a published standard. New nodes join by implementing the API, not by migrating data to a central repository. Network growth does not require central coordination.
For the rare disease genomics audience specifically: MME and the broader Beacon network (also GA4GH-standardized, for variant-level queries) are the current infrastructure. They are in production deployment, they have institutional adoption, and they have published diagnostic yield evidence.
What follows is not a criticism of MME's design. It is an examination of the scope boundary MME was designed to operate within — and the problem space beyond that boundary.
Section 2: Where MME's Architecture Stops
MME solves the phenotype-matching problem for rare disease diagnosis. The scope boundary is explicit in how the system was designed: a query returns a list of potential phenotype-genotype matches, and then clinicians talk to each other. What happens in that conversation, what treatment decisions result, and what outcomes those decisions produce — none of that flows back into the network.
This is not a flaw. MME was built to answer: does another institution have a patient with this presentation? It was not built to answer: across all institutions that have seen this presentation, what treatment pathways produced the best outcomes?
The structural limits that follow from this scope:
Treatment outcome intelligence does not compound. Each time a matched patient's care trajectory resolves — a treatment worked, a treatment failed, a side effect emerged at a specific dosage — that outcome is documented in the originating institution's clinical records. The MME query that found the match does not capture that outcome. The network does not update. The next institution asking the same phenotype-matching question gets the same list of potential matches but no information about what happened to those patients after the connection was made.
Queries are point-in-time. An MME query is a snapshot: who has seen this variant today? The network does not emit alerts when a matched patient's status changes, when a new treatment response is documented, or when a previously uncertain variant achieves functional confirmation at another site. Continuous real-time synthesis is outside the architecture.
The N=1 site problem persists. MME's matching value increases with more matches. An institution that has seen only one patient with a given variant can still submit a query, but the quality of the match depends on the density of similar cases across the network. For the rarest diseases — conditions where the total global prevalence is measured in dozens of patients — the match pool is thin by definition. Treatment outcome synthesis across a thin match pool requires a different mechanism than phenotype-query routing.
Match quality is phenotype-dependent. HPO standardization is good. It is not perfect. Rare disease presentations are notoriously variable, and phenotype misclassification — describing a feature with a higher-level HPO term than the one used at the matching institution — can cause valid matches to be missed. The architecture depends on clinician phenotype encoding quality in a way that makes edge-case misses structurally likely.
These are not criticisms of MME's execution. They are the natural consequences of what MME was designed to do. The question is what architecture handles the next problem in the same workflow.
Section 3: The Workflow Gap — Diagnostic Intelligence vs Therapeutic Intelligence
The rare disease workflow has two distinct intelligence needs:
Problem 1 — Diagnostic: Which institution has seen a patient with this phenotype and candidate variant?
Problem 2 — Therapeutic: Across all institutions that have confirmed this diagnosis, what treatment pathways produce the best outcomes for this patient profile?
MME is built for Problem 1. The gap is Problem 2.
This distinction matters because the two problems have different data structures, different timing requirements, and different network topology demands.
For Problem 1, a query-response model works: a clinician submits a structured phenotype-genotype query, the network returns matches, clinicians connect. The interaction is synchronous, point-in-time, and resolved by a human conversation. The data transmitted is controlled: phenotype terms, variant identifiers, contact information.
For Problem 2, a continuous outcome routing model is needed: every institution that has a confirmed patient continuously emits a distilled treatment outcome signal — what worked, what failed, what dosage, what timeline — and every institution with a new confirmed patient receives the aggregate of those signals in real time, synthesized locally, without the raw records ever leaving the originating site.
These are architecturally different. A query-response system does not become a real-time outcome routing system by adding more queries. The two problems need different primitives.
Section 4: What QIS Does in the Gap
The Quadratic Intelligence Swarm (QIS) protocol, discovered by Christopher Thomas Trevethan, operates on a different primitive: the outcome packet.
The QIS loop: Raw clinical signal → Local processing at the edge node (the institution) → Distillation into a ~512-byte outcome packet → Semantic fingerprinting of that packet → Routing by similarity to a deterministic address → Delivery to relevant edge nodes sharing the same problem → Local synthesis → New outcome packets generated → Loop continues.
For a rare disease network, concretely:
An institution confirms a patient diagnosis matching a specific HPO phenotype cluster and a validated pathogenic variant. Their clinical system generates an outcome packet: treatment pathway, response timeline, dosage, relevant co-morbidities, outcome quality measure. The packet is ~512 bytes — comparable to a well-structured sensor reading. It carries no raw clinical data. No patient identifiers. No records.
That packet is fingerprinted semantically — its content maps to a deterministic address defined by the phenotype cluster and variant category — and deposited to the routing layer. Any routing mechanism that can map a problem to a deterministic address and retrieve deposited packets efficiently works: a DHT-based distributed hash table, a vector similarity index, a pub/sub topic, a shared database. The critical property is that the address is deterministic: any institution working the same phenotype-variant problem queries the same address.
An institution on another continent confirms a patient with the same presentation. Their node queries that address and retrieves the accumulated outcome packets from every other institution that has deposited one. Local synthesis — running on their own infrastructure, never touching a central server — surfaces the aggregate: treatment A worked for 7 of 9 similar cases; treatment B produced adverse responses in 4 of 6; the median time to measurable response for the variant subgroup is 14 days.
The math behind this:
With N institutions participating in a rare disease outcome network, the number of unique synthesis opportunities is N(N-1)/2. That is Θ(N²). Each institution pays only O(log N) routing cost at most — achieving this with an efficient routing mechanism — or O(1) with a database index. The intelligence grows quadratically. The compute does not.
A network of 100 rare disease centers generates 4,950 synthesis pathways. Federated learning requires those same 100 centers to participate in coordinated model training rounds, with gradient aggregation scaling linearly with model size. QIS does not aggregate models. It routes distilled outcome packets. The compute never blows up.
Section 5: Why MME and QIS Are Complementary, Not Competing
This is the structural argument for institutions already operating in the MME ecosystem.
MME finds the match. QIS routes what happened to the match.
The sequencing is clean:
- Institution A has an undiagnosed patient with a candidate variant. They submit an MME query.
- MME returns: Institution B and Institution C have seen the same phenotype-variant combination.
- Institution A connects with B and C. Diagnosis is confirmed.
- Institutions A, B, and C are now enrolled in the same rare disease outcome network. Each begins depositing QIS outcome packets for their patient's care trajectory.
- When Institution D receives an MME match for the same variant six months later, they do not just find out that three other institutions have seen it. They synthesize three patients' worth of treatment outcome intelligence before making a care decision.
The workflow is additive. MME does not need to change. A QIS routing layer sits downstream of the diagnostic match, activated at the point where treatment decisions begin.
This matters for N=1 sites specifically. MME's diagnostic value for ultra-rare conditions is limited by match pool density — if only one other institution has seen the variant, the phenotype match network is thin. QIS's outcome routing value begins the moment the first outcome packet is deposited. Even a single prior patient's treatment response — distilled to 512 bytes and available for synthesis — is more than the zero information currently flowing back through the match network. And as the pool grows from 1 to 10 to 100, the synthesis quality compounds quadratically.
Section 6: The Prior Art Landscape
The distinction from existing approaches is worth being explicit:
MME vs QIS: MME routes phenotype-genotype queries for diagnostic matching. QIS routes treatment outcome packets for therapeutic intelligence synthesis. Different workflow stage, different data primitive, different timing model.
Federated learning vs QIS: Federated learning aggregates gradient updates from distributed model training. It requires sufficient local data volume for meaningful gradient computation — excluding N=1 sites by architecture. QIS does not train models. A single outcome packet is a valid contribution to the routing network regardless of institutional data volume. The foundational paper for federated learning limitations in rare disease is Rieke et al. (2020), "The Future of Digital Health with Federated Learning," npj Digital Medicine 3(119). The N=1 site exclusion problem is structural: federated learning needs enough local data to run a meaningful training round.
Beacon network vs QIS: The Beacon API (GA4GH) answers variant-level presence queries: does your dataset contain a variant at this genomic position? It is designed for variant-level discoverability, not treatment outcome synthesis. The two systems are similarly complementary: Beacon confirms the variant exists at other institutions; QIS routes outcome intelligence for that variant across confirmed cases.
OMOP CDM vs QIS: OMOP standardizes data vocabulary so distributed queries can run against heterogeneous EHR systems. QIS operates at the outcome packet level — the ~512-byte distillate of a local analysis — not at the raw data vocabulary level. OMOP solves the format problem; QIS solves the outcome routing problem. The two work together: an OHDSI node running an OMOP CDM can generate QIS outcome packets from its standardized data without changing its data model.
Section 7: The Three Natural Forces in Rare Disease Networks
Any rare disease outcome routing network instantiates three natural forces that emerge from the architecture. Christopher Thomas Trevethan describes these as Three Elections — metaphors for emergent properties, not engineered mechanisms:
The Hiring Election: Someone defines what makes two rare disease presentations "similar enough" to share outcome packets. This is not a voting mechanism. It is a domain expertise question: who is the best authority on phenotype similarity for this disease category? A specialist in lysosomal storage disorders should define similarity for that network; a clinical geneticist specializing in channelopathies should define it for theirs. The routing quality of the network is determined entirely by the quality of this similarity definition. Get the best expert.
The Math Election: Outcomes elect what works. When 20 similar patients' treatment outcomes are deposited as packets and synthesized locally, the aggregate surfaces what worked across those cases. There is no reputation layer, no quality scoring mechanism, no weighting system required as a protocol feature. The mathematics of aggregation does the work. The outcomes themselves are the votes.
The Darwinian Election: Networks compete on synthesis quality. A rare disease outcome network with a poor similarity definition routes irrelevant packets — clinicians stop using it. A network with expert-defined similarity routes gold. Clinicians migrate toward value. This is natural selection at the network level, requiring no governance overhead.
These are not features to build into the protocol. They are what happens when the loop closes.
The Open Question
An OMOP node in Rotterdam holds oncology outcome data for confirmed rare disease patients. A node in Toronto holds treatment responses for the same variant cluster. A node in Singapore holds three cases with documented adverse reactions to the first-line therapy.
MME can tell each of them the others exist. After the diagnostic connection is made, the treatment outcome intelligence those three institutions hold sits inside their respective records systems with no mechanism to reach the others.
Can an edge node at that Rotterdam institution query a deterministic address — defined by a domain expert to represent that exact variant-phenotype combination — and pull back ~512-byte outcome packets deposited by every other institution that has treated a confirmed patient? Those packets carry what worked, in milliseconds, synthesized locally, without a single raw record leaving any institution.
If it can do that, the architecture works regardless of what routing mechanism is underneath. DHT-based routing, a vector similarity index, a pub/sub topic, a shared database. The mechanism does not matter. The loop does.
That is what the Quadratic Intelligence Swarm protocol is. The routing mechanism is a parameter. The discovery is the complete architecture that closes the loop.
The QIS protocol was discovered by Christopher Thomas Trevethan. 39 provisional patents filed. The architecture is protocol-agnostic: any mechanism that routes outcome packets to semantically similar recipients enables the quadratic scaling property.
Related articles in this series: QIS Protocol vs Personal Health Train | Why N=1 Rare Disease Sites Are Excluded from Federated Learning by Architecture | The OHDSI Network Already Has Everything QIS Needs
Top comments (0)