HIPAA-compliant data transfer is how you move Protected Health Information from A to B: encrypt it, pick a method that can be audited, write a Business Associate Agreement with anyone who touches the copy, and do not email the DICOM. It is not a Dropbox product review and not a security-vendor list.
If you meant is Dropbox HIPAA → is Dropbox HIPAA compliant. If you meant what is anonymization / Safe Harbor as a privacy method → what is data anonymization. If you meant security products → healthcare data security solutions. If you meant DICOM anonymize in Python → DICOM anonymization using Python.
This page already owns /blog/hipaa/ and /blog/hipaa-compliant/. PYCAD builds custom web DICOM viewers and imaging pipelines. It does not sign BAAs as a Dropbox reseller and it is not a secure-file-transfer vendor.
Three safeguards, as a transfer job
HIPAA’s Security Rule is three buckets. For a file in motion they mean this:
| Safeguard | Requirement | In a transfer |
|---|---|---|
| Technical | Render PHI unusable to anyone who is not allowed to see it | TLS or SSH in transit; AES-256 at rest; MFA on the account that starts the send |
| Administrative | Policies, risk assessment, training, a named officer | Who may send what, to whom; a written IR plan for a failed or intercepted send; a BAA with the host |
| Physical | Lock the boxes and the rooms | The SFTP host or cloud region is in a controlled facility; workstations auto-lock; no PHI on a personal laptop “just this once” |
Encryption is the technical floor: TLS / SSH while the bytes move, AES-256 while they sit — including the five minutes they sit on the landing folder. Transit-only is a common miss.
Three methods (not a fourth)
Personal Dropbox and unencrypted email are the wrong tools. They are not a method in this table.
| Method | Best for | What “compliant” actually adds |
|---|---|---|
| SFTP | Nightly batches, billing extracts, large study archives | Hardened host, RBAC, immutable logs, encryption at rest, a BAA if a vendor hosts it |
| Secure cloud (with a BAA) | On-demand share: a specialist needs this week’s CT | Signed BAA, no public links, folder-level permissions, an audit trail you actually read |
| HTTPS APIs | EHR → portal, modality → archive, app-to-app | Auth that is not a shared key in a ticket, TLS enforced, every call logged |
Pick the one that matches the workflow. Do not add a consumer sync folder as a fourth row and call it “cloud.”
People and procedure
Walk one MRI from the scanner to the remote read. Who can see the landing folder. How the radiologist is identified. Whether anyone used personal email when the portal failed. That walk is the risk assessment; a generic checklist is not.
Minimum necessary is RBAC, not a sentence in a policy. A billing clerk does not need the series. Super-user accounts that can send anything are the usual hole. Name a Privacy Officer and a Security Officer who can change the system, not just sign the annual slide. Train on phishing against the transfer portal, unapproved devices, and “please resend that study to this Gmail.”
BAA clauses that matter for a transfer vendor
If a third party hosts, stores, or forwards the PHI, you need a signed BAA. A one-page “we maintain security” PDF is not one. Insist on:
- Encryption — TLS 1.2+ in transit, AES-256 at rest, written in the contract.
- Breach notice — without unreasonable delay; put 24–48 hours on the page so you can meet your own HIPAA clock.
- Subcontractor chain — they flow the same duties down, and they tell you who is in the chain.
- Audit — your right to a SOC 2 Type II (or equivalent), not a marketing attestation.
- Destruction — how the copy dies when the contract ends.
- Country of concern — they will not send bulk U.S. health data to a restricted destination (see overlay below).
PYCAD is an imaging partner. It is not in that vendor seat and it does not sell a BAA product.
National-security overlay, short
HIPAA is not the only rule on a cross-border send. The DOJ Data Security Program (28 CFR Part 202), under IEEPA, restricts bulk U.S. sensitive personal data — including health data, and including data that is already de-identified — to countries of concern. Civil IEEPA penalties are the greater of $368,136 or twice the transaction (§ 202.1301). Put the country-of-concern clause in the BAA. Do not treat a “HIPAA-clean” extract as free to leave the country.
Compliant vs not
| Job | Not compliant | Compliant |
|---|---|---|
| Send a study to a specialist | DICOM attached to ordinary email | SFTP or a BAA-backed imaging share, encrypted end to end |
| Billing file to an insurer | Personal cloud folder + a public link | Automated SFTP to the insurer, logs on |
| Research extract | Strip the name, send the rest on Slack | Safe Harbor or expert determination, then an encrypted channel |
Other frequent misses: no automation on a daily send (wrong inbox is a matter of time), logs nobody reads, “de-identified” that still has dates and a ZIP, no in-transit incident plan.
FAQ
Can we email PHI?
Ordinary email, no. A secure-email product that encrypts the payload and makes the recipient authenticate can be. If you do not have that, use SFTP or the BAA cloud. A DICOM on a Gmail thread is a postcard.
Is SFTP inherently HIPAA compliant?
No. SFTP encrypts the tunnel. You still need access control, logs, encryption at rest on the host, and a BAA if someone else runs the server. A naked sftp daemon on a lab VM is a tool, not a programme.
Does de-identified / anonymized / Safe Harbor mean we can send it anywhere?
Only if it is properly de-identified. HIPAA gives two paths: expert determination, or Safe Harbor (remove the 18 identifiers — names, more-specific dates, detailed geography, and the rest). Deleting the patient name is not Safe Harbor. And even a clean extract can still be bulk U.S. health data under the DOJ rule above. The method itself — what Safe Harbor is, what k-anonymity is — lives on what is data anonymization. This page is the transfer.
PYCAD implements imaging pipelines on top of DICOM / FHIR / PACS. It is not a file-transfer vendor. Case studies.