ITKv4 DICOM Communications Discussion: Difference between revisions
Wryan mayo (talk | contribs) (Discussion page to get ideas on how DICOM Q/R functionality will be used) |
Wryan mayo (talk | contribs) m (→Query/Retrieve) |
||
| 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. | 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. | 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 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: | |||
{| 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:
| 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 |
| ||||||||||||||||||
| Response 2 |
| ||||||||||||||||||
| Response 3 |
|
C-FIND
TODO: The query may be rooted at the Patient or Study Level. ...
