(57)【特許請求の範囲】
【請求項１】
接骨院の保険支払請求処理と保険者の療養費の支払処理を、接骨院端末、保険者端末、金融機関端末の間で仲介処理する保険支払請求−療養費支払仲介システムであって、
前記接骨院において患者から得た前記保険支払請求の代理権に基づいて前記保険者に前記保険支払請求ができる再代理権に関する再代理申請データを登録管理する患者情報管理部と、
前記接骨院端末からのレセプトデータの入力を受け付け、前記患者情報管理部に事前に登録されている再代理申請データとともに、前記レセプトデータを前記保険者端末に対して送信するレセプトデータ処理部と、
前記接骨院端末と前記保険者端末と前記金融機関端末の間における前記療養費の収受に関する決済を管理する決済処理部を備え、
前記決済処理部が、
前記保険者端末からの前記療養費の入力待ち状態において、前記金融機関端末に対して前記保険者端末から前記接骨院端末へ支払われるべき前記療養費の立替を依頼する立替依頼処理と、
前記保険者端末における前記保険支払請求の再代理権に関する前記再代理申請データに基づく前記保険支払処理において、前記療養費の支払い先の指定を、前記再代理申請データが指定している前記決済処理部のまま変更しないのか、前記再代理申請データが指定している者とは異なる前記金融機関端末に変更するか、の前記再代理申請データの変更選択処理を可能とすることを特徴とする保険支払請求−療養費支払仲介システム。
【請求項２】
前記決済処理部が、前記再代理申請データの変更選択処理において、前記再代理申請データが指定している者とは異なる前記金融機関端末に変更する前記支払い先のバリエーションを選択する場合、前記保険者端末に対して、前記金融機関端末が前記決済処理部に代わって療養費を代理受信する旨の代理受信申請データを通知することを特徴とする請求項１に記載の保険支払請求−療養費支払仲介システム。
【請求項３】
前記決済処理部が、前記再代理申請データの変更選択処理において、前記再代理申請データにおいて選択された者ではない前記金融機関端末に変更する前記支払い先のバリエーションを選択する場合、前記金融機関端末から前記立替にかかる前記療養費の収受が完了した旨の通知を受け、前記レセプトデータにかかる前記接骨院端末と前記保険者端末と前記金融機関端末の間における前記療養費の収受に関する決済処理の完了情報を決済情報データベースに蓄積する請求項２に記載の保険支払請求−療養費支払仲介システム。
【請求項４】
前記レセプトデータ処理部が、施術データを基にレセプトデータを作成するレセプトデータ作成機能を備え、前記接骨院端末から施術の内容を示す施術データの入力を受け付けると対応するレセプトデータを作成し、前記患者情報管理部に事前に登録されている再代理申請データとともに、前記レセプトデータを前記保険者端末に対して送信する請求項１乃至３のいずれか１項に記載の保険支払請求−療養費支払仲介システム。
【請求項５】
接骨院の保険支払請求処理と保険者の療養費の支払処理を、接骨院端末、保険者端末、金融機関端末の間で仲介処理するコンピュータに、
前記接骨院において患者から得た前記保険支払請求の代理権に基づいて前記保険者に対して前記保険支払請求ができる再代理権に関する再代理申請データを登録管理する患者情報管理手順と、
前記接骨院端末からのレセプトデータの入力を受け付け、前記患者情報管理部に事前に登録されている再代理申請データとともに、前記レセプトデータを前記保険者端末に対して送信するレセプトデータ処理手順と、
前記接骨院端末と前記保険者端末と前記金融機関端末の間における前記療養費の収受に関する決済を管理する決済処理手順を実行させ、
前記決済処理手順において、
前記保険者端末からの前記療養費支払データの入力待ち状態において、前記金融機関端末に対して前記保険者端末から前記接骨院端末へ支払われるべき前記療養費の立替を依頼する立替依頼処理と、
前記保険者端末における前記保険支払請求の再代理権に関する前記再代理申請データに基づく前記保険支払処理において、前記療養費の支払い先の指定を、前記再代理申請データが指定している前記決済処理部のまま変更しないのか、前記再代理申請データが指定している者とは異なる前記金融機関端末に変更するか、の前記再代理申請データの変更選択処理を可能とすることを特徴とする保険支払請求−療養費支払仲介処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は接骨院に関する保険支払請求と療養費支払いなどを仲介する保険支払請求−療養費支払仲介システムに関する。より詳しくは、本発明は、接骨院における外来型のマッサージ指圧施術について、素早い療養費の立替処理を可能とし、さらに、不正請求ができない客観的な療養費の保険支払請求事務処理を可能とした保険支払請求−療養費支払仲介システムに関する。
【０００２】
レセプトデータとは保険支払請求申請書（レセプト）の内容を表わすデータである。ここで、レセプトとは、診療報酬や介護報酬や療養費の支払いを請求する支払請求申請書のことである。現在は医療機関における診療報酬の場合はレセプト審査支払機関（国民健康保険団体連合会(国保連)、社会保険診療報酬支払基金(支払基金)）における審査後に保険者に提出され、接骨院などにおける療養費の場合は直接保険者に提出されることとなっている。
【０００３】
なお以下、接骨院と記述している部分は、接骨院のほか、鍼灸院、按摩マッサージ院など長期に療養が継続されるものに関して保険請求が可能となる者の総称として用いている。
また金融機関と記述している部分は、銀行や信用金庫などの金融機関に加え、クレジット会社やファンドなどのノンバンク機関も含む総称として用いている。
【背景技術】
【０００４】
健康保険制度や国民健康保険制度の下では、患者に対する医療手術、投薬、検査などの医療行為ごとに診療報酬が決められており、これら医療行為を患者に施した医療機関は診療報酬のルールに則り、作成したレセプトを使って患者が所属する保険者（市町村国民保健組合、共済組合、健保組合）に診療費の支払いを求める。
接骨院、鍼灸院、按摩マッサージ院など長期に療養が継続されるものは療養内容ごとに療養費が決められており、これら療養行為を施した療養型期間は療養費請求のルールに則り、作成したレセプトを使って患者が所属する保険者に療養費の支払いを求める。
【０００５】
図１５は、従来の一般的な接骨院における外来型のマッサージの診療報酬の支払請求と審査および支払いの概略を示す図である。図１５に見るように、患者Ａ、接骨院Ｂ、保険者Ｄの３者モデルとして説明される。
【０００６】
患者Ａは接骨院Ｂにおいて保険証を提示し、接骨院Ｂでは柔道整復師が問診表などを書き込んだ後、治療計画を立てる。長期の療養が必要な接骨治療や捻挫治療などでは療養費支払請求の際には療養費支給申請書が必要である。この療養費支給申請書には患者のサインが必要であるところ、支払請求のためのレセプト作成処理およびレセプト送付処理のタイミングと患者の来院のタイミングが合わないので、レセプト作成・送付時に患者のサインをもらうことが事実上難しく、現状は、初診時に患者に対してサインをもらい、白紙委任を取り付けているのが実情となっている。
【０００７】
接骨院Ｂは施術行為に対するレセプトを作成し、直接保険者Ｄ（市町村国民保健組合、共済組合、健保組合）にレセプトを送付する。保険者Ｄはレセプトの正当性を審査し、それが正当であれば接骨院Ｂに対して診療報酬として療養費の支払いを行う。
【０００８】
図１５に見るように、従来技術における療養費支払いの流れでは、診療報酬の支払いは、接骨院Ｂにおける施術行為に基づくレセプトの作成事務処理とレセプトの送付事務処理、さらには保険者Ｄにおけるレセプト審査事務処理、保険者Ｄから接骨院Ｂに対する支払い事務処理などを経て行われる。
従来の患者Ａ、接骨院Ｂ、保険者Ｄの３者モデルには様々な問題点が指摘されている。
【０００９】
まず、第１に、レセプトの作成を接骨院Ｂが自ら請求事務を行っていたため不適切な療養費の支払請求が問題となっていた。不適切な療養費の支払請求には過失による過誤請求もあれば故意による不正請求もある。過失による過誤請求であれば診療内容と保険点数の適合性チェック、保険点数計算の再計算チェックなどチェック方法を工夫すれば防止しやすい。しかし、故意による不正請求はチェックする方法が難しいと言われている。
【００１０】
ここで、従来の３者モデルとは異なるモデルを提案した技術が知られている。
図１６は特開２００１−３４４３３７号公報に開示された技術を説明する図である。患者Ａ、接骨院Ｂ、仲介機関Ｃ、保険者Ｄの４者モデルとして説明される。患者Ａが接骨院Ｂに来院するモデルとなっている。特開２００１−３４４３３７号公報開示の技術は、医療機関Ｂと保険者Ｄ間に仲介機関Ｃを加えたモデルであり、仲介処理内容は、レセプト情報の送受信、決済情報の送受信、返戻されるレセプト情報の送受信である。返戻されるレセプトとは、保険者Ｄで支払いを留保したレセプトのことであり医療機関Ｂに差し戻されるものである。特開２００１−３４４３３７号公報開示の技術は不正請求を防止するものであり、特に、返戻レセプトの取り扱いを自動化したことを開示したものである。なお、決済情報については単純に取り次ぐのみである。
【００１１】
【特許文献１】特開２００１−３４４３３７号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
上記従来技術における問題は、接骨院Ｂにおける診療実施日から保険者Ｄによる実際の診療報酬の支払完了日までのタイムラグが大きい点である。このタイムラグは大きく通常２ヶ月から３ヶ月程度はかかるとされている。
接骨院は個人経営など事業規模が小さいところがほとんどであり、この診療実施日から実際の診療報酬の支払い完了日までのタイムラグは経営上の大きな問題となっているケースが多い。
【００１３】
レセプトを保険者Ｄに提出してから保険者Ｄからの診療報酬の支払い完了までタイムラグが生じる点は制度上の問題であり、このタイムラグは誰かが負わねばならない。通常は接骨院Ｂ自らがこのタイムラグを負っている。特開２００１−３４４３３７号公報では仲介機関Ｃが保険者Ｄへのレセプト提出処理と診療報酬に関する決済処理を行うが、結局そのタイムラグは接骨院Ｂが負っていることには変わりない。
【００１４】
接骨院Ｂにおける診療実施日から保険者Ｄによる実際の診療報酬の支払完了日までのタイムラグは金融機関が担うことが好ましい。特開２００１−３４４３３７号公報の技術において金融機関がこのタイムラグを担うためには仲介機関Ｃ自身が金融機関でなければならず決済処理のみならずレセプト提出処理も担う必要が生じてしまうので、実際には困難である。
【００１５】
レセプト作成処理および保険者Ｄへの提出処理に関しては、レセプトに関する知識とノウハウを有する仲介機関が行うことが好ましい。さらに、決済処理および接骨院Ｂにおける診療実施日から保険者Ｄによる実際の診療報酬の支払完了日までのタイムラグを負担するのは金融機関であることが好ましい。つまり、患者Ａ、接骨院Ｂ、仲介機関Ｃ、保険者Ｄ、金融機関Ｅの５者間システムとすることが好ましい。
【００１６】
上記問題点に鑑み、本発明は、患者Ａ、接骨院Ｂ、仲介機関Ｃ、保険者Ｄ、金融機関Ｅの間を仲介しつつ、上記のレセプト作成処理および保険者Ｄへの提出処理を仲介機関Ｃが実行しつつ、決済処理およびタイムラグの負担を金融機関Ｅに担わせるように運用する保険支払請求−療養費支払仲介システムを提供することを目的とする。
【課題を解決するための手段】
【００１７】
上記目的を達成するため、本発明の保険支払請求−療養費支払仲介システムは、
接骨院の保険支払請求処理と保険者の療養費の支払処理を、接骨院端末、保険者端末、金融機関端末の間で仲介処理する保険支払請求−療養費支払仲介システムであって、
前記接骨院において患者から得た前記保険支払請求の代理権に基づいて前記保険者に前記保険支払請求ができる再代理権に関する再代理申請データを登録管理する患者情報管理部と、
前記接骨院端末からのレセプトデータの入力を受け付け、前記患者情報管理部に事前に登録されている再代理申請データとともに、前記レセプトデータを前記保険者端末に対して送信するレセプトデータ処理部と、
前記接骨院端末と前記保険者端末と前記金融機関端末の間における前記療養費の収受に関する決済を管理する決済処理部を備え、
前記決済処理部が、
前記保険者端末からの前記療養費の入力待ち状態において、前記金融機関端末に対して前記保険者端末から前記接骨院端末へ支払われるべき前記療養費の立替を依頼する立替依頼処理と、
前記保険者端末における前記保険支払請求の再代理権に関する前記再代理申請データに基づく前記保険支払処理において、前記療養費の支払い先の指定を、前記再代理申請データが指定している前記決済処理部のまま変更しないのか、前記再代理申請データが指定している者とは異なる前記金融機関端末に変更するか、の前記再代理申請データの変更選択処理を可能とすることを特徴とする。
【００１８】
上記構成において、前記決済処理部が、前記再代理申請データの変更選択処理において、前記再代理申請データが指定している者とは異なる前記金融機関端末に変更する前記支払い先のバリエーションを選択する場合、前記保険者端末に対して、前記金融機関端末が前記決済処理部に代わって療養費を代理受信する旨の代理受信申請データを通知することが好ましい。
【００１９】
また、上記構成において、前記決済処理部が、前記再代理申請データの変更選択処理において、前記再代理申請データにおいて選択された者ではない前記金融機関端末に変更する前記支払い先のバリエーションを選択する場合、前記金融機関端末から前記立替にかかる前記療養費の収受が完了した旨の通知を受け、前記レセプトデータにかかる前記接骨院端末と前記保険者端末と前記金融機関端末の間における前記療養費の収受に関する決済処理の完了情報を決済情報データベースに蓄積することが好ましい。
【００２０】
また、前記レセプトデータ処理部が、施術データを基にレセプトデータを作成するレセプトデータ作成機能を備え、前記接骨院端末から施術の内容を示す施術データの入力を受け付けると対応するレセプトデータを作成し、前記患者情報管理部に事前に登録されている再代理申請データとともに、前記レセプトデータを前記保険者端末に対して送信することが好ましい。
【００２１】
本発明の保険支払請求−療養費支払仲介処理プログラムは、接骨院の保険支払請求処理と保険者の療養費の支払処理を、接骨院端末、保険者端末、金融機関端末の間で仲介処理するコンピュータに、
前記接骨院において患者から得た前記保険支払請求の代理権に基づいて前記保険者に対して前記保険支払請求ができる再代理権に関する再代理申請データを登録管理する患者情報管理手順と、
前記接骨院端末からのレセプトデータの入力を受け付け、前記患者情報管理部に事前に登録されている再代理申請データとともに、前記レセプトデータを前記保険者端末に対して送信するレセプトデータ処理手順と、
前記接骨院端末と前記保険者端末と前記金融機関端末の間における前記療養費の収受に関する決済を管理する決済処理手順を実行させ、
前記決済処理手順において、
前記保険者端末からの前記療養費の入力待ち状態において、前記金融機関端末に対して前記保険者端末から前記接骨院端末へ支払われるべき前記療養費の立替を依頼する立替依頼処理と、
前記保険者端末における前記保険支払請求の再代理権に関する前記再代理申請データに基づく前記保険支払処理において、前記療養費の支払い先の指定を、前記再代理申請データが指定している前記決済処理部のまま変更しないのか、前記再代理申請データが指定している者とは異なる前記金融機関端末に変更するか、の前記再代理申請データの変更選択処理を可能とすることを特徴とする。
【発明の効果】
【００２２】
本発明の保険支払請求−療養費支払仲介システムによれば、患者、接骨院、仲介機関、保険者、金融機関の間を仲介しつつ、レセプト作成処理および保険者への提出処理は仲介機関が管理する仲介処理コンピュータが担い、決済処理は仲介機関の仲介処理コンピュータから金融機関の金融機関端末に引き継がれ、療養費の支払請求から療養費の支払完了までのタイムラグの負担を金融機関に担わせるように運用せしめることができる。
【発明を実施するための最良の形態】
【００２３】
以下、本発明を実施するための最良の形態について実施例により具体的に説明する。なお、本発明はこれらの実施例に限定されるものではない。
【実施例１】
【００２４】
本発明の保険支払請求−療養費支払仲介システムの構成例を、図面を参照しつつ説明する。
以下、接骨院と記述している部分は、接骨院のほか、鍼灸院、按摩マッサージ院など長期に療養が継続されるものに関して保険請求が可能となる者の総称として用いている。
【００２５】
本発明の保険支払請求−療養費支払仲介システムは、仲介処理コンピュータが、接骨院端末、保険者端末、金融機関端末の間で保険支払請求処理と療養費支払処理を仲介するものとなっている。仲介処理コンピュータを設置・管理する主体は接骨院の一組織ではなく、独立した仲介機関であることが前提である。
保険者とは自治体等（国民健康保険等）および各企業等（健康保険組合等）であり、患者は国民健康保険等や健康保険組合等の被保険者である患者である。
【００２６】
本発明の保険支払請求−療養費支払仲介システムにおいて、レセプト作成処理および保険者への提出処理は仲介機関が管理する仲介処理コンピュータが担い、決済処理は仲介機関の仲介処理コンピュータから金融機関の金融機関端末に引き継がれ、療養費の支払請求から療養費の支払完了までのタイムラグの負担を金融機関に担わせるものとなっている。
【００２７】
図１から図４は、レセプト提出処理をする者と療養費の支払請求から療養費の支払完了までのタイムラグの負担をする者を本発明の構成の場合と従来技術の構成の場合を比較して示すものである。図１は従来技術の図１５に示した構成の場合、図２は従来技術の図１６に示した構成の場合（パターン１）、図３は従来技術の図１６に示した構成の場合（パターン２）、図４は本発明の構成の場合を示している。
【００２８】
図１５に示した従来構成の場合、図１（ａ）に示すようにレセプト提出処理は接骨院端末１０が行い、図１（ｂ）に示すように療養費支払完了までタイムラグを担うのも接骨院端末１０を管理する接骨院Ｂである。
【００２９】
図１６に示した従来構成の場合、２つのパターンが想定される。
第１のパターンは、図２（ａ）に示すように、レセプト提出処理は仲介端末１０が行い、図２（ｂ）に示すように、療養費支払完了までタイムラグを担うのが接骨院端末１０を管理する接骨院Ｂとなるパターンである。
第２のパターンは、図３（ａ）に示すように、レセプト提出処理は仲介処理コンピュータ２０が行い、図３（ｂ）に示すように、療養費支払完了までタイムラグを担うのも仲介処理コンピュータ２０を管理する仲介機関Ｃとなるパターンである。
【００３０】
図４に示した本発明の構成の場合、図４（ａ）に示すように、レセプトデータは接骨院端末１０から仲介処理コンピュータ３０に渡され、仲介処理コンピュータ３０から保険者端末３０および金融機関端末４０へレセプトデータが渡される。つまり、レセプト提出処理は仲介処理コンピュータ２０が行う。
なお、金融機関Ｅから立替により療養費が速やかに接骨院Ｂに振り込まれ、金融機関端末４０から療養費データが接骨院端末１０に通知される。
【００３１】
次に、図４（ｂ）に示すように、決済処理は仲介処理コンピュータ２０から金融機関端末４０へ引き継がれ、療養費支払完了までタイムラグを担うのは金融機関端末４０を管理する金融機関Ｅとなっている。
【００３２】
保険支払請求−療養費支払仲介システムの各構成について説明する。
図５は、実施例１にかかる本発明の保険支払請求−療養費支払仲介システムの構成を示すブロック図である。
【００３３】
まず、接骨院端末１０を説明する。
接骨院端末１０は、接骨院Ｂに設置されるコンピュータ端末である。接骨院端末１０は、いわゆる据え置き型のコンピュータでも良く、柔道整復師が持ち運ぶいわゆる携帯型のハンドヘルドコンピュータでも良い。近年はゲーム機器として用いられている端末もアプリケーションの搭載により小型で携帯可能なコンピュータシステムとして利用することが可能となってきている。アプリケーションはＡＳＰ（Application Service Provider）により提供する方法も可能である。
【００３４】
接骨院端末１０は、患者情報管理部１１、患者情報データベース１２、レセプトデータ作成部１３、保険情報データベース１４、決済処理部１５、決済情報データベース１６を備えている。
なお、インタフェースとして、入力装置、出力装置、表示装置などを備えているが、図５のブロック図では図示を省略している。
【００３５】
入力装置は、操作する柔道整復師によるデータ入力を可能とする入力インターフェイスである。入力方式は特に限定されず、例えば、入力ボタン、十字キー、タッチパネルなど特に限定されない。音声認識入力も採用可能である。例えば、当日施術した内容を入力装置から入力する。
出力装置はデータ出力を行う部分であり、接骨院端末１０から必要に応じて諸データを仲介処理コンピュータ２０などに対して出力する部分である。
表示装置は、操作する柔道整復師に対するデータ出力を可能とする出力インターフェイスである。表示方式は特に限定されず、例えば、液晶表示パネルなどである。柔道整復師が弱視者である場合、音声出力機能を備えていることが好ましい。
【００３６】
接骨院端末の各要素を持つものとして、株式会社ソニー・コンピュータエンタテインメント(ＳＣＥＩ)の「プレイステーションポータブル」（以下、ＰＳＰと略記する）を用いて接骨院端末１０を構成することができる。実際には接骨院端末の持つ制御装置と記憶装置とソフトウェアなどのコンピュータリソースにより上記の各要素が構成される。
【００３７】
患者情報管理部１１は、外来型で按摩マッサージなどの療養治療を希望する患者から患者の氏名、住所、保険番号などの患者情報の入力・登録を受け付ける部分である。外来型で按摩マッサージなどの療養治療を始めるにあたり、あらかじめ患者情報管理部１１を介して患者情報を登録しておく必要がある。療養は長期に継続することが前提であり療養計画に基づいて施術が行われるからである。例えば、外来来院の初回時に療養計画を立て、患者の氏名、住所、保険番号など必要な患者情報を登録するものとする。
【００３８】
また、療養費の保険請求にあたり、患者Ａから接骨院Ｂに対する代理申請を委任してもらう必要があるが、当該代理申請データについても管理する。
【００３９】
また、後述するように、仲介機関Ｃを介して保険者Ｄに療養費の保険請求を仲介するよう依頼するので、仲介機関Ｃを選任された再代理人とした再代理権を設定する必要がある。再代理権とは接骨院Ｂが患者Ａから得た保険支払請求の代理権に基づいて保険者Ｄに保険支払請求ができる権利である。もともと患者Ａから与えられた保険支払請求の代理権は、委任者が患者Ａ、代理人が接骨院Ｂの柔道整復師である。仲介機関Ｃが保険者Ｄに保険支払請求をするには、委任者が患者Ａ、代理人である接骨院Ｂから選任された再代理人が仲介機関Ｃである再代理権が必要となる。この再代理権によれば仲介機関Ｃが関与できるようになる。再代理申請データは当該再代理権に関する申請データとなっている。患者情報管理部１１は代理申請データに基づいて再代理申請データを作成し、仲介処理コンピュータ２０に対して送信する処理も行う。
【００４０】
患者情報データベース１２は患者ごとの諸情報を格納したデータベースであり、患者の氏名、住所、年齢、保険番号などの患者属性を示す各種情報が格納されている。なお、患者ＩＤ情報としてバイオメトリックス情報を利用することも可能である。たとえば、指の静脈パターン情報、指紋情報、手のひらの静脈パターン情報、虹彩パターン情報などを利用することも可能である。
【００４１】
レセプトデータ作成部１３は入力装置を介して入力された施術内容からレセプトデータを作成する部分である。療養では来院した患者Ａに対して適切な療養行為を施すが、各療養行為には保険点数がつけられており、正確に保険点数を計算する必要があるため、柔道整復師が施した療養内容を接骨院端末１０に入力してもらい、正確なレセプトデータを作成する必要がある。図示しないがレセプトデータ作成部１３は保険点数データを蓄積したデータベースと保険点数計算手段を備えていることが好ましい。
【００４２】
保険情報データベース１４は、自治体等、各企業等の基本情報（被保険者等の情報）および病院等の医療機関・調剤薬局の基本情報（認可申請等の情報）、および法改訂時における厚生省等が発行した診療報酬算定時に必要な情報などを格納している。なお、レセプトデータ作成部１３が施術内容を表わすデータを基にレセプトデータを作成する際に保険情報データベース１４にアクセスして参照する。
【００４３】
決済処理部１５は、療養費の収受に関する決済を管理する部分であり、保険請求した療養費の額と接骨院Ｂに収受された療養費の額を把握し、決済処理を管理する。
【００４４】
決済情報データベース１６は、決済情報に関するデータを蓄積するデータベースである。金融機関Ｅにおける口座の入出金データを保持する。
【００４５】
次に、仲介処理コンピュータ２０の各構成要素について説明する。
なお、本実施例１ではレセプトデータ作成を接骨院端末１０において行うものとする。レセプトデータ作成を仲介処理コンピュータ２０で行う構成は実施例２において述べる。
【００４６】
図５の仲介処理コンピュータ２０の構成例では、患者情報管理部２１、患者情報データベース２２、レセプトデータ処理部２３、保険情報データベース２４、決済処理部２５、決済情報データベース２６を備えている。
なお、インタフェースとして、入力装置、出力装置、表示装置などを備えているが、図５のブロック図では図示を省略している。
【００４７】
患者情報管理部２１は患者ごとの諸情報を管理する部分であり、患者の氏名、住所、年齢、保険番号などの患者属性を示す各種情報ともにレセプトデータも管理する。後述するように仲介処理コンピュータ２０から保険者端末３０に対して月締めなど所定タイミングにおいてレセプトデータを患者ごとにまとめて送付する必要があるので患者Ａごとにデータを管理しておく。
【００４８】
患者情報データベース２２は、患者ごとの諸情報を格納したデータベースであり、患者の氏名、住所、年齢、保険番号などの患者属性を示す各種情報に加え、発生している療養費に関する情報も格納されている。
【００４９】
レセプトデータ処理部２３は、接骨院端末１０からレセプトデータと再代理権に関する再代理申請データの入力を受け付けて保険者端末３０に送信し、接骨院端末１０と保険者端末３０の間において仲介する部分である。
【００５０】
保険情報データベース２４は、自治体等、各企業等の基本情報（被保険者等の情報）および病院等の医療機関・調剤薬局の基本情報（認可申請等の情報）、および法改訂時における厚生省等が発行した診療報酬算定時に必要な情報などを格納している。なお、レセプトデータ処理部２３はレセプトデータを保険者端末３０に送信する前に保険情報データベース２４にアクセスしてレセプトデータが正しいことを確認する。
【００５１】
決済処理部２５は、療養費の収受に関する決済を管理する部分であり、保険者端末３０に送信して請求した保険請求額と保険者端末３０または金融機関端末４０から収受された療養費の額を把握し、決済処理を管理する。
【００５２】
決済情報データベース２６は、決済情報に関するデータを蓄積するデータベースである。
【００５３】
保険者端末３０は自治体等（国民健康保険等）および各企業等（健康保険組合等）の保険者が設置・管理しているシステムであり、被保険者の情報を備え、仲介処理コンピュータから送信されたレセプトデータの正当性を審査し、正当性が確認されたレセプトデータに従い保険支払処理などを行う。保険支払処理の流れについては後述する。
【００５４】
金融機関端末４０は、決済処理機能と、療養費の支払いを立て替えることができる立替機能を持つ金融機関が設置する端末である。ここでいう金融機関とは銀行や信用金庫などに加え、クレジット会社やファンドなどのノンバンク機関も含むもので良い。決済処理は仲介機関の仲介処理コンピュータ２０から金融機関の金融機関端末４０に引き継がれ、金融機関端末４０は療養費の支払請求から療養費の支払完了までのタイムラグの負担を担う。これらの流れについては後述する。
【００５５】
次に、保険支払請求−療養費支払仲介システムにおける仲介処理コンピュータ２０を中心とする、レセプト作成処理および療養費の保険請求処理の流れ、療養費の決済処理の流れなどを説明する。なお、以下の流れにおいて、各段階で適宜にフローチャートを参照しつつ説明する。
【００５６】
（Ａ）患者情報登録時の流れ
患者は療養計画に基づいて施術を受ける前に、患者情報の登録手続きを行う。患者は接骨院端末１０の入力装置を介して氏名、住所などの諸情報の届けに加え、提示された保険証の保険番号など必要情報を入力する（図６ステップＳ１）。
【００５７】
接骨院Ｂは患者Ａ氏名、住所、保険番号の確認などを行い、患者情報管理部１１を介して患者情報データベース１２に対して患者情報の登録処理を行う（図６ステップＳ２）。
【００５８】
次に、患者Ａは症状などを問診表に記入するなどし、柔道整復師との間で療養計画を立てる。接骨院Ｂなどで長期通院を必要とする疾病の場合を想定しているので接骨院Ｂは療養費支給申請書を作成して患者Ａに渡し、当該療養費支給申請書のサインをしてもらい委任を受ける。入力装置を介して代理申請データを入力する（図６ステップＳ３）。
【００５９】
患者情報管理部１１は、代理申請データを患者情報データベース１２に登録するとともに、仲介機関Ｃを選任された再代理人とする再代理申請データを作成し、患者情報データベース１２に登録する（図６ステップＳ４）。
【００６０】
出力装置を介して仲介処理コンピュータ２０の患者情報管理部２１に対して患者情報および再代理申請データを出力する（図６ステップＳ５）。
【００６１】
仲介処理コンピュータ２０の患者情報管理部２１は、入力装置を介して接骨院端末１０から入力された患者情報および再代理申請データを受け、患者情報データベース２２に登録する。
以上が、患者情報登録時の流れである。
【００６２】
次に、外来型による接骨院Ｂにおける療養行為時の処理の流れを図７のフローチャートを参照しつつ説明する。本実施例１ではレセプトデータの作成は接骨院端末１０において行うものとする。レセプトデータを仲介処理コンピュータ２０で行う構成は実施例２において述べる。
【００６３】
柔道整復師は、療養計画に基づいて患者に対して施術を行うとともに、患者の症状に合わせて療養計画以外の施術が必要であれば当該施術を行う。柔道整復師は、入力装置を介して当日終了した療養行為に関するデータを入力する（図７ステップＳ１）。
【００６４】
次に、レセプトデータ作成部１３は、入力装置を介して入力された施術内容に関するデータを受け、保険情報データベース１４にアクセスして保険点数を確認しつつ、レセプトデータを作成する（図７ステップＳ２）。レセプトデータを日締めで送信するか、週締めで送信するか、月締めで送信するかは運用により変更可能であることは言うまでもない。
【００６５】
次に、作成したレセプトデータを出力装置を介して仲介処理コンピュータ２０に対して送信する（図７ステップＳ３）。
以上が、接骨院Ｂにおける療養行為時の処理の流れである。
【００６６】
次に、仲介処理コンピュータ２０における仲介処理の流れを図８から図１０の模式図、図１１のフローチャートを参照しつつ説明する。
【００６７】
まず、図８（ａ）に示すように、レセプトデータ処理部２３は、入力装置を介して接骨院端末１０からレセプトデータを受け付ける。なお、再代理申請データは既に患者情報管理部２１により患者情報データベース２２に登録されているものとする（データ入力処理ステップ）（図１１ステップＳ１）。
【００６８】
次に、図８（ｂ）に示すように、レセプトデータ処理部２３は、受け付けたレセプトデータと再代理申請データを保険者端末３０に送信する（申請処理ステップ）（図１１ステップＳ２）。
【００６９】
ここで、仲介処理コンピュータ２０の決済処理部２５は、保険者端末３０に送信したレセプトデータに対応する療養費支払データの入力を待つ療養費支払待ち状態となる（療養費支払データ入力待ち処理ステップ）（図１１ステップＳ３）。
【００７０】
次に、図９（ａ）に示すように、決済処理部２５は、療養費支払データの入力待ち状態において、金融機関端末４０に対してレセプトデータとともに療養費立替を依頼する立替依頼データを送信する（立替依頼処理ステップ）（図１１ステップＳ４）。
【００７１】
金融機関端末４０から受けた立替実行データの通知を受け、図９（ｂ）に示すように、決済処理部２５は、立替実行データを接骨院端末１０に転送する（立替支払通知処理ステップ）（図１１ステップＳ５）。金融機関Ｅから接骨院Ｂに対して療養費立替支払が実行される。
【００７２】
ここで、仲介処理コンピュータ２０の決済処理部２５は、立替依頼処理ステップ実行により療養費支払待ち処理ステップの待ち状態を解消するとともに金融機関端末４０に対して療養費支払待ち処理ステップを引き継がせる（待ち状態引継ぎ処理ステップ）（図１１ステップＳ６）。
【００７３】
一方、金融機関端末４０は、仲介処理コンピュータ２０から立替依頼データを受けると、仲介処理コンピュータ２０の療養費支払待ち処理ステップおよびその待ち状態を引き受ける（待ち状態引受け処理ステップ）。
【００７４】
この後、保険者Ｄからレセプトに応じた療養費の支払い実行により、仲介処理が終了するわけであるが、保険者Ｄからレセプトに応じた療養費の支払い先についてはバリエーションがありえる。
第１のパターンは保険者Ｄからタイムラグを担っている金融機関Ｅに直接療養費を支払うパターンである。
第２のパターンは保険者Ｄから仲介機関Ｃに一旦療養費を支払い、仲介機関Ｃから療養費を金融機関Ｅに支払うパターンである。
【００７５】
ここでは、上記の第１のパターンを採るものとする。第１のパターンの場合、図８（ｂ）に示すように再代理権申請データによれば保険者Ｄは療養費を支払う先が仲介機関Ｃとなっているので、金融機関Ｅが直接受け取るためには金融機関Ｅが仲介機関Ｃに代わって代理受領の旨を保険者Ｄに通知する必要がある。そこで、図１０（ａ）に示すように、仲介処理コンピュータ２０の決済処理部２５は、保険者端末３０に対して、金融機関端末４０が仲介処理コンピュータ２０に代わって療養費支払データを代理受信する旨の代理受信申請データを通知する（代理受信申請処理ステップ）（図１１ステップＳ７）。
【００７６】
保険者端末３０は、代理受信申請データに従い、療養費支払データ送信先を仲介処理コンピュータ２０に代えて金融機関端末４０に変更する（送信先変更処理ステップ）。
【００７７】
なお、金融機関端末４０および仲介処理コンピュータ２０において、以下の療養費支払、仲介処理完了の確認をとる処理を実行する。
図１０（ｂ）に示すように、保険者端末３０は、仲介処理コンピュータ２０からのレセプトデータの受信後（図１２ステップＳ１）、レセプト審査を行い（図１２ステップＳ２）、レセプト審査の結果、正しいものと判断できれば（図１２ステップＳ３：Ｙ）、レセプトに従い、療養費支払いデータを金融機関端末４０に送信する（図１２ステップＳ４）。なお、レセプトの審査の結果、誤りと判断できれば（図１２ステップＳ３：Ｎ）、レセプトの返戻処理を行う。
【００７８】
金融機関端末４０は、保険者端末３０からの療養費支払データを代理受信すると（療養費支払データ代理受信処理ステップ）（図１３ステップＳ１）、立て替えた療養費立替支払データと代理受信した療養費支払データとを突き合わせる（突き合わせ処理ステップ）（図１３ステップＳ２）。突き合わせにより対応し合う療養費支払データが確認できた療養費立替支払データについては（図１３ステップＳ３：Ｙ）、確認完了データを仲介処理コンピュータ２０に対して送信する（確認処理ステップ）（図１３ステップＳ４）。突き合わせにより対応し合う療養費支払データが確認できない場合、エラー処理を実行する（図１３ステップＳ３：Ｎ）。
【００７９】
仲介処理コンピュータ２０の決済処理部２５は、金融機関端末４０から確認完了データの送信を受け、保険支払請求−療養費支払の仲介処理完了を確認し、決済情報データベースに反映する（仲介完了確認処理ステップ）。
【００８０】
以上、実施例１にかかる保険支払請求−療養費支払仲介システムにおける仲介処理コンピュータ２０を中心とする、レセプト作成処理および療養費の保険請求処理の流れ、療養費の決済処理の流れである。
【実施例２】
【００８１】
実施例２にかかる保険支払請求−療養費支払仲介システムは、レセプトデータの作成も仲介処理コンピュータ２０が行う構成例である。
図１４は、実施例２にかかる保険支払請求−療養費支払仲介システムの構成を示すブロック図である。図１４に見るように、実施例１にかかる保険支払請求−療養費支払仲介システムに比べ、レセプトデータ処理部１３の代わりに療養データ処理部１７が設けられており、レセプトデータの作成は接骨院端末１０ａでは行われず、仲介処理コンピュータ２０のレセプトデータ処理部２３において行われる構成となっている。
レセプトデータ処理部２３は、接骨院端末１０ａより施術内容を示す施術データが入力されると、施術データを基に保険情報データベース２４にアクセスしつつレセプトデータを作成する機能を備えている。
他の構成要素、処理内容については実施例１のものと同一で良く、ここでの説明は省略する。
【実施例３】
【００８２】
本発明にかかる保険支払請求−療養費支払仲介システムの処理ステップをコンピュータプログラムとして記述すれば、保険支払請求−療養費支払仲介処理プログラムとして提供することができる。つまり、本発明の保険支払請求−療養費支払仲介処理プログラムは、上記した実施例１乃至実施例２のいずれかに示した本発明にかかる保険支払請求−療養費支払仲介システムの処理ステップをコンピュータプログラムとして記述されたものとして、コンピュータ読み込み可能な記憶媒体に担持させた形やコンピュータネットワークを介したダウンロードの形にて提供することができる。
【００８３】
以上、本発明の保険支払請求−療養費支払仲介システムの構成例における好ましい実施形態を図示して説明してきたが、本発明の技術的範囲を逸脱することなく種々の変更が可能であることは理解されるであろう。
【産業上の利用可能性】
【００８４】
本発明の保険支払請求−療養費支払仲介システムは、レセプトを取り扱う医療システムに広く適用することができる。
【図面の簡単な説明】
【００８５】
【図１】従来技術の図１５に示した構成の場合のタイムラグ負担を示す図
【図２】従来技術の図１６に示した構成の場合（パターン１）のタイムラグ負担を示す図
【図３】従来技術の図１６に示した構成の場合（パターン２）のタイムラグ負担を示す図
【図４】本発明の保険支払請求−療養費支払仲介システムの場合のタイムラグ負担を示す図
【図５】実施例１にかかる本発明の保険支払請求−療養費支払仲介システムの構成を示すブロック図
【図６】患者情報登録時の流れを示すフローチャート
【図７】接骨院Ｂにおける療養行為時の処理の流れを示すフローチャート
【図８】仲介処理コンピュータ２０における仲介処理の流れを模式的に示す図（その１）
【図９】仲介処理コンピュータ２０における仲介処理の流れを模式的に示す図（その２）
【図１０】仲介処理コンピュータ２０における仲介処理の流れを模式的に示す図（その３）
【図１１】仲介処理コンピュータ２０における仲介処理の流れを示すフローチャート
【図１２】保険者端末３０におけるレセプト審査および療養費支払処理の流れを示すフローチャート
【図１３】金融機関端末４０における決済処理を中心とする流れを示すフローチャート
【図１４】実施例２にかかる保険支払請求−療養費支払仲介システムの構成を示すブロック図
【図１５】従来の一般的な接骨院における外来型のマッサージの診療報酬の支払請求と審査および支払いの概略を示す図
【図１６】特開２００１−３４４３３７号公報に開示された従来技術を説明する図
【符号の説明】
【００８６】
１０，１０ａ  接骨院端末
１１  患者情報管理部
１２  患者情報データベース
１３  レセプトデータ作成部
１４  保険情報データベース
１５  決済処理部
１６  決済情報データベース
１７  療養データ処理部
２０  仲介処理コンピュータ
２１  患者情報管理部
２２  患者情報データベース
２３  レセプトデータ処理部
２４  保険情報データベース
２５  決済処理部
２６  決済情報データベース
３０  保険者端末
４０  金融機関端末
【図１】
0005196948.tif 000002
【図２】
0005196948.tif 000003
【図３】
0005196948.tif 000004
【図４】
0005196948.tif 000005
【図５】
0005196948.tif 000006
【図６】
0005196948.tif 000007
【図７】
0005196948.tif 000008
【図８】
0005196948.tif 000009
【図９】
0005196948.tif 000010
【図１０】
0005196948.tif 000011
【図１１】
0005196948.tif 000012
【図１２】
0005196948.tif 000013
【図１３】
0005196948.tif 000014
【図１４】
0005196948.tif 000015
【図１５】
0005196948.tif 000016
【図１６】
0005196948.tif 000017