ITKv4 DICOM Communications Discussion: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
(Discussion page to get ideas on how DICOM Q/R functionality will be used)
 
Line 15: Line 15:
== Storage ==
== Storage ==
== Query/Retrieve ==
== Query/Retrieve ==
DICOM provides a simple mechanism to query a PACS system for imaging information and receive the results.  Instead of a full SQL-style syntax, a set of "Key Attributes" are passed to the server.  These attributes are encoded as a DICOM Data Set.  There are four levels of information that may be queried:  PATIENT, STUDY, SERIES, IMAGE (instance).  Each level defines specific Required and Optional keys that may be queried, as well as a required "Unique" key that identifies a single entity at the desired query level.  For each entity that matches all of the keys in the query, the server sends back a set of attributes with the specific results.
DICOM provides a simple mechanism to query a PACS system for imaging information and receive the results.  Instead of a full SQL-style syntax, a set of "Key Attributes" are passed to the server.  The request attributes and results are encoded as DICOM Data Sets.  There are four levels of information that may be queried:  PATIENT, STUDY, SERIES, IMAGE (instance).  Each level defines specific Required and Optional keys that may be queried, as well as a required "Unique" key that identifies a single entity at the desired query level.  If an empty (length=0) tag is added, it is treated like a wildcard.  For each entity that matches all of the keys in the query, the server sends back a set of attributes with the specific results.


For Instance, a common query is to ask the PACS for all the exams related to a specific patient.  We want to pass in the tag that specifies a Study Level Query.  We'll add in the Patient ID that we're searching forAnd we'll request to get back the Study Description, Study Date, and Modality:
For Instance, a common query is to ask the PACS for all the exams related to a specific patient.  A typical SQL statement would look like this:
 
<pre>
select PATIENT.PatientID, STUDY.StudyDate, STUDY.ModalitiesInStudy, STUDY.StudyDescription
from  PATIENT, STUDY
where  PATIENT.PatientID = "99999"
and    STUDY.Patient_fk = PATIENT.pk</pre>
 
For a DICOM request, we want to issue a "Patient Root" query and pass in the tag that specifies we want Study Level information.  We'll have to add in the Patient ID tag with its value filled inThen to request the Study Description, Study Date, and Modality fields to be returned, we add these tags to the request but give each an empty value.  This all gets assembled into a Data Set as follows:


{| border="1" cellpadding="5" cellspacing="0"
{| border="1" cellpadding="5" cellspacing="0"
Line 36: Line 44:
|(0010,0020) || PatientID || 99999
|(0010,0020) || PatientID || 99999
|}
|}
<br>
Each response comes back as a separate Data Set with all the fields filled in:


{|
{|

Revision as of 14:17, 5 August 2010

Use this page to discuss and capture scenarios for using DICOM Query/Retrieve (Q/R) to load images from source (PACS) systems.

Scenarios

  • 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. Are there plans to add this functionality to GDCM?
  • DCMTK contains the code needed for DICOM communications. It is currently not integrated into the ITK toolkit. Should it be?

Service Classes

Verification

Storage

Query/Retrieve

DICOM provides a simple mechanism to query a PACS system for imaging information and receive the results. Instead of a full SQL-style syntax, a set of "Key Attributes" are passed to the server. The request attributes and results are encoded as DICOM Data Sets. There are four levels of information that may be queried: PATIENT, STUDY, SERIES, IMAGE (instance). Each level defines specific Required and Optional keys that may be queried, as well as a required "Unique" key that identifies a single entity at the desired query level. If an empty (length=0) tag is added, it is treated like a wildcard. For each entity that matches all of the keys in the query, the server sends back a set of attributes with the specific results.

For Instance, a common query is to ask the PACS for all the exams related to a specific patient. A typical SQL statement would look like this:

select PATIENT.PatientID, STUDY.StudyDate, STUDY.ModalitiesInStudy, STUDY.StudyDescription
from   PATIENT, STUDY
where  PATIENT.PatientID = "99999"
and    STUDY.Patient_fk = PATIENT.pk

For a DICOM request, we want to issue a "Patient Root" query and pass in the tag that specifies we want Study Level information. We'll have to add in the Patient ID tag with its value filled in. Then to request the Study Description, Study Date, and Modality fields to be returned, we add these tags to the request but give each an empty value. This all gets assembled into a Data Set as follows:

DICOM Q/R Request
Tag Meaning Value
(0008,0020) StudyDate
(0008,0052) QueryRetrieveLevel STUDY
(0008,0061) ModalitiesInStudy
(0008,1030) StudyDescription
(0010,0020) PatientID 99999


Each response comes back as a separate Data Set with all the fields filled in:

Response 1
Tag Meaning Value
(0008,0020) StudyDate 20050106
(0008,0052) QueryRetrieveLevel STUDY
(0008,0061) ModalitiesInStudy CR
(0008,1030) StudyDescription Chest-- PA & Lateral
(0010,0020) PatientID 99999
Response 2
Tag Meaning Value
(0008,0020) StudyDate 20000322
(0008,0052) QueryRetrieveLevel STUDY
(0008,0061) ModalitiesInStudy CR
(0008,1030) StudyDescription Chest-PICC
(0010,0020) PatientID 99999
Response 3
Tag Meaning Value
(0008,0020) StudyDate 20000307
(0008,0052) QueryRetrieveLevel STUDY
(0008,0061) ModalitiesInStudy CR
(0008,1030) StudyDescription Hip 3+vw THA Series (Post Op)
(0010,0020) PatientID 99999

C-FIND

TODO: The query may be rooted at the Patient or Study Level. ...