JP2022055946A - 支払対象外可能性判定装置、支払対象外可能性判定システム、および支払対象外可能性判定方法 - Google Patents

Abstract

【課題】保険金の支払請求に対する査定業務を効率化する。【解決手段】支払対象外可能性判定装置は、顧客からの保険金の請求情報を取得する第１の取得部と、前記保険金の請求に関連する書類に記載された情報を取得する第２の取得部と、前記請求情報、前記書類に記載された情報、前記顧客の保険の契約情報、および過去の保険金請求と前記過去の保険金請求に対する保険金の支払い実績とに基づいて作成された統計データに基づいて、前記保険金の請求が保険金の支払対象とならない可能性を判定する判定部と、を備える。【選択図】図３

Description

本発明は、支払対象外可能性判定装置、支払対象外可能性判定システム、および支払対象外可能性判定方法に関する。

顧客が保険金を誤って請求する場合（過誤請求）や、顧客が保険金を不正に請求する場合（不正請求）があるため、保険金の支払請求の中には、保険金の支払対象外となる請求が存在する。そこで、保険会社では、請求が保険金の支払対象となるか否かを査定する査定部署を設けている。

特開２００３－３０４４１号公報

保険金の支払対象外となる請求、とくに不正請求に関しては複数の要素を複合的にチェックする必要があり、マニュアル化した一律のチェックを行うことが難しい。したがって、請求が保険金の支払対象となるか否かの判断は担当者の経験則によるところが大きく、査定業務は効率化が難しい業務となっている。

そこで本発明は、保険金の支払請求に対する査定業務を効率化できる支払対象外可能性判定装置、支払対象外可能性判定システム、および支払対象外可能性判定方法を提供することを目的とする。

本発明に係る支払対象外可能性判定装置は、顧客からの保険金の請求情報を取得する第１の取得部と、前記保険金の請求に関連する書類に記載された情報を取得する第２の取得部と、前記請求情報、前記書類に記載された情報、前記顧客の保険の契約情報、および過去の保険金請求と前記過去の保険金請求に対する保険金の支払い実績とに基づいて作成された統計データに基づいて、前記保険金の請求が保険金の支払対象とならない可能性を判定する判定部と、を備える。

上記構成において、前記可能性に基づいて、前記保険金請求に対応する部署を複数の部署の中から決定する決定部を有していてもよい。

上記構成において、前記第２の取得部は、前記書類の画像をＡＩ－ＯＣＲによりテキスト化することによって、前記書類に記載された情報を取得してもよい。

上記構成において、前記統計データは、予め定められた複数の項目と前記複数の項目のそれぞれに登録されている値との組み合わせごとに、前記過去の保険金請求において前記組み合わせに該当する全レコード数と、前記組み合わせに該当するレコード数のうち保険金が支払われなかったレコード数と、前記全レコード数に対する前記保険金が支払われなかったレコード数の割合と、を格納することとしてもよい。

上記構成において、前記判定部は、前記保険金の請求について、前記請求情報、前記書類に記載された情報、および前記顧客の保険の契約情報を用いて前記予め定められた複数の項目のそれぞれに対する値を取得し、前記統計データから、取得した前記予め定められた複数の項目のそれぞれに対する値に対応する前記割合を、取得し、前記予め定められた複数の項目のそれぞれに対して設定された重み係数と、前記割合と、を用いて前記保険金の請求が保険金の支払対象とならない可能性を判定する、こととしてもよい。

上記構成において、前記予め定められた項目は、前記請求情報、前記契約情報、および前記書類に記載された情報のいずれかに含まれる項目であるとしてもよい。

上記構成において、前記予め定められた項目は、前記過去の保険金の請求情報、契約情報、および書類に記載された情報に含まれる項目を複数用いた項目であるとしてもよい。

上記構成において、支払対象外可能性判定装置は、前記統計データを生成する統計データ生成部を備えていてもよい。

本発明に係る支払対象外可能性判定システムは、顧客から保険金の請求情報の入力を受け付ける受付部と、前記保険金の請求に関連する書類の画像を取得する第１取得部と、前記請求情報と前記書類の画像とを送信する送信部と、を有する第１の装置と、前記書類の画像から前記書類に記載された情報を取得する第２取得部と、前記請求情報、前記書類に記載された情報、前記顧客の保険の契約情報、および過去の保険金請求と前記過去の保険金請求に対する保険金の支払い実績とに基づいて作成された統計データに基づいて、前記保険金の請求が保険金の支払対象とならない可能性を判定する判定部と、を有する第２の装置と、を備える。

本発明に係る支払対象外可能性判定方法は、顧客からの保険金の請求情報を取得するステップと、前記保険金の請求に関連する書類に記載された情報を取得するステップと、前記請求情報、前記書類に記載された情報、前記顧客の保険の契約情報、および過去の保険金請求と前記過去の保険金請求に対する保険金の支払い実績とに基づいて作成された統計データに基づいて、前記保険金の請求が保険金の支払対象とならない可能性を判定するステップと、をコンピュータが実行する。

本発明によれば、保険金の支払請求に対する査定業務を効率化できる。

図１は、一実施形態に係る支払対象外可能性判定システムのブロック図である。 図２（Ａ）は、顧客端末の機能ブロック図であり、図２（Ｂ）は、顧客端末のハードウェア構成を示す図である。 図３（Ａ）は、判定サーバの機能ブロック図であり、図３（Ｂ）は、判定サーバのハードウェア構成を示す図である。 図４は、保険金支払管理テーブルの一例を示す図である。 図５は、判定サーバが請求情報および書類画像を取得するまでのプロセスを示すシーケンス図である。 図６（Ａ）は、ログイン画面の一例を示す図であり、図６（Ｂ）は、トップページの一例を示す図であり、図６（Ｃ）は、保険金請求情報入力画面の一例を示す図である。 図７（Ａ）は、書類撮影画面の一例を示す図であり、図７（Ｂ）は、受付完了画面の一例を示す図である。 図８（Ａ）は、判定ＤＢの一例を示す図であり、図８（Ｂ）は、重み係数ＤＢの一例を示す図である。 図９は、判定サーバが実行する処理の一例を示すフローチャートである。 図１０は、書類記載情報の一例を示す図である。 図１１は、判定項目の例を示す図である。

以下、本発明の実施形態について、添付図面を参照しつつ説明する。

［実施形態］
図１は、一実施形態に係る支払対象外可能性判定システム１００のブロック図である。支払対象外可能性判定システム１００は、顧客から保険金の支払い請求があった場合に、当該請求が保険金支払いの対象である可能性を判定するシステムである。

図１に示すように、支払対象外可能性判定システム１００は、顧客端末６０、契約情報管理サーバ２０、判定サーバ３０、および保険金支払管理サーバ４０などを備えている。

契約情報管理サーバ２０、判定サーバ３０、および保険金支払管理サーバ４０は、社内ＬＡＮなどのネットワークＮＷ２を介して接続されている。

また、判定サーバ３０は、顧客端末６０とネットワークＮＷ１を介して接続されている。ネットワークＮＷ１は、例えばインターネット等の電気通信回線である。

（顧客端末６０）
顧客端末６０は、保険会社（又は保険代理店）の顧客が所持する、スマートフォン、タブレット型端末、パーソナルコンピュータなどである。顧客は、保険金の支払いを請求する場合、顧客端末６０に、保険金の支払請求に必要な情報を入力し、判定サーバ３０に送信する。

図２（Ａ）は、顧客端末６０の機能ブロック図である。図２（Ａ）に示すように、顧客端末６０は、表示制御部６１、通信部６２、および画像取得部６３などとして機能する。

図２（Ｂ）は、顧客端末６０のハードウェア構成を示す図である。図２（Ｂ）で例示するように、顧客端末６０は、ＣＰＵ（Central Processing Unit）６０１、ＲＡＭ(Random Access Memory)６０２、記憶装置６０３、通信装置６０４、入力機器６０５、表示装置６０６、撮像装置６０７などを備える。これらの各機器は、バスなどによって接続されている。ＣＰＵ６０１は、中央演算処理装置である。ＲＡＭ６０２は、ＣＰＵ６０１が実行するプログラム、ＣＰＵ６０１が処理するデータなどを一時的に記憶する揮発性メモリである。記憶装置６０３は、不揮発性記憶装置である。記憶装置６０３として、例えば、ＲＯＭ（Read Only Memory）、フラッシュメモリなどのソリッド・ステート・ドライブ（SSD）、ハードディスクドライブに駆動されるハードディスクなどを用いることができる。記憶装置６０３に記憶されているプログラムをＣＰＵ６０１が実行することによって、顧客端末６０の各部の機能が実現される。なお、顧客端末６０の各部の機能は、それぞれ専用の回路等によって構成されていてもよい。通信装置６０４は、ネットワークＮＷ１に対するインタフェースである。入力機器６０５は、情報を入力するための装置であり、キーボード、マウス、タッチパネルなどである。表示装置６０６は、情報を表示するための装置であり、例えば、液晶ディスプレイなどである。撮像装置６０７は、撮影対象を撮影するための装置であり、例えば、カメラである。なお、顧客端末６０は、撮像装置６０７を備えていなくてもよい。

（契約情報管理サーバ２０）
契約情報管理サーバ２０は、例えば、サーバなどのコンピュータであり、保険会社内や保険会社が契約したクラウド環境等に設置される。契約情報管理サーバ２０には、各顧客の保険の契約情報が格納されている。契約情報は、例えば、保険の証券番号、契約タイプ、補償特約、保険期間、契約日、過去の請求履歴、初年度契約日、被保険者と契約者との関係、被保険者の性別、被保険者の年齢、保険契約を取り扱った代理店、契約者の住所、および被保険者の住所などの情報を含む。

（判定サーバ３０）
判定サーバ３０は、例えば、サーバなどのコンピュータであり、保険会社内や保険会社が契約したクラウド環境等に設置される。判定サーバ３０は、顧客端末６０から保険金の支払請求を受信すると、当該請求が保険金支払の対象外となる可能性について判定する。

図３（Ａ）は、判定サーバ３０の機能ブロック図である。図３（Ａ）に示すように、判定サーバ３０は、請求情報受信部３１、画像情報処理部３２、支払対象外可能性判定部３５、対応部署決定部３６、判定ＤＢ格納部３７、および判定ＤＢ作成部３８などとして機能する。

図３（Ｂ）は、判定サーバ３０のハードウェア構成を示す図である。図３（Ｂ）に示すように、判定サーバ３０は、ＣＰＵ３０１、ＲＡＭ３０２、記憶装置３０３、通信装置３０４、入力機器３０５などを備える。これらの各機器は、バスなどによって接続されている。ＣＰＵ３０１は、中央演算処理装置である。ＲＡＭ３０２は、ＣＰＵ３０１が実行するプログラム、ＣＰＵ３０１が処理するデータなどを一時的に記憶する揮発性メモリである。記憶装置３０３は、不揮発性記憶装置である。記憶装置３０３として、例えば、ＲＯＭ、フラッシュメモリなどのソリッド・ステート・ドライブ（SSD）、ハードディスクドライブに駆動されるハードディスクなどを用いることができる。記憶装置３０３に記憶されているプログラムをＣＰＵ３０１が実行することによって、判定サーバ３０の各部の機能が実現される。なお、判定サーバ３０の各部の機能は、それぞれ専用の回路等によって構成されていてもよい。通信装置３０４は、ネットワークＮＷ１およびネットワークＮＷ２に対するインタフェースである。入力機器３０５は、情報を入力するための装置であり、キーボード、マウスなどである。

（保険金支払管理サーバ４０）
保険金支払管理サーバ４０は、例えば、サーバなどのコンピュータであり、保険会社内や保険会社が契約したクラウド環境等に設置される。保険金支払管理サーバ４０には、顧客からの保険金の支払請求情報を管理する保険金支払管理テーブルが格納されている。保険金支払管理テーブルは、例えば、図４に示すように、顧客が顧客端末６０から入力した請求情報、保険金の請求時に提出された書類に記載された情報（書類記載情報）、および契約情報を含む。また、保険金支払管理テーブルには、保険金の各支払請求に対して、保険金の支払い対象となるか否かを専門の査定部署が査定した査定結果、および保険金の支払い対象であった場合に実際に支払われた保険金額等の実績情報も格納されている。

≪請求情報取得プロセス≫
まず、本実施形態に係る支払対象外可能性判定システム１００において、判定サーバ３０が保険金支払の請求情報および保険金の請求に必要な書類の画像を取得するまでのプロセスについて、図５のシーケンス図を用いて説明する。

図５の処理において、保険金の支払請求を行う顧客は、顧客端末６０を用いて保険会社の顧客用のウェブページにアクセスする（ステップＳ１１）。顧客端末６０の表示制御部６１は、顧客用のウェブページのログイン画面を表示装置６０６に表示する（ステップＳ１３）。

図６（Ａ）は、ログイン画面の一例を示す図である。図６（Ａ）に示すように、ログイン画面は、ログインＩＤとパスワード（ＰＷ）とを入力項目として有している。

顧客は、図６（Ａ）に示すログイン画面において、ログインＩＤとパスワードとを入力する（ステップＳ１５）。顧客が、図６（Ａ）に示すログイン画面において、送信ボタンＢ１を押すと、顧客端末６０の通信部６２は、入力されたログインＩＤ及びパスワードを判定サーバ３０に送信する（ステップＳ１７）。

判定サーバ３０は、ログインＩＤ及びパスワードを受信すると、ログインＩＤとパスワードの組み合わせが正しいか否かを判断する認証処理を実行する（ステップＳ１９）。

受信したログインＩＤとパスワードとの組み合わせが正しい場合、判定サーバ３０は、顧客用のトップページを顧客端末６０に送信する（ステップＳ２１）。顧客端末６０の表示制御部６１は、トップページを表示装置６０６に表示する（ステップＳ２３）。図６（Ｂ）に、トップページの一例を示す。図６（Ｂ）に示すように、トップページでは、顧客用のウェブページにおいて実行できる処理が選択できるようになっている。例えば、図６（Ｂ）に示すトップページでは、契約者情報の確認または修正、補償内容の確認、および保険金の請求が選択できるようになっている。

保険金の請求を行う場合、顧客は、例えば、図６（Ｂ）に示すトップページにおいて、「保険金請求」を指でタップまたはマウス等でクリックすることで、保険金請求を選択する（ステップＳ２５）。

顧客端末６０の表示制御部６１は、例えば、図６（Ｃ）に示すような請求情報入力画面を表示装置６０６に表示する（ステップＳ２７）。顧客は、請求情報入力画面において、保険金の請求に必要な情報を入力する（ステップＳ２９）。例えば、図６（Ｃ）に示すように、顧客は、請求情報入力画面に表示されている入院状況、発病日、症状等に関する質問に回答することにより、保険金の請求に必要な情報（請求情報）を入力する。

また、顧客は、医療機関で発行された領収書等、保険金の請求に必要な書類を撮影する（ステップＳ３１）。例えば、図６（Ｃ）に示す請求情報入力画面において、「次へ」ボタンＢ２を押すと、図７（Ａ）に示すように書類の撮影画面が顧客端末６０の表示装置６０６に表示される。顧客が図７（Ａ）に示す画面においてボタンＢ３を押すと、画像取得部６３は撮像装置６０７により書類を撮影し、書類の画像を取得する。なお、顧客端末６０が撮像装置６０７を有さない場合には、画像取得部６３は、顧客端末６０とは別体のカメラで撮影した書類の画像を当該カメラに接続されたＵＳＢケーブルを経由して取得し、判定サーバ３０に送信するようにしてもよい。

顧客が請求情報および書類画像の送信操作を顧客端末６０にて行うと、通信部６２は、請求情報および書類画像が判定サーバ３０に送信する（ステップＳ３３）。判定サーバ３０は、請求情報および書類画像を受信すると、受付完了画面を顧客端末６０に送信する（ステップＳ３５）。顧客端末６０の表示制御部６１は、図７（Ｂ）に示すような受付完了画面を表示装置６０６に表示させる（ステップＳ３７）。

以上の処理により、判定サーバ３０は保険金の請求情報および書類画像を取得することができる。

《支払対象外可能性判定プロセス》
上記のようにして取得した請求情報および書類画像と、顧客の保険の契約情報と、判定ＤＢ格納部３７に格納されている判定ＤＢ（Data Base）及び重み係数ＤＢと、に基づいて、判定サーバ３０は、顧客端末６０から受信した支払請求が保険金の支払対象外となる可能性（支払対象外可能性）について判定する。判定ＤＢおよび重み係数ＤＢは、査定業務担当者のノウハウを数値化することを目的として作成されたデータベースである。

判定サーバ３０が実行する処理を説明する前に、支払対象外可能性の判定に用いられる判定ＤＢおよび重み係数ＤＢについて説明する。

図８（Ａ）は、判定ＤＢの一例を示す図である。判定ＤＢは、保険金の支払請求に対する保険金の支払い実績（図４参照）に基づいて判定ＤＢ作成部３８により作成された統計データである。図８（Ａ）に示すように、判定ＤＢは、判定項目、項目値、対象外レコード数、全レコード数、および対象外率のフィールドを含む。

判定項目のフィールドには、支払対象外可能性の判定に利用される項目名が登録される。判定項目のフィールドに登録される項目名は、保険金の請求情報、保険の契約情報、および保険請求時に提出された書類に記載された情報が有する項目の項目名（例えば、図８（Ａ）に示す「受診科」、「病名」、「代理店」）であってもよいし、複数の項目の項目値から算出される値の定義（例えば、契約情報の「初年度契約日」の項目値と請求情報の「発病日」の項目値とから算出できる「初年度契約日から発病日までの経過期間」）等であってもよい。判定項目は、顧客からの請求が保険金の支払対象となるか否かを査定する査定部署が、査定を行う際によく利用する、あるいは、重要視する項目とすればよい。

項目値のフィールドには、判定項目に対する値が登録される。

全レコード数のフィールドには、保険金支払管理テーブルに登録されているレコードのうち、判定項目に対応する項目に項目値が登録されているレコードの件数が登録される。例えば、判定ＤＢ作成部３８は、支払対象外可能性判定システム１００の導入時に、保険金支払管理テーブルに登録されているレコードすべてについて、判定項目と項目値との各組み合わせに対して、該当するレコードの件数を数え、「全レコード数」の項目に登録する。判定ＤＢ作成部３８は、支払対象外可能性判定システム１００の導入後は、所定期間ごと（例えば、１日ごと、１週間ごと）に、新規に登録されたレコードに対して同様の処理を行い、判定ＤＢのデータを更新する。これにより、新規の情報を反映した判定ＤＢに基づいて、支払対象外可能性を判定できるようになる。

対象外レコード数のフィールドには、保険金支払管理テーブルにおいて、判定項目に対応する項目に項目値が登録されているレコードのうち、保険金が支払われなかったレコードの件数が登録される。例えば、判定ＤＢ作成部３８は、支払対象外可能性判定システム１００の導入時に、保険金支払管理テーブルに登録されているレコードすべてについて、判定項目と項目値との各組み合わせに対して、該当するレコードのうち保険金が支払われなかったレコードの件数を数え、「対象外レコード数」の項目に登録する。判定ＤＢ作成部３８は、支払対象外可能性判定システム１００の導入後は、所定期間ごと（例えば、１日ごと、１週間ごと）に、新規に登録されたレコードに対して同様の処理を行い、判定ＤＢのデータを更新する。これにより、新規の情報を反映した判定ＤＢに基づいて、対象外可能性を判定できるようになる。なお、上述したように、保険金支払管理テーブルには、査定を専門に行う査定部署の担当者が、各請求が保険金の支払い対象となるか否かを査定した結果が反映されている。したがって、当該保険金支払管理テーブルのデータを用いることで、保険金の支払対象外可能性を判定するのに信頼性の高い統計データを得ることができる。

対象外率のフィールドには、全レコード数に対する対象外レコード数の割合（対象外レコード数を全レコード数で除した値）が登録される。

図８（Ｂ）は、重み係数ＤＢの一例を示す図である。重み係数ＤＢは、判定項目と重み係数のフィールドを有する。判定項目のフィールドには、判定ＤＢの判定項目が登録される。重み係数のフィールドには、図８（Ｂ）に示すように、判定項目ごとの重み係数が登録される。重み係数の値は、請求が支払対象外となるか否かの判断（有無責判断）に対して判定項目が影響する度合いに応じて設定される。例えば、病名および診療科は、有無責判断に対して直接影響を及ぼす項目であるため、大きい重み係数が設定される。一方、代理店は有無責判断に直接的な影響は及ぼさず、判断の補助的項目になるため比較的小さい重み係数が設定される。

上記の判定ＤＢおよび重み係数ＤＢを用いて、支払対象外可能性判定部３５は、保険金の支払請求が、保険金の支払対象外となる可能性を判定する。

図９は、判定サーバ３０が実行する処理の一例を示すフローチャートである。図９の処理は、例えば、請求情報受信部３１が、請求情報および書類画像を受信すると開始される。

図９に示すように、請求情報受信部３１が、請求情報および書類画像を受信すると、画像情報処理部３２は、受信した書類画像をＡＩ－ＯＣＲ（Artificial Intelligence-Optical Character Recognition）によってテキスト化する（ステップＳ５３）。画像情報処理部３２は、テキスト化した情報から、予め定められた項目に対して記載されている内容を抽出し、図１０に示すように、書類記載情報として支払対象外可能性判定部３５に出力する。なお、書類画像からＡＩ－ＯＣＲで読み込む情報（項目）は、保険の補償内容に応じて調整される。

次に、支払対象外可能性判定部３５は、請求情報、書類記載情報、および契約情報から、支払対象外可能性の判定に用いる情報を取得する（ステップＳ５５）。具体的には、支払対象外可能性判定部３５は、請求情報、書類記載情報、および契約情報から、判定ＤＢの判定項目に対応する項目に対して登録されている情報を取得する。また、支払対象外可能性判定部３５は、判定ＤＢの判定項目に定義されている値を算出するのに必要な情報を請求情報、書類記載情報、および契約情報から取得する。

例えば、判定ＤＢの判定項目に「病名」が登録されている場合、支払対象外可能性判定部３５は、請求情報から「病名」に対して登録されている情報を取得する。また、例えば、支払対象外可能性判定部３５は、判定ＤＢの判定項目に「受診科」が登録されている場合、書類記載情報から「受診科」に対して登録されている情報（例えば、脳外科）を取得する。また、例えば、支払対象外可能性判定部３５は、判定ＤＢの判定項目に「代理店」が登録されている場合、契約情報の中から保険の契約を取り使った代理店の情報を取得する。

次に、支払対象外可能性判定部３５は、請求が保険金の支払対象外となる可能性を判定する（ステップＳ６１）。具体的には、請求が保険金の支払対象外となる確率（支払対象外確率）を算出する。

ここで、支払対象外確率の算出方法について説明する。まず、支払対象外可能性判定部３５は、判定ＤＢ（図８（Ａ）参照）から、ステップＳ６１で抽出した情報と同一の項目値に対して設定されている対象外率を取得する。例えば、書類記載情報において「受診科」に対して“脳外科”が登録されており、請求情報において「病名」に対して“脳梗塞”が登録されており、契約情報において「代理店」に対して“代理店Ｃ”が登録されているとする。この場合、支払対象外可能性判定部２２は、それぞれの対象外率“１０％”、“１０％”および“３３％”を判定ＤＢから取得する。

支払対象外可能性判定部３５は、取得した対象外率に、重み係数ＤＢ（図８（Ｂ）参照）において判定項目ごとに設定されている重み係数を乗算し、その総和を重み係数の和で除算した値（加重平均値）を支払対象外確率として算出する。

例えば、図８（Ｂ）に示すように、「受診科」に対する重み係数が５であり、「病名」に対する重み係数が５であり、「代理店」に対する重み係数が１であったとする。この場合、支払対象外確率は、
（１０％×５＋１０％×５＋３３％×１）/１１＝１２％
となる。

次に、対応部署決定部３６が、支払対象外確率に基づいて、顧客の保険金の支払請求に対応する（支払請求を査定する）部署を決定する（ステップＳ６３）。具体的には、例えば、支払対象外確率が低い場合、すなわち、保険金の支払対象となる可能性が高い請求については、その対応部署を、簡易的に請求を査定する部署に決定する。一方、総合対象外率が高い場合、保険金の支払対象外となる可能性が高いため、その対応部署を、専門性の高い部署に決定する。これにより、保険金の支払対象となる可能性が高い請求については、簡易的に請求を査定する部署が処理を行うため、保険金が顧客に支払われるまでの時間を短縮することができ、顧客満足度の向上につなげることができる。一方、保険金の支払対象外となる可能性が高い請求については、専門性の高い部署が査定を行うことで、不正請求または過誤請求に対して保険金が支払われるのを防止することができる。

以上、詳細に説明したように、本実施形態によれば、判定サーバ３０は、顧客からの保険金の請求情報を取得する請求情報受信部３１と、保険金の請求に関連する書類に記載された情報を取得する画像情報処理部３２と、請求情報、書類に記載された情報、顧客の保険の契約情報、および過去の保険金請求と過去の保険金請求に対する保険金の支払い実績とに基づいて作成された判定ＤＢに基づいて、保険金の請求が保険金の支払対象外となる可能性を判定する支払対象外可能性判定部３５と、を備える。これにより、過去の保険金の請求とそれに対する支払い実績に基づいて作成した判定ＤＢには、担当者の査定時のノウハウが反映されていると考えられる。したがって、判定ＤＢを用いることで、支払い対象外となる可能性を精度よく判定することができ、保険金の支払い査定業務を効率化することができる。

また、本実施形態において、判定サーバ３０は、保険金の請求が保険金の支払対象外となる可能性（支払対象外確率）に基づいて、請求に対応する部署を決定する。これにより、保険金の支払対象となる可能性が高い請求については、例えば、簡易的に請求を査定する部署が対応することで、保険金が顧客に支払われるまでの時間を短縮することができ、顧客満足度の向上につなげることができる。一方、保険金の支払対象外となる可能性が高い請求については、専門性の高い部署が対応することで、不正請求や誤請求に対して保険金が支払われるのを防止することができる。

また、本実施形態において、画像情報処理部３２は、書類の画像をＡＩ－ＯＣＲによりテキスト化することによって、書類に記載された情報を取得する。これにより、顧客や保険会社のオペレータが書類に記載された情報を登録する必要がないため、入力ミス等によって保険金の請求情報に誤りが生じることを防止することができる。

また、本実施形態において、支払対象外可能性判定部３５は、顧客からの保険金の請求について、請求情報、書類に記載された情報、および顧客の保険の契約情報を用いて判定ＤＢに設定されている判定項目に対する値を取得し、判定ＤＢから取得した値に対応する対象外率を取得し、判定項目のそれぞれに対して設定された重み係数と、取得した対象外率と、を用いて保険金の請求が保険金の支払対象外となる可能性を判定する。これにより、有無責判断に対して直接影響を及ぼす項目と、直接的には影響を及ぼさない項目とで、その重みを変えることができるとともに、査定業務担当者のノウハウ（査定時に重要視する項目、不正請求で問題となる項目）を重み係数に反映することができるので、保険金の支払対象外となる可能性をより正確に判定することができる。

なお、上記実施形態では、判定ＤＢの判定項目として「受診科」、「病名」、および「代理店」を使用していたが、これらに限られるものではない。例えば、図１１に示す項目を判定項目として使用することができる。ここで、図１１のＮｏ．１の契約タイプ～Ｎｏ．９の被保険者住所の項目に対する項目値は、契約情報から抽出することができる。Ｎｏ．１０の「入院日が契約情報の保険期間内か」の項目に対する項目値には、請求情報として取得した入院日（顧客が請求情報入力画面で入力した入院日）が、契約情報の保険期間に含まれる場合には、項目値のフィールドに“期間内”を登録し、含まれない場合には“期間外”を登録することができる。

また、Ｎｏ．１１の「初年度契約日から入院日までの経過日数」とＮｏ．１２の「初年度契約日から発病日までの経過日数」に対する項目値は、請求情報に含まれる入院日および発病日（顧客が請求情報入力画面で入力した入院日および発病日）と、契約情報の初年度契約日とから算出した値を登録することができる。

Ｎｏ．１３の「部位症状（ケガ）」～Ｎｏ．１５の「病名」の項目に対する項目値は、請求情報から取得することができる。

Ｎｏ．１６の「氏名と被保険者とが一致」の項目に対する項目値には、書類記載情報の氏名と契約情報の被保険者の情報が一致する場合には、「氏名一致」を登録し、一致しない場合には「氏名不一致」を登録することができる。

Ｎｏ．１７の「入院期間が契約情報の保険期間内か」の項目に対する項目値には、書類記載情報に含まれる入院期間が、契約情報から取得した保険期間に含まれる場合には、“期間内”を登録し、含まれない場合には“期間外”を登録することができる。

Ｎｏ．１８の「入院日数」～Ｎｏ．２１の「患者負担割合」の項目に対する項目値は、書類記載情報から取得することができる。Ｎｏ．２２の「精神科専門療法の点数記載」の項目に対する項目値は、書類記載情報にデータが存在すれば“記載あり”とし、データが存在しなければ“記載なし”とすることができる。

このように、判定項目には、査定業務担当者が請求を査定するときに確認する項目や、注意する項目を設定すればよい。また、当該判定項目に対する重み係数は、査定業務担当者が当該判定項目をどの程度重要視しているのかに基づいて設定すればよい。これにより査定担当者の経験則、ノウハウを反映した情報に基づいて、請求が支払対象外となる可能性を判定することができる。

なお、上記実施形態では、支払対象外可能性判定部３５は、顧客からの請求が保険金の支払対象外となる可能性を判定していたが、保険金の支払対象外となる可能性は、保険金の支払対象となる可能性と同義である。したがって、支払対象外可能性判定部３５は、請求が保険金の支払対象となる可能性を判定してもよい。また、支払対象外可能性判定部３５が、支払対象となる可能性を判定する場合、判定ＤＢにおいて、「対象外レコード数」のフィールドを「対象レコード数」とし、「対象外率」のフィールドを「対象率」としてもよい。この場合、判定ＤＢ作成部３８は、保険金支払管理テーブルから、保険金の請求に対して保険金が支払われたレコードの件数を「対象レコード数」のフィールドに格納すればよい。また、「対象率」のフィールドには、全レコード数に対する対象レコード数の割合を格納すればよい。

なお、上記実施形態では、顧客の顧客端末６０から受信した書類画像を画像情報処理部３２がＡＩ－ＯＣＲによりテキスト化することにより、書類に記載された情報を取得していたが、これに限られるものではない。例えば、顧客が顧客端末６０において書類に記載された情報を入力することで書類記載情報を判定サーバ３０に提供し、証左として書類を別途保険会社に送付するようにしてもよい。また、保険会社のオペレータが顧客から送付された書類に基づいて、書類に記載された情報を入力することで、書類記載情報を判定サーバ３０に提供してもよい。

また、上記実施形態では、保険金請求に関連する書類が医療費領収書である場合について説明したが、書類は、医療費領収書のほか、家事代行サービス利用領収書、自動車の修理費領収書等、保険金を支払うか否かの査定に必要なものであればこれらに限定されない。

また、上記実施形態において示した契約情報および請求情報に含まれる項目、保険金支払管理テーブルに含まれる項目は単なる例示であって、他の項目が含まれていてもよい。

また、上記実施形態では、判定サーバ３０の判定ＤＢ作成部３８が判定ＤＢを作成していたが、これに限られるものではない。例えば、保険金支払管理サーバ４０が判定ＤＢを作成してもよい。

以上本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形、変更が可能である。

３０ 判定サーバ
３１ 請求情報受信部
３２ 画像情報処理部
３５ 支払対象外可能性判定部
３６ 対応部署決定部
３７ 判定ＤＢ格納部
３８ 判定ＤＢ作成部
６０ 顧客端末
１００ 支払対象外可能性判定システム

Claims (10)

1. 顧客からの保険金の請求情報を取得する第１の取得部と、
   前記保険金の請求に関連する書類に記載された情報を取得する第２の取得部と、
   前記請求情報、前記書類に記載された情報、前記顧客の保険の契約情報、および過去の保険金請求と前記過去の保険金請求に対する保険金の支払い実績とに基づいて作成された統計データに基づいて、前記保険金の請求が保険金の支払対象とならない可能性を判定する判定部と、
   を備える支払対象外可能性判定装置。
2. 前記可能性に基づいて、前記保険金請求に対応する部署を複数の部署の中から決定する決定部を有する、
   請求項１に記載の支払対象外可能性判定装置。
3. 前記第２の取得部は、前記書類の画像をＡＩ－ＯＣＲによりテキスト化することによって、前記書類に記載された情報を取得する、請求項１または２に記載の支払対象外可能性判定装置。
4. 前記統計データは、予め定められた複数の項目と前記複数の項目のそれぞれに登録されている値との組み合わせごとに、前記過去の保険金請求において前記組み合わせに該当する全レコード数と、前記組み合わせに該当するレコード数のうち保険金が支払われなかったレコード数と、前記全レコード数に対する前記保険金が支払われなかったレコード数の割合と、を格納する、
   請求項１から請求項３のいずれか１項に記載の支払対象外可能性判定装置。
5. 前記判定部は、
   前記保険金の請求について、前記請求情報、前記書類に記載された情報、および前記顧客の保険の契約情報を用いて前記予め定められた複数の項目のそれぞれに対する値を取得し、
   前記統計データから、取得した前記予め定められた複数の項目のそれぞれに対する値に対応する前記割合を、取得し、
   前記予め定められた複数の項目のそれぞれに対して設定された重み係数と、前記割合と、を用いて前記保険金の請求が保険金の支払対象とならない可能性を判定する、
   請求項１から請求項４のいずれか１項に記載の支払対象外可能性判定装置。
6. 前記予め定められた項目は、前記請求情報、前記契約情報、および前記書類に記載された情報のいずれかに含まれる項目である、請求項１から請求項５のいずれか１項記載の支払対象外可能性判定装置。
7. 前記予め定められた項目は、前記過去の保険金の請求情報、契約情報、および書類に記載された情報に含まれる項目を複数用いた項目である、請求項１から請求項６のいずれか１項記載の支払対象外可能性判定装置。
8. 前記統計データを生成する統計データ生成部を備える、請求項１から請求項７のいずれか１項記載の支払対象外可能性判定装置。
9. 顧客から保険金の請求情報の入力を受け付ける受付部と、前記保険金の請求に関連する書類の画像を取得する第１取得部と、前記請求情報と前記書類の画像とを送信する送信部と、を有する第１の装置と、
   前記書類の画像から前記書類に記載された情報を取得する第２取得部と、前記請求情報、前記書類に記載された情報、前記顧客の保険の契約情報、および過去の保険金請求と前記過去の保険金請求に対する保険金の支払い実績とに基づいて作成された統計データに基づいて、前記保険金の請求が保険金の支払対象とならない可能性を判定する判定部と、を有する第２の装置と、
   を備える支払対象外可能性判定システム。
10. 顧客からの保険金の請求情報を取得するステップと、
    前記保険金の請求に関連する書類に記載された情報を取得するステップと、
    前記請求情報、前記書類に記載された情報、前記顧客の保険の契約情報、および過去の保険金請求と前記過去の保険金請求に対する保険金の支払い実績とに基づいて作成された統計データに基づいて、前記保険金の請求が保険金の支払対象とならない可能性を判定するステップと、
    をコンピュータが実行する支払対象外可能性判定方法。
    
    
    

Images