C-STOREhow a scanner sends images to the PACS
C-STORE is the DICOM command that moves one image (one SOP instance) from sender to receiver. A CT scanner sends a study as hundreds of C-STOREs over one association, and the PACS confirms each one.
- DICOM
- Internal action
- Dashed = reply
Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.
A-ASSOCIATE-RQ with storage contexts
Core stepWhat happens
The modality opens the association (see the association lesson). It proposes one presentation context per SOP Class it will send, for instance CT Image Storage, each with the transfer syntaxes it can produce.
Why it is needed
The PACS must agree to receive that kind of image in that encoding before any pixel is sent.
Technical details
- Abstract syntax 1.2.840.10008.5.1.4.1.1.2 (CT Image Storage)
- Transfer syntax 1.2.840.10008.1.2.1 (Explicit VR Little Endian)
- Transfer syntax 1.2.840.10008.1.2.4.70 (JPEG Lossless)
- Calling AE = modality, Called AE = PACS storage AE
A-ASSOCIATE-AC: the PACS accepts
ConfirmationWhat happens
The PACS accepts the contexts it supports and picks one transfer syntax for each. A context it cannot handle is refused, and images of that type can then not be sent on this association.
Why it is needed
If the PACS accepts only some encodings, the modality has to send in an accepted one or compress or decompress first. A refusal here is the root cause of many "store failed" tickets.
Technical details
- Context result 0 = accepted, with the chosen transfer syntax
- Context result 3 = SOP Class not supported
- Context result 4 = no acceptable transfer syntax
C-STORE-RQ with the image
Core stepWhat happens
For each image, the modality sends a C-STORE-RQ command naming the SOP Class and the unique ID of this image, followed by the image itself: all DICOM attributes plus pixel data.
Why it is needed
C-STORE moves exactly one SOP instance. The UID in the command lets the PACS spot a duplicate before it reads the whole data set.
Technical details
- (0000,0002) AffectedSOPClassUID = 1.2.840.10008.5.1.4.1.1.2
- (0000,0100) CommandField = 0001
- (0000,1000) AffectedSOPInstanceUID
- (0000,0700) Priority: 0002 low, 0000 medium, 0001 high
- (0000,0800) CommandDataSetType: any value except 0101 means a data set follows
- Data set: patient, study, series, image attributes and (7FE0,0010) PixelData
The PACS validates and stores
Key detailWhat happens
The PACS checks the data set, writes the file to its archive and adds the study, series and image to its database. Many systems also apply rules here: patient ID merging, tag morphing, routing to other nodes.
Why it is needed
The PACS only answers "success" after it has handled the image. A failure here (disk full, invalid data, conflicting patient data) is reported back in the response status.
Technical details
- Match or create patient, study, series using the UIDs
- Duplicate SOPInstanceUID: ignore, overwrite or reject, per vendor setting
- Optional tag morphing or routing rules
C-STORE-RSP with a status
ConfirmationWhat happens
The PACS answers per image. The modality keeps the image until it sees success, and many modalities retry or queue on failure.
Why it is needed
This is the delivery confirmation at DICOM level for one image. It tells the modality it may free its copy only if the PACS also supports (and the workflow uses) storage commitment, see the worklist lesson.
Technical details
- (0000,0100) CommandField = 8001
- 0000 success
- Warning, stored but changed: B000 coercion of data elements, B006 elements discarded, B007 data set does not match SOP Class
- A7xx refused: out of resources
- A9xx error: data set does not match SOP Class; Cxxx error: cannot understand
- Some failure codes are implementation specific: an SCU must treat any code in a range as that failure
- 0122 SOP Class not supported, 0110 processing failure
Next images on the same association
Key detailWhat happens
A study with 800 images is 800 C-STORE exchanges, usually on one association (or a few in parallel). The modality increments the Message ID for each.
Why it is needed
Reusing the association saves a negotiation per image. Some senders open several associations at once to go faster, which is why PACS limit the number of simultaneous associations.
Technical details
- One C-STORE-RQ and one C-STORE-RSP per instance
- Message ID increments, SOPInstanceUID is unique per image
- Some senders run several associations in parallel
A-RELEASE
ConfirmationWhat happens
When the last response has arrived the modality releases the association.
Why it is needed
The PACS can now treat the study as received (many systems wait for a quiet period instead) and release the association slot.
Technical details
- A-RELEASE-RQ (0x05) / A-RELEASE-RP (0x06)
All steps at a glance
Glossary
- SCU
- Service Class User. The side that asks for a service, such as a scanner that wants to store images.
- SCP
- Service Class Provider. The side that provides the service, such as a PACS that stores images.
- SOP Class
- Service-Object Pair class. A UID naming one kind of object plus the service used on it, e.g. CT Image Storage (1.2.840.10008.5.1.4.1.1.2).
- Presentation context
- One SOP Class (abstract syntax) paired with the transfer syntaxes offered for it. Each gets an odd ID (1, 3, 5 ...).
- Transfer syntax
- How a data set is encoded on the wire: byte order, explicit or implicit VR, and the image compression.
- Status
- A 16-bit code in every DIMSE response (0000,0900). 0000 is success, FE00 is cancel, FF00 and FF01 are pending, 0001, Bxxx, 0107 and 0116 are warnings, and Axxx, Cxxx, 01xx and 02xx (the others) are failures.
- UID
- A globally unique identifier made of numbers and dots, used for SOP Classes, transfer syntaxes, studies, series and instances.
Summary
- C-STORE moves one SOP instance. A study is many C-STOREs, usually on one association.
- The modality is the Storage SCU. The PACS is the Storage SCP.
- Command Field
0001is C-STORE-RQ,8001is C-STORE-RSP. The image goes in the data set that follows the command. - Status
0000is success.Bxxxis a warning (stored, but changed).A7xx,A9xxandCxxxare failures. - A successful C-STORE-RSP means received, not necessarily safely archived. Storage commitment (N-ACTION / N-EVENT-REPORT) confirms that.
The 7 steps in plain text
A-ASSOCIATE-RQ with storage contexts
The modality opens the association (see the association lesson). It proposes one presentation context per SOP Class it will send, for instance CT Image Storage, each with the transfer syntaxes it can produce.
Why: The PACS must agree to receive that kind of image in that encoding before any pixel is sent.
A-ASSOCIATE-AC: the PACS accepts
The PACS accepts the contexts it supports and picks one transfer syntax for each. A context it cannot handle is refused, and images of that type can then not be sent on this association.
Why: If the PACS accepts only some encodings, the modality has to send in an accepted one or compress or decompress first. A refusal here is the root cause of many "store failed" tickets.
C-STORE-RQ with the image
For each image, the modality sends a C-STORE-RQ command naming the SOP Class and the unique ID of this image, followed by the image itself: all DICOM attributes plus pixel data.
Why: C-STORE moves exactly one SOP instance. The UID in the command lets the PACS spot a duplicate before it reads the whole data set.
The PACS validates and stores
The PACS checks the data set, writes the file to its archive and adds the study, series and image to its database. Many systems also apply rules here: patient ID merging, tag morphing, routing to other nodes.
Why: The PACS only answers "success" after it has handled the image. A failure here (disk full, invalid data, conflicting patient data) is reported back in the response status.
C-STORE-RSP with a status
The PACS answers per image. The modality keeps the image until it sees success, and many modalities retry or queue on failure.
Why: This is the delivery confirmation at DICOM level for one image. It tells the modality it may free its copy only if the PACS also supports (and the workflow uses) storage commitment, see the worklist lesson.
Next images on the same association
A study with 800 images is 800 C-STORE exchanges, usually on one association (or a few in parallel). The modality increments the Message ID for each.
Why: Reusing the association saves a negotiation per image. Some senders open several associations at once to go faster, which is why PACS limit the number of simultaneous associations.
A-RELEASE
When the last response has arrived the modality releases the association.
Why: The PACS can now treat the study as received (many systems wait for a quiet period instead) and release the association slot.
Common questions
What is a DICOM C-STORE?
A DIMSE-C service that sends one SOP instance (such as one CT image) from a Storage SCU to a Storage SCP. The request carries the SOP Class UID and SOP Instance UID in the command and the object in a data set; the response carries a status.
Why does my PACS refuse some images with "SOP Class not supported"?
The PACS did not accept a presentation context for that image type. Add the SOP Class to the PACS storage configuration, or check the conformance statement. Private or newer SOP Classes (for example certain enhanced multi-frame or vendor-specific objects) are common causes.
What is the difference between a warning (Bxxx) and a failure?
With a warning such as B000 the PACS stored the image but coerced or dropped some data. With a failure (A7xx, A9xx, Cxxx) the image was not stored. Warnings should be reviewed, since the stored data differs from what was sent.
Does C-STORE success mean the images are safely archived?
Not necessarily. It means the receiver accepted the image. To be certain it is committed to long-term storage, the sender can use the Storage Commitment Push Model SOP Class (1.2.840.10008.1.20.1) with N-ACTION and N-EVENT-REPORT.
Why are some images stored and others not?
Each C-STORE stands alone. If one image fails (invalid data, a conflicting patient identity, a refused SOP Class) the others on the association can still succeed. Look at the per-image status in the modality log.