用于评估医学研究数据的方法和系统与流程

本发明涉及通过在用户装置上运行的查看应用(viewingapplication)来评估医学研究数据的方法和系统。

背景技术：

在现代医学诊断中，许多医学成像模式以及根据用于诊断目的的专利来获取测量数据的其它方式是已知的，例如医学超声、计算机断层扫描(ct，computedtomography)、磁共振成像(mri，magneticresonanceimaging)、x射线成像、单光子发射成像(spect，singlephotonemissionphotography)和正电子发射断层成像(pet，positronemissiontomography)以及心电图(ecg，electrocardiogram)，这里仅举几个示例。因此，针对一个患者通常会通过若干模式产生大量的数据，这些数据可被存储在医学图像存档与通信系统(pacs，picturearchivingandcommunicationsystem)或任何其它数据库内。在这种应用中，将此类成像或其它诊断模式产生的数据称为“医学研究数据”，其中，通常将在一个诊断会话中从一个患者获取的数据存储在一项研究中。

通常，在数据获取之后并不直接对研究进行分析，而是稍后由专业医师或其它医疗人员进行分析。为了评估和分析医学研究数据，有时需要执行具有大量计算的测量和计算，例如，用于查找不同隔室的图像分割、对体内器官的模型拟合，或者在心脏成像的情况下对诸如心输出量、心脏瓣膜处的回流等重要参数的计算。为了进行这类分析，在迄今为止的实践中，在用户装置(例如，他们的工作站、pc或笔记本电脑)上安装专用软件。用于分析医学超声图像的这类软件的示例是由申请人提出的产品图像arena^tm，该产品图像arena^tm是用于图像分析、评估和数据管理的多模式平台，并提供用于2d(二维)、3d(三维)和4d(四维)分析的临床和高级应用的全面档案。

因此，医疗从业者需要下载并定期更新数据分析软件，并且这种软件的提供者需要为所有流行的操作系统提供不同版本的软件，以针对所有操作系统来测试该软件并且向用户通知必要的更新。

心脏成像技术有限公司(heartimagingtechnologies,llc)的专利，特别是us7457656、us8166381和us6934698提供了一种允许将任何常规的因特网浏览器用作医学工作站的医学图像管理系统。该系统可用于将医学图像从多个图像格式转换为浏览器兼容格式。然而，由于具有浏览器兼容格式的完整图像被从服务器传送到客户端，所以该解决方案需要高带宽和低延迟网络。us2014/0143298a1披露了另外一种经由浏览器来显示和帮助图像内容的图像处理的系统，其中，数据管理器将图像内容格式化为便于浏览器使用的格式。

技术实现要素：

因此，为克服现有技术的缺点，本发明的目的在于通过创建一种方法和系统，其中，用户具有桌面应用程序用户体验，但并不需要高带宽因特网连接或网络以处理和分析诸如三维(3d)或四维(4d)图像(其中第四维是时间)等大数据文件。本发明的另一个目在于提供一种用于评估医学数据的的软件方案，该方案不需要诸如升级、降级、配置和部署等客户端安装。本发明的另一个目在于提供一种用于评估医学数据的软件方案，该方案一旦被编写就在无需插件的情况下在任何地方运行且可由用户随处访问。本发明的另一个目在于提供一种用于评估医学图像数据的方法，即使在低带宽、高延迟网络下从远程服务器下载图像，该方法也可提供空间和时间上的诊断图像质量。

通过根据权利要求1和6的方法、根据权利要求14的系统和根据权利要求13的计算机程序产品来实现本发明的目的。

本发明提供了一种用于医学图像查看的分布式架构，该架构具有在服务器环境下运行的一部分以及在用户个人设备上运行的另一部分，其中，服务器环境通常是受控的安全环境，例如服务器上的进程、服务器上运行的进程中的线程、虚拟架构(轻量级虚拟机)、虚拟机器、云实例等，并且另一部分例如在pc、平板电脑或智能电话上运行的因特网浏览器(即)内部运行的网页应用，或在计算机操作系统(例如，windows、linux)上运行的桌面应用或使用任何其它运行时环境或解释器(例如，ruby、python)的桌面应用、或者作为经由类似apple的appstore、googleplay的渠道或经由内部网络发布的移动设备的应用程序(“移动应用程序”或“应用程序”)。但是，对于用户而来说，这两个部分的功能类似于虚拟单一应用。

在用户个人装置上运行的部分被称为“查看应用”，而在服务器环境中运行的部分包括“助手(helper)进程”或“助手”，且在一些实施例中包括“协调器引擎(coordinatorengine)”。与现有技术的应用相比，助手不渲染和传送将被显示在用户装置上的整个图像，而是编码和传送将被客户端(即，查看应用)处理的绘制命令。另外，例如，助手和查看应用知晓彼此的状态，例如这是因为它们具有一对一的连接。因此，在助手与查看应用之间可以以优化的方式分布计算，这在无状态(stateless)、多客户端渲染架构中是不可能的或者对于远程桌面协议是不可能的。因此，在有益实施例中，助手是有状态(stateful)组件，并且查看应用能够缓存完整的绘制命令或诸如相关的数据缓冲区或绘制命令序列等部分绘制命令。由于助手知晓已经被发送到查看应用并且已经被查看应用高速缓存的内容，所以它能够匹配于其它绘制命令流，使得不用重新发送所缓存的数据。由此，对通信信道的带宽(即，助手与查看应用之间的网络连接)的要求较低。

本发明的优点在于，不必完全将因太大而不能被用户装置(存储器cpu、网络带宽)处理的医学研究数据发送到用户装置，而是可以在安全且计算速度快的服务器环境中由助手进程来处理这些数据。同时，可以使查看应用尽可能地通用且瘦(thin)，例如，它甚至可以是在用户的网页浏览器内运行的网页应用。这将减少针对浏览器、浏览器版本和/或操作系统的所有组合进行完整和复杂的应用测试的工作负荷，这在异构客户端环境下是必要的。

另一方面，可以通过助手来执行在用户装置上不可用的程序部分(例如，对于浏览器环境不可用的程序部分)。这同样适用于浏览器缺少执行计算所需的某些功能的情况。此外，助手进程可被配置成不将敏感/机密数据(例如，患者数据或机密程序代码)传送到可能处于不受信任的环境中(例如，当用户装被盗或被恶意软件劫持时)的用户装置。

除诸如姓名、年龄等患者参数之外，将在用户装置上被评估的医学研究数据可包含医学图像数据，例如，超声、ct、mri数据或由其它模式产生的图像数据，以及诸如ecg数据等进一步测量数据。在有益实施例中，医学研究数据以由模式制造商以dicom标准或任何其它现有技术格式提供的格式存在。医学研究数据可以被存储在与运行助手相同的服务器环境中，但是它也可以存储在可由网络连接可访问的不同服务器上，或者甚至可能在用户装置上。本发明以独立于医学研究数据的来源的方式发挥作用。

在有益实施例中，用户首先能够访问医学研究列表并选择一个列表(列表可能被存储在医院或其它数据库服务器上)。因此，在评估会话请求之前、之后或与评估会话请求一起，查看应用将所选的医学研究的相关信息传送至例如协调器引擎，或者一旦通信信道建立，查看应用直接将该信息传递至助手进程。在任何情况下，助手进程均能够与存储医学研究数据的服务器进行通信并且检索必要的数据。

在有益实施例中，例如，在每次评估会话之前，在需要时优选地从网页服务器将查看应用或至少查看应用的更新加载到用户装置上，并优选地无需用户干预。在有益实施例中，在每个评估会话之前，将查看应用完全加载到用户装置上，例如，如果查看应用为网页应用，则将其加载到用户的网页浏览器中。因此，不必由用户定期更新查看应用。在有益实施例中，在每个会话之后，可在没有任何痕迹的情况下从用户装置中删除查看应用或至少能够将该查看应用删除。在有益实施例中，用户可从其所有客户端装置(移动电话、平板计算机、家庭pc、工作pc)发起会话，而不必安装软件或者至多安装小型应用。

查看应用可以为充当客户端的一个或多个程序。在有益实施例中，它们可以由浏览器运行时环境(例如，java脚本程序、网页组件)运行。该程序的加载过程可以独立于这里说明的其它系统组件(协调器引擎、助手)，而例如由专用网页服务器或内容交付网络(cdn，contentdeliverynetwork)服务。一个示例是单页应用程序，而不是基于服务器的应用程序。然而，本发明还涵盖如下示例：查看应用被安装在用户装置(桌面应用)上。在所有情况下，分析医疗数据所需的功能性分布在客户端(查看应用程序)与服务器环境(助手)之间。

在用户装置上，查看应用包括用于创建包括可绘制区域的用户界面的程序代码。可绘制区域是显示图像和其它研究数据的诊断区域。例如，其是可以用于快速、甚至是图形卡辅助的2d和3d图形的再现元件(例如html5画布)。用户界面还可包括用户界面/输入元件，诸如按钮、滑块、对话框以及在网页应用的情况下由查看应用直接在浏览器中创建的一般布局等。

当查看应用向第一服务器发送(通常是远程地)评估会话的请求时，在有益实施例中，首先由所谓的协调器引擎处理。协调器引擎负责在服务器环境中分配至少一个助手进程。可以针对每个评估会话来创建新的助手进程，或者可以从准备好的助手池(热备用)中选择助手进程。在有益实施例中，协调器引擎会将助手进程的连接信息(例如，url、令牌...)传递给查看应用，然后查看应用可准备从查看应用程序到助手的一个或多个直接连接或通信信道。可替代地，可使用代理将网络连接从专用服务器分派至助手。

例如，协调器引擎负责生命周期(启动、创建、分配和关闭助手)、在运行助手的服务器环境中进行负载平衡、容错和用户的初始验证。后者可通过创建从查看应用经由安全连接传递到服务器环境(协调器引擎和/或助手进程)的一次性令牌来完成。在有益实施例中，通信信道是安全的。

在有益实施例中，每个查看应用接着建立至助手进程的直接连接。可替代地，可使用代理从专用服务器向助手分派网络连接。在有益示例中，将html5网页套接字用于低延迟、高带宽的连接。出于性能原因，查看应用还可开启至其助手的多个连接。通过使用例如安全网络协议(如ssl网页套接字)来保护通信是通信信道的责任。为了进一步改进性能，可使用基于流或基于消息的压缩(如gzip)。这些连接都是下面提到的至少一个“通信信道”的示例。

在下文中说明了优选实施例中的助手进程和查看应用进行通信的方式。为了分析医学研究数据，通常需要显示图像以及诸如测量、文本注释、图形显示等叠加(overlay)。因此，几乎每个用于医学图像分析的软件在其软件架构中具有某种类型的绘制层，该绘制层可用于定义绘制图元，例如2d和3d的线条、多边形、纹理多边形和文本。通常，被显示的项目被组织在分层“场景图形”中。通过遍历场景图形节点并生成用于底层图形应用程序编程接口(api，applicationprogramminginterface)(如directx或opengl)的更多低级绘制调用来完成分层场景图形的渲染(绘制)。

在本发明的有益实施例中，助手进程负责维护完整的场景图形。例如，助手进程(通常在经由上述在查看应用上的用户界面来传达用户的请求时)可使用所选择的医学研究数据并在其上执行一些测量或分析，并且将创建图形叠加，例如，文本注释或包含分析结果的图表。

然而，助手进程自身并不渲染(绘制)图表或文本注释。例如，助手进程只创建包含这些项目的场景图形。场景图形还可包括包含来自医学研究数据的图像数据的纹理(texture)。

助手进程(例如根据这种场景图形)生成绘制命令流，然后通过通信信道将流传送到查看应用。例如，助手进程将与场景图形相关的绘制命令编码成命令流，然后该命令被流传送到客户端/查看应用。例如，“绘制命令流”包含指令，以指示如何在可绘制区域中渲染被显示的图像。在有益实施例中，图像中的各个独立项目(例如医学图像或其一部分，以及诸如文本注释、图表或其它图形显示等叠加)被编码在各个绘制命令中，并且/或者与其相关的数据被编码至相关的数据缓冲区(例如，纹理和顶点缓冲区)中，这些数据也被传送并且用作绘制命令的参考。在有益实施例中，绘制命令流被分离成各自具有时间标记并且与一个帧相关的单独的“命令列表”，其中在可绘制区域中一帧接一帧地进行显示(例如，参见图4)。因此，优选地，所传送的绘制命令是基于矢量的(而不是基于像素的)。绘制命令可以包含命令列表，并且有时包含一个或多个纹理和/或顶点缓冲区。

查看应用解释绘制命令以生成被显示在可绘制区域中的时间序列帧。虽然被表述为“时间序列帧”，但不一定意味着医学图像数据包含时间序列图像(尽管这是有益的应用)。“时间序列”还可以指在评估会话的通常过程中在可绘制区域中发生的改变，例如，用户选择不同的图像用于显示、进行注释等，这可以在静态或运动图像中进行但是将导致诊断区域(可绘制区域)中的变化。在此使用词语“帧”来说明在一个时间点处被显示在可绘制区域内的任何内容。因此，在有益实施例中，由查看应用来进行渲染，即基于从(远程)服务器传送的绘制命令来创建图像。

在本发明的有益应用中，查看应用具有优选地非常简单的解释器，该解释器解释绘制命令流并且生成例如用于浏览器的图形api(在网页应用程序的情况下)的绘制调用。例如，这可以是webgl或任何其它图形库，例如paperjs或easljs。在有益应用中，使用高性能硬件加速图形api，例如webgl。助手和查看应用连接成使得它们知晓彼此的状态。由于查看应用能够缓存绘制命令、绘制命令序列和相关的数据缓冲区(例如，纹理、图像、顶点或顶点缓冲区)，因此助手不会再次传送被缓存的绘制命令并且/或者仅传送与前后帧之间的差异相关的绘制命令。这大大减少了要传送的数据量，这是因为通常仅逐渐地改变可绘制区域或诊断区域中的显示。例如，如果通过用户交互改变了注释或绘制线条，则底层图像(或纹理)不会被助手重新发送，而是仅仅重新发送与替换的项目(诸如注释、线条或其它叠加)有关的绘制命令。因此，当可绘制区域中只有一个项目发生改变时，助手可传送包括与该改变的项目相关的指令的更新绘制命令，或者通知查看应用来重新执行最后一帧的绘制调用。

在动态图像(即动画图像或运动图像)(例如从心脏获取的2d或3d时间序列图像)的情况下，助手进程不会重新发送叠加，而只重新发送图像内容。如果时间序列图像被循环地显示，即一次又一次地显示相同的图像序列，则也由用户装置上的查看应用来缓存图像。在有益实施例中，查看应用还缓存与每个绘制命令列表相关的时间标记，使得它可以播放动画图像的循环，而无需与助手进行交互。

在有益实施例中，通常响应于用户界面处的用户输入事件，查看应用还能够直接在可绘制区域内执行一些操作。这些输入事件不被传送到助手，并且响应于用户输入事件，可直接在绘制区域中执行这种操作，而无需从助手接收绘制命令。在有益应用中，这些操作涉及从包括亮度、对比度、着色、缩放和添加叠加的群组中选择的显示选项，或者涉及对被显示在可绘制区域中的图像执行测量，或者向可绘制区域添加注释或图表。

在大多数实施例中，医学研究数据本身由助手处理，助手将处理结果以绘制命令流的形式传送到查看应用。这种处理可包括诸如平滑、滤波等预处理步骤，并进一步包括例如体渲染、三维重建、分割、对医学研究数据的模型拟合、从图像数据的医学数据提取等的处理步骤。进一步的处理还可包括诸如测量、分类或标准化等分析步骤。通常响应于由查看应用传送的用户输入事件，助手执行这种处理步骤。在大多数实施例中，具有平台存储格式的原始医学研究数据不会被传送到查看应用。

在本发明的一些实施例中，在每个会话开始时，基于网络连接的带宽和/或查看应用或用户装置的性能能力，查看应用和助手将商定每个会话执行哪些功能。例如，如果用户装置上的处理器缓慢，而查看应用与助手之间的通信信道很快，则将由助手来执行更多的数据处理功能，并且将结果传送到查看应用。在相反的情况下，可通过用户装置上的查看应用来执行更多功能。

由于助手是有状态的，这意味着例如它会记住哪些内容在评估会话过程中已经被传送到特定查看应用，所以本发明的有益实施例包括定期保存助手的状态，其中“状态”包括例如如下信息：现行活动医学研究、完成了哪些测量和相应结果以及哪个视口是活动以及在可绘制区域中渲染的最后图像的恢复所必需的可能的绘制命令集合。在有益实施例中，“状态”或“状态信息”被以固定的间隔传送到查看应用并由查看应用存储。可替代地，例如，其可被协调器引擎存储在服务器环境中。因此，如果由于助手或查看应用的崩溃而导致评估会话意外终止，则可以通过例如由协调器引擎分配的新的助手继续该会话。在评估会话结束时存储助手的状态也是有用的，使得可在其它时间继续进行该会话。

本发明还涉及由服务器环境、特别是助手进程和可能的协调器引擎执行的方法。

本发明还涉及一种能够被加载到数字计算机的内部存储器中的计算机程序产品，该计算机程序产品包括当所述产品在计算机上运行时用于执行本发明的方法的软件代码部分。本发明还涉及包括指令集合的非易失性计算机可读介质，处理器通过执行指令集合来进行用于实施本发明的方法的一系列步骤。本发明还可以包括被处理器执行的计算机程序代码的有形计算机可读存储介质来实现，通过执行计算机程序代码来实施本发明的方法。

附图说明

现在参照附图更详细地说明本发明的有益实施例，其中：

图1示出了系统概貌的示例；

图2示出了在用户装置上运行的查看应用的屏幕截图的示例；

图3是示出了由服务器环境(serverenvironment)执行的方法的实施例；

图4示出了绘制命令流的示例；

图5示出了顶点缓冲区(vertexbuffers)和纹理(textures)的示例；并且

图6示出了动画图像数据在被本发明的方法评估时的图示。

具体实施方式

图1的一般系统概貌示出了顶部的客户端侧(即，在用户装置上运行的进程)和底部的服务器侧，并以诸如因特网等网络5作为媒介。服务器侧(“服务器环境”)可以由多个机器组成。

在开始评估会话之前或在评估会话开始时，客户端或查看应用从平台4(例如，诸如医院或其它医疗机构的pacs等远程服务器)接收医学研究的列表(例如，研究标识符的列表)，并且在2处向用户显示列表。用户可以选择研究，并且将所选的医学研究的相关信息(包括例如研究标识符)传送至助手进程12。查看应用8通常将通过协调器引擎(coordinatorengine)10的中介连接至助手进程12，协调器引擎负责例如启动、销毁和迁移助手进程12。一旦协调器引擎分配助手进程12，在有状态(stateful)助手进程12与查看应用8之间建立至少一个通信信道14或多个连接，例如交互式网页套接字通信(interactivewebsocketcommunication)。助手12可在从查看应用接收研究标识符之后例如经由html连接9来访问平台4以检索医学研究数据。

在有益实施例中，查看应用8在评估会话开始时将其能力的相关信息(例如支持哪些纹理压缩算法)发送至助手12，并且助手相应地可例如通过发送具有针对查看应用8被优化的压缩格式的纹理来使其绘制命令流匹配于这些能力。

助手12维护完整的场景图形并向查看应用8发送绘制命令，从而使查看应用8在可绘制区域上渲染场景图形。由于助手知晓客户端(＝查看应用)的状态，它可仅发送“增量”更新，即与前后帧之间的差异有关的绘制命令。

查看应用8包括解释器16，解释器16能够解释或解码从助手12接收的绘制命令流，并且生成例如在用户装置上通过其网页浏览器可直接执行的且被执行的绘制调用。

将重要状态时时地保存到助手状态存储器18，其中，助手状态存储器18可以在用户装置上，或者也可以在服务器环境内，或者甚至在另一服务器上。在大多数应用中，有状态助手进程12在一个评估会话中有效，即它不被重新使用，而是在每个评估会话之后终止。

图3示出了响应于用户向服务器发送评估会话的请求21而允许用户在用户装置上评估医学研究数据的方法。作为响应，在步骤22中将一个或几个助手进程12分配给该评估会话。在步骤24处，在客户端(查看应用)与助手之间建立通信信道，并且在许多实施例中，查看应用将自己的能力的有关信息(例如，它的可用处理能力、诸如纹理等可用软件组件、压缩格式以及可能的通信信道的带宽)传送至助手。在评估会话期间，由于网络性能在一个评估会话期间可能发生改变，因此可定期更新通信信道的带宽的有关信息，并且助手接着可相应地调整其绘制命令流(例如，在低带宽网络中使用更强的压缩)。

在步骤26中，助手还接收现行的医学研究的有关信息，并且从数据存储器或平台4中检索医学研究数据。在步骤28中，助手可选地接收另一用户输入u1，该输入可以提示助手处理医学研究数据，例如检索某些图像并产生纹理和可能的由纹理产生的叠加(overlay)。在步骤30中，助手12编码绘制命令d1流，该流通过通信信道被传送到查看应用8。查看应用将这些绘制命令d1解释为合适的绘制调用，这些绘制调用在查看应用的可绘制区域42中绘制适当的显示。用户可以在可绘制区域42中执行一些交互，例如绘制线条以执行测量。在步骤32中，用户输入u2被传送到助手进程，并且在步骤34中，助手进程相应地生成被传送到查看应用的其它绘制命令d2。在有益实施例中，通过考虑查看应用的状态来优化绘制命令d2，特别是考虑在查看应用中已经缓存了什么内容并因此不必重新发送这些内容。

在步骤36中，当用户希望结束评估会话时，助手进程可将其状态s的有关信息发送到服务器或客户端侧18以进行存储。

图2示出了客户端(即查看应用，其可以是在用户的网页浏览器内部运行的网页应用)的示例。查看应用创建包括可绘制区域42的用户界面40。可绘制区域42可例如是webgl画布。如图所示，可绘制区域可被划分为多个(在该示例中为四个)视口(viewport)，这些视口被编号为42a、42b、42c和42d。可绘制区域42也被称为诊断区域。可绘制区域是屏幕上的如下区域，该区域显示/渲染由查看应用8根据绘制命令流d1、d2解释的绘制调用。此外，用户界面包括工具栏44和可选的控制器48等用户输入元件。此外，还可能存在状态条46和用于缩略图预览50的区域。

图4和图5以示例的方式示出了助手进程与查看应用之间的交互，特别是绘制命令流以及查看应用如何缓存这些绘制命令流。

最初，查看应用不接收任何场景信息，但是希望渲染在给定时间线上具有30ms的时间标记(ts)的帧100。助手知晓客户端的状态(即，客户端还不具有任何场景信息)，并且首先发送如图5所示的必要的顶点缓冲区和纹理。在本示例中，存在两个顶点缓冲区和三个纹理。在本发明中，纹理可以包含从医学研究数据(图5中的纹理1和3)中提取的图像数据或者例如诸如纹理2等注释。例如，顶点为图形中的节点。因此，助手向查看应用发送命令列表1，以使查看应用能够将要在时间标记30ms处显示的帧100绘制在可绘制区域中。在清屏之后，绘制命令“视口(0,0)×(200,200)”指示将要使用从坐标0,0到200,200的左上窗口。然后，查看应用被指示使用顶点缓冲区1和纹理3，并使用顶点3、6和2来绘制三角形。通过查看应用来解释并执行这些绘制命令，并且在52处示出其结果。

在时间标记55ms处的后续帧101中，应该稍微改变三角形，使得顶点3和4移动。由于其它一切内容均保持不变，并且助手知晓查看应用具有用于绘制帧100的所有信息，因此助手现在仅发送更新命令以替换顶点缓冲区1中的顶点编号3和4并重新发布绘制顺序。这在命令列表2中示出，其中，相应地更新顶点缓冲区1。然后，绘制命令将调用命令列表1，因此，利用更新的顶点缓冲区1(或换句话说，更换的顶点编号3和4)来执行相同的绘制命令。在54处示出了结果。利用这种差分编码方案，在通信信道上仅传送已经改变的数据，从而通过网络传送的数据量非常少。

为了进一步减少传送的数据量，本发明的有益实施例采用数据压缩或重复数据删除算法。可非常有效地实现数据量的进一步减小的原因在于，助手可使自身匹配于查看应用。不同的用户装置(特别是不同的移动设备)可例如针对纹理压缩使用不同技术。因此，本发明的可选特征是：查看应用在评估会话开始时发送这些技术的有关信息以及特别是查看应用支持哪些纹理压缩算法的有关信息，并因此助手使绘制命令流匹配于查看应用的功能。例如，助手可以发送具有针对客户端(查看应用)被优化的格式的纹理。可替代地，助手可以将纹理压缩成jpeg或png，并且查看应用将它们解压缩。查看应用可以缓存纹理并且例如将它们(例如，经由webgl)加载到图形卡上。webgl纹理压缩非常有用，原因在于其不同于其它系统。助手知晓客户端/查看应用需要哪种纹理压缩，并且发送准备被下载到图形卡上的纹理。由此，客户端代码可缓存压缩的纹理，且图形卡上解压缩是“免费的”。

此外，助手和查看应用可以匹配于网络带宽。例如，在慢通信信道中，可以减少纹理的分辨率，或者可以提高压缩。由于助手仅传送绘制命令(而不传送所渲染的图像)，所以仍可以清楚地描绘叠加(例如文本注释、测量、ecg等)，并且仅以降低的质量的方式显示纹理(图像数据)。

因此，例如，利用网络协议的压缩以及复杂的增量压缩算法(如z-delta)或其它重复数据删除算法，可以进一步减少从助手传送到查看应用的数据量。

另一个示例是动画帧(即，时间序列医学图像)的评估。如图6所示，一个示例为心脏成像，其中，例如在一个心脏周期期间从心脏获取5-50个图像，并且必须以实际发生的速度循环显示这些图像。许多现有技术的基于网页的医学图像查看器在遇到具有高帧速率的动画帧时失效。例如，超声检查的准确的诊断性评估需要具有高帧速率的动画帧。这里，图像质量和播放速度二者必须精确。

如下文通过示例的方式所解释，可以通过本发明来解决这个问题。如图6所示，在给定在以25ms(等于40帧/秒)均匀分布的时间标记处具有图像的医学数据集的情况下，将播放从时间标记30ms到时间标记180ms的循环。图4列出了一些时间帧(帧100到106)，且假定不改变三角形的坐标，而是改变每个帧中的三角形的纹理图像。因此，对于帧101，将获得更新纹理调用以利用新的图像来替换纹理图像。

目前，查看应用也随时间对数据进行缓存，而不重写纹理图像，因此其存储纹理图像和用于绘制命令的增量，以从帧100到101、101到102、...以及105到106进行遍历。然后，在作为循环中的最后一帧的帧106，需要再次回到第一帧。由于查看应用只存储差值或“增量”，因此它不能绘制一个“不在序列中”的帧，因此，生成增量以从时间标记180ms回到时间标记30ms(其就是新帧107)。当该序列完成时，查看应用会播放整个循环的所有信息，而无需从助手传送的任何数据。通过添加更多的绘制图元(例如绘制协调或放置文本标签)将仅触发绘制序列的一小部分的更新，且将很快回到查看应用可以其自身的播放循环的水平。

在许多实施例中，在助手与查看应用之间存在一一对应的关系，但是在其它实施例中，存在多个查看应用(例如，镜像应用(电视咨询、记录、多监视器广播))和/或多个助手(例如，多个检查、用于临床任务的不同助手)。在有利的实施例中，客户端侧(查看应用)上的缓存架构可以包括用于缓存纹理(键和帧，或者例如md5散列)、缓存绘制命令(例如帧绘制调用)和/缓存例如顶点缓冲区中的顶点的能力。在一些实施例中，将webgl(图形卡纹理存储器)用作查看应用的缓存。

在有益实施例中，通过查看应用(例如浏览器)将帮助状态数据存储在用户装置上。不在助手侧(服务器环境)使用数据库或缓存，而是助手将状态信息传送到客户端(查看应用)，并将状态信息存储在客户端，该状态信息也可使用压缩和增量编码进行优化。以此方式，助手对环境的要求较低(没有数据库等)，并且当例如一个服务器机器崩溃或不再能被访问时，客户端(查看应用)可以通过协调器引擎重新创建其助手。由于所存储的帮助状态数据仅与助手相关(查看应用对该数据是无效的)，因此可以将帮助状态数据编码和存储为紧密/压缩格式。对于不受信任的环境，可以(例如，使用aes)加密该存储数据，其中加密密钥(私人/公共)保留在服务器环境中(不被发送到查看应用)。因此，用户不能解密数据，用户装置仅存储帮助状态数据以稍后供其它助手使用。

在有益实施例中，通过使用诸如谷歌浏览器等嵌入式浏览器，能够在普通桌面应用(胖客户端(thickclient))中使用用于作为网页应用的查看应用的相同程序代码。由于只需要维护一个代码路径，因此这会降低开发成本。