Skip to main content
Under HIPAA, the PC is a covered entity and the MSO is a business associate, because the MSO handles protected health information on the PC’s behalf for billing, scheduling, and IT. That allocation determines who has which obligations, and it is one of the few places where the two-entity structure creates a genuinely clean legal answer.

​
Who is what

The definitions live at 45 C.F.R. § 160.103.1
Banks are generally not business associates for payment activities. HIPAA excludes financial institutions’ payment processing from the business associate definition. This is why you don’t need a BAA with your bank to receive payer EFTs, and also why you must not put PHI in bank memo fields, since the exclusion covers processing payments, not receiving clinical data.

​
The BAA between MSO and PC

Required, and its content is specified. A business associate agreement must, among other things, establish the permitted uses and disclosures, require appropriate safeguards, require reporting of security incidents and breaches, require subcontractors to agree to the same restrictions, and address return or destruction of PHI at termination. The requirements are at 45 C.F.R. § 164.504(e).2 Three things groups get wrong:
  1. Signing it late. The BAA must be in place before the MSO touches PHI, that is, before the first patient.
  2. Forgetting subcontractors. The MSO needs BAAs with its own vendors that handle PHI. Those subcontractors are themselves business associates and are directly liable under HIPAA.
  3. One BAA for a multi-PC group. Each PC is a separate covered entity. Each needs its own BAA with the MSO.

​
Business associates are directly liable

A change many MSOs have not internalized. Since the HITECH Act and the 2013 Omnibus Rule, business associates are directly liable for compliance with the Security Rule and specified Privacy Rule provisions, and are subject to enforcement in their own right.3 Your MSO is not merely contractually exposed through the BAA. It has independent regulatory obligations: a security risk analysis, administrative/physical/technical safeguards, workforce training, and breach reporting.

​
Minimum necessary

Use, disclose, and request only the PHI reasonably necessary for the purpose. It applies to most uses and disclosures, with exceptions including disclosures to the individual, for treatment, and pursuant to an authorization. Where it bites in practice:
  • Chargeback representment. Your processor and the issuing bank are not covered entities or your business associates. Prove service and authorization without sending clinical notes. See Respond to a chargeback.
  • Collections agencies. Send the minimum needed to collect a debt, under a BAA.
  • Investor diligence. Financial and operational data can be shared; patient-identifiable data generally should not. De-identify.
  • Internal access. Your biller does not need access to every clinical note. Role-based access is a minimum necessary control.

​
PHI in the money stack

Often overlooked, because it doesn’t look clinical:
If you build a data warehouse for denial analytics across your PCs, it holds PHI. It needs encryption, access controls, audit logging, a BAA with the hosting provider, and inclusion in your risk analysis. Teams building analytics from 835 data routinely miss this because the project feels like finance rather than clinical.The same applies if you send any of it to an AI model. A zero-data-retention setting at the vendor does not discharge your obligations, and BAA coverage is scoped per service with substantial exclusions. See LLMs, zero data retention, and HIPAA.

​
The Security Rule, briefly

Applies to electronic PHI and requires administrative, physical, and technical safeguards. The requirement most often skipped: A security risk analysis, an accurate and thorough assessment of risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. It is required, it must be updated periodically and on material change, and its absence is one of the most frequently cited findings in OCR enforcement. Right-sized for a small group, the practical baseline:
  • Multi-factor authentication everywhere
  • Encryption in transit and at rest
  • Role-based access, reviewed periodically
  • Audit logging
  • Device and media controls, including personal devices
  • Vendor risk review
  • An incident response plan that has been tested

​
Breach notification

Under the Breach Notification Rule, an impermissible use or disclosure of unsecured PHI is presumed to be a breach unless the covered entity or business associate demonstrates a low probability of compromise through a documented risk assessment considering the specified factors.4 Notification requirements, in outline: Business associate to covered entity: the MSO must notify the PC of a breach, within the timeframe the BAA specifies and no later than the regulation requires. Confirm the BAA’s notification window is short enough for the PC to meet its own deadline. State breach notification laws apply on top of HIPAA and are frequently stricter and faster. A multi-state group faces the union of them.

​
What enforcement looks like

The pattern in OCR settlements and civil money penalties is consistent enough to plan against:
  1. Missing or inadequate security risk analysis, the most commonly cited failure
  2. Lack of BAAs with vendors handling PHI
  3. Impermissible disclosures, including to social media in response to reviews
  4. Failure to provide patients access to their own records, a sustained enforcement priority
  5. Insufficient access controls, including former employees retaining access
  6. Unencrypted lost or stolen devices
Most enforcement follows a complaint or a breach report, not a random audit. The practical implication: the things that generate complaints — a patient denied their records, a review answered with clinical detail, a terminated employee’s access left open — are what actually create exposure.

​
The MSO-PC-specific issues

Records ownership is not just a HIPAA question. The PC owns the medical records; the MSO administers the system holding them. That allocation is a CPOM requirement as well as the basis for the covered-entity/business-associate split. See What an MSO can and can’t do. Segregate records across PCs. If ten PCs share one EHR instance, each PC’s records belong to that PC. Access controls should reflect entity boundaries, and a clinician in one state generally has no treatment relationship justifying access to another PC’s patients. Who is the privacy officer? Each covered entity, each PC, needs one. In practice the MSO often provides a person who serves that role across the PCs. Document the arrangement in the MSA and the BAA rather than leaving it implicit. 42 C.F.R. Part 2 imposes stricter confidentiality on substance use disorder treatment records than HIPAA does. If any of your PCs deliver SUD treatment, that is a separate and more restrictive regime. See Behavioral health.

​
Sources

  1. 45 C.F.R. § 160.103 (definitions of covered entity, business associate, and the financial institution payment-processing exclusion). eCFR.
  2. 45 C.F.R. § 164.504(e) (business associate contract requirements). eCFR.
  3. HITECH Act, Pub. L. 111-5, div. A, tit. XIII; HIPAA Omnibus Rule, 78 Fed. Reg. 5566 (Jan. 25, 2013). HHS OCR, Business Associates.
  4. 45 C.F.R. §§ 164.400–414 (Breach Notification Rule). HHS OCR, Breach Notification Rule.

Related topics

Build a minimum viable HIPAA programPut a BAA in place between MSO and PCLLMs, zero data retention, and HIPAAWhat an MSO can and can't doBilling compliance: the lines you never crossThe 835: how payers answerThe complete agreement stack (checklist)