(57)【要約】【課題】複数の依頼元からの臨床研究プロジェクトが同時進行した場合の研究担当者の業務負担増を抑制する。【解決手段】臨床研究情報クラウドサービスシステム１は、臨床研究プロジェクトそれぞれに対応するように設けられ、研究担当者が使用する研究者端末２に接続された複数のアプリケーションサーバ１０と、臨床研究プロジェクトの依頼元で用いられている研究依頼元システム３それぞれに対応するように接続された複数のデータ授受サーバ３０と、データ授受サーバ３０およびアプリケーションサーバ１０の両方に接続され、研究依頼元システム３ごとに定められた通信データの構成と、複数のアプリケーションサーバ１０で共通に用いられる通信データの構成と、を互いに対応付けるメタデータにより、データ授受サーバ３０とアプリケーションサーバ１０との間で送受信される通信データの構成を相互に変換するデータ変換サーバ２０と、を備えて構成される。【選択図】図１
2017097417.tif 000002
【特許請求の範囲】
【請求項１】
複数の臨床研究プロジェクトそれぞれに対応するように設けられ、前記臨床研究プロジェクトの研究担当者によって使用される研究者端末に通信ネットワークを介して接続される複数のアプリケーションサーバと、
前記複数の臨床研究プロジェクトそれぞれの依頼元で用いられている複数の研究依頼元システムそれぞれに対応するように接続される複数のデータ授受サーバと、
前記複数のデータ授受サーバおよび前記複数のアプリケーションサーバの両方に接続され、前記複数の研究依頼元システムごとにそれぞれ定められた通信データの構成と、前記複数のアプリケーションサーバで共通に用いられる通信データの構成と、を互いに対応付けるメタデータを有し、前記メタデータを参照することにより、前記データ授受サーバと前記アプリケーションサーバとの間で送受信される通信データの構成を相互に変換するデータ変換サーバと、
を備えて構成されること
を特徴とする臨床研究情報クラウドサービスシステム。
【請求項２】
前記アプリケーションサーバは、
前記臨床研究プロジェクトの依頼元の前記研究依頼元システムから前記臨床研究プロジェクトに属する前記研究担当者宛てに送信された情報を、前記データ授受サーバおよび前記データ変換サーバを経由した情報として受信し、前記受信した情報を表示する画面の表示情報を前記研究者端末に提供すること
を特徴とする請求項１に記載の臨床研究情報クラウドサービスシステム。
【請求項３】
前記データ変換サーバは、
前記研究依頼元システムから前記アプリケーションサーバへ送信される情報を、前記複数のアプリケーションサーバで共通に用いられる情報種別に分類すること
を特徴とする請求項２に記載の臨床研究情報クラウドサービスシステム。
【請求項４】
前記アプリケーションサーバは、
前記研究者端末を介して、予めユーザ登録された研究担当者がログインする入力を受付けたときには、その時点までに受信した前記研究依頼元システムから前記研究担当者宛ての情報の概要を、前記情報種別ごとに分類して表示した画面の表示情報を、前記研究者端末に提供すること
を特徴とする請求項３に記載の臨床研究情報クラウドサービスシステム。
【請求項５】
前記アプリケーションサーバは、
予めユーザ登録された複数の研究担当者間で共有される文書を記憶した記憶部を有し、
前記記憶部を参照し、前記ログインした研究担当者が他の研究担当者との間で共有している文書のタイトルのリストを表示した画面の表示情報を、前記研究者端末に提供すること
を特徴とする請求項４に記載の臨床研究情報クラウドサービスシステム。
【請求項６】
複数の臨床研究プロジェクトそれぞれに対応するように設けられ、前記臨床研究プロジェクトの研究担当者によって使用される研究者端末に通信ネットワークを介して接続される複数のアプリケーションサーバと、
前記複数の臨床研究プロジェクトそれぞれの依頼元で用いられている複数の研究依頼元システムそれぞれに対応するように接続される複数のデータ授受サーバと、
前記複数のデータ授受サーバおよび前記複数のアプリケーションサーバの両方に接続され、前記複数の研究依頼元システムごとにそれぞれ定められた通信データの構成と、前記複数のアプリケーションサーバで共通に用いられる通信データの構成と、を互いに対応付けるメタデータを有し、前記メタデータを参照することにより、前記データ授受サーバと前記アプリケーションサーバとの間で送受信される通信データの構成を相互に変換するデータ変換サーバと、
を備えて構成された臨床研究情報クラウドサービスシステムにおける臨床研究情報クラウドサービス方法であって、
前記アプリケーションサーバは、
前記臨床研究プロジェクトの依頼元の前記研究依頼元システムから前記臨床研究プロジェクトに属する前記研究担当者宛てに送信された情報を、前記データ授受サーバおよび前記データ変換サーバを経由した情報として受信し、前記受信した情報を表示する画面の表示情報を前記研究者端末に提供すること
を特徴とする臨床研究情報クラウドサービス方法。
【請求項７】
前記データ変換サーバは、
前記研究依頼元システムから前記アプリケーションサーバへ送信される情報を、前記複数のアプリケーションサーバで共通に用いられる情報種別に分類すること
を特徴とする請求項６に記載の臨床研究情報クラウドサービス方法。
【請求項８】
前記アプリケーションサーバは、
前記研究者端末を介して、予めユーザ登録された研究担当者がログインする入力を受付けたときには、その時点までに受信した前記研究依頼元システムから前記研究担当者宛ての情報の概要を、前記情報種別ごとに分類して表示した画面の表示情報を、前記研究者端末に提供すること
を特徴とする請求項７に記載の臨床研究情報クラウドサービス方法。
【請求項９】
前記アプリケーションサーバは、
予めユーザ登録された複数の研究担当者間で共有される文書を記憶した記憶部を有し、
前記記憶部を参照し、前記ログインした研究担当者が他の研究担当者との間で共有している文書のタイトルのリストを表示した画面の表示情報を、前記研究者端末に提供すること
を特徴とする請求項８に記載の臨床研究情報クラウドサービス方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、臨床研究業務を支援する臨床研究情報クラウドサービスシステムおよび臨床研究情報クラウドサービス方法に関する。
【背景技術】
【０００２】
新薬や医療機器の治験などを含む臨床研究は、医療研究機関、病院、医薬品メーカ、医療機器メーカなどにより共同で実施される。このような臨床研究を効率よく円滑に遂行するには、その臨床研究参加者の間で様々な情報を共有する必要がある。そこで、例えば、日本医師会は、治験などの情報を共有し、臨床研究の効率向上を図るツールとして、カット・ドゥ・スクエアと呼ばれるクラウド型治験業務支援システムを提供している（非特許文献１参照）。このカット・ドゥ・スクエア・システムでは、臨床研究の依頼者である医薬品メーカや医療機器メーカ、臨床研究の実施者である研究機関や病院、さらには、臨床研究の被験者などの間での文書作成の形式を統一化するとともに、作成された文書を共有して管理することなどがサポートされる。
【０００３】
また、特許文献１には、医療研究機関や病院などにおいて治験を効率よく実施するための治験管理システムの例が開示されている（図１など参照）。この治験管理システムでは、ネットワークを介して相互に接続された治験依頼サーバ１、治験実施サーバ２および実施機関サーバ３，４，５により、治験に関わる医師や治験コーディネータなどの多岐にわたる業務がサポートされている。当然ではあるが、そのサポート業務には、治験の依頼者、医師、治験コーディネータ間での情報の授受管理、文書管理などが含まれている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−２１５８２０号公報
【非特許文献】
【０００５】
【非特許文献１】“カット・ドゥ・スクエア”、［online］、日本医師会治験促進センター、［平成２７年１０月２０日検索］、インターネット＜ＵＲＬ：http://www. jmacct.med.or.jp/cds/apply.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、治験などの臨床研究は、大規模な医療研究機関や総合病院だけでなく、街中の小さな病院も巻き込んで実施されることが多い。大規模な医療研究機関や総合病院であれば、特許文献１に開示されたような治験管理システムを導入することにより、研究者や医師や治験コーディネータの業務負担を減らすことができる。しかしながら、そのような治験管理システムの導入や導入後の運用には、相当額のコストが掛かり、小さな病院では、そのコストに耐え得るとは限らない。
【０００７】
そこで、治験依頼元などが有する治験管理システムの端末を小さな病院に貸し出すようにし、この問題の解決を図ることは可能である。しかしながら、小さな病院といえども、複数の治験依頼元からの治験実施の依頼を受けていることは少なくない。そのような場合、小さな病院は、治験依頼元ごとに異なる治験管理システムの端末をそれぞれ個別に導入することとなり、その病院の医師や治験コーディネータは、その複数の端末の操作方法に別々に習熟しなければならない。これは、医師や治験コーディネータにとって大きな負担となる。
【０００８】
日本医師会が提供するカット・ドゥ・スクエアは、インターネットに接続された一般的なパソコンがあれば利用でき、しかも、その利用料金は無料となっている。また、カット・ドゥ・スクエアでは、予め登録された統一書式に従って作成された文書や情報に限られるにせよ、その文書の作成が簡単にでき、その作成した文書を特定の治験プロジェクトの研究担当者同士で共有することができる。これなら、小さな病院の医師や治験コーディネータでも安心して利用することができる。
【０００９】
しかしながら、カット・ドゥ・スクエアの主たる機能は、統一書式に従った文書の作成とその作成された文書の管理にある。そのため、臨床研究の担当者が臨床研究一般の中で日々発生する様々な情報を、とくに研究依頼元との間で共有するための機能のサポートは十分とはいえない。そのため、とくに複数の依頼元からの臨床研究を担当する小さな病院の医師や治験コーディネータにとって、十分な業務効率向上をカット・ドゥ・スクエアに期待することはできない。
【００１０】
一般に、治験などの臨床研究は、複数の依頼元（医薬品メーカなど）からの臨床研究案件が同時進行の形で実施される。このような場合、医師、薬剤師、研究コーディネータなどの臨床研究の担当者は、同種の情報であっても、研究依頼元によって異なる形式の文書を受け取り、異なる形式で報告文書を作成する必要がある。このような状況は、臨床研究の担当者にとって大きな負担となり、研究業務の効率向上が阻害される。
【００１１】
本発明は、以上のような従来技術の課題に鑑みてなされたものであり、その目的は、複数の依頼元からの臨床研究プロジェクトが同時進行した場合であっても、その研究担当者の業務負担増を抑制することが可能な臨床研究情報クラウドサービスシステムおよび臨床研究情報クラウドサービス方法を提供することにある。
【課題を解決するための手段】
【００１２】
本発明に係る臨床研究情報クラウドサービスシステムは、複数の臨床研究プロジェクトそれぞれに対応するように設けられ、前記臨床研究プロジェクトの研究担当者によって使用される研究者端末に通信ネットワークを介して接続される複数のアプリケーションサーバと、前記複数の臨床研究プロジェクトそれぞれの依頼元で用いられている複数の研究依頼元システムそれぞれに対応するように接続される複数のデータ授受サーバと、前記複数のデータ授受サーバおよび前記複数のアプリケーションサーバの両方に接続され、前記複数の研究依頼元システムごとにそれぞれ定められた通信データの構成と、前記複数のアプリケーションサーバで共通に用いられる通信データの構成と、を互いに対応付けるメタデータを有し、前記メタデータを参照することにより、前記データ授受サーバと前記アプリケーションサーバとの間で送受信される通信データの構成を相互に変換するデータ変換サーバと、を備えて構成されることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、複数の依頼元からの臨床研究プロジェクトが同時進行した場合であっても、その研究担当者の業務負担増を抑制することが可能な臨床研究情報クラウドサービスシステムおよび臨床研究情報クラウドサービス方法が提供される。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に係る臨床研究情報クラウドサービスシステムの全体構成の例を示した図。
【図２】本発明の実施形態に係る臨床研究情報クラウドサービスシステムにおけるアプリケーションサーバの構成の例を示した図。
【図３】アプリケーションサーバにより研究者端末に表示されるログインページの例を示した図。
【図４】ログイン後の研究者端末に表示されるランディングページの例を示した図。
【図５】文書アップロードページの例を示した図。
【図６】研究依頼元システムから研究者端末に向けてアップロード依頼情報が発信されたときの情報処理の流れの例を示した図。
【図７】研究依頼元システムから研究者端末に向けて文書承認依頼情報が発信されたときの情報処理の流れの例を示した図。
【図８】研究依頼元システム３から研究者端末に向けて企業からのご案内情報が発信されたときの情報処理の流れの例を示した図。
【発明を実施するための形態】
【００１５】
以下、本発明の実施形態について、図面を参照して詳細に説明する。なお、各図面において、共通する構成要素には同一の符号を付し、重複した説明を省略する。
【００１６】
図１は、本発明の実施形態に係る臨床研究情報クラウドサービスシステム１の全体構成の例を示した図である。図１に示すように、臨床研究情報クラウドサービスシステム１は、アプリケーションサーバ１０とデータ変換サーバ２０とデータ授受サーバ３０とを含んで構成される。ここで、研究者端末２とは、臨床研究の担い手である研究者、医師、薬剤師、研究コーディネータなど（以下、研究担当者と総称する）が使用する一般的なパソコンなどをいう。また、研究依頼元システム３とは、所定のテーマについての臨床研究の依頼元である医薬品メーカや医療機器メーカの社内に導入されている臨床研究サポートのためのシステムをいう。
【００１７】
アプリケーションサーバ１０は、通信ネットワーク４ａを介して複数の研究者端末２に接続され、研究者端末２の表示装置に表示するＷＥＢブラウザ画面を介して、臨床研究に関連する研究者の業務をサポートする。すなわち、アプリケーションサーバ１０は、所定のテーマの臨床研究（以下、研究プロジェクトという）の研究依頼元からの研究担当者への情報伝達をサポートし、研究依頼元と研究担当者の間の意思疎通を円滑化させる。また、同じ研究プロジェクトに属する研究担当者間での情報や文書の共有化をサポートし、業務効率を向上させる。
【００１８】
そこで、アプリケーションサーバ１０は、原則として、１つの研究プロジェクトごとに１つ設けられる。一方、アプリケーションサーバ１０が研究者端末２に提供する機能は、研究プロジェクトが異なっても同じであるものとする。すなわち、研究者端末２に表示されるＷＥＢブラウザ画面の基本的な構成は、研究プロジェクトに依存せず同じであるとする。なお、研究者端末２に表示されるＷＥＢブラウザ画面の例については、別途図面を参照して説明する。
【００１９】
また、アプリケーションサーバ１０は、記憶部１１を有し、その記憶部１１には、対応する研究プロジェクトの全体やグループごとに研究担当者が共有すべき情報や文書などが保管される。なお、記憶部１１には、それぞれの研究担当者が独自に作成し、他人と共有しないようにした文書、例えば作成途中の文書などが保管されてもよい。
【００２０】
研究担当者は、研究者端末２を介して、それぞれの研究プロジェクトに対応付けられたアプリケーションサーバ１０にログインすることにより、研究プロジェクトごとに共有された情報や文書にアクセスすることができる。このとき、研究担当者は、通信ネットワーク４ａに接続されている研究者端末２であれば、いずれの研究者端末２であっても使用することができる。そのため、研究担当者は、複数の研究プロジェクトに同時に参加しても同一の研究者端末２（自分専用のパソコンなど）を使用することができる。しかも、研究プロジェクトが異なっても、同様の表示画面で同様の操作で使用することができる。
【００２１】
データ授受サーバ３０は、通信ネットワーク４ｂを介して研究依頼元に導入されている研究依頼元システム３に接続されるとともに、データ変換サーバ２０に接続されている。このデータ授受サーバ３０は、研究依頼元システム３から送信される情報を受信してデータ変換サーバ２０へ転送するとともに、データ変換サーバ２０から転送される情報を研究依頼元システム３へ送信する。
【００２２】
ここで、複数の研究依頼元システム３が存在する場合、それぞれの１つの研究依頼元システム３に対応させて１つのデータ授受サーバ３０が設けられる。そのため、それぞれのデータ授受サーバ３０は、研究依頼元システム３で定められた通信手順やその通信手順に合わせてデータの送受信をすることができる。
【００２３】
なお、データ授受サーバ３０は、記憶部３１を有し、記憶部３１には、研究依頼元システム３およびデータ変換サーバ２０との間のデータ送受信に際し、送受信されるデータが一時記憶される。
【００２４】
データ変換サーバ２０は、アプリケーションサーバ１０とデータ授受サーバ３０との間にあって、両者間での通信データの送受信を仲介するとともに、両者間で送受信される通信データの構成を変換する。ここで、通信データ構成の変換とは、データ変換サーバ２０とデータ授受サーバ３０（すなわち、研究依頼元システム３）との間で送受信される通信データの構成と、データ変換サーバ２０とアプリケーションサーバ１０との間で送受信される通信データの構成を互いに対応づけて、相互に変換することをいう。
【００２５】
一般に、パケットとか、フレームなどと呼ばれる通信データには、その通信データの送信元、送信先、情報種別などが含まれ、さらに、本実施形態では、研究プロジェクト名、研究担当者名なども含まれる。そして、一般には、研究依頼元システム３が違えば、通信データの中にこのような情報がどのような順番で配置されているかも、また、それぞれがどのようなビット構成（バイト構成）となっているかも同じであるとは限らない。
【００２６】
そこで、本実施形態では、データ変換サーバ２０は、複数の研究依頼元システム３それぞれとの間で互いに相違する通信データの構成を、複数のアプリケーションサーバ１０で共通に用いられる通信データの構成に変換する。この変換をするために、データ変換サーバ２０の記憶部１１には、いわゆるメタデータが記憶されている。データ変換サーバ２０は、メタデータを参照することにより両者の間での通信データの構成を変換する。
【００２７】
さらに、データ変換サーバ２０は、複数のデータ授受サーバ３０を介して受信した複数の研究依頼元システム３からの通信データを、その構成を変換した上で送信先となるアプリケーションサーバ１０へ送信する。同様に、データ変換サーバ２０は、複数のアプリケーションサーバ１０からの通信データを、その構成を変換した上で送信先となる研究依頼元システム３に対応づけられたデータ授受サーバ３０へ送信する。
【００２８】
なお、図１では、通信ネットワーク４は、研究者端末２が接続された通信ネットワーク４ａと研究依頼元システム３が接続された通信ネットワーク４ｂとが切り離されて描かれているが、これらは互いにつながったものであってもよい。すなわち、通信ネットワーク４ａ，４ｂは、インターネットなどの一部であってもよい。
【００２９】
また、図１に示したような臨床研究情報クラウドサービスシステム１を構成するアプリケーションサーバ１０、データ変換サーバ２０およびデータ授受サーバ３０は、専用の通信線やインターネットなどを介して互いに接続された複数のコンピュータによって実現することができる。その場合、複数のアプリケーションサーバ１０や複数のデータ授受サーバ３０の一部または全部が１つのコンピュータによって実現されるものであってもよく、さらには、アプリケーションサーバ１０、データ変換サーバ２０およびデータ授受サーバ３０の全部が１つのコンピュータによって実現されたものであってもよい。
【００３０】
図２は、本発明の実施形態に係る臨床研究情報クラウドサービスシステム１におけるアプリケーションサーバ１０の構成の例を示した図である。図２に示すように、アプリケーションサーバ１０は、フロントエンド処理部１３とバックエンド処理部１２と記憶部１１とを含んで構成される。
【００３１】
フロントエンド処理部１３は、主として、通信ネットワーク４ａを介して接続される研究者端末２に対する画面表示およびその表示された画面から入力されるデータの入力を制御する。また、フロントエンド処理部１３は、データ変換サーバとの間の通信データの送受信を制御する。バックエンド処理部１２は、アプリケーションサーバ１０の機能を実現するための機能ブロックとして、ユーザ認証部１２１、文書管理部１２２、ワークフロー管理部１２３、通知サービス管理部１２４などを含んで構成される。
【００３２】
ユーザ認証部１２１は、研究プロジェクトの研究担当者が当該アプリケーションサーバ１０へユーザ登録するのをサポートする。また、ユーザがアプリケーションサーバ１０にログインするときには、そのユーザが登録された正規のユーザであるか否かを認証する。なお、ユーザ登録されたユーザに関するユーザＩＤやパスワードに関する情報は、事前にユーザ情報記憶部１１１に格納される。
【００３３】
文書管理部１２２は、当該アプリケーションサーバ１０の文書記憶部１１２に格納される文書を管理する。このとき、文書は、基本的には、ユーザごとに管理されるとともに、研究プロジェクトのメンバ全員に公開可能な文書、研究プロジェクト内でグループ化されたグループメンバに公開可能な文書などに分類されて管理される。
【００３４】
ワークフロー管理部１２３は、各種のタスクや文書の作成、レビュー、承認などについて、担当者、期限、進行状況などを管理するとともに、期限に近付いた場合には、適宜、その旨を担当者に通知する。なお、ワークフロー管理部１２３で管理される情報は、ワークフロー情報記憶部１１３に格納される。
【００３５】
通知サービス管理部１２４は、主として研究依頼元システム３から通知される様々な通知情報を指定されたユーザ（研究担当者）に通知するとともに、それが閲覧された場合には、閲覧されたことを示す情報を送信元（研究依頼元システム３）に返送する。通知情報は、通知情報記憶部１１４に記憶され、例えば、ユーザがアプリケーションサーバ１０にログインしたときに、そのユーザが使用中の研究者端末２に表示される。なお、通知情報の種類としては、特定の研究担当者宛てのもの、特定のグループのメンバ宛のもの、研究プロジェクト全員宛のものなどがある。
【００３６】
図３は、アプリケーションサーバ１０により研究者端末２に表示されるログインページ５１の例を示した図である。ユーザ（研究担当者）は、担当する研究プロジェクトに対応付けられたアプリケーションサーバ１０にログインするときには、研究者端末２から図３に示すようなログインページ５１にアクセスする。
【００３７】
このログインページ５１には、当該アプリケーションサーバ１０に対応付けられている研究プロジェクトの研究依頼元および研究プロジェクト名がそれぞれ表示され、さらに、ユーザがユーザＩＤおよびパスワードを入力するための入力ボックス５１１，５１２が表示される。
【００３８】
そこで、ユーザが入力ボックス５１１，５１２にユーザＩＤおよびパスワードを入力し、「ＯＫ」ボタン５１３をクリックすると、ユーザ認証部１２１は、その入力されたユーザＩＤおよびパスワードが登録済の正規のユーザであるか否かを判定する。その判定の結果、入力されたユーザＩＤおよびパスワードが登録済の正規のユーザであった場合には、アプリケーションサーバ１０は、ランディングページ５２（図４参照）を表示する。
【００３９】
なお、このログインページ５１において、「キャンセル」ボタン５１４がクリックされると、ログインページ５１は閉じられる。また、「ユーザ登録ボタン」５１５がクリックされると、研究者端末２には、新たにユーザ登録ページ（図示省略）が表示される。
【００４０】
図４は、ログイン後の研究者端末２に表示されるランディングページ５２の例を示した図である。図４に示すように、ランディングページ５２には、例えば、「文書管理」表示窓５２１、「タスク」表示窓５２２、「お知らせ」表示窓５２３および「企業からのご案内」表示窓５２４が表示される。このように、ランディングページ５２には、ユーザが知りたい情報が、まず、簡明に網羅的に表示される。
【００４１】
ここで、「文書管理」表示窓５２１には、文書管理部１２２で管理されている文書に関する情報が表示される。その表示方法は、一般的なパソコンなどで用いられている表示方法と同様のものであり、フォルダの階層構成が表示されるとともに、選択されたフォルダについては、そのフォルダに含まれる文書の文書名、文書の変更日（作成日）などのリストが表示される。加えて、本実施形態では、それぞれの文書についてワークフロー管理部１２３で管理されている文書の作成済、レビュー済、承認済などの情報が、そのそれぞれの文書のリストに付属する形で表示される。
【００４２】
さらに、本実施形態では、各文書に付したメタデータによりワークフローの状態（作成済、レビュー済、承認済などの状態）をフォルダとみなし、それぞれの状態に属する文書のリストを表示することもできる。この場合、「文書管理」表示窓５２１には、例えば、「ＡＡＡ試験」のフォルダの下位のフォルダとして「作成済」、「レビュー済」、「承認済」などのフォルダが表示される。そして、その下位のフォルダの、例えば、「作成済」が選択されると、「ＡＡＡ試験」のフォルダに属する文書のうち、ワークフローの状態が「作成済」の文書のリストが表示される。なお、このようなワークフローの状態をフォルダとみなした文書の表示は、メタデータの組み合わせで、複数階層のいずれの階層のフォルダに対しても可能である。
【００４３】
「タスク」表示窓５２２には、ワークフロー管理部１２３で管理されている情報（以下、タスク情報という）のうち、期限が迫っているタスク情報が表示され、とくに重要なものについては、太字や赤字など目立つように表示される。なお、タスクの種類としては、文書のアップロード依頼、レビュー依頼、承認依頼、確認依頼などがある。
【００４４】
「お知らせ」表示窓５２３には、通知サービス管理部１２４で管理されている通知情報のうち、ログイン中の研究担当者宛て、ログイン中の研究担当者が属するグループのメンバ宛ておよび研究プロジェクト全員宛ての通知情報が表示される。なお、通知情報は、主として研究依頼元システム３から発信されるが、他の研究担当者が研究者端末２を介して発信した情報であってもよい。
【００４５】
「企業からのご案内」表示窓５２４には、通知サービス管理部１２４で管理されている通知情報のうち一般的な通知情報が表示される。ここで、一般的な通知情報とは、研究依頼元からの通知される、必ずしも当該研究プロジェクトに関係があるとはいえないような情報、例えば、新たな研究プロジェクトのメンバ募集などの通知情報をいう。なお、この「企業からのご案内」の表示窓５２４には、当該研究プロジェクトに依頼元以外の他の企業から発信された情報が含まれてもよい。
【００４６】
ここで、「タスク」表示窓５２２、「お知らせ」表示窓５２３および「企業からのご案内」表示窓５２４に表示された各情報については、ユーザがその１つを選択してクリックすることができる。そこで、ユーザがその１つを選択してクリックすると、新たな表示窓（例えば、図５参照）が表示され、その表示窓には、前記クリックされた情報に関するさらに詳細な情報が表示される。
【００４７】
図５は、文書アップロードページ５３の例を示した図である。ランディングページ５２の「タスク」表示窓５２２でアップロード依頼の情報がクリックされると、図５に示すような文書アップロードページ５３が表示される。この文書アップロードページ５３では、ランディングページ５２で表示されていた「文書管理」表示窓５２１が消去され、代わりに「アップロード依頼」表示窓５３１が表示される。
【００４８】
「アップロード依頼」表示窓５３１には、デフォルトのアップロードすべき文書のディレクトリおよび文書名５３２が表示されている。この文書名５３２に間違いがなければ、ユーザは、「ＯＫ」ボタン５３３をクリックすることにより、その文書を研究依頼元システム３にアップロードすることができる。また、アップロードすべき文書のディレクトリや文書名が変更されていた場合には、ユーザは、入力ボックス５３５にアップロードすべき文書のディレクトリや文書名を入力後、「ＯＫ」ボタン５３３をクリックする。なお、「キャンセル」ボタン５３４がクリックされると、文書アップロードは行われずに、「アップロード依頼」表示窓５３１が閉じられる。
【００４９】
なお、「タスク」表示窓５２２において、作成依頼、レビュー依頼、承認依頼などの情報がクリックされた場合にも、「アップロード依頼」表示窓５３１と同様の表示窓が表示される。また、「お知らせ」表示窓５２３および「企業からのご案内」表示窓５２４に表示された通知情報のうち、その１つがクリックされた場合には、新たに表示される表示窓（図示省略）には、前記クリックされた通知情報についてのさらに詳細な情報が表示される。
【００５０】
図６は、研究依頼元システム３から研究者端末２に向けてアップロード依頼情報が発信されたときの情報処理の流れの例を示した図である。以下、図６を参照しながら、研究プロジェクトＰ１の研究依頼元である製薬会社Ｃ１から研究プロジェクトＰ１に属する医師Ｄ１宛てにアップロード依頼情報を送信するケースについて説明する。
【００５１】
最初に、製薬会社Ｃ１の研究依頼元システム３は、研究プロジェクトＰ１に属する医師Ｄ１宛てにアップロード依頼情報を発信する（ステップＳ１０）。このアップロード依頼情報は、製薬会社Ｃ１の研究依頼元システム３に対応付けられたデータ授受サーバ３０に受信され、そのデータ授受サーバ３０は、受信したアップロード依頼情報をデータ変換サーバ２０へ転送する（ステップＳ１１）。
【００５２】
データ変換サーバ２０は、アップロード依頼情報を受信すると、記憶部２１に記憶されているメタデータを参照して、受信したアップロード依頼情報（通信データ）の構成を、アプリケーションサーバ１０に共通の通信データの構成に変換する（ステップＳ１２）。すなわち、データ変換サーバ２０は、受信したアップロード依頼情報に含まれている送信先、送信元、文書種別などの情報を、複数のアプリケーションサーバ１０で共通に用いられる送信先、送信元、文書種別などの情報に変換する。
【００５３】
ちなみに、データ変換サーバ２０が受信したアップロード依頼情報には、製薬会社Ｃ１の研究依頼元システム３で定められた通信データの構成に基づき、送信元が製薬会社Ｃ１、送信先が研究プロジェクトＰ１に属する医師Ｄ１などのような情報が含まれている。そこで、データ変換サーバ２０は、これらの情報を含むアップロード依頼情報をメタデータと突合して、当該アップロード依頼情報の送信先となるべきアプリケーションサーバ１０の識別番号や研究担当者名（例えば、医師Ｄ１）に変換する。そして、その取得したアプリケーションサーバ１０の識別番号や研究担当者（例えば、医師Ｄ１）を宛先として、当該アップロード依頼情報をアプリケーションサーバ１０へ送信する。
【００５４】
続いて、前記変換後のアップロード依頼情報を受信したアプリケーションサーバ１０は、例えば医師Ｄ１に対するランディングページ５２（図４参照）の「タスク」表示窓５２２に、その旨を知らせる表示（例えば、図４で「履歴書をアップロードしてください。」という表示）の準備をする（ステップＳ１３）。なお、このときアプリケーションサーバ１０がするのは、アップロード依頼情報を受信した旨を知らせる「タスク」表示窓５２２の表示を準備するだけであり、実際の表示は、研究者端末２で行われる。
【００５５】
そこで、医師Ｄ１が研究者端末２を介して当該アプリケーションサーバ１０にログインすると、医師Ｄ１が使用している研究者端末２には、前記ランディングページ５２が表示されるとともに、その中に「タスク」表示窓５２２が表示される。次に、医師Ｄ１が「タスク」表示窓５２２において、例えば、「履歴書をアップロードしてください。」という表示部分（図４参照）をクリックすると、研究者端末２は、さらに、文書アップロードページ５３（図５参照）を表示する（ステップＳ１４）。
【００５６】
医師Ｄ１が文書アップロードページ５３を介してアップロードする文書の文書名（ディレクトリ名を含む）を入力すると（ステップＳ１５）、アプリケーションサーバ１０は、その文書名で指定される文書をアップロード文書としてデータ変換サーバ２０へ転送する（ステップＳ１６）。このとき、アップロード文書には、送信先、送信元、文書種別などの情報が付加される。また、このアップロード文書（例えば、医師Ｄ１の履歴書）は、医師Ｄ１が使用する研究者端末２の中にあってもよく、研究プロジェクトＰ１用のアプリケーションサーバ１０の記憶部１１の医師Ｄ１に割り当てられた専用または共有の記憶領域の中にあってもよい。
【００５７】
次に、データ変換サーバ２０は、記憶部２１に記憶されているメタデータを参照して、アプリケーションサーバ１０から送信されたアップロード文書（送信先、送信元、情報種別などの情報を含む）の通信データの構成を、送信先の研究依頼元システム３で用いられている通信データの構成に変換し（ステップＳ１７）、変換したアップロード文書をデータ授受サーバ３０に転送する。
【００５８】
続いて、データ授受サーバ３０は、データ変換サーバ２０から転送されたアップロード文書を送信先で指定される研究依頼元システム３へ転送する（ステップＳ１８）。これで、研究依頼元システム３は、アップロードを依頼した医師Ｄ１からのアップロード文書を受信したことになる（ステップＳ１９）。
【００５９】
図７は、研究依頼元システム３から研究者端末２に向けて文書承認依頼情報が発信されたときの情報処理の流れの例を示した図である。以下、図７を参照しながら、研究プロジェクトＰ１の依頼元である製薬会社Ｃ１から研究プロジェクトＰ１に属する医師Ｄ１宛てに文書承認依頼情報を送信するケースについて説明する。
【００６０】
最初に、製薬会社Ｃ１の研究依頼元システム３は、研究プロジェクトＰ１に属する医師Ｄ１宛てに文書承認依頼情報を発信する（ステップＳ２０）。この文書承認依頼情報は、製薬会社Ｃ１の研究依頼元システム３に対応付けられたデータ授受サーバ３０に受信され、そのデータ授受サーバ３０は、受信した文書承認依頼情報をデータ変換サーバ２０へ転送する（ステップＳ２１）。
【００６１】
データ変換サーバ２０は、文書承認依頼情報を受信すると、記憶部２１に記憶されているメタデータを参照して、受信した文書承認依頼情報（通信データ）の構成を、アプリケーションサーバ１０に共通の通信データの構成に変換する（ステップＳ２２）。すなわち、データ変換サーバ２０は、受信した文書承認依頼情報に含まれている送信先、送信元、文書種別などの情報を、複数のアプリケーションサーバ１０で共通に用いられる送信先、送信元、文書種別などの情報に変換する。
【００６２】
この変換後の文書承認依頼情報を受信したアプリケーションサーバ１０は、例えば医師Ｄ１に対するランディングページ５２（図４参照）の「タスク」表示窓５２２に、その旨を知らせる表示（例えば、図４で「ＢＢ報告書を承認してください。」という表示）の準備をする（ステップＳ２３）。なお、このときアプリケーションサーバ１０がするのは、文書承認依頼情報を受信した旨を知らせる「タスク」表示窓５２２の表示を準備するだけであり、実際の表示は、研究者端末２で行われる。
【００６３】
そこで、医師Ｄ１が研究者端末２を介して当該アプリケーションサーバ１０にログインすると、医師Ｄ１が使用している研究者端末２には、前記ランディングページ５２（図４参照）が表示されるとともに、その中には「タスク」表示窓５２２が表示される。次に、医師Ｄ１が「タスク」表示窓５２２において、例えば、前記の「ＢＢ報告書を承認してください。」という表示部分（図４参照）をクリックすると、研究者端末２は、文書承認依頼ページ（図示省略）を表示する（ステップＳ２４）。
【００６４】
次に、医師Ｄ１がこの文書承認依頼ページを介して、依頼された文書の文書承認の操作入力をすると（ステップＳ２５）、アプリケーションサーバ１０は、文書承認が済んだことを示す文書承認済情報をデータ変換サーバ２０へ転送する（ステップＳ２６）。このとき、文書承認済情報には、送信先、送信元、文書種別などの情報が付加される。
【００６５】
次に、データ変換サーバ２０は、記憶部２１に記憶されているメタデータを参照して、アプリケーションサーバ１０から送信された文書承認済情報（送信先、送信元、情報種別などの情報を含む）の通信データの構成を、送信先の研究依頼元システム３で用いられている通信データの構成に変換し（ステップＳ２７）、変換した文書承認済情報をデータ授受サーバ３０に転送する。
【００６６】
データ授受サーバ３０は、データ変換サーバ２０から転送された文書承認済情報を送信先で指定される研究依頼元システム３へ転送する（ステップＳ２８）。これで、研究依頼元システム３は、文書承認を依頼した医師Ｄ１からの文書承認済情報を受信したことになる（ステップＳ２９）。
【００６７】
なお、文書の確認依頼やレビュー依頼も、以上と同様の手順で処理される。レビュー依頼は、同じ研究プロジェクトに属する複数の研究担当者に依頼されることも多いが、その場合には、レビュー依頼は、複数の研究担当者に宛てて発信され、その複数の研究担当者からの回答が返信される。
【００６８】
図８は、研究依頼元システム３から研究者端末２に向けて企業からのご案内情報が発信されたときの情報処理の流れの例を示した図である。以下、図７を参照しながら、研究プロジェクトＰ１の依頼元である製薬会社Ｃ１から研究プロジェクトＰ１に属する研究担当者全員宛てに企業からのご案内情報（例えば、「ＣＣＣＣ臨床研究を募集します。」）を送信するケースについて説明する。
【００６９】
最初に、製薬会社Ｃ１の研究依頼元システム３は、研究プロジェクトＰ１に属する研究担当者全員宛てに企業からのご案内情報を発信する（ステップＳ３０）。この企業からのご案内情報は、製薬会社Ｃ１の研究依頼元システム３に対応付けられたデータ授受サーバ３０に受信され、そのデータ授受サーバ３０は、受信した企業からのご案内情報をデータ変換サーバ２０へ転送する（ステップＳ３１）。
【００７０】
データ変換サーバ２０は、文書承認依頼情報を受信すると、記憶部２１に記憶されているメタデータを参照して、受信した企業からのご案内情報（通信データ）の構成を、アプリケーションサーバ１０に共通の通信データの構成に変換する（ステップＳ３２）。すなわち、データ変換サーバ２０は、受信した企業からのご案内情報に含まれている送信先、送信元、文書種別などの情報を、複数のアプリケーションサーバ１０で共通に用いられる送信先、送信元、文書種別などの情報に変換する。
【００７１】
この変換後の企業からのご案内情報を受信したアプリケーションサーバ１０は、例えば、研究プロジェクトＰ１のメンバそれぞれに対するランディングページ５２（図４参照）の「企業からのご案内」表示窓５２４に、その旨を知らせる表示（例えば、図４で「ＣＣＣＣ臨床研究を募集します。」という表示）の準備をする（ステップＳ３３）。なお、このとき、アプリケーションサーバ１０がするのは、企業からのご案内情報を受信した旨を知らせる「企業からのご案内」表示窓５２４を準備するだけであり、実際の表示は、研究者端末２で行われる。
【００７２】
そこで、研究プロジェクトＰ１に属するある研究担当者が研究者端末２を介して当該アプリケーションサーバ１０にログインすると、その研究担当者が使用している研究者端末２には、前記ランディングページ５２（図４参照）が表示されるとともに、その中には、「企業からのご案内」表示窓５２４が表示される。次に、その研究担当者が「企業からのご案内」表示窓５２４において、例えば、「ＣＣＣＣ臨床研究を募集します。」という表示部分（図４参照）をクリックすると、研究者端末２は、ＣＣＣＣ臨床研究の募集に関する企業からのご案内ページ（図示省略）を表示する（ステップＳ３４）。
【００７３】
次に、研究担当者がこの企業からのご案内ページを閲覧したことを確認する入力操作をすると、アプリケーションサーバ１０は、企業からのご案内ページの閲覧フラグをオンに設定する（ステップＳ３５）。そして、アプリケーションサーバ１０は、前記オンに設定した閲覧フラグを含んだ閲覧フラグ情報をデータ変換サーバ２０へ転送する（ステップＳ３６）。
【００７４】
次に、データ変換サーバ２０は、記憶部２１に記憶されているメタデータを参照して、アプリケーションサーバ１０から送信された閲覧フラグ情報（送信先、送信元、情報種別などの情報を含む）の通信データの構成を、送信先の研究依頼元システム３で用いられている通信データの構成に変換し（ステップＳ３７）、変換した閲覧フラグ情報をデータ授受サーバ３０に転送する。
【００７５】
データ授受サーバ３０は、データ変換サーバ２０から転送された閲覧フラグ情報を送信先で指定される研究依頼元システム３へ転送する（ステップＳ３８）。これで、研究依頼元システム３は、企業からのご案内情報を閲覧した研究担当者からの閲覧フラグ情報を受信したことになる（ステップＳ３９）。
【００７６】
以上の企業からのご案内情報は、研究プロジェクトＰ１に属する研究担当者全員宛てに送信されるため、その企業からのご案内情報は、複数の研究担当者によって閲覧される。従って、研究依頼元システム３は、複数の研究担当者からの閲覧フラグ情報を受信する。なお、説明を省略するが、図４などでいうお知らせ情報も、以上と同様の手順で処理される。
【００７７】
以上、本発明の実施形態に係る臨床研究情報クラウドサービスシステム１では、各研究依頼元システム３から送信される各種の情報は、データ変換サーバ２０によりアプリケーションサーバ１０で共通に用いられる情報に変換される。ちなみに、図６〜図８の例では、研究依頼元システム３から送信される通信データに含まれる送信先、送信元、情報種別などの情報が、データ変換サーバ２０により、アプリケーションサーバ１０で共通に用いられる送信先、送信元、情報種別などの情報に変換されること、また、その逆の変換がおこなわれることについて説明がされている。ただし、情報種別の変換については、説明が不十分であるので、以下に補足する。
【００７８】
図４、図５などでいうタスク情報（アップロード依頼情報、文書承認依頼情報、文書レビュー依頼情報など）、お知らせ情報、企業からのご案内情報などの情報種別は、本実施形態のアプリケーションサーバ１０で用いられている情報種別である。当然ながら、各研究依頼元システム３では、これらと異なる情報種別があり、それぞれ別の名称が用いられているのが普通である。
【００７９】
そこで、本実施形態では、データ変換サーバ２０は、各研究依頼元システム３で用いられている情報種別と、アプリケーションサーバ１０で用いられている情報種別とを対応付けたデータをメタデータとして記憶部２１に保持している。こうすることにより、データ変換サーバ２０は、研究依頼元システム３で用いられている情報種別をアプリケーションサーバ１０で用いられる情報種別に変換することができる。
【００８０】
なお、図４、図５などでいうタスク情報、お知らせ情報、企業からのご案内情報などの情報種別は、代表的な例として示したものであり、これ以外の情報種別があってもよい。また、このような情報種別の変換は、研究依頼元システム３で用いられている各種の情報を、アプリケーションサーバ１０で定義されている情報種別に分類する処理ともいえる。
【００８１】
以上のように、本発明の実施形態によれば、複数の研究依頼元システム３との間の通信でそれぞれ相違する通信データの構成（送信元、送信先、研究担当者名、情報種別などの構成）は、データ変換サーバ２０によりアプリケーションサーバ１０で共通に用いられる通信データの構成に変換され、また、その逆変換もされる。つまり、アプリケーションサーバ１０は、研究依頼元システム３から送信される情報をアプリケーションサーバ１０側の基準で分類することができることとなる。その結果、アプリケーションサーバ１０は、研究依頼元システム３からの情報を受信した場合には、それぞれ分類された情報種別に応じて、研究依頼元システム３に依存しない表示画面（ＷＥＢ表示画面）を研究者端末２に提供することができる。
【００８２】
よって、研究者端末２を操作する方法が研究依頼元システム３に依存しないものとなるため、研究者端末２を利用する研究担当者にとっては、複数の研究依頼元からの研究プロジェクトを引き受けても、それぞれ相違する複数の研究者端末２を使用する必要はない。従って、研究担当者は、依頼元が異なる複数の研究プロジェクトに参加しても、研究担当者の業務負担増を抑制することができる。
【００８３】
また、本実施形態では、アプリケーションサーバ１０は、研究プロジェクトごとに設けられ、その研究プロジェクトに属する研究担当者間で文書を共有することができるので、研究担当者間での情報共有が促進され、研究業務の効率向上を期待することができる。
【符号の説明】
【００８４】
１      臨床研究情報クラウドサービスシステム
２      研究者端末
３      研究依頼元システム
４，４ａ，４ｂ  通信ネットワーク
１０    アプリケーションサーバ
１１    記憶部
１２    バックエンド処理部
１３    フロントエンド処理部
２０    データ変換サーバ
２１    記憶部
３０    データ授受サーバ
３１    記憶部
５１    ログインページ
５２    ランディングページ
５３    文書アップロードページ
１１１  ユーザ情報記憶部
１１２  文書記憶部
１１３  ワークフロー情報記憶部
１１４  通知情報記憶部
１２１  ユーザ認証部
１２２  文書管理部
１２３  ワークフロー管理部
１２４  通知サービス管理部
【図１】
2017097417.tif 000003
【図２】
2017097417.tif 000004
【図３】
2017097417.tif 000005
【図４】
2017097417.tif 000006
【図５】
2017097417.tif 000007
【図６】
2017097417.tif 000008
【図７】
2017097417.tif 000009
【図８】
2017097417.tif 000010