特表 2024-510557 構成可能データの収集と処理とを用いた健康監視システム

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-03-08

(54)【発明の名称】構成可能データの収集と処理とを用いた健康監視システム

(51)【国際特許分類】

   G16H 10/60 20180101AFI20240301BHJP

【ＦＩ】

G16H10/60

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023551963

(86)(22)【出願日】2022-03-04

(85)【翻訳文提出日】2023-10-23

(86)【国際出願番号】 GB2022050578

(87)【国際公開番号】W WO2022185072

(87)【国際公開日】2022-09-09

(31)【優先権主張番号】17/194,043

(32)【優先日】2021-03-05

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

(31)【優先権主張番号】17/194,058

(32)【優先日】2021-03-05

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

(31)【優先権主張番号】17/194,063

(32)【優先日】2021-03-05

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

(31)【優先権主張番号】17/194,073

(32)【優先日】2021-03-05

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

(31)【優先権主張番号】21186178.6

(32)【優先日】2021-07-16

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

(31)【優先権主張番号】21186184.4

(32)【優先日】2021-07-16

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

(31)【優先権主張番号】21186186.9

(32)【優先日】2021-07-16

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

(31)【優先権主張番号】21186194.3

(32)【優先日】2021-07-16

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

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

２．ＵＮＩＸ

(71)【出願人】

【識別番号】520233043

【氏名又は名称】コネクサ ヘルス インコーポレイテッド

(74)【代理人】

【識別番号】100141173

【弁理士】

【氏名又は名称】西村 啓一

(72)【発明者】

【氏名】ケリー ピーター ジョン

(72)【発明者】

【氏名】エリス ロバート デイビッド

(72)【発明者】

【氏名】フェルドマン ジョシュ

(72)【発明者】

【氏名】イム ファニータ

【テーマコード（参考）】

5L099

【Ｆターム（参考）】

5L099AA22

(57)【要約】

【解決手段】
健康関連データを取得するユーザデバイスにおいて行われるコンピュータ実装方法は開示される。方法は、通信ネットワーク上で健康監視システムからデータ収集構成を受信することを含んで、データ収集構成は、ユーザデバイスにおいて行われるデータ収集動作のスケジュールを定めたスケジュールデータを備えて、各データ収集動作は、それぞれの健康関連データをユーザデバイスにおいて取得する動作である。スケジュールデータに基づいて、各データ収集動作が行われる目標時間は決定されて、データ収集動作は、データ収集動作について健康関連データを取得するために、データ収集動作のそれぞれの決定された目標時間に従ってユーザデバイスにおいて開始される。次いで、結果データは、取得された健康関連データに基づいて健康監視システムに送信される。
【選択図】図９Ｂ

【特許請求の範囲】

【請求項1】

健康関連データを取得するユーザデバイスにおいて行われるコンピュータ実装方法であって、前記健康関連データは、ユーザの健康を示すデータとユーザの健康を示すデータが導出され得るソースデータとのうちの１つ以上を備えて、前記方法は、
通信ネットワーク上で健康監視システムからデータ収集構成を受信することであって、前記データ収集構成は、前記ユーザデバイスにおいて行われるデータ収集動作のスケジュールを定めたスケジュールデータを備えて、前記各データ収集動作は、それぞれの前記健康関連データを前記ユーザデバイスにおいて取得する動作である、ということと、
前記スケジュールデータに基づいて、前記データ収集動作の各々について、前記データ収集動作が行われる目標時間を決定することと、
前記データ収集動作について前記健康関連データを取得するために、前記データ収集動作のそれぞれの決定された目標時間に従って前記ユーザデバイスにおいて前記データ収集動作を開始することと、
前記取得された健康関連データに基づいて結果データを前記健康監視システムに送信することと、
を含む、
ことを特徴とするコンピュータ実装方法。

【請求項2】

前記スケジュールデータは、所与のデータ収集動作について相対時間情報を指定して、前記所与のデータ収集動作について前記目標時間を決定することは、
基準時間を決定することと、
前記基準時間と、前記スケジュールデータにおいて指定される前記相対時間情報と、に基づいて前記目標時間を計算することと、
を含んで、前記相対時間情報は好ましくは、前記目標時間を取得するために前記決定された基準時間に追加される期間を定める、
請求項１記載のコンピュータ実装方法。

【請求項3】

前記相対時間情報は、トリガイベントを指定して、前記基準時間は、前記トリガイベントの発生に基づいて決定されて、前記トリガイベントは好ましくは、イベントメッセージでイベント処理システムにより通信されるイベントであって、前記基準時間は、前記イベント処理システムからの前記イベントメッセージの受信に基づいて決定される、
請求項２記載のコンピュータ実装方法。

【請求項4】

前記スケジュールデータは、前記所与のデータ収集動作に関連付けられた動的なイベントベースのタイムスタンプを含んで、前記動的なイベントベースの前記タイムスタンプは、トリガイベントと前記トリガイベントの発生に対する期間とを指定して、前記方法は、前記トリガイベントの検出時に前記動的なイベントベースの前記タイムスタンプを解明することを含んで、前記動的なイベントベースの前記タイムスタンプの情報を解明することは、
前記トリガイベントのイベント時間と前記期間とから目標時間を計算することと、
前記計算された目標時間を前記動的なイベントベースの前記タイムスタンプに追加することと、
を含む、
請求項２または３記載のコンピュータ実装方法。

【請求項5】

前記ユーザデバイスおよび／または前記健康監視システムは、イベント処理システムを実装して、前記方法は、
前記動的なイベントベースの前記タイムスタンプから前記トリガイベントを識別することと、
前記イベント処理システムにおいて前記トリガイベントにサブスクライブすることと、
を含んで、
前記イベント処理システムから、前記指定されたトリガイベントに一致するイベントを受信することと、
前記イベントの受信に応じて、前記動的なイベントベースの前記タイムスタンプを解明することと、
を任意選択的に含む、
請求項４記載のコンピュータ実装方法。

【請求項6】

前記トリガイベントは、所定のセットのイベントから選択される名前付イベントであって、前記イベントに関連付けられたデータを任意選択的に含む、
請求項３乃至５のいずれか一項に記載のコンピュータ実装方法。

【請求項7】

前記トリガイベントは、
センサ測定値に対応するセンサイベントであって、前記センサ測定値は任意選択的に、所定の基準、例えば、センサ値閾値を満たす、前記センサイベントと、
ユーザ入力の受信を定めたユーザ入力イベントと、
前記ユーザデバイスの状態または状態の変更を識別する状態イベントと、
タイミングイベントと、
前記健康監視システムにより生成されて、前記通信ネットワーク上で前記ユーザデバイスに通信されるイベントと、
のうちの１つを備える、
請求項３乃至６のいずれか一項に記載のコンピュータ実装方法。

【請求項8】

前記所与のデータ収集動作について前記目標時間を決定することは、
前記基準時間と前記目標時間とについて、それぞれの時間オフセット、任意選択的に夏時間オフセットを決定することと、
オフセットが異なる場合に、前記オフセットに基づいて前記目標時間を修正することと、
を含む、
請求項２乃至７のいずれか一項に記載のコンピュータ実装方法。

【請求項9】

前記データ収集構成は、前記所与のデータ収集動作について、前記所与のデータ収集動作が適用可能であるデバイスおよび／またはユーザを指定する適用可能性基準を備えて、前記方法は、
前記適用可能性基準を評価することと、
前記評価に応じて前記データ収集動作をスケジュールすることおよび／または行うことと、
を含んで、前記適用可能性基準は任意選択的に、１つ以上のデバイス特性および／またはユーザ特性を含む、
請求項１乃至８のいずれか一項に記載のコンピュータ実装方法。

【請求項10】

前記スケジュールデータは、前記所与のデータ収集動作について期限の日付をさらに指定して、前記方法は、
前記データ収集動作が前記指定された期限の日付までに完了されなかったことを検出することと、
応答において、前記データ収集動作をリスケジュールすること、および／または完了されていないものとして前記データ収集動作を識別する通知を生成することと、
を含んで、
前記データ収集動作が１つ以上のリスケジューリング基準を満たすかどうかを決定することであって、前記基準は好ましくは、前記データ収集動作がリスケジュールされた回数に基づく、ということと、
前記データ収集動作が前記１つ以上のリスケジューリング基準を満たしている場合、前記データ収集動作について新しい目標時間を計算することにより、前記データ収集動作をリスケジュールすることと、
を任意選択的に含む、
請求項１乃至９のいずれか一項に記載のコンピュータ実装方法。

【請求項11】

前記スケジュールデータに基づいて、好ましくは、１つ以上の通知について指定される動的に解明可能なイベントベースのタイムスタンプに基づいて、１つ以上の通知をスケジュールして開始することであって、前記通知は任意選択的に、前記ユーザデバイスにおける出力に対するプッシュ通知または他の電子メッセージを含む、ということと、
前記スケジュールデータに基づいて前記結果データの送信についての時間をスケジュールして、前記スケジュールされた時間に前記結果データを前記健康監視システムに送信することと、
のうちの少なくとも１つを含む、
請求項１乃至１０のいずれか一項に記載のコンピュータ実装方法。

【請求項12】

前記データ収集動作を開始することは、
前記決定された目標時間に前記ユーザデバイスにより自動的に前記データ収集動作を行うことと、
前記データ収集動作を開始するように前記ユーザデバイスにおいて前記ユーザに促すことと、
前記ユーザデバイスにおいて表示されるメニューを介した前記ユーザによる選択と開始とについて前記データ収集動作を利用可能にすることと、
のうちの少なくとも１つを含む、
請求項１乃至１１のいずれか一項に記載のコンピュータ実装方法。

【請求項13】

前記データ収集動作は、１つ以上のユーザ入力ベースのデータ収集動作を備えて、前記ユーザ入力ベースのデータ収集動作は、前記ユーザデバイスのインターフェースを介して１つ以上のユーザ入力を受信することを含んで、前記取得された健康関連データは、前記受信されたユーザ入力に基づいており、前記１つ以上のユーザ入力ベースのデータ収集動作は好ましくは、
健康状態または症状質問票などの１つ以上の健康関連データ値を入力するデータ入力動作と、
ユーザインタラクションに基づくインターフェースベースのインタラクティブな健康評価と、
のうちの１つ以上を備えて、前記ユーザデバイスのユーザインターフェースを介したインタラクティブなプロンプトに応じてユーザインタラクションを検出することを任意選択的に含んで、前記方法は、１つ以上のユーザインタラクションから前記健康関連データを導出することを含む、
請求項１乃至１２のいずれか一項に記載のコンピュータ実装方法。

【請求項14】

前記データ収集動作のうちの少なくとも１つは、前記ユーザデバイスに含まれるか、または前記ユーザデバイスと通信する１つ以上のセンサからセンサデータを取得することを含んで、前記取得された健康関連データは、前記取得されたセンサデータを備える、
請求項１乃至１３のいずれか一項に記載のコンピュータ実装方法。

【請求項15】

請求項１乃至１４のいずれか一項に記載の方法を行う手段を有する、
ことを特徴とするシステムもしくはデバイス、または
実行されると、請求項１乃至１４のいずれか一項に記載の方法を行うように適合されたソフトウェアコードを備える、
ことを特徴とするコンピュータプログラムもしくはコンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、例えば、臨床研究の文脈における健康監視に関する。特定の例は、中央健康監視システムが処理する健康状態情報を収集する（スマートフォンなどの）パーソナルユーザデバイスに組み込まれるか、または接続可能なセンサの使用に関する。

【背景技術】

【0002】

スマートフォン、スマートウォッチ、パーソナルフィットネスモニタなどの最近のパーソナルコンピュータ／通信デバイスは、ユーザの健康状態を監視するのに有用な様々なセンサを含む。例えば、加速度計は、身体運動を監視するために使用され得て、赤外線センサは、心拍数を測定するために使用され得る。多くのスマートフォン製造者は、このようなセンサから収集されるデータを使用して、健康とフィットネスとの監視アプリケーションとサービスとを提供する。肺活量計、体温計などのより専門的な医療センサデバイスも利用可能であって、当医療センサデバイスは、Ｂｌｕｅｔｏｏｔｈ、Ｗｉ－Ｆｉ、または同様のものを介してスマートフォンに接続されることができ、デバイスにより生成されるセンサデータを表示して処理するためにスマートフォンを使用することができる。

【0003】

健康管理業界と臨床研究業界とで開発されたいくつかのシステムは、スマートフォンを介して病気の症状を追跡して患者と健康管理の提供者とによる使用のために中央システムにデータを送信する能力を提供する。典型的な手法は、臨床医が解釈する多くの様々な健康指標を幅広く収集することか、またはスマートフォンアプリケーションが所定のセットの指標で１つの特定の病気を追跡するために実装されるソリューションのいずれかを伴う。これは、任意の新しい健康監視アプリケーションまたは臨床研究に対するオーダーメイドのソリューションを開発する必要性に伴って、新しい問題への既存のソリューションの適応性を制限する。ユーザデバイスの健康監視能力は、効果的に利用される場合、原則的に、臨床研究と他の健康監視アプリケーションと（例えば、多発性硬化症、パーキンソン病、喘息など）に新しい機会を提供して、そのコストを低減し得るが、オーダーメイドのモバイルデバイスアプリケーションと、このようなアプリケーション用の対応するサーバ側データの収集インフラストラクチャと処理インフラストラクチャと、を開発するコストは法外に高くなる場合があり、結果としてもたらされるシステムは、多くの場合、柔軟性を欠いており、新しい病気と、複雑なスケジューリングと、試設計の展開と、新しいデバイスとセンサとの技術と、を含む要求の変更に適応することができない。

【0004】

デバイスとセンサとの技術の連続的な進化に加えて、典型的には、様々なデバイス製造者のデバイスと関連付けられたアプリケーションプログラミングインターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅｓ）とはまた、互換性のないフォーマットのデータを生成して処理して、健康監視システムへの幅広い範囲のデバイスの組込みをさらに困難にする。

【発明の概要】

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

【0005】

本発明の態様は、独立請求項に記載されて、特定の好ましい特徴は、従属請求項に記載される。追加の態様と特徴とは、特定の説明の終わりで、番号付けされた節に記載される。

【0006】

開示されるものは、健康関連データを取得するユーザデバイスにおいて行われるコンピュータ実装方法である。健康関連データは、ユーザの健康を示すデータと、ユーザの健康を示すデータが導出され得るソースデータと、のうちの１つ以上を備え得る。方法は、通信ネットワーク上で健康監視システムからデータ収集構成を受信することであって、データ収集構成は、ユーザデバイスにおいて行われるデータ収集動作のスケジュールを定めたスケジュールデータを備えて、各データ収集動作は、それぞれの健康関連データをユーザデバイスにおいて取得する動作である、ということと、スケジュールデータに基づいて、データ収集動作の各々について、データ収集動作が行われる目標時間を決定することと、データ収集動作について健康関連データを取得するために、データ収集動作のそれぞれの決定された目標時間に従ってユーザデバイスにおいてデータ収集動作を開始することと、取得された健康関連データに基づいて結果データを健康監視システムに送信することと、を含む。

【0007】

開示されるものはまた、本明細書に記載される任意の方法を行うように構成された、任意選択的に少なくとも１つのプロセッサと関連付けられたメモリとを含む手段を備える、ユーザデバイス、システム、または装置と、データ処理装置上で実行されると、本明細書に記載される任意の方法を行うように適合されたソフトウェアコードを備える非一時的コンピュータ可読媒体と、である。

【図面の簡単な説明】

【0008】

【図1】図１は、概要の研究管理システムを示す。

【図2A】図２Ａは、研究管理システムを使用して、臨床研究をセットアップして実行するプロセスを示す。

【図2B】図２Ｂは、研究管理システムを使用して、臨床研究をセットアップして実行するプロセスを示す。

【図2C】図２Ｃは、研究管理システムを使用して、臨床研究をセットアップして実行するプロセスを示す。

【図2D】図２Ｄは、研究管理システムを使用して、臨床研究をセットアップして実行するプロセスを示す。

【図2E】図２Ｅは、研究管理システムを使用して、臨床研究をセットアップして実行するプロセスを示す。

【図3】図３は、システムの構成要素をより詳細に示す。

【図4】図４は、ユーザデバイス上で実装される研究構成を示す。

【図5A】図５Ａは、異なるデバイスにわたって複数の研究をサポートするためのシステムの使用を示す。

【図5B】図５Ｂは、異なるデバイスにわたって複数の研究をサポートするためのシステムの使用を示す。

【図6A】図６Ａは、システムのデータ取込アーキテクチャを示す。

【図6B】図６Ｂは、システムのデータ取込アーキテクチャを示す。

【図6C】図６Ｃは、システムのデータ取込アーキテクチャを示す。

【図7】図７は、データ処理パイプラインを示す。

【図8】図８は、データ処理プラグインの動作を示す。

【図9A】図９Ａは、特定の健康研究についてのサーバ側の構成と処理とを示す。

【図9B】図９Ｂは、ユーザデバイス上のモバイルアプリケーションにおけるデータ収集動作のスケジューリングを含む、健康研究についてのクライアント側の構成と処理とを示す。

【図9C】図９Ｃは、ユーザデバイス上のモバイルアプリケーションにおけるデータ収集動作のスケジューリングを含む、健康研究についてのクライアント側の構成と処理とを示す。

【図10A】図１０Ａは、スケジューリングプロセスのさらなる態様を示す。

【図10B】図１０Ｂは、スケジューリングプロセスのさらなる態様を示す。

【図10C】図１０Ｃは、スケジューリングプロセスのさらなる態様を示す。

【図11】図１１は、記載された技術を実装する、ユーザデバイスと中央データ収集サーバとを示す。

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

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

データ入力動作は、患者の質問票や健康日誌などの健康関連データ値の直接的なユーザ入力に基づく。当動作では、ユーザは、主観的な症状評価、加えて、非接続デバイスを使用して取得される測定値の手動入力（例えば、従来のスケールを使用して取得される重量測定値）を含み得る特定の情報を供給するように促される。データ入力動作は、電子的な患者報告アウトカム（ｅＰＲＯ）、臨床医報告アウトカム（ＣｌｉｎＲＯ）、または同等物の形態で健康関連データの捕捉を実施してもよい。データ入力動作は、ユーザデバイスのディスプレイ上に表示される入力形態として実施されてもよく、所定のセットの入力フィールドは、（例えば、タッチスクリーンとオンスクリーンとのキーボード／手書き認識、音声認識などを使用して）、ユーザデバイスでのデータ入力を介してユーザにより入力される。

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

解明は、「量」フィールドと「単位」フィールドとにより指定される期間を基準時間（解明がトリガされた時間、すなわち、関連のトリガイベントが検出された時間）に追加することにより、（例えば、従来のＩＳＯ８６０１タイムスタンプまたは同様のものとしての）絶対時間値を計算することを含む。例えば、これは、「ｆｒｏｍ」で指定されるトリガイベントの検出により決定される基準時間プラス何らかの基本時間増分、例えば、ミリ秒に解明される時間「単位」を乗じた時間「量」として計算されてもよい。したがって、「量」フィールドと「単位」フィールドとは共に、トリガイベントの発生において絶対時間（解明日付）に解明されるトリガイベントに対する相対時間量（換言すれば、遅延期間）を指定する。解明時間は、ユーザデバイスのローカル時間または世界時間フォーマット、例えば、ＵＴＣ（協定世界時）でもよい。

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

上記の番号付けされた節に記載された様々な態様の特徴は、上記開示と整合する任意の好適な組合せで組み合わされてもよい。したがって、ある態様の従属特徴は、他の態様のいずれにも適用され得る。

【図1】

【図2A】

【図2B】

【図2C】

【図2D】

【図2E】

【図3】

【図4】

【図5A】

【図5B】

【図6A】

【図6B】

【図6C】

【図7】

【図8】

【図9A】

【図9B】

【図9C】

【図10A】

【図10B】

【図10C】

【図11】

【国際調査報告】