CameleerCameleer / Use cases / DICOM imaging gateway
Medical imaging · health pack · next release
A DICOM router that is also an integration engine
Receive images from modalities and PACS over DIMSE, route on tags, de-identify with the PS3.15 profile, and forward to a PACS, a DICOMweb store or an AI model. HL7 v2, FHIR and about 230 other components run in the same small binary, so the result of an AI model can go back to the EHR as FHIR in the same route. Apache Camel has no DICOM component; Cameleer's health pack adds one with Camel-style names.
Status: in the next release, as the health pack: the image pmsudhi/cameleer:health or cargo install cameleer-main --features health (not in the default image). Not yet tested against the cloud DICOM services of Azure, Google or AWS. What is not supported.
Modality to cloud, without losing an image
From examples/medical/modality-to-cloud.camel.yaml, which the test suite runs end to end (shortened here). The gateway is a Storage SCP for named modalities, keeps CT and MR, and uploads with STOW-RS. When the store is down, the instance is parked in a folder and a second route uploads it later, so the modality is told "stored" only for an image that was uploaded or parked.
- route:
id: modality-to-cloud
from:
uri: "dicom:GATEWAY@0.0.0.0:{{env:DICOM_PORT:11112}}?acceptedCallingAets={{env:MODALITIES:CT01,MR01}}"
steps:
- filter:
simple: "${dicom.Modality} in 'CT,MR'"
steps:
- doTry:
steps:
- to: "dicomweb:{{env:DICOMWEB_URL}}?operation=stow&bearerToken={{env:DICOMWEB_TOKEN:}}&timeout=120s"
doCatch:
- exception: [java.lang.Exception]
steps:
- to: "file:{{env:PARK_DIR:parked}}?fileName=${header.CamelDicomSopInstanceUid}.dcm"
docker run --rm --network host -e DICOMWEB_URL -e DICOMWEB_TOKEN \ -v "$PWD:/routes:ro" -v "$PWD/parked:/parked" pmsudhi/cameleer:health run /routes/modality-to-cloud.camel.yaml storescu -aec GATEWAY localhost 11112 *.dcm # send a study from DCMTK
Three tested examples
Edge imaging gateway
Modality to PACS or to a DICOMweb store, with store-and-forward. modality-to-cloud
AI inference loop
Keep the series a model is for, de-identify it, send it to the inference service, and post the finding as a FHIR DiagnosticReport that points at the original study. The model never sees the identity. ai-inference-loop
De-identification pipeline
A folder in, a folder out, with pseudonyms, shifted dates and an audit record per instance. deid-pipeline
The building blocks
| you want to | use |
|---|---|
| receive images from a modality (Storage SCP) | from: dicom:MYAE@0.0.0.0:11112 |
| send images to a PACS (Storage SCU) | to: dicom:PACS@host:104 |
| store over DICOMweb (STOW-RS) | to: dicomweb:https://host/dicom-web?operation=stow |
| query and retrieve from a PACS | dicom:...?operation=find, move, get |
| answer queries and retrieves yourself | a dicom: consumer route that returns matches or instances |
| serve DICOMweb | from: dicomweb:/dicom-web |
| route on tags | ${dicom.Modality}, ${dicom.(0018,0015)}, sequence paths |
| change tags | unmarshal: dicom, edit the value tree, marshal: dicom |
| de-identify | marshal: {dicomDeidentify: {uidKey: ..., options: ...}} |
| index metadata as JSON | marshal: dicomJson (PS3.18 Annex F) |
| send results to the EHR | the fhir component, or HL7 v2 over MLLP |
Reference: DICOM guide, dicom and dicomweb components, dicomDeidentify, the DICOM Conformance Statement.
De-identification you can check
The profile
dicomDeidentify applies Table E.1-1 of PS3.15 (edition 2026d) with its options, except the pixel options. Replacement UIDs, pseudonyms and date shifts are HMAC-SHA256 values under one secret key: two gateways with the same key produce the same identifiers, and a study split across batches stays together. Each instance writes a record to the hash-chained audit log: digests of the input and output, the profile and its options, no identity.
In a confidential VM
Run the de-identifier in an Intel TDX or AMD SEV-SNP confidential VM with Cameleer's attestation, and a data owner can ask for hardware evidence of which routes and configuration (including the de-identification options) handle the identifiable images before sending them. How attestation works and what it does not prove yet.
What is supported
| area | supported |
|---|---|
| Verification | SCU and SCP |
| Storage | SCU and SCP for every Storage SOP class of PS3.4 (private SOP classes too) |
| Query/Retrieve | Patient Root and Study Root FIND, MOVE and GET as SCU and SCP; Modality Worklist FIND as SCU and SCP |
| Transfer syntaxes | implicit and explicit VR little endian, deflated, explicit big endian (read, write, convert); compressed syntaxes passed through unchanged |
| Character sets | ISO_IR 6, 100, 101, 109, 110, 126, 127, 138, 144, 148, 166, 13 and 192, GB18030, GBK, and their ISO 2022 forms (Japanese, Korean, Chinese) |
| Security | TLS 1.2 and 1.3, mutual TLS, User Identity (username, username and passcode); hash-chained audit records |
| DICOMweb | STOW-RS, QIDO-RS (all levels, limit, offset, includefield), WADO-RS (instances, metadata, bulk data), as client and server |
What it is not, and what is not supported yet
- Not a PACS or a viewer. It routes, filters, transforms and de-identifies; it does not keep an archive or render images.
- Cloud DICOM services not tested yet: Azure Health Data Services, the Google Cloud Healthcare API, AWS HealthImaging (which also needs SigV4 signing in
dicomweb). The DICOMweb tests ran against Orthanc. - Not tested with dcm4che or real modalities yet.
- Not supported: Storage Commitment, MPPS, C-CANCEL during a request, asynchronous operations; WADO frames, rendered and thumbnail retrieval, UPS-RS; transcoding compressed pixel data, and with it the pixel de-identification options.
- Audit format: hash-chained records, not yet IHE ATNA (PS3.15 A.5) messages. The DICOM Conformance Statement (PS3.2 form) lists every service and policy.
- Not measured yet: throughput against dcm4che, DCMTK, Orthanc or Mirth.
- Compliance: Cameleer is software you run; it provides controls (TLS, de-identification, audit), not a HIPAA certification.
Common questions
Does Apache Camel have a DICOM component?
No. Apache Camel has HL7 (mllp, hl7) and FHIR components but no DICOM component. Cameleer's health pack adds dicom (DIMSE), dicomweb (DICOMweb) and the dicom, dicomJson and dicomDeidentify data formats, named to read like Camel.
How do I forward DICOM from a modality to a DICOMweb store?
Start a route from dicom:GATEWAY@0.0.0.0:11112 (a Storage SCP), filter on tags such as ${dicom.Modality}, and send to dicomweb:https://host/dicom-web?operation=stow. The modality-to-cloud example also parks an instance in a folder when the upload fails and retries it later.
Which de-identification profile does Cameleer apply?
The PS3.15 Annex E basic profile (Table E.1-1, edition 2026d) and its options except the pixel options. Replacement UIDs, pseudonyms and date shifts are HMAC-SHA256 values under one key, so the output is deterministic across batches and gateways, and each instance writes a record to a hash-chained audit log.
Has it been tested with real DICOM software?
Yes: the health pack's live tests pass 10 of 10 against DCMTK 3.6.7 (as SCU and SCP, with and without TLS), Orthanc 1.12.2 (as a PACS, and its DICOMweb plugin as server and client), python-hl7 and HAPI FHIR, and 33 public pydicom test files are read and written back byte for byte. The cloud DICOM services of Azure, Google and AWS have not been tested yet.
Which Cameleer build has DICOM?
The health pack, from the next release: the image pmsudhi/cameleer:health, or cargo install cameleer-main --features health. It is not in the default image or the full build; it adds about 2 MB to the binary and also contains HL7 v2, MLLP and FHIR. The health pack.
Is Cameleer a PACS or a viewer?
No. It routes, filters, transforms and de-identifies images between modalities, PACS, cloud stores and AI services. It does not store an archive, render images or transcode compressed pixel data.