Retrieving off-line studies from DICOM archive
Yoad Gidron
In a large-scale PACS system many of the studies may be stored off-line
(i.e. on tapes or MO). When a GET request comes for one of these
studies, it could take several minutes before the study is retrieved
from the off-line media, and sent out to the client. This can take a
relatively long time (minutes), and there might be time-out conditions
detected by the client, and so on.
How does the DICOM protocol support this situation? :
Yoad Gidron
Haifa Research Lab
IBM
Todor Kantchev
If you are "GETting" composite objects (CGET) the service will keep the
association for you as long as you whant to (provided there is no a
non-standard inter-block timer set up). If you expect a longer time for
the operation to complete you may wish to call the service on a separate
thread and get back the result when it completes, using the
multithreading primitives of your operating system (both, WindowsNT and
UNIX now support multithreading).
Alternatively you may whant to build a private class and use the
N-EVENT-REPORT service element, but this will not safe you from the
multithreading, because you need to know the result back (Ok or Error)
and you whant to utilise CPU time. So, N-EVENT-REPORT is only used for
asynchronous events, not related to a particular operation. For
instance, in the Print Management service class, the printer reports
to all associated clients any change of its status, by using
N-EVENT-REPORT.This is an example, where N-EVENT-REPORT is used in a
standard service class.
Tod
--
Todor Kantchev e-mail: tkan...@markcare.co.uk
Tel: +44(0)1428 605030
MarkCare Medical Systems,Ltd, Headley House,Headley Road,
Grayshott, Hampshire, England GU26 6TU
David Clunie
A couple of observations.
First, no one supports C-GET (image retrieval on the same association
as the request) - everyone uses C-MOVE (image retrieval request goes on
one association, images come back by a C-STORE on another).
The lifetime of these associations is not specified by DICOM, but in
practice many implementations have configurable timeouts as you hint
at.
Many people use private SOP classes to give hints to the archive
that a move request is coming (a "migrate to online store request"
for example).
Interestingly enough, there has never been any push by anyone to
attempt to standardize these kinds of services in DICOM itself.
david
Todor Kantchev wrote:
> Yoad Gidron wrote:
> > In a large-scale PACS system many of the studies may be stored off-line
> > (i.e. on tapes or MO). When a GET request comes for one of these
> > studies, it could take several minutes before the study is retrieved
> > from the off-line media, and sent out to the client. This can take a
> > relatively long time (minutes), and there might be time-out conditions
> > detected by the client, and so on.
...
> If you are "GETting" composite objects (CGET) the service will keep the
> association for you as long as you whant to (provided there is no a
> non-standard inter-block timer set up). If you expect a longer time for
> the operation to complete you may wish to call the service on a separate
> thread and get back the result when it completes, using the
> multithreading primitives of your operating system (both, WindowsNT and
> UNIX now support multithreading).
...
Todor Kantchev
David Clunie wrote:
>
> A couple of observations.
>
> First, no one supports C-GET (image retrieval on the same association
> as the request) - everyone uses C-MOVE (image retrieval request goes on
> one association, images come back by a C-STORE on another).
>
CGET is much simpler and more reliable than CMOVE and should be used
always in stead of CMOVE where possible. The only advantage CMOVE has,
is that the images can be sent to a location, different from the one, in
which the request originated. However even in this case, the CMOVE
operation completes after all CSTORE sub-operations on the other
association, have completed. This means, that if the requester is
interested in the result from the master operation, it has to wait until
all the responses, including the final one, have been serviced. The
fact, that many people create unreliable implementations, by closing the
association after the operation CMOVE has been accepted by the
performer, without waiting for the result, does not mean, that we should
promote such implementations.
> The lifetime of these associations is not specified by DICOM, but in
> practice many implementations have configurable timeouts as you hint
> at.
>
Since DICOM prescribes one association per a TCP connection, it thus
implicitly specifies the lifetime as well- it is the lifetime of the
TCP/IP connection.
> Many people use private SOP classes to give hints to the archive
> that a move request is coming (a "migrate to online store request"
> for example).
>
> Interestingly enough, there has never been any push by anyone to
> attempt to standardize these kinds of services in DICOM itself.
>
I am not promoting indiscriminate use of private classes. I just wanted
to say, that DICOM is not rigid and it can accomodate different, highly
specific needs, if neccessary. On this particular issue, however, I do
not see any such need.
> david
>
Tod.
> Todor Kantchev wrote:
>
> > Yoad Gidron wrote:
>
> > > In a large-scale PACS system many of the studies may be stored off-line
> > > (i.e. on tapes or MO). When a GET request comes for one of these
> > > studies, it could take several minutes before the study is retrieved
> > > from the off-line media, and sent out to the client. This can take a
> > > relatively long time (minutes), and there might be time-out conditions
> > > detected by the client, and so on.
>
> ...
>
> > If you are "GETting" composite objects (CGET) the service will keep the
> > association for you as long as you whant to (provided there is no a
> > non-standard inter-block timer set up). If you expect a longer time for
> > the operation to complete you may wish to call the service on a separate
> > thread and get back the result when it completes, using the
> > multithreading primitives of your operating system (both, WindowsNT and
> > UNIX now support multithreading).
>
> ...
--
David Clunie
Todor Kantchev wrote:
> We at MarkCare do!
> CGET is much simpler and more reliable than CMOVE and should be used
> always instead of CMOVE where possible. The only advantage CMOVE has,
C-Get may be convenient for one particular style of coding, but is
not inherently more or less reliable, nor more or less efficient
than C-Move, nor more or less complex. It is just different.
Regardless of the perceived advantages or disadvantages of C-Get as
opposed to C-Move, the fact remains that almost nobody on the planet
uses it.
Whether it is in the standard or not, the marketplace has spoken.
If you don't believe me, check the conformance statement survey that
Otech now maintains.
The goal of the DICOM standard is interoperability. If one wants to
be able to talk to other vendors archives, workstations and modalities
then one has to use C-Move.
If one wants to define an internal architecture based on DICOM
services and C-Get fits one's needs then fine, but if one expects
to mix and match components from different sources, or communicate
bidirectional at the boundary of the PACS, then sooner or later you
are going to have to reimplement all the functionality with C-Move to
get the desired interoperability.
david
--
David A. Clunie (david....@med.ge.com)
GE Medical Systems - Global System Connectivity Platform
PO Box 414, SN-475, Milwaukee WI 53201
Phone/Fax +1-414-521-6812/6800
Todor Kantchev
Hi,
CGET is obviously less complex since it does not involve another
association.
What you say about the market now is unfortunately true.
Tod.
--
cl...@net1plus.com
In article <34BDE6...@smimed.co.uk>,
to...@smimed.co.uk wrote:
>
> Hi,
>
> CGET is obviously less complex since it does not involve another
> association.
>
I think that you are right in one specific sense: We gave very serious
consideration to supporting C-Get as part of a Q/R SCU because it would
allow AEs that connected onto the network at various times and from
various places to work more cleanly than does C-Move
The problem with supporting a C-Move is that the Q/R SCU must be a
Storage SCP -- and that means that its IP address and TCP/IP port should
be known by the other end in advance. Portable systems, that may be
connecting onto the network remotely or be moved from one room to another
within an organization can be inconvenienced by this.
However, given the rarity with which C-Get is used, we decided that it
would end up creating more problems than it solved.
--Tom Clune, Principal Software Engineer, Howtek, Inc.
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Dave Harvey
cl...@net1plus.com wrote in message <884892206...@dejanews.com>...
>In article <34BDE6...@smimed.co.uk>,
> to...@smimed.co.uk wrote:
>> CGET is obviously less complex since it does not involve another
>> association.
>
>I think that you are right in one specific sense: We gave very serious
>consideration to supporting C-Get as part of a Q/R SCU because it would
>allow AEs that connected onto the network at various times and from
>various places to work more cleanly than does C-Move
>
>The problem with supporting a C-Move is that the Q/R SCU must be a
>Storage SCP -- and that means that its IP address and TCP/IP port should
>be known by the other end in advance. Portable systems, that may be
>connecting onto the network remotely or be moved from one room to another
>within an organization can be inconvenienced by this.
>
>However, given the rarity with which C-Get is used, we decided that it
>would end up creating more problems than it solved.
I agree with the general sentiment of this thread that there is an overall
move away from C-GET to C-MOVE support, but I'd like to put in a plea on
behalf of C-GET, before it gets completely forgotten:
The particular experience I have of the usefulness of C-GET involves the
writing DICOM gateways, such as a DICOM <-> http gateway. Using C-GET, this
is quite straightforward, the incoming http request fires off a process
which connects to the DICOM server, retrieves the image, converts to
whatever and returns it to the requester, all in one nice sequential thread
of execution.
The alternative using C-MOVE is much more complex, requiring a second
"listening" thread, the need for inter-thread communication and
synchronisation mechanisms, and a means of identifying which incoming SOP
instance belongs to which request. Whilst none of these problem are
insurmountable, the level of complexity would preclude the simple but
effective solutions possible using simple scripting http servers such as
Microsoft's active server pages.
Certainly, C-MOVE can be seen as a more flexible, and arguably more secure
operation than C-GET, but the utility of C-GET for simple operations should
not be forgotten.
Dr David Harvey
Medical Connections (med...@dial.pipex.com)
Fax: +44 1792 234938
http://ds.dial.pipex.com/medconn
Girish Nair
I also agree with the fact that CGET is simpler from
an implementation point of view (programmers point of
view) but to the end user it doesn't make any difference
Also C-Move provides the functionality of CGet + more.
So if you implement CMove why bother to implement CGet.
Girish
Dave Harvey wrote:
David Clunie
Dave Harvey wrote:
> The particular experience I have of the usefulness of C-GET involves the
> writing DICOM gateways, such as a DICOM <-> http gateway. Using C-GET, this
> is quite straightforward, the incoming http request fires off a process
> which connects to the DICOM server, retrieves the image, converts to
> whatever and returns it to the requester, all in one nice sequential thread
> of execution.
>
> The alternative using C-MOVE is much more complex, requiring a second
> "listening" thread, the need for inter-thread communication and
> synchronisation mechanisms, and a means of identifying which incoming SOP
> instance belongs to which request. Whilst none of these problem are
> insurmountable, the level of complexity would preclude the simple but
> effective solutions possible using simple scripting http servers such as
> Microsoft's active server pages.
The reason for the popularity of the two association approach used
by C-Move is I think largely historical.
Imagine that you have aleady implemented devices that do C-Store.
You then add a Q/R capability ... implementing the C-Find or the
C-Move as an SCU is quite simple ... the C-Store SCP is already
there to receive the images that you are moving.
C-Get on the other hand requires the SCU to "turn around" the
association and get ready to receive images - a more complex
code and architectural change at both ends.
This is convenient in the "web client like" scenario that Dave
is describing, but extremely annoying for the background bulk
image transfers between modalities and archives that DICOM
was designed for. The high end workstations mostly evolved with
C-Store SCP functionality first (ie. they were "pushed" to)
and Q/R SCU was added later ... the ability to add studies and
images to the local browser as they are received was already in
place, so the simpler C-Move is a natural extension. The C-Get
has no advantage on this scenario.
For newcomers doing more single image queries and stateless transfers,
it may be unfortunate that most PACS and archives only support C-Move,
but I don't think this going to change in a hurry, so it makes
sense to implement C-Move everywhere for maximum interoperability.
david
Manabu Tokunaga
The DICOM standard PS 3.4 seems to define that the association must be kept
open until all the images have been sent. This applies to C-MOVE, as well
as C-GET DIMSE services. The reason why I interpret this way is because the
standard specifically indicates that the C-MOVE/GET SCP side must send RESP
DIMSE message each time an image is sent. By this definition, until all
images are successfully sent, you cannot bring down the association.
Furthermore, if the C-MOVE association was to cut out by the C-MOVE SCU,
the C-MOVE SCP shall not send any more images. This clearly won't be a
desirable behavior if someone needs to load a tape in response to a
C-MOVE/GET request, and the person is away for lunch or weekend. Also
implied in here is that, in the case of C-MOVE SCP, a coordination is
required between the C-STORE SCU that the C-MOVE SCP invokes -- every time
C-MOVE SCP requests C-STORE SCU to send image out, it has to also report
that through C-MOVE RESP to the C-MOVE SCU.
Some commercial DICOM implementations, therefore get around this problem by
defining an extra DIMSE C-MOVE response status indicating that "Operation
Pending". If you get this message, you can safely cut the C-MOVE
association, and expect that later on, a C-STORE will occur in completely
separate context from the C-MOVE.
The result of timing out on a C-MOVE association is, therefore, entirely
implementation dependent.
Manabu Tokunaga, DICOM Components Group, ACUSON Corporation (acuson.com)
Email: manabu
http://www.acuson.com
The opinions in this post may not necessarily reflect those of ACUSON
Corporation.
Todor Kantchev
Manabu Tokunaga wrote:
>
> The DICOM standard PS 3.4 seems to define that the association must be kept
> open until all the images have been sent. This applies to C-MOVE, as well
> as C-GET DIMSE services. The reason why I interpret this way is because the
> standard specifically indicates that the C-MOVE/GET SCP side must send RESP
> DIMSE message each time an image is sent. By this definition, until all
> images are successfully sent, you cannot bring down the association.
You can, but you are not allowed to!
> Furthermore, if the C-MOVE association was to cut out by the C-MOVE SCU,
> the C-MOVE SCP shall not send any more images.
It could still do, if it is implemented to do so. In fact that is what
some implementors do, and that is what I call unreliable and prone to
"misinteroperabilty" implementation.
>
>This clearly won't be a
> desirable behavior if someone needs to load a tape in response to a
> C-MOVE/GET request, and the person is away for lunch or weekend. Also
> implied in here is that, in the case of C-MOVE SCP, a coordination is
> required between the C-STORE SCU that the C-MOVE SCP invokes -- every time
> C-MOVE SCP requests C-STORE SCU to send image out, it has to also report
> that through C-MOVE RESP to the C-MOVE SCU.
>
> Some commercial DICOM implementations, therefore get around this problem by
> defining an extra DIMSE C-MOVE response status indicating that "Operation
> Pending". If you get this message, you can safely cut the C-MOVE
> association, and expect that later on, a C-STORE will occur in completely
> separate context from the C-MOVE.
Why do you think, that you can safely cut it? If the SCP is implemented
so, that it does not torelate nonstandard behaviour (and this IS a
nonstandard behaviour), then the result from the whole operation is
unpredictable.
>
> The result of timing out on a C-MOVE association is, therefore, entirely
> implementation dependent.
True, if you are doing DICOM-like implementation, but not if you are
doing a standard DICOM application.
>
> Manabu Tokunaga, DICOM Components Group, ACUSON Corporation (acuson.com)
> Email: manabu
> http://www.acuson.com
> The opinions in this post may not necessarily reflect those of ACUSON
> Corporation.
Tod.