JP2018156199A - プログラム、情報処理装置及び情報処理方法 - Google Patents

Abstract

【課題】医療費の負担軽減を支援する。【解決手段】ユーザ識別情報と、予定している受診について想定される想定医療費との入力を受け付け、ユーザ毎の医療費を記憶する第１の記憶部と、医療費を合算する対象のユーザを記憶する第２の記憶部とを参照して、月毎に、受け付けた前記ユーザ識別情報のユーザと医療費を合算するユーザの医療費と、前記想定医療費との合計を算出し、算出した前記合計が、医療費の限度額を超える月を出力する、処理をコンピュータに実行させるためのプログラムが提供される。【選択図】図１４

Description

本発明は、プログラム、情報処理装置及び情報処理方法に関する。

高額療養費制度と呼ばれる制度が知られている。高額医療保険制度は、公的医療保険における制度の一つであり、保険医療機関や薬局の窓口で支払った額が歴月（月の初めから終わりまで）で一定額を超えた場合に、その超えた金額を支給する制度である。

従来では、高額療養費制度の申請や同一世帯単位での医療費控除等の申請を簡易に行う技術が知られている（例えば特許文献１参照）。

特開２０１３−２５７６１８号公報

ここで、高額療養費制度では、年齢や所得等に応じて、支払う医療費の上限（自己負担限度額）が決められる仕組みとなっている。また、世帯合算や多数回該当等、支払う医療費の負担を更に軽減するための仕組みも設けられている。一般に、これらの仕組みの全てを理解している利用者は少ない。一方で、高額療養費制度を上手に利用することで、医療費の負担を効果的に軽減させることができる場合がある。

例えば、同一世帯内に保険医療機関の受診が定期的に必要な慢性疾患等を有する家族がいるような場合に、自身が保険医療機関を受診する月を、慢性疾患等を有する家族と同一月とすることで、世帯合算により、医療費の負担を軽減させることができる場合がある。

開示の技術は、医療費の負担軽減を支援することを目的とする。

開示の技術は、ユーザ識別情報と、予定している受診について想定される想定医療費との入力を受け付け、ユーザ毎の医療費を記憶する第１の記憶部と、医療費を合算する対象のユーザを記憶する第２の記憶部とを参照して、月毎に、受け付けた前記ユーザ識別情報のユーザと医療費を合算するユーザの医療費と、前記想定医療費との合計を算出し、算出した前記合計が、医療費の限度額を超える月を出力する、処理をコンピュータに実行させる。

医療費の負担軽減を支援することができる。

本実施形態に係る受診シミュレーション装置の構成の一例を示す図である。 本実施形態に係る受診シミュレーション装置のハードウェア構成の一例を示す図である。 受診予定情報ＤＢの一例を示す図である。 受診実績情報ＤＢの一例を示す図である。 世帯情報ＤＢの一例を示す図である。 本実施形態に係る受診シミュレーション処理部の機能構成の一例を示す図である。 世帯情報を登録する処理の一例を示すフローチャートである。 世帯情報の登録画面の一例を示す図である。 受診予定情報を登録する処理の一例を示すフローチャートである。 受診予定情報の登録画面の一例を示す図である。 受診実績情報を登録する処理の一例を示すフローチャートである。 受診実績情報の登録画面の一例を示す図である。 高額療養費制度の適用をシミュレーションする処理の一例を示すフローチャートである。 シミュレーション画面の一例を示す図である。 受診候補月を特定する処理の一例を示すフローチャートである。 超過月テーブルの一例を示す図である。 限度額テーブルの一例を示す図である。 受診候補月を特定する処理の他の例を示すフローチャートである。

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

＜受診シミュレーション装置１０の構成＞
まず、本実施形態に係る受診シミュレーション装置１０の構成について、図１を参照しながら説明する。図１は、本実施形態に係る受診シミュレーション装置１０の構成の一例を示す図である。

図１に示す受診シミュレーション装置１０は、ユーザが所望する受診予定日が高額療養費制度の適用を受けることができる月であるか否かをシミュレーションするコンピュータである。受診シミュレーション装置１０には、ＰＣ（パーソナルコンピュータ）が用いられる。ただし、受診シミュレーション装置１０は、例えば、スマートフォンやタブレット端末、携帯電話等が用いられても良い。

図１に示すように、本実施形態に係る受診シミュレーション装置１０は、受診シミュレーション処理部１００と、受診予定情報ＤＢ２００と、受診実績情報ＤＢ３００と、世帯情報ＤＢ４００とを有する。

受診予定情報ＤＢ２００は、ユーザの受診予定を示す受診予定情報データが格納されたＤＢ（データベース）である。受診実績情報ＤＢ３００は、ユーザの受診実績を示す受診実績データが格納されたＤＢである。世帯情報ＤＢ４００は、ユーザの世帯に関する情報を示す世帯情報データが格納されたＤＢである。これらの各ＤＢの詳細については後述する。

受診シミュレーション処理部１００は、受診予定情報ＤＢ２００と、受診実績情報ＤＢ３００と、世帯情報ＤＢ４００とを参照して、ユーザが所望する受診予定日が高額療養費制度の適用を受けることができる月であるか否かをシミュレーションする。すなわち、受診シミュレーション処理部１００は、ユーザが受診を予定する月における同一世帯内の医療費の合計が、高額療養費制度で定められた自己負担限度額を超えているかを判定する。そして、受診シミュレーション処理部１００は、高額療養費制度で定められた自己負担限度額を超えていると判定された月（すなわち、高額療養費制度の適用を受けることができる月）を受診候補月として出力する。高額療養費制度の適用を受けることができる月とは、高額療養費制度により医療費の自己負担を軽減することができる月である。以降では、自己負担限度額を、単に「限度額」とも表す。なお、医療費には、保険医療機関における診察や治療等に要する費用の他、薬局で処方される薬の費用等も含まれる。

なお、同一世帯とは、高額療養費制度で定められた世帯合算を行うことができる世帯人の集合のことである。高額療養費制度では、同一の公的医療保険に加入している被保険者及び被扶養者を同一世帯と定めている。

ユーザは、出力された受診候補月により、自身が受診を予定する受診内容及び受診日が高額療養費制度の適用を受けることができるか否かを知ることができる。また、ユーザは、高額療養費制度の適用を受けることができる他の月（受診を予定する月とは異なる月）を知ることができる。これにより、ユーザは、医療費の負担を軽減するための効果的な受診計画を立てることができるようになる。

なお、図１に示す受診シミュレーション装置１０の構成は一例であって、他の構成であっても良い。例えば、受診予定情報ＤＢ２００と、受診実績情報ＤＢ３００と、世帯情報ＤＢ４００とは、受診シミュレーション装置１０とネットワークを介して接続される他の装置（サーバ装置）が有していても良い。この場合、サーバ装置には、例えば、家族内の複数のユーザがそれぞれ利用する複数台の受診シミュレーション装置１０が接続されても良い。

＜受診シミュレーション装置１０のハードウェア構成＞
次に、受診シミュレーション装置１０のハードウェア構成について、図２を参照しながら説明する。図２は、本実施形態に係る受診シミュレーション装置１０のハードウェア構成の一例を示す図である。

図２に示すように、本実施形態に係る受診シミュレーション装置１０は、入力装置１１と、表示装置１２と、外部Ｉ／Ｆ１３と、通信Ｉ／Ｆ１４と、ＲＯＭ（Read Only Memory）１５とを有する。また、本実施形態に係る受診シミュレーション装置１０は、ＲＡＭ（Random Access Memory）１６と、ＣＰＵ（Central Processing Unit）１７と、補助記憶装置１８とを有する。これら各ハードウェアは、それぞれがバス１９で相互に接続されている。

入力装置１１は、例えばキーボードやマウス、タッチパネル等であり、受診シミュレーション装置１０に各種の操作信号を入力するのに用いられる。表示装置１２は、例えばディスプレイ等であり、受診シミュレーション装置１０による各種の処理結果を表示する。

外部Ｉ／Ｆ１３は、外部装置とのインタフェースである。外部装置には、記録媒体１３ａ等がある。受診シミュレーション装置１０は、外部Ｉ／Ｆ１３を介して、記録媒体１３ａの読み取りや書き込みを行うことができる。記録媒体１３ａには、受診シミュレーション処理部１００を実現する１以上のプログラムが記録されていても良い。

記録媒体１３ａには、例えば、ＳＤメモリカード(SD memory card）やＵＳＢメモリ、ＣＤ（Compact Disk）、ＤＶＤ（Digital Versatile Disk）等がある。

通信Ｉ／Ｆ１４は、受診シミュレーション装置１０をネットワークに接続するためのインタフェースである。受診シミュレーション装置１０は、通信Ｉ／Ｆ１４を介して、他の装置と通信を行うことができる。受診シミュレーション処理部１００を実現する１以上のプログラムは、通信Ｉ／Ｆ１４を介して、他の装置から取得（ダウンロード）されても良い。

ＲＯＭ１５は、電源を切ってもデータを保持することができる不揮発性の半導体メモリである。ＲＡＭ１６は、プログラムやデータを一時保持する揮発性の半導体メモリである。ＣＰＵ１７は、例えば補助記憶装置１８やＲＯＭ１５等からプログラムやデータをＲＡＭ１６上に読み出して、各種処理を実行する演算装置である。

補助記憶装置１８は、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等であり、プログラムやデータを格納している不揮発性のメモリである。補助記憶装置１８に格納されるプログラムやデータには、例えば、基本ソフトウェアであるＯＳ（Operating System）、各種アプリケーション、受診シミュレーション処理部１００を実現する１以上のプログラム等がある。

本実施形態に係る受診シミュレーション装置１０は、図２に示すハードウェア構成を有することにより、後述する各種処理が実現される。

＜受診予定情報ＤＢ２００＞
次に、受診予定情報ＤＢ２００の詳細について、図３を参照しながら説明する。図３は、受診予定情報ＤＢ２００の一例を示す図である。なお、受診予定情報ＤＢ２００は、例えば補助記憶装置１８等を用いて実現可能である。ただし、受診予定情報ＤＢ２００は、受診シミュレーション装置１０とネットワークを介して接続される記憶装置等を用いて実現されていても良い。

図３に示すように、受診予定情報ＤＢ２００には、受診予定情報データが格納されている。受診予定情報データは、データ項目として、受診予定日と、氏名と、医療機関名と、想定医療費と、科名と、入外区分とを有する。

受診予定日は、ユーザが受診を予定している年月日である。氏名は、ユーザの氏及び名である。氏名は、ユーザを識別するユーザ識別情報の一例である。氏名の代わりに、英字や数字等の組み合わせにより構成されるユーザＩＤ等が用いられても良い。以降では、同姓同名のユーザは存在しないものとして、氏名により各ユーザが識別されるものとする。

医療機関名は、ユーザが受診を予定している保険医療機関の名称である。保険医療機関の名称に代えて、例えば、保険医療機関を識別する医療機関ＩＤ等であっても良い。

想定医療費は、ユーザが予定している受診で想定される医療費である。科名は、ユーザが受診を予定している診療科目である。入外区分は、ユーザが予定している受診が外来又は入院のいずれであるかを示す区分である。

このように、受診予定情報ＤＢ２００には、ユーザが予定している受診に関する情報を示す受診予定情報データが格納されている。受診予定情報データは、ユーザが受診シミュレーション装置１０を用いて受診予定情報を登録することで、受診予定情報ＤＢ２００に格納される。

＜受診実績情報ＤＢ３００＞
次に、受診実績情報ＤＢ３００の詳細について、図４を参照しながら説明する。図４は、受診実績情報ＤＢ３００の一例を示す図である。なお、受診実績情報ＤＢ３００は、例えば補助記憶装置１８等を用いて実現可能である。ただし、受診実績情報ＤＢ３００は、受診シミュレーション装置１０とネットワークを介して接続される記憶装置等を用いて実現されていても良い。

図４に示すように、受診実績情報ＤＢ３００には、受診実績情報データが格納されている。受診実績情報データは、データ項目として、受診日と、氏名と、医療機関名と、医療費と、科名と、入外区分とを有する。

受診日は、ユーザが保険医療機関で受診した年月日である。氏名は、ユーザの氏及び名である。

医療機関は、ユーザが受診した保険医療機関の名称である。保険医療機関の名称に代えて、例えば、保険医療機関を識別する医療機関ＩＤ等であっても良い。

医療費は、実際に受診に要した医療費である。科名は、ユーザが受診した診療科目である。入外区分は、ユーザの受診が外来又は入院のいずれであったかを示す区分である。

このように、受診実績情報ＤＢ３００には、ユーザの受診実績に関する情報を示す受診実績情報データが格納されている。受診実績情報データは、ユーザが受診シミュレーション装置１０を用いて受診実績情報を登録することで、受診実績情報ＤＢ３００に格納される。

＜世帯情報ＤＢ４００＞
次に、世帯情報ＤＢ４００の詳細について、図５を参照しながら説明する。図５は、世帯情報ＤＢ４００の一例を示す図である。なお、世帯情報ＤＢ４００は、例えば補助記憶装置１８等を用いて実現可能である。ただし、世帯情報ＤＢ４００は、受診シミュレーション装置１０とネットワークを介して接続される記憶装置等を用いて実現されていても良い。

図５に示すように、世帯情報ＤＢ４００には、世帯情報データが格納されている。世帯情報データは、データ項目として、氏名と、生年月日と、保険種類と、世帯番号と、所得とを有する。

氏名は、ユーザの氏及び名である。生年月日は、ユーザの生年月日である。保険種類は、ユーザが被保険者又は被扶養者として加入している公的医療保険の種類である。世帯番号は、同一世帯を識別する番号である。

ここで、高額療養費制度では、同一の公的医療保険に加入している被保険者及び被扶養者を同一世帯と定めている。したがって、例えば、図５に示す例では、同一の公的医療保険「協会けんぽ」に加入している「山田 太郎」及び「山田 花子」は同一世帯となり、同一の世帯番号「世帯１」となる。また、同様に、同一の公的医療保険「国民健康保険」に加入している「山田 三郎」及び「山田 四郎」は同一世帯となり、同一の世帯番号「世帯２」となる。

所得は、ユーザの所得（収入）である。高額療養費制度では、ユーザの年齢及び所得に応じて医療費の限度額が異なる。

このように、世帯情報ＤＢ４００には、高額療養費制度の世帯合算の対象となるユーザに関する情報と、医療費の限度額を算出するための情報とを示す世帯情報データが格納されている。世帯情報データは、ユーザが受診シミュレーション装置１０を用いて世帯情報を登録することで、世帯情報ＤＢ４００に格納される。

＜受診シミュレーション処理部１００の機能構成＞
次に、受診シミュレーション処理部１００の機能構成について、図６を参照しながら説明する。図６は、本実施形態に係る受診シミュレーション処理部１００の機能構成の一例を示す図である。

図６に示すように、受診シミュレーション処理部１００は、入力部１０１と、出力部１０２と、ＤＢ更新部１０３と、合計算出部１０４と、多数回該当判定部１０５と、限度額取得部１０６と、超過判定部１０７と、候補月特定部１０８とを有する。なお、受診シミュレーション処理部１００は、受診シミュレーション装置１０にインストールされた１以上のプログラムが、ＣＰＵ１７に実行させる処理により実現される。

入力部１０１は、ユーザによる各種入力を受け付ける。例えば、入力部１０１は、受診予定情報の登録操作や受診実績情報の登録操作、世帯情報の登録操作、シミュレーション実行操作等の入力を受け付ける。

出力部１０２は、各種の画面を出力する。例えば、出力部１０２は、受診予定情報を登録するための画面や受診実績情報を登録するための画面、世帯情報を登録するための画面、高額療養費制度の適用をシミュレーションするための画面等を出力する。

ＤＢ更新部１０３は、受診予定情報ＤＢ２００と、受診実績情報ＤＢ３００と、世帯情報ＤＢ４００とを更新する。

例えば、ＤＢ更新部１０３は、入力部１０１が受診予定情報の登録操作の入力を受け付けた場合、当該操作により入力された各情報から受診予定情報データを作成して、受診予定情報ＤＢ２００に格納する。また、例えば、ＤＢ更新部１０３は、入力部１０１が受診実績情報の登録操作の入力を受け付けた場合、当該操作により入力された各情報から受診実績情報データを作成して、受診実績情報ＤＢ３００に格納する。更に、例えば、ＤＢ更新部１０３は、入力部１０１が世帯情報の登録操作の入力を受け付けた場合、当該操作により入力された各情報から世帯情報データを作成して、世帯情報ＤＢ４００に格納する。

合計算出部１０４は、入力部１０１がシミュレーション実行操作の入力を受け付けた場合に、当該操作により入力された想定医療費等の情報から、ある月における同一世帯内の医療費の合計額を算出する。例えば、合計算出部１０４は、現在の月から先の１２か月分における同一世帯内の医療費の月毎の合計額を算出する。

多数回該当判定部１０５は、超過月テーブル５００を参照して、合計算出部１０４により合計額が算出された月が多数回該当の条件を満たすか否かを判定する。超過月テーブル５００は、世帯毎に、直近１２か月の各月における限度額超過の有無（すなわち、高額療養費制度の適用の有無）を示す情報が格納されたテーブルである。超過月テーブル５００は、例えば補助記憶装置１８等に記憶されている。超過月テーブル５００の詳細については後述する。

ここで、多数回該当とは、高額療養費制度により医療費の負担を更に軽減するための仕組みの一つであり、７０歳未満の利用者が、直近１２か月に高額療養費制度の適用を３回以上受けた場合に、４回目以降の限度額が更に引き下げられる仕組みである。したがって、多数回該当月では、利用者の医療費の負担を更に軽減させることができる。

限度額取得部１０６は、多数回該当判定部１０５による判定結果に応じて、合計算出部１０４により合計額が算出された月におけるユーザの限度額を示す情報を、限度額テーブル６００から取得する。限度額テーブル６００は、高額療養費制度の自己負担限度額を示す情報が格納されたテーブルである。限度額テーブル６００は、例えば補助記憶装置１８等に記憶されている。限度額テーブル６００の詳細については後述する。

ここで、上述したように、自己負担限度額は、ユーザの年齢や所得に応じて異なる。また、自己負担限度額は、当該月が多数回該当月であるか否かによっても異なる。限度額取得部１０６は、ユーザの年齢や所得、当該月が多数回該当月であるか否か等に応じて、月毎に、当該ユーザの自己負担限度額を示す情報を限度額テーブル６００から取得する。

超過判定部１０７は、合計算出部１０４により算出された合計額と、限度額取得部１０６により取得された限度額とから、高額療養費制度の適用を受けることができる月であるか否かを判定する。

候補月特定部１０８は、高額療養費制度の適用を受けることができると超過判定部１０７により判定された月、又はこれらの月のうちの所定の月を、受診候補月に特定する。

＜世帯情報の登録＞
次に、ユーザが世帯情報を登録する処理について、図７を参照しながら説明する。図７は、世帯情報を登録する処理の一例を示すフローチャートである。世帯情報の登録は、高額療養費制度の適用をシミュレーションする前に行われる必要がある。

まず、出力部１０２は、例えば図８に示す世帯情報の登録画面Ｇ１００を表示する（ステップＳ１０１）。ユーザは、例えば、出力部１０２により表示されたトップ画面において、世帯情報の登録画面Ｇ１００に遷移するための操作を行うことで、当該世帯情報の登録画面Ｇ１００を表示することができる。

図８に示す世帯情報の登録画面Ｇ１００は、ユーザが世帯情報を登録するための画面である。図８に示す世帯情報の登録画面Ｇ１００には、氏名入力欄Ｇ１１０と、生年月日入力欄Ｇ１２０と、保険種類入力欄Ｇ１３０と、所得入力欄Ｇ１４０と、登録ボタンＧ１５０とが含まれる。また、図８に示す世帯情報の登録画面Ｇ１００には、既に登録されている世帯情報の一覧が表示される世帯情報一覧Ｇ１６０が含まれる。

ユーザは、氏名入力欄Ｇ１１０と、生年月日入力欄Ｇ１２０と、保険種類入力欄Ｇ１３０と、所得入力欄Ｇ１４０とに対して、それぞれ氏名と、生年月日と、保険種類と、所得とを入力する。そして、ユーザは、これらの各種情報（氏名、生年月日、保険種類及び所得）を入力した上で、登録ボタンＧ１５０を押下することで、世帯情報の登録操作を行うことができる。

次に、入力部１０１は、ユーザによる世帯情報の登録操作の入力を受け付ける（ステップＳ１０２）。入力部１０１は、世帯情報の登録操作の入力を受け付けると、ユーザにより入力された各種情報（氏名、生年月日、保険種類及び所得）を取得する。

次に、ＤＢ更新部１０３は、入力部１０１が取得した各種情報（氏名、生年月日、保険種類及び所得）から世帯情報データを作成する。なお、当該世帯情報データの世帯番号は、入力部１０１が取得した保険種類に応じて決定される。例えば、入力部１０１が取得した保険種類が「協会けんぽ」である場合、世帯番号は「世帯１」と決定される。

そして、ＤＢ更新部１０３は、作成した世帯情報データを世帯情報ＤＢ４００に格納する（ステップＳ１０３）。世帯情報データが世帯情報ＤＢ４００に格納されることで、世帯情報が受診シミュレーション装置１０に登録される。

以上より、本実施形態に係る受診シミュレーション装置１０は、世帯情報を登録することができる。ユーザは、高額療養費制度の適用をシミュレーションする前に、例えば、自身の世帯情報や同一世帯となる家族の世帯情報を登録する必要がある。

＜受診予定情報の登録＞
次に、ユーザが受診予定情報を登録する処理について、図９を参照しながら説明する。図９は、受診予定情報を登録する処理の一例を示すフローチャートである。受診予定情報の登録は、例えば、慢性疾患等により定期的に医療機関を受診する必要がある場合等、受診するタイミングが予め決まっているような場合に行われる。

まず、出力部１０２は、例えば図１０に示す受診予定情報の登録画面Ｇ２００を表示する（ステップＳ２０１）。ユーザは、例えば、出力部１０２により表示されたトップ画面において、受診予定情報の登録画面Ｇ２００に遷移するための操作を行うことで、当該受診予定情報の登録画面Ｇ２００を表示することができる。

図１０に示す受診予定情報の登録画面Ｇ２００は、ユーザが受診予定情報を登録するための画面である。図１０に示す受診予定情報の登録画面Ｇ２００には、氏名選択欄Ｇ２１０と、受診予定日入力欄Ｇ２２０と、医療機関名選択欄Ｇ２３０と、科名選択欄Ｇ２４０と、想定医療費入力欄Ｇ２５０と、入外区分選択欄Ｇ２６０と、登録ボタンＧ２７０とが含まれる。また、図１０に示す受診予定情報の登録画面Ｇ２００には、既に登録されている受診予定情報の一覧が表示される受診予定情報一覧Ｇ２８０が含まれる。

ユーザは、氏名選択欄Ｇ２１０と、医療機関名選択欄Ｇ２３０と、科名選択欄Ｇ２４０と、入外区分選択欄Ｇ２６０とから、それぞれ氏名と、受診を予定する医療機関の名称と、受診を予定する科名と、入外区分（入院又は外来）とを選択する。また、ユーザは、受診予定日入力欄Ｇ２２０と、想定医療費入力欄Ｇ２５０とに対して、それぞれ受診予定日と、想定医療費とを入力する。なお、想定医療費は、例えば、過去の医療費の領収書、後述する受診実績情報等を参考にして入力される。

そして、ユーザは、これらの各種情報（氏名、受診予定日、医療機関名、科名、想定医療費及び入外区分）を入力又は選択した上で、登録ボタンＧ２７０を押下することで、受診予定情報の登録操作を行うことができる。

次に、入力部１０１は、ユーザによる受診予定情報の登録操作の入力を受け付ける（ステップＳ２０２）。入力部１０１は、受診予定情報の登録操作の入力を受け付けると、ユーザにより入力又は選択された各種情報（氏名、受診予定日、医療機関名、科名、想定医療費及び入外区分）を取得する。

次に、ＤＢ更新部１０３は、入力部１０１が取得した各種情報（氏名、受診予定日、医療機関名、科名、想定医療費及び入外区分）から受診予定情報データを作成する。そして、ＤＢ更新部１０３は、作成した受診予定情報データを受診予定情報ＤＢ２００に格納する（ステップＳ２０３）。受診予定情報データが受診予定情報ＤＢ２００に格納されることで、受診予定情報が受診シミュレーション装置１０に登録される。

以上より、本実施形態に係る受診シミュレーション装置１０は、受診予定情報を登録することができる。ユーザは、高額療養費制度の適用をシミュレーションする前に、例えば、慢性疾患等により定期的に医療機関を受診する必要がある家族等の受診予定情報を登録する。

＜受診実績情報の登録＞
次に、ユーザが受診実績情報を登録する処理について、図１１を参照しながら説明する。図１１は、受診実績情報を登録する処理の一例を示すフローチャートである。受診実績情報の登録は、登録済の受診予定情報に対して、実際に医療機関で受診した場合又は受診しなかった場合に行われる。

まず、出力部１０２は、例えば図１２に示す受診実績情報の登録画面Ｇ３００を表示する（ステップＳ３０１）。ユーザは、例えば、出力部１０２により表示されたトップ画面において、受診実績情報の登録画面Ｇ３００に遷移するための操作を行うことで、当該受診実績情報の登録画面Ｇ３００を表示することができる。

図１２に示す受診実績情報の登録画面Ｇ３００は、ユーザが受診実績情報を登録するための画面である。図１２に示す受診実績情報の登録画面Ｇ３００には、登録済の受診予定情報が編集可能に一覧で表示される受診予定情報一覧Ｇ３１０と、当該受診予定情報一覧Ｇ３１０に含まれる１以上の受診予定情報選択するための選択欄Ｇ３２０とが含まれる。

ユーザは、受診予定一覧Ｇ３１０に含まれる受診予定情報を必要に応じて編集した上で、受診実績情報として登録する１以上の受診予定情報を選択欄Ｇ３２０から選択する。そして、ユーザは、登録ボタンＧ３３０を押下することで、受診実績情報の登録操作を行うことができる。受診予定情報の編集が必要な場合とは、登録した受診予定情報と、実際に受診した内容とが異なる場合（例えば、受診予定日が異なる場合や想定医療費が異なる場合等）である。

また、ユーザは、例えば、受診予定情報を登録したものの実際には受診しなかった場合等には、削除する１以上の受診予定情報を選択欄Ｇ３３０から選択した上で、削除ボタンＧ３４０を押下することで、受診予定情報の削除操作を行うことができる。受診予定情報の削除操作がなされることで、選択された受診予定情報の受診予定情報データが受診予定情報ＤＢ２００から削除される。

以降では、図１２に示す受診実績情報の登録画面Ｇ３００において、ユーザにより受診実績情報の登録操作が行われたものとする。

次に、入力部１０１は、ユーザによる受診実績情報の登録操作の入力を受け付ける（ステップＳ３０２）。入力部１０１は、受診実績情報の登録操作の入力を受け付けると、ユーザにより選択され、必要に応じて編集された受診予定情報を取得する。

次に、ＤＢ更新部１０３は、入力部１０１が取得した受診予定情報から受診実績データを作成する。そして、ＤＢ更新部１０３は、作成した受診実績データを受診実績情報ＤＢ３００に格納する（ステップＳ３０３）。受診実績情報データが受診実績情報ＤＢ３００に格納されることで、受診実績情報が受診シミュレーション装置１０に登録される。

次に、ＤＢ更新部１０３は、登録された受診実績情報に対応する受診予定情報を示す受診予定情報データを受診予定情報ＤＢ２００から削除する（ステップＳ３０４）。すなわち、ＤＢ更新部１０３は、図１２に示す受診実績情報の登録画面Ｇ３００に含まれる選択欄Ｇ３２０で選択された受診予定情報を示す受診予定情報データを受診予定情報ＤＢ２００から削除する。

以上より、本実施形態に係る受診シミュレーション装置１０は、受診予定情報を必要に応じて編集した上で、受診実績情報として登録することができる。ユーザは、実際に医療機関で受診した場合等に、受診実績情報の登録を行う。受診実績情報の登録が行われることで、受診シミュレーション装置１０は、後述する高額療養費制度の適用をシミュレーションする処理において、受診実績情報を考慮した、より正確なシミュレーションを行うことができるようになる。

＜高額療養費制度の適用のシミュレーション＞
次に、ユーザが所望する受診日に対して高額療養費制度の適用をシミュレーションする処理について、図１３を参照しながら説明する。図１３は、高額療養費制度の適用をシミュレーションする処理の一例を示すフローチャートである。

まず、出力部１０２は、例えば図１４に示すシミュレーション画面Ｇ４００を表示する（ステップＳ４０１）。ユーザは、例えば、出力部１０２により表示されたトップ画面において、シミュレーション画面Ｇ４００に遷移するための操作を行うことで、当該シミュレーション画面Ｇ４００を表示することができる。

図１４に示すシミュレーション画面Ｇ４００は、ユーザが高額療養費制度の適用をシミュレーションするための画面である。図１４に示すシミュレーション画面Ｇ４００には、氏名選択欄Ｇ４１０と、受診予定日入力欄Ｇ４２０と、医療機関名選択欄Ｇ４３０と、科名選択欄Ｇ４４０と、想定医療費入力欄Ｇ４５０と、入外区分選択欄Ｇ４６０とが含まれる。また、図１４に示すシミュレーション画面Ｇ４００には、シミュレーション実行ボタンＧ４７０と、シミュレーション結果表示欄Ｇ４８０とが含まれる。

ユーザは、氏名選択欄Ｇ４１０と、医療機関名選択欄Ｇ４３０と、科名選択欄Ｇ４４０と、入外区分選択欄Ｇ４６０とから、それぞれ氏名と、受診を予定する医療機関の名称と、受診を予定する科名と、入外区分（入院又は外来）とを選択する。また、ユーザは、受診予定日入力欄Ｇ４２０と、想定医療費入力欄Ｇ４５０とに対して、それぞれ受診予定日と、想定医療費とを入力する。なお、受診予定日は、例えば、現在の月から１年以内の年月日を入力する。

そして、ユーザは、これらの各種情報（氏名、受診予定日、医療機関名、科名、想定医療費及び入外区分）を入力又は選択した上で、シミュレーション実行ボタンＧ４７０を押下することで、シミュレーション実行操作を行うことができる。

次に、入力部１０１は、ユーザによるシミュレーション実行操作の入力を受け付ける（ステップＳ４０２）。入力部１０１は、シミュレーション実行操作の入力を受け付けると、ユーザにより入力又は選択された各種情報（氏名、受診予定日、医療機関名、科名、想定医療費及び入外区分）を取得する。

次に、ＤＢ更新部１０３は、入力部１０１が取得した各種情報（氏名、受診予定日、医療機関名、科名、想定医療費及び入外区分）から受診予定情報データを作成する。そして、ＤＢ更新部１０３は、作成した受診予定情報データを受診予定情報ＤＢ２００に格納する（ステップＳ４０３）。

次に、受診シミュレーション処理部１００は、受診候補月の特定処理を実行する（ステップＳ４０４）。すなわち、受診シミュレーション処理部１００は、入力部１０１が取得した各種情報（氏名、受診予定日、医療機関名、科名、想定医療費及び入外区分）から、高額療養費制度の適用を受けることができる月（すなわち、受診候補月）を特定する。受診候補月の特定処理については後述する。

次に、出力部１０２は、上記のステップＳ４０４で特定された受診候補月に応じたシミュレーション結果をシミュレーション結果表示欄Ｇ４８０に出力する（ステップＳ４０５）。

例えば、受診予定日入力欄Ｇ４２０に入力された受診予定日が「２０１７年３月３１日」であり、上記のステップＳ４０４で特定された受診候補月が「２０１７年４月」であったとする。この場合、出力部１０２は、例えば、「３月の受診では、高額療養費制度の適用を受けることはできませんが、４月に受診した場合、高額療養費制度の適用を受けることができます。」とのシミュレーション結果をシミュレーション結果表示欄Ｇ４８０に出力する。

また、例えば、受診予定日入力欄Ｇ４２０に入力された受診予定日が「２０１７年３月３１日」であり、上記のステップＳ４０４で特定された受診候補月が「２０１７年３月」であったとする。この場合、出力部１０２は、例えば、「３月に受診した場合、高額療養費制度の適用を受けることができます。」とのシミュレーション結果をシミュレーション結果表示欄Ｇ４８０に出力する。

また、例えば、受診予定日入力欄Ｇ４２０に入力された受診予定日が「２０１７年３月３１日」であり、上記のステップＳ４０４で特定された受診候補月が「２０１７年４月、５月、７月」であったとする。この場合、出力部１０２は、例えば、「３月の受診では、高額療養費制度の適用を受けることはできませんが、４月、５月、又は７月に受診した場合、高額療養費制度の適用を受けることができます。」とのシミュレーション結果をシミュレーション結果表示欄Ｇ４８０に出力する。

このように、出力部１０２は、上記のステップＳ４０４で特定された受診候補月をシミュレーション結果表示欄Ｇ４８０に出力する。

以上により、本実施形態に係る受診シミュレーション装置１０は、ユーザにより入力等がされた各種情報から、受診予定日が高額療養費制度の適用を受けることができる月であるかをシミュレーションする。そして、本実施形態に係る受診シミュレーション装置１０は、シミュレーション結果を画面上に出力する。これにより、ユーザは、自身が所望する受診予定日が高額療養費制度の適用を受けることができる月であるか否かを知ることができ、必要に応じて受診予定日を変更等することで、医療費負担の軽減を図ることができる。

例えば、受診予定日が「２０１７年３月３１日」であり、シミュレーション結果が「３月の受診では、高額療養費制度の適用を受けることはできませんが、４月に受診した場合、高額療養費制度の適用を受けることができます。」であったとする。この場合は、ユーザは、受診日を１日遅らして次の月に医療機関を受診することで、高額療養費制度の適用により、医療費の負担の軽減を図ることができる。このように、ユーザは、シミュレーション結果を参考にして、例えば、急を要しない受診については受診日を変更することで、高額療養費制度の適用により、医療費の負担の軽減を図ることができる。特に、例えば、慢性疾患等により定期的に医療機関を受診する家族がいる場合に、医療機関を受診する月を世帯内で同一の月に集中させることで、医療費の負担の軽減を図ることができる。

なお、上記のステップＳ４０３で作成及び格納された受診予定情報データは、受診予定情報ＤＢ２００に格納されたままでも良いし、上記のステップＳ４０３の後に削除されても良い。

また、図１４に示すシミュレーション画面Ｇ４００の受診予定日入力欄Ｇ４２０には、受診予定日が入力されなくても良い。この場合、上記のステップＳ４０４における受診候補月の特定処理では、例えば、現在月から最も近い受診候補月を特定すれば良い。

＜受診候補月を特定する処理＞
次に、上記のステップＳ４０４における受診候補月を特定する処理について、図１５を参照しながら説明する。図１５は、受診候補月を特定する処理の一例を示すフローチャートである。

まず、合計算出部１０４は、受診予定情報ＤＢ２００と、受診実績情報ＤＢ３００と、世帯情報ＤＢ４００とを参照して、ユーザの世帯の現在月における医療費の合計額を算出する（ステップＳ５０１）。すなわち、合計算出部１０４は、ユーザの世帯の現在月における世帯合算を算出する。

例えば、入力部１０１が取得した氏名が「山田 花子」である場合、当該氏名のユーザの世帯番号は「世帯１」である。したがって、この場合、世帯合算の対象者は「山田 太郎」及び「山田 花子」である。例えば、現在月が「２０１７年２月」であるとする。この場合、合計算出部１０４は、「山田 太郎」の「２０１７年２月」における医療費（実績及び想定）と、「山田 花子」の「２０１７年２月」における医療費（実績及び想定）とのうち、高額療養費制度の合算基準に従って合算対象となる医療費の合計額を算出する。

高額療養費制度の合算基準では、７０歳未満である場合、同一医療機関における医療費の合計が月２１，０００円以上である場合に合算対象となる。ただし、同一医療機関であっても入院と外来とは区別して計算される。一方で、７０歳以上である場合には、全ての医療費が合算対象となる。

例えば、「山田 太郎」及び「山田 花子」が共に７０歳未満である場合、受診日「２０１７年２月」、氏名「山田 太郎」又は「山田 花子」、同一医療機関かつ同一入外区分の医療費の合計が「２，１０００円以上」である受診実績情報データの医療費が合算対象となる。同様に、受診日「２０１７年２月」、氏名「山田 太郎」又は「山田 花子」、同一医療機関かつ同一入外区分の医療費の合計が「２，１０００円以上」である受診予定情報データの想定医療費が合算対象となる。

合計算出部１０４は、２０１７年２月における合算対象の医療費と、２０１７年２月における合算対象の想定医療費との合計を計算することで、現在月「２０１７年２月」における医療費の合計額を算出する。

次に、多数回該当判定部１０５は、該当の世帯の超過月テーブル５００を参照して、上記のステップＳ５０１で合計額が算出された月（現在月）が多数回該当の条件を満たすか否かを判定する（ステップＳ５０２）。すなわち、多数回該当判定部１０５は、該当の世帯における超過月テーブル５００を参照して、現在月から直近１２か月以内に、限度額を超えている月が３回以上あるか否かを判定する。

ここで、世帯番号「世帯１」、現在月「２０１７年２月」における超過月テーブル５００について、図１６を参照しながら説明する。図１６は、超過月テーブル５００の一例を示す図である。

図１６に示すように、超過月テーブル５００には、テーブルの項目として、年月と、自己負担限度額超過有無とを有し、直近１２か月（２０１６年２月〜２０１７年１月）における自己負担限度額の超過有無を示す情報が格納されている。

多数回該当判定部１０５は、同一世帯の超過月テーブル５００を参照して、自己負担限度額の超過が直近１２か月間に３回以上であるか否かを判定する。自己負担限度額の超過が直近１２か月間に３回以上である場合、現在の月は、多数回該当月となる。

ステップＳ５０２において、多数回該当の条件を満たさないと判定された場合、限度額取得部１０６は、世帯情報ＤＢ４００を参照して、多数該回当月でない場合における現在月の限度額を限度額テーブル６００から取得する（ステップＳ５０３）。

一方、ステップＳ５０２において、多数回該当の条件を満たすと判定された場合、限度額取得部１０６は、世帯情報ＤＢ４００を参照して、多数回該当月である場合における現在月の限度額を限度額テーブル６００から取得する（ステップＳ５０４）。

ここで、限度額テーブル６００について、図１７を参照しながら説明する。図１７は、限度額テーブル６００の一例を示す図である。なお、図１７では、一例として、平成２７年１月以降に受診した場合に７０歳未満の利用者に適用される自己負担限度額を示す情報が格納された限度額テーブル６００について説明する。

図１７に示すように、限度額テーブル６００には、テーブルの項目として、所得区分と、多数回該当月でない場合の自己負担限度額と、多数回該当月である場合の自己負担限度額とを有する。

所得区分は、高額療養費制度で定められた利用者の所得の区分である。例えば、区分アは標準報酬月額８３万以上の利用者が適用される所得区分である。同様に、例えば、区分イは標準報酬月額５３万〜７９万の利用者が適用される所得区分である。

限度額取得部１０６は、世帯情報ＤＢ４００に格納された世帯情報データの所得と、多数回該当判定部１０５の判定結果とから、自己負担限度額を限度額テーブル６００から取得する。

例えば、世帯番号「世帯１」の被保険者が「山田 太郎」、被扶養者が「山田 花子」であるとする。この場合、被保険者「山田 太郎」の所得「５，０００，０００円」から、所得区分は「区分ウ」となる。したがって、現在月が多数回該当月でない場合、限度額取得部１０６は、現在月の自己負担限度額「８０，１００円＋（医療費の合計額−２６７，０００円）×１％」を限度額テーブル６００から取得する。一方で、現在月が多数回該当月である場合、限度額取得部１０６は、現在月の自己負担限度額「４４，４００円」を限度額テーブル６００から取得する。

次に、超過判定部１０７は、上記のステップＳ５０１で算出された合計額と、上記のステップＳ５０３又はステップＳ５０４で取得された限度額とから、現在月が高額療養費制度の適用を受けることができる月であるか否かを判定する（ステップＳ５０５）。すなわち、超過判定部１０７は、現在月における医療費の合計額が限度額を超えているか否かを判定する。超過判定部１０７による判定結果（判定された月、及び当該月における医療費の合計額が限度額を超えているか否かを示す情報）は、例えばＲＡＭ１６等に一時的に記憶される。

次に、合計算出部１０４は、受診実績情報ＤＢ３００と、世帯情報ＤＢ４００とを参照して、ユーザの世帯の次の月における医療費の合計額を算出する（ステップＳ５０６）。すなわち、合計算出部１０４は、ユーザの世帯の次の月における世帯合算を算出する。

例えば、医療費の合計額が既に算出された月が「２０１７年２月」である場合、合計算出部１０４は、同一世帯における「２０１７年３月」における想定医療費のうち、高額療養費制度の合算基準に従って合算対象となる想定医療費の合計額を算出する。

例えば、同一世帯が「山田 太郎」及び「山田 花子」で構成され、「山田 太郎」及び「山田 花子」が共に７０歳未満であるとする。この場合、受診予定日「２０１７年３月」、氏名「山田 太郎」又は「山田 花子」、同一医療機関かつ同一入外区分の想定医療費の合計が「２，１０００円以上」である受診予定情報データの想定医療費を合算対象として、合計算出部１０４は、想定医療費の合計額を算出する。

次に、多数回該当判定部１０５は、該当の世帯の超過月テーブル５００と、超過判定部１０７のこれまでの判定結果とを参照して、上記のステップＳ５０６で合計額が算出された月が多数回該当の条件を満たすか否かを判定する（ステップＳ５０７）。すなわち、多数回該当判定部１０５は、該当の世帯における超過月テーブル５００と、超過判定部１０７のこれまでの判定結果とを参照して、当該次の月から直近１２か月以内に、限度額を超えている月が３回以上あるか否かを判定する。

ステップＳ５０７において、多数回該当の条件を満たさないと判定された場合、限度額取得部１０６は、世帯情報ＤＢ４００を参照して、多数回該当月でない場合における当該次の月の限度額を限度額テーブル６００から取得する（ステップＳ５０８）。

一方、ステップＳ５０７において、多数回該当の条件を満たすと判定された場合、限度額取得部１０６は、世帯情報ＤＢ４００を参照して、多数回該当月である場合における当該次の月の限度額を限度額テーブル６００から取得する（ステップＳ５０９）。

次に、超過判定部１０７は、上記のステップＳ５０６で算出された合計額と、上記のステップＳ５０８又はステップＳ５０９で取得された限度額とから、当該次の月が高額療養費制度の適用を受けることができる月であるか否かを判定する（ステップＳ５１０）。すなわち、超過判定部１０７は、当該次の月における医療費の合計額が限度額を超えているか否かを判定する。超過判定部１０７による判定結果は、例えばＲＡＭ１６等に一時的に記憶される。

次に、超過判定部１０７は、１年分の判定を行ったか否かを判定する（ステップＳ５１１）。すなわち、例えば、現在月が「２０１７年２月」である場合、超過判定部１０７は、現在月から「２０１８年１月」までの各月における判定結果（医療費の合計額が限度額を超えているか否かの判定結果）が存在するか否かを判定する。なお、１年分は一例であって、例えば６か月や３か月等、任意の月数であって良い。

ステップＳ５１１において、１年分の判定を行っていない場合、受診シミュレーション処理部１００は、ステップＳ５０６に戻る。したがって、受診シミュレーション処理部１００は、現在月の次の月以降の１１か月分の各月についてステップＳ５０６〜ステップＳ５１１の処理を実行する。

一方、ステップＳ５１１において、１年分の判定を行った場合、候補月特定部１０８は、超過判定部１０７による判定結果を参照して、医療費の合計額が限度額を超えている月があるか否かを判定する（ステップＳ５１２）。

ステップＳ５１２において、医療費の合計額が限度額を超えている月があると判定した場合、候補月特定部１０８は、医療費の合計額が限度額を超えている月に、受診予定日の月が含まれるか否かを判定する（ステップＳ５１３）。

ステップＳ５１３において、医療費の合計額が限度額を超えている月に、受診予定日の月が含まれると判定した場合、候補月特定部１０８は、受診予定日の月を受診候補月に特定する（ステップＳ５１４）。

一方、ステップＳ５１３において、医療費の合計額が限度額を超えている月に、受診予定日の月が含まれないと判定した場合、候補月特定部１０８は、受診予定日の月以外の月を受診候補月に特定する（ステップＳ５１５）。このとき、候補月特定部１０８は、例えば、医療費の合計額が限度額を超えている全ての月を受診候補月に特定しても良いし、医療費の合計額が限度額を超えている月のうち、受診予定日の月に最も近い月を受診候補月に特定しても良い。又は、候補月特定部１０８は、例えば、医療費の合計額が限度額を超えている月のうち、受診予定日の月から近い順に所定の数の月を受診候補月に特定しても良い。

ステップＳ５１２において、医療費の合計額が限度額を超えている月がないと判定した場合、受診シミュレーション処理部１００は、処理を終了する。この場合、受診候補月は特定されない。受診候補月が特定されなかった場合、図１３のステップＳ４０３で出力部１０２は、受診候補月が特定されなかったことをシミュレーション結果表示欄Ｇ４８０に出力すれば良い。又は、出力部１０２は、高額療養費制度の適用を受けることができる月が存在しないことを示すシミュレーション結果をシミュレーション結果表示欄Ｇ４８０に出力しても良い。

＜受診候補月を特定する処理の他の例＞
ここで、図１３のステップＳ４０４における受診候補月を特定する処理の他の例について、図１８を参照しながら説明する。図１８は、受診候補月を特定する処理の他の例を示すフローチャートである。図１５に示す例では、現在月が多数回該当月でない場合に、現在月の次の月以降で、多数回該当の条件を満たすこととなる月が存在する場合、当該月のうち最初に多数回該当の条件を満たすこととなる月を受診候補月に特定する。なお、図１８のステップＳ６０１〜ステップＳ６１２は、図１４のステップＳ５０１〜ステップＳ５１２と同様であるため、その説明を省略する。また、図１８のステップＳ６１６〜ステップＳ６１８は、図１４のステップＳ５１３〜ステップＳ５１５と同様であるため、その説明を省略する。

ステップＳ６１２において、医療費の合計額が限度額を超えている月があると判定した場合、多数回該当判定部１０５は、現在月が多数回該当月であるか否かを判定する（ステップＳ６１３）。

ステップＳ６１３において、現在月が多数回該当月であると判定した場合、受診シミュレーション処理部１００は、ステップＳ６１６に進む。

一方、ステップＳ６１３において、現在月が多数回該当月でないと判定した場合、多数回該当判定部１０５は、現在月の次の月以降に多数回該当月となる月があるか否かを判定する（ステップＳ６１４）。すなわち、多数回該当判定部１０５は、ステップＳ６０７における判定結果のうち、多数回該当の条件を満たすことを示す判定結果が存在するか否かを判定する。

ステップＳ６１４において、次の月以降に多数回該当月となる月がないと判定した場合、受診シミュレーション処理部１００は、ステップＳ６１６に進む。

一方、ステップＳ６１４において、次の月以降に多数回該当月となる月があると判定した場合、候補月特定部１０８は、現在月の次の月以降の月のうち、最初に多数回該当月となる月を受診候補月に特定する（ステップＳ６１５）。このとき、候補月特定部１０８は、最初に多数回該当月となる月に加えて、医療費の合計額が限度額を超えている月のうち、受診予定日の月に最も近い月を受診候補月に特定しても良い。また、候補月特定部１０８は、最初に多数回該当月となる月を第１の受診候補月に特定すると共に、医療費の合計額が限度額を超えている全ての月を第２の受診候補月に特定しても良い。また、候補月特定部１０８は、最初に多数回該当月となる月を第１の受診候補月に特定すると共に、医療費の合計額が限度額を超えている月のうち、受診予定日の月に最も近い月を第２の受診候補月に特定しても良い。

これにより、ユーザは、現在月が多数回該当月でない場合に、現在月の次の月以降の月で、最初に多数回該当月となる月を知ることができる。したがって、ユーザは、最初に多数回該当月となる月を考慮した上で、医療費の負担を軽減させるための受診計画を立てることができる。

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

以上の説明に関し、更に以下の項を開示する。
（付記１）
ユーザ識別情報と、予定している受診について想定される想定医療費との入力を受け付け、
ユーザ毎の医療費を記憶する第１の記憶部と、医療費を合算する対象のユーザを記憶する第２の記憶部とを参照して、月毎に、受け付けた前記ユーザ識別情報のユーザと医療費を合算するユーザの医療費と、前記想定医療費との合計を算出し、
算出した前記合計が、医療費の限度額を超える月を出力する、
処理をコンピュータに実行させるためのプログラム。
（付記２）
前記受け付ける処理は、
更に、受診予定日の入力を受け付け、
前記出力する処理は、
受け付けた前記受診予定日を含む月の前記合計が前記限度額を超えない場合、前記限度額を超える月のうち、前記受診予定日を含む月とは異なる他の月を出力する、付記１に記載のプログラム。
（付記３）
前記出力する処理は、
前記他の月のうち、高額療養費制度における多数回該当の条件を満たす最初の月を出力する、付記２に記載のプログラム。
（付記４）
ユーザ識別情報と、予定している受診について想定される想定医療費との入力を受け付ける受付部と、
ユーザ毎の医療費を記憶する第１の記憶部と、医療費を合算する対象のユーザを記憶する第２の記憶部とを参照して、月毎に、受け付けた前記ユーザ識別情報のユーザと医療費を合算するユーザの医療費と、前記想定医療費との合計を算出する算出部と、
算出した前記合計が、医療費の限度額を超える月を出力する出力部と、
を有する情報処理装置。
（付記５）
前記受付部は、
更に、受診予定日の入力を受け付け、
前記出力部は、
受け付けた前記受診予定日を含む月の前記合計が前記限度額を超えない場合、前記限度額を超える月のうち、前記受診予定日を含む月とは異なる他の月を出力する、付記４に記載の情報処理装置。
（付記６）
前記出力部は、
前記他の月のうち、高額療養費制度における多数回該当の条件を満たす最初の月を出力する、付記５に記載の情報処理装置。
（付記７）
ユーザ識別情報と、予定している受診について想定される想定医療費との入力を受け付け、
ユーザ毎の医療費を記憶する第１の記憶部と、医療費を合算する対象のユーザを記憶する第２の記憶部とを参照して、月毎に、受け付けた前記ユーザ識別情報のユーザと医療費を合算するユーザの医療費と、前記想定医療費との合計を算出し、
算出した前記合計が、医療費の限度額を超える月を出力する、
処理をコンピュータが実行する情報処理方法。
（付記８）
前記受け付ける処理は、
更に、受診予定日の入力を受け付け、
前記出力する処理は、
受け付けた前記受診予定日を含む月の前記合計が前記限度額を超えない場合、前記限度額を超える月のうち、前記受診予定日を含む月とは異なる他の月を出力する、付記７に記載の情報処理方法。
（付記９）
前記出力する処理は、
前記他の月のうち、高額療養費制度における多数回該当の条件を満たす最初の月を出力する、付記８に記載の情報処理方法。

１０ 受診シミュレーション装置
１００ 受診シミュレーション処理部
１０１ 入力部
１０２ 出力部
１０３ ＤＢ更新部
１０４ 合計算出部
１０５ 多数回該当判定部
１０６ 限度額取得部
１０７ 超過判定部
１０８ 候補月特定部
２００ 受診予定情報ＤＢ
３００ 受診実績情報ＤＢ
４００ 世帯情報ＤＢ
５００ 超過月テーブル
６００ 限度額テーブル

Claims (5)

1. ユーザ識別情報と、予定している受診について想定される想定医療費との入力を受け付け、
   ユーザ毎の医療費を記憶する第１の記憶部と、医療費を合算する対象のユーザを記憶する第２の記憶部とを参照して、月毎に、受け付けた前記ユーザ識別情報のユーザと医療費を合算するユーザの医療費と、前記想定医療費との合計を算出し、
   算出した前記合計が、医療費の限度額を超える月を出力する、
   処理をコンピュータに実行させるためのプログラム。
2. 前記受け付ける処理は、
   更に、受診予定日の入力を受け付け、
   前記出力する処理は、
   受け付けた前記受診予定日を含む月の前記合計が前記限度額を超えない場合、前記限度額を超える月のうち、前記受診予定日を含む月とは異なる他の月を出力する、請求項１に記載のプログラム。
3. 前記出力する処理は、
   前記他の月のうち、高額療養費制度における多数回該当の条件を満たす最初の月を出力する、請求項２に記載のプログラム。
4. ユーザ識別情報と、予定している受診について想定される想定医療費との入力を受け付ける受付部と、
   ユーザ毎の医療費を記憶する第１の記憶部と、医療費を合算する対象のユーザを記憶する第２の記憶部とを参照して、月毎に、受け付けた前記ユーザ識別情報のユーザと医療費を合算するユーザの医療費と、前記想定医療費との合計を算出する算出部と、
   算出した前記合計が、医療費の限度額を超える月を出力する出力部と、
   を有する情報処理装置。
5. ユーザ識別情報と、予定している受診について想定される想定医療費との入力を受け付け、
   ユーザ毎の医療費を記憶する第１の記憶部と、医療費を合算する対象のユーザを記憶する第２の記憶部とを参照して、月毎に、受け付けた前記ユーザ識別情報のユーザと医療費を合算するユーザの医療費と、前記想定医療費との合計を算出し、
   算出した前記合計が、医療費の限度額を超える月を出力する、
   処理をコンピュータが実行する情報処理方法。

Images