(57)【要約】【課題】発生してしまった事案の考え得る原因、要因、危険因子及び留意事項等を多面的な観点で提示すること。【解決手段】サービス支援システム２１０は、事案の発生に関係する各事象に対する各原因を関連付けたデータ群を事案の種別毎に格納する原因データベース４６０と、発生した事案の種別と事案の発生状況とを含む入力を受け付ける受付部３１４と、受け付けられた発生状況と、原因データベースに格納されている受け付けられた事案の種別に対応するデータ群とをマッチングさせるマッチング部３１６と、マッチング部におけるマッチングの結果得られた原因を出力する出力部３１７とを備える。【選択図】図４
2018081632.tif 000002
【特許請求の範囲】
【請求項１】
事案の発生に関係する各事象に対する各原因を関連付けたデータ群を事案の種別毎に格納する原因データベースと、
発生した事案の種別と前記事案の発生状況とを含む入力を受け付ける受付部と、
前記受け付けられた発生状況と、前記原因データベースに格納されている前記受け付けられた事案の種別に対応するデータ群とをマッチングさせるマッチング部と、
前記マッチング部におけるマッチングの結果得られた原因を出力する出力部と
を備える、サービス支援システム。
【請求項２】
前記マッチング部は、前記受け付けられた各発生状況と、前記原因データベースに格納されている前記受け付けられた事案の種別に対応する各データとを比較した結果に基づくスコアを各データに累積して加算し、
前記出力部は、累積されたスコアが所定の条件を満たす前記データに関連付けられた前記原因を出力する、請求項１に記載のサービス支援システム。
【請求項３】
事案の発生に関係する各事象を体系化した複数の発生状況レコードを前記事案の種別毎に格納する発生状況データベースと、
前記受け付けられた事案の種別と発生状況とに対応する発生状況レコードを前記発生状況データベースから入力レコードとして取得する取得部と、
をさらに備え、
前記原因データベースは、前記入力レコードと同様に体系化されたデータ構造を含む原因レコードを前記データ群に含まれるデータとして格納し、
前記マッチング部は、前記取得した入力レコードの特定の階層に含まれるキーワードと、前記原因データベースに格納されている各原因レコードの前記特定の階層に含まれるキーワードとをマッチングさせる、請求項１又は２に記載のサービス支援システム。
【請求項４】
前記マッチング部は、
マッチングのルールを保持する保持部と、
前記ルールに基づいてマッチングの方法を決定する決定部と
を備える、請求項３に記載のサービス支援システム。
【請求項５】
前記ルールは、前記入力レコードの前記特定の階層のキーワードを用いて各原因レコードの中の予め定められた階層とマッチングをさせるルールを含む、請求項４に記載のサービス支援システム。
【請求項６】
前記ルールは、前記入力レコードの処理対象の項目が特定の階層の項目である場合、当該項目の発生状況が選択された入力レコードを新たに取得させるルールを含む、請求項４又は５に記載のサービス支援システム。
【請求項７】
前記受付部は、前記出力部が出力した原因のうち、ユーザによって選択された事項をさらに受け付けることが可能であり、
前記原因データベースは、前記出力部が出力した原因と前記ユーザによって選択された事項とに基づいて再構築される、請求項１から６のいずれか一項に記載のサービス支援システム。
【請求項８】
前記事象は、時系列のデータの推移に関する項目を含み、
前記受付部は、サービス被提供者に関する蓄積されたデータを所定のタイミングで前記発生状況として入力し、
前記マッチング部は、前記蓄積されたデータと前記時系列のデータの推移に関する項目とをマッチングさせる、請求項１から７のいずれか一項に記載のサービス支援システム。
【請求項９】
発生した事案の種別と前記事案の発生状況とを含む入力を受け付けるステップと、
前記受け付けられた発生状況と、事案の発生に関係する各事象に対する各原因を関連付けたデータ群を事案の種別毎に格納する原因データベースに格納されているデータ群のうちの前記受け付けられた事案の種別に対応するデータ群とをマッチングさせるステップと、
前記マッチングの結果得られた原因を出力するステップと
を含む、サービス支援方法。
【請求項１０】
コンピュータに、
発生した事案の種別と前記事案の発生状況とを含む入力を受け付けるステップと、
前記受け付けられた発生状況と、事案の発生に関係する各事象に対する各原因を関連付けたデータ群を事案の種別毎に格納する原因データベースに格納されているデータ群のうちの前記受け付けられた事案の種別に対応するデータ群とをマッチングさせるステップと、
前記マッチングの結果得られた原因を出力するステップと
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス支援システム、サービス支援方法及びプログラムに関する。
【背景技術】
【０００２】
介護施設や医療提供施設では、そこに居留する高齢者の様々な事故が発生し得る。それら事故の原因、要因、危険因子及び事故を予防するために留意すべき事項等は、事故の種別や発生状況に応じて種々異なる。また、多種多様な事故の原因等を特定するためには、相応の知識や経験が必要となる。また、当該事故の分析と今後の対応や予防策の立案には、多くの時間と労力が費やされてしまうこともある。
【０００３】
特許文献１には、ケアプランの生成に際し、ユーザによって選択されたアセスメント項目の組み合せパターンに合致する援助目標項目を抽出する技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第３８８９１８９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
発生した事案の原因、要因、危険因子及び事案の留意すべき事項等をスタッフ等に提示する技術は提案されていない。事案が発生した原因等は、事案の種別や発生状況に応じて様々であり、画一的に特定できるものではない。むしろ、ある種の思い込み等によって、スタッフが気付いていないような真の原因等が見過ごされてしまう危険性もある。
【０００６】
そこで、本発明は、発生した事案の考え得る原因、要因、危険因子及び留意事項等を多面的な観点で提示することを可能とするサービス支援システム、サービス支援方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の一態様に係るサービス支援システムは、事案の発生に関係する各事象に対する各原因を関連付けたデータ群を事案の種別毎に格納する原因データベースと、発生した事案の種別と事案の発生状況とを含む入力を受け付ける受付部と、受け付けられた発生状況と、原因データベースに格納されている受け付けられた事案の種別に対応するデータ群とをマッチングさせるマッチング部と、マッチング部におけるマッチングの結果得られた原因を出力する出力部とを備える。
【０００８】
本発明の一態様に係るサービス支援方法は、発生した事案の種別と事案の発生状況とを含む入力を受け付けるステップと、受け付けられた発生状況と、事案の発生に関係する各事象に対する各原因を関連付けたデータ群を事案の種別毎に格納する原因データベースに格納されているデータ群のうちの受け付けられた事案の種別に対応するデータ群とをマッチングさせるステップと、マッチングの結果得られた原因を出力するステップとを含む。
【０００９】
本発明の一態様に係るプログラムは、コンピュータに、発生した事案の種別と事案の発生状況とを含む入力を受け付けるステップと、受け付けられた発生状況と、事案の発生に関係する各事象に対する各原因を関連付けたデータ群を事案の種別毎に格納する原因データベースに格納されているデータ群のうちの受け付けられた事案の種別に対応するデータ群とをマッチングさせるステップと、マッチングの結果得られた原因を出力するステップとを実行させる。
【発明の効果】
【００１０】
本発明によれば、発生した事案の原因、要因、危険因子及び留意事項等を多面的な観点で提示することができる。
【図面の簡単な説明】
【００１１】
【図１】介護施設で発生する転倒事故の要因の一例を模式的に示す図である。
【図２】利用形態の一例を示す図である。
【図３】サービス支援システムの構成とユーザ端末の構成との例を示すブロック図である。
【図４】データベース部とマッチング部の詳細な構成の例を示す図である。
【図５】転倒事故の事故報告書の作成画面の一例を示す図である。
【図６】入力領域と、入力領域に対応する発生状況レコード群を示す図である。
【図７】入力領域と、入力領域に対応する発生状況レコード群を示す図である。
【図８】外的要因に関する入力レコードの例を示す図である。
【図９】内的要因に関する入力レコードの例を示す図である。
【図１０】原因レコードの例を模式的に示す図である。
【図１１】マッチング処理を説明するための模式図である。
【図１２】縦マッチングと交差マッチングを説明するための図である。
【図１３】マッチング結果画面の一例を示す図である。
【図１４】分析結果画面の例を示す図である。
【図１５】ユーザ端末の制御方法の一例を示すフローチャートである。
【図１６】サービス支援システムにおけるサービス支援方法の一例を示すフローチャートである。
【図１７】マッチング処理の一例を示すフローチャートである。
【図１８】マッチング処理の詳細な処理の一例を示すフローチャートである。
【図１９】所定のルールに従った処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１２】
［用語の説明］
本実施形態で説明する用語について説明する。
【００１３】
「スタッフ」：施設長・管理者、ケアマネージャー（計画作成担当者）、サービス提供責任者、ケアスタッフ・ホームヘルパー、看護職員、機能訓練指導員、生活相談員、生活支援スタッフ及び受付事務員等の施設に関する仕事を行う者のことである。
【００１４】
「利用者」：本実施形態で説明するシステムを利用する者のことである。具体的な例としては、施設のスタッフが挙げられる。
【００１５】
「サービス被提供者」：施設や事業者が提供するサービスを受ける者のことである。必ずしも施設に入居していなくてもよく、一部のサービスを外来で受ける者も含まれる。以下の実施形態では、サービス被提供者は、介護施設に入居する入居者を例に挙げて説明する。なお、サービス被提供者は、通所介護や在宅での訪問介護等のサービスを受ける者のように施設に入居していない者でもよく、以下で説明する実施形態においては両者が混在していてもよい。
【００１６】
添付図面を参照して、本発明の好適な実施形態について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。
【００１７】
［事故の要因の説明］
図１は、介護施設で発生する事故の要因の一例を模式的に示す図である。図１は、転倒事故が発生する要因が多岐に渡る例を示している。例えば、転倒事故が生じる要因を二つに大別すると、内的要因と外的要因とに分けることができる。
【００１８】
内的要因とは、入居者本人に起因する要因であり、転倒事故においては、入居者の身体・生理的要因、疾病・疾患・症状、服用している薬物等の、入居者本人に関する様々な要因のことである。例えば図１に示すように身体・生理的要因と、疾病・疾患・症状要因と、薬物要因とにさらに分類することができる。例えば、身体・生理的要因の例としては、高齢であるのか、転倒の既往があったのか、感覚の低下や運動不足等があったのか、不眠、便秘、体調不良等があったのか、判断力等の低下が生じていたのか、普段と違った様子があったのか等が挙げられる。疾病・疾患・症状要因としては、高血圧等のような循環器系の疾病・疾患・症状や、脳神経系の疾病・疾患・症状や、心因性の疾病・疾患・症状や、骨折、筋力低下等の運動機能の低下等が挙げられる。薬物要因としては、服用している薬の種類や、服用している薬物の数等が挙げられる。例えば薬の副作用によってふらつき、転倒事故が生じることもある。
【００１９】
外的要因とは、入居者本人以外に起因する要因であり、施設の建物の構造や居室等の環境や、入居者が身に着けている衣服や履物や、杖や車いす等の使用用具や、施設のスタッフのスキル、知識、経験、介助方法や関わり方や、情報共有や各種研修等の、施設のマネージメントに関する事項等を含む要因のことである。例えば図１に示すように環境要因とホーム／スタッフ要因に分類することができる。環境要因の例としては、周辺環境や身辺環境がある。例えば、廊下に段差があったり、滑りやすい床になっている場合等のような周辺環境や、杖を使用している等の使用器具や、スリッパを履いていた等の履物等が例として挙げられる。ホーム／スタッフ要因は、例えばスタッフの介助方法等や、ホーム内での情報共有や、周知方法や、アセスメント・プランやスタッフのマネージメント等が挙げられる。なお、上述した要因の例は、一例に過ぎず、これに限られるものではない。
【００２０】
このように、転倒事故という括りを一つ例に挙げるだけでも、その事故の要因としては様々な要因が含まれる。また、これらの要因が複数結びつくことで転倒事故が発生する場合もある。さらに、事故の種別としては、転倒事故のみならず、例えば誤嚥・窒息事故や薬事故等も生じ得る。これらの事故の要因には、転倒事故の要因とは別個の様々な要因が含まれる。このように、介護施設の入居者に起こり得る各種の事故においては、様々な要因が複合的に絡み合って発生することが多い。また、スタッフの知識や経験不足、組織的なフォローアップが十分でない場合もあり、不十分な分析に陥ってしまい、その結果、対応や予防策が不適切なものになってしまう可能性がある。
【００２１】
そこで、本実施形態においては、事故の種別毎に、事故が発生し得る様々な原因、要因及び危険因子等を体系化してデータベース化する。例えば、同じ階層構造のデータとなるようにデータベース化する。そして、事故発生時に、利用者に事故発生の状況（事故発見の状況を含む。以下同様である。）に関する情報を入力させ、入力させた情報と体系化（例えば構造化、階層化）されたデータベースに格納されている情報とを所定のルールに従ってマッチングさせる。そしてマッチングの結果に基づいて原因候補にスコアを付与する。この結果、例えばスコアの高い原因候補がユーザ端末に表示される。このようにして、事故の原因の分析を支援する。
【００２２】
［全体の構成］
図２は、本実施形態における利用形態の一例を示す図である。サービス支援システム２１０はサーバ装置として構成することが可能であり、複数のユーザ端末２２０ａ、２２０ｂと接続される。図２においては２つのユーザ端末を示しているが、ユーザ端末の数は任意の数であってよい。複数のユーザ端末のことをまとめてユーザ端末２２０という。ユーザ端末２２０及びサービス支援システム２１０は、インターネット及びＬＡＮ（Local Area Network）等のネットワークを通じて相互に接続されている。
【００２３】
ユーザ端末２２０は、介護施設のスタッフによって使用される情報処理端末である。本実施形態において利用者は、介護施設のスタッフを含む。利用者は、サービスの提供に必要な情報等をユーザ端末２２０に表示される情報等を参照して確認することができる。
【００２４】
サービス支援システム２１０は、提供されるサービスに関するデータを記録したサーバ等の情報処理装置である。ユーザ端末２２０は、サービス支援システム２１０から送信されるデータに基づいてユーザ端末２２０に情報を表示することができる。また、サービス支援システム２１０は、利用者を例えばログイン方式で管理しており、ユーザ端末２２０の利用者に応じたデータをユーザ端末２２０に送信することもできる。
【００２５】
図３は、本実施形態に係るサービス支援システム２１０の構成とユーザ端末２２０の構成との例を示すブロック図である。
【００２６】
［ユーザ端末の構成］
ユーザ端末２２０は、入力部３２０、通信部３２１、表示部３２３、表示制御部３２４、記憶部３２５及び記憶制御部３２６を備える。ユーザ端末２２０は、例えばタブレット端末、スマートフォン及びパーソナル・コンピュータ等の各種の情報処理端末とすることができる。
【００２７】
入力部３２０には、利用者からの操作指示が入力される。
【００２８】
通信部３２１は、サービス支援システム２１０の通信部３１１との間で各種のデータを送受信する。すなわち、通信部３２１は、受信部及び送信部として機能する。
【００２９】
表示部３２３は、後述する事故報告書の作成画面を含む各種の画面を表示する。例えば、表示部３２３は、液晶ディスプレイ及び有機ＥＬ（electroluminescence）ディスプレイ等とすることができる。
【００３０】
表示制御部３２４は、表示部３２３に表示する情報の制御を行う。
【００３１】
記憶部３２５は、各種のデータを記憶する。例えば、記憶部３２５は、事故報告書の作成に用いられるデータを記憶する。記憶部３２５は、ＨＤＤ（Hard Disc Drive）やフラッシュメモリ等の各種の記憶媒体であってよい。
【００３２】
記憶制御部３２６は、記憶部３２５に各種のデータの書き込みをしたり記憶部３２５から各種のデータを読み出したりする。
【００３３】
ユーザ端末２２０は、不図示のＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）及びフラッシュメモリ又はＨＤＤを備えることができる。フラッシュメモリ又はＨＤＤは、上述した記憶部３２５と共通のものでもよいし別箇のものであってもよい。フラッシュメモリ又はＨＤＤ等に格納されたプログラムが一時的にＲＡＭに読み出され、ＣＰＵが、ＲＡＭに読み出されたプログラムを実行することで、ＣＰＵが、図３に示すユーザ端末２２０の各部として機能することができる。ここではソフトウェアを用いて実現する構成を例に挙げて説明するが、ハードウェア、ファームウェア、及びソフトウェアのいずれで構成してもよい。図３は構成の一例を示したものに過ぎず、ユーザ端末２２０は他の構成を含んでもよい。また、図３に記載された構成の全てが必須の要件であるとは限らない。
【００３４】
［サーバの構成］
次に、サービス支援システム２１０の構成について説明する。サービス支援システム２１０は、通信部３１１、記憶制御部３１２、記憶部３１３、受付部３１４、データベース３１５、マッチング部３１６及び出力部３１７を備える。
【００３５】
通信部３１１は、インターネット及びＬＡＮ等のネットワークのインタフェースを通じてユーザ端末２２０との間でデータの送受信を行う。すなわち、通信部３１１は、送信部及び受信部として機能する。
【００３６】
記憶制御部３１２は、記憶部３１３に各種のデータの書き込みをしたり記憶部３１３から各種のデータを読み出したりする。
【００３７】
記憶部３１３は、各種のデータを記憶する。例えば、記憶部３１３は、入居者が提供を受けるサービスの予定及び実績のデータを記憶する。記憶部３１３は、ＨＤＤ（Hard Disc Drive）やフラッシュメモリ等の各種の記憶媒体であってよい。
【００３８】
受付部３１４は、発生した事案（例えば事故）の種別と事案（例えば事故）の発生状況とを含む各種の情報の入力を受け付ける。例えば、受付部３１４は、通信部３１１において受信したユーザ端末２２０から送信された情報の入力を受け付けることができる。以下では、事案の一例として事故を例に説明する。
【００３９】
データベース３１５は、例えば、事案（事故）の発生（発見を含む。以下同様である）に関係する各事象を体系化（例えば構造化、階層化）したデータ群を事案（事故）の種別毎に格納する。事故の種別としては、例えば転倒事故、誤嚥・窒息事故及び薬事故が挙げられる。つまりこの場合、転倒事故の各事象に対する各原因を関連付けたデータ群と、誤嚥・窒息事故の各事象に対する各原因を関連付けたデータ群と、薬事故の各事象に対する各原因を関連付けたデータ群とを格納する。なお、ここでは３つの事故の種類を例に挙げて説明するが、これに限られることはない。また、説明の便宜上、記憶部３１３とデータベース３１５とを分けて説明しているが、両者を共通化した構成であってもよい。
【００４０】
マッチング部３１６は、受付部３１４において受け付けられた発生状況を、データベース３１５に格納されている、受け付けられた事案（事故）の種別に対応するデータ群とマッチングさせる。詳細については後述する。
【００４１】
出力部３１７は、マッチング部３１６におけるマッチングの結果得られた原因の情報を出力する。例えば、出力部３１７は、通信部３１１を介して原因の情報をユーザ端末２２０に送信することができる。
【００４２】
サービス支援システム２１０は、不図示のＣＰＵ、ＲＡＭ及びフラッシュメモリ又はＨＤＤを備えることができる。フラッシュメモリ又はＨＤＤは、上述した記憶部３１３と共通のものでもよいし別箇のものであってもよい。フラッシュメモリ又はＨＤＤ等に格納されたプログラムが一時的にＲＡＭに読み出され、ＣＰＵが、ＲＡＭに読み出されたプログラムを実行することで、ＣＰＵが、図３に示すサービス支援システム２１０の各部として機能することができる。ここではソフトウェアを用いて実現する構成を例に挙げて説明するが、ハードウェア、ファームウェア、及びソフトウェアのいずれで構成してもよい。
【００４３】
サービス支援システム２１０の各部のうちの少なくとも一部は、複数の情報処理装置による分散処理によって実現されてよい。また、サービス支援システム２１０は、図示しないクラウドサーバ等からダウンロードしたプログラムに従って処理を実行してもよい。図３は構成の一例を示したものに過ぎず、サービス支援システム２１０は他の構成を含んでもよい。また、図３に記載された構成の全てが必須の要件であるとは限らない。
【００４４】
図４は、データベース３１５とマッチング部３１６との詳細な構成の例を示す図である。本実施形態においては、データベース３１５は、発生状況データベース４５０と原因データベース４６０とを有する。発生状況データベース４５０は、事故の種別毎のデータベースを有している。図４の例においては、発生状況データベース４５０は、転倒事故発生状況データベース４５１、誤嚥・窒息事故発生状況データベース４５２及び薬事故発生状況データベース４５３を有する。原因データベース４６０も発生状況データベース４５０と同様に、事故の種別毎のデータベースを有している。図４の例においては、原因データベース４６０は、転倒事故原因データベース４６１、誤嚥・窒息事故原因データベース４６２及び薬事故原因データベース４６３を有する。なお、共通化できる原因は、事故共通原因データベース４６５として有して共有するとしても良い。
【００４５】
発生状況データベース４５０及び原因データベース４６０は、いずれも事故の発生に関係する各事象を体系化（構造化、階層化）したデータ群を事故の種別毎に格納する。発生状況データベース４５０と原因データベース４６０とは、体系化（構造化、階層化）されたレコードを複数含むデータ群をそれぞれ格納する。本実施形態では、発生状況データベース４５０に格納されているレコードのことを「発生状況レコード」という。原因データベース４６０に格納されているレコードのことを「原因レコード」という。本実施形態では、原因レコードは、発生状況レコードと共通のデータ構造を含む。例えばある発生状況レコードの第Ｎ項目（Ｎは自然数）の項目と原因レコードの第Ｎ項目の項目とが、同種の項目のデータを格納する構造となっている。つまり、事故の発生に関する同種の事象同士が、発生状況レコード及び原因レコードの第Ｎ項目に格納されているものとする。本実施形態では、Ｎの値が「１」の項目を階層が最も高い項目として扱い、Ｎの値が増えるに従って、階層が低くなる項目として扱うものとする。
【００４６】
なお、原因レコードには、発生状況レコードと共通のデータ構造に加えて、「押えるべき観点や原因の候補」といったような、事故発生の各種の要因等を示すデータが関連付けられている。つまり、原因データベース４６０は、事故の発生に関係する各事象に対する各原因を関連付けたデータ群を格納するものである。発生状況レコードと原因レコードとの詳細は後述する。
【００４７】
マッチング部３１６は、キーワード抽出部４０１、入力レコード取得部４０２、マッチングルール保持部４０３、マッチング方法決定部４０４、マッチング処理実行部４０５及びマッチング結果出力部４０６を備える。
【００４８】
キーワード抽出部４０１は、入力を受け付けた発生状況に関する情報に基づいて、データベースの検索に用いられるキーワードを抽出する。例えば、図５（後述する）に示すような、ユーザ端末２２０の表示部３２３で表示される事故報告書の作成画面５００においては、事故が発生した場合の状況を入力する入力領域が含まれる。キーワード抽出部４０１は、入力領域に入力された情報に基づいてキーワードを抽出することができる。例えば、転倒事故の場合には、「発見・発生場所」のキーワードとして「居室」が入力されたり、そのさらに詳細な情報として「ベッド」が入力されたりする。この場合、キーワード抽出部４０１は、「居室」及び「ベッド」をキーワードとして抽出することになる。また、入力された文章を、自然言語解析等の手法やソフトウェア等を用いて単語や熟語に分解して、一つ若しくは複数のキーワードを生成しても良い。
【００４９】
入力レコード取得部４０２は、受付部３１４で入力を受け付けた、発生した事故の種別に対応するデータベースを発生状況データベース４５０の中から選択する。例えば、入力を受け付けた事故の種別が「転倒事故」である場合、入力レコード取得部４０２は、転倒事故発生状況データベース４５１を選択する。そして、入力レコード取得部４０２は、キーワード抽出部４０１で抽出されたキーワードを用いて、選択された転倒事故発生状況データベース４５１を検索して、キーワードが全て含まれる発生状況レコードを入力レコードとして取得する。取得された入力レコードは、原因データベース４６０に格納されている原因レコードとのマッチング処理で用いられることになる。入力レコードは、マッチング方法決定部４０４に送られる。
【００５０】
マッチングルール保持部４０３は、マッチングルールを保持する。本実施形態においては、入力レコードと、原因レコードとの対応する項目同士（第Ｎ項同士）を比較することにより、マッチング処理が行われる。このように、第Ｎ項同士を比較するマッチング処理のことを本実施形態では「横マッチング」という。本実施形態では、基本的にこの横マッチングを用いてマッチング処理を行う例を説明するが、特定の項目（あるいは特定のキーワード）が含まれる入力レコードに対しては、別のマッチング方法が行われることがある。詳細は後述する。
【００５１】
マッチング方法決定部４０４は、入力レコードのマッチング方法を、マッチングルール保持部４０３に保持されているマッチングルールを参照して決定する。
【００５２】
マッチング処理実行部４０５は、マッチング方法決定部４０４によって決定されたマッチング方法に従って、入力レコードを用いたマッチング処理を、事故の種別に対応する原因データベース４６０に対して行う。前述のように事故の種別が転倒事故である場合、マッチング処理実行部４０５は、転倒事故原因データベース４６１に対してマッチング処理を実行する。例えば、マッチング処理実行部４０５は、処理対象の入力レコードの第Ｎ項目に含まれるキーワードが、処理対象の原因レコードの第Ｎ項目に含まれるキーワードに一致するかを判定する。そして、一致した場合、当該第Ｎ項目に対応付けられた重みに応じたスコアを、処理対象の原因レコードに累積されているスコアに加算する。このようなマッチング処理（横マッチング処理）が、転倒事故原因データベース４６１の処理対象候補の全ての原因レコードに対して行われる。また、処理対象の入力レコードを変えながら前述のマッチング処理を行う。マッチングを行ったスコアは、累積して加算されることになるので、この結果、入力レコードとの一致度が高い原因レコードのスコアが高くなる。
【００５３】
マッチング結果出力部４０６は、マッチング処理実行部４０５によるマッチング処理の結果を出力する。マッチング処理実行部４０５によるマッチング処理の結果、各原因レコードのスコアが算出されている。マッチング結果出力部４０６は、所定の閾値を超えるスコアが算出された原因レコードを、マッチング処理の結果として出力することができる。あるいは、マッチング結果出力部４０６は、原因レコード自体ではなく、原因レコードに関連付けられている「押えるべき観点や原因の候補」といったような事故発生の各種の要因等を示すデータを、マッチング結果として出力してもよい。
【００５４】
次に、具体的な例を挙げながら、マッチング処理の詳細について説明する。
【００５５】
図５は、ユーザ端末２２０の表示部３２３で表示される、転倒事故の事故報告書の作成画面５００の一例を示す図である。事故報告書とは、事故が発生した場合（あるいは事故を発見した場合）に、その事故の内容や対応状況、原因の分析と今後の対応や予防策等を記載した報告書である。ユーザ端末２２０の利用者（介護施設のスタッフ）は、作成画面５００に従って必要な事項を入力する。また、不図示の他の画面で既に入力済みの事項が作成画面５００に反映されてもよい。
【００５６】
入力領域５０１は、転倒事故を発見した日時・転倒事故が発生した日時をユーザ端末２２０の利用者が入力する領域である。入力領域５０２は、転倒事故を発見した状況・転倒事故が発生した状況をユーザ端末２２０の利用者が入力する領域である。入力領域５０３は、転倒事故を発見した場所・転倒事故が発生した場所をユーザ端末２２０の利用者が入力する領域である。入力領域５０４は、転倒事故を発見した発見者をユーザ端末２２０の利用者が入力する領域である。図５の作成画面５００は、入力領域の一部を例示しているものであり、例えば画面をスクロールすることで他の入力領域を入力する画面が表示部３２３に表示される。
【００５７】
図６は、図５の作成画面５００をスクロール又は別画面で表示される入力領域６０１、６０２、６０３と、それらの入力領域に対応する事象を含む発生状況データベース４５０の発生状況レコード群６１０、６２０、６３０を示している。発生状況レコード群６１０、６２０、６３０は、外的要因に関するレコード群である。図１を用いて説明したように、外的要因の中でカテゴリが分類されており、図６の例では、「発見・発生場所」のカテゴリ、「障害物」のカテゴリ及び「身辺」のカテゴリが存在する例を示している。
【００５８】
発生状況レコード群６１０を例に挙げて発生状況データベース４５０に格納される発生状況レコードのデータ構造について説明する。発生状況レコードは、前述したような階層化された構造を有している。図６の例では、最上位の階層を「Ｌｖ１」と表示しており、階層が下がるに従って「Ｌｖ２」、「Ｌｖ３」とレベル数が増えている。図６は、図１で説明したような「外的要因」に関するレコードであるので、最上位の階層の項目には、「外的」のデータが含まれている。また、レコード群６１０は、「発見・発生場所」のカテゴリのレコード群であるので、「Ｌｖ２」の階層の項目には、「場所」のデータが含まれる。その後の階層の項目には、入力領域６０１で入力され得る項目が含まれたレコードが含まれている。図６に示すように、発生状況レコードは、最上位の階層から下位の階層に向かうに従ってより詳細な（具体的な）内容を設定するものとなっている。
【００５９】
入力領域６０１では、発見・発生場所の候補としてチェックボックスによるチェックが可能な事項が複数列挙されている。この例では、「居室」にチェックがされている。また、「居室」の中には、さらにラジオボタンが含まれており、居室の中の詳細な場所の指定が可能となっている。この例では、「トイレ」が選択されている。ユーザ端末２２０の表示部３２３に表示されているこのような入力領域６０１において入力部３２０によって入力された情報が、ユーザ端末２２０からサービス支援システム２１０に送信される。
【００６０】
サービス支援システム２１０では、キーワード抽出部４０１が、ユーザ端末２２０から送信された情報に基づいて、キーワードを抽出する。この例では、「発見・発生場所」のカテゴリのキーワードとして、送信されたデータに基づいて「居室、トイレ」をキーワードとして抽出する。そして、入力レコード取得部４０２が、転倒事故発生状況データベース４５１から、そのキーワードに対応する発生状況レコードを入力レコードとして取得することになる。つまり、図６の例では、「発見・発生場所」のカテゴリの入力レコードとして、レコード群６１０の中でレコード６１１が取得されることになる。
【００６１】
同様に、入力領域６０２で入力された事項に従って、「障害物」のカテゴリのレコード群６２０の中から対応する入力レコードが取得され、入力領域６０３で入力された事項に従って、「身辺」のカテゴリのレコード群６３０の中から対応する入力レコードが取得されることになる。
【００６２】
つまり、図６の例においては、入力領域６０１、６０２、６０３で入力された事項に従って、発生状況レコード６１１、６２１、６２２、６３１、６３２、６３３を、入力レコード取得部４０２が入力レコードとして取得することになる。これらの入力レコードは、後述するようにマッチング処理に用いられることになる。
【００６３】
図７は、図５の作成画面５００をスクロール又は別画面で表示される入力領域７０１、７０３と、図５の作成画面に含まれる入力領域５０１と、それらの入力領域に対応する発生状況データベース４５０のレコード群７１０を示している。レコード群７１０は、内的要因に関するレコード群である。内的要因の中で「事故時の行動」、「いつもと違った様子」、「疾病・疾患・症状」、「薬物」にカテゴリが分類されている。図７の例では「事故時の行動」のカテゴリの発生状況レコードの例を示している。
【００６４】
レコード群７１０は、図６の外的要因で説明した内容と同様に、入力領域７０１で入力され得る事項に対応する各レコードが含まれており、キーワード抽出部４０１が、ユーザ端末２２０から送信された情報に基づいて、キーワードを抽出する。そして、入力レコード取得部４０２が、転倒事故発生状況データベース４５１から、そのキーワードに対応する発生状況レコードを入力レコードとして取得することになる。つまり、図７の例では、「事故時の行動」のカテゴリのレコード群７１０の中で、レコード７１１、７１２、７１３が取得されることになる。
【００６５】
なお、図７に示すような内的要因の場合には、該当するカテゴリの入力領域で入力された情報以外にも、他の入力領域で入力された情報を、レコードの所定の項目のキーワードに用いることができる。例えば、入力領域５０１においては、事故を発見した際の発見日時・事故が発生した際の発生日時が入力されるので、その入力された日時に基づいてキーワード抽出部４０１は、時間帯のキーワードを抽出する。例えばテーブル７２１に示すように、予め事故報告書の発見・発生日時として入力された値と、時間帯とを対応付けたテーブルを用意しておく。キーワード抽出部４０１は、テーブル７２１を参照して、例えば時間帯が「早朝」であるか「日中」であるか「夜間」であるか「深夜」であるかを決定する。そして、入力レコード取得部４０２は、レコード群７３０に示すように、レコード群７１０の「Ｌｖ６」の階層に当該キーワード（この例では「夜間」）を含むレコード群７３０を入力レコードとして取得する。つまり、既に他の入力領域で入力された値を転用することで、再度の入力の手間を省くことができるとともに、入力漏れがあったとしても適切なレコードを入力レコードとして入力レコード取得部４０２は取得することができる。
【００６６】
同様に、入力領域７０３は、「事故時の行動」のカテゴリに対応する入力領域以外の入力領域であり、事故発生状況を選択する領域を示している。テーブル７２２は、この入力領域７０３に入力された値と、対応するキーワードとを対応付けたテーブルである。キーワード抽出部４０１は、入力領域７０３で入力された値とテーブル７２２とに基づいて、「介助中」であるか「非介助中」であるか何も入れない「ＮＵＬＬ」であるかを決定する。そして、入力レコード取得部４０２は、レコード群７３０に示すように、レコード群７１０の「Ｌｖ７」の階層に、当該キーワード（この例では「介助中」）を含むレコード群を入力レコードとして取得する。
【００６７】
なお、このように、他の入力領域で入力された値を参照するテーブル情報や、参照して得られたキーワードを入力する入力先を示す各種の情報は、マッチングルール保持部４０３に保持されていてよく、キーワード抽出部４０１及び入力レコード取得部４０２は、マッチングルール保持部４０３に保持されているマッチングルールを参照して、処理を行うことができる。
【００６８】
同様にして、入力レコード取得部４０２は、他のカテゴリである「いつもと違った様子」、「疾病・疾患・症状」及び「薬物」の入力レコードも取得する。
【００６９】
図８は、入力レコード取得部４０２によって取得された外的要因に関する入力レコードの例を示す図である。図６を用いて説明したような処理に従って、各カテゴリの入力レコードが取得される。マッチング処理実行部４０５は、このようにして得られた各カテゴリの各入力レコードと、原因データベース４６０に格納されている各原因レコードとをマッチングする処理を行うことになる。なお、図７で説明したように、項目８０１や項目８０２のように、外的要因として扱われる項目が、内的要因の特定の項目のキーワードに設定されるなど、あるカテゴリで扱われる項目が、他のカテゴリでも使用されることもある。
【００７０】
図９は、入力レコード取得部４０２によって取得された内的要因に関する入力レコードの例を示す図である。図７を用いて説明したような処理に従って、各カテゴリの入力レコードが取得される。項目９５１には、図８の項目８０１及び項目８０２のキーワードが含まれている。なお、これまでの例では、入力領域には、ラジオボタン及びチェックボックス等によって予め値が規定されており、規定されている値（キーワード）をそのまま用いる形態を説明したが、これに限られない。例えば、項目９６０に示すように、入力領域の選択肢に「入浴後に疲れがある」という項目があった場合を想定する。この場合、キーワード抽出部４０１は、例えばキーワードとして項目９５５に示すように「入浴」を設定し、かつ、項目９５６に示すように「入浴疲れ」を設定することもできる。キーワード抽出部４０１は、例えばマッチングルール保持部４０３に保持されているルールに従って、このようなキーワードの抽出を行ってもよい。
【００７１】
また、これまでは入力領域に予め選択肢が含まれている形態を例に挙げて説明したが、入力領域が自由記入欄であってもよい。この場合、キーワード抽出部４０１は、入力された情報に基づいて、キーワードを抽出してもよい。
【００７２】
次に、原因データベース４６０の構造について説明する。
【００７３】
図１０は、原因データベースに含まれる原因レコードの例を模式的に示す図である。原因データベース４６０に含まれる原因レコードは、発生状況データベース４５０に含まれる発生状況レコードと同じ階層構造を含むものである。
【００７４】
例えば、図１０（ａ）は、外的要因に関する原因レコードの構造の例を示しており、原因レコードのうちの第一の部分１００１は、図８の入力レコード（発生状況レコード）の構造と同じ構造である。
【００７５】
ただし、発生状況レコードの各項目に設定されたキーワードに対して、原因レコードは、そのキーワードの同義語、同意語、類義語、他言語、言い換え、言い回し等が設定され得る形態である。これは、例えば発生状況レコードの各項目に含まれるキーワードの表記ゆれ等が生じた場合にも、マッチング処理で一致させるためである。例えば、「ベッド」という項目を例に挙げて説明すると、原因レコードの「ベッド」の項目には、表記ゆれ等に備えて「べっと」「べっど」「ベット」「ｂｅｄ」等のように複数のキーワードが設定されていてもよい。
【００７６】
また、原因レコードには第二の部分１００２がさらに含まれている。第二の部分１００２は、それぞれの第一の部分１００１の内容に応じた、「押えるべき観点や原因の候補」といったような、事故発生の各種の要因等を示すデータが含まれる。つまり、原因レコードは、事故の発生に関係する事象（第一の部分１００１）に対する原因（第二の部分１００２）が関連付けられたデータといえる。
【００７７】
図１０（ｂ）は、内的要因に関する原因レコードの構造の例を示しており、外的要因と同様に、原因レコードのうちの第一の部分１０５１は、図９の入力レコード（発生状況レコード）の構造と同じ構造であり、原因レコードのうちの第二の部分１０５２は、第一の部分１０５１の内容に応じた、「押えるべき観点や原因の候補」といったような、事故発生の各種の要因等を示すデータが含まれる。
【００７８】
図１１は、マッチング方法決定部４０４が決定するマッチング方法に従ってマッチング処理実行部４０５によって実行されるマッチング処理を説明するための模式図である。
【００７９】
マッチング処理の説明に先立って、まず、マッチング方法決定部４０４が決定するマッチング方法の種類について説明する。マッチング方法決定部４０４は、マッチングルール保持部４０３に保持されているマッチングルールを参照して、入力レコードに対応するマッチング方法を決定する。本実施形態におけるマッチング方法の種類としては、「横マッチング」と「縦マッチング」と「交差マッチング」とがある。もちろん、これは一例に過ぎず、「ランダムマッチング」や「全件マッチング」等、他にも多様なマッチング方法が考えられるため、これに限られるものではない。以下、各マッチング方法について説明する。
【００８０】
［横マッチング］
「横マッチング」は、前述したように、入力レコードの各項目と、原因データベースに含まれる原因レコードの各項目とマッチングさせる際に、各々同じ階層レベルの同じ項目同士をマッチングさせる処理である。例えば、図１１の例で説明すると、「発見・発生場所」のカテゴリの入力レコード１１１０の最上位の階層（Ｌｖ１）の項目と、原因レコード１１５１群に含まれる原因レコード１１５２の最上位の階層（Ｌｖ１）の項目同士をマッチングさせる。具体的には、入力レコード１１１０の最上位の階層（Ｌｖ１）の項目に含まれるキーワードと、原因レコード１１５２の最上位の階層（Ｌｖ１）の項目に含まれるキーワードとを比較して、一致するかを判定する。一致した場合、入力レコードの重み係数１１０２に応じた重みを用いたスコアが、当該原因レコード１１５２に累積されているスコア（初期値は０とする）に加算される。次に、「発見・発生場所」のカテゴリの入力レコード１１１０の二番目の階層（Ｌｖ２）の項目と、原因レコード１１５１群に含まれる原因レコード１１５２の二番目の階層（Ｌｖ２）の項目同士をマッチングする。そして、図１１の例では、最下位の階層（Ｌｖ７）と（Ｌｖ７）の項目同士のマッチングが終了すると、引き続き発生状況レコード１１１０と、原因レコード群１１５１に含まれる次の原因レコード１１５３とのマッチング処理が行われることになる。
【００８１】
このようにして、「発見・発生場所」のカテゴリの入力レコード１１１０と、「発見・発生場所」のカテゴリの原因レコード群に含まれる全ての原因レコードとのマッチングが行われる。入力レコード１１１０の処理が終了すると、発生状況レコード群１１０１の中の「発見・発生場所」のカテゴリの次の入力レコード１１１１を処理対象の入力レコードとして用いて、同様にマッチング処理が行われる。
【００８２】
「発見・発生場所」のカテゴリの入力レコードを用いたマッチング処理が終了すると、引き続き、次のカテゴリである「障害物」のカテゴリの入力レコードと、原因レコード群１１５１の中の「障害物」のカテゴリの原因レコードとのマッチング処理が行われる。
【００８３】
本実施形態においては、階層に応じて重み係数１１０２が設定される。具体的には、重み係数１１０２は、階層が下になるほど、重みが重くなる係数である。前述した各例で説明したように、本実施形態における発生状況レコード及び原因レコードは、階層が下になるに従って、より詳細な項目が設定されることになる。例えば、「発見・発生場所」のカテゴリを例に挙げると、上位の階層で「居室」が設定されている場合、その下位の層では「ベッド」が設定され、さらにその下位の階層では「二段ベッド」が設定される等がある。より詳細な項目になるほど、押えるべき観点や原因の候補も具体的な内容になる。したがって、階層が下になるほど重みを重くする重み係数１１０２を用いることで、詳細な項目が一致した場合の原因レコードのスコアを高くすることができる。したがって、具体的な、「押えるべき観点や原因の候補」が選ばれ易くなる。
【００８４】
なお、図１１の例では、カテゴリ毎に処理が行われる例を説明したが、前述したように、発生状況レコード及び原因レコードの最上位の階層は、「内的要因」又は「外的要因」の項目を含むことができ、最上位の一つ下の階層は、「発見・発生場所」などのカテゴリの項目を含むことができる。したがって、カテゴリを意識せずに、処理対象の入力レコードに対して全ての原因レコードを処理対象として処理を行う形態でもよい。
【００８５】
［縦マッチング］
図１２は、「縦マッチング」と「交差マッチング」を説明するための図である。「縦マッチング」について説明する。「縦マッチング」は、特定のカテゴリの入力レコードの特定の階層のキーワードを用いて各原因レコードの中の予め定められた階層の項目のみとマッチングをさせる処理のことである。このように、各原因レコードの中の特定の階層のみを対象にマッチングを行うこと、つまり、列方向（縦方向）にマッチングを行うことを言う。これにより、カテゴリを跨ったマッチングが行われることになる。この特定のカテゴリの特定の階層は、マッチングルール保持部４０３に保持されているマッチングルールによって予め定義されているものとする。つまり、マッチング方法決定部４０４が入力レコード取得部４０２から入力レコードを受け取った場合、マッチング方法決定部４０４は、マッチングルール保持部４０３に保持されているマッチングルールを参照して、「縦マッチング」に該当するかを判定する。そして、該当する場合、マッチング方法決定部４０４は、その項目に含まれるキーワードを用いて、「縦マッチング」の処理をさらに実行することを決定する。なお、その項目にキーワードが含まれていない場合は、処理を実行しない。
【００８６】
具体的な例を挙げて説明する。マッチングルールとして、次の内容が予め定義されているものとする。すなわち、特定のカテゴリの特定の項目に設定されているキーワードと、各原因レコードの特定の階層の項目とのマッチングを実行させるマッチングルールが定義されているものとする。そして、例えば、処理対象の入力レコードの「いつもと違う様子」カテゴリの項目（Ｌｖ５）に、「ふらつき」というキーワードが含まれている場合には、「事故時の行動」「疾病・疾患・症状」「薬物」カテゴリの階層（Ｌｖ５）に対して「縦マッチング」を行うとマッチング方法決定部４０４が決定することになる。
【００８７】
なお、「縦マッチング」は、「横マッチング」に追加的に行われるマッチング処理であり、特定のキーワード（例えば「ふらつき」）が含まれている入力レコードを処理するに際しては、「横マッチング」自体の処理もその処理対象の入力レコードに対して行われることになる。
【００８８】
マッチング処理実行部４０５は、マッチングルールに定義されているその特定のキーワード（ふらつき）に対応する特定の項目に関しては、定義されているマッチングルールに従って、特定の階層の項目のみをカテゴリを跨って検索する。そして、一致した項目があれば、その項目に対応する重みを、その項目を含む原因レコードに累積されているスコアに加算する。例えば、ふらつきが生じる原因としては、身体的な原因、病気の症状、薬の影響等、様々な場合が考えられる。そこで、例えば「いつもと違った様子」のカテゴリにおいて、いつもと違った様子として「ふらつき」が含まれている場合、「事故時の行動」のカテゴリの「移動」の項目を検索し、「疾病・疾患・症状」のカテゴリの「症状」の項目を検索し、「薬物」のカテゴリの「副作用」の項目を検索する。この結果、例えば、「事故時の行動」の原因レコードに「ＡＤＬ（Activities of Daily Living）/筋力の低下」が原因として含まれる原因レコードのスコアが高くなったり、「疾病・疾患・症状」の原因レコードに「認知症の周辺症状」「脳血管疾患」が原因として含まれる原因レコードのスコアが高くなったり、「薬物」の原因レコードに「睡眠薬」「抗不安薬」「抗てんかん薬」が原因として含まれる原因レコードのスコアが高くなったりする。
【００８９】
このような処理によれば、原因の可能性となり得るものをなるべく広く拾い集めることができる。その上で、スコアが高いものを利用者に提示して、利用者に確認を促す処理を行う。このため、「ふらつき」等のように、多面的な原因が考えられる場合には、その原因の可能性となり得るものを含む原因レコードのスコアが加算されることになる。このため、利用者の経験等に応じて考慮から漏れてしまう事項を減らすことができる。つまり、利用者（スタッフ）が発生状況を入力した際に、その入力した情報からは直ちに気付くことができないような原因に関する原因レコードのスコアが高くなるので、利用者が気付くことができなかった原因に気付く可能性が高まる。また、縦マッチングは、比較的階層が下の層（詳細な項目を規定した層）も含む複数の階層に対して行うことができるので、前述したように、一致した場合の重み付けが重くなる。したがって、縦マッチングに一致する原因レコードのスコアは、縦マッチングに一致しない原因レコードのスコアよりも相対的に高くなるので、前述の例では「ふらつき」の原因に関連する原因レコードのスコアが高くなり、マッチング結果として選出される可能性が更に高まることになる。
【００９０】
［交差マッチング］
次に、「交差マッチング」について説明する。交差マッチングは、入力レコードの処理対象の項目が特定のカテゴリの特定の階層の項目の場合、その発生状況が選択された入力レコードを新たに入力レコード取得部４０２に取得させる。そして、新たに取得した入力レコードを用いて前述したマッチング処理を行う処理のことである。換言すれば、入力レコードの処理対象の項目が、ある特定のカテゴリの特定の階層の項目の場合、その項目に含まれているキーワードを用いて、異なるカテゴリの異なる階層の項目とマッチングをさせる処理である。交差マッチングの対象となる特定のカテゴリの特定の階層の項目とキーワード等についても、マッチングルール保持部４０３に予めマッチングルールが定義されているものとする。なお、その項目にキーワードが含まれていない場合は、処理を実行しない。
【００９１】
例えば、利用者が入力をしなかった項目（したがって、入力レコードの特定の項目にキーワードが含まれていない項目）についても、あたかも利用者が入力しているかのように扱い、間接的にマッチングが行われることになる。具体例を説明する。例えば、「疾病・疾患・症状」としてパーキンソン病が入力された場合を想定する。このとき利用者は、その入居者がパーキンソン病であることを知っているが、その人が使用する薬物を知らない場合がある。この場合、「薬物」のカテゴリでは、薬が選択されていない状態、つまり空欄になっている。交差マッチングを用いることで、このように空欄であっても、「薬物」に関する入力レコードを、パーキンソン病に関連する薬物の名前が含まれる入力レコードとして扱うことができる。具体的には、マッチングルール保持部４０３に定義されているマッチングルールに従ってそのパーキンソン病に関連する薬の名前を、「薬物」の入力レコードの対応する項目に含めた入力レコードを新たに入力レコード取得部４０２が取得し、処理対象の入力レコードとして処理が行われる。これにより、薬の名前が入力された状態で、「薬物」のカテゴリに関する横マッチングが実行されることになる。
【００９２】
このような処理によれば、原因の可能性となり得るものをなるべく広く拾い集めることができる。その上で、スコアが高いものを利用者に提示して、利用者に確認を促す処理を行う。このため、利用者の経験等に応じて考慮から漏れてしまう事項を減らすことができる。つまり、利用者（スタッフ）が発生状況を入力した際に、その入力した情報からは直ちに気付くことができないような原因に関する原因レコードのスコアが高くなるので、利用者が気付くことができなかった原因に気付く可能性が高まる。また、交差マッチングも縦マッチングと同様に、比較的階層が下の層（詳細な項目を規定した層）で行われるので、前述したように、一致した場合の重み付けが重くなる。したがって、交差マッチングに一致する原因レコードのスコアは、交差マッチングに一致しない原因レコードのスコアよりも相対的に高くなるので、マッチング結果として選出される可能性が高まることになる。
【００９３】
なお、交差マッチングを行うに際しては、その特定の階層の項目の重みについては、利用者が実際に入力した情報に基づいて取得された入力レコードの重みと比べて低く設定してもよい。実際に使用している「薬物」の名前が入力された場合の方が、実際にその入居者が服用している薬物であるという信頼性が高いからである。
【００９４】
このように、マッチング処理実行部４０５は、入力レコードそれぞれについて、マッチング方法決定部４０４で決定されたマッチング方法に従ってマッチング処理を行う。この結果、原因データベース４６０の原因レコードのそれぞれのスコアが求められる。マッチング結果出力部４０６は、スコアが所定の条件を満たす原因レコードを出力する。例えば、所定の閾値のスコアを超えている原因レコードを出力したり、所定数の原因レコードをスコアの上位順に出力したり、各カテゴリについて所定数の原因レコードをスコアの上位順に出力したり、設定された件数分出力したり、設定されたスコアに達しない場合には出力させなかったりすることができる。出力部３１７は、例えばマッチング結果出力部４０６が出力した原因レコードに含まれる第二の部分１００２、１０５２の内容、すなわち、「押えるべき観点や原因の候補」といったような、事故発生の各種の要因等を示す情報をユーザ端末２２０に送信する。
【００９５】
なお、マッチングルール保持部４０３で保持されるルールは、検索を行う上で、次項目がない場合に、検索を終了するのか、あるいは検索を継続するのか、所定の範囲に限定して検索するのか、ひとつ飛ばして検索を続けるか等を規定したルールを含んでもよい。また、検索を実行する際に、全文一致か、部分一致かを、項目に応じて設定したルールを含んでもよい。また、重み係数をカテゴリに応じて変えるルールを含んでいてもよい。また、マッチングルールは、例えばインターネット上に公開されている他の情報等を参照するルールでもよい。例えばパーキンソン病とキーワードが入力されている場合に、ウェブ等を検索して、対応する治療薬や新薬の情報を取得し、その情報を用いて交差マッチングを実行させてもよい。
【００９６】
図１３は、ユーザ端末１２０の表示部３２３に表示されるマッチング結果画面１３００の一例を示す図である。ここでは、スコアの上位順に押えるべき観点・原因の情報が並んで表示されている。利用者は、マッチング結果画面１３００を確認し、尤もな事項をチェックボックス１３１０でチェックする。そして、ＯＫボタン１３２０の選択指示が入力部３２０で入力されると、チェックされた内容が通信部３２１を通じてサービス支援システム２１０に送信される。サービス支援システム２１０では、チェックされた内容を押さえるべき観点や原因の事項として確定する。そして、記憶制御部３１２は記憶部３１３に確定した押さえるべき観点や原因のデータを記憶する。このように記憶された押さえるべき観点や原因のデータは、事故報告書の作成を行う際に記憶制御部３１２によって読み出されて、自動的に設定されることになる。
【００９７】
図１４は、最終的に得られた押えるべき観点や原因を表す、観点や原因の検索画面１４００の例を示している。観点や原因の検索結果画面１４００は、ユーザ端末２２０の表示部３２３にて表示される。
【００９８】
［ユーザ端末のフローチャート］
図１５は、ユーザ端末２２０の制御方法の一例を示すフローチャートである。
【００９９】
ステップＳ１５０５において表示制御部３２４は、入力部３２０に入力された指示に従って、事故報告書の作成画面５００を表示部３２３に表示させる。ユーザ端末２２０の利用者は、作成画面５００に従って各種の値及び情報等を入力することになる。
【０１００】
ステップＳ１５１０において通信部３２１は、入力部３２０に入力された情報をサービス支援システム２１０に送信する。その後、サービス支援システム２１０においてマッチング処理が実行される。
【０１０１】
ステップＳ１５１５において表示制御部３２４は、サービス支援システム２１０から送信された情報に基づいて、マッチング結果画面１３００を表示部３２３に表示させる。ユーザ端末２２０の利用者は、マッチング結果画面１３００に表示されている内容を確認し、適当と思われる事項を選択する。
【０１０２】
ステップＳ１５２０において通信部３２１は、入力部３２０に入力された選択指示に基づいて、選択された事項をサービス支援システム２１０に送信する。
【０１０３】
ステップＳ１５２５において表示制御部３２４は、サービス支援システム２１０から送信された情報に基づいて観点や原因の検索結果画面１４００を表示する。
【０１０４】
［サービス支援システム２１０のフローチャート］
図１６は、サービス支援システム２１０におけるサービス支援方法の一例を示すフローチャートである。
【０１０５】
ステップＳ１６０５において受付部３１４は、通信部３１１を通じてユーザ端末２２０から送信された情報を受け付ける。
【０１０６】
ステップＳ１６１０においてマッチング部３１６は、マッチング処理を実行する。マッチング処理の流れについては後述する。
【０１０７】
ステップＳ１６１５において出力部３１７は、通信部３１１を通じてユーザ端末２２０にマッチング結果を送信する。
【０１０８】
ステップＳ１６２０において受付部３１４は、ユーザ端末２２０において選択された事項を通信部３１１を通じて受け付ける。
【０１０９】
ステップＳ１６２５において記憶制御部３１２は、ステップＳ１６２０において受け付けた事項のデータを記憶部３１３に書き込む。
【０１１０】
ステップＳ１６３０において出力部３１７は、ステップＳ１６２０において受け付けた事項に基づいて、通信部３１１を通じてユーザ端末２２０に観点や原因の検索結果の情報を送信する。
【０１１１】
図１７は、ステップＳ１６１０のマッチング処理の詳細な処理の一例を示すフローチャートである。
【０１１２】
ステップＳ１７０５においてキーワード抽出部４０１は、例えば事故報告書の作成画面５００でユーザが入力した情報に基づいて、選択された項目に対するキーワードを抽出する。
【０１１３】
ステップ１７１０において入力レコード取得部４０２は、ステップＳ１７０５で抽出されたキーワードに対応する発生状況レコードを入力レコードとして発生状況データベース４５０から取得する。このとき、事故の種別毎に応じたデータベースを用いて入力レコードを取得する。入力レコードは、カテゴリごとに取得される。また、各カテゴリにおいて複数の入力レコードが取得されてよい。
【０１１４】
ステップＳ１７１５においてマッチング方法決定部４０４は、マッチングルール保持部４０３に保持されているマッチングルールを参照して、ステップＳ１７１０において取得された各入力レコードに適用されるマッチングルールを決定する。例えば、「横マッチング」のみの他、「縦マッチング」及び「交差マッチング」等のような各種のマッチングルールを決定することができる。
【０１１５】
ステップＳ１７２０において、マッチング処理実行部４０５は、ステップＳ１６１０で取得された各入力レコードを用いて、ステップＳ１６１５で決定されたマッチングルールに従って、原因データベース４６０に格納されている各原因レコードに対してマッチング処理を行う。このとき、事故の種別に応じたデータベースに格納されている原因レコードに対してマッチング処理が行われる。マッチング処理実行部４０５は、各原因レコードに累積されているスコアをマッチングの結果に応じて加算する。
【０１１６】
ステップＳ１７２５においてマッチング結果出力部４０６は、ステップＳ１７２０で得られたスコアに基づいてマッチング結果を特定する。例えば、所定の閾値を超えている原因レコードをマッチング結果の候補として決定する。
【０１１７】
ステップＳ１７３０においてマッチング結果出力部４０６は、ステップＳ１７２５で特定したマッチング結果を出力部３１７に出力する。
【０１１８】
図１８は、ステップＳ１７２０の詳細な処理の一例を示すフローチャートである。
【０１１９】
ステップＳ１８０５においてマッチング処理実行部４０５は、処理対象の入力レコード内の未処理の項目を選択する。処理対象の入力レコードの最上位の階層の項目から下位の階層の項目に向けて、項目毎に処理が行われることになる。
【０１２０】
ステップＳ１８１０においてマッチング処理実行部４０５は、ステップＳ１８０５において次の階層の項目が選択できたのか否かを判定する。次の項目が選択できた場合、ステップＳ１８１５に進み、そうでない場合、ステップＳ１８３５に進む。
【０１２１】
ステップＳ１８１５においてマッチング処理実行部４０５は、処理対象の項目が、所定のルールに合致する項目であるかを判定する。例えば、縦マッチングや交差マッチングの対象の項目であるかを判定する。所定のルールに合致する項目である場合、ステップＳ１８２０に進み、ステップＳ１８２０においてマッチング処理実行部４０５は、所定のルールに従った処理を実行する。そうでない場合、ステップＳ１８２５に進む。
【０１２２】
ステップＳ１８２５においてマッチング処理実行部４０５は、処理対象の項目が原因レコードの対応する項目のキーワードと一致するかを判定する。すなわち、前述したような横マッチングが行われる。一致する場合、ステップＳ１８３０に進む。そうでない場合、ステップＳ１８３２に進む。
【０１２３】
ステップＳ１８３０においてマッチング処理実行部４０５は、処理対象の項目の重みに応じたスコアを、処理対象の原因レコードのスコアに加算する。そして、ステップＳ１８３２に進む。
【０１２４】
Ｓ１８３２においてマッチング処理実行部４０５は、次の項目に進むかを判定する。例えば、マッチング結果が不一致であった場合には次の項目に進みたくない場合や、処理対象の原因レコードの構造が、途中の階層までしか項目が存在しない場合がある。このような場合において、現在処理中の項目がＬｖ３の項目である場合、ステップＳ１８３２では次の項目に進むことなく、ステップＳ１８３５に処理を進める。そうでない場合、ステップＳ１８０５に処理が戻る。このようにして、処理対象の入力レコード内の各項目と、処理対象の原因レコード内の各項目との間でマッチング処理が行われる。
【０１２５】
ステップＳ１８１０において次の項目が選択できないと判定された場合は、ステップＳ１８３５に進む。
【０１２６】
ステップＳ１８３５においてマッチング処理実行部４０５は、次の処理対象の原因レコードがあるかを判定する。次の原因レコードがある場合、ステップＳ１８４０に進む。そうでない場合、全ての原因レコードに対する処理が完了したので、本処理を終了する。
【０１２７】
ステップＳ１８４０においてマッチング処理実行部４０５は、処理対象の原因レコードを更新する。
【０１２８】
ステップＳ１８４５においてマッチング処理実行部４０５は、入力レコード内の処理済みの項目の情報をクリアにする。すなわち、入力レコードの各項目が未処理の項目である状態に変更する。そしてステップＳ１８０５に戻る。これにより、ステップＳ１８４０で更新された処理対象の原因レコードに対して、最上位の項目同士の横マッチングが再度ステップＳ１８０５から行われることになる。
【０１２９】
図１９は、ステップＳ１８２０の詳細な処理の一例を示すフローチャートである。
【０１３０】
ステップＳ１９０５においてマッチング処理実行部４０５は、処理対象の項目が縦マッチングの対象であるかを判定する。縦マッチングの対象である場合、ステップＳ１９１０に進む。そうでない場合、ステップＳ１９３５に進む。
【０１３１】
ステップＳ１９１０においてマッチング処理実行部４０５は、マッチングルールに規定されている特定の階層の項目の検索を実行する。
【０１３２】
ステップＳ１９１５においてマッチング処理実行部４０５は、原因レコードの特定の階層の項目のキーワードと一致するかを判定する。一致する場合、ステップＳ１９２０に進み、入力レコードの処理対象の項目の重みに応じたスコアを、その一致した原因レコードに累積されているスコアに加算する。そして、ステップＳ１９２５に進む。
【０１３３】
ステップＳ１９２５においてマッチング処理実行部４０５は、処理対象の原因レコードは、処理対象の最後の原因レコードであるかを判定する。すなわち、列方向の最終行であるかを判定する。最終行である場合、ステップＳ１９３５に進む。そうでない場合、ステップＳ１９３０に進み、処理対象の原因レコードを更新し、ステップＳ１９１０に処理を戻す。
【０１３４】
ステップＳ１９３５においてマッチング処理実行部４０５は、入力レコードの処理対象の項目が交差マッチングの対象であるかを判定する。交差マッチングの対象である場合、ステップＳ１９４０に進み、そうでない場合には本処理を終了する。
【０１３５】
ステップＳ１９４０においてマッチング処理実行部４０５は、マッチングルールに規定されている対象項目にマッチングルールに規定されている特定のキーワードが入力された状態の入力レコードを未処理の入力レコードとして追加する。これにより、特定のキーワードが入力された状態の入力データを用いた横マッチングが行われることになる。以上がフローチャートの説明である。
【０１３６】
これまでは、転倒事故の場合を例に挙げて説明した。以下では、転倒事故の他に、介護施設で発生し得る事故と、その要因の具体例を説明する。転倒事故の他に、介護施設において発生する事故として、誤嚥・窒息事故（以下、「誤嚥事故」という。）が挙げられる。誤嚥事故においては、事故時の食事の内容や、食事場所や、スタッフの介助方法や、スタッフの関わり方といった外的要因の他に、入居者の食事の仕方や、身体・生理的要因や、疾病・疾患・症状や、服用している薬物等の入居者本人に関する様々な内的要因が誤嚥事故の要因として挙げられる。誤嚥事故においては、原因食品の食形態や、トロミ剤の使用の有無や、食事時間や、食事場所や、使用用具や、義歯等の外的要因を詳細に分類する。また、スタッフの介助方法や関与の仕方についても、厨房との連携も含めて、食前、食事中、食後にどういった対応をしていたかを詳細に分類する。入居者本人については、食事摂取能力や、食事時の姿勢や、食事動作や、栄養状態や、食欲・意欲や、口腔ケアの状況や、環境変化や、いつもと違う様子や、疾病・疾患・症状や、服用している薬物に至るまで、内的要因を詳細に分類する。このように事故の発生状況をより詳細化することで、それに関連する原因や押さえておくべき観点を的確にマッチングできる。具体例としては、認知症を患っている入居者の場合、「食べ物を認識できているか、味や温度のはっきりしたものの方が食がすすむか」「他の入居者の食事に手を出してしまったり、異食行為がないか、何でも混ぜて食べてしまわないか」といった観点、また、パーキンソン病を患っている入居者の場合、「手の震えで取りこぼしがないか」といった観点がマッチング結果画面１３００にリストアップされることになる。
【０１３７】
また、介護施設において発生する別の事故として、薬事故がある。薬事故においては、医師の処方や、調剤薬局での調剤と受け渡しや、介護施設の看護職員による薬剤管理や、看護職員又は介護職員による服薬介助等のように、入居者が薬剤を服用する迄の一連の作業の流れが薬事故発生の原因になる。そこで、調剤薬局の要因や、看護職員の要因や、介護スタッフの要因などの外的要因に分類することができる。また、各々分類毎に更に詳細化することができる。薬事故の原因や押さえておくべき観点としては、例えば、調剤薬局のミスを、「調剤誤り」「梱包誤り」「印字誤り」「疑義照会の行き違い」等に詳細化することができる。看護職員のミスを、例えば「受領誤り」「未処方の薬をセット」「人を間違えてセット」「計数・計量を誤ってセット」「服用タイミングを誤ってセット」「処方日数を誤ってセット」「服用方法を誤ってセット」「渡し忘れ」等に詳細化することができる。介護スタッフのミスを、例えば「違う薬を服用させてしまった」「人を間違えて服用させてしまった」「服用タイミングを間違えて服用させてしまった」「計数・計量を間違えて服用させてしまった」「服用方法を間違えて服用させてしまった」「服用できていなかった」等に詳細化することができる。発生のケース毎に対象となる原因や押さえておくべき観点がマッチング結果画面１３００にリストアップされることになる。
【０１３８】
これまで説明した実施形態では、施設で起こり得る事故を例に挙げて説明したが、これに限られるものではなく、様々な事案に適用することができる。事案の例として、事故及びヒヤリハットを含むインシデントに対しても適用することができる。つまり、事故報告書を作成する場面だけではなく、日常の業務においてヒヤリハットが生じた場合にその報告書等を作成する場面においても適用可能である。また、事故以外の他業務の事案での応用も可能である。例えば、ケアプランがあげられる。入居者個々のアセスメント結果に基づき、最適なケアプラン候補を導出するといった形態である。この応用例の実現方法としては、各アセスメント項目を分類分け、体系化（構造化、階層化）してデータベース化する。合わせて、ケアプランの事例を分類分け、体系化（構造化、階層化）してデータベース化する。各アセスメント項目に対するケアプラン事例以外に、分類を跨るケースも想定されるため、前述の転倒事故のように、任意のマッチングルールを保持して縦マッチングや交差マッチング等を行うこともできる。アセスメントとケアプラン双方の分類例として、「食事・水分」「口腔ケア」「入浴」「整容」「排泄」「移動・移乗・身体機能」「睡眠」「趣味・活動」「記憶・認知」「精神・行動」「健康管理・医療的ケア」「その他生活」等、様々な生活の場面や入居者の能力や意欲、特性等が挙げられる。このような分類に基づいて入居者のアセスメントから最適なケアプランを立案することで、個々の入居者の能力や意欲、特性等を総合的に考慮・判断した具体的かつ適切な生活の支援を行うことができる。
【０１３９】
また、事案としては、問題が生じた、あるいは問題が生じ得る案件ではなく、改善が生じた、あるいは改善が生じ得る案件でもよい。例えば、介護施設において、所定の出来事（例えば、花を飾った、散歩のルートを変更した、いつもと違う声掛けをした等）があった場合に、何かしらの改善（例えば、入居者の機嫌が良くなった、歌を口ずさむようになった、いつもよりおしゃべりが増えた等）が生じる場合がある。このように、問題が生じた、あるいは問題が生じ得る案件ではなく、改善が生じた、あるいは改善が生じ得る事案についても、前述の実施形態で説明した構成及び処理を適用することができる。
【０１４０】
また、これまでは主に介護施設で用いられる形態を例に挙げて説明したが、これに限られるものではない。例えば、医療提供施設においても、同種の事故等の事案が生じ得るものであり、医療提供施設においても前述したサービス支援システム２１０が用いられてもよい。また、サービス被提供者は、老齢者や患者である必要はなく、例えば子どもなどをサービス被提供者とする保育園や学童クラブなどに適用してもよい。また、学校、職場などの様々な場面で起こり得る事案についても前述した実施形態で説明したサービス支援システム２１０を適用することができる。
【０１４１】
前述の各種データの体系化、構造化、階層化について、データにタグ付けして意味付けすることもできる。合わせて各種ルールにおいては人工知能機能を搭載したシステムで実装し、さらに限定したデータベースをマッチング対象にするのではなく、インターネット上の多くのウェブ等を情報源とすることで、マッチング処理の多様性と高速化を実現させることもできる。例えば、マッチング結果画面１３００に表示した情報と、そのマッチング結果画面１３００を通じてユーザが選択した事項の情報とに基づいてマッチングルール保持部４０３で保持されているマッチングルールを適応的に変えてもよい。例えば、マッチング結果画面１３００に表示した情報とそのマッチング結果画面１３００を通じてユーザが選択した事項の情報とを複数集めておき、これを用いて重み係数を最適化してもよい。また、マッチング結果画面１３００を通じてユーザが選択した事項の情報に基づいてデータベースを再構築してもよい。例えば、マッチング結果画面１３００でユーザ端末２２０に表示した内容と、そのマッチング結果画面１３００を通じてユーザが選択した事項とを教師データとして用いて学習モデルを構築してもよい。そして、マッチング部としてその構築した学習モデルを用いて、マッチング結果を出力する構成を採用してもよい。学習モデルは、サービス被提供者の個々に応じて構築してもよいし、特定の条件でグループ分けを行い、グループ毎に学習モデルを構築してもよい。
【０１４２】
［変形例］
また、これまで説明した例においては、ユーザが図５に示すような事故報告書を通じて入力を行うことでマッチング処理が行われる形態を例に挙げて説明したが、これに限られるものではない。例えば、所定のタイミングでサービス支援システム２１０がデータを自動的に取り込み、この取り込んだデータに基づいてマッチング処理を行ってもよい。このような処理によれば、例えば体調変化等によってインシデント等が生じる場合に警告を出力することも可能である。
【０１４３】
介護施設の入居者を例に挙げて説明する。介護施設の現場においては、スタッフは、入居者の状態変化や危険に対して常にアンテナを張り、適切な対応をすることが求められる。しかしながら、スタッフが交代制で日々のケアサービスを提供している日常時には入居者の状態変化や危険に気付かないことが多い。なぜならば、ある１点だけを取り出せは異常な状態であるとは直ちに特定することができない場合があるからである。例えば、食事の摂取量や水分摂取量が所定の回数継続して一定量以下である場合や、排泄が一定時間無かった場合や、体温、脈拍、血圧、体重等のバイタルが一定の期間、規定の範囲を外れた値になる場合等のように、継続して平時とは異なる状態が続いた場合には、入居者の状態変化や危険が生じる可能性がある。前述した実施形態は、このような注意喚起の形態にも適用することができる。
【０１４４】
事案の種別が、体重変化の場合を例に挙げて説明する。入居者の体重等のデータは、記憶部３１３等に蓄積されている。そこで、受付部３１４は、この記憶部３１３等に蓄積されたデータに所定のタイミングでアクセスして、蓄積されたデータを発生状況として入力することができる。そして、入力されたデータをマッチング部３１６に送る。このように、所定のタイミングで自動的にマッチング処理が行われてもよい。
【０１４５】
原因データベース４６０は、時系列の推移に関する項目のレコードを含むことができる。例えば所定の基準日をＬｖ１の階層の値（体重）とした場合、Ｌｖ２の階層の値は、基準日の次の日の許容値（体重）とする原因レコードを格納してもよい。そして、マッチング部３１６は、蓄積された体重のデータを時系列の項目として配置した入力レコードを用いてマッチング処理を行う。この処理の例では、Ｌｖ２以降の階層において、原因レコードの項目（許容値（体重））に一致しない場合に、スコアを増やす手法を用いることができる。つまり、Ｌｖ２以降の階層の入力レコードの項目が、Ｌｖ２以降の階層の原因レコードの項目と一致した場合（つまり、許容範囲内の値の場合）には、マッチング処理を終了し、一致しない場合（つまり、許容範囲でない値の場合）にはスコアが加算される方式を用いてよい。このような処理を行うと、体調変化に注意すべき値が項目に含まれる原因レコード（例えば、体重が日々低下していることに対応する原因レコード）のスコアが高くなり、その原因レコードに関連付けられた原因（例えば病気の可能性があるので注意等）がマッチング部３１６から出力される。出力部３１７は、このようにマッチング部３１６から出力されたマッチング結果をユーザ端末２２０に送信して、ユーザに警告を促すことも可能である。
【０１４６】
以上説明したように、本実施形態によれば、施設で起こる様々な事故の発生状況を基に、事故が引き起こされた原因や押さえるべき観点の候補を導出して、事故の分析、対応・予防策立案を支援することができる。また、発生状況データベース４５０及び原因データベース４６０のレコードは、容易に追加、変更することができる。従って、新たな項目等を設定する必要がある場合等のメンテナンスが容易となる。
【０１４７】
また、本実施形態によれば、高度な専門的知識や経験値が少ないスタッフでも、発生した事故の状況を忠実かつ正確に選択肢から選択するだけで、一定レベル以上の精度と網羅性が担保された、事故の原因や押さえておくべき観点の候補がリストアップされて表示されることが可能となる。このため、各種専門書等資料の調査にかける時間を削減できると共に、リストアップされた内容を基に関係各所との連携が効率的に実施できる。
【０１４８】
また、本実施形態によれば、施設のスタッフが気付いていないような真の原因等が見過ごされてしまうことを防止することができる。また、スタッフ等の利用者に、事故の発生状況に応じた原因、要因、危険因子及び留意事項等を多面的な観点で提示することができる。
【０１４９】
以上説明した実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。実施形態が備える各要素並びにその配置、材料、条件、形状及びサイズ等は、例示したものに限定されるわけではなく適宜変更することができる。また、異なる実施形態で示した構成同士を部分的に置換し又は組み合わせることが可能である。
【０１５０】
以上説明した本発明の各実施形態を実現するためのプログラムは、記憶媒体に記憶させてもよい。この記憶媒体を用いれば、施設における他用途で既に使用している任意のコンピュータや新たに購入するコンピュータに、上記プログラムをインストールすることができる。ここで、上記プログラムを記憶した記憶媒体は、非一過性の記憶媒体であっても良い。非一過性の記憶媒体は特に限定されないが、例えば、ＣＤ−ＲＯＭ等の記憶媒体であっても良い。
【符号の説明】
【０１５１】
２１０…サービス支援システム、２２０、２２０ａ、２２０ｂ…ユーザ端末、３１１…通信部、３１２…記憶制御部、３１３…記憶部、３１４…受付部、３１５…データベース、３１６…マッチング部、３１７…出力部、３２０…入力部、３２１…通信部、３２３…表示部、３２４…表示制御部、３２５…記憶部、３２６…記憶制御部、４０１…キーワード抽出部、４０２…入力レコード取得部、４０３…マッチングルール保持部、４０４…マッチング方法決定部、４０５…マッチング処理実行部、４０６…マッチング結果出力部、４５０…発生状況データベース、４５１…転倒事故発生状況データベース、４５２…誤嚥・窒息事故発生状況データベース、４５３…薬事故発生状況データベース、４６０…原因データベース、４６１…転倒事故原因データベース、４６２…誤嚥・窒息事故原因データベース、４６３…薬事故原因データベース。
【図１】
2018081632.tif 000003
【図２】
2018081632.tif 000004
【図３】
2018081632.tif 000005
【図４】
2018081632.tif 000006
【図５】
2018081632.tif 000007
【図６】
2018081632.tif 000008
【図７】
2018081632.tif 000009
【図８】
2018081632.tif 000010
【図９】
2018081632.tif 000011
【図１０】
2018081632.tif 000012
【図１１】
2018081632.tif 000013
【図１２】
2018081632.tif 000014
【図１３】
2018081632.tif 000015
【図１４】
2018081632.tif 000016
【図１５】
2018081632.tif 000017
【図１６】
2018081632.tif 000018
【図１７】
2018081632.tif 000019
【図１８】
2018081632.tif 000020
【図１９】
2018081632.tif 000021