引言
看 DICOM 标准有一段时间了，前面几篇也介绍了一下 DIMSE-C 消息服务，具体参看Dicom 学习笔记-Dicom 消息服务（DIMSE-C/DIMSE-N），本文就介绍一下 DICOM 标准中的一个重要服务- Worklist 服务。
Worklist 服务简介
首先来看一下 DICOM 标准中的说明：
A worklist is the structure to present information related to a particular set of tasks. It specifies particular details for each task. The information supports the selection of the task to be performed first, and supports the performance of that task.
意思是 Worklist 是呈现与特定任务组相关信息的结构。它指定每个任务的具体细节。这个信息支持首先要执行的任务的选择，并支持该任务的执行。
这样理解起来感觉很困难，那么我们根据实际场景来一步一步的讲解这个服务具体是干什么的。我们就以医院拍片（DR）的场景来讲，临床医生给患者开具处方单（DR 检查）后，患者拿着就诊卡和这张处方单到达放射科，先要去登记处登记，登记的这个过程是将患者的信息录入到 RIS 系统，通过就诊卡卡号从 HIS 系统中获取患者信息，然后患者就到候诊区等待叫号，检查设备通过 Worklist 服务从工作流系统获取待检查列表，然后通过叫号系统呼叫患者进行检查。Worklist 服务在这里的作用是避免检查技师在设备上手动输入患者的信息，避免了信息输入错误的情况，同时减少了技师的工作量。
Worklist 的流程图如下：
Worklist 请求
Worklist 其实就是一个 C-Find 请求，不过这个 C-Find 请求指定了 SOP Class UID 为 【1.2.840.10008.5.1.4.31】，这个 SOP Class 就指定了当前的 C-Find 请求是查询 Worklist，下图是 Worklist 信息模型的实体关系图
有关 Worklist 请求的参数构造可详见 DICOM 标准 PS 3.4 中 Table K.6-1. Attributes for the Modality Worklist Information Model（P219），这里面定义了必填和可选参数：
- Scheduled Procedure Step Model 中，必需的参数有 ：
- ScheduledProcedureStepSequence(0040,0100)，这个 TAG 里面必填的 TAG 有：
1.1 设备的 AE Title【Scheduled Station AE Title(0040,0001)】；
1.2 计划程序步骤的开始日期和开始时间【Scheduled Procedure Step Start Date(0040,0002)、Scheduled Procedure Step Start Time(0040,0003)】；
1.3 设备【Modality(0008,0060)】（DR、CT etc.）；
1.4 执行医师名称【Scheduled Performing Physician's Name(0040,0006)】；
- Patient Identification 中，有两个参数必需：
- 患者姓名【Patient's Name(0010,0010)】；
- 患者 ID【Patient ID(0010,0020)】；
其他的参数均为可选参数。
在实际查询中，这些必需的参数也可以做模糊匹配查询，具体匹配的规则有设备方和 Worklist SCP 方互相定义遵循即可；
在实际场景中，有指定查询某一个患者的，即传准确的患者姓名和患者 ID，Scheduled Procedure Step Model 做模糊匹配；有通过Scheduled Procedure Step Start Date 和 Scheduled Procedure Step Start Time 结合设备的 AE Title 查询的；还有通过 Scheduled Procedure Step Start Date 和 Scheduled Procedure Step Start Time 结合 Modality 或执行医师名称查询的，具体可以参看下图：
Worklist SCU
结合开源 DICOM 库 fo-dicom 可以非常容易的构造一个 Worklist SCU，fo-dicom 已经在 DicomCFindRequest.cs 中封装好了创建查询 Worklist 的条件，只需要如下的代码即可实现 Worklist SCU。
using Dicom.Network;
using System;
using System.Collections.Generic;
var worklistItems = new List<DicomDataset>();
var cfind = DicomCFindRequest.CreateWorklistQuery(); // no filter, so query all awailable entries
cfind.OnResponseReceived = (DicomCFindRequest rq, DicomCFindResponse rp) =>
{
var dicomDataset = rp.Dataset;
if (dicomDataset != null)
{
Console.WriteLine("Study UID: {0}", dicomDataset.GetSingleValue<string>(DicomTag.StudyInstanceUID));
worklistItems.Add(rp.Dataset);
}
};
var client = new DicomClient();
client.AddRequest(cfind);
client.SendAsync(serverIP, serverPort, false, clientAET, serverAET).GetAwaiter().GetResult();
return worklistItems;
Worklist SCP
Worklist SCP 其实就是一个 C-Find SCP，可以通过派生 DicomService 服务类来实现 Dicom 服务的基本框架，然后实现 IDicomServiceProvider 和 IDicomCFindProvider 接口来实现，但要注意的是在实现 IDicomServiceProvider 接口的 OnReceiveAssociationRequestAsync 方法时需要根据请求发送的 SOP Class UID 过滤，只有值为【1.2.840.10008.5.1.4.31】的请求才同意在建立 Association 连接后接受 C-Find 请求。具体代码可以参考这里。
Worklist 过程分析
Worklist 请求的交互过程和 C-Find 请求的一样，都是先通过 A-Associate 请求建立 Association 连接，然后发送 C-Find 请求，最后通过 A-Release 请求释放 Association 连接。我主要介绍一下它们的区别，一个最主要的区别就是请求中传输的 Affected SOP Class UID 不一样，普通 C-Find 请求中根据查询的层级 Affected SOP Class UID 分为患者级【Patient Root Query Retrieve Information Model FIND（1.2.840.10008.5.1.4.1.2.1.1）】和检查级【1.2.840.10008.5.1.4.1.2.2.1（Study Root Query Retrieve Information Model FIND）】，而 Worklist 请求中 C-Find 请求的 Affected SOP Class UID 是【Modality Worklist Information Model FIND（1.2.840.10008.5.1.4.31）】，详见下图：
参考
- DICOM 标准 PS 3.4 K Basic Worklist Management Service (Normative)
- DICOM 标准 PS 3.3 C Information Module Definitions (Normative)
- DICOM 标准 PS 3.17 DD Worklists (Informative)
