Page tree
Skip to end of metadata
Go to start of metadata


In dcm4chee, DICOM objects which are transmitted out of the system (either as the result of a C-MOVE, or autoforwarding/routing) end up going through the Move SCU Service. There is currently a funded project to do some development in this area. It is not clear whether this will happen in dcm4chee 2.x or dcm4chee 3.x, but it will likely happen in early 2008.

The main area that I am concerned with is creating an administrative user interface for the move SCU service. This includes a management console so that I can see what is in the queue, what has been sent, transfer times, delete queued transmissions, send something immediately, etc. The user interface for this will be proprietary, but the back end process and API will be built into the core dcm4chee product. With that in mind, I want to open up the discussion to the dcm4che community.


This page is meant as a place to brainstorm about potential improvements to the Move SCU Service, and its operations. Please put any ideas you have here...

It is possible (likely?) that this development would occur in parallel to the current MoveSCU implementation.

List of desired functionality from a web user interface:

  • View move SCU items in their various states (pending, completed, failed, canceled, etc.)
  • View transmission time for completed move SCU items
  • Cancel a pending move SCU item
  • Time to live for an item in the queue after it has been completed/failed/canceled.
  • Trigger a pending item to be sent immediately

List of desired functionality of the forward service (above and beyond what the service currently offers):

  • An API that exposes methods/attributes to achieve the desired GUI functionality.
  • The ability to only forward if the content has changed, e.g. the MD5 of newly stored images is different than previously stored images. This is to eliminate duplicate forwarding operations when a misbehaved DICOM device sends in the same data multiple times.

This page has been viewed

Unknown macro: {tracking-info}



  • No labels


  1. Would like to have the ability to select a preferred transfer syntax per destination. 'External' destinations  are often on slow links so it would help to compress before sending.

    I think right now DCM4CHEE will send using whatever compression method is used for the stored object as long as the destination accepts the syntax - else no compression is used (either ImplicitVRLittleEndian or ExplicitVRLittleEndian I'm not sure which).

  2. Unknown User (petrkalina)

    Hi Damien,

    Some administrative functionality on queue of objects to be forwarded would be of immense use. What I'm lacking the most is:

    • global reset of timeouts on all items in the queue (start processing from the beginning)
    • selective delete by target aet (and selective reset of timeouts by aet - ot the "send immediately" you mention..)
    • some better viewing/qurying means would be great

    Just an Idea: how about having a new tab in the web console for the moveSCU queue with options query and sort it and with functional buttons like in other web console tabs? There could be query fields like target AET, time interval of next retry, expiration, creation date, buttons displayed on each row for viewing appropriate details, selector checkbox and some functionality on selected items - delete, reschedule, send imediately, reset retry intervals etc... meybe one could even fit in some way to configure the retry intervals and other config like transfer syntaxes etc per aet there..

    To enable effective queries into the queue would probably lead to changing the queue to a full blown database table, but that doesn't seem like problem to me.

  3. Unknown User (damien)

    Thanks for all the input everyone. It looks like this project will be on hold though until the new year.

    – Damien

  4. Unknown User (whats)


    another nice functionality on the forward service, will be the possibility to forward to N clients at time, but mantaining the currency param.

  5. I think I now have a reasonable solution for management of the Move SCU Service.
    Basically I make use of the Unified Worklist and Procedure Step implementation that has recently been added to DCM4CHEE.

    The following Operations are available (UPS SCU):



    Move Service Implementation Notes


    Create an Unified Procedure Step.

    UPS is created for each new Move Order.


    Set Unified Procedure Step Information

    Move Order details are copied to the UPS. Information is updated for re-tries and upon failure.


    Get Unified Procedure Step Information



    Search for Unified Procedure Step

    User can search for specific orders.


    Change UPS State



    Request UPS Cancel

    User can request cancellation of a Move Order.


    Subscribe to Receive UPS Event Reports



    Unsubscribe from Receiving UPS Event Reports



    Suspend Global Subscription.


    Note: With this approach the underlying message queues remain.

    I can provide more details if anyone is interested.

    1. Unknown User (

      This looks really interesting. Have you implemented it?  Is it available anywhere?

      1. I have this (mostly) implemented but I have not yet made it 'publicly' available - unfortunately I have not had time in recent months.

        The main missing component is a GUI front-end for the Unified Worklist.