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 conformance to the Storage SOP Classes as an SCP may be provided:
Level 0 (Local). Level 0 conformance indicates that a user-defined subset of the Attributes of the image will be stored, and all others will be discarded. This subset of the Attributes shall be defined in the Conformance Statement of the implementer.
Level 1 (Base). Level 1 conformance 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 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.
Level 2 (Full). Level 2 conformance 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 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 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, 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 Level 2 SCP.
An SCP that claims conformance to 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 Level 2 SCP.
Level 2 (Full) Storage SCP Conformance is required for support of the Enhanced Multi-Frame Image Conversion Extended Negotiation of the Query/Retrieve Service Class, since effective use of that option requires the storage of Type 3 Attributes. See Section C.3.5 New Instance Creation for Enhanced Multi-frame Image Conversion.
At any level of conformance, 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.
Table B.4-1. Attributes Subject to Coercion
|
Attribute |
Tag |
|---|---|
|
Patient ID |
(0010,0020) |
|
Study Instance UID |
(0020,000D) |
|
Series Instance UID |
(0020,000E) |
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 Coding Scheme Designator values "SNM3" to "SRT", 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 Level 2 (Full) storage support:
Signature Level 1. SCP may not preserve Digital Signatures and does not replace them.
Signature Level 2. SCP does not preserve the integrity of incoming Digital Signatures, but does validate the signatures of SOP Instances being stored, takes implementation-specific measures for insuring the integrity of data stored, and will add replacement Digital Signatures before sending SOP Instances elsewhere.
Signature Level 3. 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).
The SCU shall generate only C-STORE requests with SOP Instances that meet the requirements of the IOD associated with the SOP Class.
During Association Negotiation, an application may propose a specialized SOP Class and its related general SOP Class in separate Presentation Contexts as a Storage SCU. If the Association Acceptor rejects the specialized SOP Class Presentation Context, but accepts the related general SOP Class Presentation Context, the application may send instances of the specialized SOP Class as instances of the related general SOP Class. In this fall-back behavior, the SOP Class UID of the instance shall be the UID of the related general SOP Class, and any special semantics associated with the specialized SOP Class may be lost; the SOP Instance UID shall remain the same.
The SCU may include the SOP Class UID of the original intended specialized SOP Class in the Attribute Original Specialized SOP Class UID (0008,001B) of the instance sent under the related general SOP Class. In some cases, e.g., when all intermediate storage applications are Level 2 SCPs, this may allow an ultimate receiver of the instance to recast it as an instance of the specialized SOP Class IOD. However, this transformation is not guaranteed.
An implementation may conform to a SOP Class of the Storage Service Class as an SCU, SCP or both. The Conformance Statement shall be in the format defined in PS3.2.
The following issues shall be documented in the Conformance Statement of any implementation claiming conformance to the Storage SOP Class as an SCU:
The behavior of the SCU in the case of a successful C-STORE response status shall be described.
The behavior of the SCU in each case of an unsuccessful C-STORE response status shall be described.
The behavior of the SCU in the case of a Warning status received in response to a C-STORE operation.
Whether extended negotiation is supported.
The optional elements that may be included in Storage SOP Instances for each IOD supported shall be listed.
The standard and privately defined Functional Groups that may be included in Storage SOP Instances for each Multi-frame IOD that support Functional Groups.
The behavior of the SCU in the case of a C-STORE operation using a referenced pixel data transfer syntax such as JPIP Referenced Pixel Data Transfer Syntax shall be described. This includes the duration of validity of the reference
The following issues shall be documented in the Conformance Statement of any implementation claiming conformance to the Storage Service Class as an SCP:
The level of conformance, as defined by Section B.4.1, shall be stated.
The level of Digital Signature support, as defined by Section B.4.1, shall be stated.
The optional elements that will be discarded (if any) shall be listed for each IOD supported.
The Conformance Statement shall document the policies concerning the Attribute Lossy Image Compression (0028,2110).
The behavior of the SCP in the case of a successful C-STORE operation shall be described. This includes the following:
the access method for a stored SOP Instance
the duration of the storage
The meaning of each case of an unsuccessful C-STORE response status shall be described, as well as appropriate recovery action.
The meaning of each case of a warning C-STORE response status shall be described, as well as appropriate action.
If the SCP performs coercion on any Attributes, this shall be stated, and the conditions under which it may occur shall be described.
Implementations may provide Specialized SOP Class conformance by providing a proper superset of the SOP Instances to be stored. Implementations providing Specialized SOP Class Conformance to one of the SOP Classes defined in this Annex shall be conformant as described in the following sections and shall include within their Conformance Statement information as described in the following sections.
An implementation shall be permitted to conform as a Specialization of the standard SOP Class as an SCU, SCP or both. The Conformance Statement shall be in the format defined in PS3.2.
Any implementation that specializes the standard SOP Class shall define its specialization as an Allomorphic subclass of the standard SOP Class. As such, the specialization shall have its own unique SOP Class identification.
The Conformance Statement shall include a SOP Class Identification Statement as defined in PS3.2, declaring a SOP Name and SOP Class UID that identify the Specialized SOP Class. The SOP Name is not guaranteed to be unique (unless the implementer chooses to copyright it) but is provided for informal identification of the SOP Class. The SOP Class UID shall uniquely identify the Specialized SOP Class and conform to the DICOM UID requirements as specified in PS3.5.
The standard SOP Class may be specialized by supporting additional private Attributes. The SCU Operations Statement shall describe these specializations and be formatted as defined in PS3.2. Following this statement shall be the list of Attributes that may be sent or stored with SOP Instances.