"少なくとも1つの医療処方箋のための注文の自動処理のための方法であって、a.コマンド及び制御モジュールにて前記注文を受信するステップであって、該注文は事前に定義された文書チャネルおよび電子チャネルを含む通信チャネルを通じて受信され、文書準備プロセッサによって該注文にあらかじめ関連づけられた文書タイプまたはカテゴリに対応して貼られたラベルを通じて識別する、ステップと、b.例外処理プロセッサにて前記注文がイメージへの変換を必要とするかどうかを前記ラベルに応じて判定するステップと、c.前記注文がイメージへの変換を必要とする場合には高速スキャンプロセッサにて該注文をイメージに変換するステップと、d.イメージ品質管理プロセッサにて前記イメージを前記注文へ関連付けるステップと、e.コマンド及び制御プロセッサにて前記注文を少なくとも1つのキューに割り当てるステップであって、該キューは複数のキューから選択されるステップと、f.注文ヘッダプロセッサ、注文完成プロセッサ、及び/または、注文見直しプロセッサのうち少なくとも一つにて前記注文を処理するステップであって、前記注文を処理する前記ステップは、該注文を少なくとも1つの最初のキューから最後のキューまで、少なくとも1つの中間キューを通じて進めるために必要なアクションを実行することを含み、前記最後のキューは、出荷ステーションプロセッサにて前記注文が患者に出荷される結果となるステップと、g.コマンド及び制御プロセッサにてポジティブ制御データベースに問い合わせることによって前記注文を、前記複数のキューおよびいずれか1つのキューにおいて該注文が費やす時間の長さを通じて追跡するステップと、h.コマンド及び制御プロセッサにて前記注文がいずれか1つのキューにおいて費やす時間の長さが事前定義された値を越えるかどうかかつ該事前定義された値を超えているかどうかを判断し、アラート警報がユーザに対して送信されるステップと、i.注文ヘッダプロセッサ、注文完成プロセッサ、及び/または、注文見直しプロセッサのうち少なくとも一つにて、ユーザに割り当てられたプロファイルに呼応して、ユーザによって前記複数のキューのうちの少なくとも1つのキューに対して事前定義されたアクセスのレベルを提供するステップとを具備することを特徴とする方法。各ステップまたはその組み合わせは分散され、地理的に離れた場所で実行されることを特徴とする請求項1記載の方法。前記事前定義された通信チャネルは、ファクシミリ、電話、ワールドワイドウェブ、メール、もしくはそれらの組み合わせのうちの少なくとも1つから選択されることを特徴とする請求項1記載の方法。前記事前定義された通信チャネルは前記メールを含み、前記方法は、前記注文を受信する前記ステップの後に該注文を前処理するステップをさらに含み、該注文を前処理する前記ステップは、a.前記メールを開封するステップと、b.前記開封されたメールをスキャンするために準備するステップと、c.前記開封されたメールをスキャンするステップと、d.前記開封されたメールの前記スキャンされたイメージを見直すステップと、e.前記開封されたメールの前記スキャンされたイメージを格納するステップと、f.前記開封されたメールの前記スキャンされたイメージを処理するためにキューイングするステップとを具備することを特徴とする請求項3記載の方法。前記開封されたメールをスキャンする前記ステップは、高解像度のカラースキャナを使用して行われ、前記スキャンされたイメージはカラーであることを特徴とする請求項4記載の方法。前記開封されたメールを前記スキャンのために準備する前記ステップは、a.前記開封された封筒に、前記メールが開封される日付でスタンプを押すステップと、b.前記開封されたメールを書類束に集積するステップと、c.前記書類束を順序付けするステップとを具備することを特徴とする請求項4記載の方法。前記書類束を順序付けする前記ステップは、a.前記開封されたメールのコンテンツにバーコードを付与するステップと、b.前記開封されたメールのうち事前定義された基準を満たさない例外項目を除去するステップと、c.注文セパレータを挿入するステップと、d.バッチヘッダを挿入するステップとを具備することを特徴とする請求項6記載の方法。前記例外項目は、不正な処方箋、現金払いによる注文および3次元の物体を含むことを特徴とする請求項7記載の方法。前記例外項目または前記例外項目の表現は、フラットベッドスキャナを用いてスキャンされることを特徴とする請求項7記載の方法。前記開封されたメールをスキャンする前記ステップは、識別番号を各書類束に割り当て、識別番号を前記書類束の一部である各文書に割り当てるステップを含むことを特徴とする請求項6記載の方法。前記開封されたメールの前記スキャンされたイメージを見直す前記ステップは、前記スキャンされた開封後メールの前記イメージを受け入れるか或いは拒否するかを選択するステップを含み、前記開封後メールのスキャンされたイメージを拒否することは、追加のスキャンされたイメージが受け入れられるまでステップcおよびdを繰り返す結果となることを特徴とする請求項4記載の方法。前記スキャンされたイメージを格納する前記ステップは、前記スキャンされたイメージをコンピュータ可読メディアに格納するステップを具備することを特徴とする請求項4記載の方法。前記開封されたメールを所定の方法で格納して、該開封されたメールが、前記コンピュータ可読メディアに格納された対応するスキャン済みイメージに索引付けされるようにするステップをさらに具備することを特徴とする請求項12記載の方法。前記開封されたメールをスキャンする前記ステップは、支払文書を注文文書から分離するステップを備えることを特徴とする請求項4記載の方法。前記注文を処理する前記ステップは、a.前記注文に関連付けられたイメージを受信して見直すステップと、b.前記注文に関連付けられた各イメージを分類するステップと、c.前記注文の詳細を検証するステップと、d.前記注文を処理装置に入力するステップと、e.前記注文の正当性を確認するステップと、f.少なくとも1つのプロトコルを前記注文に適用して、該注文を前記最後のキューに向けて進めるステップと、g.前記注文を、前記少なくとも1つのプロトコルが適用された後に見直すステップとを備えることを特徴とする請求項1記載の方法。前記少なくとも1つのプロトコルを前記注文に適用する前記ステップは、a.前記注文を見直して、前記少なくとも1つのプロトコルが適用されるべきであるかどうかを判断するステップと、b.少なくとも1つのデータベースに対して適用されるときに前記少なくとも1つのプロトコルを解決するステップと、c.前記注文を見直して、前記少なくとも1つのプロトコルが適用されるかどうかを判断する前記ステップ、および、解決されるまで、前記少なくとも1つのデータベースに対して前記少なくとも1つのプロトコルを解決する前記ステップを繰り返すステップとを備えることを特徴とする請求項15記載の方法。前記少なくとも1つのデータベースは、臨床データベース、プランデータベース、ルールデータベース、連絡先データベース、受け取り可能アカウントデータベース、処方集データベース、価格設定データベース、クライアントプロフィールデータベース、患者履歴データベース、およびそれらの組み合わせのうち少なくとも1つから選択されることを特徴とする請求項16記載の方法。前記少なくとも1つのプロトコルを適用する前記ステップは、a.前記注文を見直して、前記注文に関連した情報の欠落、または不明瞭性があるかどうかを判定するステップと、b.前記注文の一時的な停止、前記処方箋のキャンセル、前記注文のキャンセル、ジェネリックブランドの薬剤の使用可能性を有する前記注文に対しての警報発令、前記注文の新しい請求書への関連付け、および前記注文の見直しの少なくとも1つを具備するステップによって、前記欠落もしくは不明瞭な情報を解決するステップとを備えることを特徴とする請求項16記載の方法。前記注文を見直して、前記少なくとも1つのプロトコルが適用されるかどうかを判断する前記ステップは、a.前記注文を解決するために連絡先が必要であるかどうかを判断するステップと、b.前記連絡先が必要であるとき、連絡のモードを選択するステップと、c.前記連絡のモードを開始するステップとを備えることを特徴とする請求項16記載の方法。前記連絡のモードは、ファクシミリ、電話、eメール、ワールドワイドウェブ、郵便、および、それらの組み合わせのうち少なくとも1つから選択されることを特徴とする請求項19記載の方法。前記連絡先は、処方者、患者、プラン管理者、およびそれらの組み合わせのうち少なくとも1つから選択されることを特徴とする請求項19記載の方法。前記連絡のモードが少なくともファクシミリであるとき、前記連絡のモードを開始する前記ステップは、a.前記ファクシミリ文書を生成するステップと、b.前記ファクシミリ文書を前記連絡先に送信するステップとを備えることを特徴とする請求項19記載の方法。前記ファクシミリ文書を生成する前記ステップは、a.ファクシミリモードを選択するステップと、b.前記少なくとも1つのプロトコルを選択するステップと、c.使用可能なファックスフィールドを追加するステップと、d.前記連絡先を選択するステップと、e.前記連絡先からの応答を受信するための待機時間を選択するステップとを備えることを特徴とする請求項22記載の方法。前記連絡先からの前記応答は、ファクシミリまたは電話通話のうち少なくとも1つであることを特徴とする請求項23記載の方法。前記連絡先からの前記応答が電話通話である場合には、前記方法は、a.前記電話通話を、かけ直すために指定されたハントグループにルーティングするステップと、b.前記注文を前記キューから検索するステップと、c.前記連絡先から情報を得るステップと、d.前記注文を更新するステップとをさらに具備することを特徴とする請求項24記載の方法。前記連絡先からの前記応答が少なくともファクシミリである場合には、a.前記ファクシミリを前記注文に、自動マッチプロセスを通じてマッチさせるステップと、b.前記注文を、前記ファクシミリについての情報により更新するステップと、c.前記ファクシミリを前記注文に付加するステップとをさらに備えることを特徴とする請求項24記載の方法。前記待機時間が、事前定義された値を越える場合には、a.前記注文を、アウトバウンドコールキューにルーティングするステップと、b.コールをスケジューリングするステップと、c.前記連絡先にコールするステップと、d.前記注文を前記アウトバウンドコールキューから検索するステップと、e.前記注文を前記連絡先に照らして見直すステップと、f.前記注文を解決するステップと、g.前記解決するのに呼応して前記注文を更新するステップとをさらに備えることを特徴とする請求項23記載の方法。前記連絡先にコールする前記ステップが連絡先に着信できない場合には、前記連絡先にコールする前記ステップは、a.かけ直しフォームを完成させるステップと、b.前記アウトバウンドコールキューを更新するステップと、c.コールをスケジューリングする前記ステップ、および、前記連絡先にコールする前記ステップを、前記連絡先に着信できるまで繰り返すステップとをさらに備えることを特徴とする請求項27記載の方法。前記連絡先からの前記応答が少なくともファクシミリである場合には、a.手動による紙のファクシミリおよび電子ファクシミリを含む事前定義された通信チャネルを通じて前記ファクシミリを受信するステップと、b.前記受信された手動による紙のファクシミリをイメージングするステップと、c.前記イメージングされた文書を前記注文と関連付けるステップと、d.前記イメージングされた文書を前記紙の束ペーパーバッチと関連付けるステップと、e.前記電子ファクシミリに含まれる情報によって前記注文を更新するステップと、f.前記ファクシミリを前記注文に関連付けるステップとをさらに備えることを特徴とする請求項24記載の方法。前記連絡のモードが電話通話である場合には、a.前記注文を前記アウトバウンドコールキューにルーティングするステップと、b.コールをスケジューリングするステップと、c.前記連絡先にコール電話するステップと、d.前記注文を前記アウトバウンドコールキューから検索するステップと、e.前記注文を前記連絡先に照らして見直すステップと、f.前記注文を解決するステップと、g.前記注文を更新するステップとをさらに備えることを特徴とする請求項19記載の方法。前記連絡先の担当者にコール電話する前記ステップは、a.非薬剤師による解決が可能な前記問題を導入するステップと、b.前記コールを薬剤師に転送するステップと、c.前記注文を、薬剤師がアクセス可能な場所にルーティングするステップとを備えることを特徴とする請求項30記載の方法。前記連絡先にコールする前記ステップが該連絡先に着信できない場合には、前記連絡先にコールする前記ステップは、a.かけ直しフォームを完成させるステップと、b.前記アウトバウンドコールキューを更新するステップと、c.前記コールをスケジューリングする前記ステップ、および、前記連絡先にコールする前記ステップを、前記連絡先に着信できるまで繰り返すステップとをさらに備えることを特徴とする請求項30記載の方法。前記注文を処理する前記ステップは、a.前記注文における各文書を分類するステップと、b.前記注文における各文書を検証するステップと、c.前記注文における処方箋の総数を検証するステップと、d.前記注文のための処方箋分類の検証および入力のうち少なくとも1つを行うステップと、e.会員番号、グループ番号、およびサブグループ番号のうち少なくとも1つの、検証および入力のうちの少なくとも1つを行うステップと、f.支払額および支払タイプの検証および入力のうち少なくとも1つを行うステップと、g.患者が提供した通信の検証および入力のうち少なくとも1つを行うステップと、h.存在する場合は更新番号またはリフィル番号の検証および入力のうち少なくとも1つを行うステップと、i.処方者名の検証および入力のうち少なくとも1つを行うステップと、j.患者名の検証および入力のうち少なくとも1つを行うステップと、k.処方箋発行日の検証および入力のうち少なくとも1つを行うステップと、l.患者情報の検証および更新のうち少なくとも1つを行うステップと、m.薬剤情報の検証および更新のうち少なくとも1つを行うステップと、n.薬剤の強さの検証および更新のうち少なくとも1つを行うステップと、o.薬剤の服用指示の検証および更新のうち少なくとも1つを行うステップと、p.前記注文の各要素が正しいことを検証するステップとを備えることを特徴とする請求項1記載の方法。前記注文の各要素が正しいことを検証する前記ステップは、該注文の要素が正しくない場合には、ステップl.乃至ステップo.を繰り返すステップをさらに具備することを特徴とする請求項33記載の方法。前記注文が多重処方箋注文である場合、ステップl乃至ステップoを繰り返すステップをさらに具備することを特徴とする請求項33記載の方法。前記多重処方箋注文におけるすべての処方箋が完成する前に前記注文の一部を調剤するステップをさらに具備することを特徴とする請求項35記載の方法。ステップm.乃至ステップo.は注文注釈ビルダーを含み、前記注文に対して作成された注釈は、少なくとも1つのプルダウンメニューから作成され、前記少なくとも1つのプルダウンメニューは注釈の選択肢を備えることを特徴とする請求項33記載の方法。ステップまたはその組み合わせを実行するユーザの能力は、該ユーザのプロフィールによって決定されることを特徴とする請求項33記載の方法。前記複数のキューは、ポジティブ制御メカニズムを通じて互いに通信し、前記ポジティブ制御メカニズムは、前記自動処理を通じて前記注文を追跡することができるようにすることを特徴とする請求項1記載の方法。前記ポジティブ制御メカニズムは前記注文の受信の際に、受信された前記注文の発信元である先行キューに対して受信確認を送信することを特徴とする請求項39記載の方法。前記ポジティブ制御メカニズムは、前記注文がいずれか1つのキューにおいて費やす時間の長さを追跡することを特徴とする請求項39記載の方法。前記注文がいずれか1つのキューにおいて費やす前記時間の長さが事前定義された値を越える場合には、アラート警報がユーザに対して送信されることを特徴とする請求項41記載の方法。注文が調剤される必要がある場合を計算するためのアルゴリズムをさらに含み、前記計算は、前記注文が受信された際の前記チャネル、および、前記患者の身元を重み付けして、注文が調剤される必要があるときを決定するステップを含むことを特徴とする請求項1記載の方法。前記注文が事前定義された基準を満たすことができない場合、該注文はオプショナルの例外処理エリアに送信されることを特徴とする請求項1記載の方法。前記オプショナルの例外処理エリアは、前記注文が不正な注文、現金払い、スキャン不可能な注文、およびそれ以外の判読不可能な注文のうち少なくとも1つを備えるかどうかを判断することを特徴とする請求項44記載のオプショナルの例外処理エリア。イメージングされた後で、前記注文は前記イメージと比較されることを特徴とする請求項1記載の方法。前記注文が前記イメージに変換された後で、前記注文が入力されることを特徴とする請求項1記載の方法。前記入力された注文は前記イメージングされた注文に対して検証され、ロックされることを特徴とする請求項47記載の方法。前記注文が前記イメージに変換された後、該イメージは見直され、分類されることを特徴とする請求項1記載の方法。受信されたすべての注文には、バーコードが取り付けられることを特徴とする請求項1記載の方法。前記受信された注文は、現金、小切手、および為替のうち少なくとも1つをさらに備えることを特徴とする請求項1記載の方法。前記注文が現金を含むとき、レシートは正副2通で完成されることを特徴とする請求項51記載の方法。イメージングが必要であるか否かを判断するステップは、a.前記注文を受信するステップと、b.あらかじめイメージングされた文書または情報を識別するステップであって、該文書または情報は前記注文と関連付けられることが可能であり、前記関連する情報は注文における処方箋の番号、処方箋分類、年金プランに関連付けられる会員番号、前記年金プランに関連付けられるグループ番号、および前記年金プラン、支払いの額およびタイプ、患者/クライアント通信、処方者名、患者/クライアント名、処方箋発行日、薬剤情報、薬剤の強さ、薬剤使用の指示、許可された再調剤の数、調剤するための薬剤の量、および1日当たりの服用量に関連付けられるサブグループ番号を含むステップと、c.もし前記情報もしくは前記あらかじめイメージングされた文書が認識されて前記イメージングのステップを実行することなく前記注文が処理されるのであれば前記イメージングのステップを迂回するステップとをさらに具備することを特徴とする請求項1記載の方法。少なくとも1つの医療処方箋に関する注文を薬局業界で自動メールオーダー処理するための方法であって、コマンド及び制御モジュールにて前記注文を受信するステップであって、該注文は紙文書チャネルおよび電子チャネルを含む事前定義された通信チャネルを通じて受信され、文書準備プロセッサによって前記注文と関連付けられる文書タイプまたはカテゴリに対応して貼られたラベルを通じて識別するステップと、前記注文がイメージングを必要とするかどうかを例外処理プロセッサにて判断するステップと、イメージングを必要とする前記注文を高速スキャンプロセッサにてスキャナでイメージに変換し、該イメージはコンピュータ画面上およびグラフィカルユーザインタフェース上の少なくとも一つで該注文と比較されるステップと、前記注文が判読可能なイメージに変換できなかった場合には、例外処理プロセッサにて該注文を例外処理によって処理し、イメージ品質管理プロセッサにて前記イメージを前記注文に関連付けるステップと、コマンド及び制御プロセッサにて前記注文を少なくとも1つのキューに割り当てるステップであって、該キューは複数のキューから選択されるステップと、注文ヘッダプロセッサ、注文完成プロセッサ、及び/または、注文見直しプロセッサのうち少なくとも一つにて前記注文を処理するステップであって、該注文の処理は該注文の妥当性の検証、プロトコルの解決、および該注文の見直しを含むものであるステップと、コマンド及び制御プロセッサにてポジティブ制御データベースに問い合わせることによって前記複数のキューおよびいずれか1つのキューにいて前記注文が費やす時間の長さを通じて前記注文を追跡するステップと、コマンド及び制御プロセッサにていずれか1つのキューにおいて前記注文が費やす時間の長さが事前定義された値を超えるかどうか、および所定の値を超えるときアラートを発信するかどうかを判断するステップと、ユーザに割り当てられたプロファイルに呼応して、注文ヘッダプロセッサ、注文完成プロセッサ、及び/または、注文見直しプロセッサのうち少なくとも一つにて前記ユーザが前記複数のキューのうち少なくとも1つにアクセスする所定のレベルを提供するステップと、注文調剤プロセッサにて患者に前記注文を調剤するステップであって、前記注文の受信、前記注文の割り当て、前記注文の処理、および前記注文の調剤の少なくとも1つは地理的に異なる場所で起こるものであるステップとを具備することを特徴とする方法。前記注文が前記イメージに変換された後で前記注文が入力されたことを特徴とする請求項54記載の方法。前記入力された注文は、前記イメージングされた注文と照らして検証され、ロックされることを特徴とする請求項55記載の方法。前記注文が前記イメージに変換された後で前記注文が検証され、ロックされることを特徴とする請求項54記載の方法。前記注文が前記イメージに変換された後で、前記イメージは見直され分類されることを特徴とする請求項54記載の方法。受信されたすべての注文には、バーコードが取り付けられることを特徴とする請求項54記載の方法。受信された前記注文は、現金、小切手、および為替のうち少なくとも1つをさらに含むことを特徴とする請求項54記載の方法。前記注文が現金を含む場合、レシートは正副2通で完成されることを特徴とする請求項60記載の方法。イメージングが必要であるかどうかを判断する前記ステップは、a.前記注文を受信するステップと、b.あらかじめイメージングされた文書または関連する情報を識別するステップであって、該文書または該情報は前記注文に関連付けられ、前記関連する情報は注文における処方箋の番号、処方箋分類、年金プランに関連付けられる会員番号、前記年金プランに関連付けられるグループ番号、および前記年金プラン、支払いの額およびタイプ、患者/クライアント通信、処方者名、患者/クライアント名、処方箋発行日、薬剤情報、薬剤の強さ、薬剤使用の指示、許可された再調剤の数、調剤するための薬剤の量、および1日当たりの服用量を含むステップと、c.前記情報または前記あらかじめイメージングされた文書が認識されて前記イメージングのステップを実行することなく前記注文が処理されるのであれば前記イメージングのステップを迂回するステップとをさらに備えることを特徴とする請求項54記載の方法。通信販売による医療処方箋注文の自動処理のための方法であって、コマンド及び制御モジュールにて前記注文を受信するステップであって、前記注文は紙の文書チャネルおよび電子チャネルを含む事前定義された通信チャネルを通じて受信され、文書準備プロセッサにて前記注文に関連付けられた文書タイプまたはカテゴリに対応して貼られたラベルを通じて識別し、例外処理プロセッサにて前記注文がイメージへの変換を要するかどうかを判断し、高速スキャンプロセッサにて高解像度のカラースキャナによって前記注文をイメージに変換し、高速スキャンプロセッサにて不正な処方箋、現金払いによる注文および3次元の物体の少なくとも1つを含む例外項目は取り除かれ、前記例外項目または前記例外項目の表現はイメージに変換されてイメージ品質管理プロセッサにて前記イメージを前記注文に関連付けるステップと、コマンド及び制御プロセッサにて前記注文を少なくとも1つのキューに割り当てるステップであって、前記キューは複数のキューから選択されるステップと、注文ヘッダプロセッサ、注文完成プロセッサ、及び/または、注文見直しプロセッサのうち少なくとも一つにて前記注文を処理するステップであって、該注文を処理するステップは前記注文の正確性を判断し、プロトコルを解決し、該注文を見直し、かつ該注文を患者に出荷することを含むステップと、コマンド及び制御プロセッサにてポジティブ制御データベースに問い合わせることによって前記複数のキューを通じて前記注文およびいずれか1つのキューにおいて該注文が費やす時間の長さを追跡するステップと、コマンド及び制御プロセッサにていずれか1つのキューにおいて前記注文が費やす時間の長さが事前定義された値を超えるかどうかを判断し、かつ前記事前定義された値を超える場合、ユーザにアラート警報を送信するステップと、注文ヘッダプロセッサ、注文完成プロセッサ、及び/または、注文見直しプロセッサのうち少なくとも一つにてユーザに割り当てられたプロファイルに呼応して前記ユーザによる前記複数のキューの少なくとも1つへの所定のアクセスレベルを提供するステップとを備え、プロトコルを解決するステップは、注文見直しプロセッサにて前記注文を見直して前記少なくとも1つのプロトコルが適用されるべきかどうかを判断するステップと、臨床データベース、プランデータベース、ルールデータベース、連絡先データベース、受け取り可能アカウントデータベース、処方集データベース、価格設定データベース、クライアントプロフィールデータベース、患者履歴データベース、およびそれらの組み合わせのうち少なくとも1つから選択される少なくとも1つのデータベースに適用される場合に、管理プロトコル解決プロセッサにて前記少なくとも1つのプロトコルを解決するステップと、管理プロトコル解決プロセッサにて前記注文を見直して前記少なくとも1つのプロトコルを適用するかどうかを判断し、かつ解決されるまで前記少なくとも1つのデータベースに対して前記少なくとも1つのプロトコルを解決するステップとを備え、前記少なくとも1つのステップまたはその組み合わせは分散され、地理的に離れた場所で実行されることを特徴とする方法。前記注文が前記イメージに変換された後に、前記注文は入力されることを特徴とする請求項63記載の方法。前記入力された注文は、前記イメージングされた注文に照らして検証され、ロックされることを特徴とする請求項64記載の方法。前記注文が前記イメージに変換された後に、前記注文は検証され、ロックされることを特徴とする請求項63記載の方法。前記注文が前記イメージに変換された後に、前記イメージは見直され、分類されることを特徴とする請求項63記載の方法。受信されたすべての注文には、バーコードが取り付けられることを特徴とする請求項63記載の方法。前記受信された注文は、現金、小切手、および為替の少なくとも1つをさらに備えることを特徴とする請求項63記載の方法。前記注文が現金を含むとき、レシートは正副2通で完成されることを特徴とする請求項69記載の方法。イメージングが必要かどうかを判断する前記ステップは、d.前記注文を受信するステップと、e.任意のあらかじめイメージングされた文書または関連する情報を識別するステップであって、該文書または該情報は前記注文に関連付けられ、前記関連する情報は注文における処方箋の番号、処方箋分類、年金プランに関連付けられる会員番号、前記年金プランに関連付けられるグループ番号、および前記年金プラン、支払いの額およびタイプ、患者/クライアント通信、処方者名、患者/クライアント名、処方箋発行日、薬剤情報、薬剤の強さ、薬剤使用の指示、許可された再調剤の数、調剤するための薬剤の量、および1日当たりの服用量を含むステップと、f.前記情報または前記あらかじめイメージングされた文書が認識されて前記イメージングのステップを実行することなく前記注文が処理されるのであれば前記イメージングのステップを迂回するステップとをさらに備えることを特徴とする請求項63記載の方法。したがって、本発明の特徴および利点の1つは、通信チャネルまたは他の注文エントリプロセス/システムから受信された少なくとも1つの医療処方箋のための注文の自動処理のための方法を提供することである。本発明の追加的およびオプショナルの特徴および利点の1つは、通信チャネルまたは他の注文エントリプロセス/システムからの少なくとも1つの医療処方箋のための注文の自動処理のためのシステムを提供することである。本発明のさらにオプショナルの特徴および利点の1つは、処方箋調合システムにおいてリアルタイムで入力、表示、認証および管理を行うためのグラフィカルユーザインタフェースであって、該グラフィカルユーザインタフェースはシステムレポートおよび他の統計情報を作成するものを提供することである。本発明のオプショナルの特徴および利点の1つはまた、用紙のファイルおよび手動による文書送付書類への依存を減らすことである。本発明のさらにもう1つのオプショナルの特徴および利点は、少なくとも1つの医療処方箋のための注文の自動処理の実行のためのコンピュータ可読メディアを提供することである。本発明のさらなるオプショナルの特徴および利点は、ユーザインターフェースサーバプログラムによってアクセスされた少なくとも1つの医療処方箋のための注文の自動処理のためのコンピュータ可読データ構造を提供することである。本発明のこれらおよび他の目標および利点は、詳細な説明、図面、および添付の特許請求の範囲を検討することにおいて、いわゆる当業者には明白であろう。本発明は例えばイメージング技術を使用して、通信販売処方箋の品質を改善し、その処理時間を高速化する。本発明の自動イメージング環境は、処方箋および処方箋見直しの適時かつ正確な処理、ならびに、完全なワークケース文書化のより容易な検索を保証する。処方箋注文に適用される、柔軟性があり構成可能なリレーショナルデータベースにより、全体的な処方箋注文処理時間が短縮される。本発明はまた手作業のコストも削減するが、これは、本発明が好ましくは、薬局中を進む注文を移送しおよび仕訳ソートするための手作業の必要性をなくすからである。加えて、本発明は好ましくは、注文毎に費やされた時間、および、新しいユーザをシステム向けに訓練するために必要とされた時間の双方に関して作業コストを減らすが、これは、システムを通じて注文が進行するのに合わせてユーザの持つナビゲーション用の画面の数を減らすことによって行う。スキャナが使用されて、郵便を通じて受け取られた情報がコンピュータファイルおよび/またはメモリに読み取られ、これらの中でデータの永続的な類似をオプショナルで格納することができる。注文の永続的レコードが作成されると、結果として注文の検索が容易となる。データベースのパラメータは手動で注文レコードに入力され、異なるタイプの着信注文文書を索引付けするために使用される。異なるパラメータは、異なるタイプの注文文書を区別するために使用される。例えば、支払いクーポンは実際の処方箋とは区別される。システム、方法およびメディアの他の特徴には、アプリケーション処理ロジックに対して、注文のために実装する動作の種別および順序を識別するデータベーステーブルが含まれる。ある場合には、これらのシーケンスは自動的に実行される。システムレベルレポートもまた生成され、このレポートはいかなるシステムレベルでの生産性、品質および性能をも追跡することができる。表記および専門語以下に続く詳細な説明を、例えば、スタンドアロンゲーム機、コンピュータ或いはコンピュータネットワークなどといった、コンピュータまたは処理システム上で実行されるプログラム手順に関して提示する場合がある。これらの手順の説明および表現は、それらの作業の本質をもっとも効果的にいわゆる当業者に伝えるために当業者が使用する手段である。手順プロシジャは本明細書で、また一般に、所望の結果に通じる、自己矛盾のない一連のステップであると考えられる。これらのステップは、物理的実体の物理的操作を必要とするものである。通常、必ずしもそうとは限らないが、これらの量の実体は、格納、転送、結合、比較およびそうでない場合は操作されることが可能である電気または磁気信号の形態を取る。時には、主に共通に使用するために、これらの信号をビット、値、要素、シンボル、キャラクタ、項目、番号などと呼ぶことが好都合であることがわかっている。しかし、これらおよびこれらに類似した用語のすべては、適切な物理量に関連付けられるべきであり、これらの量に適用された好都合なラベルでしかないということに留意されたい。さらに、実行される操作はしばしば、追加または比較などといった用語で呼ばれ、これらは一般に、人間であるオペレータによって実行される頭脳的作業に関連付けられる。本発明の一部を形成し本明細書で説明するオペレーションのいずれにおいても、人間としてのオペレータのこのような能力は必要ではなく、あるいは大抵の場合望ましくはない。却って、これらのオペレーションはマシンのオペレーションである。本発明のオペレーションを実行するための有用なマシンには、汎用のデジタルコンピュータ或いは類似の装置が含まれる。本発明のこれらおよび他の態様、利点、および新規の特徴は、以下の詳細な説明を読むことで、および、添付の図面を参照することで、明らかになるであろう。図面においては以下の通りである。本発明によれば例えばイメージング技術を使用して、通信販売処方箋の品質を改善し、その処理時間が高速化される。本発明の自動イメージング環境は、処方箋および処方箋見直しの適時かつ正確な処理、ならびに、完全なワークケース文書化のより容易な検索が保証される。処方箋注文に適用される、柔軟性があり構成可能なリレーショナルデータベースにより、全体的な処方箋注文処理時間が短縮される。図1は、本発明を実施するための医療処方箋注文処理システム10の一実施例である。詳細には、医療処方箋注文注文とも称するがシステムによって、システムへの様々な通信チャネルの少なくとも1つを通じて受信される。当該通信チャネルには、例えば、郵便米国郵便、例えばFederalExpress登録商標などの民間クーリエ、手動のファクシミリなどといった、紙としての文書のチャネル、および、例えば電子ファクシミリ、eメール、電話などといった、ペーパーレスまたは電子チャネルが含まれる。システムへの注文導入のための注文入力エントリポイントまたは通信チャネルは、紙による注文のための標準スリッタプロセッサ15並びに標準ファクシミリプロセッサ20、および、標準着信ペーパーレス注文プロセッサ25で見出される。受け取られた郵便は処理され、本システムにスキャンされる状態に置かれる。郵便はシステムに、例えばスリッタプロセッサ15で入る。該スリッタプロセッサ15は封筒を開き、例えば、各封筒がスリッタプロセッサ15によって開封される日付を含む、事前定義された情報をその封筒に押印する。類似の本前処理ステップは、手動ファックス通信チャネルを通じてファクシミリプロセッサ20に受信された手動または紙のファックスにおいて実行される。本発明の代替実施形態によれば、受信された手動のファックスは、受け取られた郵便と共にペーパバッチ書類束の中に束ねられるバンドルされる。文書準備プロセッサ30で、書類束における各封筒の内容が見直され、スキャンするために準備される。封筒の内容全体が注文を構成する。開封された封筒は、所定数の封筒束中に合わされる。次いでこの封筒束バンドルが書類束にされる。各書類束は、バンドルからのすべての文書、および、関連のあるあらゆる準備フォームを含む。関連準備フォームには、例えば、書類束の頂部にあるバッチヘッダシート、注文を分離するために使用される注文セパレータ、および、各書類束の最後に配置されるバッチ終了シートが含まれる。各封筒の内容は、システムプロトコル下で適用可能であるときには、事前定義された文書タイプまたはカテゴリに割り当てられる。各文書に、事前印刷されたバーコードラベルが貼られ、このラベルは、特定の文書タイプに属することなどによりラベル付けされた文書を識別する。文書タイプには、例えば、システム封筒と非システム封筒の間の区別である封筒;EasyRX/UniversalOrderFormUOF;例えば会員または患者が情報を書く媒体としてのあらゆるものを含むノート;処方箋再調剤;処方箋更新;支払いクーポン;例えば現金、小切手および為替を含む支払い;いずれかのタイプの会員または患者の健康プロフィールフォームであるHealth,AllergyandMedicationQuestionnaireHAQ:健康、アレルギー及び治療法に関する質問集;新しい処方箋;注文内でスキャン不可能である文書を表現するシートであるスキャン不可能シート;ならびにその他が含まれ、その他には、事前定義されたカテゴリまたは文書タイプに適合しないあらゆるものも含まれる。注文文書は、順序付けされ、適用可能なバーコードラベルが貼られた後、高速スキャナ40へイメージングのために送信される。注文の文書の内容またはコンポーネントが、事前定義された条件を満たさない場合、このような文書は注文から引き抜かれ、スキャン不可能シートで置き換えられ、オプショナルで例外処理プロセッサ35にルーティングされる渡される。例外処理プロセッサ35にルーティングされる文書には、例えば、現金、例えば空の処方ボトルなどの3次元の物体が含まれ、これらは項目を読み取ることが困難であり、文書自体のスキャン走査が困難であるか、もしくは高速スキャナプロセッサ40によるスキャンが不可能な他の文書である。注文が現金を含んでいる場合、現金が数えられ、少なくとも正副2通で記録される。現金および少なくとも1つの写しが現金箱40または預金口座に預けられ、少なくとも1通が、その現金の発生元である注文を構成する文書と共に配置される。注文に含まれた現金をスキャンするのではなく、記録された支払いフォームがスキャン走査される。現金を受け取る他のフォームをオプショナルで使用することができる。注文が3次元の物体、例えば空の処方ボトルなどを含む場合、この品目は例外処理プロセッサ35に送信される。例外処理プロセッサ35はこの項目を計算に入れ、例外品目の記録を注文にルーティングすることで、当該品目に含まれた情報がその注文に関するさらなる注文処理のために利用可能にする。例外処理プロセッサ35との通信にあたるものは、例外処理プロセッサ35によって取り込まれたイメージの監視のためのイメージディスプレイ36である。高速スキャナプロセッサ40との通信にあたるものは、取り込まれたイメージの品質を監視するためのイメージディスプレイ45である。スキャンされた書類束は、所定の見直し監査スケジュールに従って見直される。本発明の重複実施形態によれば、所定の見直し監査スケジュールはランダム選択無作為選択に基づいており、このランダム選択においては、無作為に選択されスキャンされた書類束のみが、イメージ品質管理プロセッサ50へイメージ見直しのためにルーティングされる。別法として、スキャンされた書類束をすべて利用するようにしてもよい。イメージ品質管理プロセッサ50にルーティングするように選択されなかった書類束はコンピュータ可読メディア55に格納されるが、このコンピュータ可読メディア55とは例えば、コンピュータメモリ、コンピュータハードディスクドライブ、磁気テープドライブ、および/またはコンピュータ可読光媒体メディアなどである。注文イメージに対応するハードコピーは、これらのハードコピーを電子的イメージに索引付けする所定の方法で、ファイルルーム60に格納およびアーカイブ記録保管される。本発明の代替的実施形態によれば、書類束中のスキャンされた各文書には文書識別番号が付加され、あるいはこれらの文書は文書識別番号と関連付けられ、この文書識別番号は、対応する書類束のヘッダ識別番号にリンクされ、このヘッダ識別番号のもとに当該書類束がファイルストレージルーム60内にアーカイブ記録保管される。見直しのために選択される書類束は、システムユーザによって見直される。スキャンされたイメージ内に欠陥が存在すると判明し、この欠陥が所定のしきい値を超える場合、書類束全体が再スキャン/例外処理プロセッサ35にルーティングされる。イメージ品質管理プロセッサ50による見直しの後に、イメージが受け入れ可能であると判明する場合、該イメージがコンピュータ可読メディア媒体に格納されるが、このコンピュータ可読メディアは例えば、コンピュータメモリ、コンピュータハードディスクドライブ、磁気テープドライブ、および/またはコンピュータ可読光メディア媒体などである。当該注文イメージに対応するハードコピーは、これらのハードコピーを対応する電子的イメージに索引付けする所定の方法で、ファイルルーム60に格納される。書類束は、スキャンおよび承認された後、システムキューへさらなる注文処理のためにルーティングされる。注文の内容に応じて、注文は、注文ヘッダプロセッサ65、注文完成プロセッサ70、および/または注文見直しプロセッサ75のうち少なくとも1つを通過するようになる。注文ヘッダプロセッサ65、注文完成プロセッサ70、および注文見直しプロセッサ75は、それぞれ互いと、また、管理プロトコル解決プロセッサ80およびプロフェッショナル専門プロトコル解決プロセッサ85と通信する。注文ヘッダプロセッサ65は、注文に関連付けられた非臨床データを処理する。非臨床データには、例えば、注文における処方箋の数;処方箋分類、年金プランに関係するときには会員番号、年金プランに関係するときにはグループ番号、および、年金プランに関係するときにはサブグループ番号;支払いの額およびタイプ、患者/クライアント通信;処方者名;患者/クライアント名;および処方箋発行日が含まれる。注文完成プロセッサ70は、注文に関連付けられた臨床データを処理する。臨床データには、例えば、薬剤情報、薬剤の強さ、薬剤使用法、許可された再調剤の数、調剤するための薬剤の量、および1日当たりの服用量が含まれる。注文見直しプロセッサ75は注文の全要素を見直して、注文要素が正しいかどうかを判断する。注文見直しプロセッサ75を離れる注文は高速印刷プロセッサ90にルーティングされ、そこで処方箋ラベルおよび他の添付注文資料が印刷される。次いで、薬剤が実際に注文調剤プロセッサ95で調剤され、出荷ステーションプロセッサ100へ、患者への出荷のためにルーティングされる。プロセッサ90、95および100の実施例については、例えば、参照により本明細書に組み込まれるAUTOMATICPRESCRIPTIONFILLING,SORTINGANDPACKAGINGSYSTEM自動処方箋記載、仕訳、梱包システムという名称の米国特許第5,771,657号を参照されたい。コマンドおよび制御プロセッサ101は各システムプロセッサと通信し、インタフェースを提供し、このインタフェースを通じて、例えばシステムキュー、注文の場所、システムリソースおよびシステム実働に関するリアルタイム情報が表示され、管理されおよび処理される。代替的実施形態では、分散制御システムおよび/または並列処理システムを使用することができる。本発明のさらにまた別の実施形態では、コマンドおよび制御プロセッサ101は、システムプロセッサ90、95および100を除く各システムプロセッサと通信する。ワークフロープロセッサ102は各システムプロセッサと通信し、様々なシステムプロセッサおよび作業キューを通じて、注文の流れを導く。ワークフロープロセッサ102はまた、情報をコマンドおよび制御プロセッサ101に提供する。イメージ化された注文文書図2は、本発明によって取り込まれた、イメージ化された注文文書の画面キャプチャを例示する。取り込まれた後、イメージ化された注文文書はいくつかの方法で操作することができる。これらの方法には例えば、イメージ化された注文文書の選択された部分の拡大またはズームイン;および、イメージ化された注文文書の正面および背面を同時に見直すことが含まれ、この見直しにおいて両面はイメージディスプレイの別々の領域に現れる。また、イメージ化された注文文書は注釈を直接受信することができる。イメージ化された注文文書を、例えば処方箋分類および利用見直し考察など、処方者との話し合いを反映するように直接更新することができる。直接注釈が付けられた、イメージ化された注文文書は、正当な処方箋となる。注文処理の流れ制御図3は、本発明の注文処理方法を通じた注文の全体の流れの一実施例を例示する高レベルの制御流れ図である。200、205でそれぞれ、患者は注文を非電子フォーマット例えば、用紙で、あるいは電子フォーマット例えば、ペーパーレスでサブミット提出する。非電子フォーマット注文の内容は、例えばイメージングのために準備され、210でイメージ化される。215で、注文と共に受け取られた支払いが処理され、預金口座にルーティングされる。イメージ化することができないか、あるいは220でイメージ化されるために特別処理を必要とする注文の内容は、221で、オプショナルで特別処理エリアにルーティングされる。システムは注文イメージを受信し、注文イメージに基づいて、225で、注文に対応する少なくとも1つのデータフィールドを完成させることによって、注文がシステムに入力される。本発明の代替的実施形態によれば、ステップ205でシステムに入る注文は、ステップ225を通じて進むことなく処理される。この実施形態によれば、ステップ225を必要としない注文には、例えば、IVRU、ワールドワイドウェブ、インターネット、および他の電子通信チャネルからサブミット提出された処方箋再調剤が含まれる。235でファックス通信チャネルを通じて受信された注文または注文関連情報は、225で入力される。225の注文完成のステップ中に、注文イメージが判読不可能であるか、そうでなくても解像不可能であると決定される場合、226で該注文が作業キューに送信されて、イメージが解像される。ファクシミリ注文および205で受信されたフォローアップ注文情報はファックスサーバによって取り込まれ、イメージリポジトリ貯蔵所にコピーされ、少なくとも1つの作業キューへ処理のためにルーティングされる。注文文書がシステムによってイメージ化され、受信された後、該注文イメージは230で少なくとも1つの作業キューに割り当てられる。注文を作業キューに入れることは、少なくとも部分的には、例えば、i注文を少なくとも1つの最初のキューから注文出荷キューまで進めるために、何のオペレーション群が注文に適用されなければならないか;ii注文の優先順位、この場合の優先順位はユーザまたはシステムによって割り当てられる;およびiii部分的には例えば、注文が受信された日付、クライアント、および、注文が受信されるに当たって用いられた通信チャネル、に基づく注文の目標配送日によって、決定される。この方法は、230で生成され、240で判断されるように、注文を解決して注文を少なくとも1つの最初のキューから注文出荷キューまで進めるために必要とされる、すべての適用可能プロトコルを適用する。次いで250で、入力された注文が、イメージ化された注文に対して見直される。入力された注文を、イメージ化された注文に対して検証するに当たり、この方法は、処方箋データがさらなる更新を受信しないようにロックし、255で、該注文に対応するラベルセットを印刷する。処方箋データがこのポイントから前方へさらなる更新を受信しないようにロックすることによって、該処方箋データの解釈のためのユーザアカウンタビリティ責任能力が確立される。当該ラベルセットは、例えば従来のラベル印刷方法で印刷されるが、この方法においてはラベルは最初に印刷され、次いで調合され、あるいは電子データストリームが自動調剤薬局に送信される。例えば、参照により本明細書に組み込まれたAUTOMATICPRESCRIPTIONFILLING,SORTINGANDPACKAGINGSYSTEM自動処方箋記載、仕訳、梱包システムという名称の米国特許第5,771,657号を参照されたい。ラベルセットには、例えば、実際の処方箋ラベルおよびその他のいかなる注文関連患者通信も含まれる。260で注文が調剤され、その後に265で、正しい薬剤が調剤されたかどうかを判断するための検証ステップが続く。265の検証ステップの後に、270の包装ステップ、275の積荷目録の自動生成、次いで280の、患者への注文の実際の出荷が続く。本発明の一実施形態によれば、注文をロックおよび調剤することができるようになる前に、すべてのプロトコルが解決されることが必要である。すべてのプロトコルが解決された後、1セットのルーティングロジックルール論理規則は、どの薬局群が処方箋を調剤するかを決定する。ルーティングロジックルールは、例えば、顧客年金プラン;契約上のサービスレベル;および、調剤される薬剤のタイプを考察するが、これは、規制薬剤であるかどうか、または、温度に敏感であり、特別な出荷事前注意が必要であるかどうかなどである。本発明のもう1つの実施形態によれば、注文が調剤される際の順番は、該注文に割り当てられた優先順位番号に依存する。該優先順位番号を、例えば、クライアント顧客の契約上のサービス保証に基づいて割り当てることができ、クライアントサービス保証に関連付けられた注文は、そうでない注文よりも高い優先順位を有し、したがって最初に調剤される。図4は、注文が受信される際に用いられる通信チャネルとは独立した、本発明の方法の全体の流れ制御の高レベルの例示を表す。300で注文が受信され、次いで305でシステムに入力される。310で、注文に含まれた処方箋の妥当性が検証される。妥当性検証ステップは、315で少なくとも1つのデータベースから入力を受信する。妥当性検証ステップに関連するデータベースの例には、例えば、臨床データベース316、年金プランデータベース317、ルール規則データベース318、および/または連絡先データベース319が含まれる。本発明の代替的実施形態によれば、妥当性検証ステップに関連するデータベースの例には、臨床データベース、プランデータベース、ルールデータベース、連絡先データベース、アカウント受領可能データベース、処方集一覧データベース、価格設定データベース、顧客クライアント概要プロフィールデータベース、患者履歴データベース、およびそれらの組み合わせが含まれる。処方箋の妥当性検証の際に、この方法は320で、注文に対するいずれかの適用可能なプロトコルの存在をチェックする。いずれかのプロトコルが適用される場合、325で、適用可能なプロトコルが少なくとも1つのデータベースに対して解決される。解決ステップに関連するデータベースの例には、例えば、臨床データベース316、年金プランデータベース317、ルール規則データベース318、および/または連絡先データベース319が含まれる。本発明の代替的実施形態によれば、プロトコル解決ステップに関連するデータベースの例には、臨床データベース、プランデータベース、ルールデータベース、連絡先データベース、アカウント受領可能データベース、処方一覧集データベース、価格設定データベース、クライアント顧客プロファイル概要データベース、患者履歴データベース、およびそれらの組み合わせが含まれる。表1には、本発明が解決することができるプロトコルのいくつかの例が含まれる。325でのすべての適用可能なプロトコルの解決の際、330で注文が見直されて、各注文要素が正しいかどうかが判断される。335で正しい注文が調剤薬局キューにルーティングされる。本発明の重複的実施形態によれば、調剤薬局キューは、注文エントリ、処方箋の妥当性検証、プロトコルの解決および注文見直しのステップが完了する場所とは地理的に異なる場所に位置することができる。本発明の重複的実施形態によれば、注文エントリ、処方箋の妥当性検証、プロトコルの解決、注文見直し、および調剤キューへのルーティングの各ステップをそれぞれ、地理的に互いに異なる場所で実行することができる。図5は、注文に適用されるプロトコルの解決に関連する反復プロセスを例示する。350で注文が受信され、355で少なくとも1つの最初のキューに割り当てられる。この注文は少なくとも1つの中間キューを通じて調剤薬局キューに進み、その中で、注文がポピュレート所在する各キューについて、この方法は360で、注文にあてはまるプロトコルがあるならばそれがどんなプロトコルなのかを決定する。この方法はこのプロセスを、365ですべての適用可能なプロトコルが解決されるまで継続する。この方法はまたポジティブ制御メカニズムも提供し、このメカニズムは、プロトコルを解決できないことにより注文が失われたり、あるいはいずれかの単一のキュー内で固定されたりしないようにする。この方法は370で、注文がいずれか1つのキュー内に所定の期間を超えて残るとき、アラート警報を発信する。365でのすべての適用可能なプロトコルの解決の際には、注文が見直されて、すべての注文要素が正しいことを調べるためにチェックされ、ここでもし正しい場合には、380で調剤薬局キューにルーティングされる。ヘッダエントリ図6は、ヘッダエントリのための流れ制御の一実施例を示す。ヘッダエントリは、注文フィールド内の注文に関係する非臨床データを入力するステップを提供する。ヘッダエントリプロセス内で検証および/または入力されたデータは一般に、イメージ化された注文文書または他の電子および/または非電子注文文書から導出される。検証および/またはエントリ入力プロセスは、400で、イメージ化された注文文書或いは他の取り込まれたデータを見直して、データフィールドに対してチェックするか、もしくは、必要とされるが現在は空となっているデータフィールドにデータを入力することを含む。図8は、本発明の一実施形態に係る画面キャプチャを例示し、ここにおいては、イメージ化された注文文書は会員、住所、および支払いデータエントリフィールドに近接して配される。ヘッダに入力され、かつ/または検証されたデータの例には、例えば、患者名、処方者名、出荷先住所、支払い額、および/またはクレジットカード番号が含まれる。400で各注文イメージが見直されて、その後に405のイメージ分類が続く。410で、注文に含まれた各文書が検証され、説明される。415で、注文内に存在する処方箋の総数が検証される。420で各処方箋が見直されることで、各処方箋が正しい処方箋分類に割り当てられていることが保証される。処方箋分類が存在しない場合、420で入力される。425で、注文がチェックされて、この注文に正しい年金プラン会員番号、グループ番号およびサブグループ番号が割り当てられていることが検証される。年金のプラン番号が存在しないか、あるいは、番号のサブセットのみが存在する場合、425で番号が入力される。430で、支払いの額および種類タイプが検証される。支払いの額およびタイプが提供されていない場合、430で支払いの額およびタイプが入力される。435で、患者サイドから提供した通信が検証される。患者の通信が入力されていない場合、435で患者が提供した通信が入力される。本発明の代替的実施形態によれば、患者の通信が提供されない場合、プロセスはステップ440に進み、患者通信フィールド群は空となる。440で、処方箋が更新または再調剤される回数が検証される。更新または再調剤回数が入力されていないが、更新または再調剤回数が注文中に存在する場合、440で更新または再調剤回数が入力される。445で処方者名が検証される。処方者名が入力されていない場合、445で処方者名が入力される。本発明の代替的実施形態では、処方者名の検証または入力のうち少なくとも1つのステップは加えて、患者と処方者を対応マッチさせる履歴リストから処方者を選択すること;処方者を処方者データベースから選択すること;新しい処方者を入力すること;或いは既存の処方者情報を編集すること、のうち少なくとも1つを含む。450で患者名が検証される。患者名が入力されていない場合、450で患者名が入力される。445で、各処方箋の処方箋発行日が検証される。処方箋発行日が入力されていない場合、455で処方箋発行日が入力される。460での、ヘッダエントリデータのすべてもしくは所定のセット部分の検証および/またはエントリの際には、465で注文が作業キューにサブミット提出されて、注文の次の宛先が決定される。郵便注文のための前処理の流れ制御図7Aおよび7Bは、注文が郵便によって送られるときの注文前処理の流れ制御の一実施例を例示する。500で注文が受信される。505で、受信された注文が郵便注文でない場合、510で、注文は、システムの他の通信チャネルの1つを通じてシステムに入り、適切となるべくヘッダエントリ、注文完成またはプロトコルにルーティングされる。郵送された注文は、他の受領された郵便注文と共に集められる。520で、注文がおさめられている封筒が破られ、525で日付のスタンプが押される。530で、破られた封筒が所定のサイズごとのスタック山にバンドルされ束ねられる。次いで535で、各バンドル束が書類束に変換される。540で、バーコードが書類束内のすべての適用可能な文書に取り付けられる。書類束におけるあらゆる文書は、必ずしもバーコードを受ける資格があるとは限らない。バーコードを受けるための文書の資格は、所定の基準に基づく。545で、書類束内の文書が所定の基準を満たすことができない場合、その文書がオプショナルの例外処理エリアに送信されて、該文書が例えば、550で不正な処方箋であるかどうか、555で現金払いであるかどうか、560でスキャン不可能であるかどうか、あるいはさもなければ判読不可能であるかどうかが判断される。550で注文が不正であると判断される場合、560で該注文がキャンセルされる。注文が現金払いである場合、570で現金レシートが正副2通で完成され、575で、現金払いが2通の現金レシートのうち1通と共に預金口座に入れられる。580で、他の1通の現金レシートがその対応する注文文書に戻される。注文がスキャン可能でない場合、スキャン不可能文書またはその中に含まれた情報を表す文書が作成され、スキャンされ、その対応する注文文書に戻される。スキャンすることができる例外処理文書が、フラッドベッドスキャナを使用して586でスキャンされる。585で、所定の基準を満たす書類束における文書が順序付けされるが、これは、バッチヘッダを書類束の頂上に、注文セパレータを互いの注文の間に、バッチエンドを書類束の最後に配置することによって行われる。順序付けされた書類束は、例えば、アコーディオンフォルダに590で入れられ、595で組織的な正確性について見直される。書類束の見直しが成功した場合には、600でこの書類束がスキャンされ、600で支払い文書がこの注文文書から分離される。595で、書類束が正しい順序でないことが判明する場合、この書類束は再順序付けのために545の例外処理にルーティングされる。605で、スキャンプロセスは書類束の識別番号を各書類束に付加し、ならびに605で、書類束における各文書イメージに文書識別番号を付加する。本発明の代替的実施形態によれば、この文書識別番号はユリウス日および一意的な識別番号を含む。スキャンプロセッサは注文文書のイメージをカラーで取り込み、各注文文書の両面を同時にイメージ化することが好ましい。書類束から取り込まれた、スキャンされたイメージは、所定の見直しスケジュールに従って見直される。見直した際に、取り込まれたイメージが610で承認される場合、615で、該イメージがディスクに或いは他のコンピュータ格納媒体ストレージメディアに書き込まれる。また、イメージの承認の際に、600で分離された支払いが、620で預金口座に送られる。しかし、イメージが所定の見直しスケジュールに従って見直された後に承認されない場合、この書類束は600で再スキャンされる。610のスキャンされたイメージの承認後、スキャンされたイメージを作成するために使用された書類束が625でアーカイブ記録保管される。625で書類束が所定の方法でアーカイブされるが、この方法は書類束をスキャン後イメージに索引付けるというものであり、したがって、スキャンされたイメージに基づいて注文の処理中にいつでも書類束の検索が可能である。スキャンされたイメージに基づいて注文を処理している最中に書類束にアクセスする必要がある場合、630でタスク要求をサブミット提出することができ、その要求されたタスクを635で該書類束上で実行することができる。書類束におけるすべての文書に対応する、スキャンされたイメージのセット全体は、640で、所定の見直しスケジュールに基づいて品質管理の観点から見直される。本発明の代替的実施形態によれば、所定の見直しスケジュールは、スキャン完了して間もない書類束のランダム選択に基づく。645で書類束が見直しのために選択される場合、その束における各イメージがオプショナルで見直される。650で書類束が見直しをパスする場合、655で、この書類束は少なくとも1つのシステム作業キューに、さらなる注文処理のためにキューイング待ち合わせされる。650で見直しをパスできない書類束は、545で例外処理に送られる。見直しのために選択されない束は、少なくとも1つのシステム作業キューに、さらなる注文処理のために直接キューイングされる。注文完成図9は、注文完成に関連する全体的なステップの一実施例を示す。注文完成ステップは、臨床データの検証および/またはエントリ入力に関連する。検証および/またはエントリプロセスは部分的には、イメージ化された注文文書または他の取り込まれたデータを見直すことに関連し、データフィールドに対してチェックするか、あるいはデータを入力する。図12は本発明の一実施形態の画面キャプチャを例示し、ここでは、イメージ化された処方箋注文文書は、薬剤選択データエントリ入力フィールド領域に近接して並べられる。700で、注文が作業キューから得られる。705で、患者情報が正しいかどうかについての判断が行われる。患者情報が不正確である場合、710で、それに応じて患者情報が更新される。715で、次の薬剤情報が見直されて、その正確性が判断される。薬剤情報が不正確である場合、720で、それに応じて正しい薬剤が選択され、注文が更新される。次に725で、薬剤が示す強さが見直される。強さが不正確である場合、730で正しい薬剤の強さが選択される。次いで735で、薬剤使用のための使用法が正しいかどうかについての判断が行われる。使用法が不正確である場合、740で正しい使用法が選択される。いかなる不正確なエントリへの訂正も、対応する正しい情報を手動で入力することによって、あるいは、プルダウンメニューからの正しい情報の選択によって行うことができる。さらに、上記で概説したステップは、必ずしも上述の順序で実施されなくてもよい。本発明の代替的実施形態によれば、ステップ715および対応するステップ720は、ステップ735および対応するステップ740と置き換えられる。すべての臨床データが検証および/または入力された後、745で、その特定の処方箋のための注文が見直されて、750で、あらゆる注文要素が、単一の処方箋に関係するために、正しいことが保証される。特定の処方箋の注文要素が正しくない場合、正しくなるまでステップ705から735が繰り返される。特定の処方箋のためのすべての注文要素が正しい場合、755で、該注文が追加の処方箋についてチェックされる。追加の処方箋が同じ注文内に存在する場合、単一の注文内のすべての処方箋が解決されるまで、ステップ705から750が繰り返される。注文内のすべての処方箋の完成の際および/またはすべての注文要素が正確であると判明した際には、760で該注文が調剤薬局キューにサブミットされる。本発明の代替的実施形態によれば、多重処方箋を含む注文は、760で個別の処方箋を調剤薬局キューにリリースする前に、該注文内のすべての処方箋を処理させる必要はない。また、本発明の代替的実施形態によれば、注文完成プロセス内の各ステップは、注文完成プロセスの完了においてユーザを支援する1セットのツールによってサポートされる。これらのツールには、例えば、ユーザが少なくとも1つのプルダウンメニューの句および/または語から選択することによって薬剤使用法を構築することができるようにする薬剤使用法ビルダー;スペルチェッカー、および、薬剤類似/音類似機能が含まれる。プロトコルプロトコルは、注文の要素を解決するように作用する複数組のルールのセットまたは集まりである。1つのプロトコルの解決は、追加のプロトコルを解決する必要性を引き起こす場合がある。例えば、ある注文中の一要素が欠落しているか、あるいは不明瞭である場合、プロトコルは、欠落または不明瞭な要素に対して使用されず、要素の解決を追跡するために使用される。追跡には、例えば、どのユーザが検証を実行したか、および、その要素を解決するために誰に連絡が取られたかに留意することが含まれる。本発明の一実施形態によれば、本発明の方法およびシステムは、プロトコルを解決する際にユーザを支援する1セットのウィザードおよびツールを提供する。このウィザードはユーザをプロトコルまたはプロセス中でステップバイステップ方式で進ませ、特定のプロトコルを解決する方法を示す。ウィザードはプロトコルの解決中を、一連のシステムプロンプトを提供することによって進む。これらのツールには、例えば、ユーザがプロトコルを注文に追加することができるようにするプロトコル追加;ユーザが注文の処理を一時的に停止することができるようにする注文停止;注文内の処方箋のキャンセルと同時に注文内の他の処方箋の処理を続行することができるようにする処方箋中止/キャンセル;ユーザが注文全体を完全にキャンセルすることができるようにする注文中止/キャンセル;薬剤が特許権保護を失うときにユーザが注文にフラグを立てて、再調剤時にジェネリックブランドが再調剤のために使用可能であるようにする、処方箋のプルおよび挿入;注文または処方箋を新しいインボイス請求書にコピーすることができるようにする新規処方箋コピー;および、即時注文見直しができるようにする注文見直しが含まれる。連絡管理図10は、連絡管理のための全体的な流れ制御の一実施例を示す。800で、いずれかの適用可能プロトコルが適用されるかどうかについての判断が行われる。プロトコルが適用される場合、805で、処方者に連絡を取ることなくこのプロトコルを解決することができるかどうかについての判断が行われる。連絡が必要でない場合、810でプロトコルが解決され、810でさらなる処理のために作業キューへサブミットされる。プロトコルを解決するために連絡が必要とされる場合、815で、処方者に対して発信されるアウトバウンドファクシミリがプロトコルを解決するかどうか、または、処方者への電話が必要とされるかどうかについての判断が行われる。オプショナルでアウトバウンド発信されるファクシミリによって解決することができるプロトコルについては、820でファクシミリがオプショナルで生成され、プロトコルを解決するために適切なフィールドがポピュレートされ、ポピュレートされた後、820でこのファクシミリが処方者に送信される。本発明の代替的実施形態によれば、ファックスの送信は待機キューの実行を開始させ、該待機キューは、ファックス送信から、処方者からの連絡が戻されるまでの時間の長さを計測する。計測された時間が、処方者による戻りの連絡が開始される前に所定値を超える場合、その注文はアウトバウンドコールキューに入れられる。プロトコルを解決するために電話が必要とされる場合、830で連絡要求がアウトバウンドコールキューにルーティングされ、835でコールがスケジューリングされる。840で、処方者に対して、スケジューリングされた時間に電話がかけられ、845で処方者に電話発信が届く着信する場合、電話をかけたユーザは、850で、解決されるべきプロトコルを有する注文をバーチャルシェルフ仮想棚から検索する。次いで855で、ユーザは処方者と共に注文を見直し、処方者に対してプロトコルを解決するために必要な情報を請求する。860でプロトコルが解決された後、この注文が865において作業キューに、さらなる処理のために入れられる。別法として、電話がかけられるが、ユーザが870で応答を受信しなかった場合、この注文はアウトバウンドコールキューに戻り、835で別のコール電話通話がスケジューリングされ、ステップ835から845が繰り返される。875で処方者のために電話がかけられ、メッセージが残される場合、該アウトバウンドコールキューは、メッセージが処方者のために残されたことを反映するように更新され、880で、処方者からの電話またはその他の通信が受信されるための所定時間が設定される。885で戻りのコールが行われる前に所定時間が経過する場合、別のコール電話がスケジューリングされる。885で処方者から戻された電話または返信されたファックスは、890でハントルーチンを起動して注文をシステム上で探し出す。電話のかけ直しが処方者から所定の時間内に受信される場合、890でその注文がシステム上で探し出され、850で該電話がシステム上のユーザに転送され、850でこのユーザは該注文をバーチャルシェルフ仮想棚から検索する。次いで855で、ユーザは処方者と共にこの注文を見直し、プロトコルを解決するために必要な情報を処方者に対して求める。860でプロトコルが解決された後、該注文が865で作業キューに、さらなる処理のために入れられる。885で、ファクシミリが処方者から受信される場合、このファクシミリは注文にリンクされ、ユーザはファクシミリ内に含まれた情報を見直してプロトコルを解決する。該プロトコルの解決にあたり、該注文が作業キューに、さらなる処理のために入れられる。別法として、アウトバウンドコールキューステップを通じて進むことなく、この連絡先に電話をかけることができる。注文をアウトバウンドコールキューにルーティングするのではなく、870でユーザは単に連絡先を選択し、875で、選択された連絡先へのコールを開始する。880で連絡先に電話が繋がる場合、ユーザは連絡先と共に注文を見直し、プロトコルを解決するために必要な情報を連絡先に対して求める。該プロトコルが解決された後、この注文は更新され、さらなる処理のために作業キューに入れられる。連絡先に電話が繋がらない場合、該注文はアウトバウンドコールキューにルーティングされる。ファックス連絡管理図11は、ファックス連絡管理のための流れ制御の一実施例を例示する。900で、解決されるべきプロトコルが選択される。プロトコルを解決するために必要なフィールドが、905でファクシミリ内でポピュレートされる。910で、連絡担当者が選択される。さらなるアクションが取られる前に応答を受信するための時間が915で選択される。手動のファクシミリを送信するか、システムにより生成された電子ファクシミリを送信するかについての判断が920で行われる。925で、選択された時間内に応答が連絡担当者から受信される場合、ファクシミリ内に含まれた情報に従って注文が更新される。受信されたファクシミリが注文の一部になるプロセスは、ファクシミリが受信されるモードに応じて異なる。930でファクシミリが手動または紙媒体としてのファックスである場合、950で注文がシステム上で探し出され、955でファクシミリ内の情報が入力される。次いで960で、手動または用紙のファクシミリがスキャンされ、イメージ化された注文文書、または、アーカイブ記録保管された書類束における注文文書のうち少なくとも1つに965で挿入される。別法として、スキャンされたイメージが、イメージ化された注文文書およびアーカイブされた書類束に挿入される。ファクシミリが電子的であるか、そうでない場合はあるファックス処理システムから別のファックス処理システムへと生成される場合、該注文は、ファクシミリ内に含まれた情報に基づいて更新され、該受信されたファクシミリは970でイメージ化された注文文書の一部となる。手動または電子のインバウンド入来ファクシミリが、選択された時間内に受信されない場合、該注文は975でアウトバウンドコールキューにルーティングされ、その後に図10のステップ830から845が続く。アウトバウンドファックスが連絡先向けに受信されるが、注文が連絡先との実際の連絡を必要とする場合、該注文は940でアウトバウンドコールキューにルーティングされる。図13A~13Eは、図10および図11の代替的実施形態を表し、特定のプロトコル解決のコンテキストに対する連絡管理のための流れ制御を例示する。注文完成中に、注文が見直されて、必要とされた処方箋要素が存在するかどうが判断される。必要とされた処方箋要素は、処方箋の重要な要素を表すが、この要素は存在しなければならず、処方箋を調剤するために有効でなければならない。すべての必要とされた要素が存在する場合、注文が見直される。しかし、必要とされた要素が存在しない場合、注文が、少なくとも1つのさらなる作業キューへ追加処理のためにサブミットされる。アルファAlphaのみが未解決のまま残っているか、ルーター、カウンタ、およびフラグプロトコルが未解決のまま残っているかについての判断が行われる。注文がロックされて追加の注文編集を防止し、調剤薬局にルーティングされる準備ができるまで、アルファAlphaプロトコルは自動的に作成および解決され、各注文ごとに存在する。注文完成は、注文に関するいずれかの適用可能なプロトコルの解決に関連する。プロトコルをリレーショナルデータベースに対してチェックすることによって、プロトコルを解決することができない場合、処方者または処方者の事務所内の誰かに連絡を取り、プロトコルを解決することが1025で必要である場合がある。1025で、適用可能なプロトコルを解決するために処方者の連絡が必要である場合、1030で注文がアウトバウンドコーリングキューにルーティングされる。1035で注文がシステムユーザによって検索され、解決されるべき未解決のプロトコルを処方者にファックスすることによって、プロトコルを解決することができるかどうかについての判断が1040で行われる。1040で、処方者にファックスすることによってプロトコルが解決可能である場合、1045でファックスが処方者に送信される。ファックスを処方者に送信することで、タイムスタンプがシステム内で作成される。1050で、タイムスタンプから所定値に対する時間が計測され、タイムスタンプから計測された時間が所定値を超える場合、ファックス待機時間がタイムアウトされ、1030で注文がアウトバウンドコールキューにルーティングされ、ここでステップ1030から1040が繰り返される。しかし、1055でインバウンドファックスが所定値内に受信される場合、1060で自動マッチプロセスが開始され、着信ファックスを、該着信ファックスが応答する相手である元の発信ファックスを引き起こした注文とマッチさせるように試みる。1065で注文が発見される場合、1070で、システムユーザは、着信ファックス内に含まれた情報を注文に入力する。次いで1070で注文が見直され、1075で解決処理のためにサブミットされる。別法として、1065で、自動マッチプロセスを通じて注文が発見されない場合、1080で、標準動作手順プロシジャを通じて注文が処理されるようになる。標準動作手順プロシジャには、例えば、ユーザが、受信された応答を、システム上の注文の現在の状態に対して見直すことが含まれる。例えば、注文がキャンセルされている場合、さらなるアクションは取られない。注文が調剤薬局に送信されている場合、ファックスされた応答がシステムデータと比較されて、正しい情報が処理されると判断される。システム上のデータがファックスされたデータと同じである場合、さらなるアクションは取られないが、矛盾が存在する場合、注文がユーザによってさらなる処理および解決のために見直される。1056で送信元から測定された所定値内で受信されない応答は、1030でアウトバウンドコールキューにルーティングされる。インバウンド着信ファックス応答が1250でファックスサーバ上で受信される場合、ファックスサーバが該応答を、ファックス応答識別に基づいて1255で作業キューにルーティングする。1260ですべての注文対象が作業キューから検索され、1265でファックス応答が注文に付加される。1056で送信元から計測された所定値内で受信されない応答は、1030でアウトバウンドコールキューにルーティングされる。ファックスを処方者に送信することによってプロトコルが解決可能でないと1040でユーザが判断する場合、1085でユーザは電話を開始し、1090で処方者にダイヤルする。1095で、ダイヤルされた番号に着信した際には、1100で、ユーザは処方者または他の意思決定者に連絡を取ろうと試みる。1100で処方者または他の意思決定者に到達される場合、1105でユーザは解決されるべきプロトコルを導入し、1110でコールを薬剤師に転送する。コール転送の後に次いで、あるいはそれと同時に、1115でユーザは注文を棚上げして注文を薬剤師にルーティングする。1120で薬剤師は注文をシェルフ棚から検索し、1125で介入を処方者と共に見直し、プロトコルを解決する。次いで1130で、注文が作業キューへさらなる処理のためにサブミットされる。電話をかけた際に、1095で応答がない場合、1135でかけ直し伝票が完成され、コールが再スケジューリングされ、1140で、それに応じてアウトバウンドコールキューが更新される。1145でかけ直し伝票が印刷され、1030で注文がアウトバウンドコールキューにルーティングされる。別法として、1100で、コールが応答を求めるが処方者または他の意思決定者が応答できない場合、1150でかけ直し伝票が完成され、1150で注文識別情報が処方者の事務所に残される。1140で、それに応じてアウトバウンドコールキューが更新される。1145でかけ直し伝票が印刷され、1030で注文がアウトバウンドコールキューにルーティングされる。図13Cは、1155で、アウトバウンドコールキュープロセスを通じて残されたメッセージに処方者が応答中であるときの、処方者のかけ直しプロセスの一実施例を例示する。1160でコールが、かけ直しのために指定されたハントグループへルーティングされる。1165でシステムユーザはコールを受信し、初期情報を得る。1170で処方者が注文インボイス請求書情報を有する場合、1175で、システムユーザは注文を、インボイス番号または他のプロトコル解決アプリケーションを使用して検索する。別法として、1180でシステムユーザは、アウトバウンドコールキュープロシジャから生成されたかけ直し伝票を、患者のラストネームを使用して検索する。システムユーザは注文を探し出した後に、1110でコールを薬剤師に転送する。次いでコール転送の後に、あるいはそれと同時に、1115でユーザは注文を棚上げして該注文を薬剤師にルーティングする。薬剤師は1120で注文をシェルフ棚から検索し、1125で介入を処方者と共に見直し、プロトコルを解決する。次いで1130で、該注文が作業キューへさらなる処理のためにサブミットされる。別法として、1190で、処方者または処方者の事務所に連絡を取る代わりに管理プロトコルによって、適用可能なプロトコルを解決することができる場合、1195で適用可能な管理プロトコルが注文に、管理またはルールリレーショナルデータベースから適用される。1190で、管理プロトコルの適用によって注文が解決可能でない場合、1200で、注文が処方者または処方者の事務所へのいずれかの未解決コールを有するかどうかについての判断が行われ、そうでない場合、1205で、プロフェッショナルプロトコルリレーショナルデータベースを使用して注文が解決される。1205で少なくとも1つのプロフェッショナルプロトコルが注文の解決に適用された後、1210で、どこで処方者または処方者の事務所への連絡が、いずれかの追加の未解決の適用可能プロトコルを解決するために必要であるかについての判断が行われる。1215で処方者のコールが必要でないと判断される場合、1220で薬剤師は、どの注文項目が求められるべきであるかを指示し、1030で注文をアウトバウンドコールキューにルーティングする。コールが必要であると判断される場合、1225で該注文が更新され、1230で作業キューへさらなる処理のためにルーティングされる。しかし、注文が、それと、処方者もしくは処方者の事務所への未解決コールを関連付けている場合、処方者もしくは処方者の事務所が指定された待機時間内で応答するか、あるいは、注文が待機キュー内で費やす時間が所定の値を超えるまで、注文が1050で待機キューにキューイングされる。図14A~14Eは、マネジドケアプロトコルを有する注文の解決の一実施例を示す。マネジドケアプロトコルはプロフェッショナルプロトコル内で存続し、治療的に同等の代用薬剤が、処方されたものについて使用可能であるときに生じる。治療的に同等の代用薬剤の使用可能性は、交換の機会を提示する。処方者に電話またはファックスによって連絡が取られて、処方者が交換要求を承認するかどうかが判断される。1300で薬剤師が編集を見直し、最初に、処方箋がスクリーンアウト或いはファックス可能であるかについて1305および1310でそれぞれ判断する。処方箋がスクリーンアウトである場合、1315で、薬剤師は注文を標準動作プロシジャによって解決し、次いで1320で作業キューへ、1325でのさらなる処理のためにリリースする。スクリーンアウトは、マネジドケアの機会または交換の機会を追求するために不十分なシステムリソースまたは時間の結果として生じる。標準動作プロシジャには、例えば、注文が交換として追求されなかったことを示すシステム画面を更新することが含まれる。処方箋がスクリーンアウトでないが、その代わりにファックス可能である場合、自動ファックスが起動される。アウトバウンドファックスに応答したかけ直しコール或いは他の連絡を受信するための日付および時間が1330で注文に付加される。1335でシステムは、注文の解決を促進すべく自動ファックスが起動されたことを反映するように更新される。1343で応答が所定の時間内に受信されるか、もしくは1350で注文が待機キュー内で費やす時間が所定の時間を越えるかするまで、1340で注文が待機キューに入れられる。1341で、注文が待機キュー内で費やす時間が所定の時間を越える場合、1400で注文がアウトバウンドコールキューにルーティングされる。アウトバウンドコールキューは、ファックス可能でない注文、または、注文が待機キュー内で費やした時間が所定値を超えている注文のためのものである。1405で、アウトバウンドコールキュー内の注文が、キューからユーザによって検索される。注文がキューから検索された後、1400でユーザは注文処方者にダイヤルする。1415でアウトバウンドコールが応答される場合、ユーザは1420で処方者または他の意思決定者に連絡しようと試みる。処方者または他の意思決定者に連絡がつく場合、1425でユーザは懸案事項を導入し、1430で、処方者に連絡を取る際の発信番号が安全なファックス番号である場合、1435でユーザは処方者のマスタファイル情報を更新し、1325で自動ファックスを起動する。別法として、処方者に連絡を取る際の発信番号が安全なファックス番号でない場合、1440でユーザは該コールを薬剤師に転送する。薬剤師へのコールの転送と同時か、あるいはそれに続いて、1445でユーザは注文を薬剤師のバーチャルシェルフ仮想棚にルーティングする。1450で、薬剤師は注文をバーチャルシェルフから検索し、1455で、解決されるべきプロトコルについて処方者と共に話し合う。1460でかけ直しが必要である場合、1465で薬剤師はかけ直しの日付、時間およびコメントを、処方者連絡追跡画面および連絡システム画面で入力し、1470で可視性プロトコル追加を割り当て、かけ直し伝票を完成させる。1475で、かけ直しを行うための時間がタイムアウトにされる場合、1400で注文がアウトバウンドコールキューにルーティングされ、図14Cのステップ1400から1415までが繰り返される。1480で所定の時間内に受信されたインバウンドコールは、1485で、かけ直しのためにそれらの指定されたハントグループにルーティングされる。1490で、非薬剤師はコールを受信し、注文に関する初期情報を得る。最初に1495で、非薬剤師は注文を、そのインボイス番号を通じて探し出そうと試みる。しかし、発呼コール者がインボイス番号を有していない場合、1500で非薬剤師は、患者のラストネーム、かけ直し伝票、または他のプロトコル解決アプリケーションを使用して注文を探し出そうと試みる。コール者がインボイス番号を有していない場合、非薬剤師は、プロトコル解決を使用して注文を探し出そうと試みるようになり、このプロトコル解決によりユーザは必要に応じて画面を通じて進むことができる。図12Aおよび12Bは、本発明の代替的実施形態による、注文に付加されたマネジドケアプロトコルを有する注文の解決の一実施例を示す。この実施形態によれば、薬剤交換ジェネリックバージョン同効医薬品への切り替えのための承認は、処方箋が処理された後に発生する。承認された注文にはシステム上でフラグが立てられ、再調剤時に薬剤交換が発生するようになる。1600で注文への編集が見直されて、注文が処方集コンプライアンス認証とマッチするかどうかが判断される。1605で交換認証がいずれかの他の薬局で入手可能である場合、1610で注文が監督者にルーティングされる。該監督者は1615で他の監督者と連絡を取る。処方集コンプライアンスを示すファックスが1620で受信される。当該処方集コンプライアンスレターが1625でスキャンされ、注文に挿入される。注文が1630でアウトバウンドコーリングキューにルーティングされる。検証コールが1635で行われ、1640でその交換が検証される場合、1645で薬剤師がシャドーファイル内で処方箋に注釈を付け、1650で、法律によって必要とされる患者および処方者レターを印刷するアプリケーションにおいて好ましくない処方箋を手動で入力する。このアプリケーションは、クオンセットハットQuonsethutと呼ばれる。次いで、当該ファックスの処方集コンプライアンスレターのハードコピーが1655で破棄され、1660で注文が作業キューに、さらなる注文処理のためにリリースされる。1640で交換が検証されない場合、1665で注文がマネジドケア標準動作プロシジャによって処理され、1670で作業キューに、さらなる注文処理のためにリリースされる。標準動作プロシジャには、例えば、交換が承認されないときに引き続いて行われる手動のプロシジャが含まれ、標準動作プロシジャにより、システムファイルを更新して注文処理が継続できるようにすることができる。しかし、1605で交換認証が入手可能でない場合、1675で処方箋コンプライアンスレターにマッチしようとする試みがある。1680で、好ましくない処方箋がクオンセットハットにおいて手動で入力される。処方集コンプライアンスレターおよび処方箋ハードコピーがシステムに1685でスキャンされる。スキャンされたイメージが他のイメージ注文文書に1690で挿入される。1695で注文が作業キューに、さらなる注文処理のためにリリースされる。1700で、元の処方集コンプライアンスレターが標準動作プロシジャによって裁断される。図13A~13Bは、本発明の代替的実施形態による、注文に付加されたマネジドケアプロトコルを有する注文のプロトコル解決の実施例を示す。1900で、プロトコルがマネジドケア注文に追加される。1905でマネジドケア注文が見直されて、該注文が前のファックスとマッチするかどうかが判断される。1910で、交換認証が別の薬局内で存在する場合、1915で注文が監督者にルーティングされ、1920で該監督者は他の監督者に連絡を取る。1925でファックスが受信され、1930で前のファックスがイメージ化され、注文イメージ注文文書に挿入される。次いで1935で、注文がアウトバウンドコールキューへ検証コールのためにルーティングされる。1940で検証コールが行われ、もし1945で交換が検証される場合には、1950で、プルおよびコピーPULLC/PULLNユーティリティを使用して、処方箋のための再調剤が新しい処方箋番号と共にシステムに入力される。プルおよびコピーユーティリティは処方箋を新しいインボイス請求書にコピー複写する。次いで1955で、この注文が薬剤師にルーティングされ、1960で、マネジドケア標準動作プロシジャに従って交換が処理される。1965で、好ましくない処方箋がクオンセットハットにおいて手動で入力される。1970で処方者レターが生成され、1975で前のファックスコピーが標準動作プロシジャによって破棄される。注文は作業キューに、さらなる注文処理のためにリリースされる。1945で交換が検証されない場合、1946で、マネジドケア標準動作プロシジャに従って該注文が処理される。1910で交換認証が別の薬局内に存在しない場合、1916で該注文が非薬剤師にルーティングされ、1917で前のファックスがスキャンされ、イメージ化される。このイメージ化された前のファックスが、1918で、イメージ化された注文文書に付加され、1919で処方箋に注釈が付けられる。1950で、PULLC/PULLNユーティリティを使用して、処方箋のための再調剤が新しい処方箋番号と共にシステムに入力される。次いで1955で、この注文が薬剤師にルーティングされ、1960で、マネジドケア標準動作プロシジャに従って交換処理される。1965で、好ましくない処方箋がクオンセットハットに手動で入力される。1970で処方者レターが生成され、前のファックスコピーが標準動作プロシジャによって1975で破棄される。1980で該注文が作業キューに、さらなる注文処理のためにリリースされる。コマンドおよび制御図17は、コマンドおよび制御モジュールへの情報可視性の概略図を示す。コマンドおよび制御モジュールは、注文処理システムの頂上にあるユーザインタフェースである。コマンドおよび制御モジュールは、作業キューのアクティビティ、個別ユーザのアクティビティ、プロセス制御情報、システム実働およびシステムリソース可用性を追跡する。コマンドおよび制御モジュールはいずれかの単一のキュー或いはキューのグループについての情報を抽出し、抽出されたデータに対して、標準データベースクエリツールを通じて操作を実行して、いずれかの単一の、あるいは組み合わせの、システムの側面アスペクトについての状況レポートを作成することができる。結果として生じるレポート内のデータは、それらを生成するために使用された、基礎データにハイパーリンクされる。図18は、コマンドおよび制御モジュールのユーザインタフェースの一部である、計器盤の一実施例を示す。図18は、選択されたシステムキューの状態を表す計器盤を含む画面を示す。計器盤のゲージは、該計器盤内に存在する各選択されたキューにおける定量的負荷を示す。各ゲージはまた、各表現されたキューのヘルスを色によって示すものである。各ゲージが呈することができる色の範囲は所定であり、少なくとも3つのキューヘルス状態を示すように選択される。第1の色は、キューが正常であり、過負荷になっていないことを示す。第2の色は、警告、および、キューが臨界負荷ポイントに近づきつつあることを示す。第3の色は、キューがその臨界負荷ポイントを超えており、該負荷をリバランス再調整してキューレベルを受け入れ可能な動作範囲内に下げるためにシステム調整が行われなければならないことを示す。各ゲージは、ゲージ表現を担う基礎データにハイパーリンクされる。特定のゲージの選択は、該ゲージを表現するキュー内のすべての注文に至るまでドリルダウンする。選択されたキュー内の注文を、図19に示すようにグラフで、あるいは図20に示すように表形式フォーマットで、表示されるように構成することができ、いかなるグラフ形式の縦軸および横軸、または表の列および行も、ユーザによって、キュー内の注文をいくつかの変数によって表現するように構成可能であり、これには例えば、キューに最新に到着した注文から、同じキュー内で最長に保持された注文までの時間を、所定の間隔にスライスして、キュー内の注文の分布を時間単位で示すことが含まれる。この一実施例を図21に示す。図19は、選択システムキューのグラフ表現を示す。図20は棒グラフであり、ここでは各棒は特定のキューを表し、棒の高さはそのキュー内の注文数を表す。棒グラフ内の各棒はその基礎となるキューにハイパーリンクされ、該基礎データにリンクすることにより、該選択されたキュー内のすべての注文のリストが得られる。図20は、選択システムキューを表フォーマット形式で示し、このフォーマットでは、各キューが、該キュー内に含まれた注文のカテゴリまたはタイプ、いずれか1つのキュー内のシステム注文の総数、および、いずれか1つのキュー内にある合計のシステム注文の割合まで分析される。キューのカテゴリには、例えば、注文が新しい処方箋であるか、再調剤処方箋であるか、または、新しい処方箋および再調剤処方箋の混合であるか、注文なしで支払いのみである注文がいくつあるか、および、その他の包括的なカテゴリ内にいくつの注文があるかが含まれる。表エントリはそれらのサポートするデータにハイパーリンクされ、ユーザがその基礎データにリンクまたはドリルダウンできるようになる。図22は、選択キューの棒グラフおよび選択キューの表が共に提供される結合画面を表す。棒グラフ内で提示されたキューは必ずしも表内で提示されたものと同じキューでなくてもよい。本発明のコマンドおよび制御モジュールはまた、注文処理システム内の注文の追跡のための、いくつかのポジティブ制御メカニズムも提供する。あるポジティブ制御メカニズム、および本発明の代替的実施形態は、各システムキューが、注文が直接に受信される場合の発信元である先行キューからの注文の受信を確認応答することに関連する。もう1つのポジティブ制御メカニズム、および本発明の代替的実施形態は、本発明の注文処理システムが、注文が所定の時間よりも長く特定のものに存在しているときにはいつでもユーザにアラート警報を送信するか、あるいはユーザにページングする呼び出すことに関連する。ポジティブ制御はまたユーザに、システム内におけるいかなる注文をも探し出し、薬局または注文処理システム中を通じた注文の行程を見直す能力も提供する。ポジティブ制御データベースに問い合わせて注文を見直す方法には、例えば、インボイス番号によるもの、処方箋番号によるもの、会員番号によるもの、および、作業注文IDによるものが含まれる。上記の情報のいずれか1つで開始して、ユーザは例えば、注文が現在所在する先であるキュー、注文がこれまでに所在していたキュー、注文が各キュー内で費やした時間の量、および、注文が薬局に存在していた合計経過時間を識別することができる。本発明のコマンドおよび制御モジュールを、ブラウザベースの機能性を提供するように構成することができ、このモジュールは、いかなる適切なパーソナルコンピュータまたはワークステーション上でも動作することができる。ネットワーク構成図23は、本発明によるシステムのための1つの可能なハードウェアおよびネットワーク構成を示す。PCワークステーション2300はデータサーバ2305に接続され、データサーバ2305はローカルエリアネットワークLAN2310に接続される。データサーバ2305はLAN上の他のサーバおよびメインフレームシステム2315と通信して、ユーザにワークケースを提示する。また、PCワークステーション2300に接続されるものは、バイオメトリックキャプチャ装置2316であり、これはPCワークステーション2300、およびしたがってデータサーバ2305、LAN2310およびシステムメインフレーム2315へのアクセスを制御する。光学スキャナ2320バーコード読み取り機能を含む場合があるはイメージサーバ2325に接続され、イメージサーバ2325はLAN2310に接続される。ワークフローサーバ2330はLAN2310に接続され、注文の流れを管理する。光ディスクサーバ2335およびジュークボックス2340はLAN2310に、イメージのアーカイブ記録保管の目的で接続される。また、LAN2310に接続されるものは、システム処理ロジックを識別するリレーショナルデータベースのシステム2345である。LAN2310に接続されたコンポーネントの全体の集合は、単一のハブ2350または注文処理センターを表す。本発明の1つのネットワーク構成は、それぞれ中央システムメインフレーム2315に接続された、地理的に異なるハブ2351、2352および2353のシステムからなる。分散注文処理本発明の代替的実施形態によれば、図1の各プロセッサによって実行される機能を、いくつかのハブに渡って分散させることができる。例えば、ハブ1は、入来する郵便の前処理およびスキャンのすべてを行うのに対して、ハブ2はすべての非臨床データのエントリを担い、ハブ3は臨床注文エントリおよび/または検証のみを行う。次いで、ハブ4は実際の調剤および出荷を実行するようになる。別法として、フロントエンドおよびバックエンドタスクに基づいて、処理タスクを複数のハブに渡って分散させることができる。例えば、ある単一のハブはすべての注文処理ステップまでを実行し、注文を単一の調剤薬局もしくは複数の薬剤局にルーティングすることを含むことができるのに対して、第2のハブはすべての注文の調剤および出荷ステップを実行するようになる。別法として、各ハブはその割り当てられた地域からの注文を受信および処理するようになる。例えば、ニューヨークハブは、米国の北東部における州からの注文を受信および処理するようになり、中央カリフォルニアハブは、米国の南西部における州からの注文を受信および処理するようになる。本発明は、医療処方箋の処理に関連するアプリケーションに限定されず、通信販売業界が紙媒体文書および手動の文書送信方法への依存を減らすことを望むいかなる状況にも適用することができる。本明細書で説明した様々なプロセスおよびフローチャートを、異なるものに修正しおよび/または異なる順序付けをすることができる。概して、本発明の実施形態の様々な構成要素をハードウェア、ソフトウェア、またはそれらの組み合わせにおいて実施することができることは、強調されるべきである。このような実施形態では、様々な構成要素およびステップがハードウェアおよび/またはソフトウェアにおいて実施されて、本発明の様々な機能が実行される。いかなる現在利用可能なまたは将来開発されるコンピュータソフトウェア言語および/またはハードウェアコンポーネントも、本発明のこのような実施形態において使用することができる。例えば、上述の機能性の少なくともいくつかを、CまたはCプログラミング言語を使用して実施することができる。本発明の好ましい実施形態および代替的実施形態をここで詳細に説明した。しかし、これらの特定の実施形態のこうした説明は、本発明の概念の基礎をなしている原理を例示するにすぎないことに留意されたい。したがって、開示された実施形態の様々な改良修正は、本発明の精神および範囲から逸脱することなく、いわゆる当業者には明らかになるであろうことが企図される。"