JP2014528626A - 健康管理サービスの管理 - Google Patents

健康管理サービスの管理 Download PDF

Info

Publication number
JP2014528626A
JP2014528626A JP2014535822A JP2014535822A JP2014528626A JP 2014528626 A JP2014528626 A JP 2014528626A JP 2014535822 A JP2014535822 A JP 2014535822A JP 2014535822 A JP2014535822 A JP 2014535822A JP 2014528626 A JP2014528626 A JP 2014528626A
Authority
JP
Japan
Prior art keywords
patient
prescription
information
product
provider
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2014535822A
Other languages
English (en)
Other versions
JP2014528626A5 (ja
Inventor
シュトゥッケマン，ピーター・カール
デュベイ，パンカジ
ラニアー，リチャード・エフ
ベンカタラマナン，プラカーシュ
ジンダル，バイハブ
ソード，シャノン・マリー
Original Assignee
アッヴィ バイオテクノロジー リミテッド
アッヴィ バイオテクノロジー リミテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by アッヴィ バイオテクノロジー リミテッド, アッヴィ バイオテクノロジー リミテッド filed Critical アッヴィ バイオテクノロジー リミテッド
Publication of JP2014528626A publication Critical patent/JP2014528626A/ja
Publication of JP2014528626A5 publication Critical patent/JP2014528626A5/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Chemical & Material Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Medicinal Chemistry (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

処方製品の医学的指示／処方を容易にするシステムおよび方法であって、複数のプロバイダに対応する処方製品の事前定義フォームを記憶するメモリデバイスを含むシステムおよび方法。受信機が、処方製品に関する処方製品情報、患者のプロバイダ情報を含む、患者に関する患者受入情報、および、患者に関連する給付金要約を受信する。送信機が、給付金検証リクエストを送信する。プロセッサが、患者受入情報に基づき、患者に対する給付金検証リクエストを生成し、少なくとも患者プロバイダ情報に基づき、事前定義フォームのうち１つを選択し、ユーザ受入情報に基づき、選択された事前定義フォームの少なくとも１つのフィールドを設定し、設定された事前定義フォームをリリーズして、患者への処方製品の医学的指示／処方を容易にするように構成される。

Description

本出願は、全体が参照により本明細書にそれぞれ組み入れられ、かつ優先権が主張される、２０１２年１０月１０日に出願された米国特許仮出願第６１／７１２，１５３号明細書、２０１２年４月１１日に出願された米国特許仮出願第６１／６２３，０３２号明細書、２０１２年４月１１日に提出された米国特許仮出願第６１／６２２，９３０号明細書、および２０１１年１０月１０日に出願された米国特許仮出願第６１／５４５，４８０号明細書に関する。
開示される主題は、健康管理サービスに関し、より詳細には、健康管理製品および／またはサービス、たとえば、医薬品、薬剤、医療デバイス、または他の処方された医学的処置を容易にする、調整する、または管理することに関する。
患者が健康管理プロバイダ（ｈｅａｌｔｈｃａｒｅ ｐｒｏｖｉｄｅｒ、ＨＣＰ）、たとえば、医師または臨床看護師に相談しているとき、健康管理プロバイダは、特定の健康管理製品またはサービスを患者に（たとえば、患者の診断結果または処置の一部として）処方してもよい。一例として、健康管理プロバイダは、薬剤（たとえば、医薬品または生物学的製剤）、または医療デバイス（たとえば、酸素カート）を患者に処方してもよい。他の例として、健康管理プロバイダは、特定分野の専門家である他の健康管理プロバイダに患者を紹介してもよい（たとえば、一般開業医が患者を心臓専門医に紹介してもよい）。
患者が医療保険に入っている場合、時として、患者の医療保険プロバイダが、健康管理プロバイダが患者に処方した製品またはサービスの費用の一部またはすべての支払いをする義務がある場合がある。しかしながら、いくつかのタイプの処方製品またはサービスに対して、保険プロバイダが、患者に処方された製品またはサービスの代金を支払っても構わないとする前に、しばしば「事前承諾」（ｐｒｉｏｒ ａｕｔｈｏｒｉｚａｔｉｏｎ、ＰＡ）と呼ばれる、特定のタイプの承諾または承認を必要とする場合がある。
いくつかの処方製品販売者（たとえば、薬局）または処方サービスプロバイダが、健康管理プロバイダが、製品またはサービスの処方を製品販売者またはサービスプロバイダに電子的に送信することを許可する（たとえば、ファックス、電子的処方、電子文書共有サイト、ファイル転送プロトコル（ＦＴＰ）サイト、電子的送信、画像の送信、または電子メール（ｅｍａｉｌ）を介して）。たとえば、医師が、薬剤の処方を、調合される薬局に電子的に送信してもよい。医薬品処方が書かれた患者からの保険情報を受信すると、薬局は、患者の保険プロバイダと連絡をとって、保険プロバイダが薬剤の代金を支払うことに合意する前に、保険プロバイダが、処方された薬剤の事前承諾を必要とするかどうかを判断する必要がある場合がある。本明細書で使用されるとき、医薬品処方という用語は、薬剤、医薬品、医療デバイス、医学的治療だけでなく、免許を持つＨＣＰからの処方を必要とする他の製品も含むと理解されたい。さらに、健康管理プロバイダが、たとえば、処置などのために、医学的指示を発行してもよい。ＰＡが必要である場合、患者の保険プロバイダが、適切なＰＡフォームを、処方を書いたＨＣＰに送信し、ＨＣＰがフォームを完成し、フォームに署名する。次いで、ＨＣＰは、完成したＰＡフォームを送信もしくは送る、または患者の保険プロバイダに製品および／またはサービスを要求する。患者の保険プロバイダによりＰＡフォームが受信および承認されると、保険プロバイダは、給付金の承認を薬局に送信し、この時点で、薬局は処方を調合し、製品を患者に調剤してもよい。
処方製品またはサービスの事前承諾を得るためのこのような工程は、不便であり、時間がかかり、数多くの人々が必要な事務手続きを処理し、転送する必要があるだけでなく、潜在的に、複数の人々を患者の秘密の健康情報にさらす。この複雑なシステムのせいで、失われた事務手続きのために、また経済的資料またはトレーニング資料へのアクセスが不十分であるために、処方が調合されない状態に陥るというリスクが生じる。したがって、現在のシステムの下では、今日、多くの患者が、必要な医療にアクセスすることができない場合がある。
サードパーティからさまざまなサービスおよび／または給付金が患者に利用可能である場合がある。患者がこれらのサービスおよび給付金を知らない場合、患者は、このような利用可能な給付金を利用することができない場合があり、経済的制約のため、または製品および／またはサービスの使用方法について理解が不足しているために、処方を履行しない場合がある。さらに、サードパーティは、患者の事前同意なしに患者に直接連絡をとることができない場合がある。
開示される主題の一態様では、プロバイダによりカバーされる患者に対する処方製品の医学的指示／処方を容易にするシステムが、処方製品のための複数の事前定義フォームを記憶するための少なくとも１つのメモリデバイスを含む。複数の事前定義フォームは、複数のプロバイダに対応することができる。システムは、処方製品に関する処方製品情報、および患者に関する患者受入情報を受信するための受信機を含む。患者受入情報は、患者のプロバイダ情報を備える。受信機は、給付金検証リクエストに応答して、患者に関連する給付金要約をさらに受信する。システムは、患者受入情報に基づき、給付金検証リクエストを送信するための送信機、および患者に対する給付金検証リクエストを生成するように構成されたプロセッサを含む。プロセッサはまた、少なくとも患者プロバイダ情報に基づき、事前定義フォームのうち１つを選択するように、ユーザ受入情報に基づき、選択された事前定義フォームの少なくとも１つのフィールドに設定するように、および設定された事前定義フォームをリリーズして、患者に対する処方製品の医学的指示／処方を容易にするように構成される。
本明細書で具体化されるように、例示として、医学的指示／処方を容易にするステップは、処方製品の処方を容易にするステップ、または処方製品の支払いの承認を容易にするステップを含むことができる。プロバイダは、保険会社、政府機関、または他のサードパーティの支払人を含むことができる。処方製品は、医療用製品、医療サービス、または医療用製品の投与を含むことができる。処方製品は、生物学的製剤、たとえば、アダリムマブを含むことができる。事前定義フォームは、少なくとも１つの事前承諾フォームを含むことができる。さらに、少なくとも１つのメモリデバイスは、複数のプロバイダに対応する、第２の処方製品に関する第２の複数の事前定義フォームを記憶することができる。代表的な一実施形態では、プロセッサは、患者プロバイダ情報に基づき、事前定義フォームのうち１つを自動的に選択するように構成されることができる。
さらに、本明細書で具体化されるように、例示として、送信機は、給付金検証リクエストを給付金検証者に送信するように構成されることができ、受信機は、給付金検証要約を給付金検証者から受信するように構成されることができる。代表的な一実施形態では、受信機は、事前定義フォームに関する情報を給付金検証者から受信するように構成されることができ、プロセッサは、患者プロバイダ情報に基づき、さらには、給付金検証者から受信された事前定義フォームに関する情報に基づき、事前定義フォームのうち１つを選択するように構成されることができる。送信機は、追加の患者情報のリクエストを送信するようにさらに構成されることができ、プロセッサは、追加の患者情報を受信するように、および選択された事前定義フォームの少なくとも１つのフィールドに追加の患者情報を設定するようにさらに構成されることができる。追加の患者情報は、選択された事前定義フォームに必要であり、かつ患者受入情報、または処方製品に関する処方製品情報に含まれない情報を含むことができる。プロセッサは、設定された事前定義フォームを患者のプロバイダにリリーズするように構成されることができる。プロセッサは、処方製品情報および患者受入情報の少なくとも一部分から処方文書を生成するように、および処方文書を薬局にリリーズするようにさらに構成されることができる。
本明細書で具体化されるように、例示として、システムは、患者受入情報および処方製品情報を受信機に導入するための、少なくとも１つのユーザデバイスをさらに含むことができる。代表的な一実施形態では、送信機および受信機はネットワークに接続されることができ、送信機は、ネットワーク上で、ユーザインタフェースについて記述するマークアップ言語を送信するように構成されることができる。ユーザインタフェースは、患者受入情報および処方製品情報の記入用フィールドを含むことができる。
ユーザデバイス、たとえば、タブレット、携帯電話、またはラップトップが、ネットワークに接続されることができ、データを記憶するためのメモリと、マークアップ言語を構文解析するように、ユーザインタフェースを表示するように、ユーザインタフェースのフィールドの中に記入された患者受入情報および処方製品情報をメモリに記憶するように、および患者受入情報および処方製品情報を受信機に送信するように構成されたプロセッサとを含むことができる。代表的な一実施形態では、ユーザデバイスのプロセッサが、健康管理プロバイダの署名を受信し、かつ処方製品情報から処方文書を生成するようにさらに構成されることができる。さらに、ユーザデバイスのプロセッサは、処方文書を薬局に送信するように構成されることができる。代表的な一実施形態では、システムは、少なくとも１つのユーザデバイスに通信可能に連結されたスキャニングデバイスをさらに含むことができ、スキャニングデバイスのプロセッサが、患者情報文書、たとえば、ライセンスカードまたは医療保険証の１つまたは複数の画像をスキャニングデバイスから受信するように、患者情報文書の画像から患者受入情報の少なくとも一部を抽出するように、およびユーザインタフェースの少なくとも１つのフィールドに自動的に設定するように構成されることができる。
開示される主題の他の態様では、プロバイダによりカバーされる患者に対する処方製品の医学的指示／処方を容易にする方法が、処方製品のための複数の事前定義フォーム、複数のプロバイダに対応する複数の事前定義フォームを中に記憶した少なくとも１つのメモリを提供するステップを含む。方法は、患者のプロバイダ情報、および処方製品に関する処方製品情報を備える患者受入情報を受信するステップと、プロセッサにより、患者受入情報に基づき、患者に対する給付金検証リクエストを生成するステップとを含む。給付金検証リクエストに基づき、給付金要約が得られることができる。プロセッサにより、事前定義フォームのうち１つが、少なくとも患者プロバイダ情報および給付金要約に基づき選択されることができ、患者情報に基づき、選択された事前定義フォームの少なくとも１つのフィールドに設定されることができる。方法は、選択された事前定義フォームで、患者への処方製品の医学的指示／処方を容易にするステップを含む。
さらに、本明細書で具体化されるように、医学的指示／処方を容易にするステップは、処方製品の処方を容易にするステップ、または処方製品の支払いの承認を容易にするステップを含むことができる。プロバイダは、保険会社、政府機関、または他のサードパーティの支払人を含むことができる。処方製品は、医療用製品、医療サービス、または医療用製品の投与を含むことができる。処方製品は、生物学的製剤、たとえば、アダリムマブを含むことができる。事前定義フォームは、少なくとも１つの事前承諾フォームを含むことができる。さらに、方法は、いくつかの可能な処方製品から１つの処方製品を選択するステップと、メモリが、可能な各処方製品に対して複数の事前定義フォームを中に記憶するステップをさらに含むことができ。代表的な一実施形態では、事前定義フォームのうち１つを選択するステップは、プロセッサにより、事前定義フォームのうち１つを自動的に選択するステップを含むことができる。
本明細書で具体化されるように、例示として、給付金要約を得るステップは、給付金検証リクエストを給付金検証者に送信するステップと、給付金要約を給付金検証者から受信するステップとを含むことができる。代表的な一実施形態では、方法は、事前定義フォームに関する情報を給付金検証者から受信するステップと、給付金検証者から受信された事前定義フォームに関する情報に基づき、事前定義フォームのうち１つを選択するステップとを含むことができる。代表的な一実施形態では、方法は、追加の患者情報を要求するステップをさらに含むことができる。さらに、追加の患者情報は受信されることができ、選択された事前定義フォームの少なくとも１つの空白のフィールドに追加の患者情報が設定されることができる。追加の患者情報は、選択された事前定義フォームに必要であり、かつ患者受入情報、または処方製品に関する処方製品情報に含まれない情報を含むことができる。設定された事前定義フォームは、患者のプロバイダにリリーズされることができる。
本明細書で具体化されるように、例示として、方法は、健康管理プロバイダの署名を受信するステップと、処方製品情報から処方文書を生成するステップと、処方文書を薬局にリリーズするステップとをさらに含むことができる。代表的な一実施形態では、方法は、ネットワーク上で、ユーザインタフェースについて記述するマークアップ言語を送信するステップを含む。ユーザインタフェースは、患者受入情報および処方製品情報の記入用フィールドを含むことができる。
本明細書でさらに具体化されるように、例示として、方法は、ユーザデバイスで、たとえば、タブレット、携帯電話、ラップトップ、またはデスクトップコンピュータが、マークアップ言語を構文解析するステップと、ユーザインタフェースを表示するステップと、ユーザインタフェースのフィールドの中に記入された患者受入情報および処方製品情報をメモリに記憶するステップと、患者受入情報および処方製品情報を受信機に送信するステップとを含むことができる。さらに、または代わりに、方法は、ユーザデバイスで、処方製品情報および患者受入情報の少なくとも一部分から処方文書を生成するステップと、処方文書を生成するステップの前に、健康管理プロバイダの署名を受信するステップとを含むことができる。処方文書は、薬局に送信されることができる。さらに、または代わりに、方法は、ユーザデバイスで、デバイスに通信可能に連結されたスキャニングデバイスから、患者識別文書、たとえば、ライセンスカードまたは保険証の１つまたは複数の画像を受信するステップと、患者識別文書の画像から患者受入情報の少なくとも一部を抽出するステップと、ユーザインタフェースの少なくとも１つのフィールドに自動的に設定するステップとを含むことができる。
開示される主題の他の態様では、非一時的コンピュータ可読媒体が、実行されたときに、プロバイダによりカバーされる患者の処方製品に対する医学的指示／処方を容易にする方法を１つまたは複数のユーザデバイスに実行させるコンピュータ実行可能命令を含む。
前述の一般的な説明も、以下の詳細な説明も、代表的なものであり、開示される主題のさらなる説明を提供することが意図されることを理解されたい。
本明細書の中に組み入れられ、かつ本明細書の一部を構成する添付図面が、開示される主題を例示し、かつ開示される主題のさらなる理解を提供するために含まれる。図面が縮尺どおりではなく、かつ例示のためだけに提供されることが認識されよう。説明と合わせて、図面は、開示される主題の原理を説明するのに役立つ。
開示される主題の一実施形態による、処方製品の医学的指示／処方を容易にする代表的システムの構成図である。 開示される主題の一実施形態による、処方製品の医学的指示／処方を容易にする代表的方法の流れ図である。 開示される主題の一実施形態によるサーバアーキテクチャの構成図である。 開示される主題の一実施形態によるサーバアーキテクチャの他の構成図である。 開示される主題の一実施形態によるサーバコンピュータデバイスの代表的構成を示す。 開示される主題の一実施形態によるユーザデバイスの代表的構成を示す。 開示される主題の一実施形態によるユーザデバイスの代表的な一実施形態を示す。 開示される主題の一実施形態によるユーザデバイスの代表的な一実施形態を示す。 開示される主題の他の実施形態による、処方製品の医学的指示／処方を容易にする代表的システムの構成図である。 処方製品またはサービスに関する保険承諾を得る方法の一例を示す。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの一実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題の一実施形態による薬剤の医学的指示／処方管理システムのフローブロック図である。 図６６の薬剤の医学的指示／処方管理システムを使用する患者受入工程の流れ図である。 開示される主題の一実施形態による患者オプトイン工程の流れ図である。 開示される主題の一実施形態に従って、給付金検証（ｂｅｎｅｆｉｔ ｖｅｒｉｆｉｃａｔｉｏｎ、ＢＶ）および電子処方（Ｅ−Ｐｒｅｓｃｒｉｐｔｉｏｎ）を生成するように構成された工程の流れ図である。 開示される主題の一実施形態による事前承諾（ＰＡ）工程の流れ図である。 開示される主題の一実施形態に従って、図６６の薬剤の医学的指示／処方管理システムの中に設備、職員メンバ、および医者を登録する管理者活動の流れ図である。 開示される主題の一実施形態によるコンピュータシステムのシステム図である。 開示される主題の一実施形態の登録ウィンドウの代表的スクリーンショットである。 開示される主題による一実施形態のシステムおよび方法を実装する代表的コンピュータプログラムの概略マップである。 開示される主題による一実施形態のシステムおよび方法を実装する代表的コンピュータプログラムの概略マップである。 開示される主題による一実施形態のシステムおよび方法を実装する代表的コンピュータプログラムの概略マップである。 開示される主題による一実施形態のシステムおよび方法を実装する代表的コンピュータプログラムの概略マップである。 開示される主題による一実施形態のシステムおよび方法を実装する代表的コンピュータプログラムの概略マップである。 開示される主題による一実施形態のシステムおよび方法を実装する他の代表的コンピュータプログラムの概略マップである。 開示される主題による一実施形態のシステムおよび方法を実装する他の代表的コンピュータプログラムの概略マップである。 開示される主題による一実施形態のシステムおよび方法を実装する他の代表的コンピュータプログラムの概略マップである。 開示される主題による一実施形態のシステムおよび方法を実装する他の代表的コンピュータプログラムの概略マップである。 開示される主題による一実施形態のシステムおよび方法を実装する他の代表的コンピュータプログラムの概略マップである。 開示される主題による一実施形態のシステムおよび方法を実装する他の代表的コンピュータプログラムの概略マップである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。 開示される主題のシステムおよび方法を実装するコンピュータプログラムの他の実施形態の代表的スクリーンショットである。
図面全体を通して、特に指定のない限り、同じ参照番号および文字が、例示される実施形態の類似の特徴、要素、構成要素、または部分を示すために使用される。さらに、ここで、開示される主題は、図を参照して詳細に説明されるが、説明は、例証となる実施形態と関連してそのように説明される。
開示される主題は、プロバイダによりカバーされる患者の処方製品に対する医学的指示／処方を容易にする技法に関する。開示される主題の目的および利点が示され、以下の説明から明らかになるであろう。開示される主題の他の利点が、本明細書およびその特許請求の範囲で、ならびに添付の図面から詳細に指摘される方法、装置、およびデバイスにより実現され、達成されるであろう。
時として、患者が健康管理プロバイダ（ＨＣＰ）（たとえば、医師、臨床看護師など）を訪問し、相談しており、健康管理プロバイダが処方製品（たとえば、処方薬）および／またはサービス（たとえば、処置、専門医への照会）を患者に処方／指示するとき、患者の保険プロバイダは、処方製品またはサービスの費用の一部またはすべての支払いをすることに合意する前に、処方製品またはサービスの事前承諾を必要とする場合がある。必要な承諾を保険プロバイダから得るために、健康管理プロバイダは、事前定義フォーム、たとえば事前承諾フォームに記入、署名し、フォームを患者の保険プロバイダに送信する必要がある場合がある。承諾フォームは、患者、処方製品および／またはサービス、ならびに健康管理プロバイダに関するさまざまな情報用フィールドを含んでもよい。このとき、保険プロバイダは、承諾フォームで提出された情報に基づき、処方された製品および／またはサービスの代金を支払っても構わないかどうかを判断してもよい。保険プロバイダは、処方製品および／またはサービスの事前承諾を承認する場合、それに応答して給付金の承認を送信してもよい。
本明細書で開示される主題によれば、プロバイダによりカバーされる患者の処方製品に対する医学的指示／処方を容易にするシステムが、一般に、処方製品のための複数の事前定義フォームを記憶するための少なくとも１つのメモリデバイスを含む。複数の事前定義フォームは、複数のプロバイダに対応することができる。システムは、処方製品に関する処方製品情報、および患者に関する患者受入情報を受信するための受信機を含む。患者受入情報は、患者のプロバイダ情報を備える。受信機は、給付金検証リクエストに応答して、患者に関連する給付金要約をさらに受信する。システムは、患者受入情報に基づき、給付金検証リクエストを送信するための送信機、および患者の給付金検証リクエストを生成するように構成されたプロセッサを含む。プロセッサはまた、少なくとも患者プロバイダ情報に基づき、事前定義フォームのうち１つを選択するように、ユーザ受入情報に基づき、選択された事前定義フォームの少なくとも１つのフィールドに設定するように、および設定された事前定義フォームをリリーズして、医療を容易にするように構成される。
開示される主題によれば、プロバイダによりカバーされる患者の処方製品に対する医学的指示／処方を容易にする方法が、一般に、処方製品のための複数の事前定義フォーム、複数のプロバイダに対応する複数の事前定義フォームを中に記憶した少なくとも１つのメモリを提供するステップを含む。方法は、患者のプロバイダ情報、および処方製品に関する処方製品情報を備える患者受入情報を受信するステップと、プロセッサにより、患者受入情報に基づき、患者に対する給付金検証リクエストを生成するステップとを含む。給付金検証リクエストに基づき、給付金要約が得られることができる。プロセッサにより、事前定義フォームのうち１つが、少なくとも患者プロバイダ情報および給付金要約に基づき選択されることができ、患者情報に基づき、選択された事前定義フォームの少なくとも１つのフィールドに設定されることができる。方法は、選択された事前定義フォームで、患者への処方製品の医学的指示／処方を容易にするステップを含む。
別個の図を通して、類似の参照番号が同一の、または機能的に類似する要素を指す添付図面が、さまざまな実施形態をさらに例示し、かつ開示される主題によるさまざまな原理および利点をすべて説明するのに役立つ。限定のためではなく説明および例示のために、図１および図２を参照して、開示される主題による、プロバイダによりカバーされる患者の処方製品に対する医学的指示／処方を容易にする方法およびシステムの代表的実施形態について以下で説明される。わかりやすくするために、方法およびシステムが同時に、互いに関連して説明され、図２に例示される方法の参照番号が、括弧（）付きでつけられ、図１に描かれるシステムの参照が、括弧なしで行われる。
本明細書で具体化されるように、例示として、図１および図２を参照して、プロバイダ４０によりカバーされる患者の処方製品に対する医学的指示／処方を容易にする技法が、「処方マネージャ」１０の使用を含むことができる。処方マネージャ１０は、少なくとも１つのメモリデバイス２０と、少なくとも１つのプロセッサとを含むことができる。たとえば、処方マネージャ１０は、たとえば図３に描かれ、以下でより詳細に説明されるように、１つまたは複数のコンピュータシステム（スタンドアロンのコンピュータ、サーバ、サーバクラスタ、分散コンピューティングシステム、クラウドベースのコンピューティングシステムなど）上に実装されることができる。
代表的な一実施形態では、処方マネージャ１０は、たとえば、いくつかのウェブページ（たとえば、画面）を含む、対応するウェブサイトをホスティングするウェブベースのソフトウェアアプリケーションとして実装されることができる。ウェブベースのソフトウェアは、たとえばマークアップ言語、たとえばＨＴＭＬ、ＸＭＬなどを使用して、ユーザインタフェースをウェブブラウザに送信することができ、たとえばＨＴＴＰＳ、ＰＯＳＴ、および／またはＧＥＴリクエストを使用して、ウェブブラウザと通信することができることを当業者は認識されよう。さらに、ウェブベースのソフトウェアは、１つまたは複数のウェブサービスとして実装されることができ、ＲＥＳＴ、ＪＳＯＮなどを利用することができることを当業者は認識されよう。ソフトウェアアプリケーションは、非一時的コンピュータ可読媒体、たとえば、ＣＤ−ＲＯＭ、ＤＶＤ、磁気ディスク、ＲＯＭ、ＲＡＭなどに記憶されることができ、ソフトウェアアプリケーションの命令が、処方マネージャ１０の１つまたは複数のプロセッサに連結されたメモリの中に読み込まれることができる。実行されたとき、ソフトウェアは特定の機能をプロセッサに実行させるよう命令することができる。わかりやすくするために、本明細書で以下に説明されるように、処方マネージャ１０の機能は、一般に、処方マネージャ１０のプロセッサが機能を実行させるように構成されていると詳述することなく、説明されてもよい。代わりに、処方マネージャ１０は、本願で開示される主題を実装するためのソフトウェア命令の代わりに、またはソフトウェア命令と組み合わせて、配線により接続された回路で実装されることができる。したがって、本願で開示される主題の実装形態は、ハードウェアとソフトウェアの任意の特定の組合せに、このようなハードウェアおよびソフトウェアが本明細書で開示される方法を実行させるように構成されるという前提で、限定されない。
本明細書で具体化されるように、処方マネージャ１０は、処方製品の医学的指示または処方を容易にする。すなわち、たとえば、以下でより詳細に説明されるように、処方マネージャ１０は、健康管理プロバイダにより患者に処方製品を処方する工程を容易にすることができ、この工程は、給付金検証、事前承諾、ならびに／または医学的指示／処方の生成および／もしくは送信を容易にするステップを含むことができる。代わりに、処方マネージャ１０は、処方製品の支払いの承認を容易にすることができ、たとえば、事前承諾を容易にするステップ、および／または処方製品の払い戻しの承認を容易にするステップを含む。本明細書で開示されるように、処方製品は、医療用製品、医療サービス、または医療用製品の投与を含むことができるが、これらに限定されない。たとえば、処方製品は、医療用製品、たとえば、薬剤、製薬、生物学的薬剤、医療デバイスとすることができる。さらに、または代わりに、処方製品は、たとえば、注入トレーニング、眼の検査、背骨のアラインメントなどの医療サービスとすることができる。さらに、または代わりに、処方製品は、たとえば、健康管理プロバイダの事務所での生物学的薬剤の注入などの、医療用製品の投与とすることができる。本明細書で開示されるとき、「医学的指示／処方」は、たとえば、制御された薬剤の処方、または処置の医学的指示など、処方を必要としないものの、処方および医学的指示のいずれか、または両方を含むことができる。限定するためではなく、わかりやすくするために、以下の説明は、主に処方の工程を参照して行われる。しかしながら、以下の処方に関する説明は、医学的指示に同様に適用可能とすることができることを当業者は認識されよう。システムは、１つの特定の処方製品および／または医学的指示だけを容易にする、またはさらに説明されるように、システムに記憶された数から処方製品および／または指示を選択することが可能になるように構成されることができる。
処方マネージャ１０は、たとえば、複数のプロバイダ４０により必要とされるような処方製品および／またはサービスの事前定義フォームを管理することができる。たとえば、処方マネージャ１０は、複数の保険プロバイダ４０に対応する許諾フォームのリストを維持することができる。さらに、または代わりに、処方マネージャ１０は、異なる処方製品および／またはサービスに対して、異なる健康管理プロバイダにより使用される事前定義フォームのリストを維持することができる。このような事前定義フォームは、少なくとも１つのメモリデバイス２０に、電子的フォーマットで（Ａｄｏｂｅポータブルドキュメントフォーマット（ＰＤＦ）ファイルとして）記憶されることができる。
処方マネージャ１０は、（たとえば、１つまたは複数の適切に構成されたプロセッサを使って）ある種の患者受入情報の獲得（２１）を管理することができる。処方マネージャ１０は、ある種の情報を、たとえば、処方製品に関する処方製品情報、患者に関する患者受入情報（たとえば、プロバイダ情報を含む）、および給付金検証要約を受信する受信機を含むことができる。処方マネージャ１０はまた、ある種の情報、たとえば、給付金検証リクエストを送信する送信機を含むことができる。たとえば、代表的な一実施形態では、処方マネージャ１０は、ネットワーク、たとえば、インターネットまたはイントラネットに接続されることができ、送信機および受信機は、ネットワークを介して通信するように適合された１つまたは複数のネットワークインタフェースカードを含むことができる。このように、送信機および受信機は、たとえば、健康管理プロバイダおよび／または患者により動作させられることができるユーザデバイス６０と通信することができる。さらに、送信機および受信機は、１つまたは複数のプロバイダ４０、処方製品販売者５０、および／または給付金検証者３０と通信することができる。さらに、または代わりに、送信機および受信機は、データを提供する、および／またはデータを受信し、表示するように適合されたハードウェアと通信するための入力ポートおよび出力ポートを含むことができる。たとえば、キーボードおよび表示デバイスが、処方マネージャ１０にローカルに連結されることができる。本明細書で開示されるとき、「送信する」および「受信する」という用語は、任意の電子的通信手段を含むことができ、たとえば、ＴＣＰ／ＩＰ、ＵＤＰ、ＨＴＴＰ、ファクシミリなどを含む。同様に、「送信機」および「受信機」という用語は、電子的情報を送信または受信するように構成された任意のデバイス、たとえば、ネットワークインタフェースカード（ＮＩＣ）、ファックス装置などを含むことができる。
処方マネージャ１０はまた、（たとえば、１つまたは複数の適切に構成されたプロセッサで）患者に対する給付金の検証（３１）（給付金検証リクエストの生成、および給付金検証要約の獲得を含む）を管理することができる。処方マネージャ１０の１つまたは複数のプロセッサは、少なくとも患者受入情報に基づき患者に対する給付金検証リクエストを生成するように構成されることができる。たとえば、給付金検証リクエストは、経歴、プロバイダ情報、診断情報、および受信機（たとえば、ユーザデバイス６０による）に送信される（受信される）ものだけでなく、受信機により受信される必要のない外部情報源からの情報に基づき生成されることができる。たとえば、ある種の患者受入情報が、少なくとも１つのメモリデバイス２０に記憶されることができる。さらに、代表的な一実施形態では、給付金検証リクエストは、同じく受信機により受信される、および／または少なくとも１つのメモリデバイス２０に記憶されることができる、処方製品に関する処方製品情報に基づき生成されることができる。代表的な一実施形態では、給付金検証リクエストは、給付金検証者３０に送信されることができる。給付金検証者３０は、患者に権利がある給付金の要約を１つまたは複数の患者プロバイダ４０に提供することができる任意のエンティティを含むことができる。たとえば、給付金検証者３０は、患者に関する給付金検証要約を独立に生成することができる「薬局給付金マネージャ」または「専門薬局サービスプロバイダ」（集合的に本明細書では「薬局受信者」と呼ばれることができる）を含むことができる。給付金検証要約は、処方マネージャ１０の受信機に送信される（受信機により受信される）ことができる。
処方マネージャ１０は、（たとえば、１つまたは複数の適切に構成されたプロセッサで）患者に対するある種の所定のフォーム、たとえば事前承諾フォームの選択、設定、およびリリーズ（５１）を管理することができる。処方マネージャ１０の１つまたは複数のプロセッサは、患者プロバイダ情報（患者受入情報に含まれることができる）に基づき事前定義フォームのうち１つを選択し、かつユーザ受入情報に基づき、選択された事前定義フォームの少なくとも１つのフィールドに設定するように構成されることができる。たとえば、プロセッサは、患者の保険プロバイダにより必要とされる適切な事前承諾フォームを選択し、かつ患者受入情報に対応するフィールドに自動的にするように構成されることができる。代表的な一実施形態では、処方マネージャ１０は、たとえばユーザデバイス６０との間で、追加の患者情報のリクエストを送信し、かつ追加の患者情報を受信するようにさらに構成されることができる。たとえば、追加の患者情報は、選択された事前定義フォームに必要であるが、患者受入情報、または処方製品情報に含まれない情報を含むことができる。
１つまたは複数のプロセッサは、設定された事前定義フォームをリリーズして、患者への処方製品の医学的指示／処方を容易にするように構成されることができる。たとえば、設定された事前定義フォームは、患者の保険プロバイダ４０にリリーズされることができる。代わりに、設定された事前定義フォームは、給付金検証者３０にリリーズされることができ、給付金検証者３０は、代表的な一実施形態では、設定された事前定義フォームを患者の保険プロバイダ４０にさらにリリーズすることができる。
代表的な一実施形態では、処方マネージャ１０は、（たとえば、１つまたは複数の適切に構成されたプロセッサで）患者に対する処方製品の処方文書または医学的指示文書の生成（４１）および送信（６１）を管理することができる。たとえば、１つまたは複数のプロセッサは、医師の署名を受信し、かつ処方製品情報に基づき処方文書または医学的指示を生成するように構成されることができる。さらに、１つまたは複数のプロセッサは、生成された処方文書を、たとえば処方製品販売者５０に送信するように送信機に命令することができる。さらに、代表的な一実施形態では、処方マネージャ１０は、以下でより詳細に説明されるように、ある種の処方後の工程（７１）を、たとえば、患者の処方の状態をモニタするステップ、またはある種の追加の、または補助的な特徴を患者に提供するステップを管理することができる。
限定のためではなく例示のために、図３を参照して、処方マネージャ１０の追加実施形態、または代替実施形態について以下で説明される。
図３Ａを参照すると、本明細書で「サーバシステム」１１２と呼ばれる、処方マネージャの代表的な一実施形態が、データベースサーバ１１６と、アプリケーションまたはトランザクションサーバ１２４と、ウェブサーバ１２６と、ファックスサーバ１２８と、ディレクトリサーバ１３０と、メールサーバ１３２をさらに含むことができる。記憶デバイス１３４が、データベースサーバ１１６およびディレクトリサーバ１３０に連結されることができる。サーバ１１６、１２４、１２６、１２８、１３０、および１３２は、ローカルエリアネットワーク（ＬＡＮ）内で連結されることができる。複数のクライアントサブシステム（クライアントシステム１１４とも呼ばれる）が、サーバシステム１１２に接続されることができる。たとえば、クライアントサブシステム１１４は、健康管理プロバイダまたは患者により動作させられることができるユーザデバイス６０を含むことができる。さらに、または代わりに、クライアントサブシステム１１４は、給付金検証者３０により動作させられるコンピュータデバイスを含むことができる。代表的な一実施形態では、クライアントシステム１１４は、ウェブブラウザを含むコンピュータとすることができ、その結果、サーバシステム１１２は、インターネットまたはイントラネットを使用してクライアントシステム１１４にアクセス可能である。代表的な一実施形態では、クライアントシステム１１４は、タブレットコンピューティングデバイスまたは任意の適切な携帯型コンピューティングデバイス、たとえば、タブレットコンピュータ、ノートブックコンピュータ、ネットブックコンピュータ、携帯電話などである。
クライアントシステム１１４は、ローカルエリアネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）などのネットワーク、ダイヤルイン接続、ケーブルモデム、セルラーネットワーク、および特殊な高速ＩＳＤＮ回線を含む、多くのインタフェースを通してインターネットに相互接続されることができる。クライアントシステム１１４は、インターネットに相互接続できる任意のデバイスとすることができ、ウェブベースの電話、携帯情報端末（ＰＤＡ）、タブレットコンピュータ、または他のウェブベースの接続可能装置を含む。
データベースサーバ１１６が、以下でより詳細に説明されるように、さまざまな事柄に関する情報を含むメモリデバイス、記憶デバイス、またはデータベース（たとえば、記憶デバイス１３４）に接続されることができる。本明細書で具体化されるように、例示として、集中データベースがサーバシステム１１２上に記憶され、クライアントシステム１１４の１つを通してサーバシステム１１２にログオンすることによりアクセスされることができる。代替の一実施形態では、データベースが、サーバシステム１１２から遠隔で記憶され、集中化されなくてもよい。データベースは、患者データ、健康管理プロバイダ（ＨＣＰ）データ、健康保険会社データ、薬局データ、フォーム、システム使用データ、監査証跡データなどを記憶することができる。
限定のためではなく例示のために、図３Ｂは、サーバシステム１１２の代表的サーバアーキテクチャを描く。サーバシステム１１２は、セキュリティ機器および／またはソフトウェアの集合を通してインターネットまたは他のネットワークに接続されることができる。代表的な一実施形態では、集合は、脅威マネージャ１６０と、１対のファイアウォール１６２Ａおよび１６２Ｂ（集合的にファイアウォール機器１６２）と、１対の負荷分散装置１６４Ａおよび１６４Ｂ（集合的に負荷分散装置１６４）とを含むことができる。脅威マネージャ１６０は、サーバシステム１１２に脆弱性評価および侵入検出を提供することができる。脅威マネージャ１６０は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せの形で実装されることができる。ファイアウォール１６２は、一般に、合法の通信が通過するのを許可しながら、許可されていないアクセスからサーバシステム１１２を保護する１組の規則に基づき、ネットワーク送信を許可または拒否する。ファイアウォール１６２は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せの形で実装されることができる。負荷分散装置１６４は、システム１１２の構成要素間でトラフィックのバランスを保ち、作業負荷を共有するのを容易にすることができる。負荷分散装置１６４は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せの形で実装されることができる。
１対のデジタル署名機器１６６Ａおよび１６６Ｂ（集合的にデジタル署名機器１６６）が、サーバシステム１１２の保護された側に接続されることができる。デジタル署名機器１６６は、本明細書で開示されるシステムにデジタル署名取込みおよびセキュリティ能力を提供することができる。デジタル署名機器１６６は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せの形で実装されることができる。例示される実施形態では、サーバシステム１１２は、４つのアプリケーションサーバ１２４Ａ、１２４Ｂ、１２４Ｃ、および１２４Ｄ（集合的にサーバ１２４）と、２つのデータベースサーバ１１６Ａおよび１１６Ｂ（集合的にサーバ１１６）と、トレーニングサーバ１６８とをさらに含む。サーバ１１６Ａ、１２４Ａ、および１２４Ｂは、第１のハイパーバイザ１７０Ａにより仮想化されたサーバである。同様に、サーバ１１６Ｂ、１２４Ｃ、１２４Ｄ、および１６８は、第２のハイパーバイザ１７０Ｂにより仮想化されたサーバである。他の実施形態では、サーバ１１６、１２４、および１７０は、別個の物理的サーバマシンである。
図３Ｃは、サーバコンピュータデバイス２７５の、たとえば（図１に示されるような）サーバシステム１１２および処方マネージャ１０の代表的構成を示す。サーバコンピュータデバイス２７５は、データベースサーバ１１６と、トランザクションサーバ１２４と、ウェブサーバ１２６と、ファックスサーバ１２８と、ディレクトリサーバ１３０と、メールサーバ１３２とを含むことができるが、これらに限定されない。
サーバコンピュータデバイス２７５は、命令を実行するプロセッサ２８０を含む。命令は、たとえばメモリエリア２８５に記憶されることができる。プロセッサ２８０は、１つまたは複数の処理ユニットを（たとえば、マルチコア構成で）含むことができる。
プロセッサ２８０は、送信機および受信機、すなわち、通信インタフェース２９０に動作可能に連結されることができ、その結果、サーバコンピュータデバイス２７５は、遠隔デバイス、たとえば、コンピュータデバイス２０２または他のサーバコンピュータデバイス２７５と通信することができる。たとえば、通信インタフェース２９０は、インターネットを介してクライアントシステム１１４からリクエストを受信することができる。
プロセッサ２８０はまた、少なくとも１つのメモリに、たとえば記憶デバイス１３４に動作可能に連結されることができる。記憶デバイス１３４は、データを記憶する、および／または取り出すのに適した任意のコンピュータにより動作させられるハードウェアとすることができる。代表的な一実施形態では、記憶デバイス１３４は、サーバコンピュータデバイス２７５の中に一体化される。たとえば、サーバコンピュータデバイス２７５は、１つまたは複数のハードディスクドライブを記憶デバイス１３４として含むことができる。他の実施形態では、記憶デバイス１３４は、サーバコンピュータデバイス２７５の外部にあり、複数のサーバコンピュータデバイス２７５によりアクセスされることができる。たとえば、記憶デバイス１３４は、複数の記憶ユニットを、たとえばハードディスクまたはソリッドステートディスクをＲＡＩＤ（ｒｅｄｕｎｄａｎｔ ａｒｒａｙ ｏｆ ｉｎｅｘｐｅｎｓｉｖｅ ｄｉｓｋｓ）構成で含むことができる。記憶デバイス１３４は、ストレージエリアネットワーク（ＳＡＮ）および／またはネットワーク接続ストレージ（ＮＡＳ）システムを含むことができる。
代表的な一実施形態では、プロセッサ２８０は、ストレージインタフェース２９５を介して記憶デバイス１３４に動作可能に連結されることができる。ストレージインタフェース２９５は、プロセッサ２８０に記憶デバイス１３４へのアクセスを提供することができる任意の構成要素とすることができる。ストレージインタフェース２９５は、たとえば、ＡＴＡ（Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔ）アダプタ、シリアルＡＴＡ（ＳＡＴＡ）アダプタ、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）アダプタ、ＲＡＩＤコントローラ、ＳＡＮアダプタ、ネットワークアダプタ、および／またはプロセッサ２８０に記憶デバイス１３４へのアクセスを提供する任意の構成要素を含むことができる。
メモリエリア２１０および２８５は、ランダムアクセスメモリ（ＲＡＭ）、たとえばダイナミックＲＡＭ（ＤＲＡＭ）またはスタティックＲＡＭ（ＳＲＡＭ）と、読出し専用メモリ（ＲＯＭ）と、消去可能プログラム可能読出し専用メモリ（ＥＰＲＯＭ）と、電気的消去プログラム可能読出し専用メモリ（ＥＥＰＲＯＭ）と、不揮発性ＲＡＭ（ＮＶＲＡＭ）とを含むことができるが、これらに限定されない。上記のメモリタイプは、代表的なものでしかなく、したがって、コンピュータプログラムの記憶のために使用可能なメモリのタイプに関して限定していない。
ユーザデバイス６０の追加実施形態または代替実施形態が、限定のためではなく例示のために、図４を参照して、以下で説明される。
図４は、ユーザ２０１により動作させられるユーザデバイス２０２の、たとえば、クライアントシステム１１４（図３に示されている）およびユーザデバイス６０（図１に示されている）の代表的構成を示す。ユーザデバイス２０２は、たとえば、処方マネージャ１０と通信状態にある任意のデバイスとすることができる。
コンピュータデバイス２０２は、命令を実行するプロセッサ２０５を含むことができる。代表的な一実施形態では、実行可能な命令がメモリ２１０に記憶される。プロセッサ２０５は、１つまたは複数の処理ユニットを（たとえば、マルチコア構成で）含むことができる。メモリエリア２１０は、情報が、たとえば、実行可能な命令および／または他のデータが、記憶され、取り出されることができるようになる任意のデバイスとすることができる。メモリエリア２１０は、１つまたは複数のコンピュータ可読媒体を含んでもよい。
コンピュータデバイス２０２はまた、情報をユーザ２０１に提示するための少なくとも１つの媒体出力構成要素２１５を含むことができる。媒体出力構成要素２１５は、情報をユーザ２０１に伝達することができる任意の構成要素、たとえば、ビデオアダプタおよび／またはオーディオアダプタとすることができる。出力アダプタが、プロセッサ２０５に動作可能に連結され、出力デバイスに、たとえば、表示デバイス（たとえば、液晶表示装置（ＬＣＤ）、有機発光ダイオード（ＯＬＥＤ）表示装置、陰極線管（ＣＲＴ）、または「電子インク」表示装置）および／またはオーディオ出力デバイス（たとえば、スピーカまたはヘッドホン）に動作可能に連結されることができる。
代表的な一実施形態では、コンピュータデバイス２０２は、たとえば、キーボード、スキャナ、ポインティングデバイス、マウス、スタイラス、タッチパネル（たとえば、タッチパッドまたはタッチスクリーン）、ジャイロスコープ、加速度計、位置検出器、カメラ、またはオーディオ入力デバイスなどの、ユーザ２０１からの入力を受信するための入力デバイス２２０を含む。タッチスクリーンなどの単一構成要素が、媒体出力構成要素２１５の出力デバイスと、入力デバイス２２０の両方として機能することができる。さらに、コンピュータデバイス２０２は、ユーザ２０１からの入力を受信するための２つ以上の入力デバイス２２０を含むことができる。たとえば、コンピュータデバイスは、キーボードと、タッチパネルと、スキャナの組合せを含むことができる。
コンピュータデバイス２０２はまた、サーバシステム１１２（たとえば、処方マネージャ１０）などの遠隔デバイスと通信可能に連結された通信インタフェース２２５を含むことができる。通信インタフェース２２５は、たとえば、有線または無線のネットワークアダプタ、または携帯電話ネットワーク（たとえば、ＧＳＭ（登録商標）（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、符号分割多元接続（ＣＤＭＡ）、３Ｇ、４Ｇ、またはブルートゥース）もしくは他の移動データネットワーク（たとえば、ＷＩＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ））で使用するための無線データトランシーバを含むことができる。
メモリエリア２１０に記憶されているのが、たとえば、媒体出力構成要素２１５を介してユーザ２０１にユーザインタフェースを提供し、任意選択で、入力デバイス２２０から入力を受信し、処理するためのコンピュータ可読命令である。ユーザインタフェースが、他の可能性の中でも、ウェブブラウザと、クライアントアプリケーションとを含んでもよい。ウェブブラウザにより、ユーザ２０１などのユーザが、典型的にはサーバシステム１１２からのウェブページまたはウェブサイト上に埋め込まれた媒体および他の情報を表示し、対話することが可能になる。クライアントアプリケーションにより、ユーザ２０１が、サーバシステム１１２によるサーバアプリケーションと対話することができるようになる。
ユーザデバイス５０の追加実施形態または代替実施形態が、限定のためではなく例示のために、図５を参照して、以下で説明される。
図５は、たとえば、クライアントシステム１１４（図３に示されている）およびユーザデバイス６０（図１に示されている）として動作可能な、健康管理プロバイダ（「ＨＣＰ」）により使用されるための代表的ユーザデバイスを描く。本明細書で具体化されるように、例示として、コンピューティングデバイス５０２は、表示装置５０６およびキーボード５０８を含むことができる。本明細書で遠隔入力コンピュータともばれるコンピューティングデバイス５０２は、命令を実行するプロセッサ（図示されていない）を含む。代表的な一実施形態では、実行可能な命令がメモエリア（図示されていない）に記憶される。限定のためではなく例のために、コンピューティングデバイス５０２、すなわちタブレットコンピューティングデバイスであって、表示装置５０６が、ユーザに画像およびデータを表示し、かつユーザが表示装置５０６で触れることによりユーザ（またはユーザにより制御された、スタイラスなどの道具）から入力を受信するように動作可能なタッチスクリーン表示デバイスであるコンピューティングデバイス５０２。付属のキーボードを含むのではなく、コンピューティングデバイス５０２は、表示装置５０６上に表示された仮想キーボードを含むことができる。代表的な一実施形態では、コンピューティングデバイス５０２は、一体化された物理的キーボードを含むのではなく、たとえば機械的接続、無線接続を介すなどして物理的キーボードに接続可能である。さらに、代表的な一実施形態では、コンピューティングデバイス５０２は、物理的キーボードを含む、または物理的キーボードに結合可能であり、仮想キーボードを含む。コンピューティングデバイス５０２は、サーバシステム１１２などの遠隔デバイスと通信可能に連結された少なくとも１つの通信インタフェース（図示されていない）を含む。通信インタフェースは、たとえば、有線もしくは無線のネットワークアダプタ、または携帯電話ネットワーク（たとえば、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、３Ｇ、４Ｇ、またはブルートゥース）もしくは他の移動データネットワーク（たとえば、ＷＩＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ））で使用するための無線データトランシーバを含んでもよい。さらに、コンピューティングデバイス５０２は、２つ以上の通信インタフェースを、たとえば、有線ネットワークアダプタ、ならびに無線ネットワークアダプタおよび／または無線データトランシーバを含むことができる。
さらに、または代わりに、例示のために、ユーザデバイス（ユーザデバイス、たとえば７３４０など）が、一緒に連結されたコンピュータ５０２と、スキャナ５０４とを含むことができる。ノートブックコンピュータ５０２などのコンピュータが、表示装置５０６と、キーボード５０８とを含む。本明細書で開示されるように、例示として、表示装置５０６は、ユーザがたとえば指またはスタイラスで表示装置５０６に触れたときに、ユーザ（たとえば、健康管理プロバイダ）からの入力を検出することができるタッチ感知デバイス（たとえば、タッチスクリーン）であってもよい。たとえば、ユーザは、タッチ感知表示装置５０６上のユーザインタフェース構成要素を１回または２回タップして、その構成要素を選択する、または起動させることができる。ユーザはタッチ感知表示装置５０６上のユーザインタフェース構成要素を２本の指でピンチオープンまたはピンチクローズして、その構成要素をズームイン、もしくはズームアウト、またはオープン、もしくはクローズしてもよい。ユーザは、タッチ感知表示装置５０６にわたりスワイプして（たとえば、左、右、上、または下にスワイプして）、一連のユーザインタフェース構成要素を見ることができる。本明細書で開示されるように、例示として、ユーザは、タッチ感知表示装置５０６上で（たとえば、スタイラスまたは指で）自分の名前を署名し、ユーザの署名は、電子的フォーマットの形で（たとえば、画像として）取り込まれ、記憶されることができる。さらに、ユーザは、キーボード５０８を使用して（たとえば、文字をタイプして）、ノートブックコンピュータ５０２に入力を提供することができる。
本明細書で開示されるように、例示として、ノートブックコンピュータ５０２上にウェブブラウザがインストールされ、実行されることができる。健康管理プロバイダは、ウェブブラウザを使用して、処方マネージャ７３１０にアクセスすることができる。この場合、処方マネージャ７３１０は、ウェブベースのアプリケーション（たとえば、いくつかのウェブページを含むウェブサイト）を実装することができ、健康管理プロバイダは、ウェブブラウザでウェブサイトの正しいＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）を入力することにより、処方マネージャ７３１０に対応するウェブサイトにアクセスしてもよい。ノートブックコンピュータ５０２と処方マネージャ７３１０の間で送信される情報は、たとえば、患者のプライバシを保護するために、安全なネットワーク接続上で暗号化され、送信されることができる。
たとえば、図５Ｂを参照すると、ＨＣＰシステム５００が、コンピューティングデバイス５０２と、スキャニングデバイス５０４とを含むことができる。スキャニングデバイス５０４は、データ（たとえば、画像）をコンピューティングデバイス５０２に送信するために、コンピューティングデバイス５０２に通信可能に連結されることができる。スキャニングデバイス５０４は、スキャニング窓５１０の近傍に置かれた項目をスキャンする、または画像化するように動作可能であってもよい。代表的な一実施形態では、スキャニングデバイス５０４および／またはユーザデバイス５００は（単独で、または集合的に）、メモリデバイスに記憶された命令などにより、スキャンされた画像に対してＯＣＲを行い、認識された文字をコンピューティングデバイス５０２に送信するように構成されることができる。本明細書で説明されるように、スキャニングデバイス５０４は、たとえば、ライセンス、医療保険証、処方給付金カードなどのような患者識別文書をスキャンするために使用されることができる。
代表的な一実施形態では、図５Ａを参照すると、コンピューティングデバイス５０２は、任意選択でカメラ５２４を含むタブレットコンピューティングデバイスである。代表的な一実施形態では、表示装置５２２は、ユーザに画像およびデータを表示し、かつユーザが表示装置５２２で触れることによりユーザ（またはユーザにより制御された、スタイラスなどの道具）から入力を受信するように動作可能なタッチスクリーン表示デバイスである。代わりに、例示のために、タブレット５２０は、カードスキャナ（たとえば、図５のスキャナ５０４）に連結されることができる。タッチ感知表示装置５２２は、たとえば指またはスタイラスで表示装置５２２にユーザが触れたときに、ユーザ（たとえば、健康管理プロバイダ）からの入力を検出することができる。本明細書で開示されるように、例示として、ユーザは、タッチ感知表示装置５２２上で（たとえば、スタイラスまたは指で）自分の名前を署名することができ、ユーザの署名は、電子的フォーマットの形で（たとえば、画像として）取り込まれ、記憶されることができる。さらに、または代わりに、事前に取り込まれた署名が、データストアから取り出されることができる。例示のために、カメラ５２４は、対象の、たとえば患者の識別カード、運転免許証、または保険証（複数可）のデジタル写真を撮るために使用されることができる。たとえば、患者または健康管理プロバイダは、カメラ５２４の前でカードを保持し、制御ボタンを押すことができる。代わりに、例示のために、タブレット５２０に連結されたカードスキャナが、図５に関連して上記で説明されたように、カードをスキャンするために使用されることができる。タブレット５２０上で実行されるソフトウェアとして実装されたＯＣＲまたは画像認識技法が、カード上に提供された情報を抽出し、情報を電子的フォーマットに変換し、情報を個々のフィールドに記憶するのに役立つことができる。
代表的な一実施形態では、コンピューティングデバイス５０２は、電子署名を取り込むように構成される。コンピューティングデバイス５０２は、電子署名の取込みが望まれるとき、表示装置５０６上の署名ブロックを表示するように構成される。ユーザ、たとえば、ＨＣＰは、タッチスクリーンのスタイラスを利用して、表示装置５０６上の署名ブロック内に自分の署名を行うことができる。代表的な一実施形態では、ユーザの署名は、電子的フォーマットの形で（たとえば、画像として）取り込まれ、記憶されることができる。さらに、本明細書で具体化されるように、たとえば、電子署名の使用を許可しない管轄区では、ＨＣＰは、可視媒体筆記用具、たとえば、インクペン、鉛筆、マーカなどを使用して、印刷されたフォーム上で自分の署名を行うことができる。他の実施形態では、ＨＣＰは、印刷されたフォームを表示装置５０６で整列させ、可視媒体筆記用具だけでなく電子的筆記用具も含む特殊な書込デバイスを使用して、印刷されたフォーム上に自分の署名を行うことができ、その結果、物的署名に加えて、電子署名がシステムにより取り込まれる。このような実施形態では、目に見える物理的な、手書きの署名が、印刷されたフォーム上に得られ、コンピューティングデバイス５０２は、物理的な、手書きの署名のデジタル表現を電子署名としてほぼ同時に取り込む。代表的な一実施形態では、コンピューティングデバイス５０２は、表示装置５０６に対して紙のフォームを整列させる方法をユーザに指示するレジストレーションマークを表示する。さらに、スキャニングデバイス５０４は、さらに、または代わりに、コンピューティングデバイス５０２に類似する手法で電子署名を取り込むように構成されることができる。さらに、ＨＣＰにより動作させられるユーザデバイスシステム５００は、本明細書で説明されるように、手書きの署名のデジタル表現を取り込むように本明細書に述べられているように動作可能な、別個の署名取込みデバイス（図示されていない）を含むことができる。他の実施形態では、ＨＣＰは、スキャニングデバイスまたはデジタル取込みデバイス、たとえばデジタルカメラを利用して、自分の物理的署名の画像を取り込むことができる。次いで、取り込まれた画像は、さまざまな送信手段によってシステムに送信されることができる。
コンピューティングデバイス５０２は、コンピューティングデバイス５０２およびＨＣＰユーザデバイスシステム５００が、一般に、本明細書で説明される医学的処置調整システムおよび方法に従って機能できるようにするユーザインタフェースを含むことができる。ユーザインタフェースは、メモリデバイスに記憶されることができる、および／または遠隔に（サーバシステム１１２上などに）記憶され、ウェブブラウザを介すなどしてコンピューティングデバイス５０２によりアクセスされることができる。さらに、代表的コンピューティングデバイス５０２が、ユーザインタフェースに入力されたデータをコンピューティングデバイス５０２のメモリデバイスに記憶することができる、および／または入力データを遠隔に、たとえばデータベースに記憶することができる。
限定のためではなく例示のために、図６を参照して、上記で説明された技法の追加実施形態または代替実施形態について以下で詳細に説明される。
図６は、健康管理プロバイダが自分の患者に処方する製品またはサービスに対する保険承諾を、健康管理プロバイダおよび健康管理プロバイダの患者が得るのを容易にするように動作可能な代表的システム７３００を示す。代表的な一実施形態では、システム７３００は、保険プロバイダにより必要とされる処方製品および／またはサービスの承諾フォームを管理し、かつ保険プロバイダから処方製品および／またはサービスの承諾を得るために必要なフォームに健康管理プロバイダが記入するのに役立つ処方マネージャ７３１０を含むことができる。たとえば、限定することなく、処方マネージャ７３１０は、異なる処方製品および／またはサービスに対して、異なる保険プロバイダにより必要とされる、または異なる健康管理プロバイダにより使用される承諾フォームのリストを維持することができる。これらの承諾フォームは、必要に応じて更新されることができる（たとえば、新規フォームが追加されることができる、既存のフォームが修正されることができる、期限切れのフォームが削除されることができるなど）。たとえば、紙のフォーマットの保険承諾フォームが、（たとえば、文書スキャナを使用して）スキャンされ、（たとえば、光学式文字認識（ＯＣＲ）プログラムを使用して）記入することが可能なフォームに変換され、記憶されることができる。さらに、または代わりに、システム７３００、およびより具体的には処方マネージャ７３１０は、さまざまな保険プロバイダと通信可能に、または電子的にリンクされることができ、保険プロバイダは、それぞれのフォームをシステム７３００の中に電子的にアップロードし、更新することができる。必要なときには、処方マネージャ７３１０は、特定の処方製品および／またはサービスに対する、特定の保険プロバイダにより必要とされる、適切なフォームを選択し、利用可能な、または処方マネージャ７３１０により得られた情報に基づき、選択されたフォーム内のフィールドに記入し、完成したフォームを見直しおよび署名のために健康管理プロバイダに送信することができる。
さらに、例示のために、処方マネージャ７３１０は、健康管理プロバイダが自分の患者の処方を管理するのに役立つことができる。たとえば、健康管理プロバイダが、完成した保険承諾フォームを処方マネージャ７３１０から受信後、ある期間、完成した保険承諾フォームを見直し、署名しない場合、処方マネージャ７３１０は、健康管理プロバイダにリマインダを送信することができる。処方マネージャ７３１０は、特定の処方が調合されたとき、健康管理プロバイダに通知することができる。例示のために、処方マネージャ７３１０は、患者が患者の処方を使用するのに役立つことができる。たとえば、処方マネージャ７３１０は、処方薬の服用方法に関する指示書（たとえば、ビデオまたはオーディオによる指示）、処方薬の起こり得る副作用に関連するＦＡＱ（ｆｒｅｑｕｅｎｔｌｙ ａｓｋｅｄ ｑｕｅｓｔｉｏｎ）および回答などを提供することができる。さらに、処方マネージャ７３１０は、患者の処方の状態（たとえば、患者の処方が受け取られる、または出荷される準備ができているかどうか、患者の処方が拒否されたかどうか、または健康管理プロバイダが処方／承諾工程を完了していないかどうか）を示す通知を患者に提供することができる。
本明細書で開示されるように、例示として、処方マネージャ７３１０は、自分のユーザが比較的容易に、処方マネージャ７３１０により提供されるさまざまな機能にアクセスすることができるように、ユーザインタフェースを実装することができる。ユーザインタフェースは、任意の数の画面を含むことができる。例示のために、ユーザインタフェースは、いくつかのウェブページ（たとえば、画面）を含む、対応するウェブサイトをホスティングするウェブベースのソフトウェアアプリケーションとして実装された、ウェブベースのユーザインタフェースとすることができる。たとえば、健康管理プロバイダまたは患者は、ユーザデバイス上で実行されているウェブブラウザを使用して、対応するウェブサイトにアクセスすることができる。
さらに、処方マネージャ７３１０は、上記でより詳細に説明されたように、１つまたは複数のコンピュータシステム（たとえば、サーバ）上に実装されることができる。（上記でより詳細に説明された）図３は、処方マネージャ７３１０を実装するために使用されることができる代表的サーバを示す。処方マネージャ７３１０により実行される動作または機能は、非一時的コンピュータ可読媒体に記憶され、かつコンピュータシステム上で実行されることができるコンピュータソフトウェアとして実装されることができる。本明細書で開示されるように、例示として、処方マネージャ７３１０は、さまざまなタイプのユーザ（たとえば、医師、看護師、事務所職員、患者、薬剤師など）を有することができる。処方マネージャ７３１０により実行される機能の中には、一般に、すべてのタイプのユーザに適用可能とすることができるものがあるが、一方、他の機能は特定のタイプのユーザに適用可能とすることができる（たとえば、製品またはサービスの処方に関連する機能は、具体的には医師に適用可能とすることができる）。
本明細書で開示されるように、例示として、処方マネージャ７３１０は、各データストア７３１２に記憶された情報が処方マネージャ７３１０にアクセス可能となるように、１つまたは複数のデータストア７３１２を含む、または１つまたは複数のデータストア７３１２に通信可能にリンクされることができる。データストア７３１２は、任意の適用可能な情報を記憶するために使用されることができる。たとえば、図１を参照して上記で説明されたように、保険承諾フォームは電子的フォーマット（たとえば、ＰＤＦ、テキスト、拡張可能なマーク付け言語（ＸＭＬ）、バイナリデータ、コンマ区切りデータ、または任意の他の適用可能な電子的フォーマット）の形でデータストア７３１２に記憶されることができる。他の情報、たとえば、患者に関する情報（たとえば、患者の記録、たとえば、名前、住所、病歴、保険プロバイダ、または患者に関する同様のことなどの）、健康管理プロバイダに関する情報（たとえば、名前、業務分野、専門、病院または医療施設の提携先、または健康管理プロバイダに関する同様のこと）、または処方製品またはサービスに関する情報（たとえば、推奨される投薬量、起こり得る副作用、処置手順、製造業者、または処方製品に関する同様のこと）もまたデータストア７３１２に記憶されることができる。データストア７３１２は、任意の適用可能なタイプの記憶デバイス、たとえば内部もしくは外部のドライブ、またはネットワークドライブとすることができる。本明細書で開示されるように、例示として、データストア７３１２は、電子医療記録システム（ｅｌｅｃｔｒｏｎｉｃ ｍｅｄｉｃａｌ ｒｅｃｏｒｄ ｓｙｓｔｅｍ、ＥＭＲ）をさらに含むことができる。ＥＭＲは、患者データを、たとえば、医療記録、検査結果などを含むことができ、このようなデータは、本明細書で企図されるように、処方マネージャ７３１０と共有されることができる。
本明細書で開示されるように、例示として、ユーザデバイス７３４０は、健康管理プロバイダと関連づけられることができる。健康管理プロバイダは、ユーザデバイス７３４０を介して処方マネージャ７３１０にアクセスすることができる。さらに、患者は、健康管理プロバイダを訪問している間、健康管理プロバイダからの同意を得て、同じくユーザデバイス７３４０を介して処方マネージャ７３１０にアクセスすることができる。たとえば、健康管理プロバイダまたは患者は、ユーザデバイス７３４０を使用して処方マネージャ７３１０に患者情報を送信することができる。健康管理プロバイダは、特定の製品またはサービスを患者に処方し、ユーザデバイス７３４０を使用して処方マネージャ７３１０に処方を伝達することができる。処方製品またはサービスに対して保険承諾フォームが必要とされる場合、健康管理プロバイダがフォーム見直し、署名することができるように、処方マネージャ７３１０は、処方製品またはサービスに対する、完成した保険承諾フォームをユーザデバイス７３４０に送信することができる。例示のために、健康管理プロバイダは、処方マネージャ７３１０に対してアカウントを有することができる。健康管理プロバイダと関係のある情報（たとえば、患者、処方、未決定の保険承諾フォーム、リマインダなど）が、健康管理プロバイダのアカウントに含まれることができる。健康管理プロバイダは、処方マネージャ７３１０に対して自分のアカウントにログインして、利用可能な情報を見直し、他の関連活動を行うことができる。
限定のためではなく例示のために、ユーザデバイス７３４０は、携帯型デバイス、たとえば、タブレットまたはノートブックコンピュータまたはスマート電話とすることができ、さまざまなセンサを含むことができる。ユーザデバイス７３４０は、ネットワークへの無線接続を介して（たとえば、健康管理プロバイダの事務所で利用可能なＷｉ−Ｆｉまたは３Ｇまたは４Ｇ接続を使用して）コンピュータネットワークまたは通信ネットワーク上で処方マネージャ７３１０と通信することができる。ユーザデバイス７３４０と処方マネージャ７３１０の間で送信される情報は、（たとえば、患者のプライバシを保護するために）暗号化され、任意選択で、（たとえば、データサイズを低減するために）圧縮されることができる。本明細書で開示されるように、例示として、ユーザデバイス７３４０は、電子メール（ｅｍａｉｌ）、テキスト、ファックス、および／または電子データを特定のｅｍａｉｌアドレス、ファックス番号、および／またはデータストア（たとえば、データストア７３１２）に送信することができる。電子式ファックスを送信する場合、ユーザデバイス７３４０は電話回線に接続されることができる。電話回線上で特定のファックス番号にファックスを送信するために、ユーザデバイス７３４０上にファックスソフトウェアアプリケーションがインストールされ、実行されることができる。代わりに、電子式ファックスは、コンピュータネットワーク上で送信されることができ、この場合、電話回線は必要ない。
本明細書で開示されるように、例示として、上記で指摘されたように、処方マネージャは、ウェブベースのアプリケーションとして実装されることができ、ユーザデバイス７３４０は、処方マネージャにアクセスし、かつユーザインタフェースを表示するためのウェブブラウザを含むことができる。さらに、上記で指摘されたように、スキャナ５０４は、さまざまなタイプのカードを、たとえば、患者の識別カード、運転免許証、または保険証をスキャンすることができるカードスキャナとすることができる。スキャナ５０４は、このようなカード上の情報（たとえば、患者の名前、住所、生年月日、性別、運転免許証または識別番号、保険プロバイダ、保険番号など）を取り込むことができる。例示のために、患者のカードをスキャンすることにより取り込まれた情報は、個々のフィールドに記憶されることができ、各フィールドが、フィールド名およびフィールド値を有することができる。たとえば、「Ｊｏｈｎ Ｓｍｉｔｈ」という患者では、この名前用フィールドが存在することができ、フィールド名は「患者の名前」であり、フィールド値は「Ｊｏｈｎ Ｓｍｉｔｈ」である。Ｊｏｈｎ Ｓｍｉｔｈの生年月日用の第２のフィールドが存在することができ、フィールド名が「患者の生年月日」であり、フィールド値が「１９７１年６月１５日」である。Ｊｏｈｎ Ｓｍｉｔｈの保険プロバイダ用の第３のフィールドが存在することができ、フィールド名が「保険プロバイダ」であり、フィールド値が「Ｂｌｕｅ Ｓｈｉｅｌｄ ｏｆ Ｃａｌｉｆｏｒｎｉａ」である。Ｊｏｈｎ Ｓｍｉｔｈの保険番号用の第４のフィールドが存在することができ、フィールド名が「保険番号」であり、フィールド値が「５４９１７８５０」である。
さらに、上記で説明されたようにユーザデバイス７３４０により取り込まれた各情報を表現するデータは、固有識別子でタグをつけられることができる。たとえば、患者の名前が、その識別子として「Ｆ−Ｎａｍｅ」でタグをつけられることができ、患者の名字がその識別子として「Ｌ−Ｎａｍｅ」でタグをつけられることができる。保険承諾フォームがシステム７３００に追加されたとき、フォーム内部のフィールドが、これらの固有の識別子で同様にタグをつけられることができる。したがって、データが（たとえば、ユーザデバイス７３４０により）取り込まれた、またはデータストアから（たとえば、データストア７３１２から）取り出されたとき、各承諾フォーム内部の、タグをつけられたフィールドに、必要なデータが自動的に設定されることができる。例示のために、システム７３００は技術的ユーザインタフェースを含むことができ、新しく更新されたフォームが、（たとえば、システム管理者またはシステムユーザにより）データタグを含むように編集されることができ、それにより、システム７３００および保険承諾フォームを最新に保つ能力が追加される。
本明細書で具体化されるように、スキャンされたカードの画像から情報を抽出するために、ＯＣＲ技法が使用されることができる。ＯＣＲ機能を実装するソフトウェアが存在することができる。いくつかの事例では、ＯＣＲソフトウェアは、ノートブックコンピュータ５０２の一部であり、ノートブックコンピュータ５０２上で実行されることができる。他の事例では、ＯＣＲソフトウェアは、スキャナ５０４の一部であり、スキャナ５０４上で実行されることができる。さらに、患者または健康管理プロバイダは、スキャンされた情報を見直し、必要に応じて個々のフィールド値を手作業で入力または訂正する（たとえば、キーボード５０８を使用してノートブックコンピュータ５０２の中に情報をタイプする）ことができる。
さらに、ユーザデバイス７３５０が患者と関連づけられることができる。患者は、ユーザデバイス７３５０を介して処方マネージャ７３１０にアクセスすることができる。例示のために、患者は、処方マネージャ７３１０に対するアカウントを有することができる。患者は、ユーザデバイス７３５０を使用して、自分のアカウントにログインし、自分の処方製品またはサービスに関する情報を見直すことができる。たとえば、患者は、ユーザデバイス７３５０にインストールされ、実行されているウェブブラウザを使用して、処方マネージャ７３１０に対応するウェブサイトにアクセスすることができる。
ユーザデバイス７３５０は、タブレットもしくはノートブックコンピュータもしくは携帯電話などの携帯型デバイス、またはデスクコンピュータなどの据え付け型のデバイスとすることができる。ユーザデバイス７３５０は、ネットワークへの無線接続（たとえば、ＷｉＦｉ、３Ｇ、４Ｇ）または有線接続（たとえば、イーサネット（登録商標））を介してコンピュータネットワークまたは通信ネットワーク上で処方マネージャ７３１０と通信することができる。ユーザデバイス７３５０と処方マネージャ７３１０の間で送信される情報は、（たとえば、患者のプライバシを保護するために）暗号化され、任意選択で、（たとえば、データサイズを低減するために）圧縮されることができる。
本明細書で具体化されるように、システム７３００は、１つまたは複数の処方製品販売者７３２０（たとえば、処方薬を販売するための薬局）を含むことができる。さらに、または代わりに、本明細書で開示されるように、例示として、システム７３００は、１つまたは複数の処方サービスプロバイダ７３３０（たとえば、特定の分野で健康管理サービスを提供する専門医、たとえば、心臓専門医または脳外科医）を含むことができる。健康管理プロバイダは、必要に応じて、ユーザデバイス７３４０を介して、処方製品販売者７３２０および／または処方サービスプロバイダ７３３０と通信することができる。たとえば、健康管理プロバイダは、処方製品販売者７３２０または処方サービスプロバイダ７３３０に電子メール（ｅｍａｉｌ）またはファックスを送信することができる。処方製品販売者７３２０または処方サービスプロバイダ７３３０、インターネットにアクセスするために、および任意選択で、他のエンティティと通信する（たとえば、ｅｍａｉｌを送信および受信する）ために、ユーザデバイス（図示されていない）と、たとえばネットワークに接続されたコンピューティングデバイスと関連づけられることができる。
本明細書で開示されるように、例示として、患者の記録を記憶するための１つまたは複数のデータストア７３６０が存在することができる（たとえば、電子医療記録システム）。データストア７３６０は、システム７３００の一部とすることができる、またはそうすることができない。たとえば、データストア７３６０は、処方サービスプロバイダ７３３０と関連づけられることができ、この場合、データストア７３６０は、システム７３００の一部とすることができる。代わりに、データストア７３６０は独立したサードパーティ（たとえば、病院）と関連づけられることができ、この場合、データストア７３６０は、システム７３００の一部とすることができない。いくつかの事例では、処方マネージャ７３１０は、でデータストア７３６０にアクセスして、患者の情報（たとえば、医療記録）を取り出すことが可能とすることができる。
本明細書で開示されるように、例示として、患者は、１つまたは複数の保険プロバイダ７３７０を有することができる。いくつかの事例では、患者が保険プロバイダ７３７０を１つだけ有することができる。他の事例では、患者が複数の保険プロバイダ７３７０（たとえば、主プロバイダおよび１つまたは複数の副プロバイダもしくは補助的プロバイダ）を有することができる。処方製品販売者７３２０または処方サービスプロバイダ７３３０は、任意の適用可能な手段（たとえば、電話、ファックス、ｅｍａｉｌなど）により患者の各保険プロバイダ７３７０と通信して、（たとえば、健康管理プロバイダにより）患者に処方された製品またはサービスに対して各保険プロバイダ７３７０から承諾を得ることができる。
保険プロバイダ７３７０は、システム７３００の一部ではない、１つまたは複数の指定された処方製品販売者７３８０および／または処方サービスプロバイダ７３９０を有することができることがある。この場合、処方された製品またはサービスの代金を保険プロバイダ７３７０が支払うことに合意するように、患者は、保険プロバイダ７３７０と関連づけられた処方製品販売者（複数可）７３８０または処方サービスプロバイダ（複数可）７３９０から、処方された製品またはサービスを得る必要がある。
本明細書で開示されるように、例示として、適用可能である限り、システム７３００（たとえば、システム７３００の動作および機能）は医療保険の相互運用性と説明責任に関する法律（Ｈｅａｌｔｈ Ｉｎｓｕｒａｎｃｅ Ｐｏｒｔａｂｉｌｉｔｙ ａｎｄ Ａｃｃｏｕｎｔａｂｉｌｉｔｙ Ａｃｔ、ＨＩＰＡＡ）の要件を満たす。たとえば、ある種のタイプの情報が、ＨＩＰＡＡ要件または他の機密性の懸念により特定の当事者（たとえば、処方製品製造業者またはサービスプロバイダ）にアクセス可能であるべきではない場合、システム７３００は、このタイプの情報を特定の当事者がアクセスすることができないことを保証する情報統制手段または情報保護手段を実装することができる。他の例として、患者のプライバシを保護するために、コンピュータネットワークまたは通信ネットワーク（たとえば、インターネット）上で送信された情報、たとえば、処方マネージャ７３１０とユーザデバイス７３４０または７３５０の間で送信された情報が暗号化されることができる。
本明細書で開示されるように、例示として、システム７３００を使用するために、健康管理プロバイダは、最初に（たとえば、対応するウェブサイトで）処方マネージャ７３１０に対してユーザアカウントを登録し、確立する必要がある。アカウントが確立されると、健康管理プロバイダに関する情報が、健康管理プロバイダのアカウントで、処方マネージャ７３１０に対して記憶されることができる。例示のために、健康管理プロバイダのユーザアカウントは、固有ユーザ名で識別され、アカウントにログインするために使用されることができるパスワードにより保護されることができる。さらに、健康管理プロバイダのユーザアカウントは、任意の数の、権限のあるユーザを有することができる。一例として、医師用に確立されたアカウントが、アカウントユーザの１人として医師を有することができる。医師用に確立されたアカウントはまた、このアカウントの他の、権限のあるアカウントユーザとして医師のために働いている看護師または事務所職員を有することができる。看護師または事務所職員は、アカウントにログインし、許可を得て、医師の監督の下で、さまざまな活動を行うことができる。他の例として、同じクリニックを共有している複数の医師およびその職員メンバが、単一のユーザアカウントを確立し、共有することができる。例示のために、アカウントを管理する責任のある、指定されたユーザ（たとえば、アカウント管理者）が存在することができる。管理者は、アカウントと関連づけられた情報を修正することが可能とすることができる。
開示される主題の他の態様によれば、処方マネージャ７３１０により提供されるユーザインタフェースは、アカウント登録工程を通して、健康管理プロバイダまたは指定されたアカウント管理者を誘導するために、健康管理プロバイダと関連づけられたユーザデバイス（たとえば、ユーザデバイス７３４０）でアクセス可能な一連の画面（たとえば、ウェブページ）を含むことができる。さまざまな画面で、健康管理プロバイダは、健康管理プロバイダのアカウントで、処方マネージャ７３１０に対して記憶されるべきさまざまなタイプの情報を入力することができる。たとえば、図１０〜図２０は、処方マネージャ７３１０に対してユーザアカウントを登録し、確立する（１１）ように健康管理プロバイダを誘導するための、代表する一連の画面を示し、これらの画面は、たとえば、ＨＣＰに関する情報を、たとえば、名前、提携先、場所、職員、および電子署名情報を記入するステップを含むことができる。さらに、図２５〜図３０は、（たとえば、カードスキャナを含むユーザデバイス７３４０を使用して）患者の受入工程（２１）を行うときに、必要な患者情報を自動的に抽出するために、患者のカードをスキャンするように健康管理プロバイダを誘導するための画面の例を示す。さらに、以下でより詳細に説明されるように、給付金検証（３１）および事前承諾（５１）が行われることができ、一連の画面を介して医学的指示／処方が生成され（４１）、送信される（６１）ことができる。
限定のためではなく例示のために、次に、本明細書で開示される処方製品の医学的指示および／または処方を容易にするための方法のさまざまな追加実施形態および代替実施形態について詳細に説明する。上記で指摘されたように、処方マネージャは、患者に対する処方製品の医学的指示／処方を容易にすることができ、これは、患者、ＨＣＰ、および／または他のサードパーティ、たとえば給付金検証者３０などに対して、ユーザアカウントをセットアップするステップ（１１）を含むことができる。患者受入情報が受信される（２１）ことができ、給付金検証（３１）および事前承諾（５１）が行われることができ、医学的指示／処方が生成され（４１）、送信される（６１）ことができる。
上記で指摘されたように、（たとえば、限定することなく、１０、７３１０、および１１２として図で描かれる、処方マネージャのさまざまな実施形態を含む）処方マネージャは、単独で、または（たとえば、限定することなく、６０、５００、５２２、および１１４として図で描かれる、ユーザデバイスのさまざまな実施形態を含む）１つもしくは複数のユーザデバイスと組み合わせて、システムのさまざまなユーザに対するアカウント情報を管理する（１１）ことができる。システムの異なるユーザが、ある種のカテゴリのアカウントを有することができる。たとえば、ＨＣＰはＨＣＰアカウントを有することができ、管理者は管理者アカウントを有することができ、患者は患者アカウントを有することができ、ある種の給付金検証者（たとえば、薬局受信者など）がアカウントを有することができる。このように、各当事者が、たとえば、本明細書で説明される１つまたは複数のユーザデバイスを通して、本明細書で開示されるシステムにアクセスすることができる。
図１０〜図２０は、たとえば、ＨＣＰに関する情報、たとえば、名前、提携先、場所、職員、および電子署名情報を記入するステップを含むことができる、処方マネージャ７３１０でユーザアカウントを登録し、確立する（１１）よう健康管理プロバイダを誘導するための一例の一連の画面を示す。例示のために、健康管理プロバイダのアカウントにおける情報が、その関連性に基づき、カテゴリに編成され、表示されることができる。たとえば、図１０に示される「マイプロファイル」タブ１００２から、健康管理プロバイダは、自分の名前、ユーザ名、パスワード、および連絡先情報（たとえば、電話番号）を記入することができる。代わりに、アカウントの管理者が、タブ１００２を通して自分の情報を記入することができる。図１１に示される「サービスの場所」タブ１１００から、健康管理プロバイダは、自分が提携させられる施設、または自分の事務所の場所を記入することができる。図１２および図１３に示される「ＨＣＰプロファイル」タブ１２００から、健康管理プロバイダ（たとえば、医師、看護師）である、アカウントの権限を与えられたユーザが表示され、記入されることができる。図１４および図１５に示される「事務所職員プロファイル」タブ１４００から、職員である、アカウントの権限を与えられたユーザが表示され、記入されることができる。図１６および図１７で示される「関連づけ」タブ１６００から、健康管理プロバイダの関連づけが表示され、記入されることができる。図１９および図２０に示される「署名」タブ１８０４から、健康管理プロバイダは、自分のアカウントで、またはユーザデバイス７３４０上で記憶された電子署名を有することができる。そうするためには、健康管理プロバイダは、たとえばスタイラスを使用して、ユーザデバイス７３４０のタッチスクリーン上に自分の名前を署名することができる。
本明細書で開示されるように、例示として、システム７３００を使用するために、患者が、最初に（たとえば、対応するウェブサイトで）処方マネージャ７３１０に対してユーザアカウントを登録し、確立する（１１）必要があるとすることができる。アカウントが確立されると、患者に関する情報が、患者のアカウントで、処方マネージャ７３１０に対して記憶されることができる。例示のために、患者のユーザアカウントは、固有ユーザ名で識別され、パスワードにより保護されることができる。
患者が、（たとえば、患者に関連づけられたユーザデバイス７３５０を使用して）独力で、処方マネージャ７３１０に対してユーザアカウントを登録することができる、または健康管理プロバイダを訪問したときに（たとえば、健康管理プロバイダの事務所で、健康管理プロバイダに関連づけられたユーザデバイス７３４０を使用して）、そうすることができる。たとえば、患者が健康管理プロバイダを訪問しており、健康管理プロバイダが、保険承諾を必要とする患者に対して製品またはサービスを処方することを決定したとき、患者が処方マネージャ７３１０に対してユーザアカウントをまだ有しない場合で、かつ患者が合意した場合、健康管理プロバイダは、このとき、患者の受入工程（２１）を開始し、ユーザデバイス７３４０を使用して、処方マネージャ７３１０の中に患者の情報を入力することができる。これにより、患者の記録が処方マネージャ７３１０で確立させられる。例示のために、受入工程が完了すると、ユーザアカウントが患者に対して確立される。
図７３は、典型的には、ＨＣＰシステム５００の表示装置５０６（図５に示されている）上に表示される代表的ＨＣＰ登録ウィンドウ６００のスクリーンショットである。他の実施形態では、ＨＣＰ登録ウィンドウ６００は、任意の他の適切な表示デバイス上に、たとえば、クライアントシステム１１４上の表示デバイス、ワークステーション１３８、１４０、１４２、１４６、および１５４、携帯型デバイス１５８などの上に表示されることができる。登録ウィンドウ６００は、連絡先情報ウィンドウ６０２と、事務所情報ウィンドウ６０４と、ログイン情報ウィンドウ６０６とを含む。本明細書で開示されるシステムの代表的な一実施形態でＨＣＰを登録するためには、医師の連絡先情報（たとえば、名前、ライセンス番号など）が連絡先情報ウィンドウ６０２で記入され、事務所情報（たとえば、名前、住所など）が事務所情報ウィンドウ６０４で記入され、ログイン情報（たとえば、ユーザ名、パスワードなど）がログイン情報ウィンドウ６０６で記入される。関係のある情報が記入されると、本明細書で開示されるシステムにＨＣＰを登録するために、提出ボタン６０８が選択されることができる。本明細書で具体化されるように、本明細書で開示されるシステムへの登録は、代表的ＨＣＰシステム５００を使用して行われる。他の実施形態では、本明細書で開示されるシステムへの登録は、ポータル機能を介するなどして、ＨＣＰシステム５００から別個に行われる。
図７４Ａ〜図７４Ｅは、本開示のシステムおよび方法に従って実装された、本明細書で開示されるシステムに関連する代表的ユーザインタフェースの概略マップ７００を示す。図７４Ｂは、管理者用の代表的ユーザインタフェースの図を描く。経路７０２上で、管理者は、いくつかの管理オプションを提示される。図１０〜図１７は、経路７０２に沿ったウィンドウのスクリーンショットである。
図１０は、管理者プロファイルウィンドウ１０００のスクリーンショットである。管理者プロファイルウィンドウ１０００は、現在ログインされている管理者に関する、一般的なプロファイル情報を表示する。管理者は、業務の１つもしくは複数の部分（すべてを含む）に関して、本明細書で具体化されるシステムを運営するように権限を与えられた業務管理者、および／または１人または複数の業務管理者に対して、プロファイル、認証情報などの設定を含む１つもしくは複数の業務全体に関して、本明細書で開示されるシステムを運営するように権限を与えられたシステム管理者とすることができる。プロファイル情報は、ユーザのプロファイル情報を更新／変更するために、編集され、保存されることができる。プロファイルウィンドウ１０００は、プロファイルタブ１００２を選択することにより、管理者によりいつでも表示されることができる。ユーザが、プロファイルタブ１００２以外のタブを選択した場合、以下で説明されるように、異なるウィンドウが表示される。
サービスの場所タブ１００４を選択することにより、図１１に示されるサービスの場所（ＬＯＳ）ウィンドウ１１００が表示される。ＬＯＳウィンドウ１１００は、１つまたは複数の施設に関する情報を表示する。したがって、たとえば、２つ以上の事務所を含む医療業務が、ＬＯＳウィンドウ１１００に記憶され、表示された各施設名、住所、電話番号、ファックス番号などを有することができる。代表的な一実施形態では、記憶された情報は、本明細書で開示されるシステムにより１つまたは複数のフォームに設定するために使用される。
図１２および図１３は、ＨＣＰプロファイルタブ１００６を選択することによりアクセス可能なＨＣＰウィンドウ１２００のスクリーンショットである。ＨＣＰウィンドウ１２００は、１つまたは複数のＨＣＰに関する情報を表示する。この情報は、ＨＣＰウィンドウ１２００に要約フォームの形で提示される。より詳細な情報が、本明細書で開示されるシステムの中にすでに記入されたＨＣＰに対して編集される、および／または本明細書で開示されるシステムに新規ＨＣＰを追加するときに記入されることができる。図１３は、たとえば、名前、住所、ＬＯＳ、仕事および携帯の電話番号、専門、ライセンス番号などを含む、記入されることができる、ＨＣＰに関する詳細な情報を示すために、新規ＨＣＰを追加することを選択することにより展開されたＨＣＰウィンドウ１２００のスクリーンショットである。既存のＨＣＰを選択し、かつＨＣＰプロフィルの編集を選択することにより、本明細書で開示されるシステムの代表的な一実施形態ですでに記入されたＨＣＰに対して、ＨＣＰウィンドウ１２００から、同じ情報が編集されることができる。
事務所職員プロファイルタブ１００８を選択することにより、ＨＣＰ職員メンバのプロファイルもまた、管理者により見られ、作成され、編集されることができる。この選択により、図１４および図１５に示される職員プロファイルウィンドウ１４００にアクセスできる。要約した職員プロファイル情報が職員プロファイルウィンドウ１４００に表示される。より詳細な情報が、本明細書で開示されるシステムの中にすでに入力された職員に対して編集される、および／またはシステムに新規職員メンバを追加するときに記入されることができる。図１５は、たとえば、名前、住所、ｅｍａｉｌアドレス、仕事の電話番号、および携帯電話番号を含む、記入されることができる職員メンバに関する詳細な情報を示すために、新規事務所職員メンバを追加するために選択することにより展開された職員プロファイルウィンドウ１４００のスクリーンショットである。既存の事務所職員メンバを選択し、かつプロファイルの編集を選択することにより、システムにすでに記入された事務所職員メンバに対して、職員プロファイルウィンドウ１４００から、同じ情報が編集されることができる。
関連づけタブ１０１０を選択することにより、業務内部の関連づけが見られ、追加され、および／または編集されることができる。業務内部の関連づけは、どの職員メンバが、どの業務場所で、どのＨＣＰと作業するかを含む。関連づけタブ１０１０を選択することにより、図１６および図１７に示される関連づけウィンドウ１６００にアクセスできる。要約した関連づけ情報が関連づけウィンドウ１６００に表示される。より詳細な情報が編集される、および／または新しく記入されることができる。図１７は、新規関連づけの追加を選択することにより展開された関連づけウィンドウ１６００のスクリーンショットである。展開された関連づけウィンドウ１６００から、管理者は、事務所職員メンバを選択し、どの場所（複数可）でどの職員メンバが作業するかを選択し、職員メンバが作業するＨＣＰ（複数可）を選択することができる。既存の事務所職員メンバを選択し、かつ関連づけの編集を選択することにより、関連づけがすでに記入された事務所職員メンバに対して、関連づけウィンドウ１６００から、同じ情報が編集されることができる。
上記で指摘されたように、図７３は代表的ＨＣＰ登録ウィンドウである。ユーザは、登録されたＨＣＰまたは事務所の職員メンバであるとき、管理者に提示されたのと異なるユーザへのオプションを提示されることができる。一般に、ユーザは、ユーザのプロファイルに対する（図７４Ｃに示される）プロファイル経路７０４を下方に進む、（図７４Ｃに示される）ダッシュボード経路７０６に進む、または（図７４Ｄに示される）新規患者経路７０８に進むオプションを提示される。各経路７０４〜７０８の中には、ＨＣＰだけによりアクセス可能なページがあり、事務所職員だけにアクセス可能なページがあり、職員およびＨＣＰによりアクセス可能なページがある。図１８〜図２０は、ユーザがＨＣＰとしてログインしたときの、プロファイル経路７０４に沿ったウィンドウの一部のスクリーンショットであり、一方、図２１は、ユーザが事務所職員メンバとしてログインしたときの、経路７０４に沿ったウィンドウのスクリーンショットである。
図１８は、ユーザがプロファイルボタン１８０２を選択したときに、本明細書で開示されるシステムのＨＣＰユーザに表示されるＨＣＰプロファイルウィンドウ１８００のスクリーンショットである。ＨＣＰプロファイルウィンドウ１８００は、ログインしたＨＣＰに関する情報を表示する。情報は、たとえば、名前、住所、ＬＯＳ、ＤＥＡ番号、パスワード、仕事および携帯の電話番号、専門、ライセンス番号などを含む。情報は、ＨＣＰにより編集されてもよい、および／またはシステムの中にまだ記入されていないとき、記入されてもよい。代表的な一実施形態では、関連づけられた事務所職員およびＬＯＳの情報が、ＨＣＰにより編集されなくてもよく、プロファイルウィンドウ１８００上でＨＣＰに表示されだけである。このような情報の変更および記入が、管理者により行われることができる。
署名タブ１８０４を選択することにより、ユーザは、図１９に示される署名ウィンドウ１９００にアクセスすることができる。署名ウィンドウ１９００から、ユーザは、たとえば、薬局照会、処方文書、およびＰＡフォームを含む、本明細書で開示されるシステムを使用して作成された文書に添付されてもよい電子署名を見る、および／または作成することができる。本明細書で使用されるとき、電子署名は、手書きの署名の電子的表現である。現在記憶されている電子署名が、適用可能である場合、署名ウィンドウ１９００に表示される。ユーザは、初めて、または現在保存されている署名を置換するために、新規署名を作成することを望む場合、署名を取り込むことを選択し、署名ウィンドウ１９００の上に、図２０に示されるポップアップウィンドウ２０００が出現する。次いで、ユーザは、たとえば、表示装置５０６上で、タッチスクリーンスタイラスを利用して、システムにより取り込むために自分の署名を物理的に行うことができる。他の実施形態では、ユーザは、別個の署名取込みデバイス上で物理的に署名することができる、および／またはタッチスクリーンスタイラス以外のデバイスを使用して署名することができる。取り込まれた署名は、ポップアップウィンドウ２０００に表示される。ポップアップウィンドウ２０００に表示された、取り込まれた署名は、受け入れられ、保存されてもよい、またはユーザは署名を消去し、自分の署名を再度取り込むことができる。他の実施形態では、ユーザは、デジタルカメラなどのデジタルイメージングデバイスを使用して署名を取込み、取り込まれた署名画像をシステムにアップロードすることができる。
図２１は、ユーザがプロファイルボタン１８０２を選択したときに、システムの職員ユーザに表示される職員プロファイルウィンドウ２１００のスクリーンショットである。職員プロファイルウィンドウ２１００は、ログインした職員メンバに関する情報を表示する。情報は、たとえば、名前、ユーザＩＤ、パスワード、ｅｍａｉｌアドレス、仕事および携帯の電話番号、ＬＯＳ、関連づけられたＨＣＰ、職員メンバが書類に署名する権限を与えられているＨＣＰなどを含む。情報は、職員メンバにより編集される、および／またはシステムの中にまだ記入されていないとき、記入されることができる。代表的な一実施形態では、関連づけられたＨＣＰ、ＬＯＳ情報、および職員メンバが署名する権限を与えられているＨＣＰは、職員メンバにより編集されなくてもよく、プロファイルウィンドウ２１００上で職員メンバに表示されるだけである。このような情報の変更および記入が、管理者により行われる。限定のためではなく例示のために、図７５は、本開示のシステムおよび方法に従って実装された、本明細書で開示されるシステムに関連する代表的ユーザインタフェースの他の代表的概略マップを示す。
上記で指摘されたように、（たとえば、限定することなく、１０、７３１０、および１１２として図で描かれる、処方マネージャのさまざまな実施形態を含む）処方マネージャはまた、単独で、または（たとえば、限定することなく、６０、５００、５２２、および１１４として図で描かれる、ユーザデバイスのさまざまな実施形態を含む）１つもしくは複数のユーザデバイスと組み合わせて、ある種の患者情報の獲得（「患者受入」）（２１）を管理することができる。
本明細書で開示されるように、例示として、患者の記録またはアカウントを確立する（１１）ために、「患者受入」（２１）と呼ばれることができる、患者に関するさまざまなタイプの情報が必要とされることができる。患者情報は、たとえば、限定することなく、名前、住所、性別、生年月日、社会保障番号、保険プロバイダ、保険番号、好ましい薬局、好ましい健康管理施設（たとえば、病院またはクリニック）、かかりつけの医師の名前など含むことができる。必要な患者情報を得る方法がさまざまある。一例として、患者が、健康管理プロバイダを訪問しているときに（たとえば、ユーザデバイス７３４０を使用して患者の受入工程を健康管理プロバイダに行わせる）、処方マネージャ７３１０に対してアカウントを確立したいと仮定する。ユーザデバイス７３４０がカードスキャナを含む場合、患者の運転免許証、識別カード、および／または保険証（複数可）が（たとえば、カードの表および／もしくは裏、または両側を）スキャンされ、患者の情報が、（たとえば、ＯＣＲを使用して）スキャンされた画像から自動的に抽出されることができる。他の例として、ユーザデバイス７３４０がカメラを含む場合、患者の運転免許証、患者の識別カード、のデジタル写真（たとえば患者の顔）、および／または保険証（複数可）が得られることができ、患者の情報が、（たとえば、画像認識を使用して）デジタル写真から自動的に抽出されることができる。本明細書で使用されるとき、「スキャニングデバイス」という用語は、たとえば、カードスキャナなどの光学スキャナだけでなく、デジタル写真を獲得するのに適したカメラを指すことができる。このようなスキャニングデバイスは、特定のユーザデバイス（たとえば、ユーザデバイス７３４０）に直接連結される必要がないことを当業者は認識されよう。たとえば、スキャニングデバイスは、スキャンされた画像を送信するためにユーザデバイス７３４０に連結されることができる、任意の適切なコンピューティングデバイスまたはプロセッサに連結されることができる。第３の例として、患者の情報は、（たとえば、仮想または物理的なキーボードを使用して）ユーザデバイス７３４０の中に手作業でタイプされることができる。
本明細書で開示されるように、例示として、処方マネージャ７３１０により提供されるユーザインタフェースは、患者受入工程（２１）を通して健康管理プロバイダを誘導する、またはアカウント登録工程を通して患者を誘導する、ユーザデバイス（たとえば、ユーザデバイス７３４０または７３５０）でアクセス可能な一連の画面（たとえば、ウェブページ）を含むことができる。さまざま画面で、健康管理プロバイダまたは患者は、患者のアカウントで、処方マネージャ７３１０で保存される、または患者の記録（複数可）をそこに（たとえば、データストア７３６０に）保存されるようにＥＭＲに送信される、さまざまなタイプの情報を入力することができる。
図２５〜図３０は、（たとえば、カードスキャナを含むユーザデバイス７３４０を使用して）患者の受入工程を行っているときに、必要な患者情報を自動的に抽出するために、健康管理プロバイダを誘導して、患者の識別文書をスキャンする画面の例を示す。たとえば、健康管理プロバイダは、図２５に示される「スキャン」アイコン２５０４を起動させて、カードスキャニング工程を開始することができる。図２６では、アイコン２６０２および２６０４が、健康管理プロバイダを誘導して、患者の運転免許証の表と裏の両方をスキャンすることができる。図２８および図２９では、健康管理プロバイダは、患者の医療保険証または処方カードの表および／もしくは裏、または両側をスキャンするように誘導されることができる。これらのカードから抽出された情報は、患者の情報と関係がある、図２５に示されるさまざまなフィールド２５０２、および図２８に示されるフィールド２８０２に自動的に設定する（すなわち、記入する）ために使用されることができる。患者は、個々のフィールド値を見直して、スキャンされたカードの画像から情報が正しく抽出されたことを確かめ、必要なときに、任意のフィールド値を手作業で訂正することができる。
患者の情報がユーザデバイス７３４０の中に記入されると、ユーザデバイス７３４０は、患者の情報を暗号化し、処方マネージャ７３１０に送信することができる。処方マネージャ７３１０は、さらに、患者のアカウントを作成し、患者の情報をアカウントに（たとえば、データストア７３１２に）記憶する。情報は、本明細書で開示されるように、暗号化されたフォーマットで記憶されることができ、表示または処理の目的で一時的に復号されることができる。患者は、アカウントに関連づけられたユーザ名およびパスワードを使用して、将来、自分のアカウントでログインすることができる。さらに、健康管理プロバイダは、（たとえば、図２２に示される画面２２０２から）自分自身のアカウントにより患者の情報にアクセスすることができる。
限定のためではなく、例示のために、次に、患者が健康管理プロバイダ（たとえば、医師、看護師、または他のタイプの医療専門家）を訪問しており、健康管理プロバイダが患者に処方薬（すなわち、処方製品）、たとえば、Ａｂｂｏｔｔ Ｂｉｏｔｅｃｈｎｏｌｏｇｙ Ｌｔｄにより開発および製造されたヒュミラ（ＨＵＭＩＲＡ）（Ｒ）を処方すること、または患者に他の健康管理プロバイダ（すなわち処方サービス）、たとえば専門医を照会することを決定する状況が参照され、これは、本明細書で開示されるシステムおよび方法によりサポートされる。健康管理プロバイダは、システムおよび方法を利用して、必要なときに、処方製品またはサービスに対して、患者の保険プロバイダから承諾を得ることができる。
上記で説明されたように、本明細書で開示されるように、例示として、システム７３００を利用するために、健康管理プロバイダも、患者も、処方マネージャ７３１０に対して自分のそれぞれのユーザアカウントを確立する必要がある。特定の製品またはサービスを患者に処方することを決定すると、健康管理プロバイダは、処方マネージャ７３１０に対して自分のアカウントでログインすることができる。そうするために、健康管理プロバイダは、たとえば、ユーザデバイス７３４０を使用して、ログイン画面（たとえば、処方マネージャ７３１０に対応するウェブサイトにあるログインウェブページ）にアクセスし、アカウントに関連づけられた自分のユーザ名およびパスワードを提供することができる。処方マネージャ７３１０により提供されたウェブベースのユーザインタフェースの一部とすることができるログイン画面の一例８００が図８に示されている。自分のアカウントにログインすると、健康管理プロバイダは、処方マネージャ７３１０により実装され、サポートされた機能にアクセスして、さまざまな患者看護活動を行うことができる。患者に関しては、この場合も、患者が、健康管理プロバイダを訪問している時点に、処方マネージャ７３１０に対してアカウントをまだ有しない場合、健康管理プロバイダは、自分自身のアカウントにログインし、次いで、患者のユーザアカウントを確立するために必要とされる患者受入工程を行うことができる。一方、患者がシステム７３００の中にすでに入力されており、処方マネージャ７３１０に対してユーザアカウントを有する場合、患者受入工程を行う必要がない。代わりに、本明細書で開示されるように、例示として、健康管理プロバイダは、自分自身のアカウントでログインし、自分のアカウントにより（たとえば、図２２の画面２２０２から）患者の情報を取り出し、患者について処方マネージャ７３１０に記憶された情報を検証することができる。
本明細書で具体化されるように、健康管理プロバイダがシステム７３００で患者をブラウズし、検索することができるようにするために、処方マネージャ７３１０のウェブベースのユーザインタフェースの一部として処方マネージャ７３１０により画面（たとえば、ウェブページ）が提供されることができる。図２２は、患者情報画面２２０２の一例を示す。この場合、受入工程が進行中である患者がエリア２２０４に列挙されることができる。未決定の照会を有する患者が、エリア２２０６に列挙されることができる。さらに、健康管理プロバイダは、テキストフィールド２２１０に患者の名前を入力することによりと、特定の患者を検索することができる。システム７３００内の患者の記録が見つかると、健康管理プロバイダは、処方工程を続けることができる。限定のためではなく例示のために、図２２Ｂは、開示される主題の一実施形態による署名要件を含む他の代表的患者情報画面を示す。
本明細書で開示されるように、例示として、健康管理プロバイダは、ユーザデバイス７３４０を使用して、処方された製品またはサービスに関する情報を入力することができる。例示のために、画面は、健康管理プロバイダを誘導して、処方情報を入力するために、処方マネージャ７３１０のウェブベースのユーザインタフェースの一部として、処方マネージャ７３１０により画面が提供されることができる。図３０〜図３５は、健康管理プロバイダを誘導して、ユーザデバイス７３４０で処方情報を入力する画面の例を示す。たとえば、健康管理プロバイダは、図３０に示される画面３０００から、患者に対する「サービスの場所」および「ＨＣＰの名前」（すなわち、健康管理プロバイダの名前）を選択する。これは、健康管理プロバイダ自身の事務所の場所および名前とすることができる。図３１に示される画面３１００から、健康管理プロバイダは、患者の診断結果、および患者に処方される特定の製品またはサービスをタイプインする、または事前に確立されたリスト（たとえば、プルダウンメニュー）から選択することができる。システムおよび方法は、処方された製品１つだけをサポートするように、またはいくつかの処方された異なる製品から選択することができるように構成されることができる。健康管理プロバイダが患者に薬剤を処方する場合、推奨される投薬量が図３２および図３３に示される画面３１００上に表示されることができる。健康管理プロバイダは、推奨される投薬量を選択する、または推奨される投薬量をオーバーライドして、異なる投薬量を記入することができる。同様に、薬剤投与を行う、推奨される回数が、図３３に示される画面３１００上に表示されることができ、健康管理プロバイダはこの回数を、オーバーライドするように選べば、オーバーライドすることができる。図３１に示される画面３１００上に安全性について考慮すべき点が表示されることができる。健康管理プロバイダは、薬剤投与の形態（たとえば、丸剤、注入など）を選択、または指定することができる。健康管理プロバイダは、これが患者に新規に処方される薬剤投与であるか、継続的処方であるか、患者が中断後に薬剤投与を再開しているかどうかを指定することができる。患者は、健康管理プロバイダを通して、患者が薬剤を購入し、受け取ることができる好ましい薬局を選択することができる。健康管理プロバイダは、患者に専門医を紹介する場合、専門医の名前および場所、専門医の業務分野、または患者に必要な処置を指定することができる。さらに、薬局または専門医が患者と連絡をとってもよいように（たとえば、いつ薬剤を受け取りに行ってもいいか、または専門医との予約をいつに設定するか）、患者は、１つまたは複数の電話番号（たとえば図３５に示されるように）または他の連絡先情報（たとえば、ｅｍａｉｌアドレス）を提供することができる。
例示のために、健康管理プロバイダは、患者の処置に関連する可能性がある任意選択のサービスについて患者と話し合うことができる。この場合も、このような話し合いを通して健康管理プロバイダを誘導するために、処方マネージャ７３１０により画面が提供されることができる。図３６〜図４０は、任意選択のサービスについて患者と話し合うよう健康管理プロバイダを誘導する画面の例を示す。たとえば、画面は、図３６に示されるように、患者に特別に利用可能な、または関係がある、これらの任意選択のサービス（たとえば、患者に処方された薬剤の製造会社により提供される製品サポートサービス）を表示することができる。患者は、図４０に示されるように、ユーザデバイス７３４０を使用して、健康管理プロバイダの助けを借りて、特定のサービスを選択し、契約を結び、図３９に示されるように、これらのサービスにより必要とされる所要の内容を与えることができる。代表的な一実施形態では、任意の数の段階で、誘導画面を介して、任意選択のサービスが話し合われる、および／または表示されることができる。たとえば、任意選択のサービスは、以下でより詳細に説明されるように、処方情報の記入後、処方文書または医学的指示文書の生成および／または送信の前または後、給付金検証および／または事前承諾の前または後に話し合われることができる。
いくつかの事例では、健康管理プロバイダは、患者がユーザデバイス７３４０の中に直接情報を記入できるようにすることができる。たとえば、図３５に示される画面３５００から、患者は、自分の連絡先情報（たとえば、電話番号）を記入することができる。患者は、処方薬を得るのに好ましい特定の薬局を選択することができる。所望であれば、健康管理プロバイダがユーザデバイス７３４０を患者に手渡すとき、患者はセキュリティ手段としてある種の画面からロックアウトされ得る。たとえば、患者は、健康管理プロバイダが患者に処方薬およびその投薬量を指定する画面にアクセスすることができなくなり得る。これにより、患者が自分で処方薬の投薬量を変更する（たとえば、増やす）、または薬剤投与を変更する、または他の薬剤投与を追加するのを防止する。例示のために、ユーザデバイス７３４０上にボタンが存在する、または起動されると、ある種の画面がさらにアクセスされるのをロックするアイコンが画面のうち１つに含まれることができる。ユーザデバイス７３４０を患者に手渡す前に、健康管理プロバイダはボタンまたはアイコンを起動させることができる。患者がユーザデバイス７３４０を健康管理プロバイダに戻すと、健康管理プロバイダは、（たとえば、ユーザデバイス７３４０にユーザ名およびパスワードを入力することにより）これらの画面のロックを解除することができる。
図７を参照すると、本明細書で開示されるように、例示として、７４１１で、ユーザデバイス７３４０は、健康管理プロバイダにより、および任意選択で患者により、ユーザデバイス７３４０の中に記入された、患者に関する情報（たとえば、患者の名前、保険番号、またはユーザ名）、健康管理プロバイダに関する情報（たとえば、健康管理プロバイダの名前またはユーザ名）、および処方製品またはサービスに関する情報を含むことができるすべての情報を収集することができる。７４１３で、ユーザデバイス７３４０は、任意選択で、情報を暗号化し、（たとえば、ＨＴＴＰＳ接続を通して）情報を処方マネージャ７３１０に送信することができる。たとえば、健康管理プロバイダは、画面の１つに表示された「提出」ボタンをクリックして、ユーザデバイス７３４０に、情報を処方マネージャ７３１０に送信を開始させることができる。
限定のためではなく例示のために、図２４〜図４３を参照して、本明細書で開示されるシステムの代表的な一実施形態を使用する新規患者受入について説明される。この工程は、ＨＣＰ、職員メンバ、またはＨＣＰと１人または複数の職員メンバの組合せにより行われることができる。それに応じて、図２４〜図４３では、特に指定がない限り、ユーザがＨＣＰまたは職員メンバとすることができる。
最初に、図２４を参照すると、ユーザが新規患者ボタン２４００を選択したとき、新規患者ページ２４０２が表示される。新規患者ページ２４０２は、患者情報タブ２４０４と、保険情報タブ２４０６と、ＨＣＰ情報タブ２４０８と、診断情報タブ２４１０と、患者連絡先情報タブ２４１２と、ＨＣＰの決定および署名タブ２４１４とを含む。これら６つのタブは、新規患者受入工程の６つのステップに適用可能なウィンドウにアクセスする。代表的な一実施形態では、（図５に示される）コンピューティングデバイス５０２が第１の入力モードに入る。第１の入力モードでは、コンピューティングデバイス５０２は、ＨＣＰにより記入されたデータを受信する。限定のためではなく例示のために、図２４Ｂは、開示される主題の一実施形態による他の代表的患者情報画面を示す。
患者情報タブ２４０４を選択することにより、図２５に示される患者情報ウィンドウ２５００がオープンする。患者情報ウィンドウ２５００は、患者情報（たとえば、名前、住所など）用フィールド２５０２を含む。情報は、たとえば、キーボード５０８および／またはタッチスクリーンディスプレイ５０６を使用して、患者情報ウィンドウ２５００の中に手作業で入力されることができる。代わりに、または追加で、ユーザは、患者識別文書、たとえば、運転免許証をスキャンして情報を獲得し、かつ情報をフィールド２５０２に設定するように選択することができる。ユーザがスキャンボタン２５０４を選択したとき、図２６に示されるスキャニングポップアップ２６００が患者情報ウィンドウ２６００の上に表示される。スキャニングポップアップ２６００は、たとえば、スキャニングデバイス５０４を使用して、識別文書をスキャンする方法をユーザに指示する。ユーザは、スキャニングデバイス５０４上に文書を置き、表スキャンボタン２６０２および裏スキャンボタン２６０４を選択することにより、識別文書の表および裏をスキャンする。代表的実施形態では、スキャニングデバイス５０４は、スキャンされた識別文書の画像（複数可）をコンピューティングデバイス５０２に配送する。コンピューティングデバイス５０２は、識別文書の画像からフィールド２４０６に必要な情報のために、スキャンされた画像に対して光学式文字認識を行う。他の実施形態では、システムの異なる構成要素、たとえば、スキャニングデバイス５０４が、光学式文字認識を行う。さらに、または代わりに、情報は、光学式文字認識以外により抽出されることができる。たとえば、代表的な一実施形態では、バーコード、または他の視覚的データ符号化要素が、システムにより読み取られる。さらに他の実施形態では、識別文書内の非視覚的データ記憶要素、たとえば、磁気ストライプ、ＲＦＩＤチップなどが、患者情報を抽出するために読み取られる。抽出された情報は、フィールド２５０２に自動的に設定するために、本明細書で開示されるシステムの代表的な一実施形態と共に使用される。代表的な実施形態では、システムは、取り込まれた識別文書の画像を記憶し、患者情報ウィンドウ２５００に画像のうち１つまたは複数を表示する。さらに他の実施形態では、情報は、電子医療記録システムからシステムの中にインポートされることができる。
患者プロファイルがシステム内にすでに存在する患者情報を、手作業であれ、ＩＤスキャンを介してであれ、ユーザが記入しようと試みる場合、複製プロファイルポップアップ２７００が表示される。既存の患者プロファイルの識別情報がポップアップ２７００に表示される。ユーザは、識別された患者プロファイルを使用する、または既存のプロファイルを無視して、引き続き新規患者プロファイル作成するように選択することができる。
ユーザが、保険情報タブ２４０６を選択する、または患者情報ウィンドウ２５００から継続することを選択するとき、図２８に示されるように、保険ウィンドウ２８００が表示される。保険ウィンドウ２８００は、本明細書で保険データとも呼ばれる患者の保険情報用フィールド２８０２を含む。より具体的には、保険ウィンドウ２８００は、処方保険情報、医療保険情報、および処方保護プラン情報用フィールドを含む。すべての患者がすべてのタイプの保険を有するわけではなく、一部の患者が、特定のタイプの保険のうち２つ以上を有することができる。情報は、たとえば、キーボード５０８および／またはタッチスクリーンディスプレイ５０６を使用して、保険ウィンドウ２８００の中に手作業で入力されることができる。代わりに、または追加で、ユーザは、保険識別文書（複数可）をスキャンして情報を獲得し、かつ情報をフィールド２８０２に設定するように選択することができる。患者識別文書のスキャニングと同様に、ユーザが保険識別文書をスキャンするように選択するとき、図２９に示されるスキャニングポップアップ２９００が保険情報ウィンドウ２８００の上に表示される。スキャニングポップアップ２９００は、たとえば、スキャニングデバイス５０４を使用して、特定の識別文書をスキャンする方法をユーザに指示する。ユーザは、スキャニングポップアップ２９００により指示されるように、識別文書の表および裏をスキャンする。代表的な実施形態では、スキャニングデバイス５０４は、スキャンされた識別文書の画像（複数可）をコンピューティングデバイス５０２に配送する。コンピューティングデバイス５０２は、画像からフィールド２８０２に必要な情報のために、スキャンされた画像に対して光学式文字認識を行う。他の実施形態では、システムの異なる構成要素、たとえば、スキャニングデバイス５０４が、光学式文字認識を行う。さらに、所望であれば、情報は、光学式文字認識以外により抽出されることができる。たとえば、代表的な一実施形態では、バーコード、ＱＲコード（登録商標）、または他の視覚的データ符号化要素が、システムにより読み取られる。さらに他の実施形態では、識別文書内の非視覚的データ記憶要素、たとえば、磁気ストライプ、ＲＦＩＤチップなどが、患者情報を抽出するために読み取られる。抽出された情報は、フィールド２８０２に自動的に設定するために、システムにより使用されることができる。代表的な実施形態では、システムは、取り込まれた識別文書の画像を記憶し、保険ウィンドウ２８００に画像のうち１つまたは複数を表示する。
次に進むように選択することにより、図３０に示されるように、ＨＣＰ情報ウィンドウ３０００が表示される。ユーザは、プルダウンメニューから、サービスの場所、および患者のＨＣＰを選択することができる。選択が行われた後、選択されたＨＣＰの詳細な情報がＨＣＰ情報ウィンドウ３０００に表示される。
図３１は、ユーザが、ＨＣＰ情報ウィンドウ３０００から次に進むよう選択した後に表示される診断結果ウィンドウ３１００のスクリーンショットである。情報、たとえば、処方されるべき薬剤に関する指示、安全性について考慮すべき点などが、診断結果ウィンドウ３１００に表示される。また、薬剤に関する完全な処方情報へのリンク３１０２が表示される。代表的な実施形態では、処方するＨＣＰの専門が、ＨＣＰのプロファイルに基づき、プルダウンメニュー３１０４で事前に選択される。他の実施形態では、専門が事前に選択されず、ユーザは、プルダウンメニュー３１０４から専門を選択しなければならない。代表的な実施形態では、プルダウンメニュー３１０４で利用可能な専門は、処方されるべき薬剤が処方される専門に限定される。他の実施形態では追加の専門が利用可能であってもよい、および／または特定のＨＣＰの専門が、選択のために利用可能な専門だけであってもよい。図３２〜図３４では、説明のためだけに専門としてリウマチが選択され、代表的な実施形態をリウマチに限定することは意図されない。ＨＣＰの専門が選択された後、診断結果ウィンドウ３１００は、図３２に示されるように展開される。患者の診断結果が、薬剤が処方されてもよい診断結果のリスト３２００から選択される。図３３に示されるように、ユーザは、プルダウンメニュー３２０２から投薬方式を選択し、本明細書で開示されるシステムは、選択された診断結果および投薬方式に対して医薬品の詳細を設定することができる。例示的実施形態では、送達デバイスとも呼ばれる、利用可能な投薬方式が、注射器およびインジェクションペンを含む。他の実施形態では、任意の他の適切な投薬方式が、選択可能および／または挿入可能である場合がある。適切な投薬方式は、たとえば、注入ポンプ、インジェクションペン、注射器、丸剤、カプセル、座薬、摂取可能な液体、局所適用（クリーム、ローション、パッチなどを含む）、ポンプ、装着可能ポンプなどを含むことができる。代表的な実施形態では、ユーザは、処方された製品に対して使用回数を記入する。他の実施形態では、使用回数は、患者データ、選択された投薬、および／または選択された診断結果に基づき、システムにより選択されることができる。ユーザはまた、プルダウンメニュー３３００から、処方されるべき量を選択し、処方されるべき再調剤の回数をボックス３３０２に挿入する。限定のためではなく例示のために、図３３Ｂは、開示される主題の一実施形態による他の代表的な診断情報画面を示す。
システムのある種の実施形態が、特定の事例／患者の詳細に基づき、重要な情報をユーザに通知する、追加情報を要求する、および／またはユーザに利用可能なオプションを制限する。このような制限のトリガは、処方されている特定の医薬品に基づき変わることができる。トリガは、たとえば、患者の年齢、患者の体重、患者の成人／若年状態などを含む。たとえば、患者のプロファイルおよび／または診断結果に基づき、患者が若年であると判断されたとき、システムは、追加情報、たとえば患者の体重を要求する。特定の情報は、処方されている特定の医薬品に基づき変わることができる。代表的な実施形態では、システムは、若年に医薬品を処方するための示唆および／または要件に基づき、ユーザに利用可能な処方オプションを制限する。他の実施形態では、および／または他の医薬品については、システムは、利用可能な処方オプションを制限することなくユーザに警告することができる、ユーザに警告しなくてもよい、および／または他の利用可能なオプションを制限することなく処方オプションを示唆してもよい。
所望であれば、システムは、列挙された診断結果以外の診断結果をユーザが記入することを許可することができる。図３４に示されるように、ユーザが診断結果として「その他」を選択したとき、診断結果ウィンドウ３１００の上にポップアップウィンドウ３４００が表示され、承認された指示については薬剤の処方情報を参照するようにユーザに忠告する。代表的な実施形態では、ポップアップウィンドウ３４００をクローズした後、ユーザは、「その他」の診断結果を記入し、次に進むことができる。他の実施形態では、システムは、診断結果ウィンドウ３１００に列挙された以外の診断結果の記入を禁止することができる。同様に、ユーザが、選択可能な投薬選択肢のうち１つ以外の投薬を記入するように選択したとき、ポップアップウィンドウ（示されていない）が、承認された投薬については薬剤の処方情報を参照するようにユーザに警告する。代表的な実施形態では、ポップアップウィンドウをクローズした後、ユーザは、「その他」の投薬を記入し、次に進むことができる。他の実施形態では、システムは、診断結果ウィンドウ３１００に列挙された以外の投薬の記入を禁止することができる、またはユーザに警告を提供することができない。
本明細書で具体化されるように、いくつかの医薬品および／または専門に関連して、処方が製品の新規処方であるか、継続的処方であるかに応じて、異なる指示、要件、投薬などが存在してもよい。たとえば、専門がリウマチである場合、本明細書で開示されるシステムは、ドロップダウンを提供して、新規、継続という選択肢のうち一方を選ぶことができる。本明細書で開示されるシステムは、処方製品が処方されている診断結果を選択するためのオプションを提供することができる。診断結果は、専門、医薬品などに応じて変わることができる。たとえば、リウマチの専門では、システムの実施形態が、複数選択チェックボックスを使用して、「慢性関節リウマチ（７１４．０）」、「乾癬性関節炎（６９６．０）」、「多関節若年性製特発性関節炎［ＪＩＡ］（７１４．３０）」、「強直性脊椎炎（７２０．０）」、および「その他（コードを含む）：＿＿＿＿＿」という診断結果オプションを選択するオプションを提供することができる。
さらに、患者の年齢が、指示、処方要件、投薬などに影響を及ぼす可能性がある。たとえば、システムは、「多関節若年性製特発性関節炎［ＪＩＡ］（７１４．３０）」が選択された場合、ユーザが任意の他の診断結果情報を選択することを防止することができる。診断結果が多関節若年性製特発性関節炎［ＪＩＡ］（７１４．３０）である場合、システムは、ユーザが患者の体重をポンドで記入するように促すことができる。診断結果が多関節ＪＩＡであり、患者の体重が１５ｋｇ（３３ポンド）から＜３０ｋｇ（６６ポンド）の間であり、患者が４歳以上である場合、投薬および回数が、自動的に設定され、編集可能とすることができない。量および再調剤の回数がユーザにより選択可能とすることができる。ユーザが「任意の他の投薬」チェックボックスを選択した場合、システムは、「承認された投薬計画については、［処方製品の名前］処方情報を参照してください。完全な処方情報についてはこちらをクリックしてください」と明言する警告メッセージ付きのポップアップを表示することができる。完全な処方情報リンクをクリックすると、完全な処方情報への外部リンクが、新規ウィンドウにオープンされることができる。ユーザがポップアップでＯＫを選択した場合、システムはポップアップをクローズし、ユーザが任意の他の投薬を記入することができるようにすることができる。システムは、データベース内に、照会にオフラベルとしてフラグを立てることができる。ユーザが次に進むボタンをクリックした場合、システムは照会を保存することができる。システムは、必須フィールドが記入されていることをチェックし、照会状態を「患者受入−進行中」として保持することができる。
さらに、または代わりに、たとえば、ユーザが、体重が≧３０ｋｇ（６６ポンド）であると記入し、診断結果が、慢性関節リウマチ、強直性脊椎炎、乾癬性関節炎、または多関節ＪＩＡである場合、本明細書で開示されるシステムは、投薬方式を選択するようにユーザを促すことができる。システムは、適用可能な投薬方式を備える必須ドロップダウンを提供することができる。利用可能な投薬方式は、処方されている特定の薬剤に応じて変わることができ、注射器、ペン、錠剤、液体などのうち１つまたは複数を含むことができる。投薬方式が選択された後、システムは投薬および回数に自動的に設定することができる。フィールドはユーザによる編集を許さない。量および再調剤の回数がユーザにより選択可能とすることができる。ユーザが「任意の他の投薬」チェックボックスを選択した場合、システムは上記で説明されたように、完全な処方情報への外部リンクを含む警告メッセージ付きのポップアップを表示することができ、上記で説明されたように次に進むことができる。
さらに、本明細書で具体化されるように、ユーザが診断結果情報を完成する前に他のヘッダを選択した場合、システムは動作を確認するために、ポップアップをユーザに提供することができる。ポップアップは、たとえば、「はい」および「いいえ」ボタン付きの「照会情報を保存する」と読み取ることができる。ユーザがはいのボタンをクリックした場合、システムは、ユーザにより記入された情報を保存し、照会の状態を「患者受入−進行中」として保持することができる。ユーザがいいえのボタンをクリックした場合、システムは、情報を保存することなくセッションを終了することができる。
図３５は、ユーザが診断結果ウィンドウ３１００から次に進んだ後に表示される患者連絡先情報ウィンドウ３５００のスクリーンショットである。患者連絡先情報ウィンドウ３５００の中には、患者の電話番号および代わりの電話番号が記入される。代表的な一実施形態では、電話番号の１つまたは複数は、システムに記憶された患者情報、たとえば患者のプロファイルに基づき事前に書き込まれる。
代表的な実施形態では、ユーザは、任意選択で、システムを使用して、患者連絡先情報ウィンドウを完成した後、処方されている医薬品に関連する任意選択のサービスに関する情報を表示することができる。他の実施形態では、任意選択のサービス情報が、異なる工程段階で提示されることができる。図３６は、ユーザが患者と任意選択のサービスについて話し合う次の画面を使用したいかどうか尋ねる選択画面を示す。他の実施形態が、患者と任意選択のサービス情報について話し合うかどうかに関するオプションをユーザに提示することなく図３７に直接進むが、患者は、どんな任意選択のサービスも受け入れるまたは検討することを断ることができる。図３７〜図４０は、患者が見直しおよび完成するための任意選択のサービスページのスクリーンショットである。患者がさまざまな任意選択のサービスページを完成し、見直す間の期間が、患者対話期間と呼ばれることができる。代表的な実施形態では、患者対話期間中に、（図５に示される）コンピューティングデバイス５０２は、コンピューティングデバイス５０２がＨＣＰにより記入されたデータを表示するのを禁止された、患者対話モードとも呼ばれる第２のモードに入る。それに応じて、患者はＨＣＰにより記入された機密の、および／または医療用の情報を見ることができない。
図３６で、ユーザが患者と任意選択のサービスについて話し合うことを選択したとき、（図３７に示される）ウェルカムページ３７００が患者に対して表示される。ウェルカムページ３７００は、次ページの目的に関して簡潔に説明する、すなわち、任意選択のサービスを患者に提供し、患者が任意選択のサービスの見直しおよび／または契約を結ぶことを開始するかどうかを選択することができるようにする。
図３８は、ウェルカムページ３７００上で開始することを選択した後に、患者に示される任意選択のサポートサービスプログラムに関する代表的情報ページ３８００のスクリーンショットである。他の実施形態では他の任意選択のサービスが、追加で、または代わりに、患者に提示されることができる。情報ページ３８００は、サポートサービスプログラムから受け取られることができる利益を含み、患者に処方された薬剤に関する追加情報へのリンク３８０２を提供する。利益は、たとえば、登録された看護師による医薬品のトレーニング、注射器および／または他の医療用品目の廃棄、継続的情報サービス、ならびに医薬品に関して質問するための、登録された看護師への営業時間外のアクセスを含むことができる。限定のためではなく例示のために、図７８は、開示される主題の一実施形態による代表的な看護師注入トレーニングリクエストのフォームを示す。
ユーザがサポートサービスプログラムに登録することを選ぶ場合、情報ページ３８００の上に、図３９に示される同意ポップアップ３９００が表示される。同意ポップアップ３９００は、サポートサービスを提供するサードパーティへの健康情報の開示を患者が同意または拒否することができるようにする。限定のためではなく例示のために、図３９Ｂは、開示される主題の一実施形態による他の代表的な同意ポップアップを示す。患者が開示に同意した場合、図４０に示されるように、システムは、患者に対するサポートサービスプログラムの署名契約ページ４０００を表示する。代表的な実施形態では、患者情報フィールド４００２の少なくとも一部が、上記で説明されたように、作成された患者のプロファイル情報に基づき、システムにより事前に書き込まれる。システムにより収集されたのではなく、サポートサービスプログラムへの登録に必要な追加情報が、患者により手作業で記入される。所望であれば、サポートサービスプログラムへの登録は、システムの外部で、たとえば、サポートサービスグループのウェブサイトを通して行われる。このような実施形態では、システムは、別個のウィンドウ、プログラム、タブなどに適切な登録ページをオープンすることができる、または登録ページがシステム内部に統合されたように見えるように、システム内部に登録ページをオープンすることができる。
代表的な実施形態では、患者に処方された医薬品の製造業者により、任意選択のサービスが提供される。他の実施形態では、１つまたは複数のサードパーティにより提供されるサービスが、追加で、または代わりに、システムを使用して患者に提供されることができる。
どんな所望の任意選択のサービスも登録完了した後に、またはこのようなどんなサービスの登録も拒否した後に、受入工程がＨＣＰまたは事務所職員ユーザで再開される。受入工程を継続するために、ＨＣＰまたは事務所職員ユーザは、患者対話期間が終了したことを示す。代表的な実施形態では、ユーザは、自分のユーザ名およびパスワードを再記入して、任意選択のサービスを患者が見直すことを常に把握し続ける必要がある。図４１は、次に表示されるＨＣＰの決定および署名ウィンドウ４１００のスクリーンショットである。ユーザは、確認セクション４１０２でＨＣＰに関するある種の情報が正しいことを確認する。ユーザはまた、患者の任意の既知の薬剤アレルギーをアレルギーセクション４１０４に記入することができる。処理セクション４１０６で、ユーザは、代用を可能にするかどうかを選択することができる。さらに、ユーザは、作成されている処方が保持される、すなわち調合されないこと、および処方に基づき給付金検証だけが行われるよう選択することができる。他の任意選択のサービスもまた、処理セクション４１０６で選択されることができる。たとえば、医薬品が注入可能な薬剤である代表的な実施形態では、ユーザは、任意選択で、登録された看護師による患者の注入トレーニングを要求することができる。
上記で説明されたように、患者受入手順が、各ステップに対して１組の画面に分割された、いくつかの別個のステップを含むことができ、「患者情報」、「保険情報」、「ＨＣＰ情報」、「診断結果情報」、「患者の連絡先情報」、および「ＨＣＰの決定および署名」という一般的カテゴリを含む。代わりに、患者受入手順は、より少ない数の別個のステップにグループ化されることができる。たとえば、患者受入は、「患者情報」、「保険情報」、「ＨＣＰ情報」、および「診断結果情報」という一般的カテゴリに分割されることができる。この代替実施形態では、４つの別個のステップが、上記で説明された実施形態で獲得されたのと同じ情報の獲得を含むことができる。さらに、医学的指示／処方の生成に関連して以下でより詳細に説明されるように、代表的な一実施形態では、ＨＣＰの署名は、患者受入と同時に必要とされるわけではない。
上記で指摘されたように、（たとえば、限定することなく、１０、７３１０、および１１２として図で描かれる、処方マネージャのさまざまな実施形態を含む）処方マネージャはまた、単独で、または（たとえば、限定することなく、６０、５００、５２２、および１１４として図で描かれる、ユーザデバイスのさまざまな実施形態を含む）１つもしくは複数のユーザデバイスと組み合わせて、給付金の検証（３１）を管理することができる。たとえば、給付品検証リクエストが、患者受入（２１）中に獲得された情報に基づき生成されることができ、処方情報を含む。システムは、処方照会付き、またはなしで、給付金検証リクエストの形で、「給付金検証者」に情報をルーティングすることができる。代表的な一実施形態では、たとえば、給付金検証（３１）は、処方文書または医学的指示文書の生成（４１）前に行われることができる。ある種の実施形態では、医学的指示／処方文書は、本明細書で説明されるように、給付金検証工程の少なくとも一部分の前に生成されることができる。
代表的な一実施形態では、「給付金検証者」は「薬局受信者」とすることができる。薬局受信者は、たとえば、給付金検証リクエストを含む、ＨＣＰにより提出された情報を受信することができる。たとえば、代表的な一実施形態では、薬局受信者は、１つまたは複数のユーザデバイスを介して処方マネージャにアクセスして、ＨＣＰにより提出された情報を受信することができる。代わりに、処方マネージャは、たとえば、ファックス、安全なｅｍａｉｌなどを介して、情報を薬局受信者に送信することができる。薬局受信者は、たとえば、ライセンスを受けた薬局（ライセンスを受けた薬局が処方を調合する薬局であっても、なくても）、薬局サービス会社、薬局サポート会社、および／または薬局仲介者とすることができる。薬局受信者は、給付金を検証し、代表的な一実施形態では、どんな事前承諾（ＰＡ）要件も識別することができる。薬局受信者は、本明細書で開示される医学的処置調整システムを介して、ＨＣＰに給付金検証要約（および代表的な一実施形態では、患者の保険業者により必要とされる適切なＰＡフォーム）を電子的に提供することができる。医学的処置調整システムは、給付金検証および／またはＰＡフォームの利用可能性をＨＣＰに通知するように構成されることができる。このような通知は、ｅｍａｉｌ通知、ＳＭＳテキスト通知、アイコン、警報、電話の呼出し、または医学的処置調整システム内部の状態の変化からなる優先的選択のフォームの形とすることができる。ＰＡフォームは、ＰＡフォームをＨＣＰに利用可能にする任意の適切な方法により、ＨＣＰに提供されることができる。たとえば、ＰＡフォームは、システム内にＰＡフォームを置き、かつＰＡフォームを患者、ＨＣＰ、および／もしくは出来事に関連づけることにより、ならびに／またはＰＡフォームをＨＣＰによりダウンロードされるように利用可能にすることにより、薬局受信者に関連づけられたコンピューティングデバイスからＨＣＰに関連づけられたコンピューティングデバイスに送信することにより、利用可能にされることができる。さらに、本明細書で具体化されるように、異なるエンティティが、本明細書で説明される仕事を行うことができる。たとえば、一方の薬局受信者が、給付金検証を行うことができ、一方では、第２のエンティティが任意の必要なＰＡを識別することができる。
本明細書で具体化されるように、薬局受信者は、給付金検証要約を生成して、患者の保険プロバイダにより患者に提供される給付金を要約することができる。要約は、控除免責金額（複数可）、自己負担分金額、有効期間の範囲、３カ月供給処方がカバーされ、適用可能な控除免責金額または自己負担分額であるかどうか、オンラインおよび／またはメール指示処方の利用の可能性、保険プロバイダの好ましい、および／または必須の薬局、事前承諾の継続期間、処方の期間制限、処方を調合する薬局の制約、および／または患者の保険の担保範囲に関連する他の関連情報を含むことができるが、これらに限定されない。給付金検証要約に含まれる情報は、保険プロバイダが薬局受信者に提供する情報の量に基づき変わることができる。代表的な一実施形態では、薬局受信者は、可能である場合には、給付金検証要約を生成し、給付金検証要約をＨＣＰまたは患者に送信する。他の実施形態では、給付金検証要約は生成されなくてもよい。さらに、本明細書で具体化されるように、異なるエンティティが、本明細書で説明される仕事を行うことができる。たとえば、一方の薬局受信者が、給付金検証を行うことができ、一方では、第２の薬局受信者が任意の必要なＰＡを識別することができる。
本明細書でさらに具体化されるように、ＨＣＰおよび／または患者は、たとえば、ｅｍａｉｌ通知、ＳＭＳテキスト通知、アイコン、警報、電話の呼出し、またはシステム内部の状態の変化などを介して、給付金検証要約および／またはＰＡフォームの利用の可能性について通知されることができる。図２２に戻り参照すると、本明細書で具体化されるように、ＰＡフォームおよび／または給付金検証（ＢＶ）要約が、提出された照会に応答して、薬局受信者（複数可）からいつ受信されたかを、未処理の照会セクション２２０６内部の事例の状態が示す。さらに、ＰＡフォームが受信されたが、まだ完成していない事例に対する未処理の照会セクション２２０６の未決定の措置の列は、以下でより詳細に説明されるように、未決定の措置が、ＰＡフォームを記入することであることを示す。
図５１〜図６４は、給付金検証リクエストウィンドウ５１００のさまざまな代表的タブのスクリーンショットを含む。給付金検証リクエストウィンドウ５１００は、ユーザが新規患者を登録した後、またはユーザが既存の患者を選択した後に、ユーザに提示されることができる。給付金検証リクエストウィンドウ５１００は、患者情報タブ５１０２と、保険情報タブ５１０４と、診断結果情報タブ５１０６と、トレーニング／サポートタブ５１０８と、同意タブ５１１０とを含む。同意タブ５１１０は、図６１および図６２に示されるように、患者の同意タブ５１１２と、医者の同意タブ５１１４とをさらに含む。
すべての情報が給付金検証リクエストウィンドウ５１００の中に入力され、患者および医者が同意フォーム５１２０および５１２２を作り上げると、ユーザは、提出ボタン５１３０を選択することができる。提出ボタン５１３０を選択することにより、ライセンスを受けた薬局および／または同等のプロバイダに給付金検証リクエストを送信する。給付金検証リクエストは、給付金検証リクエストウィンドウ５１００の情報を含む。図６３に示されるように、給付金検証リクエストウィンドウ５１００はまた、医者情報タブ５１６０を含むことができる。医者情報タブは、医者情報、および医者の署名のための署名スペース５１６２だけでなく、提出ボタン５１３０も含む。提出ボタン５１３０が選択された後、図６４に示されるように、提出確認５１７０が表示される。
図６５は、給付金検証リクエストを受信したときに薬局受信者により見られる、給付金検証ウィンドウ６５００のスクリーンショットである。ユーザが見て、給付金検証情報（たとえば、控除免責金額、現金支払費用など）を給付金検証タブ６５０２の中に入力することができる。文書追加ボタン６５０４を選択することにより、ユーザは、ＨＣＰに送信するために、適切な事前承諾（ＰＡ）フォームを添付することができる。所望である、および／または適切な場合、本明細書で開示されるシステムは、給付金検証リクエスト内の情報のうち少なくとも一部に基づき、適切なＰＡフォームを自動的に識別し、添付することができる。給付金検証情報が入力され、適切なＰＡフォームが添付されると、ユーザが、ＰＡ提出ボタン６５０６を選択し、ＰＡフォームがＨＣＰに送信される。代表的な一実施形態では、ＨＣＰに送信されるＰＡフォームは、データベース、たとえば、データベース２０（図１に示される）に記憶された複数のＰＡフォームから選択される。異なる保険プロバイダが、典型的には異なる別個のＰＡフォームを有するので、各ＰＡフォームが、異なる保険プロバイダに関連づけられることができる。
限定のためではなく例示のために、図７９〜図８１は、本明細書で開示されるシステムに給付金検証者がアクセスすることに関連する、給付金検証者（たとえば、薬局受信者）のための代表的な画面を示す。図７９は、開示される主題の一実施形態による代表的なダッシュボード画面を示す。図８０は、開示される主題の一実施形態に従って、ＰＡフォームを選択するための代表的な画面を示す。図８１は、開示される主題に従って、薬局の詳細を記入するための代表的な画面を示す。
上記で指摘されたように、（たとえば、限定することなく、１０、７３１０、および１１２として図で描かれる、処方マネージャのさまざまな実施形態を含む）処方マネージャは、単独で、または（たとえば、限定することなく、６０、５００、５２２、および１１４として図で描かれる、ユーザデバイスのさまざまな実施形態を含む）１つもしくは複数のユーザデバイスと組み合わせて、患者のためのある種の所定のフォーム、たとえば、事前承諾フォームの選択、設定、およびリリーズ（５１）を管理することができる。
本明細書で開示されるように、例示として、ユーザデバイス７３４０から情報を受信すると、処方マネージャ７３１０は、任意選択で、情報を復号することができる。７４２１で、処方マネージャ７３１０は、処方製品またはサービスに対する１つまたは複数の保険承諾フォームを選択するだけでなく、保険プロバイダ（複数可）により必要とされる、従われるべき手順を決定して、事前承諾を得ることができる。異なる保険プロバイダまたは健康管理プロバイダが、異なる処方製品またはサービスに対して異なる承諾フォームおよび／または手順を使用することがある。処方マネージャ７３１０は、たとえば、製品またはサービスを処方する健康管理プロバイダの識別、健康管理プロバイダが提携した施設（たとえば、病院またはクリニック）、患者に処方された製品またはサービスのタイプ、または患者の保険プロバイダに基づき、処方マネージャ７３１０に記憶された承諾フォームから、特定の処方製品またはサービスに対して適切な承諾フォームを選択することができる。本明細書で開示されるように、例示として、処方マネージャ７３１０は、７４１３でユーザデバイス７３４０から送信された情報から、必要とされる情報の一部を決定することができる。たとえば、健康管理プロバイダおよび患者の識別、ならびに患者に処方された製品またはサービスのタイプは、７４１３でユーザデバイス７３４０から受信された情報から抽出されることができる。さらに、処方マネージャ７３１０は、健康管理プロバイダおよび患者のユーザアカウントに記憶された情報から、必要とされる情報の一部を取り出すことができる。たとえば、健康管理プロバイダが提携した施設は、健康管理プロバイダのアカウントから、または７４１３でユーザデバイス７３４０により送信された情報から取り出されることができる。患者の保険プロバイダは、患者の識別に基づき決定された患者のアカウントから取り出されることができる。
患者が複数の保険プロバイダを有する場合、各保険プロバイダが、自分自身の承諾フォームおよび／または手順を必要とすることができる。本明細書で具体化されるように、処方マネージャ７３１０は、処方マネージャ７３１０に対して記憶された承諾フォームから、複数の保険承諾フォーム（たとえば、患者の各保険プロバイダに１つ）を選択することができる。
各保険承諾フォームが任意の数のフィールドを含むことができ、各フィールドが、書き込まれる必要がある異なる情報に対応する。本明細書で開示されるように、例示として、７４２３で、処方製品またはサービスに対して選択された各承諾フォームに対して、処方マネージャ７３１０は、処方マネージャ７３１０に対する健康管理プロバイダのユーザアカウントおよび患者のユーザアカウントからの情報、ユーザデバイス７３４０から受信された情報、処方された製品の製造業者または販売者により提供される情報、または処方サービスプロバイダにより提供される情報を含むことができる、処方マネージャ７３１０に利用可能な情報に基づき、フォーム内の必要なフィールドに自動的に記入することができる。さらに、処方マネージャ７３１０は、電子医療記録システムにアクセスすることができる場合、電子医療記録システムから関係のある情報（たとえば、患者の記録）を取り出すことができる。
図４３は、保険承諾フォーム例のページを示す。たとえば、フォームは、患者の情報に関するセクション、健康管理プロバイダの（すなわち、処方者の）情報に関するセクション、患者の保険情報に関するセクション、および処方された製品またはサービスに関連する２つのセクションを含むことができる。各セクションが、いくつかのフィールドを含むことができる。たとえば、「患者情報」セクションの下には、患者の名前、ミドルネームのイニシャル、名字、生年月日、性別、住所、電話番号、および薬剤アレルギーに対応するフィールドが存在する。「保険情報」セクションの下には、患者の主保険および副情報、たとえば、電話番号、カード保有者識別番号、グループ番号、保険契約者名などに対応するフィールドが存在する。これらのフィールドに書き込むために必要な情報は、データストア（たとえば、データストア７３１２および／またはデータストア７３６０）から、たとえば、患者のユーザアカウント、または電子医療記録システムからの患者の記録、または７４１３でユーザデバイス７３４０から受信された情報から取り出されることができる。次いで、情報は、システム７３００により（たとえば、具体的には処方マネージャ７３１０により）承諾フォームの中に自動的に設定される。（たとえば、複数の保険プロバイダに対応する）複数の承諾フォームの場合、処方マネージャ７３１０は、（たとえば、各承諾フォームの）適切なフィールドに自動的に設定することができる。さらに、健康管理プロバイダ（すなわち、処方者）、患者の診断結果、処方薬などに関連するフィールドが存在する。これらのフィールドに記入するために必要な情報は、たとえば、健康管理プロバイダのユーザアカウント、または７４１３でユーザデバイス７３４０から受信された情報、または薬剤の製造業者または販売者により供給された情報から取り出されることができる。
本明細書で開示されるように、例示として、７４２５で、１つまたは複数の保険承諾フォームの記入がなされると、処方マネージャ７３１０は、任意選択で、（たとえば、患者のプライバシ保護のために）フォーム（複数可）を暗号化し、完成したフォーム（複数可）を、健康管理プロバイダに関連づけられたユーザデバイス７３４０に送信することができる。必要に応じて、保険承諾フォーム（複数可）が選択されることができ、患者が依然として健康管理プロバイダに相談している間に、完成したフォーム（複数可）を健康管理プロバイダが受信することができるように、十分な時間がたった後に、完成したフォーム（複数可）がユーザデバイス７３４０に返送されることができる。この場合、健康管理プロバイダは、必要に応じて、患者とフォーム（複数可）を見直し、フォーム（複数可）署名することができる。またあるときには、完成したフォーム（複数可）は、患者が健康管理プロバイダに相談した後に（たとえば、数時間、または１日以内に）ユーザデバイス７３４０に返送されることができる。さらに、処方マネージャ７３１０は、各承諾フォームが完全に記入がなされ、フォームに記入された情報の綴りが適切である、または正しいことを保証するために、品質／綴りチェックを行うことができる。７４１６で、ＨＣＰは、たとえば、「保存」ボタンをクリックすることにより、設定された保険承諾フォームを保存することができ、このとき、事前承諾フォームがデータストア７３１２に保存されることができる。
本明細書で開示されるように、例示として、７４１５で、完成したフォームが、見直しおよび署名のために、ユーザデバイス７３４０上で健康管理プロバイダに提示されることができる。完成した保険承諾フォームを見直すために、健康管理プロバイダは、自分のアカウントで処方マネージャ７３１０にログインすることができる。（すなわち、さまざまな患者に処方された製品またはサービスに対応する）すべての未決定の保険承諾フォームが、健康管理プロバイダのアカウントで探し出されることができる。健康管理プロバイダは、見直しおよび署名のために、特定の保険承諾フォームを選択することができる。
例示のために、処方マネージャ７３１０のユーザインタフェースの一部として、見直しおよび署名の工程を通して健康管理プロバイダを誘導する画面が処方マネージャ７３１０により提供されることができる。たとえば、図４２は、完成した保険承諾フォームの中に（たとえば、健康管理プロバイダのアカウントで、またはユーザデバイス７３４０上に記憶された）電子署名を挿入するために、健康管理プロバイダがユーザ名およびパスワードを記入することができる画面の一例を示す。管轄区（たとえば、州）が保険承諾フォームに電子署名が使用されるのを許可しないことがある。このような場合、健康管理プロバイダは、フォームの物理的コピーを印刷し、紙の上でフォームに署名する必要がある場合がある。
本明細書で開示されるように、例示として、７４１７で、健康管理プロバイダは、署名された保険承諾フォームを処方製品販売者７３２０（たとえば、患者により選択された薬局）または処方サービスプロバイダ７３３０に送信することができる。任意選択で、健康管理プロバイダは、署名された保険承諾フォームと一緒に、他の関係がある文書、たとえば、患者のカルテを送信することができる。フォーム、および任意選択で追加文書が、任意の適用可能な手段を使用して、たとえば、ファックスまたはｅｍａｉｌを介して送信されることができる。
例示のために、処方マネージャ７３１０のユーザインタフェースの一部として、署名された保険承諾フォームを適切な受信者に送信するように健康管理プロバイダを誘導する画面が、処方マネージャ７３１０により提供されることができる。図４６〜図４７は、署名された保険承諾フォームをファックスするように健康管理プロバイダを誘導する画面の例を示す。たとえば、図４６に示される画面４６００から、健康管理プロバイダは、必要に応じて、署名された保険承諾フォームと一緒に送信されることができる１つまたは複数の追加文書を指定することができる。図４７に示される画面４７００から、健康管理プロバイダは、署名されたフォームおよび追加文書をファックスするための受信者（たとえば、薬局または保険プロバイダ）のファックス番号を記入することができる。
たとえば、健康管理プロバイダが、処方薬に対する、完成した、署名された承諾フォームを、システム７３００の一部である薬局（すなわち、処方製品販売者７３２０）または保険プロバイダに送信する状況が参照される。このとき、本明細書で具体化されるように、例示として、薬局は、承諾フォームを患者の保険プロバイダに送付することができる。患者の保険プロバイダが処方薬を承認する場合、保険プロバイダは、薬局に承認を通知することができる。次いで、薬局は、処方を調合し、患者が薬局で薬剤を受け取ることができるように、患者に連絡することができる（たとえば、患者により提供された電話番号を使用して患者に電話をかける、または処方マネージャ７３１０を通して患者に通知する）。
患者の保険プロバイダが、システム７３００の一部ではない、指定された薬局（すなわち処方製品販売者７３８０）を有することができることがある。しかしながら、患者が保険プロバイダから支払給付金を受け取るためには、患者は、保険プロバイダが指定した薬局から実際の薬剤を得る必要がある場合がある。この場合、保険プロバイダが、システム７３００の一部である１つの薬局または保険プロバイダ（すなわち、処方製品販売者７３２０）から処方および／または承諾フォームを受け取ったとしても、患者の保険プロバイダは、システム７３００の一部ではない他の薬局（たとえば、保険プロバイダ自身が指定した薬局）に承認を送信することができる。次いで、保険プロバイダが指定した薬局は、処方を調合し、患者に通知することができる。患者の保険プロバイダが薬剤の代金を支払うことを患者が望む場合、患者は、保険プロバイダが指定した薬局で薬剤を受け取る必要がある場合がある。当然のことながら、患者には自分で処方の代金を支払うという選択肢が常にあり、この場合、患者は、どの薬局から薬剤を購入するかを自由に選ぶことができる。
代表的な実施形態では、事前承認（５１）は、処方文書または医学的指示文書の生成（４１）前に行われることができる。ある種の実施形態では、医学的指示／処方文書は、本明細書で説明されるように、事前承諾工程の少なくとも一部分の前に生成されることができる。
さらに、代表的な一実施形態では、処方マネージャ（たとえば、処方マネージャ１０または７３１０）の１つまたは複数のプロセッサが、上記で説明されたように、適切な事前承諾フォームを自動的に選択するように構成されることができる。代わりに、代表的な一実施形態では、事前承諾フォームは、処方マネージャ１０を使用して、（たとえば、薬局受信者などの）給付金検証者により選択されることができる。代表的な一実施形態では、給付金検証者による事前承諾フォームの選択は、本明細書で開示されるように、一連の画面により誘導されることができる。たとえば、給付金検証者は、システム７３００にログインすることができ、処方マネージャは、患者プロバイダ情報に基づき事前承諾フォームを選択するためのユーザインタフェースを提供することができる。
たとえば、限定することなく、照会および処方フォームが薬局受信者に提出された後、薬局受信者は、患者の保険給付金を検証することができ、任意の事前承諾（ＰＡ）要件を識別する。所望であれば、薬局受信者は、処方に対する試験請求を準備し、患者の保険プロバイダに提出する。試験請求は、処方製品に対する、完成した処方フォーム、および支払いの宣告をするリクエストを含むことができる。請求が拒否された場合、薬局受信者は、請求がなぜ拒否されたかを判断する。詳細には、薬局受信者は、保険プロバイダからの事前承諾が必要であるかどうかを判断する。事前承諾が必要である場合、薬局受信者は、患者の保険プロバイダに対する正しいＰＡフォームを決定する。他の実施形態では、薬局受信者は、試験請求を提出することなく、保険プロバイダと直接連絡をとって、保険プロバイダの請求要件、正しいＰＡフォーム（適用可能な場合）、保険プロバイダにより患者に提供される給付金などを決定することができる。さらに他の実施形態では、特定の保険プロバイダの１つまたは複数の正しいＰＡフォーム（複数可）を識別するデータ、保険プロバイダにより提供される特定のプランに関する給付金および要件のデータなどが、正しいＰＡフォームであるＰＡフォームが必要であるかどうか、および／または保険プロバイダにより患者に提供される給付金を自動的に決定するために使用されることができる。たとえば、保険プロバイダは、試験請求に対する応答で拒否の理由を示すことができ、ＰＡフォームは拒否の理由に基づき選択されることができる。
システムに正しいフォームがすでに含まれている場合、システムは、正しいＰＡフォームを患者のＨＣＰに自動的に提供する。代表的な実施形態では、ＰＡフォームは、複数のデータフィールドを含む電子的ＰＡフォームである。正しいＰＡフォームがシステムに含まれていない場合、薬局受信者は、たとえば、システム内の他のフォームと同じ文書タイプ、たとえばポータブルドキュメントフォーマット（ＰＤＦ）文書を有するフォームのバージョンを作成し、ＰＡフォーム上のフィールドをシステムで利用可能なデータにマッピングして、システムによるＰＡフォームの自動的設定を許可することにより、ＰＡフォームをシステムに含める準備をする。次いで、準備されたＰＡフォームは、たとえば、ＰＡフォームをサーバ、たとえば、サーバコンピュータデバイス２７５に記憶することにより、システムの中にロードされる。ＰＡフォームは、ＰＡフォームをＨＣＰに利用可能にする任意の適切な手段により、ＨＣＰに提供されることができる。代表的な実施形態では、薬局受信者は、特定の患者、およびフォームが適用される事例にフォームを関連づけることにより、システムを介して正しいＰＡフォームをＨＣＰに利用可能にする。他の実施形態では、薬局受信者は、電子的送信を介して、たとえば、安全なｅｍａｉｌもしくはＳＦＴＰ（ｓｅｃｕｒｅ ｆｉｌｅ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）を介して、または他の送信、たとえば、ファクシミリ送信を介して、ＨＣＰに送信することにより、フォームをＨＣＰによりダウンロードされるように利用可能にすることにより、ＰＡフォームをＨＣＰに送信することができる。
本明細書で開示されるように、ＨＣＰに送信されることができる、少なくともいくつかのＰＡフォームが、処理デバイス、たとえば、コンピューティングデバイス５０２が、タグをつけられたフィールドに自動的に設定することができるようにする少なくとも１つの電子的に「タグをつけられた」フィールドを含む。ＰＡフォームに自動的に設定するために使用されるデータは、患者情報（たとえば、名前、住所など）、医者の連絡先情報（たとえば、名前、ライセンス番号など）、（図５１に示される）給付金検証リクエストウィンドウ５１００の中に入力された情報、事務所情報（たとえば、名前、住所）、患者の保険情報（たとえば、会社、プラン番号など）、および／またはＰＡフォームのフィールドに関係する任意の他の情報を含むことができる。
ＰＡフォームがＨＣＰに提供された後（たとえば、ＨＣＰが処方マネージャを介してＰＡフォームにアクセスした後）、ＨＣＰは、必要なデータをＰＡフォームに手作業で設定する、すでに提供された情報をシステムがフォームに自動的に設定できるようにする、またはシステムがＰＡフォームの他の部分に自動的に設定することができるようにしながら、ＰＡフォームのいくつかの部分に手作業で設定することができる。ＨＣＰは、たとえば、研究室の結果、以前の処置、または以前の処方を含む追加の医療情報を提供することにより、システムにより自動的に設定されなくてもよい任意のフィールドを手作業で完成することができる。特定のＰＡフォームで必要である場合、ＨＣＰ、および具体的には処方者が、ＰＡフォームに電子的に署名する。例示的実施形態では、電子署名は、ＨＣＰによる物理的署名のデジタル表現である。電子署名は、医者が特定のＰＡフォームに署名しているときに取り込まれることができる、またはすでに取り込まれていてもよい。医者の電子署名がすでに取り込まれていた場合、医者は、既存の電子署名をＰＡフォームに添付して、フォームに署名する要件を満たすことができる。所望であれば、既存の電子署名を添付するには、たとえば、ユーザＩＤおよびパスワードの再記入により、医者の識別の確認を必要とすることができる。さらに、所望であれば、１人または複数の事務所職員メンバが、ＰＡフォームに医者の既存の電子署名を添付する権限を与えられることができる。事務所職員メンバの識別およびこのメンバが署名を添付する権限の確認は、添付を許可する前に行われることができる。
このとき、医学的処置調整システムは、ＨＣＰがＰＡフォームを保険業者に提出することができるようにする。ＰＡフォームは、保険業者により維持されるシステムに直接、電子的に送信される、保険業者のファックス装置に送信される、安全なｅｍａｉｌで保険業者に送信される、または任意の他の適切な送信方法で保険業者に送信されることができる。代表的な一実施形態では、ＰＡフォームは、デジタルフォーマットで提出される。たとえば、ＰＡフォームは、電子的ＰＡ（ｅＰＡ）標準フォーマットで提出されることができる。上述のように、医学的処置調整システムは、工程中に患者オプトインのために患者に利用可能な任意選択のサービスを提示する。患者が、これらのサポートサービスのうち１つまたは複数に参加することに合意した場合、このようなサービスを提供する、薬剤製造業者を含むサードパーティが、患者に積極的に連絡をとって、経済的援助オプション、トレーニング、教育、またはサポートオプションについて話し合うことができる。連絡は、医者の事務所で最初に関与した数時間以内に行われることができる。オプトインした患者によって決まる、話し合いを誘導する情報が、医学的処置調整システムによりサービスプロバイダに送信される。代表的な一実施形態では、典型的にはＰＡフォーム上に含まれるＰＡ情報が、フォーム以外のフォーマットで保険業者に送信される。さらに、所望であれば、ＰＡフォームおよび／またはＰＡ情報は、電子データ交換またはウェブサービスを使用して送信される。
代表的な一実施形態では、図４４を参照すると、ダッシュボードウィンドウ２２０２でＰＡフォームに書き込むことを選択することにより、図４４に示されるように、ＰＡウィンドウ４４００がオープンされる。ＰＡウィンドウ４４００は、ＰＡフォームウィンドウ４４０４内に薬局受信者から受信されたＰＡフォーム４４０２を表示する。ＰＡフォーム４４０２は、フィールド、たとえば患者の名前、患者の住所、ＨＣＰの名前、ＨＣＰの住所、および診断結果を選択し、フィールドに所望の値をタイプすることにより情報が記入されることができる、記入式フォームである。代表的な実施形態では、ＰＡフォームは、書込ボタン４４０６を選択することにより、追加で、または代わりに書き込まれることができる。書込ボタン４４０６が選択された場合、ＰＡフォーム４４０２のフィールドは、上記で説明されたように、本明細書で開示されるシステムにより、システム１００で集められた、適切な情報を設定されることができる。具体的には、システムは、ＰＡフォーム４４０２内の１つまたは複数のデータフィールドを識別することができ、記憶された患者および／または保険のデータの対応するデータフィールドを、識別されたデータフィールドにマッピングし、マッピングを使用して、識別されたデータフィールドに、記憶された患者および／または保険のデータを設定する。ＰＡフォーム４４０２は、フォームに自動的に設定することにより部分的に完成され、かつ手作業で部分的に記入されることができる、システムにより自動的に完全に記入されることができる、または手作業で完全に記入されることができる。代表的な一実施形態では、システム、またはＰＡフォーム自体は、情報が欠けているＰＡフォームデータフィールドを示して、ＰＡフォームを完成するためにこのようなデータが必要であることをユーザに警告することができる。さらに、代表的な一実施形態では、システムは、必要なデータフィールドがすべて完成されるまで、ＰＡフォームを保存および／または提出するのを禁止することができる。ＰＡフォーム４４０２は、ＨＣＰまたは権限が与えられた職員メンバにより署名ボタン４４０８を選択すること、および図４１を参照して上記で説明されたように署名を添付することにより署名されることができる。代表的な一実施形態では、ＨＣＰは、ＨＣＰの手書きの署名のすでに記憶された電子的表現を添付する代わりに、ＰＡフォーム４４０２が完成した時点でＨＣＰの手書きの署名の電子的表現を作成することができる。限定のためではなく例示のために、図４４Ｂは、開示される主題の一実施形態による他の代表的なＰＡ画面を示す。
受入詳細ウィンドウ４４１０が、患者の名前、処方されている薬剤、診断結果、患者の保険プロバイダ、およびＨＣＰの名前を含む、特定の事例に対する情報の要約を表示する。これらの項目の各々が、追加の詳細を見るために選択可能である。たとえば、ユーザが患者の名前を選択した場合、ＰＡウィンドウ４４００の上に、図４５に示される患者情報ウィンドウ４５００が表示される。患者情報ウィンドウ４５００は、患者に関する追加の詳細、たとえば、性別、生年月日、住所、および患者の識別文書のスキャンされた画像を含む。限定のためではなく例示のために、図４５Ｂおよび図４５Ｃは、開示される主題の一実施形態による他の代表的な患者情報ウィンドウを示す。
ユーザは、ＰＡフォームに加えて、患者の処方を調合する、患者の保険プロバイダおよび／または薬局に追加の関係文書を提出することを望む場合、新規文書を文書ウィンドウ４４１２に追加することを選択することにより提出することができる。この選択により、図４６に示される文書追加ウィンドウ４６００がオープンし、文書追加ウィンドウ４６００で、ユーザは、追加文書、たとえば、研究室の結果、給付金検証要約、追加メモ、および／または診断結果の裏付けなどを配置することができる。選択された文書は、ＰＡフォーム４４０２と一緒に提出する用意として、文書ウィンドウ４４１２に追加される。限定のためではなく例示のために、図４６Ｂは、開示される主題の一実施形態による他の代表的な文書追加ウィンドウを示す。
ユーザは、ＰＡフォーム４４０２を保険プロバイダに送信する準備ができたとき、（図４４に示される）ファックスボタン４４１４を選択し、それにより、図４７に示される文書をファックスするウィンドウ４７００をオープンする。限定のためではなく例示のために、図４７Ｂは、開示される主題の一実施形態による他の代表的な、文書をファックスするウィンドウを示す。代表的な一実施形態では、システムに記憶された、および／またはユーザにより記入された連絡先情報を使用して、ＰＡフォームおよび関連する文書が、処方を調合するために、ファクシミリ送信により、保険プロバイダ、および患者の好ましい、または指定された薬局に送信される。他の実施形態では、ＰＡフォームおよび文書は、たとえば、安全なｅｍａｉｌ、直接の電子的送信、郵送のための印刷などによることを含む他の手段により、薬局および保険会社の一方または両方に送信される。所望であれば、典型的にはＰＡフォーム上に含まれるＰＡ情報が、フォーム以外のフォーマットで保険業者に送信される。さらに、所望であれば、ＰＡフォーム、ＰＡ情報、および／または追加文書は、電子データ交換またはウェブサービスを使用して送信される。さらに、所望であれば、典型的には追加文書に含まれる情報（たとえば、研究所の結果、給付金検証要約、追加メモ、および／または診断結果の裏付け）は、文書以外のフォーマットで保険業者に送信される、および／または電子データ交換またはウェブサービスを使用して送信される。
さらに、ＰＡフォームおよび追加文書は、患者の記録の中に含めるために、電子医療記録システムに送信されることができる。文書をファックスするウィンドウ４７００は、患者の保険プロバイダの名前、および保険プロバイダのファックス番号を表示する。代表的な一実施形態では、ユーザは、どの文書を保険プロバイダに送信すべきかを選択することができる。文書ウィンドウ４４１２に含まれるすべての文書が、保険プロバイダに送信するための選択のために文書をファックスするウィンドウ４７００に表示される。他の実施形態では、１つまたは複数の文書が、保険プロバイダに送信するために事前に選択される、および／または必須とすることができる。文書をファックスするウィンドウ４７００はまた、処方を調合するための、患者の好ましい薬局の名前およびファックス番号を表示する。代表的な実施形態では、処方およびＰＡフォームを含む、文書ウィンドウ４４１２に含まれるすべての文書が薬局に送信される。他の実施形態では、電子処方を含む、１つまたは複数の文書が、薬局に任意選択で送信するために選択可能とすることができる。ユーザが送信ボタン４７０２を選択したとき、選択された文書は、本明細書で開示されるシステムの代表的な一実施形態により、文書をファックスするウィンドウ４７００に列挙されたファックス番号で、患者の保険会社にファックスされ、文書のすべてがまた、列挙されたファックス番号で、調合する薬局に送信される。代表的な一実施形態に関連して、１つまたは複数の文書が、給付金検証者（たとえば、薬局受信者）、支払人（たとえば、保険プロバイダ）、または処方製品販売者（たとえば、薬局）に（たとえば、ファックスを介して）電子的に送信されたとき、文書は、たとえば、業務もしくは処方者の名前、住所、電話、および／またはファックスに関する情報を含めることにより、ＨＣＰ業務に起因すると識別されることができる。たとえば、ファックスを介して送信されたとき、業務名およびファックス番号がファックスのヘッダに出現する。
上記で指摘されたように、代表的な一実施形態では、（たとえば、限定することなく、１０、７３１０、および１１２として図に描かれている処方マネージャのさまざまな実施形態を含む）処方マネージャが、単独で、または（たとえば、限定することなく、６０、５００、５２２、および１１４として図で描かれる、ユーザデバイスのさまざまな実施形態を含む）１つまたは複数のユーザデバイスと組み合わせて、患者の処方製品に対する医学的指示／処方文書の生成（４１）および実行（６１）を管理することができる。たとえば、本明細書で開示されるように、医学的指示／処方文書の生成（４１）は、患者受入情報および医学的指示／処方情報のうち少なくとも一部分に基づく、処方製品に対する医学的指示／処方文書の生成を含むことができる。すなわち、たとえば、医学的指示／処方文書は、個々に、または集合的に、患者受入情報の一部分、および／または処方情報の一部分に基づき生成されることができる。代表的な一実施形態では、患者受入情報は、処方文書の生成に必要なもの以外の情報を含むことができ、そのようなものとして、患者受入情報のサブセットが使用されることができる。
さらに、代表的な一実施形態では、医学的指示／処方の生成（４１）は、処方文書の生成（すなわち、処方製品販売者、たとえば、薬局から処方製品を獲得するために使用されることができる、医者により署名された文書）を含むことができる。代わりに、医学的指示／処方の生成（４１）は、医学的指示の生成（すなわち、医療用製品の投与の医療サービスの提供、投与、実行などのための、健康管理プロバイダによる指示）を含むことができる。たとえば、健康管理プロバイダの施設内で医療用製品（患者が処方製品販売者から医療用製品を獲得する場合に処方が必要となる製品とすることができるが、そうである必要はない）の投与を提供する医学的指示が生成されることができる。
代表的な一実施形態では、医学的指示／処方の実行（６１）は、処方製品プロバイダ（たとえば、薬局）への、または患者のプロバイダ（たとえば保険プロバイダ）への、処方文書の送信を含むことができる。同様に、医学的指示／処方の実行（６１）は、医療サービスプロバイダ、健康管理プロバイダ（たとえば、医療用製品の投与のため）、処方製品プロバイダ（たとえは、薬局、たとえば、処方製品が処方を必要としない場合）、および／または患者のプロバイダ（たとえば、保険プロバイダ）への、医学的指示文書の送信を含むことができる。さらに、医学的指示／処方の実行（６１）は、医療用製品の投与、または医療サービスの提供を含むことができる。たとえば、医学的指示／処方の実行は、生物学的薬剤の注入を含むことができる。上記で指摘されたように、本明細書で使用されるとき、「送信」（または「送信する」）という用語は、たとえば、ファックス、ｅｍａｉｌ、１つまたは複数のユーザデバイスによる電子的アクセス、ＨＴＴＰＳ送信などによる、任意の電子的送信手段を含むことができる。
次に、限定のためではなく実施例および例示のために、処方製品のための処方の生成に関連して、開示される主題によるある種の代表的な実施形態について説明される。しかしながら、以下の説明により、同様な手法で医学的指示の生成および実行を可能にすることができ、そのようなものとして、本願で開示される主題が、処方製品の生成および送信に限定されるべきではないことを当業者は認識されよう。
処方製品の処方を完成するために、ＨＣＰの署名が必要とされることができる。代表的な一実施形態では、すでに作成された（さらに、本明細書で説明された）ＨＣＰの電子署名が、処方を完成するために添付されることができる。他の実施形態では、ＨＣＰの署名は、ＨＣＰの手書きの署名の電子的表現を同時に取り込むことにより添付されることができる。代表的な一実施形態では、本明細書で開示されるシステムの、ログインしたユーザがＨＣＰである場合、ユーザは、ＨＣＰの電子署名を添付することができる。代表的な一実施形態では、ユーザがＨＣＰの代わりに署名する権限を与えられている職員メンバである場合、ユーザは、ＨＣＰの電子署名を添付することができる。ＨＣＰの署名を添付することを選択すると、ユーザは、自分のログイン認証情報、すなわち、ユーザ名およびパスワードを再記入する必要がある可能性がある。ＨＣＰの決定および署名ウィンドウ４１００の上に、図４２に示される認証ポップアップ４２００が表示されることができる。ユーザは、正しくない認証情報を記入した、またはＨＣＰに代わって署名する権限を与えられていない場合、ＨＣＰの署名を添付することができないようにされる。ユーザが、正しいログイン認証情報を記入し、ＨＣＰに代わって署名する権限を与えられている場合、ＨＣＰの署名が添付され、完全な処方および照会は、薬局受信者に提出する準備ができている。
ＨＣＰの決定および署名ウィンドウ４１００から、ユーザは、照会および処方フォームを見る、および／または提出することができる。図４３は、照会および完成した処方フォーム４３００の一例の最初のページである。図４３ではフォームの情報フィールドのすべてが空欄で示されているが、実際の使用では、処方マネージャ（たとえば、処方マネージャ１０、７３１０、１２など）、または代わりに、ユーザデバイス（たとえば、ユーザデバイス６０、７３４０、または５００など）が、（提供可能である場合には）ＨＣＰの署名を添付することを含み、すべてのフィールドに、上記で説明されたように生成された、および／または収集された情報を設定することができる。代表的な一実施形態では、照会および処方フォーム４３００は、追加情報、たとえば、患者の保険証（複数可）のスキャンされた画像を含むことができる。他の実施形態では、照会および処方フォーム４３００は、より多くの、またはより少ない情報を含むことができる。さらに、照会および処方フォーム４３００に含まれる特定のフォーマットおよび情報が、たとえば、照会および処方フォーム４３００が送信される薬局受信者の要件および／または所望のフォーマットに基づき、変えられることができる。
ユーザが、照会および処方フォーム４３００を薬局受信者に提出することを選択したとき、およびその場合、照会および処方フォーム４３００は、薬局受信者に送信されることができる。本明細書で具体化されるように、例示として、照会および処方フォーム４３００は、ネットワークを介して、たとえば、インターネットを介して薬局受信者に電子的に送信されることができる。他の実施形態では、照会および処方フォーム４３００は、任意の適切な送信により、たとえば、ファクシミリ送信、安全なｅｍａｉｌ送信への添付、無線ネットワークを介した電子的送信、ローカルエリアネットワークを介した送信によることを含み、送信される、ファックスされる、または印刷され郵送されるなどとすることができる。代表的な一実施形態に関連して、処方フォームが、給付金検証者（たとえば、薬局受信者）、支払人（たとえば、保険プロバイダ）、または処方製品販売者（たとえば、薬局）に（たとえば、ファックスを介して）送信されたとき、文書は、たとえば、業務または処方者の名前、住所、電話に関する情報、および／またはファックスの情報を含めることにより、ＨＣＰ業務に起因すると識別されることができる。たとえば、ファックスを介して送信されたとき、業務名およびファックス番号がファックスのヘッダに出現する。
限定のためではなく例示のために、図７６は、開示される主題の一実施形態による他の処方画面を示す。
本明細書で開示されるように、例示として、処方マネージャ７３１０は、健康管理プロバイダおよび患者に役立つ追加機能を実装し、サポートすることができる。例示のために、患者が、処方された製品またはサービスを受け取ったとき（たとえば、薬局が処方薬を調合し、患者により処方薬が受け取られた、または他の方法で患者に提供された（たとえば、郵送された）、または患者が専門医に相談した、または処方された処置を受けた）とき、対応する処方製品販売者７３２０（たとえば、薬局）または対応する処方サービスプロバイダ７３３０（たとえば、専門医）が、この情報を処方マネージャ７３１０に示すことができる（たとえば、適切なユーザデバイスを使用して、対応するウェブサイトにアクセスする）。処方マネージャ７３１０は、次に、患者の処方が調合されたことを健康管理プロバイダがわかるように、健康管理プロバイダのユーザアカウントで情報を更新することができる。
例示のために、健康管理プロバイダが、完成したフォームにしばらく（たとえば、数日）署名しなかった場合、処方マネージャ７３１０は、フォームを見直し、署名するように健康管理プロバイダにリマインダを送信することができる。リマインダは、任意の適用可能なフォーマットとすることができる。たとえば、処方マネージャ７３１０は、ｅｍａｉｌ、テキストメッセージ、音声メッセージ（たとえば、自動化された電話の呼出しによる）などとして、健康管理プロバイダにリマインダを送信することができる。健康管理プロバイダが何日か自分のアカウントにログインしない場合でさえ、即座にリマインダされるように、これらのリマインダの一部は、これらのリマインダを受信するために、処方マネージャ７３１０に対して自分のアカウントに健康管理プロバイダが実際にログインする必要がない。
例示のために、健康管理プロバイダは、自分のアカウントにログインしたとき、自分の患者の保険承諾フォームすべての、現在の状態を見ることができる。視覚的指示（たとえば、異なる色）が、異なる状態の承諾フォームと関連づけられることができる。たとえば、保険承諾フォームは、数日間署名されなかった場合、黄色で表示されることができる。しかしながら、フォームが１週間以上署名されなかった場合、このフォームは、赤色で表示されることができる。一方、保険承諾フォームがすでに署名され、適切な受信者に送信された場合、このフォームは、緑色で表示されることができる。
例示のために、患者は、処方マネージャ７３１０に対して自分のアカウントにログインしたとき、図５２に示されるように、処方マネージャ７３１０のユーザインタフェースの一部として処方マネージャ７３１０により提供される画面により、自分の処方に関連する情報を見直し、追加のサポートおよびサービスに署名契約することができる。たとえば、図５３は、患者が自己注射に関するトレーニングビデオを見ることができる画面の一例を示す。図５４〜図６０は、患者が処置情報、処方薬を投与するためのトレーニングなどを受けることができるように、任意選択のサービスに署名契約するように患者を誘導する一連の画面を示す。患者は、これらのサービスを受けるために、追加情報を提供し、（たとえば、図５７および図５９に示されるような）さまざまなタイプのコンテンツを与える必要がある可能性がある。
例示のために、新規薬剤が臨床試験を受けており、患者の状態を処置するとき、処方マネージャ７３１０は、患者が患者のアカウントでログインしたとき、新規薬剤に関する情報を患者に示すことができる。適切な場合には、患者は、臨床試験に参加したいかどうか尋ねられることができ、参加したい場合、臨床試験に署名契約し、必要な情報を入力するように患者を誘導する画面が提供されることができる。
患者は、一方の居住（または作業）場所から他の居住（または作業）場所に移動することができることがある。前者の場所に居住している間、患者は、処方製品またはサービスを得るための好ましい場所として、すぐ近くの薬局またはクリニックを選択していた可能性がある。新しい場所に移動した後、すでに選択された薬局またはクリニックは、患者にとってもはや都合がよくない可能性があり、患者は、処方製品またはサービスを得るための好ましい場所として、患者の新しい居住場所の近傍の、新しい薬局またはクリニックを選択することができる。例示のために、患者は、処方マネージャ７３１０に対して自分のアカウントにログインし、自分の住所を更新することができる。患者はまた、新しい薬局またはクリニックを、自分の好ましい薬局またはクリニックとして選択することができる。例示のために、処方マネージャ７３１０は、患者の健康管理プロバイダに患者の居住地移動について通知することができる。所望であれば、患者の同意があれば、処方マネージャ７３１０は、患者の現在の処方および保険の承認を、新しく選択された薬局またはクリニックに転送することができる（たとえば、新しく選択された薬局またはクリニックもまた、システム７３００の一部である場合）。さらに、または代わりに、処方マネージャ７３１０は、処方マネージャ７３１０の中に記入された、患者の住所変更に基づき、最も近い利用可能な、承認された薬局またはＨＣＰを選択するように患者を促すことができる。限定のためではなく例示のために、図７７は、開示される主題の一実施形態による、患者の詳細に対して行われた変更の通知を含む画面を示す。
図２２および図２３は、（図７４Ｃに示される）ダッシュボード経路７０６に沿ったページのスクリーンショットである。ユーザがダッシュボードボタン２２００を選択したとき、ダッシュボードウィンドウ２２０２が表示されることができる。ダッシュボードウィンドウ２２０２は、ユーザが関連づけられた、本明細書で開示されるシステムの中に記入された事例の状態に関する全体的情報を表示することができる。受入セクション２２０４が、受入手順が開始されたが、この事例に対して、システム内で照会にまだ進んでいない患者を表示する。受入セクション２２０４は、患者の名前、事例が作成された日付、事例の状態、および事例が最後に更新されて以来経過した時間長を表示する。代表的な実施形態では、経過した時間長は、最後の更新以来経過した時間の長さを迅速に示すことが可能になるように色分けされている。したがって、たとえば、経過時間は、ほとんど時間が経過していない事例では緑色に彩色され、所定の結果日数より長く経過した事例では黄色に彩色され、第２の（そしてより大きな）所定の経過日数を超えて経過した事例では赤色に彩色されてもよい。他の実施形態では、他の色彩設計が使用されてもよい。
未処理の照会セクション２２０６が、未処理の照会が存在する患者を表示することができる。未処理の照会セクション２２０６は、患者の名前、事例が作成された日付、事例の状態、および事例が最後に更新されて以来経過した時間長を表示する。未処理の照会セクション２２０６はまた、ユーザが注意する必要がある任意の未決定の措置を表示することができる。ユーザは、完了させたいと望む未決定の措置に対するボタンを選択することにより、未決定の措置をダッシュボードから完了させることを選択することができる。代表的な実施形態では、最後の更新以来の経過時間長が、最後の更新以来の時間を迅速に識別できるように色分けされる。したがって、たとえば、経過時間は、ほとんど時間が経過していない事例では緑色に彩色され、所定の日数より長く経過した事例では黄色に彩色され、第２の（そしてより大きな）所定の日数を超えて経過した事例では赤色に彩色されることができる。他の実施形態では、他の色彩設計が使用されてもよい。
完了セクション２２０８が、ユーザが関連づけられた、完了した事例を識別することができる。完了セクション２２０８は、患者の名前、事例が作成された日付、および事例の状態を表示する。
ダッシュボードウィンドウ２２０２から、ユーザは、検索ボックス２２１０を使用して、患者を検索するように選択することができる。ユーザは、完全なまたは部分的な患者情報、たとえば、名字、または固有の患者識別子、たとえば、ＩＤ番号、運転免許証番号、保険番号を、検索ボックス２２１０の中に記入してもよく、システムは、システム内でユーザが関連づけられた、マッチする患者をすべて応答する。システムは、ユーザが関連づけられていない、マッチする患者を応答しない（たとえば、システムは、検索ボックス２２１０に記入された検索語にマッチする他の業務の患者を応答しない）。代表的な実施形態では、システムは、ＨＣＰが責任を負う、または職員メンバが関連づけられたＨＣＰが責任を負う患者だけを応答する。他の実施形態では、システムは、検索基準にマッチする業務の任意のＨＣＰに関連づけられた患者すべてに対する検索結果を返す。
ユーザはまた、ダッシュボードウィンドウ２２０２から要約ダッシュボードを見ることを選択することができる。要約を見るリンク２２１２を選択することにより、図２３に示されるように、ダッシュボードウィンドウ２２０２の上に、ダッシュボード要約２３００が表示される。ダッシュボード要約２３００は、照会工程の各ステップにおける照会数および処理時間の要約を提示する。他の実施形態では、ダッシュボード要約２３００は、別個のフォームとして表示されてもよく、ダッシュボードウィンドウ２２０２にオーバーレイしていなくてもよい。
代表的な一実施形態では、ＰＡフォームおよび関係文書が患者の保険プロバイダおよび薬局に提出された後、ユーザは、処方の状態をモニタし続けて、保険プロバイダの承認が受信され、処方が調合されたかどうか、およびいつかを判断することができる。代表的な一実施形態では、保険プロバイダは、事前承諾が与えられたことを示す電子的確認メッセージを送信する。それに応じて、システムは、ＰＡフォームが保険プロバイダに送信されたときから、電子的確認メッセージが保険プロバイダから受信されたときまでの間の期間を表す未決期間を追跡することができる。未決期間および／または関連する測定基準が、（図５に示される）コンピューティングデバイス５０２上に表示されることができる。同様に、薬局は、処方が調合される、または調合されたことを示す電子的確認メッセージを送信することができる。処方が調合された後、事例の状態は、システム内で、より具体的には、（図２２に示される）ダッシュボードウィンドウ２２０２内で完了するよう更新されることができる。さらに、代表的な一実施形態では、他の状態更新が利用可能とすることができる。たとえば、事例が、必要な事前承認を保険プロバイダが提供したことを示すように更新される、患者により処方が実際に調合されたことを示すように更新されるなどとすることができる。他の実施形態では、ＰＡフォームおよび関係書類が患者の保険プロバイダおよび薬局に送信されたときに、事例が完了することができる。代表的な一実施形態では、薬局受信者が、患者の事例をモニタし、処方の状態が確認されると、患者の事例を完了することができる。システムは、さらに、電子医療記録システムに通信可能に連結されることができ、患者の医療記録の中に記憶し、含めるために、更新および文書が電子医療記録システムに送信される。
システムは、本明細書で説明される処方および履行工程に関するデータを、患者以外の他の特定の目的のために記憶することができる。データは、患者識別情報を取り去られたフォームで記憶されることができる。たとえば、照会を薬局受信者に提出してから給付金検証および／またはＰＡフォームが戻るまでの間の経過時間が、患者特有の情報を含めることなく各事例に対して記憶されることができる。工程の他の時間間隔すべてに関するデータ、たとえば、ＰＡフォームを受信してから完成したＰＡフォームを保険プロバイダに提出するまでの間、ＰＡフォームを保険プロバイダに提出してからＰＡが承認されるまでの間の時間間隔、ＰＡが承認されてから処方が調合されるまでの間の時間などのデータ。データは、複数のＨＣＰ、ＨＣＰ業務、薬局受信者、および／または調合する薬局にわたり収集される、および解析されることができる。しかしながら、このようなデータは、ＨＣＰ、保険プロバイダ、薬局受信者、および／または調合する薬局に関して一般化されていない場合がある（すなわち、このようなデータは、識別情報を含む場合がある）ので、データは、たとえば、システムでそれぞれの仕事を完了する際のさまざまなＨＣＰ、薬局受信者、および／または調合する薬局の注意を判断するために、さらに解析されることができる。他の実施形態では、システムにより生成されたデータは、違った形で、および／または異なる目的で解析されることができる。所望であれば、ＨＣＰは、一般化されたデータ、および／またはこのような解析の結果にアクセスすることができる。
次に、限定のためではなく例示のために、本明細書で開示されるシステムおよび方法の代替実施形態または追加実施形態が、図６６〜図７１を参照して説明される。
図６６〜図７１は、開示される本主題による医学的処置調整システム６６００の態様の構成図である。図６６〜図７１では、システム６６００は、本明細書でＤＲＵＧＣＯと呼ばれる製薬会社により製造された、本明細書でＤＲＵＧ（Ｈ）と呼ばれる医薬品の処方を調整するために使用される。１つまたは複数の薬局受信者が、本明細書でＰＨＡＲＭＡＣＯと呼ばれることがある。ＤＲＵＧ（Ｈ）に関連づけられた任意選択のサポートサービス、たとえば、トレーニング、情報、経済的支援などを提供するためのサポートサービスグループが、ｍｙＤＲＵＧという名前で呼ばれる。
医学的処置調整システム６６００は、処方情報の獲得を自動化して、承認を加速し、より高い精度を保証し、重要な組込サービスに患者を接続する技術基盤である。システム６６００は、ＨＣＰの事務所の中に、薬局に、保険プロバイダおよび／または他のサードパーティ、たとえば、医薬品製造会社に広がるように、互いにネットワーク接続され通信状態にあるいくつかのコンピューティングデバイスを含む。
医学的処置調整システム６６００は、たとえば、管理された薬剤の投与および自己注射ができる患者の能力を含む、管理された薬剤に関連する患者サービスについて患者が認識するのを容易にするように構成される。医学的処置調整システム６６００により、管理された薬剤の製造業者は、新規患者と連絡をとり、患者のインフォームドコンセントを伴い、処方保護（Ｐｒｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｅｃｔｉｏｎ、ＰＰ）、注入指示サービス、および他のｍｙＤＲＵＧサービスを含むサービスの認識と使用の両方を改善することが可能になる。
医学的処置調整システム６６００は、コンピュータタブレット、キーボード、および光学スキャナデバイスを含む。ハードウェアは、薬剤製造業者と業務の間で、ユーザの合意の下で医者の事務所に設置される。さまざまな実施形態では、この基盤は、健康管理プロバイダ（ＨＣＰ）および患者が、有効な処方、事前承諾、および薬剤製造業者からの安全な組込サービスに対する患者の同意を完了するために必要なすべてのデータを記入することができるようになるウェブベースのソフトウェアプログラムを排他的に実行する。医学的処置調整システム６６００は、健康管理プロバイダが、すでに記入されたデータを再利用して、ＨＣＰ運用の能率化を可能にする、一体化されたデータ収集システムを提供する。すべてのシステムは、プライバシを保証し、すべての薬局の要件を満たすために、ＨＩＰＡＡ検証される。
図６７は、開示される主題の代表的な一実施形態による医学的処置調整システム６６００を使用する患者受入工程６７００の流れ図である。代表的実施形態では、工程６７００は、運転免許証もしくは他の識別、および／または保険証から患者情報を取り込むように構成される。
図６８は、患者がｍｙＤＲＵＧサービスにオプトインし、医学的処置調整システム６６００を使用して患者の署名を獲得することができるようになるステップを示す、患者オプトイン工程の流れ図である。
図６９は、医学的処置調整システム６６００を使用して、給付金検証（ＢＶ）、および紙の処方および／または電子処方（Ｅ−Ｐｒｅｓｃｒｉｐｔｉｏｎ）のデジタルレンダリングを生成するように構成された工程の流れ図である。代表的な実施形態では、事例の情報および患者署名工程が完了したとき、処方者が事例に署名して、ＢＶを生成する。代表的な一実施形態では、署名されたＢＶが、紙の処方および／または電子処方のデジタルレンダリングである、またはこれを含み、患者が選んだ薬局に送付される。
図７０は、事前承諾（ＰＡ）工程７０００の流れ図であり、事前承諾フォームに記入して、ＰＡフォームを保険会社にファックスするステップを伴うステップを示す。ＢＶ提出後、医学的処置調整システム６６００は、ＢＶおよび正式なＰＡフォームを送り返す。事務所職員はすでに記入されたデータを、ＰＡフォームに設定してもよい。
図７１は、施設、職員メンバ、および医者を医学的処置調整システム６６００の中に登録する、管理者活動の流れ図である。各施設に対して一度この流れに従う。
代表的システム６６００は、任意の特定の処方製品またはサービスで使用されることができる。さらに、医学的処置調整システム６６００は、いくつかの異なる処方製品またはサービスと一緒に使用されることができる。このような実施形態では、ユーザが、どの薬剤システム６６００が使用されているか、すなわち、どの製品またはサービスが処方または指示されているかを、各段階で選択することができる。
本明細書で具体化されるように、医学的処置調整システム６６００は、電子処方、事前承認、および患者組込サービスにより提供されるサービスを統合することができ、事務手続きの低減、および信頼できるＰＡフォームの完成という利益をクリニックに提供することにより、患者組込率を改善する。医学的処置調整システム６６００により、ｍｙＤＲＵＧプログラムへのより高い患者オプトインを可能にし、その結果、薬局での処方放棄が減り、トレーニングおよびフォローアップにより患者の応諾および一貫性が改善され、適切な開始投与量の使用が増加する。
図に描かれ、本明細書で説明される代表的なスクリーンショットは、限定するためではなく例示のために提供されていることを当業者は認識されよう。それに応じて、同様のスクリーンショットの順序およびグルーピングは、必要に応じて修正されることができる。限定のためではなく例示のために、参照により全体が本明細書に組み入れられる、米国特許仮出願第６１／７１２，１５３号明細書の図８２〜図２６０は、開示される主題の代表的な一実施形態による代替のスクリーンショットを提供する。
本開示は、処方製品の医学的指示／処方を容易にする、および／または調整するためのシステムおよび方法を含む、ある種の代表的な実施形態に適用されるとして説明される。本明細書で使用されるとき、医学的処置は、処方を必要とし、かつ保険プロバイダからの事前承諾をさらに必要とする場合がある患者に提供される任意の医療用製品および／または医療サービスを含むことができるが、これに限定されない。したがって、医学的処置は、薬剤、医薬品、医療用デバイス、医学的治療、物理的治療、医療用具などを含んでもよい。さらに、本明細書で使用されるとき、医学的指示／処方は、指示、リクエスト、命令、および／または医学的処置の推奨を含むことができる。本明細書で説明されるシステムおよび方法は、一般に、処方製品の医学的指示／処方を容易にするステップ、および／または調整するステップに関するが、開示される主題の特定の実施形態が、総称的にアダリムマブとしても知られる、ヒュミラ（Ｒ）製品として知られる処方薬の処方に関連して使用されることができる（ヒュミラは、Ａｂｂｏｔｔ Ｂｉｏｔｅｃｈｎｏｌｏｇｙ Ｌｔｄ．、Ｈａｍｉｌｔｏｎ、Ｂｅｒｍｕｄａの登録商標である）。たとえば、指示、診断結果、医者の専門、投薬、送達経路などが、本明細書で、患者に対するヒュミラ（Ｒ）製品の処方、および事前承諾の取得に関して説明される。しかしながら、本明細書で説明されるシステムおよび工程はまた、他の処方薬を含む、任意の他の医学的処置と共に使用されてもよく、ヒュミラ（Ｒ）製品と一緒に使用するように限定されるわけではない。
本明細書で説明されるような、本願で開示される主題の実施形態は、医学的処置管理方法およびシステムに関する。説明される方法およびシステムは、医学的処置、たとえば医療サービスおよび／または医療用製品を容易にする、調整する、または管理するために使用されることができる。本明細書で使用されるとき、医療的処置は、任意の適切な医療サービスまたは医療用製品を含む。医療用製品は、患者の医学的処置の過程で患者により使用されても、消費されてもよい物理的デバイスを含む。医療サービスは、処置、たとえば、限定することなくカウンセリングの役割を果たす医療用デバイスまたはスタンドアロンのサービスの供給および運用をサポートする活動を含む。医療サービスは、たとえば、医療用製品、医薬品、および／または医学的処置に関連する１つまたは複数のサービスを含んでもよい。さらに、医療サービスはまた、一般に、特定の製薬および／または健康管理に関連する教育および／またはトレーニングを容易にするために使用されてもよい。
本明細書で説明される方法およびシステムは、コンピュータソフトウェア、ファームウェア、ハードウェア、またはこれらの組合せもしくはサブセットを含むコンピュータプログラミングまたはエンジニアリング技法を使用して実装されてもよく、技術的効果が、（ａ）患者に対する医薬品の完成した処方フォームを含む、健康管理プロバイダ（ＨＣＰ）からの患者データ、および患者の保険プロバイダを識別する保険データを受信するステップ、（ｂ）患者データおよび保険データをメモリデバイス内部に記憶するステップ、（ｃ）患者による医薬品に対する請求をカバーする前提条件として、処方に対する事前承諾を保険プロバイダが必要としていることを判断するステップ、（ｄ）処方に対する事前承諾を要求するために、保険プロバイダにより必要とされる現在の電子的事前承諾フォームを決定するステップ、および（ｅ）決定された事前承諾フォームをＨＣＰに送信するステップであって、ＨＣＰは、決定された事前承諾フォーム内部に含まれる少なくとも１つのデータフィールドに、メモリデバイス内部に記憶された患者データを自動的に設定することにより、決定された事前承諾フォームを完成するように促され、ＨＣＰにより完成された、決定された事前承諾フォームを保険プロバイダに送信するステップのうち少なくとも１つを含んでもよい。
ある種の代表的システムが、処方情報、ＨＣＰ情報、保険情報、および／または患者情報の取込みを自動化して、処方承認の加速を容易にするための健康管理プロバイダ（ＨＣＰ）技術基盤を備える。システムの他の特徴が、より高い精度の情報、および処方された薬に関連する任意選択のサービス、または処置の代金を支払う際に患者の支援に利用可能であってもよい経済的サービスに患者を結びつける能力を含む。
本明細書で使用されるとき、ＨＣＰは、医療サービスを提供する、または有効な処方を生成する人を含み、エンティティ、たとえば、１人または複数の医師を含む医療業務を含む。ＨＣＰ情報は、識別情報を、たとえば、名前、住所、電話番号、ライセンス番号、およびＨＣＰに関連するＤＥＡ番号、ＨＣＰの従業員、ならびにＨＣＰに関連づけられた他のことを含んでもよい。保険情報は、保険会社、および／または保険会社により発行された保険証券に関する情報を含んでもよく、たとえば、保険業者の名前、住所、および連絡先情報、被保険者の名前、保険証券番号（複数可）、控除免責金額、および自己負担分を含む。患者情報は、患者に関して識別する個人情報、たとえば、名前、住所、電話番号、ｅｍａｉｌアドレス、運転免許証番号、および社会保障番号を含んでもよい。
特に指定がない限り、本明細書で説明される機能は、コンピュータ可読メモリに記憶され、かつ１つまたは複数のプロセッサベースのシステム上で実行される、実行可能コードおよび命令により実行されてもよい。しかしながら、状態機械、および／または有線接続された電子回路もまた利用されることができる。さらに、本明細書で説明される例示的工程に関して、すべての工程状態が達成される必要もなく、状態が例示された順序で行われる必要もない。
本明細書で使用されるとき、プロセッサという用語は、中央処理装置、マイクロプロセッサ、マイクロコントローラ、縮小命令セット回路（ｒｅｄｕｃｅｄ ｉｎｓｔｒｕｃｔｉｏｎ ｓｅｔ ｃｉｒｃｕｉｔ、ＲＩＳＣ）、特定用途向け集積回路（ＡＳＩＣ）、論理回路、および本明細書で説明される機能を実行することができる任意の他の回路またはプロセッサを指す。
前述の仕様に基づき認識されるように、本開示の上述の実施形態は、コンピュータソフトウェア、ファームウェア、ハードウェア、またはこれらの任意の組合せもしくはサブセットを含む、コンピュータプログラミングまたはエンジニアリング技法を使用して実装されてもよく、技術的効果が、患者に対する医薬品の処方を備える患者データ、および患者の保険プロバイダの識別を受信すること、処方が調合されてもよいとする前に、患者の保険プロバイダからの事前承諾が必要であるかどうかを判断すること、および患者の保険プロバイダからの事前承諾が必要である場合に、事前承諾フォームを患者の健康管理プロバイダに提供することのうち１つまたは複数である。コンピュータ可読コード手段を有する、このように得られた任意のプログラムが、１つまたは複数のコンピュータ可読媒体内部で具体化されても、提供されてもよく、それにより、本開示の説明された実施形態に従うコンピュータプログラム製品、すなわち、製造物を作る。コンピュータ可読媒体は、たとえば、固定（ハード）ドライブ、ディスケット、光ディスク、磁気テープ、読出し専用メモリ（ＲＯＭ）などの半導体メモリ、および／または任意の送信／受信媒体、たとえば、インターネット、または他の通信ネットワークもしくはリンクであってもよいが、これらに限定されない。コンピュータコードを含む製造物は、一方の媒体から直接コードを実行することにより、コードを一方の媒体から他の媒体にコピーすることにより、またはコードをネットワーク上で送信することにより作られてもよい、および／または使用されてもよい。
本明細書で説明されるシステムおよび方法は、任意の薬剤、医薬品または医薬品サービス、医療用デバイスと共に、および／または処方、たとえば、医療手順の指示などを必要としても、しなくてもよい任意の他の製品またはサービスと共に、同様に使用されることができることを理解されたい。
本明細書では、単数で記載された、「ａ」または「ａｎ」という語に先行される要素またはステップが、排除が明示的に記載されている場合を除いて、複数の要素またはステップを排除しないと理解されたい。さらに、「一実施形態（ｏｎｅ ｅｍｂｏｄｉｍｅｎｔ）」という参照が、記載された特徴を同じく組み入れる追加実施形態の存在を排除すると解釈されることは意図されない。
本明細書では、「または（ｏｒ）」は、他の方法で明示的に示されない、または文脈により他の方法で示されない限り、包括的であり、排他的ではない。したがって、本明細書では、「ＡまたはＢ」は、他の方法で明示的に示されない、または文脈により他の方法で示されない限り、「Ａ、Ｂ、または両方」を意味する。さらに、「および（ａｎｄ）」は、他の方法で明示的に示されない、または文脈により他の方法で示されない限り、結合と個々別々の両方である。したがって、本明細書では、「ＡおよびＢ」は、他の方法で明示的に示されない、または文脈により他の方法で示されない限り、「ＡおよびＢ、結合してまたは個々別々に」を意味する。
本開示は、当業者が理解する、本明細書の実施形態例に対するすべての変更形態、置換形態、変形形態、代替形態、および修正形態を包含する。さらに、特許請求の範囲では、特定の機能を実行するように適合された、配置された、能力のある、構成された、可能にされた、動作可能な、または作用する装置もしくはシステム、または装置もしくはシステムの構成要素への参照は、装置もしくはシステム、または装置もしくはシステムの構成要素、またはこの特定の機能が起動される、スイッチを入れられる、またはアンロックされようとなかろうと、この装置、システム、または構成要素がそのように適合され、配置され、能力があり、構成され、可能にされ、動作可能であり、作用する限り、この装置、システム、構成要素を包含する。
さらに、本開示は、特定の構成要素、要素、機能、動作、またはステップを含むとして本明細書でそれぞれの実施形態について説明し、例示するが、これらの実施形態のいずれも、当業者が理解する、本明細書のいずれかで説明される、または例示される構成要素、要素、機能、動作、またはステップのいずれかの任意の組合せまたは並べ換えを含んでもよい。

Claims (68)

  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. 事前定義フォームに関する情報を給付金検証者から受信するステップをさらに備え、事前定義フォームのうち１つを選択するステップは、給付金検証者から受信された事前定義フォームに関する情報にさらに基づき、事前定義フォームのうち１つを選択するステップを含む、請求項３０に記載の方法。
  35. 追加の患者情報を要求するステップをさらに備える、請求項２５に記載の方法。
  36. 追加の患者情報を受信するステップと、選択された事前定義フォームの少なくとも１つのフィールドに追加の患者情報を設定するステップとをさらに備える、請求項３５に記載の方法。
  37. 追加の患者情報が、選択された事前定義フォームに必要であり、かつ患者受入情報、または処方製品に関する処方製品情報に含まれない情報を含む、請求項３５に記載の方法。
  38. 設定された事前定義フォームが、患者のプロバイダにリリーズされる、請求項２５に記載の方法。
  39. 健康管理プロバイダの署名を受信するステップと、
    処方製品情報から処方文書を生成するステップと、
    処方文書を薬局にリリーズするステップと
    をさらに備える、請求項２５に記載の方法。
  40. 患者受入情報および処方製品情報の記入用フィールドを含むユーザインタフェースを記述するマークアップ言語をネットワーク上で送信するステップをさらに備える、請求項２５に記載の方法。
  41. ネットワークに接続されたユーザデバイスで、
    マークアップ言語を構文解析し、ユーザインタフェースを表示するステップと、
    ユーザインタフェースのフィールドの中に記入された患者受入情報および処方製品情報をメモリに記憶するステップと、
    患者受入情報および処方製品情報を受信機に送信するステップと
    をさらに備える、請求項４０に記載の方法。
  42. 少なくとも１つのユーザデバイスが、タブレット、携帯電話、ラップトップ、またはデスクトップコンピュータを含む、請求項４１に記載の方法。
  43. ユーザデバイスで、処方製品情報から処方文書を生成するステップと、処方文書を生成するステップの前に、健康管理プロバイダの署名を受信するステップとをさらに備える、請求項４１に記載の方法。
  44. ユーザデバイスで、処方文書を薬局に送信するステップをさらに備える、請求項４３に記載の方法。
  45. ユーザデバイスで、
    ユーザデバイスに通信可能に連結されたスキャニングデバイスから患者識別文書の１つまたは複数の画像を受信するステップと、
    患者識別文書の画像から患者受入情報の少なくとも一部を抽出するステップと、
    ユーザインタフェースの少なくとも１つのフィールドに自動的に設定するステップと
    をさらに備える、請求項４１に記載の方法。
  46. 患者識別文書がライセンスまたは保険証を含む、請求項４５に記載の方法。
  47. 実行されたときに、プロバイダによりカバーされる患者に対する処方製品の医学的指示／処方を容易にする方法を１つまたは複数のユーザデバイスに実行させるコンピュータ実行可能命令を含む非一時的コンピュータ可読媒体であって、方法は、
    中に記憶された１つまたは複数のプロバイダに対応する複数の事前定義フォームを含むメモリを提供するステップと、
    患者のプロバイダ、および処方製品に関する処方製品情報を含む患者受入情報を受信するステップと、
    プロセッサにより、患者受入情報に基づき患者に対する給付金検証リクエストを生成するステップと、
    給付金検証リクエストに基づく給付金要約を得るステップと、
    患者プロバイダ情報および給付金要約のうち少なくとも一方に基づき事前定義フォームのうち１つを選択するステップと、
    患者受入情報に基づき、選択された事前定義フォームの少なくとも１つのフィールドに設定するステップと、
    プロセッサにより、選択された事前定義フォームで、患者への処方製品の医学的指示／処方を容易にするステップと
    を備える非一時的コンピュータ可読媒体。
  48. 医学的指示／処方を容易にするステップが、処方製品の医学的指示／処方の実行を容易にするステップ、または処方製品に対する支払いの承認を容易にするステップを含む、請求項４７に記載の非一時的コンピュータ可読媒体。
  49. プロバイダが、保険会社、政府機関、またはサードパーティの支払人を含む、請求項４７に記載の非一時的コンピュータ可読媒体。
  50. 処方製品が、医療用製品、医療サービス、または医療用製品の投与を含む、請求項４７に記載の非一時的コンピュータ可読媒体。
  51. 少なくとも１つの処方製品が生物学的製剤を含む、請求項４７に記載の非一時的コンピュータ可読媒体。
  52. 生物学的製剤がアダリムマブを備える、請求項５１に記載の非一時的コンピュータ可読媒体。
  53. いくつかの可能な処方製品から処方製品を選択するステップをさらに備え、メモリは、可能な各処方製品に対して複数の事前定義フォームを中に記憶している、請求項４７に記載の非一時的コンピュータ可読媒体。
  54. 事前定義フォームのうち１つを選択するステップが、プロセッサにより、事前定義フォームのうち１つを自動的に選択するステップを含む、請求４７に記載の非一時的コンピュータ可読媒体。
  55. 給付金要約を得るステップが、
    給付金検証リクエストを給付金検証者に送信するステップと、
    給付金要約を給付金検証者から受信するステップと
    を備える、請求項４７に記載の非一時的コンピュータ可読媒体。
  56. 事前定義フォームに関する情報を給付金検証者から受信するステップをさらに備え、事前定義フォームのうち１つを選択するステップは、給付金検証者から受信された事前定義フォームに関する情報にさらに基づき、事前定義フォームのうち１つを選択するステップを含む、請求項５５に記載の非一時的コンピュータ可読媒体。
  57. 追加の患者情報を要求するステップをさらに備える、請求項４７に記載の非一時的コンピュータ可読媒体。
  58. 追加の患者情報を受信するステップと、選択された事前定義フォームの少なくとも１つのフィールドに追加の患者情報を設定するステップとをさらに備える、請求項５７に記載の非一時的コンピュータ可読媒体。
  59. 追加の患者情報が、選択された事前定義フォームに必要であり、かつ患者受入情報、または処方製品に関する処方製品情報に含まれない情報を含む、請求項５７に記載の非一時的コンピュータ可読媒体。
  60. 設定された事前定義フォームが、患者のプロバイダにリリーズされる、請求項４７に記載の非一時的コンピュータ可読媒体。
  61. 健康管理プロバイダの署名を受信するステップと、
    処方製品情報から処方文書を生成するステップと、
    処方文書を薬局にリリーズするステップと
    をさらに備える、請求項４７に記載の非一時的コンピュータ可読媒体。
  62. 患者受入情報および処方製品情報の記入用フィールドを含むユーザインタフェースを記述するマークアップ言語をネットワーク上で送信するステップをさらに備える、請求項４７に記載の非一時的コンピュータ可読媒体。
  63. ネットワークに接続されたユーザデバイスで、
    マークアップ言語を構文解析し、ユーザインタフェースを表示するステップと、
    ユーザインタフェースのフィールドの中に記入された患者受入情報および処方製品情報をメモリに記憶するステップと、
    患者受入情報および処方製品情報を受信機に送信するステップと
    をさらに備える、請求項６２に記載の非一時的コンピュータ可読媒体。
  64. 少なくとも１つのユーザデバイスが、タブレット、携帯電話、ラップトップ、またはデスクトップコンピュータを含む、請求項６３に記載の非一時的コンピュータ可読媒体。
  65. ユーザデバイスで、処方製品情報から処方文書を生成するステップと、処方文書を生成するステップの前に、健康管理プロバイダの署名を受信するステップとをさらに備える、請求項６３に記載の非一時的コンピュータ可読媒体。
  66. ユーザデバイスで、処方文書を薬局に送信するステップをさらに備える、請求項６５に記載の非一時的コンピュータ可読媒体。
  67. ユーザデバイスで、
    ユーザデバイスに通信可能に連結されたスキャニングデバイスから患者識別文書の１つまたは複数の画像を受信するステップと、
    患者識別文書の画像から患者受入情報の少なくとも一部を抽出するステップと、
    ユーザインタフェースの少なくとも１つのフィールドに自動的に設定するステップと
    をさらに備える、請求項６３に記載の非一時的コンピュータ可読媒体。
  68. 患者識別文書がライセンスまたは保険証を含む、請求項６７に記載の非一時的コンピュータ可読媒体。
JP2014535822A 2011-10-10 2012-10-10 健康管理サービスの管理 Pending JP2014528626A (ja)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US201161545480P 2011-10-10 2011-10-10
US61/545,480 2011-10-10
US201261623032P 2012-04-11 2012-04-11
US201261622930P 2012-04-11 2012-04-11
US61/622,930 2012-04-11
US61/623,032 2012-04-11
US201261712153P 2012-10-10 2012-10-10
US61/712,153 2012-10-10
PCT/US2012/059609 WO2013055828A1 (en) 2011-10-10 2012-10-10 Managing healthcare services

Publications (2)

Publication Number Publication Date
JP2014528626A true JP2014528626A (ja) 2014-10-27
JP2014528626A5 JP2014528626A5 (ja) 2015-12-03

Family

ID=47076451

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014535822A Pending JP2014528626A (ja) 2011-10-10 2012-10-10 健康管理サービスの管理

Country Status (9)

Country Link
JP (1) JP2014528626A (ja)
CN (1) CN104106071A (ja)
AU (1) AU2012322838A1 (ja)
CA (1) CA2851928A1 (ja)
IL (1) IL232024A0 (ja)
MX (1) MX2014004399A (ja)
RU (1) RU2014118744A (ja)
SG (1) SG11201401416WA (ja)
WO (1) WO2013055828A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016539402A (ja) * 2013-10-31 2016-12-15 メルク・シャープ・エンド・ドーム・コーポレイション 無料頒布薬品送付システム
CN108230158B (zh) * 2016-12-15 2021-12-03 平安科技（深圳）有限公司 一种理赔测试方法和装置
CN107315905A (zh) * 2017-06-01 2017-11-03 广西昌成科技有限公司 一种中药处方检查系统及数据处理方法
CN107918915B (zh) * 2017-06-25 2022-02-08 平安科技（深圳）有限公司 核保信息处理的装置、方法及计算机可读存储介质
AU2018348113B2 (en) * 2017-10-11 2021-12-09 Click Therapeutics, Inc. Systems and methods for ensuring data security in the treatment of diseases and disorders using digital therapeutics
CN109035039A (zh) * 2018-07-16 2018-12-18 平安健康保险股份有限公司 慢病代配药方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040249665A1 (en) * 2003-06-09 2004-12-09 Lindee David System and method for processing and managing claim forms
JP2006107069A (ja) * 2004-10-05 2006-04-20 Hitachi Ltd 医薬品処方情報照会・配信システム
US20090024412A1 (en) * 2007-06-29 2009-01-22 Mark Medvitz Systems and methods for processing requests for pharmaceuticals that require insurer preapproval

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5737539A (en) * 1994-10-28 1998-04-07 Advanced Health Med-E-Systems Corp. Prescription creation system
JP2002512712A (ja) * 1997-03-13 2002-04-23 ファースト オピニオン コーポレイション 疾患管理システム
US20050182656A1 (en) * 1999-05-28 2005-08-18 Morey Fred R. On-line prescription service system and method
US20020029223A1 (en) * 2000-03-08 2002-03-07 Rice Marion R. Prescription network supporting doctors, care givers and online drug store interaction
US7426475B1 (en) * 2000-03-21 2008-09-16 Mahesh Tangellapally Secure electronic healthcare information management process and system
JP4454834B2 (ja) * 2000-11-30 2010-04-21 キヤノン株式会社 携帯端末を用いた健康管理のためのシステム及び方法
KR100392331B1 (ko) * 2001-02-02 2003-07-22 서오텔레콤(주) 통신망을 이용한 의료보험 관리시스템 및 그 방법
US20030167190A1 (en) * 2002-03-01 2003-09-04 Rincavage Barbara A. System and method for preventing fraud and mistake in the issuance, filling and payment of medical prescriptions
US7716072B1 (en) * 2002-04-19 2010-05-11 Greenway Medical Technologies, Inc. Integrated medical software system
US20070100660A1 (en) * 2005-10-28 2007-05-03 Validus Medical Systems, Inc. Electronic physician's order entering system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040249665A1 (en) * 2003-06-09 2004-12-09 Lindee David System and method for processing and managing claim forms
JP2006107069A (ja) * 2004-10-05 2006-04-20 Hitachi Ltd 医薬品処方情報照会・配信システム
US20090024412A1 (en) * 2007-06-29 2009-01-22 Mark Medvitz Systems and methods for processing requests for pharmaceuticals that require insurer preapproval

Also Published As

Publication number Publication date
WO2013055828A1 (en) 2013-04-18
MX2014004399A (es) 2015-03-05
CN104106071A (zh) 2014-10-15
RU2014118744A (ru) 2015-11-20
NZ623641A (en) 2016-02-26
SG11201401416WA (en) 2014-10-30
AU2012322838A1 (en) 2014-04-24
CA2851928A1 (en) 2013-04-18
IL232024A0 (en) 2014-05-28

Similar Documents

Publication Publication Date Title
US20210158924A1 (en) Managing healthcare services
US20220199214A1 (en) Managing healthcare services
US20150278474A1 (en) Managing healthcare services
US20160342752A1 (en) Managing healthcare services
US10249386B2 (en) Electronic health records
US20190244683A1 (en) Systems and methods for using electronic medical records in conjunction with patient apps
US20180082022A1 (en) Systems and methods for assembling electronic medical records
US8959027B2 (en) Health portal data consolidation
US20060184524A1 (en) Method and system for automated data analysis, performance estimation and data model creation
US20130297333A1 (en) Systems and methods for electronic prescribing
US20110246231A1 (en) Accessing patient information
JP2009514108A (ja) 電子式医師オーダー入力システム
WO2003017166A1 (en) Medical service and prescription management system
US8756076B2 (en) HIPAA-compliant third party access to electronic medical records
Webster et al. Health information technology: a new world for pharmacy
JP2014528626A (ja) 健康管理サービスの管理
US20190354721A1 (en) Techniques For Limiting Risks In Electronically Communicating Patient Information
Castro Explaining international IT application leadership: Health IT
AU2013329116A1 (en) Managing healthcare services
US20240185978A1 (en) Managing healthcare services
WO2021191687A1 (en) Cloud-based medical record management system with patient control
WO2015109167A1 (en) Managing healthcare services
Tokayev The Role of Health Information Technology (HIT) in Healthcare Reform: Opportunities and Challenges
NZ623641B2 (en) Managing healthcare services
Crook An Interactive Qualifying Project

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20151009

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20151009

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20161013

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161018

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20170523