JP7413936B2 - 情報処理装置、見守りシステム、および制御プログラム - Google Patents

Description

本発明は情報処理装置、見守りシステム、および制御プログラムに関する。特に、本発明は、被介護者へのケアを行う情報処理装置、システム、および制御プログラムに関する。

患者に装着されたモニター装置から、体温、血圧などの生体情報を常時モニターし、アラーム状態となったときに、その生体情報を、通信回線を介してその患者を担当する遠隔地にいる医療スタッフに携帯情報端末を通じて、配信する生体情報配信システムが知られている（特許文献１）。この整体情報配信システムでは、常時対応するために、それぞれの患者に対して、複数の医療スタッフを担当者として割り振り、アラーム状態となったときの勤務スケジュールに応じて、複数のスタッフに、生態情報を配信している。

また、病院や老人福祉施設などの施設において、被介護者が、歩行中に転倒したり、ベッドから転落して怪我をしたりするおそれがある。そのため、被介護者等がこのような状態になったときに看護師や介護士がすぐに駆けつけられるようにするために、被介護者等の状態を常時検知するためのシステムの開発が進められている。このようなシステムでは、被介護者の転倒や転落等の異常状態を検知した場合に、担当する複数のスタッフに同時に通知をする。このような場合に、スタッフへの通知が頻繁になり、スタッフの精神的負荷や肉体的負荷が増加するという問題がある。このような課題を解決するため、特許文献２に開示されたシステムでは、被介護者に何らかの異常を検知した場合、複数のスタッフへ一斉通知するのではなく、その通知を、一旦、管理者に情報を集約し、被介護者のライブ映像を参照しながら駆けつけ対応が必要か否かを判断した上で、必要な場合に、担当させるスタッフを決定して派遣させるシステムが開示されている。

特開２００３－３１９９１３号公報 国際公開第２０１９／２１６０４５号

しかしながら、特許文献１に開示された生態情報配信システムでは、担当する患者数が多いような場合や、アラームの判定精度が低く誤判定が多いような場合には、医療スタッフに多くの通知がなされ、他の業務を行っているような場合に中断せざるを得ない等の状況により負荷が大きいという問題がある。このような問題に対して、特許文献２のシステムのように、管理者に情報を一旦集約し、対応可否を判断してから、スタッフへの指示を行うことで、アラーム等のイベント発生時に、担当するスタッフのみ送信することで、スタッフ個人への通知数は大きく減少するので、スタッフの負担は低減できる。しかしながら、管理者に全ての通知が集中するため、今度は管理者の高負担が問題となる。

本発明は、上記事情に鑑みてなされたものであり、ケアスタッフへの不要な通知を防止することでケアスタッフの負荷を軽減するとともに、管理者に過度に負荷が集中することを防止できる、情報処理装置、見守りシステム、および制御プログラムを提供することを目的とする。

本発明の上記目的は、下記の手段によって達成される。

（１）ケア対象者に関するイベント毎に、所定条件に基づいて、前記ケア対象者に対応するスタッフが使用するスタッフ端末、および前記スタッフへの指示を行う情報管理者が使用する情報管理者端末のうちのどちらに通知するかを判定する通知先判定部と、
前記通知先判定部が判定した通知先に、通知する通知部と、
を備える、情報処理装置。

（２）前記通知先判定部は、前記所定条件として、前記イベントの種類が、予め設定された特定のイベントである場合には、通知先として、前記情報管理者端末を選択し、
前記特定のイベント以外の場合には、通知先として、前記スタッフ端末を選択する、上記（１）に記載の情報処理装置。

（３）前記通知先判定部は、前記所定条件として、イベントの判定精度が所定値以上の場合に、通知先として前記スタッフ端末を選択し、
前記判定精度が前記所定値以上でない場合に、通知先として前記情報管理者端末を選択する、上記（１）に記載の情報処理装置。

（４）前記通知先判定部は、イベントの前記判定精度にかかわらず、前記イベントの種類が、予め設定された特定のイベントである場合には、通知先として、前記情報管理者端末を選択する、上記（３）に記載の情報処理装置。

（５）前記ケア対象者の状態情報、判定した前記イベントの種類、および前記ケア対象者を特定する個人ＩＤを含むイベント情報の履歴を記憶する記憶部を備え、
前記状態情報には、前記ケア対象者に対応付けられた観察領域における該ケア対象者の動きを検出する検出部からの出力が含まれ、
前記通知先判定部は、前記イベントの判定精度として、前記ケア対象者自身の過去の行動データと、今回の行動データとの類似度を用いる、上記（３）、または上記（４）に記載の情報処理装置。

（６）前記特定のイベントは、緊急な対応が必要なイベントである、上記（２）、または上記（４）に記載の情報処理装置。

（７）取得したケア対象者に関する状態情報に基づいて、前記ケア対象者に関するイベントの発生有無を判定するイベント判定部を、さらに、備え、
前記通知先判定部は、前記イベント判定部が判定したイベント毎に、前記スタッフ端末および前記情報管理者端末のうちのどちらに通知するかの判定を行う、上記（１）から上記（６）のいずれかに記載の情報処理装置。

（８）前記スタッフは複数であり、
前記通知部は、
前記通知先として前記スタッフ端末が選択された場合、複数の前記スタッフの前記スタッフ端末に対して前記イベントを通知し、
前記通知先として前記情報管理者端末が選択された場合、前記情報管理者端末に対して前記イベントを通知し、その後、
該情報管理者端末からの前記複数の前記スタッフの中から、前記ケア対象者への対応を行う前記スタッフの選択する振り分け指示を受け付け、受け付けた前記指示で選択された前記スタッフに向けて、前記イベントを通知する、上記（１）から上記（７）のいずれかに記載の情報処理装置。

（９）ケア対象者に対応付けられた観察領域における該ケア対象者の動きを検出する検出部と、
上記（１）から上記（８）のいずれかに記載の情報処理装置と、
１つ以上のスタッフ端末と、
情報管理者端末と、を備える、見守りシステム。

（１０）ケア対象者に関するイベント毎の通知先として、所定条件に基づき、前記ケア対象者に対応するスタッフが使用するスタッフ端末、および前記スタッフへの指示を行う情報管理者が使用する情報管理者端末のうちのどちらかに通知するかを判定するステップ（ａ）と、
前記ステップ（ａ）で選択した通知先に、通知するステップ（ｂ）と、を含む処理を、
情報処理装置を制御するコンピューターに実行させるための制御プログラム。

本発明によれば、情報処理装置は、ケア対象者に関するイベント毎に所定条件に基づいて、前記ケア対象者へ対応するスタッフに使用されるスタッフ端末、および前記スタッフへの指示を行う情報管理者が使用する情報管理者端末のうちのどちらかを通知先に設定する通知先判定部と、前記通知先判定部が設定した通知先に、通知する通信部と、を備える。これにより、ケアスタッフへの不要な通知を防止することでケアスタッフの負荷を軽減するとともに、管理者に過度に負荷が集中することを防止できる。

第１の実施形態に係る見守りシステムの全体構成を示す図である。 ケア対象者の部屋に設置された検出部の例を示す図である。 検出部の概略構成を示すブロック図である。 サーバーの概略構成を示すブロック図である。 情報管理者端末の概略構成を示すブロック図である。 スタッフ端末の概略構成を示すブロック図である。 第１の実施形態におけるイベント通知処理を示すフローチャートである。 通知先判定処理（ステップＳ１３０）を示すサブルーチンフローチャートである。 記憶部に記憶されるイベントリストの例である。 撮影画像に基づいて行う、ケア対象者の移動軌跡による行動情報の解析を示す模式図である。 図１０Ａの後の状態を示す模式図である。 イベントの確認用の操作画面の例である。 情報管理者端末に表示したイベント確認用の操作画面の例である。 第２の実施形態における通知先判定処理（ステップＳ１３０）を示すサブルーチンフローチャートである。

以下、添付した図面を参照して、本発明の実施形態を説明する。なお、図面の説明において同一の要素には同一の符号を付し、重複する説明を省略する。また、図面の寸法比率は、説明の都合上誇張されており、実際の比率とは異なる場合がある。

（全体構成）
図１は第１の実施形態に係る本実施形態に係るシステム（以下、見守りシステムという１）の全体構成を示す図であり、図２はケア対象者７０の部屋のベッド周辺に設置された検出部１０の例を示す図である。

図１に示すように、見守りシステム１は、複数の検出部１０、サーバー２０、情報管理者端末３０、および１つ以上のケアスタッフが勤務中に携帯するスタッフ端末４０（ケアスタッフ端末ともいう）を備える。これらは、有線や無線によって、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、電話網またはデータ通信網等のネットワーク５０を介して、相互に通信可能に接続される。ネットワーク５０は、通信信号を中継するリピーター、ブリッジ、ルーターまたはクロスコネクト等の中継機を備えてもよい。

見守りシステム１は、ケア対象者７０（対象者、または見守り対象者）に応じて適宜な場所に配設される。ケア対象者７０は、例えば、病気や怪我等によって看護を必要とする患者、高齢による身体能力の低下等によって介護を必要とする被介護者、または一人暮らしの独居者等である。特に、早期発見および早期対処を可能にする観点から、ケア対象者７０は、例えば異常状態等の所定の不都合な事象がその者に生じた場合に、その発見を必要としている者であり得る。このため、見守りシステム１は、ケア対象者７０の種類に応じて、病院、老人福祉施設および住戸等の建物に好適に配設される。図１に示す例では、見守りシステム１は、複数のケア対象者７０が入居する複数の部屋（居室）やケアステーション（ナースステーションともいう）を含む複数の部屋を備える施設に配置されている。また、ケア記録には、これらのケア対象者へのスタッフ（介護者、看護師等）によるケアを記録した、介護記録シート、看護記録シート（カルテ、生活記録）、診断カルテが含
まれる。

検出部１０は、センサーボックスとも称され、ケア対象者７０の観察領域であるそれぞれの居室に配置される。図１に示す例では、４つの検出部１０がケア対象者７０であるＡさん、Ｂさん、ＣさんおよびＤさんの居室にそれぞれ配置されている。図２に示すように、検出部１０の観察領域にはベッド６０が含まれる。ケア対象者７０に対して看護または介護等の対応（ケア）を行うケアスタッフ８０（以下、単にスタッフ８０ともいう）は、それぞれ携帯端末であるスタッフ端末４０を持ち歩いている。ただし、見守りシステム１が備える各構成の位置や個数等は、図１に示す例に限定されない。例えば、サーバー２０は、ケアステーションに配置されなくてもよく、ネットワーク５０に接続されている外部のサーバーユニットであってもよい。

（状態情報、および判定部）
本実施形態においては、サーバー２０単独で、または、サーバー２０が検出部１０と協働することで「情報処理装置」として機能する。また、本実施形態においては、情報処理装置は、取得部により、検出部１０、または情報管理者端末３０等の他の端末（ＰＣ：（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ））からケア対象者に関する状態情報を取得する。取得した状態情報は、情報処理装置の記憶部、例えば、サーバー２０の記憶部（後述のデータベース２３）に記憶される。

「状態情報」には種種の情報が含まれる。例えば検出部１０から取得する状態情報には、主に以下の３種類がある。第１、第２の種類としては、検出部１０のセンサーが検出した「検出信号」そのもの、または検出信号により判定した「イベント」である。第３の種類としては、他の端末から取得する状態情報には、ケア対象者に関する「ケア記録」である。第１の種類の「検出信号」としては、後述するカメラによる撮影画像、ケアコール（ナースコール）のコール信号、体動センサーによる体動信号が含まれる。第２の種類の「イベント」は、検出部１０の制御部がカメラの撮影画像を画像処理することにより判定したイベント（仮）である。第３の種類の「ケア記録」は、端末（ＰＣ）を通して取得したものであり、端末へスタッフ等がキー入力したデータだけでなく、手書きされた紙のケア記録シートをスキャンした読取画像データをＯＣＲでテキスト化したデータを含んでもよい。

サーバー２０は、状態情報からイベント（事故等の突発的な事象、またはケアの対応を開始するためのアクショントリガー）の発生有無を判定する「イベント判定部２１１」として機能する。状態情報が、第１の種類（検出信号）である場合には、イベント判定部２１１は、撮影画像から、ケア対象者の起床、離床、等のイベントの発生を判定したり、ケアコール部のボタンが押されたことによりイベント（ケアコール）の発生を判定したりする。また、状態情報が第２の種類（イベント（仮））であれば、イベント判定部２１１が用いる追認・修正用の判定アルゴリズムにより、後段の判断を行い、これにより検出部１０から取得したイベント（仮）をそのまま本採用したり（追認）、他のイベントに修正したりする。

状態情報が、第３の種類（ケア記録）であれば、ケア記録の変化によりイベントを判定する。例えば、あるケア対象者の長期間の記録から、排尿および排便の量または頻度や、食事および飲料の摂取量の推移の変化を検出し、それまでの量、頻度、摂取量から所定以上の割合の変化が所定期間内の短期間で生じた場合には、サーバー２０は、イベント（アラート）を判定する。この場合、イベントを判定するタイミングは、定期的（１日毎）に判定するようにしてもよく、手書きのケア記録シートをスキャンして、データ化したタイミングで行うようにしてもよい。

（検出部１０）
図３は検出部１０の概略構成を示すブロック図である。同図に示すように、検出部１０は、制御部１１、通信部１２、カメラ１３、ケアコール部１４、および音声入出力部１５を備え、これらはバスによって、相互に接続されている。検出部１０は、ケア対象者７０の状態情報を検出する。状態情報としては、上述のように例えば、カメラ１３からの撮影画像や、体動センサーによる検出信号である。

制御部１１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、およびＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、等のメモリにより構成され、プログラムにしたがって検出部１０の各部の制御および演算処理を行う。なお、制御部１１は、メモリとして、さらにＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）を備えてもよい。

通信部１２は、ネットワーク５０を介して、例えば、サーバー２０、情報管理者端末３０またはスタッフ端末４０等の、他の装置と通信するためのインターフェース回路（例えばＬＡＮカード、無線通信回路等）である。

カメラ１３は、例えば居室の天井、または壁の上部に配置され、観察領域として真下にあるケア対象者７０のベッド６０を撮影し、撮影画像（画像データ）を出力する。この撮影画像には、静止画および動画を含む。カメラ１３は近赤外線カメラであるが、これに換えて可視光カメラを用いてもよく、これらを併用してもよい。

ケアコール部１４は、押しボタン式のスイッチを含み、スイッチがケア対象者７０によって押されることでケアコールを検出する。押しボタン式のスイッチに換えて、音声マイクによりケアコールを検出してもよい。ケアコール部１４のスイッチが押された場合、すなわち、ケアコールを検出した場合、制御部１１は、通信部１２およびネットワーク５０を介して、ケアコールがあった旨の通知をサーバー２０等に送信する。

音声入出力部１５は、例えばスピーカーとマイクであり、通信部１２を介して情報管理者端末３０との間で音声信号を送受信することで音声通話を可能とする。なお、音声入出力部１５は検出部１０の外部装置として、通信部１２を介して検出部１０に接続されてもよい。

また、検出部１０は、ベッド６０に対してマイクロ波を送受信してケア対象者７０の体動（例えば呼吸動）によって生じたマイクロ波のドップラシフトを検出するドップラシフト方式の体動センサーを、さらに備えてもよい。この体動センサーにより、ケア対象者７０の呼吸動作に伴う胸部の体動（胸部の上下動）を検出する。その胸部の体動における周期の乱れや予め設定された閾値以下である胸部の体動における振幅を検知すると、微体動異常（例えば心停止に起因する）であると判定する。この微体動異常の判定は、検出部１０側で行ってもよく、信号のみをサーバー２０に送ることで、サーバー２０側で行ってもよい。

（画像処理によるイベントの判定）
本実施形態においては、ケア対象者７０に関する検出部１０が検知した状態の変化であって、起床、離床、転倒、微体動異常、などのスタッフ８０に発報（報知）を行うべき事象をイベントと称する。またこのイベントには、ケアコール部１４によるケアコールを含む。検出部１０は、生じたイベントの情報をサーバー２０に送信する。

制御部１１は、カメラ１３が撮影した撮影画像から、ケア対象者７０の行動を検知する。この検知する行動には、ベッド６０から起き上がる「起床」、起床に続いてベッド６０から離れる「離床」、ベッド６０から転落する「転落」、および床面等に転倒する「転倒」が含まれる。

制御部１１は、複数の撮影画像（動画像）から画像のシルエット（以下、「人シルエット」と称する）を検出する。人シルエットは、例えば、撮影時刻が前後する画像を差分する時間差分により差分が相対的に大きい画素の範囲を抽出することで検出され得る。人シルエットは、撮影画像から背景画像を差分する背景差分法により検出されてもよい。

ケア対象者７０の画像の輪郭が外接する矩形内の領域は、ケア対象者７０の画像の輪郭が外接する人矩形（後述の図１０Ａ参照）として検出され得る。また、人物の全体像から得る人シルエットとともに、またはこれに換えて、ケア対象者７０の頭部の画像のシルエット（以下、「頭部シルエット」と称する）を検出してもよい。ケア対象者７０の頭部の画像の輪郭が外接する矩形内の領域は、撮影画像におけるケア対象者７０の頭部の画像の輪郭に外接する頭部矩形として検出され得る。

起床、離床、転落、転倒の検知は、検出した人シルエットからケア対象者７０の姿勢（例えば立位、座位、横臥等）、およびベッド６０等の居室内の設置物との相対的な位置から起床、「離床」および「転倒（転落）」の別を検知する。例えば、「起床」は、予め設定された、ベッド６０の四隅を頂点とする、上方視の四角形の任意の辺を人シルエットが横切る幅が増加して２０ｃｍ以上となったことにより認識され得る。また、例えば、「離床」は、人シルエットの、当該四角形の内部に対する外部の面積の割合が増加して８０％以上となったことにより認識され得る。また、座位を判定する場合に、さらに座っている位置が、ベッド６０の辺の近傍に腰掛けた座位状態（端座姿勢時）であるかを認識するようにしてもよい。検出部１０の制御部１１は、このような、起床、離床、転落等のいずれかの種類の行動（イベント）を検知した場合、その行動が発生した旨の通知をサーバー２０等に送信する。

このようなイベントの検知は、制御部１１のＣＰＵが処理するプログラムにより行ってもよく、組み込み型の処理回路により行うようにしてもよい。この場合、検知したイベント（仮）は、上述のように第２の種類の状態情報として、サーバー２０に送信される。なお、これに限られずサーバー２０側でこれらの検知の全部またはほとんどの処理を行うようにし、制御部１１ではサーバー２０への撮影画像（上述の第１の種類の状態情報）の送信のみを行うようにしてもよい。制御部１１は、いずれかの種類の行動を検知した場合、その行動が発生した旨の通知をサーバー２０等に送信する。この場合、検出部１０と、サーバー２０が協働することで情報処理装置として機能し、検出部１０自体が取得した状態情報によりイベントを判定する「イベント判定部」として機能する。

ここで、スタッフ８０の業務が、ケア対象者７０に対する介護業務である場合に、所定のイベントに関する対応内容について説明する。所定のイベントとは、ケア対象者７０に関するイベントであり、少なくとも起床、離床、転落、転倒が含まれる。「起床」を判定し、その判定が所定時間内（施設で予め設定された起床時刻（例えば午前７～８時））であれば、モーニングケアを行う。このモーニングケアには、洗顔、歯磨き介助、義歯装着、着替え介助等が含まれる。また、「離床」のイベントであれば、車椅子移乗、歩行介助が必要となる場合がある。また、検出部１０が判定したイベント以外の定期的（定時）なイベント（ケアイベント）として、飲料、および食事介助、排泄介助、車椅子移乗、歩行介助、体位変換（褥瘡予防）、入浴介助がある。これらの定期的なケアイベントは、ケアコール部１４等により、定時になるとアラートを発生させるようにしてもよい。これらの所定の不定期イベント、および定期イベントに対して、スタッフ８０が対応した場合、ケアイベントの内容に応じて、記録が行われ、ケア履歴（履歴情報）として蓄積される。このケア履歴は、例えば、スタッフ端末４０、または情報管理者端末３０を通じて、主に対応したスタッフ８０により入力される。

（サーバー２０）
図４は、サーバー２０の概略構成を示すブロック図である。制御部２１、通信部２２、およびデータベース２３を備える。このサーバー２０は、ケア対象者７０用の居室と同じ建物内に設けられてもよく、遠隔地に設けられてネットワークを介して接続可能であってもよい。例えば、サーバー２０は、インターネット等のネットワーク上に配置された複数のサーバーによって仮想的に構築されるクラウドサーバーであってもよい。各構成は、バスによって、相互に通信可能に接続されている。

（制御部２１）
制御部２１は、検出部１０の制御部１１と同様の構成として、ＣＰＵ、ＲＡＭ、ＲＯＭ等を備える。制御部２１は上述の「イベント判定部２１１」に加えて、さらに「通知先判定部２１２」として機能する。

イベント判定部２１１は、上述のように第１の種類の状態情報（検出信号）を取得した場合にはこの状態情報からイベントの発生有無を判定する。第２の種類の状態情報（検出部１０が検知したイベント（仮））であれば、このイベント（仮）に対して、追認・修正用の判定アルゴリズムにより、スタッフ８０に伝えるべき、内容を判断する。例えば、検出部１０のイベント（仮）の検知結果が起床である場合に、判定アルゴリズムによりこれを、転倒のイベントに修正する。第３の種類の状態情報（ケア記録）であれば、この状態情報から、イベントの発生有無を判定する。なお、判定アルゴリズムを含むイベント判定部２１１は、ケア対象者７０の過去の行動データが反映されたものであり、後述するＦＢ結果を反映することで、修正、改善される。

また、イベント判定部２１１は、イベントの判定精度を出力する。例えば、イベント判定部２１１は、学習済みモデルを用いて、イベントを判定する際に、その判定精度（確度）を出力する。この学習済みモデルは、以下に説明する行動データ（移動軌跡）とイベント種類を正解ラベルとした、多数の学習サンプルデータを用いて、教師あり学習により機械学習したものである。また、イベント判定部２１１は別の手法として、後述するように、ケア対象者７０の過去の行動データと、現在（リアルタイム）の行動データを比較し、その類似度により、判定精度を算出する。

また、制御部２１は、イベント判定部２１１が判定したイベントの種類、イベントＩＤ、ケア対象者の個人ＩＤ（氏名、ＩＤ）を含むイベント情報を生成する。通知先判定部２１２は、ケア対象者に関するイベント毎に、所定条件に基づいて、スタッフ端末４０、および情報管理者端末３０のうちのどちらかを通知先に設定する。所定条件としては、例えば、イベントの判定精度（確度）、または、イベントが予め設定された特定の種類か否かである。特定の種類のイベントは、ケア対象者７０への緊急な対応が必要なイベントである。例えば、ケア対象者７０の身体の危険度が高いイベントである。この特定の種類の設定は、情報管理者９０等の管理者により、設定できるようにしてもよい。

（通信部２２）
通信部２２は、スタッフ８０、または情報管理者９０にイベントの通知を行う通知部として機能する。また、通信部２２は、検出部１０等から状態情報を取得する。この通信部２２は、イーサネット（登録商標）等の規格による有線通信のネットワークインターフェースや、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩＥＥＥ８０２．１１等の規格による無線通信のインターフェース等の各種ローカル接続向けのインターフェースであり、ネットワーク５０に接続した各端末との通信を行う。

（データベース２３）
データベース２３は、ケア対象者リスト、スタッフリスト、イベントリスト、およびケア記録が記録される。ケア対象者リスト、およびスタッフリストは、ケア対象者７０、およびスタッフ８０に関する、個人ＩＤ（氏名、番号）、部屋番号、スタッフ名、所属ユニット等が含まれる。また、イベントリスト（後述の図９参照）には、イベント情報、対応状況、ＦＢ結果（フィードバック結果）が含まれる。なお、データベース２３は、サーバー２０とは、別体で構成されてもよい。例えば、データベース２３のみが、クラウト上に配置されたファイルサーバーであってもよい。

（情報管理者端末３０）
図５は、情報管理者端末３０の概略構成を示すブロック図である。情報管理者端末３０は、いわゆるＰＣであり、制御部３１、通信部３２、表示部３３、入力部３４、および音声入出力部３５を備え、これらはバスにより相互に接続される。制御部３１は、検出部１０の制御部１１と同様の構成として、ＣＰＵ、ＲＡＭ、ＲＯＭ等を備える。

通信部３２は、イーサネット（登録商標）等の規格による有線通信のネットワークインターフェースや、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩＥＥＥ８０２．１１等の規格による無線通信のインターフェース等の各種ローカル接続向けのインターフェースであり、ネットワーク５０に接続した各端末との通信を行う。

表示部３３は、例えば液晶ディスプレイであり、各種情報を表示する。表示部３３は、例えば、検出部１０による撮影画像を表示する。

入力部３４は、キーボード、テンキー、マウス等を備えており、各種情報の入力を行う。

音声入出力部３５は、例えばスピーカーとマイクを備えたヘッドセットである。

本実施形態では、情報管理者端末３０は、情報管理者９０用の端末として用いられ、情報管理者９０へ施設内の各種情報を表示し、指示を受け付ける。また、通信部３２を介して検出部１０またはスタッフ端末４０との間で音声信号を送受信することでスタッフ８０等との音声通話を可能にする。ここで、情報管理者９０は、複数のスタッフ８０を統括する管理者である。情報管理者９０は１つの施設だけでなく、複数の施設で働くスタッフ８０を統括的に管理してもよい。なお、情報管理者９０は、ケアディレクターとも呼ばれ得る。情報管理者９０は、情報管理者端末３０を通じて、一旦集約した検出部１０等からのイベント等の状態情報を確認し、状態情報に関する判定を行う。そして判定結果により、このイベントへの対応をスタッフ８０に振り分けたり、具体的な指示を行ったりする。

また、スタッフ８０または技術スタッフ等は、情報管理者端末３０を通じて、検出部１０を各部屋（居室）に取り付けたときに、部屋番号と検出部１０の対応付けをしたり、ベッド６０等の居室内の設置物の位置情報、すなわち、天井のカメラ１３による上方視の輪郭情報の校正、指定を行ったりする。また、入院または入居しているケア対象者７０の名前、ＩＤ番号等の識別情報と、各部屋番号との対応付けも行う。

（スタッフ端末４０）
図６は、スタッフ端末４０の概略構成を示すブロック図である。スタッフ端末４０は、制御部４１、無線通信部４２、表示部４３、入力部４４、および音声入出力部４５を備え、これらはバスにより相互に接続される。制御部４１は、検出部１０の制御部１１と同様の構成として、ＣＰＵ、ＲＡＭ、ＲＯＭ等を備える。無線通信部４２により、Ｗｉ－Ｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の規格を用いた無線通信が可能であり、アクセスポイント５１を経由して、または直接的に各装置と無線通信する。表示部４３、および入力部４４は、タッチパネルであり、液晶等で構成される表示部４３の表示面に、入力部４４としてのタッチセンサーを重畳させたものである。表示部４３、入力部４４によって、スタッフ８０に対して、イベントリストに含まれる複数のイベントを一覧表示した各種の操作画面を表示したり、情報管理者９０からの指示を表示したり、操作画面を通じて各種の操作を受け付けたりする。音声入出力部４５は、例えばスピーカーとマイクであり、無線通信部４２を介して他のスタッフ端末４０との間でスタッフ８０による音声通話を可能にする。スタッフ端末４０は、例えば、タブレット型コンピューター、スマートフォンまたは携帯電話等の、持ち運び可能な通信端末機器によって構成できる。

スタッフ８０は、業務開始時に、割り当てられたスタッフ端末４０を通じて、ログイン認証処理を行う。スタッフ８０は、スタッフ端末４０のタッチパネル（表示部４３、入力部４４）を通じて、スタッフＩＤ、パスワードを入力し、これをサーバー２０に送信する。サーバー２０は、データベース２３に記憶している認証情報を突き合わせ、スタッフ８０の権限に応じた認証結果をスタッフ端末４０に送信することで、ログイン認証が終了する。

スタッフ８０それぞれは、スタッフユニット（担当グループ）に属する。ここでいう、スタッフユニットとは、施設内の同じフロア等、共通するエリアに居る複数の被介護者が所属する被介護者ユニット、およびこれらの被介護者ユニットを担当する複数のスタッフが所属するグループである。例えば、介護施設の２Ｆ東棟の被介護者ユニットに属する複数のケア対象者７０（被介護者）を、１つのスタッフユニットに所属する複数のスタッフで分担して、２４ｈのケアを行う。この場合、２Ｆ東棟の被介護者ユニットで、ケア対象者７０に関するなんらかのイベントが検出された場合、後述するように、この被介護者ユニットを担当するスタッフユニットに属する（ログイン中の）スタッフ全員のスタッフ端末へ、イベント情報が通知される。これらの被介護者ユニット、スタッフユニットの名簿は、対象者リスト、およびスタッフリスト（図４参照）にそれぞれ登録されている。なお、大規模な施設においては、複数の情報管理者９０により振り分け処理を分担してもよい。この場合、スタッフユニット毎に、担当する情報管理者９０が紐付けられる。

（第１の実施形態におけるイベント通知処理）
図７は、見守りシステムのイベントへの対応処理を示すフローチャートである。上述のように状態情報には、検出部１０からの「検出信号」（第１の種類）そのもの、検出部１０で判定したイベント（第２の種類）、およびケア対象者に関する「ケア記録」（第３の種類）が含まれるが、以下においては、状態情報として、検出部１０が判定したイベント（第２の種類）を用いる場合を例として説明する。ここでのイベントは、上述のように検出部１０のカメラ１３からの撮影画像、または、ケアコール部１４からのコール信号により検知した、起床、離床、転倒、ケアコール、等のイベントである。

（ステップＳ１１０、Ｓ１２０）
検出部１０は、観察領域におけるケア対象者７０の動きからイベントを検知する。サーバー２０の通信部２２は検出部１０からイベントの情報を取得する。これにより、イベント判定部２１１としての制御部２１は、通知が必要なイベントが発生したと判定し（Ｓ２０：ＹＥＳ）処理をステップＳ１３０に進める。

図９は、データベース２３に記憶されるイベントリスト（２３１～２３３）の例である。イベントリストに含まれるイベントには、上述のように起床、離床、転落、転倒、およびケアコールが含まれる。検知された、最新のイベントは、イベントリストの最後に追加される。各イベントには、「イベント情報」、「情報管理者指示情報」（以下、単に指示情報ともいう）、および「対応状況」のデータが含まれる。イベント情報には、自動的に付与される主キーとなるイベントＩＤ、部屋番号、対象者、イベント種類、発生日時（時刻）、画像データ、および対応状況の情報が含まれる。イベント情報に含まれる状態情報としての画像データ（撮影画像ｉ（以下、単に画像ｉともいう））は、ステップＳ１２０で送信された、イベントの発生時に検出部１０により撮影して得られた静止画、または動画のデータであり、イベント判定のもとになった状態情報である。例えば、イベント発生時刻（判定時刻）を含む前後十数秒の動画のデータである。「情報管理者指示情報」は、情報管理者９０による指示内容であり、情報管理者９０を特定する管理者ＩＤ、振り分け指示としての情報管理者９０により担当として振り分けられた（指名された）スタッフの情報が含まれる。なお、この指示情報には、情報管理者９０からの指示（後述の図１２の領域ａ３５参照）を含ませてもよい。「対応状況」にステイタス、対応スタッフ、および対応日時（時刻）が含まれる。対応スタッフは、振り分けられたスタッフ、または率先することで自らが対応することになったスタッフである。情報管理者指示情報、および対応状況については後述する。

（ステップＳ１３０）
ここでは、サーバー２０の制御部２１は、イベント毎に通知先判定処理を実行する。図８は、通知先判定処理（ステップＳ１３０）を示すサブルーチンフローチャートである。

（ステップＳ３１０）
図８のステップＳ３１０では、通知先判定部２１２は、ステップＳ２０で更新されたデータベース２３のイベントリストから、通知先判定処理を行う対象のイベントに関するイベント情報を取得する。このイベント情報には、上述のようにケア対象者７０を撮影した画像ｉが含まれる。

（ステップＳ３１１、Ｓ３１２）
イベント判定部２１１は、イベントの判定精度を算出する。判定精度は、サーバー２０のイベント判定部２１１が学習済みモデルを用いた判定処理を行う場合に、判定出力とともに出力される判定精度（確度）を用いてもよい。また、別な算出手法として、以下に説明するように、今回のケア対象者７０の行動データと、過去の行動データとの比較により算出するようにしてもよい。

（判定精度）
図１０Ａは、図２に示すカメラ１３による画像ｉの例を説明するための説明図である。画像ｉには、ケア対象者７０、ならびに、ベッド６０および扉６５を含む複数の物体（人以外の物体）が含まれている。イベント判定部２１１は、画像ｉから、人矩形７１０と物体領域６１０を検出する。人矩形７１０は、画像ｉにおけるケア対象者７０を含む矩形（太線の枠で表示）内の領域であり、物体領域６１０は、人物以外の特定の物体（例えば、椅子）を含む矩形（破線で表示）内の領域である。

イベント判定部２１１は、人矩形、物体領域の検出方法として上述の背景差分法、または時間差分法を適用できる。

あるいは、イベント判定部２１１は、画像ｉ上で物体（オブジェクト）が存在する領域を物体存在領域として検出し、検出した物体存在領域に含まれる物体の所定のカテゴリー毎の信頼度スコアを算出する。信頼度スコアは、対象物体に関する尤度である。イベント判定部２１１は、Ｆａｓｔｅｒ Ｒ－ＣＮＮ等のＤＮＮ（Ｄｅｅｐ Ｎｅｕｒａｌ Ｎｅｔｗｏｒｋ）を用いた公知の技術により信頼度スコアを算出し得る。

所定のカテゴリーは、例えば、人物、椅子、および機具とし得る。イベント判定部２１１は、人物のカテゴリーの信頼度スコアが最も高い物体存在領域を人矩形７１０として検出する。すなわち、イベント判定部２１１は、物体（移動体）としてのケア対象者７０を検出する検出部として機能する。同様に、所定の物体のカテゴリーの信頼度スコアが最も高い物体存在領域を、当該信頼度スコアが最も高いカテゴリーの物体領域６１０（例えば、椅子の物体領域）として検出する。

イベント判定部２１１は、人矩形７１０からケア対象者７０の姿勢を推定する。より具体的には、イベント判定部２１１は、人矩形７１０からケア対象者７０の人の体に関する特徴点７２０を推定し、特徴点７２０の推定結果に基づいてケア対象者７０の姿勢を推定する。図１０Ａにおいて、特徴点７２０を人矩形７１０に重畳させて示している。特徴点７２０の位置は、白抜きの丸により示されている。また、特徴点７２０間を結ぶ黒い太線は骨を示している。特徴点７２０には、例えば、頭、首、肩、肘、手、腰、腿、膝、および足の特徴点７２０が含まれ得る。イベント判定部２１１は、人矩形７１０から特徴点７２０を検出するための辞書が反映されたＤＮＮにより、人矩形７１０からケア対象者７０の特徴点７２０を推定し得る。例えば、イベント判定部２１１は、ＤｅｅｐＰｏｓｅ等のＤＮＮを用いた公知の技術により特徴点７２０を推定し得る。ＤｅｅｐＰｏｓｅについては、公知の文献（Alexander Toshev, et al. “DeepPose: Human Pose Estimation via Deep Neural Networks”, in CVPR, 2014）に詳細が記載されている。

イベント判定部２１１は、人の姿勢を推定する。これは、特徴点７２０の推定結果に基づいて、ケア対象者７０の姿勢を推定する。例えば、イベント判定部２１１は、隠れマルコフモデルを用いて、推定された特徴点７２０から尤もらしいケア対象者７０の姿勢を算出する。適用可能な他の方法としては、例えば、予め決められた姿勢モデルと各特徴点位置との距離が最小となるものをその姿勢とする方法、姿勢を特徴量として学習し、当該学習結果を用いて姿勢認識する方法等が挙げられる。

イベント判定部２１１は、ケア対象者７０の行動を推定する。これは、イベント判定部２１１が推定したケア対象者７０の姿勢に基づいて、ケア対象者７０の行動を推定する。より具体的には、イベント判定部２１１は、特徴点７２０の位置と物体領域６１０の位置関係と、に基づいてケア対象者７０の行動を推定する。行動には、例えば、起床、離床、転落、転倒、歩行等が含まれる。

図１０Ａ、図１０Ｂは、撮影画像に基づいて行う、ケア対象者７０の移動軌跡による行動情報の解析を示す模式図である。同図では、行動の例として、ケア対象者７０がベッド６０を離れ、歩いて出口扉６５へ向かい、その途中で転倒したことにより転倒イベントに修正された場合（転倒するおそれがある場合）を想定する。

イベント判定部２１１は、人物のカテゴリーの信頼度スコアが最も高い物体存在領域を人矩形７１０として検出する。図１０Ａでは、ベッド６０に座り、起床のイベントが検出部１０により検出された時点でのケア対象者７０に対応する人矩形７１０が検出されている。図１０Ａに示す人矩形７１０の中心位置は、記憶される。記憶される位置は、人矩形７１０の中心位置以外に、矩形の起点および終点（左上と右下）を記憶してもよい。次に、イベント判定部２１１は、ケア対象者７０の姿勢を推定する。図１０Ａに示す例では、特徴点７２０の各々の位置関係から、ケア対象者７０は座位の姿勢にあると推定する。この判定を、前後の撮影画像（画像ｉ）に含まれる複数のフレーム画像に対して、逐次行う。

図１０Ｂは、図１０Ａの後に、ケア対象者７０が出口扉６５に向かって歩行している状態を示している。イベント判定部２１１は、図１０Ａに示すようにケア対象者７０がベッド６０に座っている状態から、図１０Ｂに示す居室の出口扉６５に向かうまでの間に、ケア対象者７０が離床し、歩行したと推定する。

通知先判定部２１２は、イベントリストに履歴の行動データ（以下、単に履歴データという）として記録されている同一のケア対象者７０（例えばＣさん）の過去の同じイベント（起床）の後の行動における移動軌跡８１０を、今回の行動での移動軌跡８２０と比較する。また、これにかかわらず、同じケア対象者７０の過去の歩行時の行動を比較対象としてもよい。過去の移動軌跡８１０では、出口扉６５の手前で転倒し、転倒イベントが検出されたものである。図１０Ｂに示す、今回の行動では転倒までは至っていないが、転倒のおそれがあるとして、転倒のイベントを検出したものとして説明する。

例えば、通知先判定部２１２は、移動軌跡の類似度が８０％以上の場合に、判定精度が所定値以上であると判定し、処理をステップＳ３１３に進める。一方で、所定値未満の場合には、処理をステップＳ３１４に進める。この類似度の算出は、例えば、上面視において、移動軌跡における各時点の位置情報の差分距離の積算値から評価できる。この移動軌跡の類似度の判定は、同一のケア対象者の同一イベントの複数の履歴データ全てについて比較するが、所定期間内（例えば、過去１ヶ月）の同一イベントの履歴データのみ比較するようにしてもよい。このような処理により、判定精度を算出する。

なお、ステップＳ３１１等で、イベント判定部２１１は、判定精度が所定値以上と判定した場合には、最も判定精度が高い、履歴データを参照して、指示情報を生成するようにしてもよい。例えば、行動の類似度が最も高い過去の履歴データに、起床イベント発生の直後に転倒した事例があれば、指示情報として「転倒の危険性高。駆けつけ必要」とする。

（ステップＳ３１３）
通知先判定部２１２は、通知先としてスタッフ８０を選択する。この場合のスタッフ８０は、イベントを発生させたケア対象者７０を担当する複数のスタッフ８０である。例えば、同一のスタッフユニットに所属するログイン中（業務中）のスタッフ８０全員である。

（ステップＳ３１４）
ここでは、通知先判定部２１２は、通知先として、情報管理者９０を選択する。以上で、図８の処理を終了し、図７の処理に戻りステップＳ１４０に処理を進める（エンド（リターン））。

（ステップＳ１４０）
制御部２１は、ステップＳ１３０で選択された通知先が、スタッフ８０であれば処理をステップＳ１５０に進め、情報管理者９０であれば処理をステップＳ１７０に進める。

（ステップＳ１５０）
サーバー２０は、通信部２２により、通知先のスタッフ８０にイベントを通知する。ここでは施設で勤務中の複数のスタッフ８０にイベントリストを配信する。

（スタッフ端末４０での処理）
ステップＳ１５０の処理により、判定の対象となったイベントが含まれるイベントリストが、各スタッフ８０のスタッフ端末４０に送信される。図１１は、スタッフ端末４０の表示部４３に表示されるイベントの確認を行うための操作画面４３１の例である。このスタッフ端末４０は、スタッフＤが利用中である。同図に示す操作画面４３１は、イベントリストが一覧表示される画面である。表示するイベントは、フリック操作することで上下にスクロールさせることが可能である。

操作画面４３１の領域ａ１１、ａ１２は、それぞれ、図９のイベントリスト２３１のイベントＩＤ０１０、０１１に対応する。領域ａ１１、ａ１２には、それぞれケアコール、起床のイベントであること示すアイコン、および対応済みであることが表示されている。領域ａ１３は、ステップＳ１５０で通知されたイベントＩＤ０１２、１３（Ｂさん、起床、転倒イベント）に対応する。なお、領域ａ１３では、同じケア対象者７０（Ｂさん）のイベントなので、同じ領域に２つのイベント情報を合わせて表示している。また、未対応であることから、領域ａ１３では、対応済みと区別し易いように、大きく表示している。領域ａ１３には、付加情報として、ステップＳ３１１で生成された指示情報ａ１３１（「転倒の危険性高」）が表示されている。これにより、スタッフ８０は、どのような状況に注意して、ケアを行えばよいのかが容易に把握できる。なお、領域ａ１３に、このイベント（ＩＤ０１２、１３）に関する動画の画像ｉ０１２、ｉ０１３（図９参照）から切り出した静止画から作成したサムネイル画像を表示してもよい。領域ａ１４を操作することで、ログイン中の他のスタッフ８０とテキストメッセージの交換を行える。

スタッフ８０（スタッフＤ）は、自らが率先して、未対応のイベント（ＩＤ０１２、１３）を担当すると決めた場合には、領域ａ１３の「対応する」ボタンを操作する。スタッフ端末４０の制御部４１は、「対応する」ボタンへの操作を検出することで、サーバー２０に、このスタッフ端末４０を使用するスタッフＤが担当する旨を送信する。なお、スタッフＤが他のケア対象者７０への対応中等で、直ぐに対応できない場合には、例えば、他のスタッフ８０にスタッフ端末４０を通じて、通話したり、テキストメッセージを送信したりする等により対応を依頼する。

（ステップＳ１６０）
サーバー２０は、スタッフ端末４０から対応する旨の通知を受けることで、イベントリスト２３１の該当イベントＩＤ０１２、１３の担当をこの送信元のスタッフＤにするとともに、ステイタスを「対応済み」に変更する。ここでは、スタッフ８０による操作画面上の「対応する」ボタンの操作により対応が行われたと見做して対応日時を、イベントリストに記録する。これにより、図１１のイベントリスト２３２のように対応状況が更新される（破線枠内）。

（ステップＳ１７０）
サーバー２０は、通信部２２により、通知先の情報管理者９０にイベントを通知する。この通知は、１の施設を担当する複数の情報管理者９０がいる場合には、イベントを発生させたケア対象者７０へのケアを管理する担当の情報管理者９０に向けて通知する。

（情報管理者端末３０での処理）
ステップＳ１５０の処理により、判定の対象となったイベントが含まれるイベントリストが、情報管理者端末３０に送信される。

図１２は、情報管理者端末３０に表示したイベント確認用の操作画面の例である。情報管理者端末３０は、ステップＳ１７０の処理で、サーバー２０から受信したイベントリストを表示部３３に表示する。図１２の操作画面３３１には、領域ａ３１～ａ３５、ボタンｂ１～ｂ４が含まれる。領域ａ３１にはイベントリスト２３３のイベント情報（イベントＩＤ０１４）を表示している。領域ａ３２には、イベント情報の画像ｉを表示している。この画像ｉは例えば、イベント発生時点を含む１０ｓｅｃから１５ｓｅｃ程度の長さの動画であり、この動画は停止ボタンが操作されるまで、繰り返し表示される。ポーズホタンを操作することで停止する。領域ａ３１、ａ３２に表示したイベントに関して、スタッフ８０による対応可否が必要かの判断を行う。

情報管理者９０は、領域ａ３３を通じて指示を入力する。領域ａ３３で「指示しない」、すなわち対応不要を選択した場合には、続いてＯＫボタンｂ２を操作することで選択が確定する。領域ａ３３で「指示する」を選択した場合には、グレイアウトしていた領域ａ３４が選択できるようになる。この領域ａ３４を通じて、どのスタッフ８０を担当として指示するかの選択を行う。

また選択したスタッフ８０に対して、連絡事項を送信する場合には、領域ａ３５にテキストメッセージを入力できる。なお、領域ａ３４に表示するスタッフ８０は、ログイン中のスタッフ８０を全て表示するが、その中で、イベントのケア対象者７０を担当するスタッフ８０のみを表示してもよい。ボタンｂ１により領域ａ３２の表示をリアルタイム表示、すなわちカメラ１３からのライブ映像に切り替えることができる。ボタンｂ４により、表示するイベントを変更し、過去のイベントをスクロール表示させることができる。なお、領域ａ３１に、現在表示しているイベントとともに、表示しているケア対象者７０に関する所定期間内（例えば過去２４時間以内）のイベントを一覧表示してもよい。操作画面３３１の表示内容を確認し、各種設定を行った後、指示送信ボタンｂ３を操作することで選択が確定し、サーバー２０に向けて指示が送信される。

（ステップＳ１８０）
サーバー２０は、情報管理者端末３０から受けた指示の内容を確認し、対応不要（「指示しない」）であれば処理をステップＳ１９０に進め、対応要（「指示する」）であれば、処理をステップＳ２００に進める。

（ステップＳ１９０）
サーバー２０は、指示内容（対応不要）をイベントリストに記録する。図９のイベントリスト２３３のイベントＩＤ０１４のように、指示情報に対応不要の旨が記載され、対応状況には、対応済みのステイタスが記録される（破線枠内）。

（ステップＳ２００）
サーバー２０は、指示内容（対応要）スタッフをイベントリストに記録する。また、イベントの対応を振り分けられた指名されたスタッフ８０のＩＤ（氏名等）をイベントリストに記録する。図９のイベントリスト２３３のイベントＩＤ０１５のように、指示情報には、対応要の旨、および振り分けたスタッフ名（スタッフＡ）が記載される。なお、この時点では、対応状況のステイタスは、未対応である（図９では不図示）。

（ステップＳ２１０）
サーバー２０の通信部２２は、通信部２２により、指示内容に記載された指名された１人のスタッフ８０に向けてイベントを通知する。

（ステップＳ２２０）
対応状況のステイタスは、ステップＳ１６０と同様の処理により、その後のスタッフＡによる「対応する」ボタン（図１１参照）の操作を受けて、図９のイベントリスト２３３のイベントＩＤ０１５の対応状況に示すように、対応済みのステイタスに更新する。

このように第１の実施形態に係る情報処理装置では、ケア対象者に関するイベント毎に、所定条件に基づいて、ケア対象者へのケアを行うスタッフに使用されるスタッフ端末、およびスタッフへの指示を行う情報管理者が使用する情報管理者端末のうちのどちらに通知するかを判定する通知先判定部と、通知先判定部が判定した通知先に、通知する通知部と、を備える。これによりケアスタッフへの不要な通知を防止することでケアスタッフの負荷を軽減するとともに、管理者に過度に負荷が集中することを防止できる。特に、判断精度が低いイベントに関しては、情報管理者９０が一度、判断することでケアスタッフに不要な通知を減少させることができ負担を軽減できるとともに、判定精度が高いイベントに関しては、情報管理者９０を通さずに直接、スタッフ８０に通知されることで、情報管理者９０に通知が過度に集中することを防止できる。

（第２の実施形態における通知先判定処理）
図１３は、第２の実施形態における通知先判定処理（ステップＳ１３０）を示すサブルーチンフローチャートである。上述の第１の実施形態では判定精度により、通知先の選択処理を行っていたが、第２の実施形態では、さらに、イベントが特定のイベントであるか否かにより、選択処理するものである。なお、第２の実施形態では、図１３に説明する構成以外は、図７の処理を含めて、第１の実施形態と同様であり、図１３以外の説明は省略する。

（ステップＳ３２０）
ここでは、通知先判定部２１２は、図８のステップＳ３１０と同様の処理により、ステップＳ２０で更新されたデータベース２３のイベントリストから、通知先判定処理を行う対象のイベントに関するイベント情報を取得する。

（ステップＳ３２１）
通知先判定部２１２は、イベント情報に基づいて、イベントが特定のイベントであるか否かを判定する。特定のイベントとは、身体の危険度が高く、緊急対応が必要なイベントである。例えば、心臓停止等による微体動異常のイベントである。この緊急対応が必要なイベントは、ケア対象者７０毎、またはケア対象者７０の身体能力毎、もしくは要介護度認定レベル毎に応じて設定するようにしてもよい。例えば、常時車椅子を利用する等、歩行困難なケア対象者７０に対しては、転倒のイベントを緊急対応が必要なイベントな特定のイベントとして設定する。通知先判定部２１２は、特定のイベントであれば（ＹＥＳ）、処理をステップＳ３２５に進め、そうでなければ（ＮＯ）、処理をステップＳ３２２に進める。

（ステップＳ３２２～Ｓ３２５）
これらのステップＳ３２２～Ｓ３２５の処理は、図８のステップＳ３１１～Ｓ３１４にそれぞれ対応する。これらの処理により、通知先判定部２１２は、通知先として、スタッフ８０、または情報管理者９０を選択する。

このように、第２の実施形態では、特定のイベントであるか否かにより、通知先を選択するので、より適確に、イベントを通知できる。特に、緊急対応が必要なイベントの場合には、確実に情報管理者９０に通知が行くので、適確な対応を期待できる。

以上に説明した情報処理装置、およびこれを含む見守りシステムの構成は、上述の実施形態の特徴を説明するにあたって主要構成を説明したのであって、上述の構成に限られず、特許請求の範囲内において、種々改変することができる。また、一般的な情報処理装置、および見守りシステムが備える構成を排除するものではない。例えば、検出部１０、サーバー２０、情報管理者端末３０およびスタッフ端末４０は、上記の構成要素以外の構成要素を含んでもよく、あるいは、上記の構成要素のうちの一部を含まなくてもよい。

（変形例）
情報管理者９０が複数いる場合には、イベント情報に応じて、振り分けるようにしてもよい。例えば、被介護者ユニット毎、またはスタッフユニット毎に情報管理者９０を設定し、イベント情報に含まれるケア対象者の個人ＩＤに基づいて、スタッフリスト、対象者リストを参照することで、通知先判定部２１２は、振り分ける情報管理者９０を決定する。このようにすることで、大規模な施設において過度に１人の情報管理者９０に集中することを防止できる。

また、イベントの通知を受け取った、スタッフ８０または情報管理者９０のユーザーが、システムの通知の判定結果（正判定／誤判定）についてフィードバック（ＦＢ）できるようにしてもよい。例えば、イベントの通知をＦＢ要求とともにユーザーに送信し、そのＦＢ要求へ回答としてＦＢを情報処理装置側に集約する。そして、イベント情報をＦＢ要求の回答（ＦＢ結果）と紐付けて、記憶部としてのデータベース２３にイベントリストとして記憶する。このＦＢの回答により、イベント判定部２１１、または通知先判定部２１２のアルゴリズムを改善する。また、ＦＢの回答により、判定精度を算出するアルゴリズムを改善するようにしてもよい。例えば、イベントに対する正判定のＦＢ結果が繰り返し得られれば、判定精度の出力が高くなるようにアルゴリズムを改善する。

さらにイベント判定部２１１が、学習済みモデル等を用いて、判定精度を算出したが、これに限られず、通知先判定部２１２側で、判定精度を算出するようにしてもよい。あるいは、検出部１０側で、判定精度を算出するようにしてもよい。例えば、検出部１０がサーバー２０に送信するイベント情報に判定精度を含ませる。

また、上述した実施形態に係る情報処理装置における処理は、上記のフローチャート、シーケンスチャートに示したステップ以外のステップを含んでもよく、あるいは、上述したステップのうちの一部を含まなくてもよい。また、ステップの順序は、上述した実施形態に限定されない。さらに、各ステップは、他のステップと組み合わされて一つのステップとして実行されてもよく、他のステップに含まれて実行されてもよく、複数のステップに分割されて実行されてもよい。

例えば、図１３に示した第２の実施形態では、特定のイベントか否かの判定、および判定精度が所定値以上から否かの判定を組み合わせたが、判定精度に関するステップＳ３２２、Ｓ３２３の処理を省略し、特定のイベントか否かの判定のみにより通知先を選択するようにしてもよい。

また、上述した実施形態に係る情報処理装置、または見守りシステムにおける各種処理を行う手段および方法は、専用のハードウエア回路、またはプログラムされたコンピューターのいずれによっても実現することが可能である。上記プログラムは、例えば、ＵＳＢメモリやＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）－ＲＯＭ等のコンピューター読み取り可能な記録媒体によって提供されてもよいし、インターネット等のネットワークを介してオンラインで提供されてもよい。この場合、コンピューター読み取り可能な記録媒体に記録されたプログラムは、通常、ハードディスク等の記憶部に転送され記憶される。また、上記プログラムは、単独のアプリケーションソフトとして提供されてもよいし、一機能としてその検出部等の装置のソフトウエアに組み込まれてもよい。

１ 見守りシステム
１０ 検出部
１１ 制御部
１２ 通信部
１３ カメラ
１４ ケアコール部
２０ サーバー（情報処理装置）
２１ 制御部
２１１ イベント判定部
２１２ 通知先判定部
２２ 通信部
２３ データベース
３０ 情報管理者端末
３１ 制御部
３２ 通信部
３３ 表示部
３４ 入力部
３５ 音声入出力部
４０ スタッフ端末
４１ 制御部
４２ 無線通信部
４３ 表示部
４４ 入力部
４５ 音声入出力部
５０ ネットワーク
５１ アクセスポイント
６０ ベッド
７０ ケア対象者
８０ スタッフ
９０ 情報管理者

Claims (10)

1. ケア対象者に関するイベント毎に、所定条件に基づいて、前記ケア対象者に対応するスタッフが使用するスタッフ端末、および前記スタッフへの指示を行う情報管理者が使用する情報管理者端末のうちのどちらに通知するかを判定する通知先判定部と、
   前記通知先判定部が判定した通知先に、通知する通知部と、
   を備える、情報処理装置。
2. 前記通知先判定部は、前記所定条件として、前記イベントの種類が、予め設定された特定のイベントである場合には、通知先として、前記情報管理者端末を選択し、
   前記特定のイベント以外の場合には、通知先として、前記スタッフ端末を選択する、請求項１に記載の情報処理装置。
3. 前記通知先判定部は、前記所定条件として、イベントの判定精度が所定値以上の場合に、通知先として前記スタッフ端末を選択し、
   前記判定精度が前記所定値以上でない場合に、通知先として前記情報管理者端末を選択する、請求項１に記載の情報処理装置。
4. 前記通知先判定部は、イベントの前記判定精度にかかわらず、前記イベントの種類が、予め設定された特定のイベントである場合には、通知先として、前記情報管理者端末を選択する、請求項３に記載の情報処理装置。
5. 前記ケア対象者の状態情報、判定した前記イベントの種類、および前記ケア対象者を特定する個人ＩＤを含むイベント情報の履歴を記憶する記憶部を備え、
   前記状態情報には、前記ケア対象者に対応付けられた観察領域における該ケア対象者の動きを検出する検出部からの出力が含まれ、
   前記通知先判定部は、前記イベントの判定精度として、前記ケア対象者自身の過去の行動データと、今回の行動データとの類似度を用いる、請求項３、または請求項４に記載の情報処理装置。
6. 前記特定のイベントは、緊急な対応が必要なイベントである、請求項２、または請求項４に記載の情報処理装置。
7. 取得したケア対象者に関する状態情報に基づいて、前記ケア対象者に関するイベントの発生有無を判定するイベント判定部を、さらに、備え、
   前記通知先判定部は、前記イベント判定部が判定したイベント毎に、前記スタッフ端末および前記情報管理者端末のうちのどちらに通知するかの判定を行う、請求項１から請求項６のいずれかに記載の情報処理装置。
8. 前記スタッフは複数であり、
   前記通知部は、
   前記通知先として前記スタッフ端末が選択された場合、複数の前記スタッフの前記スタッフ端末に対して前記イベントを通知し、
   前記通知先として前記情報管理者端末が選択された場合、前記情報管理者端末に対して前記イベントを通知し、その後、
   該情報管理者端末からの前記複数の前記スタッフの中から、前記ケア対象者への対応を行う前記スタッフの選択する振り分け指示を受け付け、受け付けた前記指示で選択された前記スタッフに向けて、前記イベントを通知する、請求項１から請求項７のいずれかに記載の情報処理装置。
9. ケア対象者に対応付けられた観察領域における該ケア対象者の動きを検出する検出部と、
   請求項１から請求項８のいずれかに記載の情報処理装置と、
   １つ以上のスタッフ端末と、
   情報管理者端末と、を備える、見守りシステム。
10. ケア対象者に関するイベント毎の通知先として、所定条件に基づき、前記ケア対象者に対応するスタッフが使用するスタッフ端末、および前記スタッフへの指示を行う情報管理者が使用する情報管理者端末のうちのどちらかに通知するかを判定するステップ（ａ）と、
    前記ステップ（ａ）で選択した通知先に、通知するステップ（ｂ）と、を含む処理を、
    情報処理装置を制御するコンピューターに実行させるための制御プログラム。