大家好，我是帅气小伙。前段时间忙于实施医疗集团信息化的事情，太久没更文了，刚好今天更个文章梳理一下前段时间关于影像中心建设的一些感悟。很欢迎大家一同探讨。
为什么选择orthanc？
orthanc是一款能够提供RESTful API 的迷你影像服务器，orthanc提供了数据库存储dicom索引的插件（Postgresql，Mysql，SQLlite），它大大降低了技术开发的难度，开发者并不需要了解太多的dicom协议的知识，便能轻松应对dicom的图像的检索，dicom图像的存储，dicom图像的压缩，dicom图像的转发。因为他们面对的都是他们熟悉的东西，Http接口和关系型数据库；另外一方面，从软件实施的难度来看，orthanc提供了windows安装包，在应对医院前置机配置也是游刃有余（最糟糕的XP系统同样能兼容）
Dicom存储的难度
1.dicom图像的大小直接导致了存储成本的提高，虽然硬盘不贵
2.dicom如果使用分布式存储将提高检索难度。
3.dicom图像的管理如果采用分布式存储将会变得困难，假如要删除一次检查图像。
4.如果采用传统的HDFS这样的存储方式，开发接口将面对的是一堆未可知的问题，这并不是一堆简单的文件，需要从里面提取图像信息（根据检查号查询图像）。
5.dicom存储同样也存在网络带宽问题，影像中心到底需要多大的带宽？
问题分析
1.dicom文件的分布式存储是必然的，一组dicom图像可以把它看成是数据块（study），存储的时候不需要将它拆分，因为一旦拆分了，检索的时候很可能是大海捞针一般。
2.dicom图像的接收可以理解为点对点的传输，如果是相对于影像中心的概念，很可能是一点对多点的模式，因此对于接收节点的压力是很大的（在自动传输的情况下），并且接收节点同样也面临了磁盘使用率过高的情况，很容易造成磁盘坏道的情况。
云存储技术方案设想
1.影像中心层级结构
层级结构
1.采集层：部署在院内，负责影像的采集，图像来源可以来自设备和pacs系统
2.存储层：部署在云服务器上，负责影像图像的接收和存储
3.查询层：部署在云服务器上，负责开放对外接口（检索图像，查看图像...）
2.dicom图像分布式存储设计
分布式存储设计
采集层
自动转发：在接收到设备或pacs转发图像后，马上向影像中心转发。orthanc的技术实现是基于lua脚本。例如
function OnStoredInstance(instanceId, tags, metadata)
-- Ignore the instances that result from a modification to avoid
-- infinite loops
if (metadata['ModifiedFrom'] == nil and
metadata['AnonymizedFrom'] == nil) then
-- The tags to be replaced
local replace = {}
replace['StationName'] = 'My Medical Device'
-- 可以在此设置一些自定义的Tag，例如医院标识号等等
-- The tags to be removed
local remove = { 'MilitaryRank' }
-- Modify the instance, send it, then delete the modified instance
Delete(SendToModality(ModifyInstance(instanceId, replace, remove, true), 'sample'))
-- Delete the original instance
Delete(instanceId)
end
end
手动转发：基于orthanc的RESTful API 可以实现手动转发
orthanc RESTful API
存储层
基于docker容器技术，快速实施部署和节点监控，目前的k8s技术已经相当成熟了，无论是节点的存储，节点的网络拓扑构建是相当的出色了。
orthanc dockerfile
环式节点转发存储
这个设想主要是考虑到，将接收节点的压力分发到各个节点，但是如果链太长，很容易图像在数据链路中丢失，这里可能会有更好的设计思路。
环式节点转发
orthanc采集上传流程.png
技术可行性
lua脚本关键回调
lua脚本可以通过命令行调用python脚本实现对于业务系统的对接。例如节点注册，节点销毁。
dicom图像连续性保证，在图像传输的情况下，假设有一个18张图像的检查，A节点已经存储了17张，但是磁盘使用超过了80%，按照我设计的链式转发规则，它应该存储到下一个节点。在转发之前，我们只需要知道当前节点是否存在与这张图像的检查号（studyid）相同的图像，再确认转发即可保证图像的连续性。这里预留了10%的磁盘空间就是为了应对这种情况。
dicom存储服务扩容，存储始终都会有溢出的一天，我们的运维要及时发现，快速解决，采用链式存储，最终由溢出节点回到原点并触发接收节点溢出告警，由于一开始转发节点不存储图像，有足够的缓存时间去扩容。采用链式存储的扩容其实很简单，再启动一个转发节点，配置它的转发节点即可，然后再把这个新启动的转发节点的ip更改即可。
查询层
经过了存储层和采集层的搭建，这里已经初步解决了dicom图像存储问题，下一步就是对dicom图像的检索了。其实这就是一个分布式数据源查询的问题。
简单的设想
开发影像接口从此回到了关系数据库接口开发。
影像查询服务功能
总结
这是一个设想，没有真正实施过，希望有这一方面使用的朋友，批评指正，我也希望这个方案能够真正的实施落地。
网友评论