影像循证的计算机辅助
ȧi@b .Ǭ)h-yr iD{ixN%y$ Ewb wb
jj+Ewb REhbاDXs"http://www.xcysycw.com/k/zongjie/" target="_blank" class="keylink">总结到该病种特定的结构化病征清单（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等不同成像类，产生了大量重新设计的按病种不同的智能化自动阅片流和循证可视化引擎，形成了让这些自动阅片流得以运行的智能化网络化阅片辅助平台，可以让更多的医生在更多的地方调用各种影像循证高级可视化功能，实现更快、更方便、更关注于病情根本现象的阅片。
（本文作者王跃、吴文韬来自四川大学华西医院，茅海萼来自西门子医疗部）