特開 2023-141652 保険金支払査定支援プログラム、保険金支払査定支援方法及び情報処理装置

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

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

(11)【公開番号】P2023141652

(43)【公開日】2023-10-05

(54)【発明の名称】保険金支払査定支援プログラム、保険金支払査定支援方法及び情報処理装置

(51)【国際特許分類】

   G06Q 40/08 20120101AFI20230928BHJP

【ＦＩ】

G06Q40/08

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2022048083

(22)【出願日】2022-03-24

(71)【出願人】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】100087480

【弁理士】

【氏名又は名称】片山 修平

(72)【発明者】

【氏名】佐藤 孝史

(72)【発明者】

【氏名】藺牟田 隼人

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

5L055

【Ｆターム（参考）】

5L055BB61

(57)【要約】

【課題】保険金の支払査定において用いる照会用のデータを簡易に取得する。
【解決手段】連携サーバ１０は、保険会社端末３０から保険金の支払査定において用いる照会用データの取得依頼を受信し（図７の（３））、レセプトのデータを記憶する医療機関サーバ４０から、取得依頼に含まれる患者を特定する情報と、取得依頼に含まれる保険金の支払請求の対象の診療行為を特定する情報と、に対応するデータを照会用データとして取得し（図７の（４）～（６））、保険会社端末３０に対して、照会用のデータを送信する（図７の（７））。
【選択図】図７

【特許請求の範囲】

【請求項1】

保険金の支払査定において用いる照会用のデータの取得依頼を受信し、
診療行為に応じて作成された書面のデータを記憶する記憶部から、前記取得依頼に含まれる患者を特定する情報と、前記取得依頼に含まれる前記保険金の支払請求の対象の診療行為を特定する情報と、に対応するデータを前記照会用のデータとして取得し、
前記取得依頼の送信元に対して、前記照会用のデータを送信する、
処理をコンピュータに実行させることを特徴とする保険金支払査定支援プログラム。

【請求項2】

取得した前記照会用のデータを用いて、支払査定に必要な報告書を作成し、作成した前記報告書を前記送信元に送信する処理を前記コンピュータに更に実行させることを特徴とする請求項１に記載の保険金支払査定支援プログラム。

【請求項3】

前記保険金の支払査定は、特約対象の病気以外に対して行われる簡易査定であり、
前記取得する処理において、前記記憶部に記憶されている診療報酬明細書のデータのうち、前記取得依頼に含まれる患者を特定する情報と、前記取得依頼に含まれる前記保険金の支払請求の対象の診療行為を特定する情報と、に対応するデータを前記照会用のデータとして取得する、ことを特徴とする請求項１又は２に記載の保険金支払査定支援プログラム。

【請求項4】

前記保険金の支払請求の対象の診療行為を特定する情報には、医療機関の識別情報と、医科の識別情報と、診療日の情報と、が含まれることを特徴とする請求項３に記載の保険金支払査定支援プログラム。

【請求項5】

保険金の支払査定において用いる照会用のデータの取得依頼を受信し、
診療行為に応じて作成された書面のデータを記憶する記憶部から、前記取得依頼に含まれる患者を特定する情報と、前記取得依頼に含まれる前記保険金の支払請求の対象の診療行為を特定する情報と、に対応するデータを前記照会用のデータとして取得し、
前記取得依頼の送信元に対して、前記照会用のデータを送信する、
処理をコンピュータが実行することを特徴とする保険金支払査定支援方法。

【請求項6】

保険金の支払査定において用いる照会用のデータの取得依頼を受信する受信部と、
診療行為に応じて作成された書面のデータを記憶する記憶部から、前記取得依頼に含まれる患者を特定する情報と、前記取得依頼に含まれる前記保険金の支払請求の対象の診療行為を特定する情報と、に対応するデータを前記照会用のデータとして取得する取得部と、
前記取得依頼の送信元に対して、前記照会用のデータを送信する送信部と、
を備える情報処理装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、保険金支払査定支援プログラム、保険金支払査定支援方法及び情報処理装置に関する。

【背景技術】

【0002】

医療保険や傷害保険などの保険は、病気やケガになった際の経済的なリスクに備える保障が用意されている。保険会社では、契約者（患者）が保険金請求書等により申告する傷病名や手術名等に対して、医師が発行する診断書等により傷病名や手術名等を確認して、契約時の約款に照らし合わせて、保険金を支払うか否かを判断する。

【0003】

保険会社では、傷病名や手術名等に応じた保険金を支払うために、その傷病名や手術名等に関するエビデンスとして、契約者（患者）に医師が発行する診断書等の提出を求める場合が多い。現状、３大疾病などの特約対象の病気であれば、保険会社は「診断書査定」と呼ばれる査定を行うために、契約者（患者）に診断書の提出を求めている。一方、特約対象の病気以外の場合、保険会社は「簡易査定」と呼ばれる査定を行うために、契約者（患者）に医療機関の領収書のコピーと保険薬局の領収書のコピーの提出を求めている。

【0004】

なお、従来においては、契約者が診断書なしで保険金の請求を可能にするため、受診時医療機関にて作成された診療明細書に基づいて、該当する傷病名を導出し、保険金の支払い可否を判断するシステムが知られている（特許文献１等参照）。

【先行技術文献】

【特許文献】

【0005】

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

【発明の概要】

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

【0006】

しかしながら、特許文献１に開示されているシステムでは、契約者（患者）が、契約者端末から診療明細書の画像データを提出したり、診療明細書を郵送等で提出することとなっており、契約者にとって手間がかかる。

【0007】

１つの側面では、本発明は、保険金の支払査定において用いる照会用のデータを簡易に取得することを可能にする保険金支払査定支援プログラム、保険金支払査定支援方法及び情報処理装置を提供することを目的とする。

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

【0008】

一つの態様では、保険金支払査定支援プログラムは、保険金の支払査定において用いる照会用のデータの取得依頼を受信し、診療行為に応じて作成された書面のデータを記憶する記憶部から、前記取得依頼に含まれる患者を特定する情報と、前記取得依頼に含まれる前記保険金の支払請求の対象の診療行為を特定する情報と、に対応するデータを前記照会用のデータとして取得し、前記取得依頼の送信元に対して、前記照会用のデータを送信する、処理をコンピュータに実行させるプログラムである。

【発明の効果】

【0009】

保険金の支払査定において用いる照会用のデータを簡易に取得することができる。

【図面の簡単な説明】

【0010】

【図1】一実施形態に係る保険金支払査定システムの構成を概略的に示す図である。

【図2】図２（ａ）は、連携サーバのハードウェア構成を示す図であり、図２（ｂ）は、保険会社端末及び医療機関サーバのハードウェア構成を示す図である。

【図3】連携サーバ、保険会社サーバ、医療機関サーバの機能ブロック図である。

【図4】連携サーバの処理を示すフローチャートである。

【図5】入院手術通院状況報告書の一例を示す図である。

【図6】レセプトの一例を示す図である。

【図7】一実施形態の概要を示す図である。

【図8】変形例を示す図である。

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

【0011】

以下、保険金支払査定システムの一実施形態について、図１～図７に基づいて詳細に説明する。本実施形態の保険金支払査定システムは、保険会社における保険金の支払査定作業を支援するシステムである。支払査定には、保険契約者の病気が３大疾病などの特約対象の病気である場合の「診断書査定」と、それ以外の病気である場合の「簡易査定」とがある。本実施形態の保険金支払査定システムは、保険会社の担当者が簡易査定を行う際に、担当者が利用する端末に対して、支払査定に必要なエビデンスとしての照会用データを提供するものである。

【0012】

図１には、一実施形態に係る保険金支払査定システム１００の構成が概略的に示されている。図１に示すように、保険金支払査定システム１００は、情報処理装置としての連携サーバ１０と、保険会社端末３０と、医療機関サーバ４０と、を備える。保険会社端末３０は、インターネットなどのネットワークＮ１に接続されており、医療機関サーバ４０は、地域医療ネットワークなどのネットワークＮ２に接続されている。なお、各ネットワークＮ１，Ｎ２においては、ＳＳＬ（Secure Sockets Layer）やＶＰＮ（Virtual Private Network）等を用いているため、情報漏洩や傍受の可能性が極めて低くなっている。

【0013】

連携サーバ１０は、ネットワークＮ１，Ｎ２のいずれにも接続されており、保険会社端末３０と医療機関サーバ４０との間のデータのやり取り等を行う。より具体的には、連携サーバ１０は、保険会社端末３０から簡易査定に用いる照会用データの取得依頼を受信した場合に、医療機関サーバ４０に対して照会用データを要求し、医療機関サーバ４０から受信した照会用データを保険会社端末３０に送信する。

【0014】

図２（ａ）には、連携サーバ１０のハードウェア構成が示されている。連携サーバ１０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、ストレージ（ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive））９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。これら連携サーバ１０の構成各部は、バス９８に接続されている。連携サーバ１０では、ＲＯＭ９２あるいはストレージ９６に格納されているプログラム（保険金支払査定支援プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラムをＣＰＵ９０が実行することにより、図３に示す各部の機能が実現される。なお、図３の連携サーバ１０の各部の機能は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。図３の各部の詳細については、後述する。

【0015】

図１に戻り、保険会社端末３０は、保険会社の担当者が利用する端末であり、連携サーバ１０に対して簡易査定に用いる照会用データの取得依頼を送信したり、連携サーバ１０から照会用データを受信して表示する機能を有する。

【0016】

保険会社端末３０は、図２（ｂ）に示すようなハードウェア構成を有する。具体的には、保険会社端末３０は、ＣＰＵ１９０、ＲＯＭ１９２、ＲＡＭ１９４、ストレージ１９６、ネットワークインタフェース１９７、表示部１９３、入力部１９５、及び可搬型記憶媒体１９１に記憶されたデータ等を読み取り可能な可搬型記憶媒体用ドライブ１９９等を備えている。表示部１９３は、液晶ディスプレイ等を含み、入力部１９５は、キーボードやマウス、タッチパネル等を含む。これら保険会社端末３０の構成各部は、バス１９８に接続されている。保険会社端末３０では、ＣＰＵ１９０がプログラムを実行することにより、図３に示す各部としての機能が実現されている。

【0017】

医療機関サーバ４０は、医療機関に勤務する医師等の医療従事者が利用する利用者端末とＬＡＮ（Local Area Network）等で接続されている。医療機関サーバ１０は、利用者端末で作成された診療報酬明細書（「レセプト」と呼ぶ）のデータを、レセプトＤＢ４６（図３参照）で管理する情報処理装置である。レセプトは、図６に示すような書類であり、１か月ごとに発行される。レセプトには、患者の氏名や生年月日、傷病名、診療開始日、転帰（治癒、死亡、中止）、診療に関する情報、入院に関する情報などが含まれる。なお、レセプトＤＢ４６には、レセプトには記載されていない情報も格納される場合がある。例えば、レセプトＤＢ４６には、レセプトに記載されている各診療を行った医科の情報や日付の情報が紐づけて格納されている。なお、レセプトは、出来高レセプト、ＤＰＣ（Diagnosis Procedure Combination）制度に対応したＤＰＣレセプトのいずれであってもよい。ＤＰＣ制度は、包括医療費支払い制度と呼ばれる制度であり、入院医療費の計算方式として、疾患や診療内容（診断群分類区分）によって決められた１日あたりの定額料金を基に医療費を計算する方式（包括払い方式）が採用された制度である。ＤＰＣ制度は、厚生労働省によって、医療の質の標準化を図ることを目的として導入された制度である。

【0018】

医療機関サーバ４０は、一例として、保険会社端末３０と同様のハードウェア構成（図２（ｂ））を有する。医療機関サーバ４０では、ＣＰＵ１９０がプログラムを実行することにより、図３に示す各部としての機能が実現されている。なお、図３の医療機関サーバ４０の各部の機能は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現されてもよい。

【0019】

図３には、保険会社端末３０、連携サーバ１０、医療機関サーバ４０の機能ブロック図が示されている。

【0020】

（保険会社端末３０の機能について）
保険会社端末３０は、図３に示すように、取得依頼送信部３２と、照会用データ受信部３４と、を有する。保険会社の担当者が「簡易査定」を行う場合、照会用データの取得要求を入力する。この取得要求の際に、担当者は、所定の情報（契約者（患者）を特定する情報や、対象の診療行為を特定する情報）を入力する。なお、患者を特定する情報は、患者の識別情報（患者ＩＤなど）を含む。また、対象の診療行為を特定する情報は、医療機関の識別情報（病院コードなど）、医科の識別情報（医科コードなど）、診療を受けた日の情報を含む。なお、保険会社の担当者は、契約者（患者）から提出された、契約者自らが記載した「入院手術通院状況報告書」（図５参照）を参照して、保険会社端末３０に上記所定の情報を入力する。

【0021】

取得依頼送信部３２は、保険会社の担当者から照会用データの取得要求（上記所定の情報を含む）が入力されると、照会用データの取得依頼を連携サーバ１０に送信する。

【0022】

照会用データ受信部３４は、連携サーバ１０から照会用データが送信されてきた場合に、当該照会用データを受信し、表示部１９３上に表示する。

【0023】

（連携サーバ１０の機能について）
連携サーバ１０は、図３に示すように、受信部としての取得依頼受信部１２、医療機関特定部１４、照会用データ依頼部１６、照会用データ取得部１８、保険会社特定部２０、送信部としての照会用データ送信部２２を有する。

【0024】

取得依頼受信部１２は、保険会社端末３０の取得依頼送信部３２から送信されてきた取得依頼を受信する。医療機関特定部１４は、取得依頼に含まれる医療機関の識別情報（病院コードなど）を確認し、どの医療機関サーバ４０に対して照会用データを依頼するのかを特定する。照会用データ依頼部１６は、医療機関特定部１４によって特定された医療機関サーバ４０に対して、照会用データを依頼する処理を実行する。このとき、照会用データ依頼部１６は、医療機関サーバ４０に対して、取得依頼に含まれる患者の識別情報（患者ＩＤなど）や、医科の識別情報（医科コード）、診療を受けた日の情報を送信する。

【0025】

照会用データ取得部１８は、医療機関サーバ４０から送信されてきた照会用データを取得する。保険会社特定部２０は、取得した照会用データをどの保険会社端末３０に送信すべきかを特定する。具体的には、保険会社特定部２０は、取得した照会用データがどの患者のデータであるかを特定し、直前に当該患者の照会用データの取得依頼を送信してきた保険会社端末３０を特定する。照会用データ送信部２２は、保険会社特定部２０が特定した保険会社端末３０に対して、照会用データを送信する。

【0026】

（医療機関サーバ４０の機能について）
医療機関サーバ４０は、図３に示すように、依頼受付部４２と、データ抽出部４４と、を有する。なお、医療機関サーバ４０は、前述のように、レセプトのデータをレセプトＤＢ４６において管理している。

【0027】

依頼受付部４２は、連携サーバ１０の照会用データ依頼部１６から照会用データの取得依頼があると、当該取得依頼を受け付け、取得依頼に含まれる情報（患者の識別情報や、医科の識別情報、診療を受けた日の情報）をデータ抽出部４４に対して通知する。

【0028】

データ抽出部４４は、依頼受付部４２からの通知があると、レセプトＤＢ４６を参照し、患者の識別情報に対応するレセプトのデータを特定する。また、データ抽出部４４は、取得したレセプトのデータのうち、医科の識別情報、診療を受けた日に対応するデータを抽出して、抽出したデータを照会用データとする。データ抽出部４４は、照会用データを連携サーバ１０に対して送信する。

【0029】

（連携サーバ１０の処理について）
次に、図４のフローチャートに沿って、連携サーバ１０の処理について詳細に説明する。

【0030】

図４の処理が開始されると、まず、ステップＳ１０において、取得依頼受信部１２が、照会用データの取得依頼があるまで待機する。保険会社端末３０の取得依頼送信部３２から、取得依頼とともに、保険会社の担当者が入力した情報（患者の識別情報や医療機関の識別情報、医科の情報、及び診療日の情報）が送信されてくると、取得依頼受信部１２は、ステップＳ１２に移行する。

【0031】

ステップＳ１２に移行すると、取得依頼受信部１２は、取得依頼を受信し、医療機関特定部１４に通知する。

【0032】

次いで、ステップＳ１４では、医療機関特定部１４が、取得依頼に含まれる医療機関の識別情報から、照会用データを依頼する医療機関を特定し、照会用データ依頼部１６に通知する。

【0033】

次いで、ステップＳ１６では、照会用データ依頼部１６が、医療機関特定部１４が特定した医療機関の医療機関サーバ４０に対し、取得依頼に含まれる情報（患者の識別情報、医科の情報、及び診療日の情報）を送信する。これにより、照会用データ依頼部１６は、医療機関サーバ４０に対して、簡易査定用の照会用データを依頼する。

【0034】

医療機関サーバ４０においては、依頼受付部４２が、患者の識別情報、医科の情報、及び診療日の情報をデータ抽出部４４に通知する。そして、データ抽出部４４は、レセプトＤＢ４６を参照して、患者の識別情報に対応するレセプトのデータを特定する。ここで、レセプトは、１か月分の診療行為がまとめて記載されている書類であるため、患者が複数の傷病で通院していた場合、レセプトを見ただけでは、保険金請求の対象である医療行為と診療点数がどれであるかを判別することが難しい。これに対し、本実施形態では、前述したように、レセプトＤＢ４６において、レセプトに記載されている各診療行為のデータを、医科の識別情報及び診療日の情報と紐づけて格納している。したがって、データ抽出部４４は、患者の識別情報に対応するレセプトのデータのうち、医科の識別情報と診療日の情報とに対応するデータを簡易査定に用いる照会用データとして抽出する。データ抽出部４４は、抽出した照会用データを、連携サーバ１０に送信する。

【0035】

ステップＳ１６の後は、ステップＳ１８において、照会用データ取得部１８が、照会用データが医療機関サーバ４０から送信されてくるまで待機している。したがって、照会用データ取得部１８は、データ抽出部４４から照会用データが送信されてくると、ステップＳ２０に移行し、照会用データを取得する。

【0036】

次いで、ステップＳ２２では、保険会社特定部２０が、どの保険会社に照会用データを送信すべきかを特定する。この場合、保険会社特定部２０は、照会用データに含まれている患者の識別情報に基づいて、当該患者についての照会用データの取得依頼を送信してきた保険会社端末３０を特定する。保険会社特定部２０は、特定した保険会社端末３０の情報を照会用データ送信部２２に通知する。

【0037】

次いで、ステップＳ２４では、照会用データ送信部２２が、特定した保険会社端末３０に対して、照会用データを送信する。なお、保険会社端末３０においては、照会用データ受信部３４が照会用データを受信し、保険会社端末３０の表示部１９３上に照会用データを表示する。これにより、保険会社の担当者は、照会用データをエビデンスとして用いて、契約者（患者）への保険金の支払査定（簡易査定）を行うことができる。

【0038】

なお、本実施形態では、照会用データ依頼部１６と、照会用データ取得部１８とにより、医療機関サーバ４０から、取得依頼に対応するレセプトのデータを照会用データとして取得する取得部としての機能が実現されている。

【0039】

図７には、本実施形態の概要が模式的に示されている。図７に示すように、本実施形態では、（１）契約者（患者）が保険金支払を受けるために、入院手術通院状況報告書（図５）を提出する。次いで、（２）保険会社の担当者は、入院手術通院状況報告書を見ながら、照会用データの取得要求を入力する。（３）保険会社端末３０は、入力された取得要求を連携サーバ１０に送信する。（４）連携サーバ１０は、取得依頼を受信し（図４のＳ１２）、レセプトのデータを管理する医療機関サーバ４０に照会用データの取得依頼を送信する。（５）医療機関サーバ４０は、取得依頼に対応するデータを照会用データとして抽出し（６）連携サーバ１０に照会用データを送信するので、連携サーバ１０は、照会用データを取得する（図４のＳ２０）。そして、（７）連携サーバ１０は、取得した照会用データを保険会社端末３０に対して送信する（図４のＳ２４）。これにより、（８）保険会社端末３０の表示部１９３には、契約者（患者）のレセプトのデータが照会用データとして表示される。したがって、保険会社の担当者は、照会用データをエビデンスとして用いて、簡易査定を行うことができる。この場合、契約者（患者）は、レセプト（書類）を保険会社に郵送等により提出したり、レセプトの電子データを保険会社端末３０に送ったりする必要が無いため、契約者（患者）の手間を削減することができる。なお、従来は、簡易査定に医療機関や保険薬局が発行する領収書を用いていたが、レセプトには、領収書に記載されている情報が網羅されているので、レセプトのデータを簡易査定のエビデンスとして用いても問題はない。また、保険会社の担当者は、照会用データの取得要求を行う場合（図７の（２））、医療機関の識別情報のほか、医科の識別情報や診療日の情報を入力する。このため、医療機関サーバ４０では、レセプトの中に複数の傷病に対する診療行為の情報が含まれている場合であっても、保険対象の診療行為や病名のデータを照会用データとして抽出することができる。

【0040】

なお、上記実施形態では、連携サーバ１０は、照会用データを医療機関サーバ４０から取得した場合に、取得した照会用データをそのまま保険会社端末３０に送信する場合について説明したが、これに限られるものではない。例えば、図８に示すように、連携サーバ１０は、報告書作成部２４の機能を有していてもよい。報告書作成部２４は、照会用データ取得部１８が取得した照会用データに基づいて、入院手術通院状況報告書（図５参照）を作成する。この場合、照会用データ送信部２２は、報告書作成部２４が作成した入院手術通院状況報告書とともに、エビデンスとしての照会用データを保険会社端末３０に送信する。このようにすることで、契約者（患者）は、入院手術通院状況報告書に記入する必要がなくなり、保険会社の担当者に照会用データを取得するために必要な情報（患者の識別情報など）を伝えるだけでよくなる。なお、図８の例の場合、報告書作成部２４と、照会用データ送信部２２と、により、照会用データを用いて、支払査定に必要な報告書を作成し、作成した報告書を保険会社端末３０に送信する作成部としての機能が実現されている。

【0041】

なお、上記実施形態では、連携サーバ１０は、保険会社が「簡易査定」を行う場合に、エビデンスとしてレセプトのデータを提供する場合について説明したが、これに限られるものではない。例えば、「診断書査定」において、将来、レセプトのデータをエビデンスとして用いてもよいという運用になった場合には、当該「診断書査定」においても、上記実施形態と同様にして、保険会社端末３０に照会用データを提供すればよい。

【0042】

なお、上記実施形態では、保険会社端末３０に対して、照会用データとしてレセプトのデータを送信する場合について説明したが、これに限られるものではない。照会用データとして用いることが可能なデータ（診療行為に応じて作成されるデータ）がある場合には、当該データの少なくとも一部を照会用データとして保険会社端末３０に提供することとしてもよい。照会用データとして用いることが可能なデータとしては、例えば、ＤＰＣ制度導入の影響評価に係る調査ファイルなどが想定される。

【0043】

なお、上記実施形態では、保険会社端末３０が接続されたネットワークと、医療機関サーバ４０が接続されたネットワークと、が異なる場合について説明した。しかしながら、これに限られるものではなく、例えば、保険会社端末３０と医療機関サーバ４０が、同一のネットワークに接続されていてもよい。

【0044】

なお、上記実施形態では、レセプトのデータを医療機関サーバ４０が管理する場合について説明したが、これに限られるものではない。例えば、連携サーバ１０が、レセプトのデータを医療機関サーバ４０等から取得して、連携サーバ１０の記憶部において管理してもよい。この場合、連携サーバ１０は、照会用データの取得要求を保険会社端末３０から取得すると、取得要求に対応するレセプトのデータを記憶部から抽出して、保険会社端末３０に送信するようにすればよい。

【0045】

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記憶媒体（ただし、搬送波は除く）に記録しておくことができる。

【0046】

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記憶媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

【0047】

プログラムを実行するコンピュータは、例えば、可搬型記憶媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記憶媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

【0048】

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

【0049】

なお、以上の実施形態の説明に関して、更に以下の付記を開示する。
（付記１） 保険金の支払査定において用いる照会用のデータの取得依頼を受信し、
診療行為に応じて作成された書面のデータを記憶する記憶部から、前記取得依頼に含まれる患者を特定する情報と、前記取得依頼に含まれる前記保険金の支払請求の対象の診療行為を特定する情報と、に対応するデータを前記照会用のデータとして取得し、
前記取得依頼の送信元に対して、前記照会用のデータを送信する、
処理をコンピュータに実行させることを特徴とする保険金支払査定支援プログラム。
（付記２） 取得した前記照会用のデータを用いて、支払査定に必要な報告書を作成し、作成した前記報告書を前記送信元に送信する処理を前記コンピュータに更に実行させることを特徴とする付記１に記載の保険金支払査定支援プログラム。
（付記３） 前記保険金の支払査定は、特約対象の病気以外に対して行われる簡易査定であり、
前記取得する処理において、前記記憶部に記憶されている診療報酬明細書のデータのうち、前記取得依頼に含まれる患者を特定する情報と、前記取得依頼に含まれる前記保険金の支払請求の対象の診療行為を特定する情報と、に対応するデータを前記照会用のデータとして取得する、ことを特徴とする付記１又は２に記載の保険金支払査定支援プログラム。
（付記４） 前記保険金の支払請求の対象の診療行為を特定する情報には、医療機関の識別情報と、医科の識別情報と、診療日の情報と、が含まれることを特徴とする付記３に記載の保険金支払査定支援プログラム。
（付記５） 保険金の支払査定において用いる照会用のデータの取得依頼を受信し、
診療行為に応じて作成された書面のデータを記憶する記憶部から、前記取得依頼に含まれる患者を特定する情報と、前記取得依頼に含まれる前記保険金の支払請求の対象の診療行為を特定する情報と、に対応するデータを前記照会用のデータとして取得し、
前記取得依頼の送信元に対して、前記照会用のデータを送信する、
処理をコンピュータが実行することを特徴とする保険金支払査定支援方法。
（付記６） 保険金の支払査定において用いる照会用のデータの取得依頼を受信する受信部と、
診療行為に応じて作成された書面のデータを記憶する記憶部から、前記取得依頼に含まれる患者を特定する情報と、前記取得依頼に含まれる前記保険金の支払請求の対象の診療行為を特定する情報と、に対応するデータを前記照会用のデータとして取得する取得部と、
前記取得依頼の送信元に対して、前記照会用のデータを送信する送信部と、
を備える情報処理装置。
（付記７） 前記取得部が取得した前記照会用のデータを用いて、支払査定に必要な報告書を作成し、作成した前記報告書を前記送信元に送信する作成部を更に備える付記６に記載の情報処理装置。
（付記８） 前記保険金の支払査定は、特約対象の病気以外に対して行われる簡易査定であり、
前記取得部は、前記記憶部に記憶されている診療報酬明細書のデータのうち、前記取得依頼に含まれる患者を特定する情報と、前記取得依頼に含まれる前記保険金の支払請求の対象の診療行為を特定する情報と、に対応するデータを前記照会用のデータとして取得する、ことを特徴とする付記６又は７に記載の情報処理装置。
（付記９） 前記保険金の支払請求の対象の診療行為を特定する情報には、医療機関の識別情報と、医科の識別情報と、診療日の情報と、が含まれることを特徴とする付記８に記載の情報処理装置。

【符号の説明】

【0050】

１０ 連携サーバ（情報処理装置）
１２ 取得依頼受信部（受信部）
１６ 照会用データ依頼部（取得部の一部）
１８ 照会用データ取得部（取得部の一部）
２２ 照会用データ送信部（送信部、作成部の一部）
２４ 報告書作成部（作成部の一部）
４０ 医療機関サーバ（記憶部）
４６ レセプトＤＢ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】