Unix, Mac and Windows command line utilities for validating the contents of a DICOM file against the DICOM standard.
No. Neither the DICOM Standards Committee nor MITA (NEMA) have any official tool or certification mechanism. The dciodvfy tool is used in IHE Connectathons, along with other tools like DVTK, as an aid in establishing success or failure.
No. There may be errors that dciodvfy and dcentvfy do not detect.
No. This is both because dciodvfy may not detect all errors, and because DICOM compliance alone may not be sufficient to satisfy the expectations for any particular application. E.g., the standard may permit anatomical or orientation information to be absent, but the user expects the images to be hung on the display in anatomical order.
No. Many receiving applications are tolerant of significant errors in DICOM objects, so instances created by a particular device fail to validate but still be accepted by a PACS or displayed by a viewer. However, failure to comply with the standard, and to pass validation by dciodvfy, significantly increases the chance that other applications will have trouble with the instances.
Contact the vendor of the equipment that created and/or modified the instance (e.g., both the modality and the PACS vendors).
Contact me, and send me a copy of the offending instances and the communications with the vendor. I will either fix the tool, explain why the tool is in error, or explain why the vendor is in error. If necessary, in the last case, I can escalate the matter within the vendor through channels that may not be available through normal site support (such as the vendor's representatives to the DICOM Standards Committee).
The dcentvfy utility checks a bunch of files to see if all patient attributes are the same for a single patient (the same Patient ID), all study attributes are the same for a single study (the same Study Instance UID, and all series attributes are the same for a single series (the same Series Instance UID), as well as checking that there are no duplicate SOP Instance UIDs.
Hopefully, most messages reported by dciodvfy and dcentvfy should be self explanatory. In general, they are highly specific with respect to the problem, reporting for example, errors when a required (Type 1) Attribute is missing or an illegal Enumerated Value is present, or an Attribute has the wrong Value Representation, or has incorrectly encoded values, such as being too long, or containing too many values or containing illegal characters within values. Such errors are serious and rarely is there any excuse for the implementer in such circumstances. However, some errors and warnings require a little more explanation and/or interpretation in order to understand why they are occurring and whether or not they "matter".
Though the standard allows implementers to send alternative values than those in the standard when there is nothing suitable, in general this warning may be an indicator of a genuine problem, and certainly an indicator that the value being sent will not be interoperable, since it is not defined in the standard. For example, if an implementer sends a value of "THORAX" for Body Part Examined, they are actually in error, since they should be sending the standard value "CHEST", but the dciodfy tool has no way of detecting this "error" other than by warning that the value is unrecognized. Similarly, if a vendor is using coded terminology, and a Coding Scheme Designator other than one of the known standard ones is encountered, whilst the implementer may be legitimately using a "private coding scheme" (e.g. "99IHE"), chances are good that they have actually just made a mistake. In general, all "Unrecognized defined term" warnings should be investigated and either explained satisfactorily or corrected. Ideally, a list of the non-standard Defined Terms should be found in the implementer's DICOM Conformance Statement.
A number of identifying Attributes, such as Patient ID, are defined as Type 2 in Composite Instances, which means that they be empty (zero length), if unknown. However, by the time that the instances are recorded on interchange media with a DICOMDIR, all such Attributes are expected to have values supplied (e.g., by reconciliation with the RIS or PACS), and in the DICOMDIR they are therefore Type 1. This warning means that it will not be possible to construct a valid DICOMDIR from the Composite Instance, at least not without making up dummy values for these Attributes or obtaining values from elsewhere.
DICOM permits, but does not require, that person names be encoded as components separated by caret (^) delimiters; i.e., it is preferred that "Doe^John" be used, rather than "John Doe" or "Doe, John" or any other such informal variant. This warning is present to remind operators and implementers to use the preferred form.
The older DICOM objects expect a Laterality attribute at the Series level, which is expected to be present only if the images are of an paired body part, such as an arm or a leg, as opposed to an unpaired body part, such as an abdomen or chest. The only values permitted are "R" and "L" or zero length if unknown, and the Attribute is expected to be absent otherwise. This means that the implementer is not supposed to send a zero length value for an unpaired body part, but rather to send nothing. However, in many cases the sending device does not know what the body part is (or is too lazy to ask the operator for it, or the operator is too lazy to enter it). Regardless, dciodvfy will complain when the attribute is absent if the body part is unknown or if it is not known to be unpaired, and also when it is present (zero length or not) if the body part is not specified or is specified and is not known to be unpaired.
The presence or absence of the Laterality attribute when it is expected or not is reported as an error, not a warning, since it depends on the general mechanism of attribute condition checking used throughout, which always reports errors when conditional required attributes (those that are Type 1C or 2C) are not present if required, or are present if not required and "may be present otherwise" is not specified.
More modern objects use Image or Frame Laterality instead, which specifically allow "U" unpaired and "B" for both paired parts, and in such cases Laterality is required not to be present.
Conditional Attributes for which the presence of a value is meaningless when the condition is unsatisfied are listed in DICOM without the phrase "may be present otherwise". It is, strictly speaking, an error to send the Attribute under such circumstances, even if it is sent zero length (without a value), which would be illegal for Type 1C rather than 2C Attributes anyway.
Unique Identifiers in DICOM are encoded as strings, but the meaning of the period-separated numeric values from which they are constructed are intended to be interpreted as numbers, not strings. Thus a component "001" should mean the same as "1". In order to ensure that string comparison of UID values has exactly the same meaning as a more complex numeric comparison, the DICOM standard insists that leading zeroes not be used.
Most value representations for DICOM elements have limited set of characters that are permitted. For example (default and "-new" formats shown):
Error - Value invalid for this VR - (0x0008,0x0008) CS Image Type CS [1] = <ORIGINAL/PRIMARY> - Character invalid for this VR = '/' (0x2f)
Error - </ImageType(0008,0008)[1]> - Value invalid for this VR [CS] = <ORIGINAL/PRIMARY> - Character invalid for this VR = '/' (0x2f)
Sometimes this is caused by failing to limit the characters a user may enter in an input field, or incorrectly using a forward slash rather than a backslash as the delimter between multiple values. The consequence is that a receiver may fail to use the value at all, fail to display it correctly or insert it in the database correctly, or fail to match the value against expected values (especially for Code Strings). Occasionally, an incorrect character will cause a recipient that does not defend itself against this type of error to throw an expception or crash (e.g., if the unexpected character is included literally in a SQL statement and not removed or escaped).
The dicom3tools do not properly support multi-byte character sets and ISO 2022 escape sequences, however, so occasionally spurious errors of this type may be reported when such character sets are in use.
All DICOM data elements are required to be encoded with an even length. Most string DICOM elements are required to be padded with a SPACE character, and NOT a null (0x00) character, with the exception of the UI VR. For example:
Error - Value invalid for this VR - (0x0002,0x0013) SH Implementation Version Name SH - Trailing character invalid for this VR = '' (0)
In general, this error has little impact on recipients, largely as a consequence of the null character being the normal C++ string terminator, but may occasionally cause problems with string matching. The same cannot be said of an embedded null character, however, in which case the string will often be prematurely terminated by the recipient.
Most value representations for DICOM elements have a finite length, and if this length is exceeded then receivers may truncate the encoded values, or in rare cases, fail entirely. An example would be incorrectly allowing the precision of a decimal string value to exceed the length limit of 16, which results in a message like:
Error - Value invalid for this VR - (0x0020,0x0032) DS Image Position (Patient) DS [2] = <77.60000000000001> - Length invalid for this VR = 17, expected <= 16
The consequence of this type of error is that numeric values may be shown with different values, and string values may not match or be displayed as expected, particularly when they are truncated during database insertion.
All DICOM elements have a value representation defined in the data dictionary. This may be explicitly encoded in the dataset that is transferred, or implicit, in which case the recipient needs a dictionary in order to interpret the values. The explicit form is preferred, but is not the default on the network, but is required on media. That said, if the explicit form is used, and the VR does not match the data dictionary, then the recipient does not know what to do with the value, and may need to discard or ignore it. For example:
(0x0008,0x002a) DT Acquisition Date Time - Warning - Explicit value representation doesn't match data dictionary; Explicit <DA> Dictionary <DT>
Also, the data dictionary contains not only the standard (DICOM-defined) data elements, but many private data elements derived from published DICOM Conformance Statements as well as observation of explicit VRs encountered in images and other objects. Sometimes a vendor will not use a consistent VR for a particular data element in different products and software versions, and these warnings will be encountered. For example, vendors may be inconsistent in their use of SL versus UL, or use SH, LO and CS interchangeably, or use IS and DS, for the same data element. In some cases where the VR has been "guessed" from samples, this warning will be encountered when the guess was wrong (e.g., a guess of US with a VM of 1-n versus a single UL).
Another trigger for this warning will be when the object has been previously encoded from an implicit VR dataset and the encoder did not have the data element in their dictionary, and used a VR of UN, or a VR of OB, as a surrogate for UN.
Though DICOM allows implementers to add "extra" Attributes to an object, using standard Data Elements, as long as they do not change their meaning, this is not always a good idea, since it may not be at all clear what the presence of these extra Attributes actually means, and worse, their presence may change the interpretation of other Attributes and cause receivers to misbehave. The classic example of the latter is adding rescale values to an MR image, something that is not defined by the standard, but which does cause the interpretation of the window values to be changed, causing some viewers to fail to display the images properly. Also, these warnings may be the only indication of an encoding error by the implementer, such as nesting attributes at the wrong level of the dataset, e.g., Code Value or related attributes at the top level of the dataset rather than nested within a Code Sequence Item. One other problem caused by such attributes is that they may not be removed by some programs during de-identification or anonymization for clinical trials or teaching files or service support, leading to leakage of privacy-related information. A classic example would be the Patient's Telephone Number.
Many Attributes used in the old ACR-NEMA standards were not used in DICOM; additionally, other Attributes were specified in DICOM but have since been retired, either because they were never used, or they were used inappropriately and had to be replaced or corrected, or were used in entire IODs that were replaced or retired. In general, the presence of retired Attributes in an instance is undesirable since whatever the implementer is trying to accomplish with them is either incorrect or subject to interpretation and unlikely to be interoperable.
In ACR-NEMA, Attributes were grouped into "Groups" and there was some significance attached to those Groups, and the length of each Group was explicitly encoded before the start of the Group. This is no longer the case, and indeed the presence of such Group Length Attributes can cause significant problems if a Dataset is edited in a manner that changes the length of a value but does not correctly update the corresponding Group Length Attribute for that Group. Ideally, most modern implementations do not send Group Lengths in the first place, and if present, remove them. The warnings about retired or undesirable Group Lengths serve to indicate the potential for this problem. Regardless, any Group Length that is present is checked by dciodvfy against the actual length, and in the event that it is wrong, an error will be reported, since such an error may render the Dataset unparsable.
Pixel Aspect Ratio is only intended to be used when pixels are non-square and when there is no information specifiying the actual size of the pixels. This means that errors will be reported when Pixel Spacing, Imager Pixel Spacing and similar attributes are present at the same time as Pixel Aspect Ratio. Also, an error will be reported when the Pixel Aspect Ratio is 1:1. The presence of this Attribute is probably harmless if the information contained is redundant and not inconsistent with the spacing information. In practice, it is also very unusual to encounter non-square pixels (i.e., genuine circumstances in which the Pixel Aspect Ratio Attribute would be appropriate).
When the DICOM Standard expects that a value is important for the application, it makes it Type 1; this means that a value shall be sent, and that there is no allowance for the possibility that it is unknown or unobtainable. The implementer shall provide a value. Unfortunately, some implementers then try to circumvent this be sending "dummy" values, typically a value of zero for numeric Attributes. This warning is an indication that it is highly unlikely that the implementer is sending a legitimate zero value (e.g., the kVP for an X-Ray is never zero) and is almost certainly just deliberately violating the standard.
For cross-sectional images (like CT and MR), the Pixel Spacing attribute has always conveyed the distance within the patient between the centers of pixels. It is possible to make distance measurements between pixels using this Attribute. For projection images, like XA, CR or DX, since the actual distance within the patient cannot be known due to the diverging X-Ray beam and the consequent magnification, a new Attribute was added that corresponds to measuring distance on a film, Imager Pixel Spacing. Unfortunately, historically, since some viewers only used Pixel Spacing, regardless of the modality or SOP Class, modality implementers started to send either Pixel Spacing instead of or in addition to Imager Pixel Spacing. Whilst this was not strictly correct, as long as the values were the same, there was no safety issue. However, some vendors then started "correcting" or "calibrating" the value in Pixel Spacing by some unknown and unspecified means, presenting a dilemma for the recipient trying to measure distance or match against orthopedic templates, etc. Pixel Spacing Calibration Type was added to the standard to address this, but is often not sent. Accordingly, dciodvfy warns whenever the values in Pixel Spacing do not match those in Imager Pixel Spacing and Pixel Spacing Calibration Type is not present. Note that as a general rule, performing distance measurements on digital projection radiographs without some sort of fiducial within the image of known size to calibrate against is potentially unsafe.
E.g. (default and "-new" formats shown):
Warning - CodingSchemeDesignator is deprecated - attribute <CodingSchemeDesignator> = <SNM3>
Warning - </SharedFunctionalGroupsSequence(5200,9229)[1]/FrameAnatomySequence(0020,9071)[1]/AnatomicRegionSequence(0008,2218)[1]/CodingSchemeDesignator(0008,0102)[1]> - CodingSchemeDesignator is deprecated = <SNM3>
When this is related to a SNOMED CT code, there was a major change to all the codes to use the new numeric code rather than the historic SNOMED RT style code. Many archived DICOM objects and older products that produce DICOM images will use the old style-codes and trigger this warning. Ideally new products should use the new codes, but may elect to still use the old codes to be compatible with older recipients. The rationale of DICOM CP 1850 discusses the pros and cons of this unavoidable change.
In addition, even for the older SNOMED RT style code, the Coding Scheme Designator evolved over time and include 99SDM, SNM3 and SRT.
Any such error or warning may be a violation of the standard, but some (for example different values of Body Part
Examined, a Series level attribute, within the same Series, or different values of Study Time, a Study
level attribute, within the same Study) are less significant in that they may not affect database behavior
or browser information, whereas others (for example different values of Modality, a Series level attribute,
with the same Series, or different values of Patient's Name for the same Patient ID), may have significant consequences, depending on the way the receiving software obtains
information presented in queries and browsers. In the worst case, such inconsistencies will cause receivers
to reject images entirely. Some receivers may detect such inconsistencies and flag the entire study for manual reconciliation, compromising automated workflow.
In the best case, if the attribute is significant to the user for finding or interpreting a particular
image (e.g., by Laterality, Body Part Examined or View Position), then such inconsistencies may be a source
of considerable irritation.
Sometimes the reported error or warning will be a consequence of a difference in encoding
or precision of a value (e.g., "73" versus "73.0", or "Smith^Jones^^" versus "Smith^Jones") and whilst some of these may be
semantically harmless they may still result in inconsistent application behavior.
Another related type of warning is when an attribute for an entity like Patient, Study or Series is present or has zero length value in some instances but not
others (e.g., Patient's Birth Date); this type of inconsistency is often caused by post-processing software
that generates new Series that populate the higher level entries like Study and Patient with a different
pattern, or when screen shots, presentation states or structured reports or CAD results are saved.
A "flaw" in the design of the DICOM standard is that occasionally the same attribute may be used for different entity levels in different IODs. For example, View Position is at the Series level in CR images and the Image level in DX images, so if both types of image are present in the same study or series then this warning will be reported. The tool does not attempt to compare values in such circumstances. In practice, robust implementations need to assume the "lowest" entity level amongst the choices possible if persisting this information in a database.
If attributes occur in different instances with different IODs (SOP Classes), and that attribute is not defined in the standard for one of them, but has been added by the implementer (as a so-called "Standard Extended SOP Class"), then the IE for the additional non-standard use of the attribute will be indicated as an "unknown" IE, and the values will not be compared. Note that dciodvfy will warn about the presence of these additional attributes.
Comments, criticism and general abuse are greatly appreciated and should be directed to dclunie@dclunie.com.