以下、本発明の実施形態について図面を参照して説明する。
(第1実施形態)
第1実施形態に係る端末システムについて、図1〜図12を参照して説明する。本実施形態に係る端末システムは、1つの端末を一人又は複数のユーザが利用可能であり、かつ、端末が一人のオペレータにより操作される任意の端末システムに適用可能である。ここでいうユーザとは、端末システムのユーザとしてIDを登録された、端末を利用可能な人のことである。また、オペレータとは、端末を実際に操作しているユーザのことである。以下では、端末システムが医療用端末システムに適用された場合を例に説明する。
図1は、本実施形態に係る端末システムの一例を示す図である。図1に示すように、端末システムは、端末1と、無線送信機2と、無線受信機3と、端末管理装置4と、を備える。
端末1は、ユーザにより使用される、1つ又は複数の医療用のアプリケーションが動作するコンピュータである。端末1は、端末管理装置4と接続され、端末管理装置4によってアプリケーションの動作を制御される。端末1は、例えば、クライアント/サーバ型のアーキテクチャやサーバサイドアプリケーション型のアーキテクチャを有する医療システムのクライアントである。図1の例では、端末システムは、端末1を備えるが、複数備えてもよい。
端末1は、画像を表示する表示部(ディスプレイ)11と、オペレータが操作するための操作部(キーボードやマウスなど)12と、アプリケーション(実行モジュールなど)やOS(オペレーティングシステム)を実行する処理回路(プロセッサ)と、アプリケーション(実行モジュールなど)やOSを記憶する記憶回路と、を備える。
なお、本実施形態において、端末1上で動作するアプリケーションには、その実行モジュールが端末1により記憶及び実行されるアプリケーションや、その実行モジュールが医療用システムのサーバに記憶され、サーバから実行モジュールを受け取った端末1により実行されるアプリケーションが含まれる。また、端末1上で動作するアプリケーションは、その実行モジュールが医療用システムのサーバにより記憶及び実行され、そのGUI(Graphical User Interface)が端末1の表示部11に表示されるアプリケーションであってもよい。この場合、端末1は、アプリケーションの入出力端末の役割を果たす。
無線送信機2は、端末1のユーザにより携帯される。無線送信機2は、所定の時間間隔で無線信号を送信する。無線信号には、送信機ID(identifier)が含まれる。送信機IDとは、無線送信機2を特定するための識別子である。図1の例では、無線送信機2は、1つしか示されていないが、ユーザが複数いる場合、端末システムには、各ユーザが携帯する複数の無線送信機2が含まれる。
無線送信機2は、例えば、コイン電池で稼働するペンダント型のビーコン発信器である。ビーコン発信器は、電池寿命が長く、充電も不要なため、長期間継続して使用できるという利点がある。ビーコン発信器の通信距離は、送信電波強度、遮蔽物などの設置環境、及び機器の個体差などに応じて異なるが、遮蔽物がない場合、30m程度である。
無線受信機3は、端末1に対する所定の領域内に設けられ、端末管理装置4に接続される。所定の領域とは、端末1の表示部11に表示されている内容を肉眼で見ることができる領域、又は端末1の操作部12を操作することができる領域のことである。無線受信機3は、端末1に組み込まれていてもよいし、端末1の近傍に設置されていてもよい。例えば、受信範囲に指向性を有する無線受信機3を、端末1の表示部11と操作部12との間に設置することが考えられる。無線受信機3は、無線送信機2が送信した無線信号を受信する。無線送信機2から無線信号を受信した無線受信機3は、無線信号に含まれる無線送信機2の送信機IDを出力する。出力された送信機IDは、端末管理装置4に入力される。
無線送信機2と無線受信機3との間の無線通信の通信規格は、無線LAN(IEEE 802.11諸規格に準拠した機器で構成されるネットワーク)、Bluetooth(登録商標)、Bluetooth(登録商標) Low Energy、及びNFC(Near Field Communication)など、任意に選択可能である。
通信規格がBluetooth(登録商標)である場合、例えば、無線送信機2としてビーコン発信器が用いられ、無線受信機3としてビーコン受信機が用いられる。ビーコン発信器は、所定の間隔で所定の強度の所定の無線信号(ビーコン)を発信する。この場合、無線受信機3は、無線送信機2から受信したビーコンの信号強度に基づいて、無線送信機2との間の距離を特定できる。
本実施形態では、無線送信機2はユーザに携帯され、無線受信機3は端末1に設けられるため、無線送信機2と無線受信機3との間の距離は、端末1とユーザとの距離に相当する。
距離は、例えば、50cm未満であることを示すIMMEDIATE、50cm以上6m未満であることを示すNEAR、及び6m以上20m未満であることを示すFAR、の3値で表される。この無線受信機3は、送信機IDとともに、無線送信機2との間の距離を出力してもよい。
また、複数の無線受信機3を、その信号受信可能領域が一部重なり合う状態で端末1の周りに配置し、複数の無線受信機3による同一の無線送信機2からの信号受信状態に基づいて、無線送信機2と端末1との位置関係を特定しても良い。
さらに、通信規格がNFCである場合、例えば、無線送信機2として非接触タグが用いられ、無線受信機3として非接触タグ読み取り装置が用いられる。非接触タグは、非接触タグ読み取り装置が所定の間隔で発信する電波を受信すると、予め記憶されたデータを無線で送信する。したがって、非接触タグに予め送信機IDを記憶させることで、非接触タグ読み取り装置からの電波を受信した非接触タグから送信機IDを含む無線信号を送信させることができる。
無線送信機2として非接触タグを用いる場合、無線受信機3(非接触タグ読み取り装置)は、信号強度に基づいて無線送信機2との間の距離を特定できない。非接触タグは、非接触タグ読み取り装置から或る距離以内に近接し、非接触タグ読み取り装置からの電波を受信することができないと、データを無線送信することができない。したがって、非接触タグ読み取り装置がデータを受信した非接触タグは、非接触タグ読み取り装置から所定の距離内に存在しているものとみなしてもよい。
また、非接触タグ読み取り装置は、非接触タグから受信した送信機IDをその受信時刻または電波発信時刻と対応付けて履歴データとして記憶し、この履歴データに基づいて非接触タグ読み取り装置から所定の距離内に存在していた非接触タグの送信機IDを特定してもよい。
なお、以下では、無線送信機2がビーコン発信器であり、無線送信機2と無線受信機3との間の通信規格がBluetooth(登録商標)である場合を例に説明する。無線受信機3は、無線信号を受信すると、無線送信機2の送信機IDと、無線送信機2との間の距離と、を出力するものとする。
端末管理装置4は、端末1を管理するコンピュータであり、端末1及び無線受信機3と接続されている。端末管理装置4のハードウェア構成について、詳しくは後述する。図1では、端末管理装置4の機能構成が図示されている。
図1に示すように、端末管理装置4は、ユーザIDテーブル41と、移動履歴テーブル42と、ユーザ情報テーブル43と、アプリケーションテーブル44と、ユーザ位置特定部45と、オペレータ判定部46と、アプリケーション制御部47と、を備える。
ユーザIDテーブル41は、無線送信機2と、無線送信機2を携帯するユーザと、の対応関係を格納するテーブルである。ユーザIDテーブル41は、端末システムや医療システムの管理者により更新される。
図2は、ユーザIDテーブルの一例を示す図である。図2の例では、ユーザIDテーブル41の各レコードに、レコード番号(No)、ユーザID、及び送信機IDが含まれる。ユーザIDとは、ユーザを特定するための識別子である。以下では、レコード番号Xにより特定されるレコードを、レコードXという。
例えば、図2のレコード1は、ユーザIDがTOSHIBA−1のユーザが、送信機IDがBEACON−1の無線送信機2を携帯していることを示している。
移動履歴テーブル42は、端末1に対するユーザの距離の履歴データを格納するテーブルである。移動履歴テーブル42は、ユーザ位置特定部45及びオペレータ判定部46により更新される。
図3は、移動履歴テーブル42の一例を示す図である。図3の例では、移動履歴テーブルの各レコードには、レコード番号(No)、端末ID、ユーザID、距離、登録時刻、通知時刻、及び通知内容が含まれる。端末IDとは、端末1を特定する識別子である。登録時刻とは、ユーザ位置特定部45によりレコードが追加された時刻のことである。登録時刻は、端末1に対するユーザの距離が特定された時刻に相当する。通知時刻及び通知内容については後述する。
例えば、図3のレコード1は、「端末IDが放射線科−1の端末1に対するユーザIDがTOSHIBA−1のユーザの距離がFARである」ことが2015/2/2の8:00に特定されたことを示している。
なお、移動履歴テーブル42は、端末1の起動時に初期化(レコードを削除)されてもよいし、初期化ツールにより任意のタイミングで初期化されてもよいし、初期化されなくてもよい。
また、距離は、FAR、NEAR、及びIMMEDIATEの3値でなくてもよい。例えば、距離は、端末1から所定範囲内にユーザがいる又はいない、の2値により表されてもよいし、数値で表されてもよい。
ユーザ情報テーブル43は、各ユーザに関する情報(ユーザ情報)を格納するテーブルである。ユーザ情報は、例えば、ユーザID、ユーザの所属、資格、連絡先、及び許可アプリIDであるが、これに限られない。許可アプリIDとは、ユーザが利用を許可されたアプリケーションを特定する識別子のことである。ユーザ情報テーブル43は、端末システムや医療システムの管理者により更新される。
図4は、ユーザ情報テーブル43の一例を示す図である。図4の例では、ユーザ情報テーブルの各レコードに、レコード番号(No)、ユーザID、所属、資格、連絡先(内線)、及び許可アプリIDが含まれる。
例えば、図4のレコード1は、ユーザIDがTOSHIBA−1のユーザは、放射線科に所属し、放射線技師の資格を有し、内線番号が1111であり、許可アプリIDがAPP−01のアプリケーションの利用権限を有することを示している。
アプリケーションテーブル44は、端末1上で動作可能なアプリケーションに関する情報(アプリケーション情報)を格納するテーブルである。アプリケーション情報は、例えば、アプリ名称、ウインドウ表示名称、及び実行モジュール名であるが、これに限られない。アプリ名称とは、アプリケーションの名称のことである。ウインドウ表示名称は、アプリケーションを実行する際に、端末1のディスプレイ上に表示される名称のことである。アプリケーションテーブル44は、端末システムや医療システムの管理者により更新される。
図5は、アプリケーションテーブルの一例を示す図である。図5の例では、アプリケーションテーブルの各レコードに、レコード番号(No)、アプリID、アプリ名称、ウインドウ表示名称、及び実行モジュール名が含まれる。アプリIDとは、アプリケーションを特定するための識別子である。
例えば、図5のレコード1は、アプリIDがAPP−01のアプリケーションは、「放射線情報管理業務」という名称であり、ウインドウ表示名称が「放射線情報管理アプリケーション」であり、実行モジュール名が「app01_exe」であることを示している。
なお、以上説明した各テーブルは、データベース管理システム(DBMS)により実現されてもよいし、INI形式やXML形式などの設定ファイルにより実現されてもよい。
ユーザ位置特定部45は、無線信号を受信した無線受信機3から入力された情報(無線受信機3が受信した無線信号の信号強度など)に基づいて、端末1に対する所定の領域内にいるユーザ及びそのユーザから端末1までの距離を特定する。すなわち、ユーザ位置特定部45は、端末1に対して、どのユーザが、どのような距離にいるかを特定する。
無線受信機3から送信機ID及び距離が入力された場合、無線受信機3に対する無線送信機2の距離は特定されている。これは、端末1に対する無線送信機2の距離が特定されていることに相当する。しかしながら、この時点では、無線送信機2を携帯するユーザが特定されていない。
そこで、ユーザ位置特定部45は、無線受信機3から入力された送信機IDに基づいて、無線送信機2を携帯しているユーザを特定する。具体的には、ユーザ位置特定部45は、送信機IDを検索条件としてユーザIDテーブル41を検索し、送信機IDに対応するユーザIDを特定する。これにより、無線送信機2を携帯しているユーザが特定される。
なお、端末1に対する距離は、ユーザ位置特定部45が特定してもよい。例えば、無線受信部3が無線信号をユーザ位置特定部45に入力し、入力された無線信号に基づいて、ユーザ位置特定部45が距離を特定することが考えられる。ユーザ位置特定部45は、無線信号の信号強度などに基づいて距離を特定すればよい。
また、無線受信機3が無線送信機2との間の通信状態をユーザ位置特定部45に入力し、入力された通信状態に基づいて、ユーザ位置特定部45が距離を特定することも考えられる。この場合、ユーザ位置特定部45は、距離を、ユーザがいる又はいない、の2値で特定すればよい。ユーザ位置特定部45は、通信状態が有効(すなわち、通信中)の場合にユーザがいると特定し、通信状態が無効(すなわち、通信していない)の場合にユーザがいないと特定すればよい。この特定方法は、無線送信機2として非接触タグを用いる場合のように、無線信号の信号強度から距離を特定できない場合にも適用可能である。
端末1に対するユーザの距離を特定したユーザ位置特定部45は、移動履歴テーブル42に新たなレコードを追加する。追加されたレコードの端末ID、ユーザID、距離、登録時刻、通知時刻、及び通知内容には、端末1の端末ID、ユーザIDテーブル41を検索して特定されたユーザID、無線受信機3から入力された(又はユーザ位置特定部45が識別した)距離、現在時刻、NULL、及びNULLが、それぞれ登録される。端末1の端末IDは、設定情報として記憶されていてもよいし、無線受信機3から入力されてもよい。
ユーザ位置特定部45は、上述の特定処理及びレコードの追加処理を、無線受信機3から情報を入力されるたびに実行してもよい。例えば、無線受信機3が1秒ごとに無線信号を受信してユーザ位置特定部45に情報を入力する場合、ユーザ位置特定部45は、1秒ごとに上記の処理を行なえばよい。この場合、1秒ごとに移動履歴テーブル42のレコードが追加される。
また、ユーザ位置特定部45は、無線受信機3から情報を入力されるたびに特定処理を実行し、所定の条件を満たす場合にのみレコードを追加してもよい。所定の条件として、例えば、特定されたユーザIDを含む最新のレコードの登録時刻から、現在時刻まで、の経過時間が所定時間以上であること、などが考えられる。最新のレコードの登録時刻は、特定されたユーザIDを検索条件として移動履歴テーブル42を検索することにより取得できる。これにより、移動履歴テーブル42に追加されるレコードの数を抑制することができる。
さらに、ユーザ位置特定部45は、特定処理の結果特定されたユーザID及び距離と、最新のレコードに含まれるユーザID及び距離と、が一致する場合、最新のレコードの登録時刻だけ更新してもよい。これにより、移動履歴テーブル42に追加されるレコードの数を抑制することができる。
オペレータ判定部46は、ユーザ位置特定部45が特定した端末1に対するユーザの距離の履歴データに基づいて、ユーザ位置特定部45が特定したユーザがオペレータであるか判定し、端末1のオペレータを特定する。オペレータ判定部46は、オペレータの変更を検知すると、検知したオペレータの変更を、アプリケーション制御部47に通知する。
アプリケーション制御部47は、オペレータ判定部46から通知されたメッセージに応じて、端末1上で動作するアプリケーションを制御する。アプリケーション制御部47によるアプリケーションの制御について、詳しくは後述する。
以下、オペレータ判定部46によるオペレータの特定及び変更の通知について、それぞれ説明する。まず、オペレータの特定について説明する。
オペレータ判定部46は、あるユーザが端末1に対する所定範囲R内にいる時間が所定時間T以上になると、そのユーザを新たなオペレータとして特定する。所定時間T及び所定範囲Rは任意に設定可能である。所定時間Tは、例えば、無線受信機3が無線信号を受信する時間間隔や無線送信機2が無線信号を送信する時間間隔の、整数倍の時間に設定される。この場合、所定時間Tは、ユーザの位置が、所定範囲R内であると特定された回数に対応する。また、所定範囲Rは、端末1からの距離として設定されてもよいし、無線受信機3が受信する無線信号の信号強度の範囲として設定されてもよい。
そして、オペレータ判定部46は、新たなオペレータとして特定されたユーザが所定範囲R内からいなくなるまで(ユーザの位置が所定範囲R内であると特定されなくなるまで)、そのユーザをオペレータとして特定する。すなわち、オペレータ判定部46は、所定時間T以上断続的に、端末1に対する所定範囲R内にいるユーザを、オペレータとして特定する。オペレータ判定部46は、オペレータとして特定されていたユーザの位置が、オペレータを判定するタイミングに、所定範囲R内でなかった場合、そのユーザを、オペレータから除外する。
上述のオペレータの変更には、オペレータの登場及び退場が含まれる。オペレータの登場は、新たなオペレータの特定に相当する。オペレータの退場は、オペレータからの除外に相当する。
ここで、図6は、端末1に対するユーザの状態(距離)の遷移を示す状態遷移図である。図6の各ノードは端末1に対するユーザの距離を示し、各矢印は状態遷移を示す。図6におけるINITは、ユーザが検知されていない、すなわち、ユーザの携帯する無線送信機2の無線信号が、無線受信機3に受信されていない状態を示す。
状態遷移1〜5は、ユーザが端末1に接近する状態遷移である。状態遷移6〜10は、ユーザが端末1から離間する状態遷移である。状態遷移11〜14は、ユーザが端末1に対して所定の距離を保ったままでいる状態遷移である。例えば、状態遷移3は、ユーザの距離が、「NEAR」から「IMMEDIATE」に遷移することを示している。
なお、状態遷移4,5,9,10は、ユーザと端末1との物理的な位置関係により、無線信号から特定される距離が急激に変化する場合を想定した状態遷移である。例えば、端末1が検査室の入口に設置されており、ユーザが、廊下から検査室に入室した場合、ユーザの状態が、状態遷移4,5のように遷移することが想定される。また、図示省略されているが、端末1が検査室の入口から離れた位置(入口から50cm以上6m以内の位置)に設置されている場合には、ユーザの距離が「INIT」から「NEAR」に遷移する場合や、「NEAR」から「INIT」に遷移する場合も想定できる。
ここで、所定範囲Rが、端末1からの距離が「IMMEDIATE」の範囲である場合、を例に、オペレータの特定について説明する。図7は、オペレータの登場及び退場の検知タイミングの一例を示す図である。図7の状態遷移は、図6に対応している。図7において、○はオペレータの登場の検知タイミングであり、×はオペレータの退場の検知タイミングである。
図7の例では、ユーザの距離が「NEAR」から「IMMEDIATE」に遷移(状態遷移3)した後、同一状態の遷移(状態遷移11)が1回繰り返されると、オペレータの登場(ENTER−REGION)が検知される。すなわち、あるユーザの距離が、「NEAR」、「IMMEDIATE」、「IMMEDIATE」の順に特定された場合、そのユーザが新たなオペレータとして特定される。状態遷移4,5についても同様である。これは、所定時間Tが、ユーザ位置特定部45による特定処理の1回分の時間に相当する。例えば、ユーザ位置特定部45による特定処理が1分間隔で実行される場合、所定時間Tは1分となる。
このように、オペレータ判定部46は、所定範囲R内にユーザがいる場合であっても、所定時間Tが経過するまで、そのユーザをオペレータとして特定しない。これにより、端末1に一時的に近づいただけのユーザが、オペレータとして誤って特定されることを防ぐことができる。なお、図7の例では、オペレータの登場を検知するための同一状態の遷移回数は、1回であるが、2回以上であってもよい。
また、図7の例では、オペレータとして特定されたユーザの距離が「IMMEDIATE」から「NEAR」に遷移すると(状態遷移6)、オペレータの退場(EXIT−REGION)が検知される。すなわち、そのユーザがオペレータから除外される。状態遷移9,10についても同様である。
なお、図6における「INIT」は、実際には検知されない距離である。すなわち、無線受信機3から、ある無線送信機2の距離がINITである、という情報が入力されることはない。「INIT」は、ユーザ位置特定部45が移動履歴テーブル42を参照することにより特定される。ユーザ位置特定部45は、所定時間以上検知されていないユーザの距離をINITに特定する。
具体的には、ユーザ位置特定部45は、特定処理の度に、移動履歴テーブル42に含まれるユーザIDを取得し、各ユーザIDが含まれる最新のレコードの登録時刻を取得する。ユーザ位置特定部45は、取得した登録時刻から現在時刻までの経過時間が所定値以上のユーザIDを発見した場合、発見したユーザIDを含む新たなレコードを移動履歴テーブル42に追加する。追加されるレコードの距離はINIT、登録時刻は現在時刻、通知時刻及び通知内容はNULLである。
次に、オペレータの変更の通知について説明する。オペレータ判定部46は、オペレータの変更(登場及び退場)を検知すると、アプリケーション制御部47に、オペレータの変更を通知する。
より詳細には、オペレータ判定部46は、オペレータの登場を検知すると、新たなオペレータとして特定されたユーザのユーザID、及びそのユーザが新たなオペレータとして特定されたことを、アプリケーション制御部47に通知する。
また、オペレータ判定部46は、オペレータの退場を検知すると、オペレータから除外されたユーザのユーザID、及びそのユーザがオペレータから除外されたことを、アプリケーション制御部47に通知する。
オペレータ判定部46は、変更を検知するたびに通知処理を実行してもよい。また、オペレータ判定部46は、変更を検知し、かつ、所定の通知条件が満たされた場合に通知処理を実行してもよい。
ここで、通知条件の2つの具体例について説明する。
第1の通知条件は、変更を検知されたユーザが、端末1上で動作可能なアプリケーションの利用権限を有することである。第1の通知条件を利用する場合、オペレータ判定部46は、検知されたユーザが、端末1上で動作可能なアプリケーションの利用権限を有する場合のみ通知処理を実行する。
これは、ユーザがアプリケーションの利用権限を有さない場合、通知の有無に関わらず、そのユーザはアプリケーションを利用できず、アプリケーション制御部47による制御内容が変わらないためである。
具体的には、オペレータ判定部46は、オペレータの登場(又は退場)を検知すると、検知された(オペレータとして特定された、又はオペレータから除外された)ユーザのユーザIDを検索条件としてユーザ情報テーブル43を検索し、そのユーザの許可アプリIDを取得する。取得した許可アプリIDに、端末1上で動作可能なアプリケーションのアプリケーションIDが含まれている場合、オペレータ判定部46は通知処理を実行する。一方、ユーザの許可アプリIDに、端末1上で動作可能なアプリケーションのアプリケーションIDが含まれていない場合、オペレータ判定部46は通知処理を実行しない。
第2の通知条件は、変更を検知されたユーザが利用権限を有するアプリケーションが、端末1上で動作していることである。第2の通知条件は、第1の通知条件と併用される。第2の通知条件を利用する場合、オペレータ判定部46は、検知されたユーザが利用権限を有するアプリケーションが、端末1上で動作している場合のみ通知処理を実行する。
これは、ユーザがアプリケーションの利用権限を有していても、そのアプリケーションが端末1上で動作していない場合、アプリケーション制御部47による制御内容が変わらないためである。
具体的には、オペレータ判定部46は、まず、第1の通知条件が満たされるか判定する。第1の条件が満たされない場合、オペレータ判定部46は、通知処理を実行しない。
一方、第1の条件が満たされた場合、オペレータ判定部46は、ユーザの許可アプリIDを検索条件としてアプリケーションテーブル44を検索し、ユーザが利用権限を有するアプリケーションのウインドウ表示名称などを取得する。オペレータ判定部46は、取得したウインドウ表示名などを利用して、ユーザが利用権限を有するアプリケーションが端末1上で動作しているか確認し、動作していた場合、通知処理を実行し、動作していない場合、通知処理を実行しない。
アプリケーションが端末1上で動作しているかの確認は、既存の任意の方法を利用して行なえばよい。例えば、端末1のOS(オペレーティングシステム)がWingdows(登録商標)の場合、オペレータ判定部46は、EnumWindows関数を呼び出し、トップレベルウインドウごとに指定したコールバック関数を呼び出し、コールバック関数に含まれるウインドウハンドルを取得し、取得したウインドウハンドルを指定したGetWindowText関数を呼び出し、ウインドウのタイトルを取得する。オペレータ判定部46は、こうして取得したタイトルと、ウインドウ表示名と、を比較することにより、アプリケーションが端末1上で動作しているか確認することができる。
オペレータ判定部46は、上記のような通知条件を利用することにより、アプリケーション制御部47への余計な通知を抑制することができる。なお、オペレータ判定部46は、通知条件として、第1の通知条件だけを利用してもよいし、第1の通知条件及び第2の通知条件を併用してもよい。また、通知条件は、上記のものに限られず、任意に設定可能である。
オペレータ判定部46は、アプリケーション制御部47に変更を通知すると、移動履歴テーブル42を更新する。具体的には、オペレータ判定部46は、オペレータの変更が検知された移動履歴テーブル42のレコードの通知時刻に現在時刻(アプリケーション制御部47に変更を通知した時刻)を登録し、通知内容に検知した変更の内容(オペレータの登場又は退場)を登録する。
例えば、図3の移動履歴テーブルのレコード4は、通知時刻が2015/2/2 8:07であり、通知内容がENTER−REGIONである。これは、オペレータ判定部46が、2015/2/2の8:07に、オペレータ(ユーザIDがTOSHIBA−1のユーザ)の登場を検知し、アプリケーション制御部47に通知したことを示している。
また、図3の移動履歴テーブルのレコード5は、通知時刻が2015/2/2 9:55であり、通知内容がEXIT−REGIONである。これは、オペレータ判定部46が、2015/2/2の9:55に、オペレータ(ユーザIDがTOSHIBA−2のユーザ)の退場を検知し、アプリケーション制御部47に通知したことを示している。
オペレータ判定部46は、端末1が起動すると自動的に処理を開始し、予め設定された時間間隔で、上述の処理を実行する。以下、オペレータ判定部46による処理について、図8を参照して具体的に説明する。図8は、オペレータ判定部46による処理の一例を示すフローチャートである。
まず、オペレータ判定部46は、現在時刻から日付情報を抽出し、抽出した日付及び端末IDを検索条件として、移動履歴テーブル42を検索し、検索条件を満たすレコードに含まれる全てのユーザIDを取得する(ステップS1)。
次に、オペレータ判定部46は、取得したユーザIDの中から1つ選択し、選択したユーザIDに対して、ステップS2以降の処理を実行する。オペレータ判定部46は、取得した全てのユーザIDについて、同様にステップS2以降の処理を実行する。以下では、選択されたユーザIDはTOSHIBAであるものとする。
オペレータ判定部46は、移動履歴テーブル42を検索して、レコード数Aを取得する(ステップS2)。検索条件は、ユーザID=TOSHIBA、通知内容=ENTER−REGIONである。すなわち、レコード数Aは、現在時刻までに、ユーザID=TOSHIBAのユーザが、新たに登場したオペレータとして検知された回数(新たなオペレータとして特定された回数)に相当する。
また、オペレータ判定部46は、移動履歴テーブル42を検索して、レコード数Bを取得する(ステップS3)。検索条件は、ユーザID=TOSHIBA、通知内容=ENTER−REGIONである。すなわち、レコード数Bは、現在時刻までに、ユーザID=TOSHIBAのユーザが、退場したオペレータとして検知された回数(オペレータから除外された回数)に相当する。なお、ステップS2,S3は、順番が逆でもよい。
続いて、オペレータ判定部46は、取得したレコード数A,Bを比較する(ステップS4)。A<Bの場合は、オペレータの特定や変更の検知が適切に行われていない場合に相当する。したがって、A<Bの場合、オペレータ判定部46は、エラーログを出力し、ユーザID=TOSHIBAに関する処理を終了する(ステップS5)。
ステップS4において、A=Bの場合は、現在時刻において、ユーザID=TOSHIBAのユーザが、オペレータとして特定されていない場合に相当する。この場合、オペレータ判定部46は、移動履歴テーブル42を検索して、ユーザID=TOSHIBAのユーザが新たなオペレータとして登場したか判定する。
A=0の場合(ステップS6のYES)、オペレータ判定部46は、検索の開始時刻を設定しない(ステップS7)。開始時刻とは、上記の判定のために、移動履歴テーブル42を検索する登録時刻の始点である。A=0の場合は、端末1の使用を開始した直後に相当する。
一方、A≠0の場合(ステップS6のNO)、オペレータ判定部46は、検索の開始時刻を、ユーザID=TOSHIBA、通知内容=EXIT−REGION、となっている最新のレコードの通知時刻に設定する(ステップS8)。これは、ユーザID=TOSHIBAのユーザが新たなオペレータとして登場し得るのは、上記の通知時刻以降だからである。
次に、オペレータ判定部46は、移動履歴テーブル42を検索して、検索条件に該当するレコードが2個以上連続しているか判定する(ステップS9)。検索条件は、ユーザID=TOSHIBA、距離=IMMEDIATE、登録時刻>開始時刻である。開始時刻が設定されていない場合の検索条件は、ユーザID=TOSHIBA、距離=IMMEDIATEである。
この検索条件に該当するレコードが2つ以上連続していない場合(ステップS9のNO)、オペレータ判定部46は、ユーザID=TOSHIBAのユーザは端末1にいないと判定し、ユーザID=TOSHIBAに関する処理を終了する。
一方、この検索条件に該当するレコードが2つ以上連続している場合(ステップS9のYES)、オペレータ判定部46は、ユーザID=TOSHIBAのユーザをオペレータとして特定する(ステップS10)。これは、検索条件に該当するレコードが2つ以上連続している場合とは、ユーザID=TOSHIBAのユーザの距離が、「IMMEDIATE以外」から「IMMEDIATE」に遷移した後、再び「IMMEDIATE」に遷移した場合に相当するためである。
オペレータ判定部46は、オペレータを特定すると、上述の通り、アプリケーション制御部47に通知する。また、オペレータ判定部46は、2つ以上連続したレコードのうち、2番目に登録時刻が古いレコードを更新する。具体的には、通知内容をENTER−REGIONに更新し、通知時刻を現在時刻に更新する。その後、オペレータ判定部46は、ユーザID=TOSHIBAに関する処理を終了する。
ステップS4において、A>Bの場合は、現在時刻において、ユーザID=TOSHIBAのユーザが、オペレータとして特定されている場合に相当する。この場合、オペレータ判定部46は、移動履歴テーブル42を検索して、ユーザID=TOSHIBAのユーザをオペレータから除外するか判定する。
上記の判定のために、まず、オペレータ判定部46は、検索の開始時刻を、ユーザID=TOSHIBA、通知内容=ENTER−REGION、となっている最新のレコードの通知時刻に設定する(ステップS11)。
次に、オペレータ判定部46は、移動履歴テーブル42を検索して、検索条件に該当するレコードがあるか判定する(ステップS12)。検索条件は、ユーザID=TOSHIBA、距離≠IMMEDIATE、登録時刻>開始時刻である。
この検索条件に該当するレコードがない場合(ステップS12のNO)、オペレータ判定部46は、ユーザID=TOSHIBAのユーザはまだ端末1にいると判定し、ユーザID=TOSHIBAに関する処理を終了する。
一方、この検索条件に該当するレコードがある場合(ステップS12のYES)、オペレータ判定部46は、ユーザID=TOSHIBAのユーザをオペレータから除外する(ステップS13)。これは、検索条件に該当するレコードがある場合とは、ユーザID=TOSHIBAのユーザの距離が、「IMMEDIATE」から「IMMEDIATE以外」に遷移した場合に相当するためである。
オペレータ判定部46は、オペレータを除外すると、上述の通り、アプリケーション制御部47に通知する。また、オペレータ判定部46は、検索条件に該当した最も古いレコードを更新する。具体的には、通知内容をEXIT−REGIONに更新し、通知時刻を現在時刻に更新する。その後、オペレータ判定部46は、ユーザID=TOSHIBAに関する処理を終了する。
例えば、オペレータ判定部46が、図3の移動履歴テーブル42を参照して、2015/2/2の8:07に処理を実行した場合、まず、ユーザIDとしてTOSHIBA−1が取得される(ステップS1)。レコード数Aは0となり(ステップS2)、レコード数Bも0(ステップS3)となる。したがって、処理はステップS4のA=Bに進み、ステップS6のYESに進み、開始時刻は設定されない(ステップS7)。図3の移動履歴テーブル42では、レコード3,4(ユーザID=TOSHIBA−1、距離=IMMEDIATE)が連続しているため(ステップS9のYES)、オペレータ判定部46は、ユーザID=TOSHIBA−1のユーザをオペレータとして特定し(ステップS10)、アプリケーション制御部47に通知する。そして、オペレータ判定部46は、検索条件に該当する2番目に古いレコード4の通知時刻を現在時刻(2015/2/2 8:07)に更新し、通知内容をENTER−REGIONに更新する。ステップS1において、ユーザIDはTOSHIBA−1しか取得されていないため、8:07におけるオペレータ判定部46の処理は終了する。
一方、オペレータ判定部46が、図3の移動履歴テーブル42を参照して、2015/2/2の9:55に処理を実行した場合、まず、ユーザIDとしてTOSHIBA−1が取得される(ステップS1)。レコード4がステップS2の検索条件に該当するため、レコード数Aは1となり(ステップS2)、レコード数Bは0(ステップS3)となる。したがって、処理はステップS4のA>Bに進み、開始時刻が、レコード4の登録時刻(2015/2/2 8:07)に設定される(ステップS11)。オペレータ判定部46が開始時刻(8:07)から現在時刻(9:55)までのレコードを検索すると、ユーザID=TOSHIBA−1かつ距離=NEAR(≠IMMEDIATE)のレコードとして、レコード5が発見される(ステップS12のYES)。したがって、オペレータ判定部46は、ユーザID=TOSHIBA−1のユーザをオペレータから除外し(ステップS13)、アプリケーション制御部47に通知する。そして、オペレータ判定部46は、検索条件に該当する最も古いレコード5の通知時刻を現在時刻(2015/2/2 9:55)に更新し、通知内容をEXIT−REGIONに更新する。ステップS1において、ユーザIDはTOSHIBA−1しか取得されていないため、9:55におけるオペレータ判定部46の処理は終了する。
図9は、図8の処理により更新された移動履歴テーブル42をグラフ化した図である。図9の例では、ユーザIDは、TOSHIBA−1,TOSHIBA−2,TOSHIBA−3の3つであり、各ユーザの端末1に対する距離は、FAR、NEAR、及びIMMEDIATEの3値で示されている。
図9に示すように、オペレータ判定部46は、各ユーザの距離が2回目にIMMEDIATEになったタイミングでオペレータの登場を通知し(ENTER通知)、各ユーザの距離がIMMEDIATEからIMMEDIATE以外に遷移したタイミングでオペレータの退場を通知している(EXIT通知)。例えば、図9の例では、ユーザIDがTOSHIBA−1のユーザは、8:07にオペレータとして特定され、9:55にオペレータから除外されている。すなわち、ユーザIDがTOSHIBA−1のユーザは、8:07から9:55までオペレータとして特定されている。
以上説明した図8の処理では、オペレータとして複数のユーザが特定されることが許容されていた。このため、例えば、図9の例では、ユーザIDがTOSHIBA−2及びTOSHIBA−3のユーザが、同一の時間帯にそれぞれオペレータとして特定されている。
しかしながら、端末1がPCである場合のように、端末1のオペレータが複数であるとは考えにくい場合も想定される。そこで、以下では、オペレータ判定部46が、オペレータとして1人のユーザしか特定しない場合の処理について説明する。
オペレータ46は、あるユーザXをオペレートして特定するか判定するために、そのユーザXが図7で説明した条件を満たすか判定すると共に、そのユーザXより先にオペレータとして特定された他のユーザがいるか判定すればよい。オペレータ46は、ユーザXが図7で説明した条件を満たし、かつ、他のユーザがオペレータとして特定されていない場合、ユーザXをオペレータとして特定する。
図10は、オペレータ判定部46による処理の他の例を示すフローチャートである。図10の例では、オペレータ判定部46は、オペレータとして、一人のユーザだけを特定する。図10のステップS1〜S13は、図8と同様である。
図10の例では、検索条件に該当するレコードが2つ以上連続している場合(ステップS9のYES)、処理はステップS14に進む。ステップS14において、オペレータ判定部46は、他のユーザがオペレータとして特定済みか判定する。他のユーザがオペレータとして特定されていた場合(ステップS14のYES)、オペレータ判定部46は、処理を終了する。一方、オペレータ判定部46は、他のユーザがオペレータとして特定されていない場合(ステップS14のNO)、判定中のユーザ(ユーザIDがTOSHIBAのユーザ)をオペレータとして特定する(ステップS10)。
他のユーザがオペレータとして特定されているか判定するために、オペレータ判定部46は、移動履歴テーブル42を検索して、レコード数C及びレコード数Dを取得する。
レコード数Cの検索条件は、ユーザID≠TOSHIBA、通知内容=ENTER−REGIONである。レコード数Cは、現在時刻までに、他のユーザが新たに登場したオペレータとして検知された回数の合計に相当する。
レコード数Dの検索条件は、ユーザID≠TOSHIBA、通知内容=EXIT−REGIONである。レコード数Dは、現在時刻までに、他のユーザが退場したオペレータとして検知された回数の合計に相当する。
オペレータ判定部46は、レコード数C及びレコード数Dを比較する。C=Dの場合、オペレータ判定部46は、他のユーザがオペレータとして特定されていないと判定する(ステップS14のNO)。C>Dの場合、オペレータ判定部46は、他のユーザがオペレータとして特定されていると判定する(ステップS14のYES)。C<Dの場合、オペレータ判定部46は、エラーログを出力して処理を終了する。
図11は、図10の処理により更新された移動履歴テーブル42をグラフ化した図である。図11の例では、図9とは異なり、ユーザIDがTOSHIBA−3のユーザは、オペレータとして特定されず、通知もされていない。これは、ユーザIDがTOSHIBA−3のユーザより、ユーザIDがTOSHIBA−2のユーザが先にオペレータとして特定されているためである。オペレータをこのように特定及び通知することにより、図11に示すように、同時に一人のユーザだけをオペレータとして特定することができる。
次に、アプリケーション制御部47によるアプリケーションの制御方法について、具体的に説明する。以下では、アプリケーションが、放射線情報管理アプリケーション、読影レポート作成アプリケーション、3D画像処理アプリケーションである場合を例に説明する。
まず、アプリケーションが放射線管理アプリケーションである場合について説明する。
放射線情報管理アプリケーションは、画像検査を行う際に、撮影する患者を選択し、前回の撮影条件を確認したり、HIS(病院情報システム)から送信された画像検査オーダの内容を確認したり、撮影後に検査に使用した医薬品(造影剤)や医療材料(フィルムやカテーテルなど)を入力し、HISに送信したりするアプリケーションである。
画像検査は、独立した検査室で行われることが多く、画像検査を行う際、患者を介助したり、撮影位置を調整したり、撮影操作を行ったりするなど、複数のユーザ(職員)が連携しながら行うことが多い。このため、同じユーザが毎回同じ作業を行うとは限らない。また、異なるユーザが作業を行う度に、毎回ログイン及びログアウトを行うことも現実的ではない。
そこで、アプリケーション制御部47は、オペレータ判定部46からENTER−REGIONのメッセージを通知されると、新たなオペレータとして特定されたユーザIDと、その時点で放射線管理アプリケーションが認識しているユーザIDとを比較する。ユーザIDが異なっている場合、アプリケーション制御部47は、放射線管理アプリケーションが認識しているユーザIDを、自動的にメッセージ中のユーザIDに置き換え、端末1の表示部11に表示する。この状態で、オペレータが登録ボタンなどの操作を行うと、その時点でオペレータとして特定されたユーザが、撮影者として登録される。
一方、アプリケーション制御部47は、オペレータ判定部46からEXIT−REGIONのメッセージを通知されると、放射線管理アプリケーションが認識しているユーザIDをNULLに置換え、誰もログインしていない状態に戻す。
この端末管理装置4により、画像検査装置のコンソールを管理することにより、実際に撮影ボタンを押下したオペレータを、動的にかつ簡便に切替えられるようになる。
また、オペレータ判定部46は、ユーザの資格を確認してオペレータの変更を通知することができるため、資格の適合性に従ったオペレータの切替えが可能になる。例えば、画像検査を行うことが認められているのは、放射線検査技師または医師である。したがって、看護師の資格を持つユーザは、オペレータとして特定されない。これにより、誤って看護師の資格を持つユーザが画像検査を行った、というような記録が作成されることが未然防止できる。
なお、アプリケーション制御部47が自動的にオペレータを切替える場合には、不適切なオペレータが選ばれる可能性が残っているため、放射線情報管理アプリケーションは、オペレータが切替えられた際に警告を行うことも有効である。警告の方法として、例えば、ブザーなどの音を鳴らす、オペレータを表示している部分の背景色を動的に切り替える、オペレータを表示している文字の色を変える、などの方法が考えられる。
アプリケーション制御部47が、このように放射線管理アプリケーションを制御することにより、撮影の度にオペレータの変更の操作(ログインやログアウト)を行う煩わしさをなくし、ユーザの負担を軽減するとともに、実際に誰が撮影(実施登録)を行ったかを、より適切に記録することが可能となる。
また、画像検査を行ったオペレータを複数登録することも可能である。この場合、アプリケーション制御部47は、オペレータ判定部46からENTER−REGIONのメッセージを通知されると、新たなオペレータとして特定されたユーザIDと、その時点で放射線管理アプリケーションが認識しているユーザIDとを比較する。ユーザIDが異なっている場合、アプリケーション制御部47は、通知されたユーザIDを、オペレータのユーザIDに追加すればよい。これにより、より実態に近い撮影者を記録して登録できるようになる。
次に、アプリケーションが読影レポート作成アプリケーションである場合について説明する。
読影レポート作成アプリケーションは、ユーザが、画像検査で撮影された画像を観察し、必要に応じてカルテ情報やその他の検査結果などの情報を参照しながら画像診断を行い、診断結果を読影レポートに入力する作業を、支援するためのアプリケーションである。
読影作業は、医師単独で行う場合もあるが、複数の医師が共同で行う場合もある。このような場合に備えて、読影レポート作成アプリケーションでは、一般に、5名程度の医師を入力する枠を用意している。しかしながら、実際に複数の医師の名前を入力するかどうかは、入力者に委ねられており、正しく記録されない場合も多い。
そこで、アプリケーション制御部47は、オペレータ判定部46からENTER−REGIONのメッセージを通知されると、オペレータとして特定されたユーザIDを、読影者に自動的に追加する。また、アプリケーション制御部47は、オペレータ判定部46からEXIT−REGIONのメッセージを通知されると、オペレータから除外されたユーザIDを、読影者から自動的に削除する。これにより、読影に関与した医師(ユーザ)を自動的に記録することができる。
また、読影レポート作成アプリケーションは、ユーザID毎のENTER−REGIONの通知時刻と、EXIT−REGIONの通知時刻と、検査ごとの読影開始時刻(読影リスト上で患者を選択した時刻)と、読影完了時刻(読影レポートを登録した時刻)と、に基づいて、それぞれのユーザの読影行為に対する作業時間を算出し、その作業時間に応じて寄与率を計算して記録することが可能となる。これにより、医師の読影に関する実際の稼働時間や読影作業への寄与率を、容易に把握することが可能になる。また、このようなより精密な記録を残すことにより、より現実に即した医師の稼働状況を把握することも可能となる。
さらに、アプリケーション制御部47は、オペレータ判定部46からEXIT−REGIONのメッセージを通知された場合、患者の個人情報保護の観点から、端末1にスクリーンセーバーを起動してもよいし、編集中のデータの消失を未然に防止するために、端末1にデータを自動的に一時保存させてもよい。
またさらに、アプリケーション制御部47は、編集中のデータある状態で、EXIT−REGIONのメッセージを通知された場合、オペレータから除外されたユーザIDと、読影レポート作成アプリケーションがオペレータとして認識しているユーザIDと、を比較する。そして、アプリケーション制御部47は、ユーザIDが同じ場合、自動的にスクリーンセーバーを解除してもよい。また、アプリケーション制御部47は、ユーザIDが異なっており、かつ、編集中のデータがあるにも関わらず、オペレータが読影レポート作成アプリケーションを終了させようとした場合、「編集中のデータがあります。アプリケーションを終了させますか」という確認ダイアログを表示してもよいし、「作業中のため終了できません」というエラーメッセージを表示してもよい。エラーメッセージを表示することにより、不可抗力的なデータ消失を未然防止することが可能となる。
続いて、アプリケーションが3D画像処理アプリケーションである場合について説明する。
3D画像処理アプリケーションは、2D画像をもとに、透視断面画像を作成するためのアプリケーションである。近年、画像診断機器の検出能力の拡大に伴い、1秒あたりのデータ収集回数が増加し、シンスライス化(画像のスライス厚が数mm以下)し、大量の画像データが生成可能となった。
画像診断機器によっては、2D画像の読影のほかに、3D画像を作成して読影したり、診断・測定したりすることが多くなってきている。このため、放射線検査技師が3D画像を作成する時間は、増加傾向の一途をたどっている。
3D画像を作成する作業は、放射線検査技師や医師が、検査の合間や残業中に行う場合があったため、作業時間を適切に把握することが難しかった。従来は、作業時間を記録するために、ノートに手書きで作業時間を記録したり、放射線情報管理アプリケーションに、3D画像の作成のための時間を記録させたりしている。しかしながら、上述の通り、オペレータが変わる度にログイン及びログアウトを行うことは現実的ではなく、適切な作業時間を把握することは困難であった。
そこで、アプリケーション制御部47は、オペレータ判定部46からENTER−REGIONのメッセージを通知されると、オペレータとして特定されたユーザIDを保持し、EXIT−REGIONのメッセージを通知されると、保持したユーザIDを含むログファイルを出力する。ログファイルには、例えば、保持したユーザIDと、3D画像の作成開始時刻(検査一覧から3D画像を作成する検査を選択した時刻)と、3D画像の作成完了時刻(3D画像を作成して保存した時刻)と、3D画像の対象患者IDと、3D画像処理した検査IDと、画像枚数などの情報と、が含まれる。
アプリケ−ション制御部47によるこのような制御により、ユーザ毎の作業工数データを簡便に入手することができる。また、このような作業工数データを記録することで、3D画像処理に関する作業ボリュームが明確になり、人員配置計画等に有効な情報として活用が可能になる。
次に、本実施形態に係る端末管理装置4のハードウェア構成について、図12を参照して説明する。図12は、端末管理装置4のハードウェア構成の一例を示す図である。図12に示すように、端末管理装置4は、処理回路401と、記憶回路402と、を備える。
処理回路401は、プログラムを記憶回路402から読み出し、実行することで各プログラムに対応する機能を実現するプロセッサである。本実施形態において、ユーザ位置特定部45、オペレータ判定部46、及びアプリケーション制御部47により行われる各処理は、コンピュータによって実行可能なプログラムの形態で記憶回路402に記憶されている。各構成の機能は、処理回路401が対応するプログラムを実行することにより実現される。図12における、ユーザ位置特定機能、オペレータ特定機能、及びアプリケーション制御機能は、それぞれユーザ位置特定部45、オペレータ判定部46、及びアプリケーション制御部47の機能に相当する。
処理回路401は、ユーザ位置特定部45、オペレータ判定部46、及びアプリケーション制御部47により行われる各処理を実現する単一のプロセッサにより構成されてもよいし、各機能を実現する複数の独立したプロセッサを組み合わせて構成されてもよい。
上記説明において用いた「プロセッサ」という文言は、例えば、CPU(Central Processing Unit)、GPU(Graphics Processing Unit)、或いは、特定用途向け集積回路(Application Specific Integrated Circuit:ASIC)、プログラマブル論理デバイス(例えば、単純プログラマブル論理デバイス(Simple Programmable Logic Device:SPLD)、複合プログラマブル論理デバイス(Complex Programmable Logic Device:SPLD)、及びフィールドプログラマブルゲートアレイ(Field Programmable Gate Array:FPGA))等の回路を意味する。
プロセッサは、記憶回路に保存されたプログラムを読み出し実行することで、機能を実現する。なお、記憶回路にプログラムを保存する代わりに、プロセッサの回路内にプログラムを直接組み込むように構成しても構わない。この場合、プロセッサは回路内に組み込まれたプログラムを読み出し実行することで機能を実現する。
記憶回路402は、ユーザIDテーブル41、移動履歴テーブル42、ユーザ情報テーブル43、及びアプリケーションテーブル44を記憶している。また、記憶回路402は、ユーザ位置特定部45、オペレータ判定部46、及びアプリケーション制御部47の機能を実現するためのプログラムを記憶している。
なお、本実施形態において、端末管理装置4は、図1に示すように、端末1とは別のコンピュータにより構成されてもよいし、端末1と同じコンピュータにより構成されてもよい。端末1と同じコンピュータにより端末管理装置4を構成する場合、処理回路401として端末1のCPUを利用し、記憶回路402として端末1のメモリやHDDなどを利用すればよい。
また、端末管理装置4は、1つのコンピュータにより構成されてもよいし、複数のコンピュータにより構成されてもよい。例えば、ユーザIDテーブル41、移動履歴テーブル42、ユーザ情報テーブル43、及びアプリケーション制御部47を医療システムのサーバ上に構成し、ユーザ位置特定部45、オペレータ判定部46、及びアプリケーション制御部47を端末1上に構成することなどが考えられる。
次に、以上説明した端末管理システムの動作の一例を説明する。以下では、端末管理装置4は、端末1と同一のコンピュータにより構成されているものとする。
医療用の端末1は、一般に、毎日起動及びシャットダウンを行われる。オペレータが端末1の電源を投入することにより、端末1は起動される。端末1が起動すると、初期化処理が実行され、ログイン画面が表示される。なお、医療用の端末1は、数日以上連続稼働させることも可能である。
端末1にログイン画面が表示されると、オペレータは、端末1のOSが提供する認証手段を利用してログイン処理を実行する。ログインに成功すると、デスクトップ画面が表示される。端末1が自動ログイン機能を備える場合には、電源投入後、自動的に(すなわち、明示的なログイン処理を行わずに)デスクトップ画面が表示される。
また、ログインが成功すると、ユーザ位置特定部45及びオペレータ判定部46が自動的に起動する。これは、ユーザ位置特定部45及びオペレータ判定部46に対応するプログラムをスタートアップに登録しておくことに可能となる。これにより、端末1のログイン後、オペレータの特定及び通知が自動的に開始される。
端末1のオペレータは、端末1のデスクトップ上のアイコンやスタートメニューから、利用したアプリケーションを選択して起動する。起動したアプリケーションは、OSのユーザ認証結果からユーザ情報を取得したり、固有のユーザ認証機能によりオペレータの認証を実行したりする。その後、アプリケーションは、端末管理装置4によるオペレータの検知結果に従って、アプリケーション制御部47により制御される。なお、アプリケーション制御部47の機能は、各アプリケーションに組み込まれていてもよい。
業務の終了後、オペレータが端末1をシャットダウンすることにより、端末1の電源が切断される。端末1を連続稼働させる場合には、オペレータは、端末1をシャットダウンせず、アプリケーションを終了させ、OSが提供するログアウト処理を実行すればよい。
以上説明した通り、本実施形態に係る端末管理装置4は、端末1からユーザまでの距離の履歴データに基づいて、端末1のオペレータを精度よく特定することができる。また、オペレータの検知結果に応じて、端末1上で動作する各アプリケーションを制御することができる。アプリケーションの特性に応じて制御方法を変更することにより、端末管理装置4は、端末1による業務効率を向上させたり、エビデンスとして記録されるオペレータの精度を向上させたりすることができる。
(第2実施形態)
第2実施形態に係る端末システムについて、図13を参照して説明する。図13は、本実施形態に係る端末システムの一例を示す図である。図13に示すように、本実施形態に係る端末管理装置4は、データ出力部48を備える。他の構成は、第1実施形態と同様である。
データ出力部48は、移動履歴テーブル42に格納された履歴データを読み出し、所定のデータ形式に変換して出力する。データ形式は、例えば、CSV形式であるが、これに限られない。データ出力部48が出力したデータは、例えば、医療システムのサーバに保存される。
医療システムのユーザは、データ出力部48が出力したデータを分析することにより、医療システムに含まれる各端末1の稼働率、利用者数、及びオペレータ毎の作業時間などを分析することができる。これらの分析結果は、医療システムに導入した端末1の有効性を評価するための基礎データとして利用したり、医療システムの設備増強を提案するための基礎データとして利用したりすることができる。
なお、データ出力部48は、ユーザIDテーブル41、ユーザ情報テーブル43、及びアプリケーションテーブル44に格納された各種のデータや、無線受信機3から受信したデータを、所定のデータ形式で出力することも可能である。
(第3実施形態)
第3実施形態に係る端末システムについて、図14を参照して説明する。図14は、本実施形態に係る端末システムの一例を示す図である。図14に示すように、本実施形態に係る端末管理装置4は、動作ログ出力部49を備える。他の構成は、第1実施形態と同様である。
動作ログ出力部49は、端末1からアプリケーションの動作ログを取得し、所定のデータ形式に変換して出力する。動作ログには、現在時刻、オペレータとして特定されたユーザID、アプリケーションID、アプリケーションによる処理の開始時刻及び終了時刻、及びアプリケーションの処理対象となる患者のIDなどが含まれる。データ形式は、例えば、CSV形式であるが、これに限られない。データ出力部48が出力したデータは、例えば、医療システムのサーバに保存される。
医療システムのユーザは、動作ログ出力部49が出力したデータを分析することにより、アプリケーション毎の各オペレータの作業時間、及びアプリケーション毎の各処理の作業時間などを分析することができる。これらの分析結果は、医療システムに導入したアプリケーションの有効性を評価するための基礎データとして利用したり、医療システムの設備増強を提案するための基礎データとして利用したりすることができる。
なお、本発明は上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素を適宜組み合わせることによって種々の発明を形成できる。また例えば、各実施形態に示される全構成要素からいくつかの構成要素を削除した構成も考えられる。さらに、異なる実施形態に記載した構成要素を適宜組み合わせてもよい。