DICOM conformance testing requirements

What does DICOM require of a conforming implementation?

Conformance attaches to a Service-Object Pair Class. PS3.1 section 1.4.4 states that conformance requirements and claims are "referenced to the identifier of the SOP Class, and never referenced to an edition of the Standard", and that each implementation is required to provide a Conformance Statement in a consistent pro forma structure.

PS3.1 Section 7 names four channels through which conformance is possible: SOP Classes carried over DIMSE messages as specified in PS3.4, Web Services in PS3.18, media interchange under the Media Storage Service Class in PS3.4 and PS3.10, and the hosted application API in PS3.19. Additional claims may be made to Profiles in PS3.11 and PS3.15.

part PS3.2 sets a minimum for each channel. For a DIMSE network claim, Section 7.1.1 requires the implementation to conform to at least one Standard or Standard Extended SOP Class from PS3.4, to produce and process Data Sets as defined in PS3.5, to support TCP/IP, to hold a legitimate right to a registered organisation identifier before it creates Privately Defined UIDs, and to accept a Presentation Context for the Verification SOP Class as an SCP if it accepts any DICOM Association requests. That last one is a single testable check: an SCP that answers Associations at all has to answer C-ECHO, UID 1.2.840.10008.1.1.

For a Web Services claim, Section 7.1.2 requires conformance to at least one Service defined in PS3.18. For media interchange, Section 7.2 requires a Standard Media Storage Application Profile from PS3.11 and a physical medium and media format from PS3.12, and it closes with a disqualifier: "An implementation that does not meet all the above requirements shall not claim conformance to DICOM for Media Storage Interchange." All three routes require the same document on top: a Conformance Statement that follows the template in Annex N of PS3.2.

Twenty Parts are published. The numbering runs to PS3.22, and PS3.9 and PS3.13 are recorded as retired in PS3.1 Sections 6.9 and 6.13. These are the Parts a conformance test reads from:

DICOM Standard Parts used in conformance testing, each with its title and the item a conformance test takes from it.

Part	Title	What the test takes from it
PS3.2	Conformance	The template the Conformance Statement must follow
PS3.3	Information Object Definitions	Which modules are mandatory, conditional or user optional for an IOD
PS3.4	Service Class Specifications	The Service Class the claimed SOP Class belongs to
PS3.5	Data Structures and Encoding	The Data Element Types, and what counts as a protocol violation
PS3.6	Data Dictionary	Tag, VR and VM per element, and the registry of UIDs
PS3.7	Message Exchange	The DIMSE-C and DIMSE-N services a Command Set can carry
PS3.8	Network Communication Support for Message Exchange	The Upper Layer Protocol over TCP/IP, and the port to target
PS3.10	Media Storage and File Format for Media Interchange	The File Meta Information every DICOM file must carry
PS3.15	Security and System Management Profiles	The de-identification profile a data set is measured against
PS3.18	Web Services	The DICOMweb transactions and the declarations each one demands

Why can two conforming systems still fail to exchange images?

Because the Standard says conformance is not interoperability, and hands the check to the buyer. PS3.1 Section 1.2 ends with the caveat: "This Standard facilitates interoperability of systems claiming conformance in a multi-vendor environment, but does not, by itself, guarantee interoperability."

PS3.2 Section 6 is hedged in the same direction. Comparing the Conformance Statements of two implementations lets a knowledgeable user determine "whether and to what extent communications might be supported between the two implementations". The Standard then writes the caveat into the vendor's own document. The template text in PS3.2 Annex N.3.3 reads: "DICOM by itself does not guarantee interoperability", and "This Conformance Statement should not replace validation with other DICOM equipment to ensure proper exchange of intended information." The same annex assigns the remaining work: "Test procedures should be defined and executed to validate the required level of interoperability with specific DICOM conformant equipment, as established by the healthcare facility."

The scope of a DICOM test programme is therefore set by the peer systems named in the contract, which is why a medical device interoperability test plan starts from the site inventory rather than from the Standard.

Which release of DICOM does your requirement point at?

None of them, if the requirement is written the way the Standard asks. PS3.1 Section 7 states that conformance is claimed per SOP Class and adds that "generally, the only appropriate reference to a particular edition of the Standard is to identify a retired feature".

The release designation still matters for reading. DICOM has no numbered editions. PS3.1 section 1.4.2, Continuous Maintenance describes the mechanism: supplements and corrections are balloted and approved several times a year, and each change goes into effect immediately once approved as Final Text. Consolidated releases follow a year-plus-letter designation, and PS3.1 Section 7 calls such a publication "only a convenience to the user; the Standard is officially changed when each change is approved". The publisher's directory listing bears the cadence out: 2025a through 2025e, five releases in that year, and 2026a, 2026b and 2026c so far in this one.

The 2026c documents print no editorial publication date. The date 2026-06-18 used on this page comes from the publisher's file server, where the release archives carry the build stamp 20260618221022 and the HTML Part files carry the same day's timestamp. Separately, PS3.1 is published by ISO as ISO 12052:2026, Edition 3, recorded at stage 60.60 on 2026-02-18, 16 pages, under ISO/TC 215. The ISO abstract says only that the document is equivalent to part 1 of DICOM. It names no release designation, so this page makes no claim about which DICOM release ISO 12052:2026 corresponds to. The earlier ISO 12052:2017 is withdrawn.

For a product on a release train, the practical consequence is that the reference text under a passing test can move while the product stands still. Dating the Conformance Statement and the test report to a named release is what makes a later regression run in a regulated environment comparable with the first one.

What can be tested, when the Standard specifies no test procedure?

The encoded objects and the declared behaviour, both against normative text. The exclusion is explicit and stated twice. PS3.1 Section 1.1 lists among the things DICOM does not specify "a testing/validation procedure to assess an implementation's conformance to the Standard". PS3.2 Section 1 repeats it and adds a second exclusion: no procedure is specified for assessing "whether an implementation matches to its Conformance Statement" either.

Four normative pieces still combine into a machine-checkable object validation. PS3.5 Section 7.4 fixes the Data Element Types and names the failure. PS3.3 IOD module tables mark each module M, C or U, with the condition written into the cell. PS3.6 fixes each element's tag, VR and VM. PS3.10 Section 7.1 fixes the file header: a 128-byte File Preamble, then the four-byte prefix "DICM", then the File Meta Elements, present in every DICOM file.

DICOM Data Element Types 1, 1C, 2, 2C and 3, with their PS3.5 subclauses and what an object validator reports for each.

Data Element Type	PS3.5	What a validator reports
1	7.4.1	Element absent, or Value Field length zero: protocol violation
1C	7.4.2	Condition met and element absent: protocol violation
2	7.4.3	Element absent: protocol violation. Zero length with no value is allowed when the value is unknown
2C	7.4.4	Type 2 rules, under the stated condition
3	7.4.5	Absence carries no significance and is no violation

The note under 7.4.1 closes a loophole a validator has to handle. One or more BACKSLASH delimiters alone do not satisfy a Type 1 requirement, even though the Value Length is above zero, and for a PN element the component and component group delimiters alone do not satisfy it either. A check that only measures length passes those instances.

The module tables give the object check its shape. PS3.3 Table A.3-1, the CT Image IOD, lists 26 module rows: 11 mandatory, 4 conditional and 11 user optional. Two of the conditional rows are test cases in themselves. Single-Frame CT Series is "Required if the SOP Class UID of this instance is 1.2.840.10008.5.1.4.1.1.2.3", and Multi-energy CT Image is "Required if Multi-energy CT Acquisition (0018,9361) is YES". A validation run that covers only the mandatory modules reports clean on an instance missing both.

On the wire, PS3.8 recommends the well-known port 104 for a single DICOM Upper Layer entity, and the registered port 11112 where the operating system restricts privileged ports. DIMSE itself is not a unit of conformance: PS3.7 Section 8.3 states that implementers conform to the DIMSE protocol only through conformance to a SOP Class as defined in PS3.2 and PS3.4.

For DICOMweb, PS3.18 Table 10.3-2 is the closest thing in the Standard to a mandatory-feature checklist. Resources permitted for each transaction are marked M where support is mandatory for the origin server and O where it is optional, so a Retrieve implementation that serves Study, Series and Instance while omitting Frames or Bulk Data has a gap rather than a design choice. WADO-RS, STOW-RS and QIDO-RS are the Retrieve, Store and Search transactions of one Studies Service, as PS3.18 Section 10.1 states, and WADO-URI is a separate single-instance service in Section 9. A DICOMweb front end may also be a proxy over a DIMSE back end, which PS3.1 Section 6.18 describes explicitly. Where that is the case a test that stops at the HTTP response never reaches the SCP behind it, the same blind spot that makes testing an EHR integration an end-to-end exercise.

The Standard names no test suite, no test data set and no validation tool anywhere in its text. Any validator used on a project therefore comes from industry practice and cannot be cited to the Standard. The one artefact the publisher ships towards testing is the Standard itself in XML, which its Current Edition page describes as good for machine readability, for example self-updating validators.

Which artefacts does a reviewer ask for?

The Conformance Statement first, and it has a required shape. PS3.2 annex N, DICOM Conformance Statement Template is normative: "The content and organization of DICOM Conformance Statements shall conform to this template." One Statement is provided per implementation, with a consistent structure whether the product speaks DIMSE, media storage, Web Services, Real-Time Video or a combination. Sections that do not apply are kept and marked as not applicable.

The template runs N.0 Cover Page through N.13 Code Set Usage, 14 sections, and its own rules are what a document review checks against:

Table N.1-1 in the overview is the densest testable object in the document. It lists every Storage SOP Class in numerical order of the SOP Class UID, the Transfer Syntax Set from Table N.1-2 that applies to it, and the roles supported under the DIMSE, DICOM Web and Media Services columns, with the Create column typed S, SE, SP or P for Standard, Standard Extended, Specialized or Private. Each row is a capability a test can call.

PS3.18 adds per-transaction declarations that read as a checklist on their own. Section 10.4.5 requires the Retrieve Transaction to document the roles played, the resources supported, the media types, the optional query parameters and header fields, and the Composite SOP Classes supported. Section 10.5.5 requires the Store Transaction to declare the SOP Classes supported and any implementation-specific warning and error codes. Section 10.6.5 requires a Search origin server to declare the maximum number of matches for a single query, plus its support for fuzzy matching, empty value matching, multiple value matching, optional resources and optional attributes. Each of those is a declared behaviour that can be exercised against the declaration.

De-identification carries its own artefact. PS3.15 Annex E is normative, and an implementation claiming the Basic Application Level Confidentiality Profile as a de-identifier shall protect or retain all instances of the attributes in Table E.1-1, including those embedded in an Item of a Sequence of Items. Imaging instances carry patient identity in ordinary attributes such as Patient's Name (0010,0010) and Patient ID (0010,0020), so a test environment holding real studies holds PHI, and the terms under which an outside team may touch it are raised at how we work with protected health information. The route that removes the question is covered in PHI de-identification for test environments.

Where does DICOM conformance work go wrong?

• The Conformance Statement describes a version that no longer matches the shipped build, although N.0 requires the stated version to correspond to the functionality described.
• Sections that do not apply are deleted rather than marked N/A, so the document cannot be read row by row against the peer vendor's Statement.
• Table N.1-1 lists a Storage SOP Class whose declared Transfer Syntax set was never exercised, and the mismatch surfaces at the first site that negotiates Explicit VR Little Endian, 1.2.840.10008.1.2.1, instead of the default Implicit VR Little Endian.
• An SCP accepts Association requests and rejects the Presentation Context for the Verification SOP Class, which Section 7.1.1 does not permit.
• Type 2 elements are omitted from created instances instead of being sent with zero length, which PS3.5 Section 7.4.3 calls a protocol violation.
• A QIDO-RS origin server never declares its maximum number of matches for a single query, so a client that pages through results has nothing to code against.
• Privately Defined UIDs are minted under a root the vendor holds no registered right to.
• De-identification is measured against Table E.1-1 alone, while Annex E itself warns that identifying information may remain in Private Attributes, Retired Standard Attributes and attributes used in Standard Extended SOP Classes.

How do we test a product against its Conformance Statement?

The Statement is the specification. PS3.2 leaves the procedure for checking an implementation against its own Conformance Statement unspecified, so the test plan is built by turning each declaration into a call and each declared absence into a negative case.

The output is the artefact list above: a reviewed Conformance Statement, a capability matrix, a validation log written in the Standard's own vocabulary, and an exchange log against named peer systems. The last of those is the validation PS3.2 Annex N.3.3 asks the healthcare facility to perform, and it is the part no vendor's own document can supply.

The broader engagement is described under healthcare interoperability testing, and the record side of it under validation documentation.

Part numbers, section numbers, tags and UIDs on this page were read from release 2026c of the DICOM Standard on 2026-09-02.