Skip to main content
A dental practice that conducts covered electronic transactions is generally a HIPAA covered entity. A dental support organization (DSO) may be its business associate when the DSO creates, receives, maintains, or transmits protected health information on the practice’s behalf for functions such as billing, practice management, or IT. The roles depend on the actual entities, functions, data flows, and agreements rather than the DSO or PC label alone.

​
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 DSO and PC

Federal law specifies what a business associate agreement must cover. Among other things, the agreement must 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 Review three recurring gaps:
  1. Signing it late. The BAA must be in place before the DSO touches PHI, that is, before the first patient.
  2. Forgetting subcontractors. A business associate must obtain the required assurances from subcontractors that create, receive, maintain, or transmit PHI on its behalf. In a dental technology stack, review the PMS, imaging platform, clearinghouse, attachment service, billing vendor, and any other service that handles PHI.
  3. One BAA for a multi-PC group. Each PC is a separate covered entity. Each needs its own BAA with the DSO.

​
Business associates are directly liable

Since the HITECH Act and the 2013 Omnibus Rule, business associates have been directly liable for compliance with the Security Rule and specified Privacy Rule provisions. Regulators can enforce those requirements directly against the business associate.3 A DSO acting as a business associate has obligations that arise directly under federal law, including a security risk analysis, administrative, physical, and technical safeguards, workforce training, and breach reporting. Its exposure does not come solely from the BAA.

​
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. Apply the minimum-necessary rule to:
  • Chargeback representment. Your processor and the issuing bank are not covered entities or your business associates. Prove service and authorization without sending clinical notes or radiographs. See Fight 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 and radiograph. Role-based access is a minimum necessary control.

​
PHI in payment workflows

Financial workflows also contain PHI:
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 and the sensors and workstations in operatories
  • Vendor risk review
  • An incident response plan that has been tested
A server-based PMS adds a physical dimension: the machine in the back office holding every chart and radiograph is itself an ePHI asset, with backup, disposal, and access questions a cloud deployment shifts to the vendor.

​
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 DSO 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 treatment details shared on social media when responding to a patient review
  4. Failure to provide patients access to their own records, including radiographs, 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 breach report rather than a random audit. Common triggers include denying a patient access to records, answering a review with clinical detail, or leaving a former employee’s access active.

​
The DSO-PC-specific issues

Record ownership and custody also depend on state law. HIPAA governs uses, disclosures, access, and safeguards, but state dental law may assign ownership or custody to the dentist, professional entity, facility, or another authorized custodian. A DSO may administer systems as a business associate when the facts and agreements support that role. See What a DSO can and can’t do. Segregate records across PCs. Multi-location dental groups typically run one cloud PMS instance across every office. If ten PCs share that instance, each PC’s records belong to that PC. Access controls should reflect entity boundaries, and a dentist 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 DSO often provides a person who serves that role across the PCs. Document the arrangement in the management services agreement (MSA) and the BAA rather than leaving it implicit.

​
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.
Last modified on August 21, 2026