(57)【要約】      （修正有）【課題】患者の来院状況を客観的な基準で把握可能とする来院管理装置、来院管理プログラム及び来院管理システムを提供する。【解決手段】来院管理システム２００において、クライアント端末７０とインターネット８０を介して接続するサーバ３６の来院管理装置３０は、レセプトデータＲｄに含まれる情報の少なくとも一部をレセプト情報として蓄積可能であり、レセプト情報に基づいて所定の情報を生成可能な制御装置３２を有する。制御装置３２は、レセプト情報に含まれる情報を、患者ごとに紐付けられた患者データベースとして構築可能であり、少なくとも一部の患者について、レセプト情報に基づいて、来院周期を設定する。【選択図】図１
2019212303.tif 000002
【特許請求の範囲】
【請求項１】
レセプトデータに含まれる情報の少なくとも一部をレセプト情報として蓄積可能であり、前記レセプト情報に基づいて所定の情報を生成可能な制御装置を有し、
前記制御装置が、
前記レセプト情報に含まれる情報を、患者ごとに紐付けられた患者データベースとして構築可能であり、
少なくとも一部の患者について、前記レセプト情報に基づいて、来院周期を設定可能であることを特徴とする来院管理装置。
【請求項２】
前記制御装置が、
前記レセプト情報のうち、最終来院日の診療行為に係る情報、処方箋日数に係る情報、及び傷病に係る情報のうちの少なくともひとつに基づいて、前記来院周期を設定可能であることを特徴とする請求項１に記載の来院管理装置。
【請求項３】
前記制御装置が、
前記レセプト情報のうち、最終来院日の診療行為に係る情報と処方箋日数に係る情報とを少なくとも含む情報に基づいて、前記来院周期を設定可能であり、
前記診療行為に係る情報が、前記処方箋日数に係る情報よりも優先して前記来院周期が設定されることを特徴とする請求項１又は２に記載の来院管理装置。
【請求項４】
前記制御装置が、
最終来院日に係る情報と、前記来院周期とを含む情報に基づいて、患者を複数のカテゴリーに区分可能であることを特徴とする請求項１〜３のいずれかに記載の来院管理装置。
【請求項５】
前記制御装置が、
最終来院日に係る情報と、前記来院周期とを含む情報に基づいて、患者を複数のカテゴリーに区分可能であり、
最終来院日から少なくとも前記来院周期を含む所定日数を経過して再来院がない患者の少なくとも一部を流出可能性患者として区分することを特徴とする請求項１〜３のいずれかに記載の来院管理装置。
【請求項６】
前記制御装置が、
前記レセプト情報に基づいて、再来院を要する患者、あるいは再来院が見込まれる患者を再診患者として区分するものであり、
前記再診患者に対して前記来院周期を設定するものであることを特徴とする請求項１〜５のいずれかに記載の来院管理装置。
【請求項７】
前記制御装置が、
最終来院日に係る情報と、前記来院周期とを含む情報に基づいて、患者を複数のカテゴリーに区分可能であり、
前記カテゴリーごとの患者数を視覚的に視認可能とするカテゴリーマップに係る情報を生成可能であることを特徴とする請求項１〜６のいずれかに記載の来院管理装置。
【請求項８】
前記制御装置が、
少なくとも一部の患者をリストとして表示するとともに、患者ごとの来院状況に係る情報が含まれる来院履歴情報を生成可能であることを特徴とする請求項１〜７のいずれかに記載の来院管理装置。
【請求項９】
請求項１〜８のいずれかに記載の来院管理装置と、
インターネットを介して前記来院管理装置と接続可能なクライアント端末とを有し、
前記制御装置が、
前記クライアント端末から送信されたレセプトデータを、医療機関ごとのレセプト情報として蓄積可能であり、
前記レセプト情報に含まれる情報の少なくとも一部の統計を示す統計概要情報を前記医療機関ごとに生成可能であり、
前記統計概要情報を、対応する前記医療機関の前記クライアント端末に送信可能であることを特徴とする来院管理システム。
【請求項１０】
前記制御装置が、
前記レセプト情報に基づいて生成された所定の情報を、前記クライアント端末の表示装置に表示可能であることを特徴とする請求項９に記載の来院管理システム。
【請求項１１】
請求項１〜８のいずれかに記載の来院管理装置に用いられるプログラムであって、
前記制御装置に、
前記来院周期を設定する来院周期設定ステップを実行させることを特徴とする来院管理プログラム。
【請求項１２】
前記来院周期設定ステップにおいて、  前記レセプト情報のうち、最終来院日の診療行為に係る情報、処方箋日数に係る情報、及び傷病に係る情報のうちの少なくともひとつに基づいて、前記来院周期を設定する処理を行うことを特徴とする請求項１１に記載の来院管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、医療機関において、患者の来院状況を把握するための装置やシステム、あるいはプログラムに関する。
【背景技術】
【０００２】
医療機関においては、来院した患者毎にカルテが作成される。カルテには、各患者の住所や保険番号等の個人情報の他、行った治療の内容・方法を通院日毎に示す治療履歴、処方した薬の内容を通院日毎に示す処方履歴等が記録される。そして、医師は、カルテから過去の治療履歴や処方履歴を参照しながら治療を行う。また、医師は別途カルテを参照し、治療や処方の計画をたてることもできる。例えば、前回の来院時に検査を行った場合、医師は、検査結果が出る予定日を確認し、次回来院した際に、検査結果に応じた治療を行う日程の予定をたてることができる。また、前回の来院の際に行った治療を元に、治療の効果を確認できる日程を次回の来院予定日として計画を立てることができる。また、前回の来院の際に薬を何日分処方したかにより、次回の来院予定日を計画することもできる。このように、前回の治療の内容、検査と検査結果が出る日程、薬の処方等を考慮して、医師が治療の計画を立てることにより、病状が悪化することを未然に抑制したり、病状の悪化を早期に発見できたり、効率的に治療を行ったりすることができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１６−１６１９９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ここで、患者が来院を継続するか否かは、医療機関にとって経営の観点から重要となることに加え、患者の健康の維持、疾病の早期治癒の問題にも関わってくる。すなわち、医療機関にとって、経営的な観点から患者の流出を食い止めて患者を確保することが重要となることに加え、患者の流出を放置した結果、その患者の疾病の治療が長期化することが懸念される。例えば、複数回の来院で治療を行う必要がある傷病などでは、適切な来院サイクルで治療を行えば早期の治癒が見込めるものを、治療の途中で患者が来院しなくなると治療が長期化することが懸念される。
【０００５】
ところで、患者が来院するか否かは基本的には患者の意思に委ねられている。また、医師等の従事者が、患者に対して次回の来院日を指定したり、薬を処方したりしたとしても、患者が来院しない場合がある。その一方で、患者にとっては、医師等の医療機関の従事者から来院を促すアクションがあれば、来院する大きなきっかけとなり、結果として病気の早期治療につながる可能性がある。
【０００６】
しかしながら、医師等の医療関係の従事者は、人の健康の維持や病気の治癒等の社会的に大きな責任のもと、日々多忙な業務に追われている。そのため、医師等の医療機関の従事者が、患者に対して来院を促すアクションを起こしたいと考えたとしても、患者ごとの来院状況など、患者のひとりひとりの動きを把握することは極めて困難である。
【０００７】
また、傷病の内容や重篤度は患者により異なり、患者はそれぞれの病状に応じた来院サイクルで医療機関に通院している。そのため、患者が適切に来院しているか否かについては、一律の期限管理（例えば全ての患者に対して一律に１ヶ月の来院管理期限を設けるなど）では対応することができない。その一方で、医療機関にとって患者が流出しそうかどうかを、客観的な基準のもと把握することができれば、必要に応じて患者に来院を促すなど、何らかのアクションを起こすことが容易となる。
【０００８】
そこで本発明は、患者の来院状況を客観的な基準で把握可能とする来院管理装置、来院管理プログラム、及び来院管理システムの提供を目的とした。
【課題を解決するための手段】
【０００９】
ここで、本発明の発明者は、上述の課題を解決するための有効な手立てを模索した。まず、本発明の発明者は、医師等の従事者の手間を取らせることなく、疾病の内容や重篤度によって異なる患者ごとの適切な来院サイクルをいかにすれば設定できるかを模索した。
【００１０】
さらに本発明の発明者が思案したところ、医療機関で用いられるレセプトデータを活用することに想到した。具体的には、医療機関では、診療報酬を請求するためのレセプトデータが作成されている。また、レセプトデータには、傷病の名前や診療行為の内容、処方箋の日数など、患者の来院サイクルを推測し、適切な来院サイクルを設定するに足りる情報が含まれている。
【００１１】
また、診療報酬を請求する医療機関では、一般的にはレセプトを入力する業務（レセプト業務）が定期的に行われている。そのため、大部分の医療機関では、レセプトデータがすでにある。このような既存のデータを活用するとすれば、医療機関の従事者等に別途の作業を強いることなく、患者ごとの来院状況を把握するとともに、傷病内容などに応じて、患者ごとに来院周期を設定可能となる。
【００１２】
上述の知見に基づき提供される本発明の来院管理システムは、レセプトデータに含まれる情報の少なくとも一部をレセプト情報として蓄積可能であり、前記レセプト情報に基づいて所定の情報を生成可能な制御装置を有し、前記制御装置が、前記レセプト情報に含まれる情報を、患者ごとに紐付けられた患者データベースとして構築可能であり、少なくとも一部の患者について、前記レセプト情報に基づいて、来院周期を設定可能であることを特徴とするものである。
【００１３】
本発明の来院管理装置によれば、医療機関の従事者等に別途の作業を強いることなく、患者ごとの来院状況を把握するとともに、傷病内容などに応じて、患者ごとに来院周期を設定可能となる。また、患者ごとの来院周期を設定することができれば、医療機関の従事者が、患者が適切な期間に来院したか否か等について、客観的な判断基準とすることができる。
【００１４】
そのため、本発明の来院管理装置によれば、医師等の医療機関の従事者が、所定の患者に対して再来院を促すなどのアクションを起こすことができる。その結果、本発明の来院管理装置は、患者が流出することを抑制することに加え、再来院を要する患者の傷病の早期治癒に貢献することが期待される。
【００１５】
ここで、本発明の発明者は、来院周期の精度を高めるための構成について、さらに検討した。レセプトデータに含まれる情報のうち、来院周期を設定するに際し処方箋日数を来院周期とすれば、実際の来院サイクルに近い来院周期を設定可能であると考えられる。しかしながら、高血圧など、一定のサイクルで処方箋が処方される傷病もあれば、一度の処方で完治に至る傷病もあり、処方箋日数を一律に来院周期として設定すると、このような場合に対応できない。
【００１６】
本発明の発明者がさらに模索したところ、最終来院日の診療行為や処方箋日数などに基づいて来院周期を設定すると、来院周期の精度を高めることができるとの知見に至った。具体的に説明すると、最終来院日の診療行為として、例えば「検査」が行われた場合には患者に対して検査結果を伝えるための予約が設定されていると推測することができ、「リハビリ」が行われた場合にはリハビリが今後も所定のサイクルで行われることが予測できる。また、処方箋日数に基づいて来院周期を設定すれば、処方箋日数のサイクルに応じた来院周期を設定することができる。
【００１７】
本発明の来院管理装置は、前記制御装置が、前記レセプト情報のうち、最終来院日の診療行為に係る情報、処方箋日数に係る情報、及び傷病に係る情報のうちの少なくともひとつに基づいて、前記来院周期を設定可能であることが望ましい。
【００１８】
上述の構成によれば、来院周期の精度を高めることができる。
【００１９】
ここで、レセプトデータには様々な情報が含まれている。本発明の発明者が、これらの情報のいずれを優先して来院周期を設定するかについて検討したところ、処方箋日数よりも診療行為を優先して来院周期を設定することで、来院周期の精度を高めることができるとの知見に至った。具体的に説明すると、最終来院日において例えばリハビリが行われるとともに処方箋が処方されている場合などが想定される。このような場合に処方箋日数を優先して来院周期を設定すると想定すると、リハビリは定期的に（例えば３〜７日ごと）行う必要がある一方、処方箋は一ヶ月など所定の期間分処方される場合がある。このような場合、患者が次に来院することが予測される日は、処方箋がなくなる日ではなく、次にリハビリを行う日である。このように、処方箋日数に基づいて来院周期を設定すれば、精度を高めることができるものの、一律に処方箋日数で来院周期を設定することが妥当ではない場合もある。
【００２０】
上述の課題に対応するため、本発明の来院管理装置は、前記制御装置が、前記レセプト情報のうち、最終来院日の診療行為に係る情報と処方箋日数に係る情報とを少なくとも含む情報に基づいて、前記来院周期を設定可能であり、前記診療行為に係る情報が、前記処方箋日数に係る情報よりも優先して前記来院周期が設定されるものとするとよい。
【００２１】
上述の構成によれば、来院周期を設定する精度を、さらに高めることができる。
【００２２】
本発明の来院管理装置は、前記制御装置が、最終来院日に係る情報と、前記来院周期とを含む情報に基づいて、患者を複数のカテゴリーに区分可能であることが望ましい。
【００２３】
上述の構成によれば、患者が最終来院日から来院周期内に来院したか否かなど、客観的な基準で医師等の従事者が患者の来院状況を把握することができる。言い換えれば、本発明の来院管理装置によれば、医療機関の従事者が、来院が定着する（継続する）傾向にあるのか、適切な来院周期での来院から脱落する（流出する）傾向にあるのかといった患者ごとの傾向を容易に判別することができる。そのため、本発明の来院管理装置は、医療機関の従事者が、来院しなくなった患者をいち早く発見し、さらにフォローを要する患者であるか否かの判断が容易となる。その結果、本発明の来院管理装置は、医療機関の従事者が適切な来院周期から流出する可能性がある予備群的な患者（来院サイクルが遅れ始めている患者）に対して来院を促進するなどの対策を早い段階で講じることができる。
【００２４】
本発明の来院管理装置は、前記制御装置が、最終来院日に係る情報と、前記来院周期とを含む情報に基づいて、患者を複数のカテゴリーに区分可能であり、最終来院日から少なくとも前記来院周期を含む所定日数を経過して再来院がない患者の少なくとも一部を流出可能性患者として区分するものであることが望ましい。
【００２５】
上述の構成によれば、最終来院日と来院周期とに基づいて、適切な周期内に来院がなかった患者（例えば、適切な来院周期内で来院する患者のカテゴリーから流出する傾向にある患者）を「流出可能性患者」として抽出することができる。これにより、医療機関の従事者が、流出可能性患者に対して来院を促進するなどの対策を早い段階で講じることができる。
【００２６】
ここで、患者の中には、一度来院した後、再度来院する必要のない患者もいる。例えば、風邪やインフルエンザなど、処方箋や治療により一度の来院で完治する傷病もある。一度の来院で傷病等が完治する可能性が高い患者には来院周期を設定せずに、来院状況を看視する対象から除外して、再来院の必要がある患者や季節的な傷病等により再来院が見込まれる患者を抽出して来院周期が設定されることが望ましい。
【００２７】
本発明の来院管理装置は、前記制御装置が、前記レセプト情報に基づいて、再来院を要する患者、あるいは再来院が見込まれる患者を再診患者として区分するものであり、前記再診患者に対して前記来院周期を設定するものとするとよい。
【００２８】
上述の構成によれば、再来院を要する患者を抽出して来院周期を設定することができる。その一方、一度の来院で完治が見込まれる患者を、来院周期を設定する対象から除外することができる。その結果、来院状況を看視すべき患者を抽出して、より効率的な来院状況の管理を行い得る。
【００２９】
本発明の来院管理装置は、前記制御装置が、最終来院日に係る情報と、前記来院周期とを含む情報に基づいて、患者を複数のカテゴリーに区分可能であり、前記カテゴリーごとの患者数を視覚的に視認可能とするカテゴリーマップに係る情報を生成可能であってもよい。
【００３０】
上述の構成によれば、適切な来院周期内での来院から流出する傾向にある患者（流出可能性患者）やすでに流出したと考えられる患者（流出患者）等を、医療機関の従事者が視覚的に把握可能となる。その結果、医療機関の従事者等が、複数のカテゴリーに区分された患者数のボリュームを把握しやすくなる。
【００３１】
本発明の来院管理装置は、前記制御装置が、少なくとも一部の患者をリストとして表示するとともに、患者ごとの来院状況に係る情報が含まれる来院履歴情報を生成可能であることが望ましい。
【００３２】
上述の構成によれば、患者に対して再来院の促進を行うか否か等の判断に際し、従事者が、当該患者の過去の診療内容や来院状況を参照して、再来院を促す必要性や緊急性を判断することができる。
【００３３】
ここで、サービス提供者の端末やサーバなどに来院管理装置を設ければ、複数の医療機関に対して患者の来院状況を把握するための来院管理を行うサービスを提供することができる。このようなサービスを行うとした場合、医師等の従事者が来院管理装置に定期的にアクセスして、自らが所属する医療機関（以下、単に「自院」と記載する場合がある）の患者の来院状況を確認することが望ましい。しかしながら、医師等の従事者の業務は多忙を極めるため、従業者が積極的に来院管理装置にアクセスして患者の来院状況を確認することが望めない場合もある。
【００３４】
そこで本発明の発明者は、レセプトデータ（レセプトファイル）の受信後に、患者の来院状況の少なくとも一部を把握することができる情報を従事者に提供すれば、従事者が来院管理装置にアクセスするなど来院状況を確認しようとする動機となると考えた。具体的には、患者の来院状況の概要などが示されたメールを医療機関の従業者が閲覧するクライアント端末に送信すれば、従事者を来院管理装置にアクセスさせる動機付けとなり、従業者が定期的に来院管理装置にアクセスするきっかけになるとの知見に至った。
【００３５】
上述の知見に基づき提供される本発明の来院管理システムは、上述したいずれかの来院管理装置と、インターネットを介して前記来院管理装置と接続可能なクライアント端末とを有し、前記制御装置が、前記クライアント端末から送信されたレセプトデータを、医療機関ごとのレセプト情報として蓄積可能であり、前記レセプト情報に含まれる情報の少なくとも一部の統計を示す統計概要情報を前記医療機関ごとに生成可能であり、前記統計概要情報を、対応する前記医療機関の前記クライアント端末に送信可能であることを特徴とするものである。
【００３６】
本発明の来院管理システムによれば、来院管理状況の概要等が示されたメールなどを医療機関の従業者が閲覧するクライアント端末に送信し、従事者を来院管理装置にアクセスさせる動機付けとすることができる。
【００３７】
これにより、本発明の来院管理システムは、医師等の医療機関の従事者が、患者の来院状況を定期的に確認する動機付けとなり、患者に対して再来院を促すなどの対策を講じる動機付けとなる。その結果、本発明の来院管理システムは、患者が流出することを抑制することに加え、再来院を要する患者の傷病の早期治癒に貢献することが期待できる。
【００３８】
本発明の来院管理システムは、前記制御装置が、前記レセプト情報に基づいて生成された所定の情報を、前記クライアント端末の表示装置に表示可能であることが望ましい。
【００３９】
上述の構成によれば、医療機関が、来院管理装置が生成する各種の情報を自院のクライアント端末で確認して、患者の来院状況や再来院を要する患者等の来院状況の把握や、再来院を要する患者の傷病内容等、重大な傷病であるか否か等を確認することができる。
【００４０】
上述の知見に基づき提供される本発明の来院管理プログラムは、上述のいずれかに記載の来院管理装置に用いられるプログラムであって、前記制御装置に、前記来院周期を設定する来院周期設定ステップを実行させることを特徴とするものである。
【００４１】
本発明の来院管理プログラムによれば、医療機関の従事者等に別途の作業を強いることなく、患者ごとの来院状況を把握するとともに、傷病内容などに応じて、患者ごとに来院周期を設定可能となる。また、患者ごとの来院周期を設定することができれば、医療機関の従事者が、患者が適切な期間に来院したか否か等の判断材料とすることができる。
【００４２】
これにより、本発明の来院管理プログラムは、再来院を要するにも関わらず、未だ来院していない患者を客観的な基準で抽出することができる。そのため、本発明の来院管理プログラムによれば、医師等の医療機関の従事者が、所定の患者に対して再来院を促すなどのアクションを起こすことができる。その結果、本発明の来院管理プログラムは、患者が流出することを抑制することに加え、再来院を要する患者の傷病の早期治癒に貢献することが期待される。
【００４３】
上述の知見に基づき提供される本発明の来院管理プログラムは、前記来院周期設定ステップにおいて、  前記レセプト情報のうち、最終来院日の診療行為に係る情報、処方箋日数に係る情報、及び傷病に係る情報のうちの少なくともひとつに基づいて、前記来院周期を設定する処理を行うものとするとよい。
【００４４】
上述の構成によれば、来院周期の精度を高めることができる。
【００４５】
上述のとおり、いつ通院するかは、一般的に患者の意思に委ねられており、医師が、効率的な治療・通院の予定を立てて患者に次回の通院日を指定したとしても、予定した日に患者が通院しない場合があり、最善の治療が実施できない場合があるという問題点があった。
【００４６】
本発明は、上記問題点を解決するために、適切な日程で患者が通院するように促すことを補助することを目的とする。
【００４７】
上記目的を達成するために、本発明の一実施形態における通院管理方法は、複数の患者のレセプトデータを各医療機関からネットワークを介してサーバに読み込ませる工程と、前記レセプトデータから前記患者毎に通院履歴が整理された医療履歴情報および前記医療履歴情報と関連付けられて医療履歴が整理された医療詳細情報を対応する前記医療機関毎に前記サーバにて作成する工程と、前記サーバからネットワークを介して対応する前記医療機関に前記医療履歴情報を送信する工程とを有し、前記医療機関では前記医療履歴情報を用いて前記サーバにアクセスして前記サーバ内の前記医療詳細情報を閲覧可能であることを特徴とする。
【００４８】
このような方法により、医師等は、医療履歴情報により患者の通院履歴を確認しながら、さらに、医療詳細情報により患者の医療履歴を確認することによって、患者の来院状況とその患者の医療情報を検討し、それぞれの患者に最適な診療予定を立てることができると共に、必要に応じて患者の来院を促すこともできるため、最適な治療を行うことが可能となり、早期の完治を図ることができる。
【００４９】
さらに、本発明の一実施形態における通院管理装置は、制御装置と、ネットワークと接続される送受信器とを有し、前記送受信器は複数の医療機関それぞれから複数の患者のレセプトデータを受信し、前記制御装置は前記レセプトデータから前記患者毎に通院履歴が整理された医療履歴情報および前記医療履歴情報と関連付けられて医療履歴が整理された医療詳細情報を対応する前記医療機関毎に作成し、前記送受信器は対応する前記医療機関に前記医療履歴情報を送信し、前記制御装置は前記医療機関による前記医療履歴情報を介した操作により、前記医療機関に前記医療詳細情報を表示させることを特徴とする。
【００５０】
このような装置によっても、医師等は、医療履歴情報により患者の通院履歴を確認しながら、さらに、医療詳細情報により患者の医療履歴を確認することによって、患者の来院状況とその患者の医療情報を検討し、それぞれの患者に最適な診療予定を立てることができると共に、必要に応じて患者の来院を促すこともできるため、最適な治療を行うことが可能となり、早期の完治を図ることができる。
【００５１】
また、前記医療詳細情報は、通院予定日の順に前記患者の通院履歴を並べることが可能である。
【００５２】
これにより、通院予定日が近い順に、患者の通院予定日と通院履歴とを確認することができ、確認の必要性の高い患者から来院の要否を検討することができる。
【００５３】
また、前記医療詳細情報は、通院予定日から経過している日数順に前記患者毎に並べることが可能である。
【００５４】
これにより、確認の必要性の高い患者を優先的に確認することができ、効率的に、来院の要否を検討することができる。
【００５５】
また、前記医療詳細情報は、病気毎に並べることが可能である。
【００５６】
これにより、来院の管理を行う必要のある病気にかかる患者について、優先的に検討することができ、効率的に、来院の要否を検討することができる。
【００５７】
さらに、本発明の一実施形態における通院管理プログラムは、制御装置に、医療機関から受信した複数の患者のレセプトデータから、前記患者毎に通院履歴が整理された医療履歴情報および前記医療履歴情報と関連付けられて医療履歴が整理された医療詳細情報を対応する前記医療機関毎に作成させるステップと、前記医療履歴情報を対応する前記医療機関に送信させるステップと、前記医療機関による前記医療履歴情報を介した操作により、前記医療詳細情報を表示させるステップとを実行させることを特徴とする。
【００５８】
このようなプログラムによっても、医師等は、医療履歴情報により患者の通院履歴を確認しながら、さらに、医療詳細情報により患者の医療履歴を確認することによって、患者の来院状況とその患者の医療情報を検討し、それぞれの患者に最適な診療予定を立てることができると共に、必要に応じて患者の来院を促すこともできるため、最適な治療を行うことが可能となり、早期の完治を図ることができる。
【００５９】
前記医療詳細情報は、あらかじめ定めた基準により決定することが可能である。
【００６０】
これにより、状況に応じて最適な医療詳細情報を取得することができ、効率的に、来院の要否を検討することができる。
【００６１】
以上のように、適切な日程で患者が通院するように促すことを補助することができる。
【発明の効果】
【００６２】
本発明によれば、患者の来院状況を客観的な基準で把握可能とする来院管理装置、来院管理プログラム、及び来院管理システムを提供することができる。
【図面の簡単な説明】
【００６３】
【図１】本発明の来院管理装置、及び来院管理システムを示す模式図である。
【図２】図１の機能ブロックを示す図である。
【図３】図１の来院管理装置の周期設定テーブルの一例を示す図である。
【図４】図１の来院管理装置における最終来院日と来院基準日を示す図である。
【図５】図１の来院管理装置の来院周期と超過日数を示す図である。
【図６】図１の来院管理装置の来院状況概要表示の一例を示す図である。
【図７】図１の来院管理装置のリスト表示の一例を示す図である。
【図８】図１の来院管理装置のカテゴリーマップ表示の一例を示す図である。
【図９】図１の来院管理装置の詳細情報表示の一例を示す図である。
【図１０】図１の来院管理装置の患者分布マップ画像の一例を示す図である。
【図１１】図１の来院管理装置の自院流出患者リスト及び自院流入患者リストの一例を示す図である。
【図１２】図１の来院管理装置が実行する来院状況送信処理の一例を示すフロー図である。
【図１３】図１の来院管理装置が実行する来院周期設定処理の一例を示すフロー図である。
【図１４】図１の来院管理装置が実行する競合分析処理の一例を示すフロー図である。
【図１５】本発明の通院管理の概略を示す概念図である。
【図１６】本発明のサーバの構成を例示するブロック図である。
【図１７】レセプトデータに含まれる情報を例示する図である。
【図１８】本発明の第二実施形態に係る来院管理装置の医療履歴情報を例示する図である。
【図１９】本発明の第二実施形態に係る来院管理装置の医療詳細情報を例示する図である。
【図２０】本発明の第二実施形態に係る来院管理装置の医療詳細情報を例示する図である。
【図２１】本発明の第二実施形態に係る通院管理方法の工程を説明するフロー図である。
【図２２】本発明の第三実施形態に係る来院管理装置の医療履歴情報を例示する図である。
【図２３】本発明の第三実施形態に係る来院管理装置の医療詳細情報を例示する図である。
【発明を実施するための形態】
【００６４】
以下、本発明の第一の実施形態に係る来院管理装置３０、及び来院管理システム２００について、図面を参照しつつ詳細に説明する。
【００６５】
来院管理装置３０は、患者の来院状況を把握しようとする医療機関Ｘ（第一の医療機関）に対して、来院状況を把握可能とする各種の情報を医療機関Ｘに提供可能としている。すなわち、来院管理装置３０は、医療機関Ｘに対してサービスを提供する者（サービス提供者）が、来院管理を行うための情報の分析や提供等のサービスを医療機関Ｘに提供するために用いられる。
【００６６】
図１に示すとおり、来院管理システム２００は、少なくとも一のクライアント端末７０と、来院管理装置３０が設けられたサーバ３６とを有している。本実施形態の来院管理システム２００では、クライアント端末７０と、来院管理装置３０とが、インターネット８０を介して接続されている。また、来院管理装置３０は、サーバ３６に設けられている。
【００６７】
なお、以下の説明では、来院管理装置３０をサーバ３６に設けた例を挙げて説明するが、本発明の来院管理システムの来院管理装置は、クライアント端末７０の制御装置に設けられているものであってもよい。また、この場合には、クライアント端末７０はインターネット８０に接続されていないものであってもよい。すなわち、本発明の来院管理装置は、医療機関Ｘ等、サービスを利用する者（サービス利用者）の端末のローカルに設けられるものであり、クライアント端末７０の制御装置７２に来院管理プログラムをインストール等することにより、後述する各種の機能（来院履歴管理機能や競合圏分析機能）を発揮させるものであってもよい。
【００６８】
図１に示すとおり、クライアント端末７０は、例えば医療機関Ｘにおいて用いられている端末装置である。クライアント端末７０は、例えば、パーソナルコンピュータ７０ａ、タブレット型端末、あるいはスマートフォン７０ｂ等の端末装置が用いられる。
【００６９】
なお、本実施形態の来院管理装置３０は、複数の医療機関ＸからレセプトファイルＲｆを受信して、医療機関Ｘごとに、レセプトデータＲｄに含まれる情報を後述する患者データベース４２ａとして構築する。言い方を換えれば、本実施形態の来院管理装置３０は、医療機関Ｘごとに、患者データベース４２ａを構築する。
【００７０】
なお、本発明の来院管理装置は、本実施形態に限定されない。すなわち、本発明の来院管理装置を医療機関のクライアント端末に設けようとする場合には（医療機関のクライアント端末のローカルに設ける場合）、来院管理装置にひとつの患者データベースが構築されるものとしてもよい。
【００７１】
なお、本明細書における「医療機関」とは、診療を行う機関であって、病院、診療所、歯科や内科等の医院、整骨院など、レセプトデータＲｄが用いられる（作成される）各種の機関が含まれる。また、以下の説明では、病院、診療所、整骨院等の医療機関を総称して、単に「医療機関Ｘ」と記載して説明する場合がある。
【００７２】
また、「医療機関の従事者（以下、単に「従事者Ｐ」と記載する場合がある）」とは、医師のほか、医療機関の事務担当者、看護師等、医療機関の業務に従事する者すべてが含まれる。
【００７３】
「レセプト」とは、健康保険組合や市区町村などから医療機関Ｘが診療報酬を受け取ろうとする際に、所定の審査支払機関に診療報酬の請求を行う際の書類（データ）である。レセプトには、患者の氏名や医療機関名、診療の対象となった傷病の名前をはじめ、診療行為の内容、処方した薬などに応じた診療報酬点数などが、１ヶ月分まとめて記載されている。
【００７４】
レセプトは、所定のフォーマットに統一されたフォーマットの電子データとして、所定の審査支払機関に提出される。以下の説明では、レセプトの電子データを「レセプトデータＲｄ」と称して説明する。レセプトデータＲｄは、医療機関Ｘにおいて用いられるレセコン（レセプトコンピュータ）に、診療内容や処方箋の種類などの所定の情報が入力されて生成されるデータである。
【００７５】
図１に示すとおり、本実施形態の来院管理システム２００では、レセプトデータＲｄが加工された所定の形式のファイルに変換して暗号化されて送信される。そのため、レセプトデータＲｄが加工されて所定の形式に変換して暗号化されたファイルを、単に「レセプトファイルＲｆ」と記載して説明する場合がある。なお、本実施形態では、レセプトファイルＲｆには患者の住所や氏名等、個人を特定可能な情報（個人情報）が含まれないものとされているが、「氏名」を含むか否かに関しては任意とされている。レセプトファイルＲｆには、医療機関Ｘにおいて患者を特定可能となる患者ＩＤが含まれる。
【００７６】
なお、本実施形態の来院管理システム２００では、レセプトデータＲｄを加工して所定の形式のファイルに変換した上で送信するものとしたが、本発明の来院管理システムはこれに限定されない。例えば、本発明の来院管理システム及び来院管理装置は、レセプトデータＲｄをそのままのファイル形式として読み込み可能なものとしてもよい。
【００７７】
＜来院管理装置について＞
続いて、来院管理装置３０について詳細に説明する。来院管理装置３０は、患者の来院履歴に関する情報（来院状況）や傷病等の各種の情報を医療機関Ｘのクライアント端末７０に表示させる。来院管理装置３０は、これにより従事者Ｐが患者の来院状況等を容易に把握可能としている。
【００７８】
図１には、来院管理装置３０のハードウエア構成をブロック図として模式的に示している。上述のとおり、来院管理装置３０は、サーバ３６に設けられている。図１に示すとおり、来院管理装置３０は、制御部３２（制御装置）を備えている。また、制御部３２は、ハードウエア構成として、ＲＯＭ３３、ＣＰＵ３４、ＲＡＭ３５、及びＩ／Ｆ（図示を省略）を含み、それぞれがバスを介して接続されている。
【００７９】
このようなハードウエア構成において、ＲＯＭ３３、ＨＤＤ又は光ディスク等の記憶媒体（図示を省略）に格納されたプログラムがＲＡＭ３５に読み出され、ＣＰＵ３４がそれらのプログラムに従って演算を行うことにより、ソフトウエアが構成される。そのような制御部３２とハードウエアとの組みあわせによって、来院管理装置３０を実現する機能ブロック（来院履歴管理部４４及び競合圏分析部４６等）が構成される。
【００８０】
図２は、来院管理装置３０の機能ブロックを示している。図２に示すとおり、来院管理装置３０には、データベース４０、来院履歴管理部４４、競合圏分析部４６、メール送信部４７、及び表示制御部４８が設けられている。
【００８１】
図２に示すとおり、来院履歴管理部４４には、来院周期設定部５０、来院基準日設定部５１、患者カテゴリー設定部５２、来院状況分析部５３、及び来院情報生成部５４が設けられている。
【００８２】
データベース４０には、各種の情報がデータベース化されて蓄積されている。図２に示すとおり、データベース４０には、患者データベース４２ａ、患者属性情報データベース４２ｃ、及び医療機関データベース４２ｂが含まれている。
【００８３】
患者データベース４２ａには、医療機関Ｘから受信したレセプトファイルＲｆのデータがレセプト情報Ｒｉとして蓄積されている。具体的には、患者データベース４２ａには、医療機関Ｘにおいて作成されたレセプトデータＲｄがレセプトファイルＲｆに変換された後、医療機関Ｘのクライアント端末７０からサーバ３６に送信され、当該レセプトファイルＲｆに含まれる情報がレセプト情報Ｒｉとして蓄積されている（図１参照）。言い方を換えれば、患者データベース４２ａは、医療機関Ｘのクライアント端末７０からレセプトファイルＲｆが送信されて来院管理装置３０にアップロードされることに基づいて更新される。患者データベース４２ａには、レセプト情報Ｒｉが患者に紐付けられた情報として構築されている。なお、上述のとおり、患者データベース４２ａは医療機関Ｘごとに構築されている。
【００８４】
レセプト情報Ｒｉには、患者に対して行われた診療行為に関する情報が含まれている。具体的には、レセプト情報Ｒｉには、医療機関Ｘにおいて患者を特定する患者ＩＤや来院日、診療行為の内容を示す情報（診療情報）、処方箋の内容や処方箋日数、傷病名等の情報が含まれている。
【００８５】
患者属性情報データベース４２ｃには、患者ＩＤのほか、患者の年齢、性別、在住場所に関する情報（在住地情報）など、患者の属性を含む情報（患者属性情報）が含まれたデータベースである。本実施形態の来院管理装置３０では、医療機関Ｘから患者属性情報の提供を受け、患者属性情報データベース４２ｃに患者属性情報が蓄積されている。また、患者属性情報データベース４２ｃは、後述する競合圏分析に関するサービスの利用者である医療機関Ｘごとに構築されている。
【００８６】
医療機関データベース４２ｂには、複数の医療機関Ｘの所在地や、診療科目に係る情報など、医療機関Ｘに関する情報がデータベースとして蓄積されている。
【００８７】
来院周期設定部５０は、来院周期Ｃを設定するために設けられている。来院周期Ｃは、患者の仮想的な来院サイクルとして設定された周期である。より具体的に説明すると、来院周期Ｃは、最終来院日から次に来院することが望ましい日までの日数、あるいは最終来院日から次の来院が見込まれる日までの日数を仮想的に示す周期である。別の言い方をすれば、来院周期Ｃは、患者の最終来院日から次に来院すると推測される日までの期間として設定される周期である。
【００８８】
来院管理装置３０は、レセプト情報Ｒｉに基づいて来院周期Ｃを設定可能としている。より具体的には、来院管理装置３０は、来院周期Ｃを、レセプト情報Ｒｉに含まれる最終来院日における診療行為の情報や、処方箋日数に係る情報、あるいは傷病等に基づいて設定する。また、来院管理装置３０は、来院周期Ｃを、レセプト情報Ｒｉに含まれる情報のうち、処方箋日数よりも診療行為を優先して設定する。また、来院管理装置３０は、レセプト情報Ｒｉに基づいて、来院周期Ｃを設定する患者を抽出する。
【００８９】
来院管理装置３０による来院周期Ｃの設定について、例を挙げて説明する。来院周期Ｃは、例えば、図３に一例として示す来院周期決定テーブル等を用いて決定することができる。
【００９０】
図３に示すとおり、来院管理装置３０は、最終来院日の傷病が、例えば風邪やインフルエンザなど、一度の来院で処方される処方箋などで完治可能な傷病である場合には来院周期Ｃを設定しない。具体的には、来院管理装置３０は、最終来院日の傷病が、風邪やインフルエンザなど一時的な傷病である場合には、再度の来院（再来院）を要しない、あるいは見込まない患者を、再診患者以外の非再診患者として、来院周期Ｃを設定しない。
【００９１】
一方、来院管理装置３０は、最終来院日の傷病が、例えば花粉症など、一時的に発症緒する傷病ではあるものの、季節など所定のサイクルで発症するものである場合には、傷病の発症サイクルに沿って（例えば一年など）来院周期Ｃを設定する。
【００９２】
また、来院管理装置３０は、例えば、「高血圧」など、処方箋の処方が主な診療である場合には、処方箋が何日分処方されているか（処方箋日数）に応じて、来院周期Ｃを設定する。例えば、処方箋日数が「７日分」である場合には、来院周期Ｃを「７日間」として設定し、処方箋日数が「１０日分」である場合には、来院周期Ｃを「１０日間」として設定する。また、処方箋日数が処方されていない場合（再来院を要するものの処方箋が処方されていない場合）には、来院周期Ｃを所定の日数（例えば「１ヶ月」）として設定してもよい。
【００９３】
また、来院管理装置３０は、最終来院日の診療行為が、例えば「検査」や「リハビリ」など、処方箋日数に関わらず来院することが見込まれる、あるいは再来院を要する場合には、処方箋が処方されている場合であっても診療行為を優先して来院周期Ｃを設定する。例えば、診療行為として「検査」が行われた場合には、検査結果を伝えるため再診の予約が入っていることが想定されるため、「７日」等検査の結果が出るまでの期間を想定した来院周期Ｃが設定される。また、診療行為が「リハビリ」である場合、傷病の内容などに応じて、例えば「３日」や「７日」など、リハビリを行うに適した日数を来院周期Ｃとして設定する。
【００９４】
このように、来院管理装置３０は、処方箋日数や診療行為の内容に応じて来院周期Ｃを設定する。これにより、来院管理装置３０は、高い精度で患者ごとに適切な来院周期Ｃを設定することができる。
【００９５】
なお、歯科や内科等、診療科目によって、診療が行われる傷病の内容や診療行為の特性が異なる。そのため、来院周期Ｃの設定は、診療科目に応じてどの項目を優先するかといった優先順位が決定されることが望ましい。例えば、ある診療科目では、診療行為の内容等を優先し、その次の優先順位として処方箋日数に基づいて来院周期Ｃが決定されるものとすることができる。また、ある診療科目では、診療行為の内容を最優先項目として、次いで処方箋日数を優先した順位で来院周期Ｃを設定するなど、診療科目に応じて来院周期Ｃが決定されることが望ましい。
【００９６】
来院基準日設定部５１は、来院基準日Ｄｂを設定するために設けられている。来院基準日Ｄｂは、患者が次に来院することが見込まれる日程、あるいは患者が次ぎに来院することが望ましい日程を示すものである。
【００９７】
図４（ａ）に示すとおり、来院基準日Ｄｂは、レセプト情報Ｒｉに含まれる患者の最終来院日Ｄａと、当該患者に対して来院周期設定部５０により設定された来院周期Ｃとに基づいて設定される。具体的には、来院基準日Ｄｂは、最終来院日Ｄａから来院周期Ｃの日数を加算した日程として設定される。例えば、とある患者の最終来院日Ｄａが「８月１日」であり、来院周期設定部５０により来院周期Ｃが「７日間」として設定されている場合には、来院基準日設定部５１は、当該患者の来院基準日Ｄｂを「８月８日」として設定する。なお、設定された来院基準日Ｄｂは、患者の仮想来院日として、別途設けたカレンダーなどに登録されるものとしてもよい。これにより、医療機関Ｘにおいて、患者の来院数をある程度予測することが可能となる。
【００９８】
図４（ａ）に示すとおり、例えば、主な診療行為として処方箋の処方が行われており、継続的に医療機関Ｘに通院している患者Ａでは、処方箋日数のサイクルに沿ってある程度規則的な期間で通院することが考えられる。そのため、来院周期Ｃは患者の仮想的な来院サイクルであり、来院基準日Ｄｂは次に患者が来院すると推測される来院仮想日であると言える。
【００９９】
なお、図４（ｂ）に示すとおり、最終来院日Ｄａから現在までの日数（経過日数Ｎａ）が来院周期Ｃを超えており、現在において来院基準日Ｄｂを経過している場合もあれば、図４（ｂ）に示すように現在において来院基準日Ｄｂを経過していない場合もある。図４（ｂ）に示すとおり、例えば、継続的に医療機関Ｘに通院しているものの来院サイクルが長期となる患者Ｂでは、来院周期Ｃが設定されているものの、現在において来院周期Ｃを経過していない場合がある。
【０１００】
患者カテゴリー設定部５２は、患者のカテゴリー（患者カテゴリー）を決定する。より具体的には、患者カテゴリー設定部５２は、レセプト情報Ｒｉに含まれる最終来院日Ｄａや来院周期Ｃ、あるいは診療行為に基づいて、患者のカテゴリーを決定する。
【０１０１】
患者カテゴリーは、来院基準日Ｄｂを基準として、来院基準日Ｄｂまでに来院があったか否か、また、来院基準日Ｄｂを経過している場合（最終来院日Ｄａから来院周期Ｃを経過している場合）には、来院基準日Ｄｂから超過している日数（超過日数Ｎ）に応じて患者カテゴリーを区分する。例えば、患者が再診を要する（あるいは見込まれる）患者に対しては、「再診患者」として区分される。また、再診患者に対して、「継続患者」、「流出可能性患者」、及び「流出患者」を含む複数の患者カテゴリーに区分する。
【０１０２】
患者カテゴリーについて、図５を参照しつつさらに詳細に説明する。本実施形態の来院管理装置３０では、再診患者を、「周期内患者」、「継続患者」、「超過」、「流出可能性患者」、及び「流出患者」のいずれかに区分可能としている。なお、来院管理装置３０は、来院回数が一回である患者と、来院回数が二回以上である患者とを区分けして、上述の患者カテゴリーに区分する。
【０１０３】
具体的に説明すると、図５に示すとおり、現在において来院基準日Ｄｂが経過していない患者（最終来院日Ｄａから来院周期Ｃを経過していない患者）は、「継続患者」又は「周期内患者」として区分される。すなわち、最終来院日Ｄａから現在までの期間（経過日数Ｎａ）が、来院周期Ｃ以下である場合（Ｎａ≦Ｃの場合）には、周期内又は継続患者として区分される。
【０１０４】
また、図５に示すとおり、現在において来院基準日Ｄｂを経過している場合には、来院基準日Ｄｂから経過した日数（超過日数Ｎｂ）に応じて患者カテゴリーの区分が行われる。
【０１０５】
例えば、図５に示すとおり、現在において来院基準日Ｄｂを経過しており、かつ、第一超過日数Ｎ１をまでの場合（Ｎｂ≦Ｎ１の場合）には、「超過Ａ」として区分される。また、現在において第一超過日数Ｎ１を経過しており、かつ、第二超過日数Ｎ２までの場合（Ｎ１＜Ｎｂ≦Ｎ２の場合）には、「流出可能性」として区分される。さらに、現在において第二超過日数Ｎ２を経過しており、かつ、第三超過日数Ｎ３までの場合（Ｎ２＜Ｎｂ≦Ｎ３の場合）には、「超過Ｂ」として区分される。さらに、現在において第三超過日数Ｎ３を経過している場合（Ｎ３＜Ｎｂの場合）には、「流出」として区分される。言い方を換えれば、来院管理装置３０は、「継続患者」、「超過Ａ」、「流出可能性患者」、「超過Ｂ」、「流出患者」の順に、適切な来院周期内での来院から流出する傾向（適切な来院サイクルから脱落する傾向）のある患者として区分する。
【０１０６】
このように、来院管理装置３０は、患者が流出したか否かの基準として、来院周期Ｃや来院基準日Ｄｂ、あるいは超過日数Ｎを設定した上で、これらの基準に従って患者を段階的に区分可能とされている。これにより、来院管理装置３０は、動向を注視するべき患者を客観的な基準で抽出するとともに、流出患者に至るまでの過程において患者を段階的に区分する。
【０１０７】
これにより、医療機関Ｘの従事者Ｐが、動向を注視するべき患者を把握しやすくなるとともに、患者カテゴリーを参照して優先順位を決めて患者に対する対策を講じることができる。例えば、従事者Ｐが、来院管理装置３０の示す患者カテゴリーのうち、「流出可能性患者」や「超過」であれば完全に流出する前の段階であるとして、これらに区分される患者を優先して来院を促進するなどの対策を講じることができる。このように、来院管理装置３０は、患者がどのような状況（継続して来院しているか、流出する傾向にあるか否かなどの状況）であるかを示す客観的な判断基準を、医療機関Ｘの従事者Ｐに提供することができる。
【０１０８】
来院状況分析部５３は、レセプト情報Ｒｉに含まれる情報の少なくとも一部を集計して分析するなどして、患者の来院状況を分析可能とされている。より具体的に説明すると、来院状況分析部５３は、患者データベース４２ａに蓄積されているレセプト情報Ｒｉに基づいて、各患者カテゴリーに区分される患者が何人いるかといった集計や、前月と比較した患者の増減に関する統計、流出可能性患者あるいは流出患者として判定された患者の人数などの集計を行う。言い換えれば、来院管理装置３０は、継続患者や流出可能性患者等、各患者カテゴリーの増減傾向をデータ化することができる。その結果、従事者Ｐが、患者の定着化が進んでいるか否か、あるいは患者の流出傾向が強くなっているかなど、患者全体の傾向を把握することができる。
【０１０９】
来院情報生成部５４は、クライアント端末７０にメールとして送信するため、あるいはクライアント端末７０の表示装置７６に表示させる情報を送信するための各種の来院管理情報１００を生成する。本実施形態では、来院情報生成部５４は、来院管理情報１００として、来院状況概要情報１０１やリスト情報１０２（来院履歴情報）、カテゴリーマップ情報１０３、あるいは詳細情報１０４などを生成する。
【０１１０】
来院状況概要情報１０１は、クライアント端末７０に対してメールとして送信され、クライアント端末７０において来院状況概要表示１１１として表示される。来院状況表示１１０は、来院状況分析部５３が分析した結果に基づいて表示される来院状況の概要を可視化したものとすることができる。本実施形態では、レセプトファイルＲｆが来院管理装置３０に送信（アップロード）された後の所定のタイミング（例えば毎月予め定められた日など）に、来院状況概要情報１０１をクライアント端末７０に送信する。なお、来院状況概要情報１０１が医療機関Ｘのクライアント端末７０に送信されるタイミングは、適宜設定可能である。また、所定のタイミングまでに（例えば毎月定められた所定の期日までに）医療機関ＸからレセプトファイルＲｆのアップロードがなかった場合に、アップロードを促すメールなどを送信可能としてもよい。
【０１１１】
例えば、図６に一例として示すとおり、来院状況概要表示１１１には、当月の新規患者の人数や、流出可能性患者の人数、あるいはすべての患者のカテゴリーの内訳や流出可能性患者などの人数の推移等を含むものとすることができる。
【０１１２】
リスト情報１０２（来院履歴情報）は、来院状況概要情報１０１を含むメールに添付されてクライアント端末７０に送信される情報である。リスト情報１０２は、クライアント端末７０においてリスト表示１１２として表示される。
【０１１３】
図７に一例として示すとおり、リスト表示１１２は、例えば流出可能性患者を抽出して一覧とし、患者を識別可能なＩＤや、患者の来院状況を視認することができるものとすることができる。具体例を挙げて説明すると、図７に示すとおり、リスト表示１１２は、患者ＩＤと、患者ごとの来院履歴が一覧として表示されるものとすることができる。また、リスト表示１１２は、例えば図７に示すとおり、患者が来院した月に丸印を示し、患者が来院した月と来院していない月とを一目で視認可能なものとしてもよい（来院した月を表示する枠内と来院していない月を表示する枠内とを別の色で表示するなど）。また、リスト表示１１２は、傷病名でのソートや、超過日数Ｎに応じて並べ替え可能なものとしてもよい。
【０１１４】
カテゴリーマップ情報１０３は、クライアント端末７０にカテゴリーマップ表示１１３として表示される。カテゴリーマップ表示１１３は、各患者カテゴリーに区分される患者の人数を可視化して表示させるものである。本実施形態の来院管理装置３０は、カテゴリーマップ情報１０３を、患者カテゴリーごとの患者数を示すともに、カテゴリーの推移をイメージ化したカテゴリーマップ表示１１３として表示させる。
【０１１５】
カテゴリーマップ表示１１３は、例えば図８に示すように、患者カテゴリー区分と当該患者カテゴリーに区分される患者の人数などを表示させ、超過日数の加算に応じて、流出患者に至る過程にある患者がどれぐらいいるのかを視覚化したもの（カテゴリーマップ表示１１３）とすることができる。
【０１１６】
本実施形態のカテゴリーマップ表示１１３は、クライアント端末７０に表示されたカテゴリーマップ表示１１３の人数が表示されている人数表示ボタン１１３ａを、従事者Ｐがクリックするなどの操作を行うことにより、クリックされた人数表示ボタン１１３ａに係る患者カテゴリーの一覧が表示される。例えば、図８に示すカテゴリーマップ表示１１３の「流出可能性患者（２回以上来院）」に係る人数表示ボタン１１３ａ（１００人を示す「１００」の文字が表示されたボタン）をクリックすると、「流出可能性患者（２回以上来院）」に区分される患者のリストが表示される。
【０１１７】
カテゴリーごとに表示可能とされる患者リストは、例えば、図５に示したリスト情報１０２を用いてもよいし、他のリストを別に生成可能としてもよい。
【０１１８】
これにより、来院管理装置３０は、患者全体の来院状況や流出の可能性がある患者のボリュームを把握するとともに、各カテゴリーに区分される患者の傾向（緊急性の高い患者であるかなど）を把握することができる。また、このように来院管理装置３０は、流出患者に至る過程を段階的に区分して表示させるため、従事者Ｐが緊急性や重要性を判断する指標とすることができる。別の観点から説明すると、来院管理装置３０によれば、通院するか否かの判断を患者任せにせず、医療機関Ｘにおいてある程度管理することができる。その結果、来院管理装置３０は、患者の傷病の早期治療に貢献することが期待される。
【０１１９】
詳細情報１０４は、詳細情報表示１１４としてクライアント端末７０に表示される。詳細情報１０４は、例えば医療機関Ｘのクライアント端末７０から来院管理装置３０にアクセスしてログインするなどの操作により、クライアント端末７０に表示可能なものとすることができる。言い方を換えれば、詳細情報１０４は、患者データベース４２ａの内容をクライアント端末７０の表示装置７６に表示させるための情報とすることができる。
【０１２０】
図９に一例として示すとおり、詳細情報表示１１４は、例えば、患者ＩＤなど医療機関Ｘにおいて患者を識別可能なリストとして表示可能とするとともに、患者ごとの来院履歴や医療行為の履歴、処方箋の履歴など、レセプト情報Ｒｉに含まれる情報を患者ごとに網羅的に表示可能なものとすることができる。これにより、医療機関Ｘの従事者Ｐが、流出可能性患者など、患者ごとに診療内容や傷病の内容を確認して緊急性などを判断し、当該患者に対して来院を促す連絡を行うか否かなど、最終的に判断することができる。
【０１２１】
メール送信部４７（情報送信部）は、来院管理情報１００の少なくとも一部を医療機関Ｘのクライアント端末７０に送信するために設けられている。本実施形態の来院管理装置３０は、来院状況概要情報１０１やリスト情報１０２を、インターネット８０を介して医療機関Ｘのクライアント端末７０に送信する。
【０１２２】
表示制御部４８は、上述した詳細情報１０４やカテゴリーマップ情報１０３を、詳細情報表示１１４やカテゴリーマップ表示１１３として表示させる情報を送信するために設けられている。表示制御部４８からクライアント端末７０に対して各種の情報が送信され、クライアント端末７０（パーソナルコンピュータ７０ａやスマートフォン７０ｂ等）のブラウザを介して、各種情報に係る表示が表示される。
【０１２３】
＜競合圏分析機能＞
続いて、来院管理装置３０が実現する競合圏分析機能について説明する。
【０１２４】
来院管理装置３０は、医療機関Ｘ（第一の医療機関）が自院に来院する患者のうち、当該医療機関Ｘの近隣にある一又は複数の他の医療機関Ｘ（競合医療機関Ｘｃ）の診療圏内に在住する患者の動向を把握して、自院のマーケティング活動の指標とするためのものである。言い方を換えれば、来院管理装置３０は、医療機関Ｘがマーケティング的な視点で自院の患者の動向を看視することで、医療機関Ｘが客観的な観点で自院の強みや弱みを把握するために用いることができる。
【０１２５】
なお、以下の説明では、来院管理装置３０により患者の動向を把握しようとする医療機関Ｘを、単に「自医療機関Ｘａ」（第一の医療機関）と記載して説明する場合がある。すなわち、本明細書における「自院」や「自医療機関」の文言は、来院管理装置３０や来院管理システム２００のユーザーを意味する。
【０１２６】
また、自医療機関Ｘａ以外の医療機関Ｘを、単に「他医療機関Ｘｂ」と記載して説明する場合がある。さらに、他医療機関Ｘｂのうち、自医療機関Ｘａから所定の範囲内（近隣）にある医療機関Ｘを、「競合医療機関Ｘｃ」と記載して説明する場合がある。
【０１２７】
すなわち、本明細書の記載において、「競合医療機関Ｘｃ」とは、自医療機関Ｘａ以外の医療機関Ｘのうち、近隣にある医療機関Ｘ全般を意味する。言い方を換えれば、本明細書中の「競合医療機関Ｘｃ」とは、自医療機関Ｘａと診療科目が共通するか、医療機関Ｘとしての態様（病院であるか、診療所であるかといった態様）が同じあるいは類似するか否かといった、自医療機関Ｘａと実際の競合関係にあるか否かは問わない。
【０１２８】
競合圏分析部４６には、競合医療機関設定部５５、診療圏設定部５６、自院患者カテゴリー設定部５７、及び競合圏分析情報生成部５８が設けられている。
【０１２９】
競合医療機関設定部５５は、競合医療機関Ｘｃを設定する。具体的には、医療機関データベース４２ｂに登録されている医療機関Ｘの中から、自医療機関Ｘａの所在地から所定の範囲内にある一又は複数の他医療機関Ｘｂを抽出し、「競合医療機関Ｘｃ」として設定する。すなわち、本明細書において、競合医療機関Ｘｃは、ひとつである場合や複数である場合が含まれる。
【０１３０】
なお、自医療機関Ｘａからどの範囲内にある他医療機関Ｘｂを「競合医療機関Ｘｃ」として設定するかは、自医療機関Ｘａからの離間距離として選択可能な範囲を複数設けて自医療機関Ｘａの従事者Ｐが選択可能としてもよい。また、競合医療機関Ｘｃは、自医療機関Ｘａから所定の範囲内にある他医療機関Ｘｂを複数抽出して、さらに診療科目や規模などにより抽出して設定可能としてもよい。
【０１３１】
診療圏設定部５６は、自医療機関Ｘａや競合医療機関Ｘｃの診療圏Ｒを設定する。具体的には、診療圏設定部５６は、上述の競合医療機関設定部５５により設定された競合医療機関Ｘｃから、所定の範囲を「競合診療圏Ｒｃ」として設定する。また、診療圏設定部５６は、自医療機関Ｘａから所定の範囲を「自院診療圏Ｒａ」として設定する。
【０１３２】
なお、診療圏Ｒは、複数の選択肢の中から選択可能なものとしてもよい。また、診療圏Ｒは、少なくとも競合医療機関Ｘｃ（競合診療圏Ｒｃ）を設定するものとすれば、自医療機関Ｘａの診療圏Ｒを設定しないものとしてもよい。さらに、診療圏Ｒは、複数の選択肢が設けられるものであってもよい。例えば、診療圏Ｒは、「３００ｍ」、「５００ｍ」、「１ｋ」など、複数の距離を選択肢として提示可能として、医療機関Ｘの従事者Ｐの操作により選択されるものであってもよい（図１０参照）。
【０１３３】
自院患者カテゴリー設定部５７では、自医療機関Ｘａの少なくとも一部の患者が複数のカテゴリーに区分される。より具体的に説明すると、本実施形態の来院管理装置３０では、自医療機関Ｘａの患者のうち、競合診療圏Ｒｃの範囲内に在住する患者を「競合圏内患者」として抽出する。言い方を換えれば、来院管理装置３０は、競合医療機関Ｘｃの所在地と自院の患者の在住地との位置関係により、競合圏内患者を抽出する。また、来院管理装置３０は、競合圏内患者として区分された患者のうち少なくとも一部の患者を、自医療機関Ｘａへの来院状況に応じて、「自院流入患者」や「自院流出患者」として区分する。
【０１３４】
自院流入患者であるか自院流出患者であるかの判定は、来院管理装置３０の来院履歴機能によるものとしてもよい。具体的には、競合圏内患者のうち、来院履歴管理部４４の患者カテゴリー設定部５２により「継続患者」として区分される患者を「自院流入患者」と設定し、「流出可能患者」あるいは「流出患者」を「自院流出患者」として設定してもよい。
【０１３５】
なお、自院流出患者であるいか否かの判定は、競合圏内患者の中から決定されるものとしてもよいし、競合圏内患者であるか否かに関わらず、自医療機関Ｘａの患者のうち最終来院日からある一定の期間を徒過した患者を自院流出患者として判定されるものであってもよい。
【０１３６】
自院流入患者は、競合診療圏Ｒｃ内に在住する患者であり、自医療機関Ｘａにある程度継続して来院している患者である。すなわち、自院流入患者は、競合医療機関Ｘｃへの通院よりも自医療機関Ｘａへの通院を選択した患者であると推測することができる。そのため、複数の自院流入患者の属性（性別や年齢、在住地）や傷病内容等の傾向を把握することで、競合医療機関Ｘｃと比較した場合の自医療機関Ｘａの強み、あるいは競合医療機関Ｘｃの弱みを推測することができる。
【０１３７】
自院流出患者は、自医療機関Ｘａにある程度継続して来院している患者である。すなわち、自院流入患者は、競合医療機関Ｘｃへの通院よりも自医療機関Ｘａへの通院を選択した患者であると推測することができる。そのため、複数の自院流入患者の属性（性別や年齢、在住地）や傷病内容等の傾向を把握することで、競合医療機関Ｘｃと比較した場合の自医療機関Ｘａの強み、あるいは競合医療機関Ｘｃの弱みを推測することができる。
【０１３８】
競合圏分析情報生成部５８は、クライアント端末７０に表示させるための各種の情報を生成する。
【０１３９】
具体的には、競合圏分析情報生成部５８は、自医療機関Ｘａの患者の分布や競合医療機関Ｘｃ、競合診療圏Ｒｃ等を地図上に表示させる患者分布マップ情報１０６を生成する。患者分布マップ情報１０６は、自医療機関Ｘａのクライアント端末７０に、ブラウザを介して患者分布マップ表示１１６として表示される。
【０１４０】
図１０に一例として示すとおり、患者分布マップ表示１１６には、自院に来院する患者の在住地（位置情報）が患者アイコン１１６ａとして表示される。また、患者分布マップ表示１１６には、患者アイコン１１６ａのうち、自院流出患者と判定された患者の在住地が自院流出患者アイコン１１６ｂとして、自院流入患者と判定された患者の在住地が自院流入患者アイコン１１６ｃとして印付けとして表示される。
【０１４１】
さらに、患者分布マップ表示１１６には、自院診療圏内Ｒａや競合診療圏内Ｒｃの範囲が示される。来院管理装置３０は、このように地図上に患者の分布や、競合診療圏Ｒｃや自医療機関Ｘａの位置を一元的に表示させることで、医療機関Ｘの従事者Ｐが流入患者や流出患者がどれぐらいのボリュームで存在するのか、また競合診療圏Ｒｃにどれぐらいの流入患者や流出患者が存在するのかといったことを把握可能となる。また、明らかに自院よりも競合医療機関Ｘｃに近い場所に在住しているにも関わらず、自院に継続して来院する患者の属性等を把握することで、自院の強みを推測することができる。
【０１４２】
また、患者分布マップ表示１１６に表示される自院流出患者アイコン１１６ｂや自院流入患者アイコン１１６ｃを、従事者Ｐがクリックするなどの操作を行うと、患者属性情報データベース４２ｃに含まれる当該患者の属性や、患者データベース４２ａに含まれる傷病等が表示されるものとしてもよい。このような構成とすることで、特定の患者の属性等を確認することができる。
【０１４３】
なお、患者分布マップ表示１１６には、自院流出患者の一覧（自院流出患者リスト１０７）や自院流入患者の一覧（自院流入患者リスト１０８）を表示可能としてもよい。例えば、図１０に示すとおり、患者分布マップ表示１１６に、リスト表示ボタン１１６ｄを設けて、従事者Ｐがリスト表示ボタン１１６ｄをクリックするなどの操作に基づき、これらのリストが表示されるものとしてもよい。また、自院流出患者リスト１０７や自院流入患者リスト１０８等は、患者分布マップ表示１１６にあらかじめ表示されているものとしてもよい。
【０１４４】
また、自院流出患者リスト１０７や、自院流入患者リスト１０８に係る情報を生成してクライアント端末７０にブラウザを介して表示させる場合、これらのリストを、年齢や性別、傷病、流入あるいは流出したと推測される競合医療機関Ｘｃによりソート可能としたり、並べ替え可能としたりしてもよい。これにより、従事者Ｐが、自院流入患者や自院流出患者の傾向を把握しやすくなり、自院の強みや弱みの把握、あるいは競合医療機関Ｘｃの強みや弱みを推測することが容易となる。その結果、来院管理装置３０は、自医療機関Ｘａの強みを生かしたマーケティング活動を行う指標とすることができる。
【０１４５】
＜来院管理プログラムが実行するステップについて＞
次に、来院管理プログラムが来院管理装置３０に実行させる来院周期設定処理（来院周期設定ステップ）、及び競合圏内患者抽出処理（競合圏内患者抽出ステップ）等の処理について、図１２〜図１４を参照しつつ説明する。
【０１４６】
＜来院履歴情報更新処理＞
図１２は、来院管理装置３０が実行する来院履歴情報更新処理を示している。なお、来院履歴情報更新処理は、医療機関Ｘのクライアント端末７０からレセプトファイルＲｆを受信することに基づいて行われる。
【０１４７】
（ステップＳ１０）
ステップＳ１０において、来院管理装置３０は、患者データベース４２ａを更新する処理を行う。具体的には、来院管理装置３０は、レセプトファイルＲｆに含まれるレセプト情報Ｒｉを患者ごとに紐付けられた情報として格納し、患者データベース４２ａを更新する処理を行う。ステップＳ１０の処理が終了すると、ステップＳ１１に処理が移行される。
【０１４８】
（ステップＳ１１）
ステップＳ１１において、来院管理装置３０は、後で図１３を用いて説明する来院周期設定処理を行う。ステップＳ１１の処理が終了すると、ステップＳ１２に処理が移行される。
【０１４９】
（ステップＳ１２）
ステップＳ１２において、来院管理装置３０は、来院基準日Ｄｂを設定する処理を行う。具体的には、来院管理装置３０は、患者データベース４２ａに蓄積されている情報（レセプト情報Ｒｉ）に基づいて、患者ごとに最終来院日Ｄａを抽出し、最終来院日ＤａにステップＳ２の処理で設定された来院周期Ｃの日数を加算した日を、来院基準日Ｄｂとして設定する。なお、来院基準日Ｄｂは、来院周期Ｃが設定されている患者（再診患者）に対して設定され、来院周期Ｃが設定されていない患者に対しては設定が行われない。ステップ１２の処理が終了すると、ステップＳ１３に処理が移行される。
【０１５０】
（ステップＳ１３）
ステップＳ１３において、来院管理装置３０は、患者カテゴリー設定処理を行う。当該処理において、来院管理装置３０は、患者ごとに、最終来院日Ｄａから現在までの経過日数Ｎａや来院基準日Ｄｂからの超過日数Ｎに基づいて、「継続患者」や「流出可能性患者」等、区分する患者カテゴリーを決定する。ステップＳ１３の処理が終了すると、ステップＳ１４に処理が移行される。
【０１５１】
（ステップＳ１４）
ステップＳ１４において、来院管理装置３０は、来院情報生成処理を行う。当該処理において、来院管理装置３０は、来院状況概要情報、カテゴリーマップ情報、詳細情報等の各情報を生成する処理を行う。ステップＳ１４の処理が終了すると、ステップＳ１５に処理が移行される。
【０１５２】
（ステップＳ１５）
ステップＳ１５において、来院管理装置３０は、ステップＳ１４において生成された情報のうち、来院状況概要情報等の情報を、医療機関Ｘのクライアント端末７０に送信する処理を行う。ステップＳ１５の処理が終了すると、来院履歴情報更新処理を終了する。
【０１５３】
＜来院周期設定処理＞
次に、図１３に基づいて、来院管理装置３０が実行する来院周期設定処理について説明する。なお、患者カテゴリー設定処理は、患者データベース４２ａに含まれる患者ごとに行われる。
【０１５４】
（ステップＳ１１−１）
ステップＳ１１−１において、来院管理装置３０は、再診患者であるか否かについて判定する。具体的には、来院管理装置３０は、レセプト情報Ｒｉに含まれる診療内容や傷病等の情報等に基づいて、再来院を要する患者（再診患者）であるか否かを判定する。なお、再診患者であるか否かの判定は、レセプト情報Ｒｉと図３に示す来院周期決定テーブルとを参照して判定されるものであってもよい。再診患者であると判定された場合（ステップＳ１１−１＝ＹＥＳ）にはステップＳ１１−２に処理が移行され、要再診患者ではないと判定された場合（ステップＳ１１−１＝ＮＯ）には来院周期設定処理の処理を終了し、来院履歴情報更新処理のステップＳ１２に処理を移行する。すなわち、来院管理装置３０は、再診患者ではない場合には、来院周期Ｃを設定しない。
【０１５５】
（ステップＳ１１−２）
ステップＳ１１−２において、来院管理装置３０は、特定の診療行為であるか否かについて判定する。具体的には、来院管理装置３０は、レセプト情報Ｒｉに含まれる診療行為の内容や傷病等の情報に基づいて、リハビリや検査等、特定の診療行為であるか否かを判定する。特定の診療行為であると判定された場合（ステップＳ１１−２＝ＹＥＳ）にはステップＳ１１−３に処理が移行され、特定の診療行為ではないと判定された場合（ステップＳ１１−２＝ＮＯ）にはステップＳ１１−４に処理が移行される。
【０１５６】
（ステップＳ１１−３）
ステップＳ１１−３において、来院管理装置３０は、来院周期を設定する処理を行う。具体的には、レセプト情報Ｒｉと図３に示す来院周期決定テーブルとに基づいて、患者ごとに来院周期Ｃを設定する処理を行う。ステップＳ１１−３の処理が終了すると、来院周期設定処理の処理を終了し、来院履歴情報更新処理のステップＳ１２に処理を移行する。
【０１５７】
（ステップＳ１１−４）
ステップＳ１１−４において、来院管理装置３０は、処方箋が処方されているか否かについて判定する。具体的には、来院管理装置３０は、レセプト情報Ｒｉに含まれる処方箋の情報に基づいて、処方箋が処方されているか否かを判定する。処方箋が処方されていると判定された場合（ステップＳ１１−４＝ＹＥＳ）にはステップＳ１１−５に処理が移行され、処方箋が処方されていないと判定された場合（ステップＳ１１−４＝ＮＯ）にはステップＳ１１−６に処理が移行される。
【０１５８】
（ステップＳ１１−５）
ステップＳ１１−５において、来院管理装置３０は、来院周期を設定する処理を行う。具体的には、レセプト情報Ｒｉに含まれる処方箋日数に基づいて、患者ごとに来院周期Ｃを設定する処理を行う。ステップＳ１１−５の処理が終了すると、来院周期設定処理の処理を終了し、来院履歴情報更新処理のステップＳ１２に処理を移行する。
【０１５９】
（ステップＳ１１−６）
ステップＳ１１−６において、来院管理装置３０は、来院周期を設定する処理を行う。具体的には、来院管理装置３０は、１ヶ月の来院周期Ｃを設定する処理を行う。ステップＳ１１−６の処理が終了すると、来院周期設定処理の処理を終了し、来院履歴情報更新処理のステップＳ１２に処理を移行する。
【０１６０】
＜競合圏内患者抽出処理＞
次に、図１４に基づいて、来院管理装置３０が実行する競合圏内患者抽出処理について説明する。なお、競合圏内患者抽出処理は、患者データベース４２ａに含まれる患者ごとに行われる。
【０１６１】
（ステップＳ２０）
ステップＳ２０において、来院管理装置３０は、競合医療機関Ｘｃを設定する。具体的には、来院管理装置３０は、自医療機関Ｘａの所在地と、医療機関データベース４２ｂとに基づいて、他医療機関Ｘｂの中で自医療機関Ｘａから所定の範囲内に所在する医療機関Ｘを競合医療機関Ｘｃとして設定する。ステップＳ２０の処理が終了すると、ステップＳ２１に処理が移行される。
【０１６２】
（ステップＳ２１）
ステップＳ２１において、来院管理装置３０は、競合診療圏Ｒｃを設定する。具体的には、来院管理装置３０は、ステップＳ２０の処理で設定された競合医療機関Ｘｃから所定の範囲内を競合診療圏Ｒｃとして設定する。ステップＳ２１の処理が終了すると、ステップＳ２２に処理が移行される。
【０１６３】
（ステップＳ２２）
ステップＳ２２において、来院管理装置３０は、競合圏内患者を抽出する。具体的には、来院管理装置３０は、患者データベース４２ａに含まれる患者のうち、ステップＳ２１の処理で設定された競合診療圏Ｒｃ内に在住する患者を競合圏内患者として設定する。ステップＳ２２の処理が終了すると、来院管理装置３０は競合圏内患者抽出処理の一連の処理を終了する。
【０１６４】
以上、本発明の第一実施形態に係る来院管理装置３０、来院管理システム２００、及び来院管理プログラムについて説明したが、本発明は上述の実施形態に限定されない。
【０１６５】
例えば、上述の実施形態に係る来院管理装置３０では、来院履歴管理機能及び競合圏分析機能の双方の機能を発揮可能なものとした例を示したが、本発明の来院管理装置は、来院履歴管理機能及び競合圏分析機能のいずれか一方の機能を発揮するものであってもよい。
【０１６６】
また、上述の実施形態に係る来院管理装置３０では、競合圏分析機能において、競合圏内患者を流出する傾向にある患者（自院流出患者）であるか、定着する傾向にある患者（自院流入患者）であるかを判定可能とした例を示したが、本発明の来院管理装置はこれに限定されない。すなわち、本発明の来院管理装置は、適切な来院周期内での来院から流出する傾向にあるか適切な来院周期内での来院が定着する傾向にあるかの判定を行わず競合圏内患者を抽出可能としてもよい。
【０１６７】
続いて、図１５を用いて、本発明の第二実施形態に係る通院管理装置（来院管理装置）および通院管理プログラム（来院管理プログラム）、及び通院管理方法の概略について説明する。
【０１６８】
図１５は本発明の来院管理の概略を示す概念図である。
【０１６９】
図１５に示すように、サーバ１は、ネットワーク３を介して複数の医療機関２と接続され、サーバ１と各医療機関２とは、ネットワーク３を介してデータ通信が可能である。
【０１７０】
各医療機関２は、レセプトの情報であるレセプトデータ４を、ネットワーク３を介してサーバ１に送信する。
【０１７１】
サーバ１は、受信したレセプトデータ４に含まれるデータを元に、医療機関２毎の医療履歴情報５と医療詳細情報６とを生成する。また、生成された医療履歴情報５は、対応する各医療機関２にメール等の手段により、ネットワーク３を介してサーバ１から送信される。
【０１７２】
レセプトは各医療機関２により、毎月作成され、所定の公的機関に提出される。レセプトには、通院患者毎に、患者の個人情報や、病名、診療内容等の医療履歴が記載される。レセプトデータ４は、このようなレセプトの情報をまとめたデータであり、公的機関に提出するために、レセプトの情報を一定のフォーマットに統一されたデータである。
【０１７３】
医療履歴情報５および医療詳細情報６は、受信したレセプトデータ４を元にサーバ１にて情報を整理して作成される。医療履歴情報５（来院履歴情報）は、医療機関２毎に生成された、患者の通院状況等の通院履歴が患者毎に整理された情報である。医療詳細情報６は、医療機関２毎に生成され、通院履歴に加え、各患者の個人情報や、病名、診療内容等の医療履歴が詳細に整理された情報である。医療詳細情報６は、同一の医療機関２の医療履歴情報５と関連付けられてリンクしており、サーバ１内に保存されている。後に詳述するように、医療機関２の医師等は、受け取った医療履歴情報５を解析し、さらに、医療履歴情報５を介してサーバ１内の医療詳細情報６の内容を閲覧して、より詳細に患者の通院状況を解析することができる。
【０１７４】
以上のように、各医療機関２は、特別なデータの作成や、入力処理を行うことなく、後に詳述するように、通常の業務において作成されるレセプトデータ４をサーバ１に送信するのみで、医療履歴情報５等を作成するためのデータをサーバ１に提供することができる。一般的に、サーバ１等にデータの整理をさせるような装置においては、サーバが処理できるようなフォーマットでデータを別途作成し入力する必要があった。これに対して本発明においては、サーバ１は、通常の業務において作成されるレセプトデータ４を解読・解析・整理できるように構成され、これにより、余分な処理を行うことなく、サーバ１にデータを入力することが可能となる。
【０１７５】
また、各医療機関２は、患者毎に患者の通院状況等が整理された医療履歴情報５を、メール等により、医療機関２からはいかなる処理を行うことなく、自動的かつ定期的にサーバ１から受信することができる。一般的に、サーバ１等にデータの整理をさせるような装置においては、医療機関２の医師等の使用者が、サーバにアクセスし、サーバで生成した各種情報を取得あるいは閲覧する必要があった。これに対して本発明においては、医療履歴情報５が定期的にサーバ１から送信されるため、医療機関２の医師等の手間がかからず、医療履歴情報５の取得忘れ等が発生する恐れがない。また、患者の適切な治療予定を立てるのに最低限必要な、患者の通院状況等の情報を定期的に入手できるため、定期的に送信される医療履歴情報５のみからだけでも、ある程度の患者の治療予定を立てることができる。さらに、後に詳述するように、送信された医療履歴情報５とサーバ１内の医療詳細情報６とはリンクしており、医療機関２の医師等は医療履歴情報５を操作することによりサーバ１内の医療詳細情報６を閲覧することができ、患者のより詳細な情報や、レセプトデータ４を詳細に解析した情報等を確認し、各患者の状況を詳しく確認して、容易に患者の最適な治療予定を立てることができる。
【０１７６】
また、以上のように、必要な情報を簡単に入力すると共に、解析結果を自動的に入手しながら、患者の治療予定を容易に立てるのみならず、後に詳述するように、医療機関２と各患者の所在地との位置関係等から、患者を獲得するマーケティング活動（以下、集患とも称す）を行うことも可能である。
【０１７７】
（第二実施形態）
次に、本発明の第二実施形態に係る通院管理方法、通院管理装置（来院管理装置）および通院管理プログラム（来院管理プログラム）に係る具体例について、図１５〜図２１を用いて詳細に説明する。
【０１７８】
まず、図１６〜図２０を用いて、第二実施形態に係る通院管理装置（来院管理装置）におけるサーバの構成について説明する。図１６は本発明の通院管理装置が設けられるサーバの構成を例示するブロック図であり、データの流れが明確になるように示している。図１７はレセプトデータに含まれる情報を例示する図、図１８は第二実施形態に係る医療履歴情報を例示する図、図１９，２０は第二実施形態に係る医療詳細情報を例示する図である。
【０１７９】
図１６に示すように、サーバ１は、ＣＰＵ７等の情報処理装置と、メモリ８等の記憶装置と、ネットワーク３（図１５参照）と接続されてデータの送受信を行う送受信器９と、ネットワーク３（図１５参照）と接続されて、ネットワーク３（図１５参照）上の他の機器等のブラウザ等にブラウザ等を制御するデータを送信し、情報を表示させる表示制御装置１０と、ＣＰＵ７を動作させるプログラム１１とから構成される。
【０１８０】
サーバ１において、レセプトデータ４は各医療機関２（図１５参照）から送受信器９を介して受信され、メモリ８に記憶される。医療履歴情報５および医療詳細情報６は、ＣＰＵ７がそれぞれのレセプトデータ４を読み込み、解読・整理・解析することによって、医療機関２（図１５参照）毎に生成される。生成された医療履歴情報５および医療詳細情報６はメモリ８に記憶される。送受信器９は、各医療機関２（図１５参照）からレセプトデータ４を受信し、対応する医療機関２に医療履歴情報５を送信する。また、送受信器９は、各医療機関２（図１５参照）において、医療履歴情報５を介した操作に係る情報を受信する。受信された情報に基づいて、ＣＰＵ７は医療詳細情報６にアクセスし、表示制御装置１０から、医療履歴情報５を介した操作に対応する情報を、対応する医療機関２（図１５参照）に送信し、医療機関２のブラウザ等に操作に対応するデータを表示させる。プログラム１１は、ＣＰＵ７にサーバ１の動作をさせるプログラムであり、ＲＯＭ等の記憶装置（図示せず）に格納されても良いし、メモリ８に格納されても良い。
【０１８１】
なお、図１６の例では、サーバ１が各医療機関２（図１５参照）との間で、レセプトデータ４や医療履歴情報５の送受信、医療履歴情報５を介した操作に係る情報を受信、その操作に対応する情報の送信等の送受信を行うと共に、レセプトデータ４の整理・解析および医療履歴情報５および医療詳細情報６の生成を行う構成としたが、データの送受信に係るデータ通信構成と、レセプトデータ４の整理・解析および医療履歴情報５および医療詳細情報６の生成を行うデータ処理構成とを分けた構成とすることもできる。この場合、データ通信構成とデータ処理構成とがデータ通信可能な状態で接続されていれば良い。また、送受信器９と表示制御装置１０とを別々に構成する例を示したが、送受信器９に、ネットワーク３（図１５参照）上の他の機器等に設けられたブラウザ等を制御するデータを送信する機能を付与しても良い。
【０１８２】
レセプトデータ４（図１５参照）は、例えば、図１７に示すように、対応する医療機関２（図１５参照）毎に、通院した患者名と患者の個人情報、診療履歴等が患者毎の情報として記載されている。具体的には、レセプトデータ４（図１５参照）には、患者の個人情報として、保険者番号、生年月日、年齢、性別、住所が含まれる。また、診療履歴として、来院日等の通院履歴と、来院日における診療区分、診断された病名、診療内容、薬が処方された場合には、処方された薬の名称と処方された日数等の医療履歴が含まれる。
【０１８３】
例えば、図１７の例では、「鈴〇二郎」の住所等の個人情報と、診療履歴として、平成２９年８月１日、平成２９年８月４日、平成２９年８月８日に来院し、いずれも、腎不全と診断されて人工透析が施された旨がレセプトデータ４（図１５参照）の内容として含まれる。
【０１８４】
なお、図１７は、レセプトデータ４（図１５参照）に記載されている情報を整理した表である。なお、レセプトデータ４（図１５参照）はこのような表の形式に限らず、情報が分かりやすく整理されていれば任意の形式である。一般的にレセプトデータ４（図１５参照）はＣＳＶ形式の一定のフォーマットで作成し、所定の機関に提出される。そのため、サーバ１に送信するデータをこの形式とすれば、所定の機関に提出するレセプトデータ４（図１５参照）を流用し、別途送信用のデータを作る必要がなく便利である。
【０１８５】
医療履歴情報５は、レセプトデータ４（図１５参照）をサーバ１（図１５参照）に送信することにより、対応する各医療機関２（図１５参照）にメール等により送信される、レセプトデータ４（図１５参照）の内容を整理した情報である。医療履歴情報５は、患者毎に、該当月においていつ来院したかが分かる情報である。具体的には、図４に例示するように、横軸に日付、縦軸に患者名を記載した表であり、表における各患者の行（横軸）の来院した日付の部分に来院したことが分かる印として、例えば星印を記載する。図１８の例において、「鈴〇二郎」は、１日，４日，８日に来院し、「●田太郎」は、３日，７日に来院し、「山〇花子」は、４日に来院し、「佐藤△子」は、４日，１１日，１８日に来院したこと等が分かる。
【０１８６】
このように、患者の通院履歴が明確となるため、医療履歴情報５を受信した医療機関２（図１５参照）の医師等は、来院の日程、来院間隔を、患者毎に容易に把握することができ、患者に合った通院予定を的確かつ容易に検討し、決定することができる。また、このような医療履歴情報５を、医師等はメール等により、定期的にかつ自動的に受け取ることができる。このような整理した情報を提供するシステムがあったとしても、通常は、医師自らシステムにアクセスし、整理した情報を閲覧する必要があった。しかしながら、通常医師は多忙であり、来院する患者を診療することに重点をおいており、通院時に、次回以降の診察予定を考慮することがあったとしても、予定通り来院したかどうかを確認し、来院しなかった患者に対して来院を促す等の対処を行うことは困難であり、あえて、システムにアクセスして患者の来院状況を確認し、対処することまでを行わないことが一般的であった。これに対して、患者の通院履歴が明確となる医療履歴情報５を、メール等により直接的に受け取ることにより、医師等は、患者毎の通院履歴を確認し、来院の有無の確認を行い、治療の計画をたてるきっかけとすることができるようになる。結果として、患者の通院を医師が管理して、最適な日程で通院することを促すことが可能となり、的確な治療を施すことができ、最善の治療を行うことが可能となり、早期かつ的確に病気等を完治することが望めるようになる。
【０１８７】
また、通院履歴から通院予定日を予測し、通院予定日に来院していない場合は、その日に印をつけても良い。図１８の例では、１７日に送信された医療履歴情報５であるとし、通院予定日をすぎて来院していない場合はＸ印をつけ、経過していない通院予定日は〇印をつけている。このように、通院予定日に来院していない場合に印をつけて、通院が滞っていることを明確にすることにより、最適な日程で通院することを促すことがより容易となる。なお、通院予定日は、あらかじめ定めた様々な方法で決定することができる。例えば、「鈴〇二郎」は、１日，４日，８日に来院しており、３〜４日毎に、あるいは、毎火曜日と金曜日に来院していることが分かる。そのため、１１日金曜日は通院予定日であると予測することができる。そして、通院予定日である１１日金曜日に来院していないため、Ｘ印をつける。また、「●田太郎」は、レセプトデータ４（図１５参照）から、前回の来院の際に３日分の薬が処方されていることが分かる。そたのめ、前回通院日の７日から、遅くとも４日後に来院することが予想され、１１日を通院予定日とすることができる。そして、通院予定日である１１日に来院していないため、Ｘ印をつける。このように、通院予定日は、来院の間隔や薬の処方に応じて予想することができる。さらには、病名や診療内容に応じて通院予定日を予想することもできる。例えば、「鈴〇二郎」の病名は腎不全であり、診療内容は人工透析である。腎不全の場合、少なくとも４日毎に人工透析を行わないと生命に危険が生じる。そのため、８日に人工透析を行った後は、遅くとも１１日に人工透析を行う必要がある。そのため、１１日が通院予定日となる。また、「佐藤△子」の病名は花粉症であり、処方は７日分である。花粉症の場合、季節の変化で症状が治まることも考えられるが、症状が出ている場合は、薬の効果により症状を抑えることができる。そのため、１８日に７日分の薬を処方した場合は、２５日が通院予定日となる。ただし、花粉症は命に甚大な影響があることは少ないので、通院予定日をある程度の幅を持って推定することができる。そのため、通院予定日を２３日〜２８日とすることができる。逆に、「山〇花子」は、健康診断として内視鏡検査を行っている。健康診断や術後の検査のための内視鏡検査の場合は、１年〜半年に一度の検査で十分な場合が多い、そのため、通院予定日は設定しなくても良いし、長いスパン、例えば、１年後や半年後に設定しても良い。また、「●田太郎」の病名はかぜであり、最後に治療として注射を行っている。かぜやインフルエンザの場合、注射により劇的に症状が回復し、以降の通院が不要となる場合がある。そのため、かぜやインフルエンザで注射を行った場合は、通院予定日を設定しなくても良い。以上のように、病名や治療の内容、投薬の状況、あるいは病気の深刻度等によって、一定の通院予定日を設定することができ、通院予定日に来院していない場合に印をつけて、通院が滞っていることを明確にすることにより、最適な日程で通院することを促すことがより容易となる。
【０１８８】
また、通院予定日に伴う印は全ての患者に対して必ず付与しても良いが、再度来院する必要性が低いと判断される場合は、印を付与しなくても良い。例えば、病名や診療内容に応じて、印の付与を要するものと要さないものとを判断しても良い。例えば、診療内容が人工透析の場合は継続して診療を行う必要があるので印を付与し、病名がかぜやインフルエンザ、検診等の場合は早期に病状が改善する可能性が高かったり、次回の診療までの期間が長かったりする場合があるので、印を付与しないとすることもできる。
【０１８９】
また、医療履歴情報５は、月に一度ではなく、週に一度や、毎日送信しても良い。例えば、「鈴〇二郎」は、腎不全により人工透析を受けている。そのため、通院予定日である１１日に来院しなかったことを次月に知ったとしても、遅すぎる場合がある。そのため、医療履歴情報５の送信頻度を高くしても良い。また、少なくとも一部の状況の患者の医療履歴情報５のみ、高い頻度で送信し、その患者を含む全ての患者の医療履歴情報５は月に一度送信するようにすることもできる。この状況の判別については、病状や治療履歴、病名等によってあらかじめ定めておくことができる。
【０１９０】
医療詳細情報６は、サーバ１（図１５参照）に記録されている、レセプトの情報が解析・整理・解析されたデータデータであり、医療履歴情報５または医療履歴情報５が添付されたメール等を操作することにより閲覧することができる。医療詳細情報６は様々な表示形態で表示することができ、以下にその例を示す。
【０１９１】
例えば、図１９に示すように、医療詳細情報６は、患者毎の通院履歴やその際の診療内容、処方内容、あるいは病名等の医療情報が詳細にまとめられた情報である。このような患者毎の詳細情報を開示する医療詳細情報６は、例えば、医療履歴情報５（図１８参照）の患者名をクリックすることにより、医師等が使用しているＰＣのブラウザ等を介して表示することができる。もちろん、ブラウザ等を介さず、テキストあるいはｐｄｆデータ等を表示させることもできる。
【０１９２】
このように、医療履歴情報５（図１８参照）を確認しながら、患者の処方内容や病名等の詳細を参照することにより、通院予定日の信憑性や重要性を考慮して、通院予定日を医師自ら判断し、適切な治療予定をたてることができると共に、通院予定日に来院していない場合は、重篤性を考慮して、患者に直接来院を促す連絡を行う等の対処を行うことが可能となる。例えば、人工透析の予定日に来院していない場合には、それが重篤な結果を招く可能性が高いので、即刻患者に連絡を取ることができる。また、検査結果が出ているにもかかわらず、通院していない場合、検査結果を確認し、結果に応じて連絡を行う必要があるか否かの判断をすることもできる。
【０１９３】
また、図２０（ａ）に示すように、医療詳細情報６として、医療履歴情報５（図１８参照）を通院予定日から経過した日数が多い順に表示したデータを表示しても良い。このような医療詳細情報６についても、医療履歴情報５（図１８参照）または医療履歴情報５（図１８参照）が添付されたメール等を操作することにより、ブラウザ等を介して表示させることができる。例えば、メールに医療詳細情報６を表示するリンクを付与することもできるが、送信されたメールからブラウザを介して医療履歴情報５（図１８参照）を表示するようにし、医療履歴情報５（図１８参照）と共に、医療詳細情報６を表示するためのスイッチ１２をブラウザ上に表示させ、スイッチ１２をクリックすることにより、医療詳細情報６を表示するようにしても良い。具体的には、医師等は、送信されたメールから、ブラウザ上に図１８に示すような医療履歴情報５を表示させることができる。ブラウザ上にはスイッチ１２も表示されている。医師等は、スイッチ１２をクリックすることにより、図２０（ａ）に示すような医療詳細情報６を表示させることができる。
【０１９４】
図２０（ａ）に例示される医療詳細情報６は、医療履歴情報５（図１８参照）を通院予定日が早い順に並べ替えた情報である。図２０（ａ）に示す例では、当月において、最も通院予定日が早い「鈴〇二郎」は１１日に通院予定であったが来院しなかったため、１１日にＸ印がつけられている。「●田太郎」も１１日に通院予定であったが来院しなかったため、１１日にＸ印がつけられている。また、「佐藤△子」は２５日が通院予定であるが、２５日を経過していないので〇印が付されている。また、医療詳細情報６においては、通院予定日が推測されていない患者については、リストアップしない。上述のように、検診や今後の治療を要さないと予想される状況である患者については、通院予定日が設定されず、医療詳細情報６にも表示されない。そのため、「山〇花子」は医療詳細情報６としてリストアップされない。
【０１９５】
このように、医療詳細情報６として、医療履歴情報５（図１８参照）を通院予定日が早い順に並べ替えることにより、通院の管理をすべき患者を容易に識別することができ、最適な治療計画が実施されているかを判断することが容易となり、通院予定日に来院していない場合は、重篤性を考慮して、患者に直接来院を促す連絡を行う等の対処を行うことが容易となる。
【０１９６】
また、別の医療詳細情報６の例として、治療予定を管理する必要性の高い、通院緊急度の高い患者の順に医療履歴情報５（図１８参照）を並べ替えた情報がある。この順番は、病名や診療内容に基づいて優先順位をあらかじめ定め、優先順位に応じて決定している。図２０（ｂ）に示す例では、当月において、「鈴〇二郎」は診療内容が人工透析であり、診療を要する緊急度が高いため、リストの上位に記載されている。「佐藤△子」より「●田太郎」の方が通院予定日が早いが、「●田太郎」は病名がかぜであり、治療の継続性が低い可能性が高いのに対し、「佐藤△子」は病名が花粉症であり、治療の継続性が高いため、「佐藤△子」の方が治療予定を管理する必要性の高いと判断されている。また、このような医療詳細情報６においても、治療予定を管理する必要性のほとんどない患者については、リストアップしない。上述のように、病名や診療内容等から検診や今後の治療を要さないと予想される状況である患者については、通院予定日が設定されず、医療詳細情報６にも表示されない。そのため、診療内容が内視鏡検査であった「山〇花子」は医療詳細情報６としてリストアップされない。
【０１９７】
このように、医療詳細情報６として、病名や診療内容に基づいて優先順位をあらかじめ定め、優先順位に応じて、治療予定を管理する必要性の高い病名や診療内容の順に医療履歴情報５（図１８参照）を並べ替えることにより、通院の管理をすべき患者をより容易に識別することができ、最適な治療計画が実施されているかを判断することが容易となり、通院予定日に来院していない場合は、重篤性を考慮して、患者に直接来院を促す連絡を行う等の対処を行うことが容易となる。
【０１９８】
このような医療詳細情報６についても、医療履歴情報５（図１８参照）または医療履歴情報５（図１８参照）が添付されたメール等を操作することにより、ブラウザ等を介して表示させることができる。例えば、メールに医療詳細情報６を表示するリンクを付与することもできるが、送信されたメールからブラウザを介して医療履歴情報５（図１８参照）を表示するようにし、医療履歴情報５（図１８参照）と共に、医療詳細情報６を表示するためのスイッチ１３をブラウザ上に表示させ、スイッチ１３をクリックすることにより、医療詳細情報６を表示するようにしても良い。具体的には、医師等は、送信されたメールから、ブラウザ上に図１８に示すような医療履歴情報５を表示させることができる。ブラウザ上にはスイッチ１３も表示されている。医師等は、スイッチ１３をクリックすることにより、図２０（ｂ）に示すような医療詳細情報６を表示させることができる。
【０１９９】
なお、図１８，２０に例示されるような医療詳細情報６において、診療予定に伴い特に通院が望まれる通院予定日については、明確となるような印を別途付与しても良い。印としては、赤色等の目立つ色の印を付したり、点滅させたり、コメントを表示できるようにしても良い。このように特に通院が望まれる通院予定日は、病名や診療内容等に応じて一定の基準で自動的に付与するようにしても良いし、医師等が手動で付与するようにしても良い。また、明確な印は、通院予定日を超過した場合に付しても良い。
【０２００】
他の医療詳細情報６として、あらかじめ定めた１または複数の病名や診療内容に対応する患者についてのみ、通院履歴を通院予定日と共に表示しても良い。また、最後に行った診療内容毎に並べても良い。また、医者等の操作により、任意の条件で医療詳細情報６を表示させることもできる。また、通院予定日をあらかじめ定めた条件で設定しても良いが、継続したデータ収集による統計的処理により、通院予定日を設定する条件を随時更新していくこともできる。これらの統計的処理は、患者毎に統計を取っても良いし、病名あるいは診療内容毎に統計を取っても良い。また、医療詳細情報６は、サーバ１にて患者の通院履歴や医療履歴を解析した結果得られる、通院予定や治療予定等の推奨計画を提案事項として含んでも良い。
【０２０１】
次に、図１５〜図２１を用いて、第二実施形態に係る通院管理方法および通院管理プログラム（来院管理プログラム）について説明する。なお、以下の説明では、サーバ１における動作を、プログラム１１の指示によりＣＰＵ７が制御して行うが、任意の方法で、通院管理方法を実現することができる。
【０２０２】
図２１は第二実施形態に係る通院管理方法の工程を説明するフロー図である。
【０２０３】
まず、各医療機関２からサーバ１にレセプトデータ４がネットワーク３を介してアップロードされる。レセプトデータ４のアップロードは、単にサーバ１にレセプトデータ４をデータ転送することにより行っても良いし、医療機関２にて専用のサイトを開くことによりサーバ１にアクセスし、レセプトデータ４をアップロードしても良い。レセプトデータ４は、図１７に例示されるような情報を含むデータである（ステップ１）。
【０２０４】
次に、プログラム１１はＣＰＵ７を制御して、送受信器９によりレセプトデータ４を受信させ、メモリ８に各医療機関２から受信したレセプトデータ４を格納させる（ステップ２）。
【０２０５】
次に、プログラム１１はＣＰＵ７を制御して、各レセプトデータ４から、医療機関２毎の医療履歴情報５および医療詳細情報６を生成させる。生成された医療履歴情報５および医療詳細情報６は、メモリ８に格納される（ステップ３）。上述のように、医療履歴情報５は、レセプトデータ４の情報の内、通院履歴を患者毎に整理・解析したデータである。また、医療詳細情報６は、医療履歴情報５と関連付けられた情報であり、患者毎の通院履歴や診療履歴、病名等の医療履歴の詳細な情報や、通院予定日とその緊急度等を整理・解析したデータである。
【０２０６】
次に、プログラム１１はＣＰＵ７を制御して、送受信器９から各医療機関２に、対応する図１８に例示されるような医療履歴情報５をメール等により送信させる（ステップ４）。医療履歴情報５の送信は、各医療機関２が操作を行うことなく自動的に、定期的に行われ、月に１度送信しても良いし、週に１度送信しても良く、毎日でも良い。送信の間隔は一定であることに限らず、各医療機関２の要望に応じて、医療機関２毎に決めても良い。
【０２０７】
次に、各医療機関２では、医師等が、送信された医療履歴情報５を受信し、予定通りに患者が来院しているかを検討する。具体的には、上述のように、医療履歴情報５には、各患者の通院履歴と通院予定日とが記載されている。医師等は、医療履歴情報５から各患者の通院履歴と通院予定日とを確認し、各患者がいつ来院しており、通院予定日に来院しているか否かを確認する。そして、通院予定日に来院していない場合、直接患者に来院を促す等の処理を行うことができる（ステップ５）。なお、医療履歴情報５は、メール等に添付しても良いし、メール等の本文に記載しても良い。あるいは、メール等に記載されているＵＲＬから、ブラウザで表示された専用のＷｅｂページにアクセスし、医療履歴情報５を表示させる構成でも良い。
【０２０８】
次に、各医療機関２では、医師等が、送信された医療履歴情報５を操作し、図１９，２０に例示されるような医療詳細情報６を閲覧する。医療詳細情報６は、上述のように、例えば、図１９に示すような、各患者の詳細な通院履歴や、病名、診療内容、薬の処方内容等の医療履歴である。図１９に例示されるような医療詳細情報６は、例えば、医療履歴情報５の患者名をクリックすることにより表示させることができる。この際、サーバ１は、送受信器９を介して患者名がクリックされた情報を受信し、この受信した情報に応じて、プログラム１１はＣＰＵ７を制御して、対応する医療詳細情報６を読み出させ、表示制御装置１０を介して対応する医療機関２のＰＣのブラウザ等に医療詳細情報６を表示させるための信号を送信させる。このような医療詳細情報６と医療履歴情報５とを参照しながら、医師等は、各患者の詳細な診療履歴等を考慮して、患者の通院の必要性をより正確に判断し、通院予定や治療予定を的確に判断することができる。そのため、患者が適切に通院していないときは通院を促し、適切な治療を行うことができるので、早期の完治に資することが可能となる。また、医療詳細情報６は図２０に例示されるように、通院予定日が早い患者の順に各患者の通院履歴を表示したものや（図２０（ａ））、治療予定を管理する必要性の高い患者の順に通院履歴を表示したもの（図２０（ｂ））等とすることができる。図２０に例示されるような医療詳細情報６は、例えば、メール等に表示されたリンクや、ブラウザで表示された医療履歴情報５に付加されるスイッチ１２，１３等をクリックすることにより表示させることができる。この際、サーバ１は、送受信器９を介してスイッチ１２がクリックされた情報を受信し、この受信した情報に応じて、プログラム１１はＣＰＵ７を制御して、対応する医療詳細情報６を読み出させ、表示制御装置１０を介して対応する医療機関２のＰＣのブラウザ等に医療詳細情報６を表示させるための信号を送信させる。このような医療詳細情報６を参照することにより、医師等は、各患者の詳細な治療の進行状況や病状等を考慮して、患者の通院の必要性をより正確に判断し、通院予定や治療予定を的確に判断することができる。そのため、患者が適切に通院していないときは通院を促し、適切な治療を行うことができるので、早期の完治に資することが可能となる（ステップ６）。
【０２０９】
そして、判断結果により、医師等は、治療予定をより最適に見直したり、来院していない患者に直接連絡をする等して、最適な治療を行うことができるように、患者に来院をうながしたりすることができる。これにより、最適な治療を行うことを促進し、さらに、患者が適切に通院していないときは通院を促し、適切な治療を行うことができるので、早期の完治に資することが可能となる（ステップ７）。
【０２１０】
以上のように、通院管理方法、通院管理装置および通院管理プログラムによると、サーバ１に通院管理を行わせるに際し、医療機関が通常、定期的に作成するレセプトデータ４を、サーバ１にアップロードすることにより、特別なデータの作成や入力作業等が必要なくなり、容易かつ正確にサーバ１に必要な情報を提供することが可能となる。なお、レセプトは、一般的に特定のフォーマットで暗号化されている。そのため、サーバ１は、アップロードされたレセプトデータ４を復号化する機能を有することが好ましい。これにより、通常業務として随時作成しているレセプトをそのまま使用することが可能となり、より容易かつ正確にサーバ１に必要な情報を提供することができる。
【０２１１】
また、医療履歴情報５は、定期的かつ何の手続を行うことなく自動的に、サーバ１からメール等で直接各医療機関２に送信される。そのため、医師等は、医療履歴情報５を入手するための特別な手続を行うことなく、手間なく医療履歴情報５を確認することができる。また、定期的に医療履歴情報５が送付されるため、医師等は、失念することなく医療履歴情報５を確認する機会を得ることができ、確実に患者の通院管理を行うことができる。
【０２１２】
また、医師等は、送信された医療履歴情報５を操作することにより、容易に医療詳細情報６を閲覧することができる。医療詳細情報６の閲覧は、医療履歴情報５において、患者名をクリックしたり、スイッチ１２，１３等をクリックしたりするだけで様々な形式で整理された情報を容易に確認することができる。そして、医療履歴情報５を確認することに加えて、より詳細な医療詳細情報６をすることにより、より適切な治療予定を検討することができ、患者が通院することの必要性とその予定日を、より最適に確認することができる。そのため、患者が適切な日程で通院していなかったり、通院を止めてしまったりしている場合に、患者に直接連絡する等して、適切な治療の継続を促すことができ、最適な治療を行い、早期に病気を完治させる可能性を向上させることができる。
【０２１３】
なお、以上の説明では、ネットワーク３を介してレセプトデータ４のアップロードや、医療履歴情報５の送信を行う例を示したが、その他の通信手段を用いてデータ転送を行っても良く、専用回線で医療機関２とサーバ１との間の送受信を行っても良い。
【０２１４】
また、上記説明した医療履歴情報５および医療詳細情報６を用いることにより、患者の通院履歴や治療予定を管理することができるが、さらに、患者を確保し、患者を集める、医療機関２におけるマーケティング（集患とも称す）を行うこともできる。すなわち、医療履歴情報５により各患者の通院履歴を確認できると共に、医療詳細情報６により、通院している患者の住所や病名・診療内容を詳しく確認することができる。そのため、医療機関２を中心に各患者の所在地の分布や、他の医療機関との位置関係、あるいは、通院を続けている患者の病名・診療内容と通院しなくなった患者の病名・診療内容との関係等を分析することにより、通院を継続している患者の傾向と通院をしなくなった患者の傾向とを分析し、集患に活かすことが可能となる
【０２１５】
（第三実施形態）
第二実施形態において、医療機関におけるマーケティング（集患とも称す）に医療履歴情報および医療詳細情報を用いることについて説明した。以下、第三実施形態として、より集患活動に便利な医療履歴情報および医療詳細情報について、図２２，２３および図１８〜２０を用いて説明する。なお、第三実施形態において、医療履歴情報および医療詳細情報以外の構成は第二実施形態と同様であり、説明を省略する。
【０２１６】
図８は実施の形態２に係る医療履歴情報を例示する図、図９は実施の形態２に係る医療詳細情報を例示する図である。
【０２１７】
図２２に示すように、第三実施形態における医療履歴情報１５は、地図上の中心に、集患の対象となる医療機関のマーク（以下、当院１４とも称す）を配置し、来院した患者の所在地にマーク（以下、患者１６とも称す）を付している。さらに、地図上に同様の診療科目の診療を行う他の医療機関のマーク（以下、他院１７とも称す）を付すこともできる。また、医療履歴情報１５は実施の形態１と同様に、医療機関２（図１５参照）に定期的に送信され、医療履歴情報５に代わり、または医療履歴情報５と共に送信される。
【０２１８】
医師等は、受信した医療履歴情報１５を操作して、医療詳細情報を閲覧することができる。医療詳細情報は、例えば、図１９に示すような患者毎の詳細情報を示す医療詳細情報６であり、医療履歴情報１５の１つの患者１６をクリックすること等により表示される。また、医療詳細情報として図１９に示す医療詳細情報６の情報に加え、図１８，２０に示すような、患者の通院日の通院予定日とが、カレンダー状態で表示される情報を含んでも良い。ここで、患者１６として表示される来院患者として、送信したレセプトデータ４（図１５参照）の対象月の来院患者を表示しても良いし、医師等の操作により、過去数ヶ月の来院患者や過去来院した全ての患者について表示することもできる。
【０２１９】
医療履歴情報１５を操作して閲覧することができる医療詳細情報として、他に、来院した患者の病名や診療内容それぞれの合計数を表示したり、病名や診療内容毎に患者の詳細情報をソートした情報を表示したりさせることができる。また、病名や診療内容ごとに、患者１６の形状や色を異ならせ、該当する病名や診療内容の患者の分布を確認することもできる。
【０２２０】
例えば、図２３（ａ）に例示される医療詳細情報１８は、来院した全ての患者の病名の統計をとり、病名毎の来院数が多い順に、病名と来院数を表示した情報である。このような情報を表示させることにより、医師等は、自身の医療機関２（図１５参照）に、どのような病気の患者が多く来院し、どのような病気の患者が来院しないかを、一般的な病気の発生統計からの比較で確認することができる。
【０２２１】
また、図２３（ｂ）に例示される医療詳細情報１９は、病名毎に、患者の氏名，年齢，性別，診療内容，通院履歴を並べて表示した情報である。このような情報を表示させることにより、医師等は、自身の医療機関２（図１５参照）に来院している患者を病名毎に確認し、さらにそれらの患者の詳細な情報を確認することができる。そのため、自身の医療機関２に来院している患者の個人情報や治療状況を確認し、来院した患者の傾向をより細かく検討することができる。
【０２２２】
図２３に例示される医療詳細情報１８，１９は、医師等が、医療履歴情報１５におけるスイッチ２０をクリックすることにより、条件の表示画面や条件の選択画面が表示され、条件を入力したり、選択したりすることにより表示される。また、医療詳細情報１８，１９は医療履歴情報１５に表示される全ての患者に対して集計された情報であっても良いが、医療履歴情報１５の地図上において、一定の範囲を選択し、その範囲内の患者に対して集計された情報とすることもできる。範囲を指定する際には、例えば、図２２に例示される医療履歴情報１５を操作して、領域円２３を表示、拡大・縮小し、領域円２３で囲まれた範囲内の患者について集計を行うこともできる。
【０２２３】
次に、医療履歴情報５，１５および医療詳細情報６，１８，１９を用いた、医療機関における解析例を示す。
【０２２４】
まず、図１８に例示する医療履歴情報５や図１９に例示する医療詳細情報６を確認することにより、各患者の通院状況を確認し、通院されるべき日に通院し、通院予定日を過ぎても通院していない患者の有無を確認することができる。特に、通院予定日を過ぎても通院していない患者については流出した患者と認識し、図１９に例示する医療詳細情報６をさらに確認することにより、流出原因を解析することができる。例えば、流出した患者の多くが、同じ病気や診療内容の場合、医療機関２（図１５参照）がその病気や診療内容に対して評判が良くない可能性があり、その点を改善する方策を検討する等を行い、患者の流出を最低限に抑制することができる。また、流出した可能性のある患者に、来院を促す連絡を行うこともできる。
【０２２５】
また、図２２に例示する医療履歴情報１５を確認することにより、来院する患者の地図上の分布（以下、マップ情報とも称す）を確認することができる。これにより、近隣の住民のみが来院しているのか、遠方の住民も来院しているのか等を確認することができ、近隣の住民のみが来院していると判断される場合は、遠方の住民もが来院するような魅力を持つことを検討する等をすることができる。また、近隣の他の医療機関を示す他院１７を同時に表示させることにより、来院者の分布を他の医療機関との関係で確認することができる。例えば、図２２のマップ情報により患者１６の分布と他院１７とを比較すると、当院１４からの距離が同じであっても、近隣に他院１７がない地域の住民の方が多く来院していることが分かる。逆に、患者１６ａ，１６ｂ，１６ｃは、より近くに他院１７があっても、当院１４との間に川２１があっても大通り２２があっても来院している。この時、患者１６ａ，１６ｂ，１６ｃをクリックすることにより図１９に例示する医療詳細情報６を確認することにより、わざわざ当院１４に来院している患者の詳細情報を確認することができる。例えば、これらの患者がいずれも人工透析を受けているとすると、当院１４に係る医療機関２（図１５参照）は、人工透析に秀でているという評判を有することが予想され、この点をより発揮することにより、さらなる来院患者を獲得する等の方策をとることができる。
【０２２６】
また、図２３（ａ）に例示する医療詳細情報１８を確認することにより、医師等は、来院した患者における病気において、多い病気と少ない病気を一目で確認することができ、自身の医療機関における得意分野と苦手分野とを把握し、医療機関の運営方針を容易に決定することができる。例えば、図２３（ａ）に例示する医療詳細情報１８では、消化器系の疾患のために通院する患者が、一般的な統計に比べて少なかったとすると、消化器系の疾患の治療に力を入れる等の方策を施し、来院患者の増加を図ること等が可能となる。
【０２２７】
さらに、図２３（ｂ）に例示する医療詳細情報１９を確認することにより、医師等は、病気毎の患者の詳細情報や通院履歴を確認し、より詳細に自身の医療機関における得意分野と苦手分野とを把握すると共に、患者の流出状況を合わせて確認することができる。そのため、流出状況も考慮して、医療機関の運営方針を容易に決定することができる。
【０２２８】
なお、上記実施の形態２の例では、医療履歴情報１５としてマップ形式のマップ情報を用いたが、より簡便に、当院１４からの距離と来院患者の関係を示す表等としても良い。
【０２２９】
なお、本発明の通院管理方法、及び通院管理装置において「流出患者」、「継続患者」の定義については、種々の観点から行うことができる。例えば、患者個人ごとのレセプトデータの処方箋日数、診療行為を読み取り、最終来院日から適正来院日を設定し、その適正来院日から超過した日数により、流出可能性のある患者、あるいは既に流出してしまった患者（流出患者）としてカテゴリーしていく方法を採用することができる。「流出患者」、「継続患者」の定義付けについては、基本的に処方箋日数を基準としつつ、薬剤が処方されていない患者の来院周期を所定期間（例えば１ヶ月）を周期として設定し、この周期を基準として超過した日数により、流出可能性のある患者、あるいは既に流出してしまった患者（流出患者）としてカテゴリーしていく方法を採用することができる。また、リハビリ患者については、処方箋日数ではなく、診療行為（消炎鎮痛）を最優先し、所定期間（例えば３〜７日）を来院周期として設定し、流出可能性のある患者、あるいは流出患者としてカテゴリーしていく方法を採用することができる。
【０２３０】
また、本発明の通院管理方法、及び通院管理装置を活用し、競合施設（医院等）の診療圏内に存在する患者住所（自院の来院患者）を抽出し、年齢、疾患、男女などの各要素で分析し、競合の弱みを把握することも可能である。また、本発明の通院管理方法、及び通院管理装置は、前述したのとは逆に、自院の流出患者の住所と競合施設との距離関係から、競合施設に取られてしまっていると予測される患者を抽出し、年齢、疾患、男女などの各要素で分析し、自院の弱みを把握することに活用することも可能である。
【産業上の利用可能性】
【０２３１】
本発明は、来院する患者の維持や新規患者の獲得等、医療機関のマーケティング活動に好適に利用することができる。
【符号の説明】
【０２３２】
１      サーバ
２      医療機関
３      ネットワーク
４      レセプトデータ
５      医療履歴情報
６      医療詳細情報
７      ＣＰＵ
８      メモリ
９      送受信器
１０      表示制御装置
１１      プログラム
１２      スイッチ
１３      スイッチ
１４      当院
１５      医療履歴情報
１６      患者
１６ａ    患者
１６ｂ    患者
１６ｃ    患者
１７      他院
１８      医療詳細情報
１９      医療詳細情報
２０      スイッチ
２１      川
２２      大通り
２３      領域円
３０      来院管理装置
３２      制御部
４２ａ    患者データベース
４２ｂ    医療機関データベース
７０      クライアント端末
８０      インターネット
２００    来院管理システム
Ｃ        来院周期
Ｄａ      最終来院日
Ｐ        従事者
Ｒ        診療圏
Ｒａ      自院診療圏
Ｒｃ      競合診療圏
Ｒｄ      レセプトデータ
Ｒｉ      レセプト情報
Ｘ        医療機関
Ｘａ      自医療機関
Ｘｃ      競合医療機関
【図１】
2019212303.tif 000003
【図２】
2019212303.tif 000004
【図３】
2019212303.tif 000005
【図４】
2019212303.tif 000006
【図５】
2019212303.tif 000007
【図６】
2019212303.tif 000008
【図７】
2019212303.tif 000009
【図８】
2019212303.tif 000010
【図９】
2019212303.tif 000011
【図１０】
2019212303.tif 000012
【図１１】
2019212303.tif 000013
【図１２】
2019212303.tif 000014
【図１３】
2019212303.tif 000015
【図１４】
2019212303.tif 000016
【図１５】
2019212303.tif 000017
【図１６】
2019212303.tif 000018
【図１７】
2019212303.tif 000019
【図１８】
2019212303.tif 000020
【図１９】
2019212303.tif 000021
【図２０】
2019212303.tif 000022
【図２１】
2019212303.tif 000023
【図２２】
2019212303.tif 000024
【図２３】
2019212303.tif 000025