Introduction

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.

Ideas

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}

zero

times.