Skip to main content

Sample DICOM Router Productions

There are two sample productions that demonstrate a synchronous and an asynchronous router. These are named Demo.DICOM.Production.Router and Demo.DICOM.Production.AsyncRouter. These productions demonstrate how a user can route DICOM documents. Typically, DICOM uses synchronous messaging, but, in some cases, there are advantages to using an asynchronous router.

Synchronous DICOM Router

The synchronous DICOM router production, Demo.DICOM.Production.Router, completes sending a message to the targets before it can accept another message. The following describes the flow of messages in the Router production:

  • The Remote Service Class User (SCU) connects to the Listener service and sends a message.

  • When the Listener service receives a message, it sends a message to the Dispatcher.

  • The Dispatcher sends a message to each filer. In the sample production, there are two filers.

  • Each Filer sends the messages to an operation, which establishes an association with the appropriate PACS system and sends the document to it.

  • When the Dispatcher receives a successful response from each of the operations, it sends a success response message to the Listener, which can then accept a new message.

Asynchronous DICOM Router

The asynchronous DICOM message Listener can continue to receive messages while the production is processing previous messages. The following describes the flow of messages in the AsyncRouter production:

  • The Remote Service Class User (SCU) connects to the Listener service and starts sending messages.

  • When the Listener service receives a message, it immediately replies with the C-STORE-RSP and accepts responsibility for that message. It sends a message to the AsyncDispatcher.

  • The AsyncDispatcher process queues up an entry in the table Demo_DICOM.BatchedDocument for each Filer. In the sample production, there are two filers: AsyncFiler1 and AsyncFiler2. It uses the Rule Class SendToTargetFiler method to determine if the document should be sent to each filer.

    • If a document is intended for the filer, the AsyncDispatcher sets the DocumentStatus to "Queued".

    • If a document is not intended for the filer, the AsyncDispatcher sets the DocumentStatus to "Ignored".

  • Once the association between the remote SCU and the Listener service is released, the AsyncDispatcher sends a message to each of the Filers for which there are documents queued up in that session.

  • Each Filer sends the messages to an operation, which establishes an association with the appropriate PACS system and sends each of the documents to it.

  • When the production receives the C-STORE-RSP response, it marks the entry in the Demo_DICOM.BatchedDocument table with a DocumentStatus of either "Delivered" if the status was a success or "Errored" if not, in which case the ErrorComment is stored as the entry's Remark.

  • If the Remove Completed Entries setting for the Filer is checked, the filer removes all delivered entries in the current session once all the C-STORE-RSP messages have been received. However, if the remote SCP sends back an ABORT or if the association encounters an error before all the documents for the Filer in the current session have been delivered, then the filer resends all documents in the current session until all the documents are successfully delivered or until it reaches the specified Retry Count. If the filer reaches the specified Retry Count without successfully sending all the documents, then the filer requeues all the documents in the current session and issues an alert. The alert message is sent to Ens.Alert, which send an email alert.

FeedbackOpens in a new tab