Business Associate Agreement Checklist for Clinical Speech Recognition Software Vendors

Kevin Henry

HIPAA

Published Updated

9 minutes read
Share this article
Business Associate Agreement Checklist for Clinical Speech Recognition Software Vendors

Clinical speech recognition software can handle patient audio, draft notes, transcripts, and related system data. When a vendor creates, receives, maintains, or transmits protected health information (PHI) on behalf of a healthcare organization, the parties should determine whether HIPAA requires a business associate agreement (BAA) and define how the vendor will protect and handle that information.

Use this checklist to review the agreement alongside the actual product workflow. The BAA should reflect what the software and its service providers do—not just what the vendor calls the product.

Determine Whether the Speech Recognition Vendor Is a Business Associate

A vendor will generally be a HIPAA business associate if it performs a function or service for a covered entity—or for another business associate—that involves creating, receiving, maintaining, or transmitting PHI. For speech recognition software, that may include processing clinical audio or transcripts for a provider, storing them, or providing support that involves PHI. HHS explains the business associate definition and contract requirements in its Business Associates guidance.

Assess what the vendor actually handles, including audio captured on a clinician’s device, dictated text, generated notes, and any PHI in troubleshooting records or usage logs. A vendor that only sells software without handling PHI on the healthcare organization’s behalf may present a different analysis; review the parties’ roles and data flows rather than relying on a product label.

Do not assume that encryption alone removes the BAA requirement. HHS states that a cloud service provider maintaining ePHI on behalf of a covered entity or business associate can be a business associate even if it cannot view the encrypted information or access the decryption key. See HHS guidance on HIPAA and cloud computing.

Define Permitted Uses and Disclosures of PHI

Describe the vendor’s authorized work precisely: for example, receiving clinician dictation, converting audio into text, returning draft documentation to the provider’s system, and providing agreed technical support. Specify which categories of PHI the vendor may handle and for what service purposes. A BAA must establish the business associate’s permitted and required uses and disclosures, and generally may not authorize uses or disclosures that would violate the Privacy Rule if performed by the covered entity. See HHS’s sample business associate contract provisions.

Address secondary uses explicitly. If the vendor proposes using audio, transcripts, or related data to improve or train a model, do not assume the service-purpose language permits it. The parties should determine whether the proposed activity is authorized under HIPAA and the agreement, and specify any limits, permissions, or prohibitions clearly.

Consider a contractual limit that restricts access and use to what the service requires, consistent with the covered entity’s policies and applicable Privacy Rule obligations. The minimum necessary standard has exceptions, including certain disclosures to or requests by a health care provider for treatment purposes; avoid treating it as a blanket rule that applies identically to every use or disclosure. See HHS guidance on the minimum necessary standard.

Specify Administrative Physical and Technical Safeguards

Require the vendor to safeguard PHI and, for electronic protected health information (ePHI), comply with applicable Security Rule requirements. The agreement can describe how the parties divide security responsibilities and identify the safeguards the vendor will use. HHS summarizes the Security Rule’s safeguards and obligations in its Summary of the HIPAA Security Rule.

For a clinical speech recognition service, consider addressing who can access audio and transcripts; how accounts and administrative access are controlled; how activity is logged; and how the vendor protects data during transmission, processing, and storage. Also discuss workforce training, incident handling, backups, recovery, and secure disposal where relevant. Treat specific controls as agreement and risk-management choices unless a particular HIPAA requirement applies; HIPAA’s Security Rule requires a risk-based approach rather than one identical control configuration for every organization.

Confirm that the vendor’s safeguards cover the whole service, including clinician applications, administrative tools, support access, integrations, and any cloud infrastructure that stores or processes ePHI. HHS explains that organizations’ risk analysis should account for all ePHI they create, receive, maintain, or transmit, regardless of its source or location, in its Guidance on Risk Analysis.

Set Security Incident and Breach Reporting Duties

Set a clear process for reporting security incidents, impermissible uses or disclosures, and breaches of unsecured PHI. Define the reporting contact, method, information to provide, and how the vendor will send updates as facts become available. A BAA must include reporting duties for uses or disclosures not provided for by the agreement, including breaches of unsecured PHI; HHS describes these contract elements in its business associate contract provisions.

For breach notification, distinguish the regulatory deadline from any shorter contractual deadline. A business associate must notify the covered entity of a breach of unsecured PHI without unreasonable delay and no later than 60 calendar days after discovery. The parties may set a shorter operational deadline in the BAA to give the covered entity time to investigate and meet its own notification duties; that shorter period is a contractual choice, not a universal federal deadline. See the HHS Breach Notification Rule guidance.

Require the vendor to provide, as available, information that helps identify affected individuals and describe the event, the PHI involved, and the response. The agreement should also establish how the vendor will cooperate with investigation, mitigation, and follow-up reporting. Make clear that reporting a security incident is not necessarily the same as determining that a breach occurred.

Ready to simplify HIPAA compliance?

Join thousands of organizations that trust Accountable to manage their compliance needs.

Get Started Free Today

Require Equivalent Protections from Subcontractors

Identify whether subcontractors—such as cloud, transcription, analytics, or customer-support providers—may create, receive, maintain, or transmit PHI for the vendor. The BAA should require the vendor to ensure that any subcontractor handling PHI agrees to the same restrictions and conditions that apply to the vendor, as required by the business associate rules. HHS outlines this requirement in its sample business associate contract provisions.

For practical accountability, consider requiring the vendor to disclose relevant subcontractors, notify the customer of material changes, and explain how it will flow down safeguards and incident-reporting duties. These details help the parties understand who may handle PHI and how contractual protections extend through the service chain.

Document PHI Data Flows and Processing Locations

Map how PHI moves through the speech recognition workflow. Include audio capture, transmission, temporary processing, transcription, generated notes, integrations, support access, logs, backups, and deletion. Identify which party controls each step and which systems or service providers may receive or maintain the data. HHS recommends identifying where ePHI is stored, received, maintained, or transmitted as part of the risk-analysis process in its risk analysis guidance.

Document relevant processing and storage locations, including locations used by subcontractors, so the parties can assess risks and clarify access. HIPAA does not impose a general U.S.-only storage rule for ePHI, but HHS notes that geographic location may affect risk and should be considered in risk analysis and risk management. See HHS cloud computing guidance.

Describe any data kept outside the main clinical workflow, such as diagnostic logs or support recordings, and set limits on their content, access, and retention. A clear data-flow record can also help the parties assess which safeguards and subcontractor terms apply.

Address PHI Return or Destruction and Ongoing Oversight

At termination, the BAA must generally provide for the return or destruction of PHI if feasible. If return or destruction is infeasible, the protections of the agreement must continue to apply to the retained PHI, and further uses and disclosures must be limited to the purposes that make return or destruction infeasible. See HHS’s business associate contract provisions.

For a speech recognition service, clarify how this applies to transcripts, audio, cached files, backups, and data held by subcontractors. Consider requiring the vendor to explain any infeasibility in writing, retain only what cannot reasonably be returned or destroyed, restrict its use, and delete it when the reason for retention ends. The agreement can also specify how the vendor will confirm completed return or destruction.

Set expectations for ongoing communication and review, such as notice of material service changes, access to relevant security documentation, and cooperation with reasonable risk inquiries. These are useful contractual oversight measures, not a claim that HIPAA requires covered entities to continuously monitor every aspect of a business associate’s safeguards. HHS states that covered entities are not generally required to monitor how business associates implement privacy safeguards or comply with contractual privacy requirements in its guidance on monitoring business associates.

A strong BAA reflects the vendor’s actual PHI workflow, defines permitted uses, assigns safeguard and incident duties, extends protections to subcontractors, and sets workable rules for data locations and PHI retention and destruction.

FAQs

When does a clinical speech recognition software vendor need a BAA?

A BAA is generally needed when the vendor performs services on behalf of a covered entity or business associate that involve creating, receiving, maintaining, or transmitting PHI. This may include processing clinical audio or storing transcripts. A vendor’s role depends on the actual service and data flow, not simply on whether the product is described as speech recognition software.

What PHI uses and disclosures should a vendor BAA permit?

Permit uses and disclosures needed to provide the specified services, such as processing dictation, returning transcripts, and providing authorized support. State limits on other uses, including model training or product improvement, rather than assuming they are covered by general service language. The BAA should not authorize uses or disclosures that would violate the Privacy Rule if made by the covered entity.

What breach notification duties should the BAA specify?

Specify how and to whom the vendor reports breaches of unsecured PHI, what information it provides, and how it cooperates with investigation and follow-up. HIPAA requires notice to the covered entity without unreasonable delay and no later than 60 calendar days after discovery. The parties may agree to a shorter reporting period to support the covered entity’s response.

How should the BAA address PHI that cannot be returned or destroyed?

Require the vendor to explain why return or destruction is infeasible and continue protecting the retained PHI under the BAA. Limit further uses and disclosures to the purposes that make return or destruction infeasible, and address deletion when those purposes end. Include copies held by subcontractors and, where relevant, backups or other retained system data.

Share this article

Ready to simplify HIPAA compliance?

Join thousands of organizations that trust Accountable to manage their compliance needs.

Get Started Free Today

Related Articles