JP2009026344A - 処方箋管理システム - Google Patents

Abstract

【課題】
通信チャネルまたは他の注文エントリ・プロセス／システムから受信された少なくとも１つの医療処方箋のための注文の自動処理のための方法を提供すること。
【解決手段】
本発明は、医療処方箋注文（１５、２０、２５）の処理のために情報を効率的に処理するための、イメージングおよびワークフロー方法、システム、コンピュータ可読メディア（１０）およびユーザ・インタフェースである。このシステムは、文書スキャン（４０）、自動ルールベース注文処理、統計レポート、文書生成、ならびに、文書格納および検索のためのサポートを含む。本発明はイメージング技術を利用して、ユーザが情報をシステムおよびソフトウェア・モジュールにスキャンして注文の処理を向上させることを支援する。
【選択図】 図１

Description

本発明は一般に、薬局業界で注文を処理するためのイメージおよびワークフロー方法、システムおよびメディアに関する。徳に、本発明は、通信販売薬局業界において薬剤処方箋を処理するための方法、システムおよびメディアに関する。

通信販売薬局業界では、医療処方箋の処理の品質および効率を向上させる必要性がある。通信販売薬局業界は、途方もなく多数の注文を毎日のように受けており、薬局所在地において１週間で２５０，０００から２７５，０００もの処方箋を受けることは珍しくない。通常、医療処方箋は非常に時間効率のよい方法で調合されなければならない。さらに、処方箋の誤りの影響が患者に及ぶと命にかかわる場合があるので、高度の品質管理が処方箋調合プロセスの全体に渡って維持されることが必要である。

患者から受けた注文はしばしば、いかなる追加の処理もなく直接調合される状態にはない。例えば、処方箋は、処方者の読みにくい筆跡により判読不可能である場合がある。注文の処理時間（ターンアラウンド・タイム）を遅らせる他の状態には、例えば、年金プラン会員番号が欠落している、もしくは年金プラン会員番号が誤っているか無効であること；既存の患者の状態または医療体制と共に用いられる場合に新しい処方箋がもたらす可能性のあるいかなる薬物間相互作用をも解決すること；支払いが欠落していること；重要な患者情報が欠落していること；当該処方箋が患者の年金プランによってカバーされていないこと；および、不正確な服用量または他の服用量もしくは使用の不一致があること、が含まれる。上記の例のいずれを解決するためにも、しばしば、薬剤師、または処方箋を調合するために働いている他の技術者が、例えば、処方者、患者、会員、クライアント、またはそれらの組み合わせに連絡を取ることが必要となる。

現在、薬局業界は、物理的な用紙の注文文書を処方箋調合プロセス中で使用して、処方箋を処理する。物理的な用紙の文書化に依存することは面倒であり、結果として処方箋処理が遅れることになる。現在の薬局モデルの下では、処方箋のための注文が来るとき、これらの注文が見直され、パンに割り当てられる。パンは物理的なトレイであり、すべての注文文書がパンの上に配置される。パンは通常、各曜日、または、注文を受けた順序に関係するある種の時間順に対応するように、色でコード化される。そのため、例えば、注文が月曜に受け取られ、開かれた場合、この注文は赤いトレイに入れられるようになり、このトレイはこの例では月曜トレイである。注文に関連付けられた誤り、疑問、および／または状態のいずれをも解決するには、処方者、患者、会員、クライアント、またはそれらの組み合わせへの連絡が必要となる場合がある。処方者は、ある注文に含まれた処方箋を書くことを担う個人であり、通常は医師である。会員は年金プランを保持する個人である。患者は会員である場合があるが、そうではなく、家族など、会員によって指名され、年金プランによってカバーされた個人であってもよい。クライアントは、全部または一部が薬剤に関連付けられた勘定、および通信販売薬局への管理費用を支払い、通常は、年金プランを会員に提供することを担う会社または個人である。例えば、ある処方箋で、薬剤の服用量が読みにくいために処方者への電話連絡（コール）が必要である場合、処方者に連絡を取ろうとする試みが行われる。処方者に連絡を取ろうとする試みが失敗する場合、メッセージを処方者の事務所に残すことができる。処方者が電話連絡（コール）を返すとき、処方者は通常、薬剤師または他の技術者が山積みのパンの中から対応する注文を探し出す間に、ある待ち時間を余儀なくされる。結果として生じる待ち時間は通常、処方者側へのある種のフラストレーションとなる。

現在の用紙ベースの薬局システムはまた、いずれか１つの注文の正確な位置を探し出すことができないことにも苦労している。例えば、患者が薬局に電話連絡（コール）して自分の注文の更新を要求する場合、または、患者が注文の出荷先を訂正する必要がある場合、患者を満足させる効率のよい方法で注文を探し出すことは厄介である。患者がコールして自分の処方箋について問い合わせるときと、注文が探し出されるときの間の遅延時間により、薬局に対する悪い印象が患者の心の中に生じてしまう。

薬局が注文を処理する速度が遅いという誤った印象を生じる、現在の通信販売薬局方法のもう１つの態様は、患者および薬局が地理的に離隔していることから生じる。例えば、通信販売薬局がワシントン州シアトルに位置し、患者がニューヨーク州ニューヨークに位置する場合、注文の輸送時間だけで数日、シアトルまで２〜３日、シアトルからニューヨークまでさらに２〜３日が失われる。処方箋を処理するために、ニュージャージーのどこかなど、ニューヨークにより近い薬局に郵送させて、郵便物の輸送時間を短縮できるとすれば、有利となるであろう。

さらに、通信販売薬局の現在の方法では、注文の処理に関係する様々なシステム・コンポーネントの健康または状態についての情報を得ることができない。より詳細には、現在の方法はリアル・タイムのシステムの状態に関する情報を提供することができない。

したがって、現在のシステムの改良により、システムまたはシステムのいずれかのサブコンポーネントに関するリアル・タイムでの状態情報、プロセスの処理内でいかなる時間にいかなる場所でも注文を探し出すための能力、および、調剤薬局とは異なる場所で注文を処理するための能力が得られるであろうと、我々は判断した。

したがって、本発明の特徴および利点の１つは、通信チャネルまたは他の注文エントリ・プロセス／システムから受信された少なくとも１つの医療処方箋のための注文の自動処理のための方法を提供することである。

本発明の追加的およびオプショナルの特徴および利点の１つは、通信チャネルまたは他の注文エントリ・プロセス／システムからの少なくとも１つの医療処方箋のための注文の自動処理のためのシステムを提供することである。

本発明のさらにオプショナルの特徴および利点の１つは、処方箋調合システムにおいてリアル・タイムで入力、表示、認証および管理を行うためのグラフィカル・ユーザ・インタフェースであって、該グラフィカル・ユーザ・インタフェースはシステム・レポートおよび他の統計情報を作成するものを提供することである。

本発明のオプショナルの特徴および利点の１つはまた、用紙のファイルおよび手動による文書送付書類への依存を減らすことである。

本発明のさらにもう１つのオプショナルの特徴および利点は、少なくとも１つの医療処方箋のための注文の自動処理の実行のためのコンピュータ可読メディアを提供することである。

本発明のさらなるオプショナルの特徴および利点は、ユーザ・インターフェース・サーバ・プログラムによってアクセスされた少なくとも１つの医療処方箋のための注文の自動処理のためのコンピュータ可読データ構造を提供することである。

本発明のこれらおよび他の目標および利点は、詳細な説明、図面、および添付の特許請求の範囲を検討することにおいて、いわゆる当業者には明白であろう。

本発明は例えばイメージング技術を使用して、通信販売処方箋の品質を改善し、その処理時間を高速化する。本発明の自動イメージング環境は、処方箋および処方箋見直しの適時かつ正確な処理、ならびに、完全なワークケース文書化のより容易な検索を保証する。処方箋注文に適用される、柔軟性があり構成可能なリレーショナル・データベースにより、全体的な処方箋注文処理時間が短縮される。

本発明はまた手作業のコストも削減するが、これは、本発明が好ましくは、薬局中を進む注文を移送しおよび仕訳（ソート）するための手作業の必要性をなくすからである。加えて、本発明は好ましくは、注文毎に費やされた時間、および、新しいユーザをシステム向けに訓練するために必要とされた時間の双方に関して作業コストを減らすが、これは、システムを通じて注文が進行するのに合わせてユーザの持つナビゲーション用の画面の数を減らすことによって行う。

スキャナが使用されて、郵便を通じて受け取られた情報がコンピュータ・ファイルおよび／またはメモリに読み取られ、これらの中でデータの永続的な類似をオプショナルで格納することができる。注文の永続的レコードが作成されると、結果として注文の検索が容易となる。

データベースのパラメータは手動で注文レコードに入力され、異なるタイプの着信注文文書を索引付けするために使用される。異なるパラメータは、異なるタイプの注文文書を区別するために使用される。例えば、支払いクーポンは実際の処方箋とは区別される。

システム、方法およびメディアの他の特徴には、アプリケーション処理ロジックに対して、注文のために実装する動作の種別および順序を識別するデータベース・テーブルが含まれる。ある場合には、これらのシーケンスは自動的に実行される。システム・レベル・レポートもまた生成され、このレポートはいかなるシステム・レベルでの生産性、品質および性能をも追跡することができる。

表記および専門語
以下に続く詳細な説明を、例えば、スタンドアロン・ゲーム機、コンピュータ或いはコンピュータ・ネットワークなどといった、コンピュータまたは処理システム上で実行されるプログラム手順に関して提示する場合がある。これらの手順の説明および表現は、それらの作業の本質をもっとも効果的にいわゆる当業者に伝えるために当業者が使用する手段である。

手順（プロシジャ）は本明細書で、また一般に、所望の結果に通じる、自己矛盾のない一連のステップであると考えられる。これらのステップは、物理的実体の物理的操作を必要とするものである。通常、必ずしもそうとは限らないが、これらの量（の実体）は、格納、転送、結合、比較およびそうでない場合は操作されることが可能である電気または磁気信号の形態を取る。時には、主に共通に使用するために、これらの信号をビット、値、要素、シンボル、キャラクタ、項目、番号などと呼ぶことが好都合であることがわかっている。しかし、これらおよびこれらに類似した用語のすべては、適切な物理量に関連付けられるべきであり、これらの量に適用された好都合なラベルでしかないということに留意されたい。

さらに、実行される操作はしばしば、追加または比較などといった用語で呼ばれ、これらは一般に、人間であるオペレータによって実行される頭脳的作業に関連付けられる。本発明の一部を形成し本明細書で説明するオペレーションのいずれにおいても、人間としてのオペレータのこのような能力は必要ではなく、あるいは大抵の場合望ましくはない。却って、これらのオペレーションはマシンのオペレーションである。本発明のオペレーションを実行するための有用なマシンには、汎用のデジタル・コンピュータ或いは類似の装置が含まれる。

本発明のこれらおよび他の態様、利点、および新規の特徴は、以下の詳細な説明を読むことで、および、添付の図面を参照することで、明らかになるであろう。図面においては以下の通りである。

本発明によれば例えばイメージング技術を使用して、通信販売処方箋の品質を改善し、その処理時間が高速化される。本発明の自動イメージング環境は、処方箋および処方箋見直しの適時かつ正確な処理、ならびに、完全なワークケース文書化のより容易な検索が保証される。処方箋注文に適用される、柔軟性があり構成可能なリレーショナル・データベースにより、全体的な処方箋注文処理時間が短縮される。

図１は、本発明を実施するための医療処方箋注文処理システム１０の一実施例である。詳細には、医療処方箋注文（注文とも称する）がシステムによって、システムへの様々な通信チャネルの少なくとも１つを通じて受信される。当該通信チャネルには、例えば、郵便（米国郵便、例えばＦｅｄｅｒａｌ Ｅｘｐｒｅｓｓ（登録商標）などの民間クーリエ）、手動のファクシミリなどといった、紙としての文書のチャネル、および、例えば電子ファクシミリ、ｅメール、電話などといった、ペーパーレスまたは電子チャネルが含まれる。システムへの注文導入のための注文入力（エントリ）ポイントまたは通信チャネルは、紙による注文のための標準スリッタ・プロセッサ１５並びに標準ファクシミリ・プロセッサ２０、および、標準着信ペーパーレス注文プロセッサ２５で見出される。

受け取られた郵便は処理され、本システムにスキャンされる状態に置かれる。郵便はシステムに、例えばスリッタ・プロセッサ１５で入る。該スリッタ・プロセッサ１５は封筒を開き、例えば、各封筒がスリッタ・プロセッサ１５によって開封される日付を含む、事前定義された情報をその封筒に押印する。

類似の本前処理ステップは、手動ファックス通信チャネルを通じてファクシミリ・プロセッサ２０に受信された手動または紙のファックスにおいて実行される。本発明の代替実施形態によれば、受信された手動のファックスは、受け取られた郵便と共にペーパ・バッチ（書類束）の中に束ねられる（バンドルされる）。

文書準備プロセッサ３０で、書類束における各封筒の内容が見直され、スキャンするために準備される。封筒の内容全体が注文を構成する。開封された封筒は、所定数の封筒束中に合わされる。次いでこの封筒束（バンドル）が書類束にされる。各書類束は、バンドルからのすべての文書、および、関連のあるあらゆる準備フォームを含む。関連準備フォームには、例えば、書類束の頂部にあるバッチ・ヘッダ・シート、注文を分離するために使用される注文セパレータ、および、各書類束の最後に配置されるバッチ終了シートが含まれる。各封筒の内容は、システム・プロトコル下で適用可能であるときには、事前定義された文書タイプまたはカテゴリに割り当てられる。各文書に、事前印刷されたバーコード・ラベルが貼られ、このラベルは、特定の文書タイプに属することなどによりラベル付けされた文書を識別する。文書タイプには、例えば、システム封筒と非システム封筒の間の区別である封筒；ＥａｓｙＲＸ／Ｕｎｉｖｅｒｓａｌ Ｏｒｄｅｒ Ｆｏｒｍ（ＵＯＦ）；例えば会員または患者が情報を書く媒体としてのあらゆるものを含むノート；処方箋再調剤；処方箋更新；支払いクーポン；例えば現金、小切手および為替を含む支払い；いずれかのタイプの会員または患者の健康プロフィール・フォームであるＨｅａｌｔｈ，Ａｌｌｅｒｇｙ ａｎｄ Ｍｅｄｉｃａｔｉｏｎ Ｑｕｅｓｔｉｏｎｎａｉｒｅ（ＨＡＱ：健康、アレルギー及び治療法に関する質問集）；新しい処方箋；注文内でスキャン不可能である文書を表現するシートであるスキャン不可能シート；ならびにその他が含まれ、その他には、事前定義されたカテゴリまたは文書タイプに適合しないあらゆるものも含まれる。注文文書は、順序付けされ、適用可能なバーコード・ラベルが貼られた後、高速スキャナ４０へイメージングのために送信される。

注文の文書の内容またはコンポーネントが、事前定義された条件を満たさない場合、このような文書は注文から引き抜かれ、スキャン不可能シートで置き換えられ、オプショナルで例外処理プロセッサ３５にルーティングされる（渡される）。例外処理プロセッサ３５にルーティングされる文書には、例えば、現金、例えば空の処方ボトルなどの３次元の物体が含まれ、これらは項目を読み取ることが困難であり、文書自体のスキャン（走査）が困難であるか、もしくは高速スキャナ・プロセッサ４０によるスキャンが不可能な他の文書である。注文が現金を含んでいる場合、現金が数えられ、少なくとも正副２通で記録される。現金および少なくとも１つの写しが現金箱４０または預金口座に預けられ、少なくとも１通が、その現金の発生元である注文を構成する文書と共に配置される。注文に含まれた現金をスキャンするのではなく、記録された支払いフォームがスキャン（走査）される。現金を受け取る他のフォームをオプショナルで使用することができる。注文が３次元の物体、例えば空の処方ボトルなどを含む場合、この品目は例外処理プロセッサ３５に送信される。例外処理プロセッサ３５はこの項目を計算に入れ、例外品目の記録を注文にルーティングすることで、当該品目に含まれた情報がその注文に関するさらなる注文処理のために利用可能にする。例外処理プロセッサ３５との通信にあたるものは、例外処理プロセッサ３５によって取り込まれたイメージの監視のためのイメージ・ディスプレイ３６である。

高速スキャナ・プロセッサ４０との通信にあたるものは、取り込まれたイメージの品質を監視するためのイメージ・ディスプレイ４５である。スキャンされた書類束は、所定の見直し監査スケジュールに従って見直される。本発明の重複実施形態によれば、所定の見直し監査スケジュールはランダム選択（無作為選択）に基づいており、このランダム選択においては、無作為に選択されスキャンされた書類束のみが、イメージ品質管理プロセッサ５０へイメージ見直しのためにルーティングされる。別法として、スキャンされた書類束をすべて利用するようにしてもよい。イメージ品質管理プロセッサ５０にルーティングするように選択されなかった書類束はコンピュータ可読メディア５５に格納されるが、このコンピュータ可読メディア５５とは例えば、コンピュータ・メモリ、コンピュータ・ハード・ディスク・ドライブ、磁気テープ・ドライブ、および／またはコンピュータ可読光媒体（メディア）などである。注文イメージに対応するハード・コピーは、これらのハード・コピーを電子的イメージに索引付けする所定の方法で、ファイル・ルーム６０に格納およびアーカイブ（記録保管）される。本発明の代替的実施形態によれば、書類束中のスキャンされた各文書には文書識別番号が付加され、あるいはこれらの文書は文書識別番号と関連付けられ、この文書識別番号は、対応する書類束のヘッダ識別番号にリンクされ、このヘッダ識別番号のもとに当該書類束がファイル・ストレージ・ルーム６０内にアーカイブ（記録保管）される。

見直しのために選択される書類束は、システム・ユーザによって見直される。スキャンされたイメージ内に欠陥が存在すると判明し、この欠陥が所定のしきい値を超える場合、書類束全体が再スキャン／例外処理プロセッサ３５にルーティングされる。イメージ品質管理プロセッサ５０による見直しの後に、イメージが受け入れ可能であると判明する場合、該イメージがコンピュータ可読メディア（媒体）に格納されるが、このコンピュータ可読メディアは例えば、コンピュータ・メモリ、コンピュータ・ハード・ディスク・ドライブ、磁気テープ・ドライブ、および／またはコンピュータ可読光メディア（媒体）などである。当該注文イメージに対応するハード・コピーは、これらのハード・コピーを対応する電子的イメージに索引付けする所定の方法で、ファイル・ルーム６０に格納される。

書類束は、スキャンおよび承認された後、システム・キューへさらなる注文処理のためにルーティングされる。

注文の内容に応じて、注文は、注文ヘッダ・プロセッサ６５、注文完成プロセッサ７０、および／または注文見直しプロセッサ７５のうち少なくとも１つを通過するようになる。注文ヘッダ・プロセッサ６５、注文完成プロセッサ７０、および注文見直しプロセッサ７５は、それぞれ互いと、また、管理プロトコル解決プロセッサ８０およびプロフェッショナル（専門）プロトコル解決プロセッサ８５と通信する。

注文ヘッダ・プロセッサ６５は、注文に関連付けられた非臨床データを処理する。非臨床データには、例えば、注文における処方箋の数；処方箋分類、年金プランに関係するときには会員番号、年金プランに関係するときにはグループ番号、および、年金プランに関係するときにはサブグループ番号；支払いの額およびタイプ、患者／クライアント通信；処方者名；患者／クライアント名；および処方箋発行日が含まれる。

注文完成プロセッサ７０は、注文に関連付けられた臨床データを処理する。臨床データには、例えば、薬剤情報、薬剤の強さ、薬剤使用法、許可された再調剤の数、調剤するための薬剤の量、および１日当たりの服用量が含まれる。

注文見直しプロセッサ７５は注文の全要素を見直して、注文要素が正しいかどうかを判断する。注文見直しプロセッサ７５を離れる注文は高速印刷プロセッサ９０にルーティングされ、そこで処方箋ラベルおよび他の添付注文資料が印刷される。次いで、薬剤が実際に注文調剤プロセッサ９５で調剤され、出荷ステーション・プロセッサ１００へ、患者への出荷のためにルーティングされる。プロセッサ９０、９５および１００の実施例については、例えば、参照により本明細書に組み込まれる「ＡＵＴＯＭＡＴＩＣ ＰＲＥＳＣＲＩＰＴＩＯＮ ＦＩＬＬＩＮＧ，ＳＯＲＴＩＮＧ ＡＮＤ ＰＡＣＫＡＧＩＮＧ ＳＹＳＴＥＭ」（自動処方箋記載、仕訳、梱包システム）という名称の米国特許第５，７７１，６５７号を参照されたい。

コマンドおよび制御プロセッサ１０１は各システム・プロセッサと通信し、インタフェースを提供し、このインタフェースを通じて、例えばシステム・キュー、注文の場所、システム・リソースおよびシステム実働に関するリアル・タイム情報が表示され、管理されおよび処理される。代替的実施形態では、分散制御システムおよび／または並列処理システムを使用することができる。本発明のさらにまた別の実施形態では、コマンドおよび制御プロセッサ１０１は、システム・プロセッサ９０、９５および１００を除く各システム・プロセッサと通信する。

ワークフロー・プロセッサ１０２は各システム・プロセッサと通信し、様々なシステム・プロセッサおよび作業キューを通じて、注文の流れを導く。ワークフロー・プロセッサ１０２はまた、情報をコマンドおよび制御プロセッサ１０１に提供する。

イメージ化された注文文書
図２は、本発明によって取り込まれた、イメージ化された注文文書の画面キャプチャを例示する。取り込まれた後、イメージ化された注文文書はいくつかの方法で操作することができる。これらの方法には例えば、イメージ化された注文文書の選択された部分の拡大またはズーム・イン；および、イメージ化された注文文書の正面および背面を同時に見直すことが含まれ、この見直しにおいて両面はイメージ・ディスプレイの別々の領域に現れる。また、イメージ化された注文文書は注釈を直接受信することができる。イメージ化された注文文書を、例えば処方箋分類および利用見直し考察など、処方者との話し合いを反映するように直接更新することができる。直接注釈が付けられた、イメージ化された注文文書は、正当な処方箋となる。

注文処理の流れ制御
図３は、本発明の注文処理方法を通じた注文の全体の流れの一実施例を例示する高レベルの制御流れ図である。２００、２０５でそれぞれ、患者は注文を非電子フォーマット（例えば、用紙）で、あるいは電子フォーマット（例えば、ペーパーレス）でサブミット（提出）する。非電子フォーマット注文の内容は、例えばイメージングのために準備され、２１０でイメージ化される。２１５で、注文と共に受け取られた支払いが処理され、預金口座にルーティングされる。イメージ化することができないか、あるいは２２０でイメージ化されるために特別処理を必要とする注文の内容は、２２１で、オプショナルで特別処理エリアにルーティングされる。システムは注文イメージを受信し、注文イメージに基づいて、２２５で、注文に対応する少なくとも１つのデータ・フィールドを完成させることによって、注文がシステムに入力される。本発明の代替的実施形態によれば、ステップ２０５でシステムに入る注文は、ステップ２２５を通じて進むことなく処理される。この実施形態によれば、ステップ２２５を必要としない注文には、例えば、ＩＶＲＵ、ワールド・ワイド・ウェブ、インターネット、および他の電子通信チャネルからサブミット（提出）された処方箋再調剤が含まれる。

２３５でファックス通信チャネルを通じて受信された注文または注文関連情報は、２２５で入力される。２２５の注文完成のステップ中に、注文イメージが判読不可能であるか、そうでなくても解像不可能であると決定される場合、２２６で該注文が作業キューに送信されて、イメージが解像される。

ファクシミリ注文および２０５で受信されたフォロー・アップ注文情報はファックス・サーバによって取り込まれ、イメージ・リポジトリ（貯蔵所）にコピーされ、少なくとも１つの作業キューへ処理のためにルーティングされる。

注文文書がシステムによってイメージ化され、受信された後、該注文イメージは２３０で少なくとも１つの作業キューに割り当てられる。注文を作業キューに入れることは、少なくとも部分的には、例えば、（ｉ）注文を少なくとも１つの最初のキューから注文出荷キューまで進めるために、何のオペレーション（群）が注文に適用されなければならないか；（ｉｉ）注文の優先順位、（この場合の優先順位はユーザまたはシステムによって割り当てられる）；および（ｉｉｉ）部分的には例えば、注文が受信された日付、クライアント、および、注文が受信されるに当たって用いられた通信チャネル、に基づく注文の目標配送日によって、決定される。この方法は、２３０で生成され、２４０で判断されるように、注文を解決して注文を少なくとも１つの最初のキューから注文出荷キューまで進めるために必要とされる、すべての適用可能プロトコルを適用する。次いで２５０で、入力された注文が、イメージ化された注文に対して見直される。

入力された注文を、イメージ化された注文に対して検証するに当たり、この方法は、処方箋データがさらなる更新を受信しないようにロックし、２５５で、該注文に対応するラベル・セットを印刷する。処方箋データがこのポイントから前方へさらなる更新を受信しないようにロックすることによって、該処方箋データの解釈のためのユーザ・アカウンタビリティ（責任能力）が確立される。当該ラベル・セットは、例えば従来のラベル印刷方法で印刷されるが、この方法においてはラベルは最初に印刷され、次いで調合され、あるいは電子データ・ストリームが自動調剤薬局に送信される。例えば、参照により本明細書に組み込まれた「ＡＵＴＯＭＡＴＩＣ ＰＲＥＳＣＲＩＰＴＩＯＮ ＦＩＬＬＩＮＧ，ＳＯＲＴＩＮＧ ＡＮＤ ＰＡＣＫＡＧＩＮＧ ＳＹＳＴＥＭ」（自動処方箋記載、仕訳、梱包システム）という名称の米国特許第５，７７１，６５７号を参照されたい。ラベル・セットには、例えば、実際の処方箋ラベルおよびその他のいかなる注文関連患者通信も含まれる。２６０で注文が調剤され、その後に２６５で、正しい薬剤が調剤されたかどうかを判断するための検証ステップが続く。２６５の検証ステップの後に、２７０の包装ステップ、２７５の積荷目録の自動生成、次いで２８０の、患者への注文の実際の出荷が続く。

本発明の一実施形態によれば、注文をロックおよび調剤することができるようになる前に、すべてのプロトコルが解決されることが必要である。すべてのプロトコルが解決された後、１セットのルーティング・ロジック・ルール（論理規則）は、どの薬局（群）が処方箋を調剤するかを決定する。ルーティング・ロジック・ルールは、例えば、顧客年金プラン；契約上のサービス・レベル；および、調剤される薬剤のタイプを考察するが、これは、規制薬剤であるかどうか、または、温度に敏感であり、特別な出荷事前注意が必要であるかどうかなどである。

本発明のもう１つの実施形態によれば、注文が調剤される際の順番は、該注文に割り当てられた優先順位番号に依存する。該優先順位番号を、例えば、クライアント（顧客）の契約上のサービス保証に基づいて割り当てることができ、クライアント・サービス保証に関連付けられた注文は、そうでない注文よりも高い優先順位を有し、したがって最初に調剤される。

図４は、注文が受信される際に用いられる通信チャネルとは独立した、本発明の方法の全体の流れ制御の高レベルの例示を表す。３００で注文が受信され、次いで３０５でシステムに入力される。３１０で、注文に含まれた処方箋の妥当性が検証される。妥当性検証ステップは、３１５で少なくとも１つのデータベースから入力を受信する。妥当性検証ステップに関連するデータベースの例には、例えば、臨床データベース３１６、年金プラン・データベース３１７、ルール（規則）データベース３１８、および／または連絡先データベース３１９が含まれる。本発明の代替的実施形態によれば、妥当性検証ステップに関連するデータベースの例には、臨床データベース、プラン・データベース、ルール・データベース、連絡先データベース、アカウント受領可能データベース、処方集（一覧）データベース、価格設定データベース、顧客（クライアント）概要（プロフィール）データベース、患者履歴データベース、およびそれらの組み合わせが含まれる。

処方箋の妥当性検証の際に、この方法は３２０で、注文に対するいずれかの適用可能なプロトコルの存在をチェックする。いずれかのプロトコルが適用される場合、３２５で、適用可能なプロトコルが少なくとも１つのデータベースに対して解決される。解決ステップに関連するデータベースの例には、例えば、臨床データベース３１６、年金プラン・データベース３１７、ルール（規則）データベース３１８、および／または連絡先データベース３１９が含まれる。本発明の代替的実施形態によれば、プロトコル解決ステップに関連するデータベースの例には、臨床データベース、プラン・データベース、ルール・データベース、連絡先データベース、アカウント受領可能データベース、処方一覧（集）データベース、価格設定データベース、クライアント（顧客）プロファイル（概要）データベース、患者履歴データベース、およびそれらの組み合わせが含まれる。表１には、本発明が解決することができるプロトコルのいくつかの例が含まれる。

３２５でのすべての適用可能なプロトコルの解決の際、３３０で注文が見直されて、各注文要素が正しいかどうかが判断される。３３５で正しい注文が調剤薬局キューにルーティングされる。本発明の重複的実施形態によれば、調剤薬局キューは、注文エントリ、処方箋の妥当性検証、プロトコルの解決および注文見直しのステップが完了する場所とは地理的に異なる場所に位置することができる。本発明の重複的実施形態によれば、注文エントリ、処方箋の妥当性検証、プロトコルの解決、注文見直し、および調剤キューへのルーティングの各ステップをそれぞれ、地理的に互いに異なる場所で実行することができる。

図５は、注文に適用されるプロトコルの解決に関連する反復プロセスを例示する。３５０で注文が受信され、３５５で少なくとも１つの最初のキューに割り当てられる。この注文は少なくとも１つの中間キューを通じて調剤薬局キューに進み、その中で、注文がポピュレート（所在）する各キューについて、この方法は３６０で、注文にあてはまるプロトコルがあるならばそれがどんなプロトコルなのかを決定する。この方法はこのプロセスを、３６５ですべての適用可能なプロトコルが解決されるまで継続する。この方法はまたポジティブ制御メカニズムも提供し、このメカニズムは、プロトコルを解決できないことにより注文が失われたり、あるいはいずれかの単一のキュー内で固定されたりしないようにする。この方法は３７０で、注文がいずれか１つのキュー内に所定の期間を超えて残るとき、アラート（警報）を発信する。３６５でのすべての適用可能なプロトコルの解決の際には、注文が見直されて、すべての注文要素が正しいことを調べるためにチェックされ、ここでもし正しい場合には、３８０で調剤薬局キューにルーティングされる。

ヘッダ・エントリ
図６は、ヘッダ・エントリのための流れ制御の一実施例を示す。ヘッダ・エントリは、注文フィールド内の注文に関係する非臨床データを入力するステップを提供する。ヘッダ・エントリ・プロセス内で検証および／または入力されたデータは一般に、イメージ化された注文文書または他の電子および／または非電子注文文書から導出される。検証および／またはエントリ（入力）プロセスは、４００で、イメージ化された注文文書或いは他の取り込まれたデータを見直して、データ・フィールドに対してチェックするか、もしくは、必要とされるが現在は空となっているデータ・フィールドにデータを入力することを含む。図８は、本発明の一実施形態に係る画面キャプチャを例示し、ここにおいては、イメージ化された注文文書は会員、住所、および支払いデータ・エントリ・フィールドに近接して配される。ヘッダに入力され、かつ／または検証されたデータの例には、例えば、患者名、処方者名、出荷先住所、支払い額、および／またはクレジット・カード番号が含まれる。４００で各注文イメージが見直されて、その後に４０５のイメージ分類が続く。４１０で、注文に含まれた各文書が検証され、説明される。４１５で、注文内に存在する処方箋の総数が検証される。４２０で各処方箋が見直されることで、各処方箋が正しい処方箋分類に割り当てられていることが保証される。処方箋分類が存在しない場合、４２０で入力される。４２５で、注文がチェックされて、この注文に正しい年金プラン会員番号、グループ番号およびサブグループ番号が割り当てられていることが検証される。年金のプラン番号が存在しないか、あるいは、番号のサブセットのみが存在する場合、４２５で番号が入力される。４３０で、支払いの額および種類（タイプ）が検証される。支払いの額およびタイプが提供されていない場合、４３０で支払いの額およびタイプが入力される。４３５で、患者サイドから提供した通信が検証される。患者の通信が入力されていない場合、４３５で患者が提供した通信が入力される。本発明の代替的実施形態によれば、患者の通信が提供されない場合、プロセスはステップ４４０に進み、患者通信フィールド（群）は空となる。

４４０で、処方箋が更新または再調剤される回数が検証される。更新または再調剤回数が入力されていないが、更新または再調剤回数が注文中に存在する場合、４４０で更新または再調剤回数が入力される。４４５で処方者名が検証される。処方者名が入力されていない場合、４４５で処方者名が入力される。本発明の代替的実施形態では、処方者名の検証または入力のうち少なくとも１つのステップは加えて、患者と処方者を対応（マッチ）させる履歴リストから処方者を選択すること；処方者を処方者データベースから選択すること；新しい処方者を入力すること；或いは既存の処方者情報を編集すること、のうち少なくとも１つを含む。４５０で患者名が検証される。患者名が入力されていない場合、４５０で患者名が入力される。４４５で、各処方箋の処方箋発行日が検証される。処方箋発行日が入力されていない場合、４５５で処方箋発行日が入力される。４６０での、ヘッダ・エントリ・データのすべてもしくは所定のセット（部分）の検証および／またはエントリの際には、４６５で注文が作業キューにサブミット（提出）されて、注文の次の宛先が決定される。

郵便注文のための前処理の流れ制御
図７Ａおよび７Ｂは、注文が郵便によって送られるときの注文前処理の流れ制御の一実施例を例示する。５００で注文が受信される。５０５で、受信された注文が郵便注文でない場合、５１０で、注文は、システムの他の通信チャネルの１つを通じてシステムに入り、適切となるべくヘッダ・エントリ、注文完成またはプロトコルにルーティングされる。郵送された注文は、他の受領された郵便注文と共に集められる。５２０で、注文がおさめられている封筒が破られ、５２５で日付のスタンプが押される。５３０で、破られた封筒が所定のサイズごとのスタック（山）にバンドルされ（束ねられ）る。次いで５３５で、各バンドル（束）が書類束に変換される。５４０で、バーコードが書類束内のすべての適用可能な文書に取り付けられる。書類束におけるあらゆる文書は、必ずしもバーコードを受ける資格があるとは限らない。バーコードを受けるための文書の資格は、所定の基準に基づく。

５４５で、書類束内の文書が所定の基準を満たすことができない場合、その文書がオプショナルの例外処理エリアに送信されて、該文書が例えば、５５０で不正な処方箋であるかどうか、５５５で現金払いであるかどうか、５６０でスキャン不可能であるかどうか、あるいはさもなければ判読不可能であるかどうかが判断される。５５０で注文が不正であると判断される場合、５６０で該注文がキャンセルされる。注文が現金払いである場合、５７０で現金レシートが正副２通で完成され、５７５で、現金払いが２通の現金レシートのうち１通と共に預金口座に入れられる。５８０で、他の１通の現金レシートがその対応する注文文書に戻される。注文がスキャン可能でない場合、スキャン不可能文書またはその中に含まれた情報を表す文書が作成され、スキャンされ、その対応する注文文書に戻される。スキャンすることができる例外処理文書が、フラッドベッド・スキャナを使用して５８６でスキャンされる。

５８５で、所定の基準を満たす書類束における文書が順序付けされるが、これは、バッチ・ヘッダを書類束の頂上に、注文セパレータを互いの注文の間に、バッチ・エンドを書類束の最後に配置することによって行われる。順序付けされた書類束は、例えば、アコーディオン・フォルダに５９０で入れられ、５９５で組織的な正確性について見直される。書類束の見直しが成功した場合には、６００でこの書類束がスキャンされ、６００で支払い文書がこの注文文書から分離される。５９５で、書類束が正しい順序でないことが判明する場合、この書類束は再順序付けのために５４５の例外処理にルーティングされる。

６０５で、スキャン・プロセスは書類束の識別番号を各書類束に付加し、ならびに６０５で、書類束における各文書イメージに文書識別番号を付加する。本発明の代替的実施形態によれば、この文書識別番号はユリウス日および一意的な識別番号を含む。

スキャン・プロセッサは注文文書のイメージをカラーで取り込み、各注文文書の両面を同時にイメージ化することが好ましい。

書類束から取り込まれた、スキャンされたイメージは、所定の見直しスケジュールに従って見直される。見直した際に、取り込まれたイメージが６１０で承認される場合、６１５で、該イメージがディスクに或いは他のコンピュータ格納媒体（ストレージ・メディア）に書き込まれる。また、イメージの承認の際に、６００で分離された支払いが、６２０で預金口座に送られる。しかし、イメージが所定の見直しスケジュールに従って見直された後に承認されない場合、この書類束は６００で再スキャンされる。

６１０のスキャンされたイメージの承認後、スキャンされたイメージを作成するために使用された書類束が６２５でアーカイブ（記録保管）される。６２５で書類束が所定の方法でアーカイブされるが、この方法は書類束をスキャン後イメージに索引付けるというものであり、したがって、スキャンされたイメージに基づいて注文の処理中にいつでも書類束の検索が可能である。スキャンされたイメージに基づいて注文を処理している最中に書類束にアクセスする必要がある場合、６３０でタスク要求をサブミット（提出）することができ、その要求されたタスクを６３５で該書類束上で実行することができる。

書類束におけるすべての文書に対応する、スキャンされたイメージのセット全体は、６４０で、所定の見直しスケジュールに基づいて品質管理の観点から見直される。本発明の代替的実施形態によれば、所定の見直しスケジュールは、スキャン完了して間もない書類束のランダム選択に基づく。６４５で書類束が見直しのために選択される場合、その束における各イメージがオプショナルで見直される。６５０で書類束が見直しをパスする場合、６５５で、この書類束は少なくとも１つのシステム作業キューに、さらなる注文処理のためにキューイング（待ち合わせ）される。６５０で見直しをパスできない書類束は、５４５で例外処理に送られる。見直しのために選択されない束は、少なくとも１つのシステム作業キューに、さらなる注文処理のために直接キューイングされる。

注文完成
図９は、注文完成に関連する全体的なステップの一実施例を示す。注文完成ステップは、臨床データの検証および／またはエントリ（入力）に関連する。検証および／またはエントリ・プロセスは部分的には、イメージ化された注文文書または他の取り込まれたデータを見直すことに関連し、データ・フィールドに対してチェックするか、あるいはデータを入力する。図１２は本発明の一実施形態の画面キャプチャを例示し、ここでは、イメージ化された処方箋注文文書は、薬剤選択データ・エントリ（入力）フィールド（領域）に近接して並べられる。７００で、注文が作業キューから得られる。７０５で、患者情報が正しいかどうかについての判断が行われる。患者情報が不正確である場合、７１０で、それに応じて患者情報が更新される。７１５で、次の薬剤情報が見直されて、その正確性が判断される。薬剤情報が不正確である場合、７２０で、それに応じて正しい薬剤が選択され、注文が更新される。次に７２５で、薬剤が示す強さが見直される。強さが不正確である場合、７３０で正しい薬剤の強さが選択される。次いで７３５で、薬剤使用のための使用法が正しいかどうかについての判断が行われる。使用法が不正確である場合、７４０で正しい使用法が選択される。いかなる不正確なエントリへの訂正も、対応する正しい情報を手動で入力することによって、あるいは、プル・ダウン・メニューからの正しい情報の選択によって行うことができる。さらに、上記で概説したステップは、必ずしも上述の順序で実施されなくてもよい。本発明の代替的実施形態によれば、ステップ７１５および対応するステップ７２０は、ステップ７３５および対応するステップ７４０と置き換えられる。すべての臨床データが検証および／または入力された後、７４５で、その特定の処方箋のための注文が見直されて、７５０で、あらゆる注文要素が、単一の処方箋に関係するために、正しいことが保証される。特定の処方箋の注文要素が正しくない場合、正しくなるまでステップ７０５から７３５が繰り返される。特定の処方箋のためのすべての注文要素が正しい場合、７５５で、該注文が追加の処方箋についてチェックされる。追加の処方箋が同じ注文内に存在する場合、単一の注文内のすべての処方箋が解決されるまで、ステップ７０５から７５０が繰り返される。注文内のすべての処方箋の完成の際および／またはすべての注文要素が正確であると判明した際には、７６０で該注文が調剤薬局キューにサブミットされる。本発明の代替的実施形態によれば、多重処方箋を含む注文は、７６０で個別の処方箋を調剤薬局キューにリリースする前に、該注文内のすべての処方箋を処理させる必要はない。

また、本発明の代替的実施形態によれば、注文完成プロセス内の各ステップは、注文完成プロセスの完了においてユーザを支援する１セットのツールによってサポートされる。これらのツールには、例えば、ユーザが少なくとも１つのプル・ダウン・メニューの句および／または語から選択することによって薬剤使用法を構築することができるようにする薬剤使用法ビルダー；スペル・チェッカー、および、薬剤類似／音類似機能が含まれる。

プロトコル
プロトコルは、注文の要素を解決するように作用する複数組のルールのセットまたは集まりである。１つのプロトコルの解決は、追加のプロトコルを解決する必要性を引き起こす場合がある。例えば、ある注文中の一要素が欠落しているか、あるいは不明瞭である場合、プロトコルは、欠落または不明瞭な要素に対して使用されず、要素の解決を追跡するために使用される。追跡には、例えば、どのユーザが検証を実行したか、および、その要素を解決するために誰に連絡が取られたかに留意することが含まれる。

本発明の一実施形態によれば、本発明の方法およびシステムは、プロトコルを解決する際にユーザを支援する１セットのウィザードおよびツールを提供する。このウィザードはユーザをプロトコルまたはプロセス中でステップ・バイ・ステップ方式で進ませ、特定のプロトコルを解決する方法を示す。ウィザードはプロトコルの解決中を、一連のシステム・プロンプトを提供することによって進む。これらのツールには、例えば、ユーザがプロトコルを注文に追加することができるようにするプロトコル追加；ユーザが注文の処理を一時的に停止することができるようにする注文停止；注文内の処方箋のキャンセルと同時に注文内の他の処方箋の処理を続行することができるようにする処方箋中止／キャンセル；ユーザが注文全体を完全にキャンセルすることができるようにする注文中止／キャンセル；薬剤が特許権保護を失うときにユーザが注文にフラグを立てて、再調剤時にジェネリック・ブランドが再調剤のために使用可能であるようにする、処方箋のプルおよび挿入；注文または処方箋を新しいインボイス（請求書）にコピーすることができるようにする新規処方箋コピー；および、即時注文見直しができるようにする注文見直しが含まれる。

連絡管理
図１０は、連絡管理のための全体的な流れ制御の一実施例を示す。８００で、いずれかの適用可能プロトコルが適用されるかどうかについての判断が行われる。プロトコルが適用される場合、８０５で、処方者に連絡を取ることなくこのプロトコルを解決することができるかどうかについての判断が行われる。連絡が必要でない場合、８１０でプロトコルが解決され、８１０でさらなる処理のために作業キューへサブミットされる。プロトコルを解決するために連絡が必要とされる場合、８１５で、処方者に対して発信される（アウトバウンド）ファクシミリがプロトコルを解決するかどうか、または、処方者への電話が必要とされるかどうかについての判断が行われる。オプショナルでアウトバウンド（発信される）ファクシミリによって解決することができるプロトコルについては、８２０でファクシミリがオプショナルで生成され、プロトコルを解決するために適切なフィールドがポピュレートされ、ポピュレートされた後、８２０でこのファクシミリが処方者に送信される。本発明の代替的実施形態によれば、ファックスの送信は待機キューの実行を開始させ、該待機キューは、ファックス送信から、処方者からの連絡が戻されるまでの時間の長さを計測する。計測された時間が、処方者による戻りの連絡が開始される前に所定値を超える場合、その注文はアウトバウンド・コール・キューに入れられる。

プロトコルを解決するために電話が必要とされる場合、８３０で連絡要求がアウトバウンド・コール・キューにルーティングされ、８３５でコールがスケジューリングされる。８４０で、処方者に対して、スケジューリングされた時間に電話がかけられ、８４５で処方者に電話発信が届く（着信する）場合、電話をかけたユーザは、８５０で、解決されるべきプロトコルを有する注文をバーチャル・シェルフ（仮想棚）から検索する。次いで８５５で、ユーザは処方者と共に注文を見直し、処方者に対してプロトコルを解決するために必要な情報を請求する。８６０でプロトコルが解決された後、この注文が８６５において作業キューに、さらなる処理のために入れられる。

別法として、電話がかけられるが、ユーザが８７０で応答を受信しなかった場合、この注文はアウトバウンド・コール・キューに戻り、８３５で別のコール（電話通話）がスケジューリングされ、ステップ８３５から８４５が繰り返される。８７５で処方者のために電話がかけられ、メッセージが残される場合、該アウトバウンド・コール・キューは、メッセージが処方者のために残されたことを反映するように更新され、８８０で、処方者からの電話またはその他の通信が受信されるための所定時間が設定される。８８５で戻りのコールが行われる前に所定時間が経過する場合、別のコール（電話）がスケジューリングされる。

８８５で処方者から戻された電話または返信されたファックスは、８９０でハント・ルーチンを起動して注文をシステム上で探し出す。電話のかけ直しが処方者から所定の時間内に受信される場合、８９０でその注文がシステム上で探し出され、８５０で該電話がシステム上のユーザに転送され、８５０でこのユーザは該注文をバーチャル・シェルフ（仮想棚）から検索する。次いで８５５で、ユーザは処方者と共にこの注文を見直し、プロトコルを解決するために必要な情報を処方者に対して求める。８６０でプロトコルが解決された後、該注文が８６５で作業キューに、さらなる処理のために入れられる。

８８５で、ファクシミリが処方者から受信される場合、このファクシミリは注文にリンクされ、ユーザはファクシミリ内に含まれた情報を見直してプロトコルを解決する。該プロトコルの解決にあたり、該注文が作業キューに、さらなる処理のために入れられる。

別法として、アウトバウンド・コール・キュー・ステップを通じて進むことなく、この連絡先に電話をかけることができる。注文をアウトバウンド・コール・キューにルーティングするのではなく、８７０でユーザは単に連絡先を選択し、８７５で、選択された連絡先へのコールを開始する。８８０で連絡先に電話が繋がる場合、ユーザは連絡先と共に注文を見直し、プロトコルを解決するために必要な情報を連絡先に対して求める。該プロトコルが解決された後、この注文は更新され、さらなる処理のために作業キューに入れられる。連絡先に電話が繋がらない場合、該注文はアウトバウンド・コール・キューにルーティングされる。

ファックス連絡管理
図１１は、ファックス連絡管理のための流れ制御の一実施例を例示する。９００で、解決されるべきプロトコルが選択される。プロトコルを解決するために必要なフィールドが、９０５でファクシミリ内でポピュレートされる。９１０で、連絡担当者が選択される。さらなるアクションが取られる前に応答を受信するための時間が９１５で選択される。手動のファクシミリを送信するか、システムにより生成された電子ファクシミリを送信するかについての判断が９２０で行われる。９２５で、選択された時間内に応答が連絡担当者から受信される場合、ファクシミリ内に含まれた情報に従って注文が更新される。受信されたファクシミリが注文の一部になるプロセスは、ファクシミリが受信されるモードに応じて異なる。９３０でファクシミリが手動または紙媒体としてのファックスである場合、９５０で注文がシステム上で探し出され、９５５でファクシミリ内の情報が入力される。次いで９６０で、手動または用紙のファクシミリがスキャンされ、イメージ化された注文文書、または、アーカイブ（記録保管）された書類束における注文文書のうち少なくとも１つに９６５で挿入される。別法として、スキャンされたイメージが、イメージ化された注文文書およびアーカイブされた書類束に挿入される。ファクシミリが電子的であるか、そうでない場合はあるファックス処理システムから別のファックス処理システムへと生成される場合、該注文は、ファクシミリ内に含まれた情報に基づいて更新され、該受信されたファクシミリは９７０でイメージ化された注文文書の一部となる。

手動または電子のインバウンド（入来）ファクシミリが、選択された時間内に受信されない場合、該注文は９７５でアウトバウンド・コール・キューにルーティングされ、その後に図１０のステップ８３０から８４５が続く。アウトバウンド・ファックスが連絡先向けに受信されるが、注文が連絡先との実際の連絡を必要とする場合、該注文は９４０でアウトバウンド・コール・キューにルーティングされる。

図１３Ａ〜１３Ｅは、図１０および図１１の代替的実施形態を表し、特定のプロトコル解決のコンテキストに対する連絡管理のための流れ制御を例示する。注文完成中に、注文が見直されて、必要とされた処方箋要素が存在するかどうが判断される。必要とされた処方箋要素は、処方箋の重要な要素を表すが、この要素は存在しなければならず、処方箋を調剤するために有効でなければならない。すべての必要とされた要素が存在する場合、注文が見直される。しかし、必要とされた要素が存在しない場合、注文が、少なくとも１つのさらなる作業キューへ追加処理のためにサブミットされる。アルファ（Ａｌｐｈａ）のみが未解決のまま残っているか、「ルーター、カウンタ、およびフラグ」プロトコルが未解決のまま残っているかについての判断が行われる。注文がロックされて追加の注文編集を防止し、調剤薬局にルーティングされる準備ができるまで、アルファ（Ａｌｐｈａ）プロトコルは自動的に作成および解決され、各注文ごとに存在する。

注文完成は、注文に関するいずれかの適用可能なプロトコルの解決に関連する。プロトコルをリレーショナル・データベースに対してチェックすることによって、プロトコルを解決することができない場合、処方者または処方者の事務所内の誰かに連絡を取り、プロトコルを解決することが１０２５で必要である場合がある。１０２５で、適用可能なプロトコルを解決するために処方者の連絡が必要である場合、１０３０で注文がアウトバウンド・コーリング・キューにルーティングされる。１０３５で注文がシステム・ユーザによって検索され、解決されるべき未解決のプロトコルを処方者にファックスすることによって、プロトコルを解決することができるかどうかについての判断が１０４０で行われる。１０４０で、処方者にファックスすることによってプロトコルが解決可能である場合、１０４５でファックスが処方者に送信される。ファックスを処方者に送信することで、タイム・スタンプがシステム内で作成される。１０５０で、タイム・スタンプから所定値に対する時間が計測され、タイム・スタンプから計測された時間が所定値を超える場合、ファックス待機時間がタイム・アウトされ、１０３０で注文がアウトバウンド・コール・キューにルーティングされ、ここでステップ１０３０から１０４０が繰り返される。

しかし、１０５５でインバウンド・ファックスが所定値内に受信される場合、１０６０で自動マッチ・プロセスが開始され、着信ファックスを、該着信ファックスが応答する相手である元の発信ファックスを引き起こした注文とマッチさせるように試みる。１０６５で注文が発見される場合、１０７０で、システム・ユーザは、着信ファックス内に含まれた情報を注文に入力する。次いで１０７０で注文が見直され、１０７５で解決処理のためにサブミットされる。別法として、１０６５で、自動マッチ・プロセスを通じて注文が発見されない場合、１０８０で、標準動作手順（プロシジャ）を通じて注文が処理されるようになる。標準動作手順（プロシジャ）には、例えば、ユーザが、受信された応答を、システム上の注文の現在の状態に対して見直すことが含まれる。例えば、注文がキャンセルされている場合、さらなるアクションは取られない。注文が調剤薬局に送信されている場合、ファックスされた応答がシステム・データと比較されて、正しい情報が処理されると判断される。システム上のデータがファックスされたデータと同じである場合、さらなるアクションは取られないが、矛盾が存在する場合、注文がユーザによってさらなる処理および解決のために見直される。１０５６で送信元から測定された所定値内で受信されない応答は、１０３０でアウトバウンド・コール・キューにルーティングされる。

インバウンド（着信）ファックス応答が１２５０でファックス・サーバ上で受信される場合、ファックス・サーバが該応答を、ファックス応答識別に基づいて１２５５で作業キューにルーティングする。１２６０ですべての注文対象が作業キューから検索され、１２６５でファックス応答が注文に付加される。１０５６で送信元から計測された所定値内で受信されない応答は、１０３０でアウトバウンド・コール・キューにルーティングされる。

ファックスを処方者に送信することによってプロトコルが解決可能でないと１０４０でユーザが判断する場合、１０８５でユーザは電話を開始し、１０９０で処方者にダイヤルする。１０９５で、ダイヤルされた番号に着信した際には、１１００で、ユーザは処方者または他の意思決定者に連絡を取ろうと試みる。１１００で処方者または他の意思決定者に到達される場合、１１０５でユーザは解決されるべきプロトコルを導入し、１１１０でコールを薬剤師に転送する。コール転送の後に次いで、あるいはそれと同時に、１１１５でユーザは注文を棚上げして注文を薬剤師にルーティングする。１１２０で薬剤師は注文をシェルフ（棚）から検索し、１１２５で介入を処方者と共に見直し、プロトコルを解決する。次いで１１３０で、注文が作業キューへさらなる処理のためにサブミットされる。

電話をかけた際に、１０９５で応答がない場合、１１３５でかけ直し伝票が完成され、コールが再スケジューリングされ、１１４０で、それに応じてアウトバウンド・コール・キューが更新される。１１４５でかけ直し伝票が印刷され、１０３０で注文がアウトバウンド・コール・キューにルーティングされる。別法として、１１００で、コールが応答を求めるが処方者または他の意思決定者が応答できない場合、１１５０でかけ直し伝票が完成され、１１５０で注文識別情報が処方者の事務所に残される。１１４０で、それに応じてアウトバウンド・コール・キューが更新される。１１４５でかけ直し伝票が印刷され、１０３０で注文がアウトバウンド・コール・キューにルーティングされる。

図１３Ｃは、１１５５で、アウトバウンド・コール・キュー・プロセスを通じて残されたメッセージに処方者が応答中であるときの、処方者のかけ直しプロセスの一実施例を例示する。１１６０でコールが、かけ直しのために指定されたハント・グループへルーティングされる。１１６５でシステム・ユーザはコールを受信し、初期情報を得る。１１７０で処方者が注文インボイス（請求書）情報を有する場合、１１７５で、システム・ユーザは注文を、インボイス番号または他のプロトコル解決アプリケーションを使用して検索する。別法として、１１８０でシステム・ユーザは、アウトバウンド・コール・キュー・プロシジャから生成されたかけ直し伝票を、患者のラスト・ネームを使用して検索する。システム・ユーザは注文を探し出した後に、１１１０でコールを薬剤師に転送する。次いでコール転送の後に、あるいはそれと同時に、１１１５でユーザは注文を棚上げして該注文を薬剤師にルーティングする。薬剤師は１１２０で注文をシェルフ（棚）から検索し、１１２５で介入を処方者と共に見直し、プロトコルを解決する。次いで１１３０で、該注文が作業キューへさらなる処理のためにサブミットされる。

別法として、１１９０で、処方者または処方者の事務所に連絡を取る代わりに管理プロトコルによって、適用可能なプロトコルを解決することができる場合、１１９５で適用可能な管理プロトコルが注文に、管理またはルール・リレーショナル・データベースから適用される。１１９０で、管理プロトコルの適用によって注文が解決可能でない場合、１２００で、注文が処方者または処方者の事務所へのいずれかの未解決コールを有するかどうかについての判断が行われ、そうでない場合、１２０５で、プロフェッショナル・プロトコル・リレーショナル・データベースを使用して注文が解決される。１２０５で少なくとも１つのプロフェッショナル・プロトコルが注文の解決に適用された後、１２１０で、どこで処方者または処方者の事務所への連絡が、いずれかの追加の未解決の適用可能プロトコルを解決するために必要であるかについての判断が行われる。１２１５で処方者のコールが必要でないと判断される場合、１２２０で薬剤師は、どの注文項目が求められるべきであるかを指示し、１０３０で注文をアウトバウンド・コール・キューにルーティングする。コールが必要であると判断される場合、１２２５で該注文が更新され、１２３０で作業キューへさらなる処理のためにルーティングされる。

しかし、注文が、それと、処方者もしくは処方者の事務所への未解決コールを関連付けている場合、処方者もしくは処方者の事務所が指定された待機時間内で応答するか、あるいは、注文が待機キュー内で費やす時間が所定の値を超えるまで、注文が１０５０で待機キューにキューイングされる。

図１４Ａ〜１４Ｅは、マネジド・ケア・プロトコルを有する注文の解決の一実施例を示す。マネジド・ケア・プロトコルはプロフェッショナル・プロトコル内で存続し、治療的に同等の代用薬剤が、処方されたものについて使用可能であるときに生じる。治療的に同等の代用薬剤の使用可能性は、「交換の機会」を提示する。処方者に電話またはファックスによって連絡が取られて、処方者が交換要求を承認するかどうかが判断される。

１３００で薬剤師が編集を見直し、最初に、処方箋がスクリーン・アウト或いはファックス可能であるかについて１３０５および１３１０でそれぞれ判断する。処方箋が「スクリーン・アウト」である場合、１３１５で、薬剤師は注文を標準動作プロシジャによって解決し、次いで１３２０で作業キューへ、１３２５でのさらなる処理のためにリリースする。スクリーン・アウトは、マネジド・ケアの機会または交換の機会を追求するために不十分なシステム・リソースまたは時間の結果として生じる。標準動作プロシジャには、例えば、注文が交換として追求されなかったことを示すシステム画面を更新することが含まれる。処方箋がスクリーン・アウトでないが、その代わりにファックス可能である場合、自動ファックスが起動される。アウトバウンド・ファックスに応答したかけ直しコール或いは他の連絡を受信するための日付および時間が１３３０で注文に付加される。１３３５でシステムは、注文の解決を促進すべく自動ファックスが起動されたことを反映するように更新される。１３４３で応答が所定の時間内に受信されるか、もしくは１３５０で注文が待機キュー内で費やす時間が所定の時間を越えるかするまで、１３４０で注文が待機キューに入れられる。１３４１で、注文が待機キュー内で費やす時間が所定の時間を越える場合、１４００で注文がアウトバウンド・コール・キューにルーティングされる。

アウトバウンド・コール・キューは、ファックス可能でない注文、または、注文が待機キュー内で費やした時間が所定値を超えている注文のためのものである。１４０５で、アウトバウンド・コール・キュー内の注文が、キューからユーザによって検索される。注文がキューから検索された後、１４００でユーザは注文処方者にダイヤルする。１４１５でアウトバウンド・コールが応答される場合、ユーザは１４２０で処方者または他の意思決定者に連絡しようと試みる。処方者または他の意思決定者に連絡がつく場合、１４２５でユーザは懸案事項を導入し、１４３０で、処方者に連絡を取る際の発信番号が安全なファックス番号である場合、１４３５でユーザは処方者のマスタ・ファイル情報を更新し、１３２５で自動ファックスを起動する。

別法として、処方者に連絡を取る際の発信番号が安全なファックス番号でない場合、１４４０でユーザは該コールを薬剤師に転送する。薬剤師へのコールの転送と同時か、あるいはそれに続いて、１４４５でユーザは注文を薬剤師のバーチャル・シェルフ（仮想棚）にルーティングする。１４５０で、薬剤師は注文をバーチャル・シェルフから検索し、１４５５で、解決されるべきプロトコルについて処方者と共に話し合う。１４６０でかけ直しが必要である場合、１４６５で薬剤師はかけ直しの日付、時間およびコメントを、処方者連絡追跡画面および連絡システム画面で入力し、１４７０で可視性プロトコル追加を割り当て、かけ直し伝票を完成させる。１４７５で、かけ直しを行うための時間がタイム・アウトにされる場合、１４００で注文がアウトバウンド・コール・キューにルーティングされ、図１４Ｃのステップ１４００から１４１５までが繰り返される。

１４８０で所定の時間内に受信されたインバウンド・コールは、１４８５で、かけ直しのためにそれらの指定されたハント・グループにルーティングされる。１４９０で、非薬剤師はコールを受信し、注文に関する初期情報を得る。最初に１４９５で、非薬剤師は注文を、そのインボイス番号を通じて探し出そうと試みる。しかし、発呼（コール）者がインボイス番号を有していない場合、１５００で非薬剤師は、患者のラスト・ネーム、かけ直し伝票、または他のプロトコル解決アプリケーションを使用して注文を探し出そうと試みる。コール者がインボイス番号を有していない場合、非薬剤師は、プロトコル解決を使用して注文を探し出そうと試みるようになり、このプロトコル解決によりユーザは必要に応じて画面を通じて進むことができる。

図１２Ａおよび１２Ｂは、本発明の代替的実施形態による、注文に付加されたマネジド・ケア・プロトコルを有する注文の解決の一実施例を示す。この実施形態によれば、薬剤交換（ジェネリック・バージョン（同効医薬品）への切り替え）のための承認は、処方箋が処理された後に発生する。承認された注文にはシステム上でフラグが立てられ、再調剤時に薬剤交換が発生するようになる。１６００で注文への編集が見直されて、注文が処方集コンプライアンス認証とマッチするかどうかが判断される。１６０５で交換認証がいずれかの他の薬局で入手可能である場合、１６１０で注文が監督者にルーティングされる。該監督者は１６１５で他の監督者と連絡を取る。処方集コンプライアンスを示すファックスが１６２０で受信される。当該処方集コンプライアンス・レターが１６２５でスキャンされ、注文に挿入される。注文が１６３０でアウトバウンド・コーリング・キューにルーティングされる。検証コールが１６３５で行われ、１６４０でその交換が検証される場合、１６４５で薬剤師がシャドー・ファイル内で処方箋に注釈を付け、１６５０で、法律によって必要とされる患者および処方者レターを印刷するアプリケーションにおいて好ましくない処方箋を手動で入力する。このアプリケーションは、クオンセット・ハット（Ｑｕｏｎｓｅｔ ｈｕｔ）と呼ばれる。次いで、当該ファックスの処方集コンプライアンス・レターのハード・コピーが１６５５で破棄され、１６６０で注文が作業キューに、さらなる注文処理のためにリリースされる。１６４０で交換が検証されない場合、１６６５で注文がマネジド・ケア標準動作プロシジャによって処理され、１６７０で作業キューに、さらなる注文処理のためにリリースされる。標準動作プロシジャには、例えば、交換が承認されないときに引き続いて行われる手動のプロシジャが含まれ、標準動作プロシジャにより、システム・ファイルを更新して注文処理が継続できるようにすることができる。

しかし、１６０５で交換認証が入手可能でない場合、１６７５で処方箋コンプライアンス・レターにマッチしようとする試みがある。１６８０で、好ましくない処方箋がクオンセット・ハットにおいて手動で入力される。処方集コンプライアンス・レターおよび処方箋ハード・コピーがシステムに１６８５でスキャンされる。スキャンされたイメージが他のイメージ注文文書に１６９０で挿入される。１６９５で注文が作業キューに、さらなる注文処理のためにリリースされる。１７００で、元の処方集コンプライアンス・レターが標準動作プロシジャによって裁断される。

図１３Ａ〜１３Ｂは、本発明の代替的実施形態による、注文に付加されたマネジド・ケア・プロトコルを有する注文のプロトコル解決の実施例を示す。１９００で、プロトコルがマネジド・ケア注文に追加される。１９０５でマネジド・ケア注文が見直されて、該注文が前のファックスとマッチするかどうかが判断される。１９１０で、交換認証が別の薬局内で存在する場合、１９１５で注文が監督者にルーティングされ、１９２０で該監督者は他の監督者に連絡を取る。１９２５でファックスが受信され、１９３０で前のファックスがイメージ化され、注文イメージ注文文書に挿入される。次いで１９３５で、注文がアウトバウンド・コール・キューへ検証コールのためにルーティングされる。１９４０で検証コールが行われ、もし１９４５で交換が検証される場合には、１９５０で、プルおよびコピー（ＰＵＬＬＣ／ＰＵＬＬＮ）ユーティリティを使用して、処方箋のための再調剤が新しい処方箋番号と共にシステムに入力される。プルおよびコピー・ユーティリティは処方箋を新しいインボイス（請求書）にコピー（複写）する。次いで１９５５で、この注文が薬剤師にルーティングされ、１９６０で、マネジド・ケア標準動作プロシジャに従って交換が処理される。１９６５で、好ましくない処方箋がクオンセット・ハットにおいて手動で入力される。１９７０で処方者レターが生成され、１９７５で前のファックス・コピーが標準動作プロシジャによって破棄される。注文は作業キューに、さらなる注文処理のためにリリースされる。１９４５で交換が検証されない場合、１９４６で、マネジド・ケア標準動作プロシジャに従って該注文が処理される。

１９１０で交換認証が別の薬局内に存在しない場合、１９１６で該注文が非薬剤師にルーティングされ、１９１７で前のファックスがスキャンされ、イメージ化される。このイメージ化された前のファックスが、１９１８で、イメージ化された注文文書に付加され、１９１９で処方箋に注釈が付けられる。１９５０で、ＰＵＬＬＣ／ＰＵＬＬＮユーティリティを使用して、処方箋のための再調剤が新しい処方箋番号と共にシステムに入力される。次いで１９５５で、この注文が薬剤師にルーティングされ、１９６０で、マネジド・ケア標準動作プロシジャに従って交換処理される。１９６５で、好ましくない処方箋がクオンセット・ハットに手動で入力される。１９７０で処方者レターが生成され、前のファックス・コピーが標準動作プロシジャによって１９７５で破棄される。１９８０で該注文が作業キューに、さらなる注文処理のためにリリースされる。

コマンドおよび制御
図１７は、コマンドおよび制御モジュールへの情報可視性の概略図を示す。コマンドおよび制御モジュールは、注文処理システムの頂上にあるユーザ・インタフェースである。コマンドおよび制御モジュールは、作業キューのアクティビティ、個別ユーザのアクティビティ、プロセス制御情報、システム実働およびシステム・リソース可用性を追跡する。コマンドおよび制御モジュールはいずれかの単一のキュー或いはキューのグループについての情報を抽出し、抽出されたデータに対して、標準データベース・クエリ・ツールを通じて操作を実行して、いずれかの単一の、あるいは組み合わせの、システムの側面（アスペクト）についての状況レポートを作成することができる。結果として生じるレポート内のデータは、それらを生成するために使用された、基礎データにハイパーリンクされる。

図１８は、コマンドおよび制御モジュールのユーザ・インタフェースの一部である、計器盤の一実施例を示す。図１８は、選択されたシステム・キューの状態を表す計器盤を含む画面を示す。計器盤のゲージは、該計器盤内に存在する各選択されたキューにおける定量的負荷を示す。各ゲージはまた、各表現されたキューのヘルスを色によって示すものである。各ゲージが呈することができる色の範囲は所定であり、少なくとも３つのキュー・ヘルス状態を示すように選択される。第１の色は、キューが正常であり、過負荷になっていないことを示す。第２の色は、警告、および、キューが臨界負荷ポイントに近づきつつあることを示す。第３の色は、キューがその臨界負荷ポイントを超えており、該負荷をリバランス（再調整）してキュー・レベルを受け入れ可能な動作範囲内に下げるためにシステム調整が行われなければならないことを示す。

各ゲージは、ゲージ表現を担う基礎データにハイパーリンクされる。特定のゲージの選択は、該ゲージを表現するキュー内のすべての注文に至るまでドリル・ダウンする。選択されたキュー内の注文を、図１９に示すようにグラフで、あるいは図２０に示すように表形式（フォーマット）で、表示されるように構成することができ、いかなるグラフ形式の縦軸および横軸、または表の列および行も、ユーザによって、キュー内の注文をいくつかの変数によって表現するように構成可能であり、これには例えば、キューに最新に到着した注文から、同じキュー内で最長に保持された注文までの時間を、所定の間隔にスライスして、キュー内の注文の分布を時間単位で示すことが含まれる。この一実施例を図２１に示す。

図１９は、選択システム・キューのグラフ表現を示す。図２０は棒グラフであり、ここでは各棒は特定のキューを表し、棒の高さはそのキュー内の注文数を表す。棒グラフ内の各棒はその基礎となるキューにハイパーリンクされ、該基礎データにリンクすることにより、該選択されたキュー内のすべての注文のリストが得られる。

図２０は、選択システム・キューを表フォーマット（形式）で示し、このフォーマットでは、各キューが、該キュー内に含まれた注文のカテゴリまたはタイプ、いずれか１つのキュー内のシステム注文の総数、および、いずれか１つのキュー内にある合計のシステム注文の割合まで分析される。キューのカテゴリには、例えば、注文が新しい処方箋であるか、再調剤処方箋であるか、または、新しい処方箋および再調剤処方箋の混合であるか、注文なしで支払いのみである注文がいくつあるか、および、その他の包括的なカテゴリ内にいくつの注文があるかが含まれる。表エントリはそれらのサポートするデータにハイパーリンクされ、ユーザがその基礎データにリンクまたはドリル・ダウンできるようになる。

図２２は、選択キューの棒グラフおよび選択キューの表が共に提供される結合画面を表す。棒グラフ内で提示されたキューは必ずしも表内で提示されたものと同じキューでなくてもよい。

本発明のコマンドおよび制御モジュールはまた、注文処理システム内の注文の追跡のための、いくつかのポジティブ制御メカニズムも提供する。あるポジティブ制御メカニズム、および本発明の代替的実施形態は、各システム・キューが、注文が直接に受信される場合の発信元である先行キューからの注文の受信を確認応答することに関連する。もう１つのポジティブ制御メカニズム、および本発明の代替的実施形態は、本発明の注文処理システムが、注文が所定の時間よりも長く特定のものに存在しているときにはいつでもユーザにアラート（警報）を送信するか、あるいはユーザにページングする（呼び出す）ことに関連する。ポジティブ制御はまたユーザに、システム内におけるいかなる注文をも探し出し、薬局または注文処理システム中を通じた注文の行程を見直す能力も提供する。ポジティブ制御データベースに問い合わせて注文を見直す方法には、例えば、インボイス番号によるもの、処方箋番号によるもの、会員番号によるもの、および、作業注文ＩＤによるものが含まれる。上記の情報のいずれか１つで開始して、ユーザは例えば、注文が現在所在する先であるキュー、注文がこれまでに所在していたキュー、注文が各キュー内で費やした時間の量、および、注文が薬局に存在していた合計経過時間を識別することができる。

本発明のコマンドおよび制御モジュールを、ブラウザベースの機能性を提供するように構成することができ、このモジュールは、いかなる適切なパーソナル・コンピュータまたはワークステーション上でも動作することができる。

ネットワーク構成
図２３は、本発明によるシステムのための１つの可能なハードウェアおよびネットワーク構成を示す。ＰＣワークステーション２３００はデータ・サーバ２３０５に接続され、データ・サーバ２３０５はローカル・エリア・ネットワーク（ＬＡＮ）２３１０に接続される。データ・サーバ２３０５はＬＡＮ上の他のサーバおよびメインフレーム・システム２３１５と通信して、ユーザにワークケースを提示する。また、ＰＣワークステーション２３００に接続されるものは、バイオメトリック・キャプチャ装置２３１６であり、これはＰＣワークステーション２３００、およびしたがってデータ・サーバ２３０５、ＬＡＮ２３１０およびシステム・メインフレーム２３１５へのアクセスを制御する。光学スキャナ２３２０（バーコード読み取り機能を含む場合がある）はイメージ・サーバ２３２５に接続され、イメージ・サーバ２３２５はＬＡＮ２３１０に接続される。ワークフロー・サーバ２３３０はＬＡＮ２３１０に接続され、注文の流れを管理する。光ディスク・サーバ２３３５およびジュークボックス２３４０はＬＡＮ２３１０に、イメージのアーカイブ（記録保管）の目的で接続される。また、ＬＡＮ２３１０に接続されるものは、システム処理ロジックを識別するリレーショナル・データベースのシステム２３４５である。ＬＡＮ２３１０に接続されたコンポーネントの全体の集合は、単一のハブ２３５０または注文処理センターを表す。本発明の１つのネットワーク構成は、それぞれ中央システム・メインフレーム２３１５に接続された、地理的に異なるハブ２３５１、２３５２および２３５３のシステムからなる。

分散注文処理
本発明の代替的実施形態によれば、図１の各プロセッサによって実行される機能を、いくつかのハブに渡って分散させることができる。例えば、ハブ１は、入来する郵便の前処理およびスキャンのすべてを行うのに対して、ハブ２はすべての非臨床データのエントリを担い、ハブ３は臨床注文エントリおよび／または検証のみを行う。次いで、ハブ４は実際の調剤および出荷を実行するようになる。別法として、フロント・エンドおよびバック・エンド・タスクに基づいて、処理タスクを複数のハブに渡って分散させることができる。例えば、ある単一のハブはすべての注文処理ステップまでを実行し、注文を単一の調剤薬局（もしくは複数の薬剤局）にルーティングすることを含むことができるのに対して、第２のハブはすべての注文の調剤および出荷ステップを実行するようになる。

別法として、各ハブはその割り当てられた地域からの注文を受信および処理するようになる。例えば、ニューヨーク・ハブは、米国の北東部における州からの注文を受信および処理するようになり、中央カリフォルニア・ハブは、米国の南西部における州からの注文を受信および処理するようになる。

本発明は、医療処方箋の処理に関連するアプリケーションに限定されず、通信販売業界が紙媒体文書および手動の文書送信方法への依存を減らすことを望むいかなる状況にも適用することができる。本明細書で説明した様々なプロセスおよびフローチャートを、異なるものに修正しおよび／または異なる順序付けをすることができる。

概して、本発明の実施形態の様々な構成要素をハードウェア、ソフトウェア、またはそれらの組み合わせにおいて実施することができることは、強調されるべきである。このような実施形態では、様々な構成要素およびステップがハードウェアおよび／またはソフトウェアにおいて実施されて、本発明の様々な機能が実行される。いかなる現在利用可能なまたは将来開発されるコンピュータ・ソフトウェア言語および／またはハードウェア・コンポーネントも、本発明のこのような実施形態において使用することができる。例えば、上述の機能性の少なくともいくつかを、ＣまたはＣ＋＋プログラミング言語を使用して実施することができる。

本発明の好ましい実施形態および代替的実施形態をここで詳細に説明した。しかし、これらの特定の実施形態のこうした説明は、本発明の概念の基礎をなしている原理を例示するにすぎないことに留意されたい。したがって、開示された実施形態の様々な改良（修正）は、本発明の精神および範囲から逸脱することなく、いわゆる当業者には明らかになるであろうことが企図される。

本発明によれば例えばイメージング技術を使用して、通信販売処方箋の品質を改善し、その処理時間が高速化される。本発明の自動イメージング環境は、処方箋および処方箋見直しの適時かつ正確な処理、ならびに、完全なワークケース文書化のより容易な検索が保証される。処方箋注文に適用される、柔軟性があり構成可能なリレーショナル・データベースにより、全体的な処方箋注文処理時間が短縮される。

本発明の注文処理システムの一実施形態のアーキテクチャ（構成）を例示するブロック図である。 イメージ化された注文文書を例示する画面キャプチャの図である。 本発明の注文処理システムの一実施形態に係る全体の流れ制御を例示する高レベルのブロック図である。 注文の処理のための高レベルのブロック図を示す図である。 注文の反復適用および解決を例示する流れ図を示す図である。 ヘッダ・エントリのための流れ制御図を示す図である。 メール（郵便）通信チャネルで受信された注文を前処理するための流れ制御図を示す図である。 メール（郵便）通信チャネルで受信された注文を前処理するための流れ制御図を示す図である。 非臨床データ・エントリ／検証を例示する画面キャプチャの図である。 注文完成のための流れ制御図を示す図である。 連絡管理のための流れ制御図を示す図である。 ファックス・プロセスのための流れ制御図を示す図である。 臨床データ・エントリ／検証を例示する画面キャプチャの図である。 連絡管理のための重複実施形態の流れ制御図を示す図である。 連絡管理のための重複実施形態の流れ制御図を示す図である。 連絡管理のための重複実施形態の流れ制御図を示す図である。 連絡管理のための重複実施形態の流れ制御図を示す図である。 連絡管理のための重複実施形態の流れ制御図を示す図である。 マネジド・ケア注文の解決のための流れ制御図を示す図である。 マネジド・ケア注文の解決のための流れ制御図を示す図である。 マネジド・ケア注文の解決のための流れ制御図を示す図である。 マネジド・ケア注文の解決のための流れ制御図を示す図である。 マネジド・ケア注文の解決のための流れ制御図を示す図である。 マネジド・ケア注文の解決のための重複実施形態の流れ制御図を示す図である。 マネジド・ケア注文の解決のための重複実施形態の流れ制御図を示す図である。 マネジド・ケア注文の解決のための重複実施形態の流れ制御図を示す図である。 マネジド・ケア注文の解決のための重複実施形態の流れ制御図を示す図である。 コマンドおよび制御への情報の流れの概略図を示す図である。 コマンドおよび制御インターフェースからの計器盤画面の一実施例を示す図である。 コマンドおよび制御インターフェースからの棒グラフ・キュー・ポピュレーション（列分布数）画面の一実施例を示す図である。 コマンドおよび制御インターフェースからのキュー（列）データ表画面の一実施例を示す図である。 コマンドおよび制御からのキュー（列）データ表画面の一実施例を示す図であり、表のたて列は、注文のポピュレーション（分布数）が特定のキュー（列）内にある時間の長さに関係する時間間隔（タイム・スライス）を表す図である。 コマンドおよび制御インターフェースからの、キュー（列）データ表および棒グラフ・キュー・ポピュレーション（列分布数）の結合画面の一実施例を示す図である。 本発明によるシステムのための１つの可能なハードウェアおよびネットワーク構成を示す図である。

符号の説明

１０ 医療処方箋注文処理システム
１５ 標準スリッタ・プロセッサ
２０ 標準ファクシミリ・プロセッサ
２５ 標準着信ペーパーレス注文プロセッサ
３０ 文書準備プロセッサ
３５ 例外処理プロセッサ
３６ イメージ・ディスプレイ
４０ 高速スキャナ・プロセッサ
４５ イメージ・ディスプレイ
５０ イメージ品質管理プロセッサ
５５ コンピュータ可読メディア
６０ ファイル・ストレージ・ルーム
６５ 注文ヘッダ・プロセッサ
７０ 注文完成プロセッサ
７５ 注文見直しプロセッサ
８０ 管理プロトコル解決プロセッサ
８５ プロフェッショナル（専門）プロトコル解決プロセッサ
９０ 高速印刷プロセッサ
９５ 注文調剤プロセッサ
１００ 出荷ステーション・プロセッサ
１０１ コマンドおよび制御プロセッサ
１０２ ワークフロー・プロセッサ
２３００ ＰＣワークステーション
２３０５ データ・サーバ
２３１０ ローカル・エリア・ネットワーク（ＬＡＮ）
２３１５ サーバおよびメインフレーム・システム
２３２０ 光学スキャナ（バーコード読み取り機能を含む場合がある）
２３２５ イメージ・サーバ
２３３０ ワークフロー・サーバ
２３３５ 光ディスク・サーバ
２３４０ ジュークボックス
２３４５ リレーショナル・データベースのシステム
２３５０ ハブ
２３５１、２３５２ ハブ

Claims (34)

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. 注文注釈ビルダーを使用して注文に注釈を付ける手段をさらに含み、該注文注釈ビルダーは、少なくとも１つのプル・ダウン・メニューから注釈を作成することを特徴とする請求項２４記載の方法。
27. ユーザアクセスを使用可能キューに制限する手段をさらに含むことを特徴とする請求項２４記載の方法。
28. 自動処理中にキューを通じて前記注文を追跡する手段をさらに含むことを特徴とする請求項２４記載の方法。
29. 前記注文が調剤される必要があるときを計算する手段をさらに含むことを特徴とする請求項２４記載の方法。
30. ユーザ・インタフェース・サーバ・プログラムによってアクセスされた少なくとも１つの医療処方箋のための注文の自動処理のための注文処理データ構造を含むコンピュータ可読メモリ・デバイスであって、前記ユーザ・インタフェース・サーバ・プログラムは、前記コンピュータ可読メモリ・デバイス内でエンコードされ、データ処理システム内のプロセッサによって実行され、前記データ構造は複数のエントリを含み、前記複数のエントリは、
    患者識別子と、
    処方者識別子と、
    少なくとも１つの薬剤識別子と、
    会員識別子と、
    注文識別子とを含み、
    前記ユーザ・インタフェース・サーバ・プログラムは前記データ構造にアクセスして、前記患者識別子、前記処方者識別子、前記少なくとも１つの薬剤識別子、前記会員識別子、および前記注文識別子を使用することによって前記注文を処理することを特徴とするコンピュータ可読メモリ・デバイス。
31. 支払い識別子をさらに含み、
    前記ユーザ・インタフェース・サーバ・プログラムは前記データ構造にアクセスして、前記患者識別子、前記処方者識別子、前記少なくとも１つの薬剤識別子、前記会員識別子、前記注文識別子、および前記支払い識別子を使用することによって前記注文を処理することを特徴とする請求項３０記載のコンピュータ可読メモリ・デバイス。
32. 医療処方箋注文を処理するためのシステムであって、
    注文受信モジュールと、
    注文イメージング・モジュールと、
    特別処理モジュールと、
    注文アーカイビング・モジュールと、
    注文エントリ・モジュールと、
    ファックス受信モジュールと、
    注文割り当てモジュールと、
    プロトコル解決モジュールと、
    データ検証モジュールと、
    出荷モジュールと
    を具備することを特徴とするシステム。
33. 医療処方箋注文を処理するためのシステムであって、
    コンピュータ・ネットワークと、
    前記コンピュータ・ネットワークに接続されたメインフレーム・コンピュータと、
    前記コンピュータ・ネットワークに接続された少なくとも１つのハブと
    を含み、前記ハブは、
    注文受信モジュールと、
    注文イメージング・モジュールと、
    特別処理モジュールと、
    注文アーカイビング・モジュールと、
    ファックス受信モジュールと、
    ワークフロー・モジュールと、
    プロトコル解決モジュールと、
    出荷モジュールと
    を含むことを特徴とするシステム。
34. 少なくとも１つの医療処方箋のための注文を処理するためのシステムであって、
    コンピュータ・ネットワークと、
    前記ネットワークに接続されたコンピュータ・プロセッサと、
    前記コンピュータ・プロセッサに接続された、注文、注文のイメージ、およびソフトウェア・モジュールを格納するためのストレージおよびメモリと、
    前記コンピュータ・プロセッサに接続された、文書をスキャンするための少なくとも１つのスキャナと、
    前記コンピュータ・プロセッサに接続された、ユーザと通信するための通信リンクと、
    前記コンピュータ・プロセッサに接続された、注文イメージを表示するための少なくとも１つのディスプレイと、
    前記コンピュータ・ネットワークに接続された、少なくとも１つのプロトコル解決データベースと、
    前記ネットワークと通信する少なくとも１つのファクシミリ機と、
    コンピュータ可読格納媒体（ストレージ・メディア）に格納されたイメージ品質管理処理モジュールであって、前記イメージ品質管理処理モジュールは前記コンピュータ・プロセッサ内で実行可能であり、前記イメージ品質管理処理モジュールは、前記少なくとも１つのスキャナによって取り込まれたイメージの見直し、受け入れ、および／または拒否を行うように構成されるイメージ品質管理処理モジュールと、
    コンピュータ可読格納媒体（ストレージ・メディア）に格納された注文ヘッダ処理モジュールであって、前記注文ヘッダ処理モジュールは前記コンピュータ・プロセッサ内で実行可能であり、前記注文ヘッダ処理モジュールは、前記注文に関連付けられた非臨床データの見直しおよび受信を行うように構成される注文ヘッダ処理モジュールと、
    コンピュータ可読格納媒体（ストレージ・メディア）に格納された注文完成処理モジュールであって、前記注文完成処理モジュールは前記コンピュータ・プロセッサ内で実行可能であり、前記注文完成処理モジュールは、前記注文に関連付けられた臨床データの見直しおよび受信を行うように構成される注文完成処理モジュールと、
    コンピュータ可読格納媒体（ストレージ・メディア）に格納されたプロトコル解決処理モジュールであって、前記プロトコル解決処理モジュールは前記コンピュータ・プロセッサ内で実行可能であり、前記プロトコル解決処理モジュールは、前記注文に関連付けられた適用可能なプロトコルを解決するように構成されるプロトコル解決処理モジュールと、
    コンピュータ可読格納媒体（ストレージ・メディア）に格納されたドクター・コール処理モジュールであって、前記ドクター・コール処理モジュールは前記コンピュータ・プロセッサ内で実行可能であり、前記ドクター・コール処理モジュールは、前記注文に関する情報を受信するように構成されるドクター・コール処理モジュールと、
    コンピュータ可読格納媒体（ストレージ・メディア）に格納されたコマンドおよび制御処理モジュールであって、前記コマンドおよび制御処理モジュールは前記コンピュータ・プロセッサ内で実行可能であり、前記コマンドおよび制御処理モジュールは、前記システムへの入力の監視および受信を行うように構成されるコマンドおよび制御処理モジュールと、
    コンピュータ可読格納媒体（ストレージ・メディア）に格納された注文調剤モジュールであって、前記注文調剤モジュールは前記コンピュータ・プロセッサ内で実行可能であり、前記注文調剤モジュールは、前記注文を調剤するように構成される注文調剤モジュールと、
    コンピュータ可読格納媒体（ストレージ・メディア）に格納された出荷処理モジュールであって、前記出荷処理モジュールは前記コンピュータ・プロセッサ内で実行可能であり、前記出荷処理モジュールは、前記注文のための出荷積荷目録を処理するように構成される出荷処理モジュールと
    を具備することを特徴とするシステム。

Images