Connecting Data Sources to AI in Healthcare

The promise of AI in specialized domains like healthcare, scientific research, and industrial imaging isn't just about better algorithms—it's about connecting those algorithms to the right data at the right time. But there's a problem: the data lives in specialized systems that speak protocols AI platforms don't understand.

DICOM servers store medical images. FHIR endpoints expose patient records. Legacy databases use proprietary formats. Meanwhile, AI models expect clean JSON over REST APIs, ideally with specific schemas tailored to their training data.

This is where Runbeam excels—as a translation layer that connects specialized data sources to AI systems without forcing you to rebuild either side.

The Data-to-AI Integration Challenge

Consider a common scenario in medical imaging AI. An AI diagnostic model needs to analyze chest X-rays for pneumonia detection, but the images live in a PACS system that speaks DICOM—a 30-year-old medical imaging protocol. The AI platform expects images delivered via REST API with metadata in JSON, and the workflow requires patient demographics from a FHIR server to contextualize results.

Building this integration traditionally means writing custom adapters for DICOM protocol handling, implementing FHIR client libraries, and managing protocol translation logic in application code. You need to maintain session state across multiple data sources while handling authentication, rate limiting, and error recovery for each system. Then there's the network challenge: securely connecting on-premise hospital systems to cloud-based AI platforms requires managing firewall rules, VPNs, and network security while ensuring HIPAA compliance for data in transit.

This infrastructure work can take months—and that's before you've written a single line of AI-specific logic.

How Runbeam Solves This

Runbeam's Harmony gateway provides protocol translation as infrastructure. Instead of building custom adapters, you define pipelines that accept requests in AI-friendly formats like REST and JSON, translate them to specialized protocols like DICOM, FHIR, or SOAP, transform data between schemas using declarative JOLT specifications, and return normalized responses ready for AI consumption. The gateway also securely connects to cloud AI via authenticated, rate-limited HTTP/3 connections.

That last capability is critical. Most AI platforms are cloud-based, but healthcare data lives on-premise behind hospital firewalls. Runbeam bridges this gap with modern HTTP/3 (QUIC) connections that are outbound-only—meaning hospital systems initiate the connections, so no inbound firewall rules are needed. Every request carries JWT or OAuth2 tokens for authentication, and rate limiting protects both sides from overload. TLS 1.3 encryption is built into the QUIC protocol itself, and the connection supports multiplexing, 0-RTT resumption, and connection migration for optimal performance even on challenging networks.

Let's look at real examples from the Harmony workload library.

Example 1: DICOM to Cloud AI Gateway

The DICOM-AI pipeline demonstrates a complete bridge between traditional PACS systems and modern cloud-based AI processing services.

The Scenario

Radiology departments have CT scanners, MRI machines, and ultrasound devices that send DICOM images to a PACS. The challenge is receiving those images automatically via the DICOM C-STORE protocol, extracting relevant metadata for AI processing, transforming DICOM data into JSON format optimized for cloud AI services, sending structured requests to cloud-based AI platforms with proper authentication, and doing all this while maintaining compatibility with existing DICOM workflows that can't be disrupted.

The Pipeline

This workload implements a complete on-premise to cloud flow:

The pipeline starts with a DICOM listener that accepts incoming C-STORE operations from medical modalities and PACS systems. When DICOM images arrive, the gateway extracts metadata from DICOM's binary format into JSON—converting tags like Patient ID, Study Date, and Modality into standard JSON key-value pairs that cloud services can process.

A transformation step then reshapes this JSON into the specific schema your AI platform expects. This uses JOLT, a declarative transformation language that maps fields without requiring custom code. For example, it might restructure flat DICOM fields into nested objects that match your AI model's training data format.

Finally, the gateway forwards the transformed data to your cloud AI service over HTTPS with bearer token authentication, ensuring secure and authorized communication between on-premise systems and cloud platforms.

JSON Output for AI

The transformation produces clean, predictable JSON optimized for AI consumption. DICOM stores data in a complex binary format with cryptic identifiers, but the gateway reorganizes this into logical groupings: patient information (ID and name), study metadata (unique identifier, date, clinical description), imaging details (modality type, body part examined), and processing context (request type, priority, timestamp).

This structure is far simpler than DICOM's native format and matches what AI models trained on JSON data expect. The cloud AI platform receives a consistent schema regardless of which PACS or modality generated the original DICOM—the gateway handles all the protocol-specific variations.

What This Enables

A cloud AI diagnostic platform can now receive structured data without implementing DICOM protocol handling, process metadata in familiar JSON format with predictable schema, focus on AI inference instead of healthcare protocol integration, and scale horizontally as a standard cloud service.

Meanwhile, the hospital keeps data on-premise (only metadata and references flow to the cloud), uses existing DICOM infrastructure without modification, maintains HIPAA compliance with authenticated and encrypted connections, and avoids VPN complexity through outbound HTTP/3 connections that don't require opening inbound firewall ports.

The gateway handles DICOM protocol translation including C-STORE operations, metadata extraction from DICOM tags, JSON transformation via declarative JOLT specifications, secure cloud connectivity with token-based authentication, and rate limiting to protect both the hospital and cloud platform from overload. This infrastructure work would typically take weeks to build from scratch.

Example 2: FHIR to DICOM with AI Enrichment

The FHIR-DICOM integration shows how to bridge clinical data with imaging systems for AI workflows that need both.

The Scenario

An AI system needs to query imaging studies based on patient demographics from a FHIR server, retrieve the actual DICOM images from a PACS, and combine clinical context with imaging data for analysis. Traditional implementations require maintaining both FHIR and DICOM clients, managing session state across these different systems, and handling protocol-specific error cases that differ significantly between the two standards.

The Pipeline

This pipeline implements context-aware transformations that understand both FHIR and DICOM semantics. When an AI platform queries for imaging studies using FHIR search parameters like patient=PID123 and modality=CT, the gateway translates these into DICOM query format. DICOM uses numeric tag identifiers rather than readable field names, so the gateway maps FHIR's patient ID parameter to DICOM's Patient ID tag, and modality to DICOM's Modality tag.

When the PACS returns DICOM study results, the gateway transforms them back into FHIR ImagingStudy resources. The response is a FHIR Bundle—a container for search results—containing ImagingStudy resources with proper FHIR structure: study identifiers, patient references, and endpoint URLs where the AI platform can download the actual imaging data.

Data Flow Architecture

The response flow transforms DICOM study results back to FHIR ImagingStudy resources with JMIX download endpoints.

AI platforms can now:

• Use familiar FHIR APIs to search for imaging studies
• Receive standardized FHIR ImagingStudy resources
• Download images via JMIX URLs without implementing DICOM
• Combine patient demographics with imaging context in one request

The gateway eliminates the need for AI systems to maintain DICOM protocol knowledge.

Example 3: Data Transformation for AI Input

Raw data from specialized systems rarely matches AI model input requirements. The transform middleware enables declarative data reshaping.

The Scenario

You have patient data in a proprietary format that needs to be normalized into FHIR Patient resources before feeding to an AI model trained on FHIR-structured data.

The Pipeline

The transformation happens through JOLT—a declarative specification language that reshapes data without writing code. Think of it as a mapping document that tells the gateway where each piece of data should move. When your proprietary system sends flat JSON with simple field names like PatientID and PatientName, JOLT automatically restructures it into the deeply nested FHIR Patient resource format that AI models trained on FHIR data expect.

This declarative approach means no code to maintain. When your AI model's input schema changes, you update the transformation specification rather than rewriting logic in application code. Transformations can apply to requests flowing to backends, responses returning to clients, or both directions through the same pipeline.

Key Capabilities for AI Integration

1. Protocol Translation Harmony supports specialized protocols like DICOM (medical imaging with C-STORE, C-FIND, C-GET, C-MOVE operations), FHIR (healthcare data REST APIs for R4 and R5), DICOMweb (web-based medical imaging with QIDO-RS, WADO-RS, STOW-RS), SOAP and XML (legacy web services), and custom protocols through an extensible backend system. AI systems don't need to understand any of these—they just receive clean JSON.

2. Data Transformation JOLT specifications provide JSON-to-JSON transformation rules without requiring code. Context injection lets transforms access request metadata like query parameters and headers, enabling conditional logic based on the full request context. Transforms can be applied bidirectionally to requests and responses independently, and schema validation ensures data meets AI model requirements before consumption.

3. Workflow Orchestration Middleware pipelines let you compose transformations, authentication, and routing logic into reusable chains. Session state maintains context across multi-step workflows that span multiple backend systems. Error handling supports configurable retry logic, fallback behaviors, and failure strategies that match production requirements. Request tracing and structured logging provide observability into how data flows through complex pipelines.

4. Security & Compliance Authentication supports JWT, OAuth2, Basic Auth, and API keys for flexible integration with existing identity systems. Role-based access control and IP filtering provide authorization boundaries. Sensitive field patterns enable automatic log redaction to prevent accidental PHI exposure, and webhook middleware creates audit trails for compliance requirements.

5. Secure Cloud Connectivity Most AI platforms are cloud-based, but healthcare data lives on-premise behind hospital firewalls. Runbeam solves this with authenticated, limited HTTP/3 connections that bridge on-premise systems to cloud AI.

Getting Started

1. Choose a Workload Template

Browse the workload library for templates matching your data sources. For DICOM to cloud AI integration, use the DICOM-AI workload that provides a complete PACS to cloud AI gateway. For bridging FHIR queries with DICOM imaging, the FHIR-DICOM workload handles protocol translation between these standards. Additional templates cover medical imaging, healthcare data, data transformation, HTTP APIs, and cloud connectivity for secure on-premise to cloud connections.

2. Deploy to Runbeam

Deploy workloads directly in the Runbeam platform by navigating to Templates in the Runbeam console, selecting a workload like DICOM-AI for cloud AI integration, and clicking Deploy to create pipelines automatically. Configure the endpoints and backends for your specific environment, then update the AI service URL and authentication credentials to match your cloud platform.

3. Customize Transforms

Modify JOLT transforms to match your AI platform's expected schema. Transforms can be applied bidirectionally to requests and responses, and context injection gives you access to query parameters and headers for conditional logic. Set fail_on_error based on whether you want strict validation or more permissive handling in production.

4. Connect Your AI Platform

Point your AI platform to the Harmony endpoint to start receiving clean JSON instead of implementing protocol-specific client libraries. Instead of writing DICOM client code, your application makes simple HTTP requests and receives JSON responses with the exact schema your AI models expect.

Beyond Healthcare

While these examples focus on medical imaging and clinical data, the patterns apply wherever specialized data needs to reach AI systems. Industrial IoT environments connect sensor data to predictive maintenance models. Financial services bridge legacy banking systems to fraud detection AI. Scientific research normalizes instrument outputs for analysis models. Manufacturing connects quality control systems to defect detection AI.

The key insight: AI integration is a data connectivity problem, not an AI problem. By treating protocol translation and data transformation as infrastructure—not application logic—you can focus on what your AI does, not how it gets its data.

Learn More

Explore the workload library and documentation:

• Runbeam workloads
• Harmony Documentation
• DICOM Integration Guide
• FHIR Integration Guide

Ready to connect your data sources to AI? Start with a template...

The future of AI isn't just better models—it's connecting those models to the data they need, when they need it.