DICOM Basics - Understanding DICOM Conformance Statements

Dec 13, 2025

Introduction

This is part of my series of articles on the DICOM standard. In this article, we'll explore DICOM Conformance Statements - the official documents that describe what DICOM capabilities a system supports. Understanding how to read these statements is essential for anyone involved in integrating medical imaging systems.

Every DICOM-compliant product must provide a Conformance Statement. These documents are crucial for determining whether two systems can communicate successfully before attempting integration.

What is a DICOM Conformance Statement?

A DICOM Conformance Statement is a formal document that describes:

Which DICOM services the system supports
Which SOP Classes are implemented
The roles (SCU/SCP) the system can play
Supported transfer syntaxes
Association negotiation behavior
Extensions or deviations from the standard

The format and content of Conformance Statements are defined in DICOM Part 2.

Why Conformance Statements Matter

Before integrating two DICOM systems, you should review their Conformance Statements to verify:

Both systems support the required SOP Classes
Compatible roles (one SCU, one SCP for each service)
Common transfer syntaxes
Matching association negotiation parameters
Any limitations or extensions that might affect interoperability

Structure of a Conformance Statement

A typical Conformance Statement includes these sections:

Section	Content
Introduction	Product overview, intended use
Implementation Model	Application Data Flow Diagram, actors
AE Specifications	Application Entity details for each AE
Communication Profiles	Network capabilities
Extensions/Specializations	Deviations from standard
Configuration	Configurable parameters

Reading the Application Entity (AE) Section

The AE section describes each Application Entity and its capabilities:

Example AE Specification:

AE Title: PACS_ARCHIVE
Port: 104
Maximum PDU Size: 16384

Real-World Activities:
  - Store received images
  - Respond to queries
  - Retrieve images for display

Understanding SOP Class Tables

SOP Class tables show which services are supported:

SOP Class	Role	Transfer Syntax
CT Image Storage	SCP	Implicit VR LE, Explicit VR LE, JPEG Lossless
MR Image Storage	SCP	Implicit VR LE, Explicit VR LE
Patient Root Query/Retrieve - FIND	SCP	Implicit VR LE
Patient Root Query/Retrieve - MOVE	SCP	Implicit VR LE

Key columns explained:

SOP Class: The specific service (e.g., CT Image Storage)
Role: SCU (Service Class User/client) or SCP (Service Class Provider/server)
Transfer Syntax: How data is encoded and compressed

Transfer Syntax Compatibility

For two systems to communicate, they must share at least one transfer syntax. Common transfer syntaxes:

Transfer Syntax	UID	Description
Implicit VR Little Endian	1.2.840.10008.1.2	Default, always supported
Explicit VR Little Endian	1.2.840.10008.1.2.1	Common, explicit VR
JPEG Lossless	1.2.840.10008.1.2.4.70	Lossless compression
JPEG 2000 Lossless	1.2.840.10008.1.2.4.90	Modern lossless
JPEG Baseline	1.2.840.10008.1.2.4.50	Lossy compression

Association Negotiation Parameters

The Conformance Statement should document association parameters:

Association Initiator (SCU):
  Maximum PDU Size: 16384 bytes
  Implementation Class UID: 1.2.840.xxxxx
  Implementation Version Name: PRODUCT_V1.0
  Maximum number of associations: 10
  Timeout: 30 seconds

Association Acceptor (SCP):
  Maximum PDU Size: 32768 bytes
  Accepts multiple associations: Yes
  Timeout for idle associations: 60 seconds

Example: Reading a PACS Conformance Statement

When evaluating a PACS system, look for:

Storage SCP Capabilities:

Supported SOP Classes as SCP (can receive):
  - CT Image Storage (1.2.840.10008.5.1.4.1.1.2)
  - MR Image Storage (1.2.840.10008.5.1.4.1.1.4)
  - Ultrasound Image Storage (1.2.840.10008.5.1.4.1.1.6.1)
  - Digital X-Ray (1.2.840.10008.5.1.4.1.1.1.1)
  - Secondary Capture (1.2.840.10008.5.1.4.1.1.7)
  ... (many more)

Query/Retrieve SCP Capabilities:

Supported Query Levels:
  - PATIENT
  - STUDY
  - SERIES
  - IMAGE

Supported Query Attributes:
  - Patient Name (0010,0010)
  - Patient ID (0010,0020)
  - Study Date (0008,0020)
  - Modality (0008,0060)
  - Accession Number (0008,0050)
  ... (list of searchable attributes)

Example: Reading a Modality Conformance Statement

When evaluating a modality (e.g., CT scanner), look for:

Storage SCU Capabilities:

Supported SOP Classes as SCU (can send):
  - CT Image Storage (1.2.840.10008.5.1.4.1.1.2)
  - Secondary Capture (1.2.840.10008.5.1.4.1.1.7)
  - Storage Commitment (1.2.840.10008.1.20.1)

Modality Worklist SCU:

Worklist Query Attributes:
  - Patient Name
  - Patient ID
  - Accession Number
  - Scheduled Procedure Step Start Date
  - Modality

Common Integration Issues Revealed by Conformance Statements

1. Missing SOP Classes

Problem: Modality sends Enhanced CT, PACS only accepts CT Image Storage
Solution: Check SOP Class lists carefully before integration

2. Incompatible Transfer Syntaxes

Problem: Modality sends JPEG 2000, PACS only accepts Implicit VR LE
Solution: Configure modality to use compatible transfer syntax
         or upgrade PACS to support JPEG 2000

3. Missing Query Attributes

Problem: Need to search by referring physician,
         but PACS doesn't index that attribute
Solution: Check "Supported Query Attributes" section

Creating a Conformance Statement

If you're developing a DICOM application, you must create a Conformance Statement. Key sections to include:

Introduction: Product name, version, intended use
Implementation Model: System architecture diagrams
AE Specifications: For each Application Entity:
- Association establishment behavior
- Proposed/accepted presentation contexts
- SOP Class tables with roles
- Association initiation/acceptance policies
Communication Profiles: Network protocols, ports
Character Set Support: Supported character encodings
Security Profiles: TLS, authentication support
Configuration: Configurable parameters

Tools for Conformance Verification

Several tools can help verify DICOM conformance:

DVTk (DICOM Validation Toolkit): Open-source validation tool
DCMTK: Command-line tools for testing
Orthanc: Can be used as a test server
Vendor-provided test tools: Many vendors provide testing utilities

Best Practices

Always request Conformance Statements before purchasing equipment
Compare Conformance Statements between systems before integration
Keep Conformance Statements updated as software versions change
Use Conformance Statements during troubleshooting
Participate in IHE Connectathon events for interoperability testing

Conclusion

DICOM Conformance Statements are essential documents for understanding what a system can and cannot do. By learning to read and interpret these documents, you can predict integration issues before they occur and make informed decisions about equipment purchases and system configurations.

While Conformance Statements can be lengthy and technical, focusing on the key sections - SOP Classes, roles, transfer syntaxes, and query capabilities - will give you the information needed for most integration decisions.