特許 7046240 医療撮像および医療撮像情報の効率的共有

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-03-24

(45)【発行日】2022-04-01

(54)【発明の名称】医療撮像および医療撮像情報の効率的共有

(51)【国際特許分類】

   G16H 30/20 20180101AFI20220325BHJP

   A61B 5/055 20060101ALI20220325BHJP

   G06F 21/62 20130101ALI20220325BHJP

【ＦＩ】

G16H30/20

A61B5/055 382

G06F21/62 345

【請求項の数】 25

(21)【出願番号】P 2021007182

(22)【出願日】2021-01-20

(62)【分割の表示】P 2018527787の分割

【原出願日】2016-11-29

(65)【公開番号】P2021077389

(43)【公開日】2021-05-20

【審査請求日】2021-01-20

(31)【優先権主張番号】62/260,565

(32)【優先日】2015-11-29

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/415,203

(32)【優先日】2016-10-31

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】516215925

【氏名又は名称】アーテリーズ インコーポレイテッド

(74)【代理人】

【識別番号】110001243

【氏名又は名称】特許業務法人 谷・阿部特許事務所

(72)【発明者】

【氏名】カイル ドーマー

(72)【発明者】

【氏名】フセイン パトニ

(72)【発明者】

【氏名】ダリル ビドゥロック

(72)【発明者】

【氏名】ジョン アクセリオ－シリーズ

(72)【発明者】

【氏名】トリン アルニ ターラム

【審査官】伊知地 和之

(56)【参考文献】

【文献】特表２００７－５３１１２４（ＪＰ，Ａ）

【文献】特表２０１５－５３３４３７（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１５／０２４４６８７（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１５／０２１３４５８（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１４／０２４４３０５（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１５／０２２３０５７（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１５／０１４９２０８（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１１／０１５３３５１（ＵＳ，Ａ１）

【文献】米国特許出願公開第２００６／０２４２１５９（ＵＳ，Ａ１）

【文献】米国特許第９１１８６４１（ＵＳ，Ｂ１）

【文献】国際公開第２０１５／１２３５４０（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ａ６１Ｂ ５／００ － ５／０１

Ａ６１Ｂ ５／０５５

Ａ６１Ｂ ６／００ － ６／１４

Ｇ１６Ｈ １０／００ － １０／６５

Ｇ１６Ｈ ３０／００ － ３０／４０

Ｇ０６Ｆ ２１／６２

(57)【特許請求の範囲】

【請求項1】

医療分析学プラットフォームの分析学サービスプロバイダ（ＡＳＰ）システムであって、前記医療分析学プラットフォームは前記ＡＳＰシステムおよび被保護健康情報（ＰＨＩ）システムを備え、前記ＰＨＩシステムは、非識別化された医療スタディデータに関連付けられたＰＨＩデータを、前記ＰＨＩシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶する、当該ＡＳＰシステムは、
プロセッサ実行可能命令またはデータのうちの少なくとも１つを記憶する少なくとも１つの非一時的プロセッサ可読記憶媒体と、
前記少なくとも１つの非一時的プロセッサ可読記憶媒体に伝達可能に結合された少なくとも１つのプロセッサと
を備え、動作中、前記少なくとも１つのプロセッサは、
前記非識別化された医療スタディデータを、前記少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶し、
クライアントプロセッサベースデバイスによって前記少なくとも１つの通信ネットワーク上で前記ＰＨＩシステムから受信されたＰＨＩデータと前記クライアントプロセッサベースデバイスによってマージされるように、要求された医療スタディについての非識別化された医療スタディデータを、少なくとも１つの通信ネットワーク上で前記クライアントプロセッサベースデバイスに送り、
前記非識別化された医療スタディデータに関する分析学データを生成し、
前記生成された分析学データを、前記少なくとも１つの通信ネットワーク上で前記ＰＨＩシステムに送る
ことを特徴とするＡＳＰシステム。

【請求項2】

前記少なくとも１つのプロセッサは、
ＰＨＩアクセストークンについての要求を、少なくとも１つの通信ネットワーク上で前記クライアントプロセッサベースデバイスから受信し、
暗号化されたＰＨＩアクセストークンを、前記少なくとも１つの通信ネットワーク上で前記クライアントプロセッサベースデバイスに送り、
前記暗号化されたＰＨＩアクセストークンを、前記少なくとも１つの通信ネットワーク上で前記ＰＨＩシステムから受信し、
前記受信された、暗号化されたＰＨＩアクセストークンを有効性確認し、
前記少なくとも１つの通信ネットワーク上で、前記ＰＨＩアクセストークンが有効であることを前記ＰＨＩシステムに通知する
ことを特徴とする請求項１に記載のＡＳＰシステム。

【請求項3】

前記少なくとも１つのプロセッサは、
前記非識別化された医療スタディデータを、前記少なくとも１つの通信ネットワーク上で前記ＰＨＩシステムから受信することを特徴とする請求項１に記載のＡＳＰシステム。

【請求項4】

前記少なくとも１つのプロセッサは、
分析学データを生成するための要求を、前記少なくとも１つの通信ネットワーク上で前記クライアントプロセッサベースデバイスから受信し、
前記少なくとも１つのプロセッサは、前記クライアントプロセッサベースデバイスからの、分析学データを生成するための前記要求の受信に応答して、前記分析学データを生成することを特徴とする請求項１に記載のＡＳＰシステム。

【請求項5】

前記分析学データはレポートまたは２次キャプチャオブジェクトのうちの少なくとも１つを備え、前記少なくとも１つのプロセッサは、
前記レポートまたは前記２次キャプチャオブジェクトのうちの前記少なくとも１つを、前記ＰＨＩシステムと通信可能に結合された少なくとも１つの非一時的プロセッサ可読記憶媒体上での記憶のために、前記少なくとも１つの通信ネットワーク上で前記ＰＨＩシステムに送ることを特徴とする請求項１に記載のＡＳＰシステム。

【請求項6】

前記少なくとも１つのプロセッサは、
更新についてのチェックを、前記少なくとも１つの通信ネットワーク上で前記ＰＨＩシステムから定期的に受信し、
前記ＰＨＩシステムに対する何らかの更新が必要とされるかどうかを決定し、
前記ＰＨＩシステムの少なくとも１つの更新が必要とされるという決定に応答して、更新データを、前記少なくとも１つの通信ネットワーク上で前記ＰＨＩシステムに送る
ことを特徴とする請求項１に記載のＡＳＰシステム。

【請求項7】

医療分析学プラットフォームの被保護健康情報（ＰＨＩ）システムを操作する方法であって、前記医療分析学プラットフォームは前記ＰＨＩシステムおよび分析学サービスプロバイダ（ＡＳＰ）システムを備え、前記ＡＳＰシステムは、非識別化された医療スタディデータを、前記ＡＳＰシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶する、当該方法は、
前記ＰＨＩシステムの少なくとも１つのプロセッサによって、前記ＰＨＩシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体上に、前記非識別化された医療スタディデータに関連付けられたＰＨＩデータを記憶するステップと、
前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、前記医療スタディ用のＰＨＩデータについての要求を、クライアントプロセッサベースデバイスから受信するステップであって、前記要求は暗号化されたＰＨＩアクセストークンを含む、該ステップと、
前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、前記少なくとも１つの通信ネットワーク上で、前記暗号化されたＰＨＩアクセストークンを有効性確認のために前記ＡＳＰシステムに送るステップと、
前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、前記ＰＨＩアクセストークンが有効であるという通知を前記ＡＳＰシステムから受信するステップと、
前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、前記クライアントプロセッサベースデバイスによって前記少なくとも１つの通信ネットワーク上で前記ＡＳＰシステムから受信された非識別化された医療スタディデータと前記クライアントプロセッサベースデバイスによってマージされるように、要求された医療スタディ用のＰＨＩデータを、少なくとも１つの通信ネットワーク上で前記クライアントプロセッサベースデバイスに送るステップと
を備えたことを特徴とする方法。

【請求項8】

前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、ＰＨＩデータを含む医療スタディデータを受信するステップと、
前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、前記医療スタディデータから前記ＰＨＩデータを削除して、非識別化された医療スタディデータを生成するステップと、
前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、前記ＰＨＩシステムの前記少なくとも１つの非一時的プロセッサ可読記憶媒体中に前記ＰＨＩデータを記憶するステップと、
前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、前記少なくとも１つの通信ネットワーク上で、前記非識別化された医療スタディデータを前記ＡＳＰシステムに送るステップと
をさらに備えたことを特徴とする請求項７に記載の方法。

【請求項9】

ＰＨＩデータを含む医療スタディデータを受信するステップは、スキャナから医療撮像データを受信するステップを備えたことを特徴とする請求項８に記載の方法。

【請求項10】

前記非識別化された医療スタディデータを前記ＡＳＰシステムに送るステップは、表現状態転送（ＲＥＳＴ）アプリケーションプログラミングインタフェースを使って、前記非識別化された医療スタディデータを前記ＡＳＰシステムに送るステップを備えたことを特徴とする請求項８に記載の方法。

【請求項11】

前記医療スタディデータから前記ＰＨＩデータを削除するステップは、
前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、消去されることが許されるフィールドを削除するステップと、
前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、消去されることが許されないフィールド中のデータを、不明瞭化された置換えデータと置き換えるステップと
を備えたことを特徴とする請求項８に記載の方法。

【請求項12】

前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、医療スタディについての前記医療スタディデータに一意の識別子を関連付けるステップと、
前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、前記ＰＨＩシステムの前記少なくとも１つの非一時的プロセッサ可読記憶媒体中に前記一意の識別子を記憶するステップと、
前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、前記医療スタディについての前記非識別化された医療データとともに前記一意の識別子を、前記少なくとも１つの通信ネットワーク上で前記ＡＳＰシステムに送るステップと
をさらに備えたことを特徴とする請求項８に記載の方法。

【請求項13】

前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、前記非識別化された医療スタディデータに関する分析学データを、前記少なくとも１つの通信ネットワーク上で前記ＡＳＰシステムから受信するステップと、
前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、前記受信された分析学データを、前記ＰＨＩシステムと通信可能に結合された少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶するステップと
をさらに備えたことを特徴とする請求項７に記載の方法。

【請求項14】

前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、前記少なくとも１つの通信ネットワーク上で前記クライアントプロセッサベースデバイスに、利用可能スタディのリストを提供するステップと、
前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、前記リスト中の前記利用可能スタディのうちの少なくとも１つのスタディの選択を、前記少なくとも１つの通信ネットワーク上で前記クライアントプロセッサベースデバイスから受信するステップと
をさらに備えたことを特徴とする請求項７に記載の方法。

【請求項15】

前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、更新についてのチェックを、前記少なくとも１つの通信ネットワーク上で前記ＡＳＰシステムに定期的に送るステップと、
前記ＰＨＩシステムの前記少なくとも１つのプロセッサによって、更新データを、前記少なくとも１つの通信ネットワーク上で前記ＡＳＰシステムから受信するステップと
をさらに備えたことを特徴とする請求項７に記載の方法。

【請求項16】

前記クライアントプロセッサベースデバイスの少なくとも１つのプロセッサによって、前記少なくとも１つの通信ネットワーク上で前記ＰＨＩシステムから前記ＰＨＩデータを受信するステップと、
前記クライアントプロセッサベースデバイスの前記少なくとも１つのプロセッサによって、前記少なくとも１つの通信ネットワーク上で前記ＡＳＰシステムから、前記非識別化された医療スタディデータを受信するステップと、
前記クライアントプロセッサベースデバイスの前記少なくとも１つのプロセッサによって、前記ＰＨＩデータと前記非識別化された医療スタディデータをマージして、再識別された医療スタディデータを生成するステップと、
前記クライアントプロセッサベースデバイスの前記少なくとも１つのプロセッサによって、前記再識別された医療スタディデータを前記クライアントプロセッサベースデバイスのユーザに提示するステップと
をさらに備えたことを特徴とする請求項７に記載の方法。

【請求項17】

医療分析学プラットフォームの被保護健康情報（ＰＨＩ）システムであって、前記医療分析学プラットフォームは前記ＰＨＩシステムおよび分析学サービスプロバイダ（ＡＳＰ）システムを備え、前記ＡＳＰシステムは、非識別化された医療スタディデータを、前記ＡＳＰシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶する、当該ＰＨＩシステムは、
プロセッサ実行可能命令またはデータのうちの少なくとも１つを記憶する少なくとも１つの非一時的プロセッサ可読記憶媒体と、
前記少なくとも１つの非一時的プロセッサ可読記憶媒体に伝達可能に結合された少なくとも１つのプロセッサと
を備え、動作中、前記少なくとも１つのプロセッサは、
前記非識別化された医療スタディデータに関連付けられたＰＨＩデータを、前記ＰＨＩシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶し、
前記医療スタディ用のＰＨＩデータについての要求を、クライアントプロセッサベースデバイスから受信し、前記要求は暗号化されたＰＨＩアクセストークンを含み、
前記暗号化されたＰＨＩアクセストークンを有効性確認のために、前記少なくとも１つの通信ネットワーク上で前記ＡＳＰシステムに送り、
前記ＰＨＩアクセストークンが有効であるという通知を、前記ＡＳＰシステムから受信し、
前記クライアントプロセッサベースデバイスによって前記少なくとも１つの通信ネットワーク上で前記ＡＳＰシステムから受信された非識別化された医療スタディデータと前記クライアントプロセッサベースデバイスによってマージされるように、要求された医療スタディ用のＰＨＩデータを、少なくとも１つの通信ネットワーク上で前記クライアントプロセッサベースデバイスに送ることとを行う
ことを特徴とするＰＨＩシステム。

【請求項18】

前記少なくとも１つのプロセッサは、
ＰＨＩデータを含む医療スタディデータを受信し、
前記医療スタディデータから前記ＰＨＩデータを削除して、非識別化された医療スタディデータを生成し、
前記ＰＨＩシステムの前記少なくとも１つの非一時的プロセッサ可読記憶媒体中に、前記ＰＨＩデータを記憶し、
前記非識別化された医療スタディデータを、前記少なくとも１つの通信ネットワーク上で前記ＡＳＰシステムに送る
ことを特徴とする請求項１７に記載のＰＨＩシステム。

【請求項19】

前記医療スタディデータは、スキャナからの医療撮像データを備えたことを特徴とする請求項１８に記載のＰＨＩシステム。

【請求項20】

前記少なくとも１つのプロセッサは、表現状態転送（ＲＥＳＴ）アプリケーションプログラミングインタフェースを使用して、非識別化された医療スタディデータを前記ＡＳＰシステムに送ることを特徴とする請求項１８に記載のＰＨＩシステム。

【請求項21】

前記少なくとも１つのプロセッサは、
消去されることが許される前記医療スタディデータのフィールドを削除し、
消去されることが許されない前記医療スタディデータのフィールド中のデータを、不明瞭化された置換えデータと置き換える
ことを特徴とする請求項１８に記載のＰＨＩシステム。

【請求項22】

前記少なくとも１つのプロセッサは、
医療スタディについての前記医療スタディデータに一意の識別子を関連付け、
前記ＰＨＩシステムの前記少なくとも１つの非一時的プロセッサ可読記憶媒体中に前記一意の識別子を記憶し、
前記医療スタディについての前記非識別化された医療データとともに前記一意の識別子を、前記少なくとも１つの通信ネットワーク上で前記ＡＳＰシステムに送る
ことを特徴とする請求項１８に記載のＰＨＩシステム。

【請求項23】

前記少なくとも１つのプロセッサは、
前記非識別化された医療スタディデータに関する分析学データを、前記少なくとも１つの通信ネットワーク上で前記ＡＳＰシステムから受信し、
前記受信された分析学データを、前記ＰＨＩシステムと通信可能に結合された少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶する
ことを特徴とする請求項１７に記載のＰＨＩシステム。

【請求項24】

前記少なくとも１つのプロセッサは、
利用可能スタディのリストを、前記少なくとも１つの通信ネットワーク上で前記クライアントプロセッサベースデバイスに提供し、
前記リスト中の前記利用可能スタディのうちの少なくとも１つのスタディの選択を、前記少なくとも１つの通信ネットワーク上で前記クライアントプロセッサベースデバイスから受信する
ことを特徴とする請求項１７に記載のＰＨＩシステム。

【請求項25】

前記少なくとも１つのプロセッサは、
更新についてのチェックを、前記少なくとも１つの通信ネットワーク上で前記ＡＳＰシステムに定期的に送り、
更新データを、前記少なくとも１つの通信ネットワーク上で前記ＡＳＰシステムから受信する
ことを特徴とする請求項１７に記載のＰＨＩシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は概して、磁気共鳴撮像（ＭＲＩ）、たとえば４次元（４－Ｄ）フローＭＲＩ、ならびに通信ネットワークまたはチャネル上での医療撮像と他の情報との共有に関する。

【背景技術】

【0002】

ＭＲＩは、医療撮像において最も一般的に利用されるが、他の分野において使われる場合がある。ＭＲＩマシンは、典型的には、中心または長手方向ボアを有するコイルの環状アレイである主磁石を含む。主磁石は、強安定磁界（たとえば、０．５テスラないし３．０テスラ）を生じることが可能である。ボアは、撮像されるべきオブジェクト、たとえば人体の少なくとも一部分を受信するようなサイズである。医療撮像アプリケーションにおいて使われるとき、ＭＲＩマシンは、うつ伏せの患者がボアの中に、およびその外へ容易にスライドまたは回転されることを可能にする患者台を含むことができる。

【0003】

ＭＲＩマシンは、勾配磁石も含む。勾配磁石は、主磁石によって生じられたもの（たとえば、１８０ガウスないし２７０ガウス）よりも比較的小さい変動磁界を生じ、オブジェクト（たとえば、患者）の選択された部分が撮像されることを可能にする。ＭＲＩマシンは、撮像されるべきオブジェクト（たとえば、患者）の選択された部分に無線周波エネルギーを印加するように操作される無線周波数（ＲＦ）コイルも含む。異なる構造（たとえば、解剖構造）を撮像するために、異なるＲＦコイルが使われてよい。たとえば、ＲＦコイルのあるセットは、患者の首を撮像するのに適している場合があり、ＲＦコイルの別のセットは、患者の胸部または心臓を撮像するのに適している場合がある。ＭＲＩマシンは一般的に、追加磁石、たとえば抵抗磁石および／または永久磁石を含む。

【0004】

ＭＲＩマシンは典型的には、磁石および／もしくはコイルを制御するのに、ならびに／または撮像されるオブジェクトの部分の画像を生じるための画像処理を実施するのに使われるコンピュータシステムを含むか、または通信可能に結合される。従来、ＭＲＩマシンは、物理的構造、たとえば、解剖学的構造を表すマグニチュードデータセットを生じる。データセットはしばしば、医療におけるデジタル撮像および通信（ＤＩＣＯＭ：Digital Imaging and Communications in Medicine）規格に準拠する。ＤＩＣＯＭファイルは典型的には、規定されたフォーマットでのピクセルデータおよびメタデータを含む。

【先行技術文献】

【特許文献】

【0005】

【文献】米国特許仮出願第６１／５７１，９０８号明細書

【文献】国際特許出願第ＰＣＴ／ＵＳ２０１２／０４５５７５号明細書

【文献】米国特許仮出願第６１／９２８，７０２号明細書

【文献】国際特許出願第ＰＣＴ／ＵＳ２０１５／０１１８５１号明細書

【文献】米国特許出願第１５／１１２１３０号明細書

【文献】米国特許仮出願第６２／２６０，５６５号明細書

【文献】米国特許仮出願第６２／４１５，２０３号明細書

【文献】米国特許仮出願第６２／４１５，６６６号明細書

【発明の概要】

【課題を解決するための手段】

【0006】

医療分析学プラットフォームを操作する方法であって、医療分析学プラットフォームは、分析学サービスプロバイダ（ＡＳＰ）システムおよび被保護健康情報（ＰＨＩ）システムを含み、方法は、ＡＳＰシステムの少なくとも１つのプロセッサによって、ＡＳＰシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体上に、非識別化された医療スタディデータを記憶することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、ＰＨＩシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体上に、非識別化された医療スタディデータに関連付けられたＰＨＩデータを記憶することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上で、要求された医療スタディ用のＰＨＩデータをクライアントプロセッサベースデバイスに対して送ることと、ＡＳＰシステムの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上で、要求された医療スタディについての非識別化された医療スタディデータをクライアントプロセッサベースデバイスに対して送ることとを含むものとして要約されてよい。

【0007】

ＰＨＩシステムは、プライベートネットワークに通信可能に結合されてよく、方法は、ＡＳＰシステムの少なくとも１つのプロセッサまたはＰＨＩシステムの少なくとも１つのプロセッサによって、クライアントプロセッサベースデバイスがプライベートネットワークへのアクセスを有することを検証することをさらに含むことができる。方法は、ＡＳＰシステムの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上で、クライアントプロセッサベースデバイスからＰＨＩアクセストークンについての要求を受信することと、ＡＳＰシステムの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上で、クライアントプロセッサベースデバイスに対して、暗号化されたＰＨＩアクセストークンを送ることと、ＰＨＩシステムの少なくとも１つのプロセッサによって、医療スタディ用のＰＨＩデータについての要求をクライアントプロセッサベースデバイスから受信することであって、要求は、暗号化されたＰＨＩアクセストークンを含む、受信することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上で、暗号化されたＰＨＩアクセストークンをＡＳＰシステムに対して送ることと、ＡＳＰシステムの少なくとも１つのプロセッサによって、受信された、暗号化されたＰＨＩアクセストークンを有効性確認することと、ＡＳＰシステムの少なくとも１つのプロセッサによって、ＰＨＩアクセストークンが有効であることをＰＨＩシステムに通知することとをさらに含むことができ、要求されたＰＨＩデータをクライアントプロセッサベースデバイスに対して送ることは、ＰＨＩシステムの少なくとも１つのプロセッサがＡＳＰシステムから有効性確認通知を受信したことに応答してよい。方法は、ＰＨＩシステムの少なくとも１つのプロセッサによって、ＰＨＩデータを含む医療スタディデータを受信することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、医療スタディデータからＰＨＩデータを削除して、非識別化された医療スタディデータを生成することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、ＰＨＩシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体中にＰＨＩデータを記憶することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上で、非識別化された医療スタディデータをＡＳＰシステムに対して送ることとをさらに含むことができる。ＰＨＩデータを含む医療スタディデータを受信することは、スキャナから医療撮像データを受信することを含むことができる。非識別化された医療スタディデータをＡＳＰシステムに対して送ることは、表現状態転送（ＲＥＳＴ）アプリケーションプログラミングインタフェースを使って、非識別化された医療スタディデータをＡＳＰシステムに対して送ることを含むことができる。医療スタディデータからＰＨＩデータを削除することは、ＰＨＩシステムの少なくとも１つのプロセッサによって、消去されることが許されるフィールドを削除することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、消去されることが許されないフィールド中のデータを、不明瞭化された置換えデータと置き換えることとを含むことができる。方法は、ＰＨＩシステムの少なくとも１つのプロセッサによって、医療スタディについての医療スタディデータに一意の識別子を関連付けることと、ＰＨＩシステムの少なくとも１つのプロセッサによって、ＰＨＩシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体中に一意の識別子を記憶することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、医療スタディについての非識別化された医療データとともに一意の識別子を、少なくとも１つの通信ネットワーク上でＡＳＰシステムに対して送ることとをさらに含むことができる。方法は、クライアントプロセッサベースデバイスの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上でＰＨＩシステムからＰＨＩデータを受信することと、クライアントプロセッサベースデバイスの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上でＡＳＰシステムから、非識別化された医療スタディデータを受信することと、クライアントプロセッサベースデバイスの少なくとも１つのプロセッサによって、ＰＨＩデータと非識別化された医療スタディデータとをマージ（ｍｅｒｇｅ）して、再識別された医療スタディデータを生成することと、クライアントプロセッサベースデバイスの少なくとも１つのプロセッサによって、再識別された医療スタディデータをクライアントプロセッサベースデバイスのユーザに提示することとをさらに含むことができる。方法は、ＡＳＰシステムの少なくとも１つのプロセッサによって、非識別化された医療スタディデータに関する分析学データを生成することと、ＡＳＰシステムの少なくとも１つのプロセッサによって、生成された分析学データを、少なくとも１つの通信ネットワーク上でＰＨＩシステムに対して送ることとをさらに含むことができる。方法は、ＡＳＰシステムの少なくとも１つのプロセッサによって、分析学データを生成するための要求を、少なくとも１つの通信ネットワーク上でクライアントプロセッサベースデバイスから受信することをさらに含むことができ、分析学データを生成することは、分析学データを生成するための要求をクライアントプロセッサベースデバイスから受信したことに応答してよい。分析学データを生成することは、レポートまたは２次キャプチャオブジェクトのうちの少なくとも１つを生成することを含むことができ、生成された分析学データをＰＨＩシステムに対して送ることは、レポートまたは２次キャプチャオブジェクトのうちの少なくとも１つを、ＰＨＩシステムと通信可能に結合された少なくとも１つの非一時的プロセッサ可読記憶媒体上での記憶のために、少なくとも１つの通信ネットワーク上でＰＨＩシステムに対して送ることを含むことができる。方法は、ＰＨＩシステムの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上でクライアントプロセッサベースデバイスに、利用可能スタディのリストを提供することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、リスト中の利用可能スタディのうちの少なくとも１つのスタディの選択を、少なくとも１つの通信ネットワーク上でクライアントプロセッサベースデバイスから受信することとをさらに含むことができる。方法は、ＰＨＩシステムの少なくとも１つのプロセッサによって、更新についてのチェックを、少なくとも１つの通信ネットワーク上でＡＳＰシステムに対して定期的に送ることと、ＡＳＰシステムの少なくとも１つのプロセッサによって、ＰＨＩシステムに対する何らかの更新が必要とされるかどうかを決定することと、ＰＨＩシステムの少なくとも１つの更新が必要とされると決定したことに応答して、ＡＳＰの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上でＰＨＩシステムに対して更新データを送ることとをさらに含むことができる。

【0008】

医療分析学プラットフォームの分析学サービスプロバイダ（ＡＳＰ）システムを操作する方法であって、医療分析学プラットフォームはＡＳＰシステムおよび被保護健康情報（ＰＨＩ）システムを含み、ＰＨＩシステムは、非識別化された医療スタディデータに関連付けられたＰＨＩデータをＰＨＩシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶し、方法は、ＡＳＰシステムの少なくとも１つのプロセッサによって、非識別化された医療スタディデータを、ＡＳＰシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶することと、ＡＳＰシステムの少なくとも１つのプロセッサによって、クライアントプロセッサベースデバイスによって少なくとも１つの通信ネットワーク上でＰＨＩシステムから受信されたＰＨＩデータとクライアントプロセッサベースデバイスによってマージされるように、要求された医療スタディについての非識別化された医療スタディデータを、少なくとも１つの通信ネットワーク上でクライアントプロセッサベースデバイスに対して送ることとを含むものとして要約されてよい。

【0009】

方法は、ＡＳＰシステムの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上で、クライアントプロセッサベースデバイスからＰＨＩアクセストークンについての要求を受信することと、ＡＳＰシステムの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上で、クライアントプロセッサベースデバイスに対して、暗号化されたＰＨＩアクセストークンを送ることと、ＡＳＰシステムの少なくとも１つのプロセッサによって、暗号化されたＰＨＩアクセストークンを、少なくとも１つの通信ネットワーク上でＰＨＩシステムから受信することと、ＡＳＰシステムの少なくとも１つのプロセッサによって、受信された、暗号化されたＰＨＩアクセストークンを有効性確認することと、ＡＳＰシステムの少なくとも１つのプロセッサによって、ＰＨＩアクセストークンが有効であることをＰＨＩシステムに通知することとをさらに含むことができる。方法は、ＡＳＰシステムの少なくとも１つのプロセッサによって、非識別化された医療スタディデータを、少なくとも１つの通信ネットワーク上でＰＨＩシステムから受信することをさらに含むことができる。方法は、ＡＳＰシステムの少なくとも１つのプロセッサによって、非識別化された医療スタディデータに関する分析学データを生成することと、ＡＳＰシステムの少なくとも１つのプロセッサによって、生成された分析学データを、少なくとも１つの通信ネットワーク上でＰＨＩシステムに対して送ることとをさらに含むことができる。方法は、ＡＳＰシステムの少なくとも１つのプロセッサによって、分析学データを生成するための要求を、少なくとも１つの通信ネットワーク上でクライアントプロセッサベースデバイスから受信することをさらに含むことができ、分析学データを生成することは、分析学データを生成するための要求をクライアントプロセッサベースデバイスから受信したことに応答してよい。分析学データを生成することは、レポートまたは２次キャプチャオブジェクトのうちの少なくとも１つを生成することを含むことができ、生成された分析学データをＰＨＩシステムに対して送ることは、レポートまたは２次キャプチャオブジェクトのうちの少なくとも１つを、ＰＨＩシステムと通信可能に結合された少なくとも１つの非一時的プロセッサ可読記憶媒体上での記憶のために、少なくとも１つの通信ネットワーク上でＰＨＩシステムに対して送ることを含むことができる。方法は、ＡＳＰシステムの少なくとも１つのプロセッサによって、更新についてのチェックを、少なくとも１つの通信ネットワーク上でＰＨＩシステムから定期的に受信することと、ＡＳＰシステムの少なくとも１つのプロセッサによって、ＰＨＩシステムに対する何らかの更新が必要とされるかどうかを決定することと、ＰＨＩシステムの少なくとも１つの更新が必要とされると決定したことに応答して、ＡＳＰの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上でＰＨＩシステムに対して更新データを送ることとをさらに含むことができる。方法は、クライアントプロセッサベースデバイスの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上でＰＨＩシステムからＰＨＩデータを受信することと、クライアントプロセッサベースデバイスの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上でＡＳＰシステムから、非識別化された医療スタディデータを受信することと、クライアントプロセッサベースデバイスの少なくとも１つのプロセッサによって、ＰＨＩデータと非識別化された医療スタディデータとをマージして、再識別された医療スタディデータを生成することと、クライアントプロセッサベースデバイスの少なくとも１つのプロセッサによって、再識別された医療スタディデータをクライアントプロセッサベースデバイスのユーザに提示することとをさらに含むことができる。

【0010】

医療分析学プラットフォームの分析学サービスプロバイダ（ＡＳＰ）システムであって、医療分析学プラットフォームは、ＡＳＰシステムおよび被保護健康情報（ＰＨＩ）システムを含み、ＰＨＩシステムは、非識別化された医療スタディデータに関連付けられたＰＨＩデータを、ＰＨＩシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶し、ＡＳＰシステムは、プロセッサ実行可能命令またはデータのうちの少なくとも１つを記憶する少なくとも１つの非一時的プロセッサ可読記憶媒体と、少なくとも１つの非一時的プロセッサ可読記憶媒体に伝達可能に結合された少なくとも１つのプロセッサとを含むものとして要約されてよく、動作中、少なくとも１つのプロセッサは、非識別化された医療スタディデータを、少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶することと、クライアントプロセッサベースデバイスによって少なくとも１つの通信ネットワーク上でＰＨＩシステムから受信されたＰＨＩデータとクライアントプロセッサベースデバイスによってマージされるように、要求された医療スタディについての非識別化された医療スタディデータを、少なくとも１つの通信ネットワーク上でクライアントプロセッサベースデバイスに対して送ることとを行う。

【0011】

少なくとも１つのプロセッサは、ＰＨＩアクセストークンについての要求を、少なくとも１つの通信ネットワーク上でクライアントプロセッサベースデバイスから受信することと、暗号化されたＰＨＩアクセストークンを、少なくとも１つの通信ネットワーク上でクライアントプロセッサベースデバイスに対して送ることと、暗号化されたＰＨＩアクセストークンを、少なくとも１つの通信ネットワーク上でＰＨＩシステムから受信することと、受信された、暗号化されたＰＨＩアクセストークンを有効性確認することと、少なくとも１つの通信ネットワーク上で、ＰＨＩアクセストークンが有効であることをＰＨＩシステムに通知することとができる。少なくとも１つのプロセッサは、非識別化された医療スタディデータを、少なくとも１つの通信ネットワーク上でＰＨＩシステムから受信することができる。少なくとも１つのプロセッサは、非識別化された医療スタディデータに関する分析学データを生成することと、生成された分析学データを、少なくとも１つの通信ネットワーク上でＰＨＩシステムに対して送ることとができる。少なくとも１つのプロセッサは、分析学データを生成するための要求を、少なくとも１つの通信ネットワーク上でクライアントプロセッサベースデバイスから受信することができ、少なくとも１つのプロセッサは、クライアントプロセッサベースデバイスからの、分析学データを生成するための要求の受信に応答して、分析学データを生成することができる。分析学データは、レポートまたは２次キャプチャオブジェクトのうちの少なくとも１つを含むことができ、少なくとも１つのプロセッサは、レポートまたは２次キャプチャオブジェクトのうちの少なくとも１つを、ＰＨＩシステムと通信可能に結合された少なくとも１つの非一時的プロセッサ可読記憶媒体上での記憶のために、少なくとも１つの通信ネットワーク上でＰＨＩシステムに対して送ることができる。少なくとも１つのプロセッサは、更新についてのチェックを、少なくとも１つの通信ネットワーク上でＰＨＩシステムから定期的に受信することと、ＰＨＩシステムに対する何らかの更新が必要とされるかどうかを決定することと、ＰＨＩシステムの少なくとも１つの更新が必要とされるという決定に応答して、更新データを、少なくとも１つの通信ネットワーク上でＰＨＩシステムに対して送ることとができる。

【0012】

医療分析学プラットフォームの被保護健康情報（ＰＨＩ）システムを操作する方法であって、医療分析学プラットフォームは、ＰＨＩシステムおよび分析学サービスプロバイダ（ＡＳＰ）システムを含み、ＡＳＰシステムは、非識別化された医療スタディデータを、ＡＳＰシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶し、方法は、ＰＨＩシステムの少なくとも１つのプロセッサによって、ＰＨＩシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体上に、非識別化された医療スタディデータに関連付けられたＰＨＩデータを記憶することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上で、クライアントプロセッサベースデバイスによって少なくとも１つの通信ネットワーク上でＡＳＰシステムから受信された非識別化された医療スタディデータとクライアントプロセッサベースデバイスによってマージされるように、要求された医療スタディ用のＰＨＩデータを、クライアントプロセッサベースデバイスに対して送ることとを含むものとして要約されてよい。

【0013】

方法は、ＰＨＩシステムの少なくとも１つのプロセッサによって、医療スタディ用のＰＨＩデータについての要求を、クライアントプロセッサベースデバイスから受信することであって、要求は暗号化されたＰＨＩアクセストークンを含む、受信することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上で、暗号化されたＰＨＩアクセストークンを有効性確認のためにＡＳＰシステムに対して送ることと、ＰＨＩシステムの少なくとも１つのプロセッサによって、ＰＨＩアクセストークンが有効であるという通知をＡＳＰシステムから受信することとをさらに含むことができる。方法は、ＰＨＩシステムの少なくとも１つのプロセッサによって、ＰＨＩデータを含む医療スタディデータを受信することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、医療スタディデータからＰＨＩデータを削除して、非識別化された医療スタディデータを生成することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、ＰＨＩシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体中にＰＨＩデータを記憶することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上で、非識別化された医療スタディデータをＡＳＰシステムに対して送ることとをさらに含むことができる。ＰＨＩデータを含む医療スタディデータを受信することは、スキャナから医療撮像データを受信することを含むことができる。非識別化された医療スタディデータをＡＳＰシステムに対して送ることは、表現状態転送（ＲＥＳＴ）アプリケーションプログラミングインタフェースを使って、非識別化された医療スタディデータをＡＳＰシステムに対して送ることを含むことができる。医療スタディデータからＰＨＩデータを削除することは、ＰＨＩシステムの少なくとも１つのプロセッサによって、消去されることが許されるフィールドを削除することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、消去されることが許されないフィールド中のデータを、不明瞭化された置換えデータと置き換えることとを含むことができる。方法は、ＰＨＩシステムの少なくとも１つのプロセッサによって、医療スタディについての医療スタディデータに一意の識別子を関連付けることと、ＰＨＩシステムの少なくとも１つのプロセッサによって、ＰＨＩシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体中に一意の識別子を記憶することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、医療スタディについての非識別化された医療データとともに一意の識別子を、少なくとも１つの通信ネットワーク上でＡＳＰシステムに対して送ることとをさらに含むことができる。方法は、ＰＨＩシステムの少なくとも１つのプロセッサによって、非識別化された医療スタディデータに関する分析学データを、少なくとも１つの通信ネットワーク上でＡＳＰシステムから受信することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、受信された分析学データを、ＰＨＩシステムと通信可能に結合された少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶することとをさらに含むことができる。方法は、ＰＨＩシステムの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上でクライアントプロセッサベースデバイスに、利用可能スタディのリストを提供することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、リスト中の利用可能スタディのうちの少なくとも１つのスタディの選択を、少なくとも１つの通信ネットワーク上でクライアントプロセッサベースデバイスから受信することとをさらに含むことができる。方法は、ＰＨＩシステムの少なくとも１つのプロセッサによって、更新についてのチェックを、少なくとも１つの通信ネットワーク上でＡＳＰシステムに対して定期的に送ることと、ＰＨＩシステムの少なくとも１つのプロセッサによって、更新データを、少なくとも１つの通信ネットワーク上でＡＳＰシステムから受信することとをさらに含むことができる。方法は、クライアントプロセッサベースデバイスの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上でＰＨＩシステムからＰＨＩデータを受信することと、クライアントプロセッサベースデバイスの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワーク上でＡＳＰシステムから、非識別化された医療スタディデータを受信することと、クライアントプロセッサベースデバイスの少なくとも１つのプロセッサによって、ＰＨＩデータと非識別化された医療スタディデータとをマージして、再識別された医療スタディデータを生成することと、クライアントプロセッサベースデバイスの少なくとも１つのプロセッサによって、再識別された医療スタディデータをクライアントプロセッサベースデバイスのユーザに提示することとをさらに含むことができる。

【0014】

医療分析学プラットフォームの被保護健康情報（ＰＨＩ）システムであって、医療分析学プラットフォームは、ＰＨＩシステムおよび分析学サービスプロバイダ（ＡＳＰ）システムを含み、ＡＳＰシステムは、非識別化された医療スタディデータを、ＡＳＰシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶し、ＰＨＩシステムは、プロセッサ実行可能命令またはデータのうちの少なくとも１つを記憶する少なくとも１つの非一時的プロセッサ可読記憶媒体と、少なくとも１つの非一時的プロセッサ可読記憶媒体に伝達可能に結合された少なくとも１つのプロセッサとを含むものとして要約されてよく、動作中、少なくとも１つのプロセッサは、非識別化された医療スタディデータに関連付けられたＰＨＩデータを、ＰＨＩシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶することと、クライアントプロセッサベースデバイスによって少なくとも１つの通信ネットワーク上でＡＳＰシステムから受信された非識別化された医療スタディデータとクライアントプロセッサベースデバイスによってマージされるように、要求された医療スタディ用のＰＨＩデータを、少なくとも１つの通信ネットワーク上でクライアントプロセッサベースデバイスに対して送ることとを行う。

【0015】

少なくとも１つのプロセッサは、医療スタディ用のＰＨＩデータについての要求を、クライアントプロセッサベースデバイスから受信することであって、要求は暗号化されたＰＨＩアクセストークンを含む、受信することと、暗号化されたＰＨＩアクセストークンを有効性確認のために、少なくとも１つの通信ネットワーク上でＡＳＰシステムに対して送ることと、ＰＨＩアクセストークンが有効であるという通知を、ＡＳＰシステムから受信することとができる。少なくとも１つのプロセッサは、ＰＨＩデータを含む医療スタディデータを受信することと、医療スタディデータからＰＨＩデータを削除して、非識別化された医療スタディデータを生成することと、ＰＨＩシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体中に、ＰＨＩデータを記憶することと、非識別化された医療スタディデータを、少なくとも１つの通信ネットワーク上でＡＳＰシステムに対して送ることとができる。医療スタディデータは、スキャナからの医療撮像データを含むことができる。少なくとも１つのプロセッサは、表現状態転送（ＲＥＳＴ）アプリケーションプログラミングインタフェースを使って、非識別化された医療スタディデータをＡＳＰシステムに対して送ることができる。少なくとも１つのプロセッサは、消去されることが許される、医療スタディデータのフィールドを削除することと、消去されることが許されない、医療スタディデータのフィールド中のデータを、不明瞭化された置換えデータと置き換えることとができる。少なくとも１つのプロセッサは、医療スタディについての医療スタディデータに一意の識別子を関連付けることと、ＰＨＩシステムの少なくとも１つの非一時的プロセッサ可読記憶媒体中に一意の識別子を記憶することと、医療スタディについての非識別化された医療データとともに一意の識別子を、少なくとも１つの通信ネットワーク上でＡＳＰシステムに対して送ることとができる。少なくとも１つのプロセッサは、非識別化された医療スタディデータに関する分析学データを、少なくとも１つの通信ネットワーク上でＡＳＰシステムから受信することと、受信された分析学データを、ＰＨＩシステムと通信可能に結合された少なくとも１つの非一時的プロセッサ可読記憶媒体上に記憶することとができる。少なくとも１つのプロセッサは、利用可能スタディのリストを、少なくとも１つの通信ネットワーク上でクライアントプロセッサベースデバイスに提供することと、リスト中の利用可能スタディのうちの少なくとも１つのスタディの選択を、少なくとも１つの通信ネットワーク上でクライアントプロセッサベースデバイスから受信することとができる。少なくとも１つのプロセッサは、更新についてのチェックを、少なくとも１つの通信ネットワーク上でＡＳＰシステムに対して定期的に送ることと、更新データを、少なくとも１つの通信ネットワーク上でＡＳＰシステムから受信することとができる。

【図面の簡単な説明】

【0016】

図面において、同一の参照番号は同様の要素および作用を識別する。図面中の要素のサイズおよび相対的位置は、必ずしも一定の縮尺で描かれていない。たとえば、様々な要素および角の形状は、必ずしも一定の縮尺で描かれておらず、これらの要素のうちのいくつかは、描画可読性を向上するために、任意に拡大され、位置決めされている場合がある。さらに、描かれている要素の特定の形状は、特定の要素の実際の形状に関するいかなる情報も伝えることは必ずしも意図しておらず、図面における認識の簡単のために単に選択されている場合がある。

【図1】１つの図示した実施形態に従う、少なくとも１つのＭＲＩ獲得システムおよび少なくとも１つの画像処理システムを含むネットワーク化環境の概略図であって、ＭＲＩ獲得システムは、臨床の場に位置し、画像処理システムは、ＭＲＩ獲得システムから離れて位置し、１つまたは複数のネットワーク上でそれと通信可能に結合されている図である。

【図2】１つの図示した実施形態に従う、ＭＲＩ獲得システムならびにＭＲＩ画像処理および分析サービスを提供するＭＲＩ画像処理および分析システムの機能ブロック図である。

【図3A】１つの図示した実施形態に従う、少なくとも１つのプロセッサによって実行可能な例示的プッシュプロセスのフロー図である。

【図3B】１つの図示した実施形態に従う、少なくとも１つのプロセッサによって実行可能な例示的プッシュプロセスのフロー図である。

【図4A】１つの図示した実施形態に従う、少なくとも１つのプロセッサによって実行可能な、アーティファクトおよびアーチングを監視する例示的プロセスのフロー図である。

【図4B】１つの図示した実施形態に従う、少なくとも１つのプロセッサによって実行可能な、アーティファクトおよびアーチングを監視する例示的プロセスのフロー図である。

【図5】１つの図示した実施形態に従うＰＨＩサービスパイプラインの略図である。

【図6】１つの図示される実施形態に従う、医療プロバイダのネットワーク内に保たれるＰＨＩデータが、分析学サービスプロバイダ（ＡＳＰ）のウェブアプリケーションを介して、ＡＳＰシステムからのピクセルデータとマージされることを示す、図５のＰＨＩサービスの略図である。

【図7】１つの図示される実施形態に従う、ＤＩＣＯＭファイルがＰＨＩデータを取り去られることを示す図５のＰＨＩサービスの略図である。

【図8】１つの図示される実施形態に従う、ユーザがウェブアプリケーションを操作して、ユーザの団体の登録されたＰＡＣＳサーバについてのレポートを記憶するよう、ＡＳＰシステムに要求することを示すＰＨＩサービスの略図である。

【図9】１つの図示される実装形態に従う、ＰＨＩサービスのＰＨＩサーバによってＤＩＣＯＭファイルがどのように扱われるかを示すＰＨＩサービスの略図である。

【図10】１つの図示される実施形態に従う、ＰＨＩサービス依存がどのように編成されるかを示すＰＨＩサービスの略図である。

【図11A】１つの図示される実施形態に従う、ＰＨＩサービスの起動シーケンスのためのプロセスを示すシステムシーケンス図である。

【図11B】１つの図示される実施形態に従う、ＰＨＩサービスの起動シーケンスのためのプロセスを示すシステムシーケンス図である。

【図12】１つの図示される実施形態に従う、ＰＨＩサービスの非識別化サービスを実装するためのプロセスを示す流れ図である。

【図13A】１つの図示される実施形態に従う、ＰＨＩサービスのプッシャまたはアップローダサービスのためのプロセスを示す流れ図である。

【図13B】１つの図示される実施形態に従う、ＰＨＩサービスのプッシャまたはアップローダサービスのためのプロセスを示す流れ図である。

【図14A】１つの図示される実施形態に従う、ウェブブラウザ再識別のためのプロセスを示すシステムシーケンス図である。

【図14B】１つの図示される実施形態に従う、ウェブブラウザ再識別のためのプロセスを示すシステムシーケンス図である。

【図15A】１つの図示される実施形態に従う、アーティファクト再識別サービスを実装するためのプロセスを示すシステムシーケンス図である。

【図15B】１つの図示される実施形態に従う、アーティファクト再識別サービスを実装するためのプロセスを示すシステムシーケンス図である。

【発明を実施するための形態】

【0017】

以下の説明において、様々な開示される実施形態の完全な理解を提供するために、いくつかの具体的な詳細が記載される。ただし、実施形態は、これらの特定の詳細のうちの１つもしくは複数なしで、または他の方法、構成要素、材料などで実践されてよいことが、当業者には認識されよう。他の事例においては、ＭＲＩマシン、コンピュータシステム、サーバコンピュータ、および／または通信ネットワークに関連付けられた、よく知られている構造は、実施形態の記載を不必要に不明瞭にすることを避けるために、示されていないか、詳しく記載されていない。

【0018】

文脈上他の意味に解すべき場合を除いて、後に続く本明細書および請求項を通して、「ｃｏｍｐｒｉｓｅ（備える）」という単語ならびに「ｃｏｍｐｒｉｓｅｓ（備える）」および「ｃｏｍｐｒｉｓｉｎｇ（備える）」など、その変化形は、「ｉｎｃｌｕｄｉｎｇ（含む）」と同義であり、包含的または開放型である（すなわち、追加、具陳されていない要素または方法作用を排除しない）。

【0019】

本明細書を通しての「一実施形態」または「ある実施形態」への言及は、実施形態に関して説明する特定の特徴、構造、または特性が、少なくとも１つの実施形態中に含まれることを意味する。したがって、本明細書を通して様々な場所における「一実施形態において」または「ある実施形態において」というフレーズの出現は、必ずしもすべてが同じ実施形態に言及するわけではない。さらに、特定の特徴、構造、または特性が、１つまたは複数の実施形態において、どの適切な方式で組み合わされてもよい。

【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】

ＭＲＩ獲得システム１０２は、１つまたは複数のサーバコンピュータ（図示されず）に通信可能に結合されてよい。たとえば、ＭＲＩ獲得システム１０２は、ファイアウォール１５６ａ（図１）を含むか、または実装することができる、１つまたは複数の診断機構サーバコンピュータ（図示されず）、ルータ（図示されず）、ブリッジ（図示されず）、ＬＡＮ１０６ａ（図１）などを介して通信可能に結合されてよい。サーバコンピュータ（図示されず）は、臨床施設またはサイトでＬＡＮ１０６ａを介して通信可能に結合された、いくつかのＭＲＩ獲得システム１０２（すなわち、クライアント）用のサーバとして機能し、したがって、ＭＲＩ獲得システム１０２とＭＲＩ画像処理および分析システム１０４との間の媒介として作用するために、サーバ命令のセットを実行することができる。ＭＲＩ獲得システム１０２は、ＷＡＮを介して通信可能に結合されているサーバコンピュータのクライアントとして機能するために、クライアント命令のセットを実行することができる。

【0065】

ＭＲＩ制御システム１２６は典型的には、１つまたは複数のプロセッサ（たとえば、マイクロプロセッサ、中央処理ユニット、デジタル信号プロセッサ、グラフィカル処理ユニット）と、非一時的プロセッサ可読メモリ（たとえば、ＲＯＭ、ＲＡＭ、Ｆｌａｓｈ、磁気および／または光ディスク）とを含む。ＭＲＩオペレータのシステム１２８は、適切な命令を実行する、コンピュータ、たとえばパーソナルコンピュータ（たとえば、デスクトップもしくはラップトップコンピュータ）、ネットブックコンピュータ、タブレットコンピュータ、スマートフォン、携帯情報端末、ワークステーションコンピュータおよび／またはメインフレームコンピュータなどの形をとることができる。

【0066】

ＭＲＩオペレータのシステム１２８は、１つまたは複数の処理ユニット２６８と、システムメモリ２６９と、システムメモリ２６９を含む様々なシステム構成要素を処理ユニット２６８に結合するシステムバス（図示されず）とを含むことができる。

【0067】

処理ユニット２６８は、１つまたは複数の中央処理ユニット（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラム可能ゲートアレイ（ＦＰＧＡ）、グラフィカル処理ユニット（ＧＰＵ）などのような、どの論理処理ユニットであってもよい。市販されているコンピュータシステムの非限定的例は、米国インテルコーポレーションからの８０×８６またはペンティアムシリーズマイクロプロセッサ、ＩＢＭからのＰｏｗｅｒＰＣマイクロプロセッサ、サンマイクロシステムズ社からのＳｐａｒｃマイクロプロセッサ、ヒューレットパッカード社からのＰＡ－ＲＩＳＣシリーズマイクロプロセッサ、モトローラコーポレーションからの６８ｘｘｘシリーズマイクロプロセッサ、ＡＴＯＭプロセッサ、またはＡ４もしくはＡ５プロセッサを含むが、それらに限定されない。別段に記載されない限り、図２に示されるＭＲＩ獲得システム１０２の様々なブロックの構築および操作は、従来の設計である。その結果、そのようなブロックは、当業者によって理解されるので、本明細書においてそれ以上詳しく説明される必要はない。

【0068】

システムバスは、メモリコントローラ付きメモリバス、周辺バス、およびローカルバスを含む、どの知られているバス構造またはアーキテクチャを利用してもよい。システムメモリ２６９は、読取り専用メモリ（「ＲＯＭ」）２７０およびランダムアクセスメモリ（「ＲＡＭ」）２７２を含む。ＲＯＭ２７０の一部を形成することができる基本入出力システム（「ＢＩＯＳ」）２７１は、起動中などに、ＭＲＩ獲得システム１０２内の要素の間で情報を転送するのを助ける基本ルーチンを含む。

【0069】

ＭＲＩオペレータのシステム１２８は、コンピュータ可読記憶媒体２７４、たとえば、ハードディスク、光ディスク、および／または磁気ディスクから読み取り、そこに書き込むための、１つまたは複数の媒体ドライブ２７３、たとえば、ハードディスクドライブ、磁気ディスクドライブ、ワームドライブ、および／または光ディスクドライブも含むことができる。非一時的コンピュータ可読記憶媒体２７４は、たとえば、取外し可能媒体の形をとることができる。たとえば、ハードディスクはＷｉｎｃｈｅｓｔｅｒドライブの形をとることができ、光ディスクはＣＤ－ＲＯＭの形をとることができ、磁気ディスクは磁気フロッピーディスクまたはディスケットの形をとることができる。媒体ドライブ２７３は、１つまたは複数のシステムバスを介して処理ユニット２６８と通信する。媒体ドライブ２７３は、当業者によって知られているように、そのようなドライブとシステムバスとの間に結合されたインタフェースまたはコントローラ（図示されず）を含むことができる。媒体ドライブ２７３、およびそれらの関連非一時的コンピュータ可読記憶媒体２７４は、コンピュータ可読命令、データ構造、プログラムモジュールおよび他のデータの不揮発性記憶をＭＲＩ獲得システム１０２に提供する。ハードディスク、光ディスクおよび磁気ディスクなどのコンピュータ可読記憶媒体２７４を利用するものとして記載されているが、ＭＲＩオペレータのシステム１２８は、磁気カセット、フラッシュメモリカード、デジタルビデオディスク（「ＤＶＤ」）、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭ、スマートカードなどのような、コンピュータによってアクセス可能なデータを記憶することができる他のタイプの非一時的コンピュータ可読記憶媒体を利用してよいことが、当業者には諒解されよう。データまたは情報、たとえば、電子もしくはデジタルファイルまたはそのようなものに関連したデータもしくはメタデータは、非一時的コンピュータ可読記憶媒体２７４中に記憶されてよい。

【0070】

オペレーティングシステム、１つまたは複数のアプリケーションプログラム、他のプログラムまたはモジュールおよびプログラムデータなどのプログラムモジュールが、システムメモリ２６９中に記憶されてよい。プログラムモジュールは、ＭＲＩ処理および分析システム１０４によってホストされるかまたは提供される、ウェブサイト、エクストラネットサイトまたは他のサイトもしくはサービス（たとえば、ウェブサービス）および関連ウェブページ、他のページ、スクリーンまたはサービスにアクセスするための命令を含むことができる。

【0071】

特に、システムメモリ２６９は、ＭＲＩ獲得システム１０２が、ＭＲＩ処理および分析システム１０４によって提供されるＭＲＩ画像処理および／または分析サービスと、電子またはデジタル情報またはファイルまたはデータもしくはメタデータを交換することを許可する通信プログラムを含むことができる。通信プログラムは、たとえば、ＭＲＩ獲得システム１０２が、情報、ファイル、データおよび／またはメタデータにアクセスし、インターネット、法人イントラネット、エクストラネット、または他のネットワークのウェブサイトなどのソースと交換することを許可するウェブクライアントまたはブラウザであってよい。そのようなものは、エンドユーザクライアントが、所与のウェブサイト、たとえば、ＭＲＩ処理および分析システム１０４によってホストされるものにアクセスするための十分な権利、許可、特権または権限を有することを求める場合がある。本明細書において論じられるように、患者識別用データは、臨床施設によって、またはそのために操作されるシステム上に常駐してよく、画像処理機構または画像処理機構担当者によって、またはそのために操作されるシステムによって、またはシステムを通じてアクセス可能でない場合がある。ブラウザは、たとえば、ハイパーテキストマークアップ言語（ＨＴＭＬ）、拡張マークアップ言語（ＸＭＬ）または無線マークアップ言語（ＷＭＬ）など、マークアップ言語ベースであってよくドキュメントの構造を表すためにドキュメントのデータに追加された、統語的に区切られたキャラクタを使うマークアップ言語とともに動作することができる。

【0072】

システムメモリ２６９中に記憶されるものとして記載されているが、オペレーティングシステム、アプリケーションプログラム、他のプログラム／モジュール、プログラムデータおよび／またはブラウザは、媒体ドライブ２７３のコンピュータ可読記憶媒体２７４上に記憶されてよい。オペレータが、タッチスクリーンもしくはキーボード２７６および／またはマウスなどのポインティングデバイス２７７などの入力デバイスを通じて、ユーザインタフェース２７５を介してＭＲＩオペレータのシステム１２８にコマンドおよび情報を入れることができる。他の入力デバイスは、マイクロフォン、ジョイスティック、ゲームパッド、タブレット、スキャナなどを含むことができる。これらおよび他の入力デバイスは、システムバスに結合するシリアルポートインタフェースなどのインタフェースを通じて、処理ユニット２６９に接続されるが、パラレルポート、ゲームポートもしくは無線インタフェースまたはユニバーサルシリアルバス（「ＵＳＢ」）など、他のインタフェースが使われてよい。ディスプレイまたはモニタ２７８が、ビデオアダプタなどのビデオインタフェースを介してシステムバスに結合されてよい。ＭＲＩオペレータシステム１２８は、スピーカー、プリンタなどのような、他の出力デバイスを含むことができる。

【0073】

ＭＲＩ画像処理および分析システムは静的インタフェースを構築することができ、このインタフェースは、様々な組織タイプがＭＲＩ ４－Ｄフローデータセットに差し引かれるか、または追加されることを可能にする。たとえば、脂肪または骨などの静的組織は、空気または流れている血液などの非静的組織とは区別されてよい。ＭＲＩ画像処理および分析システムは、様々な非静的組織をさらに自律的に区別することができ、たとえば、空気（たとえば、肺）と流れている血液とを区別する。さらに、ＭＲＩ画像処理および分析システムは、動脈および静脈血流を区別することができる。

【0074】

たとえば、ＭＲＩ画像処理および分析システムは、拍動パターンまたは波形を有することが期待される血液組織を識別するのに、高速フーリエ変換を利用することができる。空気または肺は、隣接ボクセル（ｖｏｘｅｌｓ）の速度が比較されると、定義されたボリュームにわたってランダム出現パターンを有する傾向がある。たとえば、強力な、または速い速度をもつボクセルは、典型的には、空気を示す。ＭＲＩデータセットはかなり大きく、たとえば２５６×２５６×２５６×２０個の時間点であってよい。ＭＲＩ画像処理および分析システムは、異なる組織タイプを検出するために勾配（たとえば、勾配降下方法）に依拠してよく、有利には、比較的大きいＭＲＩデータセットを迅速に扱うために、分析的解決手法よりもむしろ数値的手法を利用してよい。数値的手法の大幅な桁（たとえば、２）の数を制御することによって、ＭＲＩ画像処理および分析システムは、特定のアプリケーション向けに十分に正確な結果を依然として取得しながら、非常に速い（たとえば、３０分とは反対に、１秒）結果を達成することができる。

【0075】

いくつかの実装形態において、異なる組織タイプが、一度に１つ、患者ＭＲＩデータセットから差し引かれてよい。たとえば、空気または肺を差し引き、血液を差し引き、静脈流から心房を分離し、骨を差し引き、脂肪を残す。特に、脂肪は静的であるので、脂肪を表す各ボクセルは、それに関連付けられたゼロ速度を有するべきである。ＭＲＩ画像処理および分析システムは有利には、このようなグランドトゥルースを、すべての組織タイプ向けにＭＲＩデータセットを補正するのに利用することができる。

【0076】

非ゼロ速度が脂肪タイプ組織用に見つかった場合、これは、（たとえば、すべての組織についての）データのセット全体を調節するのに使われてよい。たとえば、ＭＲＩ画像処理および分析システムは、識別されたエリアまたはボリューム（たとえば、脂肪または軟組織）に基づいて多項式モデルを生成または作成することができる。そのようなものは、単純多項式（たとえば、ａｘ²＋ｂｘ＋ｃ）またはいっそう複雑な多項式（たとえば、非有理一様ｂスプライン）であってよい。ＭＲＩ画像処理および分析システムは、たとえば直線回帰技法または線形代数技法を使って、多項式に対する係数が画像に合うことを見つけることができる。これは、ＭＲＩ画像処理および分析システムが、脂肪または軟組織だけではなく全フィールドに適用する（たとえば、そこから差し引く）ことができるモデルという結果になる。

【0077】

一実施形態において、実際に患者データから差し引かれてよいデータの参照セットまたは「ファントム」モデルを作成するために、レプリカ体が撮像される。レプリカ体は、血流はもたないが、実際に肉体のＭＲＩ応答を模倣する材料で形成されてよい。データの参照セットまたは「ファントム」モデル中の位相勾配は、ノイズ（たとえば、ランダムノイズ）を表すことができ、位相シフトを補正するのに使われてよい。この手法は有利には、３－Ｄデータに合う多項式を生成する必要を避ける。生成された参照セットまたはファントムモデルは、数か月のＭＲＩマシン操作にわたって有効であってよいが、ＭＲＩマシンがサービスされるか、または動かされた場合、参照データの新規セットまたはファントムモデルが生成されるべきである。

【0078】

ＭＲＩ画像処理および分析システムは、異なる組織タイプを取り除くための、または静脈もしくは心房血流のいずれかを取り除くための様々なフィルタまたはマスクを定義することができる。フィルタまたはマスクは、何らかの妥当な範囲の外（たとえば、高すぎるかもしくは速すぎる、遅すぎるかもしくは低すぎる）または血流があるはずのない解剖学的構造（たとえば、骨）の中を血液が流れているように見える血流などの異常血流を取り除くことができる。フィルタまたはマスクはまた、何らかの閾値値よりも大きい絶対値をもつマグニチュードを有するボクセルのみを表示するように定義されてよい。フィルタまたはマスクはまた、絶対値が何らかの定義された閾値よりも大きい、マグニチュードと速度ベクトルのクロス積の絶対値をもつボクセルのみを表示するように定義されてよい。さらに、高速度ジェットをたとえば識別するか、または閲覧するために、隣接ボクセルのベクトルと同じ方向のベクトルを有するボクセルのみを示すフィルタまたはマスクが定義されてよい。特に、隣接ボクセルの速度ベクトルは異なる方向であり、ノイズのインジケーションであってよい。

【0079】

前処理
質量保存補正エラー低減
この前処理アルゴリズムのゴールは、フローデータを補正すること（セグメント化、フロー定量化、およびバックグラウンド位相エラー補正）である。補正される必要がある３つのフローデータセット、すなわち、ｉ）ｘ速度、ｉｉ）ｙ速度、およびｉｉｉ）ｚ速度がある。撮像アーティファクト（たとえば、乱れ）およびノイズにより、フローデータは偏りがある。これを補正するために、質量保存（すなわち、物理的原理）が、フローデータを補正するのに使われる。質量保存は、閉システムの質量が、それが追加または取り除かれない場合、量を変えることができないので、時間が経過しても一定のままであることを我々に伝える。したがって、境界が心臓内に定義される場合（すなわち、心腔および血管の管腔境界）、固定ボリュームに入るフローは、体液が圧縮不能な場合、ボリュームを出るフローと一致しなければならない。この理論は、どのボリュームにも適用されてよい。血流のケースにおいて、我々は、血液濃度が一定であるという仮定を行い、したがって、連続方程式は、速度場の発散がどこにおいてもゼロであることを意味するように簡約する。物理的に、これは、ローカルボリューム膨張レートがゼロである（すなわち、ｄｕ／ｄｘ＋ｄｖ／ｄｙ＋ｄｗ／ｄｚ＝０）と言うことと等価である。この条件をどこにおいても強制することは不可能であるが、ローカルボリューム膨張は、すべての時間点にわたって最小限にされることが可能である。ｄｕ／ｄｘ＋ｄｖ／ｄｙ＋ｄｗ／ｄｚを最小限にする、いくつかの異なるタイプのアルゴリズムがあるが、最も共通するものは、フローフィールドの最小２乗発散なし近似を生成するアルゴリズムである。発散を最小限にするという制約をもつフローフィールドへの最小２乗近似を構築するための、いくつかのやり方、およびこれを達成するためのいくつかの異なるアルゴリズムがある。

【0080】

典型的には、あらゆるパスを用いて残差発散を最小限にしようとする関与する反復手法がある。さらに、血管／腔の厳密な境界を知ることが、境界を通じてゼロ磁束を確実にするためには重要である。境界なしでは、フローは、心筋および脂肪の中に逃れることを可能にされる場合がある。さらに、画像中にアーティファクトがある場合がある（すなわち、乱れによって引き起こされる）。ユーザが、アーティファクト（「不良データ」）がある領域を識別した場合、この領域は、「良好データ」領域における速度値補正に影響するのには使われない。

【0081】

これを解決するための別の手法は、最適化を使うことであり、すなわち、元のベクトルフィールドが可能な限り変えられない（依然としてローカル効果をキャプチャし、平滑化を防止するために）ことを確実にしながら、発散を最小限にすることを試みる。

【0082】

運動量の保存が、壁面せん断応力に加え、血管にわたる圧力勾配を推定するために、以降の作用において適用されてよい。この質量保存ステップは、正確な圧力推定を確実にするのに不可欠である。

【0083】

時間ドメインを使う自動位相エイリアシング補正
４－Ｄフロースキャン用に設定されたＶＥＮＣが低すぎて速度値を大きい正の値から大きい負の値に、またはその反対に「ラップ」させたとき、位相エイリアシングが起こる。原理上、このラッピングは２回以上起きてよい。

【0084】

速度データの全体的時間変動を分析することによって、心周期（他の箇所で記載される）のメイン点を決定することが可能である。ピーク拡張期での画像中に速度エイリアシング（ａｌｉａｓｉｎｇ）がないという仮定の下で、また、空間中の一地点での速度が、現実には、ある時間点から次までに＋／－ＶＥＮＣを超えては変動しないという仮定の下で、以下のように、空間中の各点の時間変動を調べることによって位相エイリアシングを補正することが可能である
ｉ）ピーク拡張時間点を識別し、その点では位相エイリアシングがないと仮定する。
ｉｉ）各獲得された速度成分の時間挙動を個々に調べる。
ｉｉｉ）各速度画像中の空間中の各点（ボクセル）について、ある時間点から次までの速度の変化を追跡する。速度が、＋／－ＶＥＮＣを超えて変動することが観察された場合、エイリアシングが起きたと仮定する。
ｉｖ）エイリアシングが検出されたとき、その点についてのラップカウントは、観測された速度がＶＥＮＣを超えて低減した場合は増分されるか、または観測された速度がＶＥＮＣを超えて増大した場合は減分されるかのいずれかである。
ｖ）各時間点で、速度は、ＶＥＮＣの２倍をもつラップカウントの積を追加することによって、その点についての現在の累計ラップカウントに従って改変される。
ｖｉ）現在の時間点が初期ピーク拡張開始点に戻ったら、ラップカウントがゼロの値に戻ったかをチェックする。ラップカウントがゼロに戻っていない場合、空間中のその点（ボクセル）の処理は、エラーであると見なされるべきである。

【0085】

方法は、対象のピクセルを決定するために他の方法を使うことによって、向上され、よりパフォーマントにされる可能性がある。たとえば、血流を表す見込みが最もあるピクセルを決定し、これらのピクセルのみを処理するために他の方法を使ってよい。

【0086】

この方法は、自己診断するという特性および利点も有する。すべての有効な血液ボクセル（たとえば、空気とは反対に）についてのラップカウントは、時間をかけたそのボクセル向けの処理が終了したとき、ゼロに戻るべきである。ボクセル単位でエラーが追跡されてよいが、これは、エラー検出のこの方法が、あらゆるエラーボクセルを捕えることを保証されるとは限らないという弱点を有する。ただし、さらに、補正が適用されたピクセルの数の断片として低い全体的エラーレートを探すことによって、方法によって求められる必要な初期仮定が概ね正しいかどうかを確かめることができる。

【0087】

自動位相エイリアシング補正
４－Ｄフロースキャン用に設定されたＶＥＮＣが低すぎたとき、位相エイリアシングが起こる。エイリアシングされたボクセルを見つけることは、以下のことにより、非常に簡単である。
ｉ）各スキャンのＶＥＮＣは、この情報がＤＩＣＯＭ画像すべてのヘッダファイル中にあるので、知られている。
ｉｉ）＋／－ＶＥＮＣ速度前後のフロー速度の急激な変化を識別する（すなわち、ＶＥＮＣが１００ｃｍ／ｓに設定されている場合、＋／－９９ｃｍ／ｓ前後の速度の急激な変化を探す）。速度の急激な変化は、ボクセルが１００ｃｍ／ｓの速度値を有する可能性があり、近接ボクセルが－９９ｃｍ／ｓの値を有することを意味する。
ｉｉｉ）次いで、＋／－ＶＥＮＣ前後に急勾配を有するボクセルすべてを接続することによって、エイリアシングされた領域のボーダーを見つける。
ｉｖ）これは、囲まれた境界という結果になる。囲まれた境界の領域中のボクセルすべてがエイリアシングされるかどうかを決定する。境界で開始し、３－Ｄ領域の中心に向かって動くことによって、システムは、大幅な急騰が（ＶＥＮＣにわたって）ないことを確実にするために、あらゆるボクセルを取り調べることができる。
ｖ）著しい急騰に遭遇しなかった場合、ＶＥＮＣ速度が、エイリアシングされた領域内のすべてのボクセルに追加されてよい。
ｖｉ）著しい急騰に遭遇した場合、問題は少し困難になる（が、依然として解決可能である）。この場合、ボクセルが何回かラップされてよい（すなわち、ＶＥＮＣが１００ｃｍ／ｓに設定されているがボクセルでの速度が実際には４９９ｃｍ／ｓである場合、これは、２回ラップされ、速度は９９ｃｍ／ｓと示される）。データを補正するやり方は、隣接ボクセルの速度に注目することである。ＶＥＮＣの１．５倍を超える急騰があった場合、２＊ＶＥＮＣが、その密閉領域中で追加されるか、または差し引かれる必要がある。追加するか、それとも差し引くかの選択は、隣接ボクセルにわたる不連続性を最小限にするように選ばれる。
ｖｉｉ）アルゴリズムをさらに向上するために、どこが静的組織であるかについての情報が、どこが絶対ゼロでなければならないかを定義する際に不可欠である場合がある。静的組織は０速度を有するので、静的組織であると識別されるボクセルはラップされなければならない。次いで、物理的プロパティによる壁面（すなわち、体液境界レイヤ）から離れていく速さの継続的増大がなければならない。これのすべてにおける唯一の仮定は、隣接ボクセルが、互いにわたって１．５＊ＶＥＮＣを超える急騰をもたないことである。

【0088】

スプラインリアルタイム渦電流補正
ＭＲＩ獲得が実施されるとき、データは、磁界中の渦電流によるアーティファクトを含む場合がある。粒子速度が獲得される４－Ｄフロー獲得において、アーティファクトは速度値を不正にさせる。４－Ｄフローでは、血管を通る血流を定量化するために、正確な速度データを有することが不可欠である。

【0089】

渦電流アーティファクトを補正するための少なくとも１つの技法は、以下を伴う。
－静的（ゼロ速度）組織のボリュームセグメント化と、
－これらの静的ロケーションでは、未加工データから差し引かれてよいボリュームに曲線を合わせるように、速度データを使うこと。

【0090】

静的組織を表すボリュームマスクが与えられると、任意のサイズの３Ｄブロックが評価される。

【0091】

ボリューム内のブロックは、十分なマスクされたボクセルを含む場合、静的組織と見なされる。静的組織ブロックの各々についての平均速度は次いで、３つの主軸方向の各々におけるスプライン関数の集合体についての制御値として使われる。すべての３つの方向におけるスプライン関数すべてを評価した後、結果は、元の分解能にアップサンプリングされ、次いで、元のデータから差し引かれることが可能な値の規則的グリッドになる。差し引いた後、静的組織は、ゼロの有効速度を有するはずであり、非静的組織は、渦電流アーティファクトが取り除かれることになる。これは、正確なフロー定量化をできるようにする。

【0092】

セグメント化されたボリュームを与えられると、大幅により低い分解能の新規ボリュームが生成された。この新規ボリュームにおける値は、より大きいボリュームからの値を平均した結果であるが、要素のうちのいくつかが、セグメント化によってマスクアウェイされることになるので、低分解能ボリューム中の要素は、大幅により少ない高分解能データを有し、潜在的に高分解能データを有しない可能性がある。データをもたないか、または不十分なデータをもつ要素は処分される。この点での結果は、その中に穴をもつ規則的グリッドである。スプラインボリュームについてのテンソル積を評価するために、初期パスは、要素の各行についてのスプライン基底関数を評価し、スプラインの次数は、利用可能制御値の数により変わってよい。第１のパスの後、穴はなくなり、したがって、テンソル積の残りが評価されることが可能である。我々のテストデータの分析に基づいて、この新規および革新的手法からの結果は、ボリューム中のエラーを表す平滑３－Ｄ時変関数であり、算出するのが非常に速い。

【0093】

第３のステップのために、補正アルゴリズムを適用するための我々の手法は、補正ボリュームからの３線サンプリングを使うことであったが、これは成功したことが判明した。ソースボリューム中の各要素について、我々は、補正ボリューム中の８つの要素の３線ブレンドを実施し、その値をソースデータから差し引く。我々の新規補正関数を適用した後、フロー測定は、３％のエラー以内であることが分かった。さらに、プロセスの一部がユーザ対話を求めるとき、我々の新規補正を評価し、適用するのには、時間ではなくミリ秒のオーダーがかかるので、リアルタイム実施のための要件も満たされた。

【0094】

バックグラウンド位相エラー補正のための立体
４－Ｄフロー ＭＲＩスキャンにおける血液速度情報は、正確な血流算出を得るために補正される必要があるエラーを有する。静的組織中のエラー信号は、非静的組織に補正関数を提供するのに使われてよい（他の箇所で記載される）。立体と呼ばれる、組織の３次元ボリュームが、静的または非静的組織のいずれかのセクションを識別するために作成されてよい。立体は、２つの方法を使って作成されてよい。

【0095】

直交輪郭：ユーザは、３つの交差閉輪郭を手描きすることができる。これらの輪郭の交差は、静的または非静的組織のいずれかの立体の、３次元ボリュームを表す。輪郭は、完璧に直交である必要はなく、ユーザは、どのロケーションでも輪郭を作成してよい。

【0096】

３－Ｄフラッド：ユーザはあるいは、３次元フラッドの開始点を指定することによって立体を自動的に作成することを選んでよい。フラッドは、位相画像を含むどの画像に対して使われてもよい。画像は、ユーザがクリックした点での値を下回る、および上回る閾値に基づいてフラッドされる。ユーザは、閾値と、生成されるフラッドの半径の両方を制御することができる。

【0097】

複数の立体が、静的および非静的組織の両方のエリアをマスクアウトするためのいずれかの方法を使って作成されてよく、既存の立体内のエリアをアンマスクするために、互いに重なって使われてよい。

【0098】

いくつかの状況において、画像中にアーティファクトがある。アーティファクトは、ユーザが正しくない診断を与えるのを防止するために、削除またはハイライトされる必要がある。我々のソフトウェアは、データセット中のボクセルすべてに基づいてメトリックを計算する前処理ステップ（すなわち、渦電流補正）を有する。これらの前処理ステップを避けるために、アーティファクトを有するボクセルを識別するためのツールが使われ、これらのボクセルは、どの前処理ステップからも取り除かれる（ただし、視覚化目的のためには取り除かれない）。ツールは、手動セグメント化ツール（すなわち、ユーザが、アーティファクトを有するエリアを丸で囲む）、またはアーティファクトを識別する半自動／自動セグメント化ツールであってよい。ツール特質にかかわらず、我々のソフトウェアは、「不良ボクセル」が定量化されるのをやめさせるための特徴を必要とする。

【0099】

自動バックグラウンド位相エラー補正
４－Ｄフロー ＭＲＩスキャンにおける速度の正確な測定は、渦電流によってもたらされる偽信号向けの補正の適用を求める。渦電流補正（ＥＣＣ）を決定することは、静的（動かない）組織における速度信号を調べることによって行われる。これは、すべての動く組織、血液および空気のマスキングを求める。この主張は、これを、ユーザ介入なしで自動的に行うための方法を記載する。自動補正は、ソフトウェアを、使うのにより単純およびより迅速にするだけでなく、ユーザがスタディを最初にオープンするときに補正が事前計算され、適用されることを可能にするので、有用である。自動補正はまた、ＥＣＣから利益を受けるために、自動セグメント化および測定のようなことを行って、他の前処理アルゴリズムを可能にするので、非常に重要である。

【0100】

自動ＥＣＣは、３つのフィルタについての初期開始値を計算することによって行われ、これらは、ユーザが次いで、スタディがオープンした後に自由に調節する。空気は、設定された閾値を下回る解剖画像値をもつ領域をマスクアウトすることによってマスクされる。この閾値は、スキャンされたボリューム全体に及ぶ解剖画像値についてのヒストグラムの分析によって自動的に決定される。胸腔にわたるこれらの値についてのヒストグラムは、空気に対応する画像値の自動検出をできるようにするパターンを表示する。

【0101】

さらに、血流の領域および心臓壁動きの領域を確実に検出する２つのフィルタが開発されている。心臓の領域は、これらの２つのフィルタを適切に設定することによって満足にマスクアウトされてよい。これらのフィルタの、本来一貫性のある性質とともに製造において使われる正規化により、単にこれらのフィルタを所定の値（たとえば、５０％）に設定することによって、満足できる結果が取得される場合がある。これらのフィルタの自動設定は、空気の領域の検出のための、前の段落において記載されたことと同様の、これらのフィルタによって生じられた値の分析によってさらに向上される（または微調整される）場合がある。設定は、結果として生じたＥＣＣを調べ、心周期にわたる大きい変動を示す領域を探すことによって微調整されてもよい。

【0102】

スタディが前処理されるときに決定された、これらのフィルタ用の正しい値は次いで、他のスタディ情報とともにデータベース中に単に記憶され、スタディが最初にオープンされるときに、クライアントソフトウェアが、これらをデフォルト値として設定することを可能にする。

【0103】

視覚化
時間的目標定量化および視覚化
体の中の、具体的には心臓の中の目標（すなわち、点、線、面、エリア、ボリューム）を識別することができることが有用である。いくつかの目標は、性質が動的であり（たとえば、僧帽弁面）、したがって、それらの動きを時間内に追跡することが重要である。
点：時間経過に伴って３－Ｄ経路（線である）を追跡する。
線：時間経過に伴って２つのエンドポイントの３－Ｄ経路を追跡する。
面：時間経過に伴って面上の点および面の法線ベクトルを追跡する。
エリア：時間経過に伴って、膨張する輪郭、輪郭中心、および輪郭法線ベクトルを追跡する。
ボリューム：時間経過に伴って、ボリュームの表面を離散化し、各離散化された点を追跡する。

【0104】

時間的目標定量化および視覚化に対する２つの作用がある。
１）検出：第１のステップは、時間経過に伴って目標を識別するものである。これは、手動でまたは自動的に行われてよい。
手動検出：ユーザは、各目標の位置および配向を示すことができる。これを行う一方法は、画像の中心が目標の所望のロケーションにあるようにパンおよび回転を使って画像をナビゲートするものであってよい。目標のロケーションは、異なる時間点では異なってよく、ユーザが明示的にロケーションを設定していない時間点について補間されることになる。それは、目標が補間された場合、ユーザに対して示される。

【0105】

２）ディスプレイ：目標のタイプに依存して、データを表示するための異なるタイプの方法が使われる。たとえば、輪郭が、その時間経過に伴う法線ベクトル（すなわち、単に広がり）を動かさず、または変えない場合、ユーザのビュー面が変わらず、常に輪郭と整列されることは道理にかなう。この輪郭が動かない場合、我々は、ビューが各時間点について面と常に整列されるような面に続くことを想像することができる。ビュー面は、ラグランジュ視点から、またはオイラー視点からのいずれかであってよい。ボリュームに対しては、ボリュームの表面が広がり、空間中で固定されているカメラで視覚化されてよい（ユーザは、必要に応じてカメラロケーションを変えることができる）オイラー視点がより適切である。

【0106】

心臓ビュー：目標が検出されると、左心室頂点、右心室頂点、僧帽弁、三尖弁、大動脈弁、および肺動脈弁が、右および左心室の両方の２腔、３腔、４腔、および短軸ビューを作成するのに使われてよい。これらのビューの配向は、Ｍａｙｏ Ｃｌｉｎｉｃ Ｇｕｉｄｅ ｔｏ Ｃａｒｄｉａｃ ＭＲにおいて指定される。各ビューについての配向およびズームレベルは、目標の位置から計算されてよい。目標の位置が時間で変化する場合、それに従ってビューは時間で変化する。

【0107】

各ビューについての例示的目標：
左２腔：大動脈弁、僧帽弁、三尖弁、左心室頂点
左３腔：大動脈弁、僧帽弁、左心室頂点
左４腔：三尖弁、僧帽弁、左心室頂点
左短軸：僧帽弁、左心室頂点
右２腔：肺動脈弁、三尖弁、僧帽弁、右心室頂点
右３腔：肺動脈弁、三尖弁、右心室頂点
右４腔：三尖弁、僧帽弁、右心室頂点
右短軸：三尖弁、右心室頂点

【0108】

対話式目標ベースビュー
いくつかの目標が置かれる（たとえば、大動脈弁、僧帽弁、左心室頂点、前乳頭筋、後乳頭筋、肺動脈弁、三尖弁、右心室頂点、ＬＰＡ、ＲＰＡ、ＳＶＣ、ＩＶＣ、下行大動脈）と、対象の解剖を表示するために自動ビューが作成されてよい。臨床医は、３つの垂直ビューをもつ一定の目標を見ること、または心臓のケースでは、４腔ビューまたは左もしくは右心室２もしくは３腔ビューを使うのに慣れている。時間点のうちの１つについてただ１つの目標のロケーションを更新することによって、それに従って、ビューが常に垂直であるか、または２、３、および４つの腔ビューがそのままであるかのいずれかであるように、すべてのビューが更新する。目標が置かれ、ビューが自動的に生成されると、これらのビューは、ソフトウェアのレポートセクション中に保存され、任意のフォーマット（すなわち、画像）でエクスポートされ、シネ動画（すなわち、時間経過に伴う複数の画像）を含んでよい。

【0109】

閉輪郭からの４－Ｄメッシュ作成
各時間点についての短軸（場合によっては曲線）に沿って輪郭が置かれると、メッシュは次いで、各時間点について独立して生成される。これは、ねじりを最小限にするように、短軸スタックにおいて各輪郭を回転し、次いで、各輪郭中の第１の点を接続する開いた３次スプライン、第２の点を接続する第２のスプラインを生成し、輪郭中の各点についてそのようにすることによって行われる（各スライスの輪郭は、同じ数の点を有する。このプロセスの結果は、我々がメッシュの頂点として使う点の円柱格子である。

【0110】

ねじりを最小限にするプロセスは、ある輪郭の中心から上の輪郭の中心までの開いた３次エルミートスプラインを計算し、次いで、このスプラインを、下方輪郭上の各点から、その上の、輪郭がある面と交差するまで延ばすことによって行われる。システムは、この交点を計算し、次いで、これらの交点のうちのどれが、上方輪郭中の実際の輪郭点の最も近くにあるかを決定する。輪郭は次いで、これらの２つの点が同じ長軸スプライン上になるように回転される。

【0111】

本実装形態は、輪郭がある程度円形であり、近隣輪郭の間の差が空間的に最小であるとき、曲線および直線軸の両方である程度うまくいく。ただし、輪郭が円形でない右心室のケースにおいては、本実装形態によって過度のねじりがもたらされることがある。これを最小限にするために、我々は、長軸スプライン手法を捨て、任意の２つのスライスの間の三角形の数が異なってよいものに切り替えるべきである。これを行うことは、より局地的にねじりを最小限にし、これは、全体的なより平滑なメッシュという結果になる。

【0112】

スナップ－フローツール
４－Ｄフロースキャンにおいて血流を正確に観測または測定することは、ユーザに、ＭＰＲを、フローの方向と垂直になるように整列することを求める。これは、ユーザがＭＰＲの正しい配向を自動的に設定することを可能にするツールを作成するための方法を記載する。

【0113】

ＭＰＲを整列するために、ユーザは最初に、ツールをアクティブ化し、次いで、問題となっている血流の中心領域をクリックする。クリック点は次いで、ＭＰＲが整列されるとき、回転の中心として働き、クリック点を、結果として生じたＭＰＲの中心に動かす。整列は、クリック点の辺りの小さい領域中の血流の平均をとることによって行われる。これを正確に行うために、測定は、ユーザがツールを使いながら現在見ている時間点にかかわらず、ピーク血流に対応する時間点を使って行われる。これは概して、ピーク収縮期における測定を行うことを含意する。

【0114】

ユーザは、ピーク収縮期のための時間点を調節することを可能にされるが、この点は、データセットの前処理中にソフトウェアを実行することによって、自動的に最初に決定され、この自動的値は、スタディが最初にユーザによってオープンされたとき、デフォルトとして使われる。スキャンされたボリューム内の血流の領域を自動的に決定するためのフィルタが開発されている（他の箇所で記載される）。ピーク収縮期が次いで、血液に対応すると決定された、フィルタリングされたまたはマスク領域内で全体的フローの時間依存性を調べることによって決定される。

【0115】

フローの方向が正確に決定されると、フローに垂直な面の上になるようにＭＰＲの配向を調節することは簡単である。

【0116】

定量化
自動血流定量化
腔および／または血管中の血流は、最初に血液プールを隔離し（この文書において記載されるセグメント化方法を参照）、腔／血管中のフローにほぼ垂直な面を目標（上の方法を使って定義されてよい）上に置く（すなわち、面の法線がフローと整列される）ことによって、自動的に定量化される。これらの２つの作用が達成されると、面と血液プールとの間の交差が輪郭を作成する。輪郭内のボクセルはすべて、フラグ付けされる。次は、あらゆるボクセルが総フローを与えるために、面の法線ベクトルのドット積を、そのボクセルの速度ベクトルと合計する（ボクセルのエリアによって正規化することに加え）ことである。その輪郭でのフローは、スクリーン上または最終的にエクスポートされる可能性があるレポート中に自動的に表示されてよい。

【0117】

ユーザが画像上の位置を選択することを可能にすることは、多くの重要アプリケーションを有する。測定を実施する際、ユーザは、ある点から別の点までの距離を測定したい場合がある。データのボリュームからのＭＰＲを使うアプリケーションにおいて、画像上の点は、３－Ｄ空間におけるロケーションを表す。これらの３－Ｄ点は、画像に関連付けられたメタデータから計算するのが簡単である。ボリュームレンダリングを使うアプリケーションにおいて、ユーザが３－Ｄ空間中の点を選択することを可能にすることは、各ピクセルが異なる深度にある場合があるので、より難しい。

【0118】

アルファが１．０に達すると終結する増大アルファ合成関数を用いる典型的な前から後へのボリュームレイキャスティングにおいて、ピクセルの深度を決定することは、どこでレイが終結するかを追跡することによって行われてよい。後から前にレイキャストするとき、早期レイ終結はない。結果色は単に、合成関数に基づいて更新される。典型的には、合成関数は空気を透明にし、したがって、レイが目の最も近くで物質を出るとき、色は変化するのをやめる。いつ色が変化するのをやめたかを追跡することによって、各ピクセルについてのこの深度は、２－Ｄユーザ選択座標を、空間中の３－Ｄロケーションに変換して戻すのに使われてよい。この３－Ｄロケーション選択は、血管を選択し、次いで、フローを自動的に定量化するのに使われてよい。

【0119】

自動シャント検出
シャントについての厳密なロケーションを見つけようとする代わりに、第１の操作は、シャントが存在するかどうかを識別することである。シャントが存在するかどうかを識別する１つの単純な方法は、左心臓フロー（Ｑｓ）および右心臓フロー（Ｑｐ）を測定するものである。ＱｐおよびＱｓは、目標および血液プールセグメント化が完了されている場合、手動（たとえば、輪郭を置くことによって）または自動のいずれかで測定されてよい。これらの数が一定の閾値内で一致しない場合、スキャンは、シャントを潜在的に有するものとしてフラグ付けされてよい。

【0120】

これらの測定は、以下の技法を使って自動的に行われてよい。
ｉ）心出力（Ｑｓ）の自動測定は、大動脈および肺動脈弁のロケーションの自動推定値とともに、大動脈および肺動脈流の両方のためのマスクの製造であるように、他の箇所で記載される。
ｉｉ）弁領域が識別されると、それらを取り出すのは簡単なタスクであり、すでに決定された肺動脈流領域は、弁からわずかに下流に動き、心出力について記載されたことと同様にしてフロー測定輪郭を生じる。肺動脈流を測定するのに適している輪郭が識別されると、既存のフロー測定アルゴリズムが、右心室からの出力を決定するのに使われてよい。
ｉｉｉ）シャントが存在する見込みを示すのに、自動フロー測定を使う。

【0121】

ピークおよび終期の収縮期および拡張期の自動検出
大部分の自動処理が、心周期中のメインの時間的目標、すなわちピークおよび終期の収縮期および拡張期に対応する時間点を最初に識別することができることに依存する。

【0122】

他の箇所で記載されるように、我々は、心臓の辺りの主幹動脈および静脈とともに心臓内の血流の領域を識別するために、速度画像に対してフーリエ分析技法を使うことが可能である。血流のこれらのメイン領域が識別されると、我々は、各時間点（典型的には、２０個の時間点）で、識別されたボクセルにわたる総血流を見つける。システムは次いで、心周期中の目標を決定するために、結果として生じた時間の関数を分析することが可能である。大部分のフローをもつ時間点は最初に、ピーク収縮目標を割り当てられる。そこから、フローが安定する傾向がある点を決定するために、関数が両方の時間の方向において分析される。総フローが安定するピーク収縮期の前の点（急速に上昇し始めるすぐ前の点）は、終期拡張期に対応する。ピーク収縮期に続いて、総フローは、それが安定するまで急速に下落し、これは終期収縮期に対応する。ピーク拡張期は典型的には、明確な点ではないので、我々は、この時間的目標を、終期収縮期と終期拡張期との間の途中の点に置く。

【0123】

自動心出力およびボリューム測定
心出力の自動測定は、以下の方法を使って行われる。
ｉ）速度画像のメインＤＦＴ構成要素の間の関係は、すでに決定されたピーク収縮目標（他の箇所で記載される）とともに、左および右心室からの動脈流のメイン領域を識別するのに使われる。
ｉｉ）２つの断片、すなわち大動脈および肺動脈流への動脈流領域を分離するために、様々なフロー連続性フィルタが次々と使われる。最も大きい速度をもつ初期動脈流マスクにおける点が、大動脈または肺動脈のいずれかの中にあることが知られている、信頼できる点を提供する。フローの２つの領域の分離は、たとえば、最大フローの点で始まってフラッドされてよい、結果として生じたフィルタ内の領域のサイズの調査によって決定されてよい。第１の断片が識別されると、たとえば、残りの領域中の最大フロー点からのフラッディングによって、第２の断片が識別されてよい。
ｉｉｉ）２つの領域、すなわち大動脈流に対応するものと肺動脈流に対応するものが識別されると、２つの領域は、限られた量を回復することを可能にされてよく（個々のピクセルは、一方のマスクまたは他方に割り当てられるだけである）、元の動脈流マスクは、増長の量に対する絶対限度を提供する。少なくともマスクのわずかな膨張を可能にすることはまた、先行プロセス動作が、結果として生じた領域に、方法における次のステップを妨げる傾向がある小さい穴をあけている可能性があるので、非常に重要な場合がある。
ｉｖ）２つのフロー領域は、それらの互いとの空間的関係、およびそれらの非常に異なる期待される形状および空間中での配向に基づいて大動脈および肺動脈流として識別されてよい。これが行われると、元の動脈流マスクは、２つの領域に本質的に分割され、一方は大動脈流とラベル付けされ、他方は肺動脈流とラベル付けされる。
ｖ）大動脈は本質的に、１つのつながった管であるので、大動脈の経路は、動脈内の開始点から、２つの末端に達するまでたどられることが可能である。各点で、メインピーク収縮フロー方向は、点の辺りの小さい領域にわたって平均をとることによって決定されてよい。フロー方向への直交線が次いで、開始点から定期的な角度間隔で投影されて、マスクされた大動脈領域との境界を決定することができ、したがって、開始点の辺りのほぼ円形の輪郭を決定する。
ｖｉ）輪郭が、何らかの開始点について、メインフロー方向と直交する面上のポリゴンとして決定されると。開始点は、ポリゴンに中心を置き直す。この点で、中心点から、開始点からどの向きに我々がたどっているかに依存して、正または負のフロー方向で、小さいステップ（たとえば、１ミリメートル）がとられてよく、プロセスは次いで、繰り返される。これは、我々が各末端でマスクからステップアウトするまで続けられる。
ｖｉｉ）大動脈に沿って定期的間隔で輪郭が生じられると、本質的にメッシュを生じるが、それらは、解剖画像（血流強調データセットを扱う場合に可能）のいずれかを使って、または収縮時間点およびその間の補間についての貫通速度を使うことによって、各個々の時間点で洗練される。１つの可能な手法は、各時間点における各輪郭についての所望の境界を正確に識別するのに、スネークアルゴリズムを使うものである。
ｖｉｉｉ）洗練された輪郭が決定されると、各輪郭の外および内径が測定され、外径は最も大きい直径であり、内径は、外径に直交する最も大きい直径である。
ｖｉｉｉ）次のタスクは、大動脈弁と、大動脈の最上部で起こる分岐との間の上行大動脈のメイン領域中の良好な輪郭を識別することであり、というのは、これは、心出力を測定するときに使われる必要がある領域だからである。これは、いくつかの作用において行われてよい。最初に、上行大動脈領域が、フロー方向によって下降領域から容易に分離される。残りの輪郭が次いで、大動脈中の一点で、空間的（大動脈に沿って）および時間的の両方で、輪郭エリアおよび直径（外および内）の連続性および変動性の組合せを使ってスコア付けされてよい。スコアは、個々の、高くスコア付けされた輪郭を単に識別するのとは反対に、良好なスコア付けの領域を探すために大動脈に沿って平均されてよい。この方法を使って、大動脈の最上部での分岐の近隣の領域を、ならびに大動脈弁の近くに、および左心室の中へのところに存在する可能性のある領域も、これらの領域は、それらの性質により悪いスコアになるので、排除することができる。
ｉｘ）上行大動脈の良好な領域が識別されると、最も高いスコアの個々の輪郭が、実際の心出力測定のために選択されてよい。可能な場合、上行大動脈に沿った複数の点で測定が行われ、これは、変動性を調べる（そうすることによって、測定不確実性の推定も提供する）ことによって、測定の品質の自動決定を提供するとともに、平均化を通じて結果を向上させる。さらに、上行大動脈に沿ったフローの複数の測定の結果を調べることは、現在適用されている速度渦電流補正の品質についての判断をできるようにする。
ｘ）上行大動脈に沿って理想的輪郭が選択されると、通常のフロー測定技法によって心出力が決定される。

【0124】

４－Ｄボリューム測定
特定の領域のボリュームを算出するために、我々は、Ａｒｔｅｒｙｓクラウドインタフェースにおける３つのオプションを開発した。

【0125】

オプション１：固定された軸
３－Ｄ空間中の２つの点が、対象のボリュームの主軸を定義する。直線が、これらの２つの点を接続する（すなわち、固定された軸）。軸は次いで、スライスが置かれるロケーションを定義する不連続点（たとえば、２ないし４０個）に分割される。スライスは、交差しないように軸に対して直交に整列される。スライスは、均一に離間される必要はない。医療画像がそのスライスロケーションでどのように見えるかをユーザが見ることを可能にするために、すべてのスライスロケーションでＭＰＲがレンダリングされる。次いで、手動または自動的のいずれかで、あらゆるスライス上に閉輪郭が作成されて、そのスライスロケーションでのボリュームの境界を定義する。あらゆるスライスロケーションで複数の閉輪郭が存在してよい。１つまたは複数のスライス上に輪郭がまったくなくてもよい。４－Ｄまたはより高い次元のスタディ（すなわち、ボリューム変化、またはスライスごとの異なる、複数のフレームを示すスタディ）のケースにおいて、フレームごとに別個の輪郭があってよい。すべての輪郭がすべてのフレームおよびスライスについて置かれると、特定のフレームについてのすべてのスライスの輪郭を接続する３－Ｄ表面が作成される。閉輪郭のセットから３－Ｄ表面が作成されるやり方は、「閉輪郭からの４－Ｄメッシュ作成」において上で説明されている。４－Ｄまたはより高い次元のボリュームがある場合、ボリュームの変化は、各フレームのボリュームを計算し、別のフレームとは差し引くことによって計算されてよい。これは、心室機能を定量化しようとするとき、特に重要であり、それは次いで、１回拍出量および駆出率を与える。

【0126】

オプション２：動く直線軸
この方法は、４－Ｄボリュームのケースにおいて、軸の２つのエンドポイントを定義する目標または点が各フレーム（たとえば、時間点）にわたって動いてよいことを除いて、オプション１と同様である。これは、ボリュームに、ボリュームを変えることなく、３－Ｄ空間中でロケーションを潜在的に移動させる。

【0127】

オプション３：固定された曲線軸。
この方法は、２つのエンドポイントを接続する線が直線でなくてよいことを除いて、オプション１と同様である。この線は、曲線であるか、または複数の直線および曲線セクションを有してよい。これは、２つのエンドポイントの間の点／ロケーションを接続するスプラインをもつシステムにおいて扱われる。これらの点／ロケーションはどこにあってもよく、必ずしも常に２つのエンドポイントの間になくてもよい。

【0128】

オプション４：動く曲線軸
この方法は、４－Ｄボリュームのケースにおいて、曲線軸の２つのエンドポイントを定義する目標または点が各フレーム（たとえば、時間点）にわたって動いてよいことを除いて、オプション２と同様である。これは、ボリュームに、ボリュームを変えることなく、３－Ｄ空間中でロケーションを潜在的に移動させる。

【0129】

上のオプションすべてにおいて、複数の軸があってよい。たとえば、１から２に分かれる「Ｙ」形軸があってよい。ボリュームを作成するために分かれ、一緒になる直線および曲線軸の両方を有するオプションもある。これのポイントは、依然として主軸（すなわち、中心線）を有する、より複雑な形状を明らかにすることであろう。

【0130】

上のオプションすべてにおいて、３－ＤボリュームがＭＰＲとどのように交差するかを表示するオプションもある。交差は、１つまたは複数の閉輪郭の集合体でなければならない。これらの閉輪郭は、ＭＰＲ上にレンダリングされてよい。さらに、これらの閉輪郭は、新規（非直交）ビュー中で輪郭を動かすことによって編集されてよい。交差輪郭は、クライアントならびにサーバ上の両方で計算され、またはローカルリソースに依存して、適応的であってよい。心撮像用に、共通非直交像は２、３、および４つの腔ビューであってよい。輪郭は、これらのビューにおいて、編集を一定の方向（すなわち、スライス面沿い）にすることを可能にするだけで編集されてよい。

【0131】

面外測定および追跡モード
ボリュームＭＲＩデータからの心システム中の測定は、いくつかの複雑なものを有する。たとえば、弁面の形状、位置、配向、および速度は、心周期上で大幅に変化する場合がある。我々はこれを、３－Ｄ空間を通じて動く２－Ｄ輪郭を使うことによって解決する。手動または自動的のいずれかで、フロー方向に最も垂直である面上の弁開口のボーダーに輪郭が置かれる。弁面の位置および配向は、心周期の各フェーズについて追跡される。フローの評価は、標準有限方法の統合を通じて実施される、ただし、弁面が動いている場合、弁面の線形および角速度は、そのフェーズについてのフロー計算に含まれてよい。視覚化中、フェーズを通じて循環するとき、ＭＰＲの位置および配向は、弁面で追跡することができる。現在のＭＰＲが面外であるときに測定が視覚化される場合、輪郭は半透明にレンダリングされる。

【0132】

セグメント化
血液プールの連続方程式駆動型セグメント化
繰り返しになるが、非圧縮性仮定を用いる質量保存（すなわち、連続性）が、血液プール中のどこでも発散がゼロでなければならないことを示すのに使われてよい。発散をどこでも計算することによって、システムは、血液プールの程度を閾値発散値によって定義することができる。血液プールの外の発散はより大きく（すなわち、肺の中の空気）、または速度は低くなり（すなわち、静的組織中の速度信号）、これらは両方とも、内腔境界を識別するのを助ける。発散マップは、セグメント化アルゴリズムへのただ１つの入力である必要はなく、代わりに、他の入力に追加され、適切に重みづけされてよい。

【0133】

自動目標検出
自動目標検出アルゴリズムを作成するための典型的なやり方は、画像中でいくつかの形状を探し、これらの形状の間の距離および角度を測定することである。測定は、一定の帯域内にある場合、分類される。いくつかの他の生理学的入力がアルゴリズムに追加されてよい。たとえば、あらゆる心拍でかなり増大および減少する体液のボリューム（心室である見込みがある）を突き止める。心室が見つかると、弁の入口および出口は、後に続くストリームラインによって見つけられてよい。弁が見つかると、残りの弁は、典型的には常に一定の距離および角度だけ互いから離れているので、見つけるのがより容易である。

【0134】

目標を見つけるために選択されるアルゴリズムは、マシンラーニングタイプであってよい。Ａｒｔｅｒｙｓは、臨床医によって正しい目標配置で認められたデータを絶えず収集しているので、このデータは、トレーニングセット（たとえば、データの統計的集約）として使われる必要がある。分析される必要があるあらゆるデータセットは、トレーニングセットデータで構築される「図解」に相互登録されてよい。十分な数のデータセットが収集されると、病気のタイプ（すなわち、健康、ファロー四徴症など）などの追加入力パラメータが、分析されるのに先立って、データセットをビニングするのに使われてよい。あらゆるビンは、病気のタイプおよびどのような病理が期待されるかに依存して、わずかに異なる目標および測定を有する可能性がある。データセットが、単一の心室を有する患者であることが知られている場合、自動目標検出アルゴリズムは、これに合わせて調節する必要があり、というのは、このアルゴリズムは４つの弁を決して見つけないからである。

【0135】

特に、大動脈および肺動脈弁目標は、以下のプロセスを使って決定されてよい。
ｉ）左および右心室からの動脈流に対応する領域を識別する。これを、高い信頼性で行うことが可能なフィルタが開発されている（他の箇所で記載される）。
ｉｉ）動脈流の領域を２つの領域に分離し、１つは大動脈に、１つは肺動脈に対応する。このプロセスは、心出力の下で詳しく記載される。
ｉｉｉ）左または右心室からのいずれかのフローに対応する一方の領域が決定されると、他方の領域が、両方のフローに対応する開始領域から差し引くことによって決定される。領域は次いで、空間中のそれらの物理的次元および配向に基づいて、左心室流または右心室流として容易に識別されることが可能である（やはり心出力の下で記載される）。
ｉｖ）フローの２つの領域が識別されると、大動脈および肺動脈弁のロケーションについての初期近似が、大きなフローを、その明らかな源にさかのぼって注意深くたどることによって決定されてよい。
ｖ）信頼できる初期推定値が、２つの弁のロケーションについて生じられると、他の技法が、弁ロケーションを洗練するのに使われてよい。たとえば、弁のロケーションを洗練するために、初期推定値を囲む領域中の血流加速度および強度を調べればよい。

【0136】

対話式４－Ｄボリュームセグメント化
心スキャンからの心室のセグメント化は、心室機能を決定するのに不可欠である。自動心室機能技法は、以下を伴い得る。
－スプラインの制御点を表す２つ以上の点の入力と、
－スプラインのエンドポイントは、心室および出口弁（肺または大動脈）の頂点を示す、と、
－これらの点を使って、スプライン曲線に沿った定期的間隔で、曲線の正接に設定された面法線をもつＭＰＲを生成する、と、
－アクティブ輪郭モデルを適用して、各ＭＰＲに対して、心室の境界（心外膜または心内膜）を見つける、と、
－これらの輪郭の各々の点を使って３－Ｄメッシュを生成する。

【0137】

アクティブ輪郭モデルは、それらに対して作用する力からの不安定性を受ける。この不安定性を低減するために、所望の出力間隔（輪郭の間の距離）で離間されるような輪郭を単に生成する代わりに、システムは、ともに非常にしっかりと離間された多くの輪郭を生成する。また、入力データが時間的データを有する場合、同じロケーションでの輪郭が、近接時間点からのデータを使って生成される。輪郭形状および品質が次いで、心室から、典型的な輪郭に対して測定される。輪郭は、十分な品質であると思われる場合、最終結果を生成する際に含められる。最終結果は、入力曲線に沿った位置および時間に接近している含められた輪郭の平均をとることによって生成される。終期収縮期と終期拡張期の両方で構築されたメッシュを用いて、ボリュームの差は、心出力および心室機能を表す。

【0138】

一例示的実装形態において、Ａｒｔｅｒｙｓシステムおよびソフトウェアは、シングルクリック４－Ｄボリュームセグメント化を提供する。これは、ユーザが、３－Ｄボリュームを自由にナビゲート（すなわち、回転、パンニング、ズーミング、スライススクロール、時間スクロール）しながら、対象のエリア（たとえば、血液プール、心筋、骨など）をクリックすることを可能にする。十分な３－Ｄボリュームセグメント化アルゴリズムは、構築し、正確であることが困難なので、第２のオプションは、ユーザがセグメント化したいエリアの境界をユーザが描く間、ユーザに対して３つの直交像を表示することである。心臓について、表示されるビューは、短軸像に加え、心臓の２、３、および４腔ビューであってよい。ユーザは、長軸で２つの直交輪郭を作成する必要のみがあり、次いで、ソフトウェアは、２つの輪郭を補間したことに基づいて、３－Ｄ表面を自動的または自律的に作成することができる。３－Ｄ表面は、素早い修正のために、ユーザに対して短軸に示されてよい。解剖画像を示すことに加え、対話式３－Ｄボリュームセグメント化プロセス中に、血液プール境界がどこであるかをさらに明確にするために、血液速度画像（ベクトルありまたはなし）が、解剖画像に重ねられてよい。

【0139】

適応的フラッドフィル
システムは、フラッド中に使われる接続性（６、１８、または２６方向接続性）によって、２－Ｄ対３－Ｄ、およびステップの最大数によって半径制約対フラッド制約として区別されることが可能である様々なタイプのフラッドを利用する。すべてのケースにおいて、フラッドは、指定されたシード点から外に動くこと、ならびにピクセルが、１）フラッドの残りに（どのような接続性が指定されていても、それを使って）接続されている、２）シード点でピクセルの指定された閾値内の強度を有する、および３）ピクセルがシード点の最大数のステップの指定された半径以内にある、場合、フラッドの結果にピクセルを含めることによって働く。フラッドの結果は、２または３次元の接続されたマスクである。フラッドアルゴリズムは、静的／非静的組織をマークするための３－Ｄフラッドの形の立体中、短軸スタックにおいて輪郭を生成するのに２－Ｄフラッドが使われてよいボリューム中、およびフラッド内に含まれるフローを決定するために血管をフラッドするのに２－Ｄフラッドが使われてよいフロー定量化中で使われる。

【0140】

半径制約２－Ｄフラッドから輪郭を生成するために、我々は、フラッドが必ずしも接続されないこと、およびそれがバイナリ画像であることを利用する。これらのことにより、我々は、フラッドの内側に存在する可能性があるどの穴も無視する輪郭を見出すためのアルゴリズムをたどる標準ボーダーを適用することができる。

【0141】

生成された輪郭から、次の操作は、潜在的には数百の点から、閉３次スプラインによって使われるべき制御点の小さいセットまで、生成された輪郭を低減して、実際の輪郭を正確に近似することである。輪郭の辺りで等しく離間された一定数の制御点をシステムが単に離間する単純なダウンサンプルは、他の手法のようにはうまくいかず、というのは、この手法は頻繁に、乳頭筋の周りにあったフラッドのくぼみ部分など、輪郭における重要な特徴の損失という結果になるからである。これを回避するために、いくつかの作用で進む「スマート」ダウンサンプル手法が利用される。始めに、輪郭中の各点は、－１から１にわたるコーナー強度スコアを割り当てられ、ならびに、各点に「影響」エリアを割り当てる。これが行われると、輪郭は、影響エリア内でコーナー強度が最大である点のみにまで低減される。我々が最小点間隔を有することを確実にし、我々の検出されたコーナーが十分に強力であることを確実にするなどの追加基準も、この段階において強制される。先行操作の結果は、フラッド中で検出された「コーナー」のリストである。これらをスプライン中の制御点として使うことによって、この手法は、スプラインが、輪郭中のどの興味深い特徴も失わないことを確実にする。ただし、元の輪郭中の比較的低い曲率のどの長い伸びもコーナーとして検出されることはなく、これは、結果として生じた輪郭の大幅な部分が、どの制御点ももたないという結果になる場合があり、そのようなセグメント中のスプラインによる乏しい近似につながる。これを回避するために、点を通じて通る元の輪郭のセグメント、およびそれらの点を通じて通るスプラインのセグメントによって形成された閉輪郭のエリアを算出することによって、制御点の各ペアについてエラーメトリックが計算される。エラーが、何らかの固定された許容差を上回る場合、別の制御点が、元の輪郭のセグメントの中点で追加される。この操作は、各セグメントが、求められる許容差を下回る計算されたエラーを有するまで繰り返される。

【0142】

このフラッド－輪郭ツールは、アプリケーション中の少なくとも２つの場所において、すなわち、ボリュームセグメント化を実施しながら、心室のスライスをフラッドするために、およびフロー定量化において使われてよい。ボリューム向けのフラッドのケースにおいて、戻された輪郭は、心室のより多くをキャプチャするために、８％膨張され、というのは、未加工フラッドフィルはしばしば、単に心臓壁に接近したピクセル強さの差のせいで、過小評価するからである。フローフラッドのために、結果は、フラッドツールが解剖に対して働きかけるので、１２％膨張され、これは、膨張されていないフラッドはしばしば、血管壁の近くのフローを逃すことを意味する。

【0143】

全体的プロセス
自動化されたレポート
超音波心臓検査レポートが生成されるのと同様のやり方で、４－ＤフローＭＲデータに基づく自動化されたレポートが、それらが有する患者のタイプをユーザがクリックすることを可能にすることによって作成されてよい。Ａｒｔｅｒｙｓは、ユーザの一定の病理またはタイプ（すなわち、患者または臨床医）に特有である一意のレポートテンプレートを有する。このレポート中の値、曲線、画像、およびシネ動画はすべて、レポートテンプレートに自動的に投入されてよい。目標は、前処理ステップの一部として置かれるので、重要な情報はすべて、データベース中に自動的に保存され、このレポートにエクスポートされてよい。

【0144】

自動化された統合テスト
自動化された統合テストを実施するための、ｎｏｄｅ．ｊｓを使ってクライアント側ウェブアプリケーションを作るように設計されるｎｏｄｅ－ｗｅｂｋｉｔと呼ばれるツール。この目的のために設計されているのではないが、それは、我々に、同じときにクライアントおよびサーバアプリケーションにわたる完全制御を可能にする同じ環境内でクライアントおよびサーバソフトウェアスタックの両方を我々が稼動することを可能にする。ｍｏｃｈａと呼ばれるテストツールとミックスされたインフラストラクチャを使って、我々は、クライアントとの顧客対話をエミュレートするテストを書くと同時に、アプリケーションの、結果として生じた状態とともに、その対話のクライアントおよびサーバ処理の両方を明示する。統合実験のこの方法は、革新的であり、このタイプのユーザインタフェース実験のためには、ほとんど視覚ベースである他のツールより優れている。

【0145】

ハイブリッドクライアントサーバレンダリング
説明：いくつかのワークフローは、リンクされたプロパティを有する１つまたは複数の画像が同じときにレンダリングされることを求める。いくつかのケースにおいて、現在のワークフローステップは、２０個の画像の同時閲覧を求める場合がある。これらの画像の各々が、異なるＨＴＴＰＳ要求で取り出された場合、要求を作成し、送る際に大幅なオーバーヘッドが存在するので、性能は、大きく損害を受ける。その代わりに、我々は、画像をすべて、１つの大きい画像の上にレンダリングし、その「スプライトシート」についての単一のＨＴＴＰＳ要求を行うだけである。クライアントは次いで、ピクセルオフセットを使うことによって画像を表示する。たとえば、ビューが、各々が２５６×２５６である４つの画像を有していた場合、スプライトシートは、２５６×１０２４であってよく、画像の各々が、別の画像の上にスタックされる。クライアントは次いで、０、２５６、５１２、および７６８のオフセットを使うことによって、４つの画像を２５６×２５６で表示する。

【0146】

さらに、画像中のいかなる線、マーカ、または面も、クライアント上でオーバーレイとして描かれ、オーバーレイをどのようにしてレンダリングするかをクライアントに知らせる情報は、ＪＳＯＮメッセージを介してサーバから来る。これは、オーバーレイがサーバ上でレンダリングされ、次いで、ＪＰＥＧとして符号化され、送信されるべきであった場合よりも高い品質の、オーバーレイデータのレンダリングを提供する。

【0147】

自動化された大域的耐性および応力実験
負荷実験および耐性実験を実施するために、我々は、我々が実行環境に対する完全制御を有する専門ウェブブラウザを開始するために、多数のコンピュータ（地理的に分散されてよい）上で多数のクライアントプロセスを起動する。それらは、アプリケーションを対象とし、規定のブラウザがするようにクライアントをロードし、次いで我々は、ソフトウェアを制御するとともに一定の作業負荷として振る舞わせるクライアント状態と直接対話する。クライアントおよびサーバメトリックは、負荷実験中に記録され、耐性実験のために、より長い期間稼動する。

【0148】

データを医療デバイスからリモートサーバにプッシュするプッシャ
我々は、活発なスタディを監視し、結果をクラウド中の我々の遠隔サービスにプッシュするためのソフトウェアを開発した。スキャナによって生成されるファイル用のフォルダが監視され、完了すると、すべての関連データが合わせてバンドリングされ、認可のために、スキャナごとに一意の秘密およびキーを使う安全な接続を介して、我々の遠隔クラウドサーバにプッシュされる。ディスク空間（たとえば、非一時的記憶媒体）使用は、どの中間ファイルも直ちに消去することによって最小限にされる。

【0149】

成功した転送のとき、転送された内容のデータ完全性が、パッケージプロセスを再生し、暗号学的ハッシュ関数の出力を比較することによって、ローカル内容と突き合わせて検証される。このようなプロセスを繰り返すことは、Ａｒｔｅｒｙｓサーバへのデータの時期尚早な転送をトリガすることがあるスキャニングプロセス中の遅延のケースにおいて、スキャンによって生成された可能性があるどの新規データも見落とされなかったことを確実にする。

【0150】

失敗した転送のケースにおいて、サーバまたはネットワークエラーのせいで、転送が失敗だったとプッシャが仮定する前に、各試行の間の残りの、増大する間隔で、構成可能な数の試行が行われる。ただし、失敗した転送（すべての後続試行を含む）の後、プッシャは、着信ファイルを監視し続け、以降の時間に別の転送を試み直す。

【0151】

データが首尾よく転送されたと検証されると、データは、我々のソフトウェアによって削除されて、スキャナ上のディスク空間を保存する。

【0152】

スキャナのローカルログデータおよび詳細な状況情報を提供するあらゆるスキャナ上で稼動する各プッシャソフトウェアから心拍メッセージが送られ、継続的監視および増大された応答時間を提供して、不可欠なスキャン時間中のスキャナ機能性を確実にする。

【0153】

初期インストール中、スキャナは、認可目的のためにすべての将来の要求に署名するための一意の秘密およびキーを要求することによって、Ａｒｔｅｒｙｓに自動的に登録する。スキャナは、我々のシステムデータベース中に登録されるが、どの団体にも付加されない。技師は次いで、すべての最近登録されたスキャナを、ウェブポータルを通じて正しい団体に付加することが可能である。

【0154】

プッシャは、Ａｒｔｅｒｙｓに対して新規バージョンを定期的に要求することによって、自動更新する（構成されない場合）ことが可能である。新規バージョンは、提供された場合、それ自体の新規コピーをインストールし、リスタートする。これは、技師からの介入なしで、セキュリティおよび機能性更新がスキャナに展開されることをできるようにする。心拍メッセージは、Ａｒｔｅｒｙｓサーバに対するこの操作の成功を確実にすることを求められる情報を提供する。心拍は、我々が、最近更新されていないどのプッシャも決定し、病院に直接接触することを可能にして、すべてのソフトウェアが最新および安全であることを積極的に確実にする。

【0155】

図３Ａ～３Ｂは、例示的なプロセス３００を示す。
プラー－アーティファクトのアーカイブ
プラーソフトウェアは、病院で、生成されたアーティファクトをアーカイブするのに使われる（たとえば、ＰＡＣＳ）。それは、病院のネットワーク内でインストールされ、プッシャと同様の方法を使って、それ自体をＡｒｔｅｒｙｓに自動的に登録する。何らかの識別用情報で要求が行われ、秘密およびキーペアが、認証および認可目的で将来の要求に署名するために戻される。プラーは次いで、ウェブポータルを通じて技師によって団体に付加される。

【0156】

インストールプロセスに自動的に含まれる一意のキーおよび秘密を用いて、団体向けのバージョンを直接ダウンロードすることも可能であり、したがって、インストールされると、プラーを自動登録し、付加する必要がない。

【0157】

アーティファクトエンドポイント向けの構成は、Ａｒｔｅｒｙｓサーバ上で行われる。ホスト名、ポート、ＡＥタイトル、およびプラーがデータをそこに転送する必要がある他のどの必要な情報ももつ、複数のロケーションが構成されてよい。これらのエンドポイントは名前がつけられてよく、臨床医によって、自分たちのアーティファクト（レポート／スクリーンショット／ビデオ）をどこにアーカイブしたいかを選ぶとき、ＡｒｔｅｒｙｓウェブＵＩから選択可能である。

【0158】

プラー（ｐｕｌｌｅｒ）は、定期的および頻繁な間隔でＡｒｔｅｒｙｓ ＡＰＩに対してリストを要求することによってアーティファクトを監視する。アーティファクトのリストは、一意のｉｄ、およびアーティファクトが記憶される、エンドポイントについての構成情報すべてを含む。一意のＩＤは、Ａｒｔｅｒｙｓサーバからアーティファクトを取り出すための、別のＡＰＩ要求への入力として使われる。アーティファクトは、求められる場合はアンジップ（ｕｎｚｉｐｐｅｄ）され、リスト要求（たとえば、ｓｔｏｒｅｓｃｐ）に含まれる構成によって定義された構成および方法を使って転送される。すべてのデータが転送されると、提供されたＩＤを使う別のＡＰＩ要求がＡｒｔｅｒｙｓに対して行われて、アーティファクトをアーカイブ済みとしてマークし、それは、プロセスループ中の最初の要求によって生成されたリスト中にそれ以上現れない。アーティファクトが、アーカイブ済みとしてマークされると、Ａｒｔｅｒｙｓサーバは、アーカイバルが完了したことをユーザに通知する。

【0159】

プラーは、すべてが期待されている通りに機能していることを検証し、確実にするのを助けるための詳細なログを提供するＡｒｔｅｒｙｓに対して、心拍要求を送る。プラーはまた、時々、すなわち構成可能な時間に（たとえば、１時間または１日に一度）、プラーソフトウェアの新規バージョンについて、ＡｒｔｅｒｙｓへのＡＰＩ要求を行う。新規バージョンは、利用可能な場合、ダウンロードされ、インストールされ、プラーはそれ自体をリスタートする。

【0160】

アーティファクトのリストを取り出すための例示的要求

【0161】

【表1】

【0162】

図４Ａ～４Ｂは、アーティファクトおよびアーカイブを監視する例示的プロセス４００を示す。

【0163】

我々は、サービスプロバイダに機密情報を開示することなく、サービスからクライアントアプリケーションに機密患者情報を安全に配信するための方法を開発した。

【0164】

サービスプロバイダに送られる前のデータは、サービスに登録されている、すべての患者識別可能健康情報を取り去られ、元の機密データは、サービスによって提供される一意のトークン識別子で置き換えられる。

【0165】

サービスプロバイダと対話しているときのクライアントは、これらのトークンを識別し、トークンを機密患者健康情報で置き換えるのに、独立トランスポートレイヤを使う。

【0166】

以下は、このようなシステムの可能な実装形態の例である。

【0167】

行為者：
クライアントソフトウェアと対話するユーザ（ユーザ）
クライアントアプリケーション（クライアント）
機密患者情報を保持するサービス（サービス）
アプリケーションサービスプロバイダ
１．ユーザは、アプリケーションサービスプロバイダに送りたいファイルのセットを、ソフトウェアに示す。
２．各ファイル機密について、すべての機密情報が、ＪＳＯＮフォーマットで集められ、ｈｔｔｐ要求上でサービスに登録される。
例：

【0168】

【表2】

３．機密データは、＃｛ＰａｔｉｅｎｔＮａｍｅ｝などのプレースホルダで置き換えられ、次いで、データは、サービスから戻されたロケーションｕｒｌとともにアップロードされる。

【0169】

４．クライアントがアプリケーションサービスプロバイダからデータをロードするとき、これらの機密トークンを含むストリングは、クライアントアプリケーションに、サービスプロバイダに対してデータを要求させる（個々に、または一括して、のいずれかで）。
例：

【0170】

【表3】

５．クライアントは、トークンを機密情報で代用する。

【0171】

注：認可のために、我々は、ｓａｍｌ２などのｓｓｏを使う場合がある。
作業空間
作業空間は、ソリューション（ｓｏｌｕｔｉｏｎ）、医療ソフトウェア全体でアプリケーション状態のサブセット（ｓｕｂｓｅｔ）を記憶し、共有するという問題である。

【0172】

作業空間は、どの分析も含むスタディのアプリケーション状態を含み、ロードされると、アプリケーション、前の状態を復元する。アプリケーション状態は、測定およびＥＣＣ補正値などを含むスタディ検討など、特定の懸念に関連した構成要素状態のサブセットを含む。

【0173】

作業空間は、ユーザがソフトウェアと対話する間、ロードされ、絶えず更新されてよい。ユーザは、スタディを初めてロードするとき、および直近に使われた適用可能作業空間をリロードすることがロードされたとき、個人的なデフォルト作業空間から始める。

【0174】

ユーザは、グループまたはより多くのユーザにスタディを公表することができ、これは、レポート生成および外部システム通知のためのトリガとしても働くことができる。

【0175】

公表された作業空間を初めて開くとき、作業空間の個人的コピーが、作成され、後続リロードにおいてもロードされる。公表されたスタディは不変であり、決して修正されてはならない。

【0176】

医療撮像を用いるマシンラーニング
クラウドインタフェースを用いると、今では、マシンラーニングを使って予測を見出すために、複数のソースからの統計を集約することが可能である。これらの複数のソースは、団体における複数の人々、またはそれどころか世界中に分散された複数の団体によって生成された結果であってよい。集約されることが可能である統計は、医療撮像ピクセルデータ、医療撮像メタデータ（たとえば、ＤＩＣＯＭヘッダ）、およびたとえば患者の電子医療記録（ＥＭＲ）であってよい。ラーニングは、ユーザレベルで、団体レベルで、またはそれどころかマクロレベルで（たとえば、大域的に）適用されてよい。

【0177】

医療画像を自動的に定量化し（たとえば、注釈をつけ、測定し、セグメント化し）ようとするケースにおいて、ディープラーニング、マシンラーニングまたは人工知能の２つの異なるカテゴリがあってよい。すなわち、医療撮像アプリケーション用には、そこから学習するべき十分なデータがないので、監視されるラーニングがより適切である。可能な限り有効に学習するために、クラウドユーザインタフェースは、構造化された様式でユーザがデータにラベルを追加することを可能にするようにあつらえられている。たとえば、心血管撮像のケースにおいて、ユーザは、いくつかの測定を行い、測定に、自分が望むようにラベル付けすることができる。完全にユーザ定義されたフィールドを可能にする代わりに、Ａｒｔｅｒｙｓが提供する、予め定義されたリストからラベルをユーザが選択するためのオプションがある。これを行うことによって、我々は、構造化および自動化された様式でデータにラベルを追加することができる。ラベル付けされたデータは、アルゴリズムが、新規のラベル付けされていないデータに基づいて出力結果を予測することができるように、マシンラーニングアルゴリズム（すなわち、ランダムフォレストまたはディープラーニングＣＮＮまたはＲＮＮのように）に供給するためのトレーニングデータセットとして作用する。たとえば、ユーザ検討プロセスにおける１つの任意選択のステップは、彼らが、自分がデータに追加したラベルに満足であることを確認するように自分の作業空間または状態を「公表する」ものである。「公表」機構は、ユーザが「保存する」ためにクリックする、ユーザインタフェースにおけるアイコンであってよく、またはアーカイブするために（たとえば、病院ＰＡＣＳサーバに）送られる結果であってよい。ダミー測定および注釈を作成するユーザを、真の臨床測定および注釈で見分けるやり方だけが存在する必要がある。

【0178】

クラウドインタフェースの利益は、提供された提案に対する、システムインタフェース内で、ユーザがいかなる修正も行う度に、この修正が次いで、マシンラーニングラベル付きデータに保存され、フィードバックされることである。これは、非常に価値あるトレーニングデータを追加する補強ラーニングループを作成する。マシンラーニングアルゴリズムによって提供された提案は、ユーザがログインしたときに一度、またはユーザがセッション中に修正を行う度にリアルタイムに提供されればよい。たとえば、ユーザが、解剖である医療画像中のボクセルを識別したとき、すべての同様のボクセルが、セッション中にリアルタイムに識別されてよい。

【0179】

特定の治療の出力結果を予測し（かつ、結果として生じた確率測度を与える）、またはどの治療選択が特定の患者により適しているかを予測しようとするケースにおいて、ＥＭＲからのデータは不可欠である。ラベル付けされた医療デバイスデータ（たとえば、医療撮像、ゲノムデータ、装着品）へのアクセスを有することは、最良治療決定を決定するのに十分でない。このデータは、同様の医療デバイスデータを有する新規患者に予測をもたらすように、すべての遡及ケースにわたって集約される必要がある。

【0180】

マシンラーニングはまた、医療画像中での探索に使われてよい。ユーザは、探索フィールドにタイプ入力し、たとえば特定のタイプの疾患を有するすべての画像を見つけることができる。ユーザは次いで、提示されたスタディがすべて、この疾患を有することを検証することができ、このデータは次いで、トレーニングデータセットにフィードバックされてよい。

【0181】

ピクチャおよびビデオサービス
我々は、ユーザが、ユーザのワークフローの現在の状態のピクチャおよびビデオをキャプチャすることが可能であることを望む。これらの画像およびビデオは、我々のサーバ上で生成された画像データと、クライアントブラウザ上でレンダリングされたオーバーレイの両方を含む必要がある。これを遂行するために、我々は、我々のクライアントとサーバソフトウェアスタックの両方を同じ環境内で我々が稼動することを可能にするｎｏｄｅ－ｗｅｂｋｉｔベースビデオサービスを有している。我々は次いで、ユーザの作業空間の現在の状態をｎｏｄｅ－ｗｅｂｋｉｔ環境上で復元し、そのユーザのセッションに割り振られた同じ計算ノードを活用する。ユーザによって単一のピクチャが要求される場合、サービスは単に、復元された作業空間のスクリーンショットを撮り、結果として生じた画像ファイルが戻される。ビデオ要求のケースにおいて、サービスは、現在のワークフローの各フレームについてのスクリーンショットを撮り、ビデオエンコーダを使って、スクリーンショット画像をビデオファイルにコンパイルし、それは次いで、戻される。戻された画像またはビデオは、サーバ上で記憶されるか、または閲覧されるようにクライアントに対して返送されてよい。

【0182】

以下は、ピクチャおよびビデオサービスのための詳細なソフトウェア設計の例である。
スクリーンショットおよびビデオキャプチャ
～～～～～～～～～～～～～～～～～～～～～～～～
要件
＾＾＾＾＾＾＾＾＾＾＾＾＾
＊スクリーンショットは、ユーザが現在、ビューポートエリアにおいて見ているもののレンダリングであるべきである
＊ビデオは、時間を通じて循環されるｍｐｒであってよい
＊ビデオは、補間されることが可能であるパラメータを補間する中間物をもつキーフレームの集合体から生成されてよい
＊ビデオは、ユーザ対話記録であってよい
＊出力は、ビューポート上にあるあらゆるもの（画像、ｗｅｂｇｌオーバーレイ、ｃｓｓオーバーレイ、．．．）を含むべきである
＊スクリーンショットおよびビデオフレームはフル品質であるべきである
設計
＾＾＾＾＾＾＾
我々は、クライアント上であらゆるものをレンダリングするので、クライアントが画像を生成することを必要とする。
残念ながら、ビデオをアップロードすることは、ネットワーク状況の大多数において禁止される。
したがって、スクリーンショット／ビデオサービスは、クライアントレンダリング技術を使うクラスタ中で稼動する。
それは、要件において定義された機能性を提供するために、ｈｔｔｐ上でインタフェースを露出する。
サービスは、ノードウェブキットプロセスをオンデマンドでスピンアップして、要求が入ってくるとビデオおよびスクリーンショットをレンダリングする。
画像または画像の集合体をレンダリングするための要求を受信すると、サービスは、ノードウェブキットプロセスを起動し、ユーザのワークリスト用の署名付きＵＲＬにリダイレクトする。
ｎｏｄｅ－ｗｅｂｋｉｔプロセスは次いで、スタディをロードし、ユーザの作業空間を注入する
次に、各フレームが十分な品質でレンダリングされる。
フレームがレンダリングされると、ｎｏｄｅ－ｗｅｂｋｉｔは、Ｘ１１スクリーンキャプチャを実施し、キャンバスビューポートにクロップする。
画像はディスクへ保存される。
すべてのフレームがキャプチャされると、サービスはスクリーンショットを戻し、またはビデオのケースにおいては、
ビデオがエンコードされ、戻される。
データフロー
＾＾＾＾＾＾＾＾＾＾
＊ユーザが、スクリーンショットまたはビデオについての要求を始動する。
＊ウェブサーバが要求を受信する
＊ｎｏｄｅ－ｗｅｂｋｉｔプロセスが開始される
＊ｎｏｄｅ－ｗｅｂｋｉｔプロセスが、求められたスタディをロードすることを認証されたセッションを開く
＊要求されたスタディがロードされる
＊要求中の作業空間がスタディに注入される
＊作業空間ロード（ストリームラインのような長く稼動するタスクを含む）が完了すると、キーフレームをレンダリングし始める
＊あらゆるフレームが、デバウンスした画像コマンドなしで、十分な品質でレンダリングされる
＊画像がレンダリングされるとき、Ｘ１１スクリーングラブ（ｘｗｄ）がウィンドウ上で実行される
＊画像は、ビューポートへクロップされ、ディスクへ保存される
＊ビデオが要求された場合、画像が生成されると符号化が稼動する
＊すべての画像が完了すると、．ｐｎｇまたは．ｍｐ４でｈｔｔｐ応答が返送される
＊ウェブサーバが結果を受信すると、結果は、Ｓ３で保存され、参照はデータベースへ保存される
追加ツールおよび最適化
＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾
＊ｎｏｄｅ－ｗｅｂｋｉｔはｗｅｂｇｌを求めるので、サービスは、Ｇ２インスタンス上で稼動する必要がある
＊「ｘ１１－ａｐｐｓ」におけるプログラム「ｘｗｄ」がウィンドウをキャプチャすることができる
＊ＩｍａｇｅＭａｇｉｃｋ「ｃｏｎｖｅｒｔ」は、ｘｗｄをｐｎｇにコンバートすることができる
＊ｆｆｍｐｅｇは、．ｐｎｇの集合体から．ｍｐ４を生成するのに使われてよい
詳細
＾＾＾＾＾＾＾
スクリーンショット
＋＋＋＋＋＋＋＋＋＋＋
クライアントメッセージ：
－－－－
ｗｓ．ｅｍｉｔ（‘ｇｅｎｅｒａｔｅ－ｓｃｒｅｅｎｓｈｏｔ’，ｐａｒａｍｓ）；
－－－－
ｐａｒａｍｓ：
－－－－
｛
ｗｏｒｋｓｐａｃｅ＿ｉｄ：‘ｗｏｒｋｓｐａｃｅ－ｉｄ’，
ｉｄ：‘ａｐｐ－ｉｄ’，
ｓｔｕｄｙ＿ｉｄ：‘ｓｔｕｄｙ－ｉｄ’，
ｕｐｌｏａｄ＿ｉｄ：‘ｕｐｌｏａｄ－ｉｄ’，
ｗｉｎｄｏｗ＿ｗｉｄｔｈ：‘ｂｒｏｗｓｅｒ＿ｗｉｎｄｏｗ＿ｗｉｄｔｈ’，
ｗｉｎｄｏｗ＿ｈｅｉｇｈｔ：‘ｂｒｏｗｓｅｒ＿ｗｉｎｄｏｗ＿ｈｅｉｇｈｔ’，
ｈｏｓｔｎａｍｅ：ｗｉｎｄｏｗ．ｌｏｃａｔｉｏｎ．ｈｏｓｔｎａｍｅ，
ｐｏｒｔ：ｗｉｎｄｏｗ．ｌｏｃａｔｉｏｎ．ｐｏｒｔ，
ｐａｔｈｎａｍｅ：‘／ａｐｐ／ｘｘｘ’
｝
－－－－
ビデオ
＋＋＋＋＋
クライアントメッセージ：
－－－－
ｗｓ．ｅｍｉｔ（‘ｇｅｎｅｒａｔｅ－ｓｃｒｅｅｎｓｈｏｔ’，ｐａｒａｍｓ）；
－－－－
ｐａｒａｍｓ：
－－－－
｛
／／スクリーンショットプラスと同じ
ｒｅｎｄｅｒ＿ｆｒａｍｅｓ：［
｛
ｏｒｉｅｎｔａｔｉｏｎ：［１，０，０，０，１，０，０，０，１］，
ｐｏｓｉｔｉｏｎ：［０，０，０］，
ｔｉｍｅｐｏｉｎｔ：１
．．．
｝，
｛
ｏｒｉｅｎｔａｔｉｏｎ：［０，１，０，１，０，０，０，０，１］，
ｐｏｓｉｔｉｏｎ：［０，０，０］，
ｔｉｍｅｐｏｉｎｔ：２
．．．
｝
．．．
］，
ｂｅｔｗｅｅｎｓ：ｏｐｔｉｏｎａｌ＿ｎｕｍｂｅｒ＿ｏｆ＿ｆｒａｍｅｓ＿ｔｏ＿ｉｎｔｅｒｐｏｌａｔｅ＿ｂｅｔｗｅｅｎ＿ｆｒａｍｅｓ
｝
－－－－

【0183】

ウェブサーバハンドラ
＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋
「ｇｅｎｅｒａｔｅ－ｓｃｒｅｅｎｓｈｏｔ」用のメッセージハンドラは、ウェブキットサービスに対して送られるａｒｇｓに現在の作業空間を付加する
ｗｅｂｋｉｔ－ｃｌｉｅｎｔモジュールは次いで、ウェブキットサービスのうちの１つに対して要求を送るのに使われる。
応答が受信されると、記録がデータベースに挿入され、画像またはビデオが記憶される。

【0184】

Ｗｅｂｋｉｔ－Ｃｌｉｅｎｔ
＋＋＋＋＋＋＋＋＋＋＋＋＋
ｗｅｂｋｉｔ－ｃｌｉｅｎｔモジュールは、スクリーンショット要求を、それを扱うことができるノードに対して経路指定することを担当する。
ｗｅｂｋｉｔ－ｃｌｉｅｎｔは、現在稼動しているウェブキットノードによって公表されるｒｅｄｉｓメッセージに加入する。
これらのメッセージは、それで稼動しているａｐｐ－ｉｄで稼動している、ｎｏｄｅ－ｗｅｂｋｉｔの既存のインスタンスを含む。
要求が受信されると、ｗｅｂｋｉｔ－ｃｌｉｅｎｔは、要求されたａｐｐ－ｉｄで稼動するｎｏｄｅ－ｗｅｂｋｉｔをすでに有しているノードを見つけようと試みる。
あるいは、セッションがまだ作成されていない場合、最小数の稼動セッションをもつノードを選ぶ。
ノードは、識別されると、ＨＴＴＰＳ上でそのホストに対してメッセージを送る。
引数が、本文中で、経路「／ｗｅｂｋｉｔ／ｅｘｅｃｕｔｅ」までのＰＯＳＴ中のＪＳＯＮとして送られる。
結果が戻ると、タイプ（ｉｍａｇｅ／ｐｎｇまたはｖｉｄｅｏ／ｍｐ４）を、収集された他の有用情報（たとえば、タイミング情報、サイズ）とともに含むバイナリおよびＪＳＯＮブロブで、コールバックが呼び出される

【0185】

【表4】

【0186】

Ｗｅｂｋｉｔ－Ｓｅｒｖｉｃｅ
＋＋＋＋＋＋＋＋＋＋＋＋＋＋
ｗｅｂｋｉｔ－ｓｅｒｖｉｃｅは、スクリーンショットおよびビデオを生成するためにＨＴＴＰＳインタフェースを露出するマイクロサービスである。
ｗｅｂｋｉｔ－ｓｅｒｖｉｃｅは、「／ｗｅｂｋｉｔ／ｅｘｅｃｕｔｅ」でＰＯＳＴ要求のみをリッスンする。
「／ｗｅｂｋｉｔ／ｅｘｅｃｕｔｅ」へのＰＯＳＴを受信すると、ｗｅｂｋｉｔ－ｃｏｎｔｅｘｔを作成し、スクリーンショットまたはビデオについての要求をキューに入れる。
このモジュールはまた、特殊「ｗｅｂｋｉｔ－ｓｃｒｅｅｎｓｈｏｔ」ユーザに関連付けられたａｕｔｈトークンを付加することによって、ｎｏｄｅ－ｗｅｂｋｉｔからウェブサーバに対して送られる要求を認可することを引き受ける。

【0187】

Ｗｅｂｋｉｔ－Ｃｏｎｔｅｘｔ
＋＋＋＋＋＋＋＋＋＋＋＋＋＋
ｗｅｂｋｉｔ－ｃｏｎｔｅｘｔモジュールは、スクリーンショットまたはビデオを生成するように稼動するｎｏｄｅ－ｗｅｂｋｉｔプロセスを管理することを担当する。
作成されると、ｗｅｂｋｉｔ－ｃｏｎｔｅｘｔは、中間結果を記憶するための作業ディレクトリを作成する。
次に、それは、単純な「ｉｎｄｅｘ．ｈｔｍｌ」および「ｐａｃｋａｇｅ．ｊｓｏｎ」ファイルを作業ディレクトリ中にコピーすることによって、ｎｏｄｅ－ｗｅｂｋｉｔを構成し、引数を含む「ａｒｇｓ．ｊｓｏｎ」が、スクリーンショット／ビデオをレンダリングするためにコンテキストに渡される。
次いで、ｎｏｄｅ－ｗｅｂｋｉｔが開始され、スクリーンショットを生成するプロセスを通じて稼動する。
ｎｏｄｅ－ｗｅｂｋｉｔが退出すると、ｗｅｂｋｉｔ－ｃｏｎｔｅｘｔは、それで応答するための適切なスクリーンショットまたはビデオファイルを探す。
ａｐｐ－ｉｄごとにただ１つのスクリーンショットが、一度に稼動することができる。
ｗｅｂｋｉｔ－ｃｏｎｔｅｘｔは、ウェブサーバがスクリーンショットおよびビデオ要求を経路指定することができるように、ｒｅｄｉｓにおいてそれ自体を登録する。

【0188】

Ｎｏｄｅ－Ｍａｉｎ
＋＋＋＋＋＋＋＋＋
ｎｏｄｅ－ｍａｉｎモジュールは、ｎｏｄｅ－ｗｅｂｋｉｔ中で稼動するブリッジモジュールである。
ｎｏｄｅ－ｗｅｂｋｉｔは、開始すると、「ｇｌｏｂａｌ．ｗｉｎｄｏｗ」変数が定義されるまで待ち、次いで、ａｒｇｓ．ｊｓｏｎファイルを読み込み、スクリーンショットを生成するためのステップを実行し始める。
これらの引数は、ウィンドウを作るための幅×高さと、ｗｉｎｄｏｗ．ｌｏｃａｔｉｏｎ．ｈｒｅｆをどこに対してリダイレクトするかを示す。
それは、ウェブソケット接続を示すＡｒｔｅｒｙｓ定義変数であるｇｌｏｂａｌ．ｗｉｎｄｏｗ．ｉｏを設定する、ウェブサイトへのリダイレクト点を仮定する。
ウェブソケット接続が行われると、「ｌｏａｄ－ｓｔｕｄｙ」コマンドを呼び出し、「ｌｏａｄ－ｗｏｒｋｓｐａｃｅ－ｃｏｍｐｌｅｔｅ」を待つ。
作業空間を復元することによって呼び出された可能性があるすべてのコマンドが終了されると、ｎｏｄｅ－ｍａｉｎは、画像をキャプチャし始める。
「ａｒｇｓ．ｊｓｏｎ」がフィールド「ｒｅｎｄｅｒ＿ｆｒａｍｅｓ」を含んでいた場合、それは、画像を生成する各々を通じて反復する。
Ｘｗｉｎｄｏｗをダンプするためのｘｗｄを呼び出すことによって、画像が生成される。
ＩｍａｇｅＭａｇｉｃｋ ｃｏｎｖｅｒｔが次いで、ｐｎｇにコンバートし、「．ａｒ－ｃｏｎｔｅｎｔ－ｂｏｄｙ－ｃａｎｖａｓｅｓ」へクロップするのに使われる。
生成された複数の画像があった場合、画像の集合体をｈ．２６４符号化ビデオ中に符号化するために、ｆｆｍｐｅｇが呼び出される。
スクリーンショットまたはビデオが作成されると、ｎｏｄｅ－ｗｅｂｋｉｔはクリーンに退出する。

【0189】

いかなるエラーも、ｎｏｄｅ－ｗｅｂｋｉｔを非ゼロコードで退出させ、これは、スクリーンショットが失敗したことをｗｅｂｋｉｔ－ｃｏｎｔｅｘｔに対して示す。
ＰＨＩサービス
図５は、１つの図示される実施形態に従う、医療分析学システムまたはプラットフォーム５００のためのネットワーク化環境を示す。プラットフォームは、医療プロバイダ（たとえば、病院）ネットワーク５０８（１つが図示されている）に関連付けられた様々なシステムとファイアウォール５０６を通じて通信するＡＳＰシステム５０４（たとえば、１つまたは複数のプロセッサベースデバイス）を備える分析学サービスプロバイダ（ＡＳＰ）ネットワーク５０２を備える。ＡＳＰシステム５０４は、上で論じられた様々な機能性の一部または全部を提供する。たとえば、ＡＳＰシステム５０４は、たとえば、図１の画像処理および分析システム１０４と同様または同一であってよい。ＡＳＰシステム５０４は、クラウドアーキテクチャを使って実装されてよく、したがって、いくつかの分散されたプロセッサベースデバイスを備えることができる。ＡＳＰシステム５０４は、たとえば、ファイアウォール５０６を介してアクセス可能な１つまたは複数の通信ネットワークを介して外部システムにアクセスすることができる。

【0190】

医療プロバイダまたは病院ネットワーク５０８は、ファイアウォール５１８を介して１つまたは複数の外部ネットワーク（たとえば、インターネット）に動作可能に結合された１つまたは複数の被保護健康情報（ＰＨＩ）システム５１０（１つが図示されている）を含むことができる。医療プロバイダネットワーク５０８は、ＰＨＩサービス５１０に動作可能に結合されたセキュリティアサーションマークアップ言語（ＳＡＭＬ）サービス５１２も含むことができる。本明細書において論じられる実装形態のうちの少なくともいくつかにおいて、ＳＡＭＬサービス５１２は、ＰＨＩシステムまたはサービス５１０の一部であるか、または統合されていると見なされてよい。

【0191】

ＰＨＩシステム５１０は、ＭＲＩマシン５１５（図７）およびホストコンピュータシステム５１７（図７）を含むＭＲＩ獲得システム５１４に動作可能に結合されてよい。ＰＨＩシステム５１０はまた、他のデータの中でも、ＭＲＩ獲得システムから受信された医療スタディデータを記憶するデータベース５２４または他の非一時的プロセッサ可読記憶媒体に通信可能に結合されてよい。医療スタディデータは、ＭＲＩデータ、４Ｄフローデータ、あるいはＰＨＩまたは他の保護された、もしくは個人情報を有する場合がある他のどのタイプのデータも含むことができる。図８に示されるように、ＰＨＩシステム５１０は、画像保管通信システム（ＰＡＣＳ）５２５または医療プロバイダに関連付けられた他の宛先ストレージに通信可能に結合されてよい。

【0192】

ＭＲＩ獲得システム５１４は典型的には、臨床施設、たとえば病院または専用医療撮像センターに位置する。ＭＲＩ獲得システム５１４は、図１のＭＲＩ獲得システム１０２と同様または同一であってよい。本明細書において説明される様々な技法および構造は、有利には、ＡＳＰシステム５０４がＭＲＩ獲得システム５１４から離れて位置することを可能にすることができる。ＡＳＰシステム５０４は、たとえば、別の建物、市、州、地域または国にさえも位置する場合がある。

【0193】

ＡＳＰシステム５０４は、着信要求および応答を扱うための１つまたは複数のサーバと、１つまたは複数のレンダリングまたは画像処理および分析コンピュータとを含むことができる。サーバは、たとえば、サーバソフトウェアまたは命令を実行する１つまたは複数のサーバコンピュータ、ワークステーションコンピュータ、スーパーコンピュータ、またはパーソナルコンピュータの形をとることができる。１つまたは複数のレンダリングまたは画像処理および分析コンピュータは、画像処理および／または分析ソフトウェアもしくは命令を実行する１つまたは複数のコンピュータ、ワークステーションコンピュータ、スーパーコンピュータ、またはパーソナルコンピュータの形をとることができる。１つまたは複数のレンダリングまたは画像処理および分析コンピュータは典型的には、１つ、および好ましくは複数の、グラフィカル処理ユニット（ＧＰＵ）またはＧＰＵコアを利用することになる。

【0194】

図５は代表的なネットワーク化環境を示すが、典型的なネットワーク化環境は、多くの追加ＭＲＩ獲得システム、ＡＳＰシステム、ＰＨＩシステム、コンピュータシステム、および／またはエンティティを含むことができる。本明細書において教示される概念は、図示されるものよりも密集したネットワーク化環境をもつ同様の様式で利用されてよい。たとえば、単一のＡＳＰエンティティが、複数の診断エンティティに画像処理および分析サービスを提供する場合がある。診断エンティティのうちの１つまたは複数が、２つ以上のＭＲＩ獲得システムを操作する場合がある。たとえば、大病院または専用医療撮像センターが、単一の施設にある２、３またはより多くのＭＲＩ獲得システムさえも操作する場合がある。

【0195】

概して、ＰＨＩシステム５１０は、医療スタディデータ（たとえば、ＤＩＣＯＭファイル）のためのセキュアなエンドポイントを作成することができる。ＰＨＩシステム５１０は、ＰＨＩのファイルを自動的または自律的に取り去り、非識別化された医療スタディデータを、処理および／または分析のためにＡＳＰシステム５０４にアップロードすることができる。さらに、以下で論じられるように、（たとえば、ＶＰＮを介して）医療プロバイダネットワーク５０８へのセキュアなアクセスを有するクライアントプロセッサベースデバイス５２０を操作するユーザに、ウェブアプリケーションが提供されてよい。ウェブアプリケーションは、どのＰＨＩデータもＡＳＰシステムに提供することなく、ＰＨＩシステム５１０からのローカルＰＨＩデータを、ＡＳＰシステム５０４からの非識別化されたデータとマージするように動作する。

【0196】

団体（たとえば、病院、他の医療プロバイダ）は、ＰＨＩシステム５１０をオンサイトで、またはクラウドにおいて実装することができる。ＰＨＩサービスを実装するＰＨＩシステム５１０は、ＰＨＩデータが医療プロバイダのネットワークおよび制御内に留まることを可能にするとともに、ＡＳＰシステム５０４が規制法を満たし、患者プライバシーを確実にしたまま、クラウドにおいて機能することを可能にする。

【0197】

図６のプロセス６００に示されるように、ユーザが、医療プロバイダのネットワーク５０８へのセキュアなアクセスを有するクライアントプロセッサベースデバイス５２０上で実行するウェブブラウザを使って医療スタディ（たとえば、ＭＲＩ）をロードすると、医療スタディデータは、ウェブブラウザ内で、オンデマンドで再識別される。ＡＳＰシステム５０４（たとえば、ＡＳＰシステムのウェブアプリケーションを介して）とＰＨＩシステム５１０のウェブＡＰＩの両方からのウェブアプリケーションによって、一斉にデータが要求される。ＰＨＩデータおよび非識別化されたデータは次いで、アクティブセッション中にクライアントプロセッサベースデバイス５２０上で実行する、ユーザのウェブブラウザ内でシームレスにマージされる。

【0198】

ＰＨＩシステム５１０は、暗号化された接続上で医療スタディデータを転送するための、医療デバイス（たとえば、ＭＲＩ獲得システム５１４）用のＡＰＩを提供することができる。データは次いで、効率的方法で、ＡＳＰシステム５０４にセキュアにアップロードされることが可能である。これは、現在の医療デバイスとの統合の容易さを提供し、医療プロバイダのネットワーク５０８の外で転送されるデータにセキュリティを提供する。ＰＨＩシステム５１０は、医療プロバイダのネットワーク５０８の中および外のすべての通信がセキュアに（たとえば、ＨＴＴＰポート上のＨＴＴＰプロトコル上で）行われることを確実にすることによって、複雑な、デバイスネットワークごとの構成を削減することができる。

【0199】

さらに以下で論じられるように、ＡＳＰシステム５０４のウェブアプリケーション内で生成される２次キャプチャオブジェクトおよびレポートなどのアーティファクトは、医療プロバイダのレポートシステムおよび／またはＰＡＣＳにプッシュバックされる必要がある場合がある。ＰＨＩシステム５１０はセキュアなプロキシとして作用し、ＡＳＰシステム５０４からアーティファクトをプルし、再識別されたデータを、医療プロバイダのネットワーク５０８内の構成されたロケーションにプッシュする。これは、医療プロバイダが、どの着信ネットワーク要求も許可することなく、ＡＳＰシステム５０４によって提供されたサービスを使うことを可能にし、それは、医療プロバイダのネットワークをセキュアに保つ。

【0200】

ＰＨＩシステム５１０は、自己更新中である場合もあり、医療プロバイダのスタッフによる介入を求めることなく、セキュリティ更新ならびに機能性更新を可能にすることができる。

【0201】

図７は、ＤＩＣＯＭファイルからＰＨＩデータを取り去るようにＰＨＩシステム５１０を操作する例示的プロセス７００を示す。ＰＨＩシステム５１０はＤＩＣＯＭファイルを受信し、これらは、ＭＲＩ獲得システム５１４のホストコンピュータシステム５１７からのＰＨＩデータおよびピクセルデータを含む。ＰＨＩシステム５１０は、ＤＩＣＯＭファイルからＰＨＩデータを取り去り、ＰＨＩデータをデータベース５２４中に記憶する。ＰＨＩシステム５１０は、非識別化されたピクセルデータを、上で論じられた様々な機能を実施するための、ＡＳＰシステム５０４による使用のために、ファイアウォール５１８を介してＡＳＰシステム５０４にアップロードする。

【0202】

図８は、医療プロバイダに関連付けられた、登録されたＰＡＣＳサーバ５２５上にユーザ生成レポートを記憶する例示的プロセス８００を示す。示されるように、クライアントプロセッサベースデバイス５２０を操作するユーザは、ウェブアプリケーションを介して、ＡＳＰシステム５０４がレポートを作成することを要求することができる。要求に応答して、ＡＳＰシステム５０４はレポートを生成する。ＰＨＩサービス５１０は、非識別化されたレポートについて、ＡＳＰシステム５０４を時々ポーリングしてよい。ＡＳＰシステム５０４が、利用可能な１つまたは複数の非識別化されたレポートを有するとき、ＡＳＰシステム５０４は、１つまたは複数の非識別化されたレポートを、暗号化された転送を介してＰＨＩシステム５１０に対して送る。ＰＨＩシステム５１０は次いで、受信されたレポートを、後で使うためにＰＡＣＳサーバ５２５に記憶する。

【0203】

図９は、ＭＲＩ獲得システム５１４のホストコンピュータシステム５１７によって受信されたＤＩＣＯＭファイルがＰＨＩシステム５１０によってどのように扱われるかを示す、ＰＨＩシステム５１０の概略図９００である。他のサービスの中でも、ＰＨＩサービス５１０は、スキャナアップロードサービス９０２、非識別化器サービス９０４、アップローダサービス９０６、ＰＨＩ記憶サービス９０８、および状況アグリゲータサービス９１０を含むことができる。これらのサービスの各々は、さらに以下で論じられる。

【0204】

概して、スキャナアップロードサービス９０２は、ＭＲＩ獲得システム５１４のホストコンピュータシステム５１７からＤＩＣＯＭファイルをアップロードすることを担当する。スキャナアップロードサービス９０２はまた、ＤＩＣＯＭファイル処理の状況を状況アグリゲータサービス９１０にポストする。スキャナアップロードサービス９０２はまた、抽出されたＤＩＣＯＭファイルを非識別化器サービス９０４に対して送る。

【0205】

図１２を参照してさらに以下で論じられるように、非識別化器サービス９０４は、ＤＩＣＯＭファイルからどのＰＨＩデータも取り去り、または削除するように機能する。非識別化器サービス９０４は次いで、非識別化されたＤＩＣＯＭファイルをアップローダサービス９０６に対して送り、取り去られたＰＨＩデータをＰＨＩ記憶サービス９０８に対して送り、これは、ＰＨＩデータをデータベース５２４中に記憶する。非識別化器サービス９０４はまた、非識別化状況情報を状況アグリゲータサービス９１０にポストする。アップローダサービス９０６は、非識別化されたＤＩＣＯＭファイルを、ＡＳＰシステムによる処理のために、暗号化された転送プロトコル上で、ＡＳＰシステム５０４に対して送る。

【0206】

図１０は、ＰＨＩサービス依存がどのように編成されるかを示す、ＰＨＩシステム５１０の概略図１０００である。ＰＨＩシステム５１０は、バッシュスクリプト１００４、ドッカー１００６、およびネイティブ実行可能ファイル１００８を備えるベースオペレーティングシステム（たとえば、Ｕｂｕｎｔｕ／ＳＬ７）を含む。ドッカー１００６は、ＰＨＩシステム５１０の様々なマイクロサービス１００２を実装するのに使われるいくつかのドッカーコンテナを含む。図９および１１に示されるように、そのようなマイクロサービス１００２は、たとえば、スキャナアップロードサービス９０２、非識別化器サービス９０４、アップローダサービス９０６、記憶サービス９０８、状況アグリゲータサービス９１０、ＳＳＬプロキシサービス１１０６、アーティファクトサービス１１０８、および起動サービス１１１０を含むことができる。

【0207】

図１１Ａないし１１Ｂ（まとめて、図１１）は、ＰＨＩサービス５１０の起動シーケンスを示すシステムシーケンス図１１００である。起動シーケンスを実装することに関連付けられた構成要素は、サービス制御ノード１１０２、ＰＨＩサービス５１０のキー管理サービス１１０４、ＡＳＰシステム５０４、スキャナアップロードサービス９０２、非識別化器サービス９０４、記憶サービス９０８、ＳＳＬプロキシサービス１１０６、アーティファクトサービス１１０８、および起動サービス１１１０を含む。

【0208】

１１１２および１１１４で、サービス制御１１０２は、記憶サービス９０８を介して、ＡＳＰシステム５０４への署名付き要求を作成する。１１１６で、ＡＳＰシステム５０４は、キー管理サービス１１０４に対して平文データキー（ｐｌａｉｎｔｅｘｔ ｄａｔａ ｋｅｙ）を要求する。１１１８で、キー管理サービス１１０４は、キーをＡＳＰシステム５０４に対して戻し、これは、１１２０で、平文データキーおよび暗号化されたデータキーをＰＨＩシステム５１０の記憶サービス９０８に対して戻す。１１２２で、記憶サービス９０８は、記憶サービス９０８が開始したというインジケーションをサービス制御１１０２に提供する。

【0209】

１１２４で、サービス制御１１０２は、起動サービス１１１０に対して開始コマンドを送る。１１２６ないし１１３０で、起動サービス１１１０は、ＡＳＰシステム５０４を介して、キー管理サービス１１０４に対して平文キーを要求する。１１３４で、起動サービス１１１０は、何も存在しない場合、ボリュームキー（ｖｏｌｕｍｅ ｋｅｙ）を生成する。ボリュームキーは次いで、平文データキーで暗号化され、今では暗号化されたボリュームキーと呼ばれる。暗号化されたボリュームキーは、暗号化されたデータキーとともに記憶される。暗号化されたデータキーは平文データキーを一意に識別し、これは、ＰＨＩシステム５１０が後続の起動においてキーをロールすることを可能にする。１１３６で、起動サービス１１１０は、起動サービスが開始したことをサービス制御１１０２に通知する。

【0210】

少なくともいくつかの実装形態において、ボリュームキーは、ａｅｓ－２５６－ｇｃｍを使って、搭載されたボリューム（たとえば、ドッカーボリューム）を、パラノイアモードでのＥｎｃＦＳファイルシステムとして初期化するのに使われる。ディスクにデータを書き込む必要があるすべての他のサービスは、起動サービス１１１０に対してボリュームキーを最初に要求する必要がある。ボリュームキーはメモリ中に保たれていない場合があるので、要求があると、起動サービス１１１０は、暗号化されたボリュームキーをインメモリ平文データキーで解読し、ボリュームキーを要求元サービスに対して戻す。要求元サービスは次いで、そのボリュームキーを使って、共有されるＥｎｃＦＳボリュームを解読された様式で搭載する。

【0211】

１１３８で、サービス制御１１０２は非識別化サービス９０４を開始する。１１４０で、非識別化サービス９０４は起動サービス１１１０からボリュームキーを得るが、これは、１１４２で、ボリュームキーを非識別化サービスに対して戻す。１１４４で、非識別化サービス９０４は、ボリュームキーを使って、共有されるＥｎｃＦＳボリュームを搭載する。１１４６で、非識別化サービス９０４は、非識別化サービスが開始したことをサービス制御１１０２に通知する。

【0212】

１１４８で、サービス制御１１０２はスキャナアップロードサービス９０２を開始する。１１５０で、スキャナアップロードサービス９０２は起動サービス１１１０からボリュームキーを得るが、これは、１１５２で、ボリュームキーをスキャナアップロードサービスに対して戻す。１１５４で、スキャナアップロードサービス９０２は、ボリュームキーを使ってＥｎｃＦＳボリュームを搭載する。１１５６で、スキャナアップロードサービス９０２は、スキャナアップロードサービスが開始したことをサービス制御１１０２に通知する。

【0213】

１１５８で、サービス制御１１０２はアーティファクトサービス１１０８を開始する。１１６０で、アーティファクトサービス１１０８はボリュームキーを起動サービス１１１０から得るが、これは、１１６２で、ボリュームキーをアーティファクトサービスに対して戻す。１１６４で、アーティファクトサービス１１０８は、ボリュームキーを使ってＥｎｃＦＳボリュームを搭載する。１１６６で、アーティファクトサービス１１０８は、アーティファクトサービスが開始したことをサービス制御１１０２に通知する。

【0214】

１１６８で、サービス制御１１０２はＳＳＬプロキシサービス１１０６を開始する。ＳＳＬプロキシサービス１１０６は、開始するのが最後のものである。ＳＳＬプロキシサービス１１０６は、すべての内部サービスへの外部アクセスを制御する。１１７０で、ＳＳＬプロキシサービス１１０６は、ＳＳＬプロキシサービスが開始したことをサービス制御１１０２に通知する。

【0215】

図１２は、ＰＨＩサービスの非識別化サービス９０４のためのプロセス１２００を示す流れ図である。非識別化サービス９０４は、スキャナアップロードサービス９０２によってアップロードされたスタディを処理すること、すべての情報を収集すること、およびＡＳＰシステム５０４にアップロードすることが安全であることを確実にすることを担当する。非識別化サービス９０４の主構成要素は、ＤＩＣＯＭデータに対して実施される実際の非識別化作用である。少なくともいくつかの実装形態において、ＧＤＣＭプロジェクトからの修正されたｇｄｃｍａｎｏｎユーティリティが使われてよい。

【0216】

プロセス１２００は１２０２で始まり、たとえば、このとき、スキャナアップロードサービス９０２が、スタディ用の抽出されたＤＩＣＯＭファイルを非識別化サービス９０４に対して送る。１２０４で、ＰＨＩ処理モジュールが始動される。１２０６で、いくつかの処理作用１２０８ないし１２２２が実施される。具体的には、１２０８で、処理されるべきスタディを含むフォルダが改名される。１２１０で、すべての非スタディファイル（たとえば、ｓｈａ１ｓｕｍ）が削除される。１２１２で、非識別化サービス９０４は、ＤＩＣＯＭファイルからＰＨＩを抽出する。１２１４で、非識別化サービスはＤＩＣＯＭファイルを非識別化する。すべての抽出されたＰＨＩデータは、あらゆるＤＩＣＯＭファイルについて収集され、記憶されてよく、たとえば、プロセスの終了で記憶サービス９０８に対して送られてよい。

【0217】

１２１６で、非識別化サービス９０４は、不明瞭化されたＵＩＤを抽出する。非識別化作用１２１４は、ＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤを、不明瞭化された値で置き換える。元のデータは、この値によって、ＡＳＰシステム５０４に対して送られるスタディとリンクされる。

【0218】

１２１８で、非識別化サービス９０４は、不明瞭化されたＵＩＤについての衝突チェックを実施して、ＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤと不明瞭化されたＵＩＤとの間に一意のマッピングがあることを確実にする。衝突がある場合、ＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤと不明瞭化されたＵＩＤとの間の一意のマッピングを確実にするために、異なる不明瞭化されたＵＩＤが生成されてよい。

【0219】

１２２０で、非識別化サービス９０４はＰＨＩデータを記憶サービス９０９に対して送り、これは、ＰＨＩデータ１２２０を、たとえばデータベース５２４中に記憶する。１２２２で、非識別化サービス９０４は、フォルダを、非識別化された状態に移す。１２２４で、処理作用１２０６が完了されると、非識別化されたデータは、アップローダサービス９０６によるＡＳＰシステム５０４へのアップロードのためにキューイング（ｑｕｅｕｅｄ）される。１２２６で、プロセス１２００は、たとえば、処理される必要がある別のスタディが見つけられるまで終わる。１２２８で、処理作用１２０８ないし１２２２のうちのいずれでもエラーが検出されない場合、ＰＨＩエラー処理モジュールが実行されてよい。

【0220】

収集されたＰＨＩデータは、２つのレベルの情報、すなわちスタディレベルおよびシリーズレベルで、ドキュメント中で編成されてよい。データは、ＡＳＰシステム５０４によって記憶されたデータとのリンクを提供する、不明瞭化されたＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤによってインデックス付けられてよい。ＰＨＩデータは記憶サービス９０８に対して送られてよく、これは、データを暗号化し、データベース５２４中に記憶する。

【0221】

ＩＳＯ２０２２データを扱うために、（ｄｃｍｔｋプロジェクトからの）ｄｃｍｃｏｎｖユーティリティが使われてよい。ＤＩＣＯＭファイルの削減されたセットからＰＨＩデータを読み取る前に、ＤＩＣＯＭファイルは、ＵＴＦ－８にコンバートされてよい。これは、コンバートされる必要があるファイルの数を制限することによってプロセスを高速化すると同時に、収集されたすべてのＰＨＩデータが整合性のあるフォーマットであることを確実にする。

【0222】

ユーティリティｇｄｃｍａｎｏｎは、ＤＩＣＯＭデータのフォルダにおける非識別化を扱う。ただし、プロジェクトは、２００８ＮＥＭＡ規格に対して非識別化するだけである。したがって、少なくともいくつかの実装形態において、最新のＤＩＣＯＭ規格に準拠するべき、求められたＤＩＣＯＭタグを追加する、ｇｄｃｍａｎｏｎユーティリティの修正されたバージョンが使われる。

【0223】

ユーティリティはまた、ＰＨＩを暗号化し、ＰＨＩを各ＤＩＣＯＭファイル内に新規タグとして記憶する。ＰＨＩシステム５１０は、どの非識別化されたデータも、暗号化されているときであっても送らないので、ユーティリティは、暗号化されたデータの新規タグを挿入するステップをスキップするようにさらに修正される。これは、そのタグを後で削除する追加ステップを追加する必要をなくすことによって、プロセスをさらに高速化する。

【0224】

ＰＨＩシステム５１０が機能するために、必要に応じて、スタディおよびシリーズレベルでのＰＨＩの小さいサブセットのみ。ただし、ＤＩＣＯＭ規格は、より多くのフィールドを削除する。ＰＨＩシステム５１０のデータベース５２４をより小さく保つために、これはユーザのために性能を強化するのだが、ＰＨＩシステムは、求められたデータをデータベース５２４中に記憶するだけでよい。追加フィールドが必要とされるケースにおいて、またはＰＨＩデータを再処理する必要がある場合、各ＤＩＣＯＭファイルから削除された、非識別化されたデータが（たとえば、圧縮され、アーカイブされるＪＳＯＮファイルとして）記憶されてよい。

【0225】

図１３Ａないし１３Ｂ（まとめて、図１３）は、ＰＨＩシステム５１０のアップローダまたはプッシャサービス９０６のためのプロセス１３００を示す流れ図である。プッシャサービス９０６は、２つの主なタスクを有する。第１のタスクは、識別されたスタディをＡＳＰシステム５０４に対して転送することである。第２のタスクは、終了状態に達するまで、アップロードされたスタディの状況を監視し、ＰＨＩシステム５１０の内部状況を更新することである。これは、ホストコンピュータシステム５１７が、スタディについての状況をＰＨＩシステム５１０に対して要求すること、およびＡＳＰシステム５０４から情報を受信することを可能にする。

【0226】

１３０２で、プッシャサービス９０６は、非識別化サービス９０４によって提供された、非識別化されたスタディ用のフォルダを監視する。プッシャサービス９０６は次いで、アップロードファイルプロセス１３０４を始める。１３０６で、プッシャサービス９０６は、非識別化されたデータをバンドルする（たとえば、スタディをｔａｒおよびｇｚｉｐする）。１３０８で、プッシャサービス９０６は、新規バンドルされたファイル（たとえば、ｔａｒファイル）のｓｈａ１ｓｕｍを算出し、ｓｈａ１ｓｕｍは、アップロードの完全性を検証するのに使われ、状況更新を要求するためのキーも提供する。１３１０で、プッシャサービス９０６は、ファイル名がＰＨＩを含まないことを確実にするように、ファイルを改名する（たとえば、「＜ｓｈａ１ｓｕｍ＞．ｔｇｚ」）ことができる。

【0227】

１３１２で、改名されたファイルは次いで、送付リトライループ１３１４を使って、ＡＳＰシステム５０４にアップロードされてよい。送付元リトライループは、試行の間の増大する遅延を伴って、ファイルをアップロードすることを試み続ける。ファイルが、いくつかの試行の後でアップロードするのに失敗した場合、エラーアップロードモジュール１３１６が実行されてよい。アップロードが成功した場合、ｓｈａ１ｓｕｍは、データ完全性を確実にするために検証される。１３１８で、アップロードされたファイルは次いで、ＡＳＰシステム５０４による処理のためにキューイングされる。

【0228】

１３２０で、アップローダサービス９０６は、アップロードされたファイルの状況をリモートに監視することができる。一例として、アップロードまたはサービス９０６は、ｓｈａ１ｓｕｍをルックアップキーとして使えばよい。アップロードされたファイルについての可能な状態は、エラーが起きたことを意味する「エラー処理」、ファイルが処理されている最中であることを意味する「処理」、またはファイルが処理されたことを意味する「処理済み」を含むことができる。

【0229】

記憶サービス９０８は、抽出されたＰＨＩデータを記憶することを担当し、したがってそれは、再識別のために後で取り出されることが可能である。記憶サービスが稼動されると、記憶サービスは、ＡＳＰシステム５０４と通信し、上述したように、平文データキーおよび暗号化されたデータキーを取り出す。これらのキーは次いで、メモリ中に記憶される。記憶サービス９０８がディスクに書き込むどのデータも、平文データキーで暗号化され、データを暗号化するのに使われた平文データキーを識別する、暗号化されたデータキーと一緒に記憶される。

【0230】

図１４Ａないし１４Ｂ（まとめて、図１４）は、クライアントプロセッサベースデバイス５２０（図５）上でウェブアプリケーションを実行するウェブブラウザにおけるデータの再識別のためのプロセス１４００を示すシステムシーケンス図１４００である。１４０２で、ウェブブラウザは、アプリケーションをロードするための要求を、ＡＳＰシステム５０４に対して送る。１４０４で、ＡＳＰシステム５０４は、ウェブブラウザ上にアプリケーションをロードする。ＡＳＰシステム５０４のウェブアプリケーション上で首尾よく認証されたユーザは、ウェブトークン（たとえば、ＪＳＯＮウェブトークン）を与えられてよい。上述したように、このウェブトークンは、データを要求するとき、ウェブブラウザによってＰＨＩシステム５１０に対して送られる。ＳＳＬプロキシサービス１１０６（図１１）は、ユーザが、ウェブアプリケーションへの有効な、認証されたアクセスを依然として有することを確実にするために、すべてのデータ要求を、ＰＨＩシステム５１０の認可サービスに対してフォワードする。これは、ユーザが関わる限り、透明プロセスである。

【0231】

１４０６で、ウェブブラウザは、ＰＨＩシステム５１０についての情報をＡＳＰシステム５０４に対して要求する。１４０８で、ＡＳＰシステム５０４は、ウェブブラウザに対してＰＨＩシステム情報を送る。１４１０で、ウェブブラウザは、ＡＳＰシステム５０４に対してＰＨＩアクセストークンを要求する。ＰＨＩアクセストークンは、暗号化され、ＡＳＰシステム５０４によってのみ読み取られることが可能である。１４１２で、ＡＳＰシステム５０４は、暗号化されたＰＨＩアクセストークンをウェブブラウザに対して送る。

【0232】

１４１４で、ウェブブラウザは、利用可能スタディのワークリストについて、ＰＨＩシステム５１０を照会する。ＰＨＩシステム５１０へのすべての要求は、暗号化されたＰＨＩアクセストークンを含む。１４１６で、ＰＨＩシステム５１０は、暗号化されたアクセストークンを有効性確認のためにＡＳＰシステム５０４に対して送る。ＡＳＰシステム５０４は、アクセストークンが有効である（すなわち、アクセストークンがアクティブセッションに属する）ことを確認する。１４１８で、ＡＳＰシステム５０４は、アクセストークンが有効であることを示す通知を、ＰＨＩシステム５１０に対して送る。

【0233】

適切な認証／認可の後、ＰＨＩシステム５１０は、記憶サービス９０８のＡＰＩを介して、ワークリストおよびスタディＰＨＩデータを取り出す。１４２０で、ＰＨＩシステム５１０は、ワークリストＰＨＩデータをウェブブラウザに対して送る。

【0234】

１４２２で、ワークリストからスタディが選択されると、ウェブブラウザは、スタディをロードするための要求をＡＳＰシステム５０４に対して送る。このような要求に応答して、ＡＳＰシステムは、コンピューティングシステム（たとえば、計算クラスタ）上にスタディをロードし始める。１４２４で、ウェブブラウザは、選択されたスタディに関連付けられたＰＨＩデータについての要求をＰＨＩシステム５１０に対して送る。付与されたアクセスは短時間キャッシュされればよく、したがって、この要求は有効性確認を求めなくてよい。１４２６で、ＰＨＩシステム５１０は、選択されたスタディについてのＰＨＩデータをウェブブラウザに対して送る。１４２８で、スタディが計算クラスタ上にロードされると、ＡＳＰシステム５０４は、ウェブブラウザ５２０に対してスタディデータを送る。

【0235】

１４３０で、ウェブブラウザは、ＡＳＰシステム５０４から受信されたスタディデータを、ＰＨＩシステム５１０から受信されたＰＨＩデータとマージし、同じものを、ＡＳＰによって提供されるサービスの使用のためにユーザに提示する。したがって、プロセス１４００を使うと、ユーザは、ＰＨＩデータへのいかなるアクセスもＡＳＰシステムに提供することなく、ＡＳＰシステム５０４によって提供されるフルスタディデータおよび分析学へのアクセスを有する。

【0236】

図１５Ａないし１５Ｂ（まとめて、図１５）は、アーティファクト再識別サービス１１０８を実装するためのプロセス１５００を示すシステムシーケンス図である。アーティファクト再識別サービス１１０８は、ＡＳＰシステム５０４に接触すること、どの懸案のアーティファクトもダウンロードすること、ダウンロードされたアーティファクトを再識別すること、およびそれらを、ＰＡＣＳ５２５、ウェブベース放射線情報システム（ＷＲＩＳ）などのような医療プロバイダ宛先システムに記憶することを担当する。

【0237】

１５０２で、アーティファクト再識別サービス１１０８は、懸案のアーティファクトのリストを要求する要求をＡＳＰシステム５０４に対して送る。１５０４で、ＡＳＰシステム５０４は、アーティファクト再識別サービス１１０８に、懸案のアーティファクトのリストを提供する。

【0238】

１５０６で、アーティファクト再識別サービス１１０８は、懸案のアーティファクトの受信されたリスト中の懸案のアーティファクトのうちの１つを得るための要求を、ＡＳＰシステム５０４に対して送る。アーティファクトは、２次キャプチャオブジェクト、レポート、またはＡＳＰシステム５０８が医療プロバイダ宛先ストレージ５２５にプッシュしたい場合がある他の何であってもよい。１５０８で、ＡＳＰシステム５０４は、要求されたアーティファクトをアーティファクト再識別サービス１１０８に対して送る。

【0239】

１５１２で、アーティファクトサービス１１０８は、アーティファクトについてのＰＨＩデータを記憶サービス９０８に対して要求する。この要求は、応答中で供給される、不明瞭化されたＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤタグを使って、そのＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤについての元の、関連付けられたタグ情報について、記憶サービス９０８を照会することができる。１５１４で、ＰＨＩシステム５１０の記憶サービス９０８は、アーティファクトサービス１１０８に対してＰＨＩデータを送る。

【0240】

１５１６で、アーティファクトサービス１１０８は、アーティファクトを再識別する。たとえば、ＤＩＣＯＭデータについて、ｄｃｍｏｄｉｆｙユーティリティは、アーティファクト用のＤＩＣＯＭタグを、当初記憶されたものと合致するように再書込みするのに使われてよい。

【0241】

再識別が成功すると、アーティファクトは医療プロバイダ宛先ストレージ５２５にプッシュされる。宛先は、ＰＡＣＳ、ＷＲＩＳ、または他のどのサポートされるエンドポイントであってもよい。接続詳細は、ＡＳＰシステム５０４からアーティファクト詳細とともに提供されてよい。

【0242】

１５２２で、アーティファクトサービス１１０８は、そのアーティファクトのためのアーティファクト再識別プロセスが完了されたことを示す通知を、ＡＳＰシステム５０４に対して送る。１５２４で、ＡＳＰシステム５０４は、そのアーティファクトについての状況が更新されたことをアーティファクトサービス１１０４に通知し、そのようなアーティファクトがもはや、次の反復中に懸案のアーティファクトのリスト中で戻されないことを示す。

【0243】

上述した自動化された手法は、従来の手法において固有である、解剖学的構造およびフローを識別する際の主観性を取り除き、高いレベルまたは再現性を提供する。この再現性は、ＭＲＩデータ向けの新規使用法を可能にする。たとえば、単一の患者についてのＭＲＩデータが、異なるセッションにわたって傾向について確実に検討されることが可能である。さらに驚くべきことに、複数の患者についてのＭＲＩデータが、母集団または人口統計にわたる傾向について確実に検討されることが可能である。

【0244】

上述した様々な実施形態は、さらなる実施形態を提供するように組み合わされてよい。それらが本明細書における特定の教示および定義と矛盾しない程度まで、２０１１年７月７日に出願した特許文献１、２０１２年７月５日に出願した特許文献２、２０１４年１月１７日に出願した特許文献３、２０１５年１月１６日に出願した特許文献４、２０１６年７月１５日に出願した特許文献５、２０１５年１１月２９日に出願した特許文献６、２０１６年１０月３１日に出願した特許文献７、および２０１６年１１月１日に出願した特許文献８を含むが、それに限定されない、本明細書において参照され、かつ／または出願データシートにおいて列挙される米国特許、米国特許出願公報、米国特許出願、外国特許、外国特許出願および非特許公開のすべてが、全体が参照によって本明細書に組み込まれている。実施形態の態様は、必要な場合、さらなる実施形態を提供するために、様々な特許、出願および公開のシステム、回路および概念を利用するように修正されてよい。

【0245】

これらおよび他の変更は、上記詳細な説明を鑑みて、実施形態に対して行われてよい。概して、添付の請求項において、使われる用語は、本明細書および請求項において開示される特定の実施形態に請求項を限定することが企図されるべきではなく、そのような請求項が権利を与えられる十分な範囲の等価物とともに、すべての可能な実施形態を含むことが企図されるべきである。したがって、請求項は、本開示によって限定されない。

【図1】

【図2】

【図3A】

【図3B】

【図4A】

【図4B】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11A】

【図11B】

【図12】

【図13A】

【図13B】

【図14A】

【図14B】

【図15A】

【図15B】