云胶片(云影像)和PACS的接口

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

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 院内RIS/PACS数据合并原理

        上边是IHE对所有系统的流程的一个理论上的定义，实际项目中，大厂商还是基本上以上述的方案进行实现的。但是，很多国内的信息化公司都是在开发RIS系统，RIS特点是技术低门槛，业务高门槛，定制度高；PACS系统都是外购或合作，明显是技术高门槛，业务定制度低的特点。反过来也是项目的市场导向占的比重大，倒逼厂商最终这么搭配开发人员，在医疗行业待久了，我相信大家肯定都明白现在项目是怎样做的。这样就导致，RIS/PACS厂商很多时候，合并RIS登记信息和影像信息时，就很牵强。另外，一个比较严重的问题就是RIS生成Study Instance UID，设备厂商通过Worklist获取后，不采纳问题RIS的StudyInstanceUID，而是自己生成一个Study Instance UID，甚至多个。导致影像和Requested Procedure登记信息不匹配问题。实际上，实施院内RIS/PACS系统时，很多工作也都集中在HIS，RIS，PACS，设备之间的信息对应上，排队叫号也会涉及到和这些信息的对应。

         解决这个问题之前，先介绍下，Q/R工作原理。一般来说，设备工作站都定时的去按照时间段、或设备类型、或AETitle去RIS中查找任务，在查到的待检任务中，有个重要的信息Study Instance UID，也就是第一节中，用来标识和Requested Procedure对应影像的UID作为当前的检查生成Dicom图像中的StudyInstanceUID。基本上，所有的厂商都是这么做的。但也有例外，如，万东核磁，完全不采纳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图像会无故失败；还有些小厂商设备生成的关键号，都是一个号，个人感觉这都是研发投入不够导致的所导致的。不过好在现在有写大厂崛起，迈瑞，联影，东软，安科，奥泰对接起来都还是很规范的，也反应出厂商在研发人员的投入上。

         最后，还有一类错误是由"人祸"引起的，导致合并出现问题。例如，院内技师重拍、送检医生的追加其他部位检查，以及急诊、夜诊，医师会直接在设备端登记操作，这样，设备上可能会生成多个或者不同的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中的静态表结构可以设计成如下静态结构。

主表静态结构

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

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

3 云胶片和院内PACS对接方案最佳实践

          院内RIS/PACS开放检查视图，进而获取当前检查对应报告以及相应影像的相关信息，这些信息可能是StudyInstanceUID，AccessNumber, PatientID, 如果是StudyInstanceUID可以直接通过CMove，将影像获取到。如果是其他信息，也可以通过C-FIND先将对应影像的UID查询到，然后，再C-MOVE。

          虽然，这个方法比院内PACS转发影像优点有很多。假使对方没有CMove，最好也叫对方提供一个ftp，或者下载地址，也比转发影像要好。  

         1 因为CMove是主动获取影像，这样，就可以在对方闲时获取影像，保证资源不够的院内PACS运行正常；

         2  如果检查的影像有补拍或者三维重建的影像，可以再次获取影像，以保证影像的完整性；

         3 转发的情况，必须保证双方服务7X24小时都在线，而CMove没有这么严格的要求。如果院内信息系统宕机，包括PACS或接口程序，或院内停电导致的图像没有上传情况，CMove都可以保证在系统恢复正常后，将这些图像获取上来。

         总之，在发生问题后，主动获取的方式，云胶片厂商自己就可以很容易的排查问题，如果是转发，就需要双方一起配合，解决问题速度会慢很多。不过，现状是很多PACS厂商，都没有提供这个服务，但是，基本上传统大厂都还是可以提供这个服务，例如，东软，英飞达

         另外，通过虚拟打印机的方案（无感接入的方案）是被我们抛弃的方案，这个方案优点是无须和院内PACS进行对接，缺点也很明显，首先是实施部署复杂，其次出错率高，需要大量的运维工作，得罪客户后，都是技术的锅。所以，本来是销售和商务要去沟通接口的事，技术通过无感接入的方案，给自己挖了个坑，自己跳下去，获取了产品不行的"美誉"和每天几次日常运维。所以，该商务办的事，还是叫他们去办好了，哈哈~~~~~~。