JP2023046376A - 制御方法、処理サーバ及びプログラム - Google Patents

Abstract

【課題】医用撮影モダリティから取得されるデータについての複数の処理ユニットによる処理を適切に制御すること。【解決手段】実施形態に係る制御方法は、複数の医用撮影モダリティにコンピュータネットワークを介して接続される複数のデータプロセッサを用いて、医用撮影モダリティから取得されるデータ処理を制御するための制御方法である。制御方法は、複数の医用撮影モダリティのうちの１つの医用撮影モダリティで行われるイメージングのためのイメージング情報を取得することと、イメージングが完了する前に、複数のデータプロセッサの負荷情報を取得することと、取得した負荷情報に基づいて、複数のデータプロセッサの少なくとも一部を、イメージング情報に基づくイメージングで取得されるデータの処理に割り当てることと、取得されるデータの処理を、割り当てられたデータプロセッサで実行することとを含む。【選択図】図１

Description

本開示は、制御方法、処理サーバ及びプログラムに関し、概して医用画像処理および診断イメージングの分野に関し、具体的には医用イメージングおよび診断のためにリアルタイムで又はほぼリアルタイムで画像処理タスクを割り当てる又は分配する複数のデータプロセッサの使用に関する。

過去のイメージングシステムの設計は、高品質の画像処理を提供するために高価で専用のコンピューティング資源を使用した。高品質の画像処理とは、介入プロシージャのため必要に応じてリアルタイムに、スキャン品質制御のため必要に応じてほぼリアルタイムに、または、迅速な診断のため臨床プロシージャ回数を最小化するように可能な限り早く、画質向上を行うことを指す。専用の高価なハードウェアは、個別のイメージングシステムの利用低下をもたらすことがある。当該ハードウェアが取り付けられた機器（撮影モダリティ）が臨床プロシージャを実行するときにのみ、当該ハードウェアは使用される。

過去のイメージングシステムのソフトウェア設計では、パフォーマンスを保証するために、専用のコンピューティング資源想定を、設計実装にハードワイヤードさせた。このため複雑になる、若しくは、プロダクトライン内およびプロダクトラインにわたる設計の発展を阻むことがある。

リアルタイム又はほぼリアルタイムでのイメージングの実現に必要なコンピューティング資源は、典型的には、単一の機器専用のサーバに収納された１つまたは複数のＧＰＵから構成される。この機械は価格が高く、当該機器がイメージングを必要とするときにのみ使用される。これは、デューティサイクルのほんの小さな部分であることが多い。また、イメージング機器内において、コンピューティング資源は、要求されるパフォーマンスを保証するために、単一のソフトウェアアプリケーション（ＣＴ／ＭＲ再構成）専用である。その結果、高価なコンピューティング資源の利用が低くなる。当該単一のソフトウェアアプリケーションもまた、典型的にはＧＰＵの特定モデルおよび構成に用いられるように設計される。ＧＰＵモデルまたはその接続トポロジーが変わると、当該ソフトウェアを異なるシステムに移植するのが難しいだろう。このため、異なる機器モデルへのフィーチャの導入が遅くなることがある。

計算処理サービスの分野では、計算に優先順位をつけること、並列計算で構成されること、当該コンピューティング資源にハードワイヤードするソフトウェア設計を必要しないこと、が求められている。また、複数のイメージング機器がコンピューティング資源を共有する分野では、ソフトウェア改変なしに、当該複数のイメージング機器により共有されるネットワークにコンピューティング資源を追加して、パフォーマンスを向上させることが求められている。

米国特許出願公開第２００８／０１３３２７１号明細書 特開２００６－１１００７１号公報 特開２０１０－１０４６１４号公報

Bernstein, et. al., Simultaneously Load Balancing for Every p-norm, With Reassignments, LIPICS, ITCS-2017 No.51, pp51:1-51:14. R. Yu, V. T. Kilari, G. Xue and D. Yang, "Load Balancing for Interdependent IoT Microservices," IEEE INFOCOM 2019 - IEEE Conference on Computer Communications, Paris, France, 2019, pp. 298-306, doi: 10.1109/INFOCOM.2019.8737450. S. Taghizadeh, H. Bobarshad and H. Elbiaze, "CLRPL: Context-Aware and Load Balancing RPL for Iot Networks Under Heavy and Highly Dynamic Load," in IEEE Access, vol. 6, pp. 23277-23291, 2018, doi: 10.1109/ACCESS.2018.2817128.

本明細書等に開示の実施形態が解決しようとする課題の一つは、医用撮影モダリティから取得されるデータについての複数の処理ユニットによる処理を適切に制御することである。ただし、本明細書及び図面に開示の実施形態が解決しようとする課題は上記課題に限られない。後述する実施形態に示す各構成に対応する課題を他の課題として位置づけることもできる。

実施形態に係る制御方法は、複数の医用撮影モダリティにコンピュータネットワークを介して接続される複数のデータプロセッサを用いて、前記医用撮影モダリティから取得されるデータ処理を制御するための制御方法である。前記制御方法は、前記複数の医用撮影モダリティのうちの１つの医用撮影モダリティで行われるイメージングのためのイメージング情報を取得することを含む。前記制御方法は、前記イメージングが完了する前に、前記複数のデータプロセッサの負荷情報を取得することを含む。前記制御方法は、前記取得した負荷情報に基づいて、前記複数のデータプロセッサの少なくとも一部を、前記イメージング情報に基づくイメージングで取得されるデータの処理に割り当てることを含む。前記制御方法は、前記取得されるデータの処理を、前記割り当てられたデータプロセッサで実行することを含む。

本開示の各種態様を示すため、同様の数字は同様の要素を示し、採用されるだろう簡略化した形式が図面で示されるが、本開示は、図示される正確な配置や手段によって、または当該配置や手段に限定されないと理解される。関連技術における当業者が本開示の内容を作成及び使用する助けとなるように、添付の図面を参照として提供する。
図１は、本開示の１つまたは複数の態様に従って、計算処理サービスを用いて複数の処理部にわたって計算を分配するイメージングシステムの概略を示す概略図である。 図２Ａは、代数的計算とデータフローグラフとしてのその表現を示す図であり、各ノードまたは頂点は、本開示の１つまたは複数の態様に従って計算処理サービスにより複数の処理部にわたって分配される計算である。 図２Ｂは、本開示の１つまたは複数の態様に従った当該データフローグラフのデータフロー機械計算モデルを示す図である。 図３Ａは、本開示の１つまたは複数の態様に従った、データフローのための並列データ処理法を示すデータフローグラフである。 図３Ｂは、本開示の１つまたは複数の態様に従った、データフローのためのパイプラインデータ処理法を示すデータフローグラフである。 図３Ｃは、本開示の１つまたは複数の態様に従った、データフローのために頂点計算を同期する必要がないデータ処理法を示すデータフローグラフである。 図４は、本開示の１つまたは複数の態様に従った、データフロー例とそのキー値ストアの使用を示す図である。 図５Ａは、本開示の１つまたは複数の態様に従った、データフローグラフの頂点またはノードで計算処理サービスにより実装されるテンソルデータタイプの例を示す図である。 図５Ｂは、本開示の１つまたは複数の態様に従った、データフローグラフの頂点またはノードで計算処理サービスにより実装されるスカラデータタイプの例を示す図である。 図５Ｃは、本開示の１つまたは複数の態様に従った、データフローグラフの頂点またはノードで計算処理サービスにより実装される表データタイプの例を示す図である。 図５Ｄは、本開示の１つまたは複数の態様に従った、データフローグラフの頂点またはノードで計算処理サービスにより実装されるパラメータリストデータタイプの例を示す図である。 図６は、本開示の１つまたは複数の態様に従った、ノードまたは頂点が計算プリミティブを表すデータフローグラフとして計算を指定するステップを示すフローチャートである。 図７は、本開示の１つまたは複数の態様に従って、ドメイン固有言語での仮のデータフロー仕様が、キー値ストアを用いるデータフローグラフにコンパイルされることを示す概略図である。 図８は、本開示の１つまたは複数の態様に従った、データフローグラフのノードまたは頂点上の計算を入力および更新するために、クライアントアプリケーションと計算処理サービスがキー値ストアにアクセスする様々なステップを含むフローチャートである。 図９は、本開示の１つまたは複数の態様に従った、クライアントアプリケーション、ストリームデータソース、計算処理サービス、キー値ストア間の様々な通信を示す図である。 図１０は、本開示の１つまたは複数の態様に従った、画像再構成のために単一のホストとして使用されるＣＴスキャナシステムを示す図である。 図１１は、本開示の１つまたは複数の態様に従った、図１０の単一ホスト上での画像再構成のためのデータフローグラフとキー値ストアの例を示す図である。 図１２は、本開示の１つまたは複数の態様に従った、単一ホスト上での画像再構成のための様々なステップを示すフローチャートである。 図１３Ａは、本開示の１つまたは複数の態様に従った、複数のホスト上での例示的な画像再構成を示す概略図である。 図１３Ｂは、本開示の１つまたは複数の態様に従った、複数のホスト上での例示的な画像再構成を示す概略図である。 図１４Ａは、本開示の１つまたは複数の態様に従った、複数のイメージングシステムおよび複数のホスト上での例示的な画像再構成を示す概略図である。 図１４Ｂは、本開示の１つまたは複数の態様に従った、複数のイメージングシステムおよび複数のホスト上での例示的な画像再構成を示す概略図である。 図１５は、本開示の１つまたは複数の態様に従った、データフロー優先順位の変更を行い、データフローをストップし、データフローを再開する概略図である。 図１６は、本開示の１つまたは複数の態様に従った、ホストシステムの例示的ハードウェア構成を示す図である。

クライアントソフトウェアに気付かれることなく利用可能なコンピューティングハードウェアを発見および使用し、クライアントソフトウェアが異なるシステムに移動され得るようにクライアントソフトウェアからコンピューティング・コンポーネント・モデルと相互接続を隠し、各システム上のクライアントソフトウェアに気付かれることなく複数の医用イメージング機器が同一コンピューティング資源を共有でき、クライアントソフトウェアに気付かれることなく発見された資源にわたる計算に優先順位付けと並列処理を行い、計算を始めから再スタートする必要なく休止および再開でき、ＣＰＵ／ＧＰＵカーネル開発へのクライアントアルゴリズム実装を削減し、特定のアルゴリズムライブラリの共有を促進する、計算処理サービスを提案する。

本開示の目的のひとつは、複数の医用撮影モダリティにコンピュータネットワークを介して接続される複数のデータプロセッサを用いて、前記医用撮影モダリティから取得されるデータ処理を制御するための制御方法である。前記制御方法は、前記複数の医用撮影モダリティのうちの１つの撮影モダリティで行われるイメージングのためのイメージング情報を取得することを含む。前記方法は、前記イメージングが完了する前に、前記複数のデータプロセッサの負荷情報を取得することと、前記取得した負荷情報に基づいて生成されるグラフ情報に基づき、前記複数のデータプロセッサの少なくとも一部を、前記イメージング情報に基づくイメージングで取得されるデータの処理に割り当てること、を含む。その後、前記方法は前記取得されるデータの処理を、前記割り当てられたデータ処理資源で実行する。

本開示の１つまたは複数の実施形態を、限定ではないが例えば医用イメージングおよびリサーチなどの臨床アプリケーションに用いてよい。

本開示の他の態様によると、複数の医用撮影モダリティにコンピュータネットワークを介して接続される複数のデータプロセッサを用いて、前記医用撮影モダリティから取得されるデータ処理を制御するための制御方法を用いる１つまたは複数の追加的装置、１つまたは複数のシステム、１つまたは複数の方法、１つまたは複数の記憶媒体が、ほぼリアルタイムおよびリアルタイム使用での画像処理タスク割当を提供するために、ここで検討される。本開示の更なる特徴は、下記の説明から添付図面を参照して、部分的に理解され、部分的に明らかであるだろう。

本開示は、概して、医用イメージングおよび診断においてリアルタイム又はほぼリアルタイム使用でのタスク割当を可能にする計算処理サービスに関する。当該タスク割当またはタスク分配は、ネットワークにわたるデータプロセッサを使って、１つまたは複数の計算ノードにわたって計算を分配することにより達成される。計算処理サービスとしても知られる情報処理装置は、少なくとも１つのホストまたは複数のホストでデプロイされ、各ホストは１つのデータプロセッサまたは複数のデータプロセッサを備える。計算処理サービスは、計算プリミティブの標準セットを含むデータフローサービスを可能にする。計算処理サービスは、ＣＰＵおよびＧＰＵなどの複数のデータプロセッサを用いる医用イメージングシステムのネットワークにわたって分散する画像処理を可能にする。

計算処理サービスは、異なる撮影モダリティ間のタスク割当と複数のアクティブなイメージングシステム間の共有を可能にする。計算処理サービスで用いられ得る異なる撮影モダリティは、例えば、Ｘ線、コンピュータ断層撮影（ｃｏｍｐｕｔｅｄ ｔｏｍｏｇｒａｐｈｙ：ＣＴ）スキャン、磁気共鳴映像法（ｍａｇｎｅｔｉｃ ｒｅｓｏｎａｎｃｅ ｉｍａｇｉｎｇ：ＭＲＩ）、超音波およびＰＥＴスキャンなどがある。本開示では、計算処理サービス用いて医用撮影モダリティから取得されるデータ処理を制御する制御方法を説明するために、Ｘ線およびＣＴスキャンの撮影モダリティが使用される。しかし、Ｘ線およびＣＴスキャンに加えて、または、Ｘ線およびＣＴスキャンの撮影モダリティの代わりに、他の撮影モダリティを使用してよい。

本開示の計算処理サービスは、任意の画像再構成または関連処理を含む多くの臨床使用事例において適用可能である。リアルタイムまたは時間的制約のある現場での診断活動中のボリューム再構成、特徴抽出等の任意の計算に適用してよい。リアルタイムのイメージングにおいて、本開示は、診断または介入プロシージャ中にリアルタイムで用いるグラフ／イメージングを生成するあらゆる計算に適用する。リアルタイムまたは非リアルタイムのアプリケーションにおいて、本開示は、診断または介入プロシージャを導くあらゆる計算（例えば、フィードバック、登録等）に適用してよい。計算処理サービスは、改変なしに低価格から高価格なイメージングシステムをサポートする同一ソフトウェアを用いて、広範囲なアプリケーションを可能にする。計算処理サービスは、コンピューティング資源（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、特殊ＡＩアクセラレータ等）を、アプリケーションソフトウェアへの変更を必要とせずに追加することで、大量の取扱件数を提供する。本開示の計算処理サービスは、共有されるハードウェアおよびソフトウェアのコンピューティング資源をイネーブルにすることで、システムコストを最小化する。

ここで、例えば共有資源をもつ２種類の医用イメージングシステムまたはモダリティから構成される例示的な放射線室１０を示す概略図である図１を参照する。多くの放射線室は複数の機器を含み、機器それぞれは画像処理を行うためにコンピューティング資源を必要とする。伝統的に、当該システムは専用資源で設計されていた。本開示では、専用資源にかかるコストが高額で、平均して利用が低い、またはこの２つが組み合わさる状況を回避または最小化するために、資源共有化をある程度促進する。ある程度の共有促進により、各種システムを所有する合計コストを抑える。共有時に、Ｘ線システム１２とコンピュータ断層撮影（ＣＴ）システム２３の両方が、本例では２つの異なるホスト（３０，３８）にわたって画像再構成計算を分配する。２つのホスト（３０，３８）が図１に示されるが、本開示は単一ホストまたは複数のホストに適用してよい。ホスト３０は、ネットワーク１８を介して通信するネットワークインターフェイスカード（ｎｅｔｗｏｒｋ ｉｎｔｅｒｆａｃｅ ｃａｒｄ：ＮＩＣ）３２を備える。ホスト３８もまた、ネットワーク１８を介して通信するＮＩＣ４０を備える。両ホスト（３０，３８）は、ネットワーク１８上でデータ処理を同時に分配するグラフィックス・プロセッシング・ユニット（ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔｓ：ＧＰＵｓ）のクラスタを備える。本例のホスト（３０，３８）は例としてＧＰＵクラスタを備えるが、他の例ではホスト（３０，３８）がＣＰＵクラスタ、１つのＣＰＵまたはＧＰＵ、またはＣＰＵとＧＰＵの組み合わせを備えてよい。またホスト（３０，３８）は、例えばフィールド・プログラマブル・ゲート・アレイ（ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ：ＦＰＧＡ）または特殊人工知能（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ：ＡＩ）アクセラレータを備えてよい。放射線室１０は２つのイメージングシステム（Ｘ線システム、ＣＴシステム）のみを示すが、本開示に従って３以上のシステムを用いてよい。代わりに、本開示はまた１つのイメージングシステムのみが用いられるシナリオを熟考する。

Ｘ線システム／撮影モダリティ１２は、ネットワーク１８に分散するデータプロセッサと通信するＮＩＣ１６を有するＸ線ホストシステム１４を備える。Ｘ線ホストシステム１４は、クライアントアプリケーション２０（サードパーティのＸ線ソフトウェア）と、クライアントサービス・フレームワーク２２と、通信する。Ｘ線イメージングシステム１２に関連するクライアントサービス・フレームワーク２２は、ドメイン固有言語（ｄｏｍａｉｎ ｓｐｅｃｉｆｉｃ ｌａｎｇｕａｇｅ：ＤＳＬ）を用いて計算処理サービス３４と効果的に通信するために使用される。またクライアントサービス・フレームワーク２２は、ネットワーク１８を介して専用のキー値ストア（ｋｅｙ－ｖａｌｕｅ ｓｔｏｒｅ：ＫＶＳ）３６と通信する。ＣＴシステム２３は、ＣＴシステム２３に関連するクライアントサービス・フレームワーク２８とともに、クライアントアプリケーション２６（サードパーティのＣＴソフトウェア）と通信するＮＩＣ２５を有するＣＴホストシステム２４を備える。ＣＴホストシステム２４は、ＣＴシステム２３に関連する専用のＫＶＳ４２がＮＩＣ２５を用いてネットワーク１８を介して通信するのと同様に、ホスト（３０，３８）の計算処理サービス３４と通信するように構成される。ＣＴシステム２３に関連するクライアントサービス・フレームワーク２８は、Ｘ線システム１２のクライアントサービス・フレームワーク２２が共通ＤＳＬで計算処理サービス３４と通信するのと同じＤＳＬを使用する。クライアントサービス・フレームワーク（２２，２８）は、標準データタイプと、キー値ストアのアクセスと、データフローのライフサイクル及び実行と、を管理するように構成される。

共通コンピューティング資源を共有するために、システムは、互いの計算に干渉せずに、共有資源上で各自の処理を実行する必要がある。このため、最低でも、計算処理サービス３４が、Ｘ線システム１２内のデータフローにより生成されたデータを、ＣＴシステム２３内のデータフローで生じたデータとは別に維持する必要がある。加えて、両システムは、一部のコンピューティング資源を専用として保持する必要があるかもしれない。計算処理サービス３４は、コンピューティング資源とデータを限定するためにドメインを使用し、データフローは実行中にアクセスできる。概念においてＬｉｎｕｘ（登録商標）名前空間アイソレーションと同様に、ドメインは、例えば図１のＸ線とＣＴシステム（１２，２３）などの別々のシステムにより管理されるデータフロー群間の資源アイソレーションを提供する。各ドメインは、単一であり唯一のキー値ストア（ｋｅｙ－ｖａｌｕｅ ｓｔｏｒｅ：ＫＶＳ）と、１つまたは複数のコンピューティング資源とから構成される。コンピューティング資源は共有できるため、複数ドメインのメンバーとなることが可能である。しかしデータフローは、１つのドメインのメンバーにのみなることができ、当該ドメインのメンバーとして、当該データフローは当該ドメインのＫＶＳと関連するコンピューティング資源のみを使用できる。システムアドミニストレータはドメインを構成する。クライアントアプリケーション（２０，２６）にはプログラムでそれらを管理する手段がない。

データフロー計算は、ＫＶＳ（３６，４２）に記憶され、ネットワーク１８上の計算処理サービス間でグローバルに、分散して、かつ共有されるように実装されたデータアイテム上で動作する。キーは文字列であり、値は標準データタイプ（例えば、スカラ、ベクトル、画像、ボリューム、表等）の小さなセットに由来し得る。クライアントサービス・フレームワーク（２２，２８）はキーによりＫＶＳ（３６，４２）へアクセスする。同時アクセスのための同期化はクライアント（２０，２６）には不可視である。ＫＶＳは、全システム上のソフトウェアクライアントに可視である。ＫＶＳは、同様に、クライアントロケーションとは関係なく行動する。ＫＶＳは物理的に分散され、ＫＶＳ値は計算を実行することで必要な場所に移動してよい。ＫＶＳに記憶されたデータのライフサイクルは、クライアントソフトウェアから独立している。複数のＫＶＳが存在できる。各イメージングシステムは１つのＫＶＳに関連する。マルチテナンシーをサポートするために、特定のイメージングシステムに所属するデータフロー計算は、当該イメージングシステムの関連ＫＶＳにのみアクセスできる。

計算処理サービス３４は、コモディティ・ハードウェアのクラスタ上で処理指定を行うソフトウェアサービスである。クライアントアプリケーション（２０，２６）は、実行対象処理をデータフローグラフとして指定する。この表現は、多くの画像処理タスクにみられる、クラスタに依存しない、粗粒の、並列性を表現するために選択される。グラフの各ノードまたは頂点は、処理ステップを指定する。２つの頂点をつなぐ各エッジは、ある処理ステップから次のステップへと結果がたどる経路を指定する。計算処理サービス３４は、データフローグラフとして指定される計算の実行を担うソフトウェアコンポーネントである。実行は、コンピューティング資源、ＣＰＵ、ＧＰＵ、ＦＰＧＡ、特殊ＡＩアクセラレータ等の分散クラスタで生じる。図１に示す例では、計算処理サービス３４は、ＣＰＵまたはＧＰＵクラスタをもつホスト上に位置する。しかし計算処理サービス３４は、Ｘ線ホストシステム１４および／またはＣＴホストシステム２４などの撮影モダリティのホストシステム上に存在してもよい。図１に示される放射線室１０は例にすぎず、本開示により様々な異なる構成が検討される。

クライアントアプリケーション（２０，２６）は、クライアントサービス・フレームワーク（２２，２８）を用いて動的にデータフローグラフに優先順位をつける。計算処理サービス・インスタンスは、当該データフローとして実行において同一優先順位であるイネーブルなデータフロー頂点をキューに入れる。ＧＰＵまたはＣＰＵにディスパッチされると、頂点は当該ＧＰＵ／ＣＰＵのランタイム環境で同一相対優先順位にて実行する。データフロー仕様は、使用のための頂点実装のタイプを定義する。計算処理サービス３４は、その実装（例えば、ＧＰＵカーネルを起動する、ＣＰＵスレッドをアクティブにする、アプリケーションへメッセージする等）に応じて、頂点をディスパッチする。ディスパッチ標的は、ローカルまたは遠隔の任意のコンピューティング資源であってよい。スレッドは遠隔ホスト上でアクティブにできる。

ディスパッチは、負荷バランシング・ポリシーを用いて頂点を実行するコンピューティング資源を選択する。計算の開始と完了は、全ての計算処理サービス・インスタンスへの負荷メトリクスを更新する。負荷バランスは、資源選択をネットワーク経路指定として扱う。ディスパッチ計算は、宛先へパケットを経路指定すること類似する。所与のディスパッチャから可視なコンピューティング資源は、メッシュトポロジーで論理オーバーレイネットワークを形成する遠隔ホストとしてみなされる。各経路は、遠隔コンピューティング資源上の現在の負荷と等しい関連コストを有する。ディスパッチは、最もコストが低い経路をもつ資源に、計算を送る。経路指定プロトコルは、計算のスタート時または終了時など経路変更のたびに、経路コストを更新する。

共有される計算処理サービス３４は、マルチテナントとマルチバージョン動作を可能にする。異なるシステムが同一のコンピューティング資源を同時に使用できる。同一の処理サーバのソフトウェアの異なるバージョンが、同一のコンピューティング資源を同時に使用してよい。各データフローは、使用が好ましい頂点実装のバージョンを指定できる。このように同一アルゴリズムの複数のバージョンを、下位互換性のために用いてよい。

データフローは、計算処理サービス３４が画像処理および類似計算を行うために用いるプログラムである。生成されると、データフローは、クライアント視点においてアプリケーションのように管理され、その実行をスタート、ストップ、休止、または再開できる。データフローは、方向性をもったグラフとして処理を表す。当該グラフは、入力と出力がつながったプリミティブオペレーションの合成である。当該プリミティブオペレーションは、当該グラフの頂点として表され、プリミティブ間のつながりはエッジとして表される。グラフエッジは、あるプリミティブの出力を別のプリミティブの入力につなぐ。これらは方向性を有し、生成された出力データは他のプリミティブの入力にのみ流れ、他の方向に向かわない。

図２Ａは、代数式を計算するデータフローグラフ４８の簡略例である。式は、プリミティブ算術演算から（７２，７４，７６，７８）から構築された合成計算である。各オペレーションの出力は、エッジ（５４，５６，５８，６０，６２，６４，６６，６８，７０，７１）により指定される次のオペレーションの入力へ向かう。エッジのトポロジーは、当該式の要求されるサブ表現式が計算、再使用等されるように設計される。実際には、画像処理ドメインのために使用されるプリミティブ計算は、ずっと複雑で粗粒である。例えば高速フーリエ変換、予測、推論等のアルゴリズムが典型例だろう。同様に、エッジを通過するデータは、本例に示す単純なスカラタイプよりも複雑なタイプを含むだろう。本例のデータフローグラフ４８は、クライアントアプリケーションから得られる値をもつ入力Ｘ５０と入力Ｙ５２とを含む。データフローグラフ４８の結果がｃ８０とｚ８２により表され、その後ＫＶＳに記憶され得る。

データフローグラフは、計算のデータフローモデルを用いて実行する。このモデルは、実行を完了する前の頂点の結果として利用可能なデータをもつエッジの全ての頂点を並列に実行してグラフを実行する。図２Ｂは、データフロー機械計算モデルを表す。初期値ｘ０８４とｙ０８６は、撮影モダリティからのクライアントアプリケーションなどの外部ソースから与えられる。当該エッジを通過するトークン（８８，９０）として示される全ての入力弧線にデータがあれば、計算を実行する。計算では、９２を実行するときに入力弧線上のデータを消費する。計算では、計算結果のコピーを全ての出力弧線（９４，９６，９８）に置く。

当該計算のデータフローモデルは、図３Ａ～３Ｃで概略する理由により利点がある。図３Ａは、当該計算のデータフローモデルの並列の利点を示す。例えばパス（１００，１０２）とパス（１０４，１０６）は、「ｘ＋ｙ」と「４」からの結果が存在する前提で、並列に実行できる。図３Ｂは当該計算のデータフローモデルに関連するパイプライン利点を示す。入力頂点／ノードｘおよびｙ（１０８，１１０）の新しい値が継続して与えられると、任意のポイントにおいて各エッジはデータを含むことができる。図３Ｃは、当該計算のデータフローモデルの単純化利点を示す。エッジ上を通るデータは共有されず、そのため頂点での計算は独立している。頂点計算を同期する必要がない。

データフローはアルゴリズムで内在的な並列性を示すことができ、頂点関数が適切に設計される（例えば、高速フーリエ変換のように固有だが汎用的関数）場合は、内在的並列性を最大化できる。さらに重要なことは、並列性が、データフローが実行されるコンピューティングクラスタ構成とは独立した方法で表現されることである。これにより、データフローの実行が、クライアントソフトウェアへの変更なしに、任意のサイズまたはトポロジーのコンピューティングクラスタ環境に適応できる。データフロー実行モデルは、エッジ上のデータが頂点実行により生成されると、当該データをキューに入れる。これにより、データフローは、データフローグラフまたはその一部が線形シーケンスの頂点から構成されるときに、パイプライン実行できる。そのため、多くの順次ステップを有する計算は、高いスループットを得られる。データフロー実行では、頂点出力のデータが複数の宛先に送られる場合は、頂点出力を共有しない。下流にある各頂点は、当該出力の自分のコピーとしてみえるものに対して動作する。そのため、下流の頂点は、別々のデータに動作するため、その実行を同期させる必要がない。これにより、頂点は、クラスタのどこであっても、並列に実行できる。

効率が良く、フレキシブルで、リリース可能なライブラリであるために、本開示では、個別のオペレーション間の関係における計算を表すためにデータフローグラフを用いる。データフローは並列計算で広く用いられるプログラミングモデルであり、データフローグラフにおいて、ノード／頂点は計算のユニットを表し、エッジは処理ユニットにより消費または生成されるデータを表す。データフローは、シンプルなＤＳＬで指定される。クライアントは、コンパイルするデータフロー仕様を計算処理サービスに送信して、データフローオブジェクトを構成する。計算サービスは、コンパイルされたフォームを、現在のドメインのＫＶＳ内に、データフローのデータタイプとして置く。データフローがＫＶＳに置かれると、実行可能な状態となる。

グラフを用いて計算を表すことで、オペレーションを表すためにノード／頂点を、並列実行可能なオペレーションを特定する従属性を表すエッジを、使用する利点が生じる。グラフという周知のデータ構成であり、実行スピードを最適化する目的で解析可能である。グラフは、言語ニュートラル且つプラットフォームニュートラルな計算の表現である。本開示では、グラフを記憶するために、構造化されたデータを直列化する、シンプルな言語ニュートラル、プラットフォームニュートラル、且つ拡張可能なメカニズムを用いる。グラフのノードは全て、独立の装置および異なる機械に設置できる。計算処理サービスは、ノード間の通信に対処し、グラフの実行が正しいことを保証する。また、計算処理サービスは、あるオペレーションはある装置でより良く行われることを把握して、複数の装置にわたるグラフを区分けすることができる。

本開示は、画像再構成能力を、リアルタイムおよび非リアルタイムのコンテキストに適用されるシステム設計へ組み込む。本開示は、ボリューム再構成、特徴抽出等のための任意の計算に、リアルタイムまたは時間的制約のある現場での診断活動中に、適用してよい。当該計算は、診断または介入プロシージャ中に使用するイメージングをリアルタイムで生成してよい。本開示は、診断または介入プロシージャを導く任意の計算に適用可能である。

計算処理サービスのキー値ストア（ＫＶＳ）は、実行中にデータフローがアクセスする全てのデータを記憶する。当該ＫＶＳはキー―値ペアを含み、各キーは文字列であり、対応する値はスカラ、テンソル、表、パラメータリスト、またはデータフローを含むサポートされたデータタイプのうちの任意の１つでよい。あるＫＶＳは、ドメインが根底にある（underlying）コンピューティングクラスタにわたって分散している場合であっても、当該ドメイン内の全てのデータフローで可視である。図４は、データフロー例とそのＫＶＳの使用を示す。４つのＫＶＳノード（１１２，１１４，１１６，１１８）は、ＫＶＳ１２０からスカラ値を読み出し、データフローに入力を与える。第５のＫＶＳノード１２２は、データフロー結果をＫＶＳ１２０に書き戻す。ＫＶＳ１２０は、キー―値ペアの一部の文字列であるキー１２４と対応する値１２６とを含む。

データフローは、入力／出力頂点をその設計に組み込むことで、ＫＶＳアイテムの読み出し及び書き込みを行う。ＫＶＳアイテムがクライアントサービス・フレームワークにより更新されるたびに、入力として当該アイテムを用いるデータフローが当該更新を受け取る。同様に、あるデータフローがＫＶＳアイテムを書き込むたびに、当該データフローの読み出しをブロックしたクライアントは、当該更新でブロックを解除するだろう。クライアントサービス・フレームワークは、データフローが入力として用いるＫＶＳアイテムを書き込むことで、当該データフローの計算を繰り返しトリガし、その後、当該データフローが生成するＫＶＳアイテムを読み出す。ＫＶＳはドメイン内の全てのデータフローに共有される。このことは、同一ドメインの２つのデータフローが同一キーを使用する場合、２つのデータフローは当該キーに関連する同一値を参照することを暗示する。ＫＶＳは設計で共有され、データフローの合成を可能にする。あるデータフローの出力を特定のＫＶＳアイテムに送ることができ、第２のデータフローは同一アイテムを自分の入力として使用できる。より一般的には、一対多の合成が可能である。データフロー出力が、次に複数のデータフローによりそれらの入力のために使用されるＫＶＳアイテムを更新する場合は、当該アイテムの各更新が関連するデータフローの入力をトリガできる。

画像処理ソフトウェアの各種実装では、アプリケーション固有のデータタイプを使用する。例えば画像は、磁気共鳴（ＭＲ）アプリケーションソフトウェアで用いられるものとは異なるＣＴアプリケーションソフトウェアのための表現を有してよい。表現におけるこれらの相違は実装のソースコードにおいて可視であり、これが各処理アプリケーションを、データタイプの表現に依存、典型的には強く依存させる。これにより、あるアプリケーションのために開発された処理は、別のアプリケーションでの使用に簡単に適応できない。画像処理アルゴリズムが簡単に再利用できることが理想である。再利用を促進するため、計算処理サービスは、一般的データタイプのうちの少数のセットのみの使用をサポートする。データフローの各頂点は、このセットからのデータタイプのみを受け付けることができ、同様に、このセットに属するデータタイプのみを出力できる。計算処理サービスは、テンソルタイプ、スカラタイプ、表タイプ、パラメータリストタイプ、データフロータイプ、の５種類のデータタイプを利用してよい。

ここで、計算処理サービスに使用される各種データタイプが示される図５Ａ～５Ｄを参照する。テンソルは、テンソルフロー（ＴｅｎｓｏｒＦｌｏｗ）のテンソルに類似する。有限の次元数の多次元アレイである。各次元はサイズ、即ち、当該次元に沿うエレメント数を有し、当該テンソルに「形状」を与える。図５Ａにおいて、テンソル例は、１次元のテンソル１２８と、２次元のテンソル１３０と、３次元のテンソル１３２とを示し、それぞれ固有の形状を有する。テンソルエレメントは実数または整数のいずれかを含むが、所与のテンソルの全てのエレメントが同一タイプでなければならない。

図５Ｂは、スカラタイプ１３４の例を示す。スカラタイプ１３４は、単一の実数または単一の整数のいずれかを含むことができる１つのエレメントの一次元テンソルであるスカラを備える。スカラはよく使用されるため、計算処理サービスは、テンソルのこの特殊性を便宜上与える。図５Ｃは、表タイプ１３６を示す。表タイプ１３６は、リレーショナル・データベースのテーブルに類似する。エレメントの２次元アレイであり、各列は名前を有し、各行は固有の数的識別子を有する。テンソルとは異なり、表エレメントは、文字列、スカラ、またはテンソルのデータタイプのうちの１つであり得る。表は様々な方法で検索できる。行、列でスキャンできる、または、個別のエレメントを直接インデックス化できる。図５Ｄは、パラメータリストタイプを示す。パラメータリストタイプは、１行のみ有する表であるパラメータリスト１３８を備える。パラメータリストは、スカラのようによく使用されるため、計算処理サービスは表のこの特殊な形式の表を便宜的に与える。パラメータリストは１行だけであるため、エレメントを置くまたは当該リストをスキャンするために、行インデックスは必要ない。リストエレメントは、列の名前のみでインデックス化できるので、パラメータリストはキー―値ペアのリストまたはマップに相当する。

コンパイルされたデータフローは別のデータタイプであり、コンパイルされると、データフローは、当該データフロー名をＫＶＳキーとして用いて、また、コンパイルされたデータフローをＫＶＳ値として用いて、計算処理サービスのＫＶＳに置かれる。当該データフローの表現はクライアントに不可視である。当該データフロータイプは、単一のオブジェクトとして扱われるバイトのシーケンスである。しかし、クライアントサービス・フレームワークは、コンパイルされた表現をクライアントが選択したファイルにセーブするために、ＫＶＳから当該コンパイルされたデータフローを読み出すことができる。クライアントは、後にこのファイルを再び開き、当該データフローをメモリに読み込み、ＫＶＳに書き戻すことができる。ＫＶＳが更新された後、当該データフローを、任意の他のコンパイルされたデータフローのように扱うことができる。当該データフロータイプは、関連するコンパイルオーバーヘッドなしに、データフローを復元する手段を提供する。

図６は、計算処理サービスに関連するデータプロセッサと同様に、医用撮影モダリティに関連するクライアントアプリケーションでデータフローを設定し、当該データフローを開始する処理を示すフローチャートである。ステップＳ１０では、クライアントサービス・フレームワークは、クライアントアプリケーションから受け取った情報に基づき、計算を指定する。当該クライアントアプリケーションから受け取った情報は、例えばＸ線システムまたはＣＴシステムなどのクライアントアプリケーションに関連する撮影モダリティから得られたイメージング情報を含む。計算は、画像再構成または画像処理計算を含んでよい。しかし、計算は画像処理や画像再構成に限られない。計算は人工知能推論、統計等を含み得る。その後、クライアントアプリケーションは、ステップＳ２０で当該計算を計算処理サービス３４へデータフローグラフの形式で送る。計算処理サービス３４は、当該データフローグラフを作成および実行するために、ステップＳ３０でデータフロー仕様をコンパイルする。データフローグラフを受け取ると、計算処理サービス３４はステップＳ４０でデータフローグラフを実行する。計算処理サービス３４がネットワークをわたって利用可能な複数のデータプロセッサを有する場合は、計算処理サービス３４は、当該データフローグラフのノードを任意の（ローカルまたは遠隔の）コンピューティング資源にディスパッチしてよい。当該データフローグラフのノードのディスパッチは、負荷バランシング情報を用いて実行するためのコンピューティング資源を選択する。負荷バランシング情報は、ネットワーク経路を解析して計算処理サービス３４が得てよい。各経路は、遠隔コンピューティング資源上の現在の負荷に等しい関連コストをもつ。計算処理サービス３４は、コストが最も低い経路をもつ資源に計算をディスパッチする。経路指定プロトコルは、計算開始または終了の結果としての経路変更のたびに、経路コストを更新する。図７は、計算処理サービス３４によりデータフローグラフオブジェクト１４２にコンパイルされる仮のデータフロー仕様１４０を示す。データフローグラフオブジェクトは、その後、ＫＶＳ１４４からの値を用いて実行される。クライアントサービス・フレームワークは、データフローグラフオブジェクトを生成するためにデータフロー計算を指定するように、ドメイン固有言語を使用する。

図６に戻り、ステップＳ４０で、計算処理サービス３４はデータフローグラフを生成および実行する。ステップＳ５０で、計算処理サービス３４は、トリガされた計算プリミティブをディスパッチする。計算プリミティブは、計算処理サービス３４で、計算処理サービス３４上に記憶されたアプリケーションを介して、事前に登録される。計算処理サービス３４はまた、トリガされた計算プリミティブをディスパッチするために、共有ライブラリとＧＰＵカーネルを備える。言い換えると、計算処理サービス３４は、生成されたデータフローグラフのトリガされた頂点を実行する。複雑な計算が、計算プリミティブを表す頂点をもつデータフローグラフとして指定される。全ての計算プリミティブは、共有ライブラリとしてパッケージ化される。計算プリミティブは、ＧＰＵカーネル、共有オブジェクトまたはアプリケーションとして実装され得る。データフローグラフ内の各計算プリミティブ（頂点／ノード）は、計算処理サービス３４でデプロイされるソフトウェアライブラリ（共有ライブラリ）として構築およびパッケージ化されるいくつかのソフトウェアに対応する。各ライブラリは、計算処理サービス３４が当該頂点／ノードを実行するために呼び出し方法を知っている周知の関数をエクスポートする。計算処理サービス３４がスタートされると、これらのライブラリの格納エリアをスキャンし、その関数をサーバに動的にリンクする。その後、クライアントサービス・フレームワークがデータフローを作成すると、計算処理サービス３４は当該データフローグラフをコンパイルする。コンパイラがドメイン固有言語の各頂点定義に遭遇すると、頂点を実装にマッチングするために、内部頂点データベースを検索する。共有ライブラリは、画像処理データフローに必要なプリミティブコンポーネントを実現するために調査員または技術者が開発したソフトウェアライブラリである。計算処理サービス３４のデータフローエンジンまたはデータフローサービスは、入力が利用可能になると、そのグラフノードのセットを並列にディスパッチして、データフローグラフを実行する。データフローグラフの実行は、その実行により計算処理サービス３４のソフトウェアが当該グラフを介してデータフローを作る処理である。

グラフ実行モデルは、計算のデータフローモデルを使用する。データフローの各頂点を調査して、全ての入力が存在するか否かを決定する。存在する場合は、頂点は実行可能であるとみなされ、実行可能な頂点のセットに加えられる。データフロー内の全ての頂点をチェックすると、実行可能な頂点のセットが並列実行するようにディスパッチされる。当該セット内の各頂点を同時に実行するために十分なコンピューティング資源がある場合は、実行は完全並列化を達成する。資源が少ない場合は、ある程度の直列化が起こるだろう。いずれの場合も、並列化の程度はデータフローから独立している。各頂点が実行を完了すると、その出力が、全ての送信エッジに沿って１つまたは複数の宛先（すなわち、従属頂点）へと引き渡される。出力は宛先頂点の新たな入力となる。当該処理は、データフロー内の全ての頂点が実行不能になるまで繰り返される。計算のデータフローモデルは、入力の全てが存在する場合に、および、その場合に限り、頂点を実行する。実際には、「入力の存在」と実際の頂点の「実行」の間には、ある程度の時間差がある。入力が存在するとき、頂点は実行する状態にあるが、まだ実行していない。実行する状態にあるがまだ実行していないとき、頂点はトリガされたと言える。トリガされた頂点は、その後、実行スタートを命令されなければならない。その専門用語が頂点のディスパッチである。

ここで、本開示に従った計算処理サービス３４によりデータフローを計算する処理を概略する各種ステップを含むフローチャートである図８を参照する。クライアントサービス・フレームワークで構築されライブラリとしてパッケージ化されたクライアントアプリケーションが、ステップＳ１００で計算の実行をトリガするために入力を送るときに、計算を開始してよい。入力はキーとしてＫＶＳに記憶される。若しくは、計算の実行をトリガするために、クライアントアプリケーションの代わりにサードパーティが入力を送ってよい。計算の状態、即ち、データフローグラフ内の全ての頂点オペランドのセットは、グローバルであり、分散され、共有された連想記憶であるＫＶＳに維持される。ステップＳ１１０にて、計算処理サービス３４はオペランドにアクセスし、後に値としてＫＶＳに記憶される結果を生成する。計算処理サービス３４は、アプリケーションと、共有ライブラリと、ＧＰＵカーネルを用いて結果を生成する。例えば、ＧＰＵアクセスはメモリまたはＫＶＳに記憶された値にアクセスする。値がアクセスされると、計算処理サービス３４のＧＰＵカーネルは、ステップＳ１２０で結果を生成し、ステップＳ１３０で当該結果をＫＶＳに戻し記憶する。その後、クライアントサービス・フレームワークを用いるクライアントアプリケーションは、ステップＳ１４０で利用可能になると当該結果を受け取る。クライアントアプリケーションは、ＫＶＳの更新時に結果を受け取る。

ここで、クライアントサービス・フレームワーク１５０のプログラミングビューを示す概略図である図９を参照する。クライアントサービス・フレームワーク１５０は、ステップＳ２００でデータフロー仕様１５１をコンパイルして「例」にラベル付けられたデータフローを作成し、当該データフローをネットワーク上の計算処理サービス１５２または複数の計算処理サービスに送信する。ステップＳ２０１で、計算処理サービス１５２はキーである「例」とデータフローグラフを値としてＫＶＳ１５６に記憶する。その後クライアントサービス・フレームワーク１５０は、ステップＳ２１０で、命令を計算処理サービス１５２へ送信してデータフロー「例」の計算を開始してよい。ステップＳ２０２とＳ２０３において、入力値がストリーミングデータソース１５４からＫＶＳ１５６へ送信される。ストリーミングデータソース１５４は、例えば入力を生成するサードパーティのデータソースであってよい。若しくは、入力値は、イメージングシステムからクライアントサービス・フレームワーク１５０を介してＫＶＳ１５６へ送信されてよい。入力が存在しデータフローが結果を計算すると、ステップＳ２２０でクライアントサービス・フレームワーク１５０はＫＶＳ１５６からの結果を要求し、ステップＳ２３０でＫＶＳ１５６は当該結果をクライアントサービス・フレームワーク１５０に戻す。計算処理サービス１５２は当初は入力を待ち、その後入力を受け取ると、計算処理サービス１５２は、クライアントサービス・フレームワーク１５０がＫＶＳ１５６にアクセスして受け取ることができる結果で、ＫＶＳ１５６を更新する。ステップＳ２０５とＳ２０６で追加データがストリーミングデータソース１５４からＫＶＳ１５６へ送信されるときに、結果を更新してもよい。計算処理サービス１５２は、次の結果を計算するために、ＫＶＳ１５６を更新する。

ここで、コンピュータ断層撮影（ＣＴ）スキャナシステム１６０が複数の投影を異なる向きで取得する図１０を参照する。下記例では、当該投影は単一のチャネル１６２からである。なお、実際には、検知器は複数のチャネルを有する。単一スライスの再構成は、２次元画像１６４を形成するために、複数の１次元投影を用いる。図１０は、本開示に従った、単一ホスト（ＣＴイメージングシステム１６０）での画像再構成の例である。単一ホストからの画像再構成は、図１１に示すデータフローグラフを備える。当該データフローグラフは、単一ホストでの再構成のためのものである。基本のファンビーム再構成のためのデータフローグラフが示される。本例において、データフローグラフは一度に１つの投影を受け付けるが、処理パイプラインを満たすために十分な投影が送られると、最大４つのオペレーションを並列で実行できる。頂点ａ １６６は、ベクトルとしても知られている１次元テンソルタイプなどの投影である。頂点ｂ １６８は、投影数と投影サイズ（パラメータリスト）を表す。頂点ｃは、フィルタ係数アレイ（１次元のテンソルタイプデータ）である。頂点ａ，ｂ，ｃ（１６６，１６８，１７２）はデータフローグラフの入力を表す。頂点１ １７４は重み投影を表す。頂点２ １７６はフィルタ投影を表し、頂点３ １７８は逆投影、即ち、画像への投影を表す。頂点３により定義される計算は、単一ベクトルである投影から画像を生成する。頂点４ １８０は、特定の限界まで画像を蓄積する。限界は頂点ｂ １６８に定義される投影数により決定される。頂点１から４（１７４，１７６，１７８，１８０）は、オペレーション頂点を表す。出力頂点ｄ １８２は、画像としても知られている２次元の「テンソルタイプ」であり、データフローグラフの出力または結果を表す。

データフローグラフ入力／出力頂点は、ＫＶＳエレメントを読み出し／書き込みする。入力頂点は、クライアントに書き込まれるすぐに、対応するＫＶＳエレメントを読み出す（または取得する）。出力頂点は、データが当該出力頂点に到着すると、対応するＫＶＳエレメントを書き込む又は更新する。図１１において、ＣＴシステム１６０に関連するＫＶＳ１７０が示される。ＫＶＳ１７０は、データフローグラフの入力および出力頂点を、各キーに関連する値と同様に、ＫＶＳ１７０のキーに記憶する。データフローグラフの入力および出力頂点は、ＫＶＳ１７０のエレメントを読み出しおよび書き込みする。入力頂点は、クライアントサービス・フレームワークにより書き込まれるとすぐに、対応するＫＶＳ１７０のエレメントを読み出す（または取得する）。出力頂点は、データが当該出力頂点に到着すると、対応するＫＶＳ１７０のエレメントを書き込む（または更新する）。

図１２は、単一ホストでの画像再構成処理を示すフローチャートである。ステップＳ３００では、クライアントアプリケーションと、実行可能な全計算処理サービスコンポーネントを含むクライアントサービス・フレームワークが、単一ホストにインストールされる。計算処理サービスのコンポーネントは、クライアントサービス・フレームワーク、共有ライブラリ、内蔵アルゴリズム、頂点実装を含む。例えば頂点実装は、図１３に示すように、重み、フィルタ、逆投影等を含んでよい。ステップＳ３１０において、計算処理サービスはシステムスタートアップ中に起動される。本例では、システムはＣＴ撮影モダリティ１６０である。計算処理サービスは、アルゴリズムと同様に、ネットワーク上のＧＰＵまたはＣＰＵクラスタなどの利用可能なコンピューティング資源を発見するように構成される。本例では、ＣＰＵ１つとＧＰＵ１つが発見される。ステップＳ３２０において、クライアントアプリケーションが起動すると、クライアントサービス・フレームワークは計算処理サービスを発見する。ステップＳ３３０において、画像再構成データフローが生成される。これは、クライアントサービス・フレームワークがデータフロー仕様を計算処理サービスに送って再構成データフローを作成するときに生じる。ステップＳ３４０において、計算処理サービスはデータフロー仕様をコンパイルし、データフローの実行をスタートする。しかし、データフローグラフの頂点は実行可能ではないため、計算は生じない。ステップＳ３５０において、画像再構成パラメータがＫＶＳに記憶される。実際には、クライアントサービス・フレームワークが画像再構成パラメータをＫＶＳに送る。ステップＳ３６０において、クライアントサービス・フレームワークはＣＴシステム１６０から投影を受け取る。クライアントサービス・フレームワークに送られた撮影モダリティ（ＣＴシステム１６０）から投影を生成するために始める取得が開始される。事後プロシージャの場合は、ストレージから読み込んで、バッチされたまたはキューに入った使用事例の投影を生成してよい。

次に、ステップＳ３７０において、クライアントサービス・フレームワークは投影をＫＶＳに書き込む。若しくは、ＣＴシステム１６０が投影をＫＶＳに直接書き込んでも良い。ステップＳ３８０において、頂点での計算が開始する。データフロー入力頂点は、投影が到着するとＫＶＳから各投影を取り、その出力エッジで投影を生成する。入力／出力頂点計算は、ＫＶＳ内のアイテムを取る、読み出す、または書き込むと定義される。ステップＳ３９０において、画像再構成結果が蓄積される。ここで処理頂点はイネーブルであるため、計算処理サービスは実行のためＧＰＵに頂点をディスパッチする。データフローが逆投影された画像のシーケンスを生成すると、再構成結果が蓄積される。同時に、クライアントアプリケーションは残りの投影を送り続ける。ステップＳ４００において、最後の投影が処理される。最後の投影が処理されると、データフロー蓄積頂点は最終結果をその出力エッジに書き込む。そして、出力頂点は結果をＫＶＳに書き込む。ステップＳ４１０において、結果がＫＶＳに到着すると、クライアントアプリケーションは結果を受け取る。

図１３Ａは、本開示の態様に従った画像再構成のための複数ホストシステムの概略図である。ソフトウェアコンポーネント１９０は、単一ホスト再構成の使用事例と同様に、複数のホストシステム（１９４，１９６）にインストールされる。計算処理サービス１９２は複数のホストシステム（１９４，１９６）と通信し、ネットワークにわたって分散する。計算処理サービスのコンポーネントは、クライアントサービス・フレームワーク、共有ライブラリ、内蔵アルゴリズム、頂点実装を含む。例えば頂点実装は、重み、フィルタ、逆投影等を含んでよい。計算処理サービス１９２は撮影モダリティ１９７のシステムスタートアップで起動するように構成される。計算処理サービス１９２は、利用可能なコンピューティング資源とアルゴリズムを発見するように構成される。本例では、２つの異なるホスト（１９４，１９６）に属するＣＰＵとＧＰＵが発見される。撮影モダリティ１９７に関連するクライアントアプリケーションが起動すると、クライアントサービス・フレームワーク１９８が計算処理サービス１９２を発見する。画像再構成は、図１３Ｂで示すように複数の計算資源にわたって並列実行２００するために、データフローの頂点２０１がディスパッチされ得ることを除いて、図１２のフローチャートについて上述した単一ホストの使用事例と同様に進む。

図１４Ａは、本開示の態様に従った複数の撮影システムおよび複数のホストでの画像再構成を表す概略図である。なお、ネットワークとネットワークインターフェイスカードは図１４に示されていない。本実施形態では、ソフトウェアコンポーネントは、複数のシステムホストと計算資源に、複数ホストシナリオに関する図１３Ａに示したものと同じ方法でデプロイされる。ホストシステム２０２は、ホストシステム２０２にデプロイされるＸ線クライアントソフトウェアとクライアントサービス・フレームワークを含むＸ線撮影モダリティのためのである。ホストシステム２０４は、ＣＴクライアントソフトウェアとクライアントサービス・フレームワークを含むＣＴ撮影モダリティのためのものである。デプロイされた計算処理サービス２０７は、追加されたコンピューティング資源（２０３，２０５）と共に含まれる。計算処理サービス２０７は、図１３の複数ホストシナリオと同じ方法で、利用可能なコンピューティング資源を発見するように構成される。クライアントサービス・フレームワークは、図１３の複数ホストシナリオと同じ方法で、計算処理サービスを発見する。クライアントサービス・フレームワークは、事前に設定されたシステム固有のＫＶＳにのみ接続する。本例では、Ｘ線撮影モダリティ用のホストシステム２０２は、Ｘ線用ＫＶＳと通信２０８する。ＣＴ撮影モダリティ用のホストシステム２０４は、ＣＴ用ＫＶＳと通信２０６する。計算処理サービス２０７は、どのデータフロー頂点がそのコンピューティング資源にディスパッチされたに依存して、複数のＫＶＳを使用してよい。本例では、追加されたコンピューティング資源２０３に関連する計算処理サービス２０７は、ＣＴ用ＫＶＳとの通信２１６と同様に、Ｘ線用ＫＶＳと通信２１４してよい。同様に、追加されたコンピューティング資源２０５は、２つの異なるＫＶＳ（Ｘ線用ＫＶＳとＣＴ用ＫＶＳ）と通信する計算処理サービス２０７を含む。

ここで、複数ホストシナリオと同様にクライアントサービス・フレームワークによりいずれかの計算処理サービス２０７に割り当てられるデータフロー（２２０，２２２）を、ホストシステム（２０２，２０４）が作成する図１４を参照する。各計算処理サービスは、頂点（２２５，２２７）を全ての計算資源にディスパッチする。所与の頂点は、所属するデータフローにより、そのオペランドと結果のために単一のＫＶＳのみを使用する。ＣＴデータフローからの頂点２２５はディスパッチされるとＣＴ用ＫＶＳを使用し、Ｘ線データフローからの頂点２２７はディスパッチされるとＸ線用ＫＶＳを使用する。

計算処理サービスはまた、放射線医学情報システム（Ｒａｄｉｏｌｏｇｙ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ：ＲＩＳ）または病院情報システム（Ｈｏｓｐｉｔａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ：ＨＩＳ）から得る予約情報に基づいて、タスク割当を行うように構成される。上述した例では、データフローグラフは、計算処理サービスにより、撮影モダリティから得られるイメージング情報を用いてコンパイルされる。しかし、イメージング情報を、ＲＩＳまたはＨＩＳにより得てもよい。追加的に、計算処理サービスは、予約情報に基づいて各計算に優先順位を設定してよい。例えば、緊急検査のための計算は、通常検査に関する計算より優先されるだろう。通常検査のための計算が緊急検査のための計算の前に始まるシナリオであっても、計算処理サービスは、緊急検査のための計算を完了するために、通常検査のための計算を休止するように構成される。

計算処理サービスはまた、撮影モダリティからのプロトコル情報に基づいてタスク割当を行うように構成される。例えば、計算処理サービスは、（ｉ）撮影モダリティの種類（ＣＴ、ＭＲＩ、Ｘ線、超音波等）の仕様、（ｉｉ）実行されるイメージング再構成処理の種類、または（ｉｉｉ）実行されるフィルタ処理の種類の観点から、各計算を行うデータプロセッサを決定できる。計算処理サービスが様々な優先順位のデータフローグラフを区別するある方法では、データフローグラフがネーミングされるやり方による。ドメイン固有言語（ＤＳＬ）をデータフローグラフのネーミングに用いてよい。この方法では、計算処理サービスが撮影モダリティまたはハードウェアの種類に基づいて計算を優先順位づけるだけではなく、優先順位が時間ドリブンまたは資源ドリブンであってよい。利用可能または必要な資源に基づいて、データフローを中断および再開してよい。このように、データフローグラフ名に関連する特定のＤＳＬにより、計算処理サービスは、各種データフローグラフに関連する計算を行う順序を決定できる。

優先順位付けの一例では、超音波診断装置などの撮影モダリティを決定する計算処理サービスが、少なくとも１つの他の撮影モダリティに対して優先することを含んでよい。計算処理サービスは、データフローグラフ名に基づいて、計算が超音波診断装置のためであること、及び、計算がＣＴイメージング装置に関連する計算に優先すること、を決定してよい。計算処理サービスのユーザまたはオペレータは、計算処理サービスがユーザ指定の優先順位の観点で資源を割り当てるように、優先される撮影モダリティを指定してよい。例えば、指定されたモダリティに関連する計算は、別の撮影モダリティに関連する計算より前に終わるだろう。

図１５は、データフロー計算の休止またはストップを示し、データフローが休止またはストップした同一ポイントで再開することができる概略図である。非常に長いまたはプロセッサ集約型の計算で最初から再スタートする必要がないため、これは利点である。任意のポイントで、アクティブなデータフロー２３９は実行中の作業２４０とキューに入った作業２５０の組み合わせをもつ。計算処理サービスに加えてホスト２３０（計算資源）は、実行中の頂点とともに、最低小および最高の優先キューをもつ２つのアクティブなデータフローを備える。クライアントは、データフロー優先順位を変更できる、または、外部イベントに応じてデータフローをストップできる。これを達成するため、計算処理サービスは、作業キューから頂点を取り除く、または、低い優先順位の作業キューに置く。計算処理サービスをもつホスト（計算資源）２３２は、作業キュー２６０から頂点を取り除くことができる。計算処理サービスは、常に、実行中の頂点計算を完了させることができる。同様に且つ同時に、異なるデータフローがその優先順位を上昇させた可能性がある。その頂点は、新しい高い優先順位でディスパッチを始める。ホスト２３４は、作業キュー２７０において低い優先順位の頂点が、最高の優先順位に上昇する例である。ストップしたデータフローの最後の頂点が実行を完了すると、ＫＶＳはホスト２３６の計算２８０の更新された状態を含む。ＫＶＳは、非アクティブなデータフローであっても状態を保持する。その後、どの頂点が実行可能であるかを決定し、実行可能な頂点を再スケジュールするために、ＫＶＳの現在の内容を用いて計算を開スタートできる。これにより、ホスト２３８で休止またはストップしたポイントから計算を効果的に再開２９０する。

上述した本開示の利点は、同一ソフトウェアが改変なしに低価格から高価格のシステムをサポートできることによる広い市場応用力と、アプリケーションソフトウェアを変更せずにインフラストラクチャを用いてコンピューティング資源を追加することによる取扱件数の増加の提供と、ハードウェアおよびソフトウェアのコンピューティング資源を共有するように構成される異なるシステムによるシステムコストの制御と、を含む。本開示は、低い待ち時間設計および実装、優先順位プリエンプティブな作業のスケジューリングのリアルタイム対応であり、進行においてプリエンプションされた作業はプリエンプションのポイントから再開できる。他の利点としては、共有される計算サービスに対する最小限の管理を含む。ソフトウェアデプロイメント、ハードウェアアップグレード、またはその他のサービス変更の必要がない。ソフトウェアアップグレードは遠隔で行ってよい。共有される計算処理サービスにより、継続かつ無人オペレーションができる。

図１６は、ホスト装置３００のハードウェア構成を示す。代わりに、図１６のハードウェア構成を、本開示に従って、イメージングシステム、計算処理サービス、またはサードパーティのサービスに使用してもよい。ハードウェア構成は制御部３１０を備え、制御部３１０はＣＰＵ３１１と、ＲＯＭ３１２と、ＲＡＭ３１３と、ＨＤＤ３１４と、ネットワークＩ／Ｆ３１５と、を備える。ＣＰＵ３１１は、各種処理の実行とＲＯＭ３１２に記憶される制御プログラムの読み出しを行って、装置全体のオペレーションを制御する。ＲＡＭ３１３は、ＣＰＵ３１１の主メモリや作業領域などの一時記憶領域として使用される。ＨＤＤ３１４は、画像データと各種プログラムを記憶する大容量記憶部である。ネットワークＩ／Ｆ３１５は、ホスト装置をネットワーク３２０に接続するインターフェイスである。ホストは別の装置からネットワークＩ／Ｆ３１５を介して処理要求を受信し、各種情報を送信／受信する。

また本開示の実施形態は、上述した実施形態のうちの１つまたは複数の実施形態の機能を実行するために、記憶媒体（詳細には「非一時的なコンピュータ読み取り可能な記憶媒体」とも称されることがある）に記録されたコンピュータで実行可能な命令（例えば、１つまたは複数のプログラム）を読み出し実行するシステムのコンピュータまたは装置、および／または、上述した実施形態のうちの１つまたは複数の実施形態の機能を実行する１つまたは複数の回路（例えば、特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：ＡＳＩＣ））を備えるシステムのコンピュータまたは装置により、及び、上述した実施形態のうちの１つまたは複数の実施形態の機能を実行するために当該システムのコンピュータまたは装置により、例えば、当該コンピュータで実行可能な命令を当該記憶媒体から読み出し実行する方法により、および／または、上述した実施形態のうちの１つまたは複数の実施形態の機能を実行するように当該１つまたは複数の回路を制御することにより実現できる。当該コンピュータは、１つまたは複数のプロセッサ（例えば、中央演算処理装置（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：ＣＰＵ）、超小型演算処理装置（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：ＭＰＵ））を備えてよい、また、当該コンピュータで実行可能な命令を読み出し実行するために、別のコンピュータまたは別のプロセッサのネットワークを備えてよい。当該コンピュータで実行可能な命令は、例えば、ネットワークまたは当該記憶媒体から、当該コンピュータに与えられてよい。当該記憶媒体は、例えば、ハードディスク、ランダム・アクセス・メモリ（Ｒａｎｄｏｍ－Ａｃｃｅｓｓ Ｍｅｍｏｒｙ：ＲＡＭ）、リード・オンリ・メモリ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ：ＲＯＭ）、分散コンピューティングシステムのストレージ、光学ディスク（コンパクトディスク（Ｃｏｍｐａｃｔ Ｄｉｓｃ：ＣＤ）、デジタル多用途ディスク（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ：ＤＶＤ）、ブルーレイディスク（Ｂｌｕ－ｒａｙ（登録商標） Ｄｉｓｃ（ＢＤ））など）、フラッシュメモリ装置、メモリカード等のうちの１つまたは複数を備えてよい。

以上説明した少なくとも１つの実施形態によれば、医用撮影モダリティから取得されるデータについての複数の処理ユニットによる処理を適切に制御することができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

以上の実施形態に関し、発明の一側面および選択的な特徴として以下の付記を開示する。

（付記１）
複数の医用撮影モダリティにコンピュータネットワークを介して接続される複数のデータプロセッサを用いて、前記医用撮影モダリティから取得されるデータ処理を制御するための制御方法であって、
前記複数の医用撮影モダリティのうちの１つの医用撮影モダリティで行われるイメージングのためのイメージング情報を取得することと、
前記イメージングが完了する前に、前記複数のデータプロセッサの負荷情報を取得することと、
前記取得した負荷情報に基づいて、前記複数のデータプロセッサの少なくとも一部を、前記イメージング情報に基づくイメージングで取得されるデータの処理に割り当てることと、
前記取得されるデータの処理を、前記割り当てられたデータプロセッサで実行することと
を含む制御方法。
（付記２）
前記複数のデータプロセッサの少なくとも一部は、グラフ情報に基づき、イメージングで取得されるデータの処理に割り当てられてもよい。
前記グラフ情報は、前記取得した負荷情報に基づいて生成されてもよい。
前記イメージングは、前記イメージング情報に基づくイメージングであってもよい。
（付記３）
前記グラフ情報は、データフローグラフであってもよい。
前記データフローグラフの各ノードは、処理ステップを指定してもよい。
前記データフローグラフの各エッジは、２つのノードをつなげて経路を指定してもよい。
処理結果は、１つの処理ステップから次の処理ステップをたどってもよい。
（付記４）
実行を完了する前のノードから利用可能なデータを有するエッジをもつ前記データフローグラフの全てのノードは、並列に実行されてもよい。
（付記５）
前記データフローグラフからの各ノードは、前記イメージング情報に基づくイメージングで取得される前記データの処理を表してもよい。
（付記６）
前記イメージング情報に基づくイメージングで取得される前記データの処理の状態は、メモリに記憶されてもよい。
（付記７）
前記データフローグラフ内の全てのノードオペランドのセットは、前記メモリに記憶されてもよい。
（付記８）
前記複数の医用撮影モダリティからの各医用撮影モダリティは、１つのキー値ストアに対応してもよい。
（付記９）
前記イメージング情報に基づくイメージングで取得される前記データの処理は、特定の医用撮影モダリティに対応してもよい。
前記特定の医用撮影モダリティは、関連するキー値ストアにのみアクセスできてもよい。
（付記１０）
前記イメージング情報は、前記データフローグラフ内で表現されてもよい。
（付記１１）
前記制御方法は、クライアントアプリケーションにより、前記イメージング情報に基づくイメージングで取得される前記データの処理に、優先順位をつけることをさらに含んでもよい。
前記制御方法は、利用可能なコンピューティング資源に応じて、前記データの処理を実行することをさらに含んでもよい。
（付記１２）
前記負荷情報は、前記複数のデータプロセッサのうちのいずれのデータプロセッサが最小の計算コストを有するか決定し、前記最小の計算コストをもつ前記データプロセッサを用いてデータを処理するために用いられてもよい。
（付記１３）
前記複数の医用撮影モダリティは、Ｘ線撮影モダリティ、コンピュータ断層撮影（ＣＴ）スキャン撮影モダリティ、磁気共鳴映像法（ＭＲＩ）モダリティ、超音波撮影モダリティ及びＰＥＴスキャン撮影モダリティのうちの少なくとも２つを含んでもよい。
（付記１４）
前記複数のデータプロセッサは、ＣＰＵ、ＧＰＵ、ハードウェア計算アクセラレータ、ＦＰＧＡ、ＡＩアクセラレータのうちの少なくとも２つを含んでもよい。
（付記１５）
前記イメージング情報は、放射線医学情報システム（Ｒａｄｉｏｌｏｇｙ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ：ＲＩＳ）又は病院情報システム（Ｈｏｓｐｉｔａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ：ＨＩＳ）から得られる情報であってもよい。
（付記１６）
前記データフローグラフの各処理ステップは、イメージングに用いられる医用撮影モダリティの仕様、実行される画像再構成処理の種類又は実行される画像フィルタリング処理の種類に依存する順番で実行されてもよい。
（付記１７）
前記イメージングに用いられる医用撮影モダリティ、実行される前記画像再構成処理の種類又は実行される前記画像フィルタリング処理の種類は、前記データフローグラフのデータフロー名により決定されてもよい。
（付記１８）
医用撮影モダリティが優先撮影モダリティとして指定され、指定された前記医用撮影モダリティに関連するデータの処理が指定されなかった医用撮影モダリティに関連するデータの処理より先に実行されてもよい。
（付記１９）
前記制御方法は、前記医用撮影モダリティから受け取った情報に基づいて、複数の計算のユニットを含む、前記データ処理のためのデータフローグラフを生成することさらに含んでもよい。
前記制御方法は、前記取得した負荷情報に基づいて、前記複数のデータプロセッサの少なくとも一部を、前記複数の計算のユニットに割り当てることさらに含んでもよい。
前記制御方法は、前記複数の計算のユニットについての前記データ処理を、前記割り当てられたデータプロセッサで実行することさらに含んでもよい。
（付記２０）
複数の医用撮影モダリティにコンピュータネットワークを介して接続される複数のデータプロセッサを用いて、前記医用撮影モダリティから取得されるデータ処理を制御するための制御方法であって、
前記複数の医用撮影モダリティのうちの１つの医用撮影モダリティで行われるイメージングが完了する前に、前記複数のデータプロセッサの負荷情報を取得することと、
前記医用撮影モダリティから受け取った情報に基づいて、複数の計算のユニットを含む、前記データ処理のためのデータフローグラフを生成することと、
前記取得した負荷情報に基づいて、前記複数のデータプロセッサの少なくとも一部を、前記複数の計算のユニットに割り当てることと、
前記複数の計算のユニットについての前記データ処理を、前記割り当てられたデータプロセッサで実行することと
を含む制御方法。
（付記２１）
医用撮影モダリティから取得されるデータ処理を制御するための処理サーバであって、
命令を記憶する１つまたは複数のメモリと、
前記命令を実行して、
複数の医用撮影モダリティのうちの１つの撮影モダリティで行われるイメージングのためのイメージング情報を取得し、
前記イメージングが完了する前に、前記複数の医用撮影モダリティに接続する複数のデータプロセッサの負荷情報を取得し、
前記取得した負荷情報に基づいて、前記複数のデータプロセッサの少なくとも一部を、前記イメージング情報に基づくイメージングで取得されるデータの処理に割り当て、
前記取得されるデータの処理を、前記割り当てられたデータプロセッサで実行する、
１つまたは複数のプロセッサと
を備える処理サーバ。
（付記２２）
複数の医用撮影モダリティにコンピュータネットワークを介して接続される複数のデータプロセッサを用いて、前記医用撮影モダリティから取得されるデータ処理を制御するための制御方法を実行するように１つまたは複数のプロセッサを動作させるプログラムであって、
前記複数の医用撮影モダリティのうちの１つの撮影モダリティで行われるイメージングのためのイメージング情報を取得すること、
前記イメージングが完了する前に、前記複数のデータプロセッサの負荷情報を取得すること、
前記取得した負荷情報に基づいて、前記複数のデータプロセッサの少なくとも一部を、前記イメージング情報に基づくイメージングで取得されるデータの処理に割り当てること、
前記取得されるデータの処理を、前記割り当てられたデータプロセッサで実行すること
を含むプログラム。
（付記２３）
複数の医用撮影モダリティにネットワークを介して接続される複数のデータプロセッサを用いて、前記医用撮影モダリティから取得されるデータ処理を制御するための制御方法であって、
前記医用撮影モダリティにより生成されるイメージング情報を受け取ることと、
受け取った前記イメージング情報に基づいて、各ノードがイメージング計算を表す複数のノードを含むデータフローグラフをコンパイルすることと、
前記データフローグラフの各ノードの前記イメージング計算を実行することと
を含み、
前記各ノードの実行は、前記複数の医用撮影モダリティから受け取ったイメージング情報に基づいて画像を生成するために、前記複数のデータプロセッサに割り当てられる、
制御方法。

１０ 放射線室
１２ Ｘ線システム
１４ Ｘ線ホストシステム
１６，２５，３２，４０ ネットワークインターフェイスカード（ＮＩＣ）
１８ ネットワーク
２０，２６ クライアントアプリケーション
２２，２８，１５０，１９８ クライアントサービス・フレームワーク
２３，１６０ ＣＴシステム
２４ ＣＴホストシステム
３０，３８，２３０，２３２，２３４，２３６，２３８ ホスト
３４，１５２，１９２，２０７ 計算処理サービス
３６，４２，１２０，１４４，１５６，１７０ キー値ストア（ＫＶＳ）
４８ データフローグラフ
１５４ ストリーミングデータソース
１９０ ソフトウェアコンポーネント
１９４，１９６，２０２，２０４ ホストシステム
１９７ 撮影モダリティ
２０３，２０５ コンピューティング資源
３００ ホスト装置
３１０ 制御部
３１１ ＣＰＵ
３１２ ＲＯＭ
３１３ ＲＡＭ
３１４ ＨＤＤ
３１５ ネットワークＩ／Ｆ
３２０ ネットワーク

Claims (23)

1. 複数の医用撮影モダリティにコンピュータネットワークを介して接続される複数のデータプロセッサを用いて、前記医用撮影モダリティから取得されるデータ処理を制御するための制御方法であって、
   前記複数の医用撮影モダリティのうちの１つの医用撮影モダリティで行われるイメージングのためのイメージング情報を取得することと、
   前記イメージングが完了する前に、前記複数のデータプロセッサの負荷情報を取得することと、
   前記取得した負荷情報に基づいて、前記複数のデータプロセッサの少なくとも一部を、前記イメージング情報に基づくイメージングで取得されるデータの処理に割り当てることと、
   前記取得されるデータの処理を、前記割り当てられたデータプロセッサで実行することと
   を含む制御方法。
2. 前記複数のデータプロセッサの少なくとも一部は、前記取得した負荷情報に基づいて生成されるグラフ情報に基づき、前記イメージング情報に基づくイメージングで取得されるデータの処理に割り当てられる、請求項１に記載の制御方法。
3. 前記グラフ情報は、データフローグラフであり、
   前記データフローグラフの各ノードは、処理ステップを指定し、
   前記データフローグラフの各エッジは、２つのノードをつなげて経路を指定し、
   処理結果は、１つの処理ステップから次の処理ステップをたどる、
   請求項２に記載の制御方法。
4. 実行を完了する前のノードから利用可能なデータを有するエッジをもつ前記データフローグラフの全てのノードは、並列に実行される、請求項３に記載の制御方法。
5. 前記データフローグラフからの各ノードは、前記イメージング情報に基づくイメージングで取得される前記データの処理を表す、請求項３に記載の制御方法。
6. 前記イメージング情報に基づくイメージングで取得される前記データの処理の状態は、メモリに記憶される、請求項５に記載の制御方法。
7. 前記データフローグラフ内の全てのノードオペランドのセットは、前記メモリに記憶される、請求項６に記載の制御方法。
8. 前記複数の医用撮影モダリティからの各医用撮影モダリティは、１つのキー値ストアに対応する、請求項７に記載の制御方法。
9. 前記イメージング情報に基づくイメージングで取得される前記データの処理は、特定の医用撮影モダリティに対応し、
   前記特定の医用撮影モダリティは、関連するキー値ストアにのみアクセスできる、
   請求項１に記載の制御方法。
10. 前記イメージング情報は、前記データフローグラフ内で表現される、請求項３に記載の制御方法。
11. クライアントアプリケーションにより、前記イメージング情報に基づくイメージングで取得される前記データの処理に、優先順位をつけることと、
    利用可能なコンピューティング資源に応じて、前記データの処理を実行することと
    をさらに含む請求項１に記載の制御方法。
12. 前記負荷情報は、前記複数のデータプロセッサのうちのいずれのデータプロセッサが最小の計算コストを有するか決定し、前記最小の計算コストをもつ前記データプロセッサを用いてデータを処理するために用いられる、請求項１に記載の制御方法。
13. 前記複数の医用撮影モダリティは、Ｘ線撮影モダリティ、コンピュータ断層撮影（ＣＴ）スキャン撮影モダリティ、磁気共鳴映像法（ＭＲＩ）モダリティ、超音波撮影モダリティ及びＰＥＴスキャン撮影モダリティのうちの少なくとも２つを含む、請求項１に記載の制御方法。
14. 前記複数のデータプロセッサは、ＣＰＵ、ＧＰＵ、ハードウェア計算アクセラレータ、ＦＰＧＡ、ＡＩアクセラレータのうちの少なくとも２つを含む、請求項１に記載の制御方法。
15. 前記イメージング情報は、放射線医学情報システム（Ｒａｄｉｏｌｏｇｙ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ：ＲＩＳ）又は病院情報システム（Ｈｏｓｐｉｔａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ：ＨＩＳ）から得られる情報である、請求項１に記載の制御方法。
16. 前記データフローグラフの各処理ステップは、イメージングに用いられる医用撮影モダリティの仕様、実行される画像再構成処理の種類又は実行される画像フィルタリング処理の種類に依存する順番で実行される、請求項３に記載の制御方法。
17. 前記イメージングに用いられる医用撮影モダリティ、実行される前記画像再構成処理の種類又は実行される前記画像フィルタリング処理の種類は、前記データフローグラフのデータフロー名により決定される、請求項１６に記載の制御方法。
18. 医用撮影モダリティが優先撮影モダリティとして指定され、指定された前記医用撮影モダリティに関連するデータの処理が指定されなかった医用撮影モダリティに関連するデータの処理より先に実行される、請求項１に記載の制御方法。
19. 前記医用撮影モダリティから受け取った情報に基づいて、複数の計算のユニットを含む、前記データ処理のためのデータフローグラフを生成することと、
    前記取得した負荷情報に基づいて、前記複数のデータプロセッサの少なくとも一部を、前記複数の計算のユニットに割り当てることと、
    前記複数の計算のユニットについての前記データ処理を、前記割り当てられたデータプロセッサで実行することと
    をさらに含む、請求項１に記載の制御方法。
20. 複数の医用撮影モダリティにコンピュータネットワークを介して接続される複数のデータプロセッサを用いて、前記医用撮影モダリティから取得されるデータ処理を制御するための制御方法であって、
    前記複数の医用撮影モダリティのうちの１つの医用撮影モダリティで行われるイメージングが完了する前に、前記複数のデータプロセッサの負荷情報を取得することと、
    前記医用撮影モダリティから受け取った情報に基づいて、複数の計算のユニットを含む、前記データ処理のためのデータフローグラフを生成することと、
    前記取得した負荷情報に基づいて、前記複数のデータプロセッサの少なくとも一部を、前記複数の計算のユニットに割り当てることと、
    前記複数の計算のユニットについての前記データ処理を、前記割り当てられたデータプロセッサで実行することと
    を含む制御方法。
21. 医用撮影モダリティから取得されるデータ処理を制御するための処理サーバであって、
    命令を記憶する１つまたは複数のメモリと、
    前記命令を実行して、
    複数の医用撮影モダリティのうちの１つの撮影モダリティで行われるイメージングのためのイメージング情報を取得し、
    前記イメージングが完了する前に、前記複数の医用撮影モダリティに接続する複数のデータプロセッサの負荷情報を取得し、
    前記取得した負荷情報に基づいて、前記複数のデータプロセッサの少なくとも一部を、前記イメージング情報に基づくイメージングで取得されるデータの処理に割り当て、
    前記取得されるデータの処理を、前記割り当てられたデータプロセッサで実行する、
    １つまたは複数のプロセッサと
    を備える処理サーバ。
22. 複数の医用撮影モダリティにコンピュータネットワークを介して接続される複数のデータプロセッサを用いて、前記医用撮影モダリティから取得されるデータ処理を制御するための制御方法を実行するように１つまたは複数のプロセッサを動作させるプログラムであって、
    前記複数の医用撮影モダリティのうちの１つの撮影モダリティで行われるイメージングのためのイメージング情報を取得すること、
    前記イメージングが完了する前に、前記複数のデータプロセッサの負荷情報を取得すること、
    前記取得した負荷情報に基づいて、前記複数のデータプロセッサの少なくとも一部を、前記イメージング情報に基づくイメージングで取得されるデータの処理に割り当てること、
    前記取得されるデータの処理を、前記割り当てられたデータプロセッサで実行すること
    を含むプログラム。
23. 複数の医用撮影モダリティにネットワークを介して接続される複数のデータプロセッサを用いて、前記医用撮影モダリティから取得されるデータ処理を制御するための制御方法であって、
    前記医用撮影モダリティにより生成されるイメージング情報を受け取ることと、
    受け取った前記イメージング情報に基づいて、各ノードがイメージング計算を表す複数のノードを含むデータフローグラフをコンパイルすることと、
    前記データフローグラフの各ノードの前記イメージング計算を実行することと
    を含み、
    前記各ノードの実行は、前記複数の医用撮影モダリティから受け取ったイメージング情報に基づいて画像を生成するために、前記複数のデータプロセッサに割り当てられる、
    制御方法。

Images