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 1823 times.
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).
Hi Damien,
Some administrative functionality on queue of objects to be forwarded would be of immense use. What I'm lacking the most is:
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.
Thanks for all the input everyone. It looks like this project will be on hold though until the new year.
– Damien