HIPAA is narrower than people assume and stricter than they expect. It applies to specific kinds of organisations, protects a specific category of data, and — unlike many frameworks — it attaches a written agreement requirement to almost every vendor you involve.
For document collaboration, that combination produces a question most teams have not answered: who signs what, and who can actually see the content.
This article describes HIPAA requirements in general terms. It is not legal advice. Confirm specifics with your compliance function or counsel.
Who is in scope
HIPAA applies to covered entities — healthcare providers, health plans and clearinghouses — and to business associates, which are the vendors and service providers that handle protected health information on their behalf.
The critical point for software selection: a vendor that stores, processes or transmits protected health information on your behalf is a business associate whether or not they call themselves one. There is no neutral position. If they touch the data, an agreement is required.
That makes a hosted collaboration suite a business associate arrangement, with the accompanying contract, due diligence and dependency. Self-hosting changes the shape of the question, because the software runs inside your boundary and the vendor may never handle the data at all. Our data sovereignty article covers the underlying distinction between where data sits and who can reach it.
What counts as protected health information
Protected health information is health information combined with an identifier that makes it traceable to a person.
The identifier list is broad and includes names, dates, contact details, account numbers, device identifiers and full-face photographs, among others. The practical implication for a document platform is blunt: a clinical note, an intake form, an imaging report, a benefits spreadsheet and a schedule all qualify, and they qualify when combined with something as ordinary as a date of birth.
This matters because document repositories are where unstructured clinical and administrative content accumulates. Unlike an electronic health record system with defined fields, a collaboration workspace holds whatever someone pasted in.
The Security Rule in practice
HIPAA’s Security Rule sets out safeguards in three categories. They map almost directly onto platform configuration.
The technical safeguards are where a platform earns its place:
- Unique user identification. No shared accounts, no per-user local credentials. Directory identity with group mapping.
- Audit controls. Who accessed what, retained for the period your policy specifies, and producible on request.
- Encryption in transit and at rest.
- Automatic logoff and session controls.
- Integrity controls — version history that shows what changed and when.
Note what is not on the list: a vendor certification. There is no HIPAA certification. Vendors sometimes describe themselves as “HIPAA compliant”, which is a marketing claim rather than an accreditation. What exists is the agreement, the risk analysis and the safeguards you can evidence.
The business associate agreement question
Every business associate relationship needs a written agreement that, among other things, restricts how the associate may use the information and requires appropriate safeguards and breach notification.
If you self-host, the calculus changes in a way that is worth being precise about:
| Relationship | Agreement needed | What the vendor can access |
|---|---|---|
| Hosted suite handling ePHI | Yes, business associate agreement | Content, in the vendor’s infrastructure |
| Self-hosted suite you operate | Usually not a business associate relationship | Nothing, unless they provide support access |
| Self-hosted with vendor support accessing data | Depends on the support arrangement | Whatever the support session exposes |
The third row is the one that gets missed. A support engineer with access to your environment, even temporarily, changes the analysis. If you go self-hosted, control support access explicitly and log it.
Where the AI question bites hardest
Enabling an AI assistant that reads clinical or benefits correspondence sends content to an inference endpoint. That is a disclosure, and it needs to be inside the business associate arrangement that covers it.
The questions are the ones in our AI agents security checklist, with the stakes raised:
- Where does inference happen, and is the provider a business associate?
- Is the content retained, and for how long?
- Does retrieval respect clinical need-to-know, or does it search everything the service account can see?
A self-hosted suite with a configurable model endpoint lets you point inference at infrastructure inside your own boundary, which keeps the disclosure question off the table for that path. If you point it at an external model provider, you have simply moved the business associate relationship rather than removed it.
Working with vendors who are not business associates
Self-hosting changes which vendors you need agreements with, and it is worth being precise about where the line sits.
A vendor is a business associate if it creates, receives, maintains or transmits protected health information on your behalf. That is a functional test, not a labelling one. A vendor that calls itself a platform provider is a business associate if the data reaches them.
The distinctions that matter in practice:
| Vendor activity | Business associate relationship |
|---|---|
| Hosting the software that stores the content | Yes |
| Shipping you software you operate yourself | No, unless support reaches the data |
| Remote support with access to the environment | Depends on what the session exposes |
| Monitoring that receives logs containing identifiers | Yes, if the logs carry protected health information |
| Backup or disaster recovery in your control | No |
Two rows catch organisations out.
Support access. A support engineer who can view your environment, even briefly, has the functional ability to receive protected health information. Either prevent it technically or bring it inside an agreement.
Telemetry. Crash reports, error logs and product analytics frequently contain fragments of user content. A telemetry pipeline is a disclosure path, and it is usually enabled by default.
The practical approach is to inventory every route by which content or identifiers could reach a third party, then decide for each whether to disable it or contract for it. Disabling is cheaper.
Breach notification
The notification rule has deadlines and a presumption that any impermissible access is a breach unless you can demonstrate a low probability of compromise — a risk assessment rather than an assumption.
Meeting that requires being able to answer, quickly and from your own systems: which records were involved, who accessed them, and over what period.
Practically:
- Access logging that covers reads, not just writes. Most incidents are disclosure, not alteration.
- The ability to enumerate affected individuals. If you cannot produce that list, you cannot notify.
- A tested response process. The deadline does not allow for designing the process during the incident.
- Detection you own, if self-hosted. Nobody else will tell you.
A checklist before onboarding clinical content
Scope
- Are you a covered entity or a business associate?
- Which repositories will hold protected health information?
- Is every vendor touching that content under an agreement?
Controls
- Directory-based identity with group mapping, and deprovisioning on leave?
- Access logs covering reads, retained to policy, and producible?
- Encryption in transit and at rest?
- Session controls and automatic logoff?
AI
- Is inference inside your boundary, or with a business associate?
- Does retrieval honour need-to-know?
Response
- Who detects, who assesses, who notifies, and within what window?
- Can you enumerate affected individuals from your own logs?
- When was the restore last tested?
Our financial services analysis covers the same structural argument for a different regulator, and the self-hosted collaboration guide covers what running the platform requires.