Multi Energy CT (MECT) - Proposal

1. Proposed Work Item: Multi Energy CT (MECT)

• Proposal Editor: Steven Nichols Steven Nichols
• Proposal Contributors: DICOM WG-21
• Profile Editor: Steven Nichols, Till Hoenig
• Profile Contributors: DICOM WG-21
• Domain: Radiology

Summary

Multi-energy CT relies on proprietary private attributes and lacks vendor-independent platforms with a standardized approach to image display. Multi-energy datasets are reconstructed and viewed separately; making it time consuming for the reviewer to page through energy levels for a given anatomic location. DICOM has developed vendor-independent CT modules for encoding enhanced and classic multi-energy images, as well as a blending presentation state that can be used to save and reproduce color overlay images. A multi-energy CT profile could standardize elements of image encoding and display to reduce reliance on proprietary workstations and applications for routine multi-energy review. DICOM workgroup 21 developed initial informational content in Supplement 188 intended to standardize multi-energy CT workflow, however this was not formalized in the final draft. Workgroup 21 remains interested in continuing this work and is willing to participate in the development of an IHE profile. The IHE process has the potential to engage users and vendors to establish baseline functionality for multi-energy display. This can be used to establish upstream image encoding requirements. The additional ability to expand upon underlying multi-energy concepts within a profile can help educate image display vendors on critical elements of multi-energy CT display and workflow.

2. The Problem

Commercial multi-energy CT solutions were established prior to the development of Supplement 188. These relied on a combination of private attributes and dedicated display applications to address user needs for image display.
For example²:

As multi-energy CT has become increasingly more routine, demand has also increased to present multi-energy CT studies on general radiology PACS displays. This profile will help make multi-energy display features more commonly available.

3. Key Use Case

A patient undergoes a multi-energy CT study in which various energy data sets are reconstructed. Depending on the indications for the exam, additional retrospective reconstructions may be created after the study is complete. All data sets are networked to the image manager/archive. Relevant prior CT studies are pre-fetched for comparison. Comparison studies are potentially classic monoenergetic or multi-energy, from a different vendor or model CT scanner, and may be from a different institution. The interpreting radiologist requires that the current and prior studies be displayed with the additional features required to properly display multi-energy objective, material quantification and material visualization images without resorting to the need for an acquisition-vendor-specific proprietary workstation. When interrogating the multi-energy images, the radiologist may examine the same image at various energies, apply color overlay to differentiate materials (e.g. to demonstrate separation of uric acid and calcifications) and apply a ROI or point measurement reporting the real-world value of a pathological feature. A presentation state is created to save the color palate, blending and annotations applied during image review. A few months later, at an external facility, the virtual monoenergetic images are imported into a legacy display system that supports the Enhanced CT SOP class, however this system does not recognize the study as multi-energy. The images are properly labeled, providing an indication to the reviewer that CT pixel values in virtual monoenergetic images are different from those in conventional CT images, avoiding confusion or misinterpretation.

4. Standards & Systems

DICOM CT Image Storage SOP Class DICOM Enhanced CT SOP Class DICOM Blending Softcopy Presentation State SOP Class

5. Technical Approach

Actors

• Acquisition Modality
• Image Archive
• Image Display

Transactions

• Modality Images Stored [RAD-8]
  • DICOM CT Image Storage SOP Class
  • DICOM Enhanced CT SOP Class
    • Define multi-frame dimension for the Image Display to sort images for a hanging protocol
• Retrieve Images [RAD-16]
  • Add attributes displayed and display functionality
• Blending Presentation States Stored [RAD-57]

Profile

Content to be developed

• Define viewing features required and reach user / vendor consensus.
• Identify any additional DICOM attributes for display.
• Identify dimensions for multi-frame objects.

Impact on existing integration profiles

• None

Decisions/Topics/Uncertainties

• Establish a minimum set of Image Display viewing features required by users.
• Reaching a vendor consensus for multi-frame dimensions.

6. Support & Resources

• DICOM Workgroup 21
• Currently soliciting user input through DICOM Workgroup 21
• References

1. Mahesh, M. Why is DECT not used widely?.
2. Thiravit, S. Building a dual-energy CT service line in abdominal radiology.

7. Risks

• User participation to develop a minimum set of display features and establish a boundary between image display and post processing. If there are several users involved, reaching a consensus could pose a challenge. To help mitigate this risk, Multi-energy image types and families will be limited to those described in DICOM Part 17

User Questions

• What would your workflow look like without proprietary software?
• What would your PACS hanging protocol look like?
• What DICOM multi-energy attributes do you need to see on the image as an overlay (e.g. Material Code Sequence, Photon Energy)?
  • Are there other DICOM attributes that you don’t need as an overlay, but would like to see in a pop-up window?
• What functions are a must-have on your PACS (e.g. color blending, ROI)?
  • What functions are nice-to-have (e.g. plot, histogram)?

• If a vendor consensus cannot be reached for multi-frame dimensions due to equipment differences, or prospective vs retrospective image reconstruction workflow, this can be included in the profile as a concept section.

8. Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>

Effort Evaluation (as a % of Tech Cmte Bandwidth):

• xx% for MUE
• yy% for MUE + optional

Editor:

TBA

<Delete this Category Templates line since your specific Profile Proposal page is no longer a template.>