Omi Health/Builders/HIPAA speech-to-text
Practical compliance guide

HIPAA-compliant speech-to-text: what builders should verify.

A BAA matters, but it is not a magic badge. Use this checklist to examine the contract, data path, controls and product behavior before your application sends protected health information.

BAASigned before the service creates, receives, maintains or transmits ePHI.
ControlsAccess, audit, integrity, authentication and transmission safeguards.
RetentionKnown storage locations, deletion behavior and result lifetime.
WorkflowYour own app, users and downstream vendors remain in scope.
Short answer: If a speech provider creates, receives, maintains or transmits ePHI for a covered entity or business associate, HHS guidance says the parties generally need a HIPAA-compliant business associate agreement. The customer still has to perform its own risk analysis and operate the full workflow appropriately.

1. Confirm whether HIPAA applies to your workflow

HIPAA applies to covered entities and business associates, not automatically to every health-related application. Start by mapping who provides the service, whose information enters the system and whether the audio or transcript contains protected health information.

The US Department of Health and Human Services explains that a cloud provider processing ePHI on behalf of a regulated entity is a business associate even if it only stores encrypted data and cannot decrypt it. That is why “we encrypt everything” is not a substitute for the correct agreement.

2. Sign the BAA before sending PHI

Ask whether the BAA covers the exact speech product, account and region you will use. Check the permitted uses, breach duties, subcontractor obligations, termination and return or destruction of PHI. A sales promise that a vendor is “HIPAA ready” is not the agreement.

Omi makes its BAA and DPA available for self-service signing in the console from the Builder plan, so a small team can establish the contract before sending PHI.

3. Trace the complete data path

Draw the path from microphone or uploaded file to transcript, webhook, database, logs, monitoring and any downstream LLM. Record the region and provider at every step. A compliant transcription boundary does not make a downstream prompt store, analytics tool or support log compliant.

  • Where are audio and transcripts processed?
  • Which subprocessors can receive them?
  • Are request bodies copied into application or observability logs?
  • Does a webhook destination have the same contractual and technical safeguards?

4. Verify safeguards, not just encryption

The HIPAA Security Rule is organised around administrative, physical and technical safeguards. For the technical layer, HHS highlights access controls, audit controls, integrity, authentication and transmission security. Your review should cover how API keys are issued and rotated, who can retrieve results, how activity is logged and how incidents are handled.

Ask for concrete answers. “Enterprise-grade security” is not a control description. Neither a BAA nor a particular cloud vendor removes your obligation to assess risks in your implementation.

5. Minimise and expire stored data

Keep only what the product needs. Prefer short-lived result storage, avoid PHI in filenames and metadata, and make deletion behavior explicit. Omi's hosted API lets projects choose a stored-job result retention period between 1 and 72 hours; customer audio and transcripts are not used to train Omi models.

6. Test the clinical failure modes

Privacy and security do not make a transcript clinically useful. Test medications, dosages, negation, abbreviations, accents, noise and speaker attribution on audio that represents your users. Score medical terminology separately from overall word error so common conversational words do not hide failures in the record.

Omi publishes an open 30-system medical speech benchmark with separate medical-term, drug-name and dosage results. Use it as a starting point, then run your own acceptance set.

7. Decide hosted or self-deployed

A hosted API is usually the fastest path to production accuracy and operational support. A self-deployed model can keep audio inside your environment, but it moves availability, patching, access, monitoring and incident response onto your team. Neither path is automatically compliant; the responsibilities move.

Omi supports both: omi-medical-1 through the hosted API and the open omi-medical-edge-1 model for local deployment.

Questions to put in your vendor review

  1. Can we sign a BAA for this exact product before sending PHI?
  2. Where are audio, transcripts, logs and backups processed and stored?
  3. Which subprocessors can access ePHI and under what agreements?
  4. What are the default and minimum retention periods?
  5. Is customer content used for model training, evaluation or human review?
  6. How are keys, access, audit events and security incidents handled?
  7. What happens to existing results if billing or service access is interrupted?
  8. Can we test clinical accuracy and failure modes on representative audio?

This guide is practical product information, not legal advice. Primary references: HHS cloud-computing guidance, HHS Security Rule summary, and HHS sample BAA provisions. Reviewed 29 August 2026.

Build behind the right boundary.

Sign the BAA, create a key and start with 25 audio-hours every month.

Start building freeRead the BAA