| DICOM PS3.4 2025a - Service Class Specifications |
|---|
The Repository Query SOP Class uses the C-FIND Service and the Study Root Query/Retrieve Information Model. The SOP Class specifies additional semantics and behaviors for the SCU and SCP beyond those defined for the Study Root Query/Retrieve Information Model - FIND SOP Class.
In particular, the Repository Query SOP Class supports incremental query/response for a large number of entities using the following features:
Both the SCU and SCP may set limits on the number of entity records (Pending status responses) returned in a C-FIND transaction.
If the number of responses would exceed the SCU or SCP limit, the C-FIND query processing is terminated with a defined Warning status response indicating an incomplete set of responses.
If requested by the SCU, each response returns a unique Record Key (0008,041B) value by which the SCP orders the C-FIND responses.
The SCU may include a Record Key (0008,041B) value it received in one C-FIND transaction as the Prior Record Key (0008,041C) in the C-FIND Request for a subsequent transaction. The SCP processes that subsequent C-FIND beginning with the record following that Prior Record Key (0008,041C).
The Repository Query SOP Class also supports return of URI links for access to stored SOP Instances using a non-DICOM file access protocol. Since stored SOP Instances accessed through a non-DICOM protocol might not include all current metadata Attributes (such as updated patient names or IDs), the Repository Query SOP Class also supports return of current metadata Attributes whose values might differ from those in the stored SOP Instance.
See additional explanatory information in Annex YYYY “Inventories (Informative)” in PS3.17, including discussion of the use of the Repository Query SOP Class to produce an Inventory SOP Instance.
The Repository Query SOP Class uses the Study Root Query/Information model specified in Section C.6.2.1, but specifies additional Key Attributes. These Key Attributes, like those defined in Section C.3.4, are not specified in the Composite IODs of PS3.3, but represent information that may be used by a repository system for managing stored SOP Instances. Table C.6.4.1-1 defines the additional Key Attributes.
Table C.6.4.1-1. Additional Keys for Repository Query
|
Implementation-specific unique identifier of the entity record. This Attribute is supported only with Universal Matching. See Section C.6.4.1.1. |
|||
|
Flag that the entity at the Query/Retrieve Level specified in the Identifier of the C-FIND, and its set of Composite Object Instances, have been removed from operational use related to patient care. See Section C.6.4.1.2. |
|||
|
Reason the entity at the Query/Retrieve Level specified in the Identifier of the C-FIND was removed from operational use. |
|||
|
>Include Table C.6-2b “Basic Code Value Keys Macro with Optional Keys” |
|||
|
Description of non-DICOM protocol access to sets of stored SOP Instances. This Attribute is defined only at the Study and Series levels. This Attribute is supported only with Universal Matching, i.e., if present in the Request Identifier it is zero-length or has only a zero-length Item. See Section C.6.4.1.3. See Section C.6.4.5.5 for additional SCP requirements. Zero or one Item may be included in this Sequence in a Response Identifier. |
|||
|
Base URI for accessing SOP Instances through a non-DICOM protocol. |
|||
|
Access URI for a folder containing all SOP Instances for this Study or Series. |
|||
|
Access URI for a container file containing all the SOP Instances for this Study or Series. |
|||
|
See Section P.1.2 “Container File Formats” in PS3.3 for definitions of Defined Terms. Required in Response Identifier if File Access URI (0008,0409) is present. |
|||
|
Description of non-DICOM protocol access to a stored SOP Instance. This Attribute is defined only at the Composite Instance level. This Attribute is supported only with Universal Matching, i.e., if present in the Request Identifier it is zero-length or has only a zero-length Item. See Section C.6.4.1.3. See Section C.6.4.5.5 for additional SCP requirements. Zero or more Items may be included in this Sequence in a Response Identifier. |
|||
|
Access URI for file containing the SOP Instance. Required in Response Identifier if File Access Sequence (0008,041A) has an Item. |
|||
|
See Section P.1.2 “Container File Formats” in PS3.3 for definitions of Defined Terms not described here. Required in Response Identifier if File Access URI (0008,0409) is present. |
|||
|
Filename within a container file of the file containing the SOP Instance. Required in Response Identifier if Container File Type (0008,040A) is ZIP, TAR, or TARGZIP. |
|||
|
Byte offset (zero-based) within a container file for the start of the SOP Instance file. Required in Response Identifier if Container File Type (0008,040A) is BLOB, may be present otherwise. |
|||
|
Length of the SOP Instance file within a container file. Required in Response Identifier if Container File Type (0008,040A) is BLOB, may be present otherwise. |
|||
|
Transfer Syntax of SOP Instance encoded in DICOM File Format. Equal to Transfer Syntax UID (0002,0010) in File Meta Information header. Required in Response Identifier if File Access Sequence (0008,041A) has an Item. |
|||
|
Describes the approximate lossy compression ratio(s) that have been applied to this image. |
|||
|
The algorithm used for generating a Message Authentication Code. See Section C.12.1.1.3.1.2 “Signature” in PS3.3 for Defined Terms. Required in Response Identifier if MAC (0400,0404) is present. |
|||
|
Message Authentication Code computed across stored instance file for verification of file integrity. |
|||
|
All non-bulk data Attributes at the Query/Retrieve Level that are managed by the SCP. See Section C.6.4.1.4. See Section C.6.4.5.5 for additional SCP requirements. This Attribute is supported only with Universal Matching, i.e., if present in the Request Identifier it is zero-length or has only a zero-length Item. Zero or one Item may be included in this Sequence in a Response Identifier. |
|||
|
Multiple Attributes may be present in the Response Identifier. |
|||
|
Non-bulk data Attributes at the Query/Retrieve Level that are managed by the SCP, for which values are different from the values contained in stored SOP Instance files. See Section C.6.4.1.4. See Section C.6.4.5.5 for additional SCP requirements. This Attribute is supported only with Universal Matching, i.e., if present in the Request Identifier it is zero-length or has only a zero-length Item. Zero or one Item may be included in this Sequence in a Response Identifier. |
|||
|
Multiple Attributes may be present in the Response Identifier. |
|||
The character "-" in the Type column is used to indicate Attributes that are within a Sequence that is defined only with Universal Matching. These Attributes therefore will not be present in a Request Identifier; hence they are not Key Attributes for matching and the Type column does not apply. If the SCP supports the Sequence Attribute, and it is requested by the SCU, the SCP returns these "-" Attributes in accordance with their Attribute Description.
Record Key (0008,041B) is defined at the Study, Series, and Instance query levels. It is an implementation-specific unique identifier within the level of the entity record in the SCP. The SCP of the Repository Query SOP Class shall return non-zero length values of Record Key (0008,041B). The content of Record Key (0008,041B) is opaque to applications other than the SCP.
The SCP shall construct the Record Key (0008,041B) value such that for each value the SCP can determine its order with respect to all other such values. C-FIND Response Identifiers shall be returned in the ordering of Record Key (0008,041B) values. The SCP shall be able to determine from a given value the next entity record to be returned that matches the given Query Request Identifier, without repeating any records.
Record Key (0008,041B) values are used as the Prior Record Key (0008,041C) value in a subsequent Query Request (see Section C.6.4.5.3). The SCP may establish implementation specific conditions after which a Record Key (0008,041B) value is not valid, i.e., will no longer allow continuation of a sequence of Query operations. The SCP shall be able to determine from a given Prior Record Key (0008,041C) value whether that value is still valid for determining the next record to be returned.
The structure, content, and ordering method of Record Key (0008,041B) values is SCP implementation-specific, and is opaque to the SCU, i.e., the SCU should not attempt to parse those values for components or semantics. Values may be permanent, or may be constructed dynamically during query processing. Only the SCP can determine from the value of one Record Key (0008,041B) what would be the next appropriate record to return. For example, an SCP may use encrypted representations of an internal database primary key as the Record Key (0008,041B), and such may appear to the SCU to be random unordered values.
The intention of the ordering and use requirements for the Record Key (0008,041B) is to allow an SCU to obtain the complete inventory matching the Key Attributes in a sequence of Queries. See Section YYYY.2.2 “Record Key and Continuation” in PS3.17.
The Removed from Operational Use (0008,0405) Attribute is defined at the Study, Series, and Instance query levels.
Enumerated Values:
A value of Y indicates the Study, Series, or Instance has been removed from operational use related to patient care, although it may be retained in the repository system for other reasons (e.g., for audit of patient radiation exposure). At the Study and Series level, the Attribute indicates whether the entire Study or Series has been removed from operational use. A value of Y at the Study level supersedes any value specified for subsidiary Series and Instances, and a value of Y at the Series level supersedes any value specified for subsidiary Instances.
While defined at the Study, Series, and Instance levels, an SCP might not support this Attribute at some, or any, of those levels. E.g., an SCP may only manage this Attribute at the Instance level, and is not required to infer a value for the Series or Study level.
The meaning of "operational userelated to patient care" is implementation or site specific, but generally includes diagnostic, clinical, and therapeutic uses, as well as administrative uses necessary for providing care (e.g., insurance authorization).
Studies, Series, or Instances might be marked removed from operational use by actions associated with the processing of specific Key Object Selection Document SOP Instances, e.g., in accordance with [IHE RAD TF-1].Image Object Change Management Integration Profile (IOCM). Those Key Object Selection Document SOP Instances, and their Series, may themselves be marked as removed from operational use. The Context Group for Reason for Removal Code Sequence (0008,0406) includes the Key Object Selection Concept Codes specified in IOCM.
The semantics of the Removed from Operational Use (0008,0405) Attribute allows the SCP to include such entities in the Repository Query response without constraint. An SCP might exclude entities marked as removed from operational use from the C-FIND Responses of other Query/Retrieve SOP Classes (e.g., see [IHE RAD TF-2] Section 4.66.4.1.3.1 Access to Rejected Instances).
Removed from Operational Use (0008,0405) is independent of Instance Availability (0008,0056). A composite instance may have been removed from operational use but is still accessible at the rapidity specified by Instance Availability (0008,0056). Conversely, an instance may not have been removed from operational use but is UNAVAILABLE for retrieval.
If the SCP retains records of deleted Studies, Series, or Instances, even though the actual Instances are physically deleted, it may include those entities in the C-FIND Response with an appropriate Reason for Removal Code Sequence (0008,0406) value. Such instances may have an Instance Availability (0008,0056) value "UNAVAILABLE" (see Section C.4.1.1.3.2).
The SCP may support optional Attributes providing a URI link to SOP Instances stored in the DICOM File Format (see Section 7 “DICOM File Format” in PS3.10) and accessible through a non-DICOM file access protocol (see Annex P “Stored File Access Through Non-DICOM Protocols (Normative)” in PS3.3).
See Section YYYY.3.4 “Access Mechanisms For Repository Data” in PS3.17
"File Set" as used here may not be identical to the File-set concept defined in PS3.10 and used in Storage Media File-set ID (0088,0130).
For a query at the Study or Series level, Stored Instance Base URI (0008,0407) within the File Set Access Sequence (0008,0419) establishes an [RFC3986] base URI that is merged with relative path reference URIs for non-DICOM protocol access to SOP Instances of the Study or Series. If all of the stored SOP Instance files of that Study or Series entity are catalogued in a single folder, Folder Access URI (0008,0408) provides the URI for protocol operations on that folder. If all of the stored SOP Instance files are in a single container file, File Access URI (0008,0409) provides the URI for accessing that file. Folder Access URI (0008,0408) and/or File Access URI (0008,0409) may be a relative path reference URI beginning with the single-dot-segment "./", and the URI is merged with the Stored Instance Base URI (0008,0407) in accordance with Section P.2.1 “URI Format” in PS3.3.
Stored Instance Base URI (0008,0407) is optional. If not present, the values of Folder Access URI (0008,0408) and File Access URI (0008,0409) will be complete URIs. If Stored Instance Base URI (0008,0407) is present, those other Attributes may still provide complete URIs, rather than relative paths to be merged with the Base URI. A complete path specified in Folder Access URI (0008,0408) or File Access URI (0008,0409) may have a different scheme and authority than is specified in Stored Instance Base URI (0008,0407).
For a query at the Instance level, Items of the File Access Sequence (0008,041A) in the Response Identifier each provide an [RFC3986] URI to access the stored SOP Instance. File Access URI (0008,0409) may be a URI relative path reference beginning with the single-dot-segment "./", and the URI is merged with the Stored Instance Base URI (0008,0407) specified within the File Set Access Sequence (0008,0419) at the Series level, if present, or otherwise to the Stored Instance Base URI (0008,0407) specified within the File Set Access Sequence (0008,0419) at the Study level.
The SCP may store a SOP Instance on multiple storage devices (e.g., fast short-term media and slower long-term media), or with different Transfer Syntaxes. The SOP Instance may therefore be accessible through a non-DICOM protocol at multiple URIs.
If the File Access URI (0008,0409) for a SOP Instance is a relative path reference URI, the SCU will need to have obtained the Stored Instance Base URI (0008,0407) from the hierarchically superior STUDY and SERIES level queries. I.e., the Study and Series level queries will have included a request for the File Set Access Sequence (0008,0419).
An SCP may manage a set of metadata Attributes of the SOP Instances in the repository for response to Query requests. Metadata Sequence (0008,041D) in a Response Identifier shall contain all SOP Instance Attributes at the Query level that are managed by the SCP, excluding bulk data elements (such as pixel, waveform, and surface mesh data) and non-SOP Instance Attributes specified in Section C.3.4 or in Table C.6.4.1-1.
The set of Attributes managed by the SCP is implementation dependent. In some implementations the managed set of Attributes might include only those few required to be supported for Query Key matching, while in other implementations the set might include every non-bulk data Attribute. See Section C.6.2.1 in PS3.4.
An SCP may manage a set of metadata Attributes whose "updated" values differ from those in a stored SOP Instance accessible through a non-DICOM protocol specified in the File Access URI (0008,0409) or Folder Access URI (0008,0408). Although a stored SOP Instance shall be conformant to its IOD (per the requirements of the DICOM File Format), some Attributes in the file might not have current values (e.g., Patient Name may have been corrected or changed after the Instance was stored). Updated Metadata Sequence (0008,041E) in a Response Identifier shall contain all Attributes at the Query level whose values are different from the values contained in the stored SOP Instance file.
An SCP that supports non-DICOM protocol URI references to stored SOP Instances shall support either the Metadata Sequence (0008,041D) or the Updated Metadata Sequence (0008,041E), or both, to provide current metadata values for SOP Instances accessed through the non-DICOM protocol.
SOP Instances accessed through DICOM protocols are expected to have current values in all Attributes.
The SCP might not track whether Attribute values have changed, or which specific Attributes have changed values, and would therefore not support Updated Metadata Sequence (0008,041E). In this case, the SCU may request the Metadata Sequence (0008,041D) that contains all current Attribute values managed by the SCP, whether or not they have been updated. Determination of differences, if any, between those returned Attribute values and values in the stored SOP Instance would be the responsibility of the SCU.
At any Query level,Metadata Sequence (0008,041D) or Updated Metadata Sequence (0008,041E) may include the Original Attributes Sequence (0400,0561) describing the provenance of changes to Attributes at that level or at higher Query levels.
If Metadata Sequence (0008,041D) and/or Updated Metadata Sequence (0008,041E) are present in a Request Identifier, their absence in the Response Identifier indicates they are not supported by the SCP (see Section C.2.2.1.3).
A zero-length value or a single empty Item in Updated Metadata Sequence (0008,041E) in a Response Identifier indicates support by the SCP, but that there are no differing metadata Attribute values.
| DICOM PS3.4 2025a - Service Class Specifications |
|---|