1、NEMA Standards Publication PS3.2(199x)最终文件 - 部分2医学数字成像和通讯(DICOM)部分2:遵从性状态：最终文件 - 1993年10 月29日这是一个草稿 - 不经NEMA 的同意，不得传播，引用或复制。DICOM - PART 2: ConformanceiFinal Text - October 29, 1993目 录2 Section Page前言14 1应用范围和领域22标准的参考26 3定义33.1参考模式定义.38 3.2 服务定义33.3 介绍服务定义310 3.4 DICOM介绍和概述定义 33.5 DICOM信息对象定义 312 3
2、.6 DICOM服务类规格定义 43.7 DICOM数据结构和编码定义 414 3.8 DICOM消息交换定义 43.9 DICOM上层服务定义 416 3.10 DICOM遵从性 44 符号和缩写.618 5约定85.1 应用程序数据流图表820 5.1.1 应用程序实体85.1.2真实世界行为.822 5.1.3 本地关系85.1.4关联.924 6 遵从性声明的目的.107遵从性要求1226 7.1 管理SOP类类型的规则 12A.0介绍 1528 A.1 实现模式 .15A.1.1应用程序数据流图 1530 A.1.2 AE的功能定义 .16A.1.3真实世界行为的排序 1632 A.
3、2AE说明 16A.2.x AEx-说明 1734 A.2.x.1关联制定策略 .17A.2.x.1.1常规 1736 A.2.x.1.2关联数目 17A.2.x.1.3异步性 1738 A.2.x.1.4实现识别信息 17A.2.x.2真实世界行为的关联初始化 .17DICOM - PART 2: ConformanceiiFinal Text - October 29, 1993A.2.x.2.i真实世界行为i .182 A.2.x.2.i.1有关的真实世界行为18A.2.x.2.i.2被提议的内容说明184 A.2.x.2.i.2.j SOP类j的SOP特殊遵从性声明 .19A.2.x.
4、3关联接受策略 .196 A.2.x.3.i真实世界行为i .19A.2.x.3.i.1关联的真实世界行为198 A.2.x.3.i.2介绍上下文表19A.2.x.3.i.2.j SOP类j的SOP特殊遵从性 .2010 A.2.x.3.i.3内容说明的接受标准20A.2.x.3.i.4传送语法选择策略2012 A.3通讯轮廓 20A.3.1支持的通讯栈（部分8，9） 2014 A.3.x OSI栈 20A.3.x.1国际标准轮廓(ISP) 2016 A.3.x.y API应用程序接口 .20A.3.x.z物理介质支持 .2018 A.3.x TCP/IP栈 .21A.3.x.y API应用程
5、序接口 .2120 A.3.x.z 物理介质支持 21A.3.x点对点栈 2122 A.4扩充/特殊化/私有化 .21A.4.1标准的扩展/特殊化/私有SOPs 2124 A.4.1.i标准的扩展/特殊化/私有SOP i 21A.4.2私有传送语法 2126 A.4.2.i私有传送语法i 21A.5配置 2128 A.5.1AE标题/介绍地址映射 .21A.5.2可配置参数 2230 A.6扩展字符集合的支持 22附录B （提供消息的）DICOM遵从性声明例子 .2332 B.0介绍 23B.1 实现模式 .2334 B.1.1 应用数据流图 23B.1.2 AEs的功能定义 2436 B.1
6、.3真实世界行为的排序 24B.2 说明 .2438 B.2.1 DIS和DAT说明 24B.2.1.1 关联制定策略 2540 B.2.1.1.1常规 25B.2.1.1.2 关联的数目 .25DICOM - PART 2: ConformanceiiiFinal Text - October 29, 1993B.2.1.1.3 异步性能 252 B.2.1.1.4 实现识别信息 .25B.2.1.2 关联初始化策略 254 B.2.1.2.1用Implicit VR编码的图象的传送 .26B.2.1.2.1.1关联的真实世界行为 .266 B.2.1.2.1.2被提议的内容说明 .26B.
7、2.1.2.2用Explicit VR编码并带有“-d“选项的图象的传送 278 B.2.1.2.2.1关联的真实世界行为 .27B.2.1.2.2.2被提议的内容说明 .2710 B.2.1.2.3用Explicit VR编码，指定“-d”选项的图象传送。 27B.2.1.2.3.1关联的真实世界行为 .2712 B.2.1.2.3.2被提议的内容说明 .28B.2.1.2.4 特殊遵从性 .2814 B.2.1.3 关联接受策略 29B.2.1.3.1关联的真实世界行为 2916 B.2.1.3.2被提议的内容说明 29B.2.1.3.3 SOP特定遵从性 .3118 B.2.1.3.3.
8、1对验证SOP类的SOP 特定遵从性 31B.2.1.3.3.2对存储SOP类的SOP 特定遵从性 3120 B.2.1.3.4介绍上下文准则 32B.2.1.3.5传送语法选择策略 3222 B.3通讯策略 32B.3.1支持的通讯栈（部分8，9） 3224 B.3.2 TCP/IP栈 .32B.3.2.1物理介质支持 .3226 B.4扩展 /特殊化/私有化 32B.5.0配置 .3328 B.5.1 AE标题/介绍地址映射 33B.5.2配置参数 3330 B.5.2.1 DIS配置 .33B.5.2.2 DAT配置 3332 B.6扩展字符集合的支持 .34DICOM - PART 2
9、: Conformance1Final Text - October 29, 1993前言ACR (美国放射学学会)和NAMA（国家电气制造商协会）组成了一个联合委员会来开发一个医学数字成像和通讯的标准。这个DICOM标准的开发符合NEMA的程序。这个标准的开发得到了诸如欧洲的CEN TC251和日本的 JIRA等标准组织的支持，并由其他组织复审，这些组织包括IEEE、HL7和USA 的ANSI 。D DICOM标准是按照下面的文档制订的方针构建的一个多部分的文档。- ISO/IEC指令，1989第三部分 国际标准的起草和介绍。这个文档是DICOM标准的一部分，包括以下内容：第一部分 - 介绍
10、和概述第二部分：遵从性第三部分：信息对象定义第四部分：服务类说明第五部分 - 数据结构和语义学第六部分 - 数据字典第七部分 - 消息交换第八部分 - 消息交换的网络通讯支持第九部分 - 消息交换的点对点通讯支持这些部分是相关的而又独立的文档。他们的开发水平和认可状态可以不同。补充部分可以加到这个多部分的标准中。部分1应该作为标准的当前部分的基本参考。DICOM - PART 2: Conformance2Final Text - October 29, 19931应用范围和领域DICOM标准的部分2定义了执行声明的遵循性的标准要遵循的原则。部分2指定了：- 最小的通用遵从性要求，任何执行声明
11、的遵从性的DICOM标准必须满足它。在DICOM标准其他章节中的遵从性部分可以找到对特殊特性、服务类、信息对象和通讯协议的附加遵从性要求。- 部分2遵从性声明的目的和结构提供了一个框架。通过它，遵从性信息可以放入到遵从性声明中，由标准其他部分的遵从性部分规定。DICOM标准没有指定：- 评定实现对标准遵从性的测试或验证过程。- 评定一个执行过程是否匹配它的遵从性声明的测试或验证过程。- 什么样的可选的特性，服务类，或信息对象应该被一个给定类型的设备所支持。2标准的参考下面的标准包含了组成标准贯穿本文的参考的必须部分。在出版的时候，所示的版本是合法的。所有的标准服从于修订版本，并且基于这个标准的
12、协议的当事人被鼓励来调查在下面列出的标准的最近版本的应用可能性。ISO/IEC指导，1989年部分3 国际标准的起草和介绍ISO 7498-1 信息处理系统 开放系统互连 基本参考模式ISO 8649:1988 信息处理系统 开放系统互连 联合控制服务元素(ACSE)的服务定义。ISO 8822：1988 信息处理系统 开放系统互连 连接定向介绍服务定义。DICOM - PART 2: Conformance3Final Text - October 29, 19933定义目的是下面定义应用的这个标准。3.1参考模式定义这个部分的定义使用下面的ISO 7498-1定义的条款：a) 应用程序实体
13、b) 应用程序实体标题c) 协议数据单元d) .传送语法3.2 ACSE服务定义这个部分的标准使用了ISO8649定义的下面的条款：a) 联合或应用联合b) .联合的创始者3.3 介绍服务定义这个部分的标准使用了ISO 8822定义的下面的条款：a) 抽象语法b) 抽象语法名c) 介绍内容d) 传送语法e) .传送语法名3.4 DICOM介绍和概述定义这个部分的标准使用了在DICOM的部分1中定义的下面的条款：a) 信息对象3.5DICOM 信息对象定义这个部分的标准使用了DICOM的部分3定义的下面的条款：a) 信息对象定义（IOD ）DICOM - PART 2: Conformance4
14、Final Text - October 29, 19933.6 DICOM服务类规范定义这个部分的标准使用了DICOM的部分4定义的下面的条款：a)现实世界的行动b) 服务类c) 服务类用户（SCU）d) 服务类提供者（SCP）e) 服务对象成对（SOP）类f)变换SOP类3.7 DICOM数据结构和编码定义这个部分的标准使用了DICOM的部分5定义的下面的条款：a) DICOM定义的 UIDb) 私有定义的UIDc)传送语法（标准的和私有的）d).唯一的标志符（UID ）3.8 DICOM消息交换定义这个部分的标准使用了DICOM的部分7定义的下面的条款：a)扩展协商b)实现类 UID3.
15、9 DICOM上层服务定义这个部分的标准使用了DICOM的部分8定义的下面的条款：a)唯一的标识符b)DICOM高层服务c)介绍地址3.10 DICOM遵从性DICOM标准的这个部分使用了下面的定义：3.10.1 : 遵从性声明：一个与DICOM标准的特定实现相关联的正式声明。它指定了服务类，信息对象和实现支持的通讯协议。DICOM - PART 2: Conformance5Final Text - October 29, 19933.10.2SOP类的标准：一个定义在DICOM标准中的SOP类，未作修改的用于实现中。3.10.3标准扩展的SOP类：在实现中扩展，具有附加的类型3属性，定义在
16、DICOM 标准中的SOP类。附加的属性可以从部分6的数据字典中抽出，或者可以是私有属性。当它不存在时，相关标准SOP类的语义学不应由附加的类型3属性修改。所以，标准扩展SOP类利用相同的UID作为相关的标准SOP 类。注意: 来自标准扩展SOP类的IODs 可以在DICOM实现之间自由地交换，因为不熟悉附加的类型3特性的实现将完全忽略他们。3.10.4专用的SOP类:.从标准的SOP 类派生的SOP类，这个类在一个实现中通过附加的类型1、1C 、2、2C或3属性应用。附加的属性可以由第6部分数据字典中取得，或者是私有属性。因为相关标准SOP类的语义学可以被附加的属性修改，一个专用的SOP类利
17、用一个私有定义的UID，这个UID与相关的标准SOP 类的 UID不同。注意：因为一个专用的SOP类有一个与标准的或标准扩展的SOP类所不同的UID，其他DICOM实现可以不认识专用的SOP类。因为这个限制，一个专用的SOP类，只应在标准的或标准扩展的SOP类不适当情况下使用。在不同的实现在专用的SOP类中交换IOD s以前，实现必须就UID ，内容（特别地，附加的类型1，1C,2,2C属性），和专用SOP类的语义学取得一致。一个专用地SOP类可以用来创建一个新的或实验的SOPl类，它与标准的SOP类有很近的关系。一个实现发行一个专用SOP类，是希望其他的实现可以使用这个类。3.10.5私有S
18、OP类: 一个SOP 类，在DICOM标准中没有定义，而发布在一个实现的遵从性声明中。注意：因为一个私有的SOP类不在DICO定义M标准中，其他的DICOM 实现可以不认识私有的SOP 类。因为这个限制。一个私有的SOP类只在一个标准或标准扩展的SOP类不合适时才被使用。为了不同的实现在私有的SOP类中交换IODs，实现必须就UID，内容（特别地，类型 1,1C,2,2C属性），和私有SOP类的语义学达成一致。一个私有的SOP类可以用来创建一个全新的或实验用的SOP类。一个实现发行一个私有SOP类，是希望其他的实现可以使用这个类。3.10.6 标准属性: .一个定义在部分6的数据字典中定义的属
19、性。3.10.7 私有属性: .一个没有定义在DICOM标准内定义的属性。DICOM - PART 2: Conformance6Final Text - October 29, 19934 符号和缩写下面的符号和缩写用在标准的这个部分。ACR American College of Radiology 美国放射学学会ACSE Associated Control Service Element联合控制服务元素API Application Programming Interface应用程序编程接口ASCII American National Standards Institute美国信息交
20、换标准码AE Application Entity 应用实体ANSI American National Standards Institute 美国国家标准协会CEN TC251 Comite Europeen de Normalisation- Technical Committee 251 - Medical Informatics欧洲标准化协会 - 技术委员会 251 - 医学信息学DICOM Digital Imaging and Communications in Medicine 医学数字成像和通讯DIMSE DICOM Message Service Element DICOM
21、消息服务元素DIMSE-C DICOM Message Service Element-Composite 复合DICOM消息服务元素DIMSE-N DICOM Message Service Element-Normalized 规格化DICOM消息服务元素HISPP Healthcare Information Standards Planning Panel 医疗信息学标准计划编制小组HL7 Health Level 7IE Information Entity 信息实体IEEE Institute of Electrical and Electronics Engineers 电气和电
22、子工程师协会IOD Information Object Definition 信息对象定义ISO International Standards Organization 国际标准组织ISP International Standard Profile 国际标准化轮廓文件JIRA Japanese Industry Radiology Apparatus 日本工业放射学仪器MSDS Healthcare Message Standard Developers Sub-Committee 医疗消息标准开发者分协会NEMA National Electrical Manufacturers As
23、sociation 国家电气制造商协会OSI Open Systems Interconnection 开放系统互连PDU Protocol Data Unit 协议数据单元SCP Service Class Provider 服务类提供者SCU Service Class User 服务类用户SOP Service-Object Pair 服务对象对TCP/IP Transfer Control Protocol/Internet Protocol 传输控制协议/ 互连网协议DICOM - PART 2: Conformance7Final Text - October 29, 1993UI
24、D Unique Identifier 唯一的标识符DICOM - PART 2: Conformance8Final Text - October 29, 19935约定5.1 应用程序数据流图表在一个遵从性声明中,真实世界活动与应用程序实体之间的关系由应用程序数据流图表阐明。5.1.1 应用程序实体一个应用程序实体被描述为一个在方框内的应用程序数据流图，如图5.1.1所示。Figure 5.1.1 Application Entity ConventionApplication Entity 5.1.2现实世界活动一个现实世界活动被描述为一个在圆内的应用程序数据流图，如图5.1.2所示。F
25、igure 5.1.2 Real-World Activity ConventionReal-World Activity . 代表多个真实世界行为的圆可以重叠，表明了真实世界行为中的重叠度。5.1.3 本地关系本地真实世界行为和应用程序之间的关系被描述在应用程序数据流图内，本地真实世界行为放置到相关应用程序实体的左边，并在他们中间放入一个双箭头。Figure 5.1.3 Local Relationship ConventionDICOM - PART 2: Conformance9Final Text - October 29, 1993LocalReal-World Activity A
26、pplication Entity 一个应用程序实体可以与多个现实世界活动关联。.一个现实世界活动可以与多个应用程序实体关联。5.1.4关联支持远程现实世界活动的本地应用实体与远程应用实体之间的关联被描述在这样一个数据流图内，把远程现实世界活动放到相关的本地应用程序实体的右边，在他们之间画入一个或两个箭头，如图5.1.4所示。破折线代表本地应用实体，与任何处理远程真实世界行为的远程应用程序之间的DICOM 标准接口。从本地应用实体到远程现实世界活动的箭头指出本地现实世界活动的一个事件将引起本地应用实体初始化一个关联，目的是引起远程真实世界行为的发生。从远程现实世界活动到本地应用实体的箭头指出，
27、当远程现实世界活动发生时，本地应用程序实体期望收到一个关联请求，引起本地应用实体执行本地真实世界行为。Figure 5.1.4 Associations ConventionLocal Real-World ActivityLocal Application EntityRemote Real-World ActivityDICOM Standard Interface DICOM - PART 2: Conformance10Final Text - October 29, 19936 遵从性声明的目的DICOM标准包含许多可选的组件。一次执行可以从下面选择：- 通讯方式的几个选择（也就是，
28、OSI，TCP/IP ， DICOM 点对点，存储介质互换，等等）；- 编码信息对象的传输语法的几种选择；- 几个SOP类（信息对象定义和相关服务的组合），他们中的许多是为特定的任务或特殊形式设计的。- 在IODs内，几个可选的（类型3）属性（一次执行可以选择使用或忽略它们）。一次执行不需要采用DICOM标准的所有可选组件。在复合了最小的常规要求后，一个完整的DICOM执行可以利用完成这项设计任务所需要的任何S OP类，通讯协议，可选（类型3）属性，等等，。注意：实际上，希望一次执行只支持与它的现实世界活动相关的SOP类。例如，一个简单的胶片数字转换器可以不支持其他成像模式的SOP类，因为可以
29、不要求有这样的支持。另一方面，为了充分执行存储服务器的功能，可以要求一个复杂的存储服务器支持多形式的SOP类。一次执行选择DICOM标准的哪一个组件加以利用，很大程度上依赖于原有的应用程序并超出这个标准的范围。另外，DICOM标准允许一个实现扩展或专用化DICOM定义的SOP类，也允许定义私有SOP类。遵从性声明允许用户决定一次执行支持DICOM标准的那些可选组件，并增加什么额外的扩展或特殊化的一次执行。通过比较两次不同执行的遵从性声明，一个有见识的用户应该能够决定是否和什么扩展通讯应该在两个实现之间被支持。一个遵从性声明有下面的主要部分组成：- 一次执行模式，它描述执行中的应用程序实体，以及
30、本地、远程真实世界行为之间如何发生关系。- 每一个应用程序实体的更加详细的说明（或规范），它列出了支持的SOP类并且概括了用来初始化或接受关联的策略。- 对于每一个应用程序实体和真实世界行为的组合，被提议的（对关联的初始化）和可接受的（对关联的接受）表述关系的描述。注意:一个表述关系由一个抽象语法加一个可接受的传输语法列表组成。抽象语法识别一个SOP 类或变换SOP类（由单一的抽象语法UID识别的相关的SOP 类的集合）。通过列出应用实体带有他们的被建议的和可接受的表述关系，遵从性声明识别执行所验证的信息对象和服务类的集合。DICOM - PART 2: Conformance11Final
31、Text - October 29, 1993- 对每一个与抽象语法相关的SOP类，任何支持SOP选项的列表。- 一组本次执行支持的通讯协议的集合。- 本次执行内的任何扩展，特殊化和公开暴露的私有化的描述。- 描述DICOM相关配置细节的部分。- .任何实现细节的描述，这些细节可以与DICOM遵从性或互操作性相关。DICOM - PART 2: Conformance12Final Text - October 29, 19937遵从性要求声明DICOM遵从性的实现将:- 遵照在这个部分定义的最小的遵从性要求。- 提供实现依照这部分包括附录A中的规则和策略构造的遵从性声明- 遵照至少一个定义在
32、部分4中标准的或标准扩展的SOP类。注意： 与标准的或标准扩展SOP类的一致，意味与在部分3中描述的相关IOD、在部分6定义的数据元素和在部分7定义的操作和通知保持一致。- 遵从在章节7.1中概括的管理SOP类类型的规则。- 如果执行接受任何的DICOM联合请求，就把一个验证SOP 类的表述关系接受为一个SCP，。- 产生和/或处理在部分5中定义的数据集合。注意： 与部分5一致也意味着与部分6一致。- 如果一次执行利用私有定义的UIDs（也就是，UIDs 没有定义在DICOM标准内），获得合法的创建UIDs（见第五部分）的注册过 的权利。- 支持一个或更多的下面的通讯模式：a)部分8 TCP/
33、IPb)部分 8 OSIc)部分9 点对点d)部分 10，部分11，部分12存储介质互换。注意：部分10，11，和12定义了存储在物理介质上的DICOM信息对象的通讯。这三个部分上的工作正在进行。作为一个结果，部分2可以需要扩展为清楚地说明DICOM介质存储实现的遵从性。7.1管理SOP 类的类型的规则发表在遵从性声明的每一个SOP类不是四个基本类型之一。在声明与DICOM标准一致的实现中的每一个SOP应该根据下面的规则处理，由SOP类的类型支配。标准SOP类遵从所有的DICOM 的相关部分，没有增加或改变。为了声明遵从标准SOP类，一次执行必须在它的遵从性声明中对这个事实做出声明，并且识别它
34、选择的选项，角色，和行为。l标准扩展的SOP类将:a) 是一个标准SOP类的适当超集;DICOM - PART 2: Conformance13Final Text - October 29, 1993b) 不改变标准SOP类的任何标准属性的语义学;c) 不包含任何私有类型1，1C，2，2C属性;d) 不把任何标准类型3属性改变为类型1，1C，2，2C的;e) 使用相同的UID作为它所基于的标准SOP 类.只要遵从性声明识别附加的属性和定义了他们与部分3信息模式之间的关系，一个标准扩展SOP类可以包括标准和/或私有类型3属性，超过了那些定义在 IOD内的属性。 .声明遵从标准扩展SOP类的实现
35、，必须识别在遵从性声明内被扩展的标准SOP类，可选项，角色和选择的行为，以及描述与标准SOP类的IOD模式和模块一起增加的属性。特殊化的SOP类应:a) 完全遵从DICOM标准的有关部分;b) 基于标准的SOP类，也就是:- 包含它所基于的标准SOP类的所有的类型1，1X，2和2C属性;- 不改变任何标准属性的语义学;c) 使用私有定义UDI（也就是，不应该被认为与DICOM 定义的UID一致）d) 基于DICOM标准的部分3和4的DICOM信息模式.特殊化SOP类可以：a) 包含额外的标准和/或私有的类型1，1C，2，或2C属性；b) 增加私有和标准类型3属性，它可以或不可以在遵从性声明中发
36、表。 注意： 任何未发表的属性的使用可以被其他的用户和特殊SOP类的提供这所忽略。声明遵从特殊SOP类的实现应包含在它的遵从性声明中被特殊化的标准SOP类的身份，对所有在特殊化SOP类中标准的和私有的类型1，1C，2，和2C属性用法的描述，以及联合私有定义的UIDs。.私有SOP类应:a) 遵从DICOM标准的相关部分，不要求支持DICOM默认传输语法的部分可以除外；b) 不改变任何标准属性的部分6的说明；c) 使用一个私有定义的UIDs（也就是，不应认为与DICOM定义的UID一致。）d) 不改变存在的DIMSE服务或创建新的服务。DICOM - PART 2: Conformance14F
37、inal Text - October 29, 1993私有SOP类可以：a) 使用或应用DIMSE服务来私有定义或改变IODs(也就是，不必基于一个标准的SOP类)b) 指定任何的标准属性为类型1，1C，2，或2C，不考虑其他IODs 的属性的类型；c) 定义私有的属性为类型1，1C，2，或2C；d) 包括私有的和标准的类型3属性，它可以或不可以在遵从性声明中发表。一个声明与一个私有的SOP类一致的实现应在执行的遵从性声明中提供一个与第3、4和6部分相似的私有SOP类的描述，包含SOP 类中所有的标准的和私有的类型1，1C，2或2C属性的用法的描述，DICOM信息模型和私有定义的UIDs。注
38、意：为了允许一个实现支持在DICOM 应用程序前后关系中的其他抽象语法，未发表的 SOP类（也就是，SOP类不被定义在DICOM标准中，并不被定义在遵从性声明中）是许可的。这样的未发表的SOP类将利用私有定义的UIDs。一个未发表SOP类的出现不妨碍实现 DICOM遵从性，但将对与其他的实现是无意义的，并且可以被忽略。DICOM - PART 2: Conformance15Final Text - October 29, 1993附录A（规范化）DICOM 遵从性声明模板A.0介绍这个附录是一个模板，它用来产生一个DICOM遵从性声明。一个DICOM 遵从性声明应该由一个建立框架的介绍开始。
39、介绍应描述实现，和在大多数情况下，它如何使用DICOM来完成它的目的。注意： 在这个文档中用来编号段落的编号表将用做一个遵从性声明的提纲准备的指导。遵从性声明不要求有精确的相同的段落号。实际上，任何特殊的遵从性声明将有特殊的考虑，这些考虑要引起提纲的某些细节与这个文档的要点不同。A.1 实现模式在介绍之后，遵从性声明的第一个部分是对实现模型的描述。实现模型由一个应用程序数据流图、应用程序实体的功能定义和他们相关的现实世界活动组成，如果可以，还有现实世界活动的排序描述。A.1.1应用程序数据流图作为实现模式的一部分，一个应用程序数据流图应该包括进来。这个图代表了所有的出现在实现中的应用程序实体
40、，并且图形化的描述了DICOM对于现实世界活动的AE s用途的关系。图A1.1.-1就是这样一个数据流图的模板。伴随应用程序数据流图的应是一个应用程序数据流所代表的讨论。在这个说明中，根据图A.1.1-1，本地现实世界活动A的出现将引起本地应用程序实体1初始化一个以引起远程现实世界活动X远程发生的关联。它也显示了真实世界活动 B和Y相互地，通过应用程序实体2，与本地B和远程Y发生关系，并且当远程真实世界活动 Z发生时，本地应用程序实体3期望收到一个关联请求，这样它可以执行现实世界活动C和/或D 。图A.1.1-1也显示出在一些真实世界活动中有一定程度地重叠。任何这样的重叠将在这里讨论。DICO
41、M - PART 2: Conformance16Final Text - October 29, 1993Figure A.1.1-1. Implementation ModelAssociation InitiationAssociation AcceptanceLocal Application Entity 1Local Application Entity 2Local Application Entity 3Local Real-World Activity ALocal Real-World Activity BLocal Real-World Activity CRemote
42、Real-World Activity XRemote Real-World Activity YRemote Real-World Activity ZDICOM Standard Interface Local Real-World Activity DA.1.2 AE的功能定义.实现模型的下一个部分应包含有每一个本地应用程序实体的功能定义。这将描述大多数情况下由AE 执行的功能和用来完成这些功能的DICOM服务。在这种意义下，“DICOM服务”不只是面向DICOM服务类，也是面向低层DICOM服务，如关联服务。A.1.3现实世界活动的排序如果可行，这个部分应包含AE需要的现实世界活动的排
43、序描述。注意： 一个需要这样描述的情况的例子是一个AE，这个AE支持存储服务类的SOP和检查内容通知服务类的SOP。一些实现将需要在检查内容通知发送之前存储图象，一些在这之后，一些可以对这样的排序很迟钝。A.2AE说明DICOM遵从性声明的下一部分是应用程序实体说明的集合。那里应有一个这样的每个应用程序实体类型的说明。DICOM - PART 2: Conformance17Final Text - October 29, 1993A.2.x AEx-说明每一个单独的AE说明有一个子部分，A.2.x。那些子部分和执行中不同的AE是同样多的。就是说，如果有两个不同的AEs，就有两个子部分，A.2
44、.1和A.2.2 。一个应用程序实体的说明应包含有形式的声明：“这个应用实体为:：下面DICOM V3.0 SOP 类作为一个SCU包括SOP类的列表 提供标准的遵从性，以及下面DICOM V3.0 SOP类作为一个SCU包括SOP类的列表 提供标准的遵从性。”A.2.x.1关联制定策略每一个AE 说明应包含有AE的关联制定策略的描述。这描述了在什么情况下AE将初始化和接受一个关联。A.2.x.1.1常规这个段描述任何管理关联初始化的常规规则。它应包含最大的将被提供/接受的PDU 尺寸。A.2.x.1.2关联数目一个应用程序实体可以支持的同时关联的数目应该被指定。任何控制同时的关联的规则应在这
45、里定义。注意： 例如一个AE可以有能力来接受多达10个同时的关联，但可以限制它自己有不超过 2个的与其他的特殊的AE关联。也可以有基于同时的现实世界活动组合的同时策略。A.2.x.1.3 Asynchronous Nature异步本能如果实现支持若干显著的处理磋商，将在这里声明，同时有显著的处理支持的最大数目。A.2.x.1.4实现识别信息这个提供给实现类UID的值应该在这里写入文档。如果提供一个版本名，这个细节将在这里写入文档。定义提供版本名的值的策略在这里声明。A.2.x.2由现实世界开始的关联如果一个AE 开始关联，它将开始一个关联的情况将在这里列举出来。如果AE从不开始关联，段A.2.
46、x.2应由声明这个事实的单独的句子组成，没有子段。否则，段 A.2.x.2应包含每种现实世界活动的情况它将引起一个关联开始的子段A.2.x.2.i。DICOM - PART 2: Conformance18Final Text - October 29, 1993A.2.x.2.i现实世界活动iA.2.x.2.i.1关联的现实世界活动子段A.2.x.2.i.1应描述引起AE开始DICOM关联的现实世界活动的部分。 A.2.x.2.i.2被提议的陈述关系每一次一个关联开始，联合发起人建议许多陈述关系用在那个关联上。在这个子段中，由应用程序实体为现实世界行为建议的陈述关系应定义在使用以下格式的一个
47、表中。Table A.2.x.2.i.2-1 Proposed Presentation Contexts for Application Entity and Real-World Activity Presentation Context TableAbstract Syntax Transfer Syntax Role ExtendedName UID Name List UID Negotiationname_a AS_UID_a XS_Name_1, _, XS_Name_nXS_UID_1, _, XS_UID_nSCP | SCU | BOTHNone |See NOTE | S
48、ee table A.2.x.2.i.2-j_ _ _ _ _ _注意: 描述为这个陈述关系的SOP类所做的任何扩展磋商的内容。就像一个单一的抽象语法常常对应于一个单独的可以出现在不同的陈述关系的SOP类，一个NOTE可以服务于多个陈述关系。在图A.2.x.2.i.2中，下面的意义分配给这些字段：这个是与陈述关系一起使用的抽象语法的名字。这个是用于陈述关系的抽象语法的UID。这个是用于陈述关系的传送语法的名字。对应的传送语法的UID。在这个事件中，陈述关系的抽象语法代表了一个变换SOP类（那就是，它包含很多的SOP类），并且扩展磋商支持这些SOP类中的一些，定义这个扩展的磋商下面的表示必须的。
49、这个表在表A.2.x.2.i.2-1中:SOP Class name SOP Class UID Extended NegotiationName_i SOP_UID_i None | See NOTE_ _ _注意： 描述了任何为这个SOP类所做的磋商的内容。就像一个以不同陈述关系出现的SOP 类和/或变换的SOP类，一个NOTE可以服务于多个陈述关系。DICOM - PART 2: Conformance19Final Text - October 29, 1993A.2.x.2.i.2.j SOP类j的SOP特殊遵从性声明这里是每一个特殊的SOP类j( 对应于现实世界事件i,通过AEx)的SOP 特定的遵从性规定的地方。这个声明应于在部分4（或相关的私有SOP定义）的SOP特定遵从性声明描述的一样。.它应包括任何扩展磋商的内容。A.2.x.3关联接受策略如果一个AE 接受关联，在这里把它接受一个关联的条件列举出来。如果一个AE从不接受关联，段A.2.x.2应由一个单独的声明这个细节并没有子段的句子组成。否则，段 A.2.x.2应包含每一个现实世界活动的情况（在这个情况下，一个关联将被接受）的子段A.2.x.2.i。A.2.x.3.i现实世界活动i段的标题应反映关联被接受的情况。这个
