单位文秘网 2021-08-23 09:17:06 点击: 次
企业级和部门级的,还有个人级的“医生工作流”。医生调用基本和常规的算法工具施加于不同病种的影像数据时,点击勾画步骤是不同的,调用的知识是不同的,因此,医生阅片工作流是病种病情特定的(Disease/Context-Specific)。
若能用计算机模拟医生阅片操作工作流,实现其尽量多的步骤,就能把医生工作流(包括病种知识和一些操作技能)的步骤尽可能多地客观化到计算机中去。在病种知识库和流技术引擎的支持下,有些医生工作流,在计算机辅助下甚至能通过单次点击(单步化)就可以完成。例如心脏科医生的“冠脉分析”,一次点击可以实现打开病人影像、移除肋骨和血池、做心肌分割、在血管内穿透巡航、测量各种狭窄值、把影像和处理结果与测量数值用合适的方式显示出来、给出报告等。
当病种特定的知识库得以建立,并在计算机模拟医生阅片时调用各种算法的工作流各步骤中得以采用,以这类病种知识库和病种操作流技术为核心所实现的病种特定的“机辅阅片流”(Workflow),形成了阅片循证自动化的基础——这样产生的病种特定“机辅阅片流”,才有可能使医生之前几百上千次点击勾画完成的手工处理,可以通过三五次点击自动完成。
3. 机辅影像循证的智能化
——预处理(Preprocessing)
在当前计算机技术水平下,医学影像中一个“证”的获取往往需要分钟级时间的运算,当有许多“证”要获取时,时间上的等待仍会让影像的直接使用者失去耐心。
若能在各个病例影像到达处理机器、而医生还没打开该病例时,机器就按照扫查时设定的处理要求和影像病种启动病种知识导向的后台处理,自动将影像归类并调配算法工具(AutoSorting),自动运行“机辅阅片流”中的各种算法和知识库展开处理(AutoProcessing)。然后,在医生打开某个病例时将该病例的处理结果按照医生阅片要求的布局自动地展示出来(AutoLayout)——这种智能化的“预处理”加上复查需要的预提取(Prefetch),所实现的病例自动准备,让医生能集中精力于利用病征结果展开诊断。
若没有自动阅片流技术为基础,这种影像循证预处理是实现不了的。因此,以往支持手动三维处理操作的软件,就必须要重新设计——纳入病种知识库和病种操作流,实现自动调取与运行——方能在医生没有点开病例时在后台实施循证预处理。
进而,当面对多个病种类型的处理阅片时,将多个“机辅阅片流”合成为一个“机辅阅片引擎”(Engine),可以开展自动的合成机辅阅片,例如心功能分析,除了包含左室分析,还有右室分析、瓣膜引导等自动阅片流——所有这些阅片流是在该病例影像到来时一起施加上的,其各个自动流的病征结果与调用工具则是在医生点击该病例时同时打开的。这里的病征结果清单是基于数据库的(可称作“病征索引器”),每个自动阅片流条目下的处理工具集则是基于病种知识库和病种操作流的(可称作“病例导航器”)。
医学影像处理技术问世至今已经发展了四代。前三代的共同点是均为“后”处理,即必须在医生打开软件、装载图像后,才能进行处理和分析。当前第四代的最主要特征就是这种智能化的“预”处理,即,在医生打开某个病例之前,就自动调用相关的软件算法对图像进行后台处理,当医生点开该病例时,处理的结果即刻展现在医生面前。
4. 机辅影像循证的智能化——大型数据库
当一个病例中的影像数量达到几百上千幅时,当后台同时在做预处理的病例达到数个乃至十数个时,当对一个病例同时施加的自动阅片流有两三个甚至五六个时,当每个阅片流自动(以及随后阅片过程中的手动)给出的“证”达到几十个乃至上百个的时候……如果没有大型数据库如Oracle或SQL,想要管理数量与种类众多的病例、影像和处理结果是不可能的。
例如,对于某一病例施加的各个自动阅片流(及其后续手工操作)所产生的几十上百条病征所见(Findings),可以建立病征索引器(Findings Navigator)——所有病证所见都自动存储在病征索引器上并建立索引,从而帮助医生列示所有的病征发现与处理结果,能高效评估和管理所有的诊断发现——只要在某个病征结果上点一下,如同书签一样,立刻自动同步跳转到给出该结果的原阅片与测量界面上,并将链接同步的其它序列影像也同步跳转至病征所在的解剖位层(可以是多个序列、多次扫查甚至多种设备类)。
更进一步,可以病种知识库为基础,建立病种类型特定的病证清单(Findings List,欧美多称其为“结构化报告”[Structure Report])模板,在每个阅片流自动运行和手工修正之后,列出医生最后修正确认的所见结果(Findings),给出“按病种结构化的”完整的病征清单,用以支撑放射科报告的结论。所有结果(包括病征截图、测量数值、临床评分)、所引用的知识库(如肿瘤随访是用RECIST评分还是WHO评分),都能总结到该病种特定的结构化病征清单(DICOM-SR)中——结构化报告应该包含该病种临床科室实践中会用到的示意方式(如绘出冠脉树用以指示狭窄位置)(图1)。
5. 机辅影像循证的网络化——服务器运算
若把上述机器智能中的所有计算能力、知识库、算法工具调用等,都放到服务器上运行,将会使网络上该服务器的任何瘦客户端(即普通PC),都能以“并发授权”方式调用这些机辅阅片流及其后面隐藏的病种知识库和病种操作流。
由于各种成像设备产生的影像都可以送到服务器上,各种成像类的算法、知识库和自动阅片流都可以装在服务器上,这种服务器运算使机辅阅片能力可以不局限于扫查设备旁,而是通过网络四处可调,能在更多的场所(如阅片室、手术室等)让更多的医生拥有更多成像类的机辅影像循证阅片能力,即可让医生在任何联网的终端上(如HIS的医生工作站)随意调用多种成像类(Multi-Modality)的影像,并实施多种成像类的机辅阅片。这就实现了同时接入和处理的成像设备类多、调用高级处理智能的用户多、可开展影像循证高级可视化处理的场所多。
而这种网络化具有现实意义的前提,首先是要有智能化的自动阅片流和循证预处理,各种临床位置的医生,在自动阅片流和自动预处理技术的支持下,可以不必耗费时间去自行做巨量的点击勾画处理操作;其次在于全服务器运算支持下的瘦客户端,即算法智能与病例影像全部都置于服务器中,客户端与服务器之间的通讯无需占用影像数据所要求的巨大带宽。
关于机辅影像循证的讨论
1. 影像循证计算机辅助的平台化
就运算核心而言,由于事务管理和影像处理是两种不同的计算处理模型与方式,也由于有多个医生对来自多种成像设备的多个病例执行智能化自动化程度更高的计算处理,还有大量医生尚未点开的病例预处理在后台持续运行,单纯四核或八核CPU计算是无法承担的,所以目前业内的解决方案以CPU+GPU运算架构为主导潮流,即CPU做基本平台的管理(包括影像的传输与存储)和数据库(包括影像病例数据库和结果数据库)的管理,引入GPU(即处理图形专用的高性能运算芯片)专注于高性能影像运算——GPU采用成百上千颗并行运算核并行执行图形语言与算法的基本指标为3D性能(如每秒数十亿次三角形运算)的含上10GB级的图像高速缓存,图像计算语言方面最好能支持OpenGL版本4以上、OpenCL、DirectX版本10以上以及CUDA等。
由于需要配置大型数据库来做数据管理,并需要高性能CPU如四核甚至八核Xeon来运行数据库,因此,需要运行GPU与数据库的服务器,来接入多台扫查设备的数据源并支持多台阅片站对“机辅阅片流”算法智能的调用——影像处理运算平台走入C/S架构时代,即由服务器来承担影像的高性能运算和结果管理,医生调用影像和智能的阅片台成为这种服务器的客户端。服务器的网络管理方面,须能支持Active Directory、SSO和VNC,而医学信息化标准方面,须能支持DICOM、IHE和HL7。
在上述软硬件平台的基础上,服务于影像循证的基本平台功能应该有:基于知识库的病例导航(Case-Navigator),即影像到来后自动实施分类调取、计算处理、阅片布局、阅片流列示和处理工具摆示等;基于数据库的病征索引(Finding-Navigator),即对病征发现做测量创建、收集管理和列表显示,通过病征做索引来同步多个影像序列中同一病征的即时找寻;基于规则库的病人筛选(Patient-Worklist),即基于角色的作业表可按阅片流或影像来驱动,供用户按成像设备、临床领域或身体部位等条件筛选其所需的病例;结构化病征列表(Structure-Report),即把病征发现自动写入某临床应用对应的报告模板中,完整记录病征发现(测量数值、表格、曲线、示意图和影像截图等);角色设置与协同阅片(Role-based AV-Sharing),支持不同用户角色间对于影像与病征发现的分享观察、同步操作等。
使用前述的影像循证高级可视化所用技术的集合以及这所列种种软硬件的重新设计与组合,构成的影像循证计算机辅助新平台,才能真正实现尽量减少阅片循证中的操作处理步骤,并对影像中的各种“证”尽量完整地获取和记录,帮助医生从繁琐复杂的点击勾画和病征结果的管理索引中解脱出来,从而有更多时间专注于病情本身。
2. 机辅影像循证高级可视化软件的再定义
首先,机器辅助的目标已经发生了变化——医生阅片面对的影像越来越多,使影像科之内、影像科室与其它科室(如手术室)之间共享高级处理智能的需求越来越高,需要跨出扫描室来让更多临床场所(如阅片室、手术室、办公室)调用病例影像和算法智能。高级处理的不断普及与复杂程度的不断提高,开始要求阅片医生之间能交流其处理的中间结果,甚至开展阅片协同。
其次,自动阅片流的实现,使上述平台基础构成已经与传统处理软硬件有了极大不同。从影像中所循病征种类的增加,需要增加计算机自动运行的操作步骤,也决定了重新设计机辅阅片流的必要性。
第三,自动阅片流并不能完全替代人工操作,仍需要提供不同于手工处理的处理工具让医生对自动结果做手动细调、增删、修改。正因如此,人机界面与手工处理时所要求的是完全不同的,需要全部重新设计。处理结果的增加和结构化病征列表的给出,需要设计更为有效的病征管理与索引工具。
因此,简单地把影像处理的算法工具和软件从工作站移到服务器上,并不能真正实现影像处理的网络化、智能化。智能化“预处理”自动流软件,需要按病种重新设计。相应地,支撑其运行的平台也需要重新设计。
3. 机辅影像循证的其它讨论
机辅阅片流的改善和创建。机辅阅片流一方面在总结了医学界关于某病种的阅片处理知识后,将这些知识固化到阅片流所调用算法的各种参数设置中,使其得以由计算机自动运行,达成让医生减少繁杂的点击勾画的目的;另一方面,其客户化可设置性,比如算法参数的细调,让医生得以在利用机辅阅片流的高效时,能深入改善自动判读某病种病灶的质量,从而进一步提高机辅效率。这需要更多的临床科研合作,不断改善已有的机辅阅片流,不断创建新病种的机辅阅片流,甚至通过对已有阅片流的组合创建一些新病种的自动阅片流、引擎。
协同机辅阅片。影像医学与临床医学开始出现越来越多的协同需求。例如影像科室高级处理的目的是突出和描述病灶,而手术科室的阅片处理,在此之外还要加上展示手术路径等。这就要求高级处理展示平台应能支持影像科室阅片与临床科室阅片的协同,支持处理中间结果的交流,支持结构化报告的共享,甚至支持对同一阅片流在不同科室使用时的一些算法与处理参数的细调。
广域机辅阅片。以往的广域阅片是由PACS支持,实现的是基本二维阅片,因为三维手动阅片对远程客户端与服务器之间的操作互动要求太高。当新的自动三维阅片平台以自动阅片流和预处理智能化为基础时,绝大部分的操作都能在服务器端基本完成,远程客户端与服务器之间的操作互动要求不高,也不需要把影像数据推送到客户端,以免产生的巨大带宽占用,从而实现在远程客户端上调用中心服务器的影像循证高级可视化智能,实现了广域的三维机辅阅片。
DICOM的高级服务类(SOP)。以上对影像循证高级可视化处理平台的要求,也对与PACS的集成提出了有关DICOM服务类的更多需求,如增强的或综合性结构化报告(Enhanced / Comprehensive SR SOPs)、空间对准(Spatial Registration SOP)、分割存储(Segmentation Storage SOP)等。
多服务器与云服务。当单台服务器发展为多台服务器同时工作、甚至多台服务器在不同地点协同工作时,才能谈得上影像高级处理阅片的“云服务”。目前医学界的实践是,先从含有智能化自动阅片流的单台服务器起步,随着放射医生和临床医生对后处理需求的增加,逐步增加服务器数量,逐步实现各个服务器之间处理能力的“算法授权中央化”,最后构成“影像云处理”。这提供了可扩容、可组合和可不断按需添置的影像循证智能化处理平台解决方案。
总之,影像循证的计算机辅助,在计算技术的发展和大量临床知识客观化成为知识库的条件下,面向心血管、神经学和肿瘤学等不同临床领域,面向CT、MR、MI和XA等不同成像类,产生了大量重新设计的按病种不同的智能化自动阅片流和循证可视化引擎,形成了让这些自动阅片流得以运行的智能化网络化阅片辅助平台,可以让更多的医生在更多的地方调用各种影像循证高级可视化功能,实现更快、更方便、更关注于病情根本现象的阅片。
(本文作者王跃、吴文韬来自四川大学华西医院,茅海萼来自西门子医疗部)
(责任编辑:单位文秘网) )地址:https://www.kgf8887.com/show-168-87227-1.html
版权声明:
本站由单位文秘网原创策划制作,欢迎订阅或转载,但请注明出处。违者必究。单位文秘网独家运营 版权所有 未经许可不得转载使用