DICOM PS3.17 2022c - Explanatory Information

YYYY.3.6 Producer vs. Consumer Implementation

In all interoperability design, there is a tradeoff between ease of implementation for the producer of information versus the consumer of that information. By adding constraints on the message content to which the producer must adhere, the processing requirements for the receiver might be simplified. Fewer constraints on the producer means the consumer must account for more variability in the exchanged data.

In the design of the Inventory IOD, a policy was chosen to simplify the production of the SOP Instances, even at the risk of complicating the implementation of the consumer. The goal is to allow the producer of the inventory to simply report what it has, without substantial additional processing. For example, in a repository that might distribute the SOP Instances of a Study across multiple subsystems, each subsystem can report on the SOP Instances that it knows about, and there is no requirement for the producer of the combined Inventory to consolidate or reconcile those different records. For the migration and consolidation use case (see Section YYYY.5.1), the consumer of the inventory will typically need to perform substantial reconciliation activities, which do not need to be replicated in the producer.

This policy can also be seen in the approach to repository data that has been removed from operational use (deprecated, soft-deleted, or hidden). As DICOM has not established a standard approach to this type of data, storage system implementations take a variety of approaches. The Inventory IOD does not attempt to introduce a single way of managing such data. Rather, the repository system can simply report a removal status at the level(s) at which it manages that status, be it Study, Series, or Instance, with an optional reason code if it has one. If the removal was due to a directive in a Key Object Selection Document SOP Instance, e.g., in accordance with the [IHE RAD TF-1] IOCM Profile, the Inventory IOD makes no assumption about the presence or status of that KOS object; the system simply reports whether it is stored in the repository.

DICOM PS3.17 2022c - Explanatory Information