Skip to main content

DICOM & DICOMweb

Medplum stores medical imaging alongside the rest of the patient record. A modality or PACS sends studies in over the DICOM network protocol or over DICOMweb, Medplum files them into DicomStudy, DicomSeries, and DicomInstance resources, and a DICOMweb viewer such as OHIF reads them back out — all under the same authentication, access policies, and audit trail as every other resource in the project.

Beta

DICOM support is a Beta feature — ready for testing, with a stable core contract. Tell us what you need at hello@medplum.com or in a GitHub issue.

How it fits together​

There are two ways in and one way out.

In, over the network protocol. Imaging equipment overwhelmingly speaks DIMSE — the DICOM upper layer protocol over raw TCP — not HTTPS, and it speaks it on a hospital network that has no route to the public internet. The Medplum Agent runs inside that network, presents itself as a DICOM Storage SCP, accepts C-STORE from the modality, and forwards each instance to Medplum over an outbound HTTPS connection. This is the same Agent that handles HL7 v2 and ASTM traffic, so a site that already runs one gets imaging by adding a channel.

In, over HTTPS. Anything that can speak DICOMweb — a cloud PACS, a research pipeline, an integration engine, or the Medplum CLI — can POST directly to the STOW-RS endpoint. No Agent required.

Out, over HTTPS. QIDO-RS and WADO-RS serve the study list, series metadata, and pixel frames that a DICOMweb viewer needs. Medplum's implementation targets the request sequence the OHIF Viewer makes.

What gets stored​

A single DICOM instance arriving at Medplum produces four things:

ResourceHolds
DicomStudyStudy-level attributes — study UID, accession number, patient name and ID, study date
DicomSeriesSeries-level attributes — series UID, modality, series description
DicomInstanceInstance-level attributes, plus the full DICOM JSON metadata and references to binaries
BinaryThe original, unmodified .dcm file

Studies and series are created conditionally on their DICOM UIDs, so the second instance of a series attaches to the study and series the first one created rather than duplicating them.

A background worker then reads the raw file and extracts pixel data into one additional Binary per frame, which is what WADO-RS frame retrieval serves. See the Data Model for the full mapping from DICOM attributes to resource fields.

Because these are ordinary Medplum resources, they are searchable with the standard FHIR search API, readable through the TypeScript SDK, subject to access policies, and able to trigger Bots on create or update.

Getting started​

  1. Store a file from your laptop. medplum dicomweb stow MRBRAIN.DCM uploads a DICOM file through STOW-RS with no infrastructure to set up. See the CLI.
  2. Look at it. Medplum's hosted cloud is preconfigured with an OHIF Viewer at viewer.medplum.com — sign in and the study is there.
  3. Connect a modality. Add a DICOM channel to a Medplum Agent and send a C-ECHO, then a C-STORE, from the device.

Reference​