C-FINDhow a viewer searches the archive
Before you can retrieve a study you have to find it. C-FIND is the DICOM query: the client sends an "identifier" with the values it knows and empty fields for what it wants back, and the PACS streams the matches.
- DICOM
- Internal action
- Dashed = reply
Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.
A-ASSOCIATE-RQ for Query/Retrieve FIND
Core stepWhat happens
The workstation opens an association and proposes the FIND SOP Class for the query model it uses. Most systems use Study Root; Patient Root is the older alternative.
Why it is needed
The SOP Class sets which levels you can query (Study Root: study, series, image) and so which attributes are allowed in the identifier.
Technical details
- Study Root FIND 1.2.840.10008.5.1.4.1.2.2.1
- Patient Root FIND 1.2.840.10008.5.1.4.1.2.1.1
- Transfer syntax: Implicit VR Little Endian is enough (identifiers are small)
A-ASSOCIATE-AC
ConfirmationWhat happens
The PACS accepts the context. Many PACS only allow queries from known AE titles, because a query exposes patient names.
Why it is needed
A rejection or refused context here is an access or configuration problem, not a problem with the query itself.
Technical details
- Context result 0 = accepted
- Context result 3 = FIND model not supported by this PACS
C-FIND-RQ with the identifier
Core stepWhat happens
The client sends the query. The identifier lists the attributes to match, with a value, and the attributes it wants back, left empty. The Query/Retrieve Level says whether it is asking about studies, series or images.
Why it is needed
This is the whole question in one object. A well-formed identifier keeps the answer small: asking for all studies with no keys can return millions of rows.
Technical details
- (0000,0100) CommandField = 0020
- (0008,0052) QueryRetrieveLevel = STUDY
- (0010,0020) PatientID = 12345678 (matching key)
- (0008,0020) StudyDate = 20260101-20260131 (range)
- (0010,0010) PatientName = SMITH* (wildcard)
- (0008,0050) AccessionNumber = (empty) (return key)
- (0020,000D) StudyInstanceUID = (empty) (return key)
The PACS matches against its database
Key detailWhat happens
The PACS compares the matching keys with its records, using DICOM matching rules: single value, list of UIDs, wildcard (* and ?), date or time range. For every record that matches it fills in the return keys.
Why it is needed
The query never touches pixel data, so it is fast. The rules explain why an empty value means "return this" and not "match empty".
Technical details
- Empty value = universal matching, and the attribute is returned
- Wildcards * and ? apply to string types such as PN and LO, not to UIDs
- Ranges use a hyphen: 20260101-20260131
- Unsupported optional keys are ignored (the SCP may flag this with status FF01)
C-FIND-RSP Pending, one per match
Core stepWhat happens
For every match the PACS sends one response with status Pending and an identifier with the requested values. This step repeats once per match: ten matching studies means ten responses.
Why it is needed
Streaming the matches lets a client show results as they arrive. Pending is not an error. The client must keep reading until it sees the final response.
Technical details
- (0000,0100) CommandField = 8020
- (0000,0900) Status = FF00 (pending) or FF01 (pending, optional keys not supported)
- Data set = identifier with the values of one match
- The client may stop early by sending C-CANCEL-FIND-RQ
Final C-FIND-RSP, Success
ConfirmationWhat happens
After the last match, the PACS sends a final response with status Success and no data set. If nothing matched, this is the only response.
Why it is needed
This marks the end of the result list. Zero pending responses followed by success simply means no match, which is a valid answer.
Technical details
- (0000,0900) Status = 0000
- (0000,0800) CommandDataSetType = 0101 (no identifier)
- Failures: A900 identifier does not match SOP Class, Cxxx unable to process
- Cancelled by the client: FE00
A-RELEASE
ConfirmationWhat happens
The client releases the association, or keeps it open to run the next query, for example a series-level query for one of the studies found.
Why it is needed
A typical retrieval is a query first (this lesson) followed by a C-MOVE or C-GET of the chosen study.
Technical details
- A-RELEASE-RQ (0x05) / A-RELEASE-RP (0x06)
All steps at a glance
Glossary
- SCU
- Service Class User. The side that asks for a service, such as a scanner that wants to store images.
- SCP
- Service Class Provider. The side that provides the service, such as a PACS that stores images.
- SOP Class
- Service-Object Pair class. A UID naming one kind of object plus the service used on it, e.g. CT Image Storage (1.2.840.10008.5.1.4.1.1.2).
- Status
- A 16-bit code in every DIMSE response (0000,0900). 0000 is success, FE00 is cancel, FF00 and FF01 are pending, 0001, Bxxx, 0107 and 0116 are warnings, and Axxx, Cxxx, 01xx and 02xx (the others) are failures.
- UID
- A globally unique identifier made of numbers and dots, used for SOP Classes, transfer syntaxes, studies, series and instances.
- Identifier
- The data set sent with a C-FIND or C-MOVE request or response. It holds the keys to match or the values returned.
Summary
- C-FIND is the search step of Query/Retrieve. It lists; it does not move any image.
- The identifier mixes matching keys (with a value) and return keys (empty).
QueryRetrieveLevel (0008,0052)selects PATIENT, STUDY, SERIES or IMAGE. - Each match is one
C-FIND-RSPwith statusFF00(pending). A final0000ends the list. - Study Root (
1.2.840.10008.5.1.4.1.2.2.1) is the usual model. Patient Root is older. - Limit the query. Unbounded queries load the PACS database and return huge lists.
The 7 steps in plain text
A-ASSOCIATE-RQ for Query/Retrieve FIND
The workstation opens an association and proposes the FIND SOP Class for the query model it uses. Most systems use Study Root; Patient Root is the older alternative.
Why: The SOP Class sets which levels you can query (Study Root: study, series, image) and so which attributes are allowed in the identifier.
A-ASSOCIATE-AC
The PACS accepts the context. Many PACS only allow queries from known AE titles, because a query exposes patient names.
Why: A rejection or refused context here is an access or configuration problem, not a problem with the query itself.
C-FIND-RQ with the identifier
The client sends the query. The identifier lists the attributes to match, with a value, and the attributes it wants back, left empty. The Query/Retrieve Level says whether it is asking about studies, series or images.
Why: This is the whole question in one object. A well-formed identifier keeps the answer small: asking for all studies with no keys can return millions of rows.
The PACS matches against its database
The PACS compares the matching keys with its records, using DICOM matching rules: single value, list of UIDs, wildcard (* and ?), date or time range. For every record that matches it fills in the return keys.
Why: The query never touches pixel data, so it is fast. The rules explain why an empty value means "return this" and not "match empty".
C-FIND-RSP Pending, one per match
For every match the PACS sends one response with status Pending and an identifier with the requested values. This step repeats once per match: ten matching studies means ten responses.
Why: Streaming the matches lets a client show results as they arrive. Pending is not an error. The client must keep reading until it sees the final response.
Final C-FIND-RSP, Success
After the last match, the PACS sends a final response with status Success and no data set. If nothing matched, this is the only response.
Why: This marks the end of the result list. Zero pending responses followed by success simply means no match, which is a valid answer.
A-RELEASE
The client releases the association, or keeps it open to run the next query, for example a series-level query for one of the studies found.
Why: A typical retrieval is a query first (this lesson) followed by a C-MOVE or C-GET of the chosen study.
Common questions
What is a DICOM C-FIND?
A DIMSE-C service from the Query/Retrieve service class. The SCU sends an identifier (matching and return keys) and the SCP returns zero or more matching identifiers followed by a final success status. It is how viewers and workstations search a PACS.
What is the difference between C-FIND for Query/Retrieve and for Modality Worklist?
The mechanism is the same C-FIND service. Only the SOP Class and the identifier differ. Query/Retrieve queries the image archive; the Modality Worklist SOP Class (1.2.840.10008.5.1.4.31) queries scheduled orders so a modality can pick a patient.
Why do I get no results?
Common causes: a matching key that is too specific or in a different format (for example the PatientID or the wildcard), a date range that is off by a day, querying at the wrong level, or the PACS limiting what the calling AE title may see. A zero-match answer is a normal success (0000), not an error.
What does the pending status FF00 mean?
More responses may follow. Each FF00 response carries one match. The client must read responses until it receives a response whose status is not pending. FF01 also means pending, but warns that one or more optional matching keys were not supported.
How do I know which query keys a device supports?
The Conformance Statement lists them per SOP Class, with the matching type each key supports (single value, list of UIDs, wildcard, range, sequence or universal) and, for a query SCU, whether the value is fixed, generated, configured or typed by the user. Keys the SCP does not support are ignored, which can make a query return more than you expect.
Does C-FIND return images?
No. It returns identifiers only (attributes). To get the images use C-MOVE or C-GET with the StudyInstanceUID found by the query.