PS-2020a / part04

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 PS3.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​

TheSOPClassUIDidentifiestheWorklistInformationModelagainstwhichtheC-FINDistobeperformed.SupportfortheSOPClass​ 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 PS3.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,theAttributeSpecificCharacterSet(0008,0005).ThisAttributeshallbeincludedifexpandedorreplacementcharacter​ 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 In-​ formation 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​ Section K.2.2.1.)​

•​Conditionally,theAttributeSpecificCharacterSet(0008,0005).ThisAttributeshallbeincludedifexpandedorreplacementcharacter​ setsmaybeusedinanyoftheAttributesintheResponseIdentifier.Itshallnotbeincludedotherwise.TheC-FINDSCPisnotrequired​ 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.​

- Standard -​

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​ AttributeshallbeincludedifHL7StructuredDocumentsarereferencedwithintheIdentifier,e.g.,inthePertinentDocumentsSequence​ (0038,0100).​

K.4.1.1.4 Status​

TableK.4-1definesthestatuscodevaluesthatmightbereturnedinaC-FINDresponse.Generalstatuscodevaluesandfieldsrelated​ to status code values are defined for C-FIND DIMSE Service in PS3.7.​

Table K.4-1. C-FIND Response Status Values​

Note​

Status Codes are returned in DIMSE response messages (see PS3.7). The code values stated in column "Status Codes"​ are returned in Status Command Element (0000,0900).​

Some Failure Status Codes are implementation specific.​

An SCP implementation shall assign specific failure status codes by replacing each 'x' symbol with a hexadecimal digit in the range​ from 0 to F. An SCP implementation wishing to differentiate between causes of “Failed: Unable to process” Failure Meaning shall​ assign those causes specific Status Code Values within valid range specified in Table K.4-1.​

An SCU implementation shall recognize any Failure Status Code within the value range specified in Table K.4-1 as an indicator of​ the Failure Meaning stated in the table. There is no requirement for an SCU implementation to differentiate between specific Status​ Codes within the valid range.​

K.4.1.2 C-FIND SCU Behavior​

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

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

- Standard -​

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 pos-​ sesses of the Worklist specified in the request.​

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

•​TheSCUshallinterpretaresponsewithastatusequaltoSuccess,Failed,RefusedorCanceltoconveytheendofPendingresponses.​

•​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 that meet the requirements of the "Worklist" Search (see Section K.4.1.3.1).​

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

•​TheSCPisrequestedtoperformamatchofallthekeysspecifiedintheIdentifieroftherequest,againsttheinformationitpossesses.​ 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 that contains a status of Success. A status of Success​ shall indicate that a response has been sent for each match known to the SCP.​

Note​

1.​No ID is contained in a response with a status of Success. For a complete definition, see PS3.7.​

2.​Whentherearenomatches,thennoresponseswithastatusofPendingaresent,onlyasingleresponsewithastatus​ 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 that 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​

AssociationestablishmentisthefirstphaseofanyinstanceofcommunicationbetweenpeerDICOMAEs.TheAssociationnegotiation​ procedure specified in PS3.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.​

- Standard -​

K.5.1 SOP Class Extended Negotiation​

The SOP Class Extended Negotiation allows, at Association establishment, peer DICOM AEs to exchange application Association​ informationdefinedbyspecificSOPClasses.ThisisachievedbydefiningtheService-class-application-informationfield.TheService-​ 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:​

•​literal matching of person names with case sensitivity unspecified​

•​timezone query adjustment unspecified​

TheAssociation-requester,foreachSOPClass,mayuseoneSOPClassExtendedNegotiationSub-Item.TheSOPClassisidentified​ by the corresponding Abstract Syntax Name (as defined by PS3.7) followed by the Service-class-application-information field. This​ field defines three or more sub-fields:​

•​reserved; shall always be 1​

•​reserved; shall always be 1​

•​literal or fuzzy semantic matching of person names by the Association-requester​

•​timezone query adjustment by the Association-requester​

The meaning of fuzzy semantic person name matching and of timezone query adjustment is as defined in Section K.2.2.2 and Sec-​ tion C.2.2.2.1.​

TheAssociation-acceptorshallreturnathreebytefield(threesub-fields)ifofferedathreebytefield(threesub-fields)bytheAssociation-​ requester. The Association-acceptor may return more than three bytes if offered more than three bytes by the Association-requester.​ A three byte response to a more than three byte request means that the missing sub-field shall be treated as 0 values.​

TheAssociation-acceptor,foreachsub-fieldoftheSOPClassExtendedNegotiationSub-Itemoffered,eitheracceptstheAssociation-​ 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 and timezone query adjustment is unspecified 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-ASSO-​ CIATE 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 PS3.7. This field shall be​ three or four bytes in length.​

Table K.5.1-1. SOP Class Extended Negotiation Sub-Item (Service-Class-Application-Information Field)​

- A-ASSOCIATE-RQ​

- Standard -​

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, rela-​ tional queries (Byte 1) are not relevant since the worklist information models are single level, and date-time matching (Byte​ 2)isalreadyrequiredbytheworklistinformationmodelsandEnhancedMulti-FrameImageConversionsupportisnotapplicable​ (Byte 5).​

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 PS3.7. This field shall be​ three or four bytes in length.​

Table K.5.1-2. SOP Class Extended Negotiation Sub-Item (Service-Class-Application-Information Field)​

- A-ASSOCIATE-AC​

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​ servicethatfacilitatesthecommunicationofinformationtotheimagingmodalityaboutScheduledProcedureSteps,andentitiesrelated​ 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:​

- Standard -​

•​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 that 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 that 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:​

•​thematchingScheduledProcedureStep,theRequestedProceduretowhichtheScheduledProcedureStepcontributes,theImaging​ 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 Section 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 PS3.3.​

•​Patient Relationship Module​

•​Patient Identification Module​

•​Patient Demographic Module​

•​Patient Medical Module​

•​Visit Relationship Module​

- Standard -​

•​Visit Identification Module​ •​Visit Status Module​ •​Visit Admission Module​

•​Scheduled Procedure Step Module​ •​Requested Procedure Module​ •​Imaging Service Request Module​

Worklist Item

Figure K.6-1. Modality 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-1. Attributes for the Modality Worklist Information Model​

- Standard -​

- Standard -​

>>Include Table 8-3a “Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”​

- Standard -​

Visit Identification​

- Standard -​