aeskulap-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexander Pipelka
Subject: [Aeskulap-users] Extended Behaviour of SCU (was dicom issues)
Date: Fri, 13 Apr 2007 09:34:40 +0200 (CEST)

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]