(57)【要約】【課題】遠隔臨床データ・エントリ・プロダクツを後置臨床データ管理システムに接続するためのシステムおよび方法を提供する。【解決手段】後置臨床定義が後置臨床データ管理システムを用いて設計されている（CDMS）（8−1）。この後置臨床定義は自動的に遠隔データ・エントリ（前置）検討定義に変換される（32−1）。前置検討定義が、前置RDEプロダクツをホスティングする遠隔コンピュータへ転送され、そこで臨床データの取得が調整される（1508）。後置臨床定義から前置検討定義への変換プロセスの間において、変換マップが作成される（1706）。この変換マップは、前置RDEプロダクツを使用して得た臨床データの、後置CDMSにより読み取られるフォーマットへの自動的変換を可能にする（1706）。臨床データは、前置RDEプロダクツをホスティングする遠隔コンピュータから検索され、これが手動による後置臨床定義/前置検討定義の矛盾する解決を生じさせることなく、自動的に行われる（1508）。【特許請求の範囲】
【請求項１】
後置臨床定義に基づいて前置検討定義を確定するための方法であって：
該後置臨床定義における第1の成分のセットを該前置検討定義における第2の成分のセットと適合させるため変換マップを作成するステップと；
該後置臨床定義におけるこの第1の成分のセット中の第1の成分をそれぞれ解析するステップと；
を具備してなり、該第1の成分のセット中の第1の成分のそれぞれについて、該解析ステップが：
(i) 該第1の成分に対応する変換マップに識別名を加えるステップと；
(ii) 第1の成分に対応する第2の成分を含むように前置検討定義を編集するステップと；
(iii) 該第1の成分に対応する前置検討定義中の第2の成分のアイデンティティを含むように変換マップを修正するステップと；
を含み、ここで、該解析ステップが完了したとき、上記変換マップは、該後置臨床定義および該対応する前置検討定義中の適合する第1および第2成分の記録を含むことを特徴とする方法。
【請求項２】
該後置検討定義が、オラクル(Oracle)臨床定義である請求項１記載の方法。
【請求項３】
該前置検討定義がマクロ検討定義である請求項１記載の方法。
【請求項４】
クライアント/サーバーシステムが特定の様式で機能するようにするために使用されるコンピュータ読み取り可能なメモリーであって：
後置臨床定義に従ってデータを保存することができる後置臨床データ管理システム（CDMS）と；
前置検討定義に従って臨床データを収集するための遠隔データ・エントリ・モジュールと；
該後置臨床定義を対応する前置検討定義に変換するためのマッパー(mapper)サーバー・モジュールであって、コンピュータ読み取り可能なメモリーに記憶されている実行可能な命令を含み；該実行可能な命令が：
該後置臨床定義中の第1の成分のセットを、対応する前置検討定義中の第2の成分のセットと適合させる変換マップを作成するための命令と；
該後置臨床定義中の第1の成分のセット内の各第1の成分を解析するための命令とを含み；ここで、該第1の成分のセット中の第1の成分の夫々について、この解析のための命令には；
(i) 該第1の成分に対応する変換マップに識別名を加えるための命令；
(ii) 第1の成分に対応する第2の成分を含むように対応する前置検討定義を編集するための命令；
(iii) 該第1の成分に対応する前置検討定義中の第2の成分のアイデンティティを含むように変換マップを修正するための命令が含まれ；
この解析のための命令が完了したとき、上記変換マップは、後置臨床定義および対応する前置検討定義中の適合する第1および第2成分の記録を含むことを特徴とするコンピュータ読み取り可能なメモリー。
【請求項５】
該後置検討定義が、オラクル(Oracle)臨床定義である請求項４記載のコンピュータ読み取り可能なメモリー。
【請求項６】
該前置検討定義がマクロ検討定義である請求項４記載のコンピュータ読み取り可能なメモリー。
【請求項７】
プロセッサーを有するコンピュータとの関連で使用されるコンピュータ・プログラム・プロダクツであって；
該コンピュータ・プログラム・プロダクツが、コンピュータ読み取り可能な記憶媒体と、その中に埋め込まれたコンピュータ・プログラム機構とを具備してなり、該コンピュータ・プログラム機構が後置臨床定義に基づいて前置検討定義を確定するためのものであり、かつ、上記プロセッサーを介して以下のステップを実行させるものであることを特徴とするコンピュータ・プログラム・プロダクツ：
該後置臨床定義における第1の成分のセットを該前置検討定義における第2の成分のセットと適合させるため変換マップを作成するステップと；
該後置臨床定義におけるこの第1の成分のセット中の第1の成分をそれぞれ解析するステップと；
からなり、該第1の成分のセット中の第1の成分のそれぞれについて、該解析ステップが：
(i) 該第1の成分に対応する変換マップに識別名を加えるステップと；
(ii) 第1の成分に対応する第2の成分を含むように前置検討定義を編集するステップと；
(iii) 該第1の成分に対応する前置検討定義中の第2の成分のアイデンティティを含むように変換マップを修正するステップと；
を含み、ここで、該解析ステップが完了したとき、上記変換マップは、該後置臨床定義および該対応する前置検討定義中の適合する第1および第2成分の記録を含むことを特徴とするもの。
【請求項８】
該後置検討定義が、オラクル(Oracle)臨床定義である請求項７記載のコンピュータ・プログラム・プロダクツ。
【請求項９】
該前置検討定義がマクロ検討定義である請求項７記載のコンピュータ・プログラム・プロダクツ。
【請求項１０】
後置臨床定義に従って後置CDMS中の臨床データを記憶するための方法であって：
前置検討定義に従って臨床データを収集する遠隔データ・エントリ・モジュールから前置データ・パケットを得るステップと；
前置データ・パケットを解析するステップであって、ここで、該前置データ・パケット中の各患者について、該解析ステップが、患者についての前置検討定義前置検討定義/後置臨床定義適合データを変換マップに加入するステップを含み；
変換マップを使用して、後置データ・パケットを構築するステップと；
該後置データ・パケットを該後置データベースにアップロードし、それにより該後置臨床定義に従って該後置データベース内に該臨床データを記憶するステップと；
を具備してなる方法。
【請求項１１】
該解析ステップが更に、患者について設定された臨床識別名を照合するステップを含み、ここで、臨床識別名が患者について設定されていない場合は、該患者に関連する該パケット中のデータが拒否されることを特徴とする請求項１０記載の方法。
【請求項１２】
該後置検討定義が、オラクル(Oracle)臨床定義である請求項１０記載の方法。
【請求項１３】
該前置検討定義がマクロ検討定義である請求項１０記載の方法。
【請求項１４】
クライアント/サーバーシステムを特定の様式で機能させるようにして使用されるコンピュータ読み取り可能なメモリーであって：
後置臨床定義に従ってデータを保存することができる後置CDMSと；
前置検討定義に従って臨床データを収集するための遠隔データ・エントリ・モジュールと；
該遠隔データ・エントリ・モジュールにより収集された臨床データを該後置CDMS内に格納することができるフォームに変換させるためのサーバー・プロセス・モジュールと；
を具備してなり、ここで、該サーバー・プロセス・モジュールがコンピュータ読み取り可能なメモリーに記憶されている実行可能な命令を含み、該実行可能な命令が；
前置検討定義に従って該臨床データを収集する遠隔データ・エントリ・モジュールから前置データ・パケットを得るための命令と；
該前置データ・パケットを解析するための命令であって、該前置データ・パケット中の各患者について、該解析命令が、患者についての前置検討定義前置検討定義/後置臨床定義適合データを変換マップに加入することを含むものと；
変換マップを使用して、後置データ・パケットを構築するための命令と；
該後置データ・パケットを該後置CDMSにアップロードするための命令と；
を含むことを特徴とするもの。
【請求項１５】
該命令が更に、患者について設定された臨床識別名を照合する命令を含み、ここで、臨床識別名が患者について設定されていない場合は、該解析命令が該患者に関連する該パケット中のデータを拒否するための命令を含む請求項１４記載のコンピュータ読み取り可能なメモリー。
【請求項１６】
該後置検討定義が、オラクル(Oracle)臨床定義である請求項１４記載のコンピュータ読み取り可能なメモリー。
【請求項１７】
該前置検討定義がマクロ検討定義である請求項１４記載のコンピュータ読み取り可能なメモリー。
【請求項１８】
プロセッサーを有するコンピュータとの関連で使用されるコンピュータ・プログラム・プロダクツであって；
該コンピュータ・プログラム・プロダクツが、コンピュータ読み取り可能な記憶媒体と、その中に埋め込まれたコンピュータ・プログラム機構とを具備してなり、該コンピュータ・プログラム機構が後置臨床定義に従って後置CDMS中の臨床データを格納するためのものであり、かつ、上記プロセッサーを介して以下のステップを実行させるものであることを特徴とするコンピュータ・プログラム・プロダクツ：
前置検討定義に従って臨床データを収集する遠隔データ・エントリ・モジュールから前置データ・パケットを得るステップ；
前置データ・パケットを解析するステップであって、ここで、該前置データ・パケット中の各患者について、該解析ステップが、患者についての前置検討定義前置検討定義/後置臨床定義適合データを変換マップに加入するステップを含み；
変換マップを使用して、後置データ・パケットを構築するステップ；および
該後置臨床定義に従って、該後置データ・パケットを該後置データベースにアップロードするステップ。
【請求項１９】
該解析ステップが更に、患者について設定された臨床識別名を照合するステップを含み、ここで、臨床識別名が患者について設定されていない場合は、該患者に関連する該パケット中のデータが拒否されることを特徴とする請求項１８記載のコンピュータ・プログラム・プロダクツ。
【請求項２０】
該後置検討定義が、オラクル(Oracle)臨床定義である請求項１８記載のコンピュータ・プログラム・プロダクツ。
【請求項２１】
該前置検討定義がマクロ検討定義である請求項１８記載のコンピュータ・プログラム・プロダクツ。
【請求項２２】
後置CDMSで生じる食い違いを解決するための方法であって：
食違いに対応する臨床値を記憶するのに使用される後置フォーマットからの食違いを、前置検討定義に適合する前置検討定義フォーマットに変換するステップと；
該前置フォーマット中の食違いをこの食違いに関連する臨床値が記入された前置サイトに転送するステップと；
該前置サイトからの食違い応答を受理するステップと；
該食違い応答が食違いを解決する場合は、該食違い応答を格納するステップと；
を具備してなる方法。
【請求項２３】
該食違い応答が該食違いを以下のステップにより解決するか否かを判定するステップを更に含む請求項２２記載の方法：
(i) 該前置フォーマットからの食違い応答を該後置フォーマットに変換するステップ；および
(ii) 該食違い応答が該臨床値と関連するデータ・エントリ基準を満足することを照合するステップ。
【請求項２４】
該データ・エントリ基準がデータタイプ又はデータレンジ（range）である請求項２３記載の方法。
【請求項２５】
該食違い応答が該食違いを解決しない場合、該転送、受理および格納ステップを更に繰り返すことを含む請求項２２記載の方法。
【請求項２６】
該食違いを考慮してオージット・トレイルを更新するステップを更に含む請求項２２記載の方法。
【請求項２７】
オージット・トレイル内に該食違い応答を格納するステップを更に含む請求項２２記載の方法。
【請求項２８】
該CDMSが、（1）臨床値を記憶するためのデータベース；（2）統計を使用して臨床値を分析するためのSASモジュール；（3）ケース・レポートフォームに見出せないデータをロードするためのジェネリック・ローダー；（4）不都合な反応術語を調和させるシソーラスをアクセスするためのシソーラス・モジュール；（5）オージット・トレイルをアクセスするためのオージット・トレイル・モジュールを含む請求項２２記載の方法。
【請求項２９】
該変換ステップにおいて変換マップが使用され、該変換マップが、後置フォーマットにおける各質問およびイベント(event)と、前置検討定義における各質問およびイベントと間の1対1の対応を記憶する請求項２２記載の方法。
【請求項３０】
クライアント/サーバーシステムが特定の様式で機能するようにするために使用されるコンピュータ読み取り可能なメモリーであって：
後置臨床定義に従ってデータを保存することができる後置CDMSと；
前置検討定義に従って臨床データを収集するための遠隔データ・エントリ・モジュールと；
該後置CDMS中に生じる食違いを解決するためのマッパー(mapper)サーバー・モジュールであって、コンピュータ読み取り可能なメモリーに記憶されている実行可能な命令を含み；該実行可能な命令が：
該食違いに対応する臨床値を格納するのに使用される該後置臨床定義フォーマットからの該食違いを該前置検討定義フォーマットに変換させるための命令と；
該前置検討定義フォーマットにおける該食違いを、該食違いと関連する臨床値が記入された前置サイトに転送させるための命令と；
該前置サイトからの食違い応答を受理するための命令と；
該食違い応答が該食違いを解決する場合に、該食違い応答を該後置CDMSに格納するための命令と；
を含むことを特徴とするコンピュータ読み取り可能なメモリー。
【請求項３１】
該マッパー・サーバー・モジュールが、食違い応答が当該食違いを以下のステップにより解決するか否かを判定する命令を更に含む請求項３０記載のコンピュータ読み取り可能なメモリー：
(i) 該前置検討定義フォーマットからの食違い応答を該後置臨床定義フォーマットに変換するステップ；および
(ii) 該食違い応答が該臨床値と関連するデータ・エントリ基準を満足することを照合するステップ。
【請求項３２】
該データ・エントリ基準がデータタイプ又はデータレンジ（range）である請求項３１記載のコンピュータ読み取り可能なメモリー。
【請求項３３】
該食違い応答が該食違いを解決しない場合、該マッパー・サーバー・モジュールが該転送、受理および格納についての命令を更に繰り返す命令を含む請求項３０記載のコンピュータ読み取り可能なメモリー。
【請求項３４】
該マッパー・サーバー・モジュールが該食違いを考慮してオージット・トレイルを更新するための命令を更に含む請求項３０記載のコンピュータ読み取り可能なメモリー。
【請求項３５】
該メモリーが、該食違いを考慮してオージット・トレイルを更新するための命令の実行に応答して、該オージット・トレイルを更新するための命令を含むデータベース・モジュールを更に含む請求項３０記載のコンピュータ読み取り可能なメモリー。
【請求項３６】
該マッパー・サーバー・モジュールが該食違い応答を用いてオージット・トレイルを更新するための命令を更に含む請求項３０記載のコンピュータ読み取り可能なメモリー。
【請求項３７】
該メモリーが、該食違い応答を用いてオージット・トレイルを更新するための命令の実行に応答して、該オージット・トレイルを更新するための命令を含むデータベース・モジュールを更に含む請求項３６記載のコンピュータ読み取り可能なメモリー。
【請求項３８】
該後置CDMSが、（1）臨床値を記憶するためのデータベース；（2）統計を使用して臨床値を分析するためのSASモジュール；（3）ケース・レポートフォームに見出せないデータをロードするためのジェネリック・ローダー；（4）不都合な反応術語を調和させるシソーラスをアクセスするためのシソーラス・モジュール；（5）オージット・トレイルをアクセスするためのオージット・トレイル・モジュールを含む請求項３０記載のコンピュータ読み取り可能なメモリー。
【請求項３９】
該変換が変換マップを使用するものであり、該変換マップが、後置臨床定義における各質問およびイベント(event)と、前置検討定義における各質問およびイベントと間の1対1の対応を記憶する請求項３０記載のコンピュータ読み取り可能なメモリー。
【請求項４０】
プロセッサーを有するコンピュータとの関連で使用されるコンピュータ・プログラム・プロダクツであって；
該コンピュータ・プログラム・プロダクツが、コンピュータ読み取り可能な記憶媒体と、その中に埋め込まれたコンピュータ・プログラム機構とを具備してなり、該コンピュータ・プログラム機構がCDMS中に生じる食違いを解決するためのものであり、かつ、上記プロセッサーを介して以下のステップを実行させるものであることを特徴とするコンピュータ・プログラム・プロダクツ：
食違いに対応する臨床値を記憶するのに使用される後置フォーマットからの食違いを、前置検討定義に適合する前置検討定義フォーマットに変換するステップ；
該前置フォーマット中の食違いをこの食違いに関連する臨床値が記入された前置サイトに転送するステップ；
該前置サイトからの食違い応答を受理するステップ；および
該食違い応答が食違いを解決する場合は、該食違い応答を格納するステップ。
【請求項４１】
該コンピュータ・プログラム機構が、該食違い応答が該食違いを以下のステップにより解決するか否かを判定するものである請求項４０記載のコンピュータ・プログラム・プロダクツ：
(i) 該前置フォーマットからの食違い応答を該後置フォーマットに変換するステップ；および
(ii) 該食違い応答が該臨床値と関連するデータ・エントリ基準を満足することを照合するステップ。
【請求項４２】
該データ・エントリ基準がデータタイプ又はデータレンジ（range）である請求項４１記載のコンピュータ・プログラム・プロダクツ。
【請求項４３】
該食違い応答が該食違いを解決しない場合、該転送、受理および格納が繰り返される請求項４０記載のコンピュータ・プログラム・プロダクツ。
【請求項４４】
該コンピュータ・プログラム機構が更に、該プロセッサーを介して、該食違いを考慮してオージット・トレイルを更新させるステップを実行させるものである請求項４０記載のコンピュータ・プログラム・プロダクツ。
【請求項４５】
該コンピュータ・プログラム機構が更に、該プロセッサーを介して、該食違い応答をオージット・トレイル内に格納するステップを実行させるものである請求項４０記載のコンピュータ・プログラム・プロダクツ。
【請求項４６】
該後置CDMSが、（1）臨床値を記憶するためのデータベース；（2）統計を使用して臨床値を分析するためのSASモジュール；（3）ケース・レポートフォームに見出せないデータをロードするためのジェネリック・ローダー；（4）不都合な反応術語を調和させるシソーラスをアクセスするためのシソーラス・モジュール；（5）オージット・トレイルをアクセスするためのオージット・トレイル・モジュールを含む請求項４０記載のコンピュータ・プログラム・プロダクツ。
【請求項４７】
該変換が変換マップを使用するものであり、該変換マップが、後置フォーマットにおける各質問およびイベント(event)と、前置検討定義における各質問およびイベントと間の1対1の対応を記憶する請求項４０記載のコンピュータ・プログラム・プロダクツ。
【請求項４８】
後置臨床定義を前置検討定義に変換する方法であって：
該後置臨床定義を後置データ・パケットにフォーマットするステップであって、ここで、該後置データ・パケットが第1のパケット・ヘッダーと、第1の複数のデータ・セグメントとを含むものと；
該第1のデータ・パケットを受理するステップと；
該第1のデータ・パケットを前置データ・パケットに変換するステップであって、ここで、該前置データ・パケットが第２のパケット・ヘッダーと、第2の複数のデータ・セグメントとを含むものと；
該前置データ・パケットを移送させ、それにより該後置臨床定義を該前置検討定義に変換させるステップと；
を具備してなる方法。
【請求項４９】
該変換ステップが更に、該前置検討定義に従ってフォーマットされた臨床データを該後置臨床定義に従ってフォーマットされた臨床データに変換させる変換マップを構築するステップを含む請求項４８記載の方法。
【請求項５０】
臨床データを格納する方法であって：
該臨床データを前置データ・パケットにフォーマットするステップであって、ここで、該前置データ・パケットが第1のパケット・ヘッダーと、第1の複数のデータ・セグメントとを含むものと；
該第1のデータ・パケットを受理するステップと；
該第1のデータ・パケットを後置データ・パケットに変換するステップであって、ここで、該後置データ・パケットが第2のパケット・ヘッダーと、第2の複数のデータ・セグメントとを含むものと；
該後置データ・パケットを移送させ、それにより該臨床データを格納するステップと；
を具備してなる方法。
【請求項５１】
後置臨床定義における各成分を、対応する前置検討定義中の対応する成分と適合させるキー(key)を有する変換マップ。
【請求項５２】
各成分が、ビジット(visit)、フォーム又は質問のリストを含む請求項５１記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は大略的に、後置（back-end）臨床定義を、前置(front-end)検討（study）定義へ変換するためのソフトウエア・プログラムおよび方法に係わり、ここで後置臨床定義は臨床データ管理システムへのデータ・エントリのためのデータ構造およびレガシー・データ・エントリフォームを定義するものである。
【背景技術】
【０００２】
新たな薬が世界の多くの国で販売される前に、規定上の承認が認可されなければならない。この規定上の承認を得るための最も費用がかかり、かつ、困難な点は、臨床試験から統計的に有意なデータの提示である。典型的には、新たな薬の適用を支持するのに使用される臨床試験は3又はそれ以上の段階に分けられ、その内の最も顕著なものは,段階I、IIおよびIIIである。
【０００３】
段階Iは主に、その薬剤の安全性を評価するものである。ヒトにおける段階Iのテストは一般に20ないし200人の健康なボランテアに対してなされる。段階Iの臨床試験は患者においてその薬がどのようになるかを判定することである。すなわち、その薬がどのように吸収され、代謝され、排出されるかを判定することである。更に、種々の投与レベルでのその薬の副作用を測定することにより、段階Iにおいて最適の投薬量のついての情報が提供される。
【０００４】
段階Iの試験は薬の安全性に向けられるが、段階IIの臨床試験では薬の薬効が試される。段階IIの試験は段階Iの試験の成功裡の後に行われる。段階IIの臨床試験は数ヶ月から2年に亘ることがあり、世界中の多くの医療機関で数百人もの患者が関与することがある。患者の1つのグループに対しては実験用薬剤が投与され、対照グループに対しては、プラシーボが投与される。段階IIはしばしば、患者も研究者も誰に対し実験用薬剤が投与されているかを知らされていない状態で行われ、その点で“目隠し”である。このようにして、段階IIの試験は、製薬会社および取締団体（例えば、米国の食品および薬剤管理機構（FDA）又は欧州共同体のヨーロピアン・コミッション（EC））に対し、新薬の薬効についての比較情報を提供する。もし、この段階IIが成功裡になされたときに始めて、段階IIIが認可される。
【０００５】
典型的には、段階IIIにおいて、新薬が世界中の何百もの医療機関にて、数百から数千の患者に対しテストされる。この大規模なテストにより製薬会社および取締団体に対し、新薬の薬効、利益および可能な有害な反応の範囲についてのより完全な理解が提供される。この段階IIIの殆どは、ランダムな、かつ、目隠しの試験である。この段階IIIは一般には数年継続される。段階IIIが一旦、成功裡に完了すると、製薬会社はこの新薬の市販のため、取締団体の認可を要求することができる。
【０００６】
複雑な多重サイトでの段階II又は段階IIIの臨床試験を支持するのに必要な供給源は多くの食い違いを有する。訓練された専門家は、臨床試験のプロトコルの正確な要求の下で新薬を投与しなければならず、複雑な患者の記録を維持しなければならない。この臨床試験プロトコルは長期間に亘って多数の患者の通院を要する。患者の記録の如何なる誤りも患者のデータの失格をもたらすことになる。
【０００７】
臨床試験で使用されるプロトコルの複雑さのため、追跡されなければならない情報量は後置臨床データ管理システム（CDMS）の大きい可能性を必要としている。後置臨床データ管理システムの代表的なものとしては、Clintrial 4.3（Clinsoft Corporation, Lexington, MA, www.clinsoft. net）およびOracle Clinical (O/C)（Oracle Inc., Redwood Shores, CA, www.oracle.com）がある。これらの後置臨床データ管理システムは一般に、洗練された器具、例えばバッチ式確認エンジン、バッチ式データ・ローダー、ランダム化システム、シソーラス管理システムおよびラブ（lab）・リファレンス・レンジ・システムを提供する。しかし、臨床試験が世界中の何百もの場所でなされるため、後置CDMSを各臨床サイト（現場）に配置することは実際的ではない。従って、臨床データを後置CDMSに発送する問題が当該分野において多くの異なるアプローチを用いて取り扱われてきた。
【０００８】
臨床データを後置CDMSに発送するための伝統的なアプローチは、臨床試験の仕様書に従って設計されたペーパーに基づくフォーム（以降、ペーパー基準フォームと呼ぶ）を用いて各臨床サイトで臨床データを収集することである。後日、これらのペーパー基準フォームは手動でコンピュータに2回記入（entry）される。この二重記入は、データ記入エラーをチェックするため、2つのデータセットを比較するのに必要なものである。このアプローチは機能的であるが、満足なものではない。これらのペーパー基準フォームをもとにした電子的データ記入はしばしば臨床環境から遠く離れた場所で行われ、ペーパー基準フォームの内容について問題があっても臨床医に相談することが困難となる。臨床試験プロトコルの正確な要件のため、上述のような未解決のエラーは一般に患者の失格に繋がることになる。ペーパー基準フォームにおける他の問題は、情報が基本的に2度処理されること、すなわち、第1にデータがペーパー基準フォームに記入される時点、第2に、電子データ記入がペーパー基準フォームの内容に基づいて行われる時点である。このことはデータ記入プロセスにおいてエラーが発生するチャンスが確実に2倍になるということである。ペーパー基準フォームにおける更なる問題は、再検討のため臨床データが入手できるまでの時間に可なりの遅延が生じるということであり、これは臨床データに対し電子的分析が実行される前に、スポンサーは臨床データが後置データベースに記入されるまで待たなければならないからである。
【０００９】
レガシーCDMSへの臨床データ記入に対する伝統的アプローチの問題を取り扱うため、リモート・データ・エントリ（RDE）プロダクツの完全な産業が開発された。この産業における代表的なベンダーは、InferMed社、ロンドン、英国,（www.infermed.com）Phase Forward社、ウォルサム, MA,（www.phaseforward.com）, CB Technology,フィラデルフィア, PA,(www.cbtech.com), DataTRAKクリーブランド, OH,(www.datatranknet.com)；Araccel,ストックホルム、スウェーデン国およびTEAMworks, Hannover, ドイツ国である。これらのRDEプロダクツは前置データ・アクイジション・プロダクツとも呼ばれている。これらRDEプロダクツは、臨床サイトでの顧客コンピュータ（例えばラップトップ）で使用されている電子臨床データ・エントリフォームを作成する能力を提供する。RDEプロダクツを使用して集められたデータは電子的に中央化後置CDMSへ送られ、ここで臨床データについての統計的分析がなされ、薬効および/又は安全性が確認される。
【００１０】
RDEプロダクツは、データ記入（エントリ）の間において食い違いを防止し得るという点で有利である。RDEプロダクツは臨床データの記入のためのデータ・エントラントに対し電子症例記録フォーム（eCRFs）を提供する。このeCRFsは、不正確な又は“プログラム範囲外”の記入を受理した場合のケースにおいて警告を示すデータ確認チェックを含むことができる。ついで、データ・エントラントはデータ記入に伴う問題を直ちに修正する。更に、このeCRFsは、“プロトコル・ガイダンス”を提供する。例えば、妊娠テストの質問は患者が女性であることが示された場合にのみ、データ・エントラントに対し表示される。
【００１１】
RDEプロダクツはペーパー基準フォームのアプローチを超えた前進を表すものであるが、それらは満足なものではない。RDEプロダクツは各臨床試験についてカスタム・スタディ定義を作成することを必要とする。例えば、InferMed社（ロンドン、英国）からのMACROは、MACROによりモニターされる各臨床試験についてマクロ・スタディ定義を作成することを必要とする。このマクロ・スタディ定義は、臨床サイトで集められた患者のデータを記載したメタテーブルの収集物である。このマクロ・スタディ定義は更に、臨床データおよび他の関連するデータ取得成分（components）を取得するのに使用された電子フォームのフォーマットを含むものであってもよい。
【００１２】
当該分野において、臨床定義を後置CDMSのためにセットアップする必要がある。この後置臨床定義は臨床検査において全ての患者を追跡するのに使用されているデータ構造である。この後置臨床定義は特定の臨床検査を支持するのに使用される特定の後置CDMSの仕様書に従って設計されている。RDEカスタム・スタディ定義および後置臨床定義に伴う問題は、RDEカスタム・スタディ定義を後置臨床定義に対しインターフェースで連結しようとする場合に明らかとなる。RDEスタディ定義および後置臨床定義についての産業上の基準がないため、RDEシステムによりデータを後置CDMSに対し電子的に供給するために、有意なカスタムプログラミングが各臨床検査について必要となる。
【００１３】
臨床データ・エントリの問題を取扱う第3のアプローチは後置CDMSに対しウェブ・ページ・インターフェースを提供することである。このアプローチを使用するプロダクツの1例は、Oracle Clinical Remote Data Capture v4i（Oracle社、Redwood Shores,カルフォニア州）である。このアプローチにおいて、各臨床サイトには標準ウェブ・ブラウザを備えたクライアント・コンピュータが含まれる。このウェブ・ブラウザは遠隔ウェブサーバーからのデータ・エントリフォームをクライアント・コンピュータにロードするのに使用される。臨床データはついで、データ・エントリフォームに記入される。好ましくは、ウェブ基準データ・エントリフォームに記入されるデータは後置CDMS中に直接、電子的に記入することができる。この第3のアプローチは前置検査定義をインターフェースを介して後置臨床定義と連結させる必要性をなくすることができるが、このアプローチは依然として満足なものとは言えない。第1にクライアント・コンピュータをデータ・エントリ全体に亘って長距離ネットワークにより後置CDMSに接続しなければならない。この要件のため、ウェブ・ページ・インターフェースをどのように構築並びに展開するかについて制限されることになる。データ・エントリ全体に亘って長距離ネットワークを使用することの他の欠点は、ネットワーク・レイテンシー（latency）、ネットワーク帯域幅の制限およびサーバー・ロード（load）の問題であり、これらは必然的に起生される。これらの問題は相重なってデータ・エントリを挫折的経験に陥れる。事実、遠隔サーバーにより駆動されるウェブ・ページを使用するデータ・エントリは、はなはだしい忍耐が要求されることが広く認識されている。例えば、臨床サイトで登録するために、www.amazon.comなどのインターネット・ウェブ・サイトで個人データを記入するのに要求される忍耐の量を考えてみればよい。ウェブ・ページシステム（例えば、Oracle Clinical Remote Data Capture v4i）を使用する臨床データ・エントリは、長期間に亘り周期的ベースでwww.amazon.com又はwww.gap.comなどのサイトで数百ないし数千のヒトを登録するのに匹敵する。
【００１４】
後置CDMSに対しウェブ・ページ・インターフェースを使用する他の不利な点は、後置CDMSインターフェースがデータ・エントリ事務員のために設計されていることである。従って、これらは臨床試験プロトコルが追従されていることを確かめるのに必要なツールについてのサポートを欠落している。このようなツールには、プロトコル違反警告、強制適格性（enforced eligibility）、および投与又はテスト手法に関するプロトコル勧告（recommendations）が含まれる。更に、ウェブ・ページを使用する後置CDMSへの直接的データ・エントリは問題となる実行を導入することになる。後置CDMSインターフェースはデータ・エントリ事務員によるデータ・エントリを容易にするように図られている。それにより、データ・エントリフォームにおけるフィールドの多くはデフォルト・アンサーを有する。デフォルト・アンサーの使用はルーチン・データ・エントリにおいては適当ではあるが、ソース・ドキュメントと考えられるフォームについては適当ではない。ソース・ドキュメントは実際の臨床診察を記録するフォームを表すものである。臨床プロトコルにより指令された全ての臨床診察が実際になされることを確実にするためには、ソース・フォームはデフォルト・アンサーを含むべきではない。
【００１５】
これらの困難に鑑み、当該分野で必要なものは、従前のシステムおよび方法に見られる多くの欠点を伴うことなく、臨床データを収集することができるシステムおよび方法を開発することである。
【００１６】
なお、ここに記載されている参照文献の説明および引用は本発明に対する従来技術として認めたものと考えられるべきではない。
【発明の開示】
【００１７】
本発明は当該分野で見られる欠点に対する新規な解決法を提供する。特に、本発明は、レガシー後置CDMSに従って開発された後置臨床定義を使用するものであり、それにより前置リモート・データ・エントリ（RDE）プロダクツにより使用することができるところの前置検討定義とも呼ばれる1セットのフォームを発生するものである。臨床ワーカーは後置CDMSを使用して後置臨床定義を設計する。ついで、本発明に従い、この後置臨床定義が前置臨床定義に変換される。この前置臨床定義は、臨床試験において前置データRDEプロダクツをホストする各コンピュータに転送される。前置RDEプロダクツは前置検討定義を使用して臨床データの取得を統制する。この前置検討定義には、臨床データを記入するデータ・エントラントにより使用されるフォームの１つのセットの記述が含まれる。
【００１８】
後置臨床定義を前置検討定義に変換するプロセスの間において、新規な変換マップが作成される。この変換マップにより、RDEプロダクツで得られた臨床データを、後置CDMSにより電子的に読むことができるフォーマットへ変換することが可能になる。本発明の１つの具体例において、前置RDEプロダクツを使用して得られた臨床データが新規な前置データ・パケットに変化され、このデータ・パケットはレガシー後置CDMS中に電子的にインポート（import）される。このようにして、後置臨床定義および前置検討定義を個々に作成することなく、かつ、これら２つの定義間の抵触をながながと解決することなくデータを得ることができる。更に、本発明は、時間のかかるインターネット駆動メニューを使用することなく、前置データを実時間で得ることを可能にする。なお、このメニューは、ウェブ・ページ基準データ・エントリ・スクリーンを用いるインターネットを通してデータを後置CDMSへ直接伝達しようとするものである。
【００１９】
本発明の１つの形態は、後置臨床定義に基づいて前置検討定義を確定するための方法を提供することである。この方法において、変換マップが後置臨床定義における第1の成分(component)のセットを前置検討定義における第２の成分のセットと適合させるために作成される。後置臨床定義におけるこの第1の成分のセット中の第1の成分のそれぞれが解析される。この解析ステップは、(i) 該第1の成分に対応する変換マップに識別名を加えるステップと；(ii) 第1の成分に対応する第2の成分を含むように前置検討定義を編集するステップと；(iii) 該第1の成分に対応する前置検討定義中の第2の成分のアイデンティティを含むように変換マップを修正するステップとを含む。この解析ステップが完了したとき、上記変換マップは、後置臨床定義および対応する前置検討定義中の適合する第1および第2成分の記録を含むことになる。本発明の１具体例において、上記後置検討定義は、オラクル(Oracle)臨床定義であり、前置検討定義はマクロ検討定義である。
【００２０】
本発明の他の形態によれば、コンピュータ読み取り可能なメモリーが提供され、これはクライアント/サーバーシステムが特定の様式で機能するようにするために使用される。このコンピュータ読み取り可能なメモリーには、後置臨床定義に従ってデータを保存することができる後置CDMSが含まれる。このメモリーは更に、前置検討定義に従って臨床データを収集するための遠隔データ・エントリ・モジュールが含まれる。更に、このメモリーには、後置臨床定義を対応する前置検討定義に変換するためのマッパー（mapper）サーバー・モジュールが含まれる。この検討定義モジュールにはコンピュータ読み取り可能なメモリーに記憶されている実行可能な命令を含み、この命令には後置臨床定義中の第1の成分のセットを、対応する前置検討定義中の第2の成分のセットと適合させる変換マップを作成するための命令が含まれる。更に、検討定義モジュールには後置臨床定義中の第1の成分のセット内の各第1の成分を解析するための命令が含まれる。第1の成分のセット中の第1の成分の夫々について、この解析のための命令には、(i) 該第1の成分に対応する変換マップに識別名を加えるための命令；(ii) 第1の成分に対応する第2の成分を含むように対応する前置検討定義を編集するための命令；(iii) 該第1の成分に対応する前置検討定義中の第2の成分のアイデンティティを含むように変換マップを修正するための命令が含まれる。この解析のための命令が完了したとき、上記変換マップは、後置臨床定義および対応する前置検討定義中の適合する第1および第2成分の記録を含むことになる。
【００２１】
本発明の更に他の形態によれば、後置臨床定義に従って後置CDMS中の臨床データを記憶するための方法が提供される。この方法において、前置データ・パケットが遠隔データ・エントリ・モジュールから得られる。この遠隔データ・エントリ・モジュールは前置検討定義に従って臨床データを収集する。ついで、前置データ・パケットが解析される。この前置データ・パケット中の各患者について、この解析ステップには、患者についての前置検討定義前置検討定義/後置臨床定義適合データを変換マップに加入するステップが含まれる。一旦、全ての患者の解析が終了すると、変換マップを使用して、後置CDMSにアップロードされた後置データ・パケットが構築される。或る具体例において、この解析ステップは更に、患者について設定された臨床識別名を照合するステップが含まれる。この場合、臨床識別名が患者について設定されていない場合、患者に関連する前置データ・パケット中のデータが拒否される。本発明の或る具体例において、後置検討定義はオラクル(Oracle)臨床定義であり、前置検討定義はマクロ検討定義である。
【００２２】
本発明の更に他の形態によれば、CDMS中に電子的に発生する食違いを解決するための方法が提供される。この方法は、変換マップを使用して、後置フォーマット（食違いに対応する臨床値を記憶するのに使用される）からの食違いを前置検討定義に適合する前置フォーマットに変換するステップを含む。更に、この食違いは前置フォーマットの形で、この食違いに関連する臨床値が最初に記入された前置サイトに転送される。食違い応答はこの前置サイトから受理される。この食違い応答によりこの食違いが解決されるとき、この食違い応答はCDMS内に格納され、それにこの食違いが解決される。
【００２３】
或る具体例において、この方法は更に、食違い応答がこの食違いを、(i) 前置フォーマットからの食違い応答を後置フォーマットに変換することにより；および(ii) その食違い応答が臨床値に関連するデータ・エントリ基準を満足することを証明することにより、解決されるか否かを判定するステップを含む。このデータ・エントリ基準は例えば、データタイプ又はデータレンジ（range）であってもよい。
【００２４】
或る具体例において、CDMSは、（1）臨床値を記憶するためのデータベース；（2）統計を使用して臨床値を分析するためのSASモジュール；（3）ケース・レポートフォームに見出せないデータをロードするためのジェネリック・ローダー；（4）不都合な反応術語を調和させるシソーラスをアクセスするためのシソーラス・モジュール；（5）オージット・トレイル（監査の手掛り）をアクセスするためのオージット・トレイル・モジュールを含む。或る具体例において、変換マップは、後置フォーマットにおける各質問およびイベント（event）と、前置検討定義における各質問およびイベントと間の1対1の対応を記憶する。
【００２５】
本発明の他の具体例によれば、クライアント/サーバーシステムを特定の様式で機能させるようにして使用されるコンピュータ読み取り可能なメモリーが提供される。このコンピュータ読み取り可能なメモリーには、後置臨床データ管理システム（CDMS）が含まれる。この後置CDMSは後置臨床定義に従ってデータを保存することができる。更に、このコンピュータ読み取り可能なメモリーには、前置検討定義に従って臨床データを収集するための遠隔データ・エントリ・モジュールが含まれる。このコンピュータ読み取り可能なメモリーには更に、後置CDMSで電子的に生じる食い違いを解決するためのマッパー（mapper）・サーバー・モジュールが含まれる。このマッパー・サーバー・モジュールには、コンピュータ読み取り可能なメモリーに記憶されている実行可能な命令が含まれる。この実行可能な命令には、変換マップを使用して、後置臨床定義フォーマット（食違いに対応する臨床値を記憶するのに使用される）からの食違いを前置検討定義フォーマットに変換するための命令が含まれる。この実行可能な命令は更に、前置検討定義フォーマットにおける食違いを、この食違いに関連する臨床値が記入された前置サイトに転送するための命令が含まれる。更に、この実行可能な命令には、前置サイトからの食違い応答を受理するための命令並びにこの食違い応答が食違いを解決するものであれば、この食違い応答を後置CDMSに格納するための命令が含まれる。
【発明を実施するための最良の形態】
【００２６】
（6.  発明の詳細な記述）
本発明は、前置データ収集システムをオラクル・クリニカルなどの後置CDMSと一体化させるための装置および方法を提供するものである。本発明は、前置データ収集システムと、後置臨床データ管理システムとの間のデータ、メタデータおよびプロセスデータの二方向変換および輸送を調和よく組み合わせたものである。本発明は複数の後置データ・ウエアハウジング（warehousing）・サイトで連続的に操作することができる。本発明の多くの形態はオープン・アプリケーション・プログラム・インターフェース（“API”）を介してアクセスすることができる。本発明は、クライアントとして作用するAPIを前置データ収集システムに提供すると共に、クライアントとして作用する更なるAPIを後置CDMSに提供するものである。
【００２７】
1具体例として、本発明は、MACRO(InferMed社、ロンドン、英国)のような遠隔データ・エントリ能力を有する前置データ収集システムと、オラクル・クリニカル（O/C）（Oracle社、Redwood Shores,カルフォニア州）のようなレガシー後置CDMSとの間のインターフェースを提供する。MACROおよびオラクル・クリニカルはそれぞれ独立して開発されたもので、データ又はメタデータの表示について共通の基準を有していない。従って、本発明の1具体例では、これら２つのプロダクツ間の自動化インターフェースが提供される。本発明による装置および方法では、O/C検討定義が翻訳され、それらがマクロ検討定義に変換される。この変換されたマクロ検討定義はついで、MACROにロード（load）される。マクロ検討定義は、MACROを使用して臨床データを収集するためのベースとして役立つ。検討データがMACROを使用して収集されたとき、本発明ではそのマクロ検討データがO/Cで読み取ることができるデータ・フォーマットに翻訳され、このフォーマット化されたデータが、インクリメンタル（漸増）ベースで、指定されたO/Cサーバーにロードされる。従って、本発明では3つの重要な使用事例（use case）シナリオ、すなわち、(i) 後置臨床定義を前置検討定義にマッピングすること；(ii) MACROのような遠隔データ・エントリ・プログラムからの臨床データを検索、翻訳し、後置CDMSをこの検索された臨床データでポピュレート（populating）すること；(iii) この後置CDMS中に発見された食違いを電子的、かつ、完全に監査された様式で解決すること；が提供される。
【００２８】
（6.1  本発明で使用されるシステム成分の概要）
本発明は、成分(コンポーネンツ：component)ソフトウエア・モジュールおよびデータベースのセットを提供するもので、これらはイントラネット、インターネット、又は他の有線、無線通信システム（ここでは、通信チャンネルとも呼ぶことにする）により互いに連結されている。本発明の有意な利点は、コンポーネンツ・ソフトウエア・モジュールが、個々のコンポーネンツ・ソフトウエア・モジュール相互が大きな地理的距離で離れていても機能するように構成することができることである。本発明の他の利点は、このシステムを広範なワークロード（work loads）を取扱えるようなスケールとすることができることである。図1には、本発明の方法を用いて、後置臨床定義8を前置検討定義70に変換するための例示的システム、すなわち、システム1300が示されている。1具体例において、後置臨床定義8はオラクル・クリニカル定義であり、前置検討定義70はマクロ検討定義である。好ましくは、システム1300は図1に示すハードウエアおよびソフトウエアコンポーネンツを有し、これらには、後置O/Cデータベース10をホスト（host）する後置コンピュータ140、サーバー・プロセス・モジュール38をホストするサーバー150、夫々が遠隔データ・エントリ（RDE）プロダクツ68を有する1又はそれ以上の前置サイト104、通信チャンネル98、およびコンソール・モジュール44および/又はマッパー・クライアント・モジュール6をホストするクライアント180が含まれる。
【００２９】
図1の概要を説明すると、コンピュータ140におけるO/Cデータベース10中の後置臨床定義8が、コンピュータ180に帰属するマッパー・クライアント・モジュール6により選択される。この選択された後置臨床定義8はついで、コンピュータ150のマッパー・サーバー・モジュール30により前置検討定義70に変換される。後置臨床定義8のデータ・フォーマットは前置検討定義70のものとは全く異なる。事実、後置臨床定義8に見出される属性（attributes）およびメタテーブルは前置検討定義70では全く使用されない。これらの使用されないメタテーブルおよび属性は通常、コンピュータ150の変換マップ（例えば、検討マップ）32に格納されており,この変換マップ32は後置臨床定義8の前置検討定義70への変換の間にマッパー・サーバー・モジュール30により作成される。更に、変換マップ32は後置臨床定義8および前置検討定義70における質問およびイベント（events）間の1対1対応を格納する。一旦、変換されると、前置検討定義70は前置サイト104へ分配される。臨床データが前置サイト104により受理されると、サーバー・プロセス・モジュール38（コンピュータ150の）は臨床データについて各データベース72を検索し、その臨床データを変換マップ32に加える。各前置サイト104が検索されたのち、変換マップ32中のデータを使用して、新規な後置データ・パケットが構築され、これはO/Cデータベース10により読み取ることができる。
【００３０】
図1がこのように大略的に説明したので、次に図1の前置サイト104に注目してみる。事実、システム1300の典型的履行において、如何なる数もの前置サイト104が大きい地理的距離に亘って展開され得る。例えば、各前置サイト104は遠い臨床サイトに位置していてもよい。好ましい具体例において、各前置サイト104は以下のものを含む：
＊  中央演算処理装置62；
＊  ソフトウエアおよびデータを格納するためのメイン不揮発性格納ユニット61（
好ましくはハードディスク・ドライブ）；
＊  前置サイト104を通信チャンネル98（これは任意の有線又は無線通信チャンネル
であってもよい）に接続するためのネットワーク接続60；
＊  システム制御プログラム、データおよびアプリケーション・プログラム（揮発
性格納ユニット61からロードされたプログラムおよびデータを含む）を格納する
ためのシステム・メモリー66（好ましくは、RAM）；
＊  ユーザー・インターフェース64（1又はそれ以上の入力装置を含む）；
＊  上記要素を本システムに相互に接続するためのインターナル・バス67。
【００３１】
各前置サイト104の操作は、当業者に公知の方法に従って、操作システム又はラウンド・ロビン（round-robin）方式で制御される。典型的履行において、このシステム・メモリーには、前置サイト104並びに本発明で使用されるソフトウエア・モジュールおよびデータ構造の数を制御するための手段が含まれる。これらのソフトウエア・モジュールおよびデータ構造には、RDEプロダクツ68、1又はそれ以上の前置検討定義70およびデータベース72が含まれる。一般的に、これらモジュールの1又はそれ以上の一部は不揮発性格納ユニット61に格納される。次に、これらのソフトウエア・モジュールのそれぞれの機能および目的について説明する。
【００３２】
RDEプロダクツ68：  本発明の1具体例において、RDEプロダクツ68は、InferMed社（ロンドン、英国）により提供されたアプリケーションおよびユーテリティ（“MACRO”）のセットのバージョン3.0である。このRDEプロダクツ68は1セットのフォームをデータ・エントラントに表示するのに使用される。このフォームは著しく専門化されていて、データ・エントラント（entrant）に対し著しく調整された様式で質問を提示するものである。例えば、フォームに提示された各質問は値の範囲に限定される。更に、RDEプロダクツ68には、提示された各フォームについての広いスケジュール情報が含まれる。例えば、複数週間に跨る試験において、その試験に登録された各患者についてのフォームがデータ・エントラントに対し、RDEプロダクツ68により維持されたスケジュールに従って1週間ベースで提示される。
【００３３】
前置検討定義70：  各前置検討定義70は、特定の試験サイトおよび研究部で遠隔データ・エントリを容易にするのに必要なデータ・フォーマットを確定するものである。本発明の利点は、各前置検討定義70が、対応する後置臨床定義8に基づいて電子的に発生することである（図1）。本発明の1具体例において、前置検討定義70はMACRO 3.0（InferMed社）マクロ検討定義であり、これは表2に記載したメタテーブルを含む。
【表１】
2004530223.tif 000002
【００３４】
これらのマクロメタテーブルの詳細については、MACRO 3.0（InferMed社、ロンドン、英国）についての技術文献に記述されている。更に、表2に列挙されたメタテーブルが、対応する後置臨床定義8に基づいてどのように発生したかを示す記述を以下の“使用事例（Use Case 1）”に開示する。
【００３５】
API 192:   アプリケーション・プログラム・インターフェース（API）192はRDE68の或る具体例により提供されている。API 192は情報をRDE68およびデータベース72に情報をアップロードするための機構を提供するもので、これはデータベース72の内部データ構造から絶縁された状態で行われる。
【００３６】
データベース72：  本発明の1具体例において、データベース72はオラクル（Oracle）9iデータベース（Redwood Shores, カルフォニア州）の装置である。データベース72は前置検討定義70に従って臨床データを格納する。
【００３７】
図1に示す後置コンピュータ140について注目すると、このコンピュータ140は好ましくは、以下のものを含む：
＊  中央演算処理装置18；
＊  ソフトウエアおよびデータを格納するためのメイン不揮発性格納ユニット19（
好ましくはハードディスク・ドライブ）；
＊  後置コンピュータ140を通信チャンネル98に接続するためのネットワーク接続
20；
＊  システム制御プログラム、データおよびアプリケーション・プログラム（揮発
性格納ユニット19からロードされたプログラムおよびデータを含む）を格納する
ためのシステム・メモリー4（好ましくは、RAM）；
＊  ユーザー・インターフェース16（1又はそれ以上の入力装置を含む）；
＊  上記要素を本システムに相互に接続するためのインターナル・バス5。
【００３８】
後置コンピュータ140の操作は、当業者に公知の方法に従って、操作システム又はラウンド・ロビン（round-robin）方式で制御される。典型的履行において、このシステム・メモリーには、後置コンピュータ140並びに本発明で使用される多数のソフトウエア・モジュール、データファイルおよびデータベースを制御するための手段が含まれる。これらのソフトウエア・モジュール、データファイルおよび/又はデータベースの一部は、揮発性格納ユニット19内に格納される。これらのソフトウエア・モジュール、データファイルおよび/又はデータベースには、O/Cデータベース10および任意に、1又はそれ以上の外部ファイル9が含まれる。O/Cデータベース10はO/C臨床モジュール12およびO/Cデータ・キャプチュア（capture）API 14との関連で稼動する。本発明の或る具体例において、O/Cデータベース10はO/C識別名3および1又はそれ以上の後置臨床定義8を格納する。次に、これらのソフトウエア・モジュール、データファイルおよび/又はデータベースのそれぞれの機能および目的について説明する。
【００３９】
O/Cデータベース10：  O/Cデータベース10は臨床データを格納、検索するためのデータベース管理システムである。このデータベース管理システムは、一般に、データを管理し、データについてユーザーからの質問を受理し、これら質問に対し応答するため、データベース・サーバー又はメインフレーム・システムについて操作されるソフトウエア・プログラムである。或る具体例において、データベース管理システムは以下のことを行うことができる。すなわち、(i) データを記録、表又はオブジェクトとして構築する方法を提供すること；(ii) オペレータからデータ入力を受理し、後の検索のためそのデータを格納すること；(iii) ユーザーが収集されたデータを関連づけたり、意味或るものとするのを助けるところの調査、分類、報告および他の決定支持活動のための質問言語を提供することであり、これらはユーザーが収集されたデータを関連づけたり、意味或るものとするのを助ける；(iv) 複数ユーザーが、他人により或る情報が見られたりおよび/又は変更されたりすることを防止する安全要素を伴いつつ、データにアクセスできるようにすること；(v) 1以上のユーザーが同一の情報を同時にアクセスしたり、変更したりするのを防止する完全性をデータに与えること；(vi) データベース、関連するファイルおよび記録情報の構造を記述したデータ辞書を与えることである。
【００４０】
殆どのデータベース管理システム、例えば後置コンピュータ140によりホストされたものは、クライアント/サーバーに基づき、ネットワークを介して操作される。図1に示す1例において、サーバーは後置コンピュータ140であり、これに対し、クライアントには前置サイト104、クライアント180又はシステム1300内に開示されていない他のクライアントが含まれる。データベース管理システムには、大きいデータ・ストアに対する高性能チャンネルを有する後置コンピュータ140に基づいて稼動されるエンジンが含まれる。後置コンピュータは、クライアント180のようなクライアントからのリクエストを受理し、これらリクエストには分類および抽出データを必要とすることがある。殆どのデータベース・システムにアクセスするための典型的な言語は、SQL(構築された質問言語)である。1具体例において、後置コンピュータ140は、SQL質問に応答するオラクル・データベース管理システムを使用する。従って、1具体例において、O/Cデータベース10はオラクル・データベース、例えばオラクル9i（Oracle、 Redwood Shores, カルフォニア州）である。
【００４１】
本発明の他の具体例において、O/Cデータベース10はフラット・ファイル・データベースである。フラット・ファイル・データベースは、一般に単純データ・システムに適用することができる。なぜならば、全ての情報が1個のファイルに格納することができるからである。他の具体例において、O/Cデータベース10は、リレーショナル・データベース・システムおよび/又はオブジェクト指向データベース・システムである。リレーショナル・データベース・システムは臨床データを多重テーブル又はメタテーブルに格納する。これらテーブルは多くの方法でデータを相互に関連させ、観察させるように関連づけたり、組合わせたりすることができる。典型的なO/Cデータベース10は潜在的に数千の関係を生じさせる数百の表を含むことができる。共通のエレメント（例えば、患者のID又は臨床試験ID）が複数の表に亘って情報を連結させるものであってもよい。
【００４２】
O/Cデータベース10についての好ましい例の範囲内であるオブジェクト指向データベースは、一般にリレーショナル・データベースの能力を含むが、多くの異なるデータの型（画像、オーディオおよびビデオを含めて）を格納することができる。更に、オブジェクト指向データベースは方法を格納し得るようになっていて、それにはデータベース中で直接的にオブジェクトと関連する特性（プロパティ）および手法が含まれる。ここに記載したシステムおよび方法の履行を可能にするためのリレーショナルおよび/又はオブジェクト指向データベースを履行させる場合の更なる情報について種々の参考文献が公に入手可能である。例えば、Cassidy, High Performance Oracle 8 SQL Programming and Tuning, Coriolis Group (1998, 3月)およびLoney and Koch, Oracle 8: The Complete Reference,(Oracle Series), Oracle Press (1997, 9月)にこれらの情報が記載されており、これらの内容は本明細書に参照として組み込まれるものとする。
【００４３】
O/C臨床モジュール12：  本発明の1形態において、O/C臨床モジュール12はOracle社（Redwood Shores, カルフォニア州）のプロダクツである。例えば、一例として、O/C臨床モジュール12はOracle Clinicalのバージョン3.1.1.1であり、O/Cデータベース10はオラクル・データベースのバージョン7.3.2である。この具体例において、オラクル・データベース・バージョン7.3.2シート（seat）はO/Cデータベース10である。本発明の他の具体例において、O/C臨床モジュール12はOracle Clinicalのv4iである。O/C臨床モジュール12はO/Cデータベース10内に後置臨床定義8を格納するのに使用される。本発明の他の具体例において、O/C臨床モジュール12はClintrial 4.3（Phaseforward, Waltham, マサチューセット州）である。当業者にとって、O/C臨床モジュール12について、他の商業的履行が可能であることが理解できよう。更に、O/C臨床モジュール12は、市販のプロダクツと、市販されていない高度にカスタマイズされたソフトウエアとの間のハイブリッドであってもよい。
【００４４】
O/Cデータ・キャプチュア（capture）API 14:   本発明の或る具体例においては任意に、O/Cデータ・キャプチュアAPI 14が含まれる。このO/Cデータ・キャプチュアAPI 14はアプリケーション・プログラミング・インターフェース（“API”）である。本発明の1具体例において、このO/Cデータ・キャプチュアAPI 14は、臨床フィールド・オフィスから後置データ・パケットをアップロードするためOracle Clinicalにより提供されたオラクル・クリニカル・データ・キャプチュアである。
【００４５】
O/C識別名（identifiers）3：  本発明の或る具体例においては任意に、O/C識別名３が含まれる。このO/C識別名3は対応するO/Cサイト、O/Cインベスチゲータ、および特定の後置臨床定義8についてのO/C患者コードを記述している。
【００４６】
後置臨床定義8：  図1に示すように、システム1300は、オラクル・クリニカル定義のような後置臨床定義8を多数含む。このシステム1300における後置臨床定義8はO/Cデータベース10のようなデータベース中に格納される。図1において、O/Cデータベース10中に格納されたN個の後置臨床定義8のセットが示されている。
【００４７】
本発明の1具体例において、後置臨床定義8は表3に示すメタテーブルを含むオラクル・クリニカル定義である。
【表２】
2004530223.tif 000003
【００４８】
これらのマクロメタテーブルの構造の詳細については、O/C v.3.1.1.1; Oracle社（Redwood Shores, カルフォニア州）に記述されている。
【００４９】
外部ファイル9：  本発明の或る具体例においては、外部ファイル9が適宜、含まれる。後置臨床定義8をO/Cデータベース10から移送し、外部ファイル9として格納することができる。この外部ファイル9は内部後置臨床定義8中のデータ構造の完全な記述を含む。この外部ファイル9と後置臨床定義8との間の1つの相違は、後置臨床定義8がO/Cデータベース10内にメタテーブルのコレクションとして格納されるのに対し、対応する外部ファイル9は臨床検討の完全で、メタテーブル非従属性の記述を含むことである。なお、本発明は、外部ファイル9がシステム1300によりアドレスを特定することができる位置にある限り、システム1300内の外部ファイル9の位置については何ら制限を課すものではないことを理解されたい。
【００５０】
本発明の1具体例において、後置コンピュータ140は臨床データ管理システム（CDMS）である。このCDMSはO/Cデータベース10などのデータベース中の臨床試験結果を格納する。本発明の1具体例において、このCDMSは以下のコア機能性を支持する任意のコンピュータとして定義することができる。すなわち、（1）臨床試験データを格納するデータベース；（2）統計を使用して臨床試験データを機能的に分析するSASへのアクセス；（3）事例報告フォームに見出せないデータをロードするためのジェネリック・ローダー；（4）不都合な反応術語を調和させるシソーラスをアクセスするためのシソーラス；（5）任意の適用可能なデータ確認手法；（6）オージット・トレイルである。本発明の或る具体例において、臨床試験データを格納するのに使用されるデータベースはO/Cデータベース10である。
【００５１】
本発明の或る具体例において、CDMSのコア機能性が、データベースとは別に、O/C臨床モジュール12に見出すことができる。図12は本発明の1具体例における例示的O/C臨床モジュール12を示している。図12において、このO/C臨床モジュール12はSASモジュール1202を含む。或る具体例において、このSASモジュール1202はSAS(Cary, ノースカロライナ州)から入手可能な統計解析パッケージであり、これは臨床データを統計的に分析するのに使用される。他の具体例において、このSASモジュール1202はO/Cデータベース10からデータをSASのような統計パッケージにより分析可能なフォームへ移送させるための機構である。なお、SASが本発明における好ましい統計パッケージではあるが、他の統計的プログラムを使用してコアCDMS機能を実施することができ、その様なプログラムは全て本発明の範囲に包含されることを理解されるべきである。
【００５２】
図12に示す例示的O/C臨床モジュール12は更にジェネリック・ローダー・モジュール1204を含む。1具体例において、このジェネリック・ローダー・モジュール1204は事例報告フォームに見出せないデータをロード（load）する。このようなデータには、例えば、血液検査および心電図分析のような実験結果が含まれる。この事例報告フォームは前置サイトで臨床データを得るために使用される。しかし、臨床試験についてのデータの或るものは多くの場合、実験結果からのみ得られる。多くの実験テストは、臨床の対象が前置サイトに置かれた後、しばらくして中央集中区域で行われる。従って、事例報告フォームは実験結果を報告するのに使用されない。その代わりに、実験結果はテストが行われた実験室から、直接、CDMSへ送信される。ジェネリック・ローダー・モジュール1204はこのデータを受理し、そのデータを正しい臨床対象と照合させる。ついで、このデータがO/Cデータベース10内に格納される。
【００５３】
図12に示す例示的O/C臨床モジュール12は更に、不都合な反応術語を調和させるためのシソーラス・モジュール1206を含む。例えば、実際に、一人の臨床医は頭痛を“頭痛”と診断し、他の臨床医が頭痛を“偏頭痛”と診断することがあり得る。更に、一人の臨床医は頭痛を“頭痛”という見出しを付け（すなわち、“頭痛”）、他の臨床医はそのような見出しを付けないことあり得る。このように、頭痛のような単純な症状についてでさえ、用語がどのように記録されるかについて大きく変化が生じることになる。シソーラス・モジュール1206は医学用語の標準的辞書を使用してこの用語を調和させるものである。1具体例において、医学用語の辞書はMedDRA辞書である。調和についての国際会議（International Comference on Harmonization: ICH）のイニシアティブによるこのMedDRAは医学用語の標準的辞書である。このMedDRAは英国のメディシン・コントロール・エイジェンシイ（MCA）の医学用語に基づくものである。これは、World Health Organization Adverse Reaction Terminology (WHO-ART;WHO Collaborating Center for International Drug Monitoring, Uppsala, スウェーデン国)、International Classification of Dieseases (ICD)およびInternational Classification of Dieseases with Clinical Modification (ICD-CM)からの関連用語規定、Coding Symbols for a Thesaurus of Adverse Reaction Terms (COSTART; Department of Health, Education and Welfare; Food and Drug administration, Rockville,メリーランド州)およびJapanese Adverse Reaction Terminology (J-ART)を組み入れたものである。他の具体例において、シソーラス・モジュール1206により他の用語シソーラス、例えば、World Health Organization Adverse Reaction Dictionary (WHO ARD)、COSTART又はHoechst Adverse Reaction Terminology System (HARTS)が使用される。
【００５４】
図12に示す例示的O/C臨床モジュール12は更に、臨床データを確認するためのデータ確認モジュール1208を含む。本発明の利点は、データ確認の或るフォームを前置データ取得プロダクツを用いて行うことができることである（例えば、図1；RDEプロダクツ68）。例えば、プロダクツ68はデータ・エントリが許容範囲内にあることを確かめるために使用することができる。プロダクツ68をデータ確認の或るフォームについて使用することができるが、CDMSは、プロダクツ68では容易に行えないようなデータ確認の或るフォームを取扱うことができるデータ確認モジュールを有するものでなければならない。プロダクツ68では容易に行うことができず、従ってCDMSを用いなければならないようなデータ確認の種類は例を挙げることにより最もよく説明することができる。1例として、臨床試験は、全臨床対象の可なりの率が特定の副作用を示すか否かを確認するために多数の臨床対象についてチェックする必要が或る。このようなチェックはプロダクツ68では容易に行うことができない。なぜならば、或るRDEプロダクツ68の施設では、そのRDEプロダクツ68が設置されているサイトで収集された患者のデータにのみアクセスすることができる。臨床試験は一般に、非常に広範な地域に亘って広がっている多数の遠隔サイトに関与するものであるから、多数の臨床対象全体を通してチェックするのに必要な患者のデータに対して容易にアクセスする手段をRDEプロダクツ68は有していない。
【００５５】
図12に示す例示的O/C臨床モジュール12は更に、O/Cデータベース10に対しなされた全ての変更を追跡するためのオージット・トレイル・モジュール1210を含む。このオージット・トレイル・モジュール1210はCDMSシステムの必要な部品である。なぜならば、CDMSシステム内の全てのデータ・エントリは、多くの国での臨床データの提出のための規定要件を満たすために検査されなければならないからである。幾つかのタスクの中で、とりわけ、オージット・トレイルはO/Cデータベース中の食違いがどのように発見され、どのようにしてそれが解決されたかを追跡する。例えば、臨床医がRDEプロダクツ68のセーフガイドを無視し、要求されている範囲を超えた特定の臨床事例についての値をエンターさせた時、食違いがデータ確認モジュール1208により起動される。本発明の1具体例において、このデータ確認モジュール1208は、個の食違いを、解決のため、その誤ったデータを発生させた前置サイト104へ送信する。ついで、前置サイトの臨床医が食違いを解決する。この解決は最終的に後置コンピュータ140に伝達され、それによりこの食違いが解決される。重要なことは、オージット・トレイル・モジュール1210が、これらの全てのステップの追跡を維持し、如何なる時点においても、食違いを解決するためになされている各ステップを判定することができるということである。本発明の1具体例において、オージット・トレイル・モジュール1210はFood and Drug Administration (FDA)により公表されているGood Clinical Practiceに従うものである。このGood Clinical Practice（GCP）は、臨床試験の設計、実施、性能、モニタリング、検査、記録、分析および報告についての基準となっている。この基準に適合することにより、データおよび報告された結果が信用でき、正確であることが保証され、被験者の権利、安全および福祉が保護されることになる。FDAは、それが規定する生物医学的研究が、FDAの規則により規定されているGCP基準に適合することを要求している。
【００５６】
CDMSがその機能性を完全に提供するため、複数のコンピュータを使用し得ることを理解されるであろう。例えば、或る具体例において、データ確認モジュール1208はオージット・トレイル112を格納するコンピュータ150（図1）上でデータベース48との関連で稼動される。しかし、一般に、CDMSは前置サイト104に依存することなく、CDMSに関連するコア機能性を提供することができる。なぜならば、前置コンピュータは一般に、O/Cデータベース10中に見られる臨床データのフルセットに対するアクセスを有していないからである。
【００５７】
図1に示すコンピュータ150について注目すると、このコンピュータ150は好ましくは、以下のものを含む：
＊  中央演算処理装置24；
＊  ソフトウエアおよびデータを格納するためのメイン不揮発性格納ユニット23（
好ましくはハードディスク・ドライブ）；
＊  後置コンピュータ150を通信チャンネル98に接続するためのネットワーク接続
22；
＊  システム制御プログラム、データおよびアプリケーション・プログラム（揮発
性格納ユニット23からロードされたプログラムおよびデータを含む）を格納する
ためのシステム・メモリー28（好ましくは、高速ランダムアクセス・メモリー（
RAM））；
＊  ユーザー・インターフェース26（1又はそれ以上の入力装置を含む）；
上記要素を本システムに相互に接続するためのインターナル・バス29。
【００５８】
コンピュータ150の操作は、当業者に公知の方法に従って、操作システム又はラウンド・ロビン方式で制御される。典型的履行において、このシステム・メモリーには、コンピュータ150並びに本発明で使用される多数のソフトウエアおよびデータ・モジュールを制御するための手段が含まれる。これらのソフトウエアおよびデータ・モジュールには、マッパー・サーバー・モジュール30、デーモン（daemon）・モジュール36、レジストレーション・モジュール37、サーバー・プロセス・モジュール38、コンフィギュレーション・ファイル40、データ交換モジュール42、データベース・モジュール48、パーシステント・ステート（persistent state）記録110、ステータス・アカウント・ブック114、タイム・スタンプ（stamp）76、オージット・トレイル112および変換マップ32が含まれる。一般に、これらソフトウエアおよび/又はデータ・モジュールの1又はそれ以上の一部は不揮発性格納ユニット19に格納される。次に、これらのソフトウエアおよび/又はデータ・モジュールのそれぞれの機能および目的について説明する。
【００５９】
マッパー・サーバー・モジュール30：  マッパー・サーバー・モジュール30は後置臨床定義8又は外部ファイル9を均等の前置検討定義70に変換するものである。これは更に、翻訳キーを発生させ、それによりサーバー・プロセス・モジュール38およびデータ交換モジュール42が後に、RDEプロダクツ68により収集されたデータを、後置臨床定義8と適合するデータ・フォーマットに変換できるようになる。この翻訳キーは変換マップ32として参照される。
【００６０】
本発明の1形態において、マッパー・サーバー・モジュール30は、新たな接続が確立されたとき、各マッパー・クライアント・モジュール6についてユーザー・セッションを提供する。マッパー・クライアント・モジュール6がマッパー・サーバー・モジュールに接続されている間において、このユーザー・セッションは情報を維持する。各セッションはマッパー・クライアント・モジュール6に対し特異なものである。或る具体例において、マッパー・サーバー・モジュール30は一度に一回のみの接続を許容する。このユーザー・セッションはマッパー・クライアント・モジュール6が最初にstartSession方法を要求したときに作成される。このユーザー・セッションはマッパー・クライアント・モジュール6が最初にstopSession方法を要求したときに削除される。このユーザー・セッションは30分を越えてアイドルにされたとき終了する。
【００６１】
ユーザー・セッションは、ユーザー名およびセッション記章により識別される。このセッション記章はクライアント180により発生され、マッパー・サーバー・モジュール30をホストするコンピュータ150へ送られる。1例として、このセッション記章はSecure Hash Algorithm (SHA-1)により形成された特異な記号であり、マッパー・クライアント・モジュール6からの各方法コール（call）はセッション記章を含む。マッパー・サーバー・モジュール30はセッション記章および各方法コールについてのセッション満了時間を確認する。
【００６２】
本発明の1具体例において、セッション記章が認識されないとき、又はユーザー・セッションが満了したとき、例外が発生する。各方法コールについて、セッション記章に基づいてユーザー・セッションが検索される。検討定義についての特質（プロパティ）のサブセットがこのユーザー・セッション内に存在する。このような状況の下で、後置臨床定義8が変更されたとき、この特質のサブセットは置き換えられる。
【００６３】
本発明の他の形態において、マッパー・サーバー・モジュール30はIMapインターフェースを提供する。1例におけるマッパー・サーバー・モジュール30は、2つの成分により共有されたIMapパブリック・インターフェースにより画成されるマッパー・クライアント・モジュール6を支持する。IMapインターフェースの方法を下記表4に項目別に記述する。
【表３】
2004530223.tif 000004
【００６４】
2004530223.tif 000005
【００６５】
2004530223.tif 000006
【００６６】
デーモン（daemon）・モジュール36：  デーモン・モジュール36は、サーバー・プロセス・モジュール38、マッパー・サーバー30およびデータ交換モジュール42のための活性化機構として作用する。本発明の事例が開始されると、デーモン・モジュール36が開始され、サーバー・プロセス・モジュール38を自動的に推進させる。デーモン・モジュール36は、別のサーバー・プロセスをスタートさせる要求を待ち、それが停止されたとき、サーバー・プロセス・モジュール38が再発進する。1具体例において、デーモン・モジュール36は介入を殆ど必要とせず、そのためユーザー・インターフェースを有しない。しかし、他の具体例において、デーモン・モジュール36は全ての出力メッセージのためのシステム・コンソールとして作用し、そのため、一般に、必要に応じてモニタリングのため利用することができる。
【００６７】
レジストレーション・モジュール37：  サーバーが直ちに利用可能な時点において、レジストレーション・モジュール37内には、システム1300中の異なる後置コンピュータ140のためのエントリが配置されている。異なるサーバーを使用する検索がレジストレーション・モジュール37に送られ、このレジストレーション・モジュール37は要求されたモジュールを参照して回答する。要求されたときに、モジュール38、30又は42が入手できない場合は、デーモン・モジュール36との接触がなされ、対応するサーバーがスタートすることになる。
【００６８】
サーバー・プロセス・モジュール38：  サーバー・プロセス・モジュール38はデータ交換モジュール42との関連で稼動され、各前置サイト104から臨床データを収集し、適当な変換マップ32を使用して、そのデータを、O/Cデータベース10で読み取ることができる後置データ・パケットに翻訳する。本発明の或る具体例においては、このサーバー・プロセス・モジュール38にはスケジュール機能が含まれる。このスケジュール機能は、前置サイト104が新規な臨床データのためにポーリングする周期を設定するのに使用される。
【００６９】
サーバー・プロセス・モジュール38は更に、データベース・モジュール48との相互作用により、その持続的記録状態を維持する。この記録はデータベース・モジュール48中にパーシスタント・ステート・レコード（persistent state record）110として格納される。このパーシスタント・ステート・レコード110には、外部システム接続（140および104に対し）の状態、現在のデータ・ロード・プログレスの状態、並びにロード・イベント（load events）についての統計的情報が含まれる。
【００７０】
サーバー・プロセス・モジュール38は更に、データベース・モジュール48中の事例のオージット・トレイル112を格納する。オージット・トレイル112は“アクティビティ”又は“エラー”のいずれかの事例タイプに分類される。好ましい具体例において、これら事例は歴史的に格納され、構築された質問用語（SQL）のような言語を使用した検索を介してアクセスすることができる。
【００７１】
サーバー・プロセス・モジュール38は、コンフィギュレーション・ファイル40、データ交換モジュール42およびコンソール・モジュール44を含む他のファイルおよびソフトウエア・モジュールとの関連で稼動される。
【００７２】
コンフィギュレーション・ファイル40：  コンフィギュレーション・ファイル40には、橋渡しすべき適当なO/Cデータベース10およびデータベース72事例並びにウオッチすべき臨床試験のリストを含む施設特異的セッテングが含まれる。サーバー・プロセス・モジュール38により特定される各臨床試験ウオッチについて、臨床試験が“テストモード”であるか否かに関して特別の指定がなされる。臨床試験が“テストモード”である場合は、データはO/C臨床モジュール12プロダクション・テーブルよりむしろ、O/C臨床モジュール12テスト・テーブル中にロードされる。
【００７３】
データ交換モジュール42：  このモジュールは前置サイト104に対するインターフェースを提供する。このモジュールによって、前置検討定義70がRDEプロダクツ68中にロードすることが可能になる。このモジュールはサーバー・プロセス・モジュール38との関連で稼動され前置サイト104から新規な患者のデータを抽出することができ、従って、それをO/Cデータベース10中にロードすることができる。1具体例において、データ交換モジュール42はサーバー・プロセス・モジュール38との関連で稼動され、前置サイト104から臨床データを受理し、そのデータをO/C臨床モジュール12に適合するフォームに翻訳する。このプロセスは下記の“Use case 2”の項目の節でより詳細に説明する。
【００７４】
データベース・モジュール48：  好ましい具体例において、データベース・モジュール48はオラクル9iデータベース・サーバーにより支持される。データベース・モジュール48は、サーバー・プロセス・モジュール38により使用又は起生された情報を格納するための持続的リポジトリである。或る具体例において、このデータベース・モジュール48には、パーシステント・ステート記録110、ステータス・アカウント・ブック114および変換マップ32が含まれる。
【００７５】
パーシステント・ステート記録110：  パーシステント・ステート記録110は、サーバー・プロセス・モジュール38により検出される全ての事例を記録するACTIVITYEVENTデータベース・テーブルを含む。パーシステント・ステート記録110は更に、サーバー・プロセス・モジュール38により検出される全てのエラーを記録するERROREVENTデータベース・テーブルを含む。さらに、パーシステント・ステート記録110は、研究および前置サイト104のそれぞれの状態並びに最後の患者の情報がロードされる時間を格納するSTATUSACCOUNTおよびSTATUSACCOUNTLINEデータベース・テーブルを含む。サーバー・プロセス・モジュール38は、新規な患者の情報のためのサイトをポーリングするとき、この情報を使用する。データベース・モジュール48は、検討について行われた検査の結果を格納するSTUDYAUDITデータベース・テーブルを含む。検討が最初にロードされるとき、又は検討が更新されるとき、その検討は検査される。
【００７６】
ステータス・アカウント・ブック114およびタイム・スタンプ76：  ステータス・アカウント・ブック114はパーシステント・ステート記録110の一部であり、前置サイト104ごとに２つのタイム・スタンプ76を保持する。第1のタイム・スタンプ76は、最後に成功裡にロードされた後置臨床応答データを指定する。第2のタイム・スタンプ76は、前置サイト104についての最も最近のタイム・スタンプを指定する。なお、この時点において、O/C識別名3は依然として患者に対し付されていない。すなわち、或るタイム・スタンプ76は、コンピュータ150のサーバー・プロセス・モジュール38からの最後のデータ・アクセスの日時を表している。従って、サーバー・プロセス・モジュール38が、臨床データについて前置サイト104を尋問するとき、選択された前置検討に対応するタイム・スタンプ76が問われる。次に、タイム・スタンプ76が最後に設定されて以来、前置検討定義70についてのデータベース72にエンターされた全てのデータが処理のためコンピュータ150に転送される。
【００７７】
変換マップ32：  各変換マップ32はキーを有し、これには、前置検討定義70および対応する後置臨床定義8について、ビジット、フォーム、質問などのリストが含まれる。一旦、データ交換モジュール42によってデータの翻訳が開始されると、変換マップ32が更新され、これは、前置検討定義70および対応する後置臨床定義8により各患者について使用されている対応する患者番号を用いて行われる。
【００７８】
次に、クライアント180について注目すると、クライアント180は、以下のものを含む：
＊  中央演算処理装置166；
＊  ソフトウエアおよびデータを格納するためのメイン不揮発性格納ユニット164
（好ましくはハードディスク・ドライブ）；
＊  クライアント180を通信チャンネル98に接続するためのネットワーク接続160；
＊  システム制御プログラム、データおよびアプリケーション・プログラム（揮発
性格納ユニット164からロードされたプログラムおよびデータを含む）を格納する
ためのシステム・メモリー170（好ましくは、RAM）；
＊  ユーザー・インターフェース168（1又はそれ以上の入力装置を含む）；
＊  上記要素を本システムに相互に接続するためのインターナル・バス162。
【００７９】
クライアント180の操作は、当業者に公知の方法に従って、操作システム又はラウンド・ロビン方式で制御される。典型的履行において、このシステム・メモリーには、クライアント180並びに本発明で使用される1又はそれ以上のソフトウエア・モジュールを制御するための手段が含まれる。これらのソフトウエア・モジュールには、コンソール・モジュール44および/又はマッパー・クライアント・モジュール6が含まれる。次に、これらのソフトウエア・モジュールのそれぞれの機能および目的について説明する。本発明の或る具体例においては、コンソール・モジュールは、コンピュータシステム180よりは、むしろコンピュータシステム150上に見られる。
【００８０】
コンソール・モジュール44：  コンソール・モジュール44はサーバー・プロセス・モジュール38の一覧を提供し、それを介して、システム管理者が活動をモニターし、システムコマンドを実行することができる。本発明の或る具体例において、コンソール・モジュール44は以下の表示パネルを提供する。すなわち、(i)システム・ステータス・パネル；(ii) システム・メッセージ・パネル；(iii)インスペクト・システム・イベント・パネル；(iv) インスペクト・スタディ・ステータス・パネル；(v) インスペクト/チェンジ・プロパティ・パネル；および(vi)ツール・メニューである。
【００８１】
(i) システム・ステータス・パネル：  システム・ステータス・パネルは、O/C臨床モジュール12、RDEプロダクツ68およびサーバー・プロセス・モジュール38のグラフィックおよびテキストの双方に基づく概要を提供する。モニターされた各ソフトウエア・モジュールについて、関連する情報が提供される。この。モニターしたソフトウエア・モジュールの任意のものの状態に変化が生じると、システム・ステータス・パネルが更新される。
【００８２】
(ii) システム・メッセージ・パネル：  このシステム・メッセージ・パネルは、システム・ステータス・パネルにより開示された一覧よりも、より詳細なシステム状態の一覧が提供される。更に、サーバー・プロセス・モジュール38からのテキストに基づく出力がこのシステム・メッセージ・パネルにより表示される。
【００８３】
(iii) インスペクト・システム・イベント・パネル：  このインスペクト・システム・イベント・パネルはサーバー・プロセス・モジュール38の活動の画像を開示するグラフおよび表を提供する。このグラフは最も最近の10個のプロセス・サイクルからの活動を示す。このグラフは現在の活動の即時の要約を提供することを意図している。一般に、このグラフは、サーバー・プロセス・モジュール38によって如何に多くの検討、サイトおよび患者が処理されたかを示すことができる。X軸はプロセスIDを示す。Y軸は各タイプの如何に多くのものが処理されたかというカウントを示す。表は最も最近発生したアクション（action）およびイベント（event）の一覧を提供する。この表の行は時間、プロセスID、イベントの符号およびイベントの記述を示す。表の行をダブル・クリックすることによりイベント記録の完全な一覧が提供される。
【００８４】
(iv) インスペクト・スタディ・ステータス・パネル：  インスペクト・スタディ・ステータス・パネルはデータの一覧を提供するもので、従って、このシステム管理者は、或る前置サイト104について、如何に多くの患者が処理されたかを判定することができる。前置検討定義70および前置サイト104に関連する臨床研究の選択の後、前置サイト104について患者の1セットが表示される。この患者のリストは前置サイト104についての登録を確認するものである。患者のリストは更に、O/Cデータベース10およびデータベース72中の対応する患者数を表示するものである。これにより、システム管理者は2つのシステムで同一の患者を比較し、全ての情報が正しく転送されたことを確認することができる。
【００８５】
(v) インスペクト/チェンジ・プロパティ・パネル：  インスペクト/チェンジ・プロパティ・パネルはシステム管理者に対し、サーバー・プロセス・モジュール38により使用された特性を検査、変更することを許容するものである。本発明の或る具体例において、このパネルのためにアクセス・プレビレッジ（特典）が強化される。すなわち、ユーザーはインスペクト/チェンジ・プロパティ・パネルに対し何らかの変更を行うためにライト（write）・アクセス・プレビレッジを有していなければならない。
【００８６】
(vi) ツール・メニュー：  ツール・メニューはコマンドをサーバー・プロセス・モジュール38へ送るために使用される。これらは、スタート/ストップ/エネイブル/ディスエイブルなどの高いレベルのコマンドである。各コマンドが表5に記述されている。本発明の或る具体例においては、ライト（write）・アクセスを有するユーザーのみがこのツール・メニューを使用することができる。リード（read）・アクセスを有するユーザーにはこのツール・メニューが与えられず、従って、使用することはできない。
【表４】
2004530223.tif 000007
【００８７】
2004530223.tif 000008
【００８８】
マッパー・クライアント・モジュール6：  マッパー・クライアント・ソフトウエア・モジュール6はマッパー・サーバー・モジュール30に対する遠隔ユーザー・インターフェースである。これはユーザーに対し、前置検討定義70およびその対応する変換マップ32を作成又は更新するためのインターフェースを提供する。マッパー・クライアント・モジュール6の意図するユーザーは、電子的事例報告フォームのデザイナー又は臨床プログラマー、すなわち、新規な臨床試験の設計に関与する人である。臨床試験の開始後、適当な前置検討定義70を更新するのにマッパー・クライアント・モジュール6が使用される。マッパー・クライアント・モジュール6は以下の機能性を提供する。すなわち、(i) 後置臨床定義8又は外部ファイル9をロード（load）すること；(ii) 後置臨床定義又は外部ファイル9に基づいて前置検討定義70を発生させること；(iii) 前置検討定義70を検査し、後置臨床定義8と比較すること；および(iv) 前置検討定義70の電子的特性を変調することである。次に、これらの機能性を、Oracle Clinical (O/C)を後置CDMSとして、MACROを前置RDEプロダクツとして使用する例示的システムを参照して説明する。
【００８９】
(i) 後置臨床定義8又は外部ファイル9をロード（load）すること：  後置臨床定義8は臨床研究を、O/Cデータベース10内の一連のメタテーブルとして定義するものである。本発明の1具体例において、マッパー・クライアント・モジュール６は、図4に示すパネル400のようなインターフェースを用いてO/Cデータベース10から後置臨床定義8をロードする能力を提供するものである。パネル400（図4）中の“Read From DB（DBから読み取る）”のボタン406をクリックすることにより、図3のスタディ・チューザー・ダイアログ・ウインドウ300がユーザーに与えられる。表６はスタディ・チューザー・ダイアログ・ウインドウ300によって提供される各ユーザー・インターフェース・エレメントの目的を説明するものである。
【表５】
2004530223.tif 000009
【００９０】
スタディ・チューザー・ダイアログ・ウインドウ300（図3）において、ユーザーは“OCサーバー” 後置コンピュータ140選択リスト302を用いてサーバーを選択する。後置コンピュータ140選択リスト302は、システム1300（図1）内のアドレス可能な如何なるコンピュータをも指定することができる。しかし、後置臨床定義はO/Cデータベース10をホストするコンピュータにのみ見出すことができる。後置臨床定義8を選択することできる後置コンピュータ140選択リスト302中に表示されているサーバーのリストは、多くの方法の任意の1つにより提供することができる。例えば、システム1300（図1）中の各後置コンピュータ140はコンピュータ150の28のメモリー内のレジストリーに登録することができる。スタディ・チューザー・ダイアログ・ウインドウ300が、次にこの登録を読み取り後置コンピュータ140選択リスト302として表示する。一旦、サーバーが選択されると、選択されたサーバーのO/Cデータベース10中にて利用できる後置臨床定義8のリストがスタディ・ネーム・ボックス304に表示される。
【００９１】
O/Cデータベース10から後置臨床定義8をロードするよりはむしろ、パネル400の“ファイルから読み取る（Read from File）”ボタン404を用いて外部ファイル9をマッパー・クライアント・モジュール6によりロードすることができる。外部ファイル9には、臨床研究の完全な記述が含まれている。ユーザーが“Read from File”ボタン404を選択すると、パネル300のものと似たパネルが表示される。このようなパネルが、ついで、ロードされるべきシステム1300内の外部ファイル9を選択するのに使用される。
【００９２】
(ii) 前置検討定義70の発生：  以下に詳述するように、後置臨床定義70（例えば、マクロ検討定義）は臨床研究を一連のメタテーブルとして定義づけるものである。これらのメタテーブルは遠隔データ・エントリ（Remote Data Entry）のために最適化される。マッパー・クライアント・モジュール6が一旦、パネル300（図3）を用いて後置臨床定義8を、又、パネル300と同様のウインドウを用いて外部ファイル9をロードすると、対応する後置臨床定義8がパネル400（図4）の“検討発生（Generate Study）”ボタン402を用いて発生されることになる。一旦、ボタン402が押されると、ロードされた後置臨床定義8に適合する前置検討定義70がパネル400のフィールド440中に表示される。
【００９３】
本発明の1具体例において、ユーザーが“検討発生”ボタン402を用いて前置検討定義70の発生を要求したとき、システム1300の現在の状態が分析され、その結果がユーザーに知らされる。特に、もしも、前置検討定義70又は対応する変換マップ32がシステム1300内に存在しないとき、ユーザーは新規な前置検討定義70および対応する変換マップ32の形成を承認するよう促される。もしも、前置検討定義70および選択された後置臨床定義8の対応する変換マップ32の双方が1300内に存在し、患者のデータが記入されていない場合は、現在の前置検討定義70および対応する変換マップ32を変更することができないことがユーザーに知らされる。マッパー・クライアント・モジュール6が終了し、前置検討定義70および選択された後置臨床定義8の対応する変換マップ32が発生したとき、それがユーザーに知らされる。ダイアログ・ウインドウは、この検討定義プロセスの結果を表示する。もしも、問題が発生した場合は、警告又はエラーメッセージがダイアログ・ウインドウに表示される。
【００９４】
(iii) 検討定義の検査と比較：  一旦、検討定義がロードされ、発生すると、パネル400（図4）は、後置臨床定義8および対応する前置検討定義70の内容を同時に検査させるための分類体系的ツリー（tree）を提供する。例えば、図4は、選択されたオラクル・クリニカル定義および対応するマクロ検討定義の並列的配置を示し、視覚による比較を容易にしている。表7は本発明の1具体例に係わるユーザー・インターフェース・エレメントのそれぞれの目的を説明している。
【表６】
2004530223.tif 000010
【００９５】
ユーザーがパネル400を使用してマクロ検討定義を検査するとき、それが対応するオラクル・クリニカル定義から正しく翻訳されているか否かを判定するため、任意のマクロ電子的事例報告フォームページを調べることができる。例えば、パネル400中に表示されているマクロ検討定義の電子的事例報告フォーム・ノードを右クリックしたとき、ダイアログ・ウインドウが形成され、電子的事例報告フォームがMACROユーザーに対し、どのように提示されるかについての描写が新規に作成されたダイアログ・ウインドウ中に表示される。
【００９６】
(iv) 前置検討定義70の電子的特性を変調する：  図4において、コンフィギャー・タブ420は、電子的事例報告フォーム（eCRF）のレイアウトを画成する特性を含むユーザー・インターフェースを提供する。RDEプロダクツ68又はマッパー・サーバー・モジュール30によりマクロ検討定義が作成および/又は更新されたとき1セットのフォームが発生する。ユーザーが図4のコンフィギャー・タブ420を選択したとき、コンフィギャー・タブ・パネル500が表示される（図5）。コンフィギャー・タブ・パネル500は前置検討定義70電子的事例報告フォームの電子的外観およびレイアウトを画成する。パネル500を使用することにより、ユーザーは電子的事例報告フォームの視覚的特性を検査、変更することができる。表8はコンフィギャー・タブ・パネル500についてのユーザー・インターフェース・エレメントの記述を提供するものである。
【００９７】
本発明の1具体例において、コンフィギャー・タブ・パネル500中の特性が分類体系的ツリーとして配置される。ホルダーとして表示されたノードは特性キー（property keys）である。各特性キー・ノードは1又はそれ以上の特性値ノードを表示するように拡張することができる。本発明の好ましい例において、特性キー・ノードは変更することができない。特性キー・ノード・プロパティ内において、値を加入、編集又は削除することができる。所望により、特性キーから全ての値を削除することもできる。
【表７】
2004530223.tif 000011
【００９８】
（6.2  別のシステム・トポロジー）
図2は、本発明による別のシステム1400のトポロジーを示している。このシステム1400において、ソフトウエア・モジュールの多くが、システム1300の対応するソフトウエア・モジュールが帰属するコンピュータとは異なるコンピュータに帰属している。すなわち、このシステム1400において、RDEプロダクツ68はサーバー204-1に帰属している。デーモン（daemon）・モジュール36、データ交換モジュール42およびサーバー・プロセス・モジュール38はサーバー250に帰属している。データベース72およびデータベース・モジュール48はサーバー204-2に帰属している。O/C臨床モジュール12はサーバー240に帰属している。最後に、マッパー・クライアント・モジュール6およびコンソール・モジュール44は別のコンピュータに帰属している。なお、図示していないが、システム1400中の各コンピュータは通信チャンネル（有線又は無線の通信チャンネルでもよい）を介してこのシステムに接続されている。
【００９９】
このシステム1400は、本発明が広範なフレキシビリティを与えるものであり、従って、本発明で使用されるソフトウエア・モジュール、データベース又はファイルの如何なるものも、システム内でアドレス可能である限り、システム1300、システム1400又は関連するシステム内の如何なるコンピュータに対しても帰属することができるということを説明するものである。なお、ここで、アドレス可能とは、システム内の１つのコンピュータに帰属するソフトウエア・モジュール、データベース又はファイルがシステム内の他のコンピュータによってアクセスできることを意味するものである。このようなアクセス可能性には、正当化される場合は、ソフトウエア・コンポーネントから実行、検索、読み書きすることができる能力を含むものである。
【０１００】
（6.3  使用事例のシナリオ）
本発明による2つの例示的システムのコンポーネント（成分）が図1およびお図2に示召されている。本発明の利点の多くを説明する３つの使用事例のシナリオに注目して見よう。第1の使用事例のシナリオにおいて、後置臨床定義8がマッパー・サーバー・モジュール30により前置検討定義70に変換される（図1）。第２の使用事例のシナリオにおいて、サーバー・プロセス・モジュール38および/又はデータ交換モジュール42が、前置サイト104から臨床データを得、ついで翻訳キーとしての適当な変換マップ32を使用し、後置臨床定義8に従ってデータベース10内のO/C臨床モジュール12により格納することができる様式で、その臨床データをフォーマットする。第３の使用事例のシナリオにおいて、データ確認モジュール1208（図12）が食違いを検出し、サーバー・プロセス・モジュール38と共に稼動して、その食違いを解決のため修正用後置サイト104へ移送する。
【０１０１】
（6.3.1  使用事例1：  後置臨床定義を前置検討定義に変換する）
図6は“使用事例1”を示し、ここで、後置臨床定義8が対応する前置検討定義70に変換される。プロセスステップ602において、後置臨床定義8がO/Cデータベース10から選択される。1具体例において、後置臨床定義8はオラクル臨床定義であり、これはオラクル臨床モジュール12を使用してO/Cデータベース10から選択、ロードされる。本発明の方法を任意の後置臨床定義から前置検討定義に変換するのに使用することができる。例えば、図6に示す例示的処理方法を、Clintrial 4.3(Clinsoft Corporation, Lexington, MA)又はオラクル臨床定義（Oracle社、Redwood Shores,カルフォニア州）を用いて作成された後置臨床定義の変換に採用することができる。
【０１０２】
プロセスステップ604において、後置臨床定義8のメタテーブルが選択される。例えば、後置臨床定義8が、表3に記載するメタテーブルを有するオラクル臨床定義である場合を考える。図6に示すプロセスステップの目標は、オラクル臨床定義のメタテーブルに提供されている情報のできるだけ多くのものを使用し前置検討定義70中にメタテーブルを構築し、それによりRDEプロダクツ68は、オラクル臨床定義のフォームを表すのに使用されるスケジュールに似たスケジュールに従って、オラクル臨床定義のデータ・エントリフォームに似たデータ・エントリフォームを有する臨床データについて検索することができる。従って、後置臨床定義8がオラクル臨床定義である場合、プロセスステップ604はCLINICALPLANNEDEVENT、CLINICALSTUDY、DATACOLLECTIONINSTRUMENTなどのオラクル臨床定義のメタテーブルを提供することができる。一般的に述べて、プロセスステップ606ないし612は、選択されたメタテーブルからできるだけ多くの情報を引き出し、オラクル臨床定義に定義づけされた臨床プロトコルに固定された前置検討定義70を構築するものである。
【０１０３】
プロセスステップ602で選択された各後置臨床定義8について、対応する前置検討定義70および変換マップ32が作成される。前置検討定義70には、1セットのメタテーブル、例えば表2に示すようなメタテーブルが含まれる。前置検討定義70中のメタテーブルの定義およびフォーマットは、前置サイト104により使用される特定のRDEプロダクツ68により決定される。前置検討定義70を作成するのに使用される代表的RDEプロダクツが、ベンダー（vendors）例えばInfermed, Ltd.,(ロンドン、英国)、Phase Forward Inc.,(Waltham, MA)、CB Technology, (Philadelphia, PA)、TEAMworks, (Hannover, ドイツ国)、DataTRAK, (Cleveland, OH)およびAraccel, (Stockholm, スウェーデン国)により提供されている。RDEプロダクツ68がMACRO (Infermed, Ltd.)の場合、前置検討定義70は表2に示すメタテーブルを有する。
【０１０４】
プロセスステップ606において、前置検討定義70中のメタテーブルのいずれかが、プロセスステップ604で選択されたメタテーブル中に見られる情報を使用できるか否かについて決定がなされる。もし、その情報が使用できる場合（606−Yes）、制御がプロセスステップ608に移される。もし、その情報が前置検討定義70で使用できる可能性がない場合（606−No）、制御がプロセスステップ612に移される。
【０１０５】
プロセスステップ608において、プロセスステップ604で選択されたメタテーブル中に見られるデータが、対応する前置検討定義70により要求されるフォーマットに従ってフォーマットされる。その後のステップはプロセスステップ608によってなされる例示的アクションであり、その場合、後置臨床定義8がオラクル臨床定義であり、前置検討定義70がマクロ検討定義である。プロセスステップ604で選択されたメタテーブルが、オラクル臨床定義中のCLINICALPLANNEDEVENTメタテーブルである場合（表3）、プロセスステップ608はCLINICALPLANNEDEVENTメタテーブルから臨床試験名を抽出し、その臨床試験名をマクロ検討定義のClinicalTrialメタテーブル中に載せる（表2）。同様にして、オラクル臨床定義のCLINICALSTUDYメタテーブル中に見られる臨床試験ヘッダー情報（表3）が抽出され、それがマクロ検討定義のStudyDefinitionメタテーブル中に載せる（表2）。プロセスステップ604がオラクル臨床定義のDCIメタテーブルを選択したとき（表3）、より複雑な事例が提示される。DCIメタテーブルはデータ・エントラントに対し、電子フォームについて、提示される一連の臨床質問である。このメタテーブルは質問のみならず、80x40文字ベース表示におけるそれらの位置が含まれる。この場合、プロセスステップ608はDCIからの質問を抽出し、抽出した質問を使用してマクロ検討定義中にDataItemメタテーブルを構築する。他の例において、オラクル臨床定義メタテーブル、DISCRETEVALUEおよびDISCRETEVALUEGROUPSs(表3)がほぼマクロ検討定義メタテーブルValueData(表2)に対応する。従って、オラクル・クリニカルDISCRETEVALUEおよびDISCRETEVALUEGROUPメタテーブルと、マクロ検討定義ValueDataメタテーブルとの間の対応がプロセスステップ608において、ValueDataメタテーブルをマクロ検討定義に移す（populate）のに使用される。
【０１０６】
プロセスステップ610において、プロセスステップ608で発生したフォーマット済みデータが前置検討定義70の適当なメタテーブル内に格納される。最後に、このデータの記録がプロセスステップ612において、対応する変換マップ32内に格納される。
【０１０７】
プロセスステップ604の間に選択されたメタテーブル内に見られるデータを使用できるメタテーブルが前置検討定義70内にない場合（606−No）、そのメタテーブル中のデータの記録がプロセスステップ612において対応する変換マップ32内に格納されるか、若しくは破棄される。1具体例において、前置検討定義70は臨床質問の位置を、80x40文字ベース表示上に確定させる。例えば、後置臨床定義は、質問が現れるテキスト・ベース・スクリーン上の場所を指定するVT100のコードを保持することができる。更に、後置臨床定義は、データ・エントリの間に、グラフィック文字を80x40文字ベース・レガシーディスプレー上に表示させるよう指定することができる。このようなグラフィックは、VT100イクステンデッド・キャラクター・セット（extended character set）中に見出せる水平又は垂直ラインについての文字であってもよい。後置臨床定義8がオラクル臨床定義である場合、このようなグラフィックは、DCMLAYOUTGRAPHICメタテーブル（表3）内に格納される。プロセスステップ604がDCMLAYOUTGRAPHICメタテーブルを選択したとき、条件606-Noが満たされる（図6）。そして、実際に、DCMLAYOUTGRAPHICの内容物が無視される。なぜならば、マクロ検討定義のeCRFフォームは、より複雑なグラフィックを使用するからである。606-Noが生じる場合の他の例は、オラクル臨床定義が質問を繰り返す回数を制限して場合である。マクロ検討定義は繰り返し質問機能を有していない。従って、オラクル臨床定義属性を利用することができない。
【０１０８】
プロセスステップ612が実行された後、このプロセスステップ604で選択されなかったその他のメタテーブルが後置臨床定義8中にあるか否かについての判断614がなされる。もし、そうであれば（614-Yes）、制御がプロセスステップ604に戻され、そこで、前回のプロセスステップ604で選択されなかった後置臨床定義8のメタテーブルが選択される。処理すべきメタテーブルが後置臨床定義8に残っていない場合（614-No）、制御がプロセスステップ616に移され、そこで前置検討定義70が各前置サイト104上に公にされる。この前置サイト104はプロセスステップ602で選択された後置臨床定義8により定義された臨床研究のための臨床データを収集するのに使用されている。ついで、プロセスステップ618において、図6に示す様式でプロセスステップ612を連続的に実行することにより画成された変換マップ32が、コンピュータ150上のデータベース・モジュール48内に格納される。プロセスステップ620において、このプロセスは終了する。
【０１０９】
次に、図7なしい図8Bを参照すると、これらには本発明の具体例で変換マップ32中に見出される選択されたデータ・セグメントが示されている。ここで、後置臨床定義はオラクル臨床定義（表3）であり、前置検討定義70はマクロ検討定義である。“使用事例1”、“使用事例2”および“使用事例3”の間に変換マップ32が使用される。“使用事例1”において、記号鎖が前置検討定義70のコンポーネンツ（対応する後置臨床定義8のコンポーネンツと同等又は類似の）について構築される。“使用事例2”（この場合、臨床データが前置サイト104から収集される）において、変換マップ32を用いて、臨床医、臨床試験に駆り出された臨床サイト104および患者についてのデータが格納される。ついで、“使用事例1”のプロセスステップ612で作成された記号鎖を使用して、後置データ・パケットが構築され、これには“使用事例2”の間に得られた臨床医/臨床サイト104/患者データが含まれている。この後置データ・パケットはついで、O/Cデータベース10内に転送される。“使用事例2”の間に添付された変換マップ32のデータ・セグメント（図8Cないし図10）が“使用事例2”の表題のセクションに記述される。
【０１１０】
オラクル臨床定義中のCLINICALPLANNEDEVENTメタテーブル（表3）の夫々について、マッパー・サーバー・モジュール30がマクロ検討定義（表2）中に対応するStudyVisitメタテーブルを作成し、この対応物の記録をセグメント702に加入する（図7A）。セグメント702において、第1の欄は、マクロ検討定義中に見られるeCRFフォームのコンポーネンツに対するシングル・フィールド・ルックアップ・キーである。セグメント702の第２の欄は、対応するオラクル臨床定義のDCIメタテーブルに対するシングル・フィールド・ルックアップ・キーである。セグメント702の第3の欄は、対応するオラクル臨床定義のDCMメタテーブル（表3）に対する参照識別名である。第2、第3の欄と同様に、欄4-6はオラクル臨床定義の種々のコンポーネンツを同定するものである。
【０１１１】
セグメント702のデータ構造が確定されているから、セグメント702の利点について説明する。セグメント702の最初のデータ列を参照すると、サーバー・プロセス・モジュール38がコード365を受理したとき、前置検討定義と関連するeCRFのコンポーネンツ365に対してエントリがなされたことを知る。eCRFのコンポーネンツ365へのエントリは、例えば、患者の名前であってもよい。更に、セグメント702中に見られるシンボル情報のため、サーバー・プロセス・モジュール38はマクロeCRFフォームのコンポーネンツ365に対する応答が、対応する後置オラクル臨床定義のDCIメタテーブル17036内にエンターされるべきことを知る。
【０１１２】
表3に示したように、オラクル臨床定義には、1又はそれ以上のデータ収集装置（DCIs）が含まれる。DCIメタテーブルがセスステップ604で選択されたとき、マッパー・サーバー・モジュール30はDCIのコンポーネンツを、変換マップ32の2つのセグメント、すなわち、OcDciセグメント（図7B、エレメント704）およびOcDciModセグメント（図7C、エレメント706）に配置する。OcDciおよびOcDciModセグメントは、オラクル臨床定義のDCIメタテーブル（表3）をマクロ検討定義内のeCRFフォーム内の対応するエレメントと相関させる情報を収集する機能に役立つ。すなわち、セグメント704はピリオド・デリミター（period delimiter）により分離された2つの数字を含む。第1の数字はマクロ検討定義内の特別のeCRFフォームを表す。第２の数字は指定されたeCRFフォーム内の特別のコンポーネンツ（例えば、臨床上の質問）を表す。セグメント704の最初の欄（図7B）がマクロ検討定義のコンポーネンツを参照するのに対し、セグメント704の残りの欄はオラクル臨床定義のDCIメタテーブルと関連する種々のアスペクト（様相）を参照する。
【０１１３】
セグメント704の構造が開示されているから、このセグメントがサーバー・プロセス・モジュール38によりどのようにして使用されるかについて1例を説明する。サーバー・プロセス・モジュール38がtmMapKey316.365と関連するデータを受理したとき、そのデータがeCRFフォーム316のコンポーネンツ365に対する臨床上の回答であることを知る。tmMapKey316.365と関連するデータの正確な性質はマクロ検討定義のコンポーネンツ316.365の性質に依存する。例えば、コンポーネンツ316.365は、eCRFフォーム316についての質問“性別は？”であってもよく、tmMapKey316.365と関連するデータは従って、その質問に対する回答、すなわち、“男性”又は“女性”であってもよい。サーバー・プロセス・モジュール38（図1）が関連するデータを受理したとき、セグメント704において、テーブル・ルックアップ（table lookup）が行われ、tmMapKey316.365と関連するデータが、対応するオラクル臨床定義のDCIメタテーブル35736に発送されるべきことを知る。
【０１１４】
図7Cに、例示的OcDciModセグメント706が列挙されている。なお、明確化のため、各列が欄に変換されている。従って、第1の欄はセグメント706内のエレメントの名称を表し、第2、第3の欄は、実際の臨床研究で使用されている変換マップ32からのデータの2つの列を表している。OcDciModセグメント706は、マクロ検討定義のeCRFページに見られる質問のグループを、オラクル臨床定義に見られる質問のグループに対して位置づけている。例えば、セグメント706（図7C）内のデータの最初の欄は質問のグループ“317.null”を参照している。すなわち、TmMapKey識別名は317グループ内の任意の質問、例えば317.1（質問1）、317.2（質問2）などを参照している。次に、セグメント706は、マクロ検討定義中のTmMapKey 317を有する質問のグループが、32936のidを有するDCM(表3)と均等であることを表している。このように、サーバー・プロセス・モジュール38が、TmMapKey識別名317.nullと関連するデータを受理したときは常に、そのデータがマクロ検討定義317内の質問のグループと関連し、これらの質問に対する回答がDCMグループ32936内に置かれる必要があることが知ることになる。
【０１１５】
セグメント704および706は、一緒で、本発明の1つの利点を示している。後置臨床定義8内の個々の臨床上の質問の、前置検討70に対する関係を追跡する記号鎖を個々に格納することにより、その質問をそれが属するグループを編集することなく、後日に変更することができる。
【０１１６】
オラクル臨床定義のDCMメタテーブル（表3）は変換マップ32のOcQuestionセグメント802（図8A）内に格納される。上述のように、オラクル・クリニカルDCMメタテーブルにはデータ収集装置（DCIs）のグループ、例えば臨床上の質問が含まれる。
【０１１７】
オラクル・クリニカルDCMからの質問は、対応するマクロ検討定義メタテーブルに見られない属性を有する。例えば、DCMはユーザーが最早、情報を提供しなくなるまで床上の質問が繰り返し尋ねられることを示唆する属性を有することができる。この“繰り返し”属性の例は、“患者に対し投与される別の薬剤を列挙してください”という催促を、データ・エントラントが患者に対し投与される別の薬剤を最早、提供することができなくなるまで繰り返す場合である。オラクル・クリニカル定義はこの“繰り返し”属性を有するが、マクロ検討定義は有していない。その結果、後置臨床定義に見られる“繰り返し”属性はセグメント804（図8B）内に格納される。セグメント804は更に、他の前置メタテーブルから全体的に得られ、従って後置メタテーブルとは対応することがない前置検討定義70からの質問又は属性を格納する。
【０１１８】
実験室の範囲：  本発明の或る具体例において、食違い、実験の値、コード化された値、範囲が、上記のメタテーブルのデータに加えて、後置臨床定義8から前置検討定義70へ転送される。このような情報には、サイト、対応する研究者および患者（臨床試験に参加している）についてのコードちが含まれる。上記範囲には、実験での正常範囲（例えば、健康な男性、女性についての血清ヘモグロビン濃度の上限および下限）が含まれる。このような具体例において、図6に記載したプロセスの結果は、前置検討定義70の作成であり、それには質問の属性、フォームのレイアウト、フォームのオーダー（form order）、および後置臨床定義8により定義されるビジット（visit）スケジュールが含まれる。
【０１１９】
シソーラスをロードした質問：  或る具体例において、発生した前置検討定義70には、記帳できないものとして、シソーラス‐コード化質問と指定される質問が含まれる。1具体例において、後置臨床定義8が、ゼロ・レングス（zero-length）離散値グループ（例えば、コードリスト）を割り当てることにより、質問がシソーラス‐コード化質問であることを指摘する。前置臨床定義において、対応する質問は臨床医によって記帳することができないであろう。
【０１２０】
中心的にロードした質問：  或る具体例において、発生した前置検討定義70には、記帳できないものとして、質問、質問のグループおよび中心的にロードした質問と指定されるデータ収集モジュールが含まれる。例えば、実験室での質問（laboratory questions）は後置臨床定義8において中心的にロードした質問と呼ぶことができる。従って、対応する前置検討定義70において、この質問は記帳できないものとして指定されるであろう。
【０１２１】
フォームのフォーマット：  本発明の或る具体例において、前置検討定義70におけるフォームは、RDEプロダクツ68（図1）に課せられた空間的制限の範囲内で、後置臨床定義8においてデータ・エントリ・スクリーンについて画成したレイアウトを二重にするようにしてフォーマットされる。
【０１２２】
後置臨床定義8に基づく前置検討定義70の更新：  本発明の或る具体例において、後置臨床定義8を前置臨床定義に対しなされた変更に基づいて更新することができる。このような更新は後置臨床定義8を使用して、臨床研究を開始する前又は後に行うことができる。一般に、このような更新は追加の形をとる。1例として、追加が後置臨床定義8に対してなされ、そして、この追加が、図6に記載したような方法を用いて対応する各前置検討定義70に伝搬される。後置臨床定義8を更新するとき、展開されている検討に対する更新について、O/C臨床モジュール12およびRDEプロダクツ68により課せられた制限は侵害されない。更に、O/C臨床モジュール12およびRDEプロダクツ68により許容される場合は、本発明の方法を、フィールド長さ変更、コードリスト変更およびデータタイプ変更などの質問‐修正変更を履行するのに使用することができる。
【０１２３】
スタディ・オージットを行う：  本発明の或る具体例において、対応する後置臨床定義8および前置検討定義70の自動的オージット（検査）が行われ、検討質問に対するユーザー回答の成功裡の移動および転送を妨げるような不適合性の検出がなされる。1具体例において、誘導質問（derived questions）、質問およびフォームが前置検討定義70に加入され、非臨床的として指定される。非臨床的として指定された誘導質問、質問およびフォームに対する回答はCDMSへは転送されない。なぜならば、対応する後置臨床定義8は非臨床的として指定された誘導質問、質問およびフォームを含んでいないからである。むしろ、これらの誘導質問に対する回答は、例えばデータベース・モジュール48およびオージット・トレイル112を用いて検査される。
【０１２４】
（6.3.2  使用事例2：  臨床データの遠隔データ・エントリ・プロダクツからの検索およびこのデータのレガシー後置臨床データ管理システムへの転送）
図11は、臨床データを前置サイト104から収集し、それをO/C臨床・モジュール12による読み取り可能なフォームに翻訳する例示的プロセスステップを示している。この図11は図1の例示的システム1300との関連で最もよく理解されるであろう。プロセスステップ1102において、サーバー・プロセス・モジュール38が開始され、コンフィギュレーション・ファイル40が開かれる。このコンフィギュレーション・ファイル40には、システム1300（図1）により追跡されている臨床試験の名称のリストが含まれる。このコンフィギュレーション・ファイル40には更に、コンフィギュレーション・ファイル40中に列挙されている臨床試験の夫々についてのデータを収集する前置サイト104のリストが含まれている。
【０１２５】
プロセスステップ1104において、システム1300により追跡されている臨床試験1104の1つの名称がコンフィギュレーション・ファイル40から検索される。ついで、プロセスステップ1106において、臨床試験（“アクティブ” 臨床試験X）のデータを現在収集している前置サイト104の1つが得られる。プロセスステップ1108において、“アクティブ” 臨床試験Xの識別名および前置サイト104を使用してタイム・スタンプ76の登録（poll）がなされる。このタイム・スタンプ76は、パーシスタント・ステート・レコード110（図1）のステータス・アカウント・ブック114中の前置サイト104に対応するものである。原則として、システム1300の前置サイト104には、各実施中の臨床試験に対応するタイム・スタンプ76が存在する。このタイム・スタンプ76は、サーバー・プロセス・モジュール38により最後になされた検索、つまり前置サイト104からの臨床データについての検索の日時を表すものである。前置サイト104が臨床データについて検索された後、対応するタイム・スタンプ76が現在の日時について設定される。
【０１２６】
プロセスステップ1120において、前置サイト104のデータベース72が登録され、タイム・スタンプ76（プロセスステップ1104で検索された臨床試験に対応する）が最後にセットされて以来、何らかの臨床データが得られたか否か判定される。タイム・スタンプ76がセットされて以来、臨床データが得られた場合（1120-Yes）、次に、プロセスステップ1122ないし1141が行われる。もしも、スタンプ76がセットされて以来、臨床データが得られていない場合は（1120-No）、制御がプロセスステップ1142へ移され、そこでコンフィギュレーション・ファイル40がチェックされ、プロセスステップ1104で検索された“アクティブ” 臨床試験Xについてのデータを収集している別の前置サイト104がシステム1300内に存在するか否かについて判定が行われる。
【０１２７】
新規なデータが前置サイト104のデータベース72で入手可能な場合（1120-Yes）、そのデータが前置データ・パケットに包装され、サーバー・プロセス・モジュール38へ転送される（プロセスステップ1122）。この前置データ・パケットはプロセスステップ1104で検索された“アクティブ” 臨床試験Xと関連する特定の前置検討定義70に従ってフォーマットされている。
【０１２８】
プロセスステップ1124において、プロセスステップ1122で検索された前置データ・パケットが、その中の新規な患者の名前を知ることにより解析される。なお、ここで新規な患者とは変換マップ32（或る前置検討定義70およびO/C識別名3（図1）に対応し、対応するO/Cサイト、O/C調査者およびO/C患者コードを記述したもの）内に配置されていない患者として定義する
プロセスステップ1126において、サーバー・プロセス・モジュール38は、前置検討定義70の要求された識別名フォーム中にセットアップされている特別の質問に対する回答を前置データ・パケット内にて探す。プロセスステップ1130において、もし、これらのO/C識別名質問が前置データ・パケット内に正しくファイルされている場合（1126-Yes）、次に、サーバー・プロセス・モジュール38は、新規な患者を“アクティブ” 臨床試験Xおよび前置検討定義70に対応する変換マップ32に加入する。なお、この変換マップ32への加入は、新規な患者が、前置検討定義70又は対応する後置臨床定義8内に追跡できるような様式で加入されるということを理解されたい。
【０１２９】
新規な患者が、患者に要求されているところの、前置サイト104、調査者、又はO/C識別名3により要求されている患者コード指定の1つ又はそれ以上を欠けている場合、サーバー・プロセス・モジュール38がそのエラーを感知し、それをプロセスステップ1128において前置サイト104のオペレータにそれを知らせる。更に、前置サイト104からの全ての臨床データは、適当なO/C識別名3が全ての患者についてエンターされるまで延期される。本発明の他の具体例において、新規な患者のデータがプロセスステップ1128で拒否される。ついで、前置データ・パケット中の別の新規な患者について検索がなされる。もし、更なる患者が前置データ・パケット中に存在する場合（1140-Yes）、プロセスステップ1124が繰り返される。
【０１３０】
もし、更なる患者が前置データ・パケット中に存在しない場合（1140-No）、その臨床試験に対応する変換マップ32を用いて、後置データ・パケットの構築が行われる。つまり、プロセスステップ1141において、一回に1つのデータが構築される。得られた回答のO/Cシーケンスは長さがデータベース72中に格納されている対応するシーケンスのものとは異なることがある。例えば、本発明の或る具体例において、オラクル・クリニカル定義の繰り返しデフォルト（規定値）はマクロ検討定義において問題にもならず、従って、サーバー・プロセス・モジュール38は対応するマクロ検討定義にその様なオージット・トレイル記録が存在しない場合は、オラクル・クリニカル定義のデフォルト回答を作成する。他の具体例として、或る要求された識別名の質問は“使用事例1”の間、マクロ検討定義についてサーバー・プロセス・モジュール38により作成される特別の質問である。従って、これらはオラクル・クリニカル定義には存在しない。このような質問に対する如何なる回答についても、対応する列は後置データ・パケットに存在しない。しかし、本発明の好ましい具体例において、RDEプロダクツ68により提供される全ての回答は後置データ・パケットに同一のオーダーで現れる。一旦、後置データ・パケットが発生すると、それはO/Cデータ・キャプチャーAPI 14を用いてO/Cデータベース10へアップロードされる。
【０１３１】
プロセスステップ1141の後、制御はプロセスステップ1142へ移され、そこでコンフィギュレーション・ファイル40がチェックされ、プロセスステップ1104で検索された“アクティブ” 臨床試験Xについてのデータを収集している別の前置サイト104がシステム1300内に存在するか否かについて判定が行われる。もし、“アクティブ” 臨床試験Xについての臨床データを収集している別の前置サイト104が存在すれば（1142-Yes）、制御がプロセスステップ1106へ戻され、そこで“アクティブ” 臨床試験Xについての臨床データを収集している異なる前置サイト104が選択される。もし、“アクティブ” 臨床試験Xについての臨床データを現在収集している別の前置サイト104が存在しないことがコンフィギュレーション・ファイル40により明らかにされたときは（1142-No）、制御がプロセスステップ1152へ移される。
【０１３２】
プロセスステップ1152において、システム1300により現在、追跡されている別の臨床試験が存在するか否かについて、コンフィギュレーション・ファイル40の検索がなされる。もし、存在すると（1152-Yes）、制御がプロセスステップ1104へ戻され、そこで異なる“アクティブ臨床試験X”がコンフィギュレーション・ファイル40により検索され、プロセスステップ1108ないし1152が従って繰り返される。システム1300により現在、追跡されている別の臨床試験が存在しない場合（1152-No）は、このプロセスは終了する（1170）。
【０１３３】
典型的な例において、図11に示す例示的プロセスステップがスケジュールに従って行われる。例えば、1例として、プロセスステップ1102が自動化スケジュール装置により“日”ベースで開始される。
【０１３４】
図11のプロセスステップが開示されたので、“使用事例2”の間に更新された変換マップ32のセグメントについて説明する。一般に、セグメント806（図8C）は、臨床サイトを前置検討定義から、対応する後置臨床定義へマップ（map）し、セグメント9A（図9A）は、臨床データを収集する調査者の識別を前置検討定義から、対応する後置臨床定義へマップし、セグメント904（図9B）は、実際の患者を前置検討定義から、対応する後置臨床定義へマップする。
【０１３５】
セグメント806（図8C）は、或る例示的変換マップ32内に見られるOcSiteセグメント806を描いている。セグメント806は前置サイト104から情報を収集する。セグメント806の第1欄において、tmMapKeyは前置サイト“rp101621”にいる患者を参照する。従って、セグメント806の第1のデータ列は前置サイト104“rp101621”の患者番号１を参照し、第2のデータ列はサイト“rp101621”の患者番号2を参照し、第3のデータ列はサイト“rp101621”の患者番号3を参照する。欄2ないし7は、第1欄に見られるサイト情報について、対応するオラクル・クリニカル定義識別名情報を列挙するものである。セグメント806は、或る前置サイト104と関連する情報を、そのサイトについて保存された後置臨床定義の特異なコンポーネントへ発送するために使用される。
【０１３６】
セグメント902（図9A）は前置サイト104で各患者についてのデータを収集する調査者の名前を追跡する。第1欄は、サイトおよび患者idを参照する。例えば、セグメント902の第1のデータ列において、サイト“rp101621”の患者が挙げられている。第3欄は患者についてのデータを収集する調査者のidを開示している。第2欄は第1欄の患者のデータを収集する調査者のオラクル・クリニカルidを開示している。セグメント806は、前置サイト104における或る臨床調査者と関連する情報を、その臨床調査者について保存された後置臨床定義の特異なコンポーネントへ発送するために使用される。
【０１３７】
セグメント904（図9B）は例示的OcPatientセグメント904を示すもので、これは本発明による或る変換マップ32内に見出すことができる。変換マップ32のセグメント904は、前置検討定義70要求識別名フォームから入手可能な患者識別名フォームを収集する。この識別名フォームはマッパー・サーバー・モジュール30により前置検討定義70のために作成される。セグメント806は、前置サイト104で或る患者と関連する情報をその患者について保存されている後置臨床定義の特異なコンポーネンツに発送するのに使用される。
【０１３８】
セグメント906（図9C）は例示的OcKeyセグメント906を示すもので、これは本発明による或る変換マップ32内に見出すことができる。このOcKeyは、オラクル臨床定義（Oracle Clinical definition）の或るメタテーブルと、“使用事例1”のプロセスステップにおいて発生したマクロ検討定義の対応するメタテーブルと間の1対1相関を記録する。この相関にはオラクル臨床定義のDISCRETE VALUEメタテーブル（表3）と、マクロ検討定義の対応するValueDataメタテーブル（表2）との間の対応が含まれる。
【０１３９】
セグメント1002（図10）は例示的SpecialValuesセグメント1002を示すもので、これは本発明による或る変換マップ32内に見出すことができる。特に、このセグメント1002は代表的臨床試験に使用される値を示す。このSpecialValuesセグメント記録は、前置サイト104および患者識別名をO/C臨床モジュール12、研究者および患者識別名と相関させるのに、データ交換モジュール42が使用しなければならない情報を提供するデータアイテムを識別する。セグメント1002のカラム2は前置検討定義70のためのビジット（visit）識別名およびデータアイテム識別名を提供する。
【０１４０】
エラー・ハンドリング（Error Handling）：  サーバー・プロセス・モジュール38は、システム1300（図1）全体を通して、幾つかの異なるサーバーおよびデスクトップ・コンピュータに亘って潜在的に分配されている多くの異なるモジュールと相互作用するため、サーバー・プロセス・モジュール38の好ましい具体例には、ロバスト（robust）・エラー・ハンドリング・フィーチャーのセットが含まれる。以下のものは、本発明の或る具体例で提供される代表的エラー・ハンドリング・フィーチャーのセットである。
【０１４１】
システムサービスの破壊された接続/損失：  データ交換モジュール42又はO/C臨床モジュール12を介してのRDEプロダクツ68に対する接続の問題が生じたとき、サーバー・プロセス・モジュール38はEメールにより、それを管理者ユーザーに知らせ、その接続が復元されるまで何度も試みる。
【０１４２】
データ・エラー-不能サイト：  本発明の或る具体例において、RDEプロダクツ68から検索されたデータ（図11、プロセスステップ1122）内に、又はO/Cデータベース10へのそのデータのローディングの間（図11、プロセスステップ1141）にエラーが検出されたとき、そのデータが由来する前置サイト104が“bad”とマークされ、問題が修正されるまで、その前置サイト104からのデータの更なるロードは不能とされる。一旦、問題が解決すると、コンソール・モジュール44を用いてその前置サイト104が使用可能となり、その前置サイト104での処理が可能となる。
【０１４３】
不完全なO/C識別名のため前置サイト104が延期される：  如何なる翻訳又はデータ・ロードエラーについても、サーバー・プロセス・モジュール38は、原因の前置サイト104を問題ありとしてマークし、サーバー・プロセス・モジュール38は、その問題が修正されるまで、前置サイト104からのデータを翻訳したり、ロードすることを止める。翻訳又はロードエラーの場合、その修理（fix）はアドミニストレータに依存される。一旦、この例示するサーバー・プロセス・モジュール38が、O/C識別名３により元の患者‐マッピング問題の修理を検知すると、このモジュール38は当初の問題が生じる前から前置サイト104にあったRDEプロダクツ68からの全てのデータを要求する。従って、本発明の1具体例において、データベース・モジュール48中のステータス・アカウント・ブック114は、1つのサイトについて2つのタイム・スタンプ（time stamps）を保持する：すなわち、最後に成功裡にロードされたマクロ回答の1つと、前置サイト104について最も最近のスタンプであって、その時点でO/C識別名3が依然として患者について欠けているものである。或る具体例において、前置サイトからのデータは、各患者からのデータに問題がある場合は、延期されない。むしろ、前置サイト104がその患者についてのデータを処理することを、その患者のデータの問題が解決されるまで、拒否する。
【０１４４】
内部エラー：  この例示のサーバー・プロセス・モジュール38は、パーシステント・ステート（persistent state）記録110（図1）内に発生した全てのイベント（events）のパーシステント・ログを記録する。致命的エラー（例えばシステム機能不全を生じさせるもの）と思われるイベントは可能な限りトラップされ、警告Eメールが管理ユーザーに送られる。
【０１４５】
回答データのインクリメント（増分）転送：  本発明の或る具体例において、データベース・モジュール48は臨床データについてのステータス・アカウント情報を維持し、どのデータおよび食違いが新規であるかを追跡する。更に、ステータス・アカウント情報が臨床試験において各患者について単一患者ベースで維持される。本発明の或る具体例において、RDEプロダクツ68についてのオージット・トレイルがビジット‐デート（visit-date）変化について登録（poll）され、これらのビジット‐デート変化が、対応する後置臨床定義8内のアプライカブル・データ収集装置およびデータ収集モジュールに適用される。
【０１４６】
実験室データおよびコード化シソーラス用語の転送：  本発明の或る具体例において、実験室データおよびコード化シソーラス用語がO/Cデータベース10からRDEプロダクツ68へ移送される。実験室データは一般的に前置サイト104とは独立した状態で得られる。例えば、或る具体例において、実験結果が、ジェネリック・ローダー1204を使用して実験室からO/Cデータベース10へロードされる。1具体例において、実験室データ又はコード化シソーラス用語として指定されたデータは前置サイト104からO/Cデータベース10へは再ロードされない。
【０１４７】
（6.3.3  本発明の1具体例に従って前置および後置インデペンダント（independent）・フォーマットにフォーマット化されたデータ・パケット）
1. 序文：  本発明はその1具体例に従って変換マップ32を使用してRDEプロダクツ68と、O/Cデータベース10との間のデータの交換に使用されるパケット構造の新規なフォームを提供するものである（図1）。1具体例において、後置臨床定義8はOracle臨床定義であり、前置検討定義70はマクロ検討定義である。しかし、当業者にとって、本発明のパケットがOracle臨床定義以外の任意のタイプの後置臨床定義8、並びにマクロ検討定義以外の任意のタイプの前置検討定義について使用可能なことを理解されるであろう。その様なパケットは、ここに記載したものと同様の構造を有するであろう。
【０１４８】
このデータ・パケットは、後置CDMSおよび前置RDEのデータ構造要求から絶縁されたデータ交換が望まれるシステム1300に適している。1例として、後置CDMSがOracle臨床定義である臨床定義8を使用し、前置RDEがマクロ検討定義である検討定義70を使用する場合を挙げることができる。臨床定義8および検討定義は、同一の臨床試験データを包含するものであるが、これらはフォーマットにおいて同一ではない。本発明のデータ・パケットはこれら2つのフォーマット間でデータを交換するのに使用することができる。
【０１４９】
本発明の1具体例によるデータ・パケットはジェネリック・“パケット”データ構造を提供するものであり、このデータ構造はデータをOracle臨床又はマクロフォーマットにカプセル化することができる。本発明の1具体例において、“使用事例1”および“使用事例2”に記述された後置パケットおよび前置パケットは同様のデータ構造を有する。サイト、臨床医および患者データに加えて、このようなパケットには、目的を説明したり、前置検討定義70と、対応する後置臨床定義8との間の関係をマッピング（mapping）するために使用されるデータの収集のためのサポートが含まれる。
【０１５０】
後置および前置の独立したデータ構造にフォーマットされた“パケット”を使用する利点は、特定の後置又は前置プロダクツの夫々についてコード化することを要することなく、ジェネリック・レベルでパケットを取扱うコード機構を再使用することができることである。例えば、1例として、本発明のパケットは、パーシスタント（持続的）・データ・ストア内に任意の“パケット”を格納することを許容する機構を提供する。
【０１５１】
本発明のこの具体例によるデータ・パケットの他の利点は、パケットの内容を、ソース・コードを再編集することを要せずに容易に変更することができることである。なぜならば、パケット定義が後置又は前置定義とは独立したファイルに保持されているからである。このパケット定義それ自体が有用である。なぜならば、それによりパケットの内容を標準化することが可能となり、更にシステムの異なるバージョンの管理の標準化も可能となる。
【０１５２】
2. 標準パケット・データ構造：  本発明の1具体例によるパケットのデータ構造が図14に示されている。パケット1400（後置又は前置独立データ構造にフォーマットされている）は以下のような基本的構造を有する：
＊  単一のパケット・ヘッダー1402の跡に1又はそれ以上のデータ・セグメント1408
が続いている。
【０１５３】
＊  各データ・セグメント1408は、レイアウトを記述する単一のデータ・セグメン
ト・ヘッダー1410を有している。
【０１５４】
（i）パケット・ヘッダー1402:  パケットのパケット・ヘッダー部分は、オージット・トレイル情報（1406）（例えば、システム・バージョンおよびパケットを作成又は変更した者）と共に、パケット中に含まれるデータのタイプ（例えば、データタイプ1404）の記録を可能にする。ヘッダー値が一連のプロパティとして格納され、従って現存するコードベースを再編集することを要せずに、延ばすことができる。Study Mapping Relationship Packet (StudyMap)からの例示的ヘッダー1402が表9に示されている。
【表８】
2004530223.tif 000012
【０１５５】
ヘッダーラインの最初の部分はパケットの名称を示すもので、この場合は、“com.roche.rde.wip.metamapper.StudyMap.”である。ヘッダーラインの次の部分は括弧したブロックであり、キーの任意の数および対の値（value pairs）を保持している。例えば、ラインの最初のキー、“build.number”は0の値を有する。次のキー、“StudyName”は“RS1”の値を有している。以下同様。
【０１５６】
(ii) データ・セグメント・ヘッダー1410：  各データ・セグメント1408はデータ・セグメント・ヘッダー1410を含んでいる。データ・セグメント・ヘッダー1410は関連するデータ・セグメント1408の次の列に見られるデータのレイアウトを記述するものである。データ・セグメント・ヘッダー1410は更に、データ・セグメント・ボディ1412内にどれほど多くのデータ列が見出せるかを示す。この値の使用はパケットに含まれるデータが損なわれないことを確実にするものである。マクロ患者データ応答パケット(TMDataPacket)からの“DataItemResponse”セグメントについてのヘッダーの例が表10に開示されている。
【表９】
2004530223.tif 000013
【０１５７】
表10に記載したデータ・セグメント・ヘッダー1410がパケット・ヘッダーと同様の“％％”プレフィックス・コンベンション（prefix convention）を使用し、データ列と区別している。表10の最初のラインはデータ・セグメント1408を命名するものである。この場合、データ・セグメント1408は“DataItemResponse”と呼ばれる。表10中の第2のラインは、データ・セグメント・ヘッダー1410に対応するデータ・セグメント・ボディ1412内に見出されるデータ列の数を記録するものである。表10中の残りのラインは、データ・セグメント・ボディ1412内に見出されるフィールドのそれぞれを命名するものである。
【０１５８】
(iii) データ・セグメント・ボディ1412：  データ・セグメント・ヘッダー1410のすぐ後にはデータ・セグメント・ボディ1412がある。データ・セグメント・ボディ1412はパケットが包含する実際のデータを含む。1具体例において、データは一連の列に格納され、これら列はタブで区切られた（このデリミッターは形状化することができる）フィールドの1セットを保持する。このフィールドは実際のデータ値を保持する。データ・セグメント・ボディ1412内の列の数および個々のフィールド名が対応するデータ・セグメント・ヘッダー1410内に示されている。表11は、表10に示した“DataItemResponse”データ・セグメント・ヘッダー1410についての対応するデータ・セグメントからの列を開示するものである。
【表１０】
2004530223.tif 000014
【０１５９】
表11において、各データ値は‘Tab’文字により次のものから分離されている。更に、データ値は単純な“string”表示で表され、従って人がそれらを読み取ることができる。
【０１６０】
(iv) パケット定義：  本発明のこの具体例によるパケットはJavaプロパティ・ファイルと呼ばれる関連するASCIIテキストファイルを使用して定義される。“Status Account Packet”についての定義ファイルの例を表12に示す。
【表１１】
2004530223.tif 000015
【０１６１】
表12に示すファイルの各部分はキーおよび対の値を定義するものである。例えば、第1のラインは、パケットが4つのセグメント、すなわち、“SystemInfo”、“StudyInfo”、 “StudySiteInfo”および “Statistics”を有することを示している。残りのラインはセグメントの夫々のレイアウトを記述するものである。例えば、“SystemInfo”セグメントは9つの異なるフィールドに分割することができ、これらは以下のように命名される。すなわち、“siterota”、 “studyrota”、 “siteupdated”、 “studiesupdated”、 “patientsupdated”、 “rdesystemenabled”、 “ocsystemenabled”、 “processid”および“processstarttimestamp”である。更に、各キー（‘=’印の前の部分）がサフィックス・バージョン・コード（この場合、1.0）を有することを留意すべきである。この方法を用いてパケットの異なるバージョンを同一の定義ファイルを使用して定義することができる。このようにして、本発明はシステムの初期のバージョンを使用して作成されたパケットを支持することができる。
【０１６２】
3. 後置から前置への臨床定義の移送：  図15は本発明のパケットが、後置臨床定義が後置CDMSから前置RDEへ送信するために、どのようにして使用されるかを説明するものである。図15に示した例示的プロセスステップは、システム1300（図1）を用いて行われる。ステップ1502において、O/C臨床モジュール12が後置臨床定義8を得、この定義をO/Cメタパケットにフォーマットする。このO/Cメタパケットは図14に示すデータ構造を有するパケットのフォームである。1例として、プロセスステップ1502で選択される後置臨床定義は“BA15428”である。この例において、ステップ1502は以下のパケット・ヘッダー1402を有するO/Cメタパケットを生じさせる（更に、図14も参照のこと）。
【表１２】
2004530223.tif 000016
【０１６３】
表13に示すパケット・ヘッダー1400は、パケットをO/Cメタパケットとして識別する。更に、このO/Cメタパケットの例には16個のデータ・セグメント1408が包含される。各データ・セグメントは、プロセスステップ1502で選択された後置臨床定義8の特定の部分の詳細を提供する。臨床試験“BA15428”についての後置臨床定義8に相当する、このO/Cメタパケット例中に見られる16個のデータ・セグメントを下記表14に示す。
【表１３】
2004530223.tif 000017
【０１６４】
表14内の各データ・セグメント1408の名称は上記表3中の同様に命名されたメタテーブルに相当する。表3は本発明の1具体例に従って、後置臨床定義8中に見出されるメタテーブルを記載したものである。表14と、表3との間の関係を説明すると、“Clinicalplannedevents”と名付けられた表14中のデータ・セグメント1408は、表3中に記載したように、“Clinicalplannedevents”と名付けられたメタテーブルについてのデータを保持するために使用される（以下、同様）。
【０１６５】
図15を参照すると、プロセスステップ1504において、O/Cメタパケットがコンピュータ150へ転送される（すなわち、コンピュータ150はO/Cメタパケットを受理する）。プロセスステップ1506において、マッパー・サーバー・モジュール30がO/Cメタパケットを前置検討マップに変換され、これはTMメタパケットのフォームにパケットかされる。更に、変換マップ32が作られ、従って、データを将来において、前置RDEからO/Cデータベース10に転送することができる。TMメタパケットは図14に示す同一のデータ構造を有する。すなわち、TMメタパケットはパケット1400（図14）である。
【０１６６】
臨床試験例“BA15428”の場合において、プロセスステップ1506で作成されたTMメタパケットは以下のパケット・ヘッダー1402を有する。
【表１４】
2004530223.tif 000018
【０１６７】
表15に示すパケット・ヘッダー1400は、パケットをTMメタパケットとして識別する。更に、このTMメタパケットの例は9個のデータ・セグメント1408を含む。このTMメタパケット中の9個のデータ・セグメント1408は、本発明の1具体例に従って、前置検討定義72中に見出される種々のコンポーネントを含む。臨床試験“BA15428”についてのこのTMメタパケット中の、この9個のデータ・セグメント1408のタイトルを下記表16に示す。
【表１５】
2004530223.tif 000019
【０１６８】
表16中の各データ・セグメント1408の名称は上記表2に同様に命名したメタテーブルに相当するものである。上記表2は、本発明の1具体例に従って、前置検討定義70中に見出されるメタテーブルを記載したものである。“Clinicalplannedevents”と名付けられた表14中のデータ・セグメント1408は、表3中に記載したように、“Clinicalplannedevents”と名付けられたメタテーブルについてのデータを保持するために使用される（以下、同様）。
【０１６９】
プロセスステップ1508において、TMメタパケットがRDEプロダクツ68へ転送される。プロセスステップ1510において、RDEプロダクツはTMメタパケットを前置検討定義に変換するよう命令される。或る具体例において、RDEプロダクツ68により提供されるアプリケーション・プログラミング・インターフェース193を用いることによりプロセスステップ1510の容易化が図られる。アプリケーション・プログラミング・インターフェース（“API”）193の使用は利点を有する。なぜならば、前置検討定義70のRDEプロダクツ68へのアップロードが、RDEプロダクツ68の特別の構成の知識を必要とせずに可能になるからである。MACRO 3.0のようなプロダクツにはAPI 193が含まれる。
【０１７０】
臨床試験“BA15428”に対応するTMメタパケットがサイト104でRDEプロダクツ68へ移送されると、サイト104は臨床試験“BA15428”についての臨床データの収集を開始する。従って、後日、サイト104で収集された臨床データが前置サイト104から後置サイト140へ転送される。本発明の1具体例において、パケット1400がこの仕事を行うために使用され、この場合、図16に示すプロセスステップが用いられる。
【０１７１】
ステップ1602において、臨床試験“BA15428”に対応する前置検討定義70により管理される或る臨床試験についての新たなデータのために、データベースをポーリングするように、RDEプロダクツ68が命令される。或る具体例において、API 193はステップ1602を容易にする。データが見付けられたとき、プロセス制御によりステップ1604へ移行する。ステップ1604において、臨床試験“BA15428”についての入手可能な臨床データを、“TM Data Packet”にフォーマットするようにRDEプロダクツ68が命令される。TM Data Packetは図14に示すデータ構造を有し、これにはパケット・ヘッダー1402およびデータ・セグメント1408が含まれる。例えば、プロセスステップ1604の1例において、臨床試験“BA15428”についてのパケット・ヘッダー1402が表17に示されている。
【表１６】
2004530223.tif 000020
【０１７２】
表17に示すパケット・ヘッダー1400は、パケットをTMデータ・パケットとして識別する。パケット・ヘッダーに加えて、臨床試験“BA15428”についてのTMデータ・パケットは5個のデータ・セグメント1408を含む。すなわち、“TrialSubject”、“VisitInstance”、“CaseReportFormPageInstance”、“DataItemResponse”および“DataItemResponseHistory”である。これらデータ・セグメントの夫々は、臨床試験“BA15428”についての前置検討定義中に見られるメタテーブルに対する種々の応答に相当する。
【０１７３】
プロセスステップ1606において、TMデータ・パケットがコンピュータ150（図1）に転送される。ステップ1608において、マッパー・サーバー・モジュール30がTMデータ・パケット・ヘッダーを読み取り、このパケットが関係する臨床試験およびこのパケットが発生するサイト104の特定について判定される。ステップ1610において、データ交換モジュール42が、マッパー・サーバー・モジュール30および適当な変換マップ32との関連で、TMデータ・パケットを“O/Cデータ・パケット”に変換される。このステップ1610で作成されたO/Cデータ・パケットは図14に記載したデータ構造を有する。特に、ステップ1610で作成されたO/Cデータ・パケットはパケット・ヘッダー1402および“BatchLoad”と呼称される単一のデータ・セグメント1408を含む。BA15428臨床試験の場合、O/Cデータ・パケットは以下のようなパケット・ヘッダー1402を有する。
【表１７】
2004530223.tif 000021
【０１７４】
表18のパケット・ヘッダー1402はパケットをO/Cデータ・パケットとして識別する。ステップ1612において、O/Cデータ・パケットがCDMS140へ移送され、O/Cデータベース10に読み込まれる。或る具体例において、O/Cデータ・キャプチャーAPI14を使用して、データがO/Cデータ・パケットにロードされる。
【０１７５】
図15および図16は、一緒になって、図14に示す新規なデータ構造を有するパケットがどのように使用されて、後置臨床定義をCDMSから前置RDEへ輸送し、更に、データを“使用事例1”および“使用事例2”に従って、このRDEから後置CDMSへ送られるかを記述している。
【０１７６】
（6.3.4  使用事例3: 自動化ペーパーレス食違い管理）
本発明の1つの利点は、食違いが解決される方法である。食違いは多くの異なる状況で発生する。例えば、臨床データが、許されたデータのタイプおよび/又はデータの範囲と合致しない状態でエンターされたときに、この食違いが発生する。本発明の或る具体例において、食違いはデータ確認モジュール1208（図12）により識別される。1具体例に従って、この食違いが発見され、解決されるステップがシステム1300（図1）との関連で図13に説明されている。
【０１７７】
ステップ1302（図13）において、データ確認モジュール1208がO/Cデータベース10中に食違いを検出する。データ確認モジュール1208（図12）は、本発明の或る具体例におけるO/C臨床モジュール12の1成分（コンポーネンツ）である。なお、食違いは、図1にも図12にも示されていない他のモジュールを使用してO/Cデータベース10中に発見できるということを理解されたい。食違いは、臨床設計と合致しないようなデータ・エントリの任意のフォームであってもよい。例えば、食違いは、容認されたデータの範囲を超えるデータ値である。血圧測定の場合、食違いは“10”又は“20”のような全く意味の無い測定である。データ確認モジュール1208は臨床試験におけるあらゆる被験者について収集されたデータにアクセスすることができるから、より複雑な食違いの発見が可能である。例えば、データ確認モジュール1208は、特定の男性被験者又は男性被験者のグループにおいてエストロゲンレベルが調査された如何なる他の弾性被験者よりも高いと判定することある。従って、測定されたエストロゲンレベルが許容範囲であったとしても、データ確認モジュール1208はその分類的に高いエストロゲンレベルを食違いとして知らせることもある。
【０１７８】
ステップ1304を参照すると、サーバー・プロセス・モジュール38は食違いを知ることができる。回答において、サーバー・プロセス・モジュール38はコンフィギュレーション・ファイル40（図1）から食違いが生じている臨床試験Xを検索する。当業者であれば、ステップ1304を種々の異なる方法で行うことができることを理解されるであろう。例えば、或る具体例として、データ確認モジュール1208を常に稼動させ、臨床試験Xについてのデータが既にロードされているようにする。ステップ1306において、食違いが生じている前置サイト104がコンフィギュレーション・ファイル40（図1）を使用して識別される。“使用事例3”の重要な点は、食違い解決が、取締り当局のガイドラインに従って完全に検査されるような方式で行われることである。従って、ステップ1308において、オージット・トレイル112（図1）が更新され、O/Cデータベース10中のデータ確認モジュール1208により発見された食違いを言及する。或る具体例において、ステップ1308は後置CDMS140（図1）についてのオージット・トレイル（図示しない）を、並びに前置RDEシステム104（図1）についてのオージット・トレイル（図示しない）を更新することを含む。本発明の或る具体例において、ステップ1308はオージット・トレイル・モジュール1210（図12）および/又はデータベース・モジュール48との関連で行われる。
本発明の１つの利点は、後置臨床定義に従って格納されたデータを前置サイト104に対し伝達することができることである。更に、前置サイト104で収集されたデータはコンピュータ140のような後置CDMSに対し伝達することができる。後置および前置サイトが非常に異なるデータ・フォーマットを使用するので、変換ステップが用いられる。従って、プロセスステップ1310において、食違いは、食違いと関連する臨床値を格納するのに使用される後置フォーマットから、適当な前置検討定義70と適合するフォームに変換される。この変換ステップ1310は上述の新規な変換マップ32を利用するものである。この変換マップ32には、後置臨床定義8および対応する前置検討定義70（図1）中の適合する第1および第2の成分の記録が含まれる。
【０１７９】
プロセスステップ1312において、食違いは前置サイト104へ送られ、ここで食違いがエンターされる。一般に、ステップ1312は食違いをRDEプロダクツ68へ送ることを含み、このRDEプロダクツ68で、食違いは前置検討定義70との関連で解釈される。なお、この前置検討定義70は食違いが生じた臨床研究に対応するものである。本発明の1具体例において、食違いは、データ確認モジュール1208により発生したメッセージと共にRDEプロダクツ68へ送られる。例えば、データ確認モジュール1208は食違いの性質および何らかの適当な回答を述べることがある。1例として、食違いを生じさせたところの観察された臨床事例は被験者が咳きを有するか否かを尋ねる検索であってもよい。回答において、臨床医は“不明”と答える。その場合、データ確認モジュール1208は食違いを注目し、その食違い（例えば、正しく再記入されなければならないデータ値）と共に、“Yes/No回答を要する”というメッセージを送る。
【０１８０】
プロセスステップ1314において、サーバー・プロセス・モジュール38および/又はデータ交換モジュール42がRDEプロダクツ68からの食違い回答を受理する。プロセスステップ1316において、この食違い回答がオージット・トレイル112に格納され、プロセスステップ1318において、この食違い回答が適当な変換マップ32を用いて適当な後置臨床定義フォーマット8に変換される。ついで、この食違い回答は後置コンピュータ140（図1）へ転送される。なお、上述のステップの多く（ステップ1314および1316を含む）の時間的シーケンスは重要でないことを理解されるべきである。ステップ1320において、データ確認モジュール1208はRDE68から受理された回答が食違いを解決するか否かを判定する。もし、そうであるとすると（図13；1320-Yes）、その食違い回答が食違い解決としてO/Cデータベース10内に格納される。更に、後置食違いが閉じられる。“Yes”又は“No”回答が要求される例において、食違い回答は“Yes”かもしれない。“Yes”回答は検索に対する容認回答であるから、データ確認モジュール1208はその回答を受け入れ、ステップ1324において、先の値（例えば、“不明”）を、値“Yes”で置き換える。回答が食違いを解決するものでない場合（図13；1320-No）は、この失敗がステップ1322においてオージット・トレイル112中に記される。ついで、プロセス制御がステップ1312に戻され、そこで食違いが前置サイト104へ送られ、そこに食違いが更なる解決のためにエンターされる。
【０１８１】
図13に開示したプロセスは、多くの理由から有利である。データ確認モジュール1208が食違いを発見したとき、ファックス、レター又はレポートを送ることよりはむしろ、本発明では新規な変換マップ32を利用し、食違いについて前置サイトを直接、検索する。ついで、変換マップ32を再び利用して、食違い回答の変換が行われ、それがアクセプトされたときは、その回答がCDMS(例えば、後置サイト140)に格納される。更に、図13に開示したプロセスは有利である。なぜならば、システム1300（図1）に見られる電子的オージット・メジャー（audit measures）が手動による入力を要することなく自動的に使用できるからである。図13に開示したプロセスの更なる利点は、それをペーパーレス方式で行うことができることである。従って、図13のプロセスは食違いを完全に自動化し、検査された様式で解決することができ、手動による入力に殆ど依存することはない。
【０１８２】
パケットを食違いの解決のために使用すること：  本発明の1具体例において、“使用事例3”が図14に示すデータ構造を有するパケットの使用により容易になる。この具体例が図17に示されている。図17に示すステップは図13に示す具体例を実行するのに使用することができる。ステップ1702でO/C臨床モジュール12により、食違いがO/Cデータベース10中に発見され、その食違いがパケット化（フォーマット）されO/C食違いパケットとなり、これは図14に示すデータ構造を有する。ステップ1704でO/C食違いパケットをコンピュータ150に転送される。ステップ1706でマッパー・サーバー・モジュール30（図1）が、データ交換モジュール42との関連で稼動し、O/C食違いパケットを前置TM食違いパケットに変換する。この前置TM食違いパケットは図14に示すデータ構造を有する。ステップ1708でTM食違いパケットがサイト104のRDEプロダクツ68へ転送される。ステップ1710で調査者がこの食違いを修正する。その後、この解決された食違いを、図16に示したステップとは逆の方法で、O/Cデータベースに戻すことができる。その他、この解決された食違いを、図16に示したプロセスステップを用いて、O/Cデータベース10に転送することもできる。
【０１８３】
（7.  その他の具体例）
患者の登録：  RDEプロダクツ68により許容される場合および現場での患者の招集が可能な研究において、本発明の1具体例として、前置検討定義70を、手動でエンターされた患者、研究者およびサイトコードに依存するのを避けるように構成することができる。患者コードの自動的割当てが不可能な研究の場合、本発明の1具体例ではO/C臨床モジュール12を使用して被験者についてのデータをロードする前に、識別コード回答（誘起又は手動でエンターされた）が要求される。識別コード回答が無い場合又は不適当な場合（例えば、指定されたサイトおよび研究者について間違った患者コード）、本発明の1具体例では、そのコードが修正されるまで、患者のデータをロードしない。しかし、そのサイトの他の患者のデータのローディングは継続される。もし、O/Cデータベース10患者コードが既に前置検討定義70の被験者と関連しているときは、本発明の1具体例では、その同じサイト104での異なる患者のための割当てとして、この患者コードを拒否することになる。
【０１８４】
互換性：  本発明の或る具体例では、Oracle Clinicalバージョン4.0およびMACROバージョン3を用いて操作される。本発明の或る具体例では、Oracle Clinicalバージョン4.0およびMACROバージョン2装置を用いて操作される。本発明の或る具体例では、Oracle Clinicalバージョン3.1.1.1およびMACROバージョン3を用いて操作される。本発明の或る具体例では、Oracle Clinicalバージョン3.1.1.1およびMACROバージョン2装置を用いて操作される。本発明の或る具体例では、MACRO v2.2を用いて操作される。
【０１８５】
アクティビティおよびエラー・ログ：  本発明の或る具体例では、アクティビティおよびエラー・ログが異なるレベルの細分性（granularity）で含まれる。このようなエラー・ログにより記録されるイベント（events）には、例えばユーザー・アクション、例えばメタデータ・マッピング、リコンフィギュレーション、スタディ・オージットおよび個々のサイト又はスタディのための活動の管理上の休止および再スタートなどが含まれる。或る具体例において、このようなログはデータ翻訳およびデータ・ロードステップの成功的および不成功的実行を記録する。
【０１８６】
セキュリティ：  本発明の或る具体例においては、全ての遠隔ユーザー（例えば、コンソール・モジュール44のユーザー、マッパー・サーバー・モジュール30のユーザー、サーバー・プロセス・モジュール38のユーザー）は、外部コーポレートユーザーデレクトリー（例えば、ライトウエイト・デレクトリー・アクセスプロトコルを介して）に対しアクセスすることができる。更に、本発明の或る具体例においては、システム・アドミニストレータはデータベース・アカウント・パスワードを格納したり、或いはシステム1300が開始されたときいつでも、ユーザーが手動でそれらをエンターすることを要求することができる。
【０１８７】
HadValue:   本発明の或る具体例は、MACROバージョン2.2を用いて操作される。特に、或る具体例では、スキップ・コンデションを有する値の削除が発生したことを検出するため、MACRO 2.2 HadValueフィールドを使用する。このような場合、このような削除（例えば、削除された薬物療法の開始および終了日）がRDE68からO/Cデータベース10へ転送される。
【０１８８】
リピーテリング・グループ（Repeating Groups）:   本発明の或る具体例では、後置臨床定義8デザイナーがリピーテリング・グループを更新して、新たな、より高いリピートの最大数を得るようにすることができる。
【０１８９】
スタディ・オージット（study audits）：  或る具体例において、後置臨床定義8中のデータ収集インストルメント・ブックページ（表3）のいずれにもない強制的質問は無視される。すなわち、その様な質問は、本発明のコンベンション・アルゴリズムを用いて作られた対応する前置検討定義72には設けられない。
【０１９０】
（8.  引用された参照文献）
本明細書に引用された全ての文献は、その全体が全ての目的において、示唆の有無に関係なく、本明細書の一部として組み込まれるものとする。
【０１９１】
（9.  その他の具体例）
本発明は、コンピュータ読み取り可能な格納媒体中に埋め込まれたコンピュータ・プログラム機構を有するコンピュータ・プログラム・プロダクツとして履行することができる。例えば、このコンピュータ・プログラム・プロダクツは図1，2および関連した図に記載したプログラムモジュールを含むことができる。これらのプログラムモジュールは、CD-ROM、磁気記憶プロダクツ、その他のコンピュータ読み取り可能なデータ又はプログラム記憶プロダクツに格納することができる。このコンピュータ・プログラム・プロダクツ内のソフトウエア・モジュールは、インターネット又はその他を介して、キャリア波上のコンピュータデータ信号（ソフトウエア・モジュールが埋め込まれている）の伝達により電子的に分配することも可能である。
【０１９２】
或る例示的具体例を添付図面を参照して詳述したが、これら具体例は単に説明のためのものであり、本発明を限定することを意図したものではないことを理解されるべきである。更に、本発明は上記の特定の配置および構成に制限されるものではなく、当業者に自明の種々の変更が可能である。
【図面の簡単な説明】
【０１９３】
【図１】本発明が履行される例示的コンピュータシステムネットワークを説明する模式図。
【図２】本発明の1具体例に従うところの、システムの成分の展開を示す模式図。
【図３】本発明の1具体例に従うところの、オラクル・臨床定義を選択するのに使用されるスタディ・チューザー・ダイログを説明する図。
【図４】本発明の1具体例に従うところの、オラクル・臨床定義をマクロ・スタディ定義と比較するのに使用されたスタディ・定義パネルを説明する図。
【図５】マクロ・スタディ定義電子的ケース・レポートフォームの電子的様相を編集するのに使用されるコンフィギャレーション・タブ・パネルを説明する図。
【図６】本発明の1具体例に従うところの、プロセスステップを示すブロック図。
【図７】図7A、7Bおよび7Cは、本発明の1具体例に従うところの、変換マップの例示的OcCpEvent、OcDciおよびOcDciModセグメントを夫々示す図。
【図８】図8A、8Bおよび8Cは、本発明の1具体例に従うところの、変換マップの例示的OcQuestion、TmDerivendItemおよびOcSiteセグメントを夫々示す図。
【図９】図9A、9Bおよび9Cは、本発明の1具体例に従うところの、変換マップの例示的OcInvestigator、OcPatientおよびOcKeyセグメントを夫々示す図。
【図１０】本発明の1具体例に従うところの、変換マップの例示的スペシャル・バリュー（Special Values）セグメントを夫々示す図。
【図１１】本発明の1具体例に従うところの、前置臨床サイトから臨床データを得るためのプロセスステップを示すブロック図。
【図１２】本発明の1具体例に従うところの、O/C臨床モジュールに見られるソフトウエア・モジュールを示す図。
【図１３】本発明の1具体例に従うところの、後置臨床データ管理システムで生じる食違いを解決するためのプロセスステップを説明するブロック図。
【図１４】本発明の1具体例に従うところの、後置および前置独立データ構造にフォーマットされたパケットを示す図。
【図１５】本発明の1具体例に従うところの、後置臨床定義を前置検討定義に変換するためのプロセスステップを説明するブロック図。
【図１６】本発明の1具体例に従うところの、前置臨床サイトからの臨床データを後置臨床データ管理システムへ転送するためのプロセスステップを説明するブロック図。
【図１７】本発明の1具体例に従うところの、後置臨床データ管理システムにおける食違いを解決するためにデータ・パケット構造を使用する方法を説明するブロック図。
【図１】
2004530223.tif 000022
【図２】
2004530223.tif 000023
【図３】
2004530223.tif 000024
【図４】
2004530223.tif 000025
【図５】
2004530223.tif 000026
【図６】
2004530223.tif 000027
【図７】
2004530223.tif 000028
【図８】
2004530223.tif 000029
【図９】
2004530223.tif 000030
【図１０】
2004530223.tif 000031
【図１１】
2004530223.tif 000032
【図１２】
2004530223.tif 000033
【図１３】
2004530223.tif 000034
【図１４】
2004530223.tif 000035
【図１５】
2004530223.tif 000036
【図１６】
2004530223.tif 000037
【図１７】
2004530223.tif 000038
【国際公開パンフレット】
2004530223.tif 000039
2004530223.tif 000040
2004530223.tif 000041
2004530223.tif 000042
2004530223.tif 000043
2004530223.tif 000044
2004530223.tif 000045
2004530223.tif 000046
2004530223.tif 000047
2004530223.tif 000048
2004530223.tif 000049
2004530223.tif 000050
2004530223.tif 000051
2004530223.tif 000052
2004530223.tif 000053
2004530223.tif 000054
2004530223.tif 000055
2004530223.tif 000056
2004530223.tif 000057
2004530223.tif 000058
2004530223.tif 000059
2004530223.tif 000060
2004530223.tif 000061
2004530223.tif 000062
2004530223.tif 000063
2004530223.tif 000064
2004530223.tif 000065
2004530223.tif 000066
2004530223.tif 000067
2004530223.tif 000068
2004530223.tif 000069
2004530223.tif 000070
2004530223.tif 000071
2004530223.tif 000072
2004530223.tif 000073
2004530223.tif 000074
2004530223.tif 000075
2004530223.tif 000076
2004530223.tif 000077
2004530223.tif 000078
2004530223.tif 000079
2004530223.tif 000080
2004530223.tif 000081
2004530223.tif 000082
2004530223.tif 000083
2004530223.tif 000084
2004530223.tif 000085
2004530223.tif 000086
2004530223.tif 000087
2004530223.tif 000088
2004530223.tif 000089
2004530223.tif 000090
2004530223.tif 000091
2004530223.tif 000092
2004530223.tif 000093
2004530223.tif 000094
2004530223.tif 000095
2004530223.tif 000096
2004530223.tif 000097
2004530223.tif 000098
2004530223.tif 000099
2004530223.tif 000100
2004530223.tif 000101
2004530223.tif 000102
2004530223.tif 000103
2004530223.tif 000104
2004530223.tif 000105
2004530223.tif 000106
2004530223.tif 000107
2004530223.tif 000108
2004530223.tif 000109
2004530223.tif 000110
2004530223.tif 000111
2004530223.tif 000112
2004530223.tif 000113
2004530223.tif 000114
2004530223.tif 000115
2004530223.tif 000116
2004530223.tif 000117
2004530223.tif 000118
2004530223.tif 000119
2004530223.tif 000120
2004530223.tif 000121
2004530223.tif 000122
2004530223.tif 000123
2004530223.tif 000124
2004530223.tif 000125
2004530223.tif 000126
2004530223.tif 000127
2004530223.tif 000128
2004530223.tif 000129
2004530223.tif 000130
2004530223.tif 000131
2004530223.tif 000132
【国際公開パンフレット（コレクトバージョン）】
2004530223.tif 000133
【手続補正書】
【提出日】平成15年6月27日(2003.6.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
後置臨床定義に基づいて前置検討定義を確定するための方法であって：
該後置臨床定義における第1の成分のセットを該前置検討定義における第2の成分のセットと適合させるため変換マップを作成するステップと；
該後置臨床定義におけるこの第1の成分のセット中の第1の成分をそれぞれ解析するステップと；
を具備してなり、該第1の成分のセット中の第1の成分のそれぞれについて、該解析ステップが：
(i) 該第1の成分に対応する変換マップに識別名を加えるステップと；
(ii) 第1の成分に対応する第2の成分を含むように前置検討定義を編集するステップと；
(iii) 該第1の成分に対応する前置検討定義中の第2の成分のアイデンティティを含むように変換マップを修正するステップと；
を含み、ここで、該解析ステップが完了したとき、上記変換マップは、該後置臨床定義および該対応する前置検討定義中の適合する第1および第2成分の記録を含むことを特徴とする方法。
【請求項２】
該後置検討定義が、オラクル(Oracle)臨床定義である請求項１記載の方法。
【請求項３】
該前置検討定義がマクロ検討定義である請求項１記載の方法。
【請求項４】
クライアント/サーバーシステムが特定の様式で機能するようにするために使用されるコンピュータ読み取り可能なメモリーであって：
後置臨床定義に従ってデータを保存することができる後置臨床データ管理システム（CDMS）と；
前置検討定義に従って臨床データを収集するための遠隔データ・エントリ・モジュールと；
該後置臨床定義を対応する前置検討定義に変換するためのマッパー(mapper)サーバー・モジュールであって、コンピュータ読み取り可能なメモリーに記憶されている実行可能な命令を含み；該実行可能な命令が：
該後置臨床定義中の第1の成分のセットを、対応する前置検討定義中の第2の成分のセットと適合させる変換マップを作成するための命令と；
該後置臨床定義中の第1の成分のセット内の各第1の成分を解析するための命令とを含み；ここで、該第1の成分のセット中の第1の成分の夫々について、この解析のための命令には；
(i) 該第1の成分に対応する変換マップに識別名を加えるための命令；
(ii) 第1の成分に対応する第2の成分を含むように対応する前置検討定義を編集するための命令；
(iii) 該第1の成分に対応する前置検討定義中の第2の成分のアイデンティティを含むように変換マップを修正するための命令が含まれ；
この解析のための命令が完了したとき、上記変換マップは、後置臨床定義および対応する前置検討定義中の適合する第1および第2成分の記録を含むことを特徴とするコンピュータ読み取り可能なメモリー。
【請求項５】
該後置検討定義が、オラクル(Oracle)臨床定義である請求項４記載のコンピュータ読み取り可能なメモリー。
【請求項６】
該前置検討定義がマクロ検討定義である請求項４記載のコンピュータ読み取り可能なメモリー。
【請求項７】
プロセッサーを有するコンピュータとの関連で使用されるコンピュータ・プログラム・プロダクツであって；
該コンピュータ・プログラム・プロダクツが、コンピュータ読み取り可能な記憶媒体と、その中に埋め込まれたコンピュータ・プログラム機構とを具備してなり、該コンピュータ・プログラム機構が後置臨床定義に基づいて前置検討定義を確定するためのものであり、かつ、上記プロセッサーを介して以下のステップを実行させるものであることを特徴とするコンピュータ・プログラム・プロダクツ：
該後置臨床定義における第1の成分のセットを該前置検討定義における第2の成分のセットと適合させるため変換マップを作成するステップと；
該後置臨床定義におけるこの第1の成分のセット中の第1の成分をそれぞれ解析するステップと；
からなり、該第1の成分のセット中の第1の成分のそれぞれについて、該解析ステップが：
(i) 該第1の成分に対応する変換マップに識別名を加えるステップと；
(ii) 第1の成分に対応する第2の成分を含むように前置検討定義を編集するステップと；
(iii) 該第1の成分に対応する前置検討定義中の第2の成分のアイデンティティを含むように変換マップを修正するステップと；
を含み、ここで、該解析ステップが完了したとき、上記変換マップは、該後置臨床定義および該対応する前置検討定義中の適合する第1および第2成分の記録を含むことを特徴とするもの。
【請求項８】
該後置検討定義が、オラクル(Oracle)臨床定義である請求項７記載のコンピュータ・プログラム・プロダクツ。
【請求項９】
該前置検討定義がマクロ検討定義である請求項７記載のコンピュータ・プログラム・プロダクツ。
【請求項１０】
後置臨床定義に従って後置CDMS中の臨床データを記憶するための方法であって：
前置検討定義に従って複数の患者の臨床データを収集する遠隔データ・エントリ・モジュールから前置データ・パケットを得るステップと；
前置データ・パケットを解析するステップであって、ここで、該複数の患者の中の各患者について、該解析ステップが、患者についての前置検討定義前置検討定義/後置臨床定義適合データを、後置臨床定義における第1の成分のセットを前置検討定義における第２の成分のセットと適合させる変換マップに加入するステップを含み；
変換マップを使用して、後置データ・パケットを構築するステップと；
該後置データ・パケットを該後置データベースにアップロードし、それにより該後置臨床定義に従って該後置データベース内に該臨床データを記憶するステップと；
を具備してなる方法。
【請求項１１】
該解析ステップが更に、患者について設定された臨床識別名を照合するステップを含み、ここで、臨床識別名が患者について設定されていない場合は、該患者に関連する該パケット中のデータが拒否されることを特徴とする請求項１０記載の方法。
【請求項１２】
該後置検討定義が、オラクル(Oracle)臨床定義である請求項１０記載の方法。
【請求項１３】
該前置検討定義がマクロ検討定義である請求項１０記載の方法。
【請求項１４】
クライアント/サーバーシステムを特定の様式で機能させるようにして使用されるコンピュータ読み取り可能なメモリーであって：
後置臨床定義に従ってデータを保存することができる後置CDMSと；
前置検討定義に従って臨床データを収集するための遠隔データ・エントリ・モジュールと；
該遠隔データ・エントリ・モジュールにより収集された臨床データを該後置CDMS内に格納することができるフォームに変換させるためのサーバー・プロセス・モジュールと；
を具備してなり、ここで、該サーバー・プロセス・モジュールがコンピュータ読み取り可能なメモリーに記憶されている実行可能な命令を含み、該実行可能な命令が；
前置検討定義に従って該複数の患者の臨床データを収集する遠隔データ・エントリ・モジュールから前置データ・パケットを得るための命令と；
該前置データ・パケットを解析するための命令であって、該複数の患者の中の各患者について、該解析命令が、患者についての前置検討定義前置検討定義/後置臨床定義適合データを、後置臨床定義における第1の成分のセットを前置検討定義における第２の成分のセットと適合させる変換マップに加入することを含むものと；
変換マップを使用して、後置データ・パケットを構築するための命令と；
該後置データ・パケットを該後置CDMSにアップロードするための命令と；
を含むことを特徴とするもの。
【請求項１５】
該命令が更に、患者について設定された臨床識別名を照合する命令を含み、ここで、臨床識別名が患者について設定されていない場合は、該解析命令が該患者に関連する該パケット中のデータを拒否するための命令を含む請求項１４記載のコンピュータ読み取り可能なメモリー。
【請求項１６】
該後置検討定義が、オラクル(Oracle)臨床定義である請求項１４記載のコンピュータ読み取り可能なメモリー。
【請求項１７】
該前置検討定義がマクロ検討定義である請求項１４記載のコンピュータ読み取り可能なメモリー。
【請求項１８】
プロセッサーを有するコンピュータとの関連で使用されるコンピュータ・プログラム・プロダクツであって；
該コンピュータ・プログラム・プロダクツが、コンピュータ読み取り可能な記憶媒体と、その中に埋め込まれたコンピュータ・プログラム機構とを具備してなり、該コンピュータ・プログラム機構が後置臨床定義に従って後置CDMS中の臨床データを格納するためのものであり、かつ、上記プロセッサーを介して以下のステップを実行させるものであることを特徴とするコンピュータ・プログラム・プロダクツ：
前置検討定義に従って複数の患者の臨床データを収集する遠隔データ・エントリ・モジュールから前置データ・パケットを得るステップ；
前置データ・パケットを解析するステップであって、ここで、該複数の患者の中の各患者について、該解析ステップが、患者についての前置検討定義前置検討定義/後置臨床定義適合データを、後置臨床定義における第1の成分のセットを前置検討定義における第２の成分のセットと適合させる変換マップに加入するステップを含み；
変換マップを使用して、後置データ・パケットを構築するステップ；および
該後置臨床定義に従って、該後置データ・パケットを該後置データベースにアップロードするステップ。
【請求項１９】
該解析ステップが更に、患者について設定された臨床識別名を照合するステップを含み、ここで、臨床識別名が患者について設定されていない場合は、該患者に関連する該パケット中のデータが拒否されることを特徴とする請求項１８記載のコンピュータ・プログラム・プロダクツ。
【請求項２０】
該後置検討定義が、オラクル(Oracle)臨床定義である請求項１８記載のコンピュータ・プログラム・プロダクツ。
【請求項２１】
該前置検討定義がマクロ検討定義である請求項１８記載のコンピュータ・プログラム・プロダクツ。
【請求項２２】
臨床データ管理システム(CDMS)で生じる食い違いを解決するための方法であって：
食違いに対応する臨床値を記憶するのに使用される後置臨床定義フォーマットからの食違いを、複数の患者のデータを適合させる前置検討定義フォーマット/後置臨床定義フォーマットを含み、該後置臨床定義フォーマットにおける第1の成分のセットを該前置検討定義フォーマットにおける第2の成分のセットと適合させる変換マップを使用して、前置検討定義フォーマットに変換するステップと；
該前置検討定義フォーマット中の食違いをこの食違いに関連する臨床値が記入された前置サイトに転送するステップと；
該前置サイトからの食違い応答を受理するステップと；
該食違い応答が食違いを解決する場合は、該食違い応答を格納するステップと；
を具備してなる方法。
【請求項２３】
該食違い応答が該食違いを以下のステップにより解決するか否かを判定するステップを更に含む請求項２２記載の方法：
(i) 該前置検討定義フォーマットからの食違い応答を該後置臨床定義フォーマットに変換するステップ；および
(ii) 該食違い応答が該臨床値と関連するデータ・エントリ基準を満足することを照合するステップ。
【請求項２４】
該データ・エントリ基準がデータタイプ又はデータレンジ（range）である請求項２３記載の方法。
【請求項２５】
該食違い応答が該食違いを解決しない場合、該転送、受理および格納ステップを更に繰り返すことを含む請求項２２記載の方法。
【請求項２６】
該食違いを考慮してオージット・トレイルを更新するステップを更に含む請求項２２記載の方法。
【請求項２７】
オージット・トレイル内に該食違い応答を格納するステップを更に含む請求項２２記載の方法。
【請求項２８】
該CDMSが、（1）臨床値を記憶するためのデータベース；（2）統計を使用して臨床値を分析するためのSASモジュール；（3）ケース・レポートフォームに見出せないデータをロードするためのジェネリック・ローダー；（4）不都合な反応術語を調和させるシソーラスをアクセスするためのシソーラス・モジュール；（5）オージット・トレイルをアクセスするためのオージット・トレイル・モジュールを含む請求項２２記載の方法。
【請求項２９】
該変換ステップにおいて変換マップが、後置臨床定義フォーマットにおける各質問およびイベント(event)と、前置検討定義における各質問およびイベントと間の1対1の対応を記憶する請求項２２記載の方法。
【請求項３０】
クライアント/サーバーシステムが特定の様式で機能するようにするために使用されるコンピュータ読み取り可能なメモリーであって：
後置臨床定義に従ってデータを保存することができる後置臨床データ管理システム(CDMS)と；
前置検討定義に従って臨床データを収集するための遠隔データ・エントリ・モジュールと；
該後置CDMS中に生じる食違いを解決するためのマッパー(mapper)サーバー・モジュールであって、コンピュータ読み取り可能なメモリーに記憶されている実行可能な命令を含み；該実行可能な命令が：
該食違いに対応する臨床値を格納するのに使用される該後置臨床定義フォーマットからの該食違いを、複数の患者のデータを適合させる前置検討定義フォーマット/後置臨床定義フォーマットを含み、該後置臨床定義フォーマットにおける第1の成分のセットを該前置検討定義フォーマットにおける第2の成分のセットと適合させる変換マップを使用して、該前置検討定義フォーマットに変換させるための命令と；
該前置検討定義フォーマットにおける該食違いを、該食違いと関連する臨床値が記入された前置サイトに転送させるための命令と；
該前置サイトからの食違い応答を受理するための命令と；
該食違い応答が該食違いを解決する場合に、該食違い応答を該後置CDMSに格納するための命令と；
を含むことを特徴とするコンピュータ読み取り可能なメモリー。
【請求項３１】
該マッパー・サーバー・モジュールが、食違い応答が当該食違いを以下のステップにより解決するか否かを判定する命令を更に含む請求項３０記載のコンピュータ読み取り可能なメモリー：
(i) 該前置検討定義フォーマットからの食違い応答を該後置臨床定義フォーマットに変換するステップ；および
(ii) 該食違い応答が該臨床値と関連するデータ・エントリ基準を満足することを照合するステップ。
【請求項３２】
該データ・エントリ基準がデータタイプ又はデータレンジ（range）である請求項３１記載のコンピュータ読み取り可能なメモリー。
【請求項３３】
該食違い応答が該食違いを解決しない場合、該マッパー・サーバー・モジュールが該転送、受理および格納についての命令を更に繰り返す命令を含む請求項３０記載のコンピュータ読み取り可能なメモリー。
【請求項３４】
該マッパー・サーバー・モジュールが該食違いを考慮してオージット・トレイルを更新するための命令を更に含む請求項３０記載のコンピュータ読み取り可能なメモリー。
【請求項３５】
該メモリーが、該食違いを考慮してオージット・トレイルを更新するための命令の実行に応答して、該オージット・トレイルを更新するための命令を含むデータベース・モジュールを更に含む請求項３０記載のコンピュータ読み取り可能なメモリー。
【請求項３６】
該マッパー・サーバー・モジュールが該食違い応答を用いてオージット・トレイルを更新するための命令を更に含む請求項３０記載のコンピュータ読み取り可能なメモリー。
【請求項３７】
該メモリーが、該食違い応答を用いてオージット・トレイルを更新するための命令の実行に応答して、該オージット・トレイルを更新するための命令を含むデータベース・モジュールを更に含む請求項３６記載のコンピュータ読み取り可能なメモリー。
【請求項３８】
該後置CDMSが、（1）臨床値を記憶するためのデータベース；（2）統計を使用して臨床値を分析するためのSASモジュール；（3）ケース・レポートフォームに見出せないデータをロードするためのジェネリック・ローダー；（4）不都合な反応術語を調和させるシソーラスをアクセスするためのシソーラス・モジュール；（5）オージット・トレイルをアクセスするためのオージット・トレイル・モジュールを含む請求項３０記載のコンピュータ読み取り可能なメモリー。
【請求項３９】
該変換が変換マップが、後置臨床定義における各質問およびイベント(event)と、前置検討定義における各質問およびイベントと間の1対1の対応を記憶する請求項３０記載のコンピュータ読み取り可能なメモリー。
【請求項４０】
プロセッサーを有するコンピュータとの関連で使用されるコンピュータ・プログラム・プロダクツであって；
該コンピュータ・プログラム・プロダクツが、コンピュータ読み取り可能な記憶媒体と、その中に埋め込まれたコンピュータ・プログラム機構とを具備してなり、該コンピュータ・プログラム機構が臨床データ管理システム(CDMS)中に生じる食違いを解決するためのものであり、かつ、上記プロセッサーを介して以下のステップを実行させるものであることを特徴とするコンピュータ・プログラム・プロダクツ：
食違いに対応する臨床値を記憶するのに使用される後置臨床定義フォーマットからの食違いを、複数の患者のデータを適合させる前置検討定義フォーマット/後置臨床定義フォーマットを含み、該後置臨床定義フォーマットにおける第1の成分のセットを該前置検討定義フォーマットにおける第2の成分のセットと適合させる変換マップを使用して、前置検討定義に適合する前置検討定義フォーマットに変換するステップ；
該前置検討定義フォーマット中の食違いをこの食違いに関連する臨床値が記入された前置サイトに転送するステップ；
該前置サイトからの食違い応答を受理するステップ；および
該食違い応答が食違いを解決する場合は、該食違い応答を格納するステップ。
【請求項４１】
該コンピュータ・プログラム機構が、該食違い応答が該食違いを以下のステップにより解決するか否かを判定するものである請求項４０記載のコンピュータ・プログラム・プロダクツ：
(i) 該前置検討定義フォーマットからの食違い応答を該後置臨床定義フォーマットに変換するステップ；および
(ii) 該食違い応答が該臨床値と関連するデータ・エントリ基準を満足することを照合するステップ。
【請求項４２】
該データ・エントリ基準がデータタイプ又はデータレンジ（range）である請求項４１記載のコンピュータ・プログラム・プロダクツ。
【請求項４３】
該食違い応答が該食違いを解決しない場合、該転送、受理および格納が繰り返される請求項４０記載のコンピュータ・プログラム・プロダクツ。
【請求項４４】
該コンピュータ・プログラム機構が更に、該プロセッサーを介して、該食違いを考慮してオージット・トレイルを更新させるステップを実行させるものである請求項４０記載のコンピュータ・プログラム・プロダクツ。
【請求項４５】
該コンピュータ・プログラム機構が更に、該プロセッサーを介して、該食違い応答をオージット・トレイル内に格納するステップを実行させるものである請求項４０記載のコンピュータ・プログラム・プロダクツ。
【請求項４６】
該後置CDMSが、（1）臨床値を記憶するためのデータベース；（2）統計を使用して臨床値を分析するためのSASモジュール；（3）ケース・レポートフォームに見出せないデータをロードするためのジェネリック・ローダー；（4）不都合な反応術語を調和させるシソーラスをアクセスするためのシソーラス・モジュール；（5）オージット・トレイルをアクセスするためのオージット・トレイル・モジュールを含む請求項４０記載のコンピュータ・プログラム・プロダクツ。
【請求項４７】
該変換が、後置臨床定義フォーマットにおける各質問およびイベント(event)と、前置検討定義における各質問およびイベントと間の1対1の対応を記憶する請求項４０記載のコンピュータ・プログラム・プロダクツ。
【請求項４８】
後置臨床定義を前置検討定義に変換する方法であって：
該後置臨床定義を後置データ・パケットにフォーマットするステップであって、ここで、該後置データ・パケットが第1のパケット・ヘッダーと、第1の複数のデータ・セグメントとを含むものと；
該第1のデータ・パケットを受理するステップと；
該第1のデータ・パケットを前置データ・パケットに変換するステップであって、ここで、該前置データ・パケットが第２のパケット・ヘッダーと、第2の複数のデータ・セグメントとを含むものと；
該前置データ・パケットを移送させ、それにより該後置臨床定義を該前置検討定義に変換させるステップと；
を具備してなる方法。
【請求項４９】
該変換ステップが更に、該前置検討定義に従ってフォーマットされた臨床データを該後置臨床定義に従ってフォーマットされた臨床データに変換させる変換マップを構築するステップを含む請求項４８記載の方法。
【請求項５０】
臨床データを格納する方法であって：
該臨床データを前置データ・パケットにフォーマットするステップであって、ここで、該前置データ・パケットが第1のパケット・ヘッダーと、第1の複数のデータ・セグメントとを含むものと；
該第1のデータ・パケットを受理するステップと；
該第1のデータ・パケットを後置データ・パケットに変換するステップであって、ここで、該後置データ・パケットが第2のパケット・ヘッダーと、第2の複数のデータ・セグメントとを含むものと；
該後置データ・パケットを移送させ、それにより該臨床データを格納するステップと；
を具備してなる方法。
【請求項５１】
後置臨床定義における各成分を、対応する前置検討定義中の対応する成分と適合させるキー(key)を有する変換マップ。
【請求項５２】
各成分が、ビジット(visit)、フォーム又は質問のリストを含む請求項５１記載の方法。
【国際調査報告】
2004530223.tif 000134