Re: [Aeskulap-users] Extended Behaviour of SCU (was dicom issues)

[Mitchell Laks]

On 09:34 Fri 13 Apr     , Alexander Pipelka wrote:
> Mitchell,
> 
> I just rechecked the DICOM standard about SCU QR behaviour.
> 
> You are completely right with your statements when using the "Baseline
> Behaviour" (PS 3.4 C.4.1.2.1)
> 
> 
> But,...
> There's also an Exended Behaviour:
> 
> C.4.1.2.2  Extended Behavior of SCU
> Extended SCU behavior shall be negotiated at Association establishment
> time. If an option within the extended behavior is not agreed upon in
> the negotiation, then only baseline SCU behavior shall be performed with
> respect to that option. Extended SCU behavior includes all baseline
> behavior with the following option:
> 
>     — Relational-queries
> 
> 
> C.4.1.2.2.1     Relational-Queries
> The C-FIND Service with relational-queries allows any combination of
> keys at any level in the hierarchy. The Unique Key Attribute associated
> with the Query/Retrieve level shall be contained in the C-FIND request
> and may specify Single Value Matching, Universal Value Matching, or List
> of UID Matching. Support for relational-queries removes the baseline
> restriction that a Unique Key shall be specified for all levels above
> the Query/Retrieve level in the C-FIND request.
> 
> So from my point of view it's perfectly legal to use universal matching
> in the PatientRootQueryRetrieveInformationModel within the study level.
> I think i just missed to announce the extended behaviour on association
> negotiation. Anyways, there must be a fallback if the SCP refuses the
> extended behaviour.
> 
> Alex

I use latest CTN 306. I run archive_server and archive_agent. 

You are correct, if you negotiate it of course, which you did not :), and you 
may very well not succeed to in ctn. 
However while it is common to find some Q/R SCP that may support 'illegal' ie 
non
conforming queries which violate the strict hierarchial 
dicom query structure - that may be why no one may have told you this before- 
it is bad to do this (in my opinion) as it will fail on conforming SCP's.

As a first pass, make sure that you conform at the strict hierarchial level. 
Many people use wustl ctn because
of its incredible robustness. I am running ctn 306, which is the basis of the 
replies I sent to you...

If you are looking for help:

1. There is nothing wrong with doing secondary queries to get 
study/series/image info. 
2. Look what other SCU implementations do - 
 ie turn on ctn and then watch while you query using Osirix or Efilm or 
whatever ....
 you can match then their query :)
3. Take a look at Q/R approaches based upon Study Root model perhaps. 
4. Also, Look at the queries that Andreas Knopke has posted in the dcmtk forum 
list, which are pretty helpful. 

Also read this it might be helpful: I quote it in full: Read this from  
comp.protocols.dicom

http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/6d8ab1cf7d4e637c/c987fda0c86f673e?lnk=gst&q=relational+queries&rnum=1&hl=en#c987fda0c86f673e

quoted from google groups below:

        
                
Bill    
View profile
         More options Jun 27 2005, 6:22 pm
Newsgroups: comp.protocols.dicom
From: "Bill" <address@hidden>
Date: 27 Jun 2005 15:22:36 -0700
Local: Mon, Jun 27 2005 6:22 pm
Subject: Q/R Relational Queries
Reply to author | Forward | Print | Individual message | Show original | Report 
this message | Find messages by this author
How commonplace is it for Q/R SCPs to support the extended behavior of
Relational queries?

How commonplace is it for Q/R SCUs to support the extended behavior of
Relational queries?

Thank you.

bill

  Reply Reply to author Forward     Rate this post: Text for clearing space
                
                
                
        
                
address@hidden          
View profile
         More options Jun 28 2005, 8:51 am
Newsgroups: comp.protocols.dicom
From: address@hidden
Date: 28 Jun 2005 05:51:33 -0700
Local: Tues, Jun 28 2005 8:51 am
Subject: Re: Q/R Relational Queries
Reply to author | Forward | Print | Individual message | Show original | Report 
this message | Find messages by this author
It is relatively common for Q/R SCPs to support relational behavior in
the processing of C-Find queries invoked under negotiated hierarchical
query SOP Class associations - e.g. allowing Series Modality
(0008,0060) to be used as a match key when querying at the Study Level.

It is fairly rare for Q/R SCPs to support extended negotiation for
relational queries and formally acknowledging they are using relational
logic (and therefore acknowledging their application behavior is not in
compliance with the hierarchical query model requirements).

It is even rarer for Q/R SCUs to support relational query extended
negotiation, which makes the lack of support in SCPs somewhat
understandable.

Basically it comes down to the old aphorism about  marriage: "Why buy
the cow when you're getting the milk for free?".  Since many SCPs
already provide relational logic in what are supposed to be only
hierarchical queries (and SCUs use it), there is little motivation for
either one to implement additional negotiation logic to "enable"
relational queries. Conversely, there also aren't any DICOM police to
penalize the applications providing relational logic under what is
supposed to be limited to hierarchical query. Even if there were a
DICOM police, it is likely the citizentry wouldn't be happy if the
applications were suddenly forced to  start conforming to the
hierarchical query limitations and breaking some very commonly used
query patterns (i.e. queries  for study by modality and study level
proxy for body part); but if there were such enforcement, it would be a
motivator for application vendors to start using the relational model
as the DICOM gods intended.

In my experience, I've never seen relational query models negotiated
and used. In discussing the topic, an engineer from IDX told me their
system supports relational query negotiation.

  Reply Reply to author Forward     Rate this post: Text for clearing space
                
                
                
        
                
Bill    
View profile
         More options Jun 28 2005, 10:42 am
Newsgroups: comp.protocols.dicom
From: "Bill" <address@hidden>
Date: 28 Jun 2005 07:42:31 -0700
Local: Tues, Jun 28 2005 10:42 am
Subject: Re: Q/R Relational Queries
Reply to author | Forward | Print | Individual message | Show original | Report 
this message | Find messages by this author
For a real world case, should the SCP allow relational behavior without
supporting the extended negotiation?

If yes, this will allow the SCU to have attributes from any query level
in the C-Find-Rq dataset.  This basically ignores the restriction put
on by the hierarchical query model.  For the real world implementation,
is this correct?

Is it commonplace for SCUs to expect relational behavior from the SCP?

thank you
bill

  Reply Reply to author Forward     Rate this post: Text for clearing space
                
                
                
        
                
address@hidden          
View profile
         More options Jul 1 2005, 10:43 am
Newsgroups: comp.protocols.dicom
From: address@hidden
Date: 1 Jul 2005 07:43:50 -0700
Local: Fri, Jul 1 2005 10:43 am
Subject: Re: Q/R Relational Queries
Reply to author | Forward | Print | Individual message | Show original | Report 
this message | Find messages by this author
I won't go so far as recommending that you support relational behavior
without first negotiating it; however, I have made the observation that
many vendors do in fact provide some level of relational behavior in
their SCPs. Many did so based on on the need to provide functionality
that the original writers of the standard probably didn't realize they
were disabling with strict compliance to the standard.

Yes - relational query allows attributes from all level/all entities in
the query model to be specified as match keys in the query.

I think the expectations of SCUs (or applications which have an
underlying SCU are all over the place). Traditionally there has been a
pretty transparent flow through from the query parameters specified by
a user in a GUI to the DICOM query interface/results. So - the
"expectations" of the SCU have been the expectations of the end user,
rather than contraints of an automated program. Automated prefetch
algorithms have traditionally used a direct database query that allowed
them to perform relational logic without worrying about hierarchical
contraints the DICOM interface was supposed to be imposing.
There is greater interest now in intra-PACS querying in a discovery
mode and I believe there may be some PACS to PACS interfaces which do
utilize or depend on violations of the hierarchical query contraints.
There was some dicussion on the topic in this news group a year or two
back. You might search back through the archive to locate that
discussion for further information and contacts.

  Reply Reply to author Forward     Rate this post: Text for clearing space
                
                
                
        
                
Bill    
View profile
Eric, I like to thank you for all your insight.  It helped answer my questions. 
bill
         More options Jul 1 2005, 2:37 pm
Newsgroups: comp.protocols.dicom
From: "Bill" <address@hidden>
Date: 1 Jul 2005 11:37:53 -0700
Local: Fri, Jul 1 2005 2:37 pm
Subject: Re: Q/R Relational Queries
Reply to author | Forward | Print | Individual message | Show original | Report 
this message | Find messages by this author
Eric, I like to thank you for all your insight.  It helped answer my
questions.

bill




> 
> 
> 
> 
> _______________________________________________
> Aeskulap-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/aeskulap-users