| DICOM PS3.4 2024c - Service Class Specifications |
|---|
An implementation that conforms to Storage SOP Classes shall meet the:
C-STORE Service requirements as defined in Section B.2
Association requirements as defined in Section B.3
No SCU or SCP behavior requirements other than those in this section are specified. In particular, an SCP of the Storage SOP Classes may not attach any significance to the particular association or associations over which C-STORE operations are requested, nor the order in which C-STORE operations occur within an association. No constraints are placed on the operations an SCU may perform during any particular association, other than those defined during association negotiation. An SCP may not expect an SCU to perform C-STORE operations in a particular order.
Similarly, no semantics are attached to the closing of an Association, such as the end of a Study or Performed Procedure Step.
Three Levels of Storage Support are defined for an SCP that claims conformance to the Storage SOP Classes:
Storage Level 0 (Local) indicates that a user-defined subset of the Attributes of the SOP Instance will be stored, and all others will be discarded. This subset of the Attributes shall be defined in the Conformance Statement of the implementer.
Storage Level 1 (Base) indicates that all Type 1 and 2 Attributes defined in the IOD associated with the SOP Class will be stored, and may be accessed. All other Data Elements may be discarded. The SCP may, but is not required to validate that the Attributes of the SOP Instance meets the requirements of the IOD.
Storage Level 2 (Full) indicates that all Type 1, Type 2, and Type 3 Attributes defined in the Information Object Definition associated with the SOP Class, as well as any Standard Extended Attributes (including Private Attributes) included in the SOP Instance, will be stored and may be accessed. The SCP may, but is not required to validate that the Attributes of the SOP Instance meet the requirements of the IOD.
A Storage Level 2 SCP may discard (not store) Type 3 Attributes that are empty (zero length and no Value), since the meaning of an empty Type 3 Attribute is the same as absence of the Attribute. See PS3.5 definition of "Type 3 Optional Data Elements".
An SCP that claims conformance to Storage Level 2 (Full) support of the Storage Service Class may accept any Presentation Context negotiation of a SOP Class that specifies the Storage Service Class during the SOP Class Common Extended Negotiation (see Section B.3.1.3), without asserting conformance to that SOP Class in its Conformance Statement.
The SCP may support storage of all SOP Classes of the Storage Service Class, preserving all Attributes as a Storage Level 2 SCP.
This Extended Negotiation allows an SCP to determine that a Private SOP Class in a proposed Presentation Context follows the semantics of the Storage Service Class, and may be handled accordingly.
An SCP that claims conformance to Storage Level 2 (Full) support of a Related General SOP Class may accept any Presentation Context negotiation of a SOP Class that specifies that Related General SOP Class during the SOP Class Common Extended Negotiation, without asserting conformance to that Specialized SOP Class in its Conformance Statement.
The term "specialized" in this section is used generically, including both Implementation-defined Specialized SOP Classes and Standard SOP Classes specified in Table B.3-3.
The SCP may handle instances of such Specialized SOP Classes using the semantics of the Related General SOP Class, but preserving all additional (potentially Type 1 or 2) Attributes as a Storage Level 2 SCP.
An SCP that has access to the current content of Table B.5-1 might use that to determine acceptance of proposed Presentation Context SOP Classes. This allows an SCP, even without Extended Negotiation, to be able to identify all Standard SOP Classes of the Storage Service Class. Access to Table B.5-1 may be through private means, or to the publication of PS3 on the web site of the DICOM Standards Committee. This provides an automated alternative to manually editing a table of supported Storage SOP Classes.
At any Level of Storage Support, the SCP of the Storage Service Class may modify the Values of certain Attributes in order to coerce the SOP Instance into the Query Model of the SCP. The Attributes that may be modified are shown in Table B.4-1.
The SCP of the Storage Service Class may modify the Values of Code Sequence Attributes to convert from one coding scheme into another. This includes changing from deprecated Values of Coding Scheme Designator (0008,0102) or Code Value (0008,0100) to currently valid Values.
If an SCP performs such a modification, it shall return a C-STORE response with a status of Warning.
Modification of these Attributes may be necessary if the SCP is also an SCP of a Query/Retrieve SOP Classes. These SOP Classes are described in this Standard. For example, an MR scanner may be implemented to generate Study Instance UIDs for images generated on the MR. When these images are sent to an archive that is HIS/RIS aware, it may choose to change the UID of the study assigned to the study by the PACS. The mechanism by which it performs this coercion is implementation dependent.
An SCP may, for instance, convert retired Code Values with a Coding Scheme Designator Value of "99SDM", "SNM3" or "SRT" to the corresponding SCT Code Values and use the "SCT" Coding Scheme Designator, in accordance with the DICOM conventions for SNOMED (see PS3.16).
Modification of Attributes that may be used to reference a SOP Instance by another SOP Instance (such as Study Instance UID and Series Instance UID Attributes) will make that reference invalid. Modification of these Attributes is strongly discouraged.
Other Attributes may be modified/corrected by an SCP of a Storage SOP Class.
Modification of Attributes may affect digital signatures referencing the content of the SOP Instance.
Three levels of Digital Signature Support are defined for an SCP that claims conformance to Storage Level 2 (Full):
At Signature Level 1, the SCP may not preserve Digital Signatures and does not replace them.
At Signature Level 2, the SCP does not preserve the integrity of incoming Digital Signatures, but does validate the Digital Signatures of SOP Instances being stored, takes implementation-specific measures for ensuring the integrity of data stored, and will add replacement Digital Signatures before sending SOP Instances elsewhere.
At Signature Level 3, the SCP does preserve the integrity of incoming Digital Signatures (i.e., is bit-preserving and stores and retrieves all Attributes regardless of whether they are defined in the IOD).
| DICOM PS3.4 2024c - Service Class Specifications |
|---|