2
votes

I planned to implement a Storage Commitment Service to verify if files previously sent to the storage were safely stored.

My architecture is very simple and straightforward my SCU sends some secondary capture images to the storage and I want to be sure they are safely stored before delete them.

I am going to adopt push model and I wonder what steps/features I need to implement to accomplish the service

What I understood is

  • I need to issue a N-ACTION request with SOP Class UID 1.2.840.10008.1.20.1 and add to the request a transaction identifier together with a list of Referenced SOP Class UID – Referenced SOP Instance UID where Referenced SOP Instance UID are the UIDs of the secondary capture images I previously sent to the storage and Referenced SOP Class UID in my case is the soap class identifier representing the Secondary Capture Image
  • Wait for my N-ACTION response to see if the N-ACTION request succeed or not
  • Get the response from the storage in form of N-EVENT-REPORT

    But when? How the storage give me back the N-EVENT-REPORT along with the results? Does my SCP AE implements some SCP features? Or I need to issue a N-EVENT request to get a N-EVENT-REPORT?

2

2 Answers

2
votes

Have a look at the image below copied from here: Image copied from Roni's Blog

Now, about your question, following is the explanation assuming same association will be used for entire communication. For communication over multiple associations, refer above article from Roni.

But when?

Immediately. On same connection/association. On receiving NAction response, you should wait for timeout configured in your application. Before timeout expires, you should get the NEventReport.

How the storage give me back the N-EVENT-REPORT along with the results?

When you receive NAction response from SCP, that means SCP saying "Ok; I understood what you want. Now wait while I fetch your data...". So, you wait. When SCP is ready with all the data (check list) necessary, it just sends it back on same association through NEventReport. You parse the Report and do your stuff and send response to SCP saying "Fine; I am done with you." and close the association.

Does my SCP AE implements some SCP features?

No (in most of the cases); you do not need to implement any SCP features in both (single association/multiple associations) cases. You should get NEventReport on same association as mentioned above. DICOM works on TCPIP. Client/Server concept in TCP is only limited to who establishes the connection and who listens for connections. Once the connection is established, any one can read/write data on socket.

In rare cases, SCP sends NEventReport by initiating new association on its own. In that case, SCU need to implement SCP features. This model is not in use as far as I am aware. It is difficult to implement this model for both SCP and SCU. It also needs multiple configurations which everyone tends to avoid. So, this could be neglected. I am calling this rare because I never (at least so far) come across such implementation. But yes; this is valid case for valid reason.

Or I need to issue a N-EVENT request to get a N-EVENT-REPORT?

No; as said above. Refer this.

J.3.3 Notifications
The DICOM AEs that claim conformance to this SOP Class as an SCP shall invoke the N-EVENT-REPORT request. The DICOM AEs that claim conformance to this SOP Class as an SCU shall be capable of receiving the N-EVENT-REPORT request.

That said, SCU should be able to process NEventReport. It will NOT issue it.

1
votes

There are three different sequences of events possible. I could describe them here, but this article is really excellent: Roni's DICOM blog

I have nothing to add to what is written there.