▶ 株式会社ｅＢａｓｅ Ｓｏｌｕｔｉｏｎｓ Ｌａｂｏｒａｔｏｒｙの特許一覧 ▶ 国立大学法人鳥取大学の特許一覧
特許7287613支援サーバ、患者向けコンピュータプログラム及びサービス支援方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-05-29
(45)【発行日】2023-06-06
(54)【発明の名称】支援サーバ、患者向けコンピュータプログラム及びサービス支援方法
(51)【国際特許分類】
G16H 40/20 20180101AFI20230530BHJP
【ＦＩ】
G16H40/20
【請求項の数】
8
(21)【出願番号】P 2020088853
(22)【出願日】2020-05-21
(65)【公開番号】P2021184146
(43)【公開日】2021-12-02
【審査請求日】2022-09-21
【新規性喪失の例外の表示】特許法第３０条第２項適用 ２０１９年５月２８日にウェブサイトからアプリリリース ２０１９年５月２８日に鳥取大学医学部附属病院内にてチラシ配布 ２０１９年９月２４日に鳥取大学医学部附属病院ウェブサイトにて公開 ２０１９年９月２４日に鳥取大学医学部附属病院内にてパンフレット配布 ２０１９年１０月７日に鳥取大学医学部附属病院内にて公開記者会見 ２０１９年１０月８日に鳥取大学医学部附属病院内にて動画公開 ２０１９年１０月１７日の愛媛新聞朝刊に掲載 ２０１９年１０月１７日の京都新聞夕刊に掲載 ２０１９年１０月１７日の東奥日報に掲載 ２０１９年１１月２８日に鳥取大学医学部附属病院内にて広報誌配置 ２０２０年１月３０日に令和元（２０１９）年度大学病院情報マネジメント部門連絡会議（秋田キャッスルホテル）にて発表 ２０２０年２月１日に第９回山陰文化圏医療情報技術研究会（米子医療センター・くずもホール）にて発表
【早期審査対象出願】
(73)【特許権者】
【識別番号】511160099
【氏名又は名称】株式会社ｅＢａｓｅ Ｓｏｌｕｔｉｏｎｓ Ｌａｂｏｒａｔｏｒｙ
(73)【特許権者】
【識別番号】504150461
【氏名又は名称】国立大学法人鳥取大学
(74)【代理人】
【識別番号】100149696
【弁理士】
【氏名又は名称】田中 俊夫
(72)【発明者】
【氏名】冨田 祐一郎
(72)【発明者】
【氏名】寺本 圭
(72)【発明者】
【氏名】原田 省
(72)【発明者】
【氏名】武中 篤
(72)【発明者】
【氏名】近藤 博史
【審査官】木村 慎太郎
(56)【参考文献】
【文献】特開２０１８－０１０６８２（ＪＰ，Ａ）
【文献】特開２０１９－０８６９７５（ＪＰ，Ａ）
【文献】特開２０１９－０７４８７９（ＪＰ，Ａ）
【文献】特開２０２０－０１６９９４（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ１６Ｈ ４０／２０
(57)【特許請求の範囲】
【請求項1】
患者が対象医療機関で受診するための受付及び呼び出しを支援する支援サーバであって、患者を識別し得るユニークＩＤとその患者の携帯端末の端末トークンとを関連付けて格納する端末情報テーブルと、
各患者に関してユニークＩＤと受付情報と呼出確認履歴とをそれぞれ格納する患者管理テーブルと、
前記患者の携帯端末の位置情報を取得する位置取得手段と、
前記位置情報が所定条件を満たすか否かを判定し、該判定の結果に応じて前記患者の携帯端末が受付操作可能状態又は受付操作不可能状態に切り替わるよう制御する端末制御手段と、
電子カルテシステムの端末に対する受付済み患者を指定した呼び出し操作に応じて、その受付済み患者のユニークＩＤを含む呼び出し指示を取得する指示取得手段と、
前記取得された呼び出し指示に含まれるユニークＩＤと関連付けられて前記端末情報テーブルに格納されている端末トークンを指定して、そのユニークＩＤを含む呼び出し情報のプッシュ通知を行う呼出送信手段と、
前記呼び出し情報のプッシュ通知を受けた前記受付済み患者の携帯端末において表示される、患者名称、受付情報及び通知メッセージを含む呼び出し情報表示に対するユーザの確認操作に伴って、その携帯端末から、呼び出し情報の確認操作が行われたことを示しかつ前記受付済み患者のユニークＩＤを含む確認情報を受信する確認受信手段と、
前記呼び出し情報のプッシュ通知及び前記確認情報の受信に応じて、前記受付済み患者のユニークＩＤと関連付けられて前記患者管理テーブルに格納されている呼出確認履歴に、呼び出しの履歴と確認の履歴とを追加する保持手段と、
前記受付済み患者の携帯端末からの前記確認情報の受信に伴い、前記受付済み患者のユニークＩＤを含む確認情報を前記電子カルテシステムへ送信する手段と、
を備える支援サーバ。
【請求項2】
登録対象患者の診察券から取得された患者ＩＤ及びその患者ＩＤに対応して生成されたユニークＩＤを取得した携帯端末から、そのユニークＩＤとその携帯端末の端末トークンを含む登録要求を受信する手段と、
前記受信された登録要求に含まれるユニークＩＤ及び端末トークンを関連付けて前記端末情報テーブルに追加格納する手段と、
前記受信された登録要求に含まれるユニークＩＤを含む患者情報を前記患者管理テーブルに追加格納する手段と、
前記携帯端末から前記ユニークＩＤを含むテスト呼出要求を受信する手段と、
前記受信されたテスト呼出要求に含まれるユニークＩＤに基づいて、そのユニークＩＤと関連付けられて前記端末情報テーブルに格納されている端末トークンを指定してテスト呼出情報のプッシュ通知を行う手段と、
を更に備え、
前記電子カルテシステム及び各患者の携帯端末は、各患者の患者ＩＤと各患者のユニークＩＤとを関連付けて保持している一方で、前記支援サーバは、前記患者ＩＤを保持しない、
請求項１に記載の支援サーバ。
【請求項3】
請求項１又は２に記載の支援サーバと通信可能な前記携帯端末で実行され得る患者向けコンピュータプログラムであって、前記携帯端末に、
前記支援サーバから送られる情報に基づいて、前記受付操作可能状態又は前記受付操作不可能状態に切り替えさせ、
受付操作が検出された場合に、受付対象となる患者のユニークＩＤを含む受付申請情報を前記支援サーバへ送信させ、
前記支援サーバから前記受付申請情報に対応する受付回答情報を受信させ、
前記受信された受付回答情報が受付エラーを示す場合には、エラー内容を示す情報を表示させ、前記受信された受付回答情報が受付完了を示す場合には、受付完了を示す情報を表示させ、
前記支援サーバからの前記呼び出し情報のプッシュ通知を受けて、受付済み患者の名称、受付情報及び通知メッセージを含む呼び出し情報を確認操作可能に表示させ、
前記呼び出し情報の表示に対するユーザの確認操作が検出されると、呼び出し情報の確認操作が行われたことを示しかつ前記受付済み患者のユニークＩＤを含む確認情報を前記支援サーバへ送信させる、
患者向けコンピュータプログラム。
【請求項4】
前記携帯端末に、更に、複数の患者の各々に関するユニークＩＤと患者名称とをそれぞれ関連付けて保持させ、
前記複数の患者の中から受付の対象となる患者を選択可能とする選択表示を出力させ、
受付操作が検出された場合に、前記選択表示で選択された患者のユニークＩＤを含む受付申請情報を前記支援サーバへ送信させ、
前記複数の患者の各々について受付済み状態か否かを管理させ、
前記支援サーバから前記呼び出し情報のプッシュ通知を受けた場合に、その呼び出し情報に含まれるユニークＩＤに関連付けられて保持されている患者名称を前記受付済み患者の名称として前記呼び出し情報の表示に含め、
ユーザの受付操作を可能とする一つの受付操作部を表示させ、
ユニークＩＤが保持されている前記複数の患者のすべてが受付済み状態となったことを契機に、前記受付操作可能状態から前記受付操作不可能状態に遷移させると共に、前記一つの受付操作部の表示態様を変更する、
請求項３に記載の患者向けコンピュータプログラム。
【請求項5】
請求項２に記載の支援サーバと通信可能な前記携帯端末で実行され得る患者向けコンピュータプログラムであって、
前記携帯端末に、
患者情報テーブルを保持させ、
登録対象患者の診察券から患者ＩＤを取得しその患者ＩＤに対応してユニークＩＤを生成した登録端末が表示する二次元コードをスキャンさせることで、その患者ＩＤ及びそのユニークＩＤを取得させ、
前記取得された患者ＩＤに対応する前記登録対象患者の名称の入力画面を表示させ、
前記入力画面に対して入力された前記登録対象患者の名称、前記取得された患者ＩＤ及びユニークＩＤを含む患者情報を前記患者情報テーブルに追加し、
前記取得された患者ＩＤを含まずかつ前記取得されたユニークＩＤ及び前記携帯端末自身の端末トークンを含む登録要求を前記支援サーバへ送信させ、
テスト呼出操作が検出されると、前記取得された患者ＩＤを含まずかつ前記取得されたユニークＩＤを含むテスト呼出要求を前記支援サーバへ送信させる、
患者向けコンピュータプログラム。
【請求項6】
サーバ装置及び携帯端末により実行される、患者が対象医療機関で受診するための受付及び呼び出しを支援するサービス支援方法であって、前記サーバ装置は、患者を識別し得るユニークＩＤとその患者の携帯端末の端末トークンとを関連付けて格納する端末情報テーブルと、各患者に関してユニークＩＤと受付情報と呼出確認履歴とをそれぞれ格納する患者管理テーブルとを有しており、
前記サーバ装置又は前記携帯端末が、
前記携帯端末の位置情報を取得し、
前記位置情報が所定条件を満たすか否かを判定し、
前記携帯端末が、
前記判定の結果に応じて受付操作可能状態又は受付操作不可能状態に切り替わり、
前記サーバ装置が、
電子カルテシステムの端末に対する受付済み患者を指定した呼び出し操作に応じて、その受付済み患者のユニークＩＤを含む呼び出し指示を取得し、
前記取得された呼び出し指示に含まれるユニークＩＤと関連付けられて前記端末情報テーブルに格納されている端末トークンを指定して、そのユニークＩＤを含む呼び出し情報のプッシュ通知を行い、
前記携帯端末が、
前記サーバ装置からの前記呼び出し情報のプッシュ通知を受けて、受付済み患者の名称、受付情報及び通知メッセージを含む呼び出し情報を確認操作可能に表示し、
前記呼び出し情報の表示に対するユーザの確認操作が検出されると、呼び出し情報の確認操作が行われたことを示しかつ前記受付済み患者のユニークＩＤを含む確認情報を前記サーバ装置へ送信し、
前記サーバ装置が、
前記確認情報を受信し、
前記呼び出し情報のプッシュ通知及び前記確認情報の受信に応じて、前記受付済み患者のユニークＩＤと関連付けられて前記患者管理テーブルに格納されている呼出確認履歴に、呼び出しの履歴と確認の履歴とを追加し、前記受付済み患者のユニークＩＤを含む確認情報を前記電子カルテシステムへ送信する、
ことを含むサービス支援方法。
【請求項7】
前記携帯端末が、
登録対象患者の診察券から患者ＩＤを取得しその患者ＩＤに対応してユニークＩＤを生成した登録端末が表示する二次元コードをスキャンすることで、その患者ＩＤ及びそのユニークＩＤを取得し、
前記取得された患者ＩＤに対応する前記登録対象患者の名称の入力画面を表示し、
前記入力画面に対して入力された前記登録対象患者の名称、前記取得された患者ＩＤ及びユニークＩＤを含む患者情報を患者情報テーブルに追加し、
前記取得された患者ＩＤを含まずかつ前記取得されたユニークＩＤ及び前記携帯端末自身の端末トークンを含む登録要求を前記サーバ装置へ送信し、
前記サーバ装置が、
前記携帯端末から、前記登録対象患者の患者ＩＤを含まず、前記登録対象患者のユニークＩＤと前記携帯端末自身の端末トークンを含む前記登録要求を受信し、
前記受信された登録要求に含まれるユニークＩＤ及び端末トークンを関連付けて前記端末情報テーブルに追加格納し、
前記受信された登録要求に含まれるユニークＩＤを含む患者情報を前記患者管理テーブルに追加格納し、
前記携帯端末が、
テスト呼出操作が検出されると、前記患者ＩＤを含まずかつ前記ユニークＩＤを含むテスト呼出要求を前記サーバ装置へ送信し、
前記サーバ装置が、
前記携帯端末から前記ユニークＩＤを含むテスト呼出要求を受信し、
前記受信されたテスト呼出要求に含まれるユニークＩＤに基づいて、そのユニークＩＤと関連付けられて前記端末情報テーブルに格納されている端末トークンを指定してテスト呼出情報のプッシュ通知を行う、
ことを含む請求項６に記載のサービス支援方法。
【請求項8】
前記携帯端末は、複数の患者の各々に関するユニークＩＤと患者名称とをそれぞれ関連付けて保持しており、
前記携帯端末が、
ユーザの受付操作を可能とする一つの受付操作部を表示し、
前記複数の患者の中から受付の対象となる患者を選択可能とする選択表示を出力し、
前記一つの受付操作部に対する受付操作が検出された場合に、前記選択表示で選択された患者のユニークＩＤを含む受付申請情報を前記サーバ装置へ送信し、
前記サーバ装置が、
前記受付申請情報に対応する受付回答情報を前記携帯端末に送信し、
前記携帯端末が、
前記受付回答情報を前記サーバ装置から受信し、
前記受信された受付回答情報に基づいて、前記複数の患者の各々について受付済み状態か否かを管理し、
前記受信された受付回答情報が受付エラーを示す場合には、エラー内容を示す情報を表示し、前記受信された受付回答情報が受付完了を示す場合には、受付完了を示す情報を表示し、
ユニークＩＤが保持されている前記複数の患者のすべてが受付済み状態となったことを契機に、前記受付操作可能状態から前記受付操作不可能状態に遷移すると共に、前記一つの受付操作部の表示態様を変更する、
ことを更に含む請求項６又は７に記載のサービス支援方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、患者が医療機関で受診するための受付及び呼び出しを支援する技術に関する。
【背景技術】
【0002】
消費者ニーズが「モノ」から「コト」へ変化する昨今、サービス提供者にとって、提供するサービス自体の品質自体もさることながら、受付や呼び出しといったサービスを提供するまでの仕組み作りの重要性も増している。例えば、下記特許文献１から４には、サービス利用者の呼び出しに関する各種手法が提案されている。
【0003】
下記特許文献１には、ユーザの現在地からサービスの提供場所まで移動するのに要する移動時間及びユーザの順番が回ってくる予定時刻に基づいて通知時刻を算出し、その通知時刻になると順番が近づいた旨をユーザのモバイル端末に通知する順番通知システムが開示されている。
下記特許文献２には、サービス情報と利用者情報との統計処理により得られる統計データと、順番待ち情報に関する利用者からの要求と、利用者の位置からサービス提供元までの移動時間とをもとに順番待ち情報配信条件を設定する装置が開示されている。
下記特許文献３には、顧客の現在位置からサービスの提供場所までの所要時間と顧客に対するサービスの開始時刻とに基づいて、顧客にサービスの提供場所への移動を促す通知情報を表示すべき通知時刻を算出し、その通知時刻で当該通知情報を表示する端末装置が開示されている。
下記特許文献４には、モバイル端末と通信する中継装置の位置を患者の位置情報として取得し、患者の位置と診察室の位置との間の距離に応じてモバイル端末に呼出情報を通知する呼出タイミングを算出し、診察順番と呼出タイミング又はモバイル端末から設定される指定タイミングとの比較結果に応じてモバイル端末に呼出情報を通知する外来患者呼出通知システムが開示されている。
下記特許文献２には、サービス情報と利用者情報との統計処理により得られる統計データと、順番待ち情報に関する利用者からの要求と、利用者の位置からサービス提供元までの移動時間とをもとに順番待ち情報配信条件を設定する装置が開示されている。
下記特許文献３には、顧客の現在位置からサービスの提供場所までの所要時間と顧客に対するサービスの開始時刻とに基づいて、顧客にサービスの提供場所への移動を促す通知情報を表示すべき通知時刻を算出し、その通知時刻で当該通知情報を表示する端末装置が開示されている。
下記特許文献４には、モバイル端末と通信する中継装置の位置を患者の位置情報として取得し、患者の位置と診察室の位置との間の距離に応じてモバイル端末に呼出情報を通知する呼出タイミングを算出し、診察順番と呼出タイミング又はモバイル端末から設定される指定タイミングとの比較結果に応じてモバイル端末に呼出情報を通知する外来患者呼出通知システムが開示されている。
【先行技術文献】
【特許文献】
【0004】
【文献】特開２００３－１４３６４８号公報
【文献】特開平１１－３０８３４４号公報
【文献】特開２０１０－２８６９５８号公報
【文献】特開２０１５－４９６２０号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、上述の提案手法では、対象サービスを受けるための受付に関する仕組みについてはほとんど言及されていない。サービス利用者にとって受付のために一度窓口に行くのは手間である。
本発明は、このような事情に鑑みてなされたものであり、患者にストレスを感じさせないよう医療機関で受診するための受付又は呼び出しを支援する技術を提供する。
本発明は、このような事情に鑑みてなされたものであり、患者にストレスを感じさせないよう医療機関で受診するための受付又は呼び出しを支援する技術を提供する。
【課題を解決するための手段】
【0006】
本発明の一側面に係る支援サーバは、患者が対象医療機関で受診するための受付及び呼び出しを支援する。当該一側面に係る支援サーバは、患者を識別し得るユニークＩＤとその患者の携帯端末の端末トークンとを関連付けて格納する端末情報テーブルと、各患者に関してユニークＩＤと受付情報と呼出確認履歴とをそれぞれ格納する患者管理テーブルと、前記患者の携帯端末の位置情報を取得する位置取得手段と、その位置情報が所定条件を満たすか否かを判定し、この判定の結果に応じて当該患者の携帯端末が受付操作可能状態又は受付操作不可能状態に切り替わるよう制御する端末制御手段と、電子カルテシステムの端末に対する受付済み患者を指定した呼び出し操作に応じて、その受付済み患者のユニークＩＤを含む呼び出し指示を取得する指示取得手段と、前記取得された呼び出し指示に含まれるユニークＩＤと関連付けられて前記端末情報テーブルに格納されている端末トークンを指定して、そのユニークＩＤを含む呼び出し情報のプッシュ通知を行う呼出送信手段と、前記呼び出し情報のプッシュ通知を受けた前記受付済み患者の携帯端末において表示される、患者名称、受付情報及び通知メッセージを含む呼び出し情報表示に対するユーザの確認操作に伴って、その携帯端末から、呼び出し情報の確認操作が行われたことを示しかつ前記受付済み患者のユニークＩＤを含む確認情報を受信する確認受信手段と、前記呼び出し情報のプッシュ通知及び前記確認情報の受信に応じて、前記受付済み患者のユニークＩＤと関連付けられて前記患者管理テーブルに格納されている呼出確認履歴に、呼び出しの履歴と確認の履歴とを追加する保持手段と、前記受付済み患者の携帯端末からの前記確認情報の受信に伴い、前記受付済み患者のユニークＩＤを含む確認情報を前記電子カルテシステムへ送信する手段と、を備える。
また、本発明の他の側面に係る患者向けコンピュータプログラムは、上述の支援サーバと通信可能な携帯端末で実行可能であり、その携帯端末に、当該支援サーバから送られる情報に基づいて、受付操作可能状態又は受付操作不可能状態に切り替えさせ、受付操作が検出された場合に、受付対象となる患者のユニークＩＤを含む受付申請情報を当該支援サーバへ送信させ、当該支援サーバから受付申請情報に対応する受付回答情報を受信させ、その受信された受付回答情報が受付エラーを示す場合には、エラー内容を示す情報を表示させ、前記受信された受付回答情報が受付完了を示す場合には、受付完了を示す情報を表示させ、前記支援サーバからの前記呼び出し情報のプッシュ通知を受けて、受付済み患者の名称、受付情報及び通知メッセージを含む呼び出し情報を確認操作可能に表示させ、前記呼び出し情報の表示に対するユーザの確認操作が検出されると、呼び出し情報の確認操作が行われたことを示しかつ前記受付済み患者のユニークＩＤを含む確認情報を前記支援サーバへ送信させる。
また、本発明の他の側面に係るサービス支援方法は、サーバ装置及び携帯端末により実行され、患者が対象医療機関で受診するための受付及び呼び出しを支援する。このサービス支援方法では、前記サーバ装置は、患者を識別し得るユニークＩＤとその患者の携帯端末の端末トークンとを関連付けて格納する端末情報テーブルと、各患者に関してユニークＩＤと受付情報と呼出確認履歴とをそれぞれ格納する患者管理テーブルとを有しており、サーバ装置又は携帯端末が、携帯端末の位置情報を取得し、その位置情報が所定条件を満たすか否かを判定し、当該携帯端末が、その判定の結果に応じて受付操作可能状態又は受付操作不可能状態に切り替わり、前記サーバ装置が、電子カルテシステムの端末に対する受付済み患者を指定した呼び出し操作に応じて、その受付済み患者のユニークＩＤを含む呼び出し指示を取得し、前記取得された呼び出し指示に含まれるユニークＩＤと関連付けられて前記端末情報テーブルに格納されている端末トークンを指定して、そのユニークＩＤを含む呼び出し情報のプッシュ通知を行い、前記携帯端末が、前記サーバ装置からの前記呼び出し情報のプッシュ通知を受けて、受付済み患者の名称、受付情報及び通知メッセージを含む呼び出し情報を確認操作可能に表示し、前記呼び出し情報の表示に対するユーザの確認操作が検出されると、呼び出し情報の確認操作が行われたことを示しかつ前記受付済み患者のユニークＩＤを含む確認情報を前記サーバ装置へ送信し、前記サーバ装置が、前記確認情報を受信し、前記呼び出し情報のプッシュ通知及び前記確認情報の受信に応じて、前記受付済み患者のユニークＩＤと関連付けられて前記患者管理テーブルに格納されている呼出確認履歴に、呼び出しの履歴と確認の履歴とを追加し、前記受付済み患者のユニークＩＤを含む確認情報を前記電子カルテシステムへ送信することを含む。
また、本発明の他の側面に係る患者向けコンピュータプログラムは、上述の支援サーバと通信可能な携帯端末で実行可能であり、その携帯端末に、当該支援サーバから送られる情報に基づいて、受付操作可能状態又は受付操作不可能状態に切り替えさせ、受付操作が検出された場合に、受付対象となる患者のユニークＩＤを含む受付申請情報を当該支援サーバへ送信させ、当該支援サーバから受付申請情報に対応する受付回答情報を受信させ、その受信された受付回答情報が受付エラーを示す場合には、エラー内容を示す情報を表示させ、前記受信された受付回答情報が受付完了を示す場合には、受付完了を示す情報を表示させ、前記支援サーバからの前記呼び出し情報のプッシュ通知を受けて、受付済み患者の名称、受付情報及び通知メッセージを含む呼び出し情報を確認操作可能に表示させ、前記呼び出し情報の表示に対するユーザの確認操作が検出されると、呼び出し情報の確認操作が行われたことを示しかつ前記受付済み患者のユニークＩＤを含む確認情報を前記支援サーバへ送信させる。
また、本発明の他の側面に係るサービス支援方法は、サーバ装置及び携帯端末により実行され、患者が対象医療機関で受診するための受付及び呼び出しを支援する。このサービス支援方法では、前記サーバ装置は、患者を識別し得るユニークＩＤとその患者の携帯端末の端末トークンとを関連付けて格納する端末情報テーブルと、各患者に関してユニークＩＤと受付情報と呼出確認履歴とをそれぞれ格納する患者管理テーブルとを有しており、サーバ装置又は携帯端末が、携帯端末の位置情報を取得し、その位置情報が所定条件を満たすか否かを判定し、当該携帯端末が、その判定の結果に応じて受付操作可能状態又は受付操作不可能状態に切り替わり、前記サーバ装置が、電子カルテシステムの端末に対する受付済み患者を指定した呼び出し操作に応じて、その受付済み患者のユニークＩＤを含む呼び出し指示を取得し、前記取得された呼び出し指示に含まれるユニークＩＤと関連付けられて前記端末情報テーブルに格納されている端末トークンを指定して、そのユニークＩＤを含む呼び出し情報のプッシュ通知を行い、前記携帯端末が、前記サーバ装置からの前記呼び出し情報のプッシュ通知を受けて、受付済み患者の名称、受付情報及び通知メッセージを含む呼び出し情報を確認操作可能に表示し、前記呼び出し情報の表示に対するユーザの確認操作が検出されると、呼び出し情報の確認操作が行われたことを示しかつ前記受付済み患者のユニークＩＤを含む確認情報を前記サーバ装置へ送信し、前記サーバ装置が、前記確認情報を受信し、前記呼び出し情報のプッシュ通知及び前記確認情報の受信に応じて、前記受付済み患者のユニークＩＤと関連付けられて前記患者管理テーブルに格納されている呼出確認履歴に、呼び出しの履歴と確認の履歴とを追加し、前記受付済み患者のユニークＩＤを含む確認情報を前記電子カルテシステムへ送信することを含む。
【発明の効果】
【0008】
本発明によれば、患者にストレスを感じさせないよう医療機関で受診するための受付又は呼び出しを支援する技術を提供することができる。
【図面の簡単な説明】
【0009】
【図1】本実施形態に係るサービス支援システムのシステム構成を示す模式図である。
【図2】サービス支援サーバ及び携帯端末のハードウェア構成例を示す模式図である。
【図3】サービス支援サーバ及び携帯端末のソフトウェア構成を概念的に示すブロック図である。
【図4】図４は、端末情報格納部に格納される情報の例を示す図であり、図４（ａ）は、携帯端末に関する端末情報を格納する端末情報テーブルを例示しており、図４（ｂ）は、患者の呼出及び受け付けに関する管理情報を格納する患者管理テーブルを例示している。
【図5】患者情報格納部に格納される患者情報テーブルを例示する図である。
【図6】携帯端末に表示されるサービス利用者向けアプリのメイン画面の例を示す図である。
【図7】患者登録時の携帯端末の動作例を示すフローチャートである
【図8】患者が受付を行う時のサービス支援サーバ及び携帯端末の動作例を示すフローチャートである。
【図9】患者呼び出し時のサービス支援サーバ及び携帯端末の動作例を示すフローチャートである。
【発明を実施するための形態】
【0010】
以下、本発明の実施形態について図面を用いて説明する。以下に挙げる実施形態は例示であり、本発明は以下の実施形態の構成に限定されない。
【0011】
図１は、本実施形態に係るサービス支援システムのシステム構成を示す模式図である。
本実施形態に係るサービス支援システムは、サービス支援サーバ（以降、支援サーバと略称される）１、電子カルテシステム５等から構成されており、医療機関による医療サービスの提供を支援する。具体的には、サービス支援システムは、個々の患者が持つ携帯端末８とそれぞれ通信を行って、患者が医療サービスを受けるための受付及び呼び出しを支援する。
本実施形態に係るサービス支援システムは、サービス支援サーバ（以降、支援サーバと略称される）１、電子カルテシステム５等から構成されており、医療機関による医療サービスの提供を支援する。具体的には、サービス支援システムは、個々の患者が持つ携帯端末８とそれぞれ通信を行って、患者が医療サービスを受けるための受付及び呼び出しを支援する。
【0012】
電子カルテシステム５は、電子カルテに関する一般的な処理を行う一以上のコンピュータからなるシステムである。
本実施形態では、電子カルテシステム５は、後述するように、支援サーバ１からの受付申請に応じて受付処理を行い、その受付処理の結果として受付回答を支援サーバ１へ送り返す。また、電子カルテシステム５は、支援サーバ１からの受付申請や受付窓口における受付などに応じて、患者ごとの受付状態を管理しており、受付済みの患者を本システムを介して呼び出すための呼び出しインタフェースを備えている。この呼び出しインタフェースでは、医師等による呼び出し操作を受け付ける画面が医療機関側端末に表示され、呼び出し操作に応じて支援サーバ１へ対象患者の呼び出し指示が送られる。また、呼び出しインタフェースは、受付済みの患者ごとの位置情報や、呼び出しに対する確認情報（既読又は未読）を表示させることができる。
但し、電子カルテシステム５は、支援サーバ１へ患者の呼び出し指示を送信することができると共に、支援サーバ１から送られる受付申請に応じて受付処理を行い、その受付処理の結果として受付回答を支援サーバ１へ送り返すことができればよく、その他の具体的な機能や処理は何ら制限されない。
本実施形態では、電子カルテシステム５は、後述するように、支援サーバ１からの受付申請に応じて受付処理を行い、その受付処理の結果として受付回答を支援サーバ１へ送り返す。また、電子カルテシステム５は、支援サーバ１からの受付申請や受付窓口における受付などに応じて、患者ごとの受付状態を管理しており、受付済みの患者を本システムを介して呼び出すための呼び出しインタフェースを備えている。この呼び出しインタフェースでは、医師等による呼び出し操作を受け付ける画面が医療機関側端末に表示され、呼び出し操作に応じて支援サーバ１へ対象患者の呼び出し指示が送られる。また、呼び出しインタフェースは、受付済みの患者ごとの位置情報や、呼び出しに対する確認情報（既読又は未読）を表示させることができる。
但し、電子カルテシステム５は、支援サーバ１へ患者の呼び出し指示を送信することができると共に、支援サーバ１から送られる受付申請に応じて受付処理を行い、その受付処理の結果として受付回答を支援サーバ１へ送り返すことができればよく、その他の具体的な機能や処理は何ら制限されない。
【0013】
支援サーバ１は、各携帯端末８と電子カルテシステム５との間に介在し、各携帯端末８及び電子カルテシステム５と相互に通信を行いながら、サービス支援のための各種処理を実行する。
携帯端末８は、個々の患者が持つ携帯型のコンピュータであり、例えば、スマートフォン、タブレット端末、携帯ノートＰＣ（Personal Computer）等である。携帯端末８は、本実施形態に係るサービス支援システムによるサービス支援を受けるためのアプリケーションが動作することで、支援サーバ１と相互に通信を行いながら、当該サービス支援システムにおける患者側即ちサービス利用者側のユーザインタフェースを実現する。
携帯端末８は、個々の患者が持つ携帯型のコンピュータであり、例えば、スマートフォン、タブレット端末、携帯ノートＰＣ（Personal Computer）等である。携帯端末８は、本実施形態に係るサービス支援システムによるサービス支援を受けるためのアプリケーションが動作することで、支援サーバ１と相互に通信を行いながら、当該サービス支援システムにおける患者側即ちサービス利用者側のユーザインタフェースを実現する。
【0014】
［ハードウェア構成］
図２は、サービス支援サーバ１及び携帯端末８のハードウェア構成例を示す模式図である。
支援サーバ１は、いわゆるコンピュータであり、図２に示されるように、バスで相互に接続される、ＣＰＵ（Central Processing Unit）１１、メモリ１２、入出力インタフェース（Ｉ／Ｆ）１３、通信ユニット１４等を有する。
ＣＰＵ１１は、一般的な一以上のＣＰＵ又はＭＰＵ（Micro Processing Unit）であってもよいし、それに替え又はそれと共に、特定用途向け集積回路（ＡＳＩＣ）、ＤＳＰ（Digital Signal Processor）、ＧＰＵ（Graphics Processing Unit）、ＦＰＧＡ（Field Programmable Gate Array）等であってもよい。
メモリ１２は、ＲＡＭ（Random Access Memory）及びＲＯＭ（Read Only Memory）であり、補助記憶装置（ハードディスク等）を含む。
図２は、サービス支援サーバ１及び携帯端末８のハードウェア構成例を示す模式図である。
支援サーバ１は、いわゆるコンピュータであり、図２に示されるように、バスで相互に接続される、ＣＰＵ（Central Processing Unit）１１、メモリ１２、入出力インタフェース（Ｉ／Ｆ）１３、通信ユニット１４等を有する。
ＣＰＵ１１は、一般的な一以上のＣＰＵ又はＭＰＵ（Micro Processing Unit）であってもよいし、それに替え又はそれと共に、特定用途向け集積回路（ＡＳＩＣ）、ＤＳＰ（Digital Signal Processor）、ＧＰＵ（Graphics Processing Unit）、ＦＰＧＡ（Field Programmable Gate Array）等であってもよい。
メモリ１２は、ＲＡＭ（Random Access Memory）及びＲＯＭ（Read Only Memory）であり、補助記憶装置（ハードディスク等）を含む。
【0015】
入出力Ｉ／Ｆユニット１３は、ＣＰＵ１１で処理すべき又は処理された信号の入力又は出力を制御する機器であり、表示装置１５、入力装置１６、マイクロフォン等のユーザインタフェース装置等に接続され得る。また、入出力Ｉ／Ｆユニット１３は、可搬型記録媒体等にも接続され得る。
表示装置１５は、ＬＣＤ（Liquid Crystal Display）やＣＲＴ（Cathode Ray Tube）ディスプレイのような、ＣＰＵ１１等により処理された描画データに対応する画面を表示する装置である。入力装置１６は、キーボード、マウス等のようなユーザ操作の入力を受け付ける装置である。表示装置１５及び入力装置１６は一体化され、タッチパネルとして実現されてもよい。また、表示装置１５及び入力装置１６の両方又は一方はなくてもよい。
通信ユニット１４は、電子カルテシステム５及び携帯端末８と通信を行う。支援サーバ１と携帯端末８との間の通信は、インターネットを含む通信網を介して行われ、その通信網に接続される外部の中継サーバを介して行われてもよいし、直接行われてもよい。
表示装置１５は、ＬＣＤ（Liquid Crystal Display）やＣＲＴ（Cathode Ray Tube）ディスプレイのような、ＣＰＵ１１等により処理された描画データに対応する画面を表示する装置である。入力装置１６は、キーボード、マウス等のようなユーザ操作の入力を受け付ける装置である。表示装置１５及び入力装置１６は一体化され、タッチパネルとして実現されてもよい。また、表示装置１５及び入力装置１６の両方又は一方はなくてもよい。
通信ユニット１４は、電子カルテシステム５及び携帯端末８と通信を行う。支援サーバ１と携帯端末８との間の通信は、インターネットを含む通信網を介して行われ、その通信網に接続される外部の中継サーバを介して行われてもよいし、直接行われてもよい。
【0016】
携帯端末８は、上述した通り、スマートフォン、タブレット端末、携帯ノートＰＣ等のような携帯型のコンピュータであり、ＣＰＵ８１、メモリ８２、表示ユニット８３、タッチセンサ８４、通信ユニット８５、撮像ユニット８６、マイクロフォンユニット８７、スピーカユニット８８等を有する。
ＣＰＵ８１及びメモリ８２上述のＣＰＵ１１及びメモリ１２で述べたとおりである。
表示ユニット８３は、表示装置１５と同様であり、タッチセンサ８４と共にタッチパネルを構成する。タッチセンサ８４は、外部からの接触を感知することによりユーザからの操作入力を受け付ける。タッチセンサ５は、非接触状態であっても外部からの近接状態を検知することができるセンサであってもよい。但し、携帯端末８は、タッチセンサ５と共に、又は、タッチセンサ５の代わりに、マウスやキーボード等の入力装置と接続される入出力インタフェース（図示せず）を持つようにしてもよい。
ＣＰＵ８１及びメモリ８２上述のＣＰＵ１１及びメモリ１２で述べたとおりである。
表示ユニット８３は、表示装置１５と同様であり、タッチセンサ８４と共にタッチパネルを構成する。タッチセンサ８４は、外部からの接触を感知することによりユーザからの操作入力を受け付ける。タッチセンサ５は、非接触状態であっても外部からの近接状態を検知することができるセンサであってもよい。但し、携帯端末８は、タッチセンサ５と共に、又は、タッチセンサ５の代わりに、マウスやキーボード等の入力装置と接続される入出力インタフェース（図示せず）を持つようにしてもよい。
【0017】
マイクロフォンユニット８７は、集音装置である。
スピーカユニット８８は、音声出力装置である。
撮像ユニット８６は、撮像画像を取得する。
通信ユニット８５は、無線通信又は有線通信を行い、通信網を介して支援サーバ１と通信を行う。また、通信ユニット８５は、通信網に接続される外部のサーバを経由して支援サーバ１と情報のよりとりをしてもよい。通信ユニット８５により実現される通信方式は、移動体通信方式、Ｗｉ－Ｆｉ方式、Bluetooth方式など様々であり、何ら限定されない。なお、本実施形態では、通信ユニット８には、ＧＰＳ（Global Positioning System）受信機を含んでいる。
スピーカユニット８８は、音声出力装置である。
撮像ユニット８６は、撮像画像を取得する。
通信ユニット８５は、無線通信又は有線通信を行い、通信網を介して支援サーバ１と通信を行う。また、通信ユニット８５は、通信網に接続される外部のサーバを経由して支援サーバ１と情報のよりとりをしてもよい。通信ユニット８５により実現される通信方式は、移動体通信方式、Ｗｉ－Ｆｉ方式、Bluetooth方式など様々であり、何ら限定されない。なお、本実施形態では、通信ユニット８には、ＧＰＳ（Global Positioning System）受信機を含んでいる。
【0018】
支援サーバ１及び携帯端末８のハードウェア構成は、図２に示される構成に限定されない。各ハードウェア要素の数は、図２に示される例に限定されないし、支援サーバ１及び携帯端末８は、図２に図示しないハードウェア要素を含んでもよい。例えば、携帯端末８は、図２に示されていない他種のユーザ操作を検出し得る振動センサ、加速度センサ、地磁気センサを有していてもよい。
【0019】
［ソフトウェア構成］
次に、支援サーバ１及び携帯端末８のソフトウェア構成について、図３を用いて説明する。
図３は、支援サーバ１及び携帯端末８のソフトウェア構成を概念的に示すブロック図である。
支援サーバ１は、ＣＰＵ１１によりメモリ１２に格納されるコンピュータプログラムが実行されることにより、図３に示されるようなソフトウェア構成を実現する。具体的には、支援サーバ１は、ソフトウェア要素として、端末情報格納部２０、端末通信モジュール２１、中継処理モジュール２２、端末制御モジュール２３等を有している。
携帯端末８は、ＣＰＵ８１によりメモリ８２に格納されているコンピュータプログラム（サービス利用者向けアプリと表記される場合もある）が実行されることにより、図３に示されるようなソフトウェア構成を実現する。具体的には、携帯端末８は、患者情報格納部９０、登録処理モジュール９１、受付処理モジュール９２、呼出処理モジュール９３、表示処理モジュール９４等を有している。
但し、図３に示される各ソフトウェア要素は、説明の便宜のために概念的にそれぞれ分けて示したものであるため、支援サーバ１又は携帯端末８で実現される各ソフトウェア要素は、図３に示されるような各要素に明確に区分けされていなくてもよい。
次に、支援サーバ１及び携帯端末８のソフトウェア構成について、図３を用いて説明する。
図３は、支援サーバ１及び携帯端末８のソフトウェア構成を概念的に示すブロック図である。
支援サーバ１は、ＣＰＵ１１によりメモリ１２に格納されるコンピュータプログラムが実行されることにより、図３に示されるようなソフトウェア構成を実現する。具体的には、支援サーバ１は、ソフトウェア要素として、端末情報格納部２０、端末通信モジュール２１、中継処理モジュール２２、端末制御モジュール２３等を有している。
携帯端末８は、ＣＰＵ８１によりメモリ８２に格納されているコンピュータプログラム（サービス利用者向けアプリと表記される場合もある）が実行されることにより、図３に示されるようなソフトウェア構成を実現する。具体的には、携帯端末８は、患者情報格納部９０、登録処理モジュール９１、受付処理モジュール９２、呼出処理モジュール９３、表示処理モジュール９４等を有している。
但し、図３に示される各ソフトウェア要素は、説明の便宜のために概念的にそれぞれ分けて示したものであるため、支援サーバ１又は携帯端末８で実現される各ソフトウェア要素は、図３に示されるような各要素に明確に区分けされていなくてもよい。
【0020】
支援サーバ１の端末情報格納部２０は、携帯端末８に関する情報及びその携帯端末８に登録されている患者の受付及び呼び出しに関する情報を格納する。
図４は、端末情報格納部２０に格納される情報の例を示す図であり、図４（ａ）は、携帯端末８に関する端末情報を格納する端末情報テーブルを例示しており、図４（ｂ）は、患者の呼出及び受け付けに関する管理情報を格納する患者管理テーブルを例示している。
図４は、端末情報格納部２０に格納される情報の例を示す図であり、図４（ａ）は、携帯端末８に関する端末情報を格納する端末情報テーブルを例示しており、図４（ｂ）は、患者の呼出及び受け付けに関する管理情報を格納する患者管理テーブルを例示している。
【0021】
端末情報テーブルは、各患者に関して、その患者を識別し得る識別子（ユニークＩＤと表記される）、その患者の情報が登録された携帯端末８の端末トークン、及びその携帯端末８の位置情報をそれぞれ関連付けて格納する。
各患者のユニークＩＤは、携帯端末８における患者登録時にそれぞれ生成され、端末情報テーブルに格納される。ここでユニークＩＤは、個々のサービス利用者を識別し得る利用者識別子と呼ぶこともできる。
端末トークンは、支援サーバ１から各携帯端末８にプッシュ通知を行う際に利用される情報であって、携帯端末８ごと或いは携帯端末８のアプリケーションごとに独自に付与される情報である。端末トークンは、支援サーバ１により付与されてもよいし、支援サーバ１と携帯端末８との間に介在する外部サーバにより付与されてもよい。後者の場合には、例えば、外部サーバとなるＦＣＭ（Firebase Cloud Messaging）接続サーバにより端末トークン（登録トークン）が発行され、携帯端末８へ提供される。但し、端末トークンは、各携帯端末８へのプッシュ通知を実現することができればよく、その付与方法や具体的内容は制限されない。
位置情報は、各携帯端末８の位置を示す情報である。位置情報は、携帯端末８から支援サーバ１へ周期的に送られ、支援サーバ１により端末情報テーブルに反映される。
各患者のユニークＩＤは、携帯端末８における患者登録時にそれぞれ生成され、端末情報テーブルに格納される。ここでユニークＩＤは、個々のサービス利用者を識別し得る利用者識別子と呼ぶこともできる。
端末トークンは、支援サーバ１から各携帯端末８にプッシュ通知を行う際に利用される情報であって、携帯端末８ごと或いは携帯端末８のアプリケーションごとに独自に付与される情報である。端末トークンは、支援サーバ１により付与されてもよいし、支援サーバ１と携帯端末８との間に介在する外部サーバにより付与されてもよい。後者の場合には、例えば、外部サーバとなるＦＣＭ（Firebase Cloud Messaging）接続サーバにより端末トークン（登録トークン）が発行され、携帯端末８へ提供される。但し、端末トークンは、各携帯端末８へのプッシュ通知を実現することができればよく、その付与方法や具体的内容は制限されない。
位置情報は、各携帯端末８の位置を示す情報である。位置情報は、携帯端末８から支援サーバ１へ周期的に送られ、支援サーバ１により端末情報テーブルに反映される。
【0022】
ここで詳細は後述するが、本実施形態では、携帯端末８には複数人の患者を登録することができる。これにより、母親は、自身の携帯端末８に自身を患者として登録することができるだけでなく、子供を患者として登録することもできるし、自身が付き添う老人（両親等）を患者として登録することもできる。
結果、上述の端末情報テーブルには、複数のユニークＩＤに対して一つの端末トークンが関連付けられて格納される場合がある。
結果、上述の端末情報テーブルには、複数のユニークＩＤに対して一つの端末トークンが関連付けられて格納される場合がある。
【0023】
患者管理テーブルは、各患者に関して、上記ユニークＩＤ、受付情報、受付状態、呼出・確認履歴をそれぞれ関連付けて格納する。
受付情報は、電子カルテシステム５から支援サーバ１へ送られる受付回答情報に基づいて支援サーバ１により患者管理テーブルに反映される情報である。受付情報は、電子カルテシステム５において受付処理により受付済みとなった場合には、受付番号、診療科名、予約時刻等のような情報を示し、受付エラーとなった場合には、エラー内容を示す。
受付状態は、各患者の受付状態を示し、受付済み、受付無し、受付エラー等の状態を示す。電子カルテシステム５から受信される受付回答情報が受付完了を示す場合には、受付状態が受付済みに設定され、その受付回答情報が受付エラーを示す場合には、受付状態が受付エラーに設定される。また、電子カルテシステム５から受診完了情報が受信された場合には、受付情報が初期化され、受付状態が初期状態（受付無し）に設定される。
呼出・確認履歴は、各患者に関する呼び出し状況と呼び出しに対する確認状況との組合せの履歴を示す。例えば、呼び出しごとに、呼び出し時刻とその呼び出しに対する確認操作の有無とが関連付けられて呼出・確認履歴として格納される。支援サーバ１から呼び出し情報のプッシュ通知が行われた際に、そのときの時刻を含む一履歴情報が追加され、その後、携帯端末８から確認情報が受信された場合に、その一履歴情報の確認状況に確認有が設定される。
受付情報は、電子カルテシステム５から支援サーバ１へ送られる受付回答情報に基づいて支援サーバ１により患者管理テーブルに反映される情報である。受付情報は、電子カルテシステム５において受付処理により受付済みとなった場合には、受付番号、診療科名、予約時刻等のような情報を示し、受付エラーとなった場合には、エラー内容を示す。
受付状態は、各患者の受付状態を示し、受付済み、受付無し、受付エラー等の状態を示す。電子カルテシステム５から受信される受付回答情報が受付完了を示す場合には、受付状態が受付済みに設定され、その受付回答情報が受付エラーを示す場合には、受付状態が受付エラーに設定される。また、電子カルテシステム５から受診完了情報が受信された場合には、受付情報が初期化され、受付状態が初期状態（受付無し）に設定される。
呼出・確認履歴は、各患者に関する呼び出し状況と呼び出しに対する確認状況との組合せの履歴を示す。例えば、呼び出しごとに、呼び出し時刻とその呼び出しに対する確認操作の有無とが関連付けられて呼出・確認履歴として格納される。支援サーバ１から呼び出し情報のプッシュ通知が行われた際に、そのときの時刻を含む一履歴情報が追加され、その後、携帯端末８から確認情報が受信された場合に、その一履歴情報の確認状況に確認有が設定される。
【0024】
携帯端末８の患者情報格納部９０は、携帯端末８に登録されている患者の情報及びその患者の受付に関する情報を格納する。
図５は、患者情報格納部９０に格納される情報の例として、患者情報テーブルを例示する。
患者情報テーブルは、携帯端末８に登録されている一以上の各患者に関して、ユニークID、患者ID、患者名称、受付情報、及び受付状態をそれぞれ関連付けて格納する。このような患者ごとの情報は、携帯端末８における患者登録時に生成され、患者情報テーブルに追加される。携帯端末８における患者登録の詳細については後述する。
図５は、患者情報格納部９０に格納される情報の例として、患者情報テーブルを例示する。
患者情報テーブルは、携帯端末８に登録されている一以上の各患者に関して、ユニークID、患者ID、患者名称、受付情報、及び受付状態をそれぞれ関連付けて格納する。このような患者ごとの情報は、携帯端末８における患者登録時に生成され、患者情報テーブルに追加される。携帯端末８における患者登録の詳細については後述する。
【0025】
ユニークＩＤは、上述したとおりであり、支援サーバ１の端末情報格納部２０に格納されるユニークIDと同様である。
患者IDは、電子カルテシステム５において各患者を識別し得る識別子である。本実施形態では、個々の患者の識別子として、電子カルテシステム５内で管理される患者IDと、その患者IDとは別に付与されるユニークIDとが設けられている。そして、患者IDは、電子カルテシステム５及び携帯端末８では保持されるが、支援サーバ１では保持されない。これにより、個人情報としての性質を持つ患者IDは、その患者個人が持つ携帯端末８又は医療機関側の電子カルテシステム５のみで利用されることになるため、個人情報の保護に繋がる。
患者名称は、携帯端末８の表示において各患者を識別するための名称であり、携帯端末８の操作により編集可能とされている。
受付情報は、支援サーバ１から携帯端末８へ送られる受付回答情報に基づいて携帯端末８により患者情報テーブルに反映される情報である。受付情報は、電子カルテシステム５において受付処理により受付済みとなった場合には、受付番号、診療科名、予約時刻等のような情報を示し、受付エラーとなった場合には、エラー内容を示す。
受付状態は、携帯端末８に登録されている各患者の受付状態を示し、受付済み、受付無し、受付エラー等の状態を示す。支援サーバ１から受信される受付回答情報が受付完了を示す場合には、受付状態が受付済みに設定され、その受付回答情報が受付エラーを示す場合には、受付状態が受付エラーに設定される。また、支援サーバ１から受診完了情報が受信された場合には、受付情報が初期化され、受付状態が初期状態（受付無し）に設定される。
患者IDは、電子カルテシステム５において各患者を識別し得る識別子である。本実施形態では、個々の患者の識別子として、電子カルテシステム５内で管理される患者IDと、その患者IDとは別に付与されるユニークIDとが設けられている。そして、患者IDは、電子カルテシステム５及び携帯端末８では保持されるが、支援サーバ１では保持されない。これにより、個人情報としての性質を持つ患者IDは、その患者個人が持つ携帯端末８又は医療機関側の電子カルテシステム５のみで利用されることになるため、個人情報の保護に繋がる。
患者名称は、携帯端末８の表示において各患者を識別するための名称であり、携帯端末８の操作により編集可能とされている。
受付情報は、支援サーバ１から携帯端末８へ送られる受付回答情報に基づいて携帯端末８により患者情報テーブルに反映される情報である。受付情報は、電子カルテシステム５において受付処理により受付済みとなった場合には、受付番号、診療科名、予約時刻等のような情報を示し、受付エラーとなった場合には、エラー内容を示す。
受付状態は、携帯端末８に登録されている各患者の受付状態を示し、受付済み、受付無し、受付エラー等の状態を示す。支援サーバ１から受信される受付回答情報が受付完了を示す場合には、受付状態が受付済みに設定され、その受付回答情報が受付エラーを示す場合には、受付状態が受付エラーに設定される。また、支援サーバ１から受診完了情報が受信された場合には、受付情報が初期化され、受付状態が初期状態（受付無し）に設定される。
【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】
１ サービス支援サーバ（支援サーバ）、５ 電子カルテシステム、８ 携帯端末、１１ ＣＰＵ、１２ メモリ、１３ 入出力Ｉ／Ｆ、１４ 通信ユニット、１５ 表示装置、１６ 入力装置、２０ 端末情報格納部、２１ 端末通信モジュール、２２ 中継処理モジュール、２３ 端末制御モジュール、８１ ＣＰＵ、８２ メモリ、８３ 表示ユニット、８４ タッチセンサ、８５ 通信ユニット、８６ 撮像ユニット、８７ マイクロフォンユニット、８８ スピーカユニット、９０ 患者情報格納部、９１ 登録処理モジュール、９２ 受付処理モジュール、９３ 呼出処理モジュール、９４ 表示処理モジュール
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】