Case Study - The EMR Integration Strategy That Deliberately Shipped Only Step One

Overview

Every Epic site is its own app registration, security review, and go-live process, run by its own interface team. Neither failure mode — ignoring integration until a deadline forces it, or over-building against an EMR nobody has committed to — is visible until it's expensive. As founding CTO, CPO, and CMO, the job was to make sure Otto did neither.

The problem

The reason write-back is structurally harder than read is regulatory, not technical: federal rules force EMRs to expose patient data for reading via FHIR, so read access is comparatively solved. There's no equivalent mandate for writing a note into the legal record, so every health system gates it behind security review, contracting, and a real, attributed EMR user identity. The bottleneck is compliance and workflow, not the API call — and building a product roadmap around that distinction, rather than around what looks technically interesting to build first, is the actual strategy problem.

Why it took a physician-engineer

Knowing that distinction is regulatory fluency. Turning it into a product sequencing decision — and into a system architecture that wouldn't need to be rewritten as that sequence played out — required holding the regulatory reality, the product roadmap, and the code structure in the same frame at once, rather than treating them as three separate conversations to have later.

Approach

The strategy took the shape of a four-rung ladder, each rung independently shippable and none of them thrown away as the next was built: copy-to-clipboard export first, then a rendered PDF delivered via secure Direct messaging, then a true EMR write through an integration middleware vendor absorbing per-site interface-engine complexity behind one API, and only as a last resort, a direct point-to-point FHIR or HL7v2 integration built for a single anchor customer whose contract justifies the bespoke cost.

Each rung carries an explicit exit trigger — climb to rung two only once a real pilot surgeon's top complaint is copy-paste friction, not before; climb to rung three only once a pilot site commits to wanting the note in the chart itself. We deliberately built and shipped only rung one, resisting the pull to start building toward a direct Epic integration before any customer existed to justify it.

Under the hood

Export is modeled as one canonical, EMR-agnostic internal note document sitting behind a pluggable adapter interface — clipboard, share-sheet, and PDF adapters shipped in the prototype; Direct-messaging, middleware-write, and direct-FHIR/HL7v2 adapters designed against the same interface but intentionally left stubbed. Every exported artifact carries a mandatory safety label identifying it as an AI-generated, human-reviewed draft not cleared for clinical use. The technical pathways for later rungs are already documented at the level needed to scope real engineering work when the time comes, including the compliance dependency for each rung — a HISP relationship for Direct messaging, a middleware vendor BAA for rung three, a full enterprise security review only for rung four.

Outcome

A pilot-ready export path shipped in days, with rungs two through four already scoped to the point where the next dollar of EMR-integration engineering has a defined target instead of an open-ended research problem — and a future integration conversation starts from "which rung does this pilot's exit trigger point to," not from zero.