The Implementation Model shall identify the DICOM Application Entities in a specific implementation and relate the Application Entities to Real-World Activities.
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. Figure A.5.1-1 is a template for such a Data Flow Diagram. Accompanying the Application Data Flow Diagram shall be a discussion of the Application Data Flow represented.
In this illustration, according to Figure A.5.1-1, an occurrence of local Real-World Activity A or B will cause the local Application Entity 1 to initiate either creation of a File-set on a medium (FSC) for the purpose of interchange with a remote Real-World Activity X or to access a File-set on a medium for reading (FSR). The remote Real-World Activity X accesses the medium physically transferred from Real-World Activity A or B.
An occurrence of Real-World Activity C will cause the local Application Entity 2 to update a File-set (FSU) on a mounted medium.
If the AE expects a remote Real-World Activity to access the media for a specific purpose, this should be shown in the Application Data Flow Diagram as well as described in Section Section A.5.1.1.
The next part of the Conformance Statement shall contain a functional definition for each 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 the Media File System and mapping to particular Media Formats.
If applicable, this section shall contain a description of sequencing of Real World Activities that the AEs require.
An example of a situation in which a such a description is required is an AE that supports roles as a File-set Updater and File-set Reader. In some instances, the File-set will be updated then read (e.g., for verification); and in other instances, may be read first to determine if the File-set needs to be updated.
This section shall be used to list the values assigned to the File Meta Information attributes (see PS3.10) that pertain to the Implementation Class and Version. These are:
File Meta Information Version
Implementation Class UID
Implementation Version Name
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 type.
The following table, Table A.5.2-1, shows that for one or more Application Profiles in the first column, there are a number of Real-World Activities in the second column and the roles required for each of these Real-World Activities in the third column
Table A.5.2-1. AE Related Application Profiles, Real-World Activities, and Roles
|
Supported Application Profile |
Real-World Activity |
Roles |
|---|---|---|
|
STD-AP1 |
RWA A |
FSR |
|
RWA B |
FSR, FSC |
|
|
STD-AP1, AUG-AP2, etc. |
RWA C |
FSU |
|
RWA D |
FSC |
This section shall also contain any general policies that apply to all of the AEs described in subsequent section.
This section shall contain the values of the File Meta Information that pertain to the Application Entity (see PS3.10). These are:
Source Application Entity Title
If Private Information is used in the Application Profile File Meta Information, the following two File Meta Information attributes may be documented:
Private Information Creator UID
Private Information
The first sentence in this section shall state the Roles and Media Storage Service Class Options supported by the "Application Entity <1>".
The AE Specification shall contain a description of the Real-World Activities, which invoke the particular AE. There will be one section, A.5.2.1.2.i where i increments for each RWA, per Real-World Activity.
The Application Profile that is used by the AE described in A.5.2-1 is specified in this section.
The options used in the Application Profiled specified in Table A.5.2-1 shall be detailed in this section. There will be separate sections for each option specified for the AP. If there are no options used in the Application Profile specified in A.5.2.x, this section may be omitted.
This Section shall be used for the description of Augmented and Private Application Profiles.
Any Augmented Application Profiles used by an AE shall be described in these sections. The rules governing the structure of an Augmented AP shall be described.
Each Augmented Application Profile shall have a section A.5.3.1.x that describes the specific features of the Application Profile that make it Augmented. These shall be described in the three repeating sections that follow.
The additional SOP Classes beyond those specified in the Standard AP on which this Augmented AP is based shall be detailed in this section.
Any additions to the Directory IOD that augment this AP shall be described in this section.
The rules that govern construction of a Private Application Profile shall be described. This section shall be used to describe the details of the Private AP.
Refer to PS3.11 for a description of constructing a Private Application Profile.
If the AP deviates from the rules governing a Private AP in any manner, it is non-conformant and is outside the scope of this Standard.