ITKv4 DICOM Communications Discussion

Use this page to discuss and capture scenarios for DICOM support in ITK, including but not limited too using DICOM Query/Retrieve (Q/R) to load images from source (PACS) systems.

Scenarios for DICOM communication

• User wants to query a PACS system for a particular series. The user only knows the Patient ID, Date of Exam and Series Description to look for. Ultimately, the user wants this loaded in memory as an ITK Image object.

Standards

Most of the documentation for Verification, Storage and Query/Retrieve functionality can be found in Part 4 of the DICOM Standard.

Toolkits

• GDCM is currently used for DICOM File I/O. At this time it does not support the communications aspects of DICOM, such as StoreSCU/StoreSCP, C-FIND, C-MOVE, etc.
  • Bill (ryan): Are there plans to add this functionality to GDCM?
  • Alex: yes, this is part of the current itk-v4 funded effort and mathieu has a working prototype / design in the git repository listed below
  • steven and steve: do not duplicate effort. Do not look over years of debugging testing thattook place in DCMTK.
  • all: agreed, let's have a standard API that allow reusing whichever lib has the correct fonctionality.
  • bill L: let's have a network API in ITK as the IO API won t suffice for that.
• DCMTK contains the code needed for DICOM communications. It is currently not integrated into the ITK toolkit.
  • Bill (ryan): Should it be?
  • Alex: is the license compatible?
    • Alex: the global licence is not: DCMTK Licencing
    • steven and mathieu: you can recompile most of the DCMTK lib for it to be BSD.
    • steven: in perticular, the communication nugget comes from CTN and should not pause any problem.
  • Alex: Is it compiling on all the platforms ITK is supposed to compile on?
    • Alex: they claim to. We would need to set up dashboards (anyone?).
  • Alex: Is it small enough to be packaged and delivered along side with ITK?
    • Bill: It is huge! So, maybe ITK should access it as an optional ExternalProject?
      • DCMTK has adopted CMake for its build process
      • CTK is accessing DCMTK as an ExternalProject
      • ExternalProject is a relatively new feature in CMake that allows CMake to git/svn/cvs checkout a project and build it, during the build process of the parent project.
    • we might not need to integrate/recompile everything

Service Classes

Verification

The Verification class uses the C-ECHO service to verify that an endpoint is alive and accepting DICOM requests. This is similar to a ping request for TCP/IP.

Storage

The C-STORE service is used to store DICOM images. To receive images, the system is set up as a Service Class Provider (SCP). The device sending the images is set up as a C-STORE Service Class User (SCU).

Query/Retrieve

The Query/Retrieve (Q/R) class is used to find images on a server and request them to be sent to a destination.

For an explanation of how to use DICOM to query a PACS, please see this page: DICOM_QueryRetrieve_Explained

Early design

To clear things, an initial implementation has been uploaded to github as a started:

• http://github.com/malaterre/ITKDICOM

Bill (Ryan) comments

C-MOVE functionality is definitely critical to a working DICOM implementation. The C-GET mechanism is not always provided by the PACS systems, so we need to offer a C-MOVE request to get the images.

In order to retrieve images from a PACS, we'll have to provide mechanisms (new classes?/MetaDataDictionary?) for collecting the query parameters and holding the responses back from the server. A user might want to query by PatientID or PatientsName, maybe for a particular Modality, and possibly for a given StudyDate. Obviously, we'll want to provide the capability to query at any of the Query Levels, at both the Patient Root and Study Root Q/R Information Models. From the results, the user can extract the appropriate Patient ID or various UID's needed to drill down to the lower levels.

It may be difficult at times to know when we've received all the images from a series. What if the user fetches an entire study? Should there be a local store of images or should it all be received into memory? In the end, using ITK to read files from PACS should be as simple as reading images from a directory. I

In the past we've used the DCMTK toolkit to provide the DICOM communications layer. We were planning to use that as well for ITK, unless GDCM already provides that functionality.