Материал: part02

DICOM PS3.2 2020a - Conformance​ Page 71​

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>"​

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>"​

ThevaluesuppliedforImplementationClassUIDshallbedocumentedhere.Ifaversionnameissupplied,thisfactshallbedocumented​ 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>"​

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​ EntityandReal-WorldActivitiesasverticalbarsandshowstheeventsexchangedbetweenthemasarrows,isstronglyrecommended.​

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​ MPPSN-SETmessagewhileotherimplementationsmightsendthefinalMPPSN-SETmessagebeforesendingtheimages.​

A.4.2.1.3.1.2 Proposed Presentation Contexts​

Eachtimeanassociationisinitiated,theAssociationInitiatorproposesanumberofPresentationContextstobeusedonthatassociation.​ 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>"​

- Standard -​

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 Ex-​ tended 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.​

IntheeventthattheAbstractSyntaxofthePresentationContextrepresentsaMeta-SOPClass(thatis,itincludesmanySOPClasses)​ andextendednegotiationissupportedforsomeoftheseSOPClasses,thefollowingtableisrequiredtodefinethisextendednegotiation.​ This table is referenced in Table A.4.2-7:​

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

<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 ac-​ cepted during the Association Acceptance.​

- Standard -​

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​

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​

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>"​

Note​

<1>: <Describe the contentof anyextended negotiationdone for the SOPClasses of this Presentation Context.In particular,​ acceptance of specialized SOP Classes of the Abstract Syntax specified in this Presentation Context shall be noted. One​

- Standard -​

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.​

IntheeventthattheAbstractSyntaxofthePresentationContextrepresentsaMeta-SOPClass(thatis,itincludesmanySOPClasses)​ andextendednegotiationissupportedforsomeoftheseSOPClasses,thefollowingtableisrequiredtodefinethisextendednegotiation.​ This table is referenced in Table A.4.2-11​

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

<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​

A.4.2.2 "Application Entity <1>"​

An Application Entity that supports Web services shall have the following sections:​

Details of this specific Application Entity shall be specified under this section.​

- Standard -​

A.4.2.2.1 Retired​

See PS3.2-2017b.​

A.4.2.2.2 WADO-URI Specifications​

All WADO-URI services that are supported shall be listed. Other WADO-URI services that are not supported may be indicated.​

For each supported service, the parameters and restrictions on those parameters shall be described.​

Any connection policies such as restrictions on the number of connections, support for pipeline requests, etc. shall be described.​

A.4.2.2.3 Restful Services Specifications​

All RESTful services that are supported shall be listed. Other RESTful services that are not supported may be indicated.​

For each supported service, the parameters and restrictions on those parameters shall be described.​

Any connection policies such as restrictions on the number of connections, support for pipeline requests, etc. shall be described.​

A.4.2.3 "Application Entity <2>"​

The same info shall be repeated for each additional AE.​

A.4.3 Network Interfaces​

A.4.3.1 Physical Network Interface​

If applicable, specifies what physical network interface(s) are supported.​

A.4.3.2 Additional Protocols​

Additional protocols such as used for configuration management are listed here. Any conformance to specific System Management​ Profiles defined in PS3.15 shall be listed per the following table.​

Table A.4.3-1. System Management Profiles Table​

If the implementation conforms to the Basic Network Address Management Profile as a DHCP Client actor (see PS3.15), the use of​ DHCP to configure the local IP address and hostname shall be described.​

Note​

The hostname is an alias for the IP address, and has no semantic relationship to AE titles. It is solely a convenience for​ configuration description.​

If the implementation conforms to the Basic Network Address Management Profile as a DNS Client actor (see PS3.15), the use of​ DNS to obtain IP addresses from hostname information shall be described.​

If the implementation conforms to the Basic Time Synchronization profile as an NTP Client or SNTP Client, the available NTP config-​ uration alternatives shall be described. If the implementation conforms to the Basic Time Synchronization Profile as an NTP Server,​ theavailableserverconfigurationalternativesshallbedescribed.Anydevicespecificrequirementsforaccuracyormaximumallowable​ synchronization error shall be described.​

If there is support for WADO (see PS3.18) the options supported and any restrictions shall be described.​

- Standard -​