The goal of dcmqi is to help you use DICOM for storing the results of quantitative image analysis.
Why would you want to use DICOM for your analysis results?
You should use DICOM if you want to improve interoperability of your data, to enhance the ability to automatically find and use the data by the computational tools, as well as support reuse of your data by individuals. These goals are widely recognized as important in the scientific community [1].
To highlight some of the specific advantages of using DICOM for storing analysis data, below we annotate the FAIR (Findable, Accessible, Interoperable, Reusable) Guiding Principles [1] formalized by FORCE11, as applied to quantitative image analysis, describing how research formats help meet the FAIR requirements, and contrasting those with the functionality provided by DICOM.
While speaking of "research formats", we refer primarily to the formats commonly used by researchers developing quantitative image analysis tools. Examples include NRRD, MetaImage, NIfTI, and Analyze.
Notable example of a domain-specific solution proposed for data storage is Brain Imaging Data Structure (BIDS) being developed for neuroimaging applications. We are not aware of a domain-specific solution developed for cancer imaging.
| FAIR Guiding principle | Research formats | DICOM |
|---|---|---|
| To be Findable: | ||
| F1. (meta)data are assigned a globally unique and persistent identifier | usually not assigned | each object has a unique identifier |
| F2. data are described with rich metadata (defined by R1 below) | minimal metadata sufficient to solve specific task (e.g., image resolution and orientation) | metadata is stored in standardized attributes describing versatile aspects of the data (the subject being imaged, processing details, references to related objects, etc.) |
| F3. metadata clearly and explicitly include the identifier of the data it describes | metadata describing the subject may be stored separately from the analysis result, and cross-linked by means of file name or similar mechanism, creating opportunity for inconsistencies and errors | metadata is stored in the same object as the processing result |
| F4. (meta)data are registered or indexed in a searchable resource | problem-specific solutions | general-purpose search and indexing of DICOM data is supported by every Picture Archival and Communications System (PACS) using DICOM Query and Retrieve protocol, or using REST-based DICOMWeb protocol |
| To be Accessible: | ||
| A1. (meta)data are retrievable, by their identifier using a standardized communication protocol | problem-specific solutions | general-purpose retrieval of DICOM data is supported by every Picture Archival and Communications System (PACS) using DICOM Query and Retrieve protocol, or using REST-based DICOMWeb protocol |
| A1.1. the protocol is open, free, and universally implementable | no comparable protocols have been proposed and implemented in widely accessible solutions | yes |
| A1.2. the protocol allows for an authentication and authorization procedure, where necessary | no comparable protocols have been proposed and implemented in widely accessible solutions | DICOMWeb can be integrated with existing authentication protocols defined by other standards |
| A2. metadata is accessible, even when the data is no longer available | no | not applicable, since metadata is stored alongside the data in the same object |
| To be Interoperable: | ||
| I1. (meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation | domain-specific solutions | DICOM is a formal, accessible, shared and broadly used standard |
| I2. (meta)data use vocabularies that follow FAIR principles | domain-specific solutions | can reuse vocabularies defined elsewhere, relying often on the terminology defined by SNOMED-CT, UCUM, NCIt, FMA, and allows for integration with other vocabularies, including those defined by the user |
| I3. (meta)data includes qualified references to other (meta)data | usually, no | derived objects can include pointers to the datasets used in the derivation, including the purpose of reference |
| To be Reusable: | ||
| R1. (meta)data are richly described with a plurality of accurate and relevant attributes | usually, no | data attributes that need to be included for a specific object are defined by the standard, as a result of the community discussion and consensus process; the process of amending the standard is formalized and open |
| R2. (meta)data are released with a clear and accessible data usage license | not applicable; data usage license is selected by the data provider | not applicable; data usage license is selected by the data provider; the DICOM standard itself is available free of charge, and its implementation is not restricted by any licenses |
| R1.2. (meta)data are associated with detailed provenance | usually, no | composite context is preserved across imaging and derived datasets describing patient and acquisition details; provenance-related attributes are included, depending on the specific object type |
| R1.3. (meta)data meet domain-relevant community standards | domain-specific solutions | DICOM is the main standard in the medical imaging domain |
[1] Wilkinson et al. 2016. The FAIR Guiding Principles for scientific data management and stewardship. Scientific data 3:160018. DOI: 10.1038/sdata.2016.18.
No.
DICOM is the international standard for biomedical images and image-related information.
Widespread use of DICOM in clinic has led to a common mis-conception that DICOM is only suitable for storing clinical images. DICOM applications are not restricted to clinical use only. The standard defines objects for storing image and image-related data, which are perfectly suitable to support imaging research.
DICOM supports a wide range of biomedical applications, including preclinical, veterinary and small animal imaging. Preclinical small animal imaging was introduced to the standard in 2015, see Supplement 187 Preclinical Small Animal Imaging Acquisition Context.
Most common types of DICOM objects are those produced by the clinical imaging equipment: Computed Tomography (CT), Magnetic Resonance Imaging (MRI) or ultrasound (US) image objects.
Some of the examples of image-related information that can be stored using DICOM include:
- radiation therapy dose, encoding dose distribution calculated by radiotherapy planning systems;
- radiation therapy structure set, containing contours of patient structures derived from images;
- segmentation image, which describes a classification of pixels in one or more referenced images;
- parametric map image, which contains pixels derived by the analysis of image data;
- measurements derived from an area in the image.
dcmqi provides tools to convert into standardized representation for the types of image-derived data produced in quantitative imaging research.
dcmqi does not support conversion to/from DICOM RT-STRUCT objects.
DICOM RT-STRUCT is a type of DICOM object that found wide adoption in the radiation therapy community to store the planar contours of the anatomical structures prepared for the purposes of radiation dose planning. Due to the large installation base of radiation therapy planning tools and history of their usage, there are large amounts of image data annotated with DICOM RT-STRUCT contours.
Many of the segmentation algorithms produce classification of image voxels, and thus do not naturally suit the representation by means of planar contours, requiring extra conversion operation and a potential for information loss. DICOM Segmentation image encodes classification of individual image voxels directly, and is thus more natural fit for voxel-based segmentation results.
We do not support RT-STRUCT, since there are established dedicated tools and libraries for handling DICOM RT-STRUCT, with some of the most notable examples include SlicerRT extension of 3D Slicer, Plastimatch, and CERR.
In our view, there is no need for yet another implementation of RT-STRUCT conversion to and from research formats.
We also note that although reporting of measurements for an image region defined by RT-STRUCT is supported by DICOM TID1500 Structured report, we currently do not implement direct support for this in dcmqi. We may consider adding this functionality in the future.
Users that have a need to report measurements over RT-STRUCT should first convert RT-STRUCT into a rasterized representation stored in an ITK-readable research format using any of the tools mentioned above, and then convert the result into DICOM Segmentation image using dcmqi. The measurements reported over the region defined by the Segmentation image can then be stored as a DICOM TID1500 Structured report.
The research formats we support are specific to the type of the object being converted, as summarized in the table below.
| Object type | Supported research formats | DICOM object |
|---|---|---|
| Segmentation image | All research volumetric image formats supported by the Insight Toolkit (ITK): NRRD, MetaImage, NIfTI, Analyze; extra metadata is communicated using JSON and constrained by JSON-Schema. | DICOM Segmentation Image |
| Parametric map image | All research volumetric image formats supported by the Insight Toolkit (ITK): NRRD, MetaImage, NIfTI, Analyze; extra metadata is communicated using JSON and constrained by JSON-Schema. | DICOM Parametric map |
| Volumetric measurements | Both measurements and associated metadata should be described using JSON and constrained by JSON-Schema. We are are planning to add support for CSV as input format in the future. | DICOM TID1500 Structured Report |
Below is the list of various tools that are used by medical imaging researchers, and description of how they relate to dcmqi:
- Insight Toolkit - does not provide tools for conversion of DICOM objects supported by
dcmqi.dcmqiuses ITK as a lower-level component for reading and writing research formats, and for image data operations. - DCMTK, GDCM - provide attribute- and SR tree-level C++ API for interacting with DICOM data; provide general-purpose command line tools for converting DICOM objects into human-readable list of attribute, and editing individual attributes of a DICOM dataset; do not provide tools for generating DICOM objects from research formats.
dcmqiis using DCMTK as the lower-level component to operate on DICOM data. - PixelMed Toolkit - provides attribute- and module-level Java API for interacting with DICOM objects; does not provide conversion tools for generating DICOM Segmentation image objects, Parametric maps, or volumetric measurements reports from research formats
- dicom3tools - provides attribute-level C API for interacting with DICOM objects, and general-purpose DICOM editing tools that can be used to change individual attributes of the dataset. Does not provide conversion tools for generating DICOM Segmentation image objects, Parametric maps, or volumetric measurements reports from research formats
- pydicom - provides attribute-level Python API for interacting with DICOM objects; does not provide conversion tools for generating DICOM Segmentation image objects, Parametric maps, or volumetric measurements reports from research formats
- 3D Slicer - provides interactive application to load and process DICOM data; includes
dcmqias an extension; usesdcmqito perform conversion of the objectsdcmqisupports. - ePAD - provides interactive application to visualize and annotate DICOM data; by design, does not provide conversion tools; uses
dcmqito perform conversion of DICOM TID1500 SR objects supports; uses attribute-level API of PixelMed to implement support of DICOM Segmentation objects and DICOM Parametric maps. - CERR - a software platform for developing and sharing research results in radiation therapy treatment planning. Supports DICOM RT-STRUCT annotation format. Does not support DICOM Segmentation image, Parametric map, or volumetric measurements.
dcmqi is intended for research work and has no FDA clearances or approvals of any kind. It is the responsibility of the user to comply with all laws and regulations (and moral/ethical guidelines) when using dcmqi.
Make sure you install the Quantitative Reporting extension.
Image-derived objects, such as segmentations or parametric map, inherit some of the attributes from the image they were derived from. Such attributes include, for example, those from the "General Study" and "Patient" modules. In the situation where some of those attributes that are mandatory, but are not present in the source images, converter will fail. The reason for this is that the converter will not write out an invalid object, and a valid object cannot be constructed when mandatory attributes are missing.
To resolve this situation, you can patch the source image to add the missing attributes. To do such patching we recommend the DCMTK dcmodify tool.
As an example, here is an error that would be generated by the itkimage2segimage converter when a mandatory "CodingSchemeDesignator" attribute is missing in the source DICOM image:
W: CodingSchemeDesignator (0008,0102) absent in CodeSequenceMacro (type 1)
1 of 512 slices mapped to source DICOM images
Found 3 label(s)
Skipping label 0
Processing label 1
Total non-empty slices that will be encoded in SEG for label 1 is 512
(inclusive from 0 to 512)
Processing label 2
Total non-empty slices that will be encoded in SEG for label 2 is 512
(inclusive from 0 to 512)
E: CodingSchemeDesignator (0008,0102) absent in CodeSequenceMacro (type 1)
E: Could not write item #0 in ProcedureCodeSequence: Missing Attribute(s)
FATAL ERROR: Writing of the SEG dataset failed! Please report the problem to the developers, ideally accompanied by a de-identified dataset allowing to reproduce the problem!
ERROR: Conversion failed.
Examining the content of the source image, indeed this attribute is missing, but is mandatory:
(0008,1032) SQ (Sequence with explicit length #=1) # 72, 1 ProcedureCodeSequence
(fffe,e000) na (Item with explicit length #=3) # 64, 1 Item
(0008,0100) SH [M2197] # 6, 1 CodeValue
(0008,0103) SH [0] # 2, 1 CodingSchemeVersion
(0008,0104) LO [BWH MR PELVIS WWO CONTRAST M2197] # 32, 1 CodeMeaning
To fix this issue, the following command can be used:
dcmodify -i "ProcedureCodeSequence[0].CodingSchemeDesignator=99UNKNOWN" 000000.dcm
Note the "99" prefix used for the coding scheme designator. Unless you know which coding scheme the specific code belongs to, you should always use this prefix to indicate that the coding scheme is "private" (not one of the coding schemes defined for use in the DICOM standard).
The way 3D Slicer works at the moment is that you cannot scroll over the slices of the segmentation unless your segmentation is accompanied by the image that was segmented.
Try importing the DICOM image you segmented into the Slicer DICOM database, and load both the segmentation and image series.
If you agree this behavior is confusing, add your voice to this discussion on 3D Slicer forum.