JP2019212304A - 来院管理装置、来院管理システム、及び来院管理プログラム - Google Patents

Abstract

【課題】医療機関が自院のマーケティング活動の指標とすることができる来院管理装置、来院管理システム、及び来院管理プログラムを提供する。【解決手段】来院管理システム２００において、医療機関のレセプトデータＲｄをレセプト情報として蓄積し、レセプト情報に基づいて所定の情報を生成可能な制御装置３２を有を有する。制御装置は、医療機関データベースを備え、競合医療機関の所在地から所定の範囲内を競合診療圏内として設定し、自医療機関Ｘａに来院した患者のうち、競合診療圏内に在住する患者を競合圏内患者として抽出する。【選択図】図１

Description

本発明は、医療機関が患者の来院状況を把握するための装置、システム、あるいはプログラムに関する。

近年では、様々な店舗、業種において、顧客を獲得するために、顧客の来店情報や購買情報等を分析し、集客のための方策であるマーテティングを行っている。

例えば、商品を販売する小売店や、サービスを提供するサービス業ではでは、来店者数等の顧客数、顧客毎の購入商品、顧客が男性であるか女性であるか、年齢層等の属性に関する情報を収集し、その情報を整理して分析することにより、顧客を確保あるいは新規顧客を獲得するためのマーケティング活動を行っている。

また、マーケティング活動に供するための情報の収集方法として、レジにて顧客の性別や年齢を入力し、購入商品や金額と紐付けて情報を蓄積される場合もあった。

特開２０１１−１８７０７４号公報

ここで、医療機関にとっても、自院の患者を増やすことは経営上の観点からで重要であり、新規来院患者の獲得や、自院の患者の流出を抑制して、患者を増やすマーケティング活動（集患・増患）を行う必要性が高まっている。

しかしながら、自院の近隣の医療機関へ通院する患者の通院状況の調査等を、マーケティング会社などに商圏調査を依頼する、あるいは商圏調査のデータを購入するなどとすると、大きなコストがかかり経営を圧迫しかねない。

そこで本発明は、医療機関が自院のマーケティング活動の指標とすることができる来院管理装置、来院管理システム、及び来院管理プログラムの提供を目的とした。

ここで、患者が医療機関を選択する際には、自宅から近い、あるいは職場から近いなどの要因に加え、何らかの理由で通院する医療機関を変更することもありえる。医療機関にしてみれば、他の医療機関（他院）のほうが近いにも関わらず自院に通院する患者や、自院に通院していた患者が来院しなくなったなどが一定の割合で存在することが想定される。

本発明の発明者が検討した結果、自院の患者をある視点で観察すれば、自院の強みや弱みを把握する指標とすることができるとの知見に至った。特に、特定の医療機関の近くに在住している患者が来院しなくなった場合など、当該患者がその医療機関に流出した可能性があり、当該患者の属性（性別や年齢）、あるいは傷病内容などの傾向を把握することで、自院に来院しなくなった要因を推測することができる。また、逆に他院のほうが近い場所に在住しているにも関わらず、わざわざ自院に来院する患者の属性（性別や年齢）、あるいは傷病内容などの傾向を把握することで、自院の強みとなる要因を推測することができる。

言い方を換えれば、自院に来院する患者のうち、競合医療機関の診療圏内の患者の動向を分析することで、マーケティング会社等の商圏調査によらずに、医療機関が自院の強みや弱み、あるいは他院の強みや弱みを推測することができるとの知見に至った。

上述の知見に基づき提供される本発明の来院管理装置は、第一の医療機関が、自院に来院する患者の傾向を分析可能な来院管理装置であって、前記第一の医療機関のレセプトデータをレセプト情報として蓄積し、前記レセプト情報に基づいて所定の情報を生成可能な制御装置を有し、前記制御装置が、複数の医療機関の所在地に係る情報を含む医療機関データベースを備え、前記第一の医療機関から所定の範囲内に所在する医療機関の少なくとも一部を競合医療機関として設定するとともに、前記競合医療機関の所在地から所定の範囲内を競合診療圏内として設定し、前記第一の医療機関の患者のうち、前記競合診療圏内に在住する患者を競合圏内患者として抽出可能であることを特徴とするものである。

本発明の来院管理装置によれば、自院に来院する患者のうち、競合医療機関の診療圏内の患者の動向を分析することで、医療機関が自院の強みや弱み、あるいは他院の強みや弱みを推測して、患者の流出の阻止や新規患者の獲得等のマーケティング活動（集患活動）に貢献することができる。

具体的に説明すると、本発明の来院管理装置によれば、競合の診療圏内に在住する患者（競合圏内患者）が、継続して来院しているかあるいは来院しなくなったかなどの動向や、これらの患者の性別や年齢などの傾向を把握することが可能となる。また、継続して来院している患者と来院しなくなった患者の属性等を比較して分析すれば、医療機関が自院の強みや競合医療機関の弱み（流出患者には男女のうちどちらが多いのか、あるいはどのような年齢の患者が流入しているのかなど）を把握して、以後のマーケティング活動の指標とすることができる。

また、本発明の来院管理装置は、前記制御装置が、前記第一の医療機関の患者の来院状況を判定して、少なくとも前記競合圏内患者を含む複数の患者を複数のカテゴリーに区分可能とするとよい。

上述の構成によれば、自院に来院する患者のうち、競合医療機関の診療圏内の患者の動向を分析することで、医療機関が自院の強みや弱み、あるいは他院の強みや弱みを推測して、患者の流出の阻止や新規患者の獲得等のマーケティング活動（集患活動）に貢献することができる。また、流出傾向にある患者や継続して来院している患者等をカテゴリーに区分することで、医療機関の従事者がこれらの患者を判別しやすくなる。

本発明の来院管理装置は、前記制御装置が、前記第一の医療機関の患者の来院状況を判定して、少なくとも前記競合圏内患者を含む複数の患者を複数のカテゴリーに区分可能であり、前記競合圏内患者のうち、前記第一の医療機関に継続して来院している患者を自院流入患者として区分し、所定の期間内に前記第一の医療機関への来院がなかった患者の少なくとも一部を自院流出患者として区分するものとすることができる。

上述の構成によれば、自院に来院する患者のうち、競合医療機関の診療圏内の患者の動向を分析することで、医療機関が自院の強みや弱み、あるいは他院の強みや弱みを推測して、患者の流出の阻止や新規患者の獲得等のマーケティング活動（集患活動）に貢献することができる。また、流出傾向にある患者（自院流出患者）や、他院のほうが近いにもの関わらず継続して来院している患者（自院流入患者）をカテゴリーに区分することで、医療機関の従事者がこれらの患者を判別しやすくなる。

さらに、本発明の来院管理装置は、前記制御装置が、前記競合圏内患者の前記第一の医療機関への来院状況を判定して、前記競合圏内患者を複数のカテゴリーに区分可能であり、前記競合圏内患者の属性を表示可能であると、さらによい。

上述の構成によれば、どのような属性（地域、年齢、性別、疾患の内容等）の患者が他院に流出しているのかを、医療機関の従事者等が予測することができる。その結果、本発明の来院管理装置は、医療機関が、流出傾向にある患者や継続傾向にある患者の属性を把握するとともに、マーケティング活動（集患）を行う際の指標とすることができる。

本発明の来院管理装置は、前記制御装置が、前記第一の医療機関の少なくとも一部の患者の在住地を、地図上に位置情報として表示させる患者分布マップ情報を生成可能であるとよい。

上述の構成によれば、自院の患者の在住地を地図上に表示して視覚的に把握することができる。その結果、本発明の来院管理装置は、医療機関の従事者が、他院（競合医療機関）に近い患者が多いか否かなど、患者の分布を視覚的に把握可能となり、効率的な集患活動の実施に貢献することができる。

本発明の来院管理装置は、前記制御装置が、患者の年齢あるいは性別を含む属性情報が蓄積された患者属性情報データベースを備え、前記患者分布マップ情報には、少なくとも一部の前記競合圏内患者の前記属性情報を表示可能であることが望ましい。

上述の構成によれば、自院の患者の在住地を地図上に表示して視覚的に把握することができる。その結果、本発明の来院管理装置は、医療機関の従事者が、他院（競合医療機関）に近い患者が多いか否か、またどのような属性の患者が多く流入しているかなど、患者の分布やその属性を視覚的に把握可能となり、効果的な集患活動の実施に貢献することができる。

本発明の来院管理システムは、上述したいずれかの来院管理装置と、前記来院管理装置とインターネットを介して接続可能なクライアント端末とを有し、前記制御装置が、前記第一の医療機関のレセプトデータをレセプト情報として蓄積し、前記レセプト情報に基づいて所定の情報を生成可能な制御装置を有し、前記制御装置が、複数の医療機関の所在地に係る情報を含む医療機関データベースを備え、前記第一の医療機関から所定の範囲内に所在する医療機関の少なくとも一部を競合医療機関として設定するとともに、前記競合医療機関の所在地から所定の範囲内を競合診療圏内として設定し、前記第一の医療機関の患者のうち、前記競合診療圏内に在住する患者を競合圏内患者として抽出可能であり、前記クライアント端末に前記競合圏内患者に係る情報を表示可能であることを特徴とするものである。

本発明の来院管理システムによれば、自院に来院する患者のうち、競合医療機関の診療圏内の患者の動向を分析することで、医療機関が自院の強みや弱み、あるいは他院の強みや弱みを推測して、患者の流出の阻止や新規患者の獲得等のマーケティング活動（集患活動）に貢献することができる。

本発明の来院管理プログラムは、上述したいずれかの来院管理装置に、前記競合圏内患者を抽出する競合圏内患者抽出ステップを実行させることを特徴とするものである。

本発明の来院管理プログラムによれば、自院に来院する患者のうち、競合医療機関の診療圏内の患者の動向を分析することで、医療機関が自院の強みや弱み、あるいは他院の強みや弱みを推測して、患者の流出の阻止や新規患者の獲得等のマーケティング活動（集患活動）に貢献することができる。

上述のとおり、医療機関においては、マーケティング活動を行うことは非常にまれであった。これは、病気の発症は予定されるような性質ではなく、通院するかしないかや通院の時期等は患者が主体となって決定されるものであり、医師等は、通院してきた患者を診断し、治療を行うのが一般的であるためである。さらに、情報の収集には手間がかかるうえ、医師は多忙であり、情報の収集や整理等の患者を集めるための継続的な活動を行うことは困難であるためである。

本発明は、医療機関においても、患者等の情報の収集や整理を容易に行うことを目的とする。

上記目的を達成するために、本発明の一実施形態における通院管理方法は、複数の患者のレセプトデータを各医療機関からネットワークを介してサーバに読み込ませる工程と、前記レセプトデータから前記患者毎に通院履歴が整理された医療履歴情報および前記医療履歴情報と関連付けられて医療履歴が整理された医療詳細情報を対応する前記医療機関毎に前記サーバにて作成する工程と、前記サーバからネットワークを介して対応する前記医療機関に前記医療履歴情報を送信する工程とを有し、前記医療履歴情報は、前記医療機関とそれぞれの前記患者の所在地との位置関係が明確となるマップ情報を含み、前記医療機関では前記マップ情報を用いて前記サーバにアクセスして前記サーバ内の前記医療詳細情報を閲覧可能であることを特徴とする。

さらに、本発明の一実施形態における通院管理装置は、制御装置と、ネットワークと接続される送受信器とを有し、前記送受信器は複数の医療機関それぞれから複数の患者のレセプトデータを受信し、前記制御装置は前記レセプトデータから前記患者毎に通院履歴が整理された医療履歴情報および前記医療履歴情報と関連付けられて医療履歴が整理された医療詳細情報を対応する前記医療機関毎に作成し、前記送受信器は対応する前記医療機関に前記医療履歴情報を送信し、前記医療履歴情報は前記医療機関とそれぞれの前記患者の住所との位置関係が明確となるマップ情報を含み、前記制御装置は前記医療機関による前記マップ情報を介した操作により、前記医療機関に前記医療詳細情報を表示させることを特徴とする。

このような通院管理方法あるいは通院管理装置によって、医師等は、マップ情報を含む医療履歴情報により来院した患者の所在地と医療機関との位置関係を確認しながら、さらに、医療詳細情報により患者の通院履歴や医療履歴を詳細に確認することによって、患者の来院状況とその患者の医療履歴を患者の所在地と医療機関との位置関係を考慮しながら検討することができるため、患者等の情報の収集や整理を容易に行い、容易かつ的確にマーケティング活動を行うことができる。

また、前記マップ情報は、地図上に、前記医療機関の所在地と、それぞれの前記患者の所在地とが表示されても良い。

これにより、来院した患者の所在地と医療機関との位置関係を視覚的に確認することができ、より的確に患者等の情報の収集や整理を行い、容易かつより的確にマーケティング活動を行うことができる。

また、前記マップ情報は、地図上に、さらに周辺の他の医療機関の所在地が表示されても良い。

これにより、来院した患者の所在地と医療機関との位置関係を、他の医療機関の所在地との位置関係を含めて検討することができ、他の医療機関との関係を踏まえた、より詳細な患者等の情報の収集や整理を行い、容易かつより的確にマーケティング活動を行うことができる。

また、前記医療詳細情報は、前記患者の病名と来院数との関係としても良い。

これにより、来院している患者の病名とその人数との関係が明確となり、より詳細な患者等の情報の収集や整理を行い、容易かつより的確にマーケティング活動を行うことができる。

また、前記医療詳細情報は、前記患者それぞれの前記医療履歴と前記通院履歴とが病名毎に並べられても良い。

これにより、病名毎に、来院している患者の通院履歴や医療履歴が明確となり、より詳細な患者等の情報の収集や整理を行い、容易かつより的確にマーケティング活動を行うことができる。

さらに、本発明の一実施形態における通院管理プログラムは、制御装置に、医療機関から受信した複数の患者のレセプトデータから、前記患者毎に通院履歴が整理され、前記医療機関とそれぞれの前記患者の所在地との位置関係が明確となるマップ情報を含む医療履歴情報、および前記医療履歴情報と関連付けられて医療履歴が整理された医療詳細情報を対応する前記医療機関毎に作成させるステップと、対応する前記医療機関に前記医療履歴情報を送信させるステップと、前記医療機関による前記マップ情報を介した操作により、前記医療機関に前記医療詳細情報を表示させるステップとを実行させることを特徴とする。

このような通院管理プログラムにおいても、医師等は、マップ情報を含む医療履歴情報により来院した患者の所在地と医療機関との位置関係を確認しながら、さらに、医療詳細情報により患者の通院履歴や医療履歴を詳細に確認することによって、患者の来院状況とその患者の医療履歴を患者の所在地と医療機関との位置関係を考慮しながら検討することができるため、患者等の情報の収集や整理を容易に行い、容易かつ的確にマーケティング活動を行うことができる。

以上のように、医療機関においても、患者等の情報の収集や整理を容易に行うことができる。

本発明によれば、医療機関が自院のマーケティング活動の指標とすることができる来院管理装置、来院管理システム、及び来院管理プログラムを提供することができる。

本発明の来院管理装置、及び来院管理システムを示す模式図である。 図１の機能ブロックを示す図である。 図１の来院管理装置の周期設定テーブルの一例を示す図である。 図１の来院管理装置における最終来院日と来院基準日を示す図である。 図１の来院管理装置の来院周期と超過日数を示す図である。 図１の来院管理装置の来院状況概要表示の一例を示す図である。 図１の来院管理装置のリスト表示の一例を示す図である。 図１の来院管理装置のカテゴリーマップ表示の一例を示す図である。 図１の来院管理装置の詳細情報表示の一例を示す図である。 図１の来院管理装置の患者分布マップ画像の一例を示す図である。 図１の来院管理装置の自院流出患者リスト及び自院流入患者リストの一例を示す図である。 図１の来院管理装置が実行する来院状況送信処理の一例を示すフロー図である。 図１の来院管理装置が実行する来院周期設定処理の一例を示すフロー図である。 図１の来院管理装置が実行する競合分析処理の一例を示すフロー図である。 本発明の通院管理の概略を示す概念図である。 本発明のサーバの構成を例示するブロック図である。 レセプトデータに含まれる情報を例示する図である。 本発明の第二実施形態に係る来院管理装置の医療履歴情報を例示する図である。 本発明の第二実施形態に係る来院管理装置の医療詳細情報を例示する図である。 本発明の第二実施形態に係る来院管理装置の医療詳細情報を例示する図である。 本発明の第二実施形態に係る通院管理方法の工程を説明するフロー図である。 本発明の第三実施形態に係る来院管理装置の医療履歴情報を例示する図である。 本発明の第三実施形態に係る来院管理装置の医療詳細情報を例示する図である。

以下、本発明の第一の実施形態に係る来院管理装置３０、及び来院管理システム２００について、図面を参照しつつ詳細に説明する。

来院管理装置３０は、患者の来院状況を把握しようとする医療機関Ｘ（第一の医療機関）に対して、来院状況を把握可能とする各種の情報を医療機関Ｘに提供可能としている。すなわち、来院管理装置３０は、医療機関Ｘに対してサービスを提供する者（サービス提供者）が、来院管理を行うための情報の分析や提供等のサービスを医療機関Ｘに提供するために用いられる。

図１に示すとおり、来院管理システム２００は、少なくとも一のクライアント端末７０と、来院管理装置３０が設けられたサーバ３６とを有している。本実施形態の来院管理システム２００では、クライアント端末７０と、来院管理装置３０とが、インターネット８０を介して接続されている。また、来院管理装置３０は、サーバ３６に設けられている。

なお、以下の説明では、来院管理装置３０をサーバ３６に設けた例を挙げて説明するが、本発明の来院管理システムの来院管理装置は、クライアント端末７０の制御装置に設けられているものであってもよい。また、この場合には、クライアント端末７０はインターネット８０に接続されていないものであってもよい。すなわち、本発明の来院管理装置は、医療機関Ｘ等、サービスを利用する者（サービス利用者）の端末のローカルに設けられるものであり、クライアント端末７０の制御装置７２に来院管理プログラムをインストール等することにより、後述する各種の機能（来院履歴管理機能や競合圏分析機能）を発揮させるものであってもよい。

図１に示すとおり、クライアント端末７０は、例えば医療機関Ｘにおいて用いられている端末装置である。クライアント端末７０は、例えば、パーソナルコンピュータ７０ａ、タブレット型端末、あるいはスマートフォン７０ｂ等の端末装置が用いられる。

なお、本実施形態の来院管理装置３０は、複数の医療機関ＸからレセプトファイルＲｆを受信して、医療機関Ｘごとに、レセプトデータＲｄに含まれる情報を後述する患者データベース４２ａとして構築する。言い方を換えれば、本実施形態の来院管理装置３０は、医療機関Ｘごとに、患者データベース４２ａを構築する。

なお、本発明の来院管理装置は、本実施形態に限定されない。すなわち、本発明の来院管理装置を医療機関のクライアント端末に設けようとする場合には（医療機関のクライアント端末のローカルに設ける場合）、来院管理装置にひとつの患者データベースが構築されるものとしてもよい。

なお、本明細書における「医療機関」とは、診療を行う機関であって、病院、診療所、歯科や内科等の医院、整骨院など、レセプトデータＲｄが用いられる（作成される）各種の機関が含まれる。また、以下の説明では、病院、診療所、整骨院等の医療機関を総称して、単に「医療機関Ｘ」と記載して説明する場合がある。

また、「医療機関の従事者（以下、単に「従事者Ｐ」と記載する場合がある）」とは、医師のほか、医療機関の事務担当者、看護師等、医療機関の業務に従事する者すべてが含まれる。

「レセプト」とは、健康保険組合や市区町村などから医療機関Ｘが診療報酬を受け取ろうとする際に、所定の審査支払機関に診療報酬の請求を行う際の書類（データ）である。レセプトには、患者の氏名や医療機関名、診療の対象となった傷病の名前をはじめ、診療行為の内容、処方した薬などに応じた診療報酬点数などが、１ヶ月分まとめて記載されている。

レセプトは、所定のフォーマットに統一されたフォーマットの電子データとして、所定の審査支払機関に提出される。以下の説明では、レセプトの電子データを「レセプトデータＲｄ」と称して説明する。レセプトデータＲｄは、医療機関Ｘにおいて用いられるレセコン（レセプトコンピュータ）に、診療内容や処方箋の種類などの所定の情報が入力されて生成されるデータである。

図１に示すとおり、本実施形態の来院管理システム２００では、レセプトデータＲｄが加工された所定の形式のファイルに変換して暗号化されて送信される。そのため、レセプトデータＲｄが加工されて所定の形式に変換して暗号化されたファイルを、単に「レセプトファイルＲｆ」と記載して説明する場合がある。なお、本実施形態では、レセプトファイルＲｆには患者の住所や氏名等、個人を特定可能な情報（個人情報）が含まれないものとされているが、「氏名」を含むか否かに関しては任意とされている。レセプトファイルＲｆには、医療機関Ｘにおいて患者を特定可能となる患者ＩＤが含まれる。

なお、本実施形態の来院管理システム２００では、レセプトデータＲｄを加工して所定の形式のファイルに変換した上で送信するものとしたが、本発明の来院管理システムはこれに限定されない。例えば、本発明の来院管理システム及び来院管理装置は、レセプトデータＲｄをそのままのファイル形式として読み込み可能なものとしてもよい。

＜来院管理装置について＞
続いて、来院管理装置３０について詳細に説明する。来院管理装置３０は、患者の来院履歴に関する情報（来院状況）や傷病等の各種の情報を医療機関Ｘのクライアント端末７０に表示させる。来院管理装置３０は、これにより従事者Ｐが患者の来院状況等を容易に把握可能としている。

図１には、来院管理装置３０のハードウエア構成をブロック図として模式的に示している。上述のとおり、来院管理装置３０は、サーバ３６に設けられている。図１に示すとおり、来院管理装置３０は、制御部３２（制御装置）を備えている。また、制御部３２は、ハードウエア構成として、ＲＯＭ３３、ＣＰＵ３４、ＲＡＭ３５、及びＩ／Ｆ（図示を省略）を含み、それぞれがバスを介して接続されている。

このようなハードウエア構成において、ＲＯＭ３３、ＨＤＤ又は光ディスク等の記憶媒体（図示を省略）に格納されたプログラムがＲＡＭ３５に読み出され、ＣＰＵ３４がそれらのプログラムに従って演算を行うことにより、ソフトウエアが構成される。そのような制御部３２とハードウエアとの組みあわせによって、来院管理装置３０を実現する機能ブロック（来院履歴管理部４４及び競合圏分析部４６等）が構成される。

図２は、来院管理装置３０の機能ブロックを示している。図２に示すとおり、来院管理装置３０には、データベース４０、来院履歴管理部４４、競合圏分析部４６、メール送信部４７、及び表示制御部４８が設けられている。

図２に示すとおり、来院履歴管理部４４には、来院周期設定部５０、来院基準日設定部５１、患者カテゴリー設定部５２、来院状況分析部５３、及び来院情報生成部５４が設けられている。

データベース４０には、各種の情報がデータベース化されて蓄積されている。図２に示すとおり、データベース４０には、患者データベース４２ａ、患者属性情報データベース４２ｃ、及び医療機関データベース４２ｂが含まれている。

患者データベース４２ａには、医療機関Ｘから受信したレセプトファイルＲｆのデータがレセプト情報Ｒｉとして蓄積されている。具体的には、患者データベース４２ａには、医療機関Ｘにおいて作成されたレセプトデータＲｄがレセプトファイルＲｆに変換された後、医療機関Ｘのクライアント端末７０からサーバ３６に送信され、当該レセプトファイルＲｆに含まれる情報がレセプト情報Ｒｉとして蓄積されている（図１参照）。言い方を換えれば、患者データベース４２ａは、医療機関Ｘのクライアント端末７０からレセプトファイルＲｆが送信されて来院管理装置３０にアップロードされることに基づいて更新される。患者データベース４２ａには、レセプト情報Ｒｉが患者に紐付けられた情報として構築されている。なお、上述のとおり、患者データベース４２ａは医療機関Ｘごとに構築されている。

レセプト情報Ｒｉには、患者に対して行われた診療行為に関する情報が含まれている。具体的には、レセプト情報Ｒｉには、医療機関Ｘにおいて患者を特定する患者ＩＤや来院日、診療行為の内容を示す情報（診療情報）、処方箋の内容や処方箋日数、傷病名等の情報が含まれている。

患者属性情報データベース４２ｃには、患者ＩＤのほか、患者の年齢、性別、在住場所に関する情報（在住地情報）など、患者の属性を含む情報（患者属性情報）が含まれたデータベースである。本実施形態の来院管理装置３０では、医療機関Ｘから患者属性情報の提供を受け、患者属性情報データベース４２ｃに患者属性情報が蓄積されている。また、患者属性情報データベース４２ｃは、後述する競合圏分析に関するサービスの利用者である医療機関Ｘごとに構築されている。

医療機関データベース４２ｂには、複数の医療機関Ｘの所在地や、診療科目に係る情報など、医療機関Ｘに関する情報がデータベースとして蓄積されている。

来院周期設定部５０は、来院周期Ｃを設定するために設けられている。来院周期Ｃは、患者の仮想的な来院サイクルとして設定された周期である。より具体的に説明すると、来院周期Ｃは、最終来院日から次に来院することが望ましい日までの日数、あるいは最終来院日から次の来院が見込まれる日までの日数を仮想的に示す周期である。別の言い方をすれば、来院周期Ｃは、患者の最終来院日から次に来院すると推測される日までの期間として設定される周期である。

来院管理装置３０は、レセプト情報Ｒｉに基づいて来院周期Ｃを設定可能としている。より具体的には、来院管理装置３０は、来院周期Ｃを、レセプト情報Ｒｉに含まれる最終来院日における診療行為の情報や、処方箋日数に係る情報、あるいは傷病等に基づいて設定する。また、来院管理装置３０は、来院周期Ｃを、レセプト情報Ｒｉに含まれる情報のうち、処方箋日数よりも診療行為を優先して設定する。また、来院管理装置３０は、レセプト情報Ｒｉに基づいて、来院周期Ｃを設定する患者を抽出する。

来院管理装置３０による来院周期Ｃの設定について、例を挙げて説明する。来院周期Ｃは、例えば、図３に一例として示す来院周期決定テーブル等を用いて決定することができる。

図３に示すとおり、来院管理装置３０は、最終来院日の傷病が、例えば風邪やインフルエンザなど、一度の来院で処方される処方箋などで完治可能な傷病である場合には来院周期Ｃを設定しない。具体的には、来院管理装置３０は、最終来院日の傷病が、風邪やインフルエンザなど一時的な傷病である場合には、再度の来院（再来院）を要しない、あるいは見込まない患者を、再診患者以外の非再診患者として、来院周期Ｃを設定しない。

一方、来院管理装置３０は、最終来院日の傷病が、例えば花粉症など、一時的に発症緒する傷病ではあるものの、季節など所定のサイクルで発症するものである場合には、傷病の発症サイクルに沿って（例えば一年など）来院周期Ｃを設定する。

また、来院管理装置３０は、例えば、「高血圧」など、処方箋の処方が主な診療である場合には、処方箋が何日分処方されているか（処方箋日数）に応じて、来院周期Ｃを設定する。例えば、処方箋日数が「７日分」である場合には、来院周期Ｃを「７日間」として設定し、処方箋日数が「１０日分」である場合には、来院周期Ｃを「１０日間」として設定する。また、処方箋日数が処方されていない場合（再来院を要するものの処方箋が処方されていない場合）には、来院周期Ｃを所定の日数（例えば「１ヶ月」）として設定してもよい。

また、来院管理装置３０は、最終来院日の診療行為が、例えば「検査」や「リハビリ」など、処方箋日数に関わらず来院することが見込まれる、あるいは再来院を要する場合には、処方箋が処方されている場合であっても診療行為を優先して来院周期Ｃを設定する。例えば、診療行為として「検査」が行われた場合には、検査結果を伝えるため再診の予約が入っていることが想定されるため、「７日」等検査の結果が出るまでの期間を想定した来院周期Ｃが設定される。また、診療行為が「リハビリ」である場合、傷病の内容などに応じて、例えば「３日」や「７日」など、リハビリを行うに適した日数を来院周期Ｃとして設定する。

このように、来院管理装置３０は、処方箋日数や診療行為の内容に応じて来院周期Ｃを設定する。これにより、来院管理装置３０は、高い精度で患者ごとに適切な来院周期Ｃを設定することができる。

なお、歯科や内科等、診療科目によって、診療が行われる傷病の内容や診療行為の特性が異なる。そのため、来院周期Ｃの設定は、診療科目に応じてどの項目を優先するかといった優先順位が決定されることが望ましい。例えば、ある診療科目では、診療行為の内容等を優先し、その次の優先順位として処方箋日数に基づいて来院周期Ｃが決定されるものとすることができる。また、ある診療科目では、診療行為の内容を最優先項目として、次いで処方箋日数を優先した順位で来院周期Ｃを設定するなど、診療科目に応じて来院周期Ｃが決定されることが望ましい。

来院基準日設定部５１は、来院基準日Ｄｂを設定するために設けられている。来院基準日Ｄｂは、患者が次に来院することが見込まれる日程、あるいは患者が次ぎに来院することが望ましい日程を示すものである。

図４（ａ）に示すとおり、来院基準日Ｄｂは、レセプト情報Ｒｉに含まれる患者の最終来院日Ｄａと、当該患者に対して来院周期設定部５０により設定された来院周期Ｃとに基づいて設定される。具体的には、来院基準日Ｄｂは、最終来院日Ｄａから来院周期Ｃの日数を加算した日程として設定される。例えば、とある患者の最終来院日Ｄａが「８月１日」であり、来院周期設定部５０により来院周期Ｃが「７日間」として設定されている場合には、来院基準日設定部５１は、当該患者の来院基準日Ｄｂを「８月８日」として設定する。なお、設定された来院基準日Ｄｂは、患者の仮想来院日として、別途設けたカレンダーなどに登録されるものとしてもよい。これにより、医療機関Ｘにおいて、患者の来院数をある程度予測することが可能となる。

図４（ａ）に示すとおり、例えば、主な診療行為として処方箋の処方が行われており、継続的に医療機関Ｘに通院している患者Ａでは、処方箋日数のサイクルに沿ってある程度規則的な期間で通院することが考えられる。そのため、来院周期Ｃは患者の仮想的な来院サイクルであり、来院基準日Ｄｂは次に患者が来院すると推測される来院仮想日であると言える。

なお、図４（ｂ）に示すとおり、最終来院日Ｄａから現在までの日数（経過日数Ｎａ）が来院周期Ｃを超えており、現在において来院基準日Ｄｂを経過している場合もあれば、図４（ｂ）に示すように現在において来院基準日Ｄｂを経過していない場合もある。図４（ｂ）に示すとおり、例えば、継続的に医療機関Ｘに通院しているものの来院サイクルが長期となる患者Ｂでは、来院周期Ｃが設定されているものの、現在において来院周期Ｃを経過していない場合がある。

患者カテゴリー設定部５２は、患者のカテゴリー（患者カテゴリー）を決定する。より具体的には、患者カテゴリー設定部５２は、レセプト情報Ｒｉに含まれる最終来院日Ｄａや来院周期Ｃ、あるいは診療行為に基づいて、患者のカテゴリーを決定する。

患者カテゴリーは、来院基準日Ｄｂを基準として、来院基準日Ｄｂまでに来院があったか否か、また、来院基準日Ｄｂを経過している場合（最終来院日Ｄａから来院周期Ｃを経過している場合）には、来院基準日Ｄｂから超過している日数（超過日数Ｎ）に応じて患者カテゴリーを区分する。例えば、患者が再診を要する（あるいは見込まれる）患者に対しては、「再診患者」として区分される。また、再診患者に対して、「継続患者」、「流出可能性患者」、及び「流出患者」を含む複数の患者カテゴリーに区分する。

患者カテゴリーについて、図５を参照しつつさらに詳細に説明する。本実施形態の来院管理装置３０では、再診患者を、「周期内患者」、「継続患者」、「超過」、「流出可能性患者」、及び「流出患者」のいずれかに区分可能としている。なお、来院管理装置３０は、来院回数が一回である患者と、来院回数が二回以上である患者とを区分けして、上述の患者カテゴリーに区分する。

具体的に説明すると、図５に示すとおり、現在において来院基準日Ｄｂが経過していない患者（最終来院日Ｄａから来院周期Ｃを経過していない患者）は、「継続患者」又は「周期内患者」として区分される。すなわち、最終来院日Ｄａから現在までの期間（経過日数Ｎａ）が、来院周期Ｃ以下である場合（Ｎａ≦Ｃの場合）には、周期内又は継続患者として区分される。

また、図５に示すとおり、現在において来院基準日Ｄｂを経過している場合には、来院基準日Ｄｂから経過した日数（超過日数Ｎｂ）に応じて患者カテゴリーの区分が行われる。

例えば、図５に示すとおり、現在において来院基準日Ｄｂを経過しており、かつ、第一超過日数Ｎ１をまでの場合（Ｎｂ≦Ｎ１の場合）には、「超過Ａ」として区分される。また、現在において第一超過日数Ｎ１を経過しており、かつ、第二超過日数Ｎ２までの場合（Ｎ１＜Ｎｂ≦Ｎ２の場合）には、「流出可能性」として区分される。さらに、現在において第二超過日数Ｎ２を経過しており、かつ、第三超過日数Ｎ３までの場合（Ｎ２＜Ｎｂ≦Ｎ３の場合）には、「超過Ｂ」として区分される。さらに、現在において第三超過日数Ｎ３を経過している場合（Ｎ３＜Ｎｂの場合）には、「流出」として区分される。言い方を換えれば、来院管理装置３０は、「継続患者」、「超過Ａ」、「流出可能性患者」、「超過Ｂ」、「流出患者」の順に、適切な来院周期内での来院から流出する傾向（適切な来院サイクルから脱落する傾向）のある患者として区分する。

このように、来院管理装置３０は、患者が流出したか否かの基準として、来院周期Ｃや来院基準日Ｄｂ、あるいは超過日数Ｎを設定した上で、これらの基準に従って患者を段階的に区分可能とされている。これにより、来院管理装置３０は、動向を注視するべき患者を客観的な基準で抽出するとともに、流出患者に至るまでの過程において患者を段階的に区分する。

これにより、医療機関Ｘの従事者Ｐが、動向を注視するべき患者を把握しやすくなるとともに、患者カテゴリーを参照して優先順位を決めて患者に対する対策を講じることができる。例えば、従事者Ｐが、来院管理装置３０の示す患者カテゴリーのうち、「流出可能性患者」や「超過」であれば完全に流出する前の段階であるとして、これらに区分される患者を優先して来院を促進するなどの対策を講じることができる。このように、来院管理装置３０は、患者がどのような状況（継続して来院しているか、流出する傾向にあるか否かなどの状況）であるかを示す客観的な判断基準を、医療機関Ｘの従事者Ｐに提供することができる。

来院状況分析部５３は、レセプト情報Ｒｉに含まれる情報の少なくとも一部を集計して分析するなどして、患者の来院状況を分析可能とされている。より具体的に説明すると、来院状況分析部５３は、患者データベース４２ａに蓄積されているレセプト情報Ｒｉに基づいて、各患者カテゴリーに区分される患者が何人いるかといった集計や、前月と比較した患者の増減に関する統計、流出可能性患者あるいは流出患者として判定された患者の人数などの集計を行う。言い換えれば、来院管理装置３０は、継続患者や流出可能性患者等、各患者カテゴリーの増減傾向をデータ化することができる。その結果、従事者Ｐが、患者の定着化が進んでいるか否か、あるいは患者の流出傾向が強くなっているかなど、患者全体の傾向を把握することができる。

来院情報生成部５４は、クライアント端末７０にメールとして送信するため、あるいはクライアント端末７０の表示装置７６に表示させる情報を送信するための各種の来院管理情報１００を生成する。本実施形態では、来院情報生成部５４は、来院管理情報１００として、来院状況概要情報１０１やリスト情報１０２（来院履歴情報）、カテゴリーマップ情報１０３、あるいは詳細情報１０４などを生成する。

来院状況概要情報１０１は、クライアント端末７０に対してメールとして送信され、クライアント端末７０において来院状況概要表示１１１として表示される。来院状況表示１１０は、来院状況分析部５３が分析した結果に基づいて表示される来院状況の概要を可視化したものとすることができる。本実施形態では、レセプトファイルＲｆが来院管理装置３０に送信（アップロード）された後の所定のタイミング（例えば毎月予め定められた日など）に、来院状況概要情報１０１をクライアント端末７０に送信する。なお、来院状況概要情報１０１が医療機関Ｘのクライアント端末７０に送信されるタイミングは、適宜設定可能である。また、所定のタイミングまでに（例えば毎月定められた所定の期日までに）医療機関ＸからレセプトファイルＲｆのアップロードがなかった場合に、アップロードを促すメールなどを送信可能としてもよい。

例えば、図６に一例として示すとおり、来院状況概要表示１１１には、当月の新規患者の人数や、流出可能性患者の人数、あるいはすべての患者のカテゴリーの内訳や流出可能性患者などの人数の推移等を含むものとすることができる。

リスト情報１０２（来院履歴情報）は、来院状況概要情報１０１を含むメールに添付されてクライアント端末７０に送信される情報である。リスト情報１０２は、クライアント端末７０においてリスト表示１１２として表示される。

図７に一例として示すとおり、リスト表示１１２は、例えば流出可能性患者を抽出して一覧とし、患者を識別可能なＩＤや、患者の来院状況を視認することができるものとすることができる。具体例を挙げて説明すると、図７に示すとおり、リスト表示１１２は、患者ＩＤと、患者ごとの来院履歴が一覧として表示されるものとすることができる。また、リスト表示１１２は、例えば図７に示すとおり、患者が来院した月に丸印を示し、患者が来院した月と来院していない月とを一目で視認可能なものとしてもよい（来院した月を表示する枠内と来院していない月を表示する枠内とを別の色で表示するなど）。また、リスト表示１１２は、傷病名でのソートや、超過日数Ｎに応じて並べ替え可能なものとしてもよい。

カテゴリーマップ情報１０３は、クライアント端末７０にカテゴリーマップ表示１１３として表示される。カテゴリーマップ表示１１３は、各患者カテゴリーに区分される患者の人数を可視化して表示させるものである。本実施形態の来院管理装置３０は、カテゴリーマップ情報１０３を、患者カテゴリーごとの患者数を示すともに、カテゴリーの推移をイメージ化したカテゴリーマップ表示１１３として表示させる。

カテゴリーマップ表示１１３は、例えば図８に示すように、患者カテゴリー区分と当該患者カテゴリーに区分される患者の人数などを表示させ、超過日数の加算に応じて、流出患者に至る過程にある患者がどれぐらいいるのかを視覚化したもの（カテゴリーマップ表示１１３）とすることができる。

本実施形態のカテゴリーマップ表示１１３は、クライアント端末７０に表示されたカテゴリーマップ表示１１３の人数が表示されている人数表示ボタン１１３ａを、従事者Ｐがクリックするなどの操作を行うことにより、クリックされた人数表示ボタン１１３ａに係る患者カテゴリーの一覧が表示される。例えば、図８に示すカテゴリーマップ表示１１３の「流出可能性患者（２回以上来院）」に係る人数表示ボタン１１３ａ（１００人を示す「１００」の文字が表示されたボタン）をクリックすると、「流出可能性患者（２回以上来院）」に区分される患者のリストが表示される。

カテゴリーごとに表示可能とされる患者リストは、例えば、図５に示したリスト情報１０２を用いてもよいし、他のリストを別に生成可能としてもよい。

これにより、来院管理装置３０は、患者全体の来院状況や流出の可能性がある患者のボリュームを把握するとともに、各カテゴリーに区分される患者の傾向（緊急性の高い患者であるかなど）を把握することができる。また、このように来院管理装置３０は、流出患者に至る過程を段階的に区分して表示させるため、従事者Ｐが緊急性や重要性を判断する指標とすることができる。別の観点から説明すると、来院管理装置３０によれば、通院するか否かの判断を患者任せにせず、医療機関Ｘにおいてある程度管理することができる。その結果、来院管理装置３０は、患者の傷病の早期治療に貢献することが期待される。

詳細情報１０４は、詳細情報表示１１４としてクライアント端末７０に表示される。詳細情報１０４は、例えば医療機関Ｘのクライアント端末７０から来院管理装置３０にアクセスしてログインするなどの操作により、クライアント端末７０に表示可能なものとすることができる。言い方を換えれば、詳細情報１０４は、患者データベース４２ａの内容をクライアント端末７０の表示装置７６に表示させるための情報とすることができる。

図９に一例として示すとおり、詳細情報表示１１４は、例えば、患者ＩＤなど医療機関Ｘにおいて患者を識別可能なリストとして表示可能とするとともに、患者ごとの来院履歴や医療行為の履歴、処方箋の履歴など、レセプト情報Ｒｉに含まれる情報を患者ごとに網羅的に表示可能なものとすることができる。これにより、医療機関Ｘの従事者Ｐが、流出可能性患者など、患者ごとに診療内容や傷病の内容を確認して緊急性などを判断し、当該患者に対して来院を促す連絡を行うか否かなど、最終的に判断することができる。

メール送信部４７（情報送信部）は、来院管理情報１００の少なくとも一部を医療機関Ｘのクライアント端末７０に送信するために設けられている。本実施形態の来院管理装置３０は、来院状況概要情報１０１やリスト情報１０２を、インターネット８０を介して医療機関Ｘのクライアント端末７０に送信する。

表示制御部４８は、上述した詳細情報１０４やカテゴリーマップ情報１０３を、詳細情報表示１１４やカテゴリーマップ表示１１３として表示させる情報を送信するために設けられている。表示制御部４８からクライアント端末７０に対して各種の情報が送信され、クライアント端末７０（パーソナルコンピュータ７０ａやスマートフォン７０ｂ等）のブラウザを介して、各種情報に係る表示が表示される。

＜競合圏分析機能＞
続いて、来院管理装置３０が実現する競合圏分析機能について説明する。

来院管理装置３０は、医療機関Ｘ（第一の医療機関）が自院に来院する患者のうち、当該医療機関Ｘの近隣にある一又は複数の他の医療機関Ｘ（競合医療機関Ｘｃ）の診療圏内に在住する患者の動向を把握して、自院のマーケティング活動の指標とするためのものである。言い方を換えれば、来院管理装置３０は、医療機関Ｘがマーケティング的な視点で自院の患者の動向を看視することで、医療機関Ｘが客観的な観点で自院の強みや弱みを把握するために用いることができる。

なお、以下の説明では、来院管理装置３０により患者の動向を把握しようとする医療機関Ｘを、単に「自医療機関Ｘａ」（第一の医療機関）と記載して説明する場合がある。すなわち、本明細書における「自院」や「自医療機関」の文言は、来院管理装置３０や来院管理システム２００のユーザーを意味する。

また、自医療機関Ｘａ以外の医療機関Ｘを、単に「他医療機関Ｘｂ」と記載して説明する場合がある。さらに、他医療機関Ｘｂのうち、自医療機関Ｘａから所定の範囲内（近隣）にある医療機関Ｘを、「競合医療機関Ｘｃ」と記載して説明する場合がある。

すなわち、本明細書の記載において、「競合医療機関Ｘｃ」とは、自医療機関Ｘａ以外の医療機関Ｘのうち、近隣にある医療機関Ｘ全般を意味する。言い方を換えれば、本明細書中の「競合医療機関Ｘｃ」とは、自医療機関Ｘａと診療科目が共通するか、医療機関Ｘとしての態様（病院であるか、診療所であるかといった態様）が同じあるいは類似するか否かといった、自医療機関Ｘａと実際の競合関係にあるか否かは問わない。

競合圏分析部４６には、競合医療機関設定部５５、診療圏設定部５６、自院患者カテゴリー設定部５７、及び競合圏分析情報生成部５８が設けられている。

競合医療機関設定部５５は、競合医療機関Ｘｃを設定する。具体的には、医療機関データベース４２ｂに登録されている医療機関Ｘの中から、自医療機関Ｘａの所在地から所定の範囲内にある一又は複数の他医療機関Ｘｂを抽出し、「競合医療機関Ｘｃ」として設定する。すなわち、本明細書において、競合医療機関Ｘｃは、ひとつである場合や複数である場合が含まれる。

なお、自医療機関Ｘａからどの範囲内にある他医療機関Ｘｂを「競合医療機関Ｘｃ」として設定するかは、自医療機関Ｘａからの離間距離として選択可能な範囲を複数設けて自医療機関Ｘａの従事者Ｐが選択可能としてもよい。また、競合医療機関Ｘｃは、自医療機関Ｘａから所定の範囲内にある他医療機関Ｘｂを複数抽出して、さらに診療科目や規模などにより抽出して設定可能としてもよい。

診療圏設定部５６は、自医療機関Ｘａや競合医療機関Ｘｃの診療圏Ｒを設定する。具体的には、診療圏設定部５６は、上述の競合医療機関設定部５５により設定された競合医療機関Ｘｃから、所定の範囲を「競合診療圏Ｒｃ」として設定する。また、診療圏設定部５６は、自医療機関Ｘａから所定の範囲を「自院診療圏Ｒａ」として設定する。

なお、診療圏Ｒは、複数の選択肢の中から選択可能なものとしてもよい。また、診療圏Ｒは、少なくとも競合医療機関Ｘｃ（競合診療圏Ｒｃ）を設定するものとすれば、自医療機関Ｘａの診療圏Ｒを設定しないものとしてもよい。さらに、診療圏Ｒは、複数の選択肢が設けられるものであってもよい。例えば、診療圏Ｒは、「３００ｍ」、「５００ｍ」、「１ｋ」など、複数の距離を選択肢として提示可能として、医療機関Ｘの従事者Ｐの操作により選択されるものであってもよい（図１０参照）。

自院患者カテゴリー設定部５７では、自医療機関Ｘａの少なくとも一部の患者が複数のカテゴリーに区分される。より具体的に説明すると、本実施形態の来院管理装置３０では、自医療機関Ｘａの患者のうち、競合診療圏Ｒｃの範囲内に在住する患者を「競合圏内患者」として抽出する。言い方を換えれば、来院管理装置３０は、競合医療機関Ｘｃの所在地と自院の患者の在住地との位置関係により、競合圏内患者を抽出する。また、来院管理装置３０は、競合圏内患者として区分された患者のうち少なくとも一部の患者を、自医療機関Ｘａへの来院状況に応じて、「自院流入患者」や「自院流出患者」として区分する。

自院流入患者であるか自院流出患者であるかの判定は、来院管理装置３０の来院履歴機能によるものとしてもよい。具体的には、競合圏内患者のうち、来院履歴管理部４４の患者カテゴリー設定部５２により「継続患者」として区分される患者を「自院流入患者」と設定し、「流出可能患者」あるいは「流出患者」を「自院流出患者」として設定してもよい。

なお、自院流出患者であるいか否かの判定は、競合圏内患者の中から決定されるものとしてもよいし、競合圏内患者であるか否かに関わらず、自医療機関Ｘａの患者のうち最終来院日からある一定の期間を徒過した患者を自院流出患者として判定されるものであってもよい。

自院流入患者は、競合診療圏Ｒｃ内に在住する患者であり、自医療機関Ｘａにある程度継続して来院している患者である。すなわち、自院流入患者は、競合医療機関Ｘｃへの通院よりも自医療機関Ｘａへの通院を選択した患者であると推測することができる。そのため、複数の自院流入患者の属性（性別や年齢、在住地）や傷病内容等の傾向を把握することで、競合医療機関Ｘｃと比較した場合の自医療機関Ｘａの強み、あるいは競合医療機関Ｘｃの弱みを推測することができる。

自院流出患者は、自医療機関Ｘａにある程度継続して来院している患者である。すなわち、自院流入患者は、競合医療機関Ｘｃへの通院よりも自医療機関Ｘａへの通院を選択した患者であると推測することができる。そのため、複数の自院流入患者の属性（性別や年齢、在住地）や傷病内容等の傾向を把握することで、競合医療機関Ｘｃと比較した場合の自医療機関Ｘａの強み、あるいは競合医療機関Ｘｃの弱みを推測することができる。

競合圏分析情報生成部５８は、クライアント端末７０に表示させるための各種の情報を生成する。

具体的には、競合圏分析情報生成部５８は、自医療機関Ｘａの患者の分布や競合医療機関Ｘｃ、競合診療圏Ｒｃ等を地図上に表示させる患者分布マップ情報１０６を生成する。患者分布マップ情報１０６は、自医療機関Ｘａのクライアント端末７０に、ブラウザを介して患者分布マップ表示１１６として表示される。

図１０に一例として示すとおり、患者分布マップ表示１１６には、自院に来院する患者の在住地（位置情報）が患者アイコン１１６ａとして表示される。また、患者分布マップ表示１１６には、患者アイコン１１６ａのうち、自院流出患者と判定された患者の在住地が自院流出患者アイコン１１６ｂとして、自院流入患者と判定された患者の在住地が自院流入患者アイコン１１６ｃとして印付けとして表示される。

さらに、患者分布マップ表示１１６には、自院診療圏内Ｒａや競合診療圏内Ｒｃの範囲が示される。来院管理装置３０は、このように地図上に患者の分布や、競合診療圏Ｒｃや自医療機関Ｘａの位置を一元的に表示させることで、医療機関Ｘの従事者Ｐが流入患者や流出患者がどれぐらいのボリュームで存在するのか、また競合診療圏Ｒｃにどれぐらいの流入患者や流出患者が存在するのかといったことを把握可能となる。また、明らかに自院よりも競合医療機関Ｘｃに近い場所に在住しているにも関わらず、自院に継続して来院する患者の属性等を把握することで、自院の強みを推測することができる。

また、患者分布マップ表示１１６に表示される自院流出患者アイコン１１６ｂや自院流入患者アイコン１１６ｃを、従事者Ｐがクリックするなどの操作を行うと、患者属性情報データベース４２ｃに含まれる当該患者の属性や、患者データベース４２ａに含まれる傷病等が表示されるものとしてもよい。このような構成とすることで、特定の患者の属性等を確認することができる。

なお、患者分布マップ表示１１６には、自院流出患者の一覧（自院流出患者リスト１０７）や自院流入患者の一覧（自院流入患者リスト１０８）を表示可能としてもよい。例えば、図１０に示すとおり、患者分布マップ表示１１６に、リスト表示ボタン１１６ｄを設けて、従事者Ｐがリスト表示ボタン１１６ｄをクリックするなどの操作に基づき、これらのリストが表示されるものとしてもよい。また、自院流出患者リスト１０７や自院流入患者リスト１０８等は、患者分布マップ表示１１６にあらかじめ表示されているものとしてもよい。

また、自院流出患者リスト１０７や、自院流入患者リスト１０８に係る情報を生成してクライアント端末７０にブラウザを介して表示させる場合、これらのリストを、年齢や性別、傷病、流入あるいは流出したと推測される競合医療機関Ｘｃによりソート可能としたり、並べ替え可能としたりしてもよい。これにより、従事者Ｐが、自院流入患者や自院流出患者の傾向を把握しやすくなり、自院の強みや弱みの把握、あるいは競合医療機関Ｘｃの強みや弱みを推測することが容易となる。その結果、来院管理装置３０は、自医療機関Ｘａの強みを生かしたマーケティング活動を行う指標とすることができる。

＜来院管理プログラムが実行するステップについて＞
次に、来院管理プログラムが来院管理装置３０に実行させる来院周期設定処理（来院周期設定ステップ）、及び競合圏内患者抽出処理（競合圏内患者抽出ステップ）等の処理について、図１２〜図１４を参照しつつ説明する。

＜来院履歴情報更新処理＞
図１２は、来院管理装置３０が実行する来院履歴情報更新処理を示している。なお、来院履歴情報更新処理は、医療機関Ｘのクライアント端末７０からレセプトファイルＲｆを受信することに基づいて行われる。

（ステップＳ１０）
ステップＳ１０において、来院管理装置３０は、患者データベース４２ａを更新する処理を行う。具体的には、来院管理装置３０は、レセプトファイルＲｆに含まれるレセプト情報Ｒｉを患者ごとに紐付けられた情報として格納し、患者データベース４２ａを更新する処理を行う。ステップＳ１０の処理が終了すると、ステップＳ１１に処理が移行される。

（ステップＳ１１）
ステップＳ１１において、来院管理装置３０は、後で図１３を用いて説明する来院周期設定処理を行う。ステップＳ１１の処理が終了すると、ステップＳ１２に処理が移行される。

（ステップＳ１２）
ステップＳ１２において、来院管理装置３０は、来院基準日Ｄｂを設定する処理を行う。具体的には、来院管理装置３０は、患者データベース４２ａに蓄積されている情報（レセプト情報Ｒｉ）に基づいて、患者ごとに最終来院日Ｄａを抽出し、最終来院日ＤａにステップＳ２の処理で設定された来院周期Ｃの日数を加算した日を、来院基準日Ｄｂとして設定する。なお、来院基準日Ｄｂは、来院周期Ｃが設定されている患者（再診患者）に対して設定され、来院周期Ｃが設定されていない患者に対しては設定が行われない。ステップ１２の処理が終了すると、ステップＳ１３に処理が移行される。

（ステップＳ１３）
ステップＳ１３において、来院管理装置３０は、患者カテゴリー設定処理を行う。当該処理において、来院管理装置３０は、患者ごとに、最終来院日Ｄａから現在までの経過日数Ｎａや来院基準日Ｄｂからの超過日数Ｎに基づいて、「継続患者」や「流出可能性患者」等、区分する患者カテゴリーを決定する。ステップＳ１３の処理が終了すると、ステップＳ１４に処理が移行される。

（ステップＳ１４）
ステップＳ１４において、来院管理装置３０は、来院情報生成処理を行う。当該処理において、来院管理装置３０は、来院状況概要情報、カテゴリーマップ情報、詳細情報等の各情報を生成する処理を行う。ステップＳ１４の処理が終了すると、ステップＳ１５に処理が移行される。

（ステップＳ１５）
ステップＳ１５において、来院管理装置３０は、ステップＳ１４において生成された情報のうち、来院状況概要情報等の情報を、医療機関Ｘのクライアント端末７０に送信する処理を行う。ステップＳ１５の処理が終了すると、来院履歴情報更新処理を終了する。

＜来院周期設定処理＞
次に、図１３に基づいて、来院管理装置３０が実行する来院周期設定処理について説明する。なお、患者カテゴリー設定処理は、患者データベース４２ａに含まれる患者ごとに行われる。

（ステップＳ１１−１）
ステップＳ１１−１において、来院管理装置３０は、再診患者であるか否かについて判定する。具体的には、来院管理装置３０は、レセプト情報Ｒｉに含まれる診療内容や傷病等の情報等に基づいて、再来院を要する患者（再診患者）であるか否かを判定する。なお、再診患者であるか否かの判定は、レセプト情報Ｒｉと図３に示す来院周期決定テーブルとを参照して判定されるものであってもよい。再診患者であると判定された場合（ステップＳ１１−１＝ＹＥＳ）にはステップＳ１１−２に処理が移行され、要再診患者ではないと判定された場合（ステップＳ１１−１＝ＮＯ）には来院周期設定処理の処理を終了し、来院履歴情報更新処理のステップＳ１２に処理を移行する。すなわち、来院管理装置３０は、再診患者ではない場合には、来院周期Ｃを設定しない。

（ステップＳ１１−２）
ステップＳ１１−２において、来院管理装置３０は、特定の診療行為であるか否かについて判定する。具体的には、来院管理装置３０は、レセプト情報Ｒｉに含まれる診療行為の内容や傷病等の情報に基づいて、リハビリや検査等、特定の診療行為であるか否かを判定する。特定の診療行為であると判定された場合（ステップＳ１１−２＝ＹＥＳ）にはステップＳ１１−３に処理が移行され、特定の診療行為ではないと判定された場合（ステップＳ１１−２＝ＮＯ）にはステップＳ１１−４に処理が移行される。

（ステップＳ１１−３）
ステップＳ１１−３において、来院管理装置３０は、来院周期を設定する処理を行う。具体的には、レセプト情報Ｒｉと図３に示す来院周期決定テーブルとに基づいて、患者ごとに来院周期Ｃを設定する処理を行う。ステップＳ１１−３の処理が終了すると、来院周期設定処理の処理を終了し、来院履歴情報更新処理のステップＳ１２に処理を移行する。

（ステップＳ１１−４）
ステップＳ１１−４において、来院管理装置３０は、処方箋が処方されているか否かについて判定する。具体的には、来院管理装置３０は、レセプト情報Ｒｉに含まれる処方箋の情報に基づいて、処方箋が処方されているか否かを判定する。処方箋が処方されていると判定された場合（ステップＳ１１−４＝ＹＥＳ）にはステップＳ１１−５に処理が移行され、処方箋が処方されていないと判定された場合（ステップＳ１１−４＝ＮＯ）にはステップＳ１１−６に処理が移行される。

（ステップＳ１１−５）
ステップＳ１１−５において、来院管理装置３０は、来院周期を設定する処理を行う。具体的には、レセプト情報Ｒｉに含まれる処方箋日数に基づいて、患者ごとに来院周期Ｃを設定する処理を行う。ステップＳ１１−５の処理が終了すると、来院周期設定処理の処理を終了し、来院履歴情報更新処理のステップＳ１２に処理を移行する。

（ステップＳ１１−６）
ステップＳ１１−６において、来院管理装置３０は、来院周期を設定する処理を行う。具体的には、来院管理装置３０は、１ヶ月の来院周期Ｃを設定する処理を行う。ステップＳ１１−６の処理が終了すると、来院周期設定処理の処理を終了し、来院履歴情報更新処理のステップＳ１２に処理を移行する。

＜競合圏内患者抽出処理＞
次に、図１４に基づいて、来院管理装置３０が実行する競合圏内患者抽出処理について説明する。なお、競合圏内患者抽出処理は、患者データベース４２ａに含まれる患者ごとに行われる。

（ステップＳ２０）
ステップＳ２０において、来院管理装置３０は、競合医療機関Ｘｃを設定する。具体的には、来院管理装置３０は、自医療機関Ｘａの所在地と、医療機関データベース４２ｂとに基づいて、他医療機関Ｘｂの中で自医療機関Ｘａから所定の範囲内に所在する医療機関Ｘを競合医療機関Ｘｃとして設定する。ステップＳ２０の処理が終了すると、ステップＳ２１に処理が移行される。

（ステップＳ２１）
ステップＳ２１において、来院管理装置３０は、競合診療圏Ｒｃを設定する。具体的には、来院管理装置３０は、ステップＳ２０の処理で設定された競合医療機関Ｘｃから所定の範囲内を競合診療圏Ｒｃとして設定する。ステップＳ２１の処理が終了すると、ステップＳ２２に処理が移行される。

（ステップＳ２２）
ステップＳ２２において、来院管理装置３０は、競合圏内患者を抽出する。具体的には、来院管理装置３０は、患者データベース４２ａに含まれる患者のうち、ステップＳ２１の処理で設定された競合診療圏Ｒｃ内に在住する患者を競合圏内患者として設定する。ステップＳ２２の処理が終了すると、来院管理装置３０は競合圏内患者抽出処理の一連の処理を終了する。

以上、本発明の第一実施形態に係る来院管理装置３０、来院管理システム２００、及び来院管理プログラムについて説明したが、本発明は上述の実施形態に限定されない。

例えば、上述の実施形態に係る来院管理装置３０では、来院履歴管理機能及び競合圏分析機能の双方の機能を発揮可能なものとした例を示したが、本発明の来院管理装置は、来院履歴管理機能及び競合圏分析機能のいずれか一方の機能を発揮するものであってもよい。

また、上述の実施形態に係る来院管理装置３０では、競合圏分析機能において、競合圏内患者を流出する傾向にある患者（自院流出患者）であるか、定着する傾向にある患者（自院流入患者）であるかを判定可能とした例を示したが、本発明の来院管理装置はこれに限定されない。すなわち、本発明の来院管理装置は、適切な来院周期内での来院から流出する傾向にあるか適切な来院周期内での来院が定着する傾向にあるかの判定を行わず競合圏内患者を抽出可能としてもよい。

続いて、図１５を用いて、本発明の第二実施形態に係る通院管理装置（来院管理装置）および通院管理プログラム（来院管理プログラム）、及び通院管理方法の概略について説明する。

図１５は本発明の来院管理の概略を示す概念図である。

図１５に示すように、サーバ１は、ネットワーク３を介して複数の医療機関２と接続され、サーバ１と各医療機関２とは、ネットワーク３を介してデータ通信が可能である。

各医療機関２は、レセプトの情報であるレセプトデータ４を、ネットワーク３を介してサーバ１に送信する。

サーバ１は、受信したレセプトデータ４に含まれるデータを元に、医療機関２毎の医療履歴情報５と医療詳細情報６とを生成する。また、生成された医療履歴情報５は、対応する各医療機関２にメール等の手段により、ネットワーク３を介してサーバ１から送信される。

レセプトは各医療機関２により、毎月作成され、所定の公的機関に提出される。レセプトには、通院患者毎に、患者の個人情報や、病名、診療内容等の医療履歴が記載される。レセプトデータ４は、このようなレセプトの情報をまとめたデータであり、公的機関に提出するために、レセプトの情報を一定のフォーマットに統一されたデータである。

医療履歴情報５および医療詳細情報６は、受信したレセプトデータ４を元にサーバ１にて情報を整理して作成される。医療履歴情報５（来院履歴情報）は、医療機関２毎に生成された、患者の通院状況等の通院履歴が患者毎に整理された情報である。医療詳細情報６は、医療機関２毎に生成され、通院履歴に加え、各患者の個人情報や、病名、診療内容等の医療履歴が詳細に整理された情報である。医療詳細情報６は、同一の医療機関２の医療履歴情報５と関連付けられてリンクしており、サーバ１内に保存されている。後に詳述するように、医療機関２の医師等は、受け取った医療履歴情報５を解析し、さらに、医療履歴情報５を介してサーバ１内の医療詳細情報６の内容を閲覧して、より詳細に患者の通院状況を解析することができる。

以上のように、各医療機関２は、特別なデータの作成や、入力処理を行うことなく、後に詳述するように、通常の業務において作成されるレセプトデータ４をサーバ１に送信するのみで、医療履歴情報５等を作成するためのデータをサーバ１に提供することができる。一般的に、サーバ１等にデータの整理をさせるような装置においては、サーバが処理できるようなフォーマットでデータを別途作成し入力する必要があった。これに対して本発明においては、サーバ１は、通常の業務において作成されるレセプトデータ４を解読・解析・整理できるように構成され、これにより、余分な処理を行うことなく、サーバ１にデータを入力することが可能となる。

また、各医療機関２は、患者毎に患者の通院状況等が整理された医療履歴情報５を、メール等により、医療機関２からはいかなる処理を行うことなく、自動的かつ定期的にサーバ１から受信することができる。一般的に、サーバ１等にデータの整理をさせるような装置においては、医療機関２の医師等の使用者が、サーバにアクセスし、サーバで生成した各種情報を取得あるいは閲覧する必要があった。これに対して本発明においては、医療履歴情報５が定期的にサーバ１から送信されるため、医療機関２の医師等の手間がかからず、医療履歴情報５の取得忘れ等が発生する恐れがない。また、患者の適切な治療予定を立てるのに最低限必要な、患者の通院状況等の情報を定期的に入手できるため、定期的に送信される医療履歴情報５のみからだけでも、ある程度の患者の治療予定を立てることができる。さらに、後に詳述するように、送信された医療履歴情報５とサーバ１内の医療詳細情報６とはリンクしており、医療機関２の医師等は医療履歴情報５を操作することによりサーバ１内の医療詳細情報６を閲覧することができ、患者のより詳細な情報や、レセプトデータ４を詳細に解析した情報等を確認し、各患者の状況を詳しく確認して、容易に患者の最適な治療予定を立てることができる。

また、以上のように、必要な情報を簡単に入力すると共に、解析結果を自動的に入手しながら、患者の治療予定を容易に立てるのみならず、後に詳述するように、医療機関２と各患者の所在地との位置関係等から、患者を獲得するマーケティング活動（以下、集患とも称す）を行うことも可能である。

（第二実施形態）
次に、本発明の第二実施形態に係る通院管理方法、通院管理装置（来院管理装置）および通院管理プログラム（来院管理プログラム）に係る具体例について、図１５〜図２１を用いて詳細に説明する。

まず、図１６〜図２０を用いて、第二実施形態に係る通院管理装置（来院管理装置）におけるサーバの構成について説明する。図１６は本発明の通院管理装置が設けられるサーバの構成を例示するブロック図であり、データの流れが明確になるように示している。図１７はレセプトデータに含まれる情報を例示する図、図１８は第二実施形態に係る医療履歴情報を例示する図、図１９，２０は第二実施形態に係る医療詳細情報を例示する図である。

図１６に示すように、サーバ１は、ＣＰＵ７等の情報処理装置と、メモリ８等の記憶装置と、ネットワーク３（図１５参照）と接続されてデータの送受信を行う送受信器９と、ネットワーク３（図１５参照）と接続されて、ネットワーク３（図１５参照）上の他の機器等のブラウザ等にブラウザ等を制御するデータを送信し、情報を表示させる表示制御装置１０と、ＣＰＵ７を動作させるプログラム１１とから構成される。

サーバ１において、レセプトデータ４は各医療機関２（図１５参照）から送受信器９を介して受信され、メモリ８に記憶される。医療履歴情報５および医療詳細情報６は、ＣＰＵ７がそれぞれのレセプトデータ４を読み込み、解読・整理・解析することによって、医療機関２（図１５参照）毎に生成される。生成された医療履歴情報５および医療詳細情報６はメモリ８に記憶される。送受信器９は、各医療機関２（図１５参照）からレセプトデータ４を受信し、対応する医療機関２に医療履歴情報５を送信する。また、送受信器９は、各医療機関２（図１５参照）において、医療履歴情報５を介した操作に係る情報を受信する。受信された情報に基づいて、ＣＰＵ７は医療詳細情報６にアクセスし、表示制御装置１０から、医療履歴情報５を介した操作に対応する情報を、対応する医療機関２（図１５参照）に送信し、医療機関２のブラウザ等に操作に対応するデータを表示させる。プログラム１１は、ＣＰＵ７にサーバ１の動作をさせるプログラムであり、ＲＯＭ等の記憶装置（図示せず）に格納されても良いし、メモリ８に格納されても良い。

なお、図１６の例では、サーバ１が各医療機関２（図１５参照）との間で、レセプトデータ４や医療履歴情報５の送受信、医療履歴情報５を介した操作に係る情報を受信、その操作に対応する情報の送信等の送受信を行うと共に、レセプトデータ４の整理・解析および医療履歴情報５および医療詳細情報６の生成を行う構成としたが、データの送受信に係るデータ通信構成と、レセプトデータ４の整理・解析および医療履歴情報５および医療詳細情報６の生成を行うデータ処理構成とを分けた構成とすることもできる。この場合、データ通信構成とデータ処理構成とがデータ通信可能な状態で接続されていれば良い。また、送受信器９と表示制御装置１０とを別々に構成する例を示したが、送受信器９に、ネットワーク３（図１５参照）上の他の機器等に設けられたブラウザ等を制御するデータを送信する機能を付与しても良い。

レセプトデータ４（図１５参照）は、例えば、図１７に示すように、対応する医療機関２（図１５参照）毎に、通院した患者名と患者の個人情報、診療履歴等が患者毎の情報として記載されている。具体的には、レセプトデータ４（図１５参照）には、患者の個人情報として、保険者番号、生年月日、年齢、性別、住所が含まれる。また、診療履歴として、来院日等の通院履歴と、来院日における診療区分、診断された病名、診療内容、薬が処方された場合には、処方された薬の名称と処方された日数等の医療履歴が含まれる。

例えば、図１７の例では、「鈴〇二郎」の住所等の個人情報と、診療履歴として、平成２９年８月１日、平成２９年８月４日、平成２９年８月８日に来院し、いずれも、腎不全と診断されて人工透析が施された旨がレセプトデータ４（図１５参照）の内容として含まれる。

なお、図１７は、レセプトデータ４（図１５参照）に記載されている情報を整理した表である。なお、レセプトデータ４（図１５参照）はこのような表の形式に限らず、情報が分かりやすく整理されていれば任意の形式である。一般的にレセプトデータ４（図１５参照）はＣＳＶ形式の一定のフォーマットで作成し、所定の機関に提出される。そのため、サーバ１に送信するデータをこの形式とすれば、所定の機関に提出するレセプトデータ４（図１５参照）を流用し、別途送信用のデータを作る必要がなく便利である。

医療履歴情報５は、レセプトデータ４（図１５参照）をサーバ１（図１５参照）に送信することにより、対応する各医療機関２（図１５参照）にメール等により送信される、レセプトデータ４（図１５参照）の内容を整理した情報である。医療履歴情報５は、患者毎に、該当月においていつ来院したかが分かる情報である。具体的には、図４に例示するように、横軸に日付、縦軸に患者名を記載した表であり、表における各患者の行（横軸）の来院した日付の部分に来院したことが分かる印として、例えば星印を記載する。図１８の例において、「鈴〇二郎」は、１日，４日，８日に来院し、「●田太郎」は、３日，７日に来院し、「山〇花子」は、４日に来院し、「佐藤△子」は、４日，１１日，１８日に来院したこと等が分かる。

このように、患者の通院履歴が明確となるため、医療履歴情報５を受信した医療機関２（図１５参照）の医師等は、来院の日程、来院間隔を、患者毎に容易に把握することができ、患者に合った通院予定を的確かつ容易に検討し、決定することができる。また、このような医療履歴情報５を、医師等はメール等により、定期的にかつ自動的に受け取ることができる。このような整理した情報を提供するシステムがあったとしても、通常は、医師自らシステムにアクセスし、整理した情報を閲覧する必要があった。しかしながら、通常医師は多忙であり、来院する患者を診療することに重点をおいており、通院時に、次回以降の診察予定を考慮することがあったとしても、予定通り来院したかどうかを確認し、来院しなかった患者に対して来院を促す等の対処を行うことは困難であり、あえて、システムにアクセスして患者の来院状況を確認し、対処することまでを行わないことが一般的であった。これに対して、患者の通院履歴が明確となる医療履歴情報５を、メール等により直接的に受け取ることにより、医師等は、患者毎の通院履歴を確認し、来院の有無の確認を行い、治療の計画をたてるきっかけとすることができるようになる。結果として、患者の通院を医師が管理して、最適な日程で通院することを促すことが可能となり、的確な治療を施すことができ、最善の治療を行うことが可能となり、早期かつ的確に病気等を完治することが望めるようになる。

また、通院履歴から通院予定日を予測し、通院予定日に来院していない場合は、その日に印をつけても良い。図１８の例では、１７日に送信された医療履歴情報５であるとし、通院予定日をすぎて来院していない場合はＸ印をつけ、経過していない通院予定日は〇印をつけている。このように、通院予定日に来院していない場合に印をつけて、通院が滞っていることを明確にすることにより、最適な日程で通院することを促すことがより容易となる。なお、通院予定日は、あらかじめ定めた様々な方法で決定することができる。例えば、「鈴〇二郎」は、１日，４日，８日に来院しており、３〜４日毎に、あるいは、毎火曜日と金曜日に来院していることが分かる。そのため、１１日金曜日は通院予定日であると予測することができる。そして、通院予定日である１１日金曜日に来院していないため、Ｘ印をつける。また、「●田太郎」は、レセプトデータ４（図１５参照）から、前回の来院の際に３日分の薬が処方されていることが分かる。そたのめ、前回通院日の７日から、遅くとも４日後に来院することが予想され、１１日を通院予定日とすることができる。そして、通院予定日である１１日に来院していないため、Ｘ印をつける。このように、通院予定日は、来院の間隔や薬の処方に応じて予想することができる。さらには、病名や診療内容に応じて通院予定日を予想することもできる。例えば、「鈴〇二郎」の病名は腎不全であり、診療内容は人工透析である。腎不全の場合、少なくとも４日毎に人工透析を行わないと生命に危険が生じる。そのため、８日に人工透析を行った後は、遅くとも１１日に人工透析を行う必要がある。そのため、１１日が通院予定日となる。また、「佐藤△子」の病名は花粉症であり、処方は７日分である。花粉症の場合、季節の変化で症状が治まることも考えられるが、症状が出ている場合は、薬の効果により症状を抑えることができる。そのため、１８日に７日分の薬を処方した場合は、２５日が通院予定日となる。ただし、花粉症は命に甚大な影響があることは少ないので、通院予定日をある程度の幅を持って推定することができる。そのため、通院予定日を２３日〜２８日とすることができる。逆に、「山〇花子」は、健康診断として内視鏡検査を行っている。健康診断や術後の検査のための内視鏡検査の場合は、１年〜半年に一度の検査で十分な場合が多い、そのため、通院予定日は設定しなくても良いし、長いスパン、例えば、１年後や半年後に設定しても良い。また、「●田太郎」の病名はかぜであり、最後に治療として注射を行っている。かぜやインフルエンザの場合、注射により劇的に症状が回復し、以降の通院が不要となる場合がある。そのため、かぜやインフルエンザで注射を行った場合は、通院予定日を設定しなくても良い。以上のように、病名や治療の内容、投薬の状況、あるいは病気の深刻度等によって、一定の通院予定日を設定することができ、通院予定日に来院していない場合に印をつけて、通院が滞っていることを明確にすることにより、最適な日程で通院することを促すことがより容易となる。

また、通院予定日に伴う印は全ての患者に対して必ず付与しても良いが、再度来院する必要性が低いと判断される場合は、印を付与しなくても良い。例えば、病名や診療内容に応じて、印の付与を要するものと要さないものとを判断しても良い。例えば、診療内容が人工透析の場合は継続して診療を行う必要があるので印を付与し、病名がかぜやインフルエンザ、検診等の場合は早期に病状が改善する可能性が高かったり、次回の診療までの期間が長かったりする場合があるので、印を付与しないとすることもできる。

また、医療履歴情報５は、月に一度ではなく、週に一度や、毎日送信しても良い。例えば、「鈴〇二郎」は、腎不全により人工透析を受けている。そのため、通院予定日である１１日に来院しなかったことを次月に知ったとしても、遅すぎる場合がある。そのため、医療履歴情報５の送信頻度を高くしても良い。また、少なくとも一部の状況の患者の医療履歴情報５のみ、高い頻度で送信し、その患者を含む全ての患者の医療履歴情報５は月に一度送信するようにすることもできる。この状況の判別については、病状や治療履歴、病名等によってあらかじめ定めておくことができる。

医療詳細情報６は、サーバ１（図１５参照）に記録されている、レセプトの情報が解析・整理・解析されたデータデータであり、医療履歴情報５または医療履歴情報５が添付されたメール等を操作することにより閲覧することができる。医療詳細情報６は様々な表示形態で表示することができ、以下にその例を示す。

例えば、図１９に示すように、医療詳細情報６は、患者毎の通院履歴やその際の診療内容、処方内容、あるいは病名等の医療情報が詳細にまとめられた情報である。このような患者毎の詳細情報を開示する医療詳細情報６は、例えば、医療履歴情報５（図１８参照）の患者名をクリックすることにより、医師等が使用しているＰＣのブラウザ等を介して表示することができる。もちろん、ブラウザ等を介さず、テキストあるいはｐｄｆデータ等を表示させることもできる。

このように、医療履歴情報５（図１８参照）を確認しながら、患者の処方内容や病名等の詳細を参照することにより、通院予定日の信憑性や重要性を考慮して、通院予定日を医師自ら判断し、適切な治療予定をたてることができると共に、通院予定日に来院していない場合は、重篤性を考慮して、患者に直接来院を促す連絡を行う等の対処を行うことが可能となる。例えば、人工透析の予定日に来院していない場合には、それが重篤な結果を招く可能性が高いので、即刻患者に連絡を取ることができる。また、検査結果が出ているにもかかわらず、通院していない場合、検査結果を確認し、結果に応じて連絡を行う必要があるか否かの判断をすることもできる。

また、図２０（ａ）に示すように、医療詳細情報６として、医療履歴情報５（図１８参照）を通院予定日から経過した日数が多い順に表示したデータを表示しても良い。このような医療詳細情報６についても、医療履歴情報５（図１８参照）または医療履歴情報５（図１８参照）が添付されたメール等を操作することにより、ブラウザ等を介して表示させることができる。例えば、メールに医療詳細情報６を表示するリンクを付与することもできるが、送信されたメールからブラウザを介して医療履歴情報５（図１８参照）を表示するようにし、医療履歴情報５（図１８参照）と共に、医療詳細情報６を表示するためのスイッチ１２をブラウザ上に表示させ、スイッチ１２をクリックすることにより、医療詳細情報６を表示するようにしても良い。具体的には、医師等は、送信されたメールから、ブラウザ上に図１８に示すような医療履歴情報５を表示させることができる。ブラウザ上にはスイッチ１２も表示されている。医師等は、スイッチ１２をクリックすることにより、図２０（ａ）に示すような医療詳細情報６を表示させることができる。

図２０（ａ）に例示される医療詳細情報６は、医療履歴情報５（図１８参照）を通院予定日が早い順に並べ替えた情報である。図２０（ａ）に示す例では、当月において、最も通院予定日が早い「鈴〇二郎」は１１日に通院予定であったが来院しなかったため、１１日にＸ印がつけられている。「●田太郎」も１１日に通院予定であったが来院しなかったため、１１日にＸ印がつけられている。また、「佐藤△子」は２５日が通院予定であるが、２５日を経過していないので〇印が付されている。また、医療詳細情報６においては、通院予定日が推測されていない患者については、リストアップしない。上述のように、検診や今後の治療を要さないと予想される状況である患者については、通院予定日が設定されず、医療詳細情報６にも表示されない。そのため、「山〇花子」は医療詳細情報６としてリストアップされない。

このように、医療詳細情報６として、医療履歴情報５（図１８参照）を通院予定日が早い順に並べ替えることにより、通院の管理をすべき患者を容易に識別することができ、最適な治療計画が実施されているかを判断することが容易となり、通院予定日に来院していない場合は、重篤性を考慮して、患者に直接来院を促す連絡を行う等の対処を行うことが容易となる。

また、別の医療詳細情報６の例として、治療予定を管理する必要性の高い、通院緊急度の高い患者の順に医療履歴情報５（図１８参照）を並べ替えた情報がある。この順番は、病名や診療内容に基づいて優先順位をあらかじめ定め、優先順位に応じて決定している。図２０（ｂ）に示す例では、当月において、「鈴〇二郎」は診療内容が人工透析であり、診療を要する緊急度が高いため、リストの上位に記載されている。「佐藤△子」より「●田太郎」の方が通院予定日が早いが、「●田太郎」は病名がかぜであり、治療の継続性が低い可能性が高いのに対し、「佐藤△子」は病名が花粉症であり、治療の継続性が高いため、「佐藤△子」の方が治療予定を管理する必要性の高いと判断されている。また、このような医療詳細情報６においても、治療予定を管理する必要性のほとんどない患者については、リストアップしない。上述のように、病名や診療内容等から検診や今後の治療を要さないと予想される状況である患者については、通院予定日が設定されず、医療詳細情報６にも表示されない。そのため、診療内容が内視鏡検査であった「山〇花子」は医療詳細情報６としてリストアップされない。

このように、医療詳細情報６として、病名や診療内容に基づいて優先順位をあらかじめ定め、優先順位に応じて、治療予定を管理する必要性の高い病名や診療内容の順に医療履歴情報５（図１８参照）を並べ替えることにより、通院の管理をすべき患者をより容易に識別することができ、最適な治療計画が実施されているかを判断することが容易となり、通院予定日に来院していない場合は、重篤性を考慮して、患者に直接来院を促す連絡を行う等の対処を行うことが容易となる。

このような医療詳細情報６についても、医療履歴情報５（図１８参照）または医療履歴情報５（図１８参照）が添付されたメール等を操作することにより、ブラウザ等を介して表示させることができる。例えば、メールに医療詳細情報６を表示するリンクを付与することもできるが、送信されたメールからブラウザを介して医療履歴情報５（図１８参照）を表示するようにし、医療履歴情報５（図１８参照）と共に、医療詳細情報６を表示するためのスイッチ１３をブラウザ上に表示させ、スイッチ１３をクリックすることにより、医療詳細情報６を表示するようにしても良い。具体的には、医師等は、送信されたメールから、ブラウザ上に図１８に示すような医療履歴情報５を表示させることができる。ブラウザ上にはスイッチ１３も表示されている。医師等は、スイッチ１３をクリックすることにより、図２０（ｂ）に示すような医療詳細情報６を表示させることができる。

なお、図１８，２０に例示されるような医療詳細情報６において、診療予定に伴い特に通院が望まれる通院予定日については、明確となるような印を別途付与しても良い。印としては、赤色等の目立つ色の印を付したり、点滅させたり、コメントを表示できるようにしても良い。このように特に通院が望まれる通院予定日は、病名や診療内容等に応じて一定の基準で自動的に付与するようにしても良いし、医師等が手動で付与するようにしても良い。また、明確な印は、通院予定日を超過した場合に付しても良い。

他の医療詳細情報６として、あらかじめ定めた１または複数の病名や診療内容に対応する患者についてのみ、通院履歴を通院予定日と共に表示しても良い。また、最後に行った診療内容毎に並べても良い。また、医者等の操作により、任意の条件で医療詳細情報６を表示させることもできる。また、通院予定日をあらかじめ定めた条件で設定しても良いが、継続したデータ収集による統計的処理により、通院予定日を設定する条件を随時更新していくこともできる。これらの統計的処理は、患者毎に統計を取っても良いし、病名あるいは診療内容毎に統計を取っても良い。また、医療詳細情報６は、サーバ１にて患者の通院履歴や医療履歴を解析した結果得られる、通院予定や治療予定等の推奨計画を提案事項として含んでも良い。

次に、図１５〜図２１を用いて、第二実施形態に係る通院管理方法および通院管理プログラム（来院管理プログラム）について説明する。なお、以下の説明では、サーバ１における動作を、プログラム１１の指示によりＣＰＵ７が制御して行うが、任意の方法で、通院管理方法を実現することができる。

図２１は第二実施形態に係る通院管理方法の工程を説明するフロー図である。

まず、各医療機関２からサーバ１にレセプトデータ４がネットワーク３を介してアップロードされる。レセプトデータ４のアップロードは、単にサーバ１にレセプトデータ４をデータ転送することにより行っても良いし、医療機関２にて専用のサイトを開くことによりサーバ１にアクセスし、レセプトデータ４をアップロードしても良い。レセプトデータ４は、図１７に例示されるような情報を含むデータである（ステップ１）。

次に、プログラム１１はＣＰＵ７を制御して、送受信器９によりレセプトデータ４を受信させ、メモリ８に各医療機関２から受信したレセプトデータ４を格納させる（ステップ２）。

次に、プログラム１１はＣＰＵ７を制御して、各レセプトデータ４から、医療機関２毎の医療履歴情報５および医療詳細情報６を生成させる。生成された医療履歴情報５および医療詳細情報６は、メモリ８に格納される（ステップ３）。上述のように、医療履歴情報５は、レセプトデータ４の情報の内、通院履歴を患者毎に整理・解析したデータである。また、医療詳細情報６は、医療履歴情報５と関連付けられた情報であり、患者毎の通院履歴や診療履歴、病名等の医療履歴の詳細な情報や、通院予定日とその緊急度等を整理・解析したデータである。

次に、プログラム１１はＣＰＵ７を制御して、送受信器９から各医療機関２に、対応する図１８に例示されるような医療履歴情報５をメール等により送信させる（ステップ４）。医療履歴情報５の送信は、各医療機関２が操作を行うことなく自動的に、定期的に行われ、月に１度送信しても良いし、週に１度送信しても良く、毎日でも良い。送信の間隔は一定であることに限らず、各医療機関２の要望に応じて、医療機関２毎に決めても良い。

次に、各医療機関２では、医師等が、送信された医療履歴情報５を受信し、予定通りに患者が来院しているかを検討する。具体的には、上述のように、医療履歴情報５には、各患者の通院履歴と通院予定日とが記載されている。医師等は、医療履歴情報５から各患者の通院履歴と通院予定日とを確認し、各患者がいつ来院しており、通院予定日に来院しているか否かを確認する。そして、通院予定日に来院していない場合、直接患者に来院を促す等の処理を行うことができる（ステップ５）。なお、医療履歴情報５は、メール等に添付しても良いし、メール等の本文に記載しても良い。あるいは、メール等に記載されているＵＲＬから、ブラウザで表示された専用のＷｅｂページにアクセスし、医療履歴情報５を表示させる構成でも良い。

次に、各医療機関２では、医師等が、送信された医療履歴情報５を操作し、図１９，２０に例示されるような医療詳細情報６を閲覧する。医療詳細情報６は、上述のように、例えば、図１９に示すような、各患者の詳細な通院履歴や、病名、診療内容、薬の処方内容等の医療履歴である。図１９に例示されるような医療詳細情報６は、例えば、医療履歴情報５の患者名をクリックすることにより表示させることができる。この際、サーバ１は、送受信器９を介して患者名がクリックされた情報を受信し、この受信した情報に応じて、プログラム１１はＣＰＵ７を制御して、対応する医療詳細情報６を読み出させ、表示制御装置１０を介して対応する医療機関２のＰＣのブラウザ等に医療詳細情報６を表示させるための信号を送信させる。このような医療詳細情報６と医療履歴情報５とを参照しながら、医師等は、各患者の詳細な診療履歴等を考慮して、患者の通院の必要性をより正確に判断し、通院予定や治療予定を的確に判断することができる。そのため、患者が適切に通院していないときは通院を促し、適切な治療を行うことができるので、早期の完治に資することが可能となる。また、医療詳細情報６は図２０に例示されるように、通院予定日が早い患者の順に各患者の通院履歴を表示したものや（図２０（ａ））、治療予定を管理する必要性の高い患者の順に通院履歴を表示したもの（図２０（ｂ））等とすることができる。図２０に例示されるような医療詳細情報６は、例えば、メール等に表示されたリンクや、ブラウザで表示された医療履歴情報５に付加されるスイッチ１２，１３等をクリックすることにより表示させることができる。この際、サーバ１は、送受信器９を介してスイッチ１２がクリックされた情報を受信し、この受信した情報に応じて、プログラム１１はＣＰＵ７を制御して、対応する医療詳細情報６を読み出させ、表示制御装置１０を介して対応する医療機関２のＰＣのブラウザ等に医療詳細情報６を表示させるための信号を送信させる。このような医療詳細情報６を参照することにより、医師等は、各患者の詳細な治療の進行状況や病状等を考慮して、患者の通院の必要性をより正確に判断し、通院予定や治療予定を的確に判断することができる。そのため、患者が適切に通院していないときは通院を促し、適切な治療を行うことができるので、早期の完治に資することが可能となる（ステップ６）。

そして、判断結果により、医師等は、治療予定をより最適に見直したり、来院していない患者に直接連絡をする等して、最適な治療を行うことができるように、患者に来院をうながしたりすることができる。これにより、最適な治療を行うことを促進し、さらに、患者が適切に通院していないときは通院を促し、適切な治療を行うことができるので、早期の完治に資することが可能となる（ステップ７）。

以上のように、通院管理方法、通院管理装置および通院管理プログラムによると、サーバ１に通院管理を行わせるに際し、医療機関が通常、定期的に作成するレセプトデータ４を、サーバ１にアップロードすることにより、特別なデータの作成や入力作業等が必要なくなり、容易かつ正確にサーバ１に必要な情報を提供することが可能となる。なお、レセプトは、一般的に特定のフォーマットで暗号化されている。そのため、サーバ１は、アップロードされたレセプトデータ４を復号化する機能を有することが好ましい。これにより、通常業務として随時作成しているレセプトをそのまま使用することが可能となり、より容易かつ正確にサーバ１に必要な情報を提供することができる。

また、医療履歴情報５は、定期的かつ何の手続を行うことなく自動的に、サーバ１からメール等で直接各医療機関２に送信される。そのため、医師等は、医療履歴情報５を入手するための特別な手続を行うことなく、手間なく医療履歴情報５を確認することができる。また、定期的に医療履歴情報５が送付されるため、医師等は、失念することなく医療履歴情報５を確認する機会を得ることができ、確実に患者の通院管理を行うことができる。

また、医師等は、送信された医療履歴情報５を操作することにより、容易に医療詳細情報６を閲覧することができる。医療詳細情報６の閲覧は、医療履歴情報５において、患者名をクリックしたり、スイッチ１２，１３等をクリックしたりするだけで様々な形式で整理された情報を容易に確認することができる。そして、医療履歴情報５を確認することに加えて、より詳細な医療詳細情報６をすることにより、より適切な治療予定を検討することができ、患者が通院することの必要性とその予定日を、より最適に確認することができる。そのため、患者が適切な日程で通院していなかったり、通院を止めてしまったりしている場合に、患者に直接連絡する等して、適切な治療の継続を促すことができ、最適な治療を行い、早期に病気を完治させる可能性を向上させることができる。

なお、以上の説明では、ネットワーク３を介してレセプトデータ４のアップロードや、医療履歴情報５の送信を行う例を示したが、その他の通信手段を用いてデータ転送を行っても良く、専用回線で医療機関２とサーバ１との間の送受信を行っても良い。

また、上記説明した医療履歴情報５および医療詳細情報６を用いることにより、患者の通院履歴や治療予定を管理することができるが、さらに、患者を確保し、患者を集める、医療機関２におけるマーケティング（集患とも称す）を行うこともできる。すなわち、医療履歴情報５により各患者の通院履歴を確認できると共に、医療詳細情報６により、通院している患者の住所や病名・診療内容を詳しく確認することができる。そのため、医療機関２を中心に各患者の所在地の分布や、他の医療機関との位置関係、あるいは、通院を続けている患者の病名・診療内容と通院しなくなった患者の病名・診療内容との関係等を分析することにより、通院を継続している患者の傾向と通院をしなくなった患者の傾向とを分析し、集患に活かすことが可能となる

（第三実施形態）
第二実施形態において、医療機関におけるマーケティング（集患とも称す）に医療履歴情報および医療詳細情報を用いることについて説明した。以下、第三実施形態として、より集患活動に便利な医療履歴情報および医療詳細情報について、図２２，２３および図１８〜２０を用いて説明する。なお、第三実施形態において、医療履歴情報および医療詳細情報以外の構成は第二実施形態と同様であり、説明を省略する。

図８は実施の形態２に係る医療履歴情報を例示する図、図９は実施の形態２に係る医療詳細情報を例示する図である。

図２２に示すように、第三実施形態における医療履歴情報１５は、地図上の中心に、集患の対象となる医療機関のマーク（以下、当院１４とも称す）を配置し、来院した患者の所在地にマーク（以下、患者１６とも称す）を付している。さらに、地図上に同様の診療科目の診療を行う他の医療機関のマーク（以下、他院１７とも称す）を付すこともできる。また、医療履歴情報１５は実施の形態１と同様に、医療機関２（図１５参照）に定期的に送信され、医療履歴情報５に代わり、または医療履歴情報５と共に送信される。

医師等は、受信した医療履歴情報１５を操作して、医療詳細情報を閲覧することができる。医療詳細情報は、例えば、図１９に示すような患者毎の詳細情報を示す医療詳細情報６であり、医療履歴情報１５の１つの患者１６をクリックすること等により表示される。また、医療詳細情報として図１９に示す医療詳細情報６の情報に加え、図１８，２０に示すような、患者の通院日の通院予定日とが、カレンダー状態で表示される情報を含んでも良い。ここで、患者１６として表示される来院患者として、送信したレセプトデータ４（図１５参照）の対象月の来院患者を表示しても良いし、医師等の操作により、過去数ヶ月の来院患者や過去来院した全ての患者について表示することもできる。

医療履歴情報１５を操作して閲覧することができる医療詳細情報として、他に、来院した患者の病名や診療内容それぞれの合計数を表示したり、病名や診療内容毎に患者の詳細情報をソートした情報を表示したりさせることができる。また、病名や診療内容ごとに、患者１６の形状や色を異ならせ、該当する病名や診療内容の患者の分布を確認することもできる。

例えば、図２３（ａ）に例示される医療詳細情報１８は、来院した全ての患者の病名の統計をとり、病名毎の来院数が多い順に、病名と来院数を表示した情報である。このような情報を表示させることにより、医師等は、自身の医療機関２（図１５参照）に、どのような病気の患者が多く来院し、どのような病気の患者が来院しないかを、一般的な病気の発生統計からの比較で確認することができる。

また、図２３（ｂ）に例示される医療詳細情報１９は、病名毎に、患者の氏名，年齢，性別，診療内容，通院履歴を並べて表示した情報である。このような情報を表示させることにより、医師等は、自身の医療機関２（図１５参照）に来院している患者を病名毎に確認し、さらにそれらの患者の詳細な情報を確認することができる。そのため、自身の医療機関２に来院している患者の個人情報や治療状況を確認し、来院した患者の傾向をより細かく検討することができる。

図２３に例示される医療詳細情報１８，１９は、医師等が、医療履歴情報１５におけるスイッチ２０をクリックすることにより、条件の表示画面や条件の選択画面が表示され、条件を入力したり、選択したりすることにより表示される。また、医療詳細情報１８，１９は医療履歴情報１５に表示される全ての患者に対して集計された情報であっても良いが、医療履歴情報１５の地図上において、一定の範囲を選択し、その範囲内の患者に対して集計された情報とすることもできる。範囲を指定する際には、例えば、図２２に例示される医療履歴情報１５を操作して、領域円２３を表示、拡大・縮小し、領域円２３で囲まれた範囲内の患者について集計を行うこともできる。

次に、医療履歴情報５，１５および医療詳細情報６，１８，１９を用いた、医療機関における解析例を示す。

まず、図１８に例示する医療履歴情報５や図１９に例示する医療詳細情報６を確認することにより、各患者の通院状況を確認し、通院されるべき日に通院し、通院予定日を過ぎても通院していない患者の有無を確認することができる。特に、通院予定日を過ぎても通院していない患者については流出した患者と認識し、図１９に例示する医療詳細情報６をさらに確認することにより、流出原因を解析することができる。例えば、流出した患者の多くが、同じ病気や診療内容の場合、医療機関２（図１５参照）がその病気や診療内容に対して評判が良くない可能性があり、その点を改善する方策を検討する等を行い、患者の流出を最低限に抑制することができる。また、流出した可能性のある患者に、来院を促す連絡を行うこともできる。

また、図２２に例示する医療履歴情報１５を確認することにより、来院する患者の地図上の分布（以下、マップ情報とも称す）を確認することができる。これにより、近隣の住民のみが来院しているのか、遠方の住民も来院しているのか等を確認することができ、近隣の住民のみが来院していると判断される場合は、遠方の住民もが来院するような魅力を持つことを検討する等をすることができる。また、近隣の他の医療機関を示す他院１７を同時に表示させることにより、来院者の分布を他の医療機関との関係で確認することができる。例えば、図２２のマップ情報により患者１６の分布と他院１７とを比較すると、当院１４からの距離が同じであっても、近隣に他院１７がない地域の住民の方が多く来院していることが分かる。逆に、患者１６ａ，１６ｂ，１６ｃは、より近くに他院１７があっても、当院１４との間に川２１があっても大通り２２があっても来院している。この時、患者１６ａ，１６ｂ，１６ｃをクリックすることにより図１９に例示する医療詳細情報６を確認することにより、わざわざ当院１４に来院している患者の詳細情報を確認することができる。例えば、これらの患者がいずれも人工透析を受けているとすると、当院１４に係る医療機関２（図１５参照）は、人工透析に秀でているという評判を有することが予想され、この点をより発揮することにより、さらなる来院患者を獲得する等の方策をとることができる。

また、図２３（ａ）に例示する医療詳細情報１８を確認することにより、医師等は、来院した患者における病気において、多い病気と少ない病気を一目で確認することができ、自身の医療機関における得意分野と苦手分野とを把握し、医療機関の運営方針を容易に決定することができる。例えば、図２３（ａ）に例示する医療詳細情報１８では、消化器系の疾患のために通院する患者が、一般的な統計に比べて少なかったとすると、消化器系の疾患の治療に力を入れる等の方策を施し、来院患者の増加を図ること等が可能となる。

さらに、図２３（ｂ）に例示する医療詳細情報１９を確認することにより、医師等は、病気毎の患者の詳細情報や通院履歴を確認し、より詳細に自身の医療機関における得意分野と苦手分野とを把握すると共に、患者の流出状況を合わせて確認することができる。そのため、流出状況も考慮して、医療機関の運営方針を容易に決定することができる。

なお、上記実施の形態２の例では、医療履歴情報１５としてマップ形式のマップ情報を用いたが、より簡便に、当院１４からの距離と来院患者の関係を示す表等としても良い。

なお、本発明の通院管理方法、及び通院管理装置において「流出患者」、「継続患者」の定義については、種々の観点から行うことができる。例えば、患者個人ごとのレセプトデータの処方箋日数、診療行為を読み取り、最終来院日から適正来院日を設定し、その適正来院日から超過した日数により、流出可能性のある患者、あるいは既に流出してしまった患者（流出患者）としてカテゴリーしていく方法を採用することができる。「流出患者」、「継続患者」の定義付けについては、基本的に処方箋日数を基準としつつ、薬剤が処方されていない患者の来院周期を所定期間（例えば１ヶ月）を周期として設定し、この周期を基準として超過した日数により、流出可能性のある患者、あるいは既に流出してしまった患者（流出患者）としてカテゴリーしていく方法を採用することができる。また、リハビリ患者については、処方箋日数ではなく、診療行為（消炎鎮痛）を最優先し、所定期間（例えば３〜７日）を来院周期として設定し、流出可能性のある患者、あるいは流出患者としてカテゴリーしていく方法を採用することができる。

また、本発明の通院管理方法、及び通院管理装置を活用し、競合施設（医院等）の診療圏内に存在する患者住所（自院の来院患者）を抽出し、年齢、疾患、男女などの各要素で分析し、競合の弱みを把握することも可能である。また、本発明の通院管理方法、及び通院管理装置は、前述したのとは逆に、自院の流出患者の住所と競合施設との距離関係から、競合施設に取られてしまっていると予測される患者を抽出し、年齢、疾患、男女などの各要素で分析し、自院の弱みを把握することに活用することも可能である。

本発明は、来院する患者の維持や新規患者の獲得等、医療機関のマーケティング活動に好適に利用することができる。

１ サーバ
２ 医療機関
３ ネットワーク
４ レセプトデータ
５ 医療履歴情報
６ 医療詳細情報
７ ＣＰＵ
８ メモリ
９ 送受信器
１０ 表示制御装置
１１ プログラム
１２ スイッチ
１３ スイッチ
１４ 当院
１５ 医療履歴情報
１６ 患者
１６ａ 患者
１６ｂ 患者
１６ｃ 患者
１７ 他院
１８ 医療詳細情報
１９ 医療詳細情報
２０ スイッチ
２１ 川
２２ 大通り
２３ 領域円
３０ 来院管理装置
３２ 制御部
４２ａ 患者データベース
４２ｂ 医療機関データベース
７０ クライアント端末
８０ インターネット
２００ 来院管理システム
Ｃ 来院周期
Ｄａ 最終来院日
Ｐ 従事者
Ｒ 診療圏
Ｒａ 自院診療圏
Ｒｃ 競合診療圏
Ｒｄ レセプトデータ
Ｒｉ レセプト情報
Ｘ 医療機関
Ｘａ 自医療機関
Ｘｃ 競合医療機関

Claims (8)

1. 第一の医療機関が、自院に来院する患者の傾向を分析可能な来院管理装置であって、
   前記第一の医療機関のレセプトデータをレセプト情報として蓄積し、前記レセプト情報に基づいて所定の情報を生成可能な制御装置を有し、
   前記制御装置が、
   複数の医療機関の所在地に係る情報を含む医療機関データベースを備え、
   前記第一の医療機関から所定の範囲内に所在する医療機関の少なくとも一部を競合医療機関として設定するとともに、前記競合医療機関の所在地から所定の範囲内を競合診療圏内として設定し、
   前記第一の医療機関に来院した患者のうち、前記競合診療圏内に在住する患者を競合圏内患者として抽出可能であることを特徴とする来院管理装置。
2. 前記制御装置が、
   前記第一の医療機関の患者の来院状況を判定して、少なくとも前記競合圏内患者を含む複数の患者を複数のカテゴリーに区分可能であることを特徴とする請求項１に記載の来院管理装置。
3. 前記制御装置が、
   前記第一の医療機関の患者の来院状況を判定して、少なくとも前記競合圏内患者を含む複数の患者を複数のカテゴリーに区分可能であり、
   前記競合圏内患者のうち、前記第一の医療機関に継続して来院している患者を自院流入患者として区分し、
   所定の期間内に前記第一の医療機関への来院がなかった患者の少なくとも一部を自院流出患者として区分することを特徴とする請求項１又は２に記載の来院管理装置。
4. 前記制御装置が、
   前記競合圏内患者の前記第一の医療機関への来院状況を判定して、前記競合圏内患者を複数のカテゴリーに区分可能であり、
   前記競合圏内患者の属性を表示可能であることを特徴とする請求項１又は２に記載の来院管理装置。
5. 前記制御装置が、
   前記第一の医療機関の少なくとも一部の患者の在住地を、地図上に位置情報として表示させる患者分布マップ情報を生成可能であることを特徴とする請求項１〜４のいずれかに記載の来院管理装置。
6. 前記制御装置が、
   患者の年齢あるいは性別を含む属性情報が蓄積された患者属性情報データベースを備え、
   前記患者分布マップ情報には、少なくとも一部の前記競合圏内患者の前記属性情報を表示可能であることを特徴とする請求項５に記載の来院管理装置。
7. 請求項１〜６のいずれかに記載の来院管理装置と、
   前記来院管理装置とインターネットを介して接続可能なクライアント端末とを有し、
   前記制御装置が、
   前記第一の医療機関のレセプトデータをレセプト情報として蓄積し、前記レセプト情報に基づいて所定の情報を生成可能な制御装置を有し、
   前記制御装置が、
   複数の医療機関の所在地に係る情報を含む医療機関データベースを備え、
   前記第一の医療機関から所定の範囲内に所在する医療機関の少なくとも一部を競合医療機関として設定するとともに、前記競合医療機関の所在地から所定の範囲内を競合診療圏内として設定し、
   前記第一の医療機関に来院した患者のうち、前記競合診療圏内に在住する患者を競合圏内患者として抽出可能であり、
   前記クライアント端末に前記競合圏内患者に係る情報を表示可能であることを特徴とする来院管理システム。
8. 請求項１〜６のいずれかに記載の来院管理装置に、
   前記競合圏内患者を抽出する競合圏内患者抽出ステップを実行させることを特徴とする来院管理プログラム。

Images