(57)【特許請求の範囲】
【請求項１】
医療又は介護に関する情報を受け付け、
医療又は介護に関する情報と、前記医療又は前記介護に関する事故に繋がる可能性のあるインシデント情報と、前記インシデント情報に対応する対策を示す対策情報とを対応付けて記憶した記憶部を参照して、受け付けた前記医療又は前記介護に関する情報との類似度が所定値以上となる医療又は介護に関する情報を前記記憶部から抽出し、
抽出した前記医療又は前記介護に関する情報のインシデント情報に対応する対策情報が登録されている場合に、前記対策情報を改善が必要な対策情報として表示する、
処理をコンピュータに実行させる医療介護支援プログラム。
【請求項２】
前記表示する処理では、前記改善が必要な対策情報の数に応じた表示を行うことを特徴とする請求項１に記載の医療介護支援プログラム。
【請求項３】
前記インシデント情報である可能性を判断するための基準に基づいて、受け付けた前記医療又は前記介護に関する情報が前記インシデント情報である可能性を判断し、
前記インシデント情報である可能性に基づいて又はユーザの入力に基づいて、受け付けた前記医療又は前記介護に関する情報を前記記憶部に記憶する、処理を前記コンピュータに更に実行させる請求項１又は２に記載の医療介護支援プログラム。
【請求項４】
前記表示する処理では、表示する対策情報が前記記憶部に記憶された時期に応じた通知を行うことを特徴とする請求項１に記載の医療介護支援プログラム。
【請求項５】
医療又は介護に関する情報を受け付け、医療又は介護に関する情報と、前記医療又は前記介護に関する事故に繋がる可能性のあるインシデント情報と、前記インシデント情報に対応する対策を示す対策情報とを対応付けて記憶した記憶部を参照して、受け付けた前記医療又は前記介護に関する情報との類似度が所定値以上となる医療又は介護に関する情報を前記記憶部から抽出する処理部と、
抽出した前記医療又は前記介護に関する情報のインシデント情報に対応する対策情報が登録されている場合に、前記対策情報を改善が必要な対策情報として表示する通知部と、
を備える医療介護支援装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本件は、医療介護支援プログラム及び医療介護支援装置に関する。
【背景技術】
【０００２】
事故等のアクシデントには至らないものの、危険性の可能性が多少なりともあった出来事を収集、管理することで、未然にアクシデントの発生を防ぐことができる。このような出来事は、「ヒヤリ」としたり、「ハッ」としたりすることに由来して、いわゆる「ヒヤリハット」事例とも呼ばれている。
【０００３】
医療や介護のシステム（以下、単に、介護システムと呼ぶ）では、職員により日々の行動が記入されたケース記録が作成される。ケース記録の中には、ヒヤリハット事例が含まれている場合がある。しかし、職員には、ヒヤリハット事例の記録が義務付けられていないことが多いため、ヒヤリハットの事例が集まらない場合が多い。そこで、ケース記録に含まれるキーワードなどからヒヤリハット事例か否かを判別してヒヤリハット事例を収集する技術がある（例えば、特許文献１参照）。
【０００４】
また、ヒヤリハット事例に関しては、対処手段を検討し、検討結果を現場に周知することにより対策が行われる。なお、提出されたヒヤリハット事例について、対策やフォローを確実に実行させる方法が知られている（例えば、特許文献２参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１１−２１０１８７号公報
【特許文献２】特開２００４−２８０３１３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ヒヤリハット事例に対する対策がなされた場合でも、同様のヒヤリハット事例が発生する場合がある。この場合、対策が誤っていると考えられるため、対策を再考しなければ将来の事故の発生を防止できないおそれがある。
【０００７】
しかしながら、特許文献１、２の技術では、このような対策の改善が必要なヒヤリハット事例が発生したか否かを判別し、システムの利用者に通知するなどすることができない。
【０００８】
そこで本件は上記の課題に鑑みてなされたものであり、対策情報の改善が必要なインシデント情報を自動的に特定することが可能な医療介護支援プログラム及び医療介護支援装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本明細書に記載の医療介護支援プログラムは、医療又は介護に関する情報を受け付け、医療又は介護に関する情報と、前記医療又は前記介護に関する事故に繋がる可能性のあるインシデント情報と、前記インシデント情報に対応する対策を示す対策情報とを対応付けて記憶した記憶部を参照して、受け付けた前記医療又は前記介護に関する情報との類似度が所定値以上となる医療又は介護に関する情報を前記記憶部から抽出し、抽出した前記医療又は前記介護に関する情報のインシデント情報に対応する対策情報が登録されている場合に、前記対策情報を改善が必要な対策情報として表示する、処理をコンピュータに実行させる医療介護支援プログラムである。
【００１０】
本明細書に記載の医療介護支援装置は、医療又は介護に関する情報を受け付け、医療又は介護に関する情報と、前記医療又は前記介護に関する事故に繋がる可能性のあるインシデント情報と、前記インシデント情報に対応する対策を示す対策情報とを対応付けて記憶した記憶部を参照して、受け付けた前記医療又は前記介護に関する情報との類似度が所定値以上となる医療又は介護に関する情報を前記記憶部から抽出する処理部と、抽出した前記医療又は前記介護に関する情報のインシデント情報に対応する対策情報が登録されている場合に、前記対策情報を改善が必要な対策情報として表示する通知部と、を備えている。
【発明の効果】
【００１１】
本明細書に記載の医療介護支援プログラム及び医療介護支援装置は、対策情報の改善が必要なインシデント情報を自動的に特定することができるという効果を奏する。
【図面の簡単な説明】
【００１２】
【図１】一実施形態に係る医療介護支援システムの構成を概略的に示す図である。
【図２】図２（ａ）は、サーバのハードウェア構成を示す図であり、図２（ｂ）は、管理者端末及び介護担当者端末のハードウェア構成を示す図である。
【図３】サーバの機能ブロック図である。
【図４】ケース記録画面の一例を示す図である。
【図５】ケース記録ＤＢの一例を示す図である。
【図６】ヒヤリハット選定マスタの一例を示す図である。
【図７】ヒヤリハット管理ＤＢの一例を示す図である。
【図８】是正通知マスタの一例を示す図である。
【図９】対策ＤＢの一例を示す図である。
【図１０】ヒヤリハット編集画面の一例を示す図である。
【図１１】対策登録画面の一例を示す図である。
【図１２】登録処理を示すフローチャートである。
【図１３】ヒヤリハット可能性ありリストを示す図である。
【図１４】再発通知リスト登録処理を示すフローチャートである。
【図１５】再発通知リストを示す図である。
【図１６】ヒヤリハット事例追加登録処理を示すフローチャートである。
【図１７】ヒヤリハット事例の内容補充処理を示すフローチャートである。
【図１８】対策ＤＢへの登録処理を示すフローチャートである。
【図１９】変形例に係る再発通知リスト登録処理を示すフローチャートである。
【発明を実施するための形態】
【００１３】
以下、医療介護支援システムの一実施形態について、図１〜図１８に基づいて詳細に説明する。図１には、本実施形態に係る医療介護支援システム１００の構成が概略的に示されている。
【００１４】
医療介護支援システム１００は、例えば介護施設で利用されるシステムであり、図１に示すように、医療介護支援装置としてのサーバ１０と、管理者端末６０と、介護担当者端末７０と、を備える。サーバ１０と、管理者端末６０と、介護担当者端末７０とは、インターネットやＬＡＮ（Local Area Network）などのネットワークに接続されている。
【００１５】
サーバ１０は、介護施設内又は介護施設外に設置されるサーバであり、介護に関する様々な処理を行う。一例として、サーバ１０は、介護担当者が介護担当者端末７０から入力するケース記録（日々の介護事例の記録）や、ケース記録から抽出されたヒヤリハット事例、及び品質管理者が管理者端末６０から入力するヒヤリハット事例に対する対策情報などの各種データを保持する。また、サーバ１０は、入力されたケース記録に基づいて、所定の処理を行い、処理結果を管理者端末６０や介護担当者端末７０に対して送信する。なお、ヒヤリハット事例とは、介護に関する事故に繋がる可能性のあるインシデント情報（事例）を意味する。
【００１６】
ここで、サーバ１０は、図２（ａ）に示すようなハードウェア構成を有している。図２（ａ）に示すように、サーバ１０は、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７及び可搬型記憶媒体用ドライブ９９等を備えており、サーバ１０の構成各部は、バス９８に接続されている。サーバ１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（医療介護支援プログラム）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（医療介護支援プログラム）をＣＰＵ９０が実行することにより、図３の各部の機能が実現される。
【００１７】
管理者端末６０は、介護施設の品質管理者が使用する端末であり、サーバ１０に格納されている各種データを閲覧したり、ヒヤリハット事例に対する対策のデータを入力したりするのに用いられる端末である。介護担当者端末７０は、実際に介護を行う人（介護担当者）が使用する端末であり、日々の介護における事例をケース記録として記録するためやヒヤリハット事例に関する入力を行うためなどに用いられる端末である。
【００１８】
ここで、管理者端末６０と、介護担当者端末７０とは、図２（ｂ）に示すようなハードウェア構成を有している。図２（ｂ）に示すように、管理者端末６０及び介護担当者端末７０は、ＣＰＵ１９０、ＲＯＭ１９２、ＲＡＭ１９４、記憶部（ここではＨＤＤ）１９６、ネットワークインタフェース１９７、表示部１９３、入力部１９５、及び可搬型記憶媒体用ドライブ１９９等を備えており、端末６０及び７０の構成各部は、バス１９８に接続されている。なお、表示部１９３は、液晶ディスプレイ等を含み、入力部１９５は、キーボードやマウス等を含んでいる。      
【００１９】
図３には、サーバ１０の機能ブロック図が示されている。図３に示すように、サーバ１０は、ＣＰＵ９０がプログラムを実行することで、ケース記録処理部１２、判断部及び格納処理部としてのヒヤリハット抽出部１４、算出部及び特定部としての再発判断部１６、及び通知部としての医療介護情報格納登録部１８の機能を実現する。なお、図３では、ＨＤＤ９６等に格納されている各種ＤＢやマスタも図示されている。
【００２０】
ケース記録処理部１２は、介護担当者端末７０の表示部１９３上に、例えば、図４に示すようなケース記録画面を表する。また、ケース記録処理部１２は、当該画面上で、介護担当者端末７０の入力部１９５を介した介護担当者からのデータ（事例）入力があった場合に、当該入力されたデータ（事例）を医療介護情報格納部としてのケース記録ＤＢ２０に格納する。
【００２１】
ここで、図４のケース記録画面は、利用者（介護を受ける側の人）ごとに生成される画面であり、時刻毎の実施内容、身体状態及び日常生活動作状況、報告者ＩＤを入力できる画面である。このケース記録画面には、更新ボタン、取り消しボタン、削除ボタンが設けられており、介護担当者が更新ボタンを押したタイミングで、ケース記録処理部１２は、更新された内容（新たに入力された事例）をケース記録ＤＢ２０に格納する処理を実行する。
【００２２】
ケース記録ＤＢ２０は、図５に示すようなデータ構造を有している。具体的には、ケース記録ＤＢ２０は、図５に示すように、「日付」、「時刻」、「実施内容」、「身体状態及び日常生活動作状況」、「報告者ＩＤ」、「利用者ＩＤ」、の各フィールドを有している。これら各フィールドには、図４のケース記録画面上で入力されたデータ（事例）等が格納される。
【００２３】
図３に戻り、ヒヤリハット抽出部１４は、ヒヤリハット事例である可能性を判断するための基準を格納したヒヤリハット選定マスタ３０を用いて、ケース記録ＤＢ２０に格納された事例のヒヤリハット基準点を算出する。ここで、ヒヤリハット基準点とは、ケース記録ＤＢ２０に格納された事例がヒヤリハット事例である可能性が高いか低いかを判断するための指標を意味する。また、ヒヤリハット抽出部１４は、算出されたヒヤリハット基準点に基づいて、ケース記録ＤＢ２０に格納された事例が、インシデント情報格納部としてのヒヤリハット管理ＤＢ２２に自動的に追加すべき事例であるか、追加候補の事例であるかなどを判断する。そして、ヒヤリハット抽出部１４は、自動的に追加すべき事例をヒヤリハット管理ＤＢ２２に追加するとともに、追加候補の事例を後述する「ヒヤリハット可能性ありリスト」（図１３参照）に登録する。なお、ヒヤリハット抽出部１４は、ヒヤリハット可能性ありリストを登録部１８に対して送信する。
【００２４】
ここで、ヒヤリハット選定マスタ３０は、図６に示すように、ヒヤリハット基準点を定めるマスタと、キーワード、場所、時間帯、問題のある利用者、問題のある職員に関するポイントの加算基準を定めるマスタとを有する。なお、図６の各マスタを使用するか否かは、例えば品質管理者が定めることができるものとする。図６の例では、時間帯のマスタの右上に「対象：□」と記載されているので、当該マスタは使用しないと定められているものとする。一方、その他のマスタについては、各マスタの右上に「対象：■」と記載されているので、当該マスタは使用すると定められているものとする。また、ヒヤリハット選定マスタ３０に含まれる各マスタの内容も、例えば品質管理者が適宜追加・変更できるものとする。なお、ヒヤリハット選定マスタ３０の詳細については、後述する。
【００２５】
また、ヒヤリハット管理ＤＢ２２は、図７に示すように、「発生日」、「発生時刻」、「連番」、「報告者ＩＤ」、「利用者ＩＤ」、「発生場所」、「影響度」、「状況」、「具体的内容影響」、「発生後の対応」、「要因背景」、「利用者家族への説明対応内容」の各フィールドを有している。
【００２６】
図３に戻り、再発判断部１６は、是正通知マスタ３２に基づいて、ヒヤリハット管理ＤＢ２２に登録された事例の是正通知ヒット率を算出する。ここで、是正通知ヒット率とは、ヒヤリハット管理ＤＢ２２に登録された事例と、過去に対策が講じられたヒヤリハットの事例との類似度合いを示す指標である。したがって、再発判断部１６は、算出した是正通知ヒット率を用いて、ヒヤリハット管理ＤＢ２２に登録された事例と、過去に対策が講じられたヒヤリハットの事例とが類似しているか否かを判断する。また、再発判断部１６は、ヒヤリハット事例が過去に対策が講じられたヒヤリハット事例と類似していた場合（再発したヒヤリハット事例であった場合）には、その旨を管理者端末６０に対して通知する。
【００２７】
ここで、是正通知マスタ３２は、図８に示すように、是正通知ヒット率を定めるマスタと、キーワード、場所、時間帯、問題のある利用者、問題のある職員に関するポイントの加算基準を定めるマスタと、是正再発期間と、を有する。なお、図８の各マスタを使用するか否かは、例えば品質管理者が定めることができるものとする。また、是正通知マスタ３２に含まれる各マスタの内容も、例えば品質管理者が適宜追加・変更できるものとする。
【００２８】
登録部１８は、管理者端末６０又は介護担当者端末７０からの求めに応じて、図１３のヒヤリハット可能性ありリスト、図１０のヒヤリハット編集画面、図１１の対策登録画面を、端末６０又は７０の表示部１９３上に表示する。また、登録部１８は、図１０、図１１の画面上において入力されたデータを用いて、ヒヤリハット管理ＤＢ２２及び対策情報格納部としての対策ＤＢ２４を更新する。
【００２９】
ここで、対策ＤＢ２４は、図９に示すように、「発生日」、「発生時刻」、「連番」、「管理者ＩＤ」、「リスク評価」、「リスク予測」、「改善の必要性」、「教育研修への活用」、「対策施行日」、「対策」、「管理者コメント」、の各フィールドを有している。ここで、「発生日」、「発生時刻」、「連番」の各フィールドは、図７のヒヤリハット管理ＤＢ２２の先頭にも含まれている。すなわち、これら３つのフィールドで、対策ＤＢ２４の各レコードとヒヤリハット管理ＤＢ２２の各レコードとが紐付いているといえる。これにより、ヒヤリハット管理ＤＢ２２に格納されている各事例に対する対策が講じられているか否かを対策ＤＢ２４との関係から判断することができる。
【００３０】
「リスク評価」のフィールドには、リスク評価をしたか否か（「あり」又は「なし」）が入力される。「リスク予測」のフィールドには、リスク予測が可能か否かが入力される。「改善の必要性」のフィールドには、改善する必要があるか否かが入力される。「教育研修への活用」のフィールドには、教育研修に活用できるか否かが入力される。「対策施行日」のフィールドには対策を講じた日付が入力される。「対策」のフィールドには、品質管理者が講じた対策の内容が入力される。また、「管理コメント」は、品質管理者のコメントが入力される。
【００３１】
次に、本実施形態のサーバ１０の処理について、図１２、図１４、図１６〜図１８のフローチャートに沿って、その他図面を適宜参照しつつ、詳細に説明する。
【００３２】
（登録処理）
まず、図１２のフローチャートに沿って、サーバ１０による登録処理について説明する。
【００３３】
図１２の処理では、ステップＳ１０において、ケース記録処理部１２が、介護担当者端末７０から、ケース記録画面の表示要求が出されるまで待機する。この場合、介護担当者端末７０からケース記録画面の表示要求が出された段階で、ケース記録処理部１２は、ステップＳ１２に移行する。
【００３４】
ステップＳ１２に移行すると、ケース記録処理部１２は、表示要求が出された日付に対応するケース記録画面（図４）を生成し、介護担当者端末７０の表示部１９３上に表示する。この場合、介護担当者は、ケース記録画面に時刻毎、実施内容ごとに、介護において気づいた点などの事例を「身体状態及び日常生活動作状況」の欄に記入し、更新ボタンを押す作業を行う。
【００３５】
次いで、ステップＳ１４では、ケース記録処理部１２は、介護担当者によってケース記録画面への記録がなされたか否か（データの入力がされ、更新ボタンが押されたか否か）を判断する。ここでの判断が否定された場合、すなわち、未だ更新ボタンが押されていない場合には、ステップＳ３０に移行し、ケース記録処理部１２は、ケース記録画面が終了されたか否かを判断する。ここでの判断が否定された場合には、ステップＳ１４に戻る。
【００３６】
一方、ステップＳ１４の判断が肯定された場合には、ステップＳ１６に移行し、ケース記録処理部１２は、ケース記録ＤＢ２０に対して新たに入力されたデータ（事例）を登録する。
【００３７】
次いで、ステップＳ１８では、ヒヤリハット抽出部１４が、ヒヤリハット判断処理を実行する。具体的には、ヒヤリハット抽出部１４は、ケース記録ＤＢ２０に登録された事例について、図６のヒヤリハット選定マスタを用いて、ヒヤリハット基準点を算出する。例えば、ヒヤリハット抽出部１４は、図５のケース記録ＤＢ２０の３行目（７：００）の事例であれば、キーワード「困難」があるので１ポイント加算、問題のある職員「００１」が報告者であるので１ポイント加算…などのポイント加算形式で、ヒヤリハット基準点を算出する。そして、ヒヤリハット抽出部１４は、ヒヤリハット選定マスタ３０のヒヤリハット基準点に関するマスタ（図６の左上）を参照し、ヒヤリハット基準点の合計ポイントに基づいて、事例が「ヒヤリハット確定」か「ヒヤリハット可能性あり」か、いずれでもないかを判断する。
【００３８】
次いで、ステップＳ２０では、ヒヤリハット抽出部１４が、ステップＳ１８において「ヒヤリハット確定」と判断されたか否かを判断する。ここでの判断が肯定された場合には、ステップＳ２２に移行する。そして、ステップＳ２２では、ヒヤリハット抽出部１４が、ヒヤリハット確定と判断された事例を、ヒヤリハット管理ＤＢ２２に登録する。この場合、例えば、図７の最下行に示すように、ヒヤリハット管理ＤＢ２２に新たな事例が登録された場合には、ケース記録ＤＢ２０のフィールドと対応するフィールドにデータが登録され、対応しないフィールドは空欄となる。なお、ステップＳ２２の処理の後は、ステップＳ２８に移行する。
【００３９】
一方、ステップＳ２０の判断が否定された場合、すなわち、ステップＳ１８において、「ヒヤリハット確定」と判断されなかった場合には、ヒヤリハット抽出部１４は、ステップＳ２４に移行する。そして、ステップＳ２４では、ヒヤリハット抽出部１４は、ステップＳ１８においてヒヤリハット可能性ありと判断されたか否かを判断する。ここでの判断が否定された場合には、ステップＳ３０に移行するが、肯定された場合には、ステップＳ２６に移行する。
【００４０】
ステップＳ２６に移行した場合、ヒヤリハット抽出部１４は、事例をヒヤリハット可能性ありリストに登録する。ここで、ヒヤリハット可能性ありリストには、図１３に示すように、事例の「発生日」、「時刻」、「実施内容」、「身体状態及び日常生活動作状況」が登録される。これらのうち、「状況」の欄には、ケース記録ＤＢ２０の「身体状態及び日常生活動作状況」の内容が入力される。なお、ヒヤリハット可能性ありリストは、報告者ＩＤごとに作成されるものとする。
【００４１】
次いで、ステップＳ２８では、再発判断部１６が、再発通知リスト登録処理のサブルーチンを実行する。この場合、再発判断部１６は、図１４のフローチャートに沿った処理を実行する。
【００４２】
図１４の処理では、まず、ステップＳ４０において、再発判断部１６が、再発回数を示すパラメータｉを０に設定（初期化）する。次いで、ステップＳ４２では、再発判断部１６が、ヒヤリハット管理ＤＢ２２の最初のレコード（事例）を抽出する。
【００４３】
次いで、ステップＳ４３では、再発判断部１６が、抽出されたレコードの対策情報が対策ＤＢ２４に登録されているか否かを判断する。この場合、再発判断部１６は、ヒヤリハット管理ＤＢ２２の抽出されたレコードの「発生日」、「発生時刻」、「連番」と同一のものが、対策ＤＢ２４に存在しているか否かを判断する。このステップＳ４３の判断が否定された場合、すなわち、抽出されたレコード（ヒヤリハット事例）が未だ対策が講じられていない事例であれば、ステップＳ５０に移行するが、肯定された場合には、ステップＳ４４に移行する。
【００４４】
ステップＳ４４に移行した場合、抽出されたレコード（事例）と、新たにケース記録画面に入力された事例とを比較して一致する項目を特定し、当該特定された項目のポイントの合計を是正通知マスタ３２を参照して算出する。
【００４５】
次いで、ステップＳ４６では、再発判断部１６が、是正通知ヒット率が「高」であるか否かを判断する。この場合、再発判断部１６は、是正通知マスタ３２の是正通知ヒット率マスタ（図８の左上のマスタ）に基づいて、ステップＳ４４で算出したヒット率が「高」であるか否かを判断する。ここでの判断が否定された場合には、ステップＳ５０に移行する。一方、ステップＳ４６の判断が肯定された場合には、ステップＳ４８に移行する。ステップＳ４８に移行した場合、再発判断部１６は、再発回数を示すパラメータｉを１インクリメント（ｉ←ｉ＋１）し、ステップＳ５０に移行する。
【００４６】
ステップＳ５０に移行すると、再発判断部１６は、是正再発期間内の全てのレコードを抽出したか否かを判断する。ここで、是正再発期間は、予め定められているものとする（図８の左下参照）。図８のように、是正再発期間として６ヶ月が設定されている場合には、現在から６ヶ月前までの全てのレコードの抽出が完了した段階で、ステップＳ５０の判断が肯定されることになる。一方、現在から６ヶ月前までの全てのレコードの抽出が完了していない場合には、ステップＳ５０の判断が否定され、ステップＳ５２に移行する。ステップＳ５２では、再発判断部１６は、ヒヤリハット管理ＤＢ２２の次のレコードを抽出し、ステップＳ４３に戻る。その後は、ステップＳ４３〜Ｓ５０の処理・判断を繰り返す。
【００４７】
一方、ステップＳ５０の判断が肯定されると、再発判断部１６は、ステップＳ５４に移行する。ステップＳ５４では、再発判断部１６は、ｉが０よりも大きいか否かを判断する。ここでの判断が否定された場合には、図１４の全処理を終了して、図１２のステップＳ３０に移行する。一方、ステップＳ５４の判断が肯定された場合には、ステップＳ５６に移行する。ステップＳ５６では、再発判断部１６は、新たなケース記録の事例を、是正通知ヒット率が「高」の回数ｉとともに、再発通知リストに登録する。ここで、再発通知リストは、図１５に示すようなリストであるものとする。図１５の再発通知リストは、「選択（の有無）」と、「発生日」と、「状況」と、「再発回数」と、「前回是正日」と、が格納される。「状況」の欄には、ケース記録ＤＢ２０の「身体状態及び日常生活動作状況」の内容が入力される。「再発回数」の欄には、パラメータｉの値が入力される。「前回是正日」の欄には、品質管理者が、直近の類似するヒヤリハット事例についての対策を講じた日付（図９の「対策施行日」）が入力される。上記のように、ステップＳ５６の処理が行われた後は、図１２のステップＳ３０に移行する。
【００４８】
図１２に戻り、ステップＳ３０に移行すると、ケース記録処理部１２は、ケース記録画面が終了されたか否かを判断する。ここでの判断が否定された場合には、ケース記録画面の表示を継続したまま、ステップＳ１４に戻り、上記と同様の処理を繰り返す。一方、ステップＳ３０の判断が肯定された場合には、ケース記録画面の表示を終了して、ステップＳ１０に戻り、上記と同様の処理を繰り返す。
【００４９】
以上のような処理を行うことで、介護担当者がケース記録画面においてケース記録を入力し、更新ボタンを押したタイミングで、ケース記録ＤＢ２０への事例の格納、ヒヤリハット管理ＤＢ２２への事例の登録又はヒヤリハット可能性ありリストへの登録、再発通知リストへの登録の処理を行うことができる。
【００５０】
（ヒヤリハット事例追加登録処理）
次に、図１６に基づいて、ヒヤリハット事例追加登録処理について説明する。本処理は、ヒヤリハット可能性ありリスト（図１３）に登録されている事例を、ヒヤリハット事例として、ヒヤリハット管理ＤＢ２２に追加登録する処理である。図１６の処理は、登録部１８が実行する処理である。
【００５１】
図１６の処理では、まず、ステップＳ６０において、登録部１８が、ヒヤリハット可能性ありリストの表示要求が出されるまで待機する。この場合、介護担当者端末７０から表示要求が出された段階で、ステップＳ６２に移行する。
【００５２】
ステップＳ６２に移行すると、登録部１８は、表示要求を出した介護担当者に対応するヒヤリハット可能性ありリスト（図１３）を表示する。介護担当者は、表示されたヒヤリハット可能性ありリストにおいて、リストに含まれる事例を選択する（図１３のいずれかの事例を選択し、実行ボタンを押す）。
【００５３】
次いで、ステップＳ６４では、登録部１８が、事例が選択されたか否かを判断する。ここでの判断が肯定された場合には、ステップＳ６６に移行し、ヒヤリハット管理ＤＢ２２に選択された事例を登録（追加登録）するとともに、ヒヤリハット可能性有りリストから選択された事例を削除した後、ステップＳ６８に移行する。一方、ステップＳ６４の判断が否定された場合には、ステップＳ６８に直接移行する。
【００５４】
ステップＳ６８に移行すると、登録部１８は、介護担当者端末７０から、ヒヤリハット可能性ありリストの表示終了要求が出されたか否かを判断する。ここでの判断が否定された場合には、ステップＳ６４に戻り、ステップＳ６４〜Ｓ６８の処理・判断を繰り返す。一方、ステップＳ６８の判断が肯定された場合（図１３の終了ボタンが押された場合）には、ヒヤリハット可能性ありリストの表示を終了して、ステップＳ６０に戻り、ステップＳ６０〜Ｓ６８の処理・判断を繰り返す。
【００５５】
以上の処理により、登録部１８は、ヒヤリハット可能性ありリストに登録された事例を、介護担当者の入力に応じて、ヒヤリハット管理ＤＢ２２に登録（追加登録）することが可能となっている。すなわち、本実施形態では、ヒヤリハット可能性ありリストに登録した事例の、ヒヤリハット管理ＤＢ２２への追加登録を、介護担当者本人の判断に委ねていることになる。
【００５６】
（ヒヤリハット事例の内容補充処理）
次に、図１７のフローチャートに沿って、ヒヤリハット事例の内容補充処理について説明する。本処理は、介護担当者が、ヒヤリハット管理ＤＢ２２（図７）に登録されている事例の内容を充実させるために行う内容補充を実現するための処理である。なお、図１７の処理は、登録部１８が実行する処理である。
【００５７】
図１７の処理では、まず、ステップＳ８０において、登録部１８が、ヒヤリハットリストの表示要求が出されるまで待機する。この場合、介護担当者端末７０から、表示要求が出された段階で、登録部１８は、ステップＳ８２に移行する。
【００５８】
ステップＳ８２に移行すると、登録部１８は、ヒヤリハットリストを表示する。なお、ヒヤリハットリストは、図７のヒヤリハット管理ＤＢ２２のうち、ヒヤリハット事例の識別に用いるために必要なフィールドのみを抽出したリストであるものとする。なお、介護担当者は、表示されたヒヤリハットリストの中から、編集やデータ追加などを行いたい１つのヒヤリハット事例を選択するものとする。
【００５９】
次いで、ステップＳ８４では、登録部１８は、ヒヤリハット事例が選択されたか否かを判断する。ここでの判断が否定された場合には、ステップＳ９２に移行する。一方、ステップＳ８４の判断が肯定された場合には、ステップＳ８６に移行する。
【００６０】
ステップＳ８６に移行した場合、登録部１８は、ヒヤリハット事例を選択した介護担当者の端末７０に、ヒヤリハット編集画面（図１０）を表示する。ここで、図１０のヒヤリハット編集画面には、ヒヤリハット管理ＤＢ２２のフィールドと同一の入力欄が存在しているものとする。介護担当者は、これらの入力欄にヒヤリハット事例に関するデータを入力する。
【００６１】
次いで、ステップＳ８８では、ヒヤリハット編集画面における編集が完了したか否か（図１０の更新ボタンが押されたか否か）を判断する。ここでの判断が否定されている間は、ステップＳ８８を繰り返すが、ステップＳ８８の判断が肯定された場合には、ステップＳ９０に移行する。
【００６２】
ステップＳ９０に移行すると、登録部１８は、ヒヤリハット編集画面に入力された内容で、ヒヤリハット管理ＤＢ２２を更新する。その後は、ステップＳ９２に移行する。
【００６３】
ステップＳ９２では、ヒヤリハット編集画面の表示終了要求が出されたか否かを判断する。ここでの判断が否定された場合には、ステップＳ８４に戻り、ステップＳ８４〜Ｓ９２の処理・判断を繰り返す。一方、ステップＳ９２の判断が肯定された場合にはステップＳ８０に戻り、ステップＳ８０〜Ｓ９２の処理・判断を繰り返す。
【００６４】
以上の処理により、登録部１８は、介護担当者の入力に応じて、ヒヤリハット管理ＤＢ２２の内容の補充を行うことが可能となっている。
【００６５】
（対策ＤＢへの登録処理）
次に、図１８のフローチャートに沿って、対策ＤＢ２４への登録処理について説明する。本処理は、品質管理者の入力を受けて、対策ＤＢ２４に、再発通知リスト（図１５）に登録されているヒヤリハット事例に関する対策情報を登録するための処理である。なお、図１８の処理は、登録部１８が実行する処理である。
【００６６】
図１８の処理では、まず、ステップＳ１０２において、登録部１８が、管理者端末６０において処理の開始要求が出されるまで待機する。なお、処理の開始要求は、例えば、品質管理者が医療介護支援システム１００の画面を起動するためのアイコン等を選択した段階で出される。
【００６７】
ステップＳ１０４では、登録部１８は、再発通知リスト（図１５）が空でないかを判断する。ここでの判断が否定された場合（空の場合）には、ステップＳ１０２に戻る。一方、ステップＳ１０４の判断が肯定された場合（空でない場合）には、ステップＳ１０６に移行する。
【００６８】
ステップＳ１０６に移行すると、登録部１８は、図１５の再発通知リストを管理者端末６０の表示部１９３上に表示する。なお、品質管理者は、表示された再発通知リストの中から、対策情報の登録を行いたい事例を選択し、実行ボタンを押す。ここで、再発通知リストには、是正再発期間における各事例の「再発回数」も記載されている。したがって、品質管理者は、例えば、是正再発期間における再発回数が多い（頻度が高い）ほど早急に対策を講じる必要があると判断して、事例の選択を行うことが可能となっている。
【００６９】
次いで、ステップＳ１０８では、登録部１８は、再発通知リストの１つの事例が選択されたか否かを判断する。ここでの判断が否定された場合には、ステップＳ１１６に移行するが、肯定された場合には、ステップＳ１１０に移行する。
【００７０】
ステップＳ１１０に移行した場合、登録部１８は、管理者端末６０の表示部１９３上に、対策登録画面（図１１）を表示する。ここで、図１１の対策登録画面には、対策ＤＢ２４のフィールドと同一の入力欄が存在しているものとする。品質管理者は、これらの入力欄にヒヤリハット事例に対する対策の情報を入力する。
【００７１】
次いで、ステップＳ１１２では、対策登録画面における入力が完了したか否か（図１１の更新ボタンが押されたか否か）を判断する。ここでの判断が否定されている間は、ステップＳ１１２を繰り返すが、ステップＳ１１２の判断が肯定された場合には、ステップＳ１１４に移行する。
【００７２】
ステップＳ１１４に移行すると、登録部１８は、対策登録画面に入力された内容で、対策ＤＢ２４を更新する。なお、登録部１１８は、新たなヒヤリハット事例に関する対策情報を対策ＤＢ２４に対して新たに登録する。また、登録部１１８は、対策ＤＢ２４にすでに登録されている対策情報（改善が必要な対策情報）を上書きするものとする。更に、登録部１８は、再発通知リストから、対策ＤＢ２４に対策情報を登録した事例を削除する。その後は、ステップＳ１１６に移行する。
【００７３】
ステップＳ１１６では、対策登録画面の表示終了要求が出されたか否かを判断する。ここでの判断が否定された場合には、ステップＳ１０８に戻り、ステップＳ１０８〜Ｓ１１４の処理・判断を繰り返す。一方、ステップＳ１１６の判断が肯定された場合にはステップＳ１０２に戻り、ステップＳ１０２〜Ｓ１１６の処理・判断を繰り返す。
【００７４】
以上の処理により、登録部１８は、品質管理者によって入力された、ヒヤリハット事例に対する対策情報を対策ＤＢ２４に格納することが可能となっている。なお、対策ＤＢ２４に格納された情報は、介護担当者等への啓蒙のため、適切なタイミングで、各介護担当者端末７０の表示部１９３上に表示されるものとする。また、対策ＤＢ２４に格納された情報は、介護担当者や品質管理者が適宜閲覧できるようになっているものとする。
【００７５】
なお、再発通知リストが空の場合であっても、品質管理者は、新たにヒヤリハット管理ＤＢ２２に登録されたヒヤリハット事例に関する対策情報を対策ＤＢ２４に登録する必要がある。この場合、品質管理者は、登録部１８に対して、ヒヤリハット管理ＤＢ２２に登録されているヒヤリハット事例に関する対策登録画面を表示させ、当該画面上にて対策情報を入力するようにする。これにより、登録部１８は、新たなヒヤリハット事例の対策情報を対策ＤＢ２４に登録することが可能となる。
【００７６】
以上、詳細に説明したように、本実施形態によると、ケース記録ＤＢ２０に、介護担当者により入力されるケース記録が格納されており、ヒヤリハット管理ＤＢ２２に、ヒヤリハット事例が格納されており、対策ＤＢ２４に、品質管理者により入力されるヒヤリハット事例に対応する対策情報が格納されている。そして、再発判断部１６は、介護担当者により入力されるケース記録と、過去にヒヤリハット管理ＤＢ２２に格納されており、かつ対策ＤＢ２４に対策情報が格納されている情報と、の類似度合い（是正通知ヒット率）を算出し、是正通知ヒット率が所定値以上であった場合（高であった場合）に、その対策情報を改善が必要な対策情報と特定する。これにより、本実施形態では、新たな事例と対策が講じられている過去のヒヤリハット事例との類似度合いから、新たな事例が再発した対策済みのヒヤリハット事例であること（対策済みのヒヤリハット事例が、対策を再検討する必要のあるヒヤリハット事例であること）を自動的に特定することができる。したがって、本実施形態では、品質管理者による再発した対策済みのヒヤリハット事例（対策を再検討する必要のあるヒヤリハット事例）の収集作業を支援することが可能となる。また、特定されたヒヤリハット事例を品質管理者に通知することで、品質管理者に対して、再発したヒヤリハット事例に関する対策の再検討を促すことが可能となる。
【００７７】
また、本実施形態では、再発判断部１６は、ケース記録ＤＢ２０に新たに格納された事例と、是正再発期間（例えば６ヶ月）内にヒヤリハット管理ＤＢ２２に格納された対策済みのヒヤリハット事例との是正通知ヒット率を算出する。そして、登録部１８が通知する再発通知リストには、是正再発期間（例えば、６ヶ月）内に是正通知ヒット率が「高」になった回数も表示する。これにより、本実施形態では、品質管理者は、是正再発期間における再発頻度に基づいた処理を行うことが可能となる。例えば、品質管理者は、是正再発期間における再発頻度に基づいて、早急に対策を講じる必要があるヒヤリハット事例と、そうでないヒヤリハット事例とを分類し、優先度をつけて処理することが可能となる。
【００７８】
また、本実施形態では、ヒヤリハット抽出部１４が、ヒヤリハット選定マスタ３０（図６）に基づいて、ケース記録ＤＢ２０に新たに格納された事例がヒヤリハット事例であるか否かの可能性を示すヒヤリハット基準点を算出する。そして、ヒヤリハット抽出部１４は、ヒヤリハット基準点に基づいて、「ヒヤリハット確定」又は「ヒヤリハット可能性あり」を判断し、「ヒヤリハット確定」であれば、事例を自動的にヒヤリハット管理ＤＢ２２に格納し、「ヒヤリハット可能性あり」であれば、介護担当者の選択に応じて事例をヒヤリハット管理ＤＢ２２に格納する。これにより、本実施形態では、ヒヤリハット基準点が高く、ヒヤリハット管理ＤＢ２２に格納すべき事例であることが明らかである場合には、ヒヤリハット抽出部１４が自動的にヒヤリハット管理ＤＢ２２に事例を格納し、ヒヤリハット基準点がやや低く、ヒヤリハット管理ＤＢ２２に格納すべき事例でない可能性がある場合には、ヒヤリハット管理ＤＢ２２に事例を格納するか否かの判断を介護担当者に委ねるようになっている。これにより、介護担当者のヒヤリハット管理ＤＢ２２への事例の登録の負担を軽減するととともに、一部を介護担当者の判断に委ねることで、登録精度を向上することが可能となる。
【００７９】
なお、上記実施形態では、再発判断部１６が、抽出されたレコードの対策情報が対策ＤＢ２４に登録されているか否かを判断し（図１４のステップＳ４３）、当該判断が肯定された場合に、是正通知ヒット率を算出する場合について説明した。しかしながら、これに限られるものではなく、例えば、図１９に示すように、図１４のステップＳ４３の処理に代えて、ステップＳ４７の処理を行うこととしても良い。この場合、再発判断部１６は、抽出したレコードと新たな事例との是正通知ヒット率が「高」であった場合に抽出したレコードの対策情報が対策ＤＢ２４に登録されているか否かを判断し、当該判断が肯定された場合に、是正通知リストに新たな事例を登録する。このようにしても、上記実施形態と同様の作用効果を得ることができる。
【００８０】
なお、上記実施形態では、再発判断部１６は、是正再発期間中における再発回数を是正通知ヒット率に加算するようにしても良い。このようにすることで、再発頻度が高い事例の是正通知ヒット率を高くすることができる。
【００８１】
また、上記実施形態では、再発するまでの期間に応じた処理（表示）を行うこととしてもよい。例えば、再発するまでの期間が長い場合には、対策情報が形骸化している旨を通知するなどしてもよい。この場合、再発通知リスト（図１５）にその旨を表示しても良いし、別途、形骸化リストなどを作成して表示することとしてもよい。
【００８２】
なお、上記実施形態では、図１２の登録処理において、ステップＳ２２及びＳ２６の処理の後にステップＳ２８の処理を行う場合について説明したが、これに限られるものではない。例えば、ステップＳ２２の後にはステップＳ２８の処理を実行する一方で、ステップＳ２６の後にはステップＳ２８の処理を実行しないようにしてもよい。この場合、図１６のステップＳ６６の処理が行われた段階で、ステップＳ２８と同様の処理を行うようにしてもよい。
【００８３】
なお、上記実施形態では、ステップＳ４６において、是正通知ヒット率が「高」である場合に、パラメータｉを１インクリメントする場合について説明したが、これに限られるものではない。例えば、パラメータｉを１インクリメントする基準を品質管理者等が変更できるようにしてもよい。
【００８４】
なお、上記実施形態では、ヒヤリハット事例をヒヤリハット抽出部１４が自動的にヒヤリハット管理ＤＢ２２に登録する場合があるものとして説明したが、これに限られるものではない。例えば、介護担当者が、全てのヒヤリハット事例を手動で登録するようにしてもよい。
【００８５】
なお、上記実施形態では、介護施設に医療介護支援システムを導入した場合について説明したが、これに限らず、医療施設に導入することとしてもよい。
【００８６】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。
【００８７】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【００８８】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【００８９】
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【００９０】
なお、以上の説明に関して更に以下の付記を開示する。
（付記１）  ユーザにより入力された医療又は介護に関する情報を医療介護情報格納部に格納し、
医療又は介護に関する事故に繋がる可能性のあるインシデント情報をインシデント情報格納部に格納し、
ユーザにより入力された前記インシデント情報に対応する対策情報を対策情報格納部に格納し、
前記医療又は介護に関する情報と、過去に前記インシデント情報格納部に格納されており、かつ前記対策情報格納部に対策情報が格納されている情報と、の類似度合いを算出し、
前記類似度合いに基づいて改善が必要な対策情報を特定する、処理をコンピュータに実行させる医療介護支援プログラム。
（付記２）前記特定された前記改善が必要な対策情報をユーザに通知する処理を前記コンピュータに更に実行させ、
前記算出する処理では、前記医療又は介護に関する情報と、過去の所定期間内にインシデント情報格納部に格納され、かつ前記対策情報格納部に対策情報が格納されている情報と、の類似度合いを算出し、
前記特定する処理では、医療又は介護に関する情報との類似度合いが所定値以上となった対策情報を特定し、
前記通知する処理では、前記特定された対策情報の数に応じた通知を行うことを特徴とする付記１に記載の医療介護支援プログラム。
（付記３）  前記インシデント情報である可能性を判断するための基準に基づいて、前記医療介護情報格納部に格納された情報が前記インシデント情報である可能性を判断する処理を前記コンピュータに更に実行させ、
前記インシデント情報格納部に格納する処理では、前記インシデント情報である可能性に基づいて又は前記ユーザの入力に基づいて、前記医療介護情報格納部に格納された情報を前記インシデント情報格納部に格納することを特徴とする付記１又は２に記載の医療介護支援プログラム。
（付記４）  前記特定された前記改善が必要な対策情報をユーザに通知する処理を前記コンピュータに更に実行させ、
前記通知する処理では、前記ユーザにより入力された医療又は介護に関する情報との類似度合いが所定値以上となった情報に対応する対策情報が前記対策情報格納部に格納された時期に応じた通知を行うことを特徴とする付記１に記載の医療介護支援プログラム。
（付記５）  ユーザにより入力された医療又は介護に関する情報を格納する医療介護情報格納部と、
医療又は介護に関する事故に繋がる可能性のあるインシデント情報を格納するインシデント情報格納部と、
ユーザにより入力された前記インシデント情報に対応する対策情報を格納する対策情報格納部と、
前記医療又は介護に関する情報と、過去に前記インシデント情報格納部に格納されており、かつ前記対策情報格納部に対策情報が格納されている情報と、の類似度合いを算出する算出部と、
前記類似度合いに基づいて改善が必要な対策情報を特定する特定部と、を備える医療介護支援装置。
（付記６）  前記特定部によって特定された前記改善が必要な対策情報をユーザに通知する通知部を更に備え、
前記算出部は、前記医療又は介護に関する情報と、過去の所定期間内にインシデント情報格納部に格納され、かつ前記対策情報格納部に対策情報が格納されている情報と、の類似度合いを算出し、
前記特定部は、前記医療又は介護に関する情報との類似度合いが所定値以上となった対策情報を特定し、
前記通知部は、前記特定された対策情報の数に応じた通知を行うことを特徴とする付記５に記載の医療介護支援装置。
（付記７）  前記インシデント情報である可能性を判断するための基準に基づいて、前記医療介護情報格納部に格納された情報が前記インシデント情報である可能性を判断する判断部と、
前記インシデント情報である可能性に基づいて又は前記ユーザの入力に基づいて、前記医療介護情報格納部に格納された情報を前記インシデント情報格納部に格納する格納処理部と、を更に備える付記５又は６に記載の医療介護支援装置。
（付記８）  前記特定された前記改善が必要な対策情報をユーザに通知する通知部を更に備え、
前記通知部は、前記ユーザにより入力された医療又は介護に関する情報との類似度合いが所定値以上となった対策情報が前記対策情報格納部に格納された時期に応じた通知を行うことを特徴とする付記５に記載の医療介護支援装置。
【符号の説明】
【００９１】
１０  サーバ（医療介護支援装置）
１４  ヒヤリハット抽出部（判断部、格納処理部）
１６  再発判断部（算出部、特定部）
１８  登録部（通知部）
２０  ケース記録ＤＢ（医療介護情報格納部）
２２  ヒヤリハット管理ＤＢ（インシデント情報格納部）
２４  対策ＤＢ（対策情報格納部）
３０  ヒヤリハット選定マスタ（基準）
【図１】
0005938769.tif 000002
【図２】
0005938769.tif 000003
【図３】
0005938769.tif 000004
【図４】
0005938769.tif 000005
【図５】
0005938769.tif 000006
【図６】
0005938769.tif 000007
【図７】
0005938769.tif 000008
【図８】
0005938769.tif 000009
【図９】
0005938769.tif 000010
【図１０】
0005938769.tif 000011
【図１１】
0005938769.tif 000012
【図１２】
0005938769.tif 000013
【図１３】
0005938769.tif 000014
【図１４】
0005938769.tif 000015
【図１５】
0005938769.tif 000016
【図１６】
0005938769.tif 000017
【図１７】
0005938769.tif 000018
【図１８】
0005938769.tif 000019
【図１９】
0005938769.tif 000020