JP2015529872A - オフライン機能のためのモバイル治験モニターフレームワーク - Google Patents

Abstract

オフライン機能を有するＣＲＡアプリケーションフレームワークと関連付けられたシステムを提供する、システムおよび方法が記載されている。代表的な一実施形態において、トリップレポートスケルトンは、臨床研究に関するトリップレポートデータを、モバイル装置に格納できるようにする。モバイル装置は、トリップレポートスケルトン作成要求を、ＣＲＡアプリケーションフレームワークを用いてサーバ側ロジックに送信する。トリップレポートに関するアクティビティは非同期で実行される。したがって、トリップレポートスケルトンに対するフェッチ要求が発行されると、このトリップレポートスケルトンの準備ができているか否かが判断される。トリップレポートスケルトンの準備ができている場合、自己記述オブジェクト（ＳＤＯ）フォーマットのトリップレポートスケルトンが受信される。

Description

関連出願の相互参照
本開示は、２０１３年３月１４日に出願され「Mobile Clinical Research Associate Framework for Offline Capability」と題された米国非仮特許出願第１３／８２７，０７３号および２０１２年６月２０日に出願され「Mobile Clinical Research Associate Framework for Offline Capability」と題された米国仮特許出願第６１／６６２，０５０号の利益を主張し、その全体を本明細書に引用により援用する。

背景
臨床試験は、健康管理対策（たとえば薬剤、診断、装置、治療プロトコル）における薬剤の有害反応および治療の有害効果に関する情報等の、安全性と効能のデータを生成する、医療研究および薬剤開発における複数組のテストである。さらに、薬剤、診断、装置、およびプロトコルに関する情報等の、臨床研究の設計に関する情報も含まれる場合がある。

トリップレポートには、臨床研究に関する情報が保存されている。このため、トリップレポートは、カスタマイズ性が高く、重要なデータを含む。モバイル装置に対するインターフェイスをカスタマイズせずに、または、遠隔サーバに繰返しアクセスせずに、モバイル装置上でトリップレポートを編集し表示することが望ましい。また、ビジネスコンポーネントとトリップレポートウェブサービスのインタラクションが、トリップレポートを標準化することを困難にしている。

概要
概して、この明細書のある局面は、コンピュータによって実行されるとこのコンピュータに方法を実行させる、コンピュータで実行可能な命令が格納された、非一時的な（non-transitory）コンピュータ読取可能な媒体を開示する。この方法は、モバイル装置からトリップレポートスケルトン作成要求を送信することを含む。トリップレポートスケルトンにより、臨床研究に関するトリップレポートデータをモバイル装置に格納することができる。トリップレポートスケルトンに対するフェッチ要求が発行される。トリップレポートスケルトンの準備ができているか否かが判断される。トリップレポートスケルトンの準備ができている場合、自己記述オブジェクト（Self Describing Object）（ＳＤＯ）フォーマットのトリップレポートスケルトンが受信される。

一実施形態において、上記命令はさらに、上記フェッチ要求をタイムアウトさせることを含み、上記トリップレポートスケルトンの準備ができていない場合に次のフェッチ要求が発行される。上記次のフェッチ要求は、予め定められたスケジュール、上記フェッチ要求のタイムアウトの直後、または、上記フェッチ要求のタイムアウトから予め定められた時間の経過後、のうちのいずれかに従って、送信される。

別の実施形態において、上記命令は、上記トリップレポートスケルトンに埋込まれたメタデータを用いて、上記トリップレポートスケルトンを上記モバイル装置上でレンダリングすることを含む。

いくつかの実施形態において、上記命令は、上記モバイル装置を用いてトリップレポートデータを入力してトリップレポートを作成することを含む。いくつかの実施形態において、上記命令はさらに、治験モニター（clinical research associate）（ＣＲＡ）アプリケーションフレームワーク内のサーバ側ロジックとのネットワークリンクを確立することによって、上記トリップレポートをサーバ側ロジックに送信することを含む。

一実施形態において、予め定められた割合のトリップレポートデータが上記トリップレポートスケルトンに入力されたと判断されたときに、上記トリップレポートはサーバ側ロジックに送信される。

別の実施形態において、トリップレポートスケルトンは、トリップレポートスケルトンをレンダリングするためのメタデータと標準トリップレポートとを組み合わせることによって生成される。

いくつかの実施形態において、データは、サーバからのこのデータのアクセシビリティにかかわらず、上記モバイル装置によって上記スケルトントリップレポートに入力される。

一実施形態において、上記トリップレポート作成要求は上記モバイル装置から第１のスレッドで送信され、上記トリップレポートスケルトンは上記モバイル装置に第２のスレッドで送信される。

概して、この明細書の別の局面は、オフライン機能のためのモバイル治験モニターフレームワークに対する計算システムを開示する。この計算システムは、データベースと、サーバ側ロジックと、自己記述オブジェクト（ＳＤＯ）とを含む。データベースは、標準トリップレポートとメタデータとを格納する。サーバ側ロジックは、トリップレポートスケルトン作成要求をモバイル装置から受信する。ＳＤＯトランスフォーマは、上記標準トリップレポートと上記メタデータとを組み合わせてＳＤＯフォーマットのトリップレポートスケルトンを作成する。

概して、この明細書のもう１つの局面は、オフライン機能のためのモバイル治験モニターフレームワークに対する計算システムを開示する。この計算システムは、臨床研究に関連するトリップレポートデータを格納する自己記述オブジェクト（ＳＤＯ）フォーマットのトリップレポートスケルトンを含む。この計算システムはまた、上記トリップレポートスケルトンに埋込まれたメタデータを用いて上記トリップレポートスケルトンをレンダリングするレンダリングロジックを含む。この計算システムは、上記トリップレポートスケルトンに生じた変化を追跡し、かつ、上記トリップレポートデータが上記トリップレポートスケルトンに入力されたときに上記トリップレポートスケルトンを更新する持続スタックを含む。

本明細書に組込まれてその一部を構成する添付の図面は、本開示のさまざまなシステム、方法、およびその他の実施形態を示している。図面において示されている要素の境界線（たとえばボックス、ボックス群、またはその他の形状）は、境界線の一実施形態を表わすことが理解されるであろう。実施形態によっては、１つの要素が複数の要素として設計されることがあり、または、これら複数の要素が１つの要素として設計されることがある。実施形態によっては、ある要素が別の要素の内部コンポーネントとして示されている場合に前者の要素が外部コンポーネントとして実現されてもよく、その逆であってもよい。さらに、要素は正しい縮尺で描かれていない場合がある。

オフライン機能のための治験モニター（ＣＲＡ）フレームワークと関連する方法の一実施形態を示す。 オフライン機能のためのＣＲＡフレームワークと関連する方法の別の実施形態を示す。 オフライン機能のためのＣＲＡフレームワークと関連するシステムの別の実施形態を示す。 オフライン機能のためのＣＲＡフレームワークと関連するシステムの別の実施形態を示す。 計算システムのある実施形態を示し、このシステムにおいて、代表的なシステムおよび方法、ならびにこれらと均等なものが機能し得る。

詳細な説明
本明細書では、オフライン機能をサポートするために構築されるモバイル治験モニター（ＣＲＡ）アプリケーションフレームワークを提供するシステムおよび方法について説明する。このＣＲＡアプリケーションフレームワークは、モバイル装置上のデータベースおよびファイルシステムに対する宣言型タグを用いて、データを暗号化しキャッシュする一般的な方法を提供する。宣言型プログラミングを使用することにより、ＣＲＡアプリケーションフレームワークを可能にするのに必要な符号化の量を最小にする。ＣＲＡアプリケーションフレームワークによって、ユーザはオフラインデータをキャッシュすることができ、データをモバイル装置にダウンロードすることができ、モバイル装置をオフライン中に操作することができる。

一実施形態において、ＣＲＡアプリケーションフレームワークは、トリップレポートに関連するアクティビティを実行する。トリップレポートの作成は、リソースを最も使用する作業のうちの１つである。一般的に、トリップレポート作成要求を処理するスレッドは、次にそのトリップレポートを生成する。ＣＲＡアプリケーションフレームワークに課される負担の量を減らすために、トリップレポートに関連するアクティビティは、非同期で実行される。よって、異なるスレッドが、トリップレポート作成要求を処理し、トリップレポートを生成する。多くのリソースを使用する作業を、別々のスレッドに分けることによって、ＣＲＡアプリケーションフレームワークは、サーバリソースに対する制御をより良好に行なうことができ、より高い拡張性を可能にし、システムの信頼性を高める。

たとえば、図１は、オフライン機能を有するＣＲＡアプリケーションフレームワークに関連する方法の代表的な実施形態を示す。この方法１００は、臨床研究からのデータを管理するために使用されるＣＲＡアプリケーションフレームワーク内で実行される。このＣＲＡアプリケーションフレームワークによって、モバイル装置とサーバの間の通信が容易になる。

臨床試験現場を訪れるユーザは、その医療機関へのトリップに関するデータを保存し管理するために使用されるモバイル装置を有している。所望のデータを確実に取得するために、ユーザは、トリップレポートデータを、トリップレポートスケルトンの中の予め定められたスペースに入力する。トリップレポートスケルトンを受信するために、１１０で、トリップレポートスケルトン作成要求が、モバイル装置から、この要求を第１のスレッドで処理するサーバに送信される。１２０で、この作成要求が、サーバによって確認される。１３０で、トリップレポートスケルトンが、サーバ上の第２のスレッドで作成される。サーバのリソースをより良好に分散させるために、第１のスレッドは第２のスレッドと非同期で動作する。

１４０で、モバイル装置は、作成されたトリップレポートスケルトンを取出すためのフェッチ要求を発行する。第１のスレッドと第２のスレッドが非同期で動作するので、トリップレポートスケルトンが要求されたときにトリップレポートスケルトンは準備できていない場合がある。１５０で、トリップレポートスケルトンをモバイル装置に送信する準備ができているか否かが判断される。トリップレポートスケルトンの準備ができていなければ、この方法１００は１６０に進み、１６０でフェッチ要求はタイムアウトする。１７０で、モバイル装置は、トリップレポートスケルトンを取出すために次のフェッチ要求を発行する。追加のフェッチ要求を送信するタイミングは、予め定められたスケジュールに従うものであってもよい。その代わりに、１６０でフェッチ要求がタイムアウトした直後に追加のフェッチ要求を送信してもよく、または、１６０でフェッチ要求がタイムアウトしてから予め定められた時間が経過した後に追加のフェッチ要求を送信してもよい。次に、この方法１００はステップ１５０に戻り、トリップレポートをモバイル装置に送信する準備ができているか否かが判断される。

トリップレポートスケルトンの準備ができていれば、この方法１００はステップ１８０に進み、１８０において、モバイル装置がトリップレポートスケルトンを受信する。１８０で、モバイル装置は、トリップレポートスケルトンを、自己記述オブジェクト（Self Describing Object）として受信する。臨床研究のカスタマイズとは無関係に、臨床データを、モバイル装置上のＳＤＯに入力することができる。ＳＤＯは、モバイル装置がトリップレポートスケルトンをモバイル装置上でレンダリングできるようにするメタデータを含む。したがって、モバイル装置は、データがトリップレポートスケルトンに入力されているときに遠隔サーバにアクセスする必要はない。これにより、モバイル装置が遠隔サーバにアクセスしなければならない回数を少なくする。

図２は、オフライン機能を有するＣＲＡアプリケーションフレームワークに関連する方法の、ある実施形態を示す。トリップレポートスケルトンは自己記述オブジェクト（ＳＤＯ）として生成される。ＳＤＯフォーマットであるトリップレポートスケルトンの１つの利点として、トリップレポートデータを操作するのに汎用ツールを使用できることが挙げられる。自己記述データは、さまざまな種類のデータをツールが正確に操作する必要があるという情報を含む。ＳＤＯフォーマットであるトリップレポートスケルトンの別の利点として、これがＣＲＡアプリケーションフレームワークをよりロバストでフレキシブルなものにすることが挙げられる。異なる装置（たとえばモバイル装置、サーバ）上で実行している複数のプログラムが、これら異なる装置がトリップレポートデータを配置する場所が異なっているにもかかわらず、１つのプログラムにインターフェイスしてもよい。

２１０で、トリップレポートをモバイル装置上でレンダリングするためのメタデータが作成され、サーバ上に格納される。２２０で、格納されたメタデータは、標準トリップレポートと組合わされて、ＳＤＯフォーマットのスケルトントリップレポートが作成される。２３０で、このスケルトントリップレポートはモバイル装置によってフェッチされる。２４０で、モバイル装置は、埋込まれたメタデータに基づいてスケルトントリップレポートをレンダリングする。２５０で、トリップレポートデータはスケルトントリップレポートに入力される。トリップレポートスケルトンはモバイル装置上でＳＤＯとして維持されるので、データは、モバイル装置によって、スケルトントリップレポートに、サーバがこのデータへの即時アクセスを有しているか否かにかかわらず、入力される。データは、モバイル装置がオフライン（すなわちサーバから切断されている）ときに入力することができる。

モバイル装置がモバイル装置パラメータを満たしていることに応じ、２６０で、完成したトリップレポートはサーバに返送されて格納される。上記装置パラメータは、予め定められた割合のトリップレポートデータを含んでトリップレポートスケルトンを完成させることを含み得る。その代わりに、装置パラメータは、モバイル装置とサーバの間の関係の関数であってもよい。たとえば、完成したトリップレポートは、モバイル装置とサーバの間でネットワークリンクが確立されたときに、ロジックに送信されてもよい。

図３は、オフライン機能を有するＣＲＡアプリケーションフレームワークに関連するシステムの、代表的な一実施形態を示す。トリップレポートは大幅にカスタマイズされている。トリップレポートのカスタマイズによって、下にあるデータ構造、関連する臨床コンポーネント、および、サーバ側ロジック３１０とモバイル装置３５０の間の通信を容易にするトリップレポートウェブサービスが、変化する。サーバ側ロジック３１０とモバイル装置３５０は、ＣＲＡアプリケーションフレームワーク３００を用いてトリップレポートデータを伝達する。

サーバ側ロジック３１０は、標準トリップレポート３２０とメタデータ３３０とを格納している。標準トリップレポート３２０は、カスタムトリップレポートにリンクされた、一般化された構造である。したがって、カスタムトリップレポートを、高度にカスタマイズして、カスタムトリップレポート形態が複数のユーザへの配布に適さなくなるようにしてもよい。標準トリップレポート３２０は、多数のトリップについて、多数のユーザに、たとえこれらのユーザが異なるモバイル装置を使用しているときでも、標準トリップレポート３２０を配布できるよう、一般化される。

メタデータ３３０は、標準トリップレポート３２０をモバイル装置３５０上でレンダリングする（たとえば、個々の画面レンダリング、個々のフィールドレンダリングおよび検証、画面遷移、およびデータ変更イベントのハンドリング）ために使用される。たとえば、標準トリップレポート３２０は、カスタムアクティビティ属性（たとえばチェックリスト機能性）をサポートする。メタデータ３３０は、カスタムアクティビティ属性をモバイル装置３５０上でレンダリングする。管理者によってメタデータ３３０が生成されサーバ側ロジック３１０上に格納される。メタデータが一旦格納されると、任意の数の、モバイル装置３５０のようなモバイル装置は、レンダリングのためにメタデータを使用することができる。モバイル装置が送信する作成要求は、モバイル装置にとって正しいメタデータがわかるよう、モバイル装置識別子等のデバイスデータを含んでいてもよい。

標準トリップレポート３２０およびメタデータ３３０は、サーバ側ロジック３１０上のＳＤＯトランスフォーマ３１５によって組合わされてトリップレポートスケルトン３４０を作成する。トリップレポートスケルトン３４０は自己記述オブジェクト（ＳＤＯ）である。ＳＤＯは、標準トリップレポート３２０と同様、オブジェクト指向コンピュータプログラミング言語（たとえばＪＡＶＡ（登録商標））によって定義される。たとえば、サーバ側ロジックから見ると、トリップレポートスケルトン３４０は、Ｊａｖａ（登録商標）からＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクト表記法（JavaScript Object Notation）（ＪＳＯＮ）への非直列化のためにＪＳＯＮにおいて構築された平易なＪａｖａ（登録商標）オブジェクトである、ＳＤＯである。標準トリップレポート３２０は、特殊な表記法を含むクラスを用いてＸＭＬの直列化を使用し易くする。

したがって、ＳＤＯクラスは、標準トリップレポートクラスと構造的に類似する。標準トリップレポート３２０とトリップレポートスケルトン３４０の相違点は、トリップレポートスケルトン３４０がＳＤＯフォーマットでありメタデータ３３０をさらに含むことである。サーバ側ロジック３１０はまた、モバイル装置３５０がトリップレポートスケルトン３４０をロードして同期させるためのアプリケーションプログラミングインターフェイス（application programming interface）（ＡＰＩ）を提供する。

ＳＤＯトランスフォーマ３１５はまた、トリップレポートスケルトン３４０を標準トリップレポート３２０に逆変換する。カスタムトリップレポートが標準トリップレポート３２０に変換されるときに、カスタムトリップレポートの特徴のうちのいくつかが失われる場合がある。したがって、カスタムトリップレポートから標準トリップレポート３２０への変換は「損失が多い」と考えられる。しかしながら、カスタムトリップレポートから標準トリップレポート３２０への変換中に失われた情報は、逆変換中にリストアされる。たとえば、サーバ側ロジック３１０は、カスタムトリップレポートを、カスタムトリップレポートを保存することによって持続する。サーバ側ロジックがトリップレポートスケルトン３４０を、トリップに関する情報とともに受信したとき、結果として得られる修正されたトリップレポートスケルトンは、逆変換中にカスタムトリップレポートとマージされる。このように、トリップレポートスケルトンの使用によって失われたトリップレポートデータは、リストアすることができる。

図４は、オフライン機能を有するＣＲＡアプリケーションフレームワークと関連するシステムの別の典型的な実施形態を示す。モバイル装置３５０はトリップレポートスケルトン３６０を既に受信している。モバイル装置３５０は、図１について説明したやり方でトリップレポートスケルトン３６０を受信してもよい。モバイル装置３５０は、トリップレポートデータ３７０を入力し、トリップレポートデータ３７０を、ＣＲＡアプリケーションフレームワークシステム３００のモバイル装置３５０上のトリップレポートスケルトン３６０に局所的に格納する。

モバイル装置３５０から見ると、トリップレポートスケルトン３６０は、汎用再帰的辞書／アレイ構造に非直列化されたＳＤＯである。レンダリングロジック３７５は、トリップレポートスケルトン３６０に含まれるメタデータに基づいて、トリップレポートスケルトン３６０をレンダリングする。トリップレポートデータ３７０は、モバイル装置３５０がネットワークに接続されているか、ネットワークから切断されているか、または接続が間欠的であるかにかかわらず、操作することができる。トリップレポートデータ３７０をサーバ側ロジック３１０と同期させる必要があるとき、トリップレポートデータ３７０を含むトリップレポートスケルトン３６０をサーバ側ロジック３１０に送り返すことができる。よって、ネットワークインタラクションは、トリップレポートデータ３７０をモバイル装置上３５０で操作し都合がよいときに送信できるので、最小になる。

トリップレポートスケルトン３６０は、持続（persistence）スタック３８０を用いてモバイル装置３５０上に局所的に格納される。持続スタック３８０は、モバイル装置３５０上でトリップレポートデータ３７０の暗号化を実行する。持続スタック３８０はまた、トリップレポートスケルトン３６０を格納し、取出し、トリップレポートデータ３７０の変更を追跡し、更新を実行する。

持続スタック３８０は、持続コンテキスト３８５と、持続モデル３９０と、持続記憶装置３９５とを含む。持続コンテキスト３８５は、ＳＤＯであるトリップレポートスケルトン３６０等のオブジェクトを、オブジェクトをユニークキーと関連付けることによって、登録する。オブジェクトをユニークキーと関連付けるやり方は多数存在することを当業者は認識するであろう。たとえば、持続コンテキスト３８５は、持続コンテキスト委譲（delegate）方法を用いてユニークキーをオブジェクトに関連付けてもよい。

持続コンテキスト３８５はまた、トリップレポートスケルトン３６０に生じた変化を、トリップレポートデータ３７０が変更されたことを持続スタック３８０が検出したときに、トリップレポートスケルトン３６０がダーティ状態であると評価することによって、追跡する。トリップレポートスケルトン３６０がダーティであると考えられる場合、トリップレポートデータ３７０に対する更新アクションをスケジュールする。更新アクションによって、フラグ付のトリップレポートスケルトン３６０が持続コンテキスト３８５に保存され、こうすることによってトリップレポートデータ３７０を保存する。トリップレポートスケルトン３６０が依然としてダーティであれば、更新をファイナライズし、結果として「ダーティ」フラグがクリアされる。

持続コンテキスト３８５は、多数のイベント（たとえば実行されている変更、初期化）に応じて、トリップレポートスケルトン３６０の変化を検出する。たとえば、初期化時に、持続コンテキスト３８０は、管理されているトリップレポートスケルトン３６０のうちのいずれかがダーティ状態であるか否か検証する。トリップレポートスケルトン３６０等のトリップレポートスケルトンがダーティであれば、持続コンテキスト３８０は、更新動作が完了していなかったと判断し、続いて、持続コンテキスト３８０は、トリップレポートスケルトンに対する更新動作を再度スケジュールする。

持続モデル３９０は、トリップレポートデータ３７０のインメモリコレクションを提供する。持続モデル３９０はまた、以前に持続されたトリップレポートスケルトンを、持続コンテキストからロードする。持続モデル３９０は、前に持続されたダーティ状態のアイテム、または、入ってきたトリップレポートデータ３７０のタイムスタンプよりも大きなタイムスタンプを有するオブジェクトは、更新しない。持続記憶装置３９５は、トリップレポートスケルトン３６０のようなトリップレポートスケルトンを保存する。持続記憶装置３９５はまた、トリップレポートデータ３７０を暗号化し解読する。

ＣＲＡアプリケーションフレームワーク３００は、宣言型プログラミングを用いてオフラインデータのキャッシュを容易にすることができ、かつ、ユーザがデータをモバイル装置３５０にダウンロードしオフライン中にこのデータを管理することを、可能にする。システムは、モバイル装置上でデータをキャッシュし、キャッシュされたデータのライフサイクルをモニターし、動的同期機能を提供する。別の実施形態では、システムは、宣言型プログラミングを用いてさまざまなフォーマットでキャッシュされたデータを表示するように構成されたウィジェット（widget）を提供する。一実施形態において、システムは、設定を用いてセンシティブデータがＨＩＰＰＡ法およびＣＦＲ（連邦規則集）第１１条に準拠するようにすることができる。

別の実施形態において、上記方法および／またはこれら方法と均等なものは、コンピュータで実行可能な命令を用いて実現されてもよい。よって、一実施形態では、非一時的なコンピュータ読取可能な媒体が、コンピュータで実行可能な命令を格納して構成され、この命令は、マシン（たとえばプロセッサ、コンピュータ等）によって実行されると、このマシン（および／または関連するコンポーネント）に、上記方法を実行させる。別の実施形態では、上記システム、方法、および／またはこれらと均等なものを、ロジックにおいて実現してもよい。

図５は、本明細書に記載の代表的なシステムおよび方法、ならびにこれらと均等なものが機能し得る、代表的な計算装置を示す。この代表的な計算装置は、バス５０８によって、動作可能に接続された、プロセッサ５０２と、メモリ５０４と、入出力ポート５１０とを含む、コンピュータ５００であってもよい。一例において、コンピュータ５００は、ＣＲＡアプリケーションフレームワーク上で動作するように、かつ、モバイル装置がオフラインで機能できるようにするように構成された、サーバ側ロジック５３０を含み得る。他の例において、サーバ側ロジック５３０は、ハードウェア、命令が格納されている非一時的なコンピュータ読取可能な媒体、ファームウェア、および／またはこれらを組み合わせたものにおいて実現されてもよい。サーバ側ロジック５３０はバス５０８に装着されたハードウェアコンポーネントとして示されているが、一例ではサーバ側ロジック５３０をプロセッサ５０２内で実現できることが理解されるはずである。

一実施形態において、サーバ側ロジック５３０は、標準トリップレポートをメタデータと組み合わせてＳＤＯを作成するための手段（たとえばハードウェア、非一時的なコンピュータ読取可能な媒体、ファームウェア）を有する。この手段は、たとえば、ＳＤＯを作成するようにプログラムされたＡＳＩＣとして実現されてもよい。また、この手段は、データ５１６としてコンピュータ５００に与えられ、一時的にメモリ５０４に保存されその後プロセッサ５０２によって実行される、格納された、コンピュータで実行可能な命令として、実現されてもよい。これに代えて、サーバ側ロジックの機能をモバイル装置上で実現してもよい。

コンピュータ５００の代表的な構成を大まかに説明すると、プロセッサ５０２は、デュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャを含む多種多様なプロセッサであってもよい。メモリ５０４は、揮発性メモリおよび／または不揮発性メモリを含み得る。不揮発性メモリは、たとえば、ＲＯＭ、ＰＲＯＭ等を含み得る。揮発性メモリは、たとえば、ＲＡＭ、ＳＲＡＭ、ＤＲＡＭ等を含み得る。

ディスク５０６は、たとえば、入出力インターフェイス（たとえばカード、装置）５１８および入出力ポート５１０を介して、コンピュータ５００に動作可能に接続されてもよい。ディスク５０６は、たとえば、磁気ディスクドライブ、ソリッドステートディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｚｉｐドライブ、フラッシュメモリカード、メモリスティック等であってもよい。さらに、ディスク５０６は、ＣＤ−ＲＯＭドライブ、ＣＤ−Ｒドライブ、ＣＤ−ＲＷドライブ、ＤＶＤ ＲＯＭ等であってもよい。メモリ５０４は、たとえば、プロセス５１４および／またはデータ５１６を格納することができる。ディスク５０６および／またはメモリ５０４は、コンピュータ５００のリソースを制御し割当てるオペレーティングシステムを格納することができる。

バス５０８は、１つの内部バス相互接続アーキテクチャおよび／またはその他のバスもしくはメッシュアーキテクチャであってもよい。１本のバスが示されているが、コンピュータ５００が、その他のバス（たとえばＰＣＩＥ、１３９４、ＵＳＢ、イーサネット（登録商標））を用いてさまざまな装置、ロジック、および周辺機器と通信し得ることが、理解されるはずである。バス５０８は、たとえば、メモリバス、メモリコントローラ、周辺バス、外部バス、クロスバースイッチ、および／またはローカルバスを含む種類のものであってもよい。

コンピュータ５００は、入出力インターフェイス５１８および入出力ポート５１０を介して入出力装置と対話してもよい。入出力装置は、たとえば、キーボード、マイク、ポインティングおよびセレクトデバイス、カメラ、ビデオカード、ディスプレイ、ディスク５０６、ネットワーク装置５２０等であってもよい。入出力ポート５１０は、たとえば、シリアルポート、パラレルポート、およびＵＳＢポートを含み得る。

コンピュータ５００は、ネットワーク環境において動作することができ、したがって、入出力インターフェイス５１８および／または入出力ポート５１０を介してネットワーク装置５２０に接続されてもよい。ネットワーク装置５２０を通して、コンピュータ５００はネットワークと対話し得る。このネットワークを通して、コンピュータ５００は、遠隔コンピュータ（たとえばモバイル装置）に論理的に接続されてもよい。コンピュータ５００が対話し得るネットワークは、ＬＡＮ、ＷＡＮ、およびその他のネットワークを含むが、これに限定されない。

別の実施形態において、上記方法および／またはこれら方法と均等なものは、コンピュータで実行可能な命令で実現されてもよい。よって、一実施形態では、非一時的なコンピュータ読取可能な媒体が、コンピュータで実行可能な命令を格納して構成され、この命令は、マシン（たとえばプロセッサ、コンピュータ等）によって実行されると、このマシン（および／または関連するコンポーネント）に、図１および図２の方法を実行させる。

説明を簡潔にするために、図面において説明されている手法は、一連のブロックとして示され説明されているが、この手法はブロックの順序によって限定されるものではないことが理解されるはずである。いくつかのブロックは、示され説明されているものと、順序が異なっている可能性があり、および／または同時である可能性がある。加えて、代表的な手法を実現するために、示されているブロックすべてを使用しなくてもよい場合がある。ブロックを組み合わせてまたは分離して複数のコンポーネントにしてもよい。さらに、追加のおよび／または代替の手法が、示されていない追加のブロックを用いることができる。

以下の記載には、本明細書で使用される選択された用語の定義が含まれる。これらの定義は、用語の範囲に含まれ実現のために使用し得る、コンポーネントのさまざまな例および／または形態を含む。上記例は、限定を意図したものではない。用語は、その単数形および複数形どちらも定義の範囲に含まれ得る。

「一実施形態」、「ある実施形態」、「一例」、「ある例」等は、このように記載された実施形態または例が、特定の特徴、構造、特性、性質、要素、または限定を含み得るものの、必ずしもすべての実施形態または例が上記特定の特徴、構造、特性、性質、要素、または限定を含むとは限らないことを、示している。さらに、「一実施形態において」という表現を繰返し使用している場合、同一の実施形態を指していることもあるが、必ずしも同一の実施形態を指している訳ではない。

ＡＳＩＣ（application specific integrated circuit）：アプリケーション専用集積回路
ＣＤ（compact disk）：コンパクトディスク
ＣＤ−Ｒ（CD recordable）：書込み可能なＣＤ
ＣＤ−ＲＷ（CD rewriteable）：書換え可能なＣＤ
ＤＶＤ（digital versatile disk and/or digital video disk）：デジタル多用途ディスクおよび／またはデジタルビデオディスク
ＨＴＴＰ（hypertext transfer protocol）：ハイパーテキスト転送プロトコル
ＬＡＮ（local area network）：ローカルエリアネットワーク
ＰＣＩ（peripheral component interconnect）：周辺コンポーネント相互接続
ＰＣＩＥ（PCI express）：ＰＣＩエクスプレス
ＲＡＭ（random access memory）：ランダムアクセスメモリ
ＤＲＡＭ（dynamic RAM）：ダイナミックＲＡＭ
ＳＲＡＭ（synchronous RAM）：同期ＲＡＭ
ＲＯＭ（read only memory）：読取り専用メモリ
ＰＲＯＭ（programmable ROM）：プログラマブルＲＯＭ
ＥＰＲＯＭ（erasable PROM）：消去可能ＰＲＯＭ
ＵＳＢ（universal serial bus）：ユニバーサルシリアルバス
ＸＭＬ（extensible markup language）：拡張マークアップ言語
ＷＡＮ（wide area network）：ワイドエリアネットワーク
本明細書で使用される「コンピュータコンポーネント」は、コンピュータに関連するエンティティ（たとえばハードウェア、ファームウェア、実行中の命令、その組合せ）を意味する。コンピュータコンポーネントは、たとえば、プロセッサ上で実行するプロセス、プロセッサ、オブジェクト、実行可能なもの、実行のスレッド、およびコンピュータを含み得る。コンピュータコンポーネントは、プロセスおよび／またはスレッドの中に存在するものであってもよい。コンピュータコンポーネントは、一つのコンピュータ上に配置されていてもよく、および／または複数のコンピュータ間に分散されていてもよい。

本明細書で使用される「コンピュータ通信」は、計算装置（たとえばコンピュータ、携帯情報端末、携帯電話）間の通信を意味し、たとえば、ネットワーク転送、ファイル転送、アプレット転送、電子メール、ＨＴＴＰ転送等であってもよい。コンピュータ通信は、たとえば、無線システム（例としてＩＥＥＥ８０２．１１）、イーサネット（登録商標）システム（たとえばＩＥＥＥ８０２．３）、トークンリングシステム（たとえばＩＥＥＥ８０２．５）、ＬＡＮ、ＷＡＮ、二点間システム、回路交換システム、パケット交換システム等を通して行なわれるものであってもよい。

本明細書で使用される「コンピュータ読取可能な媒体」は、命令および／またはデータを格納する非一時的な媒体を意味する。コンピュータ読取可能な媒体が取り得る形態は、不揮発性媒体および揮発性媒体を含むが、これに限定されない。不揮発性媒体は、たとえば、光ディスク、磁気ディスク等を含み得る。揮発性媒体は、たとえば、半導体メモリ、動的メモリ等を含み得る。コンピュータ読取可能な媒体の一般的な形態は、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、その他の磁気媒体、ＡＳＩＣ、ＣＤ、その他の光媒体、ＲＡＭ、ＲＯＭ、メモリチップまたはカード、メモリスティック、および、コンピュータ、プロセッサ、またはその他の電子機器による読取が可能なその他の媒体を含み得るが、これに限定されない。

いくつかの例では、「データベース」を用いて１つのテーブルを意味する。その他の例では、「データベース」を用いて一組のテーブルを意味する場合がある。さらにその他の例では、「データベース」が一組のデータ記憶装置およびこれらデータ記憶装置に対するアクセスおよび／または操作のための方法を意味する場合がある。

本明細書で使用される「ロジック」は、ハードウェア、ファームウェア、命令を格納している非一時的なコンピュータ読取可能な媒体、マシン上で実行中の命令、および／または、これら各々の組合せであって、１つの（複数の）機能または１つの（複数の）動作を実施する、および／または別のロジック、方法、および／またはシステムからの機能または動作を生じさせる、組合せを含むが、これに限定されない。ロジックは、アルゴリズムによって制御されるマイクロプロセッサ、離散ロジック（たとえばＡＳＩＣ）、アナログ回路、デジタル回路、プログラムされたロジック装置、命令を含むメモリ装置等を含み得る。ロジックは、１つ以上のゲート、ゲートの組合せ、または、その他の回路コンポーネントを含み得る。複数のロジックについて説明する場合、これら複数のロジックを１つの物理ロジックに組込むことが可能であろう。同様に、１つのロジックについて説明する場合、この１つのロジックを複数の物理ロジック間に分散させることが可能であろう。

「動作可能な接続」、または、エンティティが「動作可能に接続される」ようにする接続とは、信号、物理的に伝達されるもの、および／または論理的に伝達されるものを、送信および／または受信し得るようにする接続を意味する。動作可能な接続は、物理的インターフェイス、電気的インターフェイス、および／またはデータインターフェイスを含み得る。動作可能な接続は、動作可能な制御を可能にするのに十分な、インターフェイスおよび／または接続の、異なる組合せを含み得る。たとえば、２つのエンティティを動作可能に接続することによって、これらの間で、信号を、直接、または、１つ以上の中間エンティティ（たとえばプロセッサ、オペレーティングシステム、ロジック、非一時的なコンピュータ読取可能な媒体）を通して、伝達することができる。論理的および／または物理的な通信チャネルを用いて、動作可能な接続をなすことができる。

本明細書で使用される「ユーザ」は、１人以上の人、１つ以上のコンピュータもしくはその他の装置、またはこれらの組合せを含むが、これに限定されない。

代表的なシステム、方法等を、例を説明することによって示し、例は、非常に詳細に説明してきたが、出願人は、以下の特許請求の範囲をこのような詳細事項に制限することも限定することも全く意図していない。当然ながら、本明細書に記載のシステム、方法等を説明することを目的としてコンポーネントまたは手法の考えられる組合せをすべて説明することは不可能である。このため、本開示は、示され説明されている、特定の詳細事項、典型的な装置、説明のための例に、限定されない。よって、本願は、以下の特許請求の範囲に含まれる、変更、修正、および変形を包含することを意図している。

詳細な説明または請求項において「含む（includes）」または「含んでいる(including)」という用語が使用されている場合、「備える（comprising）」という用語が請求項における移行語として用いられているときの解釈と同様に、上記用語が包括的であることが意図されている。

詳細な説明または請求項において「または」という用語が使用されている場合（たとえばＡまたはＢ）、「ＡまたはＢまたはＡとＢ双方」を意味することが意図されている。出願人が「ＡのみまたはＢのみであってＡとＢ双方ではない」ことを示すことを意図する場合は、「ＡのみまたはＢのみであってＡとＢ双方ではない」という表現を使用する。よって、本明細書における「または」という用語の用法は、包括的用法であって、排他的用法ではない。Bryan A. Garner, A Dictionary of Modern Legal Usage 624 (2d. Ed. 1995)参照。

本明細書において「Ａ、Ｂ、およびＣのうちの１つ以上」という表現が使用されている場合（たとえば、Ａ、Ｂ、およびＣのうちの１つ以上を記憶するように構成されたデータ記憶装置）、これは、Ａ、Ｂ、Ｃ、ＡＢ、ＡＣ、ＢＣ、および／またはＡＢＣという１組の可能性（たとえば、データ記憶装置は、Ａのみ、Ｂのみ、Ｃのみ、Ａ＆Ｂ、Ａ＆Ｃ、Ｂ＆Ｃ、および／またはＡ＆Ｂ＆Ｃを記憶し得ること）を意味することを意図する。Ａのうちの１つ、Ｂのうちの１つ、およびＣのうちの１つを要求することを意図しているのではない。出願人が「Ａのうちの少なくとも１つ、Ｂのうちの少なくとも１つ、およびＣのうちの少なくとも１つ」を示すことを意図する場合は、「Ａのうちの少なくとも１つ、Ｂのうちの少なくとも１つ、およびＣのうちの少なくとも１つ」という表現を使用する。

Claims (20)

1. コンピュータによって実行されると前記コンピュータに方法を実行させる、コンピュータで実行可能な命令が格納された、非一時的なコンピュータ読取可能な媒体であって、前記方法は、
   モバイル装置からトリップレポートスケルトン作成要求を送信することを含み、トリップレポートスケルトンにより、臨床研究に関するトリップレポートデータをモバイル装置に格納することができ、
   前記トリップレポートスケルトンに対するフェッチ要求を発行することと、
   前記トリップレポートスケルトンの準備ができているか否か判断することと、
   前記トリップレポートスケルトンの準備ができている場合、自己記述オブジェクト（ＳＤＯ）フォーマットのトリップレポートスケルトンを受信することとを含む、非一時的なコンピュータ読取可能な媒体。
2. 前記命令はさらに、前記フェッチ要求をタイムアウトさせることと、前記トリップレポートスケルトンの準備ができていない場合に次のフェッチ要求を発行することとを含む、請求項１に記載の非一時的なコンピュータ読取可能な媒体。
3. 前記次のフェッチ要求は、予め定められたスケジュール、前記フェッチ要求のタイムアウトの直後、または、前記フェッチ要求のタイムアウトから予め定められた時間の経過後、のうちのいずれかに従って、送信される、請求項２に記載の非一時的なコンピュータ読取可能な媒体。
4. 前記命令はさらに、前記トリップレポートスケルトンに埋込まれたメタデータを用いて、前記トリップレポートスケルトンを前記モバイル装置上でレンダリングすることを含む、請求項１に記載の非一時的なコンピュータ読取可能な媒体。
5. 前記命令はさらに、前記モバイル装置を用いてトリップレポートデータを入力してトリップレポートを作成することを含む、請求項１に記載の非一時的なコンピュータ読取可能な媒体。
6. 前記命令はさらに、治験モニター（ＣＲＡ）アプリケーションフレームワーク内のサーバ側ロジックとのネットワークリンクを確立することによって、前記トリップレポートをサーバ側ロジックに送信することを含む、請求項５に記載の非一時的なコンピュータ読取可能な媒体。
7. 予め定められた割合のトリップレポートデータが前記トリップレポートスケルトンに入力されたと判断したときに、前記トリップレポートをサーバ側ロジックに送信することをさらに含む、請求項５に記載の非一時的なコンピュータ読取可能な媒体。
8. トリップレポートスケルトンは、トリップレポートスケルトンをレンダリングするためのメタデータと標準トリップレポートとを組み合わせることによって生成される、請求項１に記載の非一時的なコンピュータ読取可能な媒体。
9. データは、サーバからの前記データのアクセシビリティにかかわらず、前記モバイル装置によって前記スケルトントリップレポートに入力される、請求項１に記載の非一時的なコンピュータ読取可能な媒体。
10. 前記トリップレポート作成要求は前記モバイル装置から第１のスレッドで送信され、前記トリップレポートスケルトンは前記モバイル装置に第２のスレッドで送信される、請求項１に記載の非一時的なコンピュータ読取可能な媒体。
11. 標準トリップレポートとメタデータとを格納するように構成されたデータベースと、
    トリップレポートスケルトン作成要求をモバイル装置から受信するように構成されたサーバ側ロジックと、
    前記標準トリップレポートと前記メタデータとを組み合わせてＳＤＯフォーマットのトリップレポートスケルトンを作成するように構成された自己記述オブジェクト（ＳＤＯ）トランスフォーマとを備える、計算システム。
12. 前記メタデータは前記トリップレポートスケルトンをレンダリングし易くする、請求項１１に記載の計算システム。
13. 前記標準トリップレポートは、異なるモバイル装置を用いる多数のユーザに前記標準トリップレポートを配布できるように一般化される、請求項１１に記載の計算システム。
14. 前記トリップレポート作成要求はモバイル装置から第１のスレッドで送信され、前記トリップレポートスケルトンは前記モバイル装置に第２のスレッドで送信される、請求項１１に記載の計算システム。
15. 前記サーバ側ロジックはさらに、モバイル装置が前記トリップレポートスケルトンのロードおよび同期化を容易にするためのアプリケーションプログラミングインターフェイスを提供するように構成される、請求項１１に記載の計算システム。
16. 臨床研究に関連するトリップレポートデータを格納するように構成された自己記述オブジェクト（ＳＤＯ）フォーマットのトリップレポートスケルトンと、
    前記トリップレポートスケルトンに埋込まれたメタデータを用いて前記トリップレポートスケルトンをレンダリングするように構成されたレンダリングロジックと、
    前記トリップレポートスケルトンに生じた変化を追跡するように、かつ、前記トリップレポートデータが前記トリップレポートスケルトンに入力されたときに前記トリップレポートスケルトンを更新するように構成された持続スタックとを備える、計算システム。
17. 前記持続スタックは、持続コンテキストと、持続モデルと、持続記憶装置とを含む、請求項１６に記載の計算システム。
18. 前記持続コンテキストは、前記トリップレポートデータが変更されたことを前記持続スタックが検出したときに、前記トリップレポートスケルトンがダーティ状態であると評価することによって、前記トリップレポートスケルトンに生じた変化を追跡するように構成される、請求項１７に記載の計算システム。
19. 前記持続モデルは、前記トリップレポートデータのインメモリコレクションを与えるように構成される、請求項１７に記載の計算システム。
20. 前記持続記憶装置は、前記トリップレポートスケルトンを保存するように構成される、請求項１７に記載の計算システム。

Images