Example messages for C-FIND and C-MOVE requests

Query messages in the Healthcare: Web service to DICOM pattern specify their search criteria using DICOM tags. The DICOM standard defines the tag names, their meaning and permissible values. At each query root and level, one tag is defined as unique (U). A single value in a unique tag uniquely identifies a single entity at that level. That is, two entities at the same level do not have the same unique tag value. C-FIND SCPs support existence and matching of all unique tags defined by DICOM. All entities managed by C-FIND SCPs must have a specific non-zero length unique tag value.

Each DICOM query root and level has a small set of required (R) tags which every DICOM vendor must support. Required tags imply the SCP of a C-FIND must support matching based on a value contained in a C-FIND request. Multiple entities may have the same value for required tags. That is, a distinct value in a required tag does not necessarily identify a single entity at the level of the key. C-FIND SCPs support existence and matching of all required tags defined at a given root and level. If a C-FIND SCP manages an entity with a tag of zero length, the value is considered unknown and all matching against the zero length tag is considered a successful match.

There are a much larger set of optional (O) tags which DICOM vendors might support. Vendors are free to add additional tags supported in the search criteria. Optional tags contained in a C-FIND request may have three different types of behaviour depending on support for existence and/or matching by the C-FIND SCP. Firstly, if the C-FIND SCP does not support the existence of an optional tag, then the tag is not returned in a C-FIND response. Secondly, if the SCP supports the existence of an optional tag but does not support matching on the tag, then the tag is processed in the same manner as a zero length required tag. That is, the value specified to be matched for the tag is ignored but a value may be returned by the SCP in the response message. Finally, if the SCP supports the existence and matching of the tag, then the tag is processed in the same manner as a required tag.

DICOM has many options for describing C-FIND search criteria, particularly around wild cards, date and time ranges, and matching multiple values in a list. Please refer to PS3.4 of the DICOM standard for more information. The DICOMFindMove node does not currently support matching on sequences. An XML query message to the DICOMFindMove node may request additional return tags. These tags are not used for search criteria in the C-FIND request to the SCP. If the return tag is supported by the SCP, response messages contain a matching value for each search tag and a value for each return tag.

The following example shows an XML query message with two search tags of 00100010 (PatientName) and 00080050 (AccessionNumber), and an additional return tag configured of 00080054 (RetrieveAETitle):

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>STUDY</QueryRoot>
    <QueryLevel>STUDY</QueryLevel>
    <Match>
        <Attribute Tag="00100010">FEROVIX</Attribute>
        <Attribute Tag="00080050">1210490</Attribute>
    </Match>
    <Return>
        <Attribute Tag="00080054"/>
    </Return>
</DICOM:FindMove>

Query messages can specify their search criteria using the tag name (for example, PatientID) or the tag (00100020). The tag name is generally easier to understand and less error prone than using the tag. As shown below, response messages always use the DICOM tag.

The following example shows a DICOM C-FIND results message with the SOAP response envelope removed:

<DICOM:Results xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <DICOM>
        <Attribute Tag="00080005" VR="CS">ISO_IR 100</Attribute>
        <Attribute Tag="00080016" VR="UI">1.2.840.10008.5.1.4.1.1.2</Attribute>
        <Attribute Tag="00080018" VR="UI">1.3.12.2.1107.5.1.4.54023.30000004093016410718700003864</Attribute>
        <Attribute Tag="00080052" VR="CS">IMAGE</Attribute>
        <Attribute Tag="00080054" VR="AE">PACS</Attribute>
        <Attribute Tag="00080056" VR="CS">ONLINE</Attribute>
        <Attribute Tag="0020000D" VR="UI">1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021</Attribute>
        <Attribute Tag="0020000E" VR="UI">1.3.12.2.1107.5.1.4.54023.30000004093016410718700003676</Attribute>
        <Attribute Tag="00200013" VR="IS">188</Attribute>
        <Attribute Tag="00880130" VR="SH"/>
        <Attribute Tag="00880140" VR="UI"/>
    </DICOM>
</DICOM:Results>

The meaning of each DICOM tag in the results message is shown in the table below:

Tag Name Value
00080005 SpecificCharacterSet ISO_IR 100
00080016 SOPClassUID 1.2.840.10008.5.1.4.1.1.2
00080018 SOPInstanceUID 1.3.12.2.1107.5.1.4.54023.30000004093016410718700003864
00080052 QueryRetrieveLevel IMAGE
00080054 RetrieveAETitle PACS
00080056 InstanceAvailability ONLINE
0020000D StudyInstanceUID 1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021
0020000E SeriesInstanceUID 1.3.12.2.1107.5.1.4.54023.30000004093016410718700003676
00200013 InstanceNumber 188
00880130 StorageMediaFileSetID
00880140 StorageMediaFileSetUID

Important!

Make sure you configure the QueryRoot and QueryLevel elements correctly in your XML request messages. Use the examples in this topic as a reference for each combination of patient root and query level.

C-MOVE commands

C-MOVE request messages are set up exactly the same as C-FIND request messages. The only difference is the inclusion of a MoveDestination element in the XML query message. This move destination is the application entity title where the DICOM instances should be moved to using C-STORE commands. The PACS which processes the C-FIND and C-MOVE commands must be pre-configured with the connection details of the move destination.

The following example shows a DICOM C-FIND and C-MOVE request message with a MoveDestination specified:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>PATIENT</QueryRoot>
    <QueryLevel>STUDY</QueryLevel>
    <MoveDestination>REMOTEAE</MoveDestination>
    <OperationPriority>NORMAL</OperationPriority> 
    <Match>
        <Attribute Tag="PatientID">fWT0KTL</Attribute>
        <Attribute Tag="AccessionNumber">1210490</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>

The OperationPriority is an optional field in the XML request message. If is vendor dependent whether the field is honoured or not. The field can take the values HIGH, NORMAL or LOW.

SOAP response messages from the pattern are returned after the C-MOVE command has completed. The response may therefore take some time if large studies, series or images are moved. The response messages also include an XML element called MoveResults which describes the overall success, or otherwise, of the C-MOVE command. The detailed status fields in the response message are shown below (Completed, Failed and Warnings).

<DICOM:Results xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <DICOM>
        <Attribute Tag="00080005" VR="CS">ISO_IR 100</Attribute>
        <Attribute Tag="00080016" VR="UI">1.2.840.10008.5.1.4.1.1.2</Attribute>
        <Attribute Tag="00080018" VR="UI">1.3.12.2.1107.5.1.4.54023.30000004093016410718700003864</Attribute>
        <Attribute Tag="00080052" VR="CS">IMAGE</Attribute>
        <Attribute Tag="00080054" VR="AE">PACS</Attribute>
        <Attribute Tag="00080056" VR="CS">ONLINE</Attribute>
        <Attribute Tag="0020000D" VR="UI">1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021</Attribute>
        <Attribute Tag="0020000E" VR="UI">1.3.12.2.1107.5.1.4.54023.30000004093016410718700003676</Attribute>
        <Attribute Tag="00200013" VR="IS">188</Attribute>
        <Attribute Tag="00880130" VR="SH"/>
        <Attribute Tag="00880140" VR="UI"/>
        <MoveResults>
            <Completed>1</Completed>
            <Failed>0</Failed>
            <Warnings>0</Warnings>
        </MoveResults>
    </DICOM>
</DICOM:Results>

Patient root

The patient root allows four levels of query: patient, study, series and image.

Patient root / patient level

The patient level query is used to query a PACS for patients. It has a small number of permissible attributes which can be used in the query, such as the patient name, patient sex and birth date.

The following table shows the search tags available for a patient level query:

Name Tag Type
PatientName 00100010 R
PatientID 00100020 U
IssuerOfPatientID 00100021 O
PatientBirthDate 00100030 O
PatientBirthTime 00100032 O
PatientSex 00100040 O
OtherPatientIDs 00101000 O
OtherPatientNames 00101001 O
EthnicGroup 00102160 O
PatientComments 00104000 O
NumberOfPatientRelatedStudies 00201200 O
NumberOfPatientRelatedSeries 00201202 O
NumberOfPatientRelatedInstances 00201204 O

The following example shows a patient level query with the PatientID (00100020) used as the search criteria:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>PATIENT</QueryRoot>
    <QueryLevel>PATIENT</QueryLevel>
    <OperationPriority>NORMAL</OperationPriority> 
    <Match>
        <Attribute Tag="00100020">fWT0KTL</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>

The following example shows a patient level query with PatientBirthDate used as the search criteria:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>PATIENT</QueryRoot>
    <QueryLevel>PATIENT</QueryLevel>
    <OperationPriority>NORMAL</OperationPriority> 
    <Match>
        <Attribute Tag="PatientBirthDate">19670227</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>
Patient root / study level

The study level query is used to query a PACS for the studies for a given patient. The study level query must include the patient ID and zero or more optional tags to further refine the search, such as the study date.

The following table shows the search tags available for a study level query:

Name Tag Type
StudyDate 00080020 R
StudyTime 00080030 R
AccessionNumber 00080050 R
StudyID 00200010 R
StudyInstanceUID 0020000D U
ModalitiesInStudy 00080061 O
SOPClassesInStudy 00080062 O
ReferringPhysicianName 00080090 O
StudyDescription 00081030 O
NameOfPhysicianReadingStudy 00081060 O
ReferringPhysicianName 00080090 O
AdmittingDiagnosesDescription 00081080 O
PatientAge 00101010 O
PatientSize 00101020 O
PatientWeight 00101030 O
Occupation 00102180 O
AdditionalPatientHistory 001021B0 O
OtherStudyNumbers 00201070 O
NumberOfStudyRelatedSeries 00201206 O
NumberOfStudyRelatedInstances 00201208 O

The following example shows a study level query with the PatientID (00100020) and AccessionNumber (00080050) used as the search criteria:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>PATIENT</QueryRoot>
    <QueryLevel>STUDY</QueryLevel>
    <OperationPriority>NORMAL</OperationPriority> 
    <Match>
        <Attribute Tag="00100020">fWT0KTL</Attribute>
        <Attribute Tag="00080050">1210490</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>

The following example shows a study level query with PatientID used as the search criteria:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>PATIENT</QueryRoot>
    <QueryLevel>STUDY</QueryLevel>
    <OperationPriority>NORMAL</OperationPriority> 
    <Match>
        <Attribute Tag="PatientID">fWT0KTL</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>
Patient root / series level

The series level query is used to query a PACS for the series within a specific study. The series level query must include the study UID and zero or more optional attributes to further refine the search, such as the modality.

The following table shows the search tags available for a series level query:

Name Tag Type
Modality 00080060 R
SeriesNumber 00200011 R
SeriesInstanceUID 0020000E U
NumberOfSeriesRelatedInstances 0020,1209 O

The following example shows a series level query with the StudyInstanceUID (0020000D) used as the search criteria:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>PATIENT</QueryRoot>
    <QueryLevel>SERIES</QueryLevel>
    <OperationPriority>NORMAL</OperationPriority> 
    <Match>
        <Attribute Tag="0020000D">1.2.840.113745.101000.1008000.37796.6311.5221360</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>

The following example shows a series level query with StudyInstanceUID and Modality used as the search criteria:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>PATIENT</QueryRoot>
    <QueryLevel>SERIES</QueryLevel>
    <OperationPriority>NORMAL</OperationPriority> 
    <Match>
        <Attribute Tag="StudyInstanceUID">1.2.840.113745.101000.1008000.37796.6311.5221360</Attribute>
        <Attribute Tag="Modality">CT</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>
Patient root / image level

The image level query is used to query for specific images in a series. It is little used. An image level query must include the series UID.

The following table shows the search tags available for an image level query:

Name Tag Type
InstanceNumber 00200013 R
SOPInstanceUID 00080018 U
SOPClassUID 00080016 O
RelatedGeneralSOPClassUID 0008001A O
ContainerIdentifier 00400512 O

The following example shows an image level query with the SeriesInstanceUID (0020000E) used as the search criteria:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>PATIENT</QueryRoot>
    <QueryLevel>IMAGE</QueryLevel>
    <OperationPriority>NORMAL</OperationPriority> 
    <Match>
        <Attribute Tag="0020000E">1.3.12.2.1107.5.1.4.50146.4.0.2320790629191549</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>

The following example shows an image level query with SeriesInstanceUID used as the search criteria:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>PATIENT</QueryRoot>
    <QueryLevel>IMAGE</QueryLevel>
    <OperationPriority>NORMAL</OperationPriority> 
    <Match>
        <Attribute Tag="SeriesInstanceUID">1.3.12.2.1107.5.1.4.50146.4.0.2320790629191549</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>

Study root

The study root is similar to the patient root, and this similarity often causes confusion. There is no patient level query in the study root. The first supported level is the study level query. The study level query has a larger set of permissible attributes which can be used. Supported search critera include the study date, study time, and also attributes of a patient such as the patient name, patient ID and patient sex. This study level query can therefore be considered a merging of the study and patient level queries from the patient root.

The study level query is very useful because in one go you can query for all the studies of a patient given some basic search criteria like patient name and study date. The patient root separates this into two separate queries.

The series level and image level queries are identical in the study root and the patient root.

Study root / study level

The following table shows the search tags available for a study level query:

Name Tag Type
StudyDate 00080020 R
StudyTime 00080030 R
AccessionNumber 00080050 R
PatientName 00100010 R
PatientID 00100020 R
StudyID 00200010 R
StudyInstanceUID 0020000D U
ModalitiesInStudy 00080061 O
SOPClassesInStudy 00080062 O
ReferringPhysicianName 00080090 O
StudyDescription 00081030 O
NameOfPhysicianReadingStudy 00081060 O
AdmittingDiagnosesDescription 00081080 O
IssuerOfPatientID 00100021 O
PatientBirthDate 00100030 O
PatientBirthTime 00100032 O
PatientSex 00100040 O
OtherPatientIDs 00101000 O
OtherPatientNames 00101001 O
PatientAge 00101010 O
PatientSize 00101020 O
PatientWeight 0010,1030 O
EthnicGroup 00102160 O
Occupation 00102180 O
AdditionalPatientHistory 001021B0 O
PatientComments 00104000 O
OtherStudyNumbers 00201070 O
NumberOfPatientRelatedStudies 00201200 O
NumberOfPatientRelatedSeries 00201202 O
NumberOfPatientRelatedInstances 00201204 O
NumberOfStudyRelatedSeries 00201206 O
NumberOfStudyRelatedInstances 00201208 O

The following example shows a study level query with the PatientID (00100020) and AccessionNumber (00080050) used as the search criteria:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>STUDY</QueryRoot>
    <QueryLevel>STUDY</QueryLevel>
    <Match>
        <Attribute Tag="00100010">FEROVIX</Attribute>
        <Attribute Tag="00080050">1210490</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>

The following example shows a study level query with PatientID and AccessionNumber used as the search criteria:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>STUDY</QueryRoot>
    <QueryLevel>STUDY</QueryLevel>
    <OperationPriority>NORMAL</OperationPriority> 
    <Match>
        <Attribute Tag="PatientName">FEROVIX</Attribute>
        <Attribute Tag="AccessionNumber">1210490</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>
Study root / series level

The series level query is used to query a PACS for the series within a specific study. The series level query must include the study UID and zero or more optional attributes to further refine the search, such as the modality. This level is exactly the same as the series level in the patient root except the QueryRoot in the XML query message is set to STUDY instead of PATIENT.

The following table shows the search tags available for a series level query:

Name Tag Type
Modality 00080060 R
SeriesNumber 00200011 R
SeriesInstanceUID 0020000E U
NumberOfSeriesRelatedInstances 0020,1209 O

The following example shows a series level query with the StudyInstanceUID (0020000D) used as the search criteria:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>STUDY</QueryRoot>
    <QueryLevel>SERIES</QueryLevel>
    <OperationPriority>NORMAL</OperationPriority> 
    <Match>
        <Attribute Tag="0020000D">1.2.840.113745.101000.1008000.37796.6311.5221360</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>

The following example shows a series level query with StudyInstanceUID and Modality used as the search criteria:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>STUDY</QueryRoot>
    <QueryLevel>SERIES</QueryLevel>
    <OperationPriority>NORMAL</OperationPriority> 
    <Match>
        <Attribute Tag="StudyInstanceUID">1.2.840.113745.101000.1008000.37796.6311.5221360</Attribute>
        <Attribute Tag="Modality">CT</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>
Study root / image level

The image level query is used to query for specific images in a series. It is little used. An image level query must include the series UID. This level is exactly the same as the image level in the patient root except the QueryRoot in the XML query message is set to STUDY instead of PATIENT.

The following table shows the search tags available for an image level query:

Name Tag Type
InstanceNumber 00200013 R
SOPInstanceUID 00080018 U
SOPClassUID 00080016 O
RelatedGeneralSOPClassUID 0008001A O
ContainerIdentifier 00400512 O

The following example shows an image level query with the SeriesInstanceUID (0020000E) used as the search criteria:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>STUDY</QueryRoot>
    <QueryLevel>IMAGE</QueryLevel>
    <OperationPriority>NORMAL</OperationPriority> 
    <Match>
        <Attribute Tag="0020000E">1.3.12.2.1107.5.1.4.50146.4.0.2320790629191549</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>

The following example shows an image level query with SeriesInstanceUID used as the search criteria:

<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
    <QueryRoot>STUDY</QueryRoot>
    <QueryLevel>IMAGE</QueryLevel>
    <OperationPriority>NORMAL</OperationPriority> 
    <Match>
        <Attribute Tag="SeriesInstanceUID">1.3.12.2.1107.5.1.4.50146.4.0.2320790629191549</Attribute>
    </Match>
    <Return>
    </Return>
</DICOM:FindMove>

Back to the Healthcare: Web service to DICOM pattern specification