Implementations claiming Standard SOP Class Conformance to the Media Creation Management SOP Class shall be conformant as described in this Section and shall include within their Conformance Statement information as described in this Section and sub-Sections.
An implementation may claim conformance to this SOP Class as an SCU, SCP or both. The Conformance Statement shall be in the format defined in PS3.2.
An implementation that is conformant to this SOP Class as an SCU shall meet conformance requirements for
the operations and actions that it invokes
The mechanisms used by the SCU to transfer SOP Instances to the SCP using the Storage Service Class prior to initiating a request operation shall also be documented, and in particular the Transfer Syntaxes that may be proposed.
The SCU shall document in the Conformance Statement the actions and behavior that cause the SCU to generate an N-CREATE primitive (Create Media Creation Request), an N-ACTION primitive (Initiate Media Creation and Cancel Media Creation) or an N-GET primitive (Get Media Creation Result).
The SCU shall specify the SOP Class UIDs for which it may request media creation.
The SCU shall specify the Media Application Profiles for which it may request media creation.
The SCU shall specify if it supports the optional Storage Media File-Set ID & UID Attributes in the N-CREATE.
The SCU shall specify if it supports the optional Icon Image Sequence Attributes in the N-CREATE.
The SCU shall describe its use of expanded or replacement character sets, both in the N-CREATE, the N-GET and in its use of the Storage Service Class for composite instances.
The SCU shall specify whether or not it retries failed requests.
This allows the reader of a Conformance Statement to determine whether or not human intervention will be needed in the event of transient failures, or whether the SCU may be able to recover automatically.
The Conformance Statement shall be formatted as defined in PS3.2
An implementation that is conformant to this SOP Class as an SCP shall meet conformance requirements for
the operations and actions that it performs
The Storage Service Class mechanisms accepted by the SCP prior to receiving a request operation shall also be documented, and in particular the Transfer Syntaxes that may be accepted.
The SCP shall document in the Conformance Statement the behavior and actions of the SCP upon receiving the N-CREATE primitive (Create Media Creation Request), N-ACTION primitive (Initiate Media Creation and Cancel Media Creation) or the N-GET primitive (Get Media Creation Result).
The SCP shall specify the SOP Class UIDs for which it will accept media creation requests.
The SCP shall specify the Media Application Profiles for which it will accept media creation requests, and what default profiles it will use in the event that they are not specified by the SCU.
The forms of media that can be created are implicit in the list of Media Application Profiles supported, each of which is media-specific.
The SCP shall specify whether or not it supports creation of optional Icon Image Sequence Attributes in the DICOMDIR if none are supplied by the SCU.
The SCP shall specify the manner of use of label information, and in particular which:
Attributes are extracted from the Composite Instances when so instructed
barcode symbologies - if any - are supported
The SCP shall describe its use of expanded or replacement character sets, both in the N-CREATE, the N-GET and in its extraction of information from the Composite Instances for incorporation in the DICOMDIR and on the media label. The SCP shall describe its use of the Attributes both in the N-CREATE, and N-ACTION and the Composite Instances to create the media label.
The SCP shall specify if and how it supports the following optional Attributes in the N-CREATE and N-ACTION :
Storage Media File-Set ID (0088,0130) & Storage Media File-Set UID (0088,0140)
Media Disposition (2200,0004)
Priority (2000,0020)
Preserve Composite Instances After Media Creation (2200,000A)
The SCP shall specify the duration of persistence of received Composite Instances after a request has been processed successfully or unsuccessfully.
The SCP shall specify how long it will maintain:
the result of the creation of media after the request has succeeded or failed
the Media Creation Management Instances whose status is IDLE.
The SCP shall specify the action taken when a permanent failure (e.g., a media writing failure) or a transient failure (e.g., no empty media available) occurs, and their relationship with the media creation request status transaction.
For example, how many times the SCP will retry writing a new piece of media before setting the Execution Status (2100,0020) to FAILURE, how many media creation requests the SCP is able to queue, the SCP behavior when the request queue, if any, is full.
The SCP shall specify if it is able to split a media creation request over more than one piece of media, if the file-set doesn't fit on one.
The SCP shall specify if it is able to add to the created media Non-DICOM objects (e.g., html files, JPEG images), how these objects are organized, and how it interprets the Include Non-DICOM Objects (2200,0008) Attribute.
The SCP shall specify if it is able to add to the created media DICOM display applications, and how it interprets the Include Display Application (2200,0009) Attribute.
The Conformance Statement shall be formatted as defined in PS3.2.