Alpha · We're looking for development partners. Build with us →
Menu
Blog / Introducing Cascade Bridge
June 15, 2026 · ~1,400 words · Product & vision

Introducing Cascade Bridge: Patient-Owned Health Data, Connected and AI-Ready

Cascade Bridge is a design for a reference application on the Cascade Protocol. It would collect health data from many sources, connect it into one deduplicated knowledge graph with provenance, and give patients control: explore, augment, query with AI, and share selectively. We submitted it to the ONC EHIgnite Challenge, and the full narrative is now public.

Update: Design, not built. Submitted to the ONC EHIgnite Challenge in 2026; not selected. The name now refers to Cascade's format-conversion layer: FHIR and C-CDA in and out. This post describes the design as submitted.

Cascade Bridge EHIgnite FHIR Knowledge Graph Patient-Owned Data AI Agents

The 21st Century Cures Act and ONC's December 2023 EHI export mandate gave every patient a legal right to their complete health record. Many providers now offer single-patient EHI exports. The data transport problem is largely solved, and FHIR is its centerpiece.

But access is not the same as usability. What arrives at the patient is a raw FHIR bundle, a sprawling C-CDA XML archive, or an unstructured PDF. These formats were engineered for institution-to-institution exchange, not for a patient managing a chronic condition across five providers. FHIR is an exceptional shipping container, but it does not deliver usable, readable, or actionable information to patients. Cascade Bridge was designed to close that gap.

Collect. Connect. Control.

Patients face three distinct barriers, and the Cascade Bridge design is organized around closing each one.

1

Collect

EHI exports from FHIR or C-CDA systems, PDFs and scans, wearable streams, and self-reported data go into one patient-owned pod.

2

Connect

Every record becomes RDF anchored to standard codes. A reconcile step deduplicates records and keeps conflicts with their sources.

3

Control

Explore your record by meaning, correct it without erasing the source, ask AI questions with citations, and share selectively through a health wallet.

The Cascade Bridge data flow: patient-owned EHI, multi-provider EHRs, and wellness devices feed import and parsing pipelines; a knowledge graph and AI reconciliation write to a provenance-tracked, encrypted Cascade pod; the patient controls access through a secure SDK.
How data was designed to move through the three C's: collected into a patient-owned pod, connected via an RDF knowledge graph with provenance, and controlled by the patient. A design diagram, not a built system.

An earlier framing of these three C's used "Communicate" as the third pillar. Working through the EHIgnite submission sharpened our thinking: communication is just one thing a patient does with a unified record. The deeper promise is control: correcting records while preserving source authority, reasoning over them with AI, responding to living updates like a genomic reclassification, and sharing selectively on the patient's own terms. Control is the superset, and it is the right third pillar.

Why we designed it as an EHIgnite submission

Interactive 3D health knowledge graph rendered by Cascade Bridge, with conditions, medications, labs and supplements as distinct shapes and a flagged drug interaction.
The interactive 3D health graph demo from the Cascade Bridge design. Color encodes provenance; shape encodes type.

The ONC EHIgnite Challenge asks a pointed question: now that single-patient EHI export is a legal right, how do we turn those exports into something usable, readable, and actionable? That is exactly the gap the Cascade Protocol was designed to close, so Cascade Bridge became our answer. The submission made us be concrete about the whole journey, from an import pipeline that takes many formats, through RDF reconciliation that keeps conflicting sources instead of overwriting them, to patient-facing experiences that static files cannot offer: AI Q&A with a citation for each claim, a BRCA2 variant result that updates when a consortium reclassifies it, and a wallet-mediated SMART Health Check-in instead of a paper clipboard. These were designed, not built.

The thread that ties it together is the same one that runs through everything we build: provenance recorded on each record and checked by validation, so that an AI agent does not have to guess whether a heart-rate reading came from a Fitbit or an ICU monitor.

What exists today

The Bridge app is not built. Parts of the protocol under it are. POTS Check is live on the App Store and runs an early private copy of the Cascade Swift SDK. The cascade CLI converts FHIR and C-CDA and can reconcile duplicates across sources; narrative extraction can use a local model. It is available on npm. The TypeScript and Python SDKs and the specification are published and documented on this site.

Because the protocol underneath is open, new applications can build on the same vocabularies and tools. A focused, single-condition app like POTS Check and a whole-record design like Cascade Bridge share the same foundation.

Read the full story

The complete Cascade Bridge design narrative, including the patient walkthrough (a design scenario, not built), the standards-alignment detail, the cross-domain reasoning example, and the wireframes, is on the Cascade Bridge page. Our full ONC EHIgnite Phase 1 submission is available as a PDF.

Explore the Cascade Bridge design Read the EHIgnite narrative (PDF) Developer docs

Further reading

← Back to Blog