(57)【要約】【課題】患者を取り巻く環境に応じて患者が適切な診療科を選択することを目的とする。【解決手段】端末から問診に対するユーザの回答情報を受信し、受信した前記回答情報に応じて前記ユーザに対応する所在地及び主訴を特定し、診療履歴情報を記憶する記憶部を参照して、特定した前記所在地の周辺地域の、特定した前記主訴に対応する他のユーザの診療履歴情報を抽出し、抽出した前記他のユーザの診療履歴情報に対応する診療科を推奨する、処理をコンピュータに実行させることを特徴とする診療科推奨プログラムが提供される。【選択図】図１
2019087196.tif 000002
【特許請求の範囲】
【請求項１】
端末から問診に対するユーザの回答情報を受信し、
受信した前記回答情報に応じて前記ユーザに対応する所在地及び主訴を特定し、
診療履歴情報を記憶する記憶部を参照して、特定した前記所在地の周辺地域の、特定した前記主訴に対応する他のユーザの診療履歴情報を抽出し、抽出した前記他のユーザの診療履歴情報に対応する診療科を推奨する、
処理をコンピュータに実行させることを特徴とする診療科推奨プログラム。
【請求項２】
前記ユーザに対応する所在地は、前記回答情報又は該ユーザの基本情報を記憶する記憶部を参照して、前記ユーザが指定した特定の地域、該ユーザの居住地、該ユーザの勤務地、該ユーザの現在位置及び該ユーザが過去所定時間内に滞在した地域の少なくともいずれかを含む、
請求項１に記載の診療科推奨プログラム。
【請求項３】
前記ユーザの診療履歴情報から前記主訴に対応する診療科を抽出し、
抽出した前記診療科に応じて、診療科を推奨する際の優先順位を定める基準となる前記推奨する診療科の推奨割合の補正を行う、
請求項１又は２に記載の診療科推奨プログラム。
【請求項４】
補正定義情報を記憶する記憶部を参照して、前記ユーザに関する属性情報が前記補正定義情報の条件を満たすか否かを判定し、判定結果に基づき前記推奨する診療科の推奨割合の補正を行う、
請求項３に記載の診療科推奨プログラム。
【請求項５】
前記推奨する診療科が複数存在し、複数の前記診療科の推奨割合が同じ場合、混雑情報を記憶する記憶部を参照して、複数の前記診療科のうち、混雑が少ない診療科の推奨割合を混雑が多い診療科の推奨割合よりも高めるように補正を行う、
請求項３又は４に記載の診療科推奨プログラム。
【請求項６】
前記推奨する診療科の推奨割合に基づき、前記推奨割合が高い診療科から順に前記ユーザに表示する、
請求項１〜５のいずれか一項に記載の診療科推奨プログラム。
【請求項７】
前記推奨する診療科に対応させて、前記回答情報に含まれる特定の地域に関する病院の情報又は前記回答情報に含まれる特定の病院に関する情報を表示する、
請求項６に記載の診療科推奨プログラム。
【請求項８】
端末から問診に対するユーザの回答情報を受信し、
受信した前記回答情報に応じて前記ユーザに対応する所在地及び主訴を特定し、
診療履歴情報を記憶する記憶部を参照して、特定した前記所在地の周辺地域の、特定した前記主訴に対応する他のユーザの診療履歴情報を抽出し、抽出した前記他のユーザの診療履歴情報に対応する診療科を推奨する、
手順をコンピュータが実行する診療科推奨方法。
【請求項９】
端末から問診に対するユーザの回答情報を受信する受信部と、
受信した前記回答情報に応じて前記ユーザに対応する所在地及び主訴を特定する特定部と、
診療履歴情報を記憶する記憶部を参照して、特定した前記所在地の周辺地域の、特定した前記主訴に対応する他のユーザの診療履歴情報を抽出し、抽出した前記他のユーザの診療履歴情報に対応する診療科を推奨する推奨部と、
を有する情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、診療科推奨プログラム、診療科推奨方法及び情報処理装置に関する。
【背景技術】
【０００２】
人は調子が悪くなると、自らの症状に応じてどの診療科に行くべきかを判断し、判断した診療科のある医療機関を探す。医療機関に来院した人は、初めに受付で問診票に症状等を記入し、問診票の記入後に希望する診療科へ案内される。
【０００３】
早期に適切な診療行為を受けることは、患者の命を救ったり、予後の生活の質を良好にするために非常に重要である。そのため、最初に希望した診療科では疾病名の判断に至らずに、患者が、複数の診療科で診察を受けたり、他の医療機関を紹介してもらって他の医療機関で診察を受けたりすることで適切な診療行為を受けるまでに長時間を要することは極力避けたい。
【０００４】
一方、患者は自分の症状から受診すべき診療科を的確に判断できない場合がある。この場合、患者が来院した医療機関の窓口で受診すべき診療科を問合せ、問診内容や患者の状態に応じて、病院職員や看護婦がどの診療科で診察してもらうべきかを判断し、判断した診療科に案内することが行われる。この場合、患者は、より適切な診療科で診察を受け得る可能性は高まる。
【０００５】
近年、診察をネット予約するシステムでは、患者は病院に行かずに特定の診療科への受診を予約する。このため、患者は、窓口で受診すべき診療科を問合せ、問診内容や患者の状態に応じて、病院職員や看護婦にどの診療科で診察すべきかを判断してもらうことはできない。そこで、患者が適切な診療科を選択できるように支援するネット予約システムが提案されている（例えば、特許文献１、２を参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１４−１９１６３８号公報
【特許文献２】特開２０１４−１９９５９７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１、２にて開示されている技術では、患者の主訴から疾病名を類推したり、診療科を提示することはできるが、患者の取り巻く環境に応じてどの診療科で診察してもらうべきかを判断することは困難である。
【０００８】
そこで、１つの側面では、本発明は、患者を取り巻く環境に応じて患者が適切な診療科を選択することを目的とする。
【課題を解決するための手段】
【０００９】
１つの実施態様では、端末から問診に対するユーザの回答情報を受信し、受信した前記回答情報に応じて前記ユーザに対応する所在地及び主訴を特定し、診療履歴情報を記憶する記憶部を参照して、特定した前記所在地の周辺地域の、特定した前記主訴に対応する他のユーザの診療履歴情報を抽出し、抽出した前記他のユーザの診療履歴情報に対応する診療科を推奨する、処理をコンピュータに実行させることを特徴とする診療科推奨プログラムが提供される。
【発明の効果】
【００１０】
１つの側面では、本発明は、患者を取り巻く環境に応じて患者が適切な診療科を選択することができる。
【図面の簡単な説明】
【００１１】
【図１】一実施形態に係るネット予約システムの全体構成の一例を示す図。
【図２】一実施形態に係るネット予約システムの全体構成の一例を示す図。
【図３】一実施形態に係る情報処理装置の機能構成の一例を示す図。
【図４】一実施形態に係る情報処理装置のハードウェア構成の一例を示す図。
【図５】一実施形態に係る予約受付処理の一例を示すフローチャート。
【図６】一実施形態に係る予約受付時のスマートフォン操作の一例を示す図。
【図７】一実施形態に係る診療科推奨処理の一例を示すフローチャート。
【図８】一実施形態に係る基本情報ＤＢの一例を示す図。
【図９】一実施形態に係る特定の地域にて推奨する診療科の一例を示す図。
【図１０】一実施形態に係る居住地等にて推奨する診療科の一例を示す図。
【図１１】一実施形態に係る過去一定期間の滞在地にて推奨する診療科の一例を示す図。
【図１２】一実施形態に係る診療科推奨補正処理の一例を示すフローチャート。
【図１３】一実施形態に係る推奨する診療科の補正結果の一例を示す図。
【図１４】一実施形態に係る推奨する診療科の補正結果の一例を示す図。
【図１５】一実施形態に係る推奨する診療科の補正結果の一例を示す図。
【図１６】一実施形態に係る混雑情報テーブルの一例を示す図。
【図１７】一実施形態に係る診察予約画面の一例を示す図。
【発明を実施するための形態】
【００１２】
以下、本発明の実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。
【００１３】
［システムの全体構成］
まず、本発明の一実施形態に係るネット予約システム１の構成の一例について、図１を参照しながら説明する。図１は、本実施形態に係るネット予約システム１の構成の一例を示す。本実施形態に係るネット予約システム１は、情報処理装置１０及びスマートフォン２０ａ、２０ｂを有する。情報処理装置１０とスマートフォン２０ａ、２０ｂとは、ネットワーク４０を介して接続可能になっている。
【００１４】
情報処理装置１０は、〇大学病院や△個人病院や×個人病などの病院の診療科のネット予約を受け付けるシステムを提供する。情報処理装置１０は、診察予約プログラム１２を動作させることで、診療科のネット予約サイトを提供する。ユーザ（以下、「患者」ともいう。）は、スマートフォン２０ａ、２０ｂを用いてネット予約サイトにアクセスし、所定の病院の所定の診療科のネット予約を行う。
【００１５】
情報処理装置１０は、診察予約プログラム１２の手順に従い、ネット予約サイトにアクセスしたユーザに対して問診への回答を要求し、ユーザの回答情報をスマートフォン２０ａ、２０ｂから受信する。情報処理装置１０は、ユーザの回答情報からユーザの主訴（部位と症状の組み合わせ）を特定し、特定した主訴に応じて流行性及び地域性を考慮した診療科を推奨する。患者が病院に掛かる際、自分の症状に対して掛かるべき診療科がわからないことが多い。例えば「めまい」と「吐き気」がする場合、耳鼻科なのか内科なのか脳神経なのか判断がつかず、病院へ行って病院職員に相談したり、まず総合診療科に掛かってから専門の診療科を再受診したりする。一方、近年、ネット予約システムを利用することが多くなり、患者は「とりあえず病院に行って聞く」ということができない状況がある。この結果、適切な診療科に受診できないケースや受診すべき診療科がどの科なのかに迷うケースが多くなっている。そこで、本実施形態に係る情報処理装置１０は、患者を取り巻く環境に応じて患者が適切な診療科を選択することを目的とし、診療履歴情報とユーザに対応する所在地（地域性）とを組み合わせて、より患者の環境に合わせた診療科を推奨する。
【００１６】
ユーザは、スマートフォン２０ａ、２０ｂ（以下、総称して「スマートフォン２０」ともいう。）を用いて情報処理装置１０が提供するネット予約システムのサイトにアクセスする。スマートフォン２０は、診察予約アプリケーション（コンシェルジュ）を立ち上げ、情報処理装置１０が提供するネット予約サイトにアクセスする。スマートフォン２０は、情報処理装置１０からの問診への回答要求に対してユーザが入力した回答情報を受け付け、受け付けた回答情報を情報処理装置Ｉ１０に送信する。スマートフォン２０ａ、２０ｂは、情報処理装置１０が提供するネット予約システム１を利用する端末の一例である。
【００１７】
なお、情報処理装置１０は、サーバ、パーソナルコンピューター等のいかなる電子機器であってもよい。ネット予約システム１を利用する端末は、スマートフォン２０に限らず、タブレット型端末、ＰＤＡ（Personal Digital Assistants）、ＨＭＤ（Head Mount Display）、ＦＭＤ（Face Mount Display）等のウェアラブルデバイスを用いてもよい。
【００１８】
情報処理装置１０は、病院内のＰＣ３０ａ〜３０ｅ（以下、総称して「ＰＣ３０」ともいう。）とネットワーク４０を介して接続可能になっている。情報処理装置１０は、ＰＣ３０から診療履歴情報、混雑情報等をリアルタイムに取得し、これらの情報に基づきユーザの環境に合わせた診療科を推奨する。病院は、複数の診療科を有する大規模病院であってもよく、１つの診療科を有する個人病院であってもよい。
【００１９】
図２は、本発明の一実施形態に係るネット予約システム１の他の構成例を示す。図１の例では、情報処理装置１０は、病院内のＰＣ３０とは別体であったが、図２の例では、情報処理装置１０は、病院内に配置され、病院内のＰＣ３０と一体であってもよいし、別体であってもよい。本例においても情報処理装置１０とスマートフォン２０ａ、２０ｂとは、ネットワーク４０を介して接続可能になっており、情報処理装置１０は、病院の診療科のネット予約を受け付けるシステムを提供する。この場合においても、情報処理装置１０は、病院内のＰＣ３０や他の病院のＰＣ３０から診療履歴情報、混雑情報等をリアルタイムに取得し、これらの情報に基づきユーザの環境に合わせた診療科を推奨する。
【００２０】
なお、図１及び図２に示す、情報処理装置１０、スマートフォン２０及びＰＣ３０がネットワーク４０を介して互いに接続されているシステム形態は、本実施形態に係るネット予約システム１の一態様であり、これに限定されない。例えば、本実施形態に係るネット予約システム１に含まれる情報処理装置１０、スマートフォン２０及びＰＣ３０のそれぞれの台数は、１台又は２台以上であり得る。複数台の情報処理装置１０が設置される場合、ネット予約（診察予約処理及び診療科推奨処理は、複数台の情報処理装置１０で分散処理され得る。なお、用途や目的に応じて、複数台のうち１台の情報処理装置１０に選択的にそれら処理機能を集約させてもよい。
【００２１】
情報処理装置１０は、クラウド上のサーバにより実現されてもよい。また、情報処理装置１０は、病院内の複数のＰＣ３０によって実現されてもよい。
【００２２】
［機能構成］
次に、本実施形態に係る情報処理装置１０の機能構成の一例について、図３を参照しながら説明する。図３は、一実施形態に係る情報処理装置１０の機能構成の一例を示す。本実施形態に係る情報処理装置１０は、記憶部２、受信部３、送信部４、特定部５、取得部６、推奨部７、算出部８、補正部９及び表示制御部１１を有する。
【００２３】
記憶部２は、診察予約プログラム１２及び診療科推奨プログラム１９を格納している。また、記憶部２は、基本情報ＤＢ１３、診療履歴情報ＤＢ１４、診療科推奨情報テーブル１５、病院位置テーブル１６、補正定義テーブル１７及び混雑情報テーブル１８を記憶する。記憶部２に記憶された各ＤＢ及び各テーブルの情報は、情報処理装置１０内で記憶及び管理する替わりに、クラウド上の記憶装置にて記憶及び管理するようにしてもよい。また、これらの各ＤＢ及び各テーブルの情報は、病院等の医療機関内の記憶装置やＰＣ３０により管理され、必要に応じて医療機関内の記憶装置から転送されるようにしてもよい。
【００２４】
なお、前提として、病院等の医療機関は、診療情報システムを導入しており、情報処理装置１０は、診療履歴情報等の必要な情報を参照できるようになっている。また、情報処理装置１０が提供する診察のネット予約システムと診療情報システムとは連携しており、情報処理装置１０は、リアルタイムに診療科ごとの混雑状況を把握できるようになっている。
【００２５】
受信部３は、ネット予約サイトにアクセスしたスマートフォン２０から、問診に対するユーザの回答情報を受信する。送信部４は、スマートフォン２０やＰＣ３０に所定の情報の送信要求を行ったり、その他の所定の情報を送信したりする。特定部５は、受信した回答情報に応じて、ユーザに対応する所在地及び主訴を特定する。ユーザに対応する所在地は、受信した回答情報又は該回答情報に含まれる患者ＩＤ等に関連付けて基本情報ＤＢ１３から抽出されるユーザの基本情報から特定される、前記ユーザが指定した特定の地域、該ユーザの居住地、該ユーザの勤務地、該ユーザの現在位置及び該ユーザが過去所定時間内に滞在した地域の少なくともいずれかを含む。ユーザに対応する所在地に含まれる各地域は、同一地域又は異なる地域であり得る。
【００２６】
本実施形態では、ユーザが過去所定時間内に滞在した地域は、ユーザが直近の過去１ヶ月内に滞在した地域のうち、最も多く滞在した地域である。しかしながら、これに限らず、ユーザが直近の過去１ヶ月内に滞在した地域のうち、所定期日（例えば数日や５日）以上滞在した地域であってもよいし、ユーザが直近の過去１ヶ月内に滞在したすべての地域であってもよい。
【００２７】
過去一定期間に当該ユーザが最も多く滞在した地域の特定方法としては、当該ユーザの位置情報のログ（履歴情報）を取って、最も多く滞在した地域を特定してもよい。
【００２８】
取得部６は、受信した回答情報に含まれる患者ＩＤ等からユーザの基本情報を取得する。推奨部７は、診療履歴情報ＤＢ１４を参照して、特定したユーザに対応する所在地又はその周辺を所在地とする他のユーザの診療履歴情報から、主訴に対応する他のユーザの診療科を推奨する。
【００２９】
算出部８は、抽出された診療科に基づき診療科の推奨割合を算出し、記憶部２の診療科推奨情報テーブル１５に記憶する。例えば、図９（ａ）の診療履歴情報ＤＢ１４に示す領域Ｐは、特定したユーザに対応する所在地又はその周辺を所在地とする他のユーザの診療履歴情報から、めまいを主訴にして対応する他のユーザの診療科を抽出した結果を示す。診療科の推奨割合は、領域Ｐに一例を示す抽出した全診療科に対する各診療科の受診割合であり、抽出した全診療科に対して各診療科を推奨する際の優先順位を定める基準となる。例えば、図９（ａ）の例では、領域Ｐに示す整形外科（２回）と耳鼻科（１回）と内科（１回）の診療科の受診に基づき、算出部８は、図９（ｂ）に示すように整形外科の推奨割合を、５０％（＝（２／４）×１００）と算出し、耳鼻科と内科の推奨割合を、２５％（＝（１／４）×１００）と算出する。
【００３０】
補正部９は、診療履歴情報ＤＢ１４から主訴に対応するユーザ自身の診療科を特定し、特定したユーザの診療科の履歴情報に基づき、ユーザの既往歴等を考慮して診療科の推奨割合を補正してもよい。
【００３１】
また、補正部９は、ユーザに関する属性情報が、補正定義テーブル１７に定義された補正定義情報の条件を満たすか否かを判定し、判定結果に基づき推奨する診療科の推奨割合の補正を行ってもよい。ユーザに関する属性情報には、年齢、性別、家族構成、既往症等が挙げられる。例えば、補正部９の補正の一例としては、ユーザの年齢が５０歳の場合、小児科には受診しないため、推奨する診療科に小児科が含まれる場合には、小児科の推奨割合を０にする補正を行う等が挙げられる。また、補正部９は、複数の診療科の推奨割合が同じ場合、混雑情報テーブル１８を参照して、複数の診療科のうち、混雑が少ない診療科の推奨割合を混雑が多い診療科の推奨割合よりも高めるように補正してもよい。
【００３２】
表示制御部１１は、診療科への推奨割合に基づき、推奨割合が高い診療科から順に、推奨する診療科をスマートフォン２０の画面に表示する。また、表示制御部１１は、推奨する診療科とともに、ユーザの回答情報に含まれる特定の病院又は特定の地域に関する情報をスマートフォン２０に表示してもよい。
【００３３】
［ハードウェア構成］
次に、本実施形態に係る情報処理装置１０のハードウェア構成の一例について、図４を参照しながら説明する。図４は、一実施形態に係る情報処理装置１０のハードウェア構成の一例を示す。本実施形態に係る情報処理装置１０は、入力装置１０１、表示装置１０２、外部Ｉ／Ｆ１０３、ＲＡＭ（Random Access Memory）１０４、ＲＯＭ（Read Only Memory）１０５、ＣＰＵ（Central Processing Unit）１０６、通信Ｉ／Ｆ１０７、及びＨＤＤ（Hard Disk Drive）１０８などを備え、それぞれがバスＢで相互に接続されている。
【００３４】
入力装置１０１は、キーボードやマウスなどを含み、情報処理装置１０に各操作信号を入力するために用いられる。表示装置１０２は、ＬＣＤ（Liquid crystal Display）モニタ等のディスプレイ、プリンタ、ＣＲＴ（Cathode Ray Tube）などを含み、各種の処理結果を表示する。通信Ｉ／Ｆ１０７は、情報処理装置１０をネットワーク４０に接続するインターフェースである。これにより、情報処理装置１０は、通信Ｉ／Ｆ１０７を介して、スマートフォン２０及びＰＣ３０とデータ通信を行うことができる。
【００３５】
ＨＤＤ１０８は、プログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、情報処理装置１０の全体を制御する基本ソフトウェア及びアプリケーションソフトウェアがある。例えば、ＨＤＤ１０８には、各種のデータベースやプログラム等が格納されてもよい。
【００３６】
外部Ｉ／Ｆ１０３は、外部装置とのインターフェースである。外部装置には、記録媒体１０３ａなどがある。これにより、情報処理装置１０は、外部Ｉ／Ｆ１０３を介して記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１０３ａには、ＣＤ（Compact Disk）、及びＤＶＤ（Digital Versatile Disk）、ならびに、ＳＤメモリカード（SD Memory card）やＵＳＢメモリ（Universal Serial Bus memory）等がある。
【００３７】
ＲＯＭ１０５は、電源を切っても内部データを保持することができる不揮発性の半導体メモリである。ＲＯＭ１０５には、ネットワーク設定等のプログラム及びデータが格納されている。ＲＡＭ１０４は、プログラムやデータを一時保持する揮発性の半導体メモリである。ＣＰＵ１０６は、ＨＤＤ１０８やＲＯＭ１０５などの記憶装置から、プログラムやデータをＲＡＭ１０４上に読み出し、処理を実行することで、装置全体の制御や搭載機能を実現する演算装置である。
【００３８】
かかる構成により、本実施形態に係る情報処理装置１０は、例えばＲＡＭ１０４に読み込まれた診察予約プログラム１２をＣＰＵ１０６に実行させることで、本実施形態に係る診察予約処理を実現する。また、本実施形態に係る情報処理装置１０は、例えばＲＡＭ１０４に読み込まれた診療科推奨プログラム１９をＣＰＵ１０６に実行させることで、本実施形態に係る診療科推奨処理を実現する。つまり、特定部５、取得部６、推奨部７、算出部８、補正部９及び表示制御部１１の各機能は、例えば、診療科推奨プログラム１９が、ＣＰＵ１０６に実行させる診療科推奨処理により実現可能である。
【００３９】
受信部３及び送信部４の機能は、例えば、通信Ｉ／Ｆ１０７により実現可能である。記憶部２の機能は、例えば、ＲＡＭ１０４、ＲＯＭ１０５、ＨＤＤ１０８又はネットワーク４０を介して接続されたクラウド上の記憶装置により実現可能である。
【００４０】
［予約受付処理］
次に、本実施形態に係る予約受付処理の一例について図５を参照して説明する。図５は、一実施形態に係る予約受付処理の一例を示すフローチャートである。本実施形態に係る予約受付処理では、ユーザが、スマートフォン２０にインストールされた診察予約アプリケーション（コンシェルジュ）を立ち上げると（ステップＳ１）、スマートフォン２０は、問診にかかる質問を表示する。スマートフォン２０は、問診に対してユーザが入力した回答情報を受け付け（ステップＳ２）、受け付けた回答情報を情報処理装置１０に送信する（ステップＳ３）。
【００４１】
例えば、図６に一例を示すように、ユーザは、スマートフォン２０に表示された問診に回答する。問診の一例としては、図６（１）に示す予約したい特定の地域（又は特定の病院）、図６（２）に示す「めまい」等の主訴が挙げられる。ユーザの患者ＩＤ、受診目的、治療中の病名、既往歴、アレルギーの有無等は、基本情報として自動入力され得る。ただし、ユーザにより入力される回答情報は、これに限らない。
【００４２】
本実施形態では、患者ＩＤが「１１１」のＡさんをユーザの一例として挙げて説明する。Ａさんは４５歳の女性であり、６月２０日（現在日）に「めまい」を主訴として診察のネット予約を行うユーザである。Ａさんは、頸椎ヘルニアを治療中である。回答情報には、ユーザが入力した情報と自動生成された情報とが含まれ得る。
【００４３】
回答情報は、特定の地域及び主訴の他、ユーザの居住地、ユーザの勤務地、ユーザの現在位置、ユーザが過去所定時間内に滞在した地域の少なくともいずれかを含んでもよい。回答情報にユーザが入力した現在位置の情報が含まれている場合、ＧＰＳ等を利用してスマートフォン２０が取得したユーザの現在位置を所定時間毎に情報処理装置１０に送信する必要がなくなる。
【００４４】
［診療科推奨処理］
次に、本実施形態に係る診療科推奨処理の一例について図７を参照して説明する。図７は、一実施形態に係る診療科推奨処理の一例を示すフローチャートである。本実施形態に係る診療科推奨処理が開始されると、まず、受信部３が、スマートフォン２０から問診に対するユーザの回答情報を受信する（ステップＳ１０）。
【００４５】
次に、特定部５は、回答情報に含まれる特定の地域及び主訴を特定する（ステップＳ１２）。特定部５は、回答情報に含まれるユーザの現在位置、居住地、勤務地、過去一か月間の滞在地を特定してもよい。回答情報にユーザの現在位置が含まれていない場合、取得部６は、スマートフォン２０から現在位置の情報を取得してもよい。
【００４６】
また、特定部５は、回答情報にユーザの基本情報が含まれる場合、ユーザの属性情報を取得する。回答情報にユーザの基本情報が含まれていない場合、取得部６は、基本情報ＤＢから患者ＩＤに紐付けられたユーザの基本情報を取得する（ステップＳ１２）。基本情報ＤＢ１３の一例を図８に示す。ユーザ「Ａ」は患者ＩＤが「１１１」であるため、取得部６は、基本情報ＤＢ１３を参照して、ユーザ「Ａ」の基本情報のうち、属性情報の一例である年齢や性別を取得してもよい。取得部６は、ユーザ「Ａ」の居住地や勤務地の情報を取得してもよい。
【００４７】
図７に戻り、次に、推奨部７は、診療履歴情報ＤＢ１４を参照して、特定の地域を所在地とした病院において受診した他のユーザの診療履歴情報から、主訴に対応する診療科を抽出し、診療科推奨情報テーブル１５に記憶する（ステップＳ１４）。
【００４８】
図９に一例を示すように、特定の地域を地域ＩＤが「００１」の地域と仮定すると、ステップＳ１４の処理では、図９（ａ）は、診療履歴情報ＤＢ１４から、ユーザ「Ａ」の患者ＩＤ「１１１」以外の他のユーザの診療履歴情報であって、地域ＩＤが「００１」、主訴がユーザ「Ａ」の症状と同じ「めまい」の診療履歴情報が抽出される。この結果、特定の地域において過去に「めまい」を訴えた他のユーザは、図９（ａ）の領域Ｐに示すように、整形外科（２回）と耳鼻科（１回）と内科（１回）の診療科を受診していることがわかる。この結果、推奨部７は、推奨する診療科を「整形外科」、「耳鼻科」、「内科」とし、推奨割合を診療科推奨情報テーブル１５に記憶する。この例では、受診回数から「整形外科」の推奨割合が５０％、「耳鼻科」及び「内科」の推奨割合が２５％となる。図９（ｂ）には、診療科推奨情報テーブル１５に、推奨する診療科と推奨割合とが記憶されている例を示す。診療科推奨情報テーブル１５には、各診療科の受診回数を記憶してもよい。
【００４９】
図７に戻り、次に、推奨部７は、ユーザの現在位置、居住地、勤務地、過去一か月間の滞在地が、特定の地域と異なるか否かを判定する（ステップＳ１６）。推奨部７は、回答情報又はユーザの基本情報から、ユーザの現在位置、居住地、勤務地、過去一か月間の滞在地のすべてが特定の地域に含まれると判定した場合、ステップＳ２２に進む。また、推奨部７は、回答情報又はユーザの基本情報に、ユーザの現在位置、居住地、勤務地、過去一か月間の滞在地のいずれの情報も存在しないと判定した場合、ステップＳ２２に進む。
【００５０】
一方、ステップＳ１６において、推奨部７は、ユーザの現在位置、居住地、勤務地、過去一か月間の滞在地のすべてが特定の地域と異なると判定した場合、ステップＳ１８に進む。更に、ステップＳ１６において、推奨部７は、ユーザの現在位置、居住地、勤務地が特定の地域に含まれ、過去一か月間の滞在地が特定の地域と異なると判定した場合、ステップＳ２０に進む。
【００５１】
ステップＳ１８において、推奨部７は、診療履歴情報ＤＢ１４を参照して、ユーザの現在位置、居住地及び勤務地の周辺のうち特定の地域と異なる地域を所在地とする病院を受診した他のユーザの診療履歴情報を抽出し、抽出した前記他のユーザの診療履歴情報に対応する診療科を推奨する。また、推奨部７は、推奨する診療科及び推奨割合を診療科推奨情報テーブル１５に記憶する。
【００５２】
図１０は、ステップＳ１８の処理を説明するための図である。ここでは、ユーザの現在位置の地域ＩＤが「０３１」であり、特定の地域の地域ＩＤ「００１」と異なる。この結果、ユーザの現在位置の地域ＩＤ「０３１」において過去に「めまい」を訴えた他のユーザは、図１０（ａ）のＢに示すように、整形外科（２回）と耳鼻科（２回）の診療科を受診していることがわかる。この結果、推奨部７は、推奨する診療科を「整形外科」、「耳鼻科」、「内科」とし、整形外科（２回）と耳鼻科（２回）の受診履歴に基づき、推奨する診療科と診療科推奨情報テーブル１５の推奨割合とを図１０（ｂ）に示すように記憶する。加えて、診療科推奨情報テーブル１５に各診療科の受診回数を記憶してもよい。
【００５３】
図７に戻り、ステップＳ２０において、推奨部７は、診療履歴情報ＤＢ１４を参照して、ユーザが過去一か月間内に滞在した地域のうち最も長く滞在した地域が、特定の地域と異なる場合、当該滞在地域を所在地とする病院を受診した他のユーザの診療履歴情報を抽出し、抽出した記他のユーザの診療履歴情報に対応する診療科を推奨する。また、推奨部７は、推奨する診療科及び推奨割合を診療科推奨情報テーブル１５に記憶する。
【００５４】
図１１は、ステップＳ２０の処理を説明するための図である。ここでは、ユーザの過去一か月間の現在位置情報から、図１１（ａ）に示す患者ＩＤ「１１１」のＡさんの過去一か月間内に滞在した滞在地の位置情報（経度及び緯度）と滞在時間とを含む情報が抽出される。この結果、推奨部７は、図１１（ｂ）に示すように、抽出した滞在地のうち最も長く滞在した位置情報（経度及び緯度）の範囲に含まれる病院名「〇〇病院」とその病院が存在する地域ＩＤ「９９１」とを、病院位置テーブル１６を参照して定める。
【００５５】
推奨部７は、図１１（ｃ）に示すように、定めた地域ＩＤ「９９１」において過去に「めまい」を訴えた他のユーザの受診した診療科を求める。
【００５６】
この結果、図１１（ｃ）のＥに示すように、整形外科（１回）と婦人科（１回）と耳鼻科（１回）の診療科を受診していることがわかる。この結果、推奨部７は、推奨する診療科を「整形外科」、「耳鼻科」、「内科」、「婦人科」とし、推奨割合を診療科推奨情報テーブル１５に記憶する。加えて、診療科推奨情報テーブル１５に各診療科の受診回数を記憶してもよい。図１１（ｄ）には、診療科推奨情報テーブル１５に、推奨する診療科と推奨割合とが記憶されている例を示す。
【００５７】
図７に戻り、次に、補正部９は、推奨する診療科の推奨割合を補正する（ステップＳ２２）。
【００５８】
（補正処理）
ステップＳ２２の補正処理では、図１２に示す一実施形態に係る補正処理が呼び出される。補正処理が開始されると、補正部９は、患者ＩＤが「１１１」の当該ユーザ自身の過去の診療履歴情報から主訴に対応する診療科を抽出し、診療科の推奨割合を補正する（ステップＳ３０）。
【００５９】
図１３は、図１２のステップＳ３０の処理を説明するための図である。図１３（ａ）は、患者ＩＤが「１１１」のユーザ「Ａ」の問診に対する回答情報Ｆを示し、図１３（ｂ）は、回答情報Ｆに従い、診療履歴情報ＤＢ１４から患者ＩＤが「１１１」のユーザ「Ａ」の診療履歴情報のうち、Ａさんが過去に「めまい」を訴えたときの受診状況を示す。図１３（ｂ）のＧに示すように、ユーザ「Ａ」は過去に整形外科を２回受診していることがわかる。この結果、図１３（ｃ）に示すように、推奨部７は、推奨する診療科を「整形外科」、「耳鼻科」、「内科」とし、各診療科の推奨割合を補正して整形外科の推奨割合を高め、診療科推奨情報テーブル１５に記憶する。
【００６０】
図１２に戻り、補正部９は、補正定義テーブル１７を参照して、患者ＩＤが「１１１」の当該ユーザ自身の基本情報から抽出したユーザ属性に基づき、診療科の推奨割合を補正する（ステップＳ３２）。
【００６１】
図１４（ａ）に、補正定義テーブル１７の一例を示す。補正定義テーブル１７には、補正定義情報と診療科に応じた推奨割合の加減割合とが記憶されている。ユーザの所定の属性情報が補正定義情報の条件を満たすとき、診療科に応じた推奨割合の加減割合に応じて該当診療科の推奨割合が補正される。ユーザ「Ａ」の属性情報から、年齢は４５歳、性別は女性である。よって、図１４（ａ）のＨに示すように、Ａさんは、補正定義テーブル１７の年齢が４０歳よりも大きいという条件を満たす。よって、補正部９は、診療科推奨情報テーブル１５に記憶された、耳鼻科の加減割合に応じて推奨割合を１０％増やすように補正する。この結果、図１４（ｂ）のＩに示すように、診療科推奨情報テーブル１５に記憶されている耳鼻科の推奨割合が１０％上がるように補正される。
【００６２】
図１２に戻り、補正部９は、推奨割合が同一の診療科があるかを判定する（ステップＳ３４）。補正部９は、推奨割合が同一の診療科がないと判定した場合、本処理を終了する。一方、補正部９は、推奨割合が同一の診療科があると判定した場合、混雑情報テーブル１８を参照して、混雑が少ない診療科の推奨割合を混雑が多い診療科の推奨割合よりも高めるように補正し（ステップＳ３６）、本処理を終了する。
【００６３】
図１５（ａ）のＪに示すように、内科と婦人科との推奨割合は同一である。よって、補正部９が、図１６に一例を示す混雑情報テーブル１８を参照すると、婦人科の待ち時間は内科の待ち時間よりも少ない。よって、補正部９は、混雑が少ない婦人科の診療科の推奨割合を、相対的に混雑が多い内科よりも高めるように補正する。この結果、図１５（ｂ）に示すように、診療科推奨情報テーブル１５に記憶された、婦人科の補正後の推奨割合は、耳鼻科の補正後の推奨割合よりも大きい値となっている。
【００６４】
図７に戻り、次に、表示制御部１１は、補正後の推奨割合が高い順に、診療科を並べ替えて表示する（ステップＳ２４）。本処理を実行することで、図１５（ｃ）に示すように、推奨する診療科は、推奨割合が高い順に並べ替えられ、診療科の上から順に表示される。
【００６５】
図１２に戻り、次に、表示制御部１１は、回答情報に含まれる「特定の地域」の病院に関する情報又は「特定の病院」に関する情報を表示し（ステップＳ２６）、本処理を終了する。ただし、ユーザが予め定めた「特定の病院」の診療科を推奨する場合には、ステップＳ２６は省略でき、病院に関する情報を表示せず、推奨する診療科のみ表示される。
【００６６】
図１７は、スマートフォン２０に表示される当日診察予約画面の一例を示す。図１７（ａ）は、推奨する診療科が示され、病院に関する情報が表示されていない場合の画面の一例である。例えば、ユーザが「特定の病院」を予め指定している場合、「特定の病院」内に存在する診療科のうち、推奨される診療科が上から順番に表示される。
【００６７】
当日診察予約画面では、受診希望の診療科を選択可能に表示する。ユーザが、表示されている診療科のいずれかのボックスチェックし、選択すると、当該病院の選択した診療科のネット予約が行われる。なお、推奨される診療科が特定の病院内にない場合、図１７（ａ）の婦人科に示すようにグレーに塗潰されて表示され、選択不可能とされる。
【００６８】
ユーザが診療科をタップすると、推奨の理由が表示される。例えば、図１７（ａ）の当日診察予約画面の一例では、ユーザが整形外科をタップする。そうすると、推奨の理由として、「同じ主訴で、過去患った患者が多い診療科です。最近、同じ主訴でよく受診されています。」という説明文が表示されている。これにより、ユーザは、推奨される診療科を受診すべきかの判定材料の一つにすることができる。
【００６９】
図１７（ｂ）の当日診察予約画面の一例では、推奨する診療科とともに、特定の地域の病院名が表示されている。診療科毎に一つ又は複数の病院が表示されてもよい。ただし、特定の地域の病院名は、特定の地域の病院に関する情報の一例であり、これに限らない。図１７（ｂ）の画面の一例においても診療科をタップすると、推奨の理由が表示される。また、病院名をタップすると、病院に関する詳しい情報が表示されるようにしてもよい。
【００７０】
以上に説明したように、本実施形態にかかる情報処理装置１０が行う診療科推奨方法によれば、診療履歴情報と地域性を組み合わせて、よりユーザの環境に合わせた診療科を推奨する。本実施形態における「地域性」とは、ユーザが特定する地域、当該ユーザの居住地周辺の地域、当該ユーザの勤務地周辺の地域、受診する特定の病院周辺の地域、当該ユーザの現在位置周辺の地域、過去一定期間の間で当該ユーザが多く滞在した地域等、ユーザに対応する所在地をいう。
【００７１】
本実施形態にかかる情報処理装置１０は、以上のユーザに対応する所在地（地域）における他のユーザの診療履歴情報に基づき、当該ユーザと主訴を同一にする他のユーザが受信した診療科を抽出し、当該ユーザの属性や受診時期で抽出した診療科の推奨割合を補正する。その結果、推奨割合の高い診療科から順に「推奨する診療科」として当該ユーザのスマートフォン２０に提示する。これにより、当該ユーザの所在する又は一定期間所在した地域においてその頃流行していた病気の傾向を、主に他のユーザの受診した診療科として把握し、地域性及び流行性を考慮した診療科の推奨を行う。これにより、患者であるユーザを取り巻く環境に応じてユーザが適切な診療科を選択することができる。
【００７２】
この結果、ユーザは病院に掛かるときに症状に応じた適切な診療科に受診することができ、医療機関は、ユーザがネット予約において適切な診療科を選択することで、受付や診療科における混雑を緩和することができる。
【００７３】
本実施形態に係るネット予約システム１の利用シーンとしては、大学病院などの複数診療科が受診可能な病院や個人病院における診察のネット予約システムが挙げられる。病院の替わりに、企業が診察のネット予約システムを運営してもよい。ユーザは、スマートフォン２０等から本実施形態に係るネット予約システム１の予約サイトにアクセスする。当該ユーザが、過去に特定の病院に掛かったことがある場合は患者ＩＤ、問診情報（受診目的、主訴、治療中の病気、既往歴等）を入力すると、ネット予約システム１は、そのユーザが訴える主訴に適した順番に診療科を表示する。当該ユーザは、その中から診療科をひとつ選定し、診察予約を行う。
【００７４】
推奨する診療科は、補正部９により推奨割合を補正した後の推奨割合に応じた順番で表示することが好ましい。ただし、図７のステップＳ２２の補正処理を省き、補正部９により推奨割合を補正する前の推奨割合に応じた順番で推奨する診療科を表示してもよい。
【００７５】
以上、診療科推奨プログラム、診療科推奨方法及び情報処理装置を上記実施形態により説明したが、本発明に係る診療科推奨プログラム、診療科推奨方法及び情報処理装置は上記実施形態に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能である。また、上記実施形態及び変形例が複数存在する場合、矛盾しない範囲で組み合わせることができる。
【００７６】
以上の説明に関し、更に以下の項を開示する。
（付記１）
端末から問診に対するユーザの回答情報を受信し、
受信した前記回答情報に応じて前記ユーザに対応する所在地及び主訴を特定し、
診療履歴情報を記憶する記憶部を参照して、特定した前記所在地の周辺地域の、特定した前記主訴に対応する他のユーザの診療履歴情報を抽出し、抽出した前記他のユーザの診療履歴情報に対応する診療科を推奨する、
処理をコンピュータに実行させることを特徴とする診療科推奨プログラム。
（付記２）
前記ユーザに対応する所在地は、前記回答情報又は該回答情報に対応するユーザの基本情報を記憶する記憶部を参照して、前記ユーザが指定した特定の地域、該ユーザの居住地、該ユーザの勤務地、該ユーザの現在位置及び該ユーザが過去所定時間内に滞在した地域の少なくともいずれかを含む、
付記１に記載の診療科推奨プログラム。
（付記３）
前記ユーザの診療履歴情報から前記主訴に対応する診療科を抽出し、
抽出した前記診療科に応じて、診療科を推奨する際の優先順位を定める基準となる前記推奨する診療科の推奨割合の補正を行う、
付記１又は２に記載の診療科推奨プログラム。
（付記４）
補正定義情報を記憶する記憶部を参照して、前記ユーザに関する属性情報が前記補正定義情報の条件を満たすか否かを判定し、判定結果に基づき前記推奨する診療科の推奨割合の補正を行う、
付記３に記載の診療科推奨プログラム。
（付記５）
前記推奨する診療科が複数存在し、複数の前記診療科の推奨割合が同じ場合、混雑情報を記憶する記憶部を参照して、複数の前記診療科のうち、混雑していない診療科の推奨割合を混雑している診療科の推奨割合よりも高くする補正を行う、
付記３又は４に記載の診療科推奨プログラム。
（付記６）
前記推奨する診療科の推奨割合に基づき、前記推奨割合が高い診療科から順に前記ユーザに表示する、
付記１〜５のいずれか一項に記載の診療科推奨プログラム。
（付記７）
前記推奨する診療科に対応させて、前記回答情報に含まれる特定の地域に関する病院の情報又は前記回答情報に含まれる特定の病院に関する情報を表示する、
付記６に記載の診療科推奨プログラム。
（付記８）
端末から問診に対するユーザの回答情報を受信し、
受信した前記回答情報に応じて前記ユーザに対応する所在地及び主訴を特定し、
診療履歴情報を記憶する記憶部を参照して、特定した前記所在地の周辺地域の、特定した前記主訴に対応する他のユーザの診療履歴情報を抽出し、抽出した前記他のユーザの診療履歴情報に対応する診療科を推奨する、
手順をコンピュータが実行する診療科推奨方法。
（付記９）
前記ユーザに対応する所在地は、前記回答情報又は該回答情報に対応するユーザの基本情報を記憶する記憶部を参照して、前記ユーザが指定した特定の地域、該ユーザの居住地、該ユーザの勤務地、該ユーザの現在位置及び該ユーザが過去所定時間内に滞在した地域の少なくともいずれかを含む、
付記８に記載の診療科推奨方法。
（付記１０）
前記ユーザの診療履歴情報から前記主訴に対応する診療科を抽出し、
抽出した前記診療科に応じて、診療科を推奨する際の優先順位を定める基準となる前記推奨する診療科の推奨割合の補正を行う、
付記８又は９に記載の診療科推奨方法。
（付記１１）
補正定義情報を記憶する記憶部を参照して、前記ユーザに関する属性情報が前記補正定義情報の条件を満たすか否かを判定し、判定結果に基づき前記推奨する診療科の推奨割合の補正を行う、
付記１０に記載の診療科推奨方法。
（付記１２）
前記推奨する診療科が複数存在し、複数の前記診療科の推奨割合が同じ場合、混雑情報を記憶する記憶部を参照して、複数の前記診療科のうち、混雑していない診療科の推奨割合を混雑している診療科の推奨割合よりも高くする補正を行う、
付記１０又は１１に記載の診療科推奨方法。
（付記１３）
前記推奨する診療科の推奨割合に基づき、前記推奨割合が高い診療科から順に前記ユーザに表示する、
付記８〜１２のいずれか一項に記載の診療科推奨方法。
（付記１４）
前記推奨する診療科に対応させて、前記回答情報に含まれる特定の地域に関する病院の情報又は前記回答情報に含まれる特定の病院に関する情報を表示する、
付記１３に記載の診療科推奨方法。
（付記１５）
端末から問診に対するユーザの回答情報を受信する受信部と、
受信した前記回答情報に応じて前記ユーザに対応する所在地及び主訴を特定する特定部と、
診療履歴情報を記憶する記憶部を参照して、特定した前記所在地の周辺地域の、特定した前記主訴に対応する他のユーザの診療履歴情報を抽出し、抽出した前記他のユーザの診療履歴情報に対応する診療科を推奨する推奨部と、
を有する情報処理装置。
（付記１６）
前記ユーザに対応する所在地は、前記回答情報又は該回答情報に対応するユーザの基本情報を記憶する記憶部を参照して、前記ユーザが指定した特定の地域、該ユーザの居住地、該ユーザの勤務地、該ユーザの現在位置及び該ユーザが過去所定時間内に滞在した地域の少なくともいずれかを含む、
付記１５に記載の情報処理装置。
（付記１７）
前記ユーザの診療履歴情報から前記主訴に対応する診療科を抽出し、
抽出した前記診療科に応じて、診療科を推奨する際の優先順位を定める基準となる前記推奨する診療科の推奨割合の補正を行う補正部を有する、
付記１５又は１６に記載の情報処理装置。
（付記１８）
前記補正部は、補正定義情報を記憶する記憶部を参照して、前記ユーザに関する属性情報が前記補正定義情報の条件を満たすか否かを判定し、判定結果に基づき前記推奨する診療科の推奨割合の補正を行う、
付記１７に記載の情報処理装置。
（付記１９）
前記補正部は、前記推奨する診療科が複数存在し、複数の前記診療科の推奨割合が同じ場合、混雑情報を記憶する記憶部を参照して、複数の前記診療科のうち、混雑していない診療科の推奨割合を混雑している診療科の推奨割合よりも高くする補正を行う、
付記１７又は１８に記載の情報処理装置。
（付記２０）
前記推奨する診療科の推奨割合に基づき、前記推奨割合が高い診療科から順に前記ユーザに表示する表示制御部を有する、
付記１５〜１９のいずれか一項に記載の情報処理装置。
（付記２１）
前記表示制御部は、前記推奨する診療科に対応させて、前記回答情報に含まれる特定の地域に関する病院の情報又は前記回答情報に含まれる特定の病院に関する情報を表示する、
付記２０に記載の情報処理装置。
【符号の説明】
【００７７】
１    ネット予約システム
２    記憶部
３    受信部
４    送信部
５    特定部
６    取得部
７    推奨部
８    算出部
９    補正部
１０  情報処理装置
１１  表示制御部
１２  診察予約プログラム
１３  基本情報ＤＢ
１４  診療履歴情報ＤＢ
１５  診療科推奨情報テーブル
１６  病院位置テーブル
１７  補正定義テーブル
１８  混雑情報テーブル
１９  診療科推奨プログラム
２０  スマートフォン
３０  端末
４０  ネットワーク
【図１】
2019087196.tif 000003
【図２】
2019087196.tif 000004
【図３】
2019087196.tif 000005
【図４】
2019087196.tif 000006
【図５】
2019087196.tif 000007
【図６】
2019087196.tif 000008
【図７】
2019087196.tif 000009
【図８】
2019087196.tif 000010
【図９】
2019087196.tif 000011
【図１０】
2019087196.tif 000012
【図１１】
2019087196.tif 000013
【図１２】
2019087196.tif 000014
【図１３】
2019087196.tif 000015
【図１４】
2019087196.tif 000016
【図１５】
2019087196.tif 000017
【図１６】
2019087196.tif 000018
【図１７】
2019087196.tif 000019