HealthcareDICOM4DMedical

Medical imaging in the cloud: DICOM, PACS and ML

February 28, 2024 • 14 min read

The hard parts

•DICOM files – often a gigabyte or more per scan, with a lot of metadata attached
•HIPAA – patient data has to be protected at every hop
•ML in the loop – running models over scans without holding up the pipeline
•PACS – talking to whatever system a given hospital already runs

Roughly the scale at 4DMedical

•3,290+ scans a day – going through the pipeline
•50+ hospitals – across several countries
•ML on lung imaging – measurements, not just pictures
•99.9% uptime – the bar for anything clinical

Medical imaging has its own set of standards and quirks that you don't really appreciate until you're in it: DICOM, PACS, and a stack of regulatory rules sitting on top. At 4DMedical we run cloud infrastructure that processes 3,290+ scans a day, has to stay HIPAA compliant, and feeds machine learning models that pull quantitative measurements out of lung scans. This post is the practical side of that: the architecture, the compliance headaches, and where the ML actually fits.

Working with DICOM

DICOM (Digital Imaging and Communications in Medicine) is the format basically every medical scanner speaks. A single file isn't just the image — it carries a long list of tags about the patient, the procedure and the machine that took it. That metadata is half the work.

Traditional DICOM Handling
• On-premise PACS storage
• Limited processing power
• Manual quality control
• Isolated systems

Cloud-Native Processing
• Scalable storage & compute
• Automated quality checks
• ML-enhanced analysis
• Global accessibility

Moving processing to the cloud is mostly about headroom — you can run analysis and ML over scans that an on-premise PACS box was never going to have the compute for.

The cloud architecture, and where HIPAA bites

Patient data sets the bar for security here, and compliance shapes most of the design decisions. The aim is to keep the data locked down without making the processing pipeline unusable. Here's how the pieces fit:

// Medical imaging cloud architecture
Data Flow: Hospital → Secure Upload → Processing → Analysis → Results

┌─────────────────────────────────────────────────────────────────┐
│ Hospital PACS Integration                                       │
│ • Secure DICOM transmission (TLS 1.3)                         │
│ • De-identification at source                                 │
│ • Digital signatures for integrity                           │
│ • Audit logging for all transfers                            │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ Cloud Ingestion Layer (HIPAA BAA Compliant)                   │
│ • AWS S3 with server-side encryption                          │
│ • VPC with private subnets                                    │
│ • WAF and DDoS protection                                     │
│ • Multi-factor authentication                                 │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ Processing Pipeline                                             │
│ • DICOM parsing and validation                                 │
│ • Image quality assessment                                     │
│ • ML model inference (lung analysis)                          │
│ • Results generation and reporting                             │
└─────────────────────────────────────────────────────────────────┘

Where the ML comes in

4DMedical's XV Technology™ runs ML over lung scans to produce actual numbers — regional ventilation and perfusion — rather than a radiologist eyeballing the image. The pipeline looks something like this:

# ML Pipeline for Lung Analysis
import tensorflow as tf
import pydicom
import numpy as np

class LungAnalysisML:
    def __init__(self):
        self.ventilation_model = tf.keras.models.load_model('ventilation_v2.h5')
        self.perfusion_model = tf.keras.models.load_model('perfusion_v2.h5')
    
    def process_4d_scan(self, dicom_series):
        """Process 4D lung scan for ventilation and perfusion analysis"""
        
        # Extract respiratory phases from DICOM series
        respiratory_phases = self.extract_respiratory_phases(dicom_series)
        
        # Preprocess for ML models
        normalized_data = self.preprocess_for_ml(respiratory_phases)
        
        # Run ventilation analysis
        ventilation_map = self.ventilation_model.predict(normalized_data)
        
        # Run perfusion analysis  
        perfusion_map = self.perfusion_model.predict(normalized_data)
        
        # Generate quantitative measurements
        measurements = self.calculate_lung_metrics(
            ventilation_map, 
            perfusion_map
        )
        
        return {
            'ventilation_map': ventilation_map,
            'perfusion_map': perfusion_map,
            'quantitative_metrics': measurements,
            'analysis_timestamp': datetime.utcnow(),
            'model_versions': {
                'ventilation': 'v2.1.3',
                'perfusion': 'v2.0.8'
            }
        }
    
    def calculate_lung_metrics(self, ventilation, perfusion):
        """Calculate clinically relevant lung function metrics"""
        return {
            'total_lung_volume': np.sum(ventilation > 0.1),
            'ventilation_defect_percentage': self.calc_defect_percentage(ventilation),
            'perfusion_defect_percentage': self.calc_defect_percentage(perfusion),
            'regional_analysis': self.regional_lung_analysis(ventilation, perfusion),
            'severity_score': self.calculate_severity_score(ventilation, perfusion)
        }

What I'd tell anyone starting on this

•Privacy isn't retrofittable – de-identification, encryption and access control have to be there from the start.
•A model isn't done when it works – it has to hold up against clinical outcomes and the regulator before it counts.
•You're a guest in their workflow – fit into the hospital's existing PACS and radiology process, not the other way around.
•Reliability is clinical – downtime here isn't a bad day, it's a delayed diagnosis. Plan for 99.9%+ and fast response.
•The software is a medical device – FDA, CE and local SaMD rules apply, and they shape how you ship.

What it adds up to

# 4DMedical XV Technology Clinical Impact

Global Deployment Metrics:
• 50+ hospitals across US, Europe, Australia
• 3,290+ scans processed daily
• 200,000+ patients analyzed to date
• 15+ clinical studies published

Clinical Benefits:
• 10x more sensitive than traditional lung imaging
• Quantitative measurements vs qualitative assessment  
• Early detection of lung disease progression
• Reduced need for invasive diagnostic procedures
• Personalized treatment planning capabilities

Technical Achievements:
• 99.97% system uptime across all deployments
• <30 second processing time for complete analysis
• HIPAA/GDPR compliant with zero data breaches
• Integration with 25+ different PACS systems
• Real-time quality control and error detection

The thing that's stuck with me from 4DMedical is that the code is downstream of a real clinical decision. A bug isn't an annoyance for a user — it's a measurement a doctor might lean on. That changes how you think about a security control or an edge case in the pipeline. It's a heavier kind of responsibility than most software I've worked on, and honestly that's part of why I like it.

← Back to Blog