JP7116192B2 - 診療支援装置及び診療支援システム - Google Patents

Description

本発明は、診療支援装置及び診療支援システムに関する。

医療分野では、医師や検査技師等の医療スタッフが円滑に診察及び検査等を進めるために、診療等の過程及び結果を、医療スタッフ間又は診療科間等で共有する統合的な診療支援装置が使用されている。診療支援装置は、例えば、診療プロセスを複数の患者について一覧にしたリストを表示する等して、医療スタッフに提供することによって診療を支援する（特許文献１）。

医療スタッフは、診療支援装置によって表示される診療プロセスのリストに基づいて、診療を受ける患者の順番、各患者の情報及び診療内容等を把握して、診療を効率良く進めるように準備を行う。このような診療の準備の際、同じ時間帯に検査が集中しないようにすること、重症度等に応じた患者の優先度等を考慮しなければならない。

一方、診療支援装置には、患者毎の位置情報に基づいて各患者の待ち時間等の混雑状況を算出し、医療施設等のマップ上に混雑状況に関する情報を表示する装置がある（特許文献３）。

特開２０１６－１４３２０５号公報 特開２０１７－１０２７５９号公報 特許第５８８９６８６号公報

しかしながら、上記特許文献１記載の診療支援装置では、診療プロセスのリストを閲覧している医療スタッフが、それぞれの診療における混雑状況を把握することができない。このため、混雑状況を知らずに、診療プロセスのリストに基づいて、検査の予約を入れて同じ時間帯に同じ検査等が集中してしまうことがある。また、同じ検査への集中により待ち時間が多くなって実際の検査時間が把握できずに検査の後段の診療まで遅延する等の問題がある。

また、上記特許文献２及び３記載の混雑状況を表示する機能を有していても診療プロセスのリストを表示する表示画面から、マップ等の表示画面に切り替えなければ混雑状況を把握できない。このため、診療プロセスのリストにおける所定の診療の混雑状況を知りたい場合、表示画面を切り替えて、さらにその診療を受けるマップ上の場所を探さなければならず、非常に手間が掛かる。

そこで、本発明は、医療施設の各診療における患者の混雑状況を容易に把握し、適切なスケジュールで診療を進行することが可能な診療支援装置及び診療支援システムを提供することを目的とする。

本発明の診療支援装置は、表示画面生成部と、患者位置情報取得部と、混雑状況算出部とを備え、混雑状況算出部により算出された混雑状況を表示画面上に表示する。表示画面生成部は、複数名の患者について、患者ごとに、患者の識別情報と診療プロセスとを対応付けて表示する表示画面を生成する。患者位置情報取得部は、医療施設内における患者の位置情報を取得する。混雑状況算出部は、診療プロセスにおける診療を患者が受ける際の混雑状況を、患者位置情報取得部により取得した患者位置情報を用いて算出する。

混雑状況算出部は、診療を受ける前に患者が進入する待機区域を予め設定しており、患者位置情報から待機区域に患者が進入している場合、混雑状況として待機区域に進入している全ての患者の人数である待機人数を算出することが好ましい。

混雑状況算出部は、待機人数を算出し、かつ表示画面生成部から診療プロセスにおける検査予定時刻の情報を取得し、待機区域に進入している患者を検査予定時刻が早い順に並べた順番を混雑状況として算出することが好ましい。

患者位置情報の履歴を用いて、診療プロセスを構成する検査ごとの検査所要時間及び検査待ち時間から構成される検査時間情報を蓄積する検査時間情報蓄積部を備えていることが好ましい。

検査時間情報蓄積部は、検査時間情報に、患者情報、検査内容情報、検査結果情報、検査実施者情報、検査機器情報、及び日時情報のうち少なくとも1つと対応付けて蓄積することが好ましい。

混雑状況算出部は、患者を予め複数の種類に分類し、検査時間情報を用いて統計処理することにより種類ごとの検査所要時間又は検査待ち時間を算出し、種類ごとの検査所要時間又は検査待ち時間を用いて全体検査所要時間又は全体検査待ち時間を混雑状況として算出することが好ましい。

患者が受けた検査結果に対して早急な対応が必要と判断された場合、表示画面上に報知情報を表示することが好ましい。

患者が受けた検査結果に対して早急な対応が必要と判断された場合、医療スタッフ又は患者が所持する端末に報知情報を送信することが好ましい。

表示画面生成部は、診療プロセスを構成する検査のうち、所定条件を満たす特定の検査を受ける患者のみを抽出し、特定の検査を受ける予定の順番、又は特定の検査を受ける予定時刻に従って並べ替えた検査別表示画面を生成することが好ましい。

表示画面上に、各患者の現在位置情報を表示することが好ましい。

表示画面生成部は、各検査部門からの編集要求があった場合、患者が診療を受ける予定時刻の修正、又は診療を受ける予定の順番の入れ替えを行うことが好ましい。

本発明の診療支援システムは、診療支援装置とクライアント端末とこれらを相互に通信可能に接続するネットワークとで構成される診療支援システムであって、表示画面生成部と、患者位置情報取得部と、混雑状況算出部とを備え、混雑状況算出部により算出された混雑状況を表示画面上に表示する。

本発明によれば、医療施設の各診療等における患者の混雑状況に応じて、適切なスケジュールで診療を進行することが可能な診療支援装置及び診療支援システムを提供することができる。

診療支援システムの構成を示す説明図である。 診療支援システムが有するクライアント端末を示す説明図である。 クライアント端末の構成を示すブロック図である。 クライアント端末の機能を示すブロック図である。 診療支援装置の構成を示すブロック図である。 診療支援装置の機能を示すブロック図である。 位置情報センサの配置を示す説明図である。 患者位置情報を用いて混雑状況を算出する処理を説明するための説明図であり、待合室における特定の患者の入室前（Ａ）、入室後（Ｂ）、現在の状態（Ｃ）をそれぞれ示す。 初期画面である。 クリニカルフロー画面である。 診療支援装置およびクライアント端末の各処理部の処理の流れを示すフローチャートである。 新規患者受付又は患者位置情報の変化があった際の診療支援装置の各処理部の処理の流れを示すフローチャートである。 第２実施形態において混雑状況を算出する際の処理を説明するための説明図である。 図１３に対応する患者について、表示画面生成部から取得した検査予定時刻の一例である。 第３実施形態の診療支援装置の機能を示すブロック図である。 患者位置情報の履歴を示す説明図である。 患者位置情報の履歴に対応する各場所の入室及び退室時刻を示す説明図である。 検査時間情報蓄積部が蓄積した検査時間情報の一例である。 第１変形例のクリニカルフロー画面の一例である。 第２変形例のクライアント端末に表示される表示画面の一例である。

［第１実施形態］

図１に示すように、診療支援システム１０は、病院等の医療施設において診療支援を行うコンピュータシステムであり、クライアント端末１１と、診療支援装置１２と、サーバ群１３と、位置情報センサ１４とを備える。これらの診療支援システム１０を構成する各要素は、医療施設内に施設されたＬＡＮ（Local Area Network）等のネットワーク１５を用いて相互に通信可能に接続している。なお、サーバ群１３を医療施設外に設置し、医療施設外と接続するネットワーク１５を用いて、クライアント端末１１、診療支援装置１２及び位置情報センサ１４と通信可能に接続されてもよい。

クライアント端末１１は、診療支援装置１２からサービスの提供（診療支援装置１２の機能の提供）を受けるための端末であり、医師、検査技師、又は看護師等の医療スタッフが直接的に操作するコンピュータ（タブレット端末等である場合を含む）等である。クライアント端末１１は、内科もしくは外科等の診療科、放射線検査科もしくは臨床検査科等の各種検査科、ナースセンター、又は、その他の必要箇所に設置する。また、クライアント端末１１は、医療スタッフごとに設けることができ、また、複数の医療スタッフの共用とすることができる。したがって、図２に示すように、診療支援システム１０は、複数のクライアント端末１１を含む。例えば、グループＧ１は医師Ａ１及び医師Ａ２が属する「内科」であり、医師Ａ１と医師Ａ２はそれぞれにクライアント端末１１を保有する。同様に、例えば、グループＧ２は医師Ｂ１が属する「外科」であり、グループＧ２には少なくとも１台のクライアント端末１１がある。また、例えば、グループＧ１９は技師Ｎ１が属する「放射線科」であり、グループＧ１９には少なくとも１台のクライアント端末１１がある。

診療支援装置１２は、例えばクライアント端末１１からの要求に応じて、クライアント端末１１に診療データ等を含む表示画面を提供する。診療データとは、診察、検査もしくは手術等において取得もしくは作成した画像、レポート、検査結果、その他診療の過程において、もしくは診療の結果として得られるデータ、又はこれらの所在を示す情報（いわゆるリンク（エイリアス）等）である。診療支援装置１２は、表示画面において使用する診療データをサーバ群１３から取得する。

診療支援装置１２がクライアント端末１１に提供する表示画面とは、クライアント端末１１が、クライアント端末１１の表示部３６（図３参照）の画面を形成するために使用するデータをいう。また、診療支援装置１２がクライアント端末１１に提供する表示画面には、クライアント端末１１が画面全体の表示を構成する全画面表示用のデータだけでなく、画面の一部に係る表示を構成するデータを含む。例えば、本実施形態においては、診療支援装置１２は、表示部３６の画面の一部において一般的なウィンドウ形式で表示可能な表示画面をクライアント端末１１に提供する。

診療支援装置１２がクライアント端末１１に提供する表示画面は、具体的には、初期画面７１（図９参照）、及び、クリニカルフロー画面８１（図１０参照）等である。クリニカルフロー画面８１は、複数名の患者について、患者ごとに、患者の識別情報と、診療プロセスの一部又は全部と、を対応付けて表示する表示画面である。患者の識別情報とは、例えば、患者の氏名、生年月日、年齢、もしくは性別等、又は、患者に付与した固有の番号及び／又は記号等のＩＤ（Identification Data）である（以下、患者ＩＤという）。診療プロセスとは、既に行った診療及び将来行う予定の診療の過程又は結果をいう。したがって、診療プロセスは、既に取得等した診療データのみならず、取得等する予定の診療データを含む場合がある。取得等する予定の診療データは、例えば、特定検査のオーダの有無、その予定日時、又は、取得予定の診療データの種別等に関する情報、等である。

診療支援装置１２は、クリニカルフロー画面８１上に、後述する患者の混雑状況を表示する。混雑状況は、位置情報センサ１４を用いて取得した患者Ｐの位置情報に基づき算出される。

診療支援装置１２は、例えば、ＸＭＬ（Extensible Markup Language）データ等のマークアップ言語を用いた記述形式で、表示画面をクライアント端末１１に提供する。クライアント端末１１は、ＸＭＬ形式の表示画面を、ウェブブラウザを用いて表示する。なお、診療支援装置１２は、ＸＭＬの代わりに、ＪＳＯＮ（JavaScript（登録商標） Object Notation）等の他の形式で表示画面をクライアント端末１１に提供できる。

サーバ群１３は、診療支援装置１２からの要求に応じた診療データを検索し、要求に該当する診療データを診療支援装置１２に提供する。サーバ群１３は、電子カルテサーバ２１、画像サーバ２２、レポートサーバ２３、等を含む。

電子カルテサーバ２１は、電子カルテを格納するカルテデータベース２１Ａを有する。電子カルテは、１又は複数の診療データの集合体である。具体的には、電子カルテは、例えば、診察記憶、検体検査の結果、患者のバイタルサイン、検査等のオーダ、治療記録、又は、会計データ等の診療データを含む。電子カルテは、クライアント端末１１を用いて入力及び閲覧できる。

なお、診察記録とは、問診もしくは触診の内容及び結果、又は病名等の記録である。検体とは患者から採取した血液又は組織等であり、検体検査とは、血液検査又は生化学検査等である。バイタルサインとは、患者の脈拍、血圧、又は体温等の患者の状態を示すデータである。検査等のオーダとは、検体検査等の検査、各種モダリティを用いた撮影、レポートの作成、処置もしくは手術、又は投薬等の依頼である。治療記録とは、処置、手術、投薬、又は、処方箋等の記録である。会計データとは、受診料、薬料、又は、入院費等に関するデータである。

画像サーバ２２は、いわゆるＰＡＣＳ（Picture Archiving and Communication System）サーバであり、検査画像が格納される画像データベース２２Ａを有する。検査画像とは、ＣＴ（Computed tomography）検査、ＭＲＩ（Magnetic Resonance Imaging）検査、Ｘ線検査、超音波検査、又は内視鏡検査等の各種画像検査で得られる画像である。これらの検査画像は、例えばＤＩＣＯＭ（Digital Imaging and Communications in Medicine）規格に準拠したフォーマットで記録する。検査画像は、クライアント端末１１を用いて閲覧できる。

レポートサーバ２３は、読影レポートを格納するレポートデータベース２３Ａを有する。読影レポート（以下、単にレポートという）とは、画像検査で得た検査画像の読影結果をまとめた報告書である。検査画像の読影は読影医が行う。レポートは、クライアント端末１１を用いて、作成及び／又は閲覧できる。

上記の電子カルテ、検査画像、及び、レポートには、それぞれ、患者ＩＤが付帯する。また、電子カルテには、患者ＩＤの他、診療データ毎に、診療データを入力等した医療スタッフを識別する情報が付帯する。検査画像には、患者ＩＤの他、検査を実施した医療スタッフ（具体的には検査技師）を識別する情報が付帯する。レポートには、作成した医療スタッフ（具体的には読影医）を識別する情報が付帯する。医療スタッフを識別する情報とは、医療スタッフの氏名等、又は、各医療スタッフに付与した固有の番号及び／又は記号等のＩＤである（以下、医療スタッフＩＤという）。

クライアント端末１１、診療支援装置１２、及び、サーバ群１３を構成する各サーバ２１～２３は、サーバコンピュータ、パーソナルコンピュータ、又はワークステーションといったコンピュータをベースに、オペレーティングシステムプログラムと、サーバプログラム又はクライアントプログラム等のアプリケーションプログラムをインストールして構成する。すなわち、クライアント端末１１、診療支援装置１２、及び、サーバ群１３を構成する各サーバ２１～２３の基本的な構成は同じであり、ＣＰＵ（Central Processing Unit）、メモリ、ストレージ、通信部等、及び、これらを接続する接続回路を備える。通信部は、ネットワーク１５と接続するための通信用のインターフェース（ＬＡＮボード等）である。接続回路は、例えば、システムバス及び／又はデータバス等を提供するマザーボードである。

図３に示すように、クライアント端末１１は、ＣＰＵ３１、メモリ３２、ストレージ３３、通信部３４、及び、接続回路３５の他に、表示部３６及び操作部３７を備える。表示部３６は、例えば液晶等を用いたディスプレイであり、少なくとも診療支援装置１２が提供する表示画面を表示する画面を有する。操作部３７は、例えば、マウス等のポインティングデバイス、及び／又は、キーボード等の入力デバイスである。表示部３６及び操作部３７は、いわゆるタッチパネルを構成することができる。

クライアント端末１１は、ストレージ３３に、オペレーティングシステムプログラム等の他、作動プログラム３９を記憶する。作動プログラム３９は、クライアント端末１１を用いて診療支援装置１２の機能の提供を受けるためのアプリケーションプログラムである。本実施形態においては、作動プログラム３９は、ウェブブラウザのプログラムである。但し、作動プログラム３９は、診療支援装置１２の機能の提供を受けるための専用のアプリケーションプログラムとすることができる。なお、作動プログラム３９には、診療支援装置１２が提供する表示画面の一部又は全部を制御するための１又は複数のガジェットエンジンを含む場合がある。ガジェットエンジンとは、ウェブブラウザ等に付随して動作することにより、各種機能を発揮するサブプログラムである。なお、作動プログラム３９は、外部の記録メディアに記録されて配布され、その記録媒体からクライアント端末１１にインストールされてもよい。または、ネットワークに接続されたサーバ等に、外部からアクセス可能な状態で記憶され、要求に応じてクライアント端末１１にダウンロードされ、インストールされてもよい。

クライアント端末１１において作動プログラム３９を起動すると、図４に示すように、クライアント端末１１のＣＰＵ３１は、メモリ３２と協働してＧＵＩ（ｇｒａｐｈｉｃａｌ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ）制御部４１及び要求発行部４２として機能する。

ＧＵＩ制御部４１は、診療支援装置１２が提供する表示画面を表示部３６においてウェブブラウザ上に表示する。ＧＵＩ制御部４１は、ポインティングデバイスによるボタンのクリック操作等、操作部３７を用いて入力する操作指示に応じて、クライアント端末１１を制御する。

要求発行部４２は、操作部３７の操作指示に応じて、診療支援装置１２に対する各種処理の要求（以下、処理要求という）を発行する。要求発行部４２が発行する処理要求は、例えば、表示画面の配信要求、又は表示画面の編集要求等である。要求発行部４２は、処理要求を、通信部３４及びネットワーク１５を介して診療支援装置１２に送信する。

表示画面の配信要求は、診療支援装置１２に、特定の構成を有する表示画面の配信を要求する。例えば、表示画面の配信要求によって、初期画面７１、及び、クリニカルフロー画面８１等のうちいずれかを指定して配信を受けることができる。

表示画面の編集要求は、診療支援装置１２から特定の構成を有する表示画面の配信を受けた後、診療支援装置１２にその表示画面に表示する診療データ等の内容について編集を要求する。例えば、クリニカルフロー画面８１の配信を受けた場合、表示する患者のリストの指定もしくは変更、診療プロセスの表示対象期間の指定もしくは変更、又は、表示対象とする診療プロセスの指定もしくは変更等の要求が表示画面の編集要求である。

なお、表示画面の配信要求及び／又は編集要求等は、医療スタッフＩＤ、及び、当該クライアント端末１１のネットワーク上のアドレス等の情報を含む。医療スタッフＩＤは、診療支援システム１０（あるいは診療支援装置１２）へのログイン画面（図示しない）において入力する。

図５に示すように、診療支援装置１２は、ＣＰＵ５１、メモリ５２、ストレージ５３、通信部５４、及び、接続回路５５を備える。診療支援装置１２は、必要に応じてクライアント端末１１と同様に表示部及び／又は操作部を備えることができ、また、必要に応じて表示部及び／又は操作部を取り付けることができるが、本実施形態においては、診療支援装置１２は表示部及び操作部を有しない。

診療支援装置１２は、ストレージ５３に、オペレーティングシステム等の他、作動プログラム５９を記憶する。作動プログラム５９は、診療支援装置１２を構成するコンピュータを、診療支援装置１２として機能させるためのアプリケーションプログラムである。作動プログラム５９が起動すると、図６に示すように、診療支援装置１２のＣＰＵ５１はメモリ５２と協働して、要求受付部６１、表示画面生成部６２、患者位置情報取得部６３、及び混雑状況算出部６４等として機能する。なお、作動プログラム５９は、外部の記録メディアに記録されて配布され、その記録媒体から診療支援装置１２にインストールされてもよい。または、ネットワークに接続されたサーバ等に、外部からアクセス可能な状態で記憶され、要求に応じて診療支援装置１２にダウンロードされ、インストールされてもよい。

要求受付部６１は、クライアント端末１１から表示画面の配信要求及び編集要求等の各種処理要求を受け付ける。要求受付部６１が各種処理要求を受け付けると、要求受付部６１は、対応する処理を実行する各部に、要求があった処理の内容に応じて、処理の指示を入力する。例えば、クライアント端末１１から表示画面の配信要求があった場合、要求受付部６１は、該当する表示画面の生成指示を表示画面生成部６２に入力する。同様に、クライアント端末１１から表示画面の編集要求があった場合、要求受付部６１は、該当する表示画面の編集指示を表示画面生成部６２に入力する。なお、診療支援装置１２へのログインの要求も要求受付部６１が受け付け、ログイン処理部（図示しない）が医療スタッフＩＤ及びパスワードの確認等のログイン処理を実行する。

表示画面生成部６２は、クリニカルフロー画面８１等の各種表示画面を生成又は編集する。本実施形態においては、表示画面生成部６２は、新たな表示画面の配信要求があった場合に、その表示画面を表すＸＭＬデータを生成し、かつ、表示画面の編集要求があった場合には、その要求内容に応じて先に作成したＸＭＬデータを編集する。表示画面生成部６２は、必要に応じてサーバ群１３にアクセスし、表示画面の生成又は編集に使用する診療プロセス等に関する情報を取得する。なお、表示画面生成部６２は、サーバ群１３へのアクセス頻度を低減するために、サーバ群１３から取得した診療プロセス等に関する情報の一部又は全部を保持しておくことができる。なお、ログイン処理部がログイン処理を正常に完了した場合、表示画面生成部６２は、ログイン後最初に表示する初期画面７１（図９参照）を生成する。また、初期画面７１の作成又は編集する際には、表示画面生成部６２は、初期画面７１の生成又は編集に必要な情報を、サーバ群１３、クライアント端末１１、又は、その他の診療支援システム１０と連携する装置もしくはシステムから取得する。

混雑状況算出部６４は、患者位置情報取得部６３により取得した患者位置情報を用いて、診療プロセスにおける診療を患者Ｐが受ける際の混雑状況を算出する。混雑状況算出部６４により算出される混雑状況の内容については、後述する。表示画面生成部６２は、生成又は編集する表示画面において、混雑状況算出部６４により算出された混雑状況を表示する。なお、以下では、特定の患者を他の患者と区別する場合には、符号Ｐの後に数字（１、２、３・・・）を付して他の患者Ｐと区別する。

患者位置情報取得部６３は、医療施設内における位置情報センサ１４と患者Ｐが所持する端末の交信情報から患者Ｐが現在いる位置情報（以下、患者位置情報と称する。）を取得する。この患者位置情報を取得する技術としては、例えば特開２０１８－０５０７３９号公報に記載されている位置情報システムと同様である。位置情報センサ１４は、医療施設内の複数の区域にそれぞれ設置されている。本実施形態では、患者Ｐが所持する端末としてスマートフォン等の携帯端末１６を使用する。携帯端末１６は、例えば、クライアント端末１１と同様の構成を有し、かつ携帯性を有することが好ましい。

そして、携帯端末１６は、位置情報センサ１４と、例えばＷｉ－Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ、登録商標）等の電波により通信する。携帯端末１６は、病院から貸与される端末、あるいは患者の個人所有の端末でもよく、例えば所定のアプリケーションソフトをインストールすることにより、位置情報センサ１４と通信可能となる。また、携帯端末１６は、上記の端末に限らず、病院の受付や待合室などで貸与されるＲＦＩＤ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ ｉｄｅｎｔｉｆｉｅｒ）タグや、位置取得専用の端末（腕時計型やリストバンド型の端末等）でもよい。

位置情報センサ１４は、例えば図７に示すように、患者Ｐが診療を受ける際に入室する受付、待合室、更衣室、診察室、検査室等、医療施設１７内に予め指定された複数の区域の天井や壁に、好ましくは、ほぼ均等な距離をおいて配置されている。診療支援システム１０の稼働中、位置情報センサ１４が定期的に電波を発信し、その電波を患者Ｐの携帯端末１６が受信した場合、位置情報センサ１４及び携帯端末１６間の交信情報が、ネットワーク１５を構成する無線ＬＡＮ等を介して診療支援装置１２の患者位置情報取得部６３に送られる。

患者位置情報取得部６３は、医療施設１７内に配置された位置情報センサ１４のマップが予め記憶されており、位置情報センサ１４及び携帯端末１６間の交信情報から患者位置情報を取得する。患者位置情報取得部６３により取得された患者位置情報が、混雑状況算出部６４に蓄積される。

混雑状況算出部６４は、患者位置情報取得部６３により取得した患者位置情報を用いて、診療支援システム１０の稼働中、特定の患者Ｐ１が診療を受ける際の混雑状況を算出する。本実施形態では、診療を受ける前に患者Ｐが進入する待機区域を予め設定しており、患者位置情報から待機区域に特定の患者Ｐ１が進入していることを検出した場合、待機区域に進入している全ての患者Ｐの人数である待機人数と、この待機人数に対して特定の患者Ｐ１が待機区域に進入した順番を混雑状況として算出する。

図８は、患者位置情報を用いて混雑状況を算出する処理を説明するための一例である。なお、待合室Ｗは、予め設定され、診療を受ける前に患者Ｐが入室（進入）する待機区域である。また、図８においては、煩雑化を防ぐため、位置情報センサ１４及び携帯端末１６の図示を省略しているが、上記の図７の説明と同様に、位置情報センサ１４及び携帯端末１６の交信状態から患者位置情報を取得している。

図８（Ａ）は特定の患者Ｐが待合室Ｗに入室する場合の状態を示しており、待合室Ｗには２人の患者Ｐが入室している。図８（Ｂ）は、特定の患者Ｐ１が待合室Ｗに入室した際の状態を示している。上述したように、待合室Ｗには２人の患者Ｐが先に入室しているため、特定の患者Ｐ１が待合室Ｗに入室した順番は３人目である。そして、図８（Ｃ）は、現在の待合室Ｗの状態を示しており、待合室Ｗに入室している全ての患者Ｐの人数である待機人数が５人である。以上の患者位置情報が蓄積されることで、混雑状況算出部６４は、現在の待機人数が５人であり、５人の待機人数に対して特定の患者Ｐ１が待機区域に入室した順番が３人目であることを混雑状況として算出することができる。なお、既に診療を受けるため待合室Ｗから退室した患者Ｐについては、待機人数、及び入室した順番から除かれている。

医療スタッフがクライアント端末１１を用いて診療支援システム１０にログインした場合、表示画面生成部６２は、医療スタッフ毎にした設定等に基づいて、図９に示す初期画面７１を生成し、クライアント端末１１に提供する。これにより、クライアント端末１１は、初期画面７１を表示部３６の画面に表示する。

初期画面７１は、例えば、スケジュール表示欄７２、メール表示欄７３、リスト表示欄７４の３つの表示欄を有する。スケジュール表示欄７２及びメール表示欄７３の表示内容は、クライアント端末１１の作動プログラム３９の一部であるガジェットエンジンが、クライアント端末１１その他の装置又はシステムから情報を得て生成する。また、リスト表示欄７４は、本実施形態においては、クリニカルフロー画面８１の少なくとも一部を表示する。このため、表示画面生成部６２は、内容を含まないスケジュール表示欄７２及びメール表示欄７３と、クリニカルフロー画面８１の内容を含むリスト表示欄７４と、を含む初期画面７１を生成する。クライアント端末１１はガジェットエンジンを用いてスケジュール表示欄７２及びメール表示欄７３の内容を補充した初期画面７１を表示部３６の画面に表示する。

なお、表示すべき内容の全部がリスト表示欄７４内に収まらない場合、リスト表示欄７４に、又は、リスト表示欄７４の近傍に、リスト表示欄７４の表示内容を遷移（いわゆるスクロール）するスクロールバー７８及びスクロールバー７９を表示する。スクロールバー７８は、リスト表示欄７４の表示内容を左右方向に遷移し、非表示部分を表示する場合に操作するＧＵＩである。スクロールバー７９は、リスト表示欄７４の表示内容を上下方向に遷移することにより、非表示部分を表示する場合に操作するＧＵＩである。こうしたＧＵＩの表示及び制御はＧＵＩ制御部４１が行う。

上記の初期画面７１において、例えば、ポインティングデバイス（図示しない）等のＧＵＩを用いて所定のメニュー等の操作をした場合に、要求発行部４２は表示画面の配信要求を発行する。こうしたＧＵＩ等の操作に基づいて要求発行部４２が表示画面の配信要求を発行する動作は、表示画面配信要求ステップを構成する。本実施形態においては、リスト表示欄７４に一部を表示したクリニカルフロー画面８１の全体を表示するために、クリニカルフロー画面８１を表示するための操作を実行する。これにより、要求発行部４２は、クリニカルフロー画面８１の配信要求を発行する。

要求発行部４２が表示画面の配信要求を発行した場合、診療支援装置１２においては要求受付部６１がその表示画面の配信要求を受け、表示画面生成部６２がその表示画面の配信要求に係る表示画面を生成する。本実施形態においては、表示画面生成部６２は、サーバ群１３等から適宜取得等した診療プロセス等に係る情報を用いて、クリニカルフロー画面８１を生成する。

図１０に示すように、本実施形態において生成等するクリニカルフロー画面８１は、例えば、患者列Ｃ０１、診療項目列Ｃ０２、診療プロセス列Ｃ０３を備える。患者列Ｃ０１は、所定条件を満たす複数名の患者に係るリストを構成する。所定条件とは、例えば、当日の外来患者であること、担当がログインユーザである医療スタッフであること、又は、担当がログインユーザである医療スタッフが属するグループ（診療科等）であること、等である。図１０に示すクリニカルフロー画面８１の例では、クライアント端末１１にログインした医療スタッフである「医師 太郎」が担当する外来患者に係るリストである。また、本実施形態では、クリニカルフロー画面８１に表示される複数名の患者が、上述した特定の患者Ｐ１、Ｐ２、Ｐ３・・・に相当する。

診療項目列Ｃ０２は、各患者が受ける診療プロセスから診療項目名のみを抜き出したリストである。なお、診療プロセス列Ｃ０３は、初期画面７１におけるリスト表示欄７４と同様に、スクロール操作等により、非表示部分を表示することができる。

クリニカルフロー画面８１のうち、２行目以降の各行は、各患者の識別情報と、その患者の診療プロセスと、を対応付けた、いわゆるクリニカルフローを構成する。また、各患者のクリニカルフローに含む診療プロセスは、各診療プロセスが含む項目ごと（例えば診療データごと）に表示する。

患者列Ｃ０１には、患者名、患者識別情報、生年月日、年齢等が入力されている。また、診療項目列Ｃ０２には、診療項目を示す「診察」、「検体」、「放射線」、「生理」、「再診察」等が入力されている。診療項目列Ｃ０２に入力されている診療項目は、診療プロセス列Ｃ０３に入力されている各診療項目と対応している。なお、「検体」、「放射線」、「生理」は、それぞれ検体検査、放射線検査、生理検査の診療項目を示している。

診療プロセス列Ｃ０３には、患者が診療を受ける各診療項目が時系列順に並んで入力されている。さらに診療プロセス列Ｃ０３の各診療項目と、その診療項目のステータスが入力されている。診療項目のステータスとしては、例えば「未了」、「完了」、「実施中」等のいずれかが表示される。また、検体検査等のように、検査自体と、検査後の処理が必要な場合は、両方のステータスが表示される。そして、ステータスが「未了」の場合は開始予定時刻と所要時間が、「完了」の場合は終了時刻が、「処理中」の場合は終了予定時刻が、それぞれ入力されている。例えば、「富士 太郎」の場合、「富士 太郎」が受ける診察、検体検査、放射線検査、再診察の各診療項目が時系列順に並んでおり、診察、検体検査、および放射線検査の診療項目には、「完了」のステータスと終了時刻が、検体検査の診療項目には、検査自体の「完了」のステータスとともに、検体の「処理中」のステータスが入力されている。

本実施形態では、診療項目のステータスが「未了」でかつ患者Ｐが受ける診療に待ち時間が発生している場合、ステータス、開始予定時刻、所要時間とともに、混雑状況８２（２点鎖線で囲んでいる部分）が表示される。

この混雑状況８２は、上述したように、混雑状況算出部６４が算出した待機区域に進入している全ての患者Ｐの人数である待機人数と、待機人数に対して患者Ｐが待機区域に進入した順番の情報から構成されている。そして、本実施形態では、診療を受ける前に患者Ｐが進入する待機区域として各診察室又は各検査室に隣接する待合室を予め設定している。

例えば、「富士 太郎」の場合、「再診察」の診療項目に「未了」のステータス、開始予定時刻、及び所要時間とともに、混雑状況８２である「予定者１２人中７人目」という情報が表示されている。この場合、診察室に隣接する待合室が待機区域として予め設定されており、混雑状況算出部６４が待合室に入室している全ての患者Ｐの人数である待機人数と、待機人数に対して特定の患者Ｐ１である「富士 太郎」が待合室に入室した順番を混雑状況８２として算出する。なお、本実施形態では、待機人数に対して特定の患者Ｐ１が待合室に入室した順番を進捗状況ともいう。また、混雑状況８２としては文字情報に限らず、例えば、待機人数を人型のマークの数で表すなど、図で示すようにしてもよい。また、以降の実施形態においても混雑状況を図で示してもよい。

また、同じ「未了」のステータスの状態でも「富士 次郎」の場合、「放射線」及び「再診察」の診療項目については混雑状況８２が表示されていない。これは、「放射線」及び「再診察」の診療項目に対して予め設定された待合室に「富士 次郎」がまだ入室していないためである。

混雑状況算出部６４は、上記のように算出した待機人数や進捗状況等の混雑状況８２を表示画面生成部６２に入力する。そして、表示画面生成部６２が、混雑状況算出部６４による混雑状況を表示画面に付してクライアント端末１１に配信する。なお、以下の説明では、上述した混雑状況を表示画面に「付すことにより表示画面を更新する」ことを、「表示画面上に付して表示する」、「表示画面上に付す」、または、単に「表示画面上に表示する」、と称する場合がある。

また、患者位置情報取得部６３は、診療システムの稼働中、患者位置情報を取得しており、患者Ｐの移動に応じて患者位置情報が変化する。さらに、患者位置情報の変化に応じて混雑状況算出部６４が算出する混雑状況８２も変更されるため、表示画面生成部６２は、混雑状況８２が変更されるごとに、表示画面を更新する。

クライアント端末１１は、ログインユーザである医療スタッフが操作部３７を操作することにより、クリニカルフロー画面８１に表示される診療の開始予定時刻、所要時間等を修正したり、あるいは、特定の患者Ｐ１の診療予定の順番と、別の特定の患者Ｐ２の診療予定の順番を入れ替える編集要求を発行することもできる。なお、このような入れ替え操作は、各検査部門の医療スタッフなど権限を持つ者のみに制限して編集要求を発行することが好ましく、例えば、クライアント端末１１へのログインの際に入力する医療スタッフＩＤにより制限する。順番入れ替えの操作としては、例えば、クライアント端末１１にタッチパネルを備えている場合、ドラッグおよびドロップ操作で行うことが好ましい。表示画面生成部６２は、編集要求に基づき、患者が検査を受ける予定時刻の修正、又は検査を受ける予定の順番の入れ替えを行う。

表示画面生成部６２は、上記のように生成、編集、又は更新した表示画面を通信部５４を介してクライアント端末１１に配信する。これにより、クライアント端末１１は、表示画面生成部６２から提供を受けた表示画面を表示部３６に表示する。

以下、上記構成による作用について、図１１及び図１２示すフローチャートを参照しながら説明する。まず、医療スタッフは、クライアント端末１１を操作して作動プログラム３９を起動する。作動プログラム３９の起動により、クライアント端末１１のＣＰＵ３１にはＧＵＩ制御部４１および要求発行部４２が構築される。

図１１のステップＳ１００に示すように、医療スタッフは、表示画面を閲覧するためにログイン画面を通じて医療スタッフＩＤを入力する。これにより要求発行部４２から表示画面の配信要求が発行される。

診療支援装置１２では、作動プログラム５９が起動されてＣＰＵ５１には要求受付部６１、表示画面生成部６２、患者位置情報取得部６３、及び混雑状況算出部６４が構築される。

クライアント端末１１の要求発行部４２から発行された配信要求は、診療支援装置１２の要求受付部６１で受け付けられ、表示画面生成部６２に受け渡される。表示画面生成部６２は、ログインユーザした医療スタッフ毎の設定等に基づいて、診療プロセス等に関する情報をサーバ群１３等から適宜取得し、取得した診療プロセス等に関する情報を用いて、クリニカルフロー画面８１等の表示画面が生成される（ステップＳ２００）。また、この際、混雑状況算出部６４により算出され、クリニカルフロー画面８１に表示される複数名の患者に対する混雑状況８２が変更される。なお、混雑状況８２の変更については、図１２示すフローチャートで別途説明する。生成された表示画面は、クライアント端末１１に配信される（ステップＳ２１０）。

クライアント端末１１では、ＧＵＩ制御部４１によりクリニカルフロー画面８１等の表示画面が表示部３６に表示される（ステップＳ１１０）。

医療スタッフは、クリニカルフロー画面８１等の表示画面を閲覧し、各患者の診療プロセスの進捗状況を確認する。医療スタッフは、必要に応じて、診療プロセス列Ｃ０３に新たな診療項目を追加したり、各診療項目に対して「実施中」、「完了」等のステータスを入力する等の編集操作を行う。こうした各種編集操作がなされた場合（ステップＳ１２０でＹＥＳ）、要求発行部４２から編集要求が発行される（ステップＳ１３０）。

クライアント端末１１の要求発行部４２から発行された編集要求は、診療支援装置１２の要求受付部６１で受け付けられ、表示画面生成部６２に受け渡される。要求受付部６１からの編集要求に基づき、表示画面生成部６２により画面編集が行われる（Ｓ２２０）。編集後の表示画面は、クライアント端末１１に配信される（ステップＳ２３０）。なお、この際、クリニカルフロー画面８１に表示される患者の診療データに対して編集要求により変更があった際は、表示画面生成部６２は、サーバ群１３にもアクセスして診療データの更新を行う。

クライアント端末１１では、ＧＵＩ制御部４１により編集後の表示画面が表示部３６に表示される（ステップＳ１４０）。各医療スタッフは、クリニカルフロー画面８１等を閲覧することで、各患者の診療プロセスのリストとともに混雑状況８２を一度に確認することができる。

クライアント端末１１は、医療スタッフによりログアウトの指示がされない間（ステップＳ１５０でＮＯ）は、上記ステップＳ１２０～ステップＳ１４０を繰り返す。同様に診療支援装置１２も、ログアウトの指示が要求受付部６１で受け付けられない間（ステップＳ２４０でＮＯ）は、上記ステップＳ２２０及びステップＳ２３０を繰り返す。

なお、図１１では１台のクライアント端末１１と診療支援装置１２の処理手順を示したが、実際には診療支援装置１２は複数台のクライアント端末１１からの配信要求や編集要求を受け付け、複数台のクライアント端末１１に対する表示画面の生成や編集、及び配信を並行して行っている。さらに、図１１には含まれていないが、診療支援装置１２は、表示画面の生成や編集、及び配信に加えて、ログイン中には、新規患者のクリニカルフロー追加と、混雑状況８２の更新も常時行っており、配信される表示画面には、最新の混雑状況８２を付した画面が作成される。

図１２に示すフローチャートでは、診療支援装置１２が混雑状況８２を更新する処理について説明する。先ずログインから初期の表示画面を生成するまでは、図１１と同様のため省略する。そして、新規患者の受付要求がクライアント端末１１からあった場合（ステップＳ３００でＹＥＳ、本実施形態では新規の外来患者を受け付けた場合）、診療支援装置１２は、クリニカルフロー画面８１において表示する患者のリストに新規患者のクリニカルフローを追加する（ステップＳ３１０）。そして、新規患者のクリニカルフローを追加したクリニカルフロー画面８１等の表示画面を配信する（ステップＳ３２０）。なお、新規患者のクリニカルフローをリストに追加した時点では、クリニカルフローの各診療項目の内容を空欄にした状態で配信し、クライアント端末１１から入力可能としてもよい。

また、新規患者の受付要求が無かった場合（ステップＳ３００でＮＯ）、初期の表示画面のまま配信するか、後述のように患者位置情報に変更があった場合、混雑状況８２を更新してから表示画面を配信する。

ステップＳ３３０に示すように、患者位置情報に変化があった場合（ステップＳ３３０でＹＥＳ）、上述したように、混雑状況算出部６４は患者位置情報を用いて混雑状況８２の算出を行う（ステップＳ３４０）。混雑状況算出部６４により算出された最新の混雑状況８２が表示画面に付され、混雑情報が更新された表示画面がクライアント端末１１に配信される（ステップＳ３５０）。また、ログアウトの指示が要求受付部６１で受け付けられない間（ステップＳ３６０でＮＯ）は、上記ステップＳ３００～ステップＳ３５０を繰り返す。

上記のように、混雑状況が付されたクリニカルフロー画面８１等の表示画面が表示されることで、診療プロセスのリストとともに、混雑状況が一度に分かる。これにより、患者の混雑状況に応じて、適切なスケジュールで診療を進行することが。特に、同じ時間帯に同じ検査等の予約を入れないように注意することができる。さらに、診療プロセスのリストとともに、混雑状況を知ることで、実際の検査時間を把握しやすく、検査の後段の診療等の遅延を最小限にすることができる。また、混雑状況に応じて診療の開始予定時刻を修正したり、手の空いている別の医療スタッフに担当を代わってもらうこともできる。

また、従来の診療支援装置のように診療プロセスのリストと混雑状況が一度に閲覧できない場合、重症度等に応じた優先度が高く、早めに検査を行いたい患者の順番が後になってしまうことがあったが、本実施形態では、診療プロセスのリストとともに、混雑状況が一度に分かるため、混雑状況に応じて優先度の高い患者の診療を先に行う等の対応をすることができる。さらにまた、混雑状況として、待機人数や、進捗状況をクライアント端末１１に表示しているので、混雑状況をより把握しやすくなっている。

［第２実施形態］

上記第１実施形態においては、混雑状況算出部６４は、特定の患者が待機区域に進入した順番を混雑状況として算出しているが、これに限らず、第２実施形態の診療支援装置では、表示画面生成部６２から診療プロセスを構成する検査予定時刻の情報を取得し、待機区域に進入している患者を検査予定時刻が早い順に並べた順番を混雑状況として算出してもよい。なお、混雑状況算出部６４以外の構成は、上記第１実施形態と同様である。

図１３及び図１４は、本実施形態において混雑状況算出部６４が混雑状況を算出する際の処理を説明するための説明図である。例えば、図１３に示すように、患者位置情報取得部６３が取得した患者位置情報において、現在の待合室Ｗに患者Ｐ１～Ｐ５が入室している場合、混雑状況算出部６４は、先ず、待合室Ｗに入室している待機人数を算出し、かつ表示画面生成部６２から患者Ｐ１～Ｐ５の検査予定時刻の情報を取得する。本実施形態では、表示画面生成部６２から取得する検査予定時刻とは、クリニカルフロー画面８１を構成する情報に含まれる検査予定時刻の情報である。これらの検査予定時刻は、例えば、医療スタッフにより各クライアント端末１１から入力されている。あるいは、検査予定時刻としては、後述する第３実施形態で説明しているように患者位置情報の履歴を用いて検査時間情報を蓄積し、蓄積した検査時間情報を、患者情報、検査内容情報、検査結果情報、検査実施者情報、検査機器情報、日時情報等を加味して統計処理して算出した検査時間情報（検査所要時間及び検査待ち時間）を用いて、診療支援装置１２が算出した時刻を取得してもよい。なお、待合室Ｗは、予め設定され、特定の検査を受ける前に患者Ｐが進入する待機区域である。

図１４は、混雑状況算出部６４が表示画面生成部６２から取得した患者Ｐ１～Ｐ５の検査予定時刻の一例である。図１４の表に示す患者Ｐ１～Ｐ５は、図１３に示す待合室Ｗに入室した患者Ｐ１～Ｐ５に対応している。混雑状況算出部６４は、患者Ｐ１～Ｐ５を検査予定時刻が早い順に並べた順番を混雑状況として算出する。図１４に示す例では、例えば患者Ｐ１は、検査予定時刻が早い順に並べた順番では、３人目であり、進捗状況が「予定者５人中３人目」であることが分かる。混雑状況算出部６４は、上記のように算出した進捗状況を混雑状況として表示画面生成部６２に入力する。そして、表示画面生成部６２が、混雑状況算出部６４による混雑状況を表示画面に付してクライアント端末１１に配信する。

上記のように、患者位置情報とともに、診療プロセスを構成する検査予定時刻の情報を用いて混雑状況を算出しているので、より精度の高い混雑状況を算出することができる。

［第３実施形態］

以下で説明する第３実施形態では、検査時間情報蓄積部を備え、この検査時間情報蓄積部が蓄積した検査時間情報を用いて統計処理し、混雑状況を算出する。図１５に示すように、診療支援装置８５は、検査時間情報蓄積部８６を備えている。なお、検査時間情報蓄積部８６以外の構成は、上記第１及び第２実施形態の診療支援装置１２と同様である。また、本実施形態において統計処理に用いる診療プロセスのデータとしては、上記第１及び第２実施形態のクリニカルフロー画面８１に表示される診療プロセスのデータと同様のデータである。

検査時間情報蓄積部８６は、患者位置情報取得部６３が取得した患者位置情報の履歴を用いて、診療プロセスを構成する検査ごとの検査所要時間及び検査待ち時間から構成される検査時間情報を蓄積する。なお、検査時間情報蓄積部８６が検査時間情報を蓄積するのは、診療支援装置８５に備えた記憶装置でもよいし、サーバ群１３のいずれかに蓄積してもよい。サーバ群１３のいずれかに検査時間情報を蓄積する場合、検査時間情報蓄積部８６は、サーバ群１３にもともと記憶されていた診療データのうち、患者情報、検査内容情報、検査結果情報、検査実施者情報、検査機器情報、日時情報のうち少なくとも1つと検査時間情報とを対応付けて蓄積することが好ましい。

検査時間情報と対応付けて蓄積する患者情報としては、性別、年齢（幼年、若年、老齢）、障害の有無（視覚障害、足障害、認知症等）、症状重篤度（検査に時間を要する又は注意深い検査必要）等であり、特に検査進行に影響を与える項目を考慮している（以下の検査内容情報、検査結果情報、検査実施者情報、検査機器情報、日時情報についても同様である。）。また、検査内容情報としては、放射線検査、生理検査、検体検査、内視鏡検査等であり、さらに検査部位等の情報が含まれていてもよい。検査結果情報としては、異常値であるか否か、検査実施者が注意を要する点、再検査の有無である。検査実施者情報としては、ベテラン又は若手等の検査熟練度や、慎重・スピーディ等検査実施者個別の検査速度である。検査機器情報としては、新型（測定時間が速い）か旧型（測定時間が遅い）か、装置型番や装置の製造メーカー等である。日時情報としては、検体検査等の場合、午前中に集中する傾向があるか否か（検体処理に時間がかかるため）、上部内視鏡検査の場合も、午前中に集中する傾向があるか否か（空腹状態で実施する必要があるため）、また休診日明けか否か、曜日・時間・月末等混雑しやすい日付である等の情報である。

図１６及び図１７は、本実施形態において、患者位置情報の履歴を用いて検査時間情報蓄積部８６が検査時間情報を蓄積するときの状況を説明するための説明図である。図１６及び図１７に示す例は、診療プロセスを構成する検査の１つを患者Ｐ１が受けた際の患者位置情報の履歴および検査時間情報であり、患者Ｐ１は、医療施設１７内を丸数字１、２、３、４、５、６の順番で移動しており、図１６における丸数字の場所と、図１７における丸数字の場所が対応している。

患者Ｐ１は、受付、第１待合室、更衣室、第２待合室、検査室、第２待合室の順番で移動していることが患者位置情報の履歴から分かる。そして、検査時間情報蓄積部８６は、患者位置情報の履歴から患者Ｐ１が各場所に入室及び退室した時刻を用いて検査所要時間、及び検査待ち時間を算出することができる。すなわち、検査室に入室した時刻と退室した時刻との差から検査所要時間を算出し、第２待合室に入室した時刻と退室した時刻との差から検査待ち時間を算出することができる。このようにして、検査時間情報蓄積部８６は、診療プロセスを構成する検査ごとの検査所要時間及び検査待ち時間から構成される検査時間情報を蓄積する。

本実施形態では、混雑状況算出部６４は、検査時間情報蓄積部８６が蓄積した検査時間情報を用いて統計処理し、混雑状況を算出する。この場合、例えば、患者を予め複数の種類に分類し、検査時間情報蓄積部８６が蓄積した検査時間情報を用いて統計処理する。図１８は、検査時間情報蓄積部８６が蓄積した検査時間情報の一例である。なお、図１８に示す例では、「診察」、「検体」、「生理」、「放射線」、「再診察」等の診療項目については、入室時刻と退室時刻（各診療項目の上段が入室時刻、下段が退室時刻）を蓄積しており、診療項目から次の診療項目までの時間を待ち時間として蓄積し、受付から会計までの時間を「ＴＯＴＡＬ」（全体）の時間として蓄積している。なお、各診療項目の入室時刻と退室時刻の両方ではなく、入室時刻と退室時刻の差を蓄積してもよい。また、この検査時間情報は、患者情報としての識別情報、年齢、及び足障害の有無等の情報と対応付けて蓄積されている。

図１８に示す例では、患者の種類として、検査時間情報と対応付けて蓄積した患者情報のうち年齢を使用し、例えば、２０代、３０代、４０代、５０代、及び６０代以上の高齢者等の年代ごとに分類し、年代ごとの検査時間情報を統計処理する。統計処理としては、例えば、数学的手法等の一般的な手法で行う。また、上述した患者情報、検査内容情報、検査結果情報、検査実施者情報、検査機器情報、日時情報等のいずれかで患者の種類を分類して統計処理を行ってもよい。

そして、混雑状況算出部６４は、上記の統計処理により患者の種類ごとの検査所要時間又は検査待ち時間を算出し、さらに患者種類別の検査所要時間又は検査待ち時間を用いて全体検査所要時間や全体検査待ち時間を混雑状況として算出することができる。すなわち、検査予定の患者に応じた患者種類別の検査所要時間又は検査待ち時間を使用し、これらの値を検査予定の患者に応じて積算していき全体検査所要時間又は全体検査待ち時間を算出する。

図１８に示す例の場合、例えば、２０代、３０代、４０代、５０代、及び高齢者の患者種類別の検査所要時間を積算して全帯検査所要時間を算出する。算出した混雑状況は、上記第１及び第２実施形態と同様に、表示画面に付してクライアント端末１１に配信する。この場合、例えば、特定の患者に対して、この患者の前の検査予定の患者に応じて算出した全体検査所要時間を現在の時刻に足して開始予定時刻として表示画面に付してもよい。あるいは、特定の患者の待ち時間として、特定の患者の前の検査予定の患者に応じて算出した全体検査待ち時間を算出して表示画面に付してもよい。以上のように、診療プロセスを構成する検査ごとの検査時間情報を用いて統計処理し、混雑状況を算出しているので、より精度の高い混雑状況を算出することができる。

図１９は、上記各実施形態の変形例として、クライアント端末１１に配信されるクリニカルフロー画面の一例を示している。この変形例では、患者が受けた検査結果に対して早急な対応が必要と判断された場合、医療スタッフが所持するクライアント端末１１に、早急な対応が必要であることを示す報知情報（パニック値ともいう。）を送信する。パニック値とは、生命が危ぶまれるほど危険な状態にあることを示唆する異常値で直ちに治療を開始すれば救命しうるが，その診断は臨床的な診察だけでは困難で検査によってのみ可能であることをいう。

図１９に示す例では、クリニカルフロー画面９０の一部を示しており、「富士 太郎」の検体検査の診療項目において、「検査結果に注意が必要です」という文字情報とともに報知情報としての図形９１を付している。この報知情報は、例えば検査を担当する医師等の医療スタッフのクライアント端末１１から入力することができる。なお、報知情報を表示画面に付した以外は、上記第１及び第２実施形態と同様であり、診療支援装置１２は報知情報を付した表示画面をクライアント端末１１に配信する。あるいは、患者Ｐが携帯している携帯端末１６に報知情報を配信してもよい。これにより、検査を担当する医療スタッフ以外の医療スタッフ又は患者本人も、クライアント端末１１又は携帯端末１６を閲覧することで、早急な対応が必要であることを認識することができる。

また、別の変形例として、表示画面生成部６２は、図２０に示すように、上記各実施形態の表示画面とは異なる検査別表示画面９３を生成してクライアント端末１１に配信する。この検査別表示画面９３は、クリニカルフロー画面８１を構成する診療プロセスから、所定条件を満たす特定の検査を受ける患者のみを抽出し、検査を受ける予定の順番、又は検査を受ける予定時刻に従って並べ替えた画面である。所定条件を満たす特定の検査とは、例えば、ログインユーザである医療スタッフが担当する検査であること、又は、ログインユーザである医療スタッフが属するグループ（診療科等）の検査であること、等である。図２０に示す例は、放射線検査を受ける患者のみを抽出し、放射線検査を受ける予定の順番、又は検査を受ける予定時刻に従って並べ替えた画面である。これにより、医療スタッフは、検査スケジュールが分かりやすいうえに、混雑状況も容易に把握することができる。

また、図２０に示す検査別表示画面９３では、各患者の現在位置情報を表示している。例えば「富士 零子」の場合、「２階南トイレ」に入室していることを示し、「富士 三郎」の場合、「待合室」に入室していることを示している。この現在位置情報は、患者位置情報取得部６３で取得した最新の患者位置情報を用いている。なお、このような現在位置情報の表示は検査別表示画面９３に限らず、上記各実施形態の表示画面で同様の表示を行ってもよい。また、現在位置情報としては、文字情報に限らず、図７に示すような位置情報のマップを表示画面に重畳表示させてもよく、場所を示す図形（屋内、トイレ、階段のマーク等）や、待機区域からの距離に応じて異なる色で表示する等表示態様を変えて表示させてもよい。

また、現在位置情報でまだ待機区域に進入している患者と、進入していない患者とがいる場合、順番を入れ替え可能としてもよい。図２０に示す例では、「待合室」に入室している「富士 三郎」と、入室していない「富士 零子」がいる場合、担当検査部門のクライアント端末１１からの編集要求により「富士 零子」と「富士 三郎」の順番を入れ替え、既に入室している「富士 三郎」の順番を先にすることができる。順番入れ替えの操作としては、上記各実施形態と同様に、各検査部門からの編集要求に制限すること、ドラッグおよびドロップ操作で行うことが好ましい。あるいは、順番を上げる又は順番を下げるボタンを各患者の識別情報付近に表示させ、これらのボタンをタッチ操作した場合、順番を変更できるようにしてもよい。

なお、患者位置情報を取得する構成としては、上記各実施形態では、患者Ｐが所持する携帯端末１６、ＲＦＩＤタグ、又は位置取得専用の端末から発信する電波を位置情報センサ１４が受信する構成を例示しているが、これらに限定するものではなく、例えば、患者位置情報を取得する技術としては、上記各実施形態に記載したものに限定せず、ＩＭＥＳ（ｉｎｄｏｏｒ ｍｅｓｓａｇｉｎｇ ｓｙｓｔｅｍ）、又はＢＬＥ（Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ）等屋内用の位置検出技術を利用することが好ましい。あるいは、患者の顔画像等を予め取得し、医療施設内に配置したカメラで撮像した画像から画像認識技術を用いて患者位置情報を取得してもよい。

上記各実施形態において、ＧＵＩ制御部４１、要求発行部４２、要求受付部６１、表示画面生成部６２、患者位置情報取得部６３、混雑状況算出部６４、及び、検査時間情報蓄積部８６等といった各種の処理を実行する処理部（ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）のハードウェア的な構造は、次に示すような各種のプロセッサ（Ｐｒｏｃｅｓｓｏｒ）である。各種のプロセッサには、ソフトウエア（プログラム）を実行して各種の処理部として機能する汎用的なプロセッサであるＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＧＰＵ（ｇｒａｐｈｉｃａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＦＰＧＡ （Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ） 等の製造後に回路構成を変更可能なプロセッサであるプログラマブルロジックデバイス（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ:ＰＬＤ）、各種の処理を実行するために専用に設計された回路構成を有するプロセッサである専用電気回路等が含まれる。

１つの処理部は、これら各種のプロセッサのうちの１つで構成されてもよいし、同種又は異種の２つ以上のプロセッサの組み合せ（例えば、複数のＦＰＧＡや、ＣＰＵとＦＰＧＡの組み合わせ、又はＣＰＵとＧＰＵの組み合わせ等）で構成されてもよい。また、複数の処理部を１つのプロセッサで構成してもよい。複数の処理部を１つのプロセッサで構成する例としては、第１に、クライアントやサーバ等のコンピュータに代表されるように、１つ以上のＣＰＵとソフトウエアの組み合わせで１つのプロセッサを構成し、このプロセッサが複数の処理部として機能する形態がある。第２に、システムオンチップ（Ｓｙｓｔｅｍ Ｏｎ Ｃｈｉｐ:ＳｏＣ）等に代表されるように、複数の処理部を含むシステム全体の機能を１つのＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）チップで実現するプロセッサを使用する形態がある。このように、各種の処理部は、ハードウェア的な構造として、上記各種のプロセッサを１つ以上用いて構成される。

さらに、これらの各種のプロセッサのハードウェア的な構造は、より具体的には、半導体素子等の回路素子を組み合わせた形態の電気回路（ｃｉｒｃｕｉｔｒｙ）である。

上記記載から、以下の付記項１に記載の診療支援装置を把握することができる。

［付記項１］

プロセッサを備え、 プロセッサは、 複数名の患者について、患者ごとに、患者の識別情報と診療プロセスとを対応付けて表示する表示画面を生成し、

医療施設内における患者の位置情報を取得し、

診療プロセスにおける診療を患者が受ける際の混雑状況を、取得した患者位置情報を用いて算出し、

算出された混雑状況を表示画面上に表示する診療支援装置。

１０ 診療支援システム

１１ クライアント端末

１２ 診療支援装置

１３ サーバ群

１４ 位置情報センサ

１５ ネットワーク

１６ 携帯端末

１７ 医療施設

２１ 電子カルテサーバ

２１Ａ カルテデータベース

２２ 画像サーバ

２２Ａ 画像データベース

２３ レポートサーバ

２３Ａ レポートデータベース

３２ メモリ

３３ ストレージ

３４ 通信部

３５ 接続回路

３６ 表示部

３７ 操作部

３９ 作動プログラム

４１ ＧＵＩ（ｇｒａｐｈｉｃａｌ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ）制御部

４２ 要求発行部

５２ メモリ

５３ ストレージ

５４ 通信部

５５ 接続回路

５９ 作動プログラム

６１ 要求受付部

６２ 表示画面生成部

６３ 患者位置情報取得部

６４ 混雑状況算出部

７１ 初期画面

７２ スケジュール表示欄

７３ メール表示欄

７４ リスト表示欄

７８ スクロールバー

７９ スクロールバー

８１ クリニカルフロー画面

８２ 混雑状況

８５ 診療支援装置

８６ 検査時間情報蓄積部

９０ クリニカルフロー画面

９１ 図形

９３ 検査別表示画面

Claims (12)

1. 
   複数名の患者について、前記患者ごとに、前記患者の識別情報と診療プロセスとを対応付けて表示する表示画面を生成する表示画面生成部と、
   
   医療施設内における前記患者の位置情報を取得する患者位置情報取得部と、
   
   前記診療プロセスにおける診療を前記患者が受ける際の混雑状況を、前記患者位置情報取得部により取得した患者位置情報を用いて算出する混雑状況算出部とを備え、
   
   前記混雑状況算出部により算出された前記混雑状況を前記表示画面上に表示する診療支援装置。
   
2. 
   前記混雑状況算出部は、診療を受ける前に前記患者が進入する待機区域を予め設定しており、前記患者位置情報から前記待機区域に前記患者が進入している場合、前記混雑状況として前記待機区域に進入している全ての前記患者の人数である待機人数を算出する請求項１記載の診療支援装置。
   
3. 
   前記混雑状況算出部は、前記待機人数を算出し、かつ前記表示画面生成部から前記診療プロセスにおける検査予定時刻の情報を取得し、前記待機区域に進入している前記患者を前記検査予定時刻が早い順に並べた順番を前記混雑状況として算出する請求項２記載の診療支援装置。
   
4. 
   前記患者位置情報の履歴を用いて、前記診療プロセスを構成する検査ごとの検査所要時間及び検査待ち時間から構成される検査時間情報を蓄積する検査時間情報蓄積部を備えた請求項１ないし３のいずれか１項記載の診療支援装置。
   
5. 
   前記検査時間情報蓄積部は、前記検査時間情報に、患者情報、検査内容情報、検査結果情報、検査実施者情報、検査機器情報、及び日時情報のうち少なくとも1つと対応付けて蓄積する請求項４記載の診療支援装置。
   
6. 
   前記混雑状況算出部は、前記患者を予め複数の種類に分類し、前記検査時間情報を用いて統計処理することにより前記種類ごとの検査所要時間又は検査待ち時間を算出し、前記種類ごとの検査所要時間又は検査待ち時間を用いて全体検査所要時間又は全体検査待ち時間を前記混雑状況として算出する請求項４又は５記載の診療支援装置。
   
7. 
   前記患者が受けた検査結果に対して早急な対応が必要と判断された場合、前記表示画面上に報知情報を表示する請求項１ないし６のいずれか１項記載の診療支援装置。
   
8. 
   前記患者が受けた検査結果に対して早急な対応が必要と判断された場合、医療スタッフ又は前記患者が所持する端末に報知情報を送信する請求項１ないし７のいずれか１項記載の診療支援装置。
   
9. 
   前記表示画面生成部は、前記診療プロセスを構成する検査のうち、所定条件を満たす特定の検査を受ける患者のみを抽出し、前記特定の検査を受ける予定の順番、又は前記特定の検査を受ける予定時刻に従って並べ替えた検査別表示画面を生成する請求項１ないし８のいずれか１項記載の診療支援装置。
   
10. 
    前記表示画面上に、各患者の現在位置情報を表示する１ないし９のいずれか１項記載の診療支援装置。
    
11. 
    前記表示画面生成部は、各検査部門からの編集要求があった場合、前記患者が診療を受ける予定時刻の修正、又は診療を受ける予定の順番の入れ替えを行う請求項１ないし１０のいずれか１項記載の診療支援装置。
    
12. 
    診療支援装置とクライアント端末とこれらを相互に通信可能に接続するネットワークとで構成される診療支援システムであって、
    
    複数名の患者について、前記患者ごとに、前記患者の識別情報と診療プロセスとを対応付けて表示する表示画面を生成する表示画面生成部と、
    
    医療施設内における前記患者の位置情報を取得する患者位置情報取得部と、
    
    前記診療プロセスにおける診療を前記患者が受ける際の混雑状況を、前記患者位置情報取得部により取得した患者位置情報を用いて算出する混雑状況算出部とを備え、
    
    前記混雑状況算出部により算出された前記混雑状況を前記表示画面上に表示する診療支援システム。

Images