云胶片(云影像)的接入 关键字段的理解

文章适合厂商系统工程师和院内信息科运维人员

1 标准概念

先讨论下DICOM和IHE 中的一些基础概念，

   Accession Number 也叫流水号，在General Study Module中，是如下描述的Accession Number A RIS generated number that identifies the order for the Study.用来标示一个检查的送检单，这个号是由RIS生成。一定是标示送检单的。

     我们再从IHE RAD中找到

    Order: A request for an Imaging Service

    Requested Procedure: Unit of work resulting in one report with associated codified, billable acts.

    Scheduled and Performed Procedure Step: the smallest unit of work in the workflow that is scheduled (work to do) and/or performed (work done).

      In the IHE Scheduled Workflow, the Accession Number identifies the Order. The requested Procedure ID distinguishes among Requested Procedures when an Order requires multiple Procedures. IHE sets a common meaning for these two terms to provide clinicians with a consistent and non-ambiguous access across different vendor products (RIS, PACS and Modalities).

      Each Filler Order may contain one or more Requested Procedures. Each Requested Procedure is identified by a Requested Procedure ID that needs to be unique only within the scope of the Filler Order Number/Accession Number.

      每个Order中包含一个或者多个Procedures，并且在每个用Accession Number标示的Order中，每个procedure都用Request Procedure Id来标示唯一。

      A single Requested Procedure of one Procedure Type is the highest hierarchical unit of work level that may give rise to the creation of a report. Each report is one of the results produced to satisfy the order. For example, in a case of the order for an X-ray examination of a patient daily at 8 am for the next three days, each of the daily examinations will require a separate diagnostic report; hence each of them will be treated as a separate Requested Procedure. In order to support DICOM Query/Retrieve mechanism and easy collation of all results pertaining to a single procedure，Order Filler also generates the Study Instance UID, a globally unique identifier for each Requested Procedure. This identifier will be used to identify all generated images and other DICOM objects related to this Requested Procedure.

      所以，我们从上边的描述中，可理解，一个Order包含1个或者多个Requested Procedure，每个Requested Procedure对应一份报告。例如，一个医生开出连续三天内，每天的8AM进行X线检查的送检单（Order），那么，每天一次的检查就是一个Requested Procedure，而且，每天都要针对检查出具独立的报告。那么，每个Order用Accession Number来标示，Requested Procedure用Requested Procedure ID来标示。另外，为了将此次检查的所有的结果，如报告、影像，和Requested Procedure产生关联，Order Filler角色还产生一个Study Instance UID，用这个UID将会用来标识所有的设备产生的图像和其他角色产生的DCM对象（例如gsps，报告，二次重建图像等）。

         可以将这些关系，根据标准的一个关系图，绘制了一份相对简单的关系的实体结构图。

标题实体关系结构图

2 实际项目情况

        上边是IHE对所有系统的流程的一个精确的定义，但实际项目中，由于很多厂商的工程师理解的差异，进而他们的程序流程也是不一致的。

         首先，一个比较严重的问题就是RIS生成Study Instance UID，设备厂商不采纳问题，或者生成多个Study Instance UID，导致影像和Requested Procedure登记信息不匹配问题。

         解决这个问题之前，我们先介绍下，Q/R工作原理。一般来说，设备工作站都定时的去按照时间段或者设备类型或者AETitle去RIS中查找任务，在查到的待检任务中，有个重要的信息Study Instance UID，也就是第一节中，用来标识和Requested Procedure对应影像的UID。基本上，所有的厂商都是这么做的。

    但也有例外，如，万东核磁，完全不采纳RIS生成的Study Instance UID，自己生成一个其他的UID。但是，这个设备会使用Q\R中的Accession Number，也就是用来标识Order的号码。为了纠正这个错误，RIS可以将Request Procedure ID当做Accession Number格式发送给设备，后期，我们就可以用DCM中的Accession Number和Requested Procedure ID进行对比进行合并。

         国外GPS三家设备相对规范。不过也有例外，在江西碰到一台版本比较老的飞利浦DR，这台设备，会在一个检查中，生成多个Study Instance UID，第一张图是正确的Study Instance UID，其他张数，就会自己生成不同的Study Instance UID号，通过对比DCM信息，发现只有Patient ID一直都没发生变化。所以，RIS将Request Procedure ID当做Patient ID，后期，通过DCM文件中的Patient ID和RIS的Request Procedure ID进行合并。

         另外，国内很多小厂商，工作站的软件做的很没法形容，自动生成的ID号，会重复，例如贝斯达，发送PACS图像会无故失败；还有些小厂商设备生成的关键号，都是一个号，个人感觉这都是研发投入不够导致的所导致的。不过好在现在有写大厂崛起，迈瑞，联影，东软，安科，奥泰对接起来都还是很规范的，反正这个UI用来，无论设计上，还是操作上，都是有下了功夫的。

         另外，还有一类错误是由"人祸"引起的，导致合并出现问题。例如，重拍、追加其他部位检查、急诊、夜诊，医师会直接在设备端登记操作，这样，设备上可能会生成多个或者不同的Study Instance UID，Patient ID和Accession Number，如果以上的DCM信息中关键Tag，都和之前登记信息不相同的话，就只能医生手动合并或者补录。如果有其他的信息一致，就可以通过其他信息方式进行合并。

    所以，虽然在IHE中定义，Request Procedure ID、Study Instance UID都是和Request Procedure是一一对应的，一个Request Procedure对应写一份报告。但是，在实际的项目中，最严重的问题就是一个Request Procedure对应多个Study Instance UID的影像数据，这样，实际RIS中的静态表结构可以设计成如下静态结构。

标主表静态结构

3 合并策略

        在院内PACS的场景中，如何获取HIS信息并且和设备的检查影像正确合并是一个很重要的设计内容，主要的设计思想也就是如何去适配各种设备厂商的影像设备，常规的可根据Study Instance UID合并，其他的方式可根据AETitle或者Modality将RIS生成的Requested Procedure ID替换成 Accession Number或者Patient ID，设备生成图像后，在反向规则合并。

         这种场景应用方式，都是从PACS影像数据合并到RIS的登记信息上。目前，所有正规的PACS厂商也可以直接通过配置来完成。

         但是，今天说重点是云胶片项目。云胶片项目基本上都是直接对接院内PACS系统的。需要收集三方面的信息，一是病人信息和报告信息，其次，是PACS的影像信息，最后是通过虚拟打印机截取打印的信息。一般来说，为了保证数据的完整性，最少应当接入1和2、2和3、或者1和2和3. 最好是1和2、1和2和3的组合方式。

         一般对接的方式都是院内PACS开放一个视图，并且根据视图来CMOVE影像数据到云端。但是，当信息到达云端时，并不能保证视图信息一定比图像信息先到达。所以，这是需要解决将登记信息合并到图像信息上的问题。

         另外，当虚拟打印机的信息也发送云端时，如何和原有的信息进行合并，也会有信息到达云端先后的问题，都是需要设计程序时，需要考虑的问题。