Skip to content
Imaging Evidence Path

Conformance, acceptance, and custody

“DICOM compatible” sounds like a yes-or-no property until two systems attempt to exchange a derived object. One system may store CT but not Segmentation Storage; another may accept a segmentation without displaying it; two products may support the same object class but share no Transfer Syntax. The network can be reachable in all three cases while the intended workflow still fails.

Conformance is a capability matrix

DICOM support is better treated as a matrix of specific promises. For a given SOP Class, ask which system acts as SCU and which as SCP, which Transfer Syntaxes are proposed or accepted, and which options, levels of support, configuration requirements, and limitations are documented. A product implements a selected portion of the standard for its real-world activities; it does not automatically implement every optional component.

A DICOM Conformance Statement makes that selection inspectable. It normally describes the product’s Application Entities, Real-World Activities, SOP Classes, SCU/SCP roles, Transfer Syntaxes, extended negotiation, options, limitations, and configuration requirements such as AE Titles and ports. The document is a capability contract for comparison, not a certificate that an untested workflow will work. It can help a knowledgeable reader predict whether communication might be supported, while the actual products, configuration, and data still require an end-to-end test.

The comparison can be made mechanical. For each object and service required by the workflow, compare the sender’s SCU row with the receiver’s SCP row. Look for a shared SOP Class and at least one compatible Transfer Syntax, then read the options and limitations on both sides. An intersection is a prediction about a specific capability; it is not a guarantee for every object or viewer path.

Interoperability as a capability-matrix intersection, with two fictional systems A and B. Left panel: three pinned rows. Row 1 — A offers CT storage as SCU with syntaxes a,b, B accepts CT as SCP with syntax a; the rows intersect on a shared syntax, so transfer is predicted to work (✓). Row 2 — A sends SEG on syntax a and B accepts it as SCP, but B’s row carries a documented display limitation (DISP ✗): the object is accepted and archived yet never rendered (△). Row 3 — A offers SEG only on syntax c while B accepts only syntax a; the sets are disjoint, so no presentation context can be agreed (✗, INCOMPATIBLE). The dashed vertical line is the intersection the two statements must produce — a prediction, not a guarantee; only a real end-to-end test demonstrates it, for the tested workflow, configuration, and objects. Right panel — drawn generically, not as system B: a successful C-STORE (✓, acceptance now) is a different promise from Storage Commitment (COMMIT), which is requested with N-ACTION and reported later by N-EVENT-REPORT — responsibility for safekeeping, not the transport acknowledgement, and never an automatic consequence of the C-STORE. Syntax labels a/b/c and the two systems are synthetic teaching identifiers, not real vendors or encodings.

Three ways the matrix can fail

Consider three constructed cases. In the first, an archive declares CT and MR Storage but not Segmentation Storage. A C-STORE of a SEG fails because the receiver did not promise that SOP Class. Nothing about the network proves otherwise; the needed capability is absent.

In the second, the receiver accepts and archives Segmentation Storage but documents no display capability for the reading viewer. The object may be present and retrievable while the radiologist does not see a mask in the current reading context. Acceptance and display are different rows of the workflow.

In the third, both products implement the relevant SOP Class but propose and accept disjoint Transfer Syntaxes. TCP can connect and an association can be attempted, yet the presentation context for that object is rejected. The failure is in the encoding intersection, not necessarily in the network.

These cases explain why a product-level statement such as “supports DICOM” is too coarse for an integration decision. Inspect the cell that matters: object class, role, encoding, and documented limitations for the actual workflow.

Acceptance is not custody

The same separation is needed after a successful transfer. A successful C-STORE indicates that the information was stored in some medium and is accessible for some implementation-defined time frame. It does not, by itself, establish indefinite durability, availability to a future query, or rendering by a viewer.

Storage Commitment is a separate DICOM service for a different promise. In the Push Model, a requester asks for commitment for named SOP Instances using N-ACTION; the Storage Commitment SCP later reports committed and failed instances through N-EVENT-REPORT. The exchange is asynchronous and separate from the original C-STORE acknowledgement. The exact service behavior and any local policy still need to be checked against the applicable specification and implementation.

Keep three questions apart:

  1. Acceptance: did the receiving service accept the object now?
  2. Commitment: has the receiving service indicated responsibility for keeping and later retrieving the named instances under the Storage Commitment service?
  3. Availability: can the intended requester later find, retrieve, and use the object in the workflow?

Each answer can differ. An object can be accepted without a commitment request; a commitment indication can exist while a later query or routing path is broken; and an available object can still be unsupported by the viewer. This is a distributed systems pattern expressed through DICOM services: acknowledgement, responsibility, and usable availability are separate promises.

The distinction matters especially for derived results. If an AI service sends thousands of SEG or SR objects, the receiving system’s acceptance response does not by itself identify the later custodian or demonstrate that a reader can retrieve the results. The workflow needs explicit records for the promise it relies on. The next boundary is not transport or custody but confidentiality: preserving research utility while reducing the ways a released dataset can identify a person.

Adrian Tkacz, MD, MSc Computer ScienceAboutLinkedInORCIDXEmail

© 2026 Adrian Tkacz · BioMedical-IT
Original text and figures are licensed under the Creative Commons Attribution-NonCommercial 4.0 International License (CC BY-NC 4.0), unless otherwise noted. Please credit Adrian Tkacz / BioMedical-IT and link to the original source. Third-party materials retain their respective rights and licenses.