AI Scribes, Call Recording, and Voicemail Transcription Under HIPAA
Voice is turning into data at scale. Clinics record calls for training and dispute resolution, phone systems generate voicemail transcripts automatically, and “ambient” AI scribes listen to visits and produce structured notes. These tools can reduce documentation burden and improve operational throughput, but they also create new copies of protected health information (PHI) in forms that are easy to duplicate, easy to route to third parties, and hard to govern if you have not designed the workflow intentionally.
HIPAA rarely prohibits the underlying activity outright. A clinic can communicate with patients by phone, can leave messages, and can use technology to support treatment and operations. The compliance problem is that voice tools tend to introduce a vendor that is processing content, storing content, or both. The moment recordings, transcripts, and summaries exist, you are managing additional PHI artifacts that must be protected, retained or disposed of properly, and potentially produced under the patient right of access depending on how you use them. Those are operational obligations, not abstract legal theory.
This article breaks the topic into three practical systems: AI scribes, call recording, and voicemail transcription. The guiding question is consistent across all three: where does the PHI go, who touches it, how is it secured, and what contractual and policy controls prove that it is handled in a HIPAA-compliant way.
Informational note: This report is for informational purposes only and does not constitute legal advice.
Why these tools change your HIPAA surface area
A phone conversation can be transient. The moment you record it, you have created a record that is maintained by or for the clinic. A voicemail that used to be “listen and delete” becomes a stored audio file in a hosted platform. A transcription feature turns the audio into text, which is searchable, exportable, and easy to forward. An AI scribe can generate not only a note, but also raw audio, intermediate transcripts, and model outputs that may persist across systems if the vendor is not configured carefully. HIPAA treats PHI broadly across forms, including oral communications, and once you maintain it electronically it becomes ePHI governed by Security Rule safeguards.
Two implications follow. First, you must treat recordings and transcripts as PHI and secure them like any other record that contains identifiers and clinical content. Second, you need a clear stance on whether these artifacts are part of your official record set for a patient, because that affects access obligations and retention behavior. OCR has addressed recorded oral communications directly in the context of patient access, explaining that recording is not required, but if recordings are maintained and used to make decisions about an individual they may fall into the “designated record set” concept that triggers access rights.
The business associate line is the hinge point
For most clinics, the biggest compliance divider is whether the technology vendor is a business associate. HIPAA’s definition of a business associate is broad: a person or entity (other than the workforce) that creates, receives, maintains, or transmits PHI on behalf of a covered entity, or provides certain services to a covered entity where the service involves PHI. This includes downstream subcontractors that touch PHI on behalf of the business associate.
Once a vendor is a business associate, you need a written business associate agreement (BAA) that contains the required elements, and the vendor’s uses and disclosures of PHI are constrained by that contract and HIPAA’s limits. OCR’s guidance is explicit that the covered entity’s contract or other written arrangement with its business associate must contain the elements specified at 45 C.F.R. § 164.504(e).
This is why “AI scribe HIPAA” conversations usually converge on one technical question: does the vendor process or store PHI in any non-trivial way. If yes, you should assume you are in business associate territory unless a narrow exception applies.
The conduit exception is narrow and usually does not save you
Clinics sometimes assume phone carriers, telecom providers, and cloud platforms are “just pipes,” so no BAA is needed. HIPAA does recognize a narrow conduit concept for entities that merely transport information and do not access it other than on a random or infrequent basis as necessary to perform transportation. OCR’s FAQ describes this and gives examples like the U.S. Postal Service and certain private couriers and their electronic equivalents that act merely as conduits for PHI.
However, the moment a service is doing more than transient transmission, the analysis changes. OCR’s cloud computing guidance explains that the conduit exception applies where the only services provided are for transmission of ePHI and do not involve storage other than temporary storage incident to transmission. Where a cloud service provider maintains ePHI for processing or storage, it is a business associate, even if it offers a “no view” service.
Voicemail transcription and AI scribing are almost never “mere transmission.” They require access to content to convert audio to text and typically require storage of audio and or transcripts at least for some period. That places the vendor on the business associate side of the line in most real implementations.
AI scribes: what they are actually doing with PHI
An AI scribe workflow typically involves capturing the clinician-patient conversation, processing it to produce text, then generating a structured note or summary. The compliance reality is that you are not only managing the final note. You are potentially managing raw audio, raw transcripts, metadata about the visit, prompts and outputs, and vendor logs. Each component can contain identifiers and clinical details, which makes it PHI and often ePHI.
From a HIPAA perspective, the key question is not whether the tool is labeled “AI.” The key question is whether a vendor creates, receives, maintains, or transmits PHI on behalf of the clinic and therefore must be under a BAA with appropriate safeguards. HIPAA’s business associate concept is designed for exactly this: outsourcing a function that requires PHI while keeping the covered entity responsible for proper contracting and oversight.
The BAA must match the real data flows
A common mistake is treating the BAA as a checkbox while leaving the product configured in a way that defeats your own intent. If the vendor retains audio and transcripts indefinitely by default, that expands your breach surface area. If the vendor uses your data for product improvement or model training without a defensible legal basis, that creates a use or disclosure risk. Under HIPAA, a business associate may use or disclose PHI only as permitted or required by its business associate contract or as required by law, and it may not use or disclose PHI in a way that would violate the Privacy Rule if done by the covered entity, subject to limited exceptions described in the rule.
In practice, you want the BAA and the technical configuration to align on several points: what data types are collected (audio, transcript, final note, metadata), how long each is retained, who can access them, what security controls apply, whether subcontractors are involved, and what happens at termination of the relationship. HIPAA’s business associate contract requirements include provisions around permitted uses and disclosures, safeguards, reporting of unauthorized uses or disclosures, and return or destruction of PHI at termination when feasible.
If a vendor wants to use data for training, de-identification is the cleanest lane
Many AI vendors will ask for some ability to use data to improve models. Under HIPAA, there are limited pathways for using data beyond providing services to the covered entity, and those pathways can become messy if they rely on vague “product improvement” language. A more defensible approach is to require that any data used beyond the direct service purpose be de-identified in accordance with HIPAA’s de-identification guidance, and to document how that de-identification is performed and verified. OCR’s de-identification guidance outlines approaches for de-identifying PHI in compliance with the Privacy Rule.
If the vendor cannot or will not operate in a way that keeps training data outside the PHI boundary, then you should assume you are negotiating a high-risk arrangement and get privacy and legal review before proceeding. HIPAA does not prohibit innovation, but it does require that you understand and control disclosures.
Call recording: allowed in many contexts, but it becomes a record you must govern
HIPAA does not generally forbid recording calls. The Privacy Rule permits uses and disclosures of PHI for treatment, payment, and health care operations, with limits and protections, and many clinics record calls for quality assurance, training, documentation of patient requests, or handling disputes.
The compliance shift happens because recording is not “just a phone call” anymore. It is now a stored dataset that can contain PHI, which means you must treat it like other stored information. That includes access controls, auditability, retention management, and breach response planning under the Security Rule framework. OCR’s Security Rule summary explains that the Security Rule sets administrative, physical, and technical safeguards for ePHI maintained or transmitted by regulated entities.
Security Rule applicability depends on the technology, not your intent
OCR’s guidance on audio-only telehealth notes that covered entities using telephone systems that transmit ePHI need to apply the Security Rule safeguards to those technologies, and it distinguishes traditional landline calls from other systems in how the Security Rule may apply. That distinction matters for call recording because most modern call recording uses VoIP systems, cloud contact centers, or integrated apps that transmit and store data electronically.
If recordings are stored in a cloud platform or managed service, the vendor is typically maintaining ePHI and is therefore a business associate that requires a BAA. OCR’s cloud computing guidance makes this explicit for cloud service providers that store or process ePHI.
Minimum necessary still matters for recordings and transcripts
A call recording can be far more detailed than is necessary for the operational purpose you are trying to achieve. HIPAA’s minimum necessary standard generally requires covered entities to make reasonable efforts to limit PHI to the minimum necessary to accomplish the intended purpose, and OCR’s minimum necessary guidance explains the expectation that organizations evaluate practices and enhance safeguards as needed to limit unnecessary access or disclosure.
Translated into call recording governance, this pushes you toward design choices such as limiting which lines are recorded, limiting retention duration, restricting who can access playback, and avoiding exporting recordings outside the controlled system. It also pushes you toward staff scripting and training so that routine calls do not unnecessarily collect or repeat sensitive details when they are not needed for scheduling or operations.
Call recordings can become subject to the patient right of access
Clinics often overlook the access angle. OCR has stated that HIPAA does not require covered entities to record oral communications, nor to retain recordings after transcription, but it adds a practical warning: if recordings are maintained and used to make decisions about the individual, they may meet the definition of a designated record set. OCR gives an example where a health plan is not required to provide a member access to tapes of an advice line interaction if the tape is maintained only for customer service review and not to make decisions about the member.
The lesson is not “patients always get recordings.” The lesson is that your retention and use decisions control whether recordings fall into the record set that must be produced on request. If you record calls only for quality monitoring and you do not use them to make decisions about the patient, the access obligation may differ compared to recordings that directly feed the clinical record or adjudication decisions. The definition of “designated record set” includes records used, in whole or in part, to make decisions about individuals, and HIPAA’s access right applies to PHI in designated record sets.
Voicemail and voicemail transcription: permissible, but easy to mishandle
HIPAA permits providers to communicate with patients by phone and does not prohibit leaving messages on answering machines. OCR’s FAQ on leaving messages confirms that the Privacy Rule permits providers to communicate with patients at home and does not prohibit leaving messages, which is the baseline permission many clinics rely on for appointment reminders and follow-ups.
The operational obligation is to apply reasonable safeguards and to avoid unnecessary disclosure of details. The minimum necessary concept and incidental disclosure guidance are relevant because voicemail is a classic environment where information can be overheard or accessed by someone other than the patient. OCR’s incidental disclosures guidance emphasizes the role of reasonable safeguards and links directly to minimum necessary expectations.
Confidential communications requests change how you must contact the patient
HIPAA gives individuals the right to request that communications of PHI be sent by alternative means or at alternative locations, and covered health care providers must accommodate reasonable requests. This matters for voicemail because a patient may request that you not leave messages, or that you call only a particular number, or that you use a specific method to reduce risk of disclosure. The confidential communications requirements are codified at 45 C.F.R. § 164.522, and OCR’s incidental disclosure guidance references the obligation to honor reasonable confidential communications requests.
In practical workflow terms, your voicemail policy should not be an informal habit. It should be an explicit process that includes checking for a patient’s communication preferences before leaving a message and making sure staff understand what information is appropriate to include absent a specific patient direction.
Transcription turns voicemail into a vendor processing problem
A voicemail system that simply receives and plays messages might look like a standard communications tool. As soon as transcription is enabled, a third party is processing content, typically storing audio and generating text. That is not “mere transmission.” It is creation and maintenance of PHI on behalf of the clinic, which generally means the transcription service is acting as a business associate and requires a BAA. OCR’s business associate guidance and the definition of business associate support this conclusion, and OCR’s cloud computing guidance reinforces that storing or processing ePHI generally places a vendor in business associate scope rather than the conduit exception.
A common clinic failure mode is enabling transcription as a convenience feature from a phone provider or unified communications platform without realizing it changes the regulatory posture. If you cannot obtain a BAA for that service, you should treat the feature as not appropriate for PHI-bearing voicemail and adjust your workflow accordingly.
A practical way to evaluate these technologies before you deploy them
You can analyze AI scribes, call recording, and voicemail transcription with the same structured set of questions, and you can do it without turning the decision into a months-long project. The goal is to map data flow to HIPAA control requirements and to produce a small evidence pack that shows you made a reasonable, documented decision.
Start with classification. Identify what is collected and where it lives: raw audio, transcript text, generated summaries, extracted entities, and metadata. Then determine whether each artifact contains PHI and whether it is stored or transmitted electronically, which will typically make it ePHI under Security Rule scope.
Next determine vendor role. If a vendor creates, receives, maintains, or transmits PHI on behalf of the clinic, it is generally a business associate and needs a BAA with the required terms. This includes subcontractors that handle PHI for the vendor. OCR’s business associate guidance makes clear that business associate contracts must contain the elements at 45 C.F.R. § 164.504(e), and the definition of business associate includes subcontractors.
Then apply security design. The Security Rule requires risk analysis and risk management as part of the administrative safeguards, and that requirement applies to covered entities and business associates. When you add new systems that maintain or transmit ePHI, your risk analysis should reflect the new asset, its threats, and the safeguards you rely on.
Finally, lock governance. Define retention periods, access roles, audit expectations, and incident handling. Decide whether recordings or transcripts are part of your designated record set and document the reasoning, because that affects access obligations. OCR’s patient access guidance emphasizes that the access right is broad across designated record sets, not only the traditional “medical record,” and the designated record set definition turns on whether records are used to make decisions about individuals.
Common configurations that cause avoidable compliance problems
One of the most frequent problems is using consumer-grade transcription or “note writing” tools that do not offer a BAA. If staff paste PHI into those tools, the clinic has disclosed PHI to an entity that is not under HIPAA contractual controls. HIPAA is structured so that business associates are part of the regulated chain with enforceable obligations, and the BAA is the instrument that defines and limits the vendor’s permitted handling of PHI.
Another frequent problem is retaining audio and transcripts indefinitely because “storage is cheap.” Storage cost is not the governing constraint. Every retained artifact increases exposure. Retention should be based on a defined purpose and should be limited to what is reasonably necessary for that purpose, consistent with minimum necessary and security management expectations.
A third common problem is failing to account for patient communication preferences. If a patient requests confidential communications by alternative means or location, the clinic must accommodate reasonable requests, and voicemail practices should reflect that. This is especially relevant in households where voicemail is shared, where transcription might email the text to a shared inbox, or where staff assume that “leaving a message is always fine.”
The defensible posture
A clinic does not need perfect technology to be compliant, but it does need a controlled, documented approach. For these voice-driven tools, a defensible posture usually has five properties.
First, you can draw the data-flow diagram from memory and it matches reality in production. Second, every vendor that stores or processes PHI is under an appropriate BAA with required terms. Third, retention is constrained, access is role-based, and auditability exists. Fourth, patient communication preferences are respected, especially for voicemail and similar channels. Fifth, you can explain whether recordings and transcripts are part of the designated record set and how you will handle access requests accordingly.
If you implement those properties, you can adopt AI scribes, call recording, and voicemail transcription without turning your phone system into an uncontrolled PHI export pipeline.
Sources
HHS OCR, Business Associates guidance (BA definition and BAA requirements).
45 C.F.R. § 160.103, Definition of “business associate” (includes subcontractors).
45 C.F.R. § 164.504(e), Required elements of business associate contracts.
45 C.F.R. § 164.502(e), Business associate conditions and limits.
HHS OCR, Guidance on HIPAA and Cloud Computing (conduit exception and CSP as BA when storing or processing ePHI).
HHS OCR FAQ 245, Conduit exception description (“random or infrequent” access; mere transmission).
HHS OCR FAQ 198, Leaving messages for patients on answering machines.
HHS OCR, Minimum Necessary Requirement guidance.
HHS OCR, Incidental Uses and Disclosures guidance.
HHS OCR, Guidance on HIPAA and Audio-Only Telehealth (Security Rule considerations for telephone systems transmitting ePHI).
45 C.F.R. § 164.308(a)(1), Risk analysis and risk management requirements.
HHS OCR, Summary of the HIPAA Security Rule.
HHS OCR, De-identification guidance under the HIPAA Privacy Rule.
HHS OCR FAQ 369, Recorded oral communications, retention after transcription, and designated record set concept.
45 C.F.R. § 164.501, Definition of “designated record set.”
45 C.F.R. § 164.524, Individual right of access to PHI in a designated record set.
HHS OCR, Individuals’ Right to Access guidance (scope of designated record sets beyond the “medical record”).
45 C.F.R. § 164.522, Confidential communications and alternative means or locations.
HHS OCR, Incidental Uses and Disclosures fact sheet (references honoring reasonable confidential communications requests).