Medical records are one of the richest targets a data thief can hit. A single PDF from your provider can contain your legal name, date of birth, home address, Social Security number, insurance member ID, and a diagnosis history. Unlike a leaked password, none of that can be rotated. You can't reset your date of birth after a breach.

The uncomfortable part: HIPAA governs how your providers handle your data. The moment a record lands in your personal inbox or on your phone, those protections stop applying. If you forward your own MRI to a specialist over Gmail, you are the data controller now, and email is a bad place to be one.

Why email quietly fails at this

Standard email was never designed to be confidential. When you attach a PDF of your lab results and hit send, that file doesn't travel down a private tunnel — it gets copied and stored at every hop:

Your Sent folder, indefinitely.
Your provider's outbound mail server logs.
The recipient's inbound mail server.
The recipient's Inbox, plus any backups their IT team keeps.

That's at least four durable copies, and you control exactly one of them. Even with TLS encrypting the connection in transit, the attachment sits decrypted at rest on servers you'll never audit. If any one of those accounts is later phished or breached, your record is in the dump. Deleting your own copy does nothing to the other three.

Faxing — still weirdly common in healthcare — isn't better. Fax numbers get transposed, pages sit in output trays, and cloud-fax services store a plaintext image of every page you send.

The encrypted drop model

The fix is to stop sending the file and instead send a one-time link to an encrypted file. This is where a zero-knowledge tool changes the threat model entirely.

Here's the practical flow with SnapSend's encrypted file share:

The file is encrypted in your browser, before a single byte leaves your device, using AES-256-GCM.
The decryption key is placed in the URL's #fragment — the part after the # that browsers never transmit to the server. So the server stores only ciphertext and literally cannot read your record, even under subpoena. That design is worth understanding once; we break it down in zero-knowledge encryption explained.
You send the link (and only the link) to the specialist.
After they download it once, or after your chosen expiry passes, the file self-destructs. No lingering copies to leak later.

Compared to email, you've collapsed four durable copies down to one short-lived, encrypted blob that erases itself. That's the ephemeral-sharing principle applied to your health data.

A concrete walkthrough: sending a scan to a specialist

Say your primary care doctor exported your chest CT and you need it in front of a pulmonologist before Thursday's appointment.

Export the file from your patient portal. You'll usually get a PDF report, and sometimes the raw imaging as a .zip of DICOM files.
Drop it into the encrypted share and set an expiry — 24 to 48 hours is plenty for a scheduled appointment. Enable one-time (burn-on-read) if only one person needs it.
Send the link over a channel the recipient already trusts — the practice's secure portal message, or a phone call where you read it out. Avoid pasting it into the same email thread that contains their reply-all chain.
Confirm the download happened, then consider the transfer closed. Once it's burned, even you can't re-open it, so keep your original.

That last point matters: with burn-on-read, the link is designed to die. Keep the source file on your own device; the share is the delivery mechanism, not your backup.

Common mistakes people make

Putting the key in the same message as the context. If your email says "here's my full medical history, password is hunter2," a single compromised inbox hands over both. With a fragment-based key, there's no separate password to leak — but the same discipline applies: don't narrate what the file is in the same breach-able channel where the link lives.
Screenshotting records into a chat app. Messaging apps back up to the cloud, sync across devices, and are rarely truly ephemeral. A screenshot of your insurance card in a group thread is a copy you no longer control.
Reusing a link for a whole family. One link per recipient per purpose. If both a specialist and a school nurse need something, generate two links so one download can't be replayed by the other.
Forgetting large-file reality. A full DICOM imaging study can be hundreds of megabytes. SnapSend targets everyday medical files — compressed reports and single scans — comfortably. For a giant multi-series study, compress it or ask whether the specialist can pull it directly from an imaging exchange instead.

When someone needs to send records to you

The reverse case is just as common: a clinic needs to send you a discharge summary, or you're gathering records from three providers before switching insurers. Emailing "please send my file" invites them to reply with an unencrypted attachment.

Instead, hand them a secure receive link. They upload the file into an encrypted drop that only you can open — no account, no app install on their end. It's the same protection, pointed inward, and it keeps their reply out of your permanent inbox.

A quick pre-send checklist

Before you share anything with health data in it:

[ ] Is the file encrypted before upload, not just sent over HTTPS?
[ ] Does the link expire on a timeline that matches the need?
[ ] Is it one-time if only one person should ever open it?
[ ] Am I sending the link through a different, trusted channel than any bulk email thread?
[ ] Do I still have my own copy after the share self-destructs?
[ ] Did I redact anything the recipient doesn't actually need (e.g., SSN on a form that only requires a diagnosis)?

If you want to sanity-check how much a given service can see about you before you trust it with a scan, our privacy check and the how SnapSend is built page walk through what a zero-knowledge design does and doesn't protect.

The bottom line

Your health is private by law when it's in a hospital's system. Once it's in your hands, that privacy is your responsibility — and email hands it away by default. Encrypt before you upload, let the link expire, and stop leaving copies behind.

When you need to move a scan or a lab result to another human, send it as a self-destructing encrypted link instead of an attachment. It takes about the same effort as dragging a file into an email, and it doesn't leave your record sitting on four servers you'll never see.