医療用モニタリング方法及びシステム
本発明は、医療用モニタリング方法及びシステム１に関する。さらに本発明は、医療用モニタリングシステム１を制御するコンピュータプログラムにも関する。モニタリングされたデータをより効果的に分析することが可能である改善されたモニタリング技法を提供するために、医療モニタリング方法が提供され、この方法は患者の医療データを取得するステップ、複数のイベントパラメタ１７、１８、１９、２０に関してこの医療データを分析するステップである一方、ユーザ定義可能な複数のトリガ条件１０が前記イベントパラメタ１７、１８、１９、２０の各々に割り当てられている分析するステップ、並びに複数の前記トリガ条件１０が検出される場合、医療コンテクスト情報１５を供給するステップ、及びイベント通知２２を稼動させるステップを有する。言い換えると医療情報だけが供給されるだけでなく、加えて、複数のトリガ条件が検出される場合、イベント通知も稼動する。追加のリアルタイムのイベント通知は、臨床スタッフが患者の臨床状況等に対し直ちに応答することを可能にする。その上、提供される前記イベントに関連する医療コンテクスト情報１５を直接レビューすることができる。これは、臨床スタッフが非常に早い時点で治療を開始することを可能にする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は医療用モニタリング方法及びシステムに関する。さらに本発明は、医療用モニタリングシステムを制御するコンピュータプログラムにも関する。
【０００２】
臨床環境において、患者の状態を観察するための患者用モニターが使用される。患者用モニターの主な機能は、患者の状態の変化を臨床スタッフに通告することである。一般的に、上記患者用モニターにおいて限界警報装置が実装される。これにより、測定がユーザ定義したしきい値を超える場合に警報が稼動する。
【背景技術】
【０００３】
遡及的ドキュメンテーション方法として、患者の医療データ（"エピソード"）を後のレビュー及びドキュメンテーションのためのコンテクスト情報として供給されることが知られている。ある臨床状況（"イベント"）、例えば低血圧が患者のモニタリング中に検出される場合、医療データの供給が実行される。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、モニタリングしたデータをより効果的に分析することが可能である改善された分析技術を提供することである。
【０００５】
本目的は、患者の医療データを取得するステップ、複数のイベントパラメタに関して前記医療データを分析するステップである一方、ユーザ定義可能な複数のトリガ条件が前記イベントパラメタの各々に割り当てられている分析するステップ、並びに複数の前記トリガ条件が検出される場合、医療コンテクスト情報を供給するステップ、及びイベント通知を稼動させるステップを有する医療用モニタリング方法により、本発明に従って達成される。
【０００６】
本発明の目的は、患者の医療データを取得する取得モジュール、複数のイベントパラメタに対して前記医療データを分析する分析モジュールである一方、ユーザ定義可能な複数のトリガ条件が前記イベントパラメタの各々に割り当てられている分析モジュール、医療コンテクスト情報を供給する情報提供モジュール、及び複数の前記トリガ条件が検出される場合、イベント通知を稼動させる通知モジュールを有する医療用モニタリングシステムでも達成される。
【０００７】
本発明の目的は、医療用モニタリングシステムを制御するコンピュータプログラムによっても達成される。このコンピュータプログラムは、コンピュータ命令がコンピュータにおいて行われる場合、複数のイベントパラメタに対して医療データを分析するコンピュータ命令である一方、ユーザ定義可能な複数のトリガ条件が前記イベントパラメタの各々に割り当てられている命令、医療コンテクスト情報を供給するコンピュータ命令、及び複数の前記トリガ条件が検出される場合、イベント通知を稼動させるコンピュータ命令を有する。本発明による技術的効果の必要性は、本発明によるコンピュータプログラムの命令に基づいて実現されることができる。このようなコンピュータプログラムは、例えばＣＤ−ＲＯＭのようなキャリア上に記憶されることも可能であり、またインターネット若しくは他のコンピュータネットワークを介して利用可能とすることも可能である。実行する前に、コンピュータプログラムは、例えばＣＤ−ＲＯＭプレイヤーを用いてキャリアから、又はインターネットからコンピュータプログラムを読み出し、そのプログラムをコンピュータのメモリに記憶させることにより、コンピュータにロードされる。コンピュータはとりわけ、中央処理ユニット（ＣＰＵ）、バスメモリ、例えばＲＡＭ又はＲＯＭ等のようなメモリ手段、フロッピー（登録商標）ディスク又はハードディスクユニット等のような記憶手段、及び入力／出力ユニットを有する。コンピュータは、医療用モニタリングシステムの一部として好ましくは実装される。
【０００８】
本発明の中心となる考えは、医療情報だけが供給されるのではないことである。加えて、複数のトリガ条件が検出される場合、イベント通知も稼動する。言い換えると、定期的な患者のモニタリング中に通知が行われる。これは、リアルタイムのモニタリング、イベント分析及びイベント通知技術を用いて、本発明により達成される。追加のリアルタイムのイベント通知は、臨床スタッフが患者の臨床状況等に対し直ちに応答することを可能にする。その上、供給されるイベントに関連する医療コンテクスト情報を直接レビューすることができる。これは、臨床スタッフが非常に早い時点で治療を開始することを可能にする。
【０００９】
本発明の他の態様によれば、臨床スタッフがその後適切な治療を開始することを可能にする既定の臨床パターンの発生をより早く検出するように、複雑なトリガパターンが設定されることができる。例えば、手術室において、従来のシステムにより提供されるような、後の時点でイベントをレビューする必要が無い。しかしながら、本発明によれば、臨床パターンが発生した場合、直ぐに麻酔医に通知されることができる。本発明は、標準的な患者用モニターを使用して医療データを高い柔軟性で分析することを可能にする。この技術は、外部コンピュータ等を必要としない。ほぼ全ての利用可能な標準的な患者用モニターを使用して実行されることができる。これにより、モニターの変更だけが必要とされる。
【課題を解決するための手段】
【００１０】
本発明のこれら及び他の態様は、従属請求項に規定される以下の実施例に基づいてさらに詳しく説明される。
【００１１】
好ましくは、複数の異なる医療パラメタのデータ、例えば心拍及び血圧のデータは、前記取得モジュールを用いて取得される。ユーザ定義可能な複数のイベントパラメタは、分析モジュール内において好ましくは組み合わされ、１つ以上の条件クラスタ（"イベントグループ"）を形成する。基本的に、何れかの測定がイベントパラメタとして設定されることができる。イベントパラメタをイベントグループに組み合わせることは、分析モジュールにより数値及び又は論理演算、例えばＡＮＤ、ＯＲ、ＮＯＴを用いて好ましくは実行される。
【００１２】
イベントパラメタに割り当てられたトリガ条件が存在する。少なくとも既定数のイベントグループのトリガ条件が検出される場合、通知モジュールを用いてリアルタイムでイベント通知が稼動する。例えば、対応するトリガ条件を持つ最大４つのイベントパラメタ（例えば、心拍、血圧、呼吸、…）は、イベントグループにクラスタ化されることができる。この方法の場合、異なる疾病は、規定のやり方で別々のイベントグループに割り当てられる。言い換えると、イベント監視が設けられ、これは特定の臨床状況を表すイベントグループを規定することが可能である。ユーザはこれらグループについて知ることができ、ユーザはこれらのイベントをレビューすることができる。好ましくは、各イベントに対し、レビュー、記録及び報告されることができるエピソードが取り込まれる。
【００１３】
イベントパラメタ各々に対し、トリガ条件の測定に限定したリストは、ユーザにより提供されるか、又は測定関連の情報から得られる。例えば、トリガ条件は、測定により検出された前のイベントから得られることができる。ユーザ定義したトリガ条件を測定のクラスタに対するトリガの組み合わせの形式で応用することは、単一のイベント条件が個別に警報となる前に対応するイベント通知が稼動する場合、臨床上有利となる。これは、患者の状態が徐々に悪くなる状況において特に有効である。トリガ条件の組み合わせは、分析モジュールにより、数値及び／又は論理演算、例えばＡＮＤ、ＯＲ、ＮＯＴ等を用いて好ましくは再び実行される。
【００１４】
インテリジェントアラート(intelligent alert)を導き出す能力は、警報の量が増大することを必ずしも意味しているのではない。適切な警報低減方法が提供される場合、限られた数の場合に対してのみイベントを知らせることを許可することが可能である。例えばイベント通知は、ある数及び／又はある種類のユーザ定義可能なトリガ条件が同時に、又は分析モジュールを用いて同じ時間期間内において決められる場合、単に通知モジュールにより稼動するだけである。
【００１５】
本発明の他の好ましい実施例によれば、幾つかのイベントグループ、例えば最大６個のイベントグループはユーザにより同時に規定されることができる。好ましくは、各グループは別々に構成される。医療データの分析は、幾つかの異なるイベントグループに対して、分析モジュールにより並行して行われる。言い換えると、取得した医療データは、同時に幾つかのイベントグループのうち幾つかのトリガ条件に対し分析される。各イベントグループは特定の疾病に割り当てられるので、異なるイベントグループを同時に使用することにより、臨床的診断に対応する。多くの場合、臨床医は、患者がどの型の"疾病パターン"にかかっているかを正確には知らない。例えば、敗血症症候群(sepsis syndrome)は、早発型敗血症、敗血症の病気、又は敗血症性ショックに関連している。本発明によれば、これらの疾病の各々に対し、特定のイベントグループが設定されることができる。イベントトリガ条件及びイベント通知に関する高い柔軟性が、臨床医が本発明をほぼ如何なる臨床パターンにも適用することを可能にする。言い換えると、本発明は、鑑別診断用の患者用モニターを使用することを可能にする。
【００１６】
本発明の場合、患者用モニターに組み込まれた全面的にカスタマイズ可能なイベント検出システムが設けられている。前記システムは、このシステムを臨床パターンの特定のニーズに適合させることにより、医学文献における新しい結果に基づいてイベントを検出するように、ユーザが前記モニターを設定することを可能にする。例えば、臨床研究が集中治療室（ＩＣＵ）において早発型敗血症又は敗血症のような病気を検出する際に心拍変動（ＨＲＶ）の重要性を示す場合、適切なトリガ条件及びイベント通知を持つＨＲＶパラメタを用いてイベントグループを設定することがこの臨床状況をモニタリングすることを可能にする。
【００１７】
好ましくは、各測定に対し、例えば心拍又は血圧の測定に対し、複数のトリガ条件、例えばしきい値及びトリガ時間が分析モジュール内に設定される。一般的に、イベントを検出するためのトリガは、低いしきい値及び高いしきい値である。これにより、異なるユーザ定義可能なトリガ条件が用いられる。例えば、固定されたしきい値がトリガ条件として例えば１０秒のトリガ時間中に心拍が１００拍／分より下回る場合、使用されることができる。本発明の他の好ましい実施例によれば、相対的なしきい値は、分析モジュールにより使用される。相対的又は偏差しきい値は、例えば既定の時間期間中の測定の変更により規定される。例えば１０分の時間期間内に心拍が２０％下がる場合、上記相対的なしきい値は超過する。このような相対的なしきい値は単独で、又は他のトリガ型式と組み合わせて使用されることができる。
【００１８】
好ましくは、各イベントに対するトリガ条件は、ユーザ、例えば臨床スタッフにより定義可能である。本発明の好ましい実施例において、トリガ条件は、例えば取得した医療データに依存して動的に適合する。
【００１９】
本発明の他の実施例によれば、イベント通知の種類は、例えば各イベントグループに対しユーザ定義可能である。好ましくは、ユーザが設定可能な意識レベルは、イベント通知に割り当てられることができる。ディスプレイ上のユーザプロンプトの他に、例えば"イベント検出"のような低、中又は高度の優先度の警報の何れか１つを用いてイベントに関して警告する可能性を含んでいる。これにより、患者用モニターに既に実装される警報構造が好ましくは使用される。
【００２０】
好ましくは、各イベントに対し、ユーザは、レビューするためにどの型式の詳細なビューが情報提供モジュールにより供給されるかを規定することができる。情報提供モジュールによりコンテクスト情報（"イベントエピソード"）として供給される情報は、例えば２０分の平均傾向情報若しくは４分の高分解能傾向情報、又は１５分のリアルタイム波のスナップショットを含む。情報提供モジュールは、所望の医療データを取り込み、この医療データを他で使用するためのデータ記憶装置に記憶するのに適する。供給される医療コンテクスト情報は、臨床医に例えば信号イベントのシーケンスを視覚化することを可能にする。例えば、臨床医は、血圧が上がる前に心拍が下がったかを判断することができる。同時に、臨床医はこのイベントが起こった後、測定値がどのように回復するかを見ることができる。
【発明を実施するための最良の形態】
【００２１】
本発明のこれら及び他の態様は、以下の実施例及び付随する図面を参照して以下に詳細に例として説明される。
【００２２】
図１は、例えば病室にいる患者（図示せず）をモニタリングするための医療用モニタリングシステムを説明している。このシステム１は、タッチ式スクリーン又はキーボードのようなユーザ入力装置２、及びモニター又はプリンタのような表示手段３を有する。システム１は、ＣＤ−ＲＯＭ装置のようなソフトウェア入力装置（図示せず）、及び／又はネットワークインタフェースを介してコンピュータネットワークと接続可能である。システム１はさらに、互いに接続されると共に、表示装置３及びユーザ入力装置２にも接続される複数のモジュール４、５、６、７を有する。これらモジュール４、５、６、７は、ハードウェア及び／又はソフトウェアとして実施される。言い換えると、これらモジュール４、５、６、７の機能は、適当なハードウェアに基づく、若しくはコンピュータプログラムの命令に基づくかのどちらか一方、又は両方に基づいて達成されることができる。この目的のために、システム１は、本発明によるコンピュータプログラム命令を実行するコンピュータ手段を有する。
【００２３】
システム１は、第１のステップ１００において、患者の医療データを取得する取得モジュール４を有する。この目的のために、この取得モジュール４は、データリンク８を介して複数のセンサ（図示せず）に接続されている。
【００２４】
さらに、システム１は分析モジュール５を有する。この分析モジュール５は次のステップ１１０において、複数のイベントパラメタ１７、１８、１９、２０に関して医療データを分析する。図４に示されるように、最大４つのイベントパラメタが組み合わされ、イベントグループ９を形成する。本実施例において、最大６つのイベントグループが並行して稼動することできる。各イベントグループは互いに独立して働き、夫々稼動又は非稼動にすることができる。図４に示されるイベントグループ９のイベントパラメタ１７、１８、１９、２０は、心拍（ＨＲ）、ＳｐＯ２（酸素飽和度）、ＡＢＰ（動静脈圧）及びａｗＲＲ（気道呼吸数）である。イベントグループの名前は、イベントグループの設定中にユーザにより選択されることができる。例えば、医師名、部署名又は疾病パターン名が使用されることができる。図４に示されるイベントグループは、"group3"と名付けられている。各イベントグループは設定中、稼動スイッチ２３を用いて稼動及び非稼動にすることができる。本事例において、稼動スイッチ２３は設定マスク(setup mask)における追加の押ボタンとして実装される。
【００２５】
複数のユーザ定義可能なトリガ条件１０が各イベントパラメタ１７、１８、１９、２０に割り当てられている。言い換えると、イベントの検出は、イベントトリガ、イベントパラメタ及びイベントグループからなる階層的システムである。本実施例において、最大６つのイベントグループが用いられている。各イベントグループは最大４つのイベントパラメタからなり、最大２つのトリガ条件１０が各イベントパラメタに割り当てられている。無論、妥当であれば、それより多くのトリガ条件がイベントパラメタに割り当てられることも可能である。トリガ条件１０はユーザにより自由に定義可能であり、図５に示されるようなトリガ条件リスト１１、１２、１３、１４からユーザにより選択されることも可能である。ここで各イベントパラメタ９に対し多数の予め定義したトリガ条件１０が示されている。
【００２６】
主に４つの異なる種類のトリガ、警報トリガ、ユーザ定義したしきい値トリガ、ユーザ定義した偏差トリガ及び"測定中(On Measurement)"トリガがある。警報トリガはパラメタアラームに対し構成される。"中の優先度；ＨＩＧＨ"のような特定の警報トリガ、及び"全て高い優先度の警報"のような不特定の警報トリガがある。不特定の警報は、特定するのが難しい警報全てを含んでいる。ユーザ定義したしきい値トリガは、しきい値及び継続時間に関して定義される。このしきい値が少なくとも特定の継続時間中に超過した場合、このトリガ条件は満たされる。しきい値はパラメタユニットにおいて特定される。しきいトリガはＨＩＧＨ又はＬＯＷ（ＨＲに対し夫々頻脈(TACHY)及び徐脈(BRADY)）とすることができる。ユーザ定義したしきいトリガは、パラメタがその数値を出力している限り、動作している。ユーザ定義した偏差トリガは特定の継続時間中の偏差に関して構成される。この偏差は、相対的（例えば１０％）又は絶対的（１０ｂｐｍ）とすることができる。相対偏差は、％単位（例えばＳｐＯ２）と区別するために"％(dev)"と明記される。ユーザ定義したしきい値トリガを認める全てのイベントパラメタは、偏差トリガに対応している。３つの異なる種類の偏差トリガ、ＡＮＹ偏差（向きに関係無く検出）、ＵＰ偏差（上行性の偏差だけを検出）及びＤＯＷＮ偏差（下行性の偏差だけを検出）が存在する。前記偏差を検出するために、設定される継続時間に依存して異なる分解能の値が使用される。例えば、１０秒から１分の継続時間の場合、１秒のサンプルが用いられる。測定を行う場合、非周期的パラメタはトリガに対し構成されることができる。対応するイベント列は、"測定中(On Measurement)"である。
【００２７】
第１のトリガ条件リスト１１は、患者の心拍データに関連するＮ個のトリガ条件１０を有する。第２のトリガ条件リスト１２は、患者のＡＢＰデータに関連するトリガ条件１０を有する。残りのトリガ条件リスト１３、１４は、ＳｐＯ２及びａｗＲＲ等に対し設けられている。
【００２８】
第１のトリガ条件リスト１１のトリガ条件"１"は、この１０分間に患者の心拍が１００拍／分より下回ったかを判断する。トリガ条件"２"は、この１０分間に患者の心拍が１８０拍／分より上回ったかを判断する。固定のしきい値に代わり、相対的なしきい値がユーザにより又は分析モジュール５を用いて自動に定義される。例えば、トリガ条件"３"は相対的なしきい値として定義される。トリガ条件"３"は、患者の心拍が５分間に２０％下がったかを判断する。第２のトリガ条件リスト１２のトリガ条件"４"は、ＡＢＰ平均値が８０ｍｍＨｇより下回ったかを判断する。第３のトリガ条件リスト１３のトリガ条件"５"は、前記酸素の値が１５秒間に８５％より下回ったかを判断する。第４のパラメタリスト１４のトリガ条件"６"は、ａｗＲＲ値が８ｒｐｍ（１分当りの呼吸数）より下回ったかを判断する。
【００２９】
より進んだトリガ条件リストでは、前記トリガ条件は取得した医療データに依存して動的に作成される。他の実施例において、トリガ条件は前記トリガ条件リストから自動的に選択される。例えば、トリガ条件"１"が判断された場合、トリガ条件"３"は、分析モジュール５を用いて、イベントパラメタＨＲに対し追加の又は新しいトリガ条件として自動的に選択される。
【００３０】
本実施例において、イベントグループ"group3"のイベントパラメタＨＲに対する第１のトリガ条件１０ａは、相対的なしきい値の形式で既に定義され、これは３０秒以内に脈拍が１０％だけ変化したか判断される（図４参照）。このイベントパラメタの第２のトリガ条件は定義されず、空のまま残っている。イベントパラメタＳｐＯ２に対しては、このパラメタに対し定義された何れかの中の又は高い優先度の警報が単一のイベント条件となるトリガ条件１０ｂが設定される。２つのトリガ条件１０ｃ、１０ｄはイベントパラメタＡＢＰに割り当てられる。ここで、中の優先度のＨＩＧＨ警報、すなわち"ＨＩＧＨ"しきい値を越えることによる警報、又は中の優先度のＬＯＷ警報、すなわち"ＬＯＷ"しきい値を超えることによる警報に対する要件が満たされる場合、ＡＢＰ条件が満たされる。言い換えると、トリガ条件１０ｃ、１０ｄは、論理和（ＯＲ）演算により組み合わされる。イベントパラメタａｗＲＲの場合、トリガ条件１０ｅは、何れかの高い又は中の優先度の警報である。
【００３１】
各イベントグループ９のイベントパラメタ１７、１８、１９、２０は、イベントグループトリガ条件１６により組み合わされる。５つの型式のイベントグループトリガ条件１６；"少なくとも１つのパラメタ"、"少なくとも２つのパラメタ"、"少なくとも３つのパラメタ"、"４つのパラメタ全て"及び"高度版"が利用可能である。最初の４つの選択は、イベントグループトリガ条件１６を満たすために、少なくとも前記複数のイベントパラメタ１７、１８、１９、２０がこれらのトリガ条件１０を満たさなければならないことを意味している。高度のイベントグループトリガ条件は、イベントグループの設定中、ユーザが各イベントパラメタ及び各々可能な組み合わせを個々に選択することを可能にする。
【００３２】
イベントグループ"group3"の設定中（図４参照）、ユーザはイベントグループトリガ条件１６を判断する。一般的に、特定のイベントグループトリガ条件１６が満たされる場合、イベントが検出される。これは構成されるエピソードの型式を用いてイベントエピソード（医療コンテクスト情報１５）を取り込み及び記憶することになる。本実施例において、イベントグループトリガ条件"少なくとも２つのパラメタ"が選択されている。この場合、イベントパラメタ１７、１８、１９、２０のうち少なくとも２つの必要なトリガ条件１０が判断される場合、イベント通知２２が稼動し、医療コンテクスト情報１５が供給される。
【００３３】
例えばステップ１２０において、３０秒以内に心拍が１０％だけ変化し（トリガ１０ａ）、同時に中の又は高い優先度のＳｐＯ２警報に対する要件が満たされる（トリガ１０ｂ）ことを検出した場合、イベント通知２２が稼動し、医療コンテクスト情報１５が供給される。この目的のために、システム１は、後続するステップ１３０において医療コンテクスト情報１５を供給する情報提供モジュール６を有する。イベント通知の種類は、イベントグループの設定時にユーザにより定義されることができる。図４に説明されるイベントグループ９に対しては、低い優先度の警報が稼動する。他のイベントグループに対しては、他の種類のイベント通知が選択されることができる。システム１は、ステップ１４０においてイベント通知を稼動させる通知モジュール７を有する。
【００３４】
前記情報提供モジュール６により供給されるべき医療コンテクスト情報１５の型式は、イベントグループの設定中にユーザにより定義されることもできる。本実施例において、医療コンテクスト情報１５は、２０分の平均傾向情報を含む。この情報提供モジュール６は、医療データを取り込み、この医療データを内部のデータ記憶装置（図示せず）に記憶し、このデータを処理し、及び所望の医療コンテクスト情報１５を供給する。
【００３５】
利用可能なエピソード型式２１は、平均傾向、高分解能傾向、及びリアルタイム波である。前記平均傾向は２０分にわたり、傾向データベースから得られた１２秒の分解能を持つ数値平均サンプルを使用する。高分解能傾向は４分にわたり、１秒当り４個のサンプルを使用する。リアルタイム波は１５秒にわたる一方、これら波は１秒当り１２５個のサンプルを減少し、１６ビットから８ビットに減少する。取り込み中、しきい値は固定され、その最大の偏差に対するパラメタが観察される。このいわゆる最大の超過がイベントエピソードと共に記憶される。取り込みはポストタイム(post time)の間続く（図６参照）。ポストタイム中、新しいイベントは検出されない。最後のイベントのポストタイムが終了したらすぐに新しいイベントが検出され、以前に満たされていたトリガ条件は、そのポストタイム後はもはや満たされない。
【００３６】
本発明の他の実施例において、イベント通知は、複数のイベントが同時に検出される場合（"結果として生じるイベント"）にのみ、通知モジュールにより稼動する。
【００３７】
幾つかのイベントグループが供給される場合、トリガ条件１０の判断は、ステップ１１１においてイベントグループ"３"に関するデータ分析の後に行われる。図３に説明されるように、トリガ条件は、ステップ１２１、１２２、１２３、…において検証される。イベントグループのトリガ条件１６が満たされる場合、ステップ１３１において医療コンテクスト情報１５が供給され、イベント通知が稼動する（ステップ１４１）。同時に、ステップ１１２において他のイベントグループ、例えばイベントグループ"４"に関するデータ分析が行われる。対応するトリガ条件１０ｘ、１０ｙ、…は、ステップ１２５、１２６、…において検証される。イベントグループのトリガ条件１６が満たされる場合、ステップ１３２において医療コンテクスト情報１５が供給され、イベント通知が稼動する（ステップ１４２）。"結果として生じるイベント"の場合、この"結果として生じるイベント"の通知は、ステップ１４１、１４２における単一のイベント通知に加えて稼動するのではなく、それに代わって稼動すると定義される。イベントグループの各々が特定の疾病に割り当てられるようにこれらイベントグループが定義される場合、非常に容易な臨床診断が可能である。
【００３８】
供給される医療情報１５の一例が図７に示される。エピソードウィンドウは、イベントが検出された後、ユーザに表されるように示される。イベント時間は"１８：０８"である。イベントグループのうち２つのイベントパラメタに対し、イベント条件が満たされる。４８秒の持続時間を持つ無呼吸がａｗＲＲ値に従って検出される。加えて、ＳｐＯ２値がしきい値の８５％より下回るので、ＬＯＷ警報が発せられる。単一のイベント条件の両方に対する警告標示２４がエピソードと一緒に示され、患者の現在の状態について直ちに医師に知らせる。
【００３９】
本発明は、警報に基づくイベント通知と組み合わされた患者には依存しない偏差しきい値を用いることにより、改善される警報を定義することを可能にする。
【００４０】
本発明が上述した例示的な実施例の詳細に限定されず、本発明の意図又は本質的な特質から外れることなく、本発明が他の特定な形式で具現化されてもよいことは、当業者には明らかである。これにより本実施例は、全てに対し例示的であり、限定的ではないと理解されるべきである。本発明の範囲は、上記説明によるのではなく、特許請求の範囲により示され、請求項の同等の意味及び範囲内における変更の全てはそれに含まれていると意味している。"有する"と言う用語は他の要素又はステップを排除するものではなく、単数での表示は、それが複数あることを排除するものではなく、コンピュータシステム又は他のユニットのような単一の要素は、請求項中に挙げられる幾つかの手段の機能を遂行してもよい。請求項における参照符号は、該当する請求項を制限するとは解釈されない。
【符号の説明】
【００４１】
１ 医療用モニタシステム
２ ユーザ入力装置
３ 表示装置
４ 取得装置
５ 分析装置
６ 情報提供装置
７ 通知装置
８ データリンク
９ イベントグループ
１０ トリガ条件
１１ トリガ条件リスト
１２ トリガ条件リスト
１３ トリガ条件リスト
１４ トリガ条件リスト
１５ 医療コンテクスト情報
１６ イベントグループのトリガ条件
１７ イベントパラメタ
１８ イベントパラメタ
１９ イベントパラメタ
２０ イベントパラメタ
２１ エピソード形式
２２ イベント通知
２３ 稼動スイッチ
２４ 警告標示
【図面の簡単な説明】
【００４２】
【図１】医療モニタリングシステムの概要を示すブロック図。
【図２】医療モニタリング方法を説明するフローチャート。
【図３】並列するイベントグループ分析を用いた方法を説明するフローチャート。
【図４】イベントグループの設定手順を説明するモニター表示。
【図５】ユーザ定義したトリガ条件リストの概略図。
【図６】ユーザ定義したイベント通知リストの概略図。
【図７】供給される医療情報の一例。
【技術分野】
【０００１】
本発明は医療用モニタリング方法及びシステムに関する。さらに本発明は、医療用モニタリングシステムを制御するコンピュータプログラムにも関する。
【０００２】
臨床環境において、患者の状態を観察するための患者用モニターが使用される。患者用モニターの主な機能は、患者の状態の変化を臨床スタッフに通告することである。一般的に、上記患者用モニターにおいて限界警報装置が実装される。これにより、測定がユーザ定義したしきい値を超える場合に警報が稼動する。
【背景技術】
【０００３】
遡及的ドキュメンテーション方法として、患者の医療データ（"エピソード"）を後のレビュー及びドキュメンテーションのためのコンテクスト情報として供給されることが知られている。ある臨床状況（"イベント"）、例えば低血圧が患者のモニタリング中に検出される場合、医療データの供給が実行される。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、モニタリングしたデータをより効果的に分析することが可能である改善された分析技術を提供することである。
【０００５】
本目的は、患者の医療データを取得するステップ、複数のイベントパラメタに関して前記医療データを分析するステップである一方、ユーザ定義可能な複数のトリガ条件が前記イベントパラメタの各々に割り当てられている分析するステップ、並びに複数の前記トリガ条件が検出される場合、医療コンテクスト情報を供給するステップ、及びイベント通知を稼動させるステップを有する医療用モニタリング方法により、本発明に従って達成される。
【０００６】
本発明の目的は、患者の医療データを取得する取得モジュール、複数のイベントパラメタに対して前記医療データを分析する分析モジュールである一方、ユーザ定義可能な複数のトリガ条件が前記イベントパラメタの各々に割り当てられている分析モジュール、医療コンテクスト情報を供給する情報提供モジュール、及び複数の前記トリガ条件が検出される場合、イベント通知を稼動させる通知モジュールを有する医療用モニタリングシステムでも達成される。
【０００７】
本発明の目的は、医療用モニタリングシステムを制御するコンピュータプログラムによっても達成される。このコンピュータプログラムは、コンピュータ命令がコンピュータにおいて行われる場合、複数のイベントパラメタに対して医療データを分析するコンピュータ命令である一方、ユーザ定義可能な複数のトリガ条件が前記イベントパラメタの各々に割り当てられている命令、医療コンテクスト情報を供給するコンピュータ命令、及び複数の前記トリガ条件が検出される場合、イベント通知を稼動させるコンピュータ命令を有する。本発明による技術的効果の必要性は、本発明によるコンピュータプログラムの命令に基づいて実現されることができる。このようなコンピュータプログラムは、例えばＣＤ−ＲＯＭのようなキャリア上に記憶されることも可能であり、またインターネット若しくは他のコンピュータネットワークを介して利用可能とすることも可能である。実行する前に、コンピュータプログラムは、例えばＣＤ−ＲＯＭプレイヤーを用いてキャリアから、又はインターネットからコンピュータプログラムを読み出し、そのプログラムをコンピュータのメモリに記憶させることにより、コンピュータにロードされる。コンピュータはとりわけ、中央処理ユニット（ＣＰＵ）、バスメモリ、例えばＲＡＭ又はＲＯＭ等のようなメモリ手段、フロッピー（登録商標）ディスク又はハードディスクユニット等のような記憶手段、及び入力／出力ユニットを有する。コンピュータは、医療用モニタリングシステムの一部として好ましくは実装される。
【０００８】
本発明の中心となる考えは、医療情報だけが供給されるのではないことである。加えて、複数のトリガ条件が検出される場合、イベント通知も稼動する。言い換えると、定期的な患者のモニタリング中に通知が行われる。これは、リアルタイムのモニタリング、イベント分析及びイベント通知技術を用いて、本発明により達成される。追加のリアルタイムのイベント通知は、臨床スタッフが患者の臨床状況等に対し直ちに応答することを可能にする。その上、供給されるイベントに関連する医療コンテクスト情報を直接レビューすることができる。これは、臨床スタッフが非常に早い時点で治療を開始することを可能にする。
【０００９】
本発明の他の態様によれば、臨床スタッフがその後適切な治療を開始することを可能にする既定の臨床パターンの発生をより早く検出するように、複雑なトリガパターンが設定されることができる。例えば、手術室において、従来のシステムにより提供されるような、後の時点でイベントをレビューする必要が無い。しかしながら、本発明によれば、臨床パターンが発生した場合、直ぐに麻酔医に通知されることができる。本発明は、標準的な患者用モニターを使用して医療データを高い柔軟性で分析することを可能にする。この技術は、外部コンピュータ等を必要としない。ほぼ全ての利用可能な標準的な患者用モニターを使用して実行されることができる。これにより、モニターの変更だけが必要とされる。
【課題を解決するための手段】
【００１０】
本発明のこれら及び他の態様は、従属請求項に規定される以下の実施例に基づいてさらに詳しく説明される。
【００１１】
好ましくは、複数の異なる医療パラメタのデータ、例えば心拍及び血圧のデータは、前記取得モジュールを用いて取得される。ユーザ定義可能な複数のイベントパラメタは、分析モジュール内において好ましくは組み合わされ、１つ以上の条件クラスタ（"イベントグループ"）を形成する。基本的に、何れかの測定がイベントパラメタとして設定されることができる。イベントパラメタをイベントグループに組み合わせることは、分析モジュールにより数値及び又は論理演算、例えばＡＮＤ、ＯＲ、ＮＯＴを用いて好ましくは実行される。
【００１２】
イベントパラメタに割り当てられたトリガ条件が存在する。少なくとも既定数のイベントグループのトリガ条件が検出される場合、通知モジュールを用いてリアルタイムでイベント通知が稼動する。例えば、対応するトリガ条件を持つ最大４つのイベントパラメタ（例えば、心拍、血圧、呼吸、…）は、イベントグループにクラスタ化されることができる。この方法の場合、異なる疾病は、規定のやり方で別々のイベントグループに割り当てられる。言い換えると、イベント監視が設けられ、これは特定の臨床状況を表すイベントグループを規定することが可能である。ユーザはこれらグループについて知ることができ、ユーザはこれらのイベントをレビューすることができる。好ましくは、各イベントに対し、レビュー、記録及び報告されることができるエピソードが取り込まれる。
【００１３】
イベントパラメタ各々に対し、トリガ条件の測定に限定したリストは、ユーザにより提供されるか、又は測定関連の情報から得られる。例えば、トリガ条件は、測定により検出された前のイベントから得られることができる。ユーザ定義したトリガ条件を測定のクラスタに対するトリガの組み合わせの形式で応用することは、単一のイベント条件が個別に警報となる前に対応するイベント通知が稼動する場合、臨床上有利となる。これは、患者の状態が徐々に悪くなる状況において特に有効である。トリガ条件の組み合わせは、分析モジュールにより、数値及び／又は論理演算、例えばＡＮＤ、ＯＲ、ＮＯＴ等を用いて好ましくは再び実行される。
【００１４】
インテリジェントアラート(intelligent alert)を導き出す能力は、警報の量が増大することを必ずしも意味しているのではない。適切な警報低減方法が提供される場合、限られた数の場合に対してのみイベントを知らせることを許可することが可能である。例えばイベント通知は、ある数及び／又はある種類のユーザ定義可能なトリガ条件が同時に、又は分析モジュールを用いて同じ時間期間内において決められる場合、単に通知モジュールにより稼動するだけである。
【００１５】
本発明の他の好ましい実施例によれば、幾つかのイベントグループ、例えば最大６個のイベントグループはユーザにより同時に規定されることができる。好ましくは、各グループは別々に構成される。医療データの分析は、幾つかの異なるイベントグループに対して、分析モジュールにより並行して行われる。言い換えると、取得した医療データは、同時に幾つかのイベントグループのうち幾つかのトリガ条件に対し分析される。各イベントグループは特定の疾病に割り当てられるので、異なるイベントグループを同時に使用することにより、臨床的診断に対応する。多くの場合、臨床医は、患者がどの型の"疾病パターン"にかかっているかを正確には知らない。例えば、敗血症症候群(sepsis syndrome)は、早発型敗血症、敗血症の病気、又は敗血症性ショックに関連している。本発明によれば、これらの疾病の各々に対し、特定のイベントグループが設定されることができる。イベントトリガ条件及びイベント通知に関する高い柔軟性が、臨床医が本発明をほぼ如何なる臨床パターンにも適用することを可能にする。言い換えると、本発明は、鑑別診断用の患者用モニターを使用することを可能にする。
【００１６】
本発明の場合、患者用モニターに組み込まれた全面的にカスタマイズ可能なイベント検出システムが設けられている。前記システムは、このシステムを臨床パターンの特定のニーズに適合させることにより、医学文献における新しい結果に基づいてイベントを検出するように、ユーザが前記モニターを設定することを可能にする。例えば、臨床研究が集中治療室（ＩＣＵ）において早発型敗血症又は敗血症のような病気を検出する際に心拍変動（ＨＲＶ）の重要性を示す場合、適切なトリガ条件及びイベント通知を持つＨＲＶパラメタを用いてイベントグループを設定することがこの臨床状況をモニタリングすることを可能にする。
【００１７】
好ましくは、各測定に対し、例えば心拍又は血圧の測定に対し、複数のトリガ条件、例えばしきい値及びトリガ時間が分析モジュール内に設定される。一般的に、イベントを検出するためのトリガは、低いしきい値及び高いしきい値である。これにより、異なるユーザ定義可能なトリガ条件が用いられる。例えば、固定されたしきい値がトリガ条件として例えば１０秒のトリガ時間中に心拍が１００拍／分より下回る場合、使用されることができる。本発明の他の好ましい実施例によれば、相対的なしきい値は、分析モジュールにより使用される。相対的又は偏差しきい値は、例えば既定の時間期間中の測定の変更により規定される。例えば１０分の時間期間内に心拍が２０％下がる場合、上記相対的なしきい値は超過する。このような相対的なしきい値は単独で、又は他のトリガ型式と組み合わせて使用されることができる。
【００１８】
好ましくは、各イベントに対するトリガ条件は、ユーザ、例えば臨床スタッフにより定義可能である。本発明の好ましい実施例において、トリガ条件は、例えば取得した医療データに依存して動的に適合する。
【００１９】
本発明の他の実施例によれば、イベント通知の種類は、例えば各イベントグループに対しユーザ定義可能である。好ましくは、ユーザが設定可能な意識レベルは、イベント通知に割り当てられることができる。ディスプレイ上のユーザプロンプトの他に、例えば"イベント検出"のような低、中又は高度の優先度の警報の何れか１つを用いてイベントに関して警告する可能性を含んでいる。これにより、患者用モニターに既に実装される警報構造が好ましくは使用される。
【００２０】
好ましくは、各イベントに対し、ユーザは、レビューするためにどの型式の詳細なビューが情報提供モジュールにより供給されるかを規定することができる。情報提供モジュールによりコンテクスト情報（"イベントエピソード"）として供給される情報は、例えば２０分の平均傾向情報若しくは４分の高分解能傾向情報、又は１５分のリアルタイム波のスナップショットを含む。情報提供モジュールは、所望の医療データを取り込み、この医療データを他で使用するためのデータ記憶装置に記憶するのに適する。供給される医療コンテクスト情報は、臨床医に例えば信号イベントのシーケンスを視覚化することを可能にする。例えば、臨床医は、血圧が上がる前に心拍が下がったかを判断することができる。同時に、臨床医はこのイベントが起こった後、測定値がどのように回復するかを見ることができる。
【発明を実施するための最良の形態】
【００２１】
本発明のこれら及び他の態様は、以下の実施例及び付随する図面を参照して以下に詳細に例として説明される。
【００２２】
図１は、例えば病室にいる患者（図示せず）をモニタリングするための医療用モニタリングシステムを説明している。このシステム１は、タッチ式スクリーン又はキーボードのようなユーザ入力装置２、及びモニター又はプリンタのような表示手段３を有する。システム１は、ＣＤ−ＲＯＭ装置のようなソフトウェア入力装置（図示せず）、及び／又はネットワークインタフェースを介してコンピュータネットワークと接続可能である。システム１はさらに、互いに接続されると共に、表示装置３及びユーザ入力装置２にも接続される複数のモジュール４、５、６、７を有する。これらモジュール４、５、６、７は、ハードウェア及び／又はソフトウェアとして実施される。言い換えると、これらモジュール４、５、６、７の機能は、適当なハードウェアに基づく、若しくはコンピュータプログラムの命令に基づくかのどちらか一方、又は両方に基づいて達成されることができる。この目的のために、システム１は、本発明によるコンピュータプログラム命令を実行するコンピュータ手段を有する。
【００２３】
システム１は、第１のステップ１００において、患者の医療データを取得する取得モジュール４を有する。この目的のために、この取得モジュール４は、データリンク８を介して複数のセンサ（図示せず）に接続されている。
【００２４】
さらに、システム１は分析モジュール５を有する。この分析モジュール５は次のステップ１１０において、複数のイベントパラメタ１７、１８、１９、２０に関して医療データを分析する。図４に示されるように、最大４つのイベントパラメタが組み合わされ、イベントグループ９を形成する。本実施例において、最大６つのイベントグループが並行して稼動することできる。各イベントグループは互いに独立して働き、夫々稼動又は非稼動にすることができる。図４に示されるイベントグループ９のイベントパラメタ１７、１８、１９、２０は、心拍（ＨＲ）、ＳｐＯ２（酸素飽和度）、ＡＢＰ（動静脈圧）及びａｗＲＲ（気道呼吸数）である。イベントグループの名前は、イベントグループの設定中にユーザにより選択されることができる。例えば、医師名、部署名又は疾病パターン名が使用されることができる。図４に示されるイベントグループは、"group3"と名付けられている。各イベントグループは設定中、稼動スイッチ２３を用いて稼動及び非稼動にすることができる。本事例において、稼動スイッチ２３は設定マスク(setup mask)における追加の押ボタンとして実装される。
【００２５】
複数のユーザ定義可能なトリガ条件１０が各イベントパラメタ１７、１８、１９、２０に割り当てられている。言い換えると、イベントの検出は、イベントトリガ、イベントパラメタ及びイベントグループからなる階層的システムである。本実施例において、最大６つのイベントグループが用いられている。各イベントグループは最大４つのイベントパラメタからなり、最大２つのトリガ条件１０が各イベントパラメタに割り当てられている。無論、妥当であれば、それより多くのトリガ条件がイベントパラメタに割り当てられることも可能である。トリガ条件１０はユーザにより自由に定義可能であり、図５に示されるようなトリガ条件リスト１１、１２、１３、１４からユーザにより選択されることも可能である。ここで各イベントパラメタ９に対し多数の予め定義したトリガ条件１０が示されている。
【００２６】
主に４つの異なる種類のトリガ、警報トリガ、ユーザ定義したしきい値トリガ、ユーザ定義した偏差トリガ及び"測定中(On Measurement)"トリガがある。警報トリガはパラメタアラームに対し構成される。"中の優先度；ＨＩＧＨ"のような特定の警報トリガ、及び"全て高い優先度の警報"のような不特定の警報トリガがある。不特定の警報は、特定するのが難しい警報全てを含んでいる。ユーザ定義したしきい値トリガは、しきい値及び継続時間に関して定義される。このしきい値が少なくとも特定の継続時間中に超過した場合、このトリガ条件は満たされる。しきい値はパラメタユニットにおいて特定される。しきいトリガはＨＩＧＨ又はＬＯＷ（ＨＲに対し夫々頻脈(TACHY)及び徐脈(BRADY)）とすることができる。ユーザ定義したしきいトリガは、パラメタがその数値を出力している限り、動作している。ユーザ定義した偏差トリガは特定の継続時間中の偏差に関して構成される。この偏差は、相対的（例えば１０％）又は絶対的（１０ｂｐｍ）とすることができる。相対偏差は、％単位（例えばＳｐＯ２）と区別するために"％(dev)"と明記される。ユーザ定義したしきい値トリガを認める全てのイベントパラメタは、偏差トリガに対応している。３つの異なる種類の偏差トリガ、ＡＮＹ偏差（向きに関係無く検出）、ＵＰ偏差（上行性の偏差だけを検出）及びＤＯＷＮ偏差（下行性の偏差だけを検出）が存在する。前記偏差を検出するために、設定される継続時間に依存して異なる分解能の値が使用される。例えば、１０秒から１分の継続時間の場合、１秒のサンプルが用いられる。測定を行う場合、非周期的パラメタはトリガに対し構成されることができる。対応するイベント列は、"測定中(On Measurement)"である。
【００２７】
第１のトリガ条件リスト１１は、患者の心拍データに関連するＮ個のトリガ条件１０を有する。第２のトリガ条件リスト１２は、患者のＡＢＰデータに関連するトリガ条件１０を有する。残りのトリガ条件リスト１３、１４は、ＳｐＯ２及びａｗＲＲ等に対し設けられている。
【００２８】
第１のトリガ条件リスト１１のトリガ条件"１"は、この１０分間に患者の心拍が１００拍／分より下回ったかを判断する。トリガ条件"２"は、この１０分間に患者の心拍が１８０拍／分より上回ったかを判断する。固定のしきい値に代わり、相対的なしきい値がユーザにより又は分析モジュール５を用いて自動に定義される。例えば、トリガ条件"３"は相対的なしきい値として定義される。トリガ条件"３"は、患者の心拍が５分間に２０％下がったかを判断する。第２のトリガ条件リスト１２のトリガ条件"４"は、ＡＢＰ平均値が８０ｍｍＨｇより下回ったかを判断する。第３のトリガ条件リスト１３のトリガ条件"５"は、前記酸素の値が１５秒間に８５％より下回ったかを判断する。第４のパラメタリスト１４のトリガ条件"６"は、ａｗＲＲ値が８ｒｐｍ（１分当りの呼吸数）より下回ったかを判断する。
【００２９】
より進んだトリガ条件リストでは、前記トリガ条件は取得した医療データに依存して動的に作成される。他の実施例において、トリガ条件は前記トリガ条件リストから自動的に選択される。例えば、トリガ条件"１"が判断された場合、トリガ条件"３"は、分析モジュール５を用いて、イベントパラメタＨＲに対し追加の又は新しいトリガ条件として自動的に選択される。
【００３０】
本実施例において、イベントグループ"group3"のイベントパラメタＨＲに対する第１のトリガ条件１０ａは、相対的なしきい値の形式で既に定義され、これは３０秒以内に脈拍が１０％だけ変化したか判断される（図４参照）。このイベントパラメタの第２のトリガ条件は定義されず、空のまま残っている。イベントパラメタＳｐＯ２に対しては、このパラメタに対し定義された何れかの中の又は高い優先度の警報が単一のイベント条件となるトリガ条件１０ｂが設定される。２つのトリガ条件１０ｃ、１０ｄはイベントパラメタＡＢＰに割り当てられる。ここで、中の優先度のＨＩＧＨ警報、すなわち"ＨＩＧＨ"しきい値を越えることによる警報、又は中の優先度のＬＯＷ警報、すなわち"ＬＯＷ"しきい値を超えることによる警報に対する要件が満たされる場合、ＡＢＰ条件が満たされる。言い換えると、トリガ条件１０ｃ、１０ｄは、論理和（ＯＲ）演算により組み合わされる。イベントパラメタａｗＲＲの場合、トリガ条件１０ｅは、何れかの高い又は中の優先度の警報である。
【００３１】
各イベントグループ９のイベントパラメタ１７、１８、１９、２０は、イベントグループトリガ条件１６により組み合わされる。５つの型式のイベントグループトリガ条件１６；"少なくとも１つのパラメタ"、"少なくとも２つのパラメタ"、"少なくとも３つのパラメタ"、"４つのパラメタ全て"及び"高度版"が利用可能である。最初の４つの選択は、イベントグループトリガ条件１６を満たすために、少なくとも前記複数のイベントパラメタ１７、１８、１９、２０がこれらのトリガ条件１０を満たさなければならないことを意味している。高度のイベントグループトリガ条件は、イベントグループの設定中、ユーザが各イベントパラメタ及び各々可能な組み合わせを個々に選択することを可能にする。
【００３２】
イベントグループ"group3"の設定中（図４参照）、ユーザはイベントグループトリガ条件１６を判断する。一般的に、特定のイベントグループトリガ条件１６が満たされる場合、イベントが検出される。これは構成されるエピソードの型式を用いてイベントエピソード（医療コンテクスト情報１５）を取り込み及び記憶することになる。本実施例において、イベントグループトリガ条件"少なくとも２つのパラメタ"が選択されている。この場合、イベントパラメタ１７、１８、１９、２０のうち少なくとも２つの必要なトリガ条件１０が判断される場合、イベント通知２２が稼動し、医療コンテクスト情報１５が供給される。
【００３３】
例えばステップ１２０において、３０秒以内に心拍が１０％だけ変化し（トリガ１０ａ）、同時に中の又は高い優先度のＳｐＯ２警報に対する要件が満たされる（トリガ１０ｂ）ことを検出した場合、イベント通知２２が稼動し、医療コンテクスト情報１５が供給される。この目的のために、システム１は、後続するステップ１３０において医療コンテクスト情報１５を供給する情報提供モジュール６を有する。イベント通知の種類は、イベントグループの設定時にユーザにより定義されることができる。図４に説明されるイベントグループ９に対しては、低い優先度の警報が稼動する。他のイベントグループに対しては、他の種類のイベント通知が選択されることができる。システム１は、ステップ１４０においてイベント通知を稼動させる通知モジュール７を有する。
【００３４】
前記情報提供モジュール６により供給されるべき医療コンテクスト情報１５の型式は、イベントグループの設定中にユーザにより定義されることもできる。本実施例において、医療コンテクスト情報１５は、２０分の平均傾向情報を含む。この情報提供モジュール６は、医療データを取り込み、この医療データを内部のデータ記憶装置（図示せず）に記憶し、このデータを処理し、及び所望の医療コンテクスト情報１５を供給する。
【００３５】
利用可能なエピソード型式２１は、平均傾向、高分解能傾向、及びリアルタイム波である。前記平均傾向は２０分にわたり、傾向データベースから得られた１２秒の分解能を持つ数値平均サンプルを使用する。高分解能傾向は４分にわたり、１秒当り４個のサンプルを使用する。リアルタイム波は１５秒にわたる一方、これら波は１秒当り１２５個のサンプルを減少し、１６ビットから８ビットに減少する。取り込み中、しきい値は固定され、その最大の偏差に対するパラメタが観察される。このいわゆる最大の超過がイベントエピソードと共に記憶される。取り込みはポストタイム(post time)の間続く（図６参照）。ポストタイム中、新しいイベントは検出されない。最後のイベントのポストタイムが終了したらすぐに新しいイベントが検出され、以前に満たされていたトリガ条件は、そのポストタイム後はもはや満たされない。
【００３６】
本発明の他の実施例において、イベント通知は、複数のイベントが同時に検出される場合（"結果として生じるイベント"）にのみ、通知モジュールにより稼動する。
【００３７】
幾つかのイベントグループが供給される場合、トリガ条件１０の判断は、ステップ１１１においてイベントグループ"３"に関するデータ分析の後に行われる。図３に説明されるように、トリガ条件は、ステップ１２１、１２２、１２３、…において検証される。イベントグループのトリガ条件１６が満たされる場合、ステップ１３１において医療コンテクスト情報１５が供給され、イベント通知が稼動する（ステップ１４１）。同時に、ステップ１１２において他のイベントグループ、例えばイベントグループ"４"に関するデータ分析が行われる。対応するトリガ条件１０ｘ、１０ｙ、…は、ステップ１２５、１２６、…において検証される。イベントグループのトリガ条件１６が満たされる場合、ステップ１３２において医療コンテクスト情報１５が供給され、イベント通知が稼動する（ステップ１４２）。"結果として生じるイベント"の場合、この"結果として生じるイベント"の通知は、ステップ１４１、１４２における単一のイベント通知に加えて稼動するのではなく、それに代わって稼動すると定義される。イベントグループの各々が特定の疾病に割り当てられるようにこれらイベントグループが定義される場合、非常に容易な臨床診断が可能である。
【００３８】
供給される医療情報１５の一例が図７に示される。エピソードウィンドウは、イベントが検出された後、ユーザに表されるように示される。イベント時間は"１８：０８"である。イベントグループのうち２つのイベントパラメタに対し、イベント条件が満たされる。４８秒の持続時間を持つ無呼吸がａｗＲＲ値に従って検出される。加えて、ＳｐＯ２値がしきい値の８５％より下回るので、ＬＯＷ警報が発せられる。単一のイベント条件の両方に対する警告標示２４がエピソードと一緒に示され、患者の現在の状態について直ちに医師に知らせる。
【００３９】
本発明は、警報に基づくイベント通知と組み合わされた患者には依存しない偏差しきい値を用いることにより、改善される警報を定義することを可能にする。
【００４０】
本発明が上述した例示的な実施例の詳細に限定されず、本発明の意図又は本質的な特質から外れることなく、本発明が他の特定な形式で具現化されてもよいことは、当業者には明らかである。これにより本実施例は、全てに対し例示的であり、限定的ではないと理解されるべきである。本発明の範囲は、上記説明によるのではなく、特許請求の範囲により示され、請求項の同等の意味及び範囲内における変更の全てはそれに含まれていると意味している。"有する"と言う用語は他の要素又はステップを排除するものではなく、単数での表示は、それが複数あることを排除するものではなく、コンピュータシステム又は他のユニットのような単一の要素は、請求項中に挙げられる幾つかの手段の機能を遂行してもよい。請求項における参照符号は、該当する請求項を制限するとは解釈されない。
【符号の説明】
【００４１】
１ 医療用モニタシステム
２ ユーザ入力装置
３ 表示装置
４ 取得装置
５ 分析装置
６ 情報提供装置
７ 通知装置
８ データリンク
９ イベントグループ
１０ トリガ条件
１１ トリガ条件リスト
１２ トリガ条件リスト
１３ トリガ条件リスト
１４ トリガ条件リスト
１５ 医療コンテクスト情報
１６ イベントグループのトリガ条件
１７ イベントパラメタ
１８ イベントパラメタ
１９ イベントパラメタ
２０ イベントパラメタ
２１ エピソード形式
２２ イベント通知
２３ 稼動スイッチ
２４ 警告標示
【図面の簡単な説明】
【００４２】
【図１】医療モニタリングシステムの概要を示すブロック図。
【図２】医療モニタリング方法を説明するフローチャート。
【図３】並列するイベントグループ分析を用いた方法を説明するフローチャート。
【図４】イベントグループの設定手順を説明するモニター表示。
【図５】ユーザ定義したトリガ条件リストの概略図。
【図６】ユーザ定義したイベント通知リストの概略図。
【図７】供給される医療情報の一例。
【特許請求の範囲】
【請求項１】
−患者の医療データを取得するステップ、
−複数のイベントパラメタに関して前記医療データを分析するステップである一方、ユーザ定義可能な複数のトリガ条件が前記イベントパラメタの各々に割り当てられている分析するステップ、並びに
複数の前記トリガ条件が検出される場合、
−医療コンテクスト情報を供給するステップ、及び
−イベント通知を稼動させるステップ
を有する医療用モニタリング方法。
【請求項２】
複数のイベントパラメタが組み合わされ、イベントグループを形成する請求項１に記載の方法。
【請求項３】
前記医療データの分析は、複数の異なるイベントグループに関して同時に行われる請求項２に記載の方法。
【請求項４】
イベントパラメタに対し、複数のトリガ条件は、数値及び／又は論理演算を用いて組み合わされ、トリガの組み合わせを形成する請求項１に記載の方法。
【請求項５】
偏差しきい値がトリガ条件として用いられる請求項１に記載の方法。
【請求項６】
−前記取得した医療データに依存して動的にトリガ条件を適合させるステップ
をさらに有する請求項１に記載の方法。
【請求項７】
−患者の医療データを取得する取得モジュール、
−複数のイベントパラメタに関して前記医療データを分析する分析モジュールである一方、ユーザ定義可能な複数のトリガ条件が前記イベントパラメタの各々に割り当てられている分析モジュール、並びに
複数の前記トリガ条件が検出される場合、
−医療コンテクスト情報を供給する情報提供モジュール、及び
−イベント通知を稼動させる通知モジュール
を有する医療用モニタリングシステム。
【請求項８】
医療用モニタリングシステムを制御するコンピュータプログラムにおいて、コンピュータ命令がコンピュータにおいて行われる場合、
−複数のイベントパラメタに対して医療データを分析するコンピュータ命令である一方、ユーザ定義可能な複数のトリガ条件が前記イベントパラメタの各々に割り当てられる命令、
−医療コンテクスト情報を供給するコンピュータ命令、及び
−複数の前記トリガ条件が検出される場合、イベント通知を稼動させるコンピュータ命令
を有するコンピュータプログラム。
【請求項１】
−患者の医療データを取得するステップ、
−複数のイベントパラメタに関して前記医療データを分析するステップである一方、ユーザ定義可能な複数のトリガ条件が前記イベントパラメタの各々に割り当てられている分析するステップ、並びに
複数の前記トリガ条件が検出される場合、
−医療コンテクスト情報を供給するステップ、及び
−イベント通知を稼動させるステップ
を有する医療用モニタリング方法。
【請求項２】
複数のイベントパラメタが組み合わされ、イベントグループを形成する請求項１に記載の方法。
【請求項３】
前記医療データの分析は、複数の異なるイベントグループに関して同時に行われる請求項２に記載の方法。
【請求項４】
イベントパラメタに対し、複数のトリガ条件は、数値及び／又は論理演算を用いて組み合わされ、トリガの組み合わせを形成する請求項１に記載の方法。
【請求項５】
偏差しきい値がトリガ条件として用いられる請求項１に記載の方法。
【請求項６】
−前記取得した医療データに依存して動的にトリガ条件を適合させるステップ
をさらに有する請求項１に記載の方法。
【請求項７】
−患者の医療データを取得する取得モジュール、
−複数のイベントパラメタに関して前記医療データを分析する分析モジュールである一方、ユーザ定義可能な複数のトリガ条件が前記イベントパラメタの各々に割り当てられている分析モジュール、並びに
複数の前記トリガ条件が検出される場合、
−医療コンテクスト情報を供給する情報提供モジュール、及び
−イベント通知を稼動させる通知モジュール
を有する医療用モニタリングシステム。
【請求項８】
医療用モニタリングシステムを制御するコンピュータプログラムにおいて、コンピュータ命令がコンピュータにおいて行われる場合、
−複数のイベントパラメタに対して医療データを分析するコンピュータ命令である一方、ユーザ定義可能な複数のトリガ条件が前記イベントパラメタの各々に割り当てられる命令、
−医療コンテクスト情報を供給するコンピュータ命令、及び
−複数の前記トリガ条件が検出される場合、イベント通知を稼動させるコンピュータ命令
を有するコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２００８−５２５０８７（Ｐ２００８−５２５０８７Ａ）
【公表日】平成２０年７月１７日（２００８．７．１７）
【国際特許分類】
【出願番号】特願２００７−５４７７５２（Ｐ２００７−５４７７５２）
【出願日】平成１７年１２月１９日（２００５．１２．１９）
【国際出願番号】ＰＣＴ／ＩＢ２００５／０５４３０９
【国際公開番号】ＷＯ２００６／０６７７２５
【国際公開日】平成１８年６月２９日（２００６．６．２９）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
【公表日】平成２０年７月１７日（２００８．７．１７）
【国際特許分類】
【出願日】平成１７年１２月１９日（２００５．１２．１９）
【国際出願番号】ＰＣＴ／ＩＢ２００５／０５４３０９
【国際公開番号】ＷＯ２００６／０６７７２５
【国際公開日】平成１８年６月２９日（２００６．６．２９）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
[ Back to top ]