ＰＡＣＳ最適化技法
【課題】医用画像を効率的に転送するための方法およびシステムを提供すること。
【解決手段】画像保管通信システム(PACS)の第１のプラットフォーム依存フォーマットで医用画像を受け取る。第１のプラットフォーム依存フォーマットは、第１フォーマットをどのように復号すべきかを規定するライブラリを含む、第１フォーマットに準拠したデバイスによってアクセス可能なフォーマットである。医用画像を第１フォーマットから第２フォーマットに変換する。第２フォーマットは、第１フォーマットに準拠していないデバイス上で見ることができる、第１フォーマットを復号した内容を含む。その後、変換された画像は、表示するためにデバイスに渡される。1つまたは複数のデバイスの画像設定を識別し、要求デバイスの画像設定に従って画像をサイズ変更することによって最適化された要求画像を渡すことによって、医用画像を効率的に転送する。
【解決手段】画像保管通信システム(PACS)の第１のプラットフォーム依存フォーマットで医用画像を受け取る。第１のプラットフォーム依存フォーマットは、第１フォーマットをどのように復号すべきかを規定するライブラリを含む、第１フォーマットに準拠したデバイスによってアクセス可能なフォーマットである。医用画像を第１フォーマットから第２フォーマットに変換する。第２フォーマットは、第１フォーマットに準拠していないデバイス上で見ることができる、第１フォーマットを復号した内容を含む。その後、変換された画像は、表示するためにデバイスに渡される。1つまたは複数のデバイスの画像設定を識別し、要求デバイスの画像設定に従って画像をサイズ変更することによって最適化された要求画像を渡すことによって、医用画像を効率的に転送する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、保健医療の分野に関し、より具体的には、医用画像を画像ストアから1つまたは複数のデバイスに効率的に転送するための方法およびシステムに関する。
【背景技術】
【０００２】
保健医療の質は、絶え間なく進化し、改善し続けている。これらの改善は、しばしばより優れた医療技術および医療行為を含むが、患者データ管理の改善を含むこともある。患者データをより良く獲得し、管理し、流布させることによって、保健医療提供者は、平凡なデータ入力およびデータ獲得の仕事から自らを解放することができる。これらの仕事は、それが省ければ医療の提供に割り振ることのできる時間を浪費することがあり得る。
【０００３】
現在、多くの病院は、患者データをデジタル的に獲得し、保存している。患者データをデジタル的に保存することによって、保健医療提供者は、いつでも病院内のいかなる場所からでも、迅速に患者データを検索し、アクセスする能力を有する。しかし、デジタル患者データへの移行は、いくつかのデータ互換性問題を引き起こす。第１フォーマットまたはデバイスを使用して入力されたデータは、第２フォーマットまたはデバイスを使用して入力されたデータと必ずしも互換性があるとは限らない。このようなことは、異なる製造業者が、病院内での専門目的のために異なる画像処理デバイスを作成し、各デバイスが、しばしば独自仕様の異なるインタフェースおよび異なるファイルフォーマットを有する場合にしばしば起きていた。その結果、デジタルデータの相互運用性を保証するための規格が制定された。
【０００４】
医用デジタル画像処理および通信(DICOM: Digital Imaging and Communications in Medicine)は、デジタル医用画像処理のために制定されたそのような規格の1つである。DICOM互換デバイスまたはアプリケーションは、任意のDICOM互換画像を生成、作成、表示、送信、問い合わせ、保存、処理、検索、または印刷できることを保証される。現在、DICOMは、放射線医学、心臓病学、腫瘍学、歯科学、外科学、神経学、マンモグラフィ、放射線治療学、眼科学、整形外科学、小児科学、病理学、獣医学などにおける画像処理に使用されている。そのようなわけで、現在、DICOMは、病院または他の保健医療環境において画像を保存、検索、配布、および提示するための中央画像ストアを提供する、画像保管通信システム(PACS: Picture Archiving and Communication Systems)を実施するための好ましい規格である。これはさらに、DICOM準拠デバイスを購入することによって、病院が、そのようなデバイスを病院情報システム(HIS: Hospital Information System)にシームレスに統合することができ、デバイスにPACS内の任意の画像を表示させ、アクセスさせることができることを保証する。
【０００５】
DICOM規格は、HIS内の様々なデバイスの相互互換性および相互運用性を保証するために準拠しなければならない特定のファイルフォーマット定義を規定する。加えて、DICOMは、これらの医用画像の伝送および流布のためのネットワーク通信プロトコルを規定する。したがって、DICOM規格と互換性のあるデバイスは、専門デバイスである。そのような互換デバイスは、ファイルフォーマットを解析および処理するため、または通信プロトコルを使用して通信(例えば送信および受信)するために、必然的に1つまたは複数のライブラリを含む。
【０００６】
これらのライブラリおよびプロトコルを必要とすることによって、DICOM規格は、保健医療環境内で普通に使用されている多くのデバイスが、デジタル医用画像にアクセスできないようにする。例えば、ワイヤレス通信を行い、低解像度または高解像度画像を表示できる、スマートフォン、セルラ電話、または携帯情報端末(PDA)の多くは、DICOMフォーマット画像を処理することができない。場合によっては、これらのデバイスは、必要なDICOM機能(例えばライブラリ)を含むことによって互換性をもつようにすることができるが、それには、増大するメモリ、処理、および最終コストという犠牲が伴い、それらのために、そのような機能は実用にならないことがあり得る。代わりに、病院は、DICOM規格を使用して動作するPACSから得ることができる便益を十分に実現するために、専門ハードウェアおよび独自仕様ソフトウェアに投資しなければならない。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
したがって、DICOMによって提供される相互運用性を維持しながら、DICOM規格に準拠することに関連するオーバヘッドを低減することが、当技術分野において必要とされている。例えば、DICOM機能の欠如に関わらず、より多くの従来デバイス(例えば、スマートフォン、セルラ電話、PDAなど)を互換PACS表示プラットフォームとして利用可能にすることが必要とされている。言い換えると、これらのデバイスに変更を施す必要なしに、これらのデバイスが、DICOMフォーマット画像を送信、受信、および表示することを可能にし、それによって、保健医療提供者が負担するコストを削減することが必要とされている。
【課題を解決するための手段】
【０００８】
いくつかの実施形態は、画像保管通信システム(PACS)などの画像データベースから1つまたは複数の異なる表示デバイスに医用画像を効率的に転送するための方法およびシステムを提供する。いくつかの実施形態は、画像をクライアントデバイスに転送する前に、クライアントデバイスの仕様に基づいて画像を最適化することによって、画像の効率的な転送を実行する。いくつかの実施形態は、画像がPACSに保存されるときに画像を事前処理することによって、画像を最適化する。いくつかの実施形態は、画像がクライアントデバイスによって要求され、クライアントデバイスに送信されるときに、オンデマンドで画像を最適化する。
【０００９】
いくつかの実施形態は、専門または独自仕様デバイス上でだけ見ることができるプラットフォーム依存画像ファイルを、1つまたは複数の異なるクライアントデバイスの任意の標準的な画像表示アプリケーションによって見ることができるプラットフォーム独立画像ファイルに変換することによって、画像を最適化する。いくつかのそのような実施形態では、PACSは、プラットフォーム依存フォーマットで医用画像を保存する。プラットフォーム依存フォーマットは、画像を復号および処理するために専門ライブラリを有するようクライアントデバイスに要求する。これらの専門ライブラリは、クライアントデバイス上に存在しなければならない。加えて、これらのライブラリは、クライアントデバイスがフォーマットを復号し、見ることのできる画像を作成するために、クライアントデバイスにおいて行われる付加的な計算を必要とする。
【００１０】
いくつかの実施形態は、表示するために画像をデバイスに転送する前に、保存画像のプラットフォーム依存ファイルフォーマットをプラットフォーム独立ファイルフォーマットに変更することによって、PACS内に保存された画像を多数の異なる受信デバイス上に表示するために最適化する。このようにして、いくつかの実施形態は、プラットフォーム依存ファイルフォーマットの独自仕様の復号に必要とされる処理要件をクライアント表示デバイスから取り除く。さらに、クライアント表示デバイスは、復号機能を実行するための対応するライブラリを保存しなくても、医用画像を表示することができる。したがって、いくつかの実施形態は、最低限の処理リソースまたはメモリリソースを有するにすぎない表示デバイスを使用して医用画像を表示できるように、表示デバイスのメモリ要件も軽減する。例えば、表示デバイスは、何らかの基本的な画像再生機能を有する、ポケットPC、スマートフォン、セルラ電話、または携帯情報端末(PDA)を含むことができる。
【００１１】
いくつかの実施形態は、プラットフォーム独立ファイルフォーマットとして拡張マークアップ言語(XML)フォーマットヘッダを生成する。いくつかの実施形態では、生成されたXMLヘッダは、プラットフォーム依存ファイルフォーマットに代わって使用される。XMLは、多数の異なるコンピューティングプラットフォーム(例えば、Microsoft Windows(登録商標)およびApple Mac OS(登録商標))上で実行可能なプラットフォーム独立ファイルフォーマットの一例であり、現在、XMLフォーマットを復号および処理するために独自仕様のまたは使用許諾された復号ライブラリを必要としないいくつかのアプリケーションが存在する。いくつかの実施形態が、XMLファイルフォーマットに加えてまたは代わって、任意の数のプラットフォーム独立ファイルフォーマットを使用することは当業者には明らかであろう。プラットフォーム依存ファイルフォーマットは、医用デジタル画像処理および通信(DICOM)フォーマットなど、任意の数の独自仕様フォーマットを含むことができ、DICOMは、最初に画像を転送し、PACS内に画像を保存するために使用される。画像最適化を施してプラットフォーム独立ファイルフォーマットにしない場合、DICOMフォーマットは、DICOMフォーマットを復号するための専門ライブラリを表示デバイス上に必要とする。多くの場合、これらの専門ライブラリの使用は、使用許諾コストを招く。さらに、ライブラリは、プラットフォーム固有であるので、多くの一般に利用可能なクライアントデバイスのソフトウェアまたはハードウェアと互換性がないことがある。例えば、今日のスマートフォンのいくつかは、現在のところ、Microsoft Windows(登録商標) Mobileオペレーティングシステムを用いて動作するが、他のスマートフォンは、Palm(登録商標)オペレーティングシステムまたはSymbian(登録商標)オペレーティングシステムを用いて動作し、そのような各オペレーティングシステムは、異なる独自仕様の復号ライブラリを必要とする。
【００１２】
加えて、いくつかの実施形態は、プラットフォーム独立フォーマットを使用して、PACSの画像に対する強力な問い合わせを実施する。プラットフォーム独立フォーマットは、XMLタグを個別にまたは一緒に使用して任意の数のカスタマイズ可能なクエリを指定することができるので、より大きな柔軟性を可能にする。これは、さもなければプラットフォーム依存フォーマットのもとでは無効なクエリを使用して画像を検索する能力をユーザに与える。
【００１３】
いくつかの実施形態は、クライアント表示デバイスの画像表示設定に従って画像データをサイズ変更することによって、画像最適化および効率的な画像転送を実行する。具体的には、デバイスの画像設定まで画像をダウンサンプリングすることによって、いくつかの実施形態は、医用画像の品質を低下させることなく、表示デバイスに転送される医用画像の画像データを縮小する。例えば、1600×1200の解像度を有する元の画像は、対応する320×240の解像度を有する表示デバイスに転送する前に、320×240の解像度にサイズ変更される。このようにして、画像は、より迅速に、より短い待ち時間で、画像ストアから表示デバイスに転送される。いくつかの実施形態は、画像がPACSに最初に保存されるときもしくは更新されるときの事前処理において、またはユーザが画像を要求したときにオンデマンドで、この最適化を実行する。
【００１４】
事前処理またはオンデマンド処理の最中に、いくつかの実施形態は、異なる画像設定の組に対してサイズ変更された画像の組を生成する。各サイズ変更画像は、対応する表示設定を有するデバイスを使用して表示されたときに画像品質を損なうことのない縮小画像データの組を有する。表示デバイスの画像設定を識別することによって、いくつかの実施形態は、識別された表示設定に対応するサイズ変更画像だけを転送し、したがって、不要な画像データの転送を回避する。
【００１５】
いくつかの実施形態は、転送される画像ファイルを圧縮することによって、画像転送を最適化する。これは、表示デバイスに転送される画像データの量を削減するための付加的な手段を提供する。いくつかの実施形態は、画像のより効率的な転送を達成するために、サイズ変更画像データ、変更されたヘッダ、元の画像データ、元のヘッダ、またはヘッダと画像データの何らかの組み合わせを圧縮する。
【００１６】
いくつかの実施形態が、上述の技法の1つまたは複数を個別にまたは互いに組み合わせて使用して画像を最適化することは当業者には明らかであろう。そのようなわけで、いくつかの実施形態は、最適化の所望のレベルに応じて、異なるレベルの最適化を達成する。
【００１７】
本発明の新規な特徴は、添付の特許請求の範囲において説明される。しかし、説明の目的で、本発明のいくつかの実施形態が、以下の図において説明される。
【図面の簡単な説明】
【００１８】
【図１】いくつかの実施形態による、医用画像のプラットフォーム依存ファイルフォーマットの、プラットフォーム独立ファイルフォーマットへの変換を概念的に示す図である。
【図２】いくつかの実施形態の画像最適化モジュール250によって実行される画像のサイズ変更を示す図である。
【図３】画像がPACS内に保存されるときに画像を事前処理する統合画像最適化モジュールを有するHISの例示的なアーキテクチャを示す図である。
【図４】いくつかの実施形態による、画像最適化モジュールからクライアント要求画像を取り出すためにMedServerによって処理されるスクリプトの例示的な機能を提示する図である。
【図５】いくつかの実施形態による、画像最適化モジュールからクライアント要求画像を取り出すためにMedServerによって処理されるスクリプトの例示的な機能を提示する図である。
【図６】いくつかの実施形態の画像最適化モジュールの様々なコンポーネントのうちのいくつかを示す図である。
【図７】いくつかの実施形態による、最適化エンジンの最適化モジュールによって実行されるプロセスを提示する図である。
【図８】いくつかの実施形態による、ディスクマネージャを概念的に示す図である。
【図９】いくつかの実施形態による、クライアントデバイスへの効率的な転送のために画像を最適化するための事前処理プロセスを提示する図である。
【図１０】本発明のいくつかの実施形態による、XMLフォーマットヘッダに変換されたDICOMフォーマットヘッダの内容を示す図である。
【図１１】DICOMフォーマットヘッダをXMLフォーマットヘッダに変換するための疑似コードを示す図である。
【図１２】画像を最適化して画像をクライアントデバイスに効率的に転送するために、いくつかの実施形態の画像最適化モジュールによって実行されるプロセスを提示する図である。
【図１３】事前処理された最適化画像をHISからクライアントデバイスに転送するためのデータフローを概念的に示す図である。
【図１４】オンデマンドで最適化された画像をHISからクライアントデバイスに転送するためのデータフローを概念的に示す図である。
【図１５】本発明のいくつかの実施形態がそれを用いて実施されるコンピュータシステムを概念的に示す図である。
【発明を実施するための形態】
【００１９】
本発明の以下の詳細な説明において、本発明の多くの詳細、例、および実施形態が叙述され、説明される。しかし、本発明が叙述される実施形態に限定されないこと、また本発明が説明された特定の詳細および例のいくつかを省いても実施できることは当業者には明瞭かつ明白であろう。
【００２０】
I.概要
いくつかの実施形態は、画像保管通信システム(PACS)などの画像データベースから1つまたは複数の異なる表示デバイスに医用画像を効率的に転送するための方法およびシステムを提供する。いくつかの実施形態は、画像をクライアントデバイスに転送する前に、クライアントデバイスの仕様に基づいて画像を最適化することによって、画像の効率的な転送を実行する。いくつかの実施形態は、画像がPACSに保存されるときに画像を事前処理することによって、画像を最適化する。いくつかの実施形態は、画像がクライアントデバイスによって要求され、クライアントデバイスに送信されるときに、オンデマンドで画像を最適化する。
【００２１】
いくつかの実施形態は、専門または独自仕様デバイス上でだけ見ることができるプラットフォーム依存画像ファイルを、1つまたは複数の異なるクライアントデバイスの任意の標準的な画像表示アプリケーションによって見ることができるプラットフォーム独立画像ファイルに変換することによって、画像を最適化する。いくつかのそのような実施形態では、PACSは、プラットフォーム依存フォーマットで医用画像を保存する。プラットフォーム依存フォーマットは、画像を復号および処理するために専門ライブラリを有するようクライアントデバイスに要求する。これらの専門ライブラリは、クライアントデバイス上に存在しなければならない。加えて、これらのライブラリは、クライアントデバイスがフォーマットを復号し、見ることのできる画像を作成するために、クライアントデバイスにおいて行われる付加的な計算を必要とする。
【００２２】
いくつかの実施形態は、表示するために画像をデバイスに転送する前に、保存画像のプラットフォーム依存ファイルフォーマットをプラットフォーム独立ファイルフォーマットに変更することによって、PACS内に保存された画像を多数の異なる受信デバイス上に表示するために最適化する。このようにして、いくつかの実施形態は、プラットフォーム依存ファイルフォーマットの独自仕様の復号に必要とされる処理要件をクライアント表示デバイスから取り除く。さらに、クライアント表示デバイスは、復号機能を実行するための対応するライブラリを保存しなくても、医用画像を表示することができる。したがって、いくつかの実施形態は、最低限の処理リソースまたはメモリリソースを有するにすぎない表示デバイスを使用して医用画像を表示できるように、表示デバイスのメモリ要件も軽減する。例えば、表示デバイスは、何らかの基本的な画像再生機能を有する、ポケットPC、スマートフォン、セルラ電話、または携帯情報端末(PDA)を含むことができる。
【００２３】
いくつかの実施形態は、プラットフォーム独立ファイルフォーマットとして拡張マークアップ言語(XML)フォーマットヘッダを生成する。いくつかの実施形態では、生成されたXMLヘッダは、プラットフォーム依存ファイルフォーマットに代わって使用される。XMLは、多数の異なるコンピューティングプラットフォーム(例えば、Microsoft Windows(登録商標)およびApple Mac OS(登録商標))上で実行可能なプラットフォーム独立ファイルフォーマットの一例であり、現在、XMLフォーマットを復号および処理するために独自仕様のまたは使用許諾された復号ライブラリを必要としないいくつかのアプリケーションが存在する。いくつかの実施形態が、XMLファイルフォーマットに加えてまたは代わって、任意の数のプラットフォーム独立ファイルフォーマットを使用することは当業者には明らかであろう。プラットフォーム依存ファイルフォーマットは、医用デジタル画像処理および通信(DICOM)フォーマットなど、任意の数の独自仕様フォーマットを含むことができ、DICOMは、最初に画像を転送し、PACS内に画像を保存するために使用される。画像最適化を施してプラットフォーム独立ファイルフォーマットにしない場合、DICOMフォーマットは、DICOMフォーマットを復号するための専門ライブラリを表示デバイス上に必要とする。
【００２４】
加えて、いくつかの実施形態は、プラットフォーム独立フォーマットを使用して、PACSの画像に対する強力な問い合わせを実施する。プラットフォーム独立フォーマットは、XMLタグを個別にまたは一緒に使用して任意の数のカスタマイズ可能な問い合わせを指定することができるので、より大きな柔軟性を可能にする。多くの場合、これらの専門ライブラリの使用は、使用許諾コストを招く。さらに、ライブラリはプラットフォーム固有であるので、ライブラリは、多くの一般に利用可能なクライアントデバイスのソフトウェアまたはハードウェアと互換性がないことがある。例えば、今日のスマートフォンのいくつかは、現在のところ、Microsoft Windows(登録商標) Mobileオペレーティングシステムを用いて動作するが、他のスマートフォンは、Palm(登録商標)オペレーティングシステムまたはSymbian(登録商標)オペレーティングシステムを用いて動作し、そのような各オペレーティングシステムは、異なる独自仕様の復号ライブラリを必要とする。
【００２５】
図1は、いくつかの実施形態による、医用画像のプラットフォーム依存ファイルフォーマットの、プラットフォーム独立ファイルフォーマットへの変換を概念的に示している。この図は、DICOM準拠クライアント120と、DICOM非準拠クライアント110と、いくつかの実施形態の画像最適化モジュール130と、PACS 140とを含む。
【００２６】
この図では、PACS 140は、DICOMファイルフォーマットを使用して医用画像を保存する。したがって、各画像は、DICOMフォーマットヘッダ150を含む。クライアント120などのDICOM準拠クライアントだけが、PACS 140の医用画像に直接アクセスし、それを復号し、表示することができる。DICOM準拠クライアント120は、デバイスがDICOMファイルフォーマットを認識および復号することを可能にするのに必要なDICOMライブラリを内部的に保存している。したがって、クライアント120は、1つまたは複数のDICOMライブラリを保存するために、そのメモリリソースの一部を割り当てる。多くの場合、そのような独自仕様フォーマットに関連する復号は、プラットフォーム独立ファイルフォーマットの復号よりも大きな計算オーバヘッドを有する。
【００２７】
いくつかの実施形態の画像最適化モジュール130を利用することによって、保健医療の専門家によって普通に使用される多くのデバイスは、DICOM非準拠であっても、DICOMフォーマット画像ファイルにアクセスし、それを表示できるようにすることができる。図示されるように、いくつかの実施形態の画像最適化モジュール130は、画像をDICOM非準拠クライアント110に転送する前に、DICOMフォーマットヘッダ150をXMLフォーマットヘッダ160に変換する。XMLはプラットフォーム独立フォーマットであるので、クライアント110は、任意の従来の画像表示アプリケーションを使用して、画像内容を記述するXMLヘッダ160とともに渡された画像データを解析し、表示することができる。例えば、クライアント110は、画像再生機能を有するXML対応のウェブブラウザを、画像表示アプリケーションとして使用することができる。
【００２８】
反対に、クライアント120は、PACS 140の画像150に直接アクセスする。そのようなわけで、クライアント120がPACS 140から受け取る画像は、DICOMフォーマットヘッダを含む。したがって、画像データを表示するために、クライアント120は最初に、DICOMライブラリを使用して独自仕様のDICOMヘッダを復号する。DICOMライブラリは、クライアント120上にローカルに保存される。DICOMライブラリは、クライアントがDICOMフォーマットを認識および処理することを可能にする。しかし、別の方式ではいくつかの実施形態の画像最適化モジュール130によって実行できたそのような処理は、クライアント120の追加的な計算リソースを必要とする。さらに、DICOMライブラリはしばしば、クライアント120のユーザにDICOMライブラリの使用権に対する使用許諾料の支払いを要求する独自仕様のライブラリである。
【００２９】
いくつかの実施形態は、クライアント表示デバイスの画像表示設定に従って画像データをサイズ変更することによって、画像最適化および効率的な画像転送を実行する。具体的には、デバイスの画像設定まで画像をダウンサンプリングすることによって、いくつかの実施形態は、医用画像の品質を低下させることなく、表示デバイスに転送される医用画像の画像データを縮小する。このようにして、画像は、より迅速に、より短い待ち時間で、画像ストアから表示デバイスに転送される。いくつかの実施形態は、画像がPACSに最初に保存されるときもしくは更新されるときの事前処理において、またはユーザが画像を要求したときにオンデマンドで、この最適化を実行する。
【００３０】
事前処理またはオンデマンド処理の最中に、いくつかの実施形態は、異なる画像設定の組に対してサイズ変更された画像の組を生成する。各サイズ変更画像は、対応する表示設定を有するデバイスを使用して表示されたときに画像品質を損なうことのない縮小画像データの組を有する。表示デバイスの画像設定を識別することによって、いくつかの実施形態は、識別された表示設定に対応するサイズ変更画像だけを転送し、したがって、不要な画像データの転送を回避する。
【００３１】
図2は、いくつかの実施形態の画像最適化モジュール250によって実行される画像のサイズ変更を示している。図は、いくつかのクライアント表示デバイス210〜240と、いくつかの実施形態の画像最適化モジュール250と、PACS 260とを含む。PACS 260は、クライアントデバイス210〜240によって要求される元の画像270を保存する。
【００３２】
画像最適化モジュール250は、元の画像270から多数の異なるサイズ変更画像280〜290を生成する。サイズ変更画像の各々は、クライアントデバイスの画像表示設定に基づいて、特定のクライアントデバイス上に表示するために最適化される。いくつかの実施形態では、画像最適化モジュール250は、保存するために画像が最初にPACS 260に送られるときの事前処理の最中に、サイズ変更画像を生成する。いくつかの実施形態では、画像最適化モジュール250は、各デバイス210〜230がPACS 260に画像を要求したときにオンデマンドで、サイズ変更画像を生成する。
【００３３】
この図では、クライアントデバイス210〜240は、異なる画像表示設定を有する。例えば、クライアント210は、大きなデスクトップ表示モニタを有するデスクトップコンピュータである。クライアント210は、ラップトップコンピューティングデバイス230の画面と比べて、より高い表示解像度を有し、PDAまたはスマートフォン220と比べた場合は、さらに高い表示解像度を有する。したがって、元の画像270が2560×1980ピクセルの表示解像度を有し、コンピュータ210のディスプレイが1280×960ピクセルの表示解像度を有すると仮定すると、画像最適化モジュール250は、クライアント210上に表示するために画像270を最適化する。具体的には、画像最適化モジュール250は、非本質的なピクセル情報がクライアント210に渡されないように、画像270をデバイス210の1280×960表示解像度までダウンサンプリングする。図示されるように、画像最適化モジュール250は、元の画像270の代わりに、最適化画像280をクライアントデバイス210に渡し、最適化画像280は、元の画像270よりもわずかなピクセルデータを含む。
【００３４】
同様に、PDA 220が176×144ピクセルの表示解像度を有すると仮定すると、画像をクライアント220上に表示したときに画像品質を低下させることなく、2560×1980ピクセルデータのうちの多くが、いくつかの実施形態の画像最適化モジュール250によって削除される。この場合、画像最適化モジュール250からデバイス220に渡されるサイズ変更画像285は、わずか176×144の表示解像度を有するようにダウンサンプリングされる。この非本質的なピクセルデータを削除することによって、必要な量のデータしか渡されないので、いくつかの実施形態は、PACS 260からクライアントに画像を転送するための時間を短縮し、クライアント上で実行される処理を減少させる。いくつかの実施形態の画像最適化モジュール250が、最適化画像内に付加的なピクセルデータを含むことは当業者には明らかであろう。付加的なピクセルデータは、ユーザが画像をズームして特定の領域をより詳細に見ることを可能にする。しかし、そのような付加的なピクセルデータは、元の画像のピクセルデータの量よりもわずかであり、したがって、元の画像を転送するときよりも効率的にクライアントデバイスに転送される最適化画像をもたらす。
【００３５】
図2はまた、PACS 260から画像を直接取り出すクライアント240を示している。これらの画像は、クライアント240の画像設定向けに最適化されていない。そのようなわけで、非本質的な画像データが、クライアント240に転送される。例えば、元の画像270が2560×1980ピクセルの解像度を有し、クライアントデバイスが1280×960ピクセル解像度しか有さない場合、クライアント240は、必要とされるよりも2倍も多くのデータ(縮小画像用の1280×960ピクセルの代わりに、元の画像の2560×1980ピクセル)を受け取る。さらに、その場合、1280×960ピクセルディスプレイに適合するように適切にサイズ変更するための処理負担は、デバイス240が担わされる。
【００３６】
いくつかの実施形態は、転送される画像ファイルを圧縮することによって、画像転送を最適化する。これは、表示デバイスに転送される画像データの量を削減するための付加的な手段を提供する。いくつかの実施形態は、画像のより効率的な転送を達成するために、サイズ変更画像データ、変更されたヘッダ、元の画像データ、元のヘッダ、またはヘッダと画像データの何らかの組み合わせを圧縮する。
【００３７】
いくつかの実施形態が、上述の技法の1つまたは複数を個別にまたは互いに組み合わせて使用して画像を最適化することは当業者には明らかであろう。そのようなわけで、異なるレベルの最適化を達成することができる。
【００３８】
本発明のいくつかのより詳細な実施形態が、以下のセクションで説明される。具体的には、セクションIIは、効率的な画像転送方法を実施するための、いくつかの実施形態による環境を説明する。セクションIIIは、画像の効率的な転送を促進するための、画像ヘッダの事前処理およびオンデマンド処理のいくつかの例を提供する。次に、セクションIVは、画像の効率的な転送を促進するための、画像データの事前処理およびオンデマンド処理のいくつかの例を提供する。最後に、セクションVは、本発明のいくつかの実施形態がそれを用いて実施されるコンピュータシステムについての説明を提供する。
【００３９】
II.システムアーキテクチャ
画像を効率的に転送するための様々な画像最適化機能を実行するいくつかの実施形態の画像最適化モジュールは、病院情報システム(HIS)のコンポーネントとして既存のHISに統合される。いくつかの実施形態では、画像最適化モジュールは、HIS内の既存のコンポーネントに対する変更をわずかしかまたは全く必要としない仕方で、HISにシームレスに統合される。例えば、HISのPACSは、画像最適化モジュールが、PACSに保存され、PACSから取り出される画像を最適化する場合も、画像データベースとして動作し続ける。
【００４０】
図3は、いくつかの実施形態による、統合画像最適化モジュールを有するHISの例示的なアーキテクチャを示している。図示されるように、HIS 310は、MedServer 330と、PACSウェブサーバ340と、クエリオブジェクト350と、PACS 360と、いくつかの実施形態の画像最適化モジュール370とを含む。HIS 310は、PACS 360に投入される画像を獲得するために1つまたは複数の画像獲得デバイス320と、また表示用の画像を取り出すためにPACS 360にアクセスするクライアントデバイス325とインタフェースをとる。
【００４１】
画像獲得デバイス320は、病院の様々な病棟または部署内で使用される病院撮像デバイス(例えば、磁気共鳴映像法(MRI: Magnetic Resonance Imaging)デバイス、コンピュータ体軸断層撮影法(CAT: Computerized Axial Tomography)スキャンデバイスなど)を含む。これら様々な病棟または部署のいくつかの例は、放射線科、心臓病科、腫瘍科、歯科、外科、神経科、マンモグラフィ科、放射線治療科、眼科、整形外科、小児科、病理学科、獣医科を含む。画像獲得デバイス320は、単一のファイルフォーマットおよびネットワークプロトコル規格を使用して動作するように構成される。以下の説明は、HISを実施するのに選ばれた規格として、DICOM規格を使用する。しかし、任意のそのようなファイルフォーマットおよびネットワークプロトコル規格が、本明細書で説明される実施形態とともに使用できることは当業者には明らかであろう。したがって、デバイス320は、画像を生成してPACS 360に送る場合、画像をMedServer 330に転送する前に、DICOMファイルフォーマットに従って画像をフォーマットする。
【００４２】
MedServer 330は、いくつかの例のように、画像獲得デバイス320、クライアントデバイス325と、PACS 360および画像最適化モジュール370などのHISのバックエンドコンポーネントとの間のインタフェースを提供するHIS内のプライマリサーバである。いくつかの実施形態では、MedServer 330は、画像獲得デバイス320およびクライアントデバイス325に対する認証および/または権限付与機能を実行する。いくつかの実施形態では、MedServer 330は、画像獲得デバイス320、クライアントデバイス325、およびHISのバックエンドコンポーネントに対して、データを要求し、組織し、送信する。
【００４３】
具体的には、MedServer 330は、HIS 310に入ってくる様々なデータおよび要求を、HIS 310の適切なデータベース、データストレージ、または計算ユニットに回送する。例えば、MedServer 330は、新たに生成された画像を画像獲得デバイス320から受け取ったとき、その画像をPACS 360内に保存される新たに生成された画像として識別する。したがって、MedServer 330は、その画像を、PACS 360へのコンタクトポイントに相当するPACSウェブサーバ340またはクエリオブジェクト350に回送する。
【００４４】
いくつかの実施形態では、MedServer 330は、MedServer 330の機能を実施する様々なスクリプトを含む。例えば、MedServer 330は、PACS 360へのウェブベースのインタフェースを提供するPACSウェブサーバ340とインタフェースをとるための、ハイパーテキスト転送プロトコル(HTTP: Hyper Text Transfer Protocol)ベースのスクリプトを含む。MedServer 330は、PACS 360へのCOMインタフェースを提供するクエリオブジェクト350とインタフェースをとるための、コンポーネントオブジェクトモデル(COM: Component Object Model)ベースのスクリプトも含むことができる。クライアント325に渡す画像を圧縮するため、クライアント認証を実行するため、クライアント権限付与を実行するためなどに、他のスクリプトを実施することもできる。
【００４５】
1つまたは複数のそのようなスクリプトを変更することによって、画像最適化モジュール370をHISにシームレスに統合することができる。例えば、MedServer 330が、PACS 360内に保存される新たに生成された画像を画像獲得デバイス320から受け取る場合、保存するために画像がPACS 360に渡され、最適化のために画像最適化モジュール370にも渡されるように、MedServer 330の画像保存スクリプトを変更することができる。
【００４６】
同様に、MedServer 330が、画像を取り出すよう求める要求をクライアントから受け取る場合、最初に画像最適化モジュール370に問い合わせを行うように、MedServer 330の画像検索スクリプトを変更することができる。画像最適化モジュール370が、要求された画像を事前処理して、その最適化バージョンを生成してある場合、画像最適化モジュール370は、最適化画像をMedServer 330に返す。その後、画像検索スクリプトは、PACS 360に問い合わせを行うことなく、要求を発行したクライアントに最適化画像を返す。
【００４７】
事前処理画像が存在しない場合、画像最適化モジュール370は、要求された画像が事前処理されていないことをMedServer 330に通知する。いくつかの実施形態では、画像がPACS 360に最近入力された場合、または画像最適化モジュール370が最適化画像を生成していない画像設定を要求クライアントが有する場合に、事前処理画像が存在しないことがある。その場合、画像検索スクリプトは、使用されるPACSコンタクト(例えば、PACSウェブサーバ340またはクエリオブジェクト350)を決定する処理スレッドをMedServer 330において生成する。MedServer 330は、元の画像を取り出すためにPACS 360に問い合わせを行う。その後、元の画像は、以下のセクションで説明されるように、画像最適化モジュール370によってオンデマンドで最適化され、データベース380内に保存される。いくつかの実施形態では、画像検索スクリプトは、監視スレッドも生成する。監視スレッドは、要求された画像の最適化バージョンが利用可能になった時を決定するために、画像最適化モジュール370のデータベース380を継続的にチェックする。
【００４８】
監視スレッドが動作している間、PACS 360は、プラットフォーム依存フォーマットを含み、要求クライアントデバイス向けに最適化されていない元の画像を取り出す。元の画像は、画像が画像最適化モジュール370によってあらかじめ事前処理されているかどうかに関わりなく、最適化画像から得られる効率性の利益が実現され得るように、クライアント325またはMedServer 330に渡される前に、画像最適化モジュール370によってオンデマンドで処理される。画像最適化モジュール370は、1つまたは複数の画像最適化技法の実行を完了すると、最適化画像を用いてデータベース380を更新する。その後、MedServer 330の監視スレッドは、データベース380内の最適化画像を識別する。監視スレッドは、最適化画像を取り出し、最適化画像を要求クライアント325に転送する。
【００４９】
図4および図5は、いくつかの実施形態による、画像最適化モジュール370からクライアント要求画像を取り出すためにMedServer 330によって処理されるスクリプトの例示的な機能を提示している。具体的には、図4は、単一の画像スタディ(image study)を取り出すための機能を提示しており、一方、図5は、多数の画像を含むスタディリストを取り出すための機能を提示している。機能の各々は、DICOMクエリを発行するためのオブジェクト410または510を初期化する。機能の各々は、DICOMクエリの結果を取り出すためのXMLオブジェクト420または520も初期化する。XMLオブジェクトは、プラットフォーム独立フォーマットのクエリ結果を含む。
【００５０】
図3に示されたアーキテクチャが、HISにおいて本発明のいくつかの実施形態を実施するのに必要とされるコンポーネントの最低限の組を詳述したものであることは当業者には明らかであろう。したがって、HISは、図3に示されたものに加えて、追加的なコンポーネントを含むことができる。同様に、いくつかの実施形態の画像最適化モジュールは、様々な事前処理および最適化機能を実施するためのいくつかのコンポーネントを含む。
【００５１】
図6は、いくつかの実施形態の画像最適化モジュール610の様々なコンポーネントのうちのいくつかを示している。画像最適化モジュール610は、ファイルストア620と、最適化エンジン630と、1組のメッセージング待ち行列650と、ディスクマネージャ660と、1組のデータベース670とを含む。
【００５２】
ファイルストア620は、1組のデータベース670内に保存された画像最適化モジュール610の事前処理画像に対する識別子を保存する。いくつかの実施形態では、識別子は、事前処理画像のプラットフォーム独立ヘッダ情報を含む。いくつかの実施形態では、識別子は、1組のデータベース670内の画像へのポインタである。
【００５３】
例えば、ファイルストア620は、最適化画像を生成するために事前処理された2560×1980ピクセルの解像度を有する元の画像に関するヘッダまたはポインタを含む。最適化画像は、データベース670内に保存され、その中では、最適化画像は、800×600ピクセル解像度および640×480ピクセル解像度を有する。したがって、特定のデバイスが800×600ピクセルの表示解像度を有し、元の画像を要求した場合、MedServer 680は、特定のデバイス向けに最適化された事前処理画像が1組のデータベース670内に存在することを、ファイルストア620から決定することができる。いくつかの実施形態では、MedServer 680は、1組のデータベース670へのポインタを提供される。ポインタを使用して、MedServer 680は、適切な最適化画像を取り出す。いくつかの実施形態では、画像最適化モジュールは、ステータスがファイルストア620から決定されると、特定のデバイスにとって適切な最適化画像を、データベース670からMedServer 680に自動的に渡す。
【００５４】
最適化画像が存在しない解像度(例えば1280×768ピクセル)を要求デバイスが有する場合、ファイルストア620内に保存された事前処理画像のいずれか1つを使用すると、元の画像の画像品質は失われる。したがって、MedServer 680は、要求された画像の最適化画像が存在しないことを、ファイルストア620から決定する。その場合、MedServer 680は、クエリをPACS 690に再回送する。PACS 690は、元の画像を取り出す。最適化エンジン630は、取り出された元の画像を受け取り、画像のオンデマンド最適化を実行する。その後、最適化結果は、要求デバイスに渡される。加えて、最適化エンジン630は、その画像が後でまた要求された場合に画像最適化エンジン630がオンデマンド最適化を再び実行する必要がないように、最適化画像をデータベース670に保存する。
【００５５】
いくつかの実施形態では、最適化エンジン630によって実行される最適化は、1つまたは複数のXMLコンフィグレーションファイルに基づいて構成可能である。いくつかの実施形態では、コンフィグレーションは、最適化エンジン630用の様々な最適化モジュールを指定する。このようにして、コンフィグレーションファイルは、画像に適用される最適化を指定する。簡潔にするため、そのような最適化モジュールである2つのモジュール635および640だけが示されている。しかし、任意の数のさらなる最適化モジュールが、モジュール635および640に追加できること、またはモジュール635および640の代わりに使用できることは当業者には明らかであろう。例えば、いくつかの実施形態では、最適化エンジン630は、最適化画像を圧縮するための圧縮モジュールを含む。
【００５６】
様々な最適化モジュールを使用することによって、いくつかの実施形態の最適化エンジン630は、多数の画像処理パスを含む。各パスは、別のパスと並行して、ある画像最適化手順を実行することができる。このようにして、画像最適化モジュール610は、第１のパスに沿ってヘッダ解析モジュール635によって実行されるヘッダ操作と、第２のパスに沿って画像操作モジュール640によって実行される画像処理とを同時に実行することができる。
【００５７】
図7は、いくつかの実施形態による、最適化エンジン630の最適化モジュールによって実行されるプロセス700を提示している。プロセスは、DICOMフォーマットなど、プラットフォーム依存フォーマットでフォーマットされたヘッダを含む画像を(710において)受け取ることによって開始する。いくつかの実施形態では、ヘッダは、画像の符号化またはタイプ(例えば、ビットマップ、ジョイントフォトグラフィックエキスパートグループ(JPEG: Joint Photographic Experts Group)、グラフィックスインタチェンジフォーマット(GIF: Graphics Interchange Format)など)、画像の寸法または解像度、画像内容の量(例えばバイト単位のサイズ)、および他の説明的メタデータなど、画像についての説明的情報を提供する。ヘッダを復号できない場合、アプリケーションまたはクライアントデバイスは、画像を適切に表示することができない。
【００５８】
次に、プロセスは、DICOMファイルヘッダを事前処理して、XMLなどのプラットフォーム独立ファイルヘッダを生成する。このようにして、XML機能を有する任意のデバイスは、ファイルを解析することができ、したがって、画像が最初はDICOM規格に準拠してフォーマットされていたとしても、画像を再生することができる。いくつかの実施形態では、最適化エンジン630のヘッダ解析モジュール635は、ヘッダフォーマット変換を実行する。ヘッダフォーマット変換についてのより詳細な説明は、以下のセクションIIIにおいて提供される。
【００５９】
次に、プロセスは、1つまたは複数のさらなる最適化を実行する。例えば、プロセスは、画像データを事前処理して、(730において)元の画像データに基づいて1組のサイズ変更画像を生成する。いくつかの実施形態では、画像操作モジュール640は、1つまたは複数の異なる表示パラメータ(例えば、解像度、色深度など)向けに画像データを最適化するために、画像サイズ変更を実行する。いくつかの実施形態では、元の画像は、画像を要求する表示デバイスの表示解像度に一致するより低い解像度まで元の画像をダウンサンプリングすることによって、サイズ変更される。その場合、元の画像の代わりに、サイズ変更画像を転送するときは、デバイスにより少ないデータを転送しさえすればよい。加えて、ダウンサンプリングは、元の画像の寸法を縮小して、要求クライアントデバイスの表示設定の寸法に一致させるので、品質の低下を招かない。画像最適化についてのより詳細な説明は、以下のセクションIVにおいて提供される。
【００６０】
画像ヘッダが変換され、画像データが最適化されると、図6のディスクマネージャ660は、事前処理されたデータまたはオンデマンドで生成されたデータをファイルストア620内に保存する作業と、データベース670に投入する作業を課される。図8は、いくつかの実施形態による、ディスクマネージャ810を概念的に示している。ディスクマネージャ810は、ディレクトリモニタ820と、ドライバモニタ825と、ファイルインデックス840とを含む。
【００６１】
いくつかの実施形態では、ディレクトリモニタ820は、ドライブモニタ825と連携して、またはドライバモニタ825とは独立に、ファイルストア860のステータスを定期的にチェックする。具体的には、ディレクトリモニタ820は、ファイルストア860の使用量(例えばリソースレベルおよび利用レベル)が閾値に達したまたは超えた場合に、ファイルストア860のクリーンアップをトリガする。いくつかの実施形態では、ディレクトリモニタ820は、画像が更新、変更、またはPACSから削除されたことが検出された場合に、クリーンアップをトリガする。そのようなアクションによって、以前に事前処理されたすべてのデータは古いものとなり、それによって、画像最適化モジュールからそのような事前処理画像を削除することが必要となる。その後、画像最適化モジュールは、変更または更新画像に対して新しい1組の事前処理画像を生成しなければならない。いくつかの実施形態では、ディレクトリモニタ820は、1つまたは複数のフィルタおよびスクリプト865を利用して、監視およびクリーンアップを実行する。
【００６２】
いくつかの実施形態では、ディレクトリモニタ820は、最適化エンジンまたはMedServerから受け取った通知に基づいて、ファイルストア860のクリーンアップを実行する。いくつかの実施形態では、最適化エンジンまたはMedServerは、フィルタ865の1つまたは複数を使用してリソースを生成または変更するようファイルストア860に命令する。フィルタ865は、処理する画像またはファイルのファイル名および拡張子を識別する。フィルタの基準が満たされた場合、フィルタに関連付けられたスクリプトが実行される。スクリプトは、ファイル上で実行されるアクションを規定する。
【００６３】
ファイルインデックス840は、フォルダ、フォルダサイズ、ファイルサイズ、アクセス時間、ファイルなどのマップを含む。モニタ820および825は、最初スタートアップ時にインデックスを生成し、ファイルインデックス840は、メッセージが処理されるときに更新される。
【００６４】
図6を参照すると、様々なメッセージング待ち行列650は、メッセージが適切なモジュールによって処理されるまで、画像最適化モジュール610内を移動するメッセージを一時的に保持する。例えば、メッセージング待ち行列650は、ファイルストア620および他のデータベース670内に保存するために画像がディスクマネージャ660に渡される際、1組の事前処理結果を保持するために使用することができる。
【００６５】
いくつかの実施形態の画像最適化モジュールが、上で説明され、以下でさらに詳述される様々な事前処理および最適化機能を実行するための、メモリおよび処理リソースを有する、コンピュータなどの専用ハードウェアであることは当業者には明らかであろう。いくつかの実施形態では、いくつかの実施形態の画像最適化モジュールは、HISのハードウェアコンポーネントによって実行される1組のコンピュータ可読ソフトウェア命令を使用して定義される。このようにして、画像最適化モジュールは、HISの既存のコンポーネントと統合することができ、または新たに配備されるハードウェアとともにHIS内に組み込むことができる。例えば、いくつかの実施形態の画像最適化モジュールは、PACSに追加機能を提供するプラグインモジュールである。
【００６６】
III.画像ヘッダの事前処理
いくつかの実施形態では、画像最適化モジュールは、PACSの有用性を高める一方で、PACSの有用性の高まりに関連するコストを引き下げる。画像最適化モジュールがそのような利益を実現する1つの方法は、典型的なPACSに存在するプラットフォーム依存性を取り除くことによる。そのような依存性は、HISの医用画像用の共通で互換性のあるフォーマットを保証しようとする努力において一般に導入される。具体的には、これらの依存性は、画像ファイルを獲得し、生成する様々な異なる画像獲得デバイスと、獲得された画像ファイルにアクセスし、それを表示するクライアントデバイスとの間で、共通で互換性のあるフォーマットを保証する。DICOMは、HIS内の医用画像をフォーマットするための規格として出現した、プラットフォーム依存ファイルフォーマットの一例である。
【００６７】
DICOMフォーマットに従って符号化または復号を行うには、必要なDICOMライブラリを有する符号化または復号デバイスを必要とする。DICOMライブラリは、DICOMフォーマット画像ファイルを生成し、表示するための、DICOM画像ファイルフォーマットを定義する。DICOMライブラリは、1つのDICOM準拠デバイスから別のDICOM準拠デバイスにDICOMフォーマット画像ファイルを送受信するための、通信プロトコルも定義する。しかし、これらのプラットフォーム依存性は、医用画像およびPACSの使用を、DICOMライブラリを含む1組の専門DICOM準拠デバイスに制限する。これらのDICOM準拠デバイスは、保健医療提供者および病院が負担するコストを増加させる。具体的には、医療従事者は、ページャ、スマートフォン、またはPDAなど、病院内で通信を行うための1組のデバイスと、PACS内に保存されたプラットフォーム依存画像にアクセスするための別の1組のデバイスとを持ち運ぶ。これは、医療従事者が持ち運ぶ通信デバイスの多くが、DICOMプラットフォームをサポートしていないため、または通信デバイスの各々がDICOMプラットフォームをサポートできるようにするには、多額の使用許諾コストを招くためである。
【００６８】
いくつかの実施形態の画像最適化モジュールは、プラットフォーム依存ファイルフォーマットをプラットフォーム独立ファイルフォーマットで置き換えることによって、そのような専門デバイスの必要性を取り除く。具体的には、プラットフォーム依存性を取り除くことによって、医療従事者が通常持ち運ぶ通信デバイス(例えば、スマートフォン、PDAなど)は、もはやDICOMフォーマットのプラットフォーム依存性に準拠する必要はなく、したがって、もはやプラットフォーム依存フォーマットをサポートすることに関連する使用許諾コストを招く必要はない。さらに、デバイスは、DICOMライブラリを保存し、クライアントデバイス上でローカルにDICOMフォーマットを復号するのに必要とされる処理オーバヘッドおよびメモリオーバヘッドをもはや負担することはない。これは、任意の数のプラットフォーム独立デバイスが画像を表示し、PACSの機能にアクセスすることを可能にする。結果として、PACS内に保存される画像は、ほとんどの医療従事者がすでに所有する一般に利用可能な通信デバイスに変更またはアップグレードを施す必要なしに、そのようなデバイスを使用して医療従事者に配布できるので、医療保険提供者または病院が負担する総コストは低下する。
【００６９】
図9は、いくつかの実施形態による、クライアントデバイス上に表示するために、プラットフォーム依存フォーマットでフォーマットされた画像ファイルを、プラットフォーム独立フォーマットに変換するための事前処理プロセス900を提示している。プロセス900は、DICOMなど、プラットフォーム依存ファイルフォーマットに従ってフォーマットされた医用画像を(910において)受け取ることによって開始する。具体的には、ファイルフォーマットは、ファイルの内容および画像の仕様を記述するプラットフォーム依存フォーマットヘッダを含む。したがって、画像を適切に表示するには、クライアントデバイスまたはアプリケーションは、画像内容を決定するために、最初にヘッダを復号しなければならない。いくつかの実施形態では、画像がPACSによって受け取られたとき、または画像がMedServerによって受け取られたときに、プロセス900が開始し、具体的には、ステップ910が発生する。
【００７０】
プロセスは、フォーマットを定義し、符号化または復号する1つまたは複数のライブラリを使用して、プラットフォーム依存ファイルフォーマットを(920において)分析する。分析の一部として、プロセスは、関連する画像データについての説明的な情報を含む、ヘッダの様々な要素を識別する。上で述べられたように、これらのヘッダ要素は、画像タイプ、解像度、サイズなどを含むことができる。
【００７１】
プラットフォーム独立ファイルフォーマットを生成するため、プロセスは、プラットフォーム依存フォーマットヘッダと同一または類似の情報を含むプラットフォーム独立フォーマットヘッダを(930において)生成する。いくつかの実施形態では、プラットフォーム独立フォーマットは、画像用のXMLフォーマットヘッダを規定する。いくつかの実施形態では、プロセスは、同じ画像用にいくつかの異なるXMLフォーマットヘッダを(930において)生成する。そのようなフォーマットヘッダは各々、受け取った画像に対して生成されたまたは生成される異なるサイズ変更画像のアトリビュートに対応する。
【００７２】
プロセスは、結果のプラットフォーム独立ヘッダ情報を(940において)保存する。いくつかの実施形態は、画像データとは別に、図6のファイルストア620内にプラットフォーム独立ヘッダ情報を保存する。XMLヘッダは、対応する画像データを保存する1つまたは複数のデータベース670から実際の画像内容を識別し、取り出すためのポインタとして使用される。ファイルストア内にヘッダ情報だけを保存することによって、ヘッダ情報および画像内容を検索するのではなく、画像ヘッダ情報だけが検索されるので、ファイルストアに対するその後の検索は、より短い待ち時間で実行される。
【００７３】
図10は、本発明のいくつかの実施形態による、XMLフォーマットヘッダ1005に変換されたDICOMフォーマットヘッダの内容を示している。XMLフォーマットヘッダ1005は、ファイルストア620内に保存されるヘッダ情報を表している。図示されるように、データは、1組のXMLタグを用いて仕切られる。各タグは、画像についてのいくつかの説明的な情報を提供する。例えば、タグ1010は、画像がMRI脳スキャンであることを記述し、タグ1020は、画像が属する患者の名前を提供する。
【００７４】
XMLフォーマットヘッダ1005の利点は、画像内容を検索するために、強力で効率的なSQLクエリを使用できることである。反対に、DICOMフォーマットヘッダは、定評のあるSQL検索エンジンと比較した場合に性能が劣る独自仕様の検索エンジンを必要とする。さらに、XMLフォーマットヘッダ1005内の任意のタグを検索可能アトリビュートとして使用することができる。このようにして、カスタマイズされたクエリを1組の画像に対して実行できるように、PACSの機能が拡張されるが、他の方法では、DICOMファイルフォーマットでフォーマットされたデータを問い合わせるときに、そのようなカスタマイズされたクエリを利用することはできない。例えば、ユーザは、患者名タグ1020に基づいて特定の患者の画像を検索することができ、またより洗練されたクエリが指定でき、それによって、患者名タグ1020および検査日付タグ1030を使用して、特定の日付以降に生成された特定の患者名についての画像を問い合わせることができる。タグの任意の組み合わせを使用して、画像を識別するクエリを指定できることは当業者には明らかであろう。
【００７５】
図11は、DICOMフォーマットヘッダをXMLフォーマットヘッダに変換するための疑似コード1100を示している。疑似コードは、DICOMフォーマットヘッダの各ノードを辿るループ1110として動作し、ノードは、DICOMファイルフォーマット内の1組の仕切られたデータを指定する。疑似コードは、ノードから値表現(VR: value representation)を分析し、抽出する。いくつかの実施形態は、XMLフォーマット内において文字列として値表現を表す。いくつかの実施形態は、画像データを表す「OB」タイプなどのある種の値表現を省略する。
【００７６】
加えて、いくつかのDICOMヘッダノードは、シーケンスタグを含む。シーケンスタグは、他のタグ内にネストされるタグを表す。シーケンスタグを有する値表現を処理する場合、疑似コードは、値表現のシーケンスタグの番号を決定する。この値多重度(VM: value multiplicity)は、シーケンスタグの番号を指定する。したがって、これらのタグは、XML変換を実行するときに、一緒にグループ化される。図10に示されるように、タグ1045は、3の値多重度を有するシーケンスタグを表す。
【００７７】
いくつかの実施形態は、結果のXMLフォーマットヘッダを圧縮する。圧縮を実行することによって、クライアントデバイスに転送される情報の量が削減される。結果として、情報を転送するのによりわずかな帯域幅しか必要とされず、転送はより短い待ち時間で行われる。いくつかの実施形態では、クライアントは、画像を要求するときに、圧縮を要求する。例えば、ユーザは、画像を要求するときに、Z-Lib圧縮を要求することができる。図9〜図11および他の図は、DICOMフォーマットヘッダからXMLフォーマットヘッダへの変換に関して説明されたが、当該技法が、任意のプラットフォーム依存フォーマットからプラットフォーム独立フォーマットへの変換にも同様に適用されることは当業者には明らかであろう。
【００７８】
IV.画像の事前処理
いくつかの実施形態では、画像最適化モジュールは、クライアントデバイスに転送される画像内容を最適化することによって、PACSの有用性を高める。いくつかのそのような実施形態では、画像最適化モジュールは、クライアントデバイスの画像表示設定に基づいて画像をダウンサンプリングすることによって、画像内容を最適化する。そのようなダウンサンプリングは、画像の品質を低下させることなく画像サイズを縮小することによって、画像をサイズ変更する。例えば、640×480までダウンサンプリングおよびサイズ変更された解像度2560×1980を有する元の画像は、640×480の最大解像度を有する表示デバイス上に表示されたとき、品質低下を起こさない。
【００７９】
結果として、いくつかの実施形態の画像最適化モジュールは、PACSよりも効率的に画像内容を転送する。例えば、PACSは、元の画像の完全な1組のピクセルデータを使用して元の画像内容を送るが、画像最適化モジュールは、クライアントデバイスの表示能力に基づいて、クライアントデバイスに送られるピクセルデータの量を削減する。このようにして、他の方法では表示画像において除外される非本質的なピクセルデータは、必ずしもクライアントデバイスに送られるとは限らない。画像最適化モジュールは、クライアントデバイス上での画像品質に影響を与えることなく、よりわずかな画像データを転送する。したがって、画像最適化モジュールは、PACSと比べてより速く、より短い待ち時間で、画像をクライアントデバイスに転送する。
【００８０】
いくつかの実施形態によって実行される画像最適化のさらなる利点は、画像を表示するために、クライアントデバイスがよりわずかな処理しか行わなくてよいことである。第１に、よりわずかなピクセルデータが、クライアントデバイスに送られ、したがって、クライアントデバイスは、画像を表示するために処理すべきデータをよりわずかしかもたない。第２に、画像はクライアントデバイスの画面表示向けにすでに最適化されているので、クライアントデバイスは、画像を表示するために画像を再サンプリング(例えば画像解像度のダウンサンプリングまたはアップスケーリング)する必要がない。したがって、クライアントデバイスは、よりわずかな処理リソースおよびメモリリソースを使用して、より速く画像を表示することができる。これにより、あまり強力ではないデバイスであっても画像を表示できるようになる。
【００８１】
いくつかの実施形態では、画像最適化モジュールによって実行されるダウンサンプリング事前処理は、前のセクションにおいて説明されたヘッダ変換事前処理と併せて行われる。いくつかの他の実施形態では、ダウンサンプリングは、指定された間隔で動作するバッチプロセスである。
【００８２】
図12は、画像を最適化して画像をクライアントデバイスに効率的に転送するために、いくつかの実施形態の画像最適化モジュールによって実行されるプロセス1200を提示している。プロセス1200は、(1210において)画像を受け取ることによって開始する。いくつかの実施形態では、プロセスは、保存のために画像が画像獲得デバイスからPACSに転送されたときに、画像を受け取る。いくつかのそのような実施形態では、画像最適化は、画像最適化モジュールによって実行される事前処理の一部として行われる。いくつかの他の実施形態では、プロセスは、クライアントデバイスが要求するPACSからの画像検索の一部として、画像を受け取る。いくつかのそのような実施形態では、画像最適化は、画像転送の一部としてオンデマンドで行われる。
【００８３】
次に、プロセスは、生成される1つまたは複数のサイズ変更画像を定義する、1つまたは複数の画像設定を(1220において)識別する。いくつかの実施形態は、事前処理中に生成する、画像の1つまたは複数のダウンサンプリングバージョンを定義する、1つまたは複数の画像表示設定を事前決定する。加えて、画像最適化モジュールは、事前決定された設定とは異なる画像表示設定を有するクライアントデバイスによって送られた、画像を求める要求を識別した場合、いくつかの実施形態の画像最適化モジュールは、要求クライアントデバイスの特定の画像表示設定に基づいて、オンデマンドで画像表示設定を識別する。このようにして、いくつかの実施形態の画像最適化モジュールは、要求クライアントデバイスの特定の画像表示設定に従ってダウンサンプリングされた、オンデマンドダウンサンプリング画像を生成する。
【００８４】
1つまたは複数の画像設定を(1220において)識別した後、プロセスは、識別された設定に基づいてサイズ変更画像を生成するかどうかを(1230において)決定する。すべての識別された画像表示設定に対してサイズ変更画像を生成したとプロセスが(1230において)決定した場合、プロセスは終了する。それ以外の場合、プロセスは、対応するサイズ変更画像を生成するために、識別された画像表示設定を(1240において)選択する。次に、プロセスは、選択されたダウンサンプリング画像表示設定に基づいて、対応するサイズ変更画像を(1250において)生成する。
【００８５】
いくつかの実施形態では、プロセスは、付加的な画像最適化を実行する。そのような画像最適化技法の1つは、画像最適化モジュールからクライアントによりわずかなデータが転送されるように、画像データを圧縮することである。画像圧縮をステップ1250の画像ダウンサンプリングと組み合わせることによって、プロセスは、さらにいっそうの画像最適化利得を実現することができる。これらの最適化利得は、PACSからクライアントデバイスにダウンサンプリングも圧縮もされない元の画像を転送するのと比べた場合、帯域幅要件を低下させ、待ち時間をより短くする。したがって、圧縮は、その代償としてクライアントデバイス上でローカルに画像を伸張しなければならないが、画像がクライアントデバイスにより速く転送されることを可能にする。したがって、プロセスは、サイズ変更画像を圧縮するかどうかを(1260において)決定する。圧縮が実行されない場合、プロセスは、生成されたサイズ変更画像を(1280において)保存する。それ以外の場合、プロセスは、画像を(1270において)圧縮した後で、圧縮されたサイズ変更画像を(1280において)保存する。
【００８６】
いくつかの実施形態は、標準的な圧縮アルゴリズムを利用して、画像を圧縮する。例えば、いくつかの実施形態は、いくつかの例として、様々なレベルのJPEG圧縮、Z-Lib圧縮、ウェーブレット圧縮、またはPNG圧縮を利用する。いくつかの実施形態では、クライアントは、クライアントデバイスがサポートできる圧縮のタイプを指定し、画像最適化モジュールは、それに基づいて、圧縮を実行するかどうかを決定する。
【００８７】
いくつかの実施形態では、プロセスは、生成された画像を図6のデータベース670内に保存する。これらの画像へのポインタは、ファイルストア620において提供される。ポインタは、生成された画像のプラットフォーム独立ヘッダに関連付けられる。
【００８８】
図13は、事前処理された最適化画像をHISからクライアントデバイスに転送するためのデータフローを概念的に示している。簡潔にするため、この図は、図6において提示されたHISシステムアーキテクチャの簡略バージョンを示している。加えて、データフローに含まれるコンポーネントに限って、実線を用いて示されている。これらのコンポーネントは、クライアントデバイス1310と、MedServer 1320と、いくつかの実施形態の画像最適化モジュール1330と、画像最適化モジュール1330のファイルストア1340と、画像最適化モジュール1330の少なくとも1つのデータベース1350とを含む。
【００８９】
クライアントデバイス1310は、HISから画像内容を取り出すために、丸数字1によって表される初期要求を発行する。MedServer 1320は、画像要求を受け取る。PACSに問い合わせを行って、クライアントデバイス1310上での表示向けに最適化されていない元の画像を取り出す代わりに、MedServer 1320は、画像最適化モジュール1330に向けて要求を発行する。具体的には、要求は、画像最適化モジュール1330のファイルストア1340に渡る。
【００９０】
画像最適化モジュール1330は、要求を発行したクライアントデバイス1310の画像表示設定を識別する。これらの識別されたパラメータに基づいて、画像最適化モジュール1330は、クライアントデバイス1310上での表示向けに最適化された要求画像の事前処理バージョンに対応する、ファイルストア1340内のヘッダを識別する。具体的には、画像最適化モジュール1330は、識別されたヘッダをデータベース1350へのポインタとして利用する。その後、画像最適化モジュール1330は、識別されたヘッダに対応する画像データをデータベース1350から取り出す。その後、画像最適化モジュールは、最適化画像をMedServer 1320に渡す。MedServer 1320は、最適化画像を受け取り、最適化画像をクライアント1310に転送する。
【００９１】
図14は、オンデマンドで最適化された画像をHISからクライアントデバイスに転送するためのデータフローを概念的に示している。以前と同様に、クライアントデバイス1410は、画像検索プロセスを開始するために、MedServer 1420に向けてクエリを発行する。MedServer 1420もやはり、画像の最適化バージョンが事前処理されているかどうかを決定するために、画像最適化モジュール1430に向けてクエリを発行する。しかし、このシナリオにおいては、ファイルストア1440は、最適化画像が事前処理されていないことを示す、必要なポインタ情報を含んでいない。したがって、画像最適化モジュール1430は、画像の最適化バージョンが存在しないことをMedServer 1420に通知する。事前決定された1組の画像表示設定の中にない、クライアントデバイスのある画像表示設定に対しては、最適化画像が存在しないことがある。オンデマンド画像最適化プロセスを必要とする他の様々な理由が存在し得ることは当業者には明らかであろう。
【００９２】
その後、MedServer 1420は、PACSウェブサーバ1455またはクエリオブジェクト1460を使用して、要求をPACS 1450に転送する。PACS 1450は、いずれか特定のクライアントデバイス上での表示向けに最適化されていない画像の元のバージョンを取り出す。加えて、多くの場合、画像の元のバージョンは、プラットフォーム依存ヘッダ情報とともに保存される。したがって、最適化エンジン1470が、PACS 1450からの画像の取り出しを識別する。最適化エンジン1470は、クライアントデバイス1410に転送する前に画像を最適化すべきことも識別する。その後、最適化エンジンは、オンデマンド画像最適化プロセスを実行する。
【００９３】
いくつかの実施形態では、オンデマンド最適化は、プラットフォーム依存からプラットフォーム独立へのヘッダ変換を実行し、画像をダウンサンプリングし、および/またはデータ圧縮を実行する。いくつかの実施形態では、データ圧縮は、変換されたヘッダ、元の画像内容、ダウンサンプリングされた画像内容、変換されたヘッダと元の画像内容、または変換されたヘッダとダウンサンプリングされた画像内容を圧縮することを含む。
【００９４】
その後、最適化エンジン1470は、ファイルストア1440およびデータベース1490内に最適化画像を保存するための十分なスペースが存在することを保証するために、ディスクマネージャ1480に通知する。完了すると、最適化画像情報は、ファイルストア1440およびデータベース1490内で待ち行列に入れられ、最適化画像は、画像最適化モジュール1430からMedServer 1420に転送される。その後、MedServer 1420は、表示するために最適化画像をクライアントデバイス1410に回送する。
【００９５】
V.コンピュータシステム
上で説明されたコンポーネント(例えば、MedServer、画像最適化モジュール、最適化エンジンなど)の多くは、(コンピュータ可読媒体とも呼ばれる)機械可読媒体上に記録された1組の命令として指定されるソフトウェアプロセスを通して、上で説明された機能の一部または全部を実施する。これらの命令は、1つまたは複数のコンピューティング要素(プロセッサまたはASICおよびFPGAなどの他のコンピューティング要素)によって実行された場合、(1つまたは複数の)コンピューティング要素に命令内で指示されたアクションを実行させる。コンピュータは、その最も広い意味で解釈され、プロセッサを有する任意の電子デバイスを含むことができる。コンピュータ可読媒体の例は、CD-ROM、フラッシュドライブ、RAMチップ、ハードドライブ、EPROMなどを含むが、これらに限定されない。
【００９６】
本明細書では、「ソフトウェア」という用語は、その最も広い意味で解釈される。ソフトウェアは、リードオンリメモリ内に存在するファームウェア、またはプロセッサによる処理のためにメモリ内に読み込むことができる磁気ストレージ内に保存されたアプリケーションを含むことができる。またいくつかの実施形態では、多数のソフトウェア発明は、個々のソフトウェア発明を維持しながら、より大きなプログラムの下位区分として実施することができる。いくつかの実施形態では、多数のソフトウェア発明は、別個のプログラムとして実施することもできる。最後に、ここで説明されるソフトウェア発明を一緒に実施する別個のプログラムの任意の組み合わせも、本発明の範囲内に存在する。
【００９７】
図15は、本発明のいくつかの実施形態がそれを用いて実施されるコンピュータシステムを示している。そのようなコンピュータシステムは、様々なタイプのコンピュータ可読媒体と、様々な他のタイプのコンピュータ可読媒体用のインタフェースとを含む。コンピュータシステム1500は、バス1505と、プロセッサ1510と、システムメモリ1515と、リードオンリメモリ1520と、永久ストレージデバイス1525と、入力デバイス1530と、出力デバイス1535とを含む。
【００９８】
バス1505は、コンピュータシステム1500の多くの内部デバイスを通信可能に接続する、すべてのシステムバス、周辺バス、およびチップセットバスを一括して表している。例えば、バス1505は、プロセッサ1510を、リードオンリメモリ1520、システムメモリ1515、および永久ストレージデバイス1525と通信可能に接続する。これらの様々なメモリユニットから、プロセッサ1510は、本発明のプロセスを実行するために、実行する命令と、処理するデータとを取り出す。
【００９９】
リードオンリメモリ(ROM)1520は、プロセッサ1510およびコンピュータシステムの他のモジュールによって必要とされる、静的データと、命令とを保存する。他方、永久ストレージデバイス1525は、読み書き可能なメモリデバイスである。このデバイスは、コンピュータシステム1500がオフになった場合にも命令およびデータを保存する不揮発性メモリユニットである。本発明のいくつかの実施形態は、永久ストレージデバイス1525として大容量ストレージデバイス(磁気ディスクまたは光ディスク、および対応するディスクドライブなど)を使用する。
【０１００】
他の実施形態は、永久ストレージデバイスとして着脱可能ストレージデバイス(フロッピディスク、フラッシュドライブ、またはZIP(登録商標)ディスク、および対応するディスクドライブなど)を使用する。永久ストレージデバイス1525と同様に、システムメモリ1515は、読み書き可能なメモリデバイスである。しかし、ストレージデバイス1525と異なり、システムメモリは、ランダムアクセスメモリ(RAM)などの揮発性の読み書き可能なメモリである。システムメモリは、プロセッサが実行時に必要とする命令およびデータのいくつかを保存する。いくつかの実施形態では、本発明のプロセスは、システムメモリ1515、永久ストレージデバイス1525、および/またはリードオンリメモリ1520内に保存される。
【０１０１】
バス1505は、入力デバイス1530および出力デバイス1535にも接続する。入力デバイスは、ユーザが、コンピュータシステムに情報を伝達し、コマンドを選択することを可能にする。入力デバイス1530は、英数字キーボードと、ポインティングデバイス(「カーソル制御デバイス」とも呼ばれる)とを含む。入力デバイス1530は、オーディオ入力デバイス(例えば、マイクロフォン、MIDI楽器など)も含む。出力デバイス1535は、コンピュータシステムによって生成された画像を表示する。例えば、これらのデバイスは、GUIを表示する。出力デバイスは、プリンタと、ブラウン管(CRT)または液晶ディスプレイ(LCD)などの表示デバイスとを含む。
【０１０２】
最後に、図15に示されるように、バス1505は、ネットワークアダプタ(図示されず)を介してコンピュータ1500をネットワーク1565にも結合する。このようにして、コンピュータは、(ローカルエリアネットワーク(「LAN」)、ワイドエリアネットワーク(「WAN」)、もしくはイントラネットなど)コンピュータのネットワークの一部、またはインターネットなど、複数のネットワークにおけるネットワークの一部とすることができる。
【０１０３】
上で言及されたように、コンピュータシステム1500は、様々な異なるコンピュータ可読媒体の1つまたは複数を含むことができる。そのようなコンピュータ可読媒体のいくつかの例は、RAM、ROM、リードオンリコンパクトディスク(CD-ROM)、記録可能コンパクトディスク(CD-R)、書換可能コンパクトディスク(CD-RW)、リードオンリデジタル多用途ディスク(例えば、DVD-ROM、デュアルレイヤDVD-ROM)、様々な記録可能/書換可能DVD(例えば、DVD-RAM、DVD-RW、DVD+RWなど)、フラッシュメモリ(例えば、SDカード、ミニSDカード、マイクロSDカードなど)、磁気および/またはソリッドステートハードドライブ、ZIP(登録商標)ディスク、リードオンリーblu-rayディスクおよび記録可能blu-rayディスク、他の任意の光媒体または磁気媒体、ならびにフロッピディスクを含む。
【０１０４】
コンピュータシステム1500のコンポーネントのいずれかまたはすべてが本発明とともに使用できることを当業者であれば理解されよう。例えば、図15に関して説明されたコンピュータシステムのコンポーネントの一部または全部は、上で説明された画像最適化モジュール、MedServer、最適化エンジンなどのいくつかの実施形態を構成する。さらに、他の任意のシステム構成も本発明または本発明のコンポーネントとともに使用できることを当業者であれば理解されよう。したがって、本発明は上記の例示的な詳細によって限定されるのではなく、むしろ添付の特許請求の範囲によって確定されることを当業者であれば理解されよう。
【符号の説明】
【０１０５】
110 DICOM非準拠クライアント
120 DICOM準拠クライアント
130 画像最適化モジュール
140 PACS
150 DICOMフォーマットヘッダ
160 XMLフォーマットヘッダ
210 クライアント表示デバイス
220 クライアント表示デバイス
230 クライアント表示デバイス
240 クライアント表示デバイス
250 画像最適化モジュール
260 PACS
270 元の画像
280 サイズ変更画像
285 サイズ変更画像
290 サイズ変更画像
310 HIS
320 画像獲得デバイス
325 クライアントデバイス
330 MedServer
340 PACSウェブサーバ
350 クエリオブジェクト
360 PACS
370 画像最適化モジュール
380 データベース
410 オブジェクト
420 XMLオブジェクト
510 オブジェクト
520 XMLオブジェクト
610 画像最適化モジュール
620 ファイルストア
630 最適化エンジン
635 ヘッダ解析モジュール
640 画像操作モジュール
650 メッセージング待ち行列
660 ディスクマネージャ
670 データベース
680 MedServer
690 PACS
810 ディスクマネージャ
820 ディレクトリモニタ
825 ドライブモニタ
840 ファイルインデックス
860 ファイルストア
865 フィルタおよびスクリプト
1005 XMLフォーマットヘッダ
1010 タグ
1020 タグ
1030 タグ
1045 タグ
1100 疑似コード
1110 ループ
1310 クライアントデバイス
1320 MedServer
1330 画像最適化モジュール
1340 ファイルストア
1350 データベース
1410 クライアントデバイス
1420 MedServer
1430 画像最適化モジュール
1440 ファイルストア
1450 PACS
1455 PACSウェブサーバ
1460 クエリオブジェクト
1470 最適化エンジン
1480 ディスクマネージャ
1490 データベース
1500 コンピュータシステム
1505 バス
1510 プロセッサ
1515 システムメモリ
1520 リードオンリメモリ
1525 永久ストレージデバイス
1530 入力デバイス
1535 出力デバイス
【技術分野】
【０００１】
本発明は、保健医療の分野に関し、より具体的には、医用画像を画像ストアから1つまたは複数のデバイスに効率的に転送するための方法およびシステムに関する。
【背景技術】
【０００２】
保健医療の質は、絶え間なく進化し、改善し続けている。これらの改善は、しばしばより優れた医療技術および医療行為を含むが、患者データ管理の改善を含むこともある。患者データをより良く獲得し、管理し、流布させることによって、保健医療提供者は、平凡なデータ入力およびデータ獲得の仕事から自らを解放することができる。これらの仕事は、それが省ければ医療の提供に割り振ることのできる時間を浪費することがあり得る。
【０００３】
現在、多くの病院は、患者データをデジタル的に獲得し、保存している。患者データをデジタル的に保存することによって、保健医療提供者は、いつでも病院内のいかなる場所からでも、迅速に患者データを検索し、アクセスする能力を有する。しかし、デジタル患者データへの移行は、いくつかのデータ互換性問題を引き起こす。第１フォーマットまたはデバイスを使用して入力されたデータは、第２フォーマットまたはデバイスを使用して入力されたデータと必ずしも互換性があるとは限らない。このようなことは、異なる製造業者が、病院内での専門目的のために異なる画像処理デバイスを作成し、各デバイスが、しばしば独自仕様の異なるインタフェースおよび異なるファイルフォーマットを有する場合にしばしば起きていた。その結果、デジタルデータの相互運用性を保証するための規格が制定された。
【０００４】
医用デジタル画像処理および通信(DICOM: Digital Imaging and Communications in Medicine)は、デジタル医用画像処理のために制定されたそのような規格の1つである。DICOM互換デバイスまたはアプリケーションは、任意のDICOM互換画像を生成、作成、表示、送信、問い合わせ、保存、処理、検索、または印刷できることを保証される。現在、DICOMは、放射線医学、心臓病学、腫瘍学、歯科学、外科学、神経学、マンモグラフィ、放射線治療学、眼科学、整形外科学、小児科学、病理学、獣医学などにおける画像処理に使用されている。そのようなわけで、現在、DICOMは、病院または他の保健医療環境において画像を保存、検索、配布、および提示するための中央画像ストアを提供する、画像保管通信システム(PACS: Picture Archiving and Communication Systems)を実施するための好ましい規格である。これはさらに、DICOM準拠デバイスを購入することによって、病院が、そのようなデバイスを病院情報システム(HIS: Hospital Information System)にシームレスに統合することができ、デバイスにPACS内の任意の画像を表示させ、アクセスさせることができることを保証する。
【０００５】
DICOM規格は、HIS内の様々なデバイスの相互互換性および相互運用性を保証するために準拠しなければならない特定のファイルフォーマット定義を規定する。加えて、DICOMは、これらの医用画像の伝送および流布のためのネットワーク通信プロトコルを規定する。したがって、DICOM規格と互換性のあるデバイスは、専門デバイスである。そのような互換デバイスは、ファイルフォーマットを解析および処理するため、または通信プロトコルを使用して通信(例えば送信および受信)するために、必然的に1つまたは複数のライブラリを含む。
【０００６】
これらのライブラリおよびプロトコルを必要とすることによって、DICOM規格は、保健医療環境内で普通に使用されている多くのデバイスが、デジタル医用画像にアクセスできないようにする。例えば、ワイヤレス通信を行い、低解像度または高解像度画像を表示できる、スマートフォン、セルラ電話、または携帯情報端末(PDA)の多くは、DICOMフォーマット画像を処理することができない。場合によっては、これらのデバイスは、必要なDICOM機能(例えばライブラリ)を含むことによって互換性をもつようにすることができるが、それには、増大するメモリ、処理、および最終コストという犠牲が伴い、それらのために、そのような機能は実用にならないことがあり得る。代わりに、病院は、DICOM規格を使用して動作するPACSから得ることができる便益を十分に実現するために、専門ハードウェアおよび独自仕様ソフトウェアに投資しなければならない。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
したがって、DICOMによって提供される相互運用性を維持しながら、DICOM規格に準拠することに関連するオーバヘッドを低減することが、当技術分野において必要とされている。例えば、DICOM機能の欠如に関わらず、より多くの従来デバイス(例えば、スマートフォン、セルラ電話、PDAなど)を互換PACS表示プラットフォームとして利用可能にすることが必要とされている。言い換えると、これらのデバイスに変更を施す必要なしに、これらのデバイスが、DICOMフォーマット画像を送信、受信、および表示することを可能にし、それによって、保健医療提供者が負担するコストを削減することが必要とされている。
【課題を解決するための手段】
【０００８】
いくつかの実施形態は、画像保管通信システム(PACS)などの画像データベースから1つまたは複数の異なる表示デバイスに医用画像を効率的に転送するための方法およびシステムを提供する。いくつかの実施形態は、画像をクライアントデバイスに転送する前に、クライアントデバイスの仕様に基づいて画像を最適化することによって、画像の効率的な転送を実行する。いくつかの実施形態は、画像がPACSに保存されるときに画像を事前処理することによって、画像を最適化する。いくつかの実施形態は、画像がクライアントデバイスによって要求され、クライアントデバイスに送信されるときに、オンデマンドで画像を最適化する。
【０００９】
いくつかの実施形態は、専門または独自仕様デバイス上でだけ見ることができるプラットフォーム依存画像ファイルを、1つまたは複数の異なるクライアントデバイスの任意の標準的な画像表示アプリケーションによって見ることができるプラットフォーム独立画像ファイルに変換することによって、画像を最適化する。いくつかのそのような実施形態では、PACSは、プラットフォーム依存フォーマットで医用画像を保存する。プラットフォーム依存フォーマットは、画像を復号および処理するために専門ライブラリを有するようクライアントデバイスに要求する。これらの専門ライブラリは、クライアントデバイス上に存在しなければならない。加えて、これらのライブラリは、クライアントデバイスがフォーマットを復号し、見ることのできる画像を作成するために、クライアントデバイスにおいて行われる付加的な計算を必要とする。
【００１０】
いくつかの実施形態は、表示するために画像をデバイスに転送する前に、保存画像のプラットフォーム依存ファイルフォーマットをプラットフォーム独立ファイルフォーマットに変更することによって、PACS内に保存された画像を多数の異なる受信デバイス上に表示するために最適化する。このようにして、いくつかの実施形態は、プラットフォーム依存ファイルフォーマットの独自仕様の復号に必要とされる処理要件をクライアント表示デバイスから取り除く。さらに、クライアント表示デバイスは、復号機能を実行するための対応するライブラリを保存しなくても、医用画像を表示することができる。したがって、いくつかの実施形態は、最低限の処理リソースまたはメモリリソースを有するにすぎない表示デバイスを使用して医用画像を表示できるように、表示デバイスのメモリ要件も軽減する。例えば、表示デバイスは、何らかの基本的な画像再生機能を有する、ポケットPC、スマートフォン、セルラ電話、または携帯情報端末(PDA)を含むことができる。
【００１１】
いくつかの実施形態は、プラットフォーム独立ファイルフォーマットとして拡張マークアップ言語(XML)フォーマットヘッダを生成する。いくつかの実施形態では、生成されたXMLヘッダは、プラットフォーム依存ファイルフォーマットに代わって使用される。XMLは、多数の異なるコンピューティングプラットフォーム(例えば、Microsoft Windows(登録商標)およびApple Mac OS(登録商標))上で実行可能なプラットフォーム独立ファイルフォーマットの一例であり、現在、XMLフォーマットを復号および処理するために独自仕様のまたは使用許諾された復号ライブラリを必要としないいくつかのアプリケーションが存在する。いくつかの実施形態が、XMLファイルフォーマットに加えてまたは代わって、任意の数のプラットフォーム独立ファイルフォーマットを使用することは当業者には明らかであろう。プラットフォーム依存ファイルフォーマットは、医用デジタル画像処理および通信(DICOM)フォーマットなど、任意の数の独自仕様フォーマットを含むことができ、DICOMは、最初に画像を転送し、PACS内に画像を保存するために使用される。画像最適化を施してプラットフォーム独立ファイルフォーマットにしない場合、DICOMフォーマットは、DICOMフォーマットを復号するための専門ライブラリを表示デバイス上に必要とする。多くの場合、これらの専門ライブラリの使用は、使用許諾コストを招く。さらに、ライブラリは、プラットフォーム固有であるので、多くの一般に利用可能なクライアントデバイスのソフトウェアまたはハードウェアと互換性がないことがある。例えば、今日のスマートフォンのいくつかは、現在のところ、Microsoft Windows(登録商標) Mobileオペレーティングシステムを用いて動作するが、他のスマートフォンは、Palm(登録商標)オペレーティングシステムまたはSymbian(登録商標)オペレーティングシステムを用いて動作し、そのような各オペレーティングシステムは、異なる独自仕様の復号ライブラリを必要とする。
【００１２】
加えて、いくつかの実施形態は、プラットフォーム独立フォーマットを使用して、PACSの画像に対する強力な問い合わせを実施する。プラットフォーム独立フォーマットは、XMLタグを個別にまたは一緒に使用して任意の数のカスタマイズ可能なクエリを指定することができるので、より大きな柔軟性を可能にする。これは、さもなければプラットフォーム依存フォーマットのもとでは無効なクエリを使用して画像を検索する能力をユーザに与える。
【００１３】
いくつかの実施形態は、クライアント表示デバイスの画像表示設定に従って画像データをサイズ変更することによって、画像最適化および効率的な画像転送を実行する。具体的には、デバイスの画像設定まで画像をダウンサンプリングすることによって、いくつかの実施形態は、医用画像の品質を低下させることなく、表示デバイスに転送される医用画像の画像データを縮小する。例えば、1600×1200の解像度を有する元の画像は、対応する320×240の解像度を有する表示デバイスに転送する前に、320×240の解像度にサイズ変更される。このようにして、画像は、より迅速に、より短い待ち時間で、画像ストアから表示デバイスに転送される。いくつかの実施形態は、画像がPACSに最初に保存されるときもしくは更新されるときの事前処理において、またはユーザが画像を要求したときにオンデマンドで、この最適化を実行する。
【００１４】
事前処理またはオンデマンド処理の最中に、いくつかの実施形態は、異なる画像設定の組に対してサイズ変更された画像の組を生成する。各サイズ変更画像は、対応する表示設定を有するデバイスを使用して表示されたときに画像品質を損なうことのない縮小画像データの組を有する。表示デバイスの画像設定を識別することによって、いくつかの実施形態は、識別された表示設定に対応するサイズ変更画像だけを転送し、したがって、不要な画像データの転送を回避する。
【００１５】
いくつかの実施形態は、転送される画像ファイルを圧縮することによって、画像転送を最適化する。これは、表示デバイスに転送される画像データの量を削減するための付加的な手段を提供する。いくつかの実施形態は、画像のより効率的な転送を達成するために、サイズ変更画像データ、変更されたヘッダ、元の画像データ、元のヘッダ、またはヘッダと画像データの何らかの組み合わせを圧縮する。
【００１６】
いくつかの実施形態が、上述の技法の1つまたは複数を個別にまたは互いに組み合わせて使用して画像を最適化することは当業者には明らかであろう。そのようなわけで、いくつかの実施形態は、最適化の所望のレベルに応じて、異なるレベルの最適化を達成する。
【００１７】
本発明の新規な特徴は、添付の特許請求の範囲において説明される。しかし、説明の目的で、本発明のいくつかの実施形態が、以下の図において説明される。
【図面の簡単な説明】
【００１８】
【図１】いくつかの実施形態による、医用画像のプラットフォーム依存ファイルフォーマットの、プラットフォーム独立ファイルフォーマットへの変換を概念的に示す図である。
【図２】いくつかの実施形態の画像最適化モジュール250によって実行される画像のサイズ変更を示す図である。
【図３】画像がPACS内に保存されるときに画像を事前処理する統合画像最適化モジュールを有するHISの例示的なアーキテクチャを示す図である。
【図４】いくつかの実施形態による、画像最適化モジュールからクライアント要求画像を取り出すためにMedServerによって処理されるスクリプトの例示的な機能を提示する図である。
【図５】いくつかの実施形態による、画像最適化モジュールからクライアント要求画像を取り出すためにMedServerによって処理されるスクリプトの例示的な機能を提示する図である。
【図６】いくつかの実施形態の画像最適化モジュールの様々なコンポーネントのうちのいくつかを示す図である。
【図７】いくつかの実施形態による、最適化エンジンの最適化モジュールによって実行されるプロセスを提示する図である。
【図８】いくつかの実施形態による、ディスクマネージャを概念的に示す図である。
【図９】いくつかの実施形態による、クライアントデバイスへの効率的な転送のために画像を最適化するための事前処理プロセスを提示する図である。
【図１０】本発明のいくつかの実施形態による、XMLフォーマットヘッダに変換されたDICOMフォーマットヘッダの内容を示す図である。
【図１１】DICOMフォーマットヘッダをXMLフォーマットヘッダに変換するための疑似コードを示す図である。
【図１２】画像を最適化して画像をクライアントデバイスに効率的に転送するために、いくつかの実施形態の画像最適化モジュールによって実行されるプロセスを提示する図である。
【図１３】事前処理された最適化画像をHISからクライアントデバイスに転送するためのデータフローを概念的に示す図である。
【図１４】オンデマンドで最適化された画像をHISからクライアントデバイスに転送するためのデータフローを概念的に示す図である。
【図１５】本発明のいくつかの実施形態がそれを用いて実施されるコンピュータシステムを概念的に示す図である。
【発明を実施するための形態】
【００１９】
本発明の以下の詳細な説明において、本発明の多くの詳細、例、および実施形態が叙述され、説明される。しかし、本発明が叙述される実施形態に限定されないこと、また本発明が説明された特定の詳細および例のいくつかを省いても実施できることは当業者には明瞭かつ明白であろう。
【００２０】
I.概要
いくつかの実施形態は、画像保管通信システム(PACS)などの画像データベースから1つまたは複数の異なる表示デバイスに医用画像を効率的に転送するための方法およびシステムを提供する。いくつかの実施形態は、画像をクライアントデバイスに転送する前に、クライアントデバイスの仕様に基づいて画像を最適化することによって、画像の効率的な転送を実行する。いくつかの実施形態は、画像がPACSに保存されるときに画像を事前処理することによって、画像を最適化する。いくつかの実施形態は、画像がクライアントデバイスによって要求され、クライアントデバイスに送信されるときに、オンデマンドで画像を最適化する。
【００２１】
いくつかの実施形態は、専門または独自仕様デバイス上でだけ見ることができるプラットフォーム依存画像ファイルを、1つまたは複数の異なるクライアントデバイスの任意の標準的な画像表示アプリケーションによって見ることができるプラットフォーム独立画像ファイルに変換することによって、画像を最適化する。いくつかのそのような実施形態では、PACSは、プラットフォーム依存フォーマットで医用画像を保存する。プラットフォーム依存フォーマットは、画像を復号および処理するために専門ライブラリを有するようクライアントデバイスに要求する。これらの専門ライブラリは、クライアントデバイス上に存在しなければならない。加えて、これらのライブラリは、クライアントデバイスがフォーマットを復号し、見ることのできる画像を作成するために、クライアントデバイスにおいて行われる付加的な計算を必要とする。
【００２２】
いくつかの実施形態は、表示するために画像をデバイスに転送する前に、保存画像のプラットフォーム依存ファイルフォーマットをプラットフォーム独立ファイルフォーマットに変更することによって、PACS内に保存された画像を多数の異なる受信デバイス上に表示するために最適化する。このようにして、いくつかの実施形態は、プラットフォーム依存ファイルフォーマットの独自仕様の復号に必要とされる処理要件をクライアント表示デバイスから取り除く。さらに、クライアント表示デバイスは、復号機能を実行するための対応するライブラリを保存しなくても、医用画像を表示することができる。したがって、いくつかの実施形態は、最低限の処理リソースまたはメモリリソースを有するにすぎない表示デバイスを使用して医用画像を表示できるように、表示デバイスのメモリ要件も軽減する。例えば、表示デバイスは、何らかの基本的な画像再生機能を有する、ポケットPC、スマートフォン、セルラ電話、または携帯情報端末(PDA)を含むことができる。
【００２３】
いくつかの実施形態は、プラットフォーム独立ファイルフォーマットとして拡張マークアップ言語(XML)フォーマットヘッダを生成する。いくつかの実施形態では、生成されたXMLヘッダは、プラットフォーム依存ファイルフォーマットに代わって使用される。XMLは、多数の異なるコンピューティングプラットフォーム(例えば、Microsoft Windows(登録商標)およびApple Mac OS(登録商標))上で実行可能なプラットフォーム独立ファイルフォーマットの一例であり、現在、XMLフォーマットを復号および処理するために独自仕様のまたは使用許諾された復号ライブラリを必要としないいくつかのアプリケーションが存在する。いくつかの実施形態が、XMLファイルフォーマットに加えてまたは代わって、任意の数のプラットフォーム独立ファイルフォーマットを使用することは当業者には明らかであろう。プラットフォーム依存ファイルフォーマットは、医用デジタル画像処理および通信(DICOM)フォーマットなど、任意の数の独自仕様フォーマットを含むことができ、DICOMは、最初に画像を転送し、PACS内に画像を保存するために使用される。画像最適化を施してプラットフォーム独立ファイルフォーマットにしない場合、DICOMフォーマットは、DICOMフォーマットを復号するための専門ライブラリを表示デバイス上に必要とする。
【００２４】
加えて、いくつかの実施形態は、プラットフォーム独立フォーマットを使用して、PACSの画像に対する強力な問い合わせを実施する。プラットフォーム独立フォーマットは、XMLタグを個別にまたは一緒に使用して任意の数のカスタマイズ可能な問い合わせを指定することができるので、より大きな柔軟性を可能にする。多くの場合、これらの専門ライブラリの使用は、使用許諾コストを招く。さらに、ライブラリはプラットフォーム固有であるので、ライブラリは、多くの一般に利用可能なクライアントデバイスのソフトウェアまたはハードウェアと互換性がないことがある。例えば、今日のスマートフォンのいくつかは、現在のところ、Microsoft Windows(登録商標) Mobileオペレーティングシステムを用いて動作するが、他のスマートフォンは、Palm(登録商標)オペレーティングシステムまたはSymbian(登録商標)オペレーティングシステムを用いて動作し、そのような各オペレーティングシステムは、異なる独自仕様の復号ライブラリを必要とする。
【００２５】
図1は、いくつかの実施形態による、医用画像のプラットフォーム依存ファイルフォーマットの、プラットフォーム独立ファイルフォーマットへの変換を概念的に示している。この図は、DICOM準拠クライアント120と、DICOM非準拠クライアント110と、いくつかの実施形態の画像最適化モジュール130と、PACS 140とを含む。
【００２６】
この図では、PACS 140は、DICOMファイルフォーマットを使用して医用画像を保存する。したがって、各画像は、DICOMフォーマットヘッダ150を含む。クライアント120などのDICOM準拠クライアントだけが、PACS 140の医用画像に直接アクセスし、それを復号し、表示することができる。DICOM準拠クライアント120は、デバイスがDICOMファイルフォーマットを認識および復号することを可能にするのに必要なDICOMライブラリを内部的に保存している。したがって、クライアント120は、1つまたは複数のDICOMライブラリを保存するために、そのメモリリソースの一部を割り当てる。多くの場合、そのような独自仕様フォーマットに関連する復号は、プラットフォーム独立ファイルフォーマットの復号よりも大きな計算オーバヘッドを有する。
【００２７】
いくつかの実施形態の画像最適化モジュール130を利用することによって、保健医療の専門家によって普通に使用される多くのデバイスは、DICOM非準拠であっても、DICOMフォーマット画像ファイルにアクセスし、それを表示できるようにすることができる。図示されるように、いくつかの実施形態の画像最適化モジュール130は、画像をDICOM非準拠クライアント110に転送する前に、DICOMフォーマットヘッダ150をXMLフォーマットヘッダ160に変換する。XMLはプラットフォーム独立フォーマットであるので、クライアント110は、任意の従来の画像表示アプリケーションを使用して、画像内容を記述するXMLヘッダ160とともに渡された画像データを解析し、表示することができる。例えば、クライアント110は、画像再生機能を有するXML対応のウェブブラウザを、画像表示アプリケーションとして使用することができる。
【００２８】
反対に、クライアント120は、PACS 140の画像150に直接アクセスする。そのようなわけで、クライアント120がPACS 140から受け取る画像は、DICOMフォーマットヘッダを含む。したがって、画像データを表示するために、クライアント120は最初に、DICOMライブラリを使用して独自仕様のDICOMヘッダを復号する。DICOMライブラリは、クライアント120上にローカルに保存される。DICOMライブラリは、クライアントがDICOMフォーマットを認識および処理することを可能にする。しかし、別の方式ではいくつかの実施形態の画像最適化モジュール130によって実行できたそのような処理は、クライアント120の追加的な計算リソースを必要とする。さらに、DICOMライブラリはしばしば、クライアント120のユーザにDICOMライブラリの使用権に対する使用許諾料の支払いを要求する独自仕様のライブラリである。
【００２９】
いくつかの実施形態は、クライアント表示デバイスの画像表示設定に従って画像データをサイズ変更することによって、画像最適化および効率的な画像転送を実行する。具体的には、デバイスの画像設定まで画像をダウンサンプリングすることによって、いくつかの実施形態は、医用画像の品質を低下させることなく、表示デバイスに転送される医用画像の画像データを縮小する。このようにして、画像は、より迅速に、より短い待ち時間で、画像ストアから表示デバイスに転送される。いくつかの実施形態は、画像がPACSに最初に保存されるときもしくは更新されるときの事前処理において、またはユーザが画像を要求したときにオンデマンドで、この最適化を実行する。
【００３０】
事前処理またはオンデマンド処理の最中に、いくつかの実施形態は、異なる画像設定の組に対してサイズ変更された画像の組を生成する。各サイズ変更画像は、対応する表示設定を有するデバイスを使用して表示されたときに画像品質を損なうことのない縮小画像データの組を有する。表示デバイスの画像設定を識別することによって、いくつかの実施形態は、識別された表示設定に対応するサイズ変更画像だけを転送し、したがって、不要な画像データの転送を回避する。
【００３１】
図2は、いくつかの実施形態の画像最適化モジュール250によって実行される画像のサイズ変更を示している。図は、いくつかのクライアント表示デバイス210〜240と、いくつかの実施形態の画像最適化モジュール250と、PACS 260とを含む。PACS 260は、クライアントデバイス210〜240によって要求される元の画像270を保存する。
【００３２】
画像最適化モジュール250は、元の画像270から多数の異なるサイズ変更画像280〜290を生成する。サイズ変更画像の各々は、クライアントデバイスの画像表示設定に基づいて、特定のクライアントデバイス上に表示するために最適化される。いくつかの実施形態では、画像最適化モジュール250は、保存するために画像が最初にPACS 260に送られるときの事前処理の最中に、サイズ変更画像を生成する。いくつかの実施形態では、画像最適化モジュール250は、各デバイス210〜230がPACS 260に画像を要求したときにオンデマンドで、サイズ変更画像を生成する。
【００３３】
この図では、クライアントデバイス210〜240は、異なる画像表示設定を有する。例えば、クライアント210は、大きなデスクトップ表示モニタを有するデスクトップコンピュータである。クライアント210は、ラップトップコンピューティングデバイス230の画面と比べて、より高い表示解像度を有し、PDAまたはスマートフォン220と比べた場合は、さらに高い表示解像度を有する。したがって、元の画像270が2560×1980ピクセルの表示解像度を有し、コンピュータ210のディスプレイが1280×960ピクセルの表示解像度を有すると仮定すると、画像最適化モジュール250は、クライアント210上に表示するために画像270を最適化する。具体的には、画像最適化モジュール250は、非本質的なピクセル情報がクライアント210に渡されないように、画像270をデバイス210の1280×960表示解像度までダウンサンプリングする。図示されるように、画像最適化モジュール250は、元の画像270の代わりに、最適化画像280をクライアントデバイス210に渡し、最適化画像280は、元の画像270よりもわずかなピクセルデータを含む。
【００３４】
同様に、PDA 220が176×144ピクセルの表示解像度を有すると仮定すると、画像をクライアント220上に表示したときに画像品質を低下させることなく、2560×1980ピクセルデータのうちの多くが、いくつかの実施形態の画像最適化モジュール250によって削除される。この場合、画像最適化モジュール250からデバイス220に渡されるサイズ変更画像285は、わずか176×144の表示解像度を有するようにダウンサンプリングされる。この非本質的なピクセルデータを削除することによって、必要な量のデータしか渡されないので、いくつかの実施形態は、PACS 260からクライアントに画像を転送するための時間を短縮し、クライアント上で実行される処理を減少させる。いくつかの実施形態の画像最適化モジュール250が、最適化画像内に付加的なピクセルデータを含むことは当業者には明らかであろう。付加的なピクセルデータは、ユーザが画像をズームして特定の領域をより詳細に見ることを可能にする。しかし、そのような付加的なピクセルデータは、元の画像のピクセルデータの量よりもわずかであり、したがって、元の画像を転送するときよりも効率的にクライアントデバイスに転送される最適化画像をもたらす。
【００３５】
図2はまた、PACS 260から画像を直接取り出すクライアント240を示している。これらの画像は、クライアント240の画像設定向けに最適化されていない。そのようなわけで、非本質的な画像データが、クライアント240に転送される。例えば、元の画像270が2560×1980ピクセルの解像度を有し、クライアントデバイスが1280×960ピクセル解像度しか有さない場合、クライアント240は、必要とされるよりも2倍も多くのデータ(縮小画像用の1280×960ピクセルの代わりに、元の画像の2560×1980ピクセル)を受け取る。さらに、その場合、1280×960ピクセルディスプレイに適合するように適切にサイズ変更するための処理負担は、デバイス240が担わされる。
【００３６】
いくつかの実施形態は、転送される画像ファイルを圧縮することによって、画像転送を最適化する。これは、表示デバイスに転送される画像データの量を削減するための付加的な手段を提供する。いくつかの実施形態は、画像のより効率的な転送を達成するために、サイズ変更画像データ、変更されたヘッダ、元の画像データ、元のヘッダ、またはヘッダと画像データの何らかの組み合わせを圧縮する。
【００３７】
いくつかの実施形態が、上述の技法の1つまたは複数を個別にまたは互いに組み合わせて使用して画像を最適化することは当業者には明らかであろう。そのようなわけで、異なるレベルの最適化を達成することができる。
【００３８】
本発明のいくつかのより詳細な実施形態が、以下のセクションで説明される。具体的には、セクションIIは、効率的な画像転送方法を実施するための、いくつかの実施形態による環境を説明する。セクションIIIは、画像の効率的な転送を促進するための、画像ヘッダの事前処理およびオンデマンド処理のいくつかの例を提供する。次に、セクションIVは、画像の効率的な転送を促進するための、画像データの事前処理およびオンデマンド処理のいくつかの例を提供する。最後に、セクションVは、本発明のいくつかの実施形態がそれを用いて実施されるコンピュータシステムについての説明を提供する。
【００３９】
II.システムアーキテクチャ
画像を効率的に転送するための様々な画像最適化機能を実行するいくつかの実施形態の画像最適化モジュールは、病院情報システム(HIS)のコンポーネントとして既存のHISに統合される。いくつかの実施形態では、画像最適化モジュールは、HIS内の既存のコンポーネントに対する変更をわずかしかまたは全く必要としない仕方で、HISにシームレスに統合される。例えば、HISのPACSは、画像最適化モジュールが、PACSに保存され、PACSから取り出される画像を最適化する場合も、画像データベースとして動作し続ける。
【００４０】
図3は、いくつかの実施形態による、統合画像最適化モジュールを有するHISの例示的なアーキテクチャを示している。図示されるように、HIS 310は、MedServer 330と、PACSウェブサーバ340と、クエリオブジェクト350と、PACS 360と、いくつかの実施形態の画像最適化モジュール370とを含む。HIS 310は、PACS 360に投入される画像を獲得するために1つまたは複数の画像獲得デバイス320と、また表示用の画像を取り出すためにPACS 360にアクセスするクライアントデバイス325とインタフェースをとる。
【００４１】
画像獲得デバイス320は、病院の様々な病棟または部署内で使用される病院撮像デバイス(例えば、磁気共鳴映像法(MRI: Magnetic Resonance Imaging)デバイス、コンピュータ体軸断層撮影法(CAT: Computerized Axial Tomography)スキャンデバイスなど)を含む。これら様々な病棟または部署のいくつかの例は、放射線科、心臓病科、腫瘍科、歯科、外科、神経科、マンモグラフィ科、放射線治療科、眼科、整形外科、小児科、病理学科、獣医科を含む。画像獲得デバイス320は、単一のファイルフォーマットおよびネットワークプロトコル規格を使用して動作するように構成される。以下の説明は、HISを実施するのに選ばれた規格として、DICOM規格を使用する。しかし、任意のそのようなファイルフォーマットおよびネットワークプロトコル規格が、本明細書で説明される実施形態とともに使用できることは当業者には明らかであろう。したがって、デバイス320は、画像を生成してPACS 360に送る場合、画像をMedServer 330に転送する前に、DICOMファイルフォーマットに従って画像をフォーマットする。
【００４２】
MedServer 330は、いくつかの例のように、画像獲得デバイス320、クライアントデバイス325と、PACS 360および画像最適化モジュール370などのHISのバックエンドコンポーネントとの間のインタフェースを提供するHIS内のプライマリサーバである。いくつかの実施形態では、MedServer 330は、画像獲得デバイス320およびクライアントデバイス325に対する認証および/または権限付与機能を実行する。いくつかの実施形態では、MedServer 330は、画像獲得デバイス320、クライアントデバイス325、およびHISのバックエンドコンポーネントに対して、データを要求し、組織し、送信する。
【００４３】
具体的には、MedServer 330は、HIS 310に入ってくる様々なデータおよび要求を、HIS 310の適切なデータベース、データストレージ、または計算ユニットに回送する。例えば、MedServer 330は、新たに生成された画像を画像獲得デバイス320から受け取ったとき、その画像をPACS 360内に保存される新たに生成された画像として識別する。したがって、MedServer 330は、その画像を、PACS 360へのコンタクトポイントに相当するPACSウェブサーバ340またはクエリオブジェクト350に回送する。
【００４４】
いくつかの実施形態では、MedServer 330は、MedServer 330の機能を実施する様々なスクリプトを含む。例えば、MedServer 330は、PACS 360へのウェブベースのインタフェースを提供するPACSウェブサーバ340とインタフェースをとるための、ハイパーテキスト転送プロトコル(HTTP: Hyper Text Transfer Protocol)ベースのスクリプトを含む。MedServer 330は、PACS 360へのCOMインタフェースを提供するクエリオブジェクト350とインタフェースをとるための、コンポーネントオブジェクトモデル(COM: Component Object Model)ベースのスクリプトも含むことができる。クライアント325に渡す画像を圧縮するため、クライアント認証を実行するため、クライアント権限付与を実行するためなどに、他のスクリプトを実施することもできる。
【００４５】
1つまたは複数のそのようなスクリプトを変更することによって、画像最適化モジュール370をHISにシームレスに統合することができる。例えば、MedServer 330が、PACS 360内に保存される新たに生成された画像を画像獲得デバイス320から受け取る場合、保存するために画像がPACS 360に渡され、最適化のために画像最適化モジュール370にも渡されるように、MedServer 330の画像保存スクリプトを変更することができる。
【００４６】
同様に、MedServer 330が、画像を取り出すよう求める要求をクライアントから受け取る場合、最初に画像最適化モジュール370に問い合わせを行うように、MedServer 330の画像検索スクリプトを変更することができる。画像最適化モジュール370が、要求された画像を事前処理して、その最適化バージョンを生成してある場合、画像最適化モジュール370は、最適化画像をMedServer 330に返す。その後、画像検索スクリプトは、PACS 360に問い合わせを行うことなく、要求を発行したクライアントに最適化画像を返す。
【００４７】
事前処理画像が存在しない場合、画像最適化モジュール370は、要求された画像が事前処理されていないことをMedServer 330に通知する。いくつかの実施形態では、画像がPACS 360に最近入力された場合、または画像最適化モジュール370が最適化画像を生成していない画像設定を要求クライアントが有する場合に、事前処理画像が存在しないことがある。その場合、画像検索スクリプトは、使用されるPACSコンタクト(例えば、PACSウェブサーバ340またはクエリオブジェクト350)を決定する処理スレッドをMedServer 330において生成する。MedServer 330は、元の画像を取り出すためにPACS 360に問い合わせを行う。その後、元の画像は、以下のセクションで説明されるように、画像最適化モジュール370によってオンデマンドで最適化され、データベース380内に保存される。いくつかの実施形態では、画像検索スクリプトは、監視スレッドも生成する。監視スレッドは、要求された画像の最適化バージョンが利用可能になった時を決定するために、画像最適化モジュール370のデータベース380を継続的にチェックする。
【００４８】
監視スレッドが動作している間、PACS 360は、プラットフォーム依存フォーマットを含み、要求クライアントデバイス向けに最適化されていない元の画像を取り出す。元の画像は、画像が画像最適化モジュール370によってあらかじめ事前処理されているかどうかに関わりなく、最適化画像から得られる効率性の利益が実現され得るように、クライアント325またはMedServer 330に渡される前に、画像最適化モジュール370によってオンデマンドで処理される。画像最適化モジュール370は、1つまたは複数の画像最適化技法の実行を完了すると、最適化画像を用いてデータベース380を更新する。その後、MedServer 330の監視スレッドは、データベース380内の最適化画像を識別する。監視スレッドは、最適化画像を取り出し、最適化画像を要求クライアント325に転送する。
【００４９】
図4および図5は、いくつかの実施形態による、画像最適化モジュール370からクライアント要求画像を取り出すためにMedServer 330によって処理されるスクリプトの例示的な機能を提示している。具体的には、図4は、単一の画像スタディ(image study)を取り出すための機能を提示しており、一方、図5は、多数の画像を含むスタディリストを取り出すための機能を提示している。機能の各々は、DICOMクエリを発行するためのオブジェクト410または510を初期化する。機能の各々は、DICOMクエリの結果を取り出すためのXMLオブジェクト420または520も初期化する。XMLオブジェクトは、プラットフォーム独立フォーマットのクエリ結果を含む。
【００５０】
図3に示されたアーキテクチャが、HISにおいて本発明のいくつかの実施形態を実施するのに必要とされるコンポーネントの最低限の組を詳述したものであることは当業者には明らかであろう。したがって、HISは、図3に示されたものに加えて、追加的なコンポーネントを含むことができる。同様に、いくつかの実施形態の画像最適化モジュールは、様々な事前処理および最適化機能を実施するためのいくつかのコンポーネントを含む。
【００５１】
図6は、いくつかの実施形態の画像最適化モジュール610の様々なコンポーネントのうちのいくつかを示している。画像最適化モジュール610は、ファイルストア620と、最適化エンジン630と、1組のメッセージング待ち行列650と、ディスクマネージャ660と、1組のデータベース670とを含む。
【００５２】
ファイルストア620は、1組のデータベース670内に保存された画像最適化モジュール610の事前処理画像に対する識別子を保存する。いくつかの実施形態では、識別子は、事前処理画像のプラットフォーム独立ヘッダ情報を含む。いくつかの実施形態では、識別子は、1組のデータベース670内の画像へのポインタである。
【００５３】
例えば、ファイルストア620は、最適化画像を生成するために事前処理された2560×1980ピクセルの解像度を有する元の画像に関するヘッダまたはポインタを含む。最適化画像は、データベース670内に保存され、その中では、最適化画像は、800×600ピクセル解像度および640×480ピクセル解像度を有する。したがって、特定のデバイスが800×600ピクセルの表示解像度を有し、元の画像を要求した場合、MedServer 680は、特定のデバイス向けに最適化された事前処理画像が1組のデータベース670内に存在することを、ファイルストア620から決定することができる。いくつかの実施形態では、MedServer 680は、1組のデータベース670へのポインタを提供される。ポインタを使用して、MedServer 680は、適切な最適化画像を取り出す。いくつかの実施形態では、画像最適化モジュールは、ステータスがファイルストア620から決定されると、特定のデバイスにとって適切な最適化画像を、データベース670からMedServer 680に自動的に渡す。
【００５４】
最適化画像が存在しない解像度(例えば1280×768ピクセル)を要求デバイスが有する場合、ファイルストア620内に保存された事前処理画像のいずれか1つを使用すると、元の画像の画像品質は失われる。したがって、MedServer 680は、要求された画像の最適化画像が存在しないことを、ファイルストア620から決定する。その場合、MedServer 680は、クエリをPACS 690に再回送する。PACS 690は、元の画像を取り出す。最適化エンジン630は、取り出された元の画像を受け取り、画像のオンデマンド最適化を実行する。その後、最適化結果は、要求デバイスに渡される。加えて、最適化エンジン630は、その画像が後でまた要求された場合に画像最適化エンジン630がオンデマンド最適化を再び実行する必要がないように、最適化画像をデータベース670に保存する。
【００５５】
いくつかの実施形態では、最適化エンジン630によって実行される最適化は、1つまたは複数のXMLコンフィグレーションファイルに基づいて構成可能である。いくつかの実施形態では、コンフィグレーションは、最適化エンジン630用の様々な最適化モジュールを指定する。このようにして、コンフィグレーションファイルは、画像に適用される最適化を指定する。簡潔にするため、そのような最適化モジュールである2つのモジュール635および640だけが示されている。しかし、任意の数のさらなる最適化モジュールが、モジュール635および640に追加できること、またはモジュール635および640の代わりに使用できることは当業者には明らかであろう。例えば、いくつかの実施形態では、最適化エンジン630は、最適化画像を圧縮するための圧縮モジュールを含む。
【００５６】
様々な最適化モジュールを使用することによって、いくつかの実施形態の最適化エンジン630は、多数の画像処理パスを含む。各パスは、別のパスと並行して、ある画像最適化手順を実行することができる。このようにして、画像最適化モジュール610は、第１のパスに沿ってヘッダ解析モジュール635によって実行されるヘッダ操作と、第２のパスに沿って画像操作モジュール640によって実行される画像処理とを同時に実行することができる。
【００５７】
図7は、いくつかの実施形態による、最適化エンジン630の最適化モジュールによって実行されるプロセス700を提示している。プロセスは、DICOMフォーマットなど、プラットフォーム依存フォーマットでフォーマットされたヘッダを含む画像を(710において)受け取ることによって開始する。いくつかの実施形態では、ヘッダは、画像の符号化またはタイプ(例えば、ビットマップ、ジョイントフォトグラフィックエキスパートグループ(JPEG: Joint Photographic Experts Group)、グラフィックスインタチェンジフォーマット(GIF: Graphics Interchange Format)など)、画像の寸法または解像度、画像内容の量(例えばバイト単位のサイズ)、および他の説明的メタデータなど、画像についての説明的情報を提供する。ヘッダを復号できない場合、アプリケーションまたはクライアントデバイスは、画像を適切に表示することができない。
【００５８】
次に、プロセスは、DICOMファイルヘッダを事前処理して、XMLなどのプラットフォーム独立ファイルヘッダを生成する。このようにして、XML機能を有する任意のデバイスは、ファイルを解析することができ、したがって、画像が最初はDICOM規格に準拠してフォーマットされていたとしても、画像を再生することができる。いくつかの実施形態では、最適化エンジン630のヘッダ解析モジュール635は、ヘッダフォーマット変換を実行する。ヘッダフォーマット変換についてのより詳細な説明は、以下のセクションIIIにおいて提供される。
【００５９】
次に、プロセスは、1つまたは複数のさらなる最適化を実行する。例えば、プロセスは、画像データを事前処理して、(730において)元の画像データに基づいて1組のサイズ変更画像を生成する。いくつかの実施形態では、画像操作モジュール640は、1つまたは複数の異なる表示パラメータ(例えば、解像度、色深度など)向けに画像データを最適化するために、画像サイズ変更を実行する。いくつかの実施形態では、元の画像は、画像を要求する表示デバイスの表示解像度に一致するより低い解像度まで元の画像をダウンサンプリングすることによって、サイズ変更される。その場合、元の画像の代わりに、サイズ変更画像を転送するときは、デバイスにより少ないデータを転送しさえすればよい。加えて、ダウンサンプリングは、元の画像の寸法を縮小して、要求クライアントデバイスの表示設定の寸法に一致させるので、品質の低下を招かない。画像最適化についてのより詳細な説明は、以下のセクションIVにおいて提供される。
【００６０】
画像ヘッダが変換され、画像データが最適化されると、図6のディスクマネージャ660は、事前処理されたデータまたはオンデマンドで生成されたデータをファイルストア620内に保存する作業と、データベース670に投入する作業を課される。図8は、いくつかの実施形態による、ディスクマネージャ810を概念的に示している。ディスクマネージャ810は、ディレクトリモニタ820と、ドライバモニタ825と、ファイルインデックス840とを含む。
【００６１】
いくつかの実施形態では、ディレクトリモニタ820は、ドライブモニタ825と連携して、またはドライバモニタ825とは独立に、ファイルストア860のステータスを定期的にチェックする。具体的には、ディレクトリモニタ820は、ファイルストア860の使用量(例えばリソースレベルおよび利用レベル)が閾値に達したまたは超えた場合に、ファイルストア860のクリーンアップをトリガする。いくつかの実施形態では、ディレクトリモニタ820は、画像が更新、変更、またはPACSから削除されたことが検出された場合に、クリーンアップをトリガする。そのようなアクションによって、以前に事前処理されたすべてのデータは古いものとなり、それによって、画像最適化モジュールからそのような事前処理画像を削除することが必要となる。その後、画像最適化モジュールは、変更または更新画像に対して新しい1組の事前処理画像を生成しなければならない。いくつかの実施形態では、ディレクトリモニタ820は、1つまたは複数のフィルタおよびスクリプト865を利用して、監視およびクリーンアップを実行する。
【００６２】
いくつかの実施形態では、ディレクトリモニタ820は、最適化エンジンまたはMedServerから受け取った通知に基づいて、ファイルストア860のクリーンアップを実行する。いくつかの実施形態では、最適化エンジンまたはMedServerは、フィルタ865の1つまたは複数を使用してリソースを生成または変更するようファイルストア860に命令する。フィルタ865は、処理する画像またはファイルのファイル名および拡張子を識別する。フィルタの基準が満たされた場合、フィルタに関連付けられたスクリプトが実行される。スクリプトは、ファイル上で実行されるアクションを規定する。
【００６３】
ファイルインデックス840は、フォルダ、フォルダサイズ、ファイルサイズ、アクセス時間、ファイルなどのマップを含む。モニタ820および825は、最初スタートアップ時にインデックスを生成し、ファイルインデックス840は、メッセージが処理されるときに更新される。
【００６４】
図6を参照すると、様々なメッセージング待ち行列650は、メッセージが適切なモジュールによって処理されるまで、画像最適化モジュール610内を移動するメッセージを一時的に保持する。例えば、メッセージング待ち行列650は、ファイルストア620および他のデータベース670内に保存するために画像がディスクマネージャ660に渡される際、1組の事前処理結果を保持するために使用することができる。
【００６５】
いくつかの実施形態の画像最適化モジュールが、上で説明され、以下でさらに詳述される様々な事前処理および最適化機能を実行するための、メモリおよび処理リソースを有する、コンピュータなどの専用ハードウェアであることは当業者には明らかであろう。いくつかの実施形態では、いくつかの実施形態の画像最適化モジュールは、HISのハードウェアコンポーネントによって実行される1組のコンピュータ可読ソフトウェア命令を使用して定義される。このようにして、画像最適化モジュールは、HISの既存のコンポーネントと統合することができ、または新たに配備されるハードウェアとともにHIS内に組み込むことができる。例えば、いくつかの実施形態の画像最適化モジュールは、PACSに追加機能を提供するプラグインモジュールである。
【００６６】
III.画像ヘッダの事前処理
いくつかの実施形態では、画像最適化モジュールは、PACSの有用性を高める一方で、PACSの有用性の高まりに関連するコストを引き下げる。画像最適化モジュールがそのような利益を実現する1つの方法は、典型的なPACSに存在するプラットフォーム依存性を取り除くことによる。そのような依存性は、HISの医用画像用の共通で互換性のあるフォーマットを保証しようとする努力において一般に導入される。具体的には、これらの依存性は、画像ファイルを獲得し、生成する様々な異なる画像獲得デバイスと、獲得された画像ファイルにアクセスし、それを表示するクライアントデバイスとの間で、共通で互換性のあるフォーマットを保証する。DICOMは、HIS内の医用画像をフォーマットするための規格として出現した、プラットフォーム依存ファイルフォーマットの一例である。
【００６７】
DICOMフォーマットに従って符号化または復号を行うには、必要なDICOMライブラリを有する符号化または復号デバイスを必要とする。DICOMライブラリは、DICOMフォーマット画像ファイルを生成し、表示するための、DICOM画像ファイルフォーマットを定義する。DICOMライブラリは、1つのDICOM準拠デバイスから別のDICOM準拠デバイスにDICOMフォーマット画像ファイルを送受信するための、通信プロトコルも定義する。しかし、これらのプラットフォーム依存性は、医用画像およびPACSの使用を、DICOMライブラリを含む1組の専門DICOM準拠デバイスに制限する。これらのDICOM準拠デバイスは、保健医療提供者および病院が負担するコストを増加させる。具体的には、医療従事者は、ページャ、スマートフォン、またはPDAなど、病院内で通信を行うための1組のデバイスと、PACS内に保存されたプラットフォーム依存画像にアクセスするための別の1組のデバイスとを持ち運ぶ。これは、医療従事者が持ち運ぶ通信デバイスの多くが、DICOMプラットフォームをサポートしていないため、または通信デバイスの各々がDICOMプラットフォームをサポートできるようにするには、多額の使用許諾コストを招くためである。
【００６８】
いくつかの実施形態の画像最適化モジュールは、プラットフォーム依存ファイルフォーマットをプラットフォーム独立ファイルフォーマットで置き換えることによって、そのような専門デバイスの必要性を取り除く。具体的には、プラットフォーム依存性を取り除くことによって、医療従事者が通常持ち運ぶ通信デバイス(例えば、スマートフォン、PDAなど)は、もはやDICOMフォーマットのプラットフォーム依存性に準拠する必要はなく、したがって、もはやプラットフォーム依存フォーマットをサポートすることに関連する使用許諾コストを招く必要はない。さらに、デバイスは、DICOMライブラリを保存し、クライアントデバイス上でローカルにDICOMフォーマットを復号するのに必要とされる処理オーバヘッドおよびメモリオーバヘッドをもはや負担することはない。これは、任意の数のプラットフォーム独立デバイスが画像を表示し、PACSの機能にアクセスすることを可能にする。結果として、PACS内に保存される画像は、ほとんどの医療従事者がすでに所有する一般に利用可能な通信デバイスに変更またはアップグレードを施す必要なしに、そのようなデバイスを使用して医療従事者に配布できるので、医療保険提供者または病院が負担する総コストは低下する。
【００６９】
図9は、いくつかの実施形態による、クライアントデバイス上に表示するために、プラットフォーム依存フォーマットでフォーマットされた画像ファイルを、プラットフォーム独立フォーマットに変換するための事前処理プロセス900を提示している。プロセス900は、DICOMなど、プラットフォーム依存ファイルフォーマットに従ってフォーマットされた医用画像を(910において)受け取ることによって開始する。具体的には、ファイルフォーマットは、ファイルの内容および画像の仕様を記述するプラットフォーム依存フォーマットヘッダを含む。したがって、画像を適切に表示するには、クライアントデバイスまたはアプリケーションは、画像内容を決定するために、最初にヘッダを復号しなければならない。いくつかの実施形態では、画像がPACSによって受け取られたとき、または画像がMedServerによって受け取られたときに、プロセス900が開始し、具体的には、ステップ910が発生する。
【００７０】
プロセスは、フォーマットを定義し、符号化または復号する1つまたは複数のライブラリを使用して、プラットフォーム依存ファイルフォーマットを(920において)分析する。分析の一部として、プロセスは、関連する画像データについての説明的な情報を含む、ヘッダの様々な要素を識別する。上で述べられたように、これらのヘッダ要素は、画像タイプ、解像度、サイズなどを含むことができる。
【００７１】
プラットフォーム独立ファイルフォーマットを生成するため、プロセスは、プラットフォーム依存フォーマットヘッダと同一または類似の情報を含むプラットフォーム独立フォーマットヘッダを(930において)生成する。いくつかの実施形態では、プラットフォーム独立フォーマットは、画像用のXMLフォーマットヘッダを規定する。いくつかの実施形態では、プロセスは、同じ画像用にいくつかの異なるXMLフォーマットヘッダを(930において)生成する。そのようなフォーマットヘッダは各々、受け取った画像に対して生成されたまたは生成される異なるサイズ変更画像のアトリビュートに対応する。
【００７２】
プロセスは、結果のプラットフォーム独立ヘッダ情報を(940において)保存する。いくつかの実施形態は、画像データとは別に、図6のファイルストア620内にプラットフォーム独立ヘッダ情報を保存する。XMLヘッダは、対応する画像データを保存する1つまたは複数のデータベース670から実際の画像内容を識別し、取り出すためのポインタとして使用される。ファイルストア内にヘッダ情報だけを保存することによって、ヘッダ情報および画像内容を検索するのではなく、画像ヘッダ情報だけが検索されるので、ファイルストアに対するその後の検索は、より短い待ち時間で実行される。
【００７３】
図10は、本発明のいくつかの実施形態による、XMLフォーマットヘッダ1005に変換されたDICOMフォーマットヘッダの内容を示している。XMLフォーマットヘッダ1005は、ファイルストア620内に保存されるヘッダ情報を表している。図示されるように、データは、1組のXMLタグを用いて仕切られる。各タグは、画像についてのいくつかの説明的な情報を提供する。例えば、タグ1010は、画像がMRI脳スキャンであることを記述し、タグ1020は、画像が属する患者の名前を提供する。
【００７４】
XMLフォーマットヘッダ1005の利点は、画像内容を検索するために、強力で効率的なSQLクエリを使用できることである。反対に、DICOMフォーマットヘッダは、定評のあるSQL検索エンジンと比較した場合に性能が劣る独自仕様の検索エンジンを必要とする。さらに、XMLフォーマットヘッダ1005内の任意のタグを検索可能アトリビュートとして使用することができる。このようにして、カスタマイズされたクエリを1組の画像に対して実行できるように、PACSの機能が拡張されるが、他の方法では、DICOMファイルフォーマットでフォーマットされたデータを問い合わせるときに、そのようなカスタマイズされたクエリを利用することはできない。例えば、ユーザは、患者名タグ1020に基づいて特定の患者の画像を検索することができ、またより洗練されたクエリが指定でき、それによって、患者名タグ1020および検査日付タグ1030を使用して、特定の日付以降に生成された特定の患者名についての画像を問い合わせることができる。タグの任意の組み合わせを使用して、画像を識別するクエリを指定できることは当業者には明らかであろう。
【００７５】
図11は、DICOMフォーマットヘッダをXMLフォーマットヘッダに変換するための疑似コード1100を示している。疑似コードは、DICOMフォーマットヘッダの各ノードを辿るループ1110として動作し、ノードは、DICOMファイルフォーマット内の1組の仕切られたデータを指定する。疑似コードは、ノードから値表現(VR: value representation)を分析し、抽出する。いくつかの実施形態は、XMLフォーマット内において文字列として値表現を表す。いくつかの実施形態は、画像データを表す「OB」タイプなどのある種の値表現を省略する。
【００７６】
加えて、いくつかのDICOMヘッダノードは、シーケンスタグを含む。シーケンスタグは、他のタグ内にネストされるタグを表す。シーケンスタグを有する値表現を処理する場合、疑似コードは、値表現のシーケンスタグの番号を決定する。この値多重度(VM: value multiplicity)は、シーケンスタグの番号を指定する。したがって、これらのタグは、XML変換を実行するときに、一緒にグループ化される。図10に示されるように、タグ1045は、3の値多重度を有するシーケンスタグを表す。
【００７７】
いくつかの実施形態は、結果のXMLフォーマットヘッダを圧縮する。圧縮を実行することによって、クライアントデバイスに転送される情報の量が削減される。結果として、情報を転送するのによりわずかな帯域幅しか必要とされず、転送はより短い待ち時間で行われる。いくつかの実施形態では、クライアントは、画像を要求するときに、圧縮を要求する。例えば、ユーザは、画像を要求するときに、Z-Lib圧縮を要求することができる。図9〜図11および他の図は、DICOMフォーマットヘッダからXMLフォーマットヘッダへの変換に関して説明されたが、当該技法が、任意のプラットフォーム依存フォーマットからプラットフォーム独立フォーマットへの変換にも同様に適用されることは当業者には明らかであろう。
【００７８】
IV.画像の事前処理
いくつかの実施形態では、画像最適化モジュールは、クライアントデバイスに転送される画像内容を最適化することによって、PACSの有用性を高める。いくつかのそのような実施形態では、画像最適化モジュールは、クライアントデバイスの画像表示設定に基づいて画像をダウンサンプリングすることによって、画像内容を最適化する。そのようなダウンサンプリングは、画像の品質を低下させることなく画像サイズを縮小することによって、画像をサイズ変更する。例えば、640×480までダウンサンプリングおよびサイズ変更された解像度2560×1980を有する元の画像は、640×480の最大解像度を有する表示デバイス上に表示されたとき、品質低下を起こさない。
【００７９】
結果として、いくつかの実施形態の画像最適化モジュールは、PACSよりも効率的に画像内容を転送する。例えば、PACSは、元の画像の完全な1組のピクセルデータを使用して元の画像内容を送るが、画像最適化モジュールは、クライアントデバイスの表示能力に基づいて、クライアントデバイスに送られるピクセルデータの量を削減する。このようにして、他の方法では表示画像において除外される非本質的なピクセルデータは、必ずしもクライアントデバイスに送られるとは限らない。画像最適化モジュールは、クライアントデバイス上での画像品質に影響を与えることなく、よりわずかな画像データを転送する。したがって、画像最適化モジュールは、PACSと比べてより速く、より短い待ち時間で、画像をクライアントデバイスに転送する。
【００８０】
いくつかの実施形態によって実行される画像最適化のさらなる利点は、画像を表示するために、クライアントデバイスがよりわずかな処理しか行わなくてよいことである。第１に、よりわずかなピクセルデータが、クライアントデバイスに送られ、したがって、クライアントデバイスは、画像を表示するために処理すべきデータをよりわずかしかもたない。第２に、画像はクライアントデバイスの画面表示向けにすでに最適化されているので、クライアントデバイスは、画像を表示するために画像を再サンプリング(例えば画像解像度のダウンサンプリングまたはアップスケーリング)する必要がない。したがって、クライアントデバイスは、よりわずかな処理リソースおよびメモリリソースを使用して、より速く画像を表示することができる。これにより、あまり強力ではないデバイスであっても画像を表示できるようになる。
【００８１】
いくつかの実施形態では、画像最適化モジュールによって実行されるダウンサンプリング事前処理は、前のセクションにおいて説明されたヘッダ変換事前処理と併せて行われる。いくつかの他の実施形態では、ダウンサンプリングは、指定された間隔で動作するバッチプロセスである。
【００８２】
図12は、画像を最適化して画像をクライアントデバイスに効率的に転送するために、いくつかの実施形態の画像最適化モジュールによって実行されるプロセス1200を提示している。プロセス1200は、(1210において)画像を受け取ることによって開始する。いくつかの実施形態では、プロセスは、保存のために画像が画像獲得デバイスからPACSに転送されたときに、画像を受け取る。いくつかのそのような実施形態では、画像最適化は、画像最適化モジュールによって実行される事前処理の一部として行われる。いくつかの他の実施形態では、プロセスは、クライアントデバイスが要求するPACSからの画像検索の一部として、画像を受け取る。いくつかのそのような実施形態では、画像最適化は、画像転送の一部としてオンデマンドで行われる。
【００８３】
次に、プロセスは、生成される1つまたは複数のサイズ変更画像を定義する、1つまたは複数の画像設定を(1220において)識別する。いくつかの実施形態は、事前処理中に生成する、画像の1つまたは複数のダウンサンプリングバージョンを定義する、1つまたは複数の画像表示設定を事前決定する。加えて、画像最適化モジュールは、事前決定された設定とは異なる画像表示設定を有するクライアントデバイスによって送られた、画像を求める要求を識別した場合、いくつかの実施形態の画像最適化モジュールは、要求クライアントデバイスの特定の画像表示設定に基づいて、オンデマンドで画像表示設定を識別する。このようにして、いくつかの実施形態の画像最適化モジュールは、要求クライアントデバイスの特定の画像表示設定に従ってダウンサンプリングされた、オンデマンドダウンサンプリング画像を生成する。
【００８４】
1つまたは複数の画像設定を(1220において)識別した後、プロセスは、識別された設定に基づいてサイズ変更画像を生成するかどうかを(1230において)決定する。すべての識別された画像表示設定に対してサイズ変更画像を生成したとプロセスが(1230において)決定した場合、プロセスは終了する。それ以外の場合、プロセスは、対応するサイズ変更画像を生成するために、識別された画像表示設定を(1240において)選択する。次に、プロセスは、選択されたダウンサンプリング画像表示設定に基づいて、対応するサイズ変更画像を(1250において)生成する。
【００８５】
いくつかの実施形態では、プロセスは、付加的な画像最適化を実行する。そのような画像最適化技法の1つは、画像最適化モジュールからクライアントによりわずかなデータが転送されるように、画像データを圧縮することである。画像圧縮をステップ1250の画像ダウンサンプリングと組み合わせることによって、プロセスは、さらにいっそうの画像最適化利得を実現することができる。これらの最適化利得は、PACSからクライアントデバイスにダウンサンプリングも圧縮もされない元の画像を転送するのと比べた場合、帯域幅要件を低下させ、待ち時間をより短くする。したがって、圧縮は、その代償としてクライアントデバイス上でローカルに画像を伸張しなければならないが、画像がクライアントデバイスにより速く転送されることを可能にする。したがって、プロセスは、サイズ変更画像を圧縮するかどうかを(1260において)決定する。圧縮が実行されない場合、プロセスは、生成されたサイズ変更画像を(1280において)保存する。それ以外の場合、プロセスは、画像を(1270において)圧縮した後で、圧縮されたサイズ変更画像を(1280において)保存する。
【００８６】
いくつかの実施形態は、標準的な圧縮アルゴリズムを利用して、画像を圧縮する。例えば、いくつかの実施形態は、いくつかの例として、様々なレベルのJPEG圧縮、Z-Lib圧縮、ウェーブレット圧縮、またはPNG圧縮を利用する。いくつかの実施形態では、クライアントは、クライアントデバイスがサポートできる圧縮のタイプを指定し、画像最適化モジュールは、それに基づいて、圧縮を実行するかどうかを決定する。
【００８７】
いくつかの実施形態では、プロセスは、生成された画像を図6のデータベース670内に保存する。これらの画像へのポインタは、ファイルストア620において提供される。ポインタは、生成された画像のプラットフォーム独立ヘッダに関連付けられる。
【００８８】
図13は、事前処理された最適化画像をHISからクライアントデバイスに転送するためのデータフローを概念的に示している。簡潔にするため、この図は、図6において提示されたHISシステムアーキテクチャの簡略バージョンを示している。加えて、データフローに含まれるコンポーネントに限って、実線を用いて示されている。これらのコンポーネントは、クライアントデバイス1310と、MedServer 1320と、いくつかの実施形態の画像最適化モジュール1330と、画像最適化モジュール1330のファイルストア1340と、画像最適化モジュール1330の少なくとも1つのデータベース1350とを含む。
【００８９】
クライアントデバイス1310は、HISから画像内容を取り出すために、丸数字1によって表される初期要求を発行する。MedServer 1320は、画像要求を受け取る。PACSに問い合わせを行って、クライアントデバイス1310上での表示向けに最適化されていない元の画像を取り出す代わりに、MedServer 1320は、画像最適化モジュール1330に向けて要求を発行する。具体的には、要求は、画像最適化モジュール1330のファイルストア1340に渡る。
【００９０】
画像最適化モジュール1330は、要求を発行したクライアントデバイス1310の画像表示設定を識別する。これらの識別されたパラメータに基づいて、画像最適化モジュール1330は、クライアントデバイス1310上での表示向けに最適化された要求画像の事前処理バージョンに対応する、ファイルストア1340内のヘッダを識別する。具体的には、画像最適化モジュール1330は、識別されたヘッダをデータベース1350へのポインタとして利用する。その後、画像最適化モジュール1330は、識別されたヘッダに対応する画像データをデータベース1350から取り出す。その後、画像最適化モジュールは、最適化画像をMedServer 1320に渡す。MedServer 1320は、最適化画像を受け取り、最適化画像をクライアント1310に転送する。
【００９１】
図14は、オンデマンドで最適化された画像をHISからクライアントデバイスに転送するためのデータフローを概念的に示している。以前と同様に、クライアントデバイス1410は、画像検索プロセスを開始するために、MedServer 1420に向けてクエリを発行する。MedServer 1420もやはり、画像の最適化バージョンが事前処理されているかどうかを決定するために、画像最適化モジュール1430に向けてクエリを発行する。しかし、このシナリオにおいては、ファイルストア1440は、最適化画像が事前処理されていないことを示す、必要なポインタ情報を含んでいない。したがって、画像最適化モジュール1430は、画像の最適化バージョンが存在しないことをMedServer 1420に通知する。事前決定された1組の画像表示設定の中にない、クライアントデバイスのある画像表示設定に対しては、最適化画像が存在しないことがある。オンデマンド画像最適化プロセスを必要とする他の様々な理由が存在し得ることは当業者には明らかであろう。
【００９２】
その後、MedServer 1420は、PACSウェブサーバ1455またはクエリオブジェクト1460を使用して、要求をPACS 1450に転送する。PACS 1450は、いずれか特定のクライアントデバイス上での表示向けに最適化されていない画像の元のバージョンを取り出す。加えて、多くの場合、画像の元のバージョンは、プラットフォーム依存ヘッダ情報とともに保存される。したがって、最適化エンジン1470が、PACS 1450からの画像の取り出しを識別する。最適化エンジン1470は、クライアントデバイス1410に転送する前に画像を最適化すべきことも識別する。その後、最適化エンジンは、オンデマンド画像最適化プロセスを実行する。
【００９３】
いくつかの実施形態では、オンデマンド最適化は、プラットフォーム依存からプラットフォーム独立へのヘッダ変換を実行し、画像をダウンサンプリングし、および/またはデータ圧縮を実行する。いくつかの実施形態では、データ圧縮は、変換されたヘッダ、元の画像内容、ダウンサンプリングされた画像内容、変換されたヘッダと元の画像内容、または変換されたヘッダとダウンサンプリングされた画像内容を圧縮することを含む。
【００９４】
その後、最適化エンジン1470は、ファイルストア1440およびデータベース1490内に最適化画像を保存するための十分なスペースが存在することを保証するために、ディスクマネージャ1480に通知する。完了すると、最適化画像情報は、ファイルストア1440およびデータベース1490内で待ち行列に入れられ、最適化画像は、画像最適化モジュール1430からMedServer 1420に転送される。その後、MedServer 1420は、表示するために最適化画像をクライアントデバイス1410に回送する。
【００９５】
V.コンピュータシステム
上で説明されたコンポーネント(例えば、MedServer、画像最適化モジュール、最適化エンジンなど)の多くは、(コンピュータ可読媒体とも呼ばれる)機械可読媒体上に記録された1組の命令として指定されるソフトウェアプロセスを通して、上で説明された機能の一部または全部を実施する。これらの命令は、1つまたは複数のコンピューティング要素(プロセッサまたはASICおよびFPGAなどの他のコンピューティング要素)によって実行された場合、(1つまたは複数の)コンピューティング要素に命令内で指示されたアクションを実行させる。コンピュータは、その最も広い意味で解釈され、プロセッサを有する任意の電子デバイスを含むことができる。コンピュータ可読媒体の例は、CD-ROM、フラッシュドライブ、RAMチップ、ハードドライブ、EPROMなどを含むが、これらに限定されない。
【００９６】
本明細書では、「ソフトウェア」という用語は、その最も広い意味で解釈される。ソフトウェアは、リードオンリメモリ内に存在するファームウェア、またはプロセッサによる処理のためにメモリ内に読み込むことができる磁気ストレージ内に保存されたアプリケーションを含むことができる。またいくつかの実施形態では、多数のソフトウェア発明は、個々のソフトウェア発明を維持しながら、より大きなプログラムの下位区分として実施することができる。いくつかの実施形態では、多数のソフトウェア発明は、別個のプログラムとして実施することもできる。最後に、ここで説明されるソフトウェア発明を一緒に実施する別個のプログラムの任意の組み合わせも、本発明の範囲内に存在する。
【００９７】
図15は、本発明のいくつかの実施形態がそれを用いて実施されるコンピュータシステムを示している。そのようなコンピュータシステムは、様々なタイプのコンピュータ可読媒体と、様々な他のタイプのコンピュータ可読媒体用のインタフェースとを含む。コンピュータシステム1500は、バス1505と、プロセッサ1510と、システムメモリ1515と、リードオンリメモリ1520と、永久ストレージデバイス1525と、入力デバイス1530と、出力デバイス1535とを含む。
【００９８】
バス1505は、コンピュータシステム1500の多くの内部デバイスを通信可能に接続する、すべてのシステムバス、周辺バス、およびチップセットバスを一括して表している。例えば、バス1505は、プロセッサ1510を、リードオンリメモリ1520、システムメモリ1515、および永久ストレージデバイス1525と通信可能に接続する。これらの様々なメモリユニットから、プロセッサ1510は、本発明のプロセスを実行するために、実行する命令と、処理するデータとを取り出す。
【００９９】
リードオンリメモリ(ROM)1520は、プロセッサ1510およびコンピュータシステムの他のモジュールによって必要とされる、静的データと、命令とを保存する。他方、永久ストレージデバイス1525は、読み書き可能なメモリデバイスである。このデバイスは、コンピュータシステム1500がオフになった場合にも命令およびデータを保存する不揮発性メモリユニットである。本発明のいくつかの実施形態は、永久ストレージデバイス1525として大容量ストレージデバイス(磁気ディスクまたは光ディスク、および対応するディスクドライブなど)を使用する。
【０１００】
他の実施形態は、永久ストレージデバイスとして着脱可能ストレージデバイス(フロッピディスク、フラッシュドライブ、またはZIP(登録商標)ディスク、および対応するディスクドライブなど)を使用する。永久ストレージデバイス1525と同様に、システムメモリ1515は、読み書き可能なメモリデバイスである。しかし、ストレージデバイス1525と異なり、システムメモリは、ランダムアクセスメモリ(RAM)などの揮発性の読み書き可能なメモリである。システムメモリは、プロセッサが実行時に必要とする命令およびデータのいくつかを保存する。いくつかの実施形態では、本発明のプロセスは、システムメモリ1515、永久ストレージデバイス1525、および/またはリードオンリメモリ1520内に保存される。
【０１０１】
バス1505は、入力デバイス1530および出力デバイス1535にも接続する。入力デバイスは、ユーザが、コンピュータシステムに情報を伝達し、コマンドを選択することを可能にする。入力デバイス1530は、英数字キーボードと、ポインティングデバイス(「カーソル制御デバイス」とも呼ばれる)とを含む。入力デバイス1530は、オーディオ入力デバイス(例えば、マイクロフォン、MIDI楽器など)も含む。出力デバイス1535は、コンピュータシステムによって生成された画像を表示する。例えば、これらのデバイスは、GUIを表示する。出力デバイスは、プリンタと、ブラウン管(CRT)または液晶ディスプレイ(LCD)などの表示デバイスとを含む。
【０１０２】
最後に、図15に示されるように、バス1505は、ネットワークアダプタ(図示されず)を介してコンピュータ1500をネットワーク1565にも結合する。このようにして、コンピュータは、(ローカルエリアネットワーク(「LAN」)、ワイドエリアネットワーク(「WAN」)、もしくはイントラネットなど)コンピュータのネットワークの一部、またはインターネットなど、複数のネットワークにおけるネットワークの一部とすることができる。
【０１０３】
上で言及されたように、コンピュータシステム1500は、様々な異なるコンピュータ可読媒体の1つまたは複数を含むことができる。そのようなコンピュータ可読媒体のいくつかの例は、RAM、ROM、リードオンリコンパクトディスク(CD-ROM)、記録可能コンパクトディスク(CD-R)、書換可能コンパクトディスク(CD-RW)、リードオンリデジタル多用途ディスク(例えば、DVD-ROM、デュアルレイヤDVD-ROM)、様々な記録可能/書換可能DVD(例えば、DVD-RAM、DVD-RW、DVD+RWなど)、フラッシュメモリ(例えば、SDカード、ミニSDカード、マイクロSDカードなど)、磁気および/またはソリッドステートハードドライブ、ZIP(登録商標)ディスク、リードオンリーblu-rayディスクおよび記録可能blu-rayディスク、他の任意の光媒体または磁気媒体、ならびにフロッピディスクを含む。
【０１０４】
コンピュータシステム1500のコンポーネントのいずれかまたはすべてが本発明とともに使用できることを当業者であれば理解されよう。例えば、図15に関して説明されたコンピュータシステムのコンポーネントの一部または全部は、上で説明された画像最適化モジュール、MedServer、最適化エンジンなどのいくつかの実施形態を構成する。さらに、他の任意のシステム構成も本発明または本発明のコンポーネントとともに使用できることを当業者であれば理解されよう。したがって、本発明は上記の例示的な詳細によって限定されるのではなく、むしろ添付の特許請求の範囲によって確定されることを当業者であれば理解されよう。
【符号の説明】
【０１０５】
110 DICOM非準拠クライアント
120 DICOM準拠クライアント
130 画像最適化モジュール
140 PACS
150 DICOMフォーマットヘッダ
160 XMLフォーマットヘッダ
210 クライアント表示デバイス
220 クライアント表示デバイス
230 クライアント表示デバイス
240 クライアント表示デバイス
250 画像最適化モジュール
260 PACS
270 元の画像
280 サイズ変更画像
285 サイズ変更画像
290 サイズ変更画像
310 HIS
320 画像獲得デバイス
325 クライアントデバイス
330 MedServer
340 PACSウェブサーバ
350 クエリオブジェクト
360 PACS
370 画像最適化モジュール
380 データベース
410 オブジェクト
420 XMLオブジェクト
510 オブジェクト
520 XMLオブジェクト
610 画像最適化モジュール
620 ファイルストア
630 最適化エンジン
635 ヘッダ解析モジュール
640 画像操作モジュール
650 メッセージング待ち行列
660 ディスクマネージャ
670 データベース
680 MedServer
690 PACS
810 ディスクマネージャ
820 ディレクトリモニタ
825 ドライブモニタ
840 ファイルインデックス
860 ファイルストア
865 フィルタおよびスクリプト
1005 XMLフォーマットヘッダ
1010 タグ
1020 タグ
1030 タグ
1045 タグ
1100 疑似コード
1110 ループ
1310 クライアントデバイス
1320 MedServer
1330 画像最適化モジュール
1340 ファイルストア
1350 データベース
1410 クライアントデバイス
1420 MedServer
1430 画像最適化モジュール
1440 ファイルストア
1450 PACS
1455 PACSウェブサーバ
1460 クエリオブジェクト
1470 最適化エンジン
1480 ディスクマネージャ
1490 データベース
1500 コンピュータシステム
1505 バス
1510 プロセッサ
1515 システムメモリ
1520 リードオンリメモリ
1525 永久ストレージデバイス
1530 入力デバイス
1535 出力デバイス
【特許請求の範囲】
【請求項１】
医用画像を効率的に転送するための方法であって、
第１フォーマットに準拠したデバイスによってアクセス可能な、画像保管通信システム(PACS)の第１のプラットフォーム依存フォーマットで医用画像を受信するステップと、
前記医用画像を、前記第１フォーマットから、第１フォーマットに準拠していないデバイス上に表示するための、前記第１フォーマットを復号した内容を含む第２フォーマットに変換するステップと、
表示するために前記変換された医用画像を前記デバイスに渡すステップと
を具備し、
前記第１フォーマットに準拠したデバイスは、前記第１フォーマットを復号するためのプラットフォーム依存リソースを含むことを特徴とする方法。
【請求項２】
前記医用画像は、画像データと、識別情報と、を含み、
前記識別情報は、前記第１フォーマットであり、
前記医用画像を変換するステップは、前記第２フォーマットでの前記識別情報を生成するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記変換された医用画像を渡すステップは、前記医用画像に関連する前記画像データおよび前記第２フォーマットでの前記識別情報を、前記デバイスに渡すステップを含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記変換された医用画像を渡すステップは、前記医用画像を渡す前に、前記第１フォーマットでの前記識別情報を前記第２フォーマットでの前記識別情報で置き換えるステップを含むことを特徴とする請求項２に記載の方法。
【請求項５】
前記第１フォーマットに準拠していないデバイスは、前記第１フォーマットを復号するための前記プラットフォーム依存リソースを含まないことを特徴とする請求項１に記載の方法。
【請求項６】
前記第１フォーマットに準拠していないデバイスは、前記デバイスに渡される前記変換された画像を表示するための標準的なブラウザを具備することを特徴とする請求項１に記載の方法。
【請求項７】
前記第１フォーマットに準拠していないデバイスは、前記デバイスに渡される前記変換された画像を表示するための標準的な画像表示アプリケーションを具備することを特徴とする請求項１に記載の方法。
【請求項８】
前記第１フォーマットは、医用デジタル画像処理および通信(DICOM)フォーマットであることを特徴とする請求項１に記載の方法。
【請求項９】
前記第２フォーマットは、拡張マークアップ言語(XML)フォーマットであることを特徴とする請求項８に記載の方法。
【請求項１０】
前記第１フォーマットの前記医用画像は、画像データと、前記第１フォーマットに従って符号化された前記画像データに関連する識別情報と、を含み、
前記医用画像を渡すステップは、前記医用画像の画像データと、前記第２フォーマットでの前記識別情報の解析されたサブセットと、を渡すステップを含み、
前記渡すステップは、前記第１のプラットフォーム依存フォーマットを使用して前記画像データおよび前記識別情報を渡すよりも少ないデータを渡すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
複数のデジタル画像をプラットフォーム依存の第１フォーマットで格納するための画像ストアと、
前記デジタル画像を前記画像ストアから複数のデバイスに、少なくとも1つのプラットフォーム独立の第２フォーマットで転送するために、前記画像ストアに通信可能に結合される画像最適化デバイスと、
を含み、
前記複数のデバイスは、前記第１フォーマットを処理できないことを特徴とするシステム。
【請求項１２】
前記画像最適化デバイスは、前記デジタル画像を特定デバイスに最適に転送するために、前記特定デバイスの仕様に基づいて、デジタル画像の内容を変更することにさらに関することを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記特定デバイスの前記仕様は、表示解像度を定義し、
前記デジタル画像の内容を変更することは、前記デジタル画像を前記特定デバイスに転送する前に、前記デジタル画像の解像度を前記特定デバイスの前記表示解像度までダウンサンプリングすることを含むことを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記デジタル画像の内容を変更することは、前記デジタル画像を前記特定デバイスに転送する前に、前記デジタル画像を圧縮することをさらに含むことを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記複数のデバイス、前記画像ストア、および前記画像最適化デバイスに通信可能に結合されたサーバを具備し、
前記サーバは、前記デバイスから受け取った新しい画像を、保存のために前記画像ストアに渡し、
前記画像最適化デバイスは、事前処理を行い、
前記画像最適化デバイスは、前記新しい画像が前記画像ストアに保存されるときに、前記新しい画像の前記プラットフォーム依存の第１フォーマットを前記プラットフォーム独立の第２フォーマットに変換することによって新しい画像を事前処理することを特徴とする請求項１１に記載のシステム。
【請求項１６】
前記サーバは、さらに、前記画像ストア内に保存された前記デジタル画像にアクセスすることを求める前記複数のデバイスからの要求を処理し、
前記サーバは、前記デジタル画像が前記画像最適化デバイスによって事前処理されていない場合には、前記デジタル画像の前記第１フォーマットを前記第２フォーマットに変換するように前記画像最適化デバイスに指示することによって、デジタル画像を求める要求を処理することを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記画像ストアは、保健医療提供者の画像保管通信システム(PACS)であることを特徴とする請求項１１に記載のシステム。
【請求項１８】
前記プラットフォーム依存の第１フォーマットは、医用デジタル画像処理および通信(DICOM)フォーマットであることを特徴とする請求項１１に記載のシステム。
【請求項１９】
前記プラットフォーム独立の第２フォーマットは、拡張マークアップ言語(XML)フォーマットであることを特徴とする請求項１１に記載のシステム。
【請求項２０】
各医用画像の単一のインスタンスを保存する画像保管通信システム(PACS)から、複数の表示設定を使用して前記医用画像を表示するために複数のデバイスに医用画像を効率的に転送するための方法であって、
前記PACS内に保存するために前記医用画像を受信するステップと、
前記医用画像を表示する前記複数のデバイスの画像設定に対応する複数の画像設定を識別するステップと、
前記識別された画像設定に基づいて、受け取った各医用画像の1組のサイズ変更画像を生成するステップと、
識別された各画像設定に対して、前記識別された画像設定に基づいて、受信したそれぞれの医用画像のサイズ変更画像を生成するステップと、
前記デバイスに渡される画像データを削減するために、医用画像のサイズ変更画像を、前記サイズ変更画像の画像設定に対応する画像設定を有するデバイスに渡すステップと、
を含むことを特徴とする方法。
【請求項１】
医用画像を効率的に転送するための方法であって、
第１フォーマットに準拠したデバイスによってアクセス可能な、画像保管通信システム(PACS)の第１のプラットフォーム依存フォーマットで医用画像を受信するステップと、
前記医用画像を、前記第１フォーマットから、第１フォーマットに準拠していないデバイス上に表示するための、前記第１フォーマットを復号した内容を含む第２フォーマットに変換するステップと、
表示するために前記変換された医用画像を前記デバイスに渡すステップと
を具備し、
前記第１フォーマットに準拠したデバイスは、前記第１フォーマットを復号するためのプラットフォーム依存リソースを含むことを特徴とする方法。
【請求項２】
前記医用画像は、画像データと、識別情報と、を含み、
前記識別情報は、前記第１フォーマットであり、
前記医用画像を変換するステップは、前記第２フォーマットでの前記識別情報を生成するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記変換された医用画像を渡すステップは、前記医用画像に関連する前記画像データおよび前記第２フォーマットでの前記識別情報を、前記デバイスに渡すステップを含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記変換された医用画像を渡すステップは、前記医用画像を渡す前に、前記第１フォーマットでの前記識別情報を前記第２フォーマットでの前記識別情報で置き換えるステップを含むことを特徴とする請求項２に記載の方法。
【請求項５】
前記第１フォーマットに準拠していないデバイスは、前記第１フォーマットを復号するための前記プラットフォーム依存リソースを含まないことを特徴とする請求項１に記載の方法。
【請求項６】
前記第１フォーマットに準拠していないデバイスは、前記デバイスに渡される前記変換された画像を表示するための標準的なブラウザを具備することを特徴とする請求項１に記載の方法。
【請求項７】
前記第１フォーマットに準拠していないデバイスは、前記デバイスに渡される前記変換された画像を表示するための標準的な画像表示アプリケーションを具備することを特徴とする請求項１に記載の方法。
【請求項８】
前記第１フォーマットは、医用デジタル画像処理および通信(DICOM)フォーマットであることを特徴とする請求項１に記載の方法。
【請求項９】
前記第２フォーマットは、拡張マークアップ言語(XML)フォーマットであることを特徴とする請求項８に記載の方法。
【請求項１０】
前記第１フォーマットの前記医用画像は、画像データと、前記第１フォーマットに従って符号化された前記画像データに関連する識別情報と、を含み、
前記医用画像を渡すステップは、前記医用画像の画像データと、前記第２フォーマットでの前記識別情報の解析されたサブセットと、を渡すステップを含み、
前記渡すステップは、前記第１のプラットフォーム依存フォーマットを使用して前記画像データおよび前記識別情報を渡すよりも少ないデータを渡すステップを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
複数のデジタル画像をプラットフォーム依存の第１フォーマットで格納するための画像ストアと、
前記デジタル画像を前記画像ストアから複数のデバイスに、少なくとも1つのプラットフォーム独立の第２フォーマットで転送するために、前記画像ストアに通信可能に結合される画像最適化デバイスと、
を含み、
前記複数のデバイスは、前記第１フォーマットを処理できないことを特徴とするシステム。
【請求項１２】
前記画像最適化デバイスは、前記デジタル画像を特定デバイスに最適に転送するために、前記特定デバイスの仕様に基づいて、デジタル画像の内容を変更することにさらに関することを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記特定デバイスの前記仕様は、表示解像度を定義し、
前記デジタル画像の内容を変更することは、前記デジタル画像を前記特定デバイスに転送する前に、前記デジタル画像の解像度を前記特定デバイスの前記表示解像度までダウンサンプリングすることを含むことを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記デジタル画像の内容を変更することは、前記デジタル画像を前記特定デバイスに転送する前に、前記デジタル画像を圧縮することをさらに含むことを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記複数のデバイス、前記画像ストア、および前記画像最適化デバイスに通信可能に結合されたサーバを具備し、
前記サーバは、前記デバイスから受け取った新しい画像を、保存のために前記画像ストアに渡し、
前記画像最適化デバイスは、事前処理を行い、
前記画像最適化デバイスは、前記新しい画像が前記画像ストアに保存されるときに、前記新しい画像の前記プラットフォーム依存の第１フォーマットを前記プラットフォーム独立の第２フォーマットに変換することによって新しい画像を事前処理することを特徴とする請求項１１に記載のシステム。
【請求項１６】
前記サーバは、さらに、前記画像ストア内に保存された前記デジタル画像にアクセスすることを求める前記複数のデバイスからの要求を処理し、
前記サーバは、前記デジタル画像が前記画像最適化デバイスによって事前処理されていない場合には、前記デジタル画像の前記第１フォーマットを前記第２フォーマットに変換するように前記画像最適化デバイスに指示することによって、デジタル画像を求める要求を処理することを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記画像ストアは、保健医療提供者の画像保管通信システム(PACS)であることを特徴とする請求項１１に記載のシステム。
【請求項１８】
前記プラットフォーム依存の第１フォーマットは、医用デジタル画像処理および通信(DICOM)フォーマットであることを特徴とする請求項１１に記載のシステム。
【請求項１９】
前記プラットフォーム独立の第２フォーマットは、拡張マークアップ言語(XML)フォーマットであることを特徴とする請求項１１に記載のシステム。
【請求項２０】
各医用画像の単一のインスタンスを保存する画像保管通信システム(PACS)から、複数の表示設定を使用して前記医用画像を表示するために複数のデバイスに医用画像を効率的に転送するための方法であって、
前記PACS内に保存するために前記医用画像を受信するステップと、
前記医用画像を表示する前記複数のデバイスの画像設定に対応する複数の画像設定を識別するステップと、
前記識別された画像設定に基づいて、受け取った各医用画像の1組のサイズ変更画像を生成するステップと、
識別された各画像設定に対して、前記識別された画像設定に基づいて、受信したそれぞれの医用画像のサイズ変更画像を生成するステップと、
前記デバイスに渡される画像データを削減するために、医用画像のサイズ変更画像を、前記サイズ変更画像の画像設定に対応する画像設定を有するデバイスに渡すステップと、
を含むことを特徴とする方法。
【図１】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【公開番号】特開２０１０−２３４０５３（Ｐ２０１０−２３４０５３Ａ）
【公開日】平成２２年１０月２１日（２０１０．１０．２１）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１０−７５４１６（Ｐ２０１０−７５４１６）
【出願日】平成２２年３月２９日（２０１０．３．２９）
【出願人】（５９２１３０６９９）ザ リージェンツ オブ ザ ユニバーシティ オブ カリフォルニア (364)
【氏名又は名称原語表記】Ｔｈｅ Ｒｅｇｅｎｔｓ ｏｆ Ｔｈｅ Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｃａｌｉｆｏｒｎｉａ
【Ｆターム（参考）】
【公開日】平成２２年１０月２１日（２０１０．１０．２１）
【国際特許分類】
【出願番号】特願２０１０−７５４１６（Ｐ２０１０−７５４１６）
【出願日】平成２２年３月２９日（２０１０．３．２９）
【出願人】（５９２１３０６９９）ザ リージェンツ オブ ザ ユニバーシティ オブ カリフォルニア (364)
【氏名又は名称原語表記】Ｔｈｅ Ｒｅｇｅｎｔｓ ｏｆ Ｔｈｅ Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｃａｌｉｆｏｒｎｉａ
【Ｆターム（参考）】
[ Back to top ]