Storage Commitment N-Event-Report

[Ashutosh Dhar]

Hello,

I am trying to define future behavior of a cardiology modality and
have the following questions regarding Storage Commitment:

Is the modality "required" to be able to accept the N-Event-Report in
a different association as well as in the same association as the N-
Action-RQ?
or can the modality be DICOM and IHE card compliant, by supporting N-
Event-Reports ONLY in a Separate association.

By "required", I mean from DICOM standards point of view and from the
IHE Cardiology workflow point of view.

Let me summarize my current understanding here from reading the DICOM
standard and IHE specifications:

In the DICOM 2003 Part IV this is the relevant stated text (if there
are other references please let me know):

===
section J.3.3.1.2 Service Class Provider Behavior, specifically the
following note:
The SCP may attempt to issue the N-EVENT-REPORT on the same
Association, but this
operation may fail because the SCU is free to release at any time the
Association on which it
sent the N-ACTION-Request. As DICOM defaults the association requestor
to the SCU role,
the SCP (i.e. the association requester) negotiates an SCP role using
the SCU/SCP role
===

I interpret the standard as stating here that the modality should be
able to receive the N-Event-Report in the same association as well as
in a different association. Is my understanding correct?
Will a modality be DICOM compliant even if it supports N-Event-Reports
ONLY in a Separate association?

and IHE Card Vol 2 Section 4.3.1
===
The modality opening an Association (message channel) for Storage
Commitment shall serve as a trigger for the Image Manager to open a
separate Association to the
Modality to send the queued N-Event Report messages. This option is
required for the Cath
Workflow and Echo Workflow Profiles.
===
I interpret the IHE spec as saying that the modality can be IHE card
compliant even if it supports N-Event-Reports ONLY in a Separate
association. Is my understanding correct? It almost seems like the IHE
Card is relaxing what DICOM has specified or was it not the intent
here?

However the IHE Scheduled Workflow Profile is even more restrictive in
stating that the modality should be supporting both the use cases
(same as well as different associations).

I am quite convinced that as a modality we need to be able to support
both the use cases but I would request the experts here to validate
(or refute!) my conviction.

thanks,
Ashutosh

[Ashutosh Dhar]

I just re-read the quote from the IHE card spec and that is applicable
only for the Image Managers who support Intermittently connected
Modality option (Mandatory for Echo Workflow profile). Thus a modality
needs to conform to RAD10 to be compliant with IHE Echo workflow
profile.

So I think for a modality to be compliant to IHE Echo Workflow profile
needs to support Both same association and different association use
case (as stated in RAD10).

====

[Harry Solomon]

Once a modality and an image manager open an Association for the
Storage Commitment Service, that Association becomes available for all
valid Storage Commitment messages initiated by either the SCU or the
SCP. However, control of keeping the Association open or closing it
resides with the party that initiated the Association.

As noted in the DICOM Standard, the modality does not need to respond
to N-EVENT-REPORT on the same Association as the N-ACTION request; it
can close the Association at any time, including after receipt of the
N-EVENT-REPORT-RQ from the SCP, without sending an N-EVENT-REPORT-
RSP. So an SCU may be perfectly DICOM compliant if it only accepts N-
EVENT-REPORT on a different Association.

IHE RAD-10 adds no additional requirements on the SCU; in particular,
it does NOT specify that the SCU must accept N-EVENT-REPORT on the
same Association as the N-ACTION request.

That said, it is good practice for an SCU to accept N-EVENT-REPORT on
the same Association. But if the software architecture is such that it
cannot handle that effectively, there is no reason to jump through
hoops to implement it.

- Harry Solomon

[Ashutosh Dhar]

Hi Harry,

Thanks for your response. This discussion has me confused since David
Clunie clearly states here:

http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/2a7c103b226862a5/2ca65f1a10cb55e9?lnk=gst&q=Storage+commitment+association+negotiation#2ca65f1a10cb55e9

that the modality needs to handle both the scenarios. Not sure though
if he is talking from an ideal workflow (good practice) point of view
or DICOM standards compliance?

Ashutosh

====