基于临床超声设备环境下的Worklist 应用

李昕，鲁 晓，张 勇，丁博渊，邱 逦，罗燕

（四川大学华西医院超声医学科，四川成都 610041）

目前，临床超声医生在对患者进行超声诊疗时，需对患者进行身份信息核查工作，这是降低医疗风险非常重要的环节之一，患者信息错误导致的医疗风险，将为患者带来无法挽回的后果[1]。传统的手动输入患者信息和研究标识信息（患者姓名，患者标识，出生日期，性别和登记号）时，会出现信息不对等的错误。Worklist 的应用是基于DICOM 协议中的CFind 查询服务技术保证超声信息系统（Ultrasound Information System,UIS）与设备之间产生的数据具有一致性和完整性的功能，可以从UIS 接收Json 消息，将转换或映射数据以生成DICOM 消息的模式传递到影像归档和通信系统（Picture Archiving and Communication System，PACS）[2]。工作流程中需要UIS提供的患者和检查信息才能流向模态（Modality），利用DICOM 方式工作清单（DICOM Modality Worklist）对此提供支持。如今，医院的发展更依赖于互联网对数据的传递，从而形成闭环管理，减少数据差异产生的问题。现在，超声设备已经通过一致性声明和系统供应商之间测试，建立了用于查询或检索，存储和打印类的基本DICOM 通信协议。依赖HIS（Hospital Information System,HIS）接口将患者的信息传递到超声UIS 中。通过该服务功能将患者的数据自动、可靠、准确无误地从数据库中转换到设备工作列表中，从而减少医务人员的干预，同时避免因数据错误产生的影响，大幅度提高了医务人员的工作效率[3-5]。目前Worklist 功能已经广泛运用在放射、护理等领域。

1 Worklist定义

Worklist 作为影像设备访问工作列表，主要用于影像设备与业务系统，通过特定协议完成数据交互[6]。DICOM 协议中包含很丰富的服务，而Worklist服务仅仅是其中之一。通过模态查询数据提供者，并获取医疗环境下患者基本信息，同样也可获取与科研等相关的数据信息。根据DICOM 协议部分描述，Worklist 工作原理中定义了以下角色构成。服务类客体(Service Class User，SCU)以及服务类供体（Service Class Provider，SCP）,两者之间还需依靠DICOM SOP（Service Object Pair，SOP）类建立关联。而DICOM SOP类是由DICOM IOD 与DIMSE服务共同定义。Worklist 正是利用Query/Retrieve 服务类同时结合C-Find 的服务元，执行DICOM IOD 查询服务的过程。当SCU 需要与SCP 之间交互时，两者互为实施DICOM SOP 通讯的双方，需要依托应用实体(Application Entity，AE)对其属性信息进行控制和处理。对于C-Find 服务元素来讲，请求查询操作分为三个状态（操作成功、失败后发送成功、发送失败）。而C-Move 服务元素主要针对反馈应答及反馈操作计数。C-Get 服务则为提取性操作。C-Find的过程会包含必要键属性及可选键属性同时发起查询请求，当接收到指定的键属性后执行匹配操作，并反馈状态消息，例如患者信息、检查项目信息、设备操作信息等[7-8]。而在实际应用中，通常第三方信息系统与影像设备之间都具备查询服务能力。而运用此项服务最大的价值在于可以将消息形成闭环从而减少输入导致的错误。假设把SCP比作服务端，把SCU 比作客户端，模拟具体的交互过程如图1 所示。

图1 SCP与SCU交互过程

SCU 首先发起对话请求，试探SCP 端的响应。当SCP 响应连接请求后建立连接的同时会反馈成功连接状态给与SCU 端。此时SCU 第二次发送请求，此次请求中主要涉及到C-Find 查询。SCP 接收查询请求同时建立对话，按照查询要求定义返回SCU 需求数据，其中包含返回状态值。交互完毕后释放对话连接，完成此次查询活动[9]。

结合实际的医疗环境来阐述具体的工作原理，当患者需要进行彩超检查，患者通过就诊卡或已缴费单据前往超声科预约台，如图2 所示。登记的过程是将患者的信息（卡号、患者姓名、性别、年龄、检查项目等信息）通过HIS 系统传递到UIS 服务器。而UIS 服务器根据收到的以上信息会将患者按照具体的检查时间预约至指定的检查房间。同时UIS 服务器会将患者预约信息及状态、检查信息向PACS 服务器进行推送，当PACS 收到信息后，按照请求信息进行字段整理,最终形成一张可供设备调阅的工作列表。由超声设备向PACS 服务器发送对话请求，PACS 服务器收到超声设备发送的请求后进行响应，双方建立连接。此时设备按照需要的字段向PACS服务器再次发送请求，PACS 服务器按照超声设备需要的信息进行整理过滤后推送给设备并发送状态信息，最后设备收到PACS 服务器发送的数据信息后也会向PACS 服务器反馈一条状态信息证明此次对话是否成功，并断开此次对话服务。

图2 UIS-PACS系统与设备交互过程

超声检查前，需要对患者的身份信息进行核实，往往医务人员需要通过特定的某些字段来确认患者的基本信息和检查信息是否与预约系统中一致。

在未启用Worklist 功能前，医生需要核对患者手中的预约单，通过超声设备Patient 界面手动输入患者的检查ID（Patient Number）以及患者姓名（Patient’s Name）特定字段进行检查。日常工作中，传统的输入模式存在以下问题：

1）采用人工输入导致浪费大量时间以及工作效率的降低。

2）医生在录入患者数据过程中产生的检查ID号错误，导致图像信息的传输失败。

3）数据通过手动输入，信息过于单一，且只对患者的ID 号进行保存，对于后期科研数据的研究有一定影响。

启用Worklist 技术对于现有模式优化存在以下帮助：

1）医生通过Worklist 获取到每日的预约患者信息，通过扫描患者预约单上的检查号，在超声机上精准定位到患者，并进行检查，减少了人为出错的概率，从而大大提高了工作效率。

2）患者数据通过Worklist 工作列表抓取预约的数据，杜绝了检查号不一致导致传输失败的问题，真正意义上保证了患者图像文件的准确性及个人图像信息的归档。

3）超声设备中Worklist 含有丰富的字段（如医嘱、部位、诊断等）可以进行抓取并归档，对于后期按照病种进行研究有一定支撑作用。

2 Worklist字段参数

有关Worklist 的参数构造可详见DICOM 标准，该标准定义了必填项、可选项参数，基于DICOM3.0标准中的定义，设备与外部服务之间的信息交互需严格遵循此协议。该文仅列出Worklist 中所涉及到的必要字段，如表1 所示。

表1 Worklist字段

Worklist 的字段是非常丰富的，并不限于以上列举的字段，科研人员可以借助提供的字段（Tag）做更多更丰富的数据类型研究。

3 Worklist配置方法

以目前科室正在使用的设备为例详细阐明Worklist 的配置方法。基于服务器端及超声设备端的配置界面，介绍如何通过C-Find 查询服务实现抓取患者信息的过程。配置由服务器端配置以及设备端的配置两部分组成。

3.1 服务器端配置

服务器端采用Oracle 数据库进行搭建，系统工作模式采用点对点的配置模式，每一台设备存在一条对应独立的配置项。前期需要定义服务器的IP地址、端口号等条件，保证服务器具备与设备间互通的网络要求。并且需要给服务器分配一个SCP的角色，Worklist SCP 的AE-TiTle 和Port需要告知设备，设备上需要配置Worklist SCP 的参数才能正常查询Worklist，作为SCU 设备,需与相对应的服务端配置保持一致，需要和对应服务器端的配置一致。服务器端需根据编码规则定义字段建立属性编码，例如Patient’s Name、Patient ID、Patient’s Sex、Accession Number、Study Descripition、Modality 等，与超声设备上字段对应，从而达到超声设备端抓取患者信息的功能。也可以按照检查室进行配置，利用检查室条件限定只查询当前检查室的患者登记信息。服务器端主要关注的配置点包含服务节点描述、影像接收状态、影像注册状态、AE-TiTle、端口、日志记录。

3.2 超声设备端调试与配置

基于DICOM 协议的介绍，明确要求配置查询/检索服务配置（Query/Retrieve Service Configuration），其中，AE-TiTle（Calling AET/Called AET）为必填配置，负责服务器端的发起接收功能，Called AET 负责主动发起消息。Port 配置（Port Query/Port Retrieve），Port Query 负责检索，Port Retrieve 负责数据取回。同样IP 地址也需要配置，包括设备端的IP 及服务器端的IP 地址。

以现有环境下的超声设备为例，包括具体的配置以及调试过程，从设置、参数调试、调试中产生的问题以及解决方法几个方面进行阐述。以飞利浦的某型号设备配置为例。完整的超声设备Worklist 配置环境包含两部分：第一部分为构建超声设备的网络环境，第二部分为超声设备的服务类创建。参照某机型超声设备说明文档，首先需要配置超声设备“NETWORK/DICOM”选项模块中的基本网络参数。配置IP 地址模式（动态地址或静态地址），对于涉及到点对点传输方式与服务器交互，一般会采用静态地址作为首选。点击静态IP 地址模式后弹出“IPv4 配置”界面，填写参数包含IPv4 地址，子网掩码、默认网关。其次需要建立与Worklist 服务之间的关联，建立与服务器间的互通性关系。关于Worklist 服务类的创建，需要定义创建的类型，在超声设备中Worklist 类型属于“DICOM 工作列表服务器”，因此，需要在设备类型中选择“DICOM 工作列表服务器”，通过输入必要信息来配置设备，其中包括设备名称、AE-TiTle、端口号及IP 地址。因AETiTle 具有对大小写敏感的特性，配置时要求与服务端的AE-TiTle 保持一致性。对高级选项中所涉及的Worklist 的查询频率及查询属性的定义不做严格要求，保存设置后，超声设备提供的Verify 功能可以有效验证与服务器间的连通性。当数据校验完成后，验证信息会提示“通过”；当无法响应远端请求，验证状态则会提示黄色感叹号，并提示验证报错信息，例如“目的地址不可达”或“请求超时”等提示信息，以便为排错提供依据。当Worklist 的功能设置完毕后，需要在设备上定义Worklist 应用于患者列表中的功能配置模块，选择“DICOM 模块”默认会出现“DICOM工作列表服务器”选项，下拉列表中会显示配置的设备名称，选择相应的设备名称保存即可。Worklist 配置流程图如图3 所示。

图3 Worklist配置流程图

3.3 设备调试问题及排查

实施Worklist 项目涉及到的具体问题，归纳起来可分为两大类：一类为网络部分的连通性问题，另一类为通讯过程中服务端储存的日志问题。

网络部分需要确保超声设备与服务器处于同一网段环境，以确保消息能成功被对方接收。最佳办法是通过PING 命令向目的地址发送因特网控制报文协议（Internet Control Message Protocol，ICMP）[10]。超声设备若侦测到对方连接故障，在传输队列中会以状态的形式呈现，如图4 所示。

图4 传输队列状态图

红色⊗标识代表超声设备与目的地址之间连通性存在故障，提示目的地址不可达；绿色标识代表超声设备与目的地址之间连通性正常，所有测试均正常通过；黄色标识代表超声设备与目的地址之间连通性局部正常，某些测试或存在故障。

当出现红色标识，需要查询DICOM 相关配置，其中包括SCP端状态，以及AE-TiTle的一致性问题[11-13]。

当出现黄色标识，首先排除网络环境对于通信造成的影响，然后结合状态提示查看日志进行判断，考虑是否因进程卡死方面的因素导致传输数据堵塞，是否需要清理队列后重新传输文件。

同时，参考服务器记录日志有助于分析患者数据是否有效响应与正常提取。具体排查情况如下:首先是否正常接收设备发送的请求信息，其次解析C-Find 请求是否正常，当所有环节处于正常状态下，发送“获取患者信息”的请求。预约系统是否能正常反馈患者数据给与Worklist 服务器端，是否正常响应C-Find 请求，超声设备是否能正常刷新患者数据到超声设备队列中[14-16]。

3.4 Worklist临床应用效果

启用Worklist 功能后，超声设备按照规定的时间节点刷新患者数据信息，患者只需手持预约单前往检查室，临床医生通过扫码设备扫描患者条形码中的检查号信息，超声设备在Worklist 患者队列中筛选出符合检查号的记录，开始检查即可。科室通过信息化系统与Worklist 的结合，并配合条形码识别设备，减少因人工输入导致的数据错误。

研究发现，通过人工录入患者信息时，错误率约为6.1%（48 800 个案例中有2 928 个错误）。使用Worklist 自动获取的方式，患者数据匹配率为100%的情况下则会发生检查患者/科研患者选择数据错误，而非输入错误。对Worklist 不匹配的一项统计错误率是0.26%（48 800 个案例中有126 个错配），另一项研究中，对于数据源头出现错误的情况（登记患者信息错误）进行统计检查，患者/科研患者的错配率为0.73%（48 800 个案例中有356 个错配），但该数据包括所有错误来源，而不仅仅是Worklist 不匹配的原因。

将患者的信息完全依赖互联网传输的模式形成闭环，不仅可以降低患者信息匹配错误率，而且为未来的科研提供了前期必要的数据支撑[17-18]。对未来依照Worklist 的患者标识进行数据归纳及大数据方向的研究提供了重要支撑。

4 结论

Worklist 是将患者信息从HIS 系统传递到超声设备端的最优采集机制，但这依然无法完美地解决因医生选择患者的过程中出错的问题，该功能只能最大限度地减少发生错误的可能性，减少医生因数据错误而耗费的大量纠错时间。所以为了减少错误的发生率，该研究通过控制患者预约单的模式，同时结合扫描患者条形码ID，并自动获取数据以执行精确模态查询，从而提高数据的准确性，减少临床医生的核对工作，提高检查效率。