Somebody hands you a conformance statement the week before a new modality, archive, or viewer goes live, and asks whether it’ll work with what you have. The document is sixty to two hundred pages. You have an hour.
The good news is that a conformance statement is written to a template the standard dictates (PS3.2), so every one of them puts the same information in the same places. The better news is that the hour’s question, will these two systems talk, comes down to five things, and you can find all five in about fifteen minutes once you know where to look. The rest of the hour is for the questions the document can’t answer, which is where integrations actually fail.
What a conformance statement is#
It is a vendor’s declaration, in the standard’s own vocabulary, of exactly which parts of DICOM a product implements. Not what the product can do clinically; what it will negotiate and exchange on the wire. Section 7 of PS3.2 requires one for every product claiming DICOM conformance, and it is the only vendor document whose structure the standard controls.
Two things it is not. It is not a test report; a statement says what the vendor claims, and nothing in the standard obliges anyone to have verified it against another product. And it is not a guarantee of interoperability. PS3.2 says this outright in its scope: conformance to the standard “does not guarantee” that two implementations will interoperate. The statement gives you the information to predict whether they will. The prediction is your job.
The five questions, and where they live#
Nearly every statement you’ll be handed follows the template that was PS3.2’s Annex A from the mid-2000s until 2024. The standard has since replaced it with a reorganized template (Annex N, which among other things adds DICOMweb and retires the old sample statements), but vendors update their documents slowly, so the older layout is what you’ll see for years yet. The section numbers below are the older layout’s; I’ll note where the new one moves things.
1. Which Application Entities does the product have, and what does each one do?#
Section 2, Implementation Model. Start with the application data flow diagram. It shows every AE the product exposes and which real-world activity drives each one. A PACS might have one AE that accepts storage, another that answers queries, and a third that sends. A modality might have one for worklist, one for MPPS, one for storage. This is where you learn that the product you think of as “the archive” is really four DICOM endpoints with separate behaviors, and the one you’re planning to query may not be the one that stores.
Write down the AE names. Everything else in the document is organized by them.
2. Which SOP classes does each AE support, as SCU or SCP?#
Section 3, AE Specifications, one subsection per AE, and the SOP class table at the top of each. This is the table that decides most integrations. For a storage interface, it lists which object types (CT Image Storage, Enhanced MR, Breast Tomosynthesis, Encapsulated PDF, and so on) the AE will accept (SCP) or send (SCU). For a query interface, it lists which Query/Retrieve information models are supported, Patient Root or Study Root, and whether FIND, MOVE, and GET are each there.
The failure this table predicts: the new modality produces Enhanced CT objects, the archive’s SOP class table lists only the classic CT Image Storage. The archive will reject the association’s presentation context for Enhanced CT, the modality will either fall back or fail, and the first anyone hears of it is a tech saying “it won’t send.” Thirty seconds with the two tables side by side would have caught it.
3. Which transfer syntaxes does each SOP class support?#
Section 3 again, under each AE’s association policies, in the presentation context tables. Each row pairs a SOP class with the transfer syntaxes the AE will propose (SCU) or accept (SCP): implicit and explicit VR little endian, the JPEG family, JPEG 2000, RLE, and so on.
This is the second most common failure, and the one that doesn’t show up as an error. Two systems that both support CT Image Storage, but where the sender only offers JPEG 2000 lossless and the receiver only accepts uncompressed, will fail at association negotiation. Worse is the case where they do overlap but not on the syntax you expected: the archive accepts the compressed stream, stores it, and later serves it to a viewer that can’t decode it. The conformance statement predicted that too, in the viewer’s own table.
Check all three legs: sender to archive, archive to viewer, archive to any downstream system. Transfer syntax mismatches propagate.
4. What are the association limits?#
Section 3, association policies: General, Number of Associations, Asynchronous Nature. Three numbers. Maximum PDU size, which affects throughput and occasionally compatibility with old equipment. Maximum simultaneous associations the AE will accept, which is the number that matters when twelve modalities all push at seven in the morning. And whether the AE supports asynchronous operations (multiple outstanding requests on one association), which is almost always “no” and occasionally the reason a bulk send is slower than the network suggests.
Also here: Implementation Class UID and Implementation Version Name. Those two values appear in every association the product opens. When you’re reading a log from the other side and trying to work out which product and version was talking, this is the lookup.
5. What happens when something goes wrong?#
Section 3, under each SOP-specific conformance subsection: status code tables and behavior descriptions. This is the section people skip and the one that separates a good statement from a thin one. For a storage SCP it should say what the AE does on receipt of a duplicate SOP instance, an object with a missing required attribute, or an unsupported element: accept, reject with which status, coerce, warn. For a storage SCU it should say how it handles each status the receiver might return, including the warning statuses (B000, B006, B007) that mean “stored, but I changed something.” For Q/R it should list the matching keys supported at each level and whether relational queries are supported, which is exactly the information the C-FIND post said to go find here.
A statement that lists status codes without describing behavior is telling you the vendor filled in the template. In nearly twenty years I can count on one hand the times a production system handed me a status that pointed at the actual problem; it’s an A700-family “out of resources,” or a generic C000 processing failure, and a trip to the logs. A statement that says what its AE does after a status, how many times it retries, what it logs, and when it gives up, is telling you someone engineered the product. Most don’t say.
The order to read in#
flowchart TD
A["Section 2: list the AEs"] --> B["Section 3: SOP class table per AE"]
B --> C{"Both sides share the
SOP classes you need?"}
C -- no --> X["Stop. It won't work
without a gateway."]
C -- yes --> D["Presentation context tables:
transfer syntax overlap on
every leg"]
D --> E{"Overlap on each leg?"}
E -- no --> X
E -- yes --> F["Association limits and
implementation identifiers"]
F --> G["Status handling and
Q/R matching keys"]
G --> H["Sections 6–8: configuration,
character sets, security"]
H --> I["Now test it"]
classDef stop fill:#7f1d1d,stroke:#fca5a5,color:#fee2e2;
class X stop;
Sections 6 through 8 come last not because they don’t matter but because they rarely decide go/no-go. Configuration (6) tells you what’s adjustable in the field, which answers “can we change the AE title and port” and “where does the called-AE whitelist live.” Character sets (7) matter the moment a patient name arrives with a diacritic; if the two sides don’t share a supported character set, names get mangled or rejected. Security (8) tells you whether TLS is supported and how, which is becoming a go/no-go question of its own.
What it won’t tell you#
This is the part of the hour that matters.
Whether the claims are true. A conformance statement is self-reported. I have read statements that listed SOP classes the shipped version didn’t support and matching keys that returned nothing. The document predicts; the test confirms. Nothing goes live on the strength of the statement alone.
Which version you have. Statements are per product version and often lag releases. Check the revision history in Section 1 against the version actually installed. A statement for 5.2 tells you nothing certain about 5.4, and vendors do remove things.
Performance. Nothing in the template describes how fast a query returns, how many studies a day the storage SCP sustains, or what happens to the C-MOVE queue under load. The number of associations is the only capacity figure in the document, and it’s a limit, not a measurement.
Behavior between the lines. The statement describes each service in isolation. It does not describe what the archive does when a storage commitment request arrives for a study that’s still being received, or how it reconciles a worklist entry against a study whose accession number was typed in by hand. The interactions between services are where production surprises come from, and no template section covers them.
Which error you’ll actually get. The status table lists every code the AE can return. In practice the one you see is the generic one, and the specific codes the standard took the trouble to define show up rarely. Plan on reading logs, not statuses.
Anything about the other product. The statement is one side of a conversation. You need both, and you need to read them against each other, table by table. A single statement, however good, answers nothing on its own.
Whether the site’s configuration matches it. The statement describes what the product can do. Half of it is switched off at any given installation. The SOP class the statement lists as supported may be disabled in the config; the transfer syntax may be de-prioritized; the association limit may have been set lower by someone in 2019 for a reason nobody remembers. The statement tells you the ceiling. The installed configuration is the floor you’re standing on.
What I do with it#
Both statements, side by side, five questions, a one-page matrix of SOP class and transfer syntax overlap per leg. Anything that doesn’t overlap goes on a list with a proposed fix (gateway, configuration change, vendor ticket). Anything the statement is vague about goes on a second list: things to test before go-live rather than trust. Then the test, which is the subject of a later post.
The statement is the map. It is not the territory, and the vendor drew it.
Sources#
- DICOM PS3.2, Conformance, current edition: https://dicom.nema.org/medical/dicom/current/output/chtml/part02/PS3.2.html. Section 6 for the purpose of a statement; Section 7 for conformance requirements; Annex N for the current template. Annexes A through M, the older templates and samples, are marked retired in the current edition.
- DICOM PS3.2 2019e, Annex A, for the older template that most statements in the field still follow: https://dicom.nema.org/medical/dicom/2019e/output/chtml/part02/sect_A.3.html.
- Everything about what vendors actually put in statements, and what goes wrong in the field, is experience and is stated as such.