| DICOM PS3.4 2024e - Service Class Specifications |
|---|
The Media Creation Management Service Class defines a mechanism by which an SCU can instruct a device to create Interchange Media containing a set of Composite SOP Instances that have already been transferred to the media creation device using the Storage Service Class.
This Service Class does not address archival storage requirements. It is intended only for the management of media creation devices. There is no requirement by the Standard that an SCP of this Service Class will commit to taking responsibility for archival of Composite Instances, such that an SCU may then discard them. Such behavior is entirely outside the scope of the Standard. In other words, Media Creation does not imply Storage Commitment.
The application profile(s) for the set of instances, which implies the form of the media created (i.e., CD, DVD or MOD), can either be left to the discretion of the SCP, or explicitly specified in the media creation request. In the latter case, if the device is unable to create the requested profiles, an error shall be returned.
More than one profile may be requested or used by default, since the requested set of instances may not be compatible with a single profile. DICOM media may always contain instances written by more than one profile. See PS3.2.
It is the responsibility of the SCU to negotiate and store instances with an appropriate Transfer Syntax should a specific Transfer Syntax be required by a requested profile. The SCP is not required to support compression or decompression of stored instances in order to convert stored instances into a form suitable for a requested profile. It may do so, if so requested, but the level of lossy compression would be at the discretion of the SCP. If the degree of compression is important to the application, then the SCU may compress the images before sending them to the SCP.
The request controls whether or not a label is to be generated on the media, be it from information contained in the instances (such as patient demographics) or from text explicitly specified in the request.
An SCP may or may not be physically capable of labeling the media. This capability is outside the scope of conformance to the Standard. Inability to create a label is not an error.
De-identification of instances (and labels), such as for teaching file media or clinical trial media is the responsibility of the SCU and is outside the scope of this service. That is, the SCU must de-identify the composite instances before sending them, prior to the media creation request.
The Service Class contains a limited capability to return status information. A media creation request may initially either fail or be accepted. Subsequently, the SCP may be polled as to the status of the request (idle, pending/creating, successful or failed) by the SCU on the same or on a separate Association. There is no asynchronous notification. There is no dependence on the duration or persistence of an Association.
| DICOM PS3.4 2024e - Service Class Specifications |
|---|