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.

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

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.

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

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.

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.

Upon successfully changing the state of a UPS instance, the SCP shall carry out the appropriate N-EVENT-REPORT behavior as described in Section 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 PS3.7 and PS3.15). PS3.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.

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

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.

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

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 that the SCU is itself performing, the SCU shall instead use the Change UPS State action as described in Section CC.2.1.

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

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 Section CC.2.1.3, first to IN PROGRESS and then to CANCELED, ensuring that the Final State requirements, described in section 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 Section 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 PS3.7 and PS3.15). PS3.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.

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

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.

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

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.

See Section GGG.1 “Introduction” in PS3.17 Reliable Watchers and Deletion Locks for further discussion of deletion locks.

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 Section 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 that 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.

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.

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.

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.

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.

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 Section 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 PS3.7 and PS3.15). PS3.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.

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

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.

The SCU shall return, via the N-EVENT-REPORT response primitive, the N-EVENT-REPORT Response Status Code applicable to the associated request. See PS3.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.

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 Section CC.2.1.2.

An SCU that wishes to start/stop receiving N-EVENT-REPORTs about UPS instances may subscribe/unsubscribe as described in Section 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.

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 Section 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 Section 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 Section 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 Section 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 Section 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:

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.

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.

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

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.

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 that is to be created and for which Attribute Values are to be provided. See Section 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.

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 Section 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 Section 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 PS3.7 and PS3.15). PS3.7 provides a "Refused: Not Authorized" error code. There are no specific requirements to perform authorization.

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

The Application Entity that 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 that claims conformance as an SCP to the UPS Pull SOP Class shall support Attributes specified in Table CC.2.5-3

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

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 Section 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 use the Specific Character Set (0008,0005) value to appropriately modify its internal representation so that subsequent operations reflect the combination of the character sets in use by the Attributes in this N-SET and those used by Attributes that have not been modified.

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 PS3.7 and PS3.15). PS3.7 provides a "Refused: Not Authorized" error code. There are no specific requirements to perform authorization.

The status values that are specific for this DIMSE operation are defined in Table CC.2.6-1. See PS3.7 for additional response status codes.

The Application Entity that 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 that claims conformance as an SCP to these SOP Classes shall support the Attributes specified in Table CC.2.5-3.

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 Section 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 that 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 that 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.

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.

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

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 PS3.7 and PS3.15). PS3.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.

The status values that are specific for this DIMSE operation are defined in Table CC.2.7-1. See PS3.7 for additional response status codes.

All C-FIND SCUs shall be capable of generating query requests that meet the requirements of the "Worklist" Search Method (see Section 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:

All C-FIND SCPs shall be capable of processing queries that meet the requirements of the "Worklist" Search (see Section CC.2.8.3.1). This does not imply that an SCP that 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:

Bi-directional Authentication of machines/users/applications is possible at association time (see PS3.7 and PS3.15). PS3.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.

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