Instance Availability Notification (IAN), 2 questions
Victor Derks
In this SOP class the SCU can send N-CREATE messages to SCPs to
indicate that instances are available. The SCP can respond with any
status code from PS3.7
Question 1
Annex R does not document what the SCU should do when it receives a
status code from the SCP other then SUCCESS.
Should it for example retry to send the N-CREATE message at a later
time or drop the message?
Should the Standard require that both the SCP and the SCU should
document their behavior for such cases in their Conformance Statement?
Question 2
Annex R does not define if the SCU or the SCP should set the Affected
SOP instance UID (0000, 1000). PS 3.7, section 10.1.5.1.4 documents
the general pattern that should be used in that case.
Should the IAN sop class also not define a ‘well-known sop instance
UID’ that can be used for this purpose?
gunter zeilinger
> The IAN SOP class is defined in PS 3.4, Annex R
>
> In this SOP class the SCU can send N-CREATE messages to SCPs to
> indicate that instances are available. The SCP can respond with any
> status code from PS3.7
>
> Question 1
> Annex R does not document what the SCU should do when it receives a
> status code from the SCP other then SUCCESS.
> Should it for example retry to send the N-CREATE message at a later
> time or drop the message?
> Should the Standard require that both the SCP and the SCU should
> document their behavior for such cases in their Conformance Statement?
>
I see no need to define a specific behavior for the SCP if the
notification fails by DICOM. Such profiling of DICOM services may be
better delegated to the IHE RAD Technical framework. I also don't
think, that an explicit note, that the behavior has to be described in
the DCS, will improve the quality of DCS provided by vendors. But, it
would also not harm :)
> Question 2
> Annex R does not define if the SCU or the SCP should set the Affected
> SOP instance UID (0000, 1000). PS 3.7, section 10.1.5.1.4 documents
> the general pattern that should be used in that case.
> Should the IAN sop class also not define a ‘well-known sop instance
> UID’ that can be used for this purpose?
Different notifications must have different Affected SOP instance
UIDs! A SCP may only use the same SOP Instance UID for the retry of
previous failed Notifications - but it may also use a different one
for each retry.
Victor Derks
Thanks for the feedback, I think I didn’t explain question 2 clearly
enough.
> Different notifications must have different Affected SOP instance
> UIDs! A SCP may only use the same SOP Instance UID for the retry of
> previous failed Notifications - but it may also use a different one
> for each retry.
The IAN sender (SCU according to Annex R) can omit the Affected SOP
instance UID (0000, 1000) parameter in the N-CREATE request. The IAN
receiver (SCP) is then forced to create a UID and return it as (0000,
1000) in the N-CREATE response.
This is the general N-CREATE pattern; the SCP receives the N-CREATE
request, creates ‘something’ and returns the UID of this ‘something’
to the SCU for future reference and operations. As the IAN sender
doesn’t care about this UID in the N-CREATE response I would say that
Annex R needs to define that the IAN sender must add the (0000, 1000)
parameter in the N-CREATE request.
If the IAN sender is then required to do this, then the question
becomes what the IAN receiver will do with this (0000, 1000) UID? The
interesting UID in an IAN message is actually the Study Instance UID
(0020, 000D). And if there is no use case for (0000, 1000) I would say
that using a predefined UID value makes more sense that creating UIDs
that are thrown away.
gunter zeilinger
I would agree, if the IAN SOP Class would use the N-EVENT-REPORT or
the N-ACTION service. But according my understanding, there should not
be two N-CREATE RQ using the same value as Affected SOP Instance UID -
if so, the second should be rejected by the SCP with Error Status
0111H - Duplicate SOP instance.