Материал: part02

A.3.6 Abbreviations​

Abbreviationsshouldbelistedhere.Thesemaybetakenfromthefollowinglist,deletingtermsthatarenotusedwithintheConformance​ Statement, and adding any additional terms that are used:​

AE​ Application Entity​

AET​ Application Entity Title​

CAD​ Computer Aided Detection​

CDA​ Clinical Document Architecture​

CD-R​ Compact Disk Recordable​

CSE​ Customer Service Engineer​

CR​ Computed Radiography​

CT​ Computed Tomography​

DHCP​ Dynamic Host Configuration Protocol​

DICOM​ Digital Imaging and Communications in Medicine​

DIT​ Directory Information Tree (LDAP)​

DN​ Distinguished Name (LDAP)​

DNS​ Domain Name System​

DX​ Digital X-ray​

FSC​ File-Set Creator​

FSU​ File-Set Updater​

FSR​ File-Set Reader​

GSDF​ Grayscale Standard Display Function​

GSPS​ Grayscale Softcopy Presentation State​

HIS​ Hospital Information System​

HL7​ Health Level 7 Standard​

IHE​ Integrating the Healthcare Enterprise​

IOD​ Information Object Definition​

IPv4​ Internet Protocol version 4​

IPv6​ Internet Protocol version 6​

ISO​ International Organization for Standards​

IO​ Intra-oral X-ray​

JPEG​ Joint Photographic Experts Group​

LDAP​ Lightweight Directory Access Protocol​

LDIF​ LDAP Data Interchange Format​

- Standard -​

- Standard -​

VR​ Value Representation​

XA​ X-ray Angiography​

A.3.7 References​

Referenced documents should be listed here, including appropriate product manuals (such as service manuals that specify how to​ set DICOM communication parameters). References to the DICOM Standard should provide the URL for the free published version​ of the Standard, but should not specify a date of publication:​

NEMA PS3 Digital Imaging and Communications in Medicine (DICOM) Standard, available free at http://medical.nema.org/​

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 se-​ quencing 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 Applic-​ ation 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.​ WhentheperformanceofReal-Worldactivitiesreliesoninteractionswithintheimplementation,onemaydepictthecirclesasoverlapping​ 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.​

- Standard -​

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

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

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.4.1.2.1 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.4.1.2.2 Functional Definition of "Application Entity <2>"​

Same for "Application Entity <2>".​

A.4.1.2.3 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​ anyapplicableuserinteractions,asperformedbyalltheApplicationEntities.AUMLsequencediagram,whichdepictstheReal-World​ Activities as vertical bars and shows the events exchanged between them as arrows, is strongly recommended.​

- Standard -​

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

A.4.2.1 "Application Entity <1>"​

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

A.4.2.1.1 SOP Classes​

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

Table A.4.2-1. SOP Class(Es) for "Application Entity <1>"​

Any SOP specific behavior is documented later in the conformance statement in the applicable SOP specific conformance​ section.​

A.4.2.1.2 Association Policies​

Each AE Specification shall contain a description of the General Association Establishment and Acceptance policies of the AE.​

A.4.2.1.2.1 General​

The DICOM standard Application context shall be specified.​

A.4.2.1.2.2 Number of Associations.​

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

- Standard -​