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

[Alexander Pipelka]

Hi Pablo,

Yes. I know.
I also know that the current behavior of Aeskulap isn't correct.
But to be honest, nowadays it's common use to accept relational queries
without extended association negotiation. It's *much* easier to use
relational queries. But hardly any PACS supports this in the correct way.

I know I did some mistakes in trying to make the SCU as simple (and
working with nearly any PACS solution) as possible.

After rethinking the whole thing I think the only way to continue would be:

- implement compliant baseline QR behavior
- use extended association negotiation and use the current QR mechanism
on compliant SCP's

As you all know I'm very limited with my resources for working on Aeskulap.
Any volunteers for helping me implementing this ?

Alex

PS: Thanks to Mitchell for bothering me on this ;-)

Pablo Sau schrieb:
> Hi Alexander :
>
> CTN is a premier of DICOM software and it means, as I suppose you
> already know, Central Test Node
> used during years at RSNA to check DICOM connectivity between
> different vendors, so if Aeskulap
> can't query & retrieve  from CTN, it not depends on a peculiarity  of
> CTN but  IMHO a bug in the
> query of Aeskulap.
> Months ago, 17 March  2006,  I pointed out this problem and sent to
> the aeskualp-users list
> verbose debugging information form CTN and Aeskulap sides.
>
> Best regards
> Pablo Sau
>
>
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> Aeskulap-users mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/aeskulap-users
>>
>>
>>
>>   
>
>
>
> _______________________________________________
> Aeskulap-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/aeskulap-users
>