Runbeam logo

Visualizing Harmony Pipelines

A look at common Harmony configuration patterns through our new visualization system.

Runbeam Team
March 20, 2024

Harmony is designed to be the flexible glue between your healthcare data systems. Whether you're routing DICOM images, proxying FHIR requests, or transforming JSON payloads, pipelines are at the core of how data moves through Harmony.

To help visualize these flows, we've introduced a new diagramming system. Let's explore some common Harmony patterns using these new visualizations.

DICOM SCP Pipeline

One of the most common use cases for Harmony is acting as a DICOM Service Class Provider (SCP). In this configuration, Harmony accepts incoming DICOM associations (like C-STORE or C-FIND) and routes them to storage or other systems.

Here is a visualization of a standard DICOM SCP workflow where images are received, validated, and stored to disk:

Sources
Modality
CT Scanner
Harmony
Frontend
DICOM Listener
Port 11112
Middleware
Validation
AE Title Check
Backend
File Adapter
Write to Disk
Targets
PACS Archive
File System

In this example, the Modality initiates the connection. Harmony accepts the association via its DICOM Listener, validates the AE Title, and then streams the received DICOM files to the Storage backend.

FHIR Proxy with Authentication

Modern healthcare interoperability often relies on FHIR, but legacy systems might not support modern authentication standards. Harmony can act as a secure gateway, adding authentication layers to existing FHIR servers.

Sources
Mobile App
Patient Portal
Harmony
Frontend
HTTP Ingress
Port 8080
Middleware
Auth Guard
OAuth2 / JWT
Rate Limit
100 req/min
Backend
HTTP Client
Forward Request
Targets
Firely Server
FHIR R4

The pipeline above demonstrates a request where the Auth Guard middleware first validates the credentials. Only successful requests are passed to the Harmony Proxy core, which forwards them to the upstream Firely Server.

JOLT Transformation Pipeline

Data rarely arrives in the exact format you need. Harmony includes a powerful transformation engine based on JOLT (JSON of Large Transform), allowing you to restructure payloads on the fly without writing custom code.

Sources
Legacy System
HL7v2 -> JSON
Harmony
Frontend
Webhook
Receive POST
Middleware
JOLT Transform
Schema Mapping
Validation
Schema Check
Backend
FHIR Client
POST Bundle
Targets
FHIR Store
Cloud API

This pipeline takes a Raw Input payload, passes it through the JOLT Engine to apply a transformation spec (like patient_to_fhir.json), performs final Normalization, and delivers a compliant FHIR Bundle to the destination.

Building Your Own

These diagrams are just a glimpse of what's possible with Harmony. By chaining middleware and configuring flexible backends, you can build complex integration pipelines that solve real-world interoperability challenges.

Check out the examples directory in our repository to try these configurations yourself.

Read next

Runbeam vs Boomi: Healthcare Integration Platform or iPaaS?

December 5, 2025Engineering

Comparing Boomi's iPaaS and low-code integration approach with Runbeam's healthcare-focused data mesh and protocol-native interoperability. Learn when a generic iPaaS is the right fit versus when you need purpose-built healthcare connectivity across FHIR, HL7, DICOM, and distributed networks.