| DICOM PS3.4 2024d - Service Class Specifications |
|---|
The Basic Worklist Management Service Class defines an application-level class-of-service that facilitates the access to worklists.
A worklist is the structure to present information related to a particular set of tasks. It specifies particular details for each task. The information supports the selection of the task to be performed first, and supports the performance of that task.
One example is the worklist used to present information about scheduled imaging procedures at an imaging modality and to the operator of that modality. Another example is the worklist presented at a radiological reporting station to indicate which studies have been performed and are waiting to be reported.
This annex defines a service for communicating such worklists. The following are characteristics for this Service Class:
The worklist has to be queried by the Application Entity (AE) associated with the application on which, or by which, the tasks included in the worklist have to be performed. In this query, a number of search keys can be used, defined for each particular worklist SOP Class.
The worklist consists of worklist items, each item is related to one task. A worklist item contains Attributes from different objects related to the task.
This Service Class is not intended to provide a comprehensive generalized database query mechanism such as SQL. Instead, the Basic Worklist Management Service Class is focused towards basic queries using a small set of common Key Attributes used as Matching Keys or Return Attributes. Basic Worklist Information Models are not hierarchical.
Basic Worklist Information Models always consist of one query level, which may consist of one or more entities. There is no distinction between hierarchical and relational use of C-Find in the Basic Worklist Management Service Class.
Key Attributes 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 Keys are typically used in an SQL 'where' clause. Return Keys are typically used in an SQL 'select' clause to convey the Attribute Values.
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.
In order to serve as a Service Class Provider (SCP) of the Basic Worklist Management Service Class, a DICOM Application Entity (AE) possesses information about the Attributes of a number of managed worklist entries. This information is organized into Worklist Information Models.
Worklists are implemented against well defined Information Models. A specific SOP Class of the Basic Worklist Management Service Class consists of an informative Overview, an Information Model Definition and a DIMSE-C Service Group. In this Service Class, the Information Model plays a role similar to an Information Object Definition (IOD) of most other DICOM Service Classes.
Two peer DICOM AEs implement a SOP Class of the Basic Worklist Management Service Class with one serving in the SCU role and one serving in the SCP role. SOP Classes of the Basic Worklist Management Service Class are implemented using the DIMSE-C C-FIND service as defined in PS3.7.
Both a baseline and extended behavior are defined for the DIMSE-C C-FIND. Baseline behavior specifies a minimum level of conformance for all implementations to facilitate interoperability. Extended behavior enhances the baseline behavior to provide additional features that may be negotiated independently at Association establishment time.
The following description of the DIMSE-C C-FIND service provides a brief overview of the SCU/SCP semantics.
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 information that the SCP possesses, to the objects specified in the SOP Class.
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 each match with an Identifier containing the values of all Matching Key Attributes and all known Return Key Attributes requested. Each response contains one worklist item. All such responses will contain a status of Pending. A status of Pending indicates that the process of matching is not complete.
When the process of matching is complete a C-FIND response is sent with a status of Success and no Identifier.
A Refused or Failed response to a C-FIND request indicates that the SCP is unable to process the request.
The SCU may cancel the C-FIND service by issuing a C-CANCEL-FIND request at any time during the processing of the C-FIND service. The SCP will interrupt all matching and return a status of Canceled.
| DICOM PS3.4 2024d - Service Class Specifications |
|---|