J Storage Commitment Service Class (Normative)

The mechanism currently defined in DICOM for network based storage of SOP Instances, the Storage Service Class, allows a Service Class User (SCU) to transmit images and other Composite SOP Instances to a Service Class Provider (SCP). However, the Storage Service Class does not specify that the SCP explicitly take responsibility for the safekeeping of data into account. That is, there is no commitment that the SCP will do more than accept the transmitted SOP Instances. In order to have medical image management in addition to medical image communication, there is a need for a Service Class within DICOM that ensures that there is an explicitly defined commitment to store the SOP Instances.

The Storage Commitment Service Class defines an application-level class-of-service that facilitates this commitment to storage. The Storage Commitment Service Class enables an Application Entity (AE) acting as an SCU to request another Application Entity (AE) acting as an SCP to make the commitment for the safekeeping of the SOP Instances (i.e., that the SOP Instances will be kept for an implementation specific period of time and can be retrieved). The AE where such SOP Instances can later be retrieved may be the SCP where storage commitment was accepted or it may be distinct from that SCP.

The SCP implementation defines how it provides its commitment to storage. Certain SCPs may commit to permanently store the SOP Instances (e.g., an archive system) while other SCPs may commit to provide storage of the SOP Instances for a limited amount of time. The SCP is required to document in its Conformance Statement the nature of its commitment to storage (e.g., duration of storage, retrieve capabilities and latency, capacity).

The possession of a link to access pixel data shall not be sufficient for the SCP to commit to storage. A copy of the entire pixel data is required.

Once the SCP has committed to store the SOP Instances, the SCU may decide that it is appropriate to delete its copies of the SOP Instances. These types of behaviors are outside the scope of this Standard, however, the SCU is required to document these behaviors in its Conformance Statement.

The request for storage commitment can be accomplished using the Push Model.

The Push model expects an SCU to transmit SOP Instances to an SCP using an appropriate mechanism outside the scope of this Service Class. Storage commitment is then initiated by transmitting a Storage Commitment Request containing references to a set of one or more SOP Instances. Success or failure of storage commitment is subsequently indicated via a notification from the SCP to the SCU.