HIPAA compliant file sharing: a complete guide for healthcare teams

No product is "HIPAA compliant" by itself HIPAA compliance is a property of an organisation, not of software. A vendor can be a business associate, can sign a BAA, and can provide features that support your safeguards — but the obligation, the risk analysis and the training remain yours. Any tool marketed as making you compliant is telling you something the rule does not say.

The safeguards you are actually implementing The Security Rule groups requirements into administrative, physical and technical safeguards. For file sharing, four technical ones dominate: - **Access control.** Unique user identification, and access limited to those who need it. - **Audit controls.** Records of activity in systems containing protected health information. - **Integrity.** Assurance that PHI has not been improperly altered or destroyed. - **Transmission security.** Protection of PHI moving over a network.

How client-side encryption maps to them - **Access control** becomes cryptographic: if you were not sealed a key, no permission bug, misconfiguration or administrator action grants you a read. - **Audit controls** are satisfied by an append-only trail of grants, revocations, share creation and access events, which records who and when without recording content. - **Integrity** is provided by authenticated encryption: modified ciphertext fails to decrypt rather than silently returning corrupted data. - **Transmission security** is stronger than TLS alone, because the payload is already ciphertext before it leaves the device — the transport is protecting an envelope that is itself sealed.

Where PHI actually leaks in small practices Not through cryptanalysis. Through a shared front-desk login, an image saved to a consumer photo app that classifies it automatically, a records request answered with an email attachment, a departing locum still in a shared folder, and a laptop that was never removed from an active session list. Each of these has a mundane, mechanical fix: individual identities, encrypted storage without classification, expiring protected links, key rotation on removal, and session review.

The BAA question, answered plainly If your policy requires a signed Business Associate Agreement, that is a hard requirement and you should treat it as one. DRIVUNO does not sign BAAs today, and we publish that rather than implying otherwise; our compliance page tracks the current state. What we do provide today is an architecture in which we are not able to read PHI at all — which is a different, and in some respects stronger, statement than a contractual promise not to.

A practical checklist 1. Give every staff member their own identity; abolish shared logins. 2. Store clinical images somewhere with no automated classification. 3. Replace record-request attachments with passphrase-protected, expiring links. 4. Review device and session lists monthly. 5. Rotate keys the day someone leaves, and keep the log entry. 6. Write down which vendors hold PHI, which can read it, and which have signed agreements.

Step 6 is the one most practices skip, and the one an investigator will ask for first.