JP2023053815A - 治験管理システム、治験管理装置、治験管理方法および治験管理プログラム - Google Patents

Abstract

【課題】複数の被験者における治験の進捗状態を効率的に管理すること。【解決手段】治験プロトコールを解析し、複数の被験者への治験期間中の投薬および検査のタイムテーブルを生成する治験プロトコール解析部と、複数の被験者の被験者識別子を取得する被験者識別子取得部と、複数の被験者それぞれに割り当てられた被験者端末に対して、タイムテーブルに従って投薬タイミングまたは検査タイミングの報知を指示し、被験者端末から被験者識別子に対応付けた当該投薬または当該検査の完了通知を取得して確認する投薬および検査確認部と、被験者の投薬および検査データを取得し、被験者識別子に紐付けて被験者への投薬履歴および被験者の検査履歴を格納する治験履歴格納部と、を備える治験管理装置。【選択図】 図１

Description

本発明は、治験管理システム、治験管理装置、治験管理方法および治験管理プログラムに関する。

上記技術分野において、特許文献１には、治験の被験者に対する検査実施予定時より所定期間前の検査完了情報が記憶されてない場合に、治験の進捗警報情報を出力する技術が開示されている。

特開２００３－２０３１２２号公報

しかしながら、上記文献に記載の技術では、複数の被験者における治験の進捗状態を効率的に管理することができなかった。適格性判定基準に合致するか否かによる被験者の選択であるため、治験に適した被験者を効率的に選択することができなかった。

本発明の目的は、上述の課題を解決する技術を提供することにある。

上記目的を達成するため、本発明に係る治験管理装置は、
治験プロトコールを解析し、複数の被験者への治験期間中の投薬および検査のタイムテーブルを生成する治験プロトコール解析部と、
前記複数の被験者の被験者識別子を取得する被験者識別子取得部と、
前記複数の被験者それぞれに割り当てられた被験者端末に対して、前記タイムテーブルに従って投薬タイミングまたは検査タイミングの報知を指示し、前記被験者端末から被験者識別子に対応付けた当該投薬または当該検査の完了通知を取得して確認する投薬および検査確認部と、
前記複数の被験者の投薬および検査データを取得し、前記被験者識別子それぞれに紐付けて投薬履歴および検査履歴を格納する治験履歴格納部と、
を備える。

上記目的を達成するため、本発明に係る治験管理方法は、
治験プロトコールを解析し、複数の被験者への治験期間中の投薬および検査のタイムテーブルを生成する治験プロトコール解析ステップと、
前記複数の被験者の被験者識別子を取得する被験者識別子取得ステップと、
前記複数の被験者それぞれに割り当てられた被験者端末に対して、前記タイムテーブルに従って投薬タイミングまたは検査タイミングの報知を指示し、前記被験者端末から被験者識別子に対応付けた当該投薬または当該検査の完了通知を取得して確認する投薬および検査確認ステップと、
前記複数の被験者の投薬および検査データを取得し、前記被験者識別子それぞれに紐付けて投薬履歴および検査履歴を格納する治験履歴格納ステップと、
を含む。

上記目的を達成するため、本発明に係る治験管理プログラムは、
治験プロトコールを解析し、複数の被験者への治験期間中の投薬および検査のタイムテーブルを生成する治験プロトコール解析ステップと、
前記複数の被験者の被験者識別子を取得する被験者識別子取得ステップと、
前記複数の被験者それぞれに割り当てられた被験者端末に対して、前記タイムテーブルに従って投薬タイミングまたは検査タイミングの報知を指示し、前記被験者端末から被験者識別子に対応付けた当該投薬または当該検査の完了通知を取得して確認する投薬および検査確認ステップと、
前記複数の被験者の投薬および検査データを取得し、前記被験者識別子それぞれに紐付けて投薬履歴および検査履歴を格納する治験履歴格納ステップと、
をコンピュータに実行させる。

上記目的を達成するため、本発明に係る治験管理システムは、
治験の対象である複数の被験者それぞれに割り当てられた複数の被験者端末と、
治験プロトコールに従って、前記複数の被験者端末における前記治験の実施を管理する治験管理装置と、
を備える治験管理システムであって、
前記治験管理装置は、
前記治験プロトコールを解析し、前記複数の被験者への治験期間中の投薬および検査のタイムテーブルを生成する治験プロトコール解析部と、
前記複数の被験者の被験者識別子を取得する被験者識別子取得部と、
前記複数の被験者端末に対して、前記タイムテーブルに従って投薬タイミングまたは検査タイミングの報知を指示し、前記複数の被験者端末から被験者識別子に対応付けた当該投薬または当該検査の完了通知を取得して確認する投薬および検査確認部と、
前記複数の被験者の投薬および検査データを取得し、前記被験者識別子それぞれに紐付けて投薬履歴および検査履歴を格納する治験履歴格納部と、
を有する。

本発明によれば、複数の被験者における治験の進捗状態を効率的に管理することができる。

第１実施形態に係る治験管理装置の構成を示すブロック図である。 第２実施形態に係る治験管理装置を含む治験管理システムの構成を示す図である。 第２実施形態に係る治験管理装置を含む治験管理システムの動作概要を示す図である。 第２実施形態に係る治験管理装置を含む治験管理システムにおける動作手順を示すシーケンス図である。 図３ＡのＳ３０５の動作手順を詳細に示すシーケンス図である。 第２実施形態に係る治験管理装置を含む治験管理システムにおけるＣＲＣ端末の表示画面を示す図である。 第２実施形態に係る治験管理システムにおけるＣＲＣ端末の表示画面を示す図である。 第２実施形態に係る治験管理システムにおけるＣＲＣ端末の表示画面を示す図である。 第２実施形態に係る治験管理システムにおける被験者端末の表示画面を示す図である。 第２実施形態に係る治験管理システムにおける被験者端末の表示画面を示す図である。 第２実施形態に係る治験管理システムにおける被験者端末の表示画面を示す図である。 第２実施形態に係る治験管理システムにおける被験者端末の表示画面を示す図である。 第２実施形態に係る治験管理装置の機能構成の詳細を示すブロック図である。 第２実施形態に係る治験者情報格納部の構成を示す図である。 第２実施形態に係る治験計画情報格納部の一部の構成を示す図である。 第２実施形態に係る治験プロトコールの構成を示す図である。 第２実施形態に係る治験計画情報格納部の他の構成を示す図である。 第２実施形態に係る治験履歴格納部の構成を示す図である。 第２実施形態に係る投薬／検査チェックテーブルの構成を示す図である。 第２実施形態に係る治験管理装置の処理手順を示すフローチャートである。 第２実施形態に係る治験管理装置の処理手順を示すフローチャートである。 第２実施形態に係る被験者のスクリーニグ処理の手順を示すフローチャートである。 第２実施形態に係る被験者端末の機能構成を示す図である。 第２実施形態に係る被験者端末の処理手順を示すフローチャートである。 第２実施形態に係るＣＲＣ端末を含む機能構成を示す図である。 第２実施形態に係るＣＲＣ端末を含む他の機能構成を示す図である。 第２実施形態に係る使用資材情報の構成を示す図である。 第２実施形態に係るＣＲＣ端末の処理手順を示すフローチャートである。 第２実施形態に係るＣＲＣ端末の処理手順を示すフローチャートである。 第３実施形態に係る治験管理装置を含む治験管理システムの構成を示す図である。 第４実施形態に係る治験管理装置を含む治験管理システムの動作概要を示す図である。 第４実施形態に係る治験管理装置を含む治験管理システムの構成を示す図である。 第４実施形態に係る治験管理装置を含む治験管理システムにおける動作手順を示すシーケンス図である。 第４実施形態に係る医療従業者端末の表示画面を示す図である。 第４実施形態に係る医療従業者端末および管理者端末の表示画面を示す図である。 第４実施形態に係る管理者端末の表示画面を示す図である。 第４実施形態に係る治験依頼者端末の表示画面を示す図である。 第５実施形態に係る治験管理装置を含む治験管理システムにおける動作手順を示すシーケンス図である。 他の実施形態に係る治験管理における課題について示す図である。 他の実施形態に係る治験管理における課題について示す図である。

以下に、図面を参照して、本発明の実施の形態について例示的に詳しく説明する。ただし、以下の実施の形態に記載されている構成要素は単なる例示であり、本発明の技術範囲をそれらのみに限定する趣旨のものではない。

［第１実施形態］
本発明の第１実施形態としての治験管理装置１００について、図１を用いて説明する。治験管理装置１００は、治験プロトコールに従う治験の実施を管理する装置である。

図１に示すように、治験管理装置１００は、治験プロトコール解析部１０１と、被験者識別子取得部１０２と、投薬および検査確認部１０３と、治験履歴格納部１０４と、を含む。治験プロトコール解析部１０１は、治験プロトコールを解析し、複数の被験者１１１への治験期間中の投薬および検査のタイムテーブルを生成する。被験者識別子取得部１０２は、複数の被験者１１１の被験者識別子を取得する。投薬および検査確認部１０３は、複数の被験者１１１それぞれに割り当てられた被験者端末１１０に対して、タイムテーブルに従って投薬タイミングまたは検査タイミングの報知を指示し、被験者端末１１０から被験者識別子に対応付けた当該投薬または当該検査の完了通知を取得して確認する。治験履歴格納部１０４は、複数の被験者１１０の投薬および検査データを取得し、被験者識別子１４１それぞれに紐付けて投薬履歴１４２および被検査履歴１４３を格納する。

本実施形態によれば、治験に適した被験者を効率的に選択することができる。

［第２実施形態］
次に、本発明の第２実施形態に係る治験管理装置としての治験管理サーバ２１０を含む治験管理システム２００について説明する。本実施形態においては、フェーズ１（Ｐ１）の治験について説明する。

本実施形態に係る治験管理システム２００において、治験管理サーバ２１０は、治験プロトコールに基づいて、登録された被験者候補から実施される治験に適した被験者の識別子を取得または被験者を選択する。また、治験管理サーバ２１０は、治験プロトコールに基づいて、治験実施施設や被験者が投薬および検査を含む治験を行うタイミングを設定するタイムテーブルおよびワークフローを生成する。そして、治験管理サーバ２１０は、タイムテーブルに従って投薬タイミングまたは検査タイミングを管理しながら投薬および検査を実施する。なお、治験プロトコールとは、治験を実施にするにあたって、治験実施者（治験を実施する医療機関）および治験依頼者（おもに製薬会社）が遵守しなければならない、その治験に関する要件事項を記載した実施計画書のことである。治験プロトコールには、治験の背景、根拠および目的などとともに、統計学的な考察も含めて、治験のデザインや方法および組織についても記載される。

また、治験管理サーバ２１０は、治験が治験プロトコールを逸脱せずに行われたかを判定して、報知する。また、治験管理サーバ２１０は、投薬および検査が所定のタイミングで正常に行われたか、あるいは、検査結果がベースラインから離れていないか、を判定して、正常でなければアラートを発して報知する。また、治験依頼者による治験の進捗状態の問合せに応答する。そして、治験終了時には、治験依頼者のフォーマットに従った治験報告書を生成して報告する。

＜治験管理システム＞
以下、図２Ａから図５Ｄを参照して、治験管理サーバ２１０を含む治験管理システム２００の構成および動作を説明する。

（システム構成）
図２Ａは、本実施形態に係る治験管理サーバ２１０を含む治験管理システム２００の構成を示す図である。

治験管理システム２００は、ネットワーク２５０を介して通信する、治験管理サーバ２１０と、ＣＲＣ（Clinical Research Coordinator：治験コーディネータ）端末２２０と、被験者端末２３０と、治験依頼者端末２４０と、を備える。なお、ＣＲＣ端末２２０は、治験実施施設２０１内の治験コーディネータ用に配置されて、治験コーディネータによる治験管理を支援する。一方、被験者端末２３０は、治験実施施設２０１内の各被験者のベッドサイド端末として配置され、被験者による治験の実施を支援する。治験管理サーバ２１０は、治験依頼者（製薬会社など）２４１が使用する治験依頼者端末２４０から取得した治験プロトコールに基づいて、被験者候補から実施する治験に適した被験者の識別子を取得または被験者を選択する。そして、治験管理サーバ２１０は、治験プロトコールに基づいて、治験実施施設や被験者が投薬および検査を含む治験を行うタイミングを設定するタイムテーブルを生成する。そして、タイムテーブルに従って投薬タイミングまたは検査タイミングを管理しながら、ＣＲＣ端末２２０や被験者端末２３０に対して投薬および検査を実施するよう報知し、問題が発生すればアラートを発生する。そして、治験が完了すると、治験管理サーバ２１０は、治験依頼に対応する治験報告書（症例報告書／ＣＲＦ:Case Report Form)を作成して、治験依頼者端末２４０に報告する。

（システムの動作概要）
図２Ｂは、本実施形態に係る治験管理サーバ２１０を含む治験管理システム２００の動作概要を示す図である。なお、図２Ａと同様の構成要素には同じ参照番号を付して、重複する説明は省略する。

図２Ｂの治験実施施設２０１においては、フェーズ１（Ｐ１）の治験が実施される。例えば、治験実施施設２０１は病院内に設置されてもよい。治験実施施設２０１では、治験依頼者２４１からの依頼を受けて、治験を実施し治験報告書を治験依頼者２４１に渡す。

治験実施施設２０１においては、治験依頼内容に対応して、被験者管理（選定）２０２と、使用する院内機器の連携２０３と、タイムテーブルの生成２０４と、治験実施の記録２０５と、医師による記録データの承認２０６と、が行われる。そして、治験実施期間中には、治験依頼者２４１からのモニタリング２０８が行われ、記録データからのデータ抽出／出力２０９と、抽出データに基づく治験報告書（ｅＣＲＦ）の作成２０７と、が行われる。

本実施形態の治験管理サーバ２１０は、これら治験における処理（２０１～２０９）の進捗状態を効率的に管理するものである。

（動作シーケンス）
図３Ａは、本実施形態に係る治験管理サーバ２１０を含む治験管理システム２００における動作手順を示すシーケンス図である。

ステップＳ３０１において、治験管理サーバ２１０と、ＣＲＣ端末２２０と、被験者端末２３０と、の間で治験管理アプリケーションを起動する。ステップＳ３０３において、治験依頼者端末２４０から治験管理サーバ２１０に治験依頼情報として治験プロトコールが通知される。治験管理サーバ２１０は、ステップＳ３０５において、対象の治験に適した被験者の識別子を取得、または治験プロトコールに基づいて被験者候補登録部に登録された被験者候補をスクリーニングして、対象の治験に適した被験者を選択する。治験管理サーバ２１０は、ステップＳ３０７において、治験プロトコールに従ってタイムテーブルを生成し、ＣＲＣ用のタイムテーブルおよび各被験者用のタイムテーブルをＣＲＣ端末２２０に通知し、登録された被験者が居ることを確認して各被験者用のタイムテーブルを被験者端末２３０に通知する。ＣＲＣ端末２２０は、ステップＳ３０９において、通知されたＣＲＣ用のタイムテーブルおよび各被験者用のタイムテーブルを表示する。被験者端末２３０は、ステップＳ３１１において、通知された各被験者用のタイムテーブルを表示する。そして、治験管理サーバ２１０は、ステップＳ３１３において、治験プロトコールに基づいて、治験プロトコールからの逸脱をチェックするための逸脱チェックテーブルを生成する。

ＣＲＣ用のタイムテーブルに従い投薬タイミングが近付くと、治験管理サーバ２１０は、ステップＳ３２１において、投薬タイミングの指示および完了の管理をする。すなわち、ＣＲＣ端末２２０に対しては、投薬タイミングの所定時間前に投薬準備の指示をし、ＣＲＣ端末２２０からの、所定時間範囲内での投薬準備完了通知の受信を待つ。ＣＲＣ端末２２０は、ステップＳ３２３において、薬の確認などの投薬準備の指示を報知し、投薬準備完了通知を治験管理サーバ２１０に送信する。一方、被験者端末２３０に対しては、投薬タイミングに投薬を指示し、被験者端末２３０からの所定時間範囲内での投薬完了通知を待つ。被験者端末２３０は、ステップＳ３２５において、投薬の指示を報知し、投薬完了通知を治験管理サーバ２１０に送信する。所定時間範囲内での投薬準備完了通知がない場合、所定時間範囲内での投薬完了通知がない場合、あるいは、投薬完了通知での被験者が確認できない場合などには、アラートを発生する。

また、ＣＲＣ用のタイムテーブルに従い検査タイミングが近付くと、治験管理サーバ２１０は、ステップＳ３２７において、検査タイミングの指示および完了の管理をする。すなわち、ＣＲＣ端末２２０に対しては、検査タイミングの所定時間前に検査装置や検査用資材などの検査準備の指示をし、ＣＲＣ端末２２０からの、所定時間範囲内での検査準備完了通知の受信を待つ。ＣＲＣ端末２２０は、ステップＳ３２９において、検査準備の指示を報知し、検査準備完了通知を治験管理サーバ２１０に送信する。一方、被験者端末２３０に対しては、検査タイミングに検査を指示し、被験者端末２３０からの所定時間範囲内での検査完了通知を待つ。被験者端末２３０は、ステップＳ３３１において、検査の指示を報知し、検査完了通知を治験管理サーバ２１０に送信する。所定時間範囲内での検査準備完了通知がない場合、所定時間範囲内での検査完了通知がない場合、あるいは、検査完了通知での被験者の間違いや確認できない場合などには、アラートを発生する。

ＣＲＣ端末２２０および／または被験者端末２３０は、検査完了通知と共に、ステップＳ３３３において、検査結果を治験管理サーバ２１０に送信する。治験管理サーバ２１０は、ステップＳ３３５において、収集した検査結果を被験者ＩＤに対応付けて蓄積し、被験者と検査結果とが対応しているか、あるいは、検査結果が検査値のベースラインから逸脱していないかなどを確認する。そして、確認の結果、問題が発生していればアラートを、ＣＲＣ端末２２０、各被験者端末２３０、あるいは、治験に大きな影響があれば治験依頼者端末２４０に報知する。また、治験管理サーバ２１０は、ステップＳ３３６において、逸脱チェックテーブルを参照して治験処理が治験プロトコールから逸脱していないかをチェックし、逸脱していればアラートを、ＣＲＣ端末２２０、各被験者端末２３０、あるいは、治験に大きな影響があれば治験依頼者端末２４０に報知する。また、治験期間中に、治験依頼者端末２４０からのステップＳ３３７における進捗状態の問合せや治験履歴の閲覧要求に応答して、治験管理サーバ２１０は、ステップＳ３３９において、治験の進捗状態や治験履歴を報告する。なお、治験の進捗状態や治験履歴の報告は、治験依頼者端末２４０からの問合せなしに、治験管理サーバ２１０から随時に行われてもよい。

タイムテーブルに従い、上述の投薬、検査、検査結果の収集を治験計画の期間だけ繰り返す。なお、投薬回数と検査回数は治験計画により決められる。治験が完了すると、ＣＲＣ端末２２０は、ステップＳ３４１において、医師による治験データのチェックを行う。医師によるチェックが終了すると、治験管理サーバ２１０は、ステップＳ３４３において、収集して蓄積した検査結果に基づいて、治験依頼者のフォーマットに対応する治験報告書を生成して、治験依頼者端末２４０に送付する。治験依頼者端末２４０は、ステップＳ３４５において、治験報告書を受理する。

図３Ｂは、図３ＡのＳ３０５において、スクリーニングにより対象の治験に適した被験者の識別子を選択する場合の動作手順を詳細に示すシーケンス図である。治験管理サーバ２１０は、ステップＳ３５１において、治験プロトコールから被験者選択条件を抽出する。なお、治験データベース３０２には、治験プロトコールに対応して適した被験者を選択するための、抽出した被験者選択条件の各項目に対する重み付け値（ポイント）を格納する被験者選択情報３２１が格納されている。また、治験データベース３０２には、被験者候補が対応する被験者情報と共に登録されている被験者候補登録部３２２が格納されている。なお、フェーズ１においては、被験者候補登録部３２２が検査項目記憶部として機能する。

治験管理サーバ２１０は、ステップＳ３５３において、被験者候補登録部３２２から被験者候補の識別情報（ＩＤ）と属性や生体情報などとを取得する。治験管理サーバ２１０は、ステップＳ３５５において、被験者選択情報３２１を参照し、被験者候補の情報に基づいて被験者選択条件の各項目に対して重み付けを行う。治験管理サーバ２１０は、ステップＳ３５７において、重み付けされた被験者選択条件のトータルスコアから適格性が優先する順に被験者を並べる。そして、治験管理サーバ２１０は、ステップＳ３５９において、適格性が優先する順に治験に必要な人数の被験者とその情報とを出力する。

（ＣＲＣ端末の表示画面）
図４Ａから図１４Ｃは、本実施形態に係るＣＲＣ端末２２０の表示画面を示す図である。

図４Ａの表示画面４１０においては、ＣＲＣ端末２２０としてのタブレットに、実施記録と連動して、実施者と実施時刻とを表示する。予定時刻から実施時刻に表示が切り替わることによって、タイムリーな治験実施の進捗状態を確認できる。

図４Ｂの表示画面４２０においては、ＣＲＣ端末２２０としてのタブレットに、実施者と、実施日時と、医師コメントとが表示され、治験結果の記録データに対する医師評価が確認できる。

図４Ｃの表示画面４３０においては、ＣＲＣ端末２２０としてのタブレットにおいて、被験者の選定が行われており、間違いがない被験者の選定が効率的にできる。

（被験者端末の表示画面）
図５Ａから図５Ｄは、本実施形態に係る被験者端末２３０の表示画面を示す図である。

図５Ａは、被験者端末２３０において、被験者を選別して登録する処理を示している。表示画面５１０は、初期メニューが表示された画面であり、事前健診と、スクリーニングと、本試験とが選択可能である。表示画面５１５は、表示画面５１０でスクリーニングが選択された場合に表示される画面であり、被験者の認証が、例えば、被験者を識別するＩＣタグ（または、バーコード）の読み取りにより行われる。表示画面５１５は、被験者が実施される治験の条件を満たすか否かのスクリーニング画面である。このようにして、被験者が効率的に選別される。

図５Ｂは、被験者端末２３０において、各被験者における治験のタイムテーブルを設定、治験の進捗を管理するための処理を示している。表示画面５３０は、治験開始における被験者の認証画面である。図５Ａと同様に、被験者の認証が、例えば、被験者を識別するＩＣタグ（または、バーコード）の読み取りにより行われる。表示画面５３５は、被験者が使用するタイムテーブルを選択する画面である。各被験者の治験に対応するタイムテーブルが選択され、選択済のタイムテーブルと非選択のタイムテーブルとが識別可能に表示されている。表示画面５４０は、表示画面５３５で選択されたタイムテーブルを表示する画面である。表示画面５３５では、タイムテーブル中の各処理（投薬、検査、その他の飲水などを含む）について、その実施状態を識別可能に表示する。例えば、未実施か、実施済だが医師（すなわち、ＣＲＣ端末２２０）には未送信か、実施済で医師に送信済か、などが簡単に認識できる。

図５Ｃは、被験者端末２３０において、各被験者における本試験（治験）の開始、治験の進捗を管理するための処理を示している。表示画面５５０は、測定者（ＣＲＣ）を認証する画面であり、ＣＲＣの認証が、例えば、ＣＲＣを識別するＩＣタグ（または、バーコード）の読み取りにより行われる。表示画面５５５は、例えば、タイムテーブル中で被験者の体温測定が行われる時の画面である。表示画面５５５には、体温のベースラインが表示されてよい。なお、体温計からの計測データは、表示データを読み取る方式であっても、有線あるいは無線で送信する常識であってもよい。ウェアラブルな体温計であるのが望ましい。表示画面５６０は、治験の履歴を表示する画面である。表示画面５６０には、体温の測定履歴が表示されており、登録のみの測定結果と医師に送信された測定結果とは識別可能に表示される。

図５Ｄは、タイムテーブルに従って、被験者に次の行動を予告して指示するための画面である。表示画面５７０は、飲水の１０秒前の飲水準備を報知する画面である。そして、表示画面５８０は、飲水を報知する画面である。なお、図５Ｄには、飲水の場合を説明したが、投薬タイミングや検査タイミングにおいても同様の処理が行われる。また、ＣＲＣ端末２２０においても、同様の事前報知が行われてよい。

＜治験管理装置の機能構成＞
図６は、本実施形態に係る治験管理サーバ２１０の機能構成の詳細を示すブロック図である。なお、図６において、図２Ａと同様の構成要素には同じ参照番号を付して、重複する説明を省略する。

治験管理サーバ２１０は、通信制御部６０１と、治験データベース３０２と、治験情報取得部６０３と、被験者選択部６０４と、治験プロトコール解析部６０５と、タイムテーブル送信部６０６と、を備える。また、治験管理サーバ２１０は、投薬タイミング生成部６０７と、投薬準備通知部６０８と、投薬通知部６０９と、検査タイミング生成部６１０と、検査準備通知部６１１と、検査通知部６１２と、を備える。さらに、治験管理サーバ２１０は、投薬／検査結果取得部６１３と、投薬／検査確認部６１４と、アラート報知部６１５と、治験進捗状態報告部６１６と、治験報告書生成部６１７と、治験報告書送信部６１８と、を備える。

通信制御部６０１は、治験依頼者端末２４０、ＣＲＣ端末２２０および被験者端末２３０との通信を制御する。治験データベース３０２は、治験管理サーバ２１０が治験を管理するための種々のデータを格納する。治験データベース３０２は、治験者情報格納部６２０と、治験計画情報格納部６２３と、治験履歴格納部６３０と、を有する。治験者情報格納部６２０は、被験者候補登録部３２２と被験者選択情報３２１とを含む。治験計画情報格納部６２３は、治験プロトコール６２４とタイムテーブル６２５と治験プロトコール逸脱チェックテーブル６２６と使用資材情報６２７とを含む。治験履歴格納部６３０は、治験蓄積データ６３１とアラート履歴６３２とを含む。

治験情報取得部６０３は、治験依頼者端末２４０から依頼された治験の治験情報として治験プロトコールを取得して、治験計画情報格納部６２３に格納する。被験者選択部６０４は、治験プロトコールに基づいて、治験に適した被験者を被験者候補から選択する。治験プロトコール解析部６０５は、治験プロトコールに従って、ＣＲＣや各被験者の治験処理タイミングを表したタイムテーブルおよびワークフローを生成する。タイムテーブル送信部６０６は、ＣＲＣや各被験者用のタイムテーブルをＣＲＣ端末２２０に送信し、各被験者用のタイムテーブルを各被験者端末２３０に送信する。また、治験プロトコール解析部６０５は、治験プロトコールに従って、治験処理が治験プロトコールを逸脱してないかを判定するための治験プロトコール逸脱チェックテーブルを生成して、治験計画情報格納部６２３に格納する。

投薬タイミング生成部６０７は、タイムテーブルに従って、投薬タイミングが近付いた場合に、使用資材情報６２７と共に投薬準備の通知および投薬の通知を生成する。投薬準備通知部６０８は、投薬準備の通知をＣＲＣ端末２２０に送信する。投薬通知部６０９は、投薬の通知を各被験者端末２３０に送信する。検査タイミング生成部６１０は、タイムテーブルに従って、検査タイミングが近付いた場合に、検査準備の通知および検査の通知を生成する。検査準備通知部６１１は、検査準備の通知をＣＲＣ端末２２０に送信する。検査通知部６１２は、検査の通知を各被験者端末２３０に送信する。

投薬／検査結果取得部６１３は、投薬結果および検査結果の情報をＣＲＣ端末２２０や各被験者端末２３０から取得する。各被験者端末２３０から取得する検査結果としては、体温や血圧値など各被験者端末２３０に接続する機器で取得可能なデータが含まれる。一方、ＣＲＣ端末２２０から取得する検査結果としては、血液検査結果などＣＲＣ端末２２０に接続する機器で取得可能なデータが含まれる。投薬／検査確認部６１４は、投薬／検査チェックテーブル６４１を有する。投薬／検査確認部６１４は、治験期間中の投薬や検査に関連して正常に投薬や検査が行われたか、あるいは、検査結果が通常の検査値であるベースラインから逸脱していないか、あるいは、投薬や検査の履歴が治験プロトコールの条件を逸脱していないか、などをチェックする。そして、投薬／検査確認部６１４は、チェックの結果が正常であれば検査結果を治験蓄積データ６３１として格納する。正常でなければアラートを生成する。また、投薬／検査確認部６１４は、治験プロトコール逸脱チェックテーブルを用いて治験処理が治験プロトコールを逸脱していないかも判定する。なお、図６Ｂには矢印を記載していないが、投薬タイミング生成部６０７や検査タイミング生成部６１０から通知されたタイミングから所定時間内に応答が無い場合も、アラートを生成する。アラート報知部６１５は、投薬／検査確認部６１４が生成したアラートを、ＣＲＣ端末２２０および被験者端末２３０に報知する。なお、治験への影響が大きな問題の発生を検出した場合には、治験依頼者端末２４０にアラートを通知する。

治験進捗状態報告部６１６は、治験依頼者端末２４０から治験の進捗状態や治験履歴の閲覧の問い合わせを受けると、治験データベース３０２を参照して治験の進捗状態や治験履歴を生成して、閲覧画面送信部により治験依頼者端末２４０に報告する。治験報告書生成部６１７は、治験が完了すると、治験蓄積データ６３１を治験依頼者に応じたテンプレートでフォーマットした治験報告書を生成する。治験報告書送信部６１８は、生成した治験報告書を依頼元の治験依頼者端末２４０に送信する。

（治験情報格納部）
図７Ａは、本実施形態に係る治験者情報格納部６２０の構成を示す図である。治験者情報格納部６２０は、被験者候補登録部３２２と被験者選択情報３２１とを格納する。

被験者候補登録部３２２は、被験者候補ＩＤ７１１に対応付けて、氏名７１２と、住所７１３と、属性７１４と、被験者選択の項目となる被験者候補の生体情報７１５および治験履歴７１６と、治験対象への治験者としての合否７１７と、を記憶する。

被験者選択情報３２１は、治験目的による治験対象７２０に対応つけて、それぞれの被験者を選択するため用いる検査項目７２１を記憶する。そして、検査項目７２１のそれぞれに対応付けて、治験候補者となり得る数値の基準範囲７２２と、数値範囲のよる重み付け値（ポイント：pt）７２３～７２５と、治験対象に対応する検査項目の重み付け（反映度：×）７２８と、を記憶する。なお、値範囲のよる重み付け値（ポイント：pt）７２３～７２５と、治験対象に対応する検査項目の重み付け（反映度：×）７２８と、はいずれか一方の重み付けであっても、両方の重み付けを考慮してもよい。検査項目の重み付け７２８のみの場合は、反映度でなく重み付け数値（ポイント）となる。

（治験計画情報格納部）
図７Ｂは、本実施形態に係る治験計画情報格納部６２３の一部の構成を示す図である。かかる治験計画情報に基づいて、治験が効率的に管理されながら実施される。図７Ｂには、治験プロトコール６２４と、治験プロトコール６２４に対応して生成されたタイムテーブル６２５と、を示す。

治験プロトコール６２４は、治験ＩＤ７３１に対応付けて、治験のフェーズ７３２、治験の目的７３３、治験デザイン７３４、治験対象者（被験者）７３５、治験薬７３６や、治験薬の投与方法、治験薬の投与期間、などの治験の実施に必要な情報を含む。さらに、治験プロトコール６２４は、治験スケジュール７３７、実施詳細７３８、観察・検査項目７３９や、有効性評価項目、安全性評価項目、目標症例数、実施予定期間、などの治験を評価する条件を含む。なお、有効性評価項目はフェーズ１の治験において評価項目はない。

タイムテーブル６２５は、治験ＩＤ７４１に対応付けて、治験全体の治験スケジュール７４２、治験プロトコール６２４の条件を満たす治験の許容範囲７４３、を含み、許容範囲７４３を逸脱すればアラートの発生となる。また、タイムテーブル６２５は、ＣＲＣＩＤ７４４に対応付けて、ＣＲＣに対するＣＲＣスケジュール７４５と、ＣＲＣに関連する投薬準備や検査準備、あるいは検査結果の許容範囲７４６、とを含み、許容範囲７４６を逸脱すればアラートの発生となる。また、タイムテーブル６２５は、被治験者ＩＤ７４７に対応付けて、被治験者に対する被治験者スケジュール７４８と、被治験者に関連する投薬や検査、あるいは検査結果の許容範囲７４９、とを含み、許容範囲７４９を逸脱すればアラートの発生となる。

図７Ｃは、本実施形態に係る治験プロトコール６２４の全体の構成を示す図である。かかる治験プロトコール６２４については、国際的にも日本国内においても、ある程度規格化されたフォーマットが提供されているので、詳細な説明を省略する。

図７Ｄは、本実施形態に係る治験計画情報格納部６２３の他の構成を示す図である。図７Ｄには、治験プロトコール逸脱チェックテーブル６２６と、治験に使用される使用資材情報６２７と、を示す。

治験プロトコール逸脱チェックテーブル６２６は、治験プロトコールの項目７５１に対応付けて、判定条件７５２と逸脱判定結果７５３とを記憶する。例えば、判定条件７５２として「該当日付の検査値未入力」の場合、逸脱判定結果７５３は「規定された検査の欠測」となる。また、判定条件７５２として「選択除外基準内から外れた検査値の検出」の場合、逸脱判定結果７５３は「選択除外基準に抵触した患者の組み入れ」となる。また、判定条件７５２として「併用薬に併用禁止薬を登録」の場合、逸脱判定結果７５３は「併用禁止薬の投与」となる。また、判定条件７５２として「規定間隔以外の日程に治験薬投与記録が発生している場合」の場合、逸脱判定結果７５３は「規定された治験薬投与間隔以外での治験薬投与」となる。なお、治験プロトコール逸脱チェックは、上記例に限定されるものではない。また、実際には具体的な数値や数値範囲などが設定されるが、煩雑なため省略する。

使用資材情報６２７は、本治験で使用される計測機器や採血管などの器具の情報である。使用資材情報６２７は、資材ＩＤに対応付けて、資材名、メーカ情報を含む用途、必要な使用数、使用可能な使用期限、などを含む。

（治験結果情報格納部）
図７Ｅは、本実施形態に係る治験履歴格納部６３０の構成を示す図である。治験履歴格納部６３０は、被験者に紐付けられた投薬および検査の履歴と、履歴から治験報告者を生成するためのテンプレートとを有する治験蓄積データ６３１と、治験プロトコール６２４やタイムテーブル６２５に基づいて条件を逸脱したと判定されたアラート履歴６３２と、を含む。

治験蓄積データ６３１は、被験者ＩＤ７６１に対応付けて、日時と完了フラグとを有する投薬履歴７６２と、日時と完了フラグと検査結果内容と検査結果可否フラグとを有する検査履歴７６３と、を含む。また、治験蓄積データ６３１は、治験依頼者ＩＤ７６５に対応付けて、治験報告書テンプレート７６６を含む。

アラート履歴６３２は、ＣＲＣに関連するアラートとして、日時７７１に対応付けて、アラート内容７７２と、ＣＲＣＩＤ７７３とを含む。また、アラート履歴６３２は、被験者に関連するアラートとして、日時７８１に対応付けて、アラート内容７８２と、被験者ＩＤ７８３とを含む。また、被験者ＩＤ７８４に対応付けて、治験期間中のアラート回数７８５と、アラート回数７８５に基づく被験者評価７８６とを含む。さらに、アラート履歴６３２は、治験全体に関するアラートとして、治験ＩＤ７８７に対応付けて、治験全体のアラート回数７８８と、アラート回数７８８に基づく治験評価７８９とを含む。

（投薬／検査チェックテーブル）
図７Ｆは、本実施形態に係る投薬／検査チェックテーブル６４１の構成を示す図である。投薬／検査チェックテーブル６４１は、投薬／検査確認部６１４が被験者端末２３０やＣＲＣ端末２２０から取得した投薬結果や検査結果が、治験プロトコール６２４やタイムテーブル６２５の条件を満たすか否かを確認するために使用される。

投薬／検査チェックテーブル６４１は、タイムテーブル６２５に基づく異なるタイミング７９１においてチェックされる内容として、以下のデータを記憶する。すなわち、日時７９２に対応付けて、チェック項目７９３、チェック基準データ７９４、チェック値７９５、チェック値７９５と比較される閾値７９６、チェック結果７９７、アラートメッセージ７９８、を記憶する。

異なるタイミング７９１としては、治験開始タイミング、投薬タイミング、検査タイミング、治験終了タイミング、が含まれる。治験開始タイミングにおいては、被験者を被験者ＩＤにより確認する。また、被験者の健康状態を、被験者の正常値から被験前の検査値が変化した変化率を閾値と比較して、正常であるか否かを確認する。

投薬タイミングにおいては、投与する薬を投与薬品名により確認する。また、被験者を被験者ＩＤにより確認する。また、投薬の正常な完了を、投薬時刻が投薬タイミングの許容範囲に含まれるか否かで判定する。なお、図示しないがＣＲＣによる投薬準備も投薬準備タイミングの許容範囲に含まれるか否かで同様に判定される。

検査タイミングにおいては、検査した被験者を被験者ＩＤにより確認する。また、検査の正常な完了を、検査時刻が検査タイミングの許容範囲に含まれるか否かで判定する。なお、図示しないがＣＲＣによる検査準備も検査準備タイミングの許容範囲に含まれるか否かで同様に判定される。また、検査結果のデータを、被験者の正常値から検査値が変化した変化率を閾値と比較して、正常であるか否かを確認する。また、正しい検査資材が使用されたか否かを使用制限などから確認する。

治験終了タイミングにおいては、治験した被験者を被験者ＩＤにより確認する。また、治験履歴からアラート回数などを参照して、治験が正常に完了しているかを確認する。また、治験結果の内容を医師によって確認する。なお、図示しないが、治験全体については、治験が正常に完了した被験者数が治験プロトコールの目標症例数に達しているか否かなどにより、確認する。

＜治験管理装置の処理手順＞
図８Ａおよび図８Ｂは、本実施形態に係る治験管理サーバ２１０の処理手順を示すフローチャートである。このフローチャートは、治験管理サーバ２１０を構成するＣＰＵ(Central Processing Unit)がＲＡＭ(Random Access Memory)および治験データベース３０２のデータを用いて実行し、図６の各構成要素を実現する。

治験管理サーバ２１０は、ステップＳ８１１において、治験依頼者からの治験プロトコールの受信か否かを判定する。治験プロトコールの受信であれば、治験管理サーバ２１０は、ステップＳ８１２において、治験プロトコールに基づいた被験者のスクリーニング処理を実行する。治験管理サーバ２１０は、ステップＳ８１３において、治験プロトコールから治験全体（ＣＲＣ用）のタイムテーブルを生成する。そして、治験管理サーバ２１０は、ステップＳ８１４において、要求があれば、ＣＲＣ用のタイムテーブルをＣＲＣ端末２２０および被験者端末２３０に送信する。治験管理サーバ２１０は、ステップＳ８１５において、各被験者用のタイムテーブルを生成する。そして、治験管理サーバ２１０は、ステップＳ８１６において、要求があれば、各被験者用のタイムテーブルをＣＲＣ端末２２０および対応する被験者端末２３０に送信する。治験管理サーバ２１０は、ステップＳ８１７において、治験プロトコールに基づいて逸脱チェックテーブル６２６を生成する。

治験情報の受信でなければ、治験管理サーバ２１０は、ステップＳ８２１において、投薬タイミングの所定時間前であるか否かを判定する。投薬タイミングの所定時間前であれば投薬準備が必要なので、治験管理サーバ２１０は、ステップＳ８２３において、ＣＲＣ端末２２０に投薬準備を報知させる。そして、治験管理サーバ２１０は、ステップＳ８２５において、ＣＲＣ端末２２０からの投薬準備完了の報告を待つ。投薬準備完了の報告があれば、治験管理サーバ２１０は、ステップＳ８２７において、各被験者の投薬タイミングを対応する各被験者端末２３０に報知させる。そして、治験管理サーバ２１０は、ステップＳ８２９において、各被験者端末２３０からの投薬完了の報告を待つ。投薬が正常に完了すると、治験管理サーバ２１０は、ステップＳ８３１において、投薬完了を治験蓄積データ６３１として記録する。一方、投薬が正常に完了していないと、治験管理サーバ２１０は、ステップＳ８３３において、投薬未完了を治験蓄積データ６３１として記録すると共に、アラートを発生させる。なお、投薬未完了が所定数を超えると治験終了とする。

治験情報の受信でなく投薬タイミングでもない場合、治験管理サーバ２１０は、ステップＳ８４１において、検査タイミングの所定時間前であるか否かを判定する。検査タイミングの所定時間前であれば検査準備が必要なので、治験管理サーバ２１０は、ステップＳ８４３において、ＣＲＣ端末２２０に検査準備を報知させる。そして、治験管理サーバ２１０は、ステップＳ８４５において、ＣＲＣ端末２２０からの検査準備完了の報告を待つ。検査準備完了の報告があれば、治験管理サーバ２１０は、ステップＳ８４６において、検査に使用する資材が正しいか、有効期限内か、数は十分かなどを確認する。検査資材が確認できなければ、治験管理サーバ２１０は、ステップＳ８４３に戻って、再度検査準備を促す。検査資材が確認できれば、治験管理サーバ２１０は、ステップＳ８４７において、各被験者の検査タイミングを各被験者端末２３０に報知させる。そして、治験管理サーバ２１０は、ステップＳ８４９において、各被験者端末２３０からの検査完了の報告を待つ。検査が正常に完了すると、治験管理サーバ２１０は、ステップＳ８５１において、検査結果の値が正常な範囲であるか否かを判定する。また、治験管理サーバ２１０は、ステップＳ８５２において、治験処理が治験プロトコールを逸脱していないかを判定する。正常な範囲であり逸脱してなければ、治験管理サーバ２１０は、ステップＳ８５３において、検査結果の値を各被験者ＩＤに対応付けて治験蓄積データ６３１として記録する。一方、検査が正常に完了しない、または、検査結果が正常範囲外である場合、または、治験プロトコールを逸脱している場合は、治験管理サーバ２１０は、ステップＳ８５５において、検査未完了または正常でないとのフラグ（可否フラグ）を付した検査結果を治験蓄積データ６３１として記録する。治験管理サーバ２１０は、ステップＳ８５７において、治験期間が経過して治験完了か否かを判定する。治験完了でなければ、投薬と検査とを治験期間のあいだ繰り返す。なお、煩雑となるため、図８Ｂには、ＣＲＣ端末２２０でまとめて検査結果を取得する、例えば、血液検査などについては図示されていない。ステップＳ８４７が全被験者の検査結果をＣＲＣ端末２２０に求める内容に代わり、後のフローは同様となる。

治験完了と判定されれば、治験管理サーバ２１０は、ステップＳ８５９において、治験結果である治験蓄積データ６３１が治験プロトコールの条件を満たすか否かが判定される。なお、この判定には、医師によるデータの確認を含んでもよい。治験プロトコールの条件を満たす場合、治験管理サーバ２１０は、ステップＳ８６１において、治験蓄積データ６３１から治験報告書テンプレート７６６に従って治験報告書を生成する。そして、治験管理サーバ２１０は、ステップＳ８６３において、治験報告書を治験依頼者端末２４０に送信する。一方、治験プロトコールの条件を満たさない場合、治験管理サーバ２１０は、ステップＳ８６５において、治験エラーを治験依頼者端末２４０に通知する。

治験情報の受信でなく投薬タイミングでもなく検査タイミングでのない場合、治験管理サーバ２１０は、ステップＳ８７１において、治験依頼者端末２４０からの進捗状態の問合せか否かを判定する。進捗状態の問合せであれば、治験管理サーバ２１０は、ステップＳ８７３において、現在までの治験結果（治験蓄積データ６３１、アラート履歴６３２）を読み出す。そして、治験管理サーバ２１０は、ステップＳ８７５において、進捗状態の報告を生成して対応する治験依頼者端末２４０に返信する。

図８Ｃは、本実施形態に係る被験者のスクリーニグ処理Ｓ８１２の手順を示すフローチャートである。従来のスクリーニング（被験者の選択）は適格性判定基準に合致するか否かによる被験者の選択であるため、治験に適した被験者を効率的に選択することができなかった。本実施形態のスクリーニングによれば、治験プロトコールに対応して、被験者候補から被験者を選択する検査項目に対して重み付けをして、治験に適した順に選択された被験者を出力するので、治験に適した被験者を効率的に知ることができる。

治験管理サーバ２１０は、ステップＳ８８１において、治験プロトコールから被験者条件項目を抽出する。治験管理サーバ２１０は、ステップＳ８８３において、各条件項目内の重み付けを行うか否かを判定する。各条件項目内の重み付けを行う場合、治験管理サーバ２１０は、ステップＳ８８５において、各条件項目の数値範囲に対応した重み付けを行う。そして、管理サーバ２１０は、ステップＳ８８７において、被験者選択に必要な条件項目内への重み付けが完了したかを判定し、完了してなければ、ステップＳ８８５を繰り返す。

条件項目内への重み付けが完了あるいは条件項目内への重み付けをしない場合、治験管理サーバ２１０は、ステップＳ８８９において、各条件項目に対する重み付けを行うか否かを判定する。各条件項目に対する重み付けを行う場合、治験管理サーバ２１０は、ステップＳ８９１において、各条件項目に対して重み付けを行う。そして、管理サーバ２１０は、ステップＳ８９３において、被験者選択に必要な条件項目への重み付けが完了したかを判定し、完了してなければ、ステップＳ８９３を繰り返す。

条件項目に対する重み付けが完了あるいは条件項目に対する重み付けをしない場合、治験管理サーバ２１０は、ステップＳ８９５において、重み付けの結果から重みの大きい順に被験者候補をソートして選択された被験者として出力する。

＜被験者端末の機能構成＞
図９Ａは、本実施形態に係る被験者端末２３０の機能構成を示す図である。

被験者端末２３０は、データ制御部９０１と、通信制御部９０２と、入出力インタフェース９０３と、表示部／操作部９０４と、データ記憶部９０５と、を備える。被験者端末２３０は、標準のタブレットなどでよい。

データ制御部９０１は、ＣＰＵ、一時記憶のＲＡＭ、プログラムを格納するＲＯＭ、から構成され、被験者端末２３０を制御する。通信制御部９０２は、治験管理サーバ２１０やＣＲＣ端末２２０との通信を制御する。被験者端末２３０間の通信も制御される。

入出力インタフェース９０３には、ＩＣタグリーダ９３１、バーコードリーダ９３２、測定機器９３３、が接続できる。なお、ＩＣタグリーダ９３１とバーコードリーダ９３２とは、被験者が保持する被験者ＩＤの形態（ＩＣタグかバーコードか）により代替可能である。また、測定機器９３３は、体温計、脈拍計、血圧計など各被験者から生体情報を測定可能な機器であり、各被験者にウェアラブルな自動測定機器であることが望ましい。

表示部／操作部９０４は、タイムテーブルや投薬指示通知、検査指示通知、アラートなどを表示する表示部と、表示画面の選択や被験者端末２３０の操作指示をする操作部とを有する。なお、表示部／操作部９０４は、タッチパネルであることが望ましい。

データ記憶部９０５は、データベースやアプリケーションプログラムを記憶する。例えば、被験者ＩＤ、タイムテーブル、投薬指示通知、検査指示通知などのデータ、あるいは、測定機器９３３が測定した被験者の生体情報などを記憶する。

＜被験者端末の処理手順＞
図９Ｂは、本実施形態に係る被験者端末２３０の処理手順を示すフローチャートである。このフローチャートは、データ制御部９０１のＣＰＵがＲＡＭを使用して実行して、被験者端末２３０の機能を実現する。

データ制御部９０１は、ステップＳ９１１において、治験管理サーバ２１０から被験者情報とタイムテーブルとを含む被験者用の被験者治験情報を受信したか否かを判定する。被験者治験情報を受信した場合、データ制御部９０１は、ステップＳ９１３において、被験者治験情報から被験者ＩＤおよび被験者情報を取得して保持する。そして、データ制御部９０１は、ステップＳ９１５において、被験者治験情報からタイムテーブルを取得して保持する。なお、被験者治験情報は、被験者端末２３０から治験管理サーバ２１０に要求して取得する構成であってもよい。

被験者治験情報の受信でない場合、データ制御部９０１は、ステップＳ９２１において、治験管理サーバ２１０から投薬タイミングの通知を受信したか否かを判定する。投薬タイミングの通知を受信した場合、データ制御部９０１は、ステップＳ９２３において、投薬タイミングを被験者に報知する。そして、データ制御部９０１は、ステップＳ９２５において、投薬が完了したか否かを判定する。投薬が完了したと判定すると、データ制御部９０１は、ステップＳ９２７において、投薬完了を治験管理サーバ２１０に通知する。一方、投薬が完了してないと判定すると、データ制御部９０１は、ステップＳ９２９において、治験の経過状況として投薬タイミングからの経過時間が閾値（α）より長いか否かを判定する。経過時間が閾値（α）より長くない場合、データ制御部９０１は、ステップＳ９２３に戻って、再度投稿タイミングを報知する。経過時間が閾値（α）より長くなった場合、データ制御部９０１は、ステップＳ９３１において、投薬においてエラーが発生したと判断して投薬未完のアラートを報知し、治験管理サーバ２１０に通知する。

被験者治験情報の受信でなく投薬タイミングでもない場合、データ制御部９０１は、ステップＳ９４１において、検査タイミングの通知を受信したか否かを判定する。検査タイミングの通知を受信した場合、データ制御部９０１は、ステップＳ９４３において、検査タイミングを被験者に報知する。そして、データ制御部９０１は、ステップＳ９４５において、検査が完了したか否かを判定する。検査が完了したと判定すると、データ制御部９０１は、ステップＳ９４７において、検査完了を治験管理サーバ２１０に通知し、被験者端末２３０で測定した検査結果のデータがあれば、検査データも治験管理サーバ２１０に通知する。一方、検査が完了してないと判定すると、データ制御部９０１は、ステップＳ９４９において、治験の経過状況として検査タイミングからの経過時間が閾値（β）より長いか否かを判定する。経過時間が閾値（β）より長くない場合、データ制御部９０１は、ステップＳ９４３に戻って、再度検査タイミングを報知する。経過時間が閾値（β）より長くなった場合、データ制御部９０１は、ステップＳ９５１において、検査においてエラーが発生したと判断して検査未完のアラートを報知し、治験管理サーバ２１０に通知する。

＜ＣＲＣ端末を含む機能構成＞
図１０Ａは、本実施形態に係るＣＲＣ端末２２０を含む機能構成を示す図である。

ＣＲＣ端末２２０は、データ制御部１００１と、通信制御部１００２と、入出力インタフェース１００３と、表示部／操作部１００４と、データ記憶部１００５と、を備える。ＣＲＣ端末２２０は、標準のタブレットやパーソナルコンピュータ（ＰＣ）などでよい。

データ制御部１００１は、ＣＰＵ、一時記憶のＲＡＭ、プログラムを格納するＲＯＭ、から構成され、ＣＲＣ端末２２０を制御する。通信制御部１００２は、治験管理サーバ２１０や被験者端末２３０との通信を制御する。ＣＲＣ端末２２０間の通信も制御される。

入出力インタフェース１００３には、ＩＣタグリーダ１０３１、バーコードリーダ１０３２、測定機器１０３３、が接続できる。なお、ＩＣタグリーダ１０３１とバーコードリーダ１０３２とは、ＣＲＣが保持するＣＲＣＩＤの形態（ＩＣタグかバーコードか）により代替可能である。また、測定機器１０３３は、各被験者から収集した血液などから生体情報を測定可能な機器であり、測定値を自動的にＣＲＣ端末２２０に入力できる自動測定機器であることが望ましい。また、入出力インタフェース１００３には、採血管１０１０を被験者に対応して識別するためのＩＣタグ１０１１に被験者ＩＤを含むデータを書き込むタグ書込装置１０２０も接続可能である。タグ書込装置１０２０が書き込んだ被験者ＩＤを含むデータをＩＣタグリーダ１０３１で読み出すことで、被験者と採血との対応付けが行われる。

表示部／操作部１００４は、タイムテーブルや投薬準備指示通知、検査準備指示通知、アラートなどを表示する表示部と、表示画面の選択やＣＲＣ端末２２０の操作指示をする操作部とを有する。なお、表示部／操作部１００４は、タッチパネルであることが望ましい。

データ記憶部１００５は、データベースやアプリケーションプログラムを記憶する。例えば、ＣＲＣＩＤ、タイムテーブル、投薬準備指示通知、検査準備指示通知などのデータ、あるいは、測定機器１０３３が測定した生体情報などを各被験者に対応付けて記憶する。また、データ記憶部１００５は、治験で使用される使用資材情報１０５０を記憶し、ＣＲＣが検査準備をする場合の資材確認に使用される。

図１０Ｂは、本実施形態に係るＣＲＣ端末２２０を含む他の機能構成を示す図である。図１０ＢのＣＲＣ端末２２０は、例えば、被験者全体から血液を収集した複数の採血管１０１０を、同時に識別する構成を有する他は、図１０Ａと同様の構成であるので、重複する説明を省略する。

複数の採血管１０１０を同時に識別する構成は、複数の採血管１０１０の底部に貼られたＩＣタグ１０２１と、各ＩＣタグ１０２１に対応して配置されたＩＣタグリーダ１０３１とで構成される。また、複数の採血管１０１０の底部に貼られた二次元バーコードと、全二次元バーコードを識別可能に撮像できる高解像度カメラ１０３４とで構成される。

（使用資材情報）
図１０Ｃは、本実施形態に係るデータ記憶部１００５に記憶された使用資材情報１０５０の構成を示す図である。使用資材情報１０５０は、ＣＲＣが検査準備をする場合の資材確認のために使用される。

使用資材情報１０５０は、資材名１０５１、用途１０５２、治験での使用数１０５３との対応けられて、各資材ＩＤ１０５４と使用期限１０５５と対応する被験者ＩＤ１０５６とを記憶する。

＜ＣＲＣ端末の処理手順＞
図１０Ｄおよび図１０Ｅは、本実施形態に係るＣＲＣ端末の処理手順を示すフローチャートである。このフローチャートは、データ制御部１００１のＣＰＵがＲＡＭを使用して実行して、ＣＲＣ端末２２０の機能を実現する。

データ制御部１００１は、ステップＳ１０１１において、治験管理サーバ２１０から被験者情報とタイムテーブルとを含むＣＲＣ用のＣＲＣ治験情報を受信したか否かを判定する。ＣＲＣ治験情報を受信した場合、データ制御部１００１は、ステップＳ１０１３において、ＣＲＣ治験情報から被験者ＩＤおよび被験者情報を取得して保持する。そして、データ制御部１００１は、ステップＳ１０１５において、ＣＲＣ治験情報からタイムテーブルを取得して保持する。なお、ＣＲＣ治験情報は、ＣＲＣ端末２２０から治験管理サーバ２１０に要求して取得する構成であってもよい。

ＣＲＣ治験情報の受信でない場合、データ制御部１００１は、ステップＳ１０２１において、治験管理サーバ２１０から投薬準備タイミングの通知を受信したか否かを判定する。投薬準備タイミングの通知を受信した場合、データ制御部１００１は、ステップＳ１０２３において、投薬準備タイミングをＣＲＣに報知する。そして、データ制御部１００１は、ステップＳ１０２５において、投薬準備が完了したか否かを判定する。投薬準備が完了したと判定すると、データ制御部１００１は、ステップＳ１０２７において、投薬準備完了を治験管理サーバ２１０に通知する。一方、投薬準備が完了してないと判定すると、データ制御部１００１は、ステップＳ１０２９において、投薬準備タイミングからの経過時間が閾値（γ）より長いか否かを判定する。経過時間が閾値（γ）より長くない場合、データ制御部１００１は、ステップＳ１０２３に戻って、再度投稿準備タイミングを報知する。経過時間が閾値（γ）より長くなった場合、データ制御部１００１は、ステップＳ１０３１において、投薬準備においてエラーが発生したと判断して投薬準備未完のアラートを報知し、治験管理サーバ２１０に通知する。

ＣＲＣ治験情報の受信でなく投薬準備タイミングでもない場合、データ制御部１００１は、ステップＳ１０４１において、検査準備タイミングの通知を受信したか否かを判定する。検査準備タイミングの通知を受信した場合、データ制御部１００１は、ステップＳ１０４３において、検査準備タイミングをＣＲＣに報知する。そして、データ制御部１００１は、ステップＳ１０４５において、検査準備が完了したか否かを判定する。検査準備が完了したと判定すると、データ制御部１００１は、ステップＳ１０４７において、検査のために準備した資材が正しく使用可能期限内である、あるいは、資材数などを判定する。準備した資材がＯＫであれば、データ制御部１００１は、ステップＳ１０４９において、検査準備完了を治験管理サーバ２１０に通知する。一方、検査準備が完了してない、あるいは、資材ＯＫでないと判定すると、データ制御部１００１は、ステップＳ１０５１において、検査準備タイミングからの経過時間が閾値（δ）より長いか否かを判定する。経過時間が閾値（δ）より長くない場合、データ制御部１００１は、ステップＳ１０４３に戻って、再度検査準備タイミングを報知する。経過時間が閾値（δ）より長くなった場合、データ制御部１００１は、ステップＳ１０５３において、検査準備においてエラーが発生したと判断して検査準備未完のアラートを報知し、治験管理サーバ２１０に通知する。

データ制御部１００１は、ステップＳ１０５５において、ＣＲＣ端末２２０から治験管理サーバ２１０に通知する検査データが有るか否かを判定する。例えば、血液検査であれば、ＣＲＣ端末２２０から治験管理サーバ２１０に通知することになる。

検査データが有る場合、データ制御部１００１は、ステップＳ１０６１において、検査タイミングになるのを待つ。例えば、血液検査であれば、全被験者の採血が入った採血管が揃うのを待つ。検査タイミングになれば、データ制御部１００１は、ステップＳ１０６３において、検査データを取得したか否かを判定する。検査データを取得したら、データ制御部１００１は、ステップＳ１０６５において、検査データを保持する。そして、データ制御部１００１は、ステップＳ１０６７において、検査データが対応する被験者のものであるか否かを確認する。検査データが対応する被験者のものであれば、データ制御部１００１は、ステップＳ１０７１において、検査データを治験管理サーバ２１０に送信する。一方、検査データが対応する被験者のものでなければ、データ制御部１００１は、ステップＳ１０６３において、被験者確認におけるアラートを設定する。ステップＳ１０６３において、検査データを取得できなければ、データ制御部１００１は、ステップＳ１０７３において、治験の経過状況として検査タイミングからの経過時間が閾値（ε）より長いか否かを判定する。経過時間が閾値（ε）より長くない場合、データ制御部１００１は、ステップＳ１０６３に戻って、再度検査データの取得を待つ。経過時間が閾値（ε）より長くなった場合、データ制御部１００１は、ステップＳ１０７５において、検査においてエラーが発生したと判断して検査未完のアラートを報知し、治験管理サーバ２１０に通知する。

本実施形態によれば、複数の被験者における治験の進捗状態を効率的に管理することができる。例えば、複数の被験者それぞれに割り当てられた被験者端末に対して、タイムテーブルに従って投薬タイミングまたは検査タイミングの報知を指示し、被験者端末から被験者識別子に対応付けた投薬または検査の完了通知を取得して確認することで、効率的に投薬と検査とを管理することができる。また、ＣＲＣ端末に対して、投薬タイミングの前に投薬準備の報知を指示し、または、検査タイミングの前に検査準備を報知することによって、効率的に投薬と検査とを管理することができる。

また、複数の被験者の血液を採取する複数の採血管に対応する被験者識別子の採番を指示し、被験者識別子に基づいて、採取した血液が保持された複数の採血管と複数の被験者とを紐付けて、複数の被験者の少なくともいずれかの採血が完了していない場合に、ＣＲＣ端末に対してアラートを報知することで、採血のミスが発生しないように効率的に管理ができる。また、完了通知を投薬タイミングまたは検査タイミングの報知から所定時間内に取得できない場合、あるいは、被験者の検査結果が所定範囲内でない場合に、被験者端末に対してアラートを報知することにより、治験データの取得を効率的に管理できる。また、被験者端末に対するアラートの履歴に基づいて、被験者の治験が治験プロトコールの条件を満たさない場合に、治験中止指示部が被験者端末に治験中止を報知することによって、無駄な治験データの取得をなくして効率的に管理できる。

また、治験プロトコールに従って、複数の被験者への治験期間中の投薬および検査のタイムテーブルを生成するので、治験の進捗状態を管理するためのタイムテーブルを手動で作成する煩雑さがなくなる。また、治験プロトコールをチェックして修正指示をするので、間違いなく治験を管理することができる。

また、本実施形態によれば、治験プロトコールに対応して、被験者候補から被験者を選択する検査項目に対して重み付けをして、治験に適した順に選択された被験者を出力するので、治験に適した被験者を効率的に知ることができる。

さらに詳細には、電子カルテ収集データのうち、医師学的判断承認したデータのみを報告書に転送する。準備した資材（採血管、分注等）のメーカ、使用期限、数確認ができる。ベースラインからの変化率を算出して、自動でアラートが出せる。その変化率が、臨床的な範囲の変化率の範囲かを判断する。タイムテーブルの時刻に合わせて、担当者通知が出せる。なお、さらに、担当者の勤務情報を考慮した担当者の自動割当する、勤務時間から原価率算出して治験価格を算出する、治験価格の履歴集積から適正価格を算出することもできる。治験プロトコールを読みこめば、自動でタイムテーブルを作成できる。例えば、複数の治験プロトコールへ対応したタイムテーブルを作成できる。採血管と患者の認証をバーコードやＩＤ電子タグにより、一斉に実現できる。すなわち、タイムテーブルと連動した多数の採血管の使用期限などの確認ができる。

［第３実施形態］
次に、本発明の第３実施形態に係る治験管理装置としての治験管理サーバを含む治験管理システムについて説明する。本実施形態に係る治験管理システムは、上記第２実施形態と比べると、治験管理サーバが治験実施施設に設置されて治験管理を行う点で異なる。その他の構成および動作は、第２実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。

＜治験管理システムの構成＞
図１１は、本実施形態に係る治験管理サーバ１１１０を含む治験管理システム１１００の構成を示す図である。なお、図１１において、図２Ａと同様の構成要素には同じ参照番号を付して、重複する説明を省略する。

図１１において、治験管理サーバ１１１０は治験実施施設１１０１に設置されていて、治験実施施設１１０１内のＣＲＣ端末２２０や被験者端末２３０を直接に管理する。例えば、治験実施施設１１０１が病院内であれば、病院システムに治験管理サーバ１１１０の機能を搭載することで、簡単に本実施形態の治験管理機能を実現できる。

本実施形態によれば、簡単な治験管理機能を既存のシステムに搭載することで、治験の進捗状態を効率的に管理することができる。

［第４実施形態］
次に、本発明の第４実施形態に係る治験管理装置としての治験管理サーバを含む治験管理システムについて説明する。本実施形態に係る治験管理システムは、上記第２実施形態および第３実施形態と比べると、治験管理サーバがフェーズ２および３の治験を管理する点で異なる。その他の構成および動作は、第２実施形態または第３実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。

＜治験管理システム＞
以下、図１２から図１４を参照して、本実施形態の治験管理システムの構成および動作について説明する。

（動作概要）
図１２は、本実施形態に係る治験管理装置を含む治験管理システム１２００の動作概要を示す図である。図１２において、図２Ｂと同様の構成要素には同じ参照番号を付して、重複する説明を省略する。

フェーズ２や３の治験実施施設においては、治験実施記録１２１０と患者カルテ（電子カルテ）１２２０とが共存する。治験管理システム１２００の治験管理装置（治験管理サーバ）においては、治験実施記録１２１０と患者カルテ１２２０とを統合（マージ）して治験結果を生成し、治験依頼者に報告する。

（システム構成）
図１３は、本実施形態に係る治験管理装置１３１０を含む治験管理システム１２００の構成を示す図である。図１３において、図２Ａと同様の構成要素には同じ参照番号を付して、重複する説明を省略する。

治験管理システム１２００にいては、医療機関１３０１に、治験実施施設２０１と診察・医療施設１３０２とが存在する。診察・医療施設１３０２としては、電子カルテデータベース１３３０と、電子カルテデータベース１３３０に治験および診断結果を入力する看護師用の医療従事者端末１３２１と、医師１３２３が患者１３２４の治験および診断結果を入力する医師用の医療従事者端末１３２２と、を有する。また、治験管理サーバ１３１０は、治験データ／電子カルテ統合部１３１３を備える。また、治験管理サーバ１３１０には、治験管理者１３４１が操作する管理者端末１３４０が接続される。

（動作シーケンス）
図１４は、本実施形態に係る治験管理装置１３１０を含む治験管理システム１２００における動作手順を示すシーケンス図である。図１４において、図３Ａと同様の構成要素には同じ参照番号を付して、重複する説明を省略する。

治験管理サーバ１３１０は、ステップＳ１４０５において、電子カルテデータベース１３３０から患者のデータを読み出し、治験プロトコールの治験目的（治験対象）に適した被験者に識別子を取得する、あるいはスクリーニングにより被験者を選択する。なお、フェーズ２およびフェーズ３の患者からの被験者選択においては、電子カルテデータベース１３３０が検査項目記憶部として機能する。治験管理サーバ１３１０は、ステップＳ１４０７において、治験プロトコールに従って、電子カルテデータベース１３３０から被験者データを取得する。治験管理サーバ１３１０は、ステップＳ１４０９において、治験プロトコールに従って、電子カルテデータベース１３３０には無い治験データを特定する。

以下、ステップＳ３０７～Ｓ３１３において、図３Ａと同様の治験準備処理を実施する。また、ステップＳ３２１～Ｓ３３６において、医療従事者端末１３２０からの入力を電子カルテデータベース１３３０に格納する処理を含む、治験処理を実施する。治験管理サーバ１３１０は、ステップＳ１４１１において、治験プロトコールに従って、電子カルテと治験データを統合（マージ）する。

＜端末の評議画面例＞
以下、図１５Ａ～図１５Ｄを参照して、本治験管理システム１２００における端末の表示画面について説明する。

（医療従業者端末の表示画面）
図１５Ａは、本実施形態に係る医療従業者端末１３２０において治験を管理する表示画面を示す図である。

起動画面１５２１は、医療従業者端末１３２０におけるログイン用画面である。治験の試験一覧画面１５２２は、現在計画および実施中の試験を一覧表示する画面である。被験者一覧画面１５２３は、試験一覧画面１５２２で選択された試験の被験者を一覧表示する画面である。被験者画面１５２４は、被験者一覧画面１５２３で選択された被験者に関する治験情報を表示する画面である。

（医療従業者端末および管理者端末）
図１５Ｂは、本実施形態に係る医療従業者端末１３２０および管理者端末１３４０において治験結果を収集する表示画面を示す図である。なお、図１５Ａと同様の画面には同じ参照番号を付して、重複する説明を省略する。

管理者端末１３４０の治験管理画面１５４１は、医療従業者端末１３２０を管理しながら、治験結果を収集するための画面である。

（管理者端末の表示画面）
図１５Ｃは、本実施形態に係る管理者端末１３４０における治験結果を収集する表示画面を示す図である。管理者端末１３４０の治験管理画面１５４２および１５４３は、医療従業者端末１３２０からの治験結果を登録する表示画面を示す図である。

（治験依頼者端末の表示画面）
図１５Ｄは、本実施形態に係る治験依頼者端末２４０における治験結果を閲覧する表示画面を示す図である。治験依頼者端末２４０の治験閲覧画面１５４４は、治験中の治験結果を閲覧する画面である。

本実施形態によれば、フェーズ２や３の治験においても、フェーズ１と同様に複数の被験者における治験の進捗状態を効率的に管理することができる。

［第５実施形態］
次に、本発明の第５実施形態に係る治験管理装置としての治験管理サーバを含む治験管理システムについて説明する。本実施形態に係る治験管理システムは、上記第２実施形態から第４実施形態と比べると、治験管理サーバが治験プロトコールをチェックして訂正を管理する点で異なる。その他の構成および動作は、第２実施形態から第４実施形態と同様であるため、同じ構成および動作については同じ符号を付してその詳しい説明を省略する。

＜治験管理システムの動作シーケンス＞
図１６は、本実施形態に係る治験管理装置１６１０を含む治験管理システムにおける動作手順を示すシーケンス図である。なお、図１６において、図３Ａおよび図１４と同様のステップには同じステップ番号を付して、重複する説明を省略する。

治験管理サーバ１６１０は、ステップＳ１６０３において、取得した治験プロトコールをチェックして、基準フォーマットからの抜けやデータの間違い、データ範囲の逸脱などを治験依頼者端末２４０に通知する。治験依頼者端末２４０は、ステップＳ１６０４において、治験管理サーバ１６１０からの通知に応答して、訂正した治験プロトコールあるいは訂正箇所を送信する。このステップＳ１６０３とＳ１６０４とのやり取りを治験実施可能な治験プロトコールとなるまで繰り返す。

本実施形態によれば、治験実施可能な治験プロトコールを容易に生成することができる。

［他の実施形態］
上記実施形態においては、治験プロトコールに従って、タイムテーブルおよびワークフローを生成し、複数の治験者のそれぞれに割り当てられた治験者端末を用いて治験管理サーバが治験管理を行う治験処理について説明した。しかし、上記実施形態には記載されない種々の課題も存在し、以下に本治験管理システムでの解決方法についてさらに記載する。

図１７Ａおよび図１７Ｂは、他の実施形態に係る治験管理における課題および解決方法について示す図である。なお、図１７Ａおよび図１７Ｂでは、医療事業者である看護師および医師が利用する場合の課題と、ＣＲＣが利用する場合の課題をまとめた。

（医療事業者：看護師の場合）
・課題として、「紙なら素早くできる作業が、初期画面に戻って入力するため時間がかかる。（PCから入力が必要な実施項目が複数あった場合、どうしても画面遷移が必要になってしまう）」ことがある。解決方法として、次の表示画面のFormに移動するための遷移ボタンを作成する。
・課題として、「全員分入力できる画面にならなかったり、体温と呼吸の入力箇所が離れていたり等、実際の動きと画面が連携していない。（バイタルでも血圧・体温は別の画面で入力となっている）」ことがある。解決方法として、１つの画面で入力（取り込み）する。
・課題として、「間違えると初めからやり直し。（例えば「治験情報を入力していたが他のボタンを押してしまって画面遷移してしまった」場合等は全てやり直しになる）」ことがある。解決方法として、一時保存等の機能を設ける。
・課題として、「安全性の採血しかない時でも、無くてよいはずのPKやPD等の採血項目全てにNoを入力するため、余計な時間がかかる」ことがある。解決方法として、必要な項目のみ表示画面のFormを作成する。
・課題として、「同じ作業に対する画面の統一性がなく、記入漏れの原因になる」ことがある。１つの解決方法として、基本的な画面コンセプトを統一している。
・課題として、「紙資料も同時に必要な検査は、余計に時間がかかる」ことがある。解決方法として、紙が必要なものに関してシステム対応する。
・課題として、「検査の流れに沿ってログイン中の一人だけが入力していくようになっているため、エラー無く効率的に作業するための数人体制のフローが組めない」ことがある。解決方法として、タブレット入力では職員バーコードでログイン切り替えができる。PCにて行う工数管理等では、PC上でバーコードを用いたログイン者切り替え等を行う。
・課題として、「画面切り替えが遅い（次の画面までに時間がかかる）」ことがある。解決方法として、データ量に依存するので、データ量を考慮する。
・課題として、「数字入力だけなのに、毎回、数字と文字の入力切り替えが必要であ」ことがある。解決方法として、数字入力だけの場合には、数字入力に設定する。
・課題として、「時間がかかるため、人員を増やす必要がある。夜間の人員まで考慮すると、投与間隔を長くする必要があり、例えば、1分間隔を2分間隔にすると時間が倍かかる」ことがある。

（医療事業者：医師の場合）
・課題として、「紙なら一目で判断可能な検査なのに、１つ１つ判定を入力するため非常に時間がかかる。（紙だと、検査結果の右下に「問題なし」とサインしていただけのことが、システムだといちいち１つ１つの結果に「問題なし」と入力しなくてはいけないので不便である）」ことがある。解決方法として、臨床検査だけは一括で入力できるように工夫する。（あるいは、一ヵ所だけ「問題なし」とつければOK、のような機能をつける。）
・課題として、「問診、診察、処置などは人間相手であるため、電子カルテ以上の期待ができない」ことがある。解決方法として、電子カルテから治験データが抽出できる。
・課題として、「現実には分業で成り立っている作業に医師が全て立ち会って入力する必要がある（基準値からの逸脱は看護師が確認し、逸脱があれば医師を呼ぶなどの分業である）」ことがある。解決方法として、基準値からの逸脱は自動の検出されて、看護師や医師に報知される。

（ＣＲＣの場合）
・課題として、「DMベースで作成されているため（必要なデータのみ入力）、実際には同時に行っているプロセスの担保や再現性のための記録は含まれていない。ダブルチェック用の記録なども含め、結局別の記録が必要になる」ことがある。解決方法として、遠心分離機や保管等の管理も、バーコード読み込みで記録可能である。
・課題として、「複数のページを同時に開くことができないため、作業に時間がかかる。（前回の診察所見を確認しながら今回の診察ページを開けない。診察ページを見ながらＡＥページを入力したり、併用薬ページを入力したりすることが出来ず、保存とページ移動を繰り返すことになる）」ことがある。解決方法として、別タブを開くことは可能であり、システムとして過去のデータを見やすくする。
・課題として、「縦や横にかなり長いフォームが多く、スワイプしながらの入力となり時間がかかる」ことがある。解決方法として、１画面に納まるようにすれば入力・確認がしやすくなるので、表示する項目内容を絞る、あるいは、表示・非表示の選択をできるようにする。
・課題として、「除外基準に抵触するような内容や値を入力しても、チェック機能が設定されていない」ことがある。解決方法として、選定表にて感知できるだけでなく、捜査中には抵触有無は確認できるシステムとする。
・課題として、「文字が小さく見づらい」ことがある。既に改善されている。
・課題として、「その場での医師判定が必要な項目と、後日結果が出てから医師に判定してもらう項目が同じ個所に表示される」ことがある。解決方法として、当日に結果が出るもの・後日結果が出るものを色付け等でマークして判別可能とする。
・課題として、「被験者数が多い時などに反応がとても遅くなることがあり、実施のスピードに大きく影響する」ことがある。解決方法として、被験者数が多い場合の処理を考慮する。
・さらに、システム全体として、「実際の処置や判断に加え、入力操作や処理に追加の作業として時間がとられてしまう」との課題がある。解決方法として、実際の処置や判断を支援することで、全体の処理時間を削減する。

以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の技術的範囲で当業者が理解し得る様々な変更をすることができる。また、それぞれの実施形態に含まれる別々の特徴を如何様に組み合わせたシステムまたは装置も、本発明の技術的範囲に含まれる。

また、本発明は、複数の機器から構成されるシステムに適用されてもよいし、単体の装置に適用されてもよい。さらに、本発明は、実施形態の機能を実現する治験管理プログラムとしての情報処理プログラムが、システムあるいは装置に供給され、内蔵されたプロセッサによって実行される場合にも適用可能である。本発明の機能をコンピュータで実現するために、コンピュータにインストールされるプログラム、あるいはそのプログラムを格納した媒体、そのプログラムをダウンロードさせるサーバも、プログラムを実行するプロセッサも本発明の技術的範囲に含まれる。特に、少なくとも、上述した実施形態に含まれる処理ステップをコンピュータに実行させるプログラムを格納した非一時的コンピュータ可読媒体（non-transitory computer readable medium）は本発明の技術的範囲に含まれる。

Claims (11)

1. 治験プロトコールを解析し、複数の被験者への治験期間中の投薬および検査のタイムテーブルを生成する治験プロトコール解析部と、
   前記複数の被験者の被験者識別子を取得する被験者識別子取得部と、
   前記複数の被験者それぞれに割り当てられた被験者端末に対して、前記タイムテーブルに従って投薬タイミングまたは検査タイミングの報知を指示し、前記被験者端末から被験者識別子に対応付けた当該投薬または当該検査の完了通知を取得して確認する投薬および検査確認部と、
   前記複数の被験者の投薬および検査データを取得し、前記被験者識別子それぞれに紐付けて投薬履歴および検査履歴を格納する治験履歴格納部と、
   を備える治験管理装置。
2. 治験を担当する治験コーディネータ（ＣＲＣ:Clinical Research Coordinator）に割り当てられたＣＲＣ端末に対して前記タイムテーブルを送信するタイムテーブル送信部と、
   前記ＣＲＣ端末に対して、前記投薬タイミングの前に投薬準備を通知し、または、前記検査タイミングの前に検査準備を通知する準備通知部と、
   をさらに備え、
   前記治験履歴格納部は、前記被験者端末から取得した第１検査データと前記ＣＲＣ端末から取得した第２検査データとを前記被験者識別子により紐付けて、前記被験者の検査データとして取得する請求項１に記載の治験管理装置。
3. 前記準備通知部は、前記複数の被験者の血液を採取する複数の採血管に対応する前記被験者識別子の採番を通知し、
   前記治験履歴格納部は、前記被験者識別子に基づいて、採取した血液が保持された前記複数の採血管と前記複数の被験者とを紐付け、
   前記複数の被験者の少なくともいずれかの採血が完了していない場合に、前記ＣＲＣ端末に対してアラートを報知する第１アラート報知部をさらに備える請求項２に記載の治験管理装置。
4. 前記完了通知を前記投薬タイミングまたは前記検査タイミングの報知から所定時間内に取得できない場合、あるいは、前記被験者の検査結果が所定範囲内でない場合に、前記被験者端末に対してアラートを報知する第２アラート報知部をさらに備える請求項１から３のいずれか１項に記載の治験管理装置。
5. 前記被験者端末に対するアラート履歴に基づいて、前記被験者の治験が前記治験プロトコールの条件を満たさない場合に、前記被験者端末に治験中止を指示する治験中止指示部をさらに備える請求項４に記載の治験管理装置。
6. 治験期間中に、治験依頼者端末から治験履歴の閲覧要求を受信した場合に、前記治験履歴格納部に格納された前記被験者への投薬履歴および前記被験者の検査履歴の閲覧画面を前記治験依頼者端末に返信する閲覧画面送信部と、
   前記治験の経過状況が、前記治験プロトコールを満たさなくなった場合に、前記治験依頼者端末に対してアラートを報知する第３アラート報知部と、
   をさらに備える請求項１から５のいずれか１項に記載の治験管理装置。
7. 前記複数の被験者それぞれに紐付いた前記被験者への投薬履歴および前記被験者の検査履歴の中から、治験依頼者への治験報告書に含まれることを承認された前記投薬履歴および前記検査履歴に基づいて、前記治験依頼者に応じたフォーマットの治験報告書を生成する治験報告書生成部をさらに備える請求項１から６のいずれか１項に記載の治験管理装置。
8. 前記被験者識別子取得部は、
   治験の被験者候補と、当該被験者候補を被験者として選択する複数の検査項目とを対応付けて記憶する検査項目記憶部と、
   前記治験プロトコールに従って、治験の対象となる条件を満たす複数の被験者を前記検査項目記憶部に記憶された前記被験者候補から選択する被験者選択部と、
   を備え、
   前記被験者選択部は、前記複数の検査項目のうち前記条件となる検査項目に重みを付けて加算し、被験者として適切な順序を出力する請求項１から７のいずれか１項に記載の治験管理装置。
9. 治験プロトコールを解析し、複数の被験者への治験期間中の投薬および検査のタイムテーブルを生成する治験プロトコール解析ステップと、
   前記複数の被験者の被験者識別子を取得する被験者識別子取得ステップと、
   前記複数の被験者それぞれに割り当てられた被験者端末に対して、前記タイムテーブルに従って投薬タイミングまたは検査タイミングの報知を指示し、前記被験者端末から被験者識別子に対応付けた当該投薬または当該検査の完了通知を取得して確認する投薬および検査確認ステップと、
   前記複数の被験者の投薬および検査データを取得し、前記被験者識別子それぞれに紐付けて投薬履歴および検査履歴を格納する治験履歴格納ステップと、
   を含む治験管理方法。
10. 治験プロトコールを解析し、複数の被験者への治験期間中の投薬および検査のタイムテーブルを生成する治験プロトコール解析ステップと、
    前記複数の被験者の被験者識別子を取得する被験者識別子取得ステップと、
    前記複数の被験者それぞれに割り当てられた被験者端末に対して、前記タイムテーブルに従って投薬タイミングまたは検査タイミングの報知を指示し、前記被験者端末から被験者識別子に対応付けた当該投薬または当該検査の完了通知を取得して確認する投薬および検査確認ステップと、
    前記複数の被験者の投薬および検査データを取得し、前記被験者識別子それぞれに紐付けて投薬履歴および検査履歴を格納する治験履歴格納ステップと、
    をコンピュータに実行させる治験管理プログラム。
11. 治験の対象である複数の被験者それぞれに割り当てられた複数の被験者端末と、
    治験プロトコールに従って、前記複数の被験者端末における前記治験の実施を管理する治験管理装置と、
    を備える治験管理システムであって、
    前記治験管理装置は、
    前記治験プロトコールを解析し、前記複数の被験者への治験期間中の投薬および検査のタイムテーブルを生成する治験プロトコール解析部と、
    前記複数の被験者の被験者識別子を取得する被験者識別子取得部と、
    前記複数の被験者端末に対して、前記タイムテーブルに従って投薬タイミングまたは検査タイミングの報知を指示し、前記複数の被験者端末から被験者識別子に対応付けた当該投薬または当該検査の完了通知を取得して確認する投薬および検査確認部と、
    前記複数の被験者の投薬および検査データを取得し、前記被験者識別子それぞれに紐付けて投薬履歴および検査履歴を格納する治験履歴格納部と、
    を有する治験管理システム。

Images