This section contains the networking related services (vs. the media related ones).
The Implementation model consists of three sections: the Application Data Flow Diagram, specifying the relationship between the Application Entities and the "external world" or Real-World activities, a functional description of each Application Entity, and the sequencing constraints among them.
As part of the Implementation model, an Application Data Flow Diagram shall be included. This diagram represents all of the Application Entities present in an implementation, and graphically depicts the relationship of the AEs use of DICOM to Real-World Activities as well as any applicable User interaction. Figure A.4.1-1 is a template for such a Data Flow Diagram.
In this illustration, according to figure A.4.1-1, an occurrence of local Real-World Activity A will cause local Application Entity <1> to initiate an association for the purpose of causing Real-World Activity X to occur remotely. It also shows that Real-World Activities B and Y are interactively related via Application Entity <2>, with B being local and Y Remote, and that local Application Entity 3 expects to receive an association request when remote Real-World Activity Z occurs so that it can perform Real-World Activity C and/or D. When the performance of Real-World activities relies on interactions within the implementation, one may depict the circles as overlapping as shown in Figure A.4.1-1. Any such overlap shall be discussed in this section of a Conformance Statement.
Typically, there is a one to one relationship between an AE and an AE Title. Devices may be capable of configuring the relationship between AE and AE Title (e.g., by merging Application Entities to use a single AE Title). This is specified in the configuration section.
The Application Data Flow Diagram shall contain overview text with one bullet per AE. Each bullet should provide an overview of each one of the AEs, in relationship to their real-world activities, AE network exchanges and external real-world activities.
Note
There is no standard definition or guidelines on the number of AEs within a product and what an AE should encompass. Its functionality and scope is purely to the discretion of the vendor and typically depending on the system architecture.
This part shall contain a functional definition for each individual local Application Entity. This shall describe in general terms the functions to be performed by the AE, and the DICOM services used to accomplish these functions. In this sense, "DICOM services" refers not only to DICOM Service Classes, but also to lower level DICOM services, such as Association Services.
Functional description of "Application Entity <1>" (substitute actual AE name), i.e., what is it that the AE performs.
If applicable, this section shall contain a description of sequencing as well as potential constraints, of Real-World Activities, including any applicable user interactions, as performed by all the Application Entities. A UML sequence diagram, which depicts the Real-World Activities as vertical bars and shows the events exchanged between them as arrows, is strongly recommended.
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.
Note
AEs that utilize other services are described later, and will re-use this section numbering.
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) :"
Note
Any SOP specific behavior is documented later in the conformance statement in the applicable SOP specific conformance section.
Each AE Specification shall contain a description of the General Association Establishment and Acceptance policies of the AE.
The DICOM standard Application context shall be specified.
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 |
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 |
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 |
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.
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.
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.
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. |
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>"
|
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.
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 |
An Application Entity that supports the WADO transport services shall have the following sections:
Details of this specific Application Entity shall be specified under this section.
All WADO WS services that are supported shall be listed. Other WADO WS 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 asynchronous WS requests, etc. shall be described.
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.
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.
If applicable, specifies what physical network interface(s) are supported.
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
|
Profile Name |
Actor |
Protocols Used |
Optional Transactions |
Security Support |
|---|---|---|---|---|
|
Profile (1) |
P Client |
Protocol_1, Protocol_2 |
N/A |
|
|
Profile (x) |
X Client |
Protocol_2, Protocol_3 |
Protocol_3 Option_A supported |
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 configuration alternatives shall be described. If the implementation conforms to the Basic Time Synchronization Profile as an NTP Server, the available server configuration alternatives shall be described. Any device specific requirements for accuracy or maximum allowable synchronization error shall be described.
If there is support for WADO (see PS3.18) the options supported and any restrictions shall be described.
Any implementation's DICOM conformance may be dependent upon configuration, which takes place at the time of installation. Issues concerning configuration shall be addressed in this section.
An important installation issue is the translation from AE title to Presentation Address. How this is to be performed shall be described in this section.
Note
There does not necessarily have to be a one to one relationship between AE titles and Application Entities. If so, this should be made clear in the tables.
The local AE title mapping and configuration shall be specified. The following table shall be used:
Table A.4.4-1. AE Title Configuration Table
|
Application Entity |
Default AE Title |
Default TCP/IP Port |
|---|---|---|
|
AE (1) |
Name |
Specify |
|
AE (2) |
Name |
Specify |
|
AE (x) |
If the implementation conforms to the Application Configuration Management Profile as an LDAP Client actor (see PS3.15), any use of LDAP to configure the local AE titles shall be described. Any conformance to the Update LDAP Server option shall be specified, together with the values for all component object attributes in the update sent to the LDAP Server.
Configuration of remote host names and port numbers shall be specified here.
Configuration of the remote AET port number, host-names, IP addresses and capabilities shall be specified. If applicable, multiple remote SCPs can be specified.
If the implementation conforms to the Application Configuration Management Profile as an LDAP Client actor (see PS3.15), any use of LDAP to configure the remote device addresses and capabilities shall be described. The LDAP queries used to obtain remote device component object attributes shall be specified.
Note
In particular, use of LDAP to obtain the AE Title, TCP port, and IP address for specific system actors (e.g., an Image Archive, or a Performed Procedure Step Manager) should be detailed, as well as how the LDAP information for remote devices is selected for operational use.
The specification of important operational parameters, and if configurable, their default value and range, shall be specified here. The parameters that apply to all Application Entities should be specified in a "General Parameters" section while those specific to particular Application Entities should be specified in separate sections specific to each AE. The following table, which is shown here with a recommended baseline of parameters, shall be used:
Table A.4.4-2. Configuration Parameters Table
|
Parameter |
Configurable (Yes/No) |
Default Value |
|---|---|---|
|
General Parameters |
||
|
Time-out waiting for acceptance or rejection Response to an Association Open Request. (Application Level timeout) |
||
|
General DIMSE level time-out values |
||
|
Time-out waiting for response to TCP/IP connect request. (Low-level timeout) |
||
|
Time-out waiting for acceptance of a TCP/IP message over the network. (Low-level timeout) |
||
|
Time-out for waiting for data between TCP/IP packets. (Low-level timeout) |
||
|
Any changes to default TCP/IP settings, such as configurable stack parameters. |
||
|
Definition of arbitrarily chosen origins |
||
|
Definition of constant values used in Dose Related Distance Measurements |
||
|
Other configurable parameters |
||
|
AE Specific Parameters |
||
|
Size constraint in maximum object size (see note) |
||
|
Maximum PDU size the AE can receive |
||
|
Maximum PDU size the AE can send |
||
|
AE specific DIMSE level time-out values |
||
|
Number of simultaneous Associations by Service and/or SOP Class |
||
|
<SOP Class support> (e.g., Multi-frame vs. single frame vs. SC support), when configurable |
||
|
<Transfer Syntax support>, e.g., JPEG, Explicit VR, when configurable |
||
|
Other parameters that are configurable |
||
Note
In particular when accommodating Multi-frame objects (e.g., Ultrasound Multi-frame, NM, XA, RF), a receiver might have a certain restriction with regard to its maximum length. This restriction should be specified here.
Additional configuration parameters such as hardware options for e.g., a printer shall be specified as well.