If the SCP determines that it has successfully completed storage commitment for all the SOP Instances referenced by a Storage Commitment Request, the SCP shall issue an N-EVENT-REPORT with the Event Type ID set to 1 (storage commitment request successful). This event shall include references to the successfully stored SOP Instances. The SCP shall store the referenced SOP Instances in accordance with Level 2 as defined in the Storage Service Class (i.e. all Attributes, including Private Attributes). The Storage Service Class is defined in PS 3.4. After the N-EVENT-REPORT has been sent, the Transaction UID is no longer active and shall not be reused for other transactions.
If it is determined that storage commitment could not be achieved for one or more referenced SOP Instances, the SCP shall issue an N-EVENT-REPORT with the Event Type ID set to 2 (storage commitment request complete - failure exists) conveying that the SCP does not commit to store all SOP Instances. This event shall include references to the failed SOP Instances together with references to those SOP Instances which have been successfully stored. For each failed SOP Instance the reason for failure shall be described by the Failure Reason Attribute. After the N-EVENT-REPORT has been sent, the Transaction UID is no longer active and shall not be reused for other transactions.
The complete set of SOP Instances referenced by the Referenced SOP Sequence (0008,1150) Attribute, in the initiating N-ACTION, shall be present in both Event Types.
The N-EVENT-REPORT shall include the same Transaction UID Attribute (0008,1195) value as contained in the initiating N-ACTION.
An SCP shall be capable of issuing the N-EVENT-REPORT on a different association than the one on which the N-ACTION operation was performed.
Notes: 1. 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 negotiation (see PS 3.7).
2. When responding on a different Association, the SCP must use the same AE Title as it used on the original Association, because the DICOM Standard defines a Service between two peer applications, each identified by an AE Title. Thus the SCP should be consistently identified for all Associations in the particular instance of the Storage Commitment Service.
3. The optional Attributes Retrieve AE Title (0008,0054), Storage Media File-Set ID (0088,0130) and Storage Media File-Set UID (0088,0140) within the Event Information allows an SCP to indicate the location where it has stored SOP Instances for safekeeping. For example, the SCP could relay SOP Instances to a third Application Entity using this Service Class. In which case it can use the Retrieve AE Title Attribute to indicate the real location of the data. Another example is if the SCP stores data on media, it can indicate this using the Storage Media File-Set ID and UID Attributes.