You have FHIR. Every major hospital system in the United States has FHIR. The mandate landed, the endpoints went live, the EHR vendors shipped their APIs. As of 2024, over 6,000 US hospitals are running HL7 FHIR-compliant interfaces — and every one of them is an island.
That is the problem no one wants to say out loud: FHIR solved the schema problem completely. It did not touch the routing problem at all.
FHIR Solved the Wrong Half
When ONC mandated FHIR R4 compliance under the 21st Century Cures Act, it was a genuine infrastructure win. Before FHIR, hospital A and hospital B used different data models, different terminologies, different API conventions. After FHIR, they speak the same language. You can query a patient's medication history at Cedars-Sinai using the same GET /MedicationRequest?patient= call you'd use at UCSF.
That is real. That matters.
But here is what FHIR does not do: it does not let Hospital A learn from 300 statistically similar cases at Hospital B without those records ever leaving Hospital B's walls.
Interoperability is not intelligence. You can read each other's data — with appropriate consent and access controls — but you still cannot synthesize across institutions in real time. Every FHIR endpoint is queryable. None of them are learning from their peers.
To see why this is a gap, consider the actual clinical workflow: a hospitalist at a regional medical center in Tucson is treating a 67-year-old diabetic patient with new-onset heart failure and stage 3 CKD — a combination with roughly 11,000 analogous cases spread across US hospital systems right now. Those hospitals have collectively generated meaningful outcome signal: which medication adjustments worked, which diuretic regimens caused deterioration, which lab thresholds triggered poor outcomes.
None of that signal reaches the Tucson hospitalist. Not because of HIPAA (de-identified outcome packets are not PHI). Not because of technical incompatibility (everyone speaks FHIR). Because there is no routing layer. There is no protocol that takes an outcome from Hospital B and delivers it, automatically, to the hospitals treating similar cases.
That is the gap the Quadratic Intelligence Swarm (QIS) protocol fills.
What the Complete Loop Looks Like
QIS is not a database. It is not a federated learning framework. It is not an analytics platform. It is a routing architecture — a protocol layer that sits on top of existing infrastructure (including FHIR) and routes distilled outcome intelligence to the institutions most likely to benefit from it.
The architecture is a loop. Every step matters; removing any single step breaks the system:
FHIR Node (Hospital A)
│
▼
[1] Local outcome extraction
FHIR resource → edge processor
extracts signal: DX codes, treatment
pathway, lab trajectory, outcome flag
│
▼
[2] Distillation
Full record → ~512-byte outcome packet
(no patient identifiers, no raw data)
│
▼
[3] Semantic fingerprinting
Outcome features hashed to address in
shared routing space
│
▼
[4] Routing layer
Packet posted to address = f(fingerprint)
Protocol-agnostic: works over DHT,
vector index, database, API — any transport
│
▼
[5] Delivery to similar nodes
Hospitals with similar fingerprints
query same address space, pull packets
│
▼
[6] Local synthesis
Incoming packets integrated at edge
Raw data from Hospital A NEVER leaves
│
▼
[7] New outcome packets generated
Loop continues — each node gets smarter,
contributes smarter signal
The raw data never leaves the edge. This is privacy by architecture, not privacy by policy. Hospital B does not receive a patient record. It receives a distilled outcome packet — the compressed intelligence of what happened — routed to it because its semantic fingerprint matched.
This architecture was discovered by Christopher Thomas Trevethan on June 16, 2025. IP protection is in place across 39 provisional patents.
Plugging Into FHIR Infrastructure
The routing layer does not require replacing anything in your existing FHIR stack. Consider what FHIR already gives you at each node:
- FHIR Observation resources carry lab values, vitals, clinical findings — exactly the input features for outcome extraction
- FHIR Condition resources carry ICD-coded diagnoses — the primary dimensions of a semantic fingerprint
- FHIR MedicationRequest + MedicationAdministration carry the treatment pathway
- FHIR Encounter + EpisodeOfCare carry the outcome context
A QIS edge node consumes these resources from the local FHIR endpoint — the same endpoint you already expose internally. It extracts the outcome signal, generates the semantic fingerprint, and posts the ~512-byte packet to the routing layer. No bulk export. No central aggregation. No model weights leaving your infrastructure.
For institutions already using FHIR Subscriptions (R4B/R5), the integration surface is even cleaner: subscribe to Observation?code=HbA1c or Condition?code=E11 and feed the notification stream directly into the edge processor. The QIS routing layer activates on top of infrastructure you have already built.
Why Existing Approaches Don't Fill This Gap
This is worth being precise about, because the ecosystem has several approaches that look adjacent:
Federated Learning (FL): FL requires model weights to travel between nodes and requires a central aggregation server to combine gradient updates. It breaks down at small N — a rare disease site with 8 cases cannot contribute meaningful gradient updates. QIS outcome packets, by contrast, are meaningful at N=1. A single outcome from a single institution carries signal; the routing layer ensures it reaches the institutions for whom it is relevant.
SMART on FHIR apps: These are application-layer tools running on top of FHIR. They still require a centralized server to do analytics across institutions. You are back to the data-centralization problem.
HL7 FHIR Bulk Data ($export): This is a batch extraction mechanism. It is excellent for population analytics on a single institution's data. It does not enable real-time cross-institutional synthesis, and it involves moving full datasets rather than distilled outcome packets.
CommonWell Health Alliance / Carequality: These networks solve record access — a clinician at one institution can retrieve a patient's records from another. That is a consent and retrieval problem. QIS solves a different problem: routing synthesized intelligence between institutions that are treating similar cases, without any retrieval of individual records.
None of these are wrong. They solve real problems. They leave the routing problem untouched.
The Math Behind the Opportunity
Here is the number that should stop any FHIR implementer:
For N nodes in a network, the QIS architecture creates N(N-1)/2 synthesis opportunities — every pair of institutions can exchange distilled intelligence about their overlapping case types.
| Hospitals in network | Synthesis opportunities |
|---|---|
| 10 | 45 |
| 100 | 4,950 |
| 1,000 | 499,500 |
| 6,000 (US total) | 17,997,000 |
This is quadratic growth in intelligence capacity — which is where the name comes from. The Quadratic Intelligence Swarm protocol generates Θ(N²) synthesis paths.
The cost to participate does not scale at the same rate. Each node pays at most O(log N) routing cost — the cost of finding relevant peers in the routing layer. In practice, many transport implementations achieve O(1) for well-indexed similarity queries. Compare this to any centralized analytics architecture, where cost scales at O(N) as you add institutions and data volumes grow proportionally.
Right now, 6,000 US hospitals are FHIR-compliant. The theoretical ceiling of their collective intelligence is 17,997,000 active synthesis connections. The actual number of real-time cross-institutional outcome synthesis connections active today: zero.
That gap is not a data standards problem. FHIR already solved the data standards problem. It is a routing problem.
The Global Equity Case
It is worth making the implications explicit for health equity, because this is where the architecture's real impact lands.
A rural clinic in Kenya running a FHIR-compliant EHR — and there are more of these than most US health informaticists realize, thanks to OpenMRS FHIR support and the WHO SMART guidelines initiative — would, under a QIS routing layer, receive the same synthesized treatment outcome intelligence as a Stanford research hospital treating similar cases.
Not a diluted version. Not a delayed batch export. The same routed intelligence, because the routing layer operates on semantic similarity, not institutional prestige or network centrality.
This is not a feature. It is a structural property of the architecture. When routing is based on what a case is rather than who is asking, geography and institutional size drop out of the equation.
Implementation Posture for FHIR Teams
For teams evaluating distributed health data architectures, the practical posture is:
- FHIR is the data layer. Keep building it. R4 compliance is the foundation.
- The routing layer is additive. QIS does not require changes to your FHIR resources, your consent framework, or your existing API surface.
- The edge processor is the integration point. A lightweight service subscribed to your local FHIR endpoint, generating outcome packets, is the full footprint of a QIS node.
- Raw data never moves. The privacy model is architectural: only ~512-byte distilled packets route through the network. No patient identifiers. No raw records.
Full protocol documentation is available at qisprotocol.com.
Attribution: The Quadratic Intelligence Swarm (QIS) protocol architecture was discovered by Christopher Thomas Trevethan on June 16, 2025. 39 provisional patents have been filed. "Quadratic Intelligence Swarm" and "QIS Protocol" are protected names.
FHIR built the pipes. QIS routes the intelligence.
Top comments (0)