Материал: part02

A.4.3.3 IPv4 and IPv6 Support​

ThesupportforspecificIPv4andIPv6featuresandassociatedoptionalIPv6securityandconfigurationfacilitiesshallbedocumented.​

A.4.4 Configuration​

Anyimplementation'sDICOMconformancemaybedependentuponconfiguration,whichtakesplaceatthetimeofinstallation.Issues​ concerning configuration shall be addressed in this section.​

A.4.4.1 AE Title/Presentation Address Mapping​

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

A.4.4.1.1 Local AE Titles.​

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​

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

A.4.4.1.2 Remote AE Title/Presentation Address Mapping​

Configuration of remote host names and port numbers shall be specified here.​

A.4.4.1.2.1 Remote SCP 1​

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

A.4.4.1.2.2 Remote SCP 2​

Etc.​

- Standard -​

A.4.4.2 Parameters​

The specification of important operational parameters, and if configurable, their default value and range, shall be specified here. The​ parametersthatapplytoallApplicationEntitiesshouldbespecifiedina"GeneralParameters"sectionwhilethosespecifictoparticular​ Application Entities should be specified in separate sections specific to each AE. The following table, which is shown here with a re-​ commended baseline of parameters, shall be used:​

Table A.4.4-2. Configuration Parameters Table​

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

A.5 Media Interchange​

A.5.1 Implementation Model​

TheImplementationModelshallidentifytheDICOMApplicationEntitiesinaspecificimplementationandrelatetheApplicationEntities​ to Real-World Activities.​

A.5.1.1 Application Data Flow Diagram​

As part of the Implementation Model, an Application Data Flow Diagram shall be included. This diagram represents all of the Applic-​ ation 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.​

- Standard -​

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

Local

Real-World

Activity A

Medium

Local

Real-World

Activity B

Figure A.5.1-1. Application Data Flow Diagram​

Note​

If the AE expects a remote Real-World Activity to access the media for a specific purpose, this should be shown in the Ap-​ plication Data Flow Diagram as well as described in Section Section A.5.1.1.​

A.5.1.2 Functional Definitions of AEs​

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

A.5.1.3 Sequencing of Real World Activities​

If applicable, this section shall contain a description of sequencing of Real World Activities that the AEs require.​

Note​

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

A.5.1.4 File Meta Information for Implementation Class and Version​

This section shall be used to list the values assigned to the File Meta Information attributes (see PS3.10) that pertain to the Imple-​ mentation Class and Version. These are:​

•​File Meta Information Version​

•​Implementation Class UID​

•​Implementation Version Name​

- Standard -​

A.5.2 AE Specifications​

The next section in the DICOM Conformance Statement is a set of Application Entity Specifications. There shall be one such specific-​ ation for each Application Entity type.​

A.5.2.1 "Application Entity <1>" - Specification​

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​

This section shall also contain any general policies that apply to all of the AEs described in subsequent section.​

A.5.2.1.1 File Meta Information for the "Application Entity <1>"​

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​

A.5.2.1.2 Real-World Activities​

The first sentence in this section shall state the Roles and Media Storage Service Class Options supported by the "Application Entity​ <1>".​

A.5.2.1.2.i "Real-World Activity <i>"​

TheAESpecificationshallcontainadescriptionoftheReal-WorldActivities,whichinvoketheparticularAE.Therewillbeonesection,​ A.5.2.1.2.i where i increments for each RWA, per Real-World Activity.​

A.5.2.1.2.i.1 Media Storage Application Profile​

The Application Profile that is used by the AE described in A.5.2-1 is specified in this section.​

A.5.2.1.2.i.1.y Options​

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

A.5.2.2 "Application Entity <2>" - Specification​

Each individual AE Specification has a subsection, A.5.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.5.2.1, and A.5.2.2.​

- Standard -​

A.5.3 Augmented and Private Application Profiles​

This Section shall be used for the description of Augmented and Private Application Profiles.​

A.5.3.1 Augmented 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.​

A.5.3.1.1 "Augmented Application Profile <1>"​

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

A.5.3.1.1.1 SOP Class Augmentations​

The additional SOP Classes beyond those specified in the Standard AP on which this Augmented AP is based shall be detailed in​ this section.​

A.5.3.1.1.2 Directory Augmentations​

Any additions to the Directory IOD that augment this AP shall be described in this section.​

A.5.3.1.1.3 Other Augmentations​

Any additions to, or extensions of the Application Profile shall be described in this section. An example of such another augmentation​ is addition of a role (FSR, FSC, FSU) to the Standard Application Profile set of defined roles.​

A.5.3.1.2 "Augmented Application Profile <2>"​

To be repeated for the second, third, etc. Augmented Application Profile.​

A.5.3.2 Private Application Profiles​

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

Note​

1.​Refer to PS3.11 for a description of constructing a Private Application Profile.​

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

A.5.4 Media Configuration​

Any implementation's DICOM conformance may be dependent upon configuration that takes place at the time of installation. Issues​ concerning configuration shall be addressed in this section (e.g., the configuration of the Source AE Title in File Meta Information).​

A.6 Transformation of DICOM to CDA​

The supported SR objects and corresponding template identifiers shall be described. The release version and template identifier of​ the generated valid CDA documents shall be documented. The transformation process may be described by reference to a specific​ Annex of PS3.20.​

A.7 Support of Character Sets​

Any support for Character Sets beyond the Default Character Repertoire in Network and Media Services shall be described here.​

•​The behavior when an unsupported character set is received shall be documented.​

- Standard -​