Imagine a SOAP note, a structured clinical record covering Subjective, Objective, Assessment, and Plan, arrives in the Electronic Health Record (EHR) with the wrong medication name. Not because the LLM prompt was wrong, because the transcript feeding it was. Word error rate (WER) on untuned models can more than double in noisy, multi-speaker clinical environments compared to controlled recordings, and sound-alike medications are documented as consistent failure points for models not trained on clinical vocabulary. The transcription layer is where PHI first enters your system, where accuracy errors originate, and where your HIPAA liability starts.
This guide covers the exact requirements for building a HIPAA-ready audio pipeline, from BAA structure to zero-retention configuration, with a practical framework for evaluating whether a managed API or self-hosted approach makes sense at your current and projected scale.
Why healthcare meeting assistants need HIPAA compliance
Any product that records, transcribes, or processes conversations between clinicians and patients touches Protected Health Information. The moment your application ingests that audio, you're operating as a business associate under the HIPAA Privacy and Security Rules, and the administrative and technical safeguards those rules require apply to every vendor in your stack.
The HIPAA Security Rule organizes these requirements into three categories:
- Administrative safeguards: risk analysis, workforce training, access management policies
- Physical safeguards: data center controls and device management
- Technical safeguards: access controls, audit controls, integrity controls, and transmission security
All three apply to cloud-hosted audio pipelines.
What constitutes PHI in audio data
Protected Health Information in audio is broader than most product teams assume. Under HIPAA, PHI is any individually identifiable health information that relates to an individual's health condition, treatment, or payment for treatment. In a recorded clinical session, that covers patient names spoken aloud, birth dates and appointment dates, geographic identifiers, diagnoses and symptoms, and medication names. It also includes indirect identifiers: a caller's phone number captured in session metadata, or an account number mentioned in passing.
The practical implication is that the entire audio file and resulting transcript are PHI from the moment recording begins. You cannot treat raw audio as non-PHI and only apply compliance controls after transcription.
Avoiding HIPAA penalties in transcription
The financial exposure for a HIPAA violation is structured across four tiers under the HITECH Act, scaling with culpability. At the lowest tier (no knowledge, meaning the covered entity did not know and could not reasonably have known of the violation), penalties start at approximately $145 per violation. Tier 3 (willful neglect corrected within 30 days) carries a minimum of approximately $14,602 per violation. At the highest tier (willful neglect not corrected within 30 days), the minimum is approximately $73,011 per violation with annual maximums of $2,190,294 per violation category. Beyond financial penalties, the Office for Civil Rights can require corrective action plans carrying years of ongoing oversight costs.
Building user trust in clinical AI
Clinicians and patients evaluating AI-assisted sessions ask one question before any other: "Where does this audio go?" The answer your product gives determines whether adoption happens at all in regulated settings.
High WER undermines clinical trust as much as weak compliance posture does. A therapy session transcript that confuses patient names, misses medication references, or misattributes a statement to the wrong speaker produces notes clinicians must manually correct. That WER gap, documented above, compounds directly into SOAP note errors. For SOAP note generation specifically, loading formulary terms into custom vocabulary reduces the likelihood of sound-alike medication errors in the transcript before they reach the SOAP note.
For practices serving multilingual patient populations, a patient reverting to a first language mid-session under emotional stress is common in behavioral health settings. Solaria-1 detects these mid-conversation language switches across 100+ supported languages, while Solaria-3 is the accuracy-optimized model for noisy, real-world clinical audio in English, French, German, Spanish, and Italian.
Therapy sessions: behavioral health-specific compliance requirements
General HIPAA compliance covers the baseline, but therapy sessions carry a distinct compliance profile that generic clinical audio infrastructure guidance does not address. The content of a therapy session (mental health diagnoses, trauma disclosures, suicidal ideation, substance use history) is categorically more sensitive than most medical audio. Several federal regulations and the majority of US state statutes impose requirements that go beyond the HIPAA floor for behavioral health records specifically. Building for therapy means treating those requirements as hard architectural constraints, not edge cases.
Informed consent in behavioral health settings
HIPAA requires general authorization for the use and disclosure of PHI, but behavioral health adds layers that most product teams underestimate. The American Psychological Association's ethics code and equivalent standards from NASW require that clients receive a clear explanation of what AI tools do, who can access resulting records, how long they are retained, and what happens if the vendor relationship changes, before the first session begins. This goes further than a checkbox consent form.
For products serving licensed therapists or licensed clinical social workers, the consent flow must document: that AI transcription is being used, the identity of the infrastructure providers processing audio, the retention period, and the patient's right to withdraw consent without affecting treatment. Build consent records to be session-linked and version-controlled. If your consent form changes, existing sessions retain a pointer to the version the patient actually signed. Conflating a general "terms of service" acceptance with informed behavioral health consent is a licensing board complaint risk for the clinician, separate from HIPAA exposure for the product.
Sensitivity of therapy session content and 42 CFR Part 2
Therapy session audio may include two categories of PHI that carry stricter legal protections than general medical records.
- Psychotherapy notes have a dedicated carve-out under HIPAA (45 CFR §164.524(a)(1)(i)): they are explicitly excluded from the patient's standard right of access and cannot be shared with other providers, insurers, or researchers without separate authorization. A "psychotherapy note" under HIPAA is a clinician's subjective analysis and impressions recorded separately from the medical record, not the full session transcript.
If your product generates both a transcript and a structured SOAP note, these are likely not psychotherapy notes as defined. But if a clinician uses your platform to store their separate interpretive notes alongside session audio, that content carries the stronger protection. Build access controls to distinguish between session transcripts and clinician-authored interpretive notes, and apply the stricter access rules to the latter. - Substance use disorder treatment records fall under 42 CFR Part 2, a federal regulation that is significantly stricter than HIPAA. Where HIPAA permits disclosure for treatment, payment, and health care operations without patient authorization, 42 CFR Part 2 prohibits disclosure of substance use disorder records, including session transcripts from SUD treatment programs, without explicit written patient consent, with narrow exceptions for medical emergencies and court orders.
If your platform serves addiction treatment centers, residential SUD programs, or therapists with SUD specializations, 42 CFR Part 2 compliance is a hard requirement that changes your BAA structure, your consent flow, and the disclosure controls you build at the application layer. Confirm with legal counsel whether your specific deployment context triggers Part 2 obligations before shipping.
State-by-state therapy recording laws
The federal HIPAA floor does not preempt state laws that are more protective. For therapy session recording, two categories of state law create compliance obligations that vary significantly by jurisdiction.
- Wiretapping and recording consent laws determine whether recording a session requires the consent of one party (the clinician) or all parties (clinician and patient). Eleven states, including California, Florida, and Illinois, apply an all-party consent standard. Recording without explicit consent from every participant constitutes a criminal wiretapping violation, regardless of HIPAA compliance. Products that default to recording without surfacing consent collection to the patient are non-compliant in all-party consent jurisdictions. Your consent flow must capture verifiable patient consent to recording before audio begins, not at the end of the session or buried in intake paperwork signed weeks earlier.
- State mental health confidentiality statutes impose disclosure restrictions on behavioral health records that are stricter than HIPAA in several states. California's Confidentiality of Medical Information Act (CMIA) and Welfare and Institutions Code §5328 cover mental health records with disclosure rules that differ materially from HIPAA's treatment, payment, and operations exceptions. New York's Mental Hygiene Law §33.13 imposes similar restrictions. Illinois' Mental Health and Developmental Disabilities Confidentiality Act (740 ILCS 110) requires patient authorization for disclosures that HIPAA would permit without one.
These statutes affect how transcripts flow between providers within the same organization and what your BAA must say about subprocessor disclosures. A BAA structured only for HIPAA compliance may not satisfy California or New York requirements.
For minor patients, retention requirements for therapy records are set entirely by state law. Many states require retention until the patient reaches majority plus several years. Build retention policies that are patient-age-aware and jurisdiction-aware rather than applying a single global retention window.
Because state therapy recording laws change and interact with federal requirements in non-obvious ways, this section describes the categories of obligation your legal review should address. It is not a substitute for counsel in each jurisdiction your platform serves.
HIPAA Security Rule compliance checklist for ePHI in audio pipelines:
- Risk analysis: Conduct and document a formal risk analysis covering every system that touches audio or transcripts.
- Access controls: Enforce role-based access control (RBAC) so only authorized clinical staff can retrieve transcripts.
- Audit controls: Implement immutable, time-stamped logs for every access, modification, or deletion of ePHI.
- Transmission security: Encrypt all audio and transcript data in transit using TLS 1.2 minimum, with TLS 1.3 recommended.
- Data at rest encryption: Apply AES-256 encryption to stored audio files and transcripts.
- Business Associate Agreements: Execute a BAA with every third-party vendor that processes PHI on your behalf.
- Minimum necessary standard: Configure data retention so PHI is not held longer than required for the stated purpose.
- Breach notification procedures: Establish documented response procedures covering detection, containment, and Office for Civil Rights (OCR) notification within 60 days of discovery.
- Workforce training: Train all staff with access to clinical audio on HIPAA Security Rule requirements. Our compliance hub documents how we implement each of these controls across our SOC 2 Type II, ISO 27001, HIPAA, GDPR, and HDS (Hébergeur de Données de Santé) certification scope.
Building blocks of HIPAA-compliant transcription
A compliant transcription pipeline requires deliberate decisions at every layer: how audio enters your system, how it's processed, what logs are generated, and how data is deleted. These building blocks apply regardless of which infrastructure provider you choose.
Structuring your BAA for PHI security
A Business Associate Agreement (BAA) is a HIPAA-required contract between a covered entity and any vendor that creates, receives, maintains, or transmits PHI on its behalf. HHS guidance on cloud computing and HIPAA makes clear that a cloud service provider processing PHI is a business associate even if that provider accesses PHI only to provide its services, such as data storage. Any transcription API that receives clinical audio must sign a BAA before PHI flows to it, with no exceptions.
A BAA that protects your product must specify: permitted uses and disclosures of PHI, subcontractor compliance obligations, breach notification timelines (the HIPAA statutory maximum is 60 days, but many BAAs negotiate shorter contractual windows of 5-15 days to ensure the covered entity can meet its regulatory deadline), data deletion procedures, and liability allocation. A vendor that refuses to sign a BAA is not a viable infrastructure partner for clinical audio.
End-to-end encryption for audio and transcripts
HIPAA requires encryption of ePHI at rest and in transit. AES-256 at rest and TLS 1.2+ in transit are the accepted implementations. When PHI is encrypted in compliance with HHS guidance and encryption keys remain secure, it is considered "unusable, unreadable, or indecipherable" under the Breach Notification Rule, removing the notification obligation if unauthorized access occurs.
Apply this to every data path: client-to-API audio streaming over WSS (WebSockets over TLS), API response payloads, transcript storage in your application database, and backup replicas.
Enforcing PHI audit trail integrity
The HIPAA Security Rule's audit control requirement mandates mechanisms to record and examine access in systems containing ePHI. Every API request touching a clinical transcript must generate an immutable, time-stamped log entry capturing the requesting user, the resource accessed, the action taken, and the outcome. Implement audit logs at the application layer, not only at the infrastructure layer, so they capture the clinical staff member who opened a transcript rather than just the IP address that made an HTTP request. Retain audit logs for a minimum of six years to satisfy HIPAA's documentation retention requirement.
Regional data residency for HIPAA apps
US-based clinical platforms must ensure PHI remains within US jurisdiction unless explicit patient consent exists for cross-border transfer. For platforms serving both US and EU patients, multi-region data residency is a hard architectural requirement. Choose an API provider that offers both US and EU processing regions with the ability to route audio to a specific region per request, and confirm that audio processed in the US region never transits EU infrastructure. EU-based clinical platforms building for GDPR compliance have the additional requirement that audio not leave the EU without a valid transfer mechanism in place.
Criteria for selecting a HIPAA-ready API
The build vs. buy decision for clinical transcription comes down to three variables: total cost of ownership, compliance certification scope, and accuracy on real clinical audio. Self-hosting open-source models gives you complete data sovereignty on paper, but requires you to own the full compliance certification scope, including ongoing infrastructure maintenance and the cost of obtaining your own SOC 2 Type II attestation.
Table 1: Decision framework for product leaders
| Architecture |
Latency |
Data sovereignty |
Integration effort |
Compliance overhead |
| Cloud-based API (managed) |
~60s per hour of audio (async) |
Configurable by region, BAA-backed |
Sub-24-hour integration reported by multiple customers in production |
Vendor-certified SOC 2 Type II, ISO 27001, HIPAA, GDPR, HDS |
| On-device SDK |
Near-zero (local processing) |
Full, data never leaves device |
Weeks to months of custom integration |
You own the full certification scope |
| Self-hosted open-source |
Configurable |
Full, data never leaves your infrastructure |
Months of custom development |
You own the full certification scope |
Table 2: Unit economics at scale
| Monthly audio volume |
Starter plan (async) |
Growth plan (async) |
Enterprise plan |
| 100 hours |
$61 |
$20 |
Custom |
| 1,000 hours |
$610 |
$200 |
Custom |
| 10,000 hours |
$6,100 |
$2,000 |
Custom |
Real-time transcription pricing: Starter $0.75/hr, Growth as low as $0.25/hr. All-inclusive pricing on both tiers covers translation, named entity recognition, sentiment analysis, summarization, and custom vocabulary with no add-on fees. Diarization is available in async workflows only. Speaker attribution can be handled in post-processing for higher accuracy.
Table 3: Build vs. buy for clinical transcription
| Metric |
Self-hosted open-source |
Our managed API |
| Initial dev time |
Varies significantly by requirements and existing infrastructure. Pre-built options exist but custom implementations require additional development |
Sub-24-hour integration reported by customers in production |
| Monthly maintenance |
Ongoing maintenance required. Scope depends on infrastructure complexity and team size |
Included |
| Compliance certification cost |
Compliance responsibility on your team. Audit scope and cost vary by organizational size and existing controls |
SOC 2 Type II, ISO 27001, HIPAA, HDS certified |
| WER on real-world conversational audio |
Varies; depends on model selection, domain tuning, and audio conditions |
Solaria-3: #1 on Switchboard vs AssemblyAI, ElevenLabs, Deepgram, Mistral, and Speechmatics on real customer recordings in EN and core European languages |
Verifying BAA terms for PHI security
When reviewing a vendor BAA, verify these terms before signing: the subcontractor clause must flow BAA obligations down to any subprocessor that touches PHI, the data deletion clause must specify PHI is deleted within a defined timeframe and confirmed in writing, and the liability allocation must not cap the vendor's exposure at an amount insufficient to cover breach response costs. Request a Data Processing Agreement alongside the BAA for platforms serving EU customers, as both are required for transatlantic clinical deployments.
Defining PHI erasure protocols
Immediate data deletion means audio and transcript data are processed in memory and deleted immediately after a response is returned, with no persistence to disk or object storage on the vendor's side. This collapses the PHI footprint to your own application infrastructure, reducing both the BAAs you need to maintain and the blast radius of any future breach. Confirm this in the BAA's data deletion clause and verify it in the vendor's data retention documentation.
SOC 2 Type II and HIPAA attestations
A SOC 2 Type II report covers the design and operating effectiveness of security controls over a defined observation period, typically 6-12 months for established programs. When evaluating vendors, request the full SOC 2 Type II report rather than accepting a summary letter, and check the audit period and scope. ISO 27001 certification adds an information security management system standard with annual surveillance audits. HIPAA attestation should be confirmed against specific audit scope, not a generic compliance badge on a marketing page.
How we secure PHI in production
Our compliance hub covers our certification portfolio. On Growth and Enterprise plans, customer audio is never used for model training by default, with no opt-out action required. On the Starter plan, audio can be used for training by default, which means the data-not-used-for-training condition that clinical PHI workflows require is available only on Growth and Enterprise plans. Confirm BAA availability for your specific plan directly via the compliance hub before routing PHI.
Immediate data deletion is available on Enterprise. Deployment is limited to dedicated cloud clusters in the EU and US.
Securing PHI from capture to data retention
The lifecycle of a clinical audio session creates PHI at the moment recording begins. Every stage from microphone to final deletion must be designed with explicit data handling controls.
Documenting consent for AI sessions
Before recording begins, capture and log explicit patient consent covering the use of AI transcription and any downstream processing such as summarization or EHR population. Store consent records with a timestamp, session identifier, and the consent form version presented, and map consent records to session IDs in your audit log. For the specific wiretapping and confidentiality statutes that govern therapy recording by jurisdiction, see the state-by-state therapy recording laws section above.
Protecting PHI during live session capture
Stream audio to the transcription API over WSS (WebSockets over TLS), which encrypts audio in transit from the client device to the API endpoint. Minimize local buffering and avoid writing raw audio to local storage on the clinician's device unless the application explicitly requires offline functionality. Our live STT audio intelligence documentation covers the streaming configuration options available.
Real-time streaming for live session capture runs on Solaria-1, with a ~300ms final transcript latency built for continuous capture rather than post-session batch processing. Speaker attribution for that live stream is best handled in post-processing, since diarization is async-only.
Managing PHI access and audit logs
Implement role-based access control at the application layer so clinicians can access their own sessions, supervisors can access sessions within their assigned team, and neither role has default access outside their scope. Every API request retrieving a transcript must pass through your RBAC middleware and generate a corresponding audit log entry. Conduct regular access reviews to identify and remove stale permissions for staff who have changed roles or left the organization. Integrate with your async speaker diarization output to ensure transcripts carry correct speaker attribution before surfacing to any clinical role.
Configuring PHI deletion and retention
Set automated deletion policies that remove transcripts from your application storage after the retention period required by applicable state law. HIPAA sets no retention period for clinical transcripts themselves. That is governed entirely by state medical-record retention statutes, which vary significantly by state and are typically longer for minor patients. (HIPAA's six-year rule applies only to compliance documentation such as risk assessments, policies, and audit logs, not to patient records.) Build retention policies against your state's specific medical-record retention statute for each patient record, not a federal floor that does not exist for this data type.
Implementing HIPAA controls in your product
Automating HIPAA-compliant session notes
Pipe secured transcripts to your LLM via our Audio-to-LLM pipeline, which returns structured outputs including summaries, action items, and named entities you can format into SOAP note templates. The LLM receives a structured, speaker-attributed transcript rather than raw audio, reducing the PHI surface area passed to the model. If you use an external LLM provider for SOAP note generation, that provider must also execute a BAA covering the structured transcript data it receives. Many major LLM providers offer BAA execution for healthcare customers. Confirm BAA availability directly with your chosen provider before routing clinical transcript data to them.
Extracting action items from HIPAA notes
Named entity recognition identifies clinical entities within the transcript, such as medication names, diagnoses, and procedure codes, that you can parse into structured action items for EHR population. Entity types returned and confidence scoring vary by audio condition. The practical accuracy considerations for extracting names and identifiers from noisy, multi-speaker recordings apply directly to clinical session audio, so test against representative samples before mapping entities to EHR fields.
Automating PHI detection and masking
PII redaction replaces identified entities in the transcript with category labels such as [NAME] and [PHONE_NUMBER] before the transcript reaches downstream systems. This feature must be explicitly configured in the API request and is not enabled by default. Enabling redaction at the transcript layer means your LLM prompt and EHR integration receive a sanitized output, reducing the risk of PHI leaking into downstream storage outside your BAA scope. Configure redaction via the PII redaction feature and test against representative clinical session audio before deploying to production.
Automating EHR clinical workflows
EHR integration requires structured, speaker-attributed transcript data that maps to the clinical note format your EHR vendor expects. Common integration pitfalls include diarization errors that misattribute statements to the wrong speaker and entity extraction gaps for rare medications or procedure codes. Use custom vocabulary to load your formulary and procedure code set so the model handles domain-specific terminology before it reaches the EHR. For async workflows, our speaker diarization documentation covers the accuracy controls available for multi-speaker clinical recordings powered by pyannoteAI Precision-2, a specialized model for speaker attribution in multi-speaker audio.
Secure data flow patterns for clinical assistants
Where to handle sensitive audio data
Three architectural patterns are common in clinical audio pipelines:
- Client-side processing: audio analyzed on-device, never transmitted
- Secure gateway routing: audio passes through a server you control before reaching the transcription API
- Direct API ingestion: audio streams from the client to the transcription API over TLS.
For clinical workflows, direct API ingestion with immediate data deletion configured on the vendor side offers the smallest PHI footprint, because audio is processed and discarded at the infrastructure edge rather than persisted in a gateway database you must manage and certify. The ePHI lifecycle under immediate data deletion runs: capture, transmit over TLS, process in volatile memory, return transcript, delete audio with no PHI remaining at the vendor after the response.
Strategies for PHI data sanitization
Before using transcripts for internal analytics or product improvement, strip all PHI by running transcripts through your redaction pipeline and replacing direct identifiers with synthetic substitutes. Using PHI for internal product analytics, such as funnels, call-quality dashboards, and retention metrics, is permitted under HIPAA's health care operations provision (45 CFR §164.501) as long as the computation occurs within your compliance boundary, meaning your own infrastructure or a vendor covered by a BAA, and provided your BAA explicitly authorizes this use. Health care operations under §164.501 covers the covered entity's own qualifying activities.
A vendor's independent product analytics on a covered entity's PHI is not automatically within scope and must be expressly permitted in the BAA before that data is used. The violation occurs when PHI leaves that boundary without proper protections, not from analyzing it internally. Do not use clinical session transcripts as training data for any internal model without completing a full de-identification process under HIPAA's de-identification standards if the data will leave your compliance boundary, which requires either expert statistical determination that re-identification risk is very small, or removal of all 18 specified identifier categories.
Eliminating PHI from audit logs
Application logs, error reports, and API request logs can silently capture PHI if request payloads are logged verbatim. Implement a log scrubbing layer that strips audio file contents, transcript text, and patient identifiers from log lines before they're written to your logging infrastructure. Log the session ID and status code, not the audio payload or transcript content, and apply the same scrubbing to error reports sent to monitoring tools.
Automating HIPAA incident response
The transcription layer is where most clinical meeting assistant compliance failures originate, not in the LLM prompt, not in the EHR integration, but in the audio pipeline that feeds them. Getting the BAA structure, the retention rules, and the accuracy controls right at that layer protects every downstream system that depends on it. The controls covered in this guide, from consent logging through incident response, are only as reliable as the transcript accuracy and data handling guarantees the infrastructure underneath them can deliver.
Build automated triggers that fire when your monitoring system detects potential PHI exposure: unauthorized API access attempts, unexpected data access patterns in audit logs, or configuration changes to retention or redaction settings. When a trigger fires, isolate the affected session data, notify your security and legal teams, and assess whether the incident constitutes a breach under the Breach Notification Rule. If it does, affected individuals must be notified without unreasonable delay and within 60 days. Document every incident response action with timestamps and responsible parties.
Contact our team via the compliance hub to discuss BAA execution and deploy an immediate data deletion pipeline. To test transcription accuracy on non-PHI clinical audio before committing, start with €50 in free credits on our Starter plan.
FAQs
Which third-party vendors require a BAA?
Any vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate and requires a BAA before PHI flows to them. Per HHS cloud computing guidance, this explicitly includes transcription APIs, cloud storage providers, LLM providers receiving clinical transcripts, and any monitoring tool that processes PHI-containing request payloads.
How long can I retain therapy session transcripts?
HIPAA does not set a retention period for therapy session transcripts. That is determined by state medical-record retention law, which varies by state and is typically longer for minor patients. (The six-year HIPAA rule that often gets cited here applies to compliance documentation such as risk analyses and audit logs, not to clinical records.) Check your state's specific medical-record retention statute for each patient record.
Can I use AI summarization on PHI?
Yes, with the requirement that the LLM provider receiving the transcript executes a BAA covering the data it processes. Run PII redaction on the transcript before sending it to any external model to minimize the PHI footprint and limit the scope of data covered by each provider's BAA.
What steps should I take after a PHI exposure incident?
Isolate the affected data immediately, notify your security and legal teams, and assess whether the incident meets the definition of a breach under the HIPAA Breach Notification Rule. If it does, affected individuals must be notified without unreasonable delay and within 60 days. If more than 500 individuals in a state are affected, notify the HHS Secretary and prominent local media without unreasonable delay and within 60 days following discovery of the breach, the same window that applies to individual notification, but not required to be simultaneous.
Key terms glossary
BAA (Business Associate Agreement): A HIPAA-required contract between a covered entity and any vendor that creates, receives, maintains, or transmits PHI on its behalf.
PHI / ePHI (Protected Health Information): Individually identifiable health information relating to a person's condition, treatment, or payment for treatment. ePHI is the electronic subset covered by the HIPAA Security Rule.
SOAP note: A structured clinical documentation format covering four sections: Subjective (the patient's reported symptoms and concerns), Objective (measurable clinical observations and test results), Assessment (the clinician's diagnosis or clinical impression), and Plan (the proposed treatment, follow-up, or referrals). SOAP notes are a primary output of AI medical scribes and a common downstream consumer of session transcripts.
WER (Word Error Rate): The percentage of words a transcription model gets wrong against a verified reference transcript, the standard accuracy metric for speech-to-text.
Diarization: Attributing each segment of a transcript to the correct speaker in a multi-speaker recording.
De-identification: The HIPAA-defined process (Safe Harbor or Expert Determination) for stripping identifying details from PHI so it can be used outside the compliance boundary, such as for internal analytics.
42 CFR Part 2: A federal regulation stricter than HIPAA governing disclosure of substance use disorder treatment records.
SOC 2 Type II: An audit report covering both the design and operating effectiveness of a vendor's security controls over an observation period, typically 6-12 months.
