Technology and design decisions behind the Cascade Protocol
Deep dives into the technology and design decisions behind the Cascade Protocol. Written for AI/ML developers, healthcare engineers, and compliance-conscious architects building the next generation of health applications.
Cascade Bridge is a design for a whole-record patient app, submitted to the ONC EHIgnite Challenge (not selected). It was not built. This post introduces the design's thesis, the Collect-Connect-Control architecture, and where to read the full narrative.
Read moreYour health records are scattered across a dozen patient portals, each speaking a slightly different dialect of FHIR, each unaware of the others. This post walks through the Cascade Protocol's three-step path to owning your data: collect raw FHIR exports, connect them into a unified knowledge graph with duplicate detection and conflict resolution, then control them, querying in plain English with an AI agent — and explains why the CLI is exactly the right interface for the agentic era.
Read moreAI agents working with health data typically receive raw JSON with no schema context, proprietary API formats, or flat CSVs. None of these formats are self-describing. This post explains why RDF/OWL — the foundation of the Cascade Protocol — solves the semantic grounding problem for health AI, with a concrete comparison of how the same medication record looks in ad-hoc JSON, FHIR R4, and Cascade Turtle.
Read more
When an AI agent writes "your blood pressure trend is improving," how do you know which readings it used? Were they from a medical-grade device or a consumer app? Without provenance, you cannot answer these questions. This post introduces Cascade's provenance classes — from ClinicalGenerated to AIExtracted — and explains how the W3C PROV-O model helps document data lineage for audits and compliance work.
The common pattern: you build a health app, you add AI features, you send user health data to an AI API. Who signed the BAA? Where is the data stored? Does the AI company use it for training? This post makes the case for keeping the health data and the tools that read it on the user's machine, and says plainly that a cloud model still receives what the agent reads.
Read more