JP2019179508A - 情報提供プログラム、情報提供方法、および、情報提供装置 - Google Patents

Abstract

【課題】医療機関等での保険証の不正使用を防止する。【解決手段】情報提供プログラムは、コンピュータで実行される。コンピュータは、端末から通知された識別情報で識別される保険証の情報の照会に用いる第１のトークンを、保険証情報を保持するサーバ装置から取得する。コンピュータは、端末から通知された情報に対応付けられた診察券の情報の照会に用いる第２のトークンを、医療機関が用いる情報を保持するサーバ装置から取得する。コンピュータは、端末から、端末のユーザの認証に成功したことを表わす情報と医療機関を指定する情報を受信すると、第１のトークンを用いて取得した保険証の情報、および、第２のトークンを用いて取得した診察券の情報を、端末に送信する。【選択図】図１

Description

本発明は、情報提供プログラム、情報提供方法、および、情報提供装置に関する。

病院などの医療機関を受診する際に、患者は、医療機関から発行された診察券と共に健康保険証を提示する。医療機関は、提示された診察券を用いて患者の既往歴などを確認すると共に、健康保険証を用いて、医療費のうちの患者の負担額を決定する。

関連する技術として、ＩＣ（integrated circuit）カードを用いた保険証の保険証情報を被保険者が所有する携帯電話の記憶装置に記憶させて、携帯電話に保険証機能を持たせるシステムが提案されている（例えば、特許文献１）。

特開２００２−３５１９９７号

患者が健康保険証や診察券を医療機関に提出しても、患者が、患者自身に発行された健康保険証や診察券を使用しているかを医療機関側で確認することは困難である。このため、患者が他人の健康保険証を医療機関に提出して、他人に成りすまして診療を受けようとした場合、成りすましが行われていることを医療機関側で確認することは極めて困難である。このような状態は、紙に印刷された健康保険証が使用される場合に限らず、背景技術で述べたように携帯電話の記憶装置に保険証を記憶させて、保険証機能を持たせた携帯電話が医療機関に提示された場合も起こり得る。

本発明は、１つの側面として、医療機関等での保険証の不正使用を防止することを目的とする。

ある１つの態様にかかる情報提供プログラムは、コンピュータで実行される。コンピュータは、端末から通知された識別情報で識別される保険証の情報の照会に用いる第１のトークンを、保険証情報を保持するサーバ装置から取得する。コンピュータは、端末から通知された情報に対応付けられた診察券の情報の照会に用いる第２のトークンを、医療機関が用いる情報を保持するサーバ装置から取得する。コンピュータは、端末から、端末のユーザの認証に成功したことを表わす情報と医療機関を指定する情報を受信すると、第１のトークンを用いて取得した保険証の情報、および、第２のトークンを用いて取得した診察券の情報を、端末に送信する。

医療機関等での保険証の不正使用を防止できる。

実施形態にかかる情報提供方法の例を説明する図である。 情報提供方法が使用されるシステムの例を説明する図である。 対応テーブルと被保険者データベースの例を説明する図である。 情報処理装置およびサーバ装置のハードウェア構成の例を説明する図である。 端末および受付装置のハードウェア構成の例を説明する図である。 保険証情報の登録処理の例を説明するフローチャートである。 保険証データベースと対応テーブルの例を説明する図である。 診察券の登録処理の例を説明するフローチャートである。 病院データベースと対応テーブルの例を説明する図である。 クレジットカードの登録処理の例を説明するフローチャートである。 金融データベースと対応テーブルの例を説明する図である。 診察受付前の端末の表示例を説明する図である。 診察の受付処理の例を説明するフローチャートである。 診察の受付処理の際に行われるデータの更新の例を説明する図である。 診察受付の際の端末の表示例を説明する図である。 診察料金の支払処理の例を説明するフローチャートである。 診察料金の支払処理の際に行われるデータの更新の例を説明する図である。 診察料金の支払処理が行われたときの端末の表示例を説明する図である。 薬局の指定処理の例を説明するフローチャートである。 薬局の指定処理の際に行われるデータの更新の例を説明する図である。 薬局の指定処理の際の端末の表示例を説明する図である。 薬局の指定処理が行われたときのデータの更新の例を説明する図である。 薬の受け取りの際に行われる処理の例を説明するフローチャートである。 薬の受け取りの際に行われるデータの更新の例を説明する図である。 薬の受け取り用の表示画面の例を説明する図である。

図１は、実施形態にかかる情報提供方法の例を説明する図である。実施形態にかかる情報提供方法が行われるシステムは、受付装置１０、端末２０、情報処理装置３０、健保サーバ２、および、病院サーバ４を備える。端末２０は、病院にかかろうとしているユーザが携帯しているスマートフォンなどの携帯電話端末やタブレットであり、予め、端末２０を操作している操作者が端末２０の正規のユーザであるかを認証するための情報を保持しているものとする。健保サーバ２は、健康保険証（保険証）を発行している健康保険組合が管理するサーバであって、保険証の情報を保持している。病院サーバ４は、ある病院（Ｙ病院）の患者情報を管理するサーバである。受付装置１０は、Ｙ病院の受付処理に使用される装置であり、端末２０と通信可能である。情報処理装置３０は、ユーザの診察受付を行うために端末２０が受付装置１０に提示する情報を、端末２０に提供できる装置である。

以下、図１のシーケンス図を参照しながら、情報提供方法で行われる処理の例を時系列に沿って説明する。まず、端末２０のユーザは、事前登録として、ユーザ自身の保険証に含まれている識別情報（Ａ）を端末２０に入力する。端末２０は、保険証の識別情報（Ａ）を情報処理装置３０に送信する（ステップＳ１）。情報処理装置３０は、識別情報（Ａ）で識別される保険証に関する情報を照会する際に使用可能なアクセストークンの発行を、健保サーバ２に要求する（ステップＳ２）。健保サーバ２は、情報処理装置３０からの要求に応じて、識別情報（Ａ）で識別される保険証の情報照会用のアクセストークン（α）を生成し、アクセストークン（α）を情報処理装置３０に送信する（ステップＳ３、Ｓ４）。情報処理装置３０は、アクセストークン（α）を記憶する（ステップＳ５）。

さらに、事前登録として、端末２０のユーザは、ユーザが通院しているＹ病院の診察券の情報（Ｂ）を端末２０に入力する。端末２０は、診察券情報（Ｂ）を情報処理装置３０に送信する（ステップＳ６）。情報処理装置３０は、診察券情報（Ｂ）で識別される診察券に関する情報を照会する際に使用可能なアクセストークンの発行を、Ｙ病院の情報を保持している病院サーバ４に要求する（ステップＳ７）。病院サーバ４は、情報処理装置３０からの要求に応じて、診察券情報（Ｂ）で識別される診察券の情報照会用のアクセストークン（β）を生成し、アクセストークン（β）を情報処理装置３０に送信する（ステップＳ８、Ｓ９）。情報処理装置３０は、アクセストークン（β）を記憶する（ステップＳ１０）。

その後、端末２０のユーザがＹ病院で診察を受けようとしたとする。診察受付処理を開始するために、ユーザはＹ病院を指定する情報を端末２０に入力する。すると、端末２０は、入力処理を行った操作者が端末２０の正規のユーザであるかを判定するための認証処理を行う。端末２０で行われる認証処理は、任意の認証処理であって良い。なお、認証処理は、例えば、ＦＩＤＯ（Fast Identity Online）認証のように、端末２０での認証の他に、情報処理装置３０での検証処理を含む認証処理であっても良い。ここでは、端末２０は、認証処理によって、端末２０の操作者が端末２０の正規のユーザであると判定したとする。すると、端末２０は、情報処理装置３０に対して、認証処理に成功したことを表わす情報と、診療受付を行う病院がＹ病院であることを表わす情報を情報処理装置３０に通知する（ステップＳ１１）。

情報処理装置３０は、端末２０での認証成功と診療受付処理を行う対象がＹ病院であることを認識すると、アクセストークンαを用いて、ユーザの保険証の情報を健保サーバ２に要求する（ステップＳ１２）。さらに、情報処理装置３０は、アクセストークンβを用いて、ユーザの診察券の情報を病院サーバ４に要求する（ステップＳ１３）。情報処理装置３０は、健保サーバ２からユーザの保険証の情報を取得し、さらに、病院サーバ４からユーザの診察券情報を取得したとする（ステップＳ１４、Ｓ１５）。すると、情報処理装置３０は、得られた保険証の情報と診察券の情報を、受付処理用の情報として端末２０に送信する（ステップＳ１６）。このとき、情報処理装置３０は、例えば、保険証の情報と診察券の情報を含むＱＲ（Quick Response）コードなどの情報コードを、受付処理用の情報として端末２０に送信することができる。

端末２０は、情報処理装置３０から受信した保険証の情報と診察券の情報を、受付装置１０に提供することで受付処理を行う（ステップＳ１７）。このとき、端末２０のユーザは、例えば、受付処理用の情報として受信したＱＲコード（登録商標）を端末２０の画面に表示し、受付装置１０が備えるカメラでＱＲコードを撮像させることによって、保険証の情報と診察券の情報を受付装置１０に提供しても良い。

このように、実施形態にかかる情報提供方法によると、端末２０での認証処理によって、端末２０の操作者が端末２０の正規のユーザであると判定されると、端末２０の正規のユーザの保険証や診察券の情報が情報処理装置３０から端末２０に送信される。従って、端末２０の正規ユーザは、端末２０が情報処理装置３０から取得した情報を受付装置１０に提供することにより、ユーザが事前登録した保険証の情報を病院の受付装置１０に提示できる。さらに、情報処理装置３０からの保険証情報の提供は、端末２０での認証処理に成功しないと行われないので、端末２０の正規ユーザが端末２０の操作者ではない場合には、端末２０の正規ユーザの保険証の情報は端末２０に提供されない。このため、実施形態にかかる情報提供方法によると、保険証の不正使用を防止することができる。

なお、図１のシーケンス図は処理の一例に過ぎない。例えば、ステップＳ１〜Ｓ５の処理は、ステップＳ６〜Ｓ１０の処理と並行して行われても良く、また、ステップＳ６〜Ｓ１０の処理の後にステップＳ１〜Ｓ５の処理が行われても良い。さらに、ステップＳ１１の処理の後、情報処理装置３０は、ステップＳ１１での通知の前に健保サーバ２から取得しておいた保険証情報や、ステップＳ１１での通知の前に病院サーバ４から取得した診察券の情報を、ステップＳ１６で送信しても良い。さらに、実施形態にかかる情報提供方法は、情報処理装置３０が薬局などにも保険証情報を提供できるように変形されても良い。

＜システム構成と装置構成の例＞
図２は、情報提供方法が使用されるシステムの例を説明する図である。図２は、情報処理装置３０が薬局にも保険証情報を提供できるシステムの例を示している。さらに、以下の例では、端末２０の操作者が端末２０の正規のユーザであるかを判定するために行われる認証処理はＦＩＤＯ認証である場合を例として説明する。

システムには、病院の受付に使用される受付装置１０ａ、薬局での受付に使用される受付装置１０ｂ、端末２０、情報処理装置３０、健保サーバ２、病院サーバ４、薬局サーバ６、金融機関サーバ８が含まれる。健保サーバ２は、保険証の情報を記録した保険証データベース３を備える。病院サーバ４は、病院の診察券の情報などを記録した病院データベース５を備える。薬局サーバ６は、薬局の調剤に関する情報などを記録した薬局データベース７を備える。金融機関サーバ８は、クレジットカードを用いた決済処理に関する情報を記憶した金融データベース９を備える。

端末２０は、通信部２１、カメラ２２、アプリ処理部２３、認証処理部２４、表示部２５、および、記憶部２６を備える。通信部２１は、受付装置１０や情報処理装置３０との間の通信処理を行う。従って、アプリ処理部２３や認証処理部２４などは、通信部２１を介して情報処理装置３０などと通信できる。カメラ２２は撮像処理を行う。アプリ処理部２３は、情報提供を行うための処理に使用されるアプリケーションの処理を行う。例えば、アプリ処理部２３は、表示部２５が備える画面に表示する表示画面データの描画処理や、カメラ２２で撮像した画像の処理などを行う。認証処理部２４は、端末２０の操作を行っている操作者が端末２０の正規のユーザであるかを判定するために、ＦＩＤＯ認証を行う。ＦＩＤＯ認証において、認証処理部２４は、ＦＩＤＯクライアントとして動作する。記憶部２６は、カメラ２２、アプリ処理部２３、認証処理部２４の処理で得られたデータ等を記憶する。

情報処理装置３０は、通信部３１、ヘルスケア情報処理部３２、認証情報処理部４０を備える。通信部３１は、健保サーバ２、病院サーバ４、薬局サーバ６、金融機関サーバ８、および、端末２０との間の通信処理を行う。従って、認証情報処理部４０やヘルスケア情報処理部３２は、通信部３１を介して、健保サーバ２や端末２０などと通信できる。

認証情報処理部４０は、認証処理部４１、取得部４２、記憶部５０を備える。記憶部５０は、ＰＩＮ（personal identification number）情報５１と対応テーブル５２を有する。認証処理部４１は、ＦＩＤＯサーバとして動作する。認証処理部４１は、ＦＩＤＯクライアントとして動作する端末２０との間で送受信した取得した情報を用いて、ユーザのＦＩＤＯ登録やＦＩＤＯ認証を行う。取得部４２は、ユーザに対して発行された保険証の情報を取得するためのアクセストークンを、健保サーバ２から取得する。ＰＩＮ情報５１は、保険証情報の登録の際に使用される暗証番号の情報である。対応テーブル５２は、ＦＩＤＯ認証に成功したユーザに関する情報を記憶する。対応テーブル５２の例については後述する。

ヘルスケア情報処理部３２は、制御部６０と記憶部７０を備える。記憶部７０は、病院情報７１、薬局情報７２、被保険者データベース８０を有する。病院情報７１は、実施形態にかかる情報提供方法を用いて診療受付を行うことが可能な病院の情報である。病院情報７１には、病院情報７１に含まれる各病院の病院サーバ４のアドレス等が含まれるものとする。薬局情報７２は、実施形態にかかる情報提供方法を用いて処方箋の受付や薬の受け取りが可能な薬局の情報である。薬局情報７２には、薬局情報７２に含まれる各薬局の薬局サーバ６のアドレスや各薬局の位置情報等が含まれるものとする。被保険者データベース８０は、被保険者に関する情報を記憶するデータベースである。被保険者データベース８０の詳細については後述する。

制御部６０は、取得部６１、ＱＲコード生成部６２、サービス処理部６３、アプリ制御部６４を備える。取得部６１は、ＦＩＤＯ認証に成功したユーザに対して発行された診察券の情報を取得するためのアクセストークンを取得する。ＱＲコード生成部６２は、端末２０に送信する情報を含むＱＲコードを生成する。サービス処理部６３は、病院サーバ４、薬局サーバ６、および、金融機関サーバ８と、通信部３１を介してデータを送受信することにより、被保険者データベース８０の更新処理を行う。アプリ制御部６４は、通信部３１を介して端末２０にデータを送受信することにより、端末２０の画面表示の更新を要求する。

図３は、対応テーブル５２と被保険者データベース８０の例を説明する図である。対応テーブル５２は、ＦＩＤＯ−ＩＤごとに、健保アクセストークン、クレカアクセストークン識別子、病院アクセストークン識別子、薬局アクセストークン識別子を記憶する。ここで、ＦＩＤＯ−ＩＤは、ＦＩＤＯ登録に成功した各々のユーザを一意に識別可能な識別子である。健保アクセストークンは、エントリ中のＦＩＤＯ−ＩＤで識別されるユーザに対して発行されている保険証の情報の照会に使用可能なアクセストークンである。クレカアクセストークン識別子は、エントリ中のＦＩＤＯ−ＩＤで識別されるユーザのクレジットカードを用いた支払処理に使用されるアクセストークン（クレカアクセストークン）を識別する識別子である。病院アクセストークン識別子は、エントリ中のＦＩＤＯ−ＩＤで識別されるユーザの診察券情報を取得する際に使用されるアクセストークン（病院アクセストークン）を識別する識別子である。薬局アクセストークン識別子は、エントリ中のＦＩＤＯ−ＩＤで識別されるユーザの薬の調剤結果の通知などに使用するアクセストークン（薬局アクセストークン）を識別する識別子である。

被保険者データベース８０は、被保険者情報テーブル８１、病院アクセストークンテーブル８２、クレカアクセストークンテーブル８３、薬局アクセストークンテーブル８４を備える。被保険者情報テーブル８１は、健保アクセストークンの取得に成功したユーザに対応付けられた情報を記憶する。被保険者情報テーブル８１は、ＦＩＤＯ−ＩＤ、ステータス情報、位置情報、処方箋情報、調剤結果情報、および、支払情報を備える。ステータス情報は、エントリ中のＦＩＤＯ−ＩＤで識別されるユーザの現在の状態を表わす。ステータス情報は、例えば、「診療待ち」、「処方待ち」などに設定される。位置情報は、エントリ中のＦＩＤＯ−ＩＤで識別されるユーザが保持する端末２０の現在位置を表わす情報である。処方箋情報は、端末２０のユーザに対して発行された処方箋の情報である。調剤結果情報は、エントリ中のＦＩＤＯ−ＩＤで識別されるユーザの薬の調剤結果である。支払情報は、エントリ中のＦＩＤＯ−ＩＤで識別されるユーザについての、病院や薬局への支払状況を表わす情報である。

病院アクセストークンテーブル８２は、病院アクセストークン識別子、病院アクセストークン、および、アクセストークンを発行した病院の情報の対応関係を記録する。クレカアクセストークンテーブル８３は、クレカアクセストークン識別子、クレカアクセストークン、および、アクセストークンを発行した金融機関の情報の対応関係を記録する。薬局アクセストークンテーブル８４は、薬局アクセストークン識別子、薬局アクセストークン、および、アクセストークンを発行した薬局の情報の対応関係を記録する。

図３の例では、被保険者データベース８０は、病院アクセストークンテーブル８２、クレカアクセストークンテーブル８３、薬局アクセストークンテーブル８４を保持するが、対応テーブル５２は健保アクセストークン以外のアクセストークンは含まない。このように、複数のアクセストークンをＦＩＤＯ−ＩＤに直接対応付けて記録しないことにより、全てのアクセストークンが直接的にＦＩＤＯ−ＩＤに対応付けられている場合に比べて、アクセストークンを保持する際のセキュリティが強化されている。ただし、図３は、一例であり、テーブル中の情報要素や被保険者情報テーブル８１中の情報要素は、実装に応じて変更され得る。

図４は、情報処理装置３０、および、サーバ装置のハードウェア構成の例を説明する図である。情報処理装置３０、健保サーバ２、病院サーバ４、薬局サーバ６、金融機関サーバ８のいずれも、プロセッサ１０１、メモリ１０２、バス１０３、ネットワーク接続装置１０４を有する。プロセッサ１０１は、任意の処理回路であり、例えば、ＣＰＵ（Central Processing Unit）とすることができる。プロセッサ１０１は、メモリ１０２をワーキングメモリとして使用して、プログラムを実行することにより、様々な処理を実行する。メモリ１０２には、ＲＡＭ（Random Access Memory）が含まれ、さらに、ＲＯＭ（Read Only Memory）等の不揮発性のメモリも含まれる。メモリ１０２は、プログラムやプロセッサ１０１での処理に使用されるデータの格納に使用される。ネットワーク接続装置１０４は、ネットワークを介した他の装置との通信に使用される。バス１０３は、プロセッサ１０１、メモリ１０２、ネットワーク接続装置１０４を、互いにデータの入出力が可能になるように接続する。

情報処理装置３０において、プロセッサ１０１は、認証処理部４１、取得部４２、制御部６０として動作し、メモリ１０２は記憶部５０および記憶部７０として動作する。さらに、ネットワーク接続装置１０４は、通信部３１として動作する。健保サーバ２において、保険証データベース３はメモリ１０２に格納されている。病院サーバ４では病院データベース５はメモリ１０２に格納され、薬局サーバ６では薬局データベース７はメモリ１０２に格納される。さらに、金融機関サーバ８では金融データベース９はメモリ１０２に格納される。情報処理装置３０、健保サーバ２、病院サーバ４、薬局サーバ６、金融機関サーバ８のいずれも、コンピュータ、サーバ装置等として実現され得る。

図５は、端末２０、および、受付装置１０のハードウェア構成の例を説明する図である。受付装置１０と端末２０のいずれも、プロセッサ１１１、メモリ１１２、入力装置１１３、表示装置１１４、カメラ２２、無線処理回路１１６、バス１１７を備える。端末２０は、さらに、生体情報リーダ１１８を備える。バス１１７は、プロセッサ１１１、メモリ１１２、入力装置１１３、表示装置１１４、カメラ２２、無線処理回路１１６をデータの入出力が可能なように接続する。プロセッサ１１１は、任意の処理回路であり、例えば、ＣＰＵであっても良い。メモリ１１２は、ＲＯＭとＲＡＭを備えるものとする。

端末２０において、メモリ１１２は、記憶部２６として動作する。端末２０において、プロセッサ１１１は、ＲＯＭに記録されているプログラムを読み込んで、アプリ処理部２３を実現する。入力装置１１３は、タッチパネルやボタンなど、情報の入力に使用される任意の装置であり、表示装置１１４は、ディスプレイを含む表示デバイスである。表示部２５は、プロセッサ１１１と表示装置１１４によって実現される。無線処理回路１１６は、受付装置１０や端末２０が通信する際の無線通信の処理を行う。端末２０の通信部２１は、プロセッサ１１１と無線処理回路１１６によって実現される。生体情報リーダ１１８は、ＦＩＤＯ認証などに使用される生体情報の読み取りを行う。従って、認証処理部２４は、プロセッサ１１１と生体情報リーダ１１８によって実現される。端末２０は、スマートフォンを含む携帯電話端末、タブレット、コンピュータ等として実現される。

＜実施形態＞
以下、実施形態を、保険証の登録処理、診察券の登録処理、クレジットカードの登録処理、診察受付、診察料金の支払処理、薬を受け取る薬局の指定処理、および、薬の受け取り処理に分けて説明する。なお、端末２０には、実施形態にかかる情報提供方法を用いるためのアプリケーションが事前にインストールされているものとする。

（１）保険証の登録処理
図６は、保険証情報の登録処理の例を説明するフローチャートである。図７は、保険証データベース３と対応テーブル５２の例を説明する図である。以下、図６と図７を参照しながら、保険証の登録の際に行われる処理の例を説明する。なお、以下の説明では、予め、ユーザが使用するメールアドレスが健保サーバ２に登録されているものとする。

端末２０のユーザの処理に応じて、アプリ処理部２３は、表示部２５に保険証の登録画面を表示させているとする。この状態で、ユーザがユーザ自身に対して発行された保険証の券面を、端末２０のカメラ２２を用いて撮影したとする（ステップＳ２１）。アプリ処理部２３は、撮影された画像をＯＣＲ（Optical character recognition）処理することにより、保険証の券面に印字されている保険証番号や被保険者氏名などの情報を特定する。画像をＯＣＲ処理する際に、アプリ処理部２３は、適宜、ＡＩ（artificial intelligence）などを用いたフォーマットレスのＯＣＲ技術を用いても良く、また、予め記憶している保険証のフォーマットに基づいて、個々の情報を読取っても良い。アプリ処理部２３は、得られた保険証番号と被保険者氏名を、通信部２１を介して情報処理装置３０に送信する（ステップＳ２２）。

情報処理装置３０の取得部４２は、通信部３１を介して、保険証番号と被保険者氏名を取得する。取得部４２は、保険証の情報の登録に用いられるＰＩＮを発行する。取得部４２は、発行したＰＩＮを端末２０の情報に対応付けてＰＩＮ情報５１として記憶部５０に記憶させる。取得部４２は、保険証番号と被保険者氏名の組み合わせとともに、発行したＰＩＮを健保サーバ２に送信する（ステップＳ２３）。

健保サーバ２は、保険証番号と被保険者氏名の組み合わせ、および、ＰＩＮを受信すると、受信した保険証番号と被保険者氏名の組み合わせを含む有効な保険証が保険証データベース３に登録されているかを判定する（ステップＳ２４）。保険証番号と被保険者氏名の組み合わせを含む有効な保険証が登録されていない場合、健保サーバ２は処理を終了する（ステップＳ２４でＮｏ）。保険証番号と被保険者氏名の組み合わせを含む有効な保険証が登録されている場合、健保サーバ２は、登録が確認された保険証の情報に対応付けて予め登録されているメールアドレスに、ＰＩＮを送信する（ステップＳ２４でＹｅｓ、ステップＳ２５）。なお、健保サーバ２は、ＰＩＮを発行する契機となった保険証の情報とＰＩＮを対応付けているものとする。

端末２０のユーザは、メールを確認することにより、ＰＩＮを取得すると、端末２０にＰＩＮを入力する。例えば、ユーザは、端末２０を操作することにより、ＰＩＮの入力画面を表示させて、ＰＩＮの入力画面にＰＩＮを入力できる。アプリ処理部２３は、入力されたＰＩＮを情報処理装置３０に送信する（ステップＳ２６）。

情報処理装置３０の取得部４２は、端末２０から受信したＰＩＮと端末２０の情報を、ＰＩＮ情報５１と照合する（ステップＳ２７）。ＰＩＮコードの照合に失敗すると、取得部４２は処理を終了する（ステップＳ２７でＮｏ）。ＰＩＮコードの照合に成功すると、取得部４２は、健保サーバ２に対して、保険組合の組合員情報へのアクセスと、組合員情報の利用認可を要求するために、照合済みのＰＩＮを送信する（ステップＳ２８）。以下の説明では、保険組合の組合員情報へのアクセスと組合員情報の利用認可を要求する処理は、健保アクセストークンの発行を要求することにより行われる。換言すると、健保アクセストークンの要求は、保険証番号などの保険証に関する個人情報を、端末２０での本人確認の結果に基づいて使用する許可を求めていることになるものとする。

健保サーバ２は、情報処理装置３０からＰＩＮを受信すると、受信したＰＩＮを発行する契機となった保険証の情報の照会に使用可能な健保アクセストークンを生成する（ステップＳ２９）。健保サーバ２は、健保アクセストークンを、そのアクセストークンで照会される対象の情報と対応付ける。

図７の保険証データベース３は、健保アクセストークンと保険証の登録情報の対応付けの例である。図７の保険証データベース３には、保険証番号＝１２３４５６７の被保険者の氏名が「富士通太郎」であり、この被保険者の保険証の照会には、健保アクセストークン「ＫＮＰＴ１」が使用されることが記録されている。健保サーバ２は、健保アクセストークンを情報処理装置３０に送信する。

図６のステップＳ３０において、情報処理装置３０中の取得部４２は、取得した健保アクセストークンを対応テーブル５２に登録する。認証処理部４１は、端末２０に対して、ユーザのＦＩＤＯ認証を要求する（ステップＳ３１）。

端末２０では、アプリ処理部２３は、生体情報の読み取りをユーザに要求する画面を表示部２５に表示する。ユーザは、既に登録してある生体情報に対応する、ユーザ自身の指紋などの生体情報を生体情報リーダ１１８に読取らせる。すると、認証処理部２４は、生体情報リーダ１１８から読取ったユーザの生体情報と、予め登録されている生体情報を比較することにより、生体認証処理を行う（ステップＳ３２）。生体認証に失敗すると、認証処理部２４は処理を終了する（ステップＳ３２でＮｏ）。一方、生体認証に成功すると、認証処理部２４は、ＦＩＤＯ クライアントのオーセンティケータ（Authenticator）として、認証フェーズで用いるための秘密鍵と公開鍵を生成する。認証処理部２４は、生体認証に成功したことを表わす情報として、公開鍵を情報処理装置３０に通知する（ステップＳ３２でＹｅｓ）。

情報処理装置３０の認証処理部４１は、端末２０から受信した公開鍵を格納すると共に、端末２０のユーザを識別するためのＦＩＤＯ−ＩＤを生成する。さらに、認証処理部４１は、ＦＩＤＯ−ＩＤに対応付けて、端末２０のユーザについて取得した健保アクセストークンを登録する（ステップＳ３３）。図７の対応テーブル５２ａは、健保アクセストークンとＦＩＤＯ−ＩＤが登録された場合の例である。対応テーブル５２ａには、健保アクセストークン「ＫＮＰＴ１」のユーザに対して、ＦＩＤＯ−ＩＤ「ＩＤ＿Ａ」が生成されている。

なお、図６は処理の一例である。例えば、ステップＳ３１〜Ｓ３３の処理がステップＳ２８〜Ｓ３０の処理と並行して行われるなど、処理の順序が実装に応じて変更され得る。

（２）診察券の登録処理
図８は、診察券の登録処理の例を説明するフローチャートである。図９は、病院データベース５と対応テーブル５２の例を説明する図である。以下、図７〜図９を参照しながら診察券の登録例を説明する。

端末２０のユーザの処理により、アプリ処理部２３は、表示部２５に診察券の登録画面を表示させているとする。この状態で端末２０のユーザは、診察券の券面を、端末２０のカメラ２２を用いて撮影する（ステップＳ４２）。アプリ処理部２３は、撮影された画像をＯＣＲ処理することにより、診察券に印字されている診察券番号や氏名などの情報を特定する（ステップＳ４３）。アプリ処理部２３は、得られた診察券番号や氏名を、情報処理装置３０に送信する。このとき、アプリ処理部２３は、診察券の登録情報を送信していることを通知する情報も、診察券番号や氏名と共に情報処理装置３０に送信しても良い。

情報処理装置３０の認証処理部４１は、端末２０に対してＦＩＤＯ認証を要求する（ステップＳ４４）。このとき、認証処理部４１は、乱数などの情報をチャレンジとして端末２０に送信する。端末２０のアプリ処理部２３は、生体情報の入力をユーザに要求する画面を表示部２５に表示する。認証処理部２４は、ユーザが生体情報リーダ１１８に読取らせた生体情報と、予め登録されている生体情報を比較することにより、生体認証処理を行う（ステップＳ４５）。生体認証に失敗すると、認証処理部２４は処理を終了する（ステップＳ４５でＮｏ）。一方、生体認証に成功すると、認証処理部２４は、ＦＩＤＯ登録の際に生成した秘密鍵を用いてチャレンジに署名した情報を、生体認証に成功したことを表わす情報として情報処理装置３０に通知する（ステップＳ４５でＹｅｓ）。情報処理装置３０の認証処理部４１は、公開鍵を用いて端末２０から受信した署名を検証する。情報処理装置３０は、検証に成功すると、ユーザに対するＦＩＤＯ認証を完了する。さらに、署名の検証に成功したときに使用した公開鍵に対応付けられたＦＩＤＯ−ＩＤを、ユーザのＦＩＤＯ−ＩＤとして特定する。

ＦＩＤＯ認証が完了するとユーザのＦＩＤＯ−ＩＤが特定されるので、取得部４２は、ユーザのＦＩＤＯ−ＩＤに対応付けられている健保アクセストークンを用いて、健保サーバ２に、ユーザの保険証番号の照会を要求する（ステップＳ４６）。例えば、ＦＩＤＯ認証により、ユーザのＦＩＤＯ−ＩＤがＩＤ＿Ａであることが特定されたとする。すると、取得部４２は、図７の対応テーブル５２ａから、ＩＤ＿Ａに対応付けられた健保アクセストークンとしてＫＮＰＴ１を特定する。すると、取得部４２は、特定した健保アクセストークン（ＫＮＰＴ１）を用いて健保サーバ２に照会を要求する。健保サーバ２は、照会の要求に応答して、保険証番号を情報処理装置３０に通知する（ステップＳ４７）。図７中の保険証データベース３の例では、健保サーバ２は、保険証番号＝１２３４５６７を、情報処理装置３０に通知する。情報処理装置３０の取得部４２は、保険証番号を取得すると共に、端末２０に保険証番号を通知する（ステップＳ４８）。

端末２０が保険証番号を取得すると、アプリ処理部２３は、ステップＳ４２で撮影した診察券の情報に対応付ける病院を特定する情報の入力を待つ（ステップＳ４９でＮｏ）。なお、ステップＳ４３でのＯＣＲ処理の際に病院名が読取られている場合には、アプリ処理部２３は、ＯＣＲ処理で読取られた病院名を、病院を特定する情報として使用しても良い。病院を特定する情報が入力されると、アプリ処理部２３は、登録先の病院の情報と共に、保険証番号、診察券番号、および、ユーザの氏名を含む登録要求を、情報処理装置３０に送信する（ステップＳ５０）。

情報処理装置３０の取得部６１は、登録要求を受信すると、病院情報７１を用いて、登録先の病院が使用する情報を管理している病院サーバ４を特定する。取得部６１は、特定した病院サーバ４に対して、保険証番号、診察券番号、および、ユーザの氏名を送信すると共に、病院アクセストークンを要求する（ステップＳ５１）。病院サーバ４は、情報処理装置３０から受信した情報を、病院データベース５に登録されている情報と比較することにより検証する（ステップＳ５２）。診察券番号とユーザの氏名の組み合わせが病院データベース５に登録されていない場合、病院サーバ４は処理を終了する（ステップＳ５２でＮｏ）。一方、診察券番号とユーザの氏名の組み合わせが病院データベース５に登録されている場合、病院サーバ４は、病院アクセストークンを生成し、情報処理装置３０に送信する（ステップＳ５２でＹｅｓ、ステップＳ５３）。さらに、病院サーバ４は、病院アクセストークンを病院データベース５に記録する。例えば、診察券番号＝１２３で氏名が「富士通太郎」の患者に対して、ＨＰＴ１という病院アクセストークンが生成されたとする。この場合、図９の病院データベース５に示すように、ＨＰＴ１というアクセストークンが対応する患者の情報に対応付けて保存される。

次に、病院アクセストークンを受信したときの情報処理装置３０の処理について説明する。情報処理装置３０の取得部６１は、病院アクセストークンを病院アクセストークンテーブル８２に登録すると共に、病院アクセストークン識別子を生成する（図８のステップＳ５４）。例えば、取得部６１は、ＨＰＴ１という病院アクセストークンの識別子を、ＩＤ＿ｈｐｔ１に決定したとする。すると、図９の病院アクセストークンテーブル８２ａに示すように、病院アクセストークンと病院アクセストークン識別子が対応付けられる。病院アクセストークンテーブル８２ａの例では、取得部６１は、ＨＰＴ１という病院アクセストークンを発行した病院の情報として、Ｙ病院の情報も登録している。さらに、認証情報処理部４０の取得部４２は、病院アクセストークン識別子を、ユーザを識別するＦＩＤＯ−ＩＤに対応付けて対応テーブル５２に記録する（図８のステップＳ５５）。この例では、ＦＩＤＯ−ＩＤ＝ＩＤ＿Ａのユーザの情報照会用に、ＨＰＴ１という病院アクセストークンが生成されている。このため、取得部４２は、ＨＰＴ１という病院アクセストークンを識別する識別子ＩＤ＿ｈｐｔ１を、ＦＩＤＯ−ＩＤ＝ＩＤ＿Ａに対応付けて対応テーブル５２に記録する。このため、図７の対応テーブル５２ａは、図９の対応テーブル５２ｂに示すように更新される。

（３）クレジットカードの登録処理
図１０は、クレジットカードの登録処理の例を説明するフローチャートである。端末２０のユーザの処理により、アプリ処理部２３は、表示部２５の画面にクレジットカードの登録画面を表示させているとする。この状態で端末２０のユーザは、クレジットカードの券面を、端末２０のカメラ２２を用いて撮影する（ステップＳ６１）。アプリ処理部２３は、撮影された画像をＯＣＲ処理することにより、クレジットカードに印字されているカード番号、名義人氏名、有効期限などの情報を特定すると共に、得られた情報を情報処理装置３０に送信する（ステップＳ６２）。このとき、アプリ処理部２３は、クレジットカードの登録情報を送信していることを通知する情報も、診察券番号や氏名と共に情報処理装置３０に送信しても良い。

情報処理装置３０の取得部６１は、金融機関サーバ８に対して、カード番号、名義人氏名、有効期限などの情報を通知して、通知した情報で特定されるクレジットカードを用いた決済に使用可能なクレカアクセストークンを要求する（ステップＳ６３）。金融機関サーバ８は、通知されたクレジットカード情報に対応付けてＰＩＮを生成すると、予め登録されているユーザの端末２０に対してＰＩＮを要求する（ステップＳ６４）。なお、予め、金融機関サーバ８に登録してあるメールアドレスなどを用いて、ユーザには、金融機関サーバ８で生成されたＰＩＮが通知されているものとする。ユーザがＰＩＮを入力すると、端末２０は、入力されたＰＩＮを金融機関サーバ８に送信する（ステップＳ６５）。金融機関サーバ８は、端末２０から通知されたＰＩＮをステップＳ６４で生成したＰＩＮと比較することにより検証する（ステップＳ６６）。ＰＩＮが正しくないと判定すると、金融機関サーバ８は処理を終了する（ステップＳ６６でＮＧ）。ＰＩＮが正しいと判定すると、金融機関サーバ８は、ユーザのクレジットカードを用いた決済に使用可能なクレカアクセストークンを生成する（ステップＳ６６でＯＫ、ステップＳ６７）。

図１１は、クレカアクセストークンの格納例を示す。例えば、カード番号＝１２３４５６で名義人が「富士通太郎」、有効期限が２０２０年１０月のクレジットカードに対して発行したＰＩＮの検証の結果、正しいＰＩＮが端末２０から送信されたと判定されているとする。さらに、金融機関サーバ８は、これらの情報で特定されるクレジットカードの決済に使用可能なクレカアクセストークンを、ＣＣＴ１としたとする。すると、金融データベース９には、図１１に示すように情報が格納される。金融機関サーバ８は、クレカアクセストークンを情報処理装置３０に送信する。

取得部６１は、クレカアクセストークンを識別する識別子と共に、クレカアクセストークンを、クレカアクセストークンテーブル８３に登録する（図１０のステップＳ６８）。図１１は、クレカアクセストークンがＣＣＴ１であって、クレカアクセストークン識別子がＩＤ＿ｃｃｔ１である場合について、クレカアクセストークンテーブル８３の登録例を示している。なお、図１１の例では、ＣＣＴ１というクレカアクセストークンを発行した金融機関サーバ８は、カード会社Ｂの発行しているカードの情報を管理するサーバであるものとする。

認証処理部４１は、クレカアクセストークン識別子をどのＦＩＤＯ−ＩＤに対応付けて記録するかを確認するために、端末２０にＦＩＤＯ認証を要求する（図１０のステップＳ６９）。ステップＳ６９〜Ｓ７０で行われるＦＩＤＯ認証の処理は、図８を参照しながら説明したステップＳ４４〜Ｓ４５の処理と同様である。ユーザに対するＦＩＤＯ認証が完了すると、認証処理部４１は、ユーザのＦＩＤＯ−ＩＤを特定する。すると、取得部４２は、特定されたＦＩＤＯ−ＩＤに対応付けて、クレカアクセストークン識別子を対応テーブル５２に登録する（ステップＳ７１）。例えば、ユーザのＦＩＤＯ−ＩＤがＩＤ＿Ａであることが特定された場合、取得部４２は、クレカアクセストークン識別子ＩＤ＿ｃｃｔ１をＦＩＤＯ−ＩＤ＝ＩＤ＿Ａに対応付けて対応テーブル５２に記録する。このため、対応テーブル５２ｂ（図９）は、図１１の対応テーブル５２ｃに示すように更新される。

（４）診察受付
図１２は、診察受付前の端末２０の表示例を説明する図である。保険証の登録と診察券の登録が終わると、アプリ処理部２３は、診察券の情報の登録処理が終わっている病院を通院先として選択可能な画面を、表示部２５の画面に表示できる。図１２の例では、Ｙ病院から発行された診察券とＸ内科から発行された診察券の登録が終わっているとする。病院を通院先として選択可能な画面では、個々の病院に対応付けられたアイコンはユーザが選択可能であるとする。

図１３は、診察の受付処理の例を説明するフローチャートである。図１４は、診察の受付処理の際に行われるデータの更新の例を説明する図である。以下、図１２〜図１４を参照しながら、診察の受付処理の際に行われる処理の例を説明する。

図１２に示すような画面が端末２０に表示されている状態で、ユーザが病院のアイコンを選択すると、アプリ処理部２３は、アイコンに対応付けられている病院への診察受付が行われると認識する。そこで、アプリ処理部２３は、選択されたアイコンに対応付けられた病院を指定する情報（病院指定情報）を情報処理装置３０に送信する（図１３のステップＳ８１）。以下の例では、Ｙ病院に対応付けられたアイコンが指定されたとする。

情報処理装置３０の認証処理部４１は、病院指定情報を受信すると、診察券や保険証の情報の取得に使用するアクセストークンを特定するために、端末２０にＦＩＤＯ認証を要求する（ステップＳ８２）。ステップＳ８２〜Ｓ８３で行われるＦＩＤＯ認証の処理は、図８を参照しながら説明したステップＳ４４〜Ｓ４５の処理と同様である。ユーザに対するＦＩＤＯ認証が完了すると、認証処理部４１は、ユーザのＦＩＤＯ−ＩＤを特定する。

取得部４２は、ユーザのＦＩＤＯ−ＩＤを用いて、診察券の情報の照会に使用する病院アクセストークンを確定する（ステップＳ８４）。このとき、取得部４２は、特定されたＦＩＤＯ−ＩＤに対応付けられている病院アクセストークン識別子のうち、通知された病院指定情報に対応付けられている病院アクセストークン識別子を、診察券の情報の照会に使用するアクセストークンの識別子とする。例えば、端末２０で病院のアイコンが選択された時点では、情報処理装置３０は、図１４に示す対応テーブル５２ｄと病院アクセストークンテーブル８２を保持しているとする。また、ＦＩＤＯ認証により、ユーザのＦＩＤＯ−ＩＤがＩＤ＿Ａであることが特定されたとする。すると、取得部４２は、ＦＩＤＯ−ＩＤ＝ＩＤ＿Ａに対応付けられている病院アクセストークン識別子のうち、病院指定情報で指定されたＹ病院から発行されたアクセストークンの識別子を特定する。このとき、取得部４２は、適宜、病院アクセストークンテーブル８２を参照する。その結果、図１４の例では、取得部４２は、使用するアクセストークンの識別子としてＩＤ＿ｈｐｔ１を選択する。さらに、取得部４２は、得られた識別子をキーとして、病院アクセストークンテーブル８２（図１４）を検索することにより、診察券の情報の照会に使用する病院アクセストークンを、ＨＰＴ１に確定する。

取得部４２は、確定した病院アクセストークンを取得部６１とサービス処理部６３に通知する。取得部６１は、確定された病院アクセストークンを用いて、Ｙ病院の情報を保持する病院サーバ４に対して、診察券番号の照会を要求する（図１３のステップＳ８５）。また、サービス処理部６３は、確定した病院アクセストークンとユーザのＦＩＤＯ−ＩＤを、受付処理中のユーザの情報として記憶する。病院サーバ４は、病院アクセストークンの有効性を検証する（ステップＳ８６）。病院アクセストークンが有効ではない場合、病院サーバ４は処理を終了する（ステップＳ８６でＮＧ）。病院アクセストークンが有効である場合、病院サーバ４は、病院アクセストークンに対応付けられた診察券番号を情報処理装置３０に送信する（ステップＳ８６でＯＫ、ステップＳ８７）。例えば、病院サーバ４が保持している病院データベース５の情報が、図１４の病院データベース５ａに示すとおりであるとする。さらに、照会に使用されている病院アクセストークンがＨＰＴ１であるとする。この場合、病院サーバ４は、診察券番号＝１２３を情報処理装置３０に通知する。

診察券情報の照会と並行して、保険証情報の照会も行われる。このとき、取得部４２は、特定されたＦＩＤＯ−ＩＤに対応付けられている健保アクセストークンを、対応テーブル５２から特定する。例えば、図１４に示す対応テーブル５２ｄを情報処理装置３０が保持していて、ユーザのＦＩＤＯ−ＩＤがＩＤ＿Ａである場合、取得部４２は、照会に使用する健保アクセストークンをＫＮＰＴ１に決定する。取得部４２は、決定した健保アクセストークンを用いて、保険証情報の照会を健保サーバ２に要求する（図１３のステップＳ８８）。健保サーバ２は、健保アクセストークンの有効性を検証する（ステップＳ８９）。健保アクセストークンが有効ではない場合、健保サーバ２は処理を終了する（ステップＳ８９でＮＧ）。健保アクセストークンが有効である場合、健保サーバ２は、健保アクセストークンに対応付けられた保険証番号と被保険者の氏名を情報処理装置３０に送信する（ステップＳ８９でＯＫ、ステップＳ９０）。例えば、健保サーバ２が保持している保険証データベース３の情報が、図１４に示すとおりであり、照会に使用されている健保アクセストークンがＫＮＰＴ１であるとする。この場合、健保サーバ２は、保険証番号＝１２３４５６７と、被保険者名＝富士通太郎を情報処理装置３０に通知する。

情報処理装置３０のＱＲコード生成部６２は、病院サーバ４から送信された診察券番号と、健保サーバ２から送信された保険証番号および被保険者氏名を取得し、これらの情報を合わせた情報を生成（マージ）する。ＱＲコード生成部６２は、マージした情報を通知するＱＲコードを生成する（図１３のステップＳ９１）。サービス処理部６３は、生成したＱＲコードを端末２０に送信する。このとき、サービス処理部６３は、受付処理中のユーザの情報として記憶しているユーザのＦＩＤＯ−ＩＤを用いて、送信先の端末２０の情報を特定する。なお、図示していないが、送信先の端末２０の情報も、ＦＩＤＯ−ＩＤに対応付けて被保険者データベース８０に含まれているものとする。端末２０の情報として例えば、アプリコードなどが被保険者データベース８０に記録され得る。端末２０のアプリ処理部２３は、情報処理装置３０から受信したＱＲコードを表示部２５に表示させる（ステップＳ９２）。ユーザは、ＱＲコードが表示された端末２０の画面を受付装置１０にかざす。すると、受付装置１０は、端末２０の画面に表示されているＱＲコードを読取る（ステップＳ９３）。受付装置１０は、ＱＲコードに含まれている診察券番号、保険証番号、被保険者氏名の組み合わせを病院サーバ４に送信し、病院サーバ４は受付装置１０から受信した情報を用いて、受付処理を行う（ステップＳ９４）。

病院サーバ４は、受付処理が終わると、受付処理を行った患者の病院アクセストークンと、受付完了を通知する情報を情報処理装置３０に送信する。情報処理装置３０のサービス処理部６３は、受信した病院アクセストークンに関連付けられたＦＩＤＯ−ＩＤのユーザについて、被保険者情報テーブル８１に登録されているステータスを「診察待ち」に更新する（ステップＳ９５）。さらに、アプリ制御部６４は、端末２０に対して、受付済みであることを通知すると共に、受付済みであることを端末２０の画面に表示するように要求する。端末２０のアプリ処理部２３は、情報処理装置３０からの要求に応じて、画面の表示を変更して、診察の受付済みであることを表示する（ステップＳ９６）。

図１４の被保険者情報テーブル８１ａは、図１３のステップＳ９５の処理によるステータスの変更例である。例えば、Ｙ病院の病院サーバ４から、ＨＰＴ１の病院アクセストークンに対応付けられた患者の受付が終了したことが情報処理装置３０に通知されたとする。また、サービス処理部６３は、受付処理中のユーザのＦＩＤＯ−ＩＤがＩＤ＿Ａであり、そのユーザの病院アクセストークンはＨＰＴ１であることを記憶しているとする。すると、サービス処理部６３は、図１４の被保険者情報テーブル８１ａに示すように、ＦＩＤＯ−ＩＤがＩＤ＿Ａのユーザのステータス状態を、「診察待ち（Ｙ病院）」に更新する。

なお、図１３は処理の一例であり、実装に応じて処理手順は変更され得る。例えば、ステップＳ８４〜Ｓ８７の処理とステップＳ８８〜Ｓ９０の処理は、並行に行われても良いし、何れか一方が他方よりも前に行われても良い。

図１５は、診察受付の際の端末２０の表示例を説明する図である。図１５の画面Ｇ１は、受付処理に使用するＱＲコードの表示例である。図１３のステップＳ９２の処理により、画面Ｇ１に示すように、ＱＲコードが端末２０の画面に表示される。なお、画面には、ＱＲコード以外の情報も表示されていても良い。画面Ｇ１の例では、ユーザや病院の受付処理を行うオペレータが分かりやすいように、ＱＲコードの他に、ユーザの氏名、保険証番号、生年月日などの情報が表示されている。なお、生年月日は、保険証番号等と共に、健保サーバ２から情報処理装置３０を介して端末２０に通知され得る。さらに、画面Ｇ１の例では、ユーザがクレジットカードの登録済みであるため、実施形態にかかるシステムを用いた支払処理が事前に承認されていることも表示されている。

画面Ｇ２は、ユーザのステータスの表示例である。画面Ｇ２には、ユーザが診察券を登録している病院の各々に対応付けられたアイコンが表示されている。Ｙ病院のアイコン上にユーザが診察待ちであることを示す表示Ａが含まれている。なお、このようなアイコンの描画の変更は、情報処理装置３０のアプリ制御部６４からの要求に応じて、端末２０のアプリ処理部２３が行う。

情報処理装置３０は、ユーザの認証が成功したときに、診察受付に使用するデータを自律的に生成して、端末２０に提供している。換言すると、ユーザの認証に成功しないと、情報処理装置３０から端末２０に診察受け付け用のデータが送られてこない。従って、実施形態にかかるシステムでは、保険証や診察券が端末２０の正規ユーザ以外の者によって不正に使用されることを防止できる。

ところで、実施形態にかかるシステムでは、端末２０に提供されたＱＲコードを受付装置１０に撮影させることで診察の受付が終了する。このため、実施形態にかかるシステムでは、診察券や保険証の提示が求められていた従来の受付処理に比べて、診察の受付処理が格段に便利になっている。

さらに、情報処理装置３０は、ユーザの保険証の情報や診察券の情報を保持しておらず、ユーザの認証の成功に応じて、健保サーバ２や病院サーバ４にこれらの情報を問合わせている。すなわち、保険証の登録内容や診察券の情報などのユーザの個人情報は、情報処理装置３０に定常的に記憶されてはいない。従って、実施形態にかかるシステムでは、ユーザの個人情報を情報処理装置３０が端末２０に提供可能であるが、情報処理装置３０からユーザの個人情報が流出する危険性は小さい。

（５）診察料金の支払処理
図１６は、診察料金の支払処理の例を説明するフローチャートである。図１７は、診察料金の支払処理の際に行われるデータの更新の例を説明する図である。以下、図１６、図１７を参照しながら、診察料金の支払の際に行われる処理の例を説明する。

病院での診察が終了すると、病院サーバ４では、支払の請求情報等が生成される（図１６のステップＳ１０１）。図１７の病院データベース５ｂは、請求情報が生成された場合の病院データベース５の例である。病院データベース５ｂでは、診察券番号＝１２３、氏名＝富士通太郎の患者に対して９８０円の請求情報が記録されている。なお、この例では、処方箋情報も記録されているが、処方箋情報は診察料金の支払いが確認された後で生成されてもよい。その後、病院サーバ４は、情報処理装置３０に、診察料金の請求情報と病院アクセストークンを送信する（図１６のステップＳ１０２）。

情報処理装置３０の取得部４２は、病院アクセストークンを用いて、診察料金の支払いが請求されたユーザのＦＩＤＯ−ＩＤを特定する（ステップＳ１０３）。図１７の例では、情報処理装置３０は病院アクセストークン＝ＨＰＴ１を請求情報と共に受信するので、取得部４２は、病院アクセストークンテーブル８２を参照することにより、受信した病院アクセストークンを識別する識別子がＩＤ＿ｈｐｔ１であると認識する。そこで、取得部４２は、病院アクセストークン識別子＝ＩＤ＿ｈｐｔ１をキーとして対応テーブル５２ｄを検索することにより、診察料金が請求されたユーザのＦＩＤＯ−ＩＤがＩＤ＿Ａであることを認識する。

取得部４２は、診察料金が請求されたユーザのＦＩＤＯ−ＩＤと請求情報をサービス処理部６３に出力する。サービス処理部６３は、診察料金が請求されたユーザについて、被保険者情報テーブル８１中のステータス状態と支払情報を更新する。図１７の被保険者情報テーブル８１ｂは、サービス処理部６３が、ＦＩＤＯ−ＩＤ＝ＩＤ＿Ａのユーザのステータス状態を、「支払待ち（Ｙ病院）」に更新した場合の被保険者情報テーブル８１の例である。図１７の例では、請求金額が９８０円で、支払先がＹ病院であることも被保険者情報テーブル８１ｂに記録されている。サービス処理部６３は、診察料金が請求されたユーザのＦＩＤＯ−ＩＤに対応付けられた端末２０に対して、請求情報を送信する（図１６のステップＳ１０４）。

端末２０のアプリ処理部２３は、受信した請求情報を、表示部２５が備える画面に表示することにより、ユーザに支払いの確認を要求する（図１６のステップＳ１０５）。例えば、この例では、診察料金＝９８０円、支払先＝Ｙ病院という情報と、承認ボタンが表示され得る。端末２０のユーザは、請求情報を確認し、問題ないと判断すると、画面に表示された承認ボタンを押し下す。すると、アプリ処理部２３は、支払処理の要求を情報処理装置３０に送信する。

情報処理装置３０の取得部４２は、支払処理の要求を受信すると、端末２０にＦＩＤＯ認証を要求する（ステップＳ１０６）。ステップＳ１０６〜Ｓ１０７で行われるＦＩＤＯ認証の処理は、図８を参照しながら説明したステップＳ４４〜Ｓ４５の処理と同様である。ユーザに対するＦＩＤＯ認証が完了すると、認証処理部４１は、ユーザのＦＩＤＯ−ＩＤを特定する。

取得部４２は、支払処理に使用するクレカアクセストークンを確定する（ステップＳ１０８）。このとき、取得部４２は、特定されたＦＩＤＯ−ＩＤに対応付けられているクレカアクセストークン識別子で識別されるクレカアクセストークンを、支払処理に使用するアクセストークンとする。例えば、支払い請求が行われた時点で図１７に示す対応テーブル５２ｄを保持しているとする。また、ユーザのＦＩＤＯ−ＩＤがＩＤ＿Ａであることが特定されたとする。すると、取得部４２は、クレカアクセストークン識別子＝ＩＤ＿ｃｃｔ１で識別されるアクセストークンを支払い処理に使用することを決定する。さらに、クレカアクセストークンテーブル８３において、クレカアクセストークン識別子＝ＩＤ＿ｃｃｔ１は、クレカアクセストークン＝ＣＣＴ１に対応付けられているとする。すると、取得部４２は、クレカアクセストークン＝ＣＣＴ１を支払処理に使用するアクセストークンとする。サービス処理部６３は、支払先の病院の情報や請求金額を含む支払情報を生成し、クレカアクセストークン＝ＣＣＴ１と支払情報を含む支払要求を、金融機関サーバ８に送信する（図１６のステップＳ１０９）。このとき、サービス処理部６３は、支払要求中のユーザのＦＩＤＯ−ＩＤとクレカアクセストークンを記憶する。

金融機関サーバ８は、クレカアクセストークンの検証処理を行う（ステップＳ１１０）。クレカアクセストークンが有効ではない場合、金融機関サーバ８は処理を終了する（ステップＳ１１０でＮｏ）。クレカアクセストークンが有効である場合、金融機関サーバ８は、クレカアクセストークンに対応付けられたクレジットカード情報を用いて決済処理を行う（ステップＳ１１０でＹｅｓ）。金融機関サーバ８は、情報処理装置３０に決済完了をクレカアクセストークンと共に通知する（ステップＳ１１１）。

情報処理装置３０のサービス処理部６３は、決済完了の通知を受信する。アプリ制御部６４は、金融機関サーバ８から通知されたクレカアクセストークンに対応付けて記憶している支払要求中のユーザのＦＩＤＯ−ＩＤを特定する。アプリ制御部６４は、支払要求中のユーザのＦＩＤＯ−ＩＤに対応付けられた端末２０に対して、支払完了の通知を送信するとともに、支払完了を知らせる画面を表示するように、端末２０に要求する。（ステップＳ１１２）。端末２０のアプリ処理部２３は、情報処理装置３０からの要求に従って、表示部２５の画面に、支払完了を知らせる画面を表示する（ステップＳ１１３）。端末２０のアプリ処理部２３は、表示の変更を情報処理装置３０に通知する。すると、サービス処理部６３は、支払要求中のユーザとして記憶しているＦＩＤＯ−ＩＤに対応付けられたステータス情報と支払情報を更新する（ステップＳ１１４）。例えば、ＦＩＤＯ−ＩＤ＝ＩＤ＿Ａのユーザについての支払処理が完了すると、サービス処理部６３は、図１７に示す被保険者情報テーブル８１ｂを被保険者情報テーブル８１ｃに示すように更新する。

なお、図１６と図１７を参照しながら説明した処理は一例であり、実装に応じて変更が行われてもよい。例えば、ステップＳ１１４の処理はステップＳ１１３の前に行われてもよい。また、ステップＳ１０２の請求情報の送信の際に、病院サーバ４から情報処理装置３０に処方箋の有無が通知されてもよい。この場合、サービス処理部６３は、診察料金を請求されているユーザについて処方箋が発行されているかの情報を、適宜、被保険者情報テーブル８１に記録できる。さらに、アプリ制御部６４は、支払終了画面に、処方箋が出ていることをユーザに通知する表示を含めることを端末２０に通知できる。

図１８は、診察料金の支払処理が行われたときの端末２０の表示例を説明する図である。図１８は、支払終了画面に処方箋が出ていることを通知する表示が含められる場合の端末２０の表示例である。図１８の例では、Ｙ病院への９８０円の支払いが終了したことと、処方箋が出ていることとが、端末２０のユーザに通知される。

以上説明したように、情報処理装置３０は、病院サーバ４から請求情報を取得し、ユーザの認証が成功したときに、クレカアクセストークンを用いて支払処理を行い、支払結果を端末２０に提供している。従って、実施形態にかかるシステムでは、ユーザは、診察を受けた病院にいなくても支払い処理を行うことができる。すなわち、実施形態にかかるシステムを用いれば、ユーザは、診察が終わってから請求金額の計算が終わるまでの間の時間を、病院や病院の周辺で過ごさなくても良くなる。このため、実施形態にかかるシステムにより、ユーザの利便性が向上する。

さらに、情報処理装置３０は、クレジットカードの情報を保持しておらず、ユーザの認証の成功に応じて、金融機関サーバ８に、クレカアクセストークンを用いて支払処理を要求している。すなわち、ユーザのクレジットカード情報が情報処理装置３０に定常的に記憶されていないので、情報処理装置３０からユーザのクレジットカード情報が流出する危険性は小さい。

（６）薬を受け取る薬局の指定処理
図１９は、薬局の指定処理の例を説明するフローチャートである。図２０は、薬局の指定処理の際に行われるデータの更新の例を説明する図である。以下、図１９、図２０を参照しながら、薬を受け取る薬局を指定する際に行われる処理の例を説明する。

病院サーバ４は、支払処理が終わると、情報処理装置３０に、薬局へ提示可能な処方箋情報と病院アクセストークンを送信する（ステップＳ１２１、Ｓ１２２）。

情報処理装置３０の取得部４２は、病院アクセストークンを用いて処方箋情報が生成されたユーザのＦＩＤＯ−ＩＤを特定する（ステップＳ１２３）。ステップＳ１２３で行われる処理は、図１６のステップＳ１０３と図１７を参照しながら説明した処理と同様である。ここでは、ＦＩＤＯ−ＩＤの特定の際に、対応テーブル５２ｄと病院アクセストークンテーブル８２が使用されるものとする。次に、サービス処理部６３は、通知された処方箋情報を、ユーザのＦＩＤＯ−ＩＤに対応付けて被保険者情報テーブル８１に記録する。例えば、処方箋情報が通知されたユーザのＦＩＤＯ−ＩＤがＩＤ＿Ａであることが特定されているとする。この場合、図２０の被保険者情報テーブル８１ｄに示すように、処方箋情報は、ＦＩＤＯ−ＩＤ＝ＩＤ＿Ａのエントリ中の処方箋情報に記録される。その後、アプリ制御部６４は、処方箋が発行されたことを端末２０に通知すると共に、処方箋の内容の確認を要求する表示をすることを端末２０に要求する（図１９のステップＳ１２４）。

端末２０のアプリ処理部２３は、情報処理装置３０からの通知に応じて、処方箋の内容の確認を要求する表示を、表示部２５の画面に表示させる。処方箋の内容の確認を要求する表示は、処方箋情報を表示するかを問合わせるダイアログボックスであっても良く、また、図１８に示すように「処方箋確認」と書かれたボタンであっても良い。ユーザが処方箋情報の確認に対応付けられたボタン等を選択すると、アプリ処理部２３は、処方箋情報を表示部２５の画面に表示する（ステップＳ１２５）。画面に表示される処方箋情報は、例えば、処方箋を発行した医療機関名、処方されている個々の薬品の名称、および、個々の薬品についての処方された量を含む表示である。アプリ処理部２３は、処方箋情報の確認用の画面を表示すると、端末２０の位置情報を取得すると共に、取得した位置情報を情報処理装置３０に送信する（ステップＳ１２６）。ここで、位置情報として、例えば、ＧＰＳ（Global Positioning System）情報などが用いられる。情報処理装置３０のサービス処理部６３は、位置情報を受信すると、被保険者情報テーブル８１中の、処方箋の発行通知を送信したユーザのＦＩＤＯ−ＩＤを含むエントリに位置情報を記録する。図２０の被保険者情報テーブル８１ｅは、ＦＩＤＯ−ＩＤ＝ＩＤ＿Ａのユーザの端末２０が北緯○○東経ＸＸに位置する場合での、被保険者情報テーブル８１の更新例である。

情報処理装置３０のサービス処理部６３は、端末２０から位置情報を取得すると、薬局情報７２を用いて、端末２０の位置に近い調剤薬局を検索する（図１９のステップＳ１２７）。なお、薬局情報７２に記録されている薬局は、情報処理装置３０が処方箋情報や保険証の情報を送信可能な薬局サーバ６を保持する薬局である。サービス処理部６３は、検索で得られた薬局の情報を端末２０に送信する。サービス処理部６３は、検索した調剤薬局のリストと共に、各薬局での受け取り時間の目安などの情報を、端末２０に送信しても良い。例えば、薬局情報７２に各薬局での平均的な待ち時間が記録されている場合、受け取り時間の目安は、現在時刻から平均的な待ち時間が経過した時刻に設定される。端末２０のアプリ処理部２３は、情報処理装置３０から受信した薬局の情報を、表示部２５の画面に表示する。このとき、薬局の情報は、文字情報であっても、地図を含む情報であっても良い。また、薬局の情報と共に、処方箋情報が表示されても良い。

図２１は、薬局の指定処理の際の端末の表示例を説明する図である。図２１の画面Ｇ１１は、候補となる薬局の名称と処方箋情報が合わせて表示されている場合の例である。画面Ｇ１１の例では、処方された薬を受け取る薬局の候補として端末２０に通知された調剤薬局のリストに含まれている薬局の一部と、その薬局について通知された情報を文字表示している。この例では、アプリ処理部２３は、調剤薬局のリストから、表示対象として「Ａ薬局」を選択し、Ａ薬局では１５時以降に薬の受け取りが可能であることを目安として示している。さらに、画面Ｇ１１の例では、処方箋情報として、処方箋が発行された日付、処方箋を発行した医療機関名、処方されている個々の薬品の名称、および、個々の薬品についての処方された量が表示されている。画面Ｇ１１には、選択された薬局での調剤を申し込むためのボタンも表示されている。ユーザが画面Ｇ１１中の「受取申込」ボタンを押し下すと、Ａ薬局の調剤薬局としての指定が確定する。

図２１の画面Ｇ１２も薬局の指定用の画面の例である。画面Ｇ１２の例では、端末２０は、情報処理装置３０から薬局のリストを、薬局が表示された地図の形式で受信している。端末２０のアプリ処理部２３は、情報処理装置３０から受信した地図を画面に表示する。このとき、アプリ処理部２３は、各薬局が選択可能になるように各薬局の表示位置にアイコン等を対応付けて表示する。画面Ｇ１２の例では、選択されている薬局の情報も地図の下に表示されている。画面Ｇ１２の例でも、Ａ薬局が選択されている。また、Ａ薬局での受け取り可能な時刻の目安も、画面Ｇ１２に含められている。ユーザが画面Ｇ１２中の「この場所で申込」ボタンを押し下すと、Ａ薬局の調剤薬局としての指定が確定する。

薬局の選択画面へのユーザの入力により調剤薬局の指定が確定されると、端末２０のアプリ処理部２３は、指定された薬局への調剤の申込を情報処理装置３０に要求する（図１９のステップＳ１２８、Ｓ１２９）。

情報処理装置３０の認証処理部４１は、調剤の申込を受信すると、指定された調剤薬局に提示する情報を生成するために、保険証情報の取得処理を開始する。まず、認証処理部４１は、端末２０にＦＩＤＯ認証を要求する（ステップＳ１３０）。ステップＳ１３０〜Ｓ１３１で行われるＦＩＤＯ認証の処理は、図８を参照しながら説明したステップＳ４４〜Ｓ４５の処理と同様である。ユーザに対するＦＩＤＯ認証が完了すると、認証処理部４１は、ユーザのＦＩＤＯ−ＩＤを特定する。すると、取得部４２は、特定されたＦＩＤＯ−ＩＤを、薬局の指定処理中のユーザのＦＩＤＯ−ＩＤとして記憶する。さらに、取得部４２は、特定されたＦＩＤＯ−ＩＤに対応付けられた健保アクセストークンを用いて、保険証情報の照会を健保サーバ２に要求する（ステップＳ１３２）。健保サーバ２は、健保アクセストークンの有効性を検証する（ステップＳ１３３）。健保アクセストークンが有効ではない場合、健保サーバ２は処理を終了する（ステップＳ１３３でＮｏ）。健保アクセストークンが有効である場合、健保サーバ２は、健保アクセストークンに対応付けられた保険証番号と被保険者の氏名を情報処理装置３０に送信する（ステップＳ１３３でＹｅｓ、ステップＳ１３４）。情報処理装置３０のサービス処理部６３は、保険証番号、被保険者の氏名、および、薬局の指定処理中のユーザのＦＩＤＯ−ＩＤに対応付けられた処方箋情報を、指定された調剤薬局が使用する薬局サーバ６に送信する（ステップＳ１３５）。薬局サーバ６は、処方箋情報を薬局データベース７に登録する（ステップＳ１３６）。

図２２は、薬局の指定処理が行われたときのデータの例を説明する図である。図２２を参照しながら、被保険者情報テーブル８１の更新例と、薬局サーバ６での登録処理の詳細について説明する。

情報処理装置３０のサービス処理部６３は、処方箋情報を薬局サーバ６に送信すると（図１９のステップＳ１３５）、被保険者情報テーブル８１において、処理対象のユーザのステータス情報を更新する。例えば、Ａ薬局の薬局サーバ６に処方箋情報を送信した場合、サービス処理部６３は、被保険者情報テーブル８１ｅ（図２０）を、図２２の被保険者情報テーブル８１ｆに示すように更新する。

一方、薬局サーバ６は、処方箋情報を情報処理装置３０から受信すると、被保険者氏名をキーとして、薬局データベース７を検索し、ヒットしたエントリに処方箋情報を記録する。例えば、情報処理装置３０から、被保険者氏名＝富士通太郎という情報と共に、保険証番号と処方箋情報ｘｘｘｘｘが送信されたとする。すると、図２２の薬局データベース７に示すように、氏名＝富士通太郎を含むエントリに、処方箋情報が記録される。薬局サーバ６は、処方箋情報に対応付けて、調剤結果を通知する際に使用するアクセストークン（薬局アクセストークン）を発行する。図２２の例では、薬局データベース７に示すように、氏名＝富士通太郎の処方箋情報ｘｘｘｘｘに対する調剤結果の通知に使用する薬局アクセストークンとしてＹＫＴ１が発行されている。薬局サーバ６は、発行した薬局アクセストークンを、情報処理装置３０に通知する。

情報処理装置３０のサービス処理部６３は、通知された薬局アクセストークンを識別する薬局アクセストークン識別子を生成し、薬局アクセストークンと薬局アクセストークン識別子を、薬局アクセストークンテーブル８４に記録する。さらに、サービス処理部６３は、薬局アクセストークンを発行した薬局サーバ６に対応付けられた薬局の情報も、薬局情報として記録する。図２２の例では、薬局アクセストークン＝ＹＫＴ１と、薬局アクセストークン識別子＝ＩＤ＿ｙｋ１、薬局情報＝Ａ薬局という情報が薬局アクセストークンテーブル８４に記録されている。サービス処理部６３は、薬局アクセストークン識別子を、処理対象のユーザのＦＩＤＯ−ＩＤに対応付けて対応テーブル５２に記録する。図２２の例では、ＦＩＤＯ−ＩＤ＝ＩＤ＿Ａのユーザに対して発行された薬局アクセストークンの識別子がＩＤ＿ｙｋ１である。このため、対応テーブル５２ｄ（図２０）は、図２２の対応テーブル５２ｅに示すように更新される。

このように、実施形態にかかる方法が適用されるシステムでは、処方箋が紙媒体で発行される代わりに、電子データとして、病院サーバ４、情報処理装置３０、端末２０、薬局サーバ６の間で送受信される。従って、ユーザは、紙媒体で発行された処方箋を病院で受け取らなくても、ユーザの選択した薬局に対して薬の調剤を申し込むことができる。従って、実施形態にかかる方法が適用されるシステムでは、ユーザは紙媒体の処方箋を受け取るために診察料金の支払後に病院に立ち寄らなくても良いため、紙媒体の処方箋が発行される場合に比べて、ユーザの利便性が向上する。

（７）薬の受け取り処理
図２３は、薬の受け取りの際に行われる処理の例を説明するフローチャートである。図２４は、薬の受け取りの際に行われるデータの更新の例を説明する図である。以下、図２３、図２４を参照しながら、ユーザが薬局で薬を受け取る際に行われる処理の例を説明する。

薬局での調剤が終了すると、薬局サーバ６は、調剤結果と薬の代金の請求情報を生成する（ステップＳ１４１）。薬局サーバ６は、処方対象のユーザに対して発行した薬局アクセストークンと共に、調剤結果と請求情報を情報処理装置３０に送信する。

情報処理装置３０の取得部４２は、薬局アクセストークンを用いて、処方対象のユーザを識別するＦＩＤＯ−ＩＤを特定する（ステップＳ１４２）。例えば、薬局サーバ６から受信した情報に、薬局アクセストークン＝ＹＫＴ１が含まれていたとする。すると、取得部４２は、受信した薬局アクセストークンをキーとして、薬局アクセストークンテーブル８４を検索することにより、薬局アクセストークン識別子を特定する。図２４の例では、薬局アクセストークン＝ＹＫＴ１を識別する識別子は、ＩＤ＿ｙｋ１である。取得部４２は、得られた薬局アクセストークン識別子に対応付けられているＦＩＤＯ−ＩＤを、処方対象のユーザを識別するＦＩＤＯ−ＩＤとする。図２４に示す対応テーブル５２ｅの例では、薬局アクセストークン識別子＝ＩＤ＿ｙｋ１にＦＩＤＯ−ＩＤ＝ＩＤ＿Ａが対応付けられているので、取得部４２は、ＩＤ＿Ａを処方対象のユーザのＦＩＤＯ−ＩＤとして認識する。

取得部４２は、処方対象のユーザのＦＩＤＯ−ＩＤ、調剤結果、請求情報をサービス処理部６３に出力する。サービス処理部６３は、処方対象のユーザについて、被保険者情報テーブル８１中のステータス状態、調剤結果情報、支払情報を更新する。図２４の被保険者情報テーブル８１ｇは、サービス処理部６３が、ＦＩＤＯ−ＩＤ＝ＩＤ＿Ａのユーザについて、ステータス状態を「処方支払待ち（Ａ薬局）」、支払情報を「５６０円（Ａ薬局）」に更新した場合の被保険者情報テーブル８１の例である。図２４の被保険者情報テーブル８１ｇでは、調剤結果情報も更新されている。サービス処理部６３は、処方対象のユーザのＦＩＤＯ−ＩＤに対応付けられた端末２０に対して、調剤結果と請求情報を送信する（図２３のステップＳ１４３）。

端末２０のアプリ処理部２３は、受信した調剤結果と請求情報を、表示部２５が備える画面に表示することにより、調剤内容と支払の確認を端末２０のユーザに要求する（ステップＳ１４４）。例えば、この例では、調剤内容と共に、薬の代金＝５６０円、支払先＝Ａ薬局という情報と、承認ボタンが表示され得る。端末２０のユーザは、調剤内容と請求情報を確認し、問題ないと判断すると、画面に表示された承認ボタンを押し下す。すると、アプリ処理部２３は、支払処理の要求を情報処理装置３０に送信する（ステップＳ１４４でＹｅｓ）。

情報処理装置３０の取得部４２は、支払処理の要求を受信すると、端末２０にＦＩＤＯ認証を要求する（ステップＳ１４５）。ステップＳ１４５〜Ｓ１５１の処理は、図１６を参照しながら説明したステップＳ１０６〜Ｓ１１２の処理と同様である。すなわち、ＦＩＤＯ認証やＦＩＤＯ認証の完了後のクレジットカードを用いた支払処理は、診察料金の支払処理の際の処理と同様に行われる。

端末２０のアプリ処理部２３は、情報処理装置３０から支払完了を知らせる画面を表示することが要求されると、表示部２５の画面に、支払完了を知らせる画面を表示する（ステップＳ１５２）。端末２０のアプリ処理部２３は、表示の変更後に、ユーザからの入力があると、薬の代金の支払の完了をユーザが確認した旨を、情報処理装置３０に通知する。例えば、薬の代金の支払完了の通知画面には、確認ボタン等が含まれていても良い。この場合、確認ボタンをユーザが押し下すと、アプリ処理部２３は、薬の代金の支払の完了をユーザが確認したことを情報処理装置３０に通知できる。

薬の代金の支払の完了をユーザが確認したことが端末２０から通知されると、情報処理装置３０のサービス処理部６３は、処方対象のユーザのＦＩＤＯ−ＩＤに対応付けられたステータス情報と支払情報を更新する（ステップＳ１５３）。例えば、ＦＩＤＯ−ＩＤ＝ＩＤ＿Ａのユーザについての薬の代金の支払処理が完了すると、サービス処理部６３は、図２４に示す被保険者情報テーブル８１ｇを被保険者情報テーブル８１ｈに示すように更新する。

さらに、情報処理装置３０のＱＲコード生成部６２は、薬の受け取りの際に薬局の受付装置１０に提示するためのＱＲコードを生成する（図２３のステップＳ１５４）。薬の受け取りの際に提示するためのＱＲコードには、受け取る薬の処方箋情報と、受け取る薬の代金の支払が完了していることを表わすステータス情報が含められる。サービス処理部６３は、生成したＱＲコードを端末２０に送信する。このとき、サービス処理部６３は、薬の代金の支払処理が完了したユーザの情報として記憶しているユーザのＦＩＤＯ−ＩＤを用いて、送信先の端末２０の情報を特定する。端末２０のアプリ処理部２３は、情報処理装置３０から受信したＱＲコードを表示部２５の画面に表示させる（ステップＳ１５５）。

図２５は、薬の受け取り用の表示画面の例を説明する図である。図２５に示す例では、薬の受け取り用の表示画面には、ＱＲコードと処方箋を発行した病院の名称が含まれている。また、表示画面を、薬剤師に提示するようにユーザに促す表示も含まれている。

ユーザは、調剤を申し込んだ薬局に行き、薬剤師等に、薬の受け取りに来た旨を伝える。すると、薬剤師等は、ユーザの端末２０に表示される薬の受取用のＱＲコードを読み込ませるための受付装置１０を用意する。用意された受付装置１０にユーザが端末２０の画面をかざすと、受付装置１０は、端末２０に表示されたＱＲコードを読取る（図２３のステップＳ１５６）。すると、受付装置１０でＱＲコードがデコードされ、受け取る薬の処方内容と支払が終了しているかが受付装置１０の備える画面上に表示される。そこで、薬剤師は、受付装置１０の画面に表示された情報に基づいて、ユーザに薬を渡すと共に、薬の説明をする。

薬剤師からユーザへの薬の受け渡しと並行して、受付装置１０は、ＱＲコードに含まれている処方箋情報と薬の代金の支払が完了していることを表わすステータス情報の組み合わせを、薬局サーバ６に送信する。すると、薬局サーバ６は受付装置１０から受信した情報を用いて、薬の受取が完了したことを表わす通知を、薬を受け取ったユーザに対応付けられた薬局アクセストークンとともに情報処理装置３０に送信する（ステップＳ１５７）。

情報処理装置３０のサービス処理部６３は、受信した薬局アクセストークンに関連付けられたＦＩＤＯ−ＩＤのユーザについて、被保険者情報テーブル８１に登録されているステータスを「薬の受け取り完了」に更新する。さらに、アプリ制御部６４は、端末２０に対して、薬の受け取りが完了したことを表わす表示を端末２０の画面に表示するように要求する。端末２０のアプリ処理部２３は、情報処理装置３０からの要求に応じて、薬の受け取りが完了したことを表わす表示を、端末２０の画面に表示する（ステップＳ１５９）。

このように、実施形態にかかる方法が適用されるシステムでは、ユーザは、調剤が終わったことが端末２０の画面に表示されると、端末２０を介して支払処理を行うことができる。このため、薬局では、受付装置１０にＱＲコードを読み取らせることにより薬の受け取りができる。従って、実施形態にかかる方法が適用されるシステムでは、薬局での待ち時間が発生しにくくなり、ユーザの利便性が向上する。

以上、診察受付や薬を受け取る薬局の指定処理についての説明で述べたように、情報処理装置３０は、保険証情報の取得を行う前に、ＦＩＤＯ認証を行い、ＦＩＤＯ認証が完了すると、健保サーバ２からアクセストークンを用いて保険証情報を取得する。また、保険証情報の取得の際に使用される健保アクセストークンは、保険証ごとに発行されている。従って、実施形態にかかる方法が用いられると、ユーザの本人確認が成功した場合に、ユーザ本人の保険証情報が端末２０や薬局サーバ６に通知されるが、本人確認に失敗すると、保険証情報は端末２０などに提示されない。換言すると、本人確認に成功したときには、薬局サーバ６に保険証の情報が通知可能になり、ＱＲコードの読み取りを通して病院の受付装置１０にも保険証の情報が通知できる。一方、本人確認に失敗すると、薬局サーバ６には保険証の情報が通知されない。また、本人確認に失敗すると、端末２０に保険証情報を含むＱＲコードが表示されないので、病院の受付装置１０に保険証情報が通知されることもない。このため、実施形態にかかる方法が用いられるシステムでは、保険証の不正使用を防止することができる。

さらに、診察受付、診察料金の支払処理、薬を受け取る薬局の指定処理、および、薬の受け取り処理の各々での説明で述べたように、情報処理装置３０は、端末２０などからの受信情報に応じて、取得する個人情報の種類を決定する。また、情報処理装置３０は、取得する個人情報を、健保サーバ２などの外部機関のサーバから取得し、取得した情報の組み合わせを端末２０に提供する。この結果、病院の受付の際は保険証と診察券の情報の組み合わせが提供され、薬局での薬の受け取りの際には、薬代の支払結果と受け取り対象の薬の処方箋の情報の組み合わせが提供されるなど、ユーザの利用シーンに合わせた情報が端末２０に提供される。従って、ユーザが行う手続が簡便になる。

＜その他＞
なお、実施形態は上記に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。

以上の説明では、複数の情報を端末２０に通知するときに、複数の情報をマージする場合の例を説明したが、これは実施形態の一例に過ぎない。実装に応じて、複数の情報をマージせずに、別々のＱＲコードなどで端末２０の画面に表示するようにしても良い。

さらに、端末２０に送信する情報としてＱＲコードを使用する場合を例として、実施形態を説明したが、これも一例に過ぎない。実装に応じて情報の提示方法も任意であり、ＱＲコード以外の情報コードが用いられても良い。また、情報コードとは異なる形態で情報が端末２０や受付装置１０に提示されても良い。

端末２０に送信される情報は、病院や薬局での受付装置１０での処理に使用される情報へのアクセス先であっても良い。例えば、情報処理装置３０では、端末２０のユーザの保険証情報と診察券情報を組み合わせた情報を保持し、ＱＲコード生成部６２は、保険証情報と診察券情報を組み合わせた情報の取得に使用可能なＵＲＬ（Uniform Resource Locator）をＱＲコードに含めることができる。この場合、病院の受付装置１０は、ＱＲコードを読み込むことで取得したＵＲＬにアクセスして、端末２０のユーザの保険証情報と診察券情報を取得し、受付処理を行う。また、ＵＲＬで情報へのアクセス先を通知する対象は、端末２０のユーザの保険証情報と診察券情報の組み合わせに限られない。例えば、保険証情報と診察券情報のうちのいずれか一方について、ＵＲＬでアクセス先が指定されても良い。この場合、ＵＲＬでアクセス先が指定されていないほうの情報については、情報自体が、情報処理装置３０から端末２０に送信される。また、保険証情報と診察券情報のいずれについても、個別にアクセス先がＵＲＬで指定されても良い。さらに、ＵＲＬはアクセス先の指定方法の一例であり、アクセス先の指定方法も任意に変更され得る。ここでは、病院での受付処理に使用される情報を例として、アクセス先を指定する情報を端末２０に送信する場合について説明したが、薬局での受付の際に端末２０に送信される情報についても、情報自体の代わりにアクセス先が端末２０に送信されても良い。

また、以上の説明では、本人確認にＦＩＤＯ認証が用いられる場合を例として説明したが、ＦＩＤＯ認証以外の認証処理が用いられても良い。

調剤薬局の選択の際に使用される位置情報は、端末２０が取得可能で、かつ、位置の特定に使用可能な任意の情報とすることができ、ＧＰＳ情報には限定されない。例えば、端末２０が接続を確立している基地局情報が使用されても良い。

調剤薬局の選択の際に使用される位置情報は、端末２０の現在地には限られず、例えば、ユーザが端末２０に入力した位置の情報であっても良い。このように変形すると、例えば、ユーザが、病院等からの帰り道で自宅や会社から離れた位置にいる場合に、薬を受け取る薬局の検索に使用する位置を、自宅や会社などの近くに設定できる。すると、ユーザは、調剤の申し込みを自宅や会社などから離れた位置で行い、調剤されている間に自宅や会社などに向かって移動できる。さらに、ユーザは、調剤が終わったころに、自宅や会社などの近くの薬局から薬を受け取ることができる。

ＱＲコードには有効期限を設けても良い。ＱＲコードに有効期限が設けられる場合、有効期限は、サービス処理部６３が管理する。受付装置１０を介してＱＲコードの情報を取得した病院サーバ４や薬局サーバ６は、ＱＲコードの情報の有効性を、情報処理装置３０に問合わせる。有効期限内に問い合わせを受信すると、サービス処理部６３は、ＱＲコードが有効であることを問い合わせ元に通知し、問い合わせ元での処理が継続される。一方、有効期限が過ぎてから問い合わせを受信すると、サービス処理部６３は、ＱＲコードが無効であることを問い合わせ元に通知し、問い合わせ元に処理の終了を要求する。病院サーバ４や薬局サーバ６は、情報処理装置３０からの要求に応じて処理を終了する。このように変形することにより、保険証の不正利用をさらに防止しやすくすることができる。

情報処理装置３０は、保険証情報、診察券情報、クレジットカード情報などの個人情報を、健保サーバ２、病院サーバ４、金融機関サーバ８などから取得した後、所定期間の間保持していても良い。このように変形すると、これらの情報を取得してから所定期間内に端末２０からこれらの情報の要求があった場合、情報処理装置３０は、健保サーバ２、病院サーバ４、金融機関サーバ８などに問い合わせを行わずに、端末２０に要求された情報を送信できる。このため、毎回、情報処理装置３０から健保サーバ２などに問い合わせが行われる場合に比べて、端末２０の要求への応答時間が短縮されると共に、情報処理装置３０の処理負荷が低減される。

情報処理装置３０は、保険証情報、診察券情報、クレジットカード情報などの個人情報を所定期間にわたって保持する場合、これらの個人情報を端末２０に対応付けて保持しても良い。例えば、健保アクセストークンを取得したことにより、処理対象のユーザに関する保険証情報が健保サーバ２に登録されていることが確認できると、情報処理装置３０は、端末２０と端末２０のユーザの保険証情報を対応づけて記憶しても良い。同様に、診察券情報についても、病院アクセストークンの取得により、診察券情報が病院サーバ４に登録されていることが確認できると、情報処理装置３０は、端末２０と端末２０のユーザの診察券情報を対応づけて記憶しても良い。このように変形すると、端末２０からの問い合わせに対する応答時間がさらに短縮できる。さらに、このような処理の後で、情報処理装置３０は、端末２０からのアクセスに応じて、端末２０に対応付けて診察券情報を記憶している医療機関のリストを端末２０に送信しても良い。この場合、端末２０は、情報処理装置３０から受信したリストに基づいて、受診先候補のリストを画面上に表示できる。このとき、端末２０は、例えば、図１２に示す画面の表示例と同様に、各医療機関が選択可能になるように、医療機関のリストを表示できる。このように変形すると、診察券の登録の削除などにより診察券の登録状態が変更されたとしても、端末２０のユーザは、情報処理装置３０への診察券の登録状況を容易に把握できる。

以上の説明では、端末２０側でアプリケーションのプロセス管理をしているが、プロセス管理は、情報処理装置３０中のアプリ制御部６４によって行われても良い。この場合、例えば、ＯＣＲ処理も情報処理装置３０で行われ得る。ＯＣＲ処理が情報処理装置３０で行われる場合、情報処理装置３０は、端末２０から保険証の撮像画像や診察券の撮像画像を受信する。さらに、情報処理装置３０の取得部４２や取得部６１は、情報処理装置３０でのＯＣＲ処理によって得られた情報に基づいて、健保サーバ２や病院サーバ４などにアクセスする。なお、保険証と診察券のうちの一方が情報処理装置３０でＯＣＲ処理され、他方が端末２０でＯＣＲ処理されても良い。

２ 健保サーバ
４ 病院サーバ
６ 薬局サーバ
８ 金融機関サーバ
１０ 受付装置
２０ 端末
２１、３１ 通信部
２２ カメラ
２３ アプリ処理部
２４、４１ 認証処理部
２５ 表示部
２６、５０、７０ 記憶部
３０ 情報処理装置
３２ ヘルスケア情報処理部
４０ 認証情報処理部
４２、６１ 取得部
５１ ＰＩＮ情報
５２ 対応テーブル
６０ 制御部
６２ ＱＲコード生成部
６３ サービス処理部
６４ アプリ制御部
７１ 病院情報
７２ 薬局情報
８０ 被保険者データベース
１０１、１１１ プロセッサ
１０２、１１２ メモリ
１０３、１１７ バス
１０４ ネットワーク接続装置
１１３ 入力装置
１１４ 表示装置
１１５ カメラ
１１６ 無線処理装置
１１８ 生体情報リーダ

Claims (10)

1. 端末から通知された識別情報で識別される保険証の情報の照会に用いる第１のトークンを、保険証情報を保持するサーバ装置から取得し、
   前記端末から通知された情報に対応付けられた診察券の情報の照会に用いる第２のトークンを、医療機関が用いる情報を保持するサーバ装置から取得し、
   前記端末から、前記端末のユーザの認証に成功したことを表わす情報と前記医療機関を指定する情報を受信すると、前記第１のトークンを用いて取得した前記保険証の情報、および、前記第２のトークンを用いて取得した前記診察券の情報を、前記端末に送信する
   処理をコンピュータに実行させることを特徴とする情報提供プログラム。
2. 前記端末のユーザに対して前記医療機関が発行した処方箋情報を受信し、
   前記処方箋情報を送信可能な装置を保持する薬局のリストを、前記端末に送信し、
   前記端末から前記リストに含まれる薬局を指定する薬局情報、および、前記端末のユーザの認証に成功したことを表わす情報を受信すると、前記第１のトークンを用いて取得した保険証の情報、および、前記処方箋情報を、前記薬局情報で特定される薬局のサーバ装置に送信する
   処理を前記コンピュータに実行させることを特徴とする、請求項１に記載の情報提供プログラム。
3. 前記端末から通知されたクレジットカード情報に対応付けられた金融機関のサーバ装置から、前記端末のユーザの支払処理に使用する第３のトークンを取得し、
   前記薬局情報で特定される薬局が使用するサーバ装置から、前記処方箋情報で特定される薬の調剤結果を受信すると、前記調剤結果を前記端末に送信し、
   前記端末から、前記調剤結果の承認と前記ユーザの認証に成功したことを表わす情報を受信すると、前記第３のトークンを用いて、前記金融機関のサーバ装置に、前記調剤結果で特定される薬の代金の支払処理を要求する
   処理を前記コンピュータに実行させることを特徴とする、請求項２に記載の情報提供プログラム。
4. 前記金融機関のサーバ装置から、前記薬の代金の支払処理の終了が通知されると、前記代金の支払が終了したことを表わす情報と前記処方箋情報を含み、かつ、前記薬局情報で指定される薬局の受付装置が読取り可能な情報コードを、前記端末に送信する
   処理を前記コンピュータに実行させることを特徴とする、請求項３に記載の情報提供プログラム。
5. 前記医療機関が使用するサーバ装置から、前記端末のユーザに対する診察料金の請求情報を受信すると、前記請求情報を前記端末に送信し、
   前記端末から、前記請求情報の承認と前記ユーザの認証に成功したことを表わす情報を受信すると、前記第３のトークンを用いて、前記金融機関のサーバ装置に、前記請求情報で特定される診察料金の支払処理を要求する
   処理を前記コンピュータに実行させることを特徴とする、請求項３もしくは４に記載の情報提供プログラム。
6. 前記端末のユーザの認証に成功したことを表わす情報と前記医療機関を指定する情報を受信したときに前記端末に送信する情報は、前記第１のトークンを用いて取得した前記保険証の情報、および、前記第２のトークンを用いて取得した前記診察券の情報を含み、かつ、前記医療機関に設置された受付装置が読取り可能な情報コードである
   ことを特徴とする、請求項１〜５のいずれか１項に記載の情報提供プログラム。
7. 端末から通知された識別情報で識別される保険証の情報の照会に用いる第１のトークンを、保険証情報を保持するサーバ装置から取得し、
   前記端末から通知された情報に対応付けられた診察券の情報の照会に用いる第２のトークンを、医療機関が用いる情報を保持するサーバ装置から取得し、
   前記端末から、前記端末のユーザの認証に成功したことを表わす情報と前記医療機関を指定する情報を受信すると、前記第１のトークンを用いて取得した前記保険証の情報、および、前記第２のトークンを用いて取得した前記診察券の情報を、前記端末に送信する
   処理をコンピュータが実行することを特徴とする情報提供方法。
8. 端末から通知された識別情報で識別される保険証の情報の照会に用いる第１のトークンを、保険証情報を保持するサーバ装置から取得するとともに、前記端末から通知された情報に対応付けられた診察券の情報の照会に用いる第２のトークンを、医療機関が用いる情報を保持するサーバ装置から取得する取得部と、
   前記端末から、前記端末のユーザの認証に成功したことを表わす情報と前記医療機関を指定する情報を受信すると、前記第１のトークンを用いて取得した前記保険証の情報、および、前記第２のトークンを用いて取得した前記診察券の情報を、前記端末に送信する通信部
   を備えることを特徴とする情報提供装置。
9. 被保険者の識別情報を含む保険証情報を記憶するデータベースを備えるシステムにアクセス可能な情報処理装置において、
   端末から受信した保険証の撮像画像から抽出した被保険者の識別情報又は前記端末から受信した被保険者の識別情報に基づいて前記システムにアクセスして被保険者の情報の存在確認後、前記端末と前記識別情報との紐づけ情報を記憶部に記憶し、
   前記端末から受信した診察券の撮像画像から抽出した該診察券に対応する医療機関の情報と診察券の対象者の情報、又は、前記端末から受信した該診察券に対応する医療機関の情報と診察券の対象者の情報に基づいて、対応する医療機関のシステムにアクセスして、診察券の対象者の情報の存在確認後、各医療機関について前記端末と前記対象者情報との各紐づけ情報を記憶部に記憶し、
   前記端末からの医療機関の指定に応じて、指定された該医療機関について前記端末に紐づけられた対象者情報又は対象者情報へのアクセス先情報と、前記端末に紐づけられた被保険者の識別情報又は被保険者の識別情報へのアクセス先情報とを前記端末に送信する、
   処理をコンピュータに実行させることを特徴とする情報提供プログラム。
10. 被保険者の識別情報を含む保険証情報を記憶するデータベースを備えるシステムにアクセス可能な情報処理装置において、
    端末から受信した診察券の撮像画像から抽出した該診察券に対応する医療機関の情報と診察券の対象者の情報又は前記端末から受信した該診察券に対応する医療機関の情報と診察券の対象者の情報に基づいて対応する医療機関のシステムにアクセスして診察券の対象者の情報の存在確認後、各医療機関について前記端末と前記対象者情報との各紐づけ情報を記憶部に記憶し、
    前記端末からのアクセスに応じて、前記記憶部に前記端末に対応づけて記憶された医療機関のリストを前記端末に送信する、
    処理をコンピュータに実行させることを特徴とする情報提供プログラム。