DICOM and DICOMweb Destinations

This page allows you to configure destinations for your forward nodes. Destinations define where DICOM instances are sent and how they are processed during transfer.

Depending on the protocol used, two types of destinations can be created:

• DICOM Destinations - Traditional DICOM protocol
• STOW Destinations - DICOMweb (STOW-RS) protocol

DICOM Destination

A DICOM Destination uses the traditional DICOM protocol to forward instances to another DICOM node.

Creating a DICOM Destination

AETitle, Hostname and Port are mandatory when creating a DICOM Destination.

Configuration Options

1. Destination Parameters

These fields define where Karnak should send the DICOM instances.

• AETitle: The Application Entity Title that identifies the destination DICOM node (16 characters max, no whitespace).
• Description: An optional label shown in the destination list.
• Hostname: The IP address or hostname of the destination server.
• Port: The network port used by the destination DICOM service (must be between 1 and 65535).
• Concurrent connections: The number of parallel DICOM associations Karnak opens to this destination (between 1 and 50; 1 means a single connection). Increasing this value improves throughput when forwarding large studies, but must stay within the destination PACS’s concurrent-association limit.
• Condition (labeled Condition (Leave blank if no condition)): An optional field that can contain an expression. If the condition is met, the destination will be activated. See Conditions for more details.

2. Transfer Syntax

This field defines the transfer syntax used when sending DICOM instances to this destination. The transfer syntax determines the encoding and compression format of the DICOM data.

It is recommended to choose “Keep original transfer syntax” unless you have specific requirements for compression or compatibility with the destination system.

When selecting a specific transfer syntax, ensure that the destination system supports it to avoid decompression or compatibility issues. When you select a compressed transfer syntax, the Transcode only uncompressed checkbox becomes available and is checked automatically so that instances that are already compressed are not re-encoded; uncheck it only if every instance must be transcoded. The checkbox is disabled for Keep original transfer syntax and Explicit VR - Little Endian.

3. Use AETitle Destination

When this option is checked, use the destination AETitle as the calling AETitle instead of the Forward Node AETitle during the DICOM association.

4. Notifications

Check Activate notification to receive automatic email summaries of forwarded instances, including success and error reports.

Configuration fields (on screen each label is prefixed with Notif.: and shows its default inline, e.g. Notif.: error subject prefix (Default: **ERROR**)):

5. Virtual Destination

When Virtual destination (report only, discard DICOM) is checked, the destination does not forward anything to a real node. Each study is still received and validated, but the only output is the DICOM conformance report, which is emailed. Delivery settings (transfer syntax, notifications, etc.) do not apply, and the conformance report is mandatory and cannot be turned off while the destination is virtual.

This is useful to validate DICOM conformance — for testing, validation-only deployments, or audit purposes — without sending any data.

6. DICOM Conformance Report

Enable Build DICOM conformance report to validate every study sent to this destination against the DICOM standard and email an HTML report. When enabled, options appear to set the report’s recipient emails, to also check value content conformity (VR rules), to perform deep sequence validation, and to check for identifying data burned into the image (this last option runs OCR through the external de-identification image service, which must be reachable at OCR_URL, http://localhost:8000 by default).

See the dedicated Conformance Report page for what each option does, when the report is sent, and what it contains.

7. Tag Morphing

Tag morphing allows you to modify specific DICOM tag values defined in a profile. With this mode, it is not mandatory to de-identify patient information like in De-identification mode.

Prerequisites:

• A project must be created first
• The project must have an associated profile

Configuration:

1. Select the project from the dropdown
2. The applied profile and its version are displayed below the selection

If no project exists yet, the same no-project popup shown for de-identification appears, letting you create one or cancel.

8. De-identification

De-identification removes or replaces patient-identifying information in DICOM instances according to configurable rules and profiles. It is not possible to preserve the patient identity in the profile when this option is activated.

Prerequisites:

To activate de-identification, you must create a project first.

If no project exists:

A popup will appear with two options, either create a project or continue without activating de-identification.

If a project exists:

Configure de-identification as shown below:

Project Selection

Select the project that defines the de-identification profile to apply. The profile name and version are displayed below the selection.

Each project is associated with:

• A de-identification profile
• A secret key used for pseudonymization and UID generation

See the Projects page for more information about project configuration.

Pseudonym Type

Pseudonyms replace patient identifiers while maintaining the ability to link de-identified data back to the original patient (when necessary and authorized).

Choose how Karnak should retrieve or generate pseudonyms:

Pseudonym is already stored in KARNAK

This option queries the pseudonym stored in the internal cache as explained in External Pseudonym.

Behavior:

• Karnak queries its internal cache using the Patient ID and Issuer of Patient ID
• If a pseudonym is found, it is used for de-identification
• If no pseudonym is returned, the transfer of the DICOM instance is aborted. Ensure pseudonyms are correctly populated in External Pseudonym.

Pseudonym is in a DICOM tag

This option retrieves the pseudonym from a specified DICOM tag within the instance itself.

Required configuration:

• Tag: The DICOM tag containing the pseudonym (e.g., Clinical Trial Subject ID (0012,0040))

Optional configuration (both must be set together):

• Delimiter: Character used to split the tag value
• Position: Which part to use after splitting (zero-based index)

Example:

If tag (0012,0040) contains "SITE01-PSN12345" and you set:

• Delimiter: -
• Position: 1

The pseudonym will be "PSN12345".

If no delimiter and position are specified, the entire tag value is used as the pseudonym.

Pseudonym from external API

This option makes an API call to retrieve the pseudonym from an external service.

The detailed usage of all the fields is explained in the API Actions page. The behavior is identical to profile API actions.

You can reference an Authentication Configuration to securely manage API credentials for OAuth 2.0.

Issuer of Patient ID by default

This field (labeled Issuer of Patient ID by default) provides a default value for the Issuer of Patient ID when it’s not present in the DICOM instance. It is only shown when the pseudonym type is Pseudonym is already stored in KARNAK.

Usage:

This value is used when retrieving the pseudonym using the External Pseudonym cache. The pseudonym is queried based on:

• Patient ID (from DICOM tag 0010,0020)
• Issuer of Patient ID (from DICOM tag 0010,0021 or this default value)

The combination of Patient ID and Issuer ensures unique patient identification across different healthcare systems.

Ignore the Issuer of Patient ID (cache lookup)

This option is only available when the pseudonym type is Pseudonym is already stored in KARNAK. On screen it is the Ignore Issuer of Patient ID checkbox. When checked, the Issuer of Patient ID of the incoming image is ignored when building the key used to look up the pseudonym in the cache.

It is enabled by default, so the same Patient ID is matched even when it is registered under a different (or missing) issuer in the External Pseudonym cache than in the images you receive. Uncheck it if you need the issuer to be part of the lookup key. When this option is checked, the Issuer of Patient ID by default field is cleared and disabled, since it no longer takes part in the lookup.

9. Authorized SOPs

Filter which DICOM instance types (SOP Classes) are forwarded to this destination.

Configuration:

• Enabled: Only instances matching the specified SOP Classes are transferred. At least one SOP Class must be selected, otherwise the destination cannot be saved.
• Disabled: All SOP Classes are transferred without restriction

10. Enable the Destination

The Enable destination checkbox allows you to temporarily disable a destination without deleting it. The state is also visible in the destination list with a green (enabled) or red (disabled) indicator.

Use this feature to:

• Temporarily pause forwarding during maintenance
• Test configurations without affecting production destinations
• Keep backup destination configurations ready but inactive

11. Action Buttons

Three actions are available to manage the destination:

STOW Destination

A STOW Destination forwards instances over DICOMweb (STOW-RS) to a web server such as a DICOMweb-enabled PACS or a Kheops instance.

Creating a STOW Destination

The URL is required for STOW Destination creation. Most configuration options are identical to DICOM Destinations. Only the differences are detailed below.

Configuration Differences

1. Destination Parameters

URL: The DICOMweb STOW-RS endpoint where DICOM instances will be sent (e.g., https://pacs.example.com/dicomweb/studies).

Condition: An optional expression that activates the destination when met. See Conditions for more details.

Use HTTP/2

When Use HTTP/2 is checked, STOW-RS uploads use HTTP/2 instead of HTTP/1.1.

HTTP Headers

The Headers field contains HTTP headers added to each STOW-RS request.

Format: Headers are defined using XML-style key-value tags as shown below:

<key>Header-Name</key>
<value>Header-Value</value>

<key>Another-Header</key>
<value>Another-Value</value>

Generate Authorization Header

Click the Generate Authorization Header button to automatically generate properly formatted authentication headers.

Supported Authorization Types: the dialog has an Authorization Type selector (Basic Auth or OAuth 2) and a Generate Headers button that appends the generated header.

Basic Auth

Use for simple username/password authentication:

Generated headers:

<key>Authorization</key>
<value>Basic dXNlcm5hbWU6cGFzc3dvcmQ=</value>

The username and password are Base64-encoded automatically.

OAuth 2

Use for token-based authentication:

Generated headers:

<key>Authorization</key>
<value>Bearer 1234567890</value>

2. Switching to different Kheops albums

If the destination is a Kheops endpoint, it is possible to configure multiple albums by selecting the option “Switching in different KHEOPS albums”.

Explanations for configuring Kheops-related parameters can be found in the Kheops section.