| DICOM PS3.2 2019d - Conformance |
|---|
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.
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.
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) :"
Each AE Specification shall contain a description of the General Association Establishment and Acceptance policies of the AE.
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.
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.
If the implementation supports negotiation of multiple outstanding transactions, this shall be stated here, along with the maximum number of outstanding transactions supported.
This describes the conditions under which the AE will initiate an association.
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.
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.
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>"
|
None |See Note <1> | See Table A.4.2-8 |
|||||
<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:
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.
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.
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:
<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.
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:
The behavior of the AE during communication failure is summarized in a table as follows:
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.
Table A.4.2-11. Acceptable Presentation Contexts For"Application Entity <1>" and "Activity <2>"
|
None |See Note <1>| See Table A.4.2-12 |
|||||
<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
<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.
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.
| DICOM PS3.2 2019d - Conformance |
|---|