PS-2020a / part04

DD.3.2.4 N-DELETE​

The N-DELETE is used to delete an instance of the applicable Machine Verification SOP Class.​

DD.3.2.4.1 Attributes​

There are no specific Attributes.​

DD.3.2.4.2 Status​

There are no specific status codes. See PS3.7 for response status codes.​

DD.3.2.4.3 Behavior​

The SCU uses the N-DELETE to request the SCP to delete an applicable Machine Verification SOP Instance. The SCU shall specify​ in the N-DELETE request primitive the SOP Instance UID of the applicable Machine Verification instance.​

The SCP shall delete the specified SOP Instance, such that subsequent operations of the same SOP Instance will fail.​

The SCP shall return the status code of the requested SOP Instance deletion. The meanings of success, warning, and failure status​ classes are defined in Annex C “Status Type Encoding (Normative)” in PS3.7.​

If an N-DELETE is not issued, the SOP Class instance may be deleted on the SCP by a manual or automatic operation. This behavior​ is beyond the scope of the Standard.​

DD.3.2.5 N-EVENT-REPORT​

The N-EVENT-REPORT is used by the MPV to notify the TDS of the status of the verification task (successful or otherwise), or to​ notify the TDS that a verification is pending (in progress). The encoding of Notification Event Information is defined in PS3.7.​

DD.3.2.5.1 Attributes​

The arguments of the N-EVENT-REPORT are defined as shown in Table DD.3.2.5-1.​

Table DD.3.2.5-1. Notification Event Information​

DD.3.2.5.2 Status​

There are no specific status codes. See PS3.7 for response status codes.​

DD.3.2.5.3 Behavior​

The SCP uses the N-EVENT-REPORT to inform the SCU of the verification status. See Section BBB.3 “Use Cases” in PS3.17.​

If the Event Type ID = 1 then the verification is still in progress, and the SCU must wait until another event is received. See Sec-​ tion BBB.3.2.2 “Transactions and Message Flow” in PS3.17.​

If the Event Type ID = 2 then the verification process has been completed. The SCU may use the returned value of the Treatment​ Verification Status (3008,002C) to determine whether or not the beam is ready to be delivered, or if a machine adjustment or override​ needs to be made. See Section BBB.3.2.2 “Transactions and Message Flow” in PS3.17.​

- Standard -​

- Standard -​

EE Display System Management Service​

Class (Normative)​

EE.1 Scope​

The Display System Service Class allows service users retrieve parameters related to the Display Subsystem(s).​

Figure EE.1-1. Display System Management Data Flow​

EE.2 Display System SOP Class​

EE.2.1 IOD Description​

The Display System IOD is an abstraction of the soft-copy display system and is the basic Information Entity to monitor the status of​ a Display System. The Display System SOP Instance is created by the SCP during start-up of the Display System and has a well-​ known SOP Instance UID.​

EE.2.2 DIMSE Service Group​

The DIMSE Service shown in Table EE.2.2-1 is applicable to the Display System IOD under the Display System SOP Class.​

Table EE.2.2-1. DIMSE Service Group Applicable to Display System​

This section describes the behavior of the DIMSE services that are specific for this IOD. The general behavior of the DIMSE services​ is specified in PS3.7.​

EE.2.2.1 N-GET​

N-GET is used to retrieve information from an instance of the Display System SOP Class.​

EE.2.2.1.1 Attributes​

EE.2.2.1.1.1 Display Subsystem Macros​

To reduce the size and complexity of EE.2.2.1-2, a macro notation is used.​

- Standard -​

Page 414​ DICOM PS3.4 2020a - Service Class Specifications​

Table EE.2.2.1-1. Table Result Context Macro​

- Standard -​

- Standard -​

- Standard -​

- Standard -​

(Required if Reflected Ambient Light​ (2010,0160) is present.)​

EE.2.2.1.2 SCU Behavior​

The SCU uses the N-GET to request the SCP to provide the contents of a Display System SOP Instance. The SCU shall specify in​ the N-GET request primitive the UID of the SOP Instance from which attributes are to be returned.​

The SCU shall specify the list of Display System 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 returned in its entirety.​

The SCU shall specify in the N-GET request primitive the well-known UID of the SOP Instance.​

EE.2.2.1.3 SCP Behavior​

The SCP shall return the values for the specified Attributes of the Display System SOP Instance.​

The SCP shall return the status code for the requested SOP Instance retrieval. The meaning of success, warning, and failure status​ codes are defined in PS3.7.​

EE.2.3 SOP Class Definitions and UIDs​

The SOP Class UID of the Display System SOP Class shall have the value of "1.2.840.10008.5.1.1.40".​

EE.2.4 Reserved Identifications​

The well-known UID of the Display System SOP Instance shall have the value of "1.2.840.10008.5.1.1.40.1".​

EE.3 Conformance​

EE.3.1 Conformance Statement​

The implementation conformance statement of this SOP Class shall follow PS3.2.​

The SCU Conformance Statement shall specify the following items:​

•​Maximum number of associations to be supported at the same time​

•​List of SOP Classes supported​

•​For each of the supported SOP Classes:​

•​List of supported SOP Class attributes and DICOM Message Service Elements​

•​For each supported attribute (mandatory and optional), a valid value range​

The SCP Conformance Statement shall specify the following items:​

•​Maximum number of associations to be supported at the same time​

•​List of SOP Classes supported​

•​For each of the supported SOP Classes:​

•​List of supported SOP Class attributes and DICOM Message Service Elements​

•​For each supported attribute (mandatory and optional)​

- Standard -​

•​Valid value range​

•​Default value if no value is supplied by the SCU​

•​Status code (Failure or Warning) if the SCU supplies a value that is out of range​ •​For each supported DIMSE service​

•​SCP behavior for all specific status codes​

- Standard -​

- Standard -​