CC.2 DIMSE Service Groups

The DIMSE Services shown in Table CC.2-1, CC.2-2, CC.2-3 and CC.2-4 are applicable to the Unified Procedure Step (UPS) IOD under the UPS Push, UPS Pull, UPS Watch and UPS Event SOP Classes respectively.

Table CC.2-1

DIMSE SERVICE GROUP – UPS Push

DIMSE Service Element Usage SCU/SCP
N-CREATE M/M
N-ACTION – Request UPS Cancel M/M

Table CC.2-2

DIMSE SERVICE GROUP – UPS Pull

DIMSE Service Element Usage SCU/SCP
C-FIND M/M
N-GET M/M
N-SET M/M
N-ACTION –Change UPS State M/M

Table CC.2-3

DIMSE SERVICE GROUP – UPS Watch

DIMSE Service Element SCU/SCP
N-ACTION – Un/Subscribe M/M
N-GET M/M
C-FIND U/M
N-ACTION – Request UPS Cancel U/M

Table CC.2-4

DIMSE SERVICE GROUP – UPS Event

DIMSE Service Element Usage SCU/SCP
N-EVENT-REPORT M/M

CC.2.1 Change UPS State (N-ACTION)

This operation allows an SCU to ask the SCP to change the state of a Unified Procedure Step (UPS) instance. This operation shall be invoked by the SCU through the DIMSE N-ACTION Service.

CC.2.1.1 Action Information

DICOM AEs that claim conformance to the UPS Pull SOP Class as an SCU and/or an SCP shall support the Action Types and Action Information as specified in Table CC.2.1-1.

Table CC.2.1-1

Change UPS State – ACTION INFORMATION

Action Type Name Action Type ID Attribute Tag Requirement Type SCU/SCP
Change UPS State 1 Procedure Step State (0074,1000) 1/1
Transaction UID (0008,1195) 1/1

CC.2.1.2 Service Class User Behavior

An SCU uses N-ACTION to ask the SCP to change the state of a UPS Instance as shown in Figure CC.1.1-1. Since all UPSs are created as instances of the UPS Push SOP Class, the Requested SOP Class UID (0000,0003) in the N-ACTION request shall be the UID of the UPS Push SOP Class. See CC.3.1 for further details.

To take control of a SCHEDULED UPS, an SCU shall generate a Transaction UID and submit a state change to IN PROGRESS including the Transaction UID in the submission. The SCU shall record and use the Transaction UID in future N-ACTION and N-SET requests for that UPS instance.

Notes: 1. The performing SCU may wish to record the Transaction UID in non-volatile storage. This would allow the SCU to retain control over the UPS after recovering from a crash.

2. If two SCUs try to take control of a UPS, the second SCU will get an error since the first SCU established the correct Transaction UID, so the Transaction UID provided by the second SCU is incorrect.

Upon completion of an IN PROGRESS UPS it controls, an SCU shall submit a state change to COMPLETED and include the Transaction UID for the UPS instance.

To cancel an IN PROGRESS UPS for which it has the Transaction UID, an SCU shall submit a state change to CANCELED and include the Transaction UID for the UPS instance.

Notes: 1. Prior to submitting the state change to CANCELED, the performing SCU can N-SET the values of Reason For Cancellation, Procedure Step Discontinuation Reason Code Sequence, Contact Display Name or Contact URI to provide information to observing SCUs about the context of the cancellation.

2. To request cancellation of an IN PROGRESS UPS for which it does not have the Transaction UID, an SCU uses the Request UPS Cancel action as described in CC.2.2, rather than a Change UPS State action.

Prior to submitting a state change to COMPLETED or CANCELED for a UPS instance it controls, the SCU shall perform any N-SETs necessary for the UPS to meet Final State requirements as described in section CC.2.5.1.1.

At any time after receipt of the N-ACTION-Response, the SCU may release the association on which it sent the N-ACTION-Request.

CC.2.1.3 Service Class Provider Behavior

The SCP shall perform the submitted state change for the identified UPS instance by setting the Procedure Step State (0074,1000) to the requested value, or shall report the appropriate failure response code.

Upon successfully changing the state of a UPS instance to IN PROGRESS, the SCP shall record the Transaction UID provided by the SCU in the Transaction UID (0008,1195) of the UPS instance.

Upon completion of the N-ACTION request, the SCP shall return, via the N-ACTION response primitive, the N-ACTION Status Code applicable to the associated request as shown in Table CC.2.1-2.

The SCP shall only perform legal state changes as described in Table CC.1.1-2.

The SCP shall refuse requests to change the state of an IN PROGRESS UPS unless the Transaction UID of the UPS instance is provided in the N-ACTION request.

The SCP shall refuse requests to change the state of an IN PROGRESS UPS to COMPLETED or CANCELED if the Final State requirements described in Table CC.2.5-3 have not been met.

After the state of the UPS instance has been changed to COMPLETED or CANCELED, the SCP shall not delete the instance until all deletion locks have been removed.

Note: See CC.2.3.2 for a description of how SCUs place and remove deletion locks and see PS 3.17 GGG.1 Reliable Watchers and Deletion Locks for further discussion.

The SCP may also modify the Procedure Step State (0074,1000) of a UPS instance independently of an N-ACTION request, e.g., if the SCP is performing the procedure step itself, or if it has been determined that the performing SCU has been disabled.

Note: If the SCP is not performing the procedure step, this should be done with caution.

Upon successfully changing the state of a UPS instance, the SCP shall carry out the appropriate N-EVENT-REPORT behavior as described in CC.2.4.3 if it supports the UPS Event SOP Class as an SCP.

Bi-directional Authentication of machines/users/applications is possible at association time (see PS 3.7 and PS 3.15). PS 3.7 provides a “Refused: Not Authorized” error code. Further requiring or documenting authentication and/or authorization features from the SCU or SCP is beyond the scope of this SOP Class.

CC.2.1.4 Status Codes

The status values which are specific for this DIMSE operation are defined in Table CC.2.1-2.

Table CC.2.1-2

STATUS VALUES

Status Meaning Code
Success The requested state change was performed 0000
Warning The UPS is already in the requested state of CANCELED B304
The UPS is already in the requested state of COMPLETED B306
Failure Refused: The UPS may no longer be updated C300
Refused: The correct Transaction UID was not provided C301
Refused: The UPS is already IN PROGRESS C302
Refused: The UPS may only become SCHEDULED via N-CREATE, not N-SET or N-ACTION C303
Refused: The UPS has not met final state requirements for the requested state change C304
Specified SOP Instance UID does not exist or is not a UPS Instance managed by this SCP C307
Refused: The UPS is not yet in the “IN PROGRESS” state C310

CC.2.2 Request UPS Cancel (N-ACTION)

This operation allows an SCU which does not control a given Unified Procedure Step (UPS) instance to request to the SCP that the instance be canceled. This operation shall be invoked by the SCU through the DIMSE N-ACTION Service.

CC.2.2.1 Action Information

DICOM AEs that claim conformance to the UPS Push SOP Class as an SCU or an SCP shall support the Action Types and Action Information as specified in Table CC.2.2-1. DICOM AEs that claim conformance to the UPS Watch SOP Class as an SCP or claim conformance to the UPS Watch SOP Class as an SCU and choose to implement Request UPS Cancel shall support the Action Types and Action Information as specified in Table CC.2.2-1.

Table CC.2.2-1

Request UPS Cancel – ACTION INFORMATION

Action Type Name Action Type ID Attribute Tag Requirement Type SCU/SCP
Request UPS Cancel 2 Reason For Cancellation (0074,1238) 3/1
Procedure Step Discontinuation Reason Code Sequence (0074,100e) 3/1
>Code Value (0008,0100) 1/1
>Coding Scheme Designator (0008,0102) 1/1
>Coding Scheme Version (0008,0103) 1C/1C Required if the value of Coding Scheme Designator (0008,0102) is not sufficient to identify the Code Value (0008,0100) unambiguously
>Code Meaning (0008,0104) 1/1
Contact URI (0074,100a) 3/1
Contact Display Name (0074,100c) 3/1

CC.2.2.2 Service Class User Behavior

An SCU uses N-ACTION to request to the SCP that the state of a UPS Instance be changed to CANCELED as shown in Figure CC.1.1-1. Since all UPSs are created as instances of the UPS Push SOP Class, the Requested SOP Class UID (0000,0003) in the N-ACTION request shall be the UID of the UPS Push SOP Class. See CC.3.1 for further details.

The SCU may include a Reason For Cancellation and/or a proposed Procedure Step Discontinuation Reason Code Sequence.

The SCU may also provide a Contact Display Name and/or a Contact URI for the person with whom the cancel request may be discussed.

Note: An N-ACTION Status Code indicating success means that the Request was accepted, not that the UPS has been canceled. The system performing the UPS is not obliged to honor the request to cancel and in some scenarios, may not even receive notification of the request. See CC.2.4.

At any time after receipt of the N-ACTION-Response, the SCU may release the association on which it sent the N-ACTION-Request.

To cancel an IN PROGRESS UPS which the SCU is itself performing, the SCU shall instead use the Change UPS State action as described in CC.2.1.

CC.2.2.3 Service Class Provider Behavior

The SCP shall send appropriate “UPS Cancel Requested” N-EVENT-REPORT messages, as described in CC.2.4.3 or shall report the appropriate failure response code.

Note: If provided, the Reason For Cancellation, a proposed Procedure Step Discontinuation Reason Code Sequence, a Contact Display Name and a Contact URI of someone responsible for the Cancel request might be useful in deciding to cancel the UPS or might be displayed to an operator so they can make contact for the purpose of clarifying or confirming the Cancel request. If the SCP is the performer and chooses to actually Cancel the UPS, it may at its own discretion set the Procedure Step Discontinuation Reason Code Sequence in the UPS instance based on the corresponding values provided.

If the Procedure Step State (0074,1000) of the UPS instance is still SCHEDULED, the SCP shall change the Procedure Step State, as described in CC.2.1.3, first to IN PROGRESS and then to CANCELED, ensuring that the Final State requirements, described in section CC.2.5.1.1, are met.

If the Procedure Step State (0074,1000) of the UPS instance is IN PROGRESS, and the SCP is itself the performer of the UPS, the SCP may, at its own discretion, choose to cancel the UPS as described in CC.2.1.3.

If the SCP is the performer of the UPS and chooses not to cancel, or if there is no possibility that the performing SCU will be informed of the cancel request (e.g. the subscription list for the UPS is empty, or the SCP has determined that the performing SCU has been disabled), the SCP may return a failure.

Upon completion of the N-ACTION request, the SCP shall return, via the N-ACTION response primitive, the N-ACTION Status Code applicable to the associated request as shown in Table CC.2.2-2.

Bi-directional Authentication of machines/users/applications is possible at association time (see PS 3.7 and PS 3.15). PS 3.7 provides a “Refused: Not Authorized” error code. Further requiring or documenting authentication and/or authorization features from the SCU or SCP is beyond the scope of this SOP Class.

CC.2.2.4 Status Codes

The status values which are specific for this DIMSE operation are defined in Table CC.2.2-2.

Table CC.2.2-2

STATUS VALUES

Status Meaning Code
Success The cancel request is acknowledged 0000
Warning The UPS is already in the requested state of CANCELED B304
Failure Refused: The UPS is already COMPLETED C311
Refused: Performer chooses not to cancel C313
Specified SOP Instance UID does not exist or is not a UPS Instance managed by this SCP C307
Refused: The performer cannot be contacted C312

CC.2.3 Subscribe/Unsubscribe to Receive UPS Event Reports (N-ACTION)

This operation allows an SCU to subscribe with an SCP in order to receive N-EVENT-REPORTS of subsequent changes to the state of a UPS instance, or to unsubscribe in order to no longer receive such N-EVENT-REPORTs. This operation shall be invoked by the SCU through the DIMSE N-ACTION Service.

CC.2.3.1 Action Information

DICOM AEs that claim conformance to the UPS Watch SOP Class as an SCU and/or an SCP shall support the Action Types and Action Information as specified in Table CC.2.3-1.

Table CC.2.3-1

Subscribe/Unsubscribe to Receive UPS Event Reports – ACTION INFORMATION

Action Type Name Action Type ID Attribute Tag Requirement Type SCU/SCP
Subscribe to Receive UPS Event Reports 3 Receiving AE (0074,1234) 1/1
Deletion Lock (0074,1230) 1/1
Unsubscribe from Receiving UPS Event Reports 4 Receiving AE (0074,1234) 1/1
Suspend Global Subscription 5 Receiving AE (0074,1234) 1/1

Each AE may be in one of three UPS Subscription States for each existing UPS Instance: Not Subscribed, Subscribed with Deletion Lock, or Subscribed w/o Deletion Lock. The UPS Subscription State determines whether N-EVENT-REPORTs relating to a UPS Instance will be sent to the AE.

Each AE may also be in one of three Global Subscription States for a given SCP: No Global Subscription, Globally Subscribed with Deletion Lock, Globally Subscribed w/o Deletion Lock. The Global Subscription State mainly determines the initial UPS Subscription State for an AE and new UPS Instances created by the SCP. Changes to the Global Subscription State can also change the UPS Subscription State for existing UPS Instances as described in Table CC.2.3-2.

The three Subscription actions in Table CC.2.3-1 are used to manage the UPS Subscription State and Global Subscription State of an AE.

Table CC.2.3-2 describes the UPS Subscription State transitions of an AE for a given UPS Instance. Each row in the table defines what should happen in response to a Subscription Action, or a UPS creation event, given the initial state. The table also shows when an initial event message should be sent to the AE describing the “Current UPS State”.

Note: In general, instance specific instructions take precedence over global instructions. The exception is the Unsubscribe Globally instruction, which removes all subscriptions, global and specific. To simply stop globally subscribing to new instances without removing specific subscriptions, use the Suspend Global Subscription message.

Most actions affect only the UPS Subscription State of a single UPS Instance. However, Global actions potentially affect all existing UPS Instances managed by the SCP and this is indicated in the following table by “ All ”. For example, in the “AE Subscribes Globally with Lock” row, the content of the “Not Subscribed” cell means that in addition to setting the Global Subscription State for the AE to “Global Subscription with Lock”, all existing UPS Instances whose UPS Subscription State for the Receiving AE is “Not Subscribed” will each have their UPS Subscription State changed to “Subscribed with Lock” and an event will be sent to the Receiving AE for each Instance.

Table CC.2.3-2

UPS SUBSCRIPTION STATE TRANSITION TABLE

States (for a specific UPS and AE)
Events null Not Subscribed Subscribed with Lock Subscribed w/o Lock
A UPS is Created when the AE Global Subscription State is ”No Global Subscription” Go to Not Subscribed N/A N/A N/A
A UPS is Created when the AE Global Subscription State is ”Global Subscription with Lock” Go to Subscribed with Lock; Send initial event N/A N/A N/A
A UPS is Created when the AE Global Subscription State is ”Global Subscription w/o Lock” Go to Subscribed w/o Lock; Send initial event N/A N/A N/A
AE Subscribes Globally with Lock N/A AE Global State is now “Global Sub. with Lock”; All Go to Subscribed with Lock; All Send initial event AE Global State is now “Global Sub. with Lock”; No UPS state change; AE Global State is now “Global Sub. with Lock”; No UPS state change;
AE Subscribes Globally w/o Lock N/A AE Global State is now “Global Sub. w/o Lock”; All Go to Subscribed w/o Lock; AE Global State is now “Global Sub. w/o Lock”; No UPS state change; AE Global State is now “Global Sub. w/o Lock”; No UPS state change;
AE Subscribes to Specific UPS with Lock N/A Go to Subscribed with Lock; Send initial event No UPS state change; Send initial event Go to Subscribed with Lock; Send initial event
AE Subscribes to Specific UPS without Lock N/A Go to Subscribed w/o Lock; Send initial event Go to Subscribed w/o Lock; Send initial event No UPS state change; Send initial event
AE Unsubscribes from Specific UPS N/A No UPS state change Go to Not Subscribed Go to Not Subscribed
AE Unsubscribes Globally N/A AE Global State is now “No Global Subscription”; No UPS state change; AE Global State is now “No Global Subscription”; All Go to Not Subscribed; AE Global State is now “No Global Subscription”; All Go to Not Subscribed;
AE Suspends Global Subscription N/A AE Global State is now “No Global Subscription”; No UPS state change; AE Global State is now “No Global Subscription”; No UPS state change; AE Global State is now “No Global Subscription”; No UPS state change;

See PS 3.17 GGG.1 Reliable Watchers and Deletion Locks for further discussion of deletion locks.

CC.2.3.2 Service Class User Behavior

The SCU subscribing to track the progress and results of the scheduled procedure step may be the system that created the UPS as an SCU of the UPS Push SOP Class, or it may be some other interested observer.

An SCU shall use the N-ACTION primitive to request the SCP to subscribe an AE (usually the requesting SCU) to receive event reports relating to UPS instances managed by the SCP. Since all UPSs are created as instances of the UPS Push SOP Class, the Requested SOP Class UID (0000,0003) in the N-ACTION request shall be the UID of the UPS Push SOP Class. See CC.3.1 for further details.

An SCU shall also use the N-ACTION primitive to request the SCP to unsubscribe an AE to stop receiving event reports relating to UPS instances managed by the SCP. Action Information is specified in Table CC.2.3-1. The SCU shall always provide the AE-TITLE which is to receive (or stop receiving) the N-EVENT-REPORTs.

To subscribe for events relating to a single specific UPS instance managed by the SCP, the SCU shall use Action Type ID 3 (Subscribe to Receive UPS Event Reports) and provide the SOP Instance UID of the specific UPS instance in the N-ACTION primitive request. The SCU shall indicate a need for the UPS instance to persist after its state has changed to COMPLETED or CANCELED by setting the value of the Deletion Lock to TRUE. Otherwise the SCU shall set the value of the Deletion Lock to FALSE.

To unsubscribe for events relating to a single specific UPS instance managed by the SCP, the SCU shall use Action Type ID 4 (Unsubscribe from Receiving UPS Event Reports) and provide the SOP Instance UID of the specific UPS instance in the N-ACTION primitive request.

To subscribe for events relating to all current and subsequently created UPS instances managed by the SCP, the SCU shall use Action Type ID 3 (Subscribe to Receive UPS Event Reports) and provide the well-known UID 1.2.840.10008.5.1.4.34.5 in the N-ACTION primitive request. The SCU shall indicate a need for UPS instances to persist after their states have changed to COMPLETED or CANCELED by setting the value of the Deletion Lock to TRUE. Otherwise the SCU shall set the value of the Deletion Lock to FALSE.

Note: This “global subscription” is useful for SCUs that wish to monitor all activities without having to issue regular C-FINDs to identify new UPS instances.

To unsubscribe for events relating to all current UPS instances managed by the SCP and also stop being subscribed to subsequently created UPS instances, the SCU shall use Action Type ID 4 (Unsubscribe from Receiving UPS Event Reports) and provide the well-known UID 1.2.840.10008.5.1.4.34.5 in the N-ACTION primitive request.

Note: This “global unsubscription” is useful for SCUs that wish to stop monitoring all activities and release all deletion locks (if any) placed for this subscriber.

To just stop being subscribed to subsequently created UPS instances, but still continue to receive events for currently subscribed instances managed by the SCP, the SCU shall use Action Type ID 5 (Suspend Global Subscription) and provide the well-known UID 1.2.840.10008.5.1.4.34.5 in the N-ACTION primitive request.

For each UPS instance on which the SCU has placed a deletion lock, either explicitly on the specific instance or implicitly via a global subscription with lock, the SCU shall remove the deletion lock once any needed final state information for the instance has been obtained. The deletion lock may be removed either by unsubscribing or by subscribing with the value of the Deletion Lock set to FALSE.

Note: The SCP will retain COMPLETED or CANCELED UPS Instances until all deletion locks have been released. Failure by SCUs to release the deletion lock may cause problems for the SCP. SCU’s which do not have a significant need for the final state information, or who cannot dependably remove deletion locks should not use deletion locks.

The successful N-ACTION Response Status Code indicates that the SCP has received the N-ACTION request and the Subscription State for the AE has been successfully modified.

Note: When subscribing to a specific instance, the SCU can also expect to receive an initial N-EVENT-REPORT containing the current state of the UPS instance. When subscribing globally with the Deletion Lock set to TRUE, the SCU can expect to receive initial N-EVENT-REPORTs for every instance currently managed by the SCP. Initial N-EVENT-REPORTs for newly created instances, received as a result of a global subscription, will appear as transitions to the SCHEDULED state.

A warning N-ACTION Response Status Code of “Deletion Lock not granted”, indicates that the AE subscription requested by the SCU was successful, but the deletion lock has not been set.

A failure N-ACTION Response Status Code indicates that the subscription state change requested will not be processed and no subscription states have been changed. The action taken by the SCU upon receiving this status is beyond the scope of this Standard.

At any time after receipt of the N-ACTION-Response, the SCU may release the association on which it sent the N-ACTION-Request.

CC.2.3.3 Service Class Provider Behavior

Upon receipt of the N-ACTION request, the SCP shall attempt to update the Global Subscription State and/or UPS Subscription State of the specified AE with respect to the specified SOP Instance UID as described in Table CC.2.3-2 and then return, via the N-ACTION response primitive, the appropriate N-ACTION Response Status Code.

A success status conveys that the Global Subscription State and/or UPS Subscription State for the AE specified in Receiving AE (0074,1234) was successfully modified by the SCP. The AE-TITLE in Receiving AE (0074,1234) may be different than the AE-TITLE used by the SCU for the association negotiation. The SCP shall use the AE-TITLE specified in Receiving AE (0074,1234). This allows systems to subscribe other systems they know would be interested in events for a certain UPS.

For all UPS instances managed by the SCP, the SCP shall send N-EVENT-REPORTS (as described in CC.2.4.3) to AEs that have a UPS Subscription State of “Subscribed with Lock” or “Subscribed w/o Lock”.

Upon successfully processing a subscription action, the SCP shall send initial UPS State Report N-EVENT-REPORTs, as indicated in Table CC.2.3-2, providing the current status of the UPS Instance to the Receiving AE.

The SCP may also refuse both specific and global Subscription requests by returning a failure N-ACTION Response Status Code for “Refused: Not Authorized” if the refusal depends on permissions related to the tasks or the requestor, or “Refused: SCP does not support Event Reports” if the SCP does not support sending the events. The SCP must document in its conformance statement if it might refuse Subscription requests.

The SCP may remove existing Deletion Locks by changing the UPS Subscription State for the AE from “Subscribed with Lock” to “Subscribed w/o Lock” and/or by changing the Global Subscription State for an AE from “Global Subscription with Lock” to “Global Subscription w/o Lock”. This is intended to allow the SCP to deal with SCU malfunctions. The SCP must document in its conformance statement if it might remove a Deletion Lock.

The SCP may also refuse the Deletion Lock portion of a specific or global Subscription request. For example, a request to modify the UPS Subscription State for the AE to “Subscribed with Lock” would instead result in a UPS Subscription State of “Subscribed w/o Lock” and a Warning status (see Table CC.2.3-3) returned to the requesting SCU. This is intended to deal with Security and related policy restrictions. The SCP must document in its conformance statement if it might refuse a Deletion Lock.

Bi-directional Authentication of machines/users/applications is possible at association time (see PS 3.7 and PS 3.15). PS 3.7 provides a “Refused: Not Authorized” error code. Further requiring or documenting authentication and/or authorization features from the SCU or SCP is beyond the scope of this SOP Class.

CC.2.3.4 Status Codes

The status values which are specific for this DIMSE operation are defined in Table CC.2.3-3.

Table CC.2.3-3

STATUS VALUES

Status Meaning Code
Success The requested change of subscription state was performed 0000
Warning Deletion Lock not granted. B301
Failure Specified SOP Instance UID does not exist or is not a UPS Instance managed by this SCP C307
Receiving AE-TITLE is Unknown to this SCP C308
Refused: Specified action not appropriate for specified instance C314
Refused: SCP does not support Event Reports C315

CC.2.4 Report a Change in UPS Status (N-EVENT-REPORT)

This operation allows an SCP to notify an SCU of a change in state of a UPS instance or a change in state of the SCP itself. This operation shall be invoked by the SCP through the DIMSE N-EVENT-REPORT Service.

CC.2.4.1 Event Report Information

DICOM AEs that claim conformance to the UPS Event SOP Class as an SCU and/or an SCP shall support the Event Type IDs and Event Report Attributes as specified in Table CC.2.4-1.

Table CC.2.4-1

Report a Change in UPS Status - EVENT REPORT INFORMATION

Event Type Name Event Type ID Attribute Tag Req. Type SCU/SCP
UPS State Report 1 Procedure Step State (0074,1000) -/1
Input Readiness State (0040,4041) -/1
Reason For Cancellation (0074,1238) -/3
Procedure Step Discontinuation Reason Code Sequence (0074,100e) -/3
>Code Value (0008,0100) -/1
>Coding Scheme Designator (0008,0102) -/1
>Coding Scheme Version (0008,0103) -/1C Required if the value of Coding Scheme Designator (0008,0102) is not sufficient to identify the Code Value (0008,0100) unambiguously
>Code Meaning (0008,0104) -/1
UPS Cancel Requested 2 Requesting AE (0074,1236) -/1
Reason For Cancellation (0074,1238) -/1C Required if provided in the triggering N-ACTION
Procedure Step Discontinuation Reason Code Sequence (0074,100e) -/1C Required if provided in the triggering N-ACTION
>Code Value (0008,0100) -/1
>Coding Scheme Designator (0008,0102) -/1
>Coding Scheme Version (0008,0103) -/1C Required if the value of Coding Scheme Designator (0008,0102) is not sufficient to identify the Code Value (0008,0100) unambiguously
>Code Meaning (0008,0104) -/1
Contact URI (0074,100a) -/1C Required if provided in the triggering N-ACTION
Contact Display Name (0074,100c) -/1C Required if provided in the triggering N-ACTION
UPS Progress Report 3 Progress Information Sequence (0074,1002) -/1
>Procedure Step Progress (0074,1004) -/3
>Procedure Step Progress Description (0074,1006) -/3
>Procedure Step Communications URI Sequence (0074,1008) -/3
>>Contact URI (0074,100a) -/1
>>Contact Display Name (0074,100c) -/3
SCP Status Change 4 SCP Status (0074,1242) -/1
Subscription List Status (0074,1244) -/1
Unified Procedure Step List Status (0074,1246) -/1

Note: The meanings of the Progress Information attribute values in the context of a specific task are undefined, and the values may be obsolete when the UPS has moved to the COMPLETED or CANCELED state.

CC.2.4.2 Service Class User Behavior

The SCU shall return, via the N-EVENT-REPORT response primitive, the N-EVENT-REPORT Response Status Code applicable to the associated request. See PS 3.7 for general response status codes.

The SCU shall accept all Attributes included in any notification. No requirements are placed on what the SCU will do as a result of receiving this information.

Note: An SCU may receive N-EVENT-REPORTs with an Event Type ID of 1 (UPS State Report) either due to a state change to the UPS, or in response to initial subscription to the UPS (possibly when the UPS is initially created). See CC.2.3.3.

If an SCU performing a UPS receives an N-EVENT-REPORT for that instance with an Event Type ID of 2 (UPS Cancel Requested), then this SCU may, at its own discretion, choose to cancel the UPS as described in CC.2.1.2.

Notes: 1. A UPS Cancel Requested notification includes the AE of the Requesting SCU which could be useful to the performing SCU in deciding the significance/authority of the Cancel Request.

2. The Reason For Cancellation, a proposed Procedure Step Discontinuation Reason Code Sequence, a Contact Display Name and a Contact URI of someone responsible for the Cancel Request may also be provided in the notification. Some performing SCUs might find this information useful in deciding to cancel the UPS or might provide the information to an operator so they can make contact for the purpose of clarifying or confirming the Cancel Request. If the performing SCU chooses to Cancel the UPS, it may at its own discretion set the Procedure Step Discontinuation Reason Code Sequence in the UPS instance based on the corresponding values provided.

An SCU that wishes to start/stop receiving N-EVENT-REPORTs about UPS instances may subscribe/unsubscribe as described in CC.2.3.2.

If an SCU receives an N-EVENT-REPORT with an Event Type ID of 4 (SCP Status Change), it is not required to act on that information, however the SCU may want to consider actions such as: re-subscribing if the subscription list has been Cold Started, verifying (and recreating if necessary) scheduled UPSs if the UPS list has been Cold Started, etc.

Note: An SCU may receive SCP State Change Events from any SCP with which it is currently subscribed either globally or for any specific UPS.

CC.2.4.3 Service Class Provider Behavior

The SCP shall specify in the N-EVENT-REPORT Request Primitive the Event Type ID and the UID of the UPS Instance with which the event is associated. Since all UPSs are created as instances of the UPS Push SOP Class, the Affected SOP Class UID (0000,0002) in the N-EVENT-REPORT request shall be the UID of the UPS Push SOP Class. See CC.3.1 for further details. The SCP shall additionally include Attributes related to the event as defined in Table CC.2.4-1.

Each time the SCP completes a Subscribe to Receive UPS Event Reports Action (See CC.2.3.1) for a specific UPS instance, the SCP shall send to the Receiving AE a UPS State Report Event and provide the current value of the Procedure Step State (0074,1000) and Input Readiness State (0040,4041) attributes for the UPS instance.

Each time the SCP completes a Subscribe to Receive UPS Event Reports Action (See CC.2.3.1) for the well-known UID 1.2.840.10008.5.1.4.34.5 with the value of the Deletion Lock set to TRUE (i.e. a Global Subscription with Lock), the SCP shall send to the Receiving AE a UPS State Report Event for every UPS Instance managed by the SCP and provide the current value of the Procedure Step State (0074,1000) and Input Readiness State (0040,4041) attributes.

Each time the SCP creates a new UPS instance, the SCP shall send a UPS State Report Event, indicating a change of status to SCHEDULED and the initial value of and Input Readiness State (0040,4041), to all AEs with a Global Subscription State of “Global Subscription with Lock” or “Global Subscription w/o Lock”. (See CC.2.3)

In the following text “Subscribed SCUs” means all AEs where the UPS Subscription State of the UPS Instance in question is “Subscribed with Lock” or “Subscribed w/o Lock”. (See CC.2.3).

Each time the SCP changes the Procedure Step State (0074,1000) attribute for a UPS instance, the SCP shall send a UPS State Report Event to subscribed SCUs.

Each time the SCP changes the Input Readiness State (0040,4041) attribute for a UPS instance, the SCP shall send a UPS State Report Event to subscribed SCUs.

Each time the SCP receives an N-ACTION with an Action Type ID of 2 (Request UPS Cancel), the SCP shall send a UPS Cancel Requested Event to subscribed SCUs. The SCP shall include the AE Title of the triggering N-ACTION SCU in the Requesting AE attribute. The SCP shall include the Reason For Cancellation, Contact Display Name and Contact URI attributes if they were provided in the triggering N-ACTION.

Each time the SCP updates the Procedure Step Progress (0074,1004), the Procedure Step Progress Description (0074,1006), or the contents of the Procedure Step Communications URI Sequence (0074,1008) for a UPS instance, the SCP shall send a UPS Progress Event, with the current contents of the Progress Information Sequence (0074,1002), to subscribed SCUs.

Each time the SCP is restarted, the SCP shall send an SCP Status Change Event. The SCP, if it knows it is going down, may send an additional SCP Status Change Event before it is shut down. Since the subscription lists may be incomplete or missing in the event of a restart, the SCP shall maintain a fallback list of AEs (for example as a configuration file, or from an LDAP server). The SCP shall send the SCP Status Change Events to:

Note: The SCP may choose to not send duplicate messages to an AE.

The value of SCP Status (0074,1242) shall be RESTARTED if the SCP is sending this message due to being restarted and GOING DOWN if the SCP will be shut down soon.

Note: SCPs that report they are GOING DOWN might stop accepting new interactions from SCUs until after they have restarted.

When SCP Status (0074,1242) is RESTARTED, the value of Subscription List Status (0074,1244) shall be WARM START if the SCP preserved the Subscription List to the best of its knowledge, and COLD STARTED if the SCP has not preserved the Subscription List.

When SCP Status (0074,1242) is RESTARTED, the value of Unified Procedure Step List Status (0074,1246) shall be WARM START if the SCP preserved the UPS List to the best of its knowledge, and COLD START if the SCP has not preserved the UPS List.

If the SCP is unable to successfully complete an N-EVENT-REPORT to any given SCU, the SCP has no obligation to queue or retry, and it should not imply any effect on the subscription list or deletion locks.

CC.2.4.4 Status Codes

No Service Class specific status values are defined for the N-EVENT-REPORT Service. See PS 3.7 for general response status codes.

CC.2.5 Create a Unified Procedure Step (N-CREATE)

This operation allows an SCU to instruct an SCP to create a Unified Procedure Step. This operation shall be invoked by the SCU through the DIMSE N-CREATE Service.

CC.2.5.1 Unified Procedure Step Attribute Specification

An Application Entity that claims conformance to the UPS Push SOP Class as an SCU shall provide all Required Attributes as specified in Table CC.2.5-3. Additional Attributes defined by the UPS IOD may be provided as well.

An Application Entity that claims conformance to the UPS Push SOP Class as an SCP shall support all required Attributes as specified in Table CC.2.5-3. Additional Attributes defined by the UPS IOD may be supported as well.

CC.2.5.1.1 UPS Final State Requirements

COMPLETED and CANCELED are Final States for a UPS instance. The attributes and values of the UPS instance must meet certain requirements before it may be placed in either of the Final States.

Note: A UPS instance is in the SCHEDULED state when created. See CC.1.1 for rules governing state transitions.

Attributes shall be valued as indicated by the Final State Codes in the Final State Column of Table CC.2.5-3 before the Procedure Step State (0074,1000) may be set to COMPLETED or CANCELED (i.e. Final State).

Performing systems are encouraged to ensure that the values for all attributes reasonably reflect what was done and the Final State of the UPS. This may include blanking attributes which are permitted to be empty and for which no reasonable value can be determined. The UPS contents should make it clear whether the step was completed, what work was done, what results were produced and whether the results are usable. See PS 3.17 Section GGG.7 for a discussion of methods to convey things like partial completion.

Note: The SCU may choose not to distribute, or otherwise make available, some or all instances created during the procedure step and referenced in the Output Information Sequence (0040,4033).

Table CC.2.5-1

Final State Codes

Final State Code Meaning
R The UPS State shall not be set to COMPLETED or CANCELED if this attribute does not have a value.
RC The UPS State shall not be set to COMPLETED or CANCELED if the condition is met and this attribute does not have a value.
P The UPS State shall not be set to COMPLETED if this attribute does not have a value, but may be set to CANCELED.
X The UPS State shall not be set to CANCELED if this attribute does not have a value, but may be set to COMPLETED.
O The UPS State may be set to either COMPLETED or CANCELED if this attribute does not have a value.

CC.2.5.1.2 UPS Macros

To reduce the size and complexity of Table CC.2.5-3, a macro notation is used.

For example, in Table CC.2.5-3, a table entry specifying “Include Code Sequence Macro Table CC.2.5-2a” should be interpreted as including the following table of text as a substitution. The nesting level for the sequence inclusion is indicated by the nesting level on the reference to the macro. Where the matching key type requirement is “*” it should be replaced with the matching key type requirement of the sequence attribute that incorporates this macro.

For code sequences that have requirements for N-CREATE, N-SET, N-GET, or C-FIND behavior that differ from the Macro, the code sequence contents are explicitly listed in the Table rather than specifying inclusion of the Macro.

Table CC.2.5-2aUPS Code Sequence Macro

Attribute Name Tag
DateTime (0040,A120)
Numeric Value (0040,A30A)

Table CC.2.5-2c Referenced Instances and Access Macro

Attribute Name Tag
>Assigning Jurisdiction Code Sequence (0040,0039)
>Assigning Agency or Department Code Sequence (0040,003A)

Table CC.2.5-2f SOP Instance Reference Macro

Attribute Name
Specific Character Set
Scheduled Procedure Step Priority
Scheduled Station Name Code Sequence
Scheduled Station Class Code Sequence
Scheduled Station Geographic Location Code Sequence
Scheduled Human Performers Sequence
>Human Performer’s Name
Comments on the Scheduled Procedure Step
Study Instance UID
Patient’s Name
Other Patient IDs Sequence
Patient’s Birth Date
Admitting Diagnoses Description
Referenced Request Sequence
>Placer Order Number/Imaging Service Request
>Filler Order Number/Imaging Service Request
>Requested Procedure ID
>Reason for the Requested Procedure
>Requested Procedure Comments
Medical Alerts
Procedure Step State
Unified Procedure Step Performed Procedure Information Module
Unified Procedure Step Performed Procedure Sequence
>>Human Performer’s Name
>Performed Station Class Code Sequence
>Performed Station Geographic Location Code Sequence
>Performed Procedure Step Start DateTime
>Performed Processing Parameters Sequence
>Performed Procedure Step End DateTime

CC.2.5.2 Service Class User Behavior

An SCU uses N-CREATE to request the SCP schedule a new UPS.

The SCU shall specify in the N-CREATE request primitive the UPS Push SOP Class UID and the SOP Instance UID for the UPS which is to be created and for which Attribute Values are to be provided. See CC.3.1 for further discussion of UPS SOP Class UIDs.

The SCU shall provide Attribute values in the N-CREATE request primitive for all required UPS Attributes as specified in Table CC.2.5-3. Additionally, values may be provided for optional Attributes as specified in Table CC.2.5-3.

The SCU shall specify a value of “SCHEDULED” for the attribute Procedure Step State (0074,1000) in the N-CREATE request primitive.

CC.2.5.3 Service Class Provider Behavior

The SCP shall create and maintain UPS instances as instructed by N-CREATE requests and as specified by Table CC.2.5-3.

The SCP shall return, via the N-CREATE response primitive, the N-CREATE Response Status Code applicable to the associated request.

The SCP shall accept N-CREATE request primitives only if the value of the Procedure Step State (0074,1000) attribute is “SCHEDULED”. If the Procedure Step State attribute has another value, the SCP shall fail the N-CREATE.

The SCP may modify Attributes of a UPS instance, e.g., to correct invalid attribute values. A description of the modifications the SCP may perform shall be documented in the conformance statement of the SCP.

The SCP may also create and maintain UPS instances without receiving a UPS instance N-CREATE request, e.g., based on internal logic, operator inputs or HL7 messages. The contents of the instance created by the SCP must still comply with the N-CREATE requirements in Table CC.2.5-3.

Upon creating a new UPS Instance, the SCP shall update UPS Subscription Status of the Instance for each AE with a Global Subscription as described in CC.2.3.

Upon creating a new UPS Instance, the SCP shall send UPS State Reports (if it supports the UPS Event SOP Class) as described in CC.2.4.3 regardless of whether the creation was based on an N-CREATE or on internal logic.

Bi-directional Authentication of machines/users/applications is possible at association time (see PS 3.7 and PS 3.15). PS 3.7 provides a “Refused: Not Authorized” error code. There are no specific requirements to perform authorization.

CC.2.5.4 Status Codes

The status values which are specific for this DIMSE operation are defined in Table CC.2.5-4.

Table CC.2.5-4

STATUS VALUES

Status Meaning Code
Success The UPS was created as requested 0000
Warning The UPS was created with modifications B300
Failure Refused: The provided value of UPS State was not “SCHEDULED”. C309

CC.2.6 Set Unified Procedure Step Information (N-SET)

This operation allows an SCU to set Attribute Values of a UPS Instance and provide information about a specific real-world UPS that is under control of the SCU. This operation shall be invoked by the SCU through the DIMSE N-SET Service.

CC.2.6.1 Unified Procedure Step IOD Subset Specification

The Application Entity which claims conformance to the UPS Pull SOP Class as an SCU may choose to modify a subset of the Attributes maintained by the SCP. The Application Entity which claims conformance as an SCP to the UPS Pull SOP Class shall support attributes specified in Table CC.2.5-3

CC.2.6.2 Service Class User Behavior

The SCU shall specify in the N-SET request primitive the UID of the UPS Instance for which it wants to set Attribute Values. Since all UPSs are created as instances of the UPS Push SOP Class, the Requested SOP Class UID in the N-SET request shall be the UID of the UPS Push SOP Class. See CC.3.1 for further details.

To N-SET a UPS instance currently in the SCHEDULED state, the Transaction UID attribute shall not be present in the request. For a UPS instance in the IN PROGRESS state, the SCU shall provide the current Transaction UID (0008,1195) as an attribute.

The SCU shall be permitted to set Attribute values as specified in Table CC.2.5-3. The SCU shall specify the list of attributes for which it wants to set the Attribute Values. The SCU shall provide, with one or more N-SET request primitives, the attribute values specified in Table CC.2.5-3.

When modifying a sequence, the SCU shall include in the N-SET request all Items in the sequence, not just the Items to be modified.

N-SET requests shall be atomic (indivisible) and idempotent (repeat executions have no additional effect). Since it is possible for an N-GET to occur between two N-SET requests, any given N-SET shall leave the UPS instance in an internally consistent state (i.e. when multiple attributes need updating as a group, do this as multiple attributes in a single N-SET request, not as multiple N-SET requests)

The SCU shall not set the value of the Procedure Step State (0074,1000) attribute using N-SET. Procedure Step State is managed using N-ACTION as described in CC.2.1

The SCU shall create or set all Attributes to meet Final State requirements prior to using N-ACTION to set the value of Procedure Step State (0074,1000) to “COMPLETED” or “CANCELED”. See CC.2.5.1.1 for further details.

Once the Procedure Step State (0074,1000) has been set to “COMPLETED” or “CANCELED” the SCU shall no longer modify the UPS SOP Instance.

Note: The SCU can only set Attribute Values which have already been created with an N-CREATE request.

CC.2.6.3 Service Class Provider Behavior

The SOP Class UID of the specified UPS instance will always be the UPS Push SOP Class UID, which might not match the UPS SOP Class negotiated with the SCU. See CC.3.1 for further details.

The SCP shall support the attribute changes to the UPS instance specified by the SCU in the N-SET request primitive as specified in Table CC.2.5-3.

The SCP shall refuse N-SET requests on an IN PROGRESS UPS and not modify the UPS if the N-SET request does not include the Transaction UID (0008,1195) attribute with the same value as currently recorded in the UPS instance.

The SCP shall refuse N-SET requests on a COMPLETED or CANCELED UPS.

The SCP shall merge the Specific Character Set (0008,0005) value provided by the SCU with the existing value in the UPS instance.

The SCP shall return, via the N-SET response primitive, the N-SET Response Status Code applicable to the associated request as specified in Section CC.2.6.4.

The SCP may itself modify any Attributes of a UPS instance independently of an N-SET request, e.g., if the SCP is performing the procedure step itself, if it has been determined that the performing SCU has been disabled, or if it is necessary to correct attribute values after completion of the procedure in order to carry out reconciliation of the data. A description of the coercions the SCP may perform shall be documented in the conformance statement of the SCP.

Bi-directional Authentication of machines/users/applications is possible at association time (see PS 3.7 and PS 3.15). PS 3.7 provides a “Refused: Not Authorized” error code. There are no specific requirements to perform authorization.

CC.2.6.4 Status Codes

The status values which are specific for this DIMSE operation are defined in Table CC.2.6-1. See PS 3.7 for additional response status codes.

Table CC.2.6-1

STATUS VALUES

Status Meaning Code
Success The requested modification of the attribute values is performed 0000
Warning Requested optional Attributes are not supported. 0001
Coerced invalid values to valid values B305
Failure Refused: The UPS is not in the “IN PROGRESS” state C310
Refused: The correct Transaction UID was not provided C301
Refused: The UPS may no longer be updated C300
Specified SOP Instance UID does not exist or is not a UPS Instance managed by this SCP C307

CC.2.7 Get Unified Procedure Step Information (N-GET)

This operation allows an SCU to get information from an SCP about a specific real-world Procedure Step which is represented as a Unified Procedure Step Instance. This operation shall be invoked by the SCU through the DIMSE N-GET Service.

CC.2.7.1 Unified Procedure Step IOD Subset Specification

The Application Entity which claims conformance to the UPS Pull or UPS Watch SOP Classes as an SCU may choose to retrieve a subset of the Attribute values maintained by the SCP. The Application Entity which claims conformance as an SCP to these SOP Classes shall support the attributes specified in Table CC.2.5-3.

CC.2.7.2 Service Class User Behavior

The SCU uses the N-GET to request the SCP to provide attributes and values of a Unified Procedure Step Instance. Since all UPSs are created as instances of the UPS Push SOP Class, the Affected SOP Class UID (0000,0002) in the N-GET request shall be the UID of the UPS Push SOP Class. See CC.3.1 for further details.

The SCU shall specify in the N-GET Service Element the UID of the SOP Instance from which attributes are to be retrieved.

The SCU shall specify the list of Unified Procedure Step Attributes for which values are to be returned. The SCU shall not specify Attributes which are defined within a Sequence, but rather specify the sequence itself to be retrieved in its entirety.

The SCU shall not request the value of the Transaction UID (0008,1195) attribute.

The SCU may request Attribute Values for optional Attributes which are not maintained by the SCP. In such a case, the SCU shall function properly regardless of whether the SCP returns values for those Attributes or not. This Service Class Specification places no requirements on what the SCU shall do as a result of receiving this information.

Note: In order to accurately interpret the character set used for the Attribute Values returned, it is recommended that the Attribute Value for the Specific Character Set (0008,0005) be requested in the N-GET request primitive.

The SCU shall be permitted to request and shall be capable of receiving values for any attribute as specified in Table CC.2.5-3. Additionally, values may be requested for optional attributes.

The SCU shall be capable of receiving all requested Attribute Values provided by the SCP in response to the N-GET indication primitive.

Note: If the SCU or the user will need access to the final state attributes it is the responsibility of the SCU to Subscribe (See CC.2.2) in order to receive State Change Events and then N-GET the necessary attributes promptly upon notification of a state change to COMPLETED or CANCELED. If the SCU sets the Deletion Lock when subscribing, a COMPLETED or CANCELLED instance will continue to persist on the SCP, using resources. It is important that the SCU remove the lock (e.g. by unsubscribing) after doing the N-GET on the COMPLETED or CANCELED instance.

CC.2.7.3 Service Class Provider Behavior

The SOP Class UID of the specified UPS instance will always be the UPS Push SOP Class UID, which might not match the UPS SOP Classes negotiated with the SCU. See CC.3.1 for further details.

The SCP shall return, via the N-GET response primitive, the selected Attribute values from the indicated Unified Procedure Step Instance to the SCU.

Note: The requirement for the SCP to respond to N-GET requests for UPS Instances which have moved to the COMPLETED or CANCELED state is limited. See CC.2.1.3 Service Class Provider Behavior.

The SCP shall not return the Transaction UID (0008,1195) attribute. This is necessary to preserve this attribute’s role as an access lock.

The SCP shall return, via the N-GET response primitive, the N-GET Response Status Code applicable to the associated request. A Failure Code shall indicate that the SCP has not retrieved the SOP Instance.

Bi-directional Authentication of machines/users/applications is possible at association time (see PS 3.7 and PS 3.15). PS 3.7 provides a “Refused: Not Authorized” error code. Further requiring or documenting authentication and/or authorization features from the SCU or SCP is beyond the scope of this SOP Class.

CC.2.7.4 Status Codes

The status values which are specific for this DIMSE operation are defined in Table CC.2.7-1. See PS 3.7 for additional response status codes.

Table CC.2.7-1

STATUS VALUES

Status Meaning Code
Warning Requested optional Attributes are not supported 0001
Failure Specified SOP Instance UID does not exist or is not a UPS Instance managed by this SCP C307

CC.2.8 Search for Unified Procedure Step (C-FIND)

This operation allows an SCU to locate and get information about Unified Procedure Step instances of interest that are managed by an SCP. This operation shall be invoked by the SCU through the DIMSE C-FIND Service. The SCP processes such queries, matches UPS instances it manages against the keys present in the Identifier and returns C-FIND responses.

The SCU might be searching for UPS instance with the intention of starting work on one of them or perhaps with the intention of subscribing to monitor the progress of an instance.

CC.2.8.1 Operation

CC.2.8.1.1 E/R Model

In response to a given C-FIND request, the SCP might send several C-FIND responses, (i.e. one C-FIND response per matching worklist item). Each worklist item describes a single task and its related information.

The Unified Procedure Step Query Information Model is represented by the Entity Relationship diagram shown in Figure CC.2.8-1.

[pic]

Figure CC.2.8-1 Unified Procedure Step E-R Diagram

There is only one Information Entity in the model, which is the Unified Procedure Step. The attributes of a Unified Procedure Step can be found in Table CC.2.5-3.

CC.2.8.1.2 C-FIND Service Parameters

CC.2.8.1.2.1 SOP Class UID

The Affected SOP Class UID of the C-FIND DIMSE request shall always be the UPS SOP Class negotiated for the Presentation Context under which the service is requested. This will always be either the UPS Pull SOP Class or the UPS Watch SOP Class. See CC.3.1 for further details.

For both the UPS Pull SOP Class and the UPS Watch SOP Class, the C-FIND is performed against the Unified Procedure Step Information Model shown in CC.2.8-1.

CC.2.8.1.2.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.

CC.2.8.1.3 Identifier

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

CC.2.8.1.3.1 Request Identifier Structure

An Identifier in a C-FIND request shall contain:

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.

The Key Attributes and values allowable for the query shall be defined in the SOP Class definition corresponding to the Affected SOP Class UID for the corresponding Unified Worklist And Procedure Step Information Model.

CC.2.8.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:

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

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

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.

CC.2.8.2 Service Class User Behavior

All C-FIND SCUs shall be capable of generating query requests that meet the requirements of the “Worklist” Search Method (see CC.2.8.3.1).

Required Keys and Optional Keys, identified in Table CC.2.5-3, associated with the Query may be contained in the Identifier.

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

— The SCU shall interpret a Failure 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.

CC.2.8.3 Service Class Provider Behavior

All C-FIND SCPs shall be capable of processing queries that meet the requirements of the “Worklist” Search (see CC.2.8.3.1). This does not imply that an SCP which supports the UPS Watch SOP Class must also be an SCP of the UPS Pull SOP Class.

The SCP shall support attribute matching as described in Section C.2.2.2.

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

— 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 Identifier 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 Failure if it is unable to process the request. A Failure 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.

Bi-directional Authentication of machines/users/applications is possible at association time (see PS 3.7 and PS 3.15). PS 3.7 provides a “Refused: Not Authorized” error code. Further requiring or documenting authentication and/or authorization features from the SCU or SCP is beyond the scope of this SOP Class.

CC.2.8.3.1 Worklist Search Method

The following steps are used to generate match responses.

Table CC.2.5-3 defines the Attributes of the Unified Procedure Step Information Model, the requirements for key matching, and the requirements for return keys.

CC.2.8.4 Status Codes

Table CC.2.8-2 defines the status code values that might be returned in a C-FIND response. Fields related to status code values are defined in PS 3.7.

Table CC.2.8-2C-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)
SOP Class not Supported 0122H
Unable to process (any value C000 through CFFF as assigned by the implementation) (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).