Case Study - Isolating the Highest-Risk Data Before an Incident Forces the Question

Overview

As founding CTO, CPO, and CMO of the venture behind Otto (name withheld), part of the job is making calls nobody else is positioned to force. This is one of them: recognizing that raw operative audio — the highest-sensitivity PHI category in the entire product — needed to move into its own isolated backend before any incident, audit, or customer complaint made the case for us.

The problem

The scribe's actual payload — raw operative-note audio and transcript content — is sold to a surgeon or an OR, not to a pre-op patient, meaning every release of one dragged unrelated code from the other through the same app-store listing and review process. The parent app's backend, inherited Amplify Gen 1 tooling edited only through console generators, was legacy scaffolding to carry forward, not a foundation to build a compliance-sensitive pipeline on top of. None of this was broken yet. That was exactly the point at which it needed to be addressed.

Why it took a physician-engineer

Making this call required reasoning simultaneously about incident blast radius, BAA scope, and buyer/app-store separation — considerations that live in compliance, product, and engineering respectively, and that only cohere into a single "split it out now" decision when held together. An engineer without the compliance context sees a working feature and no reason to touch it. A non-technical operator sees a compliance concern but not the accompanying backend-architecture decision that makes the split actually pay off technically, not just organizationally.

Approach

Rather than porting only the capture screens into a new app and building the rest later, v1 of the standalone product had to be the entire loop — capture through export — on the reasoning that a backend was being built from zero either way, and designing it for only half the pipeline would just mean redesigning it again immediately afterward. The genuinely procedure-agnostic pieces — the native audio-capture module, the frozen client/server wire contract, the offline-first session cache — were ported verbatim, since they were already correct. Everything actually coupled to the old app was rewritten deliberately.

The backend itself moved to AWS CDK instead of continuing with Amplify Gen 1, specifically because the new pipeline's real shape — asynchronous Step Functions orchestration, an approval-gated data model, custom ASR vocabularies — doesn't fit Amplify's generator model.

Under the hood

The new backend is five independently deployed CDK stacks — auth, data, pipeline, API, and observability — per environment. A dedicated Cognito User Pool backs a JWT authorizer on every API Gateway route, with no Identity Pool and no direct AWS SDK access from the client at all. A single DynamoDB table and the raw-audio S3 bucket both sit under one customer-managed KMS key; the bucket blocks all public access, enforces HTTPS, and carries an explicit short-lived retention lifecycle rule rather than indefinite storage. Every Lambda authorizes against the JWT's own subject claim, so a surgeon can only ever read or approve their own sessions — there is no admin bypass path in the deployed system.

Outcome

The documentation product's backend now lives in its own isolated blast radius — separate account boundary, separate identity pool, separate data store — with the complete capture → ingest → transcribe → generate → review → approve → export loop live end-to-end in a development environment, verified against synthetic orthopedic cases including the approval-gate and audit-log paths.