Medical Imaging Transfer: Complete Technical Guide

Medical imaging transfer moves DICOM, NIFTI, and proprietary radiology formats between PACS systems, referring physicians, specialists, and patients — typically via DICOMweb (WADO-RS, STOW-RS, QIDO-RS), IHE XDS-I, direct SFTP, or web-based encrypted uploads. A single cardiac CT study runs 500 MB to 2 GB, a whole-slide pathology image hits 4 GB, and a research fMRI dataset can reach 40 GB per subject. The right transfer approach depends on file size, destination type, and whether the other end speaks DICOM natively or wants something a Mac can open.

DICOM, NIFTI, and What You're Actually Moving

Before picking a transfer method, know the format. DICOM (Digital Imaging and Communications in Medicine) wraps pixel data with metadata tags — patient name in (0010,0010), study UID in (0020,000D), modality in (0008,0060). A typical MRI study is a folder of hundreds of .dcm files, each one slice. NIFTI (.nii or .nii.gz) is the research neuroimaging format that packs a whole volume into a single file. Proprietary vendor formats like GE's Advantage Workstation exports or Siemens syngo.via files sometimes ship as .tar archives that a DICOM viewer has to unpack.

Size ranges:

• Chest X-ray: 10-30 MB
• Head CT: 50-200 MB
• Abdominal MRI: 300 MB-1 GB
• Cardiac MRI with cine: 500 MB-2 GB
• Whole-slide pathology (.svs, .ndpi): 1-4 GB per slide
• fMRI task run: 500 MB-2 GB; full study: 10-40 GB

Match the transfer tool to the largest file you'll ship, not the average.

DICOMweb: The Modern Wire Protocol

DICOMweb, defined in DICOM PS3.18, replaces the old DIMSE protocol with HTTP. Three core services:

• STOW-RS (Store Over the Web, RESTful) — POST a multipart/related body with DICOM instances to /studies.
• WADO-RS (Web Access to DICOM Objects, RESTful) — GET /studies/{StudyInstanceUID} to retrieve.
• QIDO-RS (Query based on ID) — search studies and series with query parameters.

DICOMweb runs over TLS 1.3 and plays nicely with OAuth 2.0 bearer tokens, which is why modern PACS like Orthanc, dcm4chee, and Ambra Health support it. If you're integrating two hospital systems and both speak DICOMweb, you don't need a separate transfer tool — you need a configured gateway.

When DICOMweb Isn't an Option

Most real transfers happen between systems that don't share a gateway. A community hospital sends a trauma scan to a tertiary center. A patient takes their outside MRI to a specialist. A research site ships fMRI data to a data coordinating center. In these cases:

1. SFTP (RFC 4253 with OpenSSH) — reliable for scheduled transfers between known endpoints, but weak on audit UX.
2. IHE XDS-I.b — the interoperability profile for cross-enterprise imaging, used by HIEs like Carequality. Heavyweight to deploy.
3. Web-based encrypted upload — the pragmatic choice for one-off or ad-hoc transfers, especially when a patient is in the loop.
4. Physical media — a burned CD with IHE PDI profile still happens, though it's fading fast as hospitals remove optical drives.

De-Identification Before Transfer

DICOM headers are dense with PHI. The DICOM Standard PS3.15 Annex E defines the Basic Profile for de-identification, which lists 400+ tags to remove, replace, or empty. Tools like DicomAnonymizer, CTP (Clinical Trial Processor), and dcm4che's dcmdeid implement it. Common mistakes:

• Leaving burned-in annotations in the pixel data — these need OCR-and-redaction, not just header changes.
• Forgetting private tags in (0009,xxxx) ranges where vendors stash scanner serial numbers.
• Keeping the Study Instance UID, which allows re-linking if the attacker has the original.

For research data under GDPR, de-identification plus TLS plus AES-256-GCM at rest is the baseline. Clinical data moving between treating physicians under HIPAA's Treatment exception doesn't require de-identification but still needs encryption.

Compression, Transfer Syntax, and Bandwidth

DICOM files can be stored uncompressed (Implicit VR Little Endian, Transfer Syntax UID 1.2.840.10008.1.2) or with JPEG 2000 Lossless (1.2.840.10008.1.2.4.90), JPEG-LS, or RLE. Lossless compression on CT data typically saves 50-60%. Lossy compression is a medicolegal minefield — many radiology practices prohibit it entirely for diagnostic use.

For whole-slide pathology, JPEG 2000 or the newer DICOM Supplement 145 tiling dramatically cuts transfer size. For fMRI, gzip on NIFTI (.nii.gz) is standard and shrinks files 3-5x.

If you're on a 100 Mbps symmetric link, a 2 GB cardiac MRI takes about 3 minutes at wire speed. On a site with a 10 Mbps upload, it's 30 minutes. Plan accordingly — or use a transfer service that resumes on disconnect.

Patient-Controlled Transfers

A growing workflow: the patient sits in the specialist's office, hands over a USB stick or a login for their patient portal, and the specialist imports the images. 21st Century Cures Act information blocking rules make this the patient's right, and OpenNotes/meaningful-use provisions require covered entities to support it.

For this pathway, you need a transfer method a non-technical patient can use. A web form where they drop files, encrypt client-side with a passphrase, and text the passphrase to the clinic works. No account, no IT ticket. HexaTransfer fits this pattern — client-side AES-256-GCM, shareable link, passphrase out-of-band. Try it at hexatransfer.com — free, no account, 10 GB max.

Chain of Custody for Teleradiology

Teleradiology shops like vRad, Nighthawk, and Radisphere rely on transfer pipelines that auditors trace hourly. The essentials:

• SHA-256 hash logged at the sending PACS and verified at the reading station.
• Timestamped event log including accession number and reading radiologist ID.
• Retention of transfer logs for the period specified by state medical record laws — often 7-10 years past the patient's last visit, longer for pediatric records.
• Automatic purge of the transfer staging area after confirmation of receipt, so the staging server doesn't become a shadow archive.

Handling the 10 GB Ceiling on Web Transfers

Most web-based transfer services cap individual transfers at 2-10 GB. WeTransfer Pro tops out at 200 GB per transfer but requires a paid account. SwissTransfer allows 50 GB free. HexaTransfer sits at 10 GB free with no account.

For transfers above the ceiling, the options are:

• Split into logical bundles — one visit, one modality, one series per transfer.
• Physical shipping — AWS Snowball Edge holds 80 TB; a FedEx overnight with an encrypted LUKS or VeraCrypt drive works for ad-hoc.
• Dedicated link — Direct Connect, ExpressRoute, or hospital VPN for recurring high-volume flows.

Know your ceiling before you promise a timeline.

Integrating With PACS Without Disrupting Reads

The one rule: don't break the radiologist's worklist. If your transfer workflow touches the PACS, route through a staging node (Orthanc or dcm4chee as a DICOM router works well) so the production PACS only receives validated studies. Tag incoming transfers with a distinctive AE title so they show up in a separate worklist until a technologist QCs them.

For outbound transfers, a one-click "Send to External" action in the PACS that routes to your transfer tool cuts the radiologist out of the encryption workflow — which is what they want. They drop the study, the tool encrypts, and the clinician at the other end gets a link.

Verification and Handoff

After every transfer, verify:

1. File count matches (count of .dcm files or NIFTI volumes).
2. SHA-256 of the archive matches sender and receiver.
3. At least one image opens in the receiving viewer.
4. Metadata didn't get corrupted — patient name, study date, and accession number are readable.

Log the verification in your transfer record. "We sent it" is not a defense; "we sent it and confirmed byte-level integrity" is. Medical imaging transfer isn't just moving bytes — it's moving a diagnostic record that someone's care depends on, sometimes within minutes.