JP2006518081A - 自動化された薬学、生物医学および医療装置の研究およびレポート作成のための方法およびシステム - Google Patents

Abstract

薬学的研究およびレポート作成を促進する薬学的、生物医学的および医療機器開発のための臨床実験を自動的に管理するためのシステムは、少なくとも１つのサイトサーバー２２２と、一次臨床実験データを収集するようになっている少なくとも１つの計算デバイス２１８と、認可されたユーザーがアクセス可能な計算デバイス２３４を備える。中央サーバー２３２は各サイトサーバー２２２からの一次臨床実験データを受信し、一次臨床実験データを記憶し、一次臨床実験データに基づき、二次臨床実験データを作成すると共に、認可されたユーザーがアクセス可能な計算デバイス２３４へ一次および二次臨床実験データを送信するようになっている。更に本方法を実施するための一組の命令を含むコンピュータで読み取り可能な信号を含む薬学的研究およびレポート作成を促進するために、薬学的、生物医学的および医療機器開発のための臨床実験を自動的に管理するための方法も提供される。

Description

（関連出願の相互参照）
本願は、「自動化された薬学の研究およびレポート作成のための方法およびシステム」と題され２００３年２月１４日付で出願された米国仮特許出願第６０／４４，４３３号に基づく恩恵を主張するものである。
本発明は、自動化された薬学研究およびレポート作成に関する。より詳細には、本発明は医薬の開発のための臨床的実験管理に関する。

現在の書類に基づく臨床的実験方法には基本的な問題がある。コストおよび時間に関係する圧力は医薬開発の分野において大幅に高まっており、コストを抑制するという圧力、内部容量に関する限界を克服しようとする試み、新しい医薬および／または機器の評価および開発をするためのタイムラインを改善したいという要求、固定費と比較した変わり得る開発費のパーセントを高めようとする要求、多数の国における新しい医薬または機器に関する研究を同時に実行したいという要求、種々の国における次第に厳密となる政府規制に対する対応、および内部設計および開発能力を補足するために利用できるすべての専門家を利用したいという要求を含む多数の要素を考慮している。

医薬開発に関する研究のためのタフトセンター（Ｔｕｆｔｓ Ｃｅｎｔｅｒ ｆｏｒ ｔｈｅ Ｓｔｕｄｙ ｏｆ Ｄｒｕｇ Ｄｅｖｅｌｏｐｍｅｎｔ）によれば、新しい処方医薬を開発するための平均コストは８億２００万ドルにもなっており、新しい処方医薬を開発し、米国において市販する認可を得るのに１０年〜１５年かかっている。新しい医薬を開発するのに必要な投資額が連続して増加するにつれ、医薬の開発プロセスをスピードアップし、またはこのプロセスをより効率的にするのを助ける機会が創出されている。

医薬開発の研究のためのタフトセンターは、生物薬学のための開発総時間が、１９８２年から２００１年の間に着実に長くなっていることも表明した。

これら問題に対する１つの対応は、電子データキャプチャー（ＥＤＣ）／臨床実験管理システム（ＣＴＭＳ）を採用することであった。しかしながら、ほとんどの利用できるＥＤＣ／ＣＴＭＳシステムは使用が困難であり、断片的であり、かつバラバラであり、研究を実施するプロセスに取り組んでいない。

認可されたユーザーは臨床的実験をより迅速かつコスト的に有効に完了するための次第に高まる圧力のもとにあることが現実である。不幸なことに、認可されたユーザーは研究データおよびメトリックス（ｍｅｔｒｉｃｓ）にタイムリーにアクセスできず、臨床的な管理判断が遅れる。在庫管理は極めて効率的でないことが多く、タイムリーに患者をリクルートすることは常に困難な作業である。利用できる技術製品は高価であり、断片的であり、使用が困難な部分的な解決手段である。

求められていることは、進行中の臨床実験の情報へ改善されたアクセスをし、この情報を使用することも容易にしながら、コストを削減し開発時間を短縮することを容易にする、高い利用性を有する臨床実験管理解決方法である。

本明細書は、かかる臨床実験管理解決案を教示するものであり、本明細書に記載する本発明の説明から、本発明の上記およびそれ以外の利点だけでなく、更なる発明の特徴も明らかとなろう。

本発明およびその利点をより完全に理解できるようにするために、以下、添付図面を参照しながら、次の簡単な説明を参照する。同様な参照番号は同様な特徴を示す。

本明細書は、ユーザーがデータを入力できるインターフェースを設けることにより、電子データキャプチャーを使用し、一次臨床試験データを収集するようになっている少なくとも１つの計算デバイスに各々が関連し、かつ通信可能に結合された少なくとも１つのサイトサーバー（ｓｉｔｅ ｓｅｒｖｅｒ）と、フルタイムの公衆ネットワーク（公衆網）を介し、各サイトサーバーに通信可能に結合されると共に、フルタイムの公衆ネットワークを介して、認可されたユーザーがアクセス可能な計算デバイスに通信可能に結合された中央サーバーとを含む、薬学研究およびレポートを容易にする薬学的、生物医学的および医療機器開発のための臨床実験の自動化された管理のためのシステムを教示するものである。一次臨床実験データを収集するようになっている各計算デバイスは入力されたデータを有効にする（ｖａｌｉｄａｔｅ）ようになっている。各サイトサーバーは一次臨床実験データを中央サーバーへ送信するようになっており、中央サーバーは各サイトサーバーからの一次臨床実験データを受信し、一次臨床実験データを記憶し、一次臨床実験データに基づき、二次的臨床実験データを形成するようになっている。その後、一次および二次臨床実験データを認可されたユーザーがアクセスできる計算デバイスに送信できるようになっている。

本発明は、薬学研究およびレポート作成を容易にするように、薬学的、生物医学的および医療機器開発のための臨床実験を自動的に管理するための方法も教示するものである。一次臨床実験データを収集するようになっているインターフェースと共に構成された計算デバイスをユーザーが利用することにより、一次臨床実験データに対応する電子データを捕捉する。この電子データは、データが有効にされた後に、フルタイムの公衆ネットワークを通し、対応する計算デバイスから中央サーバーへ配信される。この一次臨床実験データに基づき、二次臨床実験データが作成される。一次および二次臨床実験データを記憶し、認可されたユーザーがアクセスできる計算デバイスにより、フルタイムの公衆ネットワークを通してアクセスでき、中央サーバーにより記憶された一次および二次臨床実験データを利用できるようになる。

本発明は、ポインティングデバイスおよびスクリーンディスプレイを備えたユーザーインターフェースを有する汎用コンピュータのための一組の命令を含む、コンピュータ間で伝搬可能なコンピュータで読み取り可能な信号も教示している。命令の組は、ユーザーがマウスによりスクリーンディスプレイ上にディスプレイされたアイコンを選択できるようにするユーザーインターフェースと作動的に関連した入力ルーチンを含み、アイコンはコンピュータにアクセス可能なアプリケーションプログラムに関連している。このアプリケーションプログラムを実行することによって、薬学的研究およびレポート作成を容易にするよう、薬学的、生物医学的および医療機器のための臨床実験を自動的に管理するための方法を実施できる。一次臨床実験データを収集するようになっている、インターフェースと共に構成された計算デバイスをユーザーが使用することにより、一次臨床実験データに対応する電子データを捕捉し、この電子データが有効にされる。前記データが有効にされた後に、電子データはフルタイムの公衆ネットワークによって対応する計算デバイスから中央サーバーへ配信される。一次臨床実験データに基づき、二次臨床実験データが作成され、これら一次臨床実験データおよび二次臨床実験データが記憶される。コンピュータデバイスにアクセスできる正当なユーザーにより、フルタイムの公衆ネットワークを通してアクセスされる中央サーバーにより、記憶された一次および二次臨床実験データが利用できるようになる。アプリケーションプログラムによって発生されるテキストまたは画像をスクリーンディスプレイにディスプレイするための実行ルーチンに応答自在なディスプレイルーチンのように、マウスを用いてユーザーにより選択された前記アプリケーションプログラムを実行するための実行ルーチンも含まれる。

添付図面を参照しながら詳細な説明の残りの部分を読めば、本発明の上記以外の特徴、目的および利点がより明らかとなろう。

本発明は自動化された薬学的、生物医学的および医療機器の研究およびレポートのための方法およびシステムを提供するものであり、より詳細には、エラー、レポートの作成および分析時間ならびに薬学的フィールドテストの結果を得る際のコストを解消するか、または実質的に低減させる方法およびシステムを提供するものである。従って、本発明は臨床実験のコストを削減し、時間を短縮するのに役立つ。

本発明の理解を可能にするために、次の説明はまず薬学的、生物医学的および医療機器の研究の結果を管理し、自動的にレポートを作成するために使用されるデータベースの組織上の見解を提供するものである。その後、下記の記載は研究データ収集および関連する機能を管理するための本発明のプロセスについて、一連の注釈をつけたユーザーインターフェースダイヤグラムによって説明する。

この記載は、本発明の実施例の特徴を述べるものであるが、本発明は医薬業界だけに使用するのでなく、同様なデータ収集の必要性を有するその他の業界でも使用するための更なる別の実施例も明らかに可能である。

Ｐｒｅｃｅｒｃｈｅとは、自動化された薬学的研究およびレポートのためのプレセルチェ・インコーポレイテッド（以下、プレセルチェ社）の方法およびシステムを識別するプレセルチェ社の商標であり、この方法およびシステムの所定の実現例は添付した特許請求の範囲の少なくとも１つによってカバーできる。Ｐｒｏｔｏｃｏｌ Ｐｒｏｐｈｅｒｔとは、プレセルチェ社の基本的なプロトコル情報のアスペクト（ａｓｐｅｃｔ：特徴、側面）を識別するプレセルチェ社の商標であり、この特徴の所定の実現例は添付した特許請求の範囲のうちの少なくとも１つによってカバーできる。Ｒｅｐｏｒｔ Ｇｅｎｉｅとは、プレセルチェ社のレポートアスペクト（ｒｅｐｏｒｔｉｎｇ ａｓｐｅｃｔ）を識別するプレセルチェ社の商標であり、そのレポートの所定の実現例は添付した特許請求の範囲のうちの少なくとも１つによってカバーできる。ＩｎｔｅｒＲｘとは、臨床研究管理のいろいろなアスペクト（ｄｉｓｐａｒａｔｅ ａｓｐｅｃｔｓ）を統合するためのプレセルチェ社の総合ソリューションシステムを識別するプレセルチェ社の商標であり、このシステムの所定の実現例は添付した請求項の少なくとも１つによってカバーできる。Ｘｐｒｏｔｏｃｏｌとは、プレセルチェ社のＸＭＬに基づくプロトコル表示を識別するプレセルチェ社の商標であり、このプロトコル表示の所定の実現例は添付した特許請求の範囲の少なくとも１つによってカバーできる。

図１は、本発明の一実施例のデータベース構造体の概観を示し、データベース構造の全体は６つのコンポーネント／アスペクト、すなわち基本プロトコル情報（ＢＰＩ）１０２と、出荷１０４と、患者情報１０６と、患者スケジュール１０８と、更新１１０と、レポート１１２とを含む。

図２は、ＢＰＩアスペクト１０２を示し、プログラムのＢＰＩアスペクトにより、技術者は各研究プロトコル（ｓｔｕｄｙ ｐｒｏｔｏｃｏｌ）内で異なる情報およびパラメータのすべてを入力できるようになっている。プログラムのこの部分はプログラムの他の部分に対して不可欠なものである。管理者がこのように新しいプロトコル１１６を入力できるようにすることによって、データの利用性が促進されている。プログラムのこのようなアスペクトにより、データベースにデータをマニュアルで入力することと比較して、膨大な時間を節約できる。

ＢＰＩ部分１０２は不正確な入力および空のフィールドを示す警告スクリーンを提供しなければならない。業界固有である検証を表示するドキュメントが提供される。

プロトコル情報１１８は、プロトコル番号、名称、治験薬、認可されたユーザーおよびコンタクト、並びに患者のスケジュールを定め、現在の訪問を表示するために後でプログラムで使用されるその他のパラメータを含む。

プロトコルが設定された後にサイトが選択される（１２０）。これによって、プログラムがレポートをプリントし、患者を追跡し、サイトの進行を追跡することに役立つ。

患者の訪問１２２は、各訪問でどんな評価を実行するかを示す。これは訪問毎に各患者にアクセスするためにプログラム内で後に使用される。患者訪問もレポートをプリントするのに役立ち、プログラムの最も重要な部分のうちの１つである。

これによって、患者訪問のための新しい評価および患者スクリーニング訪問（ｐａｔｉｅｎｔ ｓｃｒｅｅｎｉｎｇ ｖｉｓｉｔ）のための新しいクォリファイア１２４にユーザーが入力することが可能となる。

これによってユーザーは入力された新しい評価に対する新しい制限１２６の量を入力することが可能となる。

図３はプログラムの出荷のアスペクトを示す。このプログラムの出荷アスペクト１０４により、製薬会社はすべての医薬キットを追跡することが可能となる。製薬会社は特定のサイトおよび特定の患者に対する医薬キットの追跡をすることができるようになる。各キットに対し、ラベルが作成され、製薬会社から出荷される前に、サイトに到着したとき、およびランダム化プロセスによって選択されたときに、システムによって各キットがスキャンされる。作成されるラベルは患者がランダム化されたときにどのキットを使用するかを研究コーディネータに表示するのに使用される。

製薬会社側では、追跡を行うことができるように各キットにラベルが張り付けられる（１３０）。

製薬会社では、追跡プロセスが開始されるように出荷前に各キットをスキャンする（１３２）。その後、正しいサイトにキットが出荷される。

サイトでは、各キットが到着したときに棚に受け入れる際（ａｓ ｒｅｃｅｉｖｅｄ ｉｎ ｉｎｖｅｎｔｏｒｙ）に各キットをスキャンする（１３４）。こうして、ランダム化プロセスにおいて選択できるようにキットを利用できるようになる。製薬会社はどのキットが受け入れられたかに基づいて問い合わせにアクセスできる。

ランダム化プロセスにおいてキットが選択されると、選択プロセスからキットを選択し、取り出す際に、キットをスキャンする（１３６）。キットは棚（ｉｎｖｅｎｔｏｒｙ）から取り出しても、他の患者が使用するのには利用できない。次に、キットは研究で使用される。どのキットがランダム化され、研究で使用されているかに基づき、製薬会社は問い合わせおよびレポートにアクセスできる。

研究が完了した後に使用されたキットおよび使用されていないキットを製薬会社に戻す。製薬会社は戻って来たキットをスキャンし（１３８）、その結果をデータベースにログインする。

図４は本発明の患者情報部分１０６を示す。このプログラムの患者情報部分により、サイトは患者訪問を実行し、患者に働きかけている間に自動的にデータを記憶する。各サイトは、バーコードスキャナを持ち、このスキャナは到着時にデータベースへ各患者をスキャンするのに使用される。訪問中、各医者、調査員はハンドヘルドデバイスでプログラムに直接関連する自分の見立て（ｆｉｎｄｉｎｇｓ）を記録することができるようになる。このデバイスは現在の訪問を完了するのに必要な現在の患者情報および評価を提供する。

患者が登録され、訪問０１のために戻った後に、現在のプロトコルが必要とする場合に、プログラムはユーザーが患者をランダム化することを自動的に促す。メインデータベースサーバーに対し、ダイレクトラインがオープンにされ、患者がランダム化される。ランダム化番号および対応するキット番号が患者に割り当てられる。

新しい患者スクリーンにより、ユーザーは新しい患者１４０に対して情報、例えばイニシャル、誕生日、人種および性別を入力できる。このセクションは医療履歴部分も含む。将来の研究のための適格性を備え得る患者に対する問い合わせのために、その後、この情報にアクセスできる。次に、新しい患者は特定のプロトコルに関連付けされる。この時点で、ユーザーはスクリーニング訪問を実行するか、または別の新しい患者を入力できる。次に、患者に対してバーコードで識別される患者カード（Ｐａｔｉｅｎｔ Ｃａｒｄ）が与えられる。

訪問プロセスをスタートするために、患者情報が入力された後に、患者に与えられた患者カードをスキャンすることにより、現在の患者１４２を選択できる。現在の患者が設定されると、患者訪問がスタートする。

患者訪問１４４により、ユーザーは現在の訪問中に各アクセスに対する評価結果を入力できる。このことはハンドヘルドデバイスによって行われる。このデバイスは医者／調査員が評価結果のためのレンジを選択したり、またはデータを入力するために使用される。

訪問０１では、（プロトコルが必要とする場合に）患者をランダム化しなければならないこと（１４６）がユーザーに自動的に通知される。メインデータベースサーバーに対してダイレクトラインがオープンにされ、患者がプログラムによってランダム化される。調査員に対してランダム化番号およびキット番号が提供される。次にキットがスキャンされ、現在の患者と関連付けされる。

評価が実行されている間、ユーザーは各評価にコメントできる。

本開示によれば、現在の訪問の完了時に次の訪問に対する患者のスケジュールが定められる。図５のブロック図は患者スケジュール１０８を示す。患者の次の訪問に対して利用できる日にちを決定するために、不都合な日にち（ｎｅｇａｔｉｖｅ ｄａｙｓ）のウィンドー、好都合の日にち（ｐｏｓｉｔｉｖｅ ｄａｙｓ）のウィンドー、訪問回数および週の数を含むパラメータを示す。プロトコルパラメータに従い、患者の訪問を行い得る利用可能な日にちを示すために、ユーザーに正しい時間フレームが提示される。次にこの時間フレーム内で患者のスケジュールが定められる（１５２）。

現在の訪問が完了し、患者が病院を離れた後で、プログラムによって利用できるようにされた時間フレームを使って次の訪問に対するスケジュールが定められる。

図６は、本開示の更新アスペクト１１０を示す。本発明によれば、研究の各要素を更新できる。このことは、改定を示すためのプロトコルの変更、住所、電話番号の変更および患者の訪問情報の訂正方法をユーザーに提供するために極めて有効である。

名前、パラメータおよびその他の情報の変化を示すために、プロトコルを更新できる（１５６）。サイトをプロトコルに関連させることができ、このプロトコルの改定に従って患者訪問評価を変更できる。

認可されたユーザーのアドレスおよびコンタクト情報を変更できる（１５８）。

変更１６０を示すために認可されたユーザーのコンタクト電話、ファックスおよび名称を変えることができる。認可されたユーザーに関連する新しいコンタクトを個々に追加することもできる。これらコンタクトは追加後にプロトコルに関連させなければならない。

サイト内での変化を示すために、サイトアドレスおよびコンタクト情報を更新できる（１６２）。コンタクト情報は変更できないが、異なるコンタクトを選択することができる。更新サイトコンタクトセクションでは、コンタクト情報を更新する。

電話番号、ファックス番号および名称の変化を示すためにサイトコンタクト情報を更新できる（１６４）。

評価の際になされた変化を示したり、または誤りを正すために、患者訪問１６６を更新することは極めて重要なことである。このスクリーンによってユーザーは患者訪問へ戻り、必要な変更を行うことができる。データベースには古いデータを含むすべてのデータが記憶される。これら変更に時間および日付スタンプが押され、現在のユーザーに帰するものとする（ａｔｔｒｉｂｕｔｅｄ ｔｏ ｔｈｅ ｃｕｒｒｅｎｔ ｕｓｅｒ）。

本発明は、図７に示されるようなレポートのアスペクト１１２も含み、このレポートアスペクトはユーザーの意のままに研究からのすべての情報を提供する。これらレポートアスペクトはサイトの個人、認可されたユーザーの個人、および技術要員を含むすべてのユーザーが問い合わせに基づいてレポートを作成できるようにする。各ユーザーはこれらのニーズに基づいてレポートを作成できる。コンピュータシステムを利用することにより、誤りを容易に見つけ、変更し、防止できるので、このプログラム部分は極めて重要である。

当事者が提供する質問を満たすために問い合わせを行うことができる。すべてのユーザーが現在のものであり、完成していることを確認するために、プリント前にスクリーンにソースドキュメントおよびケースレポートフォーム（ＣＲＦ）ドキュメントを見ることができる。これによって研究において後でレポートを訂正するのに必要な時間を短縮できる。リクエストにより、メインサーバーから問い合わせを作成し、迅速に更新することもできる。

各プロトコルまたは製薬会社固有のものに見えるようにすべてのレポートを作成できる。

研究メトリックスに関する質問に回答するために、またはデータの不一致をチェックするために、情報を見つけるようにレポート問い合わせ１７０をどのユーザでも作成できる。これら問い合わせを使って臨床データ管理に情報を提供することもでき得。

各患者に対し、ソースドキュメント１７２をプリントし、患者フォルダに保持することができる。各プロトコル、各サイト、単一の患者、または１回の訪問に対してソースドキュメントをプリントできる。

各患者に対し、ＣＲＦドキュメント１７４をプリントし、規制されたバインダー（ｒｅｇｕｌａｔｏｒｙ ｂｉｎｄｅｒ）内に保持する。各プロトコル、各サイト、一人の患者または１回の訪問に対し、ＣＲＦドキュメントをプリントできる。

研究メトリックス１７６はプロトコル、サイトまたは患者によってソートされるように提供される。

本発明のプログラムを使用することにより、新規なタイプの患者訪問を実行でき、この患者訪問は本明細書に記載の技術的利点および特徴を利用して１つのフローに従う。下記の図８はかかる１つの患者訪問を示すプロセスフローチャートである。

図８はステップ１７８でスタートし、フローはステップ１８０で分岐する。患者が新しい患者でない場合、ｆｒｍＰａｔｉｅｎｔＶｉｓｉｔ１８４を含む患者訪問（Ｐａｔｉｅｎｔ Ｖｉｓｉｔ）が行われ（１８２）、訪問回数が決定される（１８６）。患者がランダム化され（１８８）、評価が決定される（１９０）。ユーザーは評価回答１９２を提供し、その次に別の分岐ステップ１９４が続く。ユーザーがコメントしないことを選択した場合、訪問が保存され（１９６）、プロセスフローが終了する（１９８）。ユーザーがコメントする場合、ｆｒｍＣｏｍｍｅｎｔ２００が使用され、コメント（ｃｏｍｍｅｎｔ）が保存され（２０２）、訪問が保存され（１９６）、フローが終了する（１９８）。

図８に示されるように、患者が新しい患者である場合、患者情報が追加され（２０４）、完全なスクリーン訪問が生じたかどうかの判断２０６を行わなければならない。生じていない場合、フローを出て（２０８）、終了する（２１０）。他方、判断２０６が完全なスクリーン訪問と表示した場合、ｆｒｍＰａｔｉｅｎｔＶｉｓｉｔ２１２が使用され、評価が決定され（２１４）、ユーザーは評価回答１９２を提供する。この時点で、上記のようにステップ１９２からのフローが続く。

従って、３つのユーザーの判断は患者が新しいかどうか（１８０）、スクリーンプロセスを終了しているかどうか（２０６）、および完了したスクリーンプロセスに関するコメントをするかどうか（１９４）の判断である。ｆｒｍＰａｔｉｅｎｔＶｉｓｉｔおよびｆｒｍＣｏｍｍｅｎｔプロセスにより、情報を収集するのにパソコンまたはハンドヘルドの計算デバイスを使用できる。

以上で、本発明のプログラムの特徴について説明したので、次の記載はユーザーインターフェースおよび本発明が実施する関連する機能の詳細を示す。

基本プロトコル情報
プロトコル情報はプロトコル番号、名称、調査製品（Ｉｎｖｅｓｔｉｇａｔｉｏｎａｌ Ｐｒｏｄｕｃｔ）、認可されたユーザーおよび契約、および患者のスケジュールを定めるためにプログラム内で後に使用されるその他のパラメータを含む。

認可されたユーザー情報インターフェースは図９に示されている。ユーザーは既にデータベース内にある認可されたユーザーを選択できる。

コンタクト情報インターフェースは図１０に示されている。ユーザーはコンタクトを選択し、以前使用され、選択された認可ユーザーに関連するコンタクトは選択のために利用できる状態とされ、またはユーザーは新しいコンタクトを作成できる。次に、作成されたコンタクトは選択された認可ユーザーに関連付けされる。

プログラム情報インターフェースは図１１に示されている。ここには、製品名、プロトコル名および所有権の警告（ｐｒｏｐｒｉｅｔａｒｙ ｎｏｔｉｃｅ）が入力される。これら名称は通常、極めて長いパラグラフである。

構造情報インターフェースは図１２に示されている。研究がランダム化された場合、ユーザーはまずランダム化のタイプを選択する。認可されたユーザーは研究で使用されるランダム化のタイプに対する公式（ｆｏｒｍｕｌａ）を提供する。この公式は、研究内で使用されるようにプログラムされる。この公式は、他の研究で使用するために選択されるように利用できる。第２にユーザーは、研究パラメータを入力する。これらパラメータは研究をモニタし、警告を送るように使用される。全体の登録は研究が必要とする患者／被験者（ｓｕｂｊｅｃｔｓ）の全体の数である。この総数は停止場所（ｓｔｏｐｐｉｎｇ ｐｌａｃｅ）を登録簿に与え、研究の異なる部分でメトリックスを与えることができるようにする。例えば各サイトが有する登録のパーセントまたは登録の終了予想時間を与えることができる。週／日／月の数は全体の研究における全週／日／月の数であり、各訪問が行われたことを判断するのを助ける。適応可能な場合、本アプリケーションのスケジューリング部分において、肯定／否定のウィンドーが使用される。患者／被験者はこの時間内で訪問を完了しなければならない。これら数は患者が訪問をするのに利用できる適当なカレンダー日のスケジューラに警告する。

訪問情報インターフェースは図１３および１４に示されている。ユーザーは訪問回数（スクリーニング訪問、訪問０１、訪問０２）を選択し、その訪問時に行わなければならない選択（評価）をチェックする。選択を利用できない場合、ユーザーは新しい評価を選択し、評価を入力するために新しいウィンドーが生じる。ユーザーはレンジ（例えば完了：未了、例えば０〜１００、Ｙｅｓ：Ｎｏ）を選択する。所望するレンジを利用できない場合、新しい制限を作成する。ユーザーは新しい制限をクリックし、制限データを入力するためにテキストボックスを有し、ある例を示すウィンドーが生じる。ユーザーが制限データを保存すると、新しい訪問評価ウィンドーに戻る。次にユーザーは新しい評価および保存を入力する。プログラムは本文ウィンドーに戻り、ユーザーのために既に新しい評価がチェックされる。すべての評価が選択された後に、ユーザーは現在の訪問を保存し、次の訪問のためのプロセスを繰り返す。

サイトおよびコンタクト選択インターフェースは図１５および１６に示されている。ユーザーは選択された認可ユーザーに関連するサイトを選択するか、または新しいサイトを作成できる。ユーザーは選択されたサイトに関連するコンタクト（Ｃｏｎｔａｃｔ）を選択するか、または新しいコンタクトを作成する。コンタクトが選択された後に、ユーザーは選択を保存する。各プロトコルに対して多数のサイトが存在する。

ユーザーがこれらタスクのすべてを完了した後にプロトコル情報を保存する。プロトコル情報のためのどれもが更新可能である。コンタクトは通常、変化し、この情報は極めて重要である。登録が少ない場合、登録するか／しないかの基準は同じように変更できる。

患者情報
プログラムの使用に対し、利用できるユーザーＩＤにより、日／時間スタンプを押す。患者情報インターフェースは図１７に示されている。ユーザーは患者個人情報（住所、電話、生年月日および医療履歴）のすべてを入力する。患者情報および医療履歴にサイトユーザー（調査員および研究コーディネータ）がアクセスできるように、この情報を記憶する。ユーザーは将来の研究のために条件を満たす患者を探すための基準をサーチできる。本発明と共に使用するための患者バーコードが図１８に示されている。患者カードは予想される情報および現在参加中のプロトコルと整合される。患者には、（バーコードを有する）カードが与えられ、患者のチャート内にカードが入れられる。患者をスキャンし、不正行為（ｆｒａｕｄ）を防止するために、どのカルテが使用されているかが訪問ごとにログインされる。

スクリーニング訪問インターフェースは図１９に示されており、このインターフェースはその訪問に対する評価を使用して実行される。評価が決定されたすべての基準をパスすることを確認するよう、研究で患者が登録される前に訪問が行われる。

まずバーコードスキャナおよび患者のカードを使って患者が選択される。第２に、図２０のインターフェースにより患者を検査するプロトコル（研究）が選択される。これによって患者を判断しなければならない評価（質問）の組をプログラムに示す。

次に、図２１に示されているスクリーンにスクリーニング訪問評価が示され、患者の実際のスクリーニングが開始する。次にプログラムは図２２のインターフェースに患者に対する現在のすべての回答を表示するので、誤りに関して回答をチェックできる。患者がスクリーニング訪問をパスした場合、患者が確認され、研究において登録されたことをプログラムが表示する。プログラムは更に現在のプロトコルのスケジュールパラメータに従って次の患者訪問を行わなければならない時間も表示する。

患者訪問インターフェースは図２３に示されている。

患者スキャンステップにおいて、バーコードスキャナによって患者のカルテをスキャンする際にプログラムはプロトコル、患者および現在の訪問を認識する。

評価ステップにおいて、現在の訪問に対する評価を実行する。このスクリーンは基本的には上記訪問評価と同じに見るであろう。

ランダム化ステップでは、訪問０１中に患者をランダム化し、患者のために使用すべきプログラムによって医薬キットが表示される。プログラムのインベントリ部分（Ｉｎｖｅｎｔｏｒｙ ｐａｒｔ）およびプログラムのランダム化部分により、使用する医薬キットが決定される。すべての研究がランダム化されるわけではない。

悪い事象（Ａｄｖｅｒｓｅ Ｅｖｅｎｔ：ＡＥ）とは、研究中に死亡または副作用が生じるような状況である。悪い事象を示すような評価質問に対する回答がなされた場合、現在の患者のために悪い事象フォーム（ａｄｖｅｒｓｐ ｅｖｅｎｔ ｆｏｒｍ）に記入することを開始することがユーザーに対して自動的に促される。ユーザーはメニューから悪い事象を選択し、現在の患者のバーコードをスキャンすることによってこのプロセスを開始することもできる。このフォームが完成した後に、フォローアップの悪い事象フォーム（Ｆｏｌｌｏｗ−ｕｐ Ａｄｖｅｒｓｅ Ｅｖｅｎｔ ｆｏｒｍ）を完成することがＥメールによってユーザーに通知される。

患者スケジュール決定インターフェースは図２３に示されている。各訪問の後で、プログラムによって提供されるカレンダー日を使用して、患者の次の訪問のスケジュールが定められる。これらの日はプロトコルプロフェット（Ｐｒｏｔｏｃｏｌ Ｐｒｏｐｈｅｔ）内に入力されたプロトコルパラメータ内になければならない。各訪問の後で、プロトコルドキュメントから提供されるパラメータに従い、患者訪問を行うことができる利用可能な日がユーザーに通知される。

患者の更新の際に、訪問時間（例えば研究の仕事、血液の仕事（ｂｌｏｏｄ ｗｏｒｋ））にて訪問の評価に対して回答できないことがときどきある。ユーザーは不足している情報が入手できるようになるとすぐに、不完全な訪問を更新できるようになっていなければならない。この更新スクリーン（ｕｐｄａｔｅ ｓｃｒｅｅｎｓ）は正式な患者の訪問スクリーン（ｒｅｇｕｌａｒ ｐａｔｉｅｎｔ ｖｉｓｉｔ ｓｃｒｅｅｎｓ）のように見える。ユーザーは不足した情報を更新できるようになる。データ内に誤りが見つかった場合、ユーザーはデータを変更でき、新しいデータが記憶される。ソースドキュメントレポートには旧データおよび新データを見たり／プリントしたりできる。

不完全な訪問通知ステップ（Ｉｎｃｏｍｐｌｅｔｅ Ｖｉｓｉｔ Ｎｏｔｉｙｉｃａｔｉｏｎ ｓｔｅｐ）では、Ｅメールによりペンディング中の患者訪問をユーザーに通知しなければならない。

別の通知ステップ（Ｏｔｈｅｒ Ｎｏｔｉｆｉｃａｔｉｏｎｓ ｓｔｅｐ）では、特定のユーザーにとって他の患者通知を入手できるようになる。

レポート
レポートは認可されたユーザー、サイト、調査員および研究コーディネータを含む、図２５に示されているような種々のユーザーによりプリントしたりスクリーン上で見ることができる。各ユーザーはメトリックスのモニタ（ｍｏｎｉｔｏｒｉｎｇ ｍｅｔｒｉｃｓ）を含む種々の理由および患者のチャートのためにレポートを利用する。

レポート設定タイプのステップ（Ｓｅｔ Ｒｅｐｏｒｔ Ｔｙｐｅ Ｓｔｅｐ）では、認可されたユーザーはレポートのフォームを提供し、我々は認可されたユーザーが提供したものと丁度同じように見えるレポートを作成する。これらレポートはケースレポーターフォーム（ＣＲＦ）およびソースドキュメントを含む。これらレポートはプロトコル、サイトおよび患者により、通常ソートされる。

図２６に示されるような研究メトリックスレポートはサイトおよび認可されたユーザーに登録、悪い事象またはそれらのメトリックスに関する情報を提供する。これらレポートは通常プロトコルおよびサイトによってソートされる。これらレポートはグラフによっても示すことができる。

ユーザーはレポート問い合わせ（Ｒｅｐｏｒｔ Ｑｕｅｒｉｅｓ）を使用し、データベースに問い合わせをし、患者、研究またはユーザーが必要とする他のものに関する情報を得ることができる。これら問い合わせは、ユーザーがレポートでどの分野を望むのか、およびユーザーがソートされたレポートをどのように必要とするのかの選択案をユーザーに与える。このことは、すべてのユーザーに対して極めて有効なツールとなる。

インベントリ
患者訪問０１のランダム化プロセスにおいて、レポートのために図２７の認可ユーザーおよびサイトチェックインベントリインターフェースが使用される。認可されたユーザーは所定のサイトに送るべき医薬キットをスキャンし、サイトは受け取った医薬キットをマークする。一旦医薬キットが受け取られると、これらキットはランダム化プロセスで使用するために利用できる。次に、認可されたユーザーはどの医薬キットが使用されたか、およびサイトの棚にどれがまだ残っているかを検出できる。実験供給品およびその他の医療供給品を含むように、後にインベントリを拡張できる。

図２８は本開示にかかわるシステムの例を示す。サイト２６はサイトサーバー２２２と、このサーバー２２２に通信可能に結合された２つの計算デバイス２１８、２２０を含む。計算デバイス２１８、２２０はタブレットＰＣまたはノートブックコンピュータのようなデータを捕捉するのに有効なタイプのものである。サイトサーバー２３０および２つのデータ収集計算デバイス２２６、２２８を含む別のサイト２２４も示されている。各サイト２１６、２２４は直観電子データ捕捉（ＥＤＣ）機能、プリント機能、スキャン機能および在庫管理機能（ｉｎｖｅｎｔｏｒｙ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎａｌｉｔｉｅｓ）を含む。

図２８は専用サーバー、ソースドキュメント、患者データ、研究メトリックスおよび完全な監査トレール（ａｕｄｉｔ ｔｒａｉｌ）を含む中央サーバーに通信可能に結合されたサイト２１６、２２４も示す。図２８のシステム内には任意の数のサイト、例えばサイト２１６、２２４を含むことができる。

図２８にも示されるように、中央サーバー２３２は認可されたユーザーの計算デバイス２３４に通信可能に結合された状態に示されている。したがって、認可されたユーザーの計算デバイスは「即日」のレポート、トライアル管理、オンラインモニタおよび監査、ならびに在庫管理にアクセスする。

次の表は、本発明の好ましい実施例を実現したときの潜在的な経済的影響を示す。

開示されたシステムは、発明者が知っている臨床研究管理のための総合的解決案にすぎない。

開示されたシステムの能力は直観的電子データ捕捉（ＥＤＣ）、トライアル管理、在庫管理、モニタおよび監査、セキュリティおよびコンプライアンス、「即日」のレポート、機敏なフレームワークを含み、ターンキー解決方法である。

直観的ＥＤＣの特徴事項は使用が容易なタブレットＰＣ、スキャンされるソースドキュメント、患者の追加、スクリーンおよびビューを含み、開示されたシステムはすべてのプロトコルパラメータを実施し、迅速なエラーチェックは問い合わせを減らす。

トライアル管理はメッセージセンター、問い合わせ提出およびリソリューション、ビュープロトコル定義、例外リクエストおよび認定、およびスタッフ管理を含む。

在庫管理はバーコードスキャン物品、インベントリの追跡（ｔｒａｃｋｉｎｇ ｏｆ ｉｎｖｅｎｔｏｒｙ）およびインベントリ出荷リクエスト（ｉｎｖｅｎｔｏｒｙ ｓｈｉｐｍｅｎｔ ｒｅｑｕｅｓｔｓ）を含む。

モニタおよび監査は研究データ、メトリックス、問い合わせ、レポート、監査および事象への任意の時間および任意の場所でのアクセスを含む。

システムを安全かつ柔軟（ｃｏｍｐｌｉａｎｔ）にする特徴事項は、閉じたシステムであること、ＨＩＰＡＡおよび連邦法典第２１条第１１章の準拠、ユーザー管理および認可、暗号化された送信、ファイアーウォール保護および占有サーバーを有する完全に冗長な分散型データベースアーキテクチャを含む。

「即日」のレポートは連邦法典フォーム、電子およびスキャンされるソースドキュメント、研究およびサイトメトリックス、ＡＥ／ＳＡＥ、問い合わせおよび自動化された日々のレポートおよび通知を含む。

システムのフレームワークを機敏にする特徴事項は、迅速な実現および変更の伝搬を可能にする所有権のあるアーキテクチャ、開示されたシステムアプリケーションを定めるＸＭＬ仕様、プロトコルおよび連邦法典フォームおよびユーザーインターフェース、レポートおよびタスク、ならびにその完全にカスタム化可能な性質を含む。

システムをターンキーソリューションとする特徴事項は選択されたプロトコルに構成された開示システム、バーコードスキャナーと共にモバイルタブレットＰＣを利用すること、サイトサーバーおよび中央サーバーの使用、プリンタおよびドキュメントスキャナの使用、設置およびトレーニングの利用可能性、サポートおよびトライアル後のデータ記憶およびデータへのアクセス可能性を含む。

次の表はリストされたステップに対するシステムのサポートを示す。

システムアプリケーションは、Ｊ２ＥＥウェブアプリケーションであって、マニュアルのハンドオン機能およびデータ募集、有効化および観察を提供する。ＸＭＬはカテゴリー、タスク、ステップおよび分岐を含むタスクフローを記述する。

システムエージェントは、“自動化された”機能を提供するＪＭＸに基づくＪＡＶＡ（登録商標）デーモンであり、このエージェントはダイナミックに拡張可能で構成可能なデータ管理を含む。ＸＭＬは条件および応答を含むルールを記述する。

システムデータソースは、包括的なデータ読み取り／書き込み能力、すなわちＯｒａｃｌｅ（登録商標）およびＭｙＳＱＬ（登録商標）のような標準データベースへのＪＤＢＣ接続、ＸＭＬを使った入出力、種々のタイプのドキュメントファイルの利用、およびシリアル化されたＪａｖａ（登録商標）オブジェクトのような二進オブジェクトの使用を含む。

次の表はシステムのセキュリティの特徴を示す。

（オブジェクト定義、記憶ならびに検索機能、およびデータ変換のためのデータマップを含む）データテンプレート、（レポート定義を含む）プレゼンテーションおよび有効化テンプレート、アプリケーションタスクおよび自動化されたエージェントタスクでＸＭＬ仕様が使用される。

図２９は仕様から研究への変換を示す。ガッツコンポーネント（Ｇｕｔｓ ｃｏｍｐｏｎｅｎｔ）２３８は開示されたシステム２４２の例のアプリケーションを定めるためにＸＭＬ仕様２３６を消費する。プロトコル仕様２４０はエージェントが実行するための研究プロセスおよびデータならびに自動化タスクを定める。

ガッツコンポーネント（Ｇｕｔｓ ｃｏｍｐｏｎｅｎｔ）２３８は基本能力（ｂａｓｉｃ ｃａｐａｂｉｌｉｔｉｅｓ）、制御機能および記憶設備を含む安全インフラストラクチャを有する。基本能力はタスクマネージャー、メッセージセンター、レポートエンジンおよび任意のカスタム“ページ”を含み、制御機能は募集および有効化（ｓｏｌｉｃｉｔａｔｉｏｎ ａｎｄ ｖａｌｉｄａｔｉｏｎ）を含む。記憶設備は通信、配信およびマッピングを含む。

図３０に示されているようなレポート／グラフおよびチャートは、定量的かつ履歴分析の視覚的表示を提供する。使用されるグラフィック要素の例としては、表、バーチャート、パイチャート（ｐｉｅ ｃｈａｒｔ）、ヒストグラムおよびメータ（ｍｅｔｅｒｓ）を挙げることができる。

Ｊａｖａ（登録商標）ＪＭＸデーモン（ｄａｅｍｏｎ）コンポーネントは、管理モジュールを利用する能力を有し、モジュールはシステム、ファイルシステム、データアクセスおよび通知を含むデータアクセスおよび機能を含む。システム情報は処理情報およびリソース利用（ＣＰＵ、メモリ、スレッドなど）を含み、ファイルシステム情報はファイルサイズ、ステートおよびマニピュレーション（例えば作成、移動、削除、ジップ（ｚｉｐ）など）を含む。データアクセス機能によりＳＱＬ問い合わせの分析が可能となる。通知機能はＥメールおよびＳＮＭＰを含む。

“ルール”（Ｒｕｌｅｓ）のダイナミックな組み込みは、条件の評価および動作の実行を含むことができ、自動化されたタスクデータ分析、データ配信、通知およびプロアクティブな動作（“ａｃｔｉｏｎｓ”）を含む（上記段落番号０１１１および０１１２を参照すると、このことは、特許されつつある、又は、単に参照した情報か？）。

図３１は、代表的なダイナミックデータ制御（ＤＤＣ）サーバーコンフィギュレーション２４６を示し、ＤＤＣサーバーコンフィギュレーション２４６はＤＤＣアプリケーション２４８、エージェント２５０、データ記憶装置２５２およびＸＭＬ２５４を含む。

図３２は、代表的なホーム（ｈｏｍｅ）またはサイトコンフィギュレーションを示す。サイト２７４はサイトサーバー２５６と通信可能に結合された種々の計算デバイスを含むように示されている。計算デバイスはタワー２５８と、デスクトップコンピュータ２６０とノートブックコンピュータ２６２を含む。サイト２５４は４つのホームサーバー２６８を含むように示されているデータセンター２６６とインターネット２６４を介して通信可能に結合されている。

図３３は、マルチサイト（ｍｕｌｔｉｐｌｅ ｓｉｔｅｓ）２７０のための代表的なインフラストラクチャを示す。これらサイト２７０はインターネット２７２を介してデータセンター２７４と通信可能に結合されている。ここでは、この明細書および関連する図面全体にわたり、インターネットを参照する。かかる参照をする場合、意味するものはフルタイムの公衆ネットワークであると理解すべきである。インターネットは単なるかかる１つのネットワークにすぎず、便宜上インターネットを参照するが、インターネットは発明の開示の教示内容の適用範囲を制限するものではない。

開示されたシステムは、臨床研究を管理するためのシステムを創出するためのＤＤＣ技術を利用している。

このＤＤＣ技術により、研究のライフサイクル（ｓｔｕｄｙ ｌｉｆｅｃｙｃｌｅ）の管理が可能となっている。このシステムは、ＸＭＬプロトコル仕様を構成し、サイトに対し、システムおよびプロトコル仕様を配備し、患者情報を入力し、追跡し、実験の時間分析（ｔｒｉａｌ−ｔｉｍｅａｎａｌｙｓｉｓ）、通知および在庫管理の追跡を提供できる。更にこのシステムは研究ロケーションからデータを収集し、収集したレポートおよびバイオスタット（ｂｉｏｓｔａｔｓ）を作成できる。

このシステムでは、認可されたユーザー、サイトおよびプロトコルパラメータ；事象通知および受信者；レポートのタイプ；およびランダム化方法に対して、カスタム化可能である。

上記のように、このシステムは安全なデータ伝送、ファイアウォール保護、オンサイトサーバ、監査トレイルおよびメッセージトラッキングならびにユーザー管理を使用するＨＩＰＰＡコンプライアントな国際バンキングセキュリティグレードであることによって安全となっている。

プロトコル情報はスクリーニング、患者管理、情報およびドキュメント管理、および在庫管理を含む。

サイトから製薬会社によってサイト情報にアクセスできる。かかるサイト情報はスクリーニングされた番号、登録、スクリーンの障害および故障表示の数、取り下げおよび脱落（ｗｉｔｈｄｒｏｗａｌｓ ａｎｄ ｄｒｏｐｓ）、デモグラフィック、インベントリ、コンタクト情報および悪い事象（ＡＥ）および深刻な悪い事象（ＳＡＥ）を含むことができる。

患者情報は、訪問、被験者情報およびドキュメント、フォームならびにレポートを含むことができる。訪問情報は評価情報、スケジュールおよびランダム化ならびに棚卸しを含むことができ、被験者情報は医療プロファイルおよび研究の参加を含むことができ、ドキュメント、フォームおよびレポートはケースレポートフォーム（ＣＲＦ）およびソースドキュメント、ＡＥおよびＳＡＥ、および機関検討評議会（Ｉｎｓｔｉｔｕｔｉｏｎａｌ Ｒｅｖｉｅｗ Ｂｕａｒｄ：ＩＲＢ）および規制ドキュメント（ｒｅｇｕｌａｔｏｒｙ ｄｏｃｕｍｅｎｔｓ）を含むことができる。

インベントリ情報はキットランダム化の追跡（ｔｒａｃｋ ｋｉｔ ｒａｎｄｏｍｉｚａｔｉｏｎ）、サイトとの間の出荷の追跡（ｔｒａｃｋ ｓｈｉｐｐｉｎｇ ｔｏ ａｎｄ ｆｒｏｍ ｓｉｔｅ）、テスト物品の追跡（ｔｒａｃｋ ｔｅｓｔ ａｒｔｉｃｌｅ）を含むことができ、カスタム在庫管理を容易に創出し、統合することができる。

開示されたシステムの自動化されたタスクは、自動化されたエージェントタスク、例えばデータのアップロード、プロトコル変更のダウンロード、深刻な事象の通知、不正の検出、自動レポート、トレンド分析およびメッセージの配布を含む。

研究に関連するレポート、グラフおよびチャートは研究全体にわたって利用できる定量的履歴分析、ＡＥおよびＳＡＥ情報、研究メトリックスおよびデモグラフィックスおよび研究リストならびに問い合わせを含むことができる。

ドキュメント管理はソースドキュメントおよびＣＲＦだけでなく、ＩＲＢおよび規制ドキュメントも含む。ソースドキュメントおよびＣＲＦはリアルタイムでの利用可能性を受け、認可されたユーザーによってアクセスでき、プリントしたり、またスクリーン上で見ることができ、一般に問い合わせは容易に解決される。ＩＲＢおよび規制ドキュメントは電子データ転送を活用でき、リアルタイムでアクセスできる。

システムの管理能力によって、システムは患者データベースを維持し、プロトコル情報を作成し、更新し、ランダム化のタイプを判断し、投与およびキットのインベントリをモニタし、ケースレポートフォームのようなドキュメントを見ることができる。

例：プロトコルの発生
この章はプロトコルのＸＭＬ表示（プロトコル表示）を作成するのに使用される本発明にかかわるプロセスの一例について説明する。このプロトコル表示は次に実行パラメータへの開示システムのアプリケーションへの入力として使用でき、オリジナルのプロトコルが定める研究を実行するのに必要なデータフォーム、レポートおよび事象モニタを提供できる。開示システムのソリューションに対する１つの主な利点は、研究に変更を組み込まなければならないときに、これら変更をこのドキュメントで後に定めるように即座に作成し、かつ配信できるということである。これら変更はプロトコル表示に反映され、追加データフィールド、トレンド分析アルゴリズムおよび事象コンタクト情報を含むことができる。次のプロセスチャートはプロトコル表示の発生およびステップに関する添付情報の発生を実行するのに必要な主なステップをリストアップするものである。

同時に発生し得るプロトコル発生プロセスの必ずしも一部ではない、特定されない一部のステップおよびプロセスがある。これらは実行プラン、コスト分析などの評価を含む。

例：基本プロトコル情報
図２を参照して基本プロトコル情報のアスペクト（ＢＰＩ）について上述した。このＢＰＩはインターネットに基づくグラフィックツールであり、このツールは認可されたユーザープロトコルを取り込み、ＸＭＬ仕様（プロトコル表示）を作成するのに使用される。このＸＭＬ仕様は、開示システムが使用し、プロトコルが定める研究を実行するのに必要なインターフェースおよび機能を提供する。ＢＰＩはプロトコル表示を作成するのに必要なステップを通し、ユーザーをガイドするウィザードに基づくアプリケーションである。ＢＰＩの一部により、ユーザーはプロセス内で任意の時間に作業の結果を検討することが可能となる。プロセス表示の中間バージョン（またはドラフト）は、認可されたユーザーに対して完成したバージョンと同じように利用できるようになる。次の記載はＢＰＩを使ってプロセス表示を作成する際に関係する基本ステップおよび能力を説明するものであり、プロセスチャートはこれを使用するための方法を定める。

例：特定のプロトコルの作成
図３４は本発明の一実施例に従って、ＸＭＬに基づく表示を使用するプロトコルを定めるためのプロセスフローを示す。まずプロトコルを受信し（２７６）、プロトコル表示を作成する（２７８）。要件が満たされているかどうかを判断する（２８２）ために、インターフェースを実証する（２８０）。要件が満たされていなければ、インターフェースを変え、再び実証する（２８０）。

インターフェースが要件を満たせば、サイトサーバーを構成し（２８４）、エージェントＸＭＬを作成する（２８６）。次に通知および自己事象（ａｕｔｏ−ｅｖｅｎｔｓ）をテストする（２８８）。要件が満たされていなければ、エージェントＸＭＬを変え（２８６）、通知および自己事象を再テストする（２８８）。

通知および自己事象が正しく機能していれば、ホームサーバーを構成する（２９２）。ホームサーバーを構成した（２９２）後に、すべてのサービスを有効にする（２９４）。すべてのサービスの有効化（２９４）が完了すると、プロトコル仕様を記憶（２９６）し、備えつけるためにプロトコルを利用可能とする（２９８）。

例：特定のシステムのコンフィギュレーション
この例は４つの基本的なタイプのシステムをカバーするものである。これらシステムのうちの３つはカスタマーに利用でき、第４のシステムはサービスの実行（ｐｅｒｆｏｒｍａｎｃｅ）によって利用され、全体のシステムコンフィギュレーションにおける一部の役割を果たす。

グローバル認可ユーザー、サイトおよびプロトコル表示を維持し、作成するためのプロトコル表示“標準”情報を含む選択された安全なロケーションにコーポレート（会社の）サーバーシステムが設けられている。データセンターにはホームサーバーシステムが設けられており、開示システムを使用する各サイトにサイトサーバーシステムが設けられている。最後に、フィールドにデータを収集するために多数の一般的にモバイルな衛星システムが設定されている。

コーポレートサーバーは、データセンターに常駐するシステムである。この常駐位置はＢＰＩおよびその他のツールが共通グローバルレファレンスのために使用できるプロトコル表示のための共通情報と同じように、“マスター”プロトコル表示およびそれらのバージョンが維持されるロケーションとなっている。この情報はデフォルトデータの定義および制限値だけでなく、ディスプレイデフォルト、医学用語辞書、付随する薬による治療のレファレンスおよび同様なタイプの情報も含む。このサーバーは一般的にはカスタマーには利用できないが、このサーバーでのサービスを使用したり、変更したりする任務を有し、それを許可されているスタッフには利用できる。

ホームサーバーはデータセンターに常駐するシステムである。この場所特定の研究（プロトコル）のための種々のサイトからのすべてのデータを収集する場所である。ホームサーバーは研究のためのすべてのパラメータおよびデータを定める“マスター”プロトコル表示仕様も含む。本例では、ホームサーバーは認可されたユーザーおよび外部の研究参加者が望む情報を見るために、これらのものがアクセスするシステムでもある。

サイトサーバーとは、研究が行われている各ロケーションに常駐するシステムである。同じサイトサーバーを使用するサイトにおいて、多数の研究を同時に行うことができ、指定された間隔でホームサーバーに情報が送られる。サイトサーバーは衛星マシンからのデータを収集することだけでなく、これらのデータを現在のプロトコル表示に合わせてアップデートしておく責任を果たす。

衛星とは、実際にデータ入力が行われるシステムである。衛星はホームサーバーで変わることなく終了するサイトサーバーのためのデータを提供する。これらシステムは基本的には任意のタイプのシステムでよく、２つの異なるモードで使用できる。衛星システムを実現するハードウェアのタイプはカスタマー要求に応じて決まるが、本例におけるターゲットプラットフォームはタブレットＰＣでもよい。これらはデータ入力のための多数のオプションを提供し、“ペーパーレス”での研究への移行を容易にしなければならない。衛星はサイトサーバーへのインターネットクライアントとして作動でき、無線コンフィギュレーションを介して接続できるか、またはスタンドアローンシステムとして作動し、“ドッキング”されたときにサイトサーバーへ情報を転送する。これによってフレキシビリティおよびカスタマーの選択が最大となる。

例：データの同期状態の維持
研究の際に変化が起きるのは極めて一般的なことである。これら変化は被験者、レポートの定義、特定の事象、トレンド分析、通知リストなどから検索されている情報となり得る。開示システムはこれらすべてを定めるのにプロトコル表示を使用しているので、システム自身は適正なときにプロトコル表示の新しいバージョンを探す。次の表は新しいプロトコル表示を使用するために本例で使用されるプロセスの概略を示すものである。

例：ドキュメント管理
開示システムの主な機能および能力はドキュメント管理にある。開示システムの目的は、研究中に使用されるペーパーの量を大幅に削減または解消することにあるが、研究の種々の部分でまだペーパードキュメントが使用されることが予想され、（ＦＤＡを含む）研究の実行に適用される種々の規格との法律の順守を維持するために、これらドキュメントは管理されなければならない。これらドキュメントはソースドキュメントと見なされ、データの元のソースとして利用できるものでなければならない。これら規格を満たし、ユーザーに真に統合されたシステムを提供するために、開示システムはいくつかの対応する能力を提供する。

認可されたフォーマットで直接開示システムにドキュメントをスキャンするためにスキャナーが、適用可能な場合にはあらかじめ構成されて、供給される。開示システムのアプリケーションによりドキュメントが発見され、データフォーム、または潜在的には他のドキュメント管理機能に関連するように利用可能とされる。ユーザーはスキャンの質を見ることが許され、必要な場合に“再スキャン”を行うことができる。一旦スキャンを実行すると、スキャンされたドキュメントはシステムのユーザーによる更なる処理を待つ関連していないロケーションへ移行される（ｍｉｇｒａｔｅｄ）。スキャンの時間に関する情報も記録される。

ドキュメントは研究に対応するデータを含むが、ドキュメント上の情報は必ずしも共通するフォーマットとなる必要もなければ、研究が必要とする情報に整合するように構成する必要もない。開示されたシステムはドキュメントを特定の訪問またはデータフォーム（例えばインベントリ）に関連付ける能力を含む。ユーザーは２つの方法のうちの１つでデータのフォームをドキュメントに関連付けできる。第１の方法は、“関連付けされていない”ドキュメントのリストを見て、次にドキュメントを特定の被験者およびデータフォームに関連付けるために、すべての情報に関してユーザーに問い合わせをする“関連付け”機能を選択することである。第２の方法は、ターゲット被験者（ｔａｒｇｅｔ ｓｕｂｊｅｃｔ）を選択し、適当なデータフォームをイネーブルし、ユーザーがドキュメントを被験者およびデータフォームに関連付けできるようにする“アタッチ”機能を選択することである。関連付けの時間、文書の作成元、および関連付けを実行したユーザーに関するすべての情報が記録される。

ドキュメントは研究の一部であるので、これらドキュメントはサイトおよびホームサーバーに記憶し、プロトコルが必要とするようなレポートおよび規制されたドキュメント（ｒｅｇｕｌａｒｔｏｒｙ ｄｏｃｕｍｅｎｔｓ）を作成するのに利用できるようになっていなければならない。開示されたシステムはドキュメントが一旦システム内に統合されると、これらドキュメントへのアクセスを必要とするシステムのすべてのドキュメントの拡散（ｐｒｏｌｉｙｅｒａｔｉｏｎ）を取り扱う。リモートロケーション、例えば病院またはモバイルユニットからドキュメントがスキャンまたはファックスされた場合、このドキュメントは開示システムのメッセージセンターまたはＥメールを介して送ることができ（もしオリジナルのドキュメントを有するものがメッセージセンターにアクセスすることが可能であれば）、その後、ドキュメントは研究と統合される。

多くのスキャンされるドキュメントは開示されたシステムにまだ入力されていない情報を含むことが予想される。従って、開示システムはドキュメントをスキャンするか、または現在のスキャンされた画像を取り込み、種々のテキストスキャン機能を使って派生できるデータに関してドキュメントを検査する能力を提供する。この同じ技術を使って、バーコードまたはドキュメント番号によりドキュメントを識別するだけでなく、バーコードおよび／またはユーザー識別コードによりターゲットの被験者を識別することもできる。

多くの場合においてデータを入力するための電子手段を設けても、書面のテキストに変換されるものではないし、データ収集またはプリントされたページのレイアウトのために必ずしも役立つわけではない。開示したシステムはデータ値を有するか、または有しないデータフォームをプリントする手段を提供し、この手段が提供する情報は対応する電子情報（ｅｌｅｃｔｒｏｎｉｃ ｃｏｕｎｔｅｒｐａｒｔ）と同じ順序での同じ情報であり、データフォームとして使用でき、その後、開示システムにスキャンまたは関連付けされるペーパーコピーを提供する。開示されたシステムの衛星またはデータ入力システムを設けることが不可能または現実的でないか、または利用できないような状況で有効である。このことは、特定の研究に対するペーパーのバックアップを必要とするサイトでも使用できる。

図３５は、薬学的研究およびレポート作成の自動化された管理をするための、本発明の方法およびシステムの一実施例を使用するための、かかる計算システムのうちのネットワークの一部となり得る汎用計算システムを示す。本発明は汎用コンピュータ３００のネットワークを関連させることにより、医薬の開発に必要なコストおよび時間の削減を容易にするものである。本発明により設定される電子伝達環境では、所定の地理学的、または同様な境界が定められたエリア内の異なるロケーションで少なくとも２つのかかるコンピュータを作動できる。

図３５を参照すると、汎用コンピュータ３００はパソコン、ラップトップ、パームトップまたはその他のセットトップ、サーバー、メインフレーム、その他の種々のコンピュータでよく、処理ユニット３０２と、システムメモリ３０４と、システムメモリ３０４を含む種々のシステムコンポーネントを処理ユニット３０２に結合するシステムバス３０６とを含む。処理ユニット３０２は、Ｉｎｔｅｌｘ８６、Ｐｅｎｔｉｕｍ（登録商標）およびインテル（登録商標）およびＣｙｒｉｘ（登録商標）、ＡＭＤ（登録商標）およびＮｅｘｇｅｎ（登録商標）を含むその他の会社からのコンパチマイクロプロセッサ；ＭＩＰＳ Ｔｅｃｈｎｏｌｏｇｙ（登録商標）、ＮＥＣ（登録商標）、Ｓｉｅｍｅｎｓ（登録商標）およびその他からのＭＩＰＳ（登録商標）およびＩＢＭおよびＭｏｔｏｒｏｌａからのＰｏｗｅｒＰＣ（登録商標）を含む種々の市販されているプロセッサのうちのいずれかでよい。処理ユニット３０２としてデュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャも使用することができる。

システムバス３０６はメモリバスまたはメモリコントローラ、周辺バスおよび種々の従来のバスアーキテクチャ、例えばＰＣＩ、ＶＥＳＡ、ＡＧＰ、マイクロチャンネル、ＩＳＡおよびＥＩＳＡのいずれかを使用するローカルバスを含む種々のタイプのバス構造のいずれかでよい。システムメモリ３０４はリードオンリーメモリ（ＲＯＭ）３０８およびランダムアクセスメモリ（ＲＡＭ）３１０を含む。ＲＡＭ３０８には、例えばスタート時の、コンピュータ３００内での素子間の情報の転送を助ける基本ルーチンを含む基本的な入出力システム（ＢＩＯＳ）が記憶されている。

コンピュータ３００はリムーバルディスク３１６およびＣＤ−ＲＯＭドライブ３１８との間で読み出し、書き込みをし、ＣＤ−ＲＯＭディスク３０２を読み出し、または他の光メディアとの間で読み出しおよび書き込みをするための、ハードディスクドライブ３１２、フロッピー（登録商標）ドライブ３１４を更に含む。ハードディスクドライブ３１２、フロッピー（登録商標）ドライブ３１４およびＣＤ−ＲＯＭドライブ３１８はそれぞれハードディスクドライブインターフェース３２２、フロッピー（登録商標）ドライブインターフェース３２４および光ドライブインターフェース３２６により、システムバス３０６に接続されている。これらドライブおよび関連するコンピュータで読み取り可能なメディアは、例えばコンピュータ３００のためのデータ、データ構造、コンピュータで実行可能な命令などを不揮発記憶する。上記コンピュータで読み取り可能なメディアの説明は、ハードディスク、リムーバルフロッピー（登録商標）およびＣＤについて述べているが、当業者であればコンピュータで読み取り可能な他のタイプのメディア、例えば磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジおよび作動環境で使用されているその他の類似物を考えつくことができよう。

ドライブおよびＲＡＭ３１０にはオペレーティングシステム３２８、１つ以上のアプリケーションプログラム３３０、その他のプログラムモジュール３３２およびプログラムデータ３３４を含む多数のプログラムモジュールを記憶できる。消費者はキーボード３３６およびポインティングデバイス、例えばマウス３３８を使ってコンピュータ３００内にコマンドおよび情報を入力できる。その他の入力デバイス（図示せず）として、マイク、ジョイスティック、ゲームパッド、衛星ディッシュアンテナ、スキャナまたはその他のものを挙げることができる。これらデバイスおよびその他の入力デバイスはシステムバスに結合されているが、可能な場合には他のインターフェース、例えばパラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）により接続されたシリアルポートインターフェース３４０を介して処理ユニット３０２に接続されることが多い。インターフェース、例えばビデオアダプタ３４４を介してシステムバス３０６にはモニタ３４２またはその他のタイプのディスプレイデバイスも接続されている。モニタの外に、コンピュータは一般にその他の周辺デバイス（図示せず）、例えばスピーカーおよびプリンタを含む。

コンピュータ３００は１つ以上のリモートコンピュータ、例えばリモートコンピュータ３４６へのロジカル接続を使用するネットワーク化された環境内で作動できる。リモートコンピュータ３４６はサーバー、ルーター、ピアデバイスまたはその他の共通ネットワークモードでよく、一般的にはコンピュータ３００に関して説明した要素の多くまたはすべてを含むが、図３５にはメモリ記憶デバイス３４８しか示されていない。図３５に示されたロジカル接続部はローカルエリアネットワーク（ＬＡＮ）３５０およびワイドエリアネットワーク（ＷＡＮ）３５２を含む。かかるネットワーク環境はオフィス、企業のワイドコンピュータネットワーク、イントラネットおよびインターネットで一般的なものである。

ＬＡＮネットワーク環境で使用されるときに、コンピュータ３００はネットワークインターフェースまたはアダプタ３５４を通してＬＡＮ３５０に接続される。ＷＡＮネットワーク環境で使用するときに、コンピュータ３００は、ワイドエリアネットワーク３５２、例えばインターネットを通して（例えばＬＡＮ３５０およびゲートウェイまたはプロキシサーバーを通し）通信を設定するためのモデム３５６または他の手段を一般に含む。内部式または外部式とすることができるモデム３５６は、シリアルポートインターフェース３４０を介し、システムバス３０６へ接続される。ネットワーク化された環境では、コンピュータ３００またはその一部に対して示されたプログラムモジュールをリモートメモリ記憶デバイス３４８内に記憶できる。

当業者であれば、ネットワーク接続は単なる例として示されているものであることが理解できよう。この場合、コンピュータ間の通信リンクを設定するためのその他の手段を使用できる。図３５は、本発明の要旨を利用するために有効なコンピュータの一例しか示していない。本発明は汎用コンピュータ以外のコンピュータだけでなく、従来のオペレーティングシステムを有しない汎用コンピュータでも使用できる。

本明細書で引用する刊行物、特許出願および特許を含むすべての参考例は、あたかも参考例として援用するように各参考例が個々に、かつ特別に表示され、かつ全体が本明細書で記載されているかのように同じ程度に参考例として援用するものである。

発明を説明する文脈における（特に次の特許請求の範囲のコンテクストにおける）「ａ」「ａｎ」ならびに「ｔｈｅ」なる用語、および同様な引用の使用は、特に表示したり、または文脈と明らかに矛盾しない限り、単数および複数の双方をカバーするものと見なすべきである。「含む」、「有する」、「備える」なる用語は、特に記載しない限りオープンエンドの用語（すなわち、〜を含むが、これだけに限定されないという意味）である。本明細書の値の範囲の記載は特に記載しない限り、その範囲内に入る別個の各値を個々に意味する簡潔な方法として働くものであり、各別個の値は本明細書で個々に記載されているかのように明細書に組み込まれている。本明細書に記載のすべての方法は、特に表示しない限り、または文脈と明確に矛盾しないかぎり、任意の適当な順で実行できる。本明細書に記載した任意の例およびすべての例、または言語（例えば「例えば」）の使用は、本発明を良好に示すためのものに過ぎず、特に請求しない限り、発明の範囲を限定するものではない。本明細書における用語は発明を実施するのに不可欠な、請求項に記載しない要素を示すものとして見なしてはならない。

本明細書には発明を実施するために本発明者が知る最良の態様を含む、本発明の好ましい実施例について説明した。これまでの説明を当業者が読めば、当業者には好ましい実施例の変形例が明らかとなろう。本発明者は当業者がかかる変形例を適当に使用することを期待し、本発明者は本明細書に特別に記載した態様以外で発明を実施できることを期待する。従って、本発明は適用可能な法律が認めるような、添付した特許請求の範囲に記載の要旨のすべての変形例および均等物を含むものである。更に、本発明のすべての可能な変形例における上記要素の任意の組み合わせは、特に記載しない限り、または特に文脈と明らかに矛盾しない限り、本発明に含まれるものである。

本発明の一実施例に係わるデータベース構造の概観を示す。 本発明の一実施例に係わる基本プロトコル情報（ＢＰＩ）アスペクトを示す。 本発明の一実施例に係わるプログラムの出荷アスペクトを示す。 本発明の患者情報部分を示し、本発明の一実施例に従い、時間フレーム内で患者のスケジュールが定められる。 本発明の一実施例に係わる患者スケジュールを示すブロック図である。 本発明の一実施例に係わる更新アスペクトを示す。 本発明の一実施例に係わるユーザーのフィンガーチップにおける研究からすべての情報を提供するレポート作成アスペクトを示す。 本発明の一実施例に係わる患者訪問を示すプロセスフローチャートである。 本発明の一実施例に係わる認可ユーザー情報インターフェースを示す。 本発明の一実施例に係わるコンタクト情報インターフェースを示す。 本発明の一実施例に係わるプロトコル情報インターフェースを示す。 本発明の一実施例に係わる構造情報インターフェースを示す。 本発明の一実施例に係わる訪問情報インターフェースを示す。 本発明の一実施例に係わる訪問情報インターフェースを示す。 本発明の一実施例に係わる選択サイトおよびコンタクトインターフェースを示す。 本発明の一実施例に係わる選択サイトおよびコンタクトインターフェースを示す。 本発明の一実施例に係わる患者情報インターフェースを示す。 本発明の一実施例に係わる本発明と共に使用するための患者バーコードを示す。 本発明の一実施例に係わるスクリーニング訪問インターフェースを示す。 本発明の一実施例に従い、患者を検査しているプロトコルを選択するインターフェースを示す。 本発明の一実施例に従い、スクリーンに示されたスクリーニング訪問評価を示す。 本発明の一実施例に従い、ユーザーに対する現在の回答のすべてをチェックできるようにするインターフェース上のプログラムを示す。 本発明の一実施例に係わる患者訪問インターフェースを示す。 本発明の一実施例に係わる患者スケジュールインターフェースを示す。 本発明の一実施例に係わる認可ユーザー、サイト、調査員および研究コーディネータを含む多数のユーザーによりレポートをプリントし、Ｅメールし、またはスクリーンで見ることを示す。 本発明の一実施例に係わるサンプル研究メトリックスレポートを示す。 本発明の一実施例に係わる患者訪問０１のランダム化プロセスおよびレポート作成のために使用される認可ユーザーおよびサイトチェック棚卸しインターフェースを示す。 本発明の一実施例に係わるネットワークの概観を示す。 本発明の一実施例に係わる仕様から研究の実現まで流れる情報を示す。 本発明の一実施例に係わる定量的かつ履歴分析を実行するのに利用できるグラフィック表示を含むインターフェースを示す。 本発明の一実施例に係わる代表的なダイナミックデータ制御サーバーコンフィギュレーションを示す。 本発明の一実施例に係わる代表的なホーム／サイトコンフィギュレーションを示す。 本発明の一実施例に係わる、インターネットを通してネットワーク化するための代表的なインフラストラクチャを示す。 本発明の一実施例に係わる、ＸＭＬに基づく表示を使用してプロトコルを定めるためのプロセスフローを示す。 本発明の自動化された薬学的研究およびレポート作成のための方法およびシステムの一実施例を使用するためのかかる計算システムのネットワークのうちの一部とすることができる、汎用計算システムを示す。

Claims (20)

1. ユーザーがデータを入力する際にデータが通過するインターフェースを設けることにより、電子データ捕捉を使用し、一次臨床実験データを収集するようになっている少なくとも１つの計算デバイスに各々が関連し、通信可能に結合されている少なくとも１つのサイトサーバーと、
   ネットワークを介し、各サイトサーバーに通信可能に結合されると共に、前記ネットワークを介し、認可されたユーザーがアクセス可能な計算デバイスに通信可能に結合された中央サーバーとを備え、
   一次臨床実験データを収集するようになっている各計算デバイスが入力されたデータを有効化するようになっており、
   各サイトサーバーが一次臨床実験データを中央サーバーに送信するようになっており、
   前記中央サーバーが、
   各サイトサーバーからの一次臨床実験データを受信し、
   一次臨床実験データを記憶し、
   前記一次臨床実験データに基づき、二次臨床実験データを作成し、
   前記一次および二次臨床実験データを認可されたユーザーがアクセス可能な計算デバイスへ送信するようになっている、医薬研究およびレポートの作成を促進する、薬学的研究のための臨床実験を自動的に管理するためのシステム。
2. 前記一次臨床実験データが患者データを含む、請求項１記載のシステム。
3. 前記二次臨床実験データが完全な監査トレールを含む、請求項１記載のシステム。
4. 前記二次臨床実験データが前記一次臨床実験データのアルゴリズム分析により、前記一次臨床実験データに基づいて作成された研究メトリックスを含む、請求項１記載のシステム。
5. 前記中央サーバーが更に「即日」のレポートを認可されたユーザーがアクセス可能な計算デバイスへ送信するようになっている、請求項１記載のシステム。
6. 前記中央サーバーが、
   更に認可されたユーザーによってアクセス可能な計算デバイスを使用する、認可されたユーザーによって前記管理された臨床実験に関連するインベントリを管理できるようにする、認可されたユーザーによってアクセス可能な計算デバイスへデータを送信するようになっている、請求項１記載のシステム。
7. 前記中央サーバーが、
   認可されたユーザーによってアクセス可能な計算デバイスを使用する、認可されたユーザーが管理された臨床実験のオンラインモニタおよび監査を実行できるようにする、認可されたユーザーによってアクセス可能な計算デバイスへデータを送信するようになっている、請求項１記載のシステム。
8. 前記ネットワークが更に、フルタイムの公衆アクセスネットワークを備え、更に中央サーバーを備え、該中央サーバーがフルタイムの公衆アクセスネットワークを介し、各サイトサーバーへ通信可能に結合されると共に、前記フルタイムの公衆アクセスネットワークを介し、認可されたユーザーがアクセス可能な計算デバイスへ通信可能に結合されている、請求項１記載のシステム。
9. 前記フルタイムの公衆アクセスネットワークが安全チャンネルを更に備え、更に中央サーバーを備え、該中央サーバーが安全チャンネルを使用するフルタイムの公衆アクセスネットワークを介し、各サイトサーバーに通信可能に結合されると共に、前記安全チャンネルを通し、前記フルタイムの公衆アクセスネットワークを介し、認可されたユーザーがアクセス可能な計算デバイスに通信可能に結合されている、請求項８記載のシステム。
10. 薬学的研究およびレポートの作成を促進するよう、薬学的研究のための臨床実験を自動的に管理するための方法において、
    一次臨床実験データを収集するようになっているインターフェースと共に構成された計算デバイスのユーザーによる使用によって、一次臨床実験データに対応する電子データを捕捉するステップと、
    電子データを有効化するステップと、
    前記データを有効化した後に、電子データをフルタイムの公衆ネットワークを通して対応する計算デバイスから中央サーバーへ配信するステップと、
    一次臨床実験データに基づき、二次臨床実験データを作成するステップと、
    前記一次および二次臨床実験データを記憶するステップと、
    認可されたユーザーがアクセスできる計算デバイスにより、フルタイムの公衆ネットワークを通してアクセスすべき中央サーバーにより、前記記憶された一次および二次臨床実験データを利用できるようにするステップとを備えた、臨床実験を自動的に管理するための方法。
11. 前記一次臨床実験データを収集するようになっているインターフェースと共に構成された計算デバイスのユーザーにより使用することにより、一次臨床実験データに対応するデータを捕捉する前記ステップが、
    患者情報を収集するようになっているインターフェースと共に構成された、計算デバイスのユーザーによる使用によって、患者情報に対応する電子データを捕捉するステップを備えた、請求項１０記載の方法。
12. 前記一次臨床実験データに基づき、二次臨床実験データを作成する前記ステップが、
    前記一次臨床実験データに基づき、全監査トレイルを作成するステップを含む、請求項１０記載の方法。
13. 前記一次臨床実験データに基づき、二次臨床実験データを作成する前記ステップが、
    前記臨床実験データのアルゴリズム分析により、前記一次臨床実験データに基づき、研究メトリックスを作成するステップを含む、請求項１０記載の方法。
14. 前記認可されたユーザーによってアクセスできる計算デバイスにより、フルタイムの公衆ネットワークを通してアクセスすべき中央サーバーにより、前記記憶された一次および二次臨床実験データを利用できるようにする前記ステップが、
    前記認可されたユーザーによってアクセス可能な計算デバイスにより、フルタイムの公衆ネットワークを通してアクセスすべき中央サーバーにより、「即日」のレポートを利用できるようにするステップを備えた、請求項１０記載の方法。
15. 前記認可されたユーザーによってアクセスできる計算デバイスにより、フルタイムの公衆ネットワークを通してアクセスすべき中央サーバーにより、前記記憶された一次および二次臨床実験データを利用できるようにする前記ステップが、
    前記認可されたユーザーによってアクセス可能な計算デバイスにより、フルタイムの公衆ネットワークを通してアクセスすべき中央サーバーにより、前記記憶された一次および二次臨床実験データを十分利用できるようにし、よって認可されたユーザーによってアクセス可能な計算デバイスを使用する認可されたユーザーが前記管理された臨床実験に関連するインベントリを管理できるようにするステップを含む、請求項１０記載の方法。
16. 前記認可されたユーザーによってアクセスできる計算デバイスにより、フルタイムの公衆ネットワークを通してアクセスすべき中央サーバーにより、前記記憶された一次および二次臨床実験データを利用できるようにする前記ステップが、
    前記認可されたユーザーによってアクセス可能な計算デバイスにより、フルタイムの公衆ネットワークを通してアクセスすべき中央サーバーにより、前記記憶された一次および二次臨床実験データを十分利用できるようにし、よって認可されたユーザーによってアクセス可能な計算デバイスを使用する認可されたユーザーが前記管理された臨床実験のオンラインモニタおよび監査を行うことができるようにするステップを含む、請求項１０記載の方法。
17. マウスおよびスクリーンディスプレイを備えたユーザーインターフェースを有する汎用コンピュータのための一組の命令を含む、コンピュータ間で伝搬可能なコンピュータで読み取り可能な信号において、
    前記命令の組が、
    前記マウスにより前記スクリーンディスプレイにディスプレイされているアイコンをユーザーが選択できるようにするための、前記ユーザーインターフェースに作動的に関連した入力ルーチンを備え、前記アイコンが前記コンピュータにアクセス可能なアプリケーションプログラムに関連しており、
    前記アプリケーションプログラムの実行が、
    一次臨床実験データを収集するようになっているインターフェースと共に構成された計算デバイスのユーザーによる使用によって、一次臨床実験データに対応する電子データを捕捉するステップと、
    電子データを有効化するステップと、
    前記データを有効化した後に、電子データをフルタイムの公衆ネットワークを通して対応する計算デバイスから中央サーバーへ配信するステップと、
    一次臨床実験データに基づき、二次臨床実験データを作成するステップと、
    前記一次および二次臨床実験データを記憶するステップと、
    認可されたユーザーがアクセスできる計算デバイスにより、フルタイムの公衆ネットワークを通してアクセスすべき中央サーバーにより、前記記憶された一次および二次臨床実験データを利用できるようにするステップとを備え、
    前記命令の組が更に、
    前記マウスを用い、ユーザーが選択した前記アプリケーションプログラムを実行するための実行ルーチンと、
    前記アプリケーションプログラムにより発生されたテキストまたは画像を前記スクリーンディスプレイにディスプレイするための、前記実行ルーチンに応答自在なディスプレイルーチンとを備えた、コンピュータで読み取り可能な信号。
18. 前記一次臨床実験データを収集するようになっているインターフェースと共に構成された計算デバイスのユーザーにより使用することにより、一次臨床実験データに対応するデータを捕捉する前記ステップが、
    患者情報を収集するようになっているインターフェースと共に構成された、計算デバイスのユーザーによる使用によって、患者情報に対応する電子データを捕捉するステップを備えた、請求項１７記載の信号。
19. 前記一次臨床実験データに基づき、二次臨床実験データを作成する前記ステップが、
    前記一次臨床実験データに基づき、全監査トレイルを作成するステップを含む、請求項１７記載の信号。
20. 前記認可されたユーザーによってアクセスできる計算デバイスにより、フルタイムの公衆ネットワークを通してアクセスすべき中央サーバーにより、前記記憶された一次および二次臨床実験データを利用できるようにする前記ステップが、
    前記認可されたユーザーによってアクセス可能な計算デバイスにより、フルタイムの公衆ネットワークを通してアクセスすべき中央サーバーにより、前記記憶された一次および二次臨床実験データを十分利用できるようにし、よって認可されたユーザーによってアクセス可能な計算デバイスを使用する認可されたユーザーが前記管理された臨床実験に関連するインベントリを管理できるようにするステップを含む、請求項１７記載の信号。