[发明专利]医学成像中独立的系统/应用程序间共享进程的体系结构

说明书

本发明披露了在医学成像系统中共享进程的方法和系统。提供了第一应用程序系统，它能够在第二应用程序系统内处理数据。位于第二应用程序系统外部的进程共享系统被设置成能够实现在第二应用程序系统内的第一应用程序系统的进程共享。第一应用程序系统包括前端单元，它在事件发生后可通过进程启动器在第二应用程序系统中进行操作，以便于经由预定接口通过与进程共享系统进行通信来处理从第二应用程序系统获得的数据。进程启动器由进程共享系统生成，并且部署在第二应用程序系统上。

相关申请

本发明要求申请日为2007年9月14日的临时专利申请号60/972,403的优先权，该申请的全部内容在此被结合入本文引用。

技术领域

本发明涉及独立的医学成像系统之间的进程共享。

背景技术

在医学成像中，患者数据可以用不同的应用程序进行处理和浏览。需要在同一台计算机上的所述独立应用程序之间共享进程，以确保顺畅和整合的工作流。例如，在一个应用程序中，用户可能希望使用另一个专用的应用程序来进一步分析患者数据。为此，通常，不同应用程序之间的代码级整合是常用的解决方案。例如，专用的计算机辅助检测(CAD)系统识别可疑区域的位置并且提供交互式工具，从而以不同的方式评估感兴趣区域(ROI)。影像存档和通信系统(PACS) 是保存和浏览医学影像的专用平台。一种启用特定目的应用程序(如CAD系统或 PACS系统上的3D可视化系统)的方式是在PACS和应用程序系统之间进行代码级整合。例如，可以将指定的按钮设置在PACS图形用户界面(GUI)上，而点击该按钮可以激活CAD应用程序，以便用由CAD系统提供的工具来分析患者数据。不过，独立系统之间的代码级整合只能在某种程度上解决所述问题。考虑到市场上有多种特定目的应用程序和PACS系统这一事实，整合这些系统需要每个供应商巨大的工程工作量。另外，一个供应商发布的新版本的软件可能需要其他供应商的另行确认工作，并且可能不可避免地拖长了发布程序。这可能对应用程序供应商和PACS供应商造成很大的负担。另外，这使得用户更难以迅速使用到最新的技术，因为新开发的特定目的应用程序或PACS系统可能首先必须经过大量和不断的整合，以便使用户能够享受整合的益处。随着越来越多的应用程序供应商和越来越多的PACS供应商的出现，这种状况变得越来越不可行。造成这种混乱局面的根本原因在于由代码级整合所产生的相互依赖性。

鉴于这种情况，需要一种可扩展的体系结构，它能够在独立的医学系统之间实现互用性。

附图说明

本文要求保护和/或披露的发明将通过示例性实施例来进一步描述。这些示例性实施例结合附图进行详细说明。这些实施例是非限定性示例性实施例，其中，类似的附图标记在附图的不同视图中代表类似的结构，并且其中：

图1示出了根据本发明一个实施例的进程共享引擎的示例性系统框图；

图2示出了根据本发明一个实施例的进程共享引擎的详细的示例性系统框图；

图3a示出了根据本发明一个实施例的进程共享引擎和特定应用程序的后端之间的示例性数据流；

图3b示出了根据本发明一个实施例的进程共享引擎和特定应用程序的前端之间的示例性数据流；

图3c示出了根据本发明一个实施例的进程共享引擎的示例性框图；

图3d示出了根据本发明一个实施例的前端单元的构件的示例性框图；

图3e示出了根据本发明一个实施例的后端单元的构件的示例性框图；

图4示出了根据本发明另一个实施例的进程共享引擎系统的详细的示例性系统框图；

图5a是根据本发明一个实施例的数据存档、通信和处理(DACMS)系统，进程共享引擎和应用程序的后端之间的示例性后端进程的流程图；