Annex K BASIC WORKLIST MANAGEMENT SERVICE(Normative)

K.1 Overview

K.1.1 Scope

The Basic Worklist Management Service Class defines an application-level class-of-service which 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.

Note: 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.

Notes: 1. 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.

2. 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.

K.1.2 Conventions

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).

Note: 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 PS 3.5.

K.1.3 Worklist Information Model

In order to serve as a Service Class Provider (SCP) of the Basic Worklist 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 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.

K.1.4 Service Definition

Two peer DICOM AEs implement a SOP Class of the Basic Worklist Service Class with one serving in the SCU role and one serving in the SCP role. SOP Classes of the Basic Worklist Service Class are implemented using the DIMSE-C C-FIND service as defined in PS 3.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 which 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 which have been specified in the Identifier of the request, against the information that the SCP possesses, to the objects specified in the SOP Class.

Note: In this Annex, the term "Identifier" refers to the Identifier service parameter of the C-FIND service as defined in PS 3.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.

Note: The SCU needs to be prepared to receive C-FIND responses sent by the SCP until the SCP finally processed the C-CANCEL-FIND request.

K.2 Worklist Information Model Definition

The Worklist Information Model is identified by the SOP Class negotiated at Association establishment time. The SOP Class is composed of both an Information Model and a DIMSE-C Service Group.

Information Model Definitions for standard SOP Classes of the Worklist Service Class are defined in this Annex. A Worklist Information Model Definition contains:

— an Entity-Relationship Model Definition

— a Key Attributes Definition;

K.2.1 Entity-Relationship Model Definition

Basic Worklist Information Models consist of a single level, that includes all Matching Key Attributes and all Return Key Attributes, which may be sent from the SCU to the SCP in the request and whose values are expected to be returned from the SCP to the SCU in each of the responses (or worklist items). The Matching Key Attribute values in the request specify the worklist items that are to be returned in the responses. All Key Attributes (the Matching Key Attributes and the Return Key Attributes) in the request determine which Attribute values are returned in the responses for that worklist.

A Worklist Item has a one-to-one relationship with the real-world object defining the root for the Basic Worklist Information Model. In addition the worklist item is related to a number of other objects from the real-world model. Each of these real-world objects is represented by a hierarchy of entities organized in an (internal) Entity-Relationship Model.

K.2.2 Attributes Definition

Attributes are defined for each entity in the internal Entity-Relationship Model. An Identifier in a C-FIND request shall contain values to be matched against the Attributes of the Entities in a Worklist Information Model. For any worklist request, the set of entities for which Attributes are returned, shall be determined by the set of Matching and Return Key Attributes specified in the Identifier.

K.2.2.1 Attribute Types

All Attributes of entities in a Worklist Information Model shall be specified both as a Matching Key Attribute (either required or optional) and as a Return Key Attribute.

K.2.2.1.1 Matching Key Attributes

The Matching Key Attributes are Keys, which select worklist items to be included in a requested Worklist.

K.2.2.1.1.1 Required Matching Key Attributes

A Basic Worklist Management SCP shall support matching based on values of all Required Matching Key Attributes of the C-FIND request. Multiple entities may match a given value for a Required Key.

If an SCP manages an entity with an unknown Attribute value (i.e. zero length), the unknown value shall fail to match any Matching Key value.

Notes: 1. Even though there is no means to perform matching on such entities, they may be queried as a Return Key Attribute using a C-FIND request with a zero length value (universal match) or by a single wildcard (wildcard match).

2. An SCU may choose to supply any subset of Required Matching Key Attributes.

K.2.2.1.1.2 Optional Matching Key Attributes

In the Worklist Information Model, a set of Attributes may be defined as Optional Matching Key Attributes. Optional Matching Key Attributes contained in the Identifier of a C-FIND request may induce two different types of behavior depending on support for matching by the SCP. If the SCP

— does not support matching on the Optional Matching Key Attribute, then the Optional Matching Key Attribute shall be ignored for matching but shall be processed in the same manner as a Return Key Attribute.

— supports matching of the Optional Matching Key Attribute, then the Optional Matching Key Attribute shall be processed in the same manner as a Required Matching Key.

Notes: 1. The Conformance Statement of the SCP lists the Optional Matching Key Attributes which are supported for matching.

2. An SCU can not expect the SCP to support a match on an Optional Matching Key.

K.2.2.1.2 Return Key Attributes

The values of Return Key Attributes to be retrieved with the Worklist are specified with zero-length (universal matching) in the C-FIND request. SCPs shall support Return Key Attributes defined by a Worklist Information Model according to the Data Element Type (1, 1C, 2, 2C, 3) as defined in PS 3.5.

Every Matching Key Attribute shall also be considered as a Return Key Attribute. Therefore the C-FIND response shall contain in addition to the values of the requested Return Key Attributes the values of the requested Matching Key Attributes.

Notes: 1 The Conformance Statement of the SCP lists the Return Key Attributes of Type 3, which are supported.

2. An SCU may choose to supply any subset of Return Key Attributes.

3. An SCU can not expect to receive any Type 3 Return Key Attributes.

4. Return Key attributes with VR of SQ may be specified either with zero-length or with the zero-length item in the sequence.

K.2.2.2 Attribute Matching

The following types of matching, which are defined by the Query/Retrieve Service Class in Annex C may be performed on Matching Key Attributes in the Basic Worklist Service Class. Different Matching Key Attributes may be subject for different matching types. The Worklist Information Model defines the type of matching for each Required Matching Key Attribute. The Conformance Statement of the SCP shall define the type of matching for each Optional Matching Key Attribute. The types of matching are:

— Single Value Matching

— List of UID Matching

— Wild Card Matching

— Range Matching

— Sequence Matching

The following type of matching, which is defined by the Query/Retrieve Service Class in Annex C of this Part shall be performed on Return Key Attributes in the Basic Worklist Service Class.

— Universal Matching

See Section C.2.2.2 and subsections for specific rules governing of Matching Key Attribute encoding for and performing of different types of matching.

The Specific Character Set (0008,0005) Attribute and/or the Timezone Offset From UTC (0008,0201) Attribute may be present in the Identifier but are never matched, i.e., they are not considered Matching Key Attributes. See Section C.2.2.2 for details.

Single value matching of Attributes with Person Name Value Representation may be affected by extended negotiation of fuzzy semantic matching of person names.

K.2.2.3 Matching Multiple Values

When matching an Attribute which has a value multiplicity of greater than one, if any of the values match, then all values shall be returned.

K.3 Worklist Information Model

Each Worklist Information Model is associated with one SOP Class. The following Worklist Information Model is defined:

K.4 DIMSE-C Service Group

One DIMSE-C Service is used in the construction of SOP Classes of the Basic Worklist Management Service Class. The following DIMSE-C operation is used.

— C-FIND

K.4.1 C-FIND Operation

SCPs of some SOP Classes of the Basic Worklist Management Service Class are capable of processing queries using the C-FIND operation as described in PS 3.7. The C-FIND operation is the mechanism by which queries are performed. Matches against the keys present in the Identifier are returned in C-FIND responses.

K.4.1.1 C-FIND Service Parameters

K.4.1.1.1 SOP Class UID

The SOP Class UID identifies the Worklist Information Model against which the C-FIND is to be performed. Support for the SOP Class UID is implied by the Abstract Syntax UID of the Presentation Context used by this C-FIND operation.

K.4.1.1.2 Priority

The Priority Attribute defines the requested priority of the C-FIND operation with respect to other DIMSE operations being performed by the same SCP.

Processing of priority requests is not required of SCPs. Whether or not an SCP supports priority processing and the meaning of the different priority levels shall be stated in the Conformance Statement of the SCP.

K.4.1.1.3 Identifier

Both the C-FIND request and response contain an Identifier encoded as a Data Set (see PS 3.5).

K.4.1.1.3.1 Request Identifier Structure

An Identifier in a C-FIND request shall contain

— Key Attributes values to be matched against the values of Attributes specified in that SOP Class.

— Conditionally, the Attribute Specific Character Set (0008,0005). This Attribute shall be included if expanded or replacement character sets may be used in any of the Attributes in the Request Identifier. It shall not be included otherwise.

Note: This means that Specific Character Set (0008,0005) is included if the SCU supports expanded or replacement character sets in the context of this service. It will not be included if expanded or replacement character sets are not supported by the SCU.

— Conditionally, the Attribute Timezone Offset From UTC (0008,0201). This Attribute shall be included if Key Attributes of time are to be interpreted explicitly in the designated local time zone. It shall not be present otherwise, i.e., it shall not be sent with a zero-length value.

The Key Attributes and values allowable for the query shall be defined in the SOP Class definition for the corresponding Worklist Information Model.

K.4.1.1.3.2 Response Identifier Structure

The C-FIND response shall not contain Attributes that were not in the request or specified in this section.

An Identifier in a C-FIND response shall contain:

— Key Attributes with values corresponding to Key Attributes contained in the Identifier of the request (Key Attributes as defined in K.2.2.1.)

— Conditionally, the Attribute Specific Character Set (0008,0005). This Attribute shall be included if expanded or replacement character sets may be used in any of the Attributes in the Response Identifier. It shall not be included otherwise. The C-FIND SCP is not required to return responses in the Specific Character Set requested by the SCU if that character set is not supported by the SCP. The SCP may return responses with a different Specific Character Set.

Note: This means that Specific Character Set (0008,0005) is included if the SCP supports expanded or replacement character sets in the context of this service. It will not be included if expanded or replacement character sets are not supported by the SCP.

— Conditionally, the Attribute Timezone Offset From UTC (0008,0201). This Attribute shall be included if any Attributes of time in the Response Identifier are to be interpreted explicitly in the designated local time zone. It shall not be present otherwise, i.e., it shall not be sent with a zero-length value.

— Conditionally, the Attribute HL7 Structured Document Reference Sequence (0040,A390) and its subsidiary Sequence Items. This Attribute shall be included if HL7 Structured Documents are referenced within the Identifier, e.g., in the Pertinent Documents Sequence (0038,0100).

K.4.1.1.4 Status

Table K.4.-1 defines the status code values which might be returned in a C-FIND response. Fields related to status code values are defined in PS 3.7.

Table K.4-1C-FIND RESPONSE STATUS VALUES

Service Status Further Meaning Status Codes Related Fields
Failure Refused: Out of Resources A700 (0000,0902)
Identifier Does Not Match SOP Class A900 (0000,0901) (0000,0902)
Unable to process Cxxx (0000,0901) (0000,0902)
Cancel Matching terminated due to Cancel request FE00 None
Success Matching is complete - No final Identifier is supplied. 0000 None
Pending Matches are continuing - Current Match is supplied and any Optional Keys were supported in the same manner as Required Keys. FF00 Identifier
Matches are continuing - Warning that one or more Optional Keys were not supported for existence for this Identifier. FF01 Identifier

Note: Status Codes are returned in DIMSE response messages (See PS 3.7). The code values stated in column "Status Codes" are returned in Status Command Element (0000,0900).

K.4.1.2 C-FIND SCU Behavior

All C-FIND SCUs shall be capable of generating query requests which meet the requirements of the "Worklist" Search Method (see K.4.1.3.1).

Required Keys, and Optional Keys associated with the Worklist may be contained in the Identifier.

An SCU conveys the following semantics using the C-FIND requests and responses:

— The SCU requests that the SCP perform a match of all keys specified in the Identifier of the request against the information it possesses of the Worklist specified in the request.

— The SCU shall interpret Pending responses to convey the Attributes of a match of an Entity.

— The SCU shall interpret a response with a status equal to Success, Failed, Refused or Cancel to convey the end of Pending responses.

— The SCU shall interpret a Refused or Failed response to a C-FIND request as an indication that the SCP is unable to process the request.

— 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. The SCU shall recognize a status of Cancel to indicate that the C-FIND-CANCEL was successful.

K.4.1.3 C-FIND SCP Behavior

All C-FIND SCPs shall be capable of processing queries which meet the requirements of the "Worklist" Search (see K.4.1.3.1).

An SCP conveys the following semantics using the C-FIND requests and responses:

— The SCP is requested to perform a match of all the keys specified in the Identifier of the request, against the information it possesses. Attribute matching is performed using the key values specified in the Identifier of the C-FIND request as defined in Section K.2.

— The SCP generates a C-FIND response for each match using the "Worklist" Search method. All such responses shall contain an Identifier whose Attributes contain values from a single match. All such responses shall contain a status of Pending.

— When all matches have been sent, the SCP generates a C-FIND response which contains a status of Success. A status of Success shall indicate that a response has been sent for each match known to the SCP.

Notes: 1. No ID is contained in a response with a status of Success. For a complete definition, see PS 3.7.

2. When there are no matches, then no responses with a status of Pending are sent, only a single response with a status of Success.

— The SCP shall generate a response with a status of Refused or Failed if it is unable to process the request. A Refused or Failed response shall contain no Identifier.

— If the SCP receives C-FIND-CANCEL indication before it has completed the processing of the matches it shall interrupt the matching process and return a status of Cancel.

K.4.1.3.1 "Worklist" Search Method

The following procedure is used to generate matches.

The key match strings contained in the Identifier of the C-FIND request are matched against the values of the Key Attributes for each worklist entity. For each entity for which the Attributes match all of the specified match strings, construct an Identifier. This Identifier shall contain all of the values of the Attributes for this entity which match those in the C-FIND request. Return a response for each such Identifier. If there are no matching keys, then there are no matches, return a response with a status equal to Success and with no Identifier.

K.5 Association Negotiation

Association establishment is the first phase of any instance of communication between peer DICOM AEs. The Association negotiation procedure specified in PS 3.7 shall be used to negotiate the supported SOP Classes or Meta SOP Classes.

Support for the SCP/SCU role selection negotiation is optional. The SOP Class Extended Negotiation is optional.

K.5.1 SOP Class Extended Negotiation

The SOP Class Extended Negotiation allows, at Association establishment, peer DICOM AEs to exchange application Association information defined by specific SOP Classes. This is achieved by defining the Service-class-application-information field. The Service-class-application-information field is used to define support for fuzzy semantic matching of person names.

This negotiation is optional. If absent, the default conditions shall be:

The Association-requester, for each SOP Class, may use one SOP Class Extended Negotiation Sub-Item. The SOP Class is identified by the corresponding Abstract Syntax Name (as defined by PS 3.7) followed by the Service-class-application-information field. This field defines:

The meaning of fuzzy semantic person name matching is as defined in K.2.2.2 and C.2.2.2.1.

The Association-acceptor, for each sub-field of the SOP Class Extended Negotiation Sub-Item offered, either accepts the Association-requester proposal by returning the same value (1) or turns down the proposal by returning the value (0).

If the SOP Class Extended Negotiation Sub-Item is not returned by the Association-acceptor then fuzzy semantic matching of person names is not supported over the Association (default condition).

If the SOP Class Extended Negotiation Sub-Items do not exist in the A-ASSOCIATE indication they shall be omitted in the A-ASSOCIATE response.

K.5.1.1 SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-RQ)

The SOP Class Extended Negotiation Sub-Item consists of a sequence of mandatory fields as defined by PS 3.7. This field shall be three bytes in length.

Table K.5.1-1—SOP CLASS EXTENDED NEGOTIATION SUB-ITEM (service-class-application-information field)—A-ASSOCIATE-RQ

Item Bytes Field Name Description of Field
1 reserved This byte field shall always be 1
2 reserved This byte field shall always be 1
3 Fuzzy semantic matching of person names This byte field defines whether or not fuzzy semantic person name attribute is requested by the Association-requester. It shall be encoded as an unsigned binary integer and shall use one of the following values 0 – fuzzy semantic matching not requested 1 – fuzzy semantic matching requested
4 Timezone query adjustment This byte field defines whether or not the Attribute Timezone Offset From UTC (0008,0201) shall be used to adjust the query meaning for time and datetime fields in queries. 0 - Timezone query adjustment not requested 1 – Timezone query adjustment requested

Note: This Sub-Item is identical to Extended Negotiation Sub-Items as used by the Query/Retrieve SOP Classes. However, relational queries (Byte 1) are not relevant since the worklist information models are single level, and date-time matching (Byte 2) is already required by the worklist information models.

K.5.1.2 SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-AC)

The SOP Class Extended Negotiation Sub-Item is made of a sequence of mandatory fields as defined by PS 3.7. This field shall be three bytes in length.

Table K.5.1-2—SOP CLASS EXTENDED NEGOTIATION SUB-ITEM(service-class-application-information field)—A-ASSOCIATE-AC

Item Bytes Field Name Description of Field
1 reserved This byte field shall always be 1
2 reserved This byte field shall always be 1
3 Fuzzy semantic matching of person names This byte field defines whether or not fuzzy semantic person name attribute matching will be performed by the Association-acceptor. It shall be encoded as an unsigned binary integer and shall use one of the following values 0 – fuzzy semantic matching not performed 1 – fuzzy semantic matching performed
4 Timezone query adjustment This byte field defines whether or not the Attribute Timezone Offset From UTC (0008,0201) shall be used to adjust the query meaning for time and datetime fields in queries. 0 – Timezone adjustment of queries not performed 1 – Timezone adjustment of queries performed

K.6 SOP Class Definitions

K.6.1 Modality Worklist SOP Class

K.6.1.1 Modality Worklist SOP Class Overview

The Modality Worklist SOP class defined within the Basic Worklist Management Service Class defines an application-level class of service which facilitates the communication of information to the imaging modality about Scheduled Procedure Steps, and entities related to the Scheduled Procedure Steps. As will be detailed below, part of the information carried by the worklist mechanism is intended to be used by the imaging modality itself, but much of the information is intended to be presented to the modality operator.

This worklist is structured according to Scheduled Procedure Steps. A procedure step is a unit of service in the context of a requested imaging procedure.

The Modality Worklist SOP class supports the following requirements:

— Verify patient (e.g. download patient demographic information from IS to Modality, to verify that the person to be examined is the intended subject).

— Select a Scheduled Procedure Step from the IS (e.g. download procedure step information from the IS to the Modality). The Modality Worklist SOP Class supports two alternatives for the realization of this requirement, supporting different organization methods of the department:

— The Modality may obtain the list of Scheduled Procedure Steps from the IS. Display of the list and selection from the list is done at the Modality.

— The list is displayed and selection is performed on the IS. This implies, that the information is obtained by the Modality just before the Scheduled Procedure Step starts.

— Prepare the performance of a Scheduled Procedure Step.

— Couple DICOM images unambiguously with related information from the IS (e.g. patient demographics, procedure description, ID data structure from the IS, contextual IS information).

— Capture all the attributes from the IS, that are mandatory to be inserted into the DICOM Image Object

The Modality Worklist SOP Class is not intended to provide access to all IS information and services which may be of interest to a Modality operator or attending physician. Its primary focus is the efficient operation of the image acquisition equipment. DICOM SOP Classes such as the Relevant Patient Information Query SOP Class and non-DICOM Services which fall beyond the scope of the Modality Worklist SOP Class may be needed.

The Modality Worklist SOP Class does not support the transmission of information from the Modality to the information system.

K.6.1.2 Modality Worklist Information Model

K.6.1.2.1 E/R Model

In response to a given C-FIND request, the SCP might have to send several C-FIND responses, (i.e. one C-FIND response per matching worklist item). Each worklist item focuses on one Scheduled Procedure Step and the related information. The E-R diagram presented in Figure K.6-1 depicts the content of one C-FIND request, that is:

— the matching Scheduled Procedure Step, the Requested Procedure to which the Scheduled Procedure Step contributes, the Imaging Service Request in which the associated Requested Procedure is ordered, any associated Visit, and the Patient who is to be the subject of the Procedure.

Therefore, for a given C-FIND request, a given Scheduled Procedure Step will appear in only one of the resulting C-FIND responses. Obviously, information about the Requested Procedure, Imaging Service Request, Visit and Patient may be mentioned in several of these C-FIND responses.

The Modality Worklist Information Model is represented by the Entity Relationship diagram shown in figure K.6 -1.

Note: The entities appearing in messages related to the Modality Worklist SOP Class are required to comply to the Modality Worklist model. However, DICOM does not define the internal structure of the database.

The entry point of the Modality Worklist is the Scheduled Procedure Step entity.

The attributes of a Scheduled Procedure Step Worklist can be found in the following Modules in PS 3.3.

— Patient Relationship Module

— Patient Identification Module

— Patient Demographic Module

— Patient Medical Module

— Visit Relationship Module

— Visit Identification Module

— Visit Status Module

— Visit Admission Module

— Scheduled Procedure Step Module

— Requested Procedure Module

— Imaging Service Request Module

[pic]

Figure K.6-1MODALITY WORKLIST INFORMATION MODEL E/R DIAGRAM

K.6.1.2.2 Modality Worklist Attributes

Table K.6-1 defines the Attributes of the Modality Worklist Information Model:

Table K.6-1ATTRIBUTES FOR THE MODALITY WORKLIST INFORMATION MODEL

Description / Module Tag Match-ing Key Type Return Key Type Remark/Matching Type
Scheduled Procedure Step
Scheduled Procedure Step Sequence (0040,0100) R 1 The Attributes of the Scheduled Procedure Step shall only be retrieved with Sequence Matching. The Scheduled Procedure Step Sequence shall contain only a single Item.
>Scheduled Station AE Title (0040,0001) R 1 The Scheduled station AE title shall be retrieved with Single Value Matching only.
>Scheduled Procedure Step Start Date (0040,0002) R 1 Scheduled Step Start Date shall be retrieved with Single Value Matching or Range Matching. See remark under Scheduled Procedure Step Start Time (0040,0003).
>Scheduled Procedure Step Start Time (0040,0003) R 1 Scheduled Step Start Time shall be retrieved with Single Value Matching or Range Matching. Scheduled Step Start Date and Scheduled Step Start Time are subject to Range Matching. If both keys are specified for Range Matching, e.g. the date range July 5 to July 7 and the time range 10am to 6pm specifies the time period starting on July 5, 10am until July 7, 6pm. Note: If the Information System does not provide scheduling for individual Procedure Steps, it may use the closest scheduling information it possesses (e.g. Procedures are subject to scheduling instead of Procedure Steps).
>Modality (0008,0060) R 1 The Modality shall be retrieved with Single Value Matching.
>Scheduled Performing Physician's Name (0040,0006) R 2 Scheduled Performing Physician's Name shall be retrieved with Single Value Matching or Wild Card Matching.
>Scheduled Procedure Step Description (0040,0007) O 1C Either the Scheduled Procedure Step Description (0040,0007) or the Scheduled Protocol Code Sequence (0040,0008) or both shall be supported by the SCP.
>Scheduled Station Name (0040,0010) O 2
>Scheduled Procedure Step Location (0040,0011) O 2
>Scheduled Protocol Code Sequence (0040,0008) O 1C Either the Scheduled Procedure Step Description (0040,0007) or the Scheduled Protocol Code Sequence (0040,0008) or both shall be supported by the SCP. The Scheduled Protocol Code Sequence contains one or more Items.
>>Code Value (0008,0100) O 1
>>Coding Scheme Version (0008,0103) O 3
>>Coding Scheme Designator (0008,0102) O 1
>>Code Meaning (0008,0104) O 3
>>Protocol Context Sequence (0040,0440) - 3 The Protocol Context Sequence and its Items shall not be used for matching
>>>Value Type (0040,A040) - 1
>>>Concept Name Code Sequence (0040,A043) - 1
>>>>Code Value (0008,0100) - 1
>>>>Coding Scheme Designator (0008,0102) - 1
>>>>Coding Scheme Version (0008,0103) - 3
>>>>Code Meaning (0008,0104) - 1
>>>DateTime (0040,A120) - 1C Required if Value Type (0040,A040) is DATETIME.
>>>Person Name (0040,A123) - 1C Required if Value Type (0040,A040) is PNAME.
>>>Text Value (0040,A160) - 1C Required if Value Type (0040,A040) is TEXT.
>>>Concept Code Sequence (0040,A168) - 1C Required if Value Type (0040,A040) is CODE.
>>>>Code Value (0008,0100) - 1
>>>>Coding Scheme Designator (0008,0102) - 1
>>>>Coding Scheme Version (0008,0103) - 3
>>>>Code Meaning (0008,0104) - 1
>>>Numeric Value (0040,A30A) - 1C Required if Value Type (0040,A040) is NUMERIC.
>>>Measurement Units Code Sequence (0040,08EA) - 1C Required if Value Type (0040,A040) is NUMERIC.
>>>>Code Value (0008,0100) - 1
>>>>Coding Scheme Designator (0008,0102) - 1
>>>>Coding Scheme Version (0008,0103) - 3
>>>>Code Meaning (0008,0104) - 1
>>>All other attributes from Protocol Context Sequence - 3
>Pre-Medication (0040,0012) O 2C Required if Pre-Medication is to be applied to that Scheduled Procedure Step.
>Scheduled Procedure Step ID (0040,0009) O 1
>Requested Contrast Agent (0032,1070) O 2C Required if Contrast Media is to be applied to that Scheduled Procedure Step.
>Scheduled Procedure Step Status (0040,0020) O 3
>All other Attributes from the Scheduled Procedure Step Sequence O 3
Scheduled Specimen Sequence (0040,0500) O 3 One or more Items may be returned in this Sequence.
>Container Identifier (0040,0512) O 1
>Container Type Code Sequence (0040,0518) - 2 Zero or one Item shall be returned in this Sequence.
>>Code Value (0008,0100) - 1
>>Coding Scheme Designator (0008,0102) - 1
>>Coding Scheme Version (0008,0103) - 3
>>Code Meaning (0008,0104) - 1
>Specimen Description Sequence (0040,0560) O 1 One or more Items shall be returned in this Sequence.
>>Specimen Identifier (0040,0551) O 1
>>Specimen UID (0040,0554) O 1
>>All other Attributes from the Specimen Description Sequence O 3 Specimen Preparation Sequence (0040,0610), if present, describes preparation steps already performed, not scheduled procedure steps
>All other Attributes from the Scheduled Specimen Sequence O 3
Requested Procedure
Requested Procedure ID (0040,1001) O 1
Requested Procedure Description (0032,1060) O 1C The Requested Procedure Description (0032,1060) or the Requested Procedure Code Sequence (0032,1064) or both shall be supported by the SCP.
Requested Procedure Code Sequence (0032,1064) O 1C The Requested Procedure Description (0032,1060) or the Requested Procedure Code Sequence (0032,1064) or both shall be supported by the SCP. The Requested Procedure Code Sequence shall contain only a single Item.
>Code Value (0008,0100) O 1
>Coding Scheme Designator (0008,0102) O 1
>Coding Scheme Version (0008,0103) O 3
>Code Meaning (0008,0104) O 3
Study Instance UID (0020,000D) O 1
Study Date (0008,0020) O 3 See note 5.
Study Time (0008,0030) O 3 See note 5.
Referenced Study Sequence (0008,1110) O 2
>Referenced SOP Class UID (0008,1150) O 1
>Referenced SOP Instance UID (0008,1155) O 1
Requested Procedure Priority (0040,1003) O 2
Patient Transport Arrangements (0040,1004) O 2
All other Attributes from the Requested Procedure Module O 3
Imaging Service Request
Accession Number (0008,0050) O 2
Requesting Physician (0032,1032) O 2
Referring Physician's Name (0008,0090) O 2
All other Attributes from the Imaging Service Request Module O 3
Visit Identification
Admission ID (0038,0010) O 2
All other Attributes from the Visit Identification Module O 3
Visit Status
Current Patient Location (0038,0300) O 2
All other Attributes from the Visit Status Module O 3
Visit Relationship
Referenced Patient Sequence (0008,1120) O 2
>Referenced SOP Class UID (0008,1150) O 1
>Referenced SOP Instance UID (0008,1155) O 1
All other Attributes from the Visit Relationship Module exc ept those explicitly included in this table (see Note 3) O 3
Visit Admission
All Attributes from the Visit Admission Module O 3
Patient Relationship
All Attributes from the Patient Relationship Module exc ept those explicitly included in this table (see Note 3) O 3
Patient Identification
Patient's Name (0010,0010) R 1 Patient Name shall be retrieved with Single Value Matching or Wild Card Matching.
Patient ID (0010,0020) R 1 Patient ID shall be retrieved with Single Value Matching.
All other Attributes from the Patient Identification Module O 3
Patient Demographic
Patients Birth Date (0010,0030) O 2
Patient's Sex (0010,0040) O 2
Patient’s Primary Language Code Sequence (0010,0101) O 3 The languages which can be used to communicate with the patient. If returned, the Patient’s Primary Language Code Sequence shall contain one or more Items. The items are ordered by preference (most preferred language to least preferred language).
>Code Value (0008,0100) O 1
>Coding Scheme Designator (0008,0102) O 1
>Code Meaning (0008,0104) - 1 Code Meaning shall not be used as Matching Key.
>Patient’s Primary Language Modifier Code Sequence (0010,0102) O 3 A modifier for a Patient’s Primary Language. Can be used to specify a national language variant. If returned, the Patient’s Primary Language Modifier Code Sequence shall contain only a single Item.
>>Code Value (0008,0100) O 1
>>Coding Scheme Designator (0008,0102) O 1
>>Code Meaning (0008,0104) - 1 Code Meaning shall not be used as Matching Key.
Patient's Weight (0010,1030) O 2
Confidentiality constraint on patient data (0040,3001) O 2
All other Attributes from the Patient Demographic Module O 3
Patient Medical
Patient State (0038,0500) O 2
Pregnancy Status (0010,21C0) O 2
Medical Alerts (0010,2000) O 2
Allergies (0010,2110) O 2
Special Needs (0038,0050) O 2
Pertinent Documents Sequence (0038,0100) O 3 Pertinent Documents Sequence shall be retrieved with Universal Matching only
>Referenced SOP Class UID (0008,1150) - 1
>Referenced SOP Instance UID (0008,1155) - 1
>Purpose of Reference Code Sequence (0040,A170) - 2
>>Code Value (0008,0100) - 1
>>Coding Scheme Designator (0008,0102) - 1
>>Code Meaning (0008,0104) - 1
>Document Title (0042,0010) - 2
All other Attributes from the Patient Medical Module O 3

Notes: 1. Just like Series and Image Entities specified in the Query/Retrieve Service Class either an SCU or an SCP may support optional Matching Key Attributes and/or Type 3 Return Key Attributes which are not included in the Worklist Information Model (i.e. standard or private attributes). This is considered a Standard Extended SOP Class (see PS 3.2).

2. Each Module contains a Comment Attribute. This may be used to transmit non-structured information, which may be displayed to the operator of the Modality.

3. The reason for this exclusion is to assure that the attributes that may be present in multiple modules are included only once with the meaning pertaining to only one module (for example, Referenced Study Sequence (0008,1110) shall be included once with the meaning as defined in the Requested Procedure Module).

4. The use of Specific Character Set is discussed in section K.4.1.1.3.1 and K.4.1.1.3.2.

5. The values of Study Date (0008,0020) and Study Time (0008,0030) may be provided in order to achieve consistency of Study level attributes in composite instances generated in multiple performed procedure steps on different devices, and the worklist values may be updated by the SCP based on information received from Modality Performed Procedure Steps or by examining the composite instances generated.

The attributes in Table K.6-1a are not part of the Worklist Information Model; their inclusion in the C-FIND request and response identifier are governed by rules in sections K.4.1.1.3.1 and K.4.1.1.3.2, respectively.

Table K.6-1aATTRIBUTES FOR THE MODALITY WORKLIST C-FIND IDENTIFIER

Description Tag Request Identifier Response Identifier Remark Type
Specific Character Set (0008,0005) 1C 1C This attribute is required if expanded or replacement character sets are used. See C.2.2.2 and K.4.1.1.3
Timezone Offset From UTC (0008,0201) 1C 1C This attribute is required if times are to be interpreted explicitly in the designated local timezone. See C.2.2.2 and K.4.1.1.3
HL7 Structured Document Reference Sequence (0040,A390) - 1C One or more Items may be included in this sequence. Required if HL7 Structured Documents are referenced within the Identifier. See K.4.1.1.3
>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

K.6.1.3 Conformance Requirements

An implementation may conform to the Modality Worklist SOP Class as an SCU or an SCP. The Conformance Statement shall be in the format defined in PS 3.2.

K.6.1.3.1 SCU Conformance

An implementation that conforms to the Modality Worklist SOP Class shall support queries against the Worklist Information Model described in Section K.6.1.2 of this Annex using the baseline C-FIND SCU Behavior described in Section K.4.1.2 of this Part.

An implementation that conforms to the Modality Worklist SOP Class as an SCU shall state in its Conformance Statement whether it requests matching on Optional Matching Key Attributes. If it requests Type 3 Return Key Attributes, then it shall list these Optional Return Key Attributes. It shall identify any Templates it supports for the Protocol Context Sequence.

An implementation that conforms to the Modality Worklist SOP Class as an SCU shall state in its Conformance Statement whether or not it supports extended negotiation of fuzzy semantic matching of person names.

An implementation that conforms to the Modality Worklist SOP Class as an SCU shall state in its Conformance Statement how it makes use of Specific Character Set (0008,0005) and Timezone Offset From UTC (0008,0201) when encoding queries and interpreting responses.

K.6.1.3.2 SCP Conformance

An implementation that conforms to the Modality Worklist SOP Class shall support queries against the Worklist Information Model described in Section K.6.1.2 of this Annex using the C-FIND SCP Behavior described in Section K.4.1.3 of this Part.

An implementation that conforms to the Modality Worklist SOP Class as an SCP shall state in its Conformance Statement whether it supports matching on Optional Matching Key Attributes. If it supports Type 3 Return Key Attributes, then it shall list the Optional Return Key Attributes that it supports. It shall identify any Templates it supports for the Protocol Context Sequence.

An implementation that conforms to the Modality Worklist SOP Class as an SCP shall state in its Conformance Statement whether it supports case-insensitive matching for PN VR attributes and list attributes for which this applies.

An implementation that conforms to the Modality Worklist SOP Class as an SCP shall state in its Conformance Statement whether or not it supports extended negotiation of fuzzy semantic matching of person names. If fuzzy semantic matching of person names is supported, then the mechanism for fuzzy semantic matching shall be specified.

An implementation that conforms to the Modality Worklist SOP Class as an SCP shall state in its Conformance Statement how it makes use of Specific Character Set (0008,0005) and Timezone Offset From UTC (0008,0201) when interpreting queries, performing matching and encoding responses.

K.6.1.4 SOP Class

The Modality Worklist SOP Class in the Basic Worklist Service Class identify the Modality Worklist Information Model, and the DIMSE-C operations supported. The following Standard SOP Class is identified:

SOP Class Name SOP Class UID
Modality Worklist Information Model - FIND 1.2.840.10008.5.1.4.31

K.6.2 General Purpose Worklist SOP Class

K.6.2.1 General Purpose Worklist SOP Class Overview

The General Purpose Worklist SOP class defined within the Basic Worklist Management Service Class defines an application-level class of service which facilitates the communication of information to any application or piece of equipment about General Purpose Scheduled Procedure Steps and related entities. As will be detailed below, part of the information carried by the worklist mechanism is intended to be used by the application itself, and much of the information is intended to be presented to the person performing the task. In automated applications all information will go to the application.

The worklist is a list of General Purpose Scheduled Procedure Steps, i.e. each worklist item focuses on a single procedure step and the related entities. The General Purpose Worklist SOP Class covers a wide range of tasks, and the related entities may differ dependent upon the specifics of the procedure step to be performed. For example, the General Purpose Worklist may be used to schedule procedure steps for the following tasks:

The detailed actions for the specific task will be conveyed by means of Workitem Codes. The related entities, i.e. the input information the performer needs to do the task and the output information the performer has to produce, may be conditionally present based on the specific Workitem Code.Examples of these entities are: Images, Historic Images, (Structured) Reports, Films, Presentation States, Audio recordings, Requested Procedure text.

The General Purpose Worklist SOP Class is not intended to provide access to all IS information and services which may be of interest to an application operator. Its primary focus is the efficient operation of the processing application. Other DICOM SOP Classes such as the Performed Procedure Step SOP Classes, as well as non-DICOM services may be needed in conjunction with this SOP Class.

The General Purpose Worklist SOP Class does not support the communication of information from the application to the worklist provider. The General Purpose Scheduled Procedure Step, General Purpose Performed Procedure Step and other DICOM services in the Procedure Step SOP Classes section are defined to support that communication.

K.6.2.2 General Purpose Worklist Information Model

K.6.2.2.1 E/R Model

In response to a given C-FIND request, the General Purpose Worklist SCP might have to send several C-FIND responses, (i.e. one C-FIND response per matching worklist item). Each worklist item focuses on a single General Purpose Scheduled Procedure Step and the related information. The E-R diagram presented in Figure K.6-2 depicts the content of one C-FIND request, that is:

- the matching General Purpose Scheduled Procedure Step, the list of Requested Procedures to which the General Purpose Scheduled Procedure Step contributes, the Imaging Service Request(s) in which the associated Requested Procedures are ordered, and the Patient of interest.

Therefore, for a given C-FIND request, a given General Purpose Scheduled Procedure Step will appear in only one of the resulting C-FIND responses. Obviously, information about the Requested Procedures, Imaging Service Requests, and Patients may be mentioned in several of these C-FIND responses.

In the Entity-Relationship Model, one Attribute shall be defined as the Unique Key for the General Purpose Scheduled Procedure Step. A single value in a Unique Key Attribute shall uniquely identify a single entity. That is, two entities may not have the same Unique Key value.

Note: The Unique Key in this case is the SOP Instance UID of the General Purpose Scheduled Procedure Step Instance. See Table K.6-2.

The worklist provider shall support existence and matching of the Unique Key defined by the General Purpose Worklist Information Model. All entities managed by the worklist provider shall have a specific non-zero length Unique Key value.

Unique Keys may be contained in the Identifier of a C-FIND request.

The General Purpose Worklist Information Model is represented by the Entity Relationship diagram shown in figure K.6-2.

The entry point of the General Purpose Worklist is the General Purpose Scheduled Procedure Step entity.

The attributes of a General Purpose Worklist can be found in

PS 3.3 "Patient Relationship Module"

PS 3.3 "Patient Identification Module"

PS 3.3 "Patient Demographic Module"

PS 3.3 "Patient Medical Module"

PS 3.3 "General Purpose Scheduled Procedure Step Relationship Module"

PS 3.3 "General Purpose Scheduled Procedure Step Information Module"

[pic]

Figure K.6-2.

General Purpose Worklist Information Model E-R Diagram

K.6.2.2.2 General Purpose Worklist Attributes

Table K.6-2 defines the Attributes of the General Purpose Worklist Information Model:

Table K.6-2 Attributes for the General Purpose Worklist Information Model

Description / Module Tag Match-ing Key Type Return Key Type Remark / Matching Type
SOP Common
SOP Class UID (0008,0016) O 1 Uniquely identifies the SOP Class of the General Purpose Scheduled Procedure Step. See Section K.6.2.2.3 for further explanation.
SOP Instance UID (0008,0018) U 1 Uniquely identifies the SOP Instance of the General Purpose Scheduled Procedure Step. See Section K.6.2.2.3 for further explanation. SOP Instance UID shall be retrieved with Single Value Matching.
General Purpose Scheduled Procedure Step Information
General Purpose Scheduled Procedure Step Status (0040,4001) R 1 General Purpose Scheduled Procedure Step Status shall be retrieved with Single Value Matching.
Input Availability Flag (0040,4020) R 1 Input Availability Flag shall be retrieved with Single Value Matching.
General Purpose Scheduled Procedure Step Priority (0040,4003) R 1 General Purpose Scheduled Procedure Step Priority shall be retrieved with Single Value Matching.
Scheduled Procedure Step ID (0040,0009) O 1
Scheduled Procedure Step Modification Date Time (0040,4010) O 3 Scheduled Procedure Step Modification DateTime shall be retrieved with Single Value Matching or Range Matching.
Scheduled Workitem Code Sequence (0040,4018) R 1 The Attributes of the Scheduled Workitem Code Sequence shall only be retrieved with Sequence Matching. The Scheduled Workitem Code Sequence shall contain only a single Item.
>Code Value (0008,0100) R 1 Code Value shall be retrieved with Single Value Matching.
>Coding Scheme Designator (0008,0102) R 1 Coding Scheme Designator shall be retrieved with Single Value Matching.
>Code Meaning (0008,0104) - 1 Code Meaning shall not be used as Matching Key.
Scheduled Processing Applications Code Sequence (0040,4004) O 2
>Code Value (0008,0100) O 1
>Coding Scheme Designator (0008,0102) O 1
>Code Meaning (0008,0104) - 1 Code Meaning shall not be used as Matching Key.
Scheduled Station Name Code Sequence (0040,4025) R 2 The Attributes of the Scheduled Station Name Code Sequence shall only be retrieved with Sequence Matching.
>Code Value (0008,0100) R 1 Code Value shall be retrieved with Single Value Matching.
>Coding Scheme Designator (0008,0102) R 1 Coding Scheme Designator shall be retrieved with Single Value Matching.
>Code Meaning (0008,0104) - 1 Code Meaning shall not be used as Matching Key.
Scheduled Station Class Code Sequence (0040,4026) R 2 The Attributes of the Scheduled Station Class Code Sequence shall only be retrieved with Sequence Matching.
>Code Value (0008,0100) R 1 Code Value shall be retrieved with Single Value Matching.
>Coding Scheme Designator (0008,0102) R 1 Coding Scheme Designator shall be retrieved with Single Value Matching.
>Code Meaning (0008,0104) - 1 Code Meaning shall not be used as Matching Key.
Scheduled Station Geographic Location Code Sequence (0040,4027) R 2 The Attributes of the Scheduled Station Geographic Location Code Sequence shall only be retrieved with Sequence Matching.
>Code Value (0008,0100) R 1 Code Value shall be retrieved with Single Value Matching.
>Coding Scheme Designator (0008,0102) R 1 Coding Scheme Designator shall be retrieved with Single Value Matching.
>Code Meaning (0008,0104) - 1 Code Meaning shall not be used as Matching Key.
Scheduled Procedure Step Start Date Time (0040,4005) R 1 Scheduled Procedure Step Start Date Time shall be retrieved with Single Value Matching or Range Matching.
Expected Completion Date Time (0040,4011) R 2 Expected Completion Date Time shall be retrieved with Single Value Matching or Range Matching.
Scheduled Human Performers Sequence (0040,4034) R 2 The Attributes of the Scheduled Human Performers Sequence shall only be retrieved with Sequence Matching.
>Human Performer Code Sequence (0040,4009) R 1 The Attributes of the Scheduled Human Performers Code Sequence shall only be retrieved with Sequence Matching.
>>Code Value (0008,0100) R 1 Code Value shall be retrieved with Single Value Matching.
>>Coding Scheme Designator (0008,0102) R 1 Coding Scheme Designator shall be retrieved with Single Value Matching.
>>Code Meaning (0008,0104) - 1 Code Meaning shall not be used as Matching Key.
>Human Performer's Name (0040,4037) O 3
>Human Performer's Organization (0040,4036) O 3
Referenced Performed Procedure Step Sequence (0008,1111) O 2
>Referenced SOP Class UID (0008,1150) O 1
>Referenced SOP Instance UID (0008,1155) O 1
Input Information Sequence (0040,4021) O 2
>Study Instance UID (0020,000D) O 1
>Referenced Series Sequence (0008,1115) O 1
>>Series Instance UID (0020,000E) O 1
>>Retrieve AE Title (0008,0054) O 2C Shall not be present if Storage Media File-Set ID (0088,0130) or Storage Media File-Set UID (0088,0140) is present.
>>Storage Media File-Set ID (0088,0130) O 2C Shall not be present if Retrieve AE Title (0008,0054) is present.
>>Storage Media File-Set UID (0088,0140) O 2C Shall not be present if Retrieve AE Title (0008,0054) is present.
>>Referenced SOP Sequence (0008,1199) O 1
>>>Referenced SOP Class UID (0008,1150) O 1
>>>Referenced SOP Instance UID (0008,1155) O 1
>>>Purpose of Reference Code Sequence (0040,A170) O 3
>>>>Code Value (0008,0100) - 1
>>>>Coding Scheme Designator (0008,0102) - 1
>>>>Code Meaning (0008,0104) - 1
Relevant Information Sequence (0040,4022) O 2
>Study Instance UID (0020,000D) O 1
>Referenced Series Sequence (0008,1115) O 3
>>Series Instance UID (0020,000E) O 1
>>Retrieve AE Title (0008,0054) O 2C Shall not be present if Storage Media File-Set ID (0088,0130) or Storage Media File-Set UID (0088,0140) is present.
>>Storage Media File-Set ID (0088,0130) O 2C Shall not be present if Retrieve AE Title (0008,0054) is present.
>>Storage Media File-Set UID (0088,0140) O 2C Shall not be present if Retrieve AE Title (0008,0054) is present.
>>Referenced SOP Sequence (0008,1199) O 1
>>>Referenced SOP Class UID (0008,1150) O 1
>>>Referenced SOP Instance UID (0008,1155) O 1
>>>Purpose of Reference Code Sequence (0040,A170) O 3
>>>>Code Value (0008,0100) - 1
>>>>Coding Scheme Designator (0008,0102) - 1
>>>>Code Meaning (0008,0104) - 1
Resulting General Purpose Performed Procedure Step Sequence (0040,4015) O 2 This sequence shall be updated when related General Purpose Performed Procedure Step SOP Instances are created.
>Referenced SOP Class UID (0008,1150) O 1
>Referenced SOP Instance UID (0008,1155) O 1
Actual Human Performers Sequence (0040,4035) O 2 This sequence shall be updated when this information is included in the Modify General Purpose Scheduled Procedure Step Information N-ACTION Request.
>Human Performer Code Sequence (0040,4009) O 1
>>Code Value (0008,0100) O 1
>>Coding Scheme Designator (0008,0102) O 1
>>Code Meaning (0008,0104) - 1 Code Meaning shall not be used as Matching Key.
>Human Performer's Name (0040,4037) O 3
>Human Performer's Organization (0040,4036) O 3
Study Instance UID (0020,000D) O 1 This is the Study Instance UID that shall be used to identify the Composite SOP Instances resulting from this worklist item.
Study Date (0008,0020) O 3 See note 3.
Study Time (0008,0030) O 3 See note 3.
Multiple Copies Flag (0040,4006) O 1 This Attribute shall be used to determine if multiple copies of Composite SOP Instances have to be created.
All other Attributes from the General Purpose Scheduled Procedure Step Information Module O 3
General Purpose Scheduled Procedure Step Relationship
Referenced Request Sequence (0040,A370) O 1
>Study Instance UID (0020,000D) O 1 This is the Study Instance UID that shall be used to identify an identical copy of an SR Object, in case multiple copies are created.
>Referenced Study Sequence (0008,1110) O 2
>>Referenced SOP Class UID (0008,1150) O 1
>>Referenced SOP Instance UID (0008,1155) O 1
>Requested Procedure ID (0040,1001) O 1
>Requested Procedure Description (0032,1060) O 1C The Requested Procedure Description (0032,1060) or the Requested Procedure Code Sequence (0032,1064) or both shall be supported by the SCP.
>Requested Procedure Code Sequence (0032,1064) O 1C The Requested Procedure Description (0032,1060) or the Requested Procedure Code Sequence (0032,1064) or both shall be supported by the SCP. The Requested Procedure Code Sequence shall contain only a single Item.
>>Code Value (0008,0100) O 1
>>Coding Scheme Designator (0008,0102) O 1
>>Code Meaning (0008,0104) - 1 Code Meaning shall not be used as Matching Key.
>Accession Number (0008,0050) R 2 Accession Number shall be retrieved with Single Value Matching.
>Requesting Physician (0032,1032) O 2
>All other Attributes relating to the Requested Procedure and the Imaging Service Request in the General Purpose Scheduled Procedure Step Relationship Module O 3
Patient Relationship
All Attributes from the Patient Relationship Module except those explicitly included in this Table (see Note) O 3
Patient Identification
Patient's Name (0010,0010) R 1 Patient's Name shall be retrieved with Single Value Matching or Wild Card Matching.
Patient ID (0010,0020) R 1 Patient ID shall be retrieved with Single Value Matching.
All other Attributes from the Patient Identification Module O 3
Patient Demographic
Patient's Birth Date (0010,0030) O 2
Patient's Sex (0010,0040) O 2
All other Attributes from the Patient Demographic Module O 3
Patient Medical
Pertinent Documents Sequence (0038,0100) O 3 Pertinent Documents Sequence shall be retrieved with Universal Matching only
>Referenced SOP Class UID (0008,1150) - 1
>Referenced SOP Instance UID (0008,1155) - 1
>Purpose of Reference Code Sequence (0040,A170) - 2
>>Code Value (0008,0100) - 1
>>Coding Scheme Designator (0008,0102) - 1
>>Code Meaning (0008,0104) - 1
>Document Title (0042,0010) - 2
All other Attributes from the Patient Medical Module O 3

Notes: 1. The reason for this exclusion is to assure that the attributes that may be present in multiple modules are included only once with the meaning pertaining to only one module (for example, Referenced Study Sequence (0008,1110) shall be included once with the meaning as defined in the Requested Procedure Module).

2. The use of Specific Character Set is discussed in section K.4.1.1.3.1 and K.4.1.1.3.2.

3. The values of Study Date (0008,0020) and Study Time (0008,0030) may be provided in order to achieve consistency of Study level attributes in composite instances generated in multiple performed procedure steps on different devices, and the worklist values may be updated by the SCP based on information received from General Purpose Performed Procedure Steps or by examining the composite instances generated. In the absence of these attributes, the values in the composite instances in the Input Information Sequence (0040,4021) may be used.

The attributes in Table K.6-2a are not part of the Worklist Information Model; their inclusion in the C-FIND request and response identifier are governed by rules in sections K.4.1.1.3.1 and K.4.1.1.3.2, respectively.

Table K.6-2aATTRIBUTES FOR THE GENERAL PURPOSE WORKLIST C-FIND IDENTIFIER

Description Tag Request Identifier Response Identifier Remark Type
Specific Character Set (0008,0005) 1C 1C This attribute is required if expanded or replacement character sets are used. See C.2.2.2 and K.4.1.1.3
Timezone Offset From UTC (0008,0201) 1C 1C This attribute is required if times are to be interpreted explicitly in the designated local timezone. See C.2.2.2 and K.4.1.1.3.
HL7 Structured Document Reference Sequence (0040,A390) - 1C One or more Items may be included in this sequence. Required if HL7 Structured Documents are referenced within the Identifier. See K.4.1.1.3
>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

K.6.2.2.3 Unique Identification of the General Purpose Worklist Item

The SOP Class UID and SOP Instance UID Attributes are defined for all DICOM IODs. For Normalized IODs they are not encoded in the IOD, but contained in the respective Attributes in the DIMSE Services. The General Purpose Scheduled Procedure Step SOP Instance is a persistent object, and the SOP Class UID and SOP Instance UID are included in the General Purpose Worklist. The value for this attribute originates from the SOP Instance UID assigned to the corresponding object at the time of creation by the SCP.

K.6.2.3 Conformance Requirements

An implementation may conform to the General Purpose Worklist SOP Class as an SCU and/or as an SCP.

An implementation that conforms to the General Purpose Worklist SOP Class shall also support the General Purpose Worklist Management Meta SOP Class.

The Conformance Statement shall be in the format defined in Annex A of PS 3.2.

K.6.2.3.1 SCU Conformance

An implementation that conforms to the General Purpose Worklist SOP Class shall support queries against the Worklist Information Model described in Section K.6.2.2 of this Annex using the baseline C-FIND SCU Behavior described in Section K.4.1.2 of this Annex.

An implementation that conforms to the General Purpose Worklist SOP Class as an SCU shall state in its Conformance Statement whether it requests matching on Optional Matching Key Attributes. If it requests Type 3 Return Key Attributes, then it shall list these Optional Return Key Attributes.

An implementation that conforms to the General Purpose Worklist SOP Class as an SCU shall state in its Conformance Statement whether or not it supports extended negotiation of fuzzy semantic matching of person names.

An implementation that conforms to the General Purpose Worklist SOP Class as an SCU shall state in its Conformance Statement how it makes use of Specific Character Set (0008,0005) and Timezone Offset From UTC (0008,0201) when encoding queries and interpreting responses.

K.6.2.3.2 SCP Conformance

An implementation that conforms to the General Purpose Worklist SOP Class shall support queries against the Worklist Information Model described in Section K.6.2.2 of this Annex using the C-FIND SCP Behavior described in Section K.4.1.3 of this Annex.

An implementation that conforms to the General Purpose Worklist SOP Class as an SCP shall state in its Conformance Statement whether it supports matching on Optional Matching Key Attributes. If it supports Type 3 Return Key Attributes, then it shall list all Optional Return Key Attributes which it supports.

An implementation that conforms to the General Purpose Worklist SOP Class as an SCP shall state in its Conformance Statement whether or not it supports extended negotiation of fuzzy semantic matching of person names. If fuzzy semantic matching of person names is supported, then the mechanism for fuzzy semantic matching shall be specified.

An implementation that conforms to the General Purpose Worklist SOP Class as an SCP shall state in its Conformance Statement how it makes use of Specific Character Set (0008,0005) and Timezone Offset From UTC (0008,0201) when interpreting queries, performing matching and encoding responses.

K.6.2.4 SOP Classes

The General Purpose Worklist SOP Class in the General Purpose Worklist Service Class identifies the General Purpose Worklist Information Model, and the DIMSE-C operations supported. The Standard SOP Class is shown in Table K.6.2.4-1.

Table K.6.2.4-1General Purpose Worklist SOP Class

SOP Class Name SOP Class UID
General Purpose Worklist Information Model - FIND 1.2.840.10008.5.1.4.32.1

K.6.2.5 General Purpose Worklist Management Meta SOP Class

The General Purpose Worklist Management Meta SOP Class is defined by the set of supported SOP Classes listed in Table K.6.2.5-1.

Table K.6.2.5-1General Purpose Worklist Management Meta SOP Class

SOP Class Name Reference Usage SCU/SCP
General Purpose Worklist SOP Class K.6.2 M/M
General Purpose Scheduled Procedure Step SOP Class F.10 M/M
General Purpose Performed Procedure Step SOP Class F.11 M/M

The General Purpose Worklist Management Meta SOP Class is intended for those Application Entities which conform to all of the aforementioned SOP Classes.

All requirements specified for the General Purpose Worklist Information Model SOP Class, General Purpose Scheduled Procedure Step SOP Class, and General Purpose Performed Procedure Step SOP Class shall be met by Application Entities conforming to the General Purpose Worklist Management Meta SOP Class.

K.6.2.5.1 General Purpose Worklist Management Meta SOP Class UID

The General Purpose Worklist Management Meta SOP Class shall be uniquely identified by the General Purpose Worklist Management Meta SOP Class UID which shall have the value "1.2.840.10008.5.1.4.32".

K.7 EXAMPLES FOR THE USAGE OF THE MODALITY WORKLIST (Informative)

Moved to PS 3.17

K.8 GENERAL PURPOSE WORKLIST EXAMPLE (INFORMATIVE)

Moved to PS 3.17.