DICOM标准之三_信息对象定义2
第3部分 信息对象定义(2)
6 DICOM信息模型
DICOM信息模型定义医学图像传输的相关的信息的结构和组织。如图6-1描述了DICOM信息模型的主要结构之间的关系。
图6-1 DICOM信息模型的主要结构
6.1 信息对象定义
一个信息对象模型(IOD)是一个面向对象的抽象数据模型，用以明确真实世界对象的信息。一个IOD提供了交换的应用实体，以及附加交换信息的公共视图。
一个IOD不是表现为真实世界中的明确实例，但仅仅是真实世界中拥有共同属性的对象的一种类别。一个IOD用以描述单一真实世界对象的类别称作为标准IOD。一个IOD包含了相关的真实世界对象的信息称作为复合IOD。
6.1.1 复合IOD
复合IOD是一种描述了真实世界的DICOM模型的多个实体的部分的信息对象定义。该模型在第7节中介绍。该类的一个IOD包含的属性不是继承与IOD所描述的真实世界对象，而是继承于相关真实世界对象。
这些相关真实世界对象为交换信息提供了完整的上下文。当一个复合IOD的实例交换时，它的整个上下文在应用实体间交换。复合IOD实例之间关系应当在这上下文信息中得到传达。
6.1.2 标准IOD
一个标准IOD是一种通常描述真实世界的DICOM模型的单一实体的信息对象定义。
当一个标准IOD的实例交换时，该IOD的上下文事实上没有交换。然而，它的上下文是通过指向相关标准IOD实例的指针提供。
标准IOD在附录B中说明。
6.2 属性
一个IOD的属性描绘了一个真实世界对象实例的性质。相关属性按组分模块，用以描述更高等级的语义，这些在附录C中的模块说明中明细。
属性通过规则当作数据元素来编码，值表示和值的多样性在PS3.5节中明确；对于明确的数据元素，值表示和值的多样性在PS3.6节中的数据字典中明确。
当一个IOD包含的多个模块有相同的属性时，该属性只能一次编码进入数据元素。
6.3 在线传输和介质存储服务
对于在线传输，DIMSE服务允许一个DICOM的AE通过网络或点对点接口请求一个操作或通知。DIMSE服务在PS3.7节中定义。
对于介质存储交换，介质存储服务允许一个DICOM的AE请求介质存储相关操作。
注意：这些介质存储服务在PS3.10中讨论。
6.3.1 DIMSE-C 服务
DIMSE-C服务只适用于一个复合IOD的服务。DIMSE-C服务只提供操作服务。
6.3.2 DIMSE-N 服务
DIMSE-N服务只是用于一个标准IOD的服务。DIMSE-N服务同时提供了操作和通知服务。
6.4 DIMSE服务组
一个DIMSE服务组明确了一个或多个操作和通知，在PS3.7中定义；适用于一个IOD。
DIMSE服务组在PS3.4中的服务对象对类的说明中定义。
6.5 服务对象对(SOP)类
一个服务对象对是由一个IOD和一个DIMSE服务组的结合来定义。SOP类的定义包含了可以用以限制DIMSE服务组的服务和IOD属性的使用。
SOP类的选择被AE用以创建能够支持其互操作的一个商定的集合。该协商是在联合创建时进行的，如PS3.7中的描述。一个扩展协商允许AE进一步商定一个SOP类范围内明确选项。
注意：对于管理对象类，在DICOM信息对象模型中定义的SOP类等同于ISO/OSI的术语。熟悉面向对象术语的读者将会把SOP类的操作(和通知)当作一个对象类的方法。
6.5.1 标准和复合SOP类
DICOM定义了标准和复合两种SOP类。标准SOP类定义为一个标准IOD和一个DIMSE-N服务集合的结合。复合SOP类定义为一个复合IOD和一个DIMSE-C服务集合的结合。
注意：SOP类说明在定义DICOM兼容性需求中扮演了一个关键的角色。它允许DICOM的AE选择一个良好定义的应用级别的需要声明兼容的标准DICOM V3.0的子集，如PS3.2。
6.6 联合协商
联合创建是同等DICOM适用AE之间通信的第一个阶段。AE之间应当使用联合创建来协商哪个SOP类可以交换以及数据是如何编码的。
联合协商是在PS3.7章中定义。
6.7 服务类说明
一个服务类说明定义了一个或多个SOP类以及一个相关明确的功能，而这些功能是正在通信AE完成的。一个服务类说明也定义了规则，这些规则允许应用声明兼容一个或多个SOP类的一些预定义级别。应用可以兼容SOP类，比如一个SCU和SCP。
服务类说明在PS3.4章中定义。
注意：同等AE的该类交互是按Client/Server模型进行的。SCU扮演Client角色，而SCP扮演Server角色。SCU和SCP角色是在联合创建时决定的。
7 真实世界的DICOM模型
图7-1a，7-1b，7-2描绘了真实世界的DICOM视图，真实世界在DICOM标准范围内定义了相关真实世界对象以及他们的关系。它提供了一个通用的框架来保证了DICOM标准中定义各种各样的信息对象之间的持久性。
图7-1a，真实世界的DICOM模型
图7-1b，真实世界-打印-DICOM模型
7-2a，DICOM信息模型
7-2b，DICOM信息模型-打印
P7-2c，DICOM信息模型-放射治疗
图7-3，真实世界模型-为了达到模型是接口
7.1 DICOM信息模型
DICOM信息模型是衍生于真实世界的DICOM模型。DICOM信息模型通过7-2a，7-2b，7-2c来描绘，定义了各种IOD，已由本标准和它们关系明确。通常情况下，DICOM的IOD和真实世界对象没有一对一的关系。例如，一个复合IOD包含了多个真实世界中诸如序列、设备、框架参考、检查和病人等对象的属性。
图7-2a、7-2b、7-2c整个对应了从附录A到C定义的IOD。
7.2 附录A，B和C的组织
附录A定义了复合IOD(如图像)获得一系列的形态(如CT、MR、NM、US、CR和次要捕获)。这些复合IOD的参考组件在附录C中找到。
附录B定义里了标准IOD(如录像区间、打印作业)用于PS3.4中定义的一系列服务类。这些标准IOD的参考组件在附录C中找到。
7.3 真实世界的DICOM模型的扩展。
为了达到基本工作表管理服务类和形态执行过程SOP类的目的，真实世界中原始DICOM模型已增强，如图7-3描述的。
在PS3.17附录名为【原始DICOM标准的形态工作表集成和形态执行过程】讨论了相对于真实世界的原始DICOM模型的扩展的关系。
图7-3是真实世界对象的一个抽象描述，在Modality-IS接口中调用。它不是作为一个应用的数据库模式的。
7.3.1 DICOM真实世界模型的扩展定义
7.3.1.1 病人
一个病人是一个人正在接受或已登记将接受保健服务，或者有一个或多个检查的对象为了其他一些目的，如科研。
注意：一个人可能是一个人或者一个动物。
7.3.1.2 服务片段和访问
一个服务片段是一组事件，聚集在由开始时间和结束时间所界定的区间里。一个服务片段是由病人医疗条件的特定子集的治疗和管理所发生的上下文。服务片段中的开始时间、结束时间和涉及的事件的定义完全是特定的；它可能包括一次单一的门诊随访和住院治疗，或者延续为一段重要是时期，比如一次怀孕、或者一次肿瘤治疗、或者是心脏从梗塞状态到康复状态的片段。一个服务片段可能涉及到一个或多个医疗机构(管理机构授权医疗提供者在他们合法的管理领域提供医疗服务，如医院、私人医生诊所、多专业合作的临床机构和护理社区)。
随访作为服务片段的子集，形成了事件集，由一个专门医疗机构在单一设施的义务执行。一次随访可能关联到医疗机构的一个实施定义范围内的一个或多个物理区域(如不同房间、科室和建筑)，包括诊断的许可和解除，随访的时间区间。
注意：1）随访是服务片段的一部分。服务片段描述了多个医疗管理方面，而随访仅限于对一个病人对一个设施的一次访问的描述。
2）在Modality Worklist SOP类的上下文，服务片段的属性在随访部分定义。
3）随访的属性通常使用了历史性名词"许可"，尽管在流动诊所的一次随访不涉及到作为一个住院病人的许可。
7.3.1.3 图像服务请求
一个图像服务请求是进程类型列表中所选择的一个或多个请求进程的集合。一个图像服务请求是在服务片段的上下文中，由一个授权的图像服务请求者递交给一个授权的图像服务提供者。一个图像服务请求包括习惯明确和通用信息。一个图像服务请求的每个实例同时携带共同的信息到一个或多个的请求的请求进程。一个图像服务请求可能关联到一个或多个在同一服务片段发生的随访。一个图像服务请求的存在，会特定导致一个或多个图像服务报告的产生，以及图像服务报告对一个或多个目标的分发。
在Modality Worklist的上下文中，图像服务请求所提供的信息旨在完成一个或多个图像进程，比如获取新图像。在General Purpose Worklist的上下文中，图像服务请求所提供的信息支持一个更加通用的请求类型，比如写报告、在一个现有的检查中请求一个图像处理进程等等。
7.3.1.4 进程类型
一个进程类型定义了一个进程类别。在图像服务的上下文中，一个进程类型是图像进程目录中的一个细目，可以在一个图像服务设施中请求和报告。一个进程类型的实例典型地有一个名称和一个或多个的其他标识名。一个进程类型关联到一个或多个的进程计划。
注意：本实体的信息上下文关联到一个进程类型的通用定义，而不仅仅是分解到所需协议对一个制定病人来完成一个请求进程的明确实例。
待续...
【免责特此声明：
1）本内容可能是来自互联网的，或经过本人整理的，仅仅代表了互联网和个人的意见和看法！
2）本内容仅仅提供参考，任何参考该内容造成任何的后果，均与原创作者和本博客作者无关！】