知財求人 - 知財ポータルサイト「IP Force」
特許7475344保護された健康情報を追跡し、それにアクセスし、それをマージするためのシステムおよび方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-04-18
(45)【発行日】2024-04-26
(54)【発明の名称】保護された健康情報を追跡し、それにアクセスし、それをマージするためのシステムおよび方法
(51)【国際特許分類】
G16H 70/00 20180101AFI20240419BHJP
A61B 5/055 20060101ALI20240419BHJP
【ＦＩ】
G16H70/00
A61B5/055 390
【請求項の数】
19
(21)【出願番号】P 2021527976
(86)(22)【出願日】2019-11-15
(65)【公表番号】
(43)【公表日】2022-01-19
(86)【国際出願番号】 US2019061841
(87)【国際公開番号】W WO2020106588
(87)【国際公開日】2020-05-28
【審査請求日】2022-11-08
(31)【優先権主張番号】62/770,636
(32)【優先日】2018-11-21
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】516215925
【氏名又は名称】アーテリーズ インコーポレイテッド
(74)【代理人】
【識別番号】110001243
【氏名又は名称】弁理士法人谷・阿部特許事務所
(72)【発明者】
【氏名】カイル アンドリュー ドーマー
(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】
実行されると、少なくとも１つのコンピュータプロセッサに請求項１から請求項１７に記載のいずれかに従った方法を実行させる、その上に記憶されたプロセッサ実行可能命令を有する非一時的コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、一般に、通信ネットワークまたはチャネルを介して医療画像情報および他の情報を共用することに関する。
【先行技術文献】
【特許文献】
【0002】
【文献】米国特許仮出願第６１／５７１，９０８号明細書
【文献】米国特許第９，５１３，３５７号明細書
【文献】ＰＣＴ特許出願第ＰＣＴ／ＵＳ２０１２／０４５５７５号
【文献】米国特許出願第１５／３６３６８３号明細書
【文献】米国特許仮出願第６１／９２８７０２号明細書
【文献】米国特許出願第１５／１１２１３０号明細書
【文献】ＰＣＴ特許出願第ＰＣＴ／ＵＳ２０１５／０１１８５１号
【文献】米国特許仮出願第６２／２６０５６５号明細書
【文献】米国特許仮出願第６２／４１５２０３号明細書
【文献】ＰＣＴ特許出願第ＵＳ２０１６／０６４０２９号
【文献】ＰＣＴ特許出願第ＵＳ２０１６／０６４０３１号
【文献】米国特許仮出願第６２／４１５６６６号明細書
【文献】ＰＣＴ特許出願第ＵＳ２０１６／０６４０２８号
【文献】米国特許仮出願第６２／４５１４８２号明細書
【文献】米国特許仮出願第６２／５０１６１３号明細書
【文献】米国特許仮出願第６２／５１２６１０号明細書
【文献】米国特許仮出願第６２／５８９８２５号明細書
【文献】米国特許仮出願第６２／５８９８０５号明細書
【文献】米国特許仮出願第６２／５８９７７２号明細書
【文献】米国特許仮出願第６２／５８９８７２号明細書
【文献】米国特許仮出願第６２／５８９８７６号明細書
【文献】米国特許仮出願第６２／５８９８３３号明細書
【文献】米国特許仮出願第６２／５８９８３８号明細書
【文献】米国特許仮出願第６２／５８９，７６６号明細書
【文献】米国特許仮出願第６２／７７０６３６号明細書
【非特許文献】
【0003】
【文献】Ｍａｙｏ Ｃｌｉｎｉｃ Ｇｕｉｄｅ ｔｏ Ｃａｒｄｉａｃ ＭＲ
【文献】ｈｔｔｐ：／／ｄｉｃｏｍ．ｎｅｍａ．ｏｒｇ／ｍｅｄｉｃａｌ／ｄｉｃｏｍ／ｃｕｒｒｅｎｔ／ｏｕｔｐｕｔ／ｈｔｍｌ／ｐａｒｔ０５．ｈｔｍｌ＃ｓｅｃｔ＿Ｂ．２にある、医療におけるデジタルイメージングおよび通信（ＤＩＳＣＯＭ）規格
【発明の概要】
【0004】
医療におけるデジタル画像および通信（ＤＩＣＯＭ）のスタディは、分析のためにリモートシステムに送信される前に、除去または難読化されるべき、保護された健康情報（ＰＨＩ）を含む、医療スキャンを含み得る。ＰＨＩへの以降のアクセスは、医療サービスプロバイダ（例えば、病院）の仮想プライベートネットワークまたはＷｉＦｉネットワークへのリモート接続を含み得る。本明細書において説明されるシステムおよび方法は、リモートユーザが、医療サービスプロバイダの仮想プライベートネットワークまたはＷｉＦｉネットワークへの接続なしに、ＰＨＩにアクセスすることを可能にする。これは、ユーザが、医療サービスプロバイダの仮想プライベートネットワークまたはＷｉＦｉネットワークへの接続を必要とせずに、ＰＨＩにアクセスすることを可能にすることによって、コンピュータネットワークを介した医療画像および分析の技術の効率および柔軟性を向上させる。
【0005】
ＤＩＣＯＭスタディは、スキャニングシステムからの先のアップロード以降に変更された、ＤＩＣＯＭメタデータを含む、より最近のファイルと共に、経時的に分けて送信されることができる。例えば、スタディは、更新された患者の年齢が、または含まれる追加のシリーズと共に、再アップロードされ得る。いくつかの実装形態は、ＤＩＣＯＭ ＵＩＤＳを難読化されたバージョンで置き換えることによって、各着信アップロードを異なるスタディとして扱うが、これは、経時的にＤＩＣＯＭデータを受け入れること、ならびにどのＰＨＩデータが変更されたかを追跡および／または検索することをより困難にし、非効率的にする。本明細書において説明されるシステムおよびプロセスは、経時的にＤＩＣＯＭスタディデータを受け入れ、それが受信された時系列に関係なく、どのＰＨＩデータが変更されたかを追跡および検索するために、ＰＨＩサービスにおける一意識別子を相関させることによって、コンピュータネットワークを介した医療画像および分析の技術のスピード、効率、および柔軟性を向上させる。
【0006】
同じ患者に対して経時的に行われた、または異なるモダリティを使用して行われたスキャンは、注目部位（例えば、肺結節）の変化を監視するなどの課題のために、しばしば互いに比較される。これを行うために、スキャンは、１つまたは複数の共通識別子を介して、リンクされる。患者ＩＤ、受入番号、氏名、および生年月日が、そのような可能な識別子であるが、しばしば組織（例えば、病院）ごとに一意の組み合わせである。データが、すべての識別子を完全なまま残して、記憶されたとき、関連するスタディを識別するプロセスは、単純であり、識別子を照合して、スタディを類似のものと比較し、またはフィルタリングするだけである。クラウドに記憶された識別不能化されたデータは、識別子が、除去または難読化され、２つ以上のスタディを互いに照合することを不可能にするので、容易に関連させることはできない。現在の選択肢は、いくつかの識別情報をスタディ内に維持することを必要とするが、これは、識別不能化を劣化させ、識別情報をデータと共に記憶する。このプロセスは、患者の個人識別可能情報をあまり安全でないものにし、データを合法的に記憶するために、組織とのさらなる取り決めを必要とする。
【0007】
スキャンを実行する、組織内においてホストされるサービスであって、そのサービスが、個人識別可能情報のデータベースを維持する、サービスは、１つまたは複数の識別フィールドを使用して、暗号学的ハッシュを生成し得、それは、その後、識別不能化されたデータをホストするサービス（例えば、クラウドベースのサービス）に送信されることができる。少なくともいくつかの実装形態においては、暗号学的ハッシュは、値をハッシュ化する前に、識別フィールドを一意の（例えば、組織ごとに一意の）暗号鍵と組み合わせることによって、さらに安全にされ得る。一致するハッシュは、リモートサービス内における関連するスタディを示す。
【0008】
各組織は、フィールドの独自の一意セットを使用し得るので、組織内においてホストされるサービスは、必要とされるフィールドを用いて、それらから関連する暗号学的ハッシュを生成するように構成される。フィールドの構成されたセットが、変更されたときは常に、サービスは、各スタディのための暗号学的ハッシュを再生成し、送信し得る。これは、それが、以前は行われていなかった場合、または組織が、それらのシステム内において、何が患者を識別するかについて、それらの方針を変更した場合、すべての過去データおよび新規データを適切にリンクさせ、関連させることを可能にする。
【0009】
性能を向上させるために、暗号学的ハッシュのキャッシュが、組織（例えば、病院）内においてホストされるサービス上に記憶される。構成変更が、検出されたとき、サービスは、すべてのハッシュを再計算することができるが、変更された値だけを再送信し得る。構成に対する変更は、組織の構成が記憶および管理されている、リモートサービス（例えば、クラウドサービス）に定期的に問い合わせることによって行われる。
【0010】
リモートサービスは、分析を実行し、スキャンの識別情報へのアクセスを全く必要とすることなく、関連するスタディへのアクセスを臨床医に提供することができる。
【0011】
医療分析プラットフォームを動作させる方法であって、医療分析プラットフォームが、分析サービスプロバイダ（ＡＳＰ）システムを含む、方法は、以下のように要約され得、すなわち、ＡＳＰシステムの少なくとも１つのプロセッサによって、医療スタディデータを、医療スタディデータの一意識別子と共に受信するステップと、ＡＳＰシステムの少なくとも１つのプロセッサによって、医療スタディデータの一意識別子を、ＡＳＰシステム上に記憶するステップと、ＡＳＰシステムの少なくとも１つのプロセッサによって、受信された医療スタディデータに対するアクセス命令を求める要求を送信するステップであって、要求は、医療スタディデータの一意識別子を含む、ステップと、ＡＳＰシステムの少なくとも１つのプロセッサによって、要求に応答して、アクセス命令を受信するステップと、ＡＳＰシステムの少なくとも１つのプロセッサによって、受信されたアクセス命令を使用して、医療スタディデータを、ＡＳＰシステム上に記憶するステップとを含む。アクセス命令は、医療スタディデータを暗号化するための暗号化情報を含み得、医療スタディデータを記憶するステップは、暗号化情報を使用して、記憶のために医療スタディデータを暗号化するステップを含み得る。アクセス命令は、事前署名された、有効期限があるアクセスユニフォームリソースロケータ（ＵＲＬ）を含み得、医療スタディデータを記憶するステップは、事前署名された、有効期限があるアクセスＵＲＬと関連付けられたアクセス方針に従って、医療スタディデータを、事前署名された、有効期限があるアクセスＵＲＬに記憶するステップを含み得る。
【0012】
方法は、ＡＳＰシステムの少なくとも１つのプロセッサによって、ＡＳＰシステム上に記憶された医療スタディデータを求める要求を、プロセッサベースのクライアントデバイスから受信するステップと、ＡＳＰシステムの少なくとも１つのプロセッサによって、ＡＳＰシステム上に記憶された医療スタディデータを求める要求を受信したことに応答して、ＡＳＰシステム上のストレージから、医療スタディデータの識別子を検索するステップと、ＡＳＰシステムの少なくとも１つのプロセッサによって、ＡＳＰシステム上に記憶された医療スタディデータに対するアクセス命令を求める要求を送信するステップであって、アクセス命令を求める要求が、医療スタディデータの一意識別子を含む、ステップと、ＡＳＰシステムの少なくとも１つのプロセッサによって、アクセス命令を求める要求に応答して、アクセス命令を受信するステップと、ＡＳＰシステムの少なくとも１つのプロセッサによって、受信されたアクセス命令を使用して、ＡＳＰシステム上に記憶された医療スタディデータにアクセスするステップと、ＡＳＰシステムの少なくとも１つのプロセッサによって、プロセッサベースのクライアントデバイスから受信された要求に応答して、ＡＳＰシステム上に記憶されたアクセスされた医療スタディデータを、プロセッサベースのクライアントデバイスに送信するステップとをさらに含み得る。アクセス命令は、医療スタディデータを暗号化解除するための暗号化解除情報を含み得、医療スタディデータにアクセスするステップは、暗号化解除情報を使用して、医療スタディデータを暗号化解除するステップを含み得る。
【0013】
方法は、ＡＳＰシステムの少なくとも１つのプロセッサによって、ＡＳＰシステム上に記憶された医療スタディデータを求める要求を受信したことに応答して、ＡＳＰシステム上に記憶された医療スタディデータと関連付けられたファイル名を、ＡＳＰシステム上のストレージから検索するステップであって、アクセス命令は、事前署名されたダウンロードユニフォームリソースロケータ（ＵＲＬ）を含み、医療スタディデータにアクセスするステップは、ＡＳＰシステムの少なくとも１つのプロセッサによって、事前署名されたダウンロードＵＲＬによって指定されたロケーションにおける医療スタディデータを要求するステップを含む、ステップをさらに含み得る。医療スタディデータは、医療スタディデータアップローダ（ＭＳＤＵ）システムから、医療スタディデータの一意識別子と共に受信され得、受信された医療スタディデータに対するアクセス命令を求める要求は、信頼されたブローカサービス（ＴＢＳ）システムに送信され得、アクセス命令が、要求に応答して、ＴＢＳシステムから受信され得る。
【0014】
方法は、医療スタディデータを、医療スタディデータの一意識別子と共に受信する前に、ＡＳＰシステムの少なくとも１つのプロセッサによって、認証トークンおよび信頼されたブローカサービス（ＴＢＳ）システムのアドレスを求める要求を、ＭＳＤＵシステムから受信するステップであって、要求は、ＭＳＤＵシステム上に記憶された、アプリケーションプログラミングインターフェース（ＡＰＩ）鍵および一意の秘密を含む、ステップと、ＡＳＰシステムの少なくとも１つのプロセッサによって、アプリケーションプログラミングインターフェース（ＡＰＩ）鍵および一意の秘密を使用して、ＭＳＤＵシステムからの要求を認証するステップと、ＡＳＰシステムの少なくとも１つのプロセッサによって、ＭＳＤＵシステムからの要求の認証に基づいて、認証トークンおよびＴＢＳシステムのアドレスを、ＭＳＤＵシステムに送信するステップと、ＡＳＰシステムの少なくとも１つのプロセッサによって、認証トークンの検証を求める要求を、ＴＢＳシステムから受信するステップと、ＡＳＰシステムの少なくとも１つのプロセッサによって、ＴＢＳシステムからの、検証を求める要求に応答して、認証トークンを検証するステップと、ＡＳＰシステムの少なくとも１つのプロセッサによって、認証トークンの検証を、ＴＢＳシステムに送信するステップとをさらに含み得る。ＭＳＤＵシステムは、保護された健康情報（ＰＨＩ）システムの一部であり得る。医療スタディデータは、ＰＨＩシステムによって識別不能化される、識別不能化された医療スタディデータであり得る。
【0015】
医療分析プラットフォームを動作させる方法であって、医療分析プラットフォームが、信頼されたブローカサービス（ＴＢＳ）システムを含む、方法は、以下のように要約され得、すなわち、ＴＢＳシステムの少なくとも１つのプロセッサによって、ＡＳＰシステム上に記憶された医療スタディデータに対するアクセス命令を求める要求を、分析サービスプロバイダ（ＡＳＰ）システムから受信するステップであって、要求は、医療スタディデータの一意識別子を含む、ステップと、ＴＢＳシステムの少なくとも１つのプロセッサによって、一意識別子を使用して、医療スタディデータに対するアクセス命令を検索するステップと、ＴＢＳシステムの少なくとも１つのプロセッサによって、アクセス命令を求める要求に応答して、医療スタディデータに対するアクセス命令を、ＡＳＰシステムに送信するステップとを含む。アクセス命令は、ＡＳＰシステム上における記憶のために、ＡＳＰシステムによって医療スタディデータを暗号化するための暗号化情報を含み得る。アクセス命令は、医療スタディデータが、ＡＳＰシステムによって、そこに記憶されるべき、事前署名された、有効期限があるアクセスユニフォームリソースロケータ（ＵＲＬ）を含み得る。
【0016】
方法は、医療スタディデータに対するアクセス命令を求める要求を、ＡＳＰシステムから受信する前に、ＴＢＳシステムの少なくとも１つのプロセッサによって、医療スタディデータアップローダ（ＭＳＤＵ）システムから、医療スタディデータに関するメタデータを、認証トークンと共に受信するステップと、ＴＢＳシステムの少なくとも１つのプロセッサによって、認証トークンの検証を求める要求を、ＡＳＰシステムに送信するステップと、ＴＢＳシステムの少なくとも１つのプロセッサによって、認証トークンの検証を求める要求に応答して、ＡＳＰシステムから、認証トークンの検証を受信するステップと、また認証トークンの検証に応答して、ＴＢＳシステムの少なくとも１つのプロセッサによって、医療スタディデータの一意識別子を生成するステップと、ＴＢＳシステムの少なくとも１つのプロセッサによって、医療スタディデータについてのアクセス情報を生成するステップと、ＴＢＳシステムの少なくとも１つのプロセッサによって、医療スタディデータの一意識別子を、医療スタディデータについてのアクセス情報、および医療スタディデータに関するメタデータと関連付けるステップと、ＴＢＳシステムの少なくとも１つのプロセッサによって、医療スタディデータに関するメタデータを、ＴＢＳシステム上に記憶するステップと、ＴＢＳシステムの少なくとも１つのプロセッサによって、医療スタディデータの一意識別子の、医療スタディデータについてのアクセス情報、および医療スタディデータに関するメタデータとの関連付けを、ＴＢＳシステム上に記憶するステップと、ＴＢＳシステムの少なくとも１つのプロセッサによって、医療スタディデータの一意識別子を、ＭＳＤＵシステムに送信するステップとをさらに含み得る。ＭＳＤＵシステムは、保護された健康情報（ＰＨＩ）システムの一部であり得る。医療スタディデータは、ＰＨＩシステムによって識別不能化される、識別不能化された医療スタディデータであり得る。
【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】
図面においては、同一の参照番号は、類似の要素または行為を識別する。図面内の要素のサイズおよび相対位置は、必ずしも実寸に比例して描かれていない。例えば、様々な要素の形状、および角度は、必ずしも実寸に比例して描かれておらず、これらの要素のいくつかは、図面の読みやすさを向上させるために、恣意的に拡大され、位置付けられていることがある。さらに、描かれた要素の特定の形状は、特定の要素の実際の形状に関して、いずれかの情報を伝えることを、必ずしも意図したものではなく、図面における認識を容易にするために、選択されているにすぎないことがある。
【図1】例示される一実施形態に従った、少なくとも１つのＭＲＩ獲得システムと、少なくとも１つの画像処理システムとを含む、ネットワーク接続された環境であって、ＭＲＩ獲得システムは、臨床現場に設置され、画像処理システムは、ＭＲＩ獲得システムから離れた場所に設置され、１つまたは複数のネットワークを介して、それと通信可能に結合される、ネットワーク接続された環境の概略図である。
【図2】例示される一実施形態に従った、ＭＲＩ獲得システム、ならびにＭＲＩ画像処理および分析サービスを提供する、ＭＲＩ画像処理および分析システムの機能ブロック図である。
【図3A】例示される一実施形態に従った、少なくとも１つのプロセッサによって実行可能な、例示的なプッシュプロセスのフロー図である。
【図3B】例示される一実施形態に従った、少なくとも１つのプロセッサによって実行可能な、例示的なプッシュプロセスのフロー図である。
【図4A】例示される一実施形態に従った、少なくとも１つのプロセッサによって実行可能な、アーチファクトおよびアーチングを監視する、例示的なプロセスのフロー図である。
【図4B】例示される一実施形態に従った、少なくとも１つのプロセッサによって実行可能な、アーチファクトおよびアーチングを監視する、例示的なプロセスのフロー図である。
【図5】例示される一実施形態に従った、ＰＨＩサービスパイプラインの概略図である。
【図6】例示される一実施形態に従った、ＡＳＰのウェブアプリケーションを介して、分析サービスプロバイダ（ＡＳＰ）システムからのピクセルデータとマージされる、医療プロバイダのネットワーク内に保持されるＰＨＩデータを示す、図５のＰＨＩサービスの概略図である。
【図8】例示される一実施形態に従った、ユーザの組織の登録されたＰＡＣＳサーバ上にレポートを記憶するように、ＡＳＰシステムに要求するために、ウェブアプリケーションを操作するユーザを示す、ＰＨＩサービスの概略図である。
【図9】例示される一実装形態に従った、ＤＩＣＯＭファイルがＰＨＩサービスのＰＨＩサーバによってどのように処理されるかを示す、ＰＨＩサービスの概略図である。
【図10】例示される一実施形態に従った、ＰＨＩサービス依存関係がどのように組織されるかを示す、ＰＨＩサービスの概略図である。
【図11A】例示される一実施形態に従った、ＰＨＩサービスの起動シーケンスのためのプロセスを例示する、システムシーケンス図である。
【図11B】例示される一実施形態に従った、ＰＨＩサービスの起動シーケンスのためのプロセスを例示する、システムシーケンス図である。
【図12】例示される一実施形態に従った、ＰＨＩサービスの識別不能化サービスを実施するためのプロセスを例示する、フロー図である。
【図13A】例示される一実施形態に従った、ＰＨＩサービスのプッシャーまたはアップローダサービスのためのプロセスを例示する、フロー図である。
【図13B】例示される一実施形態に従った、ＰＨＩサービスのプッシャーまたはアップローダサービスのためのプロセスを例示する、フロー図である。
【図14A】例示される一実施形態に従った、ウェブブラウザ識別再可能化のためのプロセスを例示する、システムシーケンス図である。
【図14B】例示される一実施形態に従った、ウェブブラウザ識別再可能化のためのプロセスを例示する、システムシーケンス図である。
【図15A】例示される一実施形態に従った、アーチファクト識別再可能化サービスを実施するためのプロセスを例示する、システムシーケンス図である。
【図15B】例示される一実施形態に従った、アーチファクト識別再可能化サービスを実施するためのプロセスを例示する、システムシーケンス図である。
【図17】例示される一実施形態に従った、暗号化ベースのデータアップロードがＴＢＳシステムによってどのように実行されるかを示す、アップローダ、ＡＳＰシステム、およびＴＢＳシステムの概略図である。
【図18】例示される一実施形態に従った、暗号化ベースのデータダウンロードがＴＢＳシステムによってどのように実行されるかを示す、エンドユーザシステム、ＡＳＰシステム、およびＴＢＳシステムの概略図である。
【図19】例示される一実施形態に従った、アクセスベースのデータアップロードがＴＢＳシステムによってどのように実行されるかを示す、アップローダ、ＡＳＰシステム、およびＴＢＳシステムの概略図である。
【図20】例示される一実施形態に従った、アクセスベースのデータダウンロードがＴＢＳシステムによってどのように実行されるかを示す、エンドユーザシステム、ＡＳＰシステム、およびＴＢＳシステムの概略図である。
【図21】例示される一実施形態に従った、医療分析プラットフォームの分析サービスプロバイダ（ＡＳＰ）システムを動作させるプロセスを例示する、フロー図である。
【図22】例示される一実施形態に従った、医療分析プラットフォームの信頼されたブローカサービス（ＴＢＳ）システムを動作させるプロセスを例示する、フロー図である。
【図23】例示される一実施形態に従った、医療分析プラットフォームの医療スタディデータアップローダ（ＭＳＤＵ）システムを動作させるプロセスを例示する、フロー図である。
【図24】例示される一実施形態に従った、医療スタディデータアップローダ（ＭＳＤＵ）システムと、分析サービスプロバイダ（ＡＳＰ）システムと、信頼されたブローカサービス（ＴＢＳ）システムとを含む、医療分析プラットフォームを動作させるプロセスを例示する、フロー図である。
【図25】例示される一実施形態に従った、完全に識別不能化された医療スタディを追跡するためのシステムの概略ブロック図である。
【図26】例示される一実施形態に従った、ＰＨＩサービスのためのスタートアップ動作を例示する、フロー図である。
【図27】例示される一実施形態に従った、組織環境の変更プロセスを例示する、フロー図である。
【図28】例示される一実施形態に従った、新しいスタディのスキャン時に実施されるプロセスのフロー図である。
【図29】例示される一実施形態に従った、医療分析プラットフォームの分析サービスプロバイダ（ＡＳＰ）システムおよび保護された健康情報（ＰＨＩ）システムをＰＨＩにアクセスするように、動作させるプロセスを例示する、フロー図である。
【図30】例示される一実施形態に従った、ＰＨＩにアクセスするように、医療分析プラットフォームのＡＳＰシステムを動作させるプロセスを例示する、フロー図である。
【図31】例示される一実施形態に従った、組織と関連付けられたプロセッサベースのシステムをＰＨＩを記憶するように動作させるプロセスを例示する、フロー図である。
【図32】例示される一実施形態に従った、組織と関連付けられたプロセッサベースのシステムをマージされたＰＨＩを提供するように動作させるプロセスを例示する、フロー図である。
【発明を実施するための形態】
【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】
脂肪タイプ組織について、非ゼロ速度が、見つけられた場合、これが、（例えば、すべての組織についての）データのセット全体を調整するために、使用されることができる。例えば、ＭＲＩ画像処理および分析システムは、識別されたエリアまたはボリューム（例えば、脂肪または軟組織）に基づいて、多項式モデルを生成または作成し得る。そうしたものは、単純な多項式（例えば、ａｘ2＋ｂｘ＋ｃ）、またははるかに複雑な多項式（例えば、非有理一様ｂスプライン）であり得る。ＭＲＩ画像処理および分析システムは、例えば、線形回帰法や線形代数法を使用して、多項式が画像に適合するような係数を見つけ得る。これは、ＭＲＩ画像処理および分析システムが、脂肪または軟組織だけでなく、フィールド全体に適用し得る（例えば、それから引き得る）、モデルをもたらす。
【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】
ユーザが画像上の位置を選択することを可能にすることは、多くの重要なアプリケーションを有する。測定を実行する際、ユーザは、１つの点から別の点までの距離を測定することを望むことがある。データのボリュームからのＭＰＲを使用するアプリケーションでは、画像上の点は、３Ｄ空間内のロケーションを表す。これらの３Ｄ点は、画像と関連付けられたメタデータから算出するのは容易である。ボリュームレンダリングを使用するアプリケーションでは、ユーザが３Ｄ空間内の点を選択することを可能にすることは、各ピクセルが異なる深度にあることがあるので、より困難である。
【0162】
アルファが１．０に到達すると終わる増加するアルファ合成関数を用いた一般的な前面から後面へのボリュームレイキャスティングでは、ピクセルの深度を決定することは、どこでレイが終わるかを追跡することによって行われ得る。後面から前面にレイキャスティングするとき、早期のレイ終結はない。結果の色は、単に合成関数に基づいて更新される。一般に、合成関数は空気を透明にし、したがって、色は、レイが目に最も近い物質を出ると変化をやめる。いつ色が変化をやめたかを追跡することによって、各ピクセルに対するこの深度は、２Ｄユーザにより選択された座標を空間内の３Ｄロケーションに変換するために使用可能である。この３Ｄロケーション選択は、血液血管を選択し、次いでフローを自動的に定量化するために使用可能である。
【0163】
[自動吻合検出]
吻合のための正確なロケーションを見出すことを試みる代わりに、第１の動作は、吻合が存在するかどうかを識別することである。吻合が存在するかどうかを識別する１つの単純な方法は、左心臓フロー（Ｑｓ）および右心臓フロー（Ｑｐ）を測定することである。ＱｐおよびＱｓは、ランドマークおよび血液プールセグメンテーションが完了した場合、手動（例えば、輪郭を配置することによって）または自動的のどちらかで測定可能である。これらの数がある閾値内で合致しない場合、スキャンは、吻合を潜在的に有するとフラグが立てられ得る。
吻合のための正確なロケーションを見出すことを試みる代わりに、第１の動作は、吻合が存在するかどうかを識別することである。吻合が存在するかどうかを識別する１つの単純な方法は、左心臓フロー（Ｑｓ）および右心臓フロー（Ｑｐ）を測定することである。ＱｐおよびＱｓは、ランドマークおよび血液プールセグメンテーションが完了した場合、手動（例えば、輪郭を配置することによって）または自動的のどちらかで測定可能である。これらの数がある閾値内で合致しない場合、スキャンは、吻合を潜在的に有するとフラグが立てられ得る。
【0164】
これらの測定は、以下の技法を使用して自動的に行われてよい。
ｉ）心拍出量（Ｑｓ）の自動測定は、大動脈弁および肺動脈弁のロケーションの自動推定と共に大動脈フローと肺動脈フローの両方に対するマスクの製作であると、他の所で説明される。
ｉｉ）弁領域が識別されると、それらとすでに決定された肺動脈フロー領域を選び、弁からわずかに下流に動かし、心拍出量に関して説明されたものに類似した手段でフロー測定輪郭を製作することは、簡単なタスクである。肺動脈フローを測定するために適した輪郭が識別されると、既存のフロー測定アルゴリズムが、右心室から拍出量を決定するために使用可能である。
ｉｉｉ）自動フロー測定を使用して、吻合が存在する可能性を示す。
［ピーク収縮期およびピーク拡張期および収縮末期および拡張末期の自動検出］
ｉ）心拍出量（Ｑｓ）の自動測定は、大動脈弁および肺動脈弁のロケーションの自動推定と共に大動脈フローと肺動脈フローの両方に対するマスクの製作であると、他の所で説明される。
ｉｉ）弁領域が識別されると、それらとすでに決定された肺動脈フロー領域を選び、弁からわずかに下流に動かし、心拍出量に関して説明されたものに類似した手段でフロー測定輪郭を製作することは、簡単なタスクである。肺動脈フローを測定するために適した輪郭が識別されると、既存のフロー測定アルゴリズムが、右心室から拍出量を決定するために使用可能である。
ｉｉｉ）自動フロー測定を使用して、吻合が存在する可能性を示す。
［ピーク収縮期およびピーク拡張期および収縮末期および拡張末期の自動検出］
【0165】
多くの自動処理は、心臓周期内の主要な時間的ランドマークすなわちピーク収縮期およびピーク拡張期および収縮末期および拡張末期に対応する時点を最初に識別できることに依存する。
【0166】
他の所で説明されるように、心臓の周囲の主要な動脈および静脈と共に心臓内の血流の領域を識別するために、速度画像に対してフーリエ分析技法を使用することが可能である。これらの血流の主要な領域が識別されると、各時点（一般に２０の時点）における、識別されたボクセル上での全血流を見出す。次いで、システムは、結果として生じる時間の関数を分析して、心臓周期内のランドマークを決定することが可能である。最も多いフローをもつ時点が、最初にピーク収縮期ランドマークに割り当てられる。そこから、関数は、フローが平らになる傾向がある点を決定するために、時間的に両方向に分析される。全フローが平らになる、ピーク収縮期の前の点（それが急速に上昇し始める直前の点）は、拡張末期に対応する。ピーク収縮期の後、全フローは、それが平らになるまで急速に低下し、これは、収縮末期に対応する。ピーク拡張期は、一般に、明瞭に定義された点ではなく、そのため、本発明者らは、この時間的なランドマークを、収縮末期と拡張末期との間の中間の点に配置する。
【0167】
[自動心拍出量および体積測定の測定]
心拍出量の自動測定は、以下の方法を使用して行われる。
ｉ）すでに決定されたピーク収縮期ランドマーク（他の所で説明される）と共に、速度画像の主要なＤＦＴ成分間の関係は、左心室および右心室からの動脈フローの主要な領域を識別するために使用される。
ｉｉ）様々なフロー連続性フィルタが、動脈フロー領域を２つのピースすなわち大動脈フローおよび肺動脈フローへと分離するために次々と使用される。最大速度をもつ初期動脈フローマスク内の点は、大動脈または肺動脈のどちらかの中にあることが知られている信頼性の高い点を提供する。フローの２つの領域の分離は、例えば、最大フローの点で開始するフラッド可能である、結果として生じるフィルタ内の領域のサイズの調査によって、決定可能である。第１のピースが識別されると、第２のピースが、例えば、残りの領域内の最大フロー点からのフラッディングによって、識別可能である。
ｉｉｉ）２つの領域すなわち大動脈フローに対応するものと肺動脈フローに対応するものが識別されると、この２つの領域は、成長して限られた量回復することが可能にされ得（個々のピクセルは、１つのマスクまたは他方のマスクに割り当てられるのみである）、元の動脈フローマスクは、成長の量に絶対限界を提供する。少なくとも少しのマスクの拡張を可能にすることも、先行するプロセス動作が、方法における次のステップを隠す傾向がある、結果として生じる領域に小さな穴を開けた可能性があるので、非常に重要なことがある。
ｉｖ）２つのフロー領域は、互いに対するそれらの空間的な関係と、それらの非常に異なる予想形状および空間内の方位に基づいて、大動脈フローおよび肺動脈フローとして識別可能である。これが行われると、元の動脈フローマスクが２つの領域へと本質的に分割され、一方は大動脈フローとラベルが付けられ、他方は肺動脈フローとラベルが付けられる。
ｖ）大動脈は本質的に１つの連続したパイプであるので、大動脈の経路は、２つの端が到達されるまで、動脈内の開始点からトレース可能である。各点において、主要なピーク収縮期フロー方向は、その点の周囲の小さい領域にわたって平均化することによって決定可能である。次いで、フロー方向に対する直交が、マスクされた大動脈領域をもつ境界を決定するために開始点から規則正しい角度間隔で投影され、したがって、開始点の周囲のほぼ円形の輪郭を決定することができる。
ｖｉ）輪郭が、何らかの開始点に対して主要なフロー方向に直交する面上の多角形と決定されると、開始点は、多角形内で再度中心に置かれる。この点で、小さいステップ（例えば、１ミリメートル）は、開始点からどちらの方角にトレースしているかに応じて、正または負のフロー方向で中心点から取られ得、次いで、プロセスが繰り返される。これは、各端においてマスクから出るまで継続される。
ｖｉｉ）輪郭が大動脈に沿って規則正しい間隔で製作されると、メッシュを本質的に製作して、それらは、解剖学的画像（血流増強データセットを扱う場合に可能である）、または収縮期時点に対する速度およびその間の補間を通して使用することによって、のどちらかを使用して、各個々の時点で改良される。１つの可能な手法は、スネークアルゴリズムを使用して、各時点において各輪郭に対する所望の境界を正確に識別することである。
ｖｉｉｉ）改良された輪郭が決定されると、各輪郭の外径および内径が測定され、外径は最大直径であり、内径は、外径に直交する最大直径である。
ｖｉｉｉ）次のタスクは、大動脈弁と大動脈の頂部に発生する分岐部との間の上行大動脈の主要な領域内の良好な輪郭を識別することであるが、これは、心拍出量を測定するときに使用される必要がある領域であるからである。これは、いくつかの行為で行われ得る。最初に、上行大動脈領域は、フロー方向によって下行領域から容易に分離される。次いで、残りの輪郭は、輪郭エリアの連続性および可変性と大動脈内の１つの点における空間的（大動脈に沿って）と時間的の両方で直径（外径および内径）の組み合わせを使用してスコア付与可能である。スコアは、個々の、高いスコアが付与された、輪郭を単に識別するのとは反対に、良好なスコア付与の領域を探すために、大動脈に沿って平均化可能である。この方法を使用して、大動脈の頂部における分岐部の近辺における領域と、大動脈弁の近くおよび左心室内へと存在し得る領域も消去することができるが、これらの領域は、それらの性質からして、悪くスコア付与されるであろう。
ｉｘ）上行大動脈の良好な領域が識別されると、最高スコア付与の個々の輪郭は、実際の心拍出量測定のために選択可能である。可能ならば、測定は、上行大動脈に沿って複数の点において行われ、これは、可変性を調べることによって測定の品質の自動決定を提供する（それによって、測定不確実性の推定も提供する）ことと共に、平均化することを通して、結果を改善する。加えて、上行大動脈に沿ってフローの複数の測定の結果を調べることは、現在適用されている速度渦電流補正の品質に関する判断を可能にする。
ｘ）理想的な輪郭が上行大動脈に沿って選択されると、心拍出量が、通常のフロー測定技法によって決定される。
心拍出量の自動測定は、以下の方法を使用して行われる。
ｉ）すでに決定されたピーク収縮期ランドマーク（他の所で説明される）と共に、速度画像の主要なＤＦＴ成分間の関係は、左心室および右心室からの動脈フローの主要な領域を識別するために使用される。
ｉｉ）様々なフロー連続性フィルタが、動脈フロー領域を２つのピースすなわち大動脈フローおよび肺動脈フローへと分離するために次々と使用される。最大速度をもつ初期動脈フローマスク内の点は、大動脈または肺動脈のどちらかの中にあることが知られている信頼性の高い点を提供する。フローの２つの領域の分離は、例えば、最大フローの点で開始するフラッド可能である、結果として生じるフィルタ内の領域のサイズの調査によって、決定可能である。第１のピースが識別されると、第２のピースが、例えば、残りの領域内の最大フロー点からのフラッディングによって、識別可能である。
ｉｉｉ）２つの領域すなわち大動脈フローに対応するものと肺動脈フローに対応するものが識別されると、この２つの領域は、成長して限られた量回復することが可能にされ得（個々のピクセルは、１つのマスクまたは他方のマスクに割り当てられるのみである）、元の動脈フローマスクは、成長の量に絶対限界を提供する。少なくとも少しのマスクの拡張を可能にすることも、先行するプロセス動作が、方法における次のステップを隠す傾向がある、結果として生じる領域に小さな穴を開けた可能性があるので、非常に重要なことがある。
ｉｖ）２つのフロー領域は、互いに対するそれらの空間的な関係と、それらの非常に異なる予想形状および空間内の方位に基づいて、大動脈フローおよび肺動脈フローとして識別可能である。これが行われると、元の動脈フローマスクが２つの領域へと本質的に分割され、一方は大動脈フローとラベルが付けられ、他方は肺動脈フローとラベルが付けられる。
ｖ）大動脈は本質的に１つの連続したパイプであるので、大動脈の経路は、２つの端が到達されるまで、動脈内の開始点からトレース可能である。各点において、主要なピーク収縮期フロー方向は、その点の周囲の小さい領域にわたって平均化することによって決定可能である。次いで、フロー方向に対する直交が、マスクされた大動脈領域をもつ境界を決定するために開始点から規則正しい角度間隔で投影され、したがって、開始点の周囲のほぼ円形の輪郭を決定することができる。
ｖｉ）輪郭が、何らかの開始点に対して主要なフロー方向に直交する面上の多角形と決定されると、開始点は、多角形内で再度中心に置かれる。この点で、小さいステップ（例えば、１ミリメートル）は、開始点からどちらの方角にトレースしているかに応じて、正または負のフロー方向で中心点から取られ得、次いで、プロセスが繰り返される。これは、各端においてマスクから出るまで継続される。
ｖｉｉ）輪郭が大動脈に沿って規則正しい間隔で製作されると、メッシュを本質的に製作して、それらは、解剖学的画像（血流増強データセットを扱う場合に可能である）、または収縮期時点に対する速度およびその間の補間を通して使用することによって、のどちらかを使用して、各個々の時点で改良される。１つの可能な手法は、スネークアルゴリズムを使用して、各時点において各輪郭に対する所望の境界を正確に識別することである。
ｖｉｉｉ）改良された輪郭が決定されると、各輪郭の外径および内径が測定され、外径は最大直径であり、内径は、外径に直交する最大直径である。
ｖｉｉｉ）次のタスクは、大動脈弁と大動脈の頂部に発生する分岐部との間の上行大動脈の主要な領域内の良好な輪郭を識別することであるが、これは、心拍出量を測定するときに使用される必要がある領域であるからである。これは、いくつかの行為で行われ得る。最初に、上行大動脈領域は、フロー方向によって下行領域から容易に分離される。次いで、残りの輪郭は、輪郭エリアの連続性および可変性と大動脈内の１つの点における空間的（大動脈に沿って）と時間的の両方で直径（外径および内径）の組み合わせを使用してスコア付与可能である。スコアは、個々の、高いスコアが付与された、輪郭を単に識別するのとは反対に、良好なスコア付与の領域を探すために、大動脈に沿って平均化可能である。この方法を使用して、大動脈の頂部における分岐部の近辺における領域と、大動脈弁の近くおよび左心室内へと存在し得る領域も消去することができるが、これらの領域は、それらの性質からして、悪くスコア付与されるであろう。
ｉｘ）上行大動脈の良好な領域が識別されると、最高スコア付与の個々の輪郭は、実際の心拍出量測定のために選択可能である。可能ならば、測定は、上行大動脈に沿って複数の点において行われ、これは、可変性を調べることによって測定の品質の自動決定を提供する（それによって、測定不確実性の推定も提供する）ことと共に、平均化することを通して、結果を改善する。加えて、上行大動脈に沿ってフローの複数の測定の結果を調べることは、現在適用されている速度渦電流補正の品質に関する判断を可能にする。
ｘ）理想的な輪郭が上行大動脈に沿って選択されると、心拍出量が、通常のフロー測定技法によって決定される。
【0168】
[４Ｄ体積測定の測定]
特定の領域のボリュームを計算するために、本発明者らは、分析サービスプロバイダ（ＡＳＰ）システムインターフェース内の３つのオプションを開発した。
特定の領域のボリュームを計算するために、本発明者らは、分析サービスプロバイダ（ＡＳＰ）システムインターフェース内の３つのオプションを開発した。
【0169】
オプション１：固定軸
３Ｄ空間内の２つの点は、対象となるボリュームの主軸を定義する。直線は、これらの２つの点を接続する（すなわち、固定軸）。次いで、この軸は、スライスが配置されるロケーションを定義する離散的な点（例えば２～４０）へと分割される。スライスは、それらが交差しないように軸と直交して位置合わせされる。スライスは、均等に離隔される必要はない。ＭＰＲは、ユーザが、そのスライスロケーションにおいて医療画像がどのように見えるかをわかることを可能にするために、すべてのスライスロケーションにおいてレンダリングされる。次いで、手動または自動的のどちらかで、閉じた輪郭は、そのスライスロケーションにおいてボリュームの境界を定義するために、あらゆるスライス上に作成される。あらゆるスライスロケーションに複数の閉じた輪郭がある可能性がある。１つまたは複数のスライス上に輪郭が全くない可能性もある。４Ｄまたはより高次元のスタディ（すなわち、ボリューム変化を示すスタディ、または前記異なる、スライスごとに複数のフレーム）の場合、フレームごとに別個の輪郭であり得る。すべての輪郭が、すべてのフレームおよびスライスに対して配置されると、特定のフレームに対するすべてのスライスの輪郭を接続する３Ｄサーフェスが作成される。閉じた輪郭のセットから３Ｄサーフェスが作成される手段は、上記の「閉じた輪郭からの４Ｄメッシュ作成」において説明されている。４Ｄまたはより高次元のボリュームがある場合、ボリュームの変化は、各フレームのボリュームを算出し、それを別のフレームと引くことによって計算可能である。これは、心室機能を定量化することを試み、次いで心室機能が一回拍出量および駆出分画を与えるときに、特に重要である。
３Ｄ空間内の２つの点は、対象となるボリュームの主軸を定義する。直線は、これらの２つの点を接続する（すなわち、固定軸）。次いで、この軸は、スライスが配置されるロケーションを定義する離散的な点（例えば２～４０）へと分割される。スライスは、それらが交差しないように軸と直交して位置合わせされる。スライスは、均等に離隔される必要はない。ＭＰＲは、ユーザが、そのスライスロケーションにおいて医療画像がどのように見えるかをわかることを可能にするために、すべてのスライスロケーションにおいてレンダリングされる。次いで、手動または自動的のどちらかで、閉じた輪郭は、そのスライスロケーションにおいてボリュームの境界を定義するために、あらゆるスライス上に作成される。あらゆるスライスロケーションに複数の閉じた輪郭がある可能性がある。１つまたは複数のスライス上に輪郭が全くない可能性もある。４Ｄまたはより高次元のスタディ（すなわち、ボリューム変化を示すスタディ、または前記異なる、スライスごとに複数のフレーム）の場合、フレームごとに別個の輪郭であり得る。すべての輪郭が、すべてのフレームおよびスライスに対して配置されると、特定のフレームに対するすべてのスライスの輪郭を接続する３Ｄサーフェスが作成される。閉じた輪郭のセットから３Ｄサーフェスが作成される手段は、上記の「閉じた輪郭からの４Ｄメッシュ作成」において説明されている。４Ｄまたはより高次元のボリュームがある場合、ボリュームの変化は、各フレームのボリュームを算出し、それを別のフレームと引くことによって計算可能である。これは、心室機能を定量化することを試み、次いで心室機能が一回拍出量および駆出分画を与えるときに、特に重要である。
【0170】
オプション２：まっすぐな軸を動かす
この方法は、４Ｄボリュームの場合、軸の２つの端点を定義するランドマークまたは点が各フレーム（例えば、時点）上で動くことができることを除いて、オプション１に類似している。これは、ボリュームに、ボリュームを変更することなく３Ｄ空間内のロケーションを潜在的に動かす。
この方法は、４Ｄボリュームの場合、軸の２つの端点を定義するランドマークまたは点が各フレーム（例えば、時点）上で動くことができることを除いて、オプション１に類似している。これは、ボリュームに、ボリュームを変更することなく３Ｄ空間内のロケーションを潜在的に動かす。
【0171】
オプション３：固定された湾曲した軸。
この方法は、２つの端点を接続する線はまっすぐである必要はないことを除いて、オプション１に類似している。この線は、湾曲されてもよいし、複数のまっすぐなセクションおよび湾曲したセクションを有してもよい。これは、２つの端点間の点／ロケーションを接続するスプラインをもつシステム内で扱われる。これらの点／ロケーションは、どこであってもよく、必ずしも２つの端点間にあるとは限らない。
この方法は、２つの端点を接続する線はまっすぐである必要はないことを除いて、オプション１に類似している。この線は、湾曲されてもよいし、複数のまっすぐなセクションおよび湾曲したセクションを有してもよい。これは、２つの端点間の点／ロケーションを接続するスプラインをもつシステム内で扱われる。これらの点／ロケーションは、どこであってもよく、必ずしも２つの端点間にあるとは限らない。
【0172】
オプション４：湾曲した軸を動かす
この方法は、４Ｄボリュームの場合、湾曲した軸の２つの端点を定義するランドマークまたは点が各フレーム（例えば、時点）上で動くことができることを除いて、オプション２に類似している。これは、ボリュームに、ボリュームを変更することなく３Ｄ空間内のロケーションを潜在的に動かす。
この方法は、４Ｄボリュームの場合、湾曲した軸の２つの端点を定義するランドマークまたは点が各フレーム（例えば、時点）上で動くことができることを除いて、オプション２に類似している。これは、ボリュームに、ボリュームを変更することなく３Ｄ空間内のロケーションを潜在的に動かす。
【0173】
上記のオプションのすべてにおいて、複数の軸がある可能性がある。例えば、１から２に分割する「Ｙ」字形軸である可能性がある。分割し１つになってボリュームを作成する、まっすぐな軸と湾曲した軸の両方を有するオプションもある。これのポイントは、主軸（すなわち、中心線）を依然として有するより複雑な形状を説明することである。
【0174】
上記のオプションのすべてでは、３ＤボリュームがどのようにＭＰＲと交差するかを表示するオプションもある。交点は、１つまたは複数の閉じた輪郭の集まりでなければならない。これらの閉じた輪郭は、ＭＰＲ上でレンダリング可能である。加えて、これらの閉じた輪郭は、新しい（非直交）像において輪郭を動かすことによって編集可能である。交点輪郭は、クライアント上ならびにサーバ上の両方で算出されてもよいし、ローカルリソースに応じて適応性であってもよい。心臓イメージングの場合、共通する非直交像は、二腔像、三腔像、および四腔像である。輪郭は、編集がある方向にある（すなわち、スライス面に沿って）ことのみを可能にすることによって、これらの像において編集可能である。
【0175】
[面外測定および追跡モード]
体積測定ＭＲＩデータからの心臓系内の測定は、いくつかの複雑性を有する。例えば、弁面の形状、位置、方位、および速度は、心臓周期にわたって著しく変更することができる。本発明者らは、これを、３Ｄ空間を通る２Ｄ輪郭を使用することによって解決する。次いで、手動または自動的のどちらかで、輪郭は、フロー方向と最も直角をなす面上の弁開口の辺縁に配置される。弁面の位置および方位は、心臓周期の各位相に対して追跡される。フローの評価は、標準的な有限方法統合を通して実行されるが、弁面が動いている場合、弁面の線形速度および角速度は、その位相に対するフロー算出に含まれ得る。可視化中、位相を繰り返すとき、ＭＰＲの位置および方位は、弁面と共に追跡することができる。現在のＭＰＲが面外にあるときに測定が可視化される場合、輪郭は、半透明でレンダリングされる。
体積測定ＭＲＩデータからの心臓系内の測定は、いくつかの複雑性を有する。例えば、弁面の形状、位置、方位、および速度は、心臓周期にわたって著しく変更することができる。本発明者らは、これを、３Ｄ空間を通る２Ｄ輪郭を使用することによって解決する。次いで、手動または自動的のどちらかで、輪郭は、フロー方向と最も直角をなす面上の弁開口の辺縁に配置される。弁面の位置および方位は、心臓周期の各位相に対して追跡される。フローの評価は、標準的な有限方法統合を通して実行されるが、弁面が動いている場合、弁面の線形速度および角速度は、その位相に対するフロー算出に含まれ得る。可視化中、位相を繰り返すとき、ＭＰＲの位置および方位は、弁面と共に追跡することができる。現在のＭＰＲが面外にあるときに測定が可視化される場合、輪郭は、半透明でレンダリングされる。
【0176】
[セグメンテーション]
[連続の方程式により駆動される、血液プールのセグメンテーション]
もう一度、非圧縮性仮定をもつ質量保存（すなわち、連続性）は、発散は血液プール内のあらゆる所でゼロでなければならないことを示すために使用可能である。あらゆる所で発散を算出することによって、システムは、閾値発散値によって血液プールの範囲を定義することができる。血液プールの外部の発散はより大きい（すなわち、肺内に空気）、または速度は低い（すなわち、静的な組織内の速度信号）、これらは両方とも、内腔境界を識別する際の助けとなる。発散マップは、セグメンテーションアルゴリズムの唯一の入力である必要はなく、代わりに、それが、他の入力に追加されてもよく、適切に重み付けされてもよい。
[連続の方程式により駆動される、血液プールのセグメンテーション]
もう一度、非圧縮性仮定をもつ質量保存（すなわち、連続性）は、発散は血液プール内のあらゆる所でゼロでなければならないことを示すために使用可能である。あらゆる所で発散を算出することによって、システムは、閾値発散値によって血液プールの範囲を定義することができる。血液プールの外部の発散はより大きい（すなわち、肺内に空気）、または速度は低い（すなわち、静的な組織内の速度信号）、これらは両方とも、内腔境界を識別する際の助けとなる。発散マップは、セグメンテーションアルゴリズムの唯一の入力である必要はなく、代わりに、それが、他の入力に追加されてもよく、適切に重み付けされてもよい。
【0177】
[自動ランドマーク検出]
自動ランドマーク検出アルゴリズムを作成する一般的な手段は、ある形状を画像内で探し、これらの形状間の距離および角度を測定することである。測定値がある帯域内にある場合、それらは分類される。いくつかの他の生理学的入力が、アルゴリズムに追加可能である。例えば、あらゆる心拍と共に実質的に増加および減少させる流体のボリュームを設置すること（これは、心室である可能性がある）。心室が見出されると、弁の入口および出口は、ストリームラインを辿ることによって見出され得る。弁が見出されると、残りの弁を見出すことはより容易であるが、それは、それらが、一般に常に互いからある距離および角度が離れているからである。
自動ランドマーク検出アルゴリズムを作成する一般的な手段は、ある形状を画像内で探し、これらの形状間の距離および角度を測定することである。測定値がある帯域内にある場合、それらは分類される。いくつかの他の生理学的入力が、アルゴリズムに追加可能である。例えば、あらゆる心拍と共に実質的に増加および減少させる流体のボリュームを設置すること（これは、心室である可能性がある）。心室が見出されると、弁の入口および出口は、ストリームラインを辿ることによって見出され得る。弁が見出されると、残りの弁を見出すことはより容易であるが、それは、それらが、一般に常に互いからある距離および角度が離れているからである。
【0178】
ランドマークを見出すために選択されるアルゴリズムは、機械学習タイプであってよい。ＡＳＰ（例えば、Ａｒｔｅｒｙｓ）は、正しいランドマークを用いて有効性が確認されたデータを常時収集しているので、このデータを臨床医によって配置することは、トレーニングセット（例えば、データの統計的集約）として使用される必要がある。分析される必要があるあらゆるデータセットは、トレーニングセットデータを用いて構築される「アトラス」と共に共同登録可能である。十分な数のデータセットが収集されると、疾患のタイプ（すなわち、健常、ファロー四徴症など）などの追加の入力パラメータが、分析される前にデータセットをビンに入れるために使用可能である。あらゆるビンは、疾患のタイプおよびどのような病状が予想されるかに応じて、わずかに異なるランドマークおよび測定を有することがある。データセットが、単心室を有する患者であることが知られている場合、自動ランドマーク検出アルゴリズムは、それが４つの弁を見出すことは決してないので、これに合うよう調節する必要がある。
【0179】
特に、大動脈弁ランドマークおよび肺動脈弁ランドマークは、以下のプロセスを使用して決定可能である。
ｉ）左心室および右心室からの動脈フローに対応する領域を識別する。高い信頼性をもってこれを行うことが可能であるフィルタが開発されている（他の所で説明される）。
ｉｉ）動脈フローの領域を、２つの領域、すなわち大動脈に対応するものと肺動脈に対応するものへと分離する。このプロセスは、「心拍出量」の下で詳細に説明される。
ｉｉｉ）左心室からのフローまたは右心室からのフローのどちらかに対応する１つの領域が決定されると、他方の領域が、両方のフローに対応する開始領域から引くことによって決定される。次いで、領域は、それらの物理的寸法および空間内での方位に基づいて、左心室フローまたは右心室フローとして容易に識別可能である（同じく、「心拍出量」の下で説明される）。
ｉｖ）フローの２つの領域が識別されると、大動脈弁および肺動脈弁のロケーションに対する初期近似は、その見かけ上の起点へのバルクフローを注意深くトレースすることによって決定されることが可能である。
ｖ）信頼できる初期推定値が、２つの弁のロケーションに関して生じさせられると、他の技法が、弁ロケーションを改良するために使用可能である。例えば、弁のロケーションを改良するために、初期推定を取り囲む領域内の血流加速度および強度を調べてもよい。
ｉ）左心室および右心室からの動脈フローに対応する領域を識別する。高い信頼性をもってこれを行うことが可能であるフィルタが開発されている（他の所で説明される）。
ｉｉ）動脈フローの領域を、２つの領域、すなわち大動脈に対応するものと肺動脈に対応するものへと分離する。このプロセスは、「心拍出量」の下で詳細に説明される。
ｉｉｉ）左心室からのフローまたは右心室からのフローのどちらかに対応する１つの領域が決定されると、他方の領域が、両方のフローに対応する開始領域から引くことによって決定される。次いで、領域は、それらの物理的寸法および空間内での方位に基づいて、左心室フローまたは右心室フローとして容易に識別可能である（同じく、「心拍出量」の下で説明される）。
ｉｖ）フローの２つの領域が識別されると、大動脈弁および肺動脈弁のロケーションに対する初期近似は、その見かけ上の起点へのバルクフローを注意深くトレースすることによって決定されることが可能である。
ｖ）信頼できる初期推定値が、２つの弁のロケーションに関して生じさせられると、他の技法が、弁ロケーションを改良するために使用可能である。例えば、弁のロケーションを改良するために、初期推定を取り囲む領域内の血流加速度および強度を調べてもよい。
【0180】
[対話式４Ｄボリュームセグメンテーション]
心臓スキャンからの心室のセグメンテーションは、心室機能を決定するのに肝要である。自動心室機能技法は、以下を伴うことがある。
－ スプラインの制御点を表す２つ以上の点の入力、
－ スプラインの端点は、心室の心尖および出口弁（肺動脈または大動脈）を表す、
－ これらの点を使用することは、スプライン曲線に沿って定期的な間隔で曲線の接線に設定された面法線をもつＭＰＲを生成する、
－ 各ＭＰＲ上で、心室の境界（心外膜または心内膜）を見出すためにアクティブ輪郭モデルを適用する、および
－ これらの輪郭の各々の点を使用して３Ｄメッシュを生成する。
心臓スキャンからの心室のセグメンテーションは、心室機能を決定するのに肝要である。自動心室機能技法は、以下を伴うことがある。
－ スプラインの制御点を表す２つ以上の点の入力、
－ スプラインの端点は、心室の心尖および出口弁（肺動脈または大動脈）を表す、
－ これらの点を使用することは、スプライン曲線に沿って定期的な間隔で曲線の接線に設定された面法線をもつＭＰＲを生成する、
－ 各ＭＰＲ上で、心室の境界（心外膜または心内膜）を見出すためにアクティブ輪郭モデルを適用する、および
－ これらの輪郭の各々の点を使用して３Ｄメッシュを生成する。
【0181】
アクティブ輪郭モデルは、それらに対して作用する力からの不安定性にさらされる。この不安定性を低下させるために、輪郭を、それらが所望の出力間隔（輪郭間の距離）で離隔されるように単に生成する代わりに、システムは、一緒に非常に密に離隔された多くの輪郭を生成する。同じく、入力データが時間的データを有する場合、同じロケーションにある輪郭は、隣接する時点からのデータを使用して生成される。次いで、輪郭形状および品質が、心室からの典型的な輪郭に対して測定される。輪郭が十分な品質であると思われる場合、それは、最終結果を生成する際に含まれる。最終結果は、入力曲線に沿って位置および時間に近い、含まれる輪郭を平均化することによって生成される。収縮末期と拡張末期の両方で構築されるメッシュを用いると、ボリュームの差は、心拍出量および心室機能を表す。
【0182】
例示的な一実装形態では、ＡＳＰシステムおよびソフトウェアは、シングルクリック４Ｄボリュームセグメンテーションを提供する。これは、ユーザが、３Ｄボリュームを自由にナビゲート（すなわち、回転、パン、ズーム、スライススクロール、時間スクロール）しながら、対象となるエリア（例えば、血液プール、心筋、骨など）をクリックすることを可能にする。フル３Ｄボリュームセグメンテーションアルゴリズムは、構築し、正確であるのは難しいので、第２のオプションは、ユーザがセグメント化したいエリアの境界をユーザが引く間、ユーザに３つの直交像を表示することである。心臓の場合、表示される像は、短軸像に加えて、心臓の二腔像、三腔像、および四腔像であってよい。ユーザは、長軸において２つの直交輪郭を作成しさえすればよく、次いで、ソフトウェアは、２つの輪郭を補間することに基づいて、３Ｄサーフェスを自動的または自律的に作成することができる。３Ｄサーフェスは、迅速な修正のために短軸においてユーザに示され得る。解剖学的画像を示すことに加えて、血流速度画像（ベクトルをもつまたはもたない）が、対話式３Ｄボリュームセグメンテーションプロセス中に血液プール境界がどこにあるかをさらに明確にするために、解剖学的画像上に重ね合わせ可能である。
【0183】
[適応性フラッドフィル]
システムは、フラッド中に使用される接続性（６、１８、または２６方角接続性）によって、２Ｄ対３Ｄとして、およびステップの最大数によって半径制約対フラッド制約として区別され得る、複数のタイプのフラッドを利用する。すべての場合において、フラッドは、それが、１）フラッドの残りに接続され（どのような接続性が指定されたとしても使用して）、２）シード点においてピクセルの指定された閾値内の強度を有し、３）ピクセルが、シード点の最大数のステップの指定された半径内にある場合、指定されたシード点から外側に動き、フラッドの結果にピクセルを含めることによって機能する。ブラッドの結果は、２次元または３次元の接続されたマスクである。フラッドアルゴリズムは、静的／非静的な組織をマークするために３Ｄフラッドの形態でソリッド内で、２Ｄフラッドが短軸スタックにおいて輪郭を生成するために使用可能であるボリューム内で、およびフロー定量化において、使用され、２Ｄフラッドは、フラッド内に含まれるフローを決定するように血管をフラッドさせるために使用されてよい。
システムは、フラッド中に使用される接続性（６、１８、または２６方角接続性）によって、２Ｄ対３Ｄとして、およびステップの最大数によって半径制約対フラッド制約として区別され得る、複数のタイプのフラッドを利用する。すべての場合において、フラッドは、それが、１）フラッドの残りに接続され（どのような接続性が指定されたとしても使用して）、２）シード点においてピクセルの指定された閾値内の強度を有し、３）ピクセルが、シード点の最大数のステップの指定された半径内にある場合、指定されたシード点から外側に動き、フラッドの結果にピクセルを含めることによって機能する。ブラッドの結果は、２次元または３次元の接続されたマスクである。フラッドアルゴリズムは、静的／非静的な組織をマークするために３Ｄフラッドの形態でソリッド内で、２Ｄフラッドが短軸スタックにおいて輪郭を生成するために使用可能であるボリューム内で、およびフロー定量化において、使用され、２Ｄフラッドは、フラッド内に含まれるフローを決定するように血管をフラッドさせるために使用されてよい。
【0184】
半径制約２Ｄフラッドから輪郭を生成するために、本発明者らは、フラッドが必ず接続され、それが２値画像であるということを利用する。これらのことのために、本発明者らは、フラッドの内部に存在し得るいずれかの穴を無視する輪郭を見つけ出すために、標準的な境界トレーシングアルゴリズムを適用することがある。
【0185】
生成された輪郭から、次の動作は、潜在的に数百の点から、実際の輪郭を正確に近似するために閉じた３次スプラインによって使用されることになる制御点の小さいセットに、生成される輪郭を低下させることである。輪郭の周囲に等しく離隔された固定された数の制御点をシステムが単に離隔する単純なダウンサンプルは、他の手法ほどは機能しないが、それは、この手法が、乳頭筋を一回りしていたフラッドの凹状部分などの輪郭内の重要な特徴の喪失を頻繁にもたらすからである。これを避けるために、いくつかの行為に続行する「スマート」なダウンサンプル手法が用いられる。初めに、輪郭内の各点は、－１から１にわたるコーナー強度スコアが割り当てられ、ならびに、各点に「影響」のエリアを割り当てる。これが行われると、輪郭は、それらのコーナー強度がそれらの影響のエリア内で最大であるそれらの点のみに低減される。本発明者らが最小点間隔を有することを保証することおよび検出されたコーナーが十分に強いことを保証することなどの追加の基準も、このステージで施行される。先行する動作の結果は、フラッドにおいて検出された「コーナー」のリストである。これらをスプラインにおける制御点として使用することによって、この手法は、スプラインが輪郭内の興味深い特徴を失わないことを保証する。しかしながら、元の輪郭内の比較的低い湾曲のいかなる長い伸長部もコーナーとして検出されず、これは、結果として生じる輪郭のかなりの部分がいかなる制御点を有さず、そのようなセグメント内のスプラインによる不十分な近似に至ることをもたらし得る。これを避けるために、誤差メトリックが、点を通過する元の輪郭のセグメントおよび、それらの点を通過するスプラインのセグメントによって形成される閉じた輪郭の面積を計算することによって、制御点の各ペアに対して算出される。誤差が、何らかの固定された許容差を上回る場合、別の制御点が、元の輪郭のセグメントの中間点に追加される。この動作は、各セグメントが、必要とされる許容差を下回る算出された誤差を有するまで、繰り返される。
【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】
１１３８では、サービス制御１１０２が、識別不能化サービス９０４を開始する。１１４０では、識別不能化サービス９０４が、ボリューム鍵を起動サービス１１１０から得て、起動サービス１１１０は、１１４２において、ボリューム鍵を識別不能化サービスに返す。１１４４では、識別不能化サービス９０４が、ボリューム鍵を使用して、共有ＥｎｃＦＳボリュームをマウントする。１１４６では、識別不能化サービス９０４が、識別不能化サービスが開始したことをサービス制御１１０２に通知する。
【0246】
１１４８では、サービス制御１１０２が、スキャナアップロードサービス９０２を開始する。１１５０では、スキャナアップロードサービス９０２が、ボリューム鍵を起動サービス１１１０から得て、起動サービス１１１０は、１１５２において、ボリューム鍵をスキャナアップロードサービスに返す。１１５４では、スキャナアップロードサービス９０２が、ボリューム鍵を使用して、ＥｎｃＦＳボリュームをマウントする。１１５６では、スキャナアップロードサービス９０２が、スキャナアップロードサービスが開始したことをサービス制御１１０２に通知する。
【0247】
１１５８では、サービス制御１１０２が、アーチファクトサービス１１０８を開始する。１１６０では、アーチファクトサービス１１０８が、ボリューム鍵を起動サービス１１１０から得て、起動サービス１１１０は、１１６２において、ボリューム鍵をアーチファクトサービスに返す。１１６４では、アーチファクトサービス１１０８が、ボリューム鍵を使用して、ＥｎｃＦＳボリュームをマウントする。１１６６では、アーチファクトサービス１１０８が、アーチファクトサービスが開始したことをサービス制御１１０２に通知する。
【0248】
１１６８では、サービス制御１１０２が、ＳＳＬプロキシサービス１１０６を開始する。ＳＳＬプロキシサービス１１０６は、最後に開始する。ＳＳＬプロキシサービス１１０６は、すべての内部サービスへの外部アクセスを制御する。１１７０では、ＳＳＬプロキシサービス１１０６が、ＳＳＬプロキシサービスが開始したことをサービス制御１１０２に通知する。
【0249】
図１２は、ＰＨＩサービスの識別不能化サービス９０４のためのプロセス１２００を例示する、フロー図である。識別不能化サービス９０４は、スキャナアップロードサービス９０２によってアップロードされたスタディを処理し、すべての情報を収集し、ＡＳＰシステム５０４にアップロードすることが安全であることを保証することを担当する。識別不能化サービス９０４の主な構成要素は、ＤＩＣＯＭデータに対して実行される実際の識別不能化行為である。少なくともいくつかの実装形態では、ＧＤＣＭプロジェクトからの修正されたｇｄｃｍａｎｏｎユーティリティが使用されてよい。
【0250】
プロセス１２００は、例えば、スキャナアップロードサービス９０２が、スタディのための抽出されたＤＩＣＯＭファイルを識別不能化サービス９０４に送信するとき、１２０２において開始する。１２０４では、ＰＨＩ処理モジュールが開始される。１２０６では、いくつかの処理行為１２０８～１２２２が実行される。具体的には、１２０８では、処理されることになるスタディを含むフォルダの名前が変更される。１２１０では、すべての非スタディファイル（例えば、ｓｈａ１ｓｕｍ）が除去される。１２１２では、識別不能化サービス９０４が、ＤＩＣＯＭファイルからＰＨＩを抽出する。１２１４では、識別不能化サービスが、ＤＩＣＯＭファイルを識別不能化する。すべての抽出されたＰＨＩデータは、例えば、あらゆるＤＩＣＯＭファイルに対して収集され、記憶されてよく、プロセスの終了時に記憶サービス９０８に送信されてよい。
【0251】
１２１６では、識別不能化サービス９０４が、難読化されたＵＩＤを抽出する。識別不能化行為１２１４が、ＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤを、難読化された値で置き換える。元のデータは、この値によって、ＡＳＰシステム５０４に送信されたスタディとリンクされる。
【0252】
１２１８では、識別不能化サービス９０４が、ＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤと難読化されたＵＩＤとの間に一意のマッピングがあることを保証するために、難読化されたＵＩＤに対する衝突チェックを実行する。衝突がある場合、異なる難読化されたＵＩＤが、ＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤと難読化されたＵＩＤとの間の一意のマッピングを保証するために生成されてよい。
【0253】
１２２０では、例えば、識別不能化サービス９０４がＰＨＩデータを記憶サービス９０９に送信し、記憶サービス９０９が、ＰＨＩデータ１２２０をデータベース５２４に記憶する。１２２２では、識別不能化サービス９０４は、フォルダを識別不能化された状態に動かす。１２２４では、処理行為１２０６が完了すると、識別不能化されたデータは、アップローダサービス９０６によってＡＳＰシステム５０４にアップロードするために、待ち行列に入れられる。１２２６では、プロセス１２００は、例えば、処理される必要がある別のスタディが見出されるまで、終わる。１２２８では、処理行為１２０８～１２２２のいずれかにおいてエラーが検出された場合、ＰＨＩエラー処理モジュールが実行されることがある。
【0254】
収集されたＰＨＩデータは、２つのレベル情報、すなわちスタディレベルとシリーズレベルを用いて、ドキュメント内で組織されてよい。データは、ＡＳＰシステム５０４によって記憶されたデータとのリンクを提供する難読化されたＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤによってインデックスが付与されてよい。ＰＨＩデータは記憶サービス９０８に送信されてよく、記憶サービス９０８は、データを暗号化してデータベース５２４に記憶する。
【0255】
ＩＳＯ２０２２データを扱うために、ｄｃｍｃｏｎｖユーティリティ（ｄｃｍｔｋプロジェクトからの）が使用されてよい。ＤＩＣＯＭファイルの減少されたセットからＰＨＩデータを読み込む前に、ＤＩＣＯＭファイルは、ＵＴＦ－８に変換されてよい。これは、収集されたすべてのＰＨＩデータが一貫したフォーマットであることを保証しながら、変換される必要があるファイルの数を制限することによって、プロセスを高速化する。
【0256】
ユーティリティｇｄｃｍａｎｏｎは、ＤＩＣＯＭデータのフォルダ内の識別不能化を扱う。しかしながら、プロジェクトは、２００８ ＮＥＭＡ規格のみに識別不能化する。したがって、少なくともいくつかの実装形態では、最新ＤＩＣＯＭ規格に準拠するために必要とされるＤＩＣＯＭタグを追加したｇｄｃｍａｎｏｎユーティリティの修正されたバージョンが使用される。
【0257】
ユーティリティはまた、ＰＨＩを暗号化し、ＰＨＩを各ＤＩＣＯＭファイル内に新しいタグとして記憶する。ＰＨＩシステム５１０は、暗号化されるときですら、いかなる識別不能化されたデータを送信せず、そのため、ユーティリティは、暗号化されたデータの新しいタグを挿入するステップをスキップするためにさらに修正される。これは、そのタグを後で除去する追加のステップを追加する必要を除去することによって、プロセスをさらに高速化する。
【0258】
ＰＨＩシステム５１０が機能するために、スタディレベルおよびシリーズレベルにおけるＰＨＩの小さいサブセットのみ必要となる。しかしながら、ＤＩＣＯＭ規格は、はるかに多くのフィールドを除去する。ＰＨＩシステム５１０のデータベース５２４をより小さく保つために、このことはユーザのために性能を増強するが、ＰＨＩシステムは、必要とされるデータのみをデータベース５２４に記憶することがある。追加のフィールドが必要とされる場合、またはＰＨＩデータを再処理することが必要とされている場合、各ＤＩＣＯＭファイルから除去された識別不能化されたデータが（例えば、圧縮およびアーカイブされたＪＳＯＮファイルとして）記憶されてよい。
【0259】
図１３Ａ～図１３Ｂ（総称して、図１３）は、ＰＨＩシステム５１０のアップローダまたはプッシャーサービス９０６のためのプロセス１３００を例示する、フロー図である。プッシャーサービス９０６は、２つの主要なタスクを有する。第１のタスクは、識別されたスタディをＡＳＰシステム５０４に転送することである。第２のタスクは、アップロードされたスタディのステータスを監視し、終了状態が到達されるまでＰＨＩシステム５１０の内部ステータスを更新することである。これは、ホストコンピュータシステム５１７が、スタディのためのステータスをＰＨＩシステム５１０に要求し、ＡＳＰシステム５０４から情報を受信することを可能にする。
【0260】
１３０２では、プッシャーサービス９０６は、識別不能化サービス９０４によって提供された識別不能化されたスタディに関してフォルダを監視する。次いで、プッシャーサービス９０６は、ファイルアップロードプロセス１３０４を始める。１３０６では、プッシャーサービス９０６は、識別不能化されたデータを束ねる（例えば、スタディに対してｔａｒおよびｇｚｉｐを行う）。１３０８では、プッシャーサービス９０６は、新しい束ねられたファイル（例えば、ｔａｒファイル）のｓｈａ１ｓｕｍを計算し、そのｓｈａ１ｓｕｍは、アップロードの完全性を検証するために使用され、また、ステータス更新を要求する鍵を提供する。１３１０では、プッシャーサービス９０６は、ファイル名がＰＨＩを含まないことを保証するためにファイルの名前を変更してよい（例えば、「＜ｓｈａ１ｓｕｍ＞．ｔｇｚ」）。
【0261】
１３１２では、名前が変更されたファイルが、次いで、送信再試行ループ１３１４を使用してＡＳＰシステム５０４にアップロードされてよい。送信側再試行ループは、試行間の増加された遅延と共にファイルをアップロードすることを引き続き試行する。いくつかの試行の後でファイルがアップロードに失敗した場合、エラーアップロードモジュール１３１６が実行されてよい。アップロードが成功した場合、ｓｈａ１ｓｕｍは、データ完全性を保証するために検証される。１３１８では、次いで、アップロードされたファイルが、ＡＳＰシステム５０４による処理のために待ち行列に入れられる。
【0262】
１３２０では、アップローダサービス９０６は、アップロードされたファイルのステータスをリモートで監視してよい。例として、アップローダサービス９０６は、ｓｈａ１ｓｕｍをルックアップキーとして使用することがある。アップロードされたファイルに関する可能な状態は、エラーが発生したことを表明する「エラー処理」、ファイルが処理中であることを表明する「処理中」、またはファイルが処理されたことを表明する「処理された」を含んでよい。
【0263】
記憶サービス９０８は、抽出されたＰＨＩデータを記憶することを担当し、そのため、それは、識別再可能化のために後で取り出し可能である。ストレージサービスが走らされるとき、記憶サービスは、上記で論じられたように、ＡＳＰシステム５０４と通信し、平文データ鍵および暗号化されたデータ鍵を取り出す。次いで、これらの鍵がメモリに記憶される。記憶サービス９０８がディスクに書き込む任意のデータは、平文データ鍵を用いて暗号化され、データを暗号化するために使用された平文データ鍵を識別する暗号化されたデータ鍵と一緒に記憶される。
【0264】
図１４Ａ～図１４Ｂ（総称して、図１４）は、プロセッサベースのクライアントデバイス５２０（図５）上でウェブアプリケーションを実行するウェブブラウザ内のデータの識別再可能化のためのプロセス１４００を例示する、システムシーケンス図１４００である。１４０２では、ウェブブラウザは、アプリケーションをロードするために、要求をＡＳＰシステム５０４に送信する。１４０４では、ＡＳＰシステム５０４が、ウェブブラウザ上でアプリケーションをロードする。ＡＳＰシステム５０４のウェブアプリケーション上で成功裏に認証されたユーザは、ウェブトークン（例えば、ＪＳＯＮウェブトークン）が与えられてよい。上記で論じられたように、このウェブトークンは、データを要求するとき、ウェブブラウザによってＰＨＩシステム５１０に送信される。ＳＳＬプロキシサービス１１０６（図１１）は、ユーザが依然としてウェブアプリケーションへの有効な認証されたアクセスを有することを保証するために、ＰＨＩシステム５１０の許可サービスにすべてのデータ要求をフォワーディングする。これは、ユーザに関する限り、透過的プロセスである。
【0265】
１４０６では、ウェブブラウザが、ＰＨＩシステム５１０についての情報をＡＳＰシステム５０４に要求する。１４０８では、ＡＳＰシステム５０４が、ＰＨＩシステム情報をウェブブラウザに送信する。１４１０では、ウェブブラウザが、ＰＨＩアクセストークンをＡＳＰシステム５０４に要求する。ＰＨＩアクセストークンは暗号化され、ＡＳＰシステム５０４によってのみ読み取り可能である。１４１２では、ＡＳＰシステム５０４が、暗号化されたＰＨＩアクセストークンをウェブブラウザに送信する。
【0266】
１４１４では、ウェブブラウザが、利用可能なスタディのワークリストに関してＰＨＩシステム５１０に問い合わせる。ＰＨＩシステム５１０へのすべての要求は、暗号化されたＰＨＩアクセストークンを含む。１４１６では、ＰＨＩシステム５１０が、暗号化されたアクセストークンを、有効性確認のためにＡＳＰシステム５０４に送信する。ＡＳＰシステム５０４は、アクセストークンが有効である（すなわち、アクセストークンは、アクティブなセッションに属する）ことを確かめる。１４１８では、ＡＳＰシステム５０４が、アクセストークンが有効であることを示す通知をＰＨＩシステム５１０に送信する。
【0267】
適切な認証／許可の後、ＰＨＩシステム５１０は、記憶サービス９０８のＡＰＩを介してワークリストおよびスタディＰＨＩデータを取り出す。１４２０では、ＰＨＩシステム５１０が、ワークリストＰＨＩデータをウェブブラウザに送信する。
【0268】
１４２２では、ワークリストからのスタディの選択時に、ウェブブラウザが、スタディをロードするために、要求をＡＳＰシステム５０４に送信する。そのような要求に応答して、ＡＳＰシステムは、コンピューティングシステム（例えば、算出クラスタ）上へスタディをロードし始める。１４２４では、ウェブブラウザが、選択されたスタディと関連付けられたＰＨＩデータに関して要求をＰＨＩシステム５１０に送信する。授けられたアクセスは、短時間にわたってキャッシュされてよく、したがって、この要求は、有効性確認を必要としないことがある。１４２６では、ＰＨＩシステム５１０が、選択されたスタディに関するＰＨＩデータをウェブブラウザに送信する。１４２８では、スタディが算出クラスタ上にロードされると、ＡＳＰシステム５０４が、スタディデータをウェブブラウザ５２０に送信する。
【0269】
１４３０では、ウェブブラウザが、ＡＳＰシステム５０４から受信されたスタディデータを、ＰＨＩシステム５１０から受信されたＰＨＩデータとマージし、ＡＳＰによって提供されるサービスを使用するために、同じものをユーザに提示する。したがって、プロセス１４００を使用すると、ユーザは、ＡＳＰシステムにＰＨＩデータへのアクセスを提供することなくＡＳＰシステム５０４によって提供されるフルスタディデータおよび分析へのアクセスを有する。
【0270】
図１５Ａ～図１５Ｂ（総称して、図１５）は、アーチファクト識別再可能化サービス１１０８を実装するためのプロセス１５００を例示する、システムシーケンス図である。アーチファクト識別再可能化サービス１１０８は、ＡＳＰシステム５０４と連絡をとり、任意の保留中のアーチファクトをダウンロードし、ダウンロードされたアーチファクトを識別再可能化し、それらをＰＡＣＳ５２５、ｗｅｂベースの放射線情報システム（ＷＲＩＳ）などの医療プロバイダ宛先システムに記憶することを担当する。
【0271】
１５０２では、アーチファクト識別再可能化サービス１１０８が、保留中のアーチファクトのリストを要求する要求をＡＳＰシステム５０４に送信する。１５０４では、ＡＳＰシステム５０４が、アーチファクト識別再可能化サービス１１０８に保留中のアーチファクトのリストを提供する。
【0272】
１５０６では、アーチファクト識別再可能化サービス１１０８が、保留中のアーチファクトの受信されたリスト内の保留中のアーチファクトの１つを得るために、要求をＡＳＰシステム５０４に送信する。アーチファクトは、セカンダリキャプチャオブジェクト、レポート、またはＡＳＰシステム５０８が医療プロバイダ宛先ストレージ５２５にプッシュすることを望み得る他の何かであってよい。１５０８では、ＡＳＰシステム５０４は、要求されたアーチファクトをアーチファクト識別再可能化サービス１１０８に送信する。
【0273】
１５１２では、アーチファクトサービス１１０８が、アーチファクトに関するＰＨＩデータを記憶サービス９０８に要求する。この要求は、応答において供給される、難読化されたＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤタグを利用して、そのＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤに関する元の関連付けられたタグ情報について、記憶サービス９０８に問い合わせてよい。１５１４では、ＰＨＩシステム５１０の記憶サービス９０８が、ＰＨＩデータをアーチファクトサービス１１０８に送信する。
【0274】
１５１６では、アーチファクトサービス１１０８が、アーチファクトを識別再可能化する。例えば、ＤＩＣＯＭデータの場合、ｄｃｍｏｄｉｆｙユーティリティが、アーチファクトが、最初に記憶されたそれらに合致するために、ＤＩＣＯＭタグを再度書き込むために使用されてよい。
【0275】
成功した識別再可能化時、アーチファクトは、医療プロバイダ宛先ストレージ５２５にプッシュされた。宛先は、ＰＡＣＳ、ＷＲＩＳ、または他の任意のサポートされる端点であってよい。接続詳細は、アーチファクト詳細と共にＡＳＰシステム５０４から提供されてよい。
【0276】
１５２２では、アーチファクトサービス１１０８が、そのアーチファクトのためのアーチファクト識別再可能化プロセスが完了したことを示す通知をＡＳＰシステム５０４に送信する。１５２４では、ＡＳＰシステム５０４が、そのアーチファクトのためのステータスが更新されたことをアーチファクトサービス１１０４に通知し、そのようなアーチファクトは、次の反復中に保留中のアーチファクトのリスト内でもはや返されないことを示す。
【0277】
上記で説明された自動化された手法は、従来の手法に特有である、フローおよび解剖学的構造を識別する際の主観性を除去し、ハイレベルまたは再現性を提供する。この再現性は、ＭＲＩデータの新しい使用を可能にする。例えば、単一の患者に関するＭＲＩデータが、傾向に関して、異なるセッションにわたって確実に検討されることがある。さらに驚くべきことに、複数の患者に関するＭＲＩデータが、母集団または人口統計にわたって、傾向に関して確実に検討されることがある。
【0278】
図１６は、例示される一実施形態に従った、図５に示されるＰＨＩサービスパイプラインと統合された信頼されるブローカサービス（ＴＢＳ）システム１６０１の概略図である。ＴＢＳシステム１６０１は、許可されたサードパーティが、許可されたアップローダから分析サービスプロバイダ（ＡＳＰ）ネットワーク５０２にアップロードされたデータへのアクセスを制御することを可能にする。例示的な一実施形態では、クプロセッサベースのライアントデバイス５２０は、許可されたサードパーティのそれであってよい。他の実施形態では、ＰＨＩシステムまたはサービス５１０は、許可されたサードパーティのそれであってよい。ＴＢＳシステムは、ＭＲＩデータ、４Ｄフローデータ、またはＰＨＩもしくは他の保護された情報もしくは個人情報を有してよい他の任意のタイプのデータを含んでよい医療スタディデータに適用され、これへのアクセスを記憶および制御するために使用されてよいが、他の実施形態では、本明細書において説明されるＴＢＳシステムおよびＰＨＩシステムは、限定するものではないが、機密性の高いデータ、信頼データ、分類されたデータ、秘密データ、所有権データ、個人情報、遺伝情報、医療履歴データ、疾患関連データ、メンタルヘルスデータ、臨床検査結果データ、血液検査結果データ、尿検査データ、薬物検査結果データ、遺伝子検査結果データ、生検データ、心電図データ、Ｘ線イメージングデータ、医療スキャンデータ、ＣＴスキャンデータ、超音波スキャンデータ、医療イメージングデータ、診査手術データ、犯罪経歴データ、個人経歴データ、軍歴データ、封印された裁判記録データ、懲罰記録データ、学歴データ、機密保持契約に従属するデータ、家系データ、出生記録データ、個人信用データ、個人財務データ、株式非公開企業データ、企業秘密データ、秘密指令に従属するデータ、科学的データ、石油およびガス探査データ、地質学的調査データ、新しい石油が見つかったことについての地質学的データ、地理的データ、石油の潜在的発見のエリアに関するデータ、ならびに貴重な鉱物の潜在的発見のエリアに関するデータ、のうちの１つまたは複数を含む、様々なタイプの医療データと非医療データに適用され、これへのアクセスを記憶および制御するために使用されてよい。
【0279】
ＡＳＰネットワーク５０２は、医療プロバイダ（例えば、病院）ネットワーク５０８（１つが示されている）と関連付けられた様々なシステムと、およびＴＢＳシステム１６０１と、ファイアウォール５０６を通して通信するＡＳＰシステム５０４（例えば、１つまたは複数のプロセッサベースのデバイス）を備える。ＡＳＰシステム５０４は、ＡＳＰネットワーク５０２に関する、本明細書において論じられる様々な機能のいくつかまたはすべてを提供する。ＡＳＰシステム５０４は、クラウドアーキテクチャを使用して実装されてよく、したがって、いくつかの分散されたプロセッサベースのデバイスを備えることがある。ＡＳＰシステム５０４は、例えば、ファイアウォール５０６を介してアクセス可能な１つまたは複数の通信ネットワークを介して、ＴＢＳシステム１６０１などの外部システムにアクセスすることがある。
【0280】
例示的な一実施形態では、この通信経路内に３つの主要な構成要素、すなわち、１．アップローダ、２．ＡＳＰシステム５０４、３．信頼されるブローカサービス１６０１があってよい。例示的な一実施形態では、許可されたアップローダは、上記で説明されたＰＨＩシステムまたはサービス５１０であってもよいし、この一部であってもよいし、これと統合されてもよい。ＴＢＳシステム１６０１は、１つまたは複数のコンピュータまたは他のデータ処理システム、例えば、図２に示されるそれ、データおよびコンピュータ実行可能命令を記憶し、それに応じて、本明細書において説明されるプロセスを実行するためにコンピュータ実行可能命令を実行するそれなどの、コンピュータを含んでよい。
【0281】
信頼されるブローカサービスは、ＪＳＯＮメタデータ（例えば、医療スタディデータに関するメタデータ）をアップローダ（例えば、ＰＨＩシステムまたはサービス５１０）から受け取り、それに一意識別子を割り当て、その識別子をアップローダに返す。信頼されるブローカサービス１６０１の内部では、識別子は、アクセス制御下でデータをどのように記憶およびダウンロードするかを示す命令と関連付けられる。
【0282】
信頼されるブローカサービス１６０１は、一意識別子が与えられたとき、アクセス命令を返すアプリケーションプログラミングインターフェース（ＡＰＩ）を露出させる。許可されたサードパーティ（例えば、プロセッサベースのクライアントデバイス５２０によって表される）は、信頼されるブローカサービス１６０１から一意識別子（および関連付けられた記録）を除去し、それによって、アクセス不能なその一意識別子を伴った状態でアップロードされたデータをレンダリングする。
【0283】
信頼されるブローカサービス１６０１は、アップローダとＡＳＰシステム５０４の両方から通信を受信する。この通信は、トランスポート層セキュリティ（ＴＬＳ）を使用して行われてよい。構成要素は、自己書き換え型ドメイン確認済みＳＳＬ証明書が与えられる。これは、呼び出し側構成要素が、出て行く通信は、認証的に呼び出される構成要素のみを用いて発生することを保証されることを可能にする。信頼されるブローカサービス１６０１は、クライアント証明書検証を使用して、ＡＳＰシステム５０４から入ってくる接続を検証する。
【0284】
例示的な一実装形態では、信頼されるブローカサービス１６０１によって要求される３つの証明書がある。
ｐｒｉｖａｔｅ＿ｋｅｙ
ｐｕｂｌｉｃ＿ｃｅｒｔと関連付けられた秘密鍵
ｐｕｂｌｉｃ＿ｃｅｒｔ
信頼されるブローカサービスがそのパブリック証明書として使用する信頼されるＣＡによって署名された、ｐｅｍフォーマットでの、ドメインにより有効性確認されたパブリック証明書チェーン
ａｒｔｅｒｙｓ＿ｃａ＿ｃｅｒｔ
ＡＳＰシステム５０４から入ってくる要求上でのクライアント証明書検証に使用される、ｐｅｍフォーマットの証明機関
ｐｒｉｖａｔｅ＿ｋｅｙ
ｐｕｂｌｉｃ＿ｃｅｒｔと関連付けられた秘密鍵
ｐｕｂｌｉｃ＿ｃｅｒｔ
信頼されるブローカサービスがそのパブリック証明書として使用する信頼されるＣＡによって署名された、ｐｅｍフォーマットでの、ドメインにより有効性確認されたパブリック証明書チェーン
ａｒｔｅｒｙｓ＿ｃａ＿ｃｅｒｔ
ＡＳＰシステム５０４から入ってくる要求上でのクライアント証明書検証に使用される、ｐｅｍフォーマットの証明機関
【0285】
上記の証明書は、スタートアップ中にＡＳＰシステム５０４から取り出されることがある。
【0286】
例示的な実施形態では、証明書は、満了期間を有し、満了前に自動的に書き換えられる。
【0287】
例示的な実施形態では、信頼されるブローカサービス１６０１は、ＡＰＩ要求を介して、ＡＳＰシステム５０４に対する、更新された証明書に関する周期的な要求を作成する。更新された証明書が存在する場合、信頼されるブローカサービスが、それらをインストールする。
【0288】
暗号化ベースの制御：
例示的な実施形態では、信頼されるブローカサービス１６０１は、各メタデータアップロードに対する暗号化情報を生成する。これは、一意の暗号化鍵と共に使用する暗号化／暗号化解除アルゴリズムを含む。
例示的な実施形態では、信頼されるブローカサービス１６０１は、各メタデータアップロードに対する暗号化情報を生成する。これは、一意の暗号化鍵と共に使用する暗号化／暗号化解除アルゴリズムを含む。
【0289】
ＡＳＰシステム５０４が、アップロード識別子と関連付けられたデータを保存したいまたは読み出したいときはいつでも、ＡＳＰシステム５０４は、アップロード識別子を使用して、信頼されるブローカサービス１６０１に暗号化情報を要求する。
【0290】
許可されたサードパーティは、信頼されるブローカサービス１６０１から一意識別子（および関連付けられた記録）を除去し、それによって、暗号化解除することが不可能なその一意識別子と共にアップロードされたデータをレンダリングする。
【0291】
図１７は、例示される一実施形態に従った、暗号化ベースのデータアップロードがＴＢＳシステムによってどのように実行されるかを示す、アップローダおよびＴＢＳシステムの概略図である。
【0292】
信頼されるブローカサービスと通信するために、アップローダは、最初に、信頼されるブローカサービスアドレスと、認証トークンをＡＳＰシステムに要求する。（１）
【0293】
この要求の認証は、インストール中にアップローダ構成要素上に存在するＡＰＩ鍵および秘密を使用して行われる。
【0294】
アドレスおよび認証トークンの成功した受信時、アップローダは、それが記憶することを望むメタデータを、認証トークンと共に、信頼されるブローカサービスに送信する。（２）
【0295】
信頼されるブローカサービスは、認証トークンの検証を要求するＡＳＰシステムへの出て行く接続を作る。（３）
【0296】
成功した検証時に、信頼されるブローカサービスは、アップローダによって送信されたメタデータを保存する。これは、将来関連付けられるデータをＡＳＰシステムがどのようにして暗号化するべきかを示す何らかの暗号化情報と共に、そのメタデータのための一意識別子の生成を伴う。この一意識別子はアップローダに返される。（４）
【0297】
アップローダは、ここで、一意識別子と共に、データをＡＳＰシステムに送信する。（５）
【0298】
ＡＳＰシステムは、一意識別子と共に、それに問い合わせることによって、信頼されるブローカサービスにデータのための暗号化情報を要求する。（６）
【0299】
返された暗号化情報は、アップロードされるデータを暗号化するために、記憶の前に使用される。（７）
【0300】
図１８は、例示される一実施形態に従った、暗号化ベースのデータダウンロードがＴＢＳシステムによってどのように実行されるかを示す、エンドユーザシステム、ＡＳＰシステム、およびＴＢＳシステムの概略図である。
【0301】
ＡＳＰシステムがデータ要求を受信したとき、それは、内部ストレージ内の対応するアップロード識別子を探す（１）。例えば、この要求は、図５および図１６に示されるプロセッサベースのクライアントデバイス５２０からであってよい。他の実施形態では、この要求は、図５および図１６に示されるＰＨＩシステムまたはサービス５１０からであってよい。
【0302】
そのアップロード識別子と関連付けられた暗号化情報に関する要求が、信頼されるブローカサービスに送信される（２）。
【0303】
返された暗号化情報は、それが返される前に、ストレージからの要求されたデータを暗号化解除するために使用される（３）。
【0304】
データアクセスの失効：
信頼されるブローカサービスは、アクセスが取り消されることになるデータを突き止めるために、そのアップロードメタデータの検索を可能にする。
信頼されるブローカサービスは、アクセスが取り消されることになるデータを突き止めるために、そのアップロードメタデータの検索を可能にする。
【0305】
合致する記録が突き止められると、それらは、内部ストレージから除去され得る。それらの一意識別子が与えられた、暗号化情報に関するその後の要求は、もはや合致を見出さず、暗号化情報は返されない。
【0306】
これは、ＡＳＰシステムが、いかなる記憶されたデータを暗号化解除することが可能でなく、したがって、そのデータへのアクセスを取り消すことを保証する。
【0307】
図１９は、例示される一実施形態に従った、アクセスベースのデータアップロードがＴＢＳシステムによってどのように実行されるかを示す、アップローダ、ＡＳＰシステム、およびＴＢＳシステムの概略図である。
【0308】
アクセスベースの制御：
信頼されるブローカサービスは、ＵＲＬと関連付けられたアクセス方針に応じて、ＡＳＰシステムがそのＵＲＬにファイルを記憶するまたはそのＵＲＬからファイルをダウンロードすることを可能にする、事前署名された、時間満了アクセスＵＲＬを生成する。
信頼されるブローカサービスは、ＵＲＬと関連付けられたアクセス方針に応じて、ＡＳＰシステムがそのＵＲＬにファイルを記憶するまたはそのＵＲＬからファイルをダウンロードすることを可能にする、事前署名された、時間満了アクセスＵＲＬを生成する。
【0309】
信頼されるブローカサービスと通信するために、アップローダは、最初に、信頼されるブローカサービスアドレスおよび認証トークンをＡＳＰシステムに要求しなければならない。（１）この要求の認証は、インストール中にアップローダ構成要素上に存在するＡＰＩ鍵および秘密を使用して行われる。
【0310】
アドレスおよび認証トークンの成功した受信時、アップローダは、それが記憶することを望むメタデータを、認証トークンと共に、信頼されるブローカサービスに送信する。（２）
【0311】
信頼されるブローカサービスは、認証トークンの検証を要求するＡＳＰシステムへの出て行く接続を作る。（３）
【0312】
成功した検証時に、信頼されるブローカサービスは、アップローダによって送信されたメタデータを保存する。これは、そのメタデータのための一意識別子の生成を伴う。この一意識別子はアップローダに返される。（４）
【0313】
アップローダは、次に、一意識別子と共にデータをＡＳＰシステムに送信する。（５）
【0314】
ＡＳＰシステムは、ファイル名および一意識別子を信頼されるブローカサービスに送信することによって、事前署名されたアップロードＵＲＬを要求する。（６）
【0315】
信頼されるブローカサービスは、要求されたファイル名を一意識別子に関連付け、そのファイル名のための事前署名されたアップロードＵＲＬを生成する。信頼されるブローカサービスは、ＵＲＬをＡＳＰシステムに返す。（７）
【0316】
ＡＳＰシステムは、それがアップロードすることを、事前署名されたアップロードＵＲＬに望むデータを送信する。（８）
【0317】
図２０は、例示される一実施形態に従った、アクセスベースのデータダウンロードがＴＢＳシステムによってどのように実行されるかを示す、エンドユーザシステム、ＡＳＰシステム、およびＴＢＳシステムの概略図である。
【0318】
ＡＳＰシステムがデータ要求を受信したとき、ＡＳＰシステムは、内部ストレージ内の対応するアップロード識別子およびファイル名を探す（１）。
【0319】
そのファイル名およびアップロード識別子と関連付けられた事前署名されたダウンロードＵＲＬに関する要求が、信頼されるブローカサービスに送信される（２）。
【0320】
信頼されるブローカサービスは、要求されたファイルに関する事前署名されたダウンロードＵＲＬを生成する（３）。
【0321】
次いで、ＡＳＰシステムが、事前署名されたダウンロードＵＲＬによって指定されたロケーションにおけるデータを要求し得る（４）。
【0322】
データアクセスの失効
信頼されるブローカサービスは、アクセスが取り消されることになるデータを突き止めるために、そのアップロードメタデータの検索を可能にする。
信頼されるブローカサービスは、アクセスが取り消されることになるデータを突き止めるために、そのアップロードメタデータの検索を可能にする。
【0323】
合致する記録が突き止められると、それらは、内部ストレージから除去され得る。事前署名されたｕｒｌに関するその後の要求は、合致がもはや見出されないので、失敗する。
【0324】
これは、ＡＳＰシステムが、信頼されるブローカサービスによって制御される、いかなる記憶されたデータにアクセスすることが可能でないことを保証する。
【0325】
アクセスベースのデータアップロードプロセス、データアクセスプロセス、およびアクセス失効プロセスのいくつかまたはすべてが、本明細書において説明される暗号化ベースのデータアップロードプロセス、データアクセスプロセス、およびアクセス失効プロセスの代わりに使用されてもよいし、これらに関連して使用されてもよい。
【0326】
図２１は、例示される一実施形態に従った、医療分析プラットフォームの分析サービスプロバイダ（ＡＳＰ）システムを動作させるプロセス２１００を例示する、フロー図である。例えば、分析サービスプロバイダ（ＡＳＰ）システムは、ＡＳＰシステム５０４であってよい。
【0327】
２１０２では、ＡＳＰシステムが、医療スタディデータの一意識別子と共に医療スタディデータを受信する。
【0328】
２１０４では、ＡＳＰシステムは、ＡＳＰシステム上に医療スタディデータの一意識別子を記憶する。
【0329】
２１０６では、ＡＳＰシステムが、受信された医療スタディデータに対するアクセス命令を求める要求を送信し、この要求は、医療スタディデータの一意識別子を含む。
【0330】
２１０８では、ＡＳＰシステムが、要求に応答してアクセス命令を受信する。
【0331】
２１１０では、ＡＳＰシステムが、受信されたアクセス命令を使用して、ＡＳＰシステム上に医療スタディデータを記憶する。
【0332】
図２２は、例示される一実施形態に従った、医療分析プラットフォームの信頼されるブローカサービス（ＴＢＳ）システムを動作させるプロセス２２００を例示する、フロー図である。
【0333】
２２０２では、ＴＢＳシステムが、分析サービスプロバイダ（ＡＳＰ）システムから、医療スタディデータがＡＳＰシステム上に記憶されるためのアクセス命令を求める要求を受信し、この要求は、医療スタディデータの一意識別子を含む。
【0334】
２２０４では、ＴＢＳシステムが、一意識別子を使用して、医療スタディデータのためのアクセス命令を取り出す。
【0335】
２２０６では、ＴＢＳシステムが、アクセス命令に関する要求に応答して、医療スタディデータのためのアクセス命令をＡＳＰシステムに送信する。
【0336】
図２３は、例示される一実施形態に従った、医療分析プラットフォームの医療スタディデータアップローダ（ＭＳＤＵ）システムを動作させるプロセス２３００を例示する、フロー図である。
【0337】
２３０２では、ＭＳＤＵシステムが、認証トークンおよび信頼されるブローカサービス（ＴＢＳ）システムのアドレスを求める要求を分析サービスプロバイダ（ＡＳＰ）システムに送信し、この要求は、ＭＳＤＵシステム上に記憶されたアプリケーションプログラミングインターフェース（ＡＰＩ）鍵および一意の秘密を含む。
【0338】
２３０４では、ＭＳＤＵシステムが、ＡＳＰシステムに送信された要求に応答して、認証トークンとＴＢＳシステムのアドレスをＡＳＰシステムから受信する。
【0339】
２３０６では、ＭＳＤＵシステムが、ＴＢＳシステムのアドレスを使用して、認証トークンと共に医療スタディデータに関するメタデータをＴＢＳシステムに送信する。
【0340】
２３０８では、ＭＳＤＵシステムが、ＴＢＳシステムへの認証トークンと共に医療スタディデータに関するメタデータの送信に応答して、医療スタディデータの一意識別子をＴＢＳシステムから受信する。
【0341】
２３１０では、ＭＳＤＵシステムが、ＡＳＰシステム上での記憶のために、医療スタディデータと共に、医療スタディデータの一意識別子をＡＳＰシステムに送信する。
【0342】
図２４は、例示される一実施形態に従った、医療スタディデータアップローダ（ＭＳＤＵ）システムと、分析サービスプロバイダ（ＡＳＰ）システムと、信頼されるブローカサービス（ＴＢＳ）システムとを含む、医療分析プラットフォームを動作させるプロセス２４００を例示する、フロー図である。
【0343】
２４０２では、ＭＳＤＵシステムが、医療スタディデータに関するメタデータをＴＢＳシステムに送信する。
【0344】
２４０４では、ＴＢＳシステムが、医療スタディデータの一意識別子を生成する。
【0345】
２４０６では、ＴＢＳシステムが、医療スタディデータについてのアクセス情報を生成する。
【0346】
２４０８では、ＴＢＳシステムは、医療スタディデータの一意識別子を、医療スタディデータについてのアクセス情報および医療スタディデータに関するメタデータと関連付ける。
【0347】
２４１０では、ＴＢＳシステムが、医療スタディデータに関するメタデータをＴＢＳシステム上に記憶する。
【0348】
２４１２では、ＴＢＳシステムが、医療スタディデータの一意識別子の、医療スタディデータについてのアクセス情報および医療スタディデータに関するメタデータとの関連付けをＴＢＳシステム上に記憶する。
【0349】
２４１４では、ＴＢＳシステムが、医療スタディデータの一意識別子をＭＳＤＵシステムに送信する。
【0350】
２４１６では、ＭＳＤＵシステムが、ＡＳＰシステム上での記憶のために、医療スタディデータと共に、医療スタディデータの一意識別子をＡＳＰシステムに送信する。
【0351】
２４１８では、ＡＳＰシステムが、医療スタディデータの一意識別子をＡＳＰシステム上に記憶する。
【0352】
２４２０では、ＡＳＰシステムが、受信された医療スタディデータに対するアクセス命令を求める要求を送信し、この要求は、医療スタディデータの一意識別子を含む。
【0353】
２４２２では、ＡＳＰシステムが、要求に応答してアクセス命令を受信する。
【0354】
２４２４では、ＡＳＰシステムが、受信されたアクセス命令を使用して、ＡＳＰシステム上に医療スタディデータを記憶する。
【0355】
長手方向に追跡する完全に識別不能化された医療スタディ
以下は、可能な一実装形態の説明を提供する。図２５～図２８は、以下で説明される特徴を例示する。具体的には、図２５は、完全に識別不能化された医療スタディを追跡するシステム２５００の概略ブロック図である。システム２５００は、ＰＨＩサービス２５０２と、リモートサービス２５０４と、スキャナ２５０６と、関連スタディサービス２５０８と、設定２５１０とを含む。図２６は、ＰＨＩサービスのためのスタートアップ動作２６００を例示する、フロー図であり、図２７は、組織設定プロセス２７００の変更を例示する、フロー図であり、図２８は、新しいスタディのスキャン時に実施されるプロセス２８００の流れフロー図である。
以下は、可能な一実装形態の説明を提供する。図２５～図２８は、以下で説明される特徴を例示する。具体的には、図２５は、完全に識別不能化された医療スタディを追跡するシステム２５００の概略ブロック図である。システム２５００は、ＰＨＩサービス２５０２と、リモートサービス２５０４と、スキャナ２５０６と、関連スタディサービス２５０８と、設定２５１０とを含む。図２６は、ＰＨＩサービスのためのスタートアップ動作２６００を例示する、フロー図であり、図２７は、組織設定プロセス２７００の変更を例示する、フロー図であり、図２８は、新しいスタディのスキャン時に実施されるプロセス２８００の流れフロー図である。
【0356】
図２５を参照すると、関連スタディサービス２５０２は、組織（例えば、病院）内でホストされることがある。動作時、関連スタディサービス２５０２は、識別不能化情報のための暗号学的ハッシュを生成する。関連スタディサービス２５０８は、サービスが開始したとき、最初に暗号鍵をロードすることがある。鍵が存在しない場合、サービス２５０８は、（例えば、オペレーティングシステムの擬似乱数生成器を使用して）鍵を生成する。
【0357】
スタートアップ時に、２６０２において、関連スタディサービス２５０８が、最初に、組織の構成された識別フィールドをロードする。それは、別の構成または設定サービス２５１０に問い合わせることによって、これを行い、構成または設定サービス２５１０は、同じアプリケーションの一部であってよく、次いで、構成または設定サービス２５１０は、組織の構成情報についてリモートサービス２５０４に問い合わせる。この構成サービス２５１０は、構成更新についてリモートサービス２５０４に周期的に問い合わせ、関連スタディサービス２５０８などの依存サービスに何らかの変更を通知することが可能である（図２７の方法２７００の２７０２および２７０４を参照されたい）。
【0358】
２６０４では、組織の構成された識別フィールドを取り出した後、関連スタディサービス２５０８は、記憶された識別データ（例えば、スキャンによってグループ化された）に問い合わせ、組織の構成によって指定されたフィールドのすべておよび以前に生成された鍵を付加することによって、各スタディに対してハッシュ（例えば、ｓｈａ２５６ハッシュ）を生成する。
【0359】
２６０６において、新しく生成された暗号学的ハッシュが、同じスタディに関するキャッシュされたバージョンと異なる場合、または以前にキャッシュされたバージョンがない場合、２６０８では、次いで、関連スタディサービス２５０８が、ＨＴＴＰ ＡＰＩ端点を介して暗号学的ハッシュをリモートサービス２５０４に送信する（２６１０において受信される）（鍵／秘密およびｓｓｌを介して安全にされる）、次いで、そのキャッシュ内にデータをローカルに記憶する。
【0360】
新しいスタディが、通常動作中にイメージングデバイス２５０６から関連スタディサービス２５０８によって受信されたとき、関連スタディサービスは、暗号学的ハッシュを計算し、そのスタートアップ計算の間と同じＡＰＩ方法を介してリモートサービス２５０４に暗号学的ハッシュを送信する（例えば、図２８の方法２８００の行為２８０２～２８１８を参照されたい）。次いで、新しく生成された暗号学的ハッシュが、関連スタディサービス２５０８のキャッシュ内に記憶される。
【0361】
構成サービス２５１０が組織の構成の変更を検出したとき、構成サービスは、すべての依存サービスに通知する。関連スタディサービス２５０８の場合、変更通知が構成サービス２５１０から受信されたとき、関連スタディサービスは、スタートアップ時実行されたのと同じプロセスを実行し、すべての記憶されたデータを再び通過し、必要とされる場合にリモートクラウドサービス２５０４に送信されることになる暗号学的ハッシュを再生成する。
【0362】
関連スタディサービス２５０８によって送信され、リモートクラウドサービス２５０４によって受信される、各スキャンのためのそのデータは、難読化されたＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤと、暗号学的ハッシュとを含む。難読化されたＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤは、リモートクラウドサービス２５０４内でスキャンの各々を一意に識別するために使用される。
【0363】
リモートクラウドサービス２５０４は、各スキャンに対する難読化されたＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤをスキャンの収集された情報の残りに対する鍵として使用して、スキャンの収集された情報から別々にスタディを関連する暗号学的ハッシュを記憶する。これは、スキャン間の関係を提供する暗号学的ハッシュが、スキャンと関連付けられた画像およびメタデータに影響を及ぼすことなく、迅速に修正または除去されることを可能にする。それは、漏洩の場合に情報を分けられたように保つことによって、セキュリティも提供する。データ漏洩の場合、攻撃者は、データの両方のセット（すなわち、スキャンの処理中に記憶された識別不能化されたフィールドと、難読化されたＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤを介してリンクされた暗号学的ハッシュ）を必要とする。追加のセキュリティが、識別データに付与された一意の暗号鍵（上記で説明された）を使用することによって提供される。攻撃者が、組織のデータセンタ内で関連スタディサービス２５０８をホストするサーバ上に暗号化されて記憶された鍵へのアクセスを有さずに、識別情報へのアクセスを有していた場合、攻撃者は、患者のためのｓｈａ２５６サムを決定することは不可能である。
【0364】
少なくともいくつかの実装形態では、本開示は、識別不能化された複数のＤＩＣＯＭスタディ間の関係を確立するためのシステムおよび方法を提供し得る。スタディは、共通フィールドを使用してリンクされてよい。共通フィールドは、組織レベルで選ばれてよい。デフォルト共通識別フィールドは、例えば、ＰａｔｉｅｎｔＩＤと、ＩｎｓｔｉｔｕｔｉｏｎＮａｍｅとを含んでよい。共通フィールドは、組織秘密鍵と組み合わされてよい。組織ごとに一意の鍵は、誰かが、共通フィールドのみを使用して暗号学的ハッシュを作成することを防止し、これは、データを安全に保つ。一意の秘密と共に共通フィールドの暗号学的ハッシュは、すべての関連するスタディ間に共通する一意識別子を提供するために、計算および使用されてよい。
【0365】
暗号学的ハッシュは、ＰＨＩサーバ２５０２上の記憶された識別データを使用して計算され、クラウドサーバ２５０４に送信されてよい。暗号学的ハッシュは、識別不能化されたデータと共に記憶されないことがある。ハッシュが、識別不能化されたデータと共に記憶されないことがあるので、ハッシュは遡及して生成可能であり、ハッシュは、異なる共通フィールドを使用して再生成することが可能であり、ハッシュは、すべてのＤＩＣＯＭデータを再処理する必要なく迅速に削除または再計算可能である。
【0366】
各新しく処理されたスタディの暗号学的ハッシュは、クラウドサーバ２５０４に送信されてよい。
【0367】
暗号学的ハッシュは、周期的に計算され、以前に記憶された値と比較されてよい。異なる場合（以前に記憶されていないことを含む）、それらは、クラウドサービス２５０４に再送信されてよい。これは、以前に処理されたスタディが関連することを可能にする。これは、共通フィールドが修正されることも可能にし、すべてのデータは、新しい手段で関連することが可能である。
【0368】
ＰＨＩサーバ２５０２は、組織の構成された共通フィールドについてクラウドサーバ２５０４に周期的に問い合わせてよい。これは、組織が識別共通フィールドを変更し、最小の労力で関係を再生成することを可能にする。
【0369】
図２９は、例示される一実施形態に従った、医療分析プラットフォームの分析サービスプロバイダ（ＡＳＰ）システムおよび保護された健康情報（ＰＨＩ）システムをＰＨＩにアクセスするように動作させるプロセス２９００を例示する、フロー図である。医療分析プラットフォームは、図５に示される医療分析プラットフォーム５００のすべてまたは一部を備えてよい。例えば、医療分析プラットフォームは、分析サービスプロバイダ（ＡＳＰ）システムと、保護された健康情報（ＰＨＩ）システムとを備えてよい。様々な実施形態では、ＡＳＰシステムは、図５に示されるＡＳＰネットワーク５０２および／またはＡＳＰシステム５０４のすべてまたは一部を備えてよい。様々な実施形態では、ＰＨＩシステムは、図５に示されるＰＨＩシステム５１０のすべてまたは一部を備えてよい。
【0370】
２９０２では、ＡＳＰシステムの少なくとも１つのプロセッサが、識別不能化された医療スタディデータを、ＡＳＰシステムの少なくとも１つの非一時的なプロセッサ可読記憶媒体上に記憶する。
【0371】
２９０４では、ＰＨＩシステムの少なくとも１つのプロセッサが、識別不能化された医療スタディデータと関連付けられたＰＨＩデータを、ＰＨＩシステムの少なくとも１つの非一時的なプロセッサ可読記憶媒体上に記憶する。
【0372】
２９０６では、ＡＳＰシステムの少なくとも１つのプロセッサが、少なくとも１つの通信ネットワークを介してプロセッサベースのクライアントデバイスから医療スタディを求める要求を受信する。
【0373】
２９０８では、ＡＳＰシステムの少なくとも１つのプロセッサが、プロセッサベースのクライアントデバイスから受信された医療スタディを求める要求を認証する。
【0374】
２９１０では、ＡＳＰシステムの少なくとも１つのプロセッサが、要求された医療スタディと関連付けられたＰＨＩデータを、少なくとも１つの通信ネットワークを介してＰＨＩシステムに要求する。
【0375】
２９１２では、ＰＨＩシステムの少なくとも１つのプロセッサが、要求に応答して、要求されたＰＨＩデータを、少なくとも１つの通信ネットワークを介してＡＳＰシステムに送信する。
【0376】
２９１４では、ＡＳＰシステムの少なくとも１つのプロセッサが、ＰＨＩデータを、少なくとも１つの通信ネットワークを介してＰＨＩシステムから受信する。
【0377】
２９１６では、ＡＳＰシステムの少なくとも１つのプロセッサが、受信されたＰＨＩデータを、少なくとも１つの通信ネットワークを介して要求側プロセッサベースのクライアントデバイスに送信する。
【0378】
２９１８では、ＡＳＰシステムの少なくとも１つのプロセッサが、要求された医療スタディのための識別不能化された医療スタディデータを、少なくとも１つの通信ネットワークを介してプロセッサベースのクライアントデバイスに送信する。
【0379】
ＰＨＩシステムから要求された医療スタディと関連付けられたＰＨＩデータを要求することは、ＡＳＰシステムの少なくとも１つのプロセッサによって、要求された医療スタディと関連付けられたＰＨＩデータのためのＨＴＴＰＳロングポーリング要求をＰＨＩシステムのサーバに送信することを含んでよい。ＰＨＩシステムのサーバは、要求された医療スタディと関連付けられたＰＨＩデータが利用可能になるまで、要求を未解決に保ち得る。要求されたＰＨＩデータの、ＡＳＰシステムへの送信は、ＰＨＩシステムのサーバに送信されたＨＴＴＰＳロングポーリング要求に応答してよい。
【0380】
要求されたＰＨＩデータの、ＡＳＰへの送信は、ＰＨＩシステムの少なくとも１つのプロセッサによって、ＡＳＰシステムからＰＨＩシステムのサーバに送信されたＨＴＴＰＳロングポーリング要求に応答して、要求されたＰＨＩデータをＡＳＰシステムに送信することを含んでよい。また、ＰＨＩシステムからＰＨＩデータを受信したことに応答して、ＡＳＰシステムの少なくとも１つのプロセッサは、少なくとも１つの通信ネットワークを介して、ＰＨＩシステムからの新しいＰＨＩデータに関する別のＨＴＴＰＳロングポーリング要求を、ＰＨＩシステムに即時に送信してよい。
【0381】
受信されたＰＨＩデータの、要求側プロセッサベースのクライアントデバイスへの送信は、ＡＳＰシステムによってＰＨＩデータを持続的に記憶することなく、受信されたＰＨＩデータを要求側プロセッサベースのクライアントデバイスに送信することを含んでよい。また、受信されたＰＨＩデータの、要求側プロセッサベースのクライアントデバイスへの送信は、ＡＳＰシステムによって受信されたＰＨＩデータを暗号化解除することなく、受信されたＰＨＩデータを要求側プロセッサベースのクライアントデバイスに送信することを含んでよい。
【0382】
分析サービスプロバイダ（ＡＳＰ）システムと保護された健康情報（ＰＨＩ）システムとを含む医療分析プラットフォームを動作させるプロセス２９００は、プロセッサベースのクライアントデバイスの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワークを介してＰＨＩデータをＡＳＰシステムから受信することと、プロセッサベースのクライアントデバイスの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワークを介して、識別不能化された医療スタディデータをＡＳＰシステムから受信することと、プロセッサベースのクライアントデバイスの少なくとも１つのプロセッサによって、ＰＨＩデータと識別不能化された医療スタディデータをマージして、識別再可能化された医療スタディデータを生成することと、プロセッサベースのクライアントデバイスの少なくとも１つのプロセッサによって、識別再可能化された医療スタディデータをプロセッサベースのクライアントデバイスのユーザに提示することとをさらに含んでよい。
【0383】
分析サービスプロバイダ（ＡＳＰ）システムと保護された健康情報（ＰＨＩ）システムとを含む医療分析プラットフォームを動作させるプロセス２９００は、ＰＨＩシステムの少なくとも１つのプロセッサによって、ＰＨＩデータを含む医療スタディデータを受信することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、ＰＨＩデータを医療スタディデータから除去して、識別不能化された医療スタディデータを生成することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、ＰＨＩデータをＰＨＩシステムの少なくとも１つの非一時的なプロセッサ可読記憶媒体に記憶することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、識別不能化された医療スタディデータを、少なくとも１つの通信ネットワークを介してＡＳＰシステムに送信することとをさらに含んでよい。
【0384】
ＰＨＩデータを含む医療スタディデータを受信することは、医療イメージングデータをスキャナから受信することを含んでよい。医療スタディデータからＰＨＩデータを除去することは、ＰＨＩシステムの少なくとも１つのプロセッサによって、削除されることが可能にされたフィールドを除去することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、削除されることが不可能にされたフィールド内のデータを、難読化された置換データで置き換えることとを含んでよい。
【0385】
分析サービスプロバイダ（ＡＳＰ）システムと保護された健康情報（ＰＨＩ）システムとを含む医療分析プラットフォームを動作させるプロセス２９００は、ＰＨＩシステムの少なくとも１つのプロセッサによって、一意識別子を医療スタディのための医療スタディデータと関連付けることと、ＰＨＩシステムの少なくとも１つのプロセッサによって、一意識別子をＰＨＩシステムの少なくとも１つの非一時的なプロセッサ可読記憶媒体に記憶することと、ＰＨＩシステムの少なくとも１つのプロセッサによって、医療スタディについての識別不能化された医療スタディデータと共に、一意識別子を、少なくとも１つの通信ネットワークを介してＡＳＰシステムに送信することとをさらに含んでよい。
【0386】
分析サービスプロバイダ（ＡＳＰ）システムと保護された健康情報（ＰＨＩ）システムとを含む医療分析プラットフォームを動作させるプロセス２９００は、ＡＳＰシステムの少なくとも１つのプロセッサによって、識別不能化された医療スタディデータに関連する分析データを生成することと、ＡＳＰシステムの少なくとも１つのプロセッサによって、生成された分析データを、少なくとも１つの通信ネットワークを介してＰＨＩシステムに送信することとをさらに含んでよい。
【0387】
図３０は、例示される一実施形態に従った、ＰＨＩにアクセスするように、医療分析プラットフォームのＡＳＰシステムを動作させるプロセス３０００を例示する、フロー図である。医療分析プラットフォームは、図５に示される医療分析プラットフォーム５００のすべてまたは一部を備えてよい。例えば、医療分析プラットフォームは、分析サービスプロバイダ（ＡＳＰ）システムと、保護された健康情報（ＰＨＩ）システムとを備えてよい。様々な実施形態では、ＡＳＰシステムは、図５に示されるＡＳＰネットワーク５０２および／またはＡＳＰシステム５０４のすべてまたは一部を備えてよい。様々な実施形態では、ＰＨＩシステムは、図５に示されるＰＨＩシステム５１０のすべてまたは一部を備えてよい。ＰＨＩシステムは、識別不能化された医療スタディデータと関連付けられたＰＨＩデータをＰＨＩシステムの少なくとも１つの非一時的なプロセッサ可読記憶媒体上に記憶し得る。
【0388】
３００２では、ＡＳＰシステムの少なくとも１つのプロセッサが、識別不能化された医療スタディデータを、ＡＳＰシステムの少なくとも１つの非一時的なプロセッサ可読記憶媒体上に記憶する。
【0389】
３００４では、ＡＳＰシステムの少なくとも１つのプロセッサが、少なくとも１つの通信ネットワークを介してプロセッサベースのクライアントデバイスから医療スタディを求める要求を受信する。
【0390】
３００６では、ＡＳＰシステムの少なくとも１つのプロセッサが、プロセッサベースのクライアントデバイスから受信された医療スタディを求める要求を認証する。
【0391】
３００８では、ＡＳＰシステムの少なくとも１つのプロセッサが、要求された医療スタディと関連付けられたＰＨＩデータを、少なくとも１つの通信ネットワークを介してＰＨＩシステムに要求する。
【0392】
３０１０では、ＡＳＰシステムの少なくとも１つのプロセッサが、要求に応答して、ＰＨＩデータを、少なくとも１つの通信ネットワークを介してＰＨＩシステムから受信する。
【0393】
３０１２では、ＡＳＰシステムの少なくとも１つのプロセッサが、受信されたＰＨＩデータを、ＰＨＩデータの内容にアクセスすることなく、少なくとも１つの通信ネットワークを介して要求側プロセッサベースのクライアントデバイスに送信する。
【0394】
３０１４では、ＡＳＰシステムの少なくとも１つのプロセッサが、要求された医療スタディのための識別不能化された医療スタディデータを、少なくとも１つの通信ネットワーク上で、プロセッサベースのクライアントデバイスに送信する。
【0395】
識別不能化された医療スタディデータと関連付けられたＰＨＩデータをＰＨＩシステムの少なくとも１つの非一時的なプロセッサ可読記憶媒体上に記憶するＡＳＰシステムと、保護された健康情報（ＰＨＩ）システムであって、ＰＨＩシステムとを備える医療分析プラットフォームの分析サービスプロバイダ（ＡＳＰ）システムを動作させるプロセス３０００は、ＡＳＰシステムの少なくとも１つのプロセッサによって、識別不能化された医療スタディデータを、少なくとも１つの通信ネットワークを介してＰＨＩシステムから受信することをさらに含んでよい。
【0396】
識別不能化された医療スタディデータと関連付けられたＰＨＩデータをＰＨＩシステムの少なくとも１つの非一時的なプロセッサ可読記憶媒体上に記憶するＡＳＰシステムと、保護された健康情報（ＰＨＩ）システムであって、ＰＨＩシステムとを備える医療分析プラットフォームの分析サービスプロバイダ（ＡＳＰ）システムを動作させるプロセス３０００は、プロセッサベースのクライアントデバイスの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワークを介してＰＨＩデータをＡＳＰシステムから受信することと、プロセッサベースのクライアントデバイスの少なくとも１つのプロセッサによって、少なくとも１つの通信ネットワークを介して、識別不能化された医療スタディデータをＡＳＰシステムから受信することと、プロセッサベースのクライアントデバイスの少なくとも１つのプロセッサによって、ＰＨＩデータと識別不能化された医療スタディデータをマージして、識別再可能化された医療スタディデータを生成することと、プロセッサベースのクライアントデバイスの少なくとも１つのプロセッサによって、識別再可能化された医療スタディデータをプロセッサベースのクライアントデバイスのユーザに提示することとをさらに含んでよい。
【0397】
ＰＨＩシステムから要求された医療スタディと関連付けられたＰＨＩデータを要求することは、ＡＳＰシステムの少なくとも１つのプロセッサによって、要求された医療スタディと関連付けられたＰＨＩデータが利用可能になるまで未解決に保つ要求された医療スタディと関連付けられたＰＨＩデータのためのＨＴＴＰＳロングポーリング要求をＰＨＩシステムのサーバに送信することを含んでよい。ＰＨＩデータをＰＨＩシステムから受信することは、ＰＨＩシステムのサーバに送信されたＨＴＴＰＳロングポーリング要求に応答してよい。
【0398】
ＰＨＩシステムからＰＨＩデータを受信したことに応答して、ＡＳＰシステムの少なくとも１つのプロセッサは、少なくとも１つの通信ネットワーク上で、新しいＰＨＩデータがＰＨＩシステムから利用可能になるまで未解決に保つことになるＰＨＩシステムからの新しいＰＨＩデータに関する別のＨＴＴＰＳロングポーリング要求を、ＰＨＩシステムに即時に送信してよい。
【0399】
図２９および図３０に関連して説明された上記のプロセスは、ユーザが、医療サービスプロバイダ（例えば、病院）の仮想プライベートネットワークまたはＷｉＦｉネットワークへの接続を必要とせずにＰＨＩにアクセスすることを可能にすることによって、コンピュータネットワークを介した医療画像および分析の技術の効率および柔軟性を向上させる。そのような改善点は、コンピュータネットワーク技術に根ざしている。
【0400】
ＤＩＣＯＭスタディは、経時的に部分的に送信可能であり、より最近のファイルは、以前のアップロード（例えば、図５に示されるＭＲＩ獲得システム５１４からＰＨＩシステム５１０へのアップロード）以降に変化したＤＩＣＯＭメタデータを含む。例えば、ＤＩＣＯＭスタディは、更新された患者年齢、または追加のシリーズが含まれた状態で再アップロードされることがある。一実施形態は、ＤＩＣＯＭ一意識別子（ＵＩＤＳ）を、難読化されたバージョンで置き換えることによって、各入ってくるアップロードを異なるスタディとして取り扱う。図３１と図３２と本明細書における関連付けられた説明とを含む以下の説明は、どの時系列でスタディの部分が受信されるかに関係なく「同じスタディ」が同じ手段で難読化されることを保証するプロセスを開示する。
【0401】
例えば、修正された非識別子ユーティリティ（例えば、ＧＤＣＭプロジェクトからの修正されたｇｄｃｍａｎｏｎユーティリティ）が使用されてよい。具体的には、ｇｄｃｍａｎｏｎは、世界的な一意識別子（ＵＵＩＤ）由来ＵＩＤ生成スキーム（その全体が参照により本明細書に組み込まれる非特許文献２において定義される）を使用するように修正されてよい。具体的には、新しいＯｂｆｕｓｃａｔｅｄＵＩＤは、元のＵＩＤを得て、それをｏｉｄ名前空間によって修正し、ＳＨＡ－１ハッシュを適用することによって、作成されてよい。この関数は、全射である。
【0402】
上記で参照されたように、ＤＩＣＯＭメタデータは、経時的に効果的に変更可能であるので、記憶サブシステム（例えば、図５のＰＨＩシステム５１０の）は、元のＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤを参照する各新しいアップロードに対して別々にメタデータを記憶するように修正されてよい。
【0403】
一例として、スタディが、ＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤ ｛ａｌｐｈａ｝と共に入ってくる（例えば、図５のＰＨＩシステム５１０にアップロードされる）［アップロードＡ］。｛ａｌｐｈａ｝は、各ＤＩＣＯＭファイル内で、上記で説明されたように、修正された非識別子ユーティリティを使用して、ＯｂｆｕｓｃａｔｅｄＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤで置き換えられる。ＰＨＩデータが抽出され、ローカルデータベース（例えば、図５のＰＨＩシステム５１０のローカルデータベース）に記憶され、ＯｂｆｕｓｃａｔｅｄＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤを元のＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤにマップする。
【0404】
ある後の時点で、ＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤ ｛ａｌｐｈａ｝をもつ追加のスタディデータが入ってくる［アップロードＢ］（例えば、図５のＰＨＩシステム５１０にアップロードされる）。上記で説明された修正された非識別子ユーティリティによって実装される非識別子関数の性質により、｛ａｌｐｈａ｝は、次いで｛ａｌｐｈａ｝のすべてのインスタンスを置き換えるために使用される同じＯｂｆｕｓｃａｔｅｄＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤにマップされる。
【0405】
ＰＨＩデータは、第２のアップロードに対して同じ手段で抽出されてよいが、抽出されたＰＨＩデータは、次いで、アップロード識別子と一緒にＰＨＩシステム（例えば、図５のＰＨＩシステム５１０）によって記憶される。ＰＨＩデータがＰＨＩサービスから（例えば、図５のＰＨＩシステム５１０から）要求されたとき、返される応答は、最新のアップロードを含めてそれまで変更および追加をＰＨＩに適用することによって生成される。
【0406】
上記の例では、返される応答は、以下のように算出される。
ＰＨＩ＝ｅｘｔｒａｃｔ＿ｐｈｉ＿ｆｒｏｍ［アップロードＡ］
ＰＨＩ＝ｍｅｒｇｅ（ＰＨＩ，ｅｘｔｒａｃｔ＿ｐｈｉ＿ｆｒｏｍ［アップロードＢ］）
ＰＨＩ＝ｅｘｔｒａｃｔ＿ｐｈｉ＿ｆｒｏｍ［アップロードＡ］
ＰＨＩ＝ｍｅｒｇｅ（ＰＨＩ，ｅｘｔｒａｃｔ＿ｐｈｉ＿ｆｒｏｍ［アップロードＢ］）
【0407】
ｍｅｒｇｅ関数は、［アップロードＢ］から抽出されたＰＨＩが［アップロードＡ］からアップロードされたＰＨＩに優先するように設計される。これは、Ｎアップロードシナリオに一般化されてよい。任意の［アップロードＸ］に対するマージされたＰＨＩが問い合わせされ得るように、追加のＡＰＩが提供されてよい。
【0408】
図３１は、上記に関する一実施形態に従った、組織と関連付けられたプロセッサベースのシステムを、ＰＨＩデータを記憶するように動作させるプロセス３１００を例示する、フロー図である。例えば、プロセス３１００は、図５に示される医療分析プラットフォーム５００のすべてまたは一部を備えてよい医療分析プラットフォームの１つまたは複数のプロセッサによって実行されてよい。例えば、医療分析プラットフォームは、分析サービスプロバイダ（ＡＳＰ）システムと、保護された健康情報（ＰＨＩ）システムとを備えてよい。様々な実施形態では、ＡＳＰシステムは、図５に示されるＡＳＰネットワーク５０２および／またはＡＳＰシステム５０４のすべてまたは一部を備えてよい。様々な実施形態では、ＰＨＩシステムは、図５に示されるＰＨＩシステム５１０のすべてまたは一部を備えてよい。ＰＨＩシステムは、識別不能化された医療スタディデータと関連付けられたＰＨＩデータをＰＨＩシステムの少なくとも１つの非一時的なプロセッサ可読記憶媒体上に記憶し得る。一実施形態では、プロセス３１００は、図５に示されるＰＨＩシステム５１０の１つまたは複数のプロセッサによって実行されてよい。
【0409】
３１０２では、少なくとも１つのプロセッサが、ＤＩＣＯＭスタディを一意に識別するＤＩＣＯＭスタディの部分から、スタディインスタンス一意識別子を取得する。
【0410】
３１０４では、少なくとも１つのプロセッサが、スタディインスタンス一意識別子に基づいてハッシュを生成する。
【0411】
３１０６では、少なくとも１つのプロセッサが、生成されたハッシュに基づいて、難読化されたスタディインスタンス一意識別子を生成する。
【0412】
３１０８では、少なくとも１つのプロセッサが、少なくとも、ＤＩＣＯＭスタディの部分内のスタディインスタンス一意識別子を、難読化されたスタディインスタンス一意識別子で置き換えることによって、ＤＩＣＯＭスタディの部分を識別不能化する。
【0413】
３１１０では、少なくとも１つのプロセッサが、保護された健康情報（ＰＨＩ）をＤＩＣＯＭスタディの部分から抽出する。
【0414】
３１１２では、少なくとも１つのプロセッサが、ＤＩＣＯＭスタディの部分から抽出されたＰＨＩを記憶する。
【0415】
３１１４では、少なくとも１つのプロセッサが、スタディインスタンス一意識別子と、難読化されたスタディインスタンス一意識別子と、ＤＩＣＯＭスタディの部分との間の少なくとも１つの関連付けを記憶する。
【0416】
３１１６では、ＤＩＣＯＭスタディの追加の部分が受信されたかどうか、少なくとも１つのプロセッサによって決定がなされる。例えば、これは、更新されたＤＩＣＯＭメタデータまたは追加のＤＩＣＯＭメタデータを含んでよい。ＤＩＣＯＭスタディの追加の部分が受信されたことが決定された場合、プロセスは３１０２に進み、ＤＩＣＯＭスタディの追加の部分に対して動作を繰り返す。ＤＩＣＯＭスタディの追加の部分が受信されていないことが決定された場合、プロセスは３１１８における終了に進み、したがって、プロセス３１００により、ＤＩＣＯＭスタディの各追加の部分が受信されると、ＰＨＩが、そのスタディに対して記憶される。
【0417】
図３２は、例示される一実施形態に従った、組織と関連付けられたプロセッサベースのシステムを、マージされたＰＨＩデータを提供するように動作させるプロセス３２００を例示する、フロー図である。一実施形態では、プロセス３２００は、プロセス３１００により記憶されたＰＨＩにアクセスするために使用されてよい。プロセス３２００は、プロセス３１００に関連して使用されてもよいし、その一部として使用されてもよい。例えば、プロセス３１００は、図５に示される医療分析プラットフォーム５００のすべてまたは一部を備えてよい医療分析プラットフォームの１つまたは複数のプロセッサによって実行されてよい。医療分析プラットフォームは、分析サービスプロバイダ（ＡＳＰ）システムと、保護された健康情報（ＰＨＩ）システムとを備えてよい。様々な実施形態では、ＡＳＰシステムは、図５に示されるＡＳＰネットワーク５０２および／またはＡＳＰシステム５０４のすべてまたは一部を備えてよい。様々な実施形態では、ＰＨＩシステムは、図５に示されるＰＨＩシステム５１０のすべてまたは一部を備えてよい。ＰＨＩシステムは、識別不能化された医療スタディデータと関連付けられたＰＨＩデータをＰＨＩシステムの少なくとも１つの非一時的なプロセッサ可読記憶媒体上に記憶し得る。一実施形態では、プロセス３１００は、図５に示されるＰＨＩシステム５１０の１つまたは複数のプロセッサによって実行されてよい。
【0418】
３２０２では、少なくとも１つのプロセッサが、プロセス３１００の難読化されたスタディインスタンス一意識別子と関連付けられたＰＨＩを求める要求を受信する。
【0419】
３２０４では、ＰＨＩデータを求める要求に応答して、少なくとも１つのプロセッサが、ＤＩＣＯＭスタディを、難読化されたスタディインスタンス一意識別子と関連付けられていると識別する。
【0420】
３２０６では、少なくとも１つのプロセッサが、スタディインスタンス一意識別子と、難読化されたスタディインスタンス一意識別子と、ＤＩＣＯＭスタディの部分との間の少なくとも１つの関連付けに基づいて、ＤＩＣＯＭスタディの部分と関連付けられた記憶されたＰＨＩを識別する。
【0421】
３２０８では、少なくとも１つのプロセッサが、記憶されてＤＩＣＯＭスタディの部分と関連付けられたＰＨＩを抽出する。
【0422】
３２１０では、少なくとも１つのプロセッサが、抽出されたＰＨＩを、ＤＩＣＯＭスタディの複数の部分のうちの他の部分と関連付けられた以前に抽出されたＰＨＩとマージする。
【0423】
３２１４では、例えば、図５のＰＨＩシステム５１０内などで、ＤＩＳＣＯＭスタディの追加の部分が追加され、処理に利用可能であるかどうか、少なくとも１つのプロセッサによって決定がなされる。ＤＩＳＣＯＭスタディの追加の部分が記憶されたことが決定された場合、プロセス３２００は３２０６に進んで、その追加の部分を処理する。これは、記憶されて処理に利用可能な部分が残っていなくなるまで、ＤＩＣＯＭスタディのすべての部分がマージされることをもたらす。ＤＩＳＣＯＭスタディの追加の部分が記憶されていないことが決定された場合、プロセスは３２１２に進む。
【0424】
３２１２では、少なくとも１つのプロセッサが、ＤＩＣＯＭスタディに関してマージされたＰＨＩを提供する。例えば、これは、ＤＩＣＯＭスタディデータを要求した、図５に示されるプロセッサベースのクライアントデバイス５２０に提供されてよい。
【0425】
組織と関連付けられたプロセッサベースのシステムを動作させるプロセス３２００は、少なくとも１つのプロセッサによって、ＤＩＣＯＭスタディの複数の部分の各部分を別個のアップロードとして、異なる時間に受信することをさらに含んでよい。
【0426】
抽出されたＰＨＩを、ＤＩＣＯＭスタディの複数の部分のうちの他の部分と関連付けられた以前に抽出されたＰＨＩとマージすることは、ＤＩＣＯＭスタディの複数の部分のうちの各部分がいつアップロードされたかという時系列を決定することと、ＤＩＣＯＭスタディに関してマージされたＰＨＩ内で、少なくとも１つのプロセッサによって、以前に抽出されたＰＨＩよりも、対応するその後アップロードされたＰＨＩを優先することを含んでよい。
【0427】
組織と関連付けられたプロセッサベースのシステムを動作させるプロセス３２００は、少なくとも１つのプロセッサによって、ＤＩＣＯＭスタディの複数の部分のうちの一部分を識別する問い合わせを受信することであって、この問い合わせは、ＤＩＣＯＭスタディの複数の部分のうちの識別された一部分を検索するためのパラメータを含む、受信することと、この問い合わせに応答して、少なくとも１つのプロセッサによって、パラメータに基づいてＤＩＣＯＭスタディの複数の部分のうちの識別された一部分と関連付けられたＰＨＩを検索することと、少なくとも１つのプロセッサによって、パラメータに基づいてＤＩＣＯＭスタディの複数の部分のうちの識別された一部分と関連付けられたＰＨＩを提供することとをさらに含んでよい。
【0428】
ＤＩＣＯＭスタディの複数の部分のうちの少なくとも１つの部分は、ＤＩＣＯＭメタデータを含むことがあり、ＤＩＣＯＭスタディの複数の部分のうちの少なくとも別の部分は、同じＤＩＣＯＭメタデータに対する更新を含むことがある。ＤＩＣＯＭスタディの複数の部分のうちの少なくとも１つの部分は、ＤＩＣＯＭメタデータを含むことがあり、ＤＩＣＯＭスタディの複数の部分のうちの少なくとも別の部分は、ＤＩＣＯＭスタディのためのＤＩＣＯＭメタデータに対する追加を含むことがある。ＤＩＣＯＭスタディの複数の部分のうちの少なくとも１つの部分は、ＤＩＣＯＭメタデータを含むことがあり、ＤＩＣＯＭスタディの複数の部分のうちの少なくとも別の部分は、ＤＩＣＯＭスタディのためのＤＩＣＯＭメタデータに対する追加を含むことがある。ＤＩＣＯＭスタディの複数の部分のうちの少なくとも１つの部分は、ＤＩＣＯＭスタディと関連付けられた患者年齢を含むことがあり、ＤＩＣＯＭスタディの複数の部分のうちの少なくとも別の部分は、ＤＩＣＯＭスタディと関連付けられた患者年齢に対する更新を含むことがある。ＤＩＣＯＭスタディの複数の部分のうちの少なくとも１つの部分は、ＤＩＣＯＭスタディに関するシリーズレベルデータを含むことがあり、ＤＩＣＯＭスタディの複数の部分のうちの少なくとも別の部分は、ＤＩＣＯＭスタディに関する追加のシリーズレベルデータを含むことがある。
【0429】
図３１および図３２に関連して説明された上記のプロセスは、ＤＩＣＯＭスタディデータを経時的に受け入れ、どのＰＨＩデータが変化したかを、それが受信された時系列に関係なく追跡する／取り出すために、ＰＨＩサービス内の一意識別子を相関付けることによって、コンピュータネットワーク上での医療画像および分析の技術のスピード、効率、および柔軟性を向上させる。
【0430】
前述の詳細な説明は、ブロック図、概略図、および例の使用を介して、デバイスおよび／またはプロセスの様々な実装形態を記載してきた。そのようなブロック図、概略図、および例が１つまたは複数の機能および／または動作を含む限り、そのようなブロック図、フローチャート、または例における各機能および／または動作が、広範囲のハードウェア、ソフトウェア、ファームウェア、またはそれらの事実上あらゆる組み合わせによって、個別におよび／または集合的に実装され得ることは、当業者によって理解されよう。一実装形態では、本主題は、特定用途向け集積回路（ＡＳＩＣ）を介して実装され得る。しかしながら、当業者は、本明細書において開示される実装形態が、１つもしくは複数のコンピュータ上で走る１つもしくは複数のコンピュータプログラムとして、（例えば、１つもしくは複数のコンピュータシステム上で走る１つもしくは複数のプログラムとして）、１つもしくは複数のコントローラ（例えば、マイクロコントローラ）上で走る１つもしくは複数のプログラムとして、１つもしくは複数のプロセッサ（例えば、マイクロプロセッサ）上で走る１つもしくは複数のプログラムとして、ファームウェアとして、またはそれらの事実上あらゆる組み合わせとして、全体的にまたは部分的に、標準的な集積回路内で同等に実装され得ること、ならびに、回路を設計することおよび／またはソフトウェアおよび／もしくはファームウェアのためのコードを記述することが、本開示を考慮すると十分に当業者の技術の範囲内であることを認識するであろう。
【0431】
当業者は、本明細書において記載された方法またはアルゴリズムの多くが、追加の行為を用いてもよく、いくつかの行為を省略してもよく、および／または指定されたものとは異なる順序で行為を実行してもよいことを認識するであろう。
【0432】
加えて、当業者は、本明細書において教示される機構は、様々な形でプログラム製品として配布されることが可能であること、ならびに、例示的な実装形態が、配布を実際に行うために使用される特定のタイプの信号担持媒体に関係なく等しく適用することを諒解するであろう。信号担持媒体の例は、限定するものではないが、フロッピディスク、ハードディスクドライブ、ＣＤ ＲＯＭ、デジタルテープ、およびコンピュータメモリなどの記録可能タイプ媒体を含む。
【0433】
上記で説明された様々な実装形態は、さらなる実装形態を提供するために組み合わせ可能である。それらが本明細書における特定の教示および定義と矛盾しない限り、限定するものではないが、本明細書において参照されおよび／または出願データシートにおいて列挙される、２０１１年７月７日に出願された特許文献１、２０１６年１２月６日に発行された特許文献２、２０１２年７月５日に出願された特許文献３、２０１６年１１月２９日に出願された特許文献４、２０１４年１月１７日に出願された特許文献５、２０１６年７月１５日に出願された特許文献６、２０１５年１月１６日に出願された特許文献７、および２０１５年１１月２０日に出願された特許文献８、２０１６年１０月３１日に出願された特許文献９、２０１６年１１月２９日に出願された特許文献１０、２０１６年１１月２９日に出願された特許文献１１、２０１６年１１月１日に出願された特許文献１２、２０１６年１１月２９日に出願された特許文献１３、２０１７年１月２７日に出願された特許文献１４、２０１７年５月４日に出願された特許文献１５、２０１７年５月３０日に出願された特許文献１６、２０１７年１１月２２日に出願された特許文献１７、２０１７年１１月２２日に出願された特許文献１８、２０１７年１１月２２日に出願された特許文献１９、２０１７年１１月２２日に出願された特許文献２０、２０１７年１１月２２日に出願された特許文献２１、２０１７年１１月２２日に出願された特許文献２２、２０１７年１１月２２日に出願された特許文献２３、２０１７年１１月２７日に出願された特許文献２４を含む、米国特許、米国特許出願公開、米国特許出願、外国特許、外国特許出願、および非特許刊行物のすべては、その全体が参照により本明細書に組み込まれる。実装形態の態様は、必要に応じて、様々な特許、出願、および刊行物のシステム、回路、および概念を用いて、さらに別の実装形態を提供するために、修正され得る。
【0434】
これらおよび他の変更は、上記の詳細な説明に照らして実装形態に対して行われてよい。一般に、以下の特許請求の範囲では、使用される用語は、特許請求の範囲を、本明細書および特許請求の範囲に開示されている特定の実装形態に限定すると解釈されるべきでなく、そのような特許請求の範囲に権利が与えられる等価物の全範囲と共にすべての可能な実装形態を含むと解釈されるべきである。したがって、特許請求の範囲は、本開示によって限定されない。
【0435】
本出願は、２０１８年１１月２１日に出願された特許文献２５に対する優先権の利益を主張するものであり、この出願は、その全体が参照により本明細書に組み込まれる。
【図1】
【図2】
【図3A】
【図3B】
【図4A】
【図4B】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11A】
【図11B】
【図12】
【図13A】
【図13B】
【図14A】
【図14B】
【図15A】
【図15B】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
