(本開示の一態様に至る経緯)
介護施設の利用者は、ノロウィルス及びインフルエンザ等の感染症及び風邪並びに疲労等の様々な原因で、介護施設を利用する当日になって突然体調不良を訴える場合がある。特に、感染症及び風邪等の病気による体調不良を訴えた利用者が介護施設に訪れると、介護施設において病気が流行し、他の利用者の体調を悪化させる虞がある。このため、従来、介護施設では、利用者が介護施設を利用する当日に体調不良を訴えた場合、当該利用者を無条件に自宅で静養させる対処が行われていた。
しかし、上記対処では、利用者は、微熱又は疲労等による、他者に影響を与えない程度の軽微な体調不良を訴え、介護施設の個室での介護を希望したとしても、希望通りの介護を受けることができなかった。また、上記対処では、利用者が体調不良を訴えた場合に、介護施設の施設及び備品並びに介護施設のスタッフの労力等の介護施設のリソースに無条件に余剰が生じることとなり、介護施設の稼働率が低減するという問題があった。
上記特許文献1に開示の技術は、介護施設に訪れることが決まっている利用者を対象とする技術であるため、利用者を無条件に介護施設に訪れさせないことで生じる上記問題を解消することはできなかった。
そこで、本発明者は、軽微な体調不良の状態にある利用者に、当該利用者が希望する介護を受けさせて、介護施設の稼働率を向上することについて鋭意検討を重ねた結果、以下の本開示に係る各態様を想到するに至った。
本開示の一態様に係る介護サービス支援方法は、介護サービス支援システムのコンピュータが、複数の利用者各々について当日の健康状態に関する情報である健康情報を取得し、前記複数の利用者のうち、前記健康情報が示す前記当日の健康状態が所定の条件を満たす対象利用者に対し、前記当日の介護内容の希望を問い合わせて前記当日の介護内容の希望に関する希望介護情報を取得し、前記健康情報及び前記希望介護情報と、予め設定されている前記複数の利用者各々の前記当日の介護のスケジュールに関するスケジュール情報と、に基づいて、前記スケジュールを改変して、当該改変後のスケジュールに関するリスケジュール案を作成し、前記複数の利用者各々に対し、前記リスケジュール案における各利用者の前記当日の介護のスケジュールに関する情報を通知する。
本構成では、当日の健康状態が所定の条件を満たす対象利用者から、当日の介護内容の希望に関する希望介護情報が取得される。このため、利用者の健康状態が、微熱又は疲労等による、他者に影響を与えない程度の軽微な体調不良の状態であることを示す条件を、前記所定の条件として定めることができる。これにより、健康状態が当該所定の条件を満たす、軽微な体調不良の状態である利用者を対象利用者とし、当該対象利用者から当日の介護内容の希望に関する希望介護情報を取得できる。
そして、本構成では、複数の利用者各々の健康状態に関する健康情報及び予め設定されたスケジュール情報だけでなく、対象利用者から取得した希望介護情報にも基づき、リスケジュール案が作成される。このため、対象利用者が希望する当日の介護内容を加味して、対象利用者が希望する介護を受けることができるリスケジュール案を作成できる。尚、本構成では、作成されたリスケジュール案における各利用者の当日の介護のスケジュールに関する情報が各利用者に通知される。このため、対象利用者は、希望通りの介護が受けれるか否かを確認できる。
すなわち、本構成によれば、上記のように前記所定の条件を定めることで、軽微な体調不良の状態にある対象利用者が、希望する介護を受けることができるリスケジュール案を作成できる。このため、従来のように、当該対象利用者を無条件に自宅で静養させる場合よりも、介護施設のリソースに余剰が生じる機会を低減できる。その結果、介護施設の稼働率を向上することができる。
上記態様において、前記健康情報は、前記複数の利用者各々の前記当日における体温に関する情報であってもよい。
本構成によれば、複数の利用者各々の当日における体温に基づき、対象利用者が希望する当日の介護内容を加味して、対象利用者が希望する介護を受けることができるリスケジュール案を作成できる。
上記態様において、前記所定の条件は、前記複数の利用者各々の前記当日における体温が、前記当日の前日における体温よりも所定の値を超えて上昇していることであってもよい。
本構成によれば、体温が前日よりも所定の値を超えて上昇しており、熱があると考えられる利用者を対象利用者とし、当該対象利用者が希望する介護を受けることができるリスケジュール案を作成できる。
上記態様において、前記所定の条件は、前記複数の利用者各々の前記当日における体温が、前記当日の前日における体温よりも所定の値を超えて上昇しており、且つ、所定の体温以下であることであってもよい。
本構成によれば、体温が前日よりも所定の値を超えて上昇しており、且つ、所定の体温以下である、微熱があると考えられる利用者を対象利用者とし、当該対象利用者が希望する介護を受けることができるリスケジュール案を作成できる。
上記態様において、前記コンピュータは、更に、前記複数の利用者各々について同居する家族が前記当日において感染症に罹患しているか否かを示す罹患情報を取得し、前記所定の条件は、前記複数の利用者各々の前記当日における体温が、前記当日の前日における体温よりも所定の値を超えて上昇しており、且つ、当該複数の利用者各々についての前記罹患情報が感染症に罹患していないことを示すことであってもよい。
利用者と同居する家族が感染症に罹患している場合、当該利用者は、感染症に感染している可能性が非常に高いと考えられる。本構成では、罹患情報が感染症に罹患していることを示す利用者が対象利用者として扱われない。このため、罹患情報が感染症に罹患していることを示す利用者が希望する介護を受けることができるリスケジュール案が作成されることを回避できる。その結果、罹患情報が感染症に罹患していることを示す利用者が希望する介護を受けることで、他の利用者が感染症に感染するリスクを低減できる。
上記態様において、前記介護内容には、個室での介護及び在宅での介護が含まれてもよい。
本構成によれば、対象利用者が当日の介護内容として個室での介護又は在宅での介護を希望した場合に、対象利用者が、自身が希望した個室での介護又は在宅での介護を受けることができるリスケジュール案を作成できる。
上記態様において、前記スケジュール情報は、前記複数の利用者の人数、前記複数の利用者が利用する介護施設の設備リソース、前記複数の利用者各々の介護に必要な介護者の人数、及び前記介護施設の人的リソースに基づいて設定されていてもよい。
本構成では、スケジュール情報が、複数の利用者の人数、複数の利用者が利用する介護施設の設備リソース、複数の利用者各々の介護に必要な介護者の人数、及び介護施設の人的リソースに基づいて設定されている。このため、当該スケジュール情報に基づき、介護施設の設備リソース及び人的リソースに余剰が生じないようなリスケジュール案を作成できる。
上記態様において、前記リスケジュール案における前記対象利用者の前記当日の介護のスケジュールが、前記対象利用者が希望するスケジュールと一致しない場合、前記対象利用者に対し、前記当日の介護内容の希望を再度問い合わせて前記希望介護情報を再取得し、当該再取得した前記希望介護情報を用いて前記リスケジュール案を再作成してもよい。
本構成によれば、リスケジュール案における対象利用者の当日の介護のスケジュールが、当該対象利用者が希望するスケジュールと一致しない場合、当該対象利用者から希望介護情報が再取得され、当該再取得した希望介護情報に基づき、リスケジュール案が再作成される。このため、対象利用者が希望する介護を受けることができるリスケジュール案をより確実に作成できる。
本開示は、上述した方法に含まれる特徴的な各ステップをコンピュータに実行させるコンピュータプログラムとして実現することもできる。そして、そのようなコンピュータプログラムを、CD-ROM等のコンピュータ読取可能な非一時的な記録媒体あるいはインターネット等の通信ネットワークを介して流通させることができるのは、言うまでもない。
また、本開示の他の一態様に係る介護サービス支援システムは、複数の利用者各々について当日の健康状態に関する情報である健康情報を取得する第一取得部と、前記複数の利用者のうち前記健康情報が示す前記当日の健康状態が所定の条件を満たす対象利用者に対し、前記当日の介護内容の希望を問い合わせて前記当日の介護内容の希望に関する希望介護情報を取得する第二取得部と、前記健康情報及び前記希望介護情報と、予め設定されている前記複数の利用者各々の前記当日の介護のスケジュールに関するスケジュール情報と、に基づいて、前記スケジュールを改変して、当該改変後のスケジュールに関するリスケジュール案を作成する作成部と、前記複数の利用者各々に対し、前記リスケジュール案における各利用者の前記当日の介護のスケジュールに関する情報を通知する通知部と、を備える。
また、本開示の他の一態様に係る介護サービス支援サーバは、複数の利用者各々について当日の健康状態に関する情報である健康情報を取得する第一取得部と、前記複数の利用者のうち前記健康情報が示す前記当日の健康状態が所定の条件を満たす対象利用者に対し、前記当日の介護内容の希望を問い合わせて前記当日の介護内容の希望に関する希望介護情報を取得する第二取得部と、前記健康情報及び前記希望介護情報と、予め設定されている前記複数の利用者各々の前記当日の介護のスケジュールに関するスケジュール情報と、に基づいて、前記スケジュールを改変して、当該改変後のスケジュールに関するリスケジュール案を作成する作成部と、前記複数の利用者各々に対し、前記リスケジュール案における各利用者の前記当日の介護のスケジュールに関する情報を通知する通知部と、を備える。
尚、以下で説明する実施の形態は、いずれも本開示の一具体例を示すものである。以下の実施の形態で示される数値、形状、構成要素、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。また全ての実施の形態において、各々の内容を組み合わせることもできる。
(第一実施形態)
以下、本発明の実施の形態について図面を参照しながら説明する。図1は、本開示の第一実施形態における介護サービス支援システム1の全体構成の一例を示す図である。介護サービス支援システム1は、介護施設の利用者及び介護施設のリソースに関する情報と、複数の利用者各々の介護のスケジュールに関する情報と、を管理し、当該情報に基づき、各利用者の介護のスケジュールを作成及び管理するシステムである。
ここで、介護施設の利用者とは、介護施設のスタッフ(介護者の一例)によって介護を受ける利用者が該当する。介護施設のリソースとは、介護施設が備える個室、浴室、食卓及び送迎バス等の設備リソースと、介護施設に勤務するスタッフ等の人的リソースと、が該当する。
図1に示すように、介護サービス支援システム1は、DB(データベース)サーバ10、生体センサー20、利用者端末30、スタッフ端末40、及び施設端末50を備えている。DBサーバ10、生体センサー20、利用者端末30、スタッフ端末40、及び施設端末50は、ネットワークNTを介して相互に通信可能に接続されている。ネットワークNTは、例えば、携帯電話通信網及びインターネット通信網等を含む公衆通信網で構成されている。尚、図1では、説明の便宜上、生体センサー20、利用者端末30及びスタッフ端末40は、それぞれ、一個ずつしか示されていない。しかし、これに限らず、介護サービス支援システム1には、複数の生体センサー20、複数の利用者端末30及び複数のスタッフ端末40が含まれていてもよい。
DBサーバ10は、HDD(ハードディスクドライブ)等の記憶装置を備えた一以上のコンピュータで構成されている。DBサーバ10は、ネットワークNTを介してアクセス可能な利用者情報DB(データベース)131、施設リソース情報DB132及びスケジュール情報DB133を用いて、介護サービス支援システム1において使用する情報を管理する。
利用者情報DB131は、介護施設の利用者に関する情報(以降、利用者情報)を記憶する。利用者情報は、システム管理者によって、利用者が介護施設を利用する契約をした際に利用者情報DB131に記憶され、また、一年の間に一回以上更新される。
施設リソース情報DB132は、介護施設のリソースに関する情報(以降、施設リソース情報)を記憶する。施設リソース情報は、システム管理者によって、介護サービス支援システム1の導入時に施設リソース情報DB132に記憶され、また、一年の間に一回以上更新される。
スケジュール情報DB133は、各利用者が受ける介護のスケジュールに関する情報(以降、スケジュール情報)を記憶する。スケジュール情報は、介護施設が定める期日までに、各利用者によって不定期にスケジュール情報DB133に記憶される。利用者情報DB131、施設リソース情報DB132、及びスケジュール情報DB133の詳細は後述する。
生体センサー20は、例えば、介護施設の利用者の家庭に設置された通信機能付きの生体センサーで構成されている。これに限らず、生体センサー20は、利用者の身体に装着可能な通信機能付きの生体センサーで構成されていてもよい。生体センサー20は、利用者の健康状態を表す、体温、血圧、発汗量、心拍数等の生体情報(健康情報の一例)を検出し、当該検出した生体情報をネットワークNTを介して施設端末50へ送信する。
利用者端末30は、例えば、介護施設の利用者の家庭に設置されたパーソナルコンピュータで構成されている。これに限らず、利用者端末30は、介護施設の利用者又は当該利用者の連絡者が所有するタブレット端末又はスマートフォンで構成されていてもよい。利用者の連絡者とは、利用者に代わり、介護施設のスタッフと利用者による介護施設の利用について連絡し合う、利用者と同居している家族である。
具体的には、利用者端末30は、利用者端末30の全体制御を司るプロセッサと、前記プロセッサの制御の下、種々の情報を表示する表示部と、利用者端末30の操作を受け付ける操作部と、を備える。また、利用者端末30は、前記プロセッサの制御の下、外部装置との間で種々の情報を送受信する通信部と、前記プロセッサの制御の下、種々の音声を出力するスピーカと、を備える。表示部は、例えば、液晶ディスプレイ等の表示装置である。操作部は、例えば、タッチパネル、キーボード、及びマウス等の入力装置である。通信部は、利用者端末30が外部装置とネットワークNTを介して通信するための無線通信インターフェイス回路及び/又は有線通信インターフェイス回路である。
利用者端末30は、施設端末50との間で種々の情報を送受信し、施設端末50から受信した情報を表示部に表示する。また、利用者端末30は、施設端末50から受信した情報を示す音声をスピーカによって出力させる。
スタッフ端末40は、例えば、介護施設に設置されたパーソナルコンピュータで構成されている。これに限らず、スタッフ端末40は、介護施設のスタッフが所有するタブレット端末又はスマートフォンで構成されていてもよい。スタッフ端末40は、利用者端末30と同様のプロセッサ、表示部、操作部、通信部、及びスピーカを備える。スタッフ端末40は、施設端末50との間で種々の情報を送受信し、施設端末50から受信した情報を表示部に表示する。また、スタッフ端末40は、施設端末50から受信した情報を示す音声をスピーカによって出力させる。
施設端末50は、例えば、介護施設に設置されたサーバ装置又はパーソナルコンピュータで構成され、介護サービス支援システム1の全体制御を司る。
図2は、施設端末50の構成の一例を示すブロック図である。具体的には、図2に示すように、施設端末50は、施設端末50の全体制御を司るプロセッサ56と、プロセッサ56の制御の下、種々の情報を表示する表示部51と、施設端末50の操作を受け付ける操作部52と、を備える。施設端末50は、プロセッサ56の制御の下、外部装置との間で種々の情報を送受信する通信部53と、プロセッサ56の制御の下、種々の音声を出力するスピーカ54と、プロセッサ56の制御に用いる情報及びプログラムを記憶するメモリ55と、を備える。
プロセッサ56は、例えば、CPUで構成され、第一取得部561、第二取得部562、作成部563、及び通知部564として機能する。ここで、第一取得部561、第二取得部562、作成部563、及び通知部564は、例えば、プロセッサ56がメモリ55に記憶された、コンピュータを施設端末50として機能させる介護サービス支援プログラムを実行することで実現される。尚、この介護サービス支援プログラムは、ネットワークNTからダウンロードすることで市場に提供されてもよいし、コンピュータ読取可能な非一時的な記録媒体に記録されることで市場に提供されてもよい。
第一取得部561は、生体センサー20(図1)から送信され、通信部53が受信した生体情報を、通信部53から取得する。また、第一取得部561は、利用者端末30(図1)から送信され、通信部53が受信した生体情報を通信部53から取得する。第一取得部561は、通信部53を制御して、当該取得した生体情報をDBサーバ10に送信することにより、利用者情報DB131に記憶する。
具体的には、介護施設の利用者又は当該利用者の連絡者は、例えば利用者が起床した直後等、利用者が介護施設を利用する前に、生体センサー20(図1)を操作して、利用者の当日の生体情報を検出し、当該検出した生体情報を施設端末50に送信する。または、介護施設の利用者又は当該利用者の連絡者は、例えば、起床時等の介護施設を利用する前に、体温計及び血圧計等を用いて利用者の当日の生体情報を取得する。そして、介護施設の利用者又は当該利用者の連絡者は、前記取得した利用者の生体情報を利用者端末30に入力し、利用者端末30を操作して、当該入力した生体情報を施設端末50に送信する。これにより、第一取得部561は、利用者が介護施設を利用する当日の生体情報を取得することになる。
尚、第一取得部561は、生体センサー20の通信アドレスと、利用者端末30の通信アドレスと、利用者の識別子と、が、予め登録されている通信情報テーブルを参照することで、取得した生体情報がどの利用者の生体情報であるかを特定すればよい。尚、通信情報テーブルは、予め利用者情報DB131に記憶されている。第一取得部561は、通信部53を制御して、利用者情報DB131に記憶されている通信情報テーブルを参照する。ただし、これに限らず、プロセッサ56が、施設端末50の起動時等の所定のタイミングで、通信部53を制御して、利用者情報DB131から読み取った通信情報テーブルをメモリ55に記憶するようにしてもよい。そして、第一取得部561が、メモリ55に記憶されている通信情報テーブルを参照するようにしてもよい。
第二取得部562は、第一取得部561によって取得された複数の利用者の当日の生体情報のうち、利用者の当日の健康状態が所定の変更条件(所定の条件の一例)を満たすことを示す生体情報が存在するか否かを判定する。ここで、変更条件は、例えば、微熱又は疲労等が原因で、利用者が軽微な体調不良であるときの、利用者の生体情報によって定められている。
例えば、生体情報が、利用者の体温を示す情報であるとする。この場合、変更条件は、例えば、利用者の当日における体温が、当該当日の前日における体温よりも所定の値(例えば、0.5℃)を超えて上昇しており、且つ、所定の体温(例えば、38℃)以下であることに定めればよい。
このように変更条件が定められている場合、第二取得部562は、通信部53を制御して、第一取得部561によって取得され、利用者情報DB131に記憶された、複数の利用者の前記当日及び前記当日の前日の生体情報を参照する。そして、第二取得部562は、当該参照した生体情報のうち、利用者の前記当日における体温が、当該利用者の前記当日の前日における体温よりも所定の値を超えて上昇しており、且つ、所定の体温以下であることを示す生体情報が存在するか否かを判定する。
第二取得部562は、利用者の当日の健康状態が変更条件を満たすことを示す生体情報が存在すると判定したとする。この場合、第二取得部562は、当該生体情報に対応する利用者(以降、対象利用者)又は対象利用者の連絡者に対し、対象利用者が希望する前記当日の介護内容を問い合わせる。ここで、介護内容には、介護施設が備える個室での介護、及び、在宅での介護等が含まれる。在宅での介護とは、介護施設のスタッフが利用者の自宅に訪問して利用者を介護することを示す。
具体的には、第二取得部562は、第一取得部561と同様に前記通信情報テーブルを参照することで、対象利用者又は対象利用者の連絡者が利用する利用者端末30のアドレスを取得する。第二取得部562は、通信部53を制御して、前記取得したアドレス宛に、前記当日の介護内容の希望を問い合わせる旨のメッセージ(例えば、「本日希望する介護内容を返信して下さい。」)を送信する。
第二取得部562は、前記問い合わせの後、対象利用者又は対象利用者の連絡者が利用する利用者端末30から送信され、通信部53によって受信された、当日の介護内容の希望に関する希望介護情報を取得する。
具体的には、第二取得部562によって前記問い合わせが行われ、対象利用者又は対象利用者の連絡者が利用する利用者端末30の通信部が、前記当日の介護内容の希望を問い合わせる旨のメッセージを受信したとする。この場合、利用者端末30のプロセッサは、当該受信したメッセージを利用者端末30の表示部に表示するとともに、前記当日の介護内容の希望を入力するための操作画面を利用者端末30の表示部に表示する。
これに応じて、対象利用者又は対象利用者の連絡者が、利用者が希望する前記当日の介護内容(例えば「個室での介護」)を利用者端末30に入力したとする。この場合、利用者端末30のプロセッサは、利用者端末30の通信部を制御して、当該入力された介護内容を示す希望介護情報を施設端末50に送信する。
これにより、第二取得部562は、利用者端末30から送信され、通信部53が受信した希望介護情報を通信部53から取得することになる。尚、第二取得部562は、前記通信情報テーブルを参照することで、取得した希望介護情報が、どの利用者が希望する介護内容であるのかを、特定すればよい。
作成部563は、第一取得部561が取得した複数の利用者の生体情報と、第二取得部562が取得した希望介護情報と、複数の利用者各々の当日の介護のスケジュール(以降、当日スケジュール)に関するスケジュール情報(以降、当日のスケジュール情報)と、に基づいて、当日スケジュールを改変する。当日のスケジュール情報は、スケジュール情報DB133に予め記憶されている。そして、作成部563は、当該改変後の当日スケジュールに関するリスケジュール案を作成する。作成部563によるリスケジュール案の作成方法の詳細は後述する。
通知部564は、作成部563が作成したリスケジュール案における、各利用者の当日のスケジュール情報を、通信部53を制御して、当該各利用者又は当該各利用者の連絡者が利用する利用者端末30に送信する。
(DBサーバ10が管理する情報)
次に、DBサーバ10が管理する情報について詳述する。図3は、利用者情報DB131のデータ構成の一例を示す図である。尚、図3では、ある一の利用者に関する情報だけが示されているが、これは一例であり、複数の利用者の各々について利用者情報DB131は存在する。
利用者情報DB131には、利用者及び当該利用者と同居する家族のそれぞれについて一個の初期情報テーブルが割り当てられている。また、利用者情報DB131には、利用者が介護施設で行われる介護の各イベントに出席した場合に、当該利用者を介護するのに必要なスタッフ数(複数の利用者各々の介護に必要な介護者の人数の一例)を示す、一個のマンパワー情報テーブルが割り当てられている。以降、利用者を介護するスタッフ数をマンパワーと記載する。
図3の例では、利用者情報DB131には、氏名が「A」の利用者に対応する初期情報テーブル131Aと、当該利用者と同居する、当該利用者との続き柄が「娘」、「娘夫」、「孫1」、及び「孫2」の家族各々に対応する四個の初期情報テーブル131B、131C、131D、131Eと、氏名が「A」の利用者に対応する一個のマンパワー情報テーブル131Xと、が割り当てられている。
初期情報テーブル131Aは、「氏名」、「ニックネーム」、「年齢」、「介護/支援度」、「顔」、「同居家族」、「別居家族」、及び「連絡者」のフィールドを備える。「氏名」フィールドには利用者の氏名が記憶されている。「ニックネーム」フィールドには利用者のニックネームが記憶されている。「年齢」フィールドには利用者の年齢が記憶されている。「介護/支援度」フィールドには利用者の要介護認定結果が記憶されている。例えば、図3の初期情報テーブル131Aでは、「要介護1」が記憶されている。「顔」フィールドには利用者の顔の画像データが記憶されている。「同居家族」フィールドには利用者と同居する家族が記憶されている。例えば、図3の初期情報テーブル131Aでは、「娘」、「娘夫」、「孫1」、「孫2」が記憶されている。「別居家族」フィールドには利用者と別居する家族が記憶されている。例えば、図3の初期情報テーブル131Aでは、「息子」が記憶されている。「連絡者」フィールドには利用者の連絡者が、連絡の優先順に記憶されている。例えば、図3の初期情報テーブル131Aでは、「娘」、「息子」の順に、利用者の連絡者が記憶されている。これは、利用者に関する連絡を「娘」に対して行うことを優先し、当該連絡が取れなかった場合に「息子」に対して当該連絡を行うことを示している。
初期情報テーブル131B~131Eは、それぞれ、「続き柄」、「氏名」、「年齢」、「携帯ナンバー」、「所属」、「休日」、及び「備考」のフィールドを備える。「続き柄」フィールドには、利用者に対する続き柄が記憶されている。「氏名」、「年齢」は初期情報テーブル131Aと同じである。「携帯ナンバー」フィールドには、利用者が利用する介護施設から貸し出された携帯電話の番号が記憶されている。「所属」フィールドには、利用者と同居する家族の所属組織が記憶されている。図3の例では、「娘」、「娘夫」、「孫1」、「孫2」の所属組織は、それぞれ、「S社」、「P社」、「K高校」、及び「T中学」である。「休日」フィールドには、利用者と同居する家族の休日が記憶されている。「備考」フィールドには、利用者の介護を行う上で参考になる、利用者と同居する家族に関連する情報が記憶されている。図3の例では、利用者の介護を行う上で参考になる「娘」、「孫1」、「孫2」に関連する情報は、それぞれ、「10-16勤務」、「気が利く」、及び「クラブで遅い」である。
マンパワー情報テーブル131Xには、介護施設で実施可能な介護のイベントと、利用者が当該イベントに出席した場合に必要なマンパワーと、が対応付けて記憶されている。図3のマンパワー情報テーブル131Xでは、例えば、イベント「食事」とマンパワー「0.10」とが対応付けて記憶されている。ここで、マンパワーは、一時間当たりに必要なスタッフ数「人/時間」で表される。つまり、この例は、利用者がイベント「食事」に出席している間、一時間当たり「0.10」人のスタッフによって、当該利用者を介護する必要があることを示している。
図4は、施設リソース情報DB132のデータ構成の一例を示す図である。施設リソース情報DB132には、介護施設の設備リソースに関する情報を記憶するための設備リソーステーブル132Aと、介護施設の人的リソースに関する情報を記憶するための人的リソーステーブル132Bと、が割り当てられている。
具体的には、設備リソーステーブル132Aには、介護施設が備える設備及び備品と、当該設備及び備品の定員と、当該設備及び備品の個数と、が対応付けて記憶されている。図4の設備リソーステーブル132Aでは、例えば、介護施設が備える設備及び備品である「送迎バス」と、「送迎バス」の定員「5」と、「送迎バス」の個数「2」と、が対応付けて記憶されている。
人的リソーステーブル132Bには、時間帯と、当該時間帯にスタッフが出勤するか否かを示す出欠フラグと、が対応付けて記憶されている。例えば、図4の人的リソーステーブル132Bでは、時間帯「10:00-11:00」と、スタッフ「SA」が当該時間帯「10:00-11:00」に出勤することを示す出欠フラグ「1」と、スタッフ「SB」が当該時間帯「10:00-11:00」に出勤しないことを示す出欠フラグ「0」と、が対応付けて記憶されている。
図5は、スケジュール情報DB133のデータ構成の一例を示す図である。尚、図5では、ある一日における複数の利用者の介護のスケジュールに関する情報だけが示されているが、これは一例であり、複数の日についてスケジュール情報DB133は存在する。
スケジュール情報DB133には、ある一日における複数の利用者の介護のスケジュールに関するスケジュール情報を記憶するためのスケジュールテーブル133Aが割り当てられている。具体的には、スケジュールテーブル133Aには、時間帯と、当該時間帯に各利用者が出席する介護のイベントと、当該時間帯に必要なマンパワーと、を対応付けたスケジュール情報が記憶される。ここで、各時間帯に必要なマンパワーは、各利用者に対応するマンパワー情報テーブル131X(図3)に基づき、当該各時間帯に各利用者が各イベントに出席した場合に必要なマンパワーの合計値として算出される。
例えば、図5のスケジュールテーブル133Aには、時間帯「11:00-12:00」と、時間帯「11:00-12:00」に利用者「A」が出席する介護のイベント「入浴」と、時間帯「11:00-12:00」に利用者「B」が出席する介護のイベント「入浴」と、時間帯「11:00-12:00」に利用者「C」が出席する介護のイベント「入浴」と、時間帯「11:00-12:00」に利用者「D」が出席する介護のイベント「入浴」と、時間帯「11:00-12:00」に必要なマンパワー「2.00」と、が対応付けて記憶されている。
<スケジュール情報の設定方法>
スケジュール情報DB133に記憶されるスケジュール情報は、複数の利用者の人数、介護施設の設備リソース、介護施設の人的リソース、及び前記マンパワーに基づいて設定される。以下、ある対象日のスケジュール情報の設定方法の一例について、図6を用いて説明する。図6は、ある対象日のスケジュール情報の設定方法の一例を示す図である。
先ず、介護施設の利用者は、所定の期限日時までに、利用者端末30に対して、利用者が所定期間(例えば一か月)内に介護施設を利用する日(以降、利用日)と、各利用日において利用者が出席する介護のイベントと、を示す情報(以降、入力スケジュール情報)を入力する。そして、利用者は、利用者端末30を操作して、当該入力した入力スケジュール情報を施設端末50へ送信する。施設端末50において、通信部53が利用者端末30から送信された入力スケジュール情報を受信すると、プロセッサ56は、通信部53から当該入力スケジュール情報を取得する。また、プロセッサ56は、通信部53を制御して、当該取得した入力スケジュール情報をスケジュール情報DB133に記憶する。
前記所定の期限日時になると、プロセッサ56は、通信部53を制御して、各利用者に対応するマンパワー情報テーブル131X(図3)を参照して、対象日に介護施設を利用する各利用者が介護の各イベントに出席した場合に必要なマンパワーを把握する。例えば、図6の表131XAには、対象日に介護施設を利用する各利用者「A」、「B」、「C」、「D」が介護のイベント「入浴」に出席した場合に必要なマンパワーが、「0.2」、「0.3」、「0.5」、「1.0」であることを、プロセッサ56が把握した例を示している。
また、プロセッサ56は、通信部53を制御して、スケジュール情報DB133に記憶されている、各利用者の入力スケジュール情報を参照する。これにより、プロセッサ56は、対象日に各利用者が出席する介護のイベントを把握する。例えば、図6の表131XBには、対象日に利用者「A」~「D」が介護のイベント「送迎」、「バスの乗降」、「食事」、「入浴」、「体操/リハビリ」、「休憩/談話」に出席することを、プロセッサ56が把握した例を示している。
プロセッサ56は、これらの把握した内容に基づき、対象日において介護の各イベントを行う時間帯に必要なマンパワーを把握する。例えば、プロセッサ56が、図6の表131XA、131XBに示すように、対象日に各利用者「A」~「D」が介護のイベント「入浴」に出席し、各利用者「A」~「D」が介護のイベント「入浴」に出席した場合に必要なマンパワーが「0.2」、「0.3」、「0.5」、「1.0」であることを把握したとする。この場合、プロセッサ56は、図6の表131XCに示すように、当該把握したマンパワーの合計値「2.00」を、対象日に介護のイベント「入浴」を行う時間帯に必要なマンパワー「2.00」として把握する。
そして、プロセッサ56は、これらの把握した情報131XA~131XCと、施設リソース情報DB132に記憶されている情報(図4)と、に基づき、対象日において各イベントを行う時間帯を設定する。
具体的には、プロセッサ56は、対象日の各時間帯に必要なマンパワー及び当該各時間帯にイベントに出席する利用者の人数が、介護施設の設備リソース及び人的リソースによって定められる制限条件を満たすように、対象日において各イベントを行う時間帯を設定する。前記制限条件は、設備リソーステーブル132A(図4)に記憶されている、介護施設の設備及び備品の個数及び定員によって定められる制限条件と、人的リソーステーブル132B(図4)から把握される、各時間帯に出勤するスタッフ数によって定められる制限条件と、が該当する。
例えば、プロセッサ56が、図6の表131XBに示すように、対象日において、四人の利用者「A」~「D」が出席するイベント「入浴」を行う時間帯を設定するものとする。この場合、プロセッサ56は、設備リソーステーブル132A(図4)に記憶されているイベント「入浴」に関連する設備「浴室」の個数「1」及び定員「4」によって、「1個の浴室に定員4名まで同時に入浴可能である。」という制限条件が定められていると判断する。また、プロセッサ56は、人的リソーステーブル132B(図4)から把握される、各時間帯に出勤するスタッフ数によって、「10:00-11:00の時間帯は、1.00以下のマンパワーを確保可能である。」、「11:00-16:00の時間帯は、2.00以下のマンパワーを確保可能である。」という制限条件が定められていると判断する。
この場合、プロセッサ56は、イベント「入浴」を行う時間帯がどの時間帯に設定されたとしても、上記の制限条件「1個の浴室に定員4名まで同時に入浴可能である。」を満たすと判断する。そこで、プロセッサ56は、図6の表131XCに示すように、対象日においてイベント「入浴」を行う時間帯に必要なマンパワー「2.00」が、上記の制限条件「10:00-11:00の時間帯に1.00以下のマンパワーを確保可能である。」及び「11:00-16:00の時間帯に2.00以下のマンパワーを確保可能である。」を満たすように、イベント「入浴」を行う時間帯を設定する。例えば、図5のスケジュールテーブル133Aは、プロセッサ56が、イベント「入浴」を行う時間帯を上記の制限条件を満たす「11:00-12:00」の時間帯に設定した例を示している。
また、プロセッサ56は、対象日において介護の各イベントを行う時間帯を設定した後、当該設定後の各時間帯に必要なマンパワーを設定する。具体的には、図5のスケジュールテーブル133Aに示すように、プロセッサ56が、対象日に四人の利用者「A」~「D」が出席するイベント「入浴」を行う時間帯を、時間帯「11:00-12:00」に設定したものとする。この場合、プロセッサ56は、各利用者「A」~「D」に対応するマンパワー情報テーブル131X(図3)を参照する。これにより、プロセッサ56は、各利用者「A」~「D」がイベント「入浴」に出席したときに必要なマンパワーが、「0.2」、「0.3」、「0.5」、「1.0」であることを把握する。そして、プロセッサ56は、図5のスケジュールテーブル133Aに示すように、これらの把握したマンパワーの合計値「2.00」を、時間帯「11:00-12:00」に必要なマンパワー「2.00」として設定する。
<リスケジュール処理フロー>
次に、本開示の介護サービス支援システム1において実行されるリスケジュール処理について説明する。利用者は、ノロウィルス及びインフルエンザ等の感染症及び風邪並びに疲労等の様々な原因で、介護施設を利用する当日に突然体調不良を訴える場合がある。そこで、介護サービス支援システム1では、利用者の体調不良の度合いを加味し、他の利用者の体調に影響を与えないように、且つ、介護施設のリソースを無駄にしないように、当日の各利用者の介護のスケジュールを改変するリスケジュール処理が行われる。図7及び図8は、本開示の介護サービス支援システム1において実行されるリスケジュール処理の一例を示すフローチャートである。
プロセッサ56は、日付が変わる度にリスケジュール処理を実行する。図7に示すように、リスケジュール処理が開始されると、第一取得部561は、所定時刻になるまで、上述のように、リスケジュール処理が開始された当日に、介護施設を利用する利用者が使用する生体センサー20(図1)又は利用者端末30(図1)から送信された、利用者の当日の生体情報を取得する。そして、第一取得部561は、当該取得した生体情報を利用者情報DB131に記憶する(ステップS01)。ここで、所定時刻は、例えば、介護施設の営業開始時刻よりも所定時間(例えば、1時間)前の時刻に設定されている。
尚、ステップS01において、第一取得部561は、スケジュール情報DB133に記憶されている当日のスケジュール情報を参照して、当日の介護施設の利用者を把握する。第一取得部561は、前記所定時刻になるまでに、当日の生体情報を取得できなかった利用者が存在する場合、利用者情報DB131に記憶されている当該利用者の前日の生体情報を、当該利用者の当日の生体情報として取得する。
ただし、これに限らず、第一取得部561は、前記所定時刻になるまでに、当日の生体情報を取得できなかった利用者が存在する場合、予め定められた生体情報を、当該利用者の当日の生体情報として取得するようにしてもよい。ここで、予め定められた生体情報は、例えば、利用者が健康な状態であるときの生体情報とすればよい。
ステップS01の後、第二取得部562は、ステップS01で取得された生体情報のうち、利用者の当日の健康状態が所定の変更条件を満たすことを示す生体情報が存在するか否かを判定する(ステップS02)。
ステップS02において、第二取得部562が、利用者の当日の健康状態が変更条件を満たすことを示す生体情報が存在すると判定したとする(ステップS02でYES)。この場合、第二取得部562は、上述のように、当該生体情報に対応する対象利用者又は対象利用者の連絡者に対して、対象利用者が希望する当日の介護内容を問い合わせる(ステップS03)。そして、第二取得部562は、利用者端末30から送信された、対象利用者が希望する当日の介護内容に関する希望介護情報を取得する(ステップS04)。これにより、健康状態が変更条件を満たす、軽微な体調不良の状態である利用者を対象利用者とし、当該対象利用者から当日の介護内容の希望に関する希望介護情報を取得できる。
一方、ステップS02において、第二取得部562が、利用者の当日の健康状態が変更条件を満たすことを示す生体情報が存在しないと判定したとする(ステップS02でNO)。この場合、作成部563は、ステップS01で取得された生体情報のうち、利用者の当日の健康状態が所定の隔離条件を満たすことを示す生体情報が存在するか否かを判定する(ステップS05)。
ここで、隔離条件は、例えば、感染症、風邪又は高熱等が原因で利用者が体調不良を強く感じており、利用者を他者から隔離する必要があると考えられるときの、利用者の生体情報によって定められている。例えば、生体情報が利用者の体温を示す情報であるとする。この場合、隔離条件は、例えば、利用者の当日における体温が、所定の体温(例えば、38℃)よりも高いことに定めればよい。
ステップS05において、作成部563が、利用者の当日の健康状態が隔離条件を満たすことを示す生体情報が存在しないと判定したとする(ステップS05でNO)。この場合、ステップS01で取得された生体情報の中に、利用者の当日の健康状態が所定の変更条件及び隔離条件を満たすことを示す生体情報が存在しないので、当日の利用者の中に、体調不良を訴える者は存在しないと考えられる。この場合、当日スケジュールを改変する必要がないので、プロセッサ56は、リスケジュール処理を終了する。
一方、ステップS04が行われた場合又はステップS05において隔離条件を満たすことを示す生体情報が存在すると判定された場合(ステップS05でYES)、当日の利用者の中に、健康状態が変更条件又は隔離条件を満たす、体調不良を訴える利用者が存在すると考えられる。これらの場合、作成部563は、図8に示すように、ステップS11~S13を行う。これにより、作成部563は、ステップS01で取得された生体情報と、ステップS04で取得された希望介護情報と、スケジュール情報DB133に記憶されている当日のスケジュール情報と、施設リソース情報DB132に記憶されている施設リソース情報と、に基づいて、当日スケジュールを改変する。そして、作成部563は、当該改変後の当日スケジュールに関するリスケジュール案を作成する。
具体的には、ステップS11では、作成部563は、スケジュール情報DB133から当日のスケジュール情報を取得する(ステップS11)。
ステップS12では、作成部563は、ステップS11で取得したスケジュール情報において、当日に介護を受けることが設定されている利用者に対応する利用者情報(以降、当日の利用者情報)を、通信部53を制御して、利用者情報DB131(図3)から取得する。また、作成部563は、通信部53を制御して、施設リソース情報DB132(図4)に記憶されている施設リソース情報を取得する(ステップS12)。
例えば、ステップS11において図5に示すスケジュール情報が取得されたとする。この場合、ステップS12において、作成部563は、当該取得したスケジュール情報(図5)において、当日に介護を受けることが設定されている利用者「A」~「D」を把握する。そして、作成部563は、利用者情報DB131(図3)の初期情報テーブル131A~131E(図3)及びマンパワー情報テーブル131X(図3)から、当該把握した利用者「A」~「D」に対応付けられている利用者情報を、当日の利用者情報として取得する。また。ステップS12において、作成部563は、施設リソース情報DB132(図4)に備えられた設備リソーステーブル132A(図4)及び人的リソーステーブル132B(図4)に記憶されている情報を、施設リソース情報として取得する。
ステップS13では、作成部563は、ステップS01、S04、S11及びS12で取得した、利用者の当日の生体情報、希望介護情報、当日のスケジュール情報、当日の利用者情報及び施設リソース情報に基づいて、前記当日のスケジュール情報が示す当日スケジュールを改変する。そして、作成部563は、当該改変後のスケジュールに関するリスケジュール案を作成する(ステップS13)。このように、ステップS13では、利用者の当日の生体情報及び当日のスケジュール情報だけでなく、対象利用者から取得した希望介護情報にも基づき、リスケジュール案が作成される。このため、対象利用者が希望する当日の介護内容を加味して、対象利用者が希望する介護を受けることができるリスケジュール案を作成できる。尚、ステップS13の詳細については後述する。
次に、ステップS02において利用者の当日の健康状態が変更条件を満たすことを示す生体情報が存在すると判定され、当該生体情報に対応する対象利用者が存在したとする(ステップS14でYES)。この場合、通知部564は、対象利用者に対して、ステップS13で作成されたリスケジュール案における対象利用者の当日スケジュールが、対象利用者の希望通りであるか否かの確認を要求する(ステップS15)。
具体的には、ステップS15において、通知部564は、利用者情報DB131に記憶されている前記通信情報テーブルを参照して、対象利用者又は当該対象利用者の連絡者が利用する利用者端末30のアドレスを取得する。そして、通知部564は、通信部53を制御して、ステップS13で作成されたリスケジュール案における対象利用者の当日スケジュールに関する情報とともに、当該当日スケジュールが希望通りであるか否かの確認を要求するメッセージを前記取得したアドレス宛に送信する。
これに応じて、対象利用者又は当該対象利用者の連絡者が利用する利用者端末30では、通信部がリスケジュール案における対象利用者の当日の介護のスケジュールに関する情報及び前記メッセージを受信すると、プロセッサは、通信部が受信した情報及びメッセージを表示部に表示する。これにより、対象利用者又は当該対象利用者の連絡者は、ステップS13で作成されたリスケジュール案における対象利用者の当日スケジュールが対象利用者の希望通りであるかを確認できる。そして、対象利用者は、利用者端末30を操作して、利用者端末30に対象利用者の希望通りであるか否かの確認結果を入力し、当該入力した確認結果を施設端末50に送信する。
ステップS15の後、利用者端末30から送信され、通信部53が受信した確認結果が、対象利用者の希望通りであることを示していたとする(ステップS16でYES)。この場合、通知部564は、当日のスケジュール情報を更新及び通知する処理を行う(ステップS17)。
具体的には、ステップS17において、通知部564は、通信部53を制御して、ステップS13で作成されたリスケジュール案によって、スケジュール情報DB133に記憶されている当日のスケジュール情報を更新する。
そして、通知部564は、ステップS13で作成されたリスケジュール案における各利用者の当日スケジュールに関する情報を当日の各利用者に通知する。具体的には、通知部564は、利用者情報DB131に記憶されている前記通信情報テーブルを参照して、当日の各利用者又は当該各利用者の連絡者が利用する利用者端末30のアドレスを取得する。そして、通知部564は、通信部53を制御して、ステップS13で作成されたリスケジュール案における各利用者の当日スケジュールに関する情報を、前記取得したアドレス宛に送信する。
また、通知部564は、ステップS13で作成されたリスケジュール案を各スタッフに通知する。具体的には、通知部564は、通信部53を制御して、施設リソース情報DB132に予め記憶されている、各スタッフが利用するスタッフ端末40のアドレスを参照する。そして、通知部564は、通信部53を制御して、ステップS13で作成されたリスケジュール案を、前記参照したアドレス宛に送信する。
尚、ステップS05(図7)において利用者の当日の健康状態が隔離条件を満たすことを示す生体情報が存在すると判定された場合には(ステップS05でYES)、対象利用者が存在しない場合でも(ステップS14でNO)、ステップS13においてリスケジュール案が作成される。したがって、この場合も(ステップS14でNO)、ステップS17が行われる。ステップS17の後、プロセッサ56は、リスケジュール処理を終了する。
一方、ステップS15の後、利用者端末30から送信され、通信部53が受信した確認結果が、対象利用者の希望通りでない(対象利用者が希望するスケジュールと一致しない)ことを示していたとする(ステップS16でNO)。更に、ステップS13において作成部563が複数のリスケジュール案を作成し、当該複数のリスケジュール案のうち、ステップS15で用いられていないリスケジュール案(以降、未確認のリスケジュール案)が存在していたとする(ステップS18でYES)。
この場合、通知部564は、ステップS15と同様にして、対象利用者に対して、未確認のリスケジュール案における対象利用者の当日スケジュールが、対象利用者の希望通りであるか否かの確認を要求する(ステップS19)。ステップS19の後、対象利用者が利用する利用者端末30から送信され、通信部53が受信した確認結果が、対象利用者の希望通りでない(対象利用者が希望するスケジュールと一致しない)ことを示していたとする(ステップS20でNO)。この場合、ステップS18以降の処理が行われる。
一方、ステップS19の後、対象利用者が利用する利用者端末30から送信され、通信部53が受信した確認結果が、対象利用者の希望通りであることを示していた場合(ステップS20でYES)、当該ステップS19で用いた未確認のリスケジュール案を用いてステップS17が行われる。
また、ステップS13において作成部563が複数のリスケジュール案を作成したが、ステップS18~S20が繰り返された結果、未確認のリスケジュール案が存在しなくなったとする(ステップS18でNO)。この場合、ステップS03以降の処理が行われる。これにより、ステップS03において、対象利用者に対して当日の介護内容の希望を再度問い合わせ、ステップS04において、前記希望介護情報を再取得し、ステップS13において、当該再取得した希望介護情報を用いてリスケジュール案を再作成する。したがって、対象利用者が希望する介護を受けることができるリスケジュール案をより確実に作成できる。
以上のように、本構成によれば、軽微な体調不良の状態にある対象利用者が、希望する介護を受けることができるリスケジュール案を作成できる。このため、従来のように、当該対象利用者を無条件に自宅で静養させる場合よりも、介護施設のリソースに余剰が生じる機会を低減できる。その結果、介護施設の稼働率を向上することができる。
<リスケジュール案の作成方法>
次にステップS13(図8)における作成部563によるリスケジュール案の作成方法の一例について説明する。尚、以下の説明では、生体情報は、利用者の体温を示す情報であるものとする。ステップS02(図7)で用いる変更条件は、利用者の当日における体温が、当該当日の前日における体温よりも0.5℃を超えて上昇しており、且つ、38℃以下であることに定められているものとする。ステップS05(図7)で用いる隔離条件は、利用者の当日における体温が38℃よりも高いことに定められているものとする。
尚、ステップS02(図7)で用いる変更条件は、上記に限らず、例えば、利用者の当日における体温が、当該当日の前日における体温よりも0.5℃を超えて上昇していることに定められていてもよい。
また、図5に示すように、リスケジュール処理が実行される当日のスケジュール情報がスケジュールテーブル133Aに記憶されている場合に、リスケジュール処理が実行されたものとする。これにより、ステップS02及びステップS05において、図9の表91に示す判定結果が得られ、ステップS13が実行されたものとする。
図9は、生体情報に応じて各利用者の介護内容を改変する処理の一例を示す図である。図9の表91において、判定結果「△」は、各利用者の当日の体温が変更条件を満たすことを示す。判定結果「×」は、各利用者の当日の体温が上記の隔離条件を満たすことを示す。判定結果「〇」は、各利用者の当日の体温が上記の変更条件及び上記の隔離条件を共に満たしていないことを示す。つまり、図9の表91は、利用者「A」及び「B」の当日の体温が変更条件を満たし、利用者「C」の当日の体温が変更条件及び隔離条件を共に満たさず、利用者「D」の当日の体温が隔離条件を満たしていることを示している。
また、ステップS04(図7)で取得された対象利用者「A」の希望介護情報が在宅での介護を示し、ステップS04で取得された対象利用者「B」の希望介護情報が介護施設が備える個室での介護を示すものとする。
この場合、利用者「A」及び「B」の当日の体温は、変更条件を満たしているので、利用者「A」及び「B」は、微熱又は疲労等によって軽微な体調不良を感じていると考えられる。このため、利用者「A」及び「B」が介護施設に訪問したとしても、介護施設において他の利用者の体調をあまり悪化させないと考えられる。したがって、作成部563は、このように軽微な体調不良を感じていると考えられる対象利用者の介護内容を、当該対象利用者から取得した希望介護情報が示す介護内容に仮決定する。
具体的には、作成部563は、図9の表92において記号「○」で示すように、対象利用者「A」の介護内容を、ステップS04で取得した対象利用者「A」の希望介護情報が示す在宅での介護「3.訪問」に仮決定する。同様に、作成部563は、対象利用者「B」の介護内容を、ステップS04で取得した対象利用者「B」の希望介護情報が示す、個室での介護「2.個室」に仮決定する。
利用者「C」の当日の体温は、上記の変更条件及び上記の隔離条件を共に満たしていないので、利用者「C」は、平熱であると考えられる。この場合、利用者「C」が介護施設に訪問したとしても、介護施設において他の利用者の体調に影響を与えないと考えられる。このため、作成部563は、このように平熱と考えられる当日の利用者の介護内容は改変しない。
具体的には、図5のスケジュールテーブル133Aに示すように、利用者「C」の当日スケジュールは、介護施設において通常行われる介護の内容となっている。このため、作成部563は、図9の表92において記号「◎」で示すように、利用者「C」の介護内容を、通常通りの介護「1.通常」に確定する。
利用者「D」の当日の体温は、上記の隔離条件を満たしているので、利用者「D」は、感染症又は高熱等によって体調不良を強く感じていると考えられる。この場合、利用者「D」が介護施設に訪問すると、介護施設において病気が流行する虞があると考えられる。このため、作成部563は、このように体調不良を強く感じていると考えられる利用者の介護内容を、自宅での静養に確定する。
具体的には、作成部563は、図9の表92において記号「◎」で示すように、利用者「D」の介護内容を、自宅での静養「4.自宅」に確定する。
次に、作成部563は、介護内容が確定した利用者「C」及び「D」の当日スケジュールを改変する。具体的には、作成部563は、先ず、図10の表101に示すように、介護内容が確定した利用者「C」及び「D」が出席するイベントを、当該確定した介護内容に応じて設定する。
図10は、生体情報に応じて介護内容が確定された利用者の介護のスケジュールを改変する処理の一例を示す図である。図10の表101において、「1」は利用者がイベントに出席することを示し、「0」は利用者がイベントに欠席することを示している。
作成部563は、図10の表101に示すように、介護内容が通常通りの介護に確定した利用者「C」が出席するイベントを、通常通りの介護で行われるイベント「送迎」、「バスの乗降」、「食事」、「入浴」、「体操/リハビリ」、「休憩/談話」に設定する。
一方、介護内容が自宅での静養「4.自宅」に確定した利用者「D」は、介護施設で行われる介護のイベントに出席できない。このため、作成部563は、図10の表101に示すように、利用者「D」が全てのイベントに欠席することを設定する。
作成部563は、介護内容が確定した利用者「C」及び「D」が出席するイベントの設定を終えると、図10の表101に示すように、介護内容が仮決定した利用者「A」及び「B」が全てのイベントに欠席することを仮設定する。
次に、作成部563は、通信部53を制御して、各利用者に対応するマンパワー情報テーブル131X(図3)を参照し、介護内容が確定した利用者「C」及び「D」が、当該介護内容に応じて設定された各イベントに出席した場合に必要なマンパワーを把握する。
具体的には、作成部563は、利用者「C」に対応するマンパワー情報テーブル131Xを参照し、図10の表102に示すように、利用者「C」が、介護内容に応じて設定されたイベント「送迎」、「バスの乗降」、「食事」、「入浴」、「体操/リハビリ」、「休憩/談話」に出席した場合に必要なマンパワーが、「0.25」、「0.20」、「0.30」、「0.50」、「0.10」、「0.10」であることを把握する。
一方、作成部563は、上述のように、利用者「D」の介護内容に応じて、利用者「D」が全てのイベントに欠席することを設定した。このため、作成部563は、図10の表102に示すように、利用者「D」が介護内容に応じたイベントに出席した場合に必要なマンパワーは、「0.00」であることを把握する。
次に、作成部563は、介護内容が仮決定した利用者が、当該仮決定した介護内容に応じて仮設定された各イベントに出席した場合に必要なマンパワーを把握する。
具体的には、作成部563は、上述のように、介護内容が仮決定した利用者「A」及び「B」が全てのイベントに欠席することを、当該仮決定した介護内容に応じて仮設定した。このため、作成部563は、図10の表102に示すように、利用者「A」及び「B」が介護内容に応じたイベントに出席した場合に必要なマンパワーは、「0.00」であることを把握する。
そして、作成部563は、これらの把握した内容に基づき、介護内容が確定された利用者の介護だけを行う場合において、各イベントを行う時間帯に必要なマンパワーを把握する。また、作成部563は、当該把握したマンパワーを、リスケジュール処理を行う前の当日スケジュールにおいて、各イベントを行う時間帯に必要なマンパワーから減算する。これにより、作成部563は、当該減算の結果を、介護内容が確定されていない利用者の介護を行う場合に、当該利用者が各イベントを行う時間帯に割り当てることができる、マンパワーの余剰として把握する。
例えば、図10の表102に示すように、イベント「入浴」を行う時間帯には、利用者「C」がイベント「入浴」に出席した場合のマンパワー「0.50」だけが必要になる。このため、作成部563は、図10の表102の「マンパワー」欄に示すように、イベント「入浴」を行う時間帯に必要なマンパワーは「0.50」であることを把握する。また、作成部563は、当該把握したマンパワー「0.50」を、リスケジュール処理を行う前の当初の当日スケジュール(図5)において、イベント「入浴」を行う時間帯に必要なマンパワー「2.00」から減算する。これにより、作成部563は、当該減算の結果「1.50」を、介護内容が確定されていない利用者「A」及び「B」の介護を行う場合に、当該利用者「A」及び「B」が各イベントを行う時間帯に割り当てることができる、マンパワーの余剰「1.50」として把握する。
そして、作成部563は、これらの把握した情報と、施設リソース情報DB132に記憶されている情報(図4)と、に基づき、介護内容が確定された利用者が各イベントを行う時間帯を設定する。
具体的には、作成部563は、プロセッサ56がスケジュール情報を生成する場合と同様にして、各時間帯に必要なマンパワー及び当該各時間帯にイベントに出席する利用者の人数が、介護施設の設備リソース及び人的リソースによって定められる制限条件を満たすように、介護内容が確定された利用者が各イベントを行う時間帯を設定する。また、作成部563は、プロセッサ56がスケジュール情報を生成する場合と同様にして、各イベントを行う時間帯を設定した後、当該設定後の各時間帯に必要なマンパワーを設定する。
例えば、作成部563が、図10の表101に示すように、利用者「C」が出席するイベント「入浴」を行う時間帯を設定するものとする。この場合、作成部563は、設備リソーステーブル132A(図4)に記憶されているイベント「入浴」に関連する設備「浴室」の個数「1」及び定員「4」によって、「1個の浴室に定員4名まで同時に入浴可能である。」という制限条件が定められていると判断する。また、作成部563は、人的リソーステーブル132B(図4)から把握される、各時間帯に出勤するスタッフ数によって、「10:00-11:00の時間帯は、1.00以下のマンパワーを確保可能である。」、「11:00-16:00の時間帯は、2.00以下のマンパワーを確保可能である。」という制限条件が定められていると判断する。
この場合、作成部563は、イベント「入浴」を行う時間帯がどの時間帯に設定されたとしても、上記の制限条件「1個の浴室に定員4名まで同時に入浴可能である。」を満たすと判断する。そこで、作成部563は、図10の表133-0に示すように、イベント「入浴」を行う時間帯に必要なマンパワー「0.50」が、上記の制限条件「10:00-11:00の時間帯に1.00以下のマンパワーを確保可能である。」及び「11:00-16:00の時間帯に2.00以下のマンパワーを確保可能である。」を満たすように、イベント「入浴」を行う時間帯を設定する。例えば、図10の表133-0は、作成部563が、イベント「入浴」を行う時間帯を、上記の制限条件を満たし、且つ、リスケジュール処理を行う前の当初の当日スケジュール(図5)と同じ「11:00-12:00」の時間帯に設定した例を示している。
そして、作成部563は、図10の表102に示すように、利用者「C」がイベント「入浴」に出席したときに必要なマンパワーが「0.50」であることを把握しているので、図10の表133-0に示すように、当該把握したマンパワー「0.50」を、時間帯「11:00-12:00」に必要なマンパワー「0.50」として設定する。
次に、作成部563は、介護内容が仮決定した利用者「A」及び「B」の当日スケジュールを改変する。具体的には、作成部563は、先ず、図11の表111に示すように、介護内容が仮決定した利用者「A」及び「B」が出席するイベントを当該仮決定した介護内容に応じて設定する。
図11は、対象利用者が希望する介護内容に応じて、対象利用者の介護のスケジュールを改変する処理の一例を示す図である。図11の表111において、「1」は対象利用者又は利用者がイベントに出席することを示し、「0」は対象利用者又は利用者がイベントに欠席することを示している。
作成部563は、図11の表111に示すように、介護内容が在宅での介護に仮決定した対象利用者「A」が出席するイベントを、在宅での介護で行われるイベント「訪問」に設定する。また、作成部563は、図11の表111に示すように、介護内容が個室での介護に仮決定した対象利用者「B」が出席するイベントを、個室での介護で行われるイベント「送迎」、「バスの乗降」、「食事」、「静養」に設定する。
次に、作成部563は、通信部53を制御して、各対象利用者に対応するマンパワー情報テーブル131X(図3)を参照し、介護内容が仮決定した対象利用者「A」及び「B」が、当該介護内容に応じて設定された各イベントに出席した場合に必要なマンパワーを把握する。
具体的には、作成部563は、対象利用者「A」に対応するマンパワー情報テーブル131Xを参照し、図11の表112に示すように、対象利用者「A」が、介護内容に応じて設定されたイベント「訪問」に出席した場合に必要なマンパワーが「1.00」であることを把握する。同様にして、作成部563は、対象利用者「B」に対応するマンパワー情報テーブル131Xを参照し、図11の表112に示すように、対象利用者「B」が、介護内容に応じて設定されたイベント「送迎」、「バスの乗降」、「食事」、「静養」に出席した場合に必要なマンパワーが「0.25」、「0.00」、「0.10」、「0.00」であることを把握する。
そして、作成部563は、以上の把握した内容に基づき、当日スケジュールの改変後、各イベントを行う時間帯に必要なマンパワーを把握する。また、作成部563は、当該把握したマンパワーを、リスケジュール処理を行う前の当日スケジュールにおいて、各イベントを行う時間帯に必要なマンパワーから減算する。これにより、作成部563は、当該減算の結果を、当日スケジュールを改変したことによって、各イベントを行う時間帯に生じるマンパワーの差分として把握する。
例えば、図11の表112に示すように、対象利用者「A」、「B」及び利用者「D」のスケジュールを改変すると、イベント「入浴」を行う時間帯には、利用者「C」がイベント「入浴」に出席した場合のマンパワー「0.50」だけが必要になる。このため、作成部563は、図11の表112の「マンパワー」欄に示すように、当日スケジュールの改変後、イベント「入浴」を行う時間帯に必要なマンパワーは「0.50」であることを把握する。また、作成部563は、当該把握したマンパワー「0.50」を、リスケジュール処理を行う前の当初の当日スケジュール(図5)において、イベント「入浴」を行う時間帯に必要なマンパワー「2.00」から減算する。これにより、作成部563は、当該減算の結果「1.50」を、当日スケジュールを改変したことによって、イベント「入浴」を行う時間帯に生じるマンパワーの差分として把握する。
一方、図11の表112に示すように、対象利用者「A」のスケジュールを改変したことによって、対象利用者「A」がイベント「訪問」に出席した場合のマンパワー「1.00」が必要になる。このため、作成部563は、図11の表112の「マンパワー」欄に示すように、当日スケジュールの改変後、イベント「訪問」を行う時間帯に必要なマンパワーは「1.00」であることを把握する。ただし、リスケジュール処理を行う前の当初の当日スケジュール(図5)において、イベント「訪問」を行う時間帯は存在しない。このため、作成部563は、当該把握したマンパワー「1.00」を、リスケジュール処理を行う前の当初の当日スケジュールにおいて、イベント「訪問」を行う時間帯に必要なマンパワー「0.00」から減算する。これにより、作成部563は、当該減算の結果「-1.00」を、当日スケジュールを改変したことによって、イベント「訪問」を行う時間帯に生じるマンパワーの差分として把握する。
そして、作成部563は、これらの把握した情報と、施設リソース情報DB132に記憶されている情報(図4)と、に基づき、介護内容が仮決定された対象利用者が各イベントを行う時間帯を設定する。また、作成部563は、各イベントを行う時間帯を設定した後、プロセッサ56がスケジュール情報を生成する場合と同様にして、当該設定後の各時間帯に必要なマンパワーを設定する。
尚、対象利用者が複数存在する場合、作成部563は、所定の作成条件に従って、当該時間帯の設定を行う対象の対象利用者の順番を決定する。本例では、作成条件は、介護内容が個室での介護に仮決定された対象利用者を、介護内容が在宅での介護に仮決定された対象利用者よりも優先することに、定められているものとする。ただし、作成条件は、これに限らず、例えば対象利用者の年齢順等であってもよい。
具体的には、作成部563は、上記作成条件に従い、介護内容が個室での介護に仮決定された対象利用者「B」を、介護内容が在宅での介護に仮決定された対象利用者「A」よりも優先し、先ず、対象利用者「B」が各イベントを行う時間帯を設定する。
詳述すると、作成部563は、プロセッサ56がスケジュール情報を生成する場合と同様にして、各時間帯に必要なマンパワー及び当該各時間帯にイベントに出席する利用者の人数が、介護施設の設備リソース及び人的リソースによって定められる制限条件を満たすように、介護内容が仮決定された対象利用者「B」が各イベントを行う時間帯を設定する。
これにより、例えば、作成部563は、図11の表131-1、131-2に示すように、対象利用者「B」が出席するイベント「送迎」、「バスの乗降」、「食事」、「静養」を行う時間帯を、「10:00-10:40、16:10-16:50」、「10:40-10:50、16:00-16:10」、「12:00-13:00」、「10:50-12:00、13:00-16:00」に設定する。そして、作成部563は、プロセッサ56がスケジュール情報を生成する場合と同様にして、当該時間帯に必要なマンパワーを設定する。
次に、作成部563は、介護内容が在宅での介護に仮決定された対象利用者「A」がイベント「訪問」を行う時間帯を設定する。ただし、図11の表112に示すように、当日スケジュールを改変したことによって、イベント「訪問」を行う時間帯に生じるマンパワーの差分が負の値「-1.00」を示している。これは、リスケジュール処理の実行前よりも、マンパワーが「1.00」だけ多く必要になったことを示す。このため、対象利用者「A」がイベント「訪問」を行う時間帯を不用意に設定すると、当該設定した時間帯においてマンパワーが不足する虞がある。そこで、作成部563は、対象利用者「A」がイベント「訪問」を行う時間帯を、前記マンパワーの差分が大きいイベントが設定されている時間帯から優先して決定する。
具体的には、図11の表112に示すように、当日スケジュールを改変したことによって、イベント「入浴」を行う時間帯に生じるマンパワーの差分が「1.50」であり、イベント「食事」を行う時間帯に生じるマンパワーの差分が「0.60」となっている。このため、作成部563は、先ず、対象利用者「A」がイベント「訪問」を行う時間帯を、前記マンパワーの差分が最も大きいイベント「入浴」が設定されている時間帯「11:00-12:00」に設定することを検討する。
具体的には、作成部563は、当該設定を行ったと仮定する。この場合、図11の表133-1に示すように、対象利用者「A」がイベント「訪問」を行う時間帯「11:00-12:00」に必要なマンパワーは「1.50」となり、人的リソーステーブル132B(図4)から把握される、「11:00-16:00の時間帯は、2.00以下のマンパワーを確保可能である。」という制限条件を満たすことになる。よって、作成部563は、対象利用者「A」がイベント「訪問」を行う時間帯を、イベント「入浴」が設定されている時間帯「11:00-12:00」に設定する。そして、作成部563は、プロセッサ56がスケジュール情報を生成する場合と同様にして、当該時間帯に必要なマンパワーを設定する。
これにより、作成部563は、図11の表133-1に示す、時間帯と当該時間帯に各利用者が出席する介護のイベントと当該時間帯に必要なマンパワーとを対応付けたスケジュール情報を、第一のリスケジュール案として作成する。
上記と同様にして、作成部563は、対象利用者「A」がイベント「訪問」を行う時間帯を、前記マンパワーの差分が次に大きい値「0.60」となっている、イベント「食事」が設定されている時間帯「12:00-13:00」に設定することを検討する。
具体的には、作成部563は、対象利用者「A」がイベント「訪問」を行う時間帯を、前記マンパワーの差分が次に大きいイベント「食事」が設定されている時間帯「12:00-13:00」に設定したと仮定する。図11の表133-2に示すように、この場合、対象利用者「A」がイベント「訪問」を行う時間帯「12:00-13:00」に必要なマンパワーは「1.40」となり、人的リソーステーブル132B(図4)から把握される、「11:00-16:00の時間帯は、2.00以下のマンパワーを確保可能である。」という制限条件を満たすことになる。よって、作成部563は、対象利用者「A」がイベント「訪問」を行う時間帯を、イベント「食事」が設定されている時間帯「12:00-13:00」に設定する。そして、作成部563は、プロセッサ56がスケジュール情報を生成する場合と同様にして、当該時間帯に必要なマンパワーを設定する。
これにより、作成部563は、図11の表133-2に示す、時間帯と当該時間帯に各利用者が出席する介護のイベントと当該時間帯に必要なマンパワーとを対応付けたスケジュール情報を、第二のリスケジュール案として作成する。
一方、対象利用者が各イベントを行う時間帯をある時間帯に設定することを仮定した場合に、当該時間帯に必要なマンパワーが制限条件を満たさなかったとする。この場合、作成部563は、当該仮定した設定はできないと判断し、対象利用者が各イベントを行う時間帯を他の時間帯に設定することを検討する。
上記と同様にして、作成部563は、所定数のリスケジュール案を作成する。
(変形例)
本開示は下記の変形例が採用できる。
(1)上記実施形態では、利用者が介護施設を利用する当日に、施設端末50が、利用者端末30から、生体情報として、利用者の体温を示す情報を取得する例について説明した。しかし、これに限らず、利用者が介護施設を利用する当日に、施設端末50が、利用者端末30から、更に、当該利用者と同居する家族が当該当日に感染症に罹患しているか否かを示す罹患情報を取得するようにしてもよい。
具体的には、介護施設の利用者又は当該利用者の連絡者が、前記罹患情報を利用者端末30に入力し、利用者端末30を操作して、当該入力した罹患情報を施設端末50に送信するようにすればよい。そして、第一取得部561が、利用者端末30(図1)から送信され、通信部53が受信した罹患情報を通信部53から取得するようにすればよい。
そして、ステップS02(図7)で用いる変更条件を、利用者の当日における体温が、当該当日の前日における体温よりも所定の値(例えば、0.5℃)を超えて上昇しており、且つ、当該利用者についての前記罹患情報が、感染症に罹患していないことを示すことに設定してもよい。そして、ステップS05(図7)で用いる隔離条件を、利用者の当日における体温が、所定の体温(例えば、38℃)よりも高い、又は、当該利用者についての前記罹患情報が、当該利用者と同居する家族が当該当日に感染症に罹患していることを示すことに設定してもよい。
例えば、利用者の当日の体温が当該当日の前日における体温よりも所定の値を超えて上昇していたとしても、当該利用者についての罹患情報が、当該利用者と同居する家族が当該当日に感染症に罹患していることを示しているとする。この場合、本構成では、ステップS02(図7)において、当該利用者の生体情報は、当該利用者の当日の健康状態が変更条件を満たすことを示す生体情報ではないと判定される。
一方、ステップS05(図7)では、当該利用者の生体情報は、当該利用者の当日の健康状態が隔離条件を満たすことを示す生体情報であると判定される。これにより、ステップS13(図8)におけるリスケジュール案の作成において、介護施設を利用する当日に同居する家族が感染症に罹患している利用者の介護内容を、自宅での静養に改変することができる。その結果、当該利用者が、希望する介護を受けることで、他の利用者が感染症に感染するリスクを低減できる。
(2)上記実施形態では、生体センサー20又は利用者端末30から利用者の当日の生体情報を取得し、ステップS02において、利用者の健康状態が所定の変更条件を満たすことを示す生体情報の有無を判定していた。しかし、これに代えて、利用者又はその連絡者が、利用者端末30に利用者の健康状態を表す情報(以降、健康情報)を入力し、利用者端末30を操作して、施設端末50に送信するようにしてもよい。そして、ステップS02において、利用者の健康状態が所定の変更条件を満たすことを示す健康情報の有無を判定するようにしてもよい。
(3)ステップS05(図7)を省略し、ステップS02(図7)において、利用者の健康状態が変更条件を満たすことを示す生体情報が存在しないと判定された場合は、リスケジュール処理を終了するようにしてもよい。
(4)上記実施形態では、ステップS3(図7)において、第二取得部562が、対象利用者又は当該対象利用者の連絡が利用する利用者端末30に対して、当日の介護内容の希望を問い合わせる旨のメッセージを送信する例について説明した。しかし、これに代えて、第二取得部562が、対象利用者に対して当日の介護内容の希望を問い合わせるよう、スタッフに指示する旨のメッセージを、スタッフ端末40に対して送信するようにしてもよい。これに応じて、スタッフ端末40では当該メッセージを示す音声をスピーカによって出力するようにしてもよい。これにより、当該スタッフ端末40を利用するスタッフが、電話等で対象利用者の当日の介護内容の希望を問い合わせるようにしてもよい。
これと同様にして、ステップS15(図8)及びS19(図8)において、通知部564が、リスケジュール案における対象利用者の当日スケジュールが希望通りであるか否かの確認を対象利用者に要求するよう、スタッフに指示する旨のメッセージを、スタッフ端末40に対して送信するようにしてもよい。これにより、当該スタッフ端末40を利用するスタッフが、電話等で対象利用者に、リスケジュール案における対象利用者の当日スケジュールが希望通りであるか否かの確認を要求するようにしてもよい。
(5)ステップS13において、作成部563がリスケジュール案の作成時に用いる作成条件を複数定めてもよい。そして、ステップS18(図8)において、未確認のリスケジュール案が存在しなくなった場合に、作成条件を未使用の作成条件に変更してステップS13(図8)以降の処理を行うことを、未使用の作成条件がなくなるまで繰り返すようにしてもよい。この場合、作成部563によって多様なリスケジュール案を作成させることができる。これにより、対象利用者に当日の介護内容を再度問い合わせる機会を低減できる。
(6)上記の実施形態及び変形実施形態では、施設端末50が全処理を行う形態について説明したが、これに替えて、施設端末50が行う処理と同様の処理を、DBサーバ10が実行するようにしてもよい。この場合、生体センサー20、利用者端末30、及びスタッフ端末40と施設端末50との間で種々の情報を通信する処理と同様の通信処理を、生体センサー20、利用者端末30、及びスタッフ端末40とDBサーバ10との間で、施設端末50を介さずに又は施設端末50を介して、行うようにしてもよい。
又は、ステップS17(図8)を以下のように変更してもよい。つまり、通知部564がリスケジュール案をDBサーバ10に送信し、これに応じて、DBサーバ10のプロセッサが、ステップS17(図8)と同様に、当該送信されたリスケジュール案を更新及び通知する処理を行うようにしてもよい。