JP2008540015A - 組み込みネットワークアナライザ付き超音波診断イメージングシステム - Google Patents

Abstract

超音波診断イメージングシステム10が、それ自身オンボードのネットワークアナライザ34を具備する。超音波システムが接続されるネットワークで障害が発見されるとき、そのネットワークアナライザが超音波システム上で開始される。超音波システムからネットワーク上の別のデバイスにDICOMデータを送信することでテストが実行される。ネットワークアナライザはDICOM通信に関するrawパケットデータのキャプチャファイルを作り出すため、及びネットワーク上のDICOM通信データを解析するといった解析用にユーザにキャプチャファイルを提供するため、リスニングモードで動作可能である。

Description

本発明は、医療用の超音波診断システムに関し、特に、オンボードのネットワーク監視及び解析機能を備える超音波診断システムに関する。

超音波システムは、一般に、非常に携帯性に優れた器具としてデザインされ構築される。超音波システムは、患者のベッドサイドに移動されることができる、カート状器具として、又はラップトップ若しくはタブレットコンピュータの大きさのポータブル器具として構築されることができる。この携帯性は、超音波システムが病院又はクリニックの周囲を移動されることができることを意味するが、その一方で通常、格納又はレビューのためデジタル画像が別の拠点に電子的に送信されることができるよう、超音波システムをネットワークに接続することに対する要求がしばしば存在する。米国特許第5,715,823号(Woodらによる)は、インターネットに接続されることができる超音波システムを開示する。それにより、システムによって取得される画像が世界中からアクセスされ、世界中に送信されることができる。生の画像ループ(live image loop)といった大きな画像ファイルは、大容量のデジタル記憶を使うので、病院又はクリニックといった大規模な施設(institutional setting)では、画像アーカイブ通信システム(PACS)といった個別のデバイスにこれらの画像を格納することが望ましいことが多い。これを可能とするため、超音波システムが病院又はクリニックのネットワークにうまくかつ簡単にインタフェース接続する(interface)ことができるよう、超音波システムは接続能力を持つ必要がある。

しかしながら、超音波システムが、病院又はクリニックのネットワークを介してうまく通信しない場合があることが明らかになった。これは、ハードウェアの不適合性が原因の場合もあるが、より多くは、超音波システムのネットワーク・セットアップにおいて有効な接続を確立するのに必要なネットワークに関するプロトコル及び交換(exchange)が不適合であることが原因である。超音波システムが最初にネットワークに接続され、不適合性が明らかになるとき、又は、最初の接続より後にネットワーク若しくはネットワーク上の他のデバイスに対する変更がなされるとき、これらの障害が生じる可能性がある。斯かる場合において、この障害を解消するため超音波システムの修理担当者が呼び出されることになる。修理担当者は最初のアクションとして、その障害を解析しようとしてネットワーク解析デバイスをネットワークに接続することを要求することができる。しかし、病院及びクリニックは一般的に斯かる接続を許可することに対して消極的である。なぜなら、これらのネットワークは通常複雑であり、そのネットワークには、慎重に扱うべき医療に関する個人的な患者データが含まれるからであり、病院やクリニックといった施設は、これらの患者データの情報漏洩が起きないことを希望するからである。ウイルスに対する懸念及び他の可能性として未知のソフトウェアによるネットワークへのアクセスに基づく有害な効果に対する懸念も存在する。従って、解析装置及びデバイスを病院ネットワークへ持ち込むことは、そのネットワーク及びデータのセキュリティを維持しようとするネットワーク管理者と、超音波システムのネットワーク接続を解決しようとする修理担当者との両方にとって問題を生じさせる可能性がある。

本発明の原理によれば、オンボードのネットワーク解析機能を含む超音波診断イメージングシステムが提供される。この機能は、ネットワーク接続障害が生じるとき、他のいずれの機器をネットワークに接続することなく、超音波システムからネットワークレベルでネットワークトラフィックを監視するのに使用されることができる。ネットワーク上のデータトラフィックは、監視され、かつ選択的にキャプチャされることができ、その後超音波システムに関連するネットワーク障害の原因箇所を特定するために解析されることができる。超音波システムがネットワークを介してDICOMフォーマットデータを送信又は受信する必要があるとき、そのシステムは特に有益である。

まず図１を参照すると、本発明の原理に基づき構築される超音波診断イメージングシステム１０及びネットワークが、ブロック図形式で示される。超音波システム１０の超音波画像取得、処理及び表示経路は、トランスデューサ要素１４のアレイを持つアレイプローブ１２で始まる。トランスデューサアレイは、ビーム形成器１６の制御の下超音波を送信し、画像化される対象物からのエコー信号を受信する。エコー信号は、電気信号へと変換される。アレイの個別の要素により受信される信号は、コヒーレントなエコー信号を形成するよう、ビーム形成器１６により適切に遅延されかつ結合される。その後、取得され表示されることになる情報のタイプに応じて、エコー信号に対して特定の処理が行われることができる。例えば、検出、フィルタリング、ドップラ処理、調和信号分離等が行われる。この処理は、信号プロセッサ２２により実行される。処理された信号から、画像プロセッサ２４による所望の表示フォーマットの画像が形成され、処理された画像が画像ディスプレイ２０に表示される。その画像は、更なる処理及びレビューのため、又は後の表示のために画像記憶部２６に格納されることができる。

画像取得、処理及び表示経路の処理機能は、その信号経路の要素に結合されるシステムコントローラ３０により制御及び調整される。システムコントローラは、ユーザからのコマンドに応答し、そのコマンドは、ディスプレイ上のグラフィック・ユーザ・インタフェースを介して、又は制御パネル３２若しくは音声認識システムから入力されることができる。システムコントローラは、ユーザインタフェース及び／又はディスプレイ２０に関する機能を実行するオペレーティングシステム(OS)３１を起動する。本発明の原理によれば、そのOSは、一般的にディスクドライブ又は他の記憶媒体に格納されるネットワーク監視及び解析アプリケーション３４も実行することができる。ネットワーク監視及び解析アプリケーションは、利用可能な様々なアプリケーションのうちの一つであってよい。使用されるOS及び他の操作上の考慮事項に基づき、アプリケーションの選択が行われる。適切なアプリケーションとしては、UNIX（登録商標）プラットフォームにおけるtcpdump、Windows（登録商標）プラットフォームにおけるWinDump及びWinPcap、Ethereal、libpcap及び自由にダウンロードして入手可能な他の多くのソフトウェアを含む。OS３１は、超音波システムがネットワーク４０を介して通信するのに用いられるネットワークアダプタ３６に結合される。ネットワークアダプタは、超音波システム１０がネットワーク４０を介して通信するのに用いられるハードウェア及びソフトウェアを有し、そのハードウェア及びソフトウェアのためのフォーマットは、Ethernet（登録商標）、FDDI、PPP、トークンリング、IEEE 802.11、I²Cその他を含む。一般的に、ネットワークアダプタは、ネットワークインタフェースカード(NIC)又はモデムカードの形式であろう。超音波システムがネットワーク４０に接続されるとき、超音波システムはネットワーク上にある他のデバイスと通信することができる。他のデバイスは、例えば、病院情報／放射線情報システム(HIS／RIS)４２、画像アーカイブ通信システム(PACS)４４、及びワークステーション端末４６を含む。

超音波システム１０が最初にネットワーク４０に接続されるとき、又はネットワーク４０に接続されている間、超音波システムとネットワーク上の別のデバイスとの間の通信の一部又は全体で障害が発生する場合がある。例えば、超音波システムの画像プロセッサ２４は、画像及び他の情報をDICOMフォーマットでフォーマット化することができる。DICOMは、診断画像及び他の医療情報に関し広く普及しているフォーマットであり、超音波画像は、しばしばDICOMフォーマットでエンコードされ格納される。図１の装置において、例えば、PACSシステム４４に、DICOMフォーマットされた画像を格納することが望ましい場合がある。DICOM情報の記憶部に対するネットワーク通信がうまく行かない場合、そのネットワーク通信障害を解決するのに、ネットワーク監視及び解析アプリケーションが使用されることができる。

上述のWoodらによる特許において例えば示される、TCP/IPネットワークを介してデータを送信及び受信するよう構成される超音波システムは、パケットと呼ばれるデータのブロックを用いて動作する。ネットワーク上の各データパケットは、パケットの発信元であるデバイス、パケットの送信先であるデバイス、データタイプその他といったパケットの特定の特性を識別するヘッダを持つ。ネットワーク監視及び解析プログラムは、ネットワーク上のパケットの流れを監視し、それらのパケットをraw形式で記録又はキャプチャする。例えば、超音波システムのEthernet（登録商標）カードがネットワークからパケットを受信すると仮定する。そのパケットは、OSに渡され、OSは、どのタイプのパケットが受信されたかを決定しなければならない。OSは、パケットのEthernet（登録商標）ヘッダを取り出し、次のレイヤを見ることでこの決定を行う。そのパケットがIPパケットであることが判明したとする。するとOSは、そのパケットがどのタイプのIPパケットであるかを決定するため、IPヘッダを取り出す。これはUDP(User Datagram Protocol)パケットであるとOSが判別したと仮定する。すると、OSは、UDPヘッダを取り出し、そのパケットが処理されるアプリケーションにそのパケットを渡す。この時点でそのパケットを解析しても、そのネットワークを介した通信に関する情報はほとんど得られることができない。なぜなら、ヘッダが削除されてしまっているからである。本発明のネットワーク監視アナライザの目的は、ネットワークを介した通信及び他のネットワークデバイスの効果を研究することができるよう、ヘッダが手付かずの状態のままこれらのパケットをキャプチャすることである。このため、キャプチャシステムは、超音波システムのプロトコルスタックをバイパスし、ネットワークインタフェースと直接やり取りしてネットワーク上のrawデータトラフィックにアクセスする必要がある。

ネットワーク監視及び解析パッケージは、ネットワークを通過するすべてのパケット・トラフィックをキャプチャすることができるが、好ましくは、取得するデータに関する何らかの選択処理を実行する。その選択処理は、パケットフィルタリングと呼ばれる。パケットフィルタは、入ってくるパケットを操作者により事前決定される基準と比較し、そのパケットが受け入れられるべきか及びリスニングしているアプリケーションに対してコピーされるべきかどうかを決定する。こうして、リスニングしているアプリケーション及びその操作者は、洪水のようなデータに圧倒されることなく、興味のあるネットワークトラフィックのサブセットのみを見るだけで済む。例えば、PACSシステム４４といった特定のホストにより生成されるftpトラフィックのみをキャプチャするように、フィルタを設定することができる。他の例としては、すべてのUDPパケット、又はプロトコルタイプフィールドに特定の値を持ったすべてのIPパケットを受信するよう、パケットフィルタを設定することができる。適切に調整されたパケットフィルタを用いることにより、操作者は特定の障害デバイス又は通信タイプに迅速に焦点を絞ることができる。

監視及び解析パッケージに関して重要な第２の特徴は、キャプチャしたパケットのバッファリングである。パケットが取得されるとき、そのパケットは、受信タイムスタンプ及びパケットサイズといった他の有益な情報と共にバッファに格納される。バッファがあれば、高データレート・ネットワークにおけるパケットが迅速に記憶されることができ、そのバッファが大きければ、解析プログラムといったアプリケーションに転送される前に、かなりの数のパケットが取得されることができる。この目的のために採用されるバッファは、一般に循環型である。即ち、バッファが満杯になる前にデータがバッファから転送されなければならない。さもないと、データが上書きされロストすることになる。

監視及び解析プログラムにおける他の２つの特徴は、特定の場合に有益である場合がある。１つは、ネットワークに対してユーザがrawデータを書き込むことを可能にするのに用いられるパケットインジェクションである。この機能が存在するとき、ユーザは、自身が規定したヘッダを持つカスタマイズされたパケットをネットワークを介して送信することができる。この機能は、特定のネットワーク障害を診断するのに有益である。この機能は、テスト用に高速トラフィックを生成するため、同じパケットが高データレートで繰り返し送信されることを可能にするのにしばしば使われる。後述されるような純粋なリスニング実行時には、パケットインジェクションは使用されない。

監視及び解析パッケージが持つことができる他の特徴は、ネットワーク監視機能である。この機能は、ネットワークトラフィックに関する簡単な統計をプログラムがカプセル化することを可能にする。ネットワークモニタは、パケットフィルタと同じ原理を用いて、ネットワークトラフィックを分類し、測定された分類でのパケット数をカウントすることができる。この情報は、選択された規則的な間隔でユーザに渡される。ネットワークモニタは、例えば、所与の間隔でネットワークを通過するDICOMパケットの数、又は、ネットワークトラフィックにおけるDICOMパケットの割合を決定するのに使用されることができる。

こうして、本発明の通常の監視及び解析プログラムは、ネットワークを通過するrawパケットを、超音波システムから送信されるものも超音波システムで受信されるものもネットワーク上の他のホストにより交換されるものもキャプチャすることができることになる。その超音波システムは、解析アプリケーションにパケットを渡す前に、ユーザが決めたルールに基づきパケットをフィルタリングすることができる。その超音波システムは、オプションで、ネットワークにrawパケットを送信することができる。その超音波システムは、オプションで、ネットワークトラフィックに関する統計情報を集めることができる。

キャプチャされたネットワークデータが解析アプリケーションに転送された後、ネットワーク診断者にとって都合の良い態様でそのデータは表示されなければならない。これは、広範な通信プロトコルの情報を分析し表示する機能をそのアプリケーションに与えることによりなされる。例えばEthereal解析プログラムは、通常使用されるプロトコルを解析することができる。多数の解析アプリケーションが、そのアプリケーション自身のものだけでなく、広く使用されている他の多くの「スニファ」プログラムのキャプチャファイル形式を読み出す機能を備えている。これは、他のキャプチャプログラムにより以前に取得されたデータだけでなく、現在のネットワークデータを読み出す機能を提供する。

モニタを用いる方法の例として、DICOMネットワーク通信障害の解析のためリスニングモードにある解析プログラムが図２のフローチャートにより示される。ステップ５２において、ユーザは超音波システムでネットワーク監視及び解析プログラム３４を起動する。ステップ５４において、プログラムが実行中で、ネットワークトラフィックを監視する状態にあるとき、ユーザは、例えば、通信障害が生じているようなネットワーク上の別のデバイスに対して超音波システムからテストDICOMファイルを送信する。その後ステップ５６において、ネットワーク監視及び解析プログラムは、ネットワークトラフィックを監視する。

図３は、DICOMテストのための図２の送信及び監視ステップを更に詳細に説明する。超音波画像は、ステップ７２に示されるようにそのシステムに固有の画像フォーマットで超音波システムにより取得される。画像は、その固有フォーマットで画像記憶部２６に格納されることができるか、又は格納される前にステップ７４でDICOMフォーマットに変換されることができる。固有のフォーマットストレージが使用されるとき、その画像は、ネットワークを介して格納される前にDICOMフォーマットに変換される。ステップ３６で、DICOM画像は、ネットワークで使用される通信プロトコルのためパケットにフォーマット化され、ネットワークアダプタに結合される。すると、DICOM画像パケットは、ネットワーク４０を介してホストデバイスに送信される。ボックス８０が示すように、DICOM通信ではパケットはTCP/IPプロトコルで送信される。採用される通信は、超音波システムのIPアドレス及び送信ポートからPACSシステム４４のようなホストデバイスのIPアドレス及び受信ポートまでのポイントツーポイント(P2P)である。通信における最初のパケットは、いわゆるアソシエーション及びネゴシエーションとして知られる、デバイス間での基本ハンドシェイク通信を確立するものである。基本ハンドシェイクにより、受信ホストがDICOMデータを処理することができるかどうかを示す通信パラメタ等が確立される。アソシエーション／ネゴシエーションが完了すると、DICOMメッセージサービス要素(DIMSE)が交換される。ここでDIMSEは、一般にDICOM要素を参照する。DIMSEの交換が完了すると、リリース(release)が実行され、DICOMデータの特定の通信が終了する。

図２に戻り、ステップ５８では、例えば、送信元及びホストのIPアドレスでパケットをフィルタリングすることにより、超音波システムとネットワーク上の別のホストデバイスとの間で交換されるパケットがフィルタリングされる。フィルタリングされたパケットデータは、ステップ６０でキャプチャファイルにキャプチャされる。ステップ６０で、ユーザがデータのヘックスダンプを読むことができるよう、キャプチャファイルがユーザに対して表示されることができる。別の変形例は、例えばDICOM通信のみを解析するといった解析プログラムを用いて、選択された情報のみを解析することである。その後、ステップ６６で、ユーザはネットワーク障害を解析することができる。

図４は、本発明の実施形態から得られるネットワークDICOMデータの典型的なキャプチャファイルを表示するビューワの表示画面を表す。ビューワの上窓１０２には、窓の分離ラインで隔てられて、キャプチャされたパケットがそれぞれリスト表示される。パケット情報は、パケットがキャプチャされた相対時間、本実施形態では超音波システムとなる送信元のIPアドレス、及び超音波システムが通信するホストデバイス(送信先)のIPアドレスを含む。プロトコル列は、パケットタイプを示し、最初のパケットだとTCPである。最初のパケットは、表記[SYN,ACK]を含む。その表記は、このパケットが超音波システムとホストデバイスとの間のハンドシェイク(アソシエーション／ネゴシエーション)に関連していることを示す。プロトコルエントリDCMは、このビューワで解析されたDICOMパケットに対する識別子である。窓１０２に示されるパケットシーケンスにおいて、ホストデバイスは正式な(successful)格納要求に応じ、送信元デバイス(超音波システム)にその要求の一部を通知する。その要求に対して、送信元デバイスは応じることも応じないこともできる。

上窓１０２における最下段パケット#21は強調されており、パケット#21の詳細が中窓１０４に表示されることをもたらす。その識別子は、パケット#21がDICOM(DCM)パケットであることを示し、そのパケット詳細は、患者の人口統計情報、イメージングシステムモダリティ、医師、調査日等といったDICOMパケットに予想される詳細を示す。

下窓１０６は、16進数形式で表されたパケットデータを示す。パケットの各バイトは、2桁ずつの16進数字の羅列として表される。16進データは、その最も基本的な機械言語形式でパケットデータを表すものである。

図５は、キャプチャファイルからアソシエーション／ネゴシエーション情報を表示する、本発明の実施形態の別の典型的なビューワを示す。２つの上窓１１２及び１１４は、ハンドシェイクに関する２つのホスト、即ちリクエスタとアクセプタとのIPアドレス及びプロトコル情報を表示する。窓１１６及び１１８は、ハンドシェイクの過程でリクエスタにより要求されたサービスとアクセプタにより受け入れられたサービスとを分離する。このビューワは、前述のビューワより高レベルでのアソシエーション／ネゴシエーション要求に関する情報を与える、DICOMアプリケーション通信における上位層の解析結果の表示を提供するものとして理解される。通信の最後でのリリース要求は、同様なデータを持つことになる。

図６は、DIMSEデータの解析、即ちDICOM通信の実体を示す、本発明の別の実施形態のビューワを示す。ビューワの窓１２２は、DIMSE名を与え、窓１２４は、パケットが送信される時間間隔を与える。窓１２６は、DIMSEの個別の要素をそのDICOMデータタグ及び説明と共に示す。

本発明の原理に基づき構築される超音波診断イメージングシステム及びネットワークをブロック図形式で説明する図である。 本発明によるDICOMネットワーク通信障害の解析のためのフローチャートである。 DICOMファイルの通常のネットワーク転送におけるイベントシーケンスを説明する図である。 ネットワーク上のDICOMパケット・トラフィックのキャプチャを説明する図である。 キャプチャされたアソシエーション／ネゴシエーション・ネットワーク通信を説明する図である。 キャプチャされたDICOMネットワークサービス・エレメントデータを説明する図である。

Claims (19)

1. ネットワーク上の別のデバイスと超音波情報を交換するため、前記ネットワークに接続されることができる超音波診断イメージングシステムであって、
   前記超音波システムに存在するオペレーティングシステムと、
   前記超音波システムを前記ネットワークに接続するのに用いられるネットワークアダプタと、
   raw形式のネットワークパケットデータをキャプチャする、又はネットワークキャプチャファイルを表示するよう、前記オペレーティングシステムにより動作可能であり、かつ前記超音波システムに存在するネットワーク解析アプリケーションとを有する、超音波診断イメージングシステム。
2. 前記ネットワークアダプタがEthernet（登録商標）、FDDI、PPP、トークンリング又はIEEE 802.11ネットワークインタフェースのいずれかを有する、請求項１に記載の超音波診断イメージングシステム。
3. 前記ネットワーク解析アプリケーションが、raw形式のネットワークパケットデータをキャプチャし、及びキャプチャファイルにおける前記キャプチャされたパケットデータをユーザに表示するよう動作可能である、請求項１に記載の超音波診断イメージングシステム。
4. 前記ネットワーク解析アプリケーションが、TCP/IPプロトコルを用いるDICOMパケットデータをキャプチャするよう動作可能である、請求項１に記載の超音波診断イメージングシステム。
5. 前記ネットワーク解析アプリケーションが、DICOMメッセージサービス要素のキャプチャファイルを表示する、請求項４に記載の超音波診断イメージングシステム。
6. 前記DICOMメッセージサービス要素が、DICOM画像ファイルを有する、請求項５に記載の超音波診断イメージングシステム。
7. 前記ネットワーク解析アプリケーションが、DICOM通信を解析する手段を更に有する、請求項５に記載の超音波診断イメージングシステム。
8. 前記ネットワーク解析アプリケーションが、パケットフィルタを含む、請求項１に記載の超音波診断イメージングシステム。
9. 前記ネットワーク解析アプリケーションが、パケットタイムスタンプ及びホストIPアドレス付きのキャプチャファイルを表示する、請求項８に記載の超音波診断イメージングシステム。
10. 前記ネットワーク解析アプリケーションが、キャプチャファイルバッファを更に含む、請求項８に記載の超音波診断イメージングシステム。
11. 超音波診断イメージングシステムに対するネットワーク接続を、該超音波システムから診断する方法において、
    前記超音波システムからネットワーク監視及び解析プログラムを開始するステップと、
    前記超音波システムからネットワーク上のホストデバイスにデータファイルを送信するステップと、
    前記データファイルに関連付けられるネットワークトラフィックを監視するステップと、
    前記監視されるネットワークトラフィックの少なくともサブセットからキャプチャファイルを生成するステップとを有する、方法。
12. 前記送信するステップが、前記超音波システムからネットワーク上のホストデバイスへDICOMファイルを送信するステップを更に有し、
    前記監視するステップは、前記DICOMファイルに関連付けられるネットワークトラフィックを監視するステップを更に有する、請求項１１に記載の方法。
13. 前記監視するステップが、前記ネットワークを通過するraw形式のパケットデータを監視するステップを有する、請求項１１に記載の方法。
14. ユーザが規定する１つ又は複数の特徴に基づき、パケットデータトラフィックをフィルタリングするステップを更に有する、請求項１１に記載の方法。
15. DICOM通信を解析するステップを更に有する、請求項１２に記載の方法。
16. ネットワーク障害を診断する方法において、
    超音波システムのネットワークアダプタをネットワークに接続するステップと、
    前記超音波システムと前記ネットワーク上の少なくとも１つのデバイスとの間の通信障害が存在するかを決定するステップと、
    前記超音波システムが前記ネットワークに接続されている間、前記超音波システムでネットワークトラフィックのキャプチャファイルを取得するステップと、
    前記通信障害を解決するため前記キャプチャファイルを解析するステップとを有する、方法。
17. 前記ネットワークトラフィックをパケットフィルタでフィルタリングするステップを更に有する、請求項１６に記載の方法。
18. 前記超音波システムから前記ネットワーク上の別のデバイスにパケットを送信するステップを更に有する、請求項１６に記載の方法。
19. 前記パケットを送信するステップが、DIMSE要素のパケットを送信するステップを更に有し、
    前記DIMSE要素パケットの送信ステップの間及び該送信ステップの後、前記キャプチャファイルが取得される、請求項１８に記載の方法。

Images