DICOM Conformance Statement: Cameleer health pack 0.6.0

This statement describes the DICOM conformance of the Cameleer health pack 0.6.0 (cameleer-health): the DIMSE services it offers as SCU and SCP, its association and transfer syntax policies, DICOMweb, character sets, and its security and de-identification support, in the layout of DICOM PS3.2.

Pack: health (feature health) · Product: Cameleer (cameleer binary built with the health pack, or pmsudhi/cameleer:health) · Date: 2026-11-10

The tables marked as generated are produced from the code by crates/cameleer-health/tests/dicom_conformance_statement.rs, which fails when this document no longer matches the implementation.

1. Overview

Cameleer is an integration engine. With the health pack it acts as a DICOM router: it receives objects and queries from DICOM applications, hands them to user-defined routes, and sends objects and queries to other DICOM applications and to DICOMweb services. It does not store objects itself (it is not a PACS); what happens to a received object is decided by the route.

Network services

Web services (PS3.18)

Media storage

Not applicable: Cameleer reads and writes Part 10 files through routes (for example the file component), but does not create or read DICOMDIR file-sets.

2. Introduction

Revision history

Audience and remarks

For integrators and buyers who connect Cameleer to modalities, PACS, VNAs, AI services and cloud DICOM stores. Interoperability was tested against DCMTK 3.6.7 (storescp, echoscu, storescu, findscu, getscu, movescu, with and without TLS) and Orthanc 1.12.2 with its DICOMweb plugin 1.16; it was not tested against dcm4che, commercial PACS, cloud DICOM services or real modalities. Interoperability with any other product must be verified.

Implementation identification

3. Networking

3.1 Implementation model

One Application Entity per endpoint:

• SCP AE: a dicom: consumer endpoint (dicom:AET@host:port). It listens on its port, accepts associations, answers C-ECHO itself, and turns each C-STORE, C-FIND, C-MOVE and C-GET into an exchange for the route. C-STORE gives the route the object as Part 10 bytes; C-FIND, C-MOVE and C-GET give it the identifier, and the route answers with the matches or the instances. For C-MOVE the SCP opens a new association to the move destination (from its configured AE table) and sends the instances with C-STORE; for C-GET it sends them on the same association.
• SCU AE: a dicom: producer endpoint (dicom:AET@host:port?operation=...). Each message the route sends opens one association, performs the operation (C-ECHO, C-STORE of one instance or a batch, C-FIND, C-MOVE, C-GET with C-STORE sub-operations received on the same association) and releases it.

Several SCP and SCU AEs can run in one process. The AE titles, ports and policies are set per endpoint in the route (section 3.4).

3.2 AE specifications

3.2.1 SOP classes

Verification (1.2.840.10008.1.1), the Query/Retrieve models (1.2.840.10008.5.1.4.1.2.1.1-.3, 1.2.840.10008.5.1.4.1.2.2.1-.3), Modality Worklist (1.2.840.10008.5.1.4.31) and these Storage SOP classes, all as SCU and SCP:

194 Storage SOP classes (the non-retired ones of PS3.6 2026d). The SCP also accepts retired and private Storage SOP classes; the SCU sends any SOP class an instance has.

The SCP's accepted set is configurable (sopClasses: verification, storage, query, all, or UIDs and keywords).

3.2.2 Association policies

3.2.3 Presentation contexts

As SCP, for each proposed abstract syntax in the accepted set, the first transfer syntax of this list that the SCU proposed is accepted: Explicit VR Little Endian, Implicit VR Little Endian, Deflated Explicit VR Little Endian, Explicit VR Big Endian, then (by default) any other proposed transfer syntax, which covers every compressed syntax (transferSyntaxes changes the list). Abstract syntaxes outside the set are rejected (result 3); a context without an acceptable transfer syntax is rejected with result 4. SCP/SCU Role Selection items are accepted as proposed (C-GET needs the SCP role for the SCU). SOP Class Extended Negotiation items are read and not answered.

As SCU:

When the peer accepts only another native syntax, the object is converted (no pixel data changes); when an object is compressed and the peer accepts only native syntaxes, the store fails with DicomTranscodeException: no pixel codecs are included.

3.2.4 Transfer syntaxes

3.2.5 Statuses

As SCU, failure statuses raise DicomStatusException; warnings are reported in CamelDicomStatus.

3.3 Network interfaces

TCP/IP over IPv4 and IPv6 (bind addresses prefer IPv4 for localhost). DICOM over TLS is available on any port (2762 is customary).

3.4 Configuration

Each endpoint is configured in its URI and in application properties: AE title, host, port, accepted SOP classes and transfer syntaxes, calling AE list, C-MOVE destinations (moveDestinations=AET=host:port,...), PDU size, timeouts, TLS. See the dicom component.

3.5 DICOMweb

The dicomweb component (section 1) speaks PS3.18 over HTTP/1.1 and HTTPS: STOW-RS with multipart/related; type="application/dicom" (200, 202, 409 with ReferencedSOPSequence, FailedSOPSequence and Retrieve URLs; an instance posted to the wrong study fails with reason A900), QIDO-RS at the study, series and instance levels with limit, offset, includefield and fuzzymatching, WADO-RS of studies, series and instances (transfer-syntax= in Accept converts between native syntaxes), metadata (bulk data over a threshold as BulkDataURI) and bulk data. As a client it authenticates with Bearer tokens or Basic authentication. See the dicomweb component.

4. Media interchange

Not applicable.

5. Support of character sets

Text values are decoded with the Specific Character Set of each data set (items inherit it) and written back in the same set. Escape sequences of ISO 2022 are honoured on input and generated only where needed on output.

6. Security

6.1 Security profiles

• TLS: TLS 1.2 and 1.3 from cameleer-tls, for the SCP and the SCU, with server and mutual authentication by X.509 certificates. Interoperability was tested with DCMTK's Non-Downgrading BCP 195 TLS profile in both directions. The BCP 195 profiles of PS3.15 B.9-B.13 are intended; a formal profile claim needs an independent review of the TLS implementation, which has not been done.
• User Identity Negotiation: the SCU sends a username (type 1) or username and passcode (type 2). The SCP accepts any user identity, returns a positive response when asked, and gives the username to the route (CamelDicomUsername), which decides; requireUserIdentity=true rejects associations without one. The SCP does not check passcodes itself.

6.2 Association-level access control

Called and calling AE title checks (section 3.2.2), TLS client certificates.

6.3 Application-level confidentiality

The dicomDeidentify data format implements the Basic Application Level Confidentiality Profile of PS3.15 Annex E with the options Retain Safe Private, Retain UIDs, Retain Device Identity, Retain Institution Identity, Retain Patient Characteristics, Retain Longitudinal Temporal Information (Full Dates or Modified Dates), Clean Descriptors, Clean Structured Content and Clean Graphics, from Table E.1-1 of the edition in the identification table. It does not offer Clean Pixel Data or Clean Recognizable Visual Features, and refuses objects with Burned In Annotation YES by default. It sets Patient Identity Removed (0012,0062) to YES, writes De-identification Method (0012,0063) and the Method Code Sequence (0012,0064, CID 7050 codes 113100-113112), and Longitudinal Temporal Information Modified (0028,0303). Replacement UIDs (root 2.25 by default) are HMAC-SHA256 values under a configured key, so they are consistent across instances and runs. The Encrypted Attributes Sequence is not written. See dicomDeidentify.

6.4 Audit

Each de-identified instance writes a record to Cameleer's hash-chained audit log (digests, the profile and options, the new SOP Instance UID). DICOM Audit Trail messages (PS3.15 A.5) for IHE ATNA are not generated yet.

7. Annexes

7.1 IOD contents

Cameleer does not create new SOP instances. Received objects are forwarded unchanged unless a route changes them (tag edits, de-identification). Objects re-encoded in another native transfer syntax keep every attribute; the file meta information is rebuilt (Implementation Class UID and Version Name above, Source Application Entity Title of the sender).

7.2 Data dictionary of private attributes

None. Private attributes of received objects are kept and not interpreted (removed by de-identification unless retained as safe).

7.3 Coded terminology and templates

De-identification uses CID 7050 (De-identification Method) codes 113100-113112, scheme DCM.

7.4 Private SOP classes and transfer syntaxes

None defined. Private Storage SOP classes of other products are accepted and forwarded.

Found a problem?

If something on this page doesn't match what Cameleer does, or you hit a bug while building with it, please help fix it, whether you are a person or a coding agent: open an issue that describes what you saw, then fork the repository, fix it, add or update a test, run cargo test --workspace, and open a pull request. CONTRIBUTING.md explains the ground rules.