(57)【要約】【課題】利用者を１つの利用個人識別情報で認証を行い、認証後の利用実績を分類することを課題とする。【解決手段】処理部２は、ネットワーク接続された利用者装置２００から受け取った利用個人識別情報に基づき利用者の認証を行い、利用者を認証すると判定したとき、利用者に対応づけられた施設情報一覧を利用者装置２００に送信し、利用者装置２００から選択された施設情報を受信することで利用者に対応する施設情報を特定する。分類部３は、利用者の施設利用実績情報を施設情報ごとに分類する。【選択図】図２
2020086620.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク接続された利用者装置から受け取った利用個人識別情報に基づき利用者の認証を行い、上記利用者を認証すると判定したとき、上記利用者に対応づけられた施設情報一覧を上記利用者装置に送信し、上記利用者装置から選択された施設情報を受信することで上記利用者に対応する施設情報を特定する処理部と
上記利用者の施設利用実績情報を上記施設情報ごとに分類する分類部とを
備えた認証装置。
【請求項２】
上記施設利用実績情報とは、上記処理部が上記利用者および上記施設情報の組み合わせに対応して特定の処理を実行した履歴を含む情報である請求項１に記載の認証装置。
【請求項３】
上記処理部は、上記特定の処理を実行する度に、上記特定の処理を実行した時刻と上記利用個人識別情報とＩＤとを上記施設利用実績情報として記憶する
請求項２に記載の認証装置。
【請求項４】
上記分類部は、上記施設情報ごとに上記施設利用実績情報を分類するとき、利用者および施設名が一対となるＩＤが記憶された利用者マスタ情報を用いて分類する請求項３に記載の認証装置。
【請求項５】
コンピュータを、請求項１〜４のいずれか１項に記載の認証装置として機能させる認証プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、利用者を１つの利用個人識別情報で認証を行い、認証後の利用実績を分類する認証装置に関するものである。
【背景技術】
【０００２】
個人や団体が特定の施設を利用しようとするとき、その施設ごとに個人や団体を特定する利用者ＩＤとパスワードを発行し、利用時に利用者ＩＤおよびパスワードで認証処理を行うことが一般的である。
また１つの市町村内の施設をグループ化して、１つの利用者ＩＤでの複数の施設を利用することができる。たとえばＡ市市民のＺ氏がＡ市所有のＢ体育館、Ｃホール、Ｄ公民館を１つの利用者ＩＤで利用するように構成することができる。この場合、Ｚ氏の施設利用料の請求は、一括してＺ氏に請求されるのが一般的であり、Ｚ氏の利用について請求先を変えることは通常行われない。つまり、複数の施設の利用について、１つの利用者ＩＤで認証を行いながら、施設利用料の請求先を複数箇所に振り分けるようなことは一般的には行われていない。
特許文献１では、医師のシフト勤務管理について開示されている。医療機関の内外の医師が利用者ＩＤで管理されているが、一人の医師の勤務結果を複数に分類することについては開示がない。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１７−２１９９９５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この発明は、利用者を１つの利用個人識別情報で認証を行い、認証後の利用実績を分類することを課題とする。
【課題を解決するための手段】
【０００５】
この発明に係る認証装置は、ネットワーク接続された利用者装置から受け取った利用個人識別情報に基づき利用者の認証を行い、利用者を認証すると判定したとき、利用者に対応づけられた施設情報一覧を利用者装置に送信し、利用者装置から選択された施設情報を受信することで利用者に対応する施設情報を特定する処理部と利用者の施設利用実績情報を施設情報ごとに分類する分類部とを備える。
【発明の効果】
【０００６】
この発明の認証装置によると、１つの利用個人識別情報で認証した利用者の利用実績を分類することができる。
【図面の簡単な説明】
【０００７】
【図１】実施の形態１におけるシステム構成図である。
【図２】実施の形態１における認証装置１００の構成図である。
【図３】実施の形態１における病院ＰＣ２００の表示画面例である。
【図４】実施の形態１における病院ＰＣ２００の表示画面例である。
【図５】実施の形態１で用いる利用者マスタ情報１１の一例を示した図である。
【図６】実施の形態１で用いる施設マスタ情報１２の一例を示した図である。
【図７】実施の形態１で用いる利用実績情報１３の一例を示した図である。
【図８】実施の形態１で用いる課金情報１４の一例を示した図である。
【図９】実施の形態１における処理の流れを説明した図である。
【図１０】実施の形態１における処理の流れを説明した図である。
【発明を実施するための形態】
【０００８】
実施の形態１．
本実施の形態では、利用者は病院に勤務する医師（歯科医師を含む）であり、施設は病院であり、特定の処理は認証装置１００が「処方せんに電子署名を付与する」こととする。医師、特に勤務医は複数の病院で診療を行うことがあるが、本実施の形態では、医師が複数の病院において病院ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）２００を用いて、処方せんに電子署名を行うときの一連の処理の流れを例に示す。ここで、利用者、施設および特定の処理は、任意のものを設定可能である。
なお厚生労働省により、２０１６年３月に「電子処方せんの運用ガイドライン」が策定されている。このガイドラインでは、医療機関で電子処方せんを発行するとき、保健医療福祉分野の公開鍵基盤であるＨＰＫＩ（Ｈｅａｌｔｈｃａｒｅ  Ｐｕｂｌｉｃ  Ｋｅｙ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）による電子署名とタイムスタンプを行うことが定められているが、本実施の形態による電子署名は、ＨＰＫＩを含むいずれかの方式であるとする。また「電子署名を付与する」と表現するとき、合わせてタイムスタンプを付与する構成も含むものとする。
【０００９】
図１は、本実施の形態におけるシステム構成図である。１以上の病院ＰＣ２００は、インターネット等のネットワーク４００を介して認証装置１００および課金サーバ３００と接続される。認証装置１００および課金サーバ３００は、同一のサーバで構成してもよいし、ＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）サーバあるいは、クラウドサービスとして構成してもよい。
認証装置１００は、病院ＰＣ（利用者装置）２００からの要求に基づき電子処方せんに電子署名を付与し、電子署名利用実績情報を病院ごとに分類し、課金情報として課金サーバ３００に送信する。以降、「処方せん」と表記しているものは、「電子処方せん」（処方せんを電子化した情報）を示すものとする。
図２は、認証装置１００の構成図を示す。認証装置１００は、コンピュータである。認証装置１００は、プロセッサ９１０を備えるとともに、メモリ９２０、入力装置９３０、ディスプレイ９４０および通信装置９５０といった他のハードウェアを備える。プロセッサ９１０は、信号線を介して他のハードウェアと接続され、これら他のハードウェアを制御する。
【００１０】
認証装置１００は、機能要素として、認証部１と、処理部２と、分類部３と、課金情報生成部４とを備える。認証部１、処理部２、分類部３、および課金情報生成部４の機能は、ソフトウェアにより実現される。
【００１１】
プロセッサ９１０は、認証プログラムを実行する装置である。認証プログラムは、認証部１、処理部２、分類部３、および課金情報生成部４の機能を実現するプログラムである。プロセッサ９１０は、例えば、ＣＰＵである。「ＣＰＵ」は、Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔの略語である。
【００１２】
メモリ９２０は、認証プログラムを記憶する装置である。メモリ９２０は、例えば、フラッシュメモリまたはＲＡＭである。「ＲＡＭ」は、Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙの略語である。
【００１３】
入力装置９３０は、認証プログラムへのデータの入力のためにユーザにより操作される装置である。入力装置９３０は、例えば、マウス、キーボードまたはタッチパネルである。また本実施の形態では入力装置９３０として、ＩＣカード読取装置を有しているものとする。
【００１４】
ディスプレイ９４０は、認証プログラムから出力されるデータを画面に表示する装置である。ディスプレイ９４０は、例えば、ＬＣＤである。「ＬＣＤ」は、Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙの略語である。
【００１５】
通信装置９５０は、認証プログラムに入力されるデータを受信するレシーバと、認証プログラムから出力されるデータを送信するトランスミッタとを含む。通信装置９５０は、例えば、通信チップまたはＮＩＣである。「ＮＩＣ」は、Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄの略語である。
【００１６】
認証プログラムは、プロセッサ９１０に読み込まれ、プロセッサ９１０によって実行される。メモリ９２０には、認証プログラムだけでなく、ＯＳも記憶されている。「ＯＳ」は、Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍの略語である。プロセッサ９１０は、ＯＳを実行しながら、認証プログラムを実行する。
【００１７】
認証プログラムおよびＯＳは、補助記憶装置に記憶されていてもよい。補助記憶装置は、例えば、フラッシュメモリまたはＨＤＤである。「ＨＤＤ」は、Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅの略語である。補助記憶装置に記憶されている認証プログラムおよびＯＳは、メモリ９２０にロードされ、プロセッサ９１０によって実行される。
【００１８】
なお、認証プログラムの一部または全部がＯＳに組み込まれていてもよい。
【００１９】
認証装置１００は、プロセッサ９１０を代替する複数のプロセッサを備えていてもよい。これら複数のプロセッサは、認証プログラムの実行を分担する。それぞれのプロセッサは、例えば、ＣＰＵである。
【００２０】
認証プログラムにより利用、処理または出力されるデータ、情報、信号値および変数値は、メモリ９２０、補助記憶装置、または、プロセッサ９１０内のレジスタまたはキャッシュメモリに記憶される。
【００２１】
認証プログラムは、認証部１、処理部２、分類部３、および課金情報生成部４の「部」を「処理」に読み替えた各処理をコンピュータに実行させるプログラムである。あるいは、認証プログラムは、認証部１、処理部２、分類部３、および課金情報生成部４の「部」を「手順」に読み替えた各手順をコンピュータに実行させるプログラムである。認証プログラムは、コンピュータ読取可能な媒体に記録されて提供されてもよいし、プログラムプロダクトとして提供されてもよい。
利用者マスタ情報１１、施設マスタ情報１２、利用実績情報１３、課金情報１４および処方せん情報１５は、補助記憶装置に記憶されて、メモリ９２０にロードされる。
【００２２】
病院ＰＣ２００および課金サーバ３００においても、プロセッサ９１０、メモリ９２０、入力装置９３０、ディスプレイ９４０および通信装置９５０については、同等の構成である。
【００２３】
図３は、処理部２が病院ＰＣ２００に送信する情報で構成する利用施設選択画面５００の一例である。利用施設選択画面５００は、利用者からの指定に基づき病院ＰＣ２００に表示される。利用施設選択画面５００を表示する処理の前に、一連の流れとして認証部１が利用者個人を認証するために必要な情報入力を促す画面（図示せず）を表示し、利用者個人を認証する。図３に図示した利用施設選択画面５００では、個人識別番号（利用者ＩＤ）が「＠１２３２２２」で氏名が「山田太郎」で認証され、山田太郎氏に紐付けられた施設名である、「Ａ病院」、「Ｂ病院」、「Ｃ病院」が一覧５０１で表示されている。山田太郎氏は、一覧５０１で電子署名を付与する処方せんに対応する施設名を選択し、ＯＫボタン５０２を押す。この施設名は、通常は、山田太郎氏が診療中の施設名である。山田太郎氏により、一覧５０１で「Ａ病院」を選択され、ＯＫボタンが押されたとする。
【００２４】
図４は、処理部２が病院ＰＣ２００に送信する情報で構成する署名対象選択画面６００の一例である。署名対象選択画面６００は、病院ＰＣ２００に表示される。利用施設選択画面５００において、山田太郎氏はＡ病院を選択した結果が表示エリア６０１に表示され、山田太郎氏は処方せんＩＤを入力エリア６０２に入力する。あるいは、処理部２が処方せんＩＤを一意に発行する機能を有していて、署名対象選択画面６００を表示するときに、一意に定められた処方せんＩＤを発行し、表示するように構成してもよい。処方せんＩＤが特定されると、処方せん情報がイメージ表示エリア６０３に表示され、山田太郎氏は電子署名を行うときは、ＯＫボタン６０４を押す。処方せん情報は、署名対象選択画面６００で直接入力するように構成してもよいし、別画面で入力しその結果をイメージ表示エリア６０３に表示するように構成してもよい。処方せん情報を変更するときは、戻るボタン６０５を押す。
【００２５】
図１〜図４を用いて、医師である山田太郎氏が、Ａ病院にて患者に処方する処方せんに電子署名を行う行為に合わせて、本実施の形態における処理の流れを説明する。認証部１は、病院ＰＣ２００からネットワーク４００を介して山田太郎氏の利用個人識別情報を受信すると、その利用個人識別情報に基づき山田太郎氏個人の認証を行う。認証部１が山田太郎氏個人を認証すると判定したとき、その結果を受けて、処理部２は利用者マスタ情報１１を参照して、山田太郎氏に紐付けられた病院施設一覧を、図３に示した利用施設選択画面５００を用いて病院ＰＣ２００に送信し、病院ＰＣ２００から山田太郎氏の選択を受けて決定された病院情報を受信することで、このときの山田太郎氏に対応する施設情報を特定する。
【００２６】
その後、処理部２は山田太郎氏の指定により、処方に関する情報を生成し、処方せん情報１５として記憶する。なお処方せん情報１５は、認証装置１００ではなく、病院ＰＣ２００に記憶するように構成してもよいし、双方に記憶するように構成してもよい。あるいは、図示しない処方せんサーバに電子署名がなされた処方せん情報を蓄積するように構成してもよい。処理部２は、図４に示した署名対象選択画面６００に、電子署名者に関する情報と対象となる処方せんに関する情報とを表示し、山田太郎氏の確定処理により、特定の処理である処方せんへの電子署名を実行する。
【００２７】
同様に、山田太郎氏はＢ病院、Ｃ病院でも診療後、処方せんを発行する場合は、施設名を選択後、処方せんへの電子署名を要求する。また他の医師も同様に、自分が勤務する１以上の病院から１つの病院を選択後、処方せんへの電子署名を要求する。この要求を受けて、処理部２は特定の処理である、該当の処方せんへの電子署名を実行し、その結果を利用実績情報１３および処方せん情報１５に蓄積する。
【００２８】
分類部３は、例えば月末等の特定のタイミングで、利用実績情報１３を施設ごとに分類する。課金情報生成部４は、分類部３により施設ごとに分類された、利用実績情報１３を課金サーバ３００に送信し、課金サーバ３００はそれぞれの病院ＰＣ２００に課金情報１４を送信する。利用実績情報１３は、施設ごとに分類されることで、課金情報１４の元データとなる。
【００２９】
図５〜図１０を用いて、本実施の形態における、処理の流れと情報の流れを説明する。図５は、利用者マスタ情報１１の一例を示すものである。利用者マスタ情報１１には、氏名、個人識別番号、パスワード、ＩＤおよび施設ＩＤが記憶されている。個人識別番号およびパスワードの組み合わせは、利用個人識別情報の一例である。また、利用個人識別情報として、個人識別番号のみで構成しても構わないし、その他、任意の識別情報の組み合わせで構わない。氏名に対応する個人識別番号およびパスワードは一対であるが、氏名に対応するＩＤと施設ＩＤの組み合わせは、１以上となる。ＩＤは、施設ＩＤに対応して氏名を特定するＩＤである。つまり氏名とＩＤとの組み合わせにより、人物と施設が特定できる。
【００３０】
利用者マスタ情報１１は、病院ＰＣ２００、あるいは他の装置からの申請に基づき認証装置１００の管理者により設定され、処理部２が補助記憶装置に記憶する。ＩＤは、処理部２が一意に発行するように構成してもよいし、管理者が任意に指定するように構成してもよい。
【００３１】
図６は、施設マスタ情報１２の一例を示すものである。施設マスタ情報１２には、施設ＩＤと施設名の組み合わせが記憶されている。施設マスタ情報１２は、管理者からの指定により記憶される。
【００３２】
図７は、利用実績情報（施設利用実績情報）１３の一例を示すものである。利用実績情報１３には、病院ＰＣ２００から指定された医師および施設に対応して、処理部２が処方せんに電子署名を行った日時、個人識別番号およびＩＤが記憶されている。つまり処理部２は、電子署名を行うタイミングで、実績情報を履歴として利用実績情報１３に蓄積する。利用実績情報１３には、その他任意の情報を記憶することができる。利用者マスタ情報１１および施設マスタ情報１２を参照することにより、ＩＤに紐付けられた施設名が特定できる。
【００３３】
図８は、課金情報１４の一例を示すものである。施設名が請求先となるとき、分類部３は、利用者マスタ情報１１を参照して、使用実績情報１３を請求先ごとに分類して、課金情報１４を生成する。請求回数は、分類部３が各使用実績を請求先毎に分類した時点で、利用実績数をカウントした回数である。
【００３４】
図９を用いて、認証部１と処理部２の処理の流れについて説明する。この処理は病院ＰＣ２００からの処理要求により開始される。認証部１は、利用者が入力し病院ＰＣ２００から送信された、個人識別番号およびパスワードと一致する情報が利用者マスタ情報１１に存在するかどうかにより、利用者個人である医師の認証を行う（ステップＳ１１）。なおステップＳ１１の処理は、ＨＰＫＩカード等ＩＣカードを用いた認証に置き換えることができる。ＨＰＫＩカードの場合は、ＩＣカードのチップ内に電子証明書が格納されているので、その電子証明書を利用個人識別情報として認証を行う。この場合は、利用者マスタ情報１１に利用者ＩＤとパスワードの代わりに、電子証明書情報が記憶されている。その他のＩＣカードにおいても、同等の構成ができる。
【００３５】
ステップＳ１１での認証結果を判定し（ステップＳ１２）、利用者が認証されたとき、処理部２は利用者マスタ情報１１に記憶された、利用者に対応する施設情報一覧を病院ＰＣ２００に送信する（ステップＳ１３）。例えばステップＳ１２で認証部１が山田太郎氏を認証すると判定したとき、ステップＳ１３で処理部２が利用者マスタ情報１１を参照し、「山田太郎」に対応付けられた施設ＩＤがＳ０１、Ｓ０２、Ｓ０３であり、施設マスタ情報１２を参照することにより、施設名がＡ病院、Ｂ病院、Ｃ病院であることが特定する。それにより、処理部２は「山田太郎」に対応付けられた施設情報一覧が、Ａ病院、Ｂ病院、Ｃ病院であると特定する。その施設情報一覧を、病院ＰＣ２００に送信し、図３に示す利用施設選択画面５００を表示させる。
【００３６】
その後、病院ＰＣ２００からの指定に基づき、処理部２は指定された施設情報を特定する（ステップＳ１４）。図３に示す利用施設選択画面５００では、山田太郎氏の選択により、Ａ病院と特定される。処理部２は山田太郎氏の指定により、処方に関する情報を生成し、処方せん情報１５として記憶する（ステップＳ１５）。処方せん情報１５には、処方せんＩＤ、利用者名（医師名）、施設名（病院名）、患者名、処方日時、処方薬名および処方量等が記憶される。なお上述したように、処方せん情報１５として補助記憶装置への記憶は必ずしも必要ではなく、病院ＰＣ２００に記憶するように構成してもよい。
【００３７】
続いて処理部２は、署名対象に関する情報を病院ＰＣ２００に送信し、図４に示した署名対象選択画面６００に表示させる。上述したように、処方せん情報１５に基づき電子署名者に関する情報と対象となる処方せんに関する情報とを表示し、山田太郎氏の指定に基づき、該当の処方せんに電子署名処理を行い、個人識別番号、ＩＤに紐付けて日時等利用実績を利用実績情報１３に履歴として、蓄積する（ステップ１６）。利用実績情報１３に電子署名回数を含めてもよい。またこのタイミングで、電子署名付き処方せんを病院ＰＣ２００に送信して、病院ＰＣ２００で記憶するように構成してもよいし、処方せん情報１５に電子署名付き処方せんを上書き保存してもよい。電子署名付き処方せんの作成については、電子署名の仕組みを用いるが、利用者の電子証明書はステップＳ１１で読み取る構成の場合、読み取ったものを病院ＰＣ２００のメモリ内に記憶しておいてもよいし、ステップＳ１６で改めてＨＰＫＩカードの挿入を利用者に促し、電子証明書を読み取り、病院ＰＣ２００から送信されるように構成してもよい。つまり利用者の電子証明書を安全に管理し、必要なタイミングで病院ＰＣ２００で読み取り、認証装置１００で受信する構成であればよい。
【００３８】
ステップＳ１２での判定で、利用者個人が認証されない場合は、認証不可の旨を病院ＰＣ２００に送信する（ステップＳ１７）。処理を終了する。
【００３９】
図１０を用いて、分類部３と課金情報生成部４の処理の流れについて説明する。処理を開始し、分類部３は利用実績情報１３を施設ＩＤ毎に分類する（ステップＳ２１）。具体的には、利用実績情報１３に記憶されたＩＤと一致する利用者マスタ情報１１に記憶されたＩＤを参照することにより、施設ＩＤが特定されるので、そのデータ照合により利用実績を施設ＩＤ毎に分類する。その分類結果に基づき、課金情報生成部４は、課金情報１４を生成し、課金サーバ３００に送信する（ステップＳ２２）。図１０で説明した処理は、任意のタイミングで実行される。例えば、各病院への費用請求日に合わせた定時処理が考えられる。
【００４０】
また課金情報生成部４は課金情報１４に、実際の金額を算出してもよいし、図８に示した課金情報１４のように、課金の基礎情報となる請求回数に基づき、課金サーバ３００にて算出するように構成してもよい。また課金サーバ３００による、課金方法は従量制、定額制等任意の方法で定めてよい。
【００４１】
本実施の形態では、認証部１と、処理部２と、分類部３と、課金情報生成部４の機能がソフトウェアにより実現されるが、変形例として、認証部１と、処理部２と、分類部３と、課金情報生成部４の機能がソフトウェアとハードウェアとの組み合わせにより実現されてもよい。すなわち、認証部１と、処理部２と、分類部３と、課金情報生成部４の機能の一部が専用のハードウェアにより実現され、残りがソフトウェアにより実現されてもよい。
【００４２】
専用のハードウェアは、例えば、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックＩＣ、ＧＡ、ＦＰＧＡまたはＡＳＩＣである。「ＩＣ」は、Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔの略語である。「ＧＡ」は、Ｇａｔｅ  Ａｒｒａｙの略語である。「ＦＰＧＡ」は、Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙの略語である。「ＡＳＩＣ」は、Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔの略語である。
【００４３】
プロセッサ１０１および専用のハードウェアは、いずれも処理回路である。すなわち、認証部１と、処理部２と、分類部３と、課金情報生成部４の機能がソフトウェアにより実現されるか、ソフトウェアとハードウェアとの組み合わせにより実現されるかに関わらず、認証部１と、処理部２と、分類部３と、課金情報生成部４の機能は、処理回路により実現される。
【００４４】
このように本実施の形態によると、認証装置１００は１つの利用個人識別情報で認証した特定の処理について、利用者の利用実績を複数の施設に分類することができる。そうすることで、一人の医師が複数の施設で、処方せんに電子署名処理を行う仕組みにおいて、認証装置１００は、処方せんに電子署名処理を行い、さらに電子署名の回数に応じて費用請求するために、施設毎の費用請求データを作成し、施設毎に費用請求をすることができる。
【００４５】
また認証装置１００は、施設毎に利用者ＩＤおよびパスワードを用意することなく、一人の利用者を複数の施設に対して、同一の利用者ＩＤおよびパスワードで認証することができる。処理部２は利用者の認証後、利用者マスタ情報１１および施設マスタ情報１２を参照して、利用者に対応付けられている施設情報一覧を特定し、病院ＰＣ２００に施設情報一覧を送信して、利用者に情報を提示する。
それにより利用者は、認証を受けた上で、特定の施設を選択することができるので、利便性が向上する。特に、医師のように複数の病院で勤務することが多い場合は、この構成が有効となる。またそのときに認証装置１００は、認証を受けた医師に対応付けられている病院から１つの病院を選択させるように構成しているので、医師が間違った病院を選択するような操作間違いを防止することができる。
【００４６】
本実施の形態の変形例として、利用者をグループで構成して特定の処理を行う場合、利用個人識別情報はグループに対応する識別情報でもよい。
また課金情報１４を生成するとき、系列病院の利用実績をまとめて一箇所に請求するように構成することができる。その場合、認証装置１００は病院のグループ情報を記憶しておき、課金情報生成部４は課金情報を病院ごとに分類した後、さらにグループ情報を参照して、課金情報をグループ化することで、複数病院の利用実績を１箇所に請求するデータとして作り変えることができる。このように構成することで、課金の仕組みに柔軟性を持たせることができる。
【符号の説明】
【００４７】
１  認証部、２  処理部、３  分類部、４  課金情報生成部、１１  利用者マスタ情報、１２  施設マスタ情報、１３  利用実績情報（施設利用実績情報）、１４  課金情報、１５  処方せん情報、１００  認証装置、２００  病院ＰＣ（利用者装置）、３００  課金サーバ、４００  ネットワーク、９１０  プロセッサ、９２０  メモリ、９３０  入力装置、９４０  ディスプレイ、９５０  通信装置。
【図１】
2020086620.tif 000003
【図２】
2020086620.tif 000004
【図３】
2020086620.tif 000005
【図４】
2020086620.tif 000006
【図５】
2020086620.tif 000007
【図６】
2020086620.tif 000008
【図７】
2020086620.tif 000009
【図８】
2020086620.tif 000010
【図９】
2020086620.tif 000011
【図１０】
2020086620.tif 000012
【手続補正書】
【提出日】令和1年12月19日(2019.12.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワーク接続された利用者装置から受け取った利用個人識別情報に基づき利用者の認証を行う認証部と、
上記認証部によって上記利用者を認証すると判定された場合に、上記利用者に対応づけられた施設情報一覧を上記利用者装置に送信して施設を選択させた上で、情報に対して電子署名を付す処理部であって、情報に電子署名を付した場合に、上記利用個人識別情報と、上記施設を識別可能なＩＤとを対応付けて利用実績情報として記憶する処理部と、
上記処理部によって記憶された上記利用実績情報を施設ごとに分類する分類部と、
上記分類部によって分類された上記利用実績情報に基づき、電子署名の回数に応じた請求データを施設ごとに生成する課金情報生成部と
を備えた認証装置。
【請求項２】
上記処理部は、電子署名を付した時刻を、上記利用個人識別情報及び上記ＩＤと対応付けて上記利用実績情報として記憶する
請求項１に記載の認証装置。
【請求項３】
上記分類部は、上記施設情報ごとに上記利用実績情報を分類するとき、利用者および施設が一対となる上記ＩＤが記憶された利用者マスタ情報を用いて分類する
請求項２に記載の認証装置。
【請求項４】
コンピュータを、請求項１〜３のいずれか１項に記載の認証装置として機能させる認証プログラム。