特開 2023-109284 保険支払いシステム、情報処理方法、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023109284

(43)【公開日】2023-08-08

(54)【発明の名称】保険支払いシステム、情報処理方法、およびプログラム

(51)【国際特許分類】

   G06Q 40/08 20120101AFI20230801BHJP

【ＦＩ】

G06Q40/08

【審査請求】未請求

【請求項の数】11

【出願形態】ＯＬ

(21)【出願番号】P 2022010715

(22)【出願日】2022-01-27

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＱＲコード

(71)【出願人】

【識別番号】000002185

【氏名又は名称】ソニーグループ株式会社

(71)【出願人】

【識別番号】511083824

【氏名又は名称】ソニーフィナンシャルグループ株式会社

(74)【代理人】

【識別番号】100121131

【弁理士】

【氏名又は名称】西川 孝

(74)【代理人】

【識別番号】100082131

【弁理士】

【氏名又は名称】稲本 義雄

(74)【代理人】

【識別番号】100168686

【弁理士】

【氏名又は名称】三浦 勇介

(72)【発明者】

【氏名】平井 孝佳

(72)【発明者】

【氏名】豊島 顕

(72)【発明者】

【氏名】重谷 一樹

(72)【発明者】

【氏名】中嶋 清吾

(72)【発明者】

【氏名】藤原 貴裕

【テーマコード（参考）】

5L055

【Ｆターム（参考）】

5L055BB61

(57)【要約】

【課題】保険金の支払い可能性があることをユーザが容易に知ることができるようにする。
【解決手段】本技術の一側面の保険支払いシステムは、被保険者のマイナンバーに紐付けられた識別情報と、被保険者が受けた処置の内容を表す診療情報とを取得し、識別情報に紐付けられた１以上の保険加入番号に基づいて、被保険者が加入する保険の支払い基準に関する情報を読み出す。保険支払いシステムは、保険金の支払い可能性があるか否かを、診療情報と支払い基準とに基づいて判定し、保険金の支払い可能性があると判定した場合、識別情報に紐付けられた送信先に対して、保険金の支払い可能性があることの通知を送信する。本技術は、保険加入者と保険会社が利用するシステムに適用することができる。
【選択図】図２

【特許請求の範囲】

【請求項1】

被保険者のマイナンバーに紐付けられた識別情報と、前記被保険者が受けた処置の内容を表す診療情報とを取得する取得部と、
前記識別情報に紐付けられた１以上の保険加入番号に基づいて、前記被保険者が加入する保険の支払い基準に関する情報を読み出す読み出し部と、
保険金の支払い可能性があるか否かを、前記診療情報と前記支払い基準とに基づいて判定する判定部と、
保険金の支払い可能性があると判定された場合、前記識別情報に紐付けられた第１の送信先に対して、保険金の支払い可能性があることの通知を送信するレコメンド部と
を備える保険支払いシステム。

【請求項2】

前記診療情報が表す処置の内容には、健康保険の適用対象となる診療の内容、調剤の内容、および、看護の内容のうちの少なくともいずれかが含まれる
請求項１に記載の保険支払いシステム。

【請求項3】

前記レコメンド部は、保険金の支払い可能性がないと判定された場合、保険金の支払い可能性がないことの通知を前記第１の送信先に送信する
請求項１に記載の保険支払いシステム。

【請求項4】

保険金の支払い可能性があることの通知に対する前記被保険者による応答に基づいて、前記識別情報に紐付けられた第２の送信先に前記診療情報を送信する送信部をさらに備える
請求項１に記載の保険支払いシステム。

【請求項5】

前記送信部は、保険金の支払い可能性があるか否かの判定結果と前記保険加入番号とを含むデータがブロックチェーンデータベースに記憶された場合、前記保険加入番号を含む情報を前記第２の送信先に送信する
請求項４に記載の保険支払いシステム。

【請求項6】

前記判定部は、保険金の支払い可能性があると判定された保険に関する支払いの内容をさらに判定し、
前記レコメンド部は、支払い内容の通知を被保険者または保険会社に送信する
請求項１に記載の保険支払いシステム。

【請求項7】

前記判定部は、前記被保険者の過去の検診結果と、前記被保険者が過去に受けた診療の内容を表す他の診療情報とのうちの少なくともいずれかに基づいて、保険の告知義務を前記被保険者が果たしているか否かを判定する
請求項１に記載の保険支払いシステム。

【請求項8】

前記判定部は、保険金の支払い可能性があるか否かを、機械学習によって生成された推論モデルを用いて判定する
請求項１に記載の保険支払いシステム。

【請求項9】

同一の医療機関が発行する複数の診療情報に基づいて統計解析を行い、内容の正当性の解析結果を出力する解析部をさらに備える
請求項１に記載の保険支払いシステム。

【請求項10】

保険支払いシステムを管理する情報処理装置が、
被保険者のマイナンバーに紐付けられた識別情報と、前記被保険者が受けた処置の内容を表す診療情報とを取得し、
前記識別情報に紐付けられた１以上の保険加入番号に基づいて、前記被保険者が加入する保険の支払い基準に関する情報を読み出し、
保険金の支払い可能性があるか否かを、前記診療情報と前記支払い基準とに基づいて判定し、
保険金の支払い可能性があると判定した場合、前記識別情報に紐付けられた送信先に対して、保険金の支払い可能性があることの通知を送信する
情報処理方法。

【請求項11】

コンピュータに、
被保険者のマイナンバーに紐付けられた識別情報と、前記被保険者が受けた処置の内容を表す診療情報とを取得し、
前記識別情報に紐付けられた１以上の保険加入番号に基づいて、前記被保険者が加入する保険の支払い基準に関する情報を読み出し、
保険金の支払い可能性があるか否かを、前記診療情報と前記支払い基準とに基づいて判定し、
保険金の支払い可能性があると判定した場合、前記識別情報に紐付けられた送信先に対して、保険金の支払い可能性があることの通知を送信する
処理を実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本技術は、特に、保険金の支払い可能性があることをユーザが容易に知ることができるようにした保険支払いシステム、情報処理方法、およびプログラムに関する。

【背景技術】

【0002】

生命保険や医療保険の保険金を受け取るためには、保険加入者または保険加入者の親族等が保険会社に対して保険を適用する旨を示した申請をする必要がある。

【0003】

例えば申請者は、保険適用を申請する際は、保険会社が予め用意している申請書のテンプレートに記入して申請書を作成し、保険会社に申請書と証明書類（例えば医療機関の証明書）等を提出する。保険会社は、保険加入者が提出した提出書類をもとに審査を行い、保険金の支払い事由に該当することを確認してから保険金を支払うことになる。

【0004】

保険会社側は、支払い漏れを防ぐために多大な労力をかけている。そのため、支払い漏れを防ぐためのシステムとして各種のシステムが提案されている（特許文献１）。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２０１３－３７５０号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

保険金の支払い申請は、保険加入者または保険加入者の親族にとって不幸な出来事が起こった直後に行われることが多い。そのような状態での申請は、体力的または精神的に難しい場合がある。

【0007】

本技術はこのような状況に鑑みてなされたものであり、保険金の支払い可能性があることをユーザが容易に知ることができるようにするものである。

【課題を解決するための手段】

【0008】

本技術の一側面の保険支払いシステムは、被保険者のマイナンバーに紐付けられた識別情報と、前記被保険者が受けた処置の内容を表す診療情報とを取得する取得部と、前記識別情報に紐付けられた１以上の保険加入番号に基づいて、前記被保険者が加入する保険の支払い基準に関する情報を読み出す読み出し部と、保険金の支払い可能性があるか否かを、前記診療情報と前記支払い基準とに基づいて判定する判定部と、保険金の支払い可能性があると判定された場合、前記識別情報に紐付けられた第１の送信先に対して、保険金の支払い可能性があることの通知を送信するレコメンド部とを備える。

【0009】

本技術の一側面においては、被保険者のマイナンバーに紐付けられた識別情報と、前記被保険者が受けた処置の内容を表す診療情報とが取得され、前記識別情報に紐付けられた１以上の保険加入番号に基づいて、前記被保険者が加入する保険の支払い基準に関する情報が読み出される。また、保険金の支払い可能性があるか否かが、前記診療情報と前記支払い基準とに基づいて判定され、保険金の支払い可能性があると判定された場合、前記識別情報に紐付けられた送信先に対して、保険金の支払い可能性があることの通知が送信される。

【図面の簡単な説明】

【0010】

【図1】本技術の一実施形態に係る情報処理システムにより実現される保険支払いプラットフォームの利用者の例を示す図である。

【図2】保険支払いプラットフォームによる情報提供の全体の流れを示す図である。

【図3】保険会社とユーザの間のやりとりの例を示す図である。

【図4】マイナンバーと保険加入番号の関係を示す図である。

【図5】事前準備の流れを示す図である。

【図6】加入者管理情報の例を示す図である。

【図7】ユーザが医療機関を訪れてから健康保険の資格情報を確認するまでの処理の流れを示す図である。

【図8】同意確認画面の例を示す図である。

【図9】医療機関に提供される資格情報の例を示す図である。

【図10】資格情報を確認してから保険金受け取りレコメンドを送信するまでの処理の流れを示す図である。

【図11】保険金受け取りレコメンドの例を示す図である。

【図12】意思確認画面の例を示す図である。

【図13】PF管理サーバの構成例を示すブロック図である。

【図14】PF管理サーバの機能構成例を示すブロック図である。

【図15】PF管理サーバの処理について説明するフローチャートである。

【図16】ブロックチェーンのデータベースの例を示す図である。

【図17】トランザクションデータの例を示す図である。

【図18】トランザクションデータの例を示す図である。

【図19】推論モデルの例を示す図である。

【発明を実施するための形態】

【0011】

以下、本技術を実施するための形態について説明する。説明は以下の順序で行う。
１．保険支払いプラットフォームについて
２．事前準備
３．全体の処理の流れ
４．PF管理サーバの構成と動作
５．変形例

【0012】

＜保険支払いプラットフォームについて＞
図１は、本技術の一実施形態に係る情報処理システムにより実現される保険支払いプラットフォームの利用者の例を示す図である。

【0013】

図１に示すように、医療機関、保険会社、ユーザが、保険支払いプラットフォームの主な利用者となる。図１の例においては、医療機関と保険会社がそれぞれ２つずつ示されているが、さらに多くの医療機関と保険会社が保険支払いプラットフォームの利用者となる。

【0014】

医療機関は、医療に関する法で規定された、病院、診療所、介護老人保健施設、調剤を実施する薬局、その他の医療を提供する施設である。医療機関は、例えば、健康保険法で規定する健康保険を利用した保険診療に対応した機関である。

【0015】

保険会社は、生命保険、医療保険、火災保険などの、被保険者が診療を受けた場合に保険金を支払う契約を含む保険商品を販売する会社である。なお、以下では保険診療を対象とした保険商品の例を説明するが、自由診療を対象としてもよい。

【0016】

ユーザは、図１の下方に示すように、保険会社が販売する保険の加入者である。ユーザは、保険者である保険会社に対して、被保険者となる。また、ユーザは、医療機関で診療を受けた場合には患者となる。適宜、ユーザのことを、単にユーザとして説明することもあるし、保険加入者として説明することもある。また、被保険者として説明することもあるし、患者として説明することもある。

【0017】

保険支払いプラットフォームは、ユーザが患者として保険診療を受けた場合に、保険に関連する情報をユーザや保険会社に提示するなどの、各種のサービスを提供するシステムである。

【0018】

図２は、保険支払いプラットフォームによる情報提供の全体の流れを示す図である。

【0019】

保険支払いプラットフォームの各種の機能は、インターネット上の情報処理装置であるPF（プラットフォーム）管理サーバ１によって実現される。PF管理サーバ１は、１台のコンピュータにより、または、複数台のコンピュータが連携することにより構成される。

【0020】

以下、保険支払いプラットフォームの機能を実現するための処理を、PF管理サーバ１が行う処理として説明する。医療機関と保険会社の処理は、基本的には、それぞれの業務管理システムにより行われる。

【0021】

PF管理サーバ１は、保険加入者の情報である加入者管理情報のデータベースである保険加入者DB２を有する。加入者管理情報には、それぞれのユーザが保険加入者として加入する保険に関する情報、それぞれのユーザのマイナンバー、保険支払いプラットフォーム側からの通知の送信先などの情報が含まれる。マイナンバーは、政府機関が定めた社会保障・税番号である。以下ではマイナンバーを用いた例を説明する。なお、健康保険証が紐づいている、または、健康保険証の機能を有し、個人ごとに設定されている識別子であればマイナンバーの代わりにその識別子を用いてもよい。

【0022】

矢印Ａ１に示すように、ユーザが医療機関を訪れ、窓口でマイナンバーカードを提示する。医療機関の窓口には、マイナンバーカードの読み取りを行うカードリーダが設置されている。マイナンバーカードを用いた受け付けを行うことにより、ユーザは保険診療を受けることができる。なお、マイナンバーカードの代わりに、マイナンバーカードと同等の機能を有するデバイスを用いてもよい。例えば、マイナンバーが設定されているアプリケーションを用いてもよい。

【0023】

すなわち、保険支払いプラットフォームは、マイナンバーに健康保険証が紐付いていることを前提としたシステムである。ユーザは、健康保険証に代えて、マイナンバーカードを用いた受付を済ませてから診療を受けることになる。

【0024】

マイナンバーカードが提示された後、健康保険の資格情報の確認が行われる。一連の処理の詳細については後述する。

【0025】

診療が終わったとき、医療機関において診療情報が作成される。診療情報は、診療内容を示す情報を含む情報であり、例えばレセプト（診療報酬明細書）や診療レシートである。診療情報は、以下ではレセプトを用いた例を説明する。レセプトは、医療機関が健康保険組合に医療費を請求するために、患者に対して行った処置の内容などを記載した明細書である。レセプトは、医療機関の端末において、電子的な情報として生成される。なお、レセプトを用いる場合は保険診療が対象となるが、他の診療情報を用いて自由診療も対象としてもよい。例えば、医療機関が保険診療および自由診療の診療内容を記載可能なフォーマットに診療内容を記載して生成された情報を診療情報として用いてもよい。このとき、保険診療の診療内容についてはレセプトに基づいて自動的に診療内容が記入されてもよい。

【0026】

矢印Ａ２に示すように、医療機関からPF管理サーバ１に対してレセプトが提供される。後述するように、保険支払いプラットフォームに対するレセプトの提供は、レセプトを提供することに対してユーザが同意している場合に行われる。

【0027】

PF管理サーバ１は、保険加入者DB２に記憶されている加入者管理情報を参照し、ユーザが加入している保険を特定する。PF管理サーバ１は、レセプトと、ユーザが加入する保険の支払い基準などに基づいて、保険金の支払い可能性があるか否かを判定する。

【0028】

保険金の支払い可能性があると判定した場合、PF管理サーバ１は、矢印Ａ３に示すように、ユーザに対して、保険金の支払い可能性があることの通知を送信する。ユーザに対する通知は、電子メール、SNSのメッセージなどの各種の手段を用いて行われる。

【0029】

以下、適宜、保険金の支払い可能性があることの通知を、保険金の受け取りをユーザに勧める通知という意味で保険金受け取りレコメンドという。

【0030】

また、PF管理サーバ１は、保険者である保険会社に対してレセプトを提供することにユーザが同意している場合、矢印Ａ４に示すように、レセプトを提供し、保険会社との間で共有する。

【0031】

保険支払いプラットフォームとの間でレセプトを共有する保険会社は、レセプトの内容とユーザが加入する保険の内容とを比較するなどして、保険金の支払い可能性があると判定されたことが正しいか否かを確認する。保険金の支払い可能性があると判定されたことが正しい場合、図３の矢印Ａ４に示すように、保険会社は、ユーザに連絡し、必要書類の案内などを行う。

【0032】

ユーザによる必要書類の提示を受けるなどして、保険金を支払うことができる状態になった場合、保険会社は、矢印Ａ５に示すように、ユーザに対して保険金を支払う。

【0033】

このように、保険支払いプラットフォームにおいては、ユーザが保険診療を受けた場合の保険金の支払いに関するやりとりが、保険支払いプラットフォーム側（PF管理サーバ１側）からの通知をトリガとして開始される。

【0034】

保険診療を受けた保険加入者が保険金の支払いを受けるための従来の流れは以下のようになる。
・保険加入者は、診療を受けた後、自分が契約している生命保険・医療保険・火災保険（団体信用保険）の内容を思い出し、医療機関が発行する診断書に書かれている自分の病気（病名）で保険金の支払いを受けることができるかどうかを判断する。保険金の支払いを受けることができると判断した場合、保険加入者は保険会社に問い合わせを行う。
・保険会社は、提出書類を保険加入者に説明し、保険加入者が提出した書類（医療機関の証明書等）をもとに審査を行う。保険会社は、保険加入者の病気が支払い事由に該当する場合に保険金を支払う。

【0035】

このように、任意保険についての従来の保険金の支払いの流れにおいては、患者である保険加入者側がアクションを起こさなければ、保険加入者がどのような状態であるのかを保険会社が知ることもできない。

【0036】

また、保険加入者側も、保険会社に対する申請が必要なときは、大病を患った後であったり、手術を行った後であったりと、申請を検討することも難しい状態であることが多い。

【0037】

上述したように、診療を受けた場合の保険金の支払いに関するやりとりが保険支払いプラットフォーム側からの通知をトリガとして開始されることにより、ユーザは、自分の保険の内容を把握していない場合であっても、保険金の支払い可能性があることを容易に知ることができる。ユーザは、自分から申請をしなくても、保険金の支払い申請の漏れを防ぐことが可能となる。

【0038】

また、保険会社は、ユーザからの保険金支払いの申請を待つことなく、ユーザに連絡し、保険金の支払いに関するやりとりを始めることができる。保険会社は、保険金の支払い漏れを防ぐことが可能となる。

【0039】

＜事前準備＞
保険金受け取りレコメンドをユーザが受けるためには、図４に示すように、ユーザのマイナンバーと保険加入番号の紐付けが行われている必要がある。

【0040】

保険加入番号は、保険支払いプラットフォームが発行する保険加入者の識別情報である。それぞれのユーザに対して保険加入番号が発行される。

【0041】

マイナンバーと保険加入番号を紐付けるための処理が、事前準備の処理として行われる。

【0042】

図５は、事前準備の流れを示す図である。

【0043】

矢印Ａ１１に示すように、ユーザに対して保険加入番号が発行される。保険加入番号は、例えば、ユーザが保険支払いプラットフォームの利用者としてユーザ登録を行ったときにPF管理サーバ１により発行される。

【0044】

保険加入番号の発行を受けたユーザは、保険会社が販売する生命保険、医療保険などの任意保険に加入する際に、矢印Ａ１２に示すように、保険会社を介して、ユーザ情報を保険支払いプラットフォームに通知する。

【0045】

ユーザ情報には、ユーザID、パスワード、氏名、マイナンバー、送信先、および、保険IDが含まれる。

【0046】

ユーザIDは、例えば保険支払いプラットフォームの利用者登録時に設定される識別情報である。ユーザIDは、上述した保険加入番号とは異なる識別情報である。

【0047】

パスワードは、保険支払いプラットフォームのサービスを利用するために用いられるパスワードである。保険支払いプラットフォームのサービスを利用するためのインターネット上のサイトが用意されている。ユーザは、インターネット上のサイトにおいてユーザIDとパスワードを用いてログインすることにより、保険支払いプラットフォームのサービスを利用することが可能となる。

【0048】

氏名は、ユーザの氏名である。

【0049】

マイナンバーは、ユーザのマイナンバーである。

【0050】

送信先は、保険金受け取りレコメンドなどの、保険支払いプラットフォームの通知の送信先である。例えば、ユーザのメールアドレスが送信先として設定される。保険金受け取りレコメンドなどの通知の送信先がユーザにより登録される。

【0051】

保険IDは、ユーザが加入した保険の識別情報である。各保険会社の保険商品のそれぞれに対してIDが割り振られる。

【0052】

PF管理サーバ１は、以上のような情報を含むユーザ情報に基づいて、矢印Ａ１３に示すように、加入者管理情報を保険加入者DB２に登録する。

【0053】

図６は、加入者管理情報の例を示す図である。

【0054】

図６に示すように、加入者管理情報は、ユーザ情報として提供された、ユーザID、パスワード、氏名、マイナンバー、送信先、および保険IDとともに、保険加入番号を含むことによって構成される。

【0055】

保険加入番号は、ユーザに対して発行された保険加入番号である。ユーザに対して発行された保険加入番号がユーザIDなどに基づいて特定され、加入者管理情報に含められる。加入者管理情報が登録されることにより、マイナンバーと保険加入番号が保険支払いプラットフォームにおいて紐付けられた状態になる。

【0056】

図６の例においては、ユーザが加入する保険の保険IDとして、保険ID-1、保険ID-2、保険ID-3が示されている。例えばユーザが新たな保険に加入する毎に、保険IDが追加して登録される。

【0057】

このように、保険支払いプラットフォームにおいては、マイナンバーと保険加入番号が紐付けられるだけでなく、ユーザIDに対して、マイナンバー、保険加入番号などの各種の識別情報が紐付けられる。１つのユーザIDに対して、１つの保険加入番号だけでなく、複数の保険加入番号が紐付けられるようにしてもよい。

【0058】

PF管理サーバ１は、それぞれの保険会社の連絡先（通知の送信先）と、それぞれの保険会社が販売する保険IDの情報を管理する。ユーザIDに対して保険IDが紐付けられることにより、ユーザIDに対して、保険会社に対する通知の送信先も紐付けられる。

【0059】

加入者管理情報が登録された場合、図５の矢印Ａ１４に示すように、PF管理サーバ１は、マイナンバーと保険加入番号を紐付けて登録することを資格確認機関に依頼する。資格確認機関に対する依頼は、特定のマイナンバーのユーザに特定の保険加入番号を紐付けて登録することを要求する情報を、資格確認機関のシステムに送信することによって行われる。

【0060】

資格確認機関のシステムは、PF管理サーバ１からの依頼に応じてマイナンバーを確認し、資格確認機関が管理するサーバに保険加入番号を記憶させる。資格確認機関が管理するサーバにおいては、マイナンバーに紐付けて保険加入番号が記憶される。

【0061】

以上のような事前準備の処理により、保険支払いプラットフォームと資格確認機関のそれぞれにおいて、マイナンバーに対して保険加入番号が紐付けられた状態となる。

【0062】

なお、保険者加入番号は、ユーザを識別可能なIDであれば様々な識別情報を用いることが可能である。保険者加入番号に紐付けられた識別情報が生成され、生成された識別情報が、資格確認機関のサーバに保険者加入番号に代えて記憶されるようにしてもよい。

【0063】

マイナンバー自体が保険加入番号に替えて使用されるようにしてもよい。

【0064】

＜全体の処理の流れ＞
ここで、保険金受け取りレコメンドをユーザが受けるまでの各装置の処理の流れについて説明する。

【0065】

保険金受け取りレコメンドをユーザが受けるまでの全体の処理は、主に、ユーザが医療機関を訪れてから健康保険の資格情報を確認するまでの処理と、資格情報を確認してから保険金受け取りレコメンドを送信するまでの処理に分けられる。

【0066】

図７は、ユーザが医療機関を訪れてから健康保険の資格情報を確認するまでの処理の流れを示す図である。医療機関は、例えば診療が可能な医療機関や薬局である。

【0067】

ユーザは、病気をするなどして患者として医療機関を訪れた場合、矢印Ａ２１に示すように、自分のマイナンバーカードをカードリーダ１１に読み取らせる。医療機関の窓口には、マイナンバーカードのICチップに記憶されている情報の読み取りを行うカードリーダ１１が設置されている。

【0068】

マイナンバーカードの提示の際、レセプトを保険支払いプラットフォームに提供することについての同意確認が行われる。同意確認は、例えばカードリーダ１１に設けられたディスプレイに表示される同意確認画面を用いて行われる。

【0069】

図８は、同意確認画面の例を示す図である。

【0070】

図８に示すように、同意確認画面には、レセプトを保険支払いプラットフォームに提供することに同意するか否かをユーザに問い合わせる内容のメッセージが表示される。メッセージの下には、同意するときに押下するボタンと、同意しないときに押下するボタンが表示される。カードリーダ１１のディスプレイには例えばタッチパネルが設けられる。

【0071】

ユーザは、このような同意確認画面を見て、レセプトを保険支払いプラットフォームに提供することに同意するか否かを選択する。レセプトを提供することにユーザが同意した場合、そのことを表す同意情報が生成され、カードリーダ１１内に保存される。同意情報にはタイムスタンプが付加される。

【0072】

医療機関での受付時に、受付デバイスを用いて同意を得られた場合に同意情報が生成されるようにしてもよい。例えば、タブレット端末などの、カードリーダ１１とは別のデバイスが受付デバイスとして用いられる。

【0073】

患者または患者の家族の同意を得られた場合に、その情報が医療機関のPCに入力され、医療機関のPCにおいて同意情報が生成されるようにしてもよい。この場合、患者または患者の家族の同意の確認は、紙の同意書を用いて行われる。

【0074】

医療機関の受付がマイナンバーカードを用いて行われるのではなく、受付デバイスまたは紙を用いて行われるようにしてもよい。この場合、カードリーダ１１は、マイナンバーカードに記憶されている電子証明書の有効性を確認するためのデバイスとなる。

【0075】

マイナンバーカードから電子証明書を読み取ったカードリーダ１１は、矢印Ａ２２に示すように、資格確認機関が管理するオンライン資格確認システム１３（支払基金・国保中央会のオンライン資格確認システム）に電子証明書を送信し、資格情報を要求する。レセプトを保険支払いプラットフォームに提供することにユーザが同意している場合、保険加入番号ありの資格情報がオンライン資格確認システム１３に対して要求される。

【0076】

なお、オンライン資格確認は、全国民の資格情報を一元的に管理するシステムを利用し、患者のマイナンバーカードを元に、患者が加入している医療保険の内容をオンライン上で確認できる仕組みである。

【0077】

オンライン資格確認システム１３は、地方公共団体情報システム機構が管理する公的個人認証サービス（図示せず）に対して、電子証明書の有効性を照会する。電子証明書が無効である場合、オンライン資格確認システムは、電子証明書が無効であり、資格情報が取得できないことを表す情報を医療機関の業務用端末１２に送信する。

【0078】

一方、電子証明書が有効である場合、矢印Ａ２３に示すように、オンライン資格確認システム１３は、電子証明書に紐付く資格情報（電子証明書に紐付くマイナンバーに紐付く資格情報）を中間サーバ１４から読み出す。中間サーバ１４は、全国民のマイナンバーと、資格情報を含む各種の情報を紐付けて管理するサーバである。

【0079】

オンライン資格確認システム１３は、中間サーバ１４から読み出した資格情報に保険加入番号を付加し、矢印Ａ２４に示すように、医療機関の業務用端末１２に送信する。

【0080】

図９は、医療機関に提供される資格情報の例を示す図である。

【0081】

図９に示すように、資格情報には、氏名、性別、生年月日、保険者名、被保険者記号番号（健康保険）、得喪情報、および保険加入番号が含まれる。

【0082】

資格情報に付加される保険加入番号は、事前準備の処理によって資格確認機関においてマイナンバーと紐付けて管理されていた保険加入番号である（図５）。

【0083】

なお、資格情報の取得時ではなく、医療機関が問い合わせを行ったときに保険加入番号が取得されるようにしてもよい。例えば、保険加入番号がマイナンバーと紐付けてマイナポータルにおいて管理されている場合、医療機関の業務用端末１２からマイナポータル（マイナポータルを管理するシステム）に対して問い合わせが行われ、その問い合わせに応じて保険加入番号が取得される。

【0084】

図７に示すように、資格情報が付加された保険加入番号を取得した業務用端末１２は、資格情報と患者IDを紐付けて記憶する。患者IDは、医療機関が発行する患者の識別情報である。

【0085】

以上のような処理が、ユーザが医療機関の窓口でマイナンバーカードをカードリーダ１１に読み取らせたときに行われる。マイナンバーカードの提示を含む受付が終わった場合、ユーザは診察を受けることになる。医者による診察に代えて、または、診察とともに、治療、投薬、薬の提供、入院措置などが行われることがある。

【0086】

図１０は、資格情報を確認してから保険金受け取りレコメンドを送信するまでの処理の流れを示す図である。

【0087】

患者であるユーザに対する診察などが終わった場合、図１０の左端に示すように、医療機関の業務用端末１２は、処置の内容を電子カルテに記録することによってレセプト（診療報酬明細書）を作成する。

【0088】

マイナンバーカードを用いた受付が行われた医療機関が保険薬局である場合には、調剤報酬明細書がレセプトとして作成される。また、マイナンバーカードを用いて訪問看護が行われた場合には、訪問看護療養費明細書がレセプトとして作成される。レセプトに記録されるユーザの処置の内容には、診療の内容、調剤の内容、看護の内容のうちの少なくともいずれかが含まれる。

【0089】

レセプトを保険支払いプラットフォームに提供することにユーザが同意している場合、矢印Ａ３１に示すように、医療機関の業務用端末１２は、レセプトをPF管理サーバ１に送信する。

【0090】

例えば、レセプトを提供することに同意していることを表す情報が同意情報に含まれている場合、または、資格確認機関から送信されてきた資格情報に保険加入番号が含まれている場合に、レセプトを保険支払いプラットフォームに提供することにユーザが同意しているとして判断される。

【0091】

図１０の吹き出しに示すように、業務用端末１２が送信するレセプトには、資格確認機関から提供された保険加入番号が含まれる。

【0092】

双方向の矢印Ａ３２に示すように、PF管理サーバ１は、保険加入者DB２に記憶されている加入者管理情報を参照し、保険加入番号に基づいて、ユーザが加入している保険の種類を特定する。ここでは、レセプトに含まれる保険加入番号と同じ保険加入番号を含む加入者管理情報が保険加入者DB２から読み出され、加入者管理情報に含まれる保険IDに基づいて、ユーザが加入している保険の種類が特定される。

【0093】

PF管理サーバ１は、レセプトの内容に基づいてユーザの病名を推定する。レセプトには点数などが書いてあり、病名までは記録されていない。病名の推定が、機械学習によって生成された推論モデルを用いて行われるようにしてもよい。推論モデルは、レセプトの内容と病名の組み合わせを学習データとした機械学習によって生成される。

【0094】

PF管理サーバ１は、推定した病名と保険金の支払い基準とを比較することによって、保険金の支払い可否判定を行う。保険金の支払い可否判定は、保険金の支払い可能性があるか否かの判定である。

【0095】

保険金の支払い可能性があると判定した場合、PF管理サーバ１は、矢印Ａ３３に示すように、被保険者であるユーザに対して、保険金受け取りレコメンドを送信する。保険金受け取りレコメンドの送信は、例えば電子メールを用いて行われる。電子メールの送信先は、保険加入番号と紐付けて加入者管理情報において管理されていた情報（図６）に基づいて特定される。

【0096】

なお、複数の送信先が保険加入番号と紐付けて管理されるようにしてもよい。これにより、被保険者の親族などに対しても、保険金の支払い可能性があることを知らせることが可能となる。

【0097】

図１１は、電子メールを用いた保険金受け取りレコメンドの例を示す図である。

【0098】

図１１に示すように、電子メールの本文には、保険金を受け取ることができる可能性があることを通知するメッセージが含まれる。メッセージには、保険金の受け取りに関する意思確認を行う場合のアクセス先となるURLが含まれる。

【0099】

このような電子メールをスマートフォンなどのデバイスを用いて見たユーザがURLを選択した場合、Webブラウザが起動し、URLに対するアクセスが行われる。Webブラウザにより、意思確認画面が表示される。保険金受け取りレコメンドの表示や意思確認画面の表示が専用のアプリケーションによって行われるようにしてもよい。

【0100】

図１２は、意思確認画面の例を示す図である。

【0101】

図１２に示すように、意思確認画面には、医療機関で受けた診療についての保険金を受け取ることができるかどうかを保険会社に確認するか否かを問い合わせる内容のメッセージが表示される。

【0102】

また、レセプトを保険会社との間で共有することについて同意するか否かを確認する内容のメッセージが表示される。レセプトを共有することにより、保険会社とのやりとりがスムーズになることについても案内される。

【0103】

保険会社に確認することが選択された場合、PF管理サーバ１は、ユーザの情報を保険会社に送信することによって、保険金の支払い可能性があることを保険会社に通知する。

【0104】

また、保険会社に確認するとともに、レセプトを共有することが選択された場合、PF管理サーバ１は、図１０の矢印Ａ３４に示すように、レセプトを送信し、保険金の支払い可能性があることを保険会社に通知する。

【0105】

PF管理サーバ１からの通知を受けた保険会社は、被保険者に連絡し、保険金の受け取りに必要な書類の確認などを行う。保険会社と被保険者の間のやりとりが、保険支払いプラットフォームに用意された連絡機能を用いて行われるようにしてもよい。

【0106】

このように、保険支払いプラットフォームを利用することにより、被保険者は、医療機関を受診するだけで、保険金の支払い可能性があることの通知を受けることができる。被保険者は、複数の保険に加入している場合でも、自分の病気とそれぞれの保険会社の支払い基準を比較しないで済む。

【0107】

一方、保険会社は、保険金の支払い状況が発生していることを容易に確認することができる。

【0108】

保険会社によって、保険金の受け取りに必要な書類が異なることがある。保険支払いプラットフォーム側での保険金の支払い可否判定を一次確認、保険会社側での被保険者とやりとりを二次確認とすることで、保険会社のワークフローを大きく変えずに、保険金の支払い処理を実現することが可能となる。

【0109】

被保険者の保険加入番号とレセプトを使った保険金の支払い可否判定が医療機関の受付システム内で行われるようにすることも考えられるが、この場合、受付システムの情報を新しい保険ができる毎に更新する必要があり、現実的ではない。

【0110】

また、保険会社によって病気の判定基準などが異なるため、医療機関の受け付けシステム内で保険金の支払い可否判定を行うことは難しい。１人のユーザが複数の保険に加入している場合があるため、全ての保険についての保険金の支払い可否判定を行うには時間がかかる。

【0111】

保険金の支払い可否判定が保険支払いプラットフォームにおいて行われるようにすることにより、そのような負担を医療機関側にかけることなく、保険金の支払い可能性があるか否かを容易に判定することが可能となる。

【0112】

＜PF管理サーバ１の構成と動作＞
・PF管理サーバ１の構成
図１３は、PF管理サーバ１の構成例を示すブロック図である。

【0113】

図１３示すように、PF管理サーバ１はコンピュータにより構成される。複数台のコンピュータによりPF管理サーバ１が構成されるようにしてもよい。PF管理サーバ１が複数台のコンピュータにより構成される場合、それぞれのコンピュータが協働することにより、上述した各種の処理が実現される。

【0114】

CPU(Central Processing Unit)１０１、ROM(Read Only Memory)１０２、RAM(Random Access Memory)１０３は、バス１０４により相互に接続される。

【0115】

バス１０４には、さらに、入出力インタフェース１０５が接続される。入出力インタフェース１０５には、入力部１０６、出力部１０７、記憶部１０８、通信部１０９、およびドライブ１１０が接続される。

【0116】

入力部１０６は、キーボード、マウスなどより構成される。出力部１０７は、ディスプレイなどにより構成される。

【0117】

記憶部１０８は、ハードディスクや不揮発性のメモリなどにより構成される。記憶部１０８は、CPU１０１が実行するプログラムなどの各種の情報を記憶する。

【0118】

通信部１０９は、インターネットに対するインタフェースである。例えば、通信部１０９は、医療機関の業務用端末１２と通信を行い、業務用端末１２から送信されてきたレセプトを受信する。また、通信部１０９は、保険会社の業務用端末との間で通信を行い、保険金の支払い可能性があるユーザのレセプトを保険会社に送信する。

【0119】

ドライブ１１０は、リムーバブルメディア１１１に対するデータの書き込み、リムーバブルメディア１１１からのデータの読み出しを制御する。

【0120】

図１４は、PF管理サーバ１の機能構成例を示すブロック図である。図１４に示す機能部のうちの少なくとも一部は、図１３のCPU１０１により所定のプログラムが実行されることによって実現される。

【0121】

図１４に示すように、PF管理サーバ１においては情報処理部１２１が実現される。情報処理部１２１は、取得部１３１、読み出し部１３２、支払い可否判定部１３３、レコメンド部１３４、および送信制御部１３５により構成される。

【0122】

取得部１３１は、通信部１０９を制御し、事前準備の際に保険会社から送信されてきたユーザ情報を受信し、取得する。取得部１３１により取得されたユーザ情報は、保険加入者DB２に供給され、保険加入番号とともに、加入者管理情報として記憶される。

【0123】

また、取得部１３１は、医療機関の業務用端末１２との間で通信を行う。取得部１３１は、業務用端末１２から送信されてきたレセプトを受信し、取得する。取得部１３１により取得されたレセプトは、支払い可否判定部１３３と送信制御部１３５に供給される。

【0124】

取得部１３１が取得するユーザ情報には、マイナンバーに紐付けられた、ユーザIDを含む識別情報が含まれる。取得部１３１は、被保険者のマイナンバーに紐付けられた識別情報と被保険者のレセプトとを取得する取得部として機能する。

【0125】

読み出し部１３２は、レセプトに含まれる保険加入番号に基づいて、ユーザの加入者管理情報を保険加入者DB２から読み出す。読み出し部１３２により読み出された加入者管理情報は、支払い可否判定部１３３、レコメンド部１３４、および送信制御部１３５に供給される。

【0126】

また、読み出し部１３２は、加入者管理情報に含まれる保険IDに基づいて、ユーザが加入する保険についての保険金の支払い基準に関する情報を保険加入者DB２から読み出す。読み出し部１３２により読み出された保険金の支払い基準に関する情報は、支払い可否判定部１３３に供給される。

【0127】

読み出し部１３２は、加入者管理情報において識別情報に紐付けられた保険加入番号に基づいて、保険金の支払い基準に関する情報を読み出す読み出し部として機能する。

【0128】

保険加入者DB２には、それぞれの保険の保険金の支払い基準に関する情報も記憶されている。保険加入者DB２が記憶部１０８に構築されるようにしてもよいし、外部のデータベースとして構築されるようにしてもよい。

【0129】

支払い可否判定部１３３は、取得部１３１から供給されたレセプトと、読み出し部１３２から供給された保険金の支払い基準とを比較することによって、保険金の支払い可否判定を行う。保険金の支払い可否判定は、例えば、レセプトに基づいてユーザの病名や症状を推定し、推定した病名などと、保険金の支払い基準とを比較することによって行われる。保険金の支払い可否判定の結果を表す情報は、レコメンド部１３４と送信制御部１３５に供給される。

【0130】

レコメンド部１３４は、保険金の支払い可能性があると判定された場合、保険金受け取りレコメンドをユーザに送信する。レコメンド部１３４による制御に従って、保険金受け取りレコメンドが通信部１０９から送信される。保険金受け取りレコメンドの送信先として、加入者管理情報に含まれる送信先が用いられる。

【0131】

また、レコメンド部１３４は、保険金の支払い可能性がないと判定された場合、そのことを表す通知をユーザに送信する。

【0132】

送信制御部１３５は、保険金の支払い可能性があると判定された場合、通信部１０９を制御し、そのことを表す情報を保険会社に送信する。

【0133】

また、送信制御部１３５は、レセプトを提供することにユーザが同意している場合、取得部１３１から供給されたレセプトを保険会社に送信する。送信制御部１３５は、保険金受け取りレコメンドに対するユーザの応答としての同意があることに基づいて、レセプトを保険会社に送信する送信部として機能する。

【0134】

・PF管理サーバ１の動作
ここで、図１５のフローチャートを参照して、以上のような構成を有するPF管理サーバ１の処理について説明する。

【0135】

ステップＳ１において、取得部１３１は、医療機関の業務用端末１２から送信されてきたレセプトを取得する。

【0136】

ステップＳ２において、読み出し部１３２は、レセプトに含まれる保険加入番号に基づいて、ユーザの加入者管理情報を保険加入者DB２から読み出す。また、読み出し部１３２は、加入者管理情報に含まれる保険IDに基づいて、ユーザが加入する保険の支払い基準に関する情報を保険加入者DB２から読み出す。

【0137】

ステップＳ３において、支払い可否判定部１３３は、レセプトに基づいて推定した病名と、保険金の支払い基準とを比較することによって、保険金の支払い可否判定を行う。

【0138】

ステップＳ４において、支払い可否判定部１３３は、保険金の支払い可能性があるか否かを判定する。

【0139】

保険金の支払い可能性があるとステップＳ４において判定された場合、ステップＳ５において、レコメンド部１３４は、保険金の支払い可能性があることの通知である保険金受け取りレコメンドを、登録されたユーザの送信先に送信する。

【0140】

ステップＳ６において、送信制御部１３５は、保険金の支払い可能性がある旨の通知を、レセプトとともに保険会社に送信する。レセプトについては、ユーザが同意している場合に送信される。

【0141】

その後、PF管理サーバ１の処理は終了となる。保険金の支払い可能性がないとステップＳ４において判定された場合も同様に、適宜、保険金の支払い可能性がない旨の通知がユーザに対して行われた後、処理は終了となる。

【0142】

＜変形例＞
医療保険や生命保険の保険金の支払い可能性についての判定が行われるものとしたが、他の種類の任意保険の保険金の支払い可能性についての判定が保険支払いプラットフォームにおいて行われるようにしてもよい。

【0143】

例えば、火災保険や地震保険の保険金の支払い可能性についての判定が保険支払いプラットフォームにおいて行われるようにすることが可能である。この場合、医療機関において行われる上述した処理と同様の処理が、警察署や、地方公共団体の役所などにおいて行われる。

【0144】

特定の医療機関などの、登録された機関からの情報のみが保険支払いプラットフォームにおいて受け付けられるようにしてもよい。この場合、各機関に対しては機関識別符号が付与される。機関識別符号を用いた認証が、保険加入番号を含むレセプトの送受信の前に保険支払いプラットフォームにおいて行われるようにすることにより、保険者加入番号やレセプトが外部に漏れるリスクを低減することができる。

【0145】

・ブロックチェーンのデータベースを用いた例
保険金の支払い可能性についての判定結果が、保険加入番号、保険IDなどの情報と紐付けて記憶されるようにしてもよい。

【0146】

保険金の支払いに関するやりとりの際に詐欺行為が発生することがあることから、やりとりに関する履歴を正確に残しておく必要がある。また、保険会社側としても、全ての支払い義務に対して対応したかどうかを確認する必要がある。

【0147】

保険金の支払い可能性についての判定結果に関する判定結果情報の記憶先として、ブロックチェーンのデータベースが用いられる。ブロックチェーンのデータベースには、保険金の支払いが完了しているかどうかに関する情報も記憶される。

【0148】

図１６は、判定結果情報の記憶先となるブロックチェーンのデータベースの例を示す図である。

【0149】

図１６に示すように、コンソーシアム型のブロックチェーンネットワーク２０１が、ブロックチェーンのデータベースとして用いられる。ブロックチェーンネットワーク２０１は、複数の参加者が管理する複数のノードによって構成されるP2Pネットワークである。ノードは、サーバ等の装置である。１つのノードが１台の装置により構成されるようにしてもよいし、複数台の装置により構成されるようにしてもよい。

【0150】

ブロックチェーンネットワーク２０１に対しては、PF管理サーバ１と、保険会社のサーバであるサーバ２０２から各種の情報を記憶させることが可能となっている。例えば、サーバ２０２が保険会社毎に用意される。

【0151】

上述したように、PF管理サーバ１は、保険金の支払い可能性があると判定した場合、保険加入番号と保険IDを含む判定結果情報をブロックチェーンネットワーク２０１に記憶させる。保護性が高い個人情報であるため、医療機関から提供されたレセプトについては、ブロックチェーンネットワーク２０１に記憶させないようにすることが好ましい。

【0152】

保険会社は、保険金の支払い可能性があることの通知をPF管理サーバ１から受けた場合、支払い可能性があるか否かの判定を自らも行い、その判定結果を保険支払いプラットフォームに連絡する。保険金の支払い可能性があるか否かの判定結果を保険支払いプラットフォームに連絡した場合、サーバ２０２は、保険金の支払い可能性があると判定した保険に対して、保険金の支払いが完了したか否かを表す情報をブロックチェーンネットワーク２０１に記憶させる。

【0153】

図１７は、PF管理サーバ１によってブロックチェーンネットワーク２０１に記憶されるトランザクションデータの例を示す図である。

【0154】

図１７に示すように、PF管理サーバ１が生成するトランザクションデータには、保険支払いプラットフォームの電子署名、保険支払いプラットフォームの公開鍵、保険支払いプラットフォームのアドレス、送信先アドレス、保険加入番号、保険ID、および、保険金の支払い可能性があることの通知を保険会社に対して行ったか否かを表す情報が含まれる。

【0155】

送信先アドレスは、保険金受け取りレコメンドの送信先として保険支払いプラットフォームが用いた送信先を表す。保険加入番号については、ハッシュ化などにより暗号化されていることが好ましい。

【0156】

例えば、図１７の各情報を含むトランザクションデータがブロックチェーンネットワーク２０１に記憶された場合、そのことを表す情報が、例えば送信制御部１３５により保険会社に送信される。保険会社に送信される情報には保険加入番号が含まれる。

【0157】

図１８は、サーバ２０２によってブロックチェーンネットワーク２０１に記憶されるトランザクションデータの例を示す図である。

【0158】

図１８に示すように、サーバ２０２が生成するトランザクションデータには、保険会社の電子署名、保険会社の公開鍵、保険会社のアドレス、送信先アドレス、保険加入番号、保険ID、および、保険金の支払いが完了したか否かを表す情報が含まれる。

【0159】

送信先アドレスは、保険金の支払い先を表す。保険加入番号については、ハッシュ化などにより暗号化されていることが好ましい。

【0160】

このようなトランザクションデータを書き込むためのトランザクションが、ブロックチェーンネットワーク２０１を構成するブロックに格納される。ブロックには、複数のトランザクションとともに、直前のブロックのハッシュ値が格納される。

【0161】

PF管理サーバ１が生成するトランザクションデータとサーバ２０２が生成するトランザクションデータのいずれのデータにも診療情報が含まれないようにすることにより、ユーザの個人的な情報を保護することが可能となる。

【0162】

・保険支払いプラットフォームにおいて管理する情報の例
保険金の支払いが完了したかどうかを表す情報が、保険会社から保険支払いプラットフォームに対して送信され、保険支払いプラットフォームにおいて蓄積されるようにしてもよい。保険支払いプラットフォームにおいては、保険金の支払いが行われたかどうかを任意のタイミングでユーザが確認できるように、保険会社から送信されてきた情報が管理される。

【0163】

例えば、保険支払いプラットフォームにアクセスすることにより、自分がどの保険に入っているか、どの保険の保険金がどのタイミングで支払われているか、月々の保険料がいくらかなどの情報をユーザが閲覧できるようにしてもよい。また、これらの情報がマイナンバーに紐付けられ、ユーザの同意のもと、マイナポータルに掲載されるようにしてもよい。

【0164】

・保険支払いプラットフォームにおける判定の例
保険金の支払い可能性があるか否かの判定が行われるものとしたが、保険金の支払い可能性があるか否かだけでなく、保険金の金額などの、支払いの内容の判定までが支払い可否判定部１３３により行われるようにしてもよい。金銭以外の授受を補償する保険については、補償内容が支払い可否判定部１３３により判定されるようにしてもよい。

【0165】

保険金の支払い可能性があると判定された場合、レコメンド部１３４は、保険金の支払い可能性があることの通知とともに、支払いの内容を表す情報をユーザと保険会社のうちの少なくともいずれかに送信することになる。

【0166】

保険金の支払い可能性があるか否かの判定以外の判定が、保険支払いプラットフォームにおいて行われるようにしてもよい。

【0167】

例えば、保険加入者であるユーザが、保険の告知義務を果たしているかどうかの判定が保険支払いプラットフォームにおいて行われるようにしてもよい。保険の告知義務を果たしているか否かの判定は、例えば、マイナポータルから取得された過去の健康診断の結果と、ユーザが過去に受けた診療の内容を表す診療情報のうちの少なくともいずれかに基づいて行われる。

【0168】

保険の告知義務を果たしているか否かの判定は、ユーザが保険の加入を保険会社に申し込む際や、保険金の支払い可否判定の際などの、所定のタイミングで行われる。保険の告知義務を果たしているか否かの判定が、ユーザの同意と保険会社の申請の元に行われるようにしてもよい。

【0169】

保険金の支払い可否判定を含む各種の判定が、機械学習によって生成された推論モデルを用いて行われるようにしてもよい。

【0170】

図１９は、支払い可否判定部１３３に設けられる推論モデルの例を示す図である。

【0171】

図１９に示すように、支払い可否判定部１３３には、保険金の支払い可否判定に用いられる支払い可否判定モデル１３３Ａが設けられる。支払い可否判定モデル１３３Ａは、遺伝アルゴリズムに基づく機械学習によって生成された、ニューラルネットワークなどにより構成される推論モデルである。例えば、レセプト、保険の種類、および、保険金の支払い可能性の判定結果を紐付けた学習データ群に基づく機械学習が行われることによって、支払い可否判定モデル１３３Ａが生成される。なお、レセプトは診療内容を示す他の診療情報であってもよい。

【0172】

支払い可否判定モデル１３３Ａに対しては、レセプトと保険の種類が入力され、保険金の支払い可能性があるか否かの判定結果が出力される。支払い可否判定モデル１３３Ａを用いることにより、レセプトと保険の種類に基づいて、保険金の支払い可能性があるか否かの判定が可能となる。

【0173】

同一の医療機関から送信されてきた複数のレセプトに基づいて、レセプトの正当性の解析が支払い可否判定部１３３により行われるようにしてもよい。この場合、複数のレセプトの統計解析が行われ、レセプトが正当であるか否かが解析結果として出力される。

【0174】

例えば、特定の医療機関から送信されてきたレセプトの中に、類似のレセプトが他の医療機関から送られてくるレセプトに比べて統計的に多いと判定された場合、詐欺行為の可能性があると判定され、保険支払いプラットフォームの管理者に対してアラートが出力される。

【0175】

このように、同一の医療機関から送信されてきた複数のレセプトの統計解析を行う解析部としての機能を支払い可否判定部１３３に持たせることも可能である。

【0176】

それぞれの医療機関の診断・治療行為の妥当性が、複数のレセプトに基づいて統計的に判定されるようにしてもよい。例えば、他の医療機関に比べて、過剰なまたは過小な診断や治療を行っている可能性があるか否かに基づいて、妥当性が判定される。これにより、保険会社は、より適切な診断・治療行為を行っている医療機関を調査し、適切な医療機関を保険加入者に薦めることが可能となる。

【0177】

・健康保険証を提出せずに診療を受けた場合または自由診療の場合
健康保険証を提出せずに診療を受けた場合または自由診療の場合は、医療機関が診療内容を入力した診療情報が紐づく案内状を発行し、ユーザに案内状を送付してもよい。案内状は、保険支払いプラットフォームに診療情報を提出するためのフォーマットであり、例えばメールやオンライン回答フォームである。例えば、ユーザが医療機関で自由診療を受けた場合は、医療機関は保険支払いプラットフォームにアクセスして、所定フォーマットにしたがって自由診療の診療内容を入力する。保険支払いプラットフォームは、入力された診療内容に基づいて診療情報とオンライン回答フォームを生成し、一時的に生成されたIDに診療情報と案内状を紐づける。医療機関は、ユーザにオンライン回答フォームのＵＲＬまたはオンライン回答フォームにアクセスするためのコード（例えばＱＲコード）を送付する。ユーザは、オンライン回答フォームにアクセスしてマイナンバーを入力して提出する。なお、マイナンバーを入力する形式ではなく、ユーザIDとパスワードを入力してユーザ認証を行う形式でもよい。保険支払いプラットフォームは、入力されたマイナンバーまたはユーザIDに診療情報を紐づけて記憶し、上述の保険支払い可能性の判定やレコメンドの処理を実行する。これにより、ユーザは健康保険証を提出せずに診療を受けた場合や自由診療の場合であっても、保険金の支払い可能性があることを容易に知ることができる。

【0178】

・プログラムについて
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、汎用のパーソナルコンピュータなどにインストールされる。

【0179】

インストールされるプログラムは、光ディスク（CD-ROM(Compact Disc-Read Only Memory)，DVD(Digital Versatile Disc)等）や半導体メモリなどよりなる図１３に示されるリムーバブルメディア１１１に記録して提供される。また、ローカルエリアネットワーク、インターネット、デジタル放送といった、有線または無線の伝送媒体を介して提供されるようにしてもよい。プログラムは、ROM１０２や記憶部１０８に、あらかじめインストールしておくことができる。

【0180】

コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。

【0181】

本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。

【0182】

なお、本明細書に記載された効果はあくまで例示であって限定されるものでは無く、また他の効果があってもよい。

【0183】

本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

【0184】

例えば、本技術は、１つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。

【0185】

また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。

【0186】

さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。

【0187】

・構成の組み合わせ例
本技術は、以下のような構成をとることもできる。

【0188】

（１）
被保険者のマイナンバーに紐付けられた識別情報と、前記被保険者が受けた処置の内容を表す診療情報とを取得する取得部と、
前記識別情報に紐付けられた１以上の保険加入番号に基づいて、前記被保険者が加入する保険の支払い基準に関する情報を読み出す読み出し部と、
保険金の支払い可能性があるか否かを、前記診療情報と前記支払い基準とに基づいて判定する判定部と、
保険金の支払い可能性があると判定された場合、前記識別情報に紐付けられた第１の送信先に対して、保険金の支払い可能性があることの通知を送信するレコメンド部と
を備える保険支払いシステム。
（２）
前記診療情報が表す処置の内容には、健康保険の適用対象となる診療の内容、調剤の内容、および、看護の内容のうちの少なくともいずれかが含まれる
前記（１）に記載の保険支払いシステム。
（３）
前記レコメンド部は、保険金の支払い可能性がないと判定された場合、保険金の支払い可能性がないことの通知を前記第１の送信先に送信する
前記（１）または（２）に記載の保険支払いシステム。
（４）
保険金の支払い可能性があることの通知に対する前記被保険者による応答に基づいて、前記識別情報に紐付けられた第２の送信先に前記診療情報を送信する送信部をさらに備える
前記（１）乃至（３）のいずれかに記載の保険支払いシステム。
（５）
前記送信部は、保険金の支払い可能性があるか否かの判定結果と前記保険加入番号とを含むデータがブロックチェーンデータベースに記憶された場合、前記保険加入番号を含む情報を前記第２の送信先に送信する
前記（４）に記載の保険支払いシステム。
（６）
前記判定部は、保険金の支払い可能性があると判定された保険に関する支払いの内容をさらに判定し、
前記レコメンド部は、支払い内容の通知を被保険者または保険会社に送信する
前記（１）乃至（５）のいずれかに記載の保険支払いシステム。
（７）
前記判定部は、前記被保険者の過去の検診結果と、前記被保険者が過去に受けた診療の内容を表す他の診療情報とのうちの少なくともいずれかに基づいて、保険の告知義務を前記被保険者が果たしているか否かを判定する
前記（１）乃至（６）のいずれかに記載の保険支払いシステム。
（８）
前記判定部は、保険金の支払い可能性があるか否かを、機械学習によって生成された推論モデルを用いて判定する
前記（１）乃至（７）のいずれかに記載の保険支払いシステム。
（９）
同一の医療機関が発行する複数の診療情報に基づいて統計解析を行い、内容の正当性の解析結果を出力する解析部をさらに備える
前記（１）乃至（８）のいずれかに記載の保険支払いシステム。
（１０）
保険支払いシステムを管理する情報処理装置が、
被保険者のマイナンバーに紐付けられた識別情報と、前記被保険者が受けた処置の内容を表す診療情報とを取得し、
前記識別情報に紐付けられた１以上の保険加入番号に基づいて、前記被保険者が加入する保険の支払い基準に関する情報を読み出し、
保険金の支払い可能性があるか否かを、前記診療情報と前記支払い基準とに基づいて判定し、
保険金の支払い可能性があると判定した場合、前記識別情報に紐付けられた送信先に対して、保険金の支払い可能性があることの通知を送信する
情報処理方法。
（１１）
コンピュータに、
被保険者のマイナンバーに紐付けられた識別情報と、前記被保険者が受けた処置の内容を表す診療情報とを取得し、
前記識別情報に紐付けられた１以上の保険加入番号に基づいて、前記被保険者が加入する保険の支払い基準に関する情報を読み出し、
保険金の支払い可能性があるか否かを、前記診療情報と前記支払い基準とに基づいて判定し、
保険金の支払い可能性があると判定した場合、前記識別情報に紐付けられた送信先に対して、保険金の支払い可能性があることの通知を送信する
処理を実行させるためのプログラム。

【符号の説明】

【0189】

１ PF管理サーバ， ２ 保険加入者DB， １１ カードリーダ， １２ 業務用端末， １３ オンライン資格確認システム， １４ 中間サーバ， １２１ 情報処理部， １３１ 取得部， １３２ 読み出し部， １３３ 支払い可否判定部， １３４ レコメンド部， １３５ 送信制御部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】