Existing Work

• David has collected all the data structure along with the basic conversion rules in PDF format

  • The scripts and the PDF can be found here.

• Example Multiframe MR objects from NEMA

Planning

Concept (3 Weeks)

• Conceptual work, ideas:
  • Select one or two use cases with QIICR team that should be solved in this project year.
  • Define data format and details of the steps the converter performs when converting, e.g.
    • collecting input images based on user input (which series/studies, filter based on SOP Class, ...)
    • getting all attributes from the images under conversion
    • check which image instances are not sufficient for conversion (partly user defined via profile, e.g. by specifying value requirements, limits, ... ?)
    • extract all attributes into a huge table (even SQL or non-SQL DB?)
    • check requirements (partly user-defined via profle?) applicable to whole image collection (e.g. minimum number of images, minimum number of images with a specific tag value, ...)
    • perform tag mappings within source data (as required by standard or desired by user)
    • (more checks?)
    • create destination dataset (Legacy Converted Enhanced MR)
    • perform conversion (copy input data to output data based on transformed input data, use conversion rules laid down in profile)
    • automatically derive dimensions and stacks based on patterns in the data
      • hard code or "description language" from user?
    • Depending on the use cases, think about the options and "levers" the user has to control and guide the conversion
      • those options can materialize in XML profile "directives", library/commandline options, XSLT scripts working on the XML profile or the extracted input data, ...?
    • Support private data
  • Toolchain

Profile Creation (4 Weeks)

• Generating the default profile(s) from the standard

Implementation of Basic Engine (4 Weeks)

• Implement the engine that performs the basic (without user-specific stuff, ie. tag mappings, limts,...) conversion based on the profile

Implementing User Customizations (2-6 Weeks)

• Code supporting the user customizations possible
  • effort depends on what we allow there

Implementing Dimension/Stack Generation (2-6 Weeks)

• Code for automatic generation of dimensions and stacks
  • depends on what we allow there
  • rules must be defined by experts,i.e. QIICR team

Publish to Upstream DCMTK (1 Week)

• Tidy things up and checkin into DCMTK master
• Release as part of a DCMTK snapshot

Bonus

• Bonus: If time and desired:
  • Bonus Functional Groups (not planned to be used in QIICR):
    • Pixel Value Transformation
    • Contrast/Bolus Usage
    • Respiratory Synchronization
  • Bonus Modules (not planned to be used in QIICR):
    • Enhanced Contrast/Bolus
    • Respiratory Synchronization
    • Bulk Motion Synchronization
    • Specimen
  • Dedicated reading API for Legacy Enhanced MR

Milestones

• TODO Date: Concept (3 weeks)
• TODO Date: Profile Creation (4 weeks)
• TODO Date: Implementation of Basic Engine (4 weeks)
• TODO Date: Implementing User Customizations (2-6 weeks)
• TODO Date: Implementing Dimension/Stack Generation (2-6 Weeks)
• TODO Date: Publish to Upstream DCMTK (1 Week)

Total efforts: 16-24 weeks

Use cases

BWH QIN project

A sample study is available here: http://slicer.kitware.com/midas3/folder/2182.

The series of interest are:

1. T2-weighted MR (axial, sagittal and coronal) - series 3-5. This one could be first milestone?
2. Diffusion-weighted MR (trace image) - series 7. This is a 4-d series with the 4th dimension being the b-value. b-value is stored in a private attribute. We have documentation of those private attributes in several location.
3. Dynamic contrast-enhanced MR - series 9. Here 4th dimension is time. Parsing of the 4th dimension is also vendor-/sequence-specific. We have those hacks coded in a Slicer plugin that we could reuse.

Open Questions

Open questions besides those noted above:

• Do we only need a convenient API to create the Legacy Converted Enhanced MR objects or also convenient getters() and setters() to access its data?
  • i.e. do we need an API like for existing modules in dcmiod and functional groups in dcmfg? In that case there is possible extra effort for adapting the existing code generator, and write the Legacy Converted Enhanced MR IOD class (only partially generated)
    • Missing modules in dcmiod: Clinical Trial Patient, Clinical Trial Study, Clinical Trial Series, MR Series, Contrast/Bolus, Cardiac Synchronization, Device, Enhanced MR Image
    • Missing functional groups in dcmfg: Referenced Image, Cardiac Synchronization, MR Image Frame Type, Unassigned Shared Converted Attributes, Unassigned Per-Frame Converted Attributes, Image Frame Conversion Source
• Perform DICOM hierarchy consistency checks? Patient info (ID, name, birth date, ...), Study info (UID, date, description, ...), Series level info, Image info like rows/cols, color model, bit depth, ...
• What are the issues with private data?
• More questions in PDF from David (see link at the top of the page)

Possible Discussion Topics 2017-01-19

• Which uses case(s) are most relevant for QIICR?