Storage commitmentthe promise that the images are safe
A successful C-STORE only says the PACS received an image. Storage commitment is the separate, explicit promise that it keeps it. It uses two commands, a request and a notification, and the notification usually travels in the opposite direction on a new connection. This lesson walks through it in detail.
- DICOM
- Internal action
- Dashed = reply
Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.
The images are sent first
Core stepWhat happens
The Push Model is meant for senders that decide for themselves when the SOP Instances are transmitted. The SCU sends them by whatever suitable mechanism, normally C-STORE, and asks for commitment afterwards for a list of references to them.
Why it is needed
Commitment is a separate step from the store. A C-STORE status of 0000 means the instance was received and handled; only commitment is the promise to keep it safe.
Technical details
- Storage Commitment Push Model SOP Class 1.2.840.10008.1.20.1
- The images travel as in the C-STORE lesson
- SCU/SCP role selection negotiation is mandatory for this service class
- SOP Class extended negotiation shall not be supported
N-ACTION: ask for commitment
Core stepWhat happens
The modality sends an N-ACTION with Action Type ID 1. It gives a Transaction UID that identifies this request and a list of the instances by SOP Class UID and SOP Instance UID. An instance may appear in the list only once.
Why it is needed
The Transaction UID is how the SCU later matches the answer to the request, even when the answer arrives on a different association. The list is what the SCP promises to keep.
Technical details
- Requested SOP Class UID 1.2.840.10008.1.20.1
- Requested SOP Instance UID 1.2.840.10008.1.20.1.1 (the well-known instance; nothing is created)
- (0000,1008) ActionTypeID = 1 (request storage commitment)
- (0008,1195) TransactionUID, required
- (0008,1199) ReferencedSOPSequence: (0008,1150) SOP Class UID and (0008,1155) SOP Instance UID per instance
- Optional: Storage Media File-Set ID (0088,0130) and UID (0088,0140) when the instances come on media
N-ACTION-RSP: the request was received
ConfirmationWhat happens
The SCP answers at once. A success status means it received the request. Any other status means it will not process it, and so will not commit to the instances. If the status is a failure, the Transaction UID is no longer active and may not be reused.
Why it is needed
The real result comes later in a separate message. After this response the SCU may release the association at any time, and it often does.
Technical details
- No status values specific to the N-ACTION of this service class: the general PS3.7 codes apply
- (0000,0900) Status = 0000: received. Anything else: not processed
- Failure: the Transaction UID is dead and must not be used again
- The SCU may release the association any time after this response
The PACS commits to the instances
Key detailWhat happens
The SCP assesses the list. For the instances it commits to, it must store them with all their attributes, including private ones (Storage Level 2, Full). It may report straight away, or it may take longer, for example while it copies them elsewhere. It may also relay them to a third AE and say so in the report.
Why it is needed
The promise is only as good as this check. What "safe" means is the PACS's business: one copy on disk, two copies, a copy at another site. DICOM only defines the message that conveys it.
Technical details
- Instances it cannot commit to go into the failed list with a reason
- The report may name the AE they can be retrieved from: Retrieve AE Title (0008,0054)
- Media case: the request can fail if the medium has not been read yet
- Time to answer is not defined by the standard
N-EVENT-REPORT: the result
Core stepWhat happens
The SCP reports the result with the same Transaction UID as the request. It must be able to do this on a different association than the N-ACTION, and the SCU must be able to receive it there. It may try the same association first, but the SCU is free to release that at any time.
Why it is needed
This is the only place the real answer appears. If the modality cannot accept an inbound connection, from the PACS to its own AE title, IP address and port, the commitment result never arrives.
Technical details
- (0000,1002) EventTypeID = 1: commitment request successful. = 2: complete, failures exist
- (0008,1195) TransactionUID = the one from the N-ACTION
- Type 1: (0008,1199) ReferencedSOPSequence lists every instance
- Type 2: (0008,1198) FailedSOPSequence with (0008,1197) FailureReason for each failed instance, and the committed ones in ReferencedSOPSequence
- Every instance from the request appears in the report, as committed or as failed
- A new association: the SCP uses the same AE title as before, and the SCU accepts the SCP role the PACS proposes
- After the report the Transaction UID is no longer active
The modality answers the report
ConfirmationWhat happens
The SCU returns the response status to the N-EVENT-REPORT. What it does with the result is outside the standard and is stated in its Conformance Statement.
Why it is needed
The response closes the exchange from the PACS's side. The SCU's own follow-up, such as deleting local copies, is a separate decision.
Technical details
- (0000,0100) CommandField = 8100
- No status values specific to the N-EVENT-REPORT of this service class: the general PS3.7 codes apply
- The SCU's actions on receipt are described in its Conformance Statement
The modality deletes or resends
Key detailWhat happens
On event type 1 the modality knows every instance is committed and may remove its own copies, often after a configured time or when it needs the space. On event type 2 it knows exactly which instances failed and why, and it can send those again with a new request and a new Transaction UID.
Why it is needed
This is the purpose of the whole exchange: images are removed from the scanner only when the PACS has promised to keep them, and a failure never goes unnoticed.
Technical details
- FailureReason 0110: processing failure; 0112: no such object instance
- FailureReason 0119: class and instance conflict; 0122: referenced SOP Class not supported
- FailureReason 0131: duplicate Transaction UID; 0213: resource limitation
- Examples in the PS3.2 template: 0112 resend the instance and repeat the request; the others mark the request failed and warn before deleting
What if no result arrives?
Key detailWhat happens
DICOM defines no time limit for the report. The Conformance Statement template asks each vendor to describe what the product does when the report does not arrive in time, and gives the example of repeating the N-ACTION after a configurable time.
Why it is needed
The report is the weak spot of the exchange. It depends on the PACS being able to connect back to the modality, so a firewall or a wrong AE title shows up as commitments that never complete.
Technical details
- Check the modality's own port, AE title and IP address as configured on the PACS
- Check that the firewall allows the PACS to connect to the modality
- Compare the Transaction UID in the request and in any report you do receive
- A Transaction UID closed by a failure response or a report may not be reused
All steps at a glance
Glossary
- Storage commitment
- An explicit promise from a PACS that it has stored listed SOP Instances safely. It is stronger than a C-STORE success, which only means received.
- Push Model
- The storage commitment model in which the SCU decides when it sends the instances and then asks for commitment.
- Transaction UID
- A UID in the N-ACTION (0008,1195) that identifies one commitment request. The result carries the same one. It is used once.
- N-ACTION
- The DIMSE-N command that asks the peer to perform an action. Here it carries the request, with Action Type ID 1.
- N-EVENT-REPORT
- The DIMSE-N command that reports an event to the peer. Here it carries the commitment result from the PACS to the modality.
- Role selection
- A part of association negotiation in which an association requestor proposes to act as SCU, SCP or both for a SOP Class. It lets the PACS send the N-EVENT-REPORT on an association that it opened itself.
- Failure reason
- A code (0008,1197) per failed instance in a type 2 report, such as 0112 no such object instance or 0213 resource limitation.
Summary
- Storage commitment is two steps: an
N-ACTIONrequest from the sender, and anN-EVENT-REPORTresult from the PACS. AC-STOREsuccess is not commitment. - The request names the instances in
ReferencedSOPSequenceand carries a newTransaction UID. The result carries the same one, and it is used once. - The
N-ACTION-RSPonly says the request was received. Event type 1 is full success. Event type 2 lists the failed instances with aFailureReason. - The result can arrive on a different association, opened by the PACS. The modality must accept inbound connections and the PACS must know its AE title, IP address and port.
- What happens next (deleting, resending, timeouts) is not defined by the standard. It is in the sender's Conformance Statement.
The 8 steps in plain text
The images are sent first
The Push Model is meant for senders that decide for themselves when the SOP Instances are transmitted. The SCU sends them by whatever suitable mechanism, normally C-STORE, and asks for commitment afterwards for a list of references to them.
Why: Commitment is a separate step from the store. A C-STORE status of 0000 means the instance was received and handled; only commitment is the promise to keep it safe.
N-ACTION: ask for commitment
The modality sends an N-ACTION with Action Type ID 1. It gives a Transaction UID that identifies this request and a list of the instances by SOP Class UID and SOP Instance UID. An instance may appear in the list only once.
Why: The Transaction UID is how the SCU later matches the answer to the request, even when the answer arrives on a different association. The list is what the SCP promises to keep.
N-ACTION-RSP: the request was received
The SCP answers at once. A success status means it received the request. Any other status means it will not process it, and so will not commit to the instances. If the status is a failure, the Transaction UID is no longer active and may not be reused.
Why: The real result comes later in a separate message. After this response the SCU may release the association at any time, and it often does.
The PACS commits to the instances
The SCP assesses the list. For the instances it commits to, it must store them with all their attributes, including private ones (Storage Level 2, Full). It may report straight away, or it may take longer, for example while it copies them elsewhere. It may also relay them to a third AE and say so in the report.
Why: The promise is only as good as this check. What "safe" means is the PACS's business: one copy on disk, two copies, a copy at another site. DICOM only defines the message that conveys it.
N-EVENT-REPORT: the result
The SCP reports the result with the same Transaction UID as the request. It must be able to do this on a different association than the N-ACTION, and the SCU must be able to receive it there. It may try the same association first, but the SCU is free to release that at any time.
Why: This is the only place the real answer appears. If the modality cannot accept an inbound connection, from the PACS to its own AE title, IP address and port, the commitment result never arrives.
The modality answers the report
The SCU returns the response status to the N-EVENT-REPORT. What it does with the result is outside the standard and is stated in its Conformance Statement.
Why: The response closes the exchange from the PACS's side. The SCU's own follow-up, such as deleting local copies, is a separate decision.
The modality deletes or resends
On event type 1 the modality knows every instance is committed and may remove its own copies, often after a configured time or when it needs the space. On event type 2 it knows exactly which instances failed and why, and it can send those again with a new request and a new Transaction UID.
Why: This is the purpose of the whole exchange: images are removed from the scanner only when the PACS has promised to keep them, and a failure never goes unnoticed.
What if no result arrives?
DICOM defines no time limit for the report. The Conformance Statement template asks each vendor to describe what the product does when the report does not arrive in time, and gives the example of repeating the N-ACTION after a configurable time.
Why: The report is the weak spot of the exchange. It depends on the PACS being able to connect back to the modality, so a firewall or a wrong AE title shows up as commitments that never complete.
Common questions
What is the difference between a successful C-STORE and storage commitment?
A C-STORE status of 0000 means the receiver got the instance and handled it. Storage commitment is a separate request and a separate notification in which the PACS promises to keep the instances safely. A sender that wants to delete its own copy should wait for the commitment, not just the C-STORE response.
Why does the PACS connect back to the modality?
The N-EVENT-REPORT is sent by the PACS (the SCP), and the modality is free to release the association after the N-ACTION response. The PACS may try the same association, but normally it opens a new one to the modality as association requestor and proposes the SCP role through role selection. That is why the modality needs a listening port and must be configured on the PACS.
What is the Transaction UID for?
It identifies one commitment request. The sender generates it and the PACS returns the same value in the report, so the sender can match them even when they arrive on different associations. After a failure response or after the report, that Transaction UID is no longer active and may not be used for another request.
What do event types 1 and 2 mean?
Type 1, commitment request successful: the PACS commits to all the instances and lists them. Type 2, request complete with failures: the report lists the instances that failed, each with a failure reason, and the ones that were committed. In both cases every instance from the request appears in the report.
Does commitment mean the images are backed up?
It means the PACS promises to store them, with all their attributes. How safely is up to the product and its policy: one copy, two copies, another site. The report can also name another AE the instances can be retrieved from. DICOM defines the messages, not the storage policy.
What does a modality do when the commitment fails?
The standard does not say; it is in the modality's Conformance Statement. The PS3.2 template gives examples: resend an instance the PACS says does not exist, and warn the user before deleting instances that failed for other reasons.