JP2022042011A - 医療情報制御システム、信号処理装置、及び医療情報制御方法 - Google Patents

Abstract

【課題】さらに、医療イメージング装置をサーバに接続し、サーバで信号処理を行うことで、より高度な手技のサポートを行うことが考えられる。
【解決手段】本開示によれば、手術サーバは、第１のコンテナ仮想領域にインストールされた、第１の医療アプリケーションと、第２のコンテナ仮想領域にインストールされた、第２の医療アプリケーションと、がアクセス可能な複数の仮想共有バッファと、制御アプリケーションと、を有し、制御アプリケーションは、第１の医療アプリケーションの書き込みと第２の医療アプリケーションの読み込みとを第１仮想メモリ領域と、第２仮想メモリ領域と、第３仮想メモリ領域と、を交互に用いるように第１の医療アプリケーションまたは第２の医療アプリケーションを制御する、医療情報制御システムが提供される。
【選択図】図２

Description

本開示は、医療情報制御システム、信号処理装置、及び医療情報制御方法に関する。

内視鏡やビデオ顕微鏡といった医療イメージング装置を用いた手術は、より精細な手技が可能となるとともに、画像処理技術による手技のサポートを行うことが期待されている。このとき、医療イメージング装置により生成された医療用画像に対して行われる画像処理は、手技の妨げとなることを抑制することが望まれる。そのため、画像処理では、例えば、一定時間以内に１フレーム分の画像処理が完了することといったリアルタイム性や、画像処理にかかる処理時間、すなわち遅延が小さいことといった低レイテンシが求められる。また、同時に複雑な画像処理によって手技の効率化に役立つ情報を表示することが求められる。

そこで、医療用画像に対して回転補正等の画像処理を行う外部装置（ＩＰコンバータ）が提案されている（例えば、特許文献１）。

特開２０１９－１６２２３１号公報

さらに、医療イメージング装置をサーバに接続し、サーバで信号処理を行うことで、より高度な手技のサポートを行うことが考えられる。

上記の課題を解決するために、本開示によれば、手術室に設置された医療機器とネットワークを介して接続された手術サーバと、を備え、前記手術サーバは、医療機器で生成された医療画像を取得し、コンテナ仮想領域にインストールされユーザが選択可能なリアルタイム型信号処理アプリケーションおよびベストエフォート型信号処理アプリケーションを実行し、前記リアルタイム型信号処理アプリケーションによって処理された医療画像に前記ベストエフォート型信号処理アプリケーションの処理結果を重ね合わせる、
医療情報制御システムが提供される。

本開示によれば、手術室に設置された医療機器とネットワークを介して接続された手術サーバを用いて、医療機器で生成された医療画像を取得し、コンテナ仮想領域にインストールされユーザが選択可能なリアルタイム型信号処理アプリケーションおよびベストエフォート型信号処理アプリケーションを実行し、前記リアルタイム型信号処理アプリケーションによって処理された医療画像に前記ベストエフォート型信号処理アプリケーションの処理結果を重ね合わせる、
医療情報制御方法が提供される。

本開示の実施形態に係る医療情報制御システムの構成の一例を示す図。 信号処理サーバの構成例を示すブロック図。 仮想共有バッファの構成及び処理例を示す図。 ダブルバッファリングを用いた構成及び処理例を説明する図。 図２に示す重畳処理の例を示す図。 図２に示す重畳処理の別の例を示す図。 本実施形態の処理シーケンス例を示す図。 鉗子認識及び出血箇所の認識の例を示す図。 比較例２に係る医療情報制御システムの構成例を示す図。 比較例３に係る医療情報制御システムの構成例を示す図。 第１実施形態の変形例に係る信号処理サーバの構成例を示すブロック図。 第２実施形態に係る信号処理サーバの構成例を示すブロック図。 第３実施形態に係る信号処理サーバの構成例を示すブロック図。 第４実施形態に係る信号処理サーバの構成例を示すブロック図。 第４実施形態に係るＧＰＵの構成例を示すブロック図。 第４実施形態に係る仮想共有バッファの構成及び処理例を示すブロック図。

以下、図面を参照して、医療情報制御システム、信号処理装置、及び医療情報制御方法の実施形態について説明する。以下では、医療情報制御システムの主要な構成部分を中心に説明するが、医療情報制御システムには、図示又は説明されていない構成部分や機能が存在しうる。以下の説明は、図示又は説明されていない構成部分や機能を除外するものではない。

手術では、手術用内視鏡から取得した医療画像に輝度補正を行うようなレイテンシが重視されるリアルタイム型信号処理と、画像認識による腫瘍判別のように計算量を多大にかけても結果を重視するベストエフォート型信号処理と、の両方が同時に求められる場合がある。

このとき、リアルタイム型信号処理と、ベストエフォート型信号処理とで同時並列的に処理することが求められる。そこで、医療イメージング装置を信号処理サーバに接続し、信号処理サーバで低レイテンシ処理が求められるリアルタイム型のアプリケーションと、低レイテンシは強く要求されないが複雑な計算処理が求められるベストエフォート型のアプリケーションとを並行して動作し、リアルタイム性を維持しつつ手技の効率化に役立つ情報を表示することが求められている。

しかしながら、信号処理サーバ内にリアルタイム型のアプリケーションの処理結果とベストエフォート型のアプリケーションの処理結果を１枚の表示画像に反映させるとき、リアルタイム型のアプリケーションの処理速度と、ベストエフォート型のアプリケーションの処理速度が異なっているため、バッファ処理が必要となる。

（第１実施形態）
図１は、本開示の実施形態に係る医療情報制御システム１の構成の一例を示す図である。図１に示すように、本実施形態に係る医療情報制御システム１は、複数の画像イメージング装置１０と、信号処理サーバ２０と、複数の入力側のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）コンバータ３０と、ＩＰスイッチ４０と、複数の出力側のＩＰコンバータ５０と、複数の画像受信装置６０と、操作端末７０と、制御サーバ８０とを備える。また、複数の入力側のＩＰコンバータ３０と、ＩＰスイッチ４０と、複数の出力側のＩＰコンバータ５０と、操作端末７０と、制御サーバ８０とは、例えば院内画像ネットワークシステムとして映像ネットワーク２０００を構成する。

画像イメージング装置１０は、画像送出装置として機能する。例えば、画像イメージング装置１０は、モダリティとも称され、医療用画像の撮像に用いられる装置である。例えば、画像イメージング装置１０が内視鏡の場合、内視鏡カメラヘッドとＣＣＵ（Ｃａｍｅｒａ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）を有する。画像イメージング装置１０は、内視鏡に限らず、術野カメラや顕微鏡等の種々の医療機器であってもよい。すなわち、画像イメージング装置１０は、内視鏡に限らず、医療用画像を撮像する機能を有する装置であればよく、その構成は特に限定されない。

なお、本実施形態では、座標情報と関連づけられた信号値の集合を画像と称する。また、本実施形態では、画像を画像データ、又は画像信号と呼ぶ場合がある。特に、画像イメージング装置１０における撮像部、例えば二次元センサ、内の撮像素子の位置情報に対応する座標情報と関連づけられた信号値の集合を医療用画像と称する。すなわち、医療情報制御システム１においては、医療用画像は、医療用画像データ又は医療用画像信号として処理される。

信号処理サーバ２０は、信号処理装置である。信号処理サーバ２０は、画像処理などの信号処理を実行する信号処理装置（コンピュータ）である。信号処理サーバ２０は、例えば手術室外に配置されるサーバ装置であり、各々が異なる手術室内に配置される複数のＩＰコンバータ３０にＩＰスイッチ４０および映像ネットワーク２０００を介して接続される。信号処理サーバ２０は、例えば操作端末７０を介した操作指示に応じて制御サーバ８０から出力される制御コマンドに基づいて処理を実行する。なお、信号処理サーバ２０の詳細は後述する。また、本実施形態に係る信号処理サーバ２０が手術サーバに対応する。

医療情報制御システム１における信号処理サーバ２０の配置は、上記のような手術室外に配置される形態に限られない。例えば、信号処理サーバ２０の運用形態は、手術室内や手術室が設けられた施設内に配置されるようなオンプレミスの形態であってもよいし、或いは、手術室外や手術室が設けられた施設外に配置されるようなクラウドの形態であってもよい。すなわち、医療情報制御システム１における信号処理サーバ２０は、医療情報制御システム１の運用に関する条件等を満たせば、設置位置はいずれの位置であってもよい。ただし、信号処理サーバ２０が手術室外に設けられている場合は、手術室に設置できない大型の冷却設備などを使用できるため、画像処理サーバを高性能化できる。

ＩＰコンバータ３０は、画像イメージング装置１０から供給される画像信号をＩＰ伝送可能な信号、例えば、イーサネット（登録商標）信号に変換するコンバータである。画像イメージング装置１０、及び画像受信装置６０側の入出力はＳＤＩ、ＨＤＭ（登録商標）Ｉ、及びＤｉｓｐｌａｙ Ｐｏｒｔといったインターフェイスが一般的である。すなわち、ＩＰコンバータ３０は、ＳＤＩ、ＨＤＭＩ、及びＤｉｓｐｌａｙ Ｐｏｒｔといったインターフェイスから供給される画像信号をＩＰ伝送可能な信号に変換する。画像イメージング装置１０をどの画像受信装置６０につなげるかは、ユーザの操作端末７０を介した操作指示に応じて、制御サーバ８０が制御を行う。

ＩＰスイッチ４０（光スイッチャ等）は、例えば操作端末７０を介した操作指示に応じて制御サーバ８０から出力される制御コマンドに基づいて、受信した信号を所定の機器に送信する機能を備える。これにより、画像イメージング装置１０から供給される画像信号は、対応するＩＰコンバータ３０によって例えばイーサネット信号に変換され、ＩＰスイッチ４０よって、信号処理サーバ２０やＩＰコンバータ５０に出力される。例えば、ＩＰコンバータ３０、５０と、ＩＰスイッチ４０との間はイーサネット等により接続される。

ＩＰコンバータ５０は、ＩＰスイッチ４０から供給されるＩＰ伝送可能な信号を、画像受信装置６０側の入力インターフェイスであるＳＤＩ、ＨＤＭＩ（登録商標）、及びＤｉｓｐｌａｙ Ｐｏｒｔなどに対応する信号に変換し、対応する画像受信装置６０に供給する。より詳細には、ＩＰコンバータ５０は、供給されるＩＰ伝送可能な信号を表示画像信号に変換する。そして、ＩＰコンバータ５０は、生成した表示画像信号を、対応する画像受信装置６０に供給する。

画像受信装置６０は、例えばモニタである。画像受信装置６０は、ＩＰコンバータ５０から供給される表示画像信号に基づき、医療用画像を表示する。操作端末７０は、例えばマウスやキーボードで構成される。操作端末７０は、ユーザの操作に応じて、操作信号を制御サーバ８０に入力する。制御サーバ８０は、制御装置（コンピュータ）である。制御サーバ８０は、操作端末７０からの操作信号に従い、医療情報制御システム１全体を制御する。

このように映像ネットワーク２０００は、イーサネットを基盤とした映像ネットワークとして構築される。イーサネットを基盤とした映像ネットワークは、物理的なスペースを抑制することが可能となる。この際に画像イメージング装置１０と画像受信装置６０とを直接接続するのではなく、手術室内もしくは病院内の映像ネットワーク２０００を経由して接続することが可能である。これにより、内視鏡をはじめ超音波診断装置や生体情報モニタなど手術で利用される様々な映像を任意のモニタで表示したり切り替えたりできる。

ところで、手術室においては様々な画像イメージング装置１０が用いられており、所望の画像処理機能を医療イメージング装置が備えていない場合がある。そこで、本実施形態では、信号処理サーバ２０が、画像イメージング装置１０から出力された医療用画像に対して画像処理を行うことにより、個別の機器やベンダーに依存しない機能を実現する。また、画像イメージング装置１０の画像処理に対する操作性も統一化が可能となる。

上述のように、医療情報制御システム１では、画像イメージング装置１０から供給される画像に対する画像処理を手技の妨げとならないように、より小さい遅延（レイテンシ）で実行することが求められる。例えば、医療用画像に行われる画像処理では、４Ｋ等の高解像度の画像に対して６０ｆｐｓ等のフレームレートで画像受信装置６０に表示することが求められる。このように、本実施形態では、観察に対する支障が発生しないように、一定時間以内に行われる１フレーム分の信号処理をリアルタイム信号処理と称する。また、これらの性能要件を包括してリアルタイム性と称する。

一方で、リアルタイム信号処理としての画像処理の他に、ＡＩによる画像認識等によって手技のサポートを行う医療アプリケーションの実用化も進められている。これらの処理は、その内容によって処理時間が変動することがある。また、一般的に処理負荷が高いことから、より低フレームレートでの動作となったり、フレームレートに変動が生じたりする場合がある。一方で、認識処理などの信号処理は、必ずしもリアルタイム性が求められない。本実施形態では、画像認識等により、手技に対する付加情報を提供する画像処理などをベストエフォート型信号処理と称する。

手術では、手術用内視鏡から取得した医療画像に輝度補正を行うようなレイテンシが重視されるリアルタイム型信号処理と、画像認識による腫瘍判別のように計算量を多大にかけても結果を重視するベストエフォート型信号処理と、の両方が同時に求められる場合がある。このとき、リアルタイム型信号処理と、ベストエフォート型信号処理とで同時並列的に処理することが求められる。

そこで、本実施形態では、画像イメージング装置１０を信号処理サーバ２０に接続する。信号処理サーバ２０では、低レイテンシ処理が求められるリアルタイム型のアプリケーションと、低レイテンシは強く要求されないが複雑な計算処理が求められるベストエフォート型のアプリケーションとを並行して動作し、リアルタイム性を維持しつつ手技の効率化に役立つ情報を表示する。

ここで、図２に基づき信号処理サーバ２０の詳細を説明する。図２は、信号処理サーバ２０の構成例を示すブロック図である。信号処理サーバ２０は、リアルタイム型信号処理アプリケーション１００とベストエフォート型信号処理アプリケーション３００とを並行して実行可能なサーバである。

図２に示すように、信号処理サーバ２０は、リアルタイム型信号処理アプリケーション１００と、仮想共有バッファ２００と、ベストエフォート型信号処理アプリケーション３００と、仮想共有バッファ４００と、制御アプリケーション５００とを有する。この、信号処理サーバ２０は、所謂仮想コンテナを作成可能なサーバであり、リアルタイム型信号処理アプリケーション１００と、ベストエフォート型信号処理アプリケーション３００と、制御アプリケーション５００とは、それぞれ独立したコンテナとして信号処理サーバ上に配置される。すなわち、これらのアプリケーションを個別のコンテナ上で実行する。このように、リアルタイム型信号処理アプリケーション１００と、ベストエフォート型信号処理アプリケーション３００と、制御アプリケーション５００とをコンテナ化することにより、論理的に両者の計算機リソースを切り離すことが可能となる。より具体的には、コンテナをサポートしている仮想環境の例としてＤｏｃｋｅｒ社が開発を行っている”Ｄｏｃｋｅｒ”が挙げられる。

また、一般にこのような仮想コンテナ環境ではアプリケーションが利用するＣＰＵのコア数やメモリの上限、利用できるＧＰＵの台数などを指定することが可能である。これを利用することでリアルタイム型信号処理アプリケーション１００に必要なリソースを優先的に割り当て、リアルタイム型信号処理アプリケーション１００とベストエフォート型信号処理アプリケーション３００の計算機リソースを物理的に切り離すことが可能である。

リアルタイム型信号処理アプリケーション１００は、一定時間以内に１フレーム分の信号処理が可能なアプリケーションであり、入力処理１００ａと、分配処理１００ｂと、複数の信号処理１００ｃ、１００ｄと、重畳処理１００ｅと、出力処理１００ｆとを、例えばパイプライン処理により行う。入力処理１００ａは、ＩＰコンバータ３０から供給される信号を入力する。分配処理１００ｂは、入力処理１００ａにより供給された入力信号を仮想共有バッファ２００と、信号処理１００ｃに分配する。複数の信号処理１００ｃ、１００ｄは、例えば、ノイズ除去、各種歪み補正、解像感の改善、階調感の改善、色再現や色強調、デジタルズームなどの画像処理を行う。なお、本実施形態では、信号処理として、ノイズ除去、各種歪み補正、解像感の改善、階調感の改善、色再現や色強調、デジタルズームなどの画像処理を行うが、これに限定されない。

重畳処理１００ｅは、複数の信号処理１００ｃ、１００ｄを行った画像に仮想共有バッファ４００から供給される画像を重畳する。例えば、重畳処理１００ｅは、係数αにより２つの画像を合成する所謂アルファブレンドにより画像を重畳する。出力処理１００ｆは、重畳後の画像をＩＰコンバータ５０に供給する。

仮想共有バッファ２００は、リアルタイム型信号処理アプリケーション１００とベストエフォート型信号処理アプリケーション３００とが共有するバッファであり、リアルタイム型信号処理アプリケーション１００が入力画像をバッファに書き込み、ベストエフォート型信号処理アプリケーション３００が書き込まれた画像を読み出す。

ベストエフォート型信号処理アプリケーション３００は、画像認識等により、手技に対する付加情報を提供する画像処理を行うアプリケーションであり、入力処理３００ａと、複数の信号処理３００ｂ、３００ｃと、出力処理３００ｄとを、例えばパイプライン処理により行う。入力処理３００ａは、仮想共有バッファ２００から画像を読み込み、複数の信号処理３００ｂ、３００ｃに供給する。

複数の信号処理３００ｂ、３００ｃは、例えばＳＬＡＭ（Ｓｉｍｕｌｔａｎｅｏｕｓ Ｌｏｃａｌｉｚａｔｉｏｎ ａｎｄ Ｍａｐｐｉｎｇ）または機械学習による物体認識処理である。例えば、複数の信号処理３００ｂ、３００ｃは、鉗子の認識処理、出血領域の認識処理などに対応する認識処理であり、鉗子の認識処理、出血領域の認識処理などを画像に施し、例えば領域情報を透明画像に重畳する。出力処理３００ｄは、複数の信号処理３００ｂ、３００ｃにより生成された画像を仮想共有バッファ４００に書き込む処理を行う。また、複数の信号処理３００ｂ、３００ｃで鉗子の認識処理、及び出血領域の認識処理を行っても良いし、或いは、複数の信号処理３００ｂ、３００ｃで鉗子の認識処理、及び出血領域の認識処理のうちのいずれかだけを行っても良い。なお、透明画像とは、少なくとも一部の領域が透過性を有する透過領域である画像である。

仮想共有バッファ４００は、リアルタイム型信号処理アプリケーション１００とベストエフォート型信号処理アプリケーション３００とが共有するバッファである。すなわち、ベストエフォート型信号処理アプリケーション３００が処理画像をバッファに書き込み、リアルタイム型信号処理アプリケーション１００が書き込まれた画像をバッファから読み出す。仮想共有バッファ２００及び仮想共有バッファ４００の詳細は、後述する。

制御アプリケーション５００は、リアルタイム型信号処理アプリケーション１００と、仮想共有バッファ２００と、ベストエフォート型信号処理アプリケーション３００と、仮想共有バッファ４００とを制御する。なお、制御アプリケーション５００の制御例は後述する。

ここで、図３に基づき、仮想共有バッファ２００、及び仮想共有バッファ４００の構成及び処理例を説明する。図３は、仮想共有バッファ２００の構成及び処理例を示す図である。なお、仮想共有バッファ４００も仮想共有バッファ２００と同等の構成であるので説明を省略する。

上述のように、リアルタイム型信号処理アプリケーション１００の処理速度と、ベストエフォート型のアプリケーション３００の処理速度が異なっているため、バッファ処理が必要となる。このため、本実施形態に係る仮想共有バッファ２００、及び仮想共有バッファ４００は、所謂トリプルバッファリングにより、バッファ処理を行う。図３に示すように、仮想共有バッファ２００は、３つの仮想メモリ領域２００ａ、２００ｂ、２００ｃを有する。ここでは、書き込み側の方が読み込み側より処理が速いものとする。

図３の左図に示すように、書き込み側が第１仮想メモリ領域２００ａに書き込みを行っており、読み出し側は第３仮想メモリ領域２００ｃから読み出しを行っている状態である。書き込み側は第１仮想メモリ領域２００ａへの書き込みが終了した際に、もし第３仮想メモリ領域２００ｃの読み出しが完了していなければ、それを待たずに第２仮想メモリ領域２００ｂへの書き込みを行う。以下同様に第３仮想メモリ領域２００ｃの読み出しが終わるまでは第１仮想メモリ領域２００ａと第２仮想メモリ領域２００ｂに交互に書き出しを行う。第３仮想メモリ領域２００ｃの読み出しが完了したら、読み出し側は第１仮想メモリ領域２００ａと第２仮想メモリ領域２００ｂのうち書き込み中でない側の仮想メモリ領域を読み出す。それが仮に第２仮想メモリ領域２００ｂであった場合を図６の右図に示す。読み出し側が第２仮想メモリ領域２００ｂにアクセスしている間、書き込み側は、今度は第１仮想メモリ領域２００ａと２００ｃとに交互に書き出しを行う。このように、仮想共有バッファ２００は、書き込み側と読み込み側が非同期に処理を実行することが可能である。

なお、図３において、仮に読み出し側の処理が書き込み側の処理より速いような状況では、図３左図の状態であり、読み出し側が第３仮想メモリ領域２００ｃへのアクセスを完了したタイミングで、第２仮想メモリ領域２００ｂに書き込まれた情報が第３仮想メモリ領域２００ｃより古いまま残っている可能性がある。このような場合は、読み出し側が第３仮想メモリ領域２００ｃからもう一度読み出しを行うことで時間的に正しい順序でデータを受け渡しすることができる。これらから分かるように、書き込み側は読み出し側の処理速度に影響を受けることなく非同期に処理を行うことができ、読み出し側は常に書き込みが完了した最新のデータを読み出すことができる。

このように、トリプルバッファリングである仮想共有バッファ２００、及び仮想共有バッファ４００を利用した非同期データの共有により、ベストエフォート型のアプリケーション３００の処理速度がリアルタイム型信号処理アプリケーション１００の処理速度に影響を及ぼさないようにすることができる。

図４は、比較例１として、仮想共有バッファ２００、及び仮想共有バッファ４００に、ダブルバッファリングを用いた構成及び処理例を説明する図である。図４に示すように、所謂ダブルバッファリングでは、２つの第１仮想メモリ領域２００ａ、２００ｂを用いて、書き込み側と読み込み側の間でデータを共有する。ダブルバッファリングでは、書き込み側と読み出し側は常に異なるバッファにアクセスする。例えば図４の左図では書き込み側は第１仮想メモリ領域２００ａにデータを書き込んでいる。その間、読み出し側は第２仮想メモリ領域２００ｂからデータを読み込む。書き込みと読み込みが終了したら、図４の右図のように同じタイミングで読み書きするバッファを相互に切り替える。仮に書き込み中のデータを読み込んだり、読み込み中のデータに書き込んだりすると正しい出力が得られないが、上記のようにダブルバッファリングを利用することでこれを防ぐことができる。ダブルバッファリングの課題として、同じタイミングでバッファの切り替えを行うので、書き込み側と読み出し側の処理速度に差がある場合、速い方は遅い方の処理が終わるまで次の処理を待つ必要があり、性能に影響することが挙げられる。

一方で、リアルタイム型信号処理アプリケーション１００は６０ｆｐｓといった高フレームレートを保って動作させ、ベストエフォート型信号処理アプリケーション３００はより遅いフレームレートで動作させることが想定される。すなわち両者が非同期に共有バッファに対して読み書きを行える必要がある。従って仮に共有バッファをダブルバッファリングとして実現した場合、図４の分配処理において、リアルタイム型信号処理アプリケーション１００が共有バッファに書き込みを行おうとしても、そのバッファに対してベストエフォート型信号処理アプリケーション３００の読み込みが終了しておらず、リアルタイム型信号処理アプリケーション１００の処理がブロックされる（待ち状態になる）ということが起こってしまう。これらから分かるように、仮想共有バッファ２００、及び仮想共有バッファ４００にダブルバッファリングを用いた構成よっては、リアルタイム性が保証できなくなってしまう。これに対して本実施形態に係る医療情報制御システム１では、上述のように、トリプルバッファリングを利用した非同期データの共有により、ベストエフォート型のアプリケーション３００の処理速度がリアルタイム型信号処理アプリケーション１００の処理速度に影響を及ぼさないようにすることができる。

ここで、図５に基づき、図２に示す重畳処理１００ｅの詳細を説明する。図５は、図２に示す重畳処理１００ｅの例を示す図である。ここでは、ベストエフォート型信号処理アプリケーション３００が、医療用画像に対して鉗子認識を施す例を説明する。

入力された入力画像６０２に対し、ベストエフォート型信号処理アプリケーション３００の信号処理３００ｂ、３００ｃなどは、例えばＤＬ等の機械学習を用いて鉗子を認識する。そして、信号処理３００ｂ、３００ｃは、そのバウンディングボックス（位置と大きさを示す矩形）６０４ａ、６０４ｂ、６０４ｃを透明度付き重畳画像６０４に描画する。

この際、ベストエフォート型信号処理アプリケーション３００側では認識のみ行い、その位置とサイズをリアルタイム型信号処理アプリケーション１００に渡して、リアルタイム型信号処理アプリケーション１００側でバウンディングボックスを描画する方法が考えられる。だがこの方法では、認識した鉗子の数だけ描画が必要であり、必要な処理負荷を見積れない。従って描画の対象が多い場合、リアルタイム性に影響が出る可能性がある。

これに対して、本実施形態では、図５に示すように、ベストエフォート型信号処理アプリケーション３００側で透明度付きの重畳画像６０４のバッファを用意して、そこに必要な描画を行う。そして、ベストエフォート型信号処理アプリケーション３００は、仮想共有バッファ４００を介して、透明度付きの重畳画像６０４をリアルタイム型信号処理アプリケーション１００に渡す。

リアルタイム型信号処理アプリケーション１００では、受け取った透明度付きの重畳画像６０４を、その透明度の情報をもとに、自らのパイプラインを流れてきた入力画像６０２の上にアルファブレンディングで重畳した重畳画像６０２ａを生成する。

このようにすることで、リアルタイム型信号処理アプリケーション１００はベストエフォート型信号処理アプリケーション３００で行っている処理の内容に依存せず、常に全画面についてアルファブレンディングを行えば良いことになる。従ってその処理負荷は一定でかつ容易に見積もることができる。これにより、リアルタイム性を保証することができる。このように、ベストエフォート型信号処理アプリケーション３００は、透明度付きの重畳画像６０４をリアルタイム型信号処理アプリケーション１００に渡し、リアルタイム型信号処理アプリケーション１００はその重畳処理のみを行うことで、リアルタイム型信号処理アプリケーションの処理負荷の上限を一定に保つことができる。

図６は、図２に示す重畳処理１００ｅの別の例を示す図である。ここでは、ベストエフォート型信号処理アプリケーション３００が、医療用画像に対して鉗子認識を施す例を説明する。この場合、全画面に対してアルファブレンディングを行うのではなく、図６に示すように、入力画像６０２の一部の領域６０４０に対してピクチャー、イン、ピクチャー（Ｐｉｃｔｕｒｅ ｉｎ Ｐｉｃｔｕｒｅ）でベストエフォート型信号処理アプリケーション３００の処理結果を重畳しても良い。ただし、全画面に対してアルファブレンディングを行う方法の方が表現力は高くなる場合がある。

なお、本実施形態では画像の重畳について述べたが、画像データと合わせてメタデータを受け渡しすることで、リアルタイム型信号処理アプリケーション１００の実行パラメータを制御するようなことも考えられる。例として、リアルタイム型信号処理アプリケーション１００で画像処理としてデジタルズームを行い、そのズーム倍率をベストエフォート型信号処理アプリケーション３００の処理結果で制御するというような連携が挙げられる。

ここで、図７及び図８に基づき、本実施形態の処理シーケンスについて述べる。図７は、本実施形態の処理シーケンス例を示す図である。図８は、鉗子認識及び出血箇所の認識の例を示す図である。ベストエフォート型信号処理アプリケーション３００の信号処理３００ｂ、３００ｃは、鉗子認識に加え、もう一つのベストエフォート型信号処理アプリケーション３００の例として、医療用画像に対する出血認識を行う。入力された入力画像６０２は、例えば医療画像であり、入力画像６０２に対し、ベストエフォート型信号処理アプリケーション３００においてＤＬ等の機械学習を用いて出血箇所を認識し、そのバウンディングボックス（位置と大きさを示す矩形）６１０ａ、６１０ｂを出力画像６０２ｃに描画する。なお、本実施形態では画像を画像データと呼ぶ場合もある。

図７に示すように、まずユーザが操作端末７０を介してリアルタイム型信号処理アプリケーションを起動する（ステップＳ１００）。この際、操作端末７０は、制御サーバ８０を介して信号処理サーバ２０の制御アプリケーション５００と通信しても良いが、ここでは直接的に信号処理サーバ２０と通信する。

続けて、制御アプリケーション５００は、リアルタイム型信号処理アプリケーション１００を起動する（ステップＳ１０２）。リアルタイム型信号処理アプリケーション１００は指定された画像イメージング装置１０から入力された入力画像６０２に対して画像処理を行い、画像受信装置６０に対して出力する。この時点での出力画像のイメージを図８のＧ１０に示す。これと同時にリアルタイム型信号処理アプリケーション１００は仮想共有バッファ２００に対して読み書きを開始する（ステップＳ１０４）。しかし、共有先のアプリケーションが存在しないため特に結果画像に効果は及ぼさない。

次に、ユーザは操作端末７０を介して、制御アプリケーション５００に対して、ベストエフォート型信号処理アプリケーション３００として、鉗子認識アプリケーションを起動させる（ステップＳ１０６）。制御アプリケーション５００を介して、鉗子認識アプリケーションが開始されると、当該アプリケーションは仮想共有バッファ２００から得られた画像に対して鉗子認識を行い（ステップＳ１０８）、その結果を出力側の仮想共有バッファ４００に書き出す（ステップＳ１１０）。リアルタイム型信号処理アプリケーション１００の処理内容には変更がないが、これにより図８のＧ２０に示す出力画像６０２ｂが得られる。この時の信号処理の流れは、上述の図５の状態と同等であり、鉗子認識アプリケーションがベストエフォート型信号処理アプリケーション３００に相当する。

次に、ユーザは鉗子認識アプリケーションを出血認識アプリケーションに切り替えるものとする。ユーザは、操作端末７０を介して、制御アプリケーション５００に対して、鉗子認識アプリケーションを終了させる操作を行う（ステップＳ１１２）。そして、制御アプリケーション５００が鉗子認識アプリケーションを終了させる（ステップＳ１１４）。この際に鉗子認識アプリケーションは出力画像が残らないよう、出力側の仮想共有バッファ４００をクリアした上で読み書きを終了する（ステップＳ１１６）。

次に、ユーザは、操作端末７０を介して、制御アプリケーション５００に対して、出血認識アプリケーションが起動させる（ステップＳ１１８）。制御アプリケーション５００を介して、出血認識アプリケーションが開始されると、当該アプリケーションは仮想共有バッファ２００から得られた画像に対して出血認識を行い（ステップＳ１２０）、その結果を出力側の仮想共有バッファ４００に書き出す（ステップＳ１２２）。リアルタイム型信号処理アプリケーション１００の処理内容には変更がないが、これにより図８のＧ３０に示す出力画像６０２ｃが得られる。この時の信号処理の流れは、図５においてベストエフォート型信号処理アプリケーションの内容が鉗子認識アプリから出血認識アプリに差し変わったことと同等になる。

その後、ユーザが出血認識アプリケーションを終了する（ステップＳ１２４，ステップＳ１２６，ステップＳ１２８）と出力画像は図８のＧ１０の状態に戻る。

このようにベストエフォート型信号処理アプリケーション３００を起動したり、終了したり、切り替えたりしても、リアルタイム型信号処理アプリケーション１００の処理内容や負荷は変わらない。すなわち、同じ分配処理と重畳処理を続けるだけであるので、切替による画乱れやフレームレートの変動は発生せず、リアルタイム型信号処理アプリケーション１００のリアルタイム性が保証される。

図９は、比較例２に係る医療情報制御システム１ａの構成例を示す図である。図９に示すように、比較例２に係る医療情報制御システム１ａは、複数の画像イメージング置１０と、送信側の複数のＩＰコンバータ３０と、ＩＰスイッチ４０と、受信側の複数のＩＰコンバータ５００と、複数の画像受信装置６０とを備える。また、ＩＰコンバータ５００は、画像処理を実行する。

図９に示すように、比較例２に係る医療情報制御システム１ａは、信号処理を行う信号サーバを有しない。このため、比較例２に係る医療情報制御システム１ａでは、画像イメージング装置１０のＣＣＵがリアルタイム信号処理及びベストエフォート型信号処理の機能を実行する。これにより、比較例２に係る医療情報制御システム１では、画像イメージング装置１０内の機能が肥大化し開発及び品質管理コストの増加につながってしまう。また同じような機能を機器ベンダーごとに提供することにより操作性が統一されず使い勝手が悪くなってしまう。

これに対して、本実施形態に係る医療情報制御システム１は、画像イメージング装置１０から信号処理サーバ２０に入力される医療用画像は、上述したように、ＳＤＩやＨＤＭＩ（登録商標）といった一般的なフォーマットであるので、個別の機器やベンダーに依存しない機能を実現できる。これにより、機能をベンダー共通にできるので操作性も統一される。また、各画像イメージング装置１０に対して信号処理サーバ２０により統一的に信号処理を行うことが可能となるので、画像イメージング装置１０内の機能が抑制可能となり、開発及び品質管理コストを減少させることができる。

図１０は、比較例３に係る医療情報制御システム１ｂの構成例を示す図である。図９に示すように、比較例３に係る医療情報制御システム１ｂは、画像イメージング置１０ と、送信側のＩＰコンバータ３０と、受信側のＩＰコンバータ５００と、画像受信装置６０とを備える。また、ＩＰコンバータ５００は、信号処理を実行する。すなわち、ＩＰコンバータ５００は、入力処理５００ａと、複数の信号処理５００ｂ、５００ｃと、出力処理５００ｄとを行う。画像イメージング装置１０からＩＰコンバータ５００に入力される画像は上述したように、ＳＤＩやＨＤＭＩ（登録商標）といった一般的なフォーマットであるので、個別の機器やベンダーに依存しない機能を実現できる。これにより、機能をベンダー共通にできるので操作性も統一される。

一方、ＩＰコンバータ５００は、一般に小型で計算能力に限りがあるため、実現できる画像処理などの信号処理性能や機能に制限がかかってしまう。特に画像の中から特定の物体や状況を検出するような、機械学習を用いた画像認識の場合は一般に処理負荷が高くなる。また、画像の内容に依存して処理負荷が変動し、画像イメージング装置１０から出力される医療用画像の表示を行う際のリアルタイム性が損なわれてしまう。これに対して、本実施形態に係る医療情報制御システム１は、信号処理サーバ２０により信号処理を行う。この場合、上述のように、トリプルバッファリングにより、ベストエフォート型信号処理アプリケーション３００を起動したり、終了したり、切り替えたりしても、リアルタイム型信号処理アプリケーション１００の処理内容や負荷は変わらないように構成している。このため、本実施形態に係るリアルタイム型信号処理アプリケーション１００では、同じ分配処理と重畳処理を続けるだけであるので、切替による画乱れやフレームレートの変動は発生せず、リアルタイム性を保証することが可能である。

以上説明したように、本実施形態によれば、信号処理サーバ２０が、第１のコンテナ仮想領域にインストールされたリアルタイム型信号処理アプリケーション１００と、第２のコンテナ仮想領域にインストールされたベストエフォート型信号処理アプリケーション３００と、がアクセス可能な複数の仮想共有バッファ２００，４００と、制御アプリケーション５００と、を有する。そして、仮想共有バッファ２００，４００は、それぞれ第１仮想メモリ領域２００ａと、第２仮想メモリ領域２００ｂと、第３仮想メモリ領域２００ｃと、を備え、制御アプリケーション５００は、リアルタイム型信号処理アプリケーション１００及びベストエフォート型信号処理アプリケーション３００の書き込みと、読み込みとを第１仮想メモリ領域２００ａと、第２仮想メモリ領域２００ｂと、第３仮想メモリ領域２００ｃと、を交互に用いるようにリアルタイム型信号処理アプリケーション１００及びベストエフォート型信号処理アプリケーション３００を制御することとした。これにより、リアルタイム型信号処理アプリケーション１００、及びベストエフォート型信号処理アプリケーション３００が互いの動作に干渉せずデータを共有することが可能となり、リアルタイム型信号処理アプリケーション１００のリアルタイム性が維持される。

また、リアルタイム型信号処理アプリケーション１００と、ベストエフォート型信号処理アプリケーション３００と、制御アプリケーション５００とは、それぞれ独立したコンテナとして信号処理サーバ上のコンテナ仮想環境に配置される。これにより、各アプリケーションをコンテナ化することで、論理的に両者の計算機リソースを切り離すことが可能となる。さらにまた、その優先度に応じて信号処理サーバ２０のＣＰＵやＧＰＵ等のリソースを優先度に応じて割り当てることで、物理的に各アプリケーションの計算機リソースを切り離すことが可能となる。

（第１実施形態の変形例）
第１実施形態に係る医療情報制御システム１は、信号処理サーバ２０が有するリアルタイム型信号処理アプリケーション１００が一つであったが、第１実施形態の変形例に係る医療情報制御システム１は、信号処理サーバ２０が複数のリアルタイム型信号処理アプリケーション１００を備える点で相違する。以下では、第１実施形態に係る医療情報制御システム１と相違する点を説明する。

図１１は、第１実施形態の変形例に係る信号処理サーバ２０の構成例を示すブロック図である。図１１に示すように、信号処理サーバ２０は、複数のリアルタイム型信号処理アプリケーション１００を備える。このような構成にすることで、信号処理サーバが複数の画像受信装置６０に対してリアルタイム型信号処理アプリケーション１００を提供できる。

なお、ベストエフォート型信号処理アプリケーション３００を複数組み合わせた構成や、３つ以上のアプリケーションを組み合わせた構成をとることも可能である。例えば、信号処理サーバ２０は、複数のリアルタイム型信号処理アプリケーション１００と、複数のベストエフォート型信号処理アプリケーション３００を備えることが可能である。このように、種々の要件に応じて、信号処理サーバ２０を構成することが可能である。

（第２実施形態）
第２実施形態に係る医療情報制御システム１は、ベストエフォート型信号処理アプリケーション３００による遅延時間を考慮した重畳処理も可能である点で第１実施形態に係る医療情報制御システム１と相違する。以下では、第１実施形態に係る医療情報制御システム１と相違する点を説明する。

図１２は、第２実施形態に係る信号処理サーバ２０の構成例を示すブロック図である。図１２に示すように、仮想共有バッファ２００に分配される入力画像６０２は、タイムスタンプもしくは連番のＩＤを付加するメタデータ領域６０２０と、差分値領域６０２２とを有する。同様に、出力画像６０４は、タイムスタンプもしくは連番のＩＤを付加するメタデータ領域６０４０ａを有する。

上述したように、ベストエフォート型信号処理アプリケーション３００は、リアルタイム型信号処理アプリケーション１００と比較して、低フレームレートであったり、処理時間が変動したりする場合が多い。その際に、リアルタイム型信号処理アプリケーション１００の出力に対して、それに重畳するベストエフォート型信号処理アプリケーション３００の出力（重畳画像）はより時間的に遅れる。この遅れの度合いによってはユーザの操作性に影響を与えてしまう。

これに対して、本実施形態に係るベストエフォート型信号処理アプリケーション３００においては、上記の遅れを加味して時間の補正をかける処理を行う。例えば、本実施形態では、遅延している時間に対する将来の値を予測して出力する処理を行う。また遅延が一定以上であれば、遅延している旨をアラート表示するといった処理も行うことが可能である。

以下では、より具体的に説明する。図１２中では、タイムスタンプの受け渡し処理における時系列の時間経過をＡ→Ｂ→Ｃ→Ｄ→Ｅ→Ｆ→Ｇの順で示す。

Ａでは、アルタイム信号処理アプリケーション１００は、画像イメージング装置１０から入力画像６０２を入力したら、その入力画像６０２のメタデータ領域６０２０にメタデータとしてタイムスタンプ（現在時刻）を付与する。その上で、入力画像６０２を仮想共有バッファ２００に書き込む。また、当入力画像６０２を自らのパイプラインに流す。例えば、信号処理Ａ→信号処理Ｂ→…とタイムスタンプが付与された画像データを受け渡す処理を行う。

次に、Ｂでは、ベストエフォート型信号処理アプリケーション３００は、仮想共有バッファ２００を介してタイムスタンプが付与された入力画像６０２を読み出し、自らのパイプラインに流す（信号処理Ｃ→信号処理Ｄ→…とタイムスタンプが付与された画像データを受け渡していく）。

次に、Ｃでは、ベストエフォート型信号処理アプリケーション３００は仮想共有バッファ４００へ出力を行う際、パイプラインを流れてきた入力画像６０２に付与されているタイムスタンプの値を、それに対応する出力画像（重畳画像）データ６０４のメタデータ領域６０４０ａにメタデータとして付与し、仮想共有バッファ４００に書き出す。

次に、Ｄでは、リアルタイム型信号処理アプリケーション１００は、仮想共有バッファ４００からタイムスタンプが付与された重畳画像データ６０４０ａを読み出す。これを自らのパイプラインを流れてきた入力画像６０２に付与されているタイムスタンプと比較する。上述したように仮想共有バッファ２００，４００の読み書きは非同期で行われるため、前者は後者よりも過去の値になっていると考えられる。リアルタイム型信号処理アプリケーション１００はこの差分値を計算する。

次に、Ｅでは、リアルタイム型信号処理アプリケーション１００はＡにおけるタイムスタンプに加えて、Ｄで計算した差分値もメタデータとして入力画像６０２の差分値領域６０２２に付与して仮想共有バッファ２００に出力する。

次に、Ｆでは、ベストエフォート型信号処理アプリケーション３００は仮想共有バッファ２００を介して読み出した入力画像６０２に付与されている差分値を読み出して、Ｂと同様に自らのパイプラインに流す。

次に、Ｇでは、ベストエフォート型信号処理アプリケーション３００は、入力画像６０２に付与されている差分値を遅延と見なして、信号処理の際にその分の時間補正を行う（差分の分だけ将来の値を予測して信号処理を行う）。もしくは仮想共有バッファ４００への出力の際に遅延している旨のアラートを重畳画像に描画する。

次に、Ｇの結果画像がリアルタイム型信号処理アプリケーション１００において重畳処理され、ＩＰコンバータ５０を介して画像受信装置６０に出力される。なお、本実施例ではタイムスタンプを用いる前提とするが、連番ＩＤでも考え方は変わらない。

以上説明したように、本実施形態に係る医療情報制御システム１は、ベストエフォート型信号処理アプリケーション３００のリアルタイム型信号処理アプリケーション１００に対する遅延時間を測定し、遅延時間に対応する時間補正を行うこととした。これにより、ベストエフォート型信号処理アプリケーション３００のリアルタイム型信号処理アプリケーション１００に対する遅延時間による位置ずれを、出力画像６０６において抑制可能となる。

（第３実施形態）
第３実施形態に係る医療情報制御システム１は、リアルタイム型信号処理アプリケーション１００の処理変更を考慮した重畳処理も可能である点で第２実施形態に係る医療情報制御システム１と相違する。以下では、第３実施形態に係る医療情報制御システム１と相違する点を説明する。

図１３は、第３実施形態に係る信号処理サーバ２０の構成例を示すブロック図である。図１３に示すように、仮想共有バッファ２００に分配される入力画像６０２は、タイムスタンプ以外のメタデータを付与することも可能であるメタデータ領域６０２４を更に有する。本実施系形態に係る画像送出装置１０は、画像イメージング置に対応する。

ここでは、リアルタイム型信号処理アプリケーション１００の信号処理１００ｇで画像のズームを行って、ベストエフォート型信号処理アプリケーションで鉗子認識アプリケーションを動かす場合を説明する。

まず、リアルタイム型信号処理アプリケーション１００の信号処理１００ｇは、画像６０２ズーム処理を行い、ズーム画像６０２８を生成する。

次に、リアルタイム型信号処理アプリケーション１００の信号処理１００ｇのズーム倍率を、リアルタイム型信号処理アプリケーション１００は、入力画像６０２のメタデータ領域６０２４に付与する。ベストエフォート型信号処理アプリケーション３００のバウンディングボックス描画を行う信号処理２００ｇは、バウンディングボックスを描画する際にメタデータ領域６０２４に付与された倍率を反映する。さらに、バウンディングボックスは、最終的にズーム画像と重ね合わせたときに、信号処理３００ａ（入力）、３００ｂ（鉗子認識）、３００ｇ（バウンディングボックス生成）、出力３００ｄによって生成されたバッファに格納された内容が、ズーム画像に表示されている内容と一致するように、対応する１．５倍のズーム率で描画されるようになっている。

このように、リアルタイム型信号処理アプリケーション１００からベストエフォート型信号処理アプリケーション３００に対して仮想共有バッファ２００のメタデータとして常に倍率を渡すようにする。これにより、ベストエフォート型信号処理アプリケーション３００が鉗子のバウンディングボックスを描画する際にその倍率を反映することが可能となる。このため、リアルタイム型信号処理アプリケーション１００のズーム処理に鉗子認識結果の描画を合わせることができると共に、滑らかなアニメーションで連続的に倍率を変えてズームする場合でも追従することが可能となる。出力画像６０６０は、画像受信装置６０に提供され、重畳データ６０４２のコンテンツが、ズーム画像６０２８に重ねて表示される。重畳データ６０４２のコンテンツは、ベストエフォートで作成されるため、リアルタイムで更新されない場合がある。重畳データ６０４２のコンテンツは、透過領域を有するために出力画像６０６０において基礎となるズーム画像６０２８を完全に覆い隠していない。したがって、手術スタッフは、ズーム画像６０２８に重畳されたコンテンツによって手術部位の一部が覆い隠されていることに不満を感じずに手術を行うことができる。

（第４実施形態）
第４実施形態に係る医療情報制御システム１は、仮想共有バッファの構成やＧＰＵ構成において他実施形態に係る医療情報制御システム１と相違する。以下では、第４実施形態に係る医療情報制御システム１と相違する点を説明する。

図１４は、第４実施形態に係る信号処理サーバ（Ｓｅｒｖｅｒに対応）２０の構成例を示すブロック図である。図１４は、信号処理サーバが２つのＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であるＧＰＵ１４４１（ＧＰＵ＃１）と、ＧＰＵ１４４２（ＧＰＵ＃２）とを含むこと以外は、図１３に示す構成と同様のブロック図である。さらに、ＧＰＵ＃２は、複数のベストエフォート型信号処理アプリケーションを実行し、それぞれが独自の共有バッファ１４０５および１４０７を有するとともに、図１６にてより詳細に説明する共有バッファ１４０３を有している。なお、共有バッファはＳｈａｒｅｄ Ｂｕｆｆｅｒに、ベストエフォート型信号処理アプリケーションはＢｅｓｔ－ｅｆｆｏｒｔ ａｐｐｌｉｃａｔｉｏｎに、画像送出装置はＭｅｄｉｃａｌ ｉｍａｇｉｎｇ ｄｅｖｉｃｅに、ＩＰコンバータはＩＰ ｃｏｎｖｅｒｔｅｒに、リアルタイム型信号処理アプリケーションはＲｅａｌ－ｔｉｍｅ ａｐｐｌｉｃａｔｉｏｎに、入力処理はＩｎｐｕｔ Ｐｒｏｃｅｓｓｉｎｇに、分配処理はＤｉｓｔｒｉｂｕｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇに、信号処理はＳｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇに、重畳処理はＳｕｐｅｒｐｏｓｉｔｉｏｎに、出力処理はＯｕｔｐｕｔに、画像受信装置はＤｉｓｐｌａｙに対応する。

図１４に示す構成では、ＧＰＵ＃１は、リアルタイム型信号処理アプリケーションを実行している。これは画像送出装置からの画像を各フレームで受信したときに処理し、一定の時間枠（術者が一般的に知覚できない小さな処理遅延）内でフレームが入力されるのと実質的に同じレートでフレームを出力することを意味する。 例となる入力フレーム１４１０は、信号処理Ａ、信号処理Ｂとして示される複数の信号処理プロセスによって処理される例として示されているが、ＧＰＵ＃１上では、より多くのプロセスがリアルタイムで実行されてもよい。第３の実施形態のズームアプリケーションは、医療画像に適用され得る信号処理プロセスの１つのタイプに関する例に過ぎず、他のアプリケーションが適用されてもよい。

共有バッファ１４０５からの出力は、ＧＰＵ＃２で実行される信号処理Ｃと信号処理Ｄを含むベストエフォート型信号処理アプリケーション＃２によって生成されるオーバーレイコンテンツ１４３０を提供する。この例では、オーバーレイコンテンツ１４３０は、医療機器／ツール検出を行うバウンディングボックス１４３１、１４３２、１４３３である。 なお、必ずしもリアルタイムで生成されるわけではないが、医療機器／ツール検出バウンディングボックス１４３１、１４３２、１４３３は、出力画像１４５０に示されるように、手術画像に存在する医療機器を識別する。同様に、共有バッファ１４０３を介して入力画像に信号処理Ｃ、及び信号処理Ｄを適用することにより、ＧＰＵ＃２においてベストエフォート型信号処理アプリケーション＃１が実行される。この例では、ベストエフォート型信号処理アプリケーション＃１は、手術シーンの組織が活発な出血を示す領域を検出する。このとき、２つのバウンディングボックス１４２１及び１４２２は、ベストエフォート型信号処理アプリケーション＃１によって提供されるオーバーレイコンテンツ１４２０の一部であり、出力画像１４５０において出血部位を識別するように、重畳処理により最終的に画像１４１０上にオーバーレイされる。 出力画像１４５０は、ＧＰＵ＃１上で実行されたリアルタイム型信号処理アプリケーションによって提供されたリアルタイム画像内の画像特徴を識別するために、ＧＰＵ＃２上で実行されたベストエフォート型信号処理アプリケーションによって生成されたオーバーレイ用のバウンディングボックス（それぞれ不透明でもよいが、透過度を有する）を含む。

図１４では、共有バッファ１４０３が、ＧＰＵ＃１にホストされるのではなく、ＧＰＵ＃２にホストされるものとして示されている。共有バッファ１４０３をＧＰＵ＃１にホストすることは可能であるが、本発明者は、そのような構成では、ＧＰＵ間で２倍のデータを転送する必要があり、既にリアルタイム処理を行う役割を担っているＧＰＵ＃１に負荷がかかることを見出した。これに対し、ＧＰＵ＃２に共有バッファをホストすることで、ＧＰＵ内バス１５０１（図１５）を介して伝達する必要のあるデータは半分で済むようになる。 なお、ＧＰＵ＃２は２つのベストエフォート型信号処理アプリケーションを実行する例を示しているが、ＧＰＵ＃２はより多くのベストエフォート型信号処理アプリケーションを実行することも可能である。ＧＰＵ＃２でＮ個のアプリケーションが実行されたとしても、共有バッファ１４０３がＧＰＵ＃２でホストされている限り、データバスの使用量や、ＧＰＵ＃１のプロセッサ間通信の負荷がそれ以上拡大することはなく、ＧＰＵ＃２でより多くのベストエフォート型信号処理アプリケーションをサポートするためのスケーラビリティを可能とする構成となっている。

図１６は、第４実施形態に係る共有バッファの構成及び処理例を示すブロック図である。共有バッファ１４０３の構造は、４つの内部デュアルポート共有バッファ（Ｂｕｆｆｅｒ１、Ｂｕｆｆｅｒ２、Ｂｕｆｆｅｒ３、Ｂｕｆｆｅｒ４）を有するものとして示されているが、この構造は単なる例示である。より一般的には、共有バッファ１４０３は、Ｎ＋２バッファであり、ここで、Ｎは、共有バッファ１４０３によって供給される「コンシューマ・プロセス （Ｃｏｎｓｕｍｅｒ Ｐｒｏｃｅｓｓ）」（または、実行されるベストエフォート型信号処理アプリケーション）の数である。 なお、Ｎ＋２以上の内部バッファが使用されてもよいが、２以上の追加バッファでは、内部バッファの少なくとも１つが、入力（ＧＰＵ＃１にホストされた分配処理を介して提供される画像送出装置からの画像入力などのプロデューサ・プロセス（Ｐｒｏｄｕｃｅｒ Ｐｒｏｃｅｓｓ））またはコンシューマ・プロセスのいずれによっても使用されないことが好ましい。２つ（あるいはそれ以上）の追加バッファを必要とする理由は、図１６に関して後述する。

入力側が特定の共有バッファにデータを格納している最中は（例えば、データＤ１を共有バッファ１に格納する）、バッファ１のデータは安定しておらず、完了していないので取り出すことができない。しかし、データＤ１がバッファ１に完全に書き込まれると、コンシューマ・プロセス１および２（ＣＰ１およびＣＰ２）はそれを取り出すことができる。なお、プロデューサ・プロセスがデータＤ１をバッファ１に書き込み終えると、共有バッファ１４０３は、コントローラモニタ、フラグ設定などの任意の方法によって、バッファ１が安定していることを示すことができる。

データＤ１がバッファ１に格納されると、プロデューサ・プロセスは、バッファ２（またはＮ＋１の別のバッファ）にデータＤ２の書き込みを開始する。 その後、バッファ１はＣＰ１およびＣＰ２からアクセスできるようになる。データＤ２がバッファ２に書き込まれると、ＣＰ１およびＣＰ２がアクセスできるようになる。しかし、ＣＰ１の方がＣＰ２よりもスループットが速いため、ＣＰ１がバッファ２にアクセスを開始した後に、ＣＰ２がバッファ２にアクセスすることがある。このように、ＣＰ１とＣＰ２はアクセスが同期していない可能性があるため、Ｎ個のベストエフォート型信号処理アプリケーションは、任意の時間にＮ個のバッファにアクセスすることになる。しかし、プロデューサ・プロセスは、これらのＮ個のバッファのいずれかに同時にデータを保存することはできない。そのため、追加のバッファをアクティブにしてそこにデータを保存し、合計でＮ＋１個のバッファを作ることになる。しかし、プロデューサ・プロセスは、１つの内部バッファへのデータの保存を終えようとすると、次に利用可能なバッファを知る必要があり、そのバッファに入ってくるデータをすぐに満たして、オーバーロードの状況が発生しないようにする必要がある。さらに、プロデューサ・プロセスは、自分が満たしている現在のバッファに加えて、次に利用可能なバッファを知る必要がある。したがって、入力側（すなわち、プロデューサー・プロセス）は、独立して動作する（ＣＰ１またはＣＰ２との調整を必要としない）２つのバッファを必要とする。すなわち、独立した非同期の入力および出力動作をサポートするためにプロデューサ・プロセスが共有バッファ１４０３にデータを書き込むのをサポートするための２個の追加の内部バッファが必要となり、Ｎ個のベストエフォートアプリケーション用のＮ＋２個のバッファが必要となる。このとき、ＣＰ２およびＣＰ２は、すべての入力データを必要としない可能性があるアプリケーションであってもよい。 例えば、ＣＰ２は、プロセッサを多用するプロセスであり、すべての画像データを解析する必要がない場合がある。この場合、ＣＰ２は、ＣＰ１よりもはるかに遅い速度で内部バッファのデータにアクセスしてもよく、そのようなＣＰ２は、バッファ１４０３の２番目／３番目／４番目．．．のデータエントリごとにしか読まなくてもよい。

また、ＣＰ１および／またはＣＰ２は、特にＣＰ１とＣＰ２が同じ速度または同じタイミングで読み取りを開始した場合、待機モードで動作してもよい。 言い換えれば、ＣＰ１がＣＰ２と同じデータを処理することが望ましいが、ＣＰ２はＣＰ１よりも遅くデータを読み取るとする。この場合、ＣＰ１を待機モードにして、ＣＰ２が前のバッファの読み出しを終えるのを待ってから、ＣＰ１がＣＰ２と一緒に次のバッファを読み出すことができる。また、次のバッファへの書き込みが完了していない場合も、ＣＰ１を待機モードにすることができる。ＣＰ１が待機モードで動作する利点は、ＣＰ１がＣＰ２よりも低いレイテンシ要件を持つ場合があるため、レイテンシ（入力から出力までの遅延時間）が最も短いコンシューマ・プロセスを待機モードに設定可能となる点である。

共有バッファは、Ｎ＋２以上のバッファを持つことができ、Ｎ＋２を超える追加のバッファは、追加のプロセス（例えばＣＰ３）がオンラインになった場合に備えて予備として保持してもよい。例えば、ＣＰ３がオンラインになるまで、プロデューサ・プロセスは、５番目の内部バッファに書き込まない（５ ＝ Ｎ （ｎｏｗ ３） ＋２）。 同様に、ＣＰがオフラインになった場合は、内部バッファがオフラインになり、予備として保持される。

なお、本技術は以下のような構成をとることができる。
（１） 手術室の医療機器にネットワークを介して接続され、コンテナ仮想環境が構築された手術サーバと、
を備え、
前記手術サーバは、
第１のコンテナ仮想領域にインストールされた、前記医療機器から出力された情報に基づいて第１の処理を行って第１の医療情報を生成する第１の医療アプリケーションと、第２のコンテナ仮想領域にインストールされた、前記第１の処理とは異なる処理量の第２の処理を行って第２の医療情報を生成する第２の医療アプリケーションと、がアクセス可能な複数の仮想共有バッファと、
制御アプリケーションと、を有し、
前記複数の仮想共有バッファは、それぞれ第１仮想メモリ領域と、第２仮想メモリ領域と、第３仮想メモリ領域と、を備え、
前記制御アプリケーションは、前記第１の医療アプリケーションの書き込みと前記第２の医療アプリケーションの読み込みとを前記第１仮想メモリ領域と、前記第２仮想メモリ領域と、前記第３仮想メモリ領域と、を交互に用いるように前記第１の医療アプリケーションまたは前記第２の医療アプリケーションを制御する
、医療情報制御システム。
（２） 前記第２の医療アプリケーションは、前記第１の医療アプリケーションよりも処理量が大きい、
（１）に記載の医療情報制御システム。
（３） 前記第２の医療アプリケーションは、処理対象となる入力画像の内容によって処理量が変動する信号処理である、（１）に記載の医療情報制御システム。
（４） 前記第１の医療アプリケーションは、前記複数の仮想共有バッファのうちの入力側の仮想共有バッファを介して入力画像を前記第２の医療アプリケーションに供給し、
前記第２の医療アプリケーションは、前記入力画像に基づき、前記第２の医療情報を生成し、前記複数の仮想共有バッファのうちの出力側の仮想共有バッファを介して、前記第２の医療アプリケーションに供給する、（３）に記載の医療情報制御システム。
（５） 前記第２の医療アプリケーションは、時系列に供給される入力画像に基づき、第１の医療情報を時系列に生成すると共に、前記出力側の仮想共有バッファを介して供給される前記第２の医療情報に基づく情報を付与して出力する、（４）に記載の医療情報制御システム。
（６） 前記第２の医療アプリケーションは、処理時間に応じた予測処理により前記第２の医療情報を生成する、（４）又は（５）に記載の医療情報制御システム。
（７） 前記入力画像に関連づけられた処理の開始時刻と処理の終了時刻とに基づき、前記第２の医療アプリケーションの遅延時間を計測し、
前記第２の医療アプリケーションは、前記遅延時間に基づき、前記予測処理を行う、（６）に記載の医療情報制御システム。
（８） 前記第２の医療アプリケーションは、前記入力画像に対する信号処理により生成された位置情報を示す情報を透明度付きの画像上に生成し、前記第２の医療アプリケーションは、前記出力側の仮想共有バッファを介して供給された前記透明度付きの画像と前記入力画像に基づく画像とを前記透明度を用いて重畳する、（４）乃至（７）のいずれかに記載の医療情報制御システム。
（９） 前記入力画像に対する信号処理は、鉗子、及び出血部の少なくとも一方の認識処理である、（８）に記載の医療情報制御システム。
（１０） 前記第１の医療アプリケーションは、前記第１の医療アプリケーションにおける信号処理の変更に関する情報を前記入力画像に関連づけて前記第２の医療アプリケーションに供給し、前記第２の医療アプリケーションは、前記信号処理の変更に関する情報に基づき、信号処理を変更する、（４）乃至（９）のいずれかに記載の医療情報制御システム。
（１１） 医療イメージング装置と、
前記医療イメージング装置で撮像された医療用画像を所定の画像形式に変更する入力側のＩＰコンバータと、
前記所定の画像形式の医療用画像、及び前記手術サーバから供給される処理済み画像の供給先を切り換えるＩＰスイッチであって、前記所定の画像形式の医療用画像を前記手術サーバに供給可能なＩＰスイッチと、
前記ＩＰスイッチから供給される画像を所定の画像形式に変更する出力側のＩＰコンバータと、
前記出力側のＩＰコンバータから供給される画像を表示する画像受信装置と、
を更に備える、（１）乃至（１０）のいずれかに記載の医療情報制御システム。
（１２） 前記のＩＰコンバータ、前記ＩＰスイッチ及び前記手術サーバの少なくとも１つは、他の装置から取得した制御コマンドに基づいて処理を実行する、（１１）に記載の医療情報制御システム。
（１３） 手術室の医療機器にネットワークを介して接続され、コンテナ仮想環境が構築された手術用の信号処理装置であって、
第１のコンテナ仮想領域にインストールされた、前記医療機器から出力された情報に基づいて第１の処理を行って第１の医療情報を生成する第１の医療アプリケーションと、第２のコンテナ仮想領域にインストールされた、前記第１の処理とは異なる処理量の第２の処理を行って第２の医療情報を生成する第２の医療アプリケーションと、がアクセス可能な複数の仮想共有バッファと、
制御アプリケーションと、を有し、
前記複数の仮想共有バッファは、それぞれ第１仮想メモリ領域と、第２仮想メモリ領域と、第３仮想メモリ領域と、を備え、
前記制御アプリケーションは、前記第１の医療アプリケーションの書き込みと前記第２の医療アプリケーションの読み込みとを前記第１仮想メモリ領域と、前記第２仮想メモリ領域と、前記第３仮想メモリ領域と、を交互に用いるように前記第１の医療アプリケーションまたは前記第２の医療アプリケーションを制御する
、信号処理装置。
（１４） 手術室の医療機器にネットワークを介して接続され、コンテナ仮想環境が構築され、
第１のコンテナ仮想領域にインストールされた、前記医療機器から出力された情報に基づいて第１の処理を行って第１の医療情報を生成する第１の医療アプリケーションと、第２のコンテナ仮想領域にインストールされた、前記第１の処理とは異なる処理量の第２の処理を行って第２の医療情報を生成する第２の医療アプリケーションと、がアクセス可能な複数の仮想共有バッファと、
制御アプリケーションと、を有し、
前記複数の仮想共有バッファは、それぞれ第１仮想メモリ領域と、第２仮想メモリ領域と、第３仮想メモリ領域と、を備える信号処理装置の医療情報制御方法であって、
前記制御アプリケーションは、前記第１の医療アプリケーションの書き込みと前記第２の医療アプリケーションの読み込みとを前記第１仮想メモリ領域と、前記第２仮想メモリ領域と、前記第３仮想メモリ領域と、を交互に用いるように前記第１の医療アプリケーションまたは前記第２の医療アプリケーションを制御する、医療情報制御方法。
本開示の態様は、上述した個々の実施形態に限定されるものではなく、当業者が想到しうる種々の変形も含むものであり、本開示の効果も上述した内容に限定されない。すなわち、特許請求の範囲に規定された内容およびその均等物から導き出される本開示の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更および部分的削除が可能である。

１：医療情報制御システム、１０：医療イメージング装置、２０：信号処理サーバ、３０：ＩＰコンバータ、４０：ＩＰスイッチ、５０：ＩＰコンバータ５０：リアルタイム型信号処理アプリケーション、２００：仮想共有バッファ、３００：ベストエフォート型信号処理アプリケーション、４００：仮想共有バッファ、５００：制御アプリケーション。

Claims (19)

1. 手術室に設置された医療機器とネットワークを介して接続された手術サーバと、
   を備え、
   前記手術サーバは、
   医療機器で生成された医療画像を取得し、
   コンテナ仮想領域にインストールされユーザが選択可能なリアルタイム型信号処理アプリケーションおよびベストエフォート型信号処理アプリケーションを実行し、
   前記リアルタイム型信号処理アプリケーションによって処理された医療画像に前記ベストエフォート型信号処理アプリケーションの処理結果を重ね合わせる、
   医療情報制御システム。
2. 前記手術サーバは、
   第１のコンテナ仮想領域にインストールされた、前記医療機器から出力された情報に基づいて第１の処理を行って第１の医療情報を生成するリアルタイム型信号処理アプリケーションと、第２のコンテナ仮想領域にインストールされた、前記第１の処理とは異なる処理量の第２の処理を行って第２の医療情報を生成するベストエフォート型信号処理アプリケーションと、がアクセス可能な複数の仮想共有バッファと、
   制御アプリケーションと、を有し、
   前記複数の仮想共有バッファは、それぞれ第１仮想メモリ領域と、第２仮想メモリ領域と、第３仮想メモリ領域と、を備え、
   前記制御アプリケーションは、前記リアルタイム型信号処理アプリケーションの書き込みと前記ベストエフォート型信号処理アプリケーションの読み込みとを前記第１仮想メモリ領域と、前記第２仮想メモリ領域と、前記第３仮想メモリ領域と、を交互に用いるように前記リアルタイム型信号処理アプリケーションまたは前記ベストエフォート型信号処理アプリケーションを制御する
   、請求項１に記載の医療情報制御システム。
3. 前記ベストエフォート型信号処理アプリケーションは、前記リアルタイム型信号処理アプリケーションよりも処理量が大きい請求項１に記載の医療情報制御システム。
4. 前記ベストエフォート型信号処理アプリケーションは、処理対象となる入力画像の内容によって処理量が変動する信号処理である、請求項１に記載の医療情報制御システム。
5. 前記リアルタイム型信号処理は、前記複数の仮想共有バッファのうちの入力側の仮想共有バッファを介して入力画像を前記ベストエフォート型信号処理アプリケーションに供給し、
   前記ベストエフォート型信号処理アプリケーションは、前記入力画像に基づき、前記第２の医療情報を生成し、前記複数の仮想共有バッファのうちの出力側の仮想共有バッファを介して、前記リアルタイム型信号処理アプリケーションに供給する、請求項４に記載の医療情報制御システム。
6. 前記リアルタイム型信号処理アプリケーションは、時系列に供給される入力画像に基づき、第１の医療情報を時系列に生成すると共に、前記出力側の仮想共有バッファを介して供給される前記第２の医療情報に基づく情報を付与して出力する、請求項１に記載の医療情報制御システム。
7. 前記ベストエフォート型信号処理アプリケーションは、処理時間に応じた予測処理により前記第２の医療情報を生成する、請求項１に記載の医療情報制御システム。
8. 前記入力画像に関連づけられた処理の開始時刻と処理の終了時刻とに基づき、前記ベストエフォート型信号処理アプリケーションの遅延時間を計測し、
   前記ベストエフォート型信号処理アプリケーションは、前記遅延時間に基づき、前記予測処理を行う、請求項７に記載の医療情報制御システム。
9. 前記ベストエフォート型信号処理アプリケーションは、前記入力画像に対する信号処理により生成された位置情報を示す情報を透明度付きの画像上に生成し、前記リアルタイム型信号処理アプリケーションは、前記出力側の仮想共有バッファを介して供給された前記透明度付きの画像と前記入力画像に基づく画像とを前記透明度を用いて重畳する、請求項１に記載の医療情報制御システム。
10. 前記入力画像に対する信号処理は、鉗子、及び出血部の少なくとも一方の認識処理である、請求項９に記載の医療情報制御システム。
11. 前記リアルタイム型信号処理アプリケーションは、前記リアルタイム型信号処理アプリケーションにおける信号処理の変更に関する情報を前記入力画像に関連づけて前記ベストエフォート型信号処理アプリケーションに供給し、前記ベストエフォート型信号処理アプリケーションは、前記信号処理の変更に関する情報に基づき、信号処理を変更する、請求項５に記載の医療情報制御システム。
12. 医療イメージング装置と、
    前記医療イメージング装置で撮像された医療用画像を所定の画像形式に変更する入力側のＩＰコンバータと、
    前記所定の画像形式の医療用画像、及び前記手術サーバから供給される処理済み画像の供給先を切り換えるＩＰスイッチであって、前記所定の画像形式の医療用画像を前記手術サーバに供給可能なＩＰスイッチと、
    前記ＩＰスイッチから供給される画像を所定の画像形式に変更する出力側のＩＰコンバータと、
    前記出力側のＩＰコンバータから供給される画像を表示する画像受信装置と、
    を更に備える、請求項１に記載の医療情報制御システム。
13. 前記のＩＰコンバータ、前記ＩＰスイッチ及び前記手術サーバの少なくとも１つは、他の装置から取得した制御コマンドに基づいて処理を実行する、請求項１２に記載の医療情報制御システム。
14. 前記手術サーバは、
    前記リアルタイム型信号処理アプリケーションが書き込み、Ｎ個のベストエフォート型信号処理アプリケーションが読み込む共有バッファにおいて、仮想共有バッファ領域の数がＮ＋２以上となるように設定する、
    請求項１に記載の医療情報制御システム。
15. 前記手術サーバは、
    複数のベストエフォート型信号処理アプリケーションのうちいずれか１つのベストエフォート型信号処理アプリケーションの読み込みが待機となる待機モードを設定する、
    請求項１に記載の医療情報制御システム。
16. 前記手術サーバは、
    実行されるベストエフォート型信号処理アプリケーションの数に基づいて、仮想共有バッファ領域のアクティベートを制御する、
    請求項１４に記載の医療情報制御システム。
17. 前記手術サーバは、複数のＧＰＵを備え、前記リアルタイム型信号処理アプリケーションを実行するＧＰＵと、前記ベストエフォート型信号処理アプリケーションを実行するＧＰＵと、を異ならせる
    請求項１に記載の医療情報制御システム。
18. 機器とネットワークを介して接続された信号処理装置であって、
    前記機器で生成された画像を取得し、
    コンテナ仮想領域にインストールされユーザが選択可能なリアルタイム型信号処理アプリケーションおよびベストエフォート信号処理アプリケーションを実行し、
    前記リアルタイム型信号処理アプリケーションによって処理された画像に前記ベストエフォート信号処理アプリケーションの処理結果を重ね合わせる、
    信号処理装置。
19. 手術室に設置された医療機器とネットワークを介して接続された医療情報処理システムの動作方法であって、
    医療機器で生成された医療画像を取得し、
    コンテナ仮想領域にインストールされユーザが選択可能なリアルタイム型信号処理アプリケーションおよびベストエフォート型信号処理アプリケーションを実行し、
    前記リアルタイム型信号処理アプリケーションによって処理された医療画像に前記ベストエフォート型信号処理アプリケーションの処理結果を重ね合わせる、
    医療情報処理システムの動作方法。

Images