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

[Pablo Sau]

Thanks Alexander for your attention, I'll setup  a CTN server for you 
and sent you  all the debugging info,
I'll send you a private email with the IP port and AE Title, but you 
must tell me you IP, port and AE to grant
your access to CTN server.
Best regards
Pablo
> 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
> >
> >     
>
>
>
> _______________________________________________
> Aeskulap-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/aeskulap-users
>
>
>
>