Integration

DICOM Conformance Statements

Every DICOM-capable device is required by the standard to publish a conformance statement: a document listing every service class, SOP class, transfer syntax, and security profile it supports — and equally important, which it does not. If you're integrating two DICOM devices, the conformance statements tell you in advance which associations will succeed and which will fail at Presentation Context negotiation.

The structure of a conformance statement

PS3.2 prescribes the document structure. Every statement has:

  1. Introduction — vendor info, intended use, references
  2. Implementation model — Application Entities in the device, what each talks to
  3. AE specifications — per AE: SCU / SCP role, which SOP classes, which transfer syntaxes per SOP class, any Presentation Context selection rules
  4. Networking — supported TCP stack, association timeouts, maximum PDU length
  5. Media interchange — if the device reads/writes Part-10 media, which application profiles
  6. Security — TLS profile support, Basic User Identity support, encrypted media
  7. Annexes — the standard extended / private data elements, any behaviour the vendor has documented beyond the body

What to actually check when evaluating a device

When you're scoping an integration, go straight to these sections:

  • Supported SOP classes + SCU/SCP roles — must overlap with the device on the other side. A "CT Image Storage" modality that only acts as SCU won't store anywhere unless the PACS is an SCP for the same SOP class.
  • Supported transfer syntaxes per SOP class — at minimum both sides must support Implicit VR Little Endian (the required-for-all baseline). For compressed, check the specific TS UIDs.
  • Maximum number of Presentation Contexts — some older devices cap at 16 or 32, which gets tight when you have many SOP classes in flight.
  • Character set support — attribute (0008,0005). If you need Unicode, confirm both sides support ISO_IR 192 (UTF-8) or the relevant extended character set.
  • Private tag handling — the device's private creator strings, which groups they occupy. Matters for anonymization and data migration.
  • TLS support — which cipher suites, whether client certificates are required, how the CA trust store is configured.
  • Extended negotiation sub-items — some SOP classes (Storage Commitment, Q/R relational queries) require specific extended negotiation; the statement lists what the device offers and accepts.

What vendors leave out (on purpose)

Conformance statements are self-certified. Nobody audits them. Vendors routinely underdeliver against what the statement claims — here's what to validate against, not just read:

  • Private transfer syntaxes — sometimes used internally but not listed. Surfaces when a site's images won't open on a 3rd-party viewer.
  • Real Q/R match-key behaviour — statements say "PN match: case-insensitive wildcard" but test and you'll find PACS-A wildcards only the surname while PACS-B wildcards anywhere. Always test.
  • Timeout behaviour — stated 30s, actual may be 8s when under load.
  • Silent SCP failures — the device accepts a C-STORE and returns Success but never persists. Pair a Storage Commitment request with every integration test.
  • Character set fall-through — ISO_IR 192 claimed but the device mangles names with accented characters. Smoke-test with real multilingual data.

Requesting a conformance statement

Every reputable vendor publishes conformance statements on their website, often at /dicom/conformance or under a "Technical Resources" section. If it's not publicly available, ask your account rep — they're contractually obligated to provide one. Anything else is a red flag.

Collect the statements for every device in your integration scope (modality + PACS + workstation + EHR gateway + VNA + archive + cloud bridge) and diff them against each other manually. Yes, manually — nobody has built good tooling for this yet.

When a conformance statement isn't enough

Even perfect documentation doesn't replace real testing. At minimum:

  • C-ECHO from every source to every destination
  • Single-image C-STORE with the production transfer syntax
  • Full-study C-STORE of a representative modality sample
  • C-FIND + C-MOVE round trip with realistic query criteria
  • Malformed-data regression — truncated files, unexpected VRs, oversized PDUs

The IHE Connectathon is the industry event where vendors bring equipment and actually test interoperability against each other's gear. Attending (or at minimum, reading the public result reports) is a shortcut to seeing which vendor pairs work.

Explore further