JP2016512907A - レビューポータル - Google Patents

Abstract

一例では、システムは、フォーム、例えば医療レビューフォームを動的に実行するために提供される。一例では、システムはフィールドの蓄積を保有する。フィールドを蓄積から選択して、テンプレート、例えばレビューテンプレートが形成されてもよい。テンプレートに基づいて、カスタマイズされた電子フォームをブラウザに表示するために動的に実行してもよい。

Description

独立した医療レビューが知られている。客／顧客は、例えば医療記録、医療請求記録等の医療情報を独立したレビュアーに提供し、レビュアーは医療サービスの質および／または医療サービスの費用／請求について意見を提供してもよい。

医療レビューを得るプロセスでは、電子フォームが関連し得る。例えば、医療情報を収集するために客／顧客に電子フォームを与えてもよい。電子フォームを生成するいくつかの既知のシステムは、顧客が必要とする特定のサービスに基づいて電子フォームをハードコードすることを含む。

以下は、本発明のいくつかの態様の基本的な理解を提供するための発明の概要である。この概要には、本発明の主要／重大な要素を識別する、または本発明の範囲を線引きする意図は無い。その唯一の目的は、本発明のいくつかの概念を、以下に提示するより具体的な記載の前置きとして簡潔化された形式で提示することである。

一例では、例えば、医療レビューフォームといったフォームを動的に与えるために、システムが提供される。一例では、システムはフィールドの蓄積を保有する。その蓄積からフィールドを選択して、例えばレビューテンプレートといったテンプレートを形成してもよい。カスタマイズされた電子フォームは、ブラウザ上に表示するためのテンプレートに基づいて動的に表示されてもよい。

システムはフォームの一部を３つ以上の関係者に提供してもよい。一例では、第一者は医療レビュー組織のスタッフを含み、第二者は医療レビュー組織の顧客を含み、第三者はスタッフとは独立した専門家、例えばスタッフとは独立した医師などの医療専門家を含む。一例では、システムはそのレビューについて複数の予め定義されたレビューステージタイプを保有するように構成される。複数のうちの第１のレビューステージタイプは第一者に対応してもよく、第２のレビューステージタイプは第二者に対応してもよく、第３のレビューステージタイプは第三者に対応してもよい。システムは、カスタムワークフローのためのユーザ入力を受信したことに反応して、ワークフロー定義を形成するように構成されてもよい。ワークフロー定義は、複数のステージタイプのうちの選択されたもの、および複数のステージタイプのうちの選択されたものに基づいてプロセスを実行するための選択された順番を識別してもよい。

一例では、複数のレビューステージタイプのうちの少なくとも１つは、第三者の少なくとも１つの個人を選択するディスパッチステージを含んでいてもよい。ディスパッチステージは、第二者によって設定されたパラメータに基づいて、一式の専門家からサブセットを選択するためのフィルタリングを含んでいてもよい。パラメータの例には、週に閾値時間数で勤務する医師、開業外科医、特定のステージで有資格の医師、特定のトレーニングプログラムを修了した医師等、またはその組み合わせが含まれる。一例では、ディスパッチステージは、第一者によって設定されるパラメータに基づいて、フィルタリングの結果として得られたサブセットを複数のグループに分けるためのグループ分けを含んでいてもよい。一例では、ディスパッチステージは、レビュー割当について複数のうちの第１のグループのメンバーに第１回目に通知すること、および複数のうちの第１のグループとは異なる第２のグループのメンバーに第１回目とは異なる第２回目に通知することを含む、スケジューリングを含んでいてもよい。一例では、第２回目は、固定された日時と、第１のグループの全てのメンバーがレビュー割当を明示的に拒否した日時とのうちの早い方であってもよい。

本発明の追加の態様および利点は、添付図面を参照して続く以下の好適な実施形態の詳細な説明によって明らかとなるであろう。

図１Ａは動的にフォームを表示するためのシステムを図示する。 図１Ｂは、図１Ａの処理デバイス１３の動作を示すフローチャートを図示する。 図２Ａは、例示的な実行プロセスを図示する図である。 図２Ｂは、例示的な実行プロセスを図示する図である。 図３Ａは、例示的なレビューポータルのポータル管理部の例示的な表示を図示する。 ３Ｂは、例示的なレビューポータルのポータル管理部の例示的な表示を図示する。 図４は、ディスパッチスケジューリングのためのグループ割当の例を図示する。 図５は、レビューフィールド保存動作のための例示的なプロセスを図示する。 図６Ａは、レビュー再提出のための顧客ワークフローを図示する。 図６Ｂは、図６Ａの顧客ワークフローのための変形コードを図示する。 図６Ｃは、レビュー再提出のためのレビュアー／プロセッサワークフローを図示する。 図６Ｄは、図６Ｃのレビュアー／プロセッサワークフローの変形コードを図示する。 図６Ｅおよび図６Ｆは、レビュー再提出についての請求ワークフローを図示する。 図６Ｅおよび図６Ｆは、レビュー再提出についての請求ワークフローを図示する。 図６Ｇは、請求ワークフローについての変形コードを図示する。 図６Ｈは、レビュー再提出についての請求書発行概要を図示する。

図１Ａは、動的にフォームを表示するシステムを図示する。

システム１００は、リモートデバイス９のブラウザ１０によって表示されるための、医療レビューフォーム等の動的に表示されるフォームを提供するためのネットワークデバイス１１を含む。ネットワークデバイス１１は、ネットワークデバイス１１の近隣または遠隔的に位置してもよい記憶デバイス１９の情報に基づいて、フォームを動的に表示するための処理デバイス１３を含む。一例では、リモートデバイス９は、デスクトップコンピュータ、モバイルデバイス等の既知の端末である。一例では、ブラウザ１０は既知のブラウザである。

一例では、記憶デバイス１９は複数のフィールド１５を記憶してもよい。記憶デバイス１９は複数のテンプレート１７、例えば、少なくともフィールドの第１の組み合わせおよび第２の異なるフィールドの組み合わせを記憶してもよい。各テンプレートは少なくとも１つの標準フィールドおよび／または少なくとも１つのカスタムフィールドを含んでいてもよい（一式の標準フィールドが提供されてもよく、標準フィールドの１つを変更することで、対応する客／顧客によって使用されるためのカスタムフィールドが生成されてもよい）。

処理デバイス１３は、選択されたテンプレートの各フィールドで実行プロセスを行うように構成されてもよい。図２Ａ〜２Ｂにフィールドごとの実行プロセスの一例を図示するが、これは後ほどより具体的に説明する。処理デバイス１３は実行されたフィールドの第１のセット１２をリモートデバイス９に送信して、ブラウザ１０を介してレビューフォームを含むウェブページを表示させてもよい。

リモートデバイス９のユーザがウェブページのフィールドの１つにデータを入力すると、処理デバイス１３はその入力データに基づいてアップロード１４を受信してもよい。処理デバイス１３は、入力データを受信したことに反応して、選択されたテンプレートのフィールドを選択的に再実行してもよい。選択的に再実行することは、テンプレートのフィールドのサブセットのみ、例えば更新に対応するフィールド、および対応するフィールドに直接的または間接的に依存すると判定されたフィールドに行われてもよい。再実行は、図２Ａ〜２Ｂに図示されるフィールドごとの実行プロセスに従っていてもよい。例えば、図２Ａ〜２Ｂのプロセスは、ユーザ入力に関連付けられるフィールドのサブセットについて再実行されてもよい。

一例では、処理デバイス１３はフィールドごとの依存性リストを維持していてもよい。各リストは、フィールドが実行されたときに生成されてもよい。一例では、実行することは、例えばＪａｖａＳｃｒｉｐｔ（登録商標）を解析することといったフィールドのコードを解析することを含んでいてもよく、リストはコードを解析した結果に反応して生成されてもよい。生成されたリストは、対応するフィールドの再実行中に保有およびアクセスされてもよい。対応するフィールドの再実行中に、対応するリストに示される依存フィールドは、保有されるリストの他のものを識別してもよく、それらは例えば、さらに多くの対応するリストを識別してもよい。一例では、処理デバイス１３は循環参照の場合はリストを識別するのを停止するように構成されてもよい。

一例では、コードはフリーフォームＪａｖａＳｃｒｉｐｔ（登録商標）テキストボックスのものである。そのＪａｖａＳｃｒｉｐｔ（登録商標）内で、テンプレートマネージャはフィールド名を入力してもよい。テンプレートマネージャ内にフィールドを保存することに反応して、処理デバイス１３は全てのテキストボックスを解析することで任意の既知のフィールド名が含まれているかを判定してもよい。処理デバイス１３はフィールド名を依存性リストに加えてもよい。

処理デバイス１３は、実行されたフィールドの第２のセット１６をリモートデバイス９に送信して、レビューフォームを含むウェブページが変化するようにさせてもよい。ブラウザ１０のユーザの観点による経験では、レビューフォームは、ユーザとの相互作用で動的に変化し得る。フィールドは、ユーザがデータを入力することで、（選択的にフィールドを再処理する処理デバイス１３に基づいて）現れたり消えたりしてもよい。フィールドは、外見および／または機能性において変化してもよい（再実行に基づく）。

一例では、システム１００は、処理デバイスによって実行されることに反応して処理デバイスに動作を行わせる命令を記憶するメモリデバイスを含む。一例では、動作は、電子医療レビューフォームを形成するための複数のフィールドを記憶することと、複数のテンプレートであって、テンプレートの１つ目は複数のうちのフィールドの第１のセットまたはサブセットを含み、テンプレートの２つ目は複数のうちのフィールドの第２のセットまたはサブセットを含み、第２のセットまたはサブセットは第１のセットまたはサブセットとは異なる複数のテンプレートを記憶することと、複数のテンプレートのうちの１つのテンプレートを選択することと、選択されたテンプレートのフィールドを用いてウェブページを生成することと、を含む。

図２Ａ〜２Ｂは、実行プロセスにおける例示的な処理デバイスの動作を示すフローチャートを図示する。

ブロック２０３では、処理デバイス１３は選択されたテンプレートのフィールドを取得してもよい。ダイヤ２０５では、処理デバイス１３はフィールドが可視であるかを判定してもよい。可視性は、ワークフローステージごとに基づいて判定されてもよい。例えば、フィールドはワークフローの第１ステージでは可視ではないが、第１のステージとは異なる第２のステージでは可視であってもよい。

一例では、可視性はフィールドの実行コード、例えば、解析ＪａｖａＳｃｒｉｐｔ（登録商標）に基づいて判定されてもよい。実行時、コードは真値または偽値を結果として得るように実行されてもよい。例えば、６つの値の各値について真または偽を返してもよい。値の１つは可視性に対応してもよい。コードは、例えば、複数のレビューステージタイプのどのレビューステージタイプが現在のステージに対応するのか、複数の関係者のうちのどの関係者がフィールドをレビューしているのか、関連するフィールドの状態（例えば、関連するフィールドの可視性）等の条件、またはその組み合わせを確認してもよい。一例では、可視性は、コードに関連付けられる対応する値について真を返すことに反応的であるように判定されてもよい。

フィールドが可視であると判定された場合は、ダイヤ２０７では、処理デバイス１３はフィールドが読み取り専用かどうかを判定してもよい。一例では、読み取り専用の判定は、例えば解析ＪａｖａＳｃｒｉｐｔ（登録商標）等のフィールドの実行コードに基づく。可視性判定に対応するコードと同様に、例えば、複数のレビューステージタイプのどのレビューステージタイプが現在のステージに対応するのか、複数の関係者のうちのどの関係者がフィールドをレビューしているのか、関連するフィールドの状態（例えば、関連するフィールドの可視性）等の条件、またはその組み合わせが確認されてもよい。

フィールドが読み取り専用として判定された場合、ブロック２０８では、処理デバイス１３はフィールドを、読み取り専用属性２０８に基づいて２１５実行してもよい。フィールドはラベル、例えば変更不可能なフラットテキストとして実行されてもよい。

フィールドが読み取り専用でないと判定された場合、ダイヤ２０９では、処理デバイス１３はフィールドが必要かどうかを判定する。一例では、レビューステージおよび／または、医療レビューフォームを完成させるためにフィールドを完成させる必要を有していてもよい。

ダイヤ２１０では、処理デバイス１３は、フィールドに入力される情報を、バリデータ、例えばカスタムバリデータを用いてバリデートするかどうかを判定してもよい。一例では、カスタムバリデータは、例えばＪａｖａＳｃｒｉｐｔ（登録商標）コードなどのコードを含んでいてもよい。カスタムバリデータは、対応するフィールドに入力されるユーザ入力データが有効かどうかを確認し、そうでない場合は、対応するエラーメッセージを生成するようにさせて、ユーザに入力した値を確認させるおよび／または異なる値を入力させるように構成されていてもよい。

ブロック２１５では、処理デバイス１３はフィールドを実行するように構成されてもよい。一例では、フィールドを実行することは、図２Ｂに示すプロセスを含む。図２Ｂを参照すると、ブロック２５３では、処理デバイス１３はフィールドに対応するデータ値をデータベースから取得してもよい。一例では、データベースはレビューフォームに入力された情報を保有し、ユーザがレビューフォームのフィールドから離れる／出るときに更新されてもよい。

ブロック２５５では、処理デバイス１３は、そのフィールドについて、例えば解析ＪａｖａＳｃｒｉｐｔ（登録商標）の値を計算するように構成されてもよい。一例では、データ値はデータベースから取得されるものの、ブロック２５５はデータベースからのデータ値を異なる値に置換する前処理を含んでいてもよい。一例では、ブロック２５５は論理文、例えばＪａｖａＳｃｒｉｐｔ（登録商標）を、フィールドに対応して処理することを含んでいてもよく、処理は別のフィールドの値を使用して、数字、式、文、段落、日付および／もしくは時間、選択肢のドロップダウンリスト、計算等のデータ、またはその組み合わせを入力してもよい。一例では、ブロック２５５は、フィールドについての値を、他のフィールドの値をそのフィールドに関連する論理文に供給することで計算して、フィールドで何を示すかを判定することを含んでいてもよい。例えば、論理文の出力は、例えば、他のフィールドの値の合計、他のフィールドの値の積、またはその組み合わせであってもよい。

ダイヤ２５７では、処理デバイス１３はフィールドをラベルのみとして実行するかどうかを判定してもよい。処理デバイス１３がフィールドをラベルのみとして実行するように判定する場合、フィールドは幅全体で、フィールドがテキスト、例えば標準のウェブページテキストであるかのように実行されてもよい。処理デバイス１３がフィールドをラベルのみとして実行しないように判定する場合は、フィールドは幅全体で実行されず、処理デバイス１３は判定２６１、２６３、２６５、２６７、および２６９の１つ以上の判定を行ってもよい。判定２６１、２６３、２６５、２６７、および２６９のどの判定が「はい」を戻すかによって、処理デバイス１３はフィールドのデータをラベル（２６２）として実行してもよく、数値エディタ（２６４）を実行してもよく、日付エディタ（２６６）を実行してもよく、テキストエディタ（２６８）を実行してもよく、またはタイムスパンエディタ（２７０）を実行してもよい。

処理デバイス１３は、実行されたフィールドをリモートデバイス９に送信して、実行されたフィールドに基づくウェブページをブラウザ１０に表示させるように構成されてもよい。ユーザがブラウザ１０を用いてフィールドの１つの変形を作成した場合、ネットワークデバイス１１はその変形に対応するアップロードを受信してもよい。処理デバイス１３はアップロードに対応するデータベースを更新してもよい。データベースの更新に反応して、処理デバイス１３は図２Ａおよび２Ｂの処理を、選択されたテンプレートのフィールド上で選択的に行ってもよい、例えば、処理をいくつかのフィールド（すなわち、変形フィールドおよび依存性リストの１つ以上の深さを用いて得られる任意の依存フィールド）上のみで行ってもよい。処理デバイス１３は、再処理に反応的なフィールドを、リモートデバイス９に送信、例えば押すことで送信するように構成されてもよい。再処理に反応的な送信は、ユーザ画面にフィールドを表示させるか消えるようにさせる、および／または選択的な再実行に基づいて異なるようにフィールドが実行されるようにしてもよい。

図１Ｂは、図１Ａの処理デバイス１３の動作を示すフローチャートを図示する。

ブロック１０１では、処理デバイス１３は複数のテンプレートのうちの１つのテンプレートを選択してもよい。選択は、ユーザ入力に基づいていてもよい。

ブロック１０２では、処理デバイス１３は、選択されたテンプレートの各フィールドを、実行プロセスに通してもよい。一例では、ブロック１０２は選択されたテンプレートのフィールドの１つを取得することと、取得されたフィールドを実行するかどうかを判定することと、取得されたフィールドを実行するように判定したことを受けて、複数の属性から１つの属性を選択して、選択された属性に基づいて取得されたフィールドを実行することと、を含んでいてもよい。一例では、複数の属性は読み取り専用属性、必要フィールド属性、またはバリデータ属性のうちの少なくとも１つを含む。一例では、属性の選択は、複数のレビューステージタイプのうちのどのステージが現在のステージに対応するかに基づいていてもよい。

一例では、ブロック１０２は、選択されたテンプレートの最後のフィールドが取得されているかどうかを判定することと、選択されたテンプレートの最後のフィールドが取得されていないと判定したことを受けて、選択されたテンプレートの次のフィールドを取得することと、取得された次のフィールドを実行するかどうかを判断することと、取得された次のフィールドを実行するように判定したことを受けて、複数の属性から同一または異なる属性を選択して、取得したフィールドをその選択された同一または異なる属性に基づいて実行することと、を含んでいてもよい。

一例では、ブロック１０２は取得されたフィールドに対応する解析コードを含んでいてもよい。一例では、ブロック１０２は、取得されたフィールドのコードを解析した結果に反応して、取得されたフィールドをラベルのみとして実行するかどうかを判定することと、ラベルのみとして実行しないように判定したことに反応して、取得されたフィールドのデータをラベルとして再実行すること、または複数のエディタから１つのエディタを選択して、選択されたエディタに基づいて当該フィールドを裂けさせることと、を含んでもよい。一例では、複数のエディタは、数値エディタ、日付エディタ、テキストエディタ、またはタイムスパンエディタのうちの少なくとも１つを含む。

ブロック１０３では、処理デバイス１３は、選択されたテンプレートの各フィールドを実行プロセスに通した結果として得られる実行されたフィールドを送信してもよい。ブロック１０４では、処理デバイス１３は、実行されたフィールドを送信した後にブラウザからユーザ入力を受信してもよい。

ブロック１０５では、処理デバイス１３は、実行プロセスを再度通すための、選択されたテンプレートのフィールドを選択してもよい。一例では、処理デバイス１３は受信したユーザ入力に対応する（選択されたテンプレートの）フィールドを識別し得る。処理デバイス１３は、選択されたフィールドに対応してコードを解析してもよい。処理デバイス１３は、コードの解析に反応して、選択されたテンプレートの他のフィールドが、識別されたフィールドに依存するかどうかを判定する。選択されたテンプレートの他のフィールドが識別されたフィールドに依存すると判定されたことを受けて、処理デバイス１３は、他のフィールドのそれぞれに対応するコードを解析してもよい。処理デバイス１３は、他のフィールドのそれぞれに対応するコードの解析に反応して、他のフィールドの依存性に基づいてコード解析を行うかどうかを判定してもよい。

ブロック１０６では、処理デバイス１３は選択されたフィールドのそれぞれを実行プロセスに再度通した結果として得られる実行フィールドを送信してもよい。
レビューテンプレート

レビューについて、各顧客が異なるフォーマットを有してもよいため、各レビューはカスタマイズ可能なテンプレートを用いて提示されてもよい。テンプレートは、レビューのためにユーザに提示される全てのフィールドを含んでいてもよい。また、レビューの論理および処理に影響を与える他の設定をも含有していてもよい。顧客はその顧客のレビューに利用可能な２種以上のテンプレートを有していてもよいが、レビューはテンプレートを１つずつしか用いることができない。レビューのテンプレートは、他のフィールドの変更、およびテンプレート内で定義される論理に基づいて、自動的に変えられてもよい。全てのレビューが共有する、期日およびレビューＩＤ等の主要のプロパティセットに加えて、テンプレートは任意の他のレビューテンプレートのいずれにも存在する必要の無いカスタマイズされたフィールドを各レビューについて定義してもよい。レビューテンプレートの中核的な要素は、テンプレートフィールドであってもよい。テンプレートフィールドは、データタイプ、位置、および表示名等の、レビュー上の各フィールドのプロパティを定義してもよい。各テンプレートフィールドは、レビューフィールド変数を用いたＪａｖａＳｃｒｉｐｔ（登録商標）式を介した高度論理を可能とするいくつかの属性を有していてもよい。

テンプレートフィールドの論理に基づく属性は以下を含んでいてもよい：
・ワークフローステージ、ユーザ役割、またはカスタムＪａｖａＳｃｒｉｐｔ（登録商標）式に基づくフィールド可視性。
・ワークフローステージまたはカスタムＪａｖａＳｃｒｉｐｔ（登録商標）式に基づくフィールドに必要とされるバリデーション
・静的な値またはカスタムＪａｖａＳｃｒｉｐｔ（登録商標）式に基づくデフォルトフィールド値。
・静的な値またはカスタムＪａｖａＳｃｒｉｐｔ（登録商標）表現に基づくドロップダウンフィールド項目。
・ＪａｖａＳｃｒｉｐｔ（登録商標）式に基づくワークフローステージ提出後のカスタムフィールドバリデーション。バリデーション規則とバリデーションメッセージの両方は、別々のＪａｖａＳｃｒｉｐｔ（登録商標）式を介して定義可能である。
・適格なレビュアーのための自動フィルタリング規則。
・関連する自動請求規則。

これらの論理に基づく属性に加えて、テンプレートフィールドもまた、計算されたフィールドとして定義することができ、レビューを通して他のフィールドまたは変数が変化する間にその値を計算するために複雑なＪａｖａＳｃｒｉｐｔ（登録商標）式を用いる。これらの計算されたフィールドを用いることで、処理デバイス１３は正確かつ自動的に、モルヒネ当量投与量などの医薬値を、薬剤名および配達ルートならびに薬物治療期間の長さに基づいて、計算することができる。処理デバイス１３は同一分類内のレビュー上の複数の薬剤を識別してもよく、それを受けて警告してもよい。

処理デバイス１３は、具体的な医療サービス（医薬、医療行為など）を認識して、それらの医療サービスに関してユーザに関連する情報を提供してもよい。この情報はテンプレートごとにカスタマイズされてもよい。

テンプレートフィールドもまた、個人健康情報（ＰＨＩ）を含有するものとして示されてもよく、そうすることでフィールドデータがいずれの安全にされていないやり取りまたはウェブページ上でもマスクされる。
カスタマイズ可能レビューワークフロー

各レビューは、具体的なレビューステージ、例えばレビューステージタイプがテンプレートごとで選択され、注文され、実行されることを可能とするワークフローシステムを有していてもよい。ワークフローは多くのテンプレートにわたって共有されてもよく、各テンプレートは、そのテンプレートのフィールド論理に基づいてワークフローを追加で動的に変えてもよい。例えば、レビューのワークフローに次に必要なステージは、例えば「エスカレートレビュー」のようなフィールドの中の値によって、変化してもよい。このことで、レビューが通るステージの決定木の通路を得てもよい。これらのレビューワークフローはポータル管理部（図３Ａに示す）を介して、作成、管理、およびレビューテンプレートに割り当てられてもよい。

レビューのために必要な全体のワークフローをレビューの上部に表示し、現在のステージを強調し、あらゆる前のステージも異なるように、例えば別の色で示してもよい（図３Ｂ）。

ユーザは、このワークフロー図におけるステージのボックスをクリックすることで、どのステージへも飛んでいってもよい。システム１００は、誰がそのステージを完成させる資格があるか（すなわち、顧客、管理スタッフ、レビューコーディネータ、シニアレビューコーディネータ、レビュアー、臨床スタッフ等）を判定する、任意の数の異なるステージタイプを含んでいてもよい。システム１００は、ワークフローにどの種類のステージがあるか、ステージがいくつあるか、どの順番で起きるか、およびどのステージが必要でどれが任意かを定義してもよい。

レビューは、このワークフローに沿って、カスタマイズされた自動論理に基づいて動いてもよい。例えば、レビューが顧客からより多くの情報が必要であるように示されている場合、処理デバイス１３は適切な関係者に自動的にメールが送られるようにしてもよく、所定時間後、例えば３日後にレビュー上で何も変化がなければ、行動のために適切なステージに回されるか、単にワークフローに沿ってさらに進められてもよい。

ワークフローにおける各ステージでは、１つ以上のステージドキュメントを、ユーザ定義可能ステージおよびテンプレート設定によって選択してもよいドキュメントテンプレートを用いて作成してもよい。これらのドキュメントは、顧客、レビュアー、またはスタッフに自動的に送られてもよい。ドキュメントテンプレートは、グラフィックスおよび他の複雑なオブジェクト（例えばエクセルチャート）を含んでいてもよい。

一例では、処理デバイス１４は複数のレビューステージタイプを記憶するように構成されていてもよい。複数のうちの第１のステージタイプは第一者に対応していてもよく、複数のうちの第２のステージタイプは第一者とは異なる第二者に対応していてもよく、複数のうちの第３のステージタイプは第一者および第二者とは異なる第三者に対応していてもよい。第一者は医療レビュー組織のスタッフを含んでいてもよく、第二者は医療レビュー組織の顧客を含んでいてもよく、第三者はスタッフとは独立した専門家からなっていてもよい。複数のレビューステージタイプは、延長可能セットのレビューステージタイプを含んでいてもよく、ワークフロー定義データはユーザ入力の受信時に対応する延長セットバージョンに基づいていてもよい。

処理デバイス１３は、カスタムワークフローのためのユーザ入力の受信に反応してワークフロー定義を形成してもよく、ワークフロー定義データは複数のうちの選択されたステージタイプおよび複数のうちの選択されたステージタイプに基づく処理を実行するための選択された順番を識別する。

処理デバイス１３は、ワークフロー定義データを選択されたテンプレートと関連付け、選択されたテンプレートのフィールドを取得し、取得されたフィールドをステージごとで実行するかどうかを判定してもよい。

後でより具体的に記載するとおり、複数のうちの少なくとも１つのステージは第三者の個人を少なくとも１人選択するためのディスパッチステージを含んでいてもよく、ディスパッチステージは、第二者によって設定されたパラメータに基づいて一式の医療専門家からサブセットを選択するためにフィルタリングすることを含む。ディスパッチステージは、フィルタリングの結果として得られたサブセットを、第一者によって設定されたパラメータに基づいて複数のグループに分けるためのグループ分けをすることを含んでいてもよい。ディスパッチステージは、レビュー割当について複数のうちの第１のグループのメンバーに第１回目に通知することと、複数のうちの第１のグループとは異なる第２のグループのメンバーに第１回目とは異なる第２回目に通知することを含む、スケジューリングを含んでいてもよい。第２回目は、固定の日時と、第１のグループのメンバー全てがレビュー割当を明示的に拒否した日時とのうちの、より早い方であってもよい。
レビューディスパッチ

レビューディスパッチは、レビュアーがレビューを、主要レビュアーとしてまたは連署レビュアーとして、割り当てられる処理を言う。レビュアーがレビューに割り当てられると、彼または彼女は自動的に通知されて、レビューを引き受けるか拒否することができるが、その判断を延期してもよい。

レビューのディスパッチ中に、処理デバイス１３は、顧客ごとおよびレビューテンプレートごとに構成可能ないくつかの基準によって対応可能なレビュアーをフィルタリングしてもよい。一例では、基準は、顧客に対応する限定的な地理的位置、例えば顧客と同一州における、例えば医師のみの独立レビューのみを含むようにする論理文であってもよい。論理文はその顧客用のテンプレートに関連付けられてもよい。

これらの基準を用いて、可能性のあるレビュアーのグループは自動的に割り当てられるか、エンドユーザによって選択されてもよい。レビュアーが自動的にフィルタリングされるさまざまな基準は、個別のレビューならびにそのレビューの顧客およびテンプレートによって判定されてもよい。カスタマイズ可能フィルターおよび選択基準のセットは、以下を含むがこれらに限られない：
・レビューデータによって判定された州のライセンス要件。
・類似の専門グループを含むレビュアー専門性マッチング。例えば、レビューが内分泌学を必要とする場合、顧客およびテンプレートのセットアップによっては、内科もまたその要件を満たす可能性がある。
・例えば、開業医のみの選択を可能とするような、１週当たりの臨床時間。
・品質スコアリング（レビュアーはレビューを再調査した後に品質スコアが割り当てられる）。この平均品質スコアは、低品質のレビュアーを排除するまたは高品質のレビュアーに優先度を与えるために、ディスパッチ中に対応可能なレビュアーのリストをフィルタリングする上で用いることができる。
・スキルセットまたは特定の証明に基づくカスタマイズ可能なサブネットワーク（全員がＦＡＡ認定されたレビュアーのグループ分け等）。
・レビュー処理能力（レビュアーは月ごとに行うことができるレビューの最小および最大数があり、これをレビュアーの割当の際に用いることができる）。例えば、その月でのレビュー最大数を超えるレビュアーは対応可能なレビュアーのリストから除外することができ、同様に、最小数に満たないレビュアーは他のレビュアーよりも優先度を与えることができる。
・曜日に基づく空き状況および特定のレビュアーのスケジュール。

また、ディスパッチ中に、ユーザは、連絡先情報、スケジュール、空き状況、副専門分野、平均品質、およびあらゆるレビュアーメモを含むレビュアープロフィールを参照することができる。
ディスパッチスケジューリング

ディスパッチスケジューリングは、レビュアーグループに基づいて遅延したレビュアー割当を可能とし得る。レビュアーはレビューに割り当てられると、割当が有効になるべき日／時を有する限定されない数のレビュアーグループの１つに入れられてもよい。

図４に例示的なグループ割当を示す。図４のグループ割当を受けて、グループ１にいるレビュアーは全員、レビューを割り当てられたという通知を直ちに受け取ってもよい。２０１３年３月１６日の午後４時までにグループ１のレビュアーのいずれもが引き受けなければ、グループ２に並べられるレビュアー全員に通知が送り出されてもよい。次に、２０１３年３月１６日の午後８時までにグループ１またはグループ２のいずれのレビュアーもがレビューを引き受けなければ、グループ３内のレビュアー全員に通知が送り出されてもよい。

さらに、２０１３年３月１６日の午後４時前にグループ１のレビュアー全員がレビュー割当を認識したもののシステム内でレビューを明示的に拒否した場合は、システムが午後４時まで待つ理由が無いために直ちにグループ２に通知が送り出されてもよい。グループ１およびグループ２内のレビュアーの誰もがレビューを拒否した場合、同様のタイミングがグループ３にも適用される。

グループ間での遅延はテンプレートごとに自動的に定義されてもよく、案件ごとで変更されてもよい。グループの使用は、特に案件についての限定／基本情報表示モードとの組み合わせにおいて、独立したレビュアーによる利益相反のチェックを容易にし得る。例えば、グループ１のレビュアーは、彼／彼女が、先入観の無い再検討の提供を防止する、元の医療個人と付き合いがあるかどうかを判定するために、案件の限定／基本情報を参照し得る。限定／基本情報を参照することは、一例では、前に説明した実行プロセスにしたがって１つ以上のフィールドを「不可視」にすることで、行われてもよい。グループ１のレビュアーは、限定／基本情報を参照するのみに基づいて案件割当てを明示的に拒否してもよく、この場合はグループ２に通知されてもよいが、明示的な拒否が無い場合でも、グループ２はそれでも所定の時間で対応可能な案件割当てについて通知されてもよい。

一例では、スクーピングを用いてもよい。レビュアーがレビューに割り当てられたとき、彼／彼女はそのレビューを引き受けるか拒否するためにシステムにログインしてもよい。彼／彼女はまた、後ほどまで判断を延期してもよい。１人のレビュアーがレビューを引き受けると、彼／彼女は記録上のレビュアーとなり得て、他の全てのレビュアー割当は期限切れとなる。しかしながら、１人のレビュアーがレビューを引き受けると、まだレビュアー割当に応答していない他の全ての割り当てられたレビュアーは、そのレビューに対する状態は「スクープド」として見て、レビューに応答するのが遅すぎてそれ以上引き受ける（または拒否する）機会を有さないように示されてもよい。これは、レビュアーに、できるだけ早くレビュー割当通知に応答させるためのフィードバックおよび動機を与えることができる。このプロセスはまた、各レビューについてのレビュアーの費用の入札に基づくレビュアーの優先度付けを可能とする。
自動警告

論理およびフィルタリングに基づいて行為を行う自動化システム。警告のためのトリガは、ＳＱＬクエリまたはＪａｖａＳｃｒｉｐｔ（登録商標）式もしくはその両方の組み合わせを、レビュー上の任意の露出フィールドを用いることで定義されてもよい。警告システムはユーザによって構成可能な間隔（例えば、１分）で投票を得ることができ、その条件を満たすいずれのレビューでも適切な行為を行ってもよい。行うことができる行為は以下のようなものであってもよい：
・レビューにコメントをつけ、注目される必要があるものとしてフラグ付けする
・レビューについての再調査履歴入力を加える
・レビューフィールドに値を設定する
・レビューのワークフローステージを変更する
・レビューのテンプレートを変更する
・適切なレビュー情報および添付物を有する電子メールテンプレートを介して、電子メールを送信する
・適切なレビュー情報を有するファックステンプレートを介して、ファックスを送信する
・適切なレビュー情報を有するＳＭＳテンプレートを介して、ＳＭＳを送信する
・自動で電話を掛ける
・適切なレビュー情報を有するドキュメントテンプレートを用いてドキュメントを生成する
同時レビュープロセス

システム１００は、レビュー完成速度および効率性を改善させるために、認定レビューを代替的なプロセスを介して処理することを可能とする同時レビュープロセスを含んでいてもよい。システム１００は、同時レビュープロセス（ＣＲＰ）を介して処理される、顧客、テンプレート、または特定のレビューを定義してもよい。フラグ付けされると、レビューは自動的にＣＲＰキューに入れられて、それによってシステム１００がこれらのレビューをＣＲＰ認定レビュアーのキューに直ちに入れられる。ＣＲＰ認定レビュアーがポータルにログインすると、選択可能なレビューの標準リストに加えて、１つ以上のＣＲＰ案件があることを示すボタンを見つけることができる。ＣＲＰキュー自体の可視性はなく、ボタンだけが見える。一度ボタンをクリックすると、ＣＲＰキューにある次の案件が自動的に割り当てられてもよい。レビュアーは、現在のレビューが完成するまで他のどのレビューをも引き受けることができない。レビュアーはその作業を保存して後ほど完成させるために戻ってくることはできず、レビューを１セッションで完成させなければならず、さもなければそのレビューはＣＲＰキューに戻される。レビューは、一度レビュアーによって処理されると、次に最終品質確認が行われて、完成される。よって、ＣＲＰシステムは、完成速度およびレビュアーの処理効率の両方を、単純構造のレビューを識別してその完成に不必要なステップを飛ばして進むことで著しく改善することができる。
レビューフィールド即時保存

各フィールドがレビュー上で変更されるため、これはデータベースに即時保存されてもよい。これによってデータの損失を防ぎ得て、レビューを見るすべてのユーザが最新情報を得られるようにすることを可能とする。フィールドが変更されると、ＪａｖａＳｃｒｉｐｔ（登録商標）式で保存フィールドを参照する他のいずれのテンプレートフィールドもが評価され得る。依存フィールドとして知られるあらゆるかかるフィールドは、ＨＴＭＬとして実行されてウェブページに送り戻されてもよい。このＨＴＭＬは実際の可視フィールドまたは単に不可視フィールドのためのプレースホルダーであってもよい。これによって、フィールドは、レビューウェブページ全体を再読込する必要なく、表示する／隠すまたはフィールド変更に基づいてリアルタイムで単に更新することができ、結果としてより速くデータ入力することができる。

さらに、フィールド変更がデータベースに関係付けられる前に、システム１００は最初にその値がデータベース内で別のユーザによって既に変更されているかを確認してもよい。値がデータベース内で変更されていれば、ユーザに対して、ユーザ変更値を保存するか変更されたデータベース値に戻すかを尋ねるポップアップを示してもよい。いずれのレビューにおいても、レビューが別のユーザによって変更されているため、レビュー上の全てのフィールドの最新情報を得るためにレビュー全体を再読込してもよい。ユーザがレビューを見ている間、システムは間隔閾値、例えば毎分で、同じレビューを参照している他のユーザを確認し、見つかるようであれば、同時に同じレビューを見ている他の全てのユーザと共に警告を表示してもよい。この確認は、レビューを最初に立ち上げるときにも、顧客、レビュアー、またはスタッフメンバーであれ、同じレビューに対して他に誰が作業しているのかをユーザが明確に見ることができるように引き起こされてもよい。このシステムは、各フィールドが直ちに更新されて保存されるため、複数のユーザが同時に１つのレビューの作業をすることを可能とする。

一例におけるフィールド即時保存のライフサイクル全体は、図５に示される「レビューフィールド保存概要」と名付けられたフローチャートに示されている。
レビュー検査

各レビューは、任意のユーザまたは自動化システムによって行われる行為全ての完全な検査を受けてもよい。検査は以下を含んでいてもよい：
・フィールド履歴
ｏレビュー上の各フィールドは、任意のユーザまたはシステムによってそのレビューに行われた全てのデータ変更の完全なフィールド履歴を有する。この履歴は、各フィールドの隣にあるフィールド履歴アイコンをクリックすることで可視化される。そのフィールドの現在値を入れ替えるために、任意のログ入力を用いることができる。
ｏユーザは、フィールドにおいて前に保存された値に戻るため、または現在のフィールドコンテンツと以前のコンテンツとの差分分析を見るためにも、この機能を用いてもよい。
・レビュー履歴
ｏレビューに行われた全ての行為またはデータ変更は検査に記録され、以下を含むがこれらに限られない：
■ファイル添付
■レビュアー割当
■ドキュメント生成
■電子メール送信
■ワークフローステージ変更
■フィールドデータ変更
ｏレビュー履歴は、ユーザ役割（レビュアー、顧客、スタッフ等）、行為タイプ、およびユーザによってフィルタリング可能である。
・ドキュメントアーカイブ
ｏレビューについての履歴の追加レベルを提供するために、各ワークフローステージ変更でドキュメントファイルが生成される。これらのドキュメントは、各レビューのための異なるフォーマットおよび情報を提供するためにテンプレートとして構成可能でもある。
・レビュー所有
ｏレビューの各ワークフローステージにて、ユーザはそのステージの所有者として自動的に記録されて、その所有権が与えられた日時と共にレビュー上に表示される。
・レビュー使用
ｏレビューの各ワークフローステージで費やされたユーザ時間（参照または編集）は記録されて報告される。
書類読取方法

レビューは顧客からの書類を必要とし得て、ポータルはレビューに、ファックス（顧客はドキュメントページをファックスすることができて、それがレビューに添付される）、電子メール、（顧客はドキュメントを電子メールで送ることができ、それをレビューに添付する）、ウェブアップロード（顧客はウェブサイトを介して直接レビューにファイルをアップロードすることができる）、およびＳＦＴＰ（顧客はＳＦＴＰを介してファイルをアップロードして、それがレビューに添付される）等の、書類を添付するいくつかの方法を顧客に提供する。
自動証明書発行

システム１００はプロバイダ証明書を追跡および管理してもよい。この管理は以下を含んでいてもよい：
・データベースは全ての証明要素および有効期限日ならびに再確認日程を追跡する
・接近する有効期限日に基づく自動警告
・専門的な質問の自動再発行
・州免許の自動認証
レビュアー管理

レビュアーはシステム内で直接管理されてもよい。レビュアー管理のための要点は以下を含み得る：
・レビュアー用の品質スコアリング
ｏレビューを完成させた後に、レビュアーにはいくつかの要因に基づいて品質スコアが割り当てられる。レビュアーの平均品質スコアは、高品質および低品質レビュアーを認識するために、システム全体にわたって使用されて表示される。
ｏシステムが平均品質を評価するため、保持、再トレーニング通知、試用状態、レビュアー優先度状態変更、ネットワークからの除外および任意の数のその他の通知または変更の自動化トリガが存在する。
・カスタマイズ可能な規則に基づくレビュアーのためのカラーコーディング
ｏレビュー（ディスパッチ）のために選択される一方で、レビュアーはその品質、空き状況、レビュー処理能力、レビューイントレーニング、および帯域幅についてさまざまなインジケータを有する。これらのインジケータは、ディスパッチ判定を容易にするために、任意のリスト内のレビュアーに示すときにさまざまなカラーフォントおよびアイコンインジケータの形態を取る。
・以下の測定基準についての、自動測定、通知、および性能基準との比較
ｏ定刻送達
ｏ電話連絡成功度
ｏ品質
ｏレビュアーに関するサポートチケット
ｏレビュアーによって作成されたサポートチケット
・レビュアーは、彼らの請求情報をリアルタイムで、請求書発行前および後に見ることができる。この情報には以下を含む：
ｏ今月計上された時間数
ｏ先月計上された時間数
ｏ今月完成されたレビュー
ｏ先月完成されたレビュー
ｏ全時間で完成されたレビュー
ポータルショートカット

処理の速度を速めるために、ユーザが頻繁に使用されるテキストのプライベートライブラリを使用することを可能とする。このショートカットライブラリは、ユーザに可視の任意のフリーフォームテキストフィールドについて使用可能であり、ユーザは編集されるフィールドに直接アクセスすることができる。このショートカットテキストはフィールド値に付加されてもよい。レビュアーは、彼または彼女のライブラリを、フィールドを編集しながら直接管理してもよい。

ショートカット入力は全てのフィールドについて包括的であってもよく、または特定の部またはレビューフィールドに結び付けられてもよい。

レビュアーのショートカットのプライベートライブラリに加えて、包括的または特定のテンプレートに割り当てられた一般的に用いられるテキストを有するパブリックショートカットライブラリが存在してもよい。このパブリックライブラリはスタッフによって管理されてもよく、システム全体にわたるさまざまなＪａｖａＳｃｒｉｐｔ（登録商標）式有効フィールドと同様にレビューフィールド変数を用いてもよい。これは、レビュアーが使用した時に、テキストショートカットに、レビュー上の１つ以上の個別のフィールドの値を用いるようにさせることを可能としてもよい。例えば、レビュアーが理論的根拠を書いているときに、彼は「処方される｛ｍｅｄｉｃａｔｉｏｎ＿ｆｉｅｌｄ｝の量に基づいて否認することを推奨する。｛ｍｅｄｉｃａｔｉｏｎ＿ｆｉｅｌｄ＿ｄｏｓａｇｅ｝はかかる場合についての通常の上限を超えている。」と読むパブリックショートカットを選択してもよい。現在のフィールドに付加するときは、太字の値はその中で参照されるフィールドにおける値と入れ替えてもよい（例えば、「Ｌａｎｔｕｓ」および「６０単位」）。

レビュアーは、テキストを編集するために、任意のパブリックショートカット（レビューフィールド変数を含む）を自身のプライベートライブラリにコピーしてもよい。

システム１００は全てのショートカットライブラリにアクセスを有していてもよく、傾向を識別するため、およびその内部品質改善動機の一部として、全てのショートカット入力に報告アクセスを有する。
スタッフ管理

スタッフはシステム内で直接管理されてもよい。スタッフ管理の主要領域は以下を含み得る：
・スタッフの品質スコアリング
ｏ医療内容審査（Ｐｅｅｒ Ｒｅｖｉｅｗ）等のレビューステージを完了した後、スタッフメンバーはいくつかの要因に基づいて品質スコアが与えられる。スタッフメンバーの平均品質スコアは、高品質および低品質のスタッフを識別するために、システム全体にわたって使用されて表示される。
ｏシステムが平均品質を評価するため、再トレーニング通知、試用状態、および任意数の他の通知または変更の自動トリガが存在する。
・ローテーション管理
ｏローテーションは、ディスパッチ等のスタッフの責任の範囲を定義する。これは、処理能力を最大化するために、異なるグループのスタッフがシステム内で異なる責任を割り当てられることを可能にする。これらのローテーション、およびそれらに割り当てられるユーザは、ユーザが適切なセキュリティ特権を有するという条件の下で、管理部を介して管理可能である。この様態で、任意の数のローテーションを作成して管理することができる。ローテーションはまた、ユーザダッシュボード上のスタッフローテーションウィジェットを介して管理可能である。
・チーム管理
ｏスタッフのグループをチームとして一緒にグループ分けすることができる。各チームはシステム内で定義された１つ以上のチームリードを有することができる。チームは論理的にスタッフをグループ分けする方法を提供する。
・ユーザのダッシュボードページに挿入、再配置、削除可能なリアルタイムのデータウェジェットを有する部門特有ダッシュボード。ユーザの要求およびウィジェットが含む任意の数のウィジェットを作成することができ、ウィジェットアクセスはセキュリティ特権を介して制御される。ウィジェットは以下を含む：
ｏコミッション
■ウィジェット：異常コミッション率（潜在的な問題データ）
■ウィジェット：営業担当者コミッション、直近１２ヶ月（経時的にチャート化）
■ウィジェット：営業タイプ別コミッション、直近１２ヶ月（経時的にチャート化）
■ウィジェット：コミッションなしの顧客（潜在的な問題データ）
ｏ動作
■ウィジェット：動作静的概要、ステージおよび時間、ならびに最小および最大閾値に基づくカラーコーディングによる概要システム測定基準
・各ステージでのレビュー
・各ステージにおいてフラグ付けされたレビュー（フラグ付けされているのは、顧客またはレビュアー変更に基づいて注目される必要のあるレビュー）
・顧客に対して現在期限が超過しているレビュー
・本日受信のレビュー
・本日が顧客への期限であるレビュー
・次営業日が顧客への期限であるレビュー
・レビュアーから期限切れのレビュー
・今月受信のレビュー
・本日完成のレビュー
■ウィジェット：動作スタッフ統計、以下の測定基準を含むためのフィルタリング可能なスタッフのリスト
・各スタッフステージから提出されたレビュー
・生産性スコア
ｏ生産性とは、ステージの難易度（いくつかのステージは他のものに比べて完成させるのに少ない時間で済む）に関係なく、レビュー処理能力を比較するために用いられる加重スコア
・ステージごとの平均品質スコア
・ユーザについての現在の生産性スコア目標およびその目標の完成パーセント
■ウィジェット：ローテーション状態
・スタッフのローテーション割当を表示し管理する。
・ユーザがシステムにログインしているか否かを示す
・十分な数のスタッフが割り当てられていない、または各ローテーションについてのユーザ定義可能要件に基づいて十分な数のスタッフがシステムに現在ログインしていないかのいずれかによって、ローテーションのスタッフが足りないかどうかを示すカラーコード化アイコン
■ウィジェット：チーム状態
・スタッフメンバー、それらのチーム、ローテーション、およびログインしているか否かのリスト
・ユーザ定義スケジュールの選択可能なリストとして、またはワンタイム編集スケジュールとして、スタッフスケジュールの割り当てを可能とする。誰がその日の特定の時間まで作業するようにスケジューリングされているかをフィルタリングして見ることができる。
ｏ営業
■ウィジェット：本日の新しいレビュー、顧客および本日提出されたレビューの概要
■ウィジェット：上位パフォーマー、本日の完成収入、または本四半期の完成レビュー等のさまざまな構成可能な計測基準によるトップ営業担当者のリスト
■ウィジェット：完全レビュー追跡、同期間の目標および達成した目標割合を含む収入および経時的なレビュー数の概要
・本日
・今月
・本四半期
・今週
・本年
■ウィジェット：注視する顧客、収入および経時的なレビュー数を追跡する顧客のユーザ選択可能なリスト
■ウィジェット：顧客請求書発行履歴、選択可能顧客についての選択可能な期間にわたる請求測定基準
・合計レビュー数
・合計収入
・合計利益
・レビューごとの平均収入
・レビューごとの平均利益
■ウィジェット：新顧客、新顧客リストおよび選択可能な期間に基づく測定基準
■ウィジェット：上位１０顧客、収入または選択可能な期間にわたるレビュー数に基づく上位顧客
ｏ請求
■ウィジェット：有効レビュー、今月および先月（チャート）
・＃レビュー
・＃請求書付きレビュー
・再び開かれたレビュー
■ウィジェット：有効顧客、今月および先月（チャート）
・＃顧客
・＃数量割引を行う顧客
・＃再提出を要する顧客
■ウィジェット：請求期間ごとの経費（請求月）
■ウィジェット：以前に請求書発行した再び開かれたレビュー（請求スタッフからの特別な注意を要する）
■ウィジェット：キャンセルされたレビュー（キャンセルされたレビューのリスト）
■ウィジェット：数量割引警告（数量割引によって潜在的に問題を有する費用の通知）
・以下のカスタマイズ可能規則に基づくレビューのカラーインジケータによるスタッフ生産性の向上：
ｏ本日期限のレビュー
ｏ明日期限のレビュー
ｏ期限超過のレビュー
・スタッフ生産性スコアリングおよび現在のローテーションを用いた、スタッフィングおよび生産性に基づく生産予測ツール
ｏ各スタッフローテーションは、そのローテーション内にいるときに１つのレビューを完成させる難易度についての重率因子を有する。このローテーション重率因子と共にスタッフメンバーの平均生産性スコアを用いることで、システムは各スタッフメンバーが一日で完成できるだろうレビュー数を計算することができる。個別の処理能力を用いて、ローテーション割当に基づいてシステム全体の合計処理能力を計算することができる。
・レビューキューが特定の閾値に到達したときに、スタッフィングおよび責任を変更するための自動ポータルベース「緊急プラン」。全てのスタッフが、システムレベルでの告知ポップアップおよびティッカーを介して、それらのプランが有効になったときに通知される。
・セキュリティベース特権
・各スタッフメンバーは、システム機能（顧客情報を編集する、または報告書の名前をつけ直す等）へのアクセスを与えるか拒否をするユーザ特権の蓄積を有する。
顧客管理

顧客はシステム内で直接管理されてもよい。顧客管理の主要領域は以下を含み得る：
・顧客内でマルチレベルでのサブ分類を作成する能力
・レビュアーが引き受けるか拒否するために最初にレビューを開いたときに示されるカスタムレビュアー証明文（典型的には利益相反の欠如に関する）を定義する能力
・医療レビューを後ほど完成させるために、部分的に完成された要求を保存するための下書きステージ。下書きは、顧客が処理用に提出する前にレビューに対して作業することを可能とする特別なワークフローステージである。
・マルチステージ提出（顧客の異なる個人がウェブフォームの異なる部分を完成させる）を有するための能力。
・レビューリストに加えて、顧客リストにも特定の顧客タイプを自動化したインジケータと共に指定する：
ｏ新しい顧客は自動的に新顧客レビュー（ＮＣＲ）に指定されて、適切にフラグ付けされる
ｏＮＣＲ状態は自動的に、その顧客によって提出されたレビューの数を数える。
・異なる顧客ユーザについてのカスタムアクセスレベル（役割）を定義する能力
ｏ参照
ｏ管理者
ｏ監督者
ｏユーザ
・レビューの提出後に処理される間に、顧客がレビューを更新する能力。レビューにコメントを加えることができ、そのレビューに関連するサポートチケットを生成することができる。
・閉じられたレビューを、さらなる処理のために再度開けることを可能とする能力。これは、他の要因のうち、レビューが前に請求処理されているかによって異なる請求論理をトリガする。
・顧客セルフ管理能力。顧客ユーザは、アクセスレベルによって、自身を管理する以下を含む能力を有する：
ｏ自身のユーザプロフィールを更新する（タイムゾーン、地域設定、好み）
ｏユーザ名およびパスワードを変更する（長さおよびどれくらいの頻度でパスワードを繰り返すことができるか等、顧客が構成可能なパスワード規則の施行を含む）
ｏ顧客についての、役割変更を含むユーザの追加／削除／編集

カスタマイズ可能な自動無活動ログアウトは、ＨＩＰＡＡ等の異なる州および国のセキュリティ要件に基づいていてもよい。いくつかの顧客では、それらのユーザが第１の期間後、例えば１５分の無活動の後にログアウトすることを必要とする一方で、他は、デフォルトの無活動タイムアウトであってもよい別の期間、例えば３０分を用いてもよい。活動は、任意のシステムウェブページ上での任意のマウス動作またはキーボード入力として定義されてもよい（全ての開かれたタブはそれらの活動を同期させる）。無活動の期間後に、ユーザには閾値時間、例えば１分でログアウトされることを説明するカウントダウンタイマーを提示して、ユーザはそのままサインイン状態でいることを要求するためにボタンをクリックしなければならず、そうしなければ理由についてのメッセージを残してログアウトされる。
レビュアーは自動請求の時間を超過してはならない

システム１００は自動的に、レビュアー（または連署者）がレビューを行うのに合計でどれだけの時間が掛かるべきかを、以下の複数の要因を考慮した計算に基づいて判定してもよい：
・レビューするドキュメントのページ数
・レビューのために回答する質問数
・レビューの種類
・レビューの複雑さ
・レビュータイプ
・顧客
・もとのプロバイダと追加の電話または通信が必要かどうか
・顧客カスタマイズ調節

計算は顧客ごとおよびテンプレートごとにカスタマイズ可能である。これらの基準のそれぞれの式量値は、可能な最大のレビュアー時間の最も正確な計算のためにルーチン的に測定されて調節されてもよい。レビュアーがＮＴＥ時間よりも大きい合計レビュー時間を入力しようとした場合、レビュアーに彼または彼女の時間を適宜調節するように指示するバリデーションメッセージが表示されてもよい。このＮＴＥ時間は全てのレビュアーおよび連署者に適用されてもよく、各レビュアー役割のために別々に計算される値がある。
自動請求

顧客との包括的なレート交渉をもたらす自動請求システム。これらの交渉の結果として、システム１００では個人または複数の顧客に適用されるレート構造が定義され、続いてレビューの請求書を自動的に生成するために用いられてもよい。

システム１００は、以下の、顧客またはテンプレートによる構成可能な機能を可能としてもよい：
・レビューの大きさおよび完成の推定時間によって定義されるレビューの複雑さに基づいて、レビューに異なるレートを割り当てる能力。
・２つのレベルでレビューのカテゴリを定義する能力。レビューが割り当てられるカテゴリまたは複数のカテゴリによって、異なる請求レート構造に関連する。
・月次請求書について処理されたレビューの数、月次請求書の合計請求金額、および／または遅延基準に基づいて、割引を適用する能力。
・請求構造についての定額料金および１時間当たり料金の両方を定義して活用する能力。１時間当たりおよび定額料金の両方が、その複雑さによってレビューに用いられる可能性があるときは、料金は、レビューが複雑であれば複雑であるほど、確実に料金が大きくなるように常に生成される。より単純なレビューについて単体での１時間当たり料金の計算が定額料金よりも少ない金額を生成する場合、料金はその請求構造において適切なところを反映するように自動的に増加される。
・２つ以上の顧客に、フルレート構造を割り当てる能力。
・レビューを特定の請求グループカテゴリに割り当てるために複雑な条件文を（ＪａｖａＳｃｒｉｐｔ（登録商標）式およびレビューフィールド変数を用いて）書く、または具体的に交渉された割引基準を生成する能力。
・顧客ごとのＨＩＰＡＡ準拠変更
・月次対レビューごとの請求書発行
・請求書テンプレートを用いた請求書フォーマットのカスタマイズ

自動請求は毎月自動的に実行される受託システムを含んでいてもよく、外部の会計システムから請求書および支払情報を集めて、顧客ごとに情報を要約して、それらの顧客の全ての該当する営業担当者に支払われるべきコミッションを計算する。

新しい顧客については粗利益に基づいてパーセントベースで営業担当者にコミッションを支払う一方で、古い、確立された顧客（少なくとも２年以上）については粗利益ではなく企業成長に基づいてコミッションが支払われ得る、特別な計算システムを用いてもよい。これらのより古い顧客については、顧客の直近の企業記念日までの３ヶ月の平均粗利益を求めることによって「基線利益」を計算してもよい。月ごとでこれらの基線利益を超えるあらゆる利益はコミッション可能として考慮され得るため、単純な維持に対して企業成長の重要性を強調する。

このシステム１００は過去を参照してコミッションを生成してもよい。顧客の支払いが到着すると、システム１００はこの支払いがどの請求書と関連するかを識別し、請求書発行時にどの営業担当者が割り当てられていたかを見つけ出し、該当するようであれば、請求書のときに基づいて超過すべき基線利益を計算して、それによってコミッションを計算してもよい。よって、どのように経時的に営業担当の割当が変化したり、古い請求書に対してどれだけ支払いが遅れたりしたとしても、システム１００は正しい営業担当についてのコミッションを、過去からの正確性を有して正しい金額で計算され得る。

コミッションシステムは、全ての適切なコミッションレートおよび割当てが定義される別のコミッション部を介して管理されてもよい。

自動請求システムはまた、２つのシステム間での支払いおよび請求書発行を同期させるための、外部の会計ソフトウェアとの二方向統合を有していてもよい。
完成レビューの再開封

レビュー処理は、顧客、スタッフ、およびレビュアーの関与を体系づけ、顧客に具体的および予測可能な結果を提供し、料金の請求書を送付し、レビュアーに支払う、厳格な最初から最後までの方法論に従ってもよい。しかしながら、新しく取得されたデータまたは要件に基づいて、レビューの完成後に再開封しなければならない時がある。これらの状況に対処するためには、レビュー再開封機能は、顧客請求書およびレビュアーへの支払いの高決議履歴を維持しながら、完成されて再開封されながらレビューで行われた作業の累積概要を保つ。

システムは、顧客およびスタッフの両方に完成されたレビューを再開封することを可能とし、そうするための理論的根拠についての情報を提供し、必要となった新たな作業のためのパラメータを提供してもよい。システムは次にレビューを再開封し、処理のために適切な関係者に送付して、再開封された時にレビューの履歴を記憶してもよい。システムは、所定のレビューについて必要に応じた数の完成および再開封に対処する能力を有し得る。

顧客請求書発行および貢献者への支払いは、累積的な様態で対応されてもよい。レビュー自体が、行われた作業全般および全ての完成ならびに再開封にわたって費やされた時間を表してもよい。しかしながら、個別の請求書情報を完成するたびに顧客に提供して、顧客がどのような作業が行われてそれぞれの完成についていくらのお金が請求されるのかを知ることができるようにしてもよい。同様に、レビュアーは完成ごとに支払われてもよく、同一のレビューに対して異なるレビュアーが異なる完成について関与していてもよい。図６Ａ〜６Ｈは完成されたレビューを再開封する一例を図示する。
コアネットワーク請求

コアネットワーク請求は、レビュアーに確か且つ正確な作業量が提供されることを確実にするためのものである。このシステム１００は、各レビュアーについて、週ごとの時間数で定義される定義可能な作業量値を用いてもよい。所定の月では、レビュアーが作業するたびに、そのレビュアーの優先度が計算されてレビュアーに割り当てられてもよい。この優先度は、レビュアーが彼または彼女の作業量目標から遠く離れている場合は高くあってもよく、レビュアーがそこに近づくにつれて優先度は下げられてもよい。これらの優先度はレビュアー割当処理（ディスパッチ）の一部として用いられてもよい。レビューがレビュアーに割り当てられるように用意できたときに、最も高い優先度を有するレビュアーにそのレビューを受ける最初の機会が与えられてもよい。よって、この自動化されたシステムは、レビュアーが快適に自身の作業量目標に到達できる可能性を著しく引き上げる可能性がある。

レビュアーが自身の作業量値を超過すると、その優先度は落ちて、自身の報酬は自動的に割り引かれることで、レビュアーに自身の作業量予測を正確に保ち、いまだ作業量分担分に到達できていないレビュアーに行くべき作業を受けないように奨励し得る。
顧客システムと統合するための双方向ＡＰＩ
受信（ＩＮＣＯＭＩＮＧ）

レビューＡＰＩは、顧客に、安全なアプリケーションプログラミングインターフェース（ＡＰＩ）を介して、レビューを提出させる、および既存のレビューに変更を加えさせることを可能としてもよい。ＡＰＩはレビュー特定の情報を顧客から受け取り、ポータルシステム内で新しいレビューを生成してもよい。レビューの範囲に基づいて、ＡＰＩは自動的にレビューを特定のレビューテンプレートに割り当てて、顧客に自動的に多種多様の異なるレビュータイプを提出できるようにしてもよい。キャンセル要求もまたＡＰＩを介して受信されてもよく、レビューがキャンセル可能な状態にある場合は、レビューはキャンセルされてもよく、適切な関係者に通知が送られてもよい。ＡＰＩを介して行われた全ての変更は記録されてもよく、レビューおよびフィールド履歴に現れてもよい。
送信（ＯＵＴＧＯＩＮＧ）

自動化されたワークフローの一部としてフラグ付けされたレビューが完成すると、システム１００はレビューをＡＰＩキューモニタに送信してもよい。ＡＰＩキューモニタサービスは、新しく加えられたエントリーおよび各エントリーについてキューを監視してもよく、必要なレビューデータを顧客のＡＰＩに自動的に送信し返してもよい。
複製レビュー

複製は、テンプレート定義によって、いずれのレビューから作成されてもよい。

顧客は、その業務の性質に起因して、構造が非常に類似し、複製されたレビューに同一情報を必要とするレビューを（例えば、いくつかの独立したレビュアーによって処理されるために）提出してもよい。「複製レビュー」機能は、スタッフにレビューを選択させて、同一情報を共有する新しいものを生成させることを可能にしてもよい。

複製レビューの機能を発動させた後に、現在選択されているレビューのフィールド（例えば、レビューのために必要且つ使用される情報）をリストアップするインターフェースが表示されてもよく、ユーザにその多くのフィールドから新しいレビューに複製するものを選択させるまたは選択させないようにしてもよい。（なお、いくつかのフィールドは、複製される必要がある、または複製が引き出されるレビューの種類に基づいて無関係であるために、選択可能でない。）一度フィールドが選択されると、ユーザは次に、ボタンをクリックすることで、元のレビューに基づくフィールド値を自動的に含み得る新しいレビューを生成し得る。要するに、この機能は、新たなレビューを、各レビューの最初からの入力を求めるのではなく既存のレビューに基づいて生成させることを可能とすることで、時間を節約して効率性を改善させ得る。

各テンプレートフィールドの定義では、レビューを複製するときに、そのフィールド値を複製可能とし得る「複製可能」特性がある。フィールドは、デフォルトで常に複製されるようにしてもよく、または単にレビューを複製するときにユーザによって選択可能であるようにしてもよい。

一例では、レビューは、顧客によって提出された案件（またはレビュー）に医師またはその他の医療専門家がレビューを行うことを含んでもよい。一例では、レビューは顧客によって提出された医療案件を含んでいてもよい。一例では、ディスパッチは、潜在的なレビュアーにレビューに取り組むように割り当てる処理を含んでもよい。一例では、テンプレートは、潜在的なレビュアーにレビューの作業を行うように割り当てる、レビュー用の構成可能な構造を含んでいてもよい。一例では、顧客には、処理のためにレビューを提出する会社または主体が含まれていてもよい。一例では、提出者には、顧客ポータルにログインして処理用のレビューを送信することができる顧客のエンドユーザを含まれていてもよい。一例では、ステージは、レビューワークフローに沿った単一のステップ（「ディスパッチ」または「完成」など）を含んでいてもよい。一例では、ワークフローは、レビューが通らなければならない一式のステップを含んでいてもよい（いくつかのステップは任意であってもよい）。一例では、証明するという用語は、有資格医療専門家の資格を確立させるプロセスを指してもよい。一例では、ウィジェットという用語は、単一の情報セットまたは機能を提供するための、含有されるダッシュボードページ上で他のコンポーネントの隣で用いられるように設計される小型の軽量ユーザ構成可能ユーザインターフェースコンポーネントを指してもよい。

一例では、メモリデバイスが提供されてもよい。メモリデバイスは、処理デバイスによる実行に応じて、処理デバイスに、電子医療レビューフォームを形成するための複数のフィールドを記憶することと、複数のテンプレートであって、テンプレートの１つ目は複数のうちのフィールドの第１のセットまたはサブセットを含み、テンプレートの２つ目は複数のうちのフィールドの第２のセットまたはサブセットを含み、第２のセットまたはサブセットは第１のセットまたはサブセットとは異なる複数のテンプレートを記憶することと、複数のテンプレートのうちの１つのテンプレートを選択することと、選択されたテンプレートのフィールドを用いてウェブページを生成することと、を含む動作を行うようにさせる命令を、その中に記憶していてもよい。

一例では、動作は、選択されたテンプレートのフィールドのうちの１つを取得することと、取得されたフィールドを実行するかどうかを判定することと、取得されたフィールドを実行するように判定したことを受けて、複数のフィールドから属性を選択して選択された属性に基づいて取得されたフィールドを実行することと、をさらに含む。

一例では、動作は、選択されたテンプレートの最後のフィールドが取得されているかどうかを判定することと、選択されたテンプレートの最後のフィールドが取得されていないと判定したことを受けて、選択されたテンプレートの次のフィールドを取得することと、取得された次のフィールドを実行するかどうかを判定することと、取得された次のフィールドを実行するように判定したことを受けて、複数の属性から同一または異なる属性を選択して、選択された同一または異なる属性に基づいて取得されたフィールドを実行することと、をさらに含む。一例では、複数の属性は読み取り専用属性、必要フィールド属性、またはバリデータ属性のうちの少なくとも１つを含む。

一例では、動作は、最後のフィールドを実行するかどうかを判定した後に、遠隔ウェブブラウザからユーザ入力を受信することと、受信されたユーザ入力に対応する選択されたテンプレートのフィールドのうちの１つを識別することと、識別されたフィールドに対応するコードを解析することと、をさらに含む。

一例では、動作は、コードの解析に反応して、選択されたテンプレートの他のフィールドが識別されたフィールドに依存するかどうかを判定することと、選択されたテンプレートの他のフィールドが識別されたフィールドに依存すると判定したことを受けて、他のフィールドのそれぞれに対応するコードを解析することと、をさらに含む。

一例では、動作は、他のフィールドのそれぞれに対応するコードの解析に反応して、他のフィールドの依存性に基づいてコードを解析するかどうかを判定すること、をさらに含む。

一例では、動作は、ユーザ入力を受信することに反応して、選択されたテンプレートのフィールドを選択的に再実行すること、をさらに含む。

一例では、動作は、選択的に再実行されたフィールドの再実行されたフィールドのそれぞれについて、ラベルのみとして再実行するかどうかを判定することと、ラベルのみとして再実行しないように判定したことに反応して、データをラベルとして再実行することと、をさらに含む。

一例では、動作は、ラベルのみとして再実行されていない選択的に再実行されたフィールドの再実行されたフィールドのそれぞれについて、ラベルとして当該再実行されたフィールドのデータを実行する、または複数のエディタから１つのエディタを選択して、選択されたエディタに基づいて当該フィールドを再実行すること、をさらに含む。一例では、複数のエディタは、数値エディタ、日付エディタ、テキストエディタ、またはタイムスパンエディタのうちの少なくとも１つを含む。

一例では、動作は、複数のレビューステージタイプを記憶することと、複数のうちの第１のステージタイプは第一者に対応し、複数のうちの第２のステージタイプは第一者とは異なる第二者に対応し、複数のうちの第３のステージタイプは第一者および第二者とは異なる第三者に対応し、カスタムワークフローについてユーザ入力を受信することに反応してワークフロー定義を形成することと、をさらに含み、ワークフロー定義データは、複数のうちの選択されたステージタイプ、および複数のうちの選択されたもののステージタイプに基づくプロセスを実行するための選択された順序を識別する。一例では、第一者は医療レビュー組織のスタッフを含み、第二者は医療レビュー組織の顧客を含み、第三者はスタッフとは独立した専門家を含む。一例では、複数のうちの少なくとも１つのステージは、第三者の少なくとも１人の個人を選択するためのディスパッチステージを含み、ディスパッチステージは、第二者によって設定されたパラメータに基づいて、一式の医療専門家からサブセットを選択するためのフィルタリングを含む。一例では、ディスパッチステージは、フィルタリングの結果として得られたサブセットを、第一者によって設定されたパラメータに基づく複数のグループに分けるためのグループ分けをさらに含む。一例では、ディスパッチステージは、レビュー割り当てについて複数のうちの第１のグループのメンバーに第１回目に通知し、第１のグループとは異なる複数のうちの第２のグループのメンバーに、第１回目とは異なる第２回目に通知することを含むスケジューリング、をさらに含む。一例では、第２回目は、固定の日時と、第１のグループの全てのメンバーがレビュー割り当てを明示的に拒否した日時と、のより早い方である。一例では、複数は、延長可能なセットのレビューステージタイプを含み、ワークフロー定義データはユーザ入力の受信時に対応する延長可能セットバージョンに基づく。

一例では、動作は、ワークフロー定義データを選択されたテンプレートに関連付けることと、選択されたテンプレートのフィールドを取得することと、取得されたフィールドをステージごとで実行するかどうかを判定することと、をさらに含んでいてもよい。

一例では、動作は、取得したフィールドを実行するように判定したことを受けて、複数のフィールドから属性を、複数のレビューステージタイプのどのステージが現在のステージに対応するかに基づいて選択することと、選択された属性に基づいて取得されたフィールドを実行することと、をさらに含む。

上述の実施形態の詳細に多くの変更が本発明の根本的な原則から逸脱することなく行われ得ることは、当業者には明らかであろう。したがって、本発明の範囲は、以下の特許請求の範囲のみによって判定される。

上に記載される機器のほとんどはハードウェアおよび関連ソフトウェアを含む。例えば、典型的な電子デバイスは、記載の動作を行うために、１つ以上のプロセッサ、およびそれらのプロセッサ上で実行可能なソフトウェアを含むであろう。本明細書ではソフトウェアという用語を、その一般的に理解される意味で、プログラムまたはルーチン（サブルーチン、オブジェクト、プラグインなど）、および機械またはプロセッサによって使用可能なデータを指して用いられる。周知のとおり、コンピュータプログラムは一般的に、機械読み取り可能またはコンピュータ読み取り可能記憶媒体に記憶される命令を含む。本発明のいくつかの実施形態は、デジタルメモリ等の、機械読み取り可能またはコンピュータ読み取り可能記憶媒体に記憶される実行可能なプログラムまたは命令を含んでいてもよい。我々は、従来の意味での「コンピュータ」がいずれの特定の実施形態において必要であるように暗示しない。例えば、埋め込まれているか他の様態でのさまざまなプロセッサは、本明細書に記載のコンポーネントなどの機器に用いられてもよい。

また、ソフトウェアを記憶するためのメモリは周知である。いくつかの実施形態では、例えば集積回路マイクロプロセッサ等の中に設けられたＲＡＭまたはフラッシュメモリなど、所定のプロセッサに関連付けられるメモリはプロセッサと同一の物理的デバイス（「オンボード」メモリ）に格納されてもよい。他の例では、メモリは、外部ディスクドライブ、記憶アレイ、またはポータブルフラッシュキーフォブ等の独立したデバイスを含んでいてもよい。このような場合、メモリはデジタルプロセッサと、その２つが動作可能に接続されたとき、または互いに、例えばＩ／Ｏポート、ネットワーク接続等で通信可能に接続されたときに「関連付けられ」て、プロセッサはメモリに記憶されたファイルを読むことができるようになる。関連付けられたメモリは、設計（ＲＯＭ）または権限設定のおかげで「読み取り専用」であってもよく、そうでなくてもよい。他の例には、ＷＯＲＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＦＬＡＳＨ等が含まれるが、これらに限定されない。これらの技術はしばしば固体半導体デバイス内で実現される。他のメモリは従来の回転性ディスクドライブ等の動作部品を含んでいてもよい。全てのかかるメモリは「機械読み取り可能」または「コンピュータ読み取り可能」であり、本明細書に記載される機能を実現するための実行可能な命令を記憶するために用いられてもよい。

「ソフトウェア製品」は、一連の実行可能な命令が機械読み取り可能な形式で記憶されて、そのソフトウェア製品への適切なアクセスを有する好適な機器またはプロセッサがその命令を実行してその命令によって実現される処理を行うことができるメモリデバイスを指す。ソフトウェア製品は時々、ソフトウェアを配布するために用いられる。上にまとめられたものを限定されることなく含むあらゆるタイプの機械読み取り可能メモリが、ソフトウェア製品を製造するのに用いられてもよい。しかし、ソフトウェアは電子送信（「ダウンロード」）を介して配信可能であることも知られており、この場合では送信の送信元、または受信先、もしくはその両方にて、対応するソフトウェア製品が典型的に存在するであろう。

本発明の原則をその好適な実施形態で説明および図示したことで、本発明は、かかる原理を逸脱することなく、その構成および詳細が変形され得ることは明らかであろう。我々は、全ての変更および変形が以下の特許請求の範囲の精神および範囲内にあることを主張する。

９ ・・・リモートデバイス
１０ ・・・ブラウザ
１１ ・・・ネットワークデバイス
１２ ・・・実行されたフィールドの第１のセット
１３ ・・・処理デバイス
１４ ・・・ユーザ入力
１５ ・・・複数のフィールド
１６ ・・・実行されたフィールドの第２のセット
１７ ・・・複数のテンプレート
１９ ・・・記憶デバイス
１００・・・システム

Claims (20)

1. その中に命令を記憶するメモリデバイスであって、処理デバイスによる実行を受けて、前記処理デバイスに、
   電子医療レビューフォームを形成するための複数のフィールドを記憶することと、
   複数のテンプレートであって、前記テンプレートの１つ目は前記複数の前記フィールドのうちの第１のセットまたはサブセットを含み、前記テンプレートの２つ目は前記複数の前記フィールドのうちの第２のセットまたはサブセットを含み、前記第２のセットまたはサブセットは前記第１のセットまたはサブセットと異なる、複数のテンプレートを記憶することと、
   前記複数のテンプレートのうちから１つのテンプレートを選択することと、
   前記選択されたテンプレートのフィールドを用いてウェブページを生成することと、を含む動作を行うようにさせる、メモリデバイス。
2. 前記動作は、
   前記選択されたテンプレートの前記フィールドのうちの１つを取得することと、
   前記取得されたフィールドを実行するかどうかを判定することと、
   前記取得されたフィールドを実行するように判定したことを受けて、複数のフィールドから属性を選択して、前記取得されたフィールドを前記選択された属性に基づいて実行することと、をさらに含む、請求項１に記載のメモリデバイス。
3. 前記動作は、
   前記選択されたテンプレートの最後のフィールドが取得されているかどうかを判定することと、
   前記選択されたテンプレートの最後のフィールドが取得されていないように判定したことを受けて、前記選択されたテンプレートの次のフィールドを取得することと、
   前記取得された次のフィールドを実行するかどうかを判定することと、
   前記取得された次のフィールドを実行するように判定したことを受けて、複数の属性から同一または異なる属性を選択して、前記取得されたフィールドを前記選択された同一または異なる属性に基づいて実行することと、をさらに含む、請求項２に記載のメモリデバイス。
4. 前記複数の属性は、読み取り専用属性、必要フィールド属性、またはバリデータ属性のうちの少なくとも１つを含む、請求項３に記載のメモリデバイス。
5. 前記動作は、
   前記最後のフィールドを実行するかどうかを判定した後に、遠隔ウェブブラウザからユーザ入力を受信することと、
   前記受信されたユーザ入力に対応する前記選択されたテンプレートの前記フィールドのうちの１つを識別することと、
   前記識別されたフィールドに対応するコードを解析することと、をさらに含む、請求項４に記載のメモリデバイス。
6. 前記動作は、
   前記コードを解析することに反応して、前記選択されたテンプレートの他のフィールドが前記識別されたフィールドに依存するかどうかを判定することと、
   前記選択されたテンプレートの他のフィールドが前記識別されたフィールドに依存すると判定したことを受けて、前記他のフィールドのそれぞれに対応するコードを解析することと、をさらに含む、請求項５に記載のメモリデバイス。
7. 前記動作は、
   前記他のフィールドのそれぞれに対応する前記コードを解析することに反応して、前記他のフィールドの依存性に基づいてコードを解析するかどうかを判定することをさらに含む、請求項６に記載のメモリデバイス。
8. 前記動作は、
   前記ユーザ入力を受信することに反応して、前記選択されたテンプレートの前記フィールドを選択的に再実行することをさらに含む、請求項７に記載のメモリデバイス。
9. 前記動作は、
   前記選択的に再実行されたフィールドの再実行されたフィールドのそれぞれについて、ラベルのみとして再実行するかどうかを判定することと、
   ラベルのみとして再実行しないように判定したことに反応して、データをラベルとして再実行することと、をさらに含む、請求項８に記載のメモリデバイス。
10. 前記動作は、
    ラベルのみとして再実行されていない前記選択的に再実行されたフィールドの再実行されたフィールドそれぞれについて、当該再実行されたフィールドのデータをラベルとして実行する、または複数のエディタから１つのエディタを選択して、当該フィールドの前記再度裂けさせることを前記選択されたエディタに基づいて行うことをさらに含む、請求項９に記載のメモリデバイス。
11. 前記複数のエディタは、数値エディタ、日付エディタ、テキストエディタ、またはタイムスパンエディタのうちの少なくとも１つを含む、請求項１０に記載のメモリデバイス。
12. 前記動作は、
    複数のレビューステージタイプを記憶することと、
    前記複数のうちの第１のステージタイプは第一者に対応し、前記複数のうちの第２のステージタイプは前記第一者とは異なる第二者に対応し、および前記複数のうちの第３のステージタイプは前記第一者ならびに前記第二者とは異なる第三者に対応し、
    カスタムワークフローのためのユーザ入力を受信することに反応してワークフロー定義を形成することと、をさらに含み、前記ワークフロー定義データは前記複数のうちの前記ステージタイプの選択されたもの、および前記複数のうちの前記ステージタイプの前記選択されたものに基づいた処理を実行するための選択された順番を識別する、請求項１に記載のメモリデバイス。
13. 前記第一者は前記医療レビュー組織のスタッフを含み、前記第二者は前記医療レビュー組織の顧客を含み、前記第三者は前記スタッフとは独立した専門家を含む、請求項１２に記載のメモリデバイス。
14. 前記複数のうちの少なくとも１つのステージは、前記第三者の個人の少なくとも１人を選択するディスパッチステージを含み、前記ディスパッチステージは、前記第二者によって設定されたパラメータに基づいて、一式の医療専門家からサブセットを選択するためのフィルタリングを含む、請求項１２に記載のメモリデバイス。
15. 前記ディスパッチステージは、前記第一者によって設定されるパラメータに基づいて、前記フィルタリングの結果として得られる前記サブセットを複数のグループに分けるためのグループ分けをさらに含む、請求項１４に記載のメモリデバイス。
16. 前記ディスパッチステージは、レビュー割り当てについて前記複数のうちの第１のグループのメンバーに第１回目に通知することと、前記第１のグループとは異なる前記複数のうちの第２のグループのメンバーに、前記第１回目とは異なる第２回目に通知することとを含むスケジューリングをさらに含む、請求項１５に記載のメモリデバイス。
17. 前記第２回目は、固定の日時と、前記第１のグループの全てのメンバーが明示的に前記レビュー割り当てを拒否した日時とのうちの早い方である、請求項１６に記載のメモリデバイス。
18. 前記複数は延長可能セットのレビューステージタイプを含み、前記ワークフロー定義データは前記ユーザ入力の受信時に対応する延長可能セットバージョンに基づく、請求項１２に記載のメモリデバイス。
19. 前記動作は、
    前記ワークフロー定義データを前記選択されたテンプレートと関連付けることと、
    前記選択されたテンプレートのフィールドを取得することと、
    前記取得されたフィールドをステージごとで実行するかどうかを判定することと、をさらに含む、請求項１２に記載のメモリデバイス。
20. 前記動作は、
    前記取得されたフィールドを実行するように判定したことを受けて、複数のフィールドから１つの属性を、前記複数のレビューステージタイプのどのステージが現在のステージに対応するかに基づいて選択することと、
    前記取得されたフィールドを前記選択された属性に基づいて実行することと、をさらに含む、請求項１に記載のメモリデバイス。