Healthcare technology vendors use several variants of HIPAA compliance language: "HIPAA-compliant," "HIPAA-aware," "built with HIPAA controls," "HIPAA-designed infrastructure." None of these phrases has a legally defined meaning. HIPAA doesn't issue vendor certifications — it imposes obligations on covered entities (healthcare providers, payers) and business associates (vendors who handle PHI on their behalf). A vendor can say "HIPAA-compliant" without any third-party verification required.
This matters for practices evaluating ambient clinical documentation and prior authorization automation tools, because both categories of software handle protected health information directly. Ambient scribing captures audio containing patient name, date of birth, symptoms, diagnoses, and treatment plans — all of which are PHI under 45 CFR 160.103. PA automation reads clinical notes, lab values, diagnosis codes, and insurance information — the same. A vendor's marketing language doesn't tell you anything meaningful about their actual security posture.
What follows is a framework for evaluating what HIPAA controls in a clinical AI vendor actually require, based on the HIPAA Security Rule (45 CFR Part 164, Subpart C) and what meaningful security posture looks like in practice for software that processes sensitive clinical data.
The Business Associate Agreement Is the Starting Point, Not the Finish Line
The Business Associate Agreement (BAA) is a contractual requirement under 45 CFR 164.308(b)(1): a covered entity must obtain a written contract from any business associate who creates, receives, maintains, or transmits PHI on the covered entity's behalf. If a vendor processes PHI and there is no signed BAA, the covered entity is in potential HIPAA violation, and so is the vendor.
Every legitimate clinical AI vendor will sign a BAA. The BAA itself is necessary but tells you very little about actual security controls. A BAA obligates the business associate to use appropriate safeguards to prevent unauthorized use or disclosure of PHI, report breaches to the covered entity, and cooperate with OCR investigations. Those are obligations, not controls. The question is what technical and administrative mechanisms the vendor has in place to actually fulfill those obligations.
When a vendor says "we're HIPAA compliant," the translation is: "we'll sign a BAA." That's the minimum bar, not a security certification.
Technical Safeguards That Matter for Ambient AI
The HIPAA Security Rule's technical safeguard requirements (45 CFR 164.312) specify access controls, audit controls, integrity controls, and transmission security. For ambient scribing and PA automation specifically, the following implementations are what "built with HIPAA controls" should translate to in practice.
Encryption at rest and in transit. PHI stored in the vendor's infrastructure must be encrypted at rest using AES-256 or equivalent. PHI transmitted between the vendor's systems and the practice's EHR must be encrypted in transit using TLS 1.2 or higher. Audio captured during ambient scribing — which is among the most sensitive data in the system — must be encrypted from the moment it's captured on the recording device through transmission and any temporary processing storage.
Minimum necessary access. The HIPAA minimum necessary standard (45 CFR 164.502(b)) requires that PHI access be limited to what is necessary to accomplish the intended purpose. In an ambient documentation system, this means the system should access only the patient record relevant to the current encounter, not the entire patient history unless specifically needed for context. Role-based access controls within the vendor's infrastructure — limiting which engineers and support staff can access PHI in production — should also reflect minimum necessary principles.
Audit logging. The Security Rule requires audit controls (45 CFR 164.312(b)) — records that capture activity in systems that contain or use ePHI. Specifically: who accessed which patient records, when, from what IP or device, and what actions were taken. For ambient documentation, this means logging which patient encounters generated audio, when audio was processed, when notes were generated and delivered to the EHR, and when (or whether) audio was deleted. For PA automation, this means logging which patient records were read for PA criteria checking, when submissions were made, and what payer responses were received. Audit logs must be retained and available for review.
Audio data retention and deletion policies. This is specific to ambient scribing and often underspecified in vendor documentation. After a clinical encounter's audio is transcribed and the note is generated, what happens to the audio recording? A vendor whose system retains audio indefinitely creates a PHI liability — that audio is highly sensitive, is identifiable to a specific patient and encounter, and represents a significant breach surface. A vendor whose policy is to delete audio after transcription (typically within 24 hours of note generation) reduces that liability substantially. Ask specifically: is audio retained after transcription? If so, for how long, where, and why?
Administrative and Organizational Controls
Technical controls are only part of the picture. The HIPAA Security Rule's administrative safeguard requirements (45 CFR 164.308) include security management processes, workforce training, access management, and contingency planning. For clinical AI vendors, the relevant question is whether the vendor has the organizational discipline to maintain HIPAA-consistent practices as the company scales.
SOC 2 Type II certification is the most common third-party verification of security controls for SaaS vendors. A SOC 2 Type II report, produced by an independent auditor, attests that the vendor's security controls were operative continuously over an audit period (typically 6 to 12 months). This is meaningfully different from a SOC 2 Type I, which is a point-in-time snapshot. For clinical AI vendors, SOC 2 Type II is the credible minimum for third-party security verification.
We are not saying SOC 2 Type II certification equals HIPAA compliance — it doesn't, and the frameworks cover different requirements. But SOC 2 Type II from a reputable audit firm (KPMG, Deloitte, a recognized regional firm specializing in tech security audits) demonstrates that a vendor has the operational discipline to maintain documented security controls over time. That discipline is what makes "built with HIPAA controls" credible rather than aspirational.
Subprocessor Transparency
Clinical AI systems typically involve subprocessors — third-party services that the vendor uses to deliver their product. An ambient scribing vendor may use a cloud transcription API, a language model hosted by a major cloud provider, and a cloud storage provider for note generation. Each of those subprocessors potentially handles PHI. The HIPAA Security Rule requires that business associates extend their safeguard obligations to their own subcontractors who handle PHI (45 CFR 164.308(b)(2)).
When evaluating a clinical AI vendor, ask: who are your subprocessors that handle PHI? Do all subprocessors sign BAAs with you? For transcription specifically: does your cloud transcription service sign a BAA, or do you process audio in a configuration where the transcription provider doesn't have access to patient-identifiable information?
Some vendors use large-model APIs for note generation. A vendor using an API from a major AI provider needs to ensure that API is configured for HIPAA compliance — most major cloud providers offer HIPAA-eligible service configurations with BAA coverage, but the default configurations may not include those protections. The difference between "we use Azure OpenAI" and "we use Azure OpenAI under a signed BAA in their HIPAA-eligible configuration" is legally significant.
PHI in Model Training: A Specific Question to Ask
Language models used in clinical AI improve through training data. The question for practices is whether their patient data is used to train or fine-tune the vendor's models. If it is, that represents a use of PHI that goes beyond the treatment purpose that generated the data, and requires explicit authorization analysis under the HIPAA Privacy Rule.
Most credible clinical AI vendors will have a clear policy: production PHI is not used to train or fine-tune models without explicit de-identification or patient consent. This should be stated explicitly in the BAA or a separate data use agreement. If a vendor is vague about whether patient data informs model improvement — "we use data to improve our service" — that answer should prompt follow-up questions.
We build Prioriq with a clear internal policy: de-identified aggregate statistics about documentation patterns may inform system improvement, but identified patient data from production encounters is not used to fine-tune models. That policy is written into our BAA, not just mentioned verbally. Practices evaluating any clinical AI vendor should ask for the same specificity in writing.
What a Reasonable Compliance Review Looks Like
For a specialty practice's compliance or privacy officer evaluating a clinical AI vendor, a reasonable security review covers the following:
Request the vendor's most recent SOC 2 Type II report (or their SOC 2 Type I if they're pre-Type II, which is acceptable for early-stage vendors with a clear path to Type II). Review the Trust Service Criteria covered and the auditor's description of exceptions or observations. Request the vendor's current BAA template and confirm it covers all PHI processing activities in scope — audio, transcription, generated notes, PA submission data. Confirm subprocessor BAA coverage in writing. Ask specifically about audio retention policy: how long is audio retained, where, and whether it can be deleted on practice request. Ask about model training data use policy and confirm it's documented in a contractual exhibit. Confirm access logging and audit log availability — can the practice request audit logs for their patient data? Under what conditions?
This isn't an exhaustive security assessment, but it covers the specific areas where clinical AI vendors most commonly have gaps between marketing language and actual implementation. A vendor who can answer all of these questions with specificity and documentation has the organizational maturity to be trusted with PHI. A vendor who responds with general "we take security very seriously" language without specific documentation is telling you something important about their readiness for clinical deployment.
The Ongoing Responsibility Is Yours
A final point that gets overlooked in vendor evaluation: HIPAA compliance for a covered entity doesn't end with vendor selection. The covered entity — the practice — remains responsible for ensuring that its business associates are actually fulfilling their BAA obligations, that access controls within the ambient documentation system are appropriately configured for the practice's workforce, and that staff who use the system have received appropriate training on proper use and PHI handling.
Deploying ambient scribing changes how PHI is created and transmitted. That change requires a review of the practice's own HIPAA policies and procedures to ensure they reflect the new workflow. Documenting that review and any policy updates is part of the practice's own HIPAA administrative safeguard obligations — not something the vendor handles. The vendor provides the controls. The practice is responsible for using them correctly.