HIPAA for Small Healthcare-Adjacent Businesses: What Actually Applies

Short answer: HIPAA can cover small US healthcare-adjacent businesses such as dental, physio, and therapy practices when they bill electronically, and it covers their vendors as business associates who must sign an agreement before handling patient data. Being small doesn't exempt anyone.

A note before anything else: HIPAA is a US federal law. It applies to businesses operating under US jurisdiction — this post is written for that audience. If you're reading from Canada, you're not off the hook for protecting patient or client information, but you're generally governed by a different set of laws (PIPEDA federally, plus provincial health-privacy statutes like Ontario's PHIPA) — different enough that they deserve their own post rather than a paragraph tacked onto this one. The one exception worth knowing: a Canadian vendor that handles PHI for a US healthcare client (billing, IT support, cloud hosting) can itself be a HIPAA business associate and be asked to sign a BAA.

For US readers: a lot of small, local businesses assume HIPAA is something that happens at hospitals — big systems, big budgets, dedicated compliance staff. A one-chair dental practice, a two-room physio clinic, a med spa, or a solo therapist's private practice can be just as squarely covered as a hospital network, and so can the ordinary small businesses that serve them — the scheduling app, the billing service, the IT contractor with remote access to the practice's computers. The rules don't scale down just because the business does. What scales down is how much infrastructure it takes to meet them.

Who's actually covered: covered entity vs. business associate

HIPAA sorts organizations into two categories, and which one you are changes what you're directly on the hook for.

Covered entities are health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically in connection with certain standard transactions — most commonly, billing a health plan electronically or through a clearinghouse. In practice, that last part catches almost every modern provider: if your practice submits insurance claims electronically, or even submits paper claims that a billing service or clearinghouse turns into an electronic transaction on your behalf, you're a covered entity, regardless of how small the practice is. A solo chiropractor with one employee is covered by the exact same rule as a hospital system.

Business associates are everyone else who touches that data on a covered entity's behalf without being part of its own workforce. HHS defines a business associate as a person or entity that performs functions or activities on behalf of a covered entity that involve access to protected health information — think billing companies, IT support with access to systems holding patient data, scheduling or texting platforms, cloud storage providers, and even a subcontractor that a business associate itself hires if that subcontractor also touches the data. If a vendor doesn't need to touch patient information to do its job — the company that services the practice's HVAC, for instance — it isn't a business associate just because it happens to walk past a filing cabinet.

Some businesses in this space are neither. A med spa that only does non-medical cosmetic services and never bills insurance or transmits standard healthcare transactions may not meet the covered-entity definition at all — though the moment it adds any medical service billed electronically, that can change. This is exactly the kind of scoping question — "which rules actually apply to this business" — that's worth answering deliberately instead of assuming either way.

What the Privacy Rule practically requires

The HIPAA Privacy Rule governs how protected health information (PHI) — identifiable information about a patient's health, care, or payment for care — can be used and disclosed. For a small practice, the practical version comes down to a short list:

• Only use or share PHI for the purposes the rule actually permits — treatment, payment, and healthcare operations are the routine, everyday ones. Many other uses need the patient's written authorization, though the rule lists specific exceptions (for example, disclosures required by law or for public health).
• The minimum necessary standard. For most uses and disclosures, a covered entity has to take reasonable steps to limit PHI to the minimum necessary to accomplish the purpose — the front desk doesn't need a patient's full chart to confirm an appointment. Note that this standard has real exceptions: it doesn't apply to disclosures for treatment, to the patient themselves, or when the patient has authorized the specific disclosure, among others.
• Give patients their rights — most importantly, the right to get a copy of their own records and the right to an accounting of certain disclosures.
• Have a Notice of Privacy Practices that patients can actually see, and designate someone (even part-time, even the owner) responsible for privacy compliance.

None of this requires a legal department. It requires deciding, in writing, who's responsible and what "the minimum necessary" looks like for your own front desk, your own intake forms, and your own vendors.

What the Security Rule practically requires

Where the Privacy Rule is about when PHI can move, the Security Rule is about how it's protected — specifically electronic PHI. It applies to business associates the same way it applies to covered entities: the same administrative, physical, and technical safeguard requirements, and business associates are directly liable (civilly) for Security Rule compliance, with potential criminal liability for knowing misuse of health information — this isn't just the covered entity's problem to pass downstream.

The three safeguard categories, in plain terms for a small practice:

• Administrative — who's responsible for security, a documented risk analysis of what could go wrong, workforce training, and a plan for what happens if something does (an incident response plan, even a short one).
• Physical — locked doors and screens for anywhere PHI is stored or viewed, control over who can access devices and paper records, and a process for wiping or destroying old hardware before it's discarded or resold.
• Technical — access controls (unique logins, not one shared password), encryption of ePHI where reasonable and appropriate, and audit logs that show who accessed what.

The Security Rule is deliberately flexible about how a covered entity or business associate meets these standards — it explicitly allows an organization to take its own size, capabilities, and the cost of security measures into account when deciding what's reasonable and appropriate. A two-person clinic isn't expected to run the same security operation as a hospital network. It is expected to have actually thought about it and documented the decision, not to have skipped the analysis entirely.

One thing to watch: in January 2025, HHS proposed a major update to the Security Rule that would make several of today's "reasonable and appropriate" safeguards, including encryption and multi-factor authentication, firm requirements. As of this writing, that proposal has not been finalized, so the description above reflects the rule as it currently stands.

Business Associate Agreements (BAAs)

If a covered entity works with any vendor that creates, receives, maintains, or transmits PHI on its behalf, HHS is explicit that a written business associate contract — a BAA — is required before that data starts flowing. The BAA has to spell out what the vendor is permitted to do with the PHI, require the vendor to comply with the Security Rule, bar it from any use the covered entity itself couldn't make (with narrow exceptions), and cover breach reporting, subcontractors, and returning or destroying the data when the relationship ends. No BAA in place means the vendor relationship itself is a compliance gap, independent of whether the vendor ever actually mishandles anything.

This is one of the most common gaps in small healthcare-adjacent businesses, because it's invisible until someone asks. Software gets adopted the way small businesses adopt any tool — cheapest, fastest, whoever answered the phone — and "does this vendor sign a BAA" is a question that has to be asked on purpose; it's never asked by accident.

Breach notification basics

If PHI is compromised, the HIPAA Breach Notification Rule sets out who has to be told and how fast, and the timeline depends on scale:

• Affected individuals must be notified without unreasonable delay, and in no case later than 60 calendar days after the breach is discovered.
• Breaches affecting 500 or more individuals must also be reported to HHS's Secretary at the same time individuals are notified (so, within that same 60-day limit) — this is the tier that shows up publicly on HHS's breach portal.
• Breaches involving more than 500 residents of a single state or jurisdiction additionally require notice to prominent media outlets serving that state or jurisdiction.
• Breaches affecting fewer than 500 individuals still require notifying affected people, but the report to HHS can be logged and submitted annually, within 60 days after the end of the calendar year in which the breach was discovered, rather than alongside the individual notices.

A small practice is far more likely to face a small breach — a stolen laptop, a misdirected fax, a vendor's mishandled export — than a 500-record headline event. Small doesn't mean exempt from notifying the patients affected; it means the reporting rhythm to HHS is annual instead of alongside the patient notices.

Scenario: the referral coordinator's spreadsheet

(This is a composite, illustrative scenario built from a pattern common in small-practice HIPAA gaps — not a specific real business's story.)

A physical therapy clinic hires a part-time referral coordinator to track which patients came from which referring physicians, to follow up on missed appointments, and to flag patients due for a re-evaluation. To do this well, the coordinator builds a shared spreadsheet — patient name, date of birth, diagnosis code, referring physician, and treatment notes — and stores it in a personal cloud drive account so she can update it from home in the evenings, the same account she uses for her own photos and budgeting.

Nobody set out to create a problem. The clinic's practice-management software already had proper access controls and audit logging, but the coordinator's workaround sat entirely outside it — a second, unmanaged copy of PHI, on a consumer account the clinic's owner didn't know existed, with no BAA (the personal cloud provider had never been engaged as a business associate for anything, let alone this), no access logging, and diagnosis information far beyond what a scheduling and follow-up function actually needed — a clear minimum-necessary problem layered on top of the missing BAA.

The gap surfaced months after the coordinator left the clinic. Her clinic accounts had been disabled when she left, but a later access review turned up something offboarding hadn't covered: the personal cloud folder still syncing from the front-desk computer, with no way to confirm whether it had ever been deleted or backed up elsewhere. The clinic had to treat it as a potential breach: a documented investigation, legal review of whether individual notification was required, and — because it couldn't be ruled out — notifying the patients whose information had been in that spreadsheet. Nothing indicates the data was ever misused. The clinic still spent real time and legal cost establishing that, and it never would have needed to if the workaround had gone through a sanctioned tool instead of a personal one.

What closing this gap actually looks like: any tool used to work with patient information — including a spreadsheet, and including a personal cloud account nobody thinks of as "a vendor" — needs to be a sanctioned, BAA-covered system with real access controls, not a convenience someone built on their own initiative. And any role handling PHI should get only the fields it actually needs for its function, not a full export because it was easier to build that way.

What this looks like in practice for most small practices

• Figure out which category you're in — covered entity, business associate, both, or (for some cash-pay, non-medical services) neither — before assuming either way.
• Inventory every vendor that touches patient information, and confirm a signed BAA exists for each one before data flows, not after.
• Do an actual risk analysis, even a modest one — what PHI you hold, where it lives, who can access it, and what could go wrong — and write it down. The Security Rule expects this to scale to your size, but it does expect it to exist.
• Apply minimum necessary as a habit, not a policy document nobody reads — give each role only the PHI its function actually requires.
• Have a breach response plan before you need one — who investigates, who decides whether notification is required, and how fast you can move.

If you want a quick, no-signup sense of where your own business might have a gap — including patient information handling and the other areas that trip up local businesses — the free Compliance & Accessibility Self-Check walks through it in plain English, and nothing entered leaves your browser.

A note on what this is and isn't: this post is educational — general patterns, written as I work through this material myself, not a substitute for reading the actual Privacy and Security Rules that apply to your specific practice or talking to a healthcare compliance professional about your specific setup. It isn't legal advice, and it isn't a HIPAA compliance assessment of your business. If any part of the scenario above sounds familiar, that's worth a direct conversation with a qualified professional, not just a blog post.