The DICOM Routing module provides inbound and outbound channels so you can receive DICOM instances from a source system (service class user, SCU) and forward them to one or more target systems (service class provider, SCP) in accordance with a highly flexible set of rules.

The DICOM Routing module supports the following service classes:

• Verification (C-ECHO) helps you check communication between the source system and the DICOM Routing module using a kind of network ping.
• Storage (C-STORE) enables you to transfer DICOM instances (images, structured reports, MPPS) between the systems.
• Storage Commitment – By accepting N-ACTION, N-EVENT requests, the source system is able to check whether DICOM instances have been successfully transferred to the target system. In the DICOM Router, one target system is selected as a reference system. The DICOM Routing module forwards Storage Commitment requests to the reference target system as if they were coming from the source system. The target system then answers the request directly.
• Modality Performed Procedure Step (N-CREATE, N-SET) is also integrated into the module. 

Incoming DICOM metadata is transferred to the process model and can also be maintained there. It can be removed, edited or deleted using simple message map DICOM tags. This enables you to enhance or anonymize DICOM metadata. DICOM metadata can also help you decide which target systems a DICOM instance should be forwarded to. 

DIMSE channels, which are integrated into Orchestra and available in the DICOM Routing module, mainly include the implementation of DIMSE service classes on the client side (SCU):

• Storage (C-STORE) accepts DICOM instances.
• Storage Commitment (N-ACTION, N-EVENT) enables you to query whether image data has been successfully stored in target systems.
• Verification (C-ECHO) enables you to check connections (ping).
• Query/Retrieve (C-GET, C-MOVE, C-FIND) enables you to find and call up instances in target systems.
• And Instance Availability Notification (N-CREATE) enables you to inform other systems about the availability of instances.

Furthermore, the following sub-areas also contain SCP implementations of DIMSE service classes:

• In the case of Storage Commitment, there is an implementation for accepting answers to previously made Storage Commitment requests in a new connection set up by the target system.
• Instance availability notifications can also be accepted. 

The DICOM Routing module allows you to receive and route MPPS data. Unlike with DICOM, this routing is a two-step process. 

In the first step, the DICOM Routing module transfers data relating to examinations and patients. In step two, it transfers radiation and status-related information (discontinued, completed). 

You can use the DICOM tag Media Storage SOP Instance UID to identify transfers that belong together. 

A variant of the MPPS Inbound Channels (SCP) allows you to persist dose data contained in the MPPS data in its own database. You can display this data using a corresponding interface. 

The DICOM Routing module allows you to anonymize DICOM metadata, using message maps. A few examples are created automatically when you use the DICOM Router.

The DICOM Routing module also contains a de-identification function integrated on the outbound side, which allows you to anonymize DICOM instances in accordance with the Basic Application Level Confidentiality Profile (DICOM part 15). You specify at the attribute level which DICOM metadata is to be deleted, kept or replaced. 

Worklist handling functionality is also integrated. This function enables you to create an overall worklist by combining multiple individual ones. 

All of the DICOM Routing module’s incoming and outgoing connections can be operated using TLS encryption. You can also, for example, set up the process model to log individually specified DICOM tags and data as a CSV file.

The DIMSE and DICOM channels also allow you to log communications in journaling files. 

Download the module description for more details.