DEV Community

Cover image for They Declined the Meeting. I Built the App Anyway — Local-First, No Cloud, No Stored Health Data
Evelyn Caro
Evelyn Caro

Posted on

They Declined the Meeting. I Built the App Anyway — Local-First, No Cloud, No Stored Health Data

Seventeen days after a hospital system declined to evaluate a patient-prep architecture, the working reference build shipped. Here is the engineering case, and the white paper that specs it.

On September 27 I pitched a hospital system an imaging patient-preparedness tool. In October the sourcing office declined — without evaluation of the architecture. The record is private; the pattern is public. On October 22, seventeen days after the decline, the thing existed anyway: Radiology Companion™ v5, a working local-first reference build. This post is the engineering case for why it is built the way it is built, and why I wrote a whole white paper to spec it before asking anyone to trust it.

The bug class nobody audits

Here is the failure, in engineer's terms. A hospital sends prep instructions through a portal. The portal logs sent. The patient experiences nothing arrived. Fifty-eight days after the message went out, an appointment died because of it — mine, and I have the receipts, because I document the way Ida B. Wells kept records: date everything, name everything, record the reasoning.

The system's ledger says sent. The patient's ledger says lost. Only one of them gets written down. A sent-flag verifies delivery to a server; arrival at a person is the other end of the wire, and nothing in the chain checks it. It is a behavioral control that fails silently — that is what behavioral walls do. Missed US medical appointments get quoted at $150B a year; that figure is trade press and it travels flagged in everything I publish (the peer-reviewed clinic-scale literature backs the pattern: roughly a quarter of patients run nonadherent to care that includes keeping the appointment, and the prep-failure chain in endoscopy is measured in lesions and repeat procedures — receipts in the paper).

The build

Seventeen days, one builder, AI collaborators, no funding. The constraint set did the design work:

  • No cloud. No backend to breach, no accounts to provision, no data to sell.
  • No stored health data. Nothing about the patient leaves the device. Not analytics, not logs, not crash reports.
  • The protocol explained in order. Every preparation step verified, every step read aloud.
  • Twenty languages, because the register problem is also a language problem.
  • A hospital's own name and logo, fetched from a pasted link — the only configuration the institution supplies.
  • Four sourced institutional demo libraries — the prep pages Mayo, Johns Hopkins, and Cleveland Clinic already publish, cited, never generated.

That last point matters. The app invents no prep. The canon is cited; the app is the delivery layer that gets the sheet out of the app: paper, calendar, read-aloud. Exits before entrances. The department's sent-flag measures nothing that matters; the companion's whole job is to make obedience to any single channel stop being the test.

Why "local-first" is the requirement, not a preference

Health data is the most sensitive class there is, and the pitch that got declined was a 90-day fixed-fee pilot against the institution's own reschedule baseline. A system that holds nothing cannot leak anything. A demo that runs on a laptop needs no procurement cycle. The institution's only integration is pasting its own URL. The architecture assumes the deployment is the customer's — which is exactly why the source is held: demo free, deploy paid; source private; commercial license only; review under NDA. The party that owns the record owns the terms of contact.

The white paper is the spec

Before asking any department to trust the app, I wrote the paper that justifies the need: The Class of the Prep Sheet — What Bourdieu Teaches Imaging Departments About Failed Preparation.

It is a record-paper, and it verifies its own claims in the open: every clinical citation resolved to full form (authors, journal, volume, pages, DOI) and checked findings-as-used at page level; the one trade-press figure carried with its flag showing; no physician, staff, or facility named; the first patient is the author. The frame is Bourdieu's — the prep instructions as an exam testing three kinds of cultural capital at once — and the pedagogy chapter names the mechanism with Freire's: instructions deposited in a portal, adherence graded at withdrawal, banking education wearing a scheduling badge. The fix has been in medicine's own literature for twenty years. It is called teach-back. The sent-flag closes no loop; teach-back closes the only one that matters.

The return date

The paper files the design requirement; the capability build is my move and my timeline. The reference build is demoable on request. If your department has a reschedule baseline and a prep-failure number, the pilot design is already shaped: 90 days, fixed fee, measured against your own figures — the party whose performance is measured should not be the party holding the measuring instrument.

I build AI tools that solve everyday problems. What problem can AI and I solve for you today?

Top comments (1)

Collapse
 
alexcodebytes profile image
Oleksandr •

The "sent flag vs. received" gap is a massive failure mode in healthcare IT, and building it local-first is the only way to bypass the hospital procurement and privacy nightmare.

Since the app cites Mayo, Hopkins, and Cleveland Clinic instead of generating its own medical advice (which is very smart), how do you handle content drift? If those institutions update their prep pages, does the app pull the latest version live, or do you have a mechanism to manually sync the institutional libraries?

Also, +1 for mentioning "teach-back." It's the gold standard of health literacy, and most patient portals completely ignore it. Great work shipping this solo!

⌂ 换网址