> ## Documentation Index
> Fetch the complete documentation index at: https://dso.getlemma.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Build a minimum viable HIPAA program

> A practical HIPAA program for a small dental group: security risk analysis, policies, training, business associate agreements, safeguards, and breach response.

A HIPAA program for a small DSO-PC dental group has six components. The one most often missing, and most often cited in enforcement, is the **security risk analysis**.

## Prerequisites

* A designated privacy officer and security officer for each PC (often the same person, often DSO-provided)
* The DSO–PC BAA executed, see [Put a BAA in place](/guides/agreements/draft-a-baa)
* An inventory of every system and vendor that touches PHI, starting with the PMS, imaging software, and attachment vendor

## Who is responsible for what

|                      | The PC                                                                                                    | The DSO                                                                                    |
| -------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| **Role**             | Covered entity                                                                                            | Business associate                                                                         |
| **Obligations**      | Privacy Rule, Security Rule, Breach Notification                                                          | Security Rule, specified Privacy Rule provisions, Breach Notification, **directly liable** |
| **Privacy officer**  | Required per covered entity                                                                               | Not applicable                                                                             |
| **Security officer** | Required                                                                                                  | Required                                                                                   |
| **In practice**      | The DSO usually provides the people who fill these roles across the PCs, document that in the MSA and BAA |                                                                                            |

**Business associates are directly liable.** Since the HITECH Act and the 2013 Omnibus Rule, your DSO has independent regulatory obligations, its own risk analysis, safeguards, training, and breach reporting. It is not merely contractually exposed through the BAA.<sup>1</sup>

## The six components

<Steps>
  <Step title="Security risk analysis, do this one first">
    **This is required, and its absence is among the most frequently cited findings in OCR enforcement.** It must be an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic PHI.

    A right-sized version:

    1. **Inventory ePHI** across every system, device, and location where it resides. Include the PMS, imaging server, sensor-connected operatory workstations, attachment repository, clearinghouse portal, backups, and analytics warehouse.
    2. **Identify threats and vulnerabilities** per asset
    3. **Assess likelihood and impact**
    4. **Document current safeguards**
    5. **Rank residual risk**
    6. **Write a remediation plan** with owners and dates
    7. **Update annually and on material change**, new PMS, new location, new entity

    HHS and ONC publish a Security Risk Assessment Tool suitable for small practices.<sup>2</sup>
  </Step>

  <Step title="Policies">
    A minimum set, actually written and actually followed:

    * Notice of Privacy Practices (and it must be provided to patients)
    * Uses and disclosures; minimum necessary
    * Patient rights: access, amendment, accounting of disclosures, restrictions
    * Access control and workforce authorization
    * Device and media controls, including a policy for intraoral photos and other PHI on personal devices
    * Password and authentication standards
    * Encryption
    * Audit logging and review
    * Incident response and breach notification
    * Sanctions for workforce violations
    * Business associate management
    * Retention and destruction

    A short policy people follow beats a long one nobody reads.
  </Step>

  <Step title="Training">
    Train **both entities' workforces** at onboarding and annually. Record completion dates so you can demonstrate who received the training.

    Include role-specific content: front desk staff face different risks than billers, who face different risks than the clinical team.
  </Step>

  <Step title="BAA inventory">
    Every vendor handling PHI, with execution dates, breach notification windows, and review dates. The dental stack is longer than it looks:

    * The **PMS vendor**, for any cloud-hosted or vendor-accessible system
    * The **imaging software vendor**, radiographs are PHI
    * The **attachment vendor**, whose repository may hold radiographs, periodontal charts, and narratives for payer retrieval under an NEA-number workflow
    * The **clearinghouse**, and the RCM vendor if billing is outsourced
    * Patient-communication, recall, and online-scheduling tools
    * The **membership plan platform**, if it holds patient data
    * Mailing and e-statement vendors

    <Warning>
      **A denial analytics warehouse built from 835 data holds PHI.** Teams building it as a finance project routinely miss the BAA, the encryption, and its inclusion in the risk analysis. See [HIPAA for DSO-PC operators](/concepts/compliance/hipaa-fundamentals).

      **AI vendors are the same problem with an extra trap:** BAA coverage is scoped per service with substantial exclusions, and a zero-data-retention setting is not a substitute for the agreement. See [LLMs, zero data retention, and HIPAA](/concepts/compliance/llms-and-zero-data-retention).
    </Warning>

    See [Put a BAA in place](/guides/agreements/draft-a-baa).
  </Step>

  <Step title="Breach response plan">
    Written, and tested at least once.

    Under the Breach Notification Rule, an impermissible use or disclosure of unsecured PHI is **presumed to be a breach** unless you demonstrate a low probability of compromise through a documented risk assessment considering the specified factors.<sup>3</sup>

    | Scale                           | Notify               | When                                                             |
    | ------------------------------- | -------------------- | ---------------------------------------------------------------- |
    | Any breach                      | Affected individuals | Without unreasonable delay, no later than 60 days from discovery |
    | 500+ in a state or jurisdiction | Prominent media      | Same timeframe                                                   |
    | 500+                            | HHS                  | Contemporaneously with individual notice                         |
    | Under 500                       | HHS                  | Annually, within 60 days after year end                          |

    **State breach laws apply on top** and are frequently stricter and faster. A multi-state group faces the union of them.

    Confirm the **BAA's notification window is short enough** for the PC to meet its own deadline.
  </Step>

  <Step title="Security basics">
    The controls that prevent most incidents:

    * **Multi-factor authentication wherever available.** The 2024 Change Healthcare compromise reportedly involved a remote-access service without MFA. The resulting outage affected dental practices, and the ADA publicized emergency funding for dentists.<sup>4</sup>
    * **Encryption** in transit and at rest, including laptops and mobile devices
    * **Role-based access**, reviewed quarterly
    * **Prompt offboarding**, terminated employees' access removed same-day
    * **Audit logging**, with periodic review
    * **Patching** on a defined cadence, including imaging servers and operatory workstations
    * **Backups**, tested by actually restoring
    * **Email security**, phishing is the most common entry point
  </Step>
</Steps>

## Where enforcement actually comes from

Most enforcement follows a **complaint or a breach report**, not a random audit. The recurring patterns:

1. **Missing or inadequate security risk analysis**
2. **No BAA** with a vendor handling PHI
3. **Impermissible disclosures**, including responding to an online review with clinical detail
4. **Failure to provide patients access** to their own records, including radiographs requested for a second opinion or transfer to a new dentist
5. **Insufficient access controls**, including former employees retaining access
6. **Unencrypted lost or stolen devices**

Train staff not to include clinical details in responses to online reviews or confirm that a reviewer was a patient. A well-meaning attempt to correct the public record can disclose PHI and has led to OCR enforcement.

## DSO-PC-specific items

* **A BAA per PC.** Each professional entity is a separate covered entity.
* **Segregate records across PCs** in a shared PMS instance. A dentist in one state generally has no treatment relationship justifying access to another PC's patients.
* **Document who serves as each PC's privacy officer**, especially where the DSO provides the person.
* **Never put PHI in bank memo fields.** The business-associate exclusion for financial institutions covers payment processing, not the receipt of clinical information.

## Verify it worked

* [ ] Security risk analysis completed, documented, with a remediation plan
* [ ] Policy set written and accessible
* [ ] Training delivered and documented, both entities
* [ ] BAA inventory complete, including PMS, imaging, attachments, clearinghouse, and analytics infrastructure
* [ ] Breach response plan written and tested
* [ ] MFA everywhere; encryption in transit and at rest
* [ ] Access reviewed quarterly; offboarding same-day
* [ ] A BAA per PC
* [ ] Privacy officer designated per covered entity
* [ ] Annual review calendared

## Sources

1. HITECH Act, Pub. L. 111-5, div. A, tit. XIII; HIPAA Omnibus Rule, 78 Fed. Reg. 5566 (Jan. 25, 2013). HHS OCR, [Business Associates](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html).
2. HHS/ONC, [Security Risk Assessment Tool](https://www.healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool).
3. 45 C.F.R. §§ 164.400–414. HHS OCR, [Breach Notification Rule](https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html).
4. ADA News, [Funding assistance available to dentists impacted by Change Healthcare cyberattack](https://adanews.ada.org/ada-news/2024/april/funding-assistance-available-to-dentists-impacted-by-change-healthcare-cyberattack/) (Apr. 2024).
