Does Computer-Assisted Coding Software Need a BAA?

Computer-assisted coding software needs a business associate agreement (BAA) when its vendor acts as a HIPAA business associate by creating, receiving, maintaining, or transmitting protected health information (PHI) on behalf of a covered entity. The software’s label or installation method does not decide the issue by itself; the vendor’s role and the actual data flows do.

When does computer-assisted coding software require a BAA?

A BAA is generally required when a software vendor performs a service for a covered entity that involves PHI—for example, hosting patient records, processing clinical documentation, generating coding suggestions from identifiable records, or providing support that requires access to those records. The HIPAA definition includes entities that create, receive, maintain, or transmit PHI for regulated functions on a covered entity’s behalf. See 45 CFR § 160.103.

Common examples include a vendor that hosts the coding application and patient data, operates a cloud-based coding service, or remotely troubleshoots the system in a way that permits access to PHI. HHS explains that a software vendor that needs access to a covered entity’s PHI to provide its service is a business associate, and the covered entity must have an agreement in place before allowing that access. See HHS guidance on software vendors.

A BAA is not a substitute for evaluating the vendor’s security or the covered entity’s own HIPAA responsibilities. The covered entity should assess how the service handles PHI, including its safeguards and any subcontractors that process the data.

When might a software vendor not need a BAA?

A vendor may not need a BAA if it simply sells or licenses software and does not access, receive, maintain, or transmit the covered entity’s PHI as part of its service. HHS specifically says that merely providing software does not create a business associate relationship when the vendor has no access to the PHI. A typical example might be software installed and operated by the covered entity, with patient data kept within the entity’s environment and no vendor access for hosting, support, or other services.

That conclusion depends on the actual arrangement, not just a contract statement that the software is “on-premises.” Remote support tools, automatic uploads, vendor-managed backups, or cloud-connected features could change the analysis. Confirm what the vendor and its subcontractors can access and do.

Also, a vendor’s inability to read information does not always mean a BAA is unnecessary. When a cloud provider maintains or processes electronic PHI on behalf of a covered entity, HHS says it can be a business associate even if the information is encrypted and the provider does not have the decryption key. See HHS guidance on HIPAA and cloud computing.

How does PHI access affect business associate status?

Consider both the vendor’s relationship to the covered entity and its handling of PHI. A vendor performing a service on the entity’s behalf that creates, receives, maintains, or transmits PHI may be a business associate. Access can be direct—such as a support technician viewing a patient record—or operational, such as a vendor’s system storing or processing the record.

“Access” does not only mean that a person can read the data on a screen. A service provider that persistently maintains ePHI may have business associate responsibilities even if it cannot decrypt the files. HHS distinguishes that kind of persistent storage from a transmission-only conduit, whose access is generally transient and limited to moving information.

Conversely, a vendor’s general ability to provide technical support does not by itself establish the answer. Determine whether the support arrangement actually permits the vendor to access PHI, including through elevated permissions, diagnostic files, or remote sessions. HHS identifies IT vendors whose maintenance or support involves access to ePHI as examples of business associates.

What data flows should you review before signing a BAA?

Map the full lifecycle of the data, from the moment a record enters the coding workflow until it is returned, deleted, or retained under an agreed arrangement. Review more than the primary application screen: secondary systems and support processes can also handle PHI.

• Inputs and integrations: Identify whether clinical notes, claims, patient identifiers, or other PHI flow from an EHR, encoder, document repository, or billing system into the software.
• Processing and storage: Determine where coding takes place and whether the vendor or its subcontractors store records, temporary files, backups, or processed outputs.
• Logs and diagnostics: Check whether error reports, usage logs, screenshots, or support tickets can include patient details or other identifying information.
• Remote support: Establish whether vendor staff can view or retrieve PHI during troubleshooting, maintenance, implementation, or training.
• External services: Identify any cloud providers or other subcontractors that create, receive, maintain, or transmit PHI for the vendor.
• Data leaving the system: Review exports, APIs, analytics, telemetry, and any transfer of data to another platform. Confirm whether information is PHI and how it will be used.
• End of service: Document how the vendor will return or destroy PHI, including copies held in backups, and what happens if deletion is not feasible.

Use this map to make the agreement match the service in practice. A BAA that covers only the main application may not clearly address support access, backups, or a subcontractor that processes the same data.

What should a computer-assisted coding BAA cover?

HIPAA requires a business associate contract to describe permitted and required uses and disclosures of PHI, require appropriate safeguards for ePHI, address reporting of impermissible uses or disclosures and breaches, and apply relevant protections to subcontractors. It must also address availability of PHI for access, amendment, and accounting obligations, as applicable, and return or destruction of PHI when the agreement ends, when feasible. See 45 CFR § 164.504(e).

For a computer-assisted coding service, make the contract specific to how the tool works. It should clarify which data the vendor may process, which coding and support activities are allowed, whether PHI may be used for product improvement or analytics, and whether any secondary use requires separate authorization. Name or otherwise account for subcontractors that handle PHI, and require the vendor to flow applicable protections down to them.

Also agree on practical operating details: how security incidents are reported, who handles patient-rights requests involving the system, how the parties coordinate security responsibilities, and how PHI is returned or destroyed at termination. The BAA should align with the main services contract and the actual vendor data flows.

What are examples of locally operated coding software that may not require a BAA?

These are examples of deployment patterns, not endorsements or guarantees about particular products:

• A standalone coding tool installed on a covered entity’s own computers, where the vendor does not host or receive patient records.
• A locally operated application that exchanges data only with systems controlled by the covered entity and has no vendor access for support or maintenance.
• A coding program used with synthetic or properly de-identified test records, where no PHI is provided to the vendor.

In each case, verify that the arrangement matches the example. Cloud backups, automatic telemetry, remote diagnostics, or vendor support that can expose PHI may change whether a BAA is needed. The practical takeaway is to base the decision on the vendor’s role and the complete data flow—not solely on whether the software is installed locally.

FAQs

Does a computer-assisted coding vendor need access to PHI to require a BAA?

Often, a BAA is required when the vendor handles PHI on the covered entity’s behalf. That can include maintaining or processing encrypted ePHI, even if the vendor cannot read it. A vendor that only supplies software and has no access to or handling of the covered entity’s PHI generally does not become a business associate merely by providing the software.

Can locally installed coding software be used without a BAA?

Possibly. Local installation alone does not decide the issue. A BAA may not be needed if the vendor does not access, receive, maintain, or transmit PHI as part of its service. Review support access, backups, telemetry, and integrations before reaching that conclusion.

When must a covered entity sign a BAA with a software vendor?

When the vendor is acting as a business associate by providing a service on the covered entity’s behalf that involves PHI, the covered entity should have the required agreement in place before permitting the vendor to access or handle that PHI. The agreement must address the required HIPAA protections for the arrangement.

What data flows should a BAA cover?

It should reflect the PHI the vendor and its subcontractors receive, create, maintain, or transmit—including data used in processing, storage, backups, support, logs, and integrations. It should also address permitted uses and disclosures, safeguards, incident reporting, subcontractors, patient-rights support, and return or destruction of PHI when the service ends.