JP2008250664A - 看護必要度管理システム - Google Patents

Abstract

【構成】 看護必要度管理システム（１０）はサーバ（１２）を含み、サーバはネットワーク（１４）を介してセンサユニット（２０）と通信可能に接続される。センサユニットは、これを装着する看護師の発話音声を収集して、サーバに送信する。サーバは、看護師の発話データを形態素解析して単語を抽出し、看護師が関与した患者、看護師がその患者に対して遂行した看護師業務、その看護師業務の継続時間を含む看護師データを取得する。その看護師データを患者ごとにソーティングし（Ｓ３３）、患者ごとの、看護師が関与した合計時間（患者合計時間）を計算し（Ｓ３７）、それを係数で処理し（Ｓ３９）、看護必要度基礎点数を求め、ステップＳ４１で、その看護必要度基礎点数が看護必要度のランクのどれに属するか判定し、看護必要度ランクを決定する。
【効果】 患者の実態を反映した看護必要度を決定することができる。
【選択図】 図９

Description

この発明は看護必要度管理システムに関し、特にたとえば、患者の実態に即した看護必要度を決定できる、新規な看護必要度管理システムに関する。

「患者が必要としている看護量」を看護必要度と定義できるが、この看護必要度については、非特許文献１に詳細に説明されている。看護必要度は、特に診療報酬との関係で、さらには看護師の適正配置のために、必要な看護サービスの評価基準である。
「看護必要度（第２版）」株式会社日本看護協会出版会（２００７年２月５日第２版第３刷）

非特許文献１に示す背景技術では、必ずしも真の看護必要度を決定できるとは限らない。患者がたとえば手の上げ下げ、寝返り、起き上がりなどを自分でできたとしても、その患者には別の理由で実際には看護師の介助または看護が常時必要な場合もある。したがって、それらの行為が患者だけでできるか、あるいは一部介助または全部介助の必要があることを基準に看護必要度を算定しようとする、背景技術の提案手法では、決定した看護必要度が必ずしもその患者の実態を反映したものにはならないという問題がある。

それゆえに、この発明の主たる目的は、新規な、看護必要度管理システムを提供することである。

この発明の他の目的は、患者の実態を反映した看護必要度を決定できる、看護必要度管理システムを提供することである。

請求項１の発明は、患者を特定できる情報、その患者に看護師が係った所要時間を示す時間情報、およびその時間に行った看護業務を示す情報を含む看護師データを、各看護師について取得する看護師データ取得手段、看護師データに基づいて特定の患者に対する全ての看護師の所要時間を合計して患者合計時間を計算する合計時間計算手段、および患者合計時間に基づいて特定の患者に対する看護必要度を決定する看護必要度決定手段を備える、看護必要度管理システムである。

請求項１の発明は、実施例ではサーバのようなコンピュータで構成される。実施例では看護師データ取得手段は、図６に示すフロー図で示され、合計時間計算手段および看護必要度決定手段が、図９のフロー図で構成される。

請求項１の発明によれば、患者ごとに集計した患者合計時間に基づいて看護必要度を決定するので、患者の実態を反映した真の看護必要度を決定することができる。

請求項２の発明は、看護必要度決定手段は、患者合計時間を予め設定されている係数で処理した結果の看護必要度基礎点数に基づいて看護必要度を決定する、請求項１記載の看護必要度管理システムである。

請求項３の発明は、看護必要度決定手段は、看護必要度を看護必要度ランクとして決定する、請求項１または２記載の看護必要度管理システムである。

この発明によれば、患者の実態に即した看護必要度を決定することができる。

この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。

図１を参照して、この発明の一実施例である看護必要度管理システム１０は、たとえば病院内に設置されたサーバ１２を含む。このサーバ１２は、有線或いは無線による通信回線（ネットワーク）１４を介して複数の看護師用端末（以下、単に「端末」という。）１６および複数のステーション１８に接続される。端末１６は、パーソナルコンピュータ或いはワークステーションのようなコンピュータであり、病院の構成員としての看護師ごとに割り当てられる。たとえば、端末１６は看護師の詰所などに設置される。ただし、１台の端末１６を数人の看護師で使用する場合もあり得る。複数のステーション１８は、それぞれ、入院患者を収容する病棟内の、廊下、病室（入り口、ベッド或いはその近傍）および看護師の詰所などの所定位置に配置され、無線通信可能なウェアラブルセンサユニット（以下、単に「センサユニット」という。）２０の識別情報（後述する看護師ＩＤ）を取得し、サーバ１２に送信する。複数のセンサユニット２０は、それぞれ、看護師に割り当てられ（装着され）、センサユニット２０の識別情報は、無線通信可能な範囲（たとえば、半径３〜５メートル）に存在するステーション１８によって検出される。

なお、ステーション１８とセンサユニット２０とは互いに通信可能であるため、センサユニット２０は、無線通信可能な範囲に存在するステーション１８の識別情報（ステーションＩＤ）を検出する。後述の無線送信機５２および無線受信機５４（いずれも図３）を使って、センサユニット２０は、別のセンサユニットと無線通信することが可能であるため、無線通信可能な範囲に存在する２以上のセンサユニット２０同士で、互いの識別情報を検出することもできる。また、センサユニット２０は、無線ＬＡＮによってネットワーク１４に直接接続される場合もある。

図２はサーバ１２の具体的な構成を示すブロック図であり、サーバ１２には、図１では省略したが、複数の対物センサ２２、複数の集音マイク２４および複数のビデオカメラ２６が接続される。図示は省略するが、この実施例では、複数の対物センサ２２は、体温計、血圧計、注射器、点滴注射器（注入器）、血液採取用試験管、検尿コップなどの医療器具を格納してある格納箱の取り出し部分やナースコール端末などに設置され、それらの医療器具等についての使用（取り出し）の有無を検知する。ただし、これらの医療器具等に、タグ情報（ＲＦ‐ＩＤ）やバーコードのような識別情報を付加しておき、タグ情報やバーコードを読み取ることにより、その使用の有無を検出するようにしてもよい。なお、図示は省略するが、薬品にバーコードを付しておけば、薬品の取り違いの有無を検出することも可能である。

また、複数の集音マイク２４は、入院患者を収容する病棟内の廊下や病室（ベッド或いはその近傍）などに設置され、周囲音（主として看護師の音声）を集音する。さらに、複数のビデオカメラ２６は、集音マイク２４と同様の位置に設置され、さらには看護師の詰所などにも設定され、看護業務を行う看護師（の行動）を撮影する。ここで、看護業務とは、問診、検温、検圧、注射、投薬、点滴注射、退院指導などの看護師が行うべき業務（作業）の総称である。ただし、この実施例では、単に「看護業務」という場合には、これらのうちの任意の１つの業務や作業を指すこともある。

また、図１では省略したが、サーバ１２には、図２に示す３つのデータベース（ＤＢ）が接続される。具体的には、看護師用ＤＢ２８、患者用ＤＢ３０および分析用ＤＢ３２がサーバ１２に接続される。

看護師用ＤＢ２８には、看護師の識別情報（看護師ＩＤ）に対応して、つまり、看護師ごとに、看護師としての経験年数（年数および月数）およびこの病院における同じ科での勤続年数（年数および月数）などの看護師の属性を記述した看護師データが記憶される。看護師用ＤＢ２８にはまた、看護師ごとに、当該看護師の勤務シフトのデータが記憶されている。したがって、この勤務シフトデータを参照すれば、その看護師が勤務日なのかどうか、勤務時間なのか休憩時間なのかなどを、その都度容易に知ることができる。看護師用ＤＢ２８には、さらに、センサユニット２０を用いて看護師が録音しかつサーバ１２に送られた音声のデータや、その音声データに基づいてサーバ１２が看護師の看護業務の内容（作業）を分析した分析結果（たとえば、カテゴリ分析）などが、看護師ＩＤごとに（看護師ごとに）格納（記憶）される。

患者用ＤＢ３０は、たとえば、電子カルテ用のデータベースと共通のものでよく、さらには、電子カルテのサーバからデータを受け取るようにしてもよいが、患者の識別情報（患者ＩＤ）ごとに、患者の属性（性別、年齢などのデータ）の他、その患者の病名、手術予定、手術内容、さらには投薬履歴などのデータ、さらには主治医がだれか、担当看護師がだれかを示すデータなどが格納されている。この患者ＤＢ３０には、以下に説明するようにして決定される看護必要度を併せて記憶するようにしてもよい。

分析用ＤＢ３２には、たとえば、図６などに示す業務分析のためのプログラムや必要なテーブルなどが格納されている。テーブルは、後述のようにして特定される看護業務がどのカテゴリ(分類)に属するかを判定するためのテーブルである。つまり、発話データから抽出した単語が、どの業務カテゴリに属するかを予めテーブルとして設定しておく。実施例では、そのような業務カテゴリとしては、日本看護協会が発行する看護業務基準集の看護業務区分表、および日本看護科学学会が発行する看護行為用語分類を組み合わせて新たに作成した。ただし、上記２つの分類表を両方ともあるいはいずれかを選択して、そのまま利用することも可能である。たとえば、看護師の発話データの中に「カルテをチェックします。」という発話があったとすると、このカルテチェックは、「情報の整理」というカテゴリに区分できる。また、「診察」という単語が発話されたとき、「診察の補助または介助」というカテゴリに属するものと判定できる。

なお、そのカテゴリに対して学習する必要はあるものの、他のカテゴリを利用することも可能である。

分析用ＤＢ３２はさらに、図示しないが、係数テーブルを保持している。この係数テーブルは、後述の看護必要度を算出するまたは決定する際に、患者ごとの患者合計時間（１人の患者に関った全ての看護師の所要時間を合計した時間）に適用する係数を予め設定しておく。この係数は、基本的には、当該患者が看護師を必要としている程度を表すもので、手術の前後や当日で異なる数値が割り当てられる。また、手術にしても、全身麻酔を伴う手術か、部分麻酔だけでよい手術なのかによって、係数の数値が異なる。原則的には、前者の係数が後者の係数より大きく設定される。ただし、脳外科手術は部分麻酔であっても、非常に複雑で予後の大切な手術なので、他の全身麻酔手術に比べて、より大きい係数値を設定することも考えられる。さらに、身体の清潔という看護業務の中に「口腔ケア」があるが、その作業は歯磨きなどなので、時間的には５‐１５分程度（１日３回でも３０分から１時間以内）であるが、患者が自分でできないときには、基本的に寝たきりと判断するので、看護必要度としては重症の係数を設定する。いずれにしても、このような「係数」は、その病院の特性ないし個性、さらには医師、看護師などが有する知見、さらには学会などの客観的なデータに基づいて、適切に決めておく必要があることはいうまでもない。

上記係数を用いて後述のように看護必要度基礎点数を計算することができるが、この実施例では、その看護必要度基礎点数をそのまま看護必要度として決定するものではなく、計算した看護必要度基礎点数をたとえば、１０段階の看護必要度（看護必要度１‐看護必要度１０）にランク分けする。分析用ＤＢ３２には、そのための看護必要度テーブルが設定されている。その看護必要度テーブルでは、たとえば、看護必要度基礎点数が「１０００‐９００」のとき看護必要度１０とし、「９００‐８００」のとき看護必要度９とする、のように設定している。ただし、これは単なる例示である。

図３は看護師が装着するセンサユニット２０の具体的な構成を示すブロック図であり、センサユニット２０はＣＰＵ（プロセサ）４０を含む。ＣＰＵ４０には、時計回路４０ａが含まれるとともに、メモリ４２，エンコーダ／デコーダ４４，非接触センサ４６，インタフェース４８，ＤＩＰスイッチ５０，無線送信機５２および無線受信機５４が接続される。メモリ４２は、ワークメモリないしバッファメモリとして働き、ＣＰＵ４０によって使用される。エンコーダ／デコーダ４４にはマイク５６が接続され、エンコーダ／デコーダ４４は、マイク５６から入力される音声信号をＭＰ３のような圧縮音声データ（以下、単に「音声データ」という。）に変調する。圧縮音声データは、ＣＰＵ４０の指示に従って、時計回路４０ａによって生成されるタイムスタンプ（時刻データ）を付して、メモリ４２に記憶され、メモリ４２に記憶された圧縮音声データは、ＣＰＵ４０の指示に従って、一定時間（たとえば、１０秒〜３０秒）毎に、インタフェース４８およびネットワーク１４を介してサーバ１２に送信される。

なお、上述したように、音声信号を圧縮変調するのは、メモリ４２の容量を比較的少なくするためであり、また、サーバ１２に送信するデータのデータ量を低減するためである。

また、この実施例で用いるマイク５６は指向性を有するものである。これは、マイク５６を装着する看護師の音声のみを検出して、患者のプライバシを守るためである。

上述のように、通常は看護師が装着したセンサユニット２０から一定時間ごとに音声データがサーバ１２に送信されるが、この実施例では、一定時間（実施例ではたとえば、１０分間）以上その音声データがないとき、つまり、看護師が一定時間以上発話を記録しなかったかもしくは記録できなかったときには、サーバ１２から看護師のセンサユニット２０に、発話を記録することを促す信号を送信するようにしている。このサーバ１２から信号が送信される場合には、その信号に応答してセンサユニット２０に設けられているブザー（図示せず）を鳴動させる。このように、一定時間以上看護師の発話が受信できないとき、サーバ１２から該当の看護師に警告または督促を出すことによって、看護師の作業の記録の空白をなくすことができる。ただし、看護師用ＤＢ２８の看護師の勤務シフトデータから見て明らかに休憩時間と目される時刻にはこのような督促はする必要はない。

非接触センサ４６としては、焦電センサを用いることができ、ＣＰＵ４０は非接触センサ４６からの入力に応じてマイク５６をオン／オフする。この実施例では、非接触センサ４６すなわち焦電センサの前で、看護師が手を２回上下させると、その検出信号がＣＰＵ４０に入力され、これに応じて、ＣＰＵ４０はマイク５６をオンし、その後、看護師が焦電センサの前で、手を２回上下させると、マイク５６をオフする。つまり、看護師がマイク５６を用いて発話を記録する場合には、特別な入力スイッチを操作しなくても、このように手を上下させるだけでよく、手が塞がることの多い看護師の業務に配慮している。ただし、入力スイッチを手で操作するようにしてもよいことは勿論である。また、マイク５６をこのように、マイク５６をオン／オフ可能にしてあるのは、看護師のプライバシを守るためである。つまり、勤務時間では、マイク５６はオンされ、休憩時間など勤務時間以外では、マイク５６はオフされる。

インタフェース４８は、ＬＡＮ（無線ＬＡＮ）アダプタのようなインタフェースであり、これにより、センサユニット２０はステーション１８を介してまたは直接にネットワーク１４に接続される。したがって、センサユニット２０は、ネットワーク１４を介して、サーバ１２或いは端末１６のような端末との間で通信可能になる。

ＤＩＰスイッチ５０は、たとえば８ビットで構成され、各ビットのオン／オフを切換えることにより、０〜２５５の間で数値を設定することができる。この数値が看護師の識別情報（看護師ＩＤ）であり、各センサユニット２０で異なる値が設定される。ＣＰＵ４０は、送信するデータに、看護師ＩＤをラベルとして付して、インタフェース４８およびネットワーク１４を介して、サーバ１２に転送する。ここで、送信するデータとしては、音声データ、無線受信機５４で受信したステーションＩＤや看護師ＩＤについてのデータ（たとえば、数値データ）である。

図示は省略したが、看護師ＩＤに対応する看護師名を記述したテーブルデータなどをハードディスクのような内部メモリや看護師用ＤＢ２８に記憶しておけば、サーバ１２は、看護師ＩＤから看護師または看護師名を特定することができ、受信した音声データがどの看護師のものであるかを区別することができる。

なお、この実施例では、ＤＩＰスイッチ５０を用いて看護師ＩＤを設定するようにしてあるが、これに限定されるべきではない。たとえば、ＤＩＰスイッチ５０に代えて、看護師ＩＤを記憶したＲＯＭなどを設けておくようにすることもできる。

無線送信機５２は、ＣＰＵ４０の指示に従って、ＤＩＰスイッチ５０によって設定された看護師ＩＤを所定の周波数による電波（微弱電波）で送信する。無線受信機５４は、無線通信可能な範囲に存在する他のセンサユニット２０から送信される微弱電波を受信し、看護師ＩＤに復調し、復調した看護師ＩＤについてのデータをＣＰＵ４０に入力する。

ここで、ステーション１８は、上述したように、センサユニット２０の看護師ＩＤを検出し、検出した看護師ＩＤに自身のステーションＩＤを付して、ネットワーク１４を介してサーバ１２に送信する。したがって、サーバ１２は、ステーションＩＤが示すステーション１８の設置された場所を、看護師ＩＤが示す看護師の現在位置として知ることができる。なお、サーバ１２は、ステーション１８の設置された場所を、内部メモリ等に、ステーションＩＤに対応づけて記憶してある。また、ステーション１８にも識別情報（ステーションＩＤ）が割り当てられ、上述したように、このステーションＩＤがセンサユニット２０によって検出される。したがって、たとえば、ステーション１８は、センサユニット２０の一部の回路コンポーネントを用いることにより、構成することができる。具体的には、ステーション１８は、ＣＰＵ４０，ＤＩＰスイッチ５０，無線送信機５２および無線受信機５４によって構成される。

なお、ＤＩＰスイッチ５０に代えて、ステーションＩＤを記憶したＲＯＭを設けるようにしてもよい点は、センサユニット２０の場合と同様である。

上述したような構成のセンサユニット２０は、各被験者（看護師）に装着される。たとえば、図４に示すように、非接触センサ４６およびマイク５６以外の回路コンポーネントはボックス（筐体）６０に収容され、ボックス６０は看護師の腰部（ベルト部分）に装着される。また、非接触センサ４６は、ペン型のケースに収容され、看護師の衣服（白衣）の胸ポケットに挿すように収納される。ただし、図面では、分かり易く示すために、ペン型のケースを胸ポケットの外部に記載してある。また、この実施例ではマイク５６は「カチューシャ」様の装着具を用いて看護師の頭部に装着されるが、たとえば、看護師の襟や胸元、ポケットなどに装着するピンマイクであってよい。

なお、図４においては省略するが、非接触センサ４６は接続線を用いてボックス６０内のＣＰＵ４０に接続され、マイク５６は接続線を用いてボックス６０内のエンコーダ４４に電気的に接続される。ただし、接続線を用いずに、ブルートゥースのような近距離無線によって接続するようにしてもよい。つまり、電気的に接続されればよいのである。

また、図４に示すように、看護師は、たとえば、白衣の前ポケットに携帯型のコンピュータ（この実施例では、ＰＤＡ）６２を収納し、所持（携帯）している。図示は省略するが、ＰＤＡ６２は、無線ＬＡＮによって、図１に示したネットワーク１４に接続可能な構成にされる。ＰＤＡ６２は既に周知であるため、その構成および動作等の詳細な説明は省略することにする。なお、図面では、分かり易くするため、前ポケットの外部に示してある。

このようなセンサユニット２０を用いて１人の看護師が記録したかつサーバ１２が看護師用ＤＢ２８に蓄えた音声（発話）データの一例が図５に示される。この図５で、左端の「時刻」はＣＰＵ４０の時計回路４０ａ（図３）で付された時刻データである。「番号」はその看護師の発話イベントの連続番号であるが、欠番が生じているのは、発話が不明瞭であったりノイズが大きかったりして、最終的にサーバ１２がその発話イベントから業務が特定できなかった発話イベントを省いているからである。なお、ev/pの区別は図５に示す注釈のとおりである。

図５の看護師の発話データを参照すれば、その看護師は、午前７時４５分１０秒から勤務を開始し、まず、７時４９分２０秒に、「ａａａ」のＩＤを持つ患者ａａａに対してキャピラリフィッティングテストとドップラーとを継ぎ終わったことがわかる。同様に、７時５１分０３秒から、カルテのチェックを始めたことがわかる。ただし、このとき患者名を入力し忘れているので、次の発話の際に、つまり７時５４分２９秒のタイミングで、カルテチェックが「ｂｂｂ」のＩＤを持つ患者ｂｂｂのカルテのチェックであることを補足している。

７時５５分４３秒から「ｃｃｃ」のＩＤが割り当てられている患者ｃｃｃの（様子または容態）をチェックすることがわかる。ただし、この患者ｃｃｃのチェックについては終了時の発話記録がないので、終了時刻が不明である。しかしながら、次のタイミング、８時００分２７秒から、その看護師は別の業務（３直（勤務シフトの１つの）の看護師から引継ぎを聞くこと）に入っているので、上記患者ｃｃｃの容態チェックは、遅くとも８時００分２７秒までには終了しているものと推定して間違いではない。

８時００分２７秒に３直からの引継ぎを音声入力してから１０分以上音声入力がないので、サーバ１２は、当該看護師のセンサユニットに対して、ネットワーク１４を通して音声入力の督促信号を送信する。それに応じて８時１４分２５秒に「引継ぎ中です。」という発話入力を記録したことが「p」という識別子で理解できる。引継ぎが８時２３分２９秒まで続いている。

８時３１分５７秒にその看護師は耳鼻科診察室の準備を開始し、８時３４分２２秒からその耳鼻科診察室での診察を開始したことがわかる。そして、３回分のサーバ１２からの発話記録の督促に応答して、まず８時４５分２０秒に、ついで８時５６分１８秒に、最後に９時０８分１６秒に、それぞれ、業務内容として「診察中」を記録し、９時０９分３９秒にその耳鼻科診察室での診察が終了し、片付けが始まったことが記録されていることがわかる。

ただし、図５の発話データは単なる例示であり、この発明の看護必要度管理システムは耳鼻科だけでなく、すべての診療科目に対して利用可能なものであることはいうまでもない。

図５に例示したような発話（音声）データをサーバ１２で解析することによって、看護師ごとの業務分析をするが、その場合の動作フローを図６に示す。図６に示す最初のステップＳ１で、サーバ１２は、業務分析をする対象看護師の看護師ＩＤを設定する。続くステップＳ３で、サーバ１２は、看護師用ＤＢ２８の当該看護師ＩＤのタグがつけられた記憶領域から、その看護師ＩＤで特定される看護師のたとえば図５に示すように発話データを読み出す。

そして、サーバ１２は、続くステップＳ５でその読み出した発話データの「音」を切り出し、ステップＳ７で、その「音」を認識して図５の最右欄のような文章に書き起こす。

次のステップＳ９で、サーバ１２は、書き起こした文章を、たとえば、茶筅（チャセンchasen：商品名）で代表されるような言語解析ツールを利用して、言語分析を実行する。「チャセン」を利用する場合であれば、文章から形態素解析を行って、単語を抽出し、その単語の品詞を認識して形態素とする。次のステップＳ１１でサーバ１２は、抽出した形態素に基づいて、そのとき看護師が遂行していた看護業務が何であるか特定する。たとえば、図５の例でいえば、イベント番号２では「キャピラリフィッティングテスト」と「ドップラー」という名詞が抽出できる。そして、このような単語が図２に示す分析用ＤＢ３２に予め設定されているカテゴリテーブル（図示せず）のどのカテゴリに属するかを判定する。実施例の場合、「キャピラリフィッティングテスト」と「ドップラー」はいずれも「持続点滴の管理」というジョブカテゴリに分類できる。また、イベント番号５では「ｃｃｃさんチェックします。」と発話があり、この発話データからは「患者名」と「チェック」という単語が抽出できる。この場合カテゴリテーブルを適用すれば、「（患者の）症状観察」というカテゴリが特定できる。

このようにして、ステップＳ９で抽出した単語を、分析用ＤＢ３２のカテコゴリテーブルに適用することによって、看護師の発話データからそのとき看護師が実行していた看護業務を特定することができる。

次のステップＳ１３で、図５のような発話データから時刻情報を抽出する。この時刻情報の抽出は、当然、ステップＳ１１で特定した「業務」またはカテゴリに関連した時刻情報であり、その特定の看護業務を行うのに要した時間長さを計算するために必要である。たとえば、図５の例でいえば、イベント番号６‐９の音声データからは「引継ぎ」というカテゴリが看護業務として特定できるが、この「引継ぎ」の開始時刻は８時００分２７秒で、終了時刻は厳密には不明である。しかしながら、次のイベント番号１４で、８時３１分５７秒に次の業務に入ったことがわかるので、「引継ぎ」の終了時刻としてこの時刻、８時３１分５７秒を採用してもおかしくはない。そこで、実施例では、開始時刻が不明確なときには、それの直前の発話イベントでの終了時刻の直後（たとえば、１秒後）の時間を、開始時刻と擬制し、終了時刻が不明確なときには、それの直後の発話イベントでの開始時刻の直前（たとえば、１秒前）の時間を、終了時刻と擬制するようにしている。「引継ぎ」で説明すれば、開始時刻は８時００分２７秒として、終了時刻は８時３１分５６秒（８時３１分５７秒の１秒前）として確定できる。

このようにして、ステップＳ１３で、各看護業務の開始時刻および終了時刻、つまり、各業務のために必要な時間（所要時間）を計算することができる。

続くステップＳ１５でサーバ１２は、ステップＳ１１およびＳ１３で特定した看護業務とその継続時間をより詳細に分析する。

図５の発話データの例では明らかではないが、看護師の業務は、同時並行して行われることもある。たとえば、複数の患者が１部屋に入院しているとき、その部屋の中で、１人の患者に対して食事の介助をしている途中に、他の患者の点滴管理をすることは、現実の病院では日常的に発生する事象である。このような重複業務の遂行は、個室の場合でも発生する。重複業務の場合には、看護師は、大抵の場合、先に着手した業務か、あるいは重要な業務か、どれか１つだけを発話登録する。したがって、重複業務は発話データからだけでは把握しきれない。

そこで、実施例では、図２に示す対物センサ２２からのセンサ信号（データ）や集音マイク２４からの音声データ、さらにはビデオカメラ２６からの映像信号（データ）を補助的に利用して、その看護師に重複業務がなかったかどうか見極める。前に説明したように、たとえば、点滴薬液のバーコード検出データが入力されていたとすると、そのときその薬液を操作した看護師の看護師ＩＤもこの検出データと一緒に（タグとして）自動的に読み込まれる。この場合には、発話データから抽出した看護業務以外に「点滴管理」という看護業務が抽出できる。

このように、その看護師ＩＤのタグ付のあらゆるデータを探せば、複数業務の有無がかなりの確立で把握できる。集音マイク２４の音声データにも看護師の名前が入っていることがあり、同様にビデオカメラ２６の映像でも、看護師を特定することができる。したがって、そのような補助データを利用することによって、重複業務を個別に確定することができる。

なお、重複業務の把握だけでなく、発話データが不明なために特定できない不明業務の場合にも、同様の利用方法で、上述の対物センサ２２、集音マイク２４、ビデオカメラ２６からの補助情報を利用できる。

また、たとえば、いずれも図１を参照して先に説明した、看護師端末１６の操作情報、ステーション１８が検知した位置データ、センサユニット２０が発する位置データを、時刻情報とともに、たとえば、患者用ＤＢ３０に登録されている患者ごとの担当看護師名、さらには、看護師のワークフローのデータなどと照合することによって、その看護師はその時刻には特定の患者のための特定の看護業務を遂行していた可能性が極めて高い可能性で予測または推定することができる。つまり、患者データやワークフローさらには看護師の位置データなどを利用することによって、重複業務や不明業務を確定することができる。

さらに、看護師が対象としている、つまり、その看護師が関っている患者が変われば、当然看護業務も変化するものであり、実施例では、看護師の関与している患者の変更を確認できた場合にも、重複業務の有無を確認するようにしている。

このようにして、ステップＳ１５で重複業務および不明業務を確定する。そして、ステップＳ１７で、サーバ１２は、発話データやその他の補助データから確定したすべての看護業務と、それらの継続時間を内部メモリにさらには、看護師用ＤＢ２８に記憶させる。これが看護師データを構成する。

その後、ステップＳ１９で“ＹＥＳ”が判断されるまでステップＳ３‐Ｓ１７を繰り返し実行するとともに、ステップＳ２１で“ＹＥＳ”が得られるまで、ステップＳ２５で看護師ＩＤを更新しながら、ステップＳ１‐Ｓ１９を繰り返し実行する。このようにしてすべての看護師についての看護師データを作成し、ステップＳ２７で、それらを集計するとともに、作図して看護師データを目視によって確認できるようにする。

１人の看護師についての看護師データ図表が図７に示され、それの部分拡大図が図８に示される。図７および図８のいずれでも、縦軸が業務カテゴリであり、横軸が時間で、帯状の幅がそのカテゴリで示される看護業務の継続時間（所要時間）を表している。この図７および図８にはっきり示されているが、同一時間帯で縦軸に重なって示される業務が、先に説明した重複業務である。そして、図７および図８において各看護師業務は、それぞれ異なる模様（ハッチング、塗りつぶしなど）が割り当てられて表現されている。

この看護師データ図表の基礎となる看護師データは、たとえば、表１のように、少なくとも、患者を特定できる情報（患者名、患者ＩＤなど）、その患者に対して遂行した看護師業務（ジョブカテゴリに従う）、さらには、その看護師業務を実行した所要時間を示す時間情報が含まれる。

上述のようにして看護師データが取得された後、図１の実施例の看護必要度管理システム１０では、たとえば、１日の日勤の終了時などの適当なタイミングで、図９に具体的に示す、看護必要度決定処理のプロセスを実行する。

図９を参照して、このプロセスの最初において、サーバ１２は、ステップＳ３１において、看護師用ＤＢ２８に蓄積してある看護師データを読み出して、サーバ１２のワーキングメモリ（ＲＡＭ）にロードされる。続いて、ステップＳ３３で、サーバ３３は、患者ＩＤで示される１人の患者ごとに、当日の看護師データをソーティング（編集）して、ステップＳ３５で患者１人１人の看護業務図を作成する。

図１０に示す患者の看護業務図は、ある患者の手術前日のもので、図１１は同じ患者の手術翌日のものである。いずれも、横軸が時間で、縦軸にその患者に関った看護師ごとの業務カテゴリが、帯状の幅で継続時間を示すように、グラフ表示される。たとえば、図１０では、手術前日であるので、１人の患者に多くの看護師が関与し、かなり多く看護師の「手が掛かっている」ことがわかる。逆に、図１１に示す術後の看護業務図から、この患者の手術は簡単な手術で、したがって、手術翌日であっても看護師の関与量が少ないことがわかる。ただし、図１０および図１１に示す患者ごとの看護業務図を作成し表示することは、看護必要度決定のために必要なものではないが、看護師の業務の内容や軽重に拘わらず、各患者にどの程度看護師が関与し、どの程度の看護量があるのかを一覧でかつ目視によって確認できるという意味では、有用なものである。上記継続時間すなわち図１０などの帯状の幅がその看護業務での所要時間に相当する。

続くステップＳ３７で、たとえば、図１０や図１１に示す看護業務図を基に、患者ごとに、各看護師が関与した「所要時間」の合計（患者合計時間）を計算する。この患者合計時間は、看護師の業務の内容や軽重に拘わらず、看護師が事実として当該患者に関与した時間であるので、客観的な指標である。図１０の患者に対する患者合計時間は、一例として「１３９分」であるのに対し、図１１の同じ患者に対する患者合計時間は「１６分」であった。これは、この患者の手術が軽微で、術後の負担が極端にも軽減されていることを意味している。

このように、ステップＳ３７で患者ごとの患者合計時間を計算した後、ステップＳ３９でサーバ１２は、先に分析用ＤＢ３２（図２）を参照して説明した「係数」を決定する。その決定のためには、たとえば、患者用ＤＢ３０に格納されている患者の属性や手術内容を参照するようにしてもよい。係数は、最大値をたとえば、「１.０」とし最小値をたとえば、「０.１」とする。ただし、その決め方は任意である。

さらに、この「係数」は固定的なものではなく、過去の事例から学習することによって、より患者の実態を反映したものに変更可能である。たとえば、同じ病気の手術であっても、術式によって看護必要度は変化するし、また、病棟（対応する病気）によっても看護必要度は一律ではないので、「係数」はそれらを考慮して決定される。つまり、この実施例の看護必要度管理システム１０を利用すれば、過去のデータ集め、患者の実態により適合した係数を可変的に設定できる。係数を変更するためには、分析用ＤＢ３２（図２）の係数テーブルを書き換えるだけでよい。

さらに、このような看護必要度管理システム１０に電子カルテを利用できるのであれば、電子カルテからより詳細な患者データを取得できるので、患者の実態により一層適合する係数を設定することができる。

そして、続くステップＳ４１で、サーバ１２は、看護必要度を算出する。具体的には、看護必要度は、患者合計時間×係数で示す看護必要度基礎点数に基づいて決定される。図１０の場合、患者合計時間が１３９分であり、係数が０．３（手術前であるため）であるとすると、看護必要度基礎点数は４１．７（＝１３９＊０．３）となる。また、図１１の場合、患者合計時間が１６分であり、係数が０．６（手術翌日のため）とすると、看護必要度基礎点数は９．６（＝1６＊０．６）となる。実施例ではこの看護必要度基礎点数がそのまま看護必要度となるものではなく、分析用ＤＢ３２に設定している看護必要度テーブルに従って換算した看護必要度１‐看護必要度１０のいずれかのランクを看護必要度として決定する。

その後ステップＳ４３で“ＹＥＳ”のとき、すなわち、看護必要度を決定すべき患者がさらに存在するなら、ステップＳ４５で患者ＩＤを更新した後、ステップＳ３３‐Ｓ４３を繰り返し実行する。ただし、ステップＳ４３で“ＮＯ”が判断されたときは、終了する。

なお、上述の実施例では、看護師の発話はマイク５６から取り込まれ、その音声データは、一定時間ごとにセンサユニット２０からサーバ１２すなわち看護師用ＤＢ２８に記憶されるようにした。しかしながら、たとえば、ＩＣレコーダのような独立した録音装置を用いて各看護師の発話を記録し、所定時間ごとまたは勤務終了時にまとめてサーバ１２（看護師用ＤＢ２８）に記録するようにしてもよい。ただし、ＩＣレコーダを用いる場合でも音声データは時刻データ（タイムスタンプ）とともに記録されるものとし、一定時間（たとえば、１０分）以上無録音状態が継続したときはブザー（図示せず）で発話記録を看護師に督促するようにしてもよい。

図１はこの発明の看護必要度管理システムの一実施例の構成を示すブロック図である。 図２は図１に示すサーバの電気的な構成を示すブロック図である。 図３は図1に示すセンサユニットの電気的な構成の一例を示すブロック図である。 図４は図３に示すセンサユニットを看護師が装着した状態の一例を示す図解図である。 図５は看護師（サーバ）が記録した看護師の発話の一例を示す図解図である。 図６は図１の実施例において業務分析をして看護師データを取得するときのサーバの動作を示すフロー図である。 図７は図６の実施例において取得した１人の看護師の看護師データ図表の一例を示す図解図である。 図８は図７の看護師データ図表の一部を拡大して示す図解図である。 図９は図１の実施例において取得した看護師データに基づいて患者の看護必要度を決定するためのサーバの動作を示すフロー図である。 図１０は図９の方法で患者ごとにソーティングした結果の患者の看護業務図の一例を示す図解図である。 図１１は図９の方法で患者ごとにソーティングした結果の患者の看護業務図の他の例を示す図解図である。

符号の説明

１０ …看護必要度管理システム
１２ …サーバ
２０ …センサユニット
２８ …看護師用データベース（ＤＢ）
３０ …患者用データベース（ＤＢ）
４０ …ＣＰＵ
４２ …メモリ
５６ …マイク

Claims (3)

1. 患者を特定できる情報、その患者に看護師が係った所要時間を示す時間情報、およびその時間に行った看護業務を示す情報を含む看護師データを、各看護師について取得する看護師データ取得手段、
   前記看護師データに基づいて特定の患者に対する全ての看護師の前記所要時間を合計して患者合計時間を計算する合計時間計算手段、および
   前記患者合計時間に基づいて前記特定の患者に対する看護必要度を決定する看護必要度決定手段を備える、看護必要度管理システム。
2. 前記看護必要度決定手段は、前記患者合計時間を予め設定されている係数で処理した結果の看護必要度基礎点数に基づいて前記看護必要度を決定する、請求項１記載の看護必要度管理システム。
3. 前記看護必要度決定手段は、看護必要度を看護必要度ランクとして決定する、請求項１または２記載の看護必要度管理システム。

Images