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. DIOM COmmunication is also sometimes called DICOM Protocol, or PACS support.
which toolkit - Common DICOM API
GDCM
GDCM 1.x is currently used for DICOM File I/O in ITK. ITK V4 alpha will within a couple of week include gdcm 2.x. 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 is not appropriate for that.
DCMTK
DCMTK contains the code needed for DICOM communications but lack other features like support for JPEG 2000 or other compression scheme supported by the DICOM standard. It is currently not used by 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
- Bill: It is huge! So, maybe ITK should access it as an optional ExternalProject?
CTN
CTN is still alive (commit done on Jun 29 2010):
Project is at:
License is: License: Apache License V2.0 Ref:
Others Toolkits / libs
New and better libs could appear in the 10 years lifetime of itk 4 that we might want to use. It is yet another argument in favor of a common third-lib agnostic DICOM API in ITK.
DICOM Communication specific discussion
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.
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 for GDCM
To clear things, an initial implementation has been uploaded to github as a starting point:
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.
how to test against PACS automatically ?
( thanks to Steve Pieper)
I had a chance to ask Lawrence Tarbox of Washington University your question about dicom testing. Lawrence is a participant in CTK and a long-time dicom standards participant too (he's actually working on the hosted application specification, which we should ultimately be compatible with). For PACS-like testing, he pointed to two well established efforts, linked below. Lawrence knows people involved in these and thinks they might be receptive to seeing integration with ctest and cdash if you want to pursue that. In any case I think we can learn a lot from these efforts. http://www.ihe.net/Connectathon/ (look for the MESA test suite) http://www.dvtk.org/
Contestants
Setting up a dcm4che server:
Discussion about how to handle non-image data in ITK pipeline
GDCM Milestone
user case for pacs
- copy to disk for caching and many other reasons.
