JP2021022253A - 医療機関とユーザのマッチングシステム - Google Patents

Abstract

【課題】自覚症状に関するユーザの知識が十分でなかった場合にも、適切な医療機関や診療科などを選択可能なマッチングシステムを提供する。【解決手段】マッチングシステムは、、ネットワークで接続される、医療機関に関連する医療機関端末３００と、ユーザに関連するユーザ端末２００と、を仲介するサーバ端末１００により構成される。サーバ端末１００は、ユーザ端末２００よりユーザの病状に関連する情報および／またはユーザの診療希望に関連する情報を受信し、受信した情報と事前に登録された医療機関情報と比較し、比較した結果に基づき、ユーザ情報を医療機関端末３００へ送信し、ユーザ情報を基に判定された診療可否情報を、医療機関端末３００から受信する。【選択図】図７

Description

本発明は、医療機関に関連する医療機関端末と、ユーザに関連するユーザ端末と、を仲介するサーバ端末により提供される、医療機関とユーザとのマッチングシステムに関する。

従来から、医療機関内での診察待ち時間の緩和のために、診察予約システムがある。

例えば、特許文献１において、ユーザが携帯端末上に表示される、都道府県名や医療機関名、診療科名を選択し、その医療機関の診療科に対して診察予約を行うための診察予約システムが開示されている。

特開２００２−３１８８５４号公報

しかしながら、特許文献１に記載の診察予約システムでは、ユーザが医療機関名や診療科名を自ら選択しなければならないが、自覚症状に関するユーザの知識や、その自覚症状に対する最適な医療機関を選択するための情報（例えば、医療機関内の医療施設や在籍医師、診療科など）がユーザにとって必ずしも十分ではない。そのため、ユーザが誤った医療機関や診療科などを選択してしまい、早期に適切な診察が受けられない場合があり得る。

また、特許文献１に記載の診察予約システムでは、ユーザが選択しない限り、その医療機関や医師に辿り着くことはないため、例えば個人開業医のように新規設立された医療機関などからは、ユーザに広く認知してもらいたいというニーズがある。一方で、大学病院などのユーザが集中する医療機関からは、ユーザが選択した医療機関や診療科などが適切ではなかった場合、そのようなユーザのために他のユーザの診療待ち時間が長くなることを避けたいというニーズもある。

そこで、本発明は、自覚症状に関するユーザの知識が十分でなかった場合にも、適切な医療機関や診療科などを選択可能なマッチングシステムを提供することを目的とする。特に、医療機関による診療可否を提供可能なマッチングシステムを提供することを目的とする。

本発明の一態様における、ネットワークで接続される、医療機関に関連する医療機関端末と、ユーザに関連するユーザ端末と、を仲介するサーバ端末により提供される、前記医療機関と前記ユーザとのマッチングシステムであって、前記サーバ端末は、前記ユーザ端末より前記ユーザの病状に関連する情報および／または前記ユーザの診療希望に関連する情報を受信し、当該受信した情報と事前に登録された医療機関情報と比較し、当該比較した結果に基づき、少なくとも前記ユーザの病状に関連する情報および／または前記ユーザの診療希望に関連する情報を含むユーザ情報を、前記医療機関端末へ送信し、当該ユーザ情報を基に判定された診療可否情報を、前記医療機関端末から受信する。

本発明によれば、自覚症状に関するユーザの知識が十分でなかったとしても、ユーザ端末を操作するだけで、適切な医療機関や診療科などを選択することができる。また、事前にユーザの情報を確認して診療を断ることができるので、ユーザの誤選択により生じる診察待ち時間の拡大を防止することができる。さらに、不特定多数のユーザと医療機関がマッチングされることにもなるため、医療機関が積極的に診療を許可することによって、ユーザに広く認知してもらうことが可能である。

本発明の第１実施形態に係る、マッチングシステムを示すブロック構成図である。 図１のサーバ端末１００を示す機能ブロック構成図である。 図１のユーザ端末２００を示す機能ブロック構成図である。 図１の医療機関端末３００を示す機能ブロック構成図である。 サーバ１００に格納されるユーザデータの一例を示す図である。 サーバ１００に格納される医療機関データの一例を示す図である。 本発明の第１実施形態に係る、マッチング方法に係るフローチャートの一例である。 本発明の第１実施形態に係る、マッチング方法に係るフローチャートの他の例である。 本発明の第１実施形態に係る、ユーザ端末において特定の病気をフォロー登録し、医療機関や医師へのコンタクトを行う画面の一例である。 本発明の第２実施形態に係る、マッチング方法に係るフローチャートの一例である。

以下、本発明の実施形態について図面を参照して説明する。なお、以下に説明する実施形態は、特許請求の範囲に記載された本開示の内容を不当に限定するものではない。また、実施形態に示される構成要素のすべてが、本開示の必須の構成要素であるとは限らない。

（第１実施形態） ＜構成＞
図１は、本発明の第１の実施形態に係るマッチングシステムを示すブロック構成図である。本システム１は、医療機関での診療を希望するユーザに関連するユーザ端末２００と、医療機関に関連する医療機関端末３００と、を仲介するサーバ端末１００と、により構成される。

サーバ端末１００と、ユーザ端末２００及び医療機関端末３００とは、ネットワークＮＷを介して接続される。ネットワークＮＷは、インターネット、イントラネット、無線ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等により構成される。

サーバ端末１００は、ユーザから、ユーザ端末２００を通じてユーザの基本情報（例えば、ユーザの氏名やＥメールアドレスなど）や、ユーザの病状に関連する情報（例えば、自覚症状、疾患など）および／またはユーザの診療希望に関連する情報（例えば、希望の医師や医療機関、診療科、治療方法など）などを受け付け、医療機関端末３００を通じて受け付けられる、医療機関に関連する情報（例えば、医療施設や在籍医師、診療科など）に基づいて、ユーザと医療機関とのマッチング処理を行う装置であり、例えば、ワークステーションやパーソナルコンピュータのような汎用コンピュータとしてもよいし、或いはクラウド・コンピューティングによって論理的に実現されてもよい。本実施形態においては、説明の便宜上サーバ端末として１台を例示しているが、これに限定されず、複数台であってもよい。

ユーザ端末２００は、サーバ端末１００により提供されるサービスを利用するユーザが所有する、例えば、パーソナルコンピュータやタブレット端末等の情報処理装置であるが、スマートフォンや携帯電話、ＰＤＡ等により構成しても良い。

医療機関端末３００は、サーバ端末１００により提供されるサービスを利用する医療機関が所有する、例えば、パーソナルコンピュータやタブレット端末等の情報処理装置であるが、スマートフォンや携帯電話、ＰＤＡ等により構成しても良い。

本実施形態では、システム１は、サーバ端末１００と、ユーザ端末２００及び医療機関端末３００とを備え、医療機関での診療を希望するユーザまたは医療機関が各々、ユーザ端末２００、医療機関端末３００を利用して、サーバ端末１００に対する操作を行う構成として説明するが、サーバ端末１００がスタンドアローンで構成され、サーバ端末自身に、ユーザまたは医療機関が操作を行う機能を備えても良い。

図２は、図１のサーバ端末１００の機能ブロック構成図である。サーバ端末１００は、通信部１１０と、記憶部１２０と、制御部１３０とを備える。

通信部１１０は、ネットワークＮＷを介してユーザ端末２００及び医療機関端末３００と通信を行うための通信インターフェースであり、例えばＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）等の通信規約により通信が行われる。

記憶部１２０は、各種制御処理や制御部１３０内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等から構成される。また、記憶部１２０は、ユーザに関連する各種データを格納する、ユーザデータ格納部１２１、医療機関に関連する各種データを格納する、医療機関データ格納部１２２等を有する。さらに、記憶部１２０は、ユーザ端末２００、医療機関端末３００と通信を行ったデータを一時的に記憶することもできる。なお、各種データを格納したデータベース（図示せず）が記憶部１２０外に構築されていてもよい。

制御部１３０は、記憶部１２０に記憶されているプログラムを実行することにより、サーバ端末１００の全体の動作を制御するものであり、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）等から構成される。制御部１３０の機能として、ユーザ端末２００または医療機関端末３００からの指示を受け付ける指示受付部１３１と、ユーザに関連する各種データを参照し、処理するユーザデータ管理部１３２と、医療機関に関連する各種データを参照し、処理する、医療機関データ管理部１３３等を有する。この指示受付部１３１、ユーザデータ管理部１３２、医療機関データ管理部１３３は、記憶部１２０に記憶されているプログラムにより起動されてコンピュータ（電子計算機）であるサーバ端末１００により実行される。

指示受付部１３１は、サーバ端末１００が提供し、ユーザ端末２００または医療機関端末３００において表示されるウェブ画面等のユーザインターフェースを介して、ユーザまたは医療機関が、（キーワードを入力したり、アイコンを押下する等して）所定の要求を行ったとき、ユーザ端末２００または医療機関端末３００から通信部１１０を介して指示を受付ける。

ユーザデータ管理部１３２は、後述するユーザデータ格納部１２１に格納される各種データを管理し、処理を行う。

医療機関データ管理部１３３は、後述する医療機関データ格納部１２２に格納される各種データを管理し、処理を行う。

マッチングログデータ管理部１３４は、後述するマッチングログデータ格納部１２３に格納される各種データを管理し、処理を行う。

図３は、図１のユーザ端末２００を示す機能ブロック構成図である。ユーザ端末２００は、通信部２１０と、表示操作部２２０と、記憶部２３０と、制御部２４０とを備える。

通信部２１０は、ネットワークＮＷを介してサーバ端末１００と通信を行うための通信インターフェースであり、例えばＴＣＰ／ＩＰ等の通信規約により通信が行われる。

表示操作部２２０は、ユーザが指示を入力し、制御部２４０からの入力データに応じてテキスト、画像等を表示するために用いられるユーザインターフェースであり、ユーザ端末２００がパーソナルコンピュータで構成されている場合はディスプレイとキーボードやマウスにより構成され、ユーザ端末２００がタブレット端末で構成されている場合はタッチパネル等から構成される。この表示操作部２２０は、記憶部２３０に記憶されている制御プログラムにより起動されてコンピュータ（電子計算機）であるユーザ端末２００により実行される。

記憶部２３０は、各種制御処理や制御部２４０内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、ＲＡＭやＲＯＭ等から構成される。また、記憶部２３０は、サーバ端末１００との通信内容を一時的に記憶している。

制御部２４０は、記憶部２３０に記憶されているプログラムを実行することにより、ユーザ端末２００の全体の動作を制御するものであり、ＣＰＵやＧＰＵ等から構成される。

なお、サーバ端末１００に表示操作部の機能を備える構成としても良く、この場合、ユーザ端末２００を備えない構成としても良い。

図４は、図１の医療機関端末３００を示す機能ブロック構成図である。医療機関端末３００は、通信部３１０と、表示操作部３２０と、記憶部３３０と、制御部３４０とを備える。なお、医療機関端末３００の機能構成は、ユーザ端末２００と実質的に同一であるので、詳細な説明を省略する。

図５は、サーバ１００のユーザデータ格納部１２１に格納されるユーザデータの一例を示す図である。

図５に示すユーザデータ１０００は、ユーザに関連する各種データを格納する。図５において、説明の便宜上、一ユーザ（ユーザＩＤ「１０００１」で識別されるユーザ）の例を示すが、複数のユーザの情報を格納することができる。ユーザに関連する各種データとして、例えば、ユーザの基本情報（例えば、ユーザの氏名、在住エリア、Ｅメールアドレス、ＳＮＳアカウント情報、既往歴など）、支払情報（例えば、ユーザが登録したクレジットカード情報など）、ユーザが加入するプラン（例えば、通常プランや、ユーザが利用できる、予約代行、通常の受診相談、セカンドオピニオン、病気に基づいた医療機関のレコメンドといったサービスの上限を及び／または範囲を拡張できる有料プレミアムプランなど）、ユーザの病状に関連する情報（例えば、自覚症状、疾患など）、及びユーザの診療希望に関連する情報（例えば、希望の医師や医療機関、診療科、治療方法など）などを格納する。なお、上述の各種データは例示であるので、すべてのデータが格納されている必要はなく、特に、ユーザの診療希望に関連する情報は、後述する例示的なプロセスにより、必要な情報のみがデータとして格納されてもよい。

図６は、サーバ１００のユーザデータ格納部１２１に格納される医療機関データの一例を示す図である。

図６に示す医療機関データ２０００は、医療機関に関連する各種データを格納する。図６において、説明の便宜上、一医療機関（医療機関ＩＤ「２０００１」で識別される医療機関）の例を示すが、複数の医療機関の情報を格納することができる。医療機関に関連する各種データとして、例えば、医療機関の基本情報（例えば、医療機関名、住所、電話番号、Ｅメールアドレス、在籍医師名、診療科など）、支払情報（例えば、医療機関が登録した口座情報など）、医療機関が加入するプラン（例えば、通常プランや、医療機関及び医師が利用できる、Ｗｅｂページに掲載可能なコンテンツに関するオプション（医師のインタビューページ、受診相談といったサービスの上限及び／または範囲を拡張できる有料プレミアムプランなど）、及びユーザから受け付けた医療機関に関連する評価情報等の情報を格納する。

＜処理の流れ＞
図７を参照しながら、本実施形態のシステム１が実行するユーザと医療機関とのマッチング方法の処理の流れについて説明する。図７は、本発明の第１実施形態に係る、マッチング方法に係るフローチャートの一例である。

まず、本システム１を利用するために、ユーザ及び／または医療機関は、ユーザ端末２００、医療機関端末３００各々によりインターネットブラウザやアプリケーションソフト等を利用してサーバ端末１００にアクセスし、初めてサービスを利用する場合は、前述のユーザ基本情報等、医療機関基本情報等を各々入力し、既にユーザ、医療機関のアカウントを取得済の場合は、例えばＩＤとパスワードを入力する等の所定の認証を受けてログインすることで、サービスが利用可能となる（ステップＳ１０１）。この認証後、ウェブサイトやアプリケーションソフト等を介して所定のユーザインターフェースが提供される。

次に、サーバ端末１００は、ユーザ端末２００からユーザの病状に関連する情報および／またはユーザの診療希望に関連する情報を受け付ける。例えば、サーバ端末１００の制御部１３０の指示受付部１３１は、ユーザ端末２００から通信部１１０を介して、ユーザの病状に関連する情報および／またはユーザの診療希望に関連する情報を受信し、受信した情報を記憶部１２０のユーザデータ格納部１２１に記憶する（ステップＳ１０２）。なお、ユーザの病状に関連する情報および／またはユーザの診療希望に関連する情報の取得方法としては、様々な形態が考えられるが、一例として、サーバ端末１００は、ユーザの病状に関連する情報および／またはユーザの診療希望に関連する情報を取得するための質問（例えば、頭痛の有無や頻度、痛みの程度など）をユーザ端末２００に対して提供し、ユーザは、ユーザ端末２００の画面に表示される質問画面を通じて回答することで、例えばユーザの病状に関連する情報を提供することができる。これにより、自覚症状に関するユーザの知識が十分でなかったとしても、サーバ端末１００から提供された質問に対して回答するだけで、適切な医療機関や診療科などを選択することができる。また、その他の形態として、後述の図８のような方法で取得することができる。

次に、サーバ端末１００は、ユーザ端末２００から取得した情報と、医療機関端末３００から登録された情報とを比較してマッチングし（ステップＳ１０３）、条件に合う医療機関の医療機関端末３００へ、少なくともユーザから取得した情報を送信する（ステップＳ１０４）。なお、この時に、ユーザの基本情報の必要な項目を併せて送信してもよい。

また、サーバ端末１００は、機械学習等を通じて、医療機関の選定に際して、ユーザが提供した情報に類似した他のユーザに対して選定した医療機関を選定することができる。この場合、そのユーザが最終的にその医療機関を選定したか、ポジティブな評価をしたか、に基づいて、医療機関を選定することもできる。また、サーバ端末１００は、ユーザがフリーテキストで入力した情報を自然言語分析によりキーワードを特定し、特定されたキーワードに基づいて、医療機関を選定することもできる。

続いて、医療機関端末３００は、サーバ端末１００から送信された複数のユーザから取得した情報を表示する。そして、医療機関では、表示された情報の内容を確認し、その内容に応じて診療の可否を決定する（ステップＳ１０５）。これにより、大学病院などのユーザが集中する医療機関においては、事前にユーザの情報を確認して診療を断ることができるので、ユーザの誤選択により生じる診察待ち時間の拡大を防止することができる。一方、例えば上述の質問による病状の判定や、後述の図８のような方法により得られた情報を基にマッチングを行っているため、不特定多数のユーザと医療機関がマッチングされることにもなり、例えば個人開業医のように新規設立された医療機関は、積極的に診療を許可することによって、ユーザに広く認知してもらうことが可能である。なお、診療の可否を決定する際に、医療機関がユーザ情報のみでの判断が難しい場合等には、ユーザに直接質問を行ったり、ユーザの基本情報にある疾患や既往歴を参照するなどしてもよい。医療機関とユーザとの間で質問等のやり取りを行う場合、例えば、医療機関は、サービス事業者のオペレータを経由して電話等でやり取りしたり、ユーザの連絡先（Ｅメール、チャットアカウント等）に直接メールを送信したり、サーバ端末１００によって提供される質問／回答フォーム等を介してメッセージを送信したりすることができる。サーバ端末１００のマッチングログデータ管理部１３４は、やり取りの内容をマッチングログとして、記憶部１２０のマッチングログデータ格納部１２３に格納する。マッチングログを蓄積することで、機械学習等により、マッチングを成立するために必要な質問を自動生成することができる。

サーバ端末１００は、医療機関端末３００から診療可否情報を受け取り（ステップＳ１０６）、その診療可否情報から結果情報を生成して（ステップＳ１０７）、その結果情報をユーザ端末２００へ送信する（ステップ１０８）。なお、この結果情報は、診療可否情報を受信するたびに医療機関ごとに生成してもよいし、一定期間内で受信した複数の診療可否情報をまとめて生成してもよい。また、ここで、医療機関端末３００は、診療を許可しない場合は、代替案として、他の医師または医療機関をユーザに対してレコメンドすることができる。例えば、医療機関の医師は、ユーザの病状や既往歴等を参照し、そのユーザの診療により適した医師や医療機関を紹介することができる。または、医療機関の医師は、ユーザの紹介状の取得状況を確認し、紹介状の無い場合に、医療機関の所在する地域またはユーザが住む地域の医療機関を紹介することができる。

ユーザ端末２００は、受信した結果情報の中から、希望に沿う医療機関を選択し、具体的な診療予約の手続きを実行する。なお、具体的な診療予約の手続きを実行する前に、ユーザ端末２００から自覚症状について相談を行ったり、医療機関端末３００から事前問診を行ったりしてもよい。この場合、メールアドレスやユーザＩＤ等の連絡先を参照することで、サーバ端末１００を介さずに、両者が直接連絡を取れるようにしてもよい。

なお、ユーザ端末２００や医療機関端末３００が加入するプラン（例えば、有料プレミアムプランなど）に応じて、ユーザまたは医療機関が利用できるサービスの上限を拡張などできるようにしてもよい。より具体的例としては、医療機関端末３００の設定に応じて、表示されるユーザ情報をプレミアムプランユーザのみに限定したり、または、プレミアムプランユーザを優先的に上位に表示したり、質問や相談を直接可能な回数に差異を設けたり（例えば、通常プランは０または１回、プレミアムプランは無制限など）してもよいが、これに限らない。

また、サーバ端末１００は、医療機関にて診療を終了したユーザ端末２００から、その医療機関に対する評価情報を受け付けることができる。評価情報として、ユーザから医療機関に宛てたメッセージ、口コミ情報、レーティング情報（例えば、１つ星から５つ星からなる段階的評価）等の情報を受け取ることができる。サーバ端末１００は、ユーザ端末２００から受信した評価情報を、医療機関情報を表示するウェブページ等に表示する処理を行うことができる。

なお、図７に示す、医療機関端末３００によって実行される処理について、サーバ端末１００が実行し、サーバ端末１００を管理する事業者のオペレータが、例えば、ユーザに関する情報や診療可否等の必要な情報について、医療機関及び／または医師に対してやり取りすることもできる。

図８は、上述の図７におけるステップ１０２からステップ１０４の他の形態について説明するものであり、本発明の第１実施形態に係る、マッチング方法に係るフローチャートの一例である。

ユーザ端末２００から、例えば、医師紹介ページや、医療機関紹介ページ、治療法紹介ページ、特定の病気に関する特集の記事ページなどのｗｅｂコンテンツまたはアプリケーションソフトコンテンツを通じて診療を希望することにより、そのコンテンツにタグ付けされた情報を基に、ユーザの病状に関連する情報および／またはユーザの診療希望に関連する情報をサーバ端末１００に送信することができる（ステップ１０２）。これにより、自覚症状に関するユーザの知識が十分でなかったとしても、適切な医療機関や診療科などを選択することができる。また、医療機関や医師の選び方がわからないままに、例えば第三者におすすめされた医療機関や医師に診療予約をする場合、診療に対する納得感が得にくく、不安が残ることも従来あり得るが、本発明の実施形態においては、事前に医療機関や医師、治療方法、病気についての情報を十分に得ることができるため、ユーザの納得感が高く、不安が少ない診療が可能となる。なお、上記コンテンツは、上述のものに限らず、例えば、ユーザ評価に関する投稿ページなどのユーザが作成したコンテンツであってもよい。

また、医療機関端末３００に表示されるユーザ情報は、例えば、ユーザの病状に関連する情報および／またはユーザの診療希望に関連する情報に応じて、表示順位を変えることも可能である（ステップ１０４）。より具体的な例としては、特集記事ページからの診療希望については、医療機関や医師、病状を考慮した希望であるため、表示順位の優先度を高く設定し、治療法紹介ページからの診療希望については、その治療法が実施可能であればいずれの医療機関でもよいため、表示順位の優先度を低く設定することができる。一方、治療方法が特殊である場合、表示順位の優先度を高く設定するようにしてもよいが、表示順位に関しては、これらに限定されるものではない。なお、ここでは表示順位の優先度について記載したが、例えば医療機関や医師への直接コンタクト（例えば、相談や質問など）についての優先順位を変更することもできる。

また、他の例として、医療機関端末３００に表示される患者情報の並び順及び絞り込み機能を備えることができる。例えば、並び順として、おすすめ順（病名、難病、緊急度、治療状況（例：確定診断を受け治療先検討中、確定診断を受けセカンドオピニオン先検討中、疾患疑いで検査中、いずれも当てはまらない等）、（セカンドオピニオン等の自由診療に対する）課金状況の組合せまたはいずれかに基づく）、新着順、（第２実施形態で述べる）患者に対する医療機関からの診療オファーが多い順）の順で表示結果を並べて表示することができ、また、絞り込みとして、病名、診療希望の有無、年齢、性別、治療状況で表示結果を絞り込むことができる。

図９は、ユーザ端末２００において特定の病気をフォロー登録し、医療機関や医師へのコンタクトを行う画面の一例である。

図９（ａ）は、ユーザ端末２００のＷｅｂブラウザまたはアプリケーションソフトからサーバ端末１００にアクセスすることにより表示される、病気のフォロー一覧画面の一例である。本ページにおいて、ユーザは、気になる病気や既に治療を受けている病気を選択のうえ登録する。図９（ａ）においては、扁桃炎が登録された旨例示しているが、複数の病気をフォロー登録することも可能である。例えば、ユーザは、病気一覧の画面を通じて、扁桃炎について、治療状況として誰（例：本人、配偶者、子ども、両親、その他）が治療中であるか、その治療の現状（例：確定診断を受け治療先検討中、確定診断を受けセカンドオピニオン先検討中、疾患疑いで検査中、いずれも当てはまらない等）を編集することができる。ユーザは病気をフォロー登録すると、その病気に関する新着記事や新着のユーザ投稿コンテンツなどの上述したコンテンツなどについて、登録された連絡先（メールアドレス等）やアプリケーションソフトを介して受信することができる。

図９（ｂ）は、病気をフォロー登録する画面の一例である。例えば、ユーザは、複数の病気の中から「扁桃炎」という病気を選択すると、扁桃炎に関する説明、扁桃炎に関する新着記事、関連する医療機関や医師を紹介するページへのリンク等を表示する画面が表示される。また、同じ画面または別画面において、扁桃炎について、ユーザに対してフォロー登録を促すメッセージ（例：「この病気を登録する」）及びフォロー登録するためのボタン／アイコンが表示される。

図９（ｃ）は、病気のフォロー登録完了画面の一例である。例えば、ユーザは、図９（ｂ）に示す画面において、「この病気を登録する」ボタン／アイコンを押下すると、図９（ｃ）に示すように、登録完了画面が表示される。また、同じ画面または別画面において、その病気について治療リクエストを医療機関または医師に対して行うことを促すメッセージ（例：「この疾患の話が聞きたい」）及びフォロー登録するためのボタン／アイコンが表示される。また、治療リクエストのための画面を、図９（ｃ）に示すフォロー登録画面のほか、図９（ａ）に示す画面の、ユーザがフォローする病気の、上記治療状況等の（図示しない）詳細編集画面においても表示することができる。このように、ユーザは、ユーザ端末１００に表示される、病気に関するフォローページを経由して、図７に示すような診希望（ステップ１０２）及び／または治療状況の詳細をサーバ端末１００に送信することもできる。これにより、ユーザは、気になる、または、診断を受けている病気をフォローし、場合によって、その病気に関する近況を編集しながら、適切なタイミングで病気について医療機関または医師に相談をすることができる。なお、ユーザがフォロー登録として入力した内容または編集後の内容を、ユーザ端末２００からサーバ端末１００へ送信することも可能である。そうすることで、例えば医療端末３００において診療可否を判断する際に、この内容を併せて診療可否を判断することが可能となる。

以上のように、自覚症状に関するユーザの知識が十分でなかったとしても、ユーザ端末を操作するだけで、適切な医療機関や診療科などを選択することができる。また、事前にユーザの情報を確認して診療を断ることができるので、ユーザの誤選択により生じる診察待ち時間の拡大を防止することができる。さらに、不特定多数のユーザと医療機関がマッチングされることにもなるため、医療機関が積極的に診療を許可することによって、ユーザに広く認知してもらうことが可能である。

（第２実施形態）
第１の実施形態においては、ユーザから医療機関や医師に対する診療を希望する形態について説明したが、本実施形態においては、医療機関や医師からユーザに対する診療を希望する形態について説明する。なお、本実施形態のシステム構成、サーバ端末、ユーザ端末、医療機関端末の機能ブロック構成は、第１の実施形態と同等であるので、説明を省略する。

図１０を参照しながら、本実施形態のシステム１が実行するユーザと医療機関とのマッチング方法の処理の流れについて説明する。図１０は、本発明の第２実施形態に係る、マッチング方法に係るフローチャートの一例である。

まず、本システム１を利用するために、ユーザ及び／または医療機関は、ユーザ端末２００、医療機関端末３００各々によりインターネットブラウザやアプリケーションソフト等を利用してサーバ端末１００にアクセスし、初めてサービスを利用する場合は、前述のユーザ基本情報等、医療機関基本情報等を各々入力し、既にユーザ、医療機関のアカウントを取得済の場合は、例えばＩＤとパスワードを入力する等の所定の認証を受けてログインすることで、サービスが利用可能となる（ステップＳ２０１）。この認証後、ウェブサイトやアプリケーションソフト等を介して所定のユーザインターフェースが提供される。

次に、サーバ端末１００は、医療機関端末３００から病状や疾患名をキーとしたユーザ検索要求を受信する（ステップＳ２０２）。例えば、サーバ端末１００の制御部１３０の指示受付部１３１は、医療機関端末３００から通信部３１０を介して、病状に関連する情報および／または疾患名情報に関連するキーワードを受信し、受信したキーワードに基づいて、ユーザデータ格納部１２１に格納されたユーザデータを検索する（ステップＳ２０３）。具体的には、サーバ端末１００は、医療機関端末２００から取得したキーワードと、ユーザデータ１０００に含まれる病状情報とを比較し、条件にマッチする一または複数のユーザを抽出する。ここで、医療機関端末３００において、医師は、病状や疾患名のほか、例えば、緊急度、治療状況（例：確定診断を受け治療先検討中、確定診断を受けセカンドオピニオン先検討中、疾患疑いで検査中、いずれも当てはまらない等）等で検索及び／または絞り込みを行うことができる。

続いて、サーバ端末１００は、条件にマッチする一または複数のユーザに関する情報（例えば、ユーザＩＤ、基本情報、病状情報等）を医療機関端末３００に送信する（ステップＳ２０４）。

続いて、医療機関端末３００は、サーバ端末１００から送信された複数のユーザに関する情報を参照し、選択したユーザに対する診療希望情報をサーバ端末１００に送信する（ステップＳ２０５）。これにより、大学病院などのユーザが集中する医療機関においては、事前にユーザの情報を確認してニーズがマッチするユーザに対する診療希望を行うことができるので、ユーザの誤選択により生じる診察待ち時間の拡大を防止することができる。また、医療機関において、医師は、例えば、病名のほか、その病気の進行度等による絞り込みを行い、患者を特定し、診療のオファー（希望）を出すことで、その病気の治療に強みを持つ医師及び治療を必要とする患者の双方のニーズをマッチさせることができる。

サーバ端末１００は、医療機関端末３００から診療を希望するユーザに関する情報を受け取り、ユーザ端末２００に対してその医療機関及び／または医師に関する情報とともにユーザに対する診療希望情報を送信する（ステップＳ２０６）。医療機関に関する情報として、医療機関名、紹介文、所在地、診療時間、医療施設、在籍医師、診療科、治療実績、専門性、評価に関する情報等が挙げられ、医師に関する情報として、略歴、論文、執筆記事、治療実績、専門性、評価に関する情報等が挙げられる。

ユーザ端末２００は、受診した医療機関及び／または医師に関する情報を参照し、診療可否を選択し（ステップＳ２０７）、診療可否情報をサーバ端末１００へ送信する（ステップ２０８）。サーバ端末１００は、請け負った診療可否情報を基に結果情報を生成する（ステップＳ２０９）。なお、この結果情報は、診療可否情報を受信するたびに生成してもよいし、一定期間内で受信した複数の診療可否情報をまとめて生成してもよい。

サーバ端末１００は、結果情報を医療機関端末３００に送信する（ステップＳ２１０）。続いて、医療機関端末３００は、具体的な診療予約の手続きを実行することができる。なお、具体的な診療予約の手続きを実行する前に、ユーザ端末２００から自覚症状について相談を行ったり、医療機関端末３００から事前問診を行ったりしてもよい。この場合、メールアドレスやユーザＩＤ等の連絡先を参照することで、サーバ端末１００を介さずに、両者が直接連絡を取れるようにしてもよい。

１ マッチングシステム
１００ サーバ端末
２００ ユーザ端末
３００ 医療機関端末
ＮＷ ネットワーク

Claims (5)

1. ネットワークで接続される、医療機関に関連する医療機関端末と、ユーザに関連するユーザ端末と、を仲介するサーバ端末により提供される、前記医療機関と前記ユーザとのマッチングシステムであって、
   前記サーバ端末は、
   前記ユーザ端末より前記ユーザの病状に関連する情報および／または前記ユーザの診療希望に関連する情報を受信し、
   当該受信した情報と事前に登録された医療機関情報と比較し、
   当該比較した結果に基づき、少なくとも前記ユーザの病状に関連する情報および／または前記ユーザの診療希望に関連する情報を含むユーザ情報を、前記医療機関端末へ送信し、
   前記ユーザの診療可否を示す診療可否情報を、前記医療機関端末から受信する、
   マッチングシステム。
2. 前記ユーザの病状に関連する情報および／または前記ユーザの診療希望に関連する情報は、前記サーバ端末から提供される質問に回答することにより得られる、
   ことを特徴とする請求項１に記載のマッチングシステム。
3. 前記ユーザの病状に関連する情報および／または前記ユーザの診療希望に関連する情報は、前記ユーザ端末から閲覧可能なコンテンツを通じて診療を希望することにより得られる、
   ことを特徴とする請求項１に記載のマッチングシステム
4. 前記ユーザの病状に関連する情報および／または前記ユーザの診療希望に関連する情報に応じて、前記医療機関端末に表示される前記ユーザ情報の表示順位を設定する、
   ことを特徴とする請求項１乃至３に記載のマッチングシステム。
5. 前記ユーザ端末または前記医療機関端末が加入しているプランに応じて、前記医療機関端末に表示される前記ユーザ情報の表示順位を変更可能とする、
   ことを特徴とする請求項１乃至４に記載のマッチングシステム。