cpart02.docx
《cpart02.docx》由会员分享，可在线阅读，更多相关《cpart02.docx（36页珍藏版）》请在冰豆网上搜索。
cpart02
最终文件--部分2
医学数字成像和通讯（DICOM）
部分2:
遵从性
状态：
最终文件-1993年10月29日
这是一个草稿-不经NEMA的同意，不得传播，引用或复制。
目录
SectionPage
前言1
1应用范围和领域2
2标准的参考2
3定义3
3.1参考模式定义3
3.2服务定义3
3.3介绍服务定义3
3.4DICOM介绍和概述定义3
3.5DICOM信息对象定义3
3.6DICOM服务类规格定义4
3.7DICOM数据结构和编码定义4
3.8DICOM消息交换定义4
3.9DICOM上层服务定义4
3.10DICOM遵从性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.2AE的功能定义16
A.1.3真实世界行为的排序16
A.2AE说明16
A.2.xAEx-说明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真实世界行为i18
A.2.x.2.i.1有关的真实世界行为18
A.2.x.2.i.2被提议的内容说明18
A.2.x.2.i.2.jSOP类j的SOP特殊遵从性声明19
A.2.x.3关联接受策略19
A.2.x.3.i真实世界行为i19
A.2.x.3.i.1关联的真实世界行为19
A.2.x.3.i.2介绍上下文表19
A.2.x.3.i.2.jSOP类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.xOSI栈20
A.3.x.1国际标准轮廓（ISP）20
A.3.x.yAPI应用程序接口20
A.3.x.z物理介质支持20
A.3.xTCP/IP栈21
A.3.x.yAPI应用程序接口21
A.3.x.z物理介质支持21
A.3.x点对点栈21
A.4扩充/特殊化/私有化21
A.4.1标准的扩展/特殊化/私有SOPs21
A.4.1.i标准的扩展/特殊化/私有SOPi21
A.4.2私有传送语法21
A.4.2.i私有传送语法i21
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.2AEs的功能定义24
B.1.3真实世界行为的排序24
B.2说明24
B.2.1DIS和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用ImplicitVR编码的图象的传送26
B.2.1.2.1.1关联的真实世界行为26
B.2.1.2.1.2被提议的内容说明26
B.2.1.2.2用ExplicitVR编码并带有"-d"选项的图象的传送27
B.2.1.2.2.1关联的真实世界行为27
B.2.1.2.2.2被提议的内容说明27
B.2.1.2.3用ExplicitVR编码，指定“-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.3SOP特定遵从性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.2TCP/IP栈32
B.3.2.1物理介质支持32
B.4扩展/特殊化/私有化32
B.5.0配置33
B.5.1AE标题/介绍地址映射33
B.5.2配置参数33
B.5.2.1DIS配置33
B.5.2.2DAT配置33
B.6扩展字符集合的支持34
前言
ACR（美国放射学学会）和NAMA（国家电气制造商协会）组成了一个联合委员会来开发一个医学数字成像和通讯的标准。
这个DICOM标准的开发符合NEMA的程序。
这个标准的开发得到了诸如欧洲的CENTC251和日本的JIRA等标准组织的支持，并由其他组织复审，这些组织包括IEEE、HL7和USA的ANSI。
DDICOM标准是按照下面的文档制订的方针构建的一个多部分的文档。
-ISO/IEC指令，1989第三部分–国际标准的起草和介绍。
这个文档是DICOM标准的一部分，包括以下内容：
第一部分-介绍和概述
第二部分：
遵从性
第三部分：
信息对象定义
第四部分：
服务类说明
第五部分-数据结构和语义学
第六部分-数据字典
第七部分-消息交换
第八部分-消息交换的网络通讯支持
第九部分-消息交换的点对点通讯支持
这些部分是相关的而又独立的文档。
他们的开发水平和认可状态可以不同。
补充部分可以加到这个多部分的标准中。
部分1应该作为标准的当前部分的基本参考。
1应用范围和领域
DICOM标准的部分2定义了执行声明的遵循性的标准要遵循的原则。
部分2指定了：
-最小的通用遵从性要求，任何执行声明的遵从性的DICOM标准必须满足它。
在DICOM标准其他章节中的遵从性部分可以找到对特殊特性、服务类、信息对象和通讯协议的附加遵从性要求。
-部分2—遵从性声明的目的和结构提供了一个框架。
通过它，遵从性信息可以放入到遵从性声明中，由标准其他部分的遵从性部分规定。
DICOM标准没有指定：
-评定实现对标准遵从性的测试或验证过程。
-评定一个执行过程是否匹配它的遵从性声明的测试或验证过程。
-什么样的可选的特性，服务类，或信息对象应该被一个给定类型的设备所支持。
2标准的参考
下面的标准包含了组成标准贯穿本文的参考的必须部分。
在出版的时候，所示的版本是合法的。
所有的标准服从于修订版本，并且基于这个标准的协议的当事人被鼓励来调查在下面列出的标准的最近版本的应用可能性。
ISO/IEC指导，1989年部分3–国际标准的起草和介绍
ISO7498-1信息处理系统–开放系统互连–基本参考模式
ISO8649:
1988信息处理系统–开放系统互连–联合控制服务元素（ACSE）的服务定义。
ISO8822：
1988信息处理系统–开放系统互连–连接定向介绍服务定义。
3定义
目的是下面定义应用的这个标准。
3.1参考模式定义
这个部分的定义使用下面的ISO7498-1定义的条款：
a）应用程序实体
b）应用程序实体标题
c）协议数据单元
d）.传送语法
3.2ACSE服务定义
这个部分的标准使用了ISO8649定义的下面的条款：
a）联合或应用联合
b）.联合的创始者
3.3介绍服务定义
这个部分的标准使用了ISO8822定义的下面的条款：
a）抽象语法
b）抽象语法名
c）介绍内容
d）传送语法
e）.传送语法名
3.4DICOM介绍和概述定义
这个部分的标准使用了在DICOM的部分1中定义的下面的条款：
a）信息对象
3.5DICOM信息对象定义
这个部分的标准使用了DICOM的部分3定义的下面的条款：
a）信息对象定义（IOD）
3.6DICOM服务类规范定义
这个部分的标准使用了DICOM的部分4定义的下面的条款：
a）现实世界的行动
b）服务类
c）服务类用户（SCU）
d）服务类提供者（SCP）
e）服务对象成对（SOP）类
f）变换SOP类
3.7DICOM数据结构和编码定义
这个部分的标准使用了DICOM的部分5定义的下面的条款：
a）DICOM定义的UID
b）私有定义的UID
c）传送语法（标准的和私有的）
d）.唯一的标志符（UID）
3.8DICOM消息交换定义
这个部分的标准使用了DICOM的部分7定义的下面的条款：
a）扩展协商
b）实现类UID
3.9DICOM上层服务定义
这个部分的标准使用了DICOM的部分8定义的下面的条款：
a）唯一的标识符
b）DICOM高层服务
c）介绍地址
3.10DICOM遵从性
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类中交换IODs以前，实现必须就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符号和缩写
下面的符号和缩写用在标准的这个部分。
ACRAmericanCollegeofRadiology美国放射学学会
ACSEAssociatedControlServiceElement联合控制服务元素
APIApplicationProgrammingInterface应用程序编程接口
ASCIIAmericanNationalStandardsInstitute美国信息交换标准码
AEApplicationEntity应用实体
ANSIAmericanNationalStandardsInstitute美国国家标准协会
CENTC251ComiteEuropeendeNormalisation-TechnicalCommittee251-MedicalInformatics欧洲标准化协会-技术委员会251-医学信息学
DICOMDigitalImagingandCommunicationsinMedicine医学数字成像和通讯
DIMSEDICOMMessageServiceElementDICOM消息服务元素
DIMSE-CDICOMMessageServiceElement-Composite复合DICOM消息服务元素
DIMSE-NDICOMMessageServiceElement-Normalized规格化DICOM消息服务元素
HISPPHealthcareInformationStandardsPlanningPanel医疗信息学标准计划编制小组
HL7HealthLevel7
IEInformationEntity信息实体
IEEEInstituteofElectricalandElectronicsEngineers电气和电子工程师协会
IODInformationObjectDefinition信息对象定义
ISOInternationalStandardsOrganization国际标准组织
ISPInternationalStandardProfile国际标准化轮廓文件
JIRAJapaneseIndustryRadiologyApparatus日本工业放射学仪器
MSDSHealthcareMessageStandardDevelopersSub-Committee医疗消息标准开发者分协会
NEMANationalElectricalManufacturersAssociation国家电气制造商协会
OSIOpenSystemsInterconnection开放系统互连
PDUProtocolDataUnit协议数据单元
SCPServiceClassProvider服务类提供者
SCUServiceClassUser服务类用户
SOPService-ObjectPair服务对象对
TCP/IPTransferControlProtocol/InternetProtocol传输控制协议/互连网协议
UIDUniqueIdentifier唯一的标识符
5约定
5.1应用程序数据流图表
在一个遵从性声明中,真实世界活动与应用程序实体之间的关系由应用程序数据流图表阐明。
5.1.1应用程序实体
一个应用程序实体被描述为一个在方框内的应用程序数据流图，如图5.1.1所示。
Figure5.1.1—ApplicationEntityConvention
5.1.2现实世界活动
一个现实世界活动被描述为一个在圆内的应用程序数据流图，如图5.1.2所示。
Figure5.1.2—Real-WorldActivityConvention
.代表多个真实世界行为的圆可以重叠，表明了真实世界行为中的重叠度。
5.1.3本地关系
本地真实世界行为和应用程序之间的关系被描述在应用程序数据流图内，本地真实世界行为放置到相关应用程序实体的左边，并在他们中间放入一个双箭头。
Figure5.1.3—LocalRelationshipConvention
一个应用程序实体可以与多个现实世界活动关联。
.一个现实世界活动可以与多个应用程序实体关联。
5.1.4关联
支持远程现实世界活动的本地应用实体与远程应用实体之间的关联被描述在这样一个数据流图内，把远程现实世界活动放到相关的本地应用程序实体的右边，在他们之间画入一个或两个箭头，如图5.1.4所示。
破折线代表本地应用实体，与任何处理远程真实世界行为的远程应用程序之间的DICOM标准接口。
从本地应用实体到远程现实世界活动的箭头指出本地现实世界活动的一个事件将引起本地应用实体初始化一个关联，目的是引起远程真实世界行为的发生。
从远程现实世界活动到本地应用实体的箭头指出，当远程现实世界活动发生时，本地应用程序实体期望收到一个关联请求，引起本地应用实体执行本地真实世界行为。
Figure5.1.4—AssociationsConvention
6遵从性声明的目的
DICOM标准包含许多可选的组件。
一次执行可以从下面选择：
-通讯方式的几个选择（也就是，OSI，TCP/IP，DICOM点对点，存储介质互换，等等）；
-编码信息对象的传输语法的几种选择；
-几个SOP类（信息对象定义和相关服务的组合），他们中的许多是为特定的任务或特殊形式设计的。
-在IODs内，几个可选的（类型3）属性（一次执行可以选择使用或忽略它们）。
一次执行不需要采用DICOM标准的所有可选组件。
在复合了最小的常规要求后，一个完整的DICOM执行可以利用完成这项设计任务所需要的任何SOP类，通讯协议，可选（类型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）部分8TCP/IP
b）部分8OSI
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）遵从
升级会员 