DICOM Validator - dciodvfy

Getting dciodvfy and dcentvfy ...

• dciodvfy and dcentvfy are included in the dicom3tools source code package
  
• a Windows executable version of dciodvfy and dcentvfy can be found here
  
• a Mac OS X executable version of dciodvfy and dcentvfy can be found here
  
• see also the description of the dicom3tools package
  

What are dciodvfy and dcentvfy ...

Unix, Mac and Windows command line utilities for validating the contents of a DICOM file against the DICOM standard.

Features ...

• Checks attributes in file against requirements of IODs and Modules defined in DICOM PS 3.3 Information Object Definition (dciodvfy)


• Checks encoding of data elements and values against encoding rules of the DICOM PS 3.5 Data Structures and Encoding (dciodvfy)


• Checks data element value representation and multiplicity against data dictionary in DICOM PS 3.6 Data Dictionary (dciodvfy)


• Checks consistency of attributes in multiple files that are supposed to be the same for the same entity in all instances (dcentvfy)

Notes ...

• The dciodvfy tool does not check for consistency between multiple files (e.g., consistent values of Study or Series level attributes. Use dcentvfy for that.


• The dciodvfy tool does not check for compliance of behavior of network transactions; it only works with DICOM Datasets that are Composite Instances stored in files.


• Some of the warnings and errors may be subject to interpretation, particularly where the DICOM standard is vague, or ambiguous, or in the process of being corrected.


• Some of the warnings and errors may seem extremely if not excessively picky, or even beyond what is defined in the standard. This is particularly true of warnings that values are implausible or unlikely (such as 0), or creative attempts to determine real world conditions (such as laterality being dependent on a paired body part, or the body part being supposedly "unknown").


• Some of the reported errors and warnings may be spurious, particularly when conditions described in the DICOM standard depend on "real world" information that is not derivable from the DICOM Dataset itself.


• The dciodvfy tool will not detect every error that may be present, particularly those that depend on complex relationships between attributes in different sequences.


• The results of running dciodvfy on the same data may change in future revisions, as the tool incorporates more thorough checks based on experience as well as corrections and additions to the DICOM standard.

FAQ ...

• Are dciodvfy and dcentvfy an officially recognized or supported tool for certifying DICOM compliance?
  • 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.


• Is a file that passes dciodvfy and dcentvfy with no errors or warnings guaranteed to be 100% DICOM compliant?
  • No. There may be errors that dciodvfy and dcentvfy do not detect.


• Is a file that passes dciodvfy with no errors or warnings guaranteed to "work"?
  • 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.


• Is a file that fails dciodvfy with errors or warning guaranteed not to "work" ?
  • 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.


• What should I do if I encounter an instance that dciodvfy reports to have significant errors or warnings?
  • Contact the vendor of the equipment that created and/or modified the instance (e.g., both the modality and the PACS vendors).


• What should I do if a vendor claims that errors or warnings "don't matter", or that dciodvfy is "wrong", or that dciodvfy is not detecting errors?
  • 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).
• What does dcentvfy do?
  • 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.

Interpreting the output ...

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".

• What is the significance of an "Unrecognized defined term" warning?
  • 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.


• What is the significance of the "Missing attribute or value that would be needed to build DICOMDIR" warning?
  • 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.


• What is the significance of the "Value dubious for this VR - Retired Person Name form" warning?
  • 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.


• How do I interpret errors and warnings related to the Laterality attribute?
  • 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 known to be paired, and also when it is present (zero length or not) if the body part is not specified or is specified and is known to be paired. 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.


• What is the significance of the "Attribute present when condition unsatisfied (which may not be present otherwise)" error?
  • 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.


• What is the significance of the "Value invalid for this VR - UI - Leading zeroes" error?
  • 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.


• What is the significance of the "Attribute is not present in standard DICOM IOD" and "Dicom dataset contains attributes not present in standard DICOM IOD - this is a Standard Extended SOP Class" warnings?
  • 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.


• What is the significance of warnings about "Retired" Attributes?
  • 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.


• What is the significance of warnings and errors related to "Group Length" Attributes?
  • 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.


• How do I interpret errors and warnings related to the Pixel Aspect Ratio attribute?
  • 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).


• What is the significance of the "Value is zero" warning?
  • 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.


• What is the significance of warnings about inconsistent values of Pixel Spacing and Imager Pixel Spacing related to calibration?
  • 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.
• How do I interpret dcentvfy errors and warnings related to different values for the same attribute or missing attributes in different instances?
  • 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.
• How do I interpret dcentvfy warnings about the same attribute having different information entities?
  • 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.
• How do I interpret dcentvfy warnings that mention an "unknown" information entity?
  • 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.

END