JP6313020B2 - システム、コンピュータ可読記憶媒体及び方法 - Google Patents

システム、コンピュータ可読記憶媒体及び方法 Download PDF

Info

Publication number
JP6313020B2
JP6313020B2 JP2013237660A JP2013237660A JP6313020B2 JP 6313020 B2 JP6313020 B2 JP 6313020B2 JP 2013237660 A JP2013237660 A JP 2013237660A JP 2013237660 A JP2013237660 A JP 2013237660A JP 6313020 B2 JP6313020 B2 JP 6313020B2
Authority
JP
Japan
Prior art keywords
image
data
viewer
image content
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2013237660A
Other languages
English (en)
Other versions
JP2014102835A (ja
Inventor
ジェイソン・ディーター・クロッツァー
プリヤ・バルヴァント・パデイト
エリック・トッド・ジェスター
ヴィジェイ・クマール・レッディー・アーラガダ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
General Electric Co
Original Assignee
General Electric Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by General Electric Co filed Critical General Electric Co
Publication of JP2014102835A publication Critical patent/JP2014102835A/ja
Application granted granted Critical
Publication of JP6313020B2 publication Critical patent/JP6313020B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9577—Optimising the visualization of content, e.g. distillation of HTML documents
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content

Description

本発明は、表示用の画像コンテンツの転送を容易にするシステムに関する。
デジタルイメージングの勃興以前、患者の画像は、フィルムに「印刷」されていた。フィルムは「掛けられ」て、放射線科医が読影し、レポートを口述する。レポートは、事務職員から医学記録転写士まで、様々な人々により文字起こしされ、依頼元の内科医へと郵送やファックスにて送られていた。重大な結果は、電話や携帯無線呼出器で伝達され、稼働統計は、書面による報告書およびスプレッドシートで管理されていた。
放射線医学情報システムが市販されると、その最初に市販されたソリューションが、放射線科医および放射線科の要求に答えることになった。そのソリューションには、放射線医学情報システム（ＲＩＳ）や口述筆記システムがあった。ＲＩＳシステムは、依頼、スケジューリング、患者および管理者への報告処理を管理していたが、放射線科医は、依然としてフィルムで読影していた。
モダリティが、取得装置に接続したワークステーション上に画像をデジタル表示するように対応するようになると、画像保管通信システム（ＰＡＣＳ）が市販されるようになった。これにより、画像が集中的に格納されて、放射線科医に、ネットワーク接続されたコンピュータモニタで調査対象を読むためのツールが提供され、このツールが、フィルムおよびモダリティワークステーションの双方に取って代わった。
次第に、市場の要求は、専門の放射線科医のワークフローに対応することから、企業および地域の開かれた動的な要求に対応するように発展してきた。業者団体は、診断を向上させる先端技術への要求に対処するシステム、提供者と組織との間で画像を共有するシステム、放射線科医、内科医および患者をケアするチーム間の協力を支援するシステム、重大な結果を確実に報告するようにするとともに増大する記憶容量の要件を管理するシステムを追加してきた。これらは異質であることが多く、相互運用の有無も含めた最良の組み合わせをとると、コストが増加するとともに生産性が低下する。
ある種の実施例では、医療画像データをゼロフットプリントで視認するシステムおよび方法が提供される。
ある種の実施例により、クライアント装置に特別な構成がなくとも、画像コンテンツをレンダリングしてクライアント装置に提供する表示パイプラインを含み、クライアントブラウザによって、画像コンテンツを表示するとともにこのコンテンツの操作を容易にするゼロフットプリント医療イメージビューアを含むシステムが提供される。また、実施例のシステムは、画像コンテンツを記憶部から取得して、画像コンテンツを格納フォーマットからブラウザ適合フォーマットへ変換する中段サーバをも含む。ゼロフットプリント医療イメージビューアは、画像コンテンツを中段サーバから取得する第１のデータマネージャを含み、実施例の中段サーバは、画像コンテンツを取得して、画像コンテンツを、格納フォーマットからブラウザ適合フォーマットへフォーマットする第２のデータマネージャを含み、第２のデータマネージャは、第１のデータマネージャと通信して、表示用の画像コンテンツの転送を容易にする。
ある種の実施例により、プロセッサにより実行されるコンピュータプログラムコードを含む有形のコンピュータ可読記憶媒体が提供される。コンピュータプログラムコードは、実行されると、ゼロフットプリント視認システムを実現する。実施例のシステムは、クライアント装置に特別な構成がなくとも、画像コンテンツをレンダリングしてクライアント装置に提供する表示パイプラインを含み、クライアントブラウザによって、画像コンテンツを表示するとともにこのコンテンツの操作を容易にするゼロフットプリント医療画像ビューアを含む。また、実施例のシステムは、画像コンテンツを記憶部から取得して、画像コンテンツを格納フォーマットからブラウザ適合フォーマットへ変換する中段サーバをも含む。実施例のゼロフットプリント医療画像ビューアは、画像コンテンツを中段サーバから取得する第１のデータマネージャを含み、実施例の中段サーバは、画像コンテンツを取得して、画像コンテンツを、格納フォーマットからブラウザ適合フォーマットへフォーマットする第２のデータマネージャを含み、第２のデータマネージャは、第１のデータマネージャと通信して、表示用の画像コンテンツの転送を容易にする。
ある種の実施例により、ゼロフットプリントビューアでリクエストを受信し、クライアント装置上のクライアントブラウザにて画像調査対象を起動するステップであって、ゼロフットプリントビューアは、クライアント装置に特別な構成がなくとも、画像調査対象中の画像コンテンツをレンダリングしてクライアント装置に提供する表示パイプラインを含み、クライアントブラウザによって、画像コンテンツを表示するとともに画像コンテンツの操作を容易にするステップを含む方法が提供される。実施形態の方法は、リクエストされた画像コンテンツを、記憶部から中段サーバを介して取得するステップを含む。実施形態の方法は、中段サーバにより、画像コンテンツを、格納フォーマットからブラウザ適合フォーマットへ変換するステップを含む。実施形態の方法は、変換された画像コンテンツを、ゼロフットプリントビューアに提供するステップを含む。実施形態の方法は、変換された画像コンテンツのクライアントブラウザでの表示を、ゼロフットプリントビューアによって容易にするステップを含む。実施例では、ゼロフットプリント医療画像ビューアは、画像コンテンツを中段サーバから取得する第１のデータマネージャを含み、中段サーバは、画像コンテンツを取得して、画像コンテンツを、格納フォーマットからブラウザ適合フォーマットへフォーマットする第２のデータマネージャを含み、第２のデータマネージャは、第１のデータマネージャと通信して、表示用の画像コンテンツの転送を容易にする。
実施例のゼロフットプリントビューアを示す図である。 クライアントにウェブブラウザ以外の要素を追加することなく、コンテンツのウェブ対応閲覧を促進にする実施例のシステムを示す図である。 ゼロフットプリントビューアを用いた画像表示の実施例のリクエストに伴うイベントのシーケンスを説明するデータフロー図である。 ゼロフットプリント画像レビューにより可能となる実施例のエンタープライズ画像形成システムを示す図である。 クライアント装置から独立して、メモリ依存画像閲覧を提供する実施例の方法を示すフローチャートである。 可逆画像データをクライアント装置にストリーミングする実施例の方法を示すフローチャートである。 クライアント装置での遠隔機能の実行を促進する実施例の方法を示すフローチャートである。 ゼロフットプリント画像ビューアで用いる実施例の多重レベルまたは多層キャッシュを示す図である。 多重レベルキャッシュにおけるデータの格納およびデータへのアクセスを促進する実施例の方法を示すフローチャートである。 ゼロフットプリントビューアの互換性検知を促進する実施例の方法を示すフローチャートである。 ここで説明するシステムおよび方法を実装するのに用いられうる実施例のプロセッサシステムを示すブロック図である。
上述の概要、および以下の本発明のある種の実施例の詳細な説明を、添付の図面を参照して読むことにより、理解が深まることになる。本発明を説明する目的で、ある種の実施例を図示する。しかしながら、本発明は、添付の図面に示す配列および手段に限定されないことを理解されたい。
Ｉ．概説
ある種の実施例において、放射線科医および臨床医用の統合ビューアワークスペースは、結合されたインテリジェントワークフローを通じて最適な能力を発揮する革新的な差別化要因の機能を、組み合わせている。この統合ビューアワークスペースにより、放射線科医の作業遂行および効率化、放射線科医と他の臨床医との意思疎通の向上、ならびに組織間および組織横断的な画像共有が可能となり、コストを削減するとともにケアを改善することができる。
統合画像ビューアは、医療画像を表示する。医療画像には、マンモグラムおよび他のＸ線コンピュータトモグラフィ（ＣＴ）、磁気共鳴（ＭＲ）、超音波、ならびに／または他の画像、ならびに共通のワークスペース内の様々な供給源からの非画像データ等がある。さらに、ビューアは、システム内および／または分散配置のコンピュータネットワークを通じて、コメントの作成または更新、画像モデルの処理および作成、通信に利用可能である。
ある種の実施例では、統合ビューアは、高機能掲示プロトコルを実装し、画像保管通信システム（ＰＡＣＳ）内外および／または他の業者中立的アーカイブ（ＶＮＡ）から患者データを高度な方式で取得する。ある種の実施例では、統合ビューアは、画像交換機能に対応し、高性能ストリーミングが実装され、異種のＰＡＣＳ間でデータを取り込むことなく読み取りができるようになっている。統合ビューアは、例えば「マルチオロジ」ビューアとして機能する。
ある種の実施例では、統合ビューアにより、ネイティブ読取ワークリストが提供されている。ワークリストは、理解しやすく、ユーザ定義で、例えば、複数の識別子、複数の文書、および複数の施設を含むことができる。
ある種の実施例では、統合ビューアによってワークフローが統合されている。ワークフローの統合には、報告システム、ワークリスト、音声認識（ＶＲ）、電子医療記録（ＥＭＲ）との統合、測定結果のエクスポート、検査メモのエクスポート、薄切片管理等が含まれる。
ＩＩ．ゼロフットプリント医療画像ビューア
ある種の実施例では、ゼロフットプリント（ＺＦＰ）ビューアおよび／またはＺＦＰ閲覧のシステム、方法、および装置が提供される。ＺＦＰビューアは、例えば、医用画像通信規格（ＤＩＣＯＭ）画像等の医療画像を表示可能である。ある種の実施例では、ＺＦＰビューアは、ハイパーテキストマークアップ言語５（ＨＴＭＬ５）で実装可能である。
ある種の実施例では、ゼロフットプリントであることは、アプリケーション（例えば、放射線科医ビューアおよび／または臨床医ビューア等）をインストールしたり利用するために管理者権限や特別な構成変更が必要とされないこと、複数のブラウザ（例えば、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（商標）、Ｆｉｒｅｆｏｘ（商標）、Ｓａｆａｒｉ（商標）、Ｃｈｒｏｍｅ（商標）等）および複数のオペレーティングシステム（Ｍｉｃｒｏｓｏｆｔ（商標）Ｗｉｎｄｏｗｓ、Ａｐｐｌｅ ＯＳ、ｉＯＳ、Ａｎｄｒｏｉｄ（商標）等）上で実行されるアプリケーションを提供すること、携帯プラットフォームおよび多様な装置表示サイズで実行され、クライアントにおいて最小限または少ないコンピュータ処理リソース（例えば、プロセッサ、メモリ等）ですむこと、狭い帯域幅でまずまずの性能を発揮するポータビリティを提供すること等と、定義することができる。
ＺＦＰビューアにより、画像閲覧および交換が容易になる。例えば、ＤＩＣＯＭ画像は、臨床データリポジトリ、業者中立的アーカイブ等にある患者の長期的な患者記録から閲覧可能である。ＤＩＣＯＭビューアには、複数のＰＡＣＳデータベースにわたって、同一のフレームワークにおける現在／過去の表示、自動取得等が提供される。
ある種の実施例では、ＺＦＰビューアは、複数のバックエンドアーキテクチャとともに動作可能なクライアントフレームワークに基づいて実装される。例えば、共通のインターフェイス、アイコン、コメント、用語、ツール、行動等が提供可能である。アプリケーションプログラミングインターフェイス（ＡＰＩ）が公開されていることにより、報告、ＥＭＲ、ＶＲ、ＬＤＡＰ等の外部システムとの複数の双方向的統合が容易になる。
画像をサーバ側でレンダリングすることにより、ゼロフットプリントおよびゼロまたはサイレント展開が容易になる。例えば、先進的アプリケーションの画像処理は、クライアントの他にもサーバにおいて実行可能である。
さらに、イベントは、埋込アプリケーション全体での同期であってもよい。ユーザの活動の学習、インデックス付け、監査等のためにログをとることもできる。
図１に、実施例のＺＦＰビューア１００を示す。実施例のＺＦＰビューア１００は、クライアントでのインストールやコンポーネントのダウンロードが一切不要となったＤＩＣＯＭ医療画像ビューアであり、ＨＴＭＬ５ブラウザ（例えば、最近のあらゆるハードウェアおよびオペレーティングシステム）に対応可能などのようなハードウェアにおいても仮想的に実行可能である。ビューア１００にいくつかのコンポーネントを提供することで、ＺＦＰビューア１００により柔軟性が得られるとともにクライアントのフットプリントが不要となる。図１の実施例のＺＦＰビューア１００は、ビューアコンポーネント１１０と中段サーバ１２０とを備えている。
ビューアコンポーネント１１０は、ＺＦＰビューア１００のレンダリング／操作コンポーネント（例えば、ＺＦＰ ＨＴＭＬ５ブラウザ用のレンダリングおよび操作エンジン）である。ある種の実施例では、ビューアコンポーネント１１０は、ＨＴＭＬ５のｃａｎｖａｓ要素を利用して、動的にスクリプト処理可能な、形状、画像および／または他のグラフィック要素のレンダリングを促進している。また、ある種の実施例では、ビューアコンポーネント１１０は、ウェブグラッフィクライブラリ（ＷｅｂＧＬ）を用いてレンダリングすることもできる。このように、ビューアエンジン１１０は、ＺＦＰビューア１００を通じてユーザが閲覧（およびインタラクション）するために、様々な動的２次元（２Ｄ）および／または３次元（３Ｄ）レンダリングを、提供可能である。
中段サーバ１２０は、画像データを閲覧用のフォーマット（例えば、ブラウザ親和性またはブラウザ適合フォーマット）に変換するように駆動する。中段サーバ１２０は、ビューアコンポーネント１１０を通じて表示するために、ＤＩＣＯＭデータ等の画像データの符号変換に対応している。例えば、中段サーバ１２０により、ＤＩＣＯＭ重視の圧縮フォーマット（例えば、Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ委員会２０００（ＪＰＥＧ２０００）の画像圧縮および符号化フォーマット等）と最近のブラウザにより適合したフォーマット（例えば、ポータブルネットワークグラフィックス（ＰＮＧ）の画像フォーマット）との間の符号変換等、画素の符号変換が容易になる。非画像オブジェクトおよびメタ情報につき、中段サーバ１２０は、バイナリ型フォーマットを、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）等のブラウザ適合フォーマットに変換する。
ある種の実施例では、符号変換は、あるエンコードを他のものへと直接的にデジタル−デジタル変換することである。中段サーバ１２０において符号変換を容易にすることにより、ビューアコンポーネント１１０およびＺＦＰビューア１００全体としては、特定のファイルフォーマットに対応するためには、クライアント装置（例えば、電話、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ等）が必要ではなくなる。符号変換により、中段サーバ１２０は、記憶容量が限られたクライアント装置上で動作しやすくなり、および／またはクライアント上で実際にどれだけの容量が利用可能であるかにかかわらず、クライアント装置上での閲覧用に限られた容量のみを占有すればよくなるので、動作しやすくなる。中段サーバ１２０で符号変換することにより、過去の非互換的および／または旧式のデータフォーマットを、ビューアコンポーネント１１０での閲覧に適したフォーマットに変換しやすくなる。符号変換は、例えば、画像および／または非画像ファイルの検索および／または提示の間に、実行可能である。符号変換は、例えば、不可逆または可逆過程であってもよい。例えば、入力が可逆的に圧縮されて、出力も可逆的に圧縮されるか非圧縮である場合、符号変換は、可逆であってもよい。不可逆−不可逆間の符号変換過程により、様々な程度の生成損失がもたらされる。
ある種の実施例では、中段サーバ１２０は、２段階の符号変換を実行する。第１に、データファイルが、中間的な非圧縮フォーマットへと復号される。第２に、この中間的な非圧縮フォーマットが、目的とするフォーマットへと符号化される。
ある種の実施例では、同一フォーマットで、編集、ビットレート低減、画像倍率変換等のために、再度エンコードされてもよい。例えば、ＪＰＥＧ画像の編集のために、画像ファイルは、閲覧コンポーネント１１０および中段サーバ１２０により、復号、編集、再符号化される。
ある種の実施例では、ファイルは、低ビットレートへとレート変換されてもよい。レート変換は、フォーマットを変えずにファイルを低ビットレートに変換する符号変換と同様の処理である。レート変換は、例えば、サンプリングレートは同一だが圧縮率の高いサンプルレート変換であってもよい。レート変換により、媒体は、少ない記憶容量や低帯域幅のチャネル等に適合可能となる。
また、中段サーバ１２０は、閲覧コンポーネント１１０用に画像倍率を変換しやすくなる。画像サイズ変換は、トランスサイズとして知られており、例えば、出力解像度が、ある媒体の解像度と異なる場合に、利用されることがある。画像倍率変換は、中段サーバ１２０での再生時における再符号化の際に、レート変換等の一部として、容易に実装可能である。
このように、中段サーバ１２０は、符号変換を用いて、様々な機器上に適切なコンテンツ表示が確実にできるように支援することができる。中段サーバ１２０は、元のコンテンツが目的の装置に確実に表示可能となるように支援する、コンテンツ適合化の中間状態を提供する。ある種の実施例では、中段サーバ１２０は、多対多フォーマット（例えば、「任意の」入力フォーマットから「任意の」出力フォーマットへ）におけるリアルタイム（または擬似リアルタイム）符号変換を提供し、ＺＦＰビューア１００により、様々な装置において、画像および／または他のコンテンツについての検索、表示、インタラクションができるようにしている。
ある種の実施例では、ＺＦＰビューアにより、ウェブソケット（ＷｅｂＳｏｃｋｅｔ）型ＤＩＣＯＭ画像ストリーミングが容易となる。例えば、ＺＦＰビューアで取得されて表示されても、画像の元のフォーマットが保たれる。ある種の実施例では、ウェブソケットのトランスポート層を用いて、プログラム可能ワークステーション機能が提供される。ある種の実施例では、ウェブソケットを介して、ＪａｖａＳｃｒｉｐｔが関数変換をリモート処理することができる。
ある種の実施例では、ＺＦＰビューアにより、メモリ依存画像閲覧が提供される。例えば、使用リソース量がトラッキング可能で、データをサーバからオフラインにすることができる。
ある種の実施例では、ＺＦＰビューアにより、フォームファクタ対応ストリーミング技術が提供される。例えば、完全に可逆な画像をバックグラウンドでダウンロードしているものの、クライアント装置の利用可能サイズに基づき、解像度低減画像を、第１の表示用のクライアントビューアへと送出する。
ある種の実施例では、ＺＦＰビューアにより、ウェブ用のスケーラブル‐ベクター‐グラフィックス（ＳＶＧ）対応ＤＩＣＯＭグレースケールソフトコピープレゼンテーションステート（ＧＳＰＳ）が提供される。
ある種の実施例では、多重レベル画像キャッシュの中段が提供される。例えば、クライアント側に大量の情報を格納しなくてすむように、データ格納のために中段が提供されてもよい。
ある種の実施例では、「インテリジェント」ウェブブラウザクライアント機能ワークフローが提供される。
図２に、ウェブブラウザ（通例、クライアント装置にインストール済）以外にクライアントにコンポーネントを追加することなく、ウェブ対応コンテンツ閲覧（例えば、ＤＩＣＯＭ画像調査対象等）ができるようにした実施例のシステム２００を示す。
実施例のシステム２００は、フロントエンドサブシステム２０１と、中段サブシステム２０２と、バックエンドサブシステム２０３とを備える。バックエンドサブシステム２０３は、エンタープライズアーカイブ（ＥＡ）、ＶＮＡ等のデータ記憶部２９０と、画像形成モダリティ等のデータ供給元２９５からの受信データ（例えば、ＤＩＣＯＭデータ）とを備える。
中段サブシステム２０２は、ＺＦＰ中段２５０を備える。ＺＦＰ中段２５０は、ウェブソケット接続マネージャ２５１と、ウェブサービス２５２と、ＸＪＴエンジン２５３と、互換性レンダラ２５４と、ログ／監査部２５５と、言語リソースマネージャ２５６と、認証部２５７とを備える。さらに、ＺＦＰ中段２５０は、委任部２５８と、データマネージャ２６０とを備える。委任部は、データマネージャ２６０とともに、ウェブソケット接続マネージャ２５１、ウェブサービス２５２、およびＸＪＴエンジン２５３のうちの１つまたは複数を介して、ＺＦＰビューア２１０のインターフェイスとして機能し、データマネージャ２６０にタスクを委任して、コンテンツをＺＦＰビューア２１０に提供する。ＸＪＴファイルは、圧縮ＧＩＭＰ（ＧＮＵ画像操作プログラム）画像ファイルであり、ＸＪＴエンジン２５３（例えば、Ｊａｖａ仮想マシン（ＪＶＭ）、Ｔｏｍｃａｔ等であり、Ｊａｖａコードの実行環境を提供する）で表示用にレンダリング可能である。
図２の実施例におけるデータマネージャ２６０は、圧縮符号変換エンジン２６１と、非画像オブジェクトコンバータ２６２と、ＤＩＣＯＭツールキット２６３と、画像データ配信クライアント２６４と、エンタープライズアーカイブコネクタ２６５と、多層サーバキャッシュ２６６とを備える。ＥＡコネクタ２６５は、ＥＡ２９０と通信して、１または複数の画像についてのメタデータを取得および／または格納する。この画像も、表示用にアーカイブ２９０から提供されたものである。多層キャッシュ２６６は、ＺＦＰ中段２５０が、ディスク記憶部２８０とともにデータを一時的に格納またはキャッシングできるように支援する。画像データ配信クライアント２６４は、画像データ配信システム２７０から画像データを取得する。
フロントエンドサブシステム２０１は、ＺＦＰビューア２１０を備える。ＺＦＰビューア２１０は、イベントマネージャ２１１と、画像操作ツール２１２と、互換性検知部２１３と、委任部２１４と、ウェブソケット２１５と、データマネージャ２２０と、表示パイプライン２３０とを備える。患者情報ビューアまたは電子医療記録クライアント等のウェブクライアント２４０は、公開調査対象リクエスト等のリクエストを、ＺＦＰビューア２１０へ送信し、例えば、ビューア２１０と対話して、画像データおよび／または他のコンテンツを表示する。
表示パイプライン２３０は、ＨＴＭＬ５ ＣａｎｖａｓやＷｅｂＧＬ等のためのディスプレイドライバ２３１を備える。また、表示パイプライン２３０は、画像レンダラ２３２と、ビューポートマネージャ２３３と、ＸＪＴレンダラ２３４とを備え、画像および他のデータを処理して表示可能とする。
データ表示マネージャ２２０は、画素データキャッシュ２２１および／またはアレイバッファと、メタデータ記憶部２２２と、非画像記憶部２２３と、優先度エンジン２２４と、伸張エンジン２２５とを備える。画像および／または他のデータ（例えば、メタデータ）が、例えば、ウェブソケット２１５，２５１および／またはウェブサービス２５２を介して、データマネージャに対して提供され、委任部２１４は、データマネージャ２２０のコンポーネントのうちのどのコンポーネントを取得してデータに作用させるか決定する。
動作としては、ウェブクライアント２４０は、リクエストを、ＺＦＰビューア２１０へ送信して、１または複数の画像（例えば、調査対象）を開いて表示する。そして、ウェブソケット２１５および／または他の伝送機構を利用して、画像およびメタ情報を、ＺＦＰ中段２５０を介して記憶部２９０，２９５から取得する。例えば、画像データは、ウェブソケット２５１，２１５を通じ、バイナリデータとして提供可能であり、メタデータは、ウェブソケット２５１，２１５を通じ、ＪＳＯＮデータとして提供可能である。ウェブサービス２５２は、ウェブソケットが適用されない場合には、フォールバック転送機構を提供する。取得したデータは、（例えば、伸張エンジン２２５により）ブラウザ対応ＺＦＰビューア２１０内で伸張可能である。データは、優先度エンジン２２４によって優先順位付けされ、メタデータ記憶部２２２、非画像記憶部２２３および画素データキャッシュ２２１のうちの１つまたは複数内に、表示用に格納される。
データは、画素データキャッシュ２２１、メタデータ記憶部２２２および非画像記憶部２２３のうちの１つまたは複数から、表示パイプライン２３０に対して提供される。このパイプラインにおいて、画像データは、画像レンダラ２３２および／またはＸＪＴレンダラ２３４（例えば、画像ファイルの形式に基づき）によってレンダリングされ、ビューポートもしくは表示ウィンドウが調整され、および／または、ビューポートマネージャ２３３により別形式で構成される。画像レンダリングは、ディスプレイドライバ２３１（例えば、基本的ＨＴＭＬ５レンダリング等のフォールバックとしての高性能画像およびＣａｎｖａｓのシェーダ対応レンダリング用のＷｅｂＧＬ）により可能となる。ディスプレイドライバ２３１は、例えば、画像提示用のＳＶＧカプセル化（例えば、ＧＳＰＳ）を提供可能である。
さらに、ＺＦＰビューア２１０は、イベントマネージャ２１１および画像操作ツール２１２を提供し、クライアント２４０を介してユーザが表示コンテンツと対話しやすくなっている。互換性検知部２１３は、互換性レンダラ２５４とともに動作して、表示の互換性を決定し、問題を解決および／または伝達する。例えば、互換性および／または他の問題が、監査のためにログ／監査部２５５により、ログに記録および／またはトラッキング可能である。言語リソースマネージャ２５６および認証部２５７は、例えば、アクセスの検証を支援するとともに互換性の保証を支援する。
ＺＦＰ中段２５０において、画像データ配信クライアント２６４は、（例えば、ストリーミング等で）画像データを、データ記憶部２９０，２９５から、データ配信システム２７０を介して取得する。データに対して、データマネージャ２６０により、格納、処理、圧縮、符号変換等がなされ、このデータは、委任部２５８により、インターフェイス２５１，２５２，２５３のうちの１つまたは複数に対して提供される。例えば、ウェブソケット接続マネージャ２５１は、ＺＦＰビューア２１０上のウェブソケット２１５とともに動作して、コンテンツを配信し、ウェブサービスおよび／またはＷｉｎｄｏｗｓ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｆｏｕｎｄａｔｉｏｎ（ＷＣＦ）をフォールバック伝送機構としている。ＸＪＴエンジン２５３は、３次元レンダリングのためにＸＪＴレンダラ２２５と対話する。ＺＦＰ中段２５０により、ウェブ側のウェブ技術が容易になり、モデル‐ビュー‐コントローラ（ＭＶＣ）フレームワークが実装され、ウェブクライアント２４０において、３つの役割の合成として表示用コンテンツが生成される。この役割とは、モデル（例えば、アプリケーション状態をトラッキングする）、コントローラ（例えば、インタラクションをハンドリングし、モデルを更新する）、およびビュー（例えば、コントローラ用の情報に基づき、ユーザインタフェースをレンダリングする）。画像および／またはメタデータをバックエンド２０３から取得することに加えて、例えば、中段２０２は、データ記憶部２９０に保存されるべき調査対象情報および結果を提供することもできる。
このように、システム２００は、現行の各種バックエンドシステムと統合されて現行の各種バックエンドシステムのいずれかにある画像への直接的なオンラインアクセスを提供する、単一の統合ビューアを提供する。
ある種の実施例では、元の画像（例えば、元のＤＩＣＯＭ画像）のフォーマットが、ＺＦＰビューアによる取得および表示を通じて維持される。１つまたは複数の画像サブセクションが、リクエストされるとともにトランスミッションコントロールプロトコル（ＴＣＰ）接続等の通信チャネルにおいて利用可能である。ウェブソケットプロトコル等のプロトコルを用いて、バイナリデータが、符号化することなく直接的に取得可能である。ウェブソケットは、例えば、単一のＴＣＰ接続で、全二重通信を提供する。ウェブソケットを用いて、メッセージが、クライアントブラウザ（例えば、図１の実施例のビューアコンポーネント１１０を実行）とサーバ（例えば、図１の中段サーバ１２０）との間を行き来することができる。これは、現行の双方向通信により、あるいは情報を含むメッセージをサーバおよびブラウザ間で交換可能とする接続を開いてなされる。メッセージは、例えば一連のデータパケットとして交換可能である。
ある種の実施例では、各データパケットに抽象ヘッダ（例えば、パケットヘッダ）が作成される。ヘッダは、パケットを記述および／または他の態様でパケットを識別する。パケットヘッダをデータのブロックと組み合わせて用いて、クライアントの要求または予想にしたがって、データを送信することができる。例えば、ＤＩＣＯＭ画像データは、データの元々の形式で（例えば、バイナリ）で、ブラウザへと直接的にストリーミング可能である。
サーバにおいてデータを符号化および／または他の態様でカプセル化すること（例えば、ｂａｓｅ６４符号化）、符号化データをクライアントへ送ること、クライアントにおいてプラグインまたはアプレットによってデータを復号する代わりに、クライアントブラウザにおけるウェブソケット機能が、追加のアドオンまたはオーバーヘッドの大幅な増加なしにプロトコルレベルで受信した非符号化データを識別するのに利用可能である。シッククライアントアプリケーションを用いたり、データをウェブサービスとしてカプセル化したり、またはデータをアプリケーションサービスプロバイダ（ＡＳＰ）コールとしてカプセル化する代わりに、例えば、データはシンクライアントブラウザへと直接提供可能である。
ある種の実施例では、フルプレゼンテーションステート（例えば、グレースケールソフトコピープレゼンテーションステート）を提供可能なＺＦＰ医療画像ビューアが提供される。プレゼンテーションステートは、特定の画像がどのように表示されるかを示す情報を含む独立ＤＩＣＯＭサービス−オブジェクトペア（ＳＯＰ）インスタンスである。例えば、プレゼンテーションステートには、ラベル情報（例えば、ラベル形式、位置等）、ウィンドウ値、ズーム値、スクロール（パン）値、回転および／またはＤＩＣＯＭ規格内で定義された他の視覚表現要素が含まれてもよい。プレゼンテーションステートは画像に適用可能であり、画像は、プレゼンテーションステートにより定義される視覚仕様で表示される。プレゼンテーションステートを用いて、ある方式で変更されずに画像が表示可能であるため、プログラムまたは他のユーザは、希望すれば元の画像へ戻ることができる。プレゼンテーションステートは、画像保管通信システム（ＰＡＣＳ）へと送信可能であり、要求された場合に、画像とは別におよび／または画像とともに、取得可能である。
例えば、グレースケールソフトコピープレゼンテーションステート（ＧＳＰＳ）により、ＤＩＣＯＭアプリケーションエンティティは、複合画像オブジェクト内の格納画素データ値を装置またはメーカに依存しないプレゼンテーション値（Ｐ値）へとどのように変換するのかを特定することが可能となる。表示装置は、Ｐ値を、例えばソフトコピー表示の輝度に変換する。グレースケール標準表示機能は、線形知覚応答を定義し、表示装置を較正するために利用可能であり、ＧＳＰＳで規定された変換方式にしたがって表示された場合、同様のグレースケールコントラストとなる。他のプレゼンテーションステートと同様、ＧＳＰＳにより、画像表示特性が、格納画像オブジェクトから分離されるとともに独立して更新できるようになる。ある種の実施例では、ＧＳＰＳには、ベクタグラフィックスおよびプレーンテキストとともに、回転、ズーム、パン、コメント等ができるようにした拡張が含まれる。画像は、ＧＳＰＳが適用された１つまたは複数の調査対象から、独立して、および／または一連の画像の一部として選択可能である。
フルプレゼンテーションステートを用いて、ＤＩＣＯＭ画像は、クライアント装置上でプラグインや特別な表示ソフトウェアを実行することなく、ＺＦＰビューア上で完全に処理可能である。ＤＩＣＯＭ情報は、このＤＩＣＯＭ情報がクライアント（例えば、ウィンドウレベル、ズーム、パン等）上で直接操作可能となるように、画像毎に保持されている。
ある種の実施例では、ウェブブラウザにおいてＨＴＭＬ５で実行されるとともにクライアント装置から独立したＺＦＰクライアントビューアが提供される。このＺＦＰビューアは、データマネージャを備える。データマネージャによりサーバとの間でデータを順方向および逆方向にページングするとともに、データマネージャにより、ユーザはクライアント（例えば、中段画像キャッシュ内）に一定量のデータを保持することが可能となる。このような「インテリジェント」ページングにより、ＺＦＰウェブ対応ブラウザ上で、メモリ依存画像を閲覧しやすくなる。例えば、調査対象内の個々の画像間でスクロール可能であり、画像調査対象のどこに画像があるのかということに基づいてサーバとの間でページングされていることに、ユーザは気づかない。
ある種の実施例では、公開調査対象リクエストが、患者情報ビューア（ＰＩＶ）、電子医療記録（ＥＭＲ）ウェブクライアント等から取得される。表示パイプラインは、調査対象内の画像の画素データを全て読み取り、ＤＩＣＯＭ属性を、表示用画素データに与える。変更済画素データは、ｃａｎｖａｓ要素、画素シェーダ等を用いて、表示用に調整される。
「インテリジェント」ＺＦＰウェブブラウザ対応ビューアにより、互換性が特定される。まず、互換性が、クライアント側（例えば、クライアント上で早く正確に）で検知され、互換性検知結果が、サーバへ送信される。サーバがリクエストされた画像および／またはクライアント向けの他の情報を生成する場合、サーバは、クライアントが使用しないコードを追加することなくリクエストされた結果を生成することができる。互換性レンダリングに加えて、ログ取得、監査、およびリソース管理が、ＺＦＰビューアにより提供される。
ある種の実施例では、実行時多重レベルキャッシュ（例えば、メモリ、ディスク、および供給元）により、ＰＡＣＳおよび連動するビューアに対応している。ＺＦＰ中段は、例えば、ＰＡＣＳおよび／または他のデータアーカイブ（例えば、エンタープライズアーカイブ等）における記憶用のプロキシとして機能する。
ウェブソケット接続は、例えば、符号化することなく高速データ転送を提供する一次接続として機能する。ある種の実施例では、ウェブサービスにより、ウェブソケットに対応していないクライアント用のデータ転送が容易になる。画像のレンダリングは、例えば、ＺＦＰクライアントに対して提供されたサーバ上で、実行可能である。ある種の実施例では、ウェブソケット型ＤＩＣＯＭ画像ストリーミングプロトコルにより、シッククライアント対シッククライアントのストリーミングではなく、シンクライアントブラウザおよび／またはクライアント上の他のＺＦＰ ＨＴＭＬビューアに対する圧縮のために、画像が優先順位付けされる。
ある種の実施例では、データマネージャがサーバに提供されている。サーバ上のデータマネージャは、クライアントビューアへ送信されるデータの圧縮および符号変換を実行する。ある種の実施例では、データマネージャは、非ＤＩＣＯＭオブジェクトのフォーマットを使用可能なフォーマットに変換する非画像オブジェクトコンバータを備える。
ある種の実施例では、「メモリ依存」画像閲覧は、使用リソース量およびサーバからブラウザへ送信されるページングがリクエストされた画像データをトラッキングすることにより容易に実行可能となる。例えば、使用メモリ量を常時把握することに加えて、受信中のクライアント装置が解析されて、どのクライアント装置が所与の種類の画像を処理可能か判定される。
さらに、フォームファクタ対応ストリーミング技術は、サイズ（フォームファクタ）等の利用可能クライアント装置特性に基づき、第１の視認解像度で圧縮した初期画像を提供するが、一方で、完全に可逆の医療診断品質画像が、バックグラウンドでダウンロードされる。ある種の実施例では、画像データをストリーミングするときに、クライアント装置のフォームファクタを示すことにより、固有のサイズおよび／または他の装置特性の装置に配信するサーバにおいて、画像がレンダリング可能である。
例えば、クライアント装置がハンドヘルド装置または携帯装置（例えば、スマートフォン、タブレットコンピュータ等）であってマンモグラフィ画像（例えば、８〜１０メガバイトのサイズ）が表示用に選択された場合、ユーザは通例、装置上で迅速に画像を見ることができない。しかしながら、クライアント装置およびサーバ間の通信を容易にすることで、クライアントはサーバに対して、所望の画像ポートサイズを提供可能となり、サーバは、連続的に圧縮された解像度の画像を作成することができるようになる。結果としての画像は、クライアントへ送信されて、クライアント上のビューポートサイズ用の最低解像度で表示可能となる。ユーザが低い解像度の画像をクライアント装置で見ている間に、画像のデータの残りをバックグラウンドでクライアントへ送信することができる。このように、ユーザは、画像表示に用いるクライアント装置の種類に対して適切な解像度で、柔軟に受信することになる。
ある種の実施例では、拡縮およびベクタグラフィックス（例えば、ＳＶＧ対応ＤＩＣＯＭＧＳＰＳ）により、エクステンシブルマークアップランゲージ（ＸＭＬ）を用いて、データ平面をトラッキング可能となる。ベクタグラフィック座標は、ＸＭＬで表現可能であり、ＧＳＰＳは、１つまたは複数の画像について表示可能である。例えば、ＰＡＣＳビューアは、ＤＩＣＯＭ ＧＳＰＳオブジェクトを作成する。ＺＦＰビューアは、ＳＶＧを実現している。ＧＳＰＳをＳＶＧオブジェクト内にカプセル化することにより、ＧＳＰＳは、ＸＭＬでのＺＦＰブラウザ内の画像と、直接的に協働することができるようになる。ＳＶＧとともに、コメントが、ＺＦＰビューアで利用可能なＳＶＧパーサで表示可能である。コメントは、画像上に重ねて表示可能であり、ブラウザは、画面との関係で、コメントをどのように表示するか認識している。
ある種の実施例では、プログラム可能ワークステーション機能を実現するのに、ウェブソケットトランスポート層が用いられてもよい。従来、ブラウザは、ＡｃｔｉｖｅＸコンポーネントおよび高度なセキュリティ権限による以外に、クライアントと直接的に対話することはできなかったが、ウェブソケットにより、例えば、アプリケーションは、ブラウザがＴＣＰソケットを用いて直接的に対話可能なクライアント上で実行可能となる。例えば、ＡｃｔｉｖｅＸコンポーネントをインスタンス化することなく、ブラウザにより、クライアントが複数のモニタに対応しやすくなる。ウェブソケットを用いることにより、ブラウザは、クライアント装置を直接的に検査できるとともにクライアント装置と直接的に対話することができる。ウェブソケット接続により、例えば、サードパーティのアプリケーションとの相互運用性が、さらに容易かつ直接的になる。
ある種の実施例では、遠隔関数変換は、ＺＦＰビューアにより提供されてもよい。例えば、ＪａｖａＳｃｒｉｐｔ遠隔関数変換は、ウェブソケットを介して実現してもよい。例えば、プロキシは、クライアント側で作成されてもよく、このプロキシは、変換することなくサーバを呼び出す。
図３に、ＺＦＰビューア２００を用いた画像表示の実施例としてのリクエストに伴うイベント３００のシーケンスを示すデータフロー図を示す。説明の目的で、実施例のシステム２００におけるウェブクライアント２４０、ＺＦＰビューアクライアント２１０、ＺＦＰ中段２５０、データアーカイブ２９０およびストリーミングエンジン２７０に関連して、イベント３００のシーケンスを説明する。
３０５では、画像表示のリクエストが、ウェブクライアント２４０によって（例えば、ＰＩＶ、ＥＭＲ等によって）発行される。リクエストメッセージ３０５には、リクエストされた調査対象を特定するために、調査対象識別子、アクセス番号等が含まれてもよい。ＺＦＰクライアント２１０は、リクエスト３０５を受信し、コマンド３１０を送信して調査対象を起動する。ＺＦＰ中段２５０は、コマンド３１０を受信し、アーカイブ２９０に対するメタデータリクエスト３１５を生成する。アーカイブ／データ記憶部２９０は、リクエスト３１５に基づき、メタデータレスポンス３２０を中段２９０へ返送する。ＺＦＰ中段２５０は、アーカイブ２９０からの情報およびストリーミングエンジン２７０へのリクエストトークンに基づき、調査対象概要３２２を作成する。
３２５では、ＺＦＰ中段２５０は、立ち上げた調査対象のレスポンスを送信する。このレスポンスには調査対象概要３２２が含まれている。ＺＦＰビューアクライアント２１０は、起動した調査対象のレスポンス３２５を受信し、調査対象概要３２２内のトークンを用いて、ＺＦＰ中段２５０に対する１つまたは複数のリクエスト３２８を生成する。ＺＦＰクライアント２１０は、画像および／または非画像オブジェクトのリクエスト３５０を、リクエスト３２８内のトークンに基づき、ＺＦＰ中段２５０へ送信する。
３３６では、ＺＦＰ中段２５０は、ＺＦＰビューア２１０が要求した画像および／または非画像オブジェクトのリクエストを、ストリーミングエンジン２７０へ送信する。ストリーミングエンジン２７０は、データアーカイブ２９０に対する画像／非画像オブジェクトのリクエスト３４０を作成する。アーカイブ２９０は、リクエストされた画像および／または非画像データを含むレスポンス３４５を、ストリーミングエンジン２７０に提供する。ストリーミングエンジン２７０は、リクエストされた画像／非画像データを含んだレスポンス３５０をＺＦＰ中段２５０に提供する。ＺＦＰ中段２５０は、受信した画像／非画像データを処理し、データ３５５を、表示用に、ＺＦＰビューア２１０に提供する。ＺＦＰビューアクライアント２１０は、受信したＧＳＰＳおよび画素データに基づき、画像３５８をレンダリング可能である。そして、レンダリングされた画像および関連の非画像データは、ＺＦＰビューア２１０によって、ウェブクライアント２４０でアクセス可能となる。
図４に、ゼロフットプリント画像レビューにより可能となる実施例のエンタープライズ画像形成システム４００を示す。実施例のシステム４００は、ワイドエリアネットワーク４２０〜４２２を介して１または複数の場所４１０〜４１２と通信するワークステーション４０５と、サービス層４３０とを備える。各場所４１０〜４１２に、ＰＡＣＳ４１５〜４１７がある。ワークステーション４０５は、複数施設、企業横断ワークリストと、埋込型企業横断文書共有（ＸＤＳ）とを提供する。ネイティブ最大強度投影／複数平面リフォーマット（ＭＩＰ／ＭＰＲ）が、２次元および／または３次元で提供可能である。ＺＦＰビューアと画像データのサーバーサイドレンダリングにより、ワークステーション４０５を通じて単一の統合インターフェイスが可能となる。複数のユーザ用の複数のＰＡＣＳ４１５〜４１７および複数のアプリケーションにわたって単一のビューアが提供可能である。
ＩＩＩ．画像ストリーミング
ある種の実施例により、ＤＩＣＯＭ画像等の医療画像を、コンポーネントを追加したり特殊なコンポーネント（例えば、ＺＦＰブラウザまたはビューア）を必要とせずに、クライアント装置上のウェブブラウザへ直接ストリーミングすることが可能となる。ブラウザ内でＨＴＭＬ５対応のウェブソケットを用いることにより、ウェブや他のコンテンツサーバに対するポーリングや非同期ＪａｖａＳｃｒｉｐｔ（Ａｊａｘ）コールを必要とせずに、全二重バイナリ通信が提供される。ウェブソケット（および／またはＴＣＰ対応ソケット）により、通信チャネルを、確立することができる。この通信チャネルがアクティブである限り（例えば、ブラウザのページに変化がないこと）、この通信チャネルを通じて、クライアントおよびサーバがいつでもメッセージを相互に送受信できる。ＤＩＣＯＭ医療画像は、変換を必要とせずに（例えば、ｂａｓｅ６４符号化または復号化等なしで）ユーザブラウザへ送信可能である。
ＺＦＰビューアにおけるウェブソケット型ＤＩＣＯＭ画像ストリーミングプロトコルにより、ＤＩＣＯＭサービスオブジェクト（ＳＯＰ）ペアインスタンスユニーク識別子（ＵＩＤ）に基づき、調査対象内の画像を選択することが容易になる。選択した画像は、複数フレーム画像から選択した特定のフレームであってもよい。特定の圧縮および／または符号変換要素が、選択した画像に提供されてもよく、これは元の画像の倍率であってもよい。
ＺＦＰビューアの画像ストリーミングプロトコルを用いることにより、元のＤＩＣＯＭ画像のサブセクションをリクエストすることができる。例えば、メタ情報（例えば、ＤＩＣＯＭ画像ヘッダから）を取得可能である。また、画像オーバーレイ情報、画像ルックアップテーブル（ＬＵＴ）情報、画像パレット情報等も、取得可能であり、ＺＦＰビューアによって画像をストリーミングするために利用可能である。
さらに、ＺＦＰビューア画像ストリーミングプロトコルにより、リクエストされた元の情報の順番が変更可能である。また、キーオブジェクト等の非画像オブジェクト（ＮＩＯ）、構造化レポート、ＧＳＰＳ等も、リクエスト可能である。
上述の特徴を組み合わせることにより、ＨＴＭＬ５ウェブソケットを用いてウェブブラウザへ直接ＤＩＣＯＭ画像をストリーミングする、ＺＦＰソリューションが作成される。
実施例の画像ストリーミングプロトコルには、ウェブブラウザからの画像データのリクエストを受信することが含まれる（例えば、調査対象を開くリクエスト）。ある種の実施例では、画像ストリーミングエンジンにより、サーバ上での画像データの符号変換（例えば、ＪＰＥＧ２０００からＪＰＥＧへ、ＪＰＥＧからＲＡＷへ、ＲＡＷからＪＰＥＧへ等）や、元の画像データの倍率変換または関心領域をリクエストすることが可能となる。これにより、クライアントは、特にある状況（例えば、狭帯域幅、広帯域幅、漸進的表示等）に対応させて作成した画像をリクエストすることができるようになる。ある実施例においては、元の画像の６０％品質の不可逆圧縮ＪＰＥＧをリクエストすることが、デフォルトとしてクライアントに提供されており、その後、未処理データをリクエストする。これにより、画像は非常に迅速にクライアントに表示可能となり、この際、パイプでは、後続の診断品質画像表示用に、可逆（未処理）データを取得している。
ＩＶ．メモリ依存画像閲覧
ある種の実施例では、ＺＦＰビューアにより、メモリ依存画像閲覧が容易になる。使用リソース量をトラッキングするとともに画像データをサーバから切り離すことにより、画像閲覧が、ゼロフットプリントとなり、クライアントブラウザのメモリ依存となる。ＤＩＣＯＭ画像調査対象は、非常に大容量となることもあり、ウェブを通じてＤＩＣＯＭ画像調査対象を閲覧することが難しかったり、非現実的になりうる。標準的なウェブブラウザが使えるメモリは約２ギガバイトであるが、そのうちのいくらかは、ブラウザ自体や現在ロードされたりキャッシュされた他のウェブページにより使用されている。しかしながら、１０ｋ ＣＴ画像調査対象等の大規模なＤＩＣＯＭ調査対象は、メモリに直接保存するには、この容量のほぼ倍の容量が必要となる。
ある種の実施例では、ＺＦＰビューアは、ウェブビューアに用いるリソースを常時トラッキングする。リソースには、格納されたメタ情報、未処理画素情報、圧縮データ、非画像オブジェクト等が含まれる。ＺＦＰビューアは、この情報をトラッキングしつつ、先立って閲覧（例えば、プリフェッチ）されているあらゆる情報をロードすることができる。
例えば、ユーザが、大規模なＣＴ調査対象から１０００スライスＣＴ列を閲覧することを希望している場合、ビューアは、ユーザがこの列の開始点を選択するべきであると想定する。例えば、ユーザがこの列の冒頭から始めて終わりへとスクロールすることが、想定される。ユーザが所定の速度でのみスクロール可能で、ウェブクライアントにおけるメモリ内の使用可能容量がトラッキングされているので、（例えば、ＺＦＰウェブページについてハードコード化された値）、ビューアは、ユーザが画像をスクロールする際に滑らかな使用感が得られるようにするためには、およそどれだけの画像をウェブビューアにプリロードすればよいか特定する。ユーザが、ビューアにプリロードされた画像の終端に近づくと、ビューアは、表示中の画像から列内において（およびクライアントキャッシュ内において）遠位の画像を「インテリジェント」に放棄し、さらに表示用のデータをプリキャッシュする。ある種の実施例では、ユーザが活発に調査対象を閲覧している間は、この処理は連続する（あるいは実質的に連続する）。ユーザのセッションがＺＦＰビューアを介してアクティブである間は、サーバが、ロードした調査対象の全情報を保持しているので、モニタリングおよびプリフェッチ処理は非常に高速である。サーバがデータをサーバにおいて処理および編成してクライアントに表示させた状態において、ページングにより、ＺＦＰビューアは、ユーザのウェブブラウザに特別な機能がなくとも、ユーザが極端に大規模なＤＩＣＯＭ画像の組を閲覧できるように支援可能である。
図５に、クライアント装置から独立したメモリ依存画像を閲覧できるようにする方法５００のフローチャートを示す。ブロック５１０では、画像または画像列を選択したものを受信する。例えば、ユーザは、タブレットコンピュータで取得および閲読する調査対象を選択する。ブロック５２０では、選択した画像のサイズが特定される。
ブロック５３０では、データ格納容量および／またはクライアント装置で使用可能な他のリソースが特定される。例えば、キャッシュ容量および／またはユーザのタブレットで現在使用可能な他のメモリ容量が特定される。ある種の実施例では、使用可能なメモリ容量に影響する他の条件および／またはブラウザ性能が、クライアント装置（例えば、クライアント装置で実行中の他のプログラム、メモリにおける他の制約、利用可能帯域幅、利用可能な処理能力等）において特定可能である。
ブロック５４０では、選択した画像の開始点が特定される。例えば、ユーザは、画像列の一部における画像を選択済であるか、あるいは、システムが、ユーザは列における第１の画像等から開始するものと想定するように、ユーザは、開始点を特定せずに画像調査対象を選択済であってもよい。ブロック５５０では、開始点に基づき、１つまたは複数の画像が、１つまたは複数の要素にしたがって、クライアント装置上にプリロードされてもよい。例えば、開始点、サイズ、利用可能容量、他のクライアント装置および／または接続状態等が考慮されて、どの画像および／またはいくつの画像がクライアント装置にプリロードされるべきか決定される。ユーザが追加の画像をリクエストおよび／または閲覧する間、処理５００は継続し、クライアント装置に負荷をかけ過ぎることなく、ユーザのクライアント装置における閲覧感覚が向上する。
Ｖ．フォームファクタ対応ストリーミング
ある種の実施例では、フォームファクタ対応ストリーミングが提供される。例えば、クライアント装置（例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン等のクライアント装置における利用可能表示領域）の利用可能サイズに基づき、まず解像度圧縮画像が表示用に送信されるとともに、完全に可逆な診断品質画像がバックグラウンドでダウンロードされる。
画像ブラウザがサーバの記憶域から画像を取得してその画像を利用可能ビューポートに対応させて拡縮することができるとともに、ある種の実施例では、より効率的で正確な送信およびレンダリングが、特に、携帯および／または他の小型画面クライアント装置で高解像度画像を閲覧できるように、提供されている。高解像度ＤＩＣＯＭ画像を閲覧するために、ＺＦＰビューアは、フォームファクタまたはクライアント装置が画像表示する正確なビューポートに基づき、クライアント装置に対して、画像をリクエストする。例えば、携帯またはハンドヘルドで表示するために取得した画像は、通例、ハンドヘルド装置の画像サイズよりも大きな「通常」またはデフォルト表示サイズの画像等、計算処理された放射線撮像（ＣＲ）マンモグラフィ画像である。例えば、このような画像は、より大きなオーダとなりうる（例えば、１メガピクセル（Ｍｐｘｌ）対１０Ｍｐｘｌ）。
この状況で、ＺＦＰストリーミングコンポーネントは、画像が表示される特定サイズのビューポートを備えたクライアント装置から、リクエストを受信する。画像がクライアントへ送信される前に、サーバ上で、画像のサイズが変更される。そして、適切なサイズの画素群が、クライアント装置へ表示のために送信され、クライアント装置では拡縮が不要である。サーバで適切にサイズが調整されて、帯域幅およびリソースが、クライアント装置に関して保存される。
ある種の実施例では、可逆画像データは、クライアント装置で視認可能である。可逆画像を見られるように、クライアント装置は、画像の元の画素データを保持している。元の画像の画素データは、符号変換方法（圧縮／伸張等）、未処理でのデータ転送等により、提供可能である。
図６に、可逆画像データをクライアント装置へストリーミングする実施形態の方法６００のフローチャートである。ブロック６１０では、クライアント装置（例えば、ウェブクライアント２４０）からの画像のリクエストが、ＺＦＰストリーミングコンポーネントで受信される（例えば、画像データ配信クライアント２６４へと、次に画像データ配信システム２７０へと送出される）。クライアントからのリクエストには、その画像に対して利用可能なビューポートの表示サイズが含まれる。ブロック６２０では、ビューポートの表示サイズが、ＺＦＰストリーミングコンポーネントによるリクエストにより特定される。
ブロック６３０では、リクエストされた画像が取得される（例えば、エンタープライズアーカイブ等から）。ブロック６４０では、画像は、リクエストされたビューポートサイズ／解像度にしたがって、ＺＦＰストリーミングコンポーネントによりサイズ変更される。ブロック６５０では、リクエストされた解像度／ビューポートサイズに対応して特にサイズ変更された画像が、クライアント装置へ送信される。ある種の実施例では、特定の解像度と元の画像寸法との差が無視できるものである場合、元の画像がクライアントへ送信される。
ブロック６６０では、可逆に圧縮された元の画素データ（例えば、ポータブルネットワークグラフィックス（ＰＮＧ）データ、画像交換フォーマット（ＧＩＦ）データ等）が、サーバからクライアントへ送信される。元の画素データを送信することにより、ユーザが画像をクライアント装置で拡縮する場合、元の画素データは、さらに高いズーム倍率および測定のための精度を維持するために利用される。
ブロック６７０では、クライアント装置が完全に可逆な画像の画素データを受信すると、ブロック６５０で送信された解像度低減画像が、元の画素情報へと「アップグレード」（例えば、置換）可能となる。実施形態の方法６００を用いて、小型のクライアント装置は、大きな画像を閲覧することができる。初期画像を提供することにより、ユーザは、閲読を開始することができるようになり、ユーザが画像の画素情報を直接操作することを希望する場合には、可逆な元の画素情報をクライアント装置上で入手可能となる。
ＶＩ．画像表示用のＳＶＧ対応ＤＩＣＯＭ ＧＳＰＳ
ＧＳＰＳ（グレースケールソフトコピープレゼンテーションステート）は、ＤＩＣＯＭ画像の変更された表現を格納するフォーマットであり、ウィンドウ／グレースケール画像に対するレベル調節、コメント、ズーム調整、回転、その他を含む。ＤＩＣＯＭ自体が本来バイナリであるため、このプレゼンテーションステートは、ＤＩＣＯＭにおいて純粋なバイナリフォーマットで格納される。しかしながら、このバイナリフォーマットは、ウェブブラウザにおいて直接的に実装するには、非常に不便なものである。この問題を解決するため、ＺＦＰビューアにおいて、元々はＤＩＣＯＭ ＧＳＰＳとして格納された要素は、よりウェブを重視した標準フォーマット：ＳＶＧ（スケーラブル‐ベクター‐グラフィックス）へと変換される。ＳＶＧにより、ベクタデータ、カスタマイズされたメタ情報、およびＸＭＬフォーマットを読取／パーズする単体中のカスタマイズされたメタ情報等、様々なスカラー要素を格納可能となる。データ格納要件が類似しているため、ＳＶＧは、ＧＳＰＳに類似するものとして作用する。ある種の実施例では、ウェブブラウザ内で、外部ツールやプラグインなしで、ＧＳＰＳがパーズされ、レンダリングされ、変更される。
ＶＩＩ．プログラム可能ワークステーション機能
ある種の実施例では、プログラム可能クライアントワークステーション機能が、ウェブソケットトランスポート層を用いて実装可能である。多くの場合、複雑な機能またはリソース集約的アプリケーションが、ワークステーション上に展開する必要がある場合、アプリケーションが、実行可能（ＥＸＥ）、ライブラリ（ＤＬＬ）、またはハードウェアの一部として直接実行可能であってコードの実行前に「変換」されない他の展開形式（例えば、ＪａｖａＳｃｒｉｐｔ）で展開する。また、アプリケーションコードは、ウェブサイトにより利用されるべきコードの場合（例えば、ＡｃｔｉｖｅＸ）、ＣＯＭ対応方法の呼出を通じて呼出可能である。しかしながら、これらの実装には、ウェブブラウザで実行され、および／またはクライアント装置上のオペレーティングシステム（例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ８およびＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ １０では、特に「デスクトップ」モードで実行されない限り、プラグインがブラウザにより禁止されるようになっている）と対話する多くのセキュリティ要件を伴う。さらに、多くのコンポーネント（例えば、ＡｃｔｉｖｅＸコンポーネント）は、クライアント上で実行可能とする信号送信を必要とする。
ある種の実施例では、ＺＦＰビューアは、ウェブソケットを用いる。ウェブソケットは、最近のウェブブラウザにより完全にサポートされ、ウェブブラウザが、クライアント装置と直接的に対話することができる。直接インタラクションは、クライアント装置を起動することにより達成され、クライアント装置上で、サービスまたはインストール可能コンポーネントを実行する。インストール可能コンポーネントまたはサービスは、クライアント装置の事前定義された通信ポート上で「リッスン」モードとされる。クライアント上のウェブアプリケーションが起動すると、リスニング中のコンポーネント／サービスは、ＺＦＰシステムにおける事前定義されたウェブソケットポート上で接続を開くためにポーリングを行う。
ＺＦＰシステムで接続が確立すると、クライアントアプリケーションは、ＺＦＰシステム上に展開したウェブソケットサーバで定義された機能（例えば、ウェブソケット接続マネージャ２５１）にアクセスすることが可能となる。例えば、クライアントアプリケーションは、全機能をアーカイブすることができる。これらの機能は、ブラウザ内でコードを直接実行する制約やセッションについて追加のセキュリティ認証なしに、ＡｃｔｉｖｅＸコンポーネントで等価にラッピング可能である。ある種の実施例では、これらの機能は、クライアントおよびサーバ間で共有されたインターフェイス内で定義されている。クライアントインターフェイスは、例えば、サーバ上のウェブソケットにより実装される擬似サービス層と緩やかに連絡している。
ＶＩＩＩ．遠隔関数変換
ある種の実施例では、ウェブソケットを介してのＪａｖａＳｃｒｉｐｔ（商標）遠隔関数変換が提供される。「遠隔処理」または遠隔方法呼出は、例えば、．ＮＥＴ、Ｊａｖａ、および他の言語内で定義されている。ある種の実施例では、遠隔関数変換（例えば、ＪａｖａＳｃｒｉｐｔで実装）が定義されて変換されて、クライアント装置上で実行される方法が、さらに関連する処理および／または実行のために、単純なＪａｖａＳｃｒｉｐｔコードクライアントを呼び出して、カプセル化ウェブソケット接続を介してＺＦＰサーバへルーティングすることが可能となる。そして、結果または戻り値は、ウェブソケット接続によりクライアントへとルーティングされる。
図７に、クライアント装置上で遠隔機能を実行しやすくするための実施形態の方法７００のフローチャートを示す。ブロック７１０では、リクエストが、クライアント装置におけるスクリプトまたは他のコードの最初の実行を起動する。ブロック７２０では、実行がサーバまたは他のＺＦＰシステムへルーティングされる。例えば、基本スクリプトが、クライアント装置上で処理を開始するが、所望の処理をさらに関連して実行するために、サーバへの接続を起動する。ある種の実施例では、サーバへのルーティングは、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔオブジェクト記法）を用いてメソッド呼出に連番を振るとともにデータにおける連番が付されたブロックをウェブソケット接続を介してサーバ送出することにより、実行される。
ブロック７３０では、起動した機能は、クライアントではなくサーバ上で実行される。例えば、サーバは、データにおける受信したブロックを非直列化することができ、ゼロフットプリントの実施例では、呼出方法（例えば、その．ＮＥＴコード内）のために適切なマッピング属性を発見することができる。そして、サーバは、識別／マッピングコードを実行する。
ブロック７４０では、結果がクライアントへルーティングされる。例えば、呼び出されたコードからの戻り値が、ＪＳＯＮへと直列化されて、ウェブソケット接続によりクライアントへと返送され、往復が完結する。ブロック７５０では、結果は、クライアント装置で利用される。例えば、画像データの表示および／または操作は、クライアント装置におけるブラウザに反映されている。
ＩＸ．多重レベルキャッシュ中段
ある種の実施例では、メモリ、ディスクおよび格納された供給元により分割された多重レベル中段キャッシュが提供される。キャッシュは、例えば、ＺＦＰ中段２５０（例えば、多層サーバキャッシュ２６６）の一部として機能することができる。ＺＦＰは、このカスタムキャッシュにより、容易に展開することができ、クライアント装置は、画像の供給元から都度画像を取得することなく、迅速に画像にアクセスすることができる。ＺＦＰ中段サーバ２５０の実施例では、多重レベルキャッシュが実装されて、アクセス時間および信頼性が向上している。
図８に示すように、実施例の多重レベルまたは多層キャッシュ８００は、３つのレベルを含む。すなわち、メモリ層８１０、ディスク層８２０、および供給層８３０である。
メモリ層８１０は、最速層であり、本実施例の３層のうち使用可能容量が最小である。メモリ層８１０は、「メイン」メモリまたは中段サーバ（例えば、中段２５０）におけるメインメモリの一部である。メモリ層８１０は、ＺＦＰサーバのキャッシュ用に確保されている。メモリキャッシュレベル８１０は、例えばＺＦＰビューア８４０が迅速にアクセスするデータ用に、用いられている。
ディスク層８２０は、中速層であり、使用可能容量が他層と比べて中間的すなわち中程度である。ディスク層８２０は、例えば、ＺＦＰサーバのハードディスク空間である。ディスク層８２０は、ＺＦＰ中段２５０やメモリマップファイル等に、ファイルをページングすることができる。ディスク層８２０については、キャッシュ（即時メモリ）の第１層８１０よりも、アクセスが著しく低速であるが、使用可能容量がはるかに多くなっている。キャッシュレベル８２０は、キャッシュ８００上にしばらくの間（例えば、所定の時間閾値より長く）存在したデータ（おそらく、このデータは、これ以上リクエストされることがない）のために用いられる。
供給層８３０は、最低速層であり、データの元々の場所のことである。ある種の実施例では、元々のあるいは供給元のデータ８５０へのポインタが、ＺＦＰキャッシュ８００の供給層８３０に保持されており、オンラインでデータ取得のリクエストを受けると、ポインタを使用してデータをその元々の場所８５０（例えば、エンタープライズアーカイブ２９０）からキャッシュへと移行させるようになっている。元々の場所には、本来、画像がモダリティにより格納されている。例えば、供給元のキャッシュレベル８３０は、主として、オンライン移動の可能性が低いデータのために用いられる。しかしながら、そのデータがリクエストされた場合、供給元キャッシュ８３０内のポインタにより、リクエストされた情報に対して比較的迅速にアクセスできるようになっている。
キャッシュ８００における複数の層８１０，８２０，８３０は、別々の物理構造として実装されているものの、論理的に編成かつ調整されていて、例えば、いずれかあるいは全てのレベルにおいて、関連づけ、検索、取得、更新および／または他の変更が可能となっている。
多重レベルキャッシュ８００を実装することにより、ＺＦＰ中段サーバ２５０は、様々な分量の調査対象を、多数のユーザに対して、効率的にホスティングすることができる。図９に、多重レベルキャッシュ内にデータを保存してそのデータにアクセス可能とする、実施形態の方法９００のフローチャートを示す。ブロック９１０では、データのリクエストが受信される。例えば、ＺＦＰビューアは、画像データおよび／またはメタデータのリクエストを受信する。ブロック９２０では、多層キャッシュ８００にアクセスして、データを取得する。
ブロック９３０では、メモリ層８１０が検索され、高速アクセスメモリキャッシュ８１０におけるリクエストされたデータが特定される。データがメモリ層８１０内にあった場合、ブロック９７０では、データは、リクエスト元のアプリケーションに対して提供される。
リクエストされたデータがメモリ層８１０になければ、ブロック９４０では、ディスク層８２０が検索されて、リクエストされたデータが特定される。データがディスク層８２０にあれば、ブロック９７０では、データが、リクエスト元のアプリケーションに対して提供される。
リクエストされたデータがディスク層８２０にない場合、ブロック９５０では、供給層８３０が検索されて、リクエストされたデータが特定される。例えば、供給層８３０が検索されて、リクエストされたデータを格納した場所へのポインタが特定される。多くの場合、例えば、リクエストされたデータが、中段サーバ２５０のキャッシュ８００におけるメモリ層８１０にもディスク層８２０にもない場合、リクエストされたデータは、供給層８３０内のポインタにより特定される他の供給元システムにあることになる。ブロック９６０では、供給元装置にクエリが実行され、供給層８３０内のポインタに基づいてデータが取得される。ブロック９７０では、データが、リクエスト元のアプリケーションに対して提供される。データがない場合、ブロック９８０では、エラーが生成される。
例えば、ＥＡ２９０が供給元装置であって、ある画像データが取得可能であることを示している場合、実際にはデータがオフライン記憶部にあると（Ｃｅｎｔｅｒａ（商標）アーカイブ等）、所望の画像データは、取得可能となる前に、まず供給元システム（例えば、アーカイブ２９０）に対してオンラインで送られる。
Ｘ．インテリジェントウェブブラウザクライアント互換性ワークフロー
多くのウェブサイトでは、クライアント側またはサーバ側の２つの場所のいずれかで互換性検知コードが提供されている。クライアント側の互換性検知では、ツール（「ｍｏｄｅｒｎｉｚｅｒ．ｊｓ」等）がクライアント互換性を検知し、１つまたは複数のフラグをイネーブルとして、イネーブルフラグに基づいてコードを実行する。この手法による問題は、現在実行中のクライアントアプリケーションに無関係なために実行されない「デッドコード」が、クライアント装置内に多数あることである。サーバ側では、サーバに接続したクライアントの種類についての「最適推測」を行うサーバにより、クライアントからサーバへ送られた１つまたは複数のハイパーテキスト転送プロトコル（ＨＴＴＰ）変数に基づいて互換性が判定される。変数には、ブラウザのバージョン、基本的なクライアントハードウェア情報等が含まれる。しかしながら、このサーバ側の互換性検知手法は、多くの場合、サーバは、クライアントが対応している機能とこれらの機能に関連したリターンコードのみのマップを保持しているはずなので、とても正確とはいえない。
不正確な互換性検知により、機能が失われ、および／または予期せぬ結果が生じうる。互換性検知は、あるものに互換性がないことを特定するだけでなく、例えば、いかなる場合にも製品が機能しないということがないように、フォールバック技術を提供する。例えば、ＷｅｂＧＬ機能の存在検知／この機能に対応することは、互換性検知の一部となりうる。ＷｅｂＧＬ機能は、ＪａｖａＳｃｒｉｐｔエンジンに利用することができない。ブラウザにおいてＷｅｂＧＬが利用可能であると検知した場合、ブラウザはＷｅｂＧＬ機能を実行することができる。利用可能でないと検知した場合、ビューアは、Ｃａｎｖａｓレンダリング等、似ているが異なる特性を用いて、同一の機能を実装することができる。
ある種の実施例では、「インテリジェント」互換性検知のゼロフットプリント手法が提供される。図１０に、ＺＦＰビューアの互換性検知を容易にする実施例の方法１０００のフローチャートを示す。ブロック１０１０では、クライアントビューアは、コンテンツにおけるあるページまたは画面をリクエストする。例えば、ウェブクライアント（例えば、ブラウザ２４０）は、ユーザの入力に基づき、コンテンツにおけるあるページをリクエストし、このリクエストは、ＺＦＰビューア（例えば、ＺＦＰビューア２１０）を介して伝達される。ブロック１０２０では、クライアントに、導入ページが提供される。このページは、案内ページであり、クライアントに状態の通知または最初の情報を提供するとともに、バックグラウンド検出コード（例えば、「ｍｏｄｅｒｎｉｚｅｒ．ｊｓ」等）が実行されており（例えば、ＺＦＰビューア２１０の互換性検知部２１３による）クライアント互換性を正確に検出している。ブロック１０３０では、導入画面が表示されるとともに、互換性検知がバックグラウンドで実行される。例えば、互換性検知は、クライアントで利用可能な機能を特定するための現行のＪａｖａＳｃｒｉｐｔドキュメントオブジェクトモデル（ＤＯＭ）である要素を解析する。
ブロック１０４０では、クライアントは、導入ページから、クライアントが元々リクエストしていたページやコンテンツ画面へと進む。ある種の実施例では、リクエストされたページがサーバ側でレンダリングされたページなので、元々クライアントで検知した値は、サーバへと送信される。互換性検知結果（例えば、クライアントウェブブラウザのバージョン、あるウェブページの機能へのクライアントブラウザの対応等）は、例えば、サーバへ送られた情報、およびサーバによりレンダリングされたものを考慮したものである。
ブロック１０５０では、クライアントからサーバへ送られた入力値に基づき、サーバは、クライアントで表示されるクライアントのページを正確にレンダリングする。ブロック１０６０では、サーバ側でレンダリングされたコンテンツのページが、表示用にクライアントに対して提供される（例えば、ＺＦＰビューア２１０およびウェブクライアント２４０を通じて）。
このように、ある種の実施例では、互換性情報がクライアントから到来するので、より効率的にレンダリングされたコンテンツのウェブページ（例えば、「デッドコード」を低減または除去）およびより正確な互換性が得られる。
ＸＩ．結論
このように、ある種の実施例では、医療画像（例えば、ＤＩＣＯＭ医療画像）の表示、操作、リフォーマット等を容易にするゼロフットプリントプラットフォームおよびビューアが、クライアントでのインストールや、クライアントでのビューアコンポーネントのダウンロード等を要件とすることなく、提供される。これらは、適切なブラウザ（例えば、ＨＴＭＬ５ブラウザ）に対応可能であれば、どのようなハードウェア上でも仮想的に実行可能である。ある種の実施例では、画像レンダリングおよび操作を容易にするビューアコンポーネントが提供されるとともに、画像の画素、メタデータ、および非画像オブジェクトについて、データ（例えば、ＤＩＣＯＭデータ）の符号変換に対応した中段サーバが提供される。この新規のアーキテクチャを用いることにより、例えば、クライアントシステムに別途コンポーネントを追加することなく、ＤＩＣＯＭ画像調査対象をウェブに対応させて効率的に閲覧することができるようになる。
図１１は、ここで説明したシステムおよび方法を実装するために利用可能な、実施例のプロセッサシステム１１１０のブロック図である。図１１に示すように、プロセッサシステム１１１０は、相互接続バス１１１４に接続したプロセッサ１１１２を備える。プロセッサ１１１２は、例えば、任意の適切なプロセッサ、処理部、またはマイクロプロセッサであってもよい。図１１には示していないが、システム１１１０は、マルチプロセッサシステムであってもよく、このため、１つまたは複数の追加のプロセッサを備えてもよい。このプロセッサは、プロセッサ１１１２と同一または類似のものであり、相互接続バス１１１４に通信可能に接続している。
図１１のプロセッサ１１１２は、チップセット１１１８に接続している。このチップセットは、メモリコントローラ１１２０と入力／出力（「Ｉ／Ｏ」）コントローラ１１２２を備える。周知のように、チップセットにより、通例、Ｉ／Ｏおよびメモリ管理機能ならびに複数の一般的用途が提供され、ならびに／または、チップセット１１１８に接続した１つまたは複数のプロセッサからアクセス可能であってこのプロセッサが利用する、専用レジスタ、タイマ等が提供される。メモリコントローラ１１２０は、プロセッサ１１１２（または、複数のプロセッサがある場合はこれらのプロセッサ）をシステムメモリ１１２４および大容量記憶メモリ１１２５にアクセス可能とする機能を実行する。
システムメモリ１１２４は、例えば、スタティックランダムアクセスメモリメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、フラッシュメモリ、読取専用メモリ（ＲＯＭ）等、任意の所望の型の揮発および／または不揮発メモリを、備えていてもよい。大容量記憶メモリ１１２５は、ハードディスクドライブ、光学ドライブ、テープ記憶装置等、任意の所望の型の大容量記憶装置を、備えていてもよい。
Ｉ／Ｏコントローラ１１２２は、プロセッサ１１１２をＩ／Ｏバス１１３２を介して周辺入力／出力（「Ｉ／Ｏ」）機器１１２６，１１２８およびネットワークインターフェイス１１３０と通信可能とする機能を実行する。Ｉ／Ｏ機器１１２６，１１２８は、例えば、キーボード、ビデオディスプレイまたはモニタ、マウス等、所望の型のＩ／Ｏ機器であってもよい。ネットワークインターフェイス１１３０は、例えば、プロセッサシステム１１１０を他のプロセッサシステムと通信可能とする、イーサネット装置、非同期転送モード（「ＡＴＭ」）装置、８０２．１１装置、ＤＳＬモデム、ケーブルモデム、セルラモデム等であってもよい。
メモリコントローラ１１２０およびＩ／Ｏコントローラ１１２２は、チップセット１１１８内の個別のブロックとして図１１に示されているが、各ブロックが実行する機能は、単一の半導体メモリ内に統合されてもよく、あるいは、２個以上の個別の集積回路を用いて実装されてもよい。
発明の要素、発明のパラダイムおよび発明の方法は、ある例示的な実施形態によって表現されているに過ぎないことが、当業者には理解されるであろう。ただし、本発明の実際の範囲、およびその発明の各要素は選択された実施形態よりもはるかに広く、開発、技術、販売、サービスおよび広範な情報およびコンピュータ化システムへの対応という、広範な領域の文脈において、高負荷および／または高スループットおよび／または高性能および／または分散および／または連携および／または複数の専門に対応する性質のある高度なシステムを特に重視して、個別に検討されるべきものである。
ある種の実施形態では、上述の機能を実装する方法、システム、およびあらゆる機械可読媒体上のコンピュータプログラム製品を意図している。ある種の実施形態は、例えば、現行のコンピュータプロセッサを用いて、または、この目的もしくは他の目的のために組み込まれた専用コンピュータプロセッサによって、または、ハードワイヤードおよび／もしくはファームウェアシステムにより、実装されてもよい。
上述のシステムの１つまたは複数のコンポーネントおよび／または方法の各ステップは、例えば、単独で、または、ハードウェア、ファームウェア、および／またはソフトウェアにおける一連の命令の組み合わせとして、実装されてもよい。ある種の実施形態は、メモリ、ハードディスク、ＤＶＤ、またはＣＤ等のコンピュータ可読媒体上にあって、汎用コンピュータまたは他の処理装置上で実行されるための一連の命令として、提供されてもよい。本発明のある種の実施形態は、方法の各ステップの１つまたは複数を除外してもよく、および／または、各ステップを、上記順番とは異なる順番で実行してもよい。例えば、いくつかのステップは、本発明のある種の実施形態においては、実行されなくともよい。さらに別の実施例として、あるステップが、上記順番とは異なる時間的順番で実行されてもよく、これには同時実行も含まれる。
ある種の実施形態には、コンピュータ実行可能命令を担持もしくはこれを具備したコンピュータ可読媒体、またはそこに格納されたデータ構造が含まれる。このようなコンピュータ可読媒体は、汎用もしくは専用コンピュータ、またはプロセッサを具備した他の装置がアクセスできる、任意の利用可能媒体であってもよい。例として、このようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ、ＣＤ−ＲＯＭもしくは他の光学ディスク記憶部、磁気ディスク記憶部もしくは他の磁気記憶装置、またはコンピュータ実行可能命令もしくはデータ構造の形態で所望のプログラムコードを担持または格納可能であるとともに汎用もしくは専用コンピュータまたはプロセッサを有する他の装置がアクセス可能なあらゆる他の媒体で、構成されていてもよい。また、上記内容の組み合わせも、可読媒体の範囲に含まれる。コンピュータ実行可能命令は、例えば、汎用コンピュータ、専用コンピュータまたは専用処理装置に、ある機能または機能群を実行させる、命令およびデータにより構成されてもよい。
一般に、コンピュータ実行可能命令には、特定のタスクを実行するかあるいは特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造等が含まれる。コンピュータ実行可能命令、関連するデータ構造、およびプログラムモジュールは、ここに開示したある方法の各ステップおよびシステムを実行するためのプログラムコードの実施例を表している。このような実行可能命令または関連したデータ構造の特定のシーケンスは、このようなステップで記述された機能を実装するための対応する動作例を表している。
本発明の実施形態は、プロセッサを具備した１つまたは複数のコンピュータへの論理接続を用いたネットワーク環境として実施されてもよい。論理接続には、ローカルエリアネットワーク（ＬＡＮ）およびワイドエリアネットワーク（ＷＡＮ）が含まれていてもよく、これらは例示としてここに提示されており、限定にはならない。このようなネットワーク環境は、事務所規模または企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいて一般的であり、広範な個々の通信プロトコルを用いてもよい。当業者は、このようなネットワークコンピューティング環境は、通例、多くの種類のコンピュータシステム構成を包含することになり、パーソナルコンピュータ、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサ型またはプログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含むことを、理解するであろう。また、本発明の実施形態は、通信ネットワーク（ハードワイヤード接続、無線接続により、あるいは、ハードワイヤードまたは無線接続の組み合わせにより）を介して接続したローカルおよびリモート処理装置によりタスクが実行される、分散コンピューティング環境で実施されてもよい。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートメモリ記憶装置の双方に、配置されてもよい。
本発明の実施形態のシステム全体または一部を実装した例示的システムは、処理部と、システムメモリと、システムメモリから処理部までの様々なシステムコンポーネントを接続するシステムバスとを具備したコンピュータの形式で、汎用コンピュータ処理装置を、備えてもよい。システムメモリは、読取専用メモリ（ＲＯＭ）およびランダムアクセスメモリ（ＲＡＭ）を備えてもよい。また、コンピュータは、磁気ハードディスクに対して読み書きする磁気ハードディスクドライブと、リムーバブル磁気ディスクに対して読み書きする磁気ディスクドライブと、ＣＤ−ＲＯＭまたは他の光学媒体等のリムーバブル光学ディスクに対して読み書きする光学ディスクドライブとを、備えてもよい。ドライブおよび関連するコンピュータ可読媒体により、コンピュータ実行可能命令、データ構造、プログラムモジュール、およびコンピュータ用の他のデータの不揮発記憶が提供される。
本発明について、ある種の実施形態について説明したが、当業者には、本発明の範囲を逸脱することなく、様々な変更がなされ、均等なものが代用されうることが、理解されるであろう。さらに、本発明の範囲を逸脱することなく、特定の状況や材料を、本発明の説明内容に適合させるために、多くの修正がなされうる。したがって、本発明は、開示された特定の実施形態に限定されるものではなく、本発明は、添付の特許請求の範囲に含まれるあらゆる実施形態を含むことが、意図されている。
１００ ＺＦＰビューア
１１０ ビューアコンポーネント
１２０ 中段サーバ
２００ システム
２１０ ＺＦＰビューア
２２０ データマネージャ
２３０ 表示パイプライン
２４０ ウェブクライアント
２５０ ＺＦＰ中段
２６０ データマネージャ
２７０ データ配信システム
２８０ ディスク記憶部
２９０ データ記憶部、ＥＡ、アーカイブ
２９５ データ供給元
８４０ ＺＦＰビューア
１１１０ プロセッサシステム

Claims (20)

  1. クライアント装置に特別な構成がなくとも、画像コンテンツをレンダリングして前記クライアント装置に提供する表示パイプラインを含み、クライアントブラウザによって、前記画像コンテンツを表示するとともに前記画像コンテンツの操作を容易にするゼロフットプリント医療画像ビューアと、
    前記画像コンテンツを記憶部から取得して、前記画像コンテンツを格納フォーマットからブラウザ適合フォーマットへ変換する中段サーバと
    を備え、
    前記ゼロフットプリント医療画像ビューアは、画像コンテンツを前記中段サーバから取得する第１のデータマネージャと、該第１のデータマネージャのどのコンポーネントを取得してデータに作用させるか決定する第１の委任部を含み、前記中段サーバは、前記画像コンテンツを取得して、前記画像コンテンツを、前記格納フォーマットから前記ブラウザ適合フォーマットへとフォーマットする第２のデータマネージャを含み、前記第２のデータマネージャは、複数のデータインターフェイスの中から第２の委任部によって選択されたデータインターフェイスを介して、前記第１のデータマネージャと通信して、表示用の前記画像コンテンツの転送を容易にし、
    前記ゼロフットプリント医療画像ビューア及び前記中段サーバは、
    前記中段サーバを用いて、前記ゼロフットプリント医療画像ビューアからの画像表示のリクエストを取得し、
    前記中段サーバを用いて、前記画像表示のリクエストに基づいて、前記画像コンテンツに対するメタデータリクエストを生成し、
    前記中段サーバを用いて、データ記憶部に対して前記メタデータリクエストを送信し、
    前記データ記憶部から、前記メタデータリクエストに基づくメタデータレスポンスを受信し、
    前記中段サーバを用いて、前記画像コンテンツと関連する１つまたは複数のリクエストトークンを含む調査対象概要を前記メタデータレスポンスに基づいて生成し、
    前記調査対象概要を介し、前記リクエストトークンのうちの少なくとも一つの選択に基づいて前記中段サーバを用いて、前記データ記憶部から画像データを取得し、
    前記ゼロフットプリント医療画像ビューアを用いて、前記画像データを用いて前記画像コンテンツをレンダリングし、
    前記ゼロフットプリント医療画像ビューアでは、前記画像コンテンツを提供する、ように構成されるシステム。
  2. 前記ゼロフットプリント医療画像ビューアは、前記クライアントブラウザによって画像閲覧を容易にするＨＴＭＬ５対応ビューアを備える請求項１記載のシステム。
  3. 前記第１および第２のデータマネージャは、ウェブソケット接続を利用して、前記中段サーバと前記ゼロフットプリント医療画像ビューアとの間でデータを転送し、前記ウェブソケット接続が利用可能でない場合、ウェブサービス接続が転送用のフォールバックとして利用可能である請求項１記載のシステム。
  4. 前記第１のデータマネージャは、前記第２のデータマネージャとともに動作して、クライアント装置の互換性を特定する請求項１記載のシステム。
  5. 前記画像コンテンツをアーカイブから前記中段サーバへ提供するストリーミング画像配信システムを、さらに備える請求項１記載のシステム。
  6. 前記第１および第２のデータマネージャは、前記クライアント装置での使用可能メモリに基づき、前記中段サーバを用いてデータの順方向および逆方向へのページングを容易にする請求項１記載のシステム。
  7. 前記第１および第２のデータマネージャは、前記クライアントブラウザでのＤＩＣＯＭ画像コンテンツに加えて、メタ情報および非画像オブジェクトのうちの少なくとも１つの送信、フォーマット、および表示を容易にする請求項１記載のシステム。
  8. プロセッサにより実行されるコンピュータプログラムコードを含む有形のコンピュータ可読記憶媒体であって、前記コンピュータプログラムコードは、実行されると、システムを実現し、前記システムは、
    クライアント装置に特別な構成がなくとも、画像コンテンツをレンダリングして前記クライアント装置に提供する表示パイプラインを含み、クライアントブラウザによって、前記画像コンテンツを表示するとともに前記画像コンテンツの操作を容易にするゼロフットプリント医療画像ビューアと、
    前記画像コンテンツを記憶部から取得して、前記画像コンテンツを格納フォーマットからブラウザ適合フォーマットへ変換する中段サーバと
    を備え、
    前記ゼロフットプリント医療画像ビューアは、画像コンテンツを前記中段サーバから取得する第１のデータマネージャと、該第１のデータマネージャのどのコンポーネントを取得してデータに作用させるか決定する第１の委任部を含み、前記中段サーバは、前記画像コンテンツを取得して、前記画像コンテンツを、前記格納フォーマットから前記ブラウザ適合フォーマットへフォーマットする第２のデータマネージャを含み、前記第２のデータマネージャは、複数のデータインターフェイスの中から第２の委任部によって選択されたデータインターフェイスを介して、前記第１のデータマネージャと通信して、表示用の前記画像コンテンツの転送を容易にし、
    前記ゼロフットプリント医療画像ビューア及び前記中段サーバは、
    前記中段サーバを用いて、前記ゼロフットプリント医療画像ビューアからの画像表示のリクエストを取得し、
    前記中段サーバを用いて、前記画像表示のリクエストに基づいて、前記画像コンテンツに対するメタデータリクエストを生成し、
    前記中段サーバを用いて、データ記憶部に対して前記メタデータリクエストを送信し、
    前記データ記憶部から、前記メタデータリクエストに基づくメタデータレスポンスを受信し、
    前記中段サーバを用いて、前記画像コンテンツと関連する１つまたは複数のリクエストトークンを含む調査対象概要を前記メタデータレスポンスに基づいて生成し、
    前記調査対象概要を介し、前記リクエストトークンのうちの少なくとも一つの選択に基づいて前記中段サーバを用いて、前記データ記憶部から画像データを取得し、
    前記ゼロフットプリント医療画像ビューアを用いて、前記画像データを用いて前記画像コンテンツをレンダリングし、
    前記ゼロフットプリント医療画像ビューアでは、前記画像コンテンツを提供する、ように構成されるコンピュータ可読記憶媒体。
  9. 前記ゼロフットプリント医療画像ビューアは、前記クライアントブラウザによって画像閲覧を容易にするＨＴＭＬ５対応ビューアを備える請求項８記載のコンピュータ可読記憶媒体。
  10. 前記第１および第２のデータマネージャは、ウェブソケット接続を利用して、前記中段サーバと前記ゼロフットプリント医療画像ビューアとの間でデータを転送し、前記ウェブソケット接続が利用可能でない場合、ウェブサービス接続が転送用のフォールバックとして利用可能である請求項８記載のコンピュータ可読記憶媒体。
  11. 前記第１のデータマネージャは、前記第２のデータマネージャとともに動作して、クライアント装置の互換性を特定する請求項８記載のコンピュータ可読記憶媒体。
  12. 前記システムは、前記画像コンテンツをアーカイブから前記中段サーバへ提供するストリーミング画像配信システムを、さらに備える請求項８記載のコンピュータ可読記憶媒体。
  13. 前記第１および第２のデータマネージャは、前記クライアント装置での使用可能メモリに基づき、前記中段サーバを用いてデータの順方向および逆方向へのページングを容易にする請求項８記載のコンピュータ可読記憶媒体。
  14. 前記第１および第２のデータマネージャは、前記クライアントブラウザでのＤＩＣＯＭ画像コンテンツに加えて、メタ情報および非画像オブジェクトのうちの少なくとも１つの送信、フォーマット、および表示を容易にする請求項８記載のコンピュータ可読記憶媒体。
  15. ゼロフットプリント医療画像ビューアでリクエストを受信し、クライアント装置上のクライアントブラウザにて画像調査対象を起動するステップであって、前記ゼロフットプリント医療画像ビューアは、前記クライアント装置に特別な構成がなくとも、前記画像調査対象中の画像コンテンツをレンダリングしてクライアント装置に提供する表示パイプラインを含み、前記クライアントブラウザによって、前記画像コンテンツを表示するとともに前記画像コンテンツの操作を容易にするステップと、
    リクエストされた前記画像コンテンツを、記憶部から中段サーバを介して取得するステップと、
    前記中段サーバを用いて、前記ゼロフットプリント医療画像ビューアからの画像表示のリクエストを取得するステップと、
    前記中段サーバを用いて、前記画像表示のリクエストに基づいて、前記画像コンテンツに対するメタデータリクエストを生成するステップと、
    前記中段サーバを用いて、データ記憶部に対して前記メタデータリクエストを送信するステップと、
    前記データ記憶部から、前記メタデータリクエストに基づくメタデータレスポンスを受信するステップと、
    前記中段サーバを用いて、前記画像コンテンツと関連し前記ゼロフットプリント医療画像ビューアを介しての表示に対する１つまたは複数のリクエストトークンを含む調査対象概要を生成するステップと、
    前記調査対象概要を介し、前記リクエストトークンのうちの少なくとも一つの選択に基づいて前記中段サーバを用いて、前記データ記憶部から画像データを取得するステップと、
    前記中段サーバにより、前記画像コンテンツを、格納フォーマットからブラウザ適合フォーマットへ変換するステップと、
    変換された前記画像コンテンツを、前記ゼロフットプリント医療画像ビューアに提供するステップと、
    変換された前記画像コンテンツの前記クライアントブラウザでの表示を、前記ゼロフットプリント医療画像ビューアによって容易にするステップと
    を含み、
    前記ゼロフットプリント医療画像ビューアは、前記画像コンテンツを前記中段サーバから取得する第１のデータマネージャと、該第１のデータマネージャのどのコンポーネントを取得してデータに作用させるか決定する第１の委任部を含み、前記中段サーバは、前記画像コンテンツを取得して、前記画像コンテンツを、前記格納フォーマットから前記ブラウザ適合フォーマットへフォーマットする第２のデータマネージャを含み、前記第２のデータマネージャは、複数のデータインターフェイスの中から第２の委任部によって選択されたデータインターフェイスを介して、前記第１のデータマネージャと通信して、表示用の前記画像コンテンツの転送を容易にする方法。
  16. 前記第１および第２のデータマネージャは、ウェブソケット接続を利用して、前記中段サーバと前記ゼロフットプリント医療画像ビューアとの間でデータを転送し、前記ウェブソケット接続が利用可能でない場合、ウェブサービス接続が転送用のフォールバックとして利用可能である請求項１５記載の方法。
  17. 前記第１および第２のデータマネージャにより、クライアント装置の互換性を特定するステップをさらに含む請求項１５記載の方法。
  18. 最初に、前記調査対象概要を、前記クライアントブラウザに提供した後に、前記画像調査対象についてのレンダリングした画像の完全な一組を提供するステップをさらに含む請求項１５記載の方法。
  19. 前記第１および第２のデータマネージャは、前記クライアント装置での使用可能メモリに基づき、前記中段サーバを用いてデータの順方向および逆方向へのページングを容易にする請求項１５記載の方法。
  20. 前記クライアントブラウザにて、ＤＩＣＯＭ画像コンテンツに加えて、メタ情報および非画像オブジェクトのうちの少なくとも１つの送信、フォーマット、および表示を、前記第１および第２のデータマネージャにより容易にするステップをさらに含む請求項１５記載の方法。
JP2013237660A 2012-11-21 2013-11-18 システム、コンピュータ可読記憶媒体及び方法 Active JP6313020B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/683,211 US20140143298A1 (en) 2012-11-21 2012-11-21 Zero footprint dicom image viewer
US13/683,211 2012-11-21

Publications (2)

Publication Number Publication Date
JP2014102835A JP2014102835A (ja) 2014-06-05
JP6313020B2 true JP6313020B2 (ja) 2018-04-18

Family

ID=49726460

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013237660A Active JP6313020B2 (ja) 2012-11-21 2013-11-18 システム、コンピュータ可読記憶媒体及び方法

Country Status (4)

Country Link
US (1) US20140143298A1 (ja)
EP (1) EP2735982A1 (ja)
JP (1) JP6313020B2 (ja)
CN (1) CN103838813B (ja)

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5972570B2 (ja) * 2011-12-27 2016-08-17 東芝メディカルシステムズ株式会社 医用画像表示装置及び医用画像保管システム
US20130305138A1 (en) * 2012-05-14 2013-11-14 Pacsthology Ltd. Systems and methods for acquiring and transmitting high-resolution pathology images
US9298730B2 (en) * 2012-07-04 2016-03-29 International Medical Solutions, Inc. System and method for viewing medical images
US9465882B2 (en) 2012-07-19 2016-10-11 Adobe Systems Incorporated Systems and methods for efficient storage of content and animation
US9229931B2 (en) * 2012-11-21 2016-01-05 General Electric Company Systems and methods for medical image viewer compatibility determination
US20140172452A1 (en) * 2012-12-14 2014-06-19 Advanced Medical Imaging Development S.R.L. System for processing medical data
US9462089B1 (en) * 2013-03-15 2016-10-04 Kaazing Corporation Communication channels
US20140317109A1 (en) * 2013-04-23 2014-10-23 Lexmark International Technology Sa Metadata Templates for Electronic Healthcare Documents
JP2014225718A (ja) * 2013-05-15 2014-12-04 ソニー株式会社 画像処理装置および画像処理方法
EP3042549A4 (en) * 2013-09-03 2017-04-26 Swissray Asia Healthcare Co., Ltd. Articulating display for a mobile radiographic machine
US20150106344A1 (en) * 2013-10-10 2015-04-16 Calgary Scientific Inc. Methods and systems for intelligent archive searching in multiple repository systems
US9648060B2 (en) 2013-11-27 2017-05-09 General Electric Company Systems and methods for medical diagnostic collaboration
US20150178447A1 (en) * 2013-12-19 2015-06-25 Medidata Solutions, Inc. Method and system for integrating medical imaging systems and e-clinical systems
DE102014207726B4 (de) * 2014-04-24 2023-07-20 Siemens Healthcare Gmbh Effizientes Zugriffsverfahren auf in einer Cloud gespeicherte Bilddaten
JP6035288B2 (ja) * 2014-07-16 2016-11-30 富士フイルム株式会社 画像処理システム、クライアント、画像処理方法、プログラムおよび記録媒体
US20160092446A1 (en) * 2014-09-29 2016-03-31 Vital Images, Inc. Medical imaging viewer caching techniques
US9792957B2 (en) 2014-10-08 2017-10-17 JBF Interlude 2009 LTD Systems and methods for dynamic video bookmarking
US9514274B2 (en) * 2014-11-29 2016-12-06 Infinitt Healthcare Co., Ltd. Layered medical image forming, receiving, and transmitting methods
US10425494B2 (en) * 2014-12-19 2019-09-24 Smugmug, Inc. File size generation application with file storage integration
CN105824852A (zh) * 2015-01-09 2016-08-03 谢儒生 直接操纵医学影像方法
CN104994333A (zh) * 2015-05-29 2015-10-21 上海京颐科技股份有限公司 医学影像中转装置、客户端、传输系统及其传输方法
US10460765B2 (en) 2015-08-26 2019-10-29 JBF Interlude 2009 LTD Systems and methods for adaptive and responsive video
US9837042B2 (en) * 2015-11-19 2017-12-05 Viewsonic International Corporation Projection system with auto-project portable device for displaying images automatically
US10296713B2 (en) 2015-12-29 2019-05-21 Tomtec Imaging Systems Gmbh Method and system for reviewing medical study data
JP7127959B2 (ja) * 2015-12-23 2022-08-30 トムテック イメージング システムズ ゲゼルシャフト ミット ベシュレンクテル ハフツング 医療調査データをレビューするための方法及びシステム
EP3185155B1 (en) 2015-12-23 2020-05-27 TomTec Imaging Systems GmbH Method and system for reviewing medical study data
US11856271B2 (en) 2016-04-12 2023-12-26 JBF Interlude 2009 LTD Symbiotic interactive video
DE102016210312A1 (de) * 2016-06-10 2017-12-14 Siemens Healthcare Gmbh Steuerobjekt zur Steuerung eines Transfers von Dual-Energy-CT-Bilddaten an ein Clientgerät
KR101837844B1 (ko) * 2016-07-13 2018-03-13 주식회사 인피니트헬스케어 Ｖｎａ 시스템에서의 룰 기반 프리페칭 방법
US11081228B2 (en) 2016-09-06 2021-08-03 International Business Machines Corporation Automatic retrospective review of electronic medical records
US11243974B2 (en) * 2016-12-29 2022-02-08 Hyland Switzerland Sarl System and methods for dynamically converting non-DICOM content to DICOM content
JP6809249B2 (ja) 2017-01-23 2021-01-06 コニカミノルタ株式会社 画像表示システム
CN108399072B (zh) * 2017-02-06 2022-08-19 腾讯科技（深圳）有限公司 应用页面更新方法和装置
US10559378B2 (en) 2017-02-17 2020-02-11 Agfa Healthcare Nv Systems and methods for processing large medical image data
US10671659B2 (en) 2017-02-17 2020-06-02 Agfa Healthcare Nv Systems and methods for collecting large medical image data
CN107280625A (zh) * 2017-07-07 2017-10-24 深圳市博盛医疗科技有限公司 一种3d全高清电子腹腔镜系统
CN107948159B (zh) * 2017-11-27 2021-04-20 宁波市科技园区明天医网科技有限公司 一种基于浏览器的医学影像同步显示和诊断操作的方法
JP6633247B1 (ja) * 2018-05-07 2020-01-22 和寛 檜山 診断情報提供装置、方法及びシステム
US11601721B2 (en) 2018-06-04 2023-03-07 JBF Interlude 2009 LTD Interactive video dynamic adaptation and user profiling
JP7047624B2 (ja) * 2018-06-22 2022-04-05 コニカミノルタ株式会社 医用画像表示システム
CN113168904A (zh) 2018-11-20 2021-07-23 阿特瑞斯公司 基于云的放射学评述和工作空间共享
US20200194109A1 (en) * 2018-12-18 2020-06-18 Metal Industries Research & Development Centre Digital image recognition method and electrical device
CN109889493B (zh) * 2019-01-04 2021-08-13 上海七印信息科技有限公司 一种基于WebSocket协议的页面快速访问方法
US11194461B2 (en) * 2019-01-15 2021-12-07 Fujifilm Medical Systems U.S.A., Inc. Smooth image scrolling with dynamic scroll extension
US11579763B2 (en) * 2019-01-15 2023-02-14 Fujifilm Medical Systems U.S.A., Inc. Smooth image scrolling with disk I/O activity optimization and enhancement to memory consumption
US10790056B1 (en) 2019-04-16 2020-09-29 International Medical Solutions, Inc. Methods and systems for syncing medical images across one or more networks and devices
CN111984888A (zh) * 2019-05-24 2020-11-24 阿里巴巴集团控股有限公司 页面渲染方法、装置、电子设备及计算机可读介质
JP7428081B2 (ja) 2020-06-05 2024-02-06 コニカミノルタ株式会社 振り分け装置、画像処理システム及びプログラム
CN111881394B (zh) * 2020-07-28 2024-01-12 万商云集(成都)科技股份有限公司 一种应用中间层的请求处理方法及系统
JP2021047899A (ja) * 2020-12-10 2021-03-25 コニカミノルタ株式会社 画像表示システム
US11380117B1 (en) 2020-12-23 2022-07-05 Abbyy Development Inc. Zero-footprint image capture by mobile device
CN113420245B (zh) * 2021-05-11 2023-10-27 上海幻电信息科技有限公司 页面显示方法及系统
US11882337B2 (en) 2021-05-28 2024-01-23 JBF Interlude 2009 LTD Automated platform for generating interactive videos
US20230036480A1 (en) * 2021-07-22 2023-02-02 Change Healthcare Holdings, Llc Efficient streaming for client-side medical rendering applications based on user interactions
US11538578B1 (en) 2021-09-23 2022-12-27 International Medical Solutions, Inc. Methods and systems for the efficient acquisition, conversion, and display of pathology images
US11934477B2 (en) 2021-09-24 2024-03-19 JBF Interlude 2009 LTD Video player integration within websites
CN116844699A (zh) * 2023-08-29 2023-10-03 神州医疗科技股份有限公司 一种医学影像标注信息的保存和提取方法及系统

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6934698B2 (en) * 2000-12-20 2005-08-23 Heart Imaging Technologies Llc Medical image management system
US20030005464A1 (en) * 2001-05-01 2003-01-02 Amicas, Inc. System and method for repository storage of private data on a network for direct client access
US7032088B2 (en) * 2003-08-07 2006-04-18 Siemens Corporate Research, Inc. Advanced memory management architecture for large data volumes
US20060015497A1 (en) * 2003-11-26 2006-01-19 Yesvideo, Inc. Content-based indexing or grouping of visual images, with particular use of image similarity to effect same
JP2009189541A (ja) * 2008-02-14 2009-08-27 Fujifilm Corp 読影支援装置及び方法、並びに医用ネットワークシステム
US20100010983A1 (en) * 2008-07-11 2010-01-14 Apteryx, Inc. Automated dicom pre-fetch application
US8380809B2 (en) * 2009-03-05 2013-02-19 Siemens Aktiengesellschaft Providing a number of web services for imaging optional medical applications
US8634677B2 (en) * 2009-03-30 2014-01-21 The Regents Of The University Of California PACS optimization techniques
US8701167B2 (en) * 2009-05-28 2014-04-15 Kjaya, Llc Method and system for fast access to advanced visualization of medical scans using a dedicated web portal
US20110131180A1 (en) * 2009-11-27 2011-06-02 Nokia Corporation Method and apparatus for configuring a content object
US20120084350A1 (en) * 2010-10-05 2012-04-05 Liang Xie Adaptive distributed medical image viewing and manipulating systems
US8553965B2 (en) * 2012-02-14 2013-10-08 TerraRecon, Inc. Cloud-based medical image processing system with anonymous data upload and download
US8990325B2 (en) * 2012-04-30 2015-03-24 Cbs Interactive Inc. Real-time and interactive community-based content publishing system

Also Published As

Publication number Publication date
EP2735982A1 (en) 2014-05-28
US20140143298A1 (en) 2014-05-22
CN103838813A (zh) 2014-06-04
JP2014102835A (ja) 2014-06-05
CN103838813B (zh) 2019-03-22

Similar Documents

Publication Publication Date Title
JP6313020B2 (ja) システム、コンピュータ可読記憶媒体及び方法
US20140143299A1 (en) Systems and methods for medical imaging viewing
US9864815B2 (en) Systems and methods for medical image viewer compatibility determination
US20140140589A1 (en) Memory sensitive medical image browser
US20140143271A1 (en) Multi-level medical image viewer memory management
US9704207B2 (en) Administering medical digital images in a distributed medical digital image computing environment with medical image caching
US8775545B1 (en) Image hosting for cross-platform display over a communication network
JP2015529874A (ja) 医用画像を閲覧するためのシステム及び方法
US8856262B1 (en) Cloud-based image hosting
US20130166767A1 (en) Systems and methods for rapid image delivery and monitoring
CA2923964A1 (en) Architecture for distributed server-side and client-side image data rendering
CN107066794B (zh) 用于评估医学研究数据的方法和系统
US11404158B2 (en) Image viewer
US20110179094A1 (en) Method, apparatus and computer program product for providing documentation and/or annotation capabilities for volumetric data
CN111651966A (zh) 数据报告文件生成方法、装置与电子设备
US9135274B2 (en) Medical imaging workflow manager with prioritized DICOM data retrieval
JP2006301965A (ja) 情報処理装置、画像処理装置、画像処理システム及び方法、並びに記憶媒体
Dragan et al. Request redirection paradigm in medical image archive implementation
JP2022528096A (ja) Ｄｉｃｏｍオブジェクトのためのユニバーサルウェブサービス
US10296713B2 (en) Method and system for reviewing medical study data
CN114496175A (zh) 一种医疗图像查看方法、装置、设备和存储介质
US10607735B2 (en) Hybrid rendering system for medical imaging applications
Kohlmann et al. Remote visualization techniques for medical imaging research and image-guided procedures
JP2011061385A (ja) 対話的実時間遠隔可視化システム
US20220392615A1 (en) Method and system for web-based medical image processing

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20161115

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20171121

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20171117

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180202

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180220

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180322

R150 Certificate of patent or registration of utility model

Ref document number: 6313020

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250