Storage Commitment after C-MOVE: clarification on SCU/SCP roles

[massimo consonni]

Dear DICOM Community,

I would like to confirm my understanding of a workflow scenario involving Query/Retrieve and Storage Commitment, specifically regarding role assignments and standard compliance.

Scenario:

• PACS B (as Query/Retrieve SCU) sends C-FIND and C-MOVE requests to PACS A (as Query/Retrieve SCP).

• PACS A transfers the requested images to PACS B using C-STORE sub-operations (as per PS3.4 C.4.2.3).

• After the transfer is complete, PACS A wants formal confirmation that PACS B has safely archived the transferred images.

Question:
Is it standard-compliant for PACS A to act as Storage Commitment SCU and send an N-ACTION-RQ to PACS B (acting as Storage Commitment SCP) to request Storage Commitment for the SOP Instances that were just transferred via C-MOVE/C-STORE?

My understanding:
According to PS3.4 Section J.3 (Storage Commitment Push Model), the Storage Commitment service is independent of the transfer mechanism (C-STORE, C-MOVE, etc.) and only requires the SCU to provide a list of SOP Instance UIDs to the SCP. The fact that PACS A initiated the transfer as a result of a C-MOVE request from B should not prevent A from subsequently requesting Storage Commitment from B for those instances, provided that:

• PACS A supports Storage Commitment as SCU

• PACS B supports Storage Commitment as SCP

• The Storage Commitment SOP Class is properly negotiated between the two systems

Context of my question:
I have encountered a statement suggesting that "Storage Commitment is typically requested after a C-STORE operation in a push model, and is not usually expected after a Query/Retrieve (pull model) operation." While I understand this describes common practice, I would like to confirm whether there is anything in the DICOM standard that would prohibit or discourage the scenario I described above.

Thank you in advance for your clarification.

Best regards,
Massimo Consonni

[Victor Derks]

Hi Massimo,

The DICOM Conformance Statement document of both systems normally define and explain how these systems use and react on storage commitment requests and reports.
The statement you encountered is indeed the common case: a system uses storage commitment to ensure another system takes up the responsiblity for the long-term storage of the images. 

In your proposed case it would technically be possible to use storage commitment after the C-STORE operation. But such an operation would only be needed when PACS A would also transfer the ownership of the images to PACS B. This could be for example a scenario if PACS A is a legacy system and is being replaced with PACS B.

 
The more typical scenario is that PACS B wants to retrieve the images and keep them only for a short period of time. In this case using storage commitment would probably work against the workflow: PACS B has the images, but reports failure in the storage commitment report as it only has stored them in a temporarily cache location. When PACS A receives the report with the failures it wil re-transmit the images and requests SC again....etc..etc.

But there may also a scenario in which SC requests are useful. Some PACS systems report always quickly "ok" after a C-STORE operation and a SC request is needed to actually confirm if the images were transfered successfully and to repeat the images that failed. If PACS B retrieves images during the night from PACS A, it may be useful to configure SC as a mechanism to auto-recover from storage failures (even if PACS B reported success). Again see the DICOM Conformance Statements \ manuals of both systems if this configuration makes sense and is actually helpful.

[massimo consonni]

Thank you for your reply.

M

--
You received this message because you are subscribed to the Google Groups "DICOM Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dicomforum+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dicomforum/ad001c7a-68b7-4968-9947-5547414e30a1n%40googlegroups.com.