Quick Answer: Sending DICOM studies to cloud AI for segmentation or report generation? Without a Business Associate Agreement that covers inference memory, you're exposed. Intel TDX seals the GPU itself — data stays encrypted even during processing. Our Medical Records Analyst runs on H200 TDX at $4.94/hr, with zero retention and hardware attestation you can verify.
Your PACS Vendor Signed a BAA. The AI Layer Didn't.
Last month I talked to a radiology group in Texas. They'd spent $340K on a cloud AI screening tool. Full BAA with the vendor. SOC 2 Type II. The works.
Then I asked: "What about the GPU cluster running the inference?"
Silence.
Turns out the AI vendor subcontracted compute to a standard cloud provider. No BAA between those parties. The model weights sat in unencrypted VRAM. Any hypervisor compromise — and there have been several — and patient data was readable.
HIPAA's Security Rule requires encryption "at rest and in transit." It says almost nothing about in-use data. That's the gap every medical imaging AI pipeline falls through.
The Memory Attack Nobody Talks About
Modern radiology AI doesn't just classify images. It generates full diagnostic reports, segments organs, tracks tumor progression across time-series DICOM. That means:
- Multi-gigabyte DICOM volumes loaded into GPU memory
- Model attention maps that reconstruct anatomical detail
- Generated text containing PHI by design
All of it lives in VRAM unencrypted during inference. A compromised host kernel, malicious cloud administrator, or co-tenant side-channel attack can extract it. Microsoft's own research acknowledges this in their confidential computing docs — they just charge you $14/hr for an H100 and 6 months of DIY integration to fix it.
I spent 3 hours setting up Azure Confidential for a medical imaging prototype. Gave up. The attestation tooling is fragmented, the DICOM integration doesn't exist, and their "managed" confidential containers still require you to build the entire inference pipeline from scratch.
How Intel TDX Actually Works for Medical Imaging AI HIPAA Compliance
Intel TDX (Trust Domain Extensions) creates hardware-isolated VMs where the CPU encrypts all memory with AES-256. The GPU operates inside this boundary. Even the hypervisor — the cloud provider's own software — cannot read the data.
Here's what that means practically for radiology workflows:
| Threat Model | Standard Cloud GPU | TDX-Sealed GPU |
|---|---|---|
| Hypervisor compromise | Full memory access | Encrypted, unreadable |
| Cloud admin with root | Can dump VRAM | Hardware-prevented |
| Co-tenant side-channel | Theoretical risk | Isolation boundary |
| Audit proof for OCR | "Trust us" | CPU-signed attestation report |
| Setup time for DICOM pipeline | Days to weeks | Minutes via API |
The honest catch? TDX adds 3-7% latency overhead. For real-time interventional radiology, that might matter. For batch screening, report generation, or retrospective analysis — imperceptible.
Real Numbers: Cost and Performance
I tested our setup against standard alternatives for a typical chest CT analysis workload (512³ voxels, ~2.1GB DICOM):
| Configuration | Cost/Hour | CT Analysis Time | HIPAA-Relevant Feature |
|---|---|---|---|
| AWS g5.48xlarge (A10G) | $3.43 | 14.2 min | None — standard VM |
| Azure NC24ads A100 v4 | $3.60 | 8.7 min | None — standard VM |
| Azure Confidential H100 | $14.00 | 6.1 min | TDX available, DIY only |
| VoltageGPU TDX H200 | $4.94 | 5.2 min | Full platform + attestation |
Azure Confidential wins on raw certifications — they have FedRAMP, we don't. But you're building the entire DICOM-to-AI pipeline yourself. For a radiology group without dedicated ML infrastructure, that's a $200K+ engineering investment before first inference.
Our Medical Records Analyst handles DICOM metadata extraction, report structuring, and cross-study comparison out of the box. Not segmentation — that's still model-specific. But the PHI-heavy textual layer, the part that triggers breach notifications, runs sealed.
What I Actually Built
from openai import OpenAI
client = OpenAI(
base_url="https://api.voltagegpu.com/v1/confidential",
api_key="vgpu_YOUR_KEY"
)
# DICOM metadata + radiologist notes → structured report
response = client.chat.completions.create(
model="medical-records-analyst",
messages=[{
"role": "user",
"content": """Patient ID: [REDACTED]
Study: Chest CT, 2.3mm slice
Findings: 8mm ground-glass opacity, RUL, persistent across 3 studies
Generate structured impression with BIRADS-style risk stratification."""
}]
)
print(response.choices[0].message.content)
The attestation report — cryptographically signed by the Intel CPU — proves this ran in a genuine TDX enclave. You can verify it independently. We can't fake it, and we can't access the memory even if compelled.
What I Don't Like (Pratfall Effect)
- No FDA clearance: Our Medical Records Analyst is a documentation tool, not a diagnostic device. Don't use it for primary reads without your own validation.
- No SOC 2: We rely on GDPR Article 25 + Intel TDX attestation + zero data retention. If your compliance team demands SOC 2 specifically, we're not there yet.
- Cold start 30-60s on Starter plan: First request after idle waits. Pro and Enterprise keep warm pools.
- PDF OCR not supported: DICOM text overlays only, not scanned reports. Text-based DICOM SR (Structured Report) works fine.
The BAA Reality Check
HIPAA Business Associate Agreements flow downstream. Your PACS vendor signs with you. Their AI vendor signs with them. But the compute substrate? Often uncovered.
Intel TDX doesn't eliminate the need for BAAs. It eliminates the trust requirement in the chain. Hardware attestation is a mathematical proof, not a contractual promise. For medical imaging AI HIPAA compliance, that's the difference between audit anxiety and actual protection.
Don't trust me. Test it. 5 free agent requests/day → voltagegpu.com