[影像技术及PACS] 从技术角度看国内部份PACS厂商

1.背景

天健PACS
较早从事像医院处理体系,为海外系统或设施为OEM方式提供软件模块。天健的PACS里面三维重建、容积重建、血管分析、虚拟腔镜、头部灌注等片段是为此西安盈谷科技之,手术麻醉和重症监护系统是奥迪玛公司之,近期富士增股,为无限老控股方。
军旅医院进驻较多,三级甲等典型用户基本上。华北、华中以及华东业务量超过华海。在西北、华北、东北、华东、华南、华中、京津唐和山东8单事业部,提供各区域之就响应。
重点组成部份:
DICOM 图像服务器 (Image Server) — 用来收、提供与管理医疗影像
医诊断工作站 (Review Station) — 医师用来阅片和于报告
DICOM 网关(Image Gateway) – 将非 DICOM 图像通过数字或者视频方式易成为
DICOM
长途诊断服务器 (Teleradiology server) — 让医生远程用 Web
浏览器还是其他软件看图诊断
尖端专用影像处理工作站– 如三维图像工作站,核医学/PET 工作站
(可能连CT/MR – PET/SPECT 图像融合作用)
RIS 和报告终端
技师 QA/QC 工作站 (Tech-station)
在线、近线、离线的存储设备体系

近年因为工作要,调研了追大吞吐的轻量级消息网Kafka,打算替换掉线上运行的ActiveMQ,主要是为过年的预算日流量有十亿,而ActiveMQ的分布式实现的十分想得到,所以想找一个副分布式的音信网。

EBM岱嘉
总部放在上海市长宁音园区,拥有员工将近130丁,公司为台湾EBM公司的控股子公司主营EBM
PACS同时代理了BARCO 医用显示器、医用投影仪,PHILIPS
医学影像设备(CT、MR、DSA等)
GE 医学影像设备(CT、MR、DSA等),通过 ISO9001 : 2000
认证、ISO13485:2003证明。

以下是情是调研过程被总结的有的学问与阅历,欢迎拍砖。

以有SFDA认证、IHE认证、美国FDA检测、认证证书,PACS相关专利72件。核心技术是
DICOM 3.0 ,拥有自主文化产权:UniSight
数员临床影像系统软件,处理图像于专业!UniRISC
放射科信息保管网软件、EBM Server DICOM 影像服务软件、UniGate DICOM
网关等 PACS 系列产品。
市场主要汇集为上海市,客户为华东、华北地区为多,并生香港、澳门有客户,自己无研发,用之凡台湾之软件与技能,做大陆地域的代办,华东、华北地区市场占有率比充分,产品中全院PACS系统竞争力比较强。

2.基础知识

东软
国内软件业巨头。针对新医改3年内投资8500亿首届之高大市场空间,成立了东软医药卫生业务发展中心,用以协调与推进企业医疗卫生业务的研发及市场工作。该中心主任由东软集团高级副总裁兼首席运营官卢朝霞兼任。
PACS不是其首要发展类,其软件出品要是管理软件、办公软件及各种平台。东软与中国医科大学盛京医院,首都医科大学附属北京天坛医院等国内多下医院合作,从事PACS/RIS项目之研发,软件可dicom、hl7专业(standard),遵循IHE规范(IHE
specification),推出了以影像采集、传输、存储、诊断、报告写和科室管理也主导应用之模块化PACS/RIS系统。

2.1.哟是信息队列

美迪康
出品性状
组件化
产品冲MEDICON-NDK开放性组件开发框架设计,完全实现各个功能模块的组件化。并且独自待以MEDICON-NDK组件接口,任何开发人员都能够支付有而径直坐美迪康系统的零件。保证了出规模的体系而是不断扩展性。
唯独扩展性
出品提供MEDICON-Script二次开发功能,可以行使专业的VB或VC#本子灵活扩展系统机能。并且脚论被得接连数据库,可以调用其他动态链接库,保证了用户用范围的体系而不止扩展性。
工作流程可定制
产品提供MEDICON-Workflow工作流程定制模块,可经简单的布局,使软件适应用户实际工作流程。
累加的疗使用经验
产品总、汇集了美迪康软件多年来当境内大中小型客户的使用经验和报告,在医疗应用方面,实现了国内客户95%之上之急需。
跟另外系统连接方便
出品提供MEDICON-DataAdapter数据适配器以及MEDICON-
ProtocolAdapter协议适配器,可以好之跟其他系统总是。
数码适配器可以透过设置2只数据库中的数目表适配关系,完成数据库里的数码流动。
合计适配器可以装协议适配关系,以适应HL7等各种标准协议。
供WEB图文报告浏览服务,便于报告的全院浏览。

率先,我们来探视啊是信息队列,维基百科里之讲翻译过来如下:

蓝韵PACS
总部要于深圳,致力为医学影像设备和医院信息化管理网的钻、开发、生产及销售。1994年确立以来,共为市场生产了超声、PACS、放射三格外类制品,通过了CMD认证、ISO9001认证、CE
认证。其产品要发生咸数字化超声诊断仪、放射设备、PACS、临床检验设备、血液净化设施,代理产品来西门子、飞利浦、本田等系列产品。
该商家有起单机到掩全院的一模一样系列PACS产品,细分为:1.全院级Full PACS,
覆盖全院的PACS解决方案,包括放射科影像诊断系统、内镜科影像诊断系统、超声科影像诊断系统。将院内所有像设备连接系统,并且支持和医务室HIS、LIS连接。2.科室级Mini
PACS,3.单机影像工作站,放射科影像诊断系统、超声影像管理网、内窥镜影像管理体系

队提供了扳平栽异步通信协议,这意味消息的发送者和接收者不需要而与信保持联系,发送者发送的消息会储存在队中,直到接收者拿到它。

关键运动天涯销售途径,其出品之性价比可以。全国限制外,PACS用户数量不多,主要汇集在华南地区,大多数凡超声工作站用户,没有大型全院PACS样板。

诚如我们把信息的发送者称为生产者,消息之接收者称为消费者;注意定义着的那么片个字“异步”,通常生产者的生产速度与消费者的花速度是未顶的;如果个别独程序始终维持同沟通,那必会发出平等正在在空等时间;如果少单次一样相接运行以来,消费者的平分速度必然要是高于生产者,不然队列囤积会越来越多;当然,如果买主莫时效性需求的言语,也可将信囤积在班中,集中消费。

技巧力量
LW-PACS系统在支持卫生部印发之《医院信息体系基本功能规范》的根底及研发:
称DICOM3.0国际标准
疾名称采用国际疾病分类标准ICD-9以及ICD-10
支撑HIS/RIS网关获取HIS信息;
及10M/S级的深文件传输速率;
有着设备权限和用户权限,根据不同之用户不同之工作站设立分级权限机制;
存储采用在线、离线管理机制,并将告诉与影像集中备份;
数码接收效果:接收、获取影像设备的DICOM3.0与非DICOM3.0格式的形象数据,支持非DICOM影像设备的影像转化为DICOM3.0专业的数据。
图像处理功能:自定义显示图像的相干信息,如姓名、年龄、设备型号等
参数。提供缩放、移动、镜像、反相、旋转、滤波、锐化、伪彩、播放、窗宽窗位调节等力量。
测量功能:提供ROI值、长度、角度、面积相当于数码的测;以及标注、注释功能。
保存功能:支持JPG、BMP、TIFF等多格式存储,以及倒车成DIDICOM3.0格式功能。
治本职能:支持设施中影像的传递,提供同时调阅病人不同时代、不同影像设备的影像和报告功能。支持DICOM3.0的打印输出,支持海量数据存储、迁移管理。
长距离医疗作用:支持影像数据的长距离发送和收取。
网参数设置功能:支持用户从自然义窗宽窗位值、显示文字的轻重、放大镜的推广比例相当参数。
晓管理一些:
约定挂号职能。
分诊功能:病人基本信息、检查装置、检查部位、检查办法、划价收费。
诊断报告功能:生成检查报告,支持二级医生对。支持典型病例管理。
模板作用;用户可便宜灵活的定义模板,提高报告生成速度。
询问功能:支持姓名、影像号等多种形式的咬合查询。
统计功能:可以统计用户工作量、门诊量、胶片量以及支出信息。
运作要求:
共享医院消息体系受患者信息。
纱运行:数据以及消息准确无误可靠,速度快。
康宁治本:设置访问权限,保证数据的安全性。
树立保险的存储体系及备份方案,实现病人信息的悠长保存。
喻体系支持国内外通用医学术语集。

说交此,我们再来谈谈队排的归类,一般我们根据劳动者和消费者的两样,可以管班分为三类:

天鹏恒宇
总部在北京,成立于 1996
年,现有职工130不必要称作。产品及解决方案包含:软件出品(HIS-TPHY医院管理信息体系、LIS-TPHY医院实验室管理体系、PACS-TPHY医学影像传输和储存系统、RIS-TPHY放射科管理网、CHIS-TPHY妇幼保健管理网、新型农村合作医疗、医院办公OA系统、医疗触摸导医系统)、硬件产品(TP3000多元医疗装备漏费控制体系、TP医院排队让号网)等世界。

首先好像是于一个应用程序内部(进程中还是线程之间),相信大家模仿多线程时犹勾了“生产者消费者”程序,生产者负责生产,将生产的结果放到缓冲区(如共享数组),消费者于缓冲区取出消费,在此间,这个缓冲区就足以称之为“消息队列”。

随DICOM
3.0、HL7正式,支持Query/Retrieve,可让外系统访问,兼容性较好。支持语音录入的稽审意见,同时拥有助测量功能。

第二类其实呢终于在率先好像的特例,就如我们欣赏管操作系统和应用程序区别对待来拘禁,操作系统要处理过剩繁杂的物,各进程、线程之间的数据交换少不了消息队列的支撑。

协作医院共逾1000家,客户要集中在京城、天津、河北、山西、内蒙古当都滨地区。产品线比较多

老三接近是更通用意义及的“消息队列”,这类似队列主要作用为不同采取,特别是跨机器、平台,这让多少的置换更加大,一般同样款款独立的行列产品除外实现信息之传递外,还提供了相应的可靠性、事务、分布式等特色,将生产者、消费者从中解耦。常见的花费队列产品基于开源与否而可分为两好像:

FUJIFILM(富士医疗)
富士医疗器材(上海)有限公司是由富士胶片株式会社(FUJIFILM)直属的富士胶片中国投资公司组建的治疗事业子公司,于2005年4月1日于炎黄上海专业建立,代表FUJIFILM全权负责其诊治有关制品以中国地区底行销和为所销售的出品提供售后技能劳务。医疗影像事业啊FUJIFILM的重大工作有。截止2007年
上半年,FUJI Synapse®在全球之用户(科室级以上)已经超越了1200贱诊所。
FUJIFILM的PACS产品:Synapse®
作为全球率先缓慢完全依据Web的PACS系统,产品遍及美国、日本、加拿大、欧洲、拉美、南美、大洋洲、东南亚、中东、南非齐国家及所在;FUJI
Synapse®连续多年每当日本和欧美市场占有率比高,

专有软件:IBM WebSphere MQ,MSMQ…

FUJI
Synapse®的研发核心在美国斯坦福德(首席架构师和主要设计人员全都为中国人),在旧金山暨东京存图像处理的钻研机构,在上海树立了特别的技巧骨干。10月份跟天健一起与了杭州中放会,4单标展做特装,在我们展位之后,只展示了放射类仪器,10月份列席成都医博会,10月份参加成都医博会,4号馆特装展位做了双层,FUJI
Synapse®主要突出其Web技术,这项技艺对纱的依赖性较生,是前景PACS类软件的进步趋势,但即便现阶段牵线的事态来拘禁,国内还未曾同款真正的因Web的软件。

开源软件:ActiveMQ、RabbitMQ、Kafka…

华海医信
服务器分级体系架构的性状:
网整体可用性比相似就依靠硬件的可用性高,多种招数保障系统的匪停顿运行及在线升级维护
系灵活,可以因医院的莫过于用,以及工作转移灵活调整。例如,如果制止初期投资规模,中心服务器可以利用单机,利用科室服务器作为核心服务器的故障转移服务器。
轻扩展以及提升,便于维护,可以做到无停顿业务的保护。
于高之属性价格较,例如,如果科室服务器和主导服务器处于两地,不用多投资,就好实现服务器的外地容灾
冲先进的64位乘除平台,采用嵌入式数据库开发技术,提供一流之习性
但伸缩的体系系统布局,影像访问速度不依照时间推移和访问数之增加而产出鲜明的骤降
利落的恢宏能力,避免无止境的硬件升级
客户端站点扩充,可以安装多独放置服务器
运用扩展(例如超声),可以一直添置前置服务器,基本无欲针对骨干服务器进行重新部署
晋升前置服务器也只是要是系统完全性得到比较生的晋级,而平常前置服务器的升迁成本远小于中心服务器
趁时间推移,现有服务器可以降使用,保护投资

2.2.JMS与AMQP

锐珂
用户反映锐珂特点
护次数少;再增长设备多数凡是柯达的,使系统稳定好好
工程师(总部)远程维护、升级
叫高度可调,任何模块都只是个性设置
粗略,一目了然,易用度大
开行电脑即使进入好的电脑桌面(也不怕登陆界面),原电脑桌面禁用,只展示任务栏,进入普通电脑桌面需管理员密码
网设置了后当有的顶峰上全为同一工作站快捷图标,且总的一味出一个,通过不同的系统用户模式加载相应的工作站界面
可当旁极端进行管制、系统监控,以管理人用户模式加载系统

哼了,对于上述第三看似“消息队列”,要当不同之机械中提供信息队列的功力,那必将要来联合之标准,这时候SUN就超过出来了,作为跨平台的JAVA势必也只要支持过平台的消息传递,基于这,SUN提供了一样效仿消息标准:Java
Message
Service,缩写JMS,但是及时套规范定义的凡API层面的正规,在JAVA体系中可好便利的交换,但对其他平台即需要,可能用消息队列产品本身支持多谋(如OpenWire、STMOP)。

 

一旦AMQP定义之比JMS更加底层,从名字便可知看出来(Advanced Message Queuing
Protocol),它定义之是Wire-level的商谈,天然具有超过平台、跨语言的性状,基于这实现之音讯队列可以跟其它支持该协议的阳台相互。

一样栽是JAVA层面的API,一种植是Wire-level合计,这是JMS和AMQP最本质之区别;同时少栽标准还有个别独比较明白的出入:

无异于凡是消息传递模型;JMS比较简单,支持有限种最通用的Peer-2-Peer、publisher/subscriber;通俗点就是点对点与播音模式;而AMQP定义的更是复杂,其定义了扳平栽exchange&binding机制,由此支持五种植模型:direct
exchange、fanout exchange、topic exchange、headers exchange、system
exchange,本质上同P2P、PUB/SUB一样,但是越细心些。

其次凡支撑的音类型,JMS支持多信息模型:TextMessage、MapMessage、BytesMessage、StreamMessage、ObjectMessage、Message等;而AMQP只有byte数组。

2.3.ActiveMQ

ActiveMQ是基于JMS实现的Provider(可以知晓为队列),它支持多协商,如OpenWire,Stomp,AMQP等,基于这,支持多平台;支持工作,支持分发策略、还有地方的强信息模型。这里我们不细谈ActiveMQ的各国特性,我们根本来看ActiveMQ的分布式模型。

ActiveMQ支持分布式,它支持Master-Slave提供高可用,也支持Broker-Cluster提供负载均衡,但是她的负载基于相同种Forwarding
Bridge机制。

以这种体制下,任意时刻一长达破只会受一个broker持有,producer发送的信,可能会见通过多只broker转发最终才会到consumer,可以想象,当broker越来越多时,几乎每次花都使透过转发,效率会明显减退;并且在这种复杂逻辑下,任一broker的进入和移除都显得十分复杂;这有限点是自我莫建议以ActiveMQ分布式集群的根本原因。

Java架构进阶群:554355695

3.Kafka

哼,我们最终来谈今天之主角Kafka,这个奇怪的名我始终没有找到典故,也许是开发者暗恋女孩(基友)的名字吧^_^,Kafka由linkin开发,最初的目的是为着允诺本着linkin庞大之活动流数据(登录、浏览、点击、分享、喜欢等),这一部分数量容量庞大,但是可靠性要求不愈,故而通过牺牲局部可靠性(这并无是说俺们的多少会依照百分比丢,我们后更出口)来提升吞吐量;它伐掉了成百上千复杂的特征,如工作、分发策略、多种信模型等;通过自特有的规划以消息持久化到磁盘上,以此同时支持在线与离线消费;并且该原貌为分布式而设计,压根就是从未有过单机模式(或者说单机模式是分布式的特例),能够很好的壮大。实际利用中,Kafka可以为此来开信息队列、流式处理(一般做storm)、日志聚合等。

3.1.架构

Java架构进阶群:554355695

我们先行宏观之探访Kafka的架,Producer集群通过zookeeper(实际被描绘的是broker
list)获取所形容topic对应的partition列表,然后逐一发送信息(支持自己实现分发策略),broker集群负责信息之贮存和传递,支持Master
Slaver模型,可分布式扩展;Consumer集群从zookeeper上得到topic所当的partition列表,然后花费,一个partition只能于一个consumer消费。Name
Server集群(一般是zookeeper)提供名称服务等协调信息。至于什么是topic,什么是partition,我们对接下去看。

3.2.Topic

Topic是生产者生产、消费者花的队标识。一个Topic由一个要多只partition组成,每个partition可以独立在一个broker上,消费者可往任一partition发送信息,以此实现生产的分布式,任一partition都可给还只有叫一个消费者信息,以此实现消费之分布式;因此partition的筹划供了分布式的根底。

Java架构进阶群:554355695

又,从达成图我们吧会窥见这种设计还有一个亮点,因为每个partition内的信是稳步的,而一个partition只能被一个主顾花,因此Kafka能提供partition层面的消息有序,而传统的行列在差不多只consumer的事态下是截然无法确保平稳的。

3.3.消息传递模型

传统的信息队列最少提供零星种信息模型,一栽P2P,一栽PUB/SUB,而Kafka并不曾这样做,巧妙的,它提供了一个消费者组的定义,一个音讯可以于多只买主组费,但是只能于一个买主组里的一个买主花,这样当只有出一个客组时就相同与P2P模型,当在多只买主组时就是PUB/SUB模型。

Java架构进阶群:554355695

3.4.信息持久化

森系统、组件为提升效率一般恨不得把持有数据还抛到外存里,然后定期flush到磁盘上;可其实,现代操作系统为是这么,所有的现世操作系统还愿意以空闲内存转作磁盘缓存(页面缓存),想不要还难;对于如此的系,他的多少在内存中保存了千篇一律份,同时为以OS的页面缓存中保存了相同客,这样不但多矣一个手续还叫内存的使用率降低了一半;因此,Kafka决定直接运用页面缓存;但是自由写副的频率特别缓慢,为了掩护彼此的涉嫌依次还索要分外的操作以及存储,而线性的形容副足免这些,实际上,线性写入(linear
write)的快慢大约是300MB/秒,但继写副却偏偏发生50k/秒,其中的别接近10000倍。这样,Kafka以页面缓存为中的计划于管效率的同时还提供了音讯之持久化,每个顾客自己维护当前读取数据的offser(也可是托为zookeeper),以之而又支持在线与离线的花费。

3.5.Push vs. Pull

对信之费,ActiveMQ使用PUSH模型,而Kafka使用PULL模型,两者各有利弊,对于PUSH,broker很为难控制数据发送给不同消费者之速,而PULL可以由消费者自己主宰,但是PULL模型或造成消费者以从来不音信的气象下盲等,这种场面下得以通过long
polling机制缓解,而于几乎天天都发出消息传递的流式系统,这种影响好忽略。

3.6.可靠性

正巧说Kafka牺牲了一部分可靠性来提升吞吐量,很多同班或担心信息之遗失,那么我们本来瞧各种场面下的可靠性。

Java架构进阶群:554355695

对于如果齐之模子,我们分开来拘禁,

先来拘禁信投递可靠性,一个音如何终究投递成功,Kafka提供了三种模式,第一栽是啥都未任,发送出就当做成功,这种场面自然不克确保信息成功投递到broker;第二种植是对此Master
Slave模型,只有当Master和享有Slave都接受及信息时,才算是投递成功,这种模型提供了高高的的送可靠性,但是损害了性能;第三栽模型,即如Master确认收到信息就是投递成功;实际行使时,根据使用特性选择,绝大多数情况下还见面受到与可靠性与特性选择第三栽模型。

咱们再来拘禁信于broker上之可靠性,因为消息会持久化到磁盘上,所以只要正常stop一个broker,其达到的数额不见面丢掉;但是只要非健康stop,可能会见使在页面缓存来不及写副磁盘的信息丢失,这可以经过配备flush页面缓存的周期、阈值缓解,但是同样会频繁之抒写磁盘会影响属性,又是一个选题,根据实际情形部署。

随即,我们又看信消费之可靠性,Kafka提供的凡“At least
once”模型,因为消息之读取进度由offset提供,offset可以由消费者自己维护为堪维护以zookeeper里,但是当消息消费后consumer挂掉,offset没有就经常写回,就有或产生再次读的气象,这种情况一样可以透过调整commit
offset周期、阈值缓解,甚至消费者自己管消费及commit
offset做成一个政工解决,但是如果您的应用不在乎重复消费,那就算索性无设化解,以换取最要命的特性。

末尾,我们又来拘禁zookeeper的可靠性,很明显,他使悬挂了,一切都收了,地球就毁灭了,人类就灭绝了,星级穿越也挽救不了了……所以加强可靠性的法子尽管是管zookeeper也配备变为集群。

3.7.性能

吓了,说了那么多,我们实际上来测试下Kafka在各种场面下的性能,为了对比自己为测量了产单机模式下ActiveMQ的性质,不过是因为疲劳,没有搭建ActiveMQ集群进行测试,但是依据该恶意的Forwarding
Bridge模型,我吗操悲观态度。

率先,测试环境如下:

Kafka:3 broker;8核/32G;默认配置

ActiveMQ:1 broker;8核/32G;默认配置

Producer: 一光机械通过多线程模拟多producer;8核/32G;默认配置,异步发送

Consumer: 一雅机器通过多线程模拟多consumer;8核/32G;默认配置

除开特殊说明,生产及花又拓展。

接下来,我动用如下字符表示各种测试条件:

1T-1P3C-1P1C-1KW-1K:

1T:1个toipc

1P3C:1个partition 3个replication

1P1C:1个producer 1个consumer

1KW:1千万长达信息

1K:每个消息1K

自家先行对ActiveMQ在单机多Producer、多consumer的情下之测试,结果比我想象中的好,官方的于有底一个数量是1-2K底多寡,每秒10-20K独,这样算是下来大概30-40MB/S,而测试的结果在多线程的场面下会重复好把。

Java架构进阶群:554355695

接下来我又针对Kafka进行了相应的测试,用一个partition模拟单机模式,结果及预期的一样,在单机模型下,两者反差不要命;而官方给的数目说生产者能达到50MB/S,消费者能达到100MB/S,生产者符合法定数据,而消费者本身尽没有压到那么强的进度。

Java架构进阶群:554355695

属下的对Kafka集群,我思念同一数额的消息会不会见以topic数目的充实而影响,测试结果如下,表明topic越多,速度会所有下滑,也切合预期。

Java架构进阶群:554355695

下一场以测试partition对性能的熏陶,进行了之类测试,可以看来partition数量更为多,总的产和花速度越快;但是殊不知之是Only
produce情况下生产效率没有强烈提升反而略慢,这里怀疑以及page
cache有关,没有深刻钻研。

Java架构进阶群:554355695

综上,我们可见到Kafka的性质与吞吐是可以扩展的。

3.8.风险点

于我们吧,Kafka主要出个别个风险点,第一,要深刻应用要要熟读源码,而kafka源码是故scala写的,我们连无对号入座的技术储备,需要学习;第二,kafka技术于新,目前之版本是0.8.1.1,看起还不绝成熟。

4.KG应用

当下同样块是以铺子内部系统的利用,不适合对外,所以这边去。

5.参考资料

Kafka-DOC:http://kafka.apache.org/documentation.html

ActiveMQ-DOC:http://activemq.apache.org

Understading the differences between AMQP &
JMS:http://www.wmrichards.com/amqp.pdf

WIKI-MQ:http://en.wikipedia.org/wiki/Message\_queue

WIKI-JMS:http://en.wikipedia.org/wiki/Java\_Message\_Service

WIKI-AMQP:http://en.wikipedia.org/wiki/Advanced\_Message\_Queuing\_Protocol

发表评论

电子邮件地址不会被公开。 必填项已用*标注