DICOM PS3.2 2017a - Conformance

A.4.2 AE Specifications:
Prev | A.4 Networking | Next

### A.4.2 AE Specifications:

The next section in the DICOM Conformance Statement is a set of Application Entity Specifications. There shall be one such specification for each Application Entity. Each individual AE Specification has a subsection, A.4.2.x. There are as many of these subsections as there are different AEs in the implementation. That is, if there are two distinct AEs, then there will be two subsections, A.4.2.1, and A.4.2.2.

#### A.4.2.1 "Application Entity <1>"

Every detail of this specific Application Entity shall be completely specified under this section.

AEs that utilize the DIMSE services shall have the following sections.

### Note

AEs that utilize other services are described later, and will re-use this section numbering.

##### A.4.2.1.1 SOP Classes

The specification for an Application Entity shall contain a statement of the form:

"This Application Entity provides Standard Conformance to the following SOP Class(es) :"

Table A.4.2-1. SOP Class(Es) for "Application Entity <1>"

SOP Class Name | SOP Class UID | SCU | SCP
--- | --- | --- | ---
SOP Class UID Name as specified in the registry table of DICOM Unique Identifiers (UID) in PS3.6, with phrase "and specializations" as appropriate | UID as specified in PS3.6 | Yes/No | Yes/No

### Note

Any SOP specific behavior is documented later in the conformance statement in the applicable SOP specific conformance section.

##### A.4.2.1.2 Association Policies

Each AE Specification shall contain a description of the General Association Establishment and Acceptance policies of the AE.

###### A.4.2.1.2.1 General

The DICOM standard Application context shall be specified.

Table A.4.2-2. DICOM Application Context

Application Context Name | 1.2.840.10008.3.1.1.1

###### A.4.2.1.2.2 Number of Associations.

The number of simultaneous associations, which an Application Entity may support as a SCU or SCP, shall be specified. Any rules governing simultaneity of associations shall be defined here.

### Note

For example an AE may have the capability to have up to 10 simultaneous associations, but may limit itself to have no more than 2 with any particular other AE. There may also be policies based upon combinations of simultaneous Real-World Activities.

Table A.4.2-3. Number of Associations as an Association Initiator for "Application Entity <1>"

Maximum number of simultaneous associations | x

Table A.4.2-4. Number of Associations as an Association Acceptor for "Application Entity <1>"

Maximum number of simultaneous associations | x

###### A.4.2.1.2.3 Asynchronous Nature

If the implementation supports negotiation of multiple outstanding transactions, this shall be stated here, along with the maximum number of outstanding transactions supported.

Table A.4.2-5. Asynchronous Nature as an Association Initiator for "Application Entity <1>"

Maximum number of outstanding asynchronous transactions | x

###### A.4.2.1.2.4 Implementation Identifying Information

The value supplied for Implementation Class UID shall be documented here. If a version name is supplied, this fact shall be documented here. Policies defining the values supplied for version name may be stated here.

Table A.4.2-6. DICOM Implementation Class and Version for "Application Entity <1>"

Implementation Class UID | a.b.c.xxxxxxx.yyy.zz
Implementation Version Name | XYZxyz

##### A.4.2.1.3 Association Initiation Policy

This describes the conditions under which the AE will initiate an association.

###### A.4.2.1.3.1 "Activity <1>"

###### A.4.2.1.3.1.1 Description and Sequencing of Activities

If applicable, this section shall contain a description of sequencing of the events for "Activity <1>" (substitute actual activity name), including any applicable user interactions, which this specific AE performs. A UML sequence diagram, which depicts the Application Entity and Real-World Activities as vertical bars and shows the events exchanged between them as arrows, is strongly recommended.

### Note

An example of a situation in which such a description is required is an AE, which supports both the Storage Service Class and the Modality Performed Procedure SOP Class. Some implementations might store the images before sending the final MPPS N-SET message while other implementations might send the final MPPS N-SET message before sending the images.

###### A.4.2.1.3.1.2 Proposed Presentation Contexts

Each time an association is initiated, the Association Initiator proposes a number of Presentation Contexts to be used on that association. In this subsection, the Presentation Contexts proposed by "Application Entity <1>" for "Activity <1>" shall be defined in a table with the following format:

Table A.4.2-7. Proposed Presentation Contexts for "Application Entity <1>"

Presentation Context Table
Abstract Syntax | Transfer Syntax | Role | Extended Negotiation
--- | --- | --- | ---
Name | UID | Name List | UID List
name_a | AS_UID_a | XS_Name_1, ..., XS_Name_n | XS_UID_1, _, XS_UID_n | SCP | SCU | BOTH | None |See Note <1> | See Table A.4.2-8
... | ... | ... | ... | ... | ...

### Note

<1>: <Describe the content of any extended negotiation done for the SOP Classes of this Presentation Context. One note may serve multiple Presentation Contexts, as a single Abstract Syntax often corresponds to a single SOP class, which may appear in different Presentation Contexts.>

In Table A.4.2-7, the following meanings are assigned to the fields:

- <name_a> This is the name of the Abstract Syntax to be used with this Presentation Context.

- <AS_UID_a> This is the UID of the Abstract Syntax to be used for this Presentation Context.

- <XS_Name_n> This is the name of a Transfer Syntax that may be used for this Presentation Context.

- <XS_UID_n> The UID of the corresponding Transfer Syntax.

If the AE through this Real World Activity might propose any of the SOP Classes of a particular Service Class (e.g., the Storage Service Class), the Abstract Syntax Name and UID shall be those of the Service Class. This section shall describe the conditions under which a SOP Class of that Service Class will be proposed in a Presentation Context.

### Note

For instance, an AE may receive instances of a non-preconfigured SOP Class through support of SOP Class Common Extended Negotiation. These instances may be limited to specializations of a particular SOP Class, or they may be any SOP Class within the Service Class, and any such limits should be described.

This section shall describe the conditions under which the AE may change the SOP Class UID of SOP Instances sent, due to fall-back mechanisms.

### Note

For instance, if the SCP does not accept the proposed Abstract Syntax (SOP Class) for which there is a Related General SOP Class that was accepted, the AE may modify SOP Instances of the refused SOP Class to use the Related General SOP Class for transmission.

In the event that the Abstract Syntax of the Presentation Context represents a Meta-SOP Class (that is, it includes many SOP Classes) and extended negotiation is supported for some of these SOP Classes, the following table is required to define this extended negotiation. This table is referenced in Table A.4.2-7:

Table A.4.2-8. Extended Negotiation as a SCU

SOP Class Name | SOP Class UID | Extended Negotiation
--- | --- | ---
Name_i | SOP_UID_I | None | See Note <1>
... | ... | ...

### Note

<1>: <Describe the content of any extended negotiation done for this SOP Class. One note may serve multiple Presentation Contexts, as a SOP class that may appear in different Presentation Contexts and/or Meta SOP Classes>

The implementation of the initiator shall document which Transfer Syntax will be chosen in case multiple Transfer Syntaxes are accepted during the Association Acceptance.

###### A.4.2.1.3.1.3 SOP Specific Conformance for SOP Class(Es)

This section includes the SOP specific behavior, i.e., error codes, error and exception handling, time-outs, etc. The information shall be as described in the SOP specific Conformance Statement section of PS3.4 (or relevant private SOP definition). It shall include the content of any extended negotiation. Keys shall be specified including how they are used (Matching, return keys, interactive query, whether they are displayed to the user, universal and/or list matching, etc.).

In particular, the behavior associated with the exchange of images available to the AE only in a lossy compressed form shall be documented. For example, if a lossy compressed transfer syntax is not negotiated, will the AE decompress the image data and send it using one of the negotiated transfer syntaxes.

All details regarding the specific conformance, including response behavior to all status codes, both from an application level and communication errors shall be provided in the form of a table as follows:

Table A.4.2-9. DICOM Command Response Status Handling Behavior

Service Status | Further Meaning | Error Code | Behavior
--- | --- | --- | ---
e.g., Success | e.g., Matching is complete | e.g., 0000 | e.g., The SCP has successfully returned all matching information.
Warning |  |  |
Error |  |  |
….. |  |  |

The behavior of the AE during communication failure is summarized in a table as follows:

Table A.4.2-10. DICOM Command Communication Failure Behavior

Exception | Behavior
--- | ---
e.g., Timeout | e.g., The Association is aborted using A-ABORT and command marked as failed. The reason is logged and reported to the user.
e.g., Association aborted | e.g., The command is marked as failed. The reason is logged and reported to the user.

##### A.4.2.1.4 Association Acceptance Policy

Each AE Specification shall contain a description of the Association Acceptance policies of the AE. This describes the conditions under which the AE will accept an association.

###### A.4.2.1.4.1 "Activity <2>"

###### A.4.2.1.4.1.1 Description and Sequencing of Activities

###### A.4.2.1.4.1.2 Accepted Presentation Contexts

Table A.4.2-11. Acceptable Presentation Contexts For"Application Entity <1>" and "Activity <2>"

Presentation Context Table
Abstract Syntax | Transfer Syntax | Role | Extended Negotiation
--- | --- | --- | ---
Name | UID | Name | UID
name_a | AS_UID_a | XS_Name_a | XS_UID_a | SCP | SCU | Both | None |See Note <1>| See Table A.4.2-12
... | ... | ... | ... | ... | ...

### Note

<1>: <Describe the content of any extended negotiation done for the SOP Classes of this Presentation Context. In particular, acceptance of specialized SOP Classes of the Abstract Syntax specified in this Presentation Context shall be noted. One note may serve multiple Presentation Contexts, as a single Abstract Syntax often corresponds to a single SOP class, which may appear in different Presentation Contexts>

In Table A.4.2-11, the following meanings are assigned to the fields:

<name_a> This is the name of the Abstract Syntax to be used with this Presentation Context.

<AS_UID_a> This is the UID of the Abstract Syntax to be used for this Presentation Context.

<XS_Name_a> This is the name of a Transfer Syntax that may be used for this Presentation Context.

<XS_UID_a> The UID of the corresponding transfer syntax.

If the AE through this Real World Activity supports all SOP Classes of a particular Service Class (e.g., the Storage Service Class) through SOP Class Common Extended Negotiation, the Abstract Syntax Name and UID shall be those of the Service Class, and this shall be noted under Extended Negotiation.

In the event that the Abstract Syntax of the Presentation Context represents a Meta-SOP Class (that is, it includes many SOP Classes) and extended negotiation is supported for some of these SOP Classes, the following table is required to define this extended negotiation. This table is referenced in Table A.4.2-11

Table A.4.2-12. Extended Negotiation as a SCP

SOP Class name | SOP Class UID | Extended Negotiation
--- | --- | ---
Name_i | SOP_UID_I | None | See Note <1>
... | ... | ...

### Note

<1>: <Describe the content of any extended negotiation done for this SOP Class. One note may serve multiple Presentation Contexts, as a SOP class, which may appear in different Presentation Contexts, and/or Meta SOP Classes>

Any rules that govern the acceptance of presentation contexts for this AE shall be stated here as well. This includes rules for which combinations of Abstract/Transfer Syntaxes are acceptable, and rules for prioritization of presentation contexts. Rules that govern selection of transfer syntax within a presentation context shall be stated here.

###### A.4.2.1.4.1.3 SOP Specific Conformance for SOP Class(Es)

This section includes the SOP specific behavior, i.e., error codes, error and exception handling, time-outs, etc. The information shall be as described in the SOP specific Conformance Statement section of PS3.4 (or relevant private SOP definition).

The behavior of an Application Entity shall be summarized as shown in Table 4.2-13. Standard as well as the manufacturer specific status codes and their corresponding behavior shall be specified.

Table 4.2-13. Storage C-STORE Response Status

Service Status | Further Meaning | Error Code | Reason
--- | --- | --- | ---
Success | Success | 0000 | Explain
Refused | Out of Resources | A700-A7FF | Explain
Error | Data Set does not match SOP Class | A900-A9FF | Explain
Error | Specify | Specify | Explain
Warning | Specify | Specify | Explain

Prev | Up | Next
A.4 Networking | Home | A.4.2.2 "Application Entity <1>"

DICOM PS3.2 2017a - Conformance