JP2022537451A - ヘルスケアを促進するシステムおよび方法 - Google Patents

Abstract

ヘルス管理システムが、患者に関する患者ヘルスデータを受信し、ヘルス管理システムが、患者ヘルスデータを分析し、特定のタイプのヘルスケア専門家との関与が必要であることを決定し、ヘルス管理システムが、特定のタイプの特定のヘルスケア専門家を決定し、ヘルスケア専門家エンゲージメントインターフェイスを生成させ、特定のタイプのヘルスケア専門家との関与が必要であり、連絡禁止制御であることを示す情報を含むヘルスケア専門家エンゲージメントインターフェイスを生成させ、連絡禁止制御がアクティブ化されていないことが決定された場合、特定のヘルスケア専門家に対して患者連絡リマインダを生成させ、患者連絡リマインダは、特定のヘルスケア専門家が患者を呼び出すためのリマインダである。

Description

本開示は概して、ヘルスケアを促進するシステムおよび方法に関し、詳細には、患者のヘルスケアをさらに進めるために患者が必要とするアクションを低減するシステムおよび方法に関する。

ヘルスケアは、基本的かつ決定的に重要な問題である。ヘルスケアへのアクセスを改善することは、個人と社会全体に利益をもたらす。

大部分の状況、特に予防ヘルスケアに関して、では、ヘルスケアサービスにアクセスするために、個別のイニシアティブおよびアクションが必要である。必要なイニシアティブおよびアクションは、対象のケアによって異なる。例えば、個人は、病理クリニック、医師、その他のヘルスケア専門家を手配して出向いたり、医薬品の処方箋を記入したり、ヘルスプログラム（例えば、エクササイズプログラム）に従事したり、コミットしたりする必要があるかもしれないし、健康を改善または維持するためにすべきこと、すべきでないことについての知識を単に向上させる必要があるかもしれない。

健康であることの利点を考えれば、健康を増進（あるいは少なくとも維持）するための行動を率先して行うことは、人にとって基本的な優先事項であるはずである。しかし、残念ながらそうではないことが多い。多くの場合、人々は時間に追われる忙しい生活を送っており、自分自身を大切にすることが優先されない。多くの人にとって、医師の予約を取って出向くような簡単なことでさえ、必要不可欠になるまで、つまり本人が許容できるレベルの機能を果たせなくなるまで、後回しにされてしまう。しかし、この時点では、早い段階で対処していれば簡単な問題だったものが、はるかに重大な問題に発展し、修正するためにはより多くの時間と資源が必要になるかもしれない（実際には、後の段階で修正することが可能であればであるが）。

このことから、個人への教育（ヘルスケアの優先順位を上げることにつながる）と、個人へのヘルスケアサービスの提供の両方の摩擦を減らすことに大きな価値がある。

ヘルスケアへのアクセスを、ある程度まで、単純化するのを支援するさまざまな技術ツールが利用可能である。例えば、いくつかのヘルスケアセンター／医師の手術は予約をより簡単にするために、ウェブベースまたはアプリケーションベースの予約システムのいずれかを提供する。同様に、ヘルスケア製品を入手することは、おそらく、電子商取引システムおよびオンライン注文の台頭に伴って、より単純になってきた。しかしながら、これらの解決策は、依然として、個人が予約を行うためのイニシアティブをとることに依存している。

一態様では、本発明は、ヘルス管理システムが、患者に関する患者ヘルスデータを受信し、ヘルス管理システムが、患者ヘルスデータを分析し、特定のタイプのヘルスケア専門家との関与が必要であることを決定し、ヘルス管理システムが、特定のタイプの特定のヘルスケア専門家を決定し、ヘルスケア専門家エンゲージメントインターフェイスを生成させ、特定のタイプのヘルスケア専門家とのエンゲージメントが必要であり、連絡禁止制御を示す情報を含むヘルスケア専門家エンゲージメントインターフェイスを生成させ、連絡禁止制御がアクティブ化されていないと決定された場合、特定のヘルスケア専門家に対して患者連絡リマインダを生成させ、患者連絡リマインダは、特定のヘルスケア専門家が患者を呼び出すためのリマインダである、コンピュータ実装方法を提供する。

第２の態様では、本発明は、ヘルス管理システムが、患者に関する患者ヘルスデータを受信し、ヘルス管理システムが、患者ヘルスデータを分析し、ヘルス管理製品が必要であることを決定し、ヘルス管理システムが、ヘルス管理製品の特定のプロバイダを判定し、ヘルス管理システムが、ヘルス管理製品注文インターフェイスを生成させ、ヘルス管理製品に関する情報および注文禁止制御を含むヘルス管理製品注文インターフェイスを生成させ、注文禁止制御がアクティブ化されていないと判定された場合、製品注文を生成し、特定のプロバイダのプロバイダシステムに製品注文を伝送する、コンピュータ実装方法を提供する。

本明細書に記載の実施形態を実施することができる環境とネットワーク化されたコンピュータ処理システムとを示す図である。 本明細書で説明される実施形態を実行するように構成可能なコンピュータ処理システムのブロック図である。 一実施形態による、患者のヘルスデータを取得し、分析するために実行される動作を示すフローチャートである。 一実施形態による、ヘルスレポートインターフェイスデータを生成するために実行される動作を示すフローチャートである。 一実施形態による例示的なヘルスレポートインターフェイスである。

本明細書に記載されている実施形態は、ヘルスケアサービスへのアクセスを簡素化するように動作する。一般的に言えば、これは、患者が自分のヘルス管理を進めるために必要な行動を減らし、および／または、そうすることに対する患者のモチベーション／コミットメントを高めるように、コンピュータシステムを動作させる（および、場合によっては相互運用する）ように構成することによって達成される。

最初に、本明細書で説明される実施形態で動作するように構成される、関連するさまざまなシステムの高レベルの概要が提供される。これに続いて、本明細書で説明するさまざまな動作および機能を実行するように構成することができるコンピュータ処理システムについて説明する。以下、各システムの動作について説明する。

図１を参照して、本開示のさまざまな態様に関与するさまざまなコンピュータ処理システムを含むネットワーク環境１００を説明する。

環境１００は、ヘルスケア管理システム１１０と、患者システム１３０と、ヘルスケア専門家システム１５０と、製品プロバイダシステム１７０と、コンテンツプロバイダシステム１９０とを含む。これらのシステムは、一つ以上の電気通信ネットワーク１０２を介して相互接続される。

簡潔にするために、以下の略語が本明細書で使用される。ＨＭＳはヘルスケア管理システムを表し、ＰＳは患者システムを表し、ＨＰはヘルスケア専門家を表し、ＨＰＳはヘルスケア専門家システムを表し、ＰＰＳは製品プロバイダシステムを表し、ＣＰはコンテンツプロバイダを表し、ＣＰＳはコンテンツプロバイダシステムを表す。

ＨＭＳ１１０は、機能的には、ＨＭＳサーバ１１２、ＰＰＳアプリケーション１１４、ヘルス評価アプリケーション１１６、およびＨＭＳデータベース１１８を含む、コンピュータ処理システム（またはコンピュータ処理システムのグループ）である。

ＨＭＳサーバアプリケーション１１２（参照を容易にするためにＨＭＳサーバ１１２とも呼ばれる）は、ＨＭＳ１１０によって実行されると、ＨＭＳクライアントアプリケーション（例えば、患者システム１３０上で実行される患者クライアント１３２、ＨＰＳ１５０上で実行されるＨＰクライアント１５２）のためのサーバ側機能を提供するようにＨＭＳ１１０を構成するソフトウェアアプリケーションである。

ＨＭＳサーバ１１２は、さまざまな方法で実現することができる。例えば、ＨＭＳサーバ１１２はクライアント（例えば、クライアント１３２または１５２）にウェブインターフェイスを公開するためにＨＭＳ１１０上で実行されるウェブサーバアプリケーションであってもよい。この場合、関連するクライアント１３２／１５２は、ウェブブラウザアプリケーション又はウェブブラウザ機能を有するアプリケーションである。あるいは、ＨＭＳサーバ１１２は、ＨＭＳ１１０上で実行されるアプリケーションサーバであって、クライアント（例えば、クライアント１３２または１５２）にプログラマティックインターフェース（ＡＰＩ）を提供することができる。この場合、関連するクライアント１３２／１５２は専用のヘルスケア管理システムクライアントアプリケーション（例えば、アプリ）であり、クライアントおよびサーバは、定義されたＡＰＩコールを介して互いに通信する。

ＰＰＳアプリケーション１１４は、ＨＭＳ１１０によって実行されると、ＰＰＳ１７０などの製品プロバイダシステムと通信するようにＨＭＳ１１０を構成するソフトウェアアプリケーションである。以下でさらに説明するように、ＨＭＳ１１０は患者に代わってヘルスケア製品（例えば、医薬品または他のヘルスケア製品）を注文するためにＰＳＰと通信する。ＰＰＳアプリケーション１１４は、単一のＰＰＳまたは複数の異なるＰＰＳと通信するように構成することができる（あるいはそれぞれが異なるＰＰＳへのアクセスを提供する、複数のＰＰＳアプリケーション１１６を提供することができる）。

ヘルス評価アプリケーション１１６はＨＭＳ１１０によって実行されると、患者のヘルスデータを分析し、それに基づいてさまざまなヘルス評価出力を生成するようにＨＭＳ１１０を構成するソフトウェアアプリケーションである。本開示では、ヘルス評価アプリケーション１１６によって生成されるヘルス評価出力がレポート出力およびアクション出力を含む。

レポート出力は、患者（および／またはある場合にはヘルスケア専門家）にレポートされる出力である。一例として、以下でさらに説明するように、レポート出力は、患者ヘルスレポート、患者ヘルスプラン、および患者教育プランを含むことができる。

アクション出力は患者のヘルスケアを促進する際の患者への負担を軽減するために、ＨＭＳ１１０が追加の動作を実行するための出力である。例として、アクション出力は、エンゲージメントアクション出力（これはヘルスケア専門家とのコールまたは予約を促進するためにさらに処理される）および製品注文アクション出力を含み得る。

ＨＭＳデータベース１１８は、ＨＭＳ１１０によって必要とされるデータを記憶する。これは、例えば、ユーザ名および認証詳細（例えば、患者アカウント、ヘルスケア専門家アカウント、およびシステム管理者アカウントに関する）、例えば、患者アンケートを通して、および／またはヘルスケア専門家から取得されるような患者データ、ＨＭＳ１１０と対話するヘルスケア専門家によって提供される連絡詳細およびサービスなどのヘルスケア専門家データ、例えば、ＰＰＳ１７０などのさまざまな製品プロバイダシステムと接続し、対話するために必要とされる製品プロバイダシステムデータ、患者データを分析し、レポートおよび／またはアクション出力を生成するためにヘルス評価アプリケーション１１８によって使用されるヘルス評価データを含むことができる。

ＨＭＳデータベース１１８は単一のデータベースとして描かれているが、実際にはいくつかの別個のデータベースであってもよい。例えば、センシティブな患者データはＨＭＳ１１０によって使用される他のデータ（例えば、ユーザアカウント／信用証明データ、ヘルス評価データなど）を格納するデータベース（またはそれら）とは別個のデータベースによって格納されてもよい。

図１では、ＨＭＳ１１０が単一のシステムとして示されている。ＨＭＳ１０２の機能は、必要に応じて互いにデータを通信する複数のコンピュータ処理システムによって実行することができる。

一例として、ＨＭＳサーバ１１２は、ＰＰＳアプリケーション１１４、ヘルス評価アプリケーション１１６、および／またはＨＭＳデータベース１１８に対する別個のハードウェアシステム上で実行することができる。あるいは、ＨＭＳサーバ１１２が実際には複数のサーバアプリケーション（例えば、１つは患者クライアント１３２を扱うため専用であり、１つはＨＰクライアント１５２とのデッドライン専用である）であってもよい。

患者およびヘルスケア専門家に加えて、ＨＭＳサーバ１１２は、追加のタイプのユーザへのアクセスおよび特定の機能を提供する。例えば、少なくとも管理者ユーザのためのアクセスが提供され、これを介して、管理者は、ＨＭＳ１１０に関して、設定、更新、および他の管理動作を実行することができる。

ＨＭＳサーバ１１２、ＰＰＳアプリケーション１１４、ヘルス評価アプリケーション１１６、および／またはＨＭＳデータベース１１８は、ユーザ／システム要求に基づいてリソースを自動的にプロビジョニング／プロビジョニング解除するようにプログラムされたスケーラブルなシステムとして構成することができる。

患者システム１３０は、ＨＭＳ１１０と対話するために患者によって使用されるコンピュータ処理システムである。この対話を促進するために、ＰＳ１３０は患者クライアント１３２を含む。患者クライアント１３２は、ＰＳ１３０によって実行されると、ＨＭＳクライアント側患者機能を提供するようにＰＳ１３０を構成するソフトウェアアプリケーションである。

ヘルスケア専門家システム１５０は、ＨＭＳ１１０と対話するためにヘルスケア専門家によって使用されるコンピュータ処理システムである。この相互作用を促進するために、ＨＰＳ１５０は、ＨＰクライアント１５２を含む。ＨＰクライアント１５２は、ＨＰＳ１５０によって実行されると、ＨＭＳクライアント側ヘルスケア専門家機能を提供するようにＨＰＳ１５０を構成するソフトウェアアプリケーションである。

患者機能（患者クライアント１３２によって提供される）およびＨＰ機能（ＨＰクライアント１５２によって提供される）は、以下でさらに説明される。しかしながら、一般的に言えば、クライアント側の機能は通信ネットワーク１０２を介してＨＰＳサーバ１１２からデータを受信し、そこからデータを伝送することと、ＰＳ１３０またはＨＰＳ１５０上でユーザインターフェイスを生成し、表示する（または他の方法で提供する）ことと、ＰＳ１３０またはＨＰＳ１５０で入力されたユーザ入力を受信することとを含む。ＨＭＳサーバ１１２がウェブサーバである場合、対応するクライアント１３２、１５２は典型的にはＣｈｒｏｍｅ、Ｓａｆａｒｉ、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、またはワールドワイドウェブプロトコル（例えば、ｈｔｔｐ、ｈｔｔｐｓ）を介してウェブサーバと通信する他のアプリケーションのようなウェブブラウザアプリケーションである。あるいはＨＭＳサーバ１１２がアプリケーションサーバである場合、対応するクライアント１３２／１５２は定義されたＡＰＩ通信を使用してＨＭＳサーバ１１２と通信する専用アプリケーションである。

患者システム１３０およびＨＰシステム１５０の各々は典型的にはパーソナルコンピューティング装置、例えば、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン、または他のコンピューティング装置である。したがって、患者およびＨＰシステム１３０および１５０には、図示および説明したものに追加のソフトウェアアプリケーションが提供／実行される。例えば、少なくとも、患者およびＨＰシステム１３０および１５０の各々には、基本的な機能を促進するためのオペレーティングシステムが提供される。

製品プロバイダシステム１７０は、ヘルスケア製品のオンライン注文を提供するエンティティによって運営されるコンピュータ処理システムである。これは、一般に、ヘルスケア製品の注文（および支払い詳細および配達詳細などの関連情報）を受け取り、それらの注文を履行するように手配することを含む。製品プロバイダシステムの例には、Ａｍａｚｏｎ、薬局電子商取引システム、および他の電子商取引システムが含まれる。ＰＰＳ１７０は、ＨＰＳ１１０のＰＰＳアプリケーション１１４によって伝送される注文および関連情報を受信するように構成されたＰＰＳサーバ１７２を含む。製品プロバイダシステム１７０は典型的には（必ずしも必要ではないが）、ＨＭＳ１１０を所有する／運営するエンティティとは別個のエンティティによって所有され、運営され、そのサービスを提供するために、通常、図示の単一のＰＰＳサーバ１７２に追加の機能コンポーネントを含む。

コンテンツプロバイダシステム１９０はコンテンツを記憶し、ユーザに提供するコンピューティングシステムである。以下でさらに詳細に説明するように、ある場合には、所与の患者に対するヘルス評価アプリケーション１１８のレポート出力が教育プランを含む。場合によっては、教育プランがＣＰＳ１９０によってホストされるコンテンツへの参照を含む。このコンテンツへのアクセスを可能にするために、ＣＰＳ１９０は（ＰＳ１３０上で動作するクライアント１３４またはＨＰＳ１５０上で動作するクライアント１４２などのＣＰＳクライアントから）コンテンツ要求を受信し、それに応答するＣＰＳサーバ１９２を含む。ＣＰＳサーバ１９２は、ウェブサーバまたはアプリケーションサーバであってもよい。例として、ＣＰＳ１９０は任意の形態（例えば、テキスト、画像、ビデオ、オーディオ）でヘルスケア情報へのアクセスを提供する任意のウェブサイトまたはアプリケーションであってもよい。

環境１００は単一の患者システム１３０、単一のＨＰＳ１５０、単一のＰＰＳ１７０、および単一のＣＰＳ１９０と共に示されているが、環境１００は典型的には複数の患者によって所有／操作される複数の患者システム１３０、複数のＨＰによって所有／操作される複数のＨＰＳ１５０を含む。環境１００はまた、複数の製品プロバイダシステム１７０および／または複数のコンテンツプロバイダシステム１９０を含んでもよい。

上述の環境１００ではＨＭＳ１１０、ＰＳ１３０、ＨＰＳ１５０、ＰＰＳ１７０、およびＣＰＳ１９０のそれぞれはコンピュータ処理システム（または動作を実行し、本明細書で説明する機能を提供するように相互動作するように構成された複数のコンピュータ処理システム）である。

図２は本明細書で説明するように、ＨＭＳ１１０、ＰＳ１３０、ＨＰＳ１５０、ＰＰＳ１７０、および／またはＣＰＳ１９０になるように構成することができる汎用コンピュータ処理システム２００のブロック図を提供する。

システム２００は、少なくとも１つの処理ユニット２０２を含む。処理ユニット２０２は単一のコンピュータ処理装置（例えば、中央処理ユニット、グラフィックス処理ユニット、または他の計算装置）であってもよく、または複数のコンピュータ処理装置を含んでもよい。いくつかの例では所与のコンピュータ処理システム２００によって実行されるものとして説明されるすべての処理がその処理ユニット２０２によって実行されるが、他の例では処理がシステム２００によってアクセス可能かつ（共有または専用の方法のいずれかで）使用可能なリモート処理デバイスによって実行されてもよい。

通信バス２０４を介して、処理ユニット２０２は、処理システム２００の動作を制御するための命令および／またはデータを記憶する１つ以上の機械可読記憶装置とデータ通信している。このインスタンスにおいて、システム２００はシステムメモリ２０６（例えば、ＢＩＯＳ）、揮発性メモリ２０８（例えば、１つ以上のＤＲＡＭモジュールのようなランダムアクセスメモリ）、および不揮発性メモリ２１０（例えば、１つ以上のハードディスクドライブ、ソリッドステートドライブ、または他の永続的記憶装置）を含む。

システム２００はまた、一般に、２１２によって示される１つ以上のインターフェイスを含み、このインターフェイスを介してシステム２００は、さまざまな装置および／またはネットワークとインターフェイスする。一般的に言えば、他の装置はシステム２００と一体であってもよいし、別個であってもよい。装置がシステム２００から分離されている場合、装置とシステム２００との間の接続は有線または無線のハードウェアおよび通信プロトコルを介してもよく、直接的または間接的な（例えば、ネットワーク化された）接続であってもよい。

他のデバイス／ネットワークとの有線接続は、任意の適切な標準または独自のハードウェアおよび接続プロトコル（例：ＵＳＢ、ｅＳＡＴＡ、Ｅｔｈｅｒｎｅｔ（登録商標）、ＨＤＭＩ（登録商標）など（他のプロトコルも可能））によって可能である。

他の装置／ネットワークとの無線接続は同様に、任意の適切な標準又は専有のハードウェア及び通信プロトコル、例えば、ＢｌｕｅＴｏｏｔｈ（登録商標）、ＷｉＦｉ、ＮＦＣ、ＧＳＭ（登録商標）、ＥＤＧＥ、ＬＴＥ、ＣＤＭＡなどによって可能である（他のプロトコルも可能である）。

一般的に言えば、システム２００が接続する装置は、有線またはワイヤレス手段のいずれかによって、処理ユニット２０２による処理のためにデータがシステム２００に入力／受信されることを可能にする１つまたは複数の入力装置と、データがシステム２００によって出力されることを可能にする１つまたは複数の出力装置とを含む。例示的な装置を以下で説明するが、すべてのコンピュータ処理システムがすべての言及された装置を含むわけではなく、言及された装置に追加の代替の装置を使用することができることが理解されよう。

例えば、システム２００は情報／データをシステム２００に入力する（受信する）１つ以上の入力装置を含んでもよいし、それに接続してもよい。そのような入力装置は、キーボード、マウス、トラックパッド、マイクロホン、加速度計、近接センサ、ＧＰＳ装置等を含み得る。システム２００はまた、情報を出力するためにシステム２００によって制御される１つまたは複数の出力デバイスを含むか、またはそれに接続することができる。そのような出力装置はディスプレイ装置（例えば、ＣＲＴ／ＬＣＤ／ＬＥＤ／プラズマディスプレイ）、タッチスクリーンディスプレイ（入力および出力の両方を提供する）、スピーカ、振動モジュール、ライトなどを含んでもよい。システム２００はまた、入力デバイスおよび出力デバイスの両方として働くことができるデバイス、例えば、システム２００がデータを読み書きすることができるメモリデバイス（ハードドライブ、ソリッドステートドライブ、ディスクドライブ、コンパクトフラッシュ（登録商標）カード、ＳＤカードなど）、およびデータを表示（出力）し、タッチ信号（入力）を受信することができるタッチスクリーンディスプレイを含むか、またはそれらに接続することができる。

システム２００はまた、１つ以上の通信ネットワーク（例えば、インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、パーソナルホットスポット等）に接続して、ネットワーク化された装置との間でデータを伝送し、受信することができる。

システム２００は、限定されない例として、サーバコンピュータシステム、デスクトップコンピュータ、ラップトップコンピュータ、ネットブックコンピュータ、タブレットコンピューティングデバイス、モバイル／スマートフォン、パーソナルデジタルアシスタント、または他の任意のシステムなどの任意の適切なコンピュータ処理システムであってもよい。

システム２００は処理ユニット２０２によって実行されると、システム２００がデータを受信、処理、および出力するように構成するコンピュータアプリケーション（例えば、命令およびデータ）を記憶またはアクセスする。このようなプログラムには、通常、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ ＯＳＸ、Ａｐｐｌｅ ＩＯＳ、Ａｎｄｒｏｉｄ（登録商標）、Ｕｎｉｘ（登録商標）、またはＬｉｎｕｘ（登録商標）などのオペレーティングシステムが含まれる。

システム２００はまた、命令およびデータ（すなわち、アプリケーション／ソフトウェア）へアクセスするかまたは記憶するが、これらは処理ユニット２０２によって実行されるとき、本明細書に記載するように、システム２００を構成して、さまざまなコンピュータ実施プロセス／方法を実行する。そのようなアプリケーションの例には、上述のように、患者サーバ１１２、ＨＰＳサーバ１１２、ＰＰＳアプリケーション１１６、ヘルス評価アプリケーション１１８、ＨＭＳデータベース１１８、患者クライアント１３２、ＨＰクライアント１５２、ＣＰＳクライアント１３４／１５４、ＰＰＳサーバ１７２、およびＣＰＳサーバ１９２が含まれる。

命令およびデータは、システム２００にアクセス可能な非一時的機械可読媒体に記憶される。例えば、命令およびデータは、非一時的メモリ２１０上に格納することができる。命令は、有線または無線ネットワーク接続によって（例えば）イネーブルされた送信チャネル内のデータ信号を介してシステム２００に送信／受信され得る。

図２は、コンピュータ処理システムのすべての機能的または物理的構成要素を示しているわけではないことを理解されたい。例えば、電源または電源インターフェイスは示されていないが、システム２００は電源を搬送するか、または電源（またはその両方）に接続するように構成される。特定のタイプのコンピュータ処理システムは適切なハードウェアおよびアーキテクチャを決定し、本発明の態様を実施するのに適した代替のコンピュータ処理システムは、図示されたものよりも追加の、代替の、またはより少ない構成要素を有することができることも理解されよう。

本明細書で説明する機能を提供するために、さまざまなＨＭＳ１１０のセットアップおよび管理動作が実行される。これらの動作の概要はこのセクションで説明され、これらの動作の多く（例えば、ユーザアカウントの作成および管理）は当業者に知られており、さまざまな方法で実装され得ることを認識する。

患者がＨＭＳ１１０と対話するために、患者アカウントが作成される。患者アカウントは患者がＨＭＳ１１０によって提供されるサービスにアクセスし、それを利用することを可能にするさまざまな情報を含む。この情報は例えば、患者ユーザ名、患者認証／認証の詳細（例えば、パスワード及び／又は他の認証データ）、患者名、患者連絡先の詳細（例えば、電子メールアドレス、電話番号、住所等）を含む。アカウントを作成するときに、患者は特定の患者デモグラフィックデータ、例えば、生年月日及び性別を提供することもできる。

患者アカウントは患者自身によって（患者クライアント１３２を介してＨＭＳ１１０にアクセスして）、ＨＭＳアドミニストレータによって、またはそれらの組み合わせによって（例えば、ＨＭＳアドミニストレータが患者アカウントを作成し、患者にログオン詳細を提供し、患者は、さらなる患者情報を提供することによってアカウントプロセスを完了する）作成されてもよい。

患者アカウントを作成する時、またはＨＭＳ１１０を使用する過程の何れかで、患者は、追加の患者情報を提供／更新する、および／またはその患者に対するＨＭＳ１１０の操作に影響を与えるさまざまな患者ユーザパラメータを定義することができる。例えば、患者は好ましい患者連絡先の詳細、（製品発注目的のための）好ましい配送先住所、異なるタイプのサービスのための好ましいヘルスケア専門家（例えば、好ましい一般開業医、好ましい歯科医、好ましい眼科医、好ましい理学療法士、および／または他の好ましい専門家）、好ましいヘルスケア専門家の場所（例えば、患者の自宅住所、仕事先住所、または他の住所の近く）、ヘルスケア製品の好み（例えば、一般製品がブランド名製品の許容可能な代替品であるか否か）、支払いの詳細（クレジットカードまたは他の支払いアカウントの詳細など）、ヘルスケア保険会社の詳細、政府のヘルスプログラムの詳細、および任意の他の関連する好み／情報のうちの１つまたは複数を定義することができる。

ヘルスケア専門家がＨＭＳ１１０と対話するために、ＨＰアカウントが作成される。ＨＰアカウントには、ＨＰがＨＭＳ１１０によって提供されるサービスにアクセスして利用できるようにするさまざまな情報が含まれている。この情報は例えば、ＨＰユーザ名、ＨＰ許可／認証の詳細（例えば、パスワードおよび／または他の認証データ）、ＨＰ名、ＨＰ連絡先の詳細（例えば、電子メールアドレス、電話番号、ＨＰアドレスなど）、提供されるサービスのタイプ（例えば、一般開業医サービス、眼科サービス、歯科サービス、理学療法サービス、他のサービス）、ヘルスケア専門家が在宅／オフサイト訪問を行うかどうか、およびそのうち、サービスされる領域、任意の他の関連する詳細を含む。

ＨＰアカウントはＨＰ自体（ＨＰクライアント１５２を介してＨＭＳ１１０にアクセスする）、ＨＭＳ管理者、またはそれらの組み合わせ（ＨＰアカウントを作成し、ＨＰの詳細情報を提供することによってアカウントプロセスを完了するＨＰにログオンの詳細を提供するＨＭＳ管理者など）によって作成される場合がある。

ＨＰアカウントを作成するときに、またはＨＭＳ１１０を使用する過程にわたって、ＨＰは追加のＨＰ情報を提供／更新し、および／またはそのＨＰのためのＨＭＳ１１０の動作に影響を及ぼすさまざまな患者ＨＰユーザパラメータを定義することができ、たとえば、ＨＰはＨＭＳ１１０がＨＰカレンダにアクセスすることを可能にするカレンダアクセスデータを提供することができる（たとえば、患者からのコールを待ち行列に入れる、および／または予約を行う）。

ユーザアカウントの詳細（患者アカウントの詳細、ＨＰアカウントの詳細、ＨＭＳ管理者アカウントの詳細を含む）は必要に応じて、ＨＭＳ１１０によるアクセス／使用のために、例えば、ＨＭＳデータベース１１８に格納される。

特定の実施形態では、ＨＭＳ１１０がＰＰＳ１７０などの１つまたは複数の製品プロバイダシステムと対話するように構成される。そのような構成は例えば、ＰＰＳサーバ１７２と対話するためにＰＰＳアプリケーション１１６によって使用されるＰＰＳアクセス証明書を（例えば、ＨＭＳデータベース１１８に）格納することによって、さまざまな方法で実行されてもよい。

ＨＭＳ１１０はまた、クエリ生成データ、患者ヘルスデータ、ヘルス評価データ、およびヘルス教育データを、例えばＨＭＳデータベース１１８に格納する。

クエリ生成データは、クエリを生成するためにＨＭＳ１１０によって使用され、クエリは次に、患者クエリ応答データ（１つのタイプの患者ヘルスデータ）を取得するために使用される。一般的に言えば、患者クエリ応答データを取得することはＨＭＳサーバ１１２が患者クライアント１３２に患者クエリを提供することを含み、これは次に、患者システム１３０によってクエリが表示されるか、さもなければ提示されるようにする。患者は（例えば、タッチスクリーンまたはキーボードなどの入力デバイスを使用して）クエリに応答し、患者クライアント１３２はＨＭＳデータベース１１８内の患者クエリ応答データとして保存されるように、応答を患者サーバ１１２に返信する。

クエリ生成データおよびそれから生成されるクエリは典型的には患者のヘルスを評価することに関連するさまざまなタイプの情報、例えば、デモグラフィック情報、アクション情報、ヘルス履歴情報、および病理学／生体情報を収集することを目的とする。患者のデモグラフィック情報は例えば、年齢、性別、人種、収入などの情報を含むことができる。患者のアクション情報には、例えば、摂食／食習慣、喫煙習慣、飲酒習慣、薬物消費習慣、エクササイズ習慣、睡眠習慣、作業習慣、ストレスレベルなどの情報が含まれる。ヘルス歴情報には、例えば、現在／以前の医学的状態；患者の家族の病歴；患者が服用している現在の薬剤、などの情報が含まれ得る。

クエリ生成データは患者のヘルスを評価することに関連する（または関連する可能性がある）他の項目またはタイプの患者データに対するヘルスケア調査ポイントとして、（例えば、ＨＭＳ管理者ユーザによって）定期的に更新される。

前述のように、患者問合せ応答データは、患者ヘルスデータの一種である。ＨＭＳ１１０によって受信され、記憶される他のタイプの患者ヘルスデータは患者病理学／バイオメトリックデータ（例えば、血液型、血圧、血液／糖測定値、身長、体重、ウエスト測定値）を含む。患者病理学データは患者自身（患者サーバ１１２及び患者クライアント１３２の操作を介して）及び／又は患者に代わってヘルスケア専門家（例えば、医師、専門家、病理臨床医、看護師等）によりＨＭＳ１１０に提出することができる。これはＨＰＳサーバ１１２及びＨＰクライアント１５２の操作を介して行われる。

ヘルス評価データはＨＭＳ１１０に利用可能な（例えば、ＨＭＳデータベース１１８に記憶された）患者ヘルスデータを分析し、それに基づいてさまざまな出力を生成するために使用される。

クエリ生成データと同様に、ヘルス評価データはヘルスケア研究が発展することにつれて、（例えば、ＨＭＳ管理者ユーザによって）定期的に更新される。

ヘルス教育データは、教育コンテンツ、または他のコンテンツプロバイダシステム（ＣＰＡ１９０など）上に維持される教育コンテンツへのリンクのいずれかを提供する。教育内容は、記事、本、ウェブページ、ビデオ、音声、インフォグラフィック、および／または情報を伝達するための任意の他の手段の形態であってもよい。ヘルス教育コンテンツも、異なる教育コンテンツが利用可能になるにつれて更新される。

図３を参照して、一実施形態によるＨＭＳ１１０によって実行される動作を説明する。

プロセス３００の動作は患者データを提供し、ヘルス評価レポートを取得するために、患者ユーザがＨＭＳサーバ１１２に（具体的には患者クライアント１３２を介して）アクセスする状況で実行される。しかしながら、ある場合には、患者のヘルスケア専門家が（ＨＰクライアント１５２を介して）ＨＭＳサーバ１１２にアクセスして、患者の代わりに患者のヘルスデータを提供することができる。

３０２において、ＨＭＳサーバ１１２は、問題の患者を識別する。患者は、ＨＭＳサーバ１１２にログオン／アクセスするために患者によって使用されるアカウントに関連するアカウント詳細によって識別される。

３０４において、ＨＭＳサーバ１１２は識別された患者に関連し、ＨＭＳ１１０によって既に記憶されている（例えば、ＨＭＳデータベース１１８に）任意の関連する患者データを検索する。場合によっては、例えば、患者が初めてＨＭＳ１１０にアクセスしており、関連するデータをまだ提供していない場合、関連する患者データが利用可能でないことがある。その他の場合には、少量の患者データ（例えば、患者のアカウント作成時に提供された患者のデモグラフィックデータ）がすでに存在することになる。さらに別の場合には例えば、患者が以前にプロセス３００を経ていた場合には実質的な患者データがＨＭＳ１１０によって既に記憶されていてもよい。

３０６において、ＨＭＳサーバ１１２は所望の患者ヘルスデータを取得するために、患者に提供されるクエリのセットを生成する。クエリのセットは、クエリ生成データと、３０４で取り出された任意の関連する患者ヘルスデータとに基づいて生成される。いくつかの場合、例えば、患者のヘルスデータが利用可能でない場合、ＨＭＳサーバ１１２は、クエリのデフォルトセットを生成する。他の場合には、ＨＭＳサーバ１１２が３０４で検索された関連する患者データに基づいて、患者固有（または患者タイプ固有）のクエリのセットを生成する。例えば、特定のクエリは患者の性別および／または年齢、患者がすでに応答したクエリなどに応じて、特定の患者に提供されてもよいし、提供されなくてもよい。

上述したように、一般的に言えば、生成することができるクエリのタイプは、患者のデモグラフィック、アクション、ヘルス履歴、および／またはラボ／生体情報に関する情報を取得するように設計されたクエリを含む。

デモグラフィック関連クエリの例には、以下のようなクエリが含まれる。年齢はいくつですか？性別は何ですか？人種は何ですか？収入レベルはどれくらいですか？

アクション関連クエリの例には、以下のものが含まれる。喫煙しますか？アルコールを飲んでいますか？エクササイズをする頻度はどれくらいですか？

ヘルス履歴関連の問い合わせの例には、以下のものがある。家族にｘ病の病歴がありますか？心臓発作を起こしたことがありますか？現在、薬を服用していますか？

ラボ／バイオメトリック関連の問い合わせの例には、以下のものが含まれる：身長はどれくらいですか？体重はどれくらいですか？ウエストの測定値はいくつですか？

３０８において、ＨＭＳサーバ１１２は患者クライアントアプリケーション１３２に、患者システム１３０上に患者クエリインターフェイスを生成させる。患者クエリインターフェイスは３０６で決定されたクエリを提示し（例えば、表示し）、それに対する応答を受信する。任意の適切な照会インターフェイス、例えば、患者が応答を入力するために利用することができる照会および関連する入力制御を表示するアンケートタイプインターフェイスを使用することができる。

３１０において、ＨＭＳサーバ１１２はクライアントアプリケーション１３２からクエリ応答データ、すなわち、クエリインターフェイスに提示されたクエリに応答する患者に応答してクライアントアプリケーション１３２によって生成されたデータを受信する。

３１２において、ＨＭＳサーバ１１２は、クエリ応答データをＨＭＳデータベース１１８に格納する（応答データが問題の患者に関連付けられる）。

３１４において、ヘルス評価アプリケーション１１６は利用可能な患者ヘルスデータ（例えば、以前に受信された患者データと共に３１２に格納されたクエリ応答データ）を分析し、１つ以上の出力を生成する。ＨＭＳ１１０が患者ヘルスデータを分析する特定の方法は、本開示の焦点ではなく、当技術分野で知られているさまざまな技法を分析に使用することができる。例えば、ヘルス評価アプリケーション１１６は、ＨＭＳデータベース１１８に格納された患者ヘルスデータ及びヘルス評価データに基づいて出力を生成するエキスパート又はルールベースのシステムであってもよい（又はこれを含むか又はこれを利用してもよい）。

上述のように、本開示では、患者のヘルスデータを分析することによって生成される出力が（問題の患者のヘルスデータおよび実行された分析に応じて）レポート出力およびアクション出力を含むことができる。レポート出力に関して、上述のように、本開示は、患者ヘルスレポート、患者ヘルスプラン、および患者教育プランの生成を明示的に企図する。アクション出力に関して、また、上述したように、本開示は、エンゲージメントアクション出力、および製品注文アクション出力の生成を明示的に企図する。ヘルス評価アプリケーション１１６は、追加のおよび／または代替のレポート出力および／またはアクション出力を生成するように構成され得る。特定の患者についての特定の出力は、患者のヘルスデータおよびその分析の結果に依存する。

患者ヘルスレポートには、患者のヘルスに関する情報が含まれる。この情報は、例えば以下のうちの１つまたは複数を含むことができる。
●スコア、カラーコード（例えば、深刻かつ即時の危険性については赤、中等度の危険性についてはオレンジ、低危険性については緑）または他のインジケータのような全体的なヘルスインジケータ。
●患者に関連する特定のヘルス領域に関する特定のヘルス領域インジケータ（例えば、スコア、カラーコード又は他のインジケータ）、例えば、メンズヘルス、心臓のヘルス、心及び気分のような領域。
●特定の疾患または状態に対する患者の感受性に関する情報（例えば、疾患／状態ｘに対する感受性が低い／中等度／高い）。
●患者のアクション項目－すなわち、患者が引き受けることができ、ヘルスに有益な影響を及ぼすアクション。（このような患者のアクションは上述の「アクション出力」と混同されるべきではなく、「アクション出力」はさらなるＨＭＳ１１０の動作（以下に記載される）を含むが、患者のアクションは、単に、患者がアクションを行うために患者に提示される情報であるか否かの違いである。

特定の実施形態では、患者アクション項目が重要度ランキングに関連付けられる。重要度ランキングはさまざまな要因、例えば、アクションが理想的に行われるべき緊急度、アクションの影響、および／またはアクションに関連する困難（または知覚される困難）に基づくことができる。例えば、分析が患者に対して特定のアクションｘを示唆するが、ｘを実行する患者の利益が低い場合、これは典型的には低い重要度ランキングを与えられる（特に、ｘが高い困難性を有する場合）。逆に、分析が患者に対してあるアクションｙを示唆し、患者がｙを実行できない可能性が高い場合、これは典型的には重要度の高い順位付けで提供されるのであろう。さらに、患者を圧倒しないために、／患者が決定された患者アクション項目のいずれも引き受けない可能性を増加させないために、患者アクション項目の最大数（例えば、１、２、３、ｎ）が生成される（又は下流で、患者に送達される）ことがある。

一例を提供するために、特定の患者についての上位３つの患者アクション項目は、１）喫煙を停止すること、２）より多くエクササイズすること、３）赤身肉をあまり食べないことであり得る。

患者のヘルスプランには、患者がヘルス状態の改善（または状況に応じて、ヘルス状態を維持／悪化を遅らせる）のために行うと考えられるさまざまなアクションに関する情報が含まれる。例として、患者ヘルスプランは、エクササイズプラン、ダイエット／食事プラン、禁煙プランのうちの１つ以上を患者に提供してもよい。

見ても分かるように、患者のヘルスプランが患者のアクション項目と整合している場合もある。例えば、決定された患者のアクション項目が禁煙である場合、患者のヘルスプランには禁煙プランを含めることができる。

多くの場合、患者が持っている／そうである特定の疾患または状態を理解するのを助け、その疾患／状態に対処する患者のアクション意欲／意欲を高めやすい。したがって、教育プランは、３１４における患者ヘルスデータの分析が患者に関連しているか、または関連する可能性があることを示す疾患または状態に関する情報を提供するコンテンツプロバイダシステム（ＣＰＳ１９０など）によってホストされるコンテンツアイテムへの１つまたは複数のコンテンツアイテム／リンクを含む。例えば、患者のヘルスデータの分析が、患者が糖尿病を有するか、または糖尿病の影響を受けやすいことを示す場合、生成される教育プランは、糖尿病、それをどのように管理するか、および／またはそれを管理しない結果を説明するコンテンツアイテム（またはそれへのリンク）を含むことができる。コンテンツがリンクを介して患者に提供される場合、リンクは患者システム１３０上で（例えば、患者クライアント１３２を介して）患者に表示される。リンクの起動により、患者システム１３０はリンク内に定義されたＣＰＳ１９０にアクセスして、関連するコンテンツを取り出し、次いで、患者システム１３０はそれを表示する。

エンゲージメントアクションアウトプットは、患者のヘルスデータの分析の結果、ヘルスケア専門家とのさらなる相互作用が必要であるか、正当化される決定が得られた場合に生成される。例えば、分析は患者の病理情報が必要であることを示すか、または患者のヘルスに関するより良い／より包括的な分析を実施するのに役立つことを示してもよく、その場合には病理収集専門家との予約が必要であろう。

あるいは分析結果が、患者が医師（例えば、ＧＰ）との診察に注意を払うように推奨されるようなものであってもよく、これは対面による診察であっても、電話またはテレビ電話による遠隔診察であってもよい。患者がヘルスケア専門家の診察を受けるべきであるとの判定は、患者について計算されたヘルススコアの１つ以上に基づくことがある。例えば、ある実施において、患者の全体的なヘルススコア（または特定のヘルス領域ヘルススコア）が、患者が中等度または高リスクであることを示す場合、これは、医師のコンサルテーション従事アクションアウトプットを引き起こす。

エンゲージメントアクション出力の生成はまた、（ヘルスケア専門家のＨＰクライアント１５２を介した）直接的なヘルスケア専門家の対話によってトリガされてもよい。例えば、ヘルスケア専門家が患者とコンサルテーションしている場合（本人または電話／ビデオ電話のいずれかで）、専門家は患者が同じヘルスケア専門家（例えば、フォローアップコンサルテーション）または別のヘルスケア専門家（例えば、専門家、病理収集ラボまたは他のＨＰ）のいずれかとさらにコンサルテーションを予約すべきであると判定してもよい。この場合、ヘルスケア専門家は適切なユーザインターフェイス（ＨＰクライアント１５２によって生成される）を介してこの情報を入力することができ、この情報は、ＨＭＳサーバ１１２に通信されて、エンゲージメントアクション出力（およびその後のその処理）の生成をトリガする。

以下でさらに議論されるように、エンゲージメント動作出力が生成された場合、ＨＭＳサーバ１１２は必要とされる／提案されるヘルスケア専門家とエンゲージメントする患者を支援するために、それに関してさらなる動作を実行する。

製品注文アクション出力は、患者のヘルスデータの分析が患者がヘルス管理製品を必要とするか、またはヘルス管理製品から利益を得ることができるという決定をもたらすときに生成される。ヘルスケア製品は任意の関連製品、例えば、医療／医薬品（処方箋その他）、またはヘルスケア目的で販売されている他の製品（例えば、化学者／薬剤師／ドラッグストアに一般に見られるタイプの製品）であってもよい。

製品注文アクション出力の生成はまた、（ヘルスケア専門家のＨＰクライアント１５２を介した）直接的なヘルスケア専門家の対話によってトリガされてもよい。例えば、ヘルスケア専門家が患者とコンサルテーションしている場合（対面または電話／テレビ電話）、専門家は、患者が特定のヘルスケア製品を処方されるべきであると決定し得る（またはＨＭＳ１１０によって自動的に示唆された処方箋を確認し得る）。この場合、ヘルスケア専門家は適切なユーザインターフェイス（ＨＰクライアント１５２によって生成される）を介してこの情報を入力することができ、この情報は、ＨＭＳサーバ１１２に伝送されて、製品注文アクション出力（およびその後のその処理）の生成をトリガする。

以下でさらに論じるように、製品注文アクション出力が生成された場合、ＨＭＳサーバ１１２は、それに関してさらなる動作を実行して、患者が必要な／提案された製品を取得するのを支援する。

３１６において、患者ヘルスデータの分析および３１４における出力の生成に続いて、ＨＭＳサーバ１１２はヘルスレポートインターフェイスデータを生成し、３１８において、これを患者システム１３０（またはより詳細には、その上で実行される患者クライアント１３２）に伝送する。ヘルスレポートインターフェイスデータは、患者について生成されたレポートおよび動作出力に関するデータを含む。ヘルスレポートインターフェイスデータは患者クライアント１３２によって使用され、ヘルスレポートインターフェイスを生成し、表示する。このインターフェイスは患者にヘルス分析の結果を提供し、該当する場合には、患者が彼らのヘルス管理を促進するのを支援する。ヘルスレポートインターフェイスデータの生成は図４を参照してさらに説明され、例示的なヘルスレポートインターフェイスは図５を参照してさらに説明される。

ある場合には、レポートインターフェイスデータを患者クライアント１３２に伝送することに加えて、ＨＭＳサーバ１１２は患者のヘルス分析の結果の一部または全部を患者のヘルスケア専門家（すなわち、ヘルスケア専門家のＨＰクライアント１５２）に伝送する。

３２０において、ＨＭＳサーバ１１２は、ヘルスレポートインターフェイスで提供される任意のアクション出力に関して、さらなる処理を実行する。この処理は、図５の例示的な患者インターフェイスにおいて提供される種々の制御に関して以下に記載され、次いで、プロセス３００は終了する。

プロセス３００は、単一の線形プロセスとして描写／説明される。しかしながら、特定の実施形態では、これは当てはまらない。例えば、ヘルス評価アプリケーション１１６は、適応的な方法で、所望の患者ヘルスデータ、したがって患者クエリを決定するように構成することができる。すなわち、所与の患者について決定され、所与の患者に提示される後者のクエリは、以前のクエリから得られた応答に依存する。例えば、患者に提示される早期クエリは、患者が喫煙するかどうかを尋ねることができる。その問い合わせに対する回答が肯定的であれば、ヘルス評価アプリケーション１１６は喫煙に関連するいくつかのさらなる（後の）質問を決定し、これらを患者に提示する原因とする（例えば、患者がどのくらいの期間喫煙しているか、患者がどのくらいヘビーに喫煙しているかを明らかにする）。しかしながら、応答が、患者が喫煙しないというものである場合、これらの問い合わせは省略される。

さらに、多くの場合、プロセス３００（またはその一部）は、所与の患者に対して周期的に繰り返される。例えば、患者は定期的に（例えば、６ヶ月毎に１回、毎年１回、２年毎に１回）システムにアクセスして、彼らのヘルス情報を更新し、更新されたヘルスレポートを受け取ることができる。この場合、ＨＭＳ１１０はどの（もしあれば）さらなるクエリが患者に提示されるべきかを決定するときに、患者によって／患者に代わって提供された以前のクエリ応答、および任意の他の情報（例えば、患者に代わってとられたアクション）を考慮に入れる。

さらなる例として、ヘルス評価アプリケーション１１６は特定の定義されたマイルストーンにおいて、および／または基礎となるヘルス評価データ（および、したがって、関連性があると判定された患者ヘルスデータ）が変化した場合に、患者のデータを自動的に再分析するように構成され得る。例えば、患者の生年月日が、患者がちょうど４０歳になったことを示し、患者のヘルスデータの分析が決定された期間内（例えば、過去６ヶ月以内）に実行されなかった場合、ＨＭＳ１１０は、患者の年齢の増加を考慮して、患者のデータを自動的に再分析するように構成され得る。そのような再分析は患者に提供されるさらなる問い合わせなしに行われてもよく、またはさらなる患者ヘルスデータを取得するために、患者／患者のヘルスケア専門家に連絡すること（例えば、関連するクライアントアプリケーション１３２／１５２、電子メール、または他の手段を介して）を含んでもよい。

さらなる例として、新しい医学研究がｘ（情報の項目であるｘは患者のヘルス歴、デモグラフィック、アクション習慣など）がある状態／疾患を決定するための関連因子であることを示すように明らかになるかもしれない。この場合、ＨＭＳ１１０によって維持されるヘルス評価データは更新されてもよく、ｘに関する情報を取得するために生成された１つまたは複数の新しいクエリ（ｘは以前に関連があると見なされていない）であってもよい。この場合、ＨＭＳ１１０がそのように更新されると、患者は（例えば、電子メールまたはそのクライアントアプリケーション１３２を介して）自動的に連絡を受けて、新たに生成されたクエリを患者に提供し、それに応答して情報を取得することができる。

上述したプロセス３００の３１６および３１８において、ＨＭＳサーバ１１２はヘルスレポートインターフェイスデータを生成し、これをＨＭＳクライアント１３２に伝え、ヘルスレポートインターフェイスの生成を可能にする。

このセクションは、（図４を参照して）一実施形態によるヘルスレポートインターフェイスデータ４００を生成するためのプロセスを説明する。これに続いて、例示的なヘルスレポートインターフェイス５００が、図５を参照して説明される。

４０２において、ＨＭＳサーバ１１２は、レポート出力インターフェイスデータを生成する。レポート出力インターフェイスデータは３１４において、ヘルス評価アプリケーション１１６によって生成されたレポート出力（例えば、患者ヘルスレポート、ヘルスプラン、教育プラン）に基づく情報を含む。ＨＭＳクライアント１３２に伝送されると、レポート出力インターフェイスデータは、ＨＭＳクライアント１３２によってレポート出力インターフェイスを生成するために使用される。

図５のインターフェイス５００（後述）はレポート出力インターフェイス５０２の一例を提供し、そこから、４０２においてＨＭＳサーバ１１２によって生成されたレポート出力インターフェイスデータに関するさらなる詳細が明らかになるであろう。

４０４において、ＨＭＳサーバ１１２は、（３１４において生成されたように）何らかの未処理のヘルスケア専門家のエンゲージメントアクション出力が存在するか否かを判定する。もしそうであれば、処理は４０６に進む。そうでない場合、処理は４１８に進む。

４０６において、ＨＭＳサーバ１１２は、処理する次の未処理のヘルス専門家エンゲージメントアクション出力を選択する。

４０８で、ＨＭＳサーバ１１２は、選択されたアクション出力に関連付けられる１つまたは複数のヘルスケア専門家を決定する。ＨＭＳサーバ１１２は、さまざまな方法でこの決定を行うように構成することができる。例えば、特定の実施形態では、ＨＭＳサーバ１１２がアクション出力に必要とされるヘルスケアプロバイダのタイプを最初に決定し（例えば、一般開業医）、次いで、患者がそのタイプのサービスのための好ましいヘルスケアプロバイダを定義したかどうかを決定するように構成される（上述のように）。そうである場合、そのヘルスケア専門家が選択される。患者が要求されるタイプのサービスのための好ましいプロバイダを定義していない場合、ＨＭＳサーバ１１２は利用可能なヘルスケア専門家（すなわち、ＨＭＳ１１０によるアカウントを有するヘルスケア専門家）から、ヘルスケア専門家（または、患者にオプションを提供するために、いくつかの専門家）を選択する。この場合、専門家は例えば、患者の職場または自宅の住所への近さ、患者が以前に専門家の１人を使用したかどうか、専門家の評価／フィードバックスコア、および／または任意の他の適切な基準に基づいて選択されてもよい。

４１０において、ＨＭＳサーバ１１２は現在のエンゲージメントアクション出力が予約を必要とするか否かを決定する（逆に、電話またはビデオコールが問題に対して十分であるか否かを決定する）。予約が要求されるかどうかは、ヘルス評価アプリケーション１１６によって生成されたエンゲージメントアクション出力において、例えばフラグまたは他の変数によって示される。

４１０で、ＨＭＳサーバ１１２が、予約が要求されていないと判定した場合、処理は４１４に続く。逆に、ＨＭＳサーバ１１２が、予約が必要であると判定した場合、処理は４１２まで続く。

４１２において、ＨＭＳサーバ１１２は、ＨＰ予約インターフェイスデータを生成する（図５に関してさらに後述する）。一般的に言えば、ＨＰ予約インターフェイスデータは、ヘルスケア専門家との予約を行うことを促進する制御を提供する（またはそのような制御が生成されるべきであることをＨＭＳクライアント１３２に示すフラグを生成する）。次に、処理は４１４に続く。

４１４において、ＨＭＳサーバ１１２は、ＨＰコールインターフェイスデータを生成する（図５に関して以下にさらに説明する）。一般的に言えば、ＨＰコールインターフェイスデータは、患者がヘルスケア専門家からの即時コールを選択または開始することができる制御を提供する（またはそのような制御が生成されるべきであることをＨＭＳクライアント１３２に示すフラグを生成する）。

４１６において、ＨＭＳサーバ１１２は、ＨＰエンゲージメントインターフェイスデータのセットを生成する。ＨＰエンゲージメントインターフェイスデータのセットはＨＰエンゲージメントに関する任意の一般情報（例えば、エンゲージメントが作成された理由）、任意の関連情報（例えば、ＨＰの関与が病理収集に関するものである場合には病理フォーム、ＨＰの関与が特定の問題に関するものである場合には照会書）、選択されたＨＰに関するデータ（４０８で決定される）、ＨＰコールインターフェイスデータ（４１４で生成される）、およびＨＰ予約インターフェイスデータ（もしあれば４１２で生成される）を含む。ＨＭＳクライアント１３２に伝送されると、ＨＰエンゲージメントインターフェイスデータは、ＨＰエンゲージメントインターフェイスを生成するためにＨＭＳクライアント１３２によって使用される。

図５のインターフェイス５００はＨＰエンゲージメントインターフェイス５５２の一例を提供し、そこから、４１６においてＨＭＳサーバ１１２によって生成されたＨＰエンゲージメントインターフェイスデータに関するさらなる詳細が明らかになるのであろう。

４１６におけるＨＰエンゲージメントインターフェイスデータの生成に続いて、処理は４０４に戻り、さらなる未処理のＨＰエンゲージメントアクション出力が存在するかどうかを判定する。

４０４で、ＨＭＳサーバ１１２が、未処理のヘルスケア専門家エンゲージメントアクション出力が存在しないと判定した場合、処理は４１８に進む。

４１８で、ＨＭＳサーバ１１２は、（３１４で生成された）未処理の製品注文アクション出力が存在するかどうかを判定する。そうである場合、処理は４２０に進む。そうでない場合、処理は終了する。

４２０において、ＨＭＳサーバ１１２は、処理すべき次の未処理の製品注文アクション出力を選択する。

４２２で、ＨＭＳサーバ１１２は、現在のアクション出力に定義されたヘルスケア製品の確認が必要であるかどうかを判定する。特定の場合（例えば、特定の地域の特定の製品、または製品発注アクションの生成がヘルスケア専門家によって引き起こされた場合）、ヘルスケア製品発注の確認は必要とされない場合がある。他の場合（例えば、製品が承認されたヘルスケア専門家によってのみ処方され得る販売制限された医薬品である場合）には、確認が必要とされる。確認が必要かどうかは、製品注文アクション出力にフラグやその他の変数などで示される。

４２２において、ＨＭＳサーバ１１２が、確認が必要でないと判定した場合、処理は４３０に続く。そうでなければ、処理は４２４に続く。

４２４において、ＨＭＳサーバ１１２は、ヘルスケア製品注文の確認を試みる。ＨＭＳサーバ１１２は、さまざまな方法でこの試みを実行するように構成することができる。例えば、ＨＭＳサーバ１１２は生成されたヘルスレポートを、（例えば、ＨＰクライアントアプリケーション１５２を介して）注文を確認し、確認を待つ資格を有するヘルスケア専門家に提供することができる。ヘルスケア専門家が実際に当該患者とコンサルテーションしないと確認できない場合もある（対面コンサルテーション、電話・ビデオ電話コンサルテーションのいずれか）。この場合、製品注文アクション出力が関連する製品は、適切なヘルスケア専門家による確認を条件として、提案された製品のみである。さらに、この場合、エンゲージメントアクション出力は、典型的にはヘルスケア専門家との必要なコンサルテーションを手配するために生成されている。

４２４に続いて、処理は４２６に進み、そこでＨＭＳサーバ１１２が確認が受信されたか否かを決定する。いくつかの実施形態では、ＨＭＳサーバ１１２が確認のために所定の時間だけ待機するように構成される。注文の確認が受信されない場合、処理は４２８に続き、ＨＭＳ１１２は、確認されるべき製品注文インターフェイスデータを生成する。このデータは、患者ＨＭＳクライアント１３２に伝送されると、ヘルスケア製品注文の確認が保留中であることを示すメッセージの生成を引き起こす。確認されるべき製品注文の生成に続いて、インターフェイスデータ処理は４４０に続く。

４２６において、注文の確認が受信された場合、処理は４３０に続く。

４３０では、注文確認が要求されないか（４２２）、または確認が要求され、受信されているか（４２６）のいずれかである。以下で説明するように、４３０は、ヘルスケア専門家が（そのクライアント１５２を介して）製品注文を「手動で」入力する場合にも効果的に到達することができる。

４３０において、ＨＭＳサーバ１１２は、注文されるヘルスケア製品に関する注文データ（スクリプトの形態をとることができる）を生成する。注文データは例えば、製品名、製品識別子、製品数量、任意の他の関連する製品データを含むことができる。患者パラメータ（上述のような）は、注文データに影響を及ぼすことができる。例えば、製品が医療／医薬品であり、患者がジェネリック（オリジネーター／ブランド名とは対照的に）製品を使用することを好むことを示した場合、ジェネリック製品が注文のために選択される。

４３２において、ＨＭＳサーバ１１２は、注文される製品に関する支払いおよび配達の詳細を決定する。これらの詳細は、注文が準備されている患者に関連付けられたアカウント／パラメータ詳細から取り出される。

４３４において、ＨＭＳサーバ１１２は、問題の製品のプロバイダを決定する。ＨＭＳサーバ１１２は、さまざまな方法でこの決定を行うように構成することができる。例えば、特定の実施形態では、ＨＭＳサーバ１１２が単一のプロバイダ（すなわち、製品プロバイダシステム１７０）を使用してすべての注文を満たすように構成され、この場合、そのサプライヤが選択される。他の実施形態では、ＨＭＳサーバ１１２が（それらのＰＰＳ１７０を介して）複数のプロバイダとインターフェイスすることができ、その場合、特定のプロバイダをさまざまな基準に従って選択することができる。例えば、患者が（上述のように）好ましい製品プロバイダを定義した場合、そのプロバイダが選択される。そうでない場合、プロバイダは、価格、製品の入手可能性／推定納期、および／または任意の他の適切な基準に基づいて選択され得る。

４３６において、ＨＭＳサーバ１１２は、選択されたプロバイダが利用可能な製品（および、製品価格および患者の好ましい配達住所までの推定配達時間などの他の情報）を有するかどうかを判定する。これは、関連するＰＰＳ１７０のＰＰＳサーバ１７２と通信するＨＭＳサーバ１１２を含む。

４３６で、ＨＭＳサーバ１１２が選択されたプロバイダが製品を提供できない（例えば、在庫切れである）と判定した場合、処理は４２８に進み、上述のように製品注文ＴＢＣインターフェイスデータを生成する。そうでなければ、処理は４３８に続く。

複数のプロバイダがＨＭＳサーバ１１０に利用可能である実施形態では、プロバイダが最初に４３６で試みたときに製品を提供できない場合、他のプロバイダに問い合わせて、それらが注文を満たすことができるかどうかを決定することができる。この場合、プロバイダが製品を提供できない場合にのみ、処理は４２８に進む。

４３８において、ＨＭＳサーバ１１２はプロバイダインターフェイスデータを生成する。一般的に言えば、プロバイダインターフェイスデータはプロバイダおよび製品のそれらの供給に関する情報（例えば、特定の製品、価格、および推定納期）を含む。４３８に続いて、処理は４４０に進む。

４４０において、プロバイダが４３６における注文を満たすことができることの確認に続いて、ＨＭＳサーバ１１２は、製品注文インターフェイスデータを生成する。製品注文インターフェイスデータはヘルスケア製品に関する任意の一般的な情報（例えば、製品が患者にとって必要／望ましいと判定された理由）、製品ＴＢＣインターフェイスデータ（４２８で生成された場合）、およびプロバイダインターフェイスデータ（４３８で生成された場合）を含む。ＨＭＳクライアント１３２に伝送されると、製品注文インターフェイスデータは、製品注文インターフェイスを生成するためにＨＭＳクライアント１３２によって使用される。

図５のインターフェイス５００は製品注文インターフェイス５８０の一例を提供し、そこから、４４０においてＨＭＳサーバ１１２によって生成された製品注文インターフェイスデータに関するさらなる詳細が明らかになるであろう。

４４０におけるヘルスケア製品注文インターフェイスデータの生成に続いて、処理は４１８に戻り、さらなる未処理の製品注文アクション出力が存在するかどうかを判定する。

４１８で、ＨＭＳサーバ１１２が、未処理の製品注文アクション出力が存在しないと判定した場合、処理は終了する。この時点でのインターフェイスデータは、４０２で生成されたレポート出力インターフェイスデータ、４１６で生成された任意の（すなわちゼロ以上の）ＨＰエンゲージメントインターフェイスデータのセット、および４４０で生成された任意の（すなわちゼロ以上の）製品注文インターフェイスデータのセットを含む。インターフェイスデータは、ＨＭＳサーバ１１２によって、３１８においてクライアントアプリケーション１３２に伝送される。

多くの場合、製品注文（必要な場合）の確認はリアルタイムに行われない。なぜなら、注文確認に必要なヘルスケアは患者を診る必要があるか、あるいはたとえそうでなくても、確認依頼のアクションを直ちに行うことができないからである。この場合、確認すべき製品注文インターフェイスデータが生成される（レポート処理を滞留させないように）。ヘルスケア専門家が最終的に注文を承認する場合、別個の処理（例えば、動作４３０、４３２、４３４、４３６、および４３８）は、製品注文インターフェイスデータの生成のためにのみ実行され得、製品注文インターフェイスデータは次いで、患者のクライアントアプリケーション１３２に伝送されて、以下に記載されるように、製品注文インターフェイスの表示を引き起こし得る。

さらに、場合によっては、（ＨＭＳ１１０による患者のヘルスデータの分析の結果としてではなく）患者を見ることに関するヘルスケア専門家によって、ヘルスケア製品注文アクション出力が生成されることがある。この場合、ヘルスケア専門家は、ＨＭＳサーバ１１２と（そのクライアント１５２を介して）対話して、製品注文アクション出力（または同様のアクション項目）をエンダーに入力することができる。ＨＭＳサーバ１１２によって受信されると、ヘルスケア専門家によって作成された出力／アイテムは製品注文インターフェイスデータを生成するために処理される（例えば、４３０、４３２、４３４、４３６、および４３８と同じまたは類似の動作に従って）。次いで、生成された製品注文インターフェイスデータは、ＨＭＳサーバ１１２によって患者のクライアントアプリケーション１３２に伝送されて、以下で説明するように製品注文インターフェイスを表示させることができる。

図５のインターフェイス５００は、ＨＭＳサーバ１１２によって生成され、ＨＭＳクライアント１３２に伝送されるさまざまなインターフェイスデータが患者システム１３０上でＨＭＳクライアント１３２によってどのように表示されるかの一例を提供する。一般的に言えば、インターフェイス５００は、レポート出力インターフェイス５０２、ＨＰエンゲージメントインターフェイス５５２、ヘルスケア製品注文インターフェイス５８０、および退出制御５９８（患者によって起動されると、インターフェイスから退出する）を含む。

レポート出力インターフェイス５０２はヘルスレポート表示ペイン５０２、ヘルスプラン表示ペイン５２０、および教育プラン表示ペイン５４０を含み、これらはそれぞれ順に説明される。

ヘルスレポート表示ペイン５０２は患者のヘルスに関するコンテンツ５０４（例えば、テキスト、画像、または他のコンテンツ）を含む患者ヘルスレポート情報を表示するために使用される。全ての患者ヘルスレポート情報は一度に表示されることができ、又は情報が例えば、ユーザによって起動されると、より詳細な情報の提示を引き起こすユーザ制御（ハイパーリンクのような）と共に最初に表示される特定の発明の概要項目と共に、インタラクティブな方法で提示されることができる。さらに、さまざまな制御、例えば、ダウンロードヘルスレポート制御５０４（起動されると、患者が自分のヘルスレポートを自分の患者装置１３０にダウンロードすることを可能にする）および共有ヘルスレポート制御５０６（起動されると、患者が例えば、電子メール、ＳＭＳ、または任意の他の適切な手段によって、選択された受信者と自分のヘルスレポートを共有することを可能にし、ヘルスレポートに含まれ得る情報の潜在的に機密性のある性質を認識する）を提供することができる。

本例のヘルスレポート表示ペイン５０２はまた、３つの患者アクション項目５１０、すなわち、患者のヘルスに有益な影響を及ぼす上位ｎ（この例では３）の患者アクションを含む。

例示的なインターフェイス５００では、患者ヘルスプラン情報がヘルスプラン表示ペイン５２０に提供される。この特定の例では、エクササイズプランリンク５２２、ダイエットプランリンク５２４、および禁煙プランリンク５２６の３つのヘルスプランリンクが表示される。これらのリンクの各々は患者によって起動されると、問題のプランに関するさらなる情報が表示されることになる（さらなる情報は３１８においてＨＭＳサーバ１１２から受信されるか、またはリンクが起動されるときにＨＭＳ１１２から取り出される）。代替の実施形態では、ヘルスプラン情報がヘルスプラン表示ペイン５２０に完全に記載されてもよい。ヘルスプラン表示ペイン５２０はまた、さまざまな制御部、この場合、ヘルスプランダウンロード制御部５２８（起動されると、患者が自分のヘルスプランを自分の患者システム１３０にダウンロードすることを可能にする）と、ヘルスプラン共有制御部５３０（起動されると、患者が自分のヘルスプランを選択された受信者と共有することを可能にする）とを含む。

例示的なインターフェイス５００では、患者教育プラン情報が教育プラン表示ペイン５４０に提供される。この特定の例では単一の疾患／状態ペイン５４２（糖尿病）が示されており、これは疾患／状態の３つの別個の態様への３つの教育リンク、すなわち、リンク５４６（疾患／状態に関する情報にリンクする）、管理リンク５４８（疾患／状態の管理に関する情報にリンクする）、および症状リンク５５０（疾患／状態の症状に関する情報、ならびに疾患／状態がどのように管理／誤管理されるかに応じてそれらの症状がどのように変化し得るかに関する情報にリンクする）を含む。疾患／状態に関する異なる（または異なるように提示された）情報にリンクして、追加の、より少ない、および／または代替の教育を提供することができ、追加の疾患／状態ペインを表示することができる。教育リンク５４６、５４８、および５５０は教育コンテンツが第三者のコンテンツプロバイダによって維持される場合、ＨＭＳ１１０またはコンテンツプロバイダシステム１９０（より具体的にはそのＣＰＳサーバ１９２）によって教育コンテンツが維持されるＨＭＳサーバ１１２など、任意の適切なコンテンツソースにリンクすることができる。

ＨＰエンゲージメントインターフェイス５５２は、提案されたエンゲージメントに関する一般情報を提供する情報ペイン５５４を含む。これは、例えば、エンゲージメントの理由およびそれに関連する任意の他の関連情報を含むことができる。情報ペイン５５４は患者によって起動された場合に、関与に関する追加情報がアクセスされる（例えば、表示される、ダウンロードされる、または他の方法でアクセスされる）ことを可能にする追加情報制御５５６をさらに含む。例えば、ヘルスケア専門家の関与が病理予約に関するものである場合、追加情報は患者がダウンロード／印刷し、病理プロバイダに提供することができる病理フォームを含むことができる。ヘルスケア専門家の関与が一般開業医（ＧＰ）の予約に関するものである場合、追加情報は、予約に関連し得る情報を伴う紹介を含むことができる。

ＨＰエンゲージメントインターフェイス５５２はまた、４０８においてＨＭＳサーバ１１２によって選択されたヘルスケア専門家に関する情報を含む、選択されたヘルスケア専門家ペイン５５８を含む。この場合、単一のヘルスケア専門家がＨＭＳサーバ１１２によって選択されている。

選択されたヘルスケア専門家ペイン５５８は、変更ヘルスケア専門家制御５６０も含む。患者が当該関与のために代替ヘルスケア専門家を選択したい場合、彼または彼女は制御５６０を起動することができる。これにより、代替ヘルスケア専門家のリストが表示される（管理５６０の起動時に、最初にＨＭＳサーバ１１２から受信されるか、またはそこから取得される代替ヘルスケア専門家）。次いで、患者は、関与のための代替のヘルスケア専門家を選択することができる（選択がＨＭＳサーバ１１２に返信される）。

他の場合には、選択されたヘルスケア専門家ペイン５５８が４０８でＨＭＳサーバ１１２によって選択された２人以上のヘルスケア専門家のリストを表示することができる。この場合、ユーザは、表示されたヘルスケア専門家のうちの１人を選択することができる（この選択がＨＭＳサーバ１１２に返信される）。

ＨＭＳサーバ１１２が（以下で説明するように）患者コールを待ち行列に入れた後に、選択されたＨＰが変更された場合、ＨＭＳサーバ１１２は（以下でも説明する）以前のＨＰで待ち行列に入れられた患者コールをキャンセルし、新たに選択されたＨＰで患者コールを待ち行列に入れる。

ＨＰエンゲージメントインターフェイス５５２はまた、通話インターフェイス５６２を含む。コールインターフェイス５６２は、連絡禁止制御５６４および連絡制御５６６を含む。

ＨＭＳサーバ１１２が連絡禁止制御５６４も連絡制御５６６も起動されていないと判定した場合、ＨＭＳサーバ１１２は、選択されたヘルスケア専門家のために患者連絡リマインダを生成させる。

ＨＭＳサーバ１１２は、患者クライアント１３２とのセッションがいずれかの制御が起動されたという指示を患者クライアント１３２から受信することなく終了される場合、連絡禁止制御５６４も連絡制御５６６も起動されていないことを決定するように構成される。いくつかの実装形態では、ＨＭＳサーバ１１２はまた、いずれかの制御が所定の期間（例えば、１５分または任意の他の適切な期間）内にアクティブ化されたという指示を患者クライアント１３２から受信しない場合、連絡禁止制御５６４も連絡制御５６６もアクティブ化されていないと判定するように構成される。

ＨＭＳサーバ１１２は、さまざまな方法で、選択されたヘルスケア専門家のために患者連絡リマインダを生成させるように構成することができる。例えば、いくつかの実施形態では、ＨＭＳサーバ１１２が待ち行列コール（または待ち行列連絡）メッセージ（例えば、コールされる患者の名前および番号、ならびに任意の関連情報、例えば、コールが単に予約を準備するためのものであるか、または患者に関する詳細を議論するためのものであるかどうかを含む）を生成し、ＨＰクライアントアプリケーション１５２に送信する。ＨＰクライアントアプリケーション１５２は待ち行列コールメッセージを受信し、患者のためのコールをヘルスケア専門家のコール待ち行列に入れる。代替の実施形態では、ＨＭＳサーバ１１２が通話の詳細を含むカレンダ招待を（例えば、電子メール、インスタントメッセージ、または他の手段によって）ヘルスケア専門家に送信するように構成される。カレンダ招待がヘルスケア専門家によって受信されると、それを受け入れることができ、コールがヘルスケア専門家のカレンダに追加される。さらに別の例として、ＨＭＳサーバ１１２は（適切なＡＰＩを介して）ヘルスケア専門家のコール待ち行列／ダイアリ／カレンダに直接アクセスし、コールアイテムをそれに直接追加するように構成されてもよい。

ＨＭＳサーバ１１２はいずれの制御もアクティブ化されずに、タイムアウト（例えば、インターフェイスの表示がアクティブ化されずに発生したｘ秒／分後）、またはクライアントアプリケーション１３２とのセッションが閉じられている場合（例えば、出口制御５９８のアクティブ化またはＨＭＳクライアントアプリケーション１３２の終了によって）のいずれかで、連絡禁止制御５６４および現在の連絡制御５６６のいずれもアクティブ化されなかったことを決定するように構成することができる。

連絡禁止制御５６４が起動されると、ＨＭＳクライアント１３２は連絡禁止メッセージを生成し、これをＨＭＳサーバ１１２に伝送する。ＨＭＳクライアント１３２から連絡禁止メッセージを受信すると、ＨＭＳサーバ１１２はコールを受信しないように患者のアクティブな選択を記録し、ヘルスケア専門家のコール待ち行列にコールアイテムが配置されないことを保証する。ＨＭＳサーバ１１２がすでに待ち行列コールメッセージを生成／送信した後に「連絡しない」メッセージを受信した場合、ＨＭＳサーバ１１２はヘルスケア専門家のコール待ち行列から連絡リマインダを削除しようとするために、「連絡しない」メッセージを受信することについて、さらなるアクションをとる。ＨＭＳサーバ１１２は、さまざまな方法でこれを行うように構成することができる。例えば、いくつかの実施形態では、ＨＭＳサーバ１１２がキャンセル待ち行列コール（またはキャンセル待ち行列連絡）メッセージ（例えば、呼び出される患者の名前および番号、および／または待ち行列コールが識別されることを可能にする他の情報を含む）を生成し、ＨＰクライアントアプリケーション１５２に送信することによって、そのようにする。ＨＰクライアントアプリケーション１５２は待ち行列に入れられたコールのキャンセルメッセージを受信し、その患者に対する待ち行列に入れられたコールを除去する。

特定の実施形態では連絡禁止管理５６４が起動された場合、ＨＭＳサーバ１１２はヘルスケア専門家との電話／コンサルテーションが推奨されるという１つまたは複数のリマインダを患者に送信するように動作する患者リマインダプロセスをトリガする。

例として、患者リマインダプロセスはクライアントが連絡禁止制御を起動した後（例えば、１週間後）、第１所定期間、患者に第１リマインダを自動的に生成し、送信することを含んでもよい。第２所定期間（例えば、連絡禁止制御の起動後２週間）において、患者がヘルスケア専門家と連絡していることを示すデータがＨＭＳサーバ１１２によって受信されていない場合、第２のリマインダが生成され、患者に通信される。第３所定期間（例えば、連絡禁止制御の起動後４週間）において、患者がヘルスケア専門家と連絡していることを示すデータがＨＭＳサーバ１１２によって受信されていない場合、第３（およびこの特定の例では最終である）リマインダが生成され、患者に伝送される。所与のリマインダはさまざまな手段、例えば、電子メール、ＳＭＳによって、および／または患者クライアントアプリケーション１３２を介して、患者に伝送されてもよい。患者がリマインダを見逃す可能性を低減するために、リマインダは複数のチャネル、例えば、電子メールによる第１リマインダ、ＳＭＳによる第２リマインダ、および電子メールによる第３リマインダを介して送信されてもよい。

連絡制御５６６が起動されると、ＨＭＳクライアント１３２は、（ペイン５５８に表示されるように）現在選択されているヘルスケア専門家との電話を開始する。通話は、音声通話またはビデオ通話であってもよく、ヘルスケア専門家の連絡情報を使用して開始される。この場合、ＨＭＳクライアント１３２はコール発信メッセージも生成し、これをＨＭＳサーバに伝える。ＨＭＳクライアント１３２から発信されたコールメッセージを受信すると、ＨＭＳサーバ１１２はコールが発信されたことを記録し、ヘルスケアプロフェッショナルのコール待ち行列にコールアイテムが配置されないことを保証する（または、ヘルスケアプロフェッショナルのコール待ち行列に連絡リマインダがすでに配置されていた場合それは除去される）。

ＨＰエンゲージメントインターフェイス５５２はまた、予約インターフェイス５６８を含む。特定の実施形態では、予約インターフェイス５６８が問題の関与のために予約が必要とされる場合にのみ表示される。他の実施形態では、予約がＨＭＳ１１０によって必要であると決定されたか否かにかかわらず、予約インターフェイス５６８が表示される。この例では、予約インターフェイス５６８が予約作成制御５７０を含む。上述のように、場合によっては、予約は対面コンサルテーションのためのものであり、他の場合には予約は電話またはテレビ電話コンサルテーションのためのものであってもよい。

予約制御５７０が起動されると、予約インターフェイス（図示せず）が表示され、患者がＨＰの可用性を見て、予約の日付／時間を選択することを可能にする。ＨＰの予約スケジュールは、さまざまな方法で入手／対話することができる。例えば、ＨＰの予約スケジュールが公的に利用可能である場合（例えば、ウェブサイトまたはアプリケーションを介して）、ＨＭＳクライアント１３２は患者が予約を行うことを可能にするために、ヘルスケア専門家のスケジュールにリダイレクトするように構成され得る。あるいは、ＨＰがその予約スケジュールへのアクセスを（適切なＡＰＩを介して）ＨＭＳサーバ１１２に提供してもよい。この場合、ＨＭＳクライアント１３２は受信時にＨＰスケジュールにアクセスし、患者に表示するためにＨＭＳクライアント１３２にその情報を提供する手動予約要求をＨＭＳサーバ１１２に伝送する。次いで、患者は、所望の予約時間を選択することができる。

予約が行われた場合、ＨＭＳサーバ１１２は、コールアイテムがヘルスケア専門家コール待ち行列に置かれないことを保証する（または連絡リマインダがヘルスケア専門家のコール待ち行列に既に置かれていた場合、それは除去される）。

患者のヘルスデータを分析すると、ヘルスケア専門家とのさらなる関与が提案される結果となる場合、デフォルト操作は、患者のためのヘルスケア専門家の待ち行列にコールアイテムが配置される（そして、ヘルスケア専門家側に何らかのエラーがなく、患者が電話を受ける）ようなものであることは理解されるであろう。代わりに、患者はヘルスケア専門家からコールされることを防ぐために積極的なアクションをとらなければならない。これは、患者が彼らのヘルス管理をさらに進めるために必要とする作業を減少させる。

代替の実施形態では、デフォルト動作が患者のために待ち行列に入れられたコールを有さず、その代わりに、これを行うために患者による何らかの明示的なアクションを必要とすることであってもよい。この場合、連絡禁止制御５６４を表示するのではなく、コールインターフェイス５６２には待ち行列患者コール制御が提供される。待ち行列患者コール制御が起動されると、ＨＭＳクライアント１３２は待ち行列患者コールメッセージを生成し、これをＨＭＳサーバ１１２に通信する（これにより、上述のように患者コールが待ち行列に入れられる）。この場合でも、患者が行うべき全ての患者が単一の「待ち行列患者コール」制御を起動するため、患者がヘルスケア専門家に電話をかけることが要求される作業／相互作用は低減される。そのような実施形態では、「患者通話待ち行列」制御が「連絡承認」制御、すなわち、ヘルスケア専門家による連絡を承認するために患者によって起動される制御と見なすことができる。５６６のような「今すぐ連絡」管理および／または上述の５７０のような予約管理もまた、患者がヘルスケア専門家との連絡を承認することをそれらのアクティブ化が示す点で、「連絡承認」管理のタイプである。ヘルスケア専門家との通信を承認するために患者による何らかの明示的なアクションを必要とする実施形態では、連絡承認管理が患者によってアクティブ化されない場合、ＨＭＳサーバ１１２は上述のように、患者リマインダプロセス（例えば、ヘルスケア専門家とのコール／コンサルテーションが推奨されることを患者にリマインドするために１つまたは複数のリマインダを患者に送信させるように動作するプロセス）をトリガするように構成され得る。

ヘルスケア製品注文インターフェイス５８０は、注文インターフェイス５８０が関連するヘルスケア製品に関する一般情報を提供する製品情報ペイン５８２を含む。これは、例えば、注文インターフェイスが関連する製品の名前、患者について製品が識別された理由、製品に関連する使用法の提案／要件、他の関連情報に関する情報を含むことができる。製品情報ペインはまた、スクリプト／注文管理５８６を含み、これは、患者によってアクティブ化された場合、製品のためのスクリプトまたは注文ドキュメントを表示／ダウンロードおよび／または共有させるように構成され得る。これは、患者が製品の電子注文を進めることを選択せず、代わりに、スクリプト／注文を物理的な店舗に持ち込むことを望む場合に有用である。

ヘルスケア製品注文インターフェイス５８０はまた、４３４においてＨＭＳサーバ１１２によって選択された製品プロバイダに関する情報を含む、選択されたプロバイダペイン５８８を含む。この例では、情報がプロバイダの詳細（例えば、Ａｍａｚｏｎ、Ｃｈｅｍｉｓｔ Ｗａｒｅｈｏｕｓｅ、またはいずれかのプロバイダが選択されたなど、選択された製品プロバイダの名前の名前）、製品の価格、現在選択されている配達先への配達コスト、注文の総コスト、および製品の推定配達日を含む。追加の／より少ない／代替のプロバイダ情報を提供することができる。

選択されたプロバイダペイン５８８は、変更プロバイダ管理５９０も含む。患者が製品の代替プロバイダを選択することを望む場合、患者は、制御部５９０を作動させることができる。これにより、ＨＭＳ１１０に利用可能な１つ以上の代替プロバイダのリストが表示される（代替プロバイダは、ＨＭＳサーバ１１２から最初に受信されるか、または制御５９０の起動時にそこから取得される）。次いで、患者はリストから代替プロバイダを選択することができ、変更プロバイダメッセージがクライアント１３２によって生成され、ＨＭＳサーバ１１２に返信される。変更プロバイダメッセージを受信すると、ＨＭＳサーバ１１２は新たに選択されたプロバイダのＰＰＳサーバ１７２とインターフェイスし、サプライヤが問題の製品（例えば、上述の４３６ごと）を供給できることをチェックする。その場合、ＨＭＳサーバ１１２はプロバイダ更新メッセージを生成し、これをＨＭＳクライアント１３２に伝送する。プロバイダ更新メッセージはＨＭＳクライアント１３２が選択されたプロバイダペイン５８８に表示させる更新されたプロバイダデータ（例えば、新たに選択されたプロバイダ詳細、製品価格の任意の変更、配送コストの任意の変更、および／または推定配送日）を含む。

ヘルスケア製品注文インターフェイス５８０はまた、（４３２で決定された）現在選択されている配送住所に関する情報を提供する配送住所ペイン５９２を含む。配送住所ペイン５９２はまた、変更配送住所制御５９４を含む。患者が代替の送達住所を選択または入力することを望む場合、患者は、制御５９４を作動させることができる。これにより、変更配送住所インターフェイス（図示せず）が起動される。変更配送住所インターフェイスは、ユーザが所望の配送住所を指定することを可能にするデータ入力フィールド（または一連のフィールド）を含むことができる。患者が複数の住所（例えば、職場住所、自宅住所等）をＨＭＳ１１０に提供した場合、変更配送住所インターフェイスはこれらを表示することもでき（例えば、ＨＭＳクライアント１３２がＨＭＳサーバ１１２から患者のために格納された住所を要求し、それに応答して住所情報を受信することによって）、患者がリストから代替住所を選択することを可能にする。代替配送住所を選択すると、ＨＭＳクライアント１３２は変更配送住所メッセージを生成し、このメッセージをＨＭＳサーバ１１２に送り返す。変更配送住所メッセージを受信すると、ＨＭＳサーバ１１２は変更された配送住所を記録する（および、ある実施形態では、新しい配送住所を患者のアカウントに追加する）。ＨＭＳサーバ１１２はまた、現在選択されているプロバイダのＰＰＳサーバ１７２とインターフェイスし、新しい配送住所が配送コストまたは推定配送日に何らかの変更を引き起こすか否かを決定する。ＰＰＳサーバ１７２からの応答を受信すると、ＨＳサーバ１１２は新しい配送住所メッセージを生成し、これをＨＭＳクライアント１３２に伝送する。新しい配送住所メッセージは配送住所が更新されたことを確認する（したがって、ＨＭＳクライアント１３２は更新された配送住所詳細を配送住所ペイン１９２内で変更させることができる）。新しい配送住所メッセージはまた、ＨＭＳクライアント１３２が選択されたプロバイダペイン５８８に表示させる更新されたプロバイダデータを含む（例えば、配送コストまたは推定配送日付の任意の変更）。

ヘルスケア製品注文インターフェイス５８０は、注文禁止制御５９６も含む。注文禁止制御５９６がアクティブ化されていない場合、ＨＭＳサーバ１１２は、選択されたプロバイダに発注させる。

ＨＭＳサーバ１１２は、患者クライアント１３２とのセッションが患者クライアント１３２から制御がアクティブ化されたという指示を受信することなく終了される場合、注文禁止制御５９６がアクティブ化されていないことを決定するように構成される。いくつかの実装形態では、ＨＭＳサーバ１１２はまた、所定の期間（例えば、１５分または任意の他の適切な期間）内に制御がアクティブ化されたという指示を患者クライアント１３２から受信しない場合、注文禁止制御５９６がアクティブ化されていないことを決定するように構成される。

ＨＭＳサーバは、選択したプロバイダにさまざまな方法で注文を発注させるように設定できる。例えば、いくつかの実施形態では、ＨＭＳサーバ１１２がＰＰＳアプリケーション１１４に、選択されたプロバイダのＰＰＳサーバ１７２と注文を発注させることによって、これを行う。発注された注文は選択された製品、選択された配送先住所、および支払い詳細（例えば、クレジットカードまたは患者のアカウントから検索された他の支払いアカウント詳細）に関する情報を含む。注文がうまく発注された場合、ＨＭＳ１１０は注文メッセージを生成し、例えば、ＨＭＳクライアント１３２によって表示されるように、または電子メールまたは他の通信手段を介して、これを患者に通信する。注文がうまく発注されなかった場合（例えば、供給者がＰＰＳシステム１７２に注文を発注しようとする前に製品が売り切れたため）、発注されなかった注文が患者に伝えられる。ＨＭＳサーバ１１２はタイムアウト（例えば、制御がアクティブ化されずにインターフェイスの表示が発生したｘ秒／分後）または制御がアクティブ化されずにクライアントアプリケーション１３２とのセッションが閉じられた場合（例えば、出口制御５９８のアクティブ化またはＨＭＳクライアントアプリケーション１３２の終了によって）のいずれかで、注文禁止制御５９６がアクティブ化されなかったことを決定するように構成することができる。

注文禁止制御５９６がアクティブ化されると、ＨＭＳクライアント１３２は注文禁止メッセージを生成し、これをＨＭＳサーバ１１２に伝送する。ＨＭＳクライアント１３２から注文禁止メッセージを受信すると、ＨＭＳサーバ１１２は、注文を発注すべきではなく、注文を発注すべきではないという患者のアクティブな選択を記録する。ＨＭＳサーバ１１２がすでに発注を行った後に発注しないメッセージが受信された場合、ＨＭＳサーバ１１２は発注した注文をプロバイダシステムから削除／キャンセルすることを試みるために、発注しないメッセージを受信することについて、さらなるアクションをとる。ＨＭＳサーバ１１２は、さまざまな方法でこれを行うように構成することができる。例えば、いくつかの実施形態では、ＨＭＳサーバ１１２が注文キャンセルメッセージ（元の注文が識別されることを可能にするのに十分な情報を含む）を生成し、ＰＰＳアプリケーション１１４に送信することによって、そのようにする。ＰＰＳアプリケーション１１４は注文キャンセルメッセージを受信し、可能であれば、注文をキャンセルする。

理解されるように、ヘルスケア製品が患者のために必要とされるか、または推奨される場合、デフォルト動作は、その製品のための注文がなされるようなものである。代替的に言えば、患者は、指示が出されるのを防止するために積極的なアクションをとらなければならない。これは、患者が彼らのヘルス管理をさらに進めるために必要とする作業を減少させる。

代替の実施形態では、明示的な患者アクションがない状態で注文を行う代わりに、デフォルト動作は注文を行わないことであってもよい。この場合、注文禁止制御５９６を表示するのではなく、ヘルスケア製品注文インターフェイス５８０は、注文確認制御を含む。注文確認制御が起動されると、ＨＭＳクライアント１３２は注文確認メッセージを生成し、これをＨＭＳサーバ１１２に伝える（その後、上記のように注文を発注させる）。注文確認制御が起動されない場合、注文は行われない。この場合でさえ、処方された／示唆されたヘルスケア製品を注文するために患者によって必要とされる作業／相互作用は、発注された注文を有するために患者が行う必要がある全ての患者が単一の「注文確認」制御を起動するので、低減される。

場合によっては、注文を行うことができない（例えば、ＨＭＳ１１０がアクセスすることができる製品プロバイダから製品が単に入手できない、または４２６で注文が確認されない）。この場合、製品情報ペイン５８２は依然として表示されてもよいが、選択されたプロバイダペイン５８８または配送住所ペイン５９２を表示する代わりに、適切なメッセージ、例えば、「製品が利用できない」または「注文のヘルスケア専門家確認待ち」または他の適切なメッセージが表示される。

図３、図４、および図５を参照して上記で説明した動作は特定のアプリケーションによって実行されるものとして説明したが、説明した動作は任意の適切にプログラムされた／構成されたアプリケーションによって実行することができる。例えば、特定の実施形態では、ＨＭＳ１１０が個別のアプリケーションによってではなく、その上で動作する単一のモノリシックアプリケーションによってその動作を実行するように構成することができる。

図３および図４のフローチャートは、処理／機能ステップを示すために提供され、説明されてきた。これらのフローチャートはさまざまな特徴を説明するために特定の順序でステップを定義するが、場合によってはステップが異なる順序で、または並行して実行され得る。さらに、場合によっては２つ以上の動作が単一の動作に組み合わされてもよく、単一の動作が複数の別個の動作に分割されてもよく、および／または説明された／例示された動作のうちの１つ以上によって達成された機能が１つ以上の代替の動作によって達成されてもよい。

本明細書に開示され、定義された実施形態は、本文または図面から言及され、または明らかな個々の特徴のうちの２つ以上の代替的な組合せのすべてに及ぶことが理解されるであろう。これらの異なる組み合わせの全ては、実施形態のさまざまな代替態様を構成する。

Claims (24)

1. ヘルス管理システムが患者に関する患者ヘルスデータを受信し、
   前記ヘルス管理システムが特定タイプのヘルスケア専門家との関与が必要であると判定するために、前記患者ヘルスデータを分析し、
   前記ヘルス管理システムが前記特定タイプの特定ヘルスケア専門家を決定し、
   前記ヘルス管理システムが、ヘルスケア専門家エンゲージメントインターフェイスを生成させ、
   前記ヘルスケア専門家エンゲージメントインターフェイスは前記特定タイプのヘルスケア専門家との関与が必要であり、連絡禁止制御であることを示す情報を含み、
   前記連絡禁止制御がアクティブ化されていないことが決定された場合、患者連絡リマインダを生成させ、
   前記患者連絡リマインダは前記患者に連絡するための前記特定ヘルスケア専門家へのリマインダである、
   コンピュータ実装方法。
2. 前記連絡禁止制御がアクティブ化されていると判定された場合、前記ヘルス管理システムは、患者連絡リマインダを生成させることを見送るように構成されている、請求項１に記載のコンピュータ実装方法。
3. 前記連絡禁止制御がアクティブ化されていると判定された場合、
   ヘルスケア管理システムは、患者連絡リマインダをすでに生成させているか判定し、
   前記患者連絡リマインダをすでに生成させていると判定された場合、前記ヘルスケア管理システムは、キャンセル患者連絡メッセージを生成し、ヘルスケア専門家システムに前記キャンセル患者連絡メッセージを伝送する、
   ことを含む、
   請求項１に記載のコンピュータ実装方法。
4. 前記連絡禁止制御がアクティブ化されていることが判定された場合、
   ヘルスケア管理システムは、患者リマインダを生成し、
   所定時間に前記患者に前記患者リマインダを伝送する、
   ことを含む、請求項１～請求項３のいずれか１項に記載のコンピュータ実装方法。
5. 前記ヘルスケア管理システムは、前記患者リマインダを前記患者に電子メールまたはＳＭＳによって伝送する、
   請求項４に記載のコンピュータ実装方法。
6. 前記ヘルスケア専門家エンゲージメントインターフェイスは変更ヘルスケア専門家制御をさらに含み、
   前記変更ヘルスケア専門家制御のアクティブ化を検出すると、
   ヘルスケア管理システムは、関与に適した代替ヘルスケア専門家を判定し、
   前記連絡禁止制御がアクティブ化されていないと判定された場合、前記代替ヘルスケア専門家のために患者連絡リマインダを生成させる、
   ことをさらに含む、請求項１～請求項５のいずれか１項に記載のコンピュータ実装方法。
7. 前記代替ヘルスケア専門家を判定することは、
   前記ヘルスケア管理システムが、前記患者によって選択された代替ヘルスケア専門家に関する情報を受信することを含む、
   請求項６に記載のコンピュータ実装方法。
8. 前記患者連絡リマインダを生成させることは、前記ヘルスケア専門家によって、または、前記ヘルスケア専門家の代わりに、維持されるコール待ち行列に患者コールアイテムを追加させることを含む、請求項１～請求項７のいずれか１項に記載のコンピュータ実装方法。
9. 前記患者連絡リマインダを生成させることは、ヘルスケア管理システムが、前記ヘルスケア専門家にカレンダ招待を送信することを含む、
   請求項１～請求項７のいずれか１項に記載のコンピュータ実装方法。
10. 前記患者連絡リマインダを生成させることは、ヘルスケア管理システムが、カレンダイベントを前記ヘルスケア専門家のカレンダに直接追加することを含む、
    請求項１～請求項７のいずれか１項に記載のコンピュータ実装方法。
11. ヘルス管理システムが、患者がヘルスケア製品を必要とすることを決定し、
    前記ヘルス管理システムが、前記ヘルスケア製品の特定プロバイダを決定し、
    前記ヘルス管理システムが、ヘルスケア製品注文インターフェイスを生成させ、
    前記ヘルスケア製品注文インターフェイスは、前記ヘルスケア製品および注文禁止制御に関する情報を含み、
    前記注文禁止制御がアクティブ化されていないと決定された場合、製品注文を生成し、前記製品注文を前記特定プロバイダのプロバイダシステムに伝送する、
    コンピュータ実装方法。
12. 前記患者がヘルスケア製品を必要とすることを決定することは、
    前記ヘルス管理システムが、患者に関する患者ヘルスデータを受信し、
    前記ヘルス管理システムが、前記患者が前記ヘルスケア製品を必要とすることを決定するために前記患者ヘルスデータを分析する、
    ことを含む、請求項１１に記載のコンピュータ実装方法。
13. 前記患者がヘルスケア製品を必要とすることを決定することは、
    前記ヘルス管理システムが、前記患者が前記ヘルスケア製品を必要とすることを示すヘルスケア専門家システムからの通信を受信することを含む、
    請求項１１に記載のコンピュータ実装方法。
14. 前記注文禁止制御がアクティブ化されたことが決定された場合、前記ヘルス管理システムは、製品注文の生成および前記プロバイダシステムへの前記製品注文の通信を見送るように構成されている、
    請求項１１～請求項１３のいずれか１項に記載のコンピュータ実装方法。
15. 前記注文禁止制御がアクティブ化されていることが決定された場合、
    製品注文がすでに生成され、プロバイダシステムに伝送されているか否かを決定し、
    前記製品注文がすでに生成され、前記プロバイダシステムに伝送されていることが決定された場合、キャンセル注文メッセージを生成し、キャンセル注文メッセージを前記プロバイダシステムに伝送する、
    ことをさらに含む、
    請求項１１～請求項１３のいずれか１項に記載のコンピュータ実装方法。
16. 前記製品注文を生成し伝送する前に、
    患者のためのヘルスケア製品を注文する前に確認が必要か否かを決定し、
    確認が必要であると決定された場合には、確認が得られない限り、前記製品注文の生成を見送る、
    ことをさらに含む、
    請求項１１～請求項１５のいずれか１項に記載のコンピュータ実装方法。
17. 前記ヘルスケア製品注文インターフェイスは変更プロバイダ制御をさらに含み、
    前記変更プロバイダ制御のアクティブ化を検出した場合、
    代替プロバイダを決定し、
    注文禁止制御がアクティブ化されていないことが決定された場合、製品注文を生成し、前記製品注文を前記代替プロバイダのプロバイダシステムに伝送する、
    ことをさらに含む、請求項１６に記載のコンピュータ実装方法。
18. 代替プロバイダを決定することは、ヘルスケア管理システムが、前記患者によって選択された代替プロバイダに関する情報を受信することを含む、請求項１７に記載のコンピュータ実装方法。
19. ヘルス管理システムが患者に関する患者ヘルスデータを受信し、
    前記ヘルス管理システムが特定タイプのヘルスケア専門家との関与が必要であると決定するために、前記患者ヘルスデータを分析し、
    前記ヘルス管理システムが前記特定タイプの特定ヘルスケア専門家を決定し、
    前記ヘルス管理システムが、ヘルスケア専門家エンゲージメントインターフェイスを生成させ、
    前記ヘルスケア専門家エンゲージメントインターフェイスは前記特定タイプのヘルスケア専門家との関与が必要であり、１つ以上の連絡承認制御であることを示す情報を含み、
    １つ以上の前記連絡承認制御のいずれもアクティブ化されていないことが決定された場合、ヘルスケア管理システムは、第１患者リマインダを生成し、前記第１患者リマインダを前記患者に第１所定時間に伝送する、
    コンピュータ実装方法。
20. 第２所定時間に、前記患者がヘルスケア専門家に連絡していないことを決定した場合、第２患者リマインダを生成し、前記第２患者リマインダを前記患者に伝送する、
    ことをさらに含む、請求項１９に記載のコンピュータ実装方法。
21. 前記第１患者リマインダおよび第２患者リマインダは、複数の通信チャネルを介して送信される、請求項２０に記載のコンピュータ実装方法。
22. １つ以上の前記連絡承認制御は、待ち行列患者コール制御、今すぐ連絡制御、および予約作成制御のうちの１つ以上を含む、
    請求項１９～請求項２１のいずれか１項に記載のコンピュータ実装方法。
23. １つ以上のプロセッサと、
    １つ以上の前記プロセッサによって実行されると、１つ以上の前記プロセッサに、請求項１～請求項２２のいずれか１項に記載の方法を実行させる命令のシーケンスを記憶する１つ以上の非一時的コンピュータ可読記憶媒体と、
    を含むシステム。
24. コンピュータ処理ユニットによって実行されると、前記コンピュータ処理ユニットに請求項１～請求項２２のいずれか１項に記載の方法を実行させる命令のシーケンスを記憶する非一時的コンピュータ可読記憶媒体。
    

Images