Each defined SOP Class is a separate DICOM Conformance claim for an implementation. Generally, an implementation may implement any of the Inventory-related services without implementing others.

Thus, a producer of Inventory SOP Instances may choose any method for exchange of Inventory instances. It could support DIMSE Inventory STORE (with or without Inventory MOVE or Inventory GET), DICOM Web Service Retrieve, or DICOM Media exchange, and may additionally support a non-DICOM file access protocol. However, as all DICOM Conformance is to SOP Classes, an implementation cannot claim DICOM Conformance just to the Inventory IOD; it needs to claim conformance to at least one SOP Class that exchanges the Inventory SOP Instances. Note, however, that a producer that supports the Inventory Creation SOP Class must also support one or more of Inventory MOVE, Inventory GET, or DICOM Web Service Retrieve (see Section KK.2.3.1.1 “Inventory Terminated With Instances” in PS3.4).

Identification and location of Inventory instances may be supported by the Inventory FIND SOP Class or the equivalent DICOM Web Service Search Transaction, or may be done by non-DICOM means (e.g., email notification of Inventory UIDs or filenames to a client). Similarly, an application may produce Inventories under control of its local administrative user interface, and is not required to implement the Inventory Creation SOP Class for remote clients. However, if the producer does implement the Inventory Creation SOP Class, it must also implement a DICOM method for accessing the produced Inventory instances.

Figure YYYY.4-1 illustrates the relationships of the Inventory SOP Instance-related services to the Information Object Definitions.