Conformance statementswill these two devices talk?
Every DICOM product comes with a Conformance Statement that says what it supports. Part 2 of the standard defines what must be in it, and Annex N gives the template that vendors follow. Learn to read two of them side by side and you can predict most integration problems before the cables are plugged in.
- DICOM
- Internal action
- Dashed = reply
Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.
Read the Overview of device A
Core stepWhat happens
Start at the Overview at the front of the statement. It lists, per service (Verification, Storage, Workflow Management, Query/Retrieve, Print, and the DICOM web services), the SOP Classes the product supports, whether it plays SCU, SCP or both, and the transfer syntaxes it supports.
Why it is needed
The Overview is meant as the first-level compatibility check. Sales and integrators use it to decide quickly whether two products could possibly fit before reading the details.
Technical details
- Annex N layout: Overview, Table of contents, Introduction, Implementation Model, Service and Interoperability Description, Configuration, Network and Media Communication Details, then Security, IODs and further annexes
- Overview: Content and Transfer (storage SOP Classes), DIMSE Services, DICOM Web Services, Media Services, Real-Time Video, De-identification, Character sets
- Roles are listed per SOP Class: SCU, SCP, or both
Read the Overview of device B
Core stepWhat happens
Do the same for the second device. Write down each SOP Class by its UID and the role this device plays for it.
Why it is needed
The second statement is the other half of the match. Reading only one side is the typical reason "supported" turns out not to be compatible.
Technical details
- Note UIDs, not only names (e.g. CT Image Storage vs. Enhanced CT Image Storage are different SOP Classes)
- A product can have several Application Entities. The Implementation Model (application data flow diagram) shows which AE does what
- Section "Mapping of Services to Application Entities" is a table: AE, service, role
Match the roles: SCU meets SCP
Core stepWhat happens
Take each service you need and check the roles. If A sends CT images (SCU for CT Image Storage), B must list CT Image Storage as SCP. The roles must be complementary, per SOP Class.
Why it is needed
Two SCUs or two SCPs never form a working pair. This is also where a needed SOP Class that is simply missing from the other statement shows up.
Technical details
- A: CT Image Storage 1.2.840.10008.5.1.4.1.1.2, SCU
- B: CT Image Storage 1.2.840.10008.5.1.4.1.1.2, SCP
- Query/Retrieve: viewer = SCU, PACS = SCP
- Storage Commitment and MPPS have SCU and SCP sections in the statement; for commitment the SCU must also receive the N-EVENT-REPORT
Check the type of each SOP Class
Key detailWhat happens
PS3.2 sorts every SOP Class in a statement into one of four types. A Standard SOP Class is used as defined. A Standard Extended one keeps the standard UID and only adds optional (Type 3) attributes. A Specialized one is derived from a standard class, adds attributes or restrictions and uses a private UID. A Private SOP Class is not in the standard at all, only in the vendor's statement.
Why it is needed
Extended classes interoperate freely, because receivers just ignore the extras. A Specialized or Private class has a UID the other side has never heard of, so the two vendors must agree on UID, content and meaning beforehand, or it is refused.
Technical details
- Standard: no additions, declared with options and roles
- Standard Extended: same UID, extra Type 3 attributes only, listed in the statement
- Specialized: private UID, based on a standard class
- Private: defined only in the Conformance Statement
Find a common transfer syntax
Key detailWhat happens
Compare the transfer syntaxes of the two products for each SOP Class. If a storage SCU keeps images in several encodings, its statement also tells which conversions it can do on send. At least one transfer syntax must be on both lists.
Why it is needed
Implicit VR Little Endian is the default every DICOM network implementation supports, so a basic transfer is always possible. Compressed images only work if both ends list the same compression, or if one side can convert.
Technical details
- Implicit VR Little Endian 1.2.840.10008.1.2 (default)
- Explicit VR Little Endian 1.2.840.10008.1.2.1
- JPEG Lossless 1.2.840.10008.1.2.4.70, JPEG 2000 Lossless 1.2.840.10008.1.2.4.90
- Transcoding table in the statement: SUPPORTED (same SOP Instance UID), NEW_UID (a new instance is created, e.g. lossy), NOT_SUPPORTED
Read the association parameters and failure behavior
Key detailWhat happens
The "Network and Media Communication Details" section lists the association parameters (per product or per AE): maximum PDU length, ARTIM timeout, and the maximum number of simultaneous associations as initiator and as acceptor. It also describes how the AE behaves when a communication failure occurs, and which status codes it sends and how it reacts to them.
Why it is needed
A scanner that opens several associations at once will have some refused by a device that accepts few. Failure behavior (retry, abort, mark as failed) explains what you will see in the logs.
Technical details
- Application Context Name 1.2.840.10008.3.1.1.1
- Implementation Class UID and Implementation Version Name
- Maximum PDU length, ARTIM timeout
- Max simultaneous associations as initiator / as acceptor
- Status code tables per service, and behavior as initiator and as acceptor on failure
Configure both sides
Core stepWhat happens
The Configuration section lists, per service, the local and the remote parameters and whether each can be set by the USER, by SERVICE personnel or is FIXED. A product that is an SCP has a Called AE title and port to configure; an SCU has a Calling AE title and the remote Called AE title to configure.
Why it is needed
The statement describes what is possible. The configuration is what makes it happen. Most failures at go-live are missing or wrong entries here, not a conformance problem. Do it for every direction in which a device calls the other, including the return path for C-MOVE and storage commitment.
Technical details
- A calls B: A needs B's AE title, IP, port; B must know A's AE title
- B calls A (C-MOVE, N-EVENT-REPORT): A needs a listener; B needs A's AE title, IP, port
- Open the firewall for each port, in each direction that is used
- FIXED values must be copied to the other side as they are
Test: C-ECHO, then the real workflow
Core stepWhat happens
First a C-ECHO in both directions to prove network and AE titles. Then run each real exchange with test data: store a small study, query it, retrieve it, run an exam from the worklist.
Why it is needed
The standard's own template tells the reader that validating with the other equipment is their responsibility: statements are only the first step, and test procedures must be defined and executed.
Technical details
- PS3.2 requires an AE that accepts any association to accept Verification (1.2.840.10008.1.1) as SCP, so C-ECHO is always available
- Then one test study for every workflow: store, query, retrieve, worklist, MPPS, commitment
- Check that tags survive: PatientID, AccessionNumber, StudyInstanceUID, character set
Read the result: accepted or rejected
ConfirmationWhat happens
If it works, the association is accepted and the statuses are 0000. If not, the response tells you which part of the statement did not match, and the statement's status code and failure tables tell you what each side does about it.
Why it is needed
The cause is usually named by the response: a rejected AE title is configuration; a refused context is a SOP Class, role or transfer syntax row of the statement that does not match.
Technical details
- A-ASSOCIATE-RJ: AE title, access list, association limit
- AC with context result 3: SOP Class not supported by the acceptor
- AC with context result 4: no common transfer syntax
- Failure statuses: see the C-STORE and C-FIND lessons
All steps at a glance
Glossary
- Conformance Statement
- A document from the vendor, structured as defined in DICOM PS3.2 (template in Annex N), that lists what a product supports: SOP Classes, roles, transfer syntaxes and behavior.
- AE / AE title
- Application Entity: a DICOM application on a device. Its AE title (max 16 characters) is the name other devices use to address it.
- SCU
- Service Class User. The side that asks for a service, such as a scanner that wants to store images.
- SCP
- Service Class Provider. The side that provides the service, such as a PACS that stores images.
- SOP Class
- Service-Object Pair class. A UID naming one kind of object plus the service used on it, e.g. CT Image Storage (1.2.840.10008.5.1.4.1.1.2).
- Transfer syntax
- How a data set is encoded on the wire: byte order, explicit or implicit VR, and the image compression.
- Presentation context
- One SOP Class (abstract syntax) paired with the transfer syntaxes offered for it. Each gets an odd ID (1, 3, 5 ...).
- Real-World Activity
- In the application data flow diagram of a statement: something that happens outside DICOM, such as "technologist sends images", which triggers an AE to use a DICOM service.
- Standard Extended SOP Class
- A standard SOP Class with extra optional (Type 3) attributes. It keeps the standard UID, so other devices accept it and ignore the extras.
- Private SOP Class
- A SOP Class that is not in the DICOM Standard but published in a vendor's Conformance Statement. The other side must agree to it beforehand.
- IHE integration statement
- A vendor document listing which IHE profiles and actors a product supports. It complements the DICOM conformance statement and describes workflows.
Summary
- A Conformance Statement follows the PS3.2 Annex N template: Overview, Implementation Model, Service and Interoperability Description, Configuration, Network and Media Communication Details.
- The Overview gives a first-level comparison: SOP Classes,
SCUorSCProle per class, and transfer syntaxes. Match roles per SOP Class. - Check the SOP Class type. Standard Extended classes interoperate; Specialized and Private classes need prior agreement on UID and content.
- An AE that accepts any association must accept the Verification SOP Class (
1.2.840.10008.1.1) as SCP, so aC-ECHOis always a valid first test. - The template's own Remarks say DICOM by itself does not guarantee interoperability. Configure AE titles, IP addresses and ports on both sides, then test the real workflows.
The 9 steps in plain text
Read the Overview of device A
Start at the Overview at the front of the statement. It lists, per service (Verification, Storage, Workflow Management, Query/Retrieve, Print, and the DICOM web services), the SOP Classes the product supports, whether it plays SCU, SCP or both, and the transfer syntaxes it supports.
Why: The Overview is meant as the first-level compatibility check. Sales and integrators use it to decide quickly whether two products could possibly fit before reading the details.
Read the Overview of device B
Do the same for the second device. Write down each SOP Class by its UID and the role this device plays for it.
Why: The second statement is the other half of the match. Reading only one side is the typical reason "supported" turns out not to be compatible.
Match the roles: SCU meets SCP
Take each service you need and check the roles. If A sends CT images (SCU for CT Image Storage), B must list CT Image Storage as SCP. The roles must be complementary, per SOP Class.
Why: Two SCUs or two SCPs never form a working pair. This is also where a needed SOP Class that is simply missing from the other statement shows up.
Check the type of each SOP Class
PS3.2 sorts every SOP Class in a statement into one of four types. A Standard SOP Class is used as defined. A Standard Extended one keeps the standard UID and only adds optional (Type 3) attributes. A Specialized one is derived from a standard class, adds attributes or restrictions and uses a private UID. A Private SOP Class is not in the standard at all, only in the vendor's statement.
Why: Extended classes interoperate freely, because receivers just ignore the extras. A Specialized or Private class has a UID the other side has never heard of, so the two vendors must agree on UID, content and meaning beforehand, or it is refused.
Find a common transfer syntax
Compare the transfer syntaxes of the two products for each SOP Class. If a storage SCU keeps images in several encodings, its statement also tells which conversions it can do on send. At least one transfer syntax must be on both lists.
Why: Implicit VR Little Endian is the default every DICOM network implementation supports, so a basic transfer is always possible. Compressed images only work if both ends list the same compression, or if one side can convert.
Read the association parameters and failure behavior
The "Network and Media Communication Details" section lists the association parameters (per product or per AE): maximum PDU length, ARTIM timeout, and the maximum number of simultaneous associations as initiator and as acceptor. It also describes how the AE behaves when a communication failure occurs, and which status codes it sends and how it reacts to them.
Why: A scanner that opens several associations at once will have some refused by a device that accepts few. Failure behavior (retry, abort, mark as failed) explains what you will see in the logs.
Configure both sides
The Configuration section lists, per service, the local and the remote parameters and whether each can be set by the USER, by SERVICE personnel or is FIXED. A product that is an SCP has a Called AE title and port to configure; an SCU has a Calling AE title and the remote Called AE title to configure.
Why: The statement describes what is possible. The configuration is what makes it happen. Most failures at go-live are missing or wrong entries here, not a conformance problem. Do it for every direction in which a device calls the other, including the return path for C-MOVE and storage commitment.
Test: C-ECHO, then the real workflow
First a C-ECHO in both directions to prove network and AE titles. Then run each real exchange with test data: store a small study, query it, retrieve it, run an exam from the worklist.
Why: The standard's own template tells the reader that validating with the other equipment is their responsibility: statements are only the first step, and test procedures must be defined and executed.
Read the result: accepted or rejected
If it works, the association is accepted and the statuses are 0000. If not, the response tells you which part of the statement did not match, and the statement's status code and failure tables tell you what each side does about it.
Why: The cause is usually named by the response: a rejected AE title is configuration; a refused context is a SOP Class, role or transfer syntax row of the statement that does not match.
Common questions
What is a DICOM Conformance Statement?
A document that a vendor publishes for a product, following the structure and content rules of DICOM PS3.2. It states which DICOM services the product supports (DIMSE network services, DICOM web services, media storage, real-time video), in which role, with which SOP Classes and transfer syntaxes, and how it is configured and behaves on the network.
Does DICOM conformance guarantee that two devices work together?
No. The Remarks text of the PS3.2 template says: "DICOM by itself does not guarantee interoperability." Comparing two statements is a first-level check, and the user is expected to define and execute test procedures with the actual equipment. Note also that PS3.2 does not specify how conformance itself is tested or validated.
What is the minimum a DIMSE implementation must support?
According to PS3.2 section 7.1.1: provide a Conformance Statement that follows the Annex N template, conform to at least one Standard or Standard Extended SOP Class, handle SOP Classes according to their type, accept the Verification SOP Class as SCP if it accepts any association request, produce or process data sets per PS3.5, obtain its own registered UID root if it uses private UIDs, and support TCP/IP.
What is the difference between SCU and SCP?
The SCU requests a service and the SCP provides it. For storage the sending device is the SCU and the archive is the SCP. A device can be SCU for one SOP Class and SCP for another, and the roles are independent of who opens the association.
What do I look for first in a conformance statement?
The Overview, then the "Mapping of Services to Application Entities" table and the section for the service you need (for example "SCU of the Storage SOP Classes"). Find the exact SOP Classes by UID, check the role on both devices, then the transfer syntaxes, the configuration section and the association parameters.
What are Standard Extended, Specialized and Private SOP Classes?
PS3.2 section 7.3 defines the types. A Standard Extended SOP Class uses the standard UID and only adds optional attributes. A Specialized SOP Class is based on a standard one but has a private UID. A Private SOP Class is defined only in the vendor statement. For the last two, both vendors must agree on UID and content before they can exchange instances.
The statement says a SOP Class is supported but it fails. Why?
Check the role (SCU versus SCP), the transfer syntax, a per-AE or per-modality setting that is off, and whether the SOP Class is only supported on a particular AE. The statement also does not say whether a feature is licensed or enabled in your installation, and it does not replace testing.