知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6689919
(24)【登録日】2020年4月10日
(45)【発行日】2020年4月28日
(54)【発明の名称】医療情報用の進化型コンテキスト臨床データエンジン
(51)【国際特許分類】
G16H 15/00 20180101AFI20200421BHJP
G16H 30/00 20180101ALI20200421BHJP
【ＦＩ】
G16H15/00
G16H30/00
【請求項の数】15
【全頁数】41
(21)【出願番号】特願2018-134692(P2018-134692)
(22)【出願日】2018年7月18日
(62)【分割の表示】特願2016-527283(P2016-527283)の分割
【原出願日】2014年11月3日
(65)【公開番号】特開2018-185856(P2018-185856A)
(43)【公開日】2018年11月22日
【審査請求日】2018年7月18日
(31)【優先権主張番号】61/899,699
(32)【優先日】2013年11月4日
(33)【優先権主張国】US
(31)【優先権主張番号】61/909,920
(32)【優先日】2013年11月27日
(33)【優先権主張国】US
(31)【優先権主張番号】61/911,302
(32)【優先日】2013年12月3日
(33)【優先権主張国】US
(31)【優先権主張番号】61/984,624
(32)【優先日】2014年4月25日
(33)【優先権主張国】US
(31)【優先権主張番号】14/530,520
(32)【優先日】2014年10月31日
(33)【優先権主張国】US
(73)【特許権者】
【識別番号】514206282
【氏名又は名称】テラリコン インコーポレイテッド
(74)【代理人】
【識別番号】100094569
【弁理士】
【氏名又は名称】田中 伸一郎
(74)【代理人】
【識別番号】100088694
【弁理士】
【氏名又は名称】弟子丸 健
(74)【代理人】
【識別番号】100067013
【弁理士】
【氏名又は名称】大塚 文昭
(74)【代理人】
【識別番号】100086771
【弁理士】
【氏名又は名称】西島 孝喜
(74)【代理人】
【識別番号】100109070
【弁理士】
【氏名又は名称】須田 洋之
(74)【代理人】
【識別番号】100109335
【弁理士】
【氏名又は名称】上杉 浩
(74)【代理人】
【識別番号】100120525
【弁理士】
【氏名又は名称】近藤 直樹
(74)【代理人】
【識別番号】100139712
【弁理士】
【氏名又は名称】那須 威夫
(72)【発明者】
【氏名】ソレンソン ジェフリー
【審査官】
牧 裕子
(56)【参考文献】
【文献】
特表２００９−５１２０１０（ＪＰ，Ａ）
【文献】
特表２０１２−５１０６７０（ＪＰ，Ａ）
【文献】
特開２０１３−１０６９５１（ＪＰ，Ａ）
【文献】
特開２００８−２２５５８７（ＪＰ，Ａ）
【文献】
米国特許出願公開第２０１３／０１３２１１７（ＵＳ，Ａ１）
(58)【調査した分野】（Int.Cl.，ＤＢ名）
Ｇ０６Ｑ １０／００ − ９９／００
Ｇ１６Ｈ １０／００ − ８０／００
(57)【特許請求の範囲】
【請求項1】
医療情報を処理するためのコンピュータ実施方法において、
ネットワークを経てクライアント装置からの信号を医療情報サーバーで受信し、その信号は、クライアント装置に表示された第１の医療情報に対するユーザの第１のユーザ相互作用を表わすものであり、
前記信号に応答して、ユーザ相互作用分析器により、ユーザに関連した１つ以上の進化コンテキスト臨床データ（ＥＣＣＤ）ルールの第１セットを、前記第１のユーザ相互作用に基づいて呼び出して、おそらくユーザの関心を引く１つ以上の医療データカテゴリーを決定し、前記ＥＣＣＤルールの第１セットは、ＥＣＣＤエンジンにより発生されるものであり、前記ＥＣＣＤエンジンは前記ユーザに提示された異なる医療情報との以前のユーザ相互作用に基づいて前記ユーザの振舞いパターンを導出するものであり、
データ検索モジュールにより、前記医療データカテゴリーに対応する１つ以上の医療データサーバーにアクセスして、前記医療データカテゴリーの医療データを検索し、前記アクセスすることは、
前記医療データカテゴリーに対応するピクチャーアーカイブ・通信システム（ＰＡＣＳ）から医療画像データを検索し、
前記医療データカテゴリーに対応する電子医療レコード（ＥＭＲ）から医療レコードデータを検索し、
ラボラトリー情報システム（ＬＩＳ）からレポートデータを検索することを含み、前記１つ以上の医療データサーバーは、ビューアユーザインタフェースを介して構成され得る構成可能な通信プロトコルを通してアクセス可能である、
ことを含み、
前記医療情報サーバーのビュージェネレータにより、前記検索された医療画像データ、前記検索された医療レコードデータ及び前記検索された医療レポートデータを統合して、第２の医療情報の１つ以上のビューを発生し、及び
前記ビュージェネレータにより、前記クライアント装置のディスプレイに表示するための前記第２の医療情報の１つ以上のビューを前記クライアント装置に送信し、各画像処理ツールの利用頻度の観点から前記ＥＣＣＤエンジンによって決定された１つ以上の画像処理ツールが前記第２の医療情報の１つ以上のビューに含まれ、前記前記１つ以上のビューはレイアウト及びフォーミュレーションの組み合わせに基づき配列され、前記レイアウトは前記ユーザの１つ以上の好みに鑑み前記ユーザのために配列され、前記フォーミュレーションは前記ＥＣＣＤルールの第１のセットに鑑み前記ＥＣＣＤエンジンによって推薦される、
ことを含む方法。
ネットワークを経てクライアント装置からの信号を医療情報サーバーで受信し、その信号は、クライアント装置に表示された第１の医療情報に対するユーザの第１のユーザ相互作用を表わすものであり、
前記信号に応答して、ユーザ相互作用分析器により、ユーザに関連した１つ以上の進化コンテキスト臨床データ（ＥＣＣＤ）ルールの第１セットを、前記第１のユーザ相互作用に基づいて呼び出して、おそらくユーザの関心を引く１つ以上の医療データカテゴリーを決定し、前記ＥＣＣＤルールの第１セットは、ＥＣＣＤエンジンにより発生されるものであり、前記ＥＣＣＤエンジンは前記ユーザに提示された異なる医療情報との以前のユーザ相互作用に基づいて前記ユーザの振舞いパターンを導出するものであり、
データ検索モジュールにより、前記医療データカテゴリーに対応する１つ以上の医療データサーバーにアクセスして、前記医療データカテゴリーの医療データを検索し、前記アクセスすることは、
前記医療データカテゴリーに対応するピクチャーアーカイブ・通信システム（ＰＡＣＳ）から医療画像データを検索し、
前記医療データカテゴリーに対応する電子医療レコード（ＥＭＲ）から医療レコードデータを検索し、
ラボラトリー情報システム（ＬＩＳ）からレポートデータを検索することを含み、前記１つ以上の医療データサーバーは、ビューアユーザインタフェースを介して構成され得る構成可能な通信プロトコルを通してアクセス可能である、
ことを含み、
前記医療情報サーバーのビュージェネレータにより、前記検索された医療画像データ、前記検索された医療レコードデータ及び前記検索された医療レポートデータを統合して、第２の医療情報の１つ以上のビューを発生し、及び
前記ビュージェネレータにより、前記クライアント装置のディスプレイに表示するための前記第２の医療情報の１つ以上のビューを前記クライアント装置に送信し、各画像処理ツールの利用頻度の観点から前記ＥＣＣＤエンジンによって決定された１つ以上の画像処理ツールが前記第２の医療情報の１つ以上のビューに含まれ、前記前記１つ以上のビューはレイアウト及びフォーミュレーションの組み合わせに基づき配列され、前記レイアウトは前記ユーザの１つ以上の好みに鑑み前記ユーザのために配列され、前記フォーミュレーションは前記ＥＣＣＤルールの第１のセットに鑑み前記ＥＣＣＤエンジンによって推薦される、
ことを含む方法。
【請求項2】
前記信号を受信する前に、
ユーザに提示された異なる医療情報との以前のユーザ相互作用を監視し及び捕獲し、
前記ＥＣＣＤエンジンにより、前記捕獲されたユーザ相互作用に対してアルゴリズムを使用して分析を遂行し、前記異なる医療情報に応答して前記ユーザの振舞いパターンを導出し、及び
前記ＥＣＣＤエンジンにより、前記ユーザの振舞いパターンに基づいて前記ＥＣＣＤルールの第１セットを発生する、
ことを更に含む、請求項１に記載の方法。
ユーザに提示された異なる医療情報との以前のユーザ相互作用を監視し及び捕獲し、
前記ＥＣＣＤエンジンにより、前記捕獲されたユーザ相互作用に対してアルゴリズムを使用して分析を遂行し、前記異なる医療情報に応答して前記ユーザの振舞いパターンを導出し、及び
前記ＥＣＣＤエンジンにより、前記ユーザの振舞いパターンに基づいて前記ＥＣＣＤルールの第１セットを発生する、
ことを更に含む、請求項１に記載の方法。
【請求項3】
前記クライアント装置に表示される第２の医療情報の１つ以上のビューに対してユーザの第２のユーザ相互作用を受信し、
前記第２のユーザ相互作用に鑑み、ＥＣＣＤモデルをトレーニングして、前記ＥＣＣＤルールの第１セットからの更新である１つ以上のＥＣＣＤルールの第２セットを発生し、及び
前記ＥＣＣＤルールの第２セットをユーザに関連したユーザデータベースに記憶し、前記ＥＣＣＤルールの第２セットは、おそらくユーザの関心を引く将来の医療情報を予想するために、前記ＥＣＣＤルールの第１セットに代って使用される、
ことを更に含む、請求項２に記載の方法。
前記第２のユーザ相互作用に鑑み、ＥＣＣＤモデルをトレーニングして、前記ＥＣＣＤルールの第１セットからの更新である１つ以上のＥＣＣＤルールの第２セットを発生し、及び
前記ＥＣＣＤルールの第２セットをユーザに関連したユーザデータベースに記憶し、前記ＥＣＣＤルールの第２セットは、おそらくユーザの関心を引く将来の医療情報を予想するために、前記ＥＣＣＤルールの第１セットに代って使用される、
ことを更に含む、請求項２に記載の方法。
【請求項4】
前記医療データサーバーの各々に対し、医療データインターフェイスモジュールを維持して、適合性のある通信プロトコルを使用して対応する医療データサーバーと特に通信することを更に含む、請求項１に記載の方法。
【請求項5】
前記医療データサーバーは、異なる組織により動作される、請求項４に記載の方法。
【請求項6】
前記医療データカテゴリーは、医療画像、電子医療レコード、ラボラトリー情報、及び病院情報を含む、請求項１に記載の方法。
【請求項7】
前記医療データサーバーは、ピクチャーアーカイブ及び情報システム（ＰＡＣＳ）、電子的医療レコード（ＥＭＲ）サーバー、ラボラトリー情報サーバー、及び病院情報システムを含む、請求項６に記載の方法。
【請求項8】
前記第２の医療情報は、前記第１の医療情報に関連したユーザにより要求された第１の医療データを含み、そして前記第２の医療情報は、ユーザにより要求されないがＥＣＣＤルールの第１セットにより推薦される第２の医療データを含む、請求項１に記載の方法。
【請求項9】
前記ＥＣＣＤルールの第１セットに基づいて、前記第１の医療情報に鑑みユーザがおそらく使用する１つ以上の画像処理ツールのセットを決定し、及び
前記画像処理ツールのセットを表わすツール情報を前記クライアント装置へ送信し、前記画像処理ツールのセットは、グラフィック表現のセットとして前記クライアント装置に提示される、
ことを更に含む、請求項１に記載の方法。
前記画像処理ツールのセットを表わすツール情報を前記クライアント装置へ送信し、前記画像処理ツールのセットは、グラフィック表現のセットとして前記クライアント装置に提示される、
ことを更に含む、請求項１に記載の方法。
【請求項10】
前記医療データカテゴリーの医療データは、医療データサーバーの複数のサーバーから検索される、請求項１に記載の方法。
【請求項11】
前記医療データカテゴリーは、前記クライアント装置に表示される第１の医療情報のメタデータに関連したＥＣＣＤルールの第２セットに更に基づいて決定される、請求項１に記載の方法。
【請求項12】
プロセッサにより実行されたときにプロセッサが請求項１から１１のいずれかの動作を遂行するようにさせるインストラクションが記憶されるマシン読み取り可能な媒体。
【請求項13】
ネットワークを経てクライアント装置から信号を受信するためのユーザ相互作用分析器を備え、その信号は、クライアント装置に表示された第１の医療情報に対するユーザの第１のユーザ相互作用を表わすものであり、ユーザに関連した１つ以上の進化コンテキスト臨床データ（ＥＣＣＤ）ルールの第１セットを、前記第１のユーザ相互作用に基づいて呼び出して、おそらくユーザの関心を引く１つ以上の医療データカテゴリーを決定し、前記ＥＣＣＤルールの第１セットは、ＥＣＣＤエンジンにより発生されるものであり、前記ＥＣＣＤエンジンは前記ユーザに提示された異なる医療情報との以前のユーザ相互作用に基づいて前記ユーザの振舞いパターンを導出するものであり、更に、
前記ユーザ相互作用分析器に結合され、前記医療データカテゴリーに対応する１つ以上の医療データサーバーにアクセスして、前記医療データカテゴリーの医療データを検索するためのデータ検索モジュールであって、前記アクセスすることは、
前記医療データカテゴリーに対応するピクチャーアーカイブ・通信システム（ＰＡＣＳ）から医療画像データを検索し、
前記医療データカテゴリーに対応する電子医療レコード（ＥＭＲ）から医療レコードデータを検索し、
ラボラトリー情報システム（ＬＩＳ）からレポートデータを検索することを含み、前記１つ以上の医療データサーバーは、ビューアユーザインタフェースを介して構成され得る構成可能な通信プロトコルを通してアクセス可能である、
ことを含む、データ検索モジュール、及び
前記データ検索モジュールに結合され、前記検索された医療画像データ、前記検索された医療レコードデータ及び前記検索された医療レポートデータを統合して、第２の医療情報の１つ以上のビューを発生し、且つ前記第２の医療情報の１つ以上のビューを前記クライアント装置に送信して、前記クライアント装置のディスプレイに表示するためのビュージェネレータであって、各画像処理ツールの利用頻度の観点から前記ＥＣＣＤエンジンによって決定された１つ以上の画像処理ツールは前記第２の医療情報の１つ以上のビューに含まれ、前記１つ以上のビューはレイアウト及びフォーミュレーションの組み合わせに基づき配列され、前記レイアウトは前記ユーザの１つ以上の好みに鑑み前記ユーザのために配列され、前記フォーミュレーションは前記ＥＣＣＤルールの第１のセットに鑑み前記ＥＣＣＤエンジンによって推薦される、ビュージェネレータ、
を備えた、データ処理システム。
前記ユーザ相互作用分析器に結合され、前記医療データカテゴリーに対応する１つ以上の医療データサーバーにアクセスして、前記医療データカテゴリーの医療データを検索するためのデータ検索モジュールであって、前記アクセスすることは、
前記医療データカテゴリーに対応するピクチャーアーカイブ・通信システム（ＰＡＣＳ）から医療画像データを検索し、
前記医療データカテゴリーに対応する電子医療レコード（ＥＭＲ）から医療レコードデータを検索し、
ラボラトリー情報システム（ＬＩＳ）からレポートデータを検索することを含み、前記１つ以上の医療データサーバーは、ビューアユーザインタフェースを介して構成され得る構成可能な通信プロトコルを通してアクセス可能である、
ことを含む、データ検索モジュール、及び
前記データ検索モジュールに結合され、前記検索された医療画像データ、前記検索された医療レコードデータ及び前記検索された医療レポートデータを統合して、第２の医療情報の１つ以上のビューを発生し、且つ前記第２の医療情報の１つ以上のビューを前記クライアント装置に送信して、前記クライアント装置のディスプレイに表示するためのビュージェネレータであって、各画像処理ツールの利用頻度の観点から前記ＥＣＣＤエンジンによって決定された１つ以上の画像処理ツールは前記第２の医療情報の１つ以上のビューに含まれ、前記１つ以上のビューはレイアウト及びフォーミュレーションの組み合わせに基づき配列され、前記レイアウトは前記ユーザの１つ以上の好みに鑑み前記ユーザのために配列され、前記フォーミュレーションは前記ＥＣＣＤルールの第１のセットに鑑み前記ＥＣＣＤエンジンによって推薦される、ビュージェネレータ、
を備えた、データ処理システム。
【請求項14】
ユーザに提示された異なる医療情報との以前のユーザ相互作用を監視し及び捕獲するためのユーザデータコレクタ、及び
前記捕獲されたユーザ相互作用に対してアルゴリズムを使用して分析を遂行し、前記異なる医療情報に応答して前記ユーザの振舞いパターンを導出し、及び前記ユーザの振舞いパターンに基づいて前記ＥＣＣＤルールの第１セットを発生するためのＥＣＣＤエンジン、
を更に備えた、請求項１３に記載のシステム。
前記捕獲されたユーザ相互作用に対してアルゴリズムを使用して分析を遂行し、前記異なる医療情報に応答して前記ユーザの振舞いパターンを導出し、及び前記ユーザの振舞いパターンに基づいて前記ＥＣＣＤルールの第１セットを発生するためのＥＣＣＤエンジン、
を更に備えた、請求項１３に記載のシステム。
【請求項15】
医療情報を処理するための装置において、
ネットワークを経てクライアント装置からの信号を医療情報サーバーで受信する手段を備え、その信号は、クライアント装置に表示された第１の医療情報に対するユーザの第１のユーザ相互作用を表わすものであり、更に、
前記信号に応答して、ユーザに関連した１つ以上の進化コンテキスト臨床データ（ＥＣＣＤ）ルールの第１セットを、前記第１のユーザ相互作用に基づいて呼び出して、おそらくユーザの関心を引く１つ以上の医療データカテゴリーを決定する手段を備え、前記ＥＣＣＤルールの第１セットは、ＥＣＣＤエンジンにより発生されるものであり、前記ＥＣＣＤエンジンは前記ユーザに提示された異なる医療情報との以前のユーザ相互作用に基づいて前記ユーザの振舞いパターンを導出するものであり、更に、
前記医療データカテゴリーに対応する１つ以上の医療データサーバーにアクセスして、前記医療データカテゴリーの医療データを検索する手段であって、
前記医療データカテゴリーに対応するピクチャーアーカイブ・通信システム（ＰＡＣＳ）から医療画像データを検索する手段と、
前記医療データカテゴリーに対応する電子医療レコード（ＥＭＲ）から医療レコードデータを検索する手段と、
ラボラトリー情報システム（ＬＩＳ）から医療レポートデータを検索する手段と、を含み、前記１つ以上の医療データサーバーは、ビューアユーザインタフェースを介して構成され得る構成可能な通信プロトコルを通してアクセス可能であり、
前記医療情報サーバーのデータ検索モジュールによって、前記検索された医療データを統合して、第２の医療情報の１つ以上のビューを発生する手段、及び
ビューアジェネレータによって、前記クライアント装置のディスプレイに表示するために前記第２の医療情報の１つ以上のビューを前記クライアント装置に送信する手段であって、各画像処理ツールの利用頻度の観点から前記ＥＣＣＤエンジンによって決定された１つ以上の画像処理ツールは前記第２の医療情報の１つ以上のビューに含まれ、前記１つ以上のビューはレイアウト及びフォーミュレーションの組み合わせに基づき配列され、前記レイアウトは前記ユーザの１つ以上の好みに鑑み前記ユーザのために配列され、前記フォーミュレーションは前記ＥＣＣＤルールの第１のセットに鑑み前記ＥＣＣＤエンジンによって推薦される、ディスプレイに表示する手段、
を備えた装置。
ネットワークを経てクライアント装置からの信号を医療情報サーバーで受信する手段を備え、その信号は、クライアント装置に表示された第１の医療情報に対するユーザの第１のユーザ相互作用を表わすものであり、更に、
前記信号に応答して、ユーザに関連した１つ以上の進化コンテキスト臨床データ（ＥＣＣＤ）ルールの第１セットを、前記第１のユーザ相互作用に基づいて呼び出して、おそらくユーザの関心を引く１つ以上の医療データカテゴリーを決定する手段を備え、前記ＥＣＣＤルールの第１セットは、ＥＣＣＤエンジンにより発生されるものであり、前記ＥＣＣＤエンジンは前記ユーザに提示された異なる医療情報との以前のユーザ相互作用に基づいて前記ユーザの振舞いパターンを導出するものであり、更に、
前記医療データカテゴリーに対応する１つ以上の医療データサーバーにアクセスして、前記医療データカテゴリーの医療データを検索する手段であって、
前記医療データカテゴリーに対応するピクチャーアーカイブ・通信システム（ＰＡＣＳ）から医療画像データを検索する手段と、
前記医療データカテゴリーに対応する電子医療レコード（ＥＭＲ）から医療レコードデータを検索する手段と、
ラボラトリー情報システム（ＬＩＳ）から医療レポートデータを検索する手段と、を含み、前記１つ以上の医療データサーバーは、ビューアユーザインタフェースを介して構成され得る構成可能な通信プロトコルを通してアクセス可能であり、
前記医療情報サーバーのデータ検索モジュールによって、前記検索された医療データを統合して、第２の医療情報の１つ以上のビューを発生する手段、及び
ビューアジェネレータによって、前記クライアント装置のディスプレイに表示するために前記第２の医療情報の１つ以上のビューを前記クライアント装置に送信する手段であって、各画像処理ツールの利用頻度の観点から前記ＥＣＣＤエンジンによって決定された１つ以上の画像処理ツールは前記第２の医療情報の１つ以上のビューに含まれ、前記１つ以上のビューはレイアウト及びフォーミュレーションの組み合わせに基づき配列され、前記レイアウトは前記ユーザの１つ以上の好みに鑑み前記ユーザのために配列され、前記フォーミュレーションは前記ＥＣＣＤルールの第１のセットに鑑み前記ＥＣＣＤエンジンによって推薦される、ディスプレイに表示する手段、
を備えた装置。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願：本出願は、２０１３年１１月４日に出願された米国プロビジョナル特許出願第６１／８９９，６００号、２０１３年１１月２７日に出願された特許出願第６１／９０９，９２０号、２０１３年１２月３日に出願された特許出願第６１／９１１，３００号、及び２０１４年４月２５日に出願された特許出願第６１／９８４，６２４号の利益を主張するもので、その開示は、参考としてここにそのまま援用される。
【0002】
本発明の実施形態は、一般的に、医療情報処理システムに関する。より特定すれば、本発明の実施形態は、進化型コンテキスト臨床データ（ＥＣＣＤ）エンジンを使用する医療情報処理に関する。
【背景技術】
【0003】
医療用ソフトウェアが益々精巧に且つ普遍的になるにつれて、異なるデータソースからの情報及びデータのインテリジェントな統合が益々重要で且つ益々大変なものになりつつある。例えば、電子医療レコード（ＥＭＲ）又は電子ヘルスレコード（ＥＨＲ）は、臨床トライアルソフトウェア、リサーチソフトウェア、及び他のものとして次第に一般的なものになりつつある。しかし、医療データは、放射線医学情報システム（ＲＩＳ）、病院情報システム（ＨＩＳ）、ピクチャーアーカイブ・通信システム（ＰＡＣＳ）、ラボラトリー情報システム（ＬＩＳ）、企業用コンテンツマネージメント（ＥＣＭ）システム、ＥＭＲデータ、種々のディレクトリー及び他のデータソースを含めて、互いにうまく通信できない多数のデータソースに存在する。これらデータソースは、異なる組織又は実体で運営される種々のサービスに設けられる。
【0004】
種々のデータソース間に通信がないのに加えて、ＥＭＲ、ＨＥＲ、医療トライアルソフトウェア、等の医療用ソフトウェアは、それらデータソースの１つ以上に接続する場所であっても、インテリジェントな仕方でも有用な仕方でも情報を与えない。医師、技術者、患者、等のユーザは、関連のある全ての情報に容易に且つ多数の異なるソフトウェアパッケージをアクティブにオープンせずにアクセスし、患者についてサーチし、次いで、関連のある情報をサーチする必要がある。
【0005】
例えば、患者が肺癌の処置を受けている場合には、主治医は、患者の薬、実行した関連手順、手順の結果、関連ラボテストの結果、人口統計学的データ、関連記録、レポート、口述文、等を見る必要がある。医師は、例えば、骨折したつま先のｘ線写真を見る必要はない。
【0006】
現在、これは、医療用ソフトウェアパッケージ内では実際的でない。あるＥＭＲソフトウェアは、ユーザがＸ線のような静止画像を人口統計学的データと共に見られるようにするが、ユーザは、全ての関連情報を一緒に見ることは容易にできない。現在、ユーザは、どこで関連情報を見つけそしてスクリーン、ディレクトリー、サーチウインドウ、等からバックアウトしてそれを見るか、又は異なるログイン等で異なるシステム上の情報を探索するか知らねばならない。種々のデータソースへの幾つかのコネクタは存在するが、エンドユーザに有用な仕方で同時に関連データを表示する知識を有するエンジン又はシステムは存在しない。
【0007】
種々の異なるデータソースに接続できるだけでなく、関連情報をインコンテキスト(in context)でエンドユーザへ有用な仕方で表示することもできるインテリジェントなシステムが要望される。理想的には、そのようなインテリジェントなシステムは、異なるデータソースからの関連情報を、データ表示のために論理的な仕方で編成されたビューア内においてインコンテキストでユーザに表示する。
【0008】
本発明の実施形態は、同様の要素が同じ参照番号で示された添付図面に一例として示されるが、これに限定されない。
【図面の簡単な説明】
【0009】
【図1】本発明の一実施形態により進化型コンテキスト臨床データ技術を使用する医療情報システムを示すブロック図である。
【図2】本発明の一実施形態によりクライアントの観点からＥＣＣＤエンジンがどのように動作するか示す処理フロー図である。
【図3】本発明の一実施形態によりＥＣＣＤエンジンの観点からＥＣＣＤエンジンがどのように動作するか示す処理フロー図である。
【図4】本発明の幾つかの実施形態によりＥＣＣＤエンジンとクライアント／ビューアユーザインターフェイスとの間の相互作用を示す。
【図5】本発明の一実施形態による医療情報システムを示すブロック図である。
【図6】本発明の一実施形態により医療情報を処理するための進化型コンテキスト臨床データエンジンを示すブロック図である。
【図7】本発明の一実施形態による医療情報サーバーのデータコレクタの一例を示すブロック図である。
【図8】本発明の一実施形態により進化型コンテキスト臨床データ技術を使用して医療データを処理するためのプロセスを示すフローチャートである。
【図9】本発明の一実施形態により進化型コンテキスト臨床データ技術を使用して医療データを処理するためのプロセスを示すフローチャートである。
【図10A】本発明の幾つかの実施形態により医療情報を与えるためのグラフィックユーザインターフェイスの例を示すスクリーンショットである。
【図10B】本発明の幾つかの実施形態により医療情報を与えるためのグラフィックユーザインターフェイスの例を示すスクリーンショットである。
【図10C】本発明の幾つかの実施形態により医療情報を与えるためのグラフィックユーザインターフェイスの例を示すスクリーンショットである。
【図10D】本発明の幾つかの実施形態により医療情報を与えるためのグラフィックユーザインターフェイスの例を示すスクリーンショットである。
【図10E】本発明の幾つかの実施形態により医療情報を与えるためのグラフィックユーザインターフェイスの例を示すスクリーンショットである。
【図10F】本発明の幾つかの実施形態により医療情報を与えるためのグラフィックユーザインターフェイスの例を示すスクリーンショットである。
【図11A】本発明の幾つかの実施形態によるクラウドベースの画像処理システムを示すブロック図である。
【図11B】本発明の幾つかの実施形態によるクラウドベースの画像処理システムを示すブロック図である。
【図12】本発明の一実施形態に使用されるデータ処理システムのブロック図である。
【発明を実施するための形態】
【0010】
本発明の種々の実施形態及び態様を以下に詳細に説明し、添付図面は、種々の実施形態を示している。以下の説明及び添付図面は、本発明を例示するもので、本発明を限定するものではない。本発明の種々の実施形態を完全に理解するために多数の特定の細部について述べる。しかしながら、幾つかの例において、本発明の実施形態の簡潔な説明をなすために、良く知られた又は従来の細部については説明しない。
【0011】
本明細書において「ある実施形態」又は「一実施形態」とは、その実施形態に関連して述べる特定の特徴、構造又は特性が本発明の少なくとも１つの実施形態に包含されることを意味する。本明細書の種々の場所に「ある実施形態では」という句が現れたときには、必ずしも全てが同じ実施形態を指していない。
【0012】
幾つかの実施形態によれば、本発明の実施形態は、ＤＩＣＯＭ（医学におけるデジタル画像及び通信）画像、非ＤＩＣＯＭ画像、テキスト、レポート、ＰＤＦ（ポータブルドキュメントフォーマット）ドキュメント、ＪＰＥＧ（ジョイントフォトグラフエキスパートグループ）ファイル、オーディオファイル、ビデオファイル、オフィスドキュメント、他のデータオブジェクト、等を含めて、進化型コンテキスト臨床データ技術を使用する医療データの統合と、関連データの表示とを有用な仕方で又は「インコンテキスト(in context)」でエンドユーザに提供するものである。「インコンテキスト」とは、表示されるデータが、ユーザが何をサーチしているかに関連することを意味する。例えば、「インコンテキスト」とは、患者ＩＤ、アクセス番号、研究ＩＤ、ログインクレデンシャル、日付、時間フレーム、エピソード、約束、ボディ部位又はエリア、ユーザ、研究、保険コード、医療トライアル、等、又はそれらパラメータの組み合わせに関連したデータを表示することを意味する。
【0013】
例えば、患者は、最近脳スキャンを受け、その結果について医師との相談を希望する。医師は、患者のＥＭＲレコード、ＤＩＣＯＭスキャン画像、おそらくは画像処理ツールを見て、スキャン画像、もし入手できれば以前の脳スキャン、患者が飲む関連薬品、関連ラボテスト、及び関連レポートを処理することを希望する。医師は、昨年起きた脚の骨折、２年前の妊娠、皮膚アレルギーの写真、又は他の非関連情報に関する情報によりウィーディングすることに関心はない。
【0014】
ある実施形態によれば、医療情報サーバーは、ＥＣＣＤエンジンを使用して、その医療情報サーバーによって提示された医療情報とユーザとの過去の相互作用を分析する。医療情報サーバーにより与えられる異なる医療情報に関するユーザ振舞いパターンの分析に基づき、ＥＣＣＤエンジンは、特定ユーザの振舞いに対して特に調整されたＥＣＣＤルール又はモデルのセットを発生する。ＥＣＣＤルール又はモデルは、ユーザにより特に要求される医療情報に加えて、ユーザがおそらく受信に関心のある更に別の関連医療情報を予想又は決定するためにサーバーによって使用される。次いで、関連医療情報及び要求された医療情報が種々のデータソースから検索され、そしてサーバーによりホストされるデータ統合器によって医療情報の１つ以上のビューへと統合される。医療情報のビューは、次いで、クライアント装置へ送信されてユーザに提示される。現在提示された医療情報に関するユーザ相互作用は、将来の予想又は決定に対してＥＣＣＤルール又はモデルをトレーニングし又は調整するためＥＣＣＤエンジンによって使用される。その結果、医療情報は、ユーザに最も適した又はユーザに最も望まれる仕方でユーザに提示される。ある実施形態では、そのような医療情報サーバーは、特定の患者（一人又は複数）の異なる又は関連した医療データを合体するために種々の医療データソース（例えば、医療データサーバー）に通信結合される統合型医療画像処理サーバーである。
【0015】
図１は、本発明の一実施形態により進化型コンテキスト臨床データ技術を使用する医療情報システムを示すブロック図である。図１を参照すれば、医療情報サーバー１０１は、ネットワークを経てクライアント１０２のような種々のクライアントに医療情報を与えるように構成される。ある実施形態では、医療情報サーバー１０１は、とりわけ、ＥＣＣＤエンジン１０３及びデータコレクタ又は統合器１０４を備えている。ＥＣＣＤエンジン１０３は、専用のコンピューティングマシンにおいて実施される。ある実施形態では、ＥＣＣＤエンジン１０３は、人工インテリジェンス（ＡＩ）技術を使用して実施される。
【0016】
図１に戻ると、ある実施形態では、ＥＣＣＤエンジン１０３は、ユーザの入力に基づいてビューアから情報を受信し；クライアントから受信した情報に関連した情報について複数のデータソース１０５に質問するためにデータコレクタ１０４を呼び出し；及び複数のデータソース１０５から受信したデータを統合してクライアント１０２へ送信し、ビューア、おそらく異なるディスプレイ又はビューアエリアに表示する；ことを含む多数の機能を遂行する。このプロセスを繰り返し行って、ユーザが自分のサーチを狭めたり広げたりしそして結果を見ることができるようにする。これは、繰り返し質問と称され、ＥＣＣＤエンジンにより駆動される。
【0017】
ＥＣＣＤエンジン１０３は、ユーザがどんなタイプの医療データを受信することにおそらく関心があるかを、特定のユーザ又は２人以上のユーザの以前のユーザ相互作用又は振舞いに基づきモデリングされるＥＣＣＤルール又はモデルのセットに基づいて決定する。ＥＣＣＤエンジン１０３は、データソースインターフェイス１０４（１つ又は複数）を経て、データソース１０５と通信して、ＥＣＣＤエンジン１０３からの推薦に基づいて医療データを検索する。ＥＣＣＤエンジン１０３は、多数の異なるデータソースからデータオブジェクトを採掘し、そしてそれらデータオブジェクトを、共通のメタデータ、例えば、患者ＩＤ、アクセス番号、日付、時間フレーム、ボディ部位、ボディエリア、状態、遭遇、手順、兆候、等に基づいて互いに統合する。
【0018】
ＥＣＣＤエンジン１０３は、特定のデータソースインターフェイス１０４を使用して、種々のデータソース１０５に接続する。医療データは、複数のデータソースから引っ張られ、そしてクライアント１０２、好ましくはシンクライアント、更に好ましくはウェブブラウザ、へ送信されて表示される。図１に示す例では、データソース１０５は、ＬＩＳ、ＲＩＳ、ＥＣＭ、ＥＭＲ、ＨＩＳ、ＰＡＣＳ、及びＨＩＥ（ヘルス情報交換）サーバーを含む。しかしながら、それより多数又は少数のデータソースが適用されてもよい。データソース１０５は、サーバー１０１を動作する組織とは異なる組織によって管理及び／又は運営されてもよい。
【0019】
ある実施形態では、データソース１０５により与えられる医療データは、ＤＩＣＯＭフォーマットの医療画像データ、非ＤＩＣＯＭフォーマットの医療画像データ、スケジューリングデータ、登録データ、人口統計学的データ、処方箋データ、勘定データ、保険データ、口述データ、レポートデータ、ワークフローデータ、ＥＫＧデータ、ベストプラクティスレファレンス資料、レファレンス資料、トレーニング資料、等を含む。これらデータは、ＨＩＳ、ＲＩＳ、ＰＡＣＳ、ＬＩＳ、ＥＣＭ、ＥＭＲ、又は他のシステムを含む多数の位置又はシステムに存在する。非ＤＩＣＯＭデータは、Ａ／Ｖ、ＭＰＥＧ、ＷＡＶ、ＪＰＧ、ＰＤＦ、Ｍｉｃｒｏｓｏｆｔ ＯｆｆｉｃｅTMフォーマット及び他のフォーマットを含む多数のフォーマットである。
【0020】
一般的に、ＰＡＣＳのデータは、ＤＩＣＯＭデータを含み、ＨＩＳ、ＲＩＳ、ＬＩＳ、ＥＣＭ、ＥＭＲのデータは、画像及び非画像データの両方を含めて非ＤＩＣＯＭデータを含む。ＨＩＥデータは、ヘルス情報交換システムを経て入手可能なデータを含む。これらのデータは、一般的に、領域、コミュニティ又は病院システム内の異なる組織を横切って入手可能なデータを含み、そしてＤＩＣＯＭ又は非ＤＩＣＯＭデータである。他のデータは、コンピュータのディレクトリーのデータ、移動装置からのデータ、等を含む他の関連データを含む。
【0021】
種々のシステム（例えば、ＬＩＳ、ＲＩＳ、ＥＣＭ、ＥＭＲ、ＨＩＳ、ＰＡＣＳ、等）は、ＤＩＣＯＭ、ＨＬ７（ヘルスレベルセブン）、ＸＤＳ、ＨＩＥ、ＯＲＵ、等を使用するので、ＥＣＣＤエンジン１０３は、特定のコネクタ又はデータソースインターフェイス１０４を使用して、種々のシステム１０５のデータにアクセスする。これらコネクタは、一般的に、ビューアレベルにおいてエンドユーザから隠され、ユーザは、これらの複雑さに関して心配する必要はない。しかしながら、適当なアクセスクレデンシャルを伴うあるユーザは、ビューアインターフェイスを経て、又はＥＣＣＤエンジン１０３と直接的に、又は他のインターフェイスを経てコネクタを構成することができる。データコネクタのタイプは、移動、ＥＭＲプラグインＡＰＩ（アプリケーションプログラミングインターフェイス）、ウェブサービス、ウェブブラウザアップロード／ダウンロード、ＨＬ７、ディレクトリスキャナ、ＤＬＬ（ダイナミックリンクライブラリ）ＡＰＩ、ＸＤＳ（企業間ドキュメントシェアリング）、ＶＮＡ（ベンダーニュートラルアーカイブ）、インデックスサーバー、等を含むが、これに限定されない。
【0022】
この実施形態におけるビューア又はクライアント１０２は、シンクライアント、例えば、コンピュータのウェブブラウザ、移動装置の移動装置アプリケーション、等である。ビューアは、ソフトウェア又はプラグインダウンロード／インストールを要求してもよいし又はしなくてもよい。ビューアは、種々のデータソースから収集され及びサーバー１０１から受信され統合されたデータを表示するために１つ以上のビューア／ビューエリアを有する。ビューエリアは、ウェブブラウザ内のフレーム及び／又はタブにある。ビューエリアは、互いに重畳するか又は一体化される。ビューエリアは、互いの中にあってもよい。ビューアは、２つ以上のビューエリアを有するのが好ましい。
【0023】
ＥＣＣＤエンジン１０３の質問から生じるデータは、ビューアに示されるのが好ましい。しかしながら、データは、ＥＣＣＤエンジン１０３によりエクスポートされて、データベースに合体され、別のシステムにレポートされ、それと統合され、等々である。又、繰り返し質問の結果も、ＥＣＣＤエンジン１０３に記憶されるか、エクスポートされて別のシステムに記憶されるか、又はその両方である。又、ＥＣＣＤエンジン１０３は、別のプロセスも起動し、例えば、別のソフトウェアシステムを起動するか、プリンタを起動してプリントを行うか、等々である。
【0024】
図２は、本発明の一実施形態によりクライアントの観点からＥＣＣＤエンジンがどのように動作するか示す処理フロー図である。図２を参照すれば、ブロック２０２において、ユーザは、図１のクライアント装置１０２のようなクライアント装置で実行されるクライアントソフトウェアアプリケーションによって表示されるコンテンツのリンク又はコントロール（例えば、ハイパーテキストリンク、ボタン、又は関連実行コードが下に横たわるアイコン）をクリックし、ここで、コンテンツ（例えば、医療情報）は、種々の通信プロトコルを使用して、図１の医療情報サーバー１０１により、ネットワーク（例えば、ローカルエリアネットワーク、インターネットのようなワイドエリアネットワーク、又はその組み合わせ、ワイヤード又はワイヤレス）を経て与えられる。クライアント装置を動作するユーザは、医者、技師、インストラクター、患者、又は医療情報サーバー１０１で利用できるリソースにアクセスするための適当なアクセス制御クレデンシャルを伴う他のユーザである。リンクは、画像、テキスト、ボタン、又は他のタイプのリンクである。
【0025】
クライアントソフトウェアアプリケーションは、ＥＭＲ、クライアントトライアルソフトウェア、画像ソフトウェア、進歩型画像処理ソフトウェア、又は他のタイプのソフトウェアである。クライアントソフトウェアアプリケーションは、クライアント−サーバーソフトウェア環境においてクライアントとして実行されるか、又は特定のコンピュータ又は移動又は他の装置にインストールされたソフトウェアとして実行される。クライアントソフトウェアは、ウェブブラウザである。例えば、ユーザは、医療情報サーバーのＵＲＬ（ユニフォームリソースロケータ）、並びに患者ＩＤ、アクセス番号、ボディエリア、日付、手順又はその組み合わせのような識別情報を含むＨＴＭＬ（ハイパーテキストマークアップ言語）リンク（例えば、テキスト、ボタン、画像、等）をクリックする。ユーザによるリンク又はコントロールの作動に応答してクライアント装置１０２から医療情報サーバー１０１のＥＣＣＤエンジン１０３へ埋め込まれた情報が通信される。
【0026】
ボックス２０４及び２０６は、ユーザがクライアントソフトウェアアプリケーションにおいてリンクをクリックする結果を表わす。ボックス２０４は、医療情報サーバー１０１から受信したコンテンツ情報に応答して、クライアント装置１０２においてインコンテキストで１つ以上のビューアエリアを起動することを表し、ここで、サーバー１０１のＥＣＣＤエンジン１０３は、進化型コンテキスト臨床データ技術を使用してボックス２０２においてリンクとのユーザ相互作用に基づきコンテンツ情報を発生する。この例のインコンテキストとは、ビューアエリアに表示されるデータが、ホストソフトウェアにおいてユーザがクリックしたリンクに関連し、そして少なくとも幾つかのデータが、ユーザ及び／又はメタデータに関連した１つ以上のＥＣＣＤルール又はモデルに基づきＥＣＣＤエンジン１０３により予想又は決定される（ユーザにより特に要求されないが）ことを意味する。例えば、リンクが特定の日付で行われたＣＴスキャンに関連する場合には、ビューアエリアは、関連ＣＴスキャン画像を示す。ＥＣＣＤエンジン１０３は、リンクのメタデータに基づいてコンテキストを決定する。例えば、患者ＩＤ、アクセス番号、研究ＩＤ、ログインクレデンシャル、日付、ボディ部位又はエリア、等に関連するデータがメタデータに含まれる。
【0027】
ボックス２０６は、別のビューアの起動をインコンテキストで表す。例えば、ボックス２０２のリンクが特定の日付で行われたＣＴスキャンに関連する場合には、第２のビューアエリアは、その特定のＣＴスキャンに関連したノート、レポート又は口述を示す。ＥＣＣＤエンジン１０３は、リンクのメタデータに基づいてコンテキストを決定する。例えば、患者ＩＤ、アクセス番号、研究ＩＤ、ログインクレデンシャル、日付、ボディ部位又はエリア、等に関連するデータがメタデータに含まれる。ビューアエリアに提示される情報は、ＥＣＣＤエンジン１０３が結合された全てのデータソース（例えば、図１のデータソース１０５）から引っ張られる。
【0028】
ＥＣＣＤエンジン１０３により起動されるビューアエリアは、ホストクライアントソフトウェアと同じウインドウにある。例えば、複数のビューアエリアがウェブブラウザウインドウ内の異なるフレームとして起動され、ここで、ウェブブラウザウインドウは、ホストソフトウェアをホストする。しかしながら、ビューアエリアは、１つ以上の異なるウインドウでも起動される。又、ビューアエリアは、ウインドウ内の異なるタブへと起動される。又、ビューアエリアは、重畳してもよい。又、ビューアエリアは、例えば、単一フレームにおいて２つ以上のデータソースからのデータを示すように、互いに統合されてもよい。又、ビューアエリアは、例えば、ビューアエリア１がビューアエリア２内にあるように、互いの中にあってもよい。又、ホストソフトウェアシステムウインドウがビューエリア内にあってもよい。
【0029】
ある状況において、ビューアエリアに最初に提示される情報は、ユーザにとって充分なものである。しかしながら、ユーザが異なる情報を得るために自分の質問を狭めるか又は広げることを望む場合には、ボックス２０８で表わされたステップに続く。ボックス２０８は、ビューアエリア内のリンクをユーザがクリックすることを表わす。ユーザは、ビューアエリアに提示される情報の範囲を狭めるか又は広げるためにリンクをクリックする。例えば、ユーザは、特定のデータに関連したリンクをクリックするか、又は特定の状態、等に関連したリンクをクリックする。又、ユーザは、「特定の日付に関連した全てのデータを示せ」といった特定の質問も提出する。データを表示するビューアエリアの１つ又は個別のビューアエリア内でユーザに質問オプションが提示される。
【0030】
ボックス２１０は、ユーザにより与えられる付加的な入力に基づいてＥＣＣＤエンジン１０３が種々のデータソースに質問することを示す。ボックス２１２は、より関連性のあるデータがビューアエリアに表示されることを表わす。ここから、ユーザは、ビューアエリア内の異なるリンクをクリックすることによって結果を狭めるか又は広げ続ける。この質問は、ユーザが要求した情報を見ることができるまで繰り返し行うことができる。ＥＣＣＤエンジン１０３は、ユーザ又はユーザの繰り返しの質問から、ユーザ及び／又はメタデータに関連したＥＣＣＤルール又はモデルをトレーニングすることにより関連データを将来最初に「インコンテキスト」で良好に提示することを学習することができる。
【0031】
図３は、本発明の一実施形態によりＥＣＣＤエンジンの観点からＥＣＣＤエンジンがどのように動作するか示す処理フロー図である。図３を参照すれば、ボックス３０２は、ＥＣＣＤエンジン１０３がユーザから情報を受信することを表わす。この情報は、ボックス２０２に示すように、クライアントソフトウェアアプリケーションにおいてある種のリンクをユーザがクリックすることにより搬送される。又、ＥＣＣＤエンジン１０３は、自動的に起動されてもよい（ユーザがリンクをクリックする必要なく）。例えば、ＥＣＣＤエンジン１０３は、新たな患者に関連したデータを示すために毎朝ユーザに対して自動的に起動されてもよい。ＥＣＣＤエンジン１０３の起動は、インテリジェントな仕方で又は「インコンテキスト」で複数のデータソースの統合及び表示を生み出す。
【0032】
ボックス３０３は、ボックス３０２においてユーザ選択から情報を受信する結果としてＥＣＣＤエンジン１０３がとるアクションを表わす。ＥＣＣＤエンジン１０３は、種々のデータソース（例えば、図１のデータソース１０５）に質問して、ユーザ選択に最も関連したデータを見出す。ボックス３０４は、データに適用されるデータフィルタを表わす。例えば、ユーザは、あるタイプのデータのみ、例えば、画像のみ、又はある時間フレームに関連したデータのみを提示するようにあるフィルタを構成する。ＥＣＣＤエンジン１０３は、過去のユーザの振舞いにより「学習された」もののようなそれ自身のフィルタを有する。例えば、ＥＣＣＤエンジン１０３は、特定のユーザが通常胸部エリアのＣＴスキャンデータの次にＥＫＧデータを見るのを希望することを学習する。そのような「学習された」情報は、将来使用するための更新されたＥＣＣＤルール又はモデルへとコンパイルされる。このケースでは、ユーザが、胸部のＣＴスキャンを指示するホストソフトウェアパッケージのリンクをクリックした場合に、ＥＣＣＤエンジン１０３は、ＥＣＣＤルール又はモデルに基づいて、このユーザにＥＫＧデータを提示することも知る。
【0033】
ボックス３０５は、ＥＣＣＤエンジン１０３による別のデータソース質問を表わす。この付加的な質問は、ユーザがシステムの複数の質問レベルを自動的遂行のために構成した場合だけ行われる。例えば、これらの繰り返しは、図４に示すようにスクリーンにおいて構成される。この付加的な自動的質問は、ＥＣＣＤエンジン１０３が繰り返し質問を実行できる１つの方法である。又、ユーザは、ブロック３０８−３１２にも示されたが、ブロック２０８−２１２を経て、繰り返し質問を手動で行ってもよい。
【0034】
ブロック３０６は、ＥＣＣＤエンジン１０３がインコンテキストでビューアエリアを起動することを表わす。この例のインコンテキストは、ビューアエリアに表示されるデータが、ホストソフトウェアにおいてユーザがクリックしたリンクに関連していることを意味する。例えば、リンクが、特定の日付で行われたＣＴスキャンに関連する場合に、画像ビューアエリアは、関連ＣＴスキャン画像を示す。ＥＣＣＤエンジン１０３は、リンクのメタデータに基づいてコンテキストを決定することができる。例えば、患者ＩＤ、アクセス番号、研究ＩＤ、ログインクレデンシャル、日付、時間フレーム、エピソード、約束、ボディ部位又はエリア、ユーザ、研究、保険コード、医療トライアル、等に関連したデータがメタデータに含まれる。
【0035】
ボックス３０７は、ＥＣＣＤエンジン１０３がインコンテキストで別のビューアエリアを起動することを表わす。例えば、リンクが特定の日付で行われたＣＴスキャンに関連する場合に、第２のビューアエリアは、その特定のＣＴスキャンに関連したノート、レポート又は口述を表示する。ＥＣＣＤエンジンは、リンクのメタデータに基づいてコンテキストを決定する。例えば、患者ＩＤ、アクセス番号、研究ＩＤ、ログインクレデンシャル、日付、ボディ部位又はエリア、等に関連するデータがメタデータに含まれる。第２のビューアエリアに提示される情報は、ＥＣＣＤエンジン１０３が結合される全てのデータソースから引っ張られる。
【0036】
ユーザがこの点において必要な情報を有しそして異なる／より多くの情報を得る必要がない場合には、ワークフローがここで停止する。ユーザが自分の質問を変更しそして異なる情報を見たい場合には、ワークフローがボックス３０８へと続く。ボックス３０８は、ボックス２０８に示されたようにビューアエリアの１つにおいてユーザによりクリックされたリンクに関連する情報をＥＣＣＤエンジン１０３が受信することを表わす。この情報を受信するのに応答して、ＥＣＣＤエンジンは、新たな質問に埋め込まれた情報を使用して、それが接続された種々のデータソースからのデータの別の質問を実行し（ボックス３１０）、そして狭くされるか又は広げられた情報をビューアエリアに表示する（ボックス３１２）。「インコンテキスト」の構成は、適切なアクセスクレデンシャルをもつユーザにより行うことができる。この構成は、ビューアクライアントインターフェイス、異なるクライアントインターフェイスを経て、又はＥＣＣＤエンジンサーバーにおいて直接的に、遂行される。
【0037】
図４は、本発明の幾つかの実施形態によりＥＣＣＤエンジンとクライアント／ビューアユーザインターフェイスとの間の相互作用を示す。図示されたステップは、ＥＣＣＤエンジン１０３により提示される情報を見てそれと相互作用するためにユーザがとるステップを例示のための実施例として表わすに過ぎない。図４には、ＥＣＣＤエンジン１０３のアクティビティも示されている。図４を参照すれば、ステップ１は、ビューア又はクライアントスクリーンにおいてホストソフトウェア（例えば、クライアントソフトウェア）を示す。ホストソフトウェア内には、選択又はクリックされたときに、ＥＣＣＤエンジン１０３と通信し、そして患者ＩＤ、アクセス番号、研究ＩＤ、ログインクレデンシャル、日付、ボディ部位又はエリア、等の情報をＥＣＣＤエンジン１０３に送信するリンクが存在する。ステップ１は、リンクを選択するポインタと、ＥＣＣＤエンジン１０３へ転送されるリンクからの情報（この図では「ＥＥ」とも称される）とを示している。又、図示されたように、ＥＣＣＤエンジン１０３は、上述したように、ＨＩＥ、非構造化データ（この図では「ＵＥ」）、及びおそらく他のデータを含めて、種々のデータソースに接続される。
【0038】
ステップ２は、ＥＣＣＤエンジン１０３がユーザから入力を受信した後に何が起きるかを示している。ＥＣＣＤエンジン１０３は、ユーザによりＥＣＣＤエンジン１０３へ送信された情報に関連するデータを見出しそして検索するために種々のデータソースに質問する。例えば、ユーザは、患者ＩＤ及び日付を含む情報をＥＣＣＤエンジン１０３へ搬送したリンクをクリックする。ＥＣＣＤエンジン１０３は、その患者ＩＤ及びその日付に関連した情報について全ての関連データソースに質問し、そしてこの情報をビューアへ転送して戻す。情報のフォーマットに基づいて、ビューアは、ＤＩＣＯＭビューエリア及び非ＤＩＣＯＭビューエリアのような異なるビューエリアを起動する。ビューエリアは、ＤＩＣＯＭ画像、非ＤＩＣＯＭ画像、テキスト、レポート、ＰＤＦ、ＪＰＥＧ、オーディオファイル、ビデオファイル、オフィスドキュメント（マイクロソフト、等）を含む多数の異なるフォーマットのデータを受け容れることができる。好ましくは、関連情報を示すために少なくとも２つのビューエリアが起動されるが、それより多くのビューエリアが起動されてもよい。ビューエリアは、ホストビューア内で、フレームにおいて、タブとして、個別のウインドウとして、個別のフレームとして、等々でショーアップされる。ビューエリアは、互いに他の上で、個別のウインドウ又はポップアップウインドウにおいて、浮動してもよい。ビューエリアは、個別のモニタ上にあってもよい。又、ビューエリアは、ここに述べる同じフォーマットのいずれかにおいてホストアプリケーション及び／又は他のソフトウェアアプリケーションと一体化されてもよい。又、ビューエリアは、２つ以上のソフトウェアアプリケーションへと同時に一体化されてもよい。
【0039】
ステップ３は、ユーザがポインタ（キーストローク、双方向ボイスコマンド又はその組み合わせ）を使用して１つのビューエリア内でリンクをクリックすることを示している。この場合も、このリンクをクリックすると、特定の情報又は要求がＥＣＣＤエンジン１０３へ送信される。例えば、ＤＩＣＯＭ画像ビューアエリアに示される多数のＣＴスキャンがあり、そして別のビューエリアに表示される情報は、それら多数のＣＴスキャンに関連している。ユーザは、データを、１つのＣＴスキャンのみに関連したものへと狭める。単一のスキャン日付をクリックすることにより、ユーザは、この日付情報（及び他の情報）をＥＣＣＤエンジン１０３へ搬送する。
【0040】
ステップ４は、ＥＣＣＤエンジンが再びユーザによって搬送される新たな要求に関連した情報について種々のデータソースに質問することを示している。質問の結果として、ＥＣＣＤエンジン１０３は、異なる情報をクライアント装置へ送信して、ビューアの少なくとも１つのビューアエリアに表示させる。ステップ５は、ユーザが再び１つのビューアエリアにおいてリンクをクリックして、表示される情報を狭めるか又は広げることを示している。ステップ６は、ＥＣＣＤエンジン１０３が第３のビューエリアを起動することを示している。第３のビューエリアは、ここでは、他の２つのビューエリアと同じウインドウにおいて並置して示されているが、ビューエリアは、タブ、個別のウインドウに、重畳、一体化、等で示されてもよい。少なくとも幾つかのビューエリアに表示された情報は、ユーザがより多くの情報をＥＣＣＤエンジン１０３へ提出するにつれて変化することに注意されたい。この例では、第３のビューエリアが示されているが、ステップ２−５に示された２つのビューエリアの一方に新たな情報が起動されてもよい。
【0041】
図４は、種々のビューエリア内のユーザ相互作用に基づく繰り返しプロセスを示す。ＥＣＣＤエンジンは、ユーザの習慣から及び一般的に複数のユーザの習慣から学習することが明らかである。ユーザのクリック及び好みは、種々のデータオブジェクトのメタデータに追加され及び／又はＥＣＣＤエンジンそれ自体のロジック／ルールに追加されるデータを生成する。ＥＣＣＤエンジン１０３は、次いで、この情報を使用して、例えば、ユーザに関連した対応するＥＣＣＤルール又はモデルをトレーニングすることにより、インコンテキストでデータを良好に提示することができる。その結果、ＥＣＣＤエンジン１０３は、時間と共に少数の「クリック」でユーザに情報を提示することができる。
【0042】
図５は、本発明の一実施形態による医療情報システムを示すブロック図である。例えば、システム５００は、サーバー１０１の少なくとも幾つかのコンポーネント、例えば、ＥＣＣＤエンジン５０１及びＥＣＣＤルール／モデル５０２がＥＣＣＤエンジン１０３の一部分として実施されるような図１に示すシステムを表わす。図５を参照すれば、システム５００は、ネットワーク５０６を経て医療情報サーバー１０１に通信結合される１つ以上のクライアント１０２Ａ−１０２Ｂを備えているが、これに限定されない。ネットワーク５０６は、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、インターネット又はイントラネットのようなワイドエリアネットワーク（ＷＡＮ）、プライベートクラウドネットワーク、パブリッククラウドネットワーク、又はその組み合わせである。
【0043】
ある実施形態では、医療情報サーバー１０１は、とりわけ、ＥＣＣＤエンジン５０１、ＥＣＣＤモデル／ルール５０２、ユーザデータベース５０３、ユーザデータコレクタ５０４、医療データ統合器５０５、及び医療画像処理システム５１０をホストする。ＥＣＣＤエンジン５０１は、モデルに利用可能な種々の技術を使用して実施され、そしてユーザデータベース５０３に記憶された特定ユーザのユーザ相互作用、振舞い、及び／又はユーザ好みに基づいてＥＣＣＤルール又はモデル５０２を生成する。ユーザ相互作用は、クライアント１０２Ａ−１０２Ｂにおいてクライアントソフトウェアアプリケーション５０７−５０８のユーザ相互作用を監視するユーザデータコレクタ５０４によって監視され捕獲される。捕獲されたユーザ相互作用は、次いで、ユーザデータベース５０３に記憶されそしてＥＣＣＤエンジン５０１により分析されて、ＥＣＣＤルール又はモデル５０２を生成する。
【0044】
ある実施形態によれば、クライアントのユーザ、この例では、クライアント１０２Ａのユーザが、クライアントソフトウェア５０７（例えば、クライアントアプリケーション、ウェブブラウザ）に提示されるコンテンツ（例えば、患者又は医療データ５１１、医療画像５１３）と相互作用するときに、ユーザ相互作用（例えば、クリック、キーストローク、ボイスコマンド）を表わす信号又はメッセージがクライアントアプリケーション５０７により医療情報サーバー１０１へ送信される。そのメッセージは、ユーザが相互作用した特定のコンテンツ、及び他のメタデータ（例えば、患者ＩＤ、ボディエリア、医療手順ＩＤ、医療約束、医療状態、ユーザＩＤ、相互作用の日時、等）を含む。クライアント１０２Ａから受信したメッセージに基づいて、データ統合器５０５は、ＥＣＣＤエンジン５０１及び／又はＥＣＣＤルール／モデル５０２を呼び出して、医療データのセットを決定する。ＥＣＣＤルール／モデル５０２は、クライアントソフトウェア５０７及び／又はメタデータを動作するユーザのユーザＩＤに基づいて識別される。決定されたデータセットに基づいて、データ統合器５０５は、そのようなデータを与えることのできるデータソース１０５Ａ−１０５Ｃの幾つかを識別する。データ統合器５０５は、識別されたデータソース１０５Ａ−１０５Ｃと通信して、ＥＣＣＤエンジン５０１及び／又はＥＣＣＤルール／モデル５０２により決定又は推薦された医療データを検索する。
【0045】
データ統合器５０５は、検索された医療データを医療情報の１つ以上のビューへと統合する。ある実施形態では、データ統合器５０５は、例えば、ユーザに関連したＥＣＣＤルール／モデル５０２に基づいて、ユーザに最も適した仕方で医療データを統合する。次いで、医療情報の１つ以上のビューが医療情報サーバー１０１からネットワーク５０６を経てクライアント１０２Ａへ送信され、そしてクライアントソフトウェアアプリケーション５０７により医療データ５１１及び／又は医療画像５１３の一部分としてユーザに提示される。提示される医療情報は、ユーザが以前に提示されたコンテンツと相互作用するときにユーザにより要求された医療情報を含む。加えて、医療情報は、ユーザにより特に要求されないが、ＥＣＣＤルール／モデル５０２に基づきＥＣＣＤエンジン５０１により推薦された情報を更に含む。例えば、ユーザがＣＴスキャンに関する情報を要求するとき、ユーザに関連したＥＣＣＤルール又はモデルに基づき、ＥＣＣＤエンジンは、例えば、ＣＴスキャンのメタデータに関連したＥＣＣＤルールの別のセットに基づいて、その１つ以上のラボテストを推薦するか、又はＣＴスキャンに関連したＥＫＧもユーザに提示される。しかしながら、ユーザは、ラボテストもＥＫＧも特に要求しないが、ＥＣＣＤルール又はモデルに基づき、ユーザは、おそらく、ＣＴスキャン情報を見たときにラボテスト又はＥＫＧを受け取ることに関心があるであろう。
【0046】
医療画像５１３は、医療情報サーバー１０１内に一体化されるか又はリモート位置では個別サーバー又はサーバークラスターによりホストされる画像処理システム５２０の一部分として一体化される画像処理システム５１０によりレンダリングされ又は生成される。種々のデータソース１０５Ａ−１０５Ｃは、同じ又は異なる組織で運営される１つ以上のサーバーによりホストされる。ある実施形態では、データソース１０５Ａ−１０５Ｃは、ＬＩＳ、ＲＩＳ、ＥＣＭ、ＥＭＲ、ＨＩＳ、ＰＡＣＳ及びＨＩＥサーバーを含む。データ統合器５０５は、データソース１０５Ａ−１０５Ｃと通信し、例えば、ＤＩＣＯＭ、ＨＬ７、ＸＤＳ、ＨＩＥ、ＯＲＵ、等の種々の通信方法又はプロトコルを使用して医療データを検索する。
【0047】
図６は、本発明の一実施形態により医療情報を処理するための進化型コンテキスト臨床データエンジンを示すブロック図である。図６を参照すれば、システム６００は、図５の医療情報サーバー１０１の一部分として実施される。ある実施形態では、ＥＣＣＤエンジン５０１は、ユーザ振舞い分析器６０１、ルールエンジン６０２、及びＥＣＣＤエンジン６０２により生成されるＥＣＣＤルール又はモデルを含むが、これに限定されない。ある実施形態では、ユーザ振舞い分析器６０１は、ユーザのユーザ相互作用データを分析して、患者の異なる医療情報にアクセスすることに関するユーザ振舞いパターンを決定する。例えば、ユーザ振舞い分析器６０１は、異なるユーザのユーザデータベース５０３Ａ−５０３Ｂにアクセスし、対応ユーザのユーザ相互作用ヒストリー６２１−６２２を分析して、それらの各振舞いパターンを決定する。ユーザ相互作用ヒストリー６２１−６２２は、図５のユーザデータコレクタ５０４により収集され、そしてハードドライブのような持続性ストレージ装置の１つ以上のデータベースにおいて実施されるユーザデータベース５０３Ａ−５０３Ｂに記憶される。ユーザ振舞いパターンは、上述したように、種々のアルゴリズム又は技術６０４を使用して決定され又はモデリングされる。ユーザ振舞いパターンは、個々のユーザに対して使用されるか又は２人以上のユーザにわたって総計される。
【0048】
ユーザ振舞い分析器６０１により決定されたユーザ振舞いパターンに基づいて、ルールエンジン６０２は、各ユーザに対して各振舞い及び個人的好み（例えば、ユーザ好み６１１−６１２）に基づいてＥＣＣＤルール又はモデル６０３をコンパイルし及び生成する。ＥＣＣＤルール及び／又はモデルは、次いで、対応するユーザデータベースにＥＣＣＤルール／モデル６３１−６３２の一部分として記憶されるか、或いは又、ＥＣＣＤエンジン５０１によりＥＣＣＤルール／モデル６０３の一部分として集中的に維持される。それに続いて、ある医療データにアクセスするための新たなユーザアクション６３５が受け取られたとき、データ統合器５０５は、ＥＣＣＤエンジン５０１を呼び出して、ユーザに対応するＥＣＣＤルール／モデル６０３及び／又はＥＣＣＤルール／モデル６３１−６３２にアクセスし、付加的な医療データを決定する。次いで、データ統合器５０５は、関連データソース１０５と通信して、要求された医療データ（例えば、第１の医療データ）及び付加的な医療データ（例えば、第２の医療データ）を検索する。検索された医療データは、次いで、データ統合器５０５によって統合されて、医療情報６３６の１つ以上のビューを生成する。医療情報６３６の１つ以上のビューは、次いで、ユーザのクライアント装置へ送信されて、そこに提示される。
【0049】
更に、ユーザアクション６３５は、ユーザ相互作用ヒストリー（例えば、ユーザ相互作用ヒストリー６２１−６２２）の一部分として捕獲されそして持続性装置に記憶される。更新されたユーザ相互作用ヒストリーは、将来の使用に対して対応するＥＣＣＤルール又はモデルをトレーニング又は調整するためにＥＣＣＤエンジン５０１により使用され又は「学習」される。例えば、ユーザが脳のスキャンを見るときにＥＫＧデータを滅多に要求しないか又は決して要求しない場合には、ＥＣＣＤエンジン５０１は、対応するＥＣＣＤルール又はモデルを構成することにより、ユーザが脳のスキャンを見るときにＥＫＧデータを提示しないように学習する。この状況では、ユーザは、ＥＫＧ情報を見ることを希望する場合にそれを見るために特定の質問をする必要があり、そしてそのようなユーザアクションは、そのＥＣＣＤルール又はモデルの更なる変更をトリガーする。
【0050】
別の例では、過去のユーザの振舞いに基づいて、ユーザは、心臓専門医として、胸部エリアのＣＴスキャンを見るときに患者のＥＫＧを表わす画像を見ることを常に望むことがある。ユーザがこの要求を一回以上なすと、ＥＣＣＤエンジン５０１は、このユーザがそれらの画像を同時に見ることをしばしば希望することを学習し、そしてＥＣＣＤエンジン５０１は、ユーザが胸部エリアのＣＴスキャンを見ることをその後に要求したときにＥＫＧデータを提示するようにＥＣＣＤルール／モデルを変更する。多数の他のユーザも胸部エリアのＣＴスキャンを見る間にＥＫＧデータをしばしば要求する場合には、ＥＣＣＤエンジン５０１は、このデータを解釈し、そして全てのユーザ又は全てのユーザのサブセット、例えば、心臓専門医に対して胸部ＣＴスキャンデータが要求されたときにＥＫＧデータを提示する見込みを高める。このように、ＥＣＣＤエンジン５０１は、異なるユーザ又は異なるタイプのユーザ又は全てのユーザに対して「インコンテキスト」が何を意味するか「学習」することができる。
【0051】
ＥＣＣＤエンジン５０１がそのユーザから学習する別の仕方は、クリックスルーレート及びビュータイム（例えば、図５のユーザデータコレクタ５０４により監視される）を追跡し、そしてＥＣＣＤエンジン５０１内のこの情報を、ユーザ、研究のタイプ、個々の研究、情報のタイプ、表示される他の情報、等に結びつけることである。短いクリックスルーレート及び／又は短いビュータイムは、関連情報が少ないことを示し、一方、長いクリックスルーレート及び／又は長いビュータイムは、関連情報が多いことを示す。時間と共に収集されたこの情報を使用して、ＥＣＣＤエンジン５０１は、それが提示するコンテンツを洗練化することにより、使用されるにつれてインテリジェンスが更に成長する。例えば、ユーザ（１人又は複数）は、３ヶ月以上古いラボデータは数秒間しか見ないが、より新しいラボデータはもっと長く見て、古い情報があまり重要でないことを示す。この情報を使用して、ＥＣＣＤエンジン５０１は、この例では、３ヶ月以上古いラボデータをユーザ（１人又は複数）に提示するおそれを低くする。
【0052】
ＥＣＣＤエンジン５０１がユーザからどのように学習するかの別の例は、全解釈時間を追跡することである。全解釈時間とは、複数の関連画像又は情報オブジェクトを見る時間であり、及び／又はある進歩型画像処理ステップを遂行する時間であり、及び／又は１人の患者に関連する情報を検討する全時間である。この情報は、ＥＣＣＤエンジン５０１により分析されて、読み取り時間のトレンドを決定する。この情報は、最終的に、全読み取り時間を短縮するのに使用できる。例えば、ＥＣＣＤエンジン５０１が、検討プロセスの一部分がＣＴスキャンそれ自体を見ることを含むとき医師が特定の患者の検討に３０分を費やすが、以前のＣＴスキャンの次にＣＴスキャンが提示されたときは患者の検討に１０分しか費やさないと決定した場合には、システムは、ユーザがＣＴスキャンを選択して見るときに古いＣＴスキャン又は新しいＣＴスキャンを表示する見込みを高くする。
【0053】
ＥＣＣＤエンジン５０１がユーザからどのように学習するかの別の例は、ユーザフィードバックを直接的に要求することである。例えば、ＥＣＣＤエンジン５０１は、あるデータオブジェクトを表示することが有用であるか否かを尋ねる。この情報を収集して分析することにより、ＥＣＣＤエンジン５０１は、どんなデータオブジェクトの関連性が高いか低いかをより迅速に学習することができる。又、ＥＣＣＤエンジン５０１は、所与の時間に表示するデータオブジェクトの組み合わせも分かり、そしてその知識を分析に組み入れる。例えば、ユーザが、ＥＫＧそれ自体が表示されるか又は大腸内視鏡検査に関連して表示されるときにそれがあまり有用でないことを示すが、心臓のＣＴスキャンと共に表示されるときにはＥＫＧが非常に有用であることを示す場合に、ＥＣＣＤエンジン５０１は、心臓のＣＴスキャンを見ているときにはＥＫＧをより頻繁に表示し、さもなければ、あまり頻繁に表示しないことを学習する。前記の例は、ＥＣＣＤルール／モデル６０３及び６３１−６３２により表わされる幾つかの考えられる状況に過ぎない。他の可能性も適用できる。
【0054】
図７は、本発明の一実施形態による医療情報サーバーのデータコレクタの一例を示すブロック図である。図７を参照すれば、データ統合器５０５は、データ検索モジュール７０１、ビュージェネレータ７０２、ユーザアクション分析モジュール７０３、及び医療データインターフェイス（Ｉ／Ｆ）モジュール７０４Ａ−７０４Ｃを備えているが、これに限定されない。ある実施形態によれば、ユーザがクライアント装置１０２により提示された医療コンテンツと相互作用するときに、クライアント装置１０２からネットワークを経て医療情報サーバー１０１へ信号又はメッセージが送信され、そしてそのような信号又はメッセージは、ユーザアクション分析モジュール７０３により受信される。受信されたメッセージは、ユーザがどんなコンテンツアイテムと相互作用するか指示する幾つかのメタデータと、他の識別情報（例えば、ユーザＩＤ、患者ＩＤ、医療手順ＩＤ、ボディエリア又はボディ部位ＩＤ、相互作用の日付及び／又は時刻、医療状態ＩＤ、医療約束ＩＤ、等）とを含む。ユーザアクション分析モジュール７０３は、メッセージから情報を抽出し、そしてその抽出した情報で分析を行う。
【0055】
ある実施形態では、その分析に基づいて、ユーザアクション分析モジュール７０３は、分析結果の情報及び／又はメッセージから抽出されたメタデータを与えることによりＥＣＣＤエンジン５０１を呼び出す。それに応答して、ＥＣＣＤエンジン５０１は、クライアント装置１０２のユーザに関連したＥＣＣＤルール／モデル６０３からのＥＣＣＤルール又はモデルのセットを、例えば、ユーザのユーザＩＤに基づいて識別する。ＥＣＣＤエンジン５０１は、次いで、ユーザに関連した対応するＥＣＣＤルール又はモデルを使用してユーザアクション分析モジュール７０３により与えられた入力に基づき１つ以上のアクション又は推薦のセットを導出する。その推薦は、ユーザにより要求された医療データに関連したある付加的な医療データを含み、その付加的な医療データは、ユーザが、おそらく、要求した医療データ及び／又はクライアント装置１０２から受け取られたメッセージから抽出されたユーザアクションに鑑み、受け取りに関心があるとＥＣＣＤエンジン５０１により想像され又は予想されるものである。
【0056】
ユーザによって最初に要求される第１の医療データ及びＥＣＣＤエンジン５０１により付加的に推薦される第２の医療データに基づき、データ検索モジュール７０１は、そのような医療データを与える１つ以上のデータソース１０５Ａ−１０５Ｃを識別する。例えば、データ検索モジュール７０１は、ユーザにより要求され及びＥＣＣＤエンジン５０１により推薦される異なる医療データに対する識別子を決定する。データ検索モジュール７０１は、医療データ識別子を対応データソースへとマップするデータベース又はデータ構造体を維持し及び／又はそこにアクセスする。識別されたデータソースに基づいて、データ検索モジュール７０１は、それに対応する医療データインターフェイスモジュール７０４Ａ−７０４Ｃを呼び出し又はコールし、これらモジュールは、次いで、データソース１０５Ａ−１０５Ｃに各々アクセスする。
【0057】
医療データインターフェイスモジュール７０４Ａ−７０４Ｃは、データソース１０５Ａ−１０５Ｃの特定の１つとの通信を取り扱うように特に設計されたインターフェイスロジック（ソフトウェア、ハードウェア、又はその両方の組み合わせ）を含む。データインターフェイスモジュール７０４Ａ−７０４Ｃの各々は、特定の通信プロトコル（例えば、ＴＣＰ／ＩＰ、ＤＩＣＯＭ、ＨＬ７、ＸＤＳ、ＨＩＥ、ＯＲＵ、等）、又は対応するデータソースと適合し又はそれにより確認されるアプリケーションプログラミングインターフェイス（ＡＰＩ）を使用して、データソース１０５Ａ−１０５Ｃの対応する１つ以上と通信するように特に構成された機能を含む。これは、適切なプロトコルシグナリング又はコールコンベンション、ハンドシェーク、データ交換、及び関連認証クレデンシャルを使用した異なるユーザの認証を含む。
【0058】
ある実施形態によれば、データインターフェイスモジュール７０４Ａ−７０４Ｃは、データソース１０５Ａ−１０５Ｃから受け取った医療データ（例えば、ローデータ）を、データ検索モジュール７０１に共通であるか又はそれによって予想されるフォーマットへと再フォーマットするか、或いは又、データ検索モジュール７０１が再フォーマット動作を取り扱う。ある実施形態では、データインターフェイスモジュール７０４Ａ−７０４Ｃの各々は、それに対応するデータソースのためのプラグインインターフェイスモジュールを備えている。データインターフェイスモジュール７０４Ａ−７０４Ｃは、異なるタイプのデータ、例えば、ＤＩＣＯＭ画像、非ＤＩＣＯＭ画像、テキスト、レポート、ＰＤＦドキュメント、ＪＰＥＧファイル、オーディオファイル、ビデオファイル、オフィスドキュメント、及び他のデータオブジェクトを取り扱う。データソース１０５Ａ−１０５Ｃは、ＬＩＳ、ＲＩＳ、ＥＣＭ、ＥＭＲ、ＨＩＳ、ＰＡＣＳ、及び／又はＨＩＥサーバーを含む種々のサーバー又はサーバークラスターによりホストされる。
【0059】
データ検索モジュール７０１によりデータソース１０５Ａ−１０５Ｃから医療データが検索されると、医療データは、ビュージェネレータ７０２により統合されて、医療情報の１つ以上のビューを生成する。医療情報の１つ以上のビューは、ユーザの好みに基づいてユーザが好むレイアウトに従って配列される。或いは又、医療情報のビューは、ＥＣＣＤルール又はモデル６０３に基づきＥＣＣＤエンジン５０１により推薦されるように及び／又は更にユーザの好みに鑑みフォーマットされる。例えば、あまり頻繁に使用されない画像処理ツールは、ユーザに提示されないか、又は他のより頻繁に使用される画像処理ツール、等に対して低いプライオリティで提示される。次いで、医療情報の１つ以上のビューがクライアント装置１０２へ送信されて、そこに提示される。ユーザが更に医療情報と相互作用する場合には、ユーザ相互作用が再び捕獲されてデータ統合器５０５へ送信され、そして前記プロセスが繰り返し遂行される。
【0060】
図８は、本発明の一実施形態により進化型コンテキスト臨床データ技術を使用して医療データを処理するためのプロセスを示すフローチャートである。プロセス８００は、ソフトウェア、ハードウェア、又はその組み合わせを含む処理ロジックにより遂行される。例えば、プロセス８００は、医療情報サーバー１０１により遂行され、特に、プロセス８００は、データ統合器５０５により遂行される。図８を参照すれば、ブロック８０１において、処理ロジックは、ユーザのクライアント装置に表示される医療情報（例えば、第１の医療情報）に関してユーザ相互作用を提示する信号又はメッセージを受信する。ブロック８０２において、処理ロジックは、ユーザに関連したＥＣＣＤルール又はモデルのセットに基づいてＥＣＣＤエンジンを呼び出し、ユーザにより要求された医療データに加えて、ユーザがおそらく受け取るのに関心のある医療データを決定する。ＥＣＣＤルール又はモデルは、以前のユーザ相互作用又はユーザの振舞いに基づきＥＣＣＤエンジンにより生成される。ＥＣＣＤルール又はモデルは、最近のユーザ相互作用に基づき周期的にトレーニング又は調整される。
【0061】
ブロック８０３において、ユーザにより要求された及びＥＣＣＤエンジンにより決定された医療データに基づいて、医療データに対応するデータソースが識別され、そしてそれにアクセスして、医療データを検索する。ブロック８０４において、検索された医療データは、医療情報（例えば、第２の医療情報）の１つ以上のビューへ統合される。ブロック８０５において、医療情報のビューは、次いで、クライアント装置へ送信されて、ユーザに提示される。ユーザが更に医療情報のビューと相互作用すると、ユーザ相互作用がサーバーにより再び捕獲されて受信され、そして前記プロセスが繰り返し遂行される。
【0062】
図９は、本発明の一実施形態により進化型コンテキスト臨床データ技術を使用して医療データを処理するためのプロセスを示すフローチャートである。プロセス９００は、ソフトウェア、ハードウェア、又はその組み合わせを含む処理ロジックにより遂行される。例えば、プロセス９００は、医療情報サーバー１０１により遂行され、特に、プロセス９００は、ＥＣＣＤエンジン５０１により遂行される。図９を参照すれば、ブロック９０１において、処理ロジックは、ユーザに提示される種々の医療情報に関してユーザのユーザ相互作用を監視しそして収集する。ブロック９０２において、ユーザ相互作用は、進化型コンテキスト臨床データ技術を使用して分析され、異なるタイプの医療情報に応答してユーザ振舞いパターンを決定する。ブロック９０３において、ユーザ振舞いパターンに基づき１つ以上のＥＣＣＤルール又はモデルが生成される。その後、ブロック９０４において、ＥＣＣＤルール又はモデルを使用して、ユーザがおそらく受け取りに関心のある将来の医療情報を予想する。新たに受け取られたユーザ相互作用を捕獲しそしてそれを使用して、ＥＣＣＤルール又はモデルをトレーニング又は調整する。図９は、１人のユーザの振舞いパターンに基づくルール又はモデルを示しているが、２人以上のユーザの振舞いパターンを使用して、又は換言すれば、総計ユーザアクティビティに基づいて、ルール又はモデルが形成されてもよいことが明らかである。
【0063】
図１０Ａ−１０Ｆは、本発明の幾つかの実施形態により医療情報を与えるためのグラフィックユーザインターフェイスの実施例を示すスクリーンショットである。図１０Ａ−１０Ｆに示すＧＵＩは、医療情報サーバー１０１（例えば、ビュージェネレータ７０２）によって生成され、そしてクライアント装置（例えば、クライアント装置１０２）で実行されるクライアントアプリケーション（例えば、ウェブブラウザのようなビューアプログラム）により受信されて提示される。ＧＵＩにより提示される表示されたコンテンツとのユーザ相互作用は、クライアント装置により捕獲されて、そこから医療情報サーバー１０１へ送信される。次いで、ユーザ相互作用は、例えば、ＥＣＣＤエンジン５０１と、クライアント装置を動作するユーザに関連したＥＣＣＤルール又はモデルのセットを呼び出すことにより、医療情報サーバー１０１により解釈される。ユーザ相互作用に応答して、医療情報サーバー１０１は、適当なアクション、例えば、画像処理動作、情報検索動作、及びデータ処理及び／又は統合動作を、ＥＣＣＤエンジン５０１の判断又は推薦に基づいて、遂行する。医療情報の１つ以上のビューは、医療情報サーバー１０１により生成されて、そこからクライアント装置へ返送される。処理結果は、クライアント装置のディスプレイ装置に提示され及び／又は既存の情報と統合される。
【0064】
図１０Ａを参照すれば、この例では、ＧＵＩは、複数のビューエリアを伴う考えられるビューア構成を表わす。この例では、ビューアは、ウェブブラウザであり、そしてビューエリアは、フレーム、タブ又はその両方である。ある実施形態では、図１０Ａに示すＧＵＩページは、複数のビューエリア、この例では、ビューエリア１００１及びビューエリア１００２を含む。ビューエリア１００２は、ＤＩＣＯＭビューエリアであり、ビューエリア１００１は、この例では、「画像」タブ、「情報(info)」タブ、「構成(config)」タブ、及び「セットアップ」タブを含む複数のタブにおける非ＤＩＣＯＭを示す。ビューエリア１００１−１００２におけるＤＩＣＯＭ及び非ＤＩＣＯＭデータは、上述したように、ＥＣＣＤエンジンにより与えられる。この例では、ビューエリア１００１の「情報(info)」タブが選択され、特定の患者の人口統計学的、約束、医療ヒストリー及びディクテーションデータを示す。患者ＩＤ又は名前も表示される。
【0065】
ある実施形態では、ＤＩＣＯＭビューエリア１００２は、多数の画像、この例では、１つ以上の画像シリーズ１００５からの画像１００３及び画像１００４と、多数の画像処理ツール１００６及びビューオプション１００７とを含む。画像処理ツールの利用性及び／又は順序又はプライオリティは、上述したように、ＥＣＣＤエンジンにより決定される。又、この患者に対する他のＣＴスキャンシリーズ日付１００８を示す小さなスクロールウインドウや、接近して見るための拡大画像を表示する１つ以上の表示スペースもある。ユーザが低解像度画像又はサムネール１００５の１つ以上を選択すると、それに対応する拡大画像がビューエリア１００２に表示される。この例では、ユーザがサムネール１００５から２つのサムネールを選択し、そしてそれらがビューエリア１００２の表示エリア１００３−１００４に表示されると仮定する。複数のビューアエリアは、互いに関連し、又は「インコンテキスト(in context)」である。例えば、表示される全ての情報は、心臓発作のような特定患者の事象に関連するか、或いは表示される情報は、特定時間フレーム中の特定の患者又は特定の約束に関連する。そのような情報は、上述したように、ＥＣＣＤエンジンにより決定され及び／又は推薦される。
【0066】
利用可能なツール１００６は、進歩型画像処理ツールであり、そのリストが本書の末尾に含まれている。ツールの表示は、ＥＣＣＤエンジンにより、ビューエリアに表示される画像に関連したツールのみに限定される。例えば、画像が結腸を表わす場合は、ＥＣＣＤエンジンは、バーチャルの大腸内視鏡検査及び／又は他の関連ツールしかこのビューエリアに表示できない。ユーザは、ビューアエリアのリンクをクリックして、ＥＣＣＤエンジンが表示する情報を変更する。例えば、ユーザは、約束の日付又はビューエリア１００１の医療エリアをクリックするか、又はユーザは、画像、画像の特定エリア、又はビューエリア１００２の特定画像シリーズをクリックする。次いで、ユーザ相互作用が捕獲されて医療情報サーバー１０１へ送信され、そこで、ユーザ相互作用は、例えば、ユーザに関連したＥＣＣＤルール又はモデルのセットに鑑み、ＥＣＣＤエンジン５０１を使用して処理される。その結果として更に別の医療情報が決定され、そして医療情報サーバーからクライアント装置へ返送される。
【0067】
図１０Ｂは、ビューエリア１００１の「画像」タブが選択されそして非ＤＩＣＯＭ画像が表示されるビューアの別の例を示す。この例では、ＥＫＧ１０１０及びラボ結果レポート１０１１がビューエリア１００１に示されている。この場合も、これら画像は、患者、及び／又は右の画像エリアに示された画像に関連していることを意味する「インコンテキスト」である。例えば、図１０Ａに示すＤＩＣＯＭ及び非ＤＩＣＯＭ画像は、ビューエリア１００１に表示されるＥＫＧ１０１０及びラボレポート１０１１に示された特定患者の心臓の状態に関連している。又、図示された非ＤＩＣＯＭ画像は、クリック可能であるか、又は他のリンクでＥＣＣＤエンジンと通信するようにリンクされる。ＥＫＧ１０１０をクリックすると、例えば、患者の心臓状態に関連するか又はＥＫＧ１０１０の日付に関連する多くの情報を生じる。或いは、ユーザは、ラボ結果１０１１の特定エリアをクリックして、例えば、その結果に関連したより特定の情報を生じることができる。この場合も、ユーザが図１０Ｂに表示された選択可能なコンテンツのいずれかをクリックすると、ユーザの相互作用が捕獲されてクライアント装置から医療情報サーバー１０１へ送信され、例えば、サーバーによりホストされたＥＣＣＤエンジンにより処理される。次いで、ユーザにより要求された医療情報及びＥＣＣＤエンジンにより決定又は推薦された付加的な医療データが関連データソース１０５から検索される。検索された医療データは、次いで、統合され、医療情報サーバー１０１からクライアント装置へ送信されて提示される。
【0068】
図１０Ｃは、大きなビューア内の考えられる第３のタブ又はビューエリアを示す。このタブは、「セットアップ(setup)」と表示され、ＥＣＣＤエンジンのルール、フィルタ、及び／又は設定に関連する。ユーザによるこれらのルール／フィルタ／設定は、どのように質問し及び／又は種々のビューエリアにどのようにデータを表示するかについてＥＣＣＤエンジンに命令する。この例では、ユーザは、ソース設定エリア１０２１を経て、医療データを検索するためにどのＥＣＣＤエンジンからどのデータソースにアクセスすべきか特定することができる。「連結起動１」１０２２及び「連結起動２」１０２３は、異なるビューエリア又はビューエリアの異なる起動に対する設定を表わす。そのような構成情報は、次いで、クライアント装置から医療情報サーバー１０１へ送信されて、そこに、例えば、ユーザの好み及び／又はコンパイルされたＥＣＣＤルール又はモデルの一部分として記憶される。そのような設定は、その後、ユーザのための更なる医療データを決定し且つ検索するために利用される。
【0069】
図１０Ｄは、大きなビューア内の考えられる第４のタブ又はビューエリアを示す。このタブは、「構成(config)」と表示され、現在ユーザセッション中にビューエリア及び質問を構成するためのものである。構成は、他のビューセッションについてもセーブされる。この例では、ユーザは、ビューエリア（１つ又は複数）の初期起動のパラメータを構成することができる。初期起動は、上述したように、ホストソフトウェアパッケージにおいてユーザがリンクをクリックすることに対応する。これは、初期ビューエリアを起動し、ここでは、「構成」タブにおいて、ユーザは、起動時にビューエリアに何が示されるか構成することができる。例えば、ユーザは、ある時間フレーム及び／又はあるボディエリア、状態、約束／遭遇、等に関連した情報を見ることを望む。ユーザは、ホストソフトウェアパッケージからの初期起動の後にもビューエリアを同様に構成することができ、従って、それらのパラメータは、「オンザフライ」で構成できることに注意されたい。ここでは、直接的な質問もなされ、例えば、ユーザは、ある時間フレーム内の又はあるデータオブジェクトに関連した全てのデータを見ることを求める。
【0070】
図１０Ｅは、複数のビューエリアをもつ考えられるビューア構成の別の実施形態を表わしている。この例では、ビューアは、ウェブブラウザであり、そしてビューエリアは、フレーム及び／又はタブ及び／又はウインドウエリアである。右のビューエリアは、画像ビューエリアを示し、左のビューエリアは、プライバシーポリシー確認、診察ノート、ＣＴ結腸レポート、等を含めて、この患者に利用できる付加的なオブジェクトのリストを示す。ビューエリアのデータは、上述したように、医療情報サーバー１０１のＥＣＣＤエンジンにより与えられている。右側の画像ビューエリアは、１つ以上の画像シリーズからの多数の画像、ＤＩＣＯＭ及び非ＤＩＣＯＭ画像、並びに多数のツール及びビューオプションを含む。又、この患者に対する他のＣＴスキャンシリーズ日付を示す小さなスクロールウインドウと、接近して見るための拡大画像を表示する１つ以上の表示スペースもある。複数のビューアエリアは、互いに関連し、又は「インコンテキスト」である。この例では、表示される全ての情報が特定の患者に関連している。或いは又、表示される画像は、心臓発作のような特定の患者の事象に関連しているか、又は表示される情報は、特定時間フレーム中の特定の患者に関連しているか、又は特定の約束又は他の基準（１つ又は複数）に関連している。
【0071】
利用可能なツールは、進歩型画像処理ツールであり、そのリストが本書の末尾に含まれている。ツールの表示は、ＥＣＣＤエンジンにより、ビューエリアに表示される画像に関連したツールのみに限定される。ユーザは、いずれかのビューアエリアのリンクをクリックして、ＥＣＣＤエンジンが表示する情報を変更する。例えば、ユーザは、ＣＴ結腸レポートをクリックして、以前の大腸内視鏡検査のレポートをより最近の結腸画像と並置してみることができる。
【0072】
図１０Ｆは、左のビューエリアの「ＣＴ結腸レポート」リンクが選択され且つＣＴ結腸レポートが左のビューエリアに表示されるビューアの一例を示す。この場合も、このデータは、それが患者及び右のビューエリアに示す画像に関連することを意味する「インコンテキスト」で表示される。この例では、左のビューエリアに示すＣＴ結腸レポートは、右のビューエリアの結腸画像と同じ患者に関連している。図１０及び１１は、ホストソフトウェアパッケージが進歩型画像ビューイングソフトウェアパッケージであるＥＣＣＤエンジンの実施形態を表わしている。
【0073】
図５に戻ると、ある実施形態において、医療画像処理システム５１０は、ネットワークを経てクライアントに医療画像処理サービスを提供する画像処理エンジンを備えている。画像処理エンジンは、専用グラフィック又は画像処理ハードウェア、例えば、グラフィック処理ユニット（ＧＰＵ）を使用して実施される。又、医療画像処理システム５１０は、ＪＰＥＧ、ＴＩＦＦ、ビデオ、ＥＫＧ、ラボラトリー画像、レポート、テキスト、ＰＤＦ、サウンド、及び他のファイルを含めて、薬品（ＤＩＣＯＭ）適合データ又は他の画像データのデジタル画像形成及び通信のような医療データを記憶するための画像ストア（図示せず）も備えており又はそれに関連している。この画像ストアは、暗号能力も合体していて、医療データを暗号形態で記憶及び送信することができる。又、画像ストアは、多数のデータベースを含み、そしてリレーショナルデータベースマネージメントシステム（ＲＤＢＭＳ）、例えば、ＯｒａｃｌｅTMデータベース又はＭｉｃｒｏｓｏｆｔR ＳＱＬサーバー、等で実施される。
【0074】
ある実施形態では、医療情報サーバー１０１は、リソース（例えば、画像処理ツール）及び／又は画像ストアに記憶された医療データの、クライアント１０２によるアクセスを制御するためにアクセス制御システム（図示せず）を備えている。クライアント１０２は、そのアクセス特権に基づいてリソース及び／又は画像ストアに記憶された医療データのある部分又はタイプにアクセスしてもよいし、しなくてもよい。アクセス特権は、役割ベースのルール又はポリシーに基づいて決定又は構成される。例えば、クライアント１０２は、医療情報サーバー１０１により与えられるツールの幾つかへのアクセスしか許さないある役割で構成される。他の例では、クライアントは、ある患者情報へのアクセスを制限するある役割で構成される。例えば、クライアント１０２のあるユーザ（例えば、ドクター、医学学生）は、画像ストア１０８に記憶された異なる医療情報又は医療情報サーバー１０１により与えられる異なる画像レンダリングリソースにアクセスするために異なるアクセス特権を有する。
【0075】
クライアント装置１０２は、統合型医療ソフトウェアを含むクライアントである。ある実施形態では、統合型ソフトウェアは、画像（１つ又は複数）及び／又は画像処理機能を医療レコードソフトウェア（ＭＲＳ）及び／又はクライアントトライアルソフトウェア（ＣＴＳ）と統合し、これらは、ここでは、総体的に、医療レコード及び／又は医療ソフトウェア（ＭＲＣＳ）と称される。医療レコードソフトウェア（ＭＲＳ）は、ここの患者の医療レコードに焦点を当てる患者中心のソフトウェアである。患者中心とは、ここでは、ソフトウェアの第１の目的が個々の患者に関連したデータを記録しそして見ることであることを意味する。このタイプのソフトウェアは、電子的医療レコード（ＥＭＲ）ソフトウェア、電子的ヘルスレコード（ＥＨＲ）ソフトウェア、パーソナルヘルスレコード（ＰＨＲ）ソフトウェア、等と称される。ＭＲＳにより維持される情報は、典型的に、患者ＩＤ、人口統計学的情報（年齢、体重、身長、血圧(ＢＰ)、等）、ラボオーダー及び結果、テストオーダー及び結果、医療ヒストリー、約束ヒストリー、約束スケジュール、診察ヒストリー、処方箋／薬品、症状／診断、及び保険／払い戻し情報を含む。
【0076】
クライアントトライアルソフトウェア（ＣＴＳ）は、過去及び将来の両医療研究のためのソフトウェアを含む。このタイプのソフトウェアは、医療トライアルマネージメントシステムと称される。ＣＴＳは、リサーチのためのソフトウェアも含む。ＣＴＳは、トライアル中心であり、これは、ソフトウェアの第１の目的が複数の患者又は関係者の集計データを収集しそして見ることであることを意味する。データは、個々の患者／関係者レベルで収集されるが、このデータは、通常、盲目的に見られる。これは、データの観察者及び／又は分析者が一般的に個々の患者／関係者の身元を知らないことを意味する。しかしながら、データは、必要に応じて、個々の患者／関係者レベルで見ることができる。これは、画像が含まれる場合には特に重要である。ＣＴＳは、典型的に、患者ＩＤ、付随薬品、悪い事象、ランダム情報、データ収集、インフォームド・コンセント、集計データ、及び研究の状態を含む。
【0077】
ある実施形態では、クライアント１０２Ａ内で実行される統合型医療ソフトウェアとして実行されるクライアントアプリケーション５０７は、例えば、患者の医療レコード及び／又はトライアルレコードの一部分である患者の医療処置ヒストリーを含めて、患者の医療情報を表示する。そのようなレコードは、ユーザの要求及び／又はＥＣＣＤエンジン５０１による推薦に応答して医療情報サーバー１０１からダウンロードされる。統合型医療ソフトウェアＭＲＳのケースでは、患者の完全な身元が典型的に医療情報の一部分として表示される。他方、統合型ＣＴＳのケースでは、患者が典型的に上述したように匿名であり、患者の身元は、典型的に、表示される医療情報の一部分として露呈されない。
【0078】
ある実施形態では、画像（１つ又は複数）及び／又は画像処理機能がＭＲＣＳと統合される。統合は、画像（１つ又は複数）及び／又は画像処理ツールの形態をとり、ＭＲＣＳと同じウインドウを示す。又、統合は、ＭＲＣＳウインドウから個別のウインドウをオープンする画像（１つ又は複数）及び／又は画像処理ツールを含むウインドウの形態をとる。しかしながら、いずれの統合形態でも、患者及び画像（１つ又は複数）の医療情報は、統合型医療ソフトウェア内で表示され、統合型ソフトウェアのユーザが別のソフトウェアプログラムを経て画像を別々に得る必要はない。
【0079】
ある実施形態では、医療画像処理システム５１０は、進歩型画像処理システム及び自動画像処理システム（例えば、画像処理ウイザード）を備えている。進歩型画像処理システムが使用されるとき、画像処理ツールのセットを表わすグラフィック表現のセットが進歩型画像処理グラフィックユーザインターフェイスに提示されて、ユーザが特定の１つの画像を処理するために画像処理ツールの１つ以上を特定できるようにする。自動画像処理システムが使用されるとき、自動画像処理システムの基礎的処理ロジックは、例えば、ユーザの介在なく、又はどの画像処理ツールを使用するかのユーザの知識なく、画像を処理するために１つ以上の画像処理ツールを自動的に決定しそして選択するように構成される。リモート画像処理サーバー１１０により与えられる画像処理ツールのためのグラフィック表現（例えば、アイコン）は、クライアントにおいて実行される統合型医療ソフトウェアのユーザに表示される。そのような実施形態では、利用可能な画像処理ツールは、統合型医療ソフトウェアにおいてアイコン又は他のグラフィック表現のセットとして表示され、これは、ユーザによりアクチベートされると、リモート画像処理システム５１０によって画像を操作できるようにする。ある実施形態では、画像処理ソフトウェアは、ＭＲＣＳプログラムと統合され、そして「インコンテキスト」もオープンする。「インコンテキスト」とは、画像処理ソフトウェアが現在のユーザ及び／又は患者及び／又は苦悩に対して適当な画像（１つ又は複数）及び／又はツールを示すためにオープンすることを意味する。特定のユーザへの画像ツールの利用性は、その特定のユーザ（例えば、ドクター対医学学生）のアクセス特権に依存する。或いは又、画像ツールの利用性は、ＤＩＣＯＭタグのようなあるタグにより識別される患者の特定のボディ部位に基づいて決定されてもよい。
【0080】
例えば、あるドクターは、自分の患者の心臓血管画像が３Ｄビューでオープンし、血管中心線ツールが利用でき、更に、自分の患者の腹部画像が冠動脈ビューでオープンし、フライスルー又はバーチャルな大腸内視鏡検査ツールが利用できることを好む。又、ビューから隠れて他のビュー及びツールをもつことを好む。別の例では、別のドクターは、自分の患者の画像がオープンして、その患者に対して使用した最も直近のビュー及びツールを示すことを好む。別の例では、心臓血管のケースのデフォールトビューが特定のビュー及びツールを示すようにセットされるが、ユーザは、自分の好みがデフォールトビュー及びツールを無効にするようにデフォールトを変更することができる。
【0081】
全ての前記例において、その時点で評価されている患者に関連した画像のみが見られるのが理想的である。更に、ユーザ／医師は、患者に関連した画像を見つけるようにサーチする必要がなく、画像は、例えば、対応する患者ＩＤに基づいて、正しい患者に自動的に関連付けられる。これを行うために、患者の身元を患者の画像に関連付ける必要がある。これは、タグ、例えば、ＩＤ番号のような共通の識別子、１つ以上の画像に関連したメタデータ、採掘患者データ、ボディ部位分析、又は他の仕方を使用して行われる。又、適当なツールを示しそして不適当なツールを隠す必要がある。タグについては、以下で詳細に述べる。
【0082】
例えば、画像又は画像シリーズを分析して、解剖学に基づき、それが頭部であるか、腹部であるか又は他のボディ部位であるか決定することができる。頭蓋骨は、解剖学の他の部位と同様に、特徴形状を有する。基準画像のカタログを使用して特定ボディ部位の識別を助けることができる。この分析に基づいて、適当なビュー及び／又はツールをユーザに見えるようにし、そして不適当なビュー及び／又はツールを隠すことができる。例えば、画像シリーズが頭部／頭蓋骨である場合には、画像シリーズが軸方向ビューのようなあるビューに示され、脳に関連したツールが見えるようになる。更に、ＭＲＣＳレコードにおいて「腫瘍」又は「脳卒中」のようなあるキーワードが見つかった場合は、腫瘍を検出し又は脳血流を評価するツールのような特定のツールが示される。又、形状、疾病、タグ、等に基づいて画像における解剖学から患者ＩＤを決定することもできる。例えば、歯のエリアの画像を歯科レコードとマッチングさせて、医療画像から患者を識別することができる。或いは、識別タグを医療画像に含ませることができ、患者ＩＤ番号をもつタグがＣＴスキャナのテーブル又はその付近に或いは患者自身に配置される。別の実施形態では、ソフトウェアのユーザは、画像処理ソフトウェアをどのようにインコンテキストで提示するかカスタマイズすることができる。例えば、心臓専門医であるドクターＹは、画像を３Ｄモデルビューでオープンしそして心臓ツールＡ及び心臓ツールＢが彼に見えるようにすることを好む。この例では、他のビュー（例えば、軸方向、矢状及び結腸ビュー）が隠され、そして他のツール（例えば、結腸又は脳に関連したツール）が隠される。
【0083】
ある実施形態によれば、進歩型画像処理システムは、異なるタイプのユーザが、画像を処理するためのツールアイコンによって表わされた画像ツールにアクセスするのを許し、これら画像ツールは、ネットワークを経て処理リソース（例えば、画像処理エンジン）を使用する。自動画像処理システムは、異なるタイプのユーザが、ツールを直接取り扱う必要なく画像ツールの機能にアクセスするのを許す。自動画像処理システムは、既存の又は新たな進歩型医療画像処理ソフトウェアシステム（例えば、進歩型画像処理システム）の上に積層されるか又はそれと一体化されて、医療画像処理リソース（例えば、画像処理エンジン）の使用を簡単化又は自動化し、これは、ソフトウェア、ハードウェア又はその両方で実施される。
【0084】
ある実施形態によれば、進歩型画像処理システム及び自動画像処理システムは、両方とも、アプリケーションプログラミングインターフェイス（ＡＰＩ）又は通信プロトコルのセットを経て基礎的な画像処理エンジンの画像処理機能（例えば、ライブラリー、ルーチン、ツール、等）にアクセスする。進歩型画像処理システムが使用されるときは、ある実施形態によれば、ユーザにより選択された特定の画像を処理するためにユーザが詳細な画像処理パラメータを指定できるように進歩型グラフィックユーザインターフェイスが提示される。進歩型画像処理システムの基礎的な処理ロジックは、進歩型グラフィックユーザインターフェイスから受け取ったユーザ入力を処理し、そしてユーザ入力に基づき発生される画像処理パラメータのセットと共に１つ以上の画像処理コマンドを公式化する。進歩型画像処理システムの処理ロジックは、次いで、画像を処理するために、例えば、ＡＰＩを経てバックエンド画像処理エンジンへコマンドを送る。
【0085】
自動画像処理システムが使用されるときは、ある実施形態によれば、簡単なグラフィックユーザインターフェイス（例えば、ウイザード）がユーザのクライアント装置に提示され、詳細な動作画像処理パラメータの指定をユーザに要求せずに、一連の簡単なステップ又は繰り返し質問を通してユーザを歩かせる。その基礎的な処理ロジックは、簡単なグラフィックユーザインターフェイスとのユーザ相互作用に基づき詳細な画像処理パラメータを自動的に決定するように構成される。画像を処理するために画像処理コマンドのセットが発生されてバックエンド画像処理エンジンに送られる。或いは又、自動画像処理システムの基礎的な処理ロジックは、進歩型画像処理システムがユーザからその対応グラフィックユーザインターフェイスを経て受け取ったのと同様に、パラメータを決定して、それを進歩型画像処理システムへ通す。進歩型画像処理システムは、次いで、自動画像処理システムに代って、基礎的な画像処理エンジンと通信する。
【0086】
自動画像処理システムは、画像処理ウイザードの形態で実施される。ウイザードは、進歩型画像処理プロセスを通してユーザを誘導する。ウイザードは、ユーザが進歩型画像処理ツールをどのように動作するかの詳細を知る必要がないようにして画像データを処理するため、例えば、好み、仮定、及び１組のルールを使用して、できるだけ多数のステップを自動化する。又、ウイザードは、自動的に又は他の仕方で生じた結果を確認又は変更する機会をユーザに与える。ウイザードは、直感的ユーザインターフェイスの提示と、画像処理プロセスを通してユーザをガイドする上で助けとなる質問に対する応答のし易さで構成される。
【0087】
ある実施形態によれば、自動画像処理システムは、ユーザに馴染み易い双方向グラフィックユーザインターフェイスを与える。自動画像処理システムは、ユーザが、画像を処理するための特定ステップ及び／又は画像処理パラメータ又はツールを完全に理解する必要なく、ユーザが理解できる処理段階のセットに基づいて基礎的な処理リソースにアクセスして、画像に対してある主要な又は共通の又は一般的な画像処理動作を遂行できるようにする。自動画像処理システムは、ユーザに馴染み易いグラフィックユーザインターフェイス（ＧＵＩ）を通して、一連の質問を経てユーザと相互作用し、そしてユーザから応答の一部分としてユーザ入力を受け取り、ユーザの意図を決定することができる。自動画像処理システムとのユーザ相互作用に基づいて１つ以上の画像処理動作が決定されそして自動画像処理システムを経てユーザに推薦される。ユーザは、画像を処理するために推薦された画像処理動作の１つ以上を選択するか、或いは又、画像処理動作は、自動画像処理システムにより自動的に遂行される。１つ以上の画像処理インジケータをユーザが選択するのに基づき、その選択された画像処理動作に関連した１つ以上の画像処理パラメータが、ユーザの介在なく且つユーザが同じパラメータを与えることもなく、自動的に決定される。
【0088】
自動画像処理システムにより受け取られる画像処理パラメータに基づき、ある実施形態によれば、１つ以上の画像処理コマンドが発生されて、自動画像処理システムから画像処理エンジンへ画像処理のために送信される。その画像処理コマンドに応答して、画像処理エンジンは、画像処理パラメータに基づいて画像を処理し、そして新たな又は更新された画像を発生する。新たな画像は、オリジナル画像に関連した同じ医療データの異なるビューを表わす。新たな画像は、次いで、画像処理エンジンから自動画像処理システムへ返送され、この処理システムは、次いで、新たな画像をクライアント装置へ送信してユーザに提示する。又、自動画像処理システムは、ユーザが新たな画像で満足であるかどうかについてクライアントがユーザを促す。ユーザが新たな画像で満足である場合には、自動画像処理システムは、新たな画像に関するより多くのユーザ入力についてユーザと相互作用して画像処理パラメータを更に調整し、そして画像処理動作が繰り返し遂行される。その結果、ユーザは、進歩型画像処理システムをどのように利用するか完全に理解する必要がないが、進歩型画像処理システムは、進歩したユーザにも利用可能である。自動画像処理システムに関する更に詳細な情報は、参考としてここにそのまま援用される２０１４年９月２４日に出願された米国特許出願第１４／４９５，７０１号に見られる。
【0089】
ある実施形態によれば、医療データセンター又は画像捕獲装置（図示せず）から、又は別の画像ソース、例えば、ＣＤ又はコンピュータデスクトップから受け取られた画像データに応答して、画像処理システム５１０は、画像データのある前処理を自動的に遂行しそしてその前処理された画像データを医療データストア（図示せず）に記憶するように構成される。例えば、ＰＡＣＳから画像データを受け取るか又は医療画像捕獲装置から直接受け取ると、画像処理システム２０４は、ある動作、例えば、骨除去、中心線抽出、球形の発見、位置合わせ、パラメータマップ計算、再フォーマット、時間−密度分析、構造体のセグメント化、自動３Ｄ動作、及び他の動作（その幾つかは後でリストする）を自動的に遂行する。
【0090】
画像前処理システム５１０は、更に、ワークフローマネージメントシステムを含む。このワークフローマネージメントシステムは、個別のサーバーでもよいし、又は画像処理システム５１０と一体化されてもよい。又、ワークフローマネージメントシステムは、本発明の幾つかの実施形態により複数の機能を遂行する。例えば、ワークフローマネージメントシステムは、医療画像捕獲装置から受信された医療画像データを取得しそして記憶する上でデータサーバー機能を遂行する。又、グラフィックエンジンとして働くか又は画像処理システム５１０を呼び出して医療画像データを処理し、２Ｄ又は３Ｄ医療画像ビューを発生する。ある実施形態では、ワークフローマネージメントシステムは、グラフィックエンジンを有する画像処理システム５１０を呼び出して、２Ｄ及び３Ｄ画像生成を遂行する。クライアントがある医療データビューを要求するとき、ワークフローマネージメントシステムは、医療データストア２０６に記憶された医療画像データを検索し、そして医療画像データから２Ｄ又は３Ｄ医療画像ビューをレンダリングする。医療画像ビューの最終結果がクライアントに送られる。
【0091】
ある実施形態では、ワークフローマネージメントシステムは、ワークフローテンプレートの生成、更新及び削除を管理する。又、ユーザの要求を受けたときにワークフローシーン生成を遂行して、ワークフローテンプレートを医療画像データに適用する。ワークフローは、診断のために医療画像ビューを発生するプロセスにおいてアクティビティの繰り返しパターンを捕獲するように定義される。ワークフローは、これらのアクティビティを、各アクティビティを遂行する順序に従ってプロセスフローへと配列する。ワークフローの各アクティビティは、その機能の明確な定義、アクティビティを遂行するのに必要なリソース、並びに受信した入力及びアクティビティにより発生された出力を有する。ワークフローの各アクティビティは、ワークフローステージ又はワークフローエレメントと称される。明確に定義された要求及び責任では、ワークフローのワークフローステージは、ワークフローに定義された目標を達成するプロセスにおいて１つの特定のタスクを遂行するように設計される。多数の医療画像研究に対して、診断のための医療画像ビューを生成するためのアクティビティのパターンは、通常、繰り返し且つ明確に定義される。それ故、ワークフローを使用して、現実の医療画像処理をモデリング及びドキュメント化して、ワークフローの定義された手順ルールのもとで画像処理が適切に遂行されることを保証する。ワークフローステージの結果は、後で検討又は使用するためにセーブすることができる。
【0092】
ある実施形態では、特定の医療画像研究のためのワークフローがワークフローテンプレートによりモデリングされる。ワークフローテンプレートとは、論理的ワークフローを形成する既定の１組のワークフローステージを伴うテンプレートである。アクティビティを処理する順序は、既定の１組のワークフローステージの間に確立される順序でモデリングされる。ある実施形態では、ワークフローテンプレートのワークフローステージは、逐次に順序付けされ、低い順序のステージは、高い順序のステージの前に遂行される。別の実施形態では、ワークフローステージ間に依存関係が維持される。そのような構成のもとでは、ワークフローステージは、それが依存するワークフローステージが最初に遂行されるまで遂行できない。更に別の実施形態では、進歩型ワークフローマネージメントは、複数のワークフローステージに依存する１つのワークフローステージ、又は１つのワークフローステージに依存する複数のワークフローステージ、等を許す。
【0093】
画像処理動作は、医療画像形成装置により収集された医療画像データを入力として受け取り、その医療画像データを処理し、そしてメタデータを出力として発生する。メタデータエレメントとしても知られているメタデータは、医療画像データを記述し、処理し及び／又は管理するためのパラメータ及び／又はインストラクションを広く指す。例えば、ワークフローステージの画像処理動作により発生されるメタデータは、診断目的で医療画像ビューを発生するために医療画像データに適用できる画像処理パラメータを含む。更に、医療画像ビューの種々の自動及び手動操作もメタデータとして捕獲される。従って、メタデータは、メタデータがセーブされたときにシステムがあった状態にシステムを復帰できるようにする。
【0094】
ワークフローテンプレートに既定されたワークフローステージを処理することから生じた結果をユーザが有効とした後に、ワークフローマネージメントシステムは、新たなシーンを生成し、そしてその新たなシーンをワークフローシーンに記憶する。又、ワークフローマネージメントシステムは、シーンから発生される医療画像ビューのユーザ調整中にシーンの更新及びセーブも許す。ワークフローマネージメントシステムに関する更に詳細な情報は、２００８年８月２１日に出願された“Workflow Template Management for Medical Image Data Processing”と題する同時係争中の米国特許出願第１２，１９６，０９９号に見ることができ、これは、現在、米国特許第８，３７０，２９３号であり、参考としてここにそのまま援用される。
【0095】
上述したように、画像処理システムを使用するユーザにより種々の画像処理ツールにアクセスすることができる。上述した画像処理システムの一部分として含まれる医療画像処理ツールの例を以下に述べる。これらの例は、例示のためのもので、本発明を限定するものではない。
【0096】
血管分析ツールは、頸動脈及び腎動脈を含めて、冠動脈から、大動脈瘤プランニング及びより一般的な血管調査まで、広範囲の血管分析タスクを実行できるＣＴ及びＭＲ血管造影のための包括的血管分析パッケージを含む。自動中心線抽出、真っ直ぐなビュー、直径及び長さ測定、ＣＰＲ及び軸方向レンダリング、並びに自動薄板ＭＩＰのための血管追跡モードが含まれる。
【0097】
カルシウムスコアツールは、アガツトン(Agatston)、体積及びミネラル質量アルゴリズムでの冠動脈カルシウムの半自動識別を含む。カスタム化オプションを伴う一体型レポートパッケージが含まれる。
【0098】
時間従属分析ツールは、ＣＴ又はＭＲで取得される時間分析平坦又は体積４Ｄ脳灌流検査を含む。ＴＤＡツールは、分析を加速するため入力関数及び基線の半自動選択と共に、平均増強時間及び増強統合のような種々のパラメータのカラー又はマッピングをサポートする。ＴＤＡツールは、僅かな取得内での解釈を保証するために動的な４Ｄエリア検出器ＣＴ検査の迅速な自動処理をサポートする。
【0099】
ＣＴ血管造影検査から非増強構造体（例えば、骨）を除去するのにＣＴ／ＣＴＡ（コンピュータ断層撮影血管造影）差し引きツールが使用され、ＣＴ／ＣＴＡオプションは、前及び後コントラスト画像の自動位置合わせと、それに続いて、ノイズを増加せずにＣＴＡスキャンから高強度構造体（骨及び手術用クリップのような）を除去して、コントラスト増強血管構造体を分離する上で役立つ濃密ボクセルマスキングアルゴリズムとを含む。
【0100】
小葉分解(Lobular decomposition)ツールは、当該体積、例えば、血管床を含むスキャン領域又は肝臓のような器官内のツリー状構造体を識別する。このＬＤツールは、次いで、ツリーの所与の岐路又はそのサブ岐路の１つへの接近度に基づいて当該サブ体積を識別する。リサーチアプリケーションは、器官の小葉構造体の分析を含む。
【0101】
「低露出での一般的増強＆ノイズ処置(General Enhancement & Noise Treatment with Low Exposure)」ツールは、ソース画像の質が最適でないときでも、３Ｄ、中心線、輪郭及びセグメント化アルゴリズムの有効性を改善するためにノイズ管理技術を適用する進歩型体積フィルタアーキテクチャーを含む。
【0102】
スフェアファインダー(Spherefinder)ツールは、高い真球度インデックス（多数の小結節及びポリープで示される特性）をもつ構造体の位置を識別するため体積検査の自動分析を遂行する。スフェアファインダーは、潜在的な当該エリアを識別するために肺又は結腸ＣＴスキャンと共にしばしば使用される。
【0103】
セグメント化、分析＆追跡ツールは、孤立性肺小結節又は他の潜在的な障害のような塊及び構造体の分析及び特徴付けをサポートする。このツールは、当該領域を識別及びセグメント化し、次いで、ＲＥＣＩＳＴ及びＷＨＯのような測定基準を適用して、発見及び追跡比較の作表レポートを導く。スフェアファインダーを含めて、任意の検出エンジンからの候補マーカーの表示及び管理がサポートされる。
【0104】
時間体積分析ツールは、心臓心室のような、リズムのある動きをする室からの駆出率の自動計算を与える。ユーザが当該壁境界（例えば、心外膜及び心内膜）を識別し、そしてそれらのユーザ確認当該領域に基づいて、多相ＣＴでーたから、駆出率、壁体積（質量）及び壁厚みをレポートする。作表レポート出力が含まれる。
【0105】
顎顔面ツールは、顎顔面領域のＣＴ検査の分析及び可視化をサポートし、これらツールは、ＣＰＲツールを適用して、種々の平面に種々の厚みの「パノラマ」投影を、そして画成されたカーブ平面に沿って設定増分で断面ＭＰＲビューを発生する。
【0106】
結腸、肺又は血管のような腔内ＣＴ又はＭＲ調査に適当可能なものとして、「フライスルー(Flythrough)」ツールは、並置再検討、以前に見たエリアのペイント、パーセントカバレージ追跡、並びに順方向、逆方向、フィッシュアイ及びフラット体積レンダリングビューを含む複数スクリーンレイアウトをサポートする。コントラスト差し引き、「キューブビュー(Cube View)」及び一体型コンテキストレポートのためのツールがサポートされる。ｉＮｔｕｉｔｉｏｎのスフェアファインダーを含めて、任意の検出エンジンからの候補マーカーの表示及び管理がサポートされる。
【0107】
体積ヒストグラムツールは、当該体積を構成のためにセグメント化及び分析できるようにする。リサーチアプリケーションは、肺の低減衰領域の分析、腫瘍のボクセルポピュレーションへのスレッシュホールドベースの分割、血栓性血管又は動脈瘤或いは他の病気の調査を含む。
【0108】
発見ワークフローツールは、シリアルな検査にわたって発見を追跡するための枠組みを与える。データベースは、測定値及び重要な画像を保持し、そしてシリアルな比較を提示するためのＲＥＣＩＳＴ１．１解決策のように、時間に伴う発見の構造化比較及び作表レポートをサポートする。音声認識システム又は臨床学的データベースとの自動的一体化のために注釈及び画像マークアップ（ＡＩＭ）ＸＭＬスキーマがサポートされ、そしてワードベースレポートがデータベースから導出される。
【0109】
これらのツールでは、２つのＣＴ、ＰＥＴ、ＭＲ又はＳＰＥＣＴシリーズ、又はその２シリーズ組み合わせをオーバーレイすることができ、その一方は、半透明のカラーコードが指定され、そして他方は、解剖学的基準のためにグレイスケール及び体積レンダリングで示される。自動位置合わせが行われ、そして一時的なシリーズ又はセーブされた第３のシリーズに対する差し引きが可能となる。ＰＥＴ／ＭＲ可視化のためのサポートが含まれる。
【0110】
あるＭＲ検査（例えば、乳房のＭＲ）は、ある期間にわたって行われる一連の画像取得を含み、ある構造体は、他の構造体に対して時間と共に増強される。これらのツールは、前増強画像を全ての後増強画像から差し引いて増強構造体（例えば、血管構造体及び他の増強組織）の可視化を強調できることを特徴とする。所与の領域の時間強度グラフをプロットするために当該時間依存領域ツールが提供される。
【0111】
パラメータマッピングツールは、多相ＭＲツールの増強であり、パラメータマッピングオプションは、オーバーレイマップを前計算し、画像の各ピクセルは、ピクセル強度の時間依存振舞いに基づいてカラーコード化される。一例として、このツールは、増強領域の識別及び調査を加速するために乳房ＭＲに使用される。
【0112】
ＭｕｌｔｉＫｖツールは、複数の売主からの「二重エネルギー及びスペクトル画像」取得をサポートし、標準的画像処理アルゴリズム、例えば、セグメント化又はコントラスト抑制、並びに正確な分析及び新規技術の開発のための一般的ツールキットを提供する。
【0113】
以上に述べた実施形態は、種々の医療エリアに適用できる。例えば、上述した技術は、血管分析（血管内大動脈修復（ＥＶＡＲ）及び電気生理学（ＥＰ）プランニング）に適用できる。そのような血管分析は、大動脈瘤及び電気生理学プランニングに加えて、頸動脈及び腎臓動脈のような冠動脈血管及び一般的血管の両分析の解釈のために遂行される。クラウドサービスとして提供されるツールは、自動中心線抽出、真っ直ぐなビュー、直径及び長さ測定、カーブ型プレーナリフォーム（ＣＰＲ）及び軸方向レンダリング、並びに血管直径対距離のチャート及び断面ビューを含む。血管追跡ツールは、２つの直交平面に最大強度投影（ＭＩＰ）ビューを与え、これは、ナビゲーション及び深い質問を容易にするために血管中心線に沿って移動し且つその周りで回転する。プラーク分析ツールは、柔軟なプラーク、石灰化プラーク及び院内病変のような非管腔構造体の詳細な描写を与える。
【0114】
加えて、上述した技術は、血管内大動脈修復に利用できる。幾つかの実施形態によれば、クラウドサービスとして提供される血管分析ツールは、動脈瘤サイジングの測定値を捕獲するレポートテンプレートの定義をサポートする。複数のアクセス点でのＥＶＡＲ手順のプランニングを許すために複数の中心線が抽出される。血管に垂直な直径が２つの大動脈腸骨動脈路に沿った距離と共に測定される。大動脈瘤の主な製造者測定仕様をステントサイジングに必要なものとすることができるようにカスタムワークフローテンプレートが使用される。又、有窓の分岐装置プランニングのために分岐血管の方向及び位置をドキュメント化する上で役立つ「クロック・フェース」オーバーレイでのそのようなセグメント化及び体積決定を使用してもよい。要求された測定値及びデータを含むレポートが発生される。
【0115】
又、上述した技術は、左心房分析モードで適用することもでき、ここでは、各肺静脈入口の半自動左心房セグメント化が、クラウドサービスとして提供される単一クリック距離対ツールでサポートされ、大及び小の静脈直径が評価される。測定値は、自動的に検出されて、一体型レポートシステムに捕獲される。これらの能力が他の血管分析ツールと結合されて、切除及び先導解決策プランニングのための包括的且つカスタマイズされたＥＰプランニングワークフローを与える。
【0116】
又、上述した技術は、カルシウムスコアリングにも利用できる。冠動脈カルシウムの半自動識別は、オンスクリーンで合計されそしてレポートされるアガツトン、体積及びミネラル質量アルゴリズムでサポートされる。その結果は、患者及びその心臓血管ヒストリー及び危険ファクタに関連した種々の他のデータと共にオープンフォーマットのデータベースに記憶される。カスタマイズされたレポートは、それらのデータに基づいて、クラウドサービスの一部分として、自動的に発生される。又、ソサエティ・オブ・カルジオバスキュラー・コンピューテッド・トモグラフィー（ＳＣＣＴ）ガイドラインにより定義されたレポート作成も含む。
【0117】
又、上述した技術は、時間・体積分析（ＴＶＡ）にも利用でき、これは、多相データからの左心室体積、駆出率、心筋体積（質量）及び壁厚みの完全自動計算を含む。クラウドサービスの一部分として提供される高速で且つ効率的なワークフローは、レベル及び輪郭を容易に検証又は調整できるようにする。その結果は、一体型レポート機能内で提示される。
【0118】
又、上述した技術は、セグメント化分析及び追跡（ＳＡＴ）の分野にも利用でき、これは、肺のＣＴ検査を含めて、種々のスキャンでの質量及び構造体の分析及び特徴付けをサポートすることを含む。特徴は、質量の単一クリックセグメント化、セグメント化の問題を解決するための手動編集ツール、寸法及び体積の自動レポート、選択された領域のグラフィック３Ｄ表示、一体型自動レポートツール、パーセント体積変化及び倍時間を含む追跡比較のサポート、及び真球度フィルタ結果の再検討のサポートを含む。
【0119】
又、上述した技術は、フライスルーの分野にも利用でき、これは、結腸を自動セグメント化し及び中心線抽出するという特徴を含み、必要に応じてそれら中心線を再定義するために編集ツールが利用できる。２Ｄ再検討は、代表的な同期した腔内ビューと共に、軸方向、冠状及び矢状ビューのいずれかに並置の同期した背臥位及び腹臥位データセットを含む。３Ｄ再検討は、大きな腔内ビュー、及び全結腸を表示する広げられたビューと共に、軸方向、冠状及び矢状ＭＰＲ又はＭＩＰ画像表示を含む。カバレージの追跡は、見えない区分の段階的再検討、ワン・クリックポリープ識別、ブックマーク及び合流発見、並びに当該体積及び一体化コンテキストレポートツールを分離する立体的ビューで、１００％カバレージを保証するようにサポートされる。真球度フィルタ結果を使用するためにサポートが与えられる。
【0120】
又、上述した技術は、時間依存分析（ＴＤＡ）の分野にも利用でき、これは、例えば、脳の灌流研究内で適当なコンピュータ断層撮影血管造影（ＣＴＡ）及び／又はＭＲＩ検査の時間依存振舞いを分析するための評価ツールをなす。その特徴は、同時に複数の時間依存シリーズをロードするためのサポートと、入力及び出力機能並びに当該領域を選択するための手順的ワークフローとを含む。一体型レポートツール、並びに血液流、血液量及び通過時間マップをＤＩＣＯＭにエクスポートする能力が提供される。又、これらのツールは、種々の時間依存パラメータを計算するために時間依存ＭＲ取得と共に使用される。
【0121】
又、上述した技術は、ＣＴＡ−ＣＴ差し引きの分野にも利用でき、これは、前及び後コントラスト画像の自動位置合わせと、それに続いて、ノイズを増加せずにＣＴＡスキャンから高強度構造体（骨及び手術用クリップのような）を除去して、コントラスト増強血管構造体をそのままにする差し引き又は濃密ボクセルマスキング技術とを含む。
【0122】
又、上述した技術は、歯科分析にも利用でき、これは、歯科ＣＴスキャンの再検討に適用されて、種々の平面に種々の厚みの「パノラマ」投影を、そして画成されたカーブ平面に沿って設定増分で断面ＭＰＲビューを発生する能力を与えるＣＰＲツールを提供する。
【0123】
又、上述した技術は、多相ＭＲ（基本的、例えば、胸、前立腺ＭＲ）の分野にも利用できる。あるＭＲ検査（例えば、胸、前立腺ＭＲ）は、ある期間にわたって得られる一連の画像取得を含み、ある構造体は、他の構造体に対し時間と共に増強される。このモジュールは、前増強画像を全ての後増強画像から差し引いて増強構造体（例えば、血管構造体及び他の増強組織）の可視化を強調できることを特徴とする。当該時間依存領域ツールは、所与の領域の時間・強度グラフをプロットするために提供される。
【0124】
又、上述した技術は、パラメータマッピング（例えば、多相胸部ＭＲ）にも利用でき、ここでは、パラメータマッピングモジュールは、オーバーレイマップを前計算し、画像の各ピクセルは、ピクセル強度の時間依存振舞いに基づいてカラーコード化される。又、上述した技術は、スフェアファインダー（例えば、肺及び結腸の真球度フィルタ）にも利用できる。スフェアファインダーは、データセットが受け取られるや否やそれを前処理し、そしてフィルタを適用して球状構造体を検出する。これは、潜在的な当該エリアを識別するために肺又は結腸ＣＴスキャンと共にしばしば使用される。又、上述した技術は、ＣＴ／ＭＲ／ＰＥＴ／ＳＰＥＣＴの融合にも利用できる。２つのＣＴ、ＰＥＴ、ＭＲ又はＳＰＥＣＴシリーズ、又はその２シリーズ組み合わせをオーバーレイすることができ、その一方は、半透明のカラーコードが指定され、そして他方は、解剖学的基準のためにグレイスケール及び体積レンダリングで示される。自動位置合わせが行われ、そして一時的なシリーズ又はセーブされた第３のシリーズに対する差し引きが可能となる。
【0125】
又、上述した技術は、小葉分解の分野にも利用できる。小葉分解は、解剖学的構造体を念頭において設計された分析及びセグメント化ツールである。ツリー状構造体（例えば、動脈及び／又は静脈ツリー）と織り合わされた構造体又は器官領域では、小葉分解ツールは、ユーザが当該体積及びそれに関連したツリーを選択し、そしてその体積を、ツリー又は特定のサブ岐路に最も接近した葉又は領域に仕切ることができるようにする。この一般的で且つ柔軟なツールは、肝臓、肺、心臓及び種々の他の器官並びに病理学的構造体の分析において潜在的なリサーチ用途を有する。
【0126】
又、上述した技術は、体積ヒストグラムの分野にも利用できる。この体積ヒストグラムは、異なる強度又は密度範囲のポピュレーションへの構成ボクセルの仕切りに基づき所与の当該体積の分析をサポートする。これは、例えば、癌（活性腫瘍と壊死組織と浮腫との間のバランスを理解するための試みにおいて腫瘍の組成を分析することが望まれる）又は肺気腫（肺ＣＴ検査における低減衰ボクセルのポピュレーションが初期疾病の有意義な指示子である）のような疾病処理へのリサーチをサポートするのに使用できる。
【0127】
又、上述した技術は、モーション分析の分野にも利用できる。モーション分析は、双方向３Ｄ又は４Ｄディスプレイを利用できないとき発見のより有効な通信として４Ｄプロセスのパワフルな２Ｄ表現を与える。鼓動している心臓のような動的体積取得は、モーション分析を受けて、動的なシーケンス全体にわたり重要な境界の輪郭のカラーコード「トライアル」を発生し、単一の２Ｄフレームを捕獲して、文献に容易にレポートできる仕方でモーションを示すことができるようにする。カラーパターンの均一性又はその欠如は、モーションが調和的である程度を反映し、単一画像から即座に視覚的フィードバックを与える。
【0128】
図１１Ａ及び１１Ｂは、本発明の幾つかの実施形態によるクラウドベースの画像処理システムを示すブロック図である。例えば、クラウドサーバー１１０９は、上述したように、医療情報サーバー１０１を表わす。図１１Ａを参照すれば、ある実施形態により、システム１１００は、ネットワークを経てクラウド１１０３に通信結合される１つ以上のエンティティ又はインスティテュート１１０１−１１０２を備えている。エンティティ１１０１−１１０２は、世界中に存在する種々の施設を有する医療インスティテュートのような種々の組織を表わす。例えば、エンティティ１１０１は、画像捕獲装置１１０４（１つ又は複数）、画像ストレージシステム（例えば、ＰＡＣＳ）１１０５、ルーター１１０６、及び／又はデータゲートウェイマネージャー１１０７を備えているか又はそれに関連している。画像ストレージシステム１１０５は、エンティティ１１０１にアーカイブサービスを提供する第三者エンティティにより維持され、これは、エンティティ１１０１に関連した管理者又はユーザのようなワークステーション１１０８によりアクセスされる。本書の全体を通して、医療インスティテュートは、組織エンティティの一例として使用されることに注意されたい。しかしながら、それに限定されるものではなく、他の組織又はエンティティにも適用できる。
【0129】
ある実施形態では、クラウド１１０３は、サービスプロバイダーに関連し且つネットワークを経て地理的に分散されたサーバーのセット又はサーバーのクラスターを表わす。例えば、クラウド１１０３は、カリフォルニア州フォスターシティのテラレコン(TeraRecon)のような医療画像処理サービスプロバイダーに関連している。ネットワークは、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、インターネット又はイントラネットのようなワイドエリアネットワーク（ＷＡＮ）、或いはその組み合わせである。クラウド１１０３は、ネットワークを経てクライアント１１１３−１１１６のような種々のクライアントにアプリケーションサービスを提供できる種々のサーバー及び装置で形成される。ある実施形態では、クラウド１１０３は、画像処理サービスを提供するための１つ以上のクラウドサーバー１１０９、画像及び他の医療データを記憶するための１つ以上のデータベース１１１０、及びエンティティ１１０１−１１０２のような他のエンティティへ又はそこからデータを転送するための１つ以上のルーター１１１２を備えている。クラウドサーバーがサーバークラスター又は２つ以上のサーバーより成る場合は、クラスター内のサーバー間でのデータの転送を制御するルールが存在する。例えば、ある国のサーバーのデータを別の国のサーバーに入れてはならない理由がある。
【0130】
サーバー１１０９は、ネットワークを経てクライアント１１１３−１１１６に医療画像処理サービスを提供する画像処理サーバーである。例えば、サーバー１１０９は、ＴｅｒａＲｅｃｏｎ ＡｑｕａｒｉｕｓＮＥＴTMサーバー及び／又はＴｅｒａＲｅｃｏｎ ＡｑｕａｒｉｕｓＡＰＳサーバーとして実施される。データゲートウェイマネージャー１１０７及び／又はルーター１１０６は、ＴｅｒａＲｅｃｏｎ ＡｑｕａｒｉｕｓＧＡＴＥ装置の一部分として実施される。医療画像形成装置１１０４は、Ｘ線ＣＴ装置、ＭＲＩスキャニング装置、核医学装置、超音波装置、又は他の医療画像形成装置のような画像診断装置である。医療画像形成装置１１０４は、試料の複数の断面ビューから情報を収集し、それらを再構成し、そして複数の断面ビューに対する医療画像データを発生する。医療画像形成装置１１０４は、モダリティとも称される。
【0131】
データベース１１１０は、医学的デジタル画像及び通信（ＤＩＣＯＭ）適合データ又は他の画像データのような医療データを記憶するためのデータストアである。又、データベース１１１０は、暗号能力も組み込むことができる。データベース１１１０は、複数のデータベースを含んでもよく、及び／又はストレージプロバイダーのような第三者の売主により維持されてもよい。データストア１１１０は、リレーショナルデータベースマネージメントシステム（ＲＤＢＭＳ）、例えば、ＯｒａｃｌｅTMデータベース又はＭｉｃｒｏｓｏｆｔR ＳＱＬサーバー、等で実施される。クライアント１１１３−１１１６は、デスクトップ、ラップトップ、タブレット、移動電話、パーソナルデジタルアシスタント（ＰＤＡ）、等の種々のクライアント装置を表わす。クライアント１１１３−１１１６の幾つかは、ネットワークを経てサーバー１１０９によりホストされる医療画像処理ツール又はアプリケーションのようなリソースにアクセスするためにクライアントアプリケーション（例えば、シンクライアントアプリケーション）を含む。シンクライアントは、例えば、ウェブブラウザ、電話アプリケーション、等を含む。
【0132】
ある実施形態によれば、サーバー１１０９は、医療団体からの医師、インストラクター、学生、保険会社からの代理人、患者、医療調査員、等を表わすクライアント１１１３−１１１６に進歩型画像処理サービスを提供するように構成される。画像処理サーバーとも称されるクラウドサーバー１１０９は、１つ以上の医療画像及び医療画像に関連したデータをホストして、クライアント１１１３−１１１６のような複数の関係者が協力的に又は会議環境において画像の討論／処理フォーラムに参加できるようにする能力を有する。異なる関係者は、異なるステージ及び／又はレベルの討論セッション又は画像のワークフロープロセスに参加することができる。
【0133】
幾つかの実施形態によれば、データゲートウェイマネージャー１１０７は、医療団体のようなデータプロバイダー（例えば、ＰＡＣＳシステム）へ又はそこから医療データを自動的又は手動で転送するように構成される。そのようなデータゲートウェイ管理は、管理者又は許可された個人により構成されるルール又はポリシーのセットに基づいて遂行される。ある実施形態では、画像討論セッション又はクラウドで行われる画像処理動作の間に医療画像データの更新に応答して、データゲートウェイマネージャーは、ネットワーク（例えば、インターネット）を経て、更新された画像データ、又は更新された画像データとオリジナル画像データとの間の相違を、そのオリジナル医療画像データを与えたＰＡＣＳ１１０５のようなデータプロバイダーへ送信するように構成される。同様に、データゲートウェイマネージャー１１０７は、データプロバイダーから新たな画像及び／又は画像データを送信するように構成され、ここで、新たな画像は、エンティティ１１０１に関連した画像捕獲装置１１０４のような画像捕獲装置により捕獲されたものである。更に、データゲートウェイマネージャー１１０７は、同じエンティティ（例えば、医療インスティテュートの複数のファシリティ）に関連した複数のデータプロバイダーの間にデータを転送する。更に、クラウド１１０３は、クラウドシステムによって提供されるある進歩型画像処理リソースを使用して、受信画像のある前処理動作を自動的に遂行するために進歩型前処理システム（図示せず）を備えている。ある実施形態では、ゲートウェイマネージャー１１０７は、ポート８０又は４４３、等のあるインターネットポートを経てクラウド１１０３と通信するように構成される。転送されるデータは、種々の暗号及び圧縮方法を使用して暗号化及び／又は圧縮される。ここで、「インターネットポート」という語は、イントラネットポート、或いはイントラネットにおけるポート８０又は４４３等のプライベートポートでもある。
【0134】
図１２は、本発明の一実施形態に使用されるデータ処理システムのブロック図である。例えば、システム１２００は、上述したように、サーバー又はクライアントの一部分として使用される。例えば、システム１２００は、上述した医療情報サーバー１０１を表わし、これは、ネットワークインターフェイス１２１０を経てリモートクライアント装置又は別のサーバーに通信結合される。上述した少なくともＥＣＣＤエンジン５０１、医療画像処理システム５１０、及び医療データ統合器５０５は、システム１２００によりホストされる。
【0135】
図１２は、コンピュータシステムの種々のコンポーネントを示すが、それらのコンポーネントを相互接続する特定のアーキテクチャー又は方法を表すものではなく、そのような詳細は、本発明には関わりないことに注意されたい。又、より少数のコンポーネント又はおそらくより多くのコンポーネントを有するネットワークコンピュータ、ハンドヘルドコンピュータ、セルラーホン、及び他のデータ処理システムも、本発明に使用できることが明らかであろう。
【0136】
図１２に示すように、一形式のデータ処理システムであるコンピュータシステム１２００は、バス又は相互接続部１２０２を備え、これは、１つ以上のマイクロプロセッサ１２０３及びＲＯＭ１２０７、揮発性ＲＡＭ１２０５、及び不揮発性メモリ１２０６に結合される。マイクロプロセッサ１２０３は、キャッシュメモリ１２０４に結合される。バス１２０２は、それら種々のコンポーネントを一緒に相互接続すると共に、それらコンポーネント１２０３、１２０７、１２０５及び１２０６をディスプレイコントローラ及びディスプレイ装置１２０８に並びに入力／出力（Ｉ／Ｏ）装置１２１０に相互接続し、それらのＩ／Ｏ装置は、マウス、キーボード、モデム、ネットワークインターフェイス、プリンタ、及びこの分野で良く知られた他の装置である。
【0137】
典型的に、入力／出力装置１２１０は、入力／出力コントローラ１２０９を経てシステムに結合される。揮発性ＲＡＭ１２０５は、典型的に、メモリのデータをリフレッシュ又は維持するために電力を連続的に要求するダイナミックＲＡＭ（ＤＲＡＭ）として実施される。不揮発性メモリ１２０６は、典型的に、システムから電力を取り去った後もデータを維持する磁気ハードドライブ、磁気光学ドライブ、光学的装置、又はＤＶＤ ＲＡＭ、又は他の形式のメモリシステムである。又、典型的に、不揮発性メモリは、ランダムアクセスメモリであるが、これは、要求されない。
【0138】
図１２は、不揮発性メモリが、データ処理システムの残りのコンポーネントに直結されたローカル装置であることを示しているが、本発明は、システムから離れた不揮発性メモリ、例えば、モデム又はイーサネット（登録商標）インターフェイスのようなネットワークインターフェイスを通してデータ処理システムに結合されたネットワークストレージ装置を使用する。バス１２０２は、この分野で良く知られたように、種々のブリッジ、コントローラ及び／又はアダプタを通して互いに接続された１つ以上のバスを含む。ある実施形態では、Ｉ／Ｏコントローラ１２０９は、ＵＳＢ周辺機器を制御するためのＵＳＢ（ユニバーサルシリアルバス）アダプタを含む。或いは又、Ｉ／Ｏコントローラ１２０９は、ＦｉｒｅＷｉｒｅ装置を制御するためのＦｉｒｅＷｉｒｅアダプタとしても知られているＩＥＥＥ−１３９４アダプタを含む。
【0139】
以上の詳細な説明のある部分は、コンピュータメモリ内のデータビットに対する動作のアルゴリズム的及び記号表現に関して提示された。これらのアルゴリズム的説明及び表現は、データ処理分野の当業者が自分の仕事の実体を他の当業者に最も効果的に伝えるために使用される方法である。アルゴリズムとは、ここでは、一般的に、望ましい結果を導く動作の首尾一貫したシーケンスであると思われる。それらの動作は、物理的な量の物理的な操作を要求するものである。
【0140】
しかしながら、これら及び同様の用語は、全て、適切な物理的な量に関連付けられ、そしてそれらの量に適用される便利な表現に過ぎないことを銘記されたい。前記説明から明らかなように、特に指示のない限り、説明全体にわたって、請求の範囲に示すような用語を使用する討論は、コンピュータシステムのレジスタ及びメモリ内の物理的（電子的）な量として表わされたデータを、コンピュータシステムメモリ又はレジスタ或いは他のそのような情報ストレージ、送信又はディスプレイ装置内の物理的な量として同様に表わされた他のデータへと操作及び変換するコンピュータシステム又は同様の電子的コンピューティング装置のアクション及びプロセスを指すことが明らかである。
【0141】
図面に示された技術は、１つ以上の電子装置に記憶され及び実行されるコード及びデータを使用して実施される。そのような電子装置は、コンピュータ読み取り可能な媒体、例えば、非一時的なコンピュータ読み取り可能な記憶媒体（例えば、磁気ディスク、光学ディスク、ランダムアクセスメモリ、リードオンリメモリ、フラッシュメモリ装置、相変化メモリ）、並びに一時的なコンピュータ読み取り可能な送信媒体（例えば、電気的、光学的、音響的又は他の形態の伝播信号、例えば、搬送波、赤外線信号、デジタル信号）を使用して、コード及びデータを記憶及び通信する（内部的に及び／又はネットワークを経て他の電子装置と）。
【0142】
先の図面に示されたプロセス又は方法は、ハードウェア（例えば、回路、専用ロジック、等）、ファームウェア、ソフトウェア（例えば、非一時的なコンピュータ読み取り可能な媒体で実施される）、又はその両方の組み合わせを含む処理ロジックによって遂行される。プロセス又は方法は、ある順次の動作に関して上述したが、それら動作の幾つかは、異なる順序で遂行されてもよいことが明らかである。更に、ある動作は、順次ではなく、並列に遂行されてもよい。
【0143】
以上、特定の規範的実施形態を参照して本発明の実施形態を説明した。特許請求の範囲に記された本発明の精神及び範囲から逸脱せずに種々の変更がなされ得ることが明らかであろう。従って、明細書及び図面は、例示であって、それに限定されるものではない。
【符号の説明】
【0144】
１０１：医療情報サーバー１０２：クライアント
１０３：ＥＣＣＤエンジン
１０４：データコレクタ
１０５：データソース
５００：システム
５０１：ＥＣＣエンジン
５０２：ＥＣＣＤモデル／ルール
５０３：ユーザデータベース
５０４：ユーザデータコレクタ
５０５：医療データ統合器
５０６：ネットワーク
５０７、５０８：クライアントソフトウェアアプリケーション
５１０：医療画像処理システム
５１１：患者又は医療データ
５１３：医療画像
５２０：画像処理システム
６０１：ユーザ振舞い分析器
６０２：ルールエンジン
６０３：ＥＣＣＤルール／モデル
６０４：アルゴリズム
６１１：ユーザ好み
６１２：ユーザ好み
６２１：ユーザ双方向ヒストリー
６２２：ユーザ双方向ヒストリー
６３１：ＥＣＣＤルール／モデル
６３２：ＥＣＣＤルール／モデル
６３５：ユーザアクション
６３６：医療情報のビュー
７０１：データ検索モジュール
７０２：ビュージェネレータ
７０３：ユーザアクション分析モジュール
７０４：医療データＩ／Ｆモジュール１
１１０１：医療インスティテュート
１１０２：医療インスティテュート
１１０３：クラウド
１１０４：画像捕獲装置
１１０５：ＰＡＣＳ
１１０６：ルーター
１１０７：ゲートウェイマネージャー
１１０８：ワークステーション
１１０９：サーバー
１１１０：データストア
１１１２：ルーター
１１１３：タブレット
１１１４：移動装置
１１１５：デスクトップ
１１１６：ラップトップ
１２０２：バス
１２０３：マイクロプロセッサ
１２０４：キャッシュ
１２０５：揮発性ＲＡＭ
１２０６：不揮発性メモリ
１２０７：ＲＯＭ
１２０８：ディスプレイコントローラ＆ディスプレイ装置
１２０９：Ｉ／Ｏコントローラ
１２１０：Ｉ／Ｏ装置