JP7340702B2 - スマート診察システム及びその方法 - Google Patents

Description

本発明は、スマート診察システム及びその方法に関し、より詳細には、個人識別情報と個人症状情報とを区分して管理するスマート診察システム及びその方法に関する。

患者が病院に行き、待機する時間が長くなることがある。待ち時間が長くなる理由は、一つの病院に患者に対する診察時間が長くなるか、来院患者が多くなるためであろう。

待ち時間を減らすためには、患者数と担当医の診察時間を短縮する必要がある。患者数と担当医の診察時間を短縮させるためには、患者に繰り返して尋ねる情報を予め収集しておくことが役に立つだろう。具体的に、担当医又は病院は、患者が来院した理由が何か、具体的にどのような症状で来院したのかに関する情報を予め収集することで、診察時間を短縮させることができる。ここで、効率的な病院の運営、及び患者のアプローチの利便性のために、スマート診察システムを利用することができ、スマート診察システムの運営のために、患者にアプリケーションを介して病院に多様なサービスを提供することができる。具体的に、病院は、アプリケーションを介して患者に関する個人情報を要請することができる。しかし、アプリケーションを介して患者の個人情報を収集する場合、患者の個人情報がアプリケーションサーバを通じて漏洩する可能性が高くなる。患者は、個人情報をアプリケーションで記入することをためらうことがあり、病院側は、個人情報の漏洩に対する責任問題のため、個人情報（例えば、症状に関する情報）を記入してもらうことを避けようする問題が生じる。なお、処方に関する情報を患者に提供する場合でも、個人情報が漏洩する可能性があり、患者及び病院のどちらも処方情報を提供することをはばかる問題が生じかねない。

一方、来院する患者数が多くなる場合、予約システムを導入して患者の来院時間を分散させることができる。しかし、予約の確定後、予定時刻に来院しない患者が発生することもある。予定された予約時刻に来院しないノーショー（Ｎｏ－Ｓｈｏｗ）患者が多くなる場合、又は予約なしで来院する飛び込み患者がある場合、病院は受付又は受診の順番を決めることが難しくなってしまうおそれがある。よって、病院が予定された時間に患者が来院するかをしっかり判断することが、患者の待ち時間を減らすうえで大変役に立つ。予定された時間に患者がちゃんと来院してくるかを予約時間前に電話で直接聞くとなると、電話業務を行う担当者の業務負担が増え、人件費がかさむ原因になる。よって、スマート診察システムで予約機能を提供する場合、予約患者が実際に来院するかをしっかり判断することが、効率的な診察システムを管理するうえで役にたつことになる。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、個人識別情報と個人症状情報とを区分して別途の装置に伝送し、診察の順番を決めることが複雑になるという問題を解決するために、予約患者が実際に来院したか否かを判断するアプリケーション及びそのアプリケーションを含む端末装置を提供することにある。

上述の目的を達成するための本実施形態に係る端末装置に動作を実行させるコンピュータで読み取り可能な記録媒体に保存されたアプリケーションにおいて、前記動作は、症状情報を入力されるためのＵＩ画面を提供するステップと、前記ＵＩ画面を介してユーザの症状情報が入力されると、前記症状情報及び待機番号の要請を病院管理サーバに伝送するステップと、前記病院管理サーバから前記待機番号の要請に対応する待機番号を受信してよく、受信された待機番号を含むＵＩ画面を提供するステップと、前記ユーザの識別情報をアプリケーションサーバに伝送するステップと、前記アプリケーションサーバが前記ユーザの識別情報を前記病院管理サーバに伝送するように制御するステップとを含む。

ここで、前記病院管理サーバに伝送された前記症状情報を含む第１のＵＩ画面、及び前記ユーザの識別情報を含む第２のＵＩ画面が、前記病院管理サーバと通信するディスプレイ装置に提供されてよい。

なお、前記動作は、病院の予約のためのＵＩ画面を提供するステップと、前記ＵＩ画面を介して病院の予約のための情報が入力されると、前記ユーザの識別情報及び前記病院の予約のための情報を、前記アプリケーションサーバに伝送するステップと、前記アプリケーションサーバから病院の予約情報が受信されると、前記受信された病院の予約情報を含むＵＩ画面を提供するステップとを更に含んでよく、前記予約情報は、予約時間を含んでよい。

ここで、前記動作は、前記予約時間より臨界時間前の時点から、前記端末装置の位置情報を前記病院管理サーバに伝送するステップと、前記病院管理サーバから前記位置情報に対応する待機番号を受信すると、受信された待機番号を含むＵＩ画面を提供するステップとを更に含んでよい。

ここで、前記病院管理サーバは、前記位置情報が前記病院の位置から臨界距離内であれば、順位の高い待機番号を前記端末装置に提供してよい。

なお、前記動作は、前記受信された待機番号を前記アプリケーションサーバに伝送するステップと、前記アプリケーションサーバが前記待機番号を前記病院管理サーバに伝送するように制御するステップとを更に含んでよく、前記病院管理サーバに伝送された前記症状情報及び前記待機番号を含む第１のＵＩ画面、及び前記ユーザの識別情報及び前記待機番号を含む第２のＵＩ画面が、前記病院管理サーバと通信するディスプレイ装置に提供されてよい。

なお、前記動作は、前記病院管理サーバから処方情報を受信するステップと、前記受信された処方情報を含むＵＩ画面を提供するステップとを更に含んでよく、前記病院管理サーバは、前記待機番号に基づいて前記処方情報を伝送する端末装置を識別してよく、前記識別された端末装置に前記処方情報を伝送してよい。

一方、前記病院管理サーバは、第１の病院管理サーバ及び第２の病院管理サーバを含んでよく、前記症状情報及び前記待機番号の要請は、前記第１の病院管理サーバに伝送されてよく、前記ユーザの識別情報は前記第２の病院管理サーバに伝送されてよい。

なお、前記症状情報は、第１の通信モジュールを介して前記病院管理サーバに伝送されてよく、前記ユーザの識別情報は、第２の通信モジュールを介して前記病院管理サーバに伝送されてよい。

ここで、前記動作は、前記病院管理サーバから処方情報を受信するステップと、前記受信された処方情報を含むＵＩ画面を提供するステップとを含んでよく、前記処方情報は、前記第１の通信モジュールを介して前記病院管理サーバから受信されてよい。

一方、本発明の一実施形態に係る端末装置は、アプリケーションを保存するメモリと、ディスプレイと、通信インターフェースと、前記アプリケーションを実行して動作を行うプロセッサとを含み、前記動作は、症状情報を入力されるためのＵＩ画面を前記ディスプレイに表示するステップと、前記ＵＩ画面を介してユーザの症状情報が入力されると、前記症状情報及び待機番号の要請を病院管理サーバに伝送するステップと、前記病院管理サーバから前記待機番号の要請に対応する待機番号を受信してよく、受信された待機番号を含むＵＩ画面を前記ディスプレイに表示するステップと、前記ユーザの識別情報をアプリケーションサーバに伝送するステップと、前記アプリケーションサーバが前記ユーザの識別情報を前記病院管理サーバに伝送するように制御するステップとを含んでよい。

ここで、前記プロセッサは、前記病院管理サーバに伝送された前記症状情報を含む第１のＵＩ画面、及び前記ユーザの識別情報を含む第２のＵＩ画面を、前記病院管理サーバと通信するディスプレイ装置に提供してよい。

なお、前記プロセッサは、前記ＵＩ画面を介して病院の予約のための情報が入力されると、前記ユーザの識別情報及び前記病院の予約のための情報を、前記アプリケーションサーバに伝送してよく、前記アプリケーションサーバから病院の予約情報が受信されると、前記受信された病院の予約情報を含むＵＩ画面を前記ディスプレイに表示してよく、前記予約情報は、予約時間を含んでよい。

ここで、前記プロセッサは、前記予約時間より臨界時間前の時点から、前記端末装置の位置情報を前記病院管理サーバに伝送してよく、前記病院管理サーバから前記位置情報に対応する待機番号を受信すると、受信された待機番号を含むＵＩ画面を前記ディスプレイに表示してよい。

ここで、前記病院管理サーバは、前記位置情報が前記病院の位置から臨界距離内であれば、順位の高い待機番号を前記端末装置に提供してよい。

なお、前記プロセッサは、前記受信された待機番号を前記通信インターフェースを介して前記アプリケーションサーバに伝送してよく、前記アプリケーションサーバが前記待機番号を前記病院管理サーバに伝送するように制御してよく、前記病院管理サーバに伝送された前記症状情報及び前記待機番号を含む第１のＵＩ画面、及び前記ユーザの識別情報及び前記待機番号を含む第２のＵＩ画面が、前記病院管理サーバと通信するディスプレイ装置に提供されてよい。

なお、前記プロセッサは、前記病院管理サーバから処方情報を受信してよく、前記受信された処方情報を含むＵＩ画面を前記ディスプレイに表示してよく、前記病院管理サーバは、前記待機番号に基づいて前記処方情報を伝送する端末装置を識別してよく、前記識別された端末装置に前記処方情報を伝送してよい。

なお、前記病院管理サーバは、第１の病院管理サーバ及び第２の病院管理サーバを含んでよく、前記症状情報及び前記待機番号の要請は、前記第１の病院管理サーバに伝送されてよく、前記ユーザの識別情報は前記第２の病院管理サーバに伝送されてよい。

ここで、前記症状情報は、第１の通信モジュールを介して前記病院管理サーバに伝送されてよく、前記ユーザの識別情報は、第２の通信モジュールを介して前記病院管理サーバに伝送されてよい。

ここで、前記プロセッサは、前記病院管理サーバから処方情報を受信してよく、前記受信された処方情報を含むＵＩ画面を前記ディスプレイに表示してよく、前記処方情報は、前記第１の通信モジュールを介して前記病院管理サーバから受信されてよい。

本発明の一実施形態に係るユーザ端末装置を示すブロック図である。 図１のユーザ端末装置の具体的な構成を説明するためのブロック図である。 一実施形態に係る患者診察システムの構成を説明するための図である。 図３の実施形態を説明するためのフローチャートである。 別の実施形態に係る患者診察システムの構成を説明するための図である。 図５の実施形態を説明するためのフローチャートである。 更に別の実施形態に係る患者診察システムの構成を説明するための図である。 図７の実施形態を説明するためのフローチャートである。 病院で患者を管理する複数の段階を説明するためのフローチャートである。 患者を管理する複数の段階のうち、一実施形態に係る予約段階を説明するためのフローチャートである。 過去履歴情報を用いて予約段階を行う実施形態を説明するための図である。 図１１の実施形態に係るＵＩを説明するための図である。 患者を管理する複数の段階のうち、別の実施形態に係る予約段階を説明するためのフローチャートである。 図１３の実施形態に係るＵＩを説明するための図である。 患者を管理する複数の段階のうち、受付段階を説明するためのフローチャートである。 位置情報を用いて待機番号を伝送する実施形態を説明するための図である。 図１６の実施形態の具体的な方法を説明するためのフローチャートである。 順番報知情報を伝送する一実施形態を説明するためのフローチャートである。 順番報知情報を伝送する別の実施形態を説明するためのフローチャートである。 患者を管理する複数の段階のうち、診察段階を説明するためのフローチャートである。 患者情報と待機者情報とをマッピングする一実施形態を説明するための図である。 図２１の実施形態で伝送される情報を具体的に説明するための図である。 患者情報と待機者情報とをマッピングする別の実施形態を説明するための図である。 患者情報と待機者情報とをマッピングする更に別の実施形態を説明するための図である。 症状情報を同期化する一実施形態を説明するための図である。 症状情報を同期化する別の実施形態を説明するための図である。 患者を管理する複数の段階のうち、処方段階を説明するためのフローチャートである。 処方情報を伝送する段階を説明するための図である。 処方情報を同期化する一実施形態を説明するための図である。 症状情報及び処方情報を同期化する実施形態を説明するための図である。 一実施形態に係るユーザ端末装置の制御方法を説明するためのフローチャートである。

以下では、添付図面を参照し、本発明について詳細に説明する。

本発明の一実施形態で使用される用語は、本発明における機能を考慮しつつ、できる限り現在広く使われている一般的な用語を選択しているが、それは、当分野に携わる技術者の用途又は判例、新たな技術の出現などによって異なることがある。なお、特定の場合、出願人の任意で採用した用語もあり、この場合、当該開示の説明において、詳細にその意味を記載する。よって、本発明で使われる用語は単なる用語の名称ではない、その用語のもつ意味と、本発明の全般にわたる内容に基づいて定義されるべきである。

本明細書において、「有する」、「有してよい」、「含む」、又は「含んでよい」などの表現は、当該特徴（例：数値、機能、動作又は部品などの構成要素）の存在を指し、更なる特徴を排除しない。

Ａ又は／及びＢのうち少なくとも一方という表現は、「Ａ」又は「Ｂ」、或いは「Ａ及びＢ」のうち、何れかを示すものとして理解されべきである。

本明細書で使われる「第１」、「第１」、「一番目」又は「二番目」などの表現は、多様な構成要素を、順番及び／又は重要度によらず修飾してよく、或る構成要素を別の構成要素と区別するために使用するだけで、当該構成要素を限定しない。

或る構成要素（例：第１の構成要素）が別の構成要素（例：第２の構成要素）に「（機能的に又は通信的に）連結されて（（ｏｐｅｒａｔｉｖｅｌｙ ｏｒ ｃｏｍｍｕｎｉｃａｔｉｖｅｌｙ） ｃｏｕｐｌｅｄ ｗｉｔｈ／ｔｏ）」いるか、「接続されて（ｃｏｎｎｅｃｔｅｄ ｔｏ）」いると言及された際には、或る構成要素が別の構成要素に直接接続されるか、別の構成要素（例：第３の構成要素）を介して接続されてよいと理解されるべきである。

単数の表現は、文脈上明白にそうでないと意味しない限り、複数の表現を含む。本出願において、「含む」又は「構成される」などの用語は、明細書上に記載された特徴、数字、段階、動作、構成要素、部品又はそれらを組み合わせたものが存在することを指定するものであって、一つ又はそれ以上の別の特徴や、数字、段階、動作、構成要素、部品又はそれらを組み合わせたものの存在又は付加の可能性を予め排除しないものと理解されるべきである。

本発明において、「モジュール」或いは「部」は、少なくとも一つの機能や動作を行い、ハードウェア又はソフトウェアで実現されるか、ハードウェアとソフトウェアとの組み合わせで実現されてよい。なお、複数の「モジュール」或いは複数の「部」は、特定のハードウェアで実現される必要のある「モジュール」或いは「部」を除いては、少なくとも一つのモジュールで一体化されて少なくとも一つのプロセッサ（図示せず）で実現されてよい。

本明細書において、ユーザという用語は、電子装置を使用する人、又は電子装置を使用する装置（例：人工知能電子装置）を指してよい。

以下、添付された図を参照し、本発明の一実施形態についてより詳細に説明する。

図１は、本発明の一実施形態に係るユーザ端末装置を示すブロック図である。

図１を参照すると、ユーザ端末装置１００は、メモリ１１０、通信インターフェース１２０、ディスプレイ１３０及びプロセッサ１４０で構成されてよい。

メモリ１１０は、プロセッサ１４０に含まれたＲＯＭ（例えば、ＥＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ））、ＲＡＭなどの内部メモリで実現されるか、プロセッサ１４０と別途のメモリで実現されてよい。この場合、メモリ１１０は、データ保存用途に応じて、ユーザ端末装置１００にエンベデッドされたメモリで実現されるか、ユーザ端末装置１００に着脱可能なメモリで実現されてよい。例えば、ユーザ端末装置１００の駆動のためのデータの場合、ユーザ端末装置１００にエンベデッドされたメモリに保存され、ユーザ端末装置１００の拡張機能のためのデータの場合、ユーザ端末装置１００に着脱可能なメモリに保存されてよい。

メモリ１１０は、スマート診察システムに用いられるアプリケーションを保存することができる。メモリ１１０に保存されたアプリケーションは、病院予約機能をユーザに提供することができる。メモリ１１０に保存されたアプリケーションは、予め設定された周期でアップデートされてよく、アプリケーションはプロセッサ１４０を用いて多様な機能をユーザに提供してよい。

通信インターフェース１２０は、多様な通信方式によって多様な類型の外部装置と通信を行う構成である。通信インターフェース１２０は、Ｗｉ－Ｆｉモジュール、ブルートゥースモジュール、赤外線モジュール及び無線通信モジュールなどを含む。ここで、各通信モジュールは、少なくとも一つのハードウェアチップで実現されてよい。

Ｗｉ－Ｆｉモジュール、ブルートゥースモジュールは、それぞれ、Ｗｉ－Ｆｉ方式、ブルートゥース方式で通信を行う。Ｗｉ－Ｆｉモジュールやブルートゥースモジュールを用いる場合には、ＳＳＩＤ及びセッションキーなどのような各種接続情報を先に送受信し、それを用いて通信接続した後、各種情報を送受信することができる。

赤外線通信モジュールは、光線とミリ波との間にある赤外線を用いて、近距離に無線でデータを伝送する赤外線通信（ＩｒＤＡ、ｉｎｆｒａｒｅｄ Ｄａｔａ Association）技術によって通信を行う。

無線通信モジュールは、上述の通信方式の他に、Ｚｉｇｂｅｅ、３Ｇ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ）、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、ＬＴＥ－Ａ（ＬＴＥ Ａｄｖａｎｃｅｄ）、４Ｇ（４ｔｈ Ｇｅｎｅｒａｔｉｏｎ）、５Ｇ（５ｔｈ Ｇｅｎｅｒａｔｉｏｎ）などのような多様な無線通信規格によって通信を行う少なくとも一つの通信チップを含んでよい。

その他に、通信インターフェース１２０は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）モジュール、イーサネットモジュール、又はペアケーブル、同軸ケーブル又は光ファイバケーブルなどを用いて、通信を行う有線通信モジュールのうち、少なくとも一つを含んでよい。

一例によって、通信インターフェース１２０は、リモコンのような外部装置及び外部サーバと通信するために、同じ通信モジュール（例えば、Ｗｉ－Ｆｉモジュール）を利用することができる。

別の例によって、通信インターフェース１２０は、リモコンのような外部装置及び外部サーバと通信するために、異なる通信モジュール（例えば、Ｗｉ－Ｆｉモジュール）を利用することができる。例えば、通信インターフェース１２０は、外部サーバと通信するために、イーサネットモジュール又はＷｉ－Ｆｉモジュールのうち少なくとも一方を利用してよく、リモコンのような外部装置と通信するために、ＢＴモジュールを利用してよい。ただ、それは一実施形態に過ぎず、通信インターフェース１２０は、複数の外部装置又は外部サーバと通信する場合、多様な通信モジュールのうち、少なくとも一つの通信モジュールを利用してよい。

ディスプレイ１３０は、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）、ＯＬＥＤ（Ｏｒｇａｎｉｃ Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅｓ）ディスプレイ、ＰＤＰ（Ｐｌａｓｍａ Ｄｉｓｐｌａｙ Ｐａｎｅｌ）などのような多様な形態のディスプレイで実現されてよい。ディスプレイ１３０内には、ａ－ｓｉ ＴＦＴ、ＬＴＰＳ（ｌｏｗ ｔｅｍｐｅｒａｔｕｒｅ ｐｏｌｙ ｓｉｌｉｃｏｎ） ＴＦＴ、ＯＴＦＴ（ｏｒｇａｎｉｃ ＴＦＴ）などのような形態で実現できる駆動回路、バックライトユニットなども併せて含まれてよい。一方、ディスプレイ１３０は、タッチセンサと組み合わせられたタッチスクリーン、フレキシブルディスプレイ（ｆｌｅｘｉｂｌｅ ｄｉｓｐｌａｙ）、３次元ディスプレイ（３Ｄ ｄｉｓｐｌａｙ）などで実現されてよい。

なお、本発明の一実施形態に係るディスプレイ１３０は、映像を出力するディスプレイパネルだけでなく、ディスプレイパネルをハウジングするベゼルを含んでよい。特に、本発明の一実施形態に係るベゼルは、ユーザインタラクションを検知するためのタッチセンサ（図示せず）を含んでよい。

プロセッサ１４０は、端末装置を制御する動作全般を行うことができる。具体的に、プロセッサ１４０は、端末装置の動作全般を制御する機能を行う。

プロセッサ１４０は、デジタル信号を処理するデジタルシグナルプロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ（ＤＳＰ）、マイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）、ＴＣＯＮ（Ｔｉｍｅ ｃｏｎｔｒｏｌｌｅｒ）で実現されてよい。ただ、それに限らず、中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ（ＣＰＵ））、ＭＣＵ（Ｍｉｃｒｏ Ｃｏｎｔｒｏｌｌｅｒ Ｕｎｉｔ）、ＭＰＵ（ｍｉｃｒｏ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、コントローラ（ｃｏｎｔｒｏｌｌｅｒ）、アプリケーションプロセッサ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｃｅｓｓｏｒ（ＡＰ））、ＧＰＵ（ｇｒａｐｈｉｃｓ－ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）又はコミュニケーションプロセッサ（ｃｏｍｍｕｎｉｃａｔｉｏｎ ｐｒｏｃｅｓｓｏｒ（ＣＰ））、ＡＲＭプロセッサのうち、一つ又はそれ以上を含むか、当該用語に定義されてよい。なお、プロセッサ１４０は、プロセッシングアルゴリズムの登載されたＳｏＣ（Ｓｙｓｔｅｍ ｏｎ Ｃｈｉｐ）、ＬＳＩ（ｌａｒｇｅ ｓｃａｌｅ ｉｎｔｅｇｒａｔｉｏｎ）で実現されてよく、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）で実現されてよい。なお、プロセッサ１４０は、メモリ１１０に保存されたコンピュータ実行可能な命令語（ｃｏｍｐｕｔｅｒ ｅｘｅｃｕｔａｂｌｅ ｉｎｓｔｒｕｃｔｉｏｎｓ）を実行することで、多様な機能を行うことができる。

ユーザ端末装置１００は、アプリケーションを実行して動作を行うプロセッサ１４０を含んでよい。

具体的に、プロセッサ１４０は、症状情報を入力されるためのＵＩ画面をディスプレイ１３０に表示してよい。ここで、症状情報は、ユーザ端末装置１００を用いる患者の症状に関連する情報を意味してよい。例えば、症状情報は、体の部位（左手首）及び痛みの種類（しびれ）を含んでよい。なお、症状情報は、ディスプレイ１３０に表示されたＵＩ画面に基づいてユーザによって入力されてよい。ここで、ユーザは患者を意味してよい。症状情報は、ユーザ端末装置１００のユーザインターフェース１５０を介して入力されてよい。一方、プロセッサ１４０が症状情報を入力されるためのＵＩ画面をいつ表示するかに対し、多様な条件があってよい。一例として、プロセッサ１４０は、アプリケーションサーバ２００から予約情報を伝送されると、症状情報を入力されるためのＵＩ画面をディスプレイ１３０に表示してよい。別の例として、プロセッサ１４０は、アプリケーションがユーザによって実行されると、症状情報を入力されるためのＵＩ画面をディスプレイ１３０に表示してよい。一方、その他に、多様な予め設定されたイベントに基づいて、プロセッサ１４０は症状情報を入力されるためのＵＩ画面をディスプレイ１３０に表示してよい。

なお、プロセッサ１４０は、ＵＩ画面を介してユーザの症状情報が入力されると、症状情報及び待機番号の要請を病院管理サーバ３００に伝送してよい。待機番号の要請とは、患者が担当医に診察を受けるために、受付順を与えられるために、要請することを意味してよい。受付順は、患者が実際に待機番号を与えられる順番を意味してよく、診察順は患者が実際に診察を受ける順番を意味してよい。受付順と診察順とは通常一致するが、場合によって受付順と診察順とが異なってよい。

病院管理サーバ３００は、ユーザ端末装置１００から待機番号の要請を受信すると、待機番号をユーザ端末装置１００に割り当て、割り当てられた待機番号をユーザ端末装置１００に再度伝送してよい。そして、病院管理サーバ３００は、待機番号の要請を伝送したユーザ端末装置１００と待機番号をマッピングし、機器情報として病院管理サーバ３００のメモリに保存してよい。即ち、病院管理サーバ３００は、特定の待機番号に対応する端末装置をマッピングして保存していてよい。特に、病院管理サーバ３００は、待機番号とユーザ端末装置１００をマッピングする場合、待機番号とユーザ端末装置１００の症状情報をマッピングしてよい。病院管理サーバ３００は、症状情報を特定の患者に関する情報として保存せずに、待機番号に対応する症状情報として保存してよい。症状情報を待機番号とマッピング（グルーピング）して保存する理由は、症状情報がどの患者に関するものかを正確に保存しないためである。症状情報がどの患者のものかを保存しないことで、個人情報の漏洩に備えることができるためである。そして、症状情報が誰のものかは、現在の医療で診療行為とともに担当医の確認を経てから患者情報に保存されることができる。それに関連する具体的な動作は、後述する。

なお、プロセッサ１４０は、病院管理サーバ３００から待機番号の要請に対応する待機番号を受信してよく、受信された待機番号を含むＵＩ画面をディスプレイ１３０に表示してよい。ユーザは、ディスプレイ１３０に表示された待機番号に基づいて自分の診察順を判断することができる。一方、プロセッサ１４０は、ディスプレイ１３０に待機番号の他に更に、日付情報、住民番号、待機者数、待機場所、待機予想時間のうち、すくなくとも一つを更に表示してよい。

なお、プロセッサ１４０は、ユーザの識別情報をアプリケーションサーバ２００に伝送してよい。識別情報は、ユーザを特定できる情報を意味してよい。例えば、識別情報は、氏名、生年月日、アプリケーション登録ＩＤ、医療保険番号、パスポート番号など、病院に保存された患者番号のうち、少なくとも一つを含んでよい。一方、プロセッサ１４０は、症状情報を除き、識別情報のみをアプリケーションサーバ２００に伝送してよい。なお、プロセッサ１４０は、アプリケーションサーバ２００がユーザの識別情報を病院管理サーバ３００に伝送するように制御する制御命令を生成してよい。プロセッサ１４０は、上述の制御命令と識別情報とをアプリケーションサーバ２００に伝送してよい。プロセッサ１４０は、識別情報及び症状情報を区分して管理してよい。具体的に、プロセッサ１４０は、識別情報をアプリケーションサーバ２００に伝送し、症状情報を病院管理サーバ３００に直接伝送してよい。結果的に、識別情報及び症状情報のいずれもが、病院管理サーバ３００に伝送されるが、症状情報はアプリケーションサーバ２００を介さなくてよい。よって、アプリケーションサーバ２００がハッキングされる場合でも、症状情報は漏洩されずに済む。

ここで、病院管理サーバ３００に伝送された症状情報を含む第１のＵＩ画面、及びユーザの識別情報を含む第２のＵＩ画面を病院管理サーバ３００と通信するディスプレイ６００（図２４を参照）に提供されてよい。

病院管理サーバ３００は、ユーザ端末装置１００から症状情報を受信してよい。そして、病院管理サーバ３００は、識別情報をアプリケーションサーバ２００から受信してよい。そして、病院管理サーバ３００は、症状情報を含む第１のＵＩ画面を生成し、生成された第１のＵＩ画面に対応する情報をディスプレイ装置６００に伝送してよい。なお、病院管理サーバ３００は、識別情報を含む第２のＵＩ画面を生成、生成された第２のＵＩ画面に対応する情報をディスプレイ装置６００に伝送してよい。第１のＵＩ画面及び第２のＵＩ画面に関する情報を受信されるディスプレイ装置６００は、第１のＵＩ画面及び第２のＵＩ画面を同時にディスプレイ装置６００のディスプレイに表示してよい。

一方、第１のＵＩ画面は、ユーザ（患者）の症状情報、待機番号のうち少なくとも一方を含んでよい。症状情報及び待機番号は、待機者情報と称されてよい。第１のＵＩ画面は、図２４の第２の領域２４１０に表示される画面であってよい。なお、第２のＵＩ画面は、ユーザ（患者）の識別情報、病歴情報のうち、少なくとも一方を含んでよい。識別情報及び病歴情報は、患者情報と称されてよい。第２のＵＩ画面は、図２４の第１の領域２４０５に表示される画面であってよい。

ここで、ディスプレイ装置６００は、病院管理サーバ３００に接続されたディスプレイを含む電子装置を意味する。例えば、病院管理サーバ３００に接続された担当医のパソコンを意味してよい。

なお、プロセッサ１４０は、ＵＩ画面を介して病院の予約のための情報が入力されると、ユーザの識別情報及び病院の予約のための情報をアプリケーションサーバ２００に伝送してよく、アプリケーションサーバ２００から病院の予約情報が受信されると、受信された病院の予約情報を含むＵＩ画面をディスプレイに表示してよく、予約情報は予約時間を含んでよい。

プロセッサ１４０は、ユーザ端末装置１００に含まれたディスプレイを介して多様なＵＩをユーザに提供してよい。そして、ユーザ端末装置１００は、ユーザに病院の予約のための情報の入力を要請するＵＩ画面をディスプレイに表示してよい。病院の予約のための情報は、診察病院、診療科、診察時間、担当医のうち、少なくとも一つを意味してよい。プロセッサ１４０は、ユーザ端末装置１００に含まれたユーザインターフェースを介して病院の予約のための情報が受信されると、受信された病院の予約のための情報及び固有のユーザ端末装置１００の識別情報をアプリケーションサーバ２００に伝送してよい。ここで、アプリケーションサーバ２００に伝送される識別情報は、ユーザ端末装置１００を利用するユーザ（患者）の氏名、住民番号、患者番号などのような個人識別情報を意味してよい。仮に、アプリケーションサーバ２００にユーザ端末装置１００の個人識別情報が保存されている場合、ユーザ端末装置１００は識別情報をアプリケーションサーバ２００に伝送しない形態で実現されてよい。

アプリケーション２００は、ユーザ端末装置２００から病院の予約のための情報及び識別情報を受信し、病院管理サーバ３００に病院の予約のための情報及び識別情報を伝送してよい。そして、病院管理サーバ３００は、受信された病院の予約のための情報及び識別情報に基づいて病院の予約情報を生成してよい。そして、生成された病院の予約情報をアプリケーションサーバ２００に伝送してよい。アプリケーションサーバ２００は、病院管理サーバ３００から受信された病院の予約情報をユーザ端末装置１００に伝送してよい。そして、ユーザ端末装置１００は、受信された病院の予約情報を含むＵＩ画面をユーザ端末装置１００のディスプレイに表示してよい。ここで、病院の予約情報は、診察病院、診療科、診察時間（予約時間）、担当医のうち、少なくとも一つを含んでよい。

一方、一実施形態によって、ユーザ端末装置１００は、病院管理サーバ３００から予約情報及び待機番号を同時に受信する形態で実現されてよい。なお、別の実施形態によって、ユーザ端末装置１００は、病院管理サーバ３００から予約情報を先に受信し、その後で待機番号を受信する形態で実現されてよい。

一方、予約に関する具体的な動作は、図１０ないし図１４を参照して後述する。

ここで、プロセッサ１４０は、予約時間より臨界時間前の時点から、ユーザ端末装置１００の位置情報を病院管理サーバ３００に伝送してよく、病院管理サーバ３００から位置情報に対応する待機番号を受信すると、受信された待機番号を含むＵＩ画面をディスプレイに表示してよい。

ここで、病院管理サーバ３００は、位置情報が病院の位置から臨界距離内であれば、順位の高い待機番号をユーザ端末装置１００に提供してよい。

位置情報と待機番号とに関する具体的な動作は、図１５ないし図１９を参照して後述する。

一方、プロセッサ１４０は、受信された待機番号を通信インターフェースを介してアプリケーションサーバ２００に伝送してよく、アプリケーションサーバ２００が識別情報と待機番号とを病院管理サーバ３００に伝送するように制御してよい。

既に説明したように、ユーザ端末装置１００から受信された症状情報は、待機番号とマッピング（グルーピング）され、病院管理サーバ３００のメモリに保存されてよい。よって、病院管理サーバ３００は、受信された症状情報がどの患者のものか知ることができず、単に特定の待機番号に対応するものであるという情報のみを保存していることになる。よって、ユーザ端末装置１００は、待機番号のみをアプリケーションサーバ２００に伝送してよい。ユーザ端末装置１００は、ユーザ端末装置１００に割り当てられた待機番号をアプリケーションサーバ２００に伝送してよく、アプリケーションサーバ２００はユーザ端末装置１００に割り当てられた待機番号を病院管理サーバ３００に伝送してよい。病院管理サーバ３００は、ユーザ端末装置１００に割り当てられた待機番号を受信し、特定の待機番号に対応する症状情報がユーザ端末装置１００に対するものであることを判断してよい。割り当てられた待機番号をアプリケーションサーバ２００に伝送する動作に関する具体的な説明は、図２１のステップＳ２１７０で説明する。

既に説明したように、個人情報の漏洩を防止するために、病院管理サーバ３００は症状情報を識別情報と組み合わせなくてよい。そして、病院管理サーバ３００は、症状情報を特定するために、待機番号と組み合わせてよい。そして、病院管理サーバ３００は、アプリケーションサーバ２００から識別情報及び待機番号を受信してよい。

一方、一例として、病院管理サーバ３００は、識別情報及び待機番号を同時にアプリケーションサーバ２００から受信してよい。別の例として、病院管理サーバ３００は、識別情報を先にアプリケーションサーバ２００から受信し、待機番号を後でアプリケーションサーバ２００から受信する形態で実現されてよい。

それに関する具体的な動作は、図２０ないし図２４を参照して後述する。

なお、病院管理サーバ３００に伝送された症状情報及び待機番号を含む第１のＵＩ画面、及びユーザの識別情報及び待機番号を含む第２のＵＩ画面が病院管理サーバ３００と通信するディスプレイ装置６００に提供されてよい。

病院管理サーバ３００は、ユーザ端末装置１００から直接症状情報を受信してよく、病院管理サーバ３００は、ユーザ端末装置１００に与えた待機番号を症状情報に組み合わせて保存してよい。そして、病院管理サーバ３００は、アプリケーションサーバ２００から受信した識別情報及び待機情報を組み合わせて保存してよい。病院管理サーバ３００が症状情報と識別情報とを両方受信するが、症状情報はユーザ端末装置１００から受信したものであり、識別情報はアプリケーションサーバ２００から受信したものであってよい。アプリケーションサーバ２００には、識別情報のみが保存されてよく、症状情報が全く保存されていない状態であってよい。よって、アプリケーションサーバ２００がハッキングされたとしても、ユーザ端末装置１００を利用するユーザの症状情報は流出されなくて済む。

病院管理サーバ３００は、症状情報と症状情報に対応する待機番号とを含む第１のＵＩ画面を生成してよく、生成された第１のＵＩ画面をディスプレイ装置６００に伝送してよい。そして、病院管理サーバ３００は、識別情報と識別情報に対応する待機番号とを含む第２のＵＩ画面を生成してよく、生成された第２のＵＩ画面をディスプレイ装置６００に伝送してよい。

なお、プロセッサ１４０は、病院管理サーバ３００から処方情報を受信してよく、受信された処方情報を含むＵＩ画面をディスプレイに表示してよい。ここで、処方情報は、担当医が患者に対する診察の結果を入力した情報を意味してよい。病院管理サーバ３００は、待機番号に基づいて処方情報を伝送するユーザ端末装置１００を識別してよく、識別されたユーザ端末装置１００に処方情報を伝送してよい。一方、処方段階に関する具体的な動作は、図２７ないし図３０を参照して後述する。

一方、病院管理サーバ３００は、第１の病院管理サーバ及び第２の病院管理サーバを含んでよく、症状情報及び待機番号の要請は、第１の病院管理サーバに伝送されてよく、ユーザの識別情報は第２の病院管理サーバに伝送されてよい。

ここで、第１の病院管理サーバは、図７の病院管理サーバ３００及び受付管理サーバ５００を意味してよい。そして、第２の病院管理サーバは、図７の病院管理サーバ３００及びＥＭＲサーバ４００を意味してよい。症状情報及び待機番号の要請は、受付管理サーバ５００を隔てて病院管理サーバ３００に伝送されてよい。そして、識別情報は、病院管理サーバ３００を隔ててＥＭＲサーバ４００に伝送されてよい。受付管理サーバ５００及びＥＭＲサーバ４００に関する具体的な説明は、図７及び図８を参照して後述する。

ここで、症状情報は、第１の通信モジュールを介して病院管理サーバ３００に伝送されてよく、ユーザの識別情報は、第２の通信モジュールを介して病院管理サーバ３００に伝送されてよい。

ユーザ端末装置１００は、症状情報と識別情報とがまとめて漏洩されることを防止するために、別の通信方式を用いて病院管理サーバ３００に情報を伝送してよい。例えば、プロセッサ１４０は、近距離無線通信を用いて症状情報を病院管理サーバ３００に伝送してよい。近距離通信方式は、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ）、Ｗｉ－Ｆｉ、Ｚｉｇｂｅｅ、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、赤外線のうち、少なくとも一つを意味してよい。なお、プロセッサ１４０は、症状情報を伝送するのに用いた通信方式の他に、別の通信方式を用いて識別情報を病院管理サーバ３００に伝送してよい。なお、プロセッサ１４０は、識別情報を移動通信ネットワークを介して病院管理サーバ３００に伝送してよい。ここで、移動通信ネットワークは、ＬＴE（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、ＬＴＥ－Ａ（ＬＴＥ Ａｄｖａｎｃｅｄ）、４Ｇ（４ｔｈ Ｇｅｎｅｒａｔｉｏｎ）、５Ｇ（５ｔｈ Ｇｅｎｅｒａｔｉｏｎ）などのような多様な無線通信ネットワークなどを意味してよい。

ここで、プロセッサ１４０は、病院管理サーバ３００から処方情報を受信してよく、受信された処方情報を含むＵＩ画面をディスプレイに表示してよく、処方情報は、第１の通信モジュ―ルを介して病院管理サーバ３００から受信されてよい。

処方情報は、診療明細書を意味してよい。診療明細書は、薬の種類、検査項目、診療行為項目のうち、少なくとも一つを含んでよい。

処方情報は、症状情報と同様に、敏感な個人情報であってよい。よって、処方情報は、個人情報の漏洩を防止するために、識別情報と組み合わせられてまとめてユーザ（患者）に伝送されなくてよい。処方情報と識別情報が組み合わせられて保存される場所は、安定性の確保されたＥＭＲサーバ４００であってよい。病院管理サーバ３００は、処方情報を待機番号とともにグルーピングして保存してよい。処方情報及び待機番号がまとまって流出されても、処方情報が誰のものなのか知ることが困難であるであるためである。よって、病院管理サーバ３００は。症状情報を受信するのに利用した第１の通信モジュールをそのまま利用し、処方情報をユーザ端末装置１００に伝送してよい。

一方、プロセッサ１４０は、受信された待機番号を予め設定された条件に基づいて削除してよい。一例として、プロセッサ１４０は、待機番号の受信された時点から臨界時間が経過した後、待機番号を削除してよい。別の例として、プロセッサ１４０は、待機番号に含まれた日付情報に基づいて、待機番号を削除してよい。待機番号は、日付情報を含んでよく、プロセッサ１４０は、待機番号に含まれた日付情報とユーザ端末装置１００の日付情報とを比較してよい。そして、待機番号に含まれた日付情報がユーザ端末装置１００の日付より前であれば、プロセッサ１４０は待機番号を削除してよい。

一方、上述の待機番号の削除動作は、待機番号を生成及び受信した多様な装置（ユーザ端末装置１００、アプリケーションサーバ２００、病院管理サーバ３００、受付管理サーバ５００）のうち、少なくとも一つの装置で行われてよい。

一方、本発明に係るスマート診察システムは、患者の識別情報と症状情報とを区分する。具体的に、ユーザ端末装置１００は、識別情報をアプリケーションサーバ２００に伝送し、アプリケーションサーバ２００は識別情報を病院管理サーバ３００に伝送する。一方で、ユーザ端末装置１００は、症状情報をアプリケーションサーバ２００に伝送せずに、直ちに病院管理サーバ３００に伝送する。よって、アプリケーションサーバ２００がハッキングされても、患者の症状情報は流出されなくて済む。患者の症状情報は、待機番号と組み合わせて特定されてよい。通常、症状情報は、患者の固有の個人識別情報と組み合わせるため、症状情報が誰の病歴情報かを知ることができるが、症状情報が待機番号と組み合わせることになると、症状情報が誰のものか容易に知ることができない。ただ、担当医は、待機番号と組み合わせられた症状情報がどの患者のものかを把握することができるようにしなければならない。よって、待機者情報（症状情報を含む）と患者情報（識別情報）とをマッピングする動作が必要であってよい。このような過程を経て、病院管理サーバ３００又は担当医は、症状情報がどの患者のものか知ることができる。本発明に係る症状情報管理方法は、アプリケーションサーバ２００に症状情報を保存させずに、患者の症状情報を予め収集する（又は受信する）、診察時間を短縮させることができる。即ち、患者の個人情報の漏洩問題を解決すると同時に、診察時間を短縮させることができるため、本発明に係るスマート診察システムは、患者（顧客）の待機時間を効率的に減らすことができる効果を奏する。

なお、本発明は、予約患者が実際に来院するか否かを判断する動作を含む。具体的に、病院管理サーバ３００は、ユーザ端末装置１００から位置情報を受信してよい。そして、病院管理サーバ３００は、受信された位置情報が病院の位置から臨界距離内にあると判断すると、実際に来院すると判断してよい。位置情報を用いて予約患者の来院の有無を判断すると、ノーショー（Ｎｏ ｓｈｏｗ）患者を区分することができ、不要な予約を簡単にキャンセルことができる。本発明の実施形態により、不要な予約をキャンセルすることができれば、病院管理の複雑性を解決して単純化させることができ、効率よく待機者数を管理することができる。待機者数を効率的に管理することができれば、本発明に係るスマート診察システムは患者の病院での待機時間を短縮させることができる効果を奏する。

図２は、図１のユーザ端末装置の具体的な構成を説明するためのブロック図である。

図２を参照すると、ユーザ端末装置１００は、メモリ１１０、通信インターフェース１２０、ディスプレイ１３０、プロセッサ１４０、ユーザインターフェース１５０、入出力インターフェース１６０、マイク１７０又はカメラ１８０のうち、少なくとも一つで構成されてよい。

メモリ１１０、通信インターフェース１２０、ディスプレイ１３０、プロセッサ１４０については、図１を参照して既に説明しているため、繰り返し記載を省略する。

ユーザインターフェース１５０は、ボタン、タッチパッド、マウス及びキーボードのような装置で実現されるか、上述のディスプレイ機能及び操作入力機能も同時に実行可能なタッチスクリーンでも実現されてよい。ここで、ボタンは、ユーザ端末装置１００の本体の外観の前面部や側面部、背面部などの任意の領域に形成された機械的なボタン、タッチパッド、ホイールなどのような多様なボタンになってよい。

入出力インターフェース１６０は、ＨＤＭＩ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）、ＭＨＬ（Ｍｏｂｉｌｅ Ｈｉｇｈ－Ｄｅｆｉｎｉｔｉｏｎ Ｌｉｎｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）、ＤＰ（Ｄｉｓｐｌａｙ Ｐｏｒｔ）、サンダーボルト（Ｔｈｕｎｄｅｒｂｏｌｔ）、ＶＧＡ（Ｖｉｄｅｏ Ｇｒａｐｈｉｃｓ Ａｒｒａｙ）ポート、ＲＧＢポート、Ｄ－ＳＵＢ（Ｄ－ｓｕｂｍｉｎｉａｔｕｒｅ）、ＤＶＩ（Ｄｉｇｉｔａｌ Ｖｉｓｕａｌ Ｉｎｔｅｒｆａｃｅ）のうち、いずれか一つのインターフェースであってよい。

入出力インターフェース１６０は、オーディオ及びビデオ信号のうち、少なくとも一つを入出力してよい。

実現例によって、入出力インターフェース１６０は、オーディオ信号のみを入出力するポートと、ビデオ信号のみを入出力するポートとを別個のポートで含むか、オーディオ信号及びビデオ信号をいずれも入出力する一つのポートで実現されてよい。

ユーザ端末装置１００は、マイク１７０を更に含んでよい。マイクは、ユーザ音声やその他の音を入力され、オーディオデータに変換するための構成である。

マイク１７０は、活性化状態でユーザの音声を受信することができる。例えば、マイクは、ユーザ端末装置１００の上側や前面方向、側面方向などに一体型で形成されてよい。マイクは、アナログのユーザ音声を収集するマイク、収集されたユーザ音声を増幅するアンプ回路、増幅されたユーザ音声をサンプリングしてデジタル信号に減館するＡ/Ｄ変換回路、変換されたデジタル信号からノイズ成分を取り除くフィルタ回路などのような多様な構成を含んでよい

カメラ１８０は、被写体を撮像し、撮像映像を生成するための構成であり、ここで、撮像映像は、動画と静止映像の両方を含む概念である。

カメラ１８０は、少なくとも一つの外部機器に対するイメージを獲得することができ、カメラ、レンズ、赤外線センサなどで実現されてよい。

ユーザ端末装置１００は、スピーカ（図示せず）を含んでよい。スピーカ（図示せず）は、入出力インターフェースで処理された各種オーディオデータだけでなく、各種報知音や音声メッセージなどを出力する構成要素であってよい。

ユーザ端末装置１００は、振動部（図示せず）を含んでよい。振動部（図示せず）は、臨界条件で振動機能を提供する構成要素であってよい。臨界条件は、予約確定の報知、予約時間の報知、待機番号確定の報知、診察順の報知、処方情報受信の報知、決済要請の報知、決済確定の報知のうち少なくとも一つであってよい。その他にも、多様な状況で振動図（図示せず）の振動機能が提供されてよい。

図３は、一実施形態に係る患者診察システムの構成を説明するための図である。

図３を参照すると、患者診察システム１０００は、ユーザ端末装置１００、アプリケーションサーバ２００及び病院管理サーバ３００で構成されてよい。

患者診察システム１０００は、病院で行われる多様な動作の集合を意味してよい。具体的に、患者診察システム１０００は、患者の診察過程で行われる予約、受付、診察、処方段階に関連する動作を含んでよい。

ユーザ端末装置１００は、スマートフォン、タブレット、ＰＤＡのような携帯用電子装置を意味してよい。ユーザ端末装置１００には、アプリケーションがインストールされてよく、具体的に、ユーザ端末装置１００には、患者診察システム１０００に用いられる病院アプリケーションがインストールされてよい。病院アプリケーションは、ユーザが受診を希望する病院の予約を行うことができるようにガイドする多様なＵＩを提供してよい。

アプリケーションサーバ２００は、ユーザ端末装置１００にインストールされたアプリケーションに対する管理及び制御のためのサーバを意味してよい。アプリケーションサーバ２００は、ユーザ端末装置１００にインストールされたアプリケーションプログラムの実行環境及びデータベースの接続機能を行うことができる。なお、アプリケーションサーバ２００は、ユーザ端末装置１００にインストールされたアプリケーションを介してユーザ端末装置１００と外部サーバ又は外部装置とデータをやり取りできるように動作してよい。

病院管理サーバ３００は、病院で利用される多様な電子装置を意味してよい。病院管理サーバ３００は、患者の診察記録を保存する装置、待機番号などを管理する受付管理装置、医師が患者に関する情報を入力する装置、病院内の複数の装置を制御する装置などのように、病院で利用される多様な装置を意味してよい。一方、病院管理サーバ３００は、少なくとも一つの電子装置を意味してよい。実施形態によって、病院管理サーバ３００は、複数のハードウェアで構成されるか、複数の電子装置で構成されてよい。

なお、ユーザ端末装置１００は、症状情報（又は、個人症状情報）及び識別情報（又は、個人識別情報）を相互異なる装置に伝送してよい。ここで、症状情報は、ユーザの身体的又は肉体的に異変を感じる症状を意味してよい。そして、識別情報は氏名、生年月日、パスポート番号、医療保険番号、固有ＩＤなどのように、ユーザを識別できる情報を意味してよい。

なお、ユーザ端末装置１００は、予約段階で識別情報をアプリケーションサーバ２００に伝送してよい。そして、アプリケーションサーバ２００は、受信された識別情報を病院管理サーバ３００に伝送してよい。病院管理サーバ３００は、受信された識別情報に基づいて予約動作を行ってよい。

そして、ユーザ端末装置１００は、症状情報をアプリケーションサーバ２００を隔てずに直接病院管理サーバ３００に伝送してよい。ただ、患者診察システム１０００で結果的に症状情報及び識別情報は、病院管理サーバ３００に伝送されてよい。

ユーザ端末装置１００は、症状情報及び識別情報を相互異なる装置に伝送する理由は、個人情報を守るためである。症状情報と識別情報とを一つのデータグループにグルーピングして伝送する場合、個人情報が漏洩する可能性が高くなる。しかし、図３のように、症状情報及び識別情報を区分して伝送する場合、アプリケーションサーバ２００がハッキングされたとしても、症状情報は流出されない可能性が高い。同様に、ユーザ端末装置１００から伝送される症状情報の伝送過程でハッキングが行われても、ユーザの識別情報は流出されなくて済む。

図４は、図３の実施形態を説明するためのフローチャートである。

図４を参照すると、ユーザ端末装置１００は、ユーザの入力に基づいて予約要請及び識別情報をアプリケーションサーバ２００に伝送してよい（Ｓ４０５）。そして、アプリケーションサーバ２００は、受信された予約要請及び識別情報を病院管理サーバ３００に伝送してよい（Ｓ４１０）。そして、病院管理サーバ３００は、受信された予約要請及び識別情報に基づいて予約情報を生成してよい（Ｓ４１５）。ここで、予約情報は、病院名、診療科、予約時間、予約担当医、持参物、注意事項などのように、受診に関する多様な情報を含んでよい。ここで、予約情報を生成するうえで、病院管理サーバ３００は、患者の新患（新規の患者）又は再診か否かを識別してよい。病院管理サーバ３００は、患者が新患か否かに応じて、予約情報を異なるように管理することができる。具体的に、病院管理サーバ３００は、患者が新患である場合、ＥＭＲサーバ４００（図６を参照）に患者の情報を新たに生成してよい。

なお、病院管理サーバ３００は、受信された予約情報に基づいて予約情報に対応する患者情報を生成してよい（Ｓ４２０）。例えば、受信された予約情報に含まれたユーザ名が「山田 太郎」である場合、病院のデータベースに保存された「山田 太郎」に関する患者情報を生成してよい。ここで、患者情報とは、個人の識別情報及び病歴情報が全て記録された医療記録に関する情報を意味してよい。新患（新規の患者）の場合、病院管理サーバ３００は、患者情報がデータベースに保存されていないため、新たな病院登録番号を生成してよい。そして、再診の場合、患者情報がデータベースに保存されているため、従来の病院登録番号に予約情報を追加してよい。一方、予約要請に関する具体的な動作は、図１０ないし図１４を参照して後述する。一方、病院管理サーバ３００又はアプリケーションサーバ２００は、患者の個人情報に関する予約情報又は識別情報を予め設定された時間が経過した場合、自動的に削除してよい。なお、処方情報に関する削除動作については、図２８を参照して具体的に説明する。

なお、病院管理サーバ３００は、生成された予約情報をアプリケーションサーバ２００に伝送してよい（Ｓ２４５）。そして、アプリケーションサーバ２００は、受信された予約情報をユーザ端末装置１００に伝送してよい（Ｓ４３０）。そして、ユーザ端末装置１００は、受信された予約情報をディスプレイに表示してよい（Ｓ４３５）。なお、ユーザ端末装置１００は、待機番号の要請有無を判断してよい（Ｓ４４０）。待機番号の要請有無を判断する動作は、病院管理サーバ３００にユーザ固有の待機番号を割り当てよという要請を伝送するか否かを判断することを意味してよい。予約と異なり、待機番号を新たに要請する理由は、病院が予約情報と別に待機番号を用いて患者の診察順を決定しているためであってよい。よって、ユーザ端末装置１００は、ユーザが来院するか否かを判断するために、ユーザの意図を問うＵＩを提供してよい。そして、ユーザ端末装置１００が来院するとのユーザの応答を受信すると（待機番号を要請すると判断すると）、ユーザ端末装置１００は、待機番号の要請及び症状情報を病院管理サーバ３００に伝送してよい（Ｓ４４５）。ユーザ端末装置１００が待機番号の要請とともに症状情報を同時に伝送することは、個人情報である症状情報を識別情報と分離して伝送するためである。ここで、症状情報は、ユーザ端末装置１００のメモリに保存された状態か、ユーザによって入力されたものであってよい。症状情報を入力される時点は多様であってよい。

病院管理サーバ３００は、ユーザ端末装置１００から待機番号の要請及び症状情報を受信すると、病院管理サーバ３００は、待機番号の要請及び症状情報を伝送したユーザ端末装置１００に対する機器情報を獲得してよい。

そして、病院管理サーバ３００は、ユーザが来院するか否かを判断してよい（Ｓ４５０）。ステップＳ４５０に関する具体的な説明は、図１５ないし図１７を参照して後述する。

病院管理サーバ３００は、患者が来院すると判断すると、予約情報に基づいて優先順位を有する待機番号をユーザ端末装置１００に割り当ててよい。そして、病院管理サーバ３００は、ユーザ端末装置１００に割り当てられた待機番号及びユーザ端末装置１００から受信した症状情報を組み合わせて待機者情報を生成してよい（Ｓ４５５）。ここで、待機者情報は、待機番号及び症状情報を含んでよく、ユーザの識別情報を含まなくてよい。よって、待機者情報のみでは、ユーザが誰かを特定することができない。

病院管理サーバ３００は、ユーザ端末装置１００に割り当てた待機番号を獲得した機器情報に基づいてユーザ端末装置１００に伝送してよい（Ｓ４６０）。そして、ユーザ端末装置１００は、受信された待機番号をディスプレイに表示してよい（Ｓ４６５）。

そして、病院管理サーバ３００は、患者情報及び待機者情報をマッピングしてよい（Ｓ４７０）。ステップＳ４７０については、図２０ないし図２６を参照して具体的に後述する。

図５は、別の実施形態に係る患者診察システムの構成を説明するための図である。

図５を参照すると、患者診察システム１０００は、ユーザ端末装置１００、アプリケーションサーバ２００及び病院管理サーバ３００及びＥＭＲサーバ４００を含んでよい。図３の説明において、病院管理サーバ３００が病院で利用される多様な電子装置を含んでよいと述べている。しかし、図３の病院管理サーバ３００に含まれ得るＥＭＲサーバ４００を別に分離した実施形態について、図５を参照して説明する。

具体的に、ユーザ端末装置１００は、識別情報をアプリケーションサーバ２００に伝送してよく、アプリケーションサーバ２００は、受信された識別情報を病院管理サーバ３００に伝送してよく、病院管理サーバ３００は、受信された識別情報をＥＭＲサーバ４００に伝送してよい。そして、ＥＭＲサーバ４００は、受信された識別情報に対応する患者情報を検索し、検索された患者情報を病院管理サーバ３００に伝送してよい。一方、ユーザ端末装置１００は、症状情報を病院管理サーバ３００に伝送してよい。

ここで、ＥＭＲサーバ４００は、複数の患者に対する医療記録を電算処理するサーバを意味してよい。具体的に、ＥＭＲサーバ４００は、受信された識別情報に対応する患者情報を検索し、検索された患者情報（識別情報を含む）を病院管理サーバ３００に伝送してよい。

図３において、病院管理サーバ３００は、病院管理業務に用いられる多様な電子装置と記述されているが、図５の病院管理サーバ３００は、待機番号を割り当てる装置を意味してよい。なお、図５の病院管理サーバ３００は、患者情報及び待機者情報をマッピングする装置を意味してよい。

結果的に、病院管理サーバ３００は、ユーザ端末装置１００から症状情報を受信してよく、アプリケーションサーバ２００から識別情報を受信してよい。

一方、図５で開示する動作に対する具体的な説明は、図３の動作に対応してよい。よって、図３と重複する説明について詳細な記載を省略する。

図６は、図５の実施形態を説明するためのフローチャートである。

図６を参照すると、ユーザ端末装置１００は、予約要請及び識別情報をアプリケーションサーバ２００に伝送してよい（Ｓ６０５）。そして、アプリケーションサーバ２００は、受信された予約要請及び識別情報を病院管理サーバ３００に伝送してよい（Ｓ６１０）。そして、病院管理サーバ３００は、受信された識別情報をＥＭＲサーバ４００に伝送してよい（Ｓ６１５）。そして、ＥＭＲサーバ４００は、受信された識別情報に対応する患者情報を検索してよい。そして、ＥＭＲサーバ４００は、検索された患者情報を病院管理サーバ３００に伝送してよい（Ｓ６２０）。もし、ＥＭＲサーバ４００に受信された識別情報に対応する患者情報が存在しない場合、ＥＭＲサーバ４００は、新たな病院登録番号を生成し、新たに生成された病院登録番号を病院管理サーバ３００に伝送してよい。一方、病院管理サーバ３００は、受信された患者情報に基づいて予約情報を生成してよい（Ｓ６２５）。そして、病院管理サーバ３００は、生成された予約情報をアプリケーションサーバ２００に伝送してよく（Ｓ６３０）、アプリケーションサーバ２００は受信された予約情報をユーザ端末装置１００に伝送してよい（Ｓ６３５）。

ユーザ端末装置１００が予約情報を受信すると、ユーザ端末装置１００は予約情報をディスプレイに表示してよく（Ｓ６４０）、待機番号の要請有無を判断してよい（Ｓ６４５）。ユーザ端末装置１００が待機番号を要請したと判断すると、ユーザ端末装置１００は待機番号の要請及び症状情報を病院管理サーバ３００に伝送してよい（Ｓ６５０）。なお、病院管理サーバ３００は、ユーザが来院したか否かを判断してよい（Ｓ６５５）。なお、ユーザが来院したと判断されると、病院管理サーバ３００は、待機番号をユーザ端末装置１００に割り当て、割り当てられた待機番号及び症状情報を組み合わせて待機者情報を生成してよい（Ｓ６６０）。病院管理サーバ３００は、ユーザ端末装置１００に待機番号を伝送してよく（Ｓ６６５）、ユーザ端末装置１００は受信された待機番号をディスプレイに表示してよい（Ｓ６７０）。なお、病院管理サーバ３００は、患者情報及び待機者情報をマッピングしてよい（Ｓ６７５）。

一方、図６において開示する動作に対する具体的な説明は、図４の動作に対応してよい。よって、図４と重複する説明については、詳細な説明を省略する。

図７は、更に別の実施形態に係る患者診察システムの構成を説明するための図である。

図７を参照すると、患者診察システム１０００は、ユーザ端末装置１００、アプリケーションサーバ２００、病院管理サーバ３００、ＥＭＲサーバ４００及び受付管理サーバ５００を含んでよい。

受付管理サーバ５００は、病院の患者の受付動作に関連する機能を行う装置を意味してよい。受付管理サーバ５００は、待機番号を管理する機能を別に行う装置を意味してよい。一方、図５の病院管理サーバ３００は、待機番号を割り当てる機能を行うものとして記載しているが、図７の病院管理サーバ３００は、待機番号を割り当てる機能を行わなくてよく、患者情報及び待機者情報をマッピングする機能を行ってよい。

具体的に、ユーザ端末装置１００は、識別情報をアプリケーションサーバ２００に伝送してよく、アプリケーションサーバ２００は、受信された識別情報を病院管理サーバ３００に伝送してよい。病院管理サーバ３００は、受信された識別情報をＥＭＲサーバ４００に伝送してよい。ＥＭＲサーバ４００は、受信された識別情報に対応する患者情報を検索してよく、検索された患者情報を病院管理サーバ３００に伝送してよい。

なお、ユーザ端末装置１００は、症状情報を受付管理サーバ５００に伝送してよく、受付管理サーバ５００は受信された症状情報を待機番号とともに病院管理サーバ３００に伝送してよい。

結果的に、病院管理サーバ３００は、受付管理サーバ５００から症状情報を受信してよく、アプリケーションサーバ２００から識別情報を受信してよい。

一方、図７において開示する動作に対する具体的な説明は、図３及び図５の動作に対応してよい。よって、図３及び図５と重複する説明については、詳細な説明を省略する。

図８は、図７の実施形態を説明するためのフローチャートである。

図８を参照すると、ステップＳ８０５、Ｓ８１０、Ｓ８１５、Ｓ８２０、Ｓ８２５、Ｓ８３０、Ｓ８３５、Ｓ８４０、Ｓ８４５の動作は、図６ステップＳ６０５、Ｓ６１０、Ｓ６１５、Ｓ６２０、Ｓ６２５、Ｓ６３０、Ｓ６３５、Ｓ６４０、Ｓ６４５の動作に対応してよい。よって、図６と重複する説明は、その記載を省略する。

図８のユーザ端末装置１００は、待機番号を要請すると判断すると、待機番号の要請及び症状情報を受付管理サーバ５００に伝送してよい（Ｓ８５０）。なお、受付管理サーバ５００は、ユーザが来院したか否かを判断してよい（Ｓ８５５）。なお、ユーザが来院したと判断されると、受付管理サーバ５００は待機番号をユーザ端末装置１００に割り当て、割り当てられた待機番号及び症状情報を組み合わせて待機者情報を生成してよい（Ｓ８６０）。そして、受付管理サーバ５００は、待機番号をユーザ端末装置１００に伝送してよい（Ｓ８６５）。そして、ユーザ端末装置１００は、受信された待機番号をディスプレイに表示してよい（Ｓ８７０）。

一方、受付管理サーバ５００は、ステップＳ８６０を介して組み合わせられた待機者情報を病院管理サーバ３００に伝送してよい（Ｓ８７５）。そして、病院管理サーバ３００は、患者情報及び待機者情報をマッピングしてよい（Ｓ８８０）。

一方、図８において開示する動作に対する具体的な説明は、図４及び図６の動作に対応してよい。よって、図４及び図６と重複する説明については、詳細な説明を省略する。

図９は、病院で患者を管理する複数の段階を説明するためのフローチャートである。

図９を参照すると、患者診察システム１０００は、予約段階（Ｓ９００）、受付段階（Ｓ９１０）、診察段階（Ｓ９２０）及び処方段階（Ｓ９３０）を含んでよい。

予約段階（Ｓ９００）は、患者が直接来院する前に、予約対象及び予約時間を決定する段階を意味してよい。予約対象は、診察病院、診療科又は医師のうち、少なくとも一つを含んでよく、予約時間は診察時間又は検査時間のうちいずれか一方を含んでよい。

なお、予約段階（S９００）は、予約対象及び予約時間を決定する多様な実施形態を含んでよい。一実施形態によって、ユーザが直接予約対象及び予約時間を決定してよい。別の実施形態によって、症状を入力すると、自動的に診療科、診察病院、診察時間及び検査時間のうち、少なくとも一つが決定されてよい。

受付段階（Ｓ９１０）は、患者が実際に来院した場合、診察順を決定する段階を意味してよい。受付段階（Ｓ９１０）は、患者が予約をした場合と、患者が予約をしていない場合とを区分し、診察順を決定してよい。患者が予約をしていない場合、別途の待機番号の要請がある場合にのみ、待機番号をユーザに与えてよい。ここで、別途の待機番号の要請は、病院のアプリケーションを用いて待機番号を要請する形態で実現されるか、直接受付カウンターで口頭で要請する形態で実現されてよい。

一方、受付段階は、待機番号札をとる過程で実現されてよい。ここで、待機番号札を提供する装置は、病院管理サーバ３００又は受付管理サーバ５００と時間情報が同期化された状態であってよい。

診察段階（Ｓ９２０）は、医師が患者を診察する段階を意味してよい。医師の利用する電子装置は、内部のデータベースから患者情報を受信してよく、内部のデータベースの他に別途のサーバから待機者情報を受信してよい。患者情報は、ユーザに対応する識別情報を含んでよく、待機者情報はユーザに対応する症状情報を含んでよい。そして、患者情報及び待機者情報は、多様な実施形態によってマッピングされてよい。一実施形態によって、患者情報及び待機者情報は、待機番号に基づいて自動的にマッピングされてよい。別の実施形態によって、患者情報及び待機者情報は、医師の入力に基づいてマッピングされてよい。

処方段階（Ｓ９３０）は、医師が患者情報及び待機者情報に基づいて患者に対応する処方を出すことを意味する。具体的に、医師は処方情報を病院管理サーバ３００に入力してよい。そして、処方情報のうち、一部の情報を患者に伝送してよい。

図１０は、患者を管理する複数の段階のうち、一実施形態に係る予約段階を説明するためのフローチャートである。

図１０を参照すると、予約段階（Ｓ９００）は、アプリケーションのログイン段階（Ｓ９０１）、診察病院、診療科、診察時間又は担当医を選択する段階（Ｓ９０２）、予約を確定する段階（Ｓ９０３）を含んでよい。

アプリケーションのログイン段階（Ｓ９０１）は、病院に関連するアプリケーションにユーザ固有のＩＤを用いてアクセス権限を獲得することを意味してよい。ここで、ログイン方式は、予め保存された固有のＩＤ及びパスワードを用いる方式、携帯電話による本人認証方式、生体情報認証方式など、多様な本人認証方式が適用されてよい。

診察病院、診療科、診察時間又は担当医のうち、少なくとも一つを選択する段階（Ｓ９０２）は、多様な実施形態が適用されてよい。

一実施形態によって、ユーザが直接診察病院、診療科、診察時間又は担当医のうち少なくとも一つを検索してよい。ユーザが診察病院、診療科、診察時間又は担当医のうち、少なくとも一つを直接入力し、ユーザ端末装置１００は、入力された情報を予約に必要な情報として獲得してよい。

別の実施形態によって、ユーザ端末装置１００は、ユーザに複数の選択項目ＵＩを提供し、ユーザが複数の選択項目ＵＩのうち、特定の項目ＵＩを選択するようにガイドしてよい。

ユーザ端末装置１００は、診療科に対する複数の選択項目ＵＩを提供してよい。ユーザが症状を入力すると、ユーザ端末装置１００は、症状に対する診療科を分析してよい。そして、ユーザ端末装置１００は、分析された結果に基づいて少なくとも一つの診療科を項目ＵＩに提供してよい。そして、提供された項目ＵＩがユーザの意図に合っているか確認することができる。

なお、ユーザ端末装置１００は、診察病院に対する複数の選択項目ＵＩを提供してよい。具体的に、ユーザ端末装置１００は、現在のユーザ端末装置１００のＧＰＳ位置情報、予め保存されたＧＰＳ位置情報（例えば、自宅、会社）、最近の受診履歴情報のうち、少なくとも一つに基づいて診察病院に対する複数の選択項目ＵＩを提供してよい。

なお、ユーザ端末装置１００は、診察時間に対する複数の選択項目ＵＩを提供してよい。ユーザ端末装置１００は、病院管理サーバ３００と情報を交換することで、病院に予約可能な時間情報を要請してよく、病院管理サーバ３００から予約可能な時間情報を獲得してよい。そして、ユーザ端末装置１００は、獲得された予約可能な時間情報を複数の選択項目ＵＩを提供してよい。

一方、提供された複数の項目ＵＩのうち、特定の項目ＵＩに対するユーザ入力が受信されると、ユーザ端末装置１００は、受信された特定の項目に対応する情報を予約に必要な情報として獲得してよい。

なお、ユーザ端末装置１００は、ユーザの過去の受診履歴情報に基づいて複数のリストを表示し、複数のリストのうち、ユーザの選択した項目を予約に必要な情報として獲得してよい。ユーザの過去の受診履歴情報を用いる実施形態は、図１１及び図１２を参照して具体的に説明する。

予約を確定する段階（Ｓ９０３）は、ユーザ端末装置１００が予約に必要な情報を病院管理サーバ３００に伝送し、ユーザ端末装置１００が病院管理サーバ３００から最終予約情報を獲得することを意味してよい。

図１１は、過去履歴情報を用いて予約段階を行う実施形態を説明するための図である。

図１１を参照すると、表１１０５は、ユーザの過去の受診履歴情報を意味してよい。そして、表１１１０は、表１１０５を分析した結果を意味してよい。ユーザ端末装置１００は、ユーザの過去の受診履歴情報に基づいて最近受診した病院、最多受診した病院又は過去受診した病院のうち少なくとも一つを識別してよい。ここで、過去受診病院は、最多受診病院の他に、別の情報に基づいてユーザにおすすめする病院を意味してよい。例えば、最多受診病院は、データに保存された特定の臨界期間（例えば、５カ月）で最も多く受診した病院を意味してよく、過去受診病院は、データに保存された全期間で最も多く受診した病院を意味してよい。

ユーザ端末装置１００は、過去受診履歴情報のうち、日付情報に基づいて最近受診日を識別し、識別された最近受診日に対応する病院を識別し、最近受診病院として決定してよい。なお、ユーザ端末装置１００は、臨界期間（例えば、５カ月）の過去受診履歴情報を分析して最多受診病院を獲得してよい。

そして、ユーザ端末装置１００は、識別された最近受診病院、最多受診病院又は過去受診病院のうち、少なくとも一つを項目ＵＩとして提供してよい。

一方、表１１０５及び表１１１０では、日付、病院、診療科、病名などを表示しているが、それは例示的なものに過ぎず、別の情報が含まれてよい。

図１２は、図１１の実施形態に係るＵＩを説明するための図である。

図１２を参照すると、ユーザ端末装置１００は、ユーザに受診しようとする病院情報を入力するようにガイドするＵＩを提供してよい（１２０５）。なお、ユーザ端末装置１００は、複数の項目ＵＩを表示してユーザが特定の項目を選択するようにガイドしてよい。具体的に、複数の項目ＵＩは、最近受診病院に対応するＵＩ１２１０、最多受診病院に対応するＵＩ１２１５、過去受診病院に対応するＵＩ１２２０、現在位置の周辺にある病院に対応するＵＩ１２２５、ユーザが直接病院を入力するＵＩ１２３０のうち、少なくとも一つを含んでよい。

ここで、現在位置の周辺にある病院に対応するＵＩのために、ユーザ端末装置１００は、位置情報を外部サーバに伝送してよく、外部サーバから位置情報に対応する病院情報を受信してよい。

図１３は、患者を管理する複数の段階のうち、別の実施形態に係る予約段階を説明するためのフローチャートである。

図１３を参照すると、予約段階（Ｓ９００）中のログイン段階（Ｓ９０１）及び予約確定段階（Ｓ９０３）は、図１０で記載しているため、繰り返し説明は省略する。予約段階（Ｓ９００）は、ユーザの症状情報を入力される段階（Ｓ９０２－１）、診療科を決定する段階（Ｓ９０２－２）、診察病院、診察時間又は担当医のうち、少なくとも一つを選択する段階（Ｓ９０２－３）を含んでよい。

ユーザの症状情報を入力される段階（Ｓ９０２－１）は、ユーザが入力する症状情報を受信する段階を意味してよい。ユーザ端末装置１００は、ユーザが症状情報を入力することができるようにガイドするＵＩを表示してよい。なお、ユーザ端末装置１００は、ユーザインターフェース１５０を介してユーザの入力した症状情報を受信してよい。

診療科を決定する段階（Ｓ９０２－２）は、受信された症状情報に基づいて自動的に診療科を識別することを意味してよい。ユーザ端末装置１００は、予め保存されたルックアップテーブルに基づいて受信された症状情報に対応する診療科を決定してよい。ここで、識別される診療科は少なくとも一つであってよい。複数の診療科が識別される場合、ユーザ端末装置１００は、最も正確度の高い結果が優先してディスプレイに表示されてよい。

一例として、予め保存されたルックアップテーブルは、ユーザ端末装置１００に保存されてよい。ここで、ユーザ端末装置１００は、内部メモリに保存された情報に基づいて診療科を決定してよい。

別の例として、予め保存されたルックアップテーブルは、アプリケーションサーバに保存されたものであってよい。よって、ユーザ端末装置１００は、受信された症状情報をアプリケーションサーバ２００に伝送してよく、アプリケーションサーバ２００は受信された症状情報に基づいて診療科を決定してよい。そして、決定された診療科をユーザ端末装置１００に伝送してよい。ここで、ユーザ端末装置１００は、症状情報をアプリケーションサーバ２００に伝送する過程で識別情報を伝送しなくてよい。症状情報がアプリケーションサーバ２００に伝送される場合、個人情報が漏洩する可能性があるため、症状情報をアプリケーションサーバ２００に伝送する場合、ユーザ端末装置１００は、識別情報を除き症状情報のみでアプリケーションサーバ２００に伝送してよい。

診察病院、診察時間又は担当医のうち少なくとも一つを選択する段階（Ｓ９０２－３）は、診療科が決まった後で、予約に必要な詳細情報を獲得することを意味してよい。

図１４は、図１３の実施形態に係るＵＩを説明するための図である。

図１４を参照すると、ユーザ端末装置１００は、症状情報を入力されるようにガイドするＵＩ１４０５をディスプレイに表示してよい。そして、ユーザ端末装置１００は、複数の項目ＵＩをディスプレイに表示してよい。ここで、複数の項目ＵＩは、最近診断された病名に対応するＵＩ１４１０、最多診断された病名に対応するＵＩ１４１５、過去に診断された病名に対応するＵＩ１４２０、ユーザが直接症状を入力するＵＩ１４２５のうち、少なくとも一つを含んでよい。

一方、複数の項目ＵＩ１４１０、１４１５、１４２０に表示される情報（骨折、アレルギー、風邪）は、図１１の表１１０５に含まれた情報に基づいたものであってよい。

図１５は、患者を管理する複数の段階のうち、受付段階を説明するためのフローチャートである。

図１５を参照すると、受付段階（Ｓ９１０）は、来院したか否かの判断段階（Ｓ９１１）及び待機番号の付与段階（Ｓ９１２）を含んでよい。

来院したか否かの判断段階（Ｓ９１１）は、待機番号を要請したユーザ（又は患者）が来院したか否かを判断する動作を意味してよい。待機番号を遠隔から付与する場合、ユーザが病院の近くにいないのに無駄に待機番号が付与されるという問題が発生しかねない。よって、病院管理サーバ３００は、特定の条件のもとのみで患者に待機番号を与えてよい。来院したか否かへの判断に対する具体的な動作は、図１６及び図１７を参照して後述する。

待機番号の付与段階（Ｓ９１２）は、受付番号を付与する段階を意味してよい。そして、病院管理サーバ３００は、待機番号及び症状情報に基づいて診察順を決定してよい。

患者Ａ、Ｂ、Ｃの診察順を決めるとする。患者の情報は、以下の通りである。

「患者Ａ：待機番号１、ＶＡＳ痛みの評価３（どちらかというと痛む）、発病日：５カ月前から、診察予定時間までの残り時間：５分」

「患者Ｂ：待機番号２、ＶＡＳ痛みの評価６（中間ほどの痛み）、発病日：１週間前から、診察予定時間までの残り時間：２０分」

「患者Ｃ：待機番号３、ＶＡＳ痛みの評価９（ひどく痛む）、発病日：当日、１０メールの高さから落下、診察予定時間までの残り時間：４０分」

病院管理サーバ３００は、待機番号及び症状情報に基づいて診察順を決定してよい。

一実施形態によって、病院管理サーバ３００は、待機番号を考慮して診察順を決定してよい。具体的に、病院管理サーバ３００は、待機番号の順番に応じて、上述の仮定で待機番号１、２、３の順で診察順を決定してよい。

別の実施形態によって、病院管理サーバ３００は、症状情報（又は、痛み情報）を考慮して診察順を決定してよい。この場合、病院管理サーバ３００は、待機番号３、２、１の順で診察順を決定してよい。

更に別の実施形態によって、病院管理サーバ３００は、診察順を決定するうえで、優先順位が必要な患者を考慮して診察順を決定してよい。上述の例示において、待機番号が１０番の患者Ｄがあってよい。患者Ｄは、優先順位が必要な患者であってよい。例えば、患者Ｄは、治療が急がれる急患や乱暴な患者であってよい。病院管理サーバ３００は、患者Ｄに待機番号によらず、優先順位を与えて診察順を決定してよい。病院管理サーバ３００は、結果的に１０、３、２、１の順で診察順を決定してよい。

一方、待機番号に関連し、病院管理サーバ３００が関連動作を行うものとして記載しているが、受付管理サーバ５００が関連動作を行う形態で実現されてよい。ここで、受付管理サーバ５００は、ディスプレイを更に含んでよく、受付管理サーバ５００はディスプレイに診察順を表示してよい。そして、患者Ｄのように、やむを得ず優先しなければならない状況が発生すると、ご了承のお知らせを提供してよい。

一方、別の実施形態に係る待機番号の付与段階（Ｓ９１２）は、患者が来院したと判断した場合、待機番号を付与する動作を意味してよい。待機番号は、対象情報、時間情報、順番情報、救急情報のうち、少なくとも一つを含んでよい。対象情報は、診察病院、診療科、担当医のうち少なくとも一つの情報を含んでよい。ユーザは、対象情報に基づいてどの診療科のどの担当医の待機の順番かを把握してよい。時間情報は、待機番号の与えられた時間、待機予想時間情報のうち、少なくとも一つを含んでよい。順番情報は、現在の待機の順番に関連する情報を意味してよい。救急情報は、現在の患者が急患か否かを示す情報を意味してよい。もし、順位が後ろの患者であっても、急患として区分される場合、優先して受診できるようにするためである。救急情報は、症状情報、患者の要請、病院スタッフの要請のうち、少なくとも一つに基づいて決定されてよい。

図１６は、位置情報を用いて待機番号を伝送する実施形態を説明するための図である。

一実施形態によって、ユーザが病院の予約を確定した場合、ユーザ端末装置１００は、予約情報をメモリに保存してよい。そして、ユーザ端末装置１００は、予約情報に含まれた予約時間に基づいて、ＧＰＳ機能を活性化させることができる。そして、ユーザ端末装置１００は、位置情報を病院管理サーバ３００に伝送してよい。病院管理サーバ３００は、位置情報に基づいて、ユーザが現在病院の近くにいるかを判断してよい。

別の実施形態によって、ユーザが病院の予約をしていない場合、ユーザ端末装置１００は、ユーザの待機番号要請に基づいて位置情報を病院管理サーバ３００に伝送してよい。病院管理サーバ３００は、予約情報がない場合でも、ユーザ端末装置１００から位置情報が受信されると、ユーザが現在病院の近くにいるかを判断してよい。

特定の病院１６０５の病院管理サーバ３００が、ユーザ１６１５の位置情報が病院の位置から臨界距離内１６１０（例えば、１００メートル）にいると判断すると、病院管理サーバ３００は、ユーザ端末装置１００に待機番号をユーザ端末装置１００に伝送してよい。病院管理サーバ３００は、位置情報に基づいて、ユーザ１６１５の位置情報が病院の位置から臨界距離以上離れていると判断すると、病院管理サーバ３００は、待機番号を与えなくてよい。ここで、病院管理サーバ３００は、ユーザ端末装置１００に予約をキャンセルするか否かを問うＵＩを表示するように制御する信号を、ユーザ端末装置１００に伝送してよい。病院管理サーバ３００は、ユーザの応答がないか、予約のキャンセル命令を受信すると、予約をキャンセルしてよい。

図１７は、図１６の実施形態の具体的な方法を説明するためのフローチャートである。

図１７を参照すると、患者が病院の予約を確定した実施形態を仮定する。病院管理サーバ３００は、予約時間の臨界時間前からユーザ端末装置１００のＧＰＳモジュールを制御してよい（Ｓ１７０５）。例えば、予約時間が午後２時で臨界時間が１５分であれば、病院管理サーバ３００は、午後１時４５分からユーザ端末装置１００のＧＰＳモジュールを制御してよい。ここで、ユーザ端末装置１００のＧＰＳモジュールを制御するとは、病院管理サーバ３００がＧＰＳ情報を要請する制御命令をユーザ端末装置１００に伝送することを意味してよい。そして、ユーザ端末装置１００は、ＧＰＳ情報を要請する制御命令を受信し、ＧＰＳ情報を獲得してよく、獲得されたＧＰＳ情報を病院管理サーバ３００に伝送してよい。

そして、病院管理サーバ３００は、ユーザ端末装置１００から位置情報を獲得してよい（Ｓ１７１０）。

そして、病院管理サーバ３００は、予約時間後予め設定された時間が経過したかを判断してよい（Ｓ１７１５）。例えば、予約時間が午後２時で予め設定された時間が２０分であれば、病院管理サーバ３００は、午後２時２０分が経過しているか否かを判断してよい。ここで、予約時間後予め設定された時間が経過すると、病院管理サーバ３００は、予約をキャンセルしてよい（Ｓ１７１６）。予約時間後予め設定された時間が経過していない場合、病院管理サーバ３００は、受信されたユーザ端末装置１００の位置情報が予約された病院の近くかを判断してよい（Ｓ１７２０）。

ユーザ端末装置１００の位置情報が予約された病院の近くではないと判断されると、病院管理サーバ３００は、引き続きユーザ端末装置１００から位置情報を受信してよい。一方、ユーザ端末装置１００の位置情報が予約された病院の近くであると判断されると、病院管理サーバ３００は、待機番号を生成してよい（Ｓ１７２５）。

一方、待機番号を生成するか、待機番号をキャンセルする場合、ユーザの確認が必要になってよい。

図１８は、順番報知情報を伝送する一実施形態を説明するためのフローチャートである。

図１８を参照すると、ステップＳ１８０５、Ｓ１８１０、Ｓ１８１５、Ｓ１８２０、Ｓ１８２５、Ｓ１８３０、Ｓ１８３５、Ｓ１８４０、Ｓ１８４５、Ｓ１８５０、Ｓ１８５５、Ｓ１８６０、Ｓ１８６５、Ｓ１８７０は、図４のステップＳ４０５、Ｓ４１０、Ｓ４１５、Ｓ４２０、Ｓ４２５、Ｓ４３０、Ｓ４３５、Ｓ４４０、Ｓ４４５、Ｓ４５０、Ｓ４５５、Ｓ４６０、Ｓ４６５、Ｓ４７０に対応してよい。よって、重複する説明の記載を省略する。

病院管理サーバ３００は、ステップＳ１８５０に基づいて、ユーザ端末装置１００の位置情報が病院の近くかを判断してよい。そして、ユーザ端末装置１００の位置情報が病院の近くであれば、ユーザ端末装置１００に待機番号を割り当ててよい。そして、病院管理サーバ３００は、現在の診察順がユーザ端末装置１００に割り当てられた待機番号の順番かを判断してよい（Ｓ１８７５）。もし、現在の診察順がユーザ端末装置１００に割り当てられた待機番号の順番ではない場合、病院管理サーバ３００は、ユーザ端末装置１００に割り当てられた待機番号の順番がくるまで引き続き診察順をモニタリングしてよい。

病院管理サーバ３００は、ステップＳ１８５０に基づいて、ユーザ端末装置１００の位置情報が病院の近くでれば、ＥＭＲサーバ４００から最新の病院登録番号を受信（又は同期化）してよい。ＥＭＲサーバ４００に保存された病院登録番号は信頼性の高いデータであってよい。しかし、毎回ＥＭＲサーバ４００に病院登録番号の同期化を試みる場合、実際に来院していない患者の情報がＥＭＲサーバ４００にアップデートされてよい。このような状況で、不要なＥＭＲサーバ４００へのアクセスを防止するために、病院管理サーバ３００は、ユーザ端末装置１００の位置情報が病院の近くである場合に限って、最新の病院登録番号をＥＭＲサーバ４００から受信してよい。

一方、ユーザ端末装置１００に割り当てられた待機番号の順番が到来した場合、病院管理サーバ３００は、ユーザ端末装置１００に順番報知情報を提供してよい（Ｓ１８８０）。なお、ユーザ端末装置１００は、受信した順番報知情報をディスプレイに表示してよい（Ｓ１８８５）。

図１９は、順番報知情報を伝送する別の実施形態を説明するためのフローチャートである。

図１９を参照すると、ステップＳ１９０５、Ｓ１９１０、Ｓ１９１５、Ｓ１９２０、Ｓ１９２５、Ｓ１９３０、Ｓ１９３５、Ｓ１９４０、Ｓ１９４５、Ｓ１９５０、Ｓ１９５５、Ｓ１９６０、Ｓ１９６５、Ｓ１９７５、Ｓ１９８０は、図８のステップＳ８０５、Ｓ８１０、Ｓ８１５、Ｓ８２０、Ｓ８２５、Ｓ８３０、Ｓ８３５、Ｓ８４０、Ｓ８４５、Ｓ８５０、Ｓ８５５、Ｓ８６０、Ｓ８６５、Ｓ８７５、Ｓ８８０に対応してよい。よって、重複する説明の記載を省略する。

受付管理サーバ５００は、ステップＳ１９５５に基づいて、ユーザ端末装置１００の位置情報が病院の近くかを判断してよい。そして、ユーザ端末装置１００の位置情報が病院の近くであれば、ユーザ端末装置１００に待機番号を割り当ててよい。そして、受付管理サーバ５００は、現在の診察順がユーザ端末装置１００に割り当てられた待機番号の順番かを判断してよい（Ｓ１９８５）。もし、現在の診察順がユーザ端末装置１００に割り当てられた待機番号の順番ではない場合、受付管理サーバ５００は、ユーザ端末装置１００に割り当てられた待機番号の順番がくるまで引き続き診察順をモニタリングしてよい。

一方、ユーザ端末装置１００に割り当てられた待機番号の順番が到来した場合、受付管理サーバ５００は、ユーザ端末装置１００に順番報知情報を提供してよい（Ｓ１９９０）。なお、ユーザ端末装置１００は、受信した順番報知情報をディスプレイに表示してよい（Ｓ１９９５）。

図２０は、患者を管理する複数の段階のうち、診察段階を説明するためのフローチャートである。

図２０を参照すると、診察段階（Ｓ９２０）は、患者情報を受信する段階（Ｓ９２１）、待機者情報を受信する段階（Ｓ９２２）、患者情報及び待機者情報をマッピングする段階（Ｓ９２３）を含んでよい。

患者情報を受信する段階（Ｓ９２１）は、アプリケーションサーバ２００から受信した識別情報に対応する患者に関する情報を獲得することを意味してよい。例えば、病院管理サーバ３００は、アプリケーションサーバ２００から識別情報（氏名：山田 太郎、生年月日：９０年１月１日）を受信し、識別情報に対応する患者情報を病院管理サーバ３００の内部データベース又はＥＭＲサーバ４００から獲得してよい。患者が再診である場合、病院管理サーバ３００は、予め保存された患者情報を獲得してよい。患者が新患（新規の患者）の場合、病院管理サーバ３００は、新たな患者情報を獲得してよい。

待機者情報を受信する段階（Ｓ９２２）は、ユーザ端末装置１００から症状情報及び待機番号を受信する動作を意味してよい。待機者情報は、患者の症状情報及び待機番号が含まれてよい。症状情報は、ユーザ端末装置１００のユーザインターフェース１５０によって入力された情報であってよく、待機番号は病院管理サーバ３００又は受付管理サーバ５００から獲得した情報であってよい。一方、病院管理サーバ３００が待機者情報に含まれた待機番号及び症状情報をまとめて受信するものとして記載しているが、実際の実現の際は、待機番号と症状情報とを異なる時点で受信する形態で実現されてよい。ここで、症状情報は、多様な通信方式によって病院管理サーバ３００に伝送されてよい。一例として、症状情報は、近距離無線通信（例えば、ＮＦＣ通信）に基づいて病院管理サーバ３００に伝送されてよい。

病院管理サーバ３００は、受信された症状情報と待機番号とを組み合わせてよい。ここで、組み合わせの意味は、症状情報と待機番号とを一つのデータグループにグルーピングする動作を意味してよい。即ち、病院管理サーバ３００は、複数の端末装置から複数の症状情報を受信してよい。ここで、病院管理サーバ３００は、複数の症状情報がどの患者に対応するのかを識別する必要があるが、病院管理サーバ３００は、患者の氏名の代わりに待機番号を基準に識別してよい。例えば、病院管理サーバ３００は、待機番号（＃００５）と症状情報（手首のしびれ）とを一つのデータグループ（待機者情報）にグルーピングし、病院管理サーバ３００のメモリに保存してよい。そして、病院管理サーバ３００は、グルーピングされた待機者情報を病院管理サーバ３００に接続されたディスプレイ装置６００に伝送してよい。ここで、ディスプレイ装置６００は、担当医のパソコンであってよい。

患者情報及び待機者情報をマッピングする段階（S９２３）は、待機者情報に対応する患者情報を識別する動作を意味してよい。病院管理サーバ３００は、複数の患者情報を保存していてよく、現在少なくとも診察を待っている複数の患者情報を識別してよい。患者情報には、個人識別情報が含まれているため、複数の患者のうち、どの患者に対応する情報かを簡単に識別することができる。しかし、待機者情報は、待機番号及び症状情報で構成されている側面から、待機者情報がどの患者に対応する情報かを簡単に識別することは困難である。病院管理サーバ３００は、待機者情報がどの患者に対する情報かを判断する動作を行うことができる。多様なマッピング動作については、図２１ないし図２４を参照して具体的に説明する。

図２１は、患者情報と待機者情報とをマッピングする一実施形態を説明するための図である。

図２１を参照すると、ステップＳ２１０５、Ｓ２１１０、Ｓ２１１５、Ｓ２１２０、Ｓ２１２５、Ｓ２１３０、Ｓ２１３５、Ｓ２１４０、Ｓ２１４５、Ｓ２１５０、Ｓ２１５５、Ｓ２１６０、Ｓ２１６５は、図４のステップＳ４０５、Ｓ４１０、Ｓ４１５、Ｓ４２０、Ｓ４２５、Ｓ４３０、Ｓ４３５、Ｓ４４０、Ｓ４４５、Ｓ４５０、Ｓ４５５、Ｓ４６０、Ｓ４６５に対応してよい。よって、重複する説明の記載を省略する。

ユーザ端末装置１００は、病院管理サーバ３００から待機番号を受信してよく、受信された待機番号をディスプレイに表示してよい。そして、ユーザ端末装置１００は、受信された待機番号をアプリケーションサーバ２００に伝送してよい（Ｓ２１７０）。なお、アプリケーションサーバ２００は、予め保存された識別情報と受信された待機番号とを組み合わせてよい（Ｓ２１７５）。ここで、組み合わせるとは、識別情報と待機番号とを一つのデータグループにグルーピングすることを意味してよい。なお、アプリケーションサーバ２００は、組み合わせられた識別情報及び待機番号を病院管理サーバ３００に伝送してよい（Ｓ２１８０）。なお、病院管理サーバ３００は、組み合わせられた識別情報及び待機番号に基づいて、患者情報と待機者情報とをマッピングしてよい（Ｓ２１８５）。マッピング動作の過程については、図２２を参照して後述する。一方、アプリケーションサーバ２００で組み合わせ動作が行われる場合、ユーザの同意が必要になってよい。ここで、ユーザの同意に関連する処理動作は、ユーザ端末装置１００を介して受信されてよい。

図２２は、図２１の実施形態で伝送される情報を具体的に説明するための図である。

図２２を参照すると、ユーザ端末装置１００は、アプリケーションサーバ２００に予約要請及び識別情報２２０５を伝送してよい（Ｓ２１０５）。例えば、識別情報２２０５は、「山田 太郎」のような患者名であってよい。アプリケーションサーバ２００は、受信された識別情報２２０５を病院管理サーバ３００に伝送してよい（Ｓ２１１０）。

なお、病院管理サーバ３００は、受信された識別情報２２１０に基づいて予約情報を生成してよい。なお、病院管理サーバ３００は、予約情報に対応する患者情報２２２０を生成してよい（Ｓ２１２０）。ここで、患者情報２２２０は、識別情報（例えば、山田 太郎）、年齢（例えば、３０）、性別（例えば、男）、初診／再診（例えば、初診）のうち、少なくとも一つを含んでよい。ここで、初診／再診は、新患／再診に置き換えられて実施されてよい。

なお、ユーザ端末装置１００は、ユーザ端末装置１００から待機番号要請及び症状情報２２４５を病院管理サーバ３００に伝送してよい（Ｓ２１４５）。ここで、症状情報２２４５は、「手首のしびれ」のような体の一部の症状に対する内容を含んでよい。

一方、病院管理サーバ３００は、患者が来院したかを判断し、待機番号を与えてよい。なお、病院管理サーバ３００は、待機番号及び症状情報を組み合わせ、待機者情報２２５５を生成してよい（Ｓ２１５５）。ここで、待機者情報２２５５は、待機番号（例えば、＃００５）及び症状情報（例えば、手首のしびれ）を含んでよい。

なお、病院管理サーバ３００は、ユーザ端末装置１００に待機番号２２６０を伝送してよい（Ｓ２１６０）。そして、ユーザ端末装置１００は、アプリケーションサーバ２００に待機番号２２６０を伝送してよい。

アプリケーションサーバ２００は、識別情報（又は、識別情報中の一部の情報）及び待機番号を組み合わせてマッピング基準データグループ２２７５を生成してよい（Ｓ２１７５）。なお、アプリケーションサーバ２００は、生成されたマッピング基準データグループ２２７５を病院管理サーバ３００に伝送してよい（Ｓ２１８０）。マッピング基準データグループとは、マッピング動作に利用され、基準情報として利用するデータグループを意味してよい。

なお、病院管理サーバ３００は、患者情報２２２０及び待機者情報２２５５をマッピングしてよい。病院管理サーバ３００は、複数の患者情報と複数の待機者情報とをメモリに保存していてよい。

マッピング動作において、病院管理サーバ３００は、アプリケーションサーバ２００から受信したデータグループ２２７５を用いてよい。病院管理サーバ３００は、データグループ２２７５に含まれた待機番号（＃００５）を獲得し、複数の待機者情報から獲得された待機番号（＃００５）に対応する待機者情報２２５５を獲得してよい。そして、病院管理サーバ３００は、データグループ２２７５に含まれた識別情報（山田 太郎）を獲得し、複数の患者情報の中から獲得された識別情報（山田 太郎）に対応する患者情報２２２０を獲得してよい。そして、病院管理サーバ３００は、獲得された待機者情報２２５５と獲得された患者情報２２２０とをマッピングし、新たなマッピング結果データグループ２２８５を生成してよい。ここで、マッピング結果データグループ２２８５は、待機番号（＃００５）、識別情報（山田 太郎）、年齢（３０）、性別（男）、新患／再診（新患）、症状情報（手首のしびれ）のうち、少なくとも一つを含んでよい。

図２２に係る患者診察システム１０００では、症状情報がアプリケーションサーバ２００を隔てずに病院管理サーバ３００に伝送されている。そして、症状情報が待機番号と組み合わせられているにも関わらず、マッピング基準データグループ２２７５に基づいて症状情報に対応する患者情報２２２０を獲得することができる。よって、本発明の患者診察システム１０００では、アプリケーションサーバ２００がハッキングをされても、症状情報が漏洩しなくて済む。

図２３は、患者情報と待機者情報とをマッピングする別の実施形態を説明するための図である。

図２３を参照すると、ステップＳ２３０５、Ｓ２３１０、Ｓ２３１５、Ｓ２３２０、Ｓ２３２５、Ｓ２３３０、Ｓ２３３５、Ｓ２３４０、Ｓ２３４５、Ｓ２３５０、Ｓ２３５５、Ｓ２３６０、Ｓ２３６５は、図４のステップＳ４０５、Ｓ４１０、Ｓ４１５、Ｓ４２０、Ｓ４２５、Ｓ４３０、Ｓ４３５、Ｓ４４０、Ｓ４４５、Ｓ４５０、Ｓ４５５、Ｓ４６０、Ｓ４６５に対応してよい。よって、重複する説明の記載を省略する。

ユーザ端末装置１００は、病院管理サーバ３００から待機番号を受信し、ディスプレイに表示してよい。ここで、ユーザ端末装置１００は、受信された待機番号と内部メモリに予め保存された識別情報とを組み合わせ、マッピング基準データグループを生成してよい（S２３７０）。図２１及び図２２では、待機番号と識別情報とを組み合わせる動作が、アプリケーションサーバ２００で行われる実施形態について記述している。しかし、実施形態によって、待機番号と識別情報とを組み合わせる動作は、ユーザ端末装置１００で行われてよい。識別情報は、ユーザ端末装置１００及びアプリケーションサーバ２００の両方に保存されていることがあるためである。一方、ユーザ端末装置１００で組み合わせ動作が行われる場合、ユーザの同意が必要になってよい。

ユーザ端末装置１００は、組み合わせられた識別情報及び待機番号（ステップＳ２３７０で生成したマッピング基準データグループ）を病院管理サーバ３００に伝送してよい（Ｓ２３７５）。なお、病院管理サーバ３００は、組み合わせられた識別情報及び待機番号に基づいて、患者情報及び待機者情報をマッピングし、マッピング結果データグループを生成してよい（Ｓ２３８０）。マッピング動作については、図２２を参照して具体的に説明しているため、重複する説明は省略する。

図２１ないし図２３は、病院管理サーバ３００で患者情報と待機者情報とをマッピング基準データグループを用いて自動的にマッピングする実施形態について説明している。しかし、別の実施形態によって、患者情報と待機者情報とが別途のマッピング基準データグループを用いずに、担当医によって直接マッピングされてよい。担当医によって直接マッピングされる実施形態については、図２４を参照して説明する。

図２４は、患者情報と待機者情報とをマッピングする更に別の実施形態を説明するための図である。

図２４を参照すると、病院管理サーバ３００は、ディスプレイ装置６００と接続されてよい。ディスプレイ装置６００は、病院管理サーバ３００から患者情報及び待機者情報を受信してよい。ここで、患者情報は、病院管理サーバ３００から受信される形態で記載している。ただ、実施形態によって、ディスプレイ装置６００は、患者情報をＥＭRサーバ４００から直接受信してよい。

そして、ディスプレイ装置６００は、受信された患者情報及び待機者情報を同時に一つの画面に表示してよい。具体的に、ディスプレイ装置６００は、一つの画面中の第１の領域２４０５に患者情報を表示してよく、一つの画面中の第１の領域２４０５と異なる第２の領域２４１０に待機者情報を表示してよい。

ここで、ディスプレイ装置６００は、病院管理サーバ３００から複数の患者情報を受信してよい。現在病院に受付完了され、来院中の患者に対応する複数の患者情報が病院管理サーバ３００から受信されると、ディスプレイ装置６００は、複数の患者情報に含まれた識別情報中の氏名情報を第１の領域２４０５に表示してよい。第１の領域に表示される患者情報は複数であってよいが、第２の領域２４１０に表示される待機者情報は一つであってよい。病院管理サーバ３００は、受付順又は診察順のうち少なくとも一方に基づいて、待機番号を与えてよく、受付順又は診察順のうち少なくとも一方に対応する待機番号は一つであってよい。よって、病院管理サーバ３００がディスプレイ装置６００に伝送する待機者情報は一つであってよい。よって、ディスプレイ装置６００の第２の領域２４１０に表示される待機者情報は一つであってよい。

担当医は、ディスプレイ装置６００に表示される待機者情報と患者情報とを直接マッピングしてよい。複数の患者情報のうち、どの患者情報が待機者情報に対応するか、担当医が直接判断してよい。担当医は患者の顔を覚えているが、患者に直接名前、生年月日又は症状情報を再度尋ねる形態で識別情報を知ることができ、直接患者情報と待機者情報とをマッピングしてよい。

図２５は、症状情報を同期化する一実施形態を説明するための図である。

図２５を参照すると、ディスプレイ装置６００は、病院管理サーバ３００からマッピング動作（Ｓ２１８５）に基づいて、一つの患者情報と一つの待機者情報とを獲得してよい。図２２では、マッピング結果データグループ２２８５を生成するものとして説明しているが、それは一実施形態に係る動作に過ぎず、マッピング動作は新たなデータグループを生成することではなく、単に特定の患者情報と特定の待機者情報とをマッピングすることのみを意味してよい。図２５では、特定の患者情報と特定の待機者情報とがマッピングされた状態のみを仮定した実施形態を記述する。

ディスプレイ装置６００は、病院管理サーバ３００から診察順に対応する待機者情報を受信し、受信された待機者情報を第２の領域２４１０に表示してよい。そして、ディスプレイ装置６００は、待機者情報とマッピングされた患者情報を病院管理サーバ３００から受信し、受信された患者情報を第１の領域２４０５に表示してよい。

ここで、症状情報は、待機者情報のみに含まれているため、第２の領域２４１０のみに症状情報が表示されてよい。ここで、ディスプレイ装置６００は、ＵＩ２５０５又はＵＩ２５１０のうち、少なくとも一つのＵＩを表示してよい。ＵＩ２５０５は、患者情報及び待機者情報の相互間で同期化対象項目を全て同期化させる機能に対応するＵＩであってよい。ディスプレイ装置６００がＵＩ２５０５を選択するユーザ入力を受信すると、ディスプレイ装置６００は同期化対象項目に対し、同期化動作を行ってよい。図２５で同期化項目は症状情報であってよい。図２５で開示する実施形態で同期化の優先順位は待機者情報にあってよい。即ち、患者情報の症状情報はデータが存在せず、待機者情報の症状情報にはデータが存在するため、待機者情報の症状情報（左手首のしびれ）を患者情報にも含めてよい。そして、ディスプレイ装置６００は、患者情報に含まれた症状情報（左手首のしびれ）を第１の領域２４０５の表示してよい。

一方、ＵＩ２５１０は、全ての同期化項目でない、特定の項目のみを同期化する機能に対応するＵＩであってよい。図２５では、同期化項目が症状情報の一つであるとして示しているが、実際の実現の際、同期化項目が複数であってよい。ＵＩ２５１０は、複数の同期化項目のうち、特定の項目（症状情報）を同期化する機能に対応するＵＩであってよい。

図２６は、症状情報を同期化する別の実施形態を説明するための図である。

図２６を参照すると、ディスプレイ装置６００は待機者情報に含まれた症状情報を同期化させるＵＩ２６０５を表示してよい。ＵＩ２６０５がユーザによって選択されると、ディスプレイ装置６００は待機者情報に含まれた症状情報を分析してよい。具体的に、ディスプレイ装置６００は、症状情報のテキストを分析し、身体情報及び痛み情報に区分してよい。例えば、症状情報が「左手首のしびれ」であれば、ディスプレイ装置６００は症状情報に基づいて身体情報（左手首）及び痛み情報（しびれ）を獲得してよい。ディスプレイ装置６００は、獲得した身体情報及び痛み情報に基づいて、人体模型のＵＩ２６１０を表示してよい。具体的に、人体模型のＵＩ２６１０に獲得した身体情報（左手首）の位置を簡単に知ることができるように、強調ＵＩ２６１５を表示してよい。なお、当該位置の近くに獲得した痛み情報（しびれ）を表示してよい。一方、ディスプレイ装置６００は、特定した痛み情報（しびれ）を医学用語（手根管症候群）に変換して表示してよい。医学用語に変更する動作は、身体情報及び痛み情報が全て考慮されてよい。

図２７は、患者を管理する複数の段階のうち、処方段階を説明するためのフローチャートである。

図２７を参照すると、処方段階（Ｓ９３０）は、処方情報を入力する段階（Ｓ９３１）及び処方情報及びサービス情報を伝送する段階（Ｓ９３２）を含んでよい。

処方情報を入力する段階（Ｓ９３１）は、病院管理サーバ３００が担当医の処方情報を受信する段階を意味してよい。担当医は、病院管理サーバ３００に患者を診察した後、処方情報を入力してよい。例えば、病院管理サーバ３００に接続されたディスプレイ装置６００に患者情報及び待機者情報が表示されていると仮定する。担当医は、ディスプレイ装置６００に表示された患者情報、待機者情報及び診察過程で獲得した情報をまとめてどのような処方を出すかを決定してよい。そして、ディスプレイ装置６００に接続されたユーザインターフェースを介して処方結果をディスプレイ装置６００に入力してよい。処方結果に或る情報（以後、処方情報という）は、ディスプレイ装置６００のメモリに保存されてよい。そして、ディスプレイ装置６００は、保存された処方情報を病院管理サーバ３００に伝送してよい。

処方情報又はサービス情報のうち少なくとも一方の情報を伝送する段階（S９３２）は、担当医が入力した処方情報を外部に伝送する動作を意味してよい。病院管理サーバ３００は、受信された処方情報をＥＭＲサーバ４００又はユーザ端末装置１００に伝送してよい。ＥＭＲサーバ４００は、処方情報を含む患者情報を病院管理サーバ３００から受信すると、新たな患者の診察内容を患者の病院登録番号に記録及びアップデートしてよい。ＥＭＲサーバ４００には、患者情報が送られるが、ユーザ端末装置１００には、患者情報に含まれた全ての情報を伝送しなくてよく、ユーザ端末装置１００には、処方情報又はサービス情報のうち少なくとも一方を伝送してよい。

ここで、サービス情報とは、患者が熟知すべき注意事項を意味してよい。例えば、サービス情報は、控えるべき食べ物、控えるべき運動、処方薬の服用量、処方薬の服用時間、予約情報、来院のおすすめ日などを含んでよい。来院の予約有無は診察過程で次回の来院に対する予約時間を決定した場合、それに対する結果を再度患者に通知することを意味してよい。そして、来院のおすすめ日は、来院に対する予約をしていないが、いつ頃来院するかをおすすめする日を意味してよい。一例として、病院管理サーバ３００は、「２～３日後来院をおすすめする」というサービス情報をユーザ端末装置１００に伝送してよい。

一方、病院管理サーバ３００がユーザ端末装置１００に処方情報又はサービス情報のうち、少なくとも一方をユーザ端末装置１００に伝送するために、処方情報と待機番号とを組み合わせてよい。ここで、組み合わせる動作は、処方情報と待機番号とを一つのデータグループにグルーピングすることを意味してよい。そして、処方情報と待機番号とを組み合わせることは、待機者情報に処方情報を追加することを意味してよい。

処方情報と識別情報とを組み合わせずに処方情報と待機番号とを組み合わせる理由は、処方情報がハッキングされるとしても、誰の処方情報か知ることが困難になるようにするためである。通常、診察後、ＥＭＲサーバ４００に伝送される患者情報は、識別情報及び処方情報が一つのデータグループにグルーピングして保存されてよい。しかし、ＥＭＲサーバ４００は、院内システムに保存されているだけで、別途のセキュリティプログラムが作動するという点で安定性が確保できるといえる。しかし、ユーザ端末装置１００に特定の情報を伝送することは、内部システムではない、外部システムに情報を伝送するという側面からセキュリティリスクがあるといえる。

よって、このようなセキュリティリスクを防止するために、病院管理サーバ３００は処方情報と識別情報とを組み合わせずに、処方情報と待機番号とを組み合わせてよい。待機者情報には、識別情報が存在せずに単に待機番号を与えたユーザ端末装置１００に対する情報のみを含まれてよい。

一方、病院管理サーバ３００は、待機番号をユーザ端末装置１００に伝送する段階で与えられた待機番号とユーザ端末装置１００をマッピングしてよく、マッピングされた待機番号及びユーザ端末装置１００を病院管理サーバ３００のメモリに保存してよい。病院管理サーバ３００は、マッピングされた待機番号及びユーザ端末装置１００に基づいてユーザ端末装置１００に待機者情報に含まれた処方情報を選択的に伝送してよい。なお、病院管理サーバ３００は、処方情報の他にサービス情報も併せてユーザ端末装置１００に伝送してよい。

一方、処方段階（Ｓ９３０）は、第１の処方情報と第２の処方情報とに区分されてよい。

第１の処方情報は患者が決済する前の段階で生成された最初の処方情報を意味してよく、第２の処方情報は患者が決済した後の段階で生成された処方情報を意味してよい。

病院管理サーバ３００は、第１の処方情報及び決済に関する情報をユーザ端末装置１００に伝送してよい。そして、患者は受信された第１の処方情報及び決済に関する情報に基づいて決済を行ってよい。ここで、第１の処方情報は、待機番号と組み合わせられてユーザ端末装置１００に伝送されてよい。

患者がユーザ端末装置１００で決済を完了した場合、ユーザ端末装置１００は決済が完了しているという情報を病院管理サーバ３００に伝送してよい。一方、別の実施形態によって、ユーザ端末装置１００は、アプリケーションサーバ２００を介して病院管理サーバ３００に決済完了情報を伝送してよい。

病院管理サーバ３００は、決済完了情報を受信し、第２の処方情報を生成してよい。そして、病院管理サーバ３００は、最終的に第２の処方情報をユーザ端末装置１００に伝送してよい。ここで、第２の処方情報は。待機番号と組み合わせられてユーザ端末装置１００に伝送されてよい。そして、病院管理サーバ３００は、第２の処方情報及び第２の処方情報に対応するサービス情報とをユーザ端末装置１００に伝送してよい。

例えば、第１の処方情報は、注射、薬物治療及びリハビリと仮定する。ここで、病院管理サーバ３００は、第１の処方情報をユーザ端末装置１００に伝送してよい。

一方、患者が病院から臨界距離以上離れるか、予め設定された時点（診察完了時点、決済完了時点又は患者が病院から臨界距離以上離れた時点）後、臨界時間以上の場合、病院管理サーバ３００は、処方情報又はサービス情報をユーザ端末装置１００に伝送してよい。

図２８は、処方情報を伝送する段階を説明するための図である。

図２８を参照すると、病院管理サーバ３００は、組み合わせられた識別情報及び待機番号に基づいて、患者情報及び待機者情報をマッピングしてよい（Ｓ２８０５）。患者情報及び待機者情報をマッピングする動作は、図２１ないし図２４を参照して記載しているため、繰り返し説明を省略する。

病院管理サーバ３００は、患者情報及び待機者情報をマッピングした後、処方情報を受信してよい（Ｓ２８１０）。病院管理サーバ３００は、受信された処方情報と待機番号とを組み合わせてよい（Ｓ２８１５）。ここで、処方情報と待機番号とを組み合わせることは、待機者情報に処方情報を追加して一つのデータグループを生成することを意味してよい。ここで、生成されるデータグループは、変更された待機者情報であってよい。変更された待機者情報には、処方情報、待機番号が含まれてよい。病院管理サーバ３００は、変更された待機者情報に基づいて、待機番号に対応するユーザ端末装置１００を識別してよい（Ｓ２８２０）。そして、病院管理サーバ３００は、識別されたユーザ端末装置１００に処方情報を伝送してよい（Ｓ２８２５）。一方、ステップＳ２８２５と異なる実施形態により、病院管理サーバ３００は、処方情報をアプリケーションサーバ２００に伝送し、アプリケーションサーバ２００からユーザ端末装置１００に処方情報を伝送する形態で実現されてよい。なお、病院管理サーバ３００は、組み合わせられた処方情報及び待機番号を臨界時間が経過してから削除してよい（Ｓ２８３０）。患者の診療記録に関連しては、患者情報が別途に保存されているため、病院管理サーバ３００は、組み合わせられた処方情報及び待機番号を引き続きメモリに保存する必要がなくなる。一方、ステップＳ２８３０では、臨界時間が経過した後で、処方情報が削除されるものとして記載しているが、実現例によって、病院管理サーバ３００は、処方情報をユーザ端末装置１００に伝送した後、直ちに組み合わせられた処方情報及び待機番号を削除してよい。

一方、待機番号は、日付情報を更に含んでよい。病院管理サーバ３００は、待機番号に含まれた日付情報が現在の病院管理サーバ３００で識別される日付情報を比較してよい。ここで、待機番号に含まれた日付情報が現在の病院管理サーバ３００の日付より前であれば、病院管理サーバ３００は待機番号を削除してよい。

一方、図２８では、病院管理サーバ３００が処方情報、患者情報、待機者情報を保存して管理する図３及び図４の実施形態を基に記述している。しかし、実施形態により、図５ないし図８の実施形態でも、処方情報に関連する動作が適用されてよい。

具体的に、患者診察システム１０００が、ユーザ端末装置１００、アプリケーションサーバ２００、病院管理サーバ３００、ＥＭＲサーバ４００、受付管理サーバ５００及びディスプレイ装置６００を含んでよい。

ここで、ディスプレイ装置６００は、病院管理サーバ３００に接続された装置を意味してよく、担当医の管理する装置を意味してよい。そして、ディスプレイ装置６００は、ユーザインターフェース（例えば、キーボード及びマウスなど）を更に含んでよく、ユーザインターフェースを介して担当医の処方情報を受信してよい。ここで、ディスプレイ装置６００は、受信された処方情報を患者情報及び待機者情報に追加してよい。従来の患者情報及び待機者情報には、処方情報が入力されていないが、ディスプレイ装置６００は、受信された処方情報をそれぞれの患者情報及び待機者情報に追加してよい。結局、患者情報及び待機者情報は、処方情報が追加されて変更されてよい。処方情報が追加された後の患者情報及び待機者情報を、変更された患者情報及び変更された待機者情報として記述する。変更された患者情報には、患者の症状情報、患者の処方情報、患者の識別情報のうち、少なくとも一つが含まれてよい。なお、変更された待機者情報には、患者の症状情報、患者の待機番号、患者の処方情報のうち、少なくとも一つが含まれてよい。変更された待機者情報は、図２８のステップＳ２８１５に対応してよい。

ディスプレイ装置６００は、変更された患者情報及び変更された待機者情報を病院管理サーバ３００に伝送してよい。病院管理サーバ３００は、変更された患者情報をＥＭＲサーバ４００に伝送してよい。ＥＭＲサーバ４００は、アップデートされた患者情報をメモリに保存してよい。

一方、病院管理サーバ３００は、受付管理サーバ５００に変更された待機者情報を伝送してよい。受付管理サーバ５００は、変更された待機者情報を受信してよく、変更された待機者情報で待機番号を識別してよい。そして、受付管理サーバ５００は、待機番号に対応するユーザ端末装置を識別してよい。受付管理サーバ５００は、待機番号を付与するステップにおいて、待機番号とユーザ端末装置をマッピングする機器情報を生成してメモリに保存してよい。受付管理サーバ５００は、複数の機器情報で変更された待機者情報から、識別された待機番号に対応するユーザ端末装置１００を識別してよい。そして、識別されたユーザ端末装置１００に変更された待機者情報に含まれた処方情報を伝送してよい。

図２９は、処方情報を同期化する一実施形態を説明するための図である。

図２９を参照すると、ディスプレイ装置６００は、処方情報を同期化させるＵＩ２９０５を表示してよい。ディスプレイ装置６００が、担当医の処方情報を受信すると、ディスプレイ装置６００は受信された処方情報を第１の領域２４０５に表示してよい。そして、ディスプレイ装置６００は、ＵＩ２９０５を選択する担当医の入力が受信されると、第１の領域２４０５に表示された処方情報を第２の領域２４１０に表示してよい。

なお、ディスプレイ装置６００は、処方情報のみを同期化するＵＩ２９１０を第２の領域２４１０に表示してよい。ディスプレイ装置６００は、ＵＩ２９１０を選択する担当医の入力が受信されると、第１の領域２４０５に表示された全ての処方情報を第２の領域２４１０に表示してよい。

なお、ディスプレイ装置６００は、受信された特定の処方情報を患者情報に追加し、従来の患者情報をアップデートしてよい。アップデートされた患者情報を変更された患者情報として記述する。ディスプレイ装置６００は、ＵＩ２９０５又はＵＩ２９１０を選択する担当医の入力が受信されると、変更された患者情報に含まれた処方情報（無痛注射、痛み止め３日）を待機者情報に追加してよい。追加された処方情報を含む待機者情報を変更された待機者情報として記述する。

図３０は、症状情報及び処方情報を同期化する実施形態を説明するための図である。

図３０を参照すると、ディスプレイ装置６００は、症状情報及び処方情報両方を同期化するＵＩ３００５、症状情報のみを同期化するＵＩ３０１０、処方情報のみを同期化するＵＩ３０１５のうち、少なくとも一つを表示してよい。

ＵＩ３００５を選択する担当医の入力が受信されると、ディスプレイ装置６００は、待機者情報に含まれた症状情報を患者情報に追加し、患者情報に含まれた処方情報を待機者情報に追加してよい。

なお、ＵＩ３０１０を選択する担当医の入力が受信されると、ディスプレイ装置６００は、待機者情報に含まれた症状情報のみを患者情報に追加してよい。

なお、ＵＩ３０１５を選択する担当医の入力が受信されると、ディスプレイ装置６００は、患者情報に含まれた症状情報のみを待機者情報に追加してよい。

多様な同期化ＵＩを提供する図３０の実施形態は、担当医の選択によって、症状情報、処方情報のうち少なくとも一方を同期化する動作を含むため、担当医のデータ管理を容易にすることができる。

図３１は、一実施形態に係るユーザ端末装置の制御方法を説明するためのフローチャートである。

図３１を参照すると、本実施形態に係るユーザ端末装置１００に動作を実行させるコンピュータで読み取り可能な媒体に保存されたアプリケーションにおいて、動作は、症状情報を入力されるためのＵＩ画面を提供するステップ（Ｓ３１０５）と、ＵＩ画面を介してユーザの症状情報が入力されると、症状情報及び待機番号の要請を病院管理サーバ３００に伝送するステップ（Ｓ３１１０）と、病院管理サーバ３００から待機番号の要請に対応する待機番号を受信し、受信された待機番号を含むＵＩ画面を提供するステップ（Ｓ３１１５）と、ユーザの識別情報をアプリケーションサーバ２００に伝送するステップ（Ｓ３１２０）と、アプリケーションサーバ２００がユーザの識別情報を病院管理サーバ３００に伝送するように制御するステップ（Ｓ３１２５）とを含んでよい。

ここで、病院管理サーバ３００に伝送された症状情報を含む第１のＵＩ画面、及びユーザの識別情報を含む第２のＵＩ画面が、病院管理サーバ３００と通信するディスプレイ装置６００に提供されてよい。

なお、動作は、病院の予約のためのＵＩ画面を提供するステップと、ＵＩ画面を介して病院の予約のための情報が入力されると、ユーザの識別情報及び病院の予約のための情報を、アプリケーションサーバ２００に伝送するステップと、アプリケーションサーバ２００から病院の予約情報が受信されると、受信された病院の予約情報を含むＵＩ画面を提供するステップとを更に含んでよく、予約情報は、予約時間を含んでよい。

ここで、動作は、予約時間より臨界時間前の時点から、ユーザ端末装置１００の位置情報を病院管理サーバ３００に伝送するステップと、病院管理サーバ３００から位置情報に対応する待機番号を受信すると、受信された待機番号を含むＵＩ画面を提供するステップとを更に含んでよい。

ここで、病院管理サーバ３００は、位置情報が病院の位置から臨界距離内であれば、順位の高い待機番号をユーザ端末装置１００に提供してよい。

なお、動作は、受信された待機番号をアプリケーションサーバ２００に伝送するステップと、アプリケーションサーバ２００が待機番号を病院管理サーバ３００に伝送するように制御するステップとを更に含んでよく、病院管理サーバ３００に伝送された症状情報及び待機番号を含む第１のＵＩ画面、及びユーザの識別情報及び待機番号を含む第２のＵＩ画面が、病院管理サーバ３００と通信するディスプレイ装置６００に提供されてよい。

なお、動作は、病院管理サーバ３００から処方情報を受信するステップと、受信された処方情報を含むＵＩ画面を提供するステップとを更に含んでよく、病院管理サーバ３００は、待機番号に基づいて処方情報を伝送するユーザ端末装置１００を識別してよく、識別されたユーザ端末装置１００に処方情報を伝送してよい。

一方、病院管理サーバ３００は、第１の病院管理サーバ及び第２の病院管理サーバを含んでよく、症状情報及び待機番号の要請は、第１の病院管理サーバに伝送されてよく、ユーザの識別情報は第２の病院管理サーバに伝送されてよい。

なお、症状情報は、第１の通信モジュールを介して病院管理サーバ３００に伝送されてよく、ユーザの識別情報は、第２の通信モジュールを介して病院管理サーバ３００に伝送されてよい。

ここで、動作は、病院管理サーバ３００から処方情報を受信するステップと、受信された処方情報を含むＵＩ画面を提供するステップとを含んでよく、処方情報は、第１の通信モジュールを介して病院管理サーバ３００から受信されてよい。

一方、図３１のようなアプリケーション動作は、図１又は図２の構成を有する電子装置上で実行されてよく、その他の構成を有する電子装置上でも実行されてよい。

一方、上述の本発明の多様な実施形態に係る方法は、従来の電子装置にインストール可能なアプリケーション形態で実現されてよい。

なお、上述の本発明の多様な実施形態に係る方法は、従来の電子装置に対するソフトウェアアップグレード、又はハードウェアアップグレードのみでも実現されてよい。

なお、上述の本発明の多様な実施形態は、電子装置に備えられたエンベデッドサーバ、又は電子装置及びディスプレイ装置のうち少なくとも一方の外部サーバを介して実行されることも可能である。

一方、本発明の一実施形態によると、以上で説明された多様な実施形態は、機器（ｍａｃｈｉｎｅ）（例えば、コンピュータ）で読み取れる保存媒体（ｍａｃｈｉｎｅ－ｒｅａｄａｂｌｅ ｓｔｏｒａｇｅ ｍｅｄｉａ）に保存された命令語を含むソフトウェアで実現されてよい。機器は、保存媒体から保存された命令語を呼び出し、呼び出された命令語に従って動作が可能な装置として、開示された実施形態に係る電子装置を含んでよい。命令がプロセッサによって実行される場合、プロセッサが直接、又はプロセッサの制御下で異なる構成要素を用いて命令に該当する機能を行ってよい。命令は、コンパイラ又はインタプリタによって生成又は実行されるコードを含んでよい。機器で読み取れる保存媒体は、非一時的（ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ）保存媒体の形態で提供されてよい。ここで、「非一時的」とは、保存媒体が信号（ｓｉｇｎａｌ）を含まずに実在（ｔａｎｇｉｂｌｅ）することを意味するだけで、データが保存媒体に半永久的に又は一時的に保存されることを区分しない。

なお、本発明の一実施形態によると、以上で説明された多様な実施形態に係る方法は、コンピュータプログラム製品（ｃｏｍｐｕｔｅｒ ｐｒｏｇｒａｍ ｐｒｏｄｕｃｔ）に含まれて提供されてよい。コンピュータプログラム製品は、商品として販売者及び購入者間で取り引きできてよい。コンピュータプログラム製品は、機器で読み取ることができる保存媒体（例：ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ（ＣＤ－ＲＯＭ））の形態で、又はアプリケーションストア（例えば、ＰｌａｙストアＴＭ）によりオンラインで配信されてよい。オンラインによる配信の場合に、コンピュータプログラム製品の少なくとも一部は、製造元のサーバ、アプリケーションストアのサーバ、又は中継サーバのメモリのような保存媒体に少なくとも一時保存されるか、一時的に生成されてよい。

なお、上述の多様な実施形態に係る構成要素（例：モジュール又はプログラム）のそれぞれは、単数又は複数の個体で構成されてよく、上述の当該サブ構成要素のうちの一部のサブ構成要素が省略されたり、又は別のサブ構成要素が多様な実施形態に更に含まれてよい。代替で又は追加で、一部の構成要素（例：モジュール又はプログラム）は、一つの個体に統合され、統合される前のそれぞれの当該構成要素によって行われる機能を同一又は類似するように行ってよい。多様な実施形態に係るモジュール、プログラム又は他の構成要素によって実行される動作は、順次に、並列に、繰り返し、又はヒューリスティックに実行されるか、少なくとも一部の動作が別の順番で実行されたり、省略されたり、又は別の動作が追加されてよい。

以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明は以上の実施形態に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的趣旨の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

Claims (20)

1. 端末装置に動作を実行させるコンピュータで読み取り可能な保存媒体に保存されたアプリケーションにおいて、
   前記動作は、
   予約の要請及びユーザの識別情報をアプリケーションサーバを介して病院管理サーバに伝送するステップと、
   症状情報を入力されるためのＵＩ画面を提供するステップと、
   前記ＵＩ画面を介してユーザの症状情報が入力されると、前記症状情報及び待機番号の要請を前記病院管理サーバに伝送するステップと、
   前記病院管理サーバから前記待機番号の要請に対応する待機番号を受信し、受信された待機番号を含むＵＩ画面を提供するステップと、
   前記受信された待機番号を前記アプリケーションサーバを介して前記病院管理サーバに伝送するステップと
   を含み、
   前記ユーザの識別情報は、前記病院管理サーバで生成される患者情報に含まれ、
   前記症状情報及び前記待機番号は、前記病院管理サーバで生成される待機者情報に含まれ、
   前記待機者情報及び前記患者情報は、前記アプリケーションサーバで組み合わせられた識別情報及び待機番号に基づいて、前記病院管理サーバによってマッピングされる、アプリケーション。
2. 前記マッピングされた患者情報及び待機者情報に基づいて、前記病院管理サーバに伝送された前記症状情報を含む第１のＵＩ画面、及び前記ユーザの識別情報を含む第２のＵＩ画面が、前記病院管理サーバと通信するディスプレイ装置に提供される、請求項１に記載のアプリケーション。
3. 前記動作は、
   病院の予約のためのＵＩ画面を提供するステップと、
   前記病院の予約のためのＵＩ画面を介して予約の要請が受信されると、前記予約の要請及び前記ユーザの識別情報を前記アプリケーションサーバを介して前記病院管理サーバに伝送し、
   前記アプリケーションサーバを介して前記病院管理サーバから病院の予約情報が受信されると、前記受信された病院の予約情報を含むＵＩ画面を提供するステップとを更に含み、
   前記予約情報は、予約時間を含む、請求項１に記載のアプリケーション。
4. 前記動作は、
   前記予約時間より臨界時間前の時点から、前記端末装置の位置情報を前記病院管理サーバに伝送するステップと、
   前記病院管理サーバから前記位置情報に対応する待機番号を受信すると、受信された待機番号を含むＵＩ画面を提供するステップと
   を更に含む、請求項３に記載のアプリケーション。
5. 前記病院管理サーバは、
   前記位置情報が前記病院の位置から臨界距離内であれば、順位の高い待機番号を前記端末装置に提供する、請求項４に記載のアプリケーション。
6. 前記動作は、
   前記マッピングされた患者情報及び待機者情報に基づいて、前記病院管理サーバに伝送された前記症状情報及び前記待機番号を含む第１のＵＩ画面、及び前記ユーザの識別情報及び前記待機番号を含む第２のＵＩ画面が、前記病院管理サーバと通信するディスプレイ装置に提供される、請求項１に記載のアプリケーション。
7. 前記動作は、
   前記病院管理サーバから処方情報を受信するステップと、
   前記受信された処方情報を含むＵＩ画面を提供するステップと
   を更に含み、
   前記病院管理サーバは、前記待機番号に基づいて前記処方情報を伝送する端末装置を識別し、前記識別された端末装置に前記処方情報を伝送する、請求項１に記載のアプリケーション。
8. 前記病院管理サーバは、
   第１の病院管理サーバ及び第２の病院管理サーバを含み、
   前記症状情報及び前記待機番号の要請は、前記第１の病院管理サーバに伝送され、
   前記ユーザの識別情報は、前記第２の病院管理サーバに伝送される、請求項１に記載のアプリケーション。
9. 前記症状情報は、前記端末装置の第１の通信モジュールを用いて、前記病院管理サーバに伝送され、
   前記ユーザの識別情報は、前記端末装置の第２の通信モジュールを用いて、前記アプリケーションサーバを介して前記病院管理サーバに伝送される、請求項１に記載のアプリケーション。
10. 前記動作は、
    前記病院管理サーバから処方情報を受信するステップと、
    前記受信された処方情報を含むＵＩ画面を提供するステップと
    を更に含み、
    前記処方情報は、前記第１の通信モジュールを介して前記病院管理サーバから受信される、請求項９に記載のアプリケーション。
11. 端末装置、アプリケーションサーバ及び病院管理サーバを含むシステムにおいて、
    前記端末装置は、
    予約の要請及びユーザの識別情報を前記アプリケーションサーバに伝送し、
    前記アプリケーションサーバは、
    前記端末装置から受信された前記予約の要請及び前記ユーザの識別情報を病院管理サーバに伝送し、
    前記病院管理サーバは、
    前記アプリケーションサーバから受信された前記予約の要請及び前記ユーザの識別情報に基づいて患者情報を生成し、
    前記端末装置は、
    症状情報を入力されるためのＵＩ画面を表示し、
    前記ＵＩ画面を介してユーザの症状情報が入力されると、前記症状情報及び待機番号の要請を病院管理サーバに伝送し、
    前記病院管理サーバは、
    前記端末装置から受信した待機番号の要請に基づいて待機番号を生成し、
    前記生成された待機番号を前記端末装置に伝送し、
    前記端末装置から受信した前記症状情報及び前記生成された待機番号を組み合わせて待機者情報を生成し、
    前記端末装置は、
    前記病院管理サーバから前記生成された待機番号を受信し、受信された待機番号を含むＵＩ画面を表示し、
    前記受信された待機番号を前記アプリケーションサーバに伝送し、
    前記アプリケーションサーバは、
    前記端末装置から受信された待機番号及び前記ユーザの識別情報を組み合わせて前記病院管理サーバに伝送し、
    前記病院管理サーバは、
    前記アプリケーションサーバから受信した前記組み合わせられた識別情報及び待機番号に基づいて、前記患者情報及び前記待機者情報をマッピングする、システム。
12. 前記病院管理サーバは、
    前記マッピングされた患者情報及び待機者情報に基づいて、前記病院管理サーバに伝送された前記症状情報を含む第１のＵＩ画面、及び前記ユーザの識別情報を含む第２のＵＩ画面を、前記病院管理サーバと通信するディスプレイ装置に提供する、請求項１１に記載のシステム。
13. 前記端末装置は、
    病院の予約のためのＵＩ画面を表示し、
    前記病院の予約のためのＵＩ画面を介して予約の要請が受信されると、前記予約の要請及び前記ユーザの識別情報を前記アプリケーションサーバに伝送し、
    前記アプリケーションサーバは、
    前記端末装置から受信された前記予約の要請及び前記ユーザの識別情報を病院管理サーバに伝送し、
    前記病院管理サーバは、
    前記アプリケーションサーバから前記予約の要請が受信されると、前記患者情報及び病院の予約情報を生成し、
    前記生成された病院の予約情報を前記アプリケーションサーバに伝送し、
    前記アプリケーションサーバは、
    前記病院の予約情報を前記端末装置に伝送し、
    前記端末装置は、
    前記アプリケーションサーバから病院の予約情報が受信されると、前記受信された病院の予約情報を含むＵＩ画面を表示し、
    前記予約情報は、予約時間を含む、請求項１１に記載のシステム。
14. 前記端末装置は、
    前記予約時間より臨界時間前の時点から、前記端末装置の位置情報を前記病院管理サーバに伝送し、
    前記病院管理サーバから前記位置情報に対応する待機番号を受信すると、受信された待機番号を含むＵＩ画面を表示する、請求項１３に記載のシステム。
15. 前記病院管理サーバは、
    前記位置情報が前記病院の位置から臨界距離内であれば、順位の高い待機番号を前記端末装置に提供する、請求項１４に記載のシステム。
16. 前記病院管理サーバは、
    前記マッピングされた患者情報及び待機者情報に基づいて、前記症状情報及び前記待機番号を含む第１のＵＩ画面、及び前記ユーザの識別情報及び前記待機番号を含む第２のＵＩ画面が、前記病院管理サーバと通信するディスプレイ装置に提供する、請求項１１に記載のシステム。
17. 前記病院管理サーバは、
    処方情報を生成し、
    前記待機番号に基づいて前記処方情報を伝送する端末装置を識別し、
    前記識別された端末装置に前記処方情報を伝送し、
    前記識別された端末装置は、
    前記受信された処方情報を含むＵＩ画面を表示する、請求項１１に記載のシステム。
18. 前記病院管理サーバは、
    第１の病院管理サーバ及び第２の病院管理サーバを含み、
    前記症状情報及び前記待機番号の要請は、前記第１の病院管理サーバに伝送され、
    前記ユーザの識別情報は、前記第２の病院管理サーバに伝送される、請求項１１に記載のシステム。
19. 前記症状情報は、前記端末装置の第１の通信モジュールを用いて前記病院管理サーバに伝送され、
    前記ユーザの識別情報は、前記端末装置の第２の通信モジュールを用いて前記アプリケーションサーバを介して前記病院管理サーバに伝送される、請求項１１に記載のシステム。
20. 前記端末装置は、
    前記病院管理サーバから処方情報を受信し、
    前記受信された処方情報を含むＵＩ画面を表示し、
    前記処方情報は、前記第１の通信モジュールを介して前記病院管理サーバから受信される、請求項１９に記載のシステム。

Images