Rory | QIS PROTOCOL

Posted on Apr 9

FHIR Gets Your Data to Flow. Here Is What It Cannot Do With It Once It Arrives.

#ai #opensource #python #machinelearning

Understanding QIS — Part 113 · Health Interoperability Series

Your hospital implemented FHIR. The ONC Final Rule required it. You have R4-compliant APIs. Epic or Oracle Health certifies them. Patient data flows out. App developers can query Observations, Conditions, and MedicationRequests in a standardized format.

The data moves.

And your hospital is still relearning lessons that 300 other hospitals already learned — because data moving is not the same thing as intelligence synthesizing.

This is not a criticism of FHIR. FHIR solved a genuinely hard problem. The question is what problem it solved, and which adjacent problem it left untouched.

What FHIR Actually Solved (Credit Where It's Due)

Before FHIR, health data exchange was a custom negotiation at every interface. HL7 v2 messages were proprietary dialects — your Epic spoke a different v2 than their Cerner. Each integration required custom mapping. Projects cost millions and took years.

FHIR changed the unit of exchange from "institution-specific message format" to "standard RESTful resource." A Patient resource looks the same regardless of vendor. An Observation follows a defined schema. SMART on FHIR (Mandel et al., JAMIA 2016) added OAuth2-based authorization so third-party apps could access patient data with consent.

The ONC 21st Century Cures Act Final Rule (2020) mandated FHIR R4 API access for all certified EHR vendors by 2022. As of 2025, over 90% of US hospitals operate FHIR-certified systems.

That is a genuine infrastructure achievement. FHIR solved the data transport and format standardization problem.

The problem it did not solve: what to do with outcomes once they accumulate.

The Gap FHIR Was Never Designed to Close

Here is a concrete scenario. A hospital in Cleveland sees an unusual post-surgical complication pattern: elevated troponin within 72 hours of elective laparoscopic procedures in patients over 65. Over three months, their quality improvement team identifies a contributing factor — a specific anesthetic agent combination interacting with subclinical cardiac risk. They modify their pre-op risk stratification protocol. The complication rate drops 40%.

Now ask: does the hospital in Phoenix know this?

Under FHIR: not automatically. FHIR gives Phoenix the ability to query Cleveland's patient records if a patient moves between systems and consents. But FHIR does not give Phoenix the ability to receive the distilled signal from Cleveland's outcome — the validated learning that troponin elevation in this population correlates with this risk factor under these conditions.

FHIR moves records. It does not move outcome intelligence.

The distinction matters at scale. The United States has approximately 6,000 hospitals. If each institution learns independently:

Current real-time synthesis paths: 0. Each hospital relearns each lesson from scratch.
Potential synthesis paths: N(N-1)/2 = 6,000 × 5,999 / 2 = 17,997,000.

Seventeen million real-time synthesis opportunities. Currently generating zero collective intelligence — not because the data cannot move, but because the architecture has no mechanism to close the outcome loop.

CDS Hooks: The Gap Inside the Gap

FHIR's closest attempt at outcome routing is CDS Hooks — a standard for embedding real-time clinical decision support alerts into EHR workflows. When a clinician opens a patient chart, a CDS Hook fires. The CDS service receives FHIR context (patient age, active medications, problem list) and returns a recommendation card.

CDS Hooks is valuable. But it has a structural limitation: it learns only from the institution that deployed it.

A CDS service at Memorial Hospital learns from Memorial's outcomes. It does not synthesize outcomes from Mercy Hospital, St. Luke's, or the 5,997 other facilities that may have seen the same clinical pattern. Each CDS service is an island.

The irony is precise: FHIR standardized the format that makes cross-institutional synthesis technically possible for the first time — and then the stack stopped before building the synthesis layer that would use it.

The Architecture Problem in One Sentence

FHIR is a data exchange protocol. It routes structured clinical records between authorized parties.

What healthcare is missing is an outcome routing protocol. Something that routes distilled insights — not raw records — to the institutions facing the same clinical problem, in real time, without those institutions ever sharing patient data.

These are different layers. They are not competing. They are complementary. FHIR handles data transport. The outcome routing layer sits above it and handles intelligence synthesis.

What the Outcome Routing Layer Looks Like

Christopher Thomas Trevethan discovered — on June 16, 2025 — that when agents route pre-distilled outcome packets to deterministic semantic addresses instead of centralizing raw data, intelligence scales as Θ(N²) while compute scales as O(log N) or better. This is the Quadratic Intelligence Swarm (QIS) protocol. 39 provisional patents filed.

The architecture above FHIR works as follows:

FHIR Layer (existing):
  Patient record → FHIR R4 resource → Standardized API endpoint
  [Data moves. Format normalized.]

QIS Outcome Routing Layer (above FHIR):
  FHIR Observation → Local processing → Outcome packet (~512 bytes)
  → Semantic fingerprint (diagnosis_code + intervention_type + outcome_delta)
  → Route to deterministic address (hash of clinical context)
  → Similar institutions receive packet → Local synthesis
  → New outcome packets generated → Loop continues
  [Intelligence moves. No patient data leaves.]

The outcome packet for the Cleveland troponin pattern might look like:

outcome_packet = {
    "observation_context": {
        "icd10_category": "I20-I25",           # Ischemic heart disease range
        "snomed_procedure": "387713003",         # Laparoscopic surgical procedure
        "age_range": "65-80",
        "anesthetic_class": "volatile_halogenated"
    },
    "outcome_delta": {
        "metric": "troponin_elevation_72h",
        "baseline_rate": 0.087,                  # Before protocol change
        "post_intervention_rate": 0.052,          # After protocol change
        "confidence": 0.91,
        "n_cases": 47
    },
    "timestamp": "2026-03-14T00:00:00Z"
    # No patient identifiers. No names. No DOBs. No PHI.
}

This packet — 512 bytes, HIPAA-safe by architecture — gets routed to every institution whose fingerprint matches: older patients, laparoscopic procedures, relevant cardiac risk profile. The hospital in Phoenix receives it. Cleveland never shared a patient record.

The Five-Step Proof

The QIS loop has five steps. Which one requires centralized patient data?

Step 1: Each institution processes outcomes locally.
FHIR-connected hospitals already have structured outcome data in standard format: Observations, Conditions, Procedures with timestamps. Nothing new required. ✓

Step 2: Local outcomes are distilled into ~512-byte packets.
No patient identifiers. No raw records. Only: clinical context fingerprint + outcome delta + confidence score. A FHIR Observation becomes a compressed signal vector. ✓

Step 3: Packets are routed to a deterministic semantic address.
The address is defined by the best clinical expert for that domain — an oncologist for oncology networks, a hospitalist for general medicine. The routing mechanism can be any efficient system: DHT (O(log N)), vector database (O(1)), REST API over existing FHIR endpoints, message queue. ✓

Step 4: Similar institutions receive and synthesize locally.
Each institution's system queries for outcome packets matching its current clinical context. 512-byte packets arrive. Local synthesis runs on-device. No cloud aggregator. No central database. Privacy preserved by architecture. ✓

Step 5: Synthesis generates new outcome packets. Loop closes.
The synthesis result — what is working across peer institutions facing the same problem — becomes new signal in the next cycle. The network gets smarter with every loop. ✓

Which step breaks? The challenge is open. If no step requires raw patient data to leave its origin institution, then the intelligence gap above FHIR is solvable without any new privacy infrastructure.

What This Means for FHIR Implementers

If you have implemented FHIR R4 APIs, you already have the substrate for outcome routing:

FHIR Observation resources are the raw signal input to Step 1
OMOP/USCDI standardized codes provide the shared vocabulary for Step 2 fingerprinting
SMART on FHIR authorization handles the trust layer for packet exchange in Step 3
FHIR Bulk Data Access enables batch processing for high-volume outcome packet generation

You are not replacing FHIR. You are adding a synthesis layer above it.

The analogy is precise: TCP/IP moves packets between machines; HTTP adds semantic meaning to what those packets represent. FHIR moves clinical records between institutions; QIS adds outcome synthesis across those institutions. Each layer is necessary. Neither replaces the other.

The Scale Argument

Consider what N(N-1)/2 means at FHIR network scale:

Connected Institutions	Synthesis Pairs	Currently Active
10	45	0
100	4,950	0
1,000	499,500	0
6,000 US hospitals	17,997,000	0

Every FHIR implementation adds a node to a network that is generating no collective intelligence because the outcome routing layer does not exist. The 21st Century Cures Act unlocked data mobility. The next unlock is outcome mobility.

The Routing Mechanism Is Protocol-Agnostic

One clarification worth stating directly: QIS outcome routing above FHIR does not require DHT infrastructure. The routing layer is protocol-agnostic. The quadratic scaling — Θ(N²) synthesis opportunities at O(log N) or better compute cost — emerges from the closed loop architecture, not from any specific transport. The transport can be:

DHT (O(log N), fully decentralized — excellent for cross-institution anonymity)
Vector database like ChromaDB or Qdrant (O(1) lookup — excellent for high-performance institutional deployments)
REST API over FHIR-compliant endpoints (works with existing FHIR server infrastructure)
Message queue (Kafka, NATS) — excellent for real-time streaming outcome integration

If you can post a ~512-byte outcome packet to a deterministic address and another institution can query that address for packets matching their clinical context — QIS works. FHIR's existing API infrastructure is a valid transport layer for the outcome routing protocol above it.

Who This Affects

This gap is not abstract. The Cleveland-to-Phoenix scenario above plays out across every clinical domain:

A rural critical access hospital in Montana observes a medication dosing adjustment that reduces 30-day readmissions for CHF patients on diuretics. Under the current architecture, that observation never reaches the 47 other critical access hospitals running the same patient population. Under QIS outcome routing, it does — as a 512-byte packet, transmissible over the hospital's existing FHIR API infrastructure, carrying no patient data.

Federated learning cannot solve this. It requires enough local data for a meaningful gradient update — a critical access hospital with 12 CHF patients per quarter cannot participate. QIS treats any validated observation as a legitimate outcome packet, regardless of cohort size. N=1 sites participate.

This is the inclusion argument that FHIR implementers building for rural and underserved settings need to hear: standardizing the data format was necessary but not sufficient. The outcome routing layer above FHIR is what turns FHIR connectivity into collective intelligence.

DEV Community