JP2009193134A

JP2009193134A - 来院支援装置及び方法、並びに医用ネットワークシステム

Info

Publication number: JP2009193134A
Application number: JP2008030562A
Authority: JP
Inventors: Kiyohisa Okusu; 清央大楠
Original assignee: Fujifilm Corp
Current assignee: Fujifilm Corp
Priority date: 2008-02-12
Filing date: 2008-02-12
Publication date: 2009-08-27

Abstract

【課題】来院しなかった理由が単なる失念ではない患者に対する来院を促すメッセージの実効性を高める。
【解決手段】メッセージ通知サーバは、予約日に来院しない患者に対してメッセージを通知する。メッセージ通知サーバには、メッセージの通知方法を決定する通知方法決定部４１ｂが設けられている。通知方法決定部４１ｂは、患者特性情報３４から患者の来院確度情報を読み出して、通知方法を決定する。来院確度情報には、過去の事後メッセージの通知回数や予約日に来院しなかった未来院回数が含まれている。メッセージには、警告レベルが異なる複数のメッセージが用意されており、来院する確度が低い患者と高い患者とで警告レベルを変化させる。
【選択図】図７

Description

本発明は、患者宛に来院を促すメッセージを通知する来院支援装置及び方法、並びに医用ネットワークシステムに関するものである。

診察や検査などの診療の予約をした患者に対して、予約日前に予約日を案内するメッセージを通知したり、予約日に来院しなかった患者に対して来院を促すメッセージを通知する来院支援装置（例えば、特許文献１及び特許文献２参照）が知られている。予約日の失念といった理由から来院しない患者も多いため、こうした来院支援装置は有用性がある。

特許文献２には、複数の医療施設のコンピュータシステムと通信ネットワークを介して接続して、各医療施設に対してアプリケーションサービスを提供するデータセンタが記載されている。データセンタのコンピュータシステムは、予め医療施設から提供された複数の患者の患者基本情報が登録されるデータベースを備えている。患者基本情報には、患者の予約日と患者の連絡先のメールアドレスが含まれている。データセンタのコンピュータシステムは、患者毎の予約日に応じて、患者の携帯電話等にメッセージをメール形式で送信する。通知内容や一定期間内における通知回数といった通知方法は、患者に関わらず一律であり、予約日に来院しなかった患者に対しては、予約日後にメッセージを１回通知した後、所定期間を過ぎても来院が無い場合には再度メッセージが通知される。

また、患者基本情報には、患者の病態（高血圧であるなど）といった属性データが含まれている。データセンタのコンピュータシステムは、患者の属性データに応じたトピック（花粉症や冬の寒さの対策など）をメッセージに追加して配信する機能を有している。
特開２００２−０９２１８５号公報特開２００５−２８５０３３号公報

特許文献２の来院支援装置は、患者に関わらず一律の通知方法でメッセージを通知しているが、こうした通知方法は、予約日に来院しなかった理由が単なる失念である患者や、特許文献２に実施例として記載されているように、在宅治療が必要な患者など、自らの傷病に対する正しい認識をもち、来院しなければならないことを自覚している患者に対しては、一定の効果が期待できる。

しかしながら、約束を守るというモラルが低かったり、無精であったり、自らの傷病に対して認識が不足していたりする患者に対して、同じ内容のメッセージを再通知したところで、来院への動機付けを与えることは難しく、効果は期待できない。また、特許文献２の来院支援装置では、メッセージに、患者の属性データに応じたトピックを追加しているが、予約した診療にあまり関係がないトピックを追加したところで、来院への動機付けには何ら効果がない。このため、より実効性の高い通知方法が模索されていた。

そもそも、メッセージを通知する目的は、医療施設内の診療業務を予定通り行うためといった業務効率化の側面というよりも、例えば、検査の結果、病態が憂慮される患者など再診療の必要性が高い患者に対して、必ず来院してもらうようにするといった医療倫理的な側面が強い。医療倫理的な側面からは、来院の意思が薄弱な患者であっても、再診療の必要性が高い場合には放置しておくことはできない。この場合の最終手段としては、患者の担当医師が患者に対して電話などで連絡をとるといった直接的な対応が望まれるが、そうした対応は繁忙を極める医療現場の実情を考慮すると限界がある。そのため、直接的な対応を取らなければならない患者の数をできるだけ減らしたいという要望もある。

本発明は、こうした背景に鑑みてなされたもので、その目的は、来院しなかった理由が単なる失念ではない患者に対するメッセージの実効性を高めることにある。

本発明の来院支援装置は、診療を予約した患者宛てに来院を促すメッセージを通知する通知手段と、前記患者が来院する確度を表す来院確度情報に基づいて、前記メッセージの通知内容及び一定期間内における通知回数のうち少なくとも１つを含む通知方法を決定する通知方法決定手段とを備えたことを特徴とする。

前記通知方法決定手段は、来院する確度が高い患者に比べて、来院する確度が低い患者に対する、前記通知内容のレベル及び前記通知回数のうち少なくとも１つを増やすことが好ましい。

前記通知方法決定手段は、前記来院確度情報に加えて、前記患者の傷病情報に基づいて、前記通知方法を決定することが好ましい。

前記傷病情報は、傷病名、過去の診療の結果、傷病の重篤度、今回予約した診療の緊急度のうち少なくとも１つを含むことが好ましい。

前記来院確度情報は、前記メッセージのうち、過去の診療予約日後に通知した事後メッセージの通知回数を含むことが好ましい。

前記来院確度情報は、過去の診療予約日に来院しなかった未来院回数を含むことが好ましい。

前記通知内容には、今回の診療予約日と病院に関する基本情報が少なくとも含まれ、
予約の空き状況に関する予約空き情報、ネットワークを通じて予約を受け付ける予約サイトのアドレス、及び前記患者の担当医療スタッフの警告文のうち少なくともいずれか１つは、前記来院確度情報に応じて前記通知内容に追加されることが好ましい。

前記来院確度情報は、前記メッセージのうち、過去の診療予約日後に通知した事後メッセージの通知回数を含み、前記通知方法決定手段は、前記事後メッセージの通知回数が第一の規定回数以上となったときに、前記予約空き情報または前記予約サイトのアドレスを前記通知内容に追加し、前記事後メッセージの通知回数が前記第一の規定回数よりも多い第二の規定回数となったときに、前記警告文を前記通知内容に追加することが好ましい。

前記来院確度情報は、過去の診療予約日に来院しなかった未来院回数を含み、前記通知方法決定手段は、前記未来院回数が第三の規定回数以上となったときに、前記予約空き情報または前記予約サイトのアドレスを前記通知内容に追加し、前記未来院回数が前記第三の規定回数よりも多い第四の規定回数以上となったときに、前記警告文を前記通知内容に追加することが好ましい。

本発明の来院支援方法は、診療を予約した患者宛てに来院を促すメッセージを通知する来院支援方法において、前記患者が来院する確度を表す来院確度情報に基づいて、前記メッセージの通知内容及び一定期間内における通知回数のうち少なくとも１つを含む通知方法を、通知方法決定手段で決定する通知方法決定ステップと、決定した通知方法で前記メッセージを通知する通知ステップとを備えたことが好ましい。

本発明の医用コンピュータシステムは、複数の医療施設に設けられた複数の第１コンピュータシステムと、前記第１コンピュータシステムとネットワークを介して通信可能に接続されたデータセンタの第２コンピュータシステムとからなる医用ネットワークシステムにおいて、前記第２コンピュータシステムは、前記医療施設の診療を予約した患者の予約日を含む予約情報を管理する情報管理装置と、前記第１コンピュータシステムから取得した、前記患者が来院する確度を表す来院確度情報を格納する情報格納装置と、前記予約情報を元に、診療を予約した患者宛てに来院を促すメッセージを通知する来院支援装置とを備えており、前記来院支援装置は、前記情報格納装置から前記来院確度情報を読み出し、前記来院確度情報に基づいて、通知内容及び一定期間内における通知回数のうち少なくとも１つを含む通知方法を決定する通知方法決定手段を有することを特徴とする。

本発明は、患者が来院する確度の情報に基づいて、来院しなかった理由が単なる失念ではない患者の来院を積極的に促すようにメッセージの通知方法を決定するから、来院しなかった理由が単なる失念ではない患者に対するメッセージの実効性を高めることができる。

図１に示す医用ネットワークシステム１０は、データセンタ１１のコンピュータシステムと、このコンピュータシステムと通信ネットワークによって接続された、病院１２及び診療所１３の各医療施設のコンピュータシステムとからなる。

病院１２は、例えば、地域における医療施設の中で比較的大規模な医療施設であり、ＣＴ（Computed Tomography）装置やＭＲＩ（Magnetic Resonance Imaging）装置など高度な医療検査設備（モダリティ）を保有し、外部の医療施設からの検査及びそれに付随する診察といった診療依頼を受託する医療施設である。診療所１３は、そうしたモダリティを持たず、病院１２に対して診療を委託する比較的小規模な医療施設の例である。病院１２は、診療所１３から、患者１４の診療依頼をデータセンタ１１経由で受け付けて、診療を受託する。

データセンタ１１のコンピュータシステムは、病院１２及び診療所１３のそれぞれのコンピュータシステムを構成する各クライアント端末１６、１７とＷＡＮ（Wide Area Network）１８を介して通信可能に接続されており、クライアント端末１６、１７からの要求に応じて、医用データのコピーを保管するデータバックアップサービス、診療予約サービス、患者宛のメッセージ通知サービスといったアプリケーションサービスを提供する。各クライアント端末１６、１７には、例えば、ＨＴＴＰ(Hypertext Transfer Protocol)に対応したブラウザソフトがインストールされており、ブラウザソフトを通じてデータセンタ１１のコンピュータシステムと通信を行ってアプリケーションサービスを受ける。

メッセージ通知サービスは、病院１２で診療の予約をした患者１４に対して、リマインダなどの予約日前に予約日を案内して来院を促す事前メッセージや、患者１４が予約日に来院しなかった場合に、事後的に来院を促す旨の事後メッセージを通知するサービスである。メッセージ通知サービスは、病院１２の依頼に基づいて行われ、データセンタ１１から、例えば、患者１４のメールアドレスにメッセージをメール形式で通知する。通知されたメッセージは、携帯電話やＰＤＡといった患者１４の携帯端末１９やＰＣ（パーソナルコンピュータ）で受信される。

ＷＡＮ１８は、広域ＩＰ（Internet Protocol）ネットワーク、公衆電話網、専用線といった広域通信網である。データセンタ１１と、病院１２や診療所１３のそれぞれとを結ぶＷＡＮ１８としては、例えば、情報セキュリティと通信コストのバランスを考慮して、通信事業者が提供するＩＰネットワークやインターネットなどの共有ネットワーク上に専用回線を仮想的に構築するＶＰＮ（Virtual Private Network）が使用される。患者１４の携帯端末１９宛てにメッセージを通知する際には、例えば、インターネットが使用される。

診療所１３が病院１２へ診療を予約する場合には、依頼元となる診療所１３は、患者１４の都合を確認してデータセンタ１１経由で病院１２に予約を入れる。データセンタ１１は、各病院１２の予約受付可能日を記録したスケジュールデータを管理しており、診療所１３のクライアント端末１７からのアクセスを受け付けて、クライアント端末１７にスケジュールデータを配信する。

診療所１３は、受信したスケジュールを表示した予約画面から空き状況を確認して、依頼先の病院１２宛の予約申し込み情報を、クライアント端末１７からデータセンタ１１に送信する。予約申し込み情報には、依頼元の診療所名、患者名、希望受診日、検査目的などが含まれる。検査目的は、患者の傷病名、検査種別（ＣＴ検査やＭＲＩ検査など）、依頼先へ特に検査してもらいたい項目などである。病院１２は、依頼元からの予約申し込み情報をデータセンタ１１経由で受信する。

病院１２のコンピュータシステムは、各クライアント端末１６と、病院ＤＢ（Data Base）サーバ２１とからなり、ルータ２２を介してＷＡＮ１８と接続されている。各クライアント端末１６は、データセンタ１１に接続して、依頼元からの予約申し込み情報を受信する受付用端末、外科や内科といった各診療部門に配置された診療科端末、放射線科や内視鏡科といった各検査部門に配置された検査依頼管理端末及び医用レポート作成端末といった各種の端末として利用される。

受付用端末には、データセンタ１１のコンピュータシステムと通信するためのブラウザソフトがインストールされている。受付用端末は、ブラウザソフトを通じてデータセンタ１１にアクセスして、依頼元からの予約申し込み情報を受信して、検査スケジュールを管理する。

各クライアント端末１６は、病院１２内のＬＡＮ２３を介して通信可能に接続されており、各端末１６相互間でメール連絡といった通信を行う。また、クライアント端末１６は、ＬＡＮ２３を介して病院ＤＢサーバ２１と通信を行って、病院ＤＢサーバ２１内のデータにアクセスできるようになっている。また、ＬＡＮ２３には、複数のモダリティ（図示せず）が接続されており、各モダリティで撮影された検査画像は、ＬＡＮ２３を通じて病院ＤＢサーバ２１に送信されて格納される。

病院ＤＢサーバ２１は、例えば、ワークステーションをベースにＤＢＭＳ（Data Base Management System）をインストールして構成される。病院ＤＢサーバ２１は、患者のカルテデータを格納したカルテＤＢ、検査データを格納した検査データＤＢといった各種のＤＢを管理する。検査データには、モダリティで撮影された検査画像の他、生理検査や検体検査で得られた数値データや心電図、検査結果をまとめたレポートなどが含まれる。病院ＤＢサーバ２１は、各クライアント端末１６からの要求に応じて、各ＤＢ内へのデータ格納処理、各ＤＢ内のデータ検索処理を実行する。

ルータ２２は、病院１２内のＬＡＮ(Local Area Network)２３とＷＡＮ１８といった異なるネットワーク間でデータの受け渡しを行う転送機器であり、ＬＡＮ２３と接続するＬＡＮポートと、ＷＡＮ１８と接続するＷＡＮポートを備えている。

データセンタ１１のコンピュータシステムは、予約管理サーバ２６、センタＤＢサーバ２７、メッセージ通知サーバ２８、ルータ２９からなり、これらは、ＬＡＮ３０を介して通信可能に接続されている。ルータ２９は、ルータ２２と同様であり、ＬＡＮ３０とＷＡＮ１８の間でデータ転送を行う。

予約管理サーバ２６には、依頼先となる各病院１２の予約受付枠に対応したスケジュールデータが格納されており、クライアント端末１６、１７からの配信要求に応じて、スケジュールデータを配信する。配信されたスケジュールデータは、各クライアント端末１６、１７において、例えば、カレンダ形式で表示される。予約管理サーバ２６は、依頼元の診療所１３から予約申し込み情報を受信してスケジュールデータを更新し、更新したスケジュールデータを依頼先の病院１２へ配信する。

センタＤＢサーバ２７は、例えば、病院ＤＢサーバ２１と同様に、ワークステーションにＤＢＭＳをインストールして構成される。センタＤＢサーバ２７は、予約管理サーバ２６が依頼元から受信した予約申し込み情報を格納する予約情報ＤＢ３１と、患者情報を格納する患者情報ＤＢ３２を有する。患者情報は、データセンタ１１に対して、データバックアップサービス、検査予約サービス、メッセージ通知サービスといったアプリケーションサービスを依頼する病院１２や診療所１３から提供される情報に基づいて登録される。

図２の上段に示すように、予約情報ＤＢ３１には、複数の予約管理レコード３３からなる予約情報が患者単位で格納される。予約管理レコード３３は、予約管理サーバ２６が受信した１件の予約申し込み情報につき１件生成される。図２の下段に示すように、予約管理レコード３３には、例えば、予約ＩＤ、受付日、患者ＩＤ、患者名、依頼先の病院ＩＤ、検査種別、予約日、依頼元ＩＤ（図示せず）及び依頼元から依頼先への申し送り事項などの項目が記録されるフィールド（図示せず）が含まれる。

受付日は、依頼元の診療所１３で予約申し込みが行われた日であり、予約日は、病院１２において患者１４が診療を受診する受診日である。患者ＩＤは、各患者ＩＤがデータセンタ１１内でそれぞれ固有のＩＤとなるように、例えば、病院ＩＤ（「Ｈ１」や「Ｈ２」）と、依頼先の病院１２で発行された患者ＩＤ（「１２３４」など）を組み合わせたＩＤ（「Ｈ１−１２３４」など）が与えられる。

図３の上段に示すように、患者情報ＤＢ３２には、データセンタ１１に登録された患者情報が患者単位で格納される。患者情報は、患者名、性別、年齢、住所、連絡先の電話番号やメールアドレスといった患者基本情報と、患者特性情報とからなる。患者特性情報には、来院確度情報及び傷病情報が含まれる。来院確度情報は、患者が予約した病院１２に来院する確度を表す情報である。傷病情報は、患者の傷病に関する情報である。

患者特性情報は、メッセージ通知サーバ２８が患者１４に対してメッセージを通知する際に、患者毎に適切な通知方法を決定するために利用する情報であり、病状や過去の来院状況といった患者１４の特性を把握するための情報である。

患者特性情報は、メッセージ通知サービスの依頼を受けている場合に病院１２から提供される情報に基づいて登録される。メッセージ通知サービスは、データセンタ１１の予約サービスを利用した病院１２に限って提供されるものではなく、予約サービスを利用しない病院１２や診療所１３がメッセージ通知サービスだけを利用することも可能である。

データセンタ１１経由で予約がなされた患者に対しては、すでに予約情報ＤＢ３１に予約管理レコード３３が格納されているので、その情報の一部が患者特性情報の作成に利用され、両者は、予約ＩＤなどによって対応付けて記録される。

図３の下段に示す患者特性情報３４は、予約単位で作成される複数のレコードからなる。患者特性情報３４に含まれる各レコード３４ａは、データセンタ１１経由で予約がなされたレコードと、患者１４が病院１２に対して直接申し込みを行った予約に関するレコードも含まれる。例えば、データセンタ１１経由で予約がなされた場合であっても、患者１４が病院１２で１度診療を受けた後は、データセンタ１１を経由することなく、患者１４と病院１２との間で次回の診療の予約がなされる場合も多い。メッセージ通知サービスを利用する病院１２は、データセンタ１１を経由せずに患者１４との間で行った診療予約に関する情報についても、データセンタ１１に送信する。

本例においては、予約ＩＤが「071226-05」のレコード３４ａがデータセンタ１１経由で予約された予約管理レコード３３と対応しており、予約管理レコード３３に基づいて生成されるレコードである。予約ＩＤが「080110-10」のレコード３４ａは、データセンタ１１を経由せずに病院１２と患者１４との間で直接行われた予約に基づいて追加されたレコードである。このレコードに対応する予約管理レコード３３は、データセンタ１１内には存在しない。データセンタ１１は、クライアント端末１６などを通じて病院１２のコンピュータシステムから受信した診療予約情報に基づいて、レコード３４ａを生成し、患者特性情報３４に追加する。こうして、患者特性情報３４には、予約単位で生成されたレコードが蓄積される。

患者特性情報３４の各レコード３４ａには、予約ＩＤ、予約日、病院ＩＤ、来院確度情報、傷病情報のそれぞれの項目が記録されるフィールドが含まれる。これらの項目のうち、予約ＩＤ、予約日、病院ＩＤといった予約内容に関する情報は、データセンタ１１経由で予約がなされた場合には、予約管理レコード３３から読み出されて患者特性情報３４の所定のフィールドに記録される。データセンタ１１を経由しない予約の場合には、病院１２から取得した診療予約情報から所定の項目が読み出されて、患者特性情報３４に記録される。

来院確度情報には、来院実績、事後メッセージの通知回数が含まれる。来院実績は、今回の診療の予約日に患者１４が来院したか否かを表す情報である。図において、「○」は来院があったこと、「×」は来院が無かったことを表す。事後メッセージの通知回数は、予約日に来院がなかった患者に対して予約日後に通知した事後メッセージの通知回数である。後述するように、事後メッセージは、通知後の来院状況や予約状況に応じて、再通知がなされる。事後メッセージの通知回数は、１回通知する毎にカウントアップされて更新された値が記録される。来院実績は予約日とともに、事後メッセージを通知するか否かの判定に使用される。

メッセージ通知サーバ２８は、来院確度情報に基づいて、事後メッセージの通知方法を決定する。本例においては、事後メッセージの通知回数に応じて、通知内容を変えることにより、後述する警告レベルを段階的に上げる。

予約日に来院しない患者は、大きく分けて、来院する意思はあるが、単なる失念が理由で来院しない患者（来院の確度が高い患者）と、来院の確度が高い患者に比べて、約束を怠るモラルの低い患者、無精な患者というように来院する意思が薄弱で、来院しない理由が単なる失念でない患者（来院の確度が低い患者）の２種類ある。

来院の意思がある患者は、単なる失念が理由なので、来院が無かった事実を伝える内容の事後メッセージを通知すれば、来院する可能性が高い（来院の確度が高い）と考えられる。一方、来院の意思が薄弱な患者は、来院しない理由が失念以外であるため、来院の意思がある患者と同様の通知方法で事後メッセージを通知しても、来院する可能性が低い（来院の確度が低い）。メッセージ通知サーバ２８は、来院確度情報に基づいて、上記２種類の患者の通知方法を変化させることで、来院の確度が高い患者に加えて、来院の確度が低い患者に対しても実効性の高いメッセージを通知する。

傷病情報には、例えば、傷病名、傷病の重篤度、過去の診療の結果、今回予約した診療の緊急度といった情報が含まれる。来院の確度が低い患者の中には、傷病やその病状から考えれば来院する必要性が高いにも関わらず、自己の傷病に関する認識が不足しているため、来院を怠る患者もいる。傷病情報は、来院の確度が低い患者に対して、自己の傷病の危険性を具体的に認識させるために使用される。

過去の診療の結果は、例えば、過去に受診した検査の結果であり、「再検査が必要（要再検査）」、「経過観察が必要（要経過観察）」といった形式で記録される。傷病の重篤度は、病院１２の医師によって診断された傷病の重篤度であり、例えば、「高」、「中」、「低」といった形式で記録される。今回予約した診療の緊急度は、前回の診療結果を踏まえて、医師によって判断された緊急性の程度を表す情報であり、例えば、重篤度と同形式で記録される。なお、この傷病情報に、過去の予約日に予定されていたが未受診の診療に関する情報を含めてもよい。

来院確度情報と傷病情報は、病院１２のコンピュータシステムから送信されて、受信した情報に基づいて、患者特性情報３４が更新される。なお、この患者特性情報３４は、データセンタのコンピュータシステムだけでなく、病院１２のコンピュータシステムに配信して、クライアント端末１６などに表示して、病院１２のスタッフが確認できるようにしてもよい。

図４に示すように、メッセージ通知サーバ２８は、ワークステーションやパーソナルコンピュータなどのコンピュータをベースにメッセージ通知プログラム４９をインストールすることによって構成される。

メッセージ通知サーバ２８は、ＣＰＵ４１、メモリ４２、ＨＤＤ（Hard Disk Drive）４３、ＬＡＮポート４４及びコンソール４６を備えており、これらはデータバス４７を介して接続されている。コンソール４６は、ディスプレイと、キーボードやマウスなどの入力デバイスとからなり、メッセージ通知サーバ２８の管理や設定を行うために用いられる。

ＨＤＤ４３には、オペレーティングシステムなどの制御プログラム、サーバアプリケーション、メッセージ通知プログラム４９といった各種のプログラムが格納されている。

メモリ４２は、ＣＰＵ４１が処理を実行するためのワークメモリである。ＣＰＵ４１は、ＨＤＤ４３に格納されたプログラムをメモリ４２へロードして、プログラムに従った処理を実行することにより、メッセージ通知サーバ２８の各部を統括的に制御する。ＬＡＮポート４４は、ＬＡＮ３０との間で伝送制御を行うネットワークインタフェースである。

ＣＰＵ４１は、メッセージ通知プログラム４９を実行することにより、情報取得部４１ａ、通知方法決定部４１ｂ、通知部４１ｃとして機能する。メッセージ通知プログラム４９は、プログラム本体と、メッセージ用フォーマット５１（図５参照）とからなる。

図５に示すように、メッセージ用フォーマット５１は、メッセージの通知内容に含める通知項目を定めたフォーマットデータである。フォーマットデータには、予め登録された定型文などのテンプレートデータが含まれる。メッセージ用フォーマット５１には、警告レベルに応じて、例えば、３種類のテンプレートが用意されている。警告レベルは、患者１４にメッセージを通知したときに期待される心理的な効果の程度を意味し、レベルＡＬ１、レベルＡＬ２、レベルＡＬ３と数字が大きくなるにつれて警告レベルは上がる。

レベルＡＬ１の通知項目には、例えば、「予約日に来院が無かったこと」、「来院して受診すべきこと」が含まれる。これらのデータは、患者間で共通なので、テンプレートデータに予め登録されている。単なる失念が理由で来院を怠った、来院の確度が高い患者は、このような内容のメッセージを通知すれば、来院すると予想される。

レベルＡＬ２の通知項目には、レベルＡＬ１の内容に、「傷病情報」、「予約の空き状況（予約サイトのアドレスを含む）」が追加される。「傷病情報」は、メッセージの宛先の患者の患者特性情報３４から読み出されてフォーマットに追加される。予約の空き状況は、病院１２の予約受付枠の空き状況である。予約サイトのアドレスは、例えば、データセンタ１１の予約サイトのアドレスである。これらの情報は、例えば、予約管理サーバ２６内のスケジュールデータから取得されて、テンプレートに追加される。もちろん、予約サイトのアドレスは、病院１２の予約サイトのアドレスでもよい。また、空き状況については、予約管理サーバ２６に該当する病院１２のスケジュールデータが無い場合には、空欄としてもよい。

レベルＡＬ２には、予約日に来院しなかった事実や来院を促す定型文に加えて、患者１４の傷病情報が含まれるため、患者１４に対して、傷病の危険性を具体的に認識させることができ、来院への強い動機付けを与えることができる。また、予約の空き状況や予約サイトのアドレスは、予約を取る手間の軽減につながるため、無精な性向の患者１４を次回の予約へと向かわせる強い誘因となり得る。このため、失念以外の理由で来院を怠った、来院の確度が低い患者に対して、高い効果が期待される。

レベルＡＬ３には、レベルＡＬ２の項目に、担当医師の警告文が追加される。担当医師の警告文は、患者１４が病院１２で前回受診した時に患者１４を担当した担当医師が患者１４に宛てたものである。担当医師の警告文は、患者１４の病状や傷病の危険性を認識させる最も効果的な内容と考えられるので、レベルＡＬ２の警告に比べて、患者１４に対して来院へのより強い動機付けが与えられる。警告文のデータは、例えば、担当医師がメールやワープロソフトで作成したテキストデータや、直筆のメッセージを電子化したイメージデータなどである。なお、本例では、担当医師の警告文としているが、医師に限らず、担当した看護師など他の医療スタッフの警告文でもよい。

事後メッセージには、所定の通知期間が定められ、事後メッセージは、定められた通知期間内に、所定回数通知される。本例の通知期間は約２週間であり、その期間内に通知される回数は３回である。１回目の通知時期は、予約日の翌日であり、１回目の通知後、１週間が経過した後、２回目が通知され、さらに、１週間が経過した後、３回目が通知される。通知期間、通知回数、通知時期の情報は、メッセージ通知プログラム４９の設定データに記録されている。

メッセージ用フォーマット５１は、コンソール４６やＬＡＮ３０を介して接続された管理端末から、通知項目、書式、通知期間、通知回数、通知時期などの設定内容を変更することが可能である。なお、本例では、３種類のテンプレートの例で説明しているが、少なくとも２種類あればよく、４種類以上でもよい。

図６に示すように、情報取得部４１ａは、例えば、病院１２のクライアント端末１６からのアクセスを受け付けて、来院確度情報、傷病情報の他、医療スタッフの警告文のデータを取得する。情報取得部４１ａは、センタＤＢサーバ２７にアクセスして、取得した情報によって患者特性情報３４を更新する。警告文のデータは、例えば、患者特性情報３４の該当するレコードに対応付けて患者情報ＤＢ３２内に格納される。

情報取得部４１ａは、クライアント端末１６が発行するリクエストに応答して情報を取得する。あるいは、病院１２のコンピュータシステムにアクセスして、病院１２に向けてリクエストを発行して情報を取得してもよい。また、センタＤＢサーバ２７などメッセージ通知サーバ２８以外のコンピュータシステムを経由して、病院１２のコンピュータシステムからの情報を取得してもよい。

図７に示すように、通知方法決定部４１ｂは、患者特性情報３４から、予約日、来院確度情報、傷病情報を読み出して、読み出した情報に基づいて、通知時期の監視処理、警告レベル判定処理、メッセージ作成処理といった処理を行って、通知部４１ｃに対して通知指令を送る。通知時期の監視処理では、予約日と現在日付とを照合することによって予約日が経過したか否かを調べる処理、予約日が経過した場合には、来院実績に基づいて、患者１４が予約日に来院したか否かを調べる処理、未来院の場合には、予め設定された通知時期を読み出して、現在日付と照合して通知時期が到来したか否かを調べる処理といった処理がなされる。

警告レベル判定処理では、来院確度情報から読み出された事後メッセージ通知回数に応じて警告レベルを判定する。予約日が経過した後、１回目の事後メッセージは、それ以前の通知回数が０回なので、レベルＡＬ１と判定する。２回目の事後メッセージの場合には、レベルＡＬ１の事後メッセージが１回通知されているので、事後メッセージ通知回数が１回となり、警告レベルを１段階上げてレベルＡＬ２と判定する。３回目の事後メッセージは、過去の事後メッセージの通知回数が２回となり、警告レベルをさらに１段階上げてレベルＡＬ３と判定する。

このように、通知回数に応じてレベルＡＬ１、レベルＡＬ２、レベルＡＬ３と段階的に警告レベルを上げることで、来院の確度が高い患者ばかりでなく、来院の確度が低い患者に対しても、来院への動機付けを与えることができるので、高い効果が期待できる。

警告レベル判定処理の判定条件は、メッセージ通知プログラム４９の判定条件データとして設定される。この判定条件データは、メッセージ用フォーマット５１と同様に、コンソール４６や管理端末から設定が可能であり、条件の追加、変更、削除等が行われる。

メッセージデータ作成処理では、警告レベル判定処理で判定された警告レベルに応じたメッセージデータを作成する。メッセージデータ作成処理では、警告レベルに応じて、メッセージ用フォーマット５１からレベルＡＬ１〜ＡＬ３のいずれかのフォーマットを読み出して、それぞれのフォーマットに応じたメッセージデータを作成する。作成したメッセージデータは、通知部４１ｃに送られる。

通知部４１ｃは、通知方法決定部４１ｂからの通知指令を受けると、患者情報ＤＢ３２から患者のメールアドレスを読み出して、通知指令とともに受け取った事後メッセージを、読み出したメールアドレス宛に送信する処理を行う。通知部４１ｃは、事後メッセージを送信した後、患者特性情報３４の事後メッセージの通知回数を更新する。

以下、上記構成の作用について、図８のフローチャートを参照しながら説明する。メッセージ通知サーバ２８は、メッセージ通知サービスの対象の患者１４に関する患者特性情報３４を、病院１２や診療所１３から取得した情報に基づいて生成し、患者情報ＤＢ３２に格納する。ステップ（Ｓ）１０１において、メッセージ通知サーバ２８は、患者特性情報３４の来院実績を調べて、患者１４が予約日に来院したか否かを判定する。予約日に来院が無い場合には、Ｓ１０２において、１回目の通知時期が到来したか否かを監視し、通知時期が到来した場合には、Ｓ１０３に進む。

メッセージ通知サーバ２８は、Ｓ１０３において、来院実績や予約レコードの追加の有無を調べて、来院又は改めて予約があったかを判定する。判定結果が肯定（Ｙ）の場合には処理を終了する。判定結果が否定（Ｎ）の場合には、１回目の通知時期（過去の事後メッセージの通知回数が０回）であるので、警告レベル判定において警告レベルをレベルＡＬ１と判定し（Ｓ１０４）、レベルＡＬ１の事後メッセージを通知する（Ｓ１０５）。

レベルＡＬ１の事後メッセージには、来院が無かった事実や来院すべきことの定型的な内容しか含まれていないが、来院の確度が高い患者に対しては、こうした内容で充分な効果が期待できる。

メッセージ通知サーバ２８は、１回目の通知後、２回目の通知時期を監視する（Ｓ１０６）。所定期間が経過して２回目の通知時期が到来した場合には、患者特性情報３４を調べて、Ｓ１０３と同様に、来院又は改めて予約があったかを判定する（Ｓ１０７）。Ｓ１０７において、来院又は予約が無い場合には、Ｓ１０４と同様に警告レベル判定を行って、２回目であるため（過去の事後メッセージの通知回数が１回）、警告レベルをレベルＡＬ２と判定し（Ｓ１０８）、レベルＡＬ２で、２回目の事後メッセージを通知する（Ｓ１０９）。

レベルＡＬ２の通知内容には、レベルＡＬ１の内容に、予約の空き状況や予約サイトのアドレスが追加されているため、無精な性向を持つ患者に対する効果を期待できる。また、患者１４の傷病情報も含まれているため、レベルＡＬ２の事後メッセージの通知を受けた患者１４は、自己の傷病や病状を具体的に認識できるので、来院への強い動機付けとなる。このように、レベルＡＬ２の事後メッセージを通知することで、来院の確度が低い患者に対して、来院への強い動機付けを与えることができる。

メッセージ通知サーバ２８は、２回目の通知後、３回目の通知時期を監視する（Ｓ１１０）。所定期間が経過して３回目の通知時期が到来した場合には、患者特性情報３４を調べて、Ｓ１０３、Ｓ１０７と同様に、来院又は改めて予約があったか否かを判定する（Ｓ１１１）。Ｓ１１１において、来院又は予約が無い場合には、Ｓ１０４、Ｓ１０８と同様に警告レベル判定を行って、３回目であるため（過去の事後メッセージの通知回数が２回）、警告レベルをレベルＡＬ３と判定し（Ｓ１１２）、レベルＡＬ３で、３回目の事後メッセージを通知する（Ｓ１１３）。

レベルＡＬ３の通知内容には、レベルＡＬ２の内容に、担当医師の警告文が追加されているため、来院しない理由が単なる失念ではない来院の確度の低い患者に対して、レベルＡＬ２にも増して、来院への強い動機付けを与えることができる。これにより、医療倫理的な理由から、電話等によって患者に対して行っていた来院を促すための直接的な対応が軽減されるので、病院１２の業務効率の改善にも寄与する。

上記実施形態では、警告レベルを３段階に分けてそれぞれのレベルを１回目、２回目、３回目のそれぞれの通知回数に割り当てて、通知回数が１回増えるごとに、警告レベルを１段階ずつ上げているが、２回目まではレベルＡＬ１を適用し、３回目から警告レベルを１段階上げるというように、通知回数が２回以上増えるごとに警告レベルを上げてもよい。また、警告レベルを上げるための判定基準となる通知回数は、レベルＡＬ１からレベルＡＬ２に上げる場合は１回、レベルＡＬ２からレベルＡＬ３に上げる場合は３回というように、レベル毎に異なってもよい。

また、本例では、１回の予約に際して通知した事後メッセージの通知回数を基準に警告レベルを判定しているが、前回以前の予約に際して通知した事後メッセージの通知回数の合計を基準に警告レベルを判定してもよい。例えば、前回以前の過去のすべての予約に際して通知した事後メッセージの通知回数の合計が規定回数以上の場合には、警告レベルを上げる。

また、前回以前の過去のすべての予約を事後メッセージの通知回数のカウント対象とするのではなく、前回以前の過去の所定回（例えば３回）分の予約で通知された事後メッセージの通知回数の合計が規定回数以上の場合に警告レベルを上げてもよい。過去に通知回数が多い患者であっても、事後メッセージを繰り返し受け取ることによって傷病の危険性を自覚して予約を守るようになり、通知回数が減少する場合もありうる。また、健忘や無精といった患者の性向が経時的に変化して、通知回数が減少することもありうる。通知回数のカウント対象の範囲を所定回数に限定することで、患者の性向の経時変化を通知方法に反映させることができる。なお、前回以前の事後メッセージの通知回数に加えて、上記実施形態でカウント対象とした今回の予約の通知回数も含めて通知回数の合計を求めてもよい。

上記実施形態では、事後メッセージの通知回数に応じて通知内容を決定する例で説明したが、図９のフローチャートに示すように、過去の未来院回数に応じて通知方法を決定してもよい。未来院回数は、患者特性情報３４の来院実績に記録された、過去の診療予約日に来院しなかった数をカウントすることによって求められる。通知方法決定部４１ｂは、今回の予約日に来院しない患者１４に対して、Ｓ２０１において、未来院回数が「０」の場合には、事後メッセージの警告レベルをＡＬ１と判定する（Ｓ２０３）。また、未来院回数が「１」の場合には、警告レベルをＡＬ２と判定し（Ｓ２０４）、「１」以上の場合には、警告レベルをＡＬ３と判定する（Ｓ２０５）。通知部４１ｃは、判定された警告レベルの事後メッセージを通知する（Ｓ２０６）。未来院回数が多い患者は、来院の確度が低いと考えられるので、未来院回数が多い患者に対して警告レベルが高い事後メッセージを通知することも効果的である。

この場合、未来院回数に応じて決定された警告レベルで、所定期間内に何回か通知を行ってもよいし、レベルＡＬ１やレベルＡＬ２のように、最上位より低いレベルにおいては、第１実施形態で示したように、事後メッセージの通知回数に応じて、レベルを上げていってもよい。

また、未来院回数のカウント対象は、事後メッセージの通知回数について述べたとおり、前回以前の過去のすべての予約の合計でもよいし、直近の所定回数分の予約の合計でもよい。また、未来院回数と事後メッセージの通知回数を組み合わせて通知方法を決定してもよい。

上記実施形態では、事後メッセージの通知回数や未来院回数の来院確度情報を元に通知内容を決定する例で説明したが、来院確度情報に加えて、傷病情報を考慮して通知方法を決定してもよい。この場合、通知方法決定部４１ｂは、患者特性情報３４から傷病情報を読み出し、傷病情報に含まれる、傷病名、過去の診療結果、重篤度、緊急度の少なくとも１つの項目に基づいて来院の必要性が高いか否かを判定する。例えば、傷病名が、癌といった特定の傷病である場合には、来院の必要性が高いと判定する。また、前回までの過去の検査結果が「要再検査」、「要経過観察」である場合には、来院の必要性が高いと判定する。重篤度や緊急度が「中」以上の場合には、来院の必要性が高いと判定する。また、これらの項目とは別の項目で判定してもよい。また、これらの項目の判定結果を数値化して、その合計が基準以上である場合に来院の必要性が高いと判定してもよい。なお、これらの判定条件は、適宜設定変更できるようにするとよい。

図１０のフローチャートは、来院確度情報の事後メッセージの通知回数と傷病情報を組み合わせて通知内容を決定する例である。通知方法決定部４１ｂは、図８のＳ１０１〜Ｓ１０３と同様に、Ｓ３０１〜Ｓ３０３の処理ステップを実行し、来院又は予約が無い場合には、レベルＡＬ１で１回目の事後メッセージを通知する（Ｓ３０４）。次に、２回目の通知時期が到来し（Ｓ３０５）、かつ、来院又は予約が無い場合には（Ｓ３０６）、傷病情報に基づいて、上述の手順で来院の必要性を判定する（Ｓ３０７）。基準に照らして、来院の必要性が低いと判定した場合には、レベルＡＬ２と判定し、レベルＡＬ２で二回目の事後メッセージを通知する（Ｓ３０８）、来院の必要性が高いと判定した場合には、レベルＡＬ３と判定し、レベルＡＬ３で二回目の事後メッセージを通知する（Ｓ３０９）。なお、来院確度情報の未来院回数と傷病情報を組み合わせてもよい。

また、傷病情報に基づく来院の必要性は、現在診療中の傷病に加えて、患者特性情報３４に記録されている過去の病歴を含めて判定してもよい。過去の病歴を調べることで、病歴が長かったり、複数の傷病を患っていることを把握できれば、患者の傷病の危険性をより正確に判定結果に反映させることができる。

なお、本例で示すとおり警告の通知回数は１回でもよいし、もちろん、３回以上行ってもよい。また、必要性の程度に応じて、通知回数を変えてもよい。必要性の程度が高い場合には、通知時期を早めたり、通知間隔を短くするというように、必要性の程度に応じて、通知時期や通知間隔を変えてもよい。

また、上記実施形態では、来院確度情報や傷病情報に基づいて通知内容を決定する例で説明したが、通知内容の代わりに、又は通知内容に加えて、一定期間内の通知回数を決定してもよい。例えば、過去の通知回数や未来院回数が少ない患者、また、来院の必要性が低い患者に対しては、一定期間内の通知回数を少なく、反対に、過去の通知回数や未来院回数が多い患者、また、来院の必要性が高い患者に対しては、一定期間内の通知回数が多くなるようにする。一定期間内の通知回数を増やせば、通知間隔が狭まるため、患者に対する心理的な効果を強めることができる。一定期間は、例えば、数週間でも数ヶ月でもよい。

上記実施形態では、予約日に来院しなかった場合の事後メッセージを通知する例で説明したが、事後メッセージに加えて、メッセージ通知サーバが予約日前に予約日を通知して来院を促す事前メッセージを通知してもよい。事前メッセージを通知する場合には、例えば、過去の未来院回数や事後メッセージの通知回数に応じて、次回の事前メッセージの通知回数を変化させるようにしてもよい。すなわち、過去の予約で蓄積された来院確度情報をフィードバックして次回の予約の事前メッセージの通知方法を決定する。

この場合には、例えば、図１１（Ａ）に示すように、メッセージ通知プログラム４９が参照する事前メッセージテーブル５２を設ける。事前メッセージテーブル５２は、通知回数及び通知時期が異なる３つの事前メッセージの通知方法（警告レベルＢＬ１〜ＢＬ３）を記録するテーブルデータである。

図１１（Ｂ）は、各レベルＢＬ１〜ＢＬ３の通知回数及び時期を黒丸で表したチャートである。レベルＢＬ１の通知回数及び時期は、予約日の１週間前に１回であり、レベルＢＬ２の通知回数及び時期は、予約日の１週間前と、予約日の前日の２回である。レベルＢＬ３の通知回数及び時期は、レベルＢＬ２に加えて、予約日の２週間前、予約日の３日前、予約日当日の朝の計５回である。レベルＢＬ１の通知回数が最も少なく、レベルＢＬ３の通知回数が最も多い。各レベルＢＬ１〜ＢＬ３の通知内容は同じである。

図１２のフローチャートに示すように、通知方法決定部４１ｂは、患者特性情報３４から来院実績を読み出して、過去の未来院回数を調べる（Ｓ４０１、Ｓ４０２）。未来院回数が０回の場合には、次回の予約のときの事前メッセージのレベルをＢＬ１と判定し（Ｓ４０３）、未来院回数が１回の場合には、レベルをＢＬ２と判定し（Ｓ４０４）、２回以上の場合には、レベルＢＬ３と判定する（Ｓ４０５）。通知部４１ｃは、判定したレベルの事前メッセージを通知する（Ｓ４０６）。未来院回数が多い患者ほど、次回の予約を怠る可能性が高く来院する確度が低いと予想される。過去の未来院回数に応じて事前メッセージの通知回数を増やすことで、来院の確度が低い患者に対するメッセージの実効性を上げることができる。事前メッセージのレベル判定は、例えば、次回の予約に関するレコードが患者特性情報３４に記録されたときに実行される。

なお、本例の事前メッセージの通知方法の決定の仕方は、１例であり、レベルの数、それぞれの通知時期、通知回数、通知内容は、適宜変更が可能である。また、事前メッセージの通知内容をレベルに応じて変えてもよい。また、過去の未来院回数の代わりに、過去の事後メッセージの通知回数に基づいて、事前メッセージの通知方法を決定してもよいし、両者を組み合わせて、事前メッセージの通知方法を決定してもよい。

また、事前メッセージの通知方法の決定の仕方は、患者特性情報３４に記録されている過去の未来院回数の合計を基準に、次回の予約の事前メッセージの通知方法を決定しているが、事後メッセージの通知方法と同様に、過去の予約のすべてをカウント対象とするのではなく、前回以前の所定回数分の予約をカウント対象として、その回数を基準に決定してもよい。

また、上記実施形態では、患者が次回の予約を取りやすいように、メッセージの通知内容に予約の空き状況や予約サイトのアドレスを含めて患者に通知しているが、前回予約した病院とは異なる病院の空き状況や予約サイトのアドレスを通知してもよい。データセンタでは、予約管理サーバが複数の病院のスケジュールデータを保有しているので、メッセージ通知サーバは、予約管理サーバにアクセスして他の病院のスケジュールデータを読み出して、他の病院の空き状況を通知することができる。こうすれば、例えば、通院の利便性や時期的な都合といった患者の事情に合わせて、別の病院を選択するといったこともしやすい。

上記実施形態では、データセンタのコンピュータシステムに、本発明の来院支援装置を適用した例で説明したが、病院や診療所のコンピュータシステムに適用して、病院から患者宛に直接通知を行うようにしてもよい。

上記実施形態では、来院確度情報や傷病情報を、病院のコンピュータシステムからデータセンタへアップロードして、センタＤＢサーバに患者特性情報として格納した後、メッセージ通知サーバがセンタＤＢサーバにアクセスして患者特性情報を取得して、メッセージの通知に関する種々の処理を行っているが、例えば、データセンタのコンピュータシステムから病院のコンピュータシステムへ、リアルタイムでＷＡＮ経由のオンラインアクセスが可能であれば、データセンタのコンピュータシステムが、メッセージの通知に関する処理を行う際に、病院のコンピュータシステムにオンラインアクセスして、必要に応じてリアルタイムで取得するようにしてもよい。すなわち、患者特性情報を格納する格納手段は、病院のコンピュータシステムにあってもよい。

また、上記実施形態では、センタＤＢサーバに患者特性情報を格納しているが、メッセージ通知サーバに患者特性情報を格納してもよい。

また、上記実施形態では、本発明の医用ネットワークシステムを、データセンタのコンピュータシステムと、医療施設のコンピュータシステムとからなる形態で説明したが、他の形態にも適用可能である。例えば、１つの病院に複数の拠点があり、それぞれの拠点が、メッセージ通知サービスの依頼元やデータセンタとしての役割を担い、各拠点の複数のコンピュータシステムをネットワークで接続した医用ネットワークシステムとしてもよい。また、複数の病院のそれぞれのコンピュータシステムをネットワークで接続した医用ネットワークシステムでもよい。この場合、いずれかの病院がデータセンタとなりホスト的な役割を担う。上記いずれの場合でも、各コンピュータシステム間を接続するネットワークはＷＡＮでもＬＡＮでもよい。

なお、上記実施形態で示したとおり、本発明は、プログラムの形態、さらにはプログラムを記憶する記憶媒体にも及ぶことはもちろんである。

医用ネットワークシステムの概略を示す構成図である。予約管理レコードの説明図である。患者特性情報に関する説明図である。メッセージ通知サーバの概略構成図である。メッセージ用フォーマットの説明図である。情報取得部の処理の説明図である。通知方法決定部の処理の説明図である。メッセージの通知手順を示すフローチャートである。第２の実施形態のメッセージの通知手順を示すフローチャートである。第３の実施形態のメッセージの通知手順を示すフローチャートである。事前メッセージテーブルの説明図である。事前メッセージの通知手順を示すフローチャートである。

符号の説明

１０医用ネットワークシステム
１１データセンタ
１２病院
１３診療所
１４患者
１６クライアント端末（病院）
１７クライアント端末（診療所）
１８ＷＡＮ
２１病院ＤＢサーバ
２６予約管理サーバ
２７センタＤＢサーバ
２８メッセージ通知サーバ
４１ＣＰＵ
４１ａ情報取得部
４１ｂ通知方法決定部
４１ｃ通知部
５１メッセージ用フォーマット
５２事前メッセージテーブル

Claims

診療を予約した患者宛てに来院を促すメッセージを通知する通知手段と、
前記患者が来院する確度を表す来院確度情報に基づいて、前記メッセージの通知内容及び一定期間内における通知回数のうち少なくとも１つを含む通知方法を決定する通知方法決定手段とを備えたことを特徴とする来院支援装置。
前記通知方法決定手段は、来院する確度が高い患者に比べて、来院する確度が低い患者に対する、前記通知内容のレベル及び前記通知回数のうち少なくとも１つを増やすことを特徴とする請求項１記載の来院支援装置。
前記通知方法決定手段は、前記来院確度情報に加えて、前記患者の傷病情報に基づいて、前記通知方法を決定することを特徴とする請求項１又は２記載の来院支援装置。
前記傷病情報は、傷病名、過去の診療の結果、傷病の重篤度、今回予約した診療の緊急度のうち少なくとも１つを含むことを特徴とする請求項３記載の来院支援装置。
前記来院確度情報は、前記メッセージのうち、過去の診療予約日後に通知した事後メッセージの通知回数を含むことを特徴とする請求項１〜４いずれか記載の来院支援装置。
前記来院確度情報は、過去の診療予約日に来院しなかった未来院回数を含むことを特徴とする請求項１〜５いずれか記載の来院支援装置。
前記通知内容には、今回の診療予約日と病院に関する基本情報が少なくとも含まれ、
予約の空き状況に関する予約空き情報、ネットワークを通じて予約を受け付ける予約サイトのアドレス、及び前記患者の担当医療スタッフの警告文のうち少なくともいずれか１つは、前記来院確度情報に応じて前記通知内容に追加されることを特徴とする請求項１〜６いずれか記載の来院支援装置。
前記来院確度情報は、前記メッセージのうち、過去の診療予約日後に通知した事後メッセージの通知回数を含み、
前記通知方法決定手段は、前記事後メッセージの通知回数が第一の規定回数以上となったときに、前記予約空き情報または前記予約サイトのアドレスを前記通知内容に追加し、
前記事後メッセージの通知回数が前記第一の規定回数よりも多い第二の規定回数となったときに、前記警告文を前記通知内容に追加することを特徴とする請求項７記載の来院支援装置。
前記来院確度情報は、過去の診療予約日に来院しなかった未来院回数を含み、
前記通知方法決定手段は、前記未来院回数が第三の規定回数以上となったときに、前記予約空き情報または前記予約サイトのアドレスを前記通知内容に追加し、
前記未来院回数が前記第三の規定回数よりも多い第四の規定回数以上となったときに、前記警告文を前記通知内容に追加することを特徴とする請求項７又は８記載の来院支援装置。
診療を予約した患者宛てに来院を促すメッセージを通知する来院支援方法において、
前記患者が来院する確度を表す来院確度情報に基づいて、前記メッセージの通知内容及び一定期間内における通知回数のうち少なくとも１つを含む通知方法を、通知方法決定手段で決定する通知方法決定ステップと、
決定した通知方法で前記メッセージを通知する通知ステップとを備えたことを特徴とする来院支援方法。
複数の医療施設に設けられた複数の第１コンピュータシステムと、前記第１コンピュータシステムとネットワークを介して通信可能に接続されたデータセンタの第２コンピュータシステムとからなる医用ネットワークシステムにおいて、
前記第２コンピュータシステムは、前記医療施設の診療を予約した患者の予約日を含む予約情報を管理する情報管理装置と、
前記第１コンピュータシステムから取得した、前記患者が来院する確度を表す来院確度情報を格納する情報格納装置と、
前記予約情報を元に、診療を予約した患者宛てに来院を促すメッセージを通知する来院支援装置とを備えており、
前記来院支援装置は、前記情報格納装置から前記来院確度情報を読み出し、前記来院確度情報に基づいて、通知内容及び一定期間内における通知回数のうち少なくとも１つを含む通知方法を決定する通知方法決定手段を有することを特徴とする医用ネットワークシステム。