特開 2023-41390 情報処理装置、認証方法、認証プログラムおよび患者認証システム

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

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

(11)【公開番号】P2023041390

(43)【公開日】2023-03-24

(54)【発明の名称】情報処理装置、認証方法、認証プログラムおよび患者認証システム

(51)【国際特許分類】

   G06F 21/35 20130101AFI20230316BHJP

   G06Q 50/22 20180101ALI20230316BHJP

【ＦＩ】

G06F21/35

G06Q50/22

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2021148749

(22)【出願日】2021-09-13

(71)【出願人】

【識別番号】521403580

【氏名又は名称】株式会社富士通ゼネラルＯＳテクノロジー

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】石神 康将

(72)【発明者】

【氏名】小八重 幹夫

(72)【発明者】

【氏名】成田 政繁

(72)【発明者】

【氏名】笠原 大輔

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

5L099

【Ｆターム（参考）】

5L099AA21

(57)【要約】

【課題】患者本人であることを簡易かつ正確に認証することを課題とする。
【解決手段】モバイルサーバは、病院に診察を予約した患者が使用する患者端末から、患者を識別する識別子と患者が病院で受け付けすることにより発行される受付番号とを含む患者情報を受信する。モバイルサーバは、診察の予約者に関する予約情報を管理する院内サーバに、患者情報を送信し、診察を予約した患者であることの認証を要求する。モバイルサーバは、院内サーバによる認証結果を患者端末に送信する。
【選択図】図２

【特許請求の範囲】

【請求項1】

病院に診察を予約した患者が使用する患者端末から、前記患者を識別する識別子と前記患者が前記病院で受け付けすることにより発行される受付番号とを含む患者情報を受信する受信部と、
前記診察の予約者に関する予約情報を管理する院内サーバに、前記患者情報を送信し、前記診察を予約した患者であることの認証を要求する要求部と、
前記院内サーバによる認証結果を前記患者端末に送信する送信部と、
を有する情報処理装置。

【請求項2】

前記受付番号は、前記病院に設置される受付機に前記患者の診察券を投入することで発行される、診察日当日に前記患者へ付与される受付番号である、請求項１に記載の情報処理装置。

【請求項3】

前記要求部は、
前記認証とともに前記診察に関するモバイルサービスの利用登録の要求を前記院内サーバに要求し、
前記送信部は、
前記診察に関するモバイルサービスの利用登録の要求に対する応答として、前記院内サーバが前記患者情報を登録している場合に発行するサービス利用情報を、前記院内サーバから受信した場合に、前記患者端末に前記モバイルサービスの利用許可を通知する、請求項１または２に記載の情報処理装置。

【請求項4】

前記受信部は、
前記患者を特定する個人情報をさらに含む前記患者情報を受信し、
前記要求部は、
前記院内サーバに前記患者情報を送信して前記モバイルサービスの利用登録を要求し、
前記送信部は、
前記院内サーバが前記患者情報を登録している場合に発行する前記サービス利用情報を、前記院内サーバから受信した場合に、前記患者端末に前記モバイルサービスの利用許可を通知する、請求項３に記載の情報処理装置。

【請求項5】

前記要求部は、
前記患者端末から受信された前記患者情報に対して申込番号を付与し、前記患者情報と前記申込番号とを対応付けて登録情報として記憶部に格納し、
前記登録情報を前記院内サーバに送信して前記サービス利用情報の発行を要求するとともに、前記記憶部に記憶される前記患者情報のうち前記識別子と前記受付番号とを削除し、
前記送信部は、
前記院内サーバから前記サービス利用情報と前記申込番号とを受信し、前記申込番号に対応付けて前記サービス利用情報を前記記憶部に格納し、前記患者端末に前記モバイルサービスの利用許可を通知する、請求項３または４に記載の情報処理装置。

【請求項6】

前記院内サーバから、前記サービス利用情報と前記患者へのメッセージとを受信し、
前記記憶部を参照し、前記サービス利用情報に対応付けられる前記患者端末を特定し、
特定された前記患者端末に前記メッセージを送信する、提供部をさらに有する、請求項５に記載の情報処理装置。

【請求項7】

コンピュータが、
病院に診察を予約した患者が使用する患者端末から、前記患者を識別する識別子と前記患者が前記病院で受け付けすることにより発行される受付番号とを含む患者情報を受信し、
前記診察の予約者に関する予約情報を管理する院内サーバに、前記患者情報を送信し、前記診察を予約した患者であることの認証を要求し、
前記院内サーバによる認証結果を前記患者端末に送信する、
処理を実行する認証方法。

【請求項8】

コンピュータに、
病院に診察を予約した患者が使用する患者端末から、前記患者を識別する識別子と前記患者が前記病院で受け付けすることにより発行される受付番号とを含む患者情報を受信し、
前記診察の予約者に関する予約情報を管理する院内サーバに、前記患者情報を送信し、前記診察を予約した患者であることの認証を要求し、
前記院内サーバによる認証結果を前記患者端末に送信する、
処理を実行させる認証プログラム。

【請求項9】

病院に診察を予約した患者が使用する患者端末と、前記診察の予約者に関する予約情報を管理する院内サーバと、前記患者端末と前記院内サーバとの通信を中継する情報処理装置とを有する情報処理システムにおいて、
前記患者端末は、
前記患者を識別する識別子と前記患者が前記病院で受け付けすることにより発行される受付番号とを含む患者情報を前記情報処理装置に送信する送信部を有し、
前記情報処理装置は、
前記患者端末から受信した前記患者情報を前記院内サーバに送信して、前記診察に関するモバイルサービスの利用登録を要求する要求部と、
前記院内サーバによる前記利用登録の結果を前記患者端末に送信する送信部と、を有し、
前記院内サーバは、
前記診察を予約した予約者に関する予約情報を記憶する記憶部と、
前記予約情報に前記患者情報が登録されている場合に、前記モバイルサービスの利用登録を実行し、前記利用登録の結果を前記情報処理装置に通知する通知部を有する、
患者認証システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理装置、認証方法、認証プログラムおよび患者認証システムに関する。

【背景技術】

【0002】

病院などの医療現場では、医師や看護師などの医療スタッフによる医療内容や診察等に限らず、院内受付時における患者対応の不備、患者取り違え、患者のなりすましなども医療事故に発展する機会があり、起きた場合のリスクは大きい。このような患者本人を認証する技術としては、生体認証、シングルサインオン、ワンタイムパスワードなどが知られている。

【先行技術文献】

【特許文献】

【0003】

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

【特許文献2】特開２０１７－１５１７３２号公報

【発明の概要】

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

【0004】

しかしながら、上記技術では、正確に本人であることを簡易に認証することが難しい。例えば、生体認証を行う場合、スマートフォンなどの移動体端末や院内に設置された装置により、顔画像や静脈などを撮像して登録することになるが、患者一人一人を撮像するには時間がかかり、取り直しなども発生するので、簡易に認証することが難しい。

【0005】

また、外部サーバを用いたシングルサインオンや院内のサーバを用いたワンタイムパスワードの発行では、患者本人が使用する端末への発行を前提としており、発行先の端末がすでになりすました第三者の端末であっても認証が成立してしまう危険性もあり、認証精度が高いとは言い難い。

【0006】

一方、近年では、総務省が推進するＰＨＲ（パーソナルヘルスレコード）のスマートフォンのアプリケーション（以下では、単に「アプリ」と記載する場合がある）の利用が想定されている。本アプリでは、自身の健康情報、お薬の処方情報の参照、通院に便利な予約や順番待ちの機能が想定されている。本アプリは、病院の電子カルテシステムとの情報連携が必須となり、本人であることを認証する必要がある。しかし、上述した各認証技術では、カメラ撮像、ワンタイムパスワード発行のための空メール送信などの作業が発生するが、特に年配の方や体調が芳しくない人が行うには煩わしく、本アプリの普及にも繋がりにくい。

【0007】

一つの側面では、患者本人であることを簡易かつ正確に認証することができる情報処理装置、認証方法、認証プログラムおよび患者認証システムを提供することを目的とする。

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

【0008】

第１の案では、情報処理装置は、病院に診察を予約した患者が使用する患者端末から、前記患者を識別する識別子と前記患者が前記病院で受け付けすることにより発行される受付番号とを含む患者情報を受信する受信部と、前記診察の予約者に関する予約情報を管理する院内サーバに、前記患者情報を送信し、前記診察を予約した患者であることの認証を要求する要求部と、前記院内サーバによる認証結果を前記患者端末に送信する送信部と、を有する。

【発明の効果】

【0009】

一実施形態によれば、患者本人であることを簡易かつ正確に認証することができる。

【図面の簡単な説明】

【0010】

【図1】図１は、実施例１にかかる患者認証システムの全体構成例を示す図である。

【図2】図２は、実施例１にかかる患者認証システムによる処理を説明する図である。

【図3】図３は、実施例１にかかる患者認証システムの機能構成を示す機能ブロック図である。

【図4】図４は、各種画面例を示す図である。

【図5】図５は、患者情報ＤＢに記憶される情報の例を示す図である。

【図6】図６は、患者情報ＤＢの遷移を示す図である。

【図7】図７は、予約情報ＤＢに記憶される情報の例を示す図である。

【図8】図８は、予約情報ＤＢの遷移を示す図である。

【図9】図９は、実施例１にかかる患者認証システムの処理の流れを示すシーケンス図である。

【図10】図１０は、再度の診察予約時の患者認証システムの処理の流れを示すシーケンス図である。

【図11】図１１は、ハードウェア構成例を説明する図である。

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

【0011】

以下に、本願の開示する情報処理装置、認証方法、認証プログラムおよび患者認証システムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。

【実施例0012】

［全体構成］
図１は、実施例１にかかる患者認証システムの全体構成例を示す図である。図１に示すように、患者認証システムは、患者１が使用する患者端末１０と、モバイルサーバ５０と、病院７０が管理する院内サーバ８０とがネットワークＮを介して接続されるシステムであって、正当な患者を認証して診察に関する各種サービスを提供するシステムである。なお、ネットワークＮは、有線や無線を問わず、インターネットや専用線などの各種通信網を採用することができる。

【0013】

患者端末１０は、病院７０に診察の予約を行う患者１が使用する携帯電話、スマートフォンなどの端末装置の一例である。この患者端末１０は、各種アプリケーション、Ｗｅｂページ、ソーシャル・ネットワーキング・サービス（SNS：Social Networking Service）などを利用することができる。

【0014】

モバイルサーバ５０は、患者端末１０と院内サーバ８０との通信を中継する情報処理装置の一例である。例えば、モバイルサーバ５０は、クラウドシステムなどを利用した情報処理装置であり、患者端末１０との間で特定のアプリケーションを用いたデータ通信を実行することができる。

【0015】

院内サーバ８０は、病院７０が管理する情報処理装置の一例であり、病院７０の電子カルテなどを管理する管理サーバにアクセス可能な情報処理装置である。例えば、院内サーバ８０は、診察を予約した患者に関する予約情報を記憶する。

【0016】

このような構成を有する患者認証システムは、来院した患者受付時において、院内における特有の情報である本人しか受け取らない「受付番号」とクラウドサービスを用いた多要素認証による本人確認方法を強化し、患者取り違え、なりすまし防止、個人情報の管理強化を図る仕組みを提供し、医療事故に発展するリスクを低減させる。

【0017】

例えば、モバイルサーバ５０は、病院７０に診察を予約した患者１が使用する患者端末１０から、患者１を識別する識別子と患者１が病院８０で受け付けすることにより発行される受付番号とを含む患者情報を受信する。そして、モバイルサーバ５０は、診察の予約者に関する予約情報を管理する院内サーバ８０に、患者情報を送信し、診察に関するモバイルサービスの利用登録を要求し、院内サーバ７０による利用登録の結果を患者端末１０に送信する。

【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】

ここで、各処理部の処理については、図６に示した患者情報ＤＢ５３の遷移も用いて説明する。なお、図６は、患者情報ＤＢ５３の遷移を示す図である。

【0047】

受信部６１は、病院に診察を予約した患者１が使用する患者端末１０から、患者１を識別する患者ＩＤと患者１が病院７０で受け付けすることにより発行される受付番号とを含む患者情報を受信する処理部である。例えば、受信部６１は、患者端末１０から、「ユーザＩＤ：ＡＡＡＡ」と「患者情報（患者ＩＤ：１１１１、受付番号：０００１、生年月日：１９８９１１１２）」を受信する。そして、受信部６１は、図６の（ａ）に示すように、受信したこれらの情報を患者情報ＤＢ５３に格納する。

【0048】

なお、受信部６１は、Ｗｅｂブラウザなどを用いて患者情報を受信した場合は、あわせて送信されたユーザＩＤ「ＡＡＡＡ」も受信するが、患者端末１０との間でネゴシエーション済みのＳＮＳのメッセージ機能などを用いて患者情報を受信した場合は、当該ＳＮＳメッセージからにユーザＩＤを取得することもできる。

【0049】

要求部６２は、院内サーバ８０に、受信部６１により受信された患者情報を送信し、診察を予約した患者であることの認証やモバイルサービスの利用登録の要求を実行する処理部である。例えば、要求部６２は、受信された患者情報（患者ＩＤ：１１１１、受付番号：０００１、生年月日：１９８９１１１２）に対して申込ＩＤ「１」を付与する。そして、要求部６２は、図６の（ｂ）に示すように、患者情報ＤＢ５３に記憶される患者情報（患者ＩＤ：１１１１、受付番号：０００１、生年月日：１９８９１１１２）に、付与した申込ＩＤ「１」を対応付けて格納する。

【0050】

その後、要求部６２は、患者情報（患者ＩＤ：１１１１、受付番号：０００１、生年月日：１９８９１１１２）と申込ＩＤ「１」とを登録情報として、院内サーバ８０に送信して、患者１の認証およびモバイルサービスの利用登録を要求する。ここで、要求部６２は、図６の（ｃ）に示すように、申込ＩＤにより患者（ユーザＩＤ：ＡＡＡＡ）が特定可能となったことから、患者１から送信された「患者ＩＤ：１１１１、受付番号：０００１、生年月日：１９８９１１１２」を患者情報ＤＢ５３から削除する。この結果、モバイルサーバ５０では、患者１の個人情報を保存しないことになり、患者１にとって安心安全な中継サーバとして振舞うことができ、高いセキュリティを維持することもできる。

【0051】

送信部６３は、院内サーバ８０による患者１の認証結果やモバイルサービスの利用登録の要求に対する応答結果を患者端末１０に送信する処理部である。例えば、送信部６３は、院内サーバ８０から、要求部６２により送信された申込ＩＤ「１」とともに、患者１の認証結果「ＯＫ」と利用登録の応答結果であるサービス利用ＩＤ「ＸＸＸＸＸＸ」を受信する。

【0052】

すると、送信部６３は、図６の（ｄ）に示すように、申込ＩＤ「１」をキーにして患者情報ＤＢ５３を検索し、該当する患者情報に、サービス利用ＩＤ「ＸＸＸＸＸＸ」を登録する。そして、送信部６３は、認証結果「ＯＫ」やサービス利用登録の許可などを、患者端末１０に送信する。

【0053】

提供部６４は、院内サーバ８０から、サービス利用ＩＤと患者へのメッセージとを受信した場合に、患者情報ＤＢ５３を参照し、サービス利用ＩＤに対応付けられる患者端末１０を特定し、患者端末１０にメッセージを送信する処理部である。

【0054】

例えば、提供部６４は、サービス利用ＩＤ「ＸＸＸＸＸＸ」およびメッセージ「予約時間が近づいています。予約日時」を受信すると、患者情報ＤＢ５３から、サービス利用ＩＤ「ＸＸＸＸＸＸ」に対応付けられる「ユーザＩＤ：ＡＡＡＡ」を特定する。その後、提供部６４は、「ユーザＩＤ：ＡＡＡＡ」で特定される患者端末１０に、ＳＮＳメッセージなどを用いて、メッセージ「予約時間が近づいています。予約日時」を送信する。

【0055】

（院内サーバ８０）
図３に示すように、院内サーバ８０は、通信部８１、記憶部８２、制御部９０を有する。通信部８１は、他の装置との間の通信を制御する処理部であり、例えば通信インタフェースなどにより実現される。例えば、通信部８１は、患者端末１０やモバイルサーバ５０に各種データを送信し、患者端末１０やモバイルサーバ５０から各種データを受信する。

【0056】

記憶部８２は、各種データや制御部９０が実行するプログラムなどを記憶する処理部であり、例えばメモリやハードディスクなどにより実現される。例えば、記憶部８２は、予約情報ＤＢ８３を記憶する。

【0057】

予約情報ＤＢ８３は、診察を予約した患者の予約情報を記憶するデータベースである。具体的には、予約情報ＤＢ８３は、予約者を特定する患者情報と、正当な患者であるか否かが認証された結果と、モバイルサービスの利用登録が完了しているか否かを示す情報とを対応付けて記憶する。

【0058】

図７は、予約情報ＤＢ８３に記憶される情報の例を示す図である。図７に示すように、予約情報ＤＢ８３は、「患者ＩＤ、サービス利用ＩＤ、生年月日、受付番号、申込ＩＤ、認証結果、予約済み診療科、予約日時」を記憶する。

【0059】

ここで記憶される「患者ＩＤ」は、患者１を識別する識別子である。「サービス利用ＩＤ」は、正当な患者に対して発行されるモバイルサービスの利用に用いる識別子である。「生年月日」は、患者１の個人情報の一例であり、予約時に入力もしくは取得される。「受付番号」は、正当な患者１に対して発行された受付番号である。「認証結果」は、正当な患者１であることを認証した結果であり、例えば認証成功の場合には「ＯＫ」、認証失敗の場合には「ＮＧ」が登録される。「予約済み診療科」は、患者１が診察予約した診療科が登録され、「予約日時」には、患者１が診察予約した予約日時が登録される。

【0060】

図７の例では、「２０２１年９月３日１４：００」に「内科」を予約した「患者ＩＤ：１１１」の予約情報を示しており、「生年月日：１９８９１１１２」と「受付番号：０００１」等を用いてその患者の認証が許可（ＯＫ）されており、サービス利用ＩＤ「ＸＸＸＸＸＸ」が割り振られたことが示されている。

【0061】

制御部９０は、院内サーバ８０全体を司る処理部であり、例えばプロセッサなどにより実現される。この制御部６０は、受信部６１、要求部６２、送信部６３、提供部６４を有する。なお、受信部６１、要求部６２、送信部６３、提供部６４は、プロセッサが有する電子回路やプロセッサが実行するプロセスなどにより実現される。

【0062】

ここで、各処理部の処理については、図８に示した予約情報ＤＢ８３の遷移も用いて説明する。なお、図８は、予約情報ＤＢ８３の遷移を示す図である。

【0063】

予約登録部９１は、患者の予約情報を登録する処理部である。具体的には、予約登録部９１は、Ｗｅｂ画面、ＳＮＳメッセージ、専用のアプリなどを用いて、患者１の診察予約を受け付けて、予約情報ＤＢ８３に格納する。

【0064】

例えば、予約登録部９１は、図８の（ａ）に示すように、予約情報ＤＢ８３に患者１の予約情報が登録されていない状態で、予約情報として「患者ＩＤ：１１１１、生年月日：１９８９１１１２、内科、２０２１年９月３日１４：００」を受け付ける。すると、予約登録部９１は、図８の（ｂ）に示すように、予約情報ＤＢ８３に予約情報を登録する。なお、予約登録部９１は、電話等により予約情報等が受け付けられた場合、事務員により予約情報の入力を受け付けて、予約情報ＤＢ８３に予約情報を登録することもできる。

【0065】

さらに、予約登録部９１は、再来受付機７５により受付番号「０００１」が印字された受付票が発行されると、再来受付機７５から、投入された診察券の患者ＩＤ「１１１１」と発行された受付番号「０００１」との対応付けを取得する。そして、予約登録部９１は、図８の（ｃ）に示すように、予約情報ＤＢ８３において、患者ＩＤ「１１１１」に対応付けて受付番号「０００１」を登録する。

【0066】

認証部９２は、患者端末１０から受信した患者情報が予約情報ＤＢ８３に登録されているか否かにより、患者１の認証を実行する処理部である。具体的には、認証部９２は、モバイルサーバ５０を介して、患者端末１０から申込ＩＤと患者情報とを含む登録情報を受信し、その患者情報が予約情報ＤＢ８３に登録済みの場合に、正当な患者１であると認証する。この場合、認証部９２は、公知の不可逆変換処理を用いて、申込ＩＤを１６バイトのハッシュ値へ変換したサービス利用ＩＤを生成する。その後、認証部９２は、モバイルサーバ５０に、認証結果とサービス利用ＩＤとを送信する。

【0067】

一方、認証部９２は、受信した患者情報が予約情報ＤＢ８３に登録されていない場合に、正当な患者１ではないと判定し、モバイルサーバ５０に認証拒否を送信する。

【0068】

例えば、図８の（ｃ）に示すように予約情報が予約情報ＤＢ８３に登録されている状態で、認証部９２は、申込ＩＤ「１」と患者情報「患者ＩＤ：１１１１、生年月日：１９８９１１１２、受付番号：００００１」を受信する。この場合、認証部９２は、予約情報ＤＢ８３に登録されている予約情報の「患者ＩＤ：１１１１、生年月日：１９８９１１１２、受付番号：００００１」と、受信した患者情報「患者ＩＤ：１１１１、生年月日：１９８９１１１２、受付番号：００００１」とが一致することから、認証を許可する。

【0069】

そして、認証部９２は、図８の（ｄ）に示すように、申込ＩＤ「１」をサービス利用ＩＤ「ＸＸＸＸＸＸ」に変換し、「患者ＩＤ：１１１１」に対応付けて、認証結果「ＯＫ」とサービス利用ＩＤ「ＸＸＸＸＸＸ」を予約情報ＤＢ８３に格納する。その後、認証部９２は、モバイルサーバ５０に、認証結果「ＯＫ」とサービス利用ＩＤ「ＸＸＸＸＸＸ」とを送信する。

【0070】

サービス提供部９３は、モバイルサービスの利用登録済みである患者１に対して、診察に関するメッセージを送信する処理部である。上記例で説明すると、サービス提供部９３は、「２０２１年９月３日」になると、予約情報ＤＢ８３を参照し、各患者の予約日時を検索する。該当する予約日時が検索された場合、サービス提供部９３は、メッセージ「予約時間が近づいています」にサービス利用ＩＤ「ＸＸＸＸＸＸ」を付加して、モバイルサーバ５０に送信する。

【0071】

［処理の流れ］
図９は、実施例１にかかる患者認証システムの処理の流れを示すシーケンス図である。図９に示すように、患者端末１０は、院内サーバ８０にアクセスして診察予約を実行し（Ｓ１０１）、予約情報「患者ＩＤ、生年月日、予約情報」を院内サーバ８０に送信する（Ｓ１０２）。院内サーバ８０は、受信した予約情報を予約情報ＤＢ８３に登録する（Ｓ１０３）。

【0072】

その後、患者端末１０は、診察予約日の当日に診察券を再来受付機７５に投入することで発行される受付番号を取得する（Ｓ１０４とＳ１０５）。そして、患者端末１０は、ユーザＩＤと患者情報（患者ＩＤ、生年月日、受付番号）を含む登録情報をモバイルサーバ５０に送信し、認証およびモバイルサービスの利用登録を要求する（Ｓ１０６とＳ１０７）。

【0073】

そして、モバイルサーバ５０は、受信した登録情報を患者情報ＤＢ５３に登録し（Ｓ１０８）、当該患者に対して申込ＩＤを発行して患者情報ＤＢ５３に登録する（Ｓ１０９）。その後、モバイルサーバ５０は、患者情報ＤＢ５３に記憶される患者情報（患者ＩＤ、生年月日、受付番号）を削除し（Ｓ１１０）、患者情報（患者ＩＤ、生年月日、受付番号）と申込ＩＤとを含む利用登録の要求を、院内サーバ８０に送信する（Ｓ１１１とＳ１１２）。

【0074】

続いて、院内サーバ８０は、利用登録の要求として、患者情報（患者ＩＤ、生年月日、受付番号）と申込ＩＤとを受信し、患者情報が予約情報ＤＢ８３に登録されているか否かにより、患者１および利用登録の認証を実行する（Ｓ１１３）。そして、院内サーバ８０は、患者１および利用登録を許可すると、申込ＩＤをサービス利用ＩＤに変換して予約情報ＤＢ８３に登録する（Ｓ１１４）。その後、院内サーバ８０は、申込ＩＤ、サービス利用ＩＤ、認証結果をモバイルサーバ５０に送信する（Ｓ１１５とＳ１１６）。

【0075】

モバイルサーバ５０は、院内サーバ８０から受信したサービス利用ＩＤと認証結果を患者情報ＤＢ５３に登録し（Ｓ１１７）、認証結果を患者端末１０に通知する（Ｓ１１８とＳ１１９）。

【0076】

上記処理の結果、患者端末１０の患者１と院内サーバ８０との間で、モバイルサーバ５０を介した患者認証およびサービス登録が正常に実行される（Ｓ１２０）。

【0077】

その後、院内サーバ８０は、予約日時に近づいたことを契機に、患者１に対してメッセージを生成し、予約情報ＤＢ８３に登録されている当該患者１のサービス利用ＩＤと、生成したメッセージとをモバイルサーバ５０に送信する（Ｓ１２１とＳ１２２）。

【0078】

すると、モバイルサーバ５０は、受信したサービス利用ＩＤに対応付けられるユーザＩＤを患者情報ＤＢ５３から特定し（Ｓ１２３）、特定したユーザＩＤを用いて、受信したメッセージを患者端末１０に送信する（Ｓ１２４とＳ１２５）。

【0079】

この結果、患者端末１０は、院内サーバ８０からメッセージを受信して表示することができる（Ｓ１２６）。

【0080】

なお、患者１は、一度、受付番号を用いた認証および利用登録を完了した場合、新たな診察を予約したとしても、新たな受付番号を取得する必要はなく、モバイルサービスを継続的に利用することができる。

【0081】

図１０は、再度の診察予約時の患者認証システムの処理の流れを示すシーケンス図である。図１０に示すように、図９で説明した処理により、患者端末１０の患者１と院内サーバ８０との間で、モバイルサーバ５０を介した患者認証およびサービス登録が正常に完了している状態である（Ｓ２０１）。

【0082】

この状態で、患者端末１０は、新たな診察予約を実行し（Ｓ２０２）、新たな予約情報「患者ＩＤ、生年月日、新たな予約日時」を院内サーバ８０に送信する（Ｓ２０３）。院内サーバ８０は、患者ＩＤの予約済みの予約情報を、受信した新たな予約情報で更新する（Ｓ２０４）。

【0083】

その後、院内サーバ８０は、新たな予約日時に近づいたことを契機に、患者１に対してメッセージを生成し、予約情報ＤＢ８３に登録されている患者１のサービス利用ＩＤと、生成したメッセージとをモバイルサーバ５０に送信する（Ｓ２０５とＳ２０６）。

【0084】

すると、モバイルサーバ５０は、受信したサービス利用ＩＤに対応付けられるユーザＩＤを患者情報ＤＢ５３から特定し（Ｓ２０７）、特定したユーザＩＤを用いて、受信したメッセージを患者端末１０に送信する（Ｓ２０８とＳ２０９）。

【0085】

この結果、患者端末１０は、新たな診察予約時も、以前に登録した情報を活用することで、院内サーバ８０からメッセージを受信して表示することができる（Ｓ２１０）。

【0086】

［効果］
上述したように、患者予約システムは、当日病院に来院して再来受付機７５に診察券を挿入することによって、予約情報にしたがって発行される受付票に印字される当日の受付番号であって、診察券をもっている本人にしか知り得ない受付番号を用いることで、患者本人であることを簡易かつ正確に認証することができる。さらに、患者予約システムは、生年月日、マイナンバー、住所などの個人情報をさらに用いることで、セキュリティレベルを向上させることができる。

【0087】

患者予約システムは、来院した患者受付時において、院内における特有の情報である本人しか受け取らない「受付番号」とクラウドサービスを使った多要素認証による本人確認方法を強化し、患者取り違え、なりすまし防止、個人情報の管理強化をはかるしくみとして提供し、医療事故に発展するリスクを低減させることができる。

【0088】

患者予約システムは、ワンタイムパスワードのように新たなパスワードを用いることがないので、パスワード管理などの煩わしさを軽減することができる。患者予約システムは、患者本人しか知り得ない診察券、予約情報、受付番号を組み合わせることで、セキュリティレベルを向上させることができるとともに、診察予約に関係しないパスワードなどを用いることもないので、簡易さも向上させることができる。

【0089】

さらに、患者予約システムは、簡易さと高セキュリティを両立させることができるので、ＰＨＲのアプリ普及も期待することができる。

【実施例0090】

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。

【0091】

［数値等］
上記実施例で用いた数値、各装置の数等は、あくまで一例であり、任意に変更することができる。また、各シーケンス図等で説明した処理の流れも矛盾のない範囲内で適宜変更することができる。

【0092】

［受付番号の取得］
例えば、患者端末１０は、診察券を再来受付機７５に入力することで受付票を取得し、受付票に印字された二次元バーコードを読み取ることで、患者ＩＤ、受付番号を登録画面１０Ａに自動入力することもできる。

【0093】

［モバイルサービスの例］
上記実施例では、メッセージ送信を例にして説明したが、これに限定されるものではない。例えば、待合室での順番表示、会計時の呼び出し、処方箋の提示や出力、薬の管理などをモバイルサービスとして提供することができる。

【0094】

［システム］
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更されてもよい。

【0095】

また、各装置の構成要素の分散や統合の具体的形態は図示のものに限られない。例えば、要求部６２と送信部６３とが統合されてもよい。つまり、その構成要素の全部または一部は、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合されてもよい。さらに、各装置の各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

【0096】

［ハードウェア］
図１１は、ハードウェア構成例を説明する図である。なお、患者端末１０とモバイルサーバ５０と院内サーバ８０とは同じハードウェア構成を有するので、ここでは、情報処理装置１００として説明する。図１１に示すように、情報処理装置１００は、通信装置１００ａ、ＨＤＤ（Hard Disk Drive）１００ｂ、メモリ１００ｃ、プロセッサ１００ｄを有する。また、図１１に示した各部は、バス等で相互に接続される。

【0097】

通信装置１００ａは、ネットワークインタフェースカードなどであり、他の装置との通信を行う。ＨＤＤ１００ｂは、図３に示した機能を動作させるプログラムやＤＢを記憶する。

【0098】

プロセッサ１００ｄは、図３に示した各処理部と同様の処理を実行するプログラムをＨＤＤ１００ｂ等から読み出してメモリ１００ｃに展開することで、図３等で説明した各機能を実行するプロセスを動作させる。例えば、モバイルサーバ５０を例にすると、このプロセスは、モバイルサーバ５０が有する各処理部と同様の機能を実行する。具体的には、プロセッサ１００ｄは、受信部６１、要求部６２、送信部６３、提供部６４等と同様の機能を有するプログラムをＨＤＤ１００ｂ等から読み出す。そして、プロセッサ１００ｄは、受信部６１、要求部６２、送信部６３、提供部６４等と同様の処理を実行するプロセスを実行する。

【0099】

このように、情報処理装置１００は、プログラムを読み出して実行することで情報処理方法を実行する情報処理装置として動作する。また、情報処理装置１００は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、情報処理装置１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、上記実施例が同様に適用されてもよい。

【0100】

このプログラムは、インターネットなどのネットワークを介して配布されてもよい。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ、ＭＯ（Magneto－Optical disk）、ＤＶＤ（Digital Versatile Disc）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行されてもよい。