Where does the patient data go? A walkthrough for your security review

If you are the person who has to sign off on a new vendor, you have read enough marketing pages to be tired of them. What you actually need is the data path: where the protected health information enters, who touches it, where it rests, and where it leaves. So this is that walkthrough, in plain language, written for a peer doing real due diligence rather than for a brochure.

The promise is simple to state. From the moment a consultation is captured to the moment a note lands in the chart, the patient data stays inside one trust boundary, no third-party model vendor ever sees it, and no clinical record is written without a clinician approving it. The one boundary that matters, and the one every other answer hangs off, is the first one below.

The boundary that matters

PHI is processed only in Google Cloud, under Google’s Business Associate Agreement (BAA), in US regions. It is encrypted in transit and at rest. That single fact is the spine of everything else: the audio, the model calls, the storage, and the logs all live inside that one contracted, covered environment rather than scattered across a handful of SaaS tools you would each have to vet separately. When you scope your review, you are scoping one boundary, not ten.

Capture

A consultation begins with audio, captured with both the provider’s and the patient’s knowledge. That audio does not flow through our application servers. It moves through short-lived signed links that bypass the application tier and carry the media directly into the covered storage. The links are short-lived by design, so there is no long-standing URL to leak or replay. And nothing clinical is parked in the browser: no PHI is stored client-side waiting to be cleaned up later. The capture step is built to hold the smallest possible footprint for the shortest possible time.

Processing

This is the question security reviewers ask first about any AI product, and rightly so: which model vendors end up holding the patient data? The answer here is none. The ambient AI drafts the clinical note and suggests codes, and every AI model call runs through Vertex AI under that same Google BAA. Because the inference happens inside the covered boundary, no third-party model vendor ever receives patient data. There is no quiet hop out to an external API you would have to add to your subprocessor list.

The coding side is deliberately conservative. Code suggestion is decision-support, not an authority. Deterministic rule checks that the model cannot override sit underneath the suggestions, and when the documentation does not clearly support a code, the assistant abstains rather than guesses. If you want the longer version of how the system behaves when it is unsure, we wrote that up separately in can you trust the codes an AI proposes. For your purposes here, the point is narrow: the AI proposes inside the boundary, and it is built to fail safe rather than fabricate.

Storage and isolation

Multi-tenant platforms live or die on isolation, so this is worth being precise about. Each organization’s data is isolated from every other, and that isolation is enforced in code on every PHI operation, not left to a configuration setting that one bad query could sidestep. Backing that, a dedicated cross-tenant test suite verifies that one tenant can never reach another tenant’s records. That is the kind of control you usually have to ask for evidence of in a questionnaire; it is a standing part of how the platform is tested, not a one-time assertion.

What lands in logs

Logs are where PHI quietly leaks in most systems, because a stack trace or a debug line will happily print whatever object it was handed. We treat the log boundary as a control surface. A recursive log redactor scrubs PHI and credential fields at any depth before logs are written, so a nested object or a wrapped error does not become a side channel for patient data or secrets. The redaction runs ahead of the write, not as a cleanup pass after the fact.

The clinician gate

Nothing the AI produces becomes a medical record on its own. Every note is presented to the clinician for review and approval, and nothing enters the record until the clinician approves it. The same holds for coding: suggested codes are signed off by the clinician, never turned into an automatic bill. When the clinician edits the draft and the note rebuilds, those manual edits are preserved through the update rather than overwritten. The human is the gate, by design, on both the clinical content and the billing.

Where that approved note then writes back, and where the PHI ultimately lives in your environment, depends on the EHR integration. If that is part of your review, the questions worth asking are collected in EHR integration questions to ask.

What is attested, and what is on the roadmap

Here is the part where vendors usually overstate, so we will be exact. HIPAA is the only compliance claim we make today, and it is independently attested via Scytale. SOC 2 Type II is in progress. HITRUST CSF and ISO/IEC 27001 are on the roadmap, planned, not held. We do not claim a certification before its audit is complete, and you should not let any vendor get away with claiming one that is.

The subprocessors that touch PHI under contract are a short list: Google Cloud (under the BAA), Redox (HL7 FHIR R4, when EHR integration is enabled), and Scytale (for attestation). That is the full set you would carry into your own vendor inventory.

Bring your questionnaire

This walkthrough covers the data path at the level a first-pass review needs: one covered boundary, no third-party model exposure, isolation enforced in code, redacted logs, and a human gate before anything is written. The full posture, with the detail behind each of these, lives on our security and privacy pages. When you are ready to go deeper, send over your security questionnaire and we will answer it against exactly what is described here, not against a more flattering version of it.