Your Medical Scribe’s BAA Does Not Map the Data Flow

Take a 9:00 a.m. primary-care visit recorded through a clinician’s phone. The ambient scribe captures the conversation, sends audio to a transcription service, turns the transcript into a draft note, and exports the approved text to the electronic health record, or EHR.

That visible workflow may take minutes. Its data trail can last much longer.

A business associate agreement, or BAA, is the contract governing how a vendor handles protected health information on behalf of a HIPAA-covered organization. It matters, but it does not reveal whether the phone keeps a local recording, which subcontractor receives the audio, whether support staff can replay it, or whether fragments enter product analytics.

This walkthrough turns that 9:00 visit into a review artifact. It is designed to produce questions for a BAA and security review, not legal advice.

Start at the microphone, not the generated note

Ask the vendor to draw the data flow from the first captured sound. A useful diagram identifies the device, mobile or web application, network endpoints, processing services, storage systems, administrative tools, analytics pipelines, EHR connection, backups, and deletion jobs. A marketing diagram labeled “capture, generate, integrate” is not enough.

The first unresolved point is often local capture. Some applications stream audio as the visit happens. Others buffer it on the phone or computer when connectivity drops, which keeps the session usable but creates another copy of the recording. The practice needs to know whether that buffer is encrypted, whether it survives an application crash or logout, and what event deletes it.

Consent and recording rules also sit at this first boundary. HIPAA is not the only rule that may govern recording a conversation, and state requirements vary. The operational control should still be visible: the clinician starts capture, the patient receives the practice’s required notice, and staff have a non-recording fallback such as manual typing or ordinary dictation.

For the 9:00 visit, document the device owner, application account, recording indicator, offline behavior, and local deletion trigger. If the vendor documentation does not answer those points, request a written response rather than assuming that “cloud-based” means nothing remains on the device.

Separate audio, transcript, and note retention

The recording, transcript, and generated note are different data objects. They may have different storage locations, retention periods, access rules, and deletion behavior, even when the product interface displays them as one encounter.

Audio carries the full conversation, including material the clinician may omit from the final note. A transcript creates searchable text and can preserve recognition errors, speaker confusion, and incidental comments. The generated note is another derivative, produced when a model selects and restructures details from the transcript. Deleting the note therefore does not prove that the transcript or audio disappeared.

For each object, record when it is created, where it is stored, how long the default retention lasts, whether an administrator can shorten that period, and what happens in replicas and backups. The word “deleted” needs a mechanism: immediate logical removal from the customer interface, later deletion from active storage, eventual expiration from backups, or some combination.

Shorter audio retention reduces exposure and may fit a practice that treats the signed EHR note as the record. It also removes evidence that could help investigate a missing sentence, a speaker-attribution failure, or a clinician complaint. That is a real tradeoff. A reasonable configuration may retain audio just long enough for review while keeping the approved note under the practice’s established record policy, but the appropriate period depends on the organization’s obligations and workflow.

The BAA standard in 45 CFR 164.504(e) says a business associate must not “use or further disclose the information other than as permitted or required by the contract or as required by law.” The review should connect that requirement to each data object rather than relying on a general statement that the service is HIPAA compliant.

Follow every processor behind the vendor

An ambient scribe may rely on separate providers for speech recognition, model inference, cloud hosting, monitoring, customer messaging, and error reporting. A subprocessor is a company that handles customer data for the primary vendor while delivering the service.

The applicable BAA requirement says the business associate must ensure that subcontractors creating, receiving, maintaining, or transmitting protected health information agree to the same restrictions and conditions. The enforceable control comes from the executed agreements and applicable law. A public subprocessor page helps identify the chain, but it is documentation, not proof that every transmitted field is covered correctly.

Return to the 9:00 visit. Ask which processor receives raw audio, which receives transcript text, and whether the note-generation model sees the entire encounter or selected segments. Then identify processing regions, cross-border transfers, and any optional service that activates only when a feature such as translation or note customization is enabled.

Model providers deserve a precise answer. “We do not train on customer data” can mean the provider excludes content from model training while retaining prompts and outputs temporarily for abuse review. It can also refer only to the vendor’s own training, not a downstream processor’s handling. The contract, product setting, and processor terms need to describe the same path.

Treat support access as production access

Support personnel may need to inspect an encounter when transcription stalls, an export fails, or the clinician reports a defective note. That access can be more revealing than ordinary application use because an internal console may expose audio, transcripts, generated output, account metadata, and system logs together.

Ask whether support access is disabled by default, approved per case, limited by role, time-bounded, and recorded in an audit log. Determine whether staff can impersonate a user, download an encounter, or replay audio. The log should identify the staff account, affected patient or encounter, action, timestamp, and stated reason, while preserving enough information for the practice to investigate without placing more clinical text into the log itself.

Location is relevant, but job title and country do not answer the access question. The practice needs the control path: who grants access, what the technician can see, how the session ends, and whether the customer can obtain the record. If the vendor uses a subcontracted support team, that relationship belongs in the same subprocessor review as speech and hosting services.

A polished security report or industry certification may support due diligence, but HHS does not issue a general HIPAA certification that replaces this analysis. The BAA requirement to “use appropriate safeguards” still has to be translated into access controls, logs, incident reporting, and tested administrative procedures.

Inspect analytics for clinical payloads

Analytics is where a narrow documentation tool can develop a second data path. Product teams measure recording duration, transcription failures, feature use, export success, and application crashes. Those measurements can be useful without containing clinical content, but poorly designed telemetry may capture transcript snippets, generated notes, patient identifiers, URLs, or free-text error messages.

Request the analytics event schema, which lists the fields sent for each measured event, and ask whether production payloads are sampled into debugging systems. A statement that analytics data is “aggregated” does not establish that identifiers were removed before collection. Aggregation describes combining records; de-identification has a specific role under HIPAA and needs its own documented method.

The review should also separate service operation from product improvement and model training. Those purposes may have different settings and contractual permissions. Record whether the practice can disable each use, whether the choice applies to existing data, and whether the vendor’s downstream providers honor it.

For the 9:00 visit, the cleanest test is concrete: list every analytics or logging event emitted from capture through EHR export, then inspect whether any field can contain audio, transcript text, note text, a patient identifier, or a clinician’s free-form comment. If the vendor cannot supply that answer, the practice has found an observability gap, not a paperwork gap.

Verify the EHR handoff and the fallback

The generated note is not finished merely because it appears in the EHR. Determine whether the service writes through an application programming interface, or API, uses an interface engine, places text on a clipboard, or asks the clinician to copy it manually. Each route changes the audit trail and the chance that text lands in the wrong chart.

The clinician should review the draft before signing. Document what the system records when text is edited, rejected, regenerated, exported, or signed, and establish who resolves an incorrect-patient selection or failed transfer. If the integration is unavailable, the fallback should avoid uncontrolled copies in email, consumer messaging, or an unmanaged document.

Close the review by reconciling four artifacts: the vendor’s data-flow diagram, subprocessor list, retention schedule, and executed BAA. Product settings should match them. For the 9:00 visit, the practice should be able to say where every copy went, who could open it, which purpose authorized the use, and when each copy becomes unrecoverable.

Questions people ask

Is a signed

BAA enough for an ambient medical scribe?

No. A BAA establishes contractual duties, but the practice still needs to verify the actual flow of audio, transcripts, generated notes, support access, analytics, exports, and backups. Configuration choices can also create a different data path from the one described in general documentation.

Should a practice disable audio retention?

That can reduce the amount of sensitive source material held by the vendor, but it may limit investigation of transcription or note-generation failures. The practice should set a documented period based on its workflow and obligations, then confirm that deletion covers active systems, replicas, local buffers, and backup expiration.

Can a vendor use encounter data to improve its models?

The answer depends on the contract, product settings, and downstream provider terms. Ask separately about model training, human review, product analytics, abuse monitoring, and de-identified data, because a broad statement about “no training” may not address the other uses.

What should an audit log show after support opens a visit?

It should identify the staff account, affected encounter, action, timestamp, approval path, and reason for access. The practice should also know whether support replayed audio, viewed transcript or note text, downloaded data, impersonated the clinician, or sent material to another system.