Conformance Statements are critical to interoperability because they provide important information for implementers and system integrators in order to determine whether or not applications do interoperate. In addition, when issues occur, they provide a source of information in order to potentially resolve any problems. Lastly, it is important to provide potential implementers with a consistent template for generating these documents.
PS 3.2 defines principles that implementations claiming conformance to the Standard shall follow. PS 3.2 specifies:
— the minimum general conformance requirements that must be met by any implementation claiming conformance to the DICOM Standard. Additional conformance requirements for particular features, Service Classes, Information Objects, and communications protocols may be found in the conformance sections of other Parts of the DICOM Standard;
— the purpose and structure of a Conformance Statement. PS 3.2 provides a framework by which conformance information can be placed into a Conformance Statement as dictated by the conformance sections of other Parts of the DICOM Standard.
The DICOM Standard does not specify:
— testing or validation procedures to assess an implementation's conformance to the Standard;
— testing or validation procedures to assess whether an implementation matches to its Conformance Statement;
— what optional features, Service Classes, or Information Objects should be supported for a given type of device.