DICOM中文版第二章

转载 2006年05月26日 12:46:00
最终文件 -- 部分2




医学数字成像和通讯(DICOM)




部分2:遵从性




状态:最终文件 - 1993年10月29日
这是一个草稿 -  不经NEMA的同意,不得传播,引用或复制。
 
目       录
Section Page
前言 1
1应用范围和领域 2
2标准的参考 2
3定义 3
3.1参考模式定义 3
3.2 服务定义 3
3.3 介绍服务定义 3
3.4 DICOM介绍和概述定义 3
3.5 DICOM信息对象定义 3
3.6 DICOM服务类规格定义 4
3.7 DICOM数据结构和编码定义 4
3.8 DICOM消息交换定义 4
3.9 DICOM上层服务定义 4
3.10 DICOM遵从性 4
4 符号和缩写 6
5约定 8
5.1 应用程序数据流图表 8
5.1.1 应用程序实体 8
5.1.2真实世界行为 8
5.1.3 本地关系 8
5.1.4关联 9
6 遵从性声明的目的 10
7遵从性要求 12
7.1 管理SOP类类型的规则 12
A.0介绍 15
A.1 实现模式 15
A.1.1应用程序数据流图 15
A.1.2 AE的功能定义 16
A.1.3真实世界行为的排序 16
A.2AE说明 16
A.2.x AEx-说明 17
A.2.x.1关联制定策略 17
A.2.x.1.1常规 17
A.2.x.1.2关联数目 17
A.2.x.1.3异步性 17
A.2.x.1.4实现识别信息 17
A.2.x.2真实世界行为的关联初始化 17
A.2.x.2.i真实世界行为i 18
A.2.x.2.i.1有关的真实世界行为 18
A.2.x.2.i.2被提议的内容说明 18
A.2.x.2.i.2.j SOP类j的SOP特殊遵从性声明 19
A.2.x.3关联接受策略 19
A.2.x.3.i真实世界行为i 19
A.2.x.3.i.1关联的真实世界行为 19
A.2.x.3.i.2介绍上下文表 19
A.2.x.3.i.2.j SOP类j的SOP特殊遵从性 20
A.2.x.3.i.3内容说明的接受标准 20
A.2.x.3.i.4传送语法选择策略 20
A.3通讯轮廓 20
A.3.1支持的通讯栈(部分8,9) 20
A.3.x OSI栈 20
A.3.x.1国际标准轮廓(ISP) 20
A.3.x.y API应用程序接口 20
A.3.x.z物理介质支持 20
A.3.x TCP/IP栈 21
A.3.x.y API应用程序接口 21
A.3.x.z 物理介质支持 21
A.3.x点对点栈 21
A.4扩充/特殊化/私有化 21
A.4.1标准的扩展/特殊化/私有SOPs 21
A.4.1.i标准的扩展/特殊化/私有SOP i 21
A.4.2私有传送语法 21
A.4.2.i私有传送语法i 21
A.5配置 21
A.5.1AE标题/介绍地址映射 21
A.5.2可配置参数 22
A.6扩展字符集合的支持 22
附录B(提供消息的)DICOM遵从性声明例子 23
B.0介绍 23
B.1 实现模式 23
B.1.1  应用数据流图 23
B.1.2 AEs的功能定义 24
B.1.3真实世界行为的排序 24
B.2 说明 24
B.2.1 DIS和DAT说明 24
B.2.1.1 关联制定策略 25
B.2.1.1.1常规 25
B.2.1.1.2 关联的数目 25
B.2.1.1.3  异步性能 25
B.2.1.1.4 实现识别信息 25
B.2.1.2 关联初始化策略 25
B.2.1.2.1用Implicit VR编码的图象的传送 26
B.2.1.2.1.1关联的真实世界行为 26
B.2.1.2.1.2被提议的内容说明 26
B.2.1.2.2用Explicit VR编码并带有"-d"选项的图象的传送 27
B.2.1.2.2.1关联的真实世界行为 27
B.2.1.2.2.2被提议的内容说明 27
B.2.1.2.3用Explicit VR编码,指定“-d”选项的图象传送。 27
B.2.1.2.3.1关联的真实世界行为 27
B.2.1.2.3.2被提议的内容说明 28
B.2.1.2.4 特殊遵从性 28
B.2.1.3 关联接受策略 29
B.2.1.3.1关联的真实世界行为 29
B.2.1.3.2被提议的内容说明 29
B.2.1.3.3 SOP特定遵从性 31
B.2.1.3.3.1对验证SOP类的SOP特定遵从性 31
B.2.1.3.3.2对存储SOP类的SOP特定遵从性 31
B.2.1.3.4介绍上下文准则 32
B.2.1.3.5传送语法选择策略 32
B.3通讯策略 32
B.3.1支持的通讯栈(部分8,9) 32
B.3.2 TCP/IP栈 32
B.3.2.1物理介质支持 32
B.4扩展/特殊化/私有化 32
B.5.0配置 33
B.5.1 AE标题/介绍地址映射 33
B.5.2配置参数 33
B.5.2.1 DIS配置 33
B.5.2.2 DAT配置 33
B.6扩展字符集合的支持 34
 
前言
ACR (美国放射学学会)和NAMA(国家电气制造商协会)组成了一个联合委员会来开发一个医学数字成像和通讯的标准。这个DICOM标准的开发符合NEMA的程序。
这个标准的开发得到了诸如欧洲的CEN TC251和日本的JIRA等标准组织的支持,并由其他组织复审,这些组织包括IEEE、HL7和USA的ANSI。
D DICOM标准是按照下面的文档制订的方针构建的一个多部分的文档。
- ISO/IEC指令,1989第三部分 – 国际标准的起草和介绍。
这个文档是DICOM标准的一部分,包括以下内容:
第一部分 - 介绍和概述
第二部分:遵从性
第三部分:信息对象定义
第四部分:服务类说明
第五部分 - 数据结构和语义学
第六部分 - 数据字典
第七部分 - 消息交换
第八部分 - 消息交换的网络通讯支持
第九部分 - 消息交换的点对点通讯支持
这些部分是相关的而又独立的文档。他们的开发水平和认可状态可以不同。补充部分可以加到这个多部分的标准中。部分1应该作为标准的当前部分的基本参考。
 

1应用范围和领域
DICOM标准的部分2定义了执行声明的遵循性的标准要遵循的原则。部分2指定了:
- 最小的通用遵从性要求,任何执行声明的遵从性的DICOM标准必须满足它。在DICOM标准其他章节中的遵从性部分可以找到对特殊特性、服务类、信息对象和通讯协议的附加遵从性要求。
- 部分2—遵从性声明的目的和结构提供了一个框架。通过它,遵从性信息可以放入到遵从性声明中,由标准其他部分的遵从性部分规定。
DICOM标准没有指定:
- 评定实现对标准遵从性的测试或验证过程。
- 评定一个执行过程是否匹配它的遵从性声明的测试或验证过程。
- 什么样的可选的特性,服务类,或信息对象应该被一个给定类型的设备所支持。
2标准的参考
下面的标准包含了组成标准贯穿本文的参考的必须部分。在出版的时候,所示的版本是合法的。所有的标准服从于修订版本,并且基于这个标准的协议的当事人被鼓励来调查在下面列出的标准的最近版本的应用可能性。
ISO/IEC指导,1989年部分3 – 国际标准的起草和介绍
ISO 7498-1 信息处理系统 – 开放系统互连 – 基本参考模式
ISO 8649:1988 信息处理系统 – 开放系统互连 – 联合控制服务元素(ACSE)的服务定义。
ISO 8822:1988 信息处理系统 – 开放系统互连 – 连接定向介绍服务定义。
 

3定义
目的是下面定义应用的这个标准。
3.1参考模式定义
这个部分的定义使用下面的ISO 7498-1定义的条款:
a) 应用程序实体
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)
3.6 DICOM服务类规范定义
这个部分的标准使用了DICOM的部分4定义的下面的条款:
a)现实世界的行动
b) 服务类
c) 服务类用户(SCU)
d) 服务类提供者(SCP)
e) 服务对象成对(SOP)类
f)变换SOP类
3.7 DICOM数据结构和编码定义
这个部分的标准使用了DICOM的部分5定义的下面的条款:
a) DICOM定义的UID
b) 私有定义的UID
c)传送语法(标准的和私有的)
d).唯一的标志符(UID)
3.8 DICOM消息交换定义
这个部分的标准使用了DICOM的部分7定义的下面的条款:
a)扩展协商
b)实现类UID
3.9 DICOM上层服务定义
这个部分的标准使用了DICOM的部分8定义的下面的条款:
a)唯一的标识符
b)DICOM高层服务
c)介绍地址
3.10 DICOM遵从性
DICOM标准的这个部分使用了下面的定义:
3.10.1 :  遵从性声明:一个与DICOM标准的特定实现相关联的正式声明。它指定了服务类,信息对象和实现支持的通讯协议。
3.10.2SOP类的标准:一个定义在DICOM标准中的SOP类,未作修改的用于实现中。
3.10.3标准扩展的SOP类:在实现中扩展,具有附加的类型3属性,定义在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类利用一个私有定义的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私有SOP类:  一个SOP类,在DICOM标准中没有定义,而发布在一个实现的遵从性声明中。
注意:因为一个私有的SOP类不在DICO定义M标准中,其他的DICOM实现可以不认识私有的SOP类。因为这个限制。一个私有的SOP类只在一个标准 或标准扩展的SOP类不合适时才被使用。为了不同的实现在私有的SOP类中交换IODs,实现必须就UID,内容(特别地,类型1,1C,2,,2C属 性),和私有SOP类的语义学达成一致。一个私有的SOP类可以用来创建一个全新的或实验用的SOP类。一个实现发行一个私有SOP类,是希望其他的实现 可以使用这个类。
3.10.6 标准属性:  .一个定义在部分6的数据字典中定义的属性。
3.10.7 私有属性:  .一个没有定义在DICOM标准内定义的属性。
 

4 符号和缩写
下面的符号和缩写用在标准的这个部分。
ACR American College of Radiology 美国放射学学会
ACSE Associated Control Service Element联合控制服务元素
API Application Programming Interface应用程序编程接口
ASCII American National Standards Institute美国信息交换标准码
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消息服务元素
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 7
IE Information Entity 信息实体
IEEE Institute of Electrical and Electronics Engineers 电气和电子工程师协会
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 Association 国家电气制造商协会
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 传输控制协议/互连网协议
UID Unique Identifier 唯一的标识符
 

5约定
5.1 应用程序数据流图表
在一个遵从性声明中,真实世界活动与应用程序实体之间的关系由应用程序数据流图表阐明。
5.1.1 应用程序实体
一个应用程序实体被描述为一个在方框内的应用程序数据流图,如图5.1.1所示。
Figure 5.1.1 — Application Entity Convention
 
5.1.2现实世界活动
一个现实世界活动被描述为一个在圆内的应用程序数据流图,如图5.1.2所示。
Figure 5.1.2 — Real-World Activity Convention
 
. 代表多个真实世界行为的圆可以重叠,表明了真实世界行为中的重叠度。
5.1.3 本地关系
本地真实世界行为和应用程序之间的关系被描述在应用程序数据流图内,本地真实世界行为放置到相关应用程序实体的左边,并在他们中间放入一个双箭头。
Figure 5.1.3 — Local Relationship Convention
 
一个应用程序实体可以与多个现实世界活动关联。
.一个现实世界活动可以与多个应用程序实体关联。
5.1.4关联
支持远程现实世界活动的本地应用实体与远程应用实体之间的关联被描述在这样一个数据流图内,把远程现实世界活动放到相关的本地应用程序实体的右边,在他们 之间画入一个或两个箭头,如图5.1.4所示。破折线代表本地应用实体,与任何处理远程真实世界行为的远程应用程序之间的DICOM 标准接口。从本地应 用实体到远程现实世界活动的箭头指出本地现实世界活动的一个事件将引起本地应用实体初始化一个关联,目的是引起远程真实世界行为的发生。从远程现实世界活 动到本地应用实体的箭头指出,当远程现实世界活动发生时,本地应用程序实体期望收到一个关联请求,引起本地应用实体执行本地真实世界行为。
Figure 5.1.4 — Associations Convention
 
 

6 遵从性声明的目的
DICOM标准包含许多可选的组件。一次执行可以从下面选择:
- 通讯方式的几个选择(也就是,OSI,TCP/IP,DICOM 点对点,存储介质互换,等等);
- 编码信息对象的传输语法的几种选择;
- 几个SOP类(信息对象定义和相关服务的组合),他们中的许多是为特定的任务或特殊形式设计的。
- 在IODs内,几个可选的(类型3)属性(一次执行可以选择使用或忽略它们)。
一次执行不需要采用DICOM标准的所有可选组件。在复合了最小的常规要求后,一个完整的DICOM执行可以利用完成这项设计任务所需要的任何S OP类,通讯协议,可选(类型3)属性,等等,。
注意:实际上,希望一次执行只支持与它的现实世界活动相关的SOP类。例如,一个简单的胶片数字转换器可以不支持其他成像模式的SOP类,因为可以不要求 有这样的支持。另一方面,为了充分执行存储服务器的功能,可以要求一个复杂的存储服务器支持多形式的SOP类。一次执行选择DICOM标准的哪一个组件加 以利用,很大程度上依赖于原有的应用程序并超出这个标准的范围。
另外,DICOM标准允许一个实现扩展或专用化DICOM定义的SOP类,也允许定义私有SOP类。
遵从性声明允许用户决定一次执行支持DICOM标准的那些可选组件,并增加什么额外的扩展或特殊化的一次执行。通过比较两次不同执行的遵从性声明,一个有见识的用户应该能够决定是否和什么扩展通讯应该在两个实现之间被支持。
一个遵从性声明有下面的主要部分组成:
- 一次执行模式,它描述执行中的应用程序实体,以及本地、远程真实世界行为之间如何发生关系。
- 每一个应用程序实体的更加详细的说明(或规范),它列出了支持的SOP类并且概括了用来初始化或接受关联的策略。
- 对于每一个应用程序实体和真实世界行为的组合,被提议的(对关联的初始化)和可接受的(对关联的接受)表述关系的描述。
注意:一个表述关系由一个抽象语法加一个可接受的传输语法列表组成。抽象语法识别一个SOP类或变换SOP类(由单一的抽象语法UID识别的相关的SOP 类的集合)。通过列出应用实体带有他们的被建议的和可接受的表述关系,遵从性声明识别执行所验证的信息对象和服务类的集合。
- 对每一个与抽象语法相关的SOP类,任何支持SOP选项的列表。
- 一组本次执行支持的通讯协议的集合。
- 本次执行内的任何扩展,特殊化和公开暴露的私有化的描述。
- 描述DICOM相关配置细节的部分。
- .任何实现细节的描述,这些细节可以与DICOM遵从性或互操作性相关。
 

7遵从性要求
声明DICOM遵从性的实现将:
- 遵照在这个部分定义的最小的遵从性要求。
- 提供实现依照这部分包括附录A中的规则和策略构造的遵从性声明
- 遵照至少一个定义在部分4中标准的或标准扩展的SOP类。
注意: 与标准的或标准扩展SOP类的一致,意味与在部分3中描述的相关IOD、在部分6定义的数据元素和在部分7定义的操作和通知保持一致。
- 遵从在章节7.1中概括的管理SOP类类型的规则。
- 如果执行接受任何的DICOM联合请求,就把一个验证SOP类的表述关系接受为一个SCP,。
- 产生和/或处理在部分5中定义的数据集合。
注意: 与部分5一致也意味着与部分6一致。
- 如果一次执行利用私有定义的UIDs(也就是,UIDs没有定义在DICOM标准内),获得合法的创建UIDs(见第五部分)的注册过的权利。
- 支持一个或更多的下面的通讯模式:
a)部分8 TCP/IP
b)部分8 OSI
c)部分9 点对点
d)部分10,部分11,部分12存储介质互换。
注意:部分10,11,和12定义了存储在物理介质上的DICOM信息对象的通讯。这三个部分上的工作正在进行。作为一个结果,部分2可以需要扩展为清楚地说明DICOM介质存储实现的遵从性。
7.1管理SOP类的类型的规则
发表在遵从性声明的每一个SOP类不是四个基本类型之一。在声明与DICOM标准一致的实现中的每一个SOP应该根据下面的规则处理,由SOP类的类型支配。
标准SOP类遵从所有的DICOM的相关部分,没有增加或改变。
为了声明遵从标准SOP类,一次执行必须在它的遵从性声明中对这个事实做出声明,并且识别它选择的选项,角色,和行为。
l标准扩展的SOP类将:
a) 是一个标准SOP类的适当超集;
b) 不改变标准SOP类的任何标准属性的语义学;
c) 不包含任何私有类型1,1C,2,2C属性;
d) 不把任何标准类型3属性改变为类型1,1C,2,2C的;
e) 使用相同的UID作为它所基于的标准SOP类.
只要遵从性声明识别附加的属性和定义了他们与部分3信息模式之间的关系,一个标准扩展SOP类可以包括标准和/或私有类型3属性,超过了那些定义在IOD内的属性。  
.声明遵从标准扩展SOP类的实现,必须识别在遵从性声明内被扩展的标准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属性,它可以或不可以在遵从性声明中发表。  
注意: 任何未发表的属性的使用可以被其他的用户和特殊SOP类的提供这所忽略。
声明遵从特殊SOP类的实现应包含在它的遵从性声明中被特殊化的标准SOP类的身份,对所有在特殊化SOP类中标准的和私有的类型1,1C,2,和2C属性用法的描述,以及联合私有定义的UIDs。.
私有SOP类应:
a) 遵从DICOM标准的相关部分,不要求支持DICOM默认传输语法的部分可以除外;
b) 不改变任何标准属性的部分6的说明;
c) 使用一个私有定义的UIDs(也就是,不应认为与DICOM定义的UID一致。)
d) 不改变存在的DIMSE服务或创建新的服务。
 
私有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。
注意:为了允许一个实现支持在DICOM应用程序前后关系中的其他抽象语法,未发表的SOP类(也就是,SOP类不被定义在DICOM标准中,并不被定义 在遵从性声明中)是许可的。这样的未发表的SOP类将利用私有定义的UIDs。一个未发表SOP类的出现不妨碍实现DICOM遵从性,但将对与其他的实现 是无意义的,并且可以被忽略。
 

附录A(规范化)DICOM遵从性声明模板

A.0介绍
这个附录是一个模板,它用来产生一个DICOM遵从性声明。一个DICOM遵从性声明应该由一个建立框架的介绍开始。介绍应描述实现,和在大多数情况下,它如何使用DICOM来完成它的目的。
注意: 在这个文档中用来编号段落的编号表将用做一个遵从性声明的提纲准备的指导。遵从性声明不要求有精确的相同的段落号。实际上,任何特殊的遵从性声明将有特殊的考虑,这些考虑要引起提纲的某些细节与这个文档的要点不同。
A.1 实现模式
在介绍之后,遵从性声明的第一个部分是对实现模型的描述。实现模型由一个应用程序数据流图、应用程序实体的功能定义和他们相关的现实世界活动组成,如果可以,还有现实世界活动的排序描述。
A.1.1应用程序数据流图
作为实现模式的一部分,一个应用程序数据流图应该包括进来。这个图代表了所有的出现在实现中的应用程序实体 ,并且图形化的描述了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也显示出在一些真实世界活动中有一 定程度地重叠。任何这样的重叠将在这里讨论。
 
Figure A.1.1-1. Implementation Model
 

A.1.2 AE的功能定义
.实现模型的下一个部分应包含有每一个本地应用程序实体的功能定义。这将描述大多数情况下由AE执行的功能和用来完成这些功能的DICOM服务。在这种意义下,“DICOM服务”不只是面向DICOM服务类,也是面向低层DICOM服务,如关联服务。
A.1.3现实世界活动的排序
如果可行,这个部分应包含AE需要的现实世界活动的排序描述。
注意: 一个需要这样描述的情况的例子是一个AE,这个AE支持存储服务类的SOP和检查内容通知服务类的SOP。一些实现将需要在检查内容通知发送之前存储图象,一些在这之后,一些可以对这样的排序很迟钝。
A.2AE说明
DICOM遵从性声明的下一部分是应用程序实体说明的集合。那里应有一个这样的每个应用程序实体类型的说明。
A.2.x AEx-说明
每一个单独的AE说明有一个子部分,A.2.x。那些子部分和执行中不同的AE是同样多的。就是说,如果有两个不同的AE’s,就有两个子部分,A.2.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关联数目
一个应用程序实体可以支持的同时关联的数目应该被指定。任何控制同时的关联的规则应在这里定义。
注意: 例如一个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.x.2应由声明这个事实的单独的句子组成,没有子段。否则,段A.2.x.2应包含每种现实世界活动的情况——它将引起一个关联开始——的子段A.2.x.2.i。
 
A.2.x.2.i现实世界活动i
A.2.x.2.i.1关联的现实世界活动
子段A.2.x.2.i.1应描述引起AE开始DICOM关联的现实世界活动的部分。  
A.2.x.2.i.2被提议的陈述关系
每一次一个关联开始,联合发起人建议许多陈述关系用在那个关联上。在这个子段中,由应用程序实体为现实世界行为建议的陈述关系应定义在使用以下格式的一个表中。
Table A.2.x.2.i.2-1 Proposed Presentation Contexts for Application Entity  and Real-World- Activity 

Presentation Context Table
Abstract Syntax Transfer Syntax Role Extended
Name UID Name List UID Negotiation
name_a AS_UID_a XS_Name_1, _, XS_Name_n XS_UID_1, _, XS_UID_n  SCP | SCU | BOTH None |See NOTE | See table A.2.x.2.i.2-j
_ _ _ _ _ _
注意: 描述为这个陈述关系的SOP类所做的任何扩展磋商的内容。就像一个单一的抽象语法常常对应于一个单独的可以出现在不同的陈述关系的SOP类,一个NOTE可以服务于多个陈述关系。
在图A.2.x.2.i.2中,下面的意义分配给这些字段:
这个是与陈述关系一起使用的抽象语法的名字。
这个是用于陈述关系的抽象语法的UID。
这个是用于陈述关系的传送语法的名字。
对应的传送语法的UID。
在这个事件中,陈述关系的抽象语法代表了一个变换SOP类(那就是,它包含很多的SOP类),并且扩展磋商支持这些SOP类中的一些,定义这个扩展的磋商下面的表示必须的。这个表在表A.2.x.2.i.2-1中:

SOP Class name SOP Class UID Extended Negotiation
Name_i  SOP_UID_i None | See NOTE
_ _ _
注意: 描述了任何为这个SOP类所做的磋商的内容。就像一个以不同陈述关系出现的SOP类和/或变换的SOP类,一个NOTE可以服务于多个陈述关系。
A.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
段的标题应反映关联被接受的情况。这个段应包含一个这种情况的概要描述。
A.2.x.3.i.1关联的现实世界活动
这个段应包含一个与这个关联联合的现实世界活动的描述。
A.2.x.3.i.2陈述关系的表
表A.2.x.3.i.2-1应用程序实体和现实世界活动的 可接受的陈述关系

Presentation Context Table
Abstract Syntax Transfer Syntax Role Extended
Name UID Name UID Negotiation
name_a AS_UID_a XS_Name_a XS_UID_a SCP|SCU|Both None |See NOTE | See table A.2.x.3.i.2-j
name_b AS_UID_b _ _ _ _
注意:描述了任何为这个陈述关系的SOP类所做的扩展磋商的内容。就像一个单一的抽象语法常常相当于一个单独的可以不同陈述关系出现的SOP类一样,一个注释可以服务于多个陈述关系中。
在表A.2.x.3.i.2中,下面的意义分配给这些字段:
这个是与陈述关系一起使用的抽象语法的名字。
这个是用于陈述关系的抽象语法的UID。
这个是用于陈述关系的传送语法的名字。
对应的传送语法的UID。
在这个事件中,陈述关系的抽象语法代表了一个变换SOP类(那就是,它包含很多的SOP类),并且扩展磋商支持这些SOP类中的一些,定义这个扩展的磋商,下面的表是必须的。这个表在表A.2.x.3.i.2-1中。

SOP Class name SOP Class UID Extended Negotiation
Name_i SOP_UID_i None | See NOTE
_ _ _
注意: 描述了任何为这个SOP类所做的磋商的内容。作为一个可以出现在不同的介绍上下文的SOP类和/或变换的SOP类,一个NOTE可以服务与多个介绍上下文。
A.2.x.3.i.2.j SOP类j的SOP特殊遵从性
这里是每一个特殊的SOP类j(对应于现实世界事件i,通过AEx)的SOP特定的遵从性。这个声明应于在部分4(或相关的私有SOP定义)的SOP特定遵从性声明描述的一样。.它应包括任何扩展磋商的内容。
A.2.x.3.i.3陈述内容接受标准
任何管理这个AE的陈述内容接受的规则应在这里声明。这包括抽象/传送语法的组合可接受的规则,和陈述内容优化的规则。
A.2.x.3.i.4传送语法选择策略
陈述关系内管理传送语法的规则应在这里声明。
A.3通讯轮廓
A.3.1支持的通讯栈(部分8,9)
A.3.x OSI栈
.如果OSI通讯栈被支持,那么这个段应包含一个ISO轮廓的遵从性的描述。
A.3.x.1国际标准轮廓(ISP)
这个段声明了被支持的ISP’s.
注意: 这个“轮廓”的概念由ISO TR 10000定义,称为一个ISO国际标准化轮廓或ISP。这个相同的概念由CEN和欧洲开放系统工作组(EWOS)定 义为一个“功能标准”。在美国,国家标准和技术机构主持一个OSI实现者工作组,这个工作组定义了诸如“实现者协定”轮廓。这个轮廓用为政府采购轮廓(如 US或UK GOSIP)或工业采购轮廓(如MAP或TOP)。
A.3.x.y API应用程序接口
如果可行,这个段应声明到用于这个实现的OSI栈的应用编程接口。如果这个执行是一个打算集成到不同环境中得软件包才是可行的。
A.3.x.z物理介质支持
如果可行,这个段描述了支持的物理介质。
A.3.x TCP/IP栈
A.3.x.y API应用程序接口
如果可以,这个段应声明到用于这个实现的TICP/IP栈的应用程序编程接口(如Berkeley栈,XLI,TLI)。如果这个执行是一个打算集成到不同环境中得软件包才是可行的。
A.3.x.z 物理介质支持
如果可应用,这个段描述了由TCP/IP栈支持的物理介质。
A.3.x点对点栈
.如果支持点对点接口,在这里声明。
A.4扩充/特殊化/私有化
A.4.1标准的扩展/特殊化/私有SOPs
这个段描述了标准扩展SOP类、特殊化SOP类,或使用的私有SOP类。它应遵循DICOM标准的部分4中说明的准则。
A.4.1.i标准的扩展/特殊化/私有SOP i
这个段描述了一个特殊的标准扩展SOP类、特殊化SOP类,或私有的SOP类。它应遵循DICOM标准的部分4中说明的准则。
A.4.2私有传送语法
这个部分描述了任何在表A.2.x.2.i.2或A.2.x.3.i.2中列出的私有传送语法。
A.4.2.i私有传送语法i
这个部分描述了一个特殊的私有传送语法。它应遵循DICOM标准的部分5中说明的准则。
A.5配置
任何实现的DICOM遵从性可以依赖于每次安装的配置。有关配置的内容应在这个部分写出。
A.5.1AE标题/陈述地址映射
最重要安装内容之一是从AE标题到陈述地址的转换。如何这样做应在这个部分内描述出来。
A.5.2可配置参数
其他重要的内容是某一个操作参数的说明,它可以基于配置信息。他们包括下面的:
- 同时发生的关联的数目
- 最大的PDU尺寸
- 超时
任何可以影响遵从性和基于配置的操作参数应在这里描述出来。
A.6扩展字符集合的支持
任何扩展字符集合的支持应在这里描述。
 

附录B(提供消息的)DICOM遵从性声明例子
B.0介绍
这个附录是假想的DICOM实现的DICOM遵从性声明的例子。它只代表一个例子。这样一个实现的生存能力不会被假定为这个附录的目的,只是通过提供一个遵从性声明的例子来引导DICOM遵从性声明的写作者。
B.1 实现模式
为这个例子选择的应用程序是使用DICOM存储服务类的简单的图像传送。介绍的应用程序使用一个简单的UNIX命令行接口完成了图像的移动。
B.1.1  应用数据流图
DIS(DICOM图像存储)和DAT(DICOM自动传输)是用于DICOM图像传输的UNIX应用程序。DIS通过键入“dis”命令调用。“dis”命令用来存储一个图像(它必须包含在本地文件中)到一个远程系统中。“dis”命令的格式如下:
dis [-v] [-d] [-p]  
< destination >指定了C-STORE操作的目标的应用程序实体标题。指定了要发送文件的列表。"-v"选项规定文件在存储前要验证合法性,"-d" 选项指定文件以目标首选的格式传送(也就是,陈述关系的集合将被构造来允许目标只选择它的“首选”传送语法)。"-p"选项指出文件在成功地传送后将被删除。
使用“dat”命令引用DAT。"dat"命令有如下的格式:
dat [-v] 
DAT是一个后台程序;它将从终端分离它自己,并继续运行直到被杀死。"-v"选项指定被校验的文件格式。
Figure B.1.1-1. DIS and DAT Implementation Model
 
B.1.2 AEs的功能定义
当DIS被调用。它将搜索它的文件列表中的所有文件。它期望这些文件以DICOM标准部分10指定的文件格式存在。对于每一个文件列表中的文件,DIS决 定来自这些文件头的适当的陈述关系和为传送这个图像到目的文件而提出合适的关联。它在标准输出上写入文件名和文件传送的完成状态。
DAT等待另一个应用程序连接在为它的应用程序实体标题配置的陈述地址。当其他的应用程序连接时,DAT期望它是一个DICOM应用程序。DAT将接受这 个存储服务类的SOP类的带有陈述关系的关联。它将在这些陈述关系上接受图像,并把他们写到文件,这个文件以在DICOM标准的部分10中描述的格式存 放。为了调用UNIX命令成功地接收图像,必须配置它
B.1.3现实世界活动的排序
不可用。
B.2 AE说明
因为DIS只初始化关联而且DAT只接受关联,所以DIS应用程序和DAT后台程序可以配置为扮演不同角色的应用程序实体,或一个单独的应用程序实体。为 了简单化这个描述,它们被描述为一个单独的应用程序实体。因为每一个DIS和DAT的操作参数(包括AE标题)是来自/etc/dicom目录的配置文 件,尽管DIS的多个实例(每一个代表相同的应用程序实体)可以同时运行。DAT将为每一个新的连接产生一个新的拷贝,每一个代表了相同的应用程序实体。
B.2.1 DIS和DAT说明
DIS和DAT为以下DICOM V3.0 SOP类作为SCU和SCP提供了的标准遵从性。

SOP Class Name SOP Class UID
Computed Radiography Image Information Object计算射线照相术图象信息对象 1.2.840.10008.5.1.4.1.1.1
CT Image Information ObjectCT图象信息对象 1.2.840.10008.5.1.4.1.1.2
MR Image Information ObjectMR图象信息对象 1.2.840.10008.5.1.4.1.1.4
Nuclear Medicine Image  Information Object核医学图象信息对象 1.2.840.10008.5.1.4.1.1.5
Ultrasound Image Information Object超声图象信息对象 1.2.840.10008.5.1.4.1.1.6
Secondary Capture Image Information Object继发捕获图象信息对象 1.2.840.10008.5.1.4.1.1.7
B.2.1.1 关联制定策略
B.2.1.1.1常规
每当带有合法参数调用时(包括一个已知的目标和合法的DICOM格式文件),DIS将试图建立一个关联。如果它决定文件具有合法的组 0002 头,并且 制定在文件头中的抽象语法和传送语法是合法的,它将尝试建立一个关联。如果指定“-v”选项,那么DIS将为SOP类验证文件的内容是否违背IOD。
DIS将使用的PDU尺寸的最大值是可配置的,最小2K。
B.2.1.1.2 关联的数目
DIS一次只尝试建立一个关联。然而多个DIS的拷贝可以同时引用。在多个DIS的拷贝间没有同步尝试,这样DIS AE可以尝试大量的同时发生的关联,只受它运行的计算机系统资源,及DIS外部政策的限制,这个策略在可能同时调用的次数上加了限制。
DAT接受的同时发生关联的数目只受下面的TCP/IP实现的核心参数限制。因此DAT可以有多个同时连接,DAT将为每一个请求它接收的连接产生一个新的进程,并且在DIS和DAT代表的应用程序实体可保持的同时发生的关联总数上没有限制。
B.2.1.1.3  异步性能
DIS将只在一个关联上发送一个单独的图象。DAT将根据一个关联允许一个单独的显著的操作。因此,无论DIS或DAT将执行异步操作窗口磋商。
B.2.1.1.4 实现识别信息
DIS和DAT将提供一个单独的实现类UID,它是“1.840.xxxxxxx.yyy.etc.ad.inf.usw”。DIS将提供一个实现版本名“DIS v1.0”并且DAT将提供一个实现版本名“DAT v1.0”。
B.2.1.2 关联开始策略
DIS尝试为每一个它尝试传送的文件初始化一个新的关联。有三种这样的现实世界活动(图象传送)的情况要考虑:
1) 图象用Implicit VR编码,
2) 图象用Explicit VR编码,并指定了"-d"选项,
3) 图象用Explicit VR编码,没有指定了"-d"选项。
B.2.1.2.1用Implicit VR编码的图像的传送
B.2.1.2.1.1关联的现实世界的活动
相关的现实世界的活动就是传送一个用implicit VR编码的文件的尝试。DIS不能转换文件到任何其他的传送语法。因此它只提供单一的为了传送文件的传送语法。
B.2.1.2.1.2被提议的陈述关系
在这种情况下,DIS将只建议一个单独的陈述关系,就象在表B.2.1.2.1.2-1中显示的。这个陈述关系将使用在文件头指定的SOP类UID作为建 议的抽象语法和在文件(在这个情况下是“DICOM Implicit VR “)头中指定的传送语法作为建议传送语法。
 
Table B.2.1.2.1.2-1 Proposed Presentation Contexts for DIS, file encoded with Implicit VR

Presentation Context Table
Abstract Syntax Transfer Syntax Role Extended
Name UID Name List UID List Negotiation
See Note See Note DICOM Implicit VR Little Endian Transfer Syntax 1.2.840.10008.1.2  SCU None 
注意:抽象语法于在要传送的图像文件头中指定的SOP类UID一致。
B.2.1.2.2用Explicit VR编码并带有"-d"选项的图像的传送
B.2.1.2.2.1相关的真实世界活动
关联的现实世界活动是一个用“explicit VR”编码,带有“-d”选项的文件传送请求。DIS能够转换一个文件到任何其他的本地传送语法。因为指定了“-d”选项,那么它将建议在单独陈述关系内所有的这些传送语法,允许目标选择首选的传送语法。
B.2.1.2.2.2被提议的陈述关系
在这种情况下,DIS将只建议一个单独的陈述内容,就象表B.2.1.2.1.2-1内所示。这个陈述关系将使用在文件头中指定的SOP类UID作为建议抽象语法,并且在DICOM标准部分5中指定的所有本地传送语法作为建议传送语法。

Table B.2.1.2.2.2-1 Proposed Presentation Contexts for DIS, file encoded with Explicit VR, with "-d" Option Specified

Presentation Context Table
Abstract Syntax Transfer Syntax Role Extended
Name UID Name List UID List Negotiation
See Note See Note DICOM Implicit VR Little Endian Transfer Syntax,DICOM Explicit VR Big Endian Transfer Syntax,DICOM Explicit VR Little Endian Transfer Syntax 1.2.840.10008.1.21.2.840.10008.1.2.2.1.2.840.10008.1.2.1  SCU None 
注意: 抽象语法与要传送的图象文件头中指定的SOP类UID一致。
B.2.1.2.3用Explicit VR编码,指定“-d”选项的图像传送。
B.2.1.2.3.1相关的真实世界活动
 相关的真实世界活动是一个用“explicit VR”编码,带有“-d”选项的文件传送请求。DIS能够转换一个文件到任何其他的本地传送语法。因为 没有指定了“-d”选项,那么它将建议这些传送语法存在于三个不同的陈述关系中。DIS希望目标文件接受所有的可能支持的陈述关系,这样,图象(如果两个 AE’s支持多于一个)传送的传送语法的选择留给了DIS。
B.2.1.2.3.2被提议的陈述关系
在这种情况下,DIS将只建议三个陈述关系,就象在表B.2.1.2.3.2-1所示。这些陈述关系将使用在文件头中指定的SOP类UID作为建议抽象语法,并且在DICOM标准部分5中指定的所有本地传送语法的列表作为建议传送语法。
Table B.2.1.2.3.2-1 Proposed Presentation Contexts for DIS, File Encoded with Explicit VR, with "-d" Option Not Specified

Presentation Context Table
Abstract Syntax Transfer Syntax Role Extended
Name UID Name List UID List Negotiation
See Note See Note DICOM Implicit VR Little Endian Transfer Syntax 1.2.840.10008.1.2  SCU None 
See Note See Note DICOM Explicit VR Big Endian Transfer Syntax 1.2.840.10008.1.2.2 SCU None
See Note See Note DICOM Explicit VR Little Endian Transfer Syntax 1.2.840.10008.1.2.1 SCU None
注意: 抽象语法与在要传送的图象文件头中指定的SOP类UID一致。
B.2.1.2.4 SOP特殊遵从性
如果DIS不能为一个文件决定合适的抽象和传送语法,或者抽象和传送语法不被DIS所支持,或者“-v”选项被指定并且图象没有为SOP类的IOD请求满足,DIS将在标准输出上打印下面格式的一行:

相关文章推荐

Dicom3.0标准中文版

  • 2013年07月31日 12:46
  • 1.54MB
  • 下载

医学数字成像(DICOM)中文版

  • 2008年09月15日 15:41
  • 1.62MB
  • 下载

C++ Primer中文版(第五版)--第二章 变量和基本类型

数据类型是程序的基础,它告诉我们数据的意义以及我们能在数据上执行的操作      C++定义了几种基本内置类型:字符、整型、浮点数等,同时程序员可以自定义数据类型,另外C++ 标准库还定义了一些...

DICOM标准中文版

  • 2008年11月13日 17:28
  • 1.36MB
  • 下载

dicom中文版标准

  • 2011年05月26日 11:54
  • 1.35MB
  • 下载

Java Persistence with MyBatis 3(中文版) 第二章 引导MyBatis

MyBatis最关键的组成部分是SqlSessionFactory,我们可以从中获取SqlSession,并执行映射的SQL语句。SqlSessionFactory对象可以通过基于XML的配置信息或者...

DICOM标准中文版

  • 2007年07月16日 12:15
  • 1.33MB
  • 下载

DICOM 标准 3.0 中文版

  • 2012年02月17日 16:07
  • 1.36MB
  • 下载

CakePHP 2.x CookBook 中文版 第二章 安装

安装 CakePHP 很容易安装。最小安装只要有一个 web 服务器和一份 Cake 的副本,就足够了!本手册主要聚焦于在 Apache 上安装 Cake(因为 Apache 最通用), 你也可...

《数据挖掘概念与技术》第二版 中文版 第二章答案

《数据挖掘概念与技术》第二版 中文版 第一章答案这是我自己整理的手写版,在此上传图片,供大家参考以及欢迎大家指正。...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:DICOM中文版第二章
举报原因:
原因补充:

(最多只允许输入30个字)