← All posts
Filed in / hipaa · compliance · small-business

HIPAA Compliance for Medical Billing Companies: Client Separation

In this piece
  1. 01 Is a medical billing company a business associate?
  2. 02 What does minimum necessary mean when you serve several clients?
  3. 03 Where does client data get commingled?
  4. 04 How do you separate each client’s PHI across your tools?
  5. 05 How often should you review access by client?
  6. 06 What can each client’s BAA require?
  7. 07 How do you offboard a client cleanly?
  8. 08 Per-client separation checklist
  9. 09 Test client separation before your next client
  10. 10 Next step

For a medical billing company serving several covered entities, HIPAA compliance includes keeping each client’s PHI inside that client’s boundary. Each client relationship comes with its own business associate agreement, its own permitted uses, and its own exit terms. Your mailboxes, shared drives, chat channels, and reports should reflect those boundaries.

The same approach applies to revenue cycle management firms, coding services, transcription vendors, and similar business associates.

Is a medical billing company a business associate?

Usually, yes. The HIPAA business associate definition in 45 CFR 160.103 covers a person who creates, receives, maintains, or transmits PHI on behalf of a covered entity for listed functions, and billing is named alongside claims processing and practice management. The same definition includes subcontractors that handle PHI on behalf of a business associate.

HHS states that business associates are directly liable for certain HIPAA requirements, including Security Rule compliance, impermissible uses and disclosures, minimum necessary, breach notification to the covered entity, and subcontractor agreements. See the HHS fact sheet on business associate direct liability.

Under 45 CFR 164.502(e), a covered entity may let a business associate handle its PHI only after obtaining satisfactory assurances, documented in a written agreement. That agreement covers one client’s information. It does not authorize you to mix that information with another client’s work.

What does minimum necessary mean when you serve several clients?

45 CFR 164.502(b) requires covered entities and business associates to make reasonable efforts to limit PHI to the minimum necessary for the intended purpose. The implementation specifications in 45 CFR 164.514(d) are written for covered entities: identify the workforce roles that need PHI, the categories each role needs, and limit access accordingly. That structure is a practical model for a billing vendor too.

The Security Rule adds information access management at 164.308(a)(4). Its addressable specifications call for policies to authorize access and to establish, document, review, and modify each user’s access.

The regulations do not use the phrase “per-client access.” In a multi-client operation, though, the client is often the most natural boundary for a minimum necessary decision. A coder assigned to two clinics generally has no work reason to browse a third clinic’s denials folder. The role matrix approach from our role-based access control guide translates well: define roles, then scope each role to the clients it serves.

Where does client data get commingled?

Commingling tends to build up as a company adds clients faster than it adds structure. Watch for these patterns:

  • One shared inbox for every client. Remittance questions, records requests, and denial appeals for all clients land in one mailbox that everyone can read.
  • One big shared drive. Client folders sit side by side under a single permission set, so access to one means access to all.
  • Exports on laptops. Aging reports and claim extracts are downloaded for a spreadsheet task and never removed. The ePHI inventory checklist helps find these copies.
  • Blanket access across clients. Staff receive every client’s folders and practice management logins “in case they need to cover,” and that access never gets trimmed.
  • Cross-client chat channels. A general team channel collects screenshots of patient accounts.
  • Combined reports. A dashboard or spreadsheet pulls several clients’ patient-level detail into one file that then gets emailed to one client.
  • Misdirected statements. A patient statement or appeal packet for one client’s patient goes to another client or the wrong recipient.

Misdirected statements carry the most direct breach exposure. Under 45 CFR 164.402, an impermissible disclosure is presumed to be a breach unless a documented risk assessment shows a low probability that the PHI was compromised. A shared template or shared print queue that makes cross-client mistakes easy is worth fixing before it produces an assessment.

How do you separate each client’s PHI across your tools?

Give each client a consistent set of containers, and grant access through groups tied to client assignment rather than to individuals.

  • Mail: a dedicated shared mailbox or alias per client, with membership limited to the assigned team. The email guide covers message handling in more depth.
  • Files and docs: a top-level folder per client with its own permissions, so subfolders inherit the client boundary. Avoid a parent folder that grants access to all clients at once. The file sharing guide covers testing link and folder access.
  • Chat: one channel per client for account-specific discussion, with general channels kept free of patient details.
  • Reports: generate patient-level reports per client. Keep any cross-client view aggregated or de-identified, and confirm with counsel whether each BAA permits that use.

Put the client identifier first in mailbox, folder, channel, and file names so staff see it before they attach or send.

How often should you review access by client?

Review each client’s access list on a set schedule and whenever staffing or assignments change. A quarterly cadence is a reasonable starting point for many small vendors. Your risk analysis should set the actual frequency.

Have the client’s account lead confirm who is in the client’s groups, whether each person still works that account, and whether individual exceptions remain. Record the date, reviewer, and changes made as evidence that access review happens in practice.

Reassignment is the common gap. When a biller moves from one client to another, removing the old client’s access matters as much as adding the new one. Departures are a separate process covered in the HIPAA employee offboarding checklist.

What can each client’s BAA require?

The required contract terms appear in 45 CFR 164.504(e), and HHS publishes sample business associate agreement provisions. The sample language leaves room for negotiated specifics, so keep a short term summary for each client.

  • Incident reporting. 45 CFR 164.410 requires a business associate to notify the covered entity of a breach of unsecured PHI without unreasonable delay and no later than 60 calendar days after discovery. The HHS sample provisions note that parties may agree to a stricter timeframe. One client may want notice within days while another follows the regulatory outer limit.
  • Subcontractor flowdown. Your BAA must require you to ensure that subcontractors handling PHI agree to the same restrictions and conditions. That includes clearinghouses, offshore coders, transcription partners, and cloud services that handle a client’s PHI.
  • Return or destruction at termination. When feasible, you return or destroy the client’s PHI and retain no copies. Where that is not feasible, the agreement’s protections extend to what remains.

OCR has brought enforcement against billing-side business associates. In its settlement with iHealth Solutions, a provider of coding, billing, and IT services, OCR described a network server left unsecured on the internet, and the resolution agreement cites the lack of an accurate and thorough risk analysis.

Have counsel review the agreements. The cloud vendor BAA guide covers questions to ask your own vendors.

How do you offboard a client cleanly?

If each client’s PHI already lives in defined containers, the exit becomes a checklist instead of a search.

  1. Read the termination clause. Confirm whether the client expects return, destruction, or transfer to a successor vendor, and in what format.
  2. List every location. Include the client’s mailbox, folders, chat channel, report outputs, practice management access, local exports, and subcontractor copies.
  3. Return or transfer first. Deliver the agreed export and get written confirmation of receipt before deleting anything.
  4. Remove access. Retire the client’s groups, revoke logins to the client’s systems, and close the client’s channel.
  5. Address retained copies. Identify anything that cannot feasibly be destroyed, such as backups or records you must keep for your own legal obligations, and document why.
  6. Collect subcontractor confirmations. Ask each subcontractor to confirm return or destruction of that client’s data.
  7. Record the closeout. Keep a dated summary of what was returned, destroyed, or retained, and who approved it.

Per-client separation checklist

Area Separation practice Evidence to keep
Agreement Signed BAA with key terms tracked Term summary: reporting window, subcontractors, exit
Mail Dedicated client mailbox or alias Current membership list
Files and docs Client-scoped top-level folder Permission export or screenshot
Chat Client-specific channel, no PHI in general channels Channel membership list
Reports Patient-level reports scoped to one client Report distribution list
Devices Rules for local exports and cleanup Device review notes
Access review Scheduled review by account lead Dated review record
Subcontractors Flowdown agreements per client data flow Subcontractor list and agreements
Offboarding Closeout procedure per BAA terms Return, destruction, or retention record

Test client separation before your next client

If your clients currently share one inbox, one drive, or one team channel, request a healthcare pilot to test per-client separation with two fictional clients. IRONKEEP brings mail, files and docs, chat, and meetings into one workspace with folder-level sharing permissions, team mailbox controls, SCIM group lifecycle, audit logs, retention, and export. IRONKEEP signs a BAA during onboarding when it creates, receives, maintains, or transmits ePHI for your organization. Run the test with synthetic records only, and review BAA scope before any ePHI enters the workspace. Your organization still owns its HIPAA policies, risk analysis, and configuration. The workspace is in private beta.

Next step

Pick your newest client and map where its PHI lives today across mail, files, chat, reports, and laptops. Compare that map to the checklist above, fix the largest gap, and repeat for the next client.

Healthcare · Private beta

Scope your healthcare workspace.

Evaluate email, files and docs, and team access with IRONKEEP. Start with your workflow and BAA needs.

Request a healthcare pilot