JPWO2018163265A1 - 保険金請求支援システムおよび保険金請求支援方法 - Google Patents

Abstract

【課題】種々のチャネルからの情報を適宜に処理し、効率的で的確な保険金支払請求の支援を可能とする。【解決手段】保険金請求支援システム１００において、ネットワーク上の１または複数の所定装置と通信する通信装置１０５と、所定保険の被保険者に関する診療情報を、前記所定装置より受信して記憶装置１０１に格納し、前記格納した診療情報のうち所定属性のものを、所定アルゴリズムで選択する処理と、前記選択した診療情報を、前記保険の契約者が保険契約を結んでいる保険会社の情報処理装置３００に送信する処理と、を実行する演算装置１０４を含む構成とする。

Description

本発明は、保険金請求支援システムおよび保険金請求支援方法に関する。

年を追う毎に我が国の医療費は増大しており、将来的に公的保険制度の見直しも予想される。そうした状況下における各個人や団体は、民間の医療保険等を利用して、公的保険の対象外となる医療費を適宜にカバーする動きを強めている。

一方、上述の医療保険等の各契約者は、当該保険の契約内容を正確に把握しているとは言い難い。そのため契約者は、保険金支払事由に該当するインシデントが発生しても、それが保険金支払請求の契機であるかすら意識せず、保険金の支払請求漏れが容易に起こりうる状態にある。或いは、その契約者が契約内容を認識していても、保険会社への連絡等の各種手続を面倒に感じ、自らの意思で支払請求を怠るケースも存在する。

勿論、保険会社の側でも、保険金の支払漏れをなくす取り組みを進めているが、上述のインシデントの発生は契約者本人の申告によって認識しうるものであり、対策に限界がある。

そこで、そうした問題に対処する従来技術として、例えば、健康保険組合のサーバから受診者情報、医療機関情報、診療・治療内容の情報を含む診療記録情報を受信するステップと、受信した診療記録情報が当該受診者を対象とする医療保険の契約内容と適合するか否かを判定するステップと、前記判定において適合すると判定されたとき、医療保険契約に基づく医療給付金支払いのための手続きに移行することを特徴とする医療給付金支払サービス方法（特許文献１参照）などが提案されている。

特開２００５−１００１６５号公報

従来技術が示すように、診療記録情報に基づいて支払手続を適宜に進めることは有用である。ところが、保険金の支払請求の可否を判断しうる情報としては、診療記録情報の他にも様々な種類のものが存在する。例えば、健康保険組合から定期的に送付されてくる医療費通知、病院で作成されたレセプトや電子カルテ等のデータ、或いは、契約者或いは被保険者らが病院や薬局で受け取ったレシート、など複数ある。しかもこれらの情報は、その詳細さや所定項目の有無が、情報間で異なっているケースが多い上、提供時期も異なっている。

従って、契約者らの都合や置かれた状況により、或いは、病院や健康保険組合等における情報管理ポリシーなどによって、上述した支払請求の可否判断に用いられる情報がまちまちになる。また、上述の診療記録情報も含めた各種情報は、被保険者全体では膨大なデータ量となりがちである。

そのため、一人の被保険者の１回の受診行為に関してさえ複数の情報が集まりうる情報を、膨大な人数分収集し、それをそのまま支払請求の可否判断ロジックに提供するとすれば、全体として処理の速度や精度が大きく低下し、効率的で的確な支払請求の手続自体が困難となる恐れがある。

そこで本発明の目的は、種々のチャネルからの情報を適宜に処理し、効率的で的確な保険金支払請求の支援を可能とする技術を提供することにある。

上記課題を解決する本発明の保険金請求支援システムは、ネットワーク上の１または複数の所定装置と通信する通信装置と、所定保険の被保険者に関する診療情報を、前記所定装置より受信して記憶装置に格納し、前記格納した診療情報のうち所定属性のものを、所定アルゴリズムで選択する処理と、前記選択した診療情報を、前記保険の契約者が保険契約を結んでいる保険会社の情報処理装置に送信する処理と、を実行する演算装置と、を含むことを特徴とする。

また、本発明の保険金請求支援方法は、ネットワーク上の１または複数の所定装置と通信する通信装置を備えた情報処理システムが、所定保険の被保険者に関する診療情報を、前記所定装置より受信して記憶装置に格納し、前記格納した診療情報のうち所定属性のものを、所定アルゴリズムで選択する処理と、前記選択した診療情報を、前記保険の契約者が保険契約を結んでいる保険会社の情報処理装置に送信する処理と、を実行することを特徴とする。

本発明によれば、種々のチャネルからの情報を適宜に処理し、効率的で的確な保険金支払請求の支援が可能となる。

本実施形態における保険金請求支援システムを含むネットワーク構成図である。 本実施形態における保険金請求支援システムのハードウェア構成例を示す図である。 本実施形態におけるフィルタリングマスタテーブルの構成例を示す図である。 本実施形態における支払フィルタテーブルの構成例を示す図である。 本実施形態における除外フィルタテーブルの構成例を示す図である。 本実施形態におけるユーザマスタテーブルの構成例を示す図である。 本実施形態における契約内容マスタテーブルの構成例を示す図である。 本実施形態における被保険者マスタテーブルの構成例を示す図である。 本実施形態における診療履歴テーブルの構成例を示す図である。 本実施形態における保険金請求支援方法のフロー例１を示す図である。 本実施形態における保険金請求支援方法のフロー例２を示す図である。 本実施形態における保険金請求支援方法のフロー例３を示す図である。 本実施形態における画面例１を示す図である。 本実施形態における画面例２を示す図である。 本実施形態における画面例３を示す図である。 本実施形態における画面例４を示す図である。 本実施形態における画面例５を示す図である。 本実施形態における画面例６を示す図である。

−−−ネットワーク構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は本実施形態の保険金請求支援システム１００を含むネットワーク構成例を示す図である。図１に示す保険金請求支援システム１００は、種々のチャネルからの情報を適宜に処理し、効率的で的確な保険金支払請求の支援を可能とするためのコンピュータシステムである。

こうした保険金請求支援システム１００はネットワーク１０に接続され、ユーザ端末２００、保険会社システム３００、健保システム４００、および、病院システム５００とデータ通信可能となっている。

このうちユーザ端末２００は、保険会社の医療保険（死亡保障を契約内容に含む各種保険の概念含む）について契約している保険契約者の端末である。このユーザ端末２００としては、具体的には、スマートフォン、通信機能を備えたタブレット端末やＰＣ等を想定出来るが、これらに限定しない。

また、保険会社システム３００は、上述の保険会社が運用するシステムであり、保険金請求支援システム１００から送信されてくる診療情報に基づき、当該診療情報に関する保険金支払請求を承認するか判断し（担当者による判断結果を取得する概念も含む）、その判断結果を保険金請求支援システム１００に返す装置である。この保険会社システム３００としては、具体的には、サーバ装置を想定出来るが、これに限定しない。

また、健保システム４００は、上述の保険契約者や被保険者が所属する健康保険組合のシステムであり、レセプトなどの診療情報を保険金請求支援システム１００に提供するコンピュータシステムである。この健保システム４００としては、具体的には、サーバ装置を想定出来るが、これに限定しない。

また、病院システム５００は、上述の被保険者が診療行為を受ける医療機関のシステムであり、レセプトや電子カルテ等の診療情報を保険金請求支援システム１００に提供するコンピュータシステムである。この病院システム５００としては、具体的には、サーバ装置を想定出来るが、これに限定しない。

−−−ハードウェア構成例−−−
また、保険金請求支援システム１００のハードウェア構成は以下の如くとなる。保険金請求支援システム１００は、ハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行しシステム自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１０４、ネットワーク１０と接続し、ユーザ端末２００、保険会社システム３００、健保システム４００、および病院システム５００といった他装置との通信処理を担う通信装置１０５を備える。

なお、上述の記憶装置１０１には、プログラム２０２の他、フィルタリングマスタテーブル１２５、支払フィルタテーブル１２６、除外フィルタテーブル１２７、ユーザマスタテーブル１２８、契約内容マスタテーブル１２９、被保険者マスタテーブル１３０、および、診療履歴テーブル１３１が格納されている。これら各テーブルの詳細については後述する。

−−−データ構成例−−−
続いて、本実施形態の保険金請求支援システム１００が用いるテーブル類について説明する。図３に、本実施形態におけるフィルタリングマスタテーブル１２５の一例を示す。 このフィルタリングマスタテーブル１２５は、各保険会社の保険商品ごとに、診療情報のフィルタリング方法を規定したテーブルである。このフィルタリング方法とは、保険金請求支援システム１００が、記憶装置１０１に蓄積している所定期間分の診療情報の中から、保険金支払請求の承認判断を求めるべく保険会社システム３００に送信する対象を選択する方法に該当する。

そのデータ構造は、保険すなわち保険商品を一意に特定する保険商品ＩＤをキーとして、当該保険商品を販売している保険会社、当該保険商品の商品名・特約名、および、フィルタ方式といったデータから成るレコードの集合体である。このうち、フィルタ方式の具体例としては、ホワイトリスト方式とブラックリスト方式とを想定する。

ホワイトリスト方式は、保険会社が各保険商品に関して規定している保険金支払事由の情報に照合し、当該保険金支払事由に該当する傷病ないし診療行為の情報を含む診療情報を選択する方式である。このホワイトリスト方式の詳細な内容は、後述する支払フィルタテーブル１２６にて規定されている。

一方、ブラックリスト方式は、保険会社が各保険商品に関して規定している保険金支払事由に該当しない傷病ないし診療行為の情報に照合し、当該保険金支払事由に該当しない傷病ないし診療行為の情報を含まない診療情報を選択する方式である。このブラックリスト方式の詳細な内容は、除外フィルタテーブル１２７にて規定されている。

図４Ａは、本実施形態における支払フィルタテーブル１２６の構成例を示す図である。この支払フィルタテーブル１２６は、上述のホワイトリスト方式が規定された保険商品の保険金支払事由を格納したテーブルである。

そのデータ構造は、保険商品を一意に特定する保険商品ＩＤをキーとして、当該保険商品を販売する保険会社、当該保険商品の商品名・特約名、および支払事由、といったデータから成るレコードの集合体である。

図４Ｂは、本実施形態における除外フィルタテーブル１２７の構成例を示す図である。この除外フィルタテーブル１２７は、上述のブラックリスト方式が規定された保険商品の保険金の支払除外事由を格納したテーブルである。

そのデータ構造は、保険商品を一意に特定する保険商品ＩＤをキーとして、当該保険商品を販売する保険会社、当該保険商品の商品名・特約名、および支払の除外事由、といったデータから成るレコードの集合体である。

図５Ａは、本実施形態におけるユーザマスタテーブル１２８の構成例を示す図である。このユーザマスタテーブル１２８は、保険契約者の情報を格納したテーブルである。そのデータ構造は、保険契約者すなわち保険商品の契約者を一意に特定する契約者ＩＤをキーとして、契約者氏名、当該保険商品の証券番号といったデータから成るレコードの集合体である。なお、一人の保険契約者が複数の保険商品について契約を有する場合もあるため、１レコードにおいて複数の証券番号が含まれうる。

図５Ｂは、本実施形態における契約内容マスタテーブル１２９の構成例を示す図である。この契約内容マスタテーブル１２９は、上述のユーザマスタテーブル１２５に格納されている証券番号に対応する契約内容を格納したテーブルである。

そのデータ構造は、上述のユーザマスタテーブル１２５に格納されている証券番号をキーとして、該当保険商品の保険商品ＩＤ、被保険者を一意に特定する被保険者ＩＤ、および、保険金の受取人、といったデータから成るレコードの集合体である。

図５Ｃは、本実施形態における被保険者マスタテーブル１３０の構成例を示す図である。この被保険者マスタテーブル１３０は、上述の契約内容マスタテーブル１２９にＩＤが格納されている被保険者に関する情報を格納したテーブルである。

そのデータ構造は、上述の契約内容マスタテーブル１２９に格納されている被保険者ＩＤをキーとして、被保険者の氏名、および、健康保険証番号、といったデータから成るレコードの集合体である。

図６は、本実施形態における診療履歴テーブル１３１の構成例を示す図である。この診療履歴テーブル１３１は、ユーザ端末２００，健保システム４００、および、病院システム５００といった各チャネルから送信されてきた診療情報を格納したテーブルである。

そのデータ構造は、診療情報が含む、被保険者の健康保険証番号をキーに、氏名、当該被保険者が診療を受けた日時、検知区分（診療情報を受信したチャネルの種類）、診療を行った医療機関名、診療対象の傷病名、診療区分（通院／入院）、診療費の窓口支払額、保険外診療フラグ、診断未確定フラグ、フィルタ処理フラグ、および、重複削除フラグ、といったデータから成るレコードの集合体である。

このうち、保険外診療フラグは、診療情報のうち、保険外診療に関する診療情報に付与するフラグである。

また、診断未確定フラグは、診療情報のうち、確定していない診断内容に関する診療情報に付与するフラグに該当する。この診断未確定フラグが付与されている診療情報については、保険会社システム３００への送信対象から除外することとなる。

また、フィルタ処理フラグは、診療情報（診療履歴テーブルのレコード）のうち、当該診療情報の示す被保険者が契約内容に規定された全ての保険商品（契約内容マスタテーブル１２９に情報が格納されている）に関して、後述する支払請求の可否判定（図７Ａ：ｓ１１１）が完了しているものに対し付与されるフラグである。

一方、重複削除フラグは、診療情報（診療履歴テーブルのレコード）のうち、同一の被保険者（すなわち健康保険証番号が同一）の同一の診療機会（すなわち、診療日時、医療機関名、傷病名、および診療区分が同一）に関する診療情報が複数存在、すなわち重複している場合、重複している複数の診療情報のうち、所定の優先順位に従って選択した１つの診療情報以外の診療情報に付与される。

上述の優先順位の例としては、検知区分が「レセプト」＞「病院直」（電子カルテデータ等）＞手動（保険契約者がユーザ端末２００から手動入力）、といった順を想定出来るが、勿論、これに限定しない。

−−−フロー例−−−
以下、本実施形態における保険金請求支援方法の実際手順について図に基づき説明する。以下で説明する保険金請求支援方法に対応する各種動作は、保険金請求支援システム１００がメモリ１０３に読み出して実行するプログラムによって実現される。そして、これらのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

図７Ａは、本実施形態における保険金請求支援方法のフロー例１を示す図である。まず、保険金請求支援システム１００は、事前処理として、保険会社システム３００など保険会社の適宜な情報処理装置（以降、保険会社システム３００とする）から、保険商品に関する支払事由の登録を受け付ける（ｓ１００）。

なお、この支払事由の登録受付に際し、図7Ｂの詳細フローで示すように、保険金請求支援システム１００は、例えば、各保険商品の被保険者の診療情報をどのような方針でフィルタリングするべきか、について保険会社に問う画面等のインターフェイスを、例えば、保険会社システム３００に送信する（ｓ１００１）。

上述のインターフェイスは、例えば、ホワイトリスト方式かブラックリスト方式かを保険会社に問う画面となる。保険会社が或る保険商品に係わる診療情報に関して希望するフィルタリングの方式が、ホワイトリスト方式の場合、当該保険商品に関して、支払フィルタテーブル１２６が必要となる。他方、保険会社が或る保険商品の診療情報に関して希望するフィルタリングの方式が、ブラックリスト方式の場合、当該保険商品に関して、除外フィルタテーブル１２７が必要となる。

上述の保険会社の担当者等は、保険会社システム３００にて上述の画面等を確認し、自社の各保険商品に係わる診療情報に関して適用したいフィルタリングの方式を選択する。この時、保険会社システム３００は、当該選択の値を取得して保険金請求支援システム１００に返信する。

保険金請求支援システム１００は、保険会社システム３００から上述のフィルタリングの方式の値を受信し（ｓ１００２）、これを、該当保険商品および保険会社と紐付けたレコードを生成し、フィルタリングマスタテーブル１２５に格納する（ｓ１００３）。

次に、保険金請求支援システム１００は、保険会社システム３００からの返信が示すフィルタリングの方式に関する情報を取得する（ｓ１００４）。

上述で得たフィルタリングの方式に関する情報が、ホワイトリスト方式を示すものであった場合（ｓ１００５：ｗ）、保険金請求支援システム１００は、保険会社システム３００に対し、保険金の支払事由の登録受付画面を送信し、当該保険会社システム３００から支払事由データを受信する（ｓ１００６）。保険金請求支援システム１００は、受信した支払事由データを、該当保険商品と紐付けてレコードを生成し、これを支払フィルタテーブル１２６に格納する（ｓ１００７）。

他方、上述で得たフィルタリングの方式に関する情報が、ブラックリスト方式を示すものであった場合（ｓ１００５：ｂ）、保険金請求支援システム１００は、保険会社システム３００に対し、保険金の支払対象とならない傷病名等の事由データ、すなわち除外事由データの登録受付画面を送信し、当該保険会社システム３００から除外事由データを受信する（ｓ１００８）。保険金請求支援システム１００は、受信した除外事由データを、該当保険商品と紐付けてレコードを生成し、これを除外フィルタテーブル１２７に格納する（ｓ１００９）。

ここで図７Ａのメインフローの説明に戻る。保険金請求支援システム１００は、上述のステップｓ１００に続いて、保険金の支払請求支援を受けたいユーザ、すなわち保険契約者からのユーザ登録を受け付ける（ｓ１０１）。

この場合の保険契約者は、上述のユーザ登録に際して、保険金請求支援システム１００から所定アプリをユーザ端末２００にダウンロードおよびインストールしている（勿論、この形態に限定しない）。保険契約者は、このアプリのインターフェイス上で、自身の氏名、契約中の保険会社および保険商品、その証券番号、被保険者名、健康保険証番号といった情報を入力することとなる。情報入力を受けたアプリは、ユーザ端末２００およびネットワーク１０を介し、入力情報を保険金請求支援システム１００にアップロードする。 続いて、保険金請求支援システム１００は、ｓ１０１で受け付けたユーザ登録の内容について不備等の問題有無を判定する（ｓ１０２）。

この判定の結果、例えば所定項目の入力漏れが特定されたり、或いは、保険契約者が入力した証券番号は存在しないものであることが（保険会社システム３００に問い合わせて）判明するといった結果となった場合（ｓ１０３：ｎ）、保険金請求支援システム１００は、ユーザ登録不可である旨を該当ユーザのユーザ端末２００に通知し（ｓ１０４）、一旦処理を終了する。

他方、上述の判定の結果、問題が特定されなかった場合（ｓ１０３：ｙ）、保険金請求支援システム１００は、ｓ１０１で受け付けたユーザ登録の内容が含む各項目の値を適宜に抽出し、ユーザマスタテーブル１２８、契約内容マスタテーブル１２９、および被保険者マスタテーブル１３０の各レコードを生成し、登録する（ｓ１０５）。

その後、保険金請求支援システム１００は、上述のユーザ登録がなされた保険契約者の被保険者に関して、その診療情報を、各チャネルに対応する、ユーザ端末２００、健保システム４００、および病院システム５００の少なくともいずれかから受信し、これを記憶装置１０１の診療履歴テーブル１３１に格納する（ｓ１０６）。なお、保険契約者と被保険者が同一である場合と、保険契約者と被保険者が異なる場合の両方ありうる。

ここで取得して登録する診療情報としては、健保から保険契約者ごとに毎月配信される医療費通知、健保ないし支払基金からデータ連携されたレセプト、医療機関からデータ連携された電子カルテやレセコン、および、被保険者が診療機会ごとに医療機関から得たレシート情報、といったものが例として想定出来る。

なお、上述の診療情報のうち、レシート情報に関しては、医療機関で被保険者が受け取ったレシートを得た保険契約者がユーザ端末２００を操作して手動入力してきたものを取得するケースか、或いは、ユーザ端末２００のカメラ機能およびＯＣＲアプリ等を適宜利用してスキャンしたものを取得するケースの両方が想定出来る。

このように、保険契約者がユーザ端末２００を操作して診療情報を保険金請求支援システム１００に登録することを望む場合がある。その場合、ユーザ端末２００からの所定リクエストを受けた保険金請求支援システム１００は、図８Ａまたは図８Ｂに例示する入力画面１０００、１０１０を、当該保険契約者のユーザ端末２００に返す。

保険契約者は、例えば病院等の医療機関から発行された上述のレシートを参考にしつつ、いずれかの入力画面１０００、１０１０において、診療情報の入力動作を行うことになる。当該保険契約者が入力画面１０００を利用する場合、上述のレシートをユーザ端末２００のカメラで撮影し、適宜なＯＣＲアプリによって、診療情報の読み取りを実行する。その結果、ユーザ端末２００は、診療日時、医療機関名、といった値を診療情報として取得し、これを保険金請求支援システム１００に送信することとなる。

一方、上述の保険契約者が入力画面１０１０を利用する場合、上述のレシートを参照しつつ、診療情報の手入力あるいは選択動作を実行する。その結果、ユーザ端末２００は、診療日時、診療区分、傷病名、といった値を診療情報として取得し、これを保険金請求支援システム１００に送信することとなる。

また、上述の診療情報のうち、医療費通知に関しては、健保システム４００からデータ連携を受けて、電子データとして取得出来るケースと、医療費通知の内容を閲覧した保険契約者がユーザ端末２００を操作して手動入力してきたものを取得するケースの両方が想定出来る。

また、上述のように診療情報が医療費通知である場合、それには傷病名のデータが含まれていない。よって、保険金請求支援システム１００は、この医療費通知に基づく診療情報を特定し、当該診療情報に関して傷病名の入力を受け付ける所定インターフェイス（図８Ｃの画面１０２０）を、該当保険契約者のユーザ端末２００に送信して傷病名の情報入力を受け付ける。この場合の保険金請求支援システム１００は、当該受け付けた傷病名の情報を、上述の診療情報における傷病名欄に設定することとなる。

一方、上述の診療情報のうちレセプトや電子カルテやレセコンのデータは、詳細な情報が含まれており、不足データを補う措置等は基本的に不要である。ただし、レセプトに関しては、いわゆる「レセプト病名」、「疑い病名」といった、診断が未確定の傷病等に関する記載を含む場合に所定の処理が必要となる。

この場合、保険金請求支援システム１００は、該当診療情報に対して診断未確定フラグ「１」を付与するものとする。この診断未確定フラグが付与された診療情報は、後述するｓ１１１での保険会社システム３００への送信対象から除外、すなわち保険金支払可否の承認判断の対象外とすることができる。

続いて、保険金請求支援システム１００は、ステップｓ１０６で診療履歴テーブル１３１に格納した診療情報のうち、所定属性のものを選択する事前フィルタリング処理を行う（ｓ１０７）。

この場合の保険金請求支援システム１００は、このフィルタリング処理に際し、図７Ｃのフローのごとく、診療履歴テーブル１３１の各レコードすなわち診療情報のうち、同一の被保険者（同一の健康保険証番号の者）の同一の診療機会（診療日時、医療機関名、傷病名、診察区分が同一）に関する診療情報が複数存在する場合、当該複数の診療情報から１つの診療情報を、種類の異なる診療情報の間について予め定めた優先順位に基づき選択する（ｓ１０７１）。

具体的な優先順位の例としては、診療情報の「検知区分」の値が「レセプト」＞「病院直」（電子カルテデータ等）＞手動（保険契約者がユーザ端末２００から手動入力）、といった順を想定出来るが、勿論、これに限定しない。

保険金請求支援システム１００は、このｓ１０７１で選択した、診療履歴テーブル１３１の１つの診療情報以外のもの、すなわち、ｓ１０７１で選択されなかった診療情報に対して、重複削除フラグ「１」を付与する（ｓ１０７２）。

また、保険金請求支援システム１００は、上述のｓ１０７１で選択した診療情報のうち、保険外診療に関する診療情報が存在する場合、当該診療情報に保険外診療フラグ「１」を付与する（ｓ１０７４）。

ここで図７Ａのフローの説明に戻る。保険金請求支援システム１００は、上述の事前フィルタリング（ｓ１０７）で選択され、重複削除フラグが付与されていない診療情報であり、かつ、診断未確定フラグが付与されていない診療情報から、健康保険証番号、傷病名、および、診察区分の各値を抽出する（ｓ１０８）。

次に保険金請求支援システム１００は、ｓ１０８で得た値のうち、例えば健康保険証番号を、被保険者マスタテーブル１３０に照合して被保険者ＩＤを特定し、この被保険者ＩＤをキーに契約内容マスタテーブル１２９にて保険商品ＩＤを特定する（ｓ１０９）。なお、ここで特定出来る保険商品ＩＤは、該当被保険者ＩＤが契約内容マスタテーブル１２９の「被保険者ＩＤ」欄に規定されたレコード数に応じたものとなり、１つの場合も複数の場合もある。

また、保険金請求支援システム１００は、ｓ１０９で特定した１または複数の保険商品ＩＤのうち所定の１つ（例：最初に特定したもの）をキーにフィルタリングマスタテーブル１２５で該当保険商品のフィルタ方式を特定する（ｓ１１０）。

続いて、保険金請求支援システム１００は、ｓ１１０で特定した保険商品およびフィルタ方式に基づいて、支払フィルタテーブル１２６または除外フィルタテーブル１２７から支払事由または除外事由の情報を取得し、これに基づき、該当診療情報に関して、（保険会社に対する）支払請求の可否を判定する（ｓ１１１）。なお、保険金請求支援システム１００は、上述のｓ１１０およびｓ１１１の各処理を、ｓ１０９で特定できた保険商品ＩＤの数だけ、すなわち該当被保険者に適用される保険契約の数だけ実行し（ｓ１１２：ｎ→ｓ１１０→ｓ１１２→ｓ１１２：ｙ）、各保険契約の全てに関してｓ１１０、ｓ１１１の処理を実行済みとなった当該診療情報に関して、フィルタ処理フラグを診療履歴テーブル１３１に設定する。

一方、ｓ１１１における保険金請求支援システム１００は、支払フィルタテーブル１２６を利用する場合、該当診療情報に関してｓ１０８で得ている各値を、支払フィルタテーブル１２６の該当保険商品に関する支払事由の情報に照合し、当該支払事由に該当する傷病ないし診療行為に対応しているか否か判定する。

他方、保険金請求支援システム１００は、除外フィルタテーブル１２７を利用する場合、該当診療情報に関してｓ１０８で得ている各値を、除外フィルタテーブル１２７の該当保険商品に関する除外事由の情報に照合し、当該除外事由に該当する診療情報であるか否か判定する。

上述のｓ１１１における判定の結果、該当診療情報は保険金の支払請求不可と判明した場合（ｓ１１３：ｎ）、保険金請求支援システム１００は、該当診療情報は保険金の支払請求対象となりえない旨を示す棄却レポートを、当該保険契約者のユーザ端末２００に返し（ｓ１１４）、処理を終了する。

他方、該当診療情報は保険金の支払請求可能と判明した場合（ｓ１１３：ｙ）、保険金請求支援システム１００は、該当診療情報に関して保険金の支払請求が可能であり、実際に支払請求を行うか否かを問う通知（図９の画面１０３０参照）を、当該保険契約者のユーザ端末２００に宛てて送信する（ｓ１１５）。

なお、保険金請求支援システム１００は、上述のｓ１１５での通知の送信に際し、契約内容マスタテーブル１２９にて該当保険契約のレコードが示す、保険金受取人または被保険者の少なくともいずれかの端末に該当通知を送信するとしてもよい。

上述の通知の送信後、当該ユーザ端末２００から支払請求の実施不要との返信を受けた場合（ｓ１１６：ｎ）、保険金請求支援システム１００は処理を終了する。一方、当該ユーザ端末２００から支払請求の実施要との返信を受けた場合（ｓ１１６：ｙ）、保険金請求支援システム１００は、該当診療情報を含む支払請求の承認要求を、該当保険商品を販売する保険会社の保険会社システム３００に送信する（ｓ１１７）。

保険会社では、保険会社システム３００で受けた上述の承認要求に関して、所定の担当者等或いは所定の業務システムが判定処理を実行し、保険金支払いの可否を判断することとなる。また、この判断結果は、保険会社システム３００から保険金請求支援システム１００に返信される。

この場合、保険金請求支援システム１００は、上述の診療情報に基づく保険金支払請求の承認可否の判断結果を、保険会社システム３００から受信する（ｓ１１８）。

この判断結果が、保険金の支払い不可を示すものである場合（ｓ１１９：ｎ１）、保険金請求支援システム１００は、棄却レポート（図１０Ａの画面１０４０参照）を該当保険契約者のユーザ端末２００に配信し（ｓ１２０）、処理を終了する。

一方、上述の判断結果が、保険金支払いに別途確認手続が必要との回答を示すものである場合（ｓ１１９：ｎ２）、保険金請求支援システム１００は、この確認手続が必要である旨の通知を、上述の該当保険契約者のユーザ端末２００に送信し（ｓ１２１）、処理をＳ１１８に一旦戻す。

他方、上述の判断結果が、保険金支払い可を示すものである場合（ｓ１１９：ｙ）、保険金請求支援システム１００は、保険金支払いが承認された結果（図１０Ｂの画面１０５０参照）を、該当保険契約者のユーザ端末２００に送信し（ｓ１２２）、処理を終了する。

本実施形態によれば、保険契約者において、契約対象の被保険者の通院・治療行為に関する、保険契約者本人による申告を不要とすると共に、プロアクティブな保険金支払、貰いそびれの回避といったことが可能となる。従って、保険金の支払請求漏れが適宜に防止されることとなる。また、「診断書を送付する、保険会社に保険契約者自らアクションする」などの支払請求にかかる面倒な手続きが簡素化される。一方、保険会社において、保険金の不払い事象が効果的に低減される。このことは保険契約者への優良な顧客体験の提供とともに、それに伴う企業価値の向上が期待される。また支払請求にあたり、営業職員に顧客（保険契約者）との接触機会が創出される。

すなわち、種々のチャネルからの情報を適宜に処理し、効率的で的確な保険金支払請求の支援が可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記選択した所定属性の診療情報に基づき、保険金の支払請求が可能である旨の通知を、前記契約者の端末に宛てて送信し、当該端末より支払請求の実施要求を受けた場合、前記診療情報を前記保険会社の情報処理装置に送信するものである、としてもよい。

これによれば、保険の契約者における実施意思に応じて、保険金の支払請求の手順を進めることが可能となり、意思に反した保険金支払請求を的確に回避できる。ひいては、種々のチャネルからの情報を適宜に処理し、より効率的で的確な保険金支払請求の支援が可能となる。

また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記通知の送信に際し、予め記憶装置にて保持する前記保険契約の内容情報に基づき、保険金受取人または被保険者を特定し、前記契約者、前記保険金受取人、および前記被保険者の少なくともいずれかの端末に前記通知を送信するものである、としてもよい。

これによれば、保険契約者だけでなく、被保険者ないし保険金受取人といった対象者にも、保険金支払請求の要否を確認出来る。これにより、これら各対象者らの意思に反した保険金支払請求を更に的確に回避できる。

また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記所定属性の診療情報を選択するに際し、前記格納した診療情報のうち、同一の被保険者の同一の診療機会に関する診療情報が複数存在する場合、前記複数の診療情報から１つの診療情報を所定アルゴリズムで選択するものである、としてもよい。

これによれば、一人の被保険者の、同一の診療機会に関する、医療費通知、電子カルテ、レセプト、保険契約者による手入力といった種々のチャネルからの診療情報が所定期間に格納された場合にも的確に対応し、保険会社に対して診療情報を重複送信する事態を回避出来る。

また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記１つの診療情報を選択するに際し、種類の異なる診療情報の間について予め定めた優先順位に基づき、前記複数の診療情報から１つの診療情報を選択するものである、としてもよい。

これによれば、一人の被保険者の、同一の診療機会に関して得られた、医療費通知、電子カルテ、レセプト、保険契約者による手入力といった種々のチャネルからの診療情報のうち、例えば、より詳細な診療情報が得られるレセプトを優先し、それ以外の診療情報を保険会社への送信対象外とすることが可能となる。ひいては、保険会社に対する診療情報の重複送信を的確かつ効率的に回避出来る。

また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由の情報に照合し、当該保険金支払事由に該当する傷病ないし診療行為の情報を含む診療情報を選択するものである、としてもよい。

これによれば、保険金支払事由に該当する傷病等に関する診療情報のみを特定し、これを保険会社に送信し、保険金支払可否の承認判断の対象とすることができる。

また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由に該当しない傷病ないし診療行為の情報に照合し、当該保険金支払事由に該当しない傷病ないし診療行為の情報を含まない診療情報を選択するものである、としてもよい。

これによれば、数ある診療情報の中から、保険金支払事由に該当しない傷病等に関する診療情報を除外し、この除外後の診療情報のみを保険会社に送信し、保険金支払可否の承認判断の対象とすることができる。

また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記受信した診療情報のうち、確定していない診断内容に関する診療情報が存在する場合、当該診療情報に診断未確定フラグを付与して、前記保険会社の情報処理装置への送信対象から除外する処理を更に実行するものである、としてもよい。

これによれば、レセプトにおける、いわゆる「レセプト病名」、「疑い病名」といった、診断が未確定の傷病等に関する記載を含む診療情報を特定し、これを保険会社への送信対象から除外、すなわち保険金支払可否の承認判断の対象外とすることができる。

また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記受信した診療情報のうち、保険外診療に関する診療情報が存在する場合、当該診療情報に保険外診療フラグを付与して、前記保険会社の情報処理装置に送信するものである、としてもよい。

これによれば、保険金の支払事由に該当する診療情報のうち、保険外診療に関する情報を含むものを特定し、これを保険会社に提供することが出来る。この場合、保険会社では、当該保険契約者が契約中の保険について、保険外診療に対する特約と保険金支払の規定を確認して、保険金支払請求の承認可否判断を迅速に行いやすくなる。

また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記受信した診療情報のうち傷病名が含まれていないものを特定し、当該診療情報に関して傷病名の入力を受け付ける所定インターフェイスを、前記契約者の端末に送信して傷病名の情報入力を受け付け、当該受け付けた傷病名の情報を、前記診療情報に付加した上で、前記所定アルゴリズムによる選択処理の対象とするものである、としてもよい。

これによれば、例えば、医療費通知など傷病名の情報が含まれない診療情報しか取得できない場合でもこれに対応し、この診療情報を保険会社への送信対象とするか否かの判断対象とできる。

また、本実施形態の保険金請求支援システムにおいて、前記演算装置は、前記診療情報を前記保険会社の情報処理装置に送信した後、当該診療情報に基づく保険金支払請求の承認可否の判断結果を、前記情報処理装置から受信し、当該受信した判断結果を、前記契約者の端末に送信する処理を更に実行するものである、としてもよい。

これによれば、保険契約者等は、保険金の支払請求を要求した診療情報に関して、その承認判断の結果を確実に認識し、ひいては、以後の支払請求の実施要求の検討時に、無駄な実施要求を回避しやすくなる。このことは、より効率的で的確な保険金支払請求の処理につながる。

本実施形態の保険金請求支援方法において、前記情報処理システムが、前記選択した所定属性の診療情報に基づき、保険金の支払請求が可能である旨の通知を、前記契約者の端末に宛てて送信し、当該端末より支払請求の実施要求を受けた場合、前記診療情報を前記保険会社の情報処理装置に送信する、としてもよい。

本実施形態の保険金請求支援方法において、前記情報処理システムが、前記通知の送信に際し、予め記憶装置にて保持する前記保険契約の内容情報に基づき、保険金受取人または被保険者を特定し、前記契約者、前記保険金受取人、および前記被保険者の少なくともいずれかの端末に前記通知を送信する、としてもよい。

本実施形態の保険金請求支援方法において、前記情報処理システムが、前記所定属性の診療情報を選択するに際し、前記格納した診療情報のうち、同一の被保険者の同一の診療機会に関する診療情報が複数存在する場合、前記複数の診療情報から１つの診療情報を所定アルゴリズムで選択する、としてもよい。

本実施形態の保険金請求支援方法において、前記情報処理システムが、前記１つの診療情報を選択するに際し、種類の異なる診療情報の間について予め定めた優先順位に基づき、前記複数の診療情報から１つの診療情報を選択する、としてもよい。

本実施形態の保険金請求支援方法において、前記情報処理システムが、前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由の情報に照合し、当該保険金支払事由に該当する傷病ないし診療行為の情報を含む診療情報を選択する、としてもよい。

本実施形態の保険金請求支援方法において、前記情報処理システムが、前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由に該当しない傷病ないし診療行為の情報に照合し、当該保険金支払事由に該当しない傷病ないし診療行為の情報を含まない診療情報を選択する、としてもよい。

本実施形態の保険金請求支援方法において、前記情報処理システムが、前記受信した診療情報のうち、確定していない診断内容に関する診療情報が存在する場合、当該診療情報に診断未確定フラグを付与して、前記保険会社の情報処理装置への送信対象から除外する処理を更に実行する、としてもよい。

本実施形態の保険金請求支援方法において、前記情報処理システムが、前記選択した所定属性の診療情報のうち、保険外診療に関する診療情報が存在する場合、当該診療情報に保険外診療フラグを付与して、前記保険会社の情報処理装置に送信する、としてもよい。

本実施形態の保険金請求支援方法において、前記情報処理システムが、前記受信した診療情報のうち傷病名が含まれていないものを特定し、当該診療情報に関して傷病名の入力を受け付ける所定インターフェイスを、前記契約者の端末に送信して傷病名の情報入力を受け付け、当該受け付けた傷病名の情報を、前記診療情報に付加した上で、前記所定アルゴリズムによる選択処理の対象とする、としてもよい。

本実施形態の保険金請求支援方法において、前記情報処理システムが、前記診療情報を前記保険会社の情報処理装置に送信した後、当該診療情報に基づく保険金支払請求の承認可否の判断結果を、前記情報処理装置から受信し、当該受信した判断結果を、前記契約者の端末に送信する処理を更に実行する、としてもよい。

１０ ネットワーク
１００ 保険金請求支援システム
１０１ 記憶装置
１０２ プログラム
１０３ メモリ
１０４ ＣＰＵ（演算装置）
１０５ 通信装置
１２５ フィルタリングマスタテーブル
１２６ 支払フィルタテーブル
１２７ 除外フィルタテーブル
１２８ ユーザマスタテーブル
１２９ 契約内容マスタテーブル
１３０ 被保険者マスタテーブル
１３１ 診療履歴テーブル
２００ ユーザ端末
３００ 保険会社システム
４００ 健保システム
５００ 病院システム

Claims (22)

1. ネットワーク上の１または複数の所定装置と通信する通信装置と、
   所定保険の被保険者に関する診療情報を、前記所定装置より受信して記憶装置に格納し、前記格納した診療情報のうち所定属性のものを、所定アルゴリズムで選択する処理と、前記選択した診療情報を、前記保険の契約者が保険契約を結んでいる保険会社の情報処理装置に送信する処理と、を実行する演算装置と、
   を含むことを特徴とする保険金請求支援システム。
2. 前記演算装置は、
   前記選択した所定属性の診療情報に基づき、保険金の支払請求が可能である旨の通知を、前記契約者の端末に宛てて送信し、当該端末より支払請求の実施要求を受けた場合、前記診療情報を前記保険会社の情報処理装置に送信するものである、
   ことを特徴とする請求項１に記載の保険金請求支援システム。
3. 前記演算装置は、
   前記通知の送信に際し、予め記憶装置にて保持する前記保険契約の内容情報に基づき、保険金受取人または被保険者を特定し、前記契約者、前記保険金受取人、および前記被保険者の少なくともいずれかの端末に前記通知を送信するものである、
   ことを特徴とする請求項２に記載の保険金請求支援システム。
4. 前記演算装置は、
   前記所定属性の診療情報を選択するに際し、前記格納した診療情報のうち、同一の被保険者の同一の診療機会に関する診療情報が複数存在する場合、前記複数の診療情報から１つの診療情報を所定アルゴリズムで選択するものである、
   ことを特徴とする請求項１に記載の保険金請求支援システム。
5. 前記演算装置は、
   前記１つの診療情報を選択するに際し、種類の異なる診療情報の間について予め定めた優先順位に基づき、前記複数の診療情報から１つの診療情報を選択するものである、
   ことを特徴とする請求項４に記載の保険金請求支援システム。
6. 前記演算装置は、
   前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由の情報に照合し、当該保険金支払事由に該当する傷病ないし診療行為の情報を含む診療情報を選択するものである、
   ことを特徴とする請求項１に記載の保険金請求支援システム。
7. 前記演算装置は、
   前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由に該当しない傷病ないし診療行為の情報に照合し、当該保険金支払事由に該当しない傷病ないし診療行為の情報を含まない診療情報を選択するものである、
   ことを特徴とする請求項１に記載の保険金請求支援システム。
8. 前記演算装置は、
   前記受信した診療情報のうち、確定していない診断内容に関する診療情報が存在する場合、当該診療情報に診断未確定フラグを付与して、前記保険会社の情報処理装置への送信対象から除外する処理を更に実行するものである、
   ことを特徴とする請求項１に記載の保険金請求支援システム。
9. 前記演算装置は、
   前記受信した診療情報のうち、保険外診療に関する診療情報が存在する場合、当該診療情報に保険外診療フラグを付与して、前記保険会社の情報処理装置に送信するものである、
   ことを特徴とする請求項１に記載の保険金請求支援システム。
10. 前記演算装置は、
    前記受信した診療情報のうち傷病名が含まれていないものを特定し、当該診療情報に関して傷病名の入力を受け付ける所定インターフェイスを、前記契約者の端末に送信して傷病名の情報入力を受け付け、当該受け付けた傷病名の情報を、前記診療情報に付加した上で、前記所定アルゴリズムによる選択処理の対象とするものである、
    ことを特徴とする請求項１に記載の保険金請求支援システム。
11. 前記演算装置は、
    前記診療情報を前記保険会社の情報処理装置に送信した後、当該診療情報に基づく保険金支払請求の承認可否の判断結果を、前記情報処理装置から受信し、当該受信した判断結果を、前記契約者の端末に送信する処理を更に実行するものである、
    ことを特徴とする請求項１に記載の保険金請求支援システム。
12. ネットワーク上の１または複数の所定装置と通信する通信装置を備えた情報処理システムが、
    所定保険の被保険者に関する診療情報を、前記所定装置より受信して記憶装置に格納し、前記格納した診療情報のうち所定属性のものを、所定アルゴリズムで選択する処理と、
    前記選択した診療情報を、前記保険の契約者が保険契約を結んでいる保険会社の情報処理装置に送信する処理と、
    を実行することを特徴とする保険金請求支援方法。
13. 前記情報処理システムが、
    前記選択した所定属性の診療情報に基づき、保険金の支払請求が可能である旨の通知を、前記契約者の端末に宛てて送信し、当該端末より支払請求の実施要求を受けた場合、前記診療情報を前記保険会社の情報処理装置に送信する、
    ことを特徴とする請求項１２に記載の保険金請求支援方法。
14. 前記情報処理システムが、
    前記通知の送信に際し、予め記憶装置にて保持する前記保険契約の内容情報に基づき、保険金受取人または被保険者を特定し、前記契約者、前記保険金受取人、および前記被保険者の少なくともいずれかの端末に前記通知を送信する、
    ことを特徴とする請求項１３に記載の保険金請求支援方法。
15. 前記情報処理システムが、
    前記所定属性の診療情報を選択するに際し、前記格納した診療情報のうち、同一の被保険者の同一の診療機会に関する診療情報が複数存在する場合、前記複数の診療情報から１つの診療情報を所定アルゴリズムで選択する、
    ことを特徴とする請求項１２に記載の保険金請求支援方法。
16. 前記情報処理システムが、
    前記１つの診療情報を選択するに際し、種類の異なる診療情報の間について予め定めた優先順位に基づき、前記複数の診療情報から１つの診療情報を選択する、
    ことを特徴とする請求項１５に記載の保険金請求支援方法。
17. 前記情報処理システムが、
    前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由の情報に照合し、当該保険金支払事由に該当する傷病ないし診療行為の情報を含む診療情報を選択する、
    ことを特徴とする請求項１２に記載の保険金請求支援方法。
18. 前記情報処理システムが、
    前記所定属性の診療情報を選択するに際し、前記格納した診療情報を、前記保険会社が当該保険に関して規定している保険金支払事由に該当しない傷病ないし診療行為の情報に照合し、当該保険金支払事由に該当しない傷病ないし診療行為の情報を含まない診療情報を選択する、
    ことを特徴とする請求項１２に記載の保険金請求支援方法。
19. 前記情報処理システムが、
    前記受信した診療情報のうち、確定していない診断内容に関する診療情報が存在する場合、当該診療情報に診断未確定フラグを付与して、前記保険会社の情報処理装置への送信対象から除外する処理を更に実行する、
    ことを特徴とする請求項１２に記載の保険金請求支援方法。
20. 前記情報処理システムが、
    前記選択した所定属性の診療情報のうち、保険外診療に関する診療情報が存在する場合、当該診療情報に保険外診療フラグを付与して、前記保険会社の情報処理装置に送信する、
    ことを特徴とする請求項１２に記載の保険金請求支援方法。
21. 前記情報処理システムが、
    前記受信した診療情報のうち傷病名が含まれていないものを特定し、当該診療情報に関して傷病名の入力を受け付ける所定インターフェイスを、前記契約者の端末に送信して傷病名の情報入力を受け付け、当該受け付けた傷病名の情報を、前記診療情報に付加した上で、前記所定アルゴリズムによる選択処理の対象とする、
    ことを特徴とする請求項１２に記載の保険金請求支援方法。
22. 前記情報処理システムが、
    前記診療情報を前記保険会社の情報処理装置に送信した後、当該診療情報に基づく保険金支払請求の承認可否の判断結果を、前記情報処理装置から受信し、当該受信した判断結果を、前記契約者の端末に送信する処理を更に実行する、
    ことを特徴とする請求項１２に記載の保険金請求支援方法。