DICOM Integration with Mirth Connect — What's Actually Possible

Set expectations clearly. This is the most-misunderstood part of DICOM + Mirth integration. The engineers who deliver Mirth Connect support for US hospitals and imaging centers get asked this question almost weekly.

What Mirth Connect does well:

• Route HL7 v2 messages that trigger and report on DICOM activities (ORM orders, ORU results)
• Build and maintain modality worklists from incoming HL7 orders
• Receive HL7 ORU messages from RIS systems and route them to downstream consumers
• Communicate with DICOMweb HTTP endpoints (QIDO-RS, WADO-RS, STOW-RS)
• Transform DICOM metadata (in JSON form, extracted by an external tool) into FHIR ImagingStudy resources
• Audit log and trace radiology workflow events

What Mirth Connect doesn't do natively:

• Send or receive raw DICOM over the DICOM network protocol (C-STORE, C-FIND, C-MOVE, C-ECHO)
• Parse DICOM Part 10 files directly without external tooling
• Act as a PACS
• Render or display DICOM images
• Handle DICOM compression, transfer syntax negotiation, or modality-specific quirks at the protocol level

The pattern that works: Mirth Connect handles HL7 + DICOMweb. A purpose-built DICOM gateway handles raw DICOM protocol traffic. They work together.

In production radiology environments, this is the typical data flow:

EHR / Order Entry
    │
    │ HL7 ORM (radiology order)
    ▼
Mirth Connect
    │
    ├─► RIS (Radiology Information System)
    │
    │       │
    │       │ HL7 → Modality Worklist
    │       ▼
    │   DICOM Modality Worklist (MWL)
    │       │
    │       │ C-FIND query
    │       ▼
    │   Modality (CT/MR/X-Ray)
    │       │
    │       │ C-STORE
    │       ▼
    │   PACS
    │       │
    │       │ Image read by radiologist
    │       ▼
    │   RIS dictation
    │
    │ HL7 ORU (final report)
    ▼
Mirth Connect
    │
    ├─► EHR (results posting)
    ├─► Downstream analytics
    └─► FHIR endpoint (ImagingStudy + DiagnosticReport)

Mirth Connect appears twice — at order placement (routing the ORM) and at results finalization (routing the ORU). The DICOM image flow itself happens between the modality and the PACS, outside Mirth.

These are the HL7 v2 message types that drive radiology workflows. The ORM/ORU pair is the workhorse — most radiology integration work centers on getting these two right.

For the broader pattern across order/result workflows, see our HL7 ORM/ORU lab workflow guide — same message types, lab perspective.

When a clinician orders a radiology study, the EHR generates an HL7 ORM message. This message has to reach two destinations: the RIS (to schedule and track the study) and the modality worklist (so the imaging modality knows the study is coming).

Mirth Connect's role:

EHR → MLLP listener (Mirth source)
    ↓
Filter: only ORM^O01 messages with appropriate procedure codes
    ↓
Transformer: validate, normalize patient identifiers, enrich with current ADT data
    ↓
Destination 1: RIS (HL7 over MLLP or HTTP)
Destination 2: MWL builder (writes worklist entry to DICOM MWL service)

The MWL builder destination is typically not Mirth itself — it's a worklist service (dcm4che's dcm4chee Worklist SCP, a vendor RIS's MWL endpoint, or similar). Mirth pushes the structured order data to the worklist service via HTTP, JDBC write, or another HL7 channel.

When a radiologist finalizes a report, the RIS generates an HL7 ORU message containing the report text, often including embedded structured findings.

Mirth Connect's role:

RIS → MLLP listener (Mirth source)
    ↓
Filter: ORU^R01 with radiology service identifiers
    ↓
Transformer: extract report text, parse OBX segments, link to accession number
    ↓
Destination 1: EHR (results posting via HL7)
Destination 2: Analytics warehouse (transformed payload to S3/data lake)
Destination 3: FHIR endpoint (ImagingStudy + DiagnosticReport resources)

The third destination — pushing to a FHIR endpoint — is increasingly common as organizations build modern FHIR-based applications on top of radiology workflows. See our HL7 v2 to FHIR R4 mapping reference for the segment-level translations.

DICOMweb (formally part of the DICOM standard) is HTTP-based DICOM. It includes three core services:

Because DICOMweb runs over standard HTTPS, Mirth Connect can interact with DICOMweb endpoints natively using HTTP Sender destinations and HTTP Listener sources. No special DICOM toolkit required.

Example pattern — querying a study via QIDO-RS:

HTTP Sender destination:
URL: https://pacs.example.org/dicomweb/studies
Method: GET
Query parameters:
  PatientID = {patient_mrn}
  StudyDate = {study_date}
Headers:
  Accept: application/dicom+json
  Authorization: Bearer {token}

The response is JSON describing matching studies, which Mirth can parse, transform, and route like any other HTTP response.

When to use DICOMweb instead of traditional DICOM:

• Modern PACS systems and image archives — most now support DICOMweb
• Cloud-hosted imaging archives — AWS HealthImaging, Google Cloud Healthcare, Azure DICOM service all use DICOMweb
• Mobile and web-based imaging applications
• Cross-organization imaging exchange where DICOM ports aren't accessible

When to use traditional DICOM:

• Direct modality-to-PACS communication
• Legacy PACS systems without DICOMweb support
• High-volume image transfer where the binary DICOM protocol is more efficient

For organizations building FHIR-based applications that need radiology data, the DICOM-to-FHIR mapping centers on ImagingStudy.

ImagingStudy structure (high level):

{
  "resourceType": "ImagingStudy",
  "identifier": [
    {
      "system": "urn:dicom:uid",
      "value": "urn:oid:1.2.3.4.5.6.7.8.9"
    }
  ],
  "status": "available",
  "subject": { "reference": "Patient/abc-123" },
  "started": "2026-05-12T14:30:00-05:00",
  "modality": [
    { "system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT" }
  ],
  "numberOfSeries": 4,
  "numberOfInstances": 234,
  "endpoint": [
    { "reference": "Endpoint/dicomweb-pacs-1" }
  ],
  "series": [
    {
      "uid": "1.2.3.4.5.6.7.8.9.1",
      "number": 1,
      "modality": { "code": "CT" },
      "numberOfInstances": 60,
      "bodySite": { "code": "Chest" },
      "instance": [
        {
          "uid": "1.2.3.4.5.6.7.8.9.1.1",
          "sopClass": { "code": "1.2.840.10008.5.1.4.1.1.2" },
          "number": 1
        }
      ]
    }
  ]
}

Where the data comes from:

• DICOM Study metadata (extracted via QIDO-RS or DICOM toolkit) → ImagingStudy top-level fields
• DICOM Series metadata → ImagingStudy.series
• DICOM Instance metadata → ImagingStudy.series.instance
• The actual pixel data stays in the PACS — endpoint references where it can be retrieved

Mirth Connect's role: receive DICOM metadata (typically as JSON from a DICOMweb QIDO-RS query, or from a DICOM toolkit that pre-extracted the metadata), transform to ImagingStudy resource, push to FHIR endpoint.

The actual binary pixel data is not transformed by Mirth. It stays in the PACS, accessible via WADO-RS for consumers that need it.

Three patterns cover almost every production DICOM + Mirth deployment we see.

Pattern A — Mirth + dcm4che gateway (on-premise PACS)

For traditional on-premise hospital environments with legacy PACS that don't speak DICOMweb.

EHR ──HL7──> Mirth Connect ──HL7──> RIS / dcm4che MWL
                                          │
Modalities ──DICOM──> dcm4che gateway ──DICOM──> PACS
                                          │
RIS ──HL7──> Mirth Connect ──HL7──> EHR + downstream
                                  ──FHIR──> FHIR endpoint

Mirth handles HL7. dcm4che handles DICOM. Together they cover the full workflow.

Pattern B — Mirth + DICOMweb cloud archive

For modern deployments using cloud imaging services (AWS HealthImaging, Azure DICOM, etc.)

EHR ──HL7──> Mirth Connect ──HL7──> RIS
                                ──HTTP──> Cloud DICOMweb (worklist)

Modalities ──DICOMweb STOW──> Cloud DICOM Archive

RIS ──HL7──> Mirth Connect ──HTTP──> FHIR endpoint
                              ──HL7──> EHR

Mirth talks DICOMweb directly via HTTP. No separate DICOM gateway needed.

Pattern C — Hybrid (most real-world deployments)

The reality at most healthcare organizations is hybrid: some legacy PACS speaking traditional DICOM, some newer systems speaking DICOMweb, plus FHIR consumers for modern applications.

                                            ┌─> Legacy PACS (DICOM)
Modalities ──DICOM──> dcm4che gateway ──────┤
                            │               └─> Cloud archive (DICOMweb)
                            │
EHR ──HL7──> Mirth Connect ─┘
                            │
                            ├──HTTP──> DICOMweb cloud archive
                            └──HTTP──> FHIR ImagingStudy endpoint

Mirth Connect's flexibility shines here — it speaks HL7, MLLP, HTTP/HTTPS, and can orchestrate across the heterogeneous environment.

Use a DICOM-specific tool when:

• You need to send or receive raw DICOM over the network (C-STORE, C-FIND, C-MOVE)
• You need to parse DICOM Part 10 files
• You need to convert between DICOM transfer syntaxes
• You need to render images
• You need to perform DICOM compression / decompression
• You need DICOM-specific compliance features (DICOM TLS, DICOM audit messages)

Recommended DICOM tooling:

These tools work alongside Mirth Connect, not as replacements for it.

Seven mistakes we see repeatedly when auditing radiology integration projects.

Mistake 1 — Trying to use Mirth Connect for raw DICOM C-STORE

It's not what Mirth does. Use dcm4che or Orthanc for the DICOM protocol layer.

Mistake 2 — Forgetting that DICOM uses a separate identifier system

DICOM has StudyInstanceUIDs, SeriesInstanceUIDs, SOPInstanceUIDs, and Accession Numbers. HL7 has its own identifiers. Mapping between them correctly is critical and often missed in initial designs.

Mistake 3 — Not handling delays between order placement and image acquisition

A patient may be scheduled but not yet imaged. Workflows that assume immediate image availability break when reality intervenes. Build polling or event-driven patterns for this.

Mistake 4 — Treating ORU as the only source of results data

Many modern systems also publish FHIR DiagnosticReport resources, and some PACS publish structured findings via DICOM Structured Reporting (SR). A complete results workflow may need to handle multiple sources.

Mistake 5 — Ignoring DICOM SR (Structured Reporting)

Most radiology integrations parse only the free-text report. DICOM SR carries structured findings that, when available, are more useful for downstream applications. Worth handling explicitly.

Mistake 6 — Underestimating ImagingStudy complexity

ImagingStudy is one of the more complex FHIR resources because of its nested structure (study → series → instance) and DICOM-specific terminology. Budget time for getting the mapping right.

Mistake 7 — Not addressing teleradiology / multi-site workflows

Single-site radiology is simpler than multi-site. Cross-site image sharing has its own protocols (XDS-I, IHE profiles) that may or may not flow through Mirth depending on architecture.

DICOM integration touches multiple specialized domains — HL7 v2, DICOM network protocols, DICOMweb, FHIR ImagingStudy, PACS architecture, and modality-specific quirks. Teams that haven't done it before often underestimate the time investment by 2-3x.

If you're building radiology integration with Mirth Connect, we work on these architectures regularly. Book a 30-minute scoping call and we'll discuss your specific environment, the HL7-to-DICOM workflow patterns that fit, and whether you need a dedicated DICOM gateway alongside Mirth.

Book a scoping call →

For related context, see our HL7 v2 to FHIR R4 mapping reference, our Mirth Connect guide pillar, and our HL7 ORM/ORU lab workflow guide which covers the same message types from the lab perspective.

For broader healthcare integration estimation, run our pricing calculator and select radiology/PACS as one of your target systems.

Prefer email? info@tactionsoft.com — we reply within 4 business hours.