JP7325008B2 - 介護サービス支援方法、介護サービス支援システム及び介護サービス支援サーバ - Google Patents

Description

本開示は、介護施設の稼働率を向上する技術に関する。

従来から、介護施設において利用者を効率よく介護する技術が知られている。例えば、特許文献１には、介護施設に訪問する利用者を効率よく送迎する技術が開示されている。具体的には、特許文献１には、データベースに予め格納されている、利用者の個人情報、事業者に関する事業者情報、及び送迎サービスの予約状況を示す予約情報に基づき、利用者を最適な送迎車に振り分けることが開示されている。

特開２００６－１８５７０号公報

しかし、従来の介護施設では、利用者が介護施設を利用する当日に体調不良を訴えた場合、施設内で病気が流行することを回避するため、当該利用者を無条件に自宅で静養させる対処が行われていた。このため、利用者は、微熱又は疲労等による、他者に影響を与えない程度の軽微な体調不良を訴え、介護施設の個室での介護を希望したとしても、希望通りの介護を受けることができなかった。また、上記対処では、利用者が体調不良を訴えた場合に、介護施設のリソースに無条件に余剰が生じることとなり、介護施設の稼働率が低減するという問題があった。

上記特許文献１に開示の技術は、介護施設に訪れることが決まっている利用者を対象とする技術であるため、利用者を無条件に介護施設に訪れさせないことで生じる上記問題を解消できなかった。

本開示の一態様に係る介護サービス支援方法は、介護サービス支援システムのコンピュータが、複数の利用者各々について当日の健康状態に関する情報である健康情報を取得し、前記複数の利用者のうち、前記健康情報が示す前記当日の健康状態が所定の条件を満たす対象利用者に対し、前記当日の介護内容の希望を問い合わせて前記当日の介護内容の希望に関する希望介護情報を取得し、前記健康情報及び前記希望介護情報と、予め設定されている前記複数の利用者各々の前記当日の介護のスケジュールに関するスケジュール情報と、に基づいて、前記スケジュールを改変して、当該改変後のスケジュールに関するリスケジュール案を作成し、前記複数の利用者各々に対し、前記リスケジュール案における各利用者の前記当日の介護のスケジュールに関する情報を通知する。

本開示によれば、軽微な体調不良の状態にある利用者に、当該利用者が希望する介護を受けさせることができ、介護施設の稼働率を向上することができる。

本開示の第一実施形態における介護サービス支援システムの全体構成の一例を示す図である。 施設端末の構成の一例を示すブロック図である。 利用者情報ＤＢのデータ構成の一例を示す図である。 施設リソース情報ＤＢのデータ構成の一例を示す図である。 スケジュール情報ＤＢのデータ構成の一例を示す図である。 スケジュール情報の設定方法の一例を示す図である。 本開示の介護サービス支援システムにおいて実行されるリスケジュール処理の一例を示すフローチャートである。 本開示の介護サービス支援システムにおいて実行されるリスケジュール処理の一例を示すフローチャートである。 生体情報に応じて各利用者の介護内容を改変する処理の一例を示す図である。 生体情報に応じて介護内容が確定された利用者の介護のスケジュールを改変する処理の一例を示す図である。 対象利用者が希望する介護内容に応じて、対象利用者の介護のスケジュールを改変する処理の一例を示す図である。

（本開示の一態様に至る経緯）
介護施設の利用者は、ノロウィルス及びインフルエンザ等の感染症及び風邪並びに疲労等の様々な原因で、介護施設を利用する当日になって突然体調不良を訴える場合がある。特に、感染症及び風邪等の病気による体調不良を訴えた利用者が介護施設に訪れると、介護施設において病気が流行し、他の利用者の体調を悪化させる虞がある。このため、従来、介護施設では、利用者が介護施設を利用する当日に体調不良を訴えた場合、当該利用者を無条件に自宅で静養させる対処が行われていた。

しかし、上記対処では、利用者は、微熱又は疲労等による、他者に影響を与えない程度の軽微な体調不良を訴え、介護施設の個室での介護を希望したとしても、希望通りの介護を受けることができなかった。また、上記対処では、利用者が体調不良を訴えた場合に、介護施設の施設及び備品並びに介護施設のスタッフの労力等の介護施設のリソースに無条件に余剰が生じることとなり、介護施設の稼働率が低減するという問題があった。

上記特許文献１に開示の技術は、介護施設に訪れることが決まっている利用者を対象とする技術であるため、利用者を無条件に介護施設に訪れさせないことで生じる上記問題を解消することはできなかった。

そこで、本発明者は、軽微な体調不良の状態にある利用者に、当該利用者が希望する介護を受けさせて、介護施設の稼働率を向上することについて鋭意検討を重ねた結果、以下の本開示に係る各態様を想到するに至った。

本開示の一態様に係る介護サービス支援方法は、介護サービス支援システムのコンピュータが、複数の利用者各々について当日の健康状態に関する情報である健康情報を取得し、前記複数の利用者のうち、前記健康情報が示す前記当日の健康状態が所定の条件を満たす対象利用者に対し、前記当日の介護内容の希望を問い合わせて前記当日の介護内容の希望に関する希望介護情報を取得し、前記健康情報及び前記希望介護情報と、予め設定されている前記複数の利用者各々の前記当日の介護のスケジュールに関するスケジュール情報と、に基づいて、前記スケジュールを改変して、当該改変後のスケジュールに関するリスケジュール案を作成し、前記複数の利用者各々に対し、前記リスケジュール案における各利用者の前記当日の介護のスケジュールに関する情報を通知する。

本構成では、当日の健康状態が所定の条件を満たす対象利用者から、当日の介護内容の希望に関する希望介護情報が取得される。このため、利用者の健康状態が、微熱又は疲労等による、他者に影響を与えない程度の軽微な体調不良の状態であることを示す条件を、前記所定の条件として定めることができる。これにより、健康状態が当該所定の条件を満たす、軽微な体調不良の状態である利用者を対象利用者とし、当該対象利用者から当日の介護内容の希望に関する希望介護情報を取得できる。

そして、本構成では、複数の利用者各々の健康状態に関する健康情報及び予め設定されたスケジュール情報だけでなく、対象利用者から取得した希望介護情報にも基づき、リスケジュール案が作成される。このため、対象利用者が希望する当日の介護内容を加味して、対象利用者が希望する介護を受けることができるリスケジュール案を作成できる。尚、本構成では、作成されたリスケジュール案における各利用者の当日の介護のスケジュールに関する情報が各利用者に通知される。このため、対象利用者は、希望通りの介護が受けれるか否かを確認できる。

すなわち、本構成によれば、上記のように前記所定の条件を定めることで、軽微な体調不良の状態にある対象利用者が、希望する介護を受けることができるリスケジュール案を作成できる。このため、従来のように、当該対象利用者を無条件に自宅で静養させる場合よりも、介護施設のリソースに余剰が生じる機会を低減できる。その結果、介護施設の稼働率を向上することができる。

上記態様において、前記健康情報は、前記複数の利用者各々の前記当日における体温に関する情報であってもよい。

本構成によれば、複数の利用者各々の当日における体温に基づき、対象利用者が希望する当日の介護内容を加味して、対象利用者が希望する介護を受けることができるリスケジュール案を作成できる。

上記態様において、前記所定の条件は、前記複数の利用者各々の前記当日における体温が、前記当日の前日における体温よりも所定の値を超えて上昇していることであってもよい。

本構成によれば、体温が前日よりも所定の値を超えて上昇しており、熱があると考えられる利用者を対象利用者とし、当該対象利用者が希望する介護を受けることができるリスケジュール案を作成できる。

上記態様において、前記所定の条件は、前記複数の利用者各々の前記当日における体温が、前記当日の前日における体温よりも所定の値を超えて上昇しており、且つ、所定の体温以下であることであってもよい。

本構成によれば、体温が前日よりも所定の値を超えて上昇しており、且つ、所定の体温以下である、微熱があると考えられる利用者を対象利用者とし、当該対象利用者が希望する介護を受けることができるリスケジュール案を作成できる。

上記態様において、前記コンピュータは、更に、前記複数の利用者各々について同居する家族が前記当日において感染症に罹患しているか否かを示す罹患情報を取得し、前記所定の条件は、前記複数の利用者各々の前記当日における体温が、前記当日の前日における体温よりも所定の値を超えて上昇しており、且つ、当該複数の利用者各々についての前記罹患情報が感染症に罹患していないことを示すことであってもよい。

利用者と同居する家族が感染症に罹患している場合、当該利用者は、感染症に感染している可能性が非常に高いと考えられる。本構成では、罹患情報が感染症に罹患していることを示す利用者が対象利用者として扱われない。このため、罹患情報が感染症に罹患していることを示す利用者が希望する介護を受けることができるリスケジュール案が作成されることを回避できる。その結果、罹患情報が感染症に罹患していることを示す利用者が希望する介護を受けることで、他の利用者が感染症に感染するリスクを低減できる。

上記態様において、前記介護内容には、個室での介護及び在宅での介護が含まれてもよい。

本構成によれば、対象利用者が当日の介護内容として個室での介護又は在宅での介護を希望した場合に、対象利用者が、自身が希望した個室での介護又は在宅での介護を受けることができるリスケジュール案を作成できる。

上記態様において、前記スケジュール情報は、前記複数の利用者の人数、前記複数の利用者が利用する介護施設の設備リソース、前記複数の利用者各々の介護に必要な介護者の人数、及び前記介護施設の人的リソースに基づいて設定されていてもよい。

本構成では、スケジュール情報が、複数の利用者の人数、複数の利用者が利用する介護施設の設備リソース、複数の利用者各々の介護に必要な介護者の人数、及び介護施設の人的リソースに基づいて設定されている。このため、当該スケジュール情報に基づき、介護施設の設備リソース及び人的リソースに余剰が生じないようなリスケジュール案を作成できる。

上記態様において、前記リスケジュール案における前記対象利用者の前記当日の介護のスケジュールが、前記対象利用者が希望するスケジュールと一致しない場合、前記対象利用者に対し、前記当日の介護内容の希望を再度問い合わせて前記希望介護情報を再取得し、当該再取得した前記希望介護情報を用いて前記リスケジュール案を再作成してもよい。

本構成によれば、リスケジュール案における対象利用者の当日の介護のスケジュールが、当該対象利用者が希望するスケジュールと一致しない場合、当該対象利用者から希望介護情報が再取得され、当該再取得した希望介護情報に基づき、リスケジュール案が再作成される。このため、対象利用者が希望する介護を受けることができるリスケジュール案をより確実に作成できる。

本開示は、上述した方法に含まれる特徴的な各ステップをコンピュータに実行させるコンピュータプログラムとして実現することもできる。そして、そのようなコンピュータプログラムを、ＣＤ－ＲＯＭ等のコンピュータ読取可能な非一時的な記録媒体あるいはインターネット等の通信ネットワークを介して流通させることができるのは、言うまでもない。

また、本開示の他の一態様に係る介護サービス支援システムは、複数の利用者各々について当日の健康状態に関する情報である健康情報を取得する第一取得部と、前記複数の利用者のうち前記健康情報が示す前記当日の健康状態が所定の条件を満たす対象利用者に対し、前記当日の介護内容の希望を問い合わせて前記当日の介護内容の希望に関する希望介護情報を取得する第二取得部と、前記健康情報及び前記希望介護情報と、予め設定されている前記複数の利用者各々の前記当日の介護のスケジュールに関するスケジュール情報と、に基づいて、前記スケジュールを改変して、当該改変後のスケジュールに関するリスケジュール案を作成する作成部と、前記複数の利用者各々に対し、前記リスケジュール案における各利用者の前記当日の介護のスケジュールに関する情報を通知する通知部と、を備える。

また、本開示の他の一態様に係る介護サービス支援サーバは、複数の利用者各々について当日の健康状態に関する情報である健康情報を取得する第一取得部と、前記複数の利用者のうち前記健康情報が示す前記当日の健康状態が所定の条件を満たす対象利用者に対し、前記当日の介護内容の希望を問い合わせて前記当日の介護内容の希望に関する希望介護情報を取得する第二取得部と、前記健康情報及び前記希望介護情報と、予め設定されている前記複数の利用者各々の前記当日の介護のスケジュールに関するスケジュール情報と、に基づいて、前記スケジュールを改変して、当該改変後のスケジュールに関するリスケジュール案を作成する作成部と、前記複数の利用者各々に対し、前記リスケジュール案における各利用者の前記当日の介護のスケジュールに関する情報を通知する通知部と、を備える。

尚、以下で説明する実施の形態は、いずれも本開示の一具体例を示すものである。以下の実施の形態で示される数値、形状、構成要素、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。また全ての実施の形態において、各々の内容を組み合わせることもできる。

（第一実施形態）
以下、本発明の実施の形態について図面を参照しながら説明する。図１は、本開示の第一実施形態における介護サービス支援システム１の全体構成の一例を示す図である。介護サービス支援システム１は、介護施設の利用者及び介護施設のリソースに関する情報と、複数の利用者各々の介護のスケジュールに関する情報と、を管理し、当該情報に基づき、各利用者の介護のスケジュールを作成及び管理するシステムである。

ここで、介護施設の利用者とは、介護施設のスタッフ（介護者の一例）によって介護を受ける利用者が該当する。介護施設のリソースとは、介護施設が備える個室、浴室、食卓及び送迎バス等の設備リソースと、介護施設に勤務するスタッフ等の人的リソースと、が該当する。

図１に示すように、介護サービス支援システム１は、ＤＢ（データベース）サーバ１０、生体センサー２０、利用者端末３０、スタッフ端末４０、及び施設端末５０を備えている。ＤＢサーバ１０、生体センサー２０、利用者端末３０、スタッフ端末４０、及び施設端末５０は、ネットワークＮＴを介して相互に通信可能に接続されている。ネットワークＮＴは、例えば、携帯電話通信網及びインターネット通信網等を含む公衆通信網で構成されている。尚、図１では、説明の便宜上、生体センサー２０、利用者端末３０及びスタッフ端末４０は、それぞれ、一個ずつしか示されていない。しかし、これに限らず、介護サービス支援システム１には、複数の生体センサー２０、複数の利用者端末３０及び複数のスタッフ端末４０が含まれていてもよい。

ＤＢサーバ１０は、ＨＤＤ（ハードディスクドライブ）等の記憶装置を備えた一以上のコンピュータで構成されている。ＤＢサーバ１０は、ネットワークＮＴを介してアクセス可能な利用者情報ＤＢ（データベース）１３１、施設リソース情報ＤＢ１３２及びスケジュール情報ＤＢ１３３を用いて、介護サービス支援システム１において使用する情報を管理する。

利用者情報ＤＢ１３１は、介護施設の利用者に関する情報（以降、利用者情報）を記憶する。利用者情報は、システム管理者によって、利用者が介護施設を利用する契約をした際に利用者情報ＤＢ１３１に記憶され、また、一年の間に一回以上更新される。

施設リソース情報ＤＢ１３２は、介護施設のリソースに関する情報（以降、施設リソース情報）を記憶する。施設リソース情報は、システム管理者によって、介護サービス支援システム１の導入時に施設リソース情報ＤＢ１３２に記憶され、また、一年の間に一回以上更新される。

スケジュール情報ＤＢ１３３は、各利用者が受ける介護のスケジュールに関する情報（以降、スケジュール情報）を記憶する。スケジュール情報は、介護施設が定める期日までに、各利用者によって不定期にスケジュール情報ＤＢ１３３に記憶される。利用者情報ＤＢ１３１、施設リソース情報ＤＢ１３２、及びスケジュール情報ＤＢ１３３の詳細は後述する。

生体センサー２０は、例えば、介護施設の利用者の家庭に設置された通信機能付きの生体センサーで構成されている。これに限らず、生体センサー２０は、利用者の身体に装着可能な通信機能付きの生体センサーで構成されていてもよい。生体センサー２０は、利用者の健康状態を表す、体温、血圧、発汗量、心拍数等の生体情報（健康情報の一例）を検出し、当該検出した生体情報をネットワークＮＴを介して施設端末５０へ送信する。

利用者端末３０は、例えば、介護施設の利用者の家庭に設置されたパーソナルコンピュータで構成されている。これに限らず、利用者端末３０は、介護施設の利用者又は当該利用者の連絡者が所有するタブレット端末又はスマートフォンで構成されていてもよい。利用者の連絡者とは、利用者に代わり、介護施設のスタッフと利用者による介護施設の利用について連絡し合う、利用者と同居している家族である。

具体的には、利用者端末３０は、利用者端末３０の全体制御を司るプロセッサと、前記プロセッサの制御の下、種々の情報を表示する表示部と、利用者端末３０の操作を受け付ける操作部と、を備える。また、利用者端末３０は、前記プロセッサの制御の下、外部装置との間で種々の情報を送受信する通信部と、前記プロセッサの制御の下、種々の音声を出力するスピーカと、を備える。表示部は、例えば、液晶ディスプレイ等の表示装置である。操作部は、例えば、タッチパネル、キーボード、及びマウス等の入力装置である。通信部は、利用者端末３０が外部装置とネットワークＮＴを介して通信するための無線通信インターフェイス回路及び／又は有線通信インターフェイス回路である。

利用者端末３０は、施設端末５０との間で種々の情報を送受信し、施設端末５０から受信した情報を表示部に表示する。また、利用者端末３０は、施設端末５０から受信した情報を示す音声をスピーカによって出力させる。

スタッフ端末４０は、例えば、介護施設に設置されたパーソナルコンピュータで構成されている。これに限らず、スタッフ端末４０は、介護施設のスタッフが所有するタブレット端末又はスマートフォンで構成されていてもよい。スタッフ端末４０は、利用者端末３０と同様のプロセッサ、表示部、操作部、通信部、及びスピーカを備える。スタッフ端末４０は、施設端末５０との間で種々の情報を送受信し、施設端末５０から受信した情報を表示部に表示する。また、スタッフ端末４０は、施設端末５０から受信した情報を示す音声をスピーカによって出力させる。

施設端末５０は、例えば、介護施設に設置されたサーバ装置又はパーソナルコンピュータで構成され、介護サービス支援システム１の全体制御を司る。

図２は、施設端末５０の構成の一例を示すブロック図である。具体的には、図２に示すように、施設端末５０は、施設端末５０の全体制御を司るプロセッサ５６と、プロセッサ５６の制御の下、種々の情報を表示する表示部５１と、施設端末５０の操作を受け付ける操作部５２と、を備える。施設端末５０は、プロセッサ５６の制御の下、外部装置との間で種々の情報を送受信する通信部５３と、プロセッサ５６の制御の下、種々の音声を出力するスピーカ５４と、プロセッサ５６の制御に用いる情報及びプログラムを記憶するメモリ５５と、を備える。

プロセッサ５６は、例えば、ＣＰＵで構成され、第一取得部５６１、第二取得部５６２、作成部５６３、及び通知部５６４として機能する。ここで、第一取得部５６１、第二取得部５６２、作成部５６３、及び通知部５６４は、例えば、プロセッサ５６がメモリ５５に記憶された、コンピュータを施設端末５０として機能させる介護サービス支援プログラムを実行することで実現される。尚、この介護サービス支援プログラムは、ネットワークＮＴからダウンロードすることで市場に提供されてもよいし、コンピュータ読取可能な非一時的な記録媒体に記録されることで市場に提供されてもよい。

第一取得部５６１は、生体センサー２０（図１）から送信され、通信部５３が受信した生体情報を、通信部５３から取得する。また、第一取得部５６１は、利用者端末３０（図１）から送信され、通信部５３が受信した生体情報を通信部５３から取得する。第一取得部５６１は、通信部５３を制御して、当該取得した生体情報をＤＢサーバ１０に送信することにより、利用者情報ＤＢ１３１に記憶する。

具体的には、介護施設の利用者又は当該利用者の連絡者は、例えば利用者が起床した直後等、利用者が介護施設を利用する前に、生体センサー２０（図１）を操作して、利用者の当日の生体情報を検出し、当該検出した生体情報を施設端末５０に送信する。または、介護施設の利用者又は当該利用者の連絡者は、例えば、起床時等の介護施設を利用する前に、体温計及び血圧計等を用いて利用者の当日の生体情報を取得する。そして、介護施設の利用者又は当該利用者の連絡者は、前記取得した利用者の生体情報を利用者端末３０に入力し、利用者端末３０を操作して、当該入力した生体情報を施設端末５０に送信する。これにより、第一取得部５６１は、利用者が介護施設を利用する当日の生体情報を取得することになる。

尚、第一取得部５６１は、生体センサー２０の通信アドレスと、利用者端末３０の通信アドレスと、利用者の識別子と、が、予め登録されている通信情報テーブルを参照することで、取得した生体情報がどの利用者の生体情報であるかを特定すればよい。尚、通信情報テーブルは、予め利用者情報ＤＢ１３１に記憶されている。第一取得部５６１は、通信部５３を制御して、利用者情報ＤＢ１３１に記憶されている通信情報テーブルを参照する。ただし、これに限らず、プロセッサ５６が、施設端末５０の起動時等の所定のタイミングで、通信部５３を制御して、利用者情報ＤＢ１３１から読み取った通信情報テーブルをメモリ５５に記憶するようにしてもよい。そして、第一取得部５６１が、メモリ５５に記憶されている通信情報テーブルを参照するようにしてもよい。

第二取得部５６２は、第一取得部５６１によって取得された複数の利用者の当日の生体情報のうち、利用者の当日の健康状態が所定の変更条件（所定の条件の一例）を満たすことを示す生体情報が存在するか否かを判定する。ここで、変更条件は、例えば、微熱又は疲労等が原因で、利用者が軽微な体調不良であるときの、利用者の生体情報によって定められている。

例えば、生体情報が、利用者の体温を示す情報であるとする。この場合、変更条件は、例えば、利用者の当日における体温が、当該当日の前日における体温よりも所定の値（例えば、０．５℃）を超えて上昇しており、且つ、所定の体温（例えば、３８℃）以下であることに定めればよい。

このように変更条件が定められている場合、第二取得部５６２は、通信部５３を制御して、第一取得部５６１によって取得され、利用者情報ＤＢ１３１に記憶された、複数の利用者の前記当日及び前記当日の前日の生体情報を参照する。そして、第二取得部５６２は、当該参照した生体情報のうち、利用者の前記当日における体温が、当該利用者の前記当日の前日における体温よりも所定の値を超えて上昇しており、且つ、所定の体温以下であることを示す生体情報が存在するか否かを判定する。

第二取得部５６２は、利用者の当日の健康状態が変更条件を満たすことを示す生体情報が存在すると判定したとする。この場合、第二取得部５６２は、当該生体情報に対応する利用者（以降、対象利用者）又は対象利用者の連絡者に対し、対象利用者が希望する前記当日の介護内容を問い合わせる。ここで、介護内容には、介護施設が備える個室での介護、及び、在宅での介護等が含まれる。在宅での介護とは、介護施設のスタッフが利用者の自宅に訪問して利用者を介護することを示す。

具体的には、第二取得部５６２は、第一取得部５６１と同様に前記通信情報テーブルを参照することで、対象利用者又は対象利用者の連絡者が利用する利用者端末３０のアドレスを取得する。第二取得部５６２は、通信部５３を制御して、前記取得したアドレス宛に、前記当日の介護内容の希望を問い合わせる旨のメッセージ（例えば、「本日希望する介護内容を返信して下さい。」）を送信する。

第二取得部５６２は、前記問い合わせの後、対象利用者又は対象利用者の連絡者が利用する利用者端末３０から送信され、通信部５３によって受信された、当日の介護内容の希望に関する希望介護情報を取得する。

具体的には、第二取得部５６２によって前記問い合わせが行われ、対象利用者又は対象利用者の連絡者が利用する利用者端末３０の通信部が、前記当日の介護内容の希望を問い合わせる旨のメッセージを受信したとする。この場合、利用者端末３０のプロセッサは、当該受信したメッセージを利用者端末３０の表示部に表示するとともに、前記当日の介護内容の希望を入力するための操作画面を利用者端末３０の表示部に表示する。

これに応じて、対象利用者又は対象利用者の連絡者が、利用者が希望する前記当日の介護内容（例えば「個室での介護」）を利用者端末３０に入力したとする。この場合、利用者端末３０のプロセッサは、利用者端末３０の通信部を制御して、当該入力された介護内容を示す希望介護情報を施設端末５０に送信する。

これにより、第二取得部５６２は、利用者端末３０から送信され、通信部５３が受信した希望介護情報を通信部５３から取得することになる。尚、第二取得部５６２は、前記通信情報テーブルを参照することで、取得した希望介護情報が、どの利用者が希望する介護内容であるのかを、特定すればよい。

作成部５６３は、第一取得部５６１が取得した複数の利用者の生体情報と、第二取得部５６２が取得した希望介護情報と、複数の利用者各々の当日の介護のスケジュール（以降、当日スケジュール）に関するスケジュール情報（以降、当日のスケジュール情報）と、に基づいて、当日スケジュールを改変する。当日のスケジュール情報は、スケジュール情報ＤＢ１３３に予め記憶されている。そして、作成部５６３は、当該改変後の当日スケジュールに関するリスケジュール案を作成する。作成部５６３によるリスケジュール案の作成方法の詳細は後述する。

通知部５６４は、作成部５６３が作成したリスケジュール案における、各利用者の当日のスケジュール情報を、通信部５３を制御して、当該各利用者又は当該各利用者の連絡者が利用する利用者端末３０に送信する。

（ＤＢサーバ１０が管理する情報）
次に、ＤＢサーバ１０が管理する情報について詳述する。図３は、利用者情報ＤＢ１３１のデータ構成の一例を示す図である。尚、図３では、ある一の利用者に関する情報だけが示されているが、これは一例であり、複数の利用者の各々について利用者情報ＤＢ１３１は存在する。

利用者情報ＤＢ１３１には、利用者及び当該利用者と同居する家族のそれぞれについて一個の初期情報テーブルが割り当てられている。また、利用者情報ＤＢ１３１には、利用者が介護施設で行われる介護の各イベントに出席した場合に、当該利用者を介護するのに必要なスタッフ数（複数の利用者各々の介護に必要な介護者の人数の一例）を示す、一個のマンパワー情報テーブルが割り当てられている。以降、利用者を介護するスタッフ数をマンパワーと記載する。

図３の例では、利用者情報ＤＢ１３１には、氏名が「Ａ」の利用者に対応する初期情報テーブル１３１Ａと、当該利用者と同居する、当該利用者との続き柄が「娘」、「娘夫」、「孫１」、及び「孫２」の家族各々に対応する四個の初期情報テーブル１３１Ｂ、１３１Ｃ、１３１Ｄ、１３１Ｅと、氏名が「Ａ」の利用者に対応する一個のマンパワー情報テーブル１３１Ｘと、が割り当てられている。

初期情報テーブル１３１Ａは、「氏名」、「ニックネーム」、「年齢」、「介護／支援度」、「顔」、「同居家族」、「別居家族」、及び「連絡者」のフィールドを備える。「氏名」フィールドには利用者の氏名が記憶されている。「ニックネーム」フィールドには利用者のニックネームが記憶されている。「年齢」フィールドには利用者の年齢が記憶されている。「介護／支援度」フィールドには利用者の要介護認定結果が記憶されている。例えば、図３の初期情報テーブル１３１Ａでは、「要介護１」が記憶されている。「顔」フィールドには利用者の顔の画像データが記憶されている。「同居家族」フィールドには利用者と同居する家族が記憶されている。例えば、図３の初期情報テーブル１３１Ａでは、「娘」、「娘夫」、「孫１」、「孫２」が記憶されている。「別居家族」フィールドには利用者と別居する家族が記憶されている。例えば、図３の初期情報テーブル１３１Ａでは、「息子」が記憶されている。「連絡者」フィールドには利用者の連絡者が、連絡の優先順に記憶されている。例えば、図３の初期情報テーブル１３１Ａでは、「娘」、「息子」の順に、利用者の連絡者が記憶されている。これは、利用者に関する連絡を「娘」に対して行うことを優先し、当該連絡が取れなかった場合に「息子」に対して当該連絡を行うことを示している。

初期情報テーブル１３１Ｂ～１３１Ｅは、それぞれ、「続き柄」、「氏名」、「年齢」、「携帯ナンバー」、「所属」、「休日」、及び「備考」のフィールドを備える。「続き柄」フィールドには、利用者に対する続き柄が記憶されている。「氏名」、「年齢」は初期情報テーブル１３１Ａと同じである。「携帯ナンバー」フィールドには、利用者が利用する介護施設から貸し出された携帯電話の番号が記憶されている。「所属」フィールドには、利用者と同居する家族の所属組織が記憶されている。図３の例では、「娘」、「娘夫」、「孫１」、「孫２」の所属組織は、それぞれ、「Ｓ社」、「Ｐ社」、「Ｋ高校」、及び「Ｔ中学」である。「休日」フィールドには、利用者と同居する家族の休日が記憶されている。「備考」フィールドには、利用者の介護を行う上で参考になる、利用者と同居する家族に関連する情報が記憶されている。図３の例では、利用者の介護を行う上で参考になる「娘」、「孫１」、「孫２」に関連する情報は、それぞれ、「１０－１６勤務」、「気が利く」、及び「クラブで遅い」である。

マンパワー情報テーブル１３１Ｘには、介護施設で実施可能な介護のイベントと、利用者が当該イベントに出席した場合に必要なマンパワーと、が対応付けて記憶されている。図３のマンパワー情報テーブル１３１Ｘでは、例えば、イベント「食事」とマンパワー「０．１０」とが対応付けて記憶されている。ここで、マンパワーは、一時間当たりに必要なスタッフ数「人／時間」で表される。つまり、この例は、利用者がイベント「食事」に出席している間、一時間当たり「０．１０」人のスタッフによって、当該利用者を介護する必要があることを示している。

図４は、施設リソース情報ＤＢ１３２のデータ構成の一例を示す図である。施設リソース情報ＤＢ１３２には、介護施設の設備リソースに関する情報を記憶するための設備リソーステーブル１３２Ａと、介護施設の人的リソースに関する情報を記憶するための人的リソーステーブル１３２Ｂと、が割り当てられている。

具体的には、設備リソーステーブル１３２Ａには、介護施設が備える設備及び備品と、当該設備及び備品の定員と、当該設備及び備品の個数と、が対応付けて記憶されている。図４の設備リソーステーブル１３２Ａでは、例えば、介護施設が備える設備及び備品である「送迎バス」と、「送迎バス」の定員「５」と、「送迎バス」の個数「２」と、が対応付けて記憶されている。

人的リソーステーブル１３２Ｂには、時間帯と、当該時間帯にスタッフが出勤するか否かを示す出欠フラグと、が対応付けて記憶されている。例えば、図４の人的リソーステーブル１３２Ｂでは、時間帯「１０：００－１１：００」と、スタッフ「ＳＡ」が当該時間帯「１０：００－１１：００」に出勤することを示す出欠フラグ「１」と、スタッフ「ＳＢ」が当該時間帯「１０：００－１１：００」に出勤しないことを示す出欠フラグ「０」と、が対応付けて記憶されている。

図５は、スケジュール情報ＤＢ１３３のデータ構成の一例を示す図である。尚、図５では、ある一日における複数の利用者の介護のスケジュールに関する情報だけが示されているが、これは一例であり、複数の日についてスケジュール情報ＤＢ１３３は存在する。

スケジュール情報ＤＢ１３３には、ある一日における複数の利用者の介護のスケジュールに関するスケジュール情報を記憶するためのスケジュールテーブル１３３Ａが割り当てられている。具体的には、スケジュールテーブル１３３Ａには、時間帯と、当該時間帯に各利用者が出席する介護のイベントと、当該時間帯に必要なマンパワーと、を対応付けたスケジュール情報が記憶される。ここで、各時間帯に必要なマンパワーは、各利用者に対応するマンパワー情報テーブル１３１Ｘ（図３）に基づき、当該各時間帯に各利用者が各イベントに出席した場合に必要なマンパワーの合計値として算出される。

例えば、図５のスケジュールテーブル１３３Ａには、時間帯「１１：００－１２：００」と、時間帯「１１：００－１２：００」に利用者「Ａ」が出席する介護のイベント「入浴」と、時間帯「１１：００－１２：００」に利用者「Ｂ」が出席する介護のイベント「入浴」と、時間帯「１１：００－１２：００」に利用者「Ｃ」が出席する介護のイベント「入浴」と、時間帯「１１：００－１２：００」に利用者「Ｄ」が出席する介護のイベント「入浴」と、時間帯「１１：００－１２：００」に必要なマンパワー「２．００」と、が対応付けて記憶されている。

＜スケジュール情報の設定方法＞
スケジュール情報ＤＢ１３３に記憶されるスケジュール情報は、複数の利用者の人数、介護施設の設備リソース、介護施設の人的リソース、及び前記マンパワーに基づいて設定される。以下、ある対象日のスケジュール情報の設定方法の一例について、図６を用いて説明する。図６は、ある対象日のスケジュール情報の設定方法の一例を示す図である。

先ず、介護施設の利用者は、所定の期限日時までに、利用者端末３０に対して、利用者が所定期間（例えば一か月）内に介護施設を利用する日（以降、利用日）と、各利用日において利用者が出席する介護のイベントと、を示す情報（以降、入力スケジュール情報）を入力する。そして、利用者は、利用者端末３０を操作して、当該入力した入力スケジュール情報を施設端末５０へ送信する。施設端末５０において、通信部５３が利用者端末３０から送信された入力スケジュール情報を受信すると、プロセッサ５６は、通信部５３から当該入力スケジュール情報を取得する。また、プロセッサ５６は、通信部５３を制御して、当該取得した入力スケジュール情報をスケジュール情報ＤＢ１３３に記憶する。

前記所定の期限日時になると、プロセッサ５６は、通信部５３を制御して、各利用者に対応するマンパワー情報テーブル１３１Ｘ（図３）を参照して、対象日に介護施設を利用する各利用者が介護の各イベントに出席した場合に必要なマンパワーを把握する。例えば、図６の表１３１ＸＡには、対象日に介護施設を利用する各利用者「Ａ」、「Ｂ」、「Ｃ」、「Ｄ」が介護のイベント「入浴」に出席した場合に必要なマンパワーが、「０．２」、「０．３」、「０．５」、「１．０」であることを、プロセッサ５６が把握した例を示している。

また、プロセッサ５６は、通信部５３を制御して、スケジュール情報ＤＢ１３３に記憶されている、各利用者の入力スケジュール情報を参照する。これにより、プロセッサ５６は、対象日に各利用者が出席する介護のイベントを把握する。例えば、図６の表１３１ＸＢには、対象日に利用者「Ａ」～「Ｄ」が介護のイベント「送迎」、「バスの乗降」、「食事」、「入浴」、「体操／リハビリ」、「休憩／談話」に出席することを、プロセッサ５６が把握した例を示している。

プロセッサ５６は、これらの把握した内容に基づき、対象日において介護の各イベントを行う時間帯に必要なマンパワーを把握する。例えば、プロセッサ５６が、図６の表１３１ＸＡ、１３１ＸＢに示すように、対象日に各利用者「Ａ」～「Ｄ」が介護のイベント「入浴」に出席し、各利用者「Ａ」～「Ｄ」が介護のイベント「入浴」に出席した場合に必要なマンパワーが「０．２」、「０．３」、「０．５」、「１．０」であることを把握したとする。この場合、プロセッサ５６は、図６の表１３１ＸＣに示すように、当該把握したマンパワーの合計値「２．００」を、対象日に介護のイベント「入浴」を行う時間帯に必要なマンパワー「２．００」として把握する。

そして、プロセッサ５６は、これらの把握した情報１３１ＸＡ～１３１ＸＣと、施設リソース情報ＤＢ１３２に記憶されている情報（図４）と、に基づき、対象日において各イベントを行う時間帯を設定する。

具体的には、プロセッサ５６は、対象日の各時間帯に必要なマンパワー及び当該各時間帯にイベントに出席する利用者の人数が、介護施設の設備リソース及び人的リソースによって定められる制限条件を満たすように、対象日において各イベントを行う時間帯を設定する。前記制限条件は、設備リソーステーブル１３２Ａ（図４）に記憶されている、介護施設の設備及び備品の個数及び定員によって定められる制限条件と、人的リソーステーブル１３２Ｂ（図４）から把握される、各時間帯に出勤するスタッフ数によって定められる制限条件と、が該当する。

例えば、プロセッサ５６が、図６の表１３１ＸＢに示すように、対象日において、四人の利用者「Ａ」～「Ｄ」が出席するイベント「入浴」を行う時間帯を設定するものとする。この場合、プロセッサ５６は、設備リソーステーブル１３２Ａ（図４）に記憶されているイベント「入浴」に関連する設備「浴室」の個数「１」及び定員「４」によって、「１個の浴室に定員４名まで同時に入浴可能である。」という制限条件が定められていると判断する。また、プロセッサ５６は、人的リソーステーブル１３２Ｂ（図４）から把握される、各時間帯に出勤するスタッフ数によって、「１０：００－１１：００の時間帯は、１．００以下のマンパワーを確保可能である。」、「１１：００－１６：００の時間帯は、２．００以下のマンパワーを確保可能である。」という制限条件が定められていると判断する。

この場合、プロセッサ５６は、イベント「入浴」を行う時間帯がどの時間帯に設定されたとしても、上記の制限条件「１個の浴室に定員４名まで同時に入浴可能である。」を満たすと判断する。そこで、プロセッサ５６は、図６の表１３１ＸＣに示すように、対象日においてイベント「入浴」を行う時間帯に必要なマンパワー「２．００」が、上記の制限条件「１０：００－１１：００の時間帯に１．００以下のマンパワーを確保可能である。」及び「１１：００－１６：００の時間帯に２．００以下のマンパワーを確保可能である。」を満たすように、イベント「入浴」を行う時間帯を設定する。例えば、図５のスケジュールテーブル１３３Ａは、プロセッサ５６が、イベント「入浴」を行う時間帯を上記の制限条件を満たす「１１：００－１２：００」の時間帯に設定した例を示している。

また、プロセッサ５６は、対象日において介護の各イベントを行う時間帯を設定した後、当該設定後の各時間帯に必要なマンパワーを設定する。具体的には、図５のスケジュールテーブル１３３Ａに示すように、プロセッサ５６が、対象日に四人の利用者「Ａ」～「Ｄ」が出席するイベント「入浴」を行う時間帯を、時間帯「１１：００－１２：００」に設定したものとする。この場合、プロセッサ５６は、各利用者「Ａ」～「Ｄ」に対応するマンパワー情報テーブル１３１Ｘ（図３）を参照する。これにより、プロセッサ５６は、各利用者「Ａ」～「Ｄ」がイベント「入浴」に出席したときに必要なマンパワーが、「０．２」、「０．３」、「０．５」、「１．０」であることを把握する。そして、プロセッサ５６は、図５のスケジュールテーブル１３３Ａに示すように、これらの把握したマンパワーの合計値「２．００」を、時間帯「１１：００－１２：００」に必要なマンパワー「２．００」として設定する。

＜リスケジュール処理フロー＞
次に、本開示の介護サービス支援システム１において実行されるリスケジュール処理について説明する。利用者は、ノロウィルス及びインフルエンザ等の感染症及び風邪並びに疲労等の様々な原因で、介護施設を利用する当日に突然体調不良を訴える場合がある。そこで、介護サービス支援システム１では、利用者の体調不良の度合いを加味し、他の利用者の体調に影響を与えないように、且つ、介護施設のリソースを無駄にしないように、当日の各利用者の介護のスケジュールを改変するリスケジュール処理が行われる。図７及び図８は、本開示の介護サービス支援システム１において実行されるリスケジュール処理の一例を示すフローチャートである。

プロセッサ５６は、日付が変わる度にリスケジュール処理を実行する。図７に示すように、リスケジュール処理が開始されると、第一取得部５６１は、所定時刻になるまで、上述のように、リスケジュール処理が開始された当日に、介護施設を利用する利用者が使用する生体センサー２０（図１）又は利用者端末３０（図１）から送信された、利用者の当日の生体情報を取得する。そして、第一取得部５６１は、当該取得した生体情報を利用者情報ＤＢ１３１に記憶する（ステップＳ０１）。ここで、所定時刻は、例えば、介護施設の営業開始時刻よりも所定時間（例えば、１時間）前の時刻に設定されている。

尚、ステップＳ０１において、第一取得部５６１は、スケジュール情報ＤＢ１３３に記憶されている当日のスケジュール情報を参照して、当日の介護施設の利用者を把握する。第一取得部５６１は、前記所定時刻になるまでに、当日の生体情報を取得できなかった利用者が存在する場合、利用者情報ＤＢ１３１に記憶されている当該利用者の前日の生体情報を、当該利用者の当日の生体情報として取得する。

ただし、これに限らず、第一取得部５６１は、前記所定時刻になるまでに、当日の生体情報を取得できなかった利用者が存在する場合、予め定められた生体情報を、当該利用者の当日の生体情報として取得するようにしてもよい。ここで、予め定められた生体情報は、例えば、利用者が健康な状態であるときの生体情報とすればよい。

ステップＳ０１の後、第二取得部５６２は、ステップＳ０１で取得された生体情報のうち、利用者の当日の健康状態が所定の変更条件を満たすことを示す生体情報が存在するか否かを判定する（ステップＳ０２）。

ステップＳ０２において、第二取得部５６２が、利用者の当日の健康状態が変更条件を満たすことを示す生体情報が存在すると判定したとする（ステップＳ０２でＹＥＳ）。この場合、第二取得部５６２は、上述のように、当該生体情報に対応する対象利用者又は対象利用者の連絡者に対して、対象利用者が希望する当日の介護内容を問い合わせる（ステップＳ０３）。そして、第二取得部５６２は、利用者端末３０から送信された、対象利用者が希望する当日の介護内容に関する希望介護情報を取得する（ステップＳ０４）。これにより、健康状態が変更条件を満たす、軽微な体調不良の状態である利用者を対象利用者とし、当該対象利用者から当日の介護内容の希望に関する希望介護情報を取得できる。

一方、ステップＳ０２において、第二取得部５６２が、利用者の当日の健康状態が変更条件を満たすことを示す生体情報が存在しないと判定したとする（ステップＳ０２でＮＯ）。この場合、作成部５６３は、ステップＳ０１で取得された生体情報のうち、利用者の当日の健康状態が所定の隔離条件を満たすことを示す生体情報が存在するか否かを判定する（ステップＳ０５）。

ここで、隔離条件は、例えば、感染症、風邪又は高熱等が原因で利用者が体調不良を強く感じており、利用者を他者から隔離する必要があると考えられるときの、利用者の生体情報によって定められている。例えば、生体情報が利用者の体温を示す情報であるとする。この場合、隔離条件は、例えば、利用者の当日における体温が、所定の体温（例えば、３８℃）よりも高いことに定めればよい。

ステップＳ０５において、作成部５６３が、利用者の当日の健康状態が隔離条件を満たすことを示す生体情報が存在しないと判定したとする（ステップＳ０５でＮＯ）。この場合、ステップＳ０１で取得された生体情報の中に、利用者の当日の健康状態が所定の変更条件及び隔離条件を満たすことを示す生体情報が存在しないので、当日の利用者の中に、体調不良を訴える者は存在しないと考えられる。この場合、当日スケジュールを改変する必要がないので、プロセッサ５６は、リスケジュール処理を終了する。

一方、ステップＳ０４が行われた場合又はステップＳ０５において隔離条件を満たすことを示す生体情報が存在すると判定された場合（ステップＳ０５でＹＥＳ）、当日の利用者の中に、健康状態が変更条件又は隔離条件を満たす、体調不良を訴える利用者が存在すると考えられる。これらの場合、作成部５６３は、図８に示すように、ステップＳ１１～Ｓ１３を行う。これにより、作成部５６３は、ステップＳ０１で取得された生体情報と、ステップＳ０４で取得された希望介護情報と、スケジュール情報ＤＢ１３３に記憶されている当日のスケジュール情報と、施設リソース情報ＤＢ１３２に記憶されている施設リソース情報と、に基づいて、当日スケジュールを改変する。そして、作成部５６３は、当該改変後の当日スケジュールに関するリスケジュール案を作成する。

具体的には、ステップＳ１１では、作成部５６３は、スケジュール情報ＤＢ１３３から当日のスケジュール情報を取得する（ステップＳ１１）。

ステップＳ１２では、作成部５６３は、ステップＳ１１で取得したスケジュール情報において、当日に介護を受けることが設定されている利用者に対応する利用者情報（以降、当日の利用者情報）を、通信部５３を制御して、利用者情報ＤＢ１３１（図３）から取得する。また、作成部５６３は、通信部５３を制御して、施設リソース情報ＤＢ１３２（図４）に記憶されている施設リソース情報を取得する（ステップＳ１２）。

例えば、ステップＳ１１において図５に示すスケジュール情報が取得されたとする。この場合、ステップＳ１２において、作成部５６３は、当該取得したスケジュール情報（図５）において、当日に介護を受けることが設定されている利用者「Ａ」～「Ｄ」を把握する。そして、作成部５６３は、利用者情報ＤＢ１３１（図３）の初期情報テーブル１３１Ａ～１３１Ｅ（図３）及びマンパワー情報テーブル１３１Ｘ（図３）から、当該把握した利用者「Ａ」～「Ｄ」に対応付けられている利用者情報を、当日の利用者情報として取得する。また。ステップＳ１２において、作成部５６３は、施設リソース情報ＤＢ１３２（図４）に備えられた設備リソーステーブル１３２Ａ（図４）及び人的リソーステーブル１３２Ｂ（図４）に記憶されている情報を、施設リソース情報として取得する。

ステップＳ１３では、作成部５６３は、ステップＳ０１、Ｓ０４、Ｓ１１及びＳ１２で取得した、利用者の当日の生体情報、希望介護情報、当日のスケジュール情報、当日の利用者情報及び施設リソース情報に基づいて、前記当日のスケジュール情報が示す当日スケジュールを改変する。そして、作成部５６３は、当該改変後のスケジュールに関するリスケジュール案を作成する（ステップＳ１３）。このように、ステップＳ１３では、利用者の当日の生体情報及び当日のスケジュール情報だけでなく、対象利用者から取得した希望介護情報にも基づき、リスケジュール案が作成される。このため、対象利用者が希望する当日の介護内容を加味して、対象利用者が希望する介護を受けることができるリスケジュール案を作成できる。尚、ステップＳ１３の詳細については後述する。

次に、ステップＳ０２において利用者の当日の健康状態が変更条件を満たすことを示す生体情報が存在すると判定され、当該生体情報に対応する対象利用者が存在したとする（ステップＳ１４でＹＥＳ）。この場合、通知部５６４は、対象利用者に対して、ステップＳ１３で作成されたリスケジュール案における対象利用者の当日スケジュールが、対象利用者の希望通りであるか否かの確認を要求する（ステップＳ１５）。

具体的には、ステップＳ１５において、通知部５６４は、利用者情報ＤＢ１３１に記憶されている前記通信情報テーブルを参照して、対象利用者又は当該対象利用者の連絡者が利用する利用者端末３０のアドレスを取得する。そして、通知部５６４は、通信部５３を制御して、ステップＳ１３で作成されたリスケジュール案における対象利用者の当日スケジュールに関する情報とともに、当該当日スケジュールが希望通りであるか否かの確認を要求するメッセージを前記取得したアドレス宛に送信する。

これに応じて、対象利用者又は当該対象利用者の連絡者が利用する利用者端末３０では、通信部がリスケジュール案における対象利用者の当日の介護のスケジュールに関する情報及び前記メッセージを受信すると、プロセッサは、通信部が受信した情報及びメッセージを表示部に表示する。これにより、対象利用者又は当該対象利用者の連絡者は、ステップＳ１３で作成されたリスケジュール案における対象利用者の当日スケジュールが対象利用者の希望通りであるかを確認できる。そして、対象利用者は、利用者端末３０を操作して、利用者端末３０に対象利用者の希望通りであるか否かの確認結果を入力し、当該入力した確認結果を施設端末５０に送信する。

ステップＳ１５の後、利用者端末３０から送信され、通信部５３が受信した確認結果が、対象利用者の希望通りであることを示していたとする（ステップＳ１６でＹＥＳ）。この場合、通知部５６４は、当日のスケジュール情報を更新及び通知する処理を行う（ステップＳ１７）。

具体的には、ステップＳ１７において、通知部５６４は、通信部５３を制御して、ステップＳ１３で作成されたリスケジュール案によって、スケジュール情報ＤＢ１３３に記憶されている当日のスケジュール情報を更新する。

そして、通知部５６４は、ステップＳ１３で作成されたリスケジュール案における各利用者の当日スケジュールに関する情報を当日の各利用者に通知する。具体的には、通知部５６４は、利用者情報ＤＢ１３１に記憶されている前記通信情報テーブルを参照して、当日の各利用者又は当該各利用者の連絡者が利用する利用者端末３０のアドレスを取得する。そして、通知部５６４は、通信部５３を制御して、ステップＳ１３で作成されたリスケジュール案における各利用者の当日スケジュールに関する情報を、前記取得したアドレス宛に送信する。

また、通知部５６４は、ステップＳ１３で作成されたリスケジュール案を各スタッフに通知する。具体的には、通知部５６４は、通信部５３を制御して、施設リソース情報ＤＢ１３２に予め記憶されている、各スタッフが利用するスタッフ端末４０のアドレスを参照する。そして、通知部５６４は、通信部５３を制御して、ステップＳ１３で作成されたリスケジュール案を、前記参照したアドレス宛に送信する。

尚、ステップＳ０５（図７）において利用者の当日の健康状態が隔離条件を満たすことを示す生体情報が存在すると判定された場合には（ステップＳ０５でＹＥＳ）、対象利用者が存在しない場合でも（ステップＳ１４でＮＯ）、ステップＳ１３においてリスケジュール案が作成される。したがって、この場合も（ステップＳ１４でＮＯ）、ステップＳ１７が行われる。ステップＳ１７の後、プロセッサ５６は、リスケジュール処理を終了する。

一方、ステップＳ１５の後、利用者端末３０から送信され、通信部５３が受信した確認結果が、対象利用者の希望通りでない（対象利用者が希望するスケジュールと一致しない）ことを示していたとする（ステップＳ１６でＮＯ）。更に、ステップＳ１３において作成部５６３が複数のリスケジュール案を作成し、当該複数のリスケジュール案のうち、ステップＳ１５で用いられていないリスケジュール案（以降、未確認のリスケジュール案）が存在していたとする（ステップＳ１８でＹＥＳ）。

この場合、通知部５６４は、ステップＳ１５と同様にして、対象利用者に対して、未確認のリスケジュール案における対象利用者の当日スケジュールが、対象利用者の希望通りであるか否かの確認を要求する（ステップＳ１９）。ステップＳ１９の後、対象利用者が利用する利用者端末３０から送信され、通信部５３が受信した確認結果が、対象利用者の希望通りでない（対象利用者が希望するスケジュールと一致しない）ことを示していたとする（ステップＳ２０でＮＯ）。この場合、ステップＳ１８以降の処理が行われる。

一方、ステップＳ１９の後、対象利用者が利用する利用者端末３０から送信され、通信部５３が受信した確認結果が、対象利用者の希望通りであることを示していた場合（ステップＳ２０でＹＥＳ）、当該ステップＳ１９で用いた未確認のリスケジュール案を用いてステップＳ１７が行われる。

また、ステップＳ１３において作成部５６３が複数のリスケジュール案を作成したが、ステップＳ１８～Ｓ２０が繰り返された結果、未確認のリスケジュール案が存在しなくなったとする（ステップＳ１８でＮＯ）。この場合、ステップＳ０３以降の処理が行われる。これにより、ステップＳ０３において、対象利用者に対して当日の介護内容の希望を再度問い合わせ、ステップＳ０４において、前記希望介護情報を再取得し、ステップＳ１３において、当該再取得した希望介護情報を用いてリスケジュール案を再作成する。したがって、対象利用者が希望する介護を受けることができるリスケジュール案をより確実に作成できる。

以上のように、本構成によれば、軽微な体調不良の状態にある対象利用者が、希望する介護を受けることができるリスケジュール案を作成できる。このため、従来のように、当該対象利用者を無条件に自宅で静養させる場合よりも、介護施設のリソースに余剰が生じる機会を低減できる。その結果、介護施設の稼働率を向上することができる。

＜リスケジュール案の作成方法＞
次にステップＳ１３（図８）における作成部５６３によるリスケジュール案の作成方法の一例について説明する。尚、以下の説明では、生体情報は、利用者の体温を示す情報であるものとする。ステップＳ０２（図７）で用いる変更条件は、利用者の当日における体温が、当該当日の前日における体温よりも０．５℃を超えて上昇しており、且つ、３８℃以下であることに定められているものとする。ステップＳ０５（図７）で用いる隔離条件は、利用者の当日における体温が３８℃よりも高いことに定められているものとする。

尚、ステップＳ０２（図７）で用いる変更条件は、上記に限らず、例えば、利用者の当日における体温が、当該当日の前日における体温よりも０．５℃を超えて上昇していることに定められていてもよい。

また、図５に示すように、リスケジュール処理が実行される当日のスケジュール情報がスケジュールテーブル１３３Ａに記憶されている場合に、リスケジュール処理が実行されたものとする。これにより、ステップＳ０２及びステップＳ０５において、図９の表９１に示す判定結果が得られ、ステップＳ１３が実行されたものとする。

図９は、生体情報に応じて各利用者の介護内容を改変する処理の一例を示す図である。図９の表９１において、判定結果「△」は、各利用者の当日の体温が変更条件を満たすことを示す。判定結果「×」は、各利用者の当日の体温が上記の隔離条件を満たすことを示す。判定結果「〇」は、各利用者の当日の体温が上記の変更条件及び上記の隔離条件を共に満たしていないことを示す。つまり、図９の表９１は、利用者「Ａ」及び「Ｂ」の当日の体温が変更条件を満たし、利用者「Ｃ」の当日の体温が変更条件及び隔離条件を共に満たさず、利用者「Ｄ」の当日の体温が隔離条件を満たしていることを示している。

また、ステップＳ０４（図７）で取得された対象利用者「Ａ」の希望介護情報が在宅での介護を示し、ステップＳ０４で取得された対象利用者「Ｂ」の希望介護情報が介護施設が備える個室での介護を示すものとする。

この場合、利用者「Ａ」及び「Ｂ」の当日の体温は、変更条件を満たしているので、利用者「Ａ」及び「Ｂ」は、微熱又は疲労等によって軽微な体調不良を感じていると考えられる。このため、利用者「Ａ」及び「Ｂ」が介護施設に訪問したとしても、介護施設において他の利用者の体調をあまり悪化させないと考えられる。したがって、作成部５６３は、このように軽微な体調不良を感じていると考えられる対象利用者の介護内容を、当該対象利用者から取得した希望介護情報が示す介護内容に仮決定する。

具体的には、作成部５６３は、図９の表９２において記号「○」で示すように、対象利用者「Ａ」の介護内容を、ステップＳ０４で取得した対象利用者「Ａ」の希望介護情報が示す在宅での介護「３．訪問」に仮決定する。同様に、作成部５６３は、対象利用者「Ｂ」の介護内容を、ステップＳ０４で取得した対象利用者「Ｂ」の希望介護情報が示す、個室での介護「２．個室」に仮決定する。

利用者「Ｃ」の当日の体温は、上記の変更条件及び上記の隔離条件を共に満たしていないので、利用者「Ｃ」は、平熱であると考えられる。この場合、利用者「Ｃ」が介護施設に訪問したとしても、介護施設において他の利用者の体調に影響を与えないと考えられる。このため、作成部５６３は、このように平熱と考えられる当日の利用者の介護内容は改変しない。

具体的には、図５のスケジュールテーブル１３３Ａに示すように、利用者「Ｃ」の当日スケジュールは、介護施設において通常行われる介護の内容となっている。このため、作成部５６３は、図９の表９２において記号「◎」で示すように、利用者「Ｃ」の介護内容を、通常通りの介護「１．通常」に確定する。

利用者「Ｄ」の当日の体温は、上記の隔離条件を満たしているので、利用者「Ｄ」は、感染症又は高熱等によって体調不良を強く感じていると考えられる。この場合、利用者「Ｄ」が介護施設に訪問すると、介護施設において病気が流行する虞があると考えられる。このため、作成部５６３は、このように体調不良を強く感じていると考えられる利用者の介護内容を、自宅での静養に確定する。

具体的には、作成部５６３は、図９の表９２において記号「◎」で示すように、利用者「Ｄ」の介護内容を、自宅での静養「４．自宅」に確定する。

次に、作成部５６３は、介護内容が確定した利用者「Ｃ」及び「Ｄ」の当日スケジュールを改変する。具体的には、作成部５６３は、先ず、図１０の表１０１に示すように、介護内容が確定した利用者「Ｃ」及び「Ｄ」が出席するイベントを、当該確定した介護内容に応じて設定する。

図１０は、生体情報に応じて介護内容が確定された利用者の介護のスケジュールを改変する処理の一例を示す図である。図１０の表１０１において、「１」は利用者がイベントに出席することを示し、「０」は利用者がイベントに欠席することを示している。

作成部５６３は、図１０の表１０１に示すように、介護内容が通常通りの介護に確定した利用者「Ｃ」が出席するイベントを、通常通りの介護で行われるイベント「送迎」、「バスの乗降」、「食事」、「入浴」、「体操／リハビリ」、「休憩／談話」に設定する。

一方、介護内容が自宅での静養「４．自宅」に確定した利用者「Ｄ」は、介護施設で行われる介護のイベントに出席できない。このため、作成部５６３は、図１０の表１０１に示すように、利用者「Ｄ」が全てのイベントに欠席することを設定する。

作成部５６３は、介護内容が確定した利用者「Ｃ」及び「Ｄ」が出席するイベントの設定を終えると、図１０の表１０１に示すように、介護内容が仮決定した利用者「Ａ」及び「Ｂ」が全てのイベントに欠席することを仮設定する。

次に、作成部５６３は、通信部５３を制御して、各利用者に対応するマンパワー情報テーブル１３１Ｘ（図３）を参照し、介護内容が確定した利用者「Ｃ」及び「Ｄ」が、当該介護内容に応じて設定された各イベントに出席した場合に必要なマンパワーを把握する。

具体的には、作成部５６３は、利用者「Ｃ」に対応するマンパワー情報テーブル１３１Ｘを参照し、図１０の表１０２に示すように、利用者「Ｃ」が、介護内容に応じて設定されたイベント「送迎」、「バスの乗降」、「食事」、「入浴」、「体操／リハビリ」、「休憩／談話」に出席した場合に必要なマンパワーが、「０．２５」、「０．２０」、「０．３０」、「０．５０」、「０．１０」、「０．１０」であることを把握する。

一方、作成部５６３は、上述のように、利用者「Ｄ」の介護内容に応じて、利用者「Ｄ」が全てのイベントに欠席することを設定した。このため、作成部５６３は、図１０の表１０２に示すように、利用者「Ｄ」が介護内容に応じたイベントに出席した場合に必要なマンパワーは、「０．００」であることを把握する。

次に、作成部５６３は、介護内容が仮決定した利用者が、当該仮決定した介護内容に応じて仮設定された各イベントに出席した場合に必要なマンパワーを把握する。

具体的には、作成部５６３は、上述のように、介護内容が仮決定した利用者「Ａ」及び「Ｂ」が全てのイベントに欠席することを、当該仮決定した介護内容に応じて仮設定した。このため、作成部５６３は、図１０の表１０２に示すように、利用者「Ａ」及び「Ｂ」が介護内容に応じたイベントに出席した場合に必要なマンパワーは、「０．００」であることを把握する。

そして、作成部５６３は、これらの把握した内容に基づき、介護内容が確定された利用者の介護だけを行う場合において、各イベントを行う時間帯に必要なマンパワーを把握する。また、作成部５６３は、当該把握したマンパワーを、リスケジュール処理を行う前の当日スケジュールにおいて、各イベントを行う時間帯に必要なマンパワーから減算する。これにより、作成部５６３は、当該減算の結果を、介護内容が確定されていない利用者の介護を行う場合に、当該利用者が各イベントを行う時間帯に割り当てることができる、マンパワーの余剰として把握する。

例えば、図１０の表１０２に示すように、イベント「入浴」を行う時間帯には、利用者「Ｃ」がイベント「入浴」に出席した場合のマンパワー「０．５０」だけが必要になる。このため、作成部５６３は、図１０の表１０２の「マンパワー」欄に示すように、イベント「入浴」を行う時間帯に必要なマンパワーは「０．５０」であることを把握する。また、作成部５６３は、当該把握したマンパワー「０．５０」を、リスケジュール処理を行う前の当初の当日スケジュール（図５）において、イベント「入浴」を行う時間帯に必要なマンパワー「２．００」から減算する。これにより、作成部５６３は、当該減算の結果「１．５０」を、介護内容が確定されていない利用者「Ａ」及び「Ｂ」の介護を行う場合に、当該利用者「Ａ」及び「Ｂ」が各イベントを行う時間帯に割り当てることができる、マンパワーの余剰「１．５０」として把握する。

そして、作成部５６３は、これらの把握した情報と、施設リソース情報ＤＢ１３２に記憶されている情報（図４）と、に基づき、介護内容が確定された利用者が各イベントを行う時間帯を設定する。

具体的には、作成部５６３は、プロセッサ５６がスケジュール情報を生成する場合と同様にして、各時間帯に必要なマンパワー及び当該各時間帯にイベントに出席する利用者の人数が、介護施設の設備リソース及び人的リソースによって定められる制限条件を満たすように、介護内容が確定された利用者が各イベントを行う時間帯を設定する。また、作成部５６３は、プロセッサ５６がスケジュール情報を生成する場合と同様にして、各イベントを行う時間帯を設定した後、当該設定後の各時間帯に必要なマンパワーを設定する。

例えば、作成部５６３が、図１０の表１０１に示すように、利用者「Ｃ」が出席するイベント「入浴」を行う時間帯を設定するものとする。この場合、作成部５６３は、設備リソーステーブル１３２Ａ（図４）に記憶されているイベント「入浴」に関連する設備「浴室」の個数「１」及び定員「４」によって、「１個の浴室に定員４名まで同時に入浴可能である。」という制限条件が定められていると判断する。また、作成部５６３は、人的リソーステーブル１３２Ｂ（図４）から把握される、各時間帯に出勤するスタッフ数によって、「１０：００－１１：００の時間帯は、１．００以下のマンパワーを確保可能である。」、「１１：００－１６：００の時間帯は、２．００以下のマンパワーを確保可能である。」という制限条件が定められていると判断する。

この場合、作成部５６３は、イベント「入浴」を行う時間帯がどの時間帯に設定されたとしても、上記の制限条件「１個の浴室に定員４名まで同時に入浴可能である。」を満たすと判断する。そこで、作成部５６３は、図１０の表１３３－０に示すように、イベント「入浴」を行う時間帯に必要なマンパワー「０．５０」が、上記の制限条件「１０：００－１１：００の時間帯に１．００以下のマンパワーを確保可能である。」及び「１１：００－１６：００の時間帯に２．００以下のマンパワーを確保可能である。」を満たすように、イベント「入浴」を行う時間帯を設定する。例えば、図１０の表１３３－０は、作成部５６３が、イベント「入浴」を行う時間帯を、上記の制限条件を満たし、且つ、リスケジュール処理を行う前の当初の当日スケジュール（図５）と同じ「１１：００－１２：００」の時間帯に設定した例を示している。

そして、作成部５６３は、図１０の表１０２に示すように、利用者「Ｃ」がイベント「入浴」に出席したときに必要なマンパワーが「０．５０」であることを把握しているので、図１０の表１３３－０に示すように、当該把握したマンパワー「０．５０」を、時間帯「１１：００－１２：００」に必要なマンパワー「０．５０」として設定する。

次に、作成部５６３は、介護内容が仮決定した利用者「Ａ」及び「Ｂ」の当日スケジュールを改変する。具体的には、作成部５６３は、先ず、図１１の表１１１に示すように、介護内容が仮決定した利用者「Ａ」及び「Ｂ」が出席するイベントを当該仮決定した介護内容に応じて設定する。

図１１は、対象利用者が希望する介護内容に応じて、対象利用者の介護のスケジュールを改変する処理の一例を示す図である。図１１の表１１１において、「１」は対象利用者又は利用者がイベントに出席することを示し、「０」は対象利用者又は利用者がイベントに欠席することを示している。

作成部５６３は、図１１の表１１１に示すように、介護内容が在宅での介護に仮決定した対象利用者「Ａ」が出席するイベントを、在宅での介護で行われるイベント「訪問」に設定する。また、作成部５６３は、図１１の表１１１に示すように、介護内容が個室での介護に仮決定した対象利用者「Ｂ」が出席するイベントを、個室での介護で行われるイベント「送迎」、「バスの乗降」、「食事」、「静養」に設定する。

次に、作成部５６３は、通信部５３を制御して、各対象利用者に対応するマンパワー情報テーブル１３１Ｘ（図３）を参照し、介護内容が仮決定した対象利用者「Ａ」及び「Ｂ」が、当該介護内容に応じて設定された各イベントに出席した場合に必要なマンパワーを把握する。

具体的には、作成部５６３は、対象利用者「Ａ」に対応するマンパワー情報テーブル１３１Ｘを参照し、図１１の表１１２に示すように、対象利用者「Ａ」が、介護内容に応じて設定されたイベント「訪問」に出席した場合に必要なマンパワーが「１．００」であることを把握する。同様にして、作成部５６３は、対象利用者「Ｂ」に対応するマンパワー情報テーブル１３１Ｘを参照し、図１１の表１１２に示すように、対象利用者「Ｂ」が、介護内容に応じて設定されたイベント「送迎」、「バスの乗降」、「食事」、「静養」に出席した場合に必要なマンパワーが「０．２５」、「０．００」、「０．１０」、「０．００」であることを把握する。

そして、作成部５６３は、以上の把握した内容に基づき、当日スケジュールの改変後、各イベントを行う時間帯に必要なマンパワーを把握する。また、作成部５６３は、当該把握したマンパワーを、リスケジュール処理を行う前の当日スケジュールにおいて、各イベントを行う時間帯に必要なマンパワーから減算する。これにより、作成部５６３は、当該減算の結果を、当日スケジュールを改変したことによって、各イベントを行う時間帯に生じるマンパワーの差分として把握する。

例えば、図１１の表１１２に示すように、対象利用者「Ａ」、「Ｂ」及び利用者「Ｄ」のスケジュールを改変すると、イベント「入浴」を行う時間帯には、利用者「Ｃ」がイベント「入浴」に出席した場合のマンパワー「０．５０」だけが必要になる。このため、作成部５６３は、図１１の表１１２の「マンパワー」欄に示すように、当日スケジュールの改変後、イベント「入浴」を行う時間帯に必要なマンパワーは「０．５０」であることを把握する。また、作成部５６３は、当該把握したマンパワー「０．５０」を、リスケジュール処理を行う前の当初の当日スケジュール（図５）において、イベント「入浴」を行う時間帯に必要なマンパワー「２．００」から減算する。これにより、作成部５６３は、当該減算の結果「１．５０」を、当日スケジュールを改変したことによって、イベント「入浴」を行う時間帯に生じるマンパワーの差分として把握する。

一方、図１１の表１１２に示すように、対象利用者「Ａ」のスケジュールを改変したことによって、対象利用者「Ａ」がイベント「訪問」に出席した場合のマンパワー「１．００」が必要になる。このため、作成部５６３は、図１１の表１１２の「マンパワー」欄に示すように、当日スケジュールの改変後、イベント「訪問」を行う時間帯に必要なマンパワーは「１．００」であることを把握する。ただし、リスケジュール処理を行う前の当初の当日スケジュール（図５）において、イベント「訪問」を行う時間帯は存在しない。このため、作成部５６３は、当該把握したマンパワー「１．００」を、リスケジュール処理を行う前の当初の当日スケジュールにおいて、イベント「訪問」を行う時間帯に必要なマンパワー「０．００」から減算する。これにより、作成部５６３は、当該減算の結果「－１．００」を、当日スケジュールを改変したことによって、イベント「訪問」を行う時間帯に生じるマンパワーの差分として把握する。

そして、作成部５６３は、これらの把握した情報と、施設リソース情報ＤＢ１３２に記憶されている情報（図４）と、に基づき、介護内容が仮決定された対象利用者が各イベントを行う時間帯を設定する。また、作成部５６３は、各イベントを行う時間帯を設定した後、プロセッサ５６がスケジュール情報を生成する場合と同様にして、当該設定後の各時間帯に必要なマンパワーを設定する。

尚、対象利用者が複数存在する場合、作成部５６３は、所定の作成条件に従って、当該時間帯の設定を行う対象の対象利用者の順番を決定する。本例では、作成条件は、介護内容が個室での介護に仮決定された対象利用者を、介護内容が在宅での介護に仮決定された対象利用者よりも優先することに、定められているものとする。ただし、作成条件は、これに限らず、例えば対象利用者の年齢順等であってもよい。

具体的には、作成部５６３は、上記作成条件に従い、介護内容が個室での介護に仮決定された対象利用者「Ｂ」を、介護内容が在宅での介護に仮決定された対象利用者「Ａ」よりも優先し、先ず、対象利用者「Ｂ」が各イベントを行う時間帯を設定する。

詳述すると、作成部５６３は、プロセッサ５６がスケジュール情報を生成する場合と同様にして、各時間帯に必要なマンパワー及び当該各時間帯にイベントに出席する利用者の人数が、介護施設の設備リソース及び人的リソースによって定められる制限条件を満たすように、介護内容が仮決定された対象利用者「Ｂ」が各イベントを行う時間帯を設定する。

これにより、例えば、作成部５６３は、図１１の表１３１－１、１３１－２に示すように、対象利用者「Ｂ」が出席するイベント「送迎」、「バスの乗降」、「食事」、「静養」を行う時間帯を、「１０：００－１０：４０、１６：１０－１６：５０」、「１０：４０－１０：５０、１６：００－１６：１０」、「１２：００－１３：００」、「１０：５０－１２：００、１３：００－１６：００」に設定する。そして、作成部５６３は、プロセッサ５６がスケジュール情報を生成する場合と同様にして、当該時間帯に必要なマンパワーを設定する。

次に、作成部５６３は、介護内容が在宅での介護に仮決定された対象利用者「Ａ」がイベント「訪問」を行う時間帯を設定する。ただし、図１１の表１１２に示すように、当日スケジュールを改変したことによって、イベント「訪問」を行う時間帯に生じるマンパワーの差分が負の値「－１．００」を示している。これは、リスケジュール処理の実行前よりも、マンパワーが「１．００」だけ多く必要になったことを示す。このため、対象利用者「Ａ」がイベント「訪問」を行う時間帯を不用意に設定すると、当該設定した時間帯においてマンパワーが不足する虞がある。そこで、作成部５６３は、対象利用者「Ａ」がイベント「訪問」を行う時間帯を、前記マンパワーの差分が大きいイベントが設定されている時間帯から優先して決定する。

具体的には、図１１の表１１２に示すように、当日スケジュールを改変したことによって、イベント「入浴」を行う時間帯に生じるマンパワーの差分が「１．５０」であり、イベント「食事」を行う時間帯に生じるマンパワーの差分が「０．６０」となっている。このため、作成部５６３は、先ず、対象利用者「Ａ」がイベント「訪問」を行う時間帯を、前記マンパワーの差分が最も大きいイベント「入浴」が設定されている時間帯「１１：００－１２：００」に設定することを検討する。

具体的には、作成部５６３は、当該設定を行ったと仮定する。この場合、図１１の表１３３－１に示すように、対象利用者「Ａ」がイベント「訪問」を行う時間帯「１１：００－１２：００」に必要なマンパワーは「１．５０」となり、人的リソーステーブル１３２Ｂ（図４）から把握される、「１１：００－１６：００の時間帯は、２．００以下のマンパワーを確保可能である。」という制限条件を満たすことになる。よって、作成部５６３は、対象利用者「Ａ」がイベント「訪問」を行う時間帯を、イベント「入浴」が設定されている時間帯「１１：００－１２：００」に設定する。そして、作成部５６３は、プロセッサ５６がスケジュール情報を生成する場合と同様にして、当該時間帯に必要なマンパワーを設定する。

これにより、作成部５６３は、図１１の表１３３－１に示す、時間帯と当該時間帯に各利用者が出席する介護のイベントと当該時間帯に必要なマンパワーとを対応付けたスケジュール情報を、第一のリスケジュール案として作成する。

上記と同様にして、作成部５６３は、対象利用者「Ａ」がイベント「訪問」を行う時間帯を、前記マンパワーの差分が次に大きい値「０．６０」となっている、イベント「食事」が設定されている時間帯「１２：００－１３：００」に設定することを検討する。

具体的には、作成部５６３は、対象利用者「Ａ」がイベント「訪問」を行う時間帯を、前記マンパワーの差分が次に大きいイベント「食事」が設定されている時間帯「１２：００－１３：００」に設定したと仮定する。図１１の表１３３－２に示すように、この場合、対象利用者「Ａ」がイベント「訪問」を行う時間帯「１２：００－１３：００」に必要なマンパワーは「１．４０」となり、人的リソーステーブル１３２Ｂ（図４）から把握される、「１１：００－１６：００の時間帯は、２．００以下のマンパワーを確保可能である。」という制限条件を満たすことになる。よって、作成部５６３は、対象利用者「Ａ」がイベント「訪問」を行う時間帯を、イベント「食事」が設定されている時間帯「１２：００－１３：００」に設定する。そして、作成部５６３は、プロセッサ５６がスケジュール情報を生成する場合と同様にして、当該時間帯に必要なマンパワーを設定する。

これにより、作成部５６３は、図１１の表１３３－２に示す、時間帯と当該時間帯に各利用者が出席する介護のイベントと当該時間帯に必要なマンパワーとを対応付けたスケジュール情報を、第二のリスケジュール案として作成する。

一方、対象利用者が各イベントを行う時間帯をある時間帯に設定することを仮定した場合に、当該時間帯に必要なマンパワーが制限条件を満たさなかったとする。この場合、作成部５６３は、当該仮定した設定はできないと判断し、対象利用者が各イベントを行う時間帯を他の時間帯に設定することを検討する。

上記と同様にして、作成部５６３は、所定数のリスケジュール案を作成する。

（変形例）
本開示は下記の変形例が採用できる。

（１）上記実施形態では、利用者が介護施設を利用する当日に、施設端末５０が、利用者端末３０から、生体情報として、利用者の体温を示す情報を取得する例について説明した。しかし、これに限らず、利用者が介護施設を利用する当日に、施設端末５０が、利用者端末３０から、更に、当該利用者と同居する家族が当該当日に感染症に罹患しているか否かを示す罹患情報を取得するようにしてもよい。

具体的には、介護施設の利用者又は当該利用者の連絡者が、前記罹患情報を利用者端末３０に入力し、利用者端末３０を操作して、当該入力した罹患情報を施設端末５０に送信するようにすればよい。そして、第一取得部５６１が、利用者端末３０（図１）から送信され、通信部５３が受信した罹患情報を通信部５３から取得するようにすればよい。

そして、ステップＳ０２（図７）で用いる変更条件を、利用者の当日における体温が、当該当日の前日における体温よりも所定の値（例えば、０．５℃）を超えて上昇しており、且つ、当該利用者についての前記罹患情報が、感染症に罹患していないことを示すことに設定してもよい。そして、ステップＳ０５（図７）で用いる隔離条件を、利用者の当日における体温が、所定の体温（例えば、３８℃）よりも高い、又は、当該利用者についての前記罹患情報が、当該利用者と同居する家族が当該当日に感染症に罹患していることを示すことに設定してもよい。

例えば、利用者の当日の体温が当該当日の前日における体温よりも所定の値を超えて上昇していたとしても、当該利用者についての罹患情報が、当該利用者と同居する家族が当該当日に感染症に罹患していることを示しているとする。この場合、本構成では、ステップＳ０２（図７）において、当該利用者の生体情報は、当該利用者の当日の健康状態が変更条件を満たすことを示す生体情報ではないと判定される。

一方、ステップＳ０５（図７）では、当該利用者の生体情報は、当該利用者の当日の健康状態が隔離条件を満たすことを示す生体情報であると判定される。これにより、ステップＳ１３（図８）におけるリスケジュール案の作成において、介護施設を利用する当日に同居する家族が感染症に罹患している利用者の介護内容を、自宅での静養に改変することができる。その結果、当該利用者が、希望する介護を受けることで、他の利用者が感染症に感染するリスクを低減できる。

（２）上記実施形態では、生体センサー２０又は利用者端末３０から利用者の当日の生体情報を取得し、ステップＳ０２において、利用者の健康状態が所定の変更条件を満たすことを示す生体情報の有無を判定していた。しかし、これに代えて、利用者又はその連絡者が、利用者端末３０に利用者の健康状態を表す情報（以降、健康情報）を入力し、利用者端末３０を操作して、施設端末５０に送信するようにしてもよい。そして、ステップＳ０２において、利用者の健康状態が所定の変更条件を満たすことを示す健康情報の有無を判定するようにしてもよい。

（３）ステップＳ０５（図７）を省略し、ステップＳ０２（図７）において、利用者の健康状態が変更条件を満たすことを示す生体情報が存在しないと判定された場合は、リスケジュール処理を終了するようにしてもよい。

（４）上記実施形態では、ステップＳ３（図７）において、第二取得部５６２が、対象利用者又は当該対象利用者の連絡が利用する利用者端末３０に対して、当日の介護内容の希望を問い合わせる旨のメッセージを送信する例について説明した。しかし、これに代えて、第二取得部５６２が、対象利用者に対して当日の介護内容の希望を問い合わせるよう、スタッフに指示する旨のメッセージを、スタッフ端末４０に対して送信するようにしてもよい。これに応じて、スタッフ端末４０では当該メッセージを示す音声をスピーカによって出力するようにしてもよい。これにより、当該スタッフ端末４０を利用するスタッフが、電話等で対象利用者の当日の介護内容の希望を問い合わせるようにしてもよい。

これと同様にして、ステップＳ１５（図８）及びＳ１９（図８）において、通知部５６４が、リスケジュール案における対象利用者の当日スケジュールが希望通りであるか否かの確認を対象利用者に要求するよう、スタッフに指示する旨のメッセージを、スタッフ端末４０に対して送信するようにしてもよい。これにより、当該スタッフ端末４０を利用するスタッフが、電話等で対象利用者に、リスケジュール案における対象利用者の当日スケジュールが希望通りであるか否かの確認を要求するようにしてもよい。

（５）ステップＳ１３において、作成部５６３がリスケジュール案の作成時に用いる作成条件を複数定めてもよい。そして、ステップＳ１８（図８）において、未確認のリスケジュール案が存在しなくなった場合に、作成条件を未使用の作成条件に変更してステップＳ１３（図８）以降の処理を行うことを、未使用の作成条件がなくなるまで繰り返すようにしてもよい。この場合、作成部５６３によって多様なリスケジュール案を作成させることができる。これにより、対象利用者に当日の介護内容を再度問い合わせる機会を低減できる。

（６）上記の実施形態及び変形実施形態では、施設端末５０が全処理を行う形態について説明したが、これに替えて、施設端末５０が行う処理と同様の処理を、ＤＢサーバ１０が実行するようにしてもよい。この場合、生体センサー２０、利用者端末３０、及びスタッフ端末４０と施設端末５０との間で種々の情報を通信する処理と同様の通信処理を、生体センサー２０、利用者端末３０、及びスタッフ端末４０とＤＢサーバ１０との間で、施設端末５０を介さずに又は施設端末５０を介して、行うようにしてもよい。

又は、ステップＳ１７（図８）を以下のように変更してもよい。つまり、通知部５６４がリスケジュール案をＤＢサーバ１０に送信し、これに応じて、ＤＢサーバ１０のプロセッサが、ステップＳ１７（図８）と同様に、当該送信されたリスケジュール案を更新及び通知する処理を行うようにしてもよい。

本開示によれば、介護施設において病気が流行するリスクを低減しつつ、介護施設の稼働率を向上するうえで有用である。

１ ：介護サービス支援システム
５６１ ：第一取得部
５６２ ：第二取得部
５６３ ：作成部
５６４ ：通知部

Claims (10)

1. 介護サービス支援システムのコンピュータが、
   複数の利用者各々について当日の健康状態に関する情報である健康情報を取得し、
   前記複数の利用者のうち、前記健康情報が示す前記当日の健康状態が所定の条件を満たす対象利用者に対し、前記当日の介護内容の希望を問い合わせて前記当日の介護内容の希望に関する希望介護情報を取得し、
   前記健康情報及び前記希望介護情報と、予め設定されている前記複数の利用者各々の前記当日の介護のスケジュールに関するスケジュール情報と、に基づいて、前記スケジュールを改変して、当該改変後のスケジュールに関するリスケジュール案を作成し、
   前記複数の利用者各々に対し、前記リスケジュール案における各利用者の前記当日の介護のスケジュールに関する情報を通知する、
   介護サービス支援方法。
2. 前記健康情報は、前記複数の利用者各々の前記当日における体温に関する情報である、
   請求項１に記載の介護サービス支援方法。
3. 前記所定の条件は、前記複数の利用者各々の前記当日における体温が、前記当日の前日における体温よりも所定の値を超えて上昇していることである、
   請求項２に記載の介護サービス支援方法。
4. 前記所定の条件は、前記複数の利用者各々の前記当日における体温が、前記当日の前日における体温よりも所定の値を超えて上昇しており、且つ、所定の体温以下であることである、
   請求項２に記載の介護サービス支援方法。
5. 前記コンピュータは、更に、前記複数の利用者各々について同居する家族が前記当日において感染症に罹患しているか否かを示す罹患情報を取得し、
   前記所定の条件は、前記複数の利用者各々の前記当日における体温が、前記当日の前日における体温よりも所定の値を超えて上昇しており、且つ、当該複数の利用者各々についての前記罹患情報が感染症に罹患していないことを示すことである、
   請求項２に記載の介護サービス支援方法。
6. 前記介護内容には、個室での介護及び在宅での介護が含まれる、
   請求項１に記載の介護サービス支援方法。
7. 前記スケジュール情報は、前記複数の利用者の人数、前記複数の利用者が利用する介護施設の設備リソース、前記複数の利用者各々の介護に必要な介護者の人数、及び前記介護施設の人的リソースに基づいて設定されている、
   請求項１に記載の介護サービス支援方法。
8. 前記リスケジュール案における前記対象利用者の前記当日の介護のスケジュールが、前記対象利用者が希望するスケジュールと一致しない場合、前記対象利用者に対し、前記当日の介護内容の希望を再度問い合わせて前記希望介護情報を再取得し、当該再取得した前記希望介護情報を用いて前記リスケジュール案を再作成する、
   請求項１に記載の介護サービス支援方法。
9. 複数の利用者各々について当日の健康状態に関する情報である健康情報を取得する第一取得部と、
   前記複数の利用者のうち前記健康情報が示す前記当日の健康状態が所定の条件を満たす対象利用者に対し、前記当日の介護内容の希望を問い合わせて前記当日の介護内容の希望に関する希望介護情報を取得する第二取得部と、
   前記健康情報及び前記希望介護情報と、予め設定されている前記複数の利用者各々の前記当日の介護のスケジュールに関するスケジュール情報と、に基づいて、前記スケジュールを改変して、当該改変後のスケジュールに関するリスケジュール案を作成する作成部と、
   前記複数の利用者各々に対し、前記リスケジュール案における各利用者の前記当日の介護のスケジュールに関する情報を通知する通知部と、
   を備える介護サービス支援システム。
10. 複数の利用者各々について当日の健康状態に関する情報である健康情報を取得する第一取得部と、
    前記複数の利用者のうち前記健康情報が示す前記当日の健康状態が所定の条件を満たす対象利用者に対し、前記当日の介護内容の希望を問い合わせて前記当日の介護内容の希望に関する希望介護情報を取得する第二取得部と、
    前記健康情報及び前記希望介護情報と、予め設定されている前記複数の利用者各々の前記当日の介護のスケジュールに関するスケジュール情報と、に基づいて、前記スケジュールを改変して、当該改変後のスケジュールに関するリスケジュール案を作成する作成部と、
    前記複数の利用者各々に対し、前記リスケジュール案における各利用者の前記当日の介護のスケジュールに関する情報を通知する通知部と、
    を備える介護サービス支援サーバ。

Images