A major issue for any standard is determining conformance. In many situations involving public health and safety, conformance to standards is required by law. For many other types of standards, including DICOM, conformance is voluntary. The DICOM Standards Committee does not have any enforcement authority. However, the DICOM standard includes a whole section devoted to conformance. Anyone claiming that their equipment or software conforms to the DICOM standard must be able to provide a conformance statement that describes exactly how that device or software conforms to the standard. A question that is frequently asked about the DICOM standard is, If it is a standard, why is a conformance statement required? Isn't it sufficient to simply state that equipment conforms? As has already been explained, DICOM can support many different types of images, transfer syntaxes, service roles, and the like. This flexibility is needed if DICOM is to be useful across many different medical imaging applications, but it also means that possibilities or options used in a particular implementation of the standard need to be made known. The conformance statement is a prescribed way of doing this.
A conformance statement follows a standard structure; use of a standard format makes comparison between such statements simpler. A user or manufacturer trying to determine if two DICOM devices will communicate to suit a particular application can compare the conformance statements side by side. This process does not guarantee that the two devices will communicate properly, but obvious problems, such as one device not supporting the service needed by the other, can be caught. The engineer familiar with DICOM should be able to ascertain the compatibility of the two applications.
The contents of the conformance statement include (a) the implementation model of the application; (b) the presentation contexts to be used; (c) the manner in which associations are to be handled; (d) the SOP classes to be supported; (e) the communication profiles to be used; and (f) any extension, specialization, or privatization to be used.
The conformance statement must describe how an activity handles associations (ie, whether the activity initiates associations and accepts multiple associations) for each activity in the model. Some devices, such as the archives in a picture archiving and communication system, must support multiple associations if performance is to be acceptable. Otherwise, only a single activity (eg, DICOM storage) could be handled at any given time.
The list of SOP classes supported is one of the key aspects of the conformance statement. This list describes which service classes and information objects will be offered and accepted by the application. By understanding the SOP class, the reader of the conformance statement will be able to judge whether two conformance statements are describing applications that "match" (ie, if the presentation contexts [and therefore the SOP classes] offered by one application match those accepted by the other). If not, it is very unlikely that the two applications will operate together successfully, even if other aspects of conformance do match.
The communication profile used simply states which of the DICOM-supported communications stacks is used. Those available are the point-to-point, the ISO (an implementation of the ISO-OSI standards), and the transmission control protocol/Internet protocol (TCP/IP) stacks. Sections particular to the communications stack chosen are included.
The final part of a conformance statement details any extension to or specialization or privatization of SOP classes. Extension of an SOP class means the addition of standard attributes that are not mandatory but that the creator of the SOP class may use in a particular application. In effect, an extended SOP class is a superset of a standard SOP class, and most applications will not have difficulties handling it. A specialized SOP class has mandatory or conditional standard attributes added to it. A specialized SOP class may also contain private attributes that the creator of the SOP class considers mandatory. A private SOP class conforms to the structure of a standard SOP class but may contain completely private attributes. Neither specialized nor private SOP classes use the DICOM-defined UIDs, whereas the extended SOP class uses the UID of the standard SOP class on which it is based. Specialized and private SOP classes may cause problems for applications that try to interpret them unless the applications are designed to do so. The reason for such SOP classes is to allow manufacturers and other implementers to use the DICOM structure for their own purposes where there is no intent or need to communicate with these SOP classes outside their own equipment. The use of specialized and private SOP classes was never intended as a way to circumvent the DICOM standard. The pharmaceutical package insert familiar to physicians is analogous to the conformance statement. Just as the insert gives in standard format information such as the chemical structure, origin and nature, indicated uses, and adverse effects of the contents of the package, the DICOM conformance statement provides the engineering information about an implementation.
Because the conformance statement enumerates all that DICOM applications have to do or define, anyone wishing to gain a deeper understanding of DICOM would do well to read the part of the standard on conformance (PS 3.2) after reading the introduction (PS 3.1).