JP2015522871A - 医療記録ソフトウエアと高度画像処理の統合 - Google Patents

Abstract

本発明は、画像及び画像処理と医療ソフトウエアの統合に関する。患者の医療情報は、ローカルデバイス内で実行される医療記録及び臨床試験ソフトウエア（ＭＲＣＳ）内に表示され、医療情報は患者の医療処置履歴を含む。患者の表示された医療情報は、ネットワーク上で医療画像処理サーバに送信され、送信される医療情報は患者の患者識別子を含む。患者医療情報と１つ又はそれよりも多くの医療画像の両方がＭＲＣＳ内に表示され、医療画像は、患者に関連付けられ、医療画像処理サーバによってレンダリングされる。画像処理ツールのセットを表すアイコンのセットがＭＲＣＳ内に表示され、ユーザによって起動された時に画像を画像処理サーバによって操作することを可能にする。【選択図】 図３

Description

〔関連出願〕
本出願は、引用によって本明細書に組み込まれる２０１２年５月２１日出願の米国特許仮出願第６１／６４９，４２７号及び２０１２年８月１０日出願の米国特許仮出願第６１／６８１，９２１号の利益を主張するものである。

本発明の実施形態は、一般的に統合医療ソフトウエアシステムに関する。より具体的には、本発明の実施形態は、画像及び／又は画像処理と医療ソフトウエアの統合に関する。

医療ソフトエアが高性能で全世界的になる時に、ソフトウエアパッケージ間の統合はより重要かつ困難であるものになっている。例えば、電子医療記録（ＥＭＲ）又は電子健康記録（ＥＨＲ）が益々一般的になっている。臨床試験ソフトエア、口述筆記ソフトエア、研究ソフトウエア、放射線情報システム（ＲＩＳ）ソフトウエア、病院情報システム（ＨＩＳ）ソフトウエア、画像記録及び通信システム（ＰＡＣＳ）ソフトウエアは、益々一般的になっている医療ソフトウエアの他の例である。

これらの異なるソフトウエアパッケージの急増する使用の問題点の１つは、これらが一般的に異なる販売業者によって作成されてサポートされ、互いに相互作動又は「トーク」しないということである。しかし、医師、技術者、又は管理者が患者の処置をする時に、その患者に関する情報の全てに容易にアクセスする必要があり、いくつかの異なるソフトウエアパッケージを能動的に開く必要なく患者を検索し、次に、関連の患者の情報を検索しなければならない。

特定の患者及び／又は病状に関連付けられた画像を見ることができること及び必要に応じてその画像を操作することができることは特に重要である。これは、患者が定期的な健康診断を受けるか又は臨床試験／研究に参加する条件下で処置されるか否かにかかわらず重要である。

例えば、患者ががんの治療を受ける場合に、患者のＥＭＲは、投薬されている薬物、患者が受けてきた及び受ける予定の処置を示す必要があり、患者の状況を示す必要がある。患者のがんの場所及び大きさ、並びに患者の進行は、これらが走査画像（ＣＴ、ＭＲＩ、超音波など）又は単純なＸ線画像又は実験画像又は写真のような他の画像（例えば、皮膚がんの写真）などであるか否かにかかわらず、画像で最も良く示される場合がある。この患者の医師は、画像をより単純に見たいと思う場合がある。医師は、画像の設定（例えば、ウィンドウ及び／又はレベル設定）を変更し、異なる角度から画像をズーム、パン、測定、見て、３Ｄモデルで画像を見て、３Ｄモデルを回転し、画像をセグメント化し、モデル／画像等における測定又は組織識別を実行し、患者の病状をより良く評価したいと思うことがある。

現在、これは、ＥＭＲ又はＥＨＲソフトウエアパッケージのいずれにおいても実用的ではない。一部のＥＭＲソフトウエアはユーザがＸ線のような静的画像を見ることを可能にしているが、ユーザは、画像を操作し又は適切な対話型ツールによって３Ｄ画像のような高度な画像を見ることはできない。この高度な画像処理を実行するためのフトウエアパッケージは存在するが、現在、これらは、ＭＲ又は他の医療ソフトウエアプラットフォームに統合されていない。高度画像処理ソフトウエアは、大量のデータを処理し、ほとんどの他のタイプのソフトウエアパッケージの容量を超えた処理機能を供給しなければならないので、これは些細なタスクではない。同じ統合の欠如は、臨床試験及び他の医療ソフトウエアパッケージにも存在する。

以下では、ＥＭＲ、ＥＨＲ、及び他の医療記録ソフトウエアをまとめて医療記録ソフトウエア（ＭＲＳ）と呼ぶ。臨床試験又は他の試験ソフトウエアをまとめて臨床試験ソフトウエア（ＣＴＳ）と呼ぶ。医療記録及び／又は臨床試験ソフトウエア（ＭＲＣＳ）という用語は、医療画像との統合が望ましい場合にＣＴＳ及び／又はＭＲＳ又は他の医療ソフトウエアを示すために使用する。

米国特許出願第１２／１９６，０９９号明細書

ＭＲＣＳパッケージと医療画像及び／又は高度画像処理のシームレスな統合に対する必要性が存在する。ユーザは、ＭＲＣＳソフトウエアパッケージを使用している間に別の画像化アプリケーションを起動したいとは思わない。ユーザは、単純に、ＭＲＣＳを使用している間にその特定の患者に関連付けられた画像を見て、必要に応じて画像を操作することを望む。例えば、患者ＸのＥＭＲを見ている心臓内科医は、患者Ｘの心臓血管画像だけ及びそれに対応する心臓ツールだけを見たいと思う。心臓内科医は、複数の患者を調べ、患者Ｘを選択し、次に、患者Ｘの画像を調べ、心臓に関する画像を見出し、次に、複数の関係のないツールを除外して心臓ツールを見出したいとは思わない。

本発明の実施形態は、同じ参照が類似の要素を示す添付の図面の図に一例として制限ではなく示されている。

一実施形態による統合医療ソフトウエアシステムを示すブロック図である。 本発明のある一定の実施形態による画像処理ソフトウエアのウェブベースのアーキテクチャを示す図である。 本発明のある一定の実施形態による画像処理ソフトウエアのウェブベースのアーキテクチャを示す図である。 本発明の一実施形態による統合医療ソフトウエアシステムのサーバとクライアント間の通信方式を示す図である。 本発明の一実施形態による医療記録ソフトウエアのグラフィカルユーザインタフェースを示す画面図である。 本発明の一実施形態による医療記録ソフトウエアのグラフィカルユーザインタフェースを示す画面図である。 本発明の一実施形態による医療記録ソフトウエアのグラフィカルユーザインタフェースを示す画面図である。 本発明の一実施形態による医療記録ソフトウエアのグラフィカルユーザインタフェースを示す画面図である。 本発明の一実施形態による医療記録ソフトウエアのグラフィカルユーザインタフェースを示す画面図である。 本発明の一実施形態による医療記録ソフトウエアのグラフィカルユーザインタフェースを示す画面図である。 本発明の一実施形態による医療記録ソフトウエアのグラフィカルユーザインタフェースを示す画面図である。 本発明の一実施形態による臨床試験ソフトウエアのグラフィカルユーザインタフェースを示す画面図である。 本発明の一実施形態による臨床試験ソフトウエアのグラフィカルユーザインタフェースを示す画面図である。 本発明の一実施形態による臨床試験ソフトウエアのグラフィカルユーザインタフェースを示す画面図である。 本発明の一実施形態による臨床試験ソフトウエアのグラフィカルユーザインタフェースを示す画面図である。 画像に関連付けてＭＲＣＳによって使用されて正しい画像及びツールを開くことができるタグのタイプを示す図である。 本発明の別の実施形態による画像処理ソフトウエアのウェブベースのアーキテクチャを示す図である。 一実施形態による統合医療記録ソフトウエアによって実行される処理を示す流れ図である。 一実施形態による統合臨床試験ソフトウエアによって実行される処理を示す流れ図である。 別のソフトウエアプログラムを開く必要なく患者情報と関連付けられた画像との両方をＭＲＣＳ内に表示する例示的な方法を示す流れ図である。 データ処理システムを示すブロック図である。

本発明の様々な実施形態及び態様を以下に説明する詳細に関して説明し、添付の図面は様々な実施形態を示している。以下の説明及び図面は、本発明を例示するものであり本発明を制限するものとして解釈すべきではない。多数の特定の詳細が、本発明の様々な実施形態の完全な理解を提供するために説明される。しかし、特定の例では、公知の又は従来の詳細は、本発明の実施形態の簡潔な説明を提供するために説明されていない。

本明細書における「一実施形態」又は「実施形態」への参照は、実施形態に関して説明した特定の特徴、構造、又は特性が本発明の少なくとも１つの実施形態に含まれることを意味する。本明細書における様々な箇所での「一実施形態では」という句の出現は、必ずしも全て同じ実施形態を示すものではない。

一部の実施形態により、本発明の実施形態は、画像及び／又は画像処理と、ＥＭＲ、臨床試験ソフトウエア、口述筆記ソフトウエア、研究ソフトウエア、放射線情報システム（ＲＩＳ）ソフトウエア、画像記録及び通信システム（ＰＡＣＳ）ソフトウエア、及び他の医療ソフトウエアパッケージを含むＭＲＣＳとの統合を提供する。一実施形態において、高度画像処理は、ＭＲＣＳプログラムに緊密に統合される。統合は、ＭＲＣＳと同じウィンドウに表示される画像及び／又は画像処理ツールの形式を取ることができる。統合はまた、ＭＲＣＳウィンドウとは別のウィンドウに開かれる画像及び／又は画像処理ツールを含むウィンドウの形式を取ることができる。別の実施形態において、画像処理ソフトウエアがＭＲＣＳプログラムに統合され、「コンテキストにおいて」開かれる。「コンテキストにおいて」は、画像処理ソフトウエアが現在のユーザ及び／又は患者及び／又は苦痛の適切な画像及び／又はツールを表示するために開かれることを意味する。

図１は、一実施形態による統合ＭＲＣＳ及び高度画像化処理システムを示すブロック図である。図１を参照すると、一実施形態により、システム１００は、有線及び／又は無線でネットワーク１０１を通して医療画像化処理サーバ１１０及び医療データサーバ１１５に通信することができるように結合されたクライアント１０５を含む。ネットワーム１０１は、ローカルエリアネットワーク（ＬＡＮ）、都市エリアネットワーク（ＭＡＮ）、インターネット又はイントラネットのようなワイドエリアネットワーク（ＷＡＮ）、プライベートクラウドネットワーク、公共クラウドネットワーク、又はその組合せとすることができる。図１は医療画像化処理サーバ１１０及び医療データサーバ１１５に通信することができるように結合された単一クライアント１０５を示しているが、複数のこのようなクライアントを医療画像化処理サーバ１１０及び／又はＭＲＣＳサーバ１１５に通信することができるように結合することができることが認められるであろう。

ＭＲＣＳサーバ１１５は、一実施形態では医療画像化処理サーバ１１０及びクライアント１０５とは異なる場所に物理的に存在するデータサーバとすることができる。別の実施形態において、ＭＲＣＳサーバ１１５を医療画像化処理サーバ１１０及び／又はクライアント１０５と同じ場所に置くことができる。ＭＲＣＳサーバ１１５は、クライアント１０５及び／又は画像化処理サーバ１１０と同じか又は異なる機構によって運用することができる。一実施形態において、ＭＲＣＳサーバ１１５は、ＥＭＲ又はＥＨＲ１０２のような患者の医療記録を格納するためのデータストレージを含む。ＭＲＣＳサーバ１１５は、匿名の患者の臨床試験記録１０３も格納することができる。ＭＲＣＳサーバ１１５は、更に、ＥＭＲデータ１０２及び臨床記録１０３へのアクセスを提供するためのアクセス制御システム１１６を含む。異なる役割を有する異なるユーザに異なるデータへのアクセスを許可することができる。例えば、医師がＥＭＲデータ１０２にアクセスすることを許可することができ、医学生又は教授が試験記録１０３へのアクセスだけを許可することができる。例示的な目的のために、ＭＲＣＳサーバ１１５は、ＭＲＳサーバ、ＣＴＳサーバ、又はその組合せを表すことができ、ＭＲＣＳサーバ１１５を単一サーバ又はサーバのクラスターに組み込むことができる。ＭＲＣＳサーバ１１５が２つの個別のサーバ、すなわち、１）ＥＭＲデータ１０２を格納しているＭＲＳサーバ、及び２）試験記録１０３を格納しているＣＴＳサーバを表すことができることにも注意されたい。

医療画像化処理サーバ１１０は、ネットワーク上でクライアント１０５に医療画像処理サービスを提供するように構成された画像処理エンジンを含む。一実施形態において、医療画像化処理サーバ１１０は、ＪＰＥＧ、ＴＩＦＦ、ビデオ、ＥＫＧ、実験室画像、ｐｄｆ、音声などのファイルを含む医療におけるデジタル撮像及び通信（ＤＩＣＯＭ）互換データ又は他の画像データのような医療データを格納するための画像ストア１０８を含む。画像ストア１０８は、暗号化機能を組み込むことができ、医療データを暗号化形式で格納及び送信することができる。画像ストア１０８は複数のデータベースを含むことができ、関連のデータベース管理システム（ＲＤＢＭＳ）、例えば、Ｏｒａｃｌｅ（登録商標）データベース又はＭｉｃｒｏｓｏｆｔ（登録商標）ＳＱＬサーバなどによって実行することができる。一実施形態において、医療画像処理サーバ１１０はアクセス制御システム１０６を含み、画像ストアに格納されたリソース（例えば、画像処理ツール）及び／又は医療データへのクライアント１０５によるアクセスを制御する。クライアント１０５は、そのアクセス特権に応答して画像ストアに格納されたリソース及び／又は医療データの特定の部分にアクセス可能であり又はアクセスすることができない。アクセス特権は、役割ベースの規則又はポリシーのセットに基づいて決定又は構成することができる。例えば、クライアント１０５は、医療画像処理サーバ１１０によって提供されるツールの一部へのアクセスだけを許可する特定の役割によって構成することができる。他の例では、クライアント１０５をある患者情報へのアクセスを制限する特定の役割によって構成することができる。例えば、クライアント１０５のある一定のユーザ（例えば、医師、医学生）は、異なるアクセス特権を有し、画像ストア１０８に格納された異なる医療情報又は画像処理サーバ１１０によって提供されるリソースをレンダリングする異なる画像にアクセス可能である。

クライアント１０５は、本明細書に説明するように統合医療ソフトウエア１０７を含むクライアントである。一実施形態において、統合ソフトウエア１０７は、画像及び／又は画像処理機能１２１を本明細書では総称して医療記録及び／又は臨床ソフトウエア（ＭＲＣＳ）と呼ぶ医療記録ソフトウエア（ＭＲＳ）及び／又は臨床試験ソフトウエア（ＣＴＳ）１０７に統合する。例えば、画像処理機能は、ネットワーク１０１を通して画像処理サーバ１１０に通信することができるように結合された医療画像処理クライアント１２１として実施することができる。画像処理クライアント１２１は、医療ソフトウエア１０７にリンクすることができ、又は医療ソフトウエア１０７内に組み込むことができる。

ＭＲＳは、個々の患者の医療記録にフォーカスを当てた患者中心のソフトウエアである。患者中心とは、ソフトウエアの主な目的が個々の患者に関するデータを記録及び閲覧することを本明細書では意味する。このタイプのソフトウエアは、電子医療記録（ＥＭＲ）ソフトウエア、電子健康記録（ＥＨＲ）ソフトウエア、個人健康記録（ＰＨＲ）ソフトウエア、及び他の名称で呼ぶことができる。ＭＲＳによって維持される情報は、一般的には、患者ＩＤ、人口動態情報−年齢、体重、身長、血圧（ＢＰ）のような実験室オーダー及び結果、検査オーダー及び結果、医療履歴、予約履歴、予約スケジュール、試験履歴、処方／投薬、症状／診断、及び保険／返還情報を含む。

ＣＴＳは、既往及び予想臨床研究の両方のためのソフトウエアを含む。このタイプのソフトウエアは、臨床試験管理システムと呼ぶことができる。ＣＴＳは研究のためのソフトウエアを含むことができる。ＣＴＳは、ソフトウエアの主な目的が複数の患者又は参加者のための集約データを収集及び閲覧することであることを意味する試験中心的である。データは個々の患者／参加者レベルで収集されるが、このデータは通常は「盲目的に」閲覧される。これは、データの閲覧者及び／又は分析者が一般的に個々の患者／参加者のアイデンティティを知らないことを意味する。しかし、必要に応じてデータを個々の患者／参加者レベルで閲覧することができる。これは、画像が含まれる場合に特に重要である。ＣＴＳは、一般的に、患者ＩＤ、併用投薬、有害事象、ランダム化情報、データ収集、インフォームドコンセント、集約データ、及び研究のステータスを含む。

一実施形態において、クライアント１０５内で実行される統合医療ソフトウエアのＭＲＣＳ１０７は、例えば、患者の医療記録及び／又は臨床記録１２０の一部とすることができる患者の医療処置履歴などを含む患者の医療情報１２２を表示する。このような記録１２０は、ユーザの必要に応じて医療データサーバ１１５からダウンロードすることができる。統合医療ソフトウエアがＭＲＳを統合する場合に、患者の完全なアイデンティティは、医療情報の一部として一般的に表示されている。他方、統合ＣＴＳの場合に、患者は、一般的に、上述したように匿名であり、患者のアイデンティティは、一般的に、表示された医療情報の一部として明らかにされない。

一実施形態において、画像及び／又は画像処理機能１２１は、ＭＲＣＳに統合される。統合は、ＭＲＣＳと同じウィンドウに表示される画像及び／又は画像処理ツールの形式を取ることができる。統合はまた、ＭＲＣＳウィンドウとは別のウィンドウに表示される画像及び／又は画像処理ツールを伴うウィンドウの形式を取ることができる。しかし、統合のいずれの形式でも、患者の医療情報及び画像は、別のソフトウエアプログラムを通して別に画像を取得するように統合ソフトウエアのユーザに要求することなく、統合医療ソフトウエア内に表示されることに注意されたい。

一実施形態において、遠隔画像処理サーバ１１０によって提供される画像処理ツール１２３は、クライアント１０５で実行される統合医療ソフトウエアのユーザに表示されている。このような実施形態において、利用可能な画像処理ツール１２３は、アイコンのセット又はある他の図形表示として統合医療ソフトウエアに表示され、ユーザによって起動された時に画像を遠隔画像処理サーバによって操作することができる。一実施形態において、画像処理ソフトウエアは、ＭＲＣＳプログラムに統合され、「コンテキストにおいて」開かれる。「コンテキストにおいて」は、画像処理ソフトウエアが現在のユーザ及び／又は患者及び／又は苦痛のための適切な画像及び／又はツールを表示するために開かれることを意味する。特定のユーザに対する撮像ツール１２３の利用可能度は、その特定のユーザ（例えば、医師対医学生）のアクセス特権に依存する。代替的に、撮像ツール１２３の利用可能度は、ＤＩＣＯＭタグのような特定のタグによって識別することができる患者の特定の身体の部分に基づいて決定することができる。

例えば、１人の医師は、その患者の心臓血管画像を利用可能な血管中心線ツールによって３Ｄビューで開くこと、フライスルーによって環状ビューで患者の腹部画像を開くこと、又は利用可能な仮想大腸内視ツールによって開くことを好む場合がある。医師は、他のビュー及びツールを見えないようにしたい場合がある。別の例では、別の医師が、その患者に医師が使用した最新のビュー及びツールを表示するその患者の画像を開くことを好む場合がある。別の例では、心臓血管ケースのデフォルトビューを特定のビュー及びツールを表示するように設定することができるが、ユーザは、ユーザのプリファレンスがデフォルトビュー及びツールに優先するようにデフォルトを変更することができる。

上述の例の全てにおいて、理想的には、その時間に評価される患者に関する画像だけを見ることができる。更に、ユーザ／医師は、患者に関する画像を見出すために検索する必要はなく、画像１２４が、例えば、対応する患者ＩＤに基づいて自動的に正しい患者に関連付けられる。これを実行するために、患者のアイデンティティは、患者の画像に関連付ける必要がある。これは、ＩＤ番号のような共通の識別子のようなタグ、画像の１つ又はそれよりも多くに関連付けられるメタデータ、マイニング患者データ、身体部分分析、又は他の方法を使用して実行することができる。適切なツールを表示して不適切なツールを隠す必要がある。タグは、以下に更に詳しく説明する。

例えば、画像又は画像シリーズは、生体構造に基づいて頭、腹部、又は他の身体部分か否かを決定するために分析することができる。頭蓋骨は、生体構造の他の部分のように特徴的な形状を有する。特定の身体の部分の識別を助けるために基準画像のカタログを使用することができる。この分析に基づいて、適切なビュー及び／又はツールをユーザの眼に見えるようにすることができ、不適切なビュー及び／又はツールを隠すことができる。例えば、画像シリーズが頭部／頭蓋骨である場合に、画像シリーズは、軸ビューのような特定のビューに表示することができ、脳に関連付けられるツールを眼に見えるようにすることができる。更に、「腫瘍」又は「脳梗塞」のような特定のキーワードがＭＲＣＳ記録に見出された場合に、腫瘍を検出するか又は脳の潅流を決定するツールのような特定のツールを表示することができる。患者ＩＤを形状、病気、タグなどに基づいて画像の分析から決定することができ、例えば、歯科範囲の画像を歯科記録に一致させ医療画像から患者を識別することができる。これに代えて、ＣＴスキャナのテーブル上又はその近く、又は患者自身の上に配置された患者ＩＤ番号を有するタグのような識別タグを医療画像に含むことができる。

別の実施形態において、ソフトウエアのユーザは、画像処理ソフトウエアがコンテキストにおいてどのように提示されるかをカスタマイズすることができる。例えば、医師Ｙ、心臓内科医は、３Ｄモデルビューで画像を開き、心臓ツールＡ及び心臓ツールＢを医師に見えるようにすることを好む場合がある。この例では、他のビューを隠すことができる（例えば、軸、矢状、及び環状ビュー）及び他のツールが隠される（例えば、大腸又は脳に関するツール）。

図２Ａは、一実施形態による画像処理ソフトウエアシステムのウェブベースのアーキテクチャを示している。画像処理サーバ２０１は、画像処理の重要な作業を実行する。画像処理クライアント２０２は、コンピュータ、移動デバイス又は他のハードウエアに存在するクライアント−サーバベースのクライアントである。変換層２０５は、従来のクライアント情報を標準的なウェブサーバ２０３が理解することができる情報に変換する。ウェブサーバ２０３は、マイクロソフトＩＩＳ（インターネット情報サービス）サーバのような標準的なウェブサーバとすることができる。サーバ２０３は、コンピュータ、移動デバイス又は他のハードウエアに存在する。画像処理情報が標準的なウェブサーバに翻訳された状態で、いずれのコンピュータ、移動デバイス又は他のハードウエアにもあるいずれのウェブブラウザ２０４を使用するいずれのユーザも、画像を見て、画像処理ツールを使用することができる。

ウェブベースのアーキテクチャを利用する画像処理ソフトウエアは、ウェブブラウザ又は他の標準的なウェブインタフェースを通してユーザがソフトウエアにアクセス可能であるので有利である。多くのＭＲＣＳプログラムがウェブブラウザインタフェースを現在使用しているか又は使用を計画しているので、２つのウェブベースのソフトウエアアプリケーション間のグラフィカルユーザインタフェース（ＧＵＩ）の統合は、ユーザのための最もシームレスなインタフェースを提供する。

ウェブベースのアーキテクチャは、高品質の統合の柔軟性を可能にする。ウェブブラウザをいずれのコンピュータでも閲覧することができるので、インターネット又はイントラネットのいずれでも、画像処理ウィンドウ又はフレームをいずれのＭＲＣＳプログラムからも組み込む又は起動することができる。画像処理アプリケーションは、ＦＬＡＳＨ又はＪａｖａ（登録商標）又はＣｉｔｒｉｘのようないずれの追加の接続又はダウンロードもなしに標準的なウェブブラウザで起動することができる。このアーキテクチャは、ユーザ、患者、専門家等による画像処理インタフェースの大幅なカスタマイズ化を可能にする。これは、画像処理ウィンドウがより一般的なＭＲＣＳプログラム内でコンテキストにおいて起動するのに重要である。

図２Ｂは、別の実施形態による画像処理ソフトウエアシステムのウェブベースのアーキテクチャを示している。他のハードウエアにおける他のクライアントタイプは、同じサーバ、同じデータ、及び同じセッションから起動することができる。これは、例えば、ワークステーションにインストールされたクライアントソフトウエアによるワークステーションでの放射線科医の座席を見えるようにし、別のコンピュータでウェブブラウザを通してＥＭＲをレビューしている誰かが同一画像を見る／操作している間に患者の画像を操作することを可能にする。１人のユーザは別のユーザとは全く異なるインタフェースを有することができるが、画像処理サーバは同じとすることができ、データを同じにすることができる。画像処理サーバ及び／又は変換層は、上述したように、ツール、画像などへのアクセスを制御することができるので、一方のユーザは、他方のユーザが見ることのできないいくつかのツールを見ることができる。一方のユーザは、ユーザのアクセス特権に応答して、他方のユーザが見ることができないいくつかの画像又は情報を見ることができる。これは、主治医が、例えば、許可されていない画像又はツールが相談側医師に表示されるか否かを心配することなく、別の医師に相談することを可能にする。

別の実施形態において、画像処理ソフトウエアは、統合されるＭＲＣＳと数量データを共有する。数量データは、特定の画像処理ツールを使用して医療画像から抽出することができる。測定が行われて追跡される。この数量データは、メタデータの形式で画像に関連付けることができる。例えば、腫瘍のＲＥＣＩＳＴ（固形腫瘍における反応評価基準）値を測定して時間と共に追跡することができる。この情報は、ＭＲＣＳのユーザに重要であり、ＭＲＣＳプログラムと共有及び／又はＭＲＣＳプログラムに統合することができる。例えば、ＥＭＲは、数値形式で腫瘍のＲＥＣＩＳＴ値を時間と共に表示することができ、又は臨床試験ソフトウエアプログラムは、同じものを表示して、特定の薬品又は治療の結果の測定を助けることができる。別の例は、数量画像データとニュアンスＰＯＷＥＲＳＣＲＩＢＥ（登録商標）３６０のような医療口述筆記ソフトウエアの統合である。画像に関連付けられるデータは、口述筆記ソフトウエア内に提示することができ、ユーザがデータに関して口述筆記することを可能にする。例えば、腫瘍のＲＥＣＩＳＴ値が１１ｍｍである場合に、口述筆記ソフトウエアは、この情報をプレポピュレートすることができ、次に、医師は、「腫瘍ＲＥＣＩＳＴ値は…」のような口述筆記を追加するだけでよい。

数量データは、他の指示で共有することができる。ＭＲＣＳは、画像に関連付けられたデータを包含することができる。例えば、患者の体重又はＢＭＩを画像化ソフトウエアに入れて画像と共に表示するか又は数量画像計算で使用することができる。この同じタイプの数量統合は、ＥＭＲソフトウエアを含むＭＲＣＳパッケージと共に実行することができる。数量データ、又は他のメタデータは、ＸＭＬ又は他の言語を通してＭＲＣＳと医療画像化ソフトウエアの間で交換することができる。設定されたプトロコルが存在する場合に、これらは、ソフトウエアパッケージ間で数量データを共有するために使用することができる。例えば、ＡＩＭ（注釈及び画像マークアップ）プロトコルを使用することができる。

適切な場合に、ＭＲＣＳのユーザは、照会の場合などのように別のユーザへのアクセスを与えることができる。この場合に、照会ユーザは、特定の患者へのアクセス又は患者の部分的なデータのみへのアクセスのようなＭＲＣＳの一部分だけへのアクセスを与えたいと思う場合がある。照会ユーザは、アクセス可能なデータにおける数量データを含むことを望む場合がある。この場合に、照会ユーザは、数量データだけでなく、データが画像から来る場合は数量データが来る画像へのアクセスも与えることができる。これは、数量データにコンテキストを与えることになる。例えば、数量データが腫瘍の大きさの測定である場合に、照会側及び照会されるユーザは、測定が行われた腫瘍の画像にアクセス可能であることになる。腫瘍が時間と共に追跡された場合に、ユーザは、各数量測定に対する画像にアクセス可能であることになる。

図３は、一実施形態による統合クライアント及び医療画像処理サーバ及び医療データサーバ間の通信を示している。図３を参照すると、段階（１）で、クライアント１０５で統合医療ソフトウエアを実行するユーザ（例えば、医師）は、遠隔医療データサーバ１１５にログオンにする。一実施形態において、ログイン信用証明がユーザＩＤ及びパスワードを含む。ログイン処理の完了時に、ユーザは、医療データサーバ１１５にユーザが見たいと思う記録に関する情報を提供する。例えば、ユーザが患者のＥＭＲを見るように想定されている場合に、ユーザは、患者に関する情報を提供する。一実施形態において、患者情報は患者ＩＤを含む。他方、ユーザが臨床試験記録を見るように想定されている場合に、ユーザは医療データサーバ１１５に臨床試験情報を提供する。

クライアント１０５を通してユーザから必要な情報を受信した状態で、段階（２）で医療記録（例えば、ＥＭＲ）又は臨床試験記録が医療データサーバ１１５からクライアント１０５に閲覧され、統合医療ソフトウエアＧＵＩ内に表示されている。一実施形態において、ＧＵＩは、統合医療ソフトウエアウィンドウと同じウィンドウである。代替の実施形態において、ＧＵＩは、統合医療ソフトウエアウィンドウとは別のウィンドウである。

一実施形態において、ユーザは、画像を閲覧する及び／又は閲覧された医療記録又は臨床試験記録に関連付けられる画像を編集することを要求することができる。このような実施形態において、統合医療ソフトウエアのユーザは、遠隔医療画像処理サーバ１１０にアクセスすることによって段階（３）を実行する。遠隔医療画像処理サーバ１１０によって認証が成功した状態で、ユーザは、ユーザが閲覧を選択した画像に関する情報をサーバに提供する。例えば、ユーザが特定のＥＭＲ記録に関連付けられる画像の閲覧を選択した場合に、ＭＲＣＳは患者に関する情報を医療画像処理サーバ１１０に提供する。一実施形態において、情報は、患者ＩＤ及び／又は医療処置を含む。他方、ユーザが臨床試験記録に関連付けられる画像の閲覧を選択した場合に、ＭＲＣＳは、臨床試験及び／又は患者に関する情報を医療画像処理サーバ１１０に提供する。一実施形態において、遠隔医療画像処理サーバ１１０に送信される医療情報は、患者の身体の部分を識別する身体部分識別子を含む。一実施形態により、画像を識別する患者／試験情報は、ＤＩＣＯＭタグのような特定のタグを含むことができる。上述の処理は、このような情報の具体的な提供をユーザに要求することなく自動的に処理される。画像は、ＥＭＲデータ又は臨床記録から得られるタグに基づいて画像処理サーバによって識別することができ、ユーザが医療画像処理サーバへのアクセスを開始した時にタグをＥＭＲデータ又は臨床記録から自動的に抽出して遠隔医療画像処理サーバに送信することができる。一実施形態において、認証処理は、アクセス制御システム１１６とアクセス制御システム１０６間で同期することができ、それによってユーザが一方のアクセス制御システム１１６による認証に成功した状態で、ユーザは、他方のアクセス制御システム１０６によって自動的に認証される。代替的に、ＭＲＣＳ１０７はローカルでログイン信用証明（例えば、ユーザ名及びパスワード）をキャッシュに入れることができ、ユーザがシステム１１５及び１１０のいずれかにアクセスした時に、ＭＲＣＳ１０７は、ユーザに同じことを示す必要なく自動的にシステムにログインすることができる。

一実施形態により、患者の医療記録の特定の詳細な情報、情報の一部は、異なるタグに関連付けることができる。例えば、タグは、患者の特定の医療処置の身体部分を識別することができ、医療処置も別のタグによって識別することができる。ユーザがその特定の医療記録に関連付けられる医療画像を取得したいと思う場合に、ユーザは、医療画像処理サーバ１１０へのアクセスの制御を単純に起動して関連の画像を要求することができる。医療画像処理サーバ１１０に送信される要求は、タグの少なくとも一部を自動的に含むことができる。それに応じて、サーバ１１０は、タグに基づいて時点で医療記録の特定の部分に関連付けられる特定の画像を識別することができる。これらの特定の画像だけが、このような医療記録と共に医療ＳＷ１０７内にサーバ１１０によって表示されている。更に、画像処理ツールのセットがサーバ１１０によって識別され、対応するアイコンが画像を操作するためのツールをユーザを利用することができるように表示されている。ツールの利用可能度は、タグ、並びにユーザのアクセス特権に基づいて決定することができる。

図３を参照すると、クライアント１０５からの必要な情報の全てを受信した状態で、段階（４）で、ユーザによって提供される情報に関連付けられる画像が、医療画像処理サーバ１１０によってクライアント１０５に表示されている。一実施形態において、閲覧される画像は、患者ＩＤ及び／又はタグによって表すことができる患者の任意的な医療処置履歴に基づいて遠隔医療画像処理サーバ１１０によって識別される。一実施形態において、表示される画像は、上述の段階（３）の一部としてＭＲＣＳによって提供される身体部分識別子によって識別される。画像がクライアント１０５に表示された状態で、ユーザは、統合医療ソフトウエアに含まれるグラフィカルユーザインタフェース（ＧＵＩ）を通して画像を閲覧することができる。本出願を通して、医療画像処理サーバ１１０によって表示される画像は、レンダリング指令に応答して又は必要に応じて医療画像処理サーバ１１０に格納されてそれによって表示される医療画像の特定のビューを表している。画像の表示バージョンは、医療画像処理サーバ１１０によって維持されるオリジナル画像と比較して異なる解像度を有することができるか又は異なる解像度を持たなくてもよい。一実施形態において、ＧＵＩは、統合医療ソフトウエアウィンドウと同じウィンドウである。代替の実施形態において、ＧＵＩは、統合医療ソフトウエアウィンドウとは別のウィンドウである。一実施形態において、患者の表示された画像及び医療情報は、統合ソフトウエアのユーザに別のソフトウエアプログラムを通して別に画像を取得するように要求することなく、統合医療ソフトウエア内に表示されている。従来のシステムは、患者情報を取得するようにＥＭＲソフトウエアに要求し、別の画像処理クライアントソフトウエアに医療画像処理サーバから医療画像を取得するように要求する。この状況では、従来のシステムは、関連付けられる医療画像を取得するために、ＥＭＲソフトウエアから患者情報を画像処理クライアントに少なくともマニュアルで入力するようにユーザに要求する。本発明の実施形態は、例えば、タグ（図６のタグの例を参照されたい）に基づいてユーザ介入なしに関連付けられる医療画像を自動的に取得する。

一実施形態において、ユーザは、画像を操作（例えば、ズームイン／ズームアウト）し、又は異なる角度／モードなどで画像を見ることができる。このような実施形態において、段階（５）は、クライアント１０５に関連の指令を遠隔医療画像処理サーバ１１０に送信させる統合医療ソフトウエアのＧＵＩに表示される撮像ツールを表すアイコンの１つをユーザが起動することによって実行することができる。指令に応答して、遠隔医療画像処理サーバ１１０は、画像をレンダリングして要求されたビューパラメータを満足させ、応答をクライアント１０５に送信し、画像を望ましいモードで表示させる。一般的なユーザが画像を多数回操作し、及び／又はいくつかの異なるモードで画像のビューが望ましい場合に段階（５）を反復することができることが認められるであろう。

図４Ａ−４Ｇは、ある一定の実施形態によるＭＲＳのグラフィカルユーザインタフェースを示す画面図である。図４Ａを参照すると、表示された情報は、患者ＩＤ４１０（例えば、１９８６３−１）によって識別される特定の患者アルフレッドに関連付けられる。ＧＵＩは、表示エリア４０１−４０３を有する患者情報ページ４２１のような様々なページを含む。アルフレッドの人口動態データは、表示エリア４０１に表示されたメニューの人口動態リンク４１１から選択することによってアクセス可能である。同様に、アルフレッドの医療履歴は、メニュー４０１の医療履歴リンク４１２をクリックすることによってアクセス可能である。アルフレッドの予約履歴はリンク４１３を通してアクセス可能である。画面の上部を通して、ユーザは、アルフレッドの全予約データ（履歴及び次回）４２２、いずれかの医師の照会４２３、保険情報４２４、いずれかの患者説明４２５、処方情報４２６、実験室及び試験情報４２７、及びアルフレッドに対して利用可能ないずれの報告４２８にもアクセス可能である。メニュー４０１には、この例において腹部の痛み４１５及び頭痛４１６を含むアルフレッドに固有の問題４１４の列挙が表示されている。ユーザが腹部の痛み４１５をクリックした時に、画面の表示エリア４０２は、症状及び可能であれば診断を含む腹部の痛みに固有の情報を表示する。この画面は表示のみであり、他のレイアウト及び特徴を表示及び／又は消去することができる。

ここで図４Ｂを参照すると、例えば、予約、照会、保険請求、注釈、処方薬（Ｒｘ）、実験／試験、及び報告を含むことができるいくつかのタブが、図４Ａに示すＧＵＩと同様に上部を通して存在する。ＧＵＩの表示エリア４０１は、患者の名称及び年齢のような患者の特定の詳細な医療情報４０４、並びに予約履歴及び特定の医療問題のような事柄を示すことができるメニューを表示する。この特定の図４Ｂでは、「腹部の痛み」という問題が選択され、腹部の痛みの詳細がＧＵＩの表示エリア４０２に示されている。画像サムネイルが表示エリア４０３に表示され、腹部に関連の画像又は画像シリーズを表示することに注意されたい。上述したように、これらの画像は、関連方式で自動的に表示され、これらは、この患者の腹部の痛みに関する画像（例えば、腹部の痛みに関連付けられたタグに基づく）だけでなく、例えば、選択医療情報４０４に基づく患者の頭痛に関する画像又は他の画像であることに注意されたい。これらは、この患者に関する（例えば、患者ＩＤ又は患者ＩＤタグに基づく）画像だけである。この及び他の例では、画像サムネイルは、ＥＭＲブラウザフレーム内のブラウザフレームとすることができる。これらの関連の画像は、タグ及び／又は患者ＩＤなどを通して識別及び関連付けることができる。

ここで図４Ｃを参照すると、上から３番目のサムネイル４３１（例えば、表示エリア４０３からの反転表示画像）、大腸の画像がクリックされたと仮定する。このような作動に応答して、選択された画像の拡大バージョンが表示エリア４０５に表示され、ＧＵＩと同じウィンドウ又はＧＵＩとは別のウィンドウ内に表示することができる。更に、画像レンダリングツールのセットを表すアイコンのセット４０６も表示されている。アイコン４０６の利用可能度は、異なるユーザに対して及び／又は異なる画像に対して（例えば、異なる医療情報に基づいて）異なるものにすることができる。これらのツールボタンは、大腸の画像を操作するためのツールとすることができる。例えば、ツールボタンは、ユーザが大腸を通るフライスルーを実行し、又は大腸内の疑わしいポリープを位置付けることを可能にすることができる。静止画像だけがこれらの図に示されているが、画像は、ＣＴ走査からのスライスのような一連の走査スライスを表すことができる。「画像」には数百又は数千のスライスを表示することができる。このために、画像を処理するために使用することができるツールは、極めて高性能とすることができる。画像は、３Ｄモデルとして見ることができ、回転、操作などを実行することができる。画像は、映画又はムービーのように動的であり又は移動することができる。ツールの考えられるリストは、本文書の後に含まれる。図４Ｃでは、目に見えるツールは、大腸、又は腹部、又はこの特定のユーザだけに関するツールとすることができることに注意されたい。

図４Ｄは、ユーザが画像サムネイルの１つ又はそれよりも多くをクリックした時に起こる場合があることの別の例を示している。この例では、上から３番目のサムネイル４３１、大腸の画像がクリックされた。この結果、画像の拡大バージョン及びツールボタンを表示するウィンドウがＥＭＲ画面内に開かれる。これは、拡大画像及びツールのウィンドウが大きいことを除いて図４Ｃの例に類似である。

図４Ｅは、ユーザが画像サムネイルの１つ又はそれよりも多くをクリックした時に起こる場合があることの別の例を示している。この例では、上から３番目のサムネイル４３１がクリックされ、上から４番目の画像４３２がクリックされた。この結果、画像及びツールボタンの両方の拡大バージョンを表示するウィンドウがＥＭＲ画面内に開かれる。２つの画像を比較及び／又は一緒に見ることができる。２つの画像は、ユーザが画像の１つを操作する時に他方の画像がそれに応答して作用するように互いに登録することができる。例えば、図４Ｅでは、右画像が大腸フライスルーを表し、ユーザはユーザがフライスルーしているように大腸の内側を見る。左画像は、ユーザが「フライ」している大腸の場所を示す矢印を表示する。

図４Ｆは、ユーザが画像サムネイルの１つ又はそれよりも多くをクリックした時に起こる場合があることの別の例を示している。この例では、上から３番目のサムネイルがクリックされ、上から４番目の画像がクリックされた。この結果、画像及びツールボタンの両方の拡大バージョンを表示するウィンドウがＥＭＲ画面内の新しいタブで開かれる。この例は、画像閲覧／処理に利用可能な画面エリアが大きいことを除いて図４Ｅに示すものに類似である。ユーザがこの患者に関する異なる情報を閲覧したい場合にユーザは上部のタブボタンを容易にナビゲートすることができることに注意されたい。

図４Ｇは、ユーザが画像サムネイルの１つ又はそれよりも多くをクリックした時に起こる場合があることの別の例を示している。この例では、上から３番目のサムネイルがクリックされ、上から４番目の画像がクリックされた。この結果、画像及びツールボタンの両方の拡大バージョンを表示する新しいウィンドウが開かれる。これらの画面構成は、ブラウザフレーム又は他の方法を使用して達成することができる。これらの及び他の画像閲覧及び処理ウィンドウは他の方法でも開く又は起動することができる。サムネイルは表示することができ、又は表示しなくてもよい。画像は単純な「画像」ボタン又はリンクを通して起動することができ、又は適切な画像が存在する場所で自動的に起動することができる。

統合は、画像処理ソフトウエアとＭＲＣＳのいずれのタイプの間でも実施することができる。例えば、画像を臨床試験ソフトウエア、ＣＴＳに統合することができる。図５Ａ−５Ｄは、本発明のある一定の実施形態による統合ＣＴＳのＧＵＩを示す画面図である。図５Ａを参照すると、この画面図は、ＰＲＯＯＦとラベル付けされた臨床試験に固有である。ユーザは、試験を捲り参加者ページ５０２を通して試験の患者／参加者の１人に関するデータにアクセス可能である。ここで患者は、患者の名称を表示することなく患者ＩＤ５０１だけによって呼ばれる。画面の上部を通して、ユーザは、特定のサイト訪問５０３、収集された患者データ５０４、患者のインフォームドコンセント５０５、患者が受けることができるいずれの併用投薬５０６、いずれの注釈５０７又は報告５０８、及び患者が試験の間に受ける場合があるいずれの有害事象５０９にも関する情報にアクセス可能である。ユーザが左メニュー５２０のステータスリンク５１０をクリックした場合に、集約データ情報を含む研究ステータス情報を利用することができるようなり、表示エリア５３０に表示されている。更に、ランダム化のような特徴を別の画面を通して構成することができ、又は単純にソフトウエア内の環境の裏側で発生させることができる。

図５Ｂは、画像が統合される匿名の参加者に対する臨床試験ソフトウエアからの画面の例を示している。例えば、参加者５０２、サイト訪問５０３、患者データ５０４、インフォームドコンセント５０５、併用投薬５０６、注釈５０７、報告５０８、有害事象５０９、及び画像５１１などを含むことができるいくつかのタブが上部にわたって存在する。画面の左側は、参加者の年齢及び性別のようなある一定の基本的な人口動態情報を示している。この特定の図では、臨床試験、「ＰＲＯＯＦ」が選択され、この臨床試験へのこの参加者の詳細が画面の中央に表示されている。

図５Ｃは、画像タブ５１１がクリックされた時に起こることを示している。画面の表示エリア５４０への画像サムネイルが、この患者及びこの臨床試験に関する画像又は画像シリーズを示すことに注意されたい。この例では、上から３番目のサムネイル５４１、大腸の画像がクリックされた。この結果、画像５４２及びツールボタン５４３の拡大バージョンを示すウィンドウが臨床試験ソフトウエア画面内に開かれる。これは、ブラウザのフレームにすることができるか又はある他の方法で組み込むことができる。一部のツールボタンが、この時点で利用可能である点にも注意されたい。これらのツールボタン５４３は、大腸の画像を操作するためのツールとすることができる。例えば、ツールボタンは、ユーザが大腸をフライスルーすること、又は大腸内の疑わしいポリープを位置付けることを可能にすることができる。静止画像だけがこれらの図に示されているが、画像は、ＣＴ走査からのスライスのような一連の走査スライスを表すことができることに注意されたい。「画像」には数百又は数千のスライスを表すことができる。このために、画像を処理するために使用することができるツールは、極めて高性能とすることができる。画像は３Ｄモデルとして閲覧し、回転、操作などを実行することができる。ツールの考えられるリストは、本文書の終わりに含まれている。眼に見えるツール５４３は、大腸、又は腹部、又はこの臨床試験、又はこの特定のユーザだけに関するツールとすることができることに注意されたい。この例では、ポリープ検出及び測定ツールが使用され、結果情報が画面に表示されている。画像は、大腸内のポリープの位置及び大きさを示している。この検出及び測定に関する情報は、通常、画像メタデータに画像と共に格納される。

図５Ｄは、画像メタデータに格納された数量的な情報を臨床試験ソフトウエアにどのように統合することができるかを示している。この例では、特定のポリープの直径が時間と共に追跡され、画像メタデータに格納される。この数量的な情報は臨床試験ソフトウエアに統合され、それによってサイト訪問タブの以下の表に示されている。データは、グラフ又は他の方法で表現することができる。画像及び／又は画像処理とＭＲＣＳの統合は３つのレベルに存在する。統合の第１レベルは、正しい画像が、正しいコンテキスト、例えば、患者、身体部分、モダリティ等で表示されるようにする段階を含む。統合の第２のレベルは、正しいツールが、画像に対して表示される、例えば、関連のツールが、ワークフロー、プリファレンスなどに従って表示されるようにする段階を含む。統合の第３のレベルは、正しいプリファレンスが、ツール、ワークフロー内で使用されるようにする段階を含む。一実施形態において、画像及び／又は画像処理とＭＲＣＳの統合がタグの使用によって達成される。

図６は、画像に関連付けられてＭＲＣＳによって使用されて正しい画像及びツールを開くタグのタイプを示している。ＤＩＣＯＭ規格は、画像データに関連付けられるいくつかのタグを含む。タグの部分的なリストは、全国電機製造業者協会によって公開されたＤＩＣＯＭ規格に含まれる。例えば、モダリティ、患者名、患者ＩＤ、検査される身体部分、要求側医師などに関するＤＩＣＯＭタグが存在する。カスタム又はプライベートＤＩＣＯＭタグも生成することができ、ＤＩＣＯＭヘッダの一部になる。これらのタグは、画像化ソフトウエアをいずれのＭＲＣＳに統合するために使用することもできる。上述したように、タグの少なくともいくつかは、画像処理サーバに格納された特定の画像を指定又は識別するために利用することができる。公知のＤＩＣＯＭタグの一部を以下に列挙する。

（表）

画像データに関連付けるための追加のタグを設定することができる。例えば、これらは、どのツールが画像データに関連付けられるかのように定期的に使用されるタッグを事前設定することができる。これらのタグは、状況に応答して変更することができる。例えば、一部の医師は、画像の特定のタイプに関連付けられる異なるツールを好む場合がある。これらのタグは、画像データに関連付けられるワークフローを含むことができる。

カスタムタグは、画像データに関連付けることができる。例えば、医師は、医師の研究に対する関連性を設定することを要求することができる。従って、医師は、画像データを正しい患者、身体の部分、モダリティ等に適正に関連付けられるようになる。一実施形態において、カスタムタグを以下のように画像データに関連付けることができる：画像シリーズ又は研究が最初に開かれた時に、ユーザはタグをこれに付けることを要求することができる。タグは、個々の画像レベル、画像シリーズレベル又は研究レベルにすることができる。このタグは、画像／研究／シリーズを自動的に前方に進むように関連付けることができる。ラベルは、患者、身体の部分、手順タイプ、モダリティ、研究センター、医師、使用されるツール及び／又はワークフローテンプレート又は他の事柄を示すことができる。従って、ユーザが統合ＭＲＣＳを使用する時に、ユーザが複数の研究／シリーズを手動で取り除く必要なく、適切な画像が、患者、身体部分などに関連付けられる。ワークフローテンプレートに関する更に詳細な情報は、その全体が引用によって本明細書に組み込まれる２００８年８月２１日出願の「医療画像データ処理のためのワークフローテンプレート管理」という名称の現在特許出願中の米国特許出願第１２／１９６，０９９号明細書に見出すことができる。

タグは、事前に定義されたリスト（予め決められたプリファレンスタグ）からのものとすることができる。代替的に、ユーザがリストに妥当なタグを見出されなかった場合に、ユーザは、新しいタグ（カスタムタグ）、並びにそのタグに適切な関連性（開かれるツールなど）を定義することができる。いずれのユーザ生成タグも、他の画像／研究／シリーズに使用することができる。

タグは、画像データ自体からも抽出することができる。例えば、走査は、身体の部分の情報（頭蓋骨、又は心臓なども見ることができる）、コントラスト（輝度、コントラストなどに基づく）、手順、患者の体重、患者の性別、病気、患者が横たわっているテーブル又はテーブルの情報があるか否か、研究における画像の数などを含む。アルゴリズムの洗練性に応じて、大量の情報を画像自体から収集することができる。この情報から、ＭＲＣＳが正しいコンテキストで正しい画像及びツールを開くのを可能にするタグを生成することができる。

タグを画像／シリーズ／研究に関連付ける段階は、手動で又は自動で実行することができる。関連付けは、画像が医療画像処理サーバにアップロードされると直ちに実行することができ、又は必要に応じて実行することができる。画像がアップロードされた時に関連付けを自動的に実行する利点は、タグを背景で又は夜に又は他の低い使用時間中に開発することができ、それによってＭＲＣＳとの統合が速くなるということである。要求時に関連付けを実行する利点は、使用されるリソースが少なく、ユーザがタグ作成に影響を及ぼすことができ、可能であればより正確にすることができるということである。更に、タグを手動で追加する段階は、アルゴリズムを静的よりも動的にすることができる。換言すると、アルゴリズムは、画像タイプに関連付けられる可能なタグを「学習」することができる。

手動でタグを画像シリーズ／研究に関連付ける段階は、特定のセキュリティレベルを要求することができる。例えば、一部のユーザは新しいカスタムタグを生成することができ、一部のユーザは、タグを割り当てることしかできない。一部のユーザはいずれも実行することができない。タグは、プライベートとすることができ、グループ、公共などに関連付けることができる。

一実施形態において、画像データに関連付けられる上述のタグは、次に、ＭＲＣＳによって使用され、正しい画像及びツールを開く。例えば、タグが「身体の部分＝心臓」であり、タグが「病気＝狭窄」であり、タグが「患者ＩＤ＝１２３４５」である場合に、この画像データは、医師がＭＲＣＳ（ＥＭＲ又は臨床試験ソフトウエアなど）を開き患者１２３４５を見る時に利用可能になる。医師が、心臓に対応する特定の日付、又は身体部分、又は病気などを探す場合に、この画像データが医師に見えるようになる。医師が日焼けを探す場合に、これは日焼けの病気に関連付けられないので、この画像は見えないように構成される場合がある。

この同じタイプのコンテキスト的統合は、画像データに関連付けられたタグのいずれによっても実行することができる。画像データに基づいて特定のツールだけが眼に見えて特定の方法から構成されるように、同じことをツールによって実行することができる。上述の例では、心臓血管の病気に関連付けられるツールは、心臓の画像が見られた時に利用可能になる。

図７は、本発明の別の実施形態による画像処理システムを示している。ＭＲＣＳサーバは画像処理サーバとは異なる場所に物理的に存在することができるが、これらは、例えば、病院又は医療センターにおける同じ場所にすることができる。「共有ウェブブラウザ」というラベルを備えたボックスは、統合医療ソフトウエアのＧＵＩを表し、この例が図４Ａ−４Ｇ及び５Ａ−５Ｄに示されている。共有ウェブブラウザは、コンピュータ、移動デバイス又は他のハードウエアにインストールされる。図７の共有ウェブブラウザは、ＥＭＲソフトウエア、臨床試験ソフトウエア、口述筆記ソフトウエア、研究ソフトウエア、放射線情報システム（ＲＩＳ）ソフトウエア、画像記録及び通信システム（ＰＡＣＳ）ソフトウエア又は他のタイプのソフトウエアを含む２つ又はそれよりも多くの異なるソフトウエアパッケージを組み込むことができる。

図８は、一実施形態による統合医療記録ソフトウエア（ＭＲＳ）によって実行される方法を示す流れ図である。方法８００は、図１のＭＲＳ１０７によって実行することができる。図８を参照すると、ＭＲＳは、一般的に患者中心的であり、それによってユーザは特定の患者の情報を入力又は閲覧する。ＭＲＳソフトウエア自体を開いた後で（ブロック８０１）、ユーザは、ユーザが探している患者を見出し、患者のファイルを開く（ブロック８０２）。これは、患者の名称に、ＩＤ又は他の手段を示すリンクをクリックすることによって実行することができる。患者ファイル、又は画面は、患者に関する画像を自動的に表示することができる（ブロック８０３）。これらの画像は、タグに基づいて患者の記録又はファイルにリンクされる。この場合に、タグは患者ＩＤとすることができる。

患者画面は、病気、予約履歴／日付、身体の領域、症状、処置する医師、手順のようないくつかのサブカテゴリを表示することができる（ブロック８０４）。これらは、リンク、ボタン、タブとして又は他の適切な手段によって表示することができる。サブカテゴリが選択された状態で、そのサブカテゴリに関する画像だけを表示することができる（ブロック８０５）。例えば、ユーザが特定の予約日付を選択した場合に、ユーザは、その日付に収集された画像だけを見ることができる。別の一例として、ユーザが身体の部分、頭部を選択した場合に、患者の頭部に関する画像だけが表示されている。眼に見える画像の部分集合が、画像タグによって再度決定される。１つよりも多い画像又は画像シリーズをいずれかの定められたサブカテゴリ内で見ることができる。次に、ユーザが閲覧する画像／シリーズ／研究を選択した場合８０６、その画像／シリーズ／研究だけを見ることができる８０７。

更に、その画像／研究／シリーズに関連したツールだけを利用することができる／見ることができる（ブロック８０８）。ツールは、ユーザプリファレンスに基づいて見えるようにすることができる。特定のツールが選択された場合（８０９）、このツールに関連付けられるプリファレンスは、ユーザプリファレンス及び／又は画像タグによって制限することができる（８１０）。例えば、ユーザが「ズーム」ツールを選択した場合に、ユーザプリファレンス（１人のユーザが５０％を好む）又は画像タグのいずれかに基づいて画像を自動的に特定のズームレベルまでズームすることができる。例えば、大腸の画像は、開始する特定の適切な倍率で表示することができ、脳の画像を別の倍率で表示することができる。画像を操作するためにツール／複数のツールを使用することができる（ブロック８１１）。変更された画像ビューを閲覧及び／又は保存することができる（ブロック８１２）。例えば、ユーザは、潜在的な狭窄がある心臓の脈管構造の特定の範囲の反転表示を要求することができる。

図９は、一実施形態による統合臨床試験ソフトウエアによって実行される方法を示す流れ図である。方法９００は、図１のＣＴＳ１０７によって実行することができる。図９を参照すると、ユーザが一般的に全体として臨床試験に関するデータを見るか又は可能であれば入力するように、ＣＴＳは臨床試験中心的である。しかし、ユーザが個々の患者レベルを探したいと思う場合もある。例えば、データが画像を含む場合に、測定又は他のデータは、画像データから取得しなければならない。また、画像データに関する個々のデータポイントを見る必要もある。

ソフトウエア自体を開いた後（ブロック９０１）、ユーザが１つよりも多い臨床試験に含まれる場合に、ユーザは、適切な臨床試験を選択する（ブロック９０２）。次に、ユーザに、全体として臨床試験に関する画面が示される（ブロック９０２）。これは、ダッシュボード又は他のフォーマットとして表示されている。ユーザが探したい場合に、ユーザに、研究設計に応じた様々な次の段階選択が示される（ブロック９０３）。例えば、画像閲覧／処理を品質制御のために使用することができ、画像データがＯＫで受信されるようにし、又は画像閲覧／処理は参加医師によって使用することができ、臨床試験プロトコルに従って画像を解釈し、又は画像閲覧／処理が行われる作業を検査する監査のために使用され、又は画像閲覧／処理を二重盲式研究の場合の２つ又はそれよりも多くの解釈を比較するために使用することができ、又は画像閲覧／処理を呈示及びフォローアップ作業のために使用することができ、臨床データベースにおける画像化データを管理して報告などのための関連の画像を取り込む。

ユーザが閲覧したい個々の画像を探すために、ユーザは、患者ＩＤ、医師、研究センター／場所、日付のような画像カテゴリの選択を要求することができる。

画像カテゴリが選択された状態で（ブロック９０４）、そのカテゴリに関する画像を画像タグに基づいて表示することができる（ブロック９０５）。表示する画像が多すぎる場合に、画像はこのレベルで表示しなくてもよい。

ユーザが更に探したい場合に、ユーザは、様々な画像カテゴリの中を更に探すことができる。ユーザが十分狭いカテゴリに辿り着いた状態で、そのカテゴリに関する画像が（画像タグ毎に）表示されている。１つよりも多い画像又は画像シリーズは、いずれの定められたカテゴリ内でも見えるようにすることができる。次に、ユーザが閲覧する画像／シリーズ／研究を選択した場合（ブロック９０６）、その画像／シリーズ／研究だけが見えるようになる（ブロック９０７）。更に、その画像／研究／シリーズに関連するツールだけを利用することができるか又は見ることができる（ブロック９０８）。ツールは、ユーザプリファレンスに基づいて見えるようにすることができる。１つよりも多い画像／シリーズ／研究をブロック９０６で選択することができる。

特定のツールが選択された場合（ブロック９０９）、このツールに関連付けられるプリファレンスをユーザプリファレンス及び／又は画像タグによって制限することができる（ブロック９１０）。例えば、ユーザが「ズーム」ツールを選択した場合に、ユーザプリファレンス（１人のユーザは５０％を好む）又は画像タグのいずれかに基づいて画像を特定のズームレベルまで自動的にズームすることができる。例えば、大腸の画像は、開始する特定の適切な倍率で表示することができ、脳の画像は別の倍率で表示することができる。画像を操作するためにツール／複数のツールを使用することができる（ブロック９１１）。変更された画像ビューを閲覧及び／又は保存することができる（ブロック９１２）。例えば、ユーザは、潜在的な狭窄がある心臓の脈管構造の特定の領域の反転表示を要求することができる。

画像レンダリング作動の多くがネットワーク（インターネットなど）を通して画像処理サーバによって実行されることに注意されたい。ユーザがクライアントデバイスで統合ＭＲＣＳと対話した時に、指令及び応答がクライアントシステムとサーバの間で交換される。例えば、ユーザがサブカテゴリを選択した時に、サブカテゴリの情報を識別するカテゴリ（タグなど）が画像処理サーバに送信される。カテゴリ識別情報に基づいて、画像処理サーバは、望ましいサブカテゴリに関連付けられる１つ又はそれよりも多くの画像を識別して、これらの画像を統合ＭＲＣＳによって表示されるクライアントデバイスに送信する。同様に、ユーザが現在表示されている第１画像に（例えば、ズームインツールアイコンを通して）ズームインした時に、ズームイン指令がサーバに送信される。指令に基づいて、サーバは画像をレンダリングし、画像のズームインバージョンを生成する。次に、新しい画像が表示のための統合ＭＲＣＳに送信される。

一部の実施形態により、様々な画像処理ツールを統合ＭＲＣＳで提供することができる。以下は、上述の画像処理の一部として含むことができる医療画像処理ツールの例である。これらの例は、例示的な目的のために提供され、本発明の制限が想定されているものではない。

血管分析ツールは、頸動脈及び腎動脈を含む冠動脈から大動脈エンドグラフトプランニング及びより一般的な血管レビューまでの広範囲の血管分析タスクを実行することができるＣＴ及びＭＲ血管造影のための網羅的な脈管分析パッケージを含むことができる。自動化シンスラブＭＩＰのための自動中心線抽出、直線化ビュー、直径及び長さ測定、ＣＰＲ及び軸レンダリング、及び血管トラックモードを含むことができる。

カルシウムスコアリングツールは、アガトストン、容積、及びミネラルマスアルゴリズムによる冠状動脈カルシウムの半自動識別を含むことができる。カスタマイズ化選択肢を有する統合報告パッケージを含めることができる。

時間依存分析ツールは、ＣＴ又はＭＲによって得られた時間解像平面又は３次元４Ｄ脳潅流試験を含むことができる。ＴＤＡツールは、速度分析のための入力関数及びベースラインの半自動選択によって平均拡張時間及び拡張積分のような様々なパラメータのカラー又はマッピングをサポートすることができる。ＴＤＡツールは、動的４Ｄエリア検出器ＣＴ試験の高速自動処理をサポートし、収集の時間内の解釈を保証することができる。

ＣＴ／ＣＴＡ（コンピュータ断層撮影血管造影）サブトラクションツールは、ＣＴ血管造影試験から非強化構造（例えば、骨）を取り除く場合に使用され、ＣＴ／ＣＴＡ選択肢は、事前及び事後コントラスト画像の自動登録を含み、その後に、ノイズを増すことなくＣＴＡ走査から高強度構造（骨及び手術のためのクリップなど）を取り除く密度−ボクセルマスキングアルゴリズムが続き、コントラスト拡張血管構造の分離を助ける。

上皮内分解ツールは、当該の容積、例えば、血管床を含む走査領域又は肝臓のような臓器内の木のような構造を識別する。次に、ＬＤツールは、木の定められた枝又はその小枝の１つへの近接性に基づいて、当該のサブ容積を識別することができる。研究アプリケーションは、内臓の上皮構造の分析を含む。

低露出ツールによる一般的な拡張及びノイズ処理は、ソース画像品質が最適でない時にも３Ｄ、中心線、輪郭付け、及びセグメント化アルゴリムの効率を改善するためにノイズ管理技術を適用する高度容積フィルタアーキテクチャを含むことができる。

球状ファインダツールは、容積試験の自動分析を実行して高球形指数（多くの小節及びポリープに示す特徴）を有する構造の場所を識別する。球状ファインダは、肺又は大腸ＣＴ走査と共に使用されることが多く当該の潜在的な範囲を識別する。

セグメント化、分析、及び追跡ツールは、単独の肺小節又は他の潜在的な病巣のような塊及び構造の分析及び特徴付けをサポートする。ツールは、当該の領域を識別及びセグメント化することができ、次に、ＲＥＣＩＳＴ及びＷＨＯのような測定基準を適用することができ、発見の表集計報告及びフォローアップ比較を導く。球状ファインダを含む任意的な検出エンジンからの候補マーカの表示及び管理をサポートすることができる。

時間容積分析ツールは、心室のような周期的な動きの室からの排出量の自動計算を提供することができる。ユーザが当該の壁境界（例えば、心外膜及び心内膜）を識別することを可能にし、これらのユーザが確認した当該の領域に基づいて、多相ＣＴデータから、排出量、壁ボリューム（塊）及び壁の厚みを報告するための高速かつ効率的なワークフローを含むことができる。表計算報告出力が含められる。

顎顔面ツールは、顎顔面領域のＣＴ試験の分析及び視覚化をサポートし、これらのツールは、ＣＲＴツールを適用して様々な平面における様々な厚みの「パノラマ」投影、及び定義された曲平面に沿った設定増分の断面ＭＰＲビューを生成する。

大腸、肺、又は血管のような内腔ＣＴ又はＭＲ調査に適用可能なフライスルーツールは、横に並べたレビュー、以前に閲覧された範囲の色付け、百分率カバレージ追跡、及び順方向、逆方向、魚眼及び平坦ボリュームレンダリングビューを含む複数の画面レイアウトをサポートする。コントラストサブトラクション、「キューブビュー」、及び統合コンテキスト報告のためのツールをサポートすることができる。ｉＮｔｕｉｔｉｏｎの球状ファインダを含む任意的な検出エンジンからの候補マーカの表示及び管理をサポートすることができる。

容積ヒストグラムツールは、当該の容積をセグメント化して比較のために分析することができる。研究用途は、肺の低減衰領域の分析、ボクセル集団への腫瘍の閾値ベースの分割、血栓症血管又は動脈瘤、又は他の病変の検査を含む。

発見ワークフローツールは、連続の試験にわたって発見を追跡するためのフレームワークを提供する。データベースは、測定値及びキー画像を保持し、連続の比較を提示するためのＲＥＣＩＳＴ１．１手法のような時間の経過につれた発見の構造化比較及び表計算報告に対するサポートを提供する。音声認識システム又は臨床データベースとの自動統合のための注釈及び画像マークアップ（ＡＩＭ）ＸＭＬ方式をサポートすることができ、ワードベースの報告をデータベースから取得することができる。

これらのツールにより、いずれの２つのＣＴ、ＰＥＴ、ＭＲ、又はＳＰＥＣＴシリーズ、又はこれらのいずれの２つのシリーズの組合せもオーバーレイすることができ、部分的には、半透明のカラーコーディングを割り当て、他方は解剖学上の基準に対してグレースケール及び容積でレンダリングされる。自動登録を提供し、一時的シリーズ又は保存された第３のシリーズへのサブトラクションが可能である。ＰＥＴ／ＭＲ視覚化のためのサポートが含まれる。

ある一定のＭＲ試験（例えば、胸部ＭＲ）は、ある期間にわたって行われる一連の画像収集を伴い、特定の構造が、他の構造に対して時間と共に拡張される。これらのツールは、全ての過去の拡張画像から事前拡張画像を差し引いて拡張構造（例えば、血管構造及び他の拡張組織）の視覚化を強調する。時間依存の当該の領域ツールは、定められた領域の時間−強度グラフを生成するために提供することができる。

パラメータマッピングツールは、多相ＭＲツールの拡張であり、パラメータマッピングオプションが、画像における各ピクセルがピクセル強度の時間依存挙動に応答してカラー符号化されるオーバーレイマップを事前計算する。一例として、このツールを胸部ＭＲに使用することができ、拡張領域の識別及び検査の速度を上げる。

マルチＫｖツールは、複数の販売業者からの二重エネルギ及び空間画像収集のためのサポートを提供し、セグメント化又はコントラスト抑制のような標準的な画像処理アルゴリズム、並びに正確な分析のための一般的なツールキット及び新しい技術の開発を提供する。

図１０は、一実施形態による患者情報と関連付けられた画像の両方をＭＲＣＳ内に表示する方法を示す流れ図である。方法１０００は、図１のＭＲＣＳ１０７によって実行することができる。図１０を参照すると、ブロック１００５で、患者の医療情報が統合ＭＲＣＳで得られる。一実施形態において、医療情報は、図３の医療データサーバ１１５に類似の遠隔サーバから得られる。このような実施形態において、統合ＭＲＣＳのユーザは、適切なセキュリティ信用証明、例えば、アクセス制御システム１１６によって認証される有効なユーザＩＤ及びパスワードにより、ＭＲＣＳサーバ１１５のような遠隔医療データサーバにログオンにするように望ましい。

ブロック１０１０で、統合医療ソフトウエアは、取得した医療情報の一部をネットワーク上で遠隔医療画像処理サーバに送信する。一実施形態において、送信される医療情報は、少なくとも患者の患者ＩＤを含む。ブロック１０１５で、患者ＩＤに関連付けられる１つ又はそれよりも多くの医療画像が、統合ＭＲＣＳ内で見ることができるようになる。一実施形態において、患者ＩＤに関連付けられる医療画像は、遠隔医療画像処理サーバによって識別される。

ブロック１０２０で、統合医療ソフトウエアは、医療ソフトウエアのユーザに別のプログラム（例えば、別のマニュアルログイン又は別のプログラムを通じたログイン）を通して同じ画像を別々に取得するように要求することなく、そのＧＵＩ内に患者医療情報と１つ又はそれよりも多くの医療画像の両方を表示する。一実施形態において、ＧＵＩは、統合医療ソフトウエアウィンドウと同じウィンドウである。代替の実施形態において、ＧＵＩは、統合医療ソフトウエアウィンドウとは別のウィンドウである。

図１１は、本発明の一実施形態と共に使用することができるデータ処理システムのブロック図である。例えば、システム１１００は、図１に示すサーバ又はクライアントの一部として使用することができる。図１１はコンピュータシステムの様々な構成要素を示し、構成要素を相互接続するいずれかの特定のアーキテクチャ又は方式を表すように意図せず、このような詳細は本発明に密接な関係はないことに注意されたい。少ない構成要素又は恐らく多い構成要素を有するネットワークコンピュータ、手持ち式コンピュータ、携帯電話、及び他のデータ処理システムも本発明と共に使用することができることが認められるであろう。

図１１に示すように、データ処理システムの形式であるコンピュータシステム１１００は、１つ又はそれよりも多くのマイクロプロセッサ１１０３及びＲＯＭ１１０７、揮発性ＲＡＭ１１０５、及び不揮発性メモリ１１０６に結合されるバス又は相互接続１１０２を含む。マイクロプロセッサ１１０３は、キャッシュメモリ１１０４に結合される。バス１１０２は、これらの様々な構成要素を互いに相互接続し、これらの構成要素１１０３、１１０７、１１０５、及び１１０６をディスプレイコントローラ及びディスプレイデバイス１１０８、並びにマウス、キーボード、モデム、ネットワークインタフェース、プリンタ、及び当業技術で公知の他のデバイスとすることができる入力／出力（Ｉ／Ｏ）デバイスに相互接続する。

一般的に、入力／出力デバイス１１１０は、入力／出力コントローラ１１０９を通して本発明のシステムに結合される。揮発性ＲＡＭ１１０５は、一般的に、メモリ内のデータをリフレッシュ又は維持するために継続して電力を必要とするダイナミックＲＡＭ（ＤＲＡＭ）として実施される。不揮発性メモリ１１０６は、一般的に、磁気ハードドライブ、磁気光学ドライブ、光学ドライブ、又はＤＶＤ ＲＡＭ又は電力がシステムから取り除かれた後でもデータを維持する他のタイプのメモリシステムである。一般的に、不揮発性メモリは、これが望ましいわけではないが、ランダムアクセスメモリにもなる。

図１１は、不揮発性メモリがデータ処理システムにおける構成要素の残りに直接結合されたローカルデバイスであることを示しているが、本発明は、モデム又はイーサネット（登録商標）インタフェースのようなネットワークインタフェースを通してデータ処理システムに結合されるネットワーク格納デバイスのようなシステムから遠隔にある不揮発性メモリを利用することができる。バス１１０２は、当業技術で公知のように、様々なブリッジ、コントローラ、及び／又はアダプタを通して互いに接続した１つ又はそれよりも多くのバスを含むことができる。一実施形態において、Ｉ／Ｏコントローラ１１０９は、ＵＳＢ周辺機器を制御するためのＵＳＢ（ユニバーサルシリアルバス）アダプタを含む。代替的に、Ｉ／Ｏコントローラ１１０９は、ファイヤワイヤデバイスを制御するためのファイヤワイヤアダプタとして公知のＩＥＥＥ−１３９４アダプタを含むことができる。

上述の詳細説明の一部の部分は、コンピュータメモリ内のデータビットにおける作動のアルゴリズム及び記号表現を用いて提示された。これらのアルゴリズム説明及び表現は、その作業の内容を当業技術の他者に最も効率的に伝えるためにデータ処理技術における当業者によって使用される方法である。本明細書におけるアルゴリズムは、一般的に、望ましい結果をもたらす作動の自己矛盾のないシーケンスであると考えられる。作動は、物理的な量の物理的な操作を必要とするものである。

しかし、これらの及び類似の語の全てが適切な物理量に関連付けられるものであり、単にこれらの量に与えられる便利なラベルであることを念頭に置かれたい。以上の説明から明らかなように他に具体的に指示がない限り、本説明を通して、特許請求の範囲に示すような語を利用する説明は、コンピュータシステム、又はコンピュータシステムのレジスタ及びメモリ内の物理的な（電子的）量として表されるデータをコンピュータシステムメモリ又はレジスタ又は他のこのような情報格納、送信又はディスプレイデバイス内の物理的な量として同様に表される他のデータに操作及び変換する類似の電子コンピュータデバイスの作動及び処理を示すことを理解しなければならない。

図に示す技術は、１つ又はそれよりも多くの電子デバイスに格納されて実行されるコード及びデータを使用して実施することができる。このような電子デバイスは、持続性コンピュータ可読ストレージ媒体（例えば、磁気ディスク、光学ディスク、ランダムアクセスメモリ、読取専用メモリ、フラッシュメモリデバイス、フェーズ−変更メモリ）及び一時的コンピュータ可読送信媒体（例えば、電子、光学、音響又は他の形式の伝播信号−搬送波、赤外線信号、デジタル信号など）のようなコンピュータ可読媒体を使用してコード及びデータを（内部で及び／又はネットワーク上の他の電子デバイスにより）格納及び伝送する。

上述の図に示す処理又は方法は、ハードウエア（例えば、回路、専用論理部など）、ファームウエア、ソフトウエア（例えば、持続性コンピュータ可読媒体に組み込まれる）、又はこれらの両方の組合せを含む処理論理部によって実行することができる。処理又は方法はいくつかの連続する作動の点で上述されているが、説明する作動のいくつかは異なる順序で実行することができることを理解しなければならない。更に、一部の作動は、連続してではなく並行して実行することができる。

上述の明細書では、本発明の実施形態をその特定の例示的な実施形態に関して説明している。特許請求の範囲に示すような本発明の様々な精神及び範囲から逸脱することなく本明細書に様々な変更を実行することができることは明らかであろう。明細書及び図面は、従って、制限の意味ではなく例示的な意味と捉えるべきである。

１０２ ＥＭＲデータ
１０３ 試験記録
１０４ 画像処理エンジン
１０５ 画像ストア
１０６ アクセス制御システム

Claims (23)

1. 医療記録及び／又は臨床試験ソフトウエア（ＭＲＣＳ）によって実行されるコンピュータ実施式方法であって、
   患者の医療処置履歴を含む該患者の医療情報の少なくとも一部分をローカルデバイス内で実行される前記ＭＲＣＳ内に表示する段階と、
   前記患者の前記表示された医療情報の少なくとも一部分をネットワーク上で医療画像処理サーバに送信する段階であって、該送信される医療情報が、該患者の患者識別子（ＩＤ）を含む前記送信する段階と、
   患者医療情報の前記少なくとも一部分及び前記患者に関連付けられて前記医療画像処理サーバによってレンダリングされた１つ又はそれよりも多くの医療画像の両方を前記ＭＲＣＳの現在のユーザに該１つ又はそれよりも多くの画像を取得するために該医療画像処理サーバに個別に及び手動でログインするように要求することなく該ＭＲＣＳ内に表示する段階であって、該１つ又はそれよりも多くの医療画像が、前記患者ＩＤに基づいて該医療画像処理サーバによって識別される前記表示する段階と、
   ユーザによって起動された時に画像を前記画像処理サーバによって操作することを可能にする画像処理ツールのセットを表すアイコンのセットを前記ＭＲＣＳ内に表示する段階と、
   を含むことを特徴とする方法。
2. 前記医療情報は、医療記録プロバイダから提供される前記患者の医療記録の一部であることを特徴とする請求項１に記載の方法。
3. 前記医療画像処理サーバによって提供される撮像ツールの前記セットを使用して前記１つ又はそれよりも多くの医療画像を操作する段階を更に含むことを特徴とする請求項１に記載の方法。
4. 前記医療ソフトウエアは、臨床試験ソフトウエアであり、
   前記医療情報は、前記患者のアイデンティティを明らかにしない、
   ことを特徴とする請求項１に記載の方法。
5. 前記１つ又はそれよりも多くの医療画像は、前記ＭＲＣＳと同じウィンドウに表示されることを特徴とする請求項１に記載の方法。
6. 前記アイコンは、前記表示された医療画像のタイプに基づいて表示され、
   前記表示された医療画像を操作するように設計されたツールだけが利用可能である、
   ことを特徴とする請求項１に記載の方法。
7. 前記アイコンは、前記ＭＲＣＳのユーザプリファレンスに基づいて表示されることを特徴とする請求項６に記載の方法。
8. 前記送信される医療情報は、前記患者の身体の部分を識別する身体部分識別子を更に含み、
   前記１つ又はそれよりも多くの医療画像は、前記身体部分識別子によって識別される前記患者の身体部分に関連する、
   ことを特徴とする請求項１に記載の方法。
9. 前記身体部分識別子は、医療におけるデジタル撮像及び通信（ＤＩＣＯＭ）タグを含むことを特徴とする請求項８に記載の方法。
10. 実行された時に処理デバイスをして、
    患者の医療処置履歴を含む該患者の医療情報の少なくとも一部分をローカルデバイス内で実行される医療記録及び／又は臨床試験ソフトウエア（ＭＲＣＳ）内に表示する段階と、
    前記患者の前記表示された医療情報の少なくとも一部分をネットワーク上で医療画像処理サーバに送信する段階であって、該送信される医療情報が、該患者の患者識別子（ＩＤ）を含む前記送信する段階と、
    患者医療情報の前記少なくとも一部分及び前記患者に関連付けられて前記医療画像処理サーバによってレンダリングされた１つ又はそれよりも多くの医療画像の両方を前記ＭＲＣＳの現在のユーザに該１つ又はそれよりも多くの画像を取得するために該医療画像処理サーバに個別に及び手動でログインするように要求することなく該ＭＲＣＳ内に表示する段階であって、該１つ又はそれよりも多くの医療画像が、前記患者ＩＤに基づいて該医療画像処理サーバによって識別される前記表示する段階と、
    ユーザによって起動された時に画像を前記画像処理サーバによって操作することを可能にする撮像ツールのセットを表すアイコンのセットを前記ＭＲＣＳ内に表示する段階と、
    を含む方法を実行させる命令を格納する持続性機械可読媒体。
11. 前記医療情報は、医療記録プロバイダから提供される前記患者の医療記録の一部であることを特徴とする請求項１０に記載の持続性機械可読媒体。
12. 前記方法は、前記医療画像処理サーバによって提供される撮像ツールの前記セットを使用して前記１つ又はそれよりも多くの医療画像を操作する段階を更に含むことを特徴とする請求項１０に記載の持続性機械可読媒体。
13. 前記医療ソフトウエアは、臨床試験ソフトウエアであり、
    前記医療情報は、前記患者のアイデンティティを明らかにしない、
    ことを特徴とする請求項１０に記載の持続性機械可読媒体。
14. 前記１つ又はそれよりも多くの医療画像は、前記ＭＲＣＳと同じウィンドウに表示されることを特徴とする請求項１０に記載の持続性機械可読媒体。
15. 前記アイコンは、前記表示された医療画像のタイプに基づいて表示され、
    前記表示された医療画像を操作するように設計されたツールだけが利用可能である、
    ことを特徴とする請求項１０に記載の持続性機械可読媒体。
16. 前記送信される医療情報は、前記患者の身体部分を識別する身体部分識別子を更に含み、
    前記１つ又はそれよりも多くの医療画像は、前記身体部分識別子によって識別される前記患者の身体部分に関連する、
    ことを特徴とする請求項１０に記載の持続性機械可読媒体。
17. プロセッサと、
    医療記録及び／又は臨床試験ソフトウエア（ＭＲＣＳ）を表す命令を格納するメモリであって、該命令が、該メモリから実行された時に前記プロセッサをして、
    患者の医療処置履歴を含む該患者の医療情報の少なくとも一部分を前記ＭＲＣＳに関連付けられたウィンドウに表示させ、
    前記患者の患者識別子（ＩＤ）を含む該患者の前記表示された医療情報の少なくとも一部分をネットワーク上で医療画像処理サーバに送信させ、
    患者医療情報の前記少なくとも一部分と、前記患者に関連付けられて医療画像処理サーバによってレンダリングされ、前記患者ＩＤに基づいて該医療画像処理サーバによって識別される１つ又はそれよりも多くの医療画像とを前記ＭＲＣＳの現在のユーザに該１つ又はそれよりも多くの画像を取得するために該医療画像処理サーバに個別に及び手動でログインするように要求することなく該ＭＲＣＳ内に表示させ、かつ
    ユーザによって起動された時に画像を前記画像処理サーバによって操作することを可能にする撮像ツールのセットを表すアイコンのセットを前記ウィンドウ内に表示させる、
    前記メモリと、
    を含むことを特徴とするデータ処理システム。
18. 前記医療情報は、医療記録プロバイダから提供された前記患者の医療記録の一部であることを特徴とする請求項１７に記載のシステム。
19. 前記１つ又はそれよりも多くの医療画像は、前記医療画像処理サーバによって提供される撮像ツールの前記セットを使用して操作されることを特徴とする請求項１７に記載のシステム。
20. 前記医療ソフトウエアは、臨床試験ソフトウエアであり、
    前記医療情報は、前記患者のアイデンティティを明らかにしない、
    ことを特徴とする請求項１７に記載のシステム。
21. 前記１つ又はそれよりも多くの医療画像は、前記ＭＲＣＳと同じウィンドウに表示されることを特徴とする請求項１７に記載のシステム。
22. 前記アイコンは、前記表示された医療画像のタイプに基づいて表示され、
    前記表示された医療画像を操作するように設計されたツールだけが利用可能である、
    ことを特徴とする請求項１７に記載のシステム。
23. 前記送信される医療情報は、前記患者の身体部分を識別する身体部分識別子を更に含み、
    前記１つ又はそれよりも多くの医療画像は、前記身体部分識別子によって識別される前記患者の身体部分に関連する、
    ことを特徴とする請求項１７に記載のシステム。