DICOM标准之二_兼容性声明

第2部分 兼容性声明

1.应用范围和领域

兼容性声明对于共同操作是至关重要的，因为其为应用者和系统集成者决定系统是否互操作，提供了重要的信息依据。

此外，当问题出现时，它们为强有力解决任何问题提供了信息源。

最后，为有潜力的应用者制作这些文档提供了持久的模板。

3.定义

为了本标准目标，应用以下定义。
3.1 参考模型定义

本部分中使用在ISOtope7498-1中定义的如下类别：

A)  Application Entity 应用实体(AE)

B)  Application Entity Title 应用实体名称

C)  Protocol Data Unit 协议数据单位

D)  Transfer Syntax 交换语法

3.2 ACSE服务定义

A)  Associationor Application Association 关联或应用关联

B)  Association Initiator 关联发起者

3.3 陈述服务定义

本部分中使用在ISO 8822中定义的如下类别：

A)  Abstract Syntax 抽象语法

B)  Abstract Syntax Name 抽象语法名称

C)  Presentation Context 陈述上下文

D)  Transfer Syntax 转换语法

E)  Transfer Syntax Name 转换语法名称

3.4 DICOM介绍和概述定义

本部分中使用了在PS3.1中定义的以下类别：

A  )Information Object 信息对象

3.5 DICOM信息对象定义

本部分中使用了在PS3.3中定义的如下类别：

A)  Information Object Definition(IOD) 信息对象定义

3.6 DICOM服务类详细定义

本部分中使用了在PS3.4中定义的如下类别：

A)  Real-WorldActivity 现实世界活动

B)  ServiceClass 服务类

C)  ServiceClass User(SCU) 服务类客户端

D)  ServiceClass Provider(SCP) 服务类服务端

E)  Service-Object Pair(SOP) Class 服务对象对类

F)  MetaSOP Class 元SOP类

3.7 DICOM数据结构和编码定义

本部分中使用了在PS3.5中定义的如下类别：

A)  DICOM Defined UID DICOM定义的UID

B)  Privately Defined UID 自定义UID

C)  Transfer Sytax:(Standard and Private) 传输语法(标准和自定义)

D)  Unique Identifier(UID) 唯一标志UID

3.8 DICOM信息交换定义

本部分中使用了在PS3.7中定义的如下类别：

A)  Extended Negotiation 扩展的协议

B)  Implementation Class UID 应用类UID

3.9 DICOM上层服务定义

本部分中使用了在PS3.8定义的如下类别：

A)  Unique Identifier(UID) 唯一标志UID

B) DICOMUpper Layger Service DICOM上层服务

C)  Presentation Address 陈述地址

3.10 媒介存储与文件格式对数据交换的支持

本部分中使用了在PS3.10定义的如下类别：

A)  File-set文件集

B)  File-set Creator(FSC) 文件集的创建者

C)  File-set Reader(FSR)文件集读取者

D)  File-set Updater(FSU)文件集更新者 

E)  Application Profile应用规范

3.11 DICOM兼容性

本部分使用如下定义：

3.11.1 兼容性声明

一个正式的声明关联了DICOM标准的一个明确应用。它明确了应用支持的服务类，信息对象，传输协议和媒介存储技术。

3.11.2 标准SOP类

在DICOM标准中定义的一个SOP类在应用中使用时不作任何修改。

3.11.3 标准扩展SOP类

在DICOM标准中定义的一个SOP类在一个应用中使用附加的Type3属性进行扩展。附加属性可以从PS3.6中的数据字典描绘，亦可是私有属性。相关标准SOP类的语法将不会被附加Type3属性改变当缺省时。因此，标准扩展SOP类使用和相关标准SOP类一样的UID。

注意：标准扩展的SOP类中的IOD可以在DICOM应用间交换，因为应用不熟悉Type3属性将会简单地忽略它

3.11.4 专门的SOP类

一个从标准SOP类继承的SOP类，在一个应用通过附加Type1, 1C, 2, 2C 和3属性，属性明确允许值的列举，和明确运行模板列举等进行特殊化。附加属性可以在PS3.6中的数据字典描绘，可以是私有属性。运行属性值或模板的列举，应该是相关标准SOP类允许的子集。由于相关标准SOP类的语法可以被附加属性改变，一个专门SOP类使用一个私有定义UID，而且有别于相关标准SOP类的UID。

注意：1. 由于一个专门化SOP类使用了不同于标准或标准扩展SOP类的UID，其他DICOM应用可能不识别专门化的SOP类。因为这个限制，一个专门化SOP类只在标准或标准扩展SOP类不合适时才使用。在不同应用可以再专门化的SOP类交换实例之前，这些应用必须支持专门化SOP类的UID、内容(特别是附加Type1,1C,2,和2C属性)、和语法。一个专门化SOP类可以用以创建与标准SOP类密切相关的一个新的或实验性SOP类。

2.专门化SOP类的联合连接可以包含一个SOP类的公共扩展连接子集(PS3.7定义的)，使之在服务类和相关通用SOP类的定义中专门化。这可以允许一个接受中的应用，在没有专门化SOP类IOD的优先协议的情况下，运行该类的实例，就如它们是相关通用SOP类的实例。）

3.11.5 私有SOP类

一个SOP类没有在DICOM标准中定义，但在一个应用兼容性声明中公开。

注意：由于一个私有SOP类没有在DICOM标准中定义，其他DICOM应用可能不识别该私有SOP类。因为这个限制，一个私有SOP类应当只在标准或标准扩展SOP类不适用时使用。为了使不同应用在私有SOP类中交换实例，这些应用必须支持私有SOP类的UID、内容(特别是Type1,1C,2和2C属性)、和语法。一个私有SOP类可以用来创建全新或实验性SOP类。

3.11.6 标准属性

在PS3.6的数据字典中定义的属性

3.11.7 私有属性

没有在DICOM标准中定义的属性。

3.11.8 标准应用技术

在DICOM标准定义的应用技术，在一个应用使用时不作任何修改。

3.11.9 增加的应用技术

继承于标准应用技术的应用技术，通过合并对附加标准和标准扩展SOP类的支持。

3.11.10 私有应用技术

没有在DICOM标准中定义的应用技术，但在应用的兼容性声明中公开的。

3.11.11 安全技术

选择DICOM标准的部分中合理选择的集合的机制，伴随符合安全设备支持的安全机制(例如加密算法)。

4 符号和缩写

本部分中使用如下符号和缩写：

ACR  American College of Radiology 美国发射协会

ACSE  Association Control Service Element 联合控制服务元素

AE  Application Entity 应用实体

ANSI  American National Standards Institute 美国国家标准委员会

AP  Application Profile  应用规范

ASCII  American Standard Code for Information Interchange 美国信息交换编码标准

CENTC251  Comite Europeen de Normalisation- Technical Committee 251- MedicalInformatics  欧洲标准协会- 技术分会251 – 医疗信息

DICOM  Digital Imaging andCommunications in Medicine 医学数字医学与传输

DIMSEDICOM  Message Service Element DICOM消息服务元素

DIMSE-C  DICOM Message ServiceElement-Composite DICOM消息服务元素-复合的

DIMSE-N  DICOM Message Service Element-Normalized DICOM消息服务元素-标准化的

FSC  File-set Creator 文件-集 创建者

FSR  File-set Reader 文件-集 读取者

FSU  File-set Updater 文件-集 更新者

HISPP  Healthcare Informatics 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 国际标准组织

MSDS  Healthcare Message Standard Developers Sub-Committee 医护消息标准开发者子协会

NEMA National Electrical ManufacturersAssociation 国家电气生产商协会

OSI  Open Systems Interconnection 开发系统互联

PDU  Protocol Data Unit 协议数据单元

RWA  Real-World Activity 真实世界行为

SCP  Service Class Provider 服务类提供者

SCU  Service Class User 服务类使用者

SOP  Service-Object Pair 服务对象对

TCP/IP  Transmission Control Protocol/Internet Protocol 传输控制协议/因特网协议

UID  Unique Identifier 唯一识别

UML  Unified Modeling Language 统一模型语言

5 约定

5.1应用数据流图

在一个兼容性声明中，真实世界行为和应用实体之间的关系，通过应用数据流图来阐述。

5.1.1 应用实体

一个应用实体在一个应用数据流图中描述为一个盒子，如图5.1-1所示

应用实体约定

5.1.2 真实世界行为

一个真实世界行为在一个应用数据流图中描述为一个圆圈，如图5.1-2所示：

真实世界行为约定

圆圈表达了多重真实世界行为是可以重叠的，象征了在一个真实世界行为中重叠的度。

5.1.3 本地关系

一个真实世界行为和一个应用实体的关系，通过一个应用数据流图来描述，将本地真实世界行为放在应用实体的左边，两者通过虚线来连接，如图5.1-3所示：

本地关系的约定

一个应用实体可以连接多重真实世界行为。一个真实世界行为可以连接多重应用实体。

5.1.4 网络-连接

一个本地应用实体和一个远程应用实体之间的连接，通过网络支持一个远程真实世界行为；在一个应用数据流图中，将远程真实世界行为放到右边，而相关本地应用实体通过一条或多条带箭头的虚线与其连接，如图5.1-4所示。虚线代表了本地应用实体之间的DICOM标准接口，而无论是那种远程应用实体来控制远程真实世界行为。从本地应用实体到远程真实世界行为的箭头象征了本地真实世界行为的出现将引起本地应用实体启动一个连接，达到促使远程真实世界行为出现的目的。从远程真实世界行为到本地应用实体的箭头也象征了本地应用实体将会收到一个连接请求当远程真实世界行为出现时，促使本地应用实体执行本地真实世界行为。

连接约定

5.1.5 介质存储文件-集的访问

应用实体在介质之间交换信息使用如PS3.10中明确的DICOM文件服务，用以访问、创建文件集。该文件服务提供操作，支持3种基础角色，就是文件集创建者(FSC)、文件集读取者(FSR)和文件集更新者(FSU)。

这些角色在应用数据流图中，通过在本地应以实体之间的有方向的箭头和角色应用的DICOM存储介质来描述。

FSC,通过à表示，FSR通过ß表示，FSU通过ßà表示，介质的物理移动通过— — à(箭头可有可无)表示。

图5.1-5阐明了该3种基本角色。

文件集访问

左边的本地真实世界行为和本地应用实体的本地交互通过虚线来描绘。右边的箭头描述了本地应用实体与文件集在DICOM存储介质的访问。当一个应用实体支持多个角色，该结合就描述为多重箭头对每个角色的应答。点状箭头象征了一个交互应用中可移除的自然介质。

注意: 一个FSC和一个FSR关系的两个箭头的使用，应有别于与一个FSU的两个箭头的使用。例如，一个FSU可以更新文件集，而没有创建一个新的文件集，然而FSC和FSR的连接可能用以创建和验证一个文件集。

6 一个兼容性声明的目的

一个应用不需要应用DICOM标准的所有可选组件。在达到最小基本需求之后，一个兼容的DICOM应用可以利用任何SOP类，传输协议，介质存储应用技术、可选(Type3)属性，编码和控制术语等等所需的来完成其设计任务。

注意：其实，可预见到一个应用可能只支持其相关真实世界行为的SOP类。例如，一个简单影片转换器可能对其他影像设备不支持SOP类，因为此类支持可能不需要。另一方面，一个复杂介质服务器，可能需要从多重设备中支持SOP类，以足够当做存储服务器的功能。一个应用可利用DICOM标准的组件的选择，很大程度上依赖于其趋向的应用和本标准的范围。

另外，DICOM标准允许一个应用来扩展和专门化DICOM所定义的SOP类，定义私有SOP类也一样。

一个兼容性声明运行一个使用者决定一个专门的应用所支持的DICOM标准可选组件，和一个应用增加的附加扩展和专门化。通过两种不同应用的兼容性比较，一个博学的用户应该可以决定着两种应用是否支持和什么的扩展传输。

不同结构在兼容声明表中的使用，依赖于该应用是否支持DICOM网络接口，一个DICOM介质存储接口，和一个关联的结合。在后者的情形下，一个单一兼容性声明应当提供合适部分的组成。

兼容性声明的第一部分包含一个DICOM兼容性声明的概述，是一页专门描述在文档的开始，提供了一个高水平描述和列举网络和介质服务类，包含它们的角色(SCU/SCP, FSC, FSR等等)

6.1 兼容性声明的网络部分的概述

一个兼容性声明的网络部分包含如下主要部分：

--一个功能概述包含应用数据流图，描述了所有的应用实体，包括它们的任何序列约束。它也显示了如何关联到本地和远程真实世界行为的。

--一个对每个应用实体的更详细说明，列举了所支持的SOP类和素描了它创建和接收连接的策略。

--每个应用是一体和真实世界行为的结合，一个发送(连接创建)和接收(连接接收)表达内容的描述。

注意：一个表达内容由一个抽象语法加上一系列可接受传输语法组成。抽象语法定义了一个SOP类或其中SOP类(一组由单一抽象语法UID所定义的相关SOP类)。通过列举应用实体的发送和接收的表达内容，兼容性声明是由应用可识别的信息对象集和服务类定义的。

--每个SOP类关联到一个抽象语法，支持一系列任何SOP选项；

--该应用支持的一个传输协议集；

--该应用的任何扩展、专门化和公共公开私有化的描述。

--详细描述DICOM相关设置的部分；

--任何应用详细的描述，这些可能关系到DICOM兼容性和互操作性。

--该生产商使用的编码和控制术语的描述。

6.2 兼容性声明中介质存储部分的声明

兼容性声明中的介质存储部分包含了如下主要部分：

--一个功能概述包含应用数据流图，描述了所有的应用实体，包括它们的任何序列约束。它也显示了如何关联到本地和远程真实世界行为的

--一个对介质存储应用技术所支持(这定义了支持SOP类和选择的介质)的每个应用实体的更详细说明，素描了它们是如何关联到本地和远程真实世界行为的。

--列举支持的可选SOP类；

--对每种介质存储应用技术关联的每种介质存储SOP类，列举支持的任何SOP选项；

--对每种介质存储应用技术关联的每种介质存储SOP类，列举传输语法支持的选项；

--该应用的任何扩展、专门化和公开地公开私有化的描述，例如增加或私有应用技术；

--描述DICOM关联设置细节的部分

--一个对任何应用细节的描述，可能关联到DICOM兼容性和互操作性。

--一个对生厂商使用的任何编码和控制术语的描述。

7 兼容性的需求

一个应用声明DICOM兼容性可以选择支持如下之一：

— 按照7.1节的网络兼容性（DICOM网络兼容需求）；

— 按照7.2节的介质存储兼容性（DICOM介质存储兼容需求）；

— 以上两者。

7.1 DICOM网络兼容需求应当：

— 兼容本部分定义的最小兼容需求；

— 根据本部分的规则和政策保护附录A，提供应用的兼容声明；

— 兼容PS3.4中定义的至少一种标准或标准扩展SOP类；

注意：兼容标准或标准扩展SOP类意味着兼容PS3.3中描绘的相关IOD，PS3.6定义的数据元素，以及PS3.7中定义的操作和通知。

— 遵守在7.3部分描述的对SOP类的类型管理的规则；

— 接受确认SOP类的一个陈述背景作为一个SCP，如果硬要接受任何DICOM连接请求；

— 产生和/或处理PS3.5中定义的数据集；

注意：对PS3.5的兼容意味着对PS3.6的兼容。

— 获取合法的权限注册<org id>来创建UID(如PS3.5)如果一个应用使用私有定义UIDs(如UIDs没在DICOM标准中定义)；

— 支持如下传输模式：

— TCP/IP(见于PS3.8)

7.2 DICOM介质交换兼容性需求：

一个应用对DICOM介质交换兼容性应当：

— 对本部分定义的最小兼容需求的兼容；

— 根据本部分包含的附录C的规则和原则，提供对该应用的一个兼容性结构性声明；

— 兼容至少一种在PS3.11中定义的标准应用技术；

— 支持在PS3.12中明确的其中一种物理媒介机及其关联媒介格式；

— 遵守7.3节描述的用以管理SOP类的类型的规则；

— 遵守7.4节所明确的，根据媒介存储应用技术的格式而涉及的明确规则；其他任何技术格式类型都不应当使用；

— 作为一个FSC或FSU去读，所有SOP类是在编码于任何强制性的传输语法的每个技术文档中强制性定义的；

— 作为一个FSC或FSU去写，所有SOP类是在编码于任何强制性的传输语法的每个技术文档中强制性定义的；

— 能够灵活忽略任何标准、扩展标准、专门化或私有的SOP类，这些表现在存储介质上，而没有在声明兼容性的任何技术文档中定义；

注意：这里或许有多余1个的应用技术来创建和读取单一物理介质上的文件集，比如介质中有标准和有争议性的应用技术创建的的文件集

— 能够灵活忽略DICOMDIR文件中的目录记录，没有对应于在声明兼容性的任何技术文档中定义的目录记录；

— 使用在PS3.10中定义的标准规则来访问介质上的文件集；

— 产生和处理在PS3.5中定义而封装在DICOM文件中的数据集；

注意：对PS3.5的兼容，也对PS3.6兼容

— 获取适当的权限去注册<org id>来创建UID(如PS3.5)如果一个应用使用私有定义的UID(如没有在DICOM标准中定义的UID);

一个兼容性声明没有符合以上所有的要求，不应当声明对DICOM的介质存储交换的兼容

7.3 管理SOP类的类型的规则

在一个兼容性声明中出版的每个SOP类是四个基本类型之一。一个应用的每个SOP类声明对DICOM标准兼容的，应当和下面规则一致进行处理，就如SOP类的类型所要求的。标准SOP类无条件或改变地兼容DICOM标准中的所有相关部分。

为了声明对一个标准的SOP类兼容，一个应用应当在其兼容性声明中对该事实声明，并且识别其所选的选项、规则和行为。

标准扩展SOP类应当：

a)是一个标准SOP类的一个合适的超级集；

b)没有改变该标准SOP类的任何标准属性的语义；

c)不包含私有类型1、1C、2、2C属性，也不增加附属的标准类型1、1C、2、2C属性；

d)没有将任何标准类型3属性转化为类型1、1C、2、2C；

e)使用所基于标准SOP类的相同UID。

一个标准扩展SOP类除了所基于IOD定义的属性外，可以包含标准和/或私有类型3属性，只要兼容性声明中定义了附加属性以及与PS3.3信息模型的之间关系。

一个应用声明对一个标准扩展SOP类的兼容性，应当在兼容性声明中识别所扩展的标准SOP类，包括选项、规则和选定的行为，并且描述附加到标准SOP类的IOD模型和模块的属性。

专门化SOP类应当：

a)必须完全兼容DICOM标准相关部分；

b)基于一个标准SOP类，比如：

    --包含所基于的标准SOP类的所有类型1、1C、2和2C属性；

    --没有改变任何标准属性的语义；

    --该SOP类使用私有定义的UID(如：不能和DICOM定义的UID雷同。)

c)基于PS3.3和PS3.4的DICOM信息模型；

专门化SOP类可以：

a)包含附加的标准和/或私有类型1、1C、2和2C属性；

b)增加私有和标准类型3属性，这个可以也可以不在兼容性声明中出版；

注意：任何未出版的属性的使用对于其他用户和专门化SOP类的提供者可以忽略的

c)在标准SOP类允许的集合范围内，枚举属性的允许值，

d)在标准SOP类允许的集合范围内，枚举内容条款的模板；

一个应用声明对一个专门化SOP类兼容，应当在其兼容性声明中包含所专门化的SOP类的标识，专门化SOP类的所有标准和私有类型1、1C、2和2C属性的用法描述，属性值和模板的限制的描述，以及相关私有定义UID。

私有SOP类应当：

a)和相关的DICOM部分完全地兼容，除了可能异常，如：DICOM默认传输支持，一个媒介存储应用技术所要求的传输语法不需要；
b)不改变PS3.6中任何标准属性的详细规格说明；
c)为其SOP类使用私有定义的UID(不与DICOM定义的UID一致)；
d)不改变现有DIMSE服务或者创建一个新的；
e)不改变在PS3.10中现有的DICOM文件服务，或使用了破坏其互操作性的方式进行扩展。

私有SOP类可以：
a)将DIMSE服务使用或应用到私有定义的或已改变的IOD(如，不必继承于标准SOP类)；
b)将介质存储操作使用或应用到私有定义的或已改变的IOD(如，不必继承于标准SOP类)；
c)指定任何标准属性作为类型1、1C、2、2C属性，而不必要注意其他IOD的属性类型；
d)定义类型1、1C、2、2C属性；
e)包含私有或标准类型3属性，而这些可能或可能不在兼容性声明中出版。

一个应用声明对一个私有SOP类的兼容，应当在应用的兼容性声明中提供类似PS3.3、PS3.4、PS3.6的私有SOP类的描述，包括SOP类的所有标准和私有类型1、1C、2、2C属性使用的描述、DICOM信息模型和私有定义的IOD。

注意：未出版SOP类(如：SOP类没在DICOM标准中和没在兼容性声明中定义)是允许的，为了允许一个应用在DICOM应用上下文中支持其他抽象语法。这类未出版的SOP类使用私有定义的IOD。未出版的SOP类的出现，没有阻止该应用和DICOM兼容，但是对其他应用是没意义的和可能忽略的。

7.4 管理应用规范类型的规则
在一个兼容性声明中使用的应用规范应当是三个基本类型之一。在一个应用声明对DICOM标准兼容的应用规范，应当和一些规则一致处理，如应用规范类型所要求的。
7.4.1 标准应用规范
一个标准的应用规范应当：
a)无改变兼容DICOM所有相关部分；
b)支持PS3.12中所明确的一类物理介质和附带的介质格式。声明对一个标准应用规范的兼容，一个应用应当在其兼容性声明中对此事实作声明，以及其所选选项、角色和行为。
一个标准应用规范的一个应用，可能扩展于该标准应用规范的标准SOP类，这些标准扩展SOP类应当符合PS7.3所明确的需求。
7.4.2 增强应用规范
一个增强应用规范应当:
a)是标准应用规范的合适超集，增加是对附加标准或标准扩展SOP类的支持；
b)为了符合标准应用规范所明确的，使用了相同的物理介质及其相关介质格式；
c)不包含专门化和私有化SOP类；
一个增强应用技术可以:
a)除了符合标准应用技术的SOP类，还可以包含一个或多个标准的或标准扩展的SOP类。这些附加SOP类是强制的或可选的。
b)包括符合a)中定义基本目录信息对象的扩展(如：附加需要的密钥、附加目录记录)。
c)增加一个或多个新角色(FSC、FSR和FSU)。

为了声明对增强应用技术的兼容，一个应用应当在其兼容性声明中对此事实作个声明，应当识别其所衍生的和明确参数的标准参数型应用规范。该应用同时应当识别其所选选项、角色和行为。

增强应用规范的一个应用可以：
a)符合标准应用规范的扩展标准SOP类，该标准扩展SOP类应当符合PS7.3所明确的需求；
b)也可以声明对该参数型应用规范所基于的标准应用技术的兼容。在该情况之下，FSC和FSU应用应当可以控制对标准应用规范的行为(如：提供方法只可以写符合标准应用规范的标准或标准扩展SOP类)。

7.4.3 私有应用规范
一个私有应用规范应当：
a)兼容PS3.10以及PS3.4中所明确的介质存储服务类；
b)只支持PS3.12中的一种物理介质及其附带介质格式；
注意：以上两者的目的是保证至少DICOMDIR能够被其他AP读取。
c)遵守PS7.3中管理SOP类的规则。

为了声明对一种私有应用技术的兼容，一个应用应当在其兼容性声明中对此事实进行描述，以及应当提供一个对该应用规范类似于PS3.11的的描述。该应用应当识别其所选选项、角色和行为。

注意：一个应用不符合第7部分的预备，包括应用技术的类型，对于DICOM是不兼容的，同时超出了DICOM兼容的范围；如此应用在DICOM术语中不算是一个应用技术。例如，一个应用选择将DICOM文件导出到不是PS3.12中的介质，或者使用了一个文件系统对于PS3.12中一个明确介质类型是未定义的，那么该应用不能声明它对DICOM标准的兼容，若使用该媒介和文件系统。

7.5 DICOM介质的兼容性
DICOM不在通用常识中定义一块介质的兼容性，一块介质的兼容性只能在为互操作性定义了明确上下文的一个或多个介质存储应用技术的范围内进行评估。
注意：一个或许可接受的声明"这是一个DICOM CD-R"，当执行一个存储介质的时候。但不能说"该CD-R是DICOM兼容的"，但可这样说"该CD-R对于基本心脏X线血管造影 DICOM应用技术。"

7.6 安全技术
DICOM针对ISO OSI基本参考模型明确了提供不同级别的安全的方法，通过结构的使用明确到每个指定的层。对应应用该结构的方法在DICOM标准不同部分都有描述，在PS3.15中的一些结构和算法作为安全技术。一个应用的兼容性声明描述了该应用可以使用的安全技术。

注意：例如，基本TLS安全传输连接技术定义了一个用于数据交换的鉴定命名参与的结构、在交换过程中数据的完整性和机密性的包含。
一个应用应当在其兼容性声明中列出其所支持的任何安全技术，如何选择其所用的安全技术，以及它如何使用该安全技术的新特性。
一个应用应当在其兼容性声明中列出用户识别联合搜索子项的任何附属使用，而这些子项在标准安全技术中没有明确的。

【免责特此声明：
1）本内容可能是来自互联网的，或经过本人整理的，仅仅代表了互联网和个人的意见和看法！
2）本内容仅仅提供参考，任何参考该内容造成任何的后果，均与原创作者和本博客作者无关！】