Материал: part07

7.4.1 Association Establishment​

The A-ASSOCIATE Service is invoked by a DIMSE Service User to establish an Association with a peer DIMSE Service User. Asso-​ ciation establishment is always the first phase of DICOM Message Exchange.​

The initiating DIMSE Service User and the responding DIMSE Service User shall include Application Association Information on the​ request and response primitive respectively. The meaning of this parameter is Application Context specific. For more information on​ the use of the Application Association Information, see Annex D.​

7.4.2 Association Release​

The A-RELEASE Service is invoked by a DIMSE Service User to request the orderly termination of an Association between peer​ DIMSE Service Users. This Part of the Standard does not specify any use of the parameters of the A-RELEASE service.​

DICOM Application Entity

Figure 7.4-1. DICOM Application Entity and Association​

The A-ABORT Service is invoked by a DIMSE Service User to request the abrupt termination of the Association between peer DIMSE​ Service Users. The A-ABORT invoking DIMSE Service User shall include (within the A-ABORT user information field) the Abort​ Source parameter. The Abort Source parameter indicates the initiating source of the abort. It takes one of the following symbolic​ values:​

•​DIMSE Service Provider​

•​DIMSE Service User​

Reference PS3.8 for more information on the A-RELEASE and A-ABORT services.​

7.5 DIMSE Services​

Because the manner in which operations applied to Composite SOP Instances differ from operations and notifications applied to​ Normalized SOP Instances, two groups of DIMSE services are defined:​

•​DIMSE-N: those services applicable to Normalized SOP Instances​

- Standard -​

Note​

Use of the Dialog command, supported in previous versions of this Standard, has been retired.​

7.5.1 DIMSE-C Services​

The DIMSE-C services allow a DICOM Application Entity to explicitly request an operation by another DICOM Application Entity on​ CompositeSOPInstances.Theoperationsallowedareintendedtobeeffectivelycompatiblewiththoseprovidedbypreviousversions​ of this Standard. DIMSE-C provides only operation services.​

7.5.1.1 Operation Services​

DIMSE-C provides the following operation services that are all confirmed services and as such a response is expected:​

a.​The C-STORE service is invoked by a DIMSE Service User to request the storage of Composite SOP Instance information by a​ peer DIMSE Service User.​

b.​The C-FIND service is invoked by a DIMSE Service User to match a series of Attribute strings against the Attributes of the set​ ofSOPInstancesmanagedbyapeerDIMSEServiceUser.TheC-FINDservicereturnsforeachmatchalistofrequestedAttributes​ and their values.​

c.​The C-GET service is invoked by a DIMSE Service User to fetch the information for one or more Composite SOP Instances from​ a peer DIMSE Service User, based upon the Attributes supplied by the invoking DIMSE Service User.​

d.​The C-MOVE service is invoked by a DIMSE Service User to move the information for one or more Composite SOP Instances​ fromapeerDIMSEServiceUser,toathirdpartyDIMSEServiceUser,basedupontheAttributessuppliedbytheinvokingDIMSE​ Service User​

e.​The C-ECHO service is invoked by a DIMSE Service User to verify end-to-end communications with a peer DIMSE Service User.​

Note​

1.​The major differences between a C-GET and a C-MOVE operation are that the:​

a.​C-STORE sub-operations resulting from a C-GET are performed on the same Association as the C-GET. With a​ C-MOVE, the resulting C-STORE sub-operations are performed on a separate Association.​

b.​C-MOVE operation supports C-STORE sub-operations being performed with an Application Entity that is not the​ one that initiated the C-MOVE (third party move).​

- Standard -​

2.​In the case where an Application Entity wishes to request that it receives one or more images for storage, it may use​ either a C-GET operation or a C-MOVE to itself. It is expected that in most environments the C-MOVE is a simpler​ solutiondespitethefactthattwoAssociationsarerequired.TheuseoftheC-GETservicemaynotbewidelyimplemented.​ ItmaybeimplementedinspecialcaseswhereasystemdoesnotsupportmultipleAssociations.Itwasleftinthisversion​ of the Standard for backward compatibility with previous versions of the Standard.​

7.5.2 DIMSE-N Services​

The DIMSE-N services provide both notification and operation services applicable to Normalized SOP Instances.​

7.5.2.1 Notification Service​

DIMSE-N provides a single Notification Service, the N-EVENT-REPORT. The N-EVENT-REPORT service is invoked by a DIMSE​ ServiceUsertoreportaneventaboutaSOPInstancetoapeerDIMSEServiceUser.Thisserviceisaconfirmedserviceandaresponse​ is expected.​

7.5.2.2 Operation Services​

DIMSE-N provides the following operation services that are all confirmed services and as such a response is expected:​

a.​The N-GET service is invoked by a DIMSE Service User to request the retrieval of information from a peer DIMSE Service User.​

b.​The N-SET service is invoked by a DIMSE Service User to request the modification of information by a peer DIMSE Service​ User.​

c.​The N-ACTION service is invoked by a DIMSE Service User to request a peer DIMSE Service User to perform an action.​

d.​The N-CREATE service is invoked by a DIMSE Service User to request a peer DIMSE Service User to create an instance of a​ SOP Class.​

e.​The N-DELETE service is invoked by a DIMSE Service User to request a peer DIMSE Service User to delete an instance of a​ SOP Class.​

7.5.3 DIMSE Procedures​

All DIMSE operations and notifications are confirmed services. The performing DIMSE Service User shall report the response of each​ operation or notification over the same Association on which the operation or notification was invoked.​

Each DIMSE service is accomplished through the use of one or more service primitives. How the peer DIMSE Service Users utilize​ and react to the service primitives are defined by the service procedures.​

7.5.3.1 Sub-Operations​

Some DIMSE services are atomic in that the service is performed by one operation or notification. In such a case the DIMSE service​ primitives are used by peer DIMSE Service Users to invoke and perform the operation or notification.​

Other DIMSE services require the use of one or more sub-operations to perform the service. In such cases DIMSE service primitives​ areusedbypeerDIMSEServiceUserstoinvokeandperformeachsub-operation.Howandwhenthesub-operationserviceprimitives​ are used is defined by the procedures for the DIMSE service.​

7.5.3.2 Multiple Responses​

Each DIMSE service requires one or more response primitives as a result of the invocation of the service. How and when the multiple​ response primitives are used is defined by the procedures for the DIMSE service. Whether multiple responses are returned is condi-​ tional upon the information included in the request primitive by the DIMSE Service User.​

- Standard -​

7.5.3.3 Cancellation​

Certain DIMSE services permit the cancellation of the service through the use of service primitives. This allows an invoking DIMSE​ Service User to request termination of a DIMSE service after completion of the request service primitive but prior to completion of the​ confirm service primitive.​

Table 7.5-2 lists each DIMSE service and its related procedure information. The complete specifications for the service procedures​ are defined in Sections 9 and 10 for DIMSE-C and DIMSE-N respectively.​

Table 7.5-2. DIMSE Services and Procedures​

- Standard -​

- Standard -​