(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-02-06
(54)【発明の名称】臨床エンドポイント判定システム及び方法
(51)【国際特許分類】
G16H 10/00 20180101AFI20240130BHJP
【ＦＩ】
G16H10/00
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023544548
(86)(22)【出願日】2022-01-25
(85)【翻訳文提出日】2023-07-24
(86)【国際出願番号】 EP2022051564
(87)【国際公開番号】W WO2022161925
(87)【国際公開日】2022-08-04
(31)【優先権主張番号】63/141,554
(32)【優先日】2021-01-26
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＰＹＴＨＯＮ
２．ＴＲＩＮＥＴＸ
(71)【出願人】
【識別番号】391008951
【氏名又は名称】アストラゼネカ・アクチエボラーグ
【氏名又は名称原語表記】ＡＳＴＲＡＺＥＮＥＣＡ ＡＫＴＩＥＢＯＬＡＧ
(74)【代理人】
【識別番号】100106518
【弁理士】
【氏名又は名称】松谷 道子
(74)【代理人】
【識別番号】100135703
【弁理士】
【氏名又は名称】岡部 英隆
(72)【発明者】
【氏名】カーン，ファイサル
(72)【発明者】
【氏名】ビョルク，エリーサベト
(72)【発明者】
【氏名】アンデション，トーマス
(72)【発明者】
【氏名】ペルション，アナス
(72)【発明者】
【氏名】デュラン，クリスティーナ
(72)【発明者】
【氏名】デニス，グリン
(72)【発明者】
【氏名】カダー，シャミーア
(72)【発明者】
【氏名】ハッチソン，エンメッテ
(72)【発明者】
【氏名】リー，ホールジー
(72)【発明者】
【氏名】ナンパリー，スリーナス
(72)【発明者】
【氏名】ヴァランデル，マーリン
(72)【発明者】
【氏名】ヤーレモ，アンドレアス
【テーマコード（参考）】
5L099
【Ｆターム（参考）】
5L099AA21
(57)【要約】
本開示は、効率的で自動的な臨床事象分類及び医療レビュートリアージを提供し、臨床事象を識別する時間を短縮し、臨床事象を分類する統一された一貫するプロセスを提供し、準リアルタイムで事象の事前識別を提供する、臨床エンドポイント判定を実行するに当たり使用されるシステム及び方法に関する。
【特許請求の範囲】
【請求項1】
臨床試験エンドポイント判定を実行するコンピュータ実施方法であって、計算システムにおいて、複数のヘルスケア関連データソースからデータを受信することと、
前記データが非構造化データを含む場合、自然言語処理モデルを前記非構造化データに適用して、前記非構造化データにおける特徴に関連する埋め込みを取得することと、
前記データが構造化データを含む場合、そのデータから特徴を抽出することと、
前記非構造化データからの前記埋め込み及び前記構造化データから抽出された前記特徴に機械学習分類モデルを適用して、前記埋め込み及び前記構造化データから抽出された前記特徴に基づいてヘルスケア事象が発生したか否かを分類することと、
確率スコアを属性として前記分類に付与することであって、前記確率スコアは前記事象が発生した尤度の指示を提供する、付与することと、
前記確率スコアが選択された閾値未満である場合、分類を審査する通知をユーザに提供することと、
を含むコンピュータ実施方法。
【請求項2】
自然言語処理モデルを適用することは、前記データソースから利用可能なテキストでトレーニングされた第１の専用モデルを第２の汎用モデルと共に含む複数の自然言語処理モデルを適用することを含む、請求項１に記載のコンピュータ実施方法。
【請求項3】
前記データが非構造化データを含む場合、名前付きエンティティ認識モデルを前記非構造化データに適用して、前記非構造化データから正式事象特性を取得することと、前記名前付きエンティティ認識モデルを介して取得された前記正式事象特性に前記機械学習分類モデルを適用することと、
を更に含む、請求項１又は２に記載のコンピュータ実施方法。
【請求項4】
（ｉ）前記データソース及び（ｉｉ）前記非構造化データに適用される光学文字認識プロセスに基づいて特定された信頼の少なくとも１つに基づいて、信頼スコアを属性として前記データに付与することと、前記機械学習分類モデルが重みとして前記信頼スコアを使用することと、
請求項１～３のいずれか１項に記載のコンピュータ実施方法。
【請求項5】
選択された閾値未満の信頼スコアを有するデータを除外することを更に含む、請求項４に記載のコンピュータ実施方法。
【請求項6】
前記データから特徴を抽出すること及び自然言語処理モデルを前記非構造化データに適用して、前記非構造化データにおける特徴に関連する埋め込みを取得することは、前記臨床エンドポイント判定で使用するために予め定義された１組の特徴を取得することと、前記抽出された特徴及び／又は埋め込みを前記予め定義された１組の特徴にマッピングすることと、前記予め定義された１組の特徴に関連しない特徴及び／又は埋め込みを破棄することとを含む、請求項１～５のいずれか１項に記載のコンピュータ実施方法。
【請求項7】
前記機械学習分類モデルは、ヘルスケア事象が発生したか否かの分類に関わる前記特徴の重要度のランク付けを提供する、請求項１～６のいずれか１項に記載のコンピュータ実施方法。
【請求項8】
特徴の前記重要度のランク付けを提供することは、各特徴のＳＨＡＰ値を特定することを含む、請求項７に記載のコンピュータ実施方法。
【請求項9】
特徴の前記重要度のランク付けを提供することは、ローカルサロゲートモデルを前記機械学習分類モデルに適用して、前記分類への各特徴の相対寄与を特定することを含む、請求項７又は８に記載のコンピュータ実施方法。
【請求項10】
前記方法は、利用可能なデータ量が選択された閾値を超える場合、実行される、請求項１～９のいずれか１項に記載のコンピュータ実施方法。
【請求項11】
前記方法は、事象発生指示がユーザにより提供されることに応答して実行される、請求項１～１０のいずれか１項に記載のコンピュータ実施方法。
【請求項12】
臨床試験エンドポイント判定を実行するように機械学習分類モデルをトレーニングする方法であって、計算システムにおいて、複数のヘルスケア関連データソースからデータを受信することであって、前記データは、前回の臨床試験からの判定書類及びそれらの判定書類に関連する判定決定を含む、受信することと、
各データソースを解析して、前記データソースにより保持されるデータが構造化データ及び／又は非構造化データを含むかを判断することと、
前記データが非構造化データを含む場合、自然言語処理モデルを前記非構造化データに適用して、前記非構造化データにおける特徴に関連する埋め込みを取得することと、
前記データが構造化データを含む場合、そのデータから特徴を抽出することと、
前記判定書類からの前記データに基づいて前記判定決定の指示を提供することと、
前記判定決定及び前記判定書類からのデータに基づいて、前記機械学習分類モデルを更新することと、
前記更新された機械学習分類モデルを関係データベースに記憶することと、
を含む方法。
【請求項13】
臨床試験エンドポイント判定をモニタする方法であって、計算システムにおいて、臨床試験エンドポイント判定システムから判定決定の複数の通知を受信することであって、前記判定決定は、事象が発生した尤度の指示を提供する確率スコアを含む、受信することと、
（ｉ）前記確率スコア及び（ｉｉ）前記事象の深刻度の少なくとも一方に基づいて前記通知をランク付けることと、
前記判定の実行に使用されるデータの書類を取得することと、
判定決定のリスト及びデータの対応する書類をユーザに提供して、前記判定決定の正確さを審査することであって、前記リストの順序は前記ランク付けに基づく、審査することと、
を含む方法。
【請求項14】
ヘルスケア事象が発生したか否かの分類に関わる特徴の重要度のランク付けを取得することと、前記特徴の前記重要度の前記ランク付けを前記判定決定のリスト及び前記データの対応する書類と共に前記ユーザに提供することと、
を更に含む、請求項１３に記載の方法。
【請求項15】
臨床試験エンドポイント判定のために複数のヘルスケア関連ソースからのデータを調和させ校合するコンピュータ実施方法であって、計算システムにおいて、各データソースを解析して、前記データソースにより保持されるデータが構造化データ及び／又は非構造化データを含むかを判断することと、
前記データが非構造化データを含む場合、まだ機械可読形式ではない前記データの１つ又は複数の領域に対して光学文字認識を実行することと、
（ｉ）前記データソース及び（ｉｉ）前記光学文字認識プロセスに基づいて特定された信頼の少なくとも一方に基づいて、信頼スコアを属性として前記データに付与することと、
特徴解析を前記データに対して実行して、前記データから特徴を抽出することと、
前記抽出された特徴を予め定義された１組の特徴にマッピングすることと、
前記臨床試験エンドポイント判定を実行するに当たり機械学習モデルにより使用するためにｊｓｏｎ形式で前記抽出されマッピングされた特徴を公開することであって、前記信頼スコアは前記特徴の属性である、公開することと、
を含むコンピュータ実施方法。
【請求項16】
前記信頼スコアが選択された信頼閾値を超える場合前記抽出されマッピングされた特徴をｊｓｏｎ形式で公開することを更に含む、請求項１５に記載の方法。
【請求項17】
臨床試験エンドポイント判定に必要な１組の特徴を取得することであって、前記必要な１組の特徴は前記エンドポイントに基づく、取得することと、前記複数のデータソースから取得された前記特徴を臨床試験エンドポイント判定に必要な前記１組の特徴と比較して、任意の特徴が欠損又は不完全であるか否かを判断することと、
任意の特徴が欠損又は不完全であると判断される場合、特徴が欠損していることの通知をユーザに提供することであって、前記通知は前記欠損又は不完全な特徴の指示を提供する、提供することと、
を更に含む、請求項１５又は請求項１６に記載の方法。
【請求項18】
前記データに対して特徴解析を実行する前、前記データに対して名前付きエンティティ認識を実行することと、前記予め定義された１組の特徴に関連する正式事象特性を選択することとを更に含む、請求項１～１７のいずれか１項に記載の方法。
【請求項19】
データソースにより提供すべき１組の特徴を取得することと、そのデータソースで任意の特徴が欠損しているか否かを判断することと、そのデータソースで特徴が欠損している場合、特徴が欠損していることの通知をユーザに提供することとを更に含む、請求項１～１８のいずれか１項に記載の方法。
【請求項20】
特徴解析を前記データに対して実行して、前記データから特徴を抽出することは、任意の重複した特徴、一貫しない特徴、又は不適当な特徴をチェックし除去することを更に含む、請求項１～１９のいずれか１項に記載の方法。
【請求項21】
臨床試験の参加者にヘルスケア事象が発生したか否かを判断するモニタリングシステムであって、複数のソースから複数の参加者に関連するデータ信号を受信するように構成された通信インタフェースであって、前記データ信号は各々、参加者と関連するパラメータを示す情報を含む、通信インタフェースと、
プロセッサと、
を備え、
各参加者について、前記プロセッサは、各受信データ信号を処理し、前記データ信号の前記ソースに基づいて各データ信号に第１の重みを適用するように構成され、
前記プロセッサは、（ｉ）患者と関連するパラメータがその患者に選択された閾値を超えることを示す前記データ信号及び（ｉｉ）前記第１の重みが選択されたトリガー閾値を超えることの少なくとも１つに基づいて、ヘルスケア事象発生確率を特定するように構成される、システム。
【請求項22】
前記プロセッサは、前記特定された確率が選択された閾値を超えることに基づいてヘルスケア事象が発生したと判断するように構成され、ヘルスケア事象が発生したと前記プロセッサが判断する場合、前記プロセッサは、通知を前記モニタリングシステムのユーザに提供するように構成され、前記モニタリングシステムは、前記ヘルスケア事象発生の前記特定された確率に基づいて前記通知をランク付けるように構成される、請求項１１に記載のシステム。
【請求項23】
前記プロセッサは、前記データ信号の前記ソース及び前記参加者と関連する前記パラメータの前記指示に基づいて、ヘルスケア事象のタイプを決定するように構成される、請求項２１又は２２に記載のシステム。
【請求項24】
前記モニタリングシステムは、ヘルスケア事象の前記決定されたタイプに基づいて前記通知をランク付けるように構成される、請求項２３に記載のシステム。
【請求項25】
前記モニタリングシステムは、前記参加者の既知の健康に基づいて前記通知をランク付けるように構成される、請求項２２、２３、又は２４に記載のシステム。
【請求項26】
前記プロセッサは、少なくとも１つのデータ信号が、（ｉ）患者と関連するパラメータが選択された閾値を超えること及び（ｉｉ）そのデータ信号の重みが選択された閾値を超えることの少なくとも一方を示す複数のデータ信号に基づいて、ヘルスケア事象発生の前記確率を特定するように構成される、請求項２１～２５のいずれか１項に記載のシステム。
【請求項27】
前記プロセッサが、パラメータが選択された閾値を超えることを示す受信データ信号に基づいて、ヘルスケア事象発生の前記確率を特定する場合、前記プロセッサは、前記特定に先行する選択された時間間隔で、前記参加者と関連するそのパラメータの前の値を示す情報を審査する、請求項２１～２６のいずれか１項に記載のシステム。
【請求項28】
事象が発生した前記確率が選択された閾値を超えると判断される場合、前記プロセッサは、前記患者からより多くの情報が必要であるか否かについて判断するように構成され、より多くの情報が必要な場合、前記患者と連絡をとる通知が前記ヘルスケア提供者／システム管理者に提供される、請求項２１～２７のいずれか１項に記載のシステム。
【請求項29】
前記プロセッサは、前記データ信号の信頼性を特定し、前記データ信号の前記信頼性に基づいて第２の重みを適用するようにも構成され、前記プロセッサは、患者と関連するパラメータが選択された閾値を超えることを示す前記データ信号並びに前記第１及び第２の重みに基づいて、ヘルスケア事象発生の前記確率を特定するように構成される、請求項２１～２８のいずれか１項に記載のシステム。
【請求項30】
前記プロセッサは、参加者の前に特定された任意の事象発生確率にも基づいて、その参加者のヘルスケア事象発生確率を特定するように構成される、請求項２１～２９のいずれか１項に記載のシステム。
【請求項31】
臨床試験の参加者でヘルスケア事象が発生したか否かを判断する方法であって、計算システムにおいて、複数のソースから複数の参加者に関連するデータ信号を受信することであって、前記データ信号は各々、参加者と関連するパラメータを示す情報を含む、受信することと、
各参加者について、受信された各データ信号を処理し、前記データ信号の前記ソースに基づいて各データ信号に第１の重みを適用することと、
ヘルスケア事象発生の確率を、（ｉ）患者と関連するパラメータがその参加者に選択された閾値を超えることを示す前記データ信号及び（ｉｉ）選択されたトリガー閾値を超える前記第１の重みの少なくとも一方に基づいて特定することと、
を含む方法。
【請求項32】
前記特定された確率が選択された閾値を超えることに基づいて、ヘルスケア事象が発生したと判断することと、ヘルスケア事象が発生したと判断される場合、通知をユーザに提供することとを含み、前記通知は、前記ヘルスケア事象発生の前記特定された確率に基づいてランク付けされる、請求項３１に記載の方法。
【請求項33】
前記データ信号の前記ソース及び前記参加者と関連する前記パラメータの前記指示に基づいて、ヘルスケア事象のタイプを決定することを含む、請求項３１に記載の方法。
【請求項34】
前記ヘルスケア事象の前記決定されたタイプに基づいて前記通知をランク付けることを含む、請求項３３に記載の方法。
【請求項35】
前記参加者の既知の健康に基づいて前記通知をランク付けることを含む、請求項３２に記載の方法。
【請求項36】
少なくとも１つのデータ信号は、（ｉ）患者と関連するパラメータが選択された閾値を超えること及び（ｉｉ）そのデータ信号の重みが選択された閾値を超えることの少なくとも一方を示す複数のデータ信号に基づいて、ヘルスケア事象発生の前記確率を特定することを含む、請求項３１に記載の方法。
【請求項37】
パラメータが選択された閾値を超えることを示す受信データ信号に基づいて、ヘルスケア事象発生の前記確率を特定することを含み、前記特定は、前記特定に先行する選択された時間間隔で前記参加者と関連するそのパラメータの前の値を示す情報に基づく、請求項３１に記載の方法。
【請求項38】
事象が発生した前記確率が選択された閾値を超えると判断される場合、前記プロセッサは、前記患者からより多くの情報が必要であるか否かについて判断するように構成され、より多くの情報が必要な場合、前記患者と連絡をとる通知が前記ヘルスケア提供者／システム管理者に提供される、請求項３１に記載の方法。
【請求項39】
前記データ信号の信頼性を特定することと、前記データ信号の前記信頼性に基づいて第２の重みを適用することとを含み、前記方法は、患者と関連するパラメータが選択された閾値を超えることを示す前記データ信号並びに前記第１及び第２の重みに基づいて、ヘルスケア事象発生の前記確率を特定することを含む、請求項３１に記載の方法。
【請求項40】
参加者の前に特定された任意の事象発生確率にも基づいて、その参加者のヘルスケア事象発生確率を特定することを含む、請求項３１～３９のいずれか１項に記載の方法。
【請求項41】
臨床試験の参加者でヘルスケア事象が発生したか否かを判断するモニタリングシステムであって、複数のソースから複数の参加者に関連するデータ信号を受信するように構成された通信インタフェースであって、前記データ信号は各々、参加者と関連する場所を示す情報を含む、通信インタフェースと、
プロセッサと、
を備え、
各参加者について、前記プロセッサは各受信データ信号を処理するように構成され、
前記プロセッサは、（ｉ）既知のヘルスケアセンターへの前記参加者の近接性及び（ｉｉ）前記既知のヘルスケアセンターへの前記参加者の近接性の持続時間に基づいて参加者のヘルスケア事象発生確率を特定するように構成され、
前記ヘルスケア事象発生確率が選択された閾値を超えると前記プロセッサが判断する場合、前記プロセッサは、ヘルスケア事象が発生したことの前記参加者からの確認を求める通知を前記参加者に送信するように構成される、モニタリングシステム。
【請求項42】
臨床試験の参加者でヘルスケア事象が発生したか否かを判断する方法であって、計算システムにおいて、複数のソースから複数の参加者に関連するデータ信号を受信することであって、前記データ信号は各々、参加者と関連する場所を示す情報を含む、受信することと、
各参加者について、受信された各データ信号を処理して、（ｉ）既知のヘルスケアセンターへの前記参加者の近接性及び（ｉｉ）前記既知のヘルスケアセンターへの前記参加者の近接性の持続時間に基づいて参加者のヘルスケア事象発生確率を特定することと、
前記ヘルスケア事象発生確率が選択された閾値を超えると判断される場合、ヘルスケア事象が発生したことの前記参加者からの確認を求める通知を前記参加者に送信することと、
を含む方法。
【請求項43】
プロセッサに請求項１に記載の方法を実行させるように構成されたコンピュータのプログラムを含むコンピュータ可読非一時的記憶媒体。
【請求項44】
プロセッサに請求項１２に記載の方法を実行させるように構成されたコンピュータのプログラムを含むコンピュータ可読非一時的記憶媒体。
【請求項45】
プロセッサに請求項１３に記載の方法を実行させるように構成されたコンピュータのプログラムを含むコンピュータ可読非一時的記憶媒体。
【請求項46】
プロセッサに請求項１５に記載の方法を実行させるように構成されたコンピュータのプログラムを含むコンピュータ可読非一時的記憶媒体。
【請求項47】
プロセッサに請求項３１に記載の方法を実行させるように構成されたコンピュータのプログラムを含むコンピュータ可読非一時的記憶媒体。
【請求項48】
プロセッサに請求項４２に記載の方法を実行させるように構成されたコンピュータのプログラムを含むコンピュータ可読非一時的記憶媒体。
【発明の詳細な説明】
【技術分野】
【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】
【図1】臨床エンドポイント判定の従来の手法の一例の概略的なプロセスフローチャートの一例を示す。
【図2】本開示の実施形態による臨床エンドポイント判定の手法の一例の概略的なプロセスフローチャートの一例を示す。
【図3】事象スニファ又はモニタリングシステム例の機能概略の一例を示す。
【図4】通知をユーザに提供し、例えば、ヘルスケア事象を受けたと判断することができるユーザから入力を取得するためにモバイルデバイスで実行中のアプリケーションの一連のスクリーンショットの一例を示す。
【図5】事象スニファモジュールの機能の概略的なプロセスフローチャートの一例を示す。
【図7】ヘルスケアデータの取得における異常が生じたか否かの判断の仕方についてのプロセスフローチャートの一例を示す。
【図9】異常又はヘルスケア事象が発生したか否かを判断する方法のプロセスフローチャートの一例を示す。
【図10】異常又はヘルスケア事象が発生したか否かを判断する方法のプロセスフローチャートの別の例を示す。
【図11】データ調和及び収集システムを備え得るモジュールの機能概略図の一例を示す。
【図12】非構造化データソースからのデータをいかにインポートし得るかについてのプロセスフローチャートの一例を示す。
【図13】ＴＨＥＭＩＳ、ＤＡＰＡ－ＨＦ、及びＤＥＬＩＶＥＲ臨床試験の各々で使用されるフィールド数並びに３つの試験のフィールドの重複割合を示す。
【図14】ユーザが、信頼度が低い領域を有すると判断されたドキュメントを手動で審査するためのプロセスフローチャートの一例を示す。
【図15】自動事象判定モジュールをデプロイする際に関わるステップの高レベルプロセスフローチャートの一例を示す。
【図16】臨床エンドポイント判定を実行するためのコンピュータ実施方法の一例のプロセスフローチャートの一例を示す。
【図17】上述した図１６の一例の方法を実行し、図１６の一例の方法を実行するように機械学習モデルをトレーニングするように動作可能なコンポーネント（例えば、例えばソフトウェア及び／又はハードウェアで実施し得るモジュール）及びコンポーネント間のデータフローを、各コンポーネントの機能の簡単な説明と共に高レベルで示す。
【図19A-9C】ＤＥＣＬＡＲＥ臨床試験からの８１７人の患者でトレーニングされた３つのアルゴリズム（ＣＶ死、非ＣＶ死、及び不確定）の結果を示す。
【図20A-20B】解釈可能性を提供するために、本開示の例で使用されるモデル又はアルゴリズムをいかに解析することができるかを示す。
【図21】一例のモードで使用される様々な特徴の相対ＳＨＡＰ値を示すグラフの一例を示す。
【図22】幾つかのメトリック（例えば、ＡＵＣ－曲線下面積、正解率、バランス正解率、Ｆ１等）及びモデルバージョン（最初の３列）にわたる機械学習モデル性能を示す。
【図23】３つの臨床試験からのデータに対して実行された幾つかのメトリック（例えば、ＡＵＣ－曲線下面積、正解率、バランス正解率、Ｆ１等）にわたる機械学習モデル性能を示す。
【図24】本開示の１つ又は複数の実施形態の実施に適したコンピュータシステムの機能概略ブロック図を示す。
【発明を実施するための形態】
【0047】
臨床エンドポイント判定の従来の手法の一例を図１に示す。見られるように、臨床エンドポイント判定は、医療処置を必要とする健康事象（例えば心筋梗塞）が発生したとき、開始することができる。これにより、アラートがエンドポイントオフィス（ＥＰＯ）に送信され、その結果、データ収集（例えば、患者及び事象に繋がった状況、医療処置、実行された任意の試験等に関連する）及び医療審査が行われる。これが実行されると、判定が行われる。専門家チーム又は判定委員会が選任され、判定査定が実行される。これは、医療審査に同意することもあれば同意しないこともあり、必要な場合、判定アウトカムが決定される前、不同意解決が実行される。
【0048】
先に記したように、これは時間及びコストがかかるプロセスである。事象をエンドポイントオフィスに報告するに当たり遅延が生じ得、データを収集するに当たり更なる遅延が生じ得る。判定プロセスも、実行前に相当量の時間がかかり得、委員会にとって非常に時間がかかるプロセスである。さらに、非常に規模の大きな多数のセンター及び多数の国にわたる研究の場合、同じ判定チームを有することが常に可能である訳ではない。
【0049】
本発明は、これらの問題に対処する新規の解決策を割り出した。新規の解決策は、医療審査に送られる事象数を低減するとともに、アウトカム研究エンドポイントの大半に自動分類を提供しようとする。自動事象判定プロセスを実施することによりこれの実行をなんとかやり遂げた。
【0050】
自動事象判定は以下を提供し得る：
・効率的で自動化された臨床事象分類及び医療審査トリアージ、
・臨床事象を識別するための時間の短縮、
・ＴＡにわたり臨床事象を分類する統一され一貫したプロセス、及び
・事象の事前識別及び準リアルタイムでのＩｏＴエンドポイントＩＤのサポート。
・効率的で自動化された臨床事象分類及び医療審査トリアージ、
・臨床事象を識別するための時間の短縮、
・ＴＡにわたり臨床事象を分類する統一され一貫したプロセス、及び
・事象の事前識別及び準リアルタイムでのＩｏＴエンドポイントＩＤのサポート。
【0051】
自動事象判定を行えるようにする、開発された３つの主な態様又はモジュールがある。これらの３つのモジュールは、図２に示され、
（ｉ）事象が発生したときを検出することができる「事象スニファ」モジュール２０１の実施、
（ｉｉ）取得されたデータを調和させ、取得されたデータの品質が事象判定の要件を満たすことを保証するツール－「データ調和及び収集」モジュール２０３及び
（ｉｉｉ）臨床エンドポイント判定自体を実行する機械学習手法－「自動事象判定」モジュール２０５
である。
（ｉ）事象が発生したときを検出することができる「事象スニファ」モジュール２０１の実施、
（ｉｉ）取得されたデータを調和させ、取得されたデータの品質が事象判定の要件を満たすことを保証するツール－「データ調和及び収集」モジュール２０３及び
（ｉｉｉ）臨床エンドポイント判定自体を実行する機械学習手法－「自動事象判定」モジュール２０５
である。
【0052】
図２から見られるように、これらの３つの態様又はモジュールは一緒に機能し得、それにより、事象スニファ２０１並びにデータ調和及び収集モジュール２０３からの出力は、自動事象判定２０５への入力として使用することができる。例えば、ヘルスケア事象が発生した確率が比較的高い（例えば、選択された尤度閾値レベルを超える）と事象スニファモジュール２０１が判断する場合、自動事象判定モジュール２０５は事象スニファ２０１からの結果及びデータ調和及び収集モジュール２０３からの調和データ出力を使用して、判定アウトカムを特定し得る。これらの３つの態様又はモジュールが、ハードウェア及び／又はソフトウェアで個々に又は組み合わせて実施可能なことが理解されよう。例えば、モジュールは、図２４を参照して後述するようにコンピュータシステム２６００で実施されてよく、例えば、メモリ２６１０又はストレージ２６１６に記憶され、プロセッサ２６１４により実施されてよい。しかしながら、モジュールは各コンピュータシステムで実施されてもよい。先に列記したモジュールがリモートサーバで実施されてもよく、例えば、「クラウド」として動作し、インターネット等の電気通信ネットワークを介してアクセス可能であってもよいことも理解されよう。全てのモジュールが同じリモートサーバで実施されてもよく、又は異なるリモートサーバで実施されてもよいことが理解されよう。
【0053】
これら３つの態様についてこれより詳細に論じる。
【0054】
事象スニファ
歴史的に、研究者は、心血管疾患アウトカム試験（ＣＶＯＴ）においてエンドポイント事象（例えば入院）についての関連情報を適時取得することに奮闘してきた。さらに、事象によっては、決して報告されず、したがって、研究者に決して知られないことがある。そのようはデータギャップ及び遅延は、データ品質、エンドポイント事象データ収集の適時性、及び試験での患者経験に悪影響を及ぼす。検出される計画外入院数を増大させるとともに、そのような事象の検出をスピードアップするために、多様なデータソースからの患者状況についての信号を準リアルタイムでモニタし解析する「事象スニファ」が開発された。
歴史的に、研究者は、心血管疾患アウトカム試験（ＣＶＯＴ）においてエンドポイント事象（例えば入院）についての関連情報を適時取得することに奮闘してきた。さらに、事象によっては、決して報告されず、したがって、研究者に決して知られないことがある。そのようはデータギャップ及び遅延は、データ品質、エンドポイント事象データ収集の適時性、及び試験での患者経験に悪影響を及ぼす。検出される計画外入院数を増大させるとともに、そのような事象の検出をスピードアップするために、多様なデータソースからの患者状況についての信号を準リアルタイムでモニタし解析する「事象スニファ」が開発された。
【0055】
「事象スニファ」は、ヘルスケア事象が臨床試験の参加者に発生したか否かを判断するのに使用されるモニタリングシステムである。事象スニファは、例えば、図４に示されるように、患者が各自のモバイルデバイスでのアプリケーションの使用を介して、事象が発生したことを積極的に報告できるようにすることができる。事象スニファは、多様なソースからの信号を結合し得、データ信号のソースに応じて、信号により提供される患者のパラメータ及び信号ソースに基づいて適用される重みに基づいて、ヘルスケア事象が発生している／発生した確率を特定し得る。例えば、信号は、患者のパラメータ（心拍数、血圧、呼吸数等）を報告する患者接続デバイスから受信し得、重みは、信号のソースに基づいて適用し得る－例えば、既知のブランド又はメーカーの心拍数モニタの信頼性がより高いことがわかっている場合、それは信頼性の低いことがわかっている心拍数モニタよりも好意的に加重され得る。
【0056】
システムは、他のソースからも同様に、患者のパラメータを示す情報を取得するように構成し得る－これは図３により詳細に示され、例えば図５～図１０を参照してより詳細に以下説明されるが、例えば、システムは、場所データを取得し、既知の医療施設場所のデータベースと突き合わせて調査を実行することにより、その場所で費やした時間量に基づいて、患者が医療施設（病院等）を訪れたときを特定するように構成し得る。例えば、ユーザが、選択された閾値時間量を超えて医療施設の既知の場所にいる場合、システムは、ユーザが医療施設にいると判断し得る。ユーザが医療施設にいると判断された場合、図４に示されるように、システムは、ユーザが医療施設にいるか否か及びヘルスケア事象が発生しているか否か又は発生したか否かを確認を求める通知又はアラートをユーザに提供する（例えばユーザのモバイルデバイスで実行中のアプリ上で）ように構成し得る。
【0057】
事象スニファシステムの利点は、臨床現場及び医療審査から独立して臨床事象を準リアルタイムで識別するように動作可能なことである。
【0058】
事象スニファモジュール２０１は、ＡｓｔｒａＺｅｎｅｃａ（登録商標）のＵｎｉｆｙアプリ、医療機関及び／又はナショナルレジストリからの電子カルテ、電子データ捕捉（ＥＤＣ）で利用可能な患者データに基づくプロプライエタリの内部生成予測リスクアルゴリズムを含め、複数のソースから信号を受信する。これらの信号は図５に示され、ソース及び信号が「事象スニファ」機能内で果たす役割によって細分されてより詳細に後述される。図５は、事象スニファモジュールの機能の概略的なプロセスフローチャートを示し、Ｕｎｉｆｙからの信号が現実世界又は「リアルタイム」データ（例えば患者からリアルタイムで取得される）の一例であり、ＡＩＤＡスニファから取得された信号が、医療記録及びデータベースから取得することができる事前既知データの一例である。
【0059】
Ｕｎｉｆｙからの信号：
Ａ．医療ジオフェンス（トリガー事象信号）：スマートフォンオペレーティングシステムの位置特定サービスを利用して、患者が病院に入り、ＣＶ関連エンドポイント事象に準拠した指定時間量（例えば１８時間）にわたって滞在するときをモニタするＵｎｉｆｙ内のアルゴリズム；病院ジオフェンスデータベースはプロプライエタリデータセットであり；ジオフェンスルールがトリガーされる場合、Ｕｎｉｆｙアプリは、医療事象を有していることを確認するように患者に求め、全てのメタデータはＵｎｉｆｙバックエンドに送信される。このソースは「トリガー事象」信号を表し得、これは、事象スニファシステムをトリガーして、このソースからの信号が受信されたとき、ヘルスケア事象が発生したか否かを判断し得ることを意味する。異なる重み付けを「トリガー事象」信号から「状況」信号に適用し得ることが理解されよう。
Ｂ．患者報告事象（トリガー事象信号）：潜在的にエンドポイント事象を経験していることを患者が自己報告することができるＵｎｉｆｙアプリの機能；アプリは、２週間毎に１回、患者が事象を自己報告していなかった場合、自己報告するように患者に思い出させもする；アプリは、自己報告された全ての事象及び関連するメタデータをＵｎｉｆｙバックエンドに送信する。このソースはトリガー事象信号を表し得る。
Ｃ．接続されたデバイスの測定値（トリガー事象信号）：患者が、接続された医療デバイス（例えば血圧カフ）を使用して測定を自己管理できるようにするＵｎｉｆｙアプリの機能。アプリは、デバイスとスマートフォン／タブレットとの間でＢｌｕｅｔｏｏｔｈ接続を可能にする。次いで、アプリは、メタデータを含め、記録された測定値をＵｎｉｆｙバックエンドに送信する。アルゴリズムは、測定データと関連する潜在的なエンドポイント事象について各測定値を査定する。アルゴリズムは、「エッジ」上のアプリ（即ちスマートデバイスのアプリで行われている）、若しくはＵｎｉｆｙバックエンド、又は両方に内蔵することができる。潜在的なエンドポイント事象の信号を含む接続された全てのデバイスの測定データ及びメタデータは、アプリによりＵｎｉｆｙバックエンドに送信される。このソースはトリガー事象信号を表し得る。Ｕｎｉｆｙを介して試験で患者が利用可能なデバイスには、例えば、
ａ．Ｏｍｒｏｎ（登録商標）血圧カフ、
ｂ．Ｍａｒｓｄｅｎ（登録商標）体重計、
ｃ．ＭｉｇｈｔｙＳａｔ（登録商標）のＲｘパルスオキシメータ
がある。
Ｄ．アプリユーザ統計（状況信号）：Ｕｎｉｆｙアプリは、患者ユーザ統計（例えば、作業にかかった時間、ログイン間の時間等）も収集し、これは状況信号として使用することができる。これは、ユーザ統計の傾向がそれ自体では、ヘルスケア事象が発生したと事象スニファシステムが判断するのをトリガーしないことがあるが、トリガー時（例えばジオフェンス事象からの）の患者の状態についての追加の状況信号を提供することを意味する。
Ａ．医療ジオフェンス（トリガー事象信号）：スマートフォンオペレーティングシステムの位置特定サービスを利用して、患者が病院に入り、ＣＶ関連エンドポイント事象に準拠した指定時間量（例えば１８時間）にわたって滞在するときをモニタするＵｎｉｆｙ内のアルゴリズム；病院ジオフェンスデータベースはプロプライエタリデータセットであり；ジオフェンスルールがトリガーされる場合、Ｕｎｉｆｙアプリは、医療事象を有していることを確認するように患者に求め、全てのメタデータはＵｎｉｆｙバックエンドに送信される。このソースは「トリガー事象」信号を表し得、これは、事象スニファシステムをトリガーして、このソースからの信号が受信されたとき、ヘルスケア事象が発生したか否かを判断し得ることを意味する。異なる重み付けを「トリガー事象」信号から「状況」信号に適用し得ることが理解されよう。
Ｂ．患者報告事象（トリガー事象信号）：潜在的にエンドポイント事象を経験していることを患者が自己報告することができるＵｎｉｆｙアプリの機能；アプリは、２週間毎に１回、患者が事象を自己報告していなかった場合、自己報告するように患者に思い出させもする；アプリは、自己報告された全ての事象及び関連するメタデータをＵｎｉｆｙバックエンドに送信する。このソースはトリガー事象信号を表し得る。
Ｃ．接続されたデバイスの測定値（トリガー事象信号）：患者が、接続された医療デバイス（例えば血圧カフ）を使用して測定を自己管理できるようにするＵｎｉｆｙアプリの機能。アプリは、デバイスとスマートフォン／タブレットとの間でＢｌｕｅｔｏｏｔｈ接続を可能にする。次いで、アプリは、メタデータを含め、記録された測定値をＵｎｉｆｙバックエンドに送信する。アルゴリズムは、測定データと関連する潜在的なエンドポイント事象について各測定値を査定する。アルゴリズムは、「エッジ」上のアプリ（即ちスマートデバイスのアプリで行われている）、若しくはＵｎｉｆｙバックエンド、又は両方に内蔵することができる。潜在的なエンドポイント事象の信号を含む接続された全てのデバイスの測定データ及びメタデータは、アプリによりＵｎｉｆｙバックエンドに送信される。このソースはトリガー事象信号を表し得る。Ｕｎｉｆｙを介して試験で患者が利用可能なデバイスには、例えば、
ａ．Ｏｍｒｏｎ（登録商標）血圧カフ、
ｂ．Ｍａｒｓｄｅｎ（登録商標）体重計、
ｃ．ＭｉｇｈｔｙＳａｔ（登録商標）のＲｘパルスオキシメータ
がある。
Ｄ．アプリユーザ統計（状況信号）：Ｕｎｉｆｙアプリは、患者ユーザ統計（例えば、作業にかかった時間、ログイン間の時間等）も収集し、これは状況信号として使用することができる。これは、ユーザ統計の傾向がそれ自体では、ヘルスケア事象が発生したと事象スニファシステムが判断するのをトリガーしないことがあるが、トリガー時（例えばジオフェンス事象からの）の患者の状態についての追加の状況信号を提供することを意味する。
【0060】
追加の信号：
Ｅ．リアルワールドエビデンス（ＲＷＥ）ベースの予測モデル（状況信号）：潜在的な患者事象についての通知に優先度を付けるヘルスケア提供者（ＨＣＰ）の支援を目的とする機械学習アルゴリズム；アルゴリズムは、ＲＷＤ主張データ及び／又は同様の試験からの過去のＡＺデータを使用してトレーニングされる。これらのアルゴリズムは状況信号を提供し得；トリガー時（例えばジオフェンス事象から）の患者状態についての追加の状況信号を提供し得る。
Ｆ．電子カルテ（トリガー事象信号）：このデータソースは、患者の過去の通院について電子データ捕捉（ＥＤＣ）に提供された医療機関から直接又は間接的に（即ちＴｒｉＮｅｔＸのようなサービスを介して）受信された構造化及び非構造化電子カルテデータからなる。このデータは、潜在的なエンドポイント事象についての信号を提供する患者の通院（例えば退院リポート）についての詳細な情報を提供する。この信号は、生の信号（例えばＥＨＲからの直接のデータ）及び／又は上記ＥＨＲデータからトレーニングされたＡＩアルゴリズムの結果からなることができる。このソースはトリガー事象信号を表し得る。
Ｇ．集団レジストリ（状況信号）：このソースは、死亡を含む集団についての幾つかの国及び／又は地方政府により提供されるナショナルレジストリデータからなる。このソースは状況信号を提供する；トリガー時（例えばジオフェンス事象からの）の患者状態についての追加の状況信号を提供し得る。
Ｅ．リアルワールドエビデンス（ＲＷＥ）ベースの予測モデル（状況信号）：潜在的な患者事象についての通知に優先度を付けるヘルスケア提供者（ＨＣＰ）の支援を目的とする機械学習アルゴリズム；アルゴリズムは、ＲＷＤ主張データ及び／又は同様の試験からの過去のＡＺデータを使用してトレーニングされる。これらのアルゴリズムは状況信号を提供し得；トリガー時（例えばジオフェンス事象から）の患者状態についての追加の状況信号を提供し得る。
Ｆ．電子カルテ（トリガー事象信号）：このデータソースは、患者の過去の通院について電子データ捕捉（ＥＤＣ）に提供された医療機関から直接又は間接的に（即ちＴｒｉＮｅｔＸのようなサービスを介して）受信された構造化及び非構造化電子カルテデータからなる。このデータは、潜在的なエンドポイント事象についての信号を提供する患者の通院（例えば退院リポート）についての詳細な情報を提供する。この信号は、生の信号（例えばＥＨＲからの直接のデータ）及び／又は上記ＥＨＲデータからトレーニングされたＡＩアルゴリズムの結果からなることができる。このソースはトリガー事象信号を表し得る。
Ｇ．集団レジストリ（状況信号）：このソースは、死亡を含む集団についての幾つかの国及び／又は地方政府により提供されるナショナルレジストリデータからなる。このソースは状況信号を提供する；トリガー時（例えばジオフェンス事象からの）の患者状態についての追加の状況信号を提供し得る。
【0061】
事象スニファモジュールは、全て自動化されたワークフローで、信号を指揮し、例えばトリガー事象に従って結合して単一の集計信号（別名事象スニファ書類）にし、信号を潜在的なエンドポイント又はヘルスケア事象の候補とし、ランク付けるように構成される。これらの各機能の詳細については以下を参照されたい。
・データの指揮及び結合：任意のトリガー事象が発生する場合（上述したように）、システムは、他の全てのソースからの同時（及び／又は最近の）トリガー及び状況信号を探してスキャンし、それらを一緒に結合して、事象スニファ書類と呼ばれる単一の集計信号にするように構成される。事象スニファシステムがスキャンする特定のデータ要素は以下を含む：他の事象トリガー及び／又は状況信号の存在；識別された全ての事象トリガー及び／又は状況信号の年齢。
・事象ランキング：さらに、システムは全体信号ランキングを提供するように構成され、ランキングは、現場のヘルスケア提供者（ＨＣＰ）に提示するためにＵｎｉｆｙに提供される。このランキングは、ビジネスルールと事象スニファショルで利用可能な各信号を評価し重み付けする機械学習との組合せを使用して行われる。
・データの指揮及び結合：任意のトリガー事象が発生する場合（上述したように）、システムは、他の全てのソースからの同時（及び／又は最近の）トリガー及び状況信号を探してスキャンし、それらを一緒に結合して、事象スニファ書類と呼ばれる単一の集計信号にするように構成される。事象スニファシステムがスキャンする特定のデータ要素は以下を含む：他の事象トリガー及び／又は状況信号の存在；識別された全ての事象トリガー及び／又は状況信号の年齢。
・事象ランキング：さらに、システムは全体信号ランキングを提供するように構成され、ランキングは、現場のヘルスケア提供者（ＨＣＰ）に提示するためにＵｎｉｆｙに提供される。このランキングは、ビジネスルールと事象スニファショルで利用可能な各信号を評価し重み付けする機械学習との組合せを使用して行われる。
【0062】
事象スニファモジュール２０１がいかに機能し得るかの２つの例について、単なる例としてこれより以下に説明する。
・例１－低ランク事象：接続デバイスルールはトリガーする（１日にわたる高血圧）が、他のトリガー事象は患者の書類に存在しない（病院ジオフェンス情報なし；患者報告事象なし）。さらに、患者が現時点で心筋梗塞のリスクが低／中であることをＲＷＤ／ＲＣＴ予測リスクアルゴリズムが示す。この情報は書類（異なるソースからの全ての事象及び患者についてのメタデータを集計する事象スニファデジタル書類）において結合され、０．３という事象ランキングスコアが生成され、０．３は、事象が関連するエンドポイント事象である可能性が低いことを意味する。
・注：０．３のスコアは現在、代表的なものであり、作業アルゴリズムの出力を反映していない。
・例２－高ランク事象：患者がＵｎｉｆｙアプリを介して事象を自己報告する。この事象は、２つの他のトリガー信号と結合される：病院ジオフェンスアラート（数時間前にトリガーされた）及び接続デバイスビジネスルール（過去２日の各々からの高血圧）。さらに、患者が現在時点において心筋梗塞で高リスクであることをＲＷＤ／ＲＣＴ予測リスクアルゴリズムが示す。この情報は書類（事象スニファデジタル書類）において結合され、０．９の事象ランキングスコアが生成され、０．９は、事象が関連するエンドポイント事象である可能性が高いことを示す。
・注：０．９のスコアは現在、代表的なものであり、作業アルゴリズムの出力を反映していない。
・注：接続デバイス及びジオフェンスの前のトリガーは、０．９の前に存在していたスコアがあったことを暗示する。意図される機能は、各新事象で、関連する情報で患者の事象スニファ書類を「更新」し、ランキングについてリスクスコアを更新することである。
・例１－低ランク事象：接続デバイスルールはトリガーする（１日にわたる高血圧）が、他のトリガー事象は患者の書類に存在しない（病院ジオフェンス情報なし；患者報告事象なし）。さらに、患者が現時点で心筋梗塞のリスクが低／中であることをＲＷＤ／ＲＣＴ予測リスクアルゴリズムが示す。この情報は書類（異なるソースからの全ての事象及び患者についてのメタデータを集計する事象スニファデジタル書類）において結合され、０．３という事象ランキングスコアが生成され、０．３は、事象が関連するエンドポイント事象である可能性が低いことを意味する。
・注：０．３のスコアは現在、代表的なものであり、作業アルゴリズムの出力を反映していない。
・例２－高ランク事象：患者がＵｎｉｆｙアプリを介して事象を自己報告する。この事象は、２つの他のトリガー信号と結合される：病院ジオフェンスアラート（数時間前にトリガーされた）及び接続デバイスビジネスルール（過去２日の各々からの高血圧）。さらに、患者が現在時点において心筋梗塞で高リスクであることをＲＷＤ／ＲＣＴ予測リスクアルゴリズムが示す。この情報は書類（事象スニファデジタル書類）において結合され、０．９の事象ランキングスコアが生成され、０．９は、事象が関連するエンドポイント事象である可能性が高いことを示す。
・注：０．９のスコアは現在、代表的なものであり、作業アルゴリズムの出力を反映していない。
・注：接続デバイス及びジオフェンスの前のトリガーは、０．９の前に存在していたスコアがあったことを暗示する。意図される機能は、各新事象で、関連する情報で患者の事象スニファ書類を「更新」し、ランキングについてリスクスコアを更新することである。
【0063】
上述したような機能を有し得る事象スニファ又はモニタリングシステム２０００の一例を図３に示す。事象スニファシステム２０００は、臨床試験の参加者でヘルスケア事象が発生したか否かを判断するためのモニタリングシステムであり得る。システム２００１は、プロセッサ２００３に結合された通信インタフェース２００５を備える。事象スニファシステム２０００はポータブル電子デバイス（例えばスマートフォン、タブレット、若しくはラップトップ）に提供されてもよく、又はリモートに提供されて、例えばクラウドを介してアクセス可能であってもよいことが理解されよう。幾つかの例では、システム２００１は、図２４を参照して後述するシステム２６００と同様又は同じ機能及び／又はコンポーネントを有し得る。幾つかの例では、システム２００１は、ＧＰＳモジュール又はシステム２００１の場所を特定する他の手段等の任意選択的な位置特定モジュールを更に備え得る。
【0064】
通信インタフェース２００５は、複数のソースから複数の参加者に関連するデータ信号を受信するように構成され、データ信号は各々、参加者と関連するパラメータを示す情報を含む。プロセッサ２００３は、各患者について、受診した各データ信号を処理し、データ信号のソースに基づいて各データ信号に第１の重みを適用するように構成される。重み付けは、信号が「トリガー事象」信号であるかそれとも「状況」信号であるかを示すように適用可能なことが理解され、「状況」信号よりも「トリガー事象」信号に大きな重みが適用される。
【0065】
プロセッサ２００３は、（ｉ）患者と関連するパラメータがその参加者に選択された閾値を超えることを示すデータ信号及び（ｉｉ）選択されたトリガー閾値を超える第１の重みの少なくとも１つに基づいて、ヘルスケア事象発生確率を特定するように更に構成される。
【0066】
例えば、選択される閾値は例えば、１００ｍ未満の医療施設（病院等）までの距離、１６０ｂｐｍを越える心拍数、又は３０を越える呼吸数であり得る。選択される閾値は、患者の他のパラメータに基づくこともできる－例えば、選択される閾値は、例えば心拍数閾値が、若い人よりも年齢が上の人ほど低くなるように、年齢に応じて変わり得る。
【0067】
幾つかの例では、プロセッサ２００３は、（ｉ）患者と関連するパラメータがその参加者に選択された閾値を超えることを示すデータ信号及び（ｉｉ）選択されたトリガー閾値を超える第１の重みの両方に基づいて、ヘルスケア事象発生確率を特定するように構成し得る。このようにして、例えば、プロセッサ２００３は、「トリガー事象」信号が受信された場合のみ、例えば患者が医療施設から選択された距離内にいる場合のみ、特定を行い得る。このようにして、プロセッサ２００３は、（ｉ）患者と関連するパラメータが選択された閾値を超えること及び（ｉｉ）そのデータ信号の重みが選択された閾値を超えることの少なくとも一方を示す少なくとも１つのデータ信号を有する複数のデータ信号に基づいて、ヘルスケア事象発生確率を特定するように構成し得る。例えば、プロセッサ２００３は、上述したように、複数の信号を結合して事象スニファ書類にするように構成し得る。
【0068】
プロセッサ２００３は、特定された確率が選択された閾値を超える（例えば確率が５０％よりも大きい、７０％よりも大きい、９０％よりも大きい）ことに基づいて、ヘルスケア事象が発生したと判断するように構成し得、ヘルスケア事象が発生したとプロセッサ２００３が判断する場合、プロセッサ２００３は、通知をモニタリングシステムのユーザに提供するように構成され（例えば図５に示されるように）、モニタリングシステム２０００は、特定されたヘルスケア事象発生確率に基づいて、例えば通知への患者の応答に基づいて通知をランク付けるように構成される。
【0069】
プロセッサ２００３は、データ信号のソース及び参加者と関連するパラメータの指示に基づいてヘルスケア事象のタイプを特定するように構成し得る。幾つかの例では、プロセッサ２００３は、特定されたヘルスケア事象のタイプに基づいて通知をランク付けるように構成し得る－例えば、深刻度が高いと判断された事象ほど高くランク付けることができる。幾つかの例では、プロセッサ２００３は、参加者の既知の健康に基づいて通知をランク付けるように構成し得る。
【0070】
幾つかの例では、プロセッサ２００３が、パラメータが選択された閾値を超えたことを示す受信データ信号に基づいてヘルスケア事象発生確率を特定する場合、プロセッサ２００３は、特定に先立つ選択された時間間隔中の参加者と関連するそのパラメータの前の値を示す情報を審査する。選択される時間間隔は例えば、関連するパラメータに応じて可変である。例えば、プロセッサ２００３は、ここ１週間にわたる血圧を審査し得るが、前の１２時間にわたる心拍数は審査しなくてよい。プロセッサ２００３は、そのパラメータが選択された閾値を超えた場合のみ、そのパラメータの前の値を審査し得るが、他の例では、異なるパラメータが選択された閾値を超えた場合、１つ又は複数のパラメータの前の値を審査し得る。これを行うことは、ヘルスケア事象のタイプの特定に役立つのみならず、ある程度の検証可能性も提供し得る。図９及び図２０を参照してより詳細に後述するように、測定エラー（例えばデータ欠損／データ品質不良）と潜在的な安全性事象（例えば呼吸数上昇の単一点異常又は体重増加の傾向異常）とを区別するのに役立ち得る。
【0071】
事象発生確率が選択された閾値を超えると判断される場合、プロセッサ２００３は、患者からより多くの情報が必要であるか否かについて判断するように構成し得、より多くの情報が必要な場合、例えば図４に示されるようにアプリを介して、患者と連絡をとる通知がヘルスケア提供者／システム管理者に提供される。例えば、プロセッサ２００３は、患者から、最小組の別個のパラメータを示す情報を要求し得、プロセッサ２００３は、その情報のいずれかが欠損しているか否か及び／又は十分に最近、例えば特定の選択された時間窓内で取得されなかったかどうかを判断するように構成し得る。
【0072】
プロセッサ２００３は、データ信号の信頼性を特定し、データ信号の信頼性に基づいて第２の重みを適用するように構成することもできる。プロセッサ２００３は、患者と関連するパラメータが選択された閾値を超えることを示すデータ信号並びに第１及び第２の重みに基づいて、ヘルスケア事象発生確率を特定するように構成し得る。データ信号の信頼性は、例えば、信号が取得されたデバイスが低電池残量又は接続不良を有したこと又はデータが最近アップロードされていないかどうかを示す、信号と共に取得されたメタデータから特定し得る。信号の信頼性の特定については、図６～図１０を参照してより詳細に後述する。
【0073】
プロセッサ２００３は追加又は代替として、参加者について任意の以前に特定された事象発生確率に基づいて、その参加者のヘルスケア事象発生確率を特定するように構成し得る。
【0074】
図３に示されるモニタリングシステム２０００が、場所データ及び特定の場所での患者の滞在時間のみに基づいてヘルスケア事象が発生したか否かを判断するように動作可能であり得ることも理解されよう。例えば、通信インタフェース２００５は、複数のソースから複数の参加者に関連するデータ信号を受信するように構成し得、データ信号は各々、参加者と関連する場所を示す情報を含む。各参加者について、プロセッサ２００３は、各受信データ信号を処理し、（ｉ）既知のヘルスケアセンターへの参加者の近接性及び（ｉｉ）既知のヘルスケアセンターへの参加者の近接性の持続時間に基づいて、その参加者のヘルスケア事象発生確率を特定するように構成し得る。ヘルスケア事象発生確率が選択された閾値を超えるとプロセッサ２００３が判断した場合、プロセッサ２００３は、ヘルスケア事象が発生したことの参加者からの確認を求める通知を参加者に送信するように構成される（例えば図４に示されるように）。
【0075】
上述したように、プロセッサ２００３は、データ信号の信頼性を特定するように構成し得る。例えば、プロセッサ２００３は、関心のあるエンドポイントと同じ時間での同じ対象者による同じデバイスからの測定における変動が最小であることのエビデンスを見つけようとし得る。これを実行する一例の方法は以下であり得る：
・接続されたデバイス＋アプリ（Ｂｌｕｅｔｏｏｔｈ）を使用して血圧の複数の連続測定を行い、データはバックエンドストレージに送信され、
・３０分窓内で少なくとも１５回の測定を行い、必要に応じて実験を繰り返し、
・測定値のクラス間相関係数＞０．９の場合、
成功する。
・接続されたデバイス＋アプリ（Ｂｌｕｅｔｏｏｔｈ）を使用して血圧の複数の連続測定を行い、データはバックエンドストレージに送信され、
・３０分窓内で少なくとも１５回の測定を行い、必要に応じて実験を繰り返し、
・測定値のクラス間相関係数＞０．９の場合、
成功する。
【0076】
潜在的な異常に対処する方法、特に、事象が異常であるか否か又はヘルスケア事象が発生したことを示し得るか否かを判断する方法が図６～図１０に示される。異常は、データを取得したデバイスの異常（デバイス異常）であってもよく、又はデータ自体の異常（データ異常）であってもよい。図６は、潜在的な異常が発生したか否かを判断するためにプロセッサ２００３が実行し得るステップを示す。プロセッサ２００３は、まず、データ信号を介してデータを受信すると、潜在的な測定エラー及び／又は潜在的な安全性事象があるか否かを判断する。潜在的な測定エラーがあるか否かを判断するに当たり、プロセッサ２００３は、データ欠損及び／又は低品質データが存在するか否かを判断する。データ欠損がある場合、プロセッサ２００３は、アドヒアランスにより（例えば、患者が測定デバイスを十分な時間にわたって装着していない若しくは患者がスケジュールされた測定を行わない）又は接続不良により（例えば、測定デバイスが測定アプリに接続されていなかった及び／又はアプリがバックエンドサーバと接続されていない）、データが欠損しているか否かを判断する。低品質データが存在する場合、プロセッサ２００３は、デバイスが誤作動したか否か及び／又は患者により不適切に使用されたか否かを判断しようとする。例えば、例えば、患者の他のパラメータを示す他のデータに従わない単一点異常及び／又は傾向異常が存在する場合、潜在的な安全性事象が判断され得る。しかしながら、潜在的な安全性事象はヘルスケア事象を示し得、したがって幾つかの例では、潜在的な安全性事象は、例えば、事象スニファ書類等からの患者の他のパラメータを示す他のデータを利用する、ヘルスケア事象が発生したか否かについての判断をトリガーし得る。
【0077】
図７～図１０は、場所データ及び特定の場所での患者の滞在時間に基づいて、ヘルスケア事象が発生したか否かを判断するようにモニタリングシステム２０００が動作可能な例において、システム２００がまた、データにおける異常性及び非一貫性に対処しようとし得る方法を示す。図７は、判断がいかに行われるかについてのプロセスフローチャートを示し、図８は、ヘルスケア事象が発生したか否かを判断するために使用されるルールを示す。例えば図７及び図８に見られるように、患者が、選択された最小閾値時間を越える連続時間にわたり病院にいた場合、患者が事象を有しているか否か又は有したか否かを確認するように患者に求める通知を患者にアプリ上で提供し得る（図４に示されるように）。図７及び図８は、患者の電話がオフ／信号を失う場合及び／又は患者が病院を出る場合、何が生じるかも示す。両事例で、患者が戻る場合及び／又は信号が２４時間以内に再獲得され、患者が、閾値時間を越える非連続時間にわたって病院にいた場合、患者が事象を有しているか否か又は有したか否かを確認するように患者に再び求める。患者が確認する場合、システムは、事象が発生したと判断し、高確率（例えば９０％超）を事象に割り振る。患者が、事象を有さなかったとの否定的な指示を返信する場合、システムは、事象が発生しなかったと判断し、低確率（例えば１０％未満）を事象に割り振る。患者が返信しない場合、システムは、患者が潜在的に事象を有した可能性があると判断し、適切な確率（例えば５０％）を割り振る。当然ながら、これらの確率は、例えば、患者から取得された他のパラメータ並びに事象スニファ書類から取得し得る各データ信号及び重みに基づいてシステムにより調整し得る。
【0078】
データ信号を介して患者から取得し得るパラメータの例には以下がある：
・年齢、
・ＢＭＩ、
・身長、
・収縮期血圧、
・クレアチニンクリアランス（ｍＬ／分）、
・糸球体濾過量Ｃ－Ｇ（ｍＬ／分／１．７）、
・糸球体濾過量ＭＤＲＤ（ｍＬ／分／１．７）、
・アルカリホスファターゼ（ＩＵ／Ｌ）、
・アポリポタンパク質Ａ１（ｇ／Ｌ）、
・アポリポタンパク質Ｂ（ｇ／Ｌ）、
・グルコース（ｍｍｏｌ／Ｌ）、
・ヘモグロビン（ｇ／Ｌ）、
・リンパ球（１０＾９／Ｌ）、
・リンパ球／白血球（％）、
・好中球（１０＾９／Ｌ）、
・血小板（１０＾９／Ｌ）、
・尿酸（ｕｍｏｌ／Ｌ）、
・白血球（１０＾９／Ｌ）、
・患者が三硝酸グリセリンを服用しているか否か及び／又はその用量、
・患者がフロセミドを服用しているか否か及び／又はその用量、
・患者がヘパリンを服用しているか否か及び／又はその用量。
・年齢、
・ＢＭＩ、
・身長、
・収縮期血圧、
・クレアチニンクリアランス（ｍＬ／分）、
・糸球体濾過量Ｃ－Ｇ（ｍＬ／分／１．７）、
・糸球体濾過量ＭＤＲＤ（ｍＬ／分／１．７）、
・アルカリホスファターゼ（ＩＵ／Ｌ）、
・アポリポタンパク質Ａ１（ｇ／Ｌ）、
・アポリポタンパク質Ｂ（ｇ／Ｌ）、
・グルコース（ｍｍｏｌ／Ｌ）、
・ヘモグロビン（ｇ／Ｌ）、
・リンパ球（１０＾９／Ｌ）、
・リンパ球／白血球（％）、
・好中球（１０＾９／Ｌ）、
・血小板（１０＾９／Ｌ）、
・尿酸（ｕｍｏｌ／Ｌ）、
・白血球（１０＾９／Ｌ）、
・患者が三硝酸グリセリンを服用しているか否か及び／又はその用量、
・患者がフロセミドを服用しているか否か及び／又はその用量、
・患者がヘパリンを服用しているか否か及び／又はその用量。
【0079】
図９は、異常又はヘルスケア事象が発生したか否かを判断する方法２４００の一例のプロセスフローを示す。ステップ２４０１において、データ（この例では、連続呼吸数）が患者から受信される。図示の例では、データは、患者が装着したウェアラブルデバイスから受信され、無線でハンドヘルドデバイスに送信され得（例えばＢｌｕｅｔｏｏｔｈ（登録商標）を介して）、ハンドヘルドデバイスは次いで、クラウドで動作しているリモートモニタリングシステムにデータを転送し得る。ステップ２４０３において、受信データは処理されて、デバイス異常があるか否かが判断される。これは例えば、例えばデータを送信したデバイスが低電池残量、接続不良を有したこと又は正確な読み取り値を取得しなかったことを示す、データと共に提供された任意のメタデータを審査することを含み得る。データがデバイス異常を含むと判断される場合、プロセスはそこで終了し、データは使用されない。逆に、データがデバイス異常を含まないと判断される場合、データは次いで、ステップ２４０５において解析されて、ヘルスケア事象又はデータ収集における異常を示すデータ異常があるか否かを判断する。この解析は、最近の値又は１組の値（例えば、選択された時間間隔にわたって取得されて、全般的な傾向を特定する）をその患者のデータの前の値及び／又は予期される値と比較することにより実行される。例えば、方法は、患者の年齢及び他の基本的な健康状態を所与として患者の安静時呼吸数の予期される値を決定することを含み得、受信値と予期される値とを比較し得る。方法は、データストアから患者の病歴を取得すること（２４０９）によりこれを行うことができる。比較により、選択されたずれレベル閾値よりも大きいずれが示される場合、これは潜在的なヘルスケア事象及び／又はデータ異常を示し得る。本事例では、データは、最近の時間にわたる、呼吸数３０／分を越える呼吸数の急増を示す。これは潜在的なヘルスケア事象を示し得る。
【0080】
潜在的なヘルスケア事象及び／又はデータ異常が判断される場合、１組のルール／動作がステップ２４０７において適用される。例えば図４に示されるように、これらのルールは、ヘルスケア事象があるか否かをユーザに尋ねる指示又は通知をユーザに提供し、データを正しい様式で正しく取得している（例えば、呼吸数モニタを正しく使用している）ことを保証することを含み得る。ユーザがこれに応答して、デバイス（この場合、呼吸数モニタ）を正しい様式で使用していることを示す場合、システムは、ヘルスケア事象が発生した尤度が高いと判断し得る。本事例では、データは最近の時間にわたる、呼吸数３０／分を越える呼吸数の急増を示すため、デバイス（呼吸数モニタ）を正しく使用していることを確認するようにユーザに求める通知がユーザに送信される。この通知は、デバイス、この例では呼吸数モニタを正しく使用する方法についての指示を含み得る。
【0081】
図１０は、異常又はヘルスケア事象が発生したか否かを判断する方法２５００のプロセスフローチャートの別の例を示す。ステップ２５０１において、データ（この例では離散体重データ）が患者から離散時間間隔で受信される。図示の例では、データは、患者が体重をハンドヘルドデバイスで動作中のアプリに入力することにより受信され得、次いでデータをクラウドで動作しているリモートモニタリングシステムに又はデータをリモートモニタリングシステムに自動的にアップロードする「スマート」スケールセットを介して転送し得る。ステップ２５０３において、受信データは処理されて、デバイス異常があるか否かを判断する。これは例えば、例えばデータを送信したデバイスが低電池残量、接続不良を有したこと又は正確な読み取り値を取得しなかったことを示す、データと共に提供された任意のメタデータを審査することを含み得る。データがデバイス異常を含むと判断される場合、プロセスはそこで終了し、データは使用されない。逆に、データがデバイス異常を含まないと判断される場合、データは次いで、ステップ２５０５において解析されて、ヘルスケア事象又はデータ収集における異常を示すデータ異常があるか否かを判断する。この解析は、最近の値又は１組の値（例えば、選択された時間間隔にわたって取得されて、全般的な傾向を特定する）をその患者のデータの前の値及び／又は予期される値と比較することにより実行される。例えば、方法は、患者の年齢及び他の基本的な健康状態を所与として患者の安静時呼吸数の予期される値を決定することを含み得、受信値と予期される値とを比較し得る。方法は、データストアから患者の病歴を取得すること（２５０９）によりこれを行うことができる。比較により、選択されたずれレベル閾値よりも大きいずれが示される場合、これは潜在的なヘルスケア事象及び／又はデータ異常を示し得る。本事例では、データは、最近の時間にわたる（例えば一連の連続した日数にわたる）体重の急増を示す。これは潜在的なヘルスケア事象を示し得る。
【0082】
潜在的なヘルスケア事象及び／又はデータ異常が判断される場合、１組のルール／動作がステップ２５０７において適用される。これらのルールは、ヘルスケア事象があるか否かをユーザに尋ねる指示又は通知をユーザに提供し、データを正しい様式で正しく取得している（例えば、体重計を正しく使用している）ことを保証することを含み得る。ユーザがこれに応答して、デバイスを正しい様式で使用していることを示す場合、システムは、ヘルスケア事象が発生した尤度が高いと判断し得る。本事例では、データは最近の時間にわたる体重の急増を示すため、デバイスを正しく使用していることを確認し、及び／又は測定を繰り返すようにユーザに求める通知がユーザに送信される。測定が繰り返され、同じ又は同様（例えば選択された閾値内）の結果が得られる場合、システムは、ヘルスケア事象が発生したと判断し得る。
【0083】
データ調和
上述したように、有効な臨床エンドポイント判定を実行するためには、信頼性が高く堅牢なデータセット又は判定書類が必要とされる。これに伴う問題は、そのような臨床研究の性質及びそれらが大きな地理的エリアにわたり実行され得ること、データが取得され記録される方法が劇的に様々であり得ることに起因するものである。したがって、本発明者らは、多様なデータタイプ並びにデータタイプ及びストリーミングデータにわたる有意事象の抽出をサポートするように臨床事象データフローを再設計するデータ調和及び収集システム２０３を開発した。
上述したように、有効な臨床エンドポイント判定を実行するためには、信頼性が高く堅牢なデータセット又は判定書類が必要とされる。これに伴う問題は、そのような臨床研究の性質及びそれらが大きな地理的エリアにわたり実行され得ること、データが取得され記録される方法が劇的に様々であり得ることに起因するものである。したがって、本発明者らは、多様なデータタイプ並びにデータタイプ及びストリーミングデータにわたる有意事象の抽出をサポートするように臨床事象データフローを再設計するデータ調和及び収集システム２０３を開発した。
【0084】
より詳細には、データ調和及び収集システム２０３は、機械学習を適用して、機械学習（ＭＬ）使用可能なデータセットを準備し提供することを目的とする。
【0085】
上記目的を達成するために、データ調和及び収集システム２０３は、図１１に概略的に示される幾つかのモジュールを含み得る：
・ＣｌｉｎＩＱボット１３０９：臨床書類の組み立て、キュレーション及び品質制御のためのソフトウェアボット駆動型インテリジェントオートメーション、
・ＥＤＣ２書類１３０２及び書類マイナー１３０３：ソースドキュメントからの構成可能な臨床データ抽出ツール、ＥＤＣ２書類１３０２は、土台をなす電子データ捕捉（ＥＤＣ）システムから構造化データを抽出するためのものであり、書類マイナー１３０３は
、ソースドキュメントからデータを抽出するためのものであり、
・通知ボット１３０７：研究構成、通知、進行中の研究のデジタル書類生成、書類組立て、及び品質制御に的を絞った機能を提供するマイクロサービス一式。
・ＣｌｉｎＩＱボット１３０９：臨床書類の組み立て、キュレーション及び品質制御のためのソフトウェアボット駆動型インテリジェントオートメーション、
・ＥＤＣ２書類１３０２及び書類マイナー１３０３：ソースドキュメントからの構成可能な臨床データ抽出ツール、ＥＤＣ２書類１３０２は、土台をなす電子データ捕捉（ＥＤＣ）システムから構造化データを抽出するためのものであり、書類マイナー１３０３は
、ソースドキュメントからデータを抽出するためのものであり、
・通知ボット１３０７：研究構成、通知、進行中の研究のデジタル書類生成、書類組立て、及び品質制御に的を絞った機能を提供するマイクロサービス一式。
【0086】
データ調和及び収集システム２０３並びに先に列記したモジュールは、ハードウェア及び／又はソフトウェアで個々に又は集合的に実施し得ることが理解されよう。例えば、モジュールは、図２４を参照して後述するようにコンピュータシステム２６００で実施され得、例えば、メモリ２６１０又はストレージ２６１６に記憶され、プロセッサ２６１４により実施され得る。しかしながら、モジュールは各コンピュータシステムで実施されてもよい。先に列記したモジュールが、例えば「クラウド」として動作しており、インターネット等の電気通信ネットワークを介してアクセス可能なリモートサーバで実施されてもよいことも理解されよう。全てのモジュールが同じリモートサーバで実施されてもよく、又は異なるリモートサーバで実施されてもよいことが理解されよう。
【0087】
クライアント事象判定（ＣＥＡ）は、臨床試験の極めて重要なコンポーネントであり、判定決定をするための主要入力として判定書類（ＡＤ）を使用する。ＡＤを組み立ててる現行のプロセスは複雑であり、時間集約的であり、多くのサブプロセスを含む。これらのサブプロセスの幾つかは、データ抽出、ドキュメント収集、品質制御、現場でのフォローアップ等を含む。ＡＤを組み立てるためのデータ収集プロセス自体が３０日を越えることがあり得る。手動プロセスとそれらにかかる時間との組合せは、時間、品質、及びプロセス簡易化の点で多くの恩恵に繋がり得る、書類作成ワークフローを革新し自動化する理想的な機会を提示する。
【0088】
ＡＤは、Ｆｔに示されるように、構造化ソース及び非構造化ソースの両方からのデータで構成される。構造化データは、土台をなすＥＤＣシステムからの患者プロファイル、病歴、投薬等の情報を含む。各研究は独自であるため、このデータを捕捉するための規格及び要件は各研究で異なり得る。ＥＤＣ２書類モジュール１３０２は、ＥＤＣデータに基づいてデジタル書類を作成することができる。非構造化データは、退院概要、死亡証明書、検死報告書等のドキュメントに由来し得る。これらのドキュメントの形式は各国で、時には試験に参加している各病院で異なる。書類マイナーモジュール１３０３は、ソースドキュメントに基づいてデジタル書類も作成する。
【0089】
書類マイナーモジュール１３０３の出力は、１組の品質ルールを用いて検証することができ、ＱＣサービスにより管理することができる。デジタル書類サービスは、これらの出力を結合して、完全な仮想判定書類１３１３を作成する。任意の欠損データ又はドキュメント問題を解決するために必要な通知又は通信は、通知ボットモジュール１３０７により管理される。
【0090】
ＣｌｉｎＩＱボットモジュール１３０９は、ＥＤＣ２書類モジュール１３０２、書類マイナーモジュール１３０３、及び通知ボットモジュール１３０７を統合することにより仮想判定書類１３１３を組み立てるエンドツーエンド自動ワークフローである。図１１は、エンドツーエンド自動ワークフローＣｌｉｎＩＱボット１３０９の高レベル図を表し、これは、デプロイされると、臨床試験での判定プロセスを加速させ、知的自動化を適用して臨床試験を改善する新しい業界標準を設定する潜在性を有する。
【0091】
ＥＤＣ２書類モジュール１３０２は、ＥＤＣシステムからの完了した臨床試験から構造化データを抽出し処理するプロセスの自動化にフォーカスする。関連する全ての構造化ＥＤＣデータを組み立ててデジタル書類にし、事象判定又は臨床試験での所与の事象の事象検出を駆動する構成可能で再使用可能なパイプラインを提供する。デジタル書類は基本的に、事象分類又は事象検出アルゴリズムをよりよく実行できるようにすることを目的としたｊｓｏｎ形式の機械学習可能な臨床試験データである。
【0092】
まとめると、書類マイナーモジュール１３０３は、例えばＰＤＦ形式の非構造化ソースドキュメントからのデータ抽出にフォーカスする。書類マイナーモジュール１３０３は、これらのドキュメントに存在するフリーテキスト、表、及び画像からデータを抽出するために再使用可能なツールであり等であり、テルアビブ大学コンピュータサイエンススクール（Ｔｈｅ Ｓｃｈｏｏｌ ｏｆ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ Ｔｅｌ Ａｖｉｖ Ｕｎｉｖｅｒｓｉｔｙ）のＮｏａｍ Ｍｏｒ及びＬｉｏｒによる論文“Ｃｏｎｆｉｄｅｎｃｅ Ｐｒｅｄｉｃｔｉｏｎ ｆｏｒ Ｌｅｘｉｃｏｎ－Ｆｒｅｅ ＯＣＲ”２８ Ｍａｙ ２０１８に詳述されているように、現行水準のＭＬ＆光学文字認識（ＯＣＲ）技術を使用してｊｓｏｎ形式のＭＬ使用可能データに変換することができ、この文献は参照により本明細書に全体的に援用される。例えば、Ｔｅｓｓｅｒａｃｔ信頼メトリックの計算は、文字プロトタイプと比較し、この表現からの距離メトリックを計算することに基づく。
【0093】
データ抽出に加えて、書類マイナー１３０３は、各単語、表、画像、及びページの品質抽出品質を査定し、これらの品質信頼レベルをｊｓｏｎファイルに追加することもできる。これらのｊｓｏｎファイルは、ＥＤＣ２書類モジュール１３０２により作成されたデジタル書類と組み合わせられて、完全な仮想判定書類１３１３を組み立て、これは、自動事象判定システム２０５（「事象分類器」）の主要入力となる。
【0094】
したがって、より詳細には、書類マイナーモジュール１３０３は、臨床試験エンドポイント判定に向けて、複数のヘルスケア関連ソースからのデータを調和し校合するコンピュータ実施方法を実行するように動作可能である。方法は、各データソースを解析して、データソースにより保持されているデータが構造化データ及び／又は非構造化データを含むかを判断することを含む。図１２に示されるように、データが非構造化データを含む場合、光学文字認識（例えばＴｅｓｓｅｒａｃｔ）が、まだ機械可読形式ではないデータの１つ又は複数の領域に対して実行される。信頼スコアは、（ｉ）データソース及び（ｉｉ）光学文字認識プロセスに基づいて決定された信頼性の少なくとも一方に基づいて属性としてデータに付与される。これは、上述したように、ノームモール（Ｎｏａｍ Ｍｏｒ）及びリオールウルフ（Ｌｉｏｒ Ｗｏｌｆ）の方法を実行することにより行うことができる。信頼スコアはグローバルレベルで付与されてもよく、又はデータソースは領域に分割されて、信頼スコアが各領域に付与されてもよい。
【0095】
次いで、特徴解析がデータに対して実行されて、データから特徴を抽出し、抽出された特徴は予め定義された特徴セットにマッピングされる。マッピングは、抽出されたデータが、判定委員会により使用されるものと同じ情報に厳密に一致することを保証するため、重要である。例えば、マッピングは、過去の研究の判定書類においてどの情報が利用可能であるかに基づき得る。これを図１３に示し、図１３では、異なる臨床研究／試験が、データを記録することができる異なる数のフィールドを有し得、これらのフィールドが全ての試験で共通であるわけではないことがわかる。例えば、図１３に示されるように、ＤＡＰＡ－ＨＦ試験は１７のフィールドを有し、ＴＨＥＭＩＳ試験は２７のフィールドを有し、ＤＥＬＩＶＥＲ試験は２８のフィールドを有する。３つの試験の間でのこれらのフィールドの重複はわずか２７％である。したがって、判定を共通のデータセットで実行することができるように、各試験からの特徴が共通の特徴セットにマッピングされることが重要である。
【0096】
これが行われると、抽出されマッピングされた特徴は、臨床試験エンドポイント判定（より詳細に後述するように）を実行するに当たり機械学習モデルにより使用されるためにｊｓｏｎ形式で公開することができ、信頼スコアは特徴の属性である。幾つかの例では、公開は、信頼スコアが選択された閾値を超え、例えば、それにより、比較的高度の信頼性が使用される場合のみ、実行し得、それにより、抽出されマッピングされた特徴のみ。
【0097】
特徴解析をデータに対して実行して、データから特徴を抽出することは、任意の重複した特徴、一貫しない特徴、又は不適当な特徴についてチェックしてそれらを除去することを更に含み得る。例えば、不適当な特徴とは、モデルにより判定されている事象に関連しない特徴であり得る。
【0098】
幾つかの例では、信頼スコアが低い（例えば選択された閾値未満）場合、書類マイナーモジュール１３０３は、図１４に示されるように、データのそのソースを手動で審査するようにユーザに求め得る。これは例えば、連続して低い信頼スコアを有する幾つかの領域があると書類マイナーモジュール１３０３が判断することにより行うことができ、書類マイナーモジュール１３０３は、それらの領域を手動で審査するようにユーザに求めることができる。これは例えば、例えば手動で審査する必要がある領域の指示又は画像と共に通知をユーザに送信することにより行うことができる。
【0099】
臨床試験エンドポイント判定に必要な特徴は、様々であり得、その臨床試験に関連する異なるエンドポイントに基づき得る（例えば、入院、心筋梗塞、死亡等）ことが理解されよう。したがって、幾つかの例では、書類マイナーモジュール１３０１は、臨床試験エンドポイント判定に必要な１組の特徴を取得することを行うように構成し得、必要とされる１組の特徴はエンドポイントに基づき、書類マイナーモジュール１３０１は、複数のデータソースから取得された特徴を臨床試験エンドポイント判定に必要な１組の特徴と比較して、任意の特徴が欠損しているか否か又は不完全であるか否かを判断する。任意の特徴が欠損しているか、又は不完全であると判断された場合、書類マイナーモジュール１３０３は、特徴が欠損していることの通知をユーザに提供するように構成し得、通知は、欠損している又は不完全な特徴の指示を提供する。
【0100】
幾つかの例では、書類マイナーモジュール１３０３は、特徴解析をデータに対して実行する前、名前付きエンティティ認識をデータに対して実行し得（「自動事象判定」モジュール２０５を参照してより詳細に後述するように）、予め定義された１組の特徴に関連する正式事象特性を選択する。
【0101】
書類マイナーモジュール１３０３は、データソースにより提供されるべき１組の特徴を取得し、そのデータソースで任意の特徴が欠損しているか否かを判断し、そのデータソースで特徴が欠損している場合、特徴が欠損していることの通知をユーザに提供するように更に構成し得る。これにより有利なことに、完全で正確な判定書類を準備することができ、判定プロセスの性能を改善することができる。
【0102】
分類及び判定
臨床エンドポイント事象判定プロセスは、臨床事象の特定のクラス、例えば主要有害心血管系事象（ＭＡＣＥ）についての臨床現場の治験責任医師の判断のばらつきに起因して存在している。グローバル臨床試験では、現場の治験責任医師は必ずしも、関連する臨床分野（例えば心臓病学）で訓練を受けたとは限らず、心血管系死亡（ＣＶＤ）及び心不全入院（ＨＦ）等の事象の解釈の違いにより、事象報告についての品質問題が生じる恐れがある。これに対する従来の解決策は、訓練を受けた臨床医の委員会が、複数の臨床医を選任して、事象のタイプについて一致に達するまで、試験で発生した臨床事象を評価する臨床事象判定である。これらの事象は、研究の設計中に確立される手順書において明確に定義され、何が事象を構成するかについての明確な基準がまとめられている。臨床判定者は、判定書類、臨床測定値等の構造化データ及び退院リポート等の医療ソースドキュメントの形態の非構造化データの集まりを審査して、事象タイプの決定を行う。
臨床エンドポイント事象判定プロセスは、臨床事象の特定のクラス、例えば主要有害心血管系事象（ＭＡＣＥ）についての臨床現場の治験責任医師の判断のばらつきに起因して存在している。グローバル臨床試験では、現場の治験責任医師は必ずしも、関連する臨床分野（例えば心臓病学）で訓練を受けたとは限らず、心血管系死亡（ＣＶＤ）及び心不全入院（ＨＦ）等の事象の解釈の違いにより、事象報告についての品質問題が生じる恐れがある。これに対する従来の解決策は、訓練を受けた臨床医の委員会が、複数の臨床医を選任して、事象のタイプについて一致に達するまで、試験で発生した臨床事象を評価する臨床事象判定である。これらの事象は、研究の設計中に確立される手順書において明確に定義され、何が事象を構成するかについての明確な基準がまとめられている。臨床判定者は、判定書類、臨床測定値等の構造化データ及び退院リポート等の医療ソースドキュメントの形態の非構造化データの集まりを審査して、事象タイプの決定を行う。
【0103】
この時間がかかりリソース集約的なプロセスへの解決策として、本発明者らは自動事象判定モジュール２０５を開発した。自動事象判定モジュール２０５は、グラウンドトゥルースとして先の臨床判定者の決定でトレーニングされて、判定書類を評価し、ＣＶＤ及びＨＦ等の臨床エンドポイント事象を判断することができる機械学習アルゴリズムを使用するエンドツーエンドプロセスである。本手法は、特定の事象についての現場治験責任医師の決定に対して品質保証（ＱＡ）チェックを効率的に提供することができる。
【0104】
自動事象判定モジュール２０５は、判定中の臨床事象に基づいて指定された臨床試験からデータをとり、機械学習アルゴリズム又はアルゴリズム一式を適用して、臨床事象の分類についてのリポート及び推奨を出力する。
【0105】
図１５は、自動事象判定モジュール２０５をデプロイする場合に関わるステップの高レベル概説を提供する。ステップ３０１において、システムは入力データを受信する。モジュールが受信又は使用するデータは広く、構造化データ（臨床データベースをソースとする）及び非構造化データ（エンドポイント事象単位で指定された幅広い臨床ドキュメントを包含する、構造又はスキーマを持たない臨床フリーテキスト）としてカテゴリ分類することができる。データ入力は、上述したように、また図１８を参照してより詳細に後述するように、データ調和及び収集モジュール２０３から取得することができる。
【0106】
ステップ３０３において、関連データが選択され、ステップ３０５において、そのデータから特徴が抽出される。これを行うために、図示の例では、ｂｅｒｔ、ｂｉｏｂｅｒｔ、ｆａｓｔｔｅｘｔを含む（がこれらに限定されない）幾つかの既知の機械学習方法と、分類タスクの下流で評価された所与の特徴セットでの性能を有する名前付きエンティティ認識（ＮＥＲ）とを使用して、臨床フリーテキストが変換される。
【0107】
ステップ３０７において、モデルが実行され、ステップ３０９において、事象発生尤度のアウトカムを取得する。
【0108】
図１６は、臨床エンドポイント判定を実行する一例のコンピュータ実施方法５００のフローチャートを示す。コンピュータ実施方法は、図２６を参照して後述するようにコンピュータシステム２６００で実施し得、例えば、メモリ２６１０又はストレージ２６１６に記憶され、プロセッサ２６１４により実施され得ることが理解されよう。
【0109】
ステップ５０１において、方法は、複数のヘルスケア関連データソースからデータを受信することを含む。データソースは、構造化データソース及び非構造化データソースを含み得る。任意選択的に、方法は、各データソースを解析して、そのデータソースにより保持されるデータが構造化データ及び／又は非構造化データを含むかを判断するステップを含む。しかしながら、データ自体がソースを示す識別子／メタデータを有してもよく、したがって、この解析ステップが必要ないこともあることが理解されよう。
【0110】
ステップ５０３において、データが構造化データを含む場合、方法は、そのデータから特徴を抽出することを含む。ステップ５０５において、データが非構造化データを含む場合、方法は、自然言語処理モデルを非構造化データに適用して、非構造化データにおける特徴に関連する埋め込みを取得することを含む。自然言語処理モデルは、例えば、ｂｅｒｔ、ｂｉｏｂｅｒｔ、及び／又はｆａｓｔｔｅｘｔを含み得る。幾つかの例では、自然言語処理モデルの組合せを使用し得る。自然言語処理モデルは、例えば臨床データセットで予めトレーニングし得る。例えば、自然言語処理モデルを適用することは、データソースから利用可能なテキストでトレーニングされた第１の専用モデルを、Ｗｉｋｉｐｅｄｉａでトレーニングされた第２の汎用モデルと共に含む複数の自然言語処理モデルを適用することを含む。幾つかの例では、自然言語処理モデルを適用することは、入力バイオメディカルフリーテキストから７６８次元ベクトルに変換するＢＩＯｂｅｒｔ（バイオメディカルテキストで予めトレーニングされたモデル）と、両方ともそれぞれ３００次元ベクトルを変換する、利用可能なフリーテキストでトレーニングされた専用モデルをＷｉｋｉｐｅｄｉａでトレーニングされた汎用モデルと組合せたｆａｓｔｔｅｘｔを変更したものとを適用することを含む。
【0111】
データが非構造化データを含む場合、幾つかの例では、方法は、名前付きエンティティ認識モデルを非構造化データに適用して、非構造化データから正式事象特性を取得することと、名前付きエンティティ認識モデルを介して取得された正式事象特性に機械学習分類モデルを適用することとを更に含む。
【0112】
ステップ５０７において、方法は、機械学習分類モデルを非構造化データからの埋め込み及び構造化データから抽出された特徴に適用して、埋め込み及び構造化データから抽出された特徴に基づいてヘルスケア事象が発生したか否かを分類することを含む。機械学習分類モデルは、例えば、ランダムフォレスト、線形ＳＶＭ、又はＸＧＢｏｏｓｔを含み得る。
【0113】
任意選択的に、方法は、確率スコアを属性として分類に付与するステップ５０９を含み、確率スコアは、事象発生尤度の指示を提供する。例えば、方法は、確率スコアが選択された閾値未満である場合、分類を審査する通知をユーザに提供することを更に含み得る。このようにして、判定委員会が審査するのは、事象のサブセット又は選択された事象だけでよく、したがって、判定を完了することができる速度が大きく改善する。
【0114】
例えば、信頼スコアは、（ｉ）データソース及び（ｉｉ）非構造化データに適用された光学文字認識プロセスに基づいて決定された信頼性の少なくとも一方に基づいて属性としてデータに付与することができ、信頼スコアは、機械学習分類モデルにより重みとして使用し得る。方法は、選択された閾値を下回る信頼スコアを有するデータを除外することを含み得る。
【0115】
特徴をデータから抽出し、自然言語処理モデルを非構造化データに適用して、非構造化データにおける特徴に関連する埋め込みを取得することは、臨床エンドポイント判定で使用するために予め定義された特徴セットを取得することと、抽出された特徴及び／又は埋め込みを予め定義された特徴セットにマッピングすることと、予め定義された特徴セットに関連しない特徴及び／又は埋め込みを破棄することとを含み得る。
【0116】
図２０Ａ、図２０Ｂ、及び図２１を参照してより詳細に後述するように、機械学習分類モデルは、ヘルスケア事象が発生したか否かの分類に関わる特徴の重要度のランク付けを提供し得る。例えば、特徴の重要度のランク付けを提供することは、各特徴のＳＨＡＰ値を特定すること及び／又はローカルサロゲートモデルを機械学習分類モデルに適用して、分類への各特徴の相対寄与を特定することを含み得る。
【0117】
幾つかの例では、方法５００は、利用可能なデータ量が選択された閾値を超える場合のみ実行される。幾つかの例では、方法５００は、事象が発生したことの指示がユーザにより提供される（例えば、上述したように事象スニファ２０１により）ことに応答して実行される。
【0118】
図２及び図５に示されるように、幾つかの事例の判定、例えば低い確率スコアが付与された事例の判定には、人間の査定が必要となることが理解されよう。したがって、これらの事例が正しく適時モニタされ、判定されることを保証することがヘルスケア提供者又はマネージャに課せられる。したがって、本明細書では、臨床試験エンドポイント判定をモニタする方法が開示される。方法は、臨床試験エンドポイント判定システムから判定決定の複数の通知を受信することを含み、判定決定は、事象発生尤度の指示を提供する確率スコアを含む。次いで、方法は、（ｉ）確率スコア及び（ｉｉ）事象の深刻度の少なくとも一方に基づいて通知をランク付けすることと、判定実行に使用されるデータの書類（即ち仮想判定書類１３１３）を取得することとを含む。次いで、方法は、判定決定の正確性を審査するために、判定決定のリスト及びデータの対応する仮想判定書類１３１３をユーザに提供することを含み（図１１に示され、上述したように）、リストの順序はランクに基づく。
【0119】
方法は、ヘルスケア事象が発生したか否かを分類することに関わる特徴の重要度のランクを取得することと、判定決定のリスト及びデータの対応する書類と共に、特徴の重要度のランクをユーザに提供することとを更に含み得る。
【0120】
図１７は、上述した図１６の方法を実行し、図１６の方法を実行するように機械学習モデルをトレーニングするように動作可能なコンポーネント（例えば、例えばソフトウェア及び／又はハードウェアで実施し得るモジュール）及びコンポーネント間のデータフローを、各コンポーネントの機能の簡単な説明と共に高レベルで示す。
【0121】
より詳細には、６０１において、データ（ＰＤＦ等）が入力される。６０３において、構造化データ及び非構造化データ（フリーテキストドキュメント）が抽出され、この例では、システムはＰｙｔｈｏｎ言語を使用して動作し得るため、ｐｉｃｋｌｅファイルとして出力される。６０５において、暫定抽出が実行される。６０７は特徴エンジニアリングを含み、クリーニングされた構造化データが、仕様に従って暫定データから抽出される。幾つかの例では、これはＮＬＰデータ（後述する６０９における埋め込みから）及びＮＥＲ（これも後述する６１１における）と組み合わせられる。幾つかの例では、６９７は、機械学習モデルのトレーニングに使用するためにデータに対して試験／トレーニング分割を実行することも含む。
【0122】
６０９において、埋め込みが取得される。これは、ＮＬＰモデルをフリーテキストに適用して、ドキュメント埋め込みを生成することを含む。これは予めトレーニングされたｂｅｒｔモデル、ｆａｓｔｔｅｘｔモデル（事象判定タイプ毎に１つ）、及び／又はＷｉｋｉｐｅｄｉａ（登録商標）トレーニングされたｆａｓｔｔｅｘｔモデルを適用することを含み得る。これは、１事象毎に１エントリを使用して、１ドキュメント当たり１つの特徴ｐｉｃｋｌｅファイルを出力し得る。モデルはＭＬフロー６１５ｂにレフィスタ（ｒｅｆｉｓｔｅｒ）し得、特徴は特徴データベース６１５ａに登録し得る。ＭＬフロー６１５ｂ及び特徴データベース６１５ａは両方ともリモートデータストア（ＲＤＳ）６１５の一部であり得る。
【0123】
６１１において、予めトレーニングされたｂｅｒｎモデルを患者毎のｐｉｃｋｌｅファイルからフリーテキストドキュメントに適用し得る。事象毎のエントリを有するｐｉｃｋｌｅファイルを出力し得る。モデルはＭＬフロー６１５ｂに登録し得、特徴は特徴データベース６１５ａに登録し得る。
【0124】
６０７、６０９、及び６１１の各々は、特徴ストア６１３に記憶するために特徴を提供し得る。特徴ストア６１３は、６１７において、事象分類を実行するために使用される。これは、モデルに設定されたホールドアウト試験を使用して相互検証パラメータサーチ及び評価を実行し得る。結果及びモデルはｐｉｃｋｌｅファイルに出力し得、結果及びモデルはＭＬフロー６１５ｂに登録し得る。
【0125】
６２１において、可視化が実行され、分類器の性能（これについて図２０Ａ、図２０Ｂ、図２１を参照してより詳細に後述する）を可視化する。モデル統計及び結果をＭＬフロー６１５ｂ及びモデルアーチファクトからプルし得る。
【0126】
判定決定に使用されるモデルは、トレーニングされる必要があり得ることが理解されよう。したがって、上述した図１７を参照して、臨床試験エンドポイント判定を実行するように機械学習分類モデルをトレーニングする方法を本明細書に開示する。トレーニング方法が、図１７の方法及びシステムを実施することにより実行し得ることが理解されよう。方法は、複数のヘルスケア関連データソースからデータを受信することを含み、データは、前の臨床試験からの判定書類と、それらの判定書類に関連する判定決定とを含む。各データソースは解析されて、データソースにより保持されるデータが構造化データ及び／又は非構造化データを含むかを判断する。データが非構造化データを含む場合、方法は、自然言語処理モデルを非構造化データに適用して、非構造化データにおける特徴に関連する埋め込みを取得することを含む。データが構造化データを含む場合、方法は、そのデータから特徴を抽出することを含む。方法は次いで、判定書類からのデータに基づいて判定決定の指示を提供することと、判定決定及び判定書類からのデータに基づいて機械学習分類モデルを更新することとを含む。次いで、更新された機械学習分類モデルは関係データベースに記憶される。
【0127】
モデルがトレーニングされ、登録終了した試験の状況での性能について遡及的に検証された後、最良性能特徴セット及び機械学習モデルをスタンドアロン様式又はアンサンブルとしてデプロイするために選択し得る。
【0128】
上述したように、「自動事象判定」モジュール２０５は、データ調和及び収集」モジュール２０３及び任意選択的に「事象スニファ」モジュール２０１と組み合わせて使用することができる。図１８は、「自動事象判定」モジュール２０５を「データ調和及び収集」モジュール２０３と組み合わせていかに使用し得るかの一例を示す。図１８は、臨床試験において有害事象を自動的に判定するプロセスに適用し得る概念的段階を示す。
【0129】
図１８に見られるように、４０１において、データが、データ調和及び収集モジュール２０３に入力される。データは、非構造化ソースドキュメント４０３又はＥＤＣ（構造化）データ４０５に分割される。非構造化ソースドキュメント４０３の場合、抽出４０７が実行されて、抽出データを取得する（例えば、上述したように、ＮＬＰを使用して埋め込み及び／又はＮＥＲを取得することにより）。構造化データの場合、データは抽出され（４０９）、抽出構造化データ４１３が取得される。４１５において、構造化データ及び非構造化データは調和され（例えば、考慮される臨床エンドポイントに関連するフィールドの一貫性を保証するために）、調和データ４１７を取得する。この段階で、品質制御チェック４１９が、例えば、図１１１を参照して上述したように、ＱＣボット１３０５を使用して実行される。次いで、データは「自動事象判定」モジュール２０５に渡され、モデル固有のＱＣチェック４２１を実行し得る（例えば、ＱＣボット１３１１を使用して）。４２３において、特徴が構築されて１組の特徴４２５を取得し、これは次いで、４２７において分類に使用される。分類４２７の結果は、判定出力４２９である。幾つかの場合（例えば、事象発生確率が比較的低い場合）、手動判定４３１を実行し得る。
【0130】
特定又は判定するように設計された事象（例えばＣＶ死）に応じて、異なる機械学習アルゴリズムをトレーニングしデプロイしてもよいことが理解されよう。例えば、図１９Ａ～図９Ｃは、ＤＥＣＬＡＲＥ臨床試験からの８１７人の患者でトレーニングされた３つのアルゴリズム（ＣＶ死、非ＣＶ死、及び不確定）の結果を示す。線形ＳＶＣ、ＲＢＦ ＳＶＣ、ランダムフォレスト、又はＸＧＢｏｏｓｔモデルのいずれかがデータに適用されたかに関係なく、ＲＯＣ曲線が全て比較的類似しており、完全な分類器に近いことがわかる。図１９Ａは、試験セット（即ちホールドアウトセット）ＡＵＣが、各モデルで８０％を越えることを示す。図１９Ｃは、クラス（色）によるモデル予測スコア（Ｘ軸）の分布を示すとともに、モデルが一般に、陽性事例でより高いスコア（１に近い）を生成し、一般に陰性事例でより低いスコア（０に近い）を生成することを示す。この分離は、バイナリクラス間を区別することができる有効な分類器を示す傾向がある。
【0131】
機械学習モデルは、グローバル特徴空間にわたり極めて複雑であるが、局所的にははるかにより簡易である。特定の試験セットは、説明として、モデルの挙動の局所線形近似を説明し学習するように摂動し得る。これは、入力への摂動がモデル予測にどれくらいの影響を有するか及び各特徴がモデル予測にいかに寄与するかを明らかにし得る。これは、局所解釈可能モデル非依存説明又はＬＩＭＥと呼ぶことができる。
【0132】
図２０Ａ及び図２０Ｂは、解釈可能性を提供するために、モデル又はアルゴリズムをいかに解析することができるかを示す。例えば、モデルをいかに解析して、構造化データ及び非構造化データでも、相互情報を有するトップ特徴の指示を提供することができるかが見られる。図２０Ａでは、このモデルでの構造化特徴の特徴重要度解析は、「ＣＴスキャン未知」及び「検査での神経障害未知」が最高の重要度を有し、これらが、標的変数を予測するに当たり他の構造化特徴よりも有用であることを意味することを示す。
【0133】
図２０Ｂは、ＮＬＰアルゴリズム（この場合、ＢｉｏＢＥＲＴ）がいかに、テキストを数字のベクトルに変換することにより、テキスト本文における文脈に基づいて、同様の用語を解釈し一緒にグループ化するかを示すことにより、モデル解釈可能性を可能にした。例えば、グラフの右下にある「冠動脈心疾患」及び「心筋梗塞」では、循環器系疾患の一般領域からの両用語は、ＢｉｏＢＥＲＴモデルにより同様と識別され、したがって、チャートの他の用途と比べて互いに近い。このチャートの目視検査により、ＢｉｏＢＥＲＴモデルが期待通りに機能していることが確認される。
【0134】
シャプレイの加法的説明又はＳＨＡＰは、任意の機械学習モデルの出力を説明するためのゲーム理論手法である。理解のために、最適なクレジット割り振りを局所的説明と結びつける。
・全体モデル予測に対する各特徴の重要度、
・平均と比較して、特徴値が有すると妥当に予期することができる効果。
ＳＨＡＰ値は、モデル出力に対する各特徴の影響を示す。これは、例えば図２１に示されるチャートで表すことができる。
・全体モデル予測に対する各特徴の重要度、
・平均と比較して、特徴値が有すると妥当に予期することができる効果。
ＳＨＡＰ値は、モデル出力に対する各特徴の影響を示す。これは、例えば図２１に示されるチャートで表すことができる。
【0135】
図２２は、幾つかのメトリック（例えば、ＡＵＣ－曲線下面積、正解率、バランス正解率、Ｆ１等）及びモデルバージョン（最初の３列）にわたる機械学習モデル性能を示す。例えば、１行目は、構造化ＥＤＣデータでトレーニングされた死亡事象ランダムフォレストアルゴリズムでのメトリック（モデル性能）を示し、不確定クラスは非ＣＶ死にマッピングされた。
【0136】
実施例１
臨床アウトカム事象の正確な識別は、心血管アウトカム試験（ＣＶＯＴ）で信頼性の高い結果を得るために極めて重要である。事象判定の現行のプロセスは高価であり、遅延がネックとなっている。より高い信頼性でアウトカムを識別するためのより大きなプロジェクトの一環として、急性虚血性脳卒中又は一過性脳虚血発作（ＴＩＡ）後の大心血管事象のリスク低減においてチカグレロルとアスピリンを比較した大規模無作為試験であるＳＯＣＲＡＴＥＳ試験（ＮＣＴ０１９９４７２０）からのデータを使用して、事象判定を自動化するための機械学習の使用を評価した。
臨床アウトカム事象の正確な識別は、心血管アウトカム試験（ＣＶＯＴ）で信頼性の高い結果を得るために極めて重要である。事象判定の現行のプロセスは高価であり、遅延がネックとなっている。より高い信頼性でアウトカムを識別するためのより大きなプロジェクトの一環として、急性虚血性脳卒中又は一過性脳虚血発作（ＴＩＡ）後の大心血管事象のリスク低減においてチカグレロルとアスピリンを比較した大規模無作為試験であるＳＯＣＲＡＴＥＳ試験（ＮＣＴ０１９９４７２０）からのデータを使用して、事象判定を自動化するための機械学習の使用を評価した。
【0137】
機械学習アルゴリズムを研究して、虚血性脳梗塞及びＴＩＡの臨床事象の専門家判定プロセスのアウトカムを複製することができるか否かを判断した。分類モデルを過去のＣＶＯＴデータでトレーニングして、人間の判定者と同等の性能を示すことができたか？
【0138】
ＳＯＣＲＡＴＥＳ試験からのデータを使用して、グリッドサーチ及び交差検証を使用して複数の機械学習アルゴリズムを試験した。試験されたモデルは、サポートベクターマシン、ランダムフォレスト、及びＸＧＢｏｏｓｔを含んだ。モデル開発でトレーニング又は試験に使用されなかった判定データの検証サブセットで性能を査定した。モデル性能の評価に使用されたメトリックは、受信者動作特性（ＲＯＣ）、マシューズ相関係数、適合率、及び再現率であった。相互情報及び再帰的特徴量削減の両方を使用して、事象を分類するようにトレーニングされる際に分類に寄与した、アルゴリズムにより使用されたデータの特徴、属性の寄与を調べた。
【0139】
分類モデルは、グラウンドトゥルースとして判定者合意決定を使用して過去のＣＶＯＴデータでトレーニングされた。最良性能は、虚血性脳梗塞（ＲＯＣ０．９５）及びＴＩＡ（ＲＯＣ０．９７）を分類するようにトレーニングされたモデルで観測された。虚血性脳梗塞又はＴＩＡの分類に寄与したトップランクの特徴は、現場の治験責任医師の決定又は症状の持続時間等の試験手順における事象を定義するのに使用される変数に対応する。モデル性能は試験された異なる機械学習アルゴリズムにわたり同等であり、ＸＧＢｏｏｓｔが脳卒中及びＴＩＡの両方を正しく分類することに関して検証セットで最良のＲＯＣを示す。
【0140】
したがって、結果は、機械学習が臨床試験での臨床医判定を向上させ得、又は臨床医判定に取って代わり得、効率を獲得し、臨床開発を加速化させ、信頼性を保持する可能性を持つことを示す。本発明によるモデルは、自動判定と臨床医判定との一貫性及び正解率が高い、単一のＣＶＯＴ内の虚血性脳梗塞とＴＩＡとの２項分類で良好な性能を示す。
【0141】
モデルの効能の更なる証拠として、図２３は、３つの臨床試験（ＤＥＣＬＡＲＥ、ＴＨＥＭＩＳ及びＤＡＰＡ－ＨＦ）からのデータについて実行された、幾つかのメトリック（例えば、ＡＵＣ－曲線下面積、正解率、バランス正解率、Ｆ１等）にわたるアウトカムとして心血管死を査定した場合の機械学習モデル性能を示す。
【0142】
上述したように、図２に示される３つのモジュール（事象スニファモジュール２０１、データ調和及び収集モジュール２０３、並びに自動事象判定モジュール２０５）は、機械学習モデル又はモデルのアンサンブルを利用し得る。これらのモデルは、ｂｅｒｔ、ｂｉｏｂｅｒｔ、及びｆａｓｔｔｅｘｔ等の既知のモデル及び／又はこれらの既知のモデルの適応版を含み得る。
【0143】
機械学習モデルはニューラルネットワークを含み得る。ニューラルネットワークは、深層残差ネットワーク、ハイウェイネットワーク、高密度接続ネットワーク、及びカプセルネットワークの少なくとも１つを含み得る。
【0144】
任意のそのようなタイプのネットワークでは、ネットワークは、異なる層に編成された複数の異なるニューロンを含み得る。各ニューロンは、入力データを受信し、この入力データを処理し、出力データを提供するように構成される。各ニューロンは、特定の動作を入力に対して実行するように構成し得、例えばこれは、入力データを数学的に処理することを含み得る。各ニューロンの入力データは、複数の他の先行ニューロンからの出力を含み得る。入力データに対するニューロンの動作の一環として、入力データの各ストリーム（例えば、出力をそのニューロンに提供する各先行ニューロンに１つの入力データストリーム）に重みが割り当てられる。そのように、ニューロンによる入力データの処理は、入力データの異なる項目がニューロンの全体出力により大きく又はより小さく寄与するように、重みを異なる入力データストリームに適用することを含む。例えば入力重み付けの変更の結果としてのニューロンの入力の値への調整により、そのニューロンの出力の値が変わることになり得る。各ニューロンからの出力データは、複数の後続ニューロンに送信し得る。
【0145】
ニューロンは層に編成される。各層は、前層内のニューロンの出力から提供されたデータに対して動作する複数のニューロンを含む。各層内に、多数の異なるニューロンがあり得、各ニューロンは異なる重みを入力データに適用し、異なる動作を入力データに対して実行する。層内の全てのニューロンの入力データは同じであってよく、ニューロンからの出力は後続層内のニューロンに渡される。
【0146】
異なる層内のニューロン間の厳密なルーティングは、カプセルネットワークと深層残差ネットワーク（ハイウェイネットワーク及び高密度接続ネットワーク等のバリアントを含む）との間の主要な違いを形成する。
【0147】
残差ネットワークの場合、層は、ネットワークが複数のブロックを含み、各ブロックが少なくとも１つの層を含むように、ブロックに編成し得る。残差ネットワークの場合、ニューロンのある層からの出力データは、２つ以上の異なるパスを辿り得る。従来のニューラルネットワーク（例えば畳み込みニューラルネットワーク）の場合、ある層からの出力データは次層に渡され、これは、ネットワークの終わりまで続き、したがって、各層は、直前の層から入力を受け取り、出力を直後の層に提供する。しかしながら、残差ネットワークの場合、層間に異なるルーティングが生じ得る。例えば、ある層からの出力は複数の異なる後続層に渡すことができ、ある層の入力は複数の異なる前層から受け取ることができる。
【0148】
残差ネットワークでは、ニューロンの層は異なるブロックに編成し得、各ブロックはニューロンの少なくとも１つの層を含む。ブロックは、前の一層（又は複数の層）の出力が次の層ブロックの入力に供給されるように、一緒に積層された層で構成し得る。残差ネットワークの構造は、あるブロック（又は層）からの出力が、その直後のブロック（又は層）及び少なくとも１つの他の後続ブロック（又は層）の両方に渡されるようなものであり得る。データをある層（又はブロック）から別の層（又はブロック）に、それら２つの間にある他の層（又はブロック）を迂回しながら渡すショートカットをニューラルネットワークに導入することができる。これにより、例えば非常に深いネットワークに対処する場合、ネットワークのより効率的なトレーニングが可能になり得、その理由は、ネットワークをトレーニングするとき、劣化に関連する問題に対処できるようになるためである（より詳細に後述する）。残差ニューラルネットワークの構成は、ある層又は層ブロックに提供された同じ入力が少なくとも１つの他の層又は層ブロックに提供される（例えば、他の層が、その１つの層又は層ブロックからの入力データ及び出力データの両方に対して動作し得るよう）ように、分岐の発生を可能にし得る。この構成により、バックプロパゲーションアルゴリズムを使用してネットワークをトレーニングする場合、ネットワークへのより深い侵入が可能になり得る。例えば、これは、学習中、層又は層のブロックを入力、前の層／ブロックの入力、及び前の層／ブロックの出力としてとることが可能であり得、ネットワークの重みを更新するとき、ショートカットを使用してより深い侵入を提供し得るためである。
【0149】
カプセルネットワークの場合、層は他の層の内部に入れ子されて、「カプセル」を提供し得る。異なるカプセルは、他のカプセルよりも異なるタスクの実行により熟練するように構成し得る。カプセルネットワークは、所与のタスクで、そのタスクが、そのタスクの処理に最も有能なカプセルに割り当てられるように、カプセル間に動的ルーティングを提供し得る。例えば、カプセルネットワークは、層内のあらゆるニューロンから次層内のあらゆるニューロンに出力をルーティングするのを回避し得る。低レベルのカプセルは、その入力に対処する可能性が最も高いカプセルであると判断されたより高レベル（後続）のカプセルに入力を送信するように構成される。カプセルは、より高い層のカプセルの活動を予測し得る。例えば、カプセルはベクトルを出力し得、ベクトルの向きは、問題となっているオブジェクトの性質を表す。これに応答して、各後続カプセルは、出力として、カプセルが識別するようにトレーニングされたオブジェクトが入力データに存在する確率を提供し得る。情報（例えば確率）はカプセルにフィードバックすることができ、カプセルは次いでルーティング重みを動的に決定し、そのデータの処理に適切なカプセルである可能性が最も高い後続カプセルに入力データを転送することができる。
【0150】
何れのタイプのニューラルネットワークでも、異なる機能を有する複数の異なる層を含み得る。ニューラルネットワークは、その高さ及び幅にわたり入力データを畳み込むように構成された少なくとも１つの畳み込み層を含み得る。ニューラルネットワークは複数のフィルタリング層を有することもでき、その各々は、入力データの異なる部分にフォーカスし、フィルタを適用するように構成された複数のニューロンを含む。入力データを処理するために、最大プーリング及びグローバル平均プーリング、正規化線形ユニット層（ＲｅＬＵ）及び損失層等のプーリング層（非線形性を導入するため）等の他の層が含まれてもよく、例えば、そのうちの幾つかは正則化関数を含み得る。層の最終ブロックは、最後の出力層（又は分岐が存在する場合、より多くの層）から入力を受信し得る。最終ブロックは少なくとも１つの全結合層を含み得る。
【0151】
最終出力層は、ｓｏｆｔｍａｘ、ｓｉｇｍｏｉｄ、又はｔａｎｈ分類器等の分類器を含み得る。異なる分類器が異なるタイプの出力に適し得、例えば、出力がバイナリ分類器である場合、ｓｉｇｍｏｉｄ分類器が適し得る。ニューラルネットワークの出力は、確率の指示を提供し得る。
【0152】
入力は、ニューラルネットワーク内の１組の３Ｄ層に供給し得る。ネットワークのトレーニングが進むにつれて変わり得るこのネットワークの幾つかの特徴がある。各ニューロンに複数の重みがあり得、各重みは、前の層におけるニューロンからの出力データの各入力ストリームに適用される。これらの重みは変数であり、ニューラルネットワークの出力に変更を提供するように変更することができる。これらの重みは、より正確なデータを提供するように、トレーニングに応答して変更し得る。これらの重みをトレーニングしたことに応答して、変更された重みは「学習」したと呼ばれる。さらに、層のサイズ及び接続性は、ネットワークの典型的な入力データに依存し得るが、これらも変数であり得、接続の補強を含め、トレーニング中に変更し学習し得る。
【0153】
例えば重みの値を学習するようにネットワークをトレーニングするために、これらの重みには初期値が割り当てられる。これらの初期値は基本的にランダムであり得るが、ネットワークのトレーニングを改善するために、Ｘａｖｉｅｒ／Ｇｌｏｒｏｔ初期化等の値に適した初期化を適用し得る。そのような初期化は、初期のランダム重みが大きすぎるか、又は小さすぎる状況の発生を阻止し得、ニューラルネットワークは、これらの初期偏見を解消するようには決して適宜トレーニングすることができない。このタイプの初期化は、ゼロ平均を有するが、一定の分散を有する分布を使用して重みを割り当てることを含み得る。
【0154】
重みが割り当てられると、トレーニングオブジェクトデータをニューラルネットワークに供給し又は入力し得る。これは、図６を説明したときに先に参照したように、前の臨床試験判定決定の結果でニューラルネットワークを動作させることを含み得る。このプロセス中、ミニバッチ勾配降下、ＲＭＳｐｒｏｐ、Ａｄａｍ、Ａｄａｄｅｌｔａ、及びＮｅｓｔｅｒｏｖ等のアルゴリズムを使用し得る。これにより、ネットワークにおける異なる各点（ニューロン）又はパス（後続層におけるニューロン間）が、不正確なスコアに寄与する量を識別することができ、したがって、行う必要がある任意の重み調整を決定できるようになる。次いで、計算された誤差に従って重みを調整し得る。例えば、不正確な特定に寄与又は最も寄与するニューロンからの寄与を最小化又は除去するように。
【0155】
ネットワークのトレーニング反復後、重みを更新し得（７５０）、このプロセスは多数回繰り返すことができる。ネットワークを過学習する尤度を抑制するために、学習速度及びモーメンタム等のトレーニング変数は変更可能であり及び／又は選択された値に制御し得る。さらに、Ｌ２又はドロップアウト等の正則化技法を使用し得、正則化技法は、他の類似データに一般に適用可能にならずに、他の異なる層が過学習されてトレーニングデータに特異的になりすぎる尤度を下げる。同様に、バッチ正規化を使用して、トレーニングを支援し、正確性を改善し得る。一般に、重みは、ネットワークが、同じトレーニングデータで再び動作する場合、予期される結果を生成するように調整される。しかし、これが当てはまる範囲は、学習速度等のトレーニング変数に依存することになる。
【0156】
ニューラルネットワークの深さを上げると、例えば勾配消失問題に起因して、トレーニング時に問題が生じる恐れがあるとともに、より遅いネットワークも提供することを理解されたい。しかしながら、本開示は、ネットワークを適宜トレーニングする能力を犠牲にすることなく、深さ及び正確性を上げたネットワークの提供を可能にし得る。
【0157】
使用されるネットワークの深さは、正確性と出力の提供にかかる時間とのバランスを提供するように選択し得る。ネットワークの深さを上げると、より高い正確性を提供することができるが、出力の提供にかかる時間も増大し得る。分岐構造の使用（畳み込みニューラルネットワークとは対照的に）は、ネットワークの深さが上がり、ネットワークの正確性増大を提供するため、ネットワークの十分なトレーニングを行えるようにし得る。
【0158】
図２４は、本開示の１つ又は複数の実施形態を実施するのに適したコンピュータシステム２６００のブロック図である。種々の実施態様では、コンピュータシステム２６００は、無線通信用に構成されたモバイルセルラ電話、パーソナルコンピュータ（ＰＣ）、ラップトップ、ウェアラブル計算デバイス、タブレット等のユーザデバイスを含み得る。しかしながら、幾つかの例では、本開示の実施形態は、クラウドにおいてリモートサーバで実施されてもよく、図２４に示される同様の機能がリモートサーバにより提供されてもよいことも理解されよう。
【0159】
コンピュータシステム２６００は、情報データ、信号、及び情報をコンピュータシステム２６００の種々のコンポーネント間で通信するためのバス２６１２又は他の通信機構を含む。コンポーネントは、キーパッド／キーボードからのキーの選択、１つ又は複数のボタン又はリンク等の選択等のユーザ（即ち送信者、受信者、サービス提供者）動作を処理し、対応する信号をバス２６１２に送信する入出力（Ｉ／Ｏ）コンポーネント２６０４を含む。Ｉ／Ｏコンポーネント６０４は、ディスプレイ２６０２及びカーソル制御機構２６０８（キーボード、キーパッド、マウス等）等の出力コンポーネントを含むこともできる。ディスプレイ２６０２は、ユーザアカウントにログインするためのログインページ又は業者から物品を購入するためのチェックアウトページを提示するように構成し得る。任意選択的なオーディオ入出力コンポーネント２６０６も含まれて、オーディオ信号を変換することにより情報を入力するために音声をユーザが使用できるようにし得る。オーディオＩ／Ｏコンポーネント２６０６は、ユーザがオーディを聞けるようにし得る。送受信機又はネットワークインタフェース２６２０は、ネットワーク２６２２を介して、コンピュータシステム２６００と別のユーザデバイス、業者サーバ、又はサービス提供者サーバ等の他のデバイスとの間で信号を送受信する。一実施形態では、伝送は無線であるが、他の伝送媒体及び方法も適し得る。プロセッサ２６１４は、マイクロコントローラ、デジタル信号プロセッサ（ＤＳＰ）、又は他の処理コンポーネントであることができ、例えばコンピュータシステム２６００に表示するため又は通信リンク２６２４を介して他のデバイスに送信するためにこれらの種々の信号を処理する。プロセッサ２６１４は、他のデバイスへのクッキー又はＩＰアドレス等の情報の送信を制御することもできる。
【0160】
コンピュータシステム２６００のコンポーネントは、システムメモリコンポーネント２６１０（例えばＲＡＭ）、静的ストレージコンポーネント２６１６（例えばＲＯＭ）、及び／又はディスクドライブ２６１８（例えば固体状態ドライブ、ハードドライブ）も含む。コンピュータシステム６００は、システムメモリコンポーネント２６１０に含まれる１つ又は複数の命令シーケンスを実行することにより、プロセッサ６１４及び他のコンポーネントにより特定の動作を実行する。
【0161】
論理はコンピュータ可読媒体に符号化し得、コンピュータ可読媒体は、命令を実行のためにプロセッサ２６１４に提供することに参加する任意の媒体を指し得る。そのような媒体は、限定ではなく、不揮発性媒体、揮発性媒体及び伝送媒体を含め、多くの形態をとり得る。種々の実施態様では、不揮発性媒体は光又は磁気ディスクを含み、揮発性媒体はシステムメモリコンポーネント２６１０等のダイナミックメモリを含み、伝送媒体は、バス２６１２を構成するワイヤを含め、同軸ケーブル、銅線、及び光ファイバを含む。一実施形態では、論理は非一時的コンピュータ可読媒体に符号化される。一例では、伝送媒体は、電波、光学、及び赤外線データ通信中に生成されるもの等の音響波又は光波の形態をとり得る。
【0162】
幾つかの一般的な形態のコンピュータ可読媒体には、例えば、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープ、任意の他の磁気媒体、ＣＤ－ＲＯＭ、任意の他の光学媒体、パンチカード、紙テープ、穴のパターンを有する任意の他の物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、フラッシュＥＰＲＯＭ、任意の他のメモリチップ若しくはカートリッジ、又はコンピュータが読み取るように構成された任意の他の媒体がある。
【0163】
本開示の種々の実施形態では、本開示を実施する命令シーケンスの実行はコンピュータシステム２６００により実行し得る。本開示の種々の他の実施形態では、通信リンク２６２４によりネットワーク（例えばＬＡＮ、ＷＬＡＮ、ＰＴＳＮ、及び／又は電気通信、モバイル、及びセルラ電話ネットワークを含む種々の他の有線又は無線ネットワーク）に結合される複数のコンピュータシステム２６００は、命令シーケンスを実行して、互いと連携して本開示を実施し得る。
【0164】
該当する場合、本開示により提供される種々の実施形態は、ハードウェア、ソフトウェア、又はハードウェアとソフトウェアとの組合せを使用して実施し得る。また、該当する場合、本開示の趣旨から逸脱せずに、本明細書に記載の種々のハードウェアコンポーネント及び／又はソフトウェアコンポーネントは組み合わせられて、ソフトウェア、ハードウェア、及び／又は両方を含む複合コンポーネントになり得る。該当する場合、本開示の趣旨から逸脱せずに、本明細書に記載の種々のハードウェアコンポーネント及び／又はソフトウェアコンポーネントは、ソフトウェア、ハードウェア、及び／又は両方を含むサブコンポーネントに分離されてもよい。加えて、該当する場合、ソフトウェアコンポーネントがハードウェアコンポーネントとして実施されてもよく、またこの逆も同様であることが企図される。
【0165】
プログラムコード及び／又はデータ等の本開示によるソフトウェアは、１つ又は複数のコンピュータ可読媒体に記憶し得る。本明細書において識別されたソフトウェアが、１つ又は複数の汎用又は専用コンピュータ及び／又はコンピュータシステムを使用して、ネットワーク化されて、及び／又は他の方法を使用して実施し得ることも企図される。該当する場合、本明細書に記載の種々のステップの順序は、本明細書に記載の特徴を提供するために、変更されてもよく、結合された複合ステップになってもよく、及び／又は分離されてサブステップになってもよい。
【0166】
本明細書に記載の種々の特徴及びステップは、本明細書に記載の種々の情報を記憶した１つ又は複数のメモリと、１つ又は複数のメモリ及びネットワークに結合された１つ又は複数のプロセッサとを含むシステムとして実施し得、１つ又は複数のプロセッサは、複数の機械可読命令を含む非一時的機械可読媒体として本明細書に記載のステップを実行するように動作可能であり、機械可読命令は、１つ又は複数のプロセッサにより実行されると、１つ又は複数のプロセッサに本明細書に記載のステップを含む方法並びにハードウェアプロセッサ、ユーザデバイス、サーバ、及び本明細書に記載の他のデバイス等の１つ又は複数のデバイスにより実行される方法を実行させるように構成される。
【0167】
本開示に関して、本明細書に記載される装置及び方法のその他の例及びバリエーションは、当業者には明らかであろう。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【国際調査報告】