Do Billing Companies Need a BAA? HIPAA Rules Explained

Every billing relationship touches PHI — patient names, dates of service, diagnoses, insurance IDs flow through claims, remits, and worklists daily. Under HIPAA, any vendor touching that data on your behalf is your business associate, and the law requires a written business associate agreement before they touch a single record. This isn't optional paperwork; it's one of the first things OCR asks for in an investigation.

Who counts as a business associate

A business associate is any person or company that creates, receives, maintains, or transmits PHI on behalf of a covered entity. That plainly includes:

• Billing companies and RCM services — they live in your PHI all day.
• RCM and practice management software vendors — including cloud-hosted systems where the vendor can access the data.
• Clearinghouses — they translate and route your PHI-bearing claim files.
• AI and analytics vendors — any tool that processes claim or clinical data, including AI coding assistants, is handling PHI.

The test is access, not intent: if the vendor can access PHI in the course of the work, they're a business associate. "We never look at it" isn't a defense.

What the BAA must cover

HIPAA specifies the required elements. Your BAA should address:

• Permitted uses and disclosures — the vendor may use PHI only as the agreement allows, typically to perform the contracted billing functions.
• Safeguards — administrative, physical, and technical protections for ePHI.
• Breach notification — the vendor must report breaches and security incidents to you promptly so you can meet your own notification duties.
• Subcontractor flow-down — the vendor's subcontractors that touch PHI need BAAs with the vendor, with equivalent protections.
• Return or destruction — what happens to PHI when the relationship ends.
• Compliance with the Security Rule — business associates are directly liable for Security Rule failures.

Red flags in vendor contracts

• No BAA offered. A billing vendor that won't sign a BAA is disqualifying — full stop.
• "We're just a conduit." The conduit exception is narrow (think postal service). A billing company that stores, processes, or works your claims is not a conduit.
• Vague breach-notification terms. "Reasonable efforts" isn't a timeline. You need defined notification windows.
• Data-use overreach. Watch for clauses letting the vendor use your de-identified or aggregate data beyond the contracted purpose — negotiate these explicitly.
• AI sub-processors undisclosed. If the vendor's AI features send data to third-party AI APIs, that's a sub-processor handling your PHI — it needs to be in the agreement. (This is one reason to prefer vendors whose AI runs on private infrastructure.)

Making BAAs operational, not just signed

• Execute before go-live. The BAA must be signed before the vendor touches PHI — that includes implementation, data migration, and pilots.
• Keep a vendor BAA inventory. Every vendor with PHI access, agreement date, and renewal terms in one list. Review it annually — vendors get acquired and sub-processors change.
• E-signing is fine. Electronic signatures on BAAs are valid; what's required is the agreement's content and execution, not wet ink. ClaimPaid includes built-in BAA e-signing so the agreement is executed inside the platform before any PHI flows.
• Revisit on scope changes. New modules, new AI features, or new data feeds can change what PHI a vendor touches — update the BAA, don't assume the old one covers it. Our RCM software buyer's guide includes BAA posture in its evaluation criteria.