DICOM File Sharing in Healthcare: Best Practices

Modern DICOM file sharing uses the DICOMweb standard (WADO-RS, STOW-RS, QIDO-RS) over HTTPS rather than CD-based physical transfer or legacy DIMSE over DICOM upper layer protocol. The core stack: a PACS (GE Centricity, Sectra, Fujifilm Synapse, or cloud-native like Google Healthcare API) as the image archive, a vendor-neutral archive (VNA) for long-term storage across modalities, a cloud image-exchange platform (Ambra Health, LifeImage, PocketHealth) for provider-to-provider and patient-facing sharing, and a BAA-covered encrypted transfer service like HexaTransfer Enterprise for ad-hoc cases. A standard chest CT generates 300 to 800 MB; a cardiac MRI with multiple sequences can hit 2 GB.

Why CD-Based Image Transfer Is Dying

For two decades, hospitals shipped DICOM studies on CDs with an embedded viewer. The workflow was familiar but painful:

Burn rates: 3 to 5 minutes per CD at the imaging center
Read failures: 10 to 20% of CDs arrive unreadable at the receiving facility
Viewer compatibility: the embedded viewer often doesn't run on modern macOS or Linux
Physical transit: FedEx overnight for urgent transfers, often 18 to 24 hours
Lost CDs: a measurable percentage never arrive at the intended destination

The ACR and radiology societies have pushed electronic exchange for years. Cloud platforms like Ambra, LifeImage, and PocketHealth have made patient-directed image sharing the default at major academic medical centers.

DICOMweb: The Modern Standard

DICOMweb is the HTTP-based version of the DICOM network protocol. Three key services:

STOW-RS (Store over Web): send DICOM objects to a server via HTTP POST
WADO-RS (Web Access to DICOM Objects): retrieve DICOM via HTTP GET
QIDO-RS (Query based on ID): query by study/series/instance over HTTP

All three run over HTTPS with TLS 1.2 or 1.3, making them firewall-friendly in a way that legacy DICOM DIMSE (port 104 or 11112) never was. Authentication uses OAuth 2.0 or client certificates.

Most modern PACS vendors now expose DICOMweb endpoints. Cloud-native platforms (Google Cloud Healthcare API, AWS HealthImaging, Azure DICOM Service) are DICOMweb-first.

Pixel Data Sizes and Bandwidth Planning

Study sizes vary widely by modality:

Chest X-ray (CR or DX): 5 to 15 MB (uncompressed), 1 to 3 MB with JPEG 2000
CT head: 100 to 300 MB
CT chest: 300 to 800 MB
CT abdomen/pelvis with contrast: 500 MB to 1.5 GB
MRI brain (multi-sequence): 150 to 400 MB
Cardiac MRI: 500 MB to 2 GB
Mammography (digital breast tomosynthesis): 500 MB to 1.5 GB per exam
Pathology whole-slide imaging (WSI): 1 to 10 GB per slide
3D echocardiography: 200 to 500 MB

A radiology department doing 500 studies a day generates 150 GB to 1 TB of new imaging daily. Plan bandwidth accordingly; dedicated 1 Gbps links to major referral partners are increasingly common.

Compression: Lossy, Lossless, and the Diagnostic Question

DICOM supports several transfer syntaxes:

Uncompressed (Explicit VR Little Endian): baseline, largest size
JPEG Lossless: 2 to 3x compression, fully reversible
JPEG 2000 Lossless: 3 to 4x compression, current lossless recommendation
JPEG 2000 Lossy: 10 to 20x compression, discard information
HTJ2K (High-Throughput JPEG 2000): newer, similar ratios, faster decode

For primary diagnostic use, ACR guidelines recommend lossless compression. For secondary review, teleconsultation, or patient-facing viewing, lossy compression is defensible with explicit documentation.

Never apply lossy compression to screening mammography in the US — FDA MQSA requires lossless display of primary diagnostic mammograms. Similar restrictions apply to CT colonography and certain other exams.

Patient-Directed Image Sharing

The Cures Act information-blocking rules extend to imaging. Patients have the right to access their own images electronically. Platforms built for this:

PocketHealth: patient-facing image access, integrates with 700+ imaging centers
LifeImage (now part of Mach7): provider-to-patient and provider-to-provider
Ambra Health (Intelerad): cloud image exchange, patient portal
Clearpath: consumer-focused image access
Apple Health: increasingly pulls imaging via FHIR ImagingStudy resources
Mymio: Canadian-focused patient imaging

For radiology departments, offering one of these services is now effectively required. Not offering patient access is interpreted by OCR as information blocking and can trigger CMP (civil monetary penalty) enforcement.

De-Identification for Research and Teaching

Research studies, conference presentations, and teaching files need DICOM data without PHI. DICOM defines specific tags that must be removed or replaced (the Basic Application Confidentiality Profile and supplemental profiles in DICOM PS 3.15 Annex E).

Key tags to address:

PatientName (0010,0010)
PatientID (0010,0020)
PatientBirthDate (0010,0030)
StudyDate (0008,0020): can be shifted by a random offset within a patient
ReferringPhysicianName (0008,0090)
InstitutionName (0008,0080)
StationName (0008,1010)
UIDs: should be replaced with research UIDs, keeping referential integrity

Tools that handle this correctly: Posda (CTP-based), RSNA MIRC CTP (Clinical Trial Processor), pydicom with custom scripts, MIM's de-identification module, dcm4che. Always validate that pixel burned-in PHI is removed separately — text burned into image pixels isn't a DICOM tag you can just clear.

Structured Reports and Secondary Capture

Radiology reports travel alongside images. Modern workflows use:

HL7 v2 ORU (Observation Result) messages: legacy but universal
FHIR DiagnosticReport resources: modern, increasingly required
DICOM Structured Reports (SR): machine-readable report data embedded with images
DICOM Secondary Capture images: for annotated screenshots, often created in PACS or during interpretation

A complete imaging transfer package includes the DICOM study, SR if available, and the final signed report (often as a PDF attached via Encapsulated Document). Shipping the study without the report forces the receiving radiologist to re-read.

Audit Logging and Access Controls

HIPAA and the IHE Audit Trail and Node Authentication (ATNA) profile specify logging for every DICOM event:

Who accessed (authenticated user)
What was accessed (study/series/instance UIDs)
When (timestamp)
From where (source IP)
Action (view, download, modify, delete)

Most modern PACS and VNA vendors generate these logs natively. Ship them to a SIEM (Splunk, Sentinel, QRadar, Datadog) with retention of at least 6 years — the HIPAA minimum for records.

Cloud Imaging: Google, AWS, Azure

Cloud providers now offer first-party DICOM services:

Google Cloud Healthcare API: DICOM store with DICOMweb endpoints, BAA-covered
AWS HealthImaging: optimized DICOM storage with per-frame lazy loading
Azure DICOM Service: managed DICOMweb endpoint, integrates with Azure FHIR

Pricing is roughly $0.02 to $0.05 per GB stored per month plus data transfer and API call costs. For a medium radiology practice (10 TB annual volume), that's roughly $200 to $500/month plus egress.

These services sign BAAs and handle much of the compliance engineering for you. The trade-off is vendor lock-in and ongoing cost versus on-premise capital expense.

A Practical DICOM Exchange Setup

For a radiology practice:

PACS: existing enterprise vendor or Google/AWS/Azure cloud DICOM
VNA: Hyland, IBM Merge, Visage, or cloud-native
Image exchange: Ambra, LifeImage, or PocketHealth
Report delivery: bundled with PACS or FHIR integration
De-identification: RSNA MIRC CTP or MIM for research
Ad-hoc encrypted transfers: BAA-signing E2EE service
Audit log retention: 6+ years in SIEM

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