了解 DICOM 基本协议与其相关
DICOM（digital imaging communications in medicine）
（医学数字图像通信）
DICOM 可以解释为“医学数字化图像 通信/交流 的共同规格”，且在国内是唯一被接受的医疗影像国际规范。
写在前面，本文仅做笔记，对 dicom 理解不深，建议直接下拉到文末，跳转至参考文档地址学习。
DICOM规格
1. 资料结构：Patient，Study，Series，Image 四个层级
Patient 中包含了该病人的所有基本资料（姓名，性别，年龄等）和医生指定的检查 Study；
Study 中包含了检查种类（CT，MR，B超）和指定检查的 Series；
Series 中包含检查的技术条件（毫安，FOV，层厚等）和图像 Image。
2. 影像对象（IOD: Information Object Definition），可分为两大部分：象素数据（PIXELDATA），影像属性（ATTRI-BUTE）
象素数据 是通过单纯描述图像上每一个图像点的值来组合成一个医学图像；
影像属性 则包含了该图像所描述病人的资料信息，如: 病人名称、检查日期、CT号、MR号、扫描条件、层厚等，甚至包含了医嘱信息。
3. 服务功能对（SOP: Service-ObjectPair）
影像对象，如 CT，MR，US，X-ray 等，加上对之进行的服务，例如：Storage，Verification，Query/Retrieve 等，就组成了一个SOP。也就是 DICOM 最基本的运作单元。
4. SCU/SCP（ServiceClass User/Provider）
与 Client/Server 多对一的概念不同，SCU/SCP 是一对一的服务；
SCP 是负责提供对于图像资料的各种服务，扮演 Server 角色；
而 SCU 则是使用这些服务的一方，即 Client 一方。
DICOM的工作过程
1. A系统往 B系统发起初始信息（支持的 SOP 有哪些、如何编码和压缩资料、角色是 SCU 还是 SCP）；
2. B系统接收并处理初始信息，整理出两系统共同的 SOP 和 Transfer Syntax，回应给 A系统；
3. 通信起始设定完成，可进行信息交换。
DICOM的网络结构
在网络 ISO/OSI 七层结构中，DICOM 协议是定义在最高三层，底层部分则是符合 TCP/IP 结构。
Worklist服务
检查设备通过 Worklist 服务从工作流系统获取待检查列表。
Worklist 服务在这里的作用是避免检查技师在设备上手动输入患者的信息，避免了信息输入错误的情况，同时减少了技师的工作量。
Worklist 其实就是一个 C-Find 请求，不过这个 C-Find 请求指定了 SOP Class UID 为 【1.2.840.10008.5.1.4.31】，这个 SOP Class 就指定了当前的 C-Find 请求是查询 Worklist。
C-ECHO：验证DICOM服务两端的交流是否畅通
C-STORE：存储病人图像信息
C-FIND：查询病人图像信息
C-MOVE：转存或获取病人图像信息
参考文档：
基础： https://blog.csdn.net/inter_peng/article/details/38856161
UID概念：https://www.cnblogs.com/jak-black/archive/2012/12/19/2824458.html
worklist：https://www.cnblogs.com/bdqczhl/p/12099560.html
C-MOVE,C-FIND：https://blog.csdn.net/zssureqh/article/details/41631563
dicom开源库 c# fo-dicom：https://github.com/fo-dicom/fo-dicom
