JP6841973B2 - 情報処理装置及びプログラム - Google Patents

Description

本発明は、受付人員を削減することができ、受付人員が少ないことに起因したトラブルを抑制することができる情報処理装置及びプログラムに関する。

医療機関、特に規模の小さい医療機関においては、受付や精算などの事務処理を行うことができる人員が必要となる。ただし、その人数が極端に少ない（例えば１人）場合には、事務処理を十分にこなすことができなかったり、１人にかかる負担が大きくなることでミスが生じやすくなったりすることが多い。

この点については、従来から医療機関の事務処理を支援する技術は提案されている。例えば特許文献１には、診察を希望する病院の登録、診察時間の予約、診療料金の精算、処方された医薬品の受取りを希望する調剤薬局の指定、及び処方された医薬品の料金精算をスマートフォンで一貫して行うことができる、とされるシステムが提案されている。

特許文献１で提案されているシステムは、システム管理ホスト、スマートフォン、病院ホスト、及び薬局端末がインターネット網で接続された環境で稼働する構成とされている。そして、特許文献１においては、スマートフォンには予約精算アプリケーション（以下、アプリと記す）がインストールされており、このアプリにおいて、診察を希望する病院を登録し、この病院において予約を行う。そして、予約の後、実際の診察が終了すると、診療料金がスマートフォンに表示されるので、支払いボタンをクリックすることで精算が完了する。また、処方薬が処方されている場合は、スマートフォンによって処方薬を受取る調剤薬局を指定することができるとともに、料金の精算を行うことができる。

しかしながら、特許文献１で提案されているシステムでは、確かに、スマートフォンがあれば、このスマートフォン用のアプリをインストールすることで、診察希望の病院の登録、診察時間の予約、診療料金の精算、処方された医薬品の受取りを希望する調剤薬局の指定、及び処方された医薬品の料金精算を行うことが可能となるが、スマートフォン、つまり、いわゆる携帯情報端末がなければ実現することができないという課題がある。

「携帯情報端末がなければ実現できない」ということは、前提として、医療機関の利用者の全てが携帯情報端末を操作できる状態になっていなければならない。しかしながら、現実問題として、まず、特許文献１のシステムが導入された医療機関の利用者の全てが携帯情報端末を使用しているとは限らない。また、仮に携帯情報端末を使用していたとしても、それを常に携帯しているとは限らない。このため、医療機関の利用者の全ての者が特許文献１の効果を得ることができない。

また、特許文献１で提案されているシステムについては、上記の問題の他に、例えば診療料金の精算処理を行う場合、従前の精算窓口での対面式によるものではなく、スマートフォン（アプリ）において行われることとなるので、例えば以下のような問題が生じ得る。即ち、患者が、診療料金の精算、次回の予約、処方箋を貰うなどといった診療後の所定の事務手続を行うことなく医療施設の外へ出てしまうといった事態が生じることを防ぐことができない。

即ち、特許文献１で提案されているシステムは、スマートフォンを持った患者自身で、医療機関における事務を代行することができるようにするシステムである。このため、医療機関における事務手続の省力化が可能となるものの、事務手続の多くを患者に一任しているからこそ、不正や不適切な事務手続が生じるおそれがある。

特開２０１６−１１０２４７号公報

上述のように、特許文献１で提案されているシステムでは、患者が携帯情報端末を携帯していることが必須条件となる。このため、携帯情報端末を携帯していない患者は、医療機関における十分なサービスを受けることができない。また、携帯情報端末を携帯する患者（医療機関の利用者）自身に事務手続の多くを一任することとなるため、不正や不適切な事務手続が生じるおそれがある。

本発明は、このよう状況に鑑みてなされたものであり、患者に携帯情報端末に対する操作を行わせることなく、医療機関の受付事務手続における人員の削減や省力化を図ることができる手法を提供することを目的とする。

上記目的を達成するため、本発明の一態様の情報処理装置は、
商品又は役務の対象の提供が行われる施設で、前記対象の提供を受ける顧客の順番を示す第１情報を生成して、前記顧客毎に管理する第１管理手段と、
前記顧客に提示される、前記第１情報を示す媒体を出力する制御を実行する出力手段と、
前記媒体を所持する前記顧客の前記施設内における位置を示す第２情報を前記第１情報に紐付けて管理する第２管理手段と、
前記商品又は役務の内容を示す第３情報を前記第１情報に紐付けて管理する第３管理手段と、
前記第３情報を少なくとも含む情報に基いて決定された前記対象の料金の額の決済を含む、前記対象の提供の後に行われる手続の進捗状況を示す第４情報を、前記第１情報に対応付けて管理する第４管理手段と、
前記第１情報と、前記第２情報と、前記第３情報と、前記第４情報とに基づいて、前記顧客の移動の状況と、手続の状況とが一致しているか否かの監視を行う監視手段と、
を備える。

本発明の一態様のプログラムは、上述の本発明の一態様の情報処理装置に対応するプログラムである。

本発明によれば、患者に携帯情報端末に対する操作を行わせることなく、医療機関の受付事務手続における人員の削減や省力化を図ることができる。

本発明の情報処理装置の一実施形態に係る医療サーバを含む、医療事務支援施設の構成の一例を示す図である。 図１の医療事務支援装置のうち、医療サーバのハードウェア構成を示すブロック図である。 図２の医療サーバの機能的構成の一例を示す機能ブロック図である。 受付端末を中心として実行される受付処理の流れを示すフローチャートである。 診療端末を中心として実行される診察処理の流れを示すフローチャートである。 手続端末を中心として実行される精算処理の流れを示すフローチャートである。 手続端末を中心として実行される予約処理の流れを示すフローチャートである。 手続端末を中心として実行される処方箋処理の流れを示すフローチャートである。 事務端末及び医療サーバを中心とする監視処理、及び警告装置の作動処理の流れを示すフローチャートである。 来院者の種類に応じた受付処理が行われることを示すフローチャートである。 指紋認証システムを用いた受付処理の流れを示すフローチャートである。 医療事務支援設備において実行される診察後処理の流れを示すフローチャートである。 電話受付処理が行われる場合の処理の流れを示すフローチャートである。 受付手続と診察後手続とを受付けることができる端末で実行される処理の流れを示すフローチャートである。 診療端末で実行される処理の流れを示すフローチャートである。 事務端末で実行される処理の流れを示すフローチャートである。 患者端末で実行される処理の流れを示すフローチャートである。 チャージ機能を備える図１の医療事務支援設備による精算処理の流れを示すフローチャートである。 チャージ機能を備える図１の医療事務支援設備を構成する手続端末の処理の流れを示すフローチャートである。 図１の医療サーバにより提供されるラクネスにより管理されるラクネスＩＤの内容を示すイメージ図である。 ラクネスにより実現可能なサービスの具体例を示すイメージ図である。 診察の受診を終えた患者による精算手続の流れを示すフローチャートである。 診察の受診を終えた患者が子供である場合や、患者に後見人がいる場合の精算手続の流れを示すフローチャートである。

以下、本発明の一実施形態について、図面を用いて説明する。

図１は、本発明の情報処理装置の一実施形態に係る医療サーバを含む、医療事務支援施設の構成の一例を示す図である。
本発明の情報処理装置の一実施形態に係る医療サーバ１を含む医療事務支援設備Ｇは、上述の問題、即ち、医療機関の受付事務手続における人員の削減や省力化のために患者の携帯情報端末を活用することで生じ得る問題を、以下の手法を用いて解決する。

まず、対象となる医療施設内に医療事務支援設備Ｇを設置する。医療事務支援設備Ｇは、医療サーバ１と、受付端末２と、診療端末３と、手続端末４と、事務端末５と、カード検知器６と、警告装置７とを含むように構成されている。
受付端末２は、来院患者の特定、及び診察の順番を示す順番カードの発行を行う。
診療端末３は、受付端末２により発行された順番カードを一意に特定可能な識別情報（以下、「順番データ」と呼ぶ）に一時的に紐付けられた、来院患者の診療に関する情報（以下、「電子カルテ」と呼ぶ）に対する医師による診療内容の入力を受付ける。なお、「診療」とは、医師が診察や治療等を行うことをいう。
手続端末４は、診療が終わった後に、今回の診療に係る料金の精算と、次回の来院の予約の受付けと、及び処方薬があれば処方箋の印刷とを行う。
事務端末５は、受付端末２により発行された順番カードにより示される順番データに一時的に紐付けられた来院患者の移動と、手続の進行状況とを管理する。
カード検知器６は、医療施設内のあらゆる場所に設置されており、医療施設内に存在する１以上の順番カードの夫々の位置を検知する。カード検知器６による検知の結果は、医療サーバ１に逐次送信されるので、医療施設内に存在する１以上の順番カードの夫々の位置をリアルタイムで把握することが可能となる。

警告装置７は、例えば、本実施形態では、医療施設内の特に受付カウンター近くに設けたスピーカ一、及び医療施設の出入口の解錠・施錠が制御される機構、を有した構成とされている。即ち、警告装置７は、医療サーバ１に接続されており、適切な手順を踏んでいない患者に対してその旨をスピーカ等で報知するとともに、医療施設内から退去させないように出入口を施錠する構成としている。なお、この警告装置７が作動する際には事務端末５でもその旨をモニタリングできるようになっている。

なお、警告装置７は、上記に限らず、例えば、順番カードが発光、振動、文字表示、及び発音等を行うような構成とすることで、順番カード自体を警告装置７の一部とすることもできる。また、こうした点と併せて、万が一所定の手順や手続を踏んでいない患者が医療施設の外に退出してしまった場合であっても、別途、診察券発行時に登録された患者の電話番号やメールアドレス等を用いてその旨を連絡できるようにすることもできる。

警告装置７は、所定の手順や手続を踏んでいない患者に対してタイムリーにその旨を知らせて追完させることができることが好ましく、所定の手順や手続を踏んでいない患者が医療施設の外に退出することを防いで追完させることができればさらに好ましい。こうした点が実現可能であれば、警告装置７の構成は特に限定されない。

医療事務支援設備Ｇでは、医療サーバ１と、受付端末２と、診療端末３と、手続端末４と、事務端末５とネットワークＮを介して相互に通信可能に接続されている。
また、医療事務支援設備Ｇには、さらに、医療サーバ１による制御が可能な警告装置７を接続することができる。この場合、医療サーバ１は、順番カードの移動及び手続端末４の処理状況を監視して、所定の手順又は所定の手続を踏んでいないことを検知して、警告装置７を作動させることができる。
また、医療事務支援設備Ｇには、ネットワークＮを介して外部のレセプトコンピュータ、各種クレジットカード会社、銀行のホストコンピュータ等と通信可能に接続されている。
ここで、「レセプト」とは、カルテの内容に基づいて毎月患者毎に作成される診療報酬明細書のことをいい、「レセプトコンピュータ」とは、レセプトを作成する情報処理装置のことをいう。医療施設は、所定の支払機関（例えば国民健康保険団体連合会）にレセプトを提出することで診療報酬を得ることができる。

受付端末２は、来院患者の所持物、又は来院患者自身に基づいて、医療サーバ１に蓄積された患者のデータの読み出しを行い、これを順番データと一時的に紐付け、順番カードを発行する処理を行う。診療端末３は、順番カードの発行順に送信されてくる患者の電子カルテを受信して、医師による診察事項の入力を受付ける処理を行う。手続端末４は、医師による診察の後に送信されてくる電子カルテに基づいて、料金の算出を行うとともに、精算の処理と精算完了のフラグを立てる処理を行う。また、手続端末４は、次回の来院を要する場合には、日時の空き情報を画面に表示するとともに、患者が予約を希望する日時を入力させ、これが完了した後に予約完了のフラグを立てる処理を行う。医療サーバ１は、順番カードの状況を監視するとともに、手続端末４におけるフラグの状況を管理する処理を行う。また、医療サーバ１は、順番カードの状況と、手続端末４における処理状況とが一致しない場合には、警告装置７による警告を作動させる制御を実行する。

上記の他、医療事務支援設備Ｇは、例えば順番カードを、それ自体により非接触通信可能ないわゆるＲＦＩＤ（Ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ ｉｄｅｎｔｉｆｉｅｒ）機能（チップ）を備えたものを採用してもよい。この場合、医療施設の例えば受付端末２、診療端末３、及び手続端末４の周辺に設けられたカード検知器６６により、患者が受付端末２、診療端末３、及び手続端末４の順に通過したことを検知して、その結果を医療サーバ１が取得できるようにすることができる。これにより、医療サーバ１では、カード検知器６による検知の結果に基づいて、順番カードの移動と手続完了のフラグを事務端末５においてモニタリングできるようになっている。

上記構成の医療事務支援設備Ｇの動作と本発明の医療事務支援プログラムの処理手順について説明する。本発明の医療事務支援プログラムは、医療サーバ１に主プログラムがインストールされており、医療サーバ１と通信回線網Ｎを介して接続した受付端末２、診療端末３、手続端末４、事務端末５、クライアントプログラムがインストールされている。

図２は、図１の医療事務支援装置のうち、医療サーバのハードウェア構成を示すブロック図である。
医療サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３と、バス１４と、入出力インターフェース１５と、出力部１６と、入力部１７と、記憶部１８と、通信部１９と、ドライブ２０とを備えている。

ＣＰＵ１１は、ＲＯＭ１２に記録されている各種プログラム、又は、記憶部１８からＲＡＭ１３にロードされた各種プログラムに従って各種の処理を実行する。
ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、出力部１６、入力部１７、記憶部１８、通信部１９及びドライブ２０が接続されている。

出力部１６は、各種液晶ディスプレイ等で構成され、各種情報を出力する。
入力部１７は、各種ハードウェア等で構成され、各種情報を入力する。

記憶部１８は、ハードディスクやＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含むネットワークＮを介して他の装置（例えば、図１の受付端末２、診療端末３、手続端末４、事務端末５、カード検知器６、警告装置７、患者端末８等）との間で行う通信を制御する。

ドライブ２０は、必要に応じて設けられる。ドライブ２０には磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア２１が適宜装着される。ドライブ２０によってリムーバブルメディア２１から読み出されたプログラムは、必要に応じて記憶部１８にインストールされる。また、リムーバブルメディア２１は、記憶部１８に記憶されている各種データも、記憶部１８と同様に記憶することができる。

また、受付端末２、診療端末３、手続端末４、事務端末５、及び患者端末８の夫々は、医療サーバ１のハードウェア構成と基本的に同様とすることができるが、さらに以下のようなのハードウェア構成とすることができる。

受付端末２は、タッチパネルを有し、カードの情報の読み取りや、順番カードを発券する入出力に特化した構成とすることができる。

診療端末３、及び事務端末５の夫々のハードディスクには、本発明のプログラムの一実施形態に係る医療事務支援プログラムがインストールされている。

手続端末４は、タッチパネルを有し、いわゆるＡＴＭ装置のように金銭やカードの取り扱いが可能な装置構成とすることができる。また、患者が次回の希望予約日時を入力できる構成、及び処方箋等やレシート等を印刷することができる構成とすることができる。

このような図２の医療サーバ１と、受付端末２と、診療端末３と、手続端末４と、事務端末５と、警告装置７との各種ハードウェアと各種ソフトウェアとの協働により、後述する一連の処理の実行が可能となる。

図３は、図２の医療サーバの機能的構成の一例を示す機能ブロック図である。

医療サーバ１のＣＰＵ１１においては、順番管理部１０１と、発行制御部１０２と、位置管理部１０３と、診察管理部１０４と、手続管理部１０５と、監視部１０６と、警告制御部１０７と、コード生成部１０８とが機能する。

また、医療サーバ１の記憶部１８の一領域には、患者ＤＢ１８１と、カードＤＢ１８２とが設けられている。
患者ＤＢ１８１には、１以上の患者の夫々に関する情報（以下、「患者データ」と呼ぶ）が記録されて管理されている。
カードＤＢ１８２には、１以上の順番カードの夫々を特定可能とする順番データが記録されて管理されている。

順番管理部１０１は、医療施設で医師の診察を受ける患者の順番を示す順番データを生成して、患者毎に順番データを対応付けて管理する。
具体的には、順番管理部１０１は、患者ＤＢ１８１に記録されて管理されている患者データと、カードＤＢ１８２に記録されて管理されている順番データとを対応付けて管理する。

発行制御部１０２は、医療施設で医師の診察を受ける患者が医療施設内で所持する順番カードを発行する制御を実行する。
具体的には、発行制御部１０２は、医療施設に来院した患者による受付端末２に対する操作に基づいて、受付端末２から順番カードを発券する制御を実行する。患者は、受付端末２から発券された順番カードを受取ると、順番カードを所持した状態で医療施設内を移動する。

位置管理部１０３は、順番カードを所持する患者の医療施設内における位置を示す情報（以下、「患者位置情報」と呼ぶ）を管理する。
具体的には、位置管理部１０３は、医療施設内のあらゆる場所に設置されているカード検知器６による順番カードの検知結果に基づいて、患者位置情報を生成して管理する。

診察管理部１０４は、電子カルテを順番データに対応付けて管理する。
具体的には、診察管理部１０４は、医師による診療端末３に対する入力操作の内容に基づいて生成される電子カルテを取得し、順番データに対応付けて管理する。生成された電子カルテは、患者ＤＢ１８１に患者毎に記録されて管理される。

手続管理部１０５は、患者の診療料金の額、及び患者の診療料金の支払いの進捗管理を行う。
具体的には、手続管理部１０５は、患者の診療料金の額を示す情報（以下。「精算データ」と呼ぶ）と、患者による診療料金の支払いを含む、診察後に行われる種々の手続（以下、「診察後手続」と呼ぶ）の進捗状況を示す情報（以下、「手続進捗情報」と呼ぶ）とを、順番データに対応付けて管理する。
具体的には、手続管理部１０５は、手続進捗情報として、診療料金の支払いの有無を示す情報の他、処方箋の発行の有無を示す情報、及び次回の診察の予約の有無を示す情報等を、順番データに対応付けて管理する。

また、手続管理部１０５は、レセプトに基いて決定された診療料金の額を示す精算データと、順番データとを対応付けて管理する。

また、手続管理部１０５は、患者により預け入れられた（チャージされた）預り金の額を示す情報と、患者を一意に特定可能なＩＤ（以下、「患者ＩＤ」と呼ぶ）等の識別情報とを対応付けて管理する。

監視部１０６は、順番データと、患者位置情報と、電子カルテと、手続進捗情報とに基づいて、患者の移動の状況と、手続の状況とが一致しているか否かの監視を行う。
具体的には、監視部１０６は、順番管理部１０１と、位置管理部１０３と、診察管理部１０４と、手続管理部１０５との夫々により患者毎に管理されている各種データに基づいて、患者の移動の状況と、手続の状況を示すフラグの状況とのモニタリングを行う。

警告制御部１０７は、監視部１０６による監視の結果、患者の手続の状況と、患者の移動の状況とが一致しない場合には、当該患者に所定の警告を行う制御を実行する。
即ち、監視部１０６による監視の結果、医療施設内の手続の進行状況と実際の患者の位置との間に不整合が生じていることが判明した場合には、患者が勘違いをしていたり、不正行為を行っていたりするおそれがある。このため、警告制御部１０７は、監視部１０６による監視の結果に基づいて、上述したような警告装置７による警告が実施される。

コード生成部１０８は、手続管理部１０５により管理されている精算データを一意に特定可能な識別子（例えばＱＲコード（登録商標））を生成する。

以上のように、医療サーバ１において実行されるプログラムは、概略的には、医療事務支援設備Ｇを構成する各種端末等の制御や各種データの送受信を行うとともに、カード検知器６による順番カードの位置の検出と、各種手続の完了フラグの状況とに基づいて、警告装置７による警告を実施する制御を実行するようプログラムされている。
以下、医療事務支援プログラムのうち医療サーバ１にインストールされた主プログラムと、医療事務支援設備Ｇを構成する各種端末の夫々にインストールされたクライアントプログラムとにより実行される各種処理について、以下、詳細に説明する。

なお、本実施形態では、医療施設において受付業務を担当する者は、事務端末５を操作する事務担当者が１名だけであることを前提として説明する。
図４は、受付端末を中心として実行される受付処理の流れを示すフローチャートである。

患者が来院すると、医療施設の出入口に設置された受付端末２が受付処理開始する。「受付処理」とは、医療施設に来院した患者の診察の受付を行う処理のことをいう。
具体的には、受付端末２は、患者の来院を人感センサ等で検知する（ステップＳ１）。受付端末２が患者の来院を検知すると（即ちステップＳ１がＹＥＳ）、受付端末２のディスプレイに、例えば「受付手続の案内表示」を行う（ステップＳ２）。

受付端末２の「受付手続の案内表示」において、初診か再診かを選択する画面が表示される。ここで、患者が初診である場合には（即ちステップＳ３がＹＥＳ）、受付端末２の読み取り手段（例えばスキャン機能）において、患者は保険証等を読み取らせる（ステップＳ４）。すると、受付端末２は、その保険証等の読取データを医療サーバ１へ送信し、医療サーバ１において保険証に記載された情報等を含む患者データを患者ＤＢ１８１に記録する（ステップＳ５）。

続いて、受付端末２は、保険証等の読み取りを促す画面から、支払手段の選択画面に切り替えて、ここで、患者に支払手段を入力させる（ステップＳ６）。例えば支払手段としては、現金支払い、クレジットカード会社による代行支払い、銀行口座からの引き落しによる支払いのうちいずれかを選択できるようになっている。具体的には例えば、現金支払いを選択した場合は、受付端末２はその旨を示す情報を医療サーバ１に送る。すると、医療サーバ１は、ステップＳ５で患者ＤＢ１８１に記録された患者データに、支払手段を示すデータを紐付けて記録する（ステップＳ７）。

クレジットカード会社による代行支払いを選択した場合、患者は、受付端末２にクレジットカードを読み取らせるとともに、契約者等の各種情報を入力する。受付端末２は、患者により入力された情報を含む、支払手段を示すデータを、医療サーバ１に送る。医療サーバ１は、ステップＳ５で患者ＤＢ１８１に記録された患者データに、支払手段を示すデータを紐付けて記録する（ステップＳ７）。

銀行口座からの引き落しによる支払いを選択した場合、患者は、受付端末２に銀行のキャッシュカードを読み取らせるとともに、口度名義等の各種情報を入力する。受付端末２は、患者により入力された情報を含む、支払手段を示すデータを、医療サーバ１に送る。医療サーバ１は、ステップＳ５で患者ＤＢ１８１に記録された患者データに、支払手段を示すデータを紐付けて記録する（ステップＳ７）。

受付端末２は、ステップＳ４乃至Ｓ７の後、診察券を発行する（ステップＳ８）。この診察券は、受付端末２の発券口から出力されるカード状の診察券であり、患者名と所定のＩＤが付されている。受付端末２は、出力した診察券を患者が所定時間受け取らない場合には、患者が受け取るまで、警告音を発するとともに、画面上にその旨を表示する。患者が診察券を受け取ると、警告音が止み、初期画面に戻る。

一方、ステップＳ３で初診ではなく（即ちステップＳ３がＮＯ）再診である場合、患者は、既に発行されている診察券を受付端末２に挿入する。すると、診察券の券面に表示された情報の少なくとも一部を受付端末２が読み取り、又は患者が入力する（ステップＳ９）。すると、受付端末２は、読み取った又は入力されたデータを、医療サーバ１に送信し、患者を特定するための問い合わせを行う。この問い合わせの結果、患者が特定できた場合には（ステップＳ１０）、順番カードを発行する（ステップＳ１１）。

なお、本実施形態では、受付端末２が患者に対しカード状の診察券を供給する用いる構成としているが、例示に過ぎない。例えばＩＣチップのように非接触によるデータ送受が可能であり、かつ貼付が可能なものを診察券（又はこれに類似するもの）として供給することもできる。この場合、患者が携帯する物品、例えば携帯電話、財布、カバン等に貼付できるようにしてもよい。このような構成とすることで、カード状の診察券を持参し忘れて診察をスムーズに受けられないといった事態や、初診扱いとなって手続や支払いに手間取るといった事態生じることを防ぐことができる。

受付端末２が、来院した患者に対し、診察の順番を示す順番カードを発券すると、医療サーバ１は、受付が完了したことを示すフラグを立て（ステップＳ１２）、その旨を示すデータが診療端末３、手続端末４、及び事務端末５に送信される。これにより、受付処理が終了する。

医療サーバ１は、受付端末２において順番カードが発券された後、カード検知器６により検知される順番カードの位置の移動と、受付端末２、診療端末３、及び手続端末４における手続の完了を示すフラグとを監視する。これにより、手続が所定の順番で行われていない場合には、医療サーバ１が警告装置７による処理の制御を実行するとともに、事務端末５に現在の状況を示すデータを送る。その結果、事務端末５では、順番カードの位置の移動と、手続完了のフラグの状況とをモニタリングすることが可能となる。

即ち、受付業務を行う事務担当者（本実施形態では１名）は、この事務端末５の画面を見ることで、患者の位置（即ち順番カードの位置）の移動、及び当該患者が現時点でどの手続を完了しているのかを容易に視認することができる。また、順番を経ずに、例えば診療料金の支払いの手続を行うことなく医療施設の外へ出てしまうような事態が生じることを防ぐことができる。

受付端末２による順番カードの発券を受けた患者は、診察の順番が来るまで医療施設内で待ち、自分の順番が来ると、医師の診察を受けるために診察室に入室する。
次に、図５を参照して、診察を行う医師により操作される診療端末３を中心とした処理の流れについて説明する。
図５は、診療端末を中心として実行される診察処理の流れを示すフローチャートである。

患者に対し診察を行う医師により操作される診療端末３には、次に診察の順番を迎える患者の順番カードに表記された番号が表示されている。前の患者の診察を終えた医師が、診療端末３に対する所定の操作を行うと、診療端末３に表示された番号が表記された順番カードを所持する、次の患者の呼び出しが行われる（ステップＳ２１）。

この呼び出しは、診察室の前に設置された所定の表示装置に、順番カードに表記された番号が表示されたり、表示された番号が点滅等したりすることで患者に報知される。この表示装置には、診察の順番待ちをしている患者の順番カードに表記されている番号が、所定の順番で表示される構成となっている。診察の順番待ちをしている１以上の患者の順番カードの夫々に表記されている番号は、診療端末３と、事務端末５との夫々のディスプレイ画面の一部にも、リストとして一覧表示される。

診察室に患者を迎えた医師が診察を開始する際には、医療サーバ１において順番データに紐づけられて管理されている電子カルテが読み出され、診療端末３に入力可能な状態で表示される（ステップＳ２２）。そして、医師による診察が行われると、診察を行った医師は、診療端末３を操作することで、電子カルテに診察の内容を入力する（ステップＳ２３）。

医療サーバ１は、医師による診察の内容が入力された電子カルテの内容に基づいて、例えば外部のレセプトコンピュータに診療料金を算出させる。また、医師は、診療端末３を操作することで、必要に応じて薬の処方を行う（ステップＳ２４）。診療端末３において、ステップＳ２４までの処理が完了し、診察が終了した旨の操作が医師によって行われると、医療サーバ１は、その順番カードを所持する患者についての診察が完了したことを示すフラグを立てる（ステップＳ２５）。すると、その旨を示すデータが、手続端末４と、事務端末５との夫々に送信される。

次に、図６を参照して、診察を終えた患者により操作される手続端末４を中心とした処理の流れについて説明する。
図６は、手続端末を中心として実行される精算処理の流れを示すフローチャートである。

医師による患者に対する診療が完了した後、診療料金を算出する処理が完了すると、医療サーバ１は、手続端末４のディスプレイ画面に、順番カードに表記された番号を表示させる制御を実行する（ステップＳ３１）。また、医療サーバ１は、手続端末４に対し、対象となる患者の精算データを転送する。手続端末４は、医療サーバ１から転送されてきたが千さんこれを受信する（ステップＳ３２）。

対象となる患者が、手続端末４に対する操作として、順番カードを読み込ませると（ステップＳ３３）、今回の診療内容に慕づく料金が表示される（ステップＳ３４）。また、それとともに、支払方法についての案内が表示される。

支払方法についての案内の表示は、現金支払い、銀行口座からの引き落としによる支払い、クレジットカード会社による代行支払いのうち、診察券の発行の際に患者により選択された１の支払手法を示す文字が、先頭かつやや大きめに画面表示される。例えば現金支払いの場合には（即ちステップＳ３５がＹＥＳ）、手続端末４において、現金表示を操作することで、手続端末４の現金投入口が開き、ここに現金を投入し、金額不足や読み取り不能紙幣や硬貨などのエラーがなければ（ステップＳ３８がＮＯ）、精算が完了する（ステップＳ３９）。

一方、例えば銀行口座からの引き落としであれば（即ちステップＳ３６がＹＥＳ）、医療サーバ１が外部の銀行のホストコンピュータに確認のための通信を行い、引き落とし可能であれば、つまりエラーがなければ（ステップＳ３８がＮＯ）、精算が完了する（ステップＳ３９）。

さらに、例えばクレジット支払いであれば（即ちステップＳ３７がＹＥＳ）、医療サーバ１が外部のクレジット会社のホストコンピュータに確認のための通信を行い、支払い代行が可能であれば、つまりエラーがなければ（即ちステップＳ３８がＮＯ）、精算が完了する（ステップＳ３９）。

上記のとおり、手続端末４において、いずれかの方法によって精算が完了すると（ステップＳ３９）、医療サーバ１は、その順番カードの患者について精算手続が完了したことを示すフラグを立て（ステップＳ４０）、このデータが事務端末５へ送信される。

図７は、手続端末を中心として実行される予約処理の流れを示すフローチャートである。

上述の図６に示す精算処理の後、手続端末４では、精算のための表示から、次回の予約のための表示に切り替わり、次回の予約の要否が画面表示され（ステップＳ４１）、次回の予約が不要との操作がなされる（即ちステップＳ４１がＮＯ）と、処理は、ステップＳ４５へ進む。一方、次回の予約が必要との操作がなされる（即ちステップＳ４１がＹＥＳ）と、日時指定をすべく、手続端末４は医療サーバ１から日時データを読み込み、画面にカレンダーを表示する（ステップＳ４２）。

手続端末４は、カレンダー表示の際、その日のどの時間も埋まっている場合は、その日の色を変えてその旨表示し、空き時間がある場合は前記埋まっている場合とは別の色に変えてその旨表示する。患者が空き時間のある日を操作すると、手続端末４は、その日の時間を表示する。カレンダー表示において、埋まっている持間帯と、埋まっていない時間帯との色を変えて表示し、また、担当医の時間帯だけをリストアップして表示させるようにしてもよく、患者が手続端末４を操作して、次回の予約日時を設定する（ステップＳ４３）。

患者が、手続端末４の空き時間を操作し、確認操作して、次回の予約日時が設定されると、手続端末４は更新された予約の日時データを医療サーバ１に送信し、医療サーバ１は、その順番カードに紐付されている患者のデータを予約日時データと紐付して、患者データと、予約日時データの双方を更新して記録する（ステップＳ４４）。

手続端末４において、予約手続が完了すると、医療サーバ１は、その順番カードの患者について予約手続が完了したことを示すフラグを立て（ステップＳ４５）、このデータが事務端末５へ送信される。

図８は、手続端末を中心として実行される処方箋処理の流れを示すフローチャートである。

手続端末４は、医療サーバ１を介して診療端末３で作成された電子データに基づいて処方箋データがあれば（即ちステップＳ５１がＹＥＳ）、予約画面から処方箋がある旨の画面に切り替わり、処方箋データを医療サーバ１から読み出し（ステップＳ５２）、表示する。

手続端末４は、処方箋データを画面表示させた際には、薬に関する注意事項を表示させ、患者に服用容量や用法の確認データを表示する（ステップＳ５３）。手続端末４は、ステップＳ５３で患者による確認の操作がなされた後、印刷する（ステップＳ５４）。

手続端末４において、処方箋に関する手続が完了すると、医療サーバ１は、その順番カードの患者について処方箋に関する手続が完了したこと、及び手続端末４における全手続が終了したことを示すフラグを立て（ステップＳ５５）、このデータが事務端末５へ送信される。
なお、処方箋データがない（必要でない）場合には（即ちステップＳ５１がＮＯ）、処理はステップＳ５５に進む。

なお、順番カードは、ステップＳ５５を経た後、例えば、受付端末２の回収ボックスに投入すれば、順番カードにおける番号のデータと患者カードの紐付が解除され、医療施設外へ出ることができる。

次に、上記における事務端末５と医療サーバ１と警告装置７の処理について説明する。
図９は、事務端末及び医療サーバを中心とする監視処理、及び警告装置の作動処理の流れを示すフローチャートである。

上記のとおり、順番カードは非接触通信可能ないわゆるＲＦＩＤ機能を備え、患者が該順番カードを持って移動すれば、送受信機器で検知され、患者の現在位置を、医療サーバ１を介して事務端末５によって把握できる。一方、医療サーバ１を介して、順番カードに紐付された患者の受付、診療、精算、予約、処方箋（診察完了）の手続毎の完了フラグにより手続状況を把握できる。

事務端末５は、医療サーバ１を介して、順番カードの移動と、順番カードに紐付された患者の手続完了のフラグとを、受付担当者が監視できるようになっている。そして、事務端末５は、医療サーバ１が所定手続を踏んでいない患者を検知した場合に、その旨が画面に表示され、また作動した警告装置７を停止解除するように構成されている。

即ち、受付事務の人員を削減して、本例の場合、極端に１名とした場合、最も困難なことは、患者の動きと、実際の手続状況が把握できないこと、例えば診察を終えて、精算をせずに医療施設外に出てしまうトラブルを回避すること、である。

医療サーバ１は、順番カードを受付端末２、診療端末３、手続端末４の周辺に設けられた送受信機器で検知しており、この検知結果をバッファしている。そして、医療サーバ１は、順番カードが発券されて受付完了のフラグが立ってから（ステップＳ６１）、ステップＳ６２以降、当該順番カードが検知されたポイントとフラグが立った手続とを比較して、フラグが立っていない手続を過ぎたポイントで順番カードが検知された場合（即ちステップＳ６２〜ステップＳ６５がＮＯ），医療サーバ１は、警告装置７を作動させる。

医療サーバ１が警告装置７を作動させると、医療施設内における例えばスピーカから、その順番カードの番号とともに、例えば「００番の方は００の手続を行っておりません」などのアナウンスを流すとともに、事務端末５において、その旨表示させる。まず、こうすることで、受付事務が１名であっても順番カードの移動が所定の順を踏んでいないことを把握することができる。

そして、本例の場合、特に、精算完了フラグ（ステップＳ６３）、予約完了フラグ（ステップＳ６４）、処方箋完了（手続完了）フラグ（ステップＳ６５）が立つ前に、事務端末５周辺の順番カードの検知ポイントで該順番カードが検知されると、医療施設の出入口のドアが開かず、その患者は医療施設外に出ることができないようにしている。

また、事務端末５において、順番カードの移動が所定の順を踏んでいないことが把握できるので、場合によっては事務端末５を操作する者が案内や注意のためにその患者に駆け寄るような指示留面を医療サーバ１から事務端末５へ表示させることもできる。

このように、本発明であれば、予約と精算などの処理を手続端末４で処理されるようにすることで受付人員を減らすことができ、また、順番カードに紐付された患者の移動と手続遷移を事務端末５で管理し、手順に沿っていない場合は警告装置７がその旨を患者及び事務端末５に報知するようにしているので、受付人員が少ないことに起因した不具合を抑制することができる。

図１０は、来院者の種類に応じた受付処理が行われることを示すフローチャートである。

入退室管理システムでは、医療機関若しくは診察室の入口で、顔認証システムを用いた入室制限を行うこともできる。来院者としては、図１０に示すように、（１）新規の患者（初診患者）、（２）既に診察券を所有しているが、しばらく来院しておらず、予約をしていない患者（予約なし患者）、（３）診察予約をしている患者（予約あり患者）の３種類が想定される。

上記（１）の種類の来院者の場合には、受付処理が開始されると、来院者の生年月日の入力が受付けられ（ステップＳ１３１）、基本的な問診や来院者の情報が端末に登録される。その際、次回来院した際に顔認証システムを用いることができるようにするために、来院者の顔の撮像が行われ（ステップＳ１３２）、登録された患者データに基づいて診察券が発行される（ステップＳ１３３）。これにより受付処理が完了する。

上記（２）の種類の来院者の場合には、来院者の生年月日の入力が受付けられ（ステップＳ１４３）、医療機関の入口の扉が解錠され、患者データとして存在する来院者か否かが診察券によって判定され、来院の登録が行われる（ステップＳ１４４）。その後、来院者は、問診内容の入力する（ステップＳ１４６）。これにより受付処理が完了する。
また、上記（３）の種類の来院者の場合には、顔認証システムにより医療機関の入口の扉を解錠し（ステップＳ１４１，Ｓ１４７）、診察券によって来院の登録が行われる（ステップＳ１４８）。これに対して、顔認証システムがスムーズに行えなかった場合には（ステップＳ１４２）、来院者の生年月日の入力が受付けられ（ステップＳ１４３）、医療機関の入口の扉が解錠され、患者データとして存在する来院者か否かが診察券によって判定されて、来院の登録が行われる（ステップＳ１４４）。この場合、患者データが存在する場合は、診療予約の有無を確認する。来院者は、診療予約があれば予約内容を確認し、診療予約が無ければ問診内容の入力を行う（ステップＳ１４６）。これにより受付処理が完了する。

なお、患者の認証システム（生体認証端末が処理するシステム）は、顔認証システムに限られず、例えば後述する図１１や図１２のフローチャートに示すように、指紋認証システム、虹彩認証システム（図示せず）などのバイオメトリクス認証を用いてもよい。

図１１は、指紋認証システムを用いた受付処理の流れを示すフローチャートである。

図１１に示すように、入退室管理システムでは、医療機関若しくは診察室の入口で、指紋認証システムを用いた受付処理を行うことができる。
即ち、指紋認証システムによる受付処理が開始されると、来院者は受付端末２に指をかざす（ステップＳ７１）。すると、受付端末２によって指紋が読み取られ（ステップＳ７２）、登録済みのデータの照合が行われる（ステップＳ７３）。指紋が照合されると（即ちステップＳ７３がＹＥＳ）、ドアが開錠され（ステップＳ７４）、予約の有無の確認が行われる（ステップＳ７５）。予約がある場合には（即ちステップＳ７５がＹＥＳ）、診察内容の読み込みが行われ（ステップＳ７７）、受付が完了する（ステップＳ８３）。
登録済みのデータの照合（ステップＳ７３）の結果、指紋が照合されない場合には（即ちステップＳ７３がＮＯ）、ドアが解錠され（ステップＳ７８）、保険証等の読取りが行われる（ステップＳ７９）。その後、来院者の顔の撮像が行われて登録され（ステップＳ８０）、問診票の記入（ステップＳ８１）と、指紋の登録（ステップＳ８２）とが行われて、受付が完了する（ステップＳ８３）。
受付が完了すると、診察内容が医師に通知され（ステップＳ８４）、診察の順番が来ると呼び出しが行われる（ステップＳ８５）。これにより、受付処理が完了する。

図１２は、医療事務支援設備において実行される、診察後手続を行うための処理（以下、「診察後処理」と呼ぶ）の流れを示すフローチャートである。

診察が初診である場合には（即ちステップＳ９１がＹＥＳ）、治療計画の登録が行われ（ステップＳ９３）、処理はステップＳ９４に進む。
これに対して、診察が初診でない場合には（即ちステップＳ９１がＮＯ）、治療計画の追加と進捗状況の登録とが行われ（ステップＳ９２）、処理はステップＳ９４に進む。

ステップＳ９４では、診療料金の支払いが済んでいるか否かの判定が行われる。診療料金の支払いが済んでいる場合には（即ちステップＳ９４がＹＥＳ）、処理はステップＳ９５に進む。
これに対して、診療料金の支払いが済んでいない場合には（即ちステップＳ９４がＮＯ）、自動ドアの前で指紋認証が行われたとしても（ステップＳ９９）、自動ドアは開錠されない（ステップＳ１００）。

ステップＳ９５では、薬が処方されたか否かの判定が行われる。薬が処方されている場合には（即ちステップＳ９５がＹＥＳ）、処方箋の印字が行われたうえで（ステップＳ９６）、処理はステップＳ９７に進む。
これに対して、薬が処方されていない場合には（即ちステップＳ９５がＮＯ）、処理はステップＳ９７に進む。

ステップＳ９７では、次回の診察の予約が必要であるか否かの判定が行われる。次回の診察の予約が必要である場合には（即ちステップＳ９７がＹＥＳ）、処理はステップＳ９９に進む。
これに対して、次回の診察の予約が必要でない場合には（即ちステップＳ９７がＮＯ）、処理はステップＳ１０１に進む。

ステップＳ９８では、次回の診察の予約の登録が済んでいるか否かの判定が行われる。次回の診察の予約の登録が済んでいる場合には（即ちステップＳ９８がＹＥＳ）、処理はステップＳ１０１に進む。
これに対して、次回の診察の予約の登録が済んでいない場合には（即ちステップＳ９８がＮＯ）、自動ドアの前で指紋認証が行われたとしても（ステップＳ９９）、自動ドアは開錠されない（ステップＳ１００）。

ステップＳ１０１では、自動ドアの前で指紋認証が行われ、認証されれば自動ドアが開錠される（ステップＳ１０２）。これにより、診察後処理は終了する。

図１３は、電話による受付処理（以下、「電話受付処理」と呼ぶ）が行われる場合の処理の流れを示すフローチャートである。

まず、医療施設の受付が在席している状態で（即ちステップＳ１１１がＹＥＳ）、受付の電話が鳴り（ステップＳ１１２）、受付が電話に出ることができれば（即ちステップＳ１１３がＹＥＳ）、受付が電話に出る。これにより電話受付処理は終了する。これに対し、受付が電話に出ることができない状態（例えば接客中等）である場合には（即ちステップＳ１１３がＮＯ）、電話はコールセンターに転送される（ステップＳ１１４）。

また、医療施設の受付が在席していない場合には（即ちステップＳ１１１がＮＯ）、電話はコールセンターに転送される（ステップＳ１１４）。
コールセンターでは、電話の相手が初診の患者であるかどうかの確認が行われる（ステップＳ１１５）。電話の相手が初診の患者である場合には（即ちステップＳ１１５がＹＥＳ）、症状のヒアリングが行われて（ステップＳ１２２）、予約が受付けられる（ステップＳ１２３）。これにより、電話受付処理は終了する。
これに対して、電話の相手が初診の患者でない場合には（即ちステップＳ１１５がＮＯ）、電話の問合わせの内容が予約の変更であるかどうかの確認が行われる（ステップＳ１１６）。電話の問合わせの内容が予約の変更である場合には（即ちステップＳ１１６がＹＥＳ）、予約の変更が受付けられる（ステップＳ１２４）。これにより、電話受付処理は終了する。

電話の問合わせの内容が予約の変更でない場合には（即ちステップＳ１１６がＮＯ）、医師との通話を希望するかどうかの確認が行われる（ステップＳ１１７）。電話の相手が医師との通話を希望していない場合には（即ちステップＳ１１７がＮＯ）、コールセンターの担当者による症状のヒアリングが行われて（ステップＳ１２２）、予約が受付けられる（ステップＳ１２３）。これにより、電話受付処理は終了する。

電話の相手が医師との通話を希望している場合には（即ちステップＳ１１７がＹＥＳ）、医師による対応を含む医療施設による対応が可能であるかどうかの確認が行われる（ステップＳ１１８）。医療施設による対応が可能でない場合には（即ちステップＳ１１８がＮＯ）、コールセンターの担当者による症状のヒアリングが行われて（ステップＳ１２２）、予約が受付けられる（ステップＳ１２３）。これにより、電話受付処理は終了する。
患者からの希望に対し、医師による対応を含む医療施設による対応が可能である場合には（即ちステップＳ１１８がＹＥＳ）、電話は医療施設に転送され（ステップＳ１１９）、受付又は医師による症状のヒアリングが行われて（ステップＳ１２０）、予約が受付けられる（ステップＳ１２１）。これにより、電話受付処理は終了する。

このように、診療端末３には、コールセンターからの情報も展開される。さらに急ぎ連絡が必要な場合には、患者と直通通話できる電話にも切り替えることができる。なお、コールセンターに設置される端末（図示せず）では、受付が不在の際、熱センサ等で来院者を感知し、受付業務を代理で行うことができる。当該代理には、予約の変更受付も含まれ、インターネットを経由して、予約システムの予約情報の変更をも行う事ができる。また、来院者等からのクレームや急ぎの連絡などを他の診療端末３や事務端末５などにメッセージを送信することができる。さらに、診療端末３のタブレットのマイク機能を遠隔からオン（ＯＮ）若しくはオフ（ＯＦＦ）の操作が可能である。

次に、図１４乃至図１７を参照して、医療事務支援設備Ｇを構成する各端末において実行される処理の流れについて説明する。
上述したように、図１の受付端末２及び手続端末４の夫々は、患者が受付手続及び診察後手続の夫々を行うための端末であるが、受付手続と診察後手続との両者を行うことができる１つの端末とすることもできる。
図１４は、受付手続と診察後手続とを受付けることができる端末（以下、「マルチ端末」と呼ぶ）で実行される処理の流れを示すフローチャートである。

図１４に示すように、マルチ端末は、画面メニューに対する患者の入力操作をトリガとして、「来院登録」、又は「診察料収受」の処理が実行される。
「来院登録」では、来院登録の対象が初診患者である場合、指紋の登録と、顔認証を行うための顔の撮像画像の登録とが行われ、問診表の入力が受付けられる。
「診療料収受」では、診療料金の決済が確認されると、領収書が発行されて、次回の診察の予約が受付けられる。また、薬が処方されている場合には、処方箋が発行されて、次回の診察の予約が受付けられる。

図１５は、診療端末で実行される処理の流れを示すフローチャートである。

図１５に示すように、診療端末３は、画面メニューに対する医師の入力操作をトリガとして、「来院者情報通知」、又は「コールセンター連絡」の処理が実行される。
「来院者情報通知」では、来院者に関する情報の通知が行われる。
「コールセンター連絡」では、コールセンターからのメッセージの受信と、患者との直接の通話の取り次ぎとが行われる。

図１６は、事務端末で実行される処理の流れを示すフローチャートである。

図１６に示すように、事務端末５は、画面メニューに対する事務担当者の入力操作をトリガとして、「レセプト情報登録」、又は「治療状況登録」の処理が実行される。
「レセプト情報登録」では、電子カルテに基づいて作成されたレセプトの情報の登録と、診療料金の登録とが行われる。
「治療状況登録」では、患者の治療状況についての情報の登録と、次回の診察の内容の登録とが行われる。

図１７は、患者端末で実行される処理の流れを示すフローチャートである。

図１７に示すように、患者端末８は、画面メニューに対する患者の入力操作をトリガとして、「予約確認」、「診察予約」、又は「治療状況確認」の処理が実行される。
「予約確認」では、予約されている内容が表示される。また、患者が予約の変更を希望している場合には、予約の変更の登録が行われる。
「診察予約」では、診察の予約が受付けられる。初診である場合には、問診票の登録が行われる。
「治療状況確認」では、治療状況を示す情報の表示と、次回の治療の内容を示す情報の表示とが行われる。

以上のような処理を行う医療事務支援設備Ｇによれば、以下のような具体的なサービスを提供することができる。
例えば、３か月前に歯科医院（医療機関）への来院履歴がある患者Ａが、仕事に忙しく治療も無断で中断し、治療を中断した歯の痛みが再発して再来院した場合が想定される。従来であれば、患者Ａは、電話予約も無しに、歯科医院に直接来院し、受付で診察券を渡し、痛みの状況等を訴える。受付では、事前に予約が無かったので、カルテを検索、閲覧し、急患で来院した患者Ａの情報を得る。受付は、必要な患者データを入力した後、カルテを医師に渡し又は医師はカルテを閲覧することができる。その後、医師はカルテから過去の診察内容の確認を行う。その間、患者Ａは、待合室で問診票などに必要事項を記載する。または、患者Ａが問診票などへの記載が完了してから、カルテ等を検索、閲覧していたため、患者データの確認に時間を要していた。

一方、同様に、患者Ａは、電話予約も無しに、歯科医院に直接来院したと想定する。本発明であれば、来院の際、歯科医院の扉の横に設置された生体認証端末による生体認証確認を受ける。患者Ａに対する生体認証が完了すれば、医院内の受付に、患者名、病歴、中断内容などの治療データにアクセスすることができる。医師等は、アクセスできた治療データにより治療をどこで中断したか、どこに病理があるかを速やかに確認することができる。その後、患者Ａは、歯科医院の扉を通り、待合室で待機することが可能になる。つまり、患者Ａが待合室で待機した時点で、受付などの医療事務担当者及び医師は必要な情報を入手済みである。

また、例えば、従来であれば、患者Ａのカルテの確認と、そのうえでの治療準備に時間を要していた。また、医師としては、患部が痛くなってから急患で来院するのではなく、また、歯科医院のことを考えるようにコーチングする必要があるため、治療の開始が遅れることになる。そのため、患者Ａは、医師及び歯科医院に申し訳ない気分になる。

一方、本発明であれば、前回の診療期間（初診時を含む）内で、患者Ａの治療計画、急患率の部位などを検証しているので、今回の急患来院はある程度予測できている。そこで、医師は、患者Ａに対して今回の救急が予測の範囲内であることを告げることができる。治療そのものも、他の予約診療と同様に、治療に入ることができる。患者Ａは、急患として歯科医院に来診している認識があるにもかかわらず、当該医院では、治療の予測をしている事と、手際のよい流れが実践されていることに安心感や満足感を覚える。また、次に急患で来院しても大丈夫だという安心感を覚える。
具体的には、医師がレントゲンで治療が終わっていない箇所を把握しており、診断を中断し場合、急患になりそうなところを把握できている場合などが該当する。例えば、８本の歯の中で、４本の歯が痛くなるだろうと診療している場合、急患として再来院しても、予想通りであり、その予測がシステムで把握できている場合、医師も患者も治療の前に安心感を得ることができる。

医療機関若しくは診察室の入口は、医療機関若しくは診療室の出口の機能を有するため、入退室管理の機能の他に、診療費用の清算、必要に応じて処方箋の発行、及び次回の予約が可能である。

予約システムには、初診時における治療計画や痛みが出そうな時期の予想などの病状の進捗を入力する。これらの情報は、患者も閲覧、確認することができるため、治療の中断を防止することができる。
また、予約システムは、次回の治療内容を自動検索し、患者に提供することもできる。さらに、予約システムは、治療中断期間を算出することもできる。加えて、１日の予約内容をエクセル等で保存する事ができ、インターネットの無い場所でも確認することが可能である。

例えば、従来であれば、歯科医院による診療後、患者Ａは、受付を治療費の支払い、処方箋の受け取り、次回の予約を行わなければならなかった。ただし、受付処理は、受付人員（人的資源）による処理でなされるため、処理速度には限界がある。また電話が鳴ったりすると、電話対応に人員を奪われるため、時間を要することになる。さらに、万が一、治療費の支払い及び次回の予約を入れずに、患者Ａは歯科医院を自由に出入りできるという不利益が生ずる可能性があった。

一方、本発明であれば、診療後、患者Ａは、受付を通らずに、手続端末４に向かうことができる。手続端末４では、本日の治療費の支払いや、処方箋の受け取りが可能で、次回の予約も可能である。また、万が一、患者Ａが治療費の支払いや予約を行わなかった場合には、警告装置７が、歯科医院の出口（出入口）の扉が閉まった状態のままにする。なお、同時に又は個別に、警報音を発報することや、若しくは警告内容を音声で告知してもよい。

また、予約システムは、医療機関内に設置された端末に限られず、患者が所有する患者端末８から予約システムにアクセスしてもよい。患者端末８からは、予約の確認及び変更、診察予約及び問診登録、治療状況の確認及び次回治療内容の確認が可能である。
また、患者端末８からは、新規予約や既に設定している予約の変更を行うことが可能であり、例えば、治療時間や医師を選択し、予約を行うことも可能である。
さらに、他の患者が予約をキャンセルした場合には、キャンセルされたその時点で予約可能状態を他の患者（利用者）が確認できるため、予約のキャンセルによって時間があいてしまうリスクを軽減することができる。
加えて、２４時間対応可能な予約システム（受付システム）なので、真夜中に痛くなった患者（利用者）が、即時に予約を行う事ができ、少しでも落ち着いていただけるという利点がある。

また、予約システムを介して、患者が医院に入ってきた際の認証により、患者が特定される事から、患者データは診療端末３に送信される。診療端末３は、リアルタイムに全ての情報を受信することができ、必要に応じてそれらの情報は切り替えて表示することができる。
診療端末３には、患者の認証システムによる患者の認証後、初診、中断、予約のそれぞれの情報が表示される。つまり、診療端末３には、必要な来院者情報が通知される。なお、「中断」とは、初診時及び継続治療中の疾患の治療の完治が確認されていない状態をいう。従って、治療が中断された患者の場合は、医師によって認定された疾患であれば、中断疾患の再診となる。一方、中断された患者であっても、医師によって認定されていない疾患であれば、新規疾患に対する新たな診察となる。なお、中断疾患の再診と新規疾患の診察が同時に行われることもある。

近年は、治療を中断した患者が、再来院し易くするシステムが望まれている。通常、歯科医院では、毎日１０％の患者が治療をキャンセル（取り消し）する。突然、治療がキャンセルされることは、歯科医院にとっては空き時間となり、治療による報酬を得ることができなくなる。そればかりか、突然キャンセルした患者は良心の呵責から（申し訳ないと思って）、その後の治療に行きにくくなってしまうと問題があった。この突然のキャンセルが治療中断をした患者が再来院しない理由の上位となっている。
このことは、突然のキャンセルに伴う治療報酬の獲得機会の損失ばかりでなく、継続的に発生する治療の機会をも損失するため、その損失はさらに大きいものとなっていた。
そこで、予約システムをパソコンだけでなくスマートフォン（例えば図１の患者端末８）などの携帯情報端末から、２４時間操作できる事から、気兼ねなく予約時間の変更を行う事ができ、連絡なしキャンセルの防止が可能である。

一方、患者は治療が中断されているので、しばらくすると痛みが出てくる。そのため、再来院する可能性はあるが、急患となる可能性は高くなる。初診時の歯科医院では、予約診療（通常の治療）と異なり、スムーズな治療が開始できない。
また、上述の予約治療を突然キャンセルした患者は、他の歯科医院での治療に切り替えてしまう可能性が高かった。他の歯科医院では、他の歯科医師が中途まで治療した部位を、カルテを新規に作成し直したうえで、治療する必要があった。
そのため、このような行動を回避する必要がある。

上述の様に、予約治療を突然キャンセルした患者が再来院してもらうためには、良心の呵責（申し訳ない）という気持ちを払拭することが重要である。具体的には、初診時に、現在の治療状況や残っている治療計画などが予約システムから確認できる事や、２４時間予約が可能であることから、「中断の患者様が来やすくなるシステム」を導入していることを予め説明しておくことが有益である。

予約システムでは、予約管理を行う。予約の書忘れ、消し忘れ、移動忘れ、予約台帳が一つしかない等の問題を整理する管理機能である。

医療事務支援装置Ｇによれば、歯科用診察椅子（チェア）、歯科医師及びスタッフ毎の管理を行うこともできる。具体的には、チェア、歯科医師及びスタッフの出勤状況、開院状況の３つの要素をもとに、予約可能かどうか瞬時にチェックし、患者（利用者）のダブルブッキングを防止することができる。また、例えば、１０分単位での管理を行う事ができるため、無駄のないスケジュールを実現することができる。
また、患者（利用者）がどうしても都合が悪くなった際も、携帯、ＰＣのインターネット経由で変更が可能となり、再び予約を設定する手間や、受付への連絡が不要とすることができる。

予約の入っている患者（利用者）に対して、診察時間までに事前に設定したタイミングでメールを配信し、確認してもらうアポイント（予約）確認機能を有することができる。予約変更やキャンセルを行った回数や、予定通り来ない患者（利用者）をカウントすることにより、柔軟な対応が可能となり、念入りな予約設定や都合等も考慮に入れた予約が可能となる。

患者（利用者）の予約状況や来院履歴など、予約に関連した情報が蓄積されることにより、予約状況一覧画面では、担当スタッフや担当医師毎の色分けと患者分類での色分けが可能となる。そのため、よりスムーズな医院運営を実施され、患者への接し方に大変役立つことになる。

また、医療事務支援設備Ｇによれば、例えば以下のような問題や課題を解決することができる。
近年、様々な分野において、ペーパレス化、及びキャッシュレス化が進められている。ただし、ペーパレス化、及びキャッシュレス化に伴い生じ得るコストは、顧客（例えば患者）側ではなく、顧客に対し商品やサービスの提供を行う者側（例えば医療施設）が負担することとなる。
具体的には例えば、医療施設におけるクレジットカード決済は、キャッシュレス化の１つであるが、決済額のうち所定割合の額は、代行手数料として医療施設が負担しなければならない仕組みになっている。これは、クレジットカードに限らず、例えば交通機関で利用可能なＩＣカードやスマートフォンによるスマート決済においても同様の仕組みが採用されている。
このように、ペーパレス化、及びキャッシュレス化に伴い生じ得るコストは、顧客に対し商品やサービスの提供を行う者側が全て負担しなければならないという問題がある。

また、従来より、医療施設における診療料金等の支払いは、所定の支払機器（従来品）によって行われる。この支払機器（従来品）は、レセプトから得られる情報に基づいて患者が支払うべき料金の額の算出を行う。
しかしながら、この支払機器（従来品）は、レセプトの点検の代行する会社（以下、「レセプト会社」と呼ぶ）との連携が求められ、さらに、多くのレセプト会社が、支払機器（従来品）の販売権を独占しているとされている。
その結果、支払機器（従来品）は、レセプト会社によって高値で販売され、広く一般に普及されていない状況にあり、支払機器（従来品）を製造するメーカーにおいては、販売台数が伸びないという問題が生じている。

また、従来より、医療施設では、営業時間の終了後、１日の売上額の集計を行うが、その額の辻褄が合わないことがある。このような場合、医療施設では、集計担当者に残業をさせることで売上額の再確認が行われる。
このように、医療施設では、売上額の辻褄が合わない事態が生じた場合、集計担当者に残業代を支払わなければならないため、そのような事態が生じるリスクを低減化させる仕組みを構築したいという問題が存在する。

これらの問題に対し、図１の医療事務支援設備Ｇは、チャージ機能等によって上述の問題を解決することができる。
「チャージ機能」とは、患者が保有する現金のうち所定額を医療事務支援設備Ｇに管理させることで、その所定額（預り金）の範囲内であればいつでも診療料金等の支払いに充てることができる機能のことをいう。チャージ機能によれば、患者は、手続端末４に事前にチャージした額の範囲内であればキャッシュレスで診療料金等の支払いを済ませることができる。また、医療施設は、現金管理が容易化されるとともに、例えばクレジットカード決済のような代行手数料を負担する必要がないので、キャッシュレス化に伴い生じ得るコストを抑えることができる。

具体的には、医療施設において、医師による電子カルテに対する入力操作が完了すると、診療端末３から事務端末５に対し、治療内容を示す情報と、診療料金等を示す情報とが転送される。事務端末５の操作を行う担当者は、必要に応じて請求書又は領収書（以下、「請求書等」と呼ぶ）を発行し、請求書等に記載の精算額を入力する操作、又は請求書等をスキャンすることで精算額を読込ませる操作を行う。これにより、精算額を示す情報は、医療サーバ１により提供される専用のクラウドサービス（以下、「ラクネス」と呼ぶ）に転送される。
医療サーバ１（ラクネス）では、事務端末５から精算額を示す情報が転送されてくると、これに基づいて精算データを生成する。また、生成された精算データを一意に特定可能とするＱＲコード（登録商標）やバーコード等の識別子（以下、「識別コード」と呼ぶ）が生成される。生成された識別コードは、医療サーバ１（ラクネス）から患者端末８に提示される。
患者端末８は、患者の操作に基づいて、医療サーバ１（ラクネス）から提示された識別コードを画面に表示させることができる。患者は、患者端末８の画面に識別コードを表示させ、これを手続端末４にかざして読込ませると、チャージされている額から精算額が差し引かれる。これにより、患者は、キャッシュレスで診療料金等の支払いを行うことができる。

以上は識別コードを患者端末８に表示させることで診療料金等の支払いをキャッシュレスで行う例であるが、患者端末８を用いることなく、例えばＩＣカード（例えばＩＣカード状の診察券）を用いて診療料金等の支払いをキャッシュレスで行うこともできる。
この場合、医療サーバ１（ラクネス）は、事務端末５から転送されてきた精算データと、患者ＩＤ等の識別情報とを対応付けて管理する。患者ＩＤ等の識別情報が記憶されたＩＣカードは、対象となる患者に診察券等として配布される。これにより、患者は、上述の識別コードが表示された患者端末８と同様に、ＩＣカード状の診察券を手続端末４にかざして読込ませると、チャージされている額から精算額が差し引かれる。
また、患者ＩＤ等の識別子は、複数の医療施設で共通して使用することができる。このため、従来のように医療施設毎に発行される診察券を夫々管理する必要がなくなるので、例えば患者が診察券を持参し忘れたりするようなことを防ぐことができる。
また、患者端末８にＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）機能を持たせることで、患者がどこの医療施設に所在するのかを特定することもできる。

以下、チャージ機能を備える医療事務支援設備Ｇによる精算処理の流れについて説明する。
図１８は、チャージ機能を備える図１の医療事務支援設備による精算処理の流れを示すフローチャートである。

ステップＳ２４１において、事務端末５は、必要に応じて請求書等を発行する。
ステップＳ２４１が実行されると、ステップＳ２４２とステップＳ２４３のうち何れかが実行される。
ステップＳ２４２において、事務端末５は、請求書等に記載の精算額を入力する操作を受付けて、受付けた精算額を示す情報を医療サーバ１（ラクネス）に送信する。
また、ステップＳ２４３において、事務端末５は、請求書等をスキャンする操作を受付けて、請求書等に記載の精算額を読込み、読込んだ精算額を示す情報を医療サーバ１（ラクネス）に送信する。

ステップＳ２４４において、医療サーバ１（ラクネス）は、事務端末５からに精算額を示す情報が転送されてくると、これに基づいて精算データを生成する。
ステップＳ２４５において、医療サーバ１（ラクネス）は、識別コードを生成し、患者端末８に提示する。

ステップＳ２４４において、医療サーバ１（ラクネス）は、事務端末５から精算額を示す情報が転送されてくると、これに基づいて精算データを生成する。
ステップＳ２４５において、医療サーバ１（ラクネス）は、識別コードを生成して発行する。発行された識別コードは患者端末８に提示される。

ステップＳ２４６において、患者端末８は、患者の操作に基づいて、医療サーバ１（ラクネス）から提示された識別コードを画面に表示させる。患者は、患者端末８に表示された識別コードを手続端末４にかざす。
ステップＳ２４７において、手続端末４は、患者端末８の画面に表示された識別コードを読込む。これにより、精算手続が開始される。
ステップＳ２４８において、手続端末４は、精算が完了した旨を示すフラグを立てる。
これにより、精算処理が終了する。

図１９は、チャージ機能を備える図１の医療事務支援設備を構成する手続端末の処理の流れを示すフローチャートである。

図１９に示すように、手続端末４は、画面メニューに対する患者の入力操作をトリガとして、「現金によるチャージ」、又は「診察料収受」の処理が実行される。
現金をチャージする処理が行われると、その明細書が発行される。
チャージされた現金の額から診察料の支払いが行われると、その明細書が発行される。その後、次回の診察の予約が可能であることを示すフラグが立てられると、患者端末８で予約を行うことができるようになる。

図２０は、図１の医療サーバにより提供されるラクネスにより管理されるラクネスＩＤの内容を示すイメージ図である。

ラクネスでは、医療施設を一意に特定可能な識別情報としての医療施設ＩＤと、患者ＩＤとの組み合わせからなるラクネスＩＤによる管理が行われる。
具体的には例えば、図２０に示すように、医療施設Ａを示す医療施設ＩＤと、患者Ｘを示す患者ＩＤとの組み合わせからなるラクネスＩＤがラクネスによって管理される。
医療施設Ｂを示す医療施設ＩＤと、患者Ｙを示す患者ＩＤとの組み合わせからなるラクネスＩＤがラクネスによって管理される。
医療施設Ｃを示す医療施設ＩＤと、患者Ｚを示す患者ＩＤとの組み合わせからなるラクネスＩＤがラクネスによって管理される。
医療施設Ｅを示す医療施設ＩＤと、患者Ｘを示す患者ＩＤとの組み合わせからなるラクネスＩＤがラクネスによって管理される。
医療施設Ｄを示す医療施設ＩＤと、患者Ｗを示す患者ＩＤとの組み合わせからなるラクネスＩＤがラクネスによって管理される。
医療施設Ｃを示す医療施設ＩＤと、患者Ｖを示す患者ＩＤとの組み合わせからなるラクネスＩＤがラクネスによって管理される。
ここで例えば、患者Ｘを示す患者ＩＤが「０００１」であり、医療施設Ａを示す医療施設ＩＤが「０Ａ」であり、医療施設Ｅを示す医療施設ＩＤが「０Ｅ」である場合には、「０Ａ０００１」というラクネスＩＤと、「０Ｅ０００１」というラクネスＩＤとの夫々がラクネスによって管理されるが、この２つのラクネスＩＤは、いずれも患者Ｘを対象とするラクネスＩＤであるため、対応付けが行われる。その結果、患者個人の診療料金等の支払いについては、患者ＩＤ（いずれも「０００１」で共通）で管理されるが、医療施設の管理は、医療施設ＩＤ（「０Ａ」と「０Ｅ」）で夫々管理される。

図２１は、ラクネスにより実現可能なサービスの具体例を示すイメージ図である。

図２１に示すように、例えば患者Ｘは、医療施設Ｂでチャージを行った後に、医療施設Ａで診察を受けた場合であっても、医療施設Ｂでチャージした額の範囲内で医療施設Ａに対する診療料金の支払いを行うことができる。
この場合、ラクネスでは、患者Ｘが医療施設Ｂでチャージを行った履歴が医療施設Ｂと医療施設Ａとの夫々に提示される。また、患者Ｘの支払履歴が患者Ｘに提示される。
これように、ラクネスでは、患者は複数の医療施設を利用することができるとともに、その履歴が管理される。
なお、このようにして、チャージが行われた医療施設（上述の例では医療施設Ｂ）と、診察が行われて診療料金が行われた医療施設（上述の例では医療施設Ａ）とが異なる場合、これらの２つの医療施設の間でチャージ及び診療料金の相殺が行われる。具体的には例えば、月まとめで、全ての医療施設について「相殺をするための処理」が夫々実行されて、その処理の結果が各医療施設の夫々に通知される。

図２２は、診察の受診を終えた患者による精算手続の流れを示すフローチャートである。

図２２に示すように、ステップＳ２７１において、患者は、手続端末４を操作することにより、必要に応じて請求書の発行を依頼する。
ステップＳ２７２において、患者は、手続端末４を操作することにより、精算手続を行うための操作画面を表示させる。
ステップＳ２７３において、患者は、手続端末４を操作することにより、預り金（チャージされた金額）の残高を表示させて確認する。
ステップＳ２７４において、患者は、預り金（チャージされた金額）の残高で精算可能であるかを判断する。預り金（チャージされた金額）の残高で精算が可能である場合には、ステップＳ２７４において、「ＹＥＳ」と判定されて、精算手続はステップＳ２７６に進む。これに対して、預り金（チャージされた金額）の残高で精算できない（残高不足等）場合には、ステップＳ２７４において、「ＮＯ」と判定されて、精算手続はステップＳ２７５に進む。
ステップＳ２７５において、患者は、手続端末４と患者端末８を操作することによりチャージを行う。このとき、患者は、患者端末８に識別コードを表示させることで、個人認証における個人の証明を行う。
ステップＳ２７６において、患者は、手続端末４を操作することにより、預り金（チャージされた金額）による精算手続を行う。
ステップＳ２７７において、患者は、手続端末４を操作することにより、必要に応じて領収書の発行を依頼する。
ステップＳ２７８において、患者は、手続端末４を操作することにより、支払履歴の確認を行う。
これにより、患者による精算手続は完了する。

図２３は、診察の受診を終えた患者が子供である場合や、患者に後見人がいる場合の精算手続の流れを示すフローチャートである。

図２３に示すように、ステップＳ２８１において、患者は、手続端末４を操作することにより、必要に応じて請求書の発行を依頼する。
ここで、診察の受診を終えた患者が子供である場合や、患者に後見人がいる場合には、患者本人ではなく支払責任者による精算処理が行われる。
ステップＳ２８２において、患者の支払責任者は、手続端末４を操作することにより、精算手続を行うための操作画面を表示させる。
ステップＳ２８３において、患者の支払責任者は、手続端末４を操作することにより、預り金（チャージされた金額）の残高を表示させて確認する。
ステップＳ２８４において、患者の支払責任者は、預り金（チャージされた金額）の残高で精算可能であるかを判断する。預り金（チャージされた金額）の残高で精算が可能である場合には、ステップＳ２８４において、「ＹＥＳ」と判定されて、精算手続はステップＳ２８６に進む。これに対して、預り金（チャージされた金額）の残高で精算できない（残高不足等）場合には、ステップＳ２８４において、「ＮＯ」と判定されて、精算手続はステップＳ２８５に進む。
ステップＳ２８５において、患者の支払責任者は、振込入金を行うか手続端末４と患者端末８を操作することによりチャージを行う。このとき、患者の支払責任者は、患者端末８に識別コードを表示させることで、個人認証における個人（患者）の証明を行う。
ステップＳ２８６において、患者の支払責任者は、手続端末４を操作することにより、預り金（チャージされた金額）による精算手続を行う。
ステップＳ２８７において、患者の支払責任者は、手続端末４を操作することにより、領収書の発行を依頼する。
ステップＳ２８８において、患者の支払責任者は、手続端末４を操作することにより、支払履歴の認を行う。
これにより、患者の支払責任者による精算手続は完了する。

ここで、介護施設における精算手続について説明する。
介護施設における診療の種類は、訪問診療と通院診療とに大別される。
従来は、訪問医師や介護施設、もしくは入所者の親族の夫々が、診療の費用の支払いの管理と、診療履歴の管理を行う必要があった。
この点、上述の実施形態によれば、クラウド上に診療内容（レセプト）及び支払い金額の情報がアップされるため、訪問する医師は通院診療に基づく患者情報を紙媒体で持ち出さなくてもよくなり、診察時の負担が軽減され、患者の個人情報漏洩防止ともなる。また、診療の費用の支払いをしてもらうために訪問医師が自己の所属する医院において介護施設または親族に請求書及び領収書を送付する必要があったところ、これらもクラウド上の管理となるため請求書と領収書を作成する人手、送付するための郵送料を削減することが可能となる。
一方、介護施設においては、どの入所者がどのような支払いや診療を受けたかを個々に管理するという負担がなくなる。
特に通院診療においては通院先での支払いが必要になるため、診療の費用を予測して予め患者親族からその金額の現金を患者が預かる等をしなくてはならず、管理のみならず現金管理負担まで生じていたが、これも上述のチャージ機能により回避できる。具体的には例えば、介護施設内に診療の費用分をチャージするための端末を設置しておくことにより、親族が施設訪問時にその端末を用いて患者端末にチャージしておいてもらうことで、診療の費用を予測して施設に預けてもらうといったことをしなくてよくなる。さらに、親族においても、診療の費用の支払いのために施設訪問をしなければならない、といった負担が軽減されることになる。

以上、本発明の実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。また、上述の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、上述の実施形態に記載されたものに限定されるものではない。

例えば、上述の実施形態では、医療施設、及び医療施設を利用する患者の夫々を対象とするサービスであることを前提に記載しているが、医療施設、及び医療施設を利用する患者に限定されない。商品又は役務の提供が行われるあらゆる施設等、及びその施設等を利用する者を対象とするサービスとして本発明を適用することもできる。

上述した実施形態における一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。

一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであっても良い。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えば汎用のパーソナルコンピュータであっても良い。

このようなプログラムを含む記録媒体は、ユーザにプログラムを提供するために装置本体とは別に配布されるリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される記録媒体等で構成される。リムーバブルメディアは、例えば、磁気ディスク（フロッピーディスクを含む）、光ディスク、又は光磁気ディスク等により構成される。光ディスクは、例えば、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ−Ｒｅａｄ Ｏｎｌｙ ＭｅｍｏｒｙＹ），ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等により構成される。光磁気ディスクは、ＭＤ（ＭＩＮＩ ＤＩＳＫ）等により構成される。また、装置本体に予め組み込まれた状態でユーザに提供される記録媒体は、例えば、プログラムが記録されているＲＯＭや、記憶部に含まれるハードディスク等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。

図１に示すシステム構成は、本発明の目的を達成するための例示に過ぎず、特に限定されない。即ち、夫々の装置の役割を実行することができる機能が情報処理システム内に備えられていれば良く、さらに、夫々の装置は、ネットワークを介さずに、直接接続されていても良い。

図２に示す各ハードウェア構成は、本発明の目的を達成するための例示に過ぎず、特に限定されない。例えば、１つのハードウェアが他のハードウェアの機能を兼ね備えていても良く、同じ機能を持つハードウェアが複数含まれていても良い。

また、図３の機能的構成は例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能がサーバ１に備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図３の例に限定されない。
また、１つの機能ブロックは、ハードウェア単体で構成しても良く、ソフトウェア単体で構成しても良く、それらの組み合わせで構成しても良い。

以上まとめると、本発明が適用される情報処理装置は、次のような構成を取れば足り、各種各様な実施形態を取ることができる。
即ち、本発明が適用される情報処理装置（例えば図１の医療サーバ１）は、
商品又は役務の対象の提供が行われる施設で、前記対象の提供を受ける顧客の順番を示す第１情報（例えば順番データ）を生成して、前記顧客毎に管理する第１管理手段（例えば図３の順番管理部１０１）と、
前記顧客に提示される、前記第１情報を示す媒体（例えば順番カード）を出力する制御を実行する出力手段（例えば図３の発行制御部１０２）と、
前記媒体を所持する前記顧客の前記施設内における位置を示す第２情報（例えば患者位置情報）を前記第１情報に紐付けて管理する第２管理手段（例えば図３の位置管理部１０３）と、
前記商品又は役務の内容を示す第３情報（例えば電子カルテ）を前記第１情報に紐付けて管理する第３管理手段（例えば図３の診察管理部１０４）と、
前記第３情報を少なくとも含む情報に基いて決定された前記対象の料金の額の決済を含む、前記対象の提供の後に行われる手続（例えば「診察後手続」）の進捗状況を示す第４情報（例えば手続進捗情報）を、前記第１情報に対応付けて管理する第４管理手段（例えば図３の手続管理部１０５）と、
前記第１情報と、前記第２情報と、前記第３情報と、前記第４情報とに基づいて、前記顧客の移動の状況と、手続の状況とが一致しているか否かの監視を行う監視手段（例えば図３の監視部１０６）と、
を備える。

これにより、第１管理手段が、商品又は役務の対象の提供が行われる施設で、その対象の提供を受ける顧客の順番を示す第１情報を生成して、顧客毎に管理し、出力手段が、顧客に提示される、第１情報を示す媒体を出力する制御を実行する。また、第２管理手段が、媒体を所持する顧客の施設内における位置を示す第２情報を第１情報に紐付けて管理し、第３管理手段が、商品又は役務の内容を示す第３情報を第１情報に紐付けて管理する。また、第４管理手段が、第３情報を少なくとも含む情報に基いて決定された商品又は役務の対象の料金の額の決済を含む、商品又は役務の対象の提供の後に行われる手続の進捗状況を示す第４情報を、第１情報に対応付けて管理する。また、監視手段が、第１情報と、第２情報と、第３情報と、第４情報とに基づいて、顧客の移動の状況と、手続の状況とが一致しているか否かの監視を行う。
その結果、顧客に携帯情報端末に対する操作を行わせることなく、商品又は役務の提供を行う施設の受付事務手続における人員の削減や省力化を図ることができる。

また、前記第１管理手段は、前記第１情報として、前記施設としての医療施設で医師の診療を受ける患者の順番を示す情報を生成して、前記患者毎に管理し、
前記出力手段は、前記患者に提示される、前記第１情報を示す媒体を出力する制御を実行し、
前記第２管理手段は、前記第２情報として、前記媒体を所持する前記患者の前記医療施設内における位置を示す情報を、前記第１情報に紐付けて管理し、
前記第３管理手段は、前記第３情報として、前記医師による前記患者の診療の内容を示す情報を、前記第１情報に紐付けて管理し、
前記第４管理手段は、前記第４情報として、前記第３情報を少なくとも含む情報に基いて額が決定された前記診療の料金の決済を含む、前記診療の後に行われる手続の進捗状況を示す情報を、前記第１情報に対応付けて管理し、
前記監視手段は、前記第１情報と、前記第２情報と、前記第３情報と、前記第４情報とに基づいて、前記患者の移動の状況と、手続の状況とが一致しているか否かの監視を行うことができる。

これにより、患者に携帯情報端末に対する操作を行わせることなく、医療機関の受付事務手続における人員の削減や省力化を図ることができる。

また、前記監視手段による監視の結果、前記患者の移動の状況と手続の状況とが一致しない場合には、当該患者に所定の警告を行う制御を実行する警告制御手段（例えば図３の警告制御部１０７）をさらに備えることができる。

これにより、患者の勘違いや不正を防ぐことができる。

また、前記第４管理手段は、前記第４情報として、処方箋の有無を示す情報を、前記第１情報に対応付けて管理することができる。

これにより、患者に携帯情報端末に対する操作を行わせることなく、医療機関における処方箋の受付事務を含む諸手続における人員の削減や省力化を図ることができる。

また、前記第４管理手段は、前記第４情報として、次回の前記診療の予約の有無を示す情報を、前記第１情報に対応付けて管理することができる。

これにより、患者に携帯情報端末に対する操作を行わせることなく、医療機関における予約の受付事務を含む諸手続における人員の削減や省力化を図ることができる。

また、前記第４管理手段は、さらに、前記診療の料金の決済のために前記患者により預け入れられた預り金の額を示す第５情報（例えばチャージされた預り金の額を示す情報）と、当該患者を一意に特定可能な所定の識別情報を少なくとも含む第６情報（例えば患者ＩＤ）とを対応付けて管理することができる。

これにより、患者は、事前に預け入れた預り金の額の範囲内であれば、キャッシュレスで診療も料金の決済を済ませることができる。また、医療施設は、現金管理が容易化されるとともに、例えばクレジットカード決済のような代行手数料を負担する必要がないので、キャッシュレス化に伴い生じ得るコストを抑えることができる。

また、前記第４管理手段は、前記第３情報（例えば電子カルテ）を少なくとも含む情報（例えばレセプト）に基いて決定された前記診療の料金の額を示す第７情報（例えば精算データ）を、前記第１情報（例えば順番データ）にさらに対応付けて管理し、
前記第４管理手段により管理されている前記第７情報を一意に特定可能な識別子（例えばＱＲコード（登録商標））を生成する生成手段（例えば図３のコード生成部１０８）をさらに備えることができる。

これにより、患者は、キャッシュレスで診療料金等の支払いを行うことができる。また、医療施設は、キャッシュレス化やペーパレス化に容易に対応することができる。

Ｓ・・・医療事務支援設備、２・・・受付端末、３・・・診療端末、４・・・手続端末、５・・・事務端末、６・・・カード検知器、７・・・警告装置、８・・・患者端末、１・・・医療サーバ、１１・・・ＣＰＵ、１２・・・ＲＯＭ、１３・・・ＲＡＭ、１４・・・バス、１５・・・入出力インターフェース、１６・・・出力部、１７・・・入力部、１８・・・記憶部、１９・・・通信部、２０・・・ドライブ、３０・・・リムーバブルメディア、１０１・・・順番管理部、１０２・・・発行制御部、１０３・・・位置管理部、１０４・・・診察管理部、１０５・・・手続管理部、１０６・・・監視部、１０７・・・警告制御部、１０８・・・コード生成部、１８１・・・患者ＤＢ、１８２・・・カードＤＢ、Ｓ・・・各ステップ、Ｎ・・・通信回線網

Claims (7)

1. 商品又は役務の対象の提供が行われる施設で、前記対象の提供を受ける顧客の順番を示す第１情報を生成して、前記顧客毎に管理する第１管理手段と、
   前記顧客に提示される、前記第１情報を示す媒体を出力する制御を実行する出力手段と、
   前記媒体を所持する前記顧客の前記施設内における位置を示す第２情報を前記第１情報に紐付けて管理する第２管理手段と、
   前記商品又は役務の内容を示す第３情報を前記第１情報に紐付けて管理する第３管理手段と、
   前記第３情報を少なくとも含む情報に基いて決定された前記対象の料金の額の決済を含む、前記対象の提供の後に行われる手続の進捗状況を示す第４情報を、前記第１情報に対応付けて管理する第４管理手段と、
   前記第１情報と、前記第２情報と、前記第３情報と、前記第４情報とに基づいて、前記顧客の移動の状況と、手続の状況とが一致しているか否かの監視を行う監視手段と、
   を備え、
   前記第１管理手段は、前記第１情報として、前記施設としての医療施設で医師の診療を受ける患者の順番を示す情報を生成して、前記患者毎に管理し、
   前記出力手段は、前記患者に提示される、前記第１情報を示す媒体を出力する制御を実行し、
   前記第２管理手段は、前記第２情報として、前記媒体を所持する前記患者の前記医療施設内における位置を示す情報を、前記第１情報に紐付けて管理し、
   前記第３管理手段は、前記第３情報として、前記医師による前記患者の診療の内容を示す情報を、前記第１情報に紐付けて管理し、
   前記第４管理手段は、前記第４情報として、前記第３情報を少なくとも含む情報に基いて額が決定された前記診療の料金の決済を含む、前記診療の後に行われる手続の進捗状況を示す情報を、前記第１情報に対応付けて管理し、
   前記監視手段は、前記第１情報と、前記第２情報と、前記第３情報と、前記第４情報とに基づいて、前記患者の移動の状況と、手続の状況とが一致しているか否かの監視を行い、
   前記第３情報は、前記患者の診療の内容として、前記患者が急患として再来院する可能性を示す情報と、その根拠となる情報とを含み、
   前記第３情報に基づいて、前記患者が急患として再来院した場合における前記医師の診療の内容及び流れの予測を行う予測手段をさらに備える、
   情報処理装置。
2. 前記第４管理手段は、前記第４情報のうち前記診療の後に行われる手続の進捗状況を示す情報として、前記患者の次回の前記診療の予約の手続の進捗状況を示す情報を、前記第１情報に対応付けて管理し、
   前記患者の次回の診療の予約の手続の進捗状況を示す情報には、前記患者の過去における前記診療の予約の変更及び前記診療の予約のキャンセルの実績に関する情報が含まれ、
   前記患者の過去における診療の予約の変更及び診療の予約のキャンセルの実績に関する情報を考慮して、前記患者の診療の予約を受付ける予約受付手段をさらに備える、
   請求項１に記載の情報処理装置。
3. 前記監視手段による監視の結果、前記患者の移動の状況と手続の状況とが一致しない場合には、当該患者に所定の警告を行う制御を実行する警告制御手段をさらに備える、
   請求項１又は２に記載の情報処理装置。
4. 前記第４管理手段は、前記第４情報として、処方箋の有無を示す情報を、前記第１情報に対応付けて管理する、
   請求項１乃至３のうちいずれか１項に記載の情報処理装置。
5. 前記第４管理手段は、前記第４情報として、次回の前記診療の予約の有無を示す情報を、前記第１情報に対応付けて管理する、
   請求項１乃至４のうちいずれか１項に記載の情報処理装置。
6. 前記第４管理手段は、さらに、前記診療の料金の決済のために前記患者により預け入れられた預り金の額を示す第５情報と、当該患者を一意に特定可能な所定の識別情報を少なくとも含む第６情報とを対応付けて管理する、
   請求項１乃至５のうち、いずれか１項に記載の情報処理装置。
7. 情報処理装置を制御するコンピュータに、
   商品又は役務の対象の提供が行われる施設で、前記対象の提供を受ける顧客の順番を示す第１情報を生成して、前記顧客毎に管理する第１管理ステップと、
   前記顧客に提示される、前記第１情報を示す媒体を出力する制御を実行する出力ステップと、
   前記媒体を所持する前記顧客の前記施設内における位置を示す第２情報を前記第１情報に紐付けて管理する第２管理ステップと、
   前記商品又は役務の内容を示す第３情報を前記第１情報に紐付けて管理する第３管理ステップと、
   前記第３情報を少なくとも含む情報に基いて決定された前記対象の料金の額の決済を含む、前記対象の提供の後に行われる手続の進捗状況を示す第４情報を、前記第１情報に対応付けて管理する第４管理ステップと、
   前記第１情報と、前記第２情報と、前記第３情報と、前記第４情報とに基づいて、前記顧客の移動の状況と、手続の状況とが一致しているか否かの監視を行う監視ステップと、
   を含む制御処理を実行し、
   前記第１管理ステップは、前記第１情報として、前記施設としての医療施設で医師の診療を受ける患者の順番を示す情報を生成して、前記患者毎に管理するステップを含み、
   前記出力ステップは、前記患者に提示される、前記第１情報を示す媒体を出力する制御を実行するステップを含み、
   前記第２管理ステップは、前記第２情報として、前記媒体を所持する前記患者の前記医療施設内における位置を示す情報を、前記第１情報に紐付けて管理するステップを含み、
   前記第３管理ステップは、前記第３情報として、前記医師による前記患者の診療の内容を示す情報を、前記第１情報に紐付けて管理するステップを含み、
   前記第４管理ステップは、前記第４情報として、前記第３情報を少なくとも含む情報に基いて額が決定された前記診療の料金の決済を含む、前記診療の後に行われる手続の進捗状況を示す情報を、前記第１情報に対応付けて管理するステップを含み、
   前記監視ステップは、前記第１情報と、前記第２情報と、前記第３情報と、前記第４情報とに基づいて、前記患者の移動の状況と、手続の状況とが一致しているか否かの監視を行うステップを含み、
   前記第３情報は、前記患者の診療の内容として、前記患者が急患として再来院する可能性を示す情報と、その根拠となる情報とを含み、
   前記第３情報に基づいて、前記患者が急患として再来院した場合における前記医師の診療の内容及び流れの予測を行う予測ステップをさらに含む、
   プログラム。
   

Images