错误：
E: can’t load data dictionary
W: Monochrome encoder: No data dictionary
解决：
https://forum.dcmtk.org/viewtopic.php?f=4&t=13
(0020,0032) DS -131.76953125-291.76953125\1412.6 # 3, 34 Image Position (Patient)
(0020,1041) DS 1412.6 # 1, 6 Slice Location
(0020,0037) DS 1\0\0\0\1\0 # 6, 12 Image Orientation (Patient)
(0018,0050) DS 0.75 # 1, 4 Slice Thickness
(0020,0013) IS 11 # 1, 2 Instance Number
(0018,9313) FD 0.23046875-177.76953125\1411.9000000000001 # 3, 24 Data Collection Center (Patient)
(0018,9318) FD -13.76953125-173.76953125\1411.9000000000001 # 3, 24 Reconstruction Target Center (Patient)
DICOM协议更多的是关于医疗行业各种服务及相关流程的约定，因此其实DICOM协议中最主要的是信息流，是对医院整体运作流程的约定。
DICOM网络传输：
所有与连接相关的信息在DICOM协议中的ACSE（Association Control Service Element）定义。
AE Title：AE Title用于标识DICOM网络中的唯一（Unique）DICOM系统（有点类似于互联网中的IP地址），因此在一个DICOM网络环境中，要确保每一个DICOM系统拥有唯一的名称——这个工作通常由DICOM网络管理员来完成。
Presentation Contexts：客户端（SCU）会向服务端发送一系列长度小于128的被称为描述上下文（Presentation Contexts）的消息列表，每一个描述上下文代表一种客户端期望的服务。客户端用DICOM标识符来标识每种服务，即SOP Class UID（Service Object Pair Class Unique Identifier）
DCMTK开源库更偏重于按照层（Layer）来实现DICOM应用实体（AE）之间的连接（ACSE）及消息传输（DIMSE），主要分为DIMSE（应用层）、ACSE（属于OSI七层协议中的应用层）和DUL（Dicom Upper Layer层，该层与OSI中的TCP/IP层对接）三大部分。用户通过使用DCMTK提供的DICOM协议中规定的各层的数据结构和操作函数，按照DICOM标准中规定的流程来实现自己的DICOM服务。
ACSE主要应用户连接建立阶段。 连接（Association）的建立是两个DICOM实体（AE）之间进行交互的第一步，AEs在建立的连接上进行数据编码格式、传输方式的协商。
有上述对比可以看出ACSE是DIMSE的基础，DIMSE是在ACSE之上实现的。正如PDU vs PDV中提到的，DIMSE Message是在Association建立完成后，通过ACSE中的P-DATA-TF服务来传输，各种DIMSE 消息会被分割成PDVs放入到P-DATA-TF的Variable Field。
DIMSE：DIMSE中消息由指令（Command）和数据集（Data Set）构成；
将DIMSE归类为表示层，用于指出DICOM协议中提供的各项基础服务，也就是DIMSE Protocol中规定的 服务原语 （Service Primitives），为对等DICOM 应用实体（Application Entity）之间交流服务。
DIMSE-C 服务是支持在有同等 DIMSE-service-user 复合信息对象定义的复合 SOP 实例上操作的 DIMSE 服务的子集，复合 SOP 实例大致可以理解为不会被改变的文档类的实体，例如 dicom 影像文件。DIMSE-C 服务包含以下5个服务：
1.C-STORE：用于一个 DIMSE-service-user 在同等的 DIMSE-service-user 上存储一个复合 SOP 实例；其实就是存储服务，可以用来归档影像，也可以用来获取影像；
有关详细介绍请参考 Dicom 学习笔记-DICOM C-Store 消息服务
2.C-FIND：查询服务，用于一个 DIMSE-service-user 在同等的DIMSE-service-user 上查询复合 SOP 实例的属性满足查询条件给出的一组属性的复合 SOP 实例；我们可以通过此服务查询某一 PatientID 为xx的患者的所有检查影像；
有关详细介绍请参考 Dicom 学习笔记-DICOM C-Find 消息服务
3.C-GET：获取服务，用于一个 DIMSE-service-user 在同等的DIMSE-service-user 上查询复合 SOP 实例的属性满足查询条件给出的一组属性的复合 SOP 实例，并取回这些符合条件的复合 SOP 实例，同时在这个过程中将触发一个或多个 C-STORE 子操作过程，所有的操作（包含 C-STORE 子操作）均在同一个 Association 连接中；
有关详细介绍请参考 Dicom 学习笔记-DICOM C-Get 消息服务
4.C-MOVE：也是获取服务，但是获取的发起方和接收方可以是同一个实体也可以是两个不同的实体。标准中是这么定义的：用于一个 DIMSE-service-user 在同等的 DIMSE-service-user 上查询复合 SOP 实例的属性满足查询条件给出的一组属性的复合 SOP 实例，并取回这些符合条件的复合 SOP 实例，同时在这个过程中将触发一个或多个 C-STORE 子操作过程，所有的 C-STORE 子操作触发在另外一个单独的 TCP 连接中；和 C-GET 最大的区别是这个是两个 Association 连接，而 C-GET 服务是一个；
有关详细介绍请参考 Dicom 学习笔记-DICOM C-Move 消息服务
5.C-ECHO：验证两个同等的 DIMSE-service-user 之间端到端的通信是否成功；
有关详细介绍请参考 Dicom 学习笔记-DICOM C-Echo 消息服务
DIMSE-N 服务是支持在有对等 DIMSE-service-user 规格化信息对象定义的规格化 SOP 实例上操作和通知的 DIMSE 服务的子集。这类服务会在打印（具体可以参考 DICOM 标准第4部分的附录H和第17部分的附录BB）中使用到。DIMSE-N 服务包含以下6个服务：
N-EVENT-REPORT：用来由一个 DIMSE-service-user 给对等的另一个 DIMSE-service-user 报告一个事件；唯一一个通知类型的服务；
N-GET：用于一个 DIMSE-service-user 从对等的另一个 DIMSE-service-user 取回属性值；
N-SET：用于一个 DIMSE-service-user 向对等的另一个 DIMSE-service-user 请求属性值修改；
N-ACTION：用于一个 DIMSE-service-user 向对等的另一个 DIMSE-service-user 请求一个操作；
N-CREATE：用于一个 DIMSE-service-user 向对等的另一个 DIMSE-service-user 请求创建新的托管 SOP 实例，完成其标识和相关属性的值，同时注册其标识。
N-DELETE：用于一个 DIMSE-service-user 向对等的另一个 DIMSE-service-user 请求删除一个托管 SOP 实例，同时注销其标识。
协议Protocol：协议为计算机网络中进行数据交换而建立的规则、标准或约定的集合。由三个要素组成，即语义、语法和时序。
服务原语Service Primitive：服务原语（Service Primitives）：用户和协议实体间的接口,实际上是一段程序代码，但其具有不可分割性。通过服务原语能实现服务用户和服务提供者间的交流。服务原语只有四种类型，分别是请求（Request）、指示（Indication）、响应（Response）、确认（Confirm）。
worklist:
worklist可以看做是放射科设备从医院RIS系统中自动读取患者信息的一种“通信协议”，可以指存储在RIS系统中的患者数据库，主要包括患者的基本信息（如年龄、性别、身高、体重、出生年月等），这与DCM文件信息头MetaInfo中的多数字段重合。因此从RIS系统中自动获取worklist是医院信息化的必要组成部分。
worklist 测试:
用wlmscpfs.exe来作为worklist通讯的服务端，即等待外部访问的终端；用findscu.exe来作为服务端，用来发起worklist访问。
HIS：
医院除了存储影像的PACS系统以外，与信息和流程管理相关的还有HIS和RIS系统，HIS系统是全院级的信息登记系统，覆盖了医院全业务流程，甚至涵盖了像财务管理、人事管理、住院病人管理、药品库管理等，为医院所属各部门提供病人诊疗信息、行政管理信息的收集、存储、处理、提取和数据交换。
HIS数字化医院解决方案根据医院的业务特征，满足四个面向的目标，即面向医疗，面向管理，面向患者，面对员工，它是最终实现医院数字化建设目标的有效工具。HIS数字化医院解决方案建设整体框架可以概括为：一个中心（数据中心和集成平台HAI）；两卡（即外部就诊卡，医保卡和内部工作卡）；两网（即内网和外网）；五大业务平台（医疗业务平台，客户关系管理平台，供应链管理平台，知识协作平台，管理业务和决策支持平台）；两大体系（管理信息和临床信息）；十大核心系统（HRP，PACS，LIS，EMR，SCM，（OA，Tele-Medicine，无线应用）。
HL7（Health Level Seven）：
HL7标准是目前医疗数据交换标准中应用最广泛的一个基于文本的国际标准，主要应用领域就是HIS、RIS，用于规范HIS、RIS系统及其设备间的文本数据通信，HL7最早是在1987年提出的。
HL7规范了医院的HIS、RIS及内部设备之间的通信，而DICOM则涵盖了数字医学图像采集、归档、通信、显示及查询等信息交换的所有范畴，用于实现PACS系统与RIS、HIS的集成。那么是不是有了这两个标准就万事大吉了呢？当然不是。HL7和DICOM标准虽然为信息共享提供了基础，但是两者由于分属不同机构、设计目的，发布时间等都不同导致彼此之间存在着差异，更糟糕的是HL7和DICOM标准处理的数据对象不同，HL7偏重于文本数据管理，而DICOM标准在数字图像的通信和管理方面擅长
IHE：
为了强化已有的DICOM和HL7通讯标准的协同工作。IHE并非一种新的标准，而是提供DICOM和HL7的集成方案，IHE集成方案不对医疗体系内各系统功能的具体实现进行定义，而只关心系统内部各部分之间以及系统与外部环境交互的方式。
PACS系统：
PACS，全称为Picture Archiving and Communication Systems，主要负责医学图像的存储，如CT、US等放射图像，甚至可以用来存储心电等wave类型数据。
在PACS系统中，通常采用关系模型数据库（如SQL、DB2、Cache、Oracle等）存储数据，关系数据库是通过具有关联关系的表格来归档数据，通常为了表示DICOM数据的层级关系，PACS系统依据DICOM标准采用Patient、Study、Series、Image四级表格来存储，各表之间的关系如DICOM标准第三部分所述：Patient与Study、Study与Series、Series与Image都是1对n的关系。另外除了核心的四级表格以外，PACS系统中也会添加其他与系统相关的表格，例如用户表User，设备表AE等。
存储影像数据的具体实施方案，PACS领域中常见的方案主要有以下几种：
–基于文件系统的存储方案
–基于blob的数据库存储方案 BLOG（binary large object）
–混合存储方案
raise InvalidDicomError("File is missing DICOM File Meta Information "
ds = pydicom.dcmread(file_path,force=True)
问题2：
AttributeError: ‘Dataset’ object has no attribute ‘TransferSyntaxUID’
ds.file_meta.TransferSyntaxUID = pydicom.uid.ImplicitVRLittleEndian
问题3：
解析压缩的dicom
https://pydicom.github.io/pydicom/stable/old/image_data_handlers.html?highlight=synta
