JP2017058885A - 端末管理装置及び端末システム - Google Patents

Abstract

【課題】端末のオペレータを精度よく特定できる端末管理装置及び端末システムを提供する。【解決手段】一実施形態に係る端末管理装置は、ユーザ特定部と、オペレータ判定部と、を備える。ユーザ特定部は、端末の少なくとも表示部に表示されている内容を肉眼で見ることができる領域または操作部を操作することができる領域の何れかの領域内に存在する、ユーザが携帯する無線機から取得した無線信号に基づいて、端末から領域内にいるユーザを特定する。オペレータ判定部は、ユーザ特定部が特定したユーザがオペレータであるかを無線機が受信した無線信号の受信状態情報に基づいて判定する。【選択図】図１

Description

本発明の実施形態は、端末管理装置及び端末システムに関する。

医療用端末システムなどの端末システムでは、１台の端末が複数のユーザにより共用されることがある。従来、ユーザが携帯した無線機器との無線通信により、ユーザの認証や管理を行う端末システムが知られている。しかしながら、従来の端末システムでは、端末を操作するユーザがかわる度に、認証やユーザ確認の為にログインが要求されたため、ユーザの作業効率が低下するという問題があった。また、既にあるユーザによってログインされている端末をログインしていない他のユーザが利用することも可能であった。結果として、実際に端末を操作しているユーザ（オペレータ）を特定することが困難であった。

特開２００８−１７６３８８号公報

端末のオペレータを精度よく特定できる端末管理装置及び端末システムを提供する。

一実施形態に係る端末管理装置は、ユーザ特定部と、オペレータ判定部と、を備える。ユーザ特定部は、端末の少なくとも表示部に表示されている内容を肉眼で見ることができる領域または操作部を操作することができる領域の何れかの領域内に存在する、ユーザが携帯する無線機から取得した無線信号に基づいて、端末から領域内にいるユーザを特定する。オペレータ判定部は、ユーザ特定部が特定したユーザがオペレータであるかを無線機が受信した無線信号の受信状態情報に基づいて判定する。オペレータとは、端末を実際に操作しているユーザのことである。

第１実施形態に係る端末システムの一例を示す図。 ユーザＩＤテーブルの一例を示す図。 移動履歴テーブルの一例を示す図。 ユーザ情報テーブルの一例を示す図。 アプリケーションテーブルの一例を示す図。 端末に対するユーザの状態（距離）の遷移を示す状態遷移図。 オペレータの登場及び退場の検知タイミングの一例を示す図。 オペレータ判定部による処理の一例を示すフローチャート。 図８の処理により更新された移動履歴テーブルをグラフ化した図。 オペレータ判定部による処理の他の例を示すフローチャート。 図１０の処理により更新された移動履歴テーブルをグラフ化した図。 端末管理装置のハードウェア構成を示す図。 第２実施形態に係る端末システムの一例を示す図。 第３実施形態に係る端末システムの一例を示す図。

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

（第１実施形態）
第１実施形態に係る端末システムについて、図１〜図１２を参照して説明する。本実施形態に係る端末システムは、１つの端末を一人又は複数のユーザが利用可能であり、かつ、端末が一人のオペレータにより操作される任意の端末システムに適用可能である。ここでいうユーザとは、端末システムのユーザとしてＩＤを登録された、端末を利用可能な人のことである。また、オペレータとは、端末を実際に操作しているユーザのことである。以下では、端末システムが医療用端末システムに適用された場合を例に説明する。

図１は、本実施形態に係る端末システムの一例を示す図である。図１に示すように、端末システムは、端末１と、無線送信機２と、無線受信機３と、端末管理装置４と、を備える。

端末１は、ユーザにより使用される、１つ又は複数の医療用のアプリケーションが動作するコンピュータである。端末１は、端末管理装置４と接続され、端末管理装置４によってアプリケーションの動作を制御される。端末１は、例えば、クライアント／サーバ型のアーキテクチャやサーバサイドアプリケーション型のアーキテクチャを有する医療システムのクライアントである。図１の例では、端末システムは、端末１を備えるが、複数備えてもよい。

端末１は、画像を表示する表示部（ディスプレイ）１１と、オペレータが操作するための操作部（キーボードやマウスなど）１２と、アプリケーション（実行モジュールなど）やＯＳ（オペレーティングシステム）を実行する処理回路（プロセッサ）と、アプリケーション（実行モジュールなど）やＯＳを記憶する記憶回路と、を備える。

なお、本実施形態において、端末１上で動作するアプリケーションには、その実行モジュールが端末１により記憶及び実行されるアプリケーションや、その実行モジュールが医療用システムのサーバに記憶され、サーバから実行モジュールを受け取った端末１により実行されるアプリケーションが含まれる。また、端末１上で動作するアプリケーションは、その実行モジュールが医療用システムのサーバにより記憶及び実行され、そのＧＵＩ（Graphical User Interface）が端末１の表示部１１に表示されるアプリケーションであってもよい。この場合、端末１は、アプリケーションの入出力端末の役割を果たす。

無線送信機２は、端末１のユーザにより携帯される。無線送信機２は、所定の時間間隔で無線信号を送信する。無線信号には、送信機ＩＤ（identifier）が含まれる。送信機ＩＤとは、無線送信機２を特定するための識別子である。図１の例では、無線送信機２は、１つしか示されていないが、ユーザが複数いる場合、端末システムには、各ユーザが携帯する複数の無線送信機２が含まれる。

無線送信機２は、例えば、コイン電池で稼働するペンダント型のビーコン発信器である。ビーコン発信器は、電池寿命が長く、充電も不要なため、長期間継続して使用できるという利点がある。ビーコン発信器の通信距離は、送信電波強度、遮蔽物などの設置環境、及び機器の個体差などに応じて異なるが、遮蔽物がない場合、３０ｍ程度である。

無線受信機３は、端末１に対する所定の領域内に設けられ、端末管理装置４に接続される。所定の領域とは、端末１の表示部１１に表示されている内容を肉眼で見ることができる領域、又は端末１の操作部１２を操作することができる領域のことである。無線受信機３は、端末１に組み込まれていてもよいし、端末１の近傍に設置されていてもよい。例えば、受信範囲に指向性を有する無線受信機３を、端末１の表示部１１と操作部１２との間に設置することが考えられる。無線受信機３は、無線送信機２が送信した無線信号を受信する。無線送信機２から無線信号を受信した無線受信機３は、無線信号に含まれる無線送信機２の送信機ＩＤを出力する。出力された送信機ＩＤは、端末管理装置４に入力される。

無線送信機２と無線受信機３との間の無線通信の通信規格は、無線ＬＡＮ（IEEE 802.11諸規格に準拠した機器で構成されるネットワーク）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ、及びＮＦＣ（Near Field Communication）など、任意に選択可能である。

通信規格がＢｌｕｅｔｏｏｔｈ（登録商標）である場合、例えば、無線送信機２としてビーコン発信器が用いられ、無線受信機３としてビーコン受信機が用いられる。ビーコン発信器は、所定の間隔で所定の強度の所定の無線信号（ビーコン）を発信する。この場合、無線受信機３は、無線送信機２から受信したビーコンの信号強度に基づいて、無線送信機２との間の距離を特定できる。

本実施形態では、無線送信機２はユーザに携帯され、無線受信機３は端末１に設けられるため、無線送信機２と無線受信機３との間の距離は、端末１とユーザとの距離に相当する。

距離は、例えば、５０ｃｍ未満であることを示すＩＭＭＥＤＩＡＴＥ、５０ｃｍ以上６ｍ未満であることを示すＮＥＡＲ、及び６ｍ以上２０ｍ未満であることを示すＦＡＲ、の３値で表される。この無線受信機３は、送信機ＩＤとともに、無線送信機２との間の距離を出力してもよい。

また、複数の無線受信機３を、その信号受信可能領域が一部重なり合う状態で端末１の周りに配置し、複数の無線受信機３による同一の無線送信機２からの信号受信状態に基づいて、無線送信機２と端末１との位置関係を特定しても良い。

さらに、通信規格がＮＦＣである場合、例えば、無線送信機２として非接触タグが用いられ、無線受信機３として非接触タグ読み取り装置が用いられる。非接触タグは、非接触タグ読み取り装置が所定の間隔で発信する電波を受信すると、予め記憶されたデータを無線で送信する。したがって、非接触タグに予め送信機ＩＤを記憶させることで、非接触タグ読み取り装置からの電波を受信した非接触タグから送信機ＩＤを含む無線信号を送信させることができる。

無線送信機２として非接触タグを用いる場合、無線受信機３（非接触タグ読み取り装置）は、信号強度に基づいて無線送信機２との間の距離を特定できない。非接触タグは、非接触タグ読み取り装置から或る距離以内に近接し、非接触タグ読み取り装置からの電波を受信することができないと、データを無線送信することができない。したがって、非接触タグ読み取り装置がデータを受信した非接触タグは、非接触タグ読み取り装置から所定の距離内に存在しているものとみなしてもよい。

また、非接触タグ読み取り装置は、非接触タグから受信した送信機ＩＤをその受信時刻または電波発信時刻と対応付けて履歴データとして記憶し、この履歴データに基づいて非接触タグ読み取り装置から所定の距離内に存在していた非接触タグの送信機ＩＤを特定してもよい。

なお、以下では、無線送信機２がビーコン発信器であり、無線送信機２と無線受信機３との間の通信規格がＢｌｕｅｔｏｏｔｈ（登録商標）である場合を例に説明する。無線受信機３は、無線信号を受信すると、無線送信機２の送信機ＩＤと、無線送信機２との間の距離と、を出力するものとする。

端末管理装置４は、端末１を管理するコンピュータであり、端末１及び無線受信機３と接続されている。端末管理装置４のハードウェア構成について、詳しくは後述する。図１では、端末管理装置４の機能構成が図示されている。

図１に示すように、端末管理装置４は、ユーザＩＤテーブル４１と、移動履歴テーブル４２と、ユーザ情報テーブル４３と、アプリケーションテーブル４４と、ユーザ位置特定部４５と、オペレータ判定部４６と、アプリケーション制御部４７と、を備える。

ユーザＩＤテーブル４１は、無線送信機２と、無線送信機２を携帯するユーザと、の対応関係を格納するテーブルである。ユーザＩＤテーブル４１は、端末システムや医療システムの管理者により更新される。

図２は、ユーザＩＤテーブルの一例を示す図である。図２の例では、ユーザＩＤテーブル４１の各レコードに、レコード番号（Ｎｏ）、ユーザＩＤ、及び送信機ＩＤが含まれる。ユーザＩＤとは、ユーザを特定するための識別子である。以下では、レコード番号Ｘにより特定されるレコードを、レコードＸという。

例えば、図２のレコード１は、ユーザＩＤがＴＯＳＨＩＢＡ−１のユーザが、送信機ＩＤがＢＥＡＣＯＮ−１の無線送信機２を携帯していることを示している。

移動履歴テーブル４２は、端末１に対するユーザの距離の履歴データを格納するテーブルである。移動履歴テーブル４２は、ユーザ位置特定部４５及びオペレータ判定部４６により更新される。

図３は、移動履歴テーブル４２の一例を示す図である。図３の例では、移動履歴テーブルの各レコードには、レコード番号（Ｎｏ）、端末ＩＤ、ユーザＩＤ、距離、登録時刻、通知時刻、及び通知内容が含まれる。端末ＩＤとは、端末１を特定する識別子である。登録時刻とは、ユーザ位置特定部４５によりレコードが追加された時刻のことである。登録時刻は、端末１に対するユーザの距離が特定された時刻に相当する。通知時刻及び通知内容については後述する。

例えば、図３のレコード１は、「端末ＩＤが放射線科−１の端末１に対するユーザＩＤがＴＯＳＨＩＢＡ−１のユーザの距離がＦＡＲである」ことが２０１５／２／２の８：００に特定されたことを示している。

なお、移動履歴テーブル４２は、端末１の起動時に初期化（レコードを削除）されてもよいし、初期化ツールにより任意のタイミングで初期化されてもよいし、初期化されなくてもよい。

また、距離は、ＦＡＲ、ＮＥＡＲ、及びＩＭＭＥＤＩＡＴＥの３値でなくてもよい。例えば、距離は、端末１から所定範囲内にユーザがいる又はいない、の２値により表されてもよいし、数値で表されてもよい。

ユーザ情報テーブル４３は、各ユーザに関する情報（ユーザ情報）を格納するテーブルである。ユーザ情報は、例えば、ユーザＩＤ、ユーザの所属、資格、連絡先、及び許可アプリＩＤであるが、これに限られない。許可アプリＩＤとは、ユーザが利用を許可されたアプリケーションを特定する識別子のことである。ユーザ情報テーブル４３は、端末システムや医療システムの管理者により更新される。

図４は、ユーザ情報テーブル４３の一例を示す図である。図４の例では、ユーザ情報テーブルの各レコードに、レコード番号（Ｎｏ）、ユーザＩＤ、所属、資格、連絡先（内線）、及び許可アプリＩＤが含まれる。

例えば、図４のレコード１は、ユーザＩＤがＴＯＳＨＩＢＡ−１のユーザは、放射線科に所属し、放射線技師の資格を有し、内線番号が１１１１であり、許可アプリＩＤがＡＰＰ−０１のアプリケーションの利用権限を有することを示している。

アプリケーションテーブル４４は、端末１上で動作可能なアプリケーションに関する情報（アプリケーション情報）を格納するテーブルである。アプリケーション情報は、例えば、アプリ名称、ウインドウ表示名称、及び実行モジュール名であるが、これに限られない。アプリ名称とは、アプリケーションの名称のことである。ウインドウ表示名称は、アプリケーションを実行する際に、端末１のディスプレイ上に表示される名称のことである。アプリケーションテーブル４４は、端末システムや医療システムの管理者により更新される。

図５は、アプリケーションテーブルの一例を示す図である。図５の例では、アプリケーションテーブルの各レコードに、レコード番号（Ｎｏ）、アプリＩＤ、アプリ名称、ウインドウ表示名称、及び実行モジュール名が含まれる。アプリＩＤとは、アプリケーションを特定するための識別子である。

例えば、図５のレコード１は、アプリＩＤがＡＰＰ−０１のアプリケーションは、「放射線情報管理業務」という名称であり、ウインドウ表示名称が「放射線情報管理アプリケーション」であり、実行モジュール名が「ａｐｐ０１_ｅｘｅ」であることを示している。

なお、以上説明した各テーブルは、データベース管理システム（ＤＢＭＳ）により実現されてもよいし、ＩＮＩ形式やＸＭＬ形式などの設定ファイルにより実現されてもよい。

ユーザ位置特定部４５は、無線信号を受信した無線受信機３から入力された情報（無線受信機３が受信した無線信号の信号強度など）に基づいて、端末１に対する所定の領域内にいるユーザ及びそのユーザから端末１までの距離を特定する。すなわち、ユーザ位置特定部４５は、端末１に対して、どのユーザが、どのような距離にいるかを特定する。

無線受信機３から送信機ＩＤ及び距離が入力された場合、無線受信機３に対する無線送信機２の距離は特定されている。これは、端末１に対する無線送信機２の距離が特定されていることに相当する。しかしながら、この時点では、無線送信機２を携帯するユーザが特定されていない。

そこで、ユーザ位置特定部４５は、無線受信機３から入力された送信機ＩＤに基づいて、無線送信機２を携帯しているユーザを特定する。具体的には、ユーザ位置特定部４５は、送信機ＩＤを検索条件としてユーザＩＤテーブル４１を検索し、送信機ＩＤに対応するユーザＩＤを特定する。これにより、無線送信機２を携帯しているユーザが特定される。

なお、端末１に対する距離は、ユーザ位置特定部４５が特定してもよい。例えば、無線受信部３が無線信号をユーザ位置特定部４５に入力し、入力された無線信号に基づいて、ユーザ位置特定部４５が距離を特定することが考えられる。ユーザ位置特定部４５は、無線信号の信号強度などに基づいて距離を特定すればよい。

また、無線受信機３が無線送信機２との間の通信状態をユーザ位置特定部４５に入力し、入力された通信状態に基づいて、ユーザ位置特定部４５が距離を特定することも考えられる。この場合、ユーザ位置特定部４５は、距離を、ユーザがいる又はいない、の２値で特定すればよい。ユーザ位置特定部４５は、通信状態が有効（すなわち、通信中）の場合にユーザがいると特定し、通信状態が無効（すなわち、通信していない）の場合にユーザがいないと特定すればよい。この特定方法は、無線送信機２として非接触タグを用いる場合のように、無線信号の信号強度から距離を特定できない場合にも適用可能である。

端末１に対するユーザの距離を特定したユーザ位置特定部４５は、移動履歴テーブル４２に新たなレコードを追加する。追加されたレコードの端末ＩＤ、ユーザＩＤ、距離、登録時刻、通知時刻、及び通知内容には、端末１の端末ＩＤ、ユーザＩＤテーブル４１を検索して特定されたユーザＩＤ、無線受信機３から入力された（又はユーザ位置特定部４５が識別した）距離、現在時刻、ＮＵＬＬ、及びＮＵＬＬが、それぞれ登録される。端末１の端末ＩＤは、設定情報として記憶されていてもよいし、無線受信機３から入力されてもよい。

ユーザ位置特定部４５は、上述の特定処理及びレコードの追加処理を、無線受信機３から情報を入力されるたびに実行してもよい。例えば、無線受信機３が１秒ごとに無線信号を受信してユーザ位置特定部４５に情報を入力する場合、ユーザ位置特定部４５は、１秒ごとに上記の処理を行なえばよい。この場合、１秒ごとに移動履歴テーブル４２のレコードが追加される。

また、ユーザ位置特定部４５は、無線受信機３から情報を入力されるたびに特定処理を実行し、所定の条件を満たす場合にのみレコードを追加してもよい。所定の条件として、例えば、特定されたユーザＩＤを含む最新のレコードの登録時刻から、現在時刻まで、の経過時間が所定時間以上であること、などが考えられる。最新のレコードの登録時刻は、特定されたユーザＩＤを検索条件として移動履歴テーブル４２を検索することにより取得できる。これにより、移動履歴テーブル４２に追加されるレコードの数を抑制することができる。

さらに、ユーザ位置特定部４５は、特定処理の結果特定されたユーザＩＤ及び距離と、最新のレコードに含まれるユーザＩＤ及び距離と、が一致する場合、最新のレコードの登録時刻だけ更新してもよい。これにより、移動履歴テーブル４２に追加されるレコードの数を抑制することができる。

オペレータ判定部４６は、ユーザ位置特定部４５が特定した端末１に対するユーザの距離の履歴データに基づいて、ユーザ位置特定部４５が特定したユーザがオペレータであるか判定し、端末１のオペレータを特定する。オペレータ判定部４６は、オペレータの変更を検知すると、検知したオペレータの変更を、アプリケーション制御部４７に通知する。

アプリケーション制御部４７は、オペレータ判定部４６から通知されたメッセージに応じて、端末１上で動作するアプリケーションを制御する。アプリケーション制御部４７によるアプリケーションの制御について、詳しくは後述する。

以下、オペレータ判定部４６によるオペレータの特定及び変更の通知について、それぞれ説明する。まず、オペレータの特定について説明する。

オペレータ判定部４６は、あるユーザが端末１に対する所定範囲Ｒ内にいる時間が所定時間Ｔ以上になると、そのユーザを新たなオペレータとして特定する。所定時間Ｔ及び所定範囲Ｒは任意に設定可能である。所定時間Ｔは、例えば、無線受信機３が無線信号を受信する時間間隔や無線送信機２が無線信号を送信する時間間隔の、整数倍の時間に設定される。この場合、所定時間Ｔは、ユーザの位置が、所定範囲Ｒ内であると特定された回数に対応する。また、所定範囲Ｒは、端末１からの距離として設定されてもよいし、無線受信機３が受信する無線信号の信号強度の範囲として設定されてもよい。

そして、オペレータ判定部４６は、新たなオペレータとして特定されたユーザが所定範囲Ｒ内からいなくなるまで（ユーザの位置が所定範囲Ｒ内であると特定されなくなるまで）、そのユーザをオペレータとして特定する。すなわち、オペレータ判定部４６は、所定時間Ｔ以上断続的に、端末１に対する所定範囲Ｒ内にいるユーザを、オペレータとして特定する。オペレータ判定部４６は、オペレータとして特定されていたユーザの位置が、オペレータを判定するタイミングに、所定範囲Ｒ内でなかった場合、そのユーザを、オペレータから除外する。

上述のオペレータの変更には、オペレータの登場及び退場が含まれる。オペレータの登場は、新たなオペレータの特定に相当する。オペレータの退場は、オペレータからの除外に相当する。

ここで、図６は、端末１に対するユーザの状態（距離）の遷移を示す状態遷移図である。図６の各ノードは端末１に対するユーザの距離を示し、各矢印は状態遷移を示す。図６におけるＩＮＩＴは、ユーザが検知されていない、すなわち、ユーザの携帯する無線送信機２の無線信号が、無線受信機３に受信されていない状態を示す。

状態遷移１〜５は、ユーザが端末１に接近する状態遷移である。状態遷移６〜１０は、ユーザが端末１から離間する状態遷移である。状態遷移１１〜１４は、ユーザが端末１に対して所定の距離を保ったままでいる状態遷移である。例えば、状態遷移３は、ユーザの距離が、「ＮＥＡＲ」から「ＩＭＭＥＤＩＡＴＥ」に遷移することを示している。

なお、状態遷移４，５，９，１０は、ユーザと端末１との物理的な位置関係により、無線信号から特定される距離が急激に変化する場合を想定した状態遷移である。例えば、端末１が検査室の入口に設置されており、ユーザが、廊下から検査室に入室した場合、ユーザの状態が、状態遷移４，５のように遷移することが想定される。また、図示省略されているが、端末１が検査室の入口から離れた位置（入口から５０ｃｍ以上６ｍ以内の位置）に設置されている場合には、ユーザの距離が「ＩＮＩＴ」から「ＮＥＡＲ」に遷移する場合や、「ＮＥＡＲ」から「ＩＮＩＴ」に遷移する場合も想定できる。

ここで、所定範囲Ｒが、端末１からの距離が「ＩＭＭＥＤＩＡＴＥ」の範囲である場合、を例に、オペレータの特定について説明する。図７は、オペレータの登場及び退場の検知タイミングの一例を示す図である。図７の状態遷移は、図６に対応している。図７において、○はオペレータの登場の検知タイミングであり、×はオペレータの退場の検知タイミングである。

図７の例では、ユーザの距離が「ＮＥＡＲ」から「ＩＭＭＥＤＩＡＴＥ」に遷移（状態遷移３）した後、同一状態の遷移（状態遷移１１）が１回繰り返されると、オペレータの登場（ＥＮＴＥＲ−ＲＥＧＩＯＮ）が検知される。すなわち、あるユーザの距離が、「ＮＥＡＲ」、「ＩＭＭＥＤＩＡＴＥ」、「ＩＭＭＥＤＩＡＴＥ」の順に特定された場合、そのユーザが新たなオペレータとして特定される。状態遷移４，５についても同様である。これは、所定時間Ｔが、ユーザ位置特定部４５による特定処理の１回分の時間に相当する。例えば、ユーザ位置特定部４５による特定処理が１分間隔で実行される場合、所定時間Ｔは１分となる。

このように、オペレータ判定部４６は、所定範囲Ｒ内にユーザがいる場合であっても、所定時間Ｔが経過するまで、そのユーザをオペレータとして特定しない。これにより、端末１に一時的に近づいただけのユーザが、オペレータとして誤って特定されることを防ぐことができる。なお、図７の例では、オペレータの登場を検知するための同一状態の遷移回数は、１回であるが、２回以上であってもよい。

また、図７の例では、オペレータとして特定されたユーザの距離が「ＩＭＭＥＤＩＡＴＥ」から「ＮＥＡＲ」に遷移すると（状態遷移６）、オペレータの退場（ＥＸＩＴ−ＲＥＧＩＯＮ）が検知される。すなわち、そのユーザがオペレータから除外される。状態遷移９，１０についても同様である。

なお、図６における「ＩＮＩＴ」は、実際には検知されない距離である。すなわち、無線受信機３から、ある無線送信機２の距離がＩＮＩＴである、という情報が入力されることはない。「ＩＮＩＴ」は、ユーザ位置特定部４５が移動履歴テーブル４２を参照することにより特定される。ユーザ位置特定部４５は、所定時間以上検知されていないユーザの距離をＩＮＩＴに特定する。

具体的には、ユーザ位置特定部４５は、特定処理の度に、移動履歴テーブル４２に含まれるユーザＩＤを取得し、各ユーザＩＤが含まれる最新のレコードの登録時刻を取得する。ユーザ位置特定部４５は、取得した登録時刻から現在時刻までの経過時間が所定値以上のユーザＩＤを発見した場合、発見したユーザＩＤを含む新たなレコードを移動履歴テーブル４２に追加する。追加されるレコードの距離はＩＮＩＴ、登録時刻は現在時刻、通知時刻及び通知内容はＮＵＬＬである。

次に、オペレータの変更の通知について説明する。オペレータ判定部４６は、オペレータの変更（登場及び退場）を検知すると、アプリケーション制御部４７に、オペレータの変更を通知する。

より詳細には、オペレータ判定部４６は、オペレータの登場を検知すると、新たなオペレータとして特定されたユーザのユーザＩＤ、及びそのユーザが新たなオペレータとして特定されたことを、アプリケーション制御部４７に通知する。

また、オペレータ判定部４６は、オペレータの退場を検知すると、オペレータから除外されたユーザのユーザＩＤ、及びそのユーザがオペレータから除外されたことを、アプリケーション制御部４７に通知する。

オペレータ判定部４６は、変更を検知するたびに通知処理を実行してもよい。また、オペレータ判定部４６は、変更を検知し、かつ、所定の通知条件が満たされた場合に通知処理を実行してもよい。

ここで、通知条件の２つの具体例について説明する。

第１の通知条件は、変更を検知されたユーザが、端末１上で動作可能なアプリケーションの利用権限を有することである。第１の通知条件を利用する場合、オペレータ判定部４６は、検知されたユーザが、端末１上で動作可能なアプリケーションの利用権限を有する場合のみ通知処理を実行する。

これは、ユーザがアプリケーションの利用権限を有さない場合、通知の有無に関わらず、そのユーザはアプリケーションを利用できず、アプリケーション制御部４７による制御内容が変わらないためである。

具体的には、オペレータ判定部４６は、オペレータの登場（又は退場）を検知すると、検知された（オペレータとして特定された、又はオペレータから除外された）ユーザのユーザＩＤを検索条件としてユーザ情報テーブル４３を検索し、そのユーザの許可アプリＩＤを取得する。取得した許可アプリＩＤに、端末１上で動作可能なアプリケーションのアプリケーションＩＤが含まれている場合、オペレータ判定部４６は通知処理を実行する。一方、ユーザの許可アプリＩＤに、端末１上で動作可能なアプリケーションのアプリケーションＩＤが含まれていない場合、オペレータ判定部４６は通知処理を実行しない。

第２の通知条件は、変更を検知されたユーザが利用権限を有するアプリケーションが、端末１上で動作していることである。第２の通知条件は、第１の通知条件と併用される。第２の通知条件を利用する場合、オペレータ判定部４６は、検知されたユーザが利用権限を有するアプリケーションが、端末１上で動作している場合のみ通知処理を実行する。

これは、ユーザがアプリケーションの利用権限を有していても、そのアプリケーションが端末１上で動作していない場合、アプリケーション制御部４７による制御内容が変わらないためである。

具体的には、オペレータ判定部４６は、まず、第１の通知条件が満たされるか判定する。第１の条件が満たされない場合、オペレータ判定部４６は、通知処理を実行しない。

一方、第１の条件が満たされた場合、オペレータ判定部４６は、ユーザの許可アプリＩＤを検索条件としてアプリケーションテーブル４４を検索し、ユーザが利用権限を有するアプリケーションのウインドウ表示名称などを取得する。オペレータ判定部４６は、取得したウインドウ表示名などを利用して、ユーザが利用権限を有するアプリケーションが端末１上で動作しているか確認し、動作していた場合、通知処理を実行し、動作していない場合、通知処理を実行しない。

アプリケーションが端末１上で動作しているかの確認は、既存の任意の方法を利用して行なえばよい。例えば、端末１のＯＳ（オペレーティングシステム）がＷｉｎｇｄｏｗｓ（登録商標）の場合、オペレータ判定部４６は、ＥｎｕｍＷｉｎｄｏｗｓ関数を呼び出し、トップレベルウインドウごとに指定したコールバック関数を呼び出し、コールバック関数に含まれるウインドウハンドルを取得し、取得したウインドウハンドルを指定したＧｅｔＷｉｎｄｏｗＴｅｘｔ関数を呼び出し、ウインドウのタイトルを取得する。オペレータ判定部４６は、こうして取得したタイトルと、ウインドウ表示名と、を比較することにより、アプリケーションが端末１上で動作しているか確認することができる。

オペレータ判定部４６は、上記のような通知条件を利用することにより、アプリケーション制御部４７への余計な通知を抑制することができる。なお、オペレータ判定部４６は、通知条件として、第１の通知条件だけを利用してもよいし、第１の通知条件及び第２の通知条件を併用してもよい。また、通知条件は、上記のものに限られず、任意に設定可能である。

オペレータ判定部４６は、アプリケーション制御部４７に変更を通知すると、移動履歴テーブル４２を更新する。具体的には、オペレータ判定部４６は、オペレータの変更が検知された移動履歴テーブル４２のレコードの通知時刻に現在時刻（アプリケーション制御部４７に変更を通知した時刻）を登録し、通知内容に検知した変更の内容（オペレータの登場又は退場）を登録する。

例えば、図３の移動履歴テーブルのレコード４は、通知時刻が２０１５／２／２ ８：０７であり、通知内容がＥＮＴＥＲ−ＲＥＧＩＯＮである。これは、オペレータ判定部４６が、２０１５／２／２の８：０７に、オペレータ（ユーザＩＤがＴＯＳＨＩＢＡ−１のユーザ）の登場を検知し、アプリケーション制御部４７に通知したことを示している。

また、図３の移動履歴テーブルのレコード５は、通知時刻が２０１５／２／２ ９：５５であり、通知内容がＥＸＩＴ−ＲＥＧＩＯＮである。これは、オペレータ判定部４６が、２０１５／２／２の９：５５に、オペレータ（ユーザＩＤがＴＯＳＨＩＢＡ−２のユーザ）の退場を検知し、アプリケーション制御部４７に通知したことを示している。

オペレータ判定部４６は、端末１が起動すると自動的に処理を開始し、予め設定された時間間隔で、上述の処理を実行する。以下、オペレータ判定部４６による処理について、図８を参照して具体的に説明する。図８は、オペレータ判定部４６による処理の一例を示すフローチャートである。

まず、オペレータ判定部４６は、現在時刻から日付情報を抽出し、抽出した日付及び端末ＩＤを検索条件として、移動履歴テーブル４２を検索し、検索条件を満たすレコードに含まれる全てのユーザＩＤを取得する（ステップＳ１）。

次に、オペレータ判定部４６は、取得したユーザＩＤの中から１つ選択し、選択したユーザＩＤに対して、ステップＳ２以降の処理を実行する。オペレータ判定部４６は、取得した全てのユーザＩＤについて、同様にステップＳ２以降の処理を実行する。以下では、選択されたユーザＩＤはＴＯＳＨＩＢＡであるものとする。

オペレータ判定部４６は、移動履歴テーブル４２を検索して、レコード数Ａを取得する（ステップＳ２）。検索条件は、ユーザＩＤ＝ＴＯＳＨＩＢＡ、通知内容＝ＥＮＴＥＲ−ＲＥＧＩＯＮである。すなわち、レコード数Ａは、現在時刻までに、ユーザＩＤ＝ＴＯＳＨＩＢＡのユーザが、新たに登場したオペレータとして検知された回数（新たなオペレータとして特定された回数）に相当する。

また、オペレータ判定部４６は、移動履歴テーブル４２を検索して、レコード数Ｂを取得する（ステップＳ３）。検索条件は、ユーザＩＤ＝ＴＯＳＨＩＢＡ、通知内容＝ＥＮＴＥＲ−ＲＥＧＩＯＮである。すなわち、レコード数Ｂは、現在時刻までに、ユーザＩＤ＝ＴＯＳＨＩＢＡのユーザが、退場したオペレータとして検知された回数（オペレータから除外された回数）に相当する。なお、ステップＳ２，Ｓ３は、順番が逆でもよい。

続いて、オペレータ判定部４６は、取得したレコード数Ａ，Ｂを比較する（ステップＳ４）。Ａ＜Ｂの場合は、オペレータの特定や変更の検知が適切に行われていない場合に相当する。したがって、Ａ＜Ｂの場合、オペレータ判定部４６は、エラーログを出力し、ユーザＩＤ＝ＴＯＳＨＩＢＡに関する処理を終了する（ステップＳ５）。

ステップＳ４において、Ａ＝Ｂの場合は、現在時刻において、ユーザＩＤ＝ＴＯＳＨＩＢＡのユーザが、オペレータとして特定されていない場合に相当する。この場合、オペレータ判定部４６は、移動履歴テーブル４２を検索して、ユーザＩＤ＝ＴＯＳＨＩＢＡのユーザが新たなオペレータとして登場したか判定する。

Ａ＝０の場合（ステップＳ６のＹＥＳ）、オペレータ判定部４６は、検索の開始時刻を設定しない（ステップＳ７）。開始時刻とは、上記の判定のために、移動履歴テーブル４２を検索する登録時刻の始点である。Ａ＝０の場合は、端末１の使用を開始した直後に相当する。

一方、Ａ≠０の場合（ステップＳ６のＮＯ）、オペレータ判定部４６は、検索の開始時刻を、ユーザＩＤ＝ＴＯＳＨＩＢＡ、通知内容＝ＥＸＩＴ−ＲＥＧＩＯＮ、となっている最新のレコードの通知時刻に設定する（ステップＳ８）。これは、ユーザＩＤ＝ＴＯＳＨＩＢＡのユーザが新たなオペレータとして登場し得るのは、上記の通知時刻以降だからである。

次に、オペレータ判定部４６は、移動履歴テーブル４２を検索して、検索条件に該当するレコードが２個以上連続しているか判定する（ステップＳ９）。検索条件は、ユーザＩＤ＝ＴＯＳＨＩＢＡ、距離＝ＩＭＭＥＤＩＡＴＥ、登録時刻＞開始時刻である。開始時刻が設定されていない場合の検索条件は、ユーザＩＤ＝ＴＯＳＨＩＢＡ、距離＝ＩＭＭＥＤＩＡＴＥである。

この検索条件に該当するレコードが２つ以上連続していない場合（ステップＳ９のＮＯ）、オペレータ判定部４６は、ユーザＩＤ＝ＴＯＳＨＩＢＡのユーザは端末１にいないと判定し、ユーザＩＤ＝ＴＯＳＨＩＢＡに関する処理を終了する。

一方、この検索条件に該当するレコードが２つ以上連続している場合（ステップＳ９のＹＥＳ）、オペレータ判定部４６は、ユーザＩＤ＝ＴＯＳＨＩＢＡのユーザをオペレータとして特定する（ステップＳ１０）。これは、検索条件に該当するレコードが２つ以上連続している場合とは、ユーザＩＤ＝ＴＯＳＨＩＢＡのユーザの距離が、「ＩＭＭＥＤＩＡＴＥ以外」から「ＩＭＭＥＤＩＡＴＥ」に遷移した後、再び「ＩＭＭＥＤＩＡＴＥ」に遷移した場合に相当するためである。

オペレータ判定部４６は、オペレータを特定すると、上述の通り、アプリケーション制御部４７に通知する。また、オペレータ判定部４６は、２つ以上連続したレコードのうち、２番目に登録時刻が古いレコードを更新する。具体的には、通知内容をＥＮＴＥＲ−ＲＥＧＩＯＮに更新し、通知時刻を現在時刻に更新する。その後、オペレータ判定部４６は、ユーザＩＤ＝ＴＯＳＨＩＢＡに関する処理を終了する。

ステップＳ４において、Ａ＞Ｂの場合は、現在時刻において、ユーザＩＤ＝ＴＯＳＨＩＢＡのユーザが、オペレータとして特定されている場合に相当する。この場合、オペレータ判定部４６は、移動履歴テーブル４２を検索して、ユーザＩＤ＝ＴＯＳＨＩＢＡのユーザをオペレータから除外するか判定する。

上記の判定のために、まず、オペレータ判定部４６は、検索の開始時刻を、ユーザＩＤ＝ＴＯＳＨＩＢＡ、通知内容＝ＥＮＴＥＲ−ＲＥＧＩＯＮ、となっている最新のレコードの通知時刻に設定する（ステップＳ１１）。

次に、オペレータ判定部４６は、移動履歴テーブル４２を検索して、検索条件に該当するレコードがあるか判定する（ステップＳ１２）。検索条件は、ユーザＩＤ＝ＴＯＳＨＩＢＡ、距離≠ＩＭＭＥＤＩＡＴＥ、登録時刻＞開始時刻である。

この検索条件に該当するレコードがない場合（ステップＳ１２のＮＯ）、オペレータ判定部４６は、ユーザＩＤ＝ＴＯＳＨＩＢＡのユーザはまだ端末１にいると判定し、ユーザＩＤ＝ＴＯＳＨＩＢＡに関する処理を終了する。

一方、この検索条件に該当するレコードがある場合（ステップＳ１２のＹＥＳ）、オペレータ判定部４６は、ユーザＩＤ＝ＴＯＳＨＩＢＡのユーザをオペレータから除外する（ステップＳ１３）。これは、検索条件に該当するレコードがある場合とは、ユーザＩＤ＝ＴＯＳＨＩＢＡのユーザの距離が、「ＩＭＭＥＤＩＡＴＥ」から「ＩＭＭＥＤＩＡＴＥ以外」に遷移した場合に相当するためである。

オペレータ判定部４６は、オペレータを除外すると、上述の通り、アプリケーション制御部４７に通知する。また、オペレータ判定部４６は、検索条件に該当した最も古いレコードを更新する。具体的には、通知内容をＥＸＩＴ−ＲＥＧＩＯＮに更新し、通知時刻を現在時刻に更新する。その後、オペレータ判定部４６は、ユーザＩＤ＝ＴＯＳＨＩＢＡに関する処理を終了する。

例えば、オペレータ判定部４６が、図３の移動履歴テーブル４２を参照して、２０１５／２／２の８：０７に処理を実行した場合、まず、ユーザＩＤとしてＴＯＳＨＩＢＡ−１が取得される（ステップＳ１）。レコード数Ａは０となり（ステップＳ２）、レコード数Ｂも０（ステップＳ３）となる。したがって、処理はステップＳ４のＡ＝Ｂに進み、ステップＳ６のＹＥＳに進み、開始時刻は設定されない（ステップＳ７）。図３の移動履歴テーブル４２では、レコード３，４（ユーザＩＤ＝ＴＯＳＨＩＢＡ−１、距離＝ＩＭＭＥＤＩＡＴＥ）が連続しているため（ステップＳ９のＹＥＳ）、オペレータ判定部４６は、ユーザＩＤ＝ＴＯＳＨＩＢＡ−１のユーザをオペレータとして特定し（ステップＳ１０）、アプリケーション制御部４７に通知する。そして、オペレータ判定部４６は、検索条件に該当する２番目に古いレコード４の通知時刻を現在時刻（２０１５／２／２ ８：０７）に更新し、通知内容をＥＮＴＥＲ−ＲＥＧＩＯＮに更新する。ステップＳ１において、ユーザＩＤはＴＯＳＨＩＢＡ−１しか取得されていないため、８：０７におけるオペレータ判定部４６の処理は終了する。

一方、オペレータ判定部４６が、図３の移動履歴テーブル４２を参照して、２０１５／２／２の９：５５に処理を実行した場合、まず、ユーザＩＤとしてＴＯＳＨＩＢＡ−１が取得される（ステップＳ１）。レコード４がステップＳ２の検索条件に該当するため、レコード数Ａは１となり（ステップＳ２）、レコード数Ｂは０（ステップＳ３）となる。したがって、処理はステップＳ４のＡ＞Ｂに進み、開始時刻が、レコード４の登録時刻（２０１５／２／２ ８：０７）に設定される（ステップＳ１１）。オペレータ判定部４６が開始時刻（８：０７）から現在時刻（９：５５）までのレコードを検索すると、ユーザＩＤ＝ＴＯＳＨＩＢＡ−１かつ距離＝ＮＥＡＲ（≠ＩＭＭＥＤＩＡＴＥ）のレコードとして、レコード５が発見される（ステップＳ１２のＹＥＳ）。したがって、オペレータ判定部４６は、ユーザＩＤ＝ＴＯＳＨＩＢＡ−１のユーザをオペレータから除外し（ステップＳ１３）、アプリケーション制御部４７に通知する。そして、オペレータ判定部４６は、検索条件に該当する最も古いレコード５の通知時刻を現在時刻（２０１５／２／２ ９：５５）に更新し、通知内容をＥＸＩＴ−ＲＥＧＩＯＮに更新する。ステップＳ１において、ユーザＩＤはＴＯＳＨＩＢＡ−１しか取得されていないため、９：５５におけるオペレータ判定部４６の処理は終了する。

図９は、図８の処理により更新された移動履歴テーブル４２をグラフ化した図である。図９の例では、ユーザＩＤは、ＴＯＳＨＩＢＡ−１，ＴＯＳＨＩＢＡ−２，ＴＯＳＨＩＢＡ−３の３つであり、各ユーザの端末１に対する距離は、ＦＡＲ、ＮＥＡＲ、及びＩＭＭＥＤＩＡＴＥの３値で示されている。

図９に示すように、オペレータ判定部４６は、各ユーザの距離が２回目にＩＭＭＥＤＩＡＴＥになったタイミングでオペレータの登場を通知し（ＥＮＴＥＲ通知）、各ユーザの距離がＩＭＭＥＤＩＡＴＥからＩＭＭＥＤＩＡＴＥ以外に遷移したタイミングでオペレータの退場を通知している（ＥＸＩＴ通知）。例えば、図９の例では、ユーザＩＤがＴＯＳＨＩＢＡ−１のユーザは、８：０７にオペレータとして特定され、９：５５にオペレータから除外されている。すなわち、ユーザＩＤがＴＯＳＨＩＢＡ−１のユーザは、８：０７から９：５５までオペレータとして特定されている。

以上説明した図８の処理では、オペレータとして複数のユーザが特定されることが許容されていた。このため、例えば、図９の例では、ユーザＩＤがＴＯＳＨＩＢＡ−２及びＴＯＳＨＩＢＡ−３のユーザが、同一の時間帯にそれぞれオペレータとして特定されている。

しかしながら、端末１がＰＣである場合のように、端末１のオペレータが複数であるとは考えにくい場合も想定される。そこで、以下では、オペレータ判定部４６が、オペレータとして１人のユーザしか特定しない場合の処理について説明する。

オペレータ４６は、あるユーザＸをオペレートして特定するか判定するために、そのユーザＸが図７で説明した条件を満たすか判定すると共に、そのユーザＸより先にオペレータとして特定された他のユーザがいるか判定すればよい。オペレータ４６は、ユーザＸが図７で説明した条件を満たし、かつ、他のユーザがオペレータとして特定されていない場合、ユーザＸをオペレータとして特定する。

図１０は、オペレータ判定部４６による処理の他の例を示すフローチャートである。図１０の例では、オペレータ判定部４６は、オペレータとして、一人のユーザだけを特定する。図１０のステップＳ１〜Ｓ１３は、図８と同様である。

図１０の例では、検索条件に該当するレコードが２つ以上連続している場合（ステップＳ９のＹＥＳ）、処理はステップＳ１４に進む。ステップＳ１４において、オペレータ判定部４６は、他のユーザがオペレータとして特定済みか判定する。他のユーザがオペレータとして特定されていた場合（ステップＳ１４のＹＥＳ）、オペレータ判定部４６は、処理を終了する。一方、オペレータ判定部４６は、他のユーザがオペレータとして特定されていない場合（ステップＳ１４のＮＯ）、判定中のユーザ（ユーザＩＤがＴＯＳＨＩＢＡのユーザ）をオペレータとして特定する（ステップＳ１０）。

他のユーザがオペレータとして特定されているか判定するために、オペレータ判定部４６は、移動履歴テーブル４２を検索して、レコード数Ｃ及びレコード数Ｄを取得する。

レコード数Ｃの検索条件は、ユーザＩＤ≠ＴＯＳＨＩＢＡ、通知内容＝ＥＮＴＥＲ−ＲＥＧＩＯＮである。レコード数Ｃは、現在時刻までに、他のユーザが新たに登場したオペレータとして検知された回数の合計に相当する。

レコード数Ｄの検索条件は、ユーザＩＤ≠ＴＯＳＨＩＢＡ、通知内容＝ＥＸＩＴ−ＲＥＧＩＯＮである。レコード数Ｄは、現在時刻までに、他のユーザが退場したオペレータとして検知された回数の合計に相当する。

オペレータ判定部４６は、レコード数Ｃ及びレコード数Ｄを比較する。Ｃ＝Ｄの場合、オペレータ判定部４６は、他のユーザがオペレータとして特定されていないと判定する（ステップＳ１４のＮＯ）。Ｃ＞Ｄの場合、オペレータ判定部４６は、他のユーザがオペレータとして特定されていると判定する（ステップＳ１４のＹＥＳ）。Ｃ＜Ｄの場合、オペレータ判定部４６は、エラーログを出力して処理を終了する。

図１１は、図１０の処理により更新された移動履歴テーブル４２をグラフ化した図である。図１１の例では、図９とは異なり、ユーザＩＤがＴＯＳＨＩＢＡ−３のユーザは、オペレータとして特定されず、通知もされていない。これは、ユーザＩＤがＴＯＳＨＩＢＡ−３のユーザより、ユーザＩＤがＴＯＳＨＩＢＡ−２のユーザが先にオペレータとして特定されているためである。オペレータをこのように特定及び通知することにより、図１１に示すように、同時に一人のユーザだけをオペレータとして特定することができる。

次に、アプリケーション制御部４７によるアプリケーションの制御方法について、具体的に説明する。以下では、アプリケーションが、放射線情報管理アプリケーション、読影レポート作成アプリケーション、３Ｄ画像処理アプリケーションである場合を例に説明する。

まず、アプリケーションが放射線管理アプリケーションである場合について説明する。

放射線情報管理アプリケーションは、画像検査を行う際に、撮影する患者を選択し、前回の撮影条件を確認したり、ＨＩＳ（病院情報システム）から送信された画像検査オーダの内容を確認したり、撮影後に検査に使用した医薬品（造影剤）や医療材料（フィルムやカテーテルなど）を入力し、ＨＩＳに送信したりするアプリケーションである。

画像検査は、独立した検査室で行われることが多く、画像検査を行う際、患者を介助したり、撮影位置を調整したり、撮影操作を行ったりするなど、複数のユーザ（職員）が連携しながら行うことが多い。このため、同じユーザが毎回同じ作業を行うとは限らない。また、異なるユーザが作業を行う度に、毎回ログイン及びログアウトを行うことも現実的ではない。

そこで、アプリケーション制御部４７は、オペレータ判定部４６からＥＮＴＥＲ−ＲＥＧＩＯＮのメッセージを通知されると、新たなオペレータとして特定されたユーザＩＤと、その時点で放射線管理アプリケーションが認識しているユーザＩＤとを比較する。ユーザＩＤが異なっている場合、アプリケーション制御部４７は、放射線管理アプリケーションが認識しているユーザＩＤを、自動的にメッセージ中のユーザＩＤに置き換え、端末１の表示部１１に表示する。この状態で、オペレータが登録ボタンなどの操作を行うと、その時点でオペレータとして特定されたユーザが、撮影者として登録される。

一方、アプリケーション制御部４７は、オペレータ判定部４６からＥＸＩＴ−ＲＥＧＩＯＮのメッセージを通知されると、放射線管理アプリケーションが認識しているユーザＩＤをＮＵＬＬに置換え、誰もログインしていない状態に戻す。

この端末管理装置４により、画像検査装置のコンソールを管理することにより、実際に撮影ボタンを押下したオペレータを、動的にかつ簡便に切替えられるようになる。

また、オペレータ判定部４６は、ユーザの資格を確認してオペレータの変更を通知することができるため、資格の適合性に従ったオペレータの切替えが可能になる。例えば、画像検査を行うことが認められているのは、放射線検査技師または医師である。したがって、看護師の資格を持つユーザは、オペレータとして特定されない。これにより、誤って看護師の資格を持つユーザが画像検査を行った、というような記録が作成されることが未然防止できる。

なお、アプリケーション制御部４７が自動的にオペレータを切替える場合には、不適切なオペレータが選ばれる可能性が残っているため、放射線情報管理アプリケーションは、オペレータが切替えられた際に警告を行うことも有効である。警告の方法として、例えば、ブザーなどの音を鳴らす、オペレータを表示している部分の背景色を動的に切り替える、オペレータを表示している文字の色を変える、などの方法が考えられる。

アプリケーション制御部４７が、このように放射線管理アプリケーションを制御することにより、撮影の度にオペレータの変更の操作（ログインやログアウト）を行う煩わしさをなくし、ユーザの負担を軽減するとともに、実際に誰が撮影（実施登録）を行ったかを、より適切に記録することが可能となる。

また、画像検査を行ったオペレータを複数登録することも可能である。この場合、アプリケーション制御部４７は、オペレータ判定部４６からＥＮＴＥＲ−ＲＥＧＩＯＮのメッセージを通知されると、新たなオペレータとして特定されたユーザＩＤと、その時点で放射線管理アプリケーションが認識しているユーザＩＤとを比較する。ユーザＩＤが異なっている場合、アプリケーション制御部４７は、通知されたユーザＩＤを、オペレータのユーザＩＤに追加すればよい。これにより、より実態に近い撮影者を記録して登録できるようになる。

次に、アプリケーションが読影レポート作成アプリケーションである場合について説明する。

読影レポート作成アプリケーションは、ユーザが、画像検査で撮影された画像を観察し、必要に応じてカルテ情報やその他の検査結果などの情報を参照しながら画像診断を行い、診断結果を読影レポートに入力する作業を、支援するためのアプリケーションである。

読影作業は、医師単独で行う場合もあるが、複数の医師が共同で行う場合もある。このような場合に備えて、読影レポート作成アプリケーションでは、一般に、５名程度の医師を入力する枠を用意している。しかしながら、実際に複数の医師の名前を入力するかどうかは、入力者に委ねられており、正しく記録されない場合も多い。

そこで、アプリケーション制御部４７は、オペレータ判定部４６からＥＮＴＥＲ−ＲＥＧＩＯＮのメッセージを通知されると、オペレータとして特定されたユーザＩＤを、読影者に自動的に追加する。また、アプリケーション制御部４７は、オペレータ判定部４６からＥＸＩＴ−ＲＥＧＩＯＮのメッセージを通知されると、オペレータから除外されたユーザＩＤを、読影者から自動的に削除する。これにより、読影に関与した医師（ユーザ）を自動的に記録することができる。

また、読影レポート作成アプリケーションは、ユーザＩＤ毎のＥＮＴＥＲ−ＲＥＧＩＯＮの通知時刻と、ＥＸＩＴ−ＲＥＧＩＯＮの通知時刻と、検査ごとの読影開始時刻（読影リスト上で患者を選択した時刻）と、読影完了時刻（読影レポートを登録した時刻）と、に基づいて、それぞれのユーザの読影行為に対する作業時間を算出し、その作業時間に応じて寄与率を計算して記録することが可能となる。これにより、医師の読影に関する実際の稼働時間や読影作業への寄与率を、容易に把握することが可能になる。また、このようなより精密な記録を残すことにより、より現実に即した医師の稼働状況を把握することも可能となる。

さらに、アプリケーション制御部４７は、オペレータ判定部４６からＥＸＩＴ−ＲＥＧＩＯＮのメッセージを通知された場合、患者の個人情報保護の観点から、端末１にスクリーンセーバーを起動してもよいし、編集中のデータの消失を未然に防止するために、端末１にデータを自動的に一時保存させてもよい。

またさらに、アプリケーション制御部４７は、編集中のデータある状態で、ＥＸＩＴ−ＲＥＧＩＯＮのメッセージを通知された場合、オペレータから除外されたユーザＩＤと、読影レポート作成アプリケーションがオペレータとして認識しているユーザＩＤと、を比較する。そして、アプリケーション制御部４７は、ユーザＩＤが同じ場合、自動的にスクリーンセーバーを解除してもよい。また、アプリケーション制御部４７は、ユーザＩＤが異なっており、かつ、編集中のデータがあるにも関わらず、オペレータが読影レポート作成アプリケーションを終了させようとした場合、「編集中のデータがあります。アプリケーションを終了させますか」という確認ダイアログを表示してもよいし、「作業中のため終了できません」というエラーメッセージを表示してもよい。エラーメッセージを表示することにより、不可抗力的なデータ消失を未然防止することが可能となる。

続いて、アプリケーションが３Ｄ画像処理アプリケーションである場合について説明する。

３Ｄ画像処理アプリケーションは、２Ｄ画像をもとに、透視断面画像を作成するためのアプリケーションである。近年、画像診断機器の検出能力の拡大に伴い、１秒あたりのデータ収集回数が増加し、シンスライス化（画像のスライス厚が数ｍｍ以下）し、大量の画像データが生成可能となった。

画像診断機器によっては、２Ｄ画像の読影のほかに、３Ｄ画像を作成して読影したり、診断・測定したりすることが多くなってきている。このため、放射線検査技師が３Ｄ画像を作成する時間は、増加傾向の一途をたどっている。

３Ｄ画像を作成する作業は、放射線検査技師や医師が、検査の合間や残業中に行う場合があったため、作業時間を適切に把握することが難しかった。従来は、作業時間を記録するために、ノートに手書きで作業時間を記録したり、放射線情報管理アプリケーションに、３Ｄ画像の作成のための時間を記録させたりしている。しかしながら、上述の通り、オペレータが変わる度にログイン及びログアウトを行うことは現実的ではなく、適切な作業時間を把握することは困難であった。

そこで、アプリケーション制御部４７は、オペレータ判定部４６からＥＮＴＥＲ−ＲＥＧＩＯＮのメッセージを通知されると、オペレータとして特定されたユーザＩＤを保持し、ＥＸＩＴ−ＲＥＧＩＯＮのメッセージを通知されると、保持したユーザＩＤを含むログファイルを出力する。ログファイルには、例えば、保持したユーザＩＤと、３Ｄ画像の作成開始時刻（検査一覧から３Ｄ画像を作成する検査を選択した時刻）と、３Ｄ画像の作成完了時刻（３Ｄ画像を作成して保存した時刻）と、３Ｄ画像の対象患者ＩＤと、３Ｄ画像処理した検査ＩＤと、画像枚数などの情報と、が含まれる。

アプリケ−ション制御部４７によるこのような制御により、ユーザ毎の作業工数データを簡便に入手することができる。また、このような作業工数データを記録することで、３Ｄ画像処理に関する作業ボリュームが明確になり、人員配置計画等に有効な情報として活用が可能になる。

次に、本実施形態に係る端末管理装置４のハードウェア構成について、図１２を参照して説明する。図１２は、端末管理装置４のハードウェア構成の一例を示す図である。図１２に示すように、端末管理装置４は、処理回路４０１と、記憶回路４０２と、を備える。

処理回路４０１は、プログラムを記憶回路４０２から読み出し、実行することで各プログラムに対応する機能を実現するプロセッサである。本実施形態において、ユーザ位置特定部４５、オペレータ判定部４６、及びアプリケーション制御部４７により行われる各処理は、コンピュータによって実行可能なプログラムの形態で記憶回路４０２に記憶されている。各構成の機能は、処理回路４０１が対応するプログラムを実行することにより実現される。図１２における、ユーザ位置特定機能、オペレータ特定機能、及びアプリケーション制御機能は、それぞれユーザ位置特定部４５、オペレータ判定部４６、及びアプリケーション制御部４７の機能に相当する。

処理回路４０１は、ユーザ位置特定部４５、オペレータ判定部４６、及びアプリケーション制御部４７により行われる各処理を実現する単一のプロセッサにより構成されてもよいし、各機能を実現する複数の独立したプロセッサを組み合わせて構成されてもよい。

上記説明において用いた「プロセッサ」という文言は、例えば、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、或いは、特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）、プログラマブル論理デバイス（例えば、単純プログラマブル論理デバイス（Simple Programmable Logic Device：ＳＰＬＤ）、複合プログラマブル論理デバイス（Complex Programmable Logic Device：ＳＰＬＤ）、及びフィールドプログラマブルゲートアレイ（Field Programmable Gate Array：ＦＰＧＡ））等の回路を意味する。

プロセッサは、記憶回路に保存されたプログラムを読み出し実行することで、機能を実現する。なお、記憶回路にプログラムを保存する代わりに、プロセッサの回路内にプログラムを直接組み込むように構成しても構わない。この場合、プロセッサは回路内に組み込まれたプログラムを読み出し実行することで機能を実現する。

記憶回路４０２は、ユーザＩＤテーブル４１、移動履歴テーブル４２、ユーザ情報テーブル４３、及びアプリケーションテーブル４４を記憶している。また、記憶回路４０２は、ユーザ位置特定部４５、オペレータ判定部４６、及びアプリケーション制御部４７の機能を実現するためのプログラムを記憶している。

なお、本実施形態において、端末管理装置４は、図１に示すように、端末１とは別のコンピュータにより構成されてもよいし、端末１と同じコンピュータにより構成されてもよい。端末１と同じコンピュータにより端末管理装置４を構成する場合、処理回路４０１として端末１のＣＰＵを利用し、記憶回路４０２として端末１のメモリやＨＤＤなどを利用すればよい。

また、端末管理装置４は、１つのコンピュータにより構成されてもよいし、複数のコンピュータにより構成されてもよい。例えば、ユーザＩＤテーブル４１、移動履歴テーブル４２、ユーザ情報テーブル４３、及びアプリケーション制御部４７を医療システムのサーバ上に構成し、ユーザ位置特定部４５、オペレータ判定部４６、及びアプリケーション制御部４７を端末１上に構成することなどが考えられる。

次に、以上説明した端末管理システムの動作の一例を説明する。以下では、端末管理装置４は、端末１と同一のコンピュータにより構成されているものとする。

医療用の端末１は、一般に、毎日起動及びシャットダウンを行われる。オペレータが端末１の電源を投入することにより、端末１は起動される。端末１が起動すると、初期化処理が実行され、ログイン画面が表示される。なお、医療用の端末１は、数日以上連続稼働させることも可能である。

端末１にログイン画面が表示されると、オペレータは、端末１のＯＳが提供する認証手段を利用してログイン処理を実行する。ログインに成功すると、デスクトップ画面が表示される。端末１が自動ログイン機能を備える場合には、電源投入後、自動的に（すなわち、明示的なログイン処理を行わずに）デスクトップ画面が表示される。

また、ログインが成功すると、ユーザ位置特定部４５及びオペレータ判定部４６が自動的に起動する。これは、ユーザ位置特定部４５及びオペレータ判定部４６に対応するプログラムをスタートアップに登録しておくことに可能となる。これにより、端末１のログイン後、オペレータの特定及び通知が自動的に開始される。

端末１のオペレータは、端末１のデスクトップ上のアイコンやスタートメニューから、利用したアプリケーションを選択して起動する。起動したアプリケーションは、ＯＳのユーザ認証結果からユーザ情報を取得したり、固有のユーザ認証機能によりオペレータの認証を実行したりする。その後、アプリケーションは、端末管理装置４によるオペレータの検知結果に従って、アプリケーション制御部４７により制御される。なお、アプリケーション制御部４７の機能は、各アプリケーションに組み込まれていてもよい。

業務の終了後、オペレータが端末１をシャットダウンすることにより、端末１の電源が切断される。端末１を連続稼働させる場合には、オペレータは、端末１をシャットダウンせず、アプリケーションを終了させ、ＯＳが提供するログアウト処理を実行すればよい。

以上説明した通り、本実施形態に係る端末管理装置４は、端末１からユーザまでの距離の履歴データに基づいて、端末１のオペレータを精度よく特定することができる。また、オペレータの検知結果に応じて、端末１上で動作する各アプリケーションを制御することができる。アプリケーションの特性に応じて制御方法を変更することにより、端末管理装置４は、端末１による業務効率を向上させたり、エビデンスとして記録されるオペレータの精度を向上させたりすることができる。

（第２実施形態）
第２実施形態に係る端末システムについて、図１３を参照して説明する。図１３は、本実施形態に係る端末システムの一例を示す図である。図１３に示すように、本実施形態に係る端末管理装置４は、データ出力部４８を備える。他の構成は、第１実施形態と同様である。

データ出力部４８は、移動履歴テーブル４２に格納された履歴データを読み出し、所定のデータ形式に変換して出力する。データ形式は、例えば、ＣＳＶ形式であるが、これに限られない。データ出力部４８が出力したデータは、例えば、医療システムのサーバに保存される。

医療システムのユーザは、データ出力部４８が出力したデータを分析することにより、医療システムに含まれる各端末１の稼働率、利用者数、及びオペレータ毎の作業時間などを分析することができる。これらの分析結果は、医療システムに導入した端末１の有効性を評価するための基礎データとして利用したり、医療システムの設備増強を提案するための基礎データとして利用したりすることができる。

なお、データ出力部４８は、ユーザＩＤテーブル４１、ユーザ情報テーブル４３、及びアプリケーションテーブル４４に格納された各種のデータや、無線受信機３から受信したデータを、所定のデータ形式で出力することも可能である。

（第３実施形態）
第３実施形態に係る端末システムについて、図１４を参照して説明する。図１４は、本実施形態に係る端末システムの一例を示す図である。図１４に示すように、本実施形態に係る端末管理装置４は、動作ログ出力部４９を備える。他の構成は、第１実施形態と同様である。

動作ログ出力部４９は、端末１からアプリケーションの動作ログを取得し、所定のデータ形式に変換して出力する。動作ログには、現在時刻、オペレータとして特定されたユーザＩＤ、アプリケーションＩＤ、アプリケーションによる処理の開始時刻及び終了時刻、及びアプリケーションの処理対象となる患者のＩＤなどが含まれる。データ形式は、例えば、ＣＳＶ形式であるが、これに限られない。データ出力部４８が出力したデータは、例えば、医療システムのサーバに保存される。

医療システムのユーザは、動作ログ出力部４９が出力したデータを分析することにより、アプリケーション毎の各オペレータの作業時間、及びアプリケーション毎の各処理の作業時間などを分析することができる。これらの分析結果は、医療システムに導入したアプリケーションの有効性を評価するための基礎データとして利用したり、医療システムの設備増強を提案するための基礎データとして利用したりすることができる。

なお、本発明は上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素を適宜組み合わせることによって種々の発明を形成できる。また例えば、各実施形態に示される全構成要素からいくつかの構成要素を削除した構成も考えられる。さらに、異なる実施形態に記載した構成要素を適宜組み合わせてもよい。

１：端末、２：無線送信機、３：無線受信機、４：端末管理装置、１１：表示部、１２：操作部、４１：ユーザＩＤテーブル、４２：移動履歴テーブル、４３：ユーザ情報テーブル、４４：アプリケーションテーブル、４５：ユーザ位置特定部、４６：オペレータ判定部、４７：アプリケーション制御部、４８：データ出力部、４９：動作ログ出力部

Claims (9)

1. 端末の少なくとも表示部に表示されている内容を肉眼で見ることができる領域または操作部を操作することができる領域の何れかの領域内に存在する、ユーザが携帯する無線機から取得した無線信号に基づいて、当該端末から前記領域内にいるユーザを特定するユーザ特定部と、
   前記ユーザ特定部が特定したユーザがオペレータであるかを前記無線機が受信した無線信号の受信状態情報に基づいて判定するオペレータ判定部と、
   を備える端末管理装置。
2. 前記オペレータ判定部は、所定の時間内に所定回数以上無線信号を受信した無線機の無線信号で特定したユーザを、前記オペレータとして特定する
   請求項１に記載の端末管理装置。
3. 前記オペレータ判定部は、前記無線信号の信号強度に基づいて前記オペレータを特定する
   請求項１に記載の端末管理装置。
4. 前記無線信号の強度に基づいてユーザがいる位置を特定する位置特定部を更に有し、
   前記オペレータ判定部は、所定時間内におけるユーザの位置移動状態に基づいてオペレータを特定する
   請求項１に記載の端末管理装置。
5. 前記オペレータ判定部は、前記受信状態情報の時系列上の変化に基づいて、前記オペレータの変更を検知する
   請求項１に記載の端末管理装置。
6. 前記オペレータ判定部が特定した前記オペレータに基づいて、前記端末上で動作するアプリケーションを制御するアプリケーション制御部を備える
   請求項１乃至請求項５のいずれか１項に記載の端末管理装置。
7. 前記オペレータ判定部は、前記オペレータの変更を検知すると、前記アプリケーション制御部に通知する
   請求項６に記載の端末管理装置。
8. 前記オペレータ判定部は、前記ユーザが前記アプリケーションの利用権限を有さない場合、前記アプリケーション制御部に通知しない
   請求項６又は請求項７に記載の端末管理装置。
9. 表示部と操作部と有する端末と、
   前記端末のユーザが携帯し、当該ユーザを識別可能な情報を無線で送信する無線送信機と、
   前記端末の少なくとも表示部に表示されている内容を肉眼で見ることができる領域または操作部を操作することができる領域の何れかの領域内に存在する、ユーザの前記無線送信機から無線信号を受信する無線受信機と、
   前記無線受信機が受信した無線信号に基づいて、前記端末から所定距離内にいるユーザを特定するユーザ特定部と、前記ユーザ特定部が特定したユーザがオペレータであるかを前記無線信号の受信状態情報に基づいて判定するオペレータ判定部と、を備える端末管理装置と、
   を備える端末システム。

Images