What HIPAA expects, and where a tool like Dropshare fits

HIPAA is organised around two ideas: covered entities and business associates are responsible for PHI, and they have to put administrative, physical and technical safeguards in place to protect it. Most file-sharing conversations get tangled up in the business-associate side of that, because traditional services hold plaintext copies of whatever you upload. If the provider can read it, they are handling PHI on your behalf, which drags in Business Associate Agreements, audit obligations and the whole apparatus of §164.308 and §164.314.

Dropshare is deliberately designed so that we do not hold plaintext. Files are encrypted with AES-256-GCM in your browser. The key is generated locally and lives in the URL fragment, the portion after the # that browsers never transmit to servers. What we store is an encrypted blob together with the minimum metadata needed to expire it. Twenty-four hours later the blob is deleted. Whether that model removes us from the business-associate relationship entirely, or merely narrows it to a conduit role, is a judgement call that depends on how you use the service and on your own counsel’s reading of HHS guidance. We don’t claim to make that decision for you.

How this maps onto the Technical Safeguards

The Security Rule’s technical safeguards at §164.312 are useful to walk through, because they describe what the regulation is actually trying to achieve rather than what boxes to tick.

Access control under §164.312(a) is about making sure only authorised people reach ePHI. With Dropshare, access is gated by possession of the decryption key in the share URL. Anyone without that fragment sees only ciphertext, including us. That places a lot of weight on how the URL is distributed — a secure messaging channel, not an unencrypted email — and that part is your responsibility.

Audit controls under §164.312(b) require that systems record and examine activity involving ePHI. Here Dropshare is genuinely limited: because we cannot see the contents, we cannot produce a content-level audit trail. We retain only basic request-level logs for the short life of the object. If your programme requires detailed per-access auditing of PHI, Dropshare alone will not satisfy it, and you should pair it with a system that does.

Integrity under §164.312(c) asks that ePHI not be improperly altered or destroyed. AES-GCM is an authenticated encryption mode, which means any tampering with the ciphertext will cause decryption to fail rather than silently produce corrupted PHI. The cryptography, not a policy document, enforces integrity end to end.

Person or entity authentication under §164.312(d) is satisfied at Dropshare’s layer by the cryptographic key; authentication of the human at the other end remains the sender’s problem, the same way it is with an email or a fax.

Transmission security under §164.312(e) calls for protection of ePHI in transit. Dropshare transmits only ciphertext, over TLS, with the decryption key travelling through a separate channel of your choosing. That is the shape the rule was written to encourage.

The administrative and physical side

Dropshare cannot discharge your administrative safeguards for you. Workforce training, sanction policies, risk analyses and contingency plans still belong to the covered entity. What we try to do is not add unnecessary complexity on top of them. Because there is no account system, there are no user-provisioning workflows to audit. Because files expire automatically, there is no retention policy to enforce at our layer.

On the physical side, the servers holding encrypted blobs sit in professionally managed data centres with the usual access controls; but this is largely beside the point, because even someone with physical access to the disks would find only ciphertext.

Where Dropshare is not the right tool

We want to be clear about the edges. Dropshare is built for short-lived sharing. It is not a medical records system, not an EHR, not an archive, and not a platform for ongoing clinical collaboration that requires traceable access history. If HIPAA obligations require you to retain records for years or to produce detailed access logs on demand, Dropshare can only reasonably play the role of secure transport alongside a system that handles retention and audit. Equally, because we cannot see content, we cannot help you identify PHI that shouldn’t have been sent, or rescind a share once the link is out — the sender has to treat the URL with the care its contents deserve.

A practical pattern for healthcare users

Teams that use Dropshare well in a healthcare setting tend to treat it the way they would treat a secure envelope. A clinician exports the document they need to share, uploads it, and hands the resulting link to the intended recipient through a channel that already carries sensitive traffic — a secure messaging system, a phone call, an authenticated portal. The link expires on its own, the encrypted object is cryptographically unreadable afterwards, and no long-lived copy is sitting on an unrelated vendor’s server waiting to be breached.

That pattern is not a substitute for a HIPAA programme. It is a small, well-behaved component inside one.

---

If you would like to discuss a specific workflow or a business-associate arrangement tailored to a narrow infrastructure role, get in touch. The Privacy Policy and Terms describe the technical behaviour in more detail.