(57)【要約】【課題】サービス提供の対価請求を一元化して請求手続きの煩雑さを軽減し、対価請求費用引き落としが確実に行えることを目的としている。【解決手段】一括管理請求処理装置はサービスの内容とサービスの対価請求費用を関連付けたデータを、サービス提供者から受け取り、データベース内のテーブルに書き込んで、データベースを参照して、サービス提供者毎と、サービス享受者毎に対価請求費用をまとめ、サービス享受者に示す提示し、サービス享受者毎にまとめられた対価請求費用の合算金額を、サービス享受者の口座から、自動で引き落とし、サービス提供者毎にまとめられた対価請求費用の合算金額を、サービス提供者の口座へ、自動で振り込むことを特徴とする。【選択図】図１
2019197440.tif 000002
【特許請求の範囲】
【請求項１】
サービスの提供を行うサービス提供者に割り当てられたサービス提供者ＩＤと、前記サービスを享受するサービス享受者に割り当てられたサービス享受者ＩＤが付記された、前記サービスの内容及び前記サービスの対価請求費用を関連付けたデータを受け取る受信手段と、
前記サービス提供者ＩＤ、前記サービス享受者ＩＤ、前記サービスの内容、及び、前記サービスの対価請求費用が記録されたデータベースを参照して、前記サービス享受者ＩＤ毎に対価請求費用をまとめる第１集約手段と、
前記サービス享受者ＩＤ毎にまとめられた対価請求費用の合算金額を示す提示手段と、
を備えることを特徴とした一括管理請求処理装置。
【請求項２】
請求項１に記載の一括管理請求処理装置であって、
前記サービス享受者ＩＤ毎にまとめられた対価請求費用の合算金額を、前記サービス享受者の口座から、自動で引き落としを行う引き落とし手段と、
前記データベースを参照して、前記サービス提供者ＩＤ毎に対価請求費用をまとめる第２集約手段と、
前記サービス提供者ＩＤ毎にまとめられた対価請求費用の合算金額を、前記サービス提供者の口座へ、自動で振り込む振り込み手段と、
を備えることを特徴とした一括管理請求処理装置。
【請求項３】
請求項１又は請求項２に記載の一括管理請求処理装置であって
前記サービスの享受者がサービス享受の後に、次回のサービスを受けるために必要な利用チケットを請求した際に、チケットを発券する発券手段と
前記発券手段に基づいて、前記サービス享受者が前記サービス提供者からサービスを享受した事を証明させる第１確認手段と、
を備えることを特徴とした一括管理請求処理装置。
【請求項４】
請求項１乃至３の何れか１項に記載の一括管理請求処理装置であって
前記サービスの享受者がサービス享受の前に、前記サービス享受者の年金振込口座、給与振込口座、又は保険金受取口座の申込書を提出させることによって、前記サービス享受者から対価請求費用の引き落としが可能である事を証明させる第２確認手段と、
を備えることを特徴とした一括管理請求処理装置。
【請求項５】
請求項１乃至４の何れか１項に記載の一括管理請求処理装置であって
前記サービス享受者ＩＤを生成させる際に、マイナンバーを数字として扱い、固定演算をさせる演算手段と、
上記計算結果をｎ進数に変換する変換手段と、
生成した数字をＩＤとして記憶しておく記憶手段と、
を備えることを特徴とした一括管理請求処理装置。
【請求項６】
一括管理請求処理方法であって、
受信手段が、サービスの提供を行うサービス提供者に割り当てられたサービス提供者ＩＤと、前記サービスを享受するサービス享受者に割り当てられたサービス享受者ＩＤが付記された、前記サービスの内容と前記サービスの対価請求費用を関連付けたデータを受け取るステップと、
集約手段が、前記サービス提供者ＩＤ、前記サービス享受者ＩＤ、前記サービスの内容、及び、前記サービスの対価請求費用が記録されたデータベースを参照して、前記サービス享受者ＩＤ毎に対価請求費用をまとめる集約ステップと、
提示手段が、前記サービス享受者ＩＤ毎にまとめられた対価請求費用の合算金額を示す提示ステップと、
を含むことを特徴とする一括管理請求処理方法
【請求項７】
コンピュータを、
サービスの提供を行うサービス提供者に割り当てられたサービス提供者ＩＤとサービスを享受するサービス享受者に割り当てられたサービス享受者ＩＤが付記された、前記サービスの内容と前記サービスの対価請求費用を関連付けたデータを受け取る受信手段、
前記サービス提供者ＩＤ、前記サービス享受者ＩＤ、前記サービスの内容、及び、前記サービスの対価請求費用が記録されたデータベースを参照して、前記サービス享受者ＩＤ毎に対価請求費用をまとめる集約手段、
前記サービス享受者ＩＤ毎にまとめられた対価請求費用の合算金額を示す提示手段、
として機能させることを特徴とする一括管理請求処理プログラム
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、配置薬品業者等が地域包括ケアを行う際に発生する、地域包括ケア費用、置き薬費用、処方薬代、食品代、おむつ代に加え、在宅医療の医療費請求を一括管理し、被介護者、患者に請求する一括管理請求処理装置、一括管理請求処理方法、一括管理請求処理プログラムに関する。
【背景技術】
【０００２】
日本国内の団塊の世代が７５歳以上となる２０２５年問題、牽いては高齢化社会の社会問題となっている中、厚生労働省は、重度な要介護状態となっても住み慣れた地域で自分らしい暮らしを人生の最後まで続けることができるよう、住まい・医療・介護・予防・生活支援が一体的に提供される地域包括ケアシステム構築の実現を目標としている。
【０００３】
このため、介護関連従事者はこの数年で倍以上に増え、その対応業種も増加している。今後、医療・介護関連事業は、自己の得意分野を基軸に新規サービスや業種の多角化が進み、各分野での競争激化が予想される。
【０００４】
医療・介護サービスを享受するサービス享受者は、加齢と共に、自分にとって最適なサービスがもたらされるよう、医師や介護プランを立案するケアマネージャーと打ち合わせを繰り返し、多様化されていくサービスを比肩しながら、それぞれを選択し組み合わせていく事が課せられる、という煩雑な仕組みに曝されていくと想定される。
【０００５】
現状の医療・介護市場を見ると、その半数以上が認知障害と認められているとされ、上記複雑化していくサービスを享受するためには煩雑な処理が必要となっている。
【０００６】
実際現在でも、各種サービスへの対価支払いはサービス毎に分散され、振り込み手続きや、自動支払い手続きも高齢者にとっては厄介で難しい作業を強いられている。
【０００７】
そこで、高齢化社会を迎える日本の生活の質を上げる対策、つまりクオリティ・オブ・ライフ対策を考えるとき、これらの煩雑な手続きの一切を引き受ける業者、及び処理の一本化システムの構築が求められている。
【０００８】
一方、一連の在宅医療、地域包括ケア、在宅医療の枠組みとは別に、「富山の薬売り」を起源とする配置薬品業者が存在する。
【０００９】
配置薬品業者は、在宅訪問をして救急箱を設置し、「先用後利」にて薬品や絆創膏を含む日用品を提供する業務体制をメインとしているが、訪問に際し、訪問した営業担当者が特に医療関係の資格を有していないため、一般薬の補充業務、及び生存確認を行っている。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
地域包括ケアシステム構築の実現に必要な、医療機関、介護施設、薬局、介護用品販売店といったサービス提供者は、対価請求費用を、患者や被介護者であるサービス享受者個別に直接請求をしているため、請求先が多くなり、手続きとして非常に煩雑となっている。
また現在でも、医療、又は介護サービス享受者は認知症を患った者や高齢者であることが多いため、請求内容を把握しづらく、対価請求費用の支払いが滞り、サービス提供者が対価請求費用を受け取れないといったトラブルや、サービスを享受したかどうか否かの記憶が曖昧な場合は、対価請求費用支払いを行わないといったトラブルも発生している。
【００１１】
さらにサービス享受者の支払い方法として、自動引き落とし契約をしたとしても、サービス提供者がサービスを提供後に、引き落とし口座の残高が不足しているといったトラブルも発生している。
【００１２】
本発明は、以上の点に鑑みてなされたものであり、サービス提供の対価請求を一元化して請求手続きの煩雑さを軽減し、対価請求費用引き落としが確実に行えることを目的としている。
【課題を解決するための手段】
【００１３】
上記課題を解決するために、請求項１に記載の発明は、サービスの提供を行うサービス提供者に割り当てられたサービス提供者ＩＤと、前記サービスを享受するサービス享受者に割り当てられたサービス享受者ＩＤが付記された、前記サービスの内容及び前記サービスの対価請求費用を関連付けたデータを受け取る受信手段と、前記サービス提供者ＩＤ、前記サービス享受者ＩＤ、前記サービスの内容、及び、前記サービスの対価請求費用が記録されたデータベースを参照して、前記サービス享受者ＩＤ毎に対価請求費用をまとめる第１集約手段と、前記サービス享受者ＩＤ毎にまとめられた対価請求費用の合算金額を示す提示手段とを備えることを特徴としている。
【００１４】
本発明によれば、医療機関、介護施設、薬局、介護用品販売店といったサービス提供者が、対価請求費用を、患者や被介護者であるサービス享受者個別に対して直接請求することなく、在宅訪問を行っている配置薬品業者等が有している上記特徴を備えた一括管理請求処理装置に対して一括で行うことができる。
また、サービス享受者へ集約した請求書を渡すことによって、認知症を患った者や高齢者に対しても、請求内容を一覧で把握することができる。
【００１５】
請求項２に記載の発明は、請求項１に記載の一括管理請求処理装置であって、前記サービス享受者ＩＤ毎にまとめられた対価請求費用の合算金額を、前記サービス享受者の口座から、自動で引き落としを行う引き落とし手段と、前記データベースを参照して、前記サービス提供者ＩＤ毎に対価請求費用をまとめる第２集約手段と、前記サービス提供者ＩＤ毎にまとめられた対価請求費用の合算金額を、前記サービス提供者の口座へ、自動で振り込む振り込み手段とを備えることを特徴としている。
【００１６】
本発明によれば、サービス享受者からの対価請求費用の支払いが滞ることが減少し、サービス提供者に対しては、漏れなく対価請求費用を支払うことができる。
【００１７】
請求項３に記載の発明は、請求項１又は請求項２に記載の一括管理請求処理装置であって、前記サービスの享受者がサービス享受の後に、次回のサービスを受けるために必要な利用チケットを請求した際に、チケットを発券する発券手段と、前記発見手段に基づいて、前記サービス享受者が前記サービス提供者からサービスを享受した事を証明させる第１確認手段とを備えることを特徴としている。
【００１８】
本発明によれば、サービスを享受した患者や被介護者が、実際にサービスを享受した事実の証明を、自らの次回チケット請求で、サービス享受者自らが行うようになり、サービスを享受したか否か、サービス享受者の記憶が曖昧な場合に発生する、対価請求費用支払いの際のトラブルを回避することができる。
【００１９】
請求項４に記載の発明は、請求項１乃至３の何れか１項に記載の一括管理請求処理装置であって、前記サービスの享受者がサービス享受の前に、前記サービス享受者の年金振込口座、給与振込口座、又は保険金受取口座の申込書を提出させることによって、前記サービス享受者から対価請求費用の引き落としが可能である事を証明させる第２確認手段とを備えることを特徴としている。
【００２０】
本発明によれば、定期的に入金があるサービス享受者の年金振込口座、給与振込口座、又は保険金受取口座を特定することができ、医療機関、介護施設、薬局、介護用品販売店といったサービス提供者がサービスを提供したにも関わらず、引き落とし口座に残高が無いといったトラブルを回避することができる。
【００２１】
請求項５に記載の発明は、請求項１乃至４の何れか１項に記載の一括管理請求処理装置であって、前記サービス享受者ＩＤを生成させる際に、マイナンバーを数字として扱い、固定演算をさせる演算手段と、上記計算結果をｎ進数に変換する変換手段と、生成した数字をＩＤとして記憶しておく記憶手段とを備えることを特徴としている。
【００２２】
本発明によれば、国民一人一人に与えられている唯一無二のナンバーから請求項1に記載した発明に利用するＩＤを生成するため、このＩＤも固定演算の方法によっては重複のないＩＤとなるため、医療機関、介護施設、薬局、介護用品販売店といった様々なサービス提供者から対価請求を受けた場合でも、ＩＤの重複は発生せず、一括管理請求処理装置をトラブルなく運用することができる。
【００２３】
請求項６に記載の発明は、受信手段が、サービスの提供を行うサービス提供者に割り当てられたサービス提供者ＩＤと、前記サービスを享受するサービス享受者に割り当てられたサービス享受者ＩＤが付記された、前記サービスの内容と前記サービスの対価請求費用を関連付けたデータを受け取るステップと、集約手段が、前記サービス提供者ＩＤ、前記サービス享受者ＩＤ、前記サービスの内容、及び、前記サービスの対価請求費用が記録されたデータベースを参照して、前記サービス享受者ＩＤ毎に対価請求費用をまとめる集約ステップと、提示手段が、前記サービス享受者ＩＤ毎にまとめられた対価請求費用の合算金額を示す提示ステップとを含むことを特徴としている。
【００２４】
請求項７に記載の発明は、サービスの提供を行うサービス提供者に割り当てられたサービス提供者ＩＤとサービスを享受するサービス享受者に割り当てられたサービス享受者ＩＤが付記された、前記サービスの内容と前記サービスの対価請求費用を関連付けたデータを受け取る受信手段、前記サービス提供者ＩＤ、前記サービス享受者ＩＤ、前記サービスの内容、及び、前記サービスの対価請求費用が記録されたデータベースを参照して、前記サービス享受者ＩＤ毎に対価請求費用をまとめる集約手段、前記サービス享受者ＩＤ毎にまとめられた対価請求費用の合算金額を示す提示手段、として機能させることを特徴としている。
【発明の効果】
【００２５】
本発明によれば、医療機関、介護施設、薬局、介護用品販売店といったサービス提供者はサービス提供の対価請求を一元化して一括管理請求処理装置に対して行うことができ、サービスを享受した患者、被介護者からの対価請求費用引き落としを確実に行うことができる。
【図面の簡単な説明】
【００２６】
【図１】一実施形態による地域包括ケア一括管理請求処理装置を用いた概略構成図である。
【図２】管理請求処理装置の利用登録から対価費用請求までの処理を示す図である。
【図３】（ａ）は地域包括ケア一括管理請求処理装置１０が有する記憶部１０２内のＤＢ１０２ｂ及びＤＢ１０２ｃの構造を示しており、（ｂ）はバッチ処理後のクエリ、又は、ビュー構造を示す図である。
【図４】サービス享受者向け請求書の一例を示す図である。
【図５】実施形態に係る管理請求処理装置１０の概要構成の一例を示すブロック図である。
【図６】（ａ）は、サービス提供者ＤＢ１０２ａに登録される内容の一例を示す図であり、（ｂ）は、サービス享受者ＤＢ１０２ｂに登録される内容の一例を示す図であり、（ｃ）は、サービス提供実績ＤＢ１０２ｃに登録される内容の一例を示す図である。
【図７】サービス享受者が実際にサービスを享受したと、自らが証明する方法例を示したフローチャート図である。
【図８】サービス享受者初期登録のステップの一例を示すフローチャート図である。
【図９】（ａ）はサービス享受者１がサービスを受ける際、（ｂ）は病院等のサービス提供者３〜６が請求をする際における処理の一例を示すフローチャート図である。
【図１０】（ａ）バッチ処理を開始させる処理の一例を、（ｂ）はサービス享受者対価請求費用を集約する際におけるバッチ処理の一例を、（ｃ）はサービス提供者対価請求費用を集約する際におけるバッチ処理の一例を示すフローチャート図である。
【図１１】サービス享受者へ請求書を送付する方法の一例を示すフローチャート図である。
【図１２】自動的に享受者の口座から引落しをする際における処理例のフローチャートフ図である。
【図１３】自動的に提供者の口座に振り込みをする際における処理例のフローチャート図である。
【図１４】サービス享受者のサービス享受ランクを変更する処理例のフローチャート図である。
【発明を実施するための形態】
【００２７】
以下、添付した図面を参照しながら、本発明の実施形態を説明する。なお、以下の記載は特許請求の範囲に記載される技術的範囲や用語の意義を限定するものではない。
【００２８】
［１．管理請求処理装置の構成及び機能概要］
先ず、本実施形態に係る管理請求処理システムＳの構成及び機能概要について、図１を用いて説明する。図１は、本実施形態に係る管理請求処理システムＳの概要構成の一例を示す図である。
【００２９】
図１に示すように、管理請求処理システムＳは、地域包括ケア一括管理請求処理装置１０（以下、管理請求処理装置と略す）と、複数の配置薬品業者等２の端末２０、複数のサービス提供者３〜６の端末３０、複数の銀行等サーバ７０及び複数の行政機関の端末８０と、を含んで構成されている。そして、管理請求処理装置１０、配置薬品業者等の端末２０、サービス提供者３〜６の端末３０、銀行等サーバ７０及び行政機関の端末８０とは、ネットワークＮＷを介して、例えば、通信プロトコルにＴＣＰ／ＩＰ等を用いて相互にデータの送受信が可能になっている。なお、ネットワークＮＷは、例えば、インターネット、専用通信回線（例えば、ＣＡＴＶ（Community Antenna Television）回線）、移動体通信網（基地局等を含む）、及びゲートウェイ等により構築されている。
【００３０】
管理請求処理装置１０は、配置薬品業者等２が管理する、もしくは契約している装置であり、内部の記憶部に支払い請求を管理するデータベースや処理プログラム等を有しており、各サービス提供者から対価請求を受け、支払い処理行う装置である。
【００３１】
端末２０は、配置薬品業者等２が保有、もしくは契約をしている通信機用を有した汎用端末であり、パソコンであってもよく、タブレット等でも良い。内部にＷＥＢブラウザアプリケーションを有している、もしくは専用アプリケーションを有しており、それらを使って、ネットワークＮＷを介し、管理請求処理装置１０に接続を行って、患者、もしくは被介護者であるサービス享受者１（以下、サービス享受者１）の登録や、サービス享受のチェック、クーポンコードの発行請求などを行う。
【００３２】
管理請求処理装置１０、端末２０は配置薬品業者等が管理、保有、もしくは契約することを前提としている。配置薬品業者とは在宅訪問をして救急箱を設置し、薬品や絆創膏を含む日用品を提供する業務を行っている。配置薬品営業担当者は一般薬の補充業務、及び生存確認をする目的で、定期的に在宅訪問を行うため、サービス享受者１と緊密な関係を取りやすく、管理請求処理システムＳの管理者としてふさわしいが、訪問介護を行う介護施設開設者や、医療関係業者が行っても良い。
【００３３】
端末３０は、病院３、介護施設４、薬局５及び介護用品業者６といったサービス提供者が保有、もしくは契約をしている通信機用を有した汎用端末であり、パソコンであってもよく、タブレット等でも良い。内部にＷＥＢブラウザアプリケーションを有している、もしくは専用アプリケーションを有しており、それらを使って、ネットワークＮＷを介し、管理請求処理装置１０に接続を行って、提供したサービスの登録、サービス提供対価費用請求などを行う。
【００３４】
銀行等サーバ７０は、サービス享受者１やサービス提供者３〜６が契約している銀行口座の銀行のサーバである。オンライン取引用に稼働しているサーバであり、ネットワークＮＷを介し、管理請求処理装置１０と接続され、対価請求費用の引き落としや振り込みを行う。
【００３５】
端末８０は、市町村である行政機関８が保有、もしくは契約をしている通信機用を有した汎用端末であり、パソコンであってもよく、タブレット等でも良い。内部にＷＥＢブラウザアプリケーションを有している、もしくは専用アプリケーションを有しており、それらを使って、ネットワークＮＷを介し、管理請求処理装置１０に接続を行って、サービス享受者１の要介護認定などの認定ランク指定を行う。
【００３６】
［２．管理請求処理装置の利用登録から対価費用請求まで］
次に、図２を参照しながら、管理請求処理装置の利用登録から対価費用請求までの説明をする。
自宅にて医療、介護サービスを享受するためにサービス享受者１は、自宅を訪問した配置薬品業者等２に対し、管理請求処理システムＳを利用するための申し込みを行う。
【００３７】
この管理請求処理システムＳを利用するための申し込みに関しては、氏名や住所及びＩＤ発行のためのマイナンバーに加え、対価請求費用の引き落としがスムーズに行われるために、銀行口座、又はクレジットカードナンバーなどを付記して行う。
【００３８】
申し込みを受けた配置薬品業者等２は端末２０を使って、ネットワークＮＷを介し、管理請求処理装置１０に接続をして、必要事項を入力し、患者、もしくは被介護者であるサービス享受者１の利用登録を行う。
申し込みを行った際、サービス享受者１にはサービス提供者が複数に渡った場合でも重複が無いように生成されたＩＤが発行されている。
【００３９】
同様にサービス提供者である医療事業者の病院３は、本発明の管理請求処理装置１０を利用する申し込みを事前に行い、管理請求処理装置１０からサービス提供者用ＩＤの発行を受けている。このＩＤは管理請求処理装置１０内で管理されていればよいため、発行ロジックは独自に設けてよい。
【００４０】
サービス提供者である病院３は、サービス享受者１からサービスの提供の依頼を受けた時、端末３０を使って、ネットワークＮＷを介し、管理請求処理装置１０に接続を行う。
【００４１】
ここで図２に加え、図３参照しながら説明をする。図３の（ａ）は地域包括ケア一括管理請求処理装置１０が有する記憶部１０２内のサービス享受者ＤＢ１０２ｂ及びサービス提供実績ＤＢ１０２ｃ構造を示しており、（ｂ）はバッチ処理後のクエリ（Query）、又は、ビュー（Ｖｅｉｗ）構造を示す図である。
接続された病院３用のＩＤで管理請求処理装置１０内にログインし、記憶部１０２内に格納されている病院３が管理しているサービス享受者１のサービス享受者ＤＢ１０２ｂにアクセスをする。端末３０内のＷＥＢブラウザアプリケーションもしくは専用アプリケーションは病院内の独自管理請求システムと連携して効率化を図っても良い。
【００４２】
病院３が管理しているサービス享受者１のサービス享受者ＤＢ１０２ｂにアクセスをした病院担当者は、サービス享受者１のＩＤを確認する画面で、サービス享受者１のＩＤを入力する。管理請求処理装置１０はサービス享受者ＩＤとサービス享受者１の氏名、住所、又は生年月日等の登録情報を病院３が保有する端末３０内のＷＥＢブラウザアプリケーションもしくは専用アプリケーションに表示をする。
【００４３】
病院担当者は、サービス提供依頼申し込み内容と、表示された内容とが一致をしていればサービス享受者１の管理請求処理装置１０の利用登録が正しく行われていることが証明されたため、サービス享受者１に対し、病院３は在宅医療などのサービスを提供することができる。
【００４４】
なお、病院３はサービス享受者１へサービス提供後に、次回の利用するためのクーポンコードの発行処理を管理請求処理装置１０に対して行って、サービス享受者１にクーポンコードを引き渡してもよい。クーポンコードの発行処理とは、サービス提供者３〜６が管理請求処理装置１０に対して行うもので、サービス提供者３〜６が入手したクーポンコードをサービス提供後にサービス享受者１に渡し、サービス享受者１が次回サービス申し込みの際にクーポンコードを提示することによって、サービスの享受を実際に受けた証明ともなるものである。
【００４５】
病院３はサービスを提供した後、管理請求処理装置１０に対しサービスの対価請求処理を行う。
病院３は保有している端末３０内のＷＥＢブラウザアプリケーションもしくは専用アプリケーションを使って、ネットワークＮＷを介し、管理請求処理装置１０に接続を行う。
病院担当者は、接続された病院３用のＩＤで、管理請求処理装置１０内にログインし、端末３０から、病院３用のＩＤ、サービスを提供した患者ＩＤ、提供した診療、治療、薬などのサービス内容と、診療費、治療費、薬代などのサービスに対価請求費用を入力する。
【００４６】
入力した内容に誤りが無ければ、確定送信処理を行う。確定送信処理が行われると、端末３０は、病院３用のＩＤ、サービスを享受した患者ＩＤが付記され、サービスの内容とサービスの対価費用請求を関連付けたデータを、管理請求処理装置１０に送信する。
【００４７】
管理請求処理装置１０は受信したサービス提供者ＩＤとサービス享受者ＩＤ付記されている対価請求費用のデータを、記憶部１０２内のサービス提供実績ＤＢ１０２ｃに書き込む。この時点ではまだサービス享受の証明が取れていないため、対価請求費用は確定しなくても良い。
【００４８】
同様にサービス提供者である介護事業者の介護施設４、薬局５、又は、介護用品業者６なども本発明の管理請求処理装置１０を利用する申し込みを事前に行い、管理請求処理装置１０からＩＤの発行を受け、上記のように病院３と同様の処理を行う。
【００４９】
管理請求処理装置１０は、毎月、もしくは決められた期間内の決められた期日に、サービス提供実績ＤＢ１０２ｃを参照して、サービス提供者ＩＤ毎と、サービス享受者ＩＤ毎に対価請求費用の集約処理を行う。
【００５０】
医療機関、介護施設、薬局、介護用品販売店といったサービス提供者３〜６のＩＤ毎の対価請求費用集約処理は、サービスを提供した対価を集約してサービス提供者に対価請求費用を振り込むために行う。
管理請求処理装置１０は記憶部１０２内のサービス提供実績ＤＢ１０２ｃを参照して、サービス提供者ＩＤｄＦ１を集約キーに設定し、クエリ（Query）、又は、ビュー（Ｖｅｉｗ）を作成、データの対価請求費用をすべて加算する。その期間の対価請求費用合計として、  サービス提供者ＩＤの決められた期間内の請求費用合計として記憶部１０２に保持する。
【００５１】
サービス享受者ＩＤ毎の対価請求費用集約処理とは、サービスを享受した対価を集約して、サービス享受者１に対価請求費用として請求書を作成し、あらかじめ指定している銀行口座等がある銀行等サーバ７０に接続をして、対価請求費用の引き落とし処理をおこなうことをいう。
管理請求処理装置１０は記憶部１０２を参照して、サービス享受者ＩＤｄＦ２を集約キーに設定し、クエリ（Query）、又は、ビュー（Ｖｅｉｗ）を作成、データの対価請求費用をすべて加算する。その期間の対価請求費用合計として、  サービス享受者ＩＤの決められた期間内の請求費用合計として記憶部１０２に保持する。
【００５２】
サービス享受者ＩＤの決められた期間内の請求費用合計とし記憶部１０２に保持された合算金額を、管理請求処理装置１０は、図４の例のようなサービス享受者ＩＤをキーとして集約した請求書として、印刷することができる。
管理請求処理装置１０を保有する配置薬品業者等２は、印刷物を請求書としてサービス享受者１に郵送で送付することによって、サービス享受者１はサービスの享受内容とその対価請求費用が一覧で確認することが可能となる。
【００５３】
管理請求処理装置１０を保有する配置薬品業者等２は、請求書を電子データとして電子メールに添付して送付、又は、LINE、MessengerといったＳＮＳ（Social Networking Service）のサービス（以下ＳＮＳ）に添付して配布することも可能である。管理請求処理装置１０に自動で送信する機能を持たせても良い。
【００５４】
管理請求処理装置１０は、請求書に印刷した対価請求費用の合算金額を、あらかじめ指定している銀行口座等がある銀行等サーバ７０に接続をして、対価請求費用の引き落とし処理をおこなう。
サービス享受者１が年金振込口座や給与振込口座等を引き落とし口座を指定している場合は、年金振込日や給料日直後に対価請求費用の引き落としを行うことにより、対価請求費用の引き落としが不可能となるリスクを回避することができる。
【００５５】
サービス享受者１から対価請求費用を引き落とした管理請求処理装置１０は、サービス提供者３〜６のＩＤ毎の対価請求費用決められた期間内の請求費用合計として、記憶部１０２に書き込まれた合計金額を参照し、サービス提供者からあらかじめ指定している銀行口座等がある銀行等サーバ７０に接続をして、その対価請求費用合計の振り込み処理をおこなう。
ここでは金銭のやり取りであり、リスクを減らすために人間を介在させ、管理請求処理装置１０が自動振り込み前に人間による確認処理を待ってから、振り込みを行ってもよい。
【００５６】
また、市町村などの行政機関８は、サービス享受者１が要介護／要支援の認定がされたり外れたり、病気を患い、患者となったり回復したり、もしくは死亡したりといった情報を、サービス享受者１やサービス提供者３〜６である医者やケアマネージャーから受け取る。この情報は保険の適用に関わり、対価請求に大きく関わるものであるので、ケアマネージャーや行政機関８は積極的にやり取りを行う情報である。
【００５７】
認定のランクが変わった場合、市町村などの行政機関８は、端末８０を使って、ネットワークＮＷを介し、管理請求処理装置１０に接続を行う。行政機関担当者は、接続された行政機関８用のＩＤで、管理請求処理装置１０内にログインし、端末８０から、サービス享受者ＩＤとランクが変更されたことを入力する。管理請求処理装置１０は記憶部１０２内のサービス享受者ＤＢ１０２ｂ内の認定ランクｄＦｒの欄の書き換えを行う。
【００５８】
［３．管理請求処理装置の構成］
次に、図５及び図６を参照しながら、管理請求処理装置１０の構成について説明する。
【００５９】
図５は、本実施形態に係る管理請求装置１０の概要構成の一例を示すブロック図で
ある。図５に示すように、管理請求処理装置１０は、通信部１０１と、記憶部１０２と、入出力インターフェース１０３と、システム制御部１０４と、を備えている。そして、システム制御部１０４と入出力インターフェース１０３とは、システムバス１０５を介して接続されている。
【００６０】
通信部１０１は、ネットワークＮＷに接続して、配置薬品業者等の端末２０及びサービス提供者の端末３０等との通信状態を制御するようになっている。
【００６１】
記憶部１０２は、例えば、ハードディスクドライブ及びＳＳＤ等により構成されている。この記憶部１０２には、サービス提供者ＤＢ１０２ａ、サービス享受者ＤＢ１０２ｂ、サービス提供実績ＤＢ１０２ｃ、銀行口座ＤＢ１０２ｄ等のデータベースが構築されている。「ＤＢ」は、データベースの略語である。なお、記憶部１０２は、本発明における記憶手段及び確認日記憶手段の一例である。
【００６２】
図６（ａ）は、サービス提供者ＤＢ１０２ａに登録される内容の一例を示す図である。サービス提供者ＤＢ１０２ａには、管理請求処理システムＳにサービス提供者登録しているサービス提供者３〜６に関するサービス享受者情報が登録される。具体的に、サービス提供者ＤＢ１０２ａには、サービス提供者ＩＤ、パスワード、サービス提供者名、郵便番号、所在地、電話番号、担当者電子メールアドレス、サービス提供者振り込み用口座情報等が、サービス提供者３〜６ごとに対応付けて登録される。サービス提供者ＩＤは、サービス提供者の識別情報である。サービス提供者振り込み用口座情報は、サービス提供者により登録された銀行の振り込み用口座の情報である。サービス提供者振り込み用口座情報には、例えば、銀行情報（銀行コード番号）、支店情報（支店コード）、普通／当座、名義人の名称、口座番号等の情報が設定される。銀行情報は、銀行を識別する情報である。サービス提供者は、予めサービス提供者振り込み用口座情報を登録しておくことにより、サービス提供のたびにサービス提供者振り込み用口座情報を入力しなくてもよい。
【００６３】
図６（ｂ）は、サービス享受者ＤＢ１０２ｂに登録される内容の一例を示す図である。サービス享受者ＤＢ１０２ｂには、管理請求処理システムＳにサービス享受者登録しているサービス享受者１に関するサービス享受者情報が登録される。具体的に、サービス享受者ＤＢ１０２ｂには、サービス享受者ＩＤ、サービス享受者名、サービス享受ランク、（要介護支援等のランク）、生年月日、郵便番号、住所、電話番号、電子メールアドレス、サービス享受者引き落とし口座情報等が、サービス享受者１ごとに対応付けて登録される。サービス享受者ＩＤは、サービス享受者１の識別情報である。サービス享受者引き落とし用口座情報は、サービス享受者１により登録された銀行の引き落とし用口座の情報である。サービス享受者引き落とし用口座情報には、例えば、銀行情報（銀行コード番号）、支店情報（支店コード）、普通／当座、名義人の名称、口座番号等の情報が設定される。銀行情報は、銀行を識別する情報である。サービス享受者ＩＤは重複を防ぐため、後述するマイナンバーから生成されたものでもよい。
【００６４】
図６（ｃ）は、サービス提供実績ＤＢ１０２ｃに登録される内容の一例を示す図である。サービス提供実績ＤＢ１０２ｃには、管理請求処理システムＳにサービス提供者３〜６がサービス提供後に、サービスを提供した実績として送信したものが登録される。具体的に、サービス提供実績ＤＢ１０２ｃには、提供年月日、提供時間、提供内容、提供サービス提供者ＩＤ、サービス享受者ＩＤ、対価請求費用、サービス享受チェック等が、サービス提供実績ごとに対応付けて登録される。提供内容は、サービス提供者３〜６がサービス享受者１に対して行ったサービスの内容であり、例えば病院３であれば「診療」、介護施設であれば「ヘルパー提供」といったものが登録される。
【００６５】
次に、記憶部１０２に記憶されるその他の情報について説明する。記憶部１０２には、ＷＥＢページを表示するためのＨＴＭＬ（HyperText Markup Language）文書、ＸＭＬ（Extensible Markup Language）文書、画像データ、テキストデータ、電子文書等の各種データが記憶されている。
【００６６】
また、記憶部１０２には、オペレーティングシステム、ＷＷＷ（World Wide ＷＥＢ）サーバプログラム、ＤＢＭＳ（Database Management System）、サービス提供処理プログラム、ｎ進数変換プログラム等の各種プログラムが記憶されている。サービス提供処理プログラムは、サービス内容と費用の受信処理、対価費用請求集約処理、サービス合計金額提示処理、口座自動引き落とし処理、口座自動振り込み処理、クーポンコード生成処理と確認処理、引き落とし可能証明処理、マイナンバーからＩＤを生成する処理等を実行するためのプログラムである。
サービス提供処理プログラムは、本発明における情報処理プログラムの一例である。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークＮＷを介して取得されるようにしてもよいし、ＤＶＤ（Digital Versatile Disc）等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。
【００６７】
入出力インターフェース１０３は、通信部１０１及び記憶部１０２とシステム制御部１０４との間のインターフェース処理を行うようになっている。
【００６８】
システム制御部１０４は、ＣＰＵ１０４ａ、ＲＯＭ（Read Only Memory）１０４ｂ、ＲＡＭ（
Random Access Memory）１０４ｃ等により構成されている。そして、システム制御部１０４は、ＣＰＵ１０４ａが、各種プログラムを読み出し実行することにより、本発明における受信手段、集約手段、提示手段、引き落とし手段、振り込み手段、第１確認手段、第２確認手段、演算手段、変換手段及び記憶手段として機能するようになっている。
【００６９】
なお、管理請求処理装置１０が、複数のサーバ装置で構成されてもよい。例えば、サービス内容受信サーバ装置、銀行口座管理処理を行うサーバ装置、端末２０及び端末３０からのリクエストに応じてＷＥＢページを送信するサーバ装置、及びデータベースを管理するサーバ装置等が、互いにＬＡＮ等で接続されてもよい。
【００７０】
［４．管理請求システムの動作］
引き続き図５を参照しながら、日本国内で重複のないサービス享受者ＩＤの生成方法について説明する。
【００７１】
患者、もしくは被介護者であるサービス享受者１から医療サービス、介護サービスを受けるための申し込みを受けた配置薬品業者等２は、端末２０、もしくは端末２０に接続されたマイナンバー読み取り機から、マイナンバーを読み取り、ネットワークＮＷを介して管理請求処理装置１０に接続し、管理請求処理装置１０内の入出力インターフェース１０３に申し込みを受けたマイナンバーを入力する。マイナンバーは重複無く住民票を有するすべての国民に割り振られているナンバーのため、このナンバーを起点にナンバーを発生させることができれば、日本国内で重複のないＩＤを作成する事ができる。
【００７２】
システム制御部１０４内のＣＰＵ１０４ａは入力されたマイナンバーからあらかじめプログラミングされている固定の値を演算する。例えばマイナンバーに固定値を加えた後、その数を整数倍する等が考えられる。本発明に係る管理請求処理システムＳに１つの固定演算を設定することにより、一意にナンバー変換をする事が可能である。また、外部には不明な演算をすることにより、万が一サービス享受者ＩＤが外部に漏れた場合にも、サービス享受者ＩＤからマイナンバーを推測されない利点がある。
【００７３】
システム制御部１０４内のＣＰＵ１０４ａはｎ進数変換プログラムを読み出し、固定演算されたマイナンバーをｎ進数に変換をする。ｎ進数は０から９までの１０進数に加え、標準キーボードで入力が可能な英文字アルファベット２６文字を加え、３６進数までの設定が可能である。本発明に係る１システムに１つのｎ進数を設定することにより、一意にナンバー変換をする事が可能である。またｎ進数のｎの値が大きければ大きいほど、桁数が減り、ユーザＩＤの扱いがし易くなる利点がある。
【００７４】
システム制御部１０４内のＲＡＭ１０４ｃは、上記で生成されたサービス享受者ＩＤを記憶する。生成されたサービス享受者ＩＤはシステムバス１０５を介し、入出力インターフェース１０３から、記憶部１０２に渡り、サービス享受者ＤＢ１０２ｂに登録される。この登録により、サービス享受者ＩＤが確定し、このＩＤに関連付けられた他情報を登録後に、サービス享受者１はサービスを享受することができる。
【００７５】
次に、図７を参照しながら、サービス享受者１が実際にサービスを享受したと、自らが証明する方法例について説明をする。
医療機関、介護施設、薬局、介護用品販売店といったサービス提供者３〜６が実際にサービスを提供した後、日々の生活の中で受けたサービスを克明に記憶しているサービス享受者１は少ない。そこで以下のフローでサービスを享受したことを自らの処理で証明する。
【００７６】
サービス提供者である病院３が医療サービスを提供する前に、端末３０を利用して、ネットワークＮＷを介して管理請求処理装置１０に接続し、サービスを提供する旨の登録をしておく。それを受け、管理請求処理装置１０はクーポンコードを生成（ステップS１１）、病院３はあらかじめそのクーポンコードを手に入れておく。
例えば、クーポンコードはサービスを提供する日が分かるように、提供日時の数字と、サービス享受者１のＩＤをキーとして固定演算を行い、生成してもよい。
【００７７】
サービス提供者である病院３が医療サービスを提供した後、病院３は次回のサービスを受けるためのクーポンコードをサービス享受者１に提示する。提示方法は、紙媒体に印刷するものを直接手渡ししても良いし、電子メールやＳＮＳにて知らせても良い。
【００７８】
サービスを享受したサービス享受者１は、決められた期日までにそのクーポンコードを付記して、在宅訪問した配置薬品業者等２に対して次回のサービス享受の利用券の申し込みを行う。配置薬品業者等２は端末２０を利用して、ネットワークＮＷを介し、管理請求処理装置１０に接続をして、クーポンコードが付記されたサービス享受申し込みデータを管理請求処理装置１０に送信をする（ステップS１２）。この際、管理請求処理装置１０はクーポンコードが付記されているか確認し（ステップS１３）、付記されていない申し込みは、管理請求処理装置１０で受け付けることができない。その場合、配置薬品業者等２は前回のサービス享受内容と日付をサービス享受者１に申込書に記載させるなど、確認させた上で、再度利用申し込みを受け付けることができる。
【００７９】
上記ステップを踏むことにより、サービス享受者１はサービスを享受した事実を自ら証明しなければ、次回のサービス享受ができないため、サービス享受の有無を把握していない高齢者や認知症患者に対しても安心してサービスの継続提供をおこなうことができる。
【００８０】
病院３と同様、サービス提供者である介護事業者の介護施設４、薬局５、又は、介護用品業者６なども上記ステップにて行うことができる。
【００８１】
次に、図８を参照しながら、サービス享受者１が配置薬品業者等２に管理請求処理装置１０を利用するために行う、初期登録のステップ例を説明する。
サービス享受者１が配置薬品業者等２の管理請求処理装置１０を利用したい場合、自宅に訪れた配置薬品業者等２や、サービス享受者１自ら配置薬品業者等２を訪れ、サービスの申し込みを行う。
【００８２】
利用申し込み用紙には、当然に、住所、氏名、年齢、職業等を記載するが、その際にある一定以上の年齢や、既往歴がある場合は、対価請求費用引き落とし口座に条件を設ける。
条件とは、その引き落とし口座が一定の周期で金銭の振り込みがあることや、ある程度の残高が一定の期間預金されていること等である。その口座は給与振込口座、年金振込口座、又は、介護保険振込口座などを想定している。
【００８３】
申し込み利用を受けた配置薬品業者等２には端末２０を利用して、ネットワークＮＷを介し、管理請求処理装置１０に接続をした後、申し込みの内容のデータを管理請求処理装置１０に送信する（ステップS２１）。データを受信した管理請求処理装置１０はある一定以上の年齢や、既往歴があるかどうか判定をする（ステップS２２）。
【００８４】
上記ステップを踏むことにより、対価請求費用の自動引き落としをする際に、口座の残高が足りず、引き落としができないリスクを回避することができる。
【００８５】
その引き落とし口座の条件を確認する手段としては、その口座の１年以上の履歴が記載されている通帳のコピーを当利用申込書に添付したり、年金振込口座の申し込み用紙のコピーを添付したり、といったことが考えられる。その添付の有無を管理処理サーバは判定し（ステップS２３）、これらが添付されていない場合は、利用の申し込みを拒絶することもできる（ステップS２４）。
【００８６】
上記ステップを踏むことにより、医療機関、介護施設、薬局、介護用品販売店といったサービス提供者３〜６がサービスを提供したにも関わらず、サービス享受者１の引き落とし口座に残高が無いといったトラブルを回避することができる。
【００８７】
次に本実施形態に係る管理請求処理装置１０による、請求費用の管理処理方法について説明する。
図９は、一実施形式に係る管理請求処理装置１０による、サービス享受者１がサービスを受け、病院等のサービス提供者３〜６が請求をする際における処理例を示すフローチャートである。図９（ａ）はサービス享受者１がサービスを受ける際の図、図９（ｂ）は病院等のサービス提供者３〜６が請求をする際の図である。
サービス享受者１が診療等を受けたり、商品等を購入したりといったサービスを享受する際に、サービス提供者である病院３に対して、サービス享受者ＩＤを示す。サービス享受者ＩＤを示された病院担当者は、端末３０内のＷＥＢブラウザアプリケーションもしくは専用アプリケーションを使って、ネットワークＮＷを介し、管理請求処理装置１０に接続をして、サービス享受者ＩＤ入力画面を開き、サービス享受者ＩＤと氏名、生年月日等を入力する。サービス享受者ＩＤがカード面に記載された、もしくは、磁気にＩＤ情報が書き込まれたカード等を示しても良い。
上記処理により、管理請求処理装置１０はサービス享受者１のＩＤと付加情報を受信する（ステップＳ３１）。
【００８８】
サービス享受者ＩＤと氏名、生年月日等が入力された管理請求処理装置１０は、記憶部１０２の中のサービス享受者ＤＢ１０２ｂ内に保管されているサービス享受者ＩＤとその他の入力情報が一致しているか判定をする（ステップＳ３２）。一致している場合は、支払い手段が確保されたと証明され、そのサービスを享受できる旨を、管理請求処理装置１０は病院３が保有する端末３０内のＷＥＢブラウザアプリケーションもしくは専用アプリケーションへ通知をする（ステップＳ３３）。一致していない場合は支払い手段を確保するまで、管理請求処理システムＳのサービスを享受できない旨を通知する（ステップＳ３４）。
【００８９】
サービス提供者である病院３は、医療サービスを提供した後、事前にクーポンコードを申請、取得し、管理請求処理装置１０ではクーポンコードを発行していた場合（ステップＳ３５）、サービス享受者１に対し、次回のサービスを受けるためにクーポンコードを提示する。紙ベースの利用証明書にサービス享受者１のサインやチェックをしてもらって、写しを病院３が保管しておいても良い。チェックやサインが行われた場合（ステップＳ３６）、病院３は端末３０内のＷＥＢブラウザアプリケーションもしくは専用アプリケーションを使って管理請求処理装置１０は記憶部１０２の中のサービス提供実績ＤＢ１０２ｃにサービス享受者１が当該サービスを享受した旨の記録を行う（ステップＳ３７）。
【００９０】
次にサービス提供者が、管理請求処理装置１０に対し、費用請求処理を行った際の例を説明する。
サービスを提供した病院３は、対価費用を請求するために、端末３０内のＷＥＢブラウザアプリケーションもしくは専用アプリケーションを使って、ネットワークＮＷを介し、管理請求処理装置１０に接続をして、提供したサービスの対価である費用をサービス享受者ＩＤと、提供したサービスと共に入力する。
上記処理により、管理請求処理装置１０は病院３のＩＤと対価費用、提供サービス名を受信する（ステップＳ４１）。
【００９１】
請求を受けた管理請求処理装置１０は、記憶部１０２の中のサービス提供実績ＤＢ１０２ｃ内で、そのサービス内容をサービス享受者１がサービスとして受けた旨の記録が入っているか否かを判断する（ステップＳ４２）。サービスを受けている場合は、記憶部１０２の中のサービス提供実績ＤＢ１０２ｃの請求フィールドに請求額を記載する（ステップＳ４３）。サービスを受けていない場合は、クーポンコード入力待ち状態となり、端末３０内のＷＥＢブラウザアプリケーションもしくは専用アプリケーション上に請求確定待ちである旨のメッセージを表示する（ステップＳ４４）
【００９２】
サービス享受者１は、配置薬品業者等２、もしくは、サービスを提供する病院３に直接申し込みをする際に、前回サービス享受をした時に病院３から提示されたクーポンコードがあれば、そのコードを申し込み用紙に記入する。申し込みを受けた配置薬品業者等２、もしくは、サービスを提供する病院３は端末３０内のＷＥＢブラウザアプリケーションもしくは専用アプリケーションを使って、ネットワークＮＷを介し、管理請求処理装置１０に接続をして、サービス利用券の発券処理を行い、管理請求処理装置１０はクーポンコードが付記された享受申請を受信する（ステップＳ４５）。
【００９３】
上記ステップ後、管理請求処理装置１０はクーポンコードが管理請求処理装置１０で生成されたものかチェックを行う（ステップＳ４６）。クーポンコードが記入されていなかったり、管理請求処理装置１０が生成したコードでなかったりした場合は特に処理は行わない（ステップＳ４７）。コードの桁数が合っていない等の人間によるオペレーションミスと推測される場合は、その旨、管理請求処理装置１０は通知をしてもよい。
クーポンコードが管理請求処理装置１０で生成されたものである場合は、前記そのクーポンコードに紐づいているサービスが享受された旨のチェックを記入するときと同じ処理を行う。
【００９４】
上記のステップで、サービスが享受された旨が確認された請求は、確定請求となり、対価請求費用の確定欄にチェックが入って、サービス提供者ＩＤ毎、サービス享受者ＩＤ毎の対価請求費用を集約するリストに加わることとなる（ステップＳ４９）。
【００９５】
次に、本実施形態に係る管理請求処理装置１０による、請求費用の集約方法について説明する。
図１０は、一実施形式に係る管理請求処理装置１０による、一定の期間の、一定の期日になった時に、自動的に対価請求費用を集約する際における処理例を示すフローチャートである。（ａ）はバッチ処理の概要、（ｂ）はサービス提供者向けの振り込み用の集約、（ｃ）はサービス享受者１向けの引き落とし用の集約の図である。
ここで一定の期間とは、月毎の処理を行うことが一般的であるが、高齢者は年金から対価請求費用を支払うことが多いと考えられるため、ここでは年金振込の期間二か月間を一定の期間とし、決められた期日とは年金振込日として説明する。
【００９６】
二カ月に一度、年金振込月の振込日である１５日の前日１４日（１５日が土曜、休日の場合はその前々日）に、集約処理のバッチ処理が走る（ステップＳ５１）。この処理は管理請求処理装置１０内にある記憶部１０２の中のサービス提供実績ＤＢ１０２ｃを参照して、図３に記載されたサービス提供者ＩＤ毎と、サービス享受者ＩＤ毎に集約を行っていく。
【００９７】
まず、サービス提供者ＩＤ毎の集約について、図３（ａ）に記載した記憶部１０２の中のサービス提供実績ＤＢ１０２ｃを参照しながら、説明する。
サービス提供実績ＤＢ１０２ｃのサービス提供者ＩＤ欄ｄF１をキーに、同じＩＤを有する対価請求費用データｄF３を集約して、クエリ（Query）、又は、ビュー（Ｖｅｉｗ）を作成する（ステップＳ５２）。作成したクエリ、又は  ビューを基に、請求リストを作成する（ステップＳ５３）。このクエリ、又は、ビューはサービス享受者１によってサービスの享受が自身によって確認がされたチェックｄＦｃが入っているデータのみを集約する。
請求リスト内の対価請求費用欄ｄＦ３の金額をすべて加算処理して（ステップＳ５４）、このサービス提供者ＩＤの２か月分の請求合計として、図３（ｂ）に記載した新たに振り込み用テーブルＱｒ１を作成して（ステップＳ５５）、サービス提供者ＩＤ、対価請求合計費用欄を記録する（ステップＳ５６）。
【００９８】
同様に、サービス享受者ＩＤ毎の集約について、図３（ａ）に記載したサービス提供実績ＤＢ１０２ｃを参照しながら、記載する。
サービス提供実績ＤＢ１０２ｃのサービス享受者ＩＤ欄ｄＦ２をキーに、同じＩＤを有する対価請求費用欄ｄＦ３を集約して、クエリ、又は、ビューを作成する（ステップＳ５７）。作成したクエリ、又は  ビューを基に、請求リストを作成する（ステップＳ５８）。このクエリ、又は、ビューはサービス享受者１によってサービスの享受が自身によって確認がされたチェックｄＦｃが入っているデータのみを集約する。
請求リスト内の対価請求費用欄ｄＦ３の金額をすべて加算処理して（ステップＳ５９）、このサービス享受者ＩＤの２か月分の請求合計として、図３（ｂ）に記載した引き落とし用テーブルＱｒ２を作成して（ステップＳ６０）、サービス享受者ＩＤ、対価請求合計費用欄を記録する（ステップＳ６１）。
【００９９】
次に、本実施形態に係る管理請求処理装置１０による、サービス享受者１へ請求書を送付する方法について説明する。
図１１は、一実施形式に係る管理請求処理装置１０による、一定の期間の、一定の期日になった時に、集約したサービス享受者毎の対価請求費用を請求書として送付する処理例を示すフローチャートである。
上記と同様に、年金振込の期間二か月間を一定の期間とし、決められた期日とは年金振込日として説明する。
【０１００】
上記バッチ処理が行われた、年金振込月の振込日である１５日の前日１４日（１５日が土曜、休日の場合はその前々日）に、上記で作成した図３の引き落とし用テーブルＱｒ２を基に、サービス享受者１のＩＤ毎、用意した請求書の表（電子データでも良いし、紙媒体でもよい）に合計金額を記入する（ステップＳ７１）。図４の例のように請求書の明細として、サービス享受者ＩＤを基に対価請求費用データを集約して作成された、クエリ、又は、ビュー上のサービス提供名、サービス提供日、対価請求費用を請求書の表に列記する（ステップＳ７２）。
【０１０１】
明細が列記された後、サービス享受者ＩＤを基に、サービス享受者１の氏名、住所（もしくは電子メールアドレス、ＳＮＳのＩＤ）を請求書の表に記入する（ステップＳ７３）。
上記ステップで請求書は完成したので、氏名、住所のみが外部から見える封筒で郵送、もしくはパスワードをかけた請求書データを添付した電子メール、ＳＮＳ経由で請求書を送付する（ステップＳ７４）。
【０１０２】
次に、本実施形態に係る管理請求処理装置１０による、請求費用の引き落とし方法について説明する。
図１２は、一実施形式に係る管理請求処理装置１０による、一定の期間の、一定の期日になった時に、自動的に対価請求費用をサービス享受者１の口座から引き落としをする際における処理例を示すフローチャートである。
上記と同様に、年金振込の期間二か月間を一定の期間とし、決められた期日とは年金振込日として記載する。
【０１０３】
上記バッチ処理と、請求書が作成、もしくは送付された翌日、年金支給月の支給日である１５日（１５日が土曜、休日の場合はその前日）に、上記で作成した図２の引き落とし用テーブルＱｒ２を基に、サービス享受者ＩＤ毎の引き落とし金額をチェックする（ステップＳ８１）。引き落とし用テーブルＱｒ２に記載されている、引き落とし銀行口座ごとにクエリ、又は、ビューを生成し（ステップＳ８２）、例えば銀行Aを指定しているサービス享受者１をまとめて、リストを作成。作成したリストを基に銀行Aに対して引き落とし処理を行う（ステップＳ８３）。同様に、銀行B、銀行Cと引き落とし処理を行っていく。
【０１０４】
引き落とし可能であったか否かを確認し（ステップＳ８４）、引き落としが無事できた場合は、特に処理は行わない。引き落としができなかった場合、引き落としができなかったサービス享受者ＩＤのテーブルに引き落とし不可の欄ｄＦ７にチェックを入れる（ステップＳ８５）。ここにチェックが入った場合、今後の利用の制限を設けても良いし、サービスの享受自体を停止するなどの処理に使っても良い。
その場合、管理請求処理装置１０は、引き落としができなかった旨をサービス享受者１に氏名、住所のみが外部から見える封筒で郵送、もしくは電子メール、ＳＮＳ経由で引き落としができなかった旨を知らせる書面を送付する（ステップＳ８６）。
またその後、振り込み用テーブルＱｒ１に記載されている、サービス提供者３〜６の振り込み金額から減額をする処理を行う（ステップＳ８７）。その上で、サービス提供者３〜６に電子メール等で、引き落としができなかったサービス享受者ＩＤ、その他情報と共に知らせる処理を行う（ステップＳ８８）。
【０１０５】
次に、本実施形態に係る管理請求処理装置１０による、請求費用の振り込み方法について説明する。
図１３は、一実施形式に係る管理請求処理装置１０による、一定の期間の、一定の期日になった時に、自動的に対価請求費用をサービス提供者の口座に振り込みをする際における処理を示すフローチャートである。
【０１０６】
上記引き落としが行われた、翌日、上記で作成した図３の振り込み用テーブルＱｒ１を基に、サービス提供者ＩＤ毎の振り込み金額をチェックする（ステップＳ９１）。そのなかで、振り込み用テーブルＱｒ１に記載されている、振り込み銀行口座ごとにクエリ、又は、ビューを作成し、例えば銀行Aを指定しているサービス提供者をまとめて、リストを作成。作成したリストを基に銀行Aに対して振り込み処理を行う（ステップＳ９２）。同様に、銀行B、銀行Cと振り込み処理を行っていく。
【０１０７】
管理請求処理装置１０は振り込みを実施したのち、サービス提供者３〜６に対して、電子メール等で振り込みを実施した旨と、振り込んだ金額を記載した文面を送付する（ステップＳ９３）。
【０１０８】
次に、本実施形態に係る管理請求処理装置１０による、サービス享受者１のサービス認定ランク（要介護支援等のランク）設定変更作について説明する。
図１４は、一実施形式に係る管理請求処理装置１０による、サービス享受者１のサービス享受ランクを変更する処理を示すフローチャートである。
【０１０９】
市町村等の行政機関８はサービス享受者１の認定ランクを変更した場合、保険料の負担が変更になるため、保有している端末８０内のＷＥＢブラウザアプリケーションもしくは専用アプリケーションを使って、ネットワークＮＷを介し、管理請求処理装置１０に接続を行い、ランク変更申請画面を開く（ステップＳ１０１）。
【０１１０】
もしサービス享受者１が死亡した場合は（ステップＳ１０２）、死亡した場合、その旨を入力するが、銀行口座等が凍結される可能性があるので、管理請求処理装置１０は未引き落とし金の有無を直ちに調べる（ステップＳ１０３）。未引き落とし金がある場合は、口座凍結前に集約処理を直ちに行い、引き落とし処理を行う（ステップＳ１０４）。
【０１１１】
引き落とし処理が無事完了した後、もしくは未引き落とし金が無かった場合は、管理請求処理装置１０はサービス享受者管理用のＤＢ１０２ｂから、該当享受者のデータを削除する（ステップＳ１０５）。
【０１１２】
認定ランク変更が「死亡処理」ではなかった場合は、認定ランク申請入力を受け、認定ランクが上がったか下がったかを確認する（ステップＳ１０６）。ランクが上がるとは要介護、要支援、患者の重度が重くなることであり、一般的に保険金や補助金が増えるケースが多いため、管理請求処理装置１０は認定ランクｄＦｒの変更をサービス享受者管理用のＤＢ１０２ｂに書き込むだけの処理となる（ステップＳ１０７）。
【０１１３】
認定ランク変更が下がった時は、要介護、要支援、患者の重度が軽くなるなった時であり、一般的に保険金や補助金が減るケースが多いため、未引き落とし金の有無を直ちに調べる（ステップＳ１０８）。未引き落とし金がある場合は、認定ランク変更前に集約処理を直ちに行い、引き落とし処理を行う（ステップＳ１０９）。
【０１１４】
引き落とし処理が無事完了した後、もしくは未引き落とし金が無かった場合は、管理請求処理装置１０は認定ランクｄＦｒの変更をサービス享受者管理用のＤＢ１０２ｂに書き込む。（ステップＳ１０７）。
【符号の説明】
【０１１５】
１    サービスを享受するサービス享受者
２    配置薬品業者、介護施設開設者、又は、医療関連事業者
３    医療サービスを提供する、医師、看護師などを有し、診療、治療等を行う病院
４    介護サービスを提供する、主に在宅介護を業とする介護施設開設者
５    薬販売サービスを提供する、薬剤師などを有し、薬の販売を業とする薬局
６    主に介護用品（介護用おむつ等）の販売を業とする介護用品販売業者
８    市町村などの行政機関
１０  地域包括ケア一括管理請求処理装置
２０  配置薬品業者等２が保有している汎用端末（パソコン、タブレット等）
３０  病院、介護施設等のサービス提供者が保有している汎用端末（パソコン、タブレット等）
７０  銀行等の金融機関が管理、保有している金銭の授受を行うサーバ
８０  行政機関８が保有している汎用端末（パソコン、タブレット等）
１０１  通信部
１０２  記憶部
１０２ａ  サービス提供者ＤＢ
１０２ｂ  サービス享受者ＤＢ
１０２ｃ  サービス提供実績ＤＢ
１０３  入出力インターフェース
１０４  システム制御部
１０４ａ  ＣＰＵ
１０４ｂ  ＲＯＭ
１０４ｃ  ＲＡＭ
１０５  システムバス
ＮＷ  ネットワーク
Ｑｒ１  振り込み用テーブル
Ｑｒ２  引き落とし用テーブル
Ｓ  管理請求処理システム
【図１】
2019197440.tif 000003
【図２】
2019197440.tif 000004
【図３】
2019197440.tif 000005
【図４】
2019197440.tif 000006
【図５】
2019197440.tif 000007
【図６】
2019197440.tif 000008
【図７】
2019197440.tif 000009
【図８】
2019197440.tif 000010
【図９】
2019197440.tif 000011
【図１０】
2019197440.tif 000012
【図１１】
2019197440.tif 000013
【図１２】
2019197440.tif 000014
【図１３】
2019197440.tif 000015
【図１４】
2019197440.tif 000016