DICOM PS3.2 2019a - Conformance

A.4 Networking

This section contains the networking related services (vs. the media related ones).

A.4.1 Implementation Model

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.

A.4.1.1 Application Data Flow

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.

Functional Overview

Figure A.4.1-1. Functional Overview

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.


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.

A.4.1.2 Functional Definition of AEs

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.

A. Functional Definition of "Application Entity <1>"

Functional description of "Application Entity <1>" (substitute actual AE name), i.e., what is it that the AE performs.

A. Functional Definition of "Application Entity <2>"

Same for "Application Entity <2>".

A. Functional Definition of "Application Entity <3>"

Same for "Application Entity <3>".

A.4.1.3 Sequencing of Real World Activities

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.

DICOM PS3.2 2019a - Conformance