ITKv4 DICOM Communications Discussion: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
No edit summary
Line 1: Line 1:
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.
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 =
= which toolkit - Common DICOM API =
Line 85: Line 85:


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.
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.
= other requests from the community =
== handling of RT (steven) ==
* (steven, please flesh out with details of what you'd like)
* note that there should be a dataset of cardiac CT on the webpage of osirix we could use.
* included in cosmo's proposal
== handling of higher order manifold as described in DICOM standard ==
* included in cosmo proposal
== handling of DICOMDIR format disk archives (navneeth) ==
* Unlike a standard dicom series (located in a single directory) the DICOMDIR format spreads files across directories
* A reader that reads the DICOMDIR file and parses appropriate files & directories is desirable

Revision as of 04:22, 22 April 2011

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 and DCMTK

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

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.