JP2010518517A - ユーザによるカスタマイズが可能な双方向医師リコールメッセージデータベースのための方法及びシステム - Google Patents

Abstract

医師の医薬品リコールメッセージを分析する技術が開示されている。好適な実施形態においては、医師リコールメッセージを受信し検索可能なデータベースに入力することを含む方法が示されている。コンピュータプログラムにより、ユーザは、カスタマイズされたメッセージカテゴリを定義することができる。これらのユーザ定義は、メッセージに対する全文検索文字列を含む。メッセージは、定義に基づいて、カスタマイズされたメッセージカテゴリに分類される。そして、分類されたメッセージがユーザに提示される。

Description

関連出願の相互参照

本出願は、米国特許仮出願番号第６０／８８８，４７０号（２００７年２月６日出願）の優先権を主張し、その内容の全体は本明細書に参考として組み込まれる。

本発明は、医薬品情報の医師リコール（想起）を記載したメッセージを分析するための技術に関し、特にコンテンツ(内容)に基づいてメッセージを分類するためのコンピュータ化された技術に関する。

製薬会社は、薬剤師（医師）に提供される、営業担当者用主要製品メッセージの作成に多大な時間と資源を投資している。その目的は、製品の強みの正確且つ詳細な説明、競争における製品の差別化、及び製品への競争上の優位性の付与である。そして、その課題は、どのようなメッセージが実際に薬剤師に伝えられているか、どのようなメッセージが有効であるか、そしてどのようなメッセージが薬剤師の心に響くかを知ることである。

どのようなメッセージが伝えられ、どのようなメッセージが心に響くかを決定するために、企業は、一般に月ごと、或いは四半期ごとに医師を集め、営業担当者とのやり取りを報告してもらう。そのような報告は、インターネットにアクセスされた調査機器、或いは書面で行われる。これらのリコール（想起）メッセージには、例えば、主要製品メッセージのそのままの記載、医師自身の処方意図、どれだけの詳細な説明を受けたか、及び各製品に平均何分の時間が掛けられたかが含まれる。

そして、アナリストがこれらのメッセージを検討し、種々のメッセージ戦略の有効性を決定する。メッセージを分析するために、アナリストはまず、紙の形で原メッセージの取捨選択、調査、並び替え、分類、及び記録を行うことにより、多大な時間を費やしてデータを収集しなければならない。このような手動での月ごとの分類処理では、分類エラーの割合が高くなり、分類のためのビジネスルールの透明性が限定される。また、非常に多くの時間が掛かり、アナリストが分類されたメッセージを分析する時間がほとんど残されていないという事態が起きてしまう。

アナリストによるメッセージの分類に掛かる時間を減少させるために、メッセージの全文検索と標準的なカテゴリへの分類が可能なコンピュータによる検索システムが用いられている。しかしながら、プログラムに組み込まれた標準的なメッセージカテゴリが、分析されるメッセージに対して不適切であるとユーザが判断し得る場合、そのようなコンピュータによる分析技術は元来柔軟ではない。従って、リコールメッセージの分析及び分類のための、柔軟性を有するコンピュータ化された技術が必要とされている。

本発明は、カスタマイズされたメッセージカテゴリをユーザが全文検索文字列を用いて定義することが可能であり、ユーザが入力した検索文字列に基づいてカテゴリにメッセージを分類する、医師リコールメッセージを分析するためのコンピュータ化された技術を提供することを目的とする。

この目的、及び以下の開示を参照することにより明らかになる目的を達成するために、本発明は、医薬品のリコール情報を分析するための技術を提供する。

実施形態において、医師リコールメッセージは、受信された後、検索可能なデータベースに入力される。データベースは、メインデータテーブルと、過去１０年間の各年度からのメッセージのための分離データテーブルの両方を有する。コンピュータプログラムにより、ユーザは、カスタマイズされたメッセージカテゴリを、ウェブインターフェイスを通じて定義することができる。これらのユーザ定義は、メッセージに対する全文検索文字列を含む。メッセージは、定義に基づいて、カスタマイズされたメッセージカテゴリに分類される。そして、分類されたメッセージがユーザに提示される。

添付の図面は、部分的に本開示を構成し、本発明の好適な実施形態を示すと共に、本発明の原理の説明に用いられる。

本発明の一態様に係るメッセージの収集及び分析処理を行うシステムの一実施形態の機能図である。 メインメッセージデータベースにおけるデータ読み込み処理の一例の一実施形態を表す機能図である。 本システムの一形態において実行されるメッセージ分析プログラムの一例を表すブロック図である。 図３のプログラムのユーザインターフェイスにおける一実施形態の説明図である。 本発明の一実施形態において、ユーザの指示に応じてデータベースからデータを取得する際の、図３におけるプログラム構成間の相互作用を示す機能図である。

以下、図面を参照しつつ本発明を詳細に説明するが、これにより図示された実施形態に関連づけられる。
図１には、データ入力データベース１３５、メインメッセージ（ＭＭ）データベース１４５、ＤＳＤ製品市場定義ツール（ＤＳＤ）データベース１５５、アプリケーション１７５、及びＷｅｂユーザインターフェイス１８５を含むシステム１００が示されている。アプリケーション１７５及びＷｅｂユーザインターフェイス１８５は、メインメッセージデータベース１４５と同様に、メッセージ分析プログラムの動作に用いられるプログラムコンポーネントである。本実施形態では、データ入力（ＤＥ）データベース１３５はＮＴ、Ｕｎｉｘ（登録商標）プラットフォーム上で動作するＯＡＳＹＳ（登録商標）データベースであり、メインメッセージデータベース１４５とＤＳＤデータベース１５５は共にＳＱＬ Ｓｅｒｖｅｒ ２０００上で動作する。メインメッセージデータベース１４５は全文検索（ＦＴＳ）エンジン１６５を有する。一形態として、アプリケーション１７５とＷｅｂユーザインターフェイス１８５は、インテルプロセッサ、１ギガバイトＲＡＭ、及び７２ギガバイトのハードディスク容量を備えたＷｉｎｄｏｗｓ （登録商標）Ｓｅｒｖｅｒ ２００３上で動作し、メインメッセージデータベース１４５は、２基のインテルプロセッサ、２ギガバイトＲＡＭ、及び１４０ギガバイトのハードディスク容量を備えたＳＱＬ Ｓｅｒｖｅｒ ２０００上で動作し、データ入力データベース１３５及びＤＳＤデータベース１５５は、インテルプロセッサ、１、２ギガバイトＲＡＭ、及び５５ギガバイトのハードディスク容量を備えたサーバ上で動作する。

以下、本実施形態に基づき本発明を説明するが、本発明は記載された実施形態以外の構成によって実現されてもよいことは当業者にとっては当然である。例えば、データ入力データベース１３５及びＤＳＤデータベース１５５は、ＳＱＬサーバ、Ｉｎｔｅｒｍｉｘサーバ、又はＮＴ、Ｕｎｉｘ又はＷｉｎｄｏｗｓプラットフォーム上で動作可能な他のＳＱＬサーバ上で動作されてもよい。また、メインメッセージデータベース１４５は、ＥＴＬ（抽出、変換、移行）及びテキスト検索機能を有しているデータベースサーバ上で動作されてもよいし、データ入力データベース１３５に統合化されてもよい。

図１に示すように、医師１１５は、情報１１０を、書類として又はウェブサイトを通じてサービスプロバイダに送る。次に、１２０にて、サービスプロバイダ（ＩＭＳ）１２５は、調査データをデータ入力データベース１３５に入力する。データ入力データベース１３５は、本システムで用いる全てのデータを格納している。次に、データ変換サービス（ＤＴＳ）を用いてデータ入力データベース１３５内の全てのデータをコピーし、メインメッセージデータベース１４５内のステージングテーブルに格納するデータ読み込み処理１３０（ＥＴＬ処理の１つ）が実行される。そして、１４０にて、ストアドプロシージャを用いて、メインメッセージデータベース１４５内の製品テーブルを更新する。ＤＳＤデータベース１５５はメインメッセージデータベース１４５にリンクされている。ＤＳＤデータベース１５５は、本システムにアクセスするユーザ１９５の各々について、市場定義とデータの日付範囲の決定に用いられる情報を格納している。これにより、各ユーザのアクセスを、特定の市場及び特定の日付範囲に関するメッセージに限定することができる。ユーザ１９５がログインすると、１５０にて、当該情報がＤＳＤデータベース１５５から読み出され、メインメッセージデータベース１４５に送信される。

メインメッセージデータベースは、全てのメッセージとそれらに関連する全ての情報をアクセス可能な形式で格納するメインメッセージテーブルと、各々が特定の年度の医師メッセージを格納する年次メッセージテーブルとを有する。年次メッセージテーブルは、各メッセージについて情報量を減少させて格納しているが、メッセージ文章の全文検索が可能である。メインメッセージテーブルは、「各医師のＩＤ番号、所在地、及び専門」、「各営業担当者の取引の日付、仕入れ先、製品、及び期間」、「当該製品の主要製品メッセージ及びカテゴリ」、「メッセージＩＤ番号」（及びその他の事柄）をそれぞれ格納する列を含む。各年次メッセージテーブルは、期間識別子、製品ＩＤ番号、主要製品メッセージ文章、専門コード、及びメッセージＩＤをそれぞれ格納する列を含む。

本システムは、メインメッセージデータベース１４５の一部である全文検索エンジン１６５を用いて、メッセージ記録に索引を作成する。索引により、メッセージ属性を容易に検索でき、データベースからメッセージを迅速に取り出すことができる。全文検索は非常に強力かつ柔軟であるが、メッセージのカタログ(一覧表)が増大し過ぎている場合は、クエリ（検索要求）の速度が低下することがあり、また、カタログについても、新規の索引作成の速度が低下する。これらの問題を回避するために、メインメッセージデータベース１４５は以下の特徴を有している。即ち、メインメッセージデータベース１４５は、過去複数年のメッセージを格納できる。しかしながら、ユーザは特定の年度からのデータしか必要としないことがある。そのため、メッセージデータは、その日付に基づいて、年次メッセージテーブルにコピーされる。例えば、２０００年からのデータは、２０００年メッセージテーブルに格納され、２００１年からのデータは２００１年メッセージテーブルに格納される。全文検索クエリを実行してメッセージをカテゴリごとに分類する際には、検索に含まれる年度ごとに分離クエリが実行される。

ユーザ１９５は、Ｗｅｂユーザインターフェイス１８５を通じてシステム１７０にアクセスし、データに対する要求を入力する。好適な実施形態においては、Ｗｅｂユーザインターフェイス１８５は、Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＸＭＬ）で定義されるが、ＪａｖａＳｃｒｉｐｔ（登録商標）で定義することも可能である。次に、１７１において、ユーザインターフェイス１８５はユーザの要求を、ユーザインターフェイス１８５とデータベース１４５の間の全ての処理を取り扱うアプリケーション１７５に伝達する。アプリケーション１７５は、データベース１４５内のストアドプロシージャ１７２を作動させ、ユーザの要求を実行する。ストアドプロシージャは、要求に応じたデータ１８０をアプリケーション１７５に送る。１８１において、アプリケーション１７５は、当該データをユーザインターフェイス１８５に送る。１８２において、ユーザインターフェイス１８５は、当該データをユーザ１９５に提示する。

次に、図２を参照しつつ、データ読み込み処理の一例を説明する。データ読み込み処理は、データベースにアクセスしようとするユーザがほとんどいないときに、月に１度実施される。好適な実施形態においては、データ読み込みプログラムは、以下の処理を行うＷｉｎｄｏｗｓ ＮＴ プログラムである。２１０において、メインメッセージデータベース２４５用のデータ２０５は、メッセージに付帯する調査データ及びデータ入力データベース内の関連記述子データのみを有する特別ビュー２１５に入力される。次に、２２０において、データ読み込みプログラムは、データ入力データベースビュー２１５内の全てのデータをメインメッセージデータベース２４５内のステージングテーブル２３５に同一構造でコピーするデータ変換サービス（ＤＴＳ）パッケージ２２５を実行する。そして、２３０において、データ読み込み処理中に実行されるストアドプロシージャが、データをメインメッセージテーブル２５５及び製品・専門グループテーブル２６５にコピー、及び／又は送る。

２４０において、メインメッセージテーブル内のデータは、メッセージの年度に基づいて、年次メッセージテーブル２７０にコピーされる。そして、２５０において、データが更新された各年次メッセージテーブル２７０に対して、全文検索（ＦＴＳ）カタログ２７５がＳＱＬ Ｓｅｒｖｅｒ ２０００において再構築される。テーブル内でデータの変更がない場合、既存のカタログが保持される。全文検索エンジンは、各メッセージ文章内の単語を解析し、各単語をそれを含むメッセージに対応づけた索引を作成する。クエリの速度を上昇させるため、これらの索引は全文検索カタログ２７５に格納され、ユーザ全文検索クエリが、各メッセージの全文章に渡ってではなく、カタログ２７５に対して実行される。そして、２６０において、全文検索結果テーブル２８０は、個別メッセージを特定ユーザカテゴリに対応づける。全文検索クエリは各カテゴリに対して再実行され、その結果が該テーブルに入力される。

データ読み込み処理において、メインメッセージ２５５内のデータが変更された場合は、年次メッセージテーブル２７０は、当該データに基づく更新のみが行われる。全文検索カタログ２７５は、変更されたカタログに対しては、全体が再構築される。過去データの変更は極めて珍しいため、ほとんどの場合、年次メッセージテーブルに基づくカタログの索引１つのみを、データの読み込みの間に再構築すればよい。これにより、所要時間を大幅に減少させることができる。

本システムは、報告がなされる度に全文検索クエリを実行するのではなく、各全文検索クエリの結果を全文検索結果テーブル２８０に保存してもよい。このテーブルは、カテゴリＩＤをメッセージＩＤにリンクさせる。個々のレコードの組は、ユーザがカテゴリクエリを修正する際に更新される。テーブル全体の内容は、データ読み込み処理中に、削除及び再構築される。

次に、図３を参照しつつ、メッセージ分析プログラムのコンポーネント間の相互作用及び関係を説明する。ユーザは、ウェブインターフェイスを通じてメッセージ分析プログラムにアクセスする。本システムは、４つの論理層、即ち、Ｗｅｂ／ＵＩ（ユーザインターフェイス）層、ビジネス層、サービス層、及び前述のデータベース層を利用して作成することができる。しかしながら、本システムは単一層を用いて導入されてもよいし、４つ全ての層を用いて導入されてもよい。好適な実施形態においては、本システムは３つの層、即ち、ウェブ層、アプリケーション層、及びデータベース層を用いて導入される。各論理層及び各種サブシステムは、別々のアセンブリに分けられてもよい。

ウェブ層３００及びアプリケーション層３１０は、Ｍｉｃｒｏｓｏｆｔ ．ＮＥＴ Ｆｒａｍｅｗｏｒｋ １．１が実行されているＷｉｎｄｏｗｓ Ｓｅｒｖｅｒ ２００３サーバ上で動作させることができ、データベース層３２０は、ＳＱＬ Ｓｅｒｖｅｒ ２０００上で動作させることができる。ウェブ層サーバは、ウェブ層サーバにいずれのアプリケーション層サーバを使用すべきかを伝える構成ファイルを有し、アプリケーション層サーバは、アプリケーション層サーバにどのようにデータベース層サーバに接続するかを伝える同様の構成ファイルを有する。

プログラムのウェブ層３００及びアプリケーション層３１０は、データラッパを有するスキーマ・ネームスペース３３０を用いて通信する。データラッパは、主にストロング・タイプによるデータセットで構成されるが、クラスラッパも有することが可能である。各スキーマオブジェクトはシリアル化可能であるべきである。また、スキーマオブジェクトはアプリケーションサーバからウェブサーバに渡される全てのデータを表示し、記録するべきである。

プログラムのウェブ層３００は本システムのためのユーザインターフェイスを有する。アプリケーション層３１０には、可能な限りビジネスルール及びビジネスロジックが存在するべきである。ウェブ層３００は、ユーザインターフェイス（ＵＩ）コンポーネントのみに限定されるべきである。ウェブ層３００は、バリデータ(検証機能)や他のＪａｖａＳｃｒｉｐｔ（ジャバスクリプト）の機能を有していても良いが、アプリケーション層３１０は、適切な動作のため、そのようなコードを必要とすべきではない。

一形態として、アプリケーション層３１０は、ＳＱＬ呼出しをラップするために、ビジネスオブジェクト３１５、サービスオブジェクト３２５、ＳＱＬヘルパ３３５を有していても良い。ビジネスオブジェクト３１５は、データを保存、読み込み、又はバリデート（検証）するためのビジネスロジック及びビジネスメソッドを有するシングルコール（Ｓｉｎｇｌｅ Ｃａｌｌ）Ｍｉｃｒｏｓｏｆｔ ．ＮＥＴリモーティングオブジェクトである。本システムが動作している間、ウェブ層３００は、エンドユーザからの入力、例えば、彼らがどのレポートを見ているかやレポートのフィルタ（日付、製品、カテゴリ、専門など）を収集し、それらの入力をアプリケーション層３１０に渡す。そして、ビジネスオブジェクト３１５は、ビジネスロジックを使用してメインメッセージデータベース３４０から要求されたデータを取得するためにどのプロシージャを呼び出すかを決定した後、そのデータを取得し、ウェブ層３００に返す。ビジネスオブジェクト３１５は、スキーマオブジェクト３３０に記憶されたデータを取り扱い、データベースからの読み出し、及び／又は書き込みのために、サービスオブジェクト３２５を使用する。

サービスオブジェクト３２５は、データベース層３２０と直接的に通信可能な、アプリケーション内で唯一のオブジェクトである。サービスオブジェクト３２５は、データの読み込みと保存の機能に限定されるべきであり、データのバリデートや、ビジネスルールの実行を行ういかなるロジックとも関係させるべきではない。

データベース層３２０は、ストアドプロシージャ３４５とメインメッセージデータベース３４０とを備える。

図４は、ウェブ層で実行されるメッセージ分析プログラムのＷｅｂユーザインターフェイス上でユーザによって閲覧されるメッセージカテゴリページを示している。各ユーザは、そのユーザ専用のカスタムカテゴリを定義できる。カスタムカテゴリは、サブカテゴリやサブカテゴリのサブカテゴリなどを作成することにより、階層化させても良い。メッセージは、２以上のカテゴリに関連する場合は、複数のカテゴリに振り分けることができる。ユーザは、二種類のクエリ、即ち、シンプルフレーズ４１０及びアドバンスクエリ４２０を入力することができる。シンプルフレーズの例としては、「低費用」、「有効」、或いは「無毒」などが挙げられる。メッセージは、検索フレーズのいずれかがメッセージ文章内において発見された場合、シンプルフレーズに振り分けられる。アドバンスクエリ４２０を選択することにより、ユーザは、“ＡＮＤ”、“ＯＲ”、“ＮＯＴ”、及び括弧などのブール演算子を使用して、全文検索クエリを作成することができる。アドバンスクエリとしては、「低費用 ＡＮＤ 有効」、或いは「無害 ＯＲ 低費用」のような文字列が挙げられる。ページの左側には、ユーザ定義カテゴリ４４０とユーザ定義カテゴリ４６０、及びサブカテゴリ４４５とサブカテゴリ４６５の構成と関係を示す樹形図４３０が描かれている。本例においては、現在選択中のカテゴリである「費用」カテゴリ４４０が樹形図内でハイライト表示されており、メッセージを「費用」カテゴリ４４０に振り分ける、ユーザにより入力された全文検索クエリ４５０が、画面の右側に表示されている。

メッセージボタン４７０が選択された場合、現在選択中のカテゴリに対応した全てのメッセージを表示するダイアログボックスが出現する。現在選択中のカテゴリが未分類４８０である場合、メッセージボタン４７０が選択されると、いずれのカテゴリにも割り当てられていない全てのメッセージが表示される。

次に、図５内の図表５００を参照しつつ、種々のプログラム層間における相互作用の一例を説明する。５１０において、Ｗｅｂインターフェイスを通して操作を行うユーザは、カテゴリページ上のカテゴリツリー表示内にある「費用」カテゴリを選択する。そして、これに呼応して、５２０において、ウェブ層オブジェクト・チェックサブカテゴリ（費用）５０５は、表示上のカテゴリと全てのサブカテゴリを選択する。カテゴリツリー内のカテゴリを選択することによりカテゴリの詳細も表示されるため、ウェブ層オブジェクト・詳細取得（費用）５１５が実行される。５３０において、詳細取得（費用）５１５は、スキーマ５３５を使用して、アプリケーション層ビジネスオブジェクト・詳細取得（費用）５２５を呼出し、費用カテゴリの詳細と全文検索クエリを取得する。次に、５４０において、詳細取得（費用）５２５は、対応する詳細取得（費用）サービスオブジェクト５４５を呼び出す。

５５０において、詳細取得（費用）５４５は、データベース層５５５と通信し、ストアドプロシージャ・カテゴリ詳細取得５６５を呼び出す。５６０において、カテゴリ詳細取得５６５は、データベース５７５からカテゴリの詳細を取り出す。５７０において、カテゴリ詳細取得５６５は、詳細をアプリケーション層内のサービスオブジェクト・詳細取得（費用）５４５に返す。そして、５８０において、サービスオブジェクト・詳細取得（費用）５４５は、「カテゴリ詳細」データセットを作成し、そのデータセットをビジネスオブジェクト・詳細取得（費用）５２５に返す。次に、５９０において、ビジネスオブジェクト・詳細取得（費用）５２５は、スキーム５３５を使用して、そのデータセットをウェブ層に送る。そして最後に、５９５において、ウェブ層は、取得されたカテゴリの詳細をユーザに表示する。

以上の説明は、単に本発明の原理を示したものである。本記載に鑑みて、上記実施形態の種々の改良や変形が可能であることは当業者にとって明らかである。そのため当業者は、本説明に明確には記載されていないが、本発明の原理を具体化した、本発明の趣旨の範囲内の多数の技術を考案することができるのは当然である。

Claims (26)

1. 製品リコールメッセージを分析し、前記メッセージをカテゴリに分類する方法であって、
   １以上のリコールメッセージを受信する工程と、
   前記１以上のメッセージを１以上の検索可能なデータベースに入力する工程と、
   各々が前記１以上のメッセージに対して全文検索文字列を有する、１以上のカスタマイズされたメッセージカテゴリを定義する工程と、
   前記１以上のメッセージを、定義に基づいて、前記１以上のカスタマイズされたメッセージカテゴリに分類する工程と、
   を含む方法。
2. 前記メッセージを検索可能なデータベースに入力する工程は、
   前記メッセージをデータ入力データベースに入力する工程と、
   前記メッセージを検索可能なデータベース内のステージングテーブルに送る工程と、
   前記検索可能なデータベース内の製品テーブルを、前記ステージングテーブルに記憶された前記メッセージを用いて更新する工程と、
   を含む請求項１に記載の方法。
3. 過去１０年間の各年度に対してデータテーブルを設ける工程と、
   各メッセージを、当該メッセージが送信された年度に基づいて、データテーブルにコピーする工程と、
   を更に含む請求項２に記載の方法。
4. 前記メッセージは医薬品リコールメッセージである請求項１に記載の方法。
5. 前記医薬品リコールメッセージは医師の医薬品リコールメッセージである請求項４に記載の方法。
6. 前記メッセージは医師識別番号を含む請求項１に記載の方法。
7. 前記メッセージは製品識別コードを含む請求項１に記載の方法。
8. 前記メッセージは専門識別コードを含む請求項１に記載の方法。
9. 前記全文検索文字列はブール演算子を含む請求項１に記載の方法。
10. 前記１以上のカスタマイズされたメッセージカテゴリを定義する工程は、各人が関連する製薬市場とメッセージ日付範囲を有する１以上のユーザにより行われる請求項１に記載の方法。
11. 前記ユーザは、そのユーザの製薬市場とメッセージ日付範囲に関連するメッセージのみを検索するように制限されている請求項１０に記載の方法。
12. 前記データベースはＳＱＬデータベースである請求項１に記載の方法。
13. 前記１以上のカスタマイズされたメッセージカテゴリを定義する工程は、ウェブインターフェイスを通じて１以上のユーザによって行われる請求項１に記載の方法。
14. 製品リコールメッセージを分析し、前記メッセージをカテゴリに分類するシステムであって、
    １以上のリコールメッセージを１以上の検索可能なデータベースに送る少なくとも１つの入力装置と、
    前記少なくとも１つの入力装置に接続され、前記１以上のメッセージを記憶する少なくとも１つのデータベースと、
    前記少なくとも１つのデータベースに接続された少なくとも１つの処理装置と、
    実行された際に、前記少なくとも１つの処理装置により、各々が前記１以上のメッセージに対して全文検索文字列を有する１以上のカスタマイズされたメッセージカテゴリのユーザによる定義を可能とし、且つ前記１以上のメッセージを、定義に基づいて、前記１以上のカスタマイズされたメッセージカテゴリに分類する、記憶された指示を有する、前記少なくとも１つの処理装置に接続されたコンピュータ読み取り可能な記録媒体と、
    を備えるシステム。
15. 前記データベースは、
    前記入力装置からメッセージを受信し、検索可能なデータベースに前記メッセージを送るデータ入力データベースと、
    製品テーブルと、前記データ入力データベースから前記メッセージを受信し、前記製品テーブルを前記データ入力データベースから受信した前記メッセージを用いて更新するステージングテーブルとを含む検索可能なデータベースとを更に備え、
    前記メッセージを、検索可能なデータベース内のステージングテーブルに送るものである請求項１４に記載のシステム。
16. 前記検索可能なデータベースは、過去１０年間の各年度に対してデータテーブルを含み、各メッセージを、当該メッセージが送信された年度に基づいて、データテーブルにコピーすることを可能とするものである請求項１５に記載のシステム。
17. 前記メッセージは医薬品リコールメッセージである請求項１４に記載のシステム。
18. 前記医薬品リコールメッセージは医師の医薬品リコールメッセージである請求項１７に記載のシステム。
19. 前記メッセージは医師識別番号を含む請求項１４に記載のシステム。
20. 前記メッセージは製品識別コードを含む請求項１４に記載のシステム。
21. 前記メッセージは専門識別コードを含む請求項１４に記載のシステム。
22. 前記全文検索文字列はブール演算子を含む請求項１４に記載のシステム。
23. 各ユーザは、関連する製薬市場とメッセージ日付範囲を有する請求項１４に記載のシステム。
24. 前記ユーザは、そのユーザの製薬市場とメッセージ日付範囲に関連するメッセージのみを検索するように制限されている請求項１４に記載のシステム。
25. 前記データベースはＳＱＬデータベースである請求項１４に記載のシステム。
26. 前記ユーザは、ウェブインターフェイスを通じて前記システムにアクセスする請求項１４に記載のシステム。

Images