Transfer Medical Records Securely: HIPAA-Friendly Guide

Transferring medical records securely means the file is encrypted with keys the transfer provider cannot access, the transmission uses TLS 1.3, the provider either signs a Business Associate Agreement (BAA) or the encryption is end-to-end so no BAA is required for the plaintext, and the workflow produces an auditable record of transmission and receipt. In HIPAA terms, you're honouring 45 CFR § 164.312 (Technical Safeguards) — access control, audit controls, integrity, and transmission security. The practical shortcut: upload the DICOM study or PDF records to a browser-based service that encrypts client-side with AES-256-GCM before any byte leaves the clinical workstation.

What HIPAA actually requires for transmission

The HIPAA Security Rule's Technical Safeguards section (§ 164.312) specifies:

• Access Control (§ 164.312(a)(1)): unique user identification, emergency access procedure, automatic logoff, encryption and decryption.
• Audit Controls (§ 164.312(b)): hardware, software, and procedural mechanisms that record and examine activity.
• Integrity (§ 164.312(c)(1)): PHI is not altered or destroyed in an unauthorized manner.
• Transmission Security (§ 164.312(e)(1)): integrity controls plus encryption, where "reasonable and appropriate."

"Addressable" in HIPAA language doesn't mean optional — it means the covered entity must implement the safeguard or document why it's not reasonable and implement an equivalent alternative. For transmission of ePHI outside a trusted network, encryption is the near-universal default.

The BAA question, reframed

A Business Associate Agreement is required when a vendor has access to PHI on behalf of a covered entity. If the transfer service can see plaintext PHI — even transiently — a BAA is needed. If the PHI is encrypted end-to-end and the service only handles ciphertext, the service arguably isn't a Business Associate as to that data because it never has access to PHI as defined in § 160.103.

This is the zero-knowledge argument. The OCR (HHS Office for Civil Rights) hasn't issued a bright-line ruling, but the HITECH Act's "safe harbor" at § 13402(h) — encrypted data per NIST guidance is not considered unsecured PHI — supports the position that properly-encrypted transmissions don't trigger breach notification. Practical advice: smaller practices pair a BAA-signed service or a zero-knowledge service with documented risk analysis under § 164.308(a)(1)(ii)(A).

Common clinical file types

| File | Typical size | Contents | | --- | --- | --- | | DICOM CT study | 200 MB – 2 GB | Slices, metadata (patient name, MRN, study date) | | DICOM MRI study | 100 MB – 3 GB | Multiple series | | Digital pathology .svs | 500 MB – 5 GB | Whole-slide images | | Consolidated CDA (C-CDA) XML | 100 KB – 5 MB | Structured clinical summary | | PDF lab results | 50 KB – 20 MB | Bloodwork, imaging reports | | DEXA/DXA study | 10–50 MB | Bone density images | | Full EMR export | 10 MB – 2 GB | De-identified or patient-requested export |

A single abdominal CT with contrast can hit 1.2 GB. Email is not a channel for these.

Why email and standard cloud storage fall short

• Standard SMTP is hop-by-hop TLS — mail servers along the way decrypt and re-encrypt. A message traversing three relays has three decryption points.
• Gmail, Outlook.com, and iCloud Mail store messages on the provider's servers with provider-held keys.
• Dropbox, Google Drive, and OneDrive all offer encryption at rest, but the provider holds the keys. Google signs a BAA only for Workspace Enterprise with HIPAA-enabled admin configuration. Free-tier Drive is not HIPAA-covered.
• Fax, the perennial backup, is still in use in US healthcare — but unencrypted landline fax passes through telecom carriers in plaintext.

A zero-knowledge transfer flow for clinical use

1. Clinician exports the DICOM study from the PACS (GE Centricity, Philips IntelliSpace, Siemens syngo.via, or the open-source dcm4chee) to a .zip containing anonymised or patient-identified DICOM files.
2. Clinician opens the transfer service in the browser. Web Crypto API derives a 256-bit key from a shared passphrase via PBKDF2-HMAC-SHA256, 600,000 iterations, random 128-bit salt.
3. The browser encrypts each 5 MB chunk with AES-256-GCM, fresh 96-bit IV per chunk. Ciphertext uploads over TLS 1.3.
4. The link is sent to the receiving clinician via secure messaging (DirectTrust, TigerConnect) or patient portal.
5. The passphrase is transmitted via a second channel — a signed paper form handed to the patient, an SMS to a verified number, or a phone call.
6. The receiver downloads, decrypts in the browser, opens in OsiriX, Horos, RadiAnt, or their local PACS.

The transfer service never sees patient data. The audit trail records upload timestamp, file size (not content), download timestamp(s), and IP addresses. Those logs support § 164.312(b) audit controls without revealing PHI.

Metadata leakage risks

DICOM files embed a rich header: patient name, MRN, date of birth, referring physician, institution. Two leakage paths:

• Filename includes PATIENT_LASTNAME_MRN123456.dcm. A transfer service with visible filenames exposes identifiers even with encrypted content. Rename before zipping.
• DICOM tags inside the file hold all the demographics. An encrypted file hides this from the transfer service, but the receiver sees it on decryption. If the use case doesn't require identifiers, de-identify per DICOM Supplement 142 or HIPAA's § 164.514(b) Safe Harbor before sending.

Patient-initiated transfers

Under the HITECH Act and the 21st Century Cures Act's information blocking rules (45 CFR Part 171, effective 2021), patients have the right to receive their records in an electronic format. A browser-based encrypted transfer is well-suited:

• Patient requests records from the provider's release-of-information office.
• ROI staff uploads a zipped PDF/C-CDA/DICOM bundle.
• Patient receives the link at their verified email, password via phone.
• Patient downloads, keeps a copy, forwards to a second-opinion provider.

This flow satisfies information-sharing obligations without requiring the patient to set up a portal account.

GDPR parallel for European healthcare

Article 9 of the GDPR classifies health data as a special category. Article 32 mandates appropriate technical and organisational measures, including encryption. For EU clinics (German Krankenhäuser, French hôpitaux, Swiss Spitäler, Dutch ziekenhuizen), end-to-end encryption with client-side key derivation satisfies the article's requirements, and zero-knowledge processing reduces the scope of data-processor contracts under Article 28.

Swiss clinics additionally fall under the revised FADP (nFADP, in force since September 2023), which broadly aligns with GDPR on encryption expectations.

Retention and deletion

Clinical records have statutory retention: 10 years in France (Code de la santé publique L.1110-4), 30 years in Germany for hospital records under state law, 7+ years in most US states under state law layered on HIPAA. The transfer itself, though, is ephemeral. The retention clock applies to the provider's system of record (the EMR), not to the transfer link. Configure transfer expiry for 14–30 days; the receiver's PACS or EMR takes over long-term custody.

Comparison of healthcare-appropriate transfer options

| Option | E2E encryption | HIPAA-capable | Max size (typical) | Patient-accessible | | --- | --- | --- | --- | --- | | Standard Gmail | No (TLS only) | No without Workspace BAA | 25 MB | Yes | | Google Workspace HIPAA (with BAA) | No | Yes | 5 TB quota | Yes | | Microsoft 365 HIPAA (with BAA) | No | Yes | 250 GB per file (OneDrive) | Yes | | DirectTrust (Direct Project) | Yes (S/MIME) | Yes, designed for HIPAA | Configured per HISP | Limited | | Tresorit Send | Yes (server-assisted) | BAA available | 5 GB free | Yes | | HexaTransfer | Yes (AES-256-GCM in-browser) | Zero-knowledge by design | 10 GB | Yes, no account needed |

Medical records carry weight the moment they leave the building. The transmission mechanism has to match that weight.

Try it at hexatransfer.com — free, no account, 10 GB max.