JP2022122974A - 医療調査データをレビューするための方法及びシステム - Google Patents

Abstract

【課題】ユーザの機器上で動作する表示アプリケーションによって医療調査データをレビューするための方法及びシステムを提供する。【解決手段】システムは、ユーザの機器に描画可能領域を含むユーザインタフェースを生成する表示アプリケーション８、表示アプリケーション８からレビューセッションのための要求を受け取るためのコーディネートエンジン１０を含むサーバ環境及びコーディネータエンジン１０によって各レビューセッションに割り当てられたレビューヘルパープロセス１２を含む。ヘルパープロセスは、データストレージ４から医療調査データを検索し、描画コマンドのストリームを表示アプリケーションへ転送する。描画コマンドの少なくとも一部分は、ユーザの機器にキャッシュされ、ヘルパープロセスは、キャッシュされた描画コマンドを再度は転送しないか及び／又は１のフレームと次のフレームとの差分にのみ関係する描画コマンドを転送する。【選択図】図１

Description

本発明は、ユーザの機器上で動作する表示アプリケーションによって医療調査データをレビューするための方法及びシステムに関する。

現代の医療診断において、診断の目的のために患者から計測データを獲得する多数の医療画像モダリティ及び他の手段が公知であり、例えば、医療超音波、ＣＴ（コンピュータトモグラフィー）、ＭＲＩ（磁気共鳴撮像）、Ｘ線撮像、ＳＰＥＣＴ（単光子放出コンピュータ断層撮像）、及びＰＥＴ（ポジトロン断層撮像）、ＥＣＧ（心電図）が、いくつかの例として挙げられる。従ってデータの相当量が、１人の患者について、多くの場合、幾つかのモダリティによって生成され、それは、画像アーカイブ及び通信システム（ＰＡＣＳ）又は何らかの別のデータベース内に蓄積されうる。そのような撮像法又は別の診断モダリティによって生み出されたデータは、この応用において「医療調査データ」と呼ばれる。多くの場合、１診断セッションにおいて１人の患者から獲得されるデータは、１つの調査毎に蓄積される。

調査は、多くの場合に獲得された直後ではなくより後の時間に、専門の医師又は別の医療職員によって分析される。医療調査データをレビュー及び分析するために、集約的な計測及び計算、例えば異なる部分を発見するために画像をセグメント化すること、モデルを身体の器官に合わせること、又は心電図の場合の重要なパラメータ、例えば心拍出量、心臓弁での逆流などを計算することをコンピュータ的に実行することが時によっては要求される。そのような分析を遂行するために、専用のソフトウェアをユーザの機器、例えばワークステーション、ＰＣ（パーソナルコンピュータ）、又はラップトップコンピュータ、にインストールすることは、これまで実際に行われてきた。医療超音波画像を解析するためのそのようなソフトウェアの１例が、本出願人によるproduct image Arena（登録商標）であり、これは画像の分析、レビュー及びデータ管理のための多様性のあるプラットフォームであり、２Ｄ（二次元）、３Ｄ（三次元）及び４Ｄ（四次元）分析のための臨床かつ高度な応用の総合的なポートフォリオを提供する。

したがって、医療実務者は、データ分析ソフトウェアをダウンロードし且つ規則的にアップデートする必要があり、そして、そのようなソフトウェアの提供者は、広く普及しているオペレーティングシステムのためのソフトウェアの様々なバージョンを提供すること、全てのオペレーティングシステムのためにソフトウェアをテストすること、及びユーザへ要求されたアップデートの注意を出すことを要求される。

Heart Imaging Technologies, LLC（合同会社）による特許、特に米国特許US 7,457,656、US 8,166,381、及びUS 6,934,698、は任意の従来のインターネットブラウザが医療ワークステーションとして機能することを可能にするために医療画像管理システムを提供する。システムは、医療画像を複数の画像フォーマットからブラウザ互換性フォーマットへ変換するために用いられうる。しかし、この解決策は、ブラウザ互換性フォーマットにおける完全な画像がサーバからクライアントへ転送されるので、広帯域かつ短い待機時間のネットワークを必要とする。ブラウザを介して画像コンテンツを表示し且つその画像操作を容易にするための別のシステムが、米国特許出願公開US 2014/0143298 A1に開示され、そこでは、データマネジャーが、画像コンテンツをブラウザ向きのフォーマットへ変換する。

従って、本発明の目的は、例えば三次元（３Ｄ）、又は四次元（４Ｄ）画像（ここでは第４の次元は時間である）のような大きなデータファイルを処理し且つ分析するために、ユーザはデスクトップアプリケーションのユーザ経験を持つが、広帯域のインターネット接続又はネットワークを必要としない方法及びシステムを創出することによって従来技術の不利な点を克服することである。本発明の別の目的は、医療データをレビューするためのソフトウェア的解決策を提供することであり、そこでは、クライアントのインストール、例えばアップグレード、ダウングレード、設定、配備、は不要である。本発明の別の目的は、医療データをレビューするためのソフトウェア的解決策を提供することであり、そこでは、一度書かれたソフトウェアは、プラグインなしにどこででも実行ができ、且つユーザによってどこからでもアクセスされうる。更に本発明の別の目的は、例え画像が、狭い帯域、待機時間の長いネットワークで遠隔サーバからダウンロードされても、診断画像の品質（空間的及び時間的の両方での）を与える医療画像をレビューするための方法を提供することである。

本発明の目的は、請求項１および６による方法、請求項１４によるシステム、及び請求項１３によるコンピュータプログラム製品によって達成される。

本発明は、医療画像表示のための分散アーキテクチャを提供する。分散アーキテクチャは、通常は制御され安全な環境、例えばサーバマシン上のプロセス、サーバマシン上で動作するプロセス内のスレッド、コンテナ（軽量仮想マシン）、仮想マシン、クラウドインスタンス等であるところのサーバ環境において動作する一部分を有し、且つ、ユーザの個人的な機器上で、例えば、パーソナルコンピュータ（ＰＣ）、タブレット若しくはスマートフォン上で動作するインターネットブラウザ内部（即ちウェブアプリケーション）、又はコンピュータのオペレーティングシステム（例えばWindows、Linux（登録商標））上で動作する、又は何らかの別のランタイム環境若しくはインタプリタ（例えばJava（登録商標）、Ruby、Python（登録商標））を用いる、デスクトップアプリケーションとして、又はアップルのAppStore、GooglePlayのようなチャネルを介して若しくはイントラネットを介して分配されているところの移動機器のためのアプリケーション（「モバイルアプリケーション」若しくは「アプリ」）として動作する別の部分を有している。しかし、ユーザに対しては、上記２つの部分は、仮想の単一アプリケーションのように機能する。

ユーザの個人的な機器上で動作する部分は、「表示アプリケーション」と呼ばれ、一方、サーバ環境内で動作する部分は、「ヘルパープロセス」又は「ヘルパー」、及びいくつかの実施態様においては「コーディネータエンジン」を含む。従来技術のアプリケーションとは対照的に、ヘルパーは、ユーザの機器に表示されるべき画像の全体を描画も転送もせず、むしろクライアント、すなわち表示アプリケーションによって処理されるべき描画コマンドを符号化し転送する。さらにヘルパー及び表示アプリケーションは、例えばそれらが１対１の接続を有するので、各々他方の状態を知っている。従って計算は、ヘルパーと表示アプリケーションとの間で最適な仕方で分配されうる。それは、状態の無い多クライアント描画アーキテクチャ、又は遠隔デスクトッププロトコルでは不可能である。従って有用な実施態様において、ヘルパーは、状態を含むコンポーネントであり、そして表示アプリケーションは、描画コマンド全体、又はそれらの部分、例えば関連するデータバッファ、又は描画コマンドの列、をキャッシュできる。ヘルパーは、表示アプリケーションへ何を送信したか、及びそれによって何がキャッシュされたかを知っているので、それは、描画コマンドの別のストリームをキャッシュされたデータは再送信されないように適合させることができる。このために、通信チャネル、即ちヘルパーと表示アプリケーションとの間のネットワーク接続、の帯域に関する要求は低くなる。

ユーザの機器（メモリ、ＣＰＵ、ネットワーク帯域）によって処理されるには大き過ぎる医療調査データが、ユーザの機器へ全部転送されなければならないことはなく、安全でかつ計算的に高速のサーバ環境におけるヘルパープロセスによって扱われうることは、本発明の有利な点である。同時に、表示アプリケーションを可能な限り一般的で且つ能力を乏しくすることも可能であり、例えばユーザのウェブブラウザ内で動作するウェブアプリケーションでもよい。これは、ブラウザ、ブラウザの版、及び／又はオペレーティングシステムの全ての組合せについての、完全で複雑なアプリケーションをテストするための作業負担を減少させるが、その作業負担は非均質なクライアント環境においては別途必要である。

他方で、ユーザの機器で利用可能でない、例えばブラウザ環境では利用できないプログラム部分は、ヘルパーによって実行されうる。例えばブラウザが計算を遂行するのに必要とされる或る種の能力を欠いていることも、同様に真実である。さらにヘルパープロセスは、慎重に扱うべき／秘密のデータ（例えば患者のデータ又は秘密のプログラムコード）を信頼できない（例えば、ユーザの機器が盗まれ又は不正なソフトウェアによって乗っ取られたときの）環境であるかも知れないユーザの機器へ転送しないように構成されうる。

ユーザの機器上で検索されるべき医療調査データは、医療画像データ、例えば、超音波、ＣＴ、ＭＲＩデータ、又は別のモダリティによって生成された画像データ、及び例えばＥＣＧデータ等の別の計測データ、さらに名前、年齢等の患者のパラメータを含みうる。有用な実施態様において、医療調査データは、モダリティ製造業者によってＤＩＣＯＭ標準又は技術フォーマットの何か別の状態で供給されるところのフォーマットで提示される。医療調査データは、ヘルパーが動作しているところの同一サーバ環境内に蓄積されうるが、また、ネットワーク接続によってアクセスできる異なるサーバに、又は場合によってはユーザの機器にさえも蓄積されうる。本発明は、医療調査データの発信元からは独立に機能する。

有用な実施態様において、ユーザは、医療調査のリストに最初にアクセスすることができ、そして（場合によっては病院、又は別のデータベースサーバに蓄積された）１つを選択する。従って、表示アプリケーションは、選択された医療調査に関する情報を、例えば、レビューセッションの要求の前もしくは後もしくは一緒にコーディネータエンジンへ回送し、又は代わりに一度通信チャネルが設定されるとヘルパープロセスへ直接に回送する。どの場合でも、ヘルパープロセスは、医療調査データが蓄積されるサーバと通信ができ、且つ要求されたデータを検索できる。

有用な実施態様において、表示アプリケーション、又は表示アプリケーションについての少なくとも更新は、好ましくはウェブサーバから、好ましくはユーザの介入なしに、そして要求されるときはいつでも、例えば各レビューセッションの前に、ユーザの機器上にロードされる。有用な実施態様において、表示アプリケーションは、各レビューセッションの前にユーザの機器上に完全にロードされる。例えばもし表示アプリケーションがウェブアプリケーションであれば、それはユーザのウェブブラウザ内にロードされる。このようにして、表示アプリケーションは、ユーザによって規則的に更新される必要はない。有用な実施態様において、表示アプリケーションは、各セッションの後、如何なるトレースもなしにユーザの機器から削除されるか、又は少なくとも削除されうる。有用な実施態様において、ユーザは、ソフトウェアをインストールする必要なしに、又はせいぜい小さなアプリをインストールして、彼のクライアント機器の全て（携帯電話、タブレットコンピュータ、家庭のＰＣ、職場のＰＣ）からセッションを起動できる。

表示アプリケーションは、１つ以上のプログラムでありえ、それはクライアントとして動作する。有用な実施態様において、それらはブラウザの実行時環境（例えばJava（登録商標）スクリプトプログラム、Ｗｅｂアセンブリ）によって動作させられうる。このプログラムのロード過程は、例えば専用のウェブサーバ又はＣＤＮ（コンテント配送ネットワーク）によって提供される、ここで記載された別のシステム構成要素（コーディネートエンジン、ヘルパー）から独立でありうる。１つの例は、単一ページアプリケーションであり、サーバベースのアプリケーションではない。しかし、本発明はまた、表示アプリケーションがユーザの機器にインストールされるところの例（デスクトップアプリケーション）をカバーする。全ての場合に、医療データを分析するために要求される機能は、クライアント（表示アプリケーション）とサーバ環境（ヘルパー）との間に分配される。

表示アプリケーションは、ユーザの機器上の描画可能領域を含むユーザインタフェースを生成するプログラムコードを含む。描画可能領域は、画像及び別の調査データが表示されるべき診断領域である。それは、高速の、グラフィックカード支援２Ｄ及び３Ｄ描画にさえ用いられうるところの例えば表現要素（例えばＨＴＭＬ５のキャンバス）である。ユーザインタフェースは、ウェブアプリケーションの場合に表示アプリケーションによって直接にブラウザ内に生成される一般的レイアウトは勿論のこと、さらに、ユーザインタフェース／入力要素、例えばボタン、スライダー、ダイアログを含みうる。

表示アプリケーションが、レビューセッションのための要求を（通常は遠隔の）第１サーバへ送信するとき、それは、有用な実施態様において、いわゆるコーディネータエンジンによって最初に扱われる。このコーディネータエンジンは、少なくとも１つのヘルパーをサーバ環境内に割り当てることに責任を負っている。ヘルパープロセスは、各々のレビューセッション毎に新しく生成されうるか、又は準備された（ウォーム待機の）ヘルパーの集まりから選択されうる。有用な実施態様において、コーディネータエンジンは、ヘルパープロセスの接続情報（例えば、ＵＲＬ、トークン、・・）を表示アプリケーションへ回送し、それは次に表示アプリケーションからヘルパーへの１又は複数の直接接続又は通信チャネルを準備することができる。代わりにプロキシが、専用のサーバからヘルパーへのネットワーク接続を確立するために用いられうる。

コーディネータエンジンは、例えば、ライフサイクル（開始、生成、ヘルパーの割り当て及び閉じること）、ヘルパーが動作するサーバ環境内の負荷バランス、障害迂回及びユーザの初期認証に責任を負っている。後者は、表示アプリケーションからサーバ環境（コーディネータエンジン、及び／又は、ヘルパー）へと安全な接続を介して通過させられる一時的トークンの生成によって為されうる。有用な実施態様において通信チャネルは安全である。

有用な実施態様において、各表示アプリケーションは、次にヘルパープロセスへの直接接続を確立する。代わりに、プロキシが、専用サーバからヘルパーへのネットワーク接続を確立する。有用な実施例において、ＨＴＭＬ５ウェブソケットが、短い待機時間、広帯域接続のために用いられる。性能の理由により、表示アプリケーションはまた、そのヘルパーに対して多重接続を開きうる。通信を安全にすることは、通信チャネルの責任であり、例えば安全なネットワークプロトコル（ＳＳＬウェブソケットのような）を用いる。更なる性能改良のために、ストリーム又はメッセージベースの圧縮（gzipのような）が用いられうる。これらの接続は、以下で言及される少なくとも１つの「通信チャネル」のための例の全てである。

ヘルパーと表示アプリケーションとが好ましい実施態様において通信する方法が、次に記載される：医療調査データを分析するために、画像及びオーバーレイ、例えば計測、テキスト注釈、図形表示等、を表示することが通常必要である。従って、医療画像分析用ソフトウェアのほとんどどれもが、２Ｄ及び３Ｄの両方における直線、多角形、テクスチャ付き多角形、テキストのようなプリミティブの描画を規定するために用いられうるそのソフトウェアアーキテクチャにおいて何種類かの描画レイヤを有する。しばしば、表示されるべき事項は、階層的な「シーングラフ」において組織化される。階層的なシーングラフを表示（描画）することは、シーングラフノードを詳しくレビューすること、及びDirectX、OpenGLのような内在するグラフィックＡＰＩ（アプリケーション・プログラミング・インタフェース）のためのより低いレベルの描画コールを生成することによってなされる。

有用な実施態様において、ヘルパープロセスは、完全なシーングラフを維持することを担当している。例えば、ヘルパープロセスは、（通常、表示アプリケーション上の上述のユーザインタフェースを介して通信されたユーザの要求で）それらについてのいくつかの計測又は分析を実行するために、選択された医療調査データを用いることができ、そして図形的オーバーレイ、例えばテキスト注釈若しくは分析の結果を含む図表、を生成する。

しかし、ヘルパープロセスは、図表又はテキスト注釈自体を表示（描画）しない。それは、例えばこれらの事項を含んでいるシーングラフを生成するだけである。シーングラフはまた、医療調査データからの画像データを含んでいるテクスチャを含む。

ヘルパープロセスは、（例えばそのようなシーングラフから）描画コマンドのストリームを生成し、次にそれを通信チャネルを通して表示アプリケーションへ転送する。例えばヘルパープロセスは、シーングラフに関連する描画コマンドをコマンドのストリームへ符号化し、次にそれはクライアント／表示アプリケーションへ転送される。「描画コマンドのストリーム」は例えば、描画可能領域に表示されるべき画像をどのように描くかの指示を含む。有用な実施態様において、画像内の個々の事項（例えば、医療画像若しくはその一部分、及びオーバーレイ、例えば、テキスト注釈、図表、又は別の図形表示）は、個々の描画コマンドに符号化され、及び／又は、それに関係付けられたデータは、関連付けられたバッファ（例えばテクスチャ及び頂点バッファ）内に符号化され、それはまた転送され、且つそれを描画コマンドが参照する。有用な実施態様において、描画コマンドのストリームは、個々の「コマンドリスト」に分離され、その各々は、タイムスタンプを有し１つのフレームに関係し、次から次にフレームは描画可能領域に表示されるべきである（例えば、図４を参照）。このようにして、好ましくは転送された描画コマンドは、（ピクセルベースというよりは）ベクトルベースである。描画コマンドは、コマンドリスト、並びに時々は１又は数個のテクスチャ、及び／又は頂点バッファを含みうる。

表示アプリケーションは、描画可能領域に表示されるフレームの時系列を生成するために描画コマンドを翻訳する。「フレームの時系列」によって、医療画像データが画像の時系列を包含していること（これは有用なアプリケーションであるけれども）を必ずしも意味しない。「時系列」はまた、レビューセッションの通常の過程における描画可能領域で生起する変化、例えば、静的又は動的画像内で為されうるが、診断領域（描画可能領域）における変化を引き起こすところの、ユーザが表示のために異なる画像を選択し注釈等を付けること、を参照する。「フレーム」という用語はここでは、一時点で描画可能領域内に表示されるあらゆるものを記載するために用いられる。このようにして、有用な実施態様において、レンダリング、即ち（遠隔）サーバから転送される描画コマンドからの画像の生成は、表示アプリケーションによってなされる。

本発明の有用な実施態様において、表示アプリケーションは、好ましくは非常に簡易なインタプリタを有し、それは描画コマンドのストリームを通訳し且つ例えば、ブラウザ（ウェブアプリケーションの場合）のグラフィックＡＰＩのための描画コールを生成する。これは、例えばWebGL、又は別の任意のグラフィックライブラリ、例えばPaperJS又はEasIJS、である。有用な実施態様において、高性能ハードウェア加速グラフィックＡＰＩ、例えばWebGLが用いられる。ヘルパー及び表示アプリケーションは、相互に他の状態を知っているような仕方で接続される。表示アプリケーションが、描画コマンド、一連の描画コマンド、及び関連付けられたデータバッファ、例えばテクスチャ、画像、複数頂点バッファ又は頂点バッファをキャッシュできるので、ヘルパーは、キャッシュされた描画コマンドを再度は転送せず、及び／又は１のフレームと次のフレームとの間の差分にのみ関係する描画コマンドを転送する。これは、転送すべきデータの量を劇的に低下させる。なぜなら非常に多くの場合に、描画可能又は診断領域における表示は、徐々にのみ変化するからである。例えば、もしユーザの干渉によって注釈が変えられ又は直線が引かれるならば、基礎的な下層の画像（又はテクスチャ）は、ヘルパーによって再送されず、交換された事項、例えば注釈、直線、又は他のオーバーレイに関連する描画コマンドのみが再送される。このようにして、描画可能領域内の１つの事項のみが変化したとき、ヘルパーは、変化された事項に関する指示を含む更新された描画コマンドを転送しうる。そして別途、表示アプリケーションへ最新のフレームについて描画コールを再実行するように教える。

動的画像（即ちアニメ化された画像又は動画）、例えば２Ｄ又は３Ｄ画像（例えば心臓から得られた）の時系列の場合に、ヘルパープロセスは、オーバーレイを再送しないが、画像コンテンツのみ再送する。もし画像の時系列がループ状に、即ち同じ一連の画像を何度も何度も表示されるべきであるなら、同様に画像は、ユーザの機器上の表示アプリケーションによってキャッシュされる。有用な実施態様において、表示アプリケーションは、同様に各描画コマンドリストに関連するタイムスタンプをキャッシュし、ヘルパーとの相互作用なしに動的画像のループを表示することができる。

有用な実施態様において、表示アプリケーションはさらに、通常はユーザインタフェースでのユーザ入力イベントに応答して、描画可能領域内で直接に幾つかのオペレーションを実行しうる。これらの入力イベントは、ヘルパーへ転送されず、そしてそのような描画可能領域内でのオペレーションは、ヘルパーからの描画コマンドを受け取ることなしに、ユーザ入力イベントに応答して直接的に実行される。有用な応用において、これらのオペレーションは、明るさ、輝度、色付け、縮尺、及びオーバーレイの追加を含むグループから選択された表示オプションに関し、又は描画可能領域に表示された画像に対する計測の実行に、又は描画可能領域への注釈若しくは図表の追加に関する。

大部分の実施態様において、医療調査データ自体は、ヘルパーによって処理され、ヘルパーはそのような処理の結果を描画コマンドのストリームの形態で表示アプリケーションへ転送する。そのような処理は、予備処理工程、例えばスムージング、フィルタリング等、並びに別の処理工程、例えば立体表示、三次元再構築、セグメント分け、モデルの医療調査データへの適合、画像データからの医療データの抽出等を含みうる。別の処理はまた、分析工程、例えば計測、分類、又は標準化を含む。そのような処理工程は、表示アプリケーションによって転送されたユーザ入力イベントに応答してヘルパーによってしばしば実行される。プラットフォームに蓄積されるフォーマットにおける元の医療調査データは、ほとんどの実施態様において表示アプリケーションへ転送されない。

本発明のいくつかの実施態様において、表示アプリケーション及びヘルパーは、各セッションの始めで、ネットワーク接続の帯域、及び／又は表示アプリケーション若しくはユーザの機器の実行能力に基づいて、どの機能がそれぞれによって実行されるべきであるかについて同意する。例えば、もしユーザの機器のプロセッサが遅く、一方、表示アプリケーションとヘルパーとの間の通信チャネルが速いと、より多くのデータ処理機能がヘルパーによって実行され、そして結果は表示アプリケーションへ転送される。逆の状況において、より多くの機能がユーザの機器上の表示アプリケーションによって実行されうる。

ヘルパーは状態を含んでいる、即ち例えば、レビューセッションの過程において特定の表示アプリケーションへ既に転送されたものをヘルパーが記憶することを意味するので、本発明の有用な実施態様は通常、ヘルパーの状態をセーブすることを含み、「状態」は情報を含み、それは例えば、活動中の医療調査、どの計測が為されたか、及びそれぞれの結果、並びにどのビューポートが活動的であるか、場合によっては描画可能領域に表示された最新の画像を復元するために必要な描画コマンドの一組についての情報である。有用な実施態様において、「状態」又は「状態情報」は、規則的な間隔で、表示アプリケーションへ転送され且つ表示アプリケーションによって記憶される。代わりに、それはサーバ環境内に、例えばコーディネータエンジンによって記憶されてもよい。従って、もしレビューセッションが、ヘルパー又は表示アプリケーションのどちらかの故障が原因で予期せずに終了されると、それは例えばコーディネータエンジンによって割り当てられた新たなヘルパーによって続行されうる。また、レビューセッションの最後でヘルパーの状態を記憶し、それが別の時に続行されうることも有用でありうる。

本発明はまた、サーバ環境、特にヘルパープロセス及び場合によってはコーディネータエンジンにおいて実行される方法を目指している。

本発明はさらに、デジタルコンピュータの内部メモリに直接にロードしうるコンピュータプログラム製品を目指しており、この製品は、上記製品が１のコンピュータ上で動作するとき、本方法を実行するためのソフトウェアコード部分を含んでいる。それはさらに、プロセッサにより実行されるとき結果は実行される工程の系列であるところの指令の一組を含む持続的なコンピュータ可読性媒体を目指しており、それは本発明の方法を実行する。本発明はさらに、プロセッサによって実行されるべきコンピュータプログラムコード（ここで該コンピュータプログラムコードは、実行されるとき本発明の方法を実装する）を含んでいる有形のコンピュータ可読性ストレージ媒体内に実装されうる。

本発明の有用な実施態様が、添付された図面との関係でより詳細に記載されよう。

システムの概要の１例を示すブロック図である。 ユーザの機器上で動く表示アプリケーションのスクリーン・ショットの１例を示す図である。 サーバ環境によって実行される方法の１実施態様を示す図である。 描画コマンドのストリームの例を示す説明図である。 頂点バッファ及びテクスチャの例を示す説明図である。 本発明の方法によってレビューされるときの、アニメ化された画像データの説明図である。

図１の一般的なシステムの概要は、クライアント側、即ちユーザの機器上で動くプロセッサを上方に示し、そしてサーバ側を下方に、さらにネットワーク５、例えばインターネットを中間に示す。サーバ側（「サーバ環境」）は多数のマシンから成りうる。

レビューセッションを始める前又は最初に、クライアント又は表示アプリケーションは、プラットフォーム４、例えば病院又は別の医療機関のＰＡＣＳのような遠隔サーバからの、例えば調査リストの識別子を含む医療調査のリストを受け取り、そしてそれを参照符号２でユーザに表示する。ユーザは１つの調査を選択することができ、そして選択された医療調査に関する情報（例えば調査識別子を含む）は、ヘルパープロセス１２へ伝えられる。表示アプリケーション８は、通常はコーディネータエンジン１０（それは例えば、ヘルパープロセス１２を立ち上げ、分岐しかつ移住させるための責任がある）の仲介を通してヘルパープロセス１２に接続されうる。一度、コーディネータエンジンが、ヘルパープロセス１２を割り当てると、少なくとも１つの通信チャネル１４又は多重接続、例えば双方向性のウェブソケット通信が、状態を含むヘルパープロセス１２と表示アプリケーション８との間に確立される。ヘルパー１２は、表示アプリケーションから調査識別子を受取った後に医療調査データを検索するために、例えばＨＴＭＬ接続９を介して、プラットフォーム４へアクセスすることができる。

有用な実施態様において、表示アプリケーション８は、レビューセッションの開始にあたり、その能力に関する情報、例えばどのテクスチャ圧縮アルゴリズムがサポートされているかをヘルパー１２へ送出し、そしてそれに従ってヘルパーは、例えば表示アプリケーション８に対して最適化された圧縮フォーマットでテクスチャを送ることによって、その描画コマンドのストリームをそれらの能力に適合させる。

ヘルパー１２は、完全なシーングラフを維持し、且つ描画コマンドを表示アプリケーション８へ送り、それによって表示アプリケーション８が、描画可能領域にシーングラフを描くことを可能にする。ヘルパーはクライアント（＝表示アプリケーション）の状態を知っているので、それは「デルタ」更新情報、すなわち１のフレームと次のフレームとの間の差分に関する描画コマンドだけを送りうる。

表示アプリケーション８は、インタプリタ１６を含んでおり、該インタプリタは、ヘルパー１２から受信した描画コマンドのストリームを解釈又は復号することができ、並びに、直接的に実行可能であり且つユーザ機器上で、例えばウェブブラウザによって実行されるところの描画コールを生成することができる。

重要な状態は、時々刻々にヘルパー状態ストレージ１８へ記憶され、そのストレージ１８は、ユーザ機器上に又は代替的にサーバ環境内に、又は別のサーバ上にさえありうる。状態を含むヘルパープロセス１２は、大抵のアプリケーションにおいてはレビューセッション毎に働いている、即ちそれは再利用されず、各レビューセッションの後で終結させられる。

図３は、レビューセッションに対する要求２４をサーバへ送るユーザへの応答において、ユーザがユーザの機器上の医療調査データをレビューすることを可能にするための方法を示す。応答において、１又は数個のヘルパープロセス１２が、工程２２においてこのレビューセッションへ割り当てられる。工程２４で、通信チャネルが、クライアント（表示アプリケーション）とヘルパーとの間に確立され、そして多くの実施態様において、表示アプリケーションは、その能力に関する情報、例えばその利用可能な処理性能、利用可能なソフトウェアコンポーネント、例えばテクスチャ、圧縮フォーマット及び場合によっては通信チャネルの帯域をヘルパーへ転送する。通信チャネルの帯域に関する情報は、ネットワーク性能が１つのレビューセッション中に変化しうるので、レビューセッション中に規則的に更新され得、そしてヘルパーは、その描画コマンドのストリームをそれに対応して（例えば、狭い帯域のネットワークにおいてより強力な圧縮を用いる等）適合させうる。

ヘルパーはまた、工程２６において、利用可能な医療調査に関する情報を受け取り、そしてデータストレージ又はプラットフォーム４から医療調査データを検索する。工程２８において、ヘルパーは任意選択的に別のユーザ入力Ｕ１を受け取り、それが、ヘルパーに対して医療調査データを処理すること、例えば、或る画像を検索し及びテクスチャを生成し及び場合によってはそれらをオーバーレイすること、を促進しうる。工程３０において、ヘルパー１２は、描画コマンドＤ１のストリームを符号化し、それは通信チャネルを通して表示アプリケーション８へ移動する。これら描画コマンドＤ１は、表示アプリケーションによって、表示アプリケーションの描画可能領域４２内に適切な表示を描くところの適切な描画コールに解釈される。ユーザは、描画可能領域４２内において何らかの相互作用、例えば計測をするために線を引くこと、を行いうる。このユーザ入力Ｕ２は、工程３２においてヘルパープロセスへ送信され、そしてヘルパープロセスは、それに応じて別の描画コマンドＤ２を工程３４において生成し、それは表示アプリケーションへ転送される。有用な実施態様において、そのような描画コマンドＤ２は、表示アプリケーションの状態を考慮すること、特に表示アプリケーションでキャッシュされたもの従って再送される必要がないものを考慮することによって、最適化される。

ユーザが、工程３６においてレビューセッションの終了を望むとき、ヘルパープロセスは、その状態Ｓに関する情報をサーバへ又は蓄積のためにクライアント側１８へ送りうる。

図２は、クライアントの１例、即ち表示アプリケーションであって、ユーザのウェブブラウザ内で動作するウェブアプリケーションでありうるものを示す。表示アプリケーションは、描画可能領域４２を含んでいるユーザインタフェース４０を生成する。描画可能領域４２は、例えばWebGLキャンバスでもよい。それは、示されたように複数の表示ポート（この例では４つ）に分割され得、表示ポートは４２ａ、４２ｂ、４２ｃ、及び４２ｄと符号が付けられる。描画可能領域４２は、診断領域とも呼ばれる。それはスクリーン上の領域であって、表示アプリケーション８によって描画コマンドＤ１、Ｄ２のストリームから解釈されるところの描画コールが、表示／描画されるところである。さらに、ユーザインタフェースは、ユーザ入力要素、例えばツールバー４４及び任意選択的に制御部４８を含む．さらに状態バー４６及びサムネイルプレビュー５０のための領域が存在してもよい。

ヘルパープロセスと表示アプリケーションとの間の相互作用、特に描画コマンドのストリームとそれらが表示アプリケーションによってどのようにキャッシュされるかが、図４及び５に示された実施例によって説明される。

最初に、表示アプリケーションは、受信された如何なるシーン情報も持たないが、与えられた時間軸上のタイムスタンプ３０ｍｓでフレーム１００を描きたい。ヘルパーは、クライアントの状態（即ち、それが如何なるシーン情報も未だに有していないこと）について知っている、そして最初に、図５に描かれたように必要な頂点バッファ及びテクスチャを送るであろう。この実施例において、２つの頂点バッファ及び３つのテクスチャが存在する。この関連においてテクスチャは、医療調査データから抽出された画像データ（図５のテクスチャ１及び３）、又は例えばテクスチャ２のような注釈を含みうる。頂点は、例えばグラフのノード（節）である。従って、ヘルパーは、それが描画可能領域内にフレーム１００を描くこと、タイムスタンプ３０ｍｓで表示されることを可能にするために、コマンドリスト１を表示アプリケーションに送る。スクリーンをクリアした後、描画コマンド「表示ポート（０、０）×（２００、２００）」は、座標（０、０）から座標（２００、２００）まで達する上部左側のウインドウが用いられるべきことを指示する。表示アプリケーションは、その後、頂点バッファ１及びテクスチャ３を用い、そして頂点３、６、２を用いて三角形を描くことに指示される。これら描画コマンドは、表示アプリケーションによって解釈されかつ実行され、そして結果は参照符号５２で示される。

タイムスタンプ５５ｍｓでの次のフレーム１０１において、三角形は、僅かに変化させられるべきであり、頂点３及び４は動かされる。それ以外の全てのものは同じままであり、且つヘルパーは、表示アプリケーションがフレーム１００を描くための全情報を持っていることを知っているので、ヘルパーは頂点バッファ１内の頂点番号３と４とを置き換え且つ描画列を再発行するために更新コマンドを送るだけである。このことは、コマンドリスト２内に示され、頂点バッファ１はそれに従って更新される。それから、描画コマンドは、コマンドリスト１を呼ぶことであり、従って、同じ描画コマンドが、更新された頂点バッファ１（又は言い換えると、交換された頂点番号３及び４）を伴って実行される。結果が、５４で示される。この差分－符号化スキームによって、変化されたデータのみが通信チャネルを越えて転送され、ネットワークを越えて転送されるデータを非常に少ない量にする。

さらに転送されるデータ量を低減するために、本発明の有用な実施態様は、データ圧縮アルゴリズム又はデータ重複排除アルゴリズムを採用する。これは非常に効果的になされうる。なぜならヘルパーは、自身を表示アプリケーションへ適応させることができるからである。様々なユーザの機器は、例えばテクスチャ圧縮について、特に様々な移動機器について様々な技術を用いうる。したがって、本発明の任意選択的な特徴は、表示アプリケーションが、レビューセッションの開始において、技術に関する情報、及び特にそれがどのテクスチャ圧縮アルゴリズムをサポートするのか、及びそれに従いヘルパーが、描画コマンドのストリームを表示アプリケーションの能力に適合させることに関する情報を送ることである。例えばヘルパーは、クライアント（表示アプリケーション）のために最適化されたフォーマットでテクスチャを送りうる。代わりにヘルパーは、ＪＰＥＧ又はＰＮＧにテクスチャを圧縮することができ、表示アプリケーションはそれらを展開する。表示アプリケーションは、テクスチャをキャッシュし得て、そして例えばそれらをグラフィックカードに（例えばWebGLを介して）ロードしうる。WebGLテクスチャ圧縮は他のシステムと異なっているので、これは有用である。ヘルパーは、どのテクスチャ圧縮をクライアント／表示アプリケーションが必要としているかを知っており、そしてグラフィックカードにダウンロードされるべき準備の整ったテクスチャを送る。このように、クライアントコードは、圧縮されたテクスチャをキャッシュでき、且つ展開は、グラフィックカード上で「自由」である。

さらに、ヘルパー及び表示アプリケーションは、ネットワーク帯域に適合させられうる。例えば遅い通信チャネルにおいて、テクスチャの解像度は低下させられうるか又は圧縮度が上げられうる。ヘルパーは描画コマンドのみ（表示された画像ではなく）を転送するので、オーバーレイ（例えばテキスト注釈、寸法、心電図（ＥＣＧ）など）は依然として鮮明に表示されうるが、テクスチャ（画像データ）だけは低品質で表示される。

従って、ヘルパーから表示アプリケーションへ転送されるデータの総量は、例えば、ネットワークプロトコル上の圧縮及びz-deltaのような洗練された差分圧縮アルゴリズム又は別の重複排除アルゴリズムで、さらに低下させられうる。

別の実施例は、アニメ化されたフレーム、即ち医療画像の時系列のレビューである。１例は心臓画像であり、例えば５～５０の画像が１心拍の間に心臓から獲得され、且つそれは図６に示されたようにループ状に現実の速度で表示されなければならない。多くの従来技術のウェブベース医療画像ビユワーが、高フレームレートを有するアニメ化されたフレームになると失敗した。これは、例えば超音波検査の正確な診断レビューのために必要とされる。ここでは、画像の質とプレイバック速度の両方がぴったりしたものでなければならない。

この問題は、次の１例によって説明されるように、本発明によって解決できる。２５ｍｓの等間隔に分配したタイムスタンプ（１秒間に４０枚のフレームに等しい）での画像を有しているところの、与えられた医療データセットを、図６に示されたように、タイムスタンプ３０ｍｓ～１８０ｍｓまでのループでプレイしたい。図４は、タイムフレームのいくつか（フレーム１００～１０６）を列挙し、そして各フレームの三角形の座標を変えないで、むしろ三角形のテクスチャ画像を変えることを仮定している。従ってフレーム１０１については、テクスチャ画像を新たな画像で置き換える更新されたテクスチャコールを有する。

テクスチャ画像を書き換えることよりもむしろ、表示アプリケーションは今やまた、時間にわたりデータをキャッシュする。従ってそれはテクスチャ画像、及びフレーム１００から１０１へ、１０１から１０２へ、・・及び１０５から１０６へ行くための描画コマンドの差分を蓄積する。ループ内の最後のフレームであるフレーム１０６に対して、次に最初のフレームに再度戻る必要がある。表示アプリケーションは、差分又は「デルタ」を蓄積するのみであるので、それは、「系列から外れた」フレームを描くことができない。従ってその代わりに、タイムスタンプ１８０ｍｓからタイムスタンプ３０ｍｓへ戻るように、デルタを生成し、それが新たなフレーム１０７である。この系列が終了するときに、表示アプリケーションは、ヘルパーから転送される如何なるデータも無しにループ全体をプレイするための全ての情報を有している。描画プリミティブ（直線を描く又はテキストラベルを貼るような）を追加することは、描画系列の小さな部分のみの更新を起動し、そして描画アプリケーションがそれ自身でループを演じうるようなレベルに直ぐ戻るであろう。

多くの実施態様において、ヘルパーと表示アプリケーションとの間に一対一の関係があるが、多表示アプリケーション、例えばミラーアプリケーション（遠隔コンサルティング、レコーディング、マルチモニタ放送）を有する、及び／又は多ヘルパー（例えば、多試験、臨床タスクのための様々なヘルパー）を有する実施態様がある。有利な実施態様において、クライアント側（表示アプリケーション）のキャッシュアーキテクチャは、テクスチャをキャッシュする、描画コマンド（例えばフレーム描画コール）をキャッシュする、及び／又は頂点を、例えば頂点バッファ内にキャッシュする能力を含みうる。いくつかの実施態様において、WebGL（グラフィックカードテクスチャメモリ）は、表示アプリケーションキャッシュとして用いられる。

有用な実施態様において、ヘルパー状態は、表示アプリケーション（例えばブラウザ）によってユーザの機器上に記憶される：ヘルパー側（サーバ環境）のデータベース又はキャッシュを用いる代わりに、ヘルパーは状態情報をクライアント（表示アプリケーション）へ転送し且つそれをそこに記憶し、場合によってはまた圧縮及びデルタ符号化によって最適化されうる。ヘルパー環境についての要求のこの道は低く（データベースなし等）、そしてクライアント（表示アプリケーション）は、例えば１つのサーバマシンが壊れ又は最早そこへ到達できないときに、コーディネータエンジンを介してそのヘルパーを再創出できる。記憶されたヘルパーの状態データはヘルパーに関連するだけ（表示アプリケーションはこのデータでは動作しない）なので、それは、コンパクトな／圧縮されたフォーマットに符号化され且つ記憶されうる。信頼できない環境のために、この記憶されたデータは、（例えばＡＥＳで）暗号化され得、暗号化鍵（非公開／公開）は、サーバ環境内に留まる（表示アプリケーションへ送信されない）。従って、ユーザはデータを復号化できず、ユーザの機器は、別のヘルパーにより後での使用のために、ヘルパーの状態データを記憶するだけである。

有用な実施態様において、ウェブアプリケーションとしての表示アプリケーションのための同じプログラムコードは、例えばクロームのような埋め込まれたブラウザを用いることにより通常のデスクトップアプリケーション（能力の豊富なクライアント）において用いられうる。１つのコードパスだけを維持すればよいので、このことは開発コストを低下させる。

Claims (15)

1. ユーザ機器で動作する表示アプリケーション（８）によって医療調査データをレビューするための方法であって、該方法は以下の工程：
   ａ．表示アプリケーション（８）は、ユーザ機器上に描画可能領域（４２）を具備するユーザインターフェイス（４０）を生成し、且つレビューセッションのための要求を第１サーバへ送ること；
   ｂ．少なくとも１つのヘルパー（１２）が、表示アプリケーション（８）に割り当てられること、ここで、ヘルパーは、第１サーバ又は別のサーバ上のソフトウェアアプリケーションであり、且つ表示アプリケーションとヘルパーとの間に、少なくとも１つの通信チャネル（１４）が確立される；
   ｃ．表示アプリケーション（８）からの要求に応答して、ヘルパーはデータストレージ（４）データを検索し、任意選択的に医療調査データを処理し、且つ前記任意選択的に処理された医療調査データの少なくとも一部分を、表示されるべき項目、例えば医療調査データからの画像データを含むテクスチャ及び図形的オーバーレイ、例えばテキスト注釈又は図表、を包含する階層的なシーングラフを維持するために利用すること；
   及び、そのようなシーングラフから、ヘルパーは描画コマンド（Ｄ１）のストリームを生成し、それは通信チャネル（１４）を通して表示アプリケーションへ転送されること；
   ｄ．表示アプリケーション（８）は、描画可能領域に表示されるフレーム（５２、５４）の時系列を生成するように描画コマンドを解釈し、それにより描画可能領域にシーングラフを表示すること；
   を包含し、
   描画コマンド（Ｄ１）の少なくとも一部分は、ユーザの機器にキャッシュされ、ヘルパーは、キャッシュされた描画コマンドを再度は転送しない、及び／又は１のフレームと次のフレームとの間の差分にのみ関係する描画コマンドを転送する、
   上記方法。
2. 表示アプリケーション（８）は、インターネットブラウザ内で動作するウェブアプリケーション、デスクトップアプリケーション、又は携帯アプリケーションである、請求項１に記載の方法。
3. 表示アプリケーション（８）は、ユーザとの相互作用なしに、好ましくは各レビューセッションの前に、ウェブサーバからユーザの機器にロードされる、請求項１又は２に記載の方法。
4. 表示アプリケーション（８）は、インタプリタエンジン（１６）を含み、それは、ヘルパー（１２）から受け取られた描画コマンドを解釈し、且つそれらを、ユーザの機器に既に存在しているソフトウェア、及び／又はハードウェアによって可読性であるところの描画コールへ変換する能力を有する、請求項１～３のいずれか１項に記載の方法。
5. 表示アプリケーション（８）は、ヘルパーから描画コマンドを受け取ることなく描画可能領域でいくつかのオペレーションを実行する能力がある、ここで、これらのオペレーションは、好ましくは明るさ、コントラスト、色彩、オーバーレイの追加、及び拡大縮小を含むグループから選択されたオプションを表示すること、又は描画可能領域に表示された画像についての計測を実行すること、に関する、請求項１～４のいずれか１項に記載の方法。
6. レビューセッションのための要求をユーザの機器上で動作する表示アプリケーション（８）から第１サーバへ送るユーザに応答して、ユーザがユーザの機器で医療調査データを
   レビューすることを可能にするための方法であって、該方法は、以下の工程：
   ｉ．ユーザのレビューセッションのための要求（２４）に応えて、第１又は別のサーバ上で動作している少なくとも１つのヘルパープロセス（１２）が、表示アプリケーションへ割り当てられ、且つ通信情報が表示アプリケーションまで伝えられ、それは前記表示アプリケーションが、表示アプリケーションとヘルパーとの間に少なくとも１つの通信チャネル（１４）を確立することを可能にすること；
   ii．ヘルパー（１２）は、データストレージ（４）から医療調査データを検索し、任意選択的に医療調査データを処理し、且つ表示されるべき項目、例えば、医療調査データからの画像データを含むテクスチャ、及び図形的オーバーレイ、例えばテキスト注釈又は図表、を包含する階層的なシーングラフを維持するために、前記任意選択的に処理された医療調査データの少なくとも一部分を利用すること；
   そしてそのようなシーングラフから、ヘルパーは、描画コマンド（Ｄ１）のストリームを符号化し、それを通信チャネル（１４）を通して表示アプリケーションへ転送する、ここでヘルパーは図形的オーバーレイ自体を表示しないこと；
   iii．ヘルパーは、表示アプリケーションの状態について知り、且つコマンド（Ｄ２）のストリームをそれらへ適合させ、特にヘルパーは、表示アプリケーションによってキャッシュされたところの少なくともいくつかの描画コマンドを再送しないこと；
   を包含する、上記方法。
7. ヘルパー（１２）は、第１サーバ上のコーディネータエンジン（１９）によって割り当てられる、ここで、コーディネータエンジンは、ヘルパーを開始するように、及び／又はヘルパーが動作しているサーバ環境内での負荷をバランスさせるように割り当てるように構成され、及び／又はユーザの当初の認証を保証するように構成されている、請求項１～６のいずれか１項に記載の方法。
8. ヘルパー（１２）は、表示アプリケーションからユーザ入力情報（Ｕ１、Ｕ２）を受け取り、特に医療調査データに関する計測を行うことによって又は医療調査データを編集することによって、前記ユーザ入力を処理し、そしてそのような処理の結果を描画コマンド（Ｄ１、Ｄ２）のストリームの部分として表示アプリケーションへ転送するように構成されている、請求項１～７のいずれか１項に記載の方法。
9. 描画コマンド（Ｄ１、Ｄ２）のストリームは、医療データ、例えば医療画像データ、及びオーバーレイ、例えばテキスト注釈及び図形表示、を符号化し、且つ関連データバッファを含んでいる、請求項１～８のいずれか１項に記載の方法。
10. もし描画可能領域に表示されるべき項目の一部分のみが、１のフレームから次のフレームへ変化するとき、ヘルパー（１２）は、各新たなフレームに関する更新描画コマンド、特に変化された１つ又は複数の項目を変化させるためのコマンド、及び変化された項目を有する最新のフレームについての描画コールを再利用するためのコマンド、を転送する、請求項１～９のいずれか１項に記載の方法。
11. 医療調査データは医療画像の時系列を含み、医療画像はフレームの時系列で描画可能領域にループ的に表示され、且つ表示アプリケーションは、表示されるべき画像データを記憶しているデータバッファを含んでいる描画コマンドをキャッシュし、ヘルパーの中断なしにループを表示することができる、請求項１～１０のいずれか１項に記載の方法。
12. ヘルパー（１２）の状態（Ｓ）は、規則的な間隔で、特にレビューセッションの最後で、表示アプリケーションへ転送され且つそれによって記憶される、請求項１～１１のいずれか１項に記載の方法。
13. デジタルコンピュータの内部メモリ内に直接にロードしうるコンピュータプログラム製品であって、前記製品が１のコンピュータ上で、又はネットワーク、例えばインターネット、を介して接続された数台のコンピュータ上で動作するときに、請求項１～１２のいずれか１項に記載の方法を実行するためのソフトウェアコード部分を含んでいる、上記コンピュータプログラム製品。
14. システムであって、
    ‐ ユーザの機器上に描画可能領域を含むユーザインタフェースを作り出すよう構成されたユーザの機器上で動作する表示アプリケーション（８）；
    ‐ サーバ環境であって、
    ・表示アプリケーションからのレビューセッションのための要求を受け取るためのコーディネータエンジン（１０）、及び
    ・少なくとも１つの状態を含むレビューヘルパープロセス（１２）、
    を含み、
    ここで、１つのヘルパープロセスは、コーディネータエンジンによって各レビューセッションへ割り当てられ、ヘルパープロセスは、データストレージから医療調査データを検索し、且つ表示されるべき項目、例えば医療調査データからの画像データを含むテクスチャ、及び図形的オーバーレイ、例えばテキスト注釈又は図表、を含む階層的なシーングラフを維持するために前記医療調査データの少なくとも部分を利用する；
    を含み、
    そしてそのようなシーングラフから、ヘルパーは描画コマンド（Ｄ１）のストリームを符号化し、それをヘルパーは表示アプリケーションへ転送する、
    上記システム。
15. 請求項１～１２のいずれか１項に記載の方法を実行するよう構成されている、請求項１４に記載のシステム。

Images