JP2008191955A - 支払請求事務代行システム - Google Patents

Abstract

【課題】 レセプトの作成を医療機関側による診療内容の申告のみに頼らず、客観的に診療内容を確認しつつレセプトを作成するシステムを提供する。
【解決手段】 医療機関が管理する医療機関システムとレセプト審査支払機関が管理する審査システムとの間に介在し、診療報酬請求事務を代行するシステム１０であり請求事務代行主体が管理する。患者確認部１１により患者から入力された患者ＩＤ情報を基に患者を特定・確認する。診療データ収集部１２により患者に施した診療内容を記述した診療データを医療機関システム２０から受信する。内容確認処理部１３により診療内容を患者に直接提示し、患者の患者ＩＤ情報の入力とともに診療内容の確認入力を受け付ける。レセプトデータ作成・送信部１４は内容確認処理部１３において診療内容が正しいと確認された場合のみレセプトデータを作成し、審査システム３０に送信する。
【選択図】 図１

Description

本発明は診療報酬や介護報酬や療養費などの支払請求事務代行システムに関する。より詳しくは、本発明は、事務作業が低減され効率的なレセプト作成処理と、不正請求ができない客観的な診療報酬や介護報酬や療養費の支払請求事務代行処理とを可能にした支払請求事務代行システムに関する。
ここで、レセプトとは、診療報酬や介護報酬や療養費の支払いを請求するためレセプト審査支払機関（国民健康保険団体連合会(国保連)、社会保険診療報酬支払基金(支払基金)）に対して提出する支払請求申請書のことである。

健康保険制度や国民健康保険制度の下では、患者に対する医療手術、投薬、検査などの医療行為ごとに診療報酬が決められており、これら医療行為を患者に施した医療機関は診療報酬のルールに則り、作成したレセプトを使って患者が所属する保険者に診療費の支払いを求める（例えば、非特許文献１参照）。
接骨院、鍼灸院、按摩マッサージ院など長期に療養が継続されるものは療養内容ごとに療養費が決められており、これら療養行為を施した療養型期間は療養費請求のルールに則り、作成したレセプトを使って患者が所属する保険者に療養費の支払いを求める。
また同様に、介護保険制度の下、要介護者に対する介護の内容ごとに介護報酬も定められており、これら介護行為を施した介護機関は介護報酬のルールに則り、作成したレセプトを使って介護保険者に介護報酬の支払いを求める。

図１８は、従来の一般的なレセプトを使用した、医療機関などでの診療報酬や介護機関などでの介護報酬請求の請求と審査および支払いの概略を示す図である。来院型と訪問型では施術スタイルが異なるものの、支払いの流れや医療機関・介護機関と審査機関との関係などは基本的には同じである。
例えば、患者Ａは初診時に医療機関（病院、診療所、薬局、歯科）Ｂに対して保険証を提示し、問診表などを書き込んだ後、治療を受ける。その後窓口で診療費の自己負担分（例えば１割や３割）を支払う。
一方、医療機関Ｂは医療行為に対するレセプトを作成し、各都道府県のレセプト審査支払機関（国保連、支払基金）Ｃに送致し、レセプト審査支払機関Ｃは審査担当者（指定医師など）によりレセプトの正当性を審査し、それが正当であれば保険者（市町村国民保健組合、共済組合、健保組合）Ｄに通知する。保険者Ｄはレセプト審査支払機関Ｃに支払い承認をし、レセプト審査支払機関Ｃは医療機関Ｂに診療報酬の支払いをする。

医療機関が作成するレセプトには、患者の所属保険、患者の名前、病名、手術の種類、使用した薬の名前と量など１カ月分の診療内容が紙に記載される。レセプトの審査は、医師や歯科医師などで構成される審査委員会で審査され、レセプトの内容が診療報酬のルールに則しているかどうかを１枚ずつチェックし、不正請求やルールから外れた不当請求であれば指定解除などもあり得る。

上記の従来の流れにおいては、健康保険・国民健康保険等の診療報酬請求事務（レセプト処理）は、病院や開業医、薬局等がそれぞれ行った診療費用または薬品に対して、病院、開業医、薬局等がそれぞれ自分で請求事務を行っていた。すなわち、各企業（健康保険組合等）の組合員や地方公共団体（国民健康保険等）の加入者（被保険者）が医療機関で健康診断や病気の治療を受けた場合、それぞれについて医療費が計算され、一部（１割負担、３割負担）は組合員や加入者本人に対して請求され、残りの部分は医療機関でレセプト事務処理が行われ、レセプト審査支払機関に対してレセプト請求が行われる。

投薬に関する支払いにおいてもレセプト処理が行われる。医療機関が院外処方箋を出すことにより、調剤薬局から患者（組合員や加入者）に出された薬剤等の費用は、調剤薬局からレセプト審査支払機関にレセプト請求され、その後、医療機関、調剤薬局等から厚生省・都道府県知事・地方社会保険事務長宛等に対して、許認可事項等についての各種申請を各自で行っていた。

図１９は、従来の一般的な接骨院、柔整院での療養費の請求と審査および支払いの概略を示す図である。
患者Ａは初診時に接骨院・柔整院Ｂに対して保険証を提示し、問診表などを書き込んだ後、治療を受ける。その後窓口で療養費の自己負担分（例えば１割や３割）を支払う。
なお、長期の療養が必要な接骨院などでは療養費支払請求の際には療養費支給申請書が必要である。この療養費支給申請書には患者のサインが必要であるところ、支払請求のためのレセプト作成処理およびレセプト送付処理のタイミングと患者の来院のタイミングが合わないので、レセプト作成・送付時に患者のサインをもらうことが事実上難しく、現状は、初診時に患者に対してサインをもらい、白紙委任を取り付けているのが実情となっている。
接骨院・柔整院Ｂは施術行為に対するレセプトを作成し、直接保険者（市町村国民保健組合、共済組合、健保組合）Ｄに通知する。保険者Ｄはレセプトの正当性を審査し、それが正当であれば医療機関Ｂに診療報酬の支払いをする。

ここで、図１８、図１９に見るように、従来から、レセプトの作成を病院、開業医、薬局等が自ら請求事務を行っていたため不適切な診療報酬や療養費の支払請求が問題となっていた。不適切な診療報酬や療養費の支払請求には過失による過誤請求もあれば故意による不正請求もある。過失による過誤請求であれば診療内容と保険点数の適合性チェック、保険点数計算の再計算チェックなどチェック方法を工夫すれば防止しやすい。しかし、故意による不正請求はチェックする方法が難しいと言われている。

第１の問題は、患者に対する診療内容や施術内容が実際に行われた内容であるのか否かは第三者がチェックできず、医療機関や療養型機関の自己申告をそのまま信じて診療報酬や療養費を計算せざるを得ず、不正請求の温床となっている。

第２の問題は、接骨院での接骨治療など長期に繰り返し通院する治療の場合、療養費支給申請書のサインは初診時に行い、内容については白紙委任している状況であるので、接骨院側の架空診療の書き込みをそのまま信じて療養費を計算せざるを得ず、不正請求の温床となっている。
レセプト支払審査機関は、大量のレセプト審査を行っており、上記のような不正請求に対して十分なチェックを行うことが難しい現状がある。
不適切な支払請求を防止する従来技術としては、例えば特開２０００−２０６０８号公報に記載の『医療事務処理システム及びそのプログラム記録媒体』がある。これは医療機関において、各種医療事務を管理するレセプトシステムと各受付窓口で料金授受（一時負担金の精算）を管理するレジスタシステムとは互いに連動していなかったので、これを連動させ、レセプト事務と窓口会計とを一本化するものである。これは主に過失による診療報酬の過誤請求を防止する技術と言える。

また、特開２００２−２８８３３６号公報に開示された技術は、診療報酬請求事務処理の煩わしさを解消することを主目的として開発された技術であり、診療報酬請求事務の代行処理が主機能であるシステムとなっているが、診療報酬の不正請求を防止する機能が一部盛り込まれている。当該システムは病院等の医療機関・調剤薬局の装置からインターネット等を介して送られてきた患者ＩＤカード番号と、該患者が診療を受けた診療情報とを受信すると、当該患者が加入している保険の計算をした上で請求書を作成して、該請求書を含む情報を該医療機関の装置に返送し、診療報酬請求事務代行システムは、医療機関の装置から受信した情報および上記請求書の情報を患者診療行為情報として、患者基本情報とともに蓄積しておき、レセプト請求可否確認処理の際に、上記患者診療情報を参照することにより、該当する患者が病院で受診したか否かの確認をとって、該確認の結果により、請求可否の判定を行うことを特徴としている。

その中で開示されている不正請求を防止する技術（同公報図２など）とは、システムが患者基本情報ＤＢ７１を装備しておくとともに、医療機関は自前の診察カードを発行せずにシステム運営者が各医療機関に共通な患者ＩＤカードを発行することを前提として、受診時に患者ＩＤカードを提示させて診療を受けさせ、レセプトを作成する際にその患者ＩＤカード番号を含めた形でレセプトを作成する。この作成したレセプトデータを患者基本情報ＤＢ７１のデータと突き合わせることによりチェックを行い、整合がとれた場合にレセプト審査支払機関に送る技術である。

診療報酬請求書（昭和５９年９月２８日厚生省告示第１７２号） 特開２０００−２０６０８号公報 特開２００２−２８８３３６号公報

上記従来技術では、故意の不正請求に対しては依然確実にはチェックしたり防止したりすることが難しいという問題点がある。
医療機関による故意の不正請求を防止する手立てとしては、まず第１はレセプトの作成を各医療機関自らが作成するのではなく第三者機関が行うことが有効である。さらに、第三者機関がレセプト作成にあたり各医療機関からの申告のみではなく、各医療機関ではない他者による申告や確認を取ることが有効である。

しかし、特開２０００−２０６０８号公報に開示された技術では、レセプトの作成自体は依然、各医療機関自らが作成するものであり、レセプトの第三者作成については何も開示がなく、医療機関による診療報酬の故意の不正請求を防止する手立てとしては不十分である。

一方、特開２００２−２８８３３６号公報に開示された技術では、レセプトの作成自体は第三者機関（診療報酬請求事務代行・情報サービス装置）が行う仕組みが開示されている。しかし、特開２００２−２８８３３６号公報に開示された技術では、患者が診療機関の窓口で提示する患者ＩＤカードの患者ＩＤカード番号と、各医療機関自らの診療内容の申告に含まれた患者ＩＤカード番号を突き合わせることが唯一のチェック事項であり、患者ＩＤカード番号が合致する限り、第三者機関は各医療機関からの申告内容のみに基づいてレセプトが作成されてしまう。

診療報酬の不正請求が行われる要因は多数ある。特開２００２−２８８３３６号公報では、患者ＩＤカード番号をチェックキーとしているが、例えば、患者が実際に来院し、正当な患者ＩＤカードを提示して受付を行った後は、診療内容の水増しが可能である。患者ＩＤカード番号のみがチェックキーであるので、受付により患者ＩＤカード番号が入力された後は、当該患者ＩＤカード番号を含める限り診療内容の申告は正当なものとして認証されてしまい、実際には行っていない診療内容を含めて診療内容を申告してしまえば診療報酬の不正請求が可能となる。不正請求により１割や３割など自己負担する患者の負担分も増えるが、余程ルーチン化された同じ内容の診療行為が続かない限り、窓口での料金支払い時には請求額のみでは患者は医療機関側の不正請求には気が付かないことがほとんどである。

上記問題点に鑑み、本発明の第１の目的は、レセプトの作成を第三者機関により行うことを基本とし、医療機関、介護機関、療養型機関による自己申告のみに頼らず、客観的に診療内容、介護内容、療養内容を確認しつつレセプトを作成し、医療機関側による意図的な不正請求を確実に防止できる支払請求事務代行システムを提供することを目的とする。
また、本発明の第２の目的は、医療機関、介護機関、療養型機関に義務付けられている厚生省や都道府県等の行政機関に対する許認可申請や内容変更の届出等の事務手続きを代行することにより、煩雑な事務手続のための人手と作業時間をなくすことができる支払請求事務代行システムを提供することにある。

上記目的を達成するため、患者が医療機関に来院するいわゆる来院型医療にかかる本発明の支払請求事務代行システムは、医療機関が管理する医療機関システムとレセプト審査支払機関が管理する審査システムとの間に介在し、診療報酬の支払請求事務を代行する支払請求事務代行主体が管理する支払請求事務代行システムであって、
前記医療機関に来院した患者から入力されたＩＤ情報を基に前記患者を特定・確認し、患者管理番号を前記医療機関システムに通知する患者確認部と、
前記医療機関で前記患者に施した診療内容を記述した診療データを前記患者管理番号とともに前記医療機関システムから受信する診療データ収集部と、
前記診療内容を前記患者に直接提示し、前記患者のＩＤ情報の入力とともに前記診療内容の確認入力を受け付ける内容確認処理部と、
前記内容確認処理部において前記診療内容が正しいと確認入力されたことを条件としてレセプトデータを作成し、前記審査システムに送信するレセプトデータ作成・送信部とを備えたものである。
いわゆる来院型医療にかかる支払請求事務代行システムにおいて、内容確認処理部を用いた患者自身による診療内容の確認処理とレセプトデータ作成・送信部によるレセプト作成処理を確実に連動させており、診療内容が患者自身によって確実に確認されたもののみレセプトデータとして作成され、不正請求や間違った請求が低減される。

次に、上記目的を達成するため、要介護者が介護施設に来院するいわゆる来院型介護にかかる本発明の請求事務代行システムは、介護機関が管理する介護機関システムとレセプト審査支払機関が管理する審査システムとの間に介在し、介護報酬の支払請求事務を代行する支払請求事務代行主体が管理する支払請求事務代行システムであって、
前記介護機関に来院した要介護者から入力されたＩＤ情報を基に前記要介護者を特定・確認し、要介護者管理番号を前記介護機関システムに通知する要介護者確認部と、
前記介護機関で前記要介護者に施した介護内容を記述した介護データを前記要介護者管理番号とともに前記介護機関システムから受信する介護データ収集部と、
前記介護内容を前記要介護者に直接提示し、前記要介護者のＩＤ情報の入力とともに前記介護内容の確認入力を受け付ける内容確認処理部と、
前記内容確認処理部において前記介護内容が正しいと確認入力されたことを条件としてレセプトデータを作成し、前記審査システムに送信するレセプトデータ作成・送信部とを備えたものである。
いわゆる来院型介護にかかる支払請求事務代行システムにおいて、内容確認処理部を用いた要介護者自身による介護内容の確認処理とレセプトデータ作成・送信部によるレセプト作成処理を確実に連動させており、介護内容が要介護者自身によって確実に確認されたもののみレセプトデータとして作成され、不正請求や間違った請求が低減される。
次に、上記目的を達成するため、患者が接骨院、鍼灸院、按摩マッサージ院などの療養型機関に来院するいわゆる来院型療養にかかる本発明の請求事務代行システムは、療養型機関が管理する療養機関システムとレセプト審査支払機関が管理する審査システムとの間に介在し、療養費の支払請求事務を代行する支払請求事務代行主体が管理する支払請求事務代行システムであって、
前記療養型機関に来院した患者から入力されたＩＤ情報を基に前記患者を特定・確認し、患者管理番号を前記療養機関システムに通知する患者確認部と、
前記療養機関で前記患者に施した療養内容を記述した療養データを前記患者管理番号とともに前記医療機関システムから受信する療養データ収集部と、
前記療養内容を前記患者に直接提示し、前記患者のＩＤ情報の入力とともに前記療養内容の確認入力を受け付ける内容確認処理部と、
前記内容確認処理部において前記療養内容が正しいと確認入力されたことを条件としてレセプトデータを作成し、前記審査システムに送信するレセプトデータ作成・送信部とを備えたものである。
いわゆる来院型療養にかかる支払請求事務代行システムにおいて、内容確認処理部を用いた患者自身による療養内容の確認処理とレセプトデータ作成・送信部によるレセプト作成処理を確実に連動させており、療養内容が患者自身によって確実に確認されたもののみレセプトデータとして作成され、不正請求や間違った請求が低減される。
次に、上記目的を達成するため、医療スタッフが患者のもとへ訪問して施術するいわゆる訪問型医療の本発明の支払請求事務代行システムは、訪問する医療スタッフが携帯する携帯端末とレセプト審査支払機関が管理する審査システムとの間に介在し、診療報酬の支払請求事務を代行する支払請求事務代行主体が管理する支払請求事務代行システムであって、
前記携帯端末を介して患者から入力され送信されたＩＤ情報を基に前記患者を特定・確認する患者確認部と、
訪問した前記医療スタッフが前記患者に施した診療内容を記述した診療データを前記携帯端末から受信する診療データ収集部と、
前記携帯端末の画面を介して前記診療内容を前記患者に直接提示し、前記患者のＩＤ情報の入力とともに前記診療内容の確認入力を受け付ける内容確認処理部と、
前記内容確認処理部において前記診療内容が正しいと確認入力されたことを条件としてレセプトデータを作成し、前記審査システムに送信するレセプトデータ作成・送信部とを備えたものである。
いわゆる訪問型医療にかかる支払請求事務代行システムにおいても、内容確認処理部を用いた患者自身による診療内容の確認処理とレセプトデータ作成・送信部によるレセプト作成処理を確実に連動させており、診療内容が患者自身によって確実に確認されたもののみレセプトデータとして作成され、不正請求や間違った請求が低減される。
次に、上記目的を達成するため、介護スタッフが要介護者のもとへ訪問して介護するいわゆる訪問型介護にかかる本発明の支払請求事務代行システムは、訪問する介護スタッフが携帯する携帯端末とレセプト審査支払機関が管理する審査システムとの間に介在し、介護報酬の支払請求事務を代行する支払請求事務代行主体が管理する支払請求事務代行システムであって、
前記携帯端末を介して要介護者から入力され送信されたＩＤ情報を基に前記要介護者を特定・確認する要介護者確認部と、
訪問した前記介護スタッフが前記要介護者に施した介護内容を記述した介護データを前記携帯端末から受信する介護データ収集部と、
前記携帯端末の画面を介して前記介護内容を前記要介護者に直接提示し、前記要介護者のＩＤ情報の入力とともに前記介護内容の確認入力を受け付ける内容確認処理部と、
前記内容確認処理部において前記介護内容が正しいと確認入力されたことを条件としてレセプトデータを作成し、前記審査システムに送信するレセプトデータ作成・送信部とを備えた支払請求事務代行システム。
いわゆる訪問型介護にかかる支払請求事務代行システムにおいても、内容確認処理部を用いた要介護者自身による介護内容の確認処理とレセプトデータ作成・送信部によるレセプト作成処理を確実に連動させており、介護内容が要介護者自身によって確実に確認されたもののみレセプトデータとして作成され、不正請求や間違った請求が低減される。
次に、上記目的を達成するため、療養スタッフが患者のもとへ訪問して療養するいわゆる訪問型療養にかかる本発明の支払請求事務代行システムは、訪問する療養スタッフが携帯する携帯端末とレセプト審査支払機関が管理する審査システムとの間に介在し、療養費の支払請求事務を代行する支払請求事務代行主体が管理する支払請求事務代行システムであって、
前記携帯端末を介して患者から入力され送信されたＩＤ情報を基に前記患者を特定・確認する患者確認部と、
訪問した前記療養スタッフが前記患者に施した療養内容を記述した療養データを前記携帯端末から受信する療養データ収集部と、
前記携帯端末の画面を介して前記療養内容を前記患者に直接提示し、前記患者のＩＤ情報の入力とともに前記療養内容の確認入力を受け付ける内容確認処理部と、
前記内容確認処理部において前記療養内容が正しいと確認入力されたことを条件としてレセプトデータを作成し、前記審査システムに送信するレセプトデータ作成・送信部とを備えたものである。
いわゆる訪問型療養にかかる支払請求事務代行システムにおいても、内容確認処理部を用いた患者自身による療養内容の確認処理とレセプトデータ作成・送信部によるレセプト作成処理を確実に連動させており、療養内容が患者自身によって確実に確認されたもののみレセプトデータとして作成され、不正請求や間違った請求が低減される。

次に、上記診療報酬請求事務代行システムにおいて、前記患者ＩＤ情報が患者のバイオメトリックス情報を含むものであることが好ましい。
患者のバイオメトリックス情報を用いれば偽造は極めて困難であり、より一層、不正請求などが低減される。
さらに、前記患者確認部において入力を求める前記患者のバイオメトリックス情報と、前記内容確認処理部において入力を求める前記患者のバイオメトリックス情報とを異なる部位のバイオメトリックス情報とすることも好ましい。
複数のバイオメトリックス情報を組み合わせることによりより一層偽造が困難となり、不正請求などが低減される。

さらに、前記患者の複数の部位のバイオメトリックス情報を登録しておき、確認部において入力を求める前記患者のバイオメトリックス情報と、前記内容確認処理部において入力を求める前記患者のバイオメトリックス情報とを動的に選択して入力させることも好ましい。
上記構成により、毎回バイオメトリックス情報を入力する部位が動的に選択されるので、より一層偽造が困難となり、不正請求などが低減される。

次に、上記診療報酬請求事務代行システムにおいて、上記のレセプト作成・診療報酬請求事務代行処理に加え、レセプトに基づく診療報酬請求権を債権として債権買取処理機能を加えた構成も好ましい。例えば、レセプトに基づく支払請求権を債権として買い取る旨の債権買取申込情報を表示する機能と、前記債権の買い取りを認める旨の債権買取承諾情報の入力を受け付ける機能と、両者間の債権売買契約が成立した場合に債権売買契約データを作成する機能を備えた債権売買契約締結部を備え、前記内容確認部による確認入力処理と、前記債権売買契約締結部による前記債権買取申込情報の表示処理とを連動せしめたことを特徴とする構成である。

また、レセプトに基づく診療報酬請求権を債権として債権買取処理機能を加え別の以下の構成も好ましい。例えば、レセプトに基づく支払請求権を債権として買い取る旨の債権買取申込情報を表示する機能と、前記債権の買い取りを認める旨の債権買取承諾情報の入力を受け付ける機能と、両者間の債権売買契約が成立した場合に債権売買契約データを作成する機能を備えた債権売買契約締結部を備え、前記内容確認部による確認入力処理と、前記レセプトデータ作成・送信部による前記レセプトデータの作成処理と、前記債権売買契約締結部による前記債権買取申込情報の表示処理とを連動せしめたことを特徴とする構成である。

本発明の診療報酬請求事務代行システムによれば、上記構成により、レセプト作成を医療機関以外の第３者である請求事務代行主体によってレセプトを客観的に作成することができ、かつ、診療内容に関して医療機関の自己申告のみに頼らず、レセプト作成前に患者に対して診療内容の確認を取ることにより実際の診療内容とレセプトに書き込まれる診療内容とが合致していることを確実に確認した後でレセプトを作成することができる。診療報酬の水増し請求や架空請求を確実に防止することができる。

また、上記した内容確認処理部においてバイオメトリックス認証を用いる構成では、内容確認処理部を介した患者による診療内容の認否において、勝手に他人が診療内容の確認ができないよう、患者自身が実際に確認することを必須の構成とすることができ、不正が入り込む余地を失くすことができる。
また、上記した患者確認部において確認入力時にバイオメトリックス認証を用いる構成では、患者が確実に本人であり、いわゆる「なりすまし」による不正受診を防止することができる。

また、上記した内容確認部による確認入力処理と債権売買契約締結部による債権の買い取り処理を連動せしめた構成では、患者や要介護者から直接内容が正しいと確認されたもののみに対して医療機関側に診療報酬の債権の買い取り処理を進めることができ、不正診療報酬請求が介在する余地がなくなる。
また、上記した内容確認部による確認入力処理とレセプトデータ作成送信部によるレセプトデータ作成処理と債権売買契約締結部による債権の買い取り処理を連動せしめた構成では、患者や要介護者から直接内容が正しいと確認されたもののみに対してレセプトの作成処理と医療機関側に診療報酬の債権の買い取り処理を進めることができ、不正診療報酬請求が介在する余地がなくなる。
なお、上記債権買い取り処理は、レセプトに基づく診療報酬請求権を債権と見て債権買い取り処理を行なう仕組みである。ここで、本発明の診療報酬請求事務代行システムでは診療報酬請求の内容に不正が介在する余地がないため保険者から必ず診療報酬が支払われるので、診療報酬の受け取りは債権回収ではなく取立て委任方式による立替金の受け取りと位置づけることもできる。つまり、診療報酬請求の受け取りは上記の債権買い取り処理と位置づけず立替金の取立て委任処理と位置づけることもできる。

以下、本発明を実施するための最良の形態について実施例により具体的に説明する。なお、本発明はこれらの実施例に限定されるものではない。

実施例１として、患者が来院するいわゆる来院型の診療報酬請求事務代行システムの構成例を、図面を参照しつつ説明する。なお、介護者が来院するいわゆる来院型の介護報酬請求事務代行システムの構成も同様で良い。
以下の説明において医療機関は特に限定されず、総合病院、医院、接骨院、歯科医院、調剤薬局など、社会保険制度の利用が可能で診療報酬請求事務が生じる機関であれば本発明のシステムを導入する対象機関となる。なお、介護報酬請求事務代行システムの場合は、介護機関も特に限定されず、介護施設、介護付き老人ホーム、介護付きマンションなど介護保険制度の利用が可能で介護報酬請求事務が生じる機関であれば良い。

図１は、本発明の実施例１にかかる来院型の診療報酬請求事務代行システムのブロック図である。図１において、１０は本発明の中心的な役割を果す診療報酬請求事務代行システムであり、２０は病院等の医療機関が設置・管理する医療機関システム、３０は支払基金・国保連合会等のレセプト審査支払機関が設置・管理している審査システム、４０は自治体等（国民健康保険等）および各企業等（健康保険組合等）の保険者が設置・管理している保険者システム、５０は国民健康保険等や健康保険組合等の被保険者である患者である。
ここで、診療報酬請求事務代行システム１０は、医療機関システム２０と審査システム３０との間に介在し、両者間におけるレセプトデータの作成処理の代行実行と、診療報酬請求事務処理の代行実行するものである。なお、診療報酬請求事務代行システム１０を設置・管理する主体は、請求事務代行主体であり、医療機関の一組織ではなく、医療機関組織から独立した存在であることが好ましい。

診療報酬請求事務代行システム１０の各構成要素について説明する。
患者確認部１１は、医療機関に来院した患者５０から入力された患者ＩＤ情報を基に患者５０を特定・確認し、患者管理番号を医療機関システムに通知する部分である。
この構成例では、医療機関の窓口に設置されるいわゆる窓口端末２１の一部に患者ＩＤ情報入力部１１１が組み込まれている。患者ＩＤ情報入力部１１１の設置・管理は、請求事務代行主体が行っても良く、医療機関が行っても良い。前者の場合は、請求事務代行主体が診療報酬請求事務代行システム１０の一部として医療機関に供給または貸与して医療機関システム２０に組み込むこととなり、後者の場合は、医療機関側が医療機関システム２０の一部として購入・設置して組み込むこととなる。

患者ＩＤ情報入力部１１１は、医療機関に来院した患者５０から患者ＩＤ情報の入力を受け付ける部分である。ここで、患者ＩＤ情報は、患者を特定・識別する情報である。システムのセキュリティレベルにより扱う患者ＩＤ情報は多様であるが、例えば、患者個人に発行された患者ＩＤカードが挙げられる。患者ＩＤカードとして、患者管理番号などをコード化した情報を磁気ストライプに書き込んだいわゆる磁気カードや、ＩＣチップに格納したいわゆるＩＣカードなどがあり得る。なお、患者ＩＤ情報としてバイオメトリックス情報を採用することは好ましい。例えば、手のひらや指の静脈パターンをバイオメトリックス情報として読み取る静脈認証、指の指紋をバイオメトリックス情報として読み取る指紋認証、虹彩パターンをバイオメトリックス情報として読み取る虹彩認証などは、いわゆる「なりすまし」が困難であり本発明のレセプト作成・診療報酬請求事務代行において不正を防止するセキュリティを向上させるには有効な認証方法といえる。

本実施例１では指の静脈パターンを患者ＩＤ情報として採用し、患者確認部１１において静脈認証を伴う患者の特定を行うものとして説明する。
患者確認部１１は、患者ＩＤ情報入力部１１１を介して取得された患者ＩＤ情報を基に患者５０を特定する患者特定機能と、特定した患者５０に割り当てられている患者管理番号を医療機関システム２０に通知する患者管理番号通知機能を備えている。

患者特定機能は患者ＩＤ情報入力部１１１により読み取った患者ＩＤ情報をもとに患者を特定・識別する機能であるが、患者ＩＤ情報が磁気ストライプやＩＣチップから読み取ったコード情報であれば、当該コード情報を基に患者情報データベース１１２に格納されている情報と照合し、患者を特定・識別する。
なお、患者情報データベース１１２は患者ごとの諸情報を格納したデータベースであり、患者の名前、性別、年齢、保険種類などの患者属性を示す各種情報のほか患者ＩＤ情報も格納されている。患者ＩＤ情報がバイオメトリックス情報の場合、照合が予定されているバイオメトリックス情報、たとえば、指の静脈パターン情報、指紋情報、手のひらの静脈パターン情報、虹彩パターン情報などが格納されている。

患者管理番号通知機能は特定した患者５０に割り当てられている患者管理番号を医療機関システム２０に通知する機能であるが、当該患者管理番号は、医療機関側が各患者に割り振った番号でも良く、請求事務代行主体が各医療機関を横断的に共通して患者に割り振った番号でも良い。前者であれば、本発明の診療報酬請求事務代行システム導入に伴って医療機関システム２０のプログラム等の変更は必要ないが、医療機関個別のシステム構成となる。後者であれば、本発明の診療報酬請求事務代行システム導入に伴って医療機関システム２０の既存のプログラム等の変更が必要となるが、各医療機関システム２０で横断的に同じ患者管理番号が使用されることとなり親和性が向上する。
患者確認部１１により患者管理番号が医療機関システム２０に通知されると医療機関側は当該患者が受診のために来院したことを把握することができ、医療機関システム２０側において通常の窓口受付業務を行うことが可能となる。

１２は診療データ収集部であり、医療機関において患者に施した診療内容を記述した診療データを医療機関システム２０から受信する部分である。
医療機関では来院した患者に対して適切な診療行為を施すが、各診療行為には保険点数がつけられており、医療機関システム２０は施術された診療行為の入力を受け、患者に施した診療内容を記述した診療データを作成し、本発明の診療報酬請求事務代行システム１０に送信する。診療データ収集部１２は医療機関システム２０から診療内容を記述した診療データを受信する。

１３は内容確認処理部であり、患者５０に対して診療データに記述された診療内容を直接提示する表示機能と、患者５０から提示された診療内容が正しいか誤りかの確認入力を受け付ける確認機能とを備えている。従来では診療報酬の不正請求は、診療内容の水増し請求（例えば、接骨院での治療箇所を多く請求する）、実際には行っていない診療内容の架空請求（実際には行っていない治療を行ったとする）などがあるが、内容確認処理部１３はこの診療内容が正しいか否かをもっとも確実かつ簡便に確認する。

内容確認処理部１３の表示機能は窓口端末２１のモニタ上に診療内容を提示することにより実現しても良い。例えば、医療機関の窓口に設置されるいわゆる窓口端末２１のモニタを確認インターフェイス１３１とし、患者に対して診療内容の表示を行う。確認機能はこの窓口端末２１の確認インターフェイス１３１を介して確認入力を受けるものとし、例えば、タッチパネル方式の確認ボタンの押下により患者から直接診療内容が正しいか否かの意思表示を受け付けても良い。

ここで、内容確認処理部１３を介した患者による診療内容の確認入力に併せて患者のバイオメトリックス情報の入力を行わせる構成も好ましい。窓口端末２１上に設けた確認ボタンの押下のみでは、いわゆる「なりすまし」による確認ボタン押下という不正行為が介在するおそれがあるが、確認入力に併せて患者のバイオメトリックス情報の入力を行わせる構成とすれば、診療内容の確認は確実に患者本人が行うこととなり、いわゆる「なりすまし」による確認ボタン押下という不正行為が介在する余地がなくなる。

１４はレセプトデータ作成・送信部であり、診療データ収集部１２から診療データを受け取り、内容確認処理部１３での認否確認において患者５０より診療内容が正しいと確認入力された場合にのみ、当該診療データに基づいてレセプトデータを作成する機能と、作成したレセプトデータを審査システム３０に送信する機能を備えている。
内容確認処理部１３とレセプトデータ作成・送信部１４の連動処理により、レセプトデータ作成・送信部１４によりレセプトデータが作成される場合は常に患者により診療内容が確認されており、診療内容の水増し請求や診療内容の架空請求を確実に防止することができることとなる。
診療報酬は最終的には保険者に請求されるのであるが、その前にレセプトがレセプト審査機関において審査に付される。診療報酬請求事務代行システム１０では内容確認処理部１３により確認済みのレセプトデータがレセプトデータ作成・送信部１４により作成され送信される。

１５は保険情報データベースであり、自治体等、各企業等の基本情報（被保険者等の情報）および病院等の医療機関・調剤薬局の基本情報（認可申請等の情報）、および法改訂時における厚生省等が発行した診療報酬算定時に必要な情報などを格納しており、レセプトデータ作成・送信部１４は診療内容を保険点数化するときに保険情報データベース１５にアクセスして診療内容を保険点数化するための配点や計算式など必要な情報を取得することができる。

診療報酬請求事務代行システム１０を中心とした、レセプト作成処理および診療報酬請求事務代行処理の流れを説明する前に、各機関が保持・管理する各システムについて説明しておく。

医療機関システム２０は病院等の医療機関が設置・管理するシステムであり、いわゆるカルテの管理なども含めたいわゆる病院運営に必要な医療事務管理、診療報酬管理やレセプト管理を実行するシステムであるが、レセプト作成処理と診療報酬請求事務は本発明の診療報酬請求事務代行システムに譲るため含む必要はない。

審査システム３０は、支払基金・国保連合会等のレセプト審査支払機関が設置・管理しているシステムであり、レセプト審査に必要なレセプトデータ等の情報を受け取り、レセプト審査の結果情報（返戻通知情報等）を送り返す。本発明では医療機関システム２０と審査システム３０の間に診療報酬請求事務代行システム１０が介在しているので、レセプトデータ等の情報の受け取り、レセプト審査の結果情報の返信は診療報酬請求事務代行システム１０に対して行う。

保険者システム４０は自治体等（国民健康保険等）および各企業等（健康保険組合等）の保険者が設置・管理しているシステムであり、被保険者の情報を備え、レセプト審査機関が承認したレセプトデータに従い診療報酬請求に応じて保険支払処理などを行う。

以下、診療報酬請求事務代行システム１０を中心とした、レセプト作成処理および診療報酬請求事務代行処理の流れを説明する。なお、以下の流れにおいて、医療機関として患者が長期に繰り返し通院する接骨院を例に挙げて説明する。初診来院時の処理と、再来院の処理を分けて説明する。初診来院時の流れは図２のフローチャート、図３の流れ図、図４の流れ図にまとめられており、再来院時の流れは図５のフローチャート、図６の流れ図、図７の流れ図にまとめられており、各段階で適宜に他図を参照しつつ説明する。

（Ａ）初診来院の場合
患者５０は初診時、医療機関の窓口で初診来院手続きを行う。保険証を提示する（図２ステップＳ１）。
医療機関は保険番号の確認を含め必要な窓口手続きを行う。医療機関は患者管理番号を付す（図２ステップＳ２）。
次に、患者５０は、医療機関に設置された窓口端末２１の一部として組み込まれている患者確認部１１の患者ＩＤ情報入力部１１１を介して患者のＩＤ情報を入力する（図２ステップＳ３）。ここでは、バイオメトリックス情報を入力し、指の静脈パターンを入力するものとする。患者５０は患者ＩＤ情報入力部１１１に指を添えて静脈パターンを入力する。図３の流れ図の例は医療機関の窓口端末２１に付属されている患者ＩＤ情報入力部１１１に患者５０が指を添えて静脈パターンを入力する様子を模式的に示した図である。

患者確認部１１の患者情報データベース１１２において当該患者のバイオメトリックス情報を保険番号、医療機関が付した患者管理番号とともに格納する。なお、その他の患者の基本情報も併せて格納することが好ましい（ステップＳ４）。
次に、患者５０は疾病の状態を問診表に記入するなどし、診察に臨む。医療機関は患者に対して適切な診療行為を施す（図２ステップＳ５）。
医療機関は患者に対して施した診療内容を記述した診療データを患者管理番号とともに診療データ収集部１２に対して送信する（図２ステップＳ６）。

この実施例では、接骨院などで長期通院を必要とする疾病の場合を想定している。そこで初診診療している間に、療養費支給申請書を作成しておく。なお、医療機関において診察券を併用する運用の場合、ここで診察券も作成することが想定される。診療後、患者５０に対して療養費支給申請書のサインをしてもらう（図２ステップＳ７）。
内容確認処理部１３は診療データに記述された診療内容を患者に対して直接提示する（図２ステップＳ８）。たとえば、窓口端末２１のモニタ上に診療内容を表示する。

内容確認処理部１３は、患者５０から診療内容が正しいか誤りかの確認入力を受け付ける（図２ステップＳ９）。なお、この実施例では、内容確認処理部１３を介した診療内容の確認入力に併せて、患者５０のバイオメトリックス情報（静脈パターン）の入力を行わせる例とする。
患者５０が受けた診療内容が正しい場合は（図２ステップＳ９：Ｙ）、患者５０は確認入力を行う。この例では患者５０は患者ＩＤ情報入力部１１１に指を添えて静脈パターンも併せて入力する。

患者５０からの確認入力が行われた場合（図２ステップＳ９：Ｙ）、レセプトデータ作成・送信部１４は確認された診療内容に基づいて保険情報データベース１５にアクセスし保険点数を計算してレセプトデータを作成し、保険情報データベース１５に作成されたレセプトデータを蓄積する（図２ステップＳ１０）。
なお、この実施例では患者の自己負担分の明細データと請求金額データもレセプトデータ作成・送信部１４が作成する例とする。レセプトデータ作成・送信部１４は患者の自己負担分の明細データと請求金額データを作成するものとする。この実施例では、レセプトデータ作成・送信部１４は、医療機関システム２０に対して患者の自己負担分の明細データと請求金額データを送信する。

医療機関システム２０はレセプトデータ作成・送信部１４より渡された患者の自己負担分の明細データと請求金額データを基に患者に対する窓口支払い業務を行い、料金の支払いを受ける。
なお、患者５０からの確認入力が行われない場合または誤りであると確認された場合（図２ステップＳ９：Ｎ）、所定の誤り請求時の処理を行う。ここでは詳述しないが、決められた運営に従って処理する。例えば、カルテに実際に記載されている診療内容と医療機関システム２０から診療報酬請求事務代行システム１０に送信された診療データとの突き合わせによる再確認処理、患者５０の単なる誤解ではないかの確認処理などを行う。

以上が初診来院時の処理の概要である。レセプトデータは月末など所定の時期になるとレセプトデータ作成・送信部１４を介して審査システム３０に対して送信されるが、ここでは初診であり、レセプトデータ作成・送信部１４によるレセプトデータの審査システム３０に対する送信処理は行われなかったとする。

（Ｂ）再来院の場合
患者５０は再来院時、医療機関の窓口で再診手続きを行う。
まず、患者５０は、患者ＩＤ情報入力部１１１を介して患者５０のＩＤ情報を入力する（図５ステップＳ２１）。ここでは指の静脈パターンを入力する。患者５０は患者ＩＤ情報入力部１１１に指を添えて静脈パターンを入力する。
再来院時には既に患者情報データベース１１２には患者５０の諸情報が格納されており、患者５０の名前などの患者属性を示す各種情報のほか患者のバイオメトリックス情報が患者ＩＤ情報として格納されている。指の静脈パターンにより患者５０が特定・識別される。このバイオメトリックス情報を用いた患者５０の特定・識別により患者５０本人の再来院が確実に立証され、他人による「なりすまし」を利用した架空請求が不可能となる。

患者確認部１１は患者５０を特定・識別し、患者５０の患者管理番号を通知する（図５ステップＳ２２）。
その後、医療機関では患者管理番号をキーとして患者５０の前回の来院時の治療内容や疾病の経過情報など必要な医療事務管理を行い、医療スタッフは今回の診療・施術を行う（図５ステップＳ２３）。
医療機関は患者に対して施した診療内容を記述した診療データを患者管理番号とともに診療データ収集部１２に対して送信する（図５ステップＳ２４）。

内容確認処理部１３は診療データに記述された診療内容を患者に対して直接提示する（図５ステップＳ２５）。
内容確認処理部１３は、患者５０から診療内容が正しいか誤りかの確認入力を受け付ける（図５ステップＳ２６）。
患者５０が受けた診療内容が正しい場合（図５ステップＳ２６：Ｙ）は、患者５０は確認入力を行う。この例では内容確認処理部１３を介した診療内容の確認入力に併せて、患者５０は患者ＩＤ情報入力部１１１に指を添えて静脈パターンを入力する。

患者５０からの確認入力が行われた場合（図５ステップＳ２６：Ｙ）、レセプトデータ作成・送信部１４は確認された診療内容に基づいて保険情報データベース１５にアクセスし保険点数を計算し、レセプトデータを作成し、保険情報データベース１５にレセプトデータを蓄積する（図５ステップＳ２７）。
この実施例では、レセプトデータ作成・送信部１４は、医療機関システム２０に対して患者の自己負担分の明細データと請求金額データを送信する（図５ステップＳ２８）。医療機関システム２０はレセプトデータ作成・送信部１４より渡された患者の自己負担分の明細データと請求金額データを基に患者に対する窓口支払い業務を行い、料金の支払いを受ける（図５ステップＳ２９）。

レセプトデータは月末など所定の時期になるとレセプトデータ作成・送信部１４を介して審査システム３０に対して送信される（図５ステップＳ３０）。
その後、審査システム３０においてレセプトの審査が行われ、審査に合格すれば各保険者にレセプトデータが送付され、診療報酬請求が行われる。

本発明の実施例１にかかる診療報酬請求事務代行システムによれば、レセプト作成を医療機関以外の第３者である請求事務代行主体によってレセプトを客観的に作成することができ、かつ、レセプト作成前に患者に対して診療内容の確認を取ることにより実際の診療内容とレセプトに書き込まれる診療内容とが合致していることを確実に確認した後でレセプトを作成することができ、診療報酬の水増し請求や架空請求を確実に防止することができる。

実施例２として、患者のもとに医療スタッフが訪問して治療・介護を行う、いわゆる訪問型の診療報酬請求事務代行システムの構成例を、図面を参照しつつ説明する。なお、介護者宅に訪問するいわゆる訪問型の介護報酬請求事務代行システムの構成も同様で良い。
以下の説明において訪問治療・介護の内容は特に限定されず、医師・歯科医師による往診、柔整師によるマッサージ、介護士による介護など社会保険制度の利用が可能で診療報酬請求事務や介護報酬請求事務が生じる内容であれば本発明のシステムを導入する対象となる。

図８は、本発明の実施例２にかかる訪問型の診療報酬請求事務代行システムのブロック図である。図８において、診療報酬請求事務代行システム１０の構成は実施例１のものと同様で良く、病院等の医療機関が設置・管理する医療機関システム２０、支払基金・国保連合会等のレセプト審査支払機関が設置・管理している審査システム３０、自治体等（国民健康保険等）および各企業等（健康保険組合等）の保険者が設置・管理している保険者システム４０も同様である。
実施例１では来院型システムであったので医療機関窓口に設置される窓口端末２１が存在したが、実施例２は訪問型システムであるので、訪問する医療スタッフが携帯する携帯端末２２が用いられる。携帯端末２２は携帯電話、携帯型ハンドヘルドコンピュータなど携帯が可能でかつ通信機能を備えた端末が想定される。

診療報酬請求事務代行システム１０は、医療機関システム２０と審査システム３０との間に介在し、両者間におけるレセプトデータの作成処理の代行実行と、診療報酬請求事務処理の代行実行するものである。なお、ここでも、診療報酬請求事務代行システム１０を設置・管理する主体は、請求事務代行主体であり、医療機関の一組織ではなく、医療機関組織から独立した存在であることが好ましい。

診療報酬請求事務代行システム１０の各構成要素について説明する。
患者確認部１１は、医療スタッフが携帯する携帯端末２２に組み込まれた患者ＩＤ情報入力部１１１を介して取得された患者ＩＤ情報を基に患者５０を特定する患者特定機能と、特定した患者５０に割り当てられている患者管理番号を医療機関システム２０に通知する患者管理番号通知機能を備えている。この構成例では患者確認部１１は端末システム１０ｂに設けられているが、携帯端末２２の一部として組み込まれている構成も可能である。

患者ＩＤ情報入力部１１１は、訪問先の在宅の患者５０から患者ＩＤ情報の入力を受け付ける部分であり、実施例１と同様、バイオメトリックス情報を入力できるもので良い。本実施例２でも指の静脈パターンを患者ＩＤ情報として採用し、患者確認部１１において静脈認証を伴う患者の特定を行うものとして説明する。患者ＩＤ情報入力部１１１を介して取得したバイオメトリックス情報は携帯端末２２の持つ通信機能を介して患者確認部１１に送信される。

患者特定機能は患者ＩＤ情報入力部１１１を介して読み取った患者ＩＤ情報をもとに患者を特定・識別する機能であるが、患者ＩＤ情報が磁気ストライプやＩＣチップから読み取ったコード情報であれば、当該コード情報を基に患者情報データベース１１２に格納されている情報と照合し、患者を特定・識別する。患者ＩＤ情報がバイオメトリックス情報の場合、照合が予定されているバイオメトリックス情報、たとえば、指の静脈パターン情報、指紋情報、手のひらの静脈パターン情報、虹彩パターン情報などが格納されている。
患者管理番号通知機能は特定した患者５０に割り当てられている患者管理番号を医療機関システム２０に通知する機能である。

診療データ収集部１２は、訪問した医療スタッフが患者に施した診療内容を記述した診療データを医療機関システムから受信する部分である。
医療スタッフは在宅の患者に対して適切な診療行為を施すが、各診療行為には保険点数がつけられており、医療機関システム２０は施術予定の診療内容を記述した診療データを作成し、本発明の診療報酬請求事務代行システム１０に送信する。診療データ収集部１２は医療機関システム２０から診療内容を記述した診療データを受信する。

１３は内容確認処理部であり、患者５０に対して診療データに記述された診療内容を直接提示する表示機能と、患者５０から提示された診療内容が正しいか誤りかの確認入力を受け付ける確認機能とを備えている。
本実施例２では、内容確認処理部１３は訪問する医療スタッフの携帯端末２２の一部として組み込まれている。表示機能はこの携帯端末２２のモニタ上に診療内容を提示することにより実現しても良い。確認機能はこの携帯端末２２のモニタ上に構築したタッチパネル方式の確認ボタンの押下により患者から直接診療内容が正しいか否かの意思表示を受け付けても良い。

ここで、実施例１と同様、内容確認処理部１３を介した患者による診療内容の確認入力に併せて患者のバイオメトリックス情報の入力を行わせる構成が好ましい。確認入力に併せて患者のバイオメトリックス情報の入力を行わせる構成とすれば、診療内容の確認は確実に患者本人が行うこととなり、いわゆる「なりすまし」による確認ボタン押下という不正行為が介在する余地がなくなる。
レセプトデータ作成・送信部１４は、診療データ収集部１２から診療データを受け取り、内容確認処理部１３での認否確認において患者５０より診療内容が正しいと確認入力された場合にのみ、当該診療データに基づいてレセプトデータを作成する機能と、作成したレセプトデータを審査システム３０に送信する機能を備えている。

実施例２においても実施例１と同様、内容確認処理部１３とレセプトデータ作成・送信部１４の連動処理により、レセプトデータ作成・送信部１４によりレセプトデータが作成される場合は常に患者により診療内容が確認されており、診療内容の水増し請求や診療内容の架空請求を確実に防止することができることとなる。
審査システム３０、保険者システム４０の働きは実施例１と同様で良い。
実施例２の診療報酬請求事務代行システム１０においても内容確認処理部１３により確認済みのレセプトデータがレセプトデータ作成・送信部１４により作成され送信される。

以下、実施例２にかかる、診療報酬請求事務代行システム１０を中心とした、レセプト作成処理および診療報酬請求事務代行処理の流れを説明する。なお、以下の流れにおいて、医療機関として患者が長期に繰り返し施術を受けるマッサージを例に挙げて説明する。
実施例２では、患者のバイオメトリックス情報の登録、療養費支給申告書のサインなどは既に終わっているものとし、繰り返しの訪問施術の処理を説明する。訪問施術の流れは図９のフローチャート、図１０の流れ図、図１１の流れ図にまとめられている。各段階で適宜に他図を参照しつつ説明する。

医療スタッフが患者５０の自宅等へ訪問する。まず、医療スタッフは患者５０に対して携帯端末２２を渡して、患者ＩＤ情報入力部１１１介したＩＤ情報入力を促す（図９ステップＳ３１）。ここでは指の静脈パターンを入力する。患者５０は患者ＩＤ情報入力部１１１に指を添えて静脈パターンを入力する。
ここでは既に患者情報データベース１１２には患者５０の諸情報が格納されており、患者５０の名前などの患者属性を示す各種情報のほか患者のバイオメトリックス情報が患者ＩＤ情報として格納されている。指の静脈パターンにより患者５０が特定・識別される。このバイオメトリックス情報を用いた患者５０の特定・識別により患者５０本人の再来院が確実に立証され、他人による「なりすまし」を利用した架空請求が不可能となる。
入力された患者ＩＤ情報は携帯端末２２の通信機能を介して患者ＩＤ情報が送信される。

患者確認部１１は受信した患者ＩＤ情報をもとに患者５０を特定・識別し、患者５０の患者管理番号を通知する（図９ステップＳ３２）。
その後、医療機関では患者管理番号をキーとして患者５０の前回までの訪問施術の治療内容や疾病の経過情報など必要な医療事務管理を行ない、医療スタッフは今回の診療・施術を行う（図９ステップＳ３３）。なお、診療・施術内容は、医療スタッフに対して訪問前にあらかじめ計画したものを医療スタッフに持たせておくか、携帯端末２２のもつ通信機能を用いて医療スタッフに通知しておく。
医療機関システム２０は患者に対して施す診療内容を記述した診療データを患者管理番号とともに診療データ収集部１２に対して送信する（図９ステップＳ３４）。この例では医療機関システム２０が送信する構成例であるが、訪問で治療・施術した医療スタッフが携帯端末２２から実際に行った治療・施術の診療内容を記述した診療データを送信する構成としても良い。

内容確認処理部１３は診療データに記述された診療内容を携帯端末２２に送信し、携帯端末２２の確認インターフェイス１３１上に診療内容を表示し、患者に対して直接提示する（図９ステップＳ３５）。
内容確認処理部１３は、患者５０から診療内容が正しいか誤りかの確認入力を受け付ける（図９ステップＳ３６）。
患者５０が受けた診療内容が正しい場合（図９ステップＳ３６：Ｙ）は、患者５０は確認入力を行う。この例では内容確認処理部１３を介した診療内容の確認入力に併せて、患者５０は患者ＩＤ情報入力部１１１に指を添えて静脈パターンを入力する。
患者５０からの確認入力が行われた場合（図９ステップＳ３６：Ｙ）、レセプトデータ作成・送信部１４は確認された診療内容に基づいて保険情報データベース１５にアクセスし保険点数を計算し、レセプトデータを作成し、保険情報データベース１５にレセプトデータを蓄積する（図９ステップＳ３７）。

この実施例では、レセプトデータ作成・送信部１４は、医療機関システム２０に対して患者の自己負担分の明細データと請求金額データを送信する（図９ステップＳ３８）。医療機関システム２０はレセプトデータ作成・送信部１４より渡された患者の自己負担分の明細データと請求金額データを基に患者に対する窓口支払い業務を行い、料金の支払いを受ける（図９ステップＳ３９）。
レセプトデータは月末など所定の時期になるとレセプトデータ作成・送信部１４を介して審査システム３０に対して送信される（図９ステップＳ４０）。
その後、審査システム３０においてレセプトの審査が行われ、審査に合格すれば各保険者にレセプトデータが送付され、診療報酬請求が行われる。

本発明の実施例２にかかる診療報酬請求事務代行システムによれば、レセプト作成を医療機関以外の第３者である請求事務代行主体によってレセプトを客観的に作成することができ、かつ、レセプト作成前に患者に対して診療内容の確認を取ることにより実際の診療内容とレセプトに書き込まれる診療内容とが合致していることを確実に確認した後でレセプトを作成することができ、診療報酬の水増し請求や架空請求を確実に防止することができる。

実施例３は、実施例１、実施例２の構成と同様であるが、患者確認部１１において入力を求める患者のバイオメトリックス情報と、内容確認処理部１３において入力を求める患者のバイオメトリックス情報とを異なる部位のバイオメトリックス情報とした構成例を示すものである。
特に、患者の複数の部位のバイオメトリックス情報を登録しておき、患者確認部１１において入力を求める患者のバイオメトリックス情報と、内容確認処理部１３において入力を求める患者のバイオメトリックス情報とを動的に選択して入力させる構成例を示すものである。

本実施例３では患者ＩＤ情報入力部１１１として、複数のバイオメトリックス情報を読み取る手段（デバイス）を備えているものとする。例えば、図１２のように、手のひらの静脈パターン、指の静脈パターン、指の指紋パターン、虹彩パターンの４つのバイオメトリックス情報を読み取ることができるものを採用する。もちろん、ハイブリッド型デバイスでも良く、４つの専用デバイスを複数並べたものでも良い。
例えば、患者確認部１１において入力を求める患者のバイオメトリックス情報を手のひらの静脈パターンとし、内容確認処理部１３において入力を求める患者のバイオメトリックス情報を指の静脈パターンとする組み合わせを用いることができる。

実施例１の来院型システムの場合であれば、患者確認ステップでは患者確認部１１が窓口端末２１の表示部を介して来院した患者に入力を求める生体部位（ここでは手のひらの静脈パターン）の案内を行い、患者は案内された生体部位（ここでは手のひらの静脈パターン）をデバイスにかざして生体ＩＤ情報を入力する。次に、診療内容確認ステップでは、内容確認処理部１３が窓口端末２１の表示部を介して患者に対して診療内容確認時に併せて入力する生体部位（ここでは指の静脈パターン）の案内を行い、患者は案内された生体部位（ここでは指の静脈パターン）をデバイスにかざして生体ＩＤ情報を入力する。

実施例２の訪問型システムの場合であれば、患者確認ステップでは患者確認部１１が携帯端末２２の表示部を介して訪問先の患者に入力を求める生体部位（ここでは手のひらの静脈パターン）の案内を行い、患者は案内された生体部位（ここでは手のひらの静脈パターン）をデバイスにかざして生体ＩＤ情報を入力する。次に、診療内容確認ステップでは、内容確認処理部１３が携帯端末２２の表示部を介して患者に対して診療内容確認時に併せて入力する生体部位（ここでは指の静脈パターン）の案内を行い、患者は案内された生体部位（ここでは指の静脈パターン）をデバイスにかざして生体ＩＤ情報を入力する。

上記生体情報の組み合わせに限らず、手のひら静脈パターンと虹彩パターンの組み合わせ、指紋パターンと虹彩パターンの組み合わせなど自由に採用することができる。
また、患者確認部１１において入力を求める患者のバイオメトリックス情報と内容確認処理部１３において入力を求める患者のバイオメトリックス情報をあらかじめ静的に決めておかず、その都度動的に選択するものでも良い。動的に決められた生体部位の生体情報を入力してもらうように案内して入力させる。

実施例４にかかる診療報酬請求事務代行システムは、請求事務代行主体が、レセプトに基づく診療報酬請求権を債権として、医療機関側から買い取る債権売買契約処理を、内容確認部による確認入力処理と連動せしめる機能を備えたものである。
図１３は本発明の実施例４にかかる診療報酬請求事務代行システム１０ａの構成例を示した図である。実施例１または実施例２に示した診療報酬請求事務代行システム１０の構成に加えて、実施例４の構成例では、債権売買契約締結部１７を備えている。

債権売買契約締結部１７は、医療機関システム２０との間で債権売買契約を締結する機能を備えている。より具体的には、レセプトに基づく診療報酬請求権を債権として、医療機関システム２０を介して医療機関側に債権の買取の申し込み情報を表示する機能と、医療機関システム２０を介して売主である医療機関側からの債権買取承諾情報の入力を受け付ける機能と、両者間の債権売買契約が成立した場合に債権売買契約データを作成する機能を備えている。
ここで、内容確認処理部１３による確認入力処理と、債権売買契約締結部１７による債権売買契約締結処理がスムーズにつながるように、両者を連動させるよう工夫する。つまり、医療機関での毎回の診療ごとに、内容確認部１３による確認入力処理と、債権売買契約締結部１７による債権の買取申し込み情報の表示処理を連動せしめる。

以下、実施例４にかかる診療報酬請求事務代行システム１０ａを中心とした、内容確認部１３による確認入力処理、債券売買契約締結、診療報酬支払処理までの流れを説明する。ここでは、実施例１の再来院時の処理について債券売買契約処理を組み合わせた場合を示す。図１４のフローチャート、図１５の流れ図を参照しつつ説明する。
図１４において、ステップＳ５１からステップＳ５５までは実施例１の図５のステップＳ２１からステップＳ２５までの処理と同様で良く、ここでは説明を省略する。

ステップＳ５６において診療内容が正しいか誤りかの確認入力において正しいと確認入力された場合（ステップＳ５６：Ｙ）、債権売買契約締結部１７は、レセプトに基づく診療報酬請求権を債権として、医療機関システム２０のモニタ上に医療機関側に債権の買取の申し込み情報を表示する（図１４ステップＳ５７）。
図１５に示すように、実施例４にかかる診療報酬請求事務代行システム１０ａは、内容確認部１３による確認入力処理と、債権売買契約締結部１７による債権の買取申し込み情報の表示処理を連動せしめている。つまり、患者や要介護者により直接、内容確認がなされない限り、債権売買契約締結部１７による債権の買取申し込み情報の表示処理が行われず、医療機関に対して債権買取処理が実行されることもない。

次に、債権売買契約締結部１７は、医療機関システム２０を介して売主である医療機関側からの債権買取承諾情報の入力を受け付ける。例えば、債権買取の申し込みの旨の表示とともに、債権買取を承諾する旨の承諾ボタンと承諾しない旨の拒否ボタンがモニタ上に表示され、タッチパネル方式により入力可能となっている。
権限を有する医療スタッフが債権買取の承諾を行い、承諾ボタンの押下により（ステップＳ５７：Ｙ）、債権買取承諾の旨が債権売買契約締結部１７に伝えられる。拒否ボタンの押下により債権買取拒否の旨が債権売買契約締結部１７に伝えられる。

承諾ボタンの押下により両者間の債権売買契約が成立した場合（ステップＳ５７：Ｙ）に、債権売買契約締結部１７は債権売買契約データを作成する（ステップＳ５８）。契約締結は電子処理化しておくことも可能である。
診療報酬債権買取契約の締結により、診療報酬債権の買取額の支払い処理を行う（ステップＳ５９）。診療報酬額１００％に対して診療報酬債権の買取額は例えば８０％の金額や７５％の金額とし、若干の割引を行った額とする。

診療報酬債権の買取額の支払処理終了後、通常のレセプト作成処理に移行する。
レセプトデータ作成・送信部１４は患者により確認された診療内容に基づいて保険情報データベース１５にアクセスし保険点数を計算し、レセプトデータを作成する。本実施例４の図１４のステップＳ６０からステップＳ６４は実施例１の図５のステップＳ２８からステップＳ３１と同様で良い。

一方、拒否ボタンの押下により両者間の債権売買契約が不成立であった場合（図１４ステップＳ５７：Ｎ）には、直接通常のレセプト作成処理（ステップＳ６０）に移行する。
当該レセプトデータは報酬請求名義が医療機関である旨のデータとともに保険情報データベース１５に格納蓄積される。

レセプトデータは月末など所定の時期になるとレセプトデータ作成・送信部１４を介して審査システム３０に対して送信される。
その後、審査システム３０においてレセプトの審査が行われ、審査に合格すれば各保険者にレセプトデータが送付され、診療報酬請求が行われる。
本発明の実施例４にかかる診療報酬請求事務代行システムによれば、債権買取自動処理に不正診療報酬請求などが介在する余地がなくなる。

実施例５にかかる診療報酬請求事務代行システムは、請求事務代行主体が、レセプトに基づく診療報酬請求権を債権として、医療機関側から買い取る債権売買契約処理を、内容確認部による確認入力処理と、レセプトデータ作成・送信部によるレセプト作成処理と連動せしめる機能を備えたものである。
実施例５にかかる診療報酬請求事務代行システムの構成例は実施例４の図１３の構成例と同様で良く、債権売買契約締結部１７を備えている。

実施例５における債権売買契約締結部１７も実施例５と同様、医療機関システム２０との間で債権売買契約を締結する機能を備えており、レセプトに基づく診療報酬請求権を債権として医療機関側に債権の買取の申し込み情報を表示する機能、医療機関側からの債権買取承諾情報の入力を受け付ける機能、両者間の債権売買契約が成立した場合に債権売買契約データを作成する機能を備えている。

ここで、実施例５では、内容確認部１３による確認入力処理と、レセプトデータ作成・送信部１４によるレセプトデータの作成処理と、債権売買契約締結部１７による債権売買契約締結処理がスムーズにつながるように、３者を連動させるよう工夫する。つまり、内容確認部１３により患者または要介護者から直接内容が正しいと確認された場合に、レセプトデータ作成・送信部１４によるレセプトデータの作成処理と、債権売買契約締結部１７による債権の買取申し込み情報の表示処理を連動せしめる。

以下、実施例５にかかる診療報酬請求事務代行システムを中心とした、内容確認部１３による確認入力処理とレセプトデータ作成・送信部１４によるレセプト作成処理と債権売買契約処理部１７による債券売買契約締結までの流れを図１６のフローチャートを参照しつつ説明する。

以下、実施例５にかかる診療報酬請求事務代行システム１０ａを中心とした、レセプト作成処理および診療報酬請求事務代行処理および債券売買契約締結、診療報酬支払処理までの流れを図１６のフローチャート、図１７の流れ図を参照しつつ説明する。
図１６において、ステップＳ７１からステップＳ７５までは実施例１の図５のステップＳ２１からステップＳ２５までの処理と同様で良く、ここでは説明を省略する。

ステップＳ７６において診療内容が正しいか誤りかの確認入力において正しいと確認入力された場合（ステップＳ７６：Ｙ）、レセプトデータ作成・送信部１４は診療のたびに患者により確認された診療内容に基づいて保険情報データベース１５にアクセスし保険点数を計算し、レセプトデータを作成する（ステップＳ７７）。債権売買契約締結部１７は、レセプトに基づく診療報酬請求権を債権として、医療機関システム２０のモニタ上に医療機関側に債権の買取の申し込み情報を表示する（ステップＳ７８）。
図１７に示すように、実施例５にかかる診療報酬請求事務代行システム１０ａは内容確認部１３による確認入力処理と、レセプトデータ作成・送信部１４によるレセプトデータの作成処理と、債権売買契約締結部１７による債権の買取申し込み情報の表示処理を連動せしめている。

次に、債権売買契約締結部１７は、医療機関システム２０を介して売主である医療機関側からの債権買取承諾情報の入力を受け付ける。例えば、債権買取の申し込みの旨の表示とともに、債権買取を承諾する旨の承諾ボタンと承諾しない旨の拒否ボタンがモニタ上に表示され、タッチパネル方式により入力可能となっている。
権限を有する医療スタッフが債権買取の承諾を行い、承諾ボタンの押下により（ステップＳ７８：Ｙ）、債権買取承諾の旨が債権売買契約締結部１７に伝えられる。拒否ボタンの押下により債権買取拒否の旨が債権売買契約締結部１７に伝えられる。

承諾ボタンの押下により両者間の債権売買契約が成立した場合（ステップＳ７８：Ｙ）に、債権売買契約締結部１７は債権売買契約データを作成して締結処理を実行する（ステップＳ７９）。契約締結処理手続きは実印の押印などに代え、電子署名など手続きの電子処理化しておくことも可能である。
診療報酬債権買取契約の締結により、診療報酬債権の買取額の支払い処理を行う（ステップＳ８０）。診療報酬額１００％に対して診療報酬債権の買取額は例えば８０％の金額や７５％の金額とし、若干の割引を行った額とする。

当該債権買い取りにかかるレセプトデータは債権名義つまり報酬請求名義が請求事務代行主体である旨のデータとともにレセプト審査システム３０に送信される。（ステップＳ８１）。
審査機関での審査に合格すれば各保険者にレセプトデータが送付され、診療報酬請求が行われる。ここで送信したレセプトデータを保険情報データベース１５にバックアップ格納することは好ましい。

一方、拒否ボタンの押下により両者間の債権売買契約が不成立であった場合（Ｓ７８：Ｎ）に、債権売買契約締結部１７は当該レセプトデータは報酬請求名義が医療機関である旨のデータとともにレセプト審査システム３０に送信される（ステップＳ８１）。同様に、送信したレセプトデータを保険情報データベース１５にバックアップ格納することは好ましい。

本発明の実施例５にかかる診療報酬請求事務代行システムによれば、内容確認部による確認入力処理とレセプトデータ送信部によるレセプトデータ作成処理と債権売買契約締結部による債権の買い取り処理を連動せしめ、債権買取自動処理において不正診療報酬請求などが介在する余地がなくなる。

本発明にかかる診療報酬請求事務代行システムの処理ステップをコンピュータプログラムとして記述すれば、診療報酬請求事務代行処理プログラムとして提供することができる。つまり、本発明の診療報酬請求事務代行処理プログラムは、上記した実施例１乃至実施例５のいずれかに示した本発明にかかる診療報酬請求事務代行システムの処理ステップをコンピュータプログラムとして記述されたものとして、コンピュータ読み込み可能な記憶媒体に担持させた形やコンピュータネットワークを介したダウンロードの形にて提供することができる。

以上、本発明の診療報酬請求事務代行システムの構成例における好ましい実施形態を図示して説明してきたが、本発明の技術的範囲を逸脱することなく種々の変更が可能であることは理解されるであろう。

本発明の診療報酬請求事務代行システムは、医療分野の事務処理システムに適用することができる。また、診療報酬請求事務代行事業者が用いる事務処理システムに適用することができる。また、債権売買契約を行う事業者が用いる事務処理システムに適用することができる。

本発明の実施例１にかかる来院型の診療報酬請求事務代行システムのブロック図 実施例１の来院型のシステム構成例における初診来院時の処理の流れを示したフローチャート 診療報酬請求事務代行システム、医療機関システム、審査機関システム、保険者システム、患者間のやり取りを示す図（その１） 診療報酬請求事務代行システム、医療機関システム、審査機関システム、保険者システム、患者間のやり取りを示す図（その２） 実施例１の来院型のシステム構成例における再来院時の処理の流れを示したフローチャート 診療報酬請求事務代行システム、医療機関システム、審査機関システム、保険者システム、患者間のやり取りを示す図（その３） 診療報酬請求事務代行システム、医療機関システム、審査機関システム、保険者システム、患者間のやり取りを示す図（その４） 本発明の実施例２にかかる訪問型の診療報酬請求事務代行システムのブロック図 実施例２の訪問型のシステム構成例における初診来院時の処理の流れを示したフローチャート 診療報酬請求事務代行システム、医療機関システム、審査機関システム、保険者システム、患者間のやり取りを示す図（その５） 診療報酬請求事務代行システム、医療機関システム、審査機関システム、保険者システム、患者間のやり取りを示す図（その６） 本発明の実施例３にかかる患者確認部１１の患者ＩＤ情報入力部１１１を模式的に示す図 本発明の実施例４にかかる診療報酬請求事務代行システム１０ａの構成例を示した図 実施例４の債券買取契約処理を伴うシステム構成例における処理の流れを示したフローチャート 診療報酬請求事務代行システム、医療機関システム、審査機関システム、保険者システム、患者間のやり取りを示す図（その７） 実施例５の債券買取契約処理を伴うシステム構成例における処理の流れを示したフローチャート 診療報酬請求事務代行システム、医療機関システム、審査機関システム、保険者システム、患者間のやり取りを示す図（その８） 従来の一般的なレセプトを使用した診療報酬の請求と審査および支払いの概略を示す図 従来の一般的な接骨院、柔整院での療養費の請求と審査および支払いの概略を示す図

符号の説明

１０ 診療報酬請求事務代行システム
１１ 患者確認部
１１１ 患者ＩＤ情報入力部
１１２ 患者情報データベース
１２ 診療データ収集部
１３ 内容確認処理部
１３１ 確認インターフェイス
１４ レセプト作成部
１５ 保険情報データベース
１７ 債権売買契約締結部
２０ 医療機関システム
２１ 窓口端末
２２ 携帯端末
３０ 審査システム
４０ 保険者システム
５０ 患者

Claims (10)

1. 医療機関が管理する医療機関システムとレセプト審査支払機関が管理する審査システムとの間に介在し、診療報酬の支払請求事務を代行する支払請求事務代行主体が管理する支払請求事務代行システムであって、
   前記医療機関に来院した患者から入力されたＩＤ情報を基に前記患者を特定・確認し、患者管理番号を前記医療機関システムに通知する患者確認部と、
   前記医療機関で前記患者に施した診療内容を記述した診療データを前記患者管理番号とともに前記医療機関システムから受信する診療データ収集部と、
   前記診療内容を前記患者に直接提示し、前記患者のＩＤ情報の入力とともに前記診療内容の確認入力を受け付ける内容確認処理部と、
   前記内容確認処理部において前記診療内容が正しいと確認入力されたことを条件としてレセプトデータを作成し、前記審査システムに送信するレセプトデータ作成・送信部とを備えた支払請求事務代行システム。
2. 介護機関が管理する介護機関システムとレセプト審査支払機関が管理する審査システムとの間に介在し、介護報酬の支払請求事務を代行する支払請求事務代行主体が管理する支払請求事務代行システムであって、
   前記介護機関に来院した要介護者から入力されたＩＤ情報を基に前記要介護者を特定・確認し、要介護者管理番号を前記介護機関システムに通知する要介護者確認部と、
   前記介護機関で前記要介護者に施した介護内容を記述した介護データを前記要介護者管理番号とともに前記介護機関システムから受信する介護データ収集部と、
   前記介護内容を前記要介護者に直接提示し、前記要介護者のＩＤ情報の入力とともに前記介護内容の確認入力を受け付ける内容確認処理部と、
   前記内容確認処理部において前記介護内容が正しいと確認入力されたことを条件としてレセプトデータを作成し、前記審査システムに送信するレセプトデータ作成・送信部とを備えた支払請求事務代行システム。
3. 接骨院、鍼灸院、按摩マッサージ院などの療養型機関が管理する療養機関システムとレセプト審査支払機関が管理する審査システムとの間に介在し、療養費の支払請求事務を代行する支払請求事務代行主体が管理する支払請求事務代行システムであって、
   前記療養型機関に来院した患者から入力されたＩＤ情報を基に前記患者を特定・確認し、患者管理番号を前記療養機関システムに通知する患者確認部と、
   前記療養機関で前記患者に施した療養内容を記述した療養データを前記患者管理番号とともに前記医療機関システムから受信する療養データ収集部と、
   前記療養内容を前記患者に直接提示し、前記患者のＩＤ情報の入力とともに前記療養内容の確認入力を受け付ける内容確認処理部と、
   前記内容確認処理部において前記療養内容が正しいと確認入力されたことを条件としてレセプトデータを作成し、前記審査システムに送信するレセプトデータ作成・送信部とを備えた支払請求事務代行システム。
4. 訪問する医療スタッフが携帯する携帯端末とレセプト審査支払機関が管理する審査システムとの間に介在し、診療報酬の支払請求事務を代行する支払請求事務代行主体が管理する支払請求事務代行システムであって、
   前記携帯端末を介して患者から入力され送信されたＩＤ情報を基に前記患者を特定・確認する患者確認部と、
   訪問した前記医療スタッフが前記患者に施した診療内容を記述した診療データを前記携帯端末から受信する診療データ収集部と、
   前記携帯端末の画面を介して前記診療内容を前記患者に直接提示し、前記患者のＩＤ情報の入力とともに前記診療内容の確認入力を受け付ける内容確認処理部と、
   前記内容確認処理部において前記診療内容が正しいと確認入力されたことを条件としてレセプトデータを作成し、前記審査システムに送信するレセプトデータ作成・送信部とを備えた支払請求事務代行システム。
5. 訪問する介護スタッフが携帯する携帯端末とレセプト審査支払機関が管理する審査システムとの間に介在し、介護報酬の支払請求事務を代行する支払請求事務代行主体が管理する支払請求事務代行システムであって、
   前記携帯端末を介して要介護者から入力され送信されたＩＤ情報を基に前記要介護者を特定・確認する要介護者確認部と、
   訪問した前記介護スタッフが前記要介護者に施した介護内容を記述した介護データを前記携帯端末から受信する介護データ収集部と、
   前記携帯端末の画面を介して前記介護内容を前記要介護者に直接提示し、前記要介護者のＩＤ情報の入力とともに前記介護内容の確認入力を受け付ける内容確認処理部と、
   前記内容確認処理部において前記介護内容が正しいと確認入力されたことを条件としてレセプトデータを作成し、前記審査システムに送信するレセプトデータ作成・送信部とを備えた支払請求事務代行システム。
6. 訪問する療養スタッフが携帯する携帯端末とレセプト審査支払機関が管理する審査システムとの間に介在し、療養費の支払請求事務を代行する支払請求事務代行主体が管理する支払請求事務代行システムであって、
   前記携帯端末を介して患者から入力され送信されたＩＤ情報を基に前記患者を特定・確認する患者確認部と、
   訪問した前記療養スタッフが前記患者に施した療養内容を記述した療養データを前記携帯端末から受信する療養データ収集部と、
   前記携帯端末の画面を介して前記療養内容を前記患者に直接提示し、前記患者のＩＤ情報の入力とともに前記療養内容の確認入力を受け付ける内容確認処理部と、
   前記内容確認処理部において前記療養内容が正しいと確認入力されたことを条件としてレセプトデータを作成し、前記審査システムに送信するレセプトデータ作成・送信部とを備えた支払請求事務代行システム。
7. 前記ＩＤ情報がバイオメトリックス情報を含むことを特徴とする請求項１から６のいずれかに記載の支払請求事務代行システム。
8. 複数の部位のバイオメトリックス情報を登録しておき、前記ＩＤ情報として入力を求める部位のバイオメトリックス情報を動的に変更・指定して入力させることを特徴とする請求項７に記載の支払請求事務代行システム。
9. レセプトに基づく支払請求権を債権として買い取る旨の債権買取申込情報を表示する機能と、前記債権の買い取りを認める旨の債権買取承諾情報の入力を受け付ける機能と、両者間の債権売買契約が成立した場合に債権売買契約データを作成する機能を備えた債権売買契約締結部を備え、
   前記内容確認部による確認入力処理と、前記債権売買契約締結部による前記債権買取申込情報の表示処理とを連動せしめたことを特徴とする請求項１から８のいずれかに記載の支払請求事務代行システム。
10. レセプトに基づく支払請求権を債権として買い取る旨の債権買取申込情報を表示する機能と、前記債権の買い取りを認める旨の債権買取承諾情報の入力を受け付ける機能と、両者間の債権売買契約が成立した場合に債権売買契約データを作成する機能を備えた債権売買契約締結部を備え、
    前記内容確認部による確認入力処理と、前記レセプトデータ作成・送信部による前記レセプトデータの作成処理と、前記債権売買契約締結部による前記債権買取申込情報の表示処理とを連動せしめたことを特徴とする請求項１から８のいずれかに記載の支払請求事務代行システム。

Images