DICOM Conformance Statement

Defines the identity and configuration of each DICOM network interface. This section specifies the Application Entity Title (AET), which is the unique name used to address the device on the network. It details the role the device plays in an association, whether it acts as a Service Class User (SCU) to initiate operations, a Service Class Provider (SCP) to respond to them, or both. The specification also lists the maximum number of simultaneous associations the entity can manage, which is critical for sizing network infrastructure and preventing connection refusals in high-throughput environments.

The core interoperability table that maps every supported Service-Object Pair (SOP) Class to its intended usage. Each row represents a specific SOP Class UID, such as CT Image Storage or Modality Worklist Information Model - FIND. The matrix explicitly declares the device's role (SCU or SCP) for each class. This is the primary reference for determining if two systems can exchange a specific type of data. A mismatch here is the most common cause of a failed DICOM association negotiation, as the devices cannot agree on a common language for the transaction.

Details the encoding rules the device supports for serializing data into a byte stream. This section lists the Transfer Syntax UIDs accepted for each SOP Class, specifying byte ordering (Little Endian vs. Big Endian) and compression schemes. Common entries include JPEG Lossless, JPEG 2000, and the uncompressed Explicit VR Little Endian. The statement clarifies the device's preference order, which dictates the final encoding chosen during association negotiation. This directly impacts network bandwidth usage and the computational load required for on-the-fly decompression.

Provides a granular breakdown of the data elements a device populates or requires for a given SOP Class. This section lists the specific DICOM Tags (e.g., Patient Name (0010,0010), Study Instance UID (0020,000D)) and their Value Representations (VR). It distinguishes between mandatory Type 1 attributes that must be present, Type 2 attributes that must be present but can be empty, and optional Type 3 attributes. This allows an engineer to predict exactly which fields will be filled in a C-FIND response or a stored image header, ensuring downstream database mapping is accurate.

Defines the underlying network stack the device uses to establish a connection. This section specifies the supported TCP/IP configuration, including the port number for incoming associations (typically port 104 or 11112 for secure connections). It details the maximum PDU (Protocol Data Unit) length the device can receive, which is a critical parameter for optimizing network throughput and avoiding fragmentation. For modern implementations, this section also declares support for DICOMweb protocols like WADO-RS and STOW-RS, specifying the base URL and supported media types like application/dicom+json.

Documents any vendor-specific additions that deviate from the standard DICOM dictionary. This section defines Private Tags—data elements with an odd group number—that a device embeds in images or objects to store proprietary information like advanced reconstruction parameters or scanner calibration data. The statement must provide the Private Creator Identification code and the VR for each custom element. Without this explicit definition, a receiving system cannot parse these blocks of data, potentially causing parsing errors or the silent loss of clinically relevant acquisition context.