Материал: part07

The DICOM Application Entity uses the services provided by the DICOM Message Service Element. The DICOM Message Service​ Element specifies two sets of services.​

•​DIMSE-CsupportsoperationsassociatedwithcompositeSOPClassesandprovideseffectivecompatibilitywiththepreviousversions​ of the DICOM Standard.​

•​DIMSE-NsupportsoperationsassociatedwithnormalizedSOPClassesandprovidesanextendedsetofobject-orientedoperations​ and notifications. It is based on the OSI System Management Model and more specifically on the OSI Common Management In-​ formation Services (CMIS) Service definition.​

DICOM Application Entity

DICOM

PART 7

DICOM Message Service Element

(DIMSE)

(DIMSE-C and DIMSE-N Operations and Notifications)

DICOM

PART 8 & 9 Upper Layer Association

Services *

Upper Layer Presentation Data Service

(see figure 6.1-1)

* This figure expands upon figure 6.1-1 by showing that the Association Services specified in Part 8 are formally part of the Application Entity.

Figure 6.2-1. DICOM Application Layer Structure​

The DIMSE-C and DIMSE-N services are supported by a single DIMSE protocol that uses the DICOM-specific Message formatting​ and encoding.​

6.3 DICOM Message Structure and Command Set​

Information is communicated across the DICOM network interface in a DICOM Message. A Message is composed of a Command​ Set followed by a conditional Data Set (see PS3.5 for the definition of a Data Set). The Command Set is used to indicate the opera-​ tions/notifications to be performed on or with the Data Set.​

A Command Set is constructed of Command Elements. Command Elements contain the encoded values for each individual field of​ the Command Set per the semantics specified in the DIMSE protocol (see Section 9.2 and Section 10.2). Each Command Element​ is composed of an explicit Tag, a Value Length, and a Value Field.​

The overall structure of a DICOM Message is shown in Figure 6.3-1.​

- Standard -​

Command Element

Figure 6.3-1. DICOM Message Structure​

6.3.1 Command Set Structure​

The Command Elements in a Command Set shall be ordered by increasing Command Element Tag number. A Command Element​ Tag uniquely identifies a Command Element and shall occur at most once in a Command Set. The encoding of the Command Set​ shall be Little Endian Byte Ordering as defined in PS3.5. The requirements for the existence of a Command Element in a Command​ Set are defined in the DIMSE protocol.​

Note​

1.​The use of Private Command Elements has been retired in this version of the DICOM Standard.​

2.​The encoding corresponds to the Implicit VR Data Element encoding defined in PS3.5.​

A Command Element is composed of three fields; a Command Element Tag, a Value Length, and a Value Field.​

Command Element Tag: An ordered pair of 16-bit unsigned integers representing the Group Number followed by Element Number.​

Value Length: A 32-bit unsigned integer representing the explicit Length as the number of bytes (even) that make up the Value. It​ does not include the length of the Command Element Tag or Value Length fields.​

Value Field: An even number of bytes containing the Value(s) of the Command Element.​

The command type of Value(s) stored in this field is specified by the Command Element's Value Representation (VR). The VR for a​ given Command Element can be determined using the Command Dictionary in Annex E. The VR of Command Elements shall agree​ with those specified in the Command Dictionary. The VR definitions are defined in PS3.5​

The Value Multiplicity (VM) specifies how many Values with the VR can be placed in the Value Field. If the VM is greater than one,​ multipleValuesshallbedelimitedwithintheValueFieldasdefinedinPS3.5.TheVMforagivenCommandElementcanbedetermined​ using the Command Dictionary in Annex E.​

Note​

1.​The Message Length-to-End (0000,0001) Command Element is retired. Implementations may choose to send it for​ backward compatibility reasons. DICOM V3.0 conformant implementations must not rely on its presence for their oper-​ ation.​

2.​The delimitation of the Message length is actually achieved by relying on the fact that the Presentation Data Value​ (conveyingeachMessagefragment)isdelimitedasdefinedbytheOSIUpperLayerServiceandtheassociatedMessage​ ControlHeader(seePS3.8).ThisresultsfromthefactthattheDICOMV3.0ULprotocolortheOSIPresentationprotocol​ explicitly conveys the length of a PDV.​

- Standard -​

7 Service Overview​

The DICOM Message Service Element supports communication between peer DIMSE Service Users. A DIMSE Service User acts​ in one of two roles:​

a.​invoking DIMSE Service User​

b.​performing DIMSE Service User​

DIMSE Service Users make use of service primitives that are provided by the DIMSE Service Provider. The DIMSE Service Provider​ is an abstraction of the totality of those entities that provide DIMSE services to peer DIMSE Service Users. A service primitive shall​ be one of the following types:​

a.​request primitive​

b.​indication primitive​

c.​response primitive​

d.​confirmation primitive​

These primitives (which are shown in Figure 7-1) are used as follows to successfully complete a DIMSE service:​

•​The invoking DIMSE Service User issues a request primitive to the DIMSE Service Provider.​

•​TheDIMSEServiceProviderreceivestherequestprimitivefromtheinvokingDIMSEServiceUserandissuesanindicationprimitive​ to the performing DIMSE Service User.​

•​The performing DIMSE Service User receives the indication primitive from the DIMSE Service Provider and performs the requested​ service.​

•​The performing DIMSE Service User issues a response primitive to the DIMSE Service Provider.​

•​The DIMSE Service Provider receives the response primitive from the performing DIMSE Service User and issues a confirmation​ primitive to the invoking DIMSE Service User.​

•​The invoking DIMSE Service User receives the confirmation primitive from the DIMSE Service Provider completing the DIMSE​ service.​

7.1 Service Types​

DIMSE provides two types of information transfer services that are used by DICOM Application Entities:​

a.​a notification service​

b.​an operation service​

- Standard -​

Figure 7-1. DIMSE Service Primitives​

Notification services enable one DICOM Application Entity to notify another about the occurrence of an event or change of state. The​ definition of the notification and the consequent behavior of the Application Entities is dependent upon the Service Class and Inform-​ ation Object Definitions. See PS3.3 and PS3.4.​

Operation services enable one DICOM Application Entity to explicitly request an operation to be performed upon a SOP Instance​ managed by another DICOM Application Entity.​

7.2 DIMSE Service User Interaction​

The DICOM Message Service Element receives notification and operation requests and their related information from the DIMSE​ Service User. Two DICOM Application Entities take the roles as peer DIMSE Service Users in order to exchange notifications and​ operations.​

Anotificationoroperationisimplementedasarequest/responseinteractioncarriedoutwithinthecontextofanestablishedapplication​ Association. Typically, one DIMSE Service User requests that a particular operation be performed (or notification be processed) and​ theotherDIMSEServiceUserattemptstoperformtheoperation(orprocessthenotification)andthenreportstheoutcomeoftheattempt.​

When engaging in the operations or notifications, the DIMSE Service User takes on one of two roles:​

a.​it performs operations (on SOP Instances for which it has responsibility) that were invoked by a peer DIMSE Service User. It may​ also emit change-of-state notifications for SOP Instances to one or more peer DIMSE Service Users. These notifications may​ be invoked as a result of operations initiated by other DIMSE Service Users.​

b.​it invokes the performance of an operation on a peer DIMSE Service User. It may also receive notifications from a peer DIMSE​ Service User.​

These roles are depicted in Figure 7.2-1.​

Note​

1.​Role a) (called the Agent role in ISO terminology) is used by an implementation that conforms to a DICOM Service​ Class as an SCP.​

2.​Role b) (called the Manager role in ISO terminology) is used by an implementation that conforms to a DICOM Service​ Class as an SCU.​

- Standard -​

Figure 7.2-1. Operation and Notification Flow​

7.3 Service Modes​

Operations and notifications, on an Association, are used in one of the following two modes:​

a.​synchronous​

b.​asynchronous​

In the synchronous mode, the invoking DIMSE Service User, on an established Association, requires a response from the performing​ DIMSE Service User before invoking another operation or notification.​

Intheasynchronousmode,theinvokingDIMSEServiceUser,onanestablishedAssociation,maycontinuetoinvokefurtheroperations​ ornotificationstotheperformingDIMSEServiceUserwithoutawaitingaresponse.Intheasynchronousmode,theperformingDIMSE​ Service User may respond to the operations or notifications in a different order than they were received.​

The mode selection (synchronous or asynchronous) is determined at Association establishment time. The synchronous mode serves​ as the default mode and shall be supported by all DIMSE Service Users. The asynchronous mode is optional and the maximum​ number of outstanding operations/notifications is negotiated during Association establishment. This negotiation is accomplished by​ Application Association Information as defined in Annex D.​

7.4 Association Services​

The DICOM Message Service Element does not provide separate services for the establishment and termination of application Asso-​ ciations. This section provides an overview of how an Application Entity using the DIMSE service uses the Association Services​ defined in PS3.8.​

During the Association establishment phase, a DIMSE Service User shall exchange initialization information using parameters of the​ A-ASSOCIATE Upper Layer Service (see Figure 7.4-1) that include:​

•​Application context​

•​Presentation and session requirements​

•​DIMSE-specific user information​

•​Application Association Information​

The A-RELEASE and A-ABORT Services defined in PS3.8 shall be used for the termination of an Association.​

Note​

The rules defining how the Association Services are used by a DIMSE Service User are defined in Annex D.​

- Standard -​