(57)【要約】  本発明は、異なる複数ユーザーのための臨床研究データ管理システムおよび方法を目的とする（３１ａ−ｂ）。このシステムは、ユーザーにデータベースからの情報を提供するように動作するプレゼンテーション作成メカニズム（３１ａ−ｂ）、ユーザー要求にサービスするように動作するアプリケーションコントロールおよびナビゲーション手段、ならびにシステムデータ中に常駐する情報にアクセスするように動作するデータアクセス（３１ａ−ｂ）を含む。データベースは、ユーザーデータおよび研究データを保存するように動作する（３１ａ−ｂ）。研究データは、候補データ、検体データ（３１ｂ）、イベントデータおよび少なくとも１つのデータセット（３１ａ）を含む。データセットは、メタデータを用いて定義される（３１ａ−ｂ）。データベースは、各ユーザーに関連付けられた少なくとも１つの役割を保存するように動作する（３１ａ）。
2005516286.tif 000002
【特許請求の範囲】
【請求項１】
複数ユーザーのための臨床研究データ管理システムであって、
ユーザー要求にサービスし、ユーザー要求に応じた情報をユーザーに提供するように動作するコンピュータシステムと、
コンピュータシステムに連結されたデータベースとを含み、データベースは、ユーザー要求および研究データを保存するように動作し、研究データは、候補データ、検体データ、イベントデータおよび少なくとも１つのデータセットを含み、データベースは、メタデータを用いて定義されるシステム。
【請求項２】
データベースは、予定のイベントおよび予定外のイベントに関連したデータを保存するように動作する請求項１に記載のシステム。
【請求項３】
コンピュータシステムは、少なくとも２人のユーザー間で電子メッセージを送受信するように動作する請求項１に記載のシステム。
【請求項４】
コンピュータシステムは、特定の研究に関連して特定の役割を有しているユーザー間の電子メッセージの通信を制限するように動作する請求項３に記載のシステム。
【請求項５】
候補データは、候補の複数に関連するデータを含み、検体データは、複数の検体に関連するデータを含み、システムは、各検体を候補に関連付けるように動作する請求項１に記載のシステム。
【請求項６】
ユーザーデータは、各ユーザーに関連付けられた少なくとも１つの役割を含む請求項１に記載のシステム。
【請求項７】
ユーザーデータは、各ユーザーに関連付けられた少なくとも１つの役割を含み、役割は、データモニタ、エンローラ、データエディタ、研究管理者およびシステム管理者の群から選択される請求項１に記載のシステム。
【請求項８】
役割は、データセット定義レベルにおいて与えられたデータアクセス権を定義する請求項６に記載のシステム。
【請求項９】
役割は、データ項目定義レベルにおいて与えられたデータアクセス権を定義する請求項６に記載のシステム。
【請求項１０】
役割は、データセット定義レベルおよびデータ項目定義レベルにおいて与えられたデータアクセス権を定義する請求項６に記載のシステム。
【請求項１１】
データベースは、ユーザーデータの少なくとも一部をプライバシーデータとして識別するように動作し、役割は、プライバシーデータを閲覧するユーザー能力を定義する請求項６に記載のシステム。
【請求項１２】
データベースは、データセットに関連付けられた少なくとも１つの表示フォームを含み、表示フォームは、メタデータを用いて定義される請求項１に記載のシステム。
【請求項１３】
データベースは、データセットに関連付けられた少なくとも２つの表示フォームを含み、表示フォームは、メタデータを用いて定義される請求項１に記載のシステム。
【請求項１４】
第１の表示フォームは、第１の表示装置上でデータセットを表示するようにフォーマットされ、第２の表示フォームは、第２の表示装置上でデータセットを表示するようにフォーマットされる請求項１３に記載のシステム。
【請求項１５】
第１の表示フォームは、データセットを第１の言語で表示するようにフォーマットされ、第２の表示フォームは、データセットを第２の言語で表示するようにフォーマットされる請求項１３に記載のシステム。
【請求項１６】
データベースは、アクセスされたデータに関連する情報、ユーザー、日付および時間を含むデータアクセスの監査記録を保存する請求項１に記載のシステム。
【請求項１７】
ユーザーデータまたは研究データの少なくとも一部が、暗号化されたフォーマットでデータベース中に保存される請求項１に記載のシステム。
【請求項１８】
複数ユーザーのための臨床研究データ管理方法であって、
コンピュータシステムに連結されたデータベース中にユーザーデータおよび研究データを保存するステップを含み、研究データは、候補データ、検体データ、イベントデータおよび少なくとも１つのデータセットを含み、データセットは、メタデータを用いて定義される方法。
【請求項１９】
データベースは、予定のイベントおよび予定外のイベントに関連したデータを保存するように動作する請求項１８に記載の方法。
【請求項２０】
コンピュータシステムは、少なくとも２人のユーザー間の電子メッセージを送受信するように動作する請求項１８に記載の方法。
【請求項２１】
コンピュータシステムは、特定の研究に関連して特定の役割を有しているユーザー間の電子メッセージの通信を制限するように動作する請求項２０に記載の方法。
【請求項２２】
候補データは、候補の複数に関連するデータを含み、検体データは、複数の検体に関連するデータを含み、システムは、各検体を候補に関連付けるように動作する請求項１８に記載の方法。
【請求項２３】
ユーザーデータは、各ユーザーに関連付けられた少なくとも１つの役割を含む請求項１８に記載の方法。
【請求項２４】
ユーザーデータは、各ユーザーに関連付けられた少なくとも１つの役割を含み、役割は、データモニタ、エンローラ、データエディタ、研究管理者およびシステム管理者の群から選択される請求項１８に記載の方法。
【請求項２５】
役割は、データセット定義レベルにおいて与えられたデータアクセス権を定義する請求項２３に記載の方法。
【請求項２６】
役割は、データ項目定義レベルにおいて与えられたデータアクセス権を定義する請求項２３に記載の方法。
【請求項２７】
役割は、データセット定義レベルおよびデータ項目定義レベルにおいて与えられたデータアクセス権を定義する請求項２３に記載の方法。
【請求項２８】
データベースは、ユーザーデータの少なくとも一部をプライバシーデータとして識別するように動作し、役割は、プライバシーデータを閲覧するユーザー能力を定義する請求項２３に記載の方法。
【請求項２９】
データベースは、データセットに関連付けられた少なくとも１つの表示フォームを含み、表示フォームは、メタデータを用いて定義される請求項１８に記載の方法。
【請求項３０】
データベースは、データセットに関連付けられた少なくとも２つの表示フォームを含み、表示フォームは、メタデータを用いて定義される請求項１８に記載の方法。
【請求項３１】
第１の表示フォームは、第１の表示装置上でデータセットを表示するようにフォーマットされ、第２の表示フォームは、第２の表示装置上でデータセットを表示するようにフォーマットされる請求項１８に記載の方法。
【請求項３２】
第１の表示フォームは、データセットを第１の言語で表示するようにフォーマットされ、第２の表示フォームは、データセットを第２の言語で表示するようにフォーマットされる請求項１８に記載の方法。
【請求項３３】
データベースは、アクセスされたデータに関連する情報、ユーザー、日付および時間を含むデータアクセスの監査記録を保存する請求項１８に記載の方法。
【請求項３４】
複数ユーザーのための臨床研究データ管理システムであって、
ユーザー要求にサービスし、ユーザー要求に応じた情報をユーザーに提供するように動作するコンピュータシステムと、
コンピュータシステムに連結されたデータベースとを含み、データベースは、複数の研究に関連するユーザーデータおよび研究データを保存するように動作し、研究データは、候補データ、検体データ、イベントデータおよび少なくとも１つのデータセットを含み、ユーザーデータは、各ユーザーに関連付けられた少なくとも１つの役割を含み、役割は、データセット定義レベルおよびデータ項目定義レベルの少なくとも１つにおいて与えられたデータアクセス権を定義するシステム。
【請求項３５】
複数ユーザーのための臨床研究データ管理システムであって、
ユーザー要求にサービスし、ユーザー要求に応じた情報をユーザーに提供するように動作するコンピュータシステムと、
コンピュータシステムに連結されたデータベースとを含み、データベースは、複数の研究に関連するユーザーデータおよび研究データを保存するように動作し、研究データは、候補データ、検体データ、イベントデータおよび少なくとも１つのデータセットを含み、ユーザーデータは、各ユーザーに関連付けられた少なくとも１つの役割を含み、コンピュータシステムは、特定の研究に関連して特定の役割を有しているユーザー間の電子メッセージの通信を制限するように動作するシステム。
【請求項３６】
複数ユーザーのための臨床研究データ管理システムであって、
ユーザー要求にサービスし、ユーザー要求に応じた情報をユーザーに提供するための手段と、
ユーザーデータおよび研究データを保存するためのデータベースとを含み、研究データは、候補データ、検体データ、イベントデータおよび少なくとも１つのデータセットを含み、データベースは、メタデータを用いて定義されるシステム。
【請求項３７】
複数の研究を管理するための臨床研究データ管理システムであって、システムは、ユーザー要求にサービスしユーザー要求に応じた情報をユーザーに提供するように動作するコンピュータシステムと、広範囲の研究についての研究定義プロセスを容易にする柔軟なデータベース構造を有するデータベースとを含み、
（ａ）  動的情報をユーザーに提供するように動作するプレゼンテーション作成手段と、
（ｂ）  ユーザー要求にサービスするように動作するアプリケーションコントロールおよびナビゲーション手段と、
（ｃ）  システムデータ中に常駐する情報にアクセスするように動作するデータアクセスとを含み、データベースは、ユーザーデータおよび研究データを保存するように動作し、研究データは、候補データ、検体データ、イベントデータおよび少なくとも１つのデータセットを含み、データセットは、メタデータを用いて定義されるシステム。
【請求項３８】
（ｄ）  システムデータベース中の情報へのユーザーアクセスを制限するように動作するアプリケーションおよびデータセキュリティ手段をさらに含む請求項３７に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、科学的データ管理の分野に関し、より詳細には、臨床研究を容易にするためのデータ管理システムおよび方法に関する。
【背景技術】
【０００２】
本発明は、患者関連データの専門的見解を地理的に異なる医療専門家に提供しようとするものである。例えば、実験技術者、臨床医、およびゲノム研究者が、ある個人に関する同じ情報を調べたいと望むことがあるが、各々は特別な関心も有していることがある。問題を複雑にすると、特定のデータが大きく、複製および／またはその本来のありかから移動することが高価なことがよくある。この目的のため、インターネットおよび関連する通信プラットホームのようなデータネットワークにより、医師と実験科学者との間のより大がかりな協力のための基盤、患者または被験対象をより多くの関連データと結び付け場合によっては診断から治療までの医学のワークフローに影響を与える手段が提供される。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
このシステムは、好ましくは、以下の特徴を１つ以上含んでいる。
【０００４】
・役割ベース認証および許可：ユーザーは、役割（ロール）およびその役割に関連付けられた相応のケイパビリティを定義している。例えば、ユーザーは、以下でより詳細に論じるように、特定の研究、イベント、データセットおよび質問に限定されたアクセス権を持ち得る。
【０００５】
・セキュアードシステムメッセージング：ユーザー間の通信は、ユーザーの権利に基いて限定さもなければ制限される。
【０００６】
・セキュアードデータアクセス：データへのユーザーのアクセス（例えば、読み取り／書込み特権）は、ユーザーの権利に基いて限定さもなければ制限される。データの特定項目へのユーザーのアクセスは、当該データ項目を含んでいるデータセット定義か個々のデータ項目定義のどちらか一方に関連してユーザーの役割により規制される。システムは、データアクセスに関する情報（例えば、誰が、何を、いつ…）を含む監査証跡も含み得る。
【０００７】
・さらなる研究コントロール：データ記録、患者および検体の間の関連は、正確な追跡作業が実行できるように慎重に追跡される。
【０００８】
・構造化された柔軟性：ユーザーは、予測不可能または予期せぬ情報を組織化するためのメカニズムを提供される。
【０００９】
・メタデータを用いるデータ保存：システムデータベースは、データ保存柔軟性を最大にするためにメタデータを利用し、その結果、データベース構造の修正は、研究要件の広範囲な実行のために必要とされないと想定される。
【課題を解決するための手段】
【００１０】
（発明の要旨）
本発明は、複数ユーザーのための臨床研究データ管理システムおよび方法に関する。コンピュータシステムは、ユーザー要求にサービスし、ユーザー要求に応答する情報をユーザーに提供するように動作する。データベースがコンピュータシステムに連結されている。このデータベースは、ユーザーデータおよび研究データを保存するように動作する。研究データには、候補データ、検体データ、イベントデータおよび少なくとも１つのデータセットを含む。データセットは、メタデータを用いて定義される。
【００１１】
本発明の好ましい局面においては、データベースは、予定のイベントおよび予定外のイベントに関連するデータを保存するように動作する。
【００１２】
本発明の別の好ましい局面においては、コンピュータシステムは、少なくとも２ユーザー間の電子メッセージの送受信をするように動作する。
【００１３】
本発明の別の好ましい局面においては、コンピュータシステムは、特定の研究に関して特定の役割を有するユーザー間の電子メッセージの通信を制限するように動作する。
【００１４】
本発明の別の好ましい局面においては、候補データは、複数の候補に関連するデータを含み、検体データは、複数の検体に関連するデータを含み、システムは、各検体を候補に関連付けるように動作する。
【００１５】
本発明の別の好ましい局面においては、ユーザーデータは、各ユーザーに関連付けられた少なくとも１つの役割を含む。
【００１６】
本発明の別の好ましい局面においては、役割は、データモニタ、エンローラ、データエディタ、研究管理者およびシステム管理者を含む。
【００１７】
本発明の別の好ましい局面においては、役割は、データセット定義レベルにおいて与えられたデータアクセス権を定義する。
【００１８】
本発明の別の好ましい局面においては、役割は、データ項目定義レベルにおいて与えられたデータアクセス権を定義する。
【００１９】
本発明の別の好ましい局面においては、役割は、データセット定義レベルおよびデータ項目定義レベルにおいて与えられたデータアクセス権を定義する。
【００２０】
本発明の別の好ましい局面においては、データベースは、ユーザーデータの少なくとも一部をプライバシーデータとして識別するように動作し、役割は、プライバシーデータを閲覧するためのユーザー能力を定義する。
【００２１】
本発明の別の好ましい局面においては、データベースは、データセットに関連付けられた少なくとも１つの表示フォームを含み、表示フォームは、メタデータを用いて定義される。
【００２２】
本発明の別の好ましい局面においては、データベースは、データセットに関連付けられた少なくとも２つの表示フォームを含み、表示フォームは、メタデータを用いて定義される。
【００２３】
本発明の別の好ましい局面においては、第１の表示装置上でデータセットを表示するために第１の表示フォームがフォーマットされ、第２の表示装置上でデータセットを表示するために第２の表示フォームがフォーマットされる。
【００２４】
本発明の別の好ましい局面においては、データセットを第１の言語で表示するために第１の表示フォームがフォーマットされ、データセットを第２の言語で表示するために第２の表示フォームがフォーマットされる。１つ以上の表示フォームを各々が有する多くのデータセットを有するシステムおよび方法が本発明に含まれることが理解される。
【００２５】
本発明の別の好ましい局面においては、データベースは、アクセスされたデータ、ユーザー、日付および時刻に関する情報を含むデータアクセス監査記録を保存する。
【００２６】
本発明の１つの技術的効果は、広範囲な研究の研究定義プロセスを容易にする柔軟なデータベース構造である。
【００２７】
本発明の別の技術的効果は、ユーザーデータアクセスを調整するための単純、柔軟そして安全なメカニズムを提供する役割ベースの認証および許可メカニズムである。
【００２８】
本発明の別の技術的効果は、ユーザーの権利に基づいて（例えば、ユーザーに割り当てられた役割に基づいて）ユーザー間の電子通信を限定さもなければ制限するメカニズムを提供するセキュアードシステムメッセージングである。
【００２９】
本発明の別の技術的効果は、データアクセス関連情報（例えば、誰が、何を、いつ…）を収集する監査証跡メカニズムである。これらおよびその他の技術的効果は、本明細書中の開示から容易に明らかになる。
【発明を実施するための最良の形態】
【００３０】
以下の用語は、本出願の目的のために、以下に述べるそれぞれの意味を有するものとする：
クライアント：ある種のプロトコルを用いて別のコンピュータシステムまたはプロセス（例えば、“サーバー”）のサービスを要求し、そのサーバーの応答を受け入れるプロセスコンピュータシステムまたはプロセスを一般に指す。クライアントは、クライアントサーバーソフトウェアアーキテクチャの一部である。
【００３１】
データベース：後の検索のために蓄積された情報の集まりを一般に指す。従来のデータベースは、フィールド、レコード、およびファイルで構成されている。フィールドは１個の情報であり、レコードは１つの完全なフィールドのセットであり、ファイルはレコードの集まりである。用語“データベース”は、本明細書中ではその最も広い意味（すなわち、情報の集まり）で用いられ、どのような特定の構造または実施にも限定されない。
【００３２】
データネットワーク：データ通信において共に結ばれた２つ以上のコンピュータシステムのグループを一般に指す。用語“データネットワーク”は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）ならびにイントラネット、エクストラネットおよびインターネットを含む、プロトコルから独立したどのようなタイプの有線または無線ネットワークも含む。
【００３３】
ＨＴＭＬ：ワールド・ワイド・ウェブ上のドキュメントを作成するために用いられるオーサリング言語である“ハイパーテキストマークアップ言語”を一般に意味する。ＨＴＭＬは、各種のタグおよび属性を用いてウェブドキュメントの構造およびレイアウトを定義する。
【００３４】
メタデータ：データ定義を保存するためのデータベーステーブルの第１のセットおよび実際のデータを保存するためのテーブルの第２のセットを用いるデータの保存を一般に指す。これは、対照的に、固定された属性を有するテーブルの固定されたセット中にデータを保存している。
【００３５】
ラショナルローズ（Ｒａｔｉｏｎａｌ  Ｒｏｓｅ）：ＵＭＬを利用するモデル駆動ソフトウェア開発ツールを一般に指す。
【００３６】
リレーショナルデータベース：データがテーブル中に整理されるリレーションシップモデル上に一般に構築されたデータベース。テーブル列の名称のセットは、テーブルの“スキーマ”と呼ばれる。データは、リレーショナル代数を用いて操作できる。ＳＱＬは、リレーショナルモデル上に構築されたデータベースとの通信および／または問い合わせのための標準言語である。
【００３７】
サーバー：あるサービスを他の（例えば、クライアント）プログラムへ提供するコンピュータ上で走るプログラムを一般に指す。クライアントとサーバーとの間の接続は通常、しばしばネットワーク上を通過するメッセージによって行われ、クライアントの要求およびサーバーの応答をエンコードするためにある種のプロトコルを用いる。
【００３８】
ＳＱＬ：データベースに情報を要求するための標準問い合わせ言語である“構造化照会言語”を一般に指す。
【００３９】
ＵＭＬ：開発中のオブジェクト指向システムのアーティファクトを指定、視覚化、およびドキュメント化するための方法である統一モデリング言語を一般に指す。
【００４０】
（システムアーキテクチャ）
本発明は、好ましくは、多層構成化されたウェブアプリケーションとしてデザインされる。代表的なブロック図を図１に示す。クライアント層は、好ましくは、ユーザーアクセスおよび対話を提供するプレゼンテーションおよびプレゼンテーションロジック要素で構成されている。中間層は、好ましくは、アプリケーションコントロール、ビジネスロジックおよびデータアクセスを扱う。データ層は、好ましくは、データベース管理システム（例えば、リレーショナルデータベース管理システムまたはＲＤＢＭＳ）を含む様々な企業資源を利用してアプリケーションデータを提供する。
【００４１】
ユーザーは、好ましくは、ウェブブラウザ（例えば、マイクロソフト（商標）インターネットエクスプローラ５．０＋）を用いてアプリケーションにアクセスする。ウェブインタフェースは、パーソナルコンピュータなどのネットワーク処理装置（例えば、デスクトップ／ラップトップコンピュータ、ＰＤＡ、無線装置など）を介してユーザーが発明の機能性にアクセスできるグラフィカルユーザーインタフェースを提供する。
【００４２】
図１において、用語“インターネット”および“Ｌａｎ”が付された矢印は、機能ブロックを相互接続するための代表的なデータネットワーキング方法である。本明細書中での開示に基づき、典型的なデータネットワーキング原理に基づく本発明に従うクライアント層、中間層およびデータ層の間の通信は、当業者の十分理解の範囲内にある。様々な層間のデータ通信が、いくつかのノードを横断できることおよび／または図示されない１つ以上のコンピュータシステムにより促進され得ることも理解される。
【００４３】
クライアント要求は、好ましくは、ミドルウェアインフラストラクチャーにより扱われる。このインフラストラクチャーは、ユーザーのアクションの解釈および必要なプロセスの実行を担当する。これらのプロセスは、要求されたビジネスプロセス（ロジック）および任意の情報資源対話を含む。代表的なミドルウェアインフラストラクチャーは、Ｊ２ＥＥフレームワークに基づくことができる。これは、プレゼンテーション、通信、配信、並行処理、およびトランザクション管理のようなサービスを提供する。それらがサポートするその他の代表的な技術およびアーキテクチャのメカニズムを以下の表に示す。
【００４４】
【表１】
2005516286.tif 000003
（アーキテクチャのメカニズムデザイン）
本発明において用いられる実施技術メカニズムの各々は、高レベルメカニズムデザインによって利用される。これらのデザインの各々は、データ検索、プレゼンテーション、セキュリティおよびビジネスロジックアプリケーションのキーアプリケーション要素に備えたものである。図２にこの概念が例示されている。
【００４５】
（プレゼンテーション作成）
プレゼンテーション作成メカニズムは、好ましくは、非常に動的な情報をユーザーに提供する能力を提供する。これは様々なプレゼンテーション技術を用いて達成される。これらのメカニズムは、工程管理および並行処理およびデータアクセスメカニズムに存在する他のメカニズムを利用する。このフレームワークは、ビジネスロジックに基づくデータ検索、適切なフォーマットへのそのデータの変換およびウェブプレゼンテーション要素とそのデータとの統合に備えたものである。この統合は、好ましくは、ユーザーに表示されるカスタムプレゼンテーション要素を作成するために、Ｊａｖａ（登録商標）Ｓｅｒｖｅｒ  Ｐａｇｅｓ、ＸＭＬおよびＸＳＬの組合せを用いて達成される。これらの技術を使用することにより、ユーザーに対してだけでなくそのユーザーが使用している表示装置に対してもプレゼンテーション要素をカスタマイズすることも可能になる。
【００４６】
（アプリケーションコントロールおよびナビゲーション）
アプリケーションコントロールおよびナビゲーションメカニズムは、好ましくは、ユーザー要求の実施またはサービシングに備える。これは、ソフトウェアアプリケーションによるユーザーナビゲーションの管理を含む要求にビジネスロジックを適用するためのメカニズムを含んでいる。さらに、アプリケーションコントロールおよびナビゲーションメカニズムは、複数ユーザーの管理、セキュリティルールのチェック、およびプレゼンテーション作成メカニズムによる使用に適したやり方での要求への応答のフォーマットを取り扱う。これは、好ましくは、Ｊａｖａ（登録商標）  Ｓｅｒｖｌｅｔ、Ｊａｖａ（登録商標）Ｂｅａｎｓ、およびＸＭＬの使用によって取り扱われる。
【００４７】
（データアクセス）
データアクセスメカニズムは、好ましくは、システム中にある情報にアクセスするためにデザインされる。それらは、好ましくは、データへの信頼性があり誤り許容性のあるアクセスを提供するためにトランザクションメカニズムおよび持続メカニズムを利用する。さらに、それらは、データへのアクセスに定義されるようにセキュリティルールを管理する。データアクセスメカニズムは、研究に関与しているリモートサイトからのデータのアップロードおよび検索にも備える。データアクセスメカニズムは、好ましくは、Ｊａｖａ（登録商標）Ｂｅａｎｓ、ＪＤＢＣ、およびＯｒａｃｌｅ保存された手順の組合せを用いる。さらに、データアクセスメカニズムは、データの定義を可能にするために、メタモデルアプローチを利用する。これは、非常に拡張性および柔軟性のあるデータアクセスケイパビリティに備える。
【００４８】
（アプリケーションおよびデータセキュリティ）
アプリケーションおよびデータセキュリティメカニズムは、好ましくは、多様な技術およびドメイン特有のルールに依拠している。セキュリティを管理するための主要メカニズムは、定義された役割の割り当ておよびそれらの役割に適用されるセキュリティルールである。これらのルールには、アプリケーションの一部へのアクセスだけでなく、そのシステム内でユーザーが実行できるアクティビティも含まれる。さらに、これらのルールは、ユーザーがデータのどの個別の部分にアクセスできるかおよびそのアクセスの性質を定義する。データの特定項目へのユーザーのアクセスは、当該データ項目を含むデータセット定義または個別のデータ項目定義に関連してユーザーの役割により規制される。ほとんどのケースでは、データセット定義レベルにおいて役割にデータアクセス許可を割り当てれば十分であるが、きめ細かいアクセスが必要な場合には、役割はデータ項目（フィールド）レベルにおける読み取り／書き込みアクセスを与えられることがある。データセットとデータ項目レベルとの間のアクセス権間に矛盾がある場合、データ項目レベルで与えられたアクセスが優先されるか、データセットレベルでのアクセスを無効にする。これにより、適切に指定されたユーザーのみが特定のデータにアクセスできることを保証する。
【００４９】
図３は、データアクセスの代表的な役割および関連するレベルを示す。例えば、“データモニタ（Ｄａｔａ  Ｍｏｎｉｔｏｒ）”役割は、特定データを閲覧する権利（すなわち、リードオンリーアクセス）をユーザーに与える。“エンローラ（Ｅｎｒｏｌｌｅｒ）”役割は、研究に被験対象をエンロールする権利をユーザーに与える。“データエディタ（Ｄａｔａ  Ｅｄｉｔｏｒ）”役割は、特定データの閲覧、追加および編集（すなわち、読み取り／書き込み／修正アクセス）の権利をユーザーに与える。“研究管理者（Ｓｔｕｄｙ  Ａｄｍｉｎｉｓｔｒａｔｏｒ）”役割は、ユーザーに役割を割り当てる権利をユーザーに与える。“システム管理者（Ｓｙｓｔｅｍ  Ａｄｍｉｎｉｓｔｒａｔｏｒ）”役割は、指定された役割についてシステムへのユーザーのアクセスを管理する権利をユーザーに与える。この役割は、システムへの個人のアクセスを不可または可能にする能力も提供する。（以下でより詳細に論じる）このルール／役割ベースのアプローチは、好ましくは、Ｊａｖａ（登録商標）ＢｅａｎｓおよびＯｒａｃｌｅ保存された手順を用いて実施される。その他のセキュリティ面は、様々なウェブベースのセキュリティメカニズム（すなわち、ＳＳＬ）およびＪ２ＥＥセキュリティ仕様に依存する。
【００５０】
（Ｒｅｖｉｅｗ  Ｄａｔａ（データ見直し））
Ｒｅｖｉｅｗ  Ｄａｔａデータユースケースは、データモニターにより開始され、研究のデータセットの閲覧を可能にする。このデータセットのいくつかの部分はローカルかリモートのどちらかである。（役割により定義される）アクセス特権に基づき、特定データフィールドが閲覧できる。
【００５１】
（Ａｓｓｉｇｎ  Ｒｏｌｅｓ  ｔｏ  Ｕｓｅｒｓ（ユーザーへの役割の割り当て））
Ａｓｓｉｇｎ  Ｒｏｌｅｓ  ｔｏ  Ｕｓｅｒｓユースケースは、研究管理者により開始され、特定のデータセットまたはそのセット内の要素への関連アクセス特権素を有する役割の割り当てを可能にする。このユースケースは、役割について定義されたアクセスを管理者が変更することも可能にする。１）ユーザーがすでに作られていること、および２）役割がすでに定義されていることが仮定される。
【００５２】
（Ａｄｄ  ａｎｄ  Ｅｄｉｔ  Ｓｔｕｄｙ  Ｄａｔａ（研究データの追加および編集））
Ａｄｄ  ａｎｄ  Ｅｄｉｔ  Ｓｔｕｄｙ  Ｄａｔａユースケースは、データエディタまたは患者により開始され（例えば、研究質問票のため）、このユースケースは、セキュリティ役割およびアクセス特権に基づき所定の研究−被験対象ペアについてデータセットに対するデータ追加または編集を可能にする。このユースケースは、様々なタイプの臨床および研究データセット（Ｘ線画像、遺伝子型ファイル／画像、臨床データなど）の維持を考慮している。データセットおよびデータ項目（フィールド）へのアクセスは、各データエディタに割り当てられた役割により定義される。例えば、臨床データエディタは、被験対象の全データ項目への追加／編集アクセスを有し得るのに対して、プライバシー保護法の要件のため、ゲノムデータエディタは、特定の被験対象（ヒトの場合）データ項目（性別、身長、血液型等）へのリードオンリーアクセスを有することになる。様々なデータエディタは、好ましくは、それらのドメインのみを有するデータを修正する権利を有している。例えば、ゲノムデータエディタは、ゲノムデータセットの追加／編集ができるが、臨床データセットの一部しか閲覧できない。
【００５３】
（Ｅｎｒｏｌｌ  Ｓｕｂｊｅｃｔ  ｉｎ  Ｓｔｕｄｙ（研究への被験対象エンロール））
Ｅｎｒｏｌｌ  Ｓｕｂｊｅｃｔ  ｉｎ  Ｓｔｕｄｙユースケースは、エンローラにより開始される。このユースケースは被験対象を研究にエンロールする。被験対象は事前に候補被験対象として記載されていなければならない。
【００５４】
（Ｍａｎａｇｅ  Ｕｓｅｒ  Ａｃｃｏｕｎｔ（ユーザーアカウント管理））
Ｍａｎａｇｅ  Ｕｓｅｒ  Ａｃｃｏｕｎｔユースケースは、システム管理者により開始される。このユースケースは、指定された役割についてのシステムへの個人のアクセスを管理する。このユースケースは、そのシステムへの個人のアクセスを無効または不可にする能力も提供する。
【００５５】
（Ａｓｓｉｇｎ  Ｒｏｒｅｌｓ  ｔｏ  Ｕｓｅｒｓ（ユーザーへの役割割り当て））
Ａｓｓｉｇｎ  Ｒｏｒｅｌｓ  ｔｏ  Ｕｓｅｒｓユースケースは、研究管理者により開始される。このユースケースは、指定された役割についてのシステムへの個人のアクセスを管理する。このユースケースは、個人への役割の追加／除去およびシステムへの個人のアクセスを不可または可能にする能力も提供する。
【００５６】
（Ｌｏｇｉｃａｌ  Ｖｉｅｗ（論理ビュー））
システムアーキテクチャの論理ビューは、最も重要なクラス、サービスパッケージおよびサブシステムにおけるそれらの組織化、ならびにこれらのサブシステムのレイヤへの組織化を記述する。
【００５７】
ラショナル統一プロセスは、デザインモデルおよびプロセスビューならびに任意のビジネスオブジェクトモデルおよび分析モデルを組織化するために“Ｌｏｇｉｃａｌ  Ｖｉｅｗ  ｉｎ  Ｒｏｓｅ”を用いる。
【００５８】
（アーキテクチャ概観−パッケージおよびサブシステム階層化）
図４は、論理層へのデザインモデルの組織化を示す。各層は、システムのオペレーション内に有している責任により関連付けられたパッケージ、サブシステムおよびクラスのコレクションを表す。
【００５９】
プレゼンテーション層は、ユーザーへのプレゼンテーションを作成するために使用されるメカニズムおよびクラスから成る。これは、プレゼンテーション要素を翻訳し、アプリケーションナビゲーションをコントロールするためのクラスを含んでいる。アプリケーション層は、サービスをシステムに提供する研究独立サブシステムおよびサブシステムインタフェースで構成される。これらは、データアクセスおよびビジネスロジックを含んでいる。ドメインモデル層は、データに対するすべての作成、読み取り、更新、および削除オペレーションで構成される。データモデルは、それがデータベース中に存在する際のデータテーブルの構造を表す。
【００６０】
（アーキテクチャ的に重要なモデル要素）
図５は、システムアーキテクチャの代表的な要素を示す。
【００６１】
（ＳｃｔｒＣｏｎｔｒｏｌｌｅｒ−ユーザー要求受信およびその要求への応答発信のための主要コントローラ）
アプリケーション−システムにサービスを提供する研究独立サブシステムおよびサブシステムインタフェース。これらはデータアクセスおよびビジネスロジックを含んでいる。
【００６２】
プレゼンテーション−ユーザーに対するプレゼンテーションを作成するために用いられるメカニズムおよびクラス。これは、プレゼンテーション要素を翻訳し、アプリケーションナビゲーションをコントロールするためのクラスを含んでいる。
【００６３】
（ＷｏｒｋｅｒＢｅａｎｓ−ユーザー要求処理をを扱うために用いられるＪａｖａ（登録商標）Ｂｅａｎｓ）
研究マネージャー−研究データ関連アクティビティにサービスを提供する。
【００６４】
被験対象マネージャー−研究被験対象データ関連アクティビティにサービスを提供する。
【００６５】
候補マネージャー−候補データ関連アクティビティにサービスを提供する。
【００６６】
プレゼンテーションマネージャー−プレゼンテーション装置による使用のためのデータ操作にサービスを提供する。
【００６７】
ｓｍ２Ｆｗｋ―Ｊａｖａ（登録商標）Ｓｅｒｖｌｅｔベースのナビゲーションシステムのメカニズムおよびベースクラスを提供する。
【００６８】
ユーザーマネージャー−ユーザー関連アクティビティにサービスを提供する。
【００６９】
データアクセスオブジェクト−データベースに含まれるデータのアクセス用に用いられる。
【００７０】
バリューオブジェクト−システムのドメインモデルを表すクラス。これは、全システムデータのデータメタモデルおよびＸＭＬ表現のために用いられるクラスを含む。
【００７１】
Ｕｔｉｌ−種々のアプリケーションクラスにより用いられる一般ユーティリティ。
【００７２】
メッセージマネージャー−ユーザーへの通信サービスを提供する。
【００７３】
ＪＳＰ（Ｊａｖａ（登録商標）  Ｓｅｒｖｅｒ  Ｐａｇｅｓ）−ユーザーに対するデータのグラフィックウェブプレゼンテーションを作成するために用いられる。
【００７４】
（要求処理概観）
図６は、クライアントウェブブラウザから発生した処理要求に含まれるメカニズムおよび要素の概観を表す。これらの要求は通常、システムに対する何らかのアクションの実行またはシステムからのデータの要求という形である。この図においては、実線の矢印は１つの要素から別の要素に対してなされた要求を表す。要素ライン上のボックスは、要素によりされた内部処理を表す。破線の矢印は、１つの要素から別の要素へ返送されたデータを表す。
【００７５】
ユーザーがページをシステムに要求する場合、その要求はｓｍ２Ｆｗｋサブシステムに渡され、適切なＷｏｒｋｅｒＢｅａｎが選択される。ＷｏｒｋｅｒＢｅａｎは、コントロールロジックを処理し、どのサブシステムが必要とされているかを決定する。例えば、様々なエンティティサブシステムは、実行データアクセス機能を実行し、データアクセスオブジェクトは、データベースからデータを検索し、そのデータをバリューオブジェクトおよびＸＭＬ型式に変換する。ＷｏｒｋｅｒＢｅａｎは、プレゼンテーション要件を処理し、プレゼンテーションサブシステムを介してプレゼンテーション要素を作成する。次に、ユーザー要求ページは、ｓｍ２Ｆｗｋサブシステムを介してユーザーに配信される。
【００７６】
（セキュリティアーキテクチャ（Ｓｅｃｕｒｉｔｙ  Ａｒｃｈｉｔｅｃｔｕｒｅ））
上記で論じたように、システムは、ユーザーがアクセスできるデータおよびその性質を制限するセキュリティを含んでいる。これは、適切に指定されたユーザーのみが特定データにアクセスできることを保証する。例えば、有効なユーザーのみがシステムにアクセスでき、承認されたユーザーのみがアクションを実行でき、すべてのプライバシーデータはそのデータベース中で暗号化され、承認されたユーザーにとり構成可能なセキュリティポリシーが利用可能になる。
【００７７】
（認証（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ））
認証は、本質的に、ユーザーが、システムを使用する権限を適切に与えられていることを検証するプロセスである。システムは、好ましくは、ユーザー名／パスワード認証、１２８ビット暗号化、およびネットワークセキュリティ実施の組合せを用いる。システム管理者は、好ましくは、システムにユーザーを追加するケイパビリティを持つ唯一の役割である。
【００７８】
（セキュアソケット層（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒｓ））
システム全体にわたるウェブページ上の全データは、好ましくは、１２８ビットセキュアソケット層（ＳＳＬ）プロトコルを用いて暗号化される。ＳＳＬは、ＨＴＴＰＳとしても知られるＨＴＴＰ（ハイパーテキスト転送プロトコル）に加えて実装できる。ＳＳＬは、公開／秘密キー暗号化およびデジタル証明書の実装を用いる。システムは、好ましくは、サーバー側デジタル証明書のみを用いる。
【００７９】
（ユーザー名／パスワード）
データベースに対して確認されたメインウェブページで、有効なユーザー名およびパスワードを提示することにより、そのシステム上でユーザーが確認される。この情報は、好ましくは、未認証の個人がこの機密情報を取り込むことがないように、ネットワーク上で暗号化される。
【００８０】
（一般的セキュリティ問題）
データベース（例えば、Ｏｒａｃｌｅデータベース）は、好ましくは、１つのＩＰアドレスによってのみアクセス可能である。このＩＰアドレスは、好ましくは、アプリケーションサーバー（例えば、ＷｅｂＬｏｇｉｃ）のＩＰアドレスである。好ましくは、ＷｅｂＬｏｇｉｃは、データベース中のデータにアクセスできる唯一のサーバー上に常駐する。システムアプリケーションサーバーをホストするマシンは、好ましくは、ファイアウォール装置の背後でホストされる。本明細書中の開示に基づくシステムに関連するファイアウォールハードウェアおよびソフトウェアの構成は、当業者の十分範囲内にある。本明細書中の開示に基づくシステムに関連する適切なイントラネットセキュリティ（ＤＭＺ、ＴＣＰポート、サブネットドメイン、バーチャルＬＡＮなど）の構成も、当業者の十分範囲内にある。
【００８１】
（認可（Ａｕｔｈｏｒｉｚａｔｉｏｎ））
認可は、ユーザーがひとたびシステム上で認証されると、研究管理者により指定された許可に基づき実行または閲覧することが認可されていたアクションの実行およびデータの閲覧をする能力をそのユーザーのみが有することを保証するプロセスである。
【００８２】
（役割（Ｒｏｌｅｓ））
研究管理者は、特定の研究についての役割を作成することに責任を負う。役割は、ケイパビリティおよびデータセット許可のコレクションで構成される。研究管理者は、役割名および関連したケイパビリティ、ならびに適切なデータ許可を作成できる。ひとたび研究内で役割が作成されると、次に研究管理者は、役割を１人以上のユーザーに割り当てることができる。代表的な役割定義および割り当て機能を以下で詳細に論じる。
【００８３】
（データセット）
データセットは、１グループのデータとして指定される。研究管理者は、追加／編集／削除または読み取り特権のような特定のデータセットへの許可を与えられるように役割を設定できる。役割がユーザーに割り当てられる場合、このユーザーは、その役割において研究管理者により指定されたデータセットへのこのレベルのアクセスが与えられるか、または与えられない。
【００８４】
（ケイパビリティ（Ｃａｐａｂｉｌｉｔｉｅｓ））
ケイパビリティは、システムの機能部分へマッピングする。これは、“研究エンロール（Ｅｎｒｏｌｌ  Ｓｔｕｄｙ）”のようなメニュー項目とすることができ、または“プライバシーデータ閲覧（Ｖｉｅｗ  Ｐｒｉｖａｃｙ  Ｄａｔａ）”のようなデータのグループとすることができる。あるユーザーが、ひとたび研究内での１つ以上の役割を割り当てられられると、ユーザーは、そのユーザーに割り当てられた役割についてのシステムに対する集合的ケイパビリティのすべてへのアクセスを受け取る。代表的な役割および関連する機能については、以下の表２を参照されたい。
【００８５】
【表２】
2005516286.tif 000004
表２は、代表的な役割に関連付けられるケイパビリティの代表的なグループ分けを一般的に定義している。これらおよび／またはその他の役割が、異なるケイパビリティセットに関連付け得ることが理解される。
【００８６】
（代表的なシステム機能）
（ログイン（Ｌｏｇｉｎ）機能）
図７は、本発明に従う代表的なログイン機能を示す。ユーザーは、上記で論じたようなネットワーク処理装置およびウェブブラウザを介してシステムにアクセスする。次にユーザーには、ログイン画面が表示され、この画面はユーザー名およびパスワードの入力を促す。システムはユーザー名およびパスワードを受け取り、それらを前もって保存された値と比較する。ユーザー名およびパスワードが有効である場合には、ユーザーはシステムへのアクセスが許される。好ましくは、次にユーザーには、ユーザー（アクター）、ユーザーができること（ナビゲーション）、現在の研究およびその研究内でのユーザーのケイパビリティを特定するサマリ画面が表示される。もしユーザーが自分のパスワードを忘れてしまったのであれば、システムは、好ましくは、システムへのアクセスを与えるためのメカニズムを提供する（例えば、アクセスが与えられる前に、セキュリティ質問は正しく回答されなければならない）。
【００８７】
ひとたびユーザーがログインされると、多くの機能が特定の研究に関連する。図８は、代表的な研究ホームページを示す。この研究ホームページは、基本インタフェースを提供し、その結果、以下でより詳細に論じるような研究被験対象のマネジメント、報告書、管理および登録のような研究関連タスクをユーザーが実行する。
【００８８】
（レジストラ機能（Ｒｅｇｉｓｔｒａｒ  Ｆｕｎｃｔｉｏｎ）−候補の登録）
図９は、本発明に従う代表的な候補被験対象登録機能を示す。この機能にアクセスするために、ユーザーはシステムにログインしなければならず、レジストラとしてふるまうための適切な役割および関連した権利を有していなければならない。登録機能が選択され、候補データまたは情報がシステムに入力される。候補データは、被験対象タイプ（この場合はヒト）、個人情報（例えば、名、姓、誕生日、社会保障番号、接触情報、病歴など）を含んでいる。ひとたび情報がシステムに入力されると、レジストラには確認画面が表示される。候補データがすべて正しければ、レジストラは確認ボタンをクリックし、候補データはシステムデータベースに保存される。システムは、好ましくは、すべての必要なデータフィールドを識別し、候補データを保存する前に、これらのフィールドへのデータ入力を要求し、それによって候補を登録する（研究における後のエンロールメントのために）。
【００８９】
（レジストラ機能（Ｒｅｇｉｓｔｒａｒ  Ｆｕｎｃｔｉｏｎ）−検体登録）
図１０は、本発明に従う代表的な検体登録機能を示す。上記で論じたように、登録機能が選択され、検体データまたは情報がシステムに入力される。検体データは、被験対象タイプ（この場合は検体）、関連する被験対象、関連する検体、医療機関、所在地、受け入れ日付、生成日付、重量などを含む。このシステムは、好ましくは、関連する被験対象および／または検体の同定を容易にするための検索機能を提供する。代表的な検索画面が図１１に示してある。好ましくは、システム中に保存されたデータまたは情報の検索は、キーワード、候補または患者データ、研究データなどに基づいて実行できる。ひとたび情報がシステムに入力されると、レジストラに確認画面が表示される。検体データがすべて正しければ、レジストラは確認ボタンをクリックし、検体データはシステムデータベースに保存される。システムは、好ましくは、すべての必要なデータフィールドを識別し、候補データを保存する前に、これらのフィールドのデータ入力を要求し、それによって検体を登録する。
【００９０】
（研究管理者機能−エンロールメントを開く）
図１２は、本発明に従う代表的なエンロールメントを開く機能を示す。この機能にアクセスするために、ユーザーはシステムにログインしなければならず、研究管理者としてふるまうための適切な役割および関連する権利を有していなければならない。エンロールメントが開かれる前に、１つ以上の研究が前もって定義され、（エンロールメントが閉じられた）システムに入力されなければならないことが理解される。エンロールメントを開く機能が選択され、次に適切な研究（これについてエンロールメントが開かれる）が特定される。研究管理者は、エンローラの数、コントロール情報、開始日付などのエンロールメントデータ（情報または基準）を入力するように促される。ひとたび登録データがシステムに入力されると、研究管理者には確認画面が表示される。エンロールメントデータがすべて正しければ、研究管理者は確認ボタンをクリックし、エンロールメントデータはシステムデータベースに保存される。システムは、好ましくは、すべての必要なデータフィールドを識別し、登録データを保存する前に、これらのフィールドのデータ入力を要求する。
【００９１】
（研究管理者機能−エンロールメントを閉じる）
図１３は、本発明に従う代表的なエンロールメントを閉じる機能を示す。この機能にアクセスするために、ユーザーはシステムにログインしなければならず、研究管理者としてふるまうための適切な役割および関連する権利を有していなければならない。エンロールメントが閉じられる前に、１つ以上の研究が前もって定義され、（エンロールメントを開いた）システムに入力されなければならないことが理解される。エンロールメントを閉じる機能が選択され、次に適切な研究（これについてエンロールメントが閉じられる）が特定される。研究管理者は、エンロールメントなどを閉じる理由を含むエンロールメントデータを閉じるように促される。ひとたびエンロールメントを閉じるデータがシステムに入力されたら、研究管理者には、エンロールメントが閉じられることを確認する確認画面が表示される。
【００９２】
（研究管理者機能−役割定義）
図１４ａおよび１４ｂは、本発明に従う代表的な役割定義機能を示す。この機能にアクセスするために、ユーザーはシステムにログインしなければならず、研究管理者としてふるまうための適切な役割および関連する権利を有していなければならない。役割が割り当てられる前に、１つ以上の研究が前もって定義され、システムに入力されなければならないことが理解される。管理タブそして次に役割タブが選択される。次に研究管理者は、役割を定義する研究を（例えば、ドロップダウンリストにより）指定できる。次に研究管理者には、選択された研究に関連して定義される役割のリスト（もしあれば）が提示される。研究管理者は、新たな役割の追加、既存の役割の編集、有効化および／または無効化が行える。各役割は、その役割に関連するセキュリティまたはデータアクセス権を一般に定義する関連付けられた役割データを有する。例えば、“ナース検索３（Ｒｅｓｅａｒｃｈ  Ｎｕｒｓｅ  ３）”役割は、被験対象をエンロールおよび／またはディスエンロールする権利を有することができる。ひとたび研究管理者が終了したら、実行依頼ボタンをクリックする。研究管理者には、どのような変更も確認しデータベースにその変更を保存する確認画面が表示される。
【００９３】
（研究管理者機能−ユーザーへの役割割り当て）
図１５ａおよび１５ｂは、本発明に従う代表的な役割割り当て機能を示す。この機能にアクセスするために、ユーザーはシステムにログインしなければならず、研究管理者として振る舞うための適切な役割および関連する権利を有していなければならない。役割が割り当てられる前に、１つ以上の研究が前もって定義され、システムに入力されなければならないことが理解される。管理タブそして次に割り当てタブが選択される。次に研究管理者は、役割を割り当てる研究を（例えば、ドロップダウンリストにより）指定できる。次に研究管理者は、“ユーザーにより”または“役割により”役割を割り当てることができる。“ユーザーにより”が選択されれば、ユーザーのリストが（例えば、ドロップダウンリストから）研究管理者に提示される。ひとたびユーザーが選択されると、研究管理者には、そのユーザーに割り当てられる役割のリストおよび利用可能な役割のリストが提示される。次に研究管理者は、割り当てまたは解除ボタンをそれぞれクリックして役割の割り当てまたは解除を行える。
【００９４】
“役割により”が選択されれば、研究管理者には（例えば、ドロップダウンリストから）役割のリストが提示される。ひとたび役割が選択されると、研究管理者には、選択された役割を有するユーザーのリストおよび選択された役割のないユーザーのリストが提示される。次に研究管理者は、割り当てまたは解除ボタンをそれぞれクリックして役割の割り当てまたは解除を行える。
【００９５】
ひとたび研究管理者が終了したら、実行依頼ボタンをクリックする。研究管理者には、どのような変更も確認しデータベースにその変更を保存する確認画面が表示される。
【００９６】
（研究管理者機能−ユーザー管理）
図１６ａおよび１６ｂは、本発明に従う代表的なユーザー管理機能を示す。この機能にアクセスするために、ユーザーはシステムにログインしなければならず、研究管理者としてふるまうための適切な役割および関連する権利を有していなければならない。管理タブおよびユーザータブが選択される。次に研究管理者には、定義されるユーザー（ユーザーＩＤ）のリストが（もしあれば）提示される。研究管理者は、新しいユーザーＩＤの追加、既存のユーザーＩＤの編集、有効化および／または無効化を行える。各ユーザーＩＤは、ユーザープロファイルを形成する関連付けられたユーザーデータを有している。ユーザープロファイルの編集または追加をシステム管理者が望めば、ユーザープロファイルページが提示される。ユーザーデータは、ユーザーＩＤ、名、姓、電子メールアドレス、接触情報、ユーザーに関連する研究、役割などを一般に含んでいる。ひとたび研究管理者がユーザープロファイルの追加または編集を終了すると、実行依頼ボタンをクリックする。研究管理者には、どのような変更も確認し、ユーザーデータに対するどのような変更もデータベースに保存する確認画面が表示される。
【００９７】
（エンローラ機能−研究への被験対象のエンロール）
図１７は、本発明に従う代表的な被験対象エンロールメント機能を示す。この機能にアクセスするために、ユーザーはシステムにログインしなければならず、エンローラとしてふるまうための適切な役割および関連する権利を有していなければならない。被験対象がエンロールされる前に、１つ以上の研究が前もって定義され、（開かれたエンロールメントを有する）システムに入力されなければならないことが理解される。１つ以上の候補がシステムに前もって登録されていなければならないことも理解される。エンローラは、適切な研究を最初に選択し、研究にエンロールする候補を特定する。好ましくは、システムに保存されたデータまたは情報の検索は、候補の姓の最初の３文字などのようなキーワードに基づいて実行できる。ひとたび候補が特定されたら、エンローラはエンロールボタンをクリックし、研究への候補のエンロールプロセスを開始できる。
【００９８】
次にエンローラには、研究定義により事前に決定されている研究基準を定義する質問表が提示される。研究基準を満たさない候補は、研究にエンロールできない。候補が研究基準を満たせば、エンローラは、候補が同意書式に署名したことを確認するために、イエスのボタンをクリックするよう求められる。エンローラがイエスのボタンをクリックすれば、候補は、研究にエンロールされる。エンローラには、確認画面が表示され、システムデータベースは必要に応じて更新される。
【００９９】
（データエディタ機能−研究データの追加／編集）
図１８は、本発明に従う代表的な研究データの追加／編集機能を示す。この機能にアクセスするために、ユーザーはシステムにログインしなければならず、データエディタとしてふるまうための適切な役割および関連する権利を有していなければならない。１つ以上の研究が前もって定義され、システムに入力されなければならないことが理解される。データエディタは最初に、（例えば、ドロップダウンリストから）研究を選択する。データエディタは次に、高レベルおよび低レベルのデータに分けられた研究データの一部を閲覧できる。高レベルデータは、研究開始日付ステータス、説明などを含む。低レベルデータは、データセット名、最後に修正されたフィールド、ステータスフィールド、アクションフィールドなどを含む。システムは、好ましくは、データアクセス（例えば、誰が、何を、いつ…）に関する情報を含む監査証跡（ブレッドクラムトライアル：ｂｒｅａｄｃｒｕｍｂ  ｔｒｉａｌｓ）の形で、データアクセスの詳細な記録を保持する。データエディタは、所定のデータセット中の項目（例えば、所定のエンローリー（ｅｎｒｏｌｌｅｅ））を追加または編集できる。ひとたびデータが追加または入力されると、データエディタは実行依頼ボタンをクリックする。データエディタには、確認画面が表示され、システムデータベースは必要に応じて更新される。
【０１００】
（データエディタ機能−遺伝学データの追加／編集）
図１９は、本発明に従う代表的な遺伝学データ追加／編集機能を示す。この機能にアクセスするために、ユーザーはシステムにログインしなければならず、データエディタとしてふるまうための適切な役割および関連する権利を有していなければならない。１つ以上の研究が前もって定義され、システムに入力されなければならないことが理解される。データエディタは最初に、（例えば、ドロップダウンリストから）研究を選択する。データエディタは次に、適切な被験対象（検体）を検索し、その検体に関する研究データの一部（例えば、データセット名、採集日付、場所、ステータスフィールド、アクションフィールドなど）を閲覧できる。上記で論じたように、システムは、好ましくは、データアクセス（例えば、誰が、何を、いつ…）に関する情報を含む監査証跡（ブレッドクラムトライアル）の形で、データアクセスの詳細な記録を保持する。データエディタは、その検体に関連付けられた遺伝学データを追加または編集できる。ひとたびデータが追加または入力されると、データエディタは実行依頼ボタンをクリックする。データエディタには、確認画面が表示され、システムデータベースは必要に応じて更新される。
【０１０１】
（データモニタ機能−データ閲覧）
図２０は、本発明に従う代表的なデータ閲覧機能を示す。この機能にアクセスするために、ユーザーはシステムにログインしなければならず、データモニタとしてふるまうための適切な役割および関連する権利を有していなければならない。１つ以上の研究が前もって定義され、システムに入力されなければならないことが理解される。データモニタは最初に、（例えば、ドロップダウンリストから）研究を選択する。次にデータモニタには、関連する高および低レベルの詳細と共に、被験対象およびイベントのリストに構成された研究データの一部が表示される。高レベルの詳細は、研究開始日付、ステータス、説明などを含む。低レベルの詳細は、登録者、イベント、ステータスなどを含む。好ましくは、データモニタは、データアクセスを容易にために様々な基準に基づいて研究データをソートできる。データモニタは、深く閲覧（ｉｎ  ｄｅｐｔｈ  ｖｉｅｗｉｎｇ）するために特定の詳細を選択することもできる。上記で論じたように、システムは、好ましくは、データアクセス（例えば、誰が、何を、いつ…）に関する情報を含む監査証跡（ブレッドクラムトライアル）の形で、データアクセスの詳細な記録を保持する。ひとたびデータモニタが終了すると、システムデータベースは必要に応じて更新される。
【０１０２】
（データ管理者機能−データセット承認）
図２１は、本発明に従う代表的なデータセット承認機能を示す。この機能にアクセスするために、ユーザーはシステムにログインしなければならず、データ管理者としてふるまうための適切な役割および関連する権利を有していなければならない。１つ以上の研究が前もって定義され、システムに入力されなければならないことが理解される。データ管理者は最初に、（例えば、ドロップダウンリストから）研究を選択する。次にデータ管理者は、承認オプションを選択し、次に被験対象および関連するステータスを有するイベントのリストに組織された研究データの一部を提示される。データ管理者は、承認のために１つ以上の被験対象またはイベントを選択できる。ひとたびデータ管理者が完了すると、必要に応じてシステムデータベースが更新され承認確認が表示される。
【０１０３】
（データ管理者機能−データセット承認）
図２２は、本発明に従う代表的なデータセット承認（フリーズ）機能を示す。この機能にアクセスするために、ユーザーはシステムにログインしなければならず、データ管理者としてふるまうための適切な役割および関連する権利を有していなければならない。１つ以上の研究が前もって定義され、システムに入力されなければならないことが理解される。データ管理者は最初に、（例えば、ドロップダウンリストから）研究を選択する。次にデータ管理者は、承認選択を選択し、次に被験対象および関連するステータスを有するイベントのリストに組織された研究データの一部を提示される。データ管理者は、承認およびさらなる研究のために１つ以上の被験対象またはイベントを選択できる。ひとたびデータ管理者が完了すると、必要に応じてシステムデータベースが更新され確認が表示される。
【０１０４】
（データ管理者機能−編集ケイパビリティ復元）
図２３は、本発明に従う代表的な復元機能を示す。この機能にアクセスするために、ユーザーはシステムにログインしなければならず、データ管理者としてふるまうための適切な役割および関連する権利を有していなければならない。１つ以上の研究が前もって定義され、システムに入力されなければならないことが理解される。データ管理者は最初に、（例えば、ドロップダウンリストから）研究を選択する。次にデータ管理者は、復元オプションを選択し、次に被験対象および関連するステータスを有するイベントのリストに組織された研究データの一部を提示される。研究データは、中段されたステータスを有する被験対象イベントのみを含むようにフィルタリングされる。データ管理者は、復元のために１つ以上の被験対象またはイベントを選択できる。ひとたびデータ管理者が完了すると、システムデータベースは必要に応じて（例えば、被験対象またはイベントステータス情報）更新されて確認が表示される。
【０１０５】
（ユーザー間の通信−システムメール）
図２４は、本発明に従う代表的なメールメッセージセンター画面を示す。この機能にアクセスするために、ユーザーはシステムにログインしなければならず、適切な役割および関連する権利を有していなければならない。メール機能は一般に、ユーザーが新しいメッセージを投稿または送信（送出）および他のユーザーからのメッセージを読んだり閲覧（着信）できるようにする。新しいメッセージを作成するために、ユーザーは最初に、受信者を（例えば、ドロップダウンリストから）選択する。システムは、受信者リストを、適切な役割を有しているユーザー（例えば、所望の研究に関連した役割を有しているユーザー）に限定する。ユーザーは、メッセージに関して優先順位インジケータ（例えば、通常、高度、アラート…）を選択することもできる。次にユーザーは、メッセージのタイトルおよび本文を入力し、送信ボタンを押してメッセージを受信者へ送る。次にメッセージは、安全な方法で受信者へ電子的に送られる。所定の研究についてユーザーが通信できる安全な環境をシステムが提供するのが有利である。所定の研究に関連して適切な役割を筆者および受信者が割り当てられているのでない限り、その研究に関連してどのようなメッセージも送信または受信できない。ユーザーは、他のユーザーにより送られたメッセージも読むことができる。図２５は、本発明に従う代表的なメールメッセージを示す。
【０１０６】
（イベント：）
図２６は、予定のイベントの代表的なリストを示す。個々の研究は、被験対象または患者に関連する１つ以上の予期されるイベントを有することができる。この例においては、各被験対象は、初診、手術およびいくつかのフォローアップ回診を有することになる。これらのイベントは、好ましくは、その研究が定義される時点で定義される。システムは、好ましくは、被験対象に関連した最後のイベント、そのイベントのステータスおよび次回のイベントを追跡する。各イベントが起こると、予期されるイベントの完了に向けた各被験対象の進捗を反映するためにシステムデータベースは（権限を付与されたユーザーにより）更新される。
【０１０７】
最大の柔軟性を提供するために、システムは、不意または予定外のイベントを追跡するように動作可能である。好ましくは、予定外のイベントは、特定の被験対象に関連付けられる。図２７は、予定のイベントおよび予定外のイベント双方をリスト化する特定の被験対象の代表的な詳細図を示す。この例では、被験対象に関連して、２つの予定外のイベント（追加の身体的検査および手術）がすでに追加されている。
【０１０８】
別の予定外イベントを追加するために、ユーザーは、“予定外イベント追加”ボタンをクリックする。ユーザーにはデータ入力画面が提示され、予定外イベント名を入力し、実行依頼ボタンをクリックする。例えば、図２８を参照されたい。次にユーザーには確認メッセージが提示される。例えば、図２９を参照されたい。この特定の被験対象についての詳細閲覧に戻り、新たに追加された予定外のイベントはイベントリストに追加される。図３０を参照されたい。
【０１０９】
（研究オーサーシップ（Ｓｔｕｄｙ  Ａｕｔｈｏｒｓｈｉｐ））
システムと共に使用のために研究を手作業で作成またはオーサリングするためのプロセスを以下で説明する。以下に述べるステップのいくつかまたは全部が、オーサリングプロセスを支援するために自動化できることが理解される。一般に、研究のオーサリングにおける基本構成要素は、１）研究要件の収集、２）既存ソフトウェアに対するリスク／影響評価、３）データベースへの転記、４）いずれかの必要とされるソフトウェア変更の実現、５）研究参加者へロールアウトを含むが、これらに限定されるものではない。
【０１１０】
（研究要件の収集）
研究を適切にオーサリングするために必要な典型的な要件としては、参加者および関連する役割の識別、含まれるデータセットおよびドキュメント、ならびにイベントスケジュールが含まれる。好ましくは、この情報は、プロセスを支援するための質問表を用いて収集される。研究要件を収集するための代表的な質問表を、以下の表３に述べる。
【０１１１】
【表３】
2005516286.tif 000005
（既存ソフトウェアに対するリスク／影響評価）
好ましくは、上記に記載されるようなシステムは、システムソフトウェアへのどのような変更もなしで新たな研究の実施に対処できるだけの十分な柔軟性がある。表４には、既存ソフトウェアに対するリスク／影響を体系的に評価するためのいくつかの代表的な質問が示される。
【０１１２】
【表４】
2005516286.tif 000006
（好ましいシステムデータベースデザイン）
ひとたび研究要件が収集されたら、システムデータベース中に研究が取り込まれなければならない。システムは、好ましくは、広範囲の研究について研究定義プロセスを容易にする柔軟なデータベース構造を含んでいる。代表的なデータの保存に関連するときの好ましいデータベース構造の実現を以下に述べる。
【０１１３】
（データセット定義−メタデータ）
上記で論じたように、データセットはデータ項目の集まりで構成されている。データセットの構造およびデータセット内の関連付けられた全データ項目は、固定されたテーブルおよび属性によってではなくて、メタデータを用いて定義される。各データ項目は、特定のデータ型となるように定義される。データ型は、数、ストリング、および日付／時間のような典型的な数量型を含んでいる。データ型は、あらかじめ定義されたリストに値が強制的に拘束されるシングルまたはマルチ選択リストとすることができる。複数のデータ項目が、それらの応答ドメインにおいて同じ選択リストを用いる場合（例えば、多くのデータ項目は、“イエス／ノー”または“真／偽”に限定された許容できる応答を持つことがある）、選択リストは一度だけ定義されればよく、何度でも参照できる。付加的なデータ型は、大きな（最高４ＧＢ）バイナリまたは文字データを含む。大きなバイナリデータを扱うために定義されたデータ項目は、スプレッドレッドシート、プレゼンテーション、またはワードプロセッシング文書のような専用型式の文書を保存するために用いることができる。データ項目レベルのメタデータにより、文字ストリングについてのデフォルト値、最大／最小数値および型式マスクの指定が可能になる。データ項目は、要求通りかあるいは要求通りでないかのいずれかとして標示され、これにより、システムはそれらの完了テータスを得ることが可能になる。データ項目は、ヌル可能（ｎｕｌｌａｂｌｅ）またはヌル不可能（ｎｏｎ−ｎｕｌｌａｂｌｅ）としても標示される。ヌル可能データ項目は、編集および保存サイクルの間（完了ステータスの見地から要求されることがたとえあっても）ブランクのままにしておけるデータ項目である。データ項目がヌル不可能である場合には、ユーザーが次へ進む（例えば、次の画面へ進む）ことができる前に、値が存在しなければならない。
【０１１４】
（代表的なデータベーステーブル）
図３１ａおよび３１ｂは、本発明に従う代表的なデータベーステーブルを示す。添付書類Ａは、データセット定義、データセット保存、データセット表示、データアクセス、ケイパビリティ、役割およびイベントに関連して用いられるテーブル中の個々のフィールドの簡単な説明を含んでいる。様々なテーブルおよびフィールドの相互関係を以下で論じる。
【０１１５】
（代表的なデータセット定義−ＤＡＳＨフォーム）
上記で論じたように、データセットは一般にデータのグループである。システム中にデータを保存するために、最初にデータセットが定義されなければならない。システムは、データセット定義を保存するために用いられる１組のデータベーステーブルを含んでいる。データセットは単独のデータ項目を含むことができるし、あるいは多くのデータ項目を含むことができる。議論の目的のため、システムは、ＤＡＳＨ（ｄｉｓａｂｉｌｉｔｉｅｓ  ｏｆ  ｔｈｅ  ａｒｍ，  ｓｈｏｕｌｄｅｒ  ａｎｄ  ｈａｎｄ：腕、肩および手の障害）フォームまたは質問票に関して収集されたデータを保存できる。ＤＡＳＨは、上肢障害訓練において開業医を支援する規格化された質問票である。ＤＡＳＨは、Ｉｎｓｔｉｔｕｔｅ  ｆｏｒ  Ｗｏｒｋ  ＆  ＨｅａｌｔｈとＡＡＯＳ／ＣＯＭＳＳ／ＣＯＳＳ−Ｏｕｔｃｏｍｅｓ  Ｄａｔａ  Ｉｎｓｔｒｕｍｅｎｔｓとの共同作業において開発された。ＤＡＳＨ  フォームに関する追加の情報は、ｈｔｔｐ：／／ｗｗｗ．ｉｗｈ．ｏｎ．ｃａ／Ｐａｇｅｓ／Ｒｅｓｅａｒｃｈ／ＤＡＳＨ．ｈｔｍから得ることができる。
【０１１６】
一般に、ＤＡＳＨ  Ｏｕｔｃｏｍｅ  Ｍｅａｓｕｒｅは、上肢筋骨格疾患に関する障害および症状を測定するために開発された。ＤＡＳＨは一般に、被験対象の身体機能、症状およびその他の情報に関する複数の質問を含んでいる。ＤＡＳＨは一般に、研究被験対象により完結され、システムに入力されなければならない。所定の研究被験対象は一般に、研究の間に複数のＤＡＳＨフォームを完結する。典型的なＤＡＳＨフォームは、表５において以下で概説される様々なタイプの情報を要求する。
【０１１７】
【表５】
2005516286.tif 000007
ＤＡＳＨフォームは、一連の質問も含んでいる。例えば、被験対象は、複数の動作を実行する自らの能力を１から５までの尺度（１＝困難は皆無、２＝軽度の困難、３＝中等度の困難、４＝重度の困難、および５＝不可能）で評価するよう求められる。代表的なタスクとして、きついまたは新しいジャーを開ける、文字を書く、キーを回す、食事を準備する、重いドア等を押し開くなどが含まれる。これらの数値応答すべての合計が、フォーム完了の際にスコアとして集計される。
【０１１８】
システム内でのＤＡＳＨフォームの定義は以下の通り進行する。ＤＡＳＨフォームおよび関連するすべての質問および応答は、好ましくは、単独のデータセットとして定義される。従って、単独の入力またはレコードがｄａｔａｓｅｔ＿ｄｅｆｉｎｉｔｉｏｎｓテーブル中で作成される。添付書類Ａを参照されたい。レコードは、主キー、名、および説明を一般に含んでいる。典型的なＤＡＳＨフォームは、６０の情報項目を研究被験対象に要求することがある。従って、６１項目（例えば、６０の応答およびスコア）が定義されなければならない。
【０１１９】
各項目について、ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓテーブル中でレコードが作成される。各レコードは、ｄａｔａｓｅｔ＿ｄｅｆｉｎｉｔｉｏｎｓテーブルに関連する外部キー（ｓｅｔ＿ｄｅｆｎ＿ｉｄ）を有している。各レコードは、一般に自明の他のフィールドだけでなく項目を作る構成要素の数を定義するための、説明、Ｘ、およびＹ次元を有している。
【０１２０】
ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓテーブルにおいて定義された個々のレコードは、ｃｏｍｐｏｎｅｎｔ＿ｄｅｆｉｎｉｔｉｏｎｓテーブルにおいて定義された少なくとも１つの関連したレコードも有している。例えば、ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓ：ｘ＿ｄｉｍｅｎｓｉｏｎおよびｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓ：ｙ＿ｄｉｍｅｎｓｉｏｎ（所定項目について）双方が１に等しければ、単独のレコードがｃｏｍｐｏｎｅｎｔ＿ｄｅｆｉｎｉｔｉｏｎｓテーブル中で定義される。ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓ：ｘ＿ｄｉｍｅｎｓｉｏｎ＝２でありｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓ：ｙ＿ｄｉｍｅｎｓｉｏｎ＝１であれば、２つのレコードがｃｏｍｐｏｎｅｎｔ＿ｄｅｆｉｎｉｔｉｏｎｓテーブル等の中で定義される。２つの構成要素を有するデータ項目の例は血圧（収縮／拡張）である。
【０１２１】
ｃｏｍｐｏｎｅｎｔ＿ｄｅｆｉｎｉｔｉｏｎｓテーブル中の各レコードは、ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓテーブルに関連する外部キー（ｉｔｅｍ＿ｄｅｆｎ＿ｉｄ）を有している。各レコードは、一般的に自明である名、説明およびいくつかのフィールドも有している。添付書類Ａを参照されたい。ｃｏｍｐｏｎｅｎｔ＿ｄｅｆｉｎｉｔｉｏｎｓテーブル中の各レコードは、ｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓテーブル中の対応するレコードも参照する。ｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓテーブル中の各レコードは、ｃｏｍｐｏｎｅｎｔ＿ｄｅｆｉｎｉｔｉｏｎｓテーブルへ戻って関連する主キー（ｄｏｍａｉｎ＿ｉｄ）を含んでいる。ｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓテーブルは、説明、リスト選択モードおよびデータ型（例えば、ＳＴＲＩＮＧ、ＮＵＭＥＲＩＣ、ＤＡＴＥ、ＬＩＳＴ、ＢＬＯＢ（ｂｉｎａｒｙ  ｌａｒｇｅ  ｏｂｊｅｃｔ：バイナリの大きなオブジェクト）、ＣＬＯＢ（ｃｈａｒａｃｔｅｒ  ｌａｒｇｅ  ｏｂｊｅｃｔ：文字の大きなオブジェクト））を含む。
【０１２２】
上記で論じたように、いくつかのデータ項目（または構成要素）は、所定範囲の値（イエス／ノー、１〜５など）を有することできる。この場合には、対応するレコードがｄｏｍａｉｎ＿ｖａｌｕｅｓテーブル中で作成される。一般に、ｄｏｍａｉｎ＿ｖａｌｕｅｓ：ｄｏｍａｉｎ＿ｉｄフィールドは、応答ドメインへの外部キーである。ｄｏｍａｉｎ＿ｖａｌｕｅｓ：ｌａｂｅｌフィールドは、実効値のリスト（例えば、“イエス”、“ノー”、“真”、等）を含んでいる。
【０１２３】
最終的に、ｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓ：ｄａｔａ＿ｔｙｐｅフィールドは、全データセット中の全データ項目の全構成要素についてのデータ型を定義する。例えば、ＤＡＳＨフォームの“患者氏名”および“受診理由”部分は、各々がｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓ：ｄａｔａ＿ｔｙｐｅ＝ＳＴＲＩＮＧを有している別個のデータ項目に対応する。これらの項目の各々は、異なるストリング長で（ｃｏｍｐｏｎｅｎｔ＿ｄｅｆｉｎｉｔｉｏｎｓ：ｄａｔａ＿ｌｅｎｇｔｈにより）定義できる。“以前手術を受けたことがありますか”のようなＤＡＳＨ質問の場合には、単独のレコードが、ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓテーブル、ｃｏｍｐｏｎｅｎｔ＿ｄｅｆｉｎｉｔｉｏｎｓテーブルおよびｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓテーブル中で定義される。ｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓ：ｄａｔａ＿ｔｙｐｅｆｉｅｌｄ＝ＬＩＳＴおよびレコードが、ｄｏｍａｉｎ＿ｖａｌｕｅｓテーブル中で、考えられるイエスおよびノーの応答を含むｄｏｍａｉｎ＿ｖａｌｕｅｓ：ｌａｂｅｌフィールドと共に作成される。同様に、ＤＡＳＨ質問“身体部位：”は、ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓテーブル、ｃｏｍｐｏｎｅｎｔ＿ｄｅｆｉｎｉｔｉｏｎｓテーブル、ｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓテーブルおよびｄｏｍａｉｎ＿ｖａｌｕｅｓテーブル中で定義された対応する単独のレコードを有している。しかしながら、ｄｏｍａｉｎ＿ｖａｌｕｅｓ：ｌａｂｅｌフィールドは、考えられる応答である指、手首、手、前腕および肘を含んでいる。年齢またはスコアに対応するデータ項目定義は、ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎテーブル、ｃｏｍｐｏｎｅｎｔ＿ｄｅｆｉｎｉｔｉｏｎｓテーブルおよびｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓ（ｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓ：ｄａｔａ＿ｔｙｐｅ  ｆｉｅｌｄ＝ＮＵＭＢＥＲ）において定義された単独のレコードを有するであろう。ＤＯＢに対応するデータ項目定義は、ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓテーブル、ｃｏｍｐｏｎｅｎｔ＿ｄｅｆｉｎｉｔｉｏｎｓテーブル、およびｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓにおいて定義された単独のレコード（ｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓ：ｄａｔａ＿ｔｙｐｅｆｉｅｌｄ＝ＤＡＴＥ）を有するであろう。上記で論じたテーブル中で定義された同様のレコードセットを関連するｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓ：ｄａｔａ＿ｔｙｐｅｆｉｅｌｄ＝ＢＬＯＢまたはＣＬＯＢと共にそれぞれ有するバイナリまたは文字ベースファイル（例えば、ｘ線画像または文書）のようなデータ項目を他のデータセットが含み得ることが理解される。
【０１２４】
（代表的なデータセット保存−ＤＡＳＨフォーム）
データセットが定義された後、システムは、データベース中にデータセットデータ（例えば、応答）を保存するように動作可能である。添付書類Ａは、データセット保存に関連して用いられる個々のフィールドの簡単な説明を含んでいる。ＤＡＳＨフォームの例を続けると、被験対象がＤＡＳＨフォームを完了し、データがデータベースに入力されるたびに、対応するレコードのセットが、適切なデータベーステーブル中に作成される。単独のレコードがデータセットテーブル中に作成される。このテーブルは、データセットＩＤ、コレクションの日付および自明のその他のフィールドのような様々な情報を含んでいる。各データ項目（例えば、６０件の応答およびスコア）は、ｄａｔａ＿ｉｔｅｍｓテーブル中に別個のレコードを有している。このテーブルは、データ項目が編集された理由に関する注記だけでなく適切なテーブルに対するいくつかのキーを含む。
【０１２５】
ｄａｔａ＿ｉｔｅｍｓ：ｄａｔａ＿ｉｔｅｍ＿ｉｄフィールドは、ｉｔｅｍ＿ｃｏｍｐｏｎｅｎｔｓテーブルを関連させるために用いられる主キーである。このテーブルは、自明な他のフィールドだけでなく実際のデータ項目またはそのデータ項目へのポインタ（ｎｕｍｅｒｉｃ＿ｖａｌｕｅ、ｓｔｒｉｎｇ＿ｖａｌｕｅ、ｂｌｏｂ＿ｐｔｒ、ｃｌｏｂ＿ｐｔｒまたはｄａｔｅ＿ｖａｌｕｅ）を保存するためのデータ型フィールド（ＤＡＴＥ、ＬＩＳＴ、ＮＵＭＢＥＲ、ＳＴＲＩＮＧ等）を保存するためのフィールドを含んでいる。
【０１２６】
（表示フォーム）
ユーザーへのデータセットのプレゼンテーションは表示フォームにより達成される。表示フォームは、１つのデータセット定義に関連付けられており、所定の表示装置上でデータセットの対応するフィールドがどのように提示されるべきかを記述する。データセットのように、表示フォームもメタデータベースである。所定のデータセットは、各型式について別個の表示フォームを定義することにより様々な形式で提示できる。同様に、所定のデータセットは、各プラットフォームについて別個の表示フォームを定義することにより様々なプラットフォーム上で提示できる。例えば、同じデータセットは、ウェブブラウザ、ＰＤＡ、またはタッチスクリーンタブレット上で様々に表現できるであろう。同様に、同じデータセットは、適切な表示フォームをターゲットデータセット定義と単に関連付けることにより、どのような修正もすることなく、英語またはスペイン語で提示することができるであろう。
【０１２７】
上記の例を続けると、典型的なＤＡＳＨフォームは、質問および応答のいくつかのグループに再分割される。従って、表示フォームは、好ましくは、拡張されたユーザー表示のためのデータのグループ分けに対応する。
【０１２８】
（代表的なデータセット表示テーブル−ＤＡＳＨフォーム）
添付書類Ａは、フォームを生成するために用いられる代表的なテーブルを示し、このフォームを通してユーザーがデータセットにアクセスできる。各表示フォームは単独のデータセット定義に関連しているが、所定のデータセット定義は、マルチ表示フォームを定義／使用することにより様々に表示できる。
【０１２９】
ｄｉｓｐｌａｙ＿ｆｏｒｍｓテーブルは、表示フォーム名、タイプ、説明等を保存するためのフィールドを含んでいる。ｄｉｓｐｌａｙ＿ｆｏｒｍｓ：ｓｅｔ＿ｄｅｆｎ＿ｉｄフィールドは、上記で論じたｄａｔａｓｅｔ＿ｄｅｆｉｎｉｔｉｏｎｓテーブルにへの外部キーである。ｄｉｓｐｌａｙ＿ｆｏｒｍｓ：ｄｉｓｐｌａｙ＿ｆｏｒｍ＿ｉｄフィールドは、ｄｉｓｐｌａｙ＿ｇｒｏｕｐｓテーブルに関連する主キーである。このテーブルは、グループ名、シーケンス等のような表示されるデータの各グループについての１つのレコードを含んでいる。ｄｉｓｐｌａｙ＿ｇｒｏｕｐｓ：ｄｉｓｐｌａｙ＿ｇｒｏｕｐ＿ｉｄフィールドは、ｄｉｓｐｌａｙ＿ｉｔｅｍｓテーブルに関連する主キーである。
【０１３０】
ｄｉｓｐｌａｙ＿ｉｔｅｍｓテーブルは、表示されるデータセット中の各項目につき１つのレコードを含んでいる。ｄｉｓｐｌａｙ＿ｉｔｅｍｓ：ｉｔｅｍ＿ｄｅｆｎ＿ｉｄフィールドは、上記で論じたｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓテーブルへの外部キーである。ｄｉｓｐｌａｙ＿ｉｔｅｍｓ：ｐｒｅ＿ｌａｂｅｌフィールドは、実際のデータ（例えば、ＤＡＳＨフォーム上の質問への応答）を表示する前に表示されるテキストを含んでいる。ＤＡＳＨフォームの例を続けると、ＤＡＳＨフォーム上の各質問に関連するデータセット項目は、上記で述べたように定義される。これらのデータ項目の１つが、ＤＡＳＨフォーム質問“以前手術を受けたことがありますか？”への応答に関連する。従って、対応するｄｉｓｐｌａｙ＿ｉｔｅｍｓ：ｐｒｅ＿ｌａｂｅｌフィールドは、“以前手術を受けたことがありますか？”に設定される。このテキストは実際には、特定のＤＡＳＨフォームに（イエスまたはノー）に関連してデータベース中に保存された実際の応答に先行して表示される。実際のデータ（例えば、応答）に続いて表示するためのどのようなテキストも、ｄｉｓｐｌａｙ＿ｉｔｅｍｓ：ｐｏｓｔ＿ｌａｂｅｌフィールド中に保存される。典型的な記入テキストの例は、応答に関連付けられた単位に関連するテキストである（例えば、ポンド、センチメートル、度など）。別の言語での表示が求められれば、別の表示フォームは、ｄｉｓｐｌａｙ＿ｉｔｅｍｓ：ｐｒｅ＿ｌａｂｅｌおよびｄｉｓｐｌａｙ＿ｉｔｅｍｓ：ｐｏｓｔ＿ｌａｂｅｌフィールド中の適切なテキストによって定義される。様々な型式での同じデータの表示を容易にするために（例えば、ウェブブラウザ、ＰＤＡ、またはタッチスクリーン等の上で様々に表示するために）、無数の表示フォームが定義できることも理解される。
【０１３１】
（データアクセス）
特定のデータ項目へのユーザーのアクセスは、当該データ項目を含むデータセット定義または個々のデータ項目定義のいずれか一方に関連するユーザーの役割により規制される。ほとんどの場合、データセット定義レベルでのデータアクセス許可を役割に割り当てれば十分であるが、きめ細かいアクセスが必要な場合には、データ項目（フィールド）レベルでの読み取り／書き込みアクセスを役割に認めることができる。データセットとデータ項目レベルと間のアクセス権利間に矛盾がある場合、データ項目レベルで認められたアクセスはデータセットレベルでのアクセスに優先するか、これを無効にする。
【０１３２】
添付書類Ａは、データセット定義かデータ項目定義レベルのどちらか一方においてデータアクセスが役割に与えられることを可能にする代表的なデータベーステーブルを示す（ｄａｔａｓｅｔ＿ｐｒｉｖｉｌｅｇｅｓおよびｄａｔａ＿ｉｔｅｍ＿ｐｒｉｖｉｌｅｇｅｓテーブル参照）。各データセットは、役割および関連するデータアクセス特権を識別するｄａｔａｓｅｔ＿ｐｒｉｖｉｌｅｇｅｓ中の少なくとも１つのレコードを有している。ｄａｔａｓｅｔ＿ｐｒｉｖｉｌｅｇｅｓ：ｓｅｔ−ｄｅｆｎ＿ｉｄフィールドは、ｄａｔａｓｅｔ＿ｄｅｆｉｎｉｔｉｏｎｓテーブルに関連する外部キーであり、ｄａｔａｓｅｔ＿ｐｒｉｖｉｌｅｇｅｓ：ｒｏｌｅ＿ｉｄフィールドは、役割への外部キーである（以下でより詳細に論じる）。残りのフィールドは自明である。
【０１３３】
アクセスを特定のデータ項目に限定するため、必要とされる程度までレコードをｄａｔａ＿ｉｔｅｍ＿ｐｒｉｖｉｌｅｇｅｓテーブルに追加できる。ｄａｔａ＿ｉｔｅｍ＿ｐｒｉｖｉｌｅｇｅｓ：ｉｔｅｍ＿ｄｅｆｎ＿ｉｄフィールドは、ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓテーブルに関連する外部キーである。ｄａｔａ＿ｉｔｅｍ＿ｐｒｉｖｉｌｅｇｅｓ：ｒｏｌｅ＿ｉｄフィールドは、役割への外部キーである。残りのフィールドは自明である。
【０１３４】
（役割およびケイパビリティ）
各役割は、これに関連付けられた１つ以上のケイパビリティを有している。データベース内では、各役割は一意のｒｏｌｅ＿ｉｄにより識別される。種々の役割およびそれらの関連付けられたケイパビリティは、各研究について具体的に定義される。役割はアプリケーション中であらかじめ定義されないが、ケイパビリティは定義される。特定のケイパビリティは、関連付けられた役割を有するユーザーにアプリケーションの特定機能の権利を与える。ユーザーインタフェースのメニュー項目およびナビゲーションコントロールでさえも、ユーザーのケイパビリティにより影響される。
【０１３５】
同じ役割名は、複数の研究で繰り返し使用してもよいが、役割名が発生するたびに一意の役割識別子が作成される。例えば、ほとんどの研究は、“研究Ａｄｍｉｎ”と名付けられた役割を有するが、これらの役割は種々の研究において発生し、従って、別のｒｏｌｅ＿ｉｄは用いられる。好ましくは、システムは、役割作成を含む研究の様々な部分が“複製され”たりコピーされたりできるようにする。これにより、新しい役割をそれらの関連付けられたケイパビリティによって定義するといういささか退屈なタスクが簡略化される。なぜならば、役割は、１つの研究から別の研究へ容易に再現できるからである。以前に言及されたように、役割名は、システム内であらかじめ定義されず、研究および共同体管理者により定義される。しかしながら、役割に関連付けることができるケイパビリティはあらかじめ定義される。システム内の機能の多くを実行するためには、特定のケイパビリティ（それらの割り当てられた役割により）を有することをユーザーは要求される。
【０１３６】
添付書類Ａは、各研究について役割が作成されるようにし、１つ以上の役割がユーザーに与えられるようにし、役割に１つ以上のケイパビリティが関連付けられるようにする代表的なデータベーステーブルを示す。各役割は、関連付けられたレコードを役割テーブル中に有している。このテーブルは、役割名、研究等を特定するフィールドを含んでいる。ｒｏｌｅ：ｒｏｌｅ＿ｉｄフィールドは、主キーである。ｒｏｌｅ：ｓｔｕｄｙ＿ｉｄファイルは、研究テーブルに関連する外部キーである。
【０１３７】
ｒｏｌｅ＿ｃａｐａｂｉｌｉｔｉｅｓテーブルは、所定の役割に関連付けられた各ケイパビリティについて１つのレコードを含んでいる。ｒｏｌｅ：ｒｏｌｅ＿ｉｄフィールドは、役割テーブルへの外部キーである。ｒｏｌｅ：ｃａｐａｂｉｌｉｔｙ＿ｉｄフィールドは、ケイパビリティテーブルへの外部キーである。ｒｏｌｅ＿ｕｓｅｒｓテーブルは、所定の役割に関連付けられた各ユーザーについて１つのレコードを含んでいる。ｒｏｌｅ＿ｕｓｅｒｓ：ｒｏｌｅ＿ｉｄフィールドは、役割テーブルへの外部キーである。ｒｏｌｅ＿ｕｓｅｒｓ：ｕｓｅｒｎａｍｅフィールドは、ユーザーテーブルへの外部キーである。残りのフィールドは、自明である。
【０１３８】
ケイパビリティテーブルは、システム中で定義された各ケイパビリティについて１つのレコードを含んでいる。このテーブルは、ケイパビリティの名前、ケイパビリティのタイプなどを保存するためのフィールドを含んでいる。ｃａｐａｂｉｌｉｔｉｅｓ：ｃａｐａｂｉｌｉｔｙ＿ｉｄフィールドは、主キーである。上記で論じたように、様々なケイパビリティは、ケイパビリティを実行するためにアプリケーションレベルにおいて要求されるロジックと共にあらかじめ定義される。
【０１３９】
（イベント）
イベントは、研究被験対象とのある種の相互作用または禁止がある、早晩の実際の発生を指す。通常、１つ以上のデータセットがイベントに関連付けられる。イベントは、“予定の”か“予定外の”かのどちらか一方とすることができる。研究定義により禁止されたアクティビティにイベントが対応する場合、そのイベントは予定のイベントと見なされる。予期しないイベントは、予定外のイベントである。研究定義は、すべての予定のイベントのために収集されるデータセットのリストを含んでいる。
【０１４０】
研究が著される場合、予期される、または予定されるイベントのリストは知られている。データモデルにより、これらの予期されるイベントの順次配列が可能になる。このモデルは、イベントパスの分岐、および様々なパスの１つが選択される決定イベントも可能にする。
【０１４１】
添付書類Ａは、イベントの発生を記録し、ある研究についてどんなイベントが予期される（すなわち予定される）のかを定義するために用いられる代表的なデータベーステーブルを示す。
【０１４２】
イベントテーブルは、データベースに入力された各（予定のまたは予定外の）イベントについて１つのレコードを含んでいる。このテーブルは、イベント名、ステータス、日付などのためのフィールドを含んでいる。ｅｖｅｎｔ：ｅｖｅｎｔ＿ｉｄフィールドは、主キーである。ｅｖｅｎｔ：ｓｔｕｄｙ＿ｉｄフィールドは、研究テーブルへの外部キーである。ｅｖｅｎｔ：ｓｕｂｊｅｃｔ＿ｉｄフィールドは、被験対象テーブルへの外部キーである。ｓｃｈｅｄｕｌｅｄ＿ｅｖｅｎｔｓテーブルは、各予定のイベントについて１つのレコードを含んでいる。このテーブルは、イベント名、関連付けられた研究、イベントのタイプ（ｎｏｄｅ＿ｔｙｐｅおよびｂｒａｎｃｈ＿ｔｙｐｅ）などを保存するためのフィールドを有している。
【０１４３】
（被験対象および検体）
各被験対象には一意の識別子、またはｓｕｂｊｅｃｔ＿ｉｄが与えられる。臨床研究において典型的に研究される被験対象は、ヒト患者である。多くの場合、ヒト被験対象は、研究の一部として血液または組織の検体を提供できる。検体にも、一意の識別子またはｓｕｂｊｅｃｔ＿ｉｄが与えられる。検体は寄与“親”（ｃｏｎｔｒｉｂｕｔｉｎｇ  “ｐａｒｅｎｔ”）に関連付けられ、その情報が知られていれは、その検体から派生したどのような実験研究もソース被験対象まで遡及して調べることができる。検体は、複数のサンプルにさらに分割できる。各サンプルも、そのソースにまで遡及して調べることができる一意の識別子を有している。
【０１４４】
データベース内では、被験対象という用語は、広い意味で用いられ、研究の被験対象となり得るどのような実体をも指す。被験対象のこの広い定義は、以下の例、すなわち、ヒト被験対象、動物被験対象、検体、サンプル、医療装置、補綴学、死体、および細胞株に適用される。被験対象タイプの各々には、それ独自の一意のｓｕｂｊｅｃｔ＿ｉｄが割り当てられる。検体のプールでさえも被験対象と見なすことができ、従って、ｓｕｂｊｅｃｔ＿ｉｄが割り当てられる。このモデルにより、検体およびサンプルをそれらのソースに関連付けることが可能になる。このモデルにより、さもなければ匿名の構成要素で構成されるプールが、複数のソース（もし知られていれば）を有することも可能になる。
【０１４５】
（研究間での被験対象データの共有）
システムは、研究間での被験対象データの共有に任意に備えることができる。各被験対象（または検体、サンプル等）には、それ自身の一意のｓｕｂｊｅｃｔ＿ｉｄが与えられるので、その被験対象の研究データのすべてと登録データとの間には暗黙の関係がある。従って、被験対象は再登録される必要はなく、関連するデータは、各研究について再入力される必要はない。研究間での単独の被験対象のデータセットの利用は、データが当初収集された時には予見されなかった研究を実施する場合に極めて貴重なことがある。
【０１４６】
（データプライバシー）
連邦政府の要件と歩調を合わせるにあたり、許可を付与されたユーザーのみがヒト被験対象のプライバシーデータを閲覧できる。プライバシーデータは、研究被験対象または候補に関連する１つ以上の私的情報フィールドを一般に含んでいる（例えば、氏名、住所、社会保障番号、電子メールアドレスなど）。ケイパビリティ“プライバシーデータ閲覧（Ｖｉｅｗ  Ｐｒｉｖａｃｙ  Ｄａｔａ）”は、個人を識別可能なデータにアクセスできるはずのどのような共同体または研究役割にも付与できる。このケイパビリティを持たないどのようなアプリケーションユーザーに対しても、プライバシーデータはアスタリスク文字列（”＊＊＊＊＊＊＊＊＊＊”）として表示される。
【０１４７】
（データ暗号化）
種々のレベルのデータ暗号化が本発明と両立する。簡単な例では、ユーザーパスワードのみが暗号化される。ユーザーが自分のパスワードをリセットすると、そのパスワードは、（例えば、Ｏｒａｃｌｅ  ９ｉに組み込まれた）適切なデータベースユーティリティを用いて暗号化された形でデータベース内に保存される。これによって、代替手段（例えば、レポートライター、データマイニングツールなど）を介してシステムデータベースへのアクセスが万一得られる場合に、強化されたセキュリティが提供される。この場合には、データベースは、文字情報とは対照的に、暗号化された情報を含んでいる。
【０１４８】
代表的な暗号化アルゴリズムは、国防省により開発され、様々なオペレーティングシステムにいてパスワードを暗号化するために用いられるＤＥＳ（データ暗号化規格）である。ユーザーがアプリケーションへのログインを試みる場合、パスワードは暗号化され、データベース中に保存されている暗号化パスワードと比較される。所定のユーザーについて２つの暗号化パスワードが一致すれば、そのユーザーは認証されたと見なされて、アプリケーションに入ることが許される。
【０１４９】
（監査証跡）
上記で論じたように、システムは、好ましくは、特定のデータ項目のアクセスに関する情報を含む監査証跡（ブレッドクラムトライアル）の形で、データアクセスの詳細な記録を取る。監査情報は、好ましくは、複数の記録を有する少なくとも１つの監査証跡テーブル中に保持される。各記録は、データ項目の値を変更する（すなわち、データがデータベースに追加されるか、既存データが修正される）イベントに対応している。例えば、データ項目がデータベースに追加されると、監査証跡テーブル中にエントリが作成される。レコードは、好ましくは、データ項目、ユーザー、アクセス日時を特定する。データ項目が修正されるたびに、やはりデータ項目、ユーザー、アクセス日時を特定するエントリが監査証跡テーブル中に作成される。監査テーブルは、実際のデータ値も含み得る。実際のデータ値の保存により、監査テーブルは、なされた実際の変更のレコードを含む、所定のデータ項目の完全な改訂履歴を提供することが可能になる。
【０１５０】
好ましい実施の形態に重点を置いて本発明を説明してきたが、好ましい装置および方法における変形例を用いることができることおよび本明細書中で具体的に記載された以外の方法で本発明が実施できることが当業者には明らかであろう。
【０１５１】
（添付書類Ａ）
（代表的データベーステーブル）
１．  データセット定義（Ｄａｔａｓｅｔ  Ｄｅｆｉｎｉｔｉｏｎｓ）−以下のテーブルは、データセット定義の構造を定義するために用いられる。
【０１５２】
（ｄａｔａｓｅｔ＿ｄｅｆｉｎｉｔｉｏｎｓ）
ｓｅｔ＿ｄｅｆｎ＿ｉｄ−主キー
ｎａｍｅ−参照のために研究筆者により用いられる；ユーザーには表示されない
ｄｅｓｃｒｉｐｔｉｏｎ−参照のために研究筆者により用いられる；ユーザーには表示されない
（ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓ）
ｉｔｅｍ−ｄｅｆｎ＿ｉｄ−主キー
ｓｅｔ＿ｄｅｆｎ＿ｉｄ−データセット＿ｄｅｆｉｎｉｔｉｏｎｓテーブルへの外部キー
ｄｅｓｃｒｉｐｔｉｏｎ−参照のために研究筆者により用いられる；ユーザーには表示されない
ｘ＿ｄｉｍｅｎｓｉｏｎ−複合のデータ項目用；ｘ−軸成分の＃（通常１）
ｙ＿ｄｉｍｅｎｓｉｏｎ−複合のデータ項目用；ｙ−軸成分の＃（通常１）
ｒｅａｓｏｎ＿ｆｌａｇ−この項目の修正によりユーザーが理由の入力を要求される場合
ｒｅｑｕｉｒｅｄ＿ｆｌａｇ−データセットを完結するためにこの項目に記入しなければならない場合
（ｃｏｍｐｏｎｅｎｔ＿ｄｅｆｉｎｉｔｉｏｎｓ）
ｃｏｍｐ＿ｄｅｆｎ＿ｉｄ−主キー
ｉｔｅｍ＿ｄｅｆｎ＿ｉｄ−ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓテーブルへの外部キー
ｎａｍｅ−参照のために研究筆者により用いられる；ユーザーには表示されない
ｄｏｍａｉｎ＿ｉｄ−ｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓテーブルへの外部キー
ｄｅｓｃｒｉｐｔｉｏｎ−参照のために研究筆者により用いられる；ユーザーには表示されない
ｖａｌｕｅ＿ｕｎｉｔｓ−このデータ項目についての測定単位を定義する（例えば、グラム）
ｘ＿ｐｏｓｉｔｉｏｎ−ｘ−軸に沿ったマトリクスまたは配列の成分（通常１）
ｙ＿ｐｏｓｉｔｉｏｎ−ｙ−軸に沿ったマトリクスまたは配列の成分（通常１）
ｍｉｎ＿ｎｕｍｂｅｒ−数値データ、最小数が可能
ｍａｘ＿ｎｕｍｂｅｒ−数値データ、最大数が可能
ｄａｔａ＿ｐｒｅｃｉｓｉｏｎ−数のデータの有効桁数
ｄａｔａ＿ｓｃａｌｅ−数値データ小数部分桁数
ｄａｔａ＿ｌｅｎｇｔｈ−ストリングまたは数値データの長さ
ｎｕｌｌａｂｌｅ＿ｆｌａｇ−成分は、入力および編集時にブランクのままにして置くことができる
ｆｏｒｍａｔ＿ｍａｓｋ−フォーマット入力するための入力マスク（例えば、ＳＳＮ：”９９９−９９−９９９９”）
ｄｅｆａｕｌｔ＿ｖａｌｕｅ−この値で新しい項目成分をあらかじめロードする
（ｒｅｓｐｏｎｓｅ＿ｄｏｍａｉｎｓ）
ｄｏｍａｉｎ＿ｉｄ−主キー
ｄｅｓｃｒｉｐｔｉｏｎ−参照のために研究筆者により用いられる；ユーザーには表示されない
ｌｉｓｔ＿ｓｅｌｅｃｔｉｏｎ＿ｍｏｄｅ−値のリスト用（シングルまたはマルチ選択）
ｄａｔａ＿ｔｙｐｅ−ＳＴＲＩＮＧ、ＮＵＭＥＲＩＣ、ＤＡＴＥ、ＬＩＳＴ、ＢＬＯＢ（バイナリの大きいオブジェクト）等
（ｄｏｍａｉｎ＿ｖａｌｕｅｓ）
ｄｏｍａｉｎ＿ｉｄ−応答ドメインへの外部キー；主キーの一部
ｓｅｌｅｃｔｉｏｎ＿ｉｄ−主キーの一部
ｌａｂｅｌ−リスト用、実際の表示値（例えば、“Ｙｅｓ”、“Ｎｏ”、“Ｔｒｕｅ”等）
２．  データセット保存（Ｄａｔａｓｅｔ  Ｓｔｒａｇｅ）−以下のテーブルは、所定のデータセットの発生について収集された実際のデータを保存するために用いられる。
【０１５３】
（ｄａｔａｓｅｔ）
ｄａｔａｓｅｔ  ＿ｉｄ−主キー
ｓｅｔ＿ｄｅｆｎ＿ｉｄ−ｄａｔａｓｅｔ  ＿ｄｅｆｉｎｉｔｉｏｎｓへの外部キー
ｓｔｕｄｙ＿ｉｄ−研究への外部キー
ｓｕｂｊｅｃｔ＿ｉｄ−被験対象への外部キー
ｅｖｅｎｔ＿ｉｄ−イベントへの外部キー
ｄａｔｅ＿ｃｏｌｌｅｃｔｅｄ−コレクションの日付
ｔｉｔｌｅ−ＵＲＬおよびファイルアップロードのような特別なデータセットが追加された時に用いられる
ｄａｔａｓｅｔ＿ｔｙｐｅ−ＳＣＨＥＤＵＬＥＤ（予定の）またはＡＰＰＥＮＤＥＤ（追加）
ｃｏｍｐｌｅｔｉｏｎ＿ｓｔａｔｕｓ−ＣＯＭＰＬＥＴＥ（完了）、ＩＮＣＯＭＰＬＥＴＥ（未完）、またはＮＯＴ  ＡＰＰＬＩＣＡＢＬＥ（適用不可）
ａｐｐｒｏｖａｌ＿ｓｔａｔｕｓ−ＡＰＰＲＯＶＥＤ（承認）、ＮＯＴ  ＡＰＰＲＯＶＥＤ（未承認）、ＲＥＴＲＡＣＴＥＤ（撤回）、ＮＯＴ  ＡＰＰＬＩＣＡＢＬＥ（適用不可）
ｅｄｉｔ＿ｒｅａｓｏｎ−最後の編集の理由に関する注記（必要に応じて）
ａｐｐｒｏｖａｌ＿ｒｅｔｒａｃｔｉｏｎ＿ｎｏｔｅｓ−承認が撤回された理由に関する注記
（ｄａｔａ＿ｉｔｅｍｓ）
ｄａｔａ＿ｉｔｅｍ＿ｉｄ−主キー
ｄａｔａｓｅｔ＿ｉｄ−データセットへの外部キー
ｉｔｅｍ＿ｄｅｆｎ＿ｉｄ−ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓへの外部キー
ｅｄｉｔ＿ｒｅａｓｏｎ−データ項目が編集された理由に関する注記（必要に応じて）
（ｉｔｅｍ＿ｃｏｍｐｏｎｅｎｔｓ）
ｃｏｍｐｏｎｅｎｔ＿ｉｄ−主キー
ｄａｔａ＿ｉｔｅｍ＿ｉｄ−ｄａｔａ＿ｉｔｅｍｓへの外部キー
ｃｏｍｐ＿ｄｅｆｎ＿ｉｄ−ｃｏｍｐｏｎｅｎｔ＿ｄｅｆｉｎｉｔｉｏｎｓへの外部キー
ｄａｔａ＿ｔｙｐｅ−ＤＡＴＥ、ＬＩＳＴ、ＮＵＭＢＥＲ、ＳＴＲＩＮＧ等
ｎｕｍｅｒｉｃ＿ｖａｌｕｅ−実際の値、数値であれば、ここに保存される
ｓｔｒｉｎｇ＿ｖａｌｕｅ−実際の値、文字列であれば、ここに保存される
ｂｌｏｂ＿ｐｔｒ−“バイナリの大きいオブジェクト”（最高４ＧＢ）へのポインタ、ここに保存される
ｃｌｏｂ＿ｐｔｒ−“キャラクタの大きいオブジェクト”（最高４ＧＢ）へのポインタ、ここに保存される
ｄａｔｅ＿ｖａｌｕｅ−実際の値、日付であれば、ここに保存される
３．  以下のテーブルの表示は、それを通ってユーザーがデータセットにアクセスできるフォームを生成するために用いられる。各表示フォームは、ただ１つのデータセット定義に関連するが、１つのデータセット定義を複数の表示フォームにより様々に表示できるであろう。
【０１５４】
（ｄｉｓｐｌａｙ＿ｆｏｒｍｓ）
ｄｉｓｐｌａｙ＿ｆｏｒｍ＿ｉｄ−主キー
ｎａｍｅ−この表示フォームを識別するために用いられる名
ｄｅｓｃｒｉｐｔｉｏｎ−この表示フォームの説明
ｓｅｔ＿ｄｅｆｎ＿ｉｄ−ｄａｔａｓｅｔ＿ｄｅｆｉｎｉｔｉｏｎへの外部キー
ｆｏｒｍ＿ｔｙｐｅ−ＢＲＯＷＳＥＲ、ＰＤＡ等
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｃｏｄｅ−ＵＩにより使用される内部コード
（ｄｉｓｐｌａｙ＿ｇｒｏｕｐｓ）
ｄｉｓｐｌａｙ＿ｇｒｏｕｐ＿ｉｄ−主キー
ｄｉｓｐｌａｙ＿ｆｏｒｍ＿ｉｄ−ｄｉｓｐｌａｙ＿ｆｏｒｍｓへの外部キー
ｇｒｏｕｐ＿ｓｅｑｕｅｎｃｅ−この表示フォーム内でのグループのシーケンス（１、２、３…）
ｇｒｏｕｐ＿ｎａｍｅ−参照のため研究筆者により用いられる；ユーザーには表示されない
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｃｏｄｅ−ＵＩにより使用される内部コード（例えば、ＴＡＢＬＥ）
（ｄｉｓｐｌａｙ＿ｉｔｅｍｓ）
ｄｉｓｐｌａｙ＿ｉｔｅｍ＿ｉｄ−主キー
ｄｉｓｐｌａｙ＿ｇｒｏｕｐ＿ｉｄ−ｄｉｓｐｌａｙ＿ｇｒｏｕｐｓへの外部キー
ｉｔｅｍ＿ｓｅｑｕｅｎｃｅ−この表示グループ内での項目のシーケンス（１、２、３…）
ｉｔｅｍ＿ｄｅｆｎ＿ｉｄ−ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓへの外部キー
ｐｒｅ＿ｌａｂｅｌ−データフィールドの直前に表示されるテキスト
ｐｏｓｔ＿ｌａｂｅｌ−（もしあれば）データフィールドの直後に表示されるテキスト（例えば、“グラム”）
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｃｏｄｅ−ＵＩにより使用される内部コード（例えば、ＲＡＤＩＯ、ＤＲＯＰＤＯＷＮ、ＬＩＳＴ）
４．  データセットアクセス特権−これらのテーブルは、データセット＿ｄｅｆｉｎｉｔｉｏｎかｄａｔａ＿ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎレベルのいずれか一方において、アクセスが役割に与えられることを許す。
【０１５５】
（ｄａｔａｓｅｔ＿ｐｒｉｖｉｌｅｇｅｓ）
ｓｅｔ＿ｄｅｆｎ＿ｉｄ−ｄａｔａｓｅｔ＿ｄｅｆｉｎｉｔｉｏｎｓへの外部キー；主キーの一部
ｒｏｌｅ＿ｉｄ−役割への外部キー；主キーの一部
ｗｒｉｔｅ＿ｐｒｉｖ−１＝データ項目更新可；０＝不可
ｒｅａｄ＿ｐｒｉｖ−１＝データ項目閲覧可；０＝不可
ｄｅｌｅｔｅ＿ｐｒｉｖ−１＝レコード削除可；０＝不可
ｉｎｓｅｒｔ＿ｐｒｉｖ−１＝新規レコード挿入可；０＝不可
（ｄａｔａ＿ｉｔｅｍ＿ｐｒｉｖｉｌｅｇｅｓ）
ｉｔｅｍ＿ｄｅｆｎ＿ｉｄ−ｉｔｅｍ＿ｄｅｆｉｎｉｔｉｏｎｓへの外部キー；主キーの一部
ｒｏｌｅ＿ｉｄ−役割への外部キー；主キーの一部
ｗｒｉｔｅ＿ｐｒｉｖ−１＝データ項目更新可；０＝不可
ｒｅａｄ＿ｐｒｉｖ−１＝データ項目閲覧可；０＝不可
５．  ケイパビリティおよび役割−これらのテーブルにより、各研究について役割を作成すること、ユーザーに１つ以上の役割を与えること、および役割を１つ以上のケイパビリティに関連付けることが可能になる。
【０１５６】
（Ｒｏｌｅｓ）
ｒｏｌｅ＿ｉｄ−主キー
ｓｔｕｄｙ＿ｉｄ−研究への外部キー
ｃｏｍｍｕｎｉｔｙ＿ｉｄ−共同体への外部キー
ｒｏｌｅ＿ｎａｍｅ−役割の名称
（ｒｏｌｅ＿ｃａｐａｂｉｌｉｔｉｅｓ）
ｒｏｌｅ＿ｉｄ−役割への外部キー
ｃａｐａｂｉｌｉｔｙ＿ｉｄ−ケイパビリティへの外部キー
（ｒｏｌｅ＿ｕｓｅｒｓ）
ｒｏｌｅ＿ｉｄ−役割への外部キー
ｕｓｅｒｎａｍｅ−ユーザーへの外部キー
ｄａｔｅ＿ａｓｓｉｇｎｅｄ−日付ユーザーはこの役割が割り当てられた
ｓｔａｔｕｓ−ＡＣＴＩＶＥ、ＩＮＡＣＴＩＶＥ
（ｃａｐａｂｉｌｉｔｉｅｓ）
ｃａｐａｂｉｌｉｔｙ＿ｉｄ−主キー
ｃａｐａｂｉｌｉｔｙ＿ｎａｍｅ−ケイパビリティの名称（例えば、‘被験対象をエンロールする’）
ｃａｐａｂｉｌｉｔｙ＿ｔｙｐｅ−このケイパビリティはＳＴＵＤＹ、ＣＯＭＭＵＮＩＴＹ、またはＳＹＳＴＥＭに関連する
６．  イベント−これらのテーブルは、イベントの発生を記録し、研究についてどんなイベントが予想される（すなわち、予定される）かを定義するために用いられる。
【０１５７】
（Ｅｖｅｎｔｓ）
ｅｖｅｎｔ＿ｉｄ−主キー
ｔｉｔｌｅ−イベントの名称（例えば、‘初診’、‘術後１ヶ月’）
ｓｔｕｄｙ＿ｉｄ−研究への外部キー
ｓｕｂｊｅｃｔ＿ｉｄ−被験対象への外部キー
ｓｃｈｅｄｕｌｅｄ＿ｅｖｅｎｔ＿ｉｄ−ｓｃｈｅｄｕｌｅｄ＿ｅｖｅｎｔｓへの外部キー
ｅｖｅｎｔ＿ｓｔａｔｕｓ−ステータス：ＩＮＣＯＭＰＬＥＴＥ、ＡＰＰＲＯＶＥＤ、ＣＯＭＰＬＥＴＥ
ｓｔａｔｕｓ＿ｕｐｄａｔｅｄ−日付ステータスが最後に変更された
ｅｖｅｎｔ＿ｄａｔｅ−イベントの日付／時間
ｅｎｔｒｙ＿ｄａｔｅ−レコードが作成された日付／時間
（ｓｃｈｅｄｕｌｅｄ＿ｅｖｅｎｔｓ）
ｓｃｈｅｄｕｌｅｄ＿ｅｖｅｎｔ＿ｉｄ−主キー
ｓｔｕｄｙ＿ｉｄ−研究への外部キー
ｔｉｔｌｅ−予定のイベントの名称（例えば、‘初診’、‘術後１ヶ月’）
ｎｏｄｅ＿ｔｙｐｅ−逐次の場合はＯＲＤＥＲＥＤ；非逐次の場合はＮＯＮ−ＯＲＤＥＲＥＤ
ｂｒａｎｃｈ＿ｔｙｐｅ−ＡＮＤ、すべての送出パスに続く；ＯＲ、送出パスを選択する
ｄｅｓｃｒｉｐｔｉｏｎ−参照のために研究筆者により用いられる；ユーザーには表示されない
（ｓｃｈｅｄｕｌｅｄ＿ｅｖｅｎｔ＿ｌｉｎｋｓ）
ｐａｒｅｎｔ＿ｉｄ−ｓｃｈｅｄｕｌｅｄ＿ｅｖｅｎｔｓへの外部キー（先行イベント）
ｃｈｉｌｄ＿ｉｄ−ｓｃｈｅｄｕｌｅｄ＿ｅｖｅｎｔｓへの外部キー（次のイベント）
【図面の簡単な説明】
【０１５８】
【図１】図１は、本発明に従うクライアント層、中間層およびデータ層を有する代表的システムのブロック図である。
【図２】図２は、本発明に従うプレゼンテーション作成メカニズム、データアクセスメカニズムアプリケーションコントロールおよびナビゲーションメカニズムならびにデータセキュリティメカニズムを含むいくつかのアプリケーション要素を示すブロック図である。
【図３】図３は、本発明に従うデータモニタ、エンローラ、データエディタ、研究管理者およびシステム管理者役割を含む代表的役割およびデータアクセスの関連付けられたレベルを示す絵図である。
【図４】図４は、論理層に分解されたデザインモデルの組織を示す絵図であり、各々は、本発明に従うシステムのオペレーション中に有する責任により関係付けられるパッケージ、サブシステムおよびクラスの収集を表す。
【図５】図５は、本発明に従うプレゼンテーション層、アプリケーション層、データアクセスオブジェクト、値オブジェクトおよびユーティリティ要素を含むシステムアーキテクチャの代表的要素を示す絵図である。
【図６】図６は、本発明に従うクライアントウェブブラウザから生成された処理要求に伴うメカニズムおよび要素のグラフィック表現を示す絵図である。
【図７】図７は、本発明に従う代表的なログイン機能を示す絵図である。
【図８】図８は、本発明に従う代表的な研究ホームページを示す絵図である。
【図９】図９は、本発明に従う代表的な候補被験対象登録機能を示す絵図である。
【図１０】図１０は、本発明に従う代表的な検体登録機能を示している絵図である。
【図１１】図１１は、本発明に従う高度検索機能を示す絵図である。
【図１２】図１２は、本発明に従う代表的なオープンエンロールメント機能を示す絵図である。
【図１３】図１３は、本発明に従う代表的なクローズエンロールメント機能を示す絵図である。
【図１４ａ】図１４ａは、本発明に従う代表的な役割定義機能を示す絵図である。
【図１４ｂ】図１４ｂは、本発明に従う代表的な役割定義機能を示す絵図である。
【図１５ａ】図１５ａは、本発明に従う代表的な役割割り当て機能を示す絵図である。
【図１５ｂ】図１５ｂは、本発明に従う代表的な役割割り当て機能を示す絵図である。
【図１６ａ】図１６ａは、本発明に従う代表的なユーザー管理機能を示す絵図である。
【図１６ｂ】図１６ｂは、本発明に従う代表的なユーザー管理機能を示す絵図である。
【図１７】図１７は、本発明に従う代表的な被験対象エンロールメント機能を示す絵図である。
【図１８】図１８は、本発明に従う代表的な研究データ追加／編集機能を示す絵図である。
【図１９】図１９は、本発明に従う代表的な遺伝学データ追加／編集機能を示す絵図である。
【図２０】図２０は、本発明に従う代表的なデータ見直し機能を示す絵図である。
【図２１】図２１は、本発明に従う代表的なデータセット承認機能を示す絵図である。
【図２２】図２２は、本発明に従う代表的なデータセット承認（フリーズ）機能を示す絵図である。
【図２３】図２３は、本発明に従う代表的な復元機能を示す絵図である。
【図２４】図２４は、本発明に従う代表的なメールメッセージセンター画面を示す絵図である。
【図２５】図２５は、本発明に従う代表的なメールメッセージを示す。
【図２６】図２６は、本発明に従う予定のイベントの代表的な一覧を示す。
【図２７】図２７は、本発明に従う予定のイベントおよび予定外のイベント双方を一覧表示する特定被験対象の代表的な詳細図を示す。
【図２８】図２８は、本発明に従う予定外のイベントを入力するための代表的なデータ入力画面を示す。
【図２９】図２９は、本発明に従う予定外のイベント追加後の代表的な確認メッセージを示す。
【図３０】図３０は、本発明に従う新たに追加された予定外のイベントを含む予定のおよび予定外のイベントを一覧表示する特定被験対象の代表的な詳細図を示す。
【図３１ａ】図３１ａは、本発明に従う代表的なデータベーステーブルを示す。
【図３１ｂ】図３１ｂは、本発明に従う代表的なデータベーステーブルを示す。
【図１】
2005516286.tif 000008
【図２】
2005516286.tif 000009
【図３】
2005516286.tif 000010
【図４】
2005516286.tif 000011
【図５】
2005516286.tif 000012
【図６】
2005516286.tif 000013
【図７】
2005516286.tif 000014
【図８】
2005516286.tif 000015
【図９】
2005516286.tif 000016
【図１０】
2005516286.tif 000017
【図１１】
2005516286.tif 000018
【図１２】
2005516286.tif 000019
【図１３】
2005516286.tif 000020
【図１４ａ】
2005516286.tif 000021
【図１４ｂ】
2005516286.tif 000022
【図１５ａ】
2005516286.tif 000023
【図１５ｂ】
2005516286.tif 000024
【図１６ａ】
2005516286.tif 000025
【図１６ｂ】
2005516286.tif 000026
【図１７】
2005516286.tif 000027
【図１８】
2005516286.tif 000028
【図１９】
2005516286.tif 000029
【図２０】
2005516286.tif 000030
【図２１】
2005516286.tif 000031
【図２２】
2005516286.tif 000032
【図２３】
2005516286.tif 000033
【図２４】
2005516286.tif 000034
【図２５】
2005516286.tif 000035
【図２６】
2005516286.tif 000036
【図２７】
2005516286.tif 000037
【図２８】
2005516286.tif 000038
【図２９】
2005516286.tif 000039
【図３０】
2005516286.tif 000040
【図３１ａ】
2005516286.tif 000041
【図３１ｂ】
2005516286.tif 000042
【国際調査報告】
2005516286.tif 000043
2005516286.tif 000044