The DIMSE-C C-FIND service is the operation by which relevant patient information is queried and provided.
Key Attributes in the Request Identifier serve two purposes. They may be used as Matching Key Attributes and Return Key Attributes. Matching Key Attributes may be used for matching (criteria to be used in the C-FIND request to determine whether an entity matches the query). Return Key Attributes may be used to specify desired return Attributes (what elements in addition to the Matching Key Attributes have to be returned in the C-FIND response).
Matching Key Attributes may be of Type "required" (R) or "optional" (O). Return Key Attributes may be of Type 1, 1C, 2, 2C, 3 as defined in PS3.5.
Two peer DICOM AEs implement this Relevant Patient Information Query Service Class with one serving in the SCU role and one serving in the SCP role. The SOP Class is implemented using the DIMSE-C C-FIND service as defined in PS3.7.
Only a baseline behavior of the DIMSE-C C-FIND is used in this Service Class.
A C-FIND service conveys the following semantics:
The SCU requests that the SCP perform a match for the Matching Keys and return values for the Return Keys that have been specified in the Identifier of the request, against the Relevant Patient Information that the SCP possesses.
In this Annex, the term "Identifier" refers to the Identifier service parameter of the C-FIND service as defined in PS3.7.
The SCP generates a C-FIND response for at most one match with an Identifier containing the values of all Matching Key Attributes and all known Return Key Attributes requested. The response contains one relevant patient information instance in the form that matches the Template that was requested. This response shall contain a status of Pending.
When the process of matching is complete, with zero or one match, a C-FIND response is sent with a status of Success and no Identifier.
A Failed response to a C-FIND request indicates that the SCP is unable to process the request. This shall be used to indicate that the requested template is not supported by the SCP, or that more than one match was found by the SCP.
The SCU may cancel the C-FIND service by issuing a C-FIND-CANCEL request at any time during the processing of the C-FIND service. The SCP will interrupt all matching and return a status of Canceled.
The SCU needs to be prepared to receive C-FIND responses sent by the SCP until the SCP finally processes the C-FIND-CANCEL request.
In order to serve as a Service Class Provider (SCP) of one or more Relevant Patient Information Model SOP Classes, a DICOM Application Entity (AE) possesses relevant information about patients. This information is organized into a Relevant Patient Information Model.
The SOP Classes are composed of both the Information Model and a DIMSE-C Service Group.
The E/R Model consists of Patient and Structured Information, with no relationship to other Information Entities in the DICOM Information model.
The Patient IE includes the Attributes of the Patient Identification and Patient Demographics Modules.
The Structured Information IE includes Attributes that are not inherently related to a real-world entity, but are interpreted through their coded content. This includes the Attributes of the Structured Document Content Module, which in the case of the Relevant Patient Information Query Service has its content constrained by specified templates to convey patient related information. Also included in the Structured Information IE are Attributes of the SOP Common and Common Instance Reference Modules that support the interpretation of coded data, or support access to referenced information objects identified in the coded data.
Table Q.4-1 defines the Attributes of the Relevant Patient Information Model:
Table Q.4-1. Attributes for the Relevant Patient Information Model
Description / Module |
Tag |
Matching Key Type |
Return Key Type |
Remark / Matching Type |
---|---|---|---|---|
Patient |
||||
Patient's Name |
(0010,0010) |
- |
1 |
|
Patient ID |
(0010,0020) |
R |
1 |
Shall be present in the Request Identifier. Shall be retrieved with Single Value Matching. NoteSince only one response is expected, this is a unique key. |
Issuer of Patient ID |
(0010,0021) |
R |
2 |
Shall be retrieved with Single Value Matching. In situations where there are multiple issuers, this key constrains matching of Patient ID (0010,0020) to a domain in which the Patient ID (0010,0020) is unique. |
Patient's Birth Date |
(0010,0030) |
- |
2 |
|
Patient's Sex |
(0010,0040) |
- |
2 |
|
All other Attributes of the Patient Identification Module |
- |
3 |
||
All other Attributes of the Patient Demographic Module |
- |
3 |
||
Structured Information (SR Document Content Module) |
||||
Observation DateTime |
(0040,A032) |
- |
1 |
|
Value Type |
(0040,A040) |
- |
1 |
See Section Q.4.3.1.2.1. |
Concept Name Code Sequence |
(0040,A043) |
- |
1 |
See Section Q.4.3.1.2.1. |
>Code Value |
(0008,0100) |
- |
1 |
|
>Coding Scheme Designator |
(0008,0102) |
- |
1 |
|
>Coding Scheme Version |
(0008,0103) |
- |
1C |
Required if the value of Coding Scheme Designator (0008,0102) is not sufficient to identify the Code Value (0008,0100) unambiguously. |
>Code Meaning |
(0008,0104) |
- |
1 |
|
>All other Attributes of the Concept Name Code Sequence |
||||
Content Sequence |
(0040,A730) |
- |
2 |
See Section Q.4.3.1.2.1. |
>All Attributes of the Content Sequence |
- |
- |
Content Items as provided by the SCP. Requirements on Content Item Attribute Types shall be in accordance with the definitions in the SR Document Content Module. |
|
HL7 Structured Document Reference Sequence |
(0040,A390) |
- |
1C |
|
>Referenced SOP Class UID |
(0008,1150) |
- |
1 |
|
>Referenced SOP Instance UID |
(0008,1155) |
- |
1 |
|
>HL7 Instance Identifier |
(0040,E001) |
- |
1 |
|
>Retrieve URI |
(0040,E010) |
- |
3 |
|
Structured Information (Common Instance Reference Module) |
||||
Studies Containing Other Referenced Instances Sequence |
(0008,1200) |
- |
1C |
Required if Content Sequence (0040,A390) includes Content Items that reference SOP Instances that use the Patient/Study/Series/Instance information model. |
>Referenced Series Sequence |
(0008,1115) |
- |
1 |
|
>>Series Instance UID |
(0020,000E) |
- |
1 |
|
>>Referenced Instance Sequence |
(0008,114A) |
- |
1 |
|
>>>Referenced SOP Class UID |
(0008,1150) |
- |
1 |
|
>>>Referenced SOP Instance UID |
(0008,1155) |
- |
1 |
The Attributes in Table Q.4-2 are not part of the Information Model; their inclusion in the C-FIND request and response identifier are governed by rules in sections Section Q.2.1.1.3.1 and Section Q.2.1.1.3.2, respectively.
Table Q.4-2. Additional C-FIND Identifier Attributes
Attribute |
Tag |
Type in Request Identifier |
Type in Response Identifier |
Remark |
---|---|---|---|---|
Content Template Sequence |
(0040,A504) |
1 |
1 |
|
>Mapping Resource |
(0008,0105) |
1 |
1 |
|
>Template Identifier |
(0040,DB00) |
1 |
1 |
|
Specific Character Set |
(0008,0005) |
1C |
1C |
Required if expanded or replacement character sets are used. See Section Q.2.1.1.3, |
Concept Name Code Sequence (0040,A043) in a C-FIND Response shall have one sequence item that identifies the Root node concept of the returned structure. This shall be the same as the Concept Name of the first row of the template identified in the Content Template Sequence (0040,A504) in the Identifier. The Concept Name Code Sequence (0040,A043) shall always be sent zero length in the Request Identifier.
The Value Type (0040,A040) applies to the Concept Name Code Sequence (0040,A043), and shall be the same as the Value Type (0040,A040) of the first row of the template identified in the Content Template Sequence (0040,A504) in the Identifier.
The Content Sequence (0040,A730) is a potentially recursively nested Sequence of Items, as described in PS3.3, SR Document Content Module. The Content Sequence shall always be sent zero length in the Request Identifier. The Content Sequence in the data set of the Response shall contain the content items of the requested template.
An implementation may conform to the Relevant Patient Information Model SOP Classes as an SCU and/or as an SCP.
The Conformance Statement shall be in the format defined in PS3.2.
An implementation that conforms to one or more of the Relevant Patient Information Model SOP Classes shall support queries against the Relevant Patient Information Model described in Section Q.4.3.1 using the baseline C-FIND SCU Behavior described in Section Q.4.2.
An implementation that conforms to one or more of the Relevant Patient Information Model SOP Classes as an SCU shall state in its Conformance Statement which SOP Class(es) it supports, and which Root template(s) it may request in a query if not specified by the SOP Class. The Conformance Statement shall also state the definition of any supported template extensions.
An implementation that conforms to one or more of the Relevant Patient Information Model SOP Classes shall support queries against the Relevant Patient Information Model described in Section Q.4.3.1 using the baseline C-FIND SCP Behavior described in Section Q.4.2.
An implementation that conforms to one or more of the Relevant Patient Information Model SOP Classes as an SCP shall state in its Conformance Statement which SOP Class(es) it supports, and which Root template(s) it will support in a query response if not specified by the SOP Class. The Conformance Statement shall also state the definition of any supported template extensions.
An implementation that conforms to one or more of the Relevant Patient Information Model SOP Classes as an SCP shall state in its Conformance Statement how it makes use of Specific Character Set (0008,0005) when interpreting queries, performing matching, and encoding responses.
The Relevant Patient Information Model SOP Classes in the Relevant Patient Information Query Service Class identify the Relevant Patient Information Model, and the DIMSE-C operation supported. In some instances a Root template is specified. The Standard SOP Classes are defined in Table Q.4-3:
Table Q.4-3. SOP Classes for the Relevant Patient Information Model
SOP Class Name |
SOP Class UID |
Root Template |
---|---|---|
General Relevant Patient Information Query |
1.2.840.10008.5.1.4.37.1 |
TID 9007 General Relevant Patient Information, or from the list in PS3.16 |
Breast Imaging Relevant Patient Information Query |
1.2.840.10008.5.1.4.37.2 |
TID 9000 Relevant Patient Information for Breast Imaging |
Cardiac Relevant Patient Information Query |
1.2.840.10008.5.1.4.37.3 |
TID 3802 Cardiovascular Patient History |
The list of Root templates for the General Relevant Patient Information Query is extensible.