医療データを格納し、分析し、取り出すシステムおよび方法
医療患者から取得された生理学的情報を動的ラウンドロビンデータベースに格納することが可能である。パラメータ記述子を用いて、レコード内のパラメータ値を識別することが可能である。パラメータ記述子を変更することによってパラメータ値を動的に更新することが可能であり、これによってデータベースがフレキシブルになる。さらに、データベースで使用するファイルのサイズを、患者の状態に応じて動的に調節することが可能である。特定の実装では、ラウンドロビンデータベースは適応的であることが可能であり、これによって、データベースに格納されるデータの量は、患者の状態および／または信号状態に基づいて適応される。さらに、生理学的監視装置の臨床ネットワークから取得された医療データをジャーナルデータベースに格納することが可能である。医療データは、臨床担当者と１つまたは複数の医療装置との対話に応じて発生する装置イベントと、装置が開始するイベント（アラームなど）とを含むことが可能である。ジャーナルデータベースを分析して、統計を導出することが可能であり、この統計を、臨床担当者および／または病院の能力の向上に用いることが可能である。
【発明の詳細な説明】
【技術分野】
【０００１】
病院、老人ホーム、その他の患者介護施設は、典型的には、施設内の１つまたは複数のベッドサイドに患者監視装置を備えている。患者監視装置は、一般に、医療患者の生理学的パラメータ（血中酸素飽和度、呼吸数など）を取得および分析するためのセンサ、処理機器、ディスプレイなどを備えている。
【背景技術】
【０００２】
臨床担当者（医師、看護師、その他の医療スタッフなど）は、患者監視装置から取得された生理学的パラメータを用いて、病気の診断を行い、治療を処方する。また、臨床担当者は、様々な臨床状況にある患者を、それらの生理学的パラメータに関して監視することにより、患者に対して行っている治療のレベルを上げるかどうかを判断する。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
多くの患者監視装置は、特定の生理学的パラメータが安全閾値を超えたときにアラームをトリガするアラーム機能を備えている。アラームを引き起こす状況としては、たとえば、心拍数や呼吸数の減少、あるいは、低血中酸素飽和度などが挙げられる。アラームにより、臨床担当者は、生命を脅かしうる状況に迅速に対処することが可能である。アラームは、院内の、患者から離れた場所にいる臨床担当者にも、可聴的または可視的に、あるいはネットワーク送信で伝えられる。アラームや他の生理学的情報は、多くの場合、看護師や他の臨床担当者が複数の患者を一度に監視できる中央看護師詰所または同様の場所に送信される。
【課題を解決するための手段】
【０００４】
１つまたは複数の臨床担当者監視詰所と通信している複数の患者監視装置を有する多患者監視環境において、医療患者から取得された生理学的情報を格納する方法が、特定の実施形態では、ネットワークを介して患者監視装置から識別情報を受信するステップであって、患者監視装置は、医療患者につながれた１つまたは複数のセンサから取得された生理学的データを処理するように動作する１つまたは複数の処理装置を有する、前記ステップと、識別情報を受信して、識別情報に少なくとも部分的に基づいて、患者監視装置に対応する第１のパラメータ記述子を取り出すステップであって、各第１のパラメータ記述子は、患者監視装置によって測定可能なパラメータを識別することが可能である、前記ステップと、第１のパラメータ記述子を有するヘッダを有するラウンドロビンデータベース（ＲＲＤＢ）ファイルを作成するステップと、患者監視装置から生理学的データを受信するステップであって、生理学的データは、生理学的データを識別することが可能な第２のパラメータ記述子を有する、前記ステップと、患者監視装置から受信された第２のパラメータ記述子に少なくとも部分的に基づき、ヘッダ内の第１のパラメータ記述子を用いて、生理学的データをＲＲＤＢファイル内のロケーションにマッピングするステップと、を含む。
【０００５】
特定の実施形態では、複数の医療装置から医療データをジャーナルする方法が、臨床ネットワークを介して複数の医療装置からメッセージを受信するステップであって、医療装置は患者監視装置を有し、各患者監視装置は、医療患者につながれた１つまたは複数のセンサから受信される生理学的情報を処理することが可能な１つまたは複数の処理装置を有する、前記ステップと、メッセージを処理して、メッセージのそれぞれに記載された医療イベントを特定するステップであって、医療イベントは、臨床担当者と、医療装置のうちの選択された１つとの対話に応じて発生する第１の装置イベントと、臨床担当者と選択された医療装置との対話がなくても発生する第２の装置イベントと、のうちの１つまたは複数を含む、前記ステップと、１つまたは複数の医療イベントに関する情報を、物理的コンピュータ記憶装置を有するジャーナルデータベースに格納するステップと、医療イベントレポートの要求に対する応答として、ジャーナルデータベースに格納されている医療イベントに関する医療統計を取得するステップと、医療統計を含むレポートを生成するステップと、を含む。
【０００６】
さらに、各種実施形態では、医療患者から取得された生理学的情報のタイプを動的に調節する方法が、医療患者につながれた１つまたは複数のセンサで測定される生理学的信号を処理することが可能な１つまたは複数の処理装置を用いて、患者の１つまたは複数の第１の生理学的パラメータに対応する第１の生理学的データを取得するステップと、第１の生理学的データを、第１の生理学的データの中の１つまたは複数の第１の生理学的パラメータを説明することが可能な第１のパラメータ記述子と自動的に関連付けて、第１の関連付けられた生理学的データを生成するステップと、第１の関連付けられた生理学的データをラウンドロビンデータベースに供給するステップであって、第１のパラメータ記述子は、ラウンドロビンデータベース内の第１の生理学的データを説明することが可能であり、ラウンドロビンデータベースは物理的コンピュータ記憶装置を有する、前記ステップと、医療患者の１つまたは複数の第２の生理学的パラメータに対応する第２の生理学的データを取得するステップと、第２の生理学的データを第２のパラメータ記述子と自動的に関連付けて、第２の関連付けられた生理学的データを生成するステップと、第２の関連付けられた生理学的データをラウンドロビンデータベースに供給するステップと、を含むことが可能である。
【０００７】
医療患者から取得された生理学的情報を格納するシステムの各種実装は、ネットワーク管理モジュールおよびラウンドロビンデータベース（ＲＲＤＢ）コンポーネントを含み、ネットワーク管理モジュールは、ネットワークを介して患者監視装置から識別情報を受信するステップであって、患者監視装置は、医療患者につながれた１つまたは複数のセンサから取得された生理学的データを処理することが可能な１つまたは複数の処理装置を有する、前記ステップと、患者監視装置から生理学的データを受信するステップであって、生理学的データは、生理学的データを識別するように動作する第１のパラメータ記述子を含む、前記ステップと、を行うことが可能であり、ＲＲＤＢコンポーネントは、ネットワーク管理モジュールから識別情報を受信して、識別情報に少なくとも部分的に基づいて、患者監視装置に対応する第２のパラメータ記述子を取り出すステップであって、各第２のパラメータ記述子は、患者監視装置によって測定可能なパラメータを識別することが可能である、前記ステップと、第２のパラメータ記述子を含むヘッダを有するＲＲＤＢファイルを作成するステップと、患者監視装置から受信された第１のパラメータ記述子に少なくとも部分的に基づき、ヘッダ内の第２のパラメータ記述子を用いて、生理学的データをＲＲＤＢファイル内のロケーションにマッピングするステップと、を行うように動作する。
【０００８】
以下、各種実施形態を、添付図面を参照しながら説明する。これらの実施形態は、例としてのみ図示および説明するものであって、本開示の範囲の限定を意図するものではない。各図面において、類似の要素は類似の参照符号を有する。
【図面の簡単な説明】
【０００９】
【図１】臨床ネットワーク環境の実施形態を示すブロック図である。
【００１０】
【図２】図１の臨床ネットワーク環境のより詳細な実施形態を示すブロック図である。
【００１１】
【図３】図１または図２の臨床ネットワーク環境において生理学的データを格納するラウンドロビンデータベースファイルの実施形態を示すブロック図である。
【００１２】
【図４】図３のラウンドロビンデータベースファイルのより詳細な実施形態を示す図である。
【００１３】
【図５Ａ】ラウンドロビンデータベースを用いて生理学的データを格納するプロセスの実施形態を示すフローチャートである。
【図５Ｂ】ラウンドロビンデータベースを用いて生理学的データを格納するプロセスの実施形態を示すフローチャートである。
【図５Ｃ】ラウンドロビンデータベースを用いて生理学的データを格納するプロセスの実施形態を示すフローチャートである。
【００１４】
【図６Ａ】医療イベントをジャーナルデータベースにジャーナルするプロセスの実施形態を示すフローチャートである。
【図６Ｂ】ジャーナルデータベースのデータとラウンドロビンデータベースのデータとを相互に関連付けるプロセスの実施形態を示すフローチャートである。
【００１５】
【図７】図１の臨床ネットワーク環境において患者を監視するためのユーザインターフェースの一例のスクリーンショットである。
【発明を実施するための形態】
【００１６】
特定の実施形態では、生理学的動向データを迅速に格納および取得するシステムおよび方法を提供する。たとえば、医療患者から取得された生理学的情報をラウンドロビンデータベースに格納することが可能である。ラウンドロビンデータベースは、生理学的情報を、一定の時間間隔のレコードの系列として格納することが可能である。パラメータ記述子を用いて、レコード内のパラメータ値を識別することが可能である。パラメータ記述子を変更することによってパラメータ値を動的に更新することが可能であり、これによってデータベースがフレキシブルになる。さらに、データベースで使用するファイルのサイズを、患者の状態に応じて動的に調節することが可能である。
【００１７】
さらに、特定の実施形態では、生理学的監視装置の臨床ネットワークから取得された医療データをジャーナルデータベースに格納またはジャーナルすることが可能である。医療データは、臨床担当者と１つまたは複数の医療装置との対話に応じて発生する装置イベントを含むことが可能である。医療イベントデータは、装置が開始するイベント、たとえばアラームなども含んでよい。ジャーナルデータベースに格納された医療データを分析して、統計や指標を導出することが可能であり、これらを、臨床担当者および／または病院の能力の向上に用いることが可能である。
【００１８】
本明細書で用いている用語「ラウンドロビンデータベース」および「ＲＲＤＢ」は、本来の意味に加えて、本明細書で開示している独自の特性および特徴を有する、改良されたデータベース構造を表すことも可能である。これらの構造を、本明細書では、動的ＲＲＤＢまたは適応ＲＲＤＢと称することもある。
【００１９】
図１は、臨床ネットワーク環境１００の実施形態を示す。臨床ネットワーク環境１００は、多患者監視システム（ＭＭＳ）１２０を含んでおり、ＭＭＳ １２０は、ネットワーク１１０を介して、１つまたは複数の患者監視装置１４０、看護師詰所システム１３０、および臨床担当者端末１５０と通信している。特定の実施形態では、ＭＭＳ １２０は、患者監視装置１４０から取得された生理学的データを看護師詰所システム１３０および／または臨床担当者端末１５０に供給する。さらに、特定の実施形態では、ＭＭＳ １２０は、生理学的情報および医療イベント情報を、後で分析するために格納する。
【００２０】
臨床ネットワーク環境１００のネットワーク１１０は、どの病院、老人ホーム、患者介護センター、その他の臨床現場でも使用されているＬＡＮまたはＷＡＮ、無線ＬＡＮ（「ＷＬＡＮ」）、または他のタイプのネットワークであってよい。説明を簡単にするために、本明細書の以降では、病院の場合について臨床環境を説明するが、本明細書に記載の特徴は、他の臨床現場または臨床設定にも適用可能であることを理解されたい。実装によっては、ネットワーク１１０は、互いに離れていてもよい複数の病院または臨床現場にある装置をインターネットや専用線などで相互接続することが可能である。同様に、臨床ネットワーク環境１００の各種装置１２０、１３０、１４０、および１５０は、（たとえば、複数の病院に）地理的に分散していてよく、同じ場所に（たとえば、１か所の病院に）あってもよい。
【００２１】
患者監視装置１４０は、医療患者につないだセンサで検出される生理学的信号を監視するポイントオブケア（ＰＯＣ）計器などであってよい。患者監視装置１４０は、それらの信号を処理して、様々な生理学的パラメータのうちのいずれかを測定することが可能である。生理学的パラメータの一例が、血中酸素飽和度（ＳｐＯ２）である。後で、生理学的パラメータの他の例を、図２に関して説明する。
【００２２】
患者監視装置１４０は、生理学的情報をＭＭＳ １２０に供給することが可能である。また、患者監視装置１４０は、医療イベント、たとえばアラームなどの情報をＭＭＳ １２０に供給することも可能である。たとえば、生理学的パラメータが正常範囲から外れたことに対する応答として、アラームをトリガすることが可能である。また、センサが患者から外れたプローブオフ状態のような機器障害に関するアラートをアラームに含めることも可能である。後で、医療イベントの他の例を、図２に関して説明する。
【００２３】
各種実施形態では、患者監視装置１４０は、生理学的情報および医療イベントをＭＭＳ １２０に供給する。ＭＭＳ １２０については、後で詳述する。実装によっては、患者監視装置１４０は、この情報のうちの少なくともいくつかを看護師詰所システム１３０および臨床担当者端末１５０に直接供給することが可能である。
【００２４】
看護師詰所システム１３０は、看護師詰所に位置するデスクトップコンピュータ、ラップトップ、ワークステーションなどであってよい。１つの看護師詰所に、１つまたは複数の看護師詰所コンピュータ１３０を配置することが可能である。看護師詰所コンピュータ１３０は、ＭＭＳ １２０（または患者監視装置１４０）から受信した生理学的情報およびアラームデータを受信して表示することが可能である。特定の実施形態では、看護師詰所コンピュータ１３０は、生理学的情報および医療情報が一目でわかる合理化されたビューを提供するグラフィカル・ユーザ・インターフェース（ＧＵＩ）を採用している。後で、このＧＵＩの一例を、図７に関して説明する。
【００２５】
臨床担当者端末１５０は、臨床担当者が使用する任意の様々な端末であってよく、たとえば、ページャ、携帯電話、スマートフォン、携帯情報端末（ＰＤＡ）、ラップトップ、タブレットＰＣ、パーソナルコンピュータなどであってよい。実施形態によっては、臨床担当者端末１５０は、生理学的情報およびアラームを、ＭＭＳ １２０（または患者監視装置１４０）から受信することが可能である。生理学的データおよびアラームデータは、たとえば、アラームに対する応答として、特定の臨床担当者端末１５０に供給されることが可能である。臨床担当者端末１５０は、場合によっては、生理学的パラメータの値および波形を受信することが可能である。
【００２６】
ＭＭＳ １２０は、特定の実施形態では、ハードウェアおよび／またはソフトウェアを有してネットワーク１１０のネットワークトラフィックを管理する１つまたは複数の物理的コンピューティング装置、たとえばサーバなどを含む。このハードウェアおよび／またはソフトウェアは、論理的かつ／または物理的に、機能の異なる、複数の異なるサーバ１２０、たとえば、通信サーバ、Ｗｅｂサーバ、データベースサーバ、アプリケーションサーバ、ファイルサーバ、プロキシサーバなどに分割されていてよい。
【００２７】
ＭＭＳ １２０は、標準化されたプロトコル（ＴＣＰ／ＩＰなど）または独自プロトコルを用いて、患者監視装置１４０、看護師詰所コンピュータ１３０、および臨床担当者端末１５０と通信することが可能である。一実施形態では、患者監視装置１４０がＭＭＳ １２０と接続することを要求した場合、ＭＭＳ １２０は、患者監視装置１４０を認証してから、患者監視装置１４０につながっている患者のコンテキスト情報を患者監視装置１４０に与えることが可能である。コンテキスト情報には、特に、患者デモグラフィ、患者アラーム設定、およびその患者に対する臨床担当者の割り当てを含めることが可能である。参照によりその開示の全体が本明細書に組み込まれている、２００６年１２月４日に出願した米国特許出願第１１／６３３６５６号明細書（件名「Ｐｈｙｓｉｏｌｏｇｉｃａｌ ａｌａｒｍ ｎｏｔｉｆｉｃａｔｉｏｎ ｓｙｓｔｅｍ」）に、コンテキスト情報の例が記載されている。ＭＭＳ １２０は、このコンテキスト情報を、患者入院情報が備えてある看護師詰所システム１３０または他の院内コンピュータシステムから取得することが可能である。
【００２８】
ＭＭＳ １２０は、患者監視装置１４０に接続した時点で、生理学的情報および医療イベントを患者監視装置１４０から受信することが可能である。ＭＭＳ １２０は、生理学的情報およびイベントの少なくとも一部を看護師詰所システム１３０および／または臨床担当者端末１５０に供給することが可能である。たとえば、ＭＭＳ １２０は、複数の患者監視装置１４０に関連する生理学的データおよびアラームを看護師詰所システム１３０に供給することが可能であり、看護師詰所システム１３０では、看護師がそのデータおよび／またはアラームを評価して患者の治療方法を決定することが可能である。同様に、ＭＭＳ １２０は、無線ページ、電子メール、インスタントメッセージなどを臨床担当者端末１５０に送信して、生理学的データおよびアラームを臨床担当者に供給することが可能である。
【００２９】
有利なこととして、特定の実施形態では、ＭＭＳ １２０は、患者監視装置１４０から取得された生理学的情報をラウンドロビンデータベース（ＲＲＤＢ）１２４に格納することが可能である。各種実施形態のＲＲＤＢ １２２は、患者データの迅速な格納および取り出しを容易にする合理化されたデータベース構造を有する。したがって、特定の実施形態では、ＲＲＤＢ １２２を用いて、生理学的動向データを看護師詰所１３０および臨床担当者端末１５０に迅速に供給することが可能である。そこで、たとえば、臨床担当者が患者の特定の時間帯、たとえば、過去１時間の生理学的動向を見たい場合、臨床担当者は、看護師詰所コンピュータ１３０または臨床担当者端末１５０からＭＭＳ １２０に照会することが可能である。その後、ＭＭＳ １２０は、所望の時間帯に対応する生理学的情報をＲＲＤＢ １２２から取得することが可能である。有利なこととして、ＲＲＤＢ １２２は、動向データの取得を高速化することが可能であり、これは、院内監視システムで使用中のリレーショナルデータベースを用いて可能である。後で、ＲＲＤＢ １２２のさらなる利用法および最適化について説明する。
【００３０】
また、特定の実施形態では、ＭＭＳ １２０は、医療イベントの情報をジャーナルデータベース１２４にアーカイブまたは格納する。医療イベントは、患者監視装置１４０、看護師詰所システム１３０、臨床担当者端末１５０などの装置で記録されたイベントを含むことが可能である。特に、医療イベントは、臨床担当者と装置との対話に応じて発生する装置イベント、たとえば、臨床担当者が行うアラームの動作停止を含むことが可能である。また、医療イベントは、臨床担当者と装置との対話がなくても発生する装置イベント、たとえば、アラームそのものを含むことも可能である。後で、医療イベントのさらなる例を、図２に関して説明する。
【００３１】
ＭＭＳ １２０は、ジャーナルデータベース１２４に格納されている医療イベント情報を分析して、医療イベントに関する統計を導出することが可能である。たとえば、ＭＭＳ １２０は、アラームイベントとアラーム動作停止イベントとを分析して、アラームに対する臨床担当者の応答時間を調べることが可能である。これらの統計を用いて、ＭＭＳ １２０は、臨床担当者および／または病院の能力に関するレポートを生成することが可能である。有利なこととして、特定の実施形態では、これらの統計およびレポートを用いて、臨床担当者および病院の能力を向上させることが可能である。
【００３２】
たとえば、特定の状況では、これらのレポートは、患者監視装置１４０に関する問題の原因を病院が見つける助けになるであろう。以下のシナリオ例は、そのようなレポートの潜在的効能を示すことが可能である。ＳｐＯ２のアラームレベルは、傾向として、成人と新生児とで異なる。しかしながら、一部の臨床担当者は、このことを知らずに、新生児のＳｐＯ２監視装置を、成人のアラームレベルを含むように修正してしまうことがある。こうした変更は多くの間違いアラームを引き起こす可能性があり、これによって、臨床担当者は苛立ち、患者監視装置１４０の使用をやめる可能性がある。臨床担当者によるアラーム変更のような医療イベントをジャーナルし、ジャーナルしたデータを分析することにより、臨床担当者が新生児用監視装置のアラーム設定を不適切に調節していたことがわかる可能性がある。このような情報に基づいて、病院は、アラームのリミットを固定したり、臨床担当者をトレーニングしたりするなどの是正措置を講じることが可能である。
【００３３】
図示していないが、臨床ネットワーク環境１００に管理装置を設けてもよい。管理装置は、病院管理者やＩＴ担当者などが操作するコンピューティング装置であってよい。ＩＴ担当者は、管理装置を用いて、たとえば、複数の患者監視装置１４０、看護師詰所システム１３０、およびＭＭＳ １２０に変更を一斉に伝えることが可能である。また、ＩＴ担当者は、管理装置を用いて、サードパーティシステム、たとえば、電子医療記録（ＥＭＲ）システムをＭＭＳ １２０とインターフェースさせることも可能である。たとえば、サードパーティシステムを用いて、複数の監視装置のアラーム設定の変更を管理装置から行うことが可能である。管理者、ＩＴ担当者、および管理装置によって実行されるほとんどのアクションも、ジャーナルデータベース１２４にジャーナルすることが可能である。
【００３４】
図２は、臨床ネットワーク環境２００のより詳細な実施形態を示す。臨床ネットワーク環境２００は、ネットワーク２１０、患者監視装置２４０、看護師詰所システム２３０、ＭＭＳ ２２０、ＲＲＤＢ ２２２、およびジャーナルデータベース２２４を含んでいる。これらのコンポーネントは、図１に関して上述した機能性をすべて備えていることが可能である。説明を簡単にするために、患者監視装置２４０および看護師詰所システム２３０を１つずつ図示した。さらに、図示していないが、上述の臨床担当者端末１５０を臨床ネットワーク環境２００に含めることも可能である。
【００３５】
図示した、患者監視装置２４０の実施形態は、監視モジュール２４２、ＲＲＤＢモジュール２４４、およびジャーナルモジュール２４６を含んでいる。これらのモジュールのそれぞれは、ハードウェアおよび／またはソフトウェアを含んでよい。通信モジュールなどの他のコンポーネントも、図示していないが、様々な実装において、患者監視装置２４０に含めることが可能である。
【００３６】
監視モジュール２４２は、患者につないだ１つまたは複数のセンサで生成される生理学的信号を監視することが可能である。監視モジュール２４２は、それらの信号を処理して、様々な生理学的パラメータのうちのいずれかを測定することが可能である。たとえば、監視モジュール２４２は、脈拍数、プレチスモグラフ波形データ、灌流指数、生体組織の血液成分の値などの生理学的パラメータを測定することが可能である。生体組織の血液成分の値としては、たとえば、動脈血一酸化炭素飽和度（「ＨｂＣＯ」）、メトヘモグロビン飽和度（「ＨｂＭｅｔ」）、総ヘモグロビン（「ＨｂＴ」または「ＳｐＨｂ」）、動脈血酸素飽和度（「ＳｐＯ２」）、分数的動脈血酸素飽和度（「ＳｐａＯ２」）、酸素含量（「ＣａＯ２」）などがある。
【００３７】
さらに、監視モジュール２４２は、呼吸数、吸気時間、呼気時間、吸気対呼気比、吸気流、呼気流、一回換気量、毎分換気量、無呼吸継続時間、呼吸音、ラ音、いびき音、喘鳴、および音量の減少などの呼吸音の変化または空気流の変化を調べるために、音響センサから生理学的情報を取得することが可能である。さらに、場合によっては、監視モジュール２４２は、他の生理学的な音（たとえば、心拍（たとえば、プローブオフ検出の検出に役立つ）、心音（たとえば、Ｓ１、Ｓ２、Ｓ３、Ｓ４、および心雑音）、および心音の変化（たとえば、正常音から雑音への変化、あるいは体液過剰を示す分裂心音）を監視する。さらに、監視モジュール２４２は、心電図検査（ＥＣＧ）および他の多くの生理学的パラメータを介して、患者の電気的心臓活動を監視することが可能である。
【００３８】
実装によっては、患者監視装置１４０は、様々なデータ信頼度指標を測定することも可能であり、たとえば、参照によりその開示の全体が本明細書に組み込まれている米国特許第７０２４２３３号明細書（件名「Ｐｕｌｓｅ ｏｘｉｍｅｔｒｙ ｄａｔａ ｃｏｎｆｉｄｅｎｃｅ ｉｎｄｉｃａｔｏｒ」）に記載されているデータ信頼度指標を測定することが可能である。また、患者監視装置１４０は、灌流指数を測定することも可能であり、たとえば、参照によりその開示の全体が本明細書に組み込まれている米国特許第７２９２８８３号明細書（件名「Ｐｈｙｓｉｏｌｏｇｉｃａｌ ａｓｓｅｓｓｍｅｎｔ ｓｙｓｔｅｍ」）に記載されている灌流指数を測定することが可能である。さらに患者監視装置１４０は、プレチスモグラフ変動指数（ＰＶＩ）を測定することが可能であり、たとえば、参照によりその開示の全体が本明細書に組み込まれている米国特許出願公開第２００８／０１８８７６０号明細書（件名「Ｐｌｅｔｈｙｓｍｏｇｒａｐｈ ｖａｒｉａｂｉｌｉｔｙ ｐｒｏｃｅｓｓｏｒ」）に記載されているＰＶＩを測定することが可能である。本明細書に記載のパラメータは例に過ぎず、他の多くのパラメータも、実施形態によっては使用可能である。
【００３９】
特定の実施形態では、ＲＲＤＢモジュール２４４は、監視モジュール２４２から生理学的情報を受信し、その生理学的情報を、ネットワーク２１０を介してＭＭＳ ２２０に送信する。応答として、後で詳述するように、ＭＭＳ ２２０は、生理学的情報をＲＲＤＢ ２２２に格納することが可能である。有利なこととして、特定の実施形態では、ＲＲＤＢモジュール２４４は、生理学的情報を、パラメータ記述子に関連付けてから、ＭＭＳ ２２０に送信する。パラメータ記述子は、ＲＲＤＢモジュール２４４が、測定された各生理学的パラメータ値に関連付ける識別子であってよい。ＭＭＳ ２２０は、これらのパラメータ記述子を用いて、ＲＲＤＢモジュール２４４から受信した測定済みパラメータのタイプを識別することが可能である。
【００４０】
パラメータ記述子は、マークアップ言語仕様（拡張可能マークアップ言語（ＸＭＬ）仕様など）に従って生成される記述子であってよい。したがって、パラメータ記述子は、測定された生理学的値を囲むタグを含んでよい。これらのタグは、機械可読であっても人間可読であってもよい。たとえば、タグは、数値識別子（たとえば、「００１７」）や記述識別子（「ＳＰＯ２」や「ＳＰＨＢ」など）を含んでよい。各パラメータ記述子に関連付けられたＳｐＯ２センサおよびＳｐＨｂセンサからの生理学的情報の簡単なストリーム例を以下に示す。＜ＳＰＯ２＞９６＜／ＳＰＯ２＞＜ＳＰＨＢ＞１４．１＜／ＳＰＨＢ＞＜ＳＰＯ２＞９７＜／ＳＰＯ２＞＜ＳＰＨＢ＞１４．０＜／ＳＰＨＢ＞（さらに続く）。
【００４１】
一実施形態では、ＲＲＤＢモジュール２４４は、患者監視装置２４０で使用可能な事前定義済みパラメータ記述子のセットを（たとえば、データファイルの形で）格納していることが可能である。これらのパラメータ記述子は、患者監視装置２４０で測定可能な潜在的パラメータに対応してよい。ＲＲＤＢモジュール２４４から送信されるパラメータ記述子は、患者監視装置２４０で測定されるパラメータの特定のサブセットに依存してよい。
【００４２】
その後、患者監視装置２４０が追加の（または別の）パラメータを測定する場合、ＲＲＤＢモジュール２４０は、パラメータ記述子を動的に更新してＭＭＳ ２２０に送信することが可能である。同様に、患者監視装置２４０がいずれかのパラメータの測定を中止する場合、ＲＲＤＢモジュール２４４は、対応するパラメータ記述子の、ＭＭＳ ２２０への送信を中止することが可能である。
【００４３】
また、図示した実施形態では、患者監視装置２４０は、ジャーナルモジュール２４６を含んでいる。ジャーナルモジュール２４０は、患者監視装置２４０に関連する医療イベントを記録することが可能である。そのような医療イベントは、臨床担当者が開始するイベントを含むことが可能であり、たとえば、アラーム設定（たとえば、最大および最小許容パラメータ値）、監視対象パラメータのタイプ、患者監視装置２４０に接続したセンサのタイプなどの変更を含むことが可能である。ジャーナルモジュール２４６は、これらのイベントを記録するために、たとえば、キーロガーなどのように動作して、臨床担当者のボタン押し動作を記録することが可能である。また、ジャーナルモジュール２４６は、センサまたはケーブルが監視装置２４０などに接続されたタイミングを検出する電流感知回路を含むことが可能である。医療イベントには、臨床担当者が開始するイベントではないもの、たとえばアラームやアラートなども含まれてよい。また、管理装置（図示せず）からのイベント、たとえば、ネットワーク２１０経由での、ＥＭＲによるアラーム設定の更新も、医療イベントに含まれてよい。
【００４４】
ジャーナルモジュール２４６は、これらのイベントを、患者監視装置２４０においてローカルにログすることが可能である。さらに、またはイベントをローカルにログする代わりに、ジャーナルモジュール２４６は、イベントに関する情報をＭＭＳ ２２０に送信することが可能である。これを受けてＭＭＳ ２２０は、そのイベント情報をジャーナルデータベース２２４に格納することが可能である。
【００４５】
図示した実施形態では、患者監視クライアント２３２を有する看護師詰所システム２３０を示している。患者監視クライアント２３２は、看護師詰所システム２３０が生理学的情報およびアラーム情報を受信して表示することを可能にする。患者監視クライアント２３２は、ユーザ・インターフェース・モジュール２３４を含んでいる。ユーザ・インターフェース・モジュール２３４は、たとえば、複数の患者監視装置２４０に関連する生理学的情報、患者情報、および医療イベント情報を表示するソフトウェアを含むことが可能である。また、ユーザ・インターフェース・モジュール２３４は、臨床担当者が患者を入退院させたり、装置のアラームリミットを遠隔修正したりすることなどを可能にする。ユーザ・インターフェース・モジュール２３４で生成可能なユーザインターフェースの一例を、後で図７に関して説明する。
【００４６】
患者監視クライアント２３２はさらに、ジャーナルモジュール２３６を含んでいる。ジャーナルモジュール２３６は、患者監視クライアント２３２に関連する医療イベントを記録するソフトウェアを含むことが可能である。たとえば、ジャーナルモジュール２３６は、患者監視クライアント２３２にログインおよびログオフしている臨床担当者、これらのイベントの発生時刻、入院および退院イベント、および他の、臨床担当者のキーストローク、マウスクリック、患者監視クライアント２３２との対話などを記録することが可能である。ジャーナルモジュール２３６は、このイベント情報を看護師詰所システム２３０においてローカルにログしたり、かつ／または、このイベント情報をＭＭＳ ２２０に送信したりすることが可能である。
【００４７】
図示したように、ＭＭＳ ２２０は、ネットワーク管理モジュール２２１、ＲＲＤＢ管理モジュール２２３、およびジャーナル管理モジュール２２５を含むことが可能であり、これらはそれぞれ、１つまたは複数のソフトウェアコンポーネントを含むことが可能である。一実施形態では、ネットワーク管理モジュール２２１は、生理学的情報および医療イベントデータを含むメッセージを患者監視装置２４０から受信する。ネットワーク管理モジュール２２１は、このデータの少なくとも一部を、看護師詰所システム２３０および図１の臨床担当者端末１５０に供給することが可能である。また、ネットワーク管理モジュール２２１は、生理学的情報をＲＲＤＢ管理モジュール２２３に供給し、医療イベントデータをジャーナル管理モジュール２２５に供給することが可能である。
【００４８】
特定の実施形態では、ＲＲＤＢ管理モジュール２２３は、患者監視装置２４０から受信した生理学的情報をＲＲＤＢ ２２２に格納する。患者監視装置２４０が最初にＭＭＳ ２２０に接続されたとき、または別のときに、ＲＲＤＢ管理モジュール２２３は、その患者監視装置２４０に対応する１つまたは複数のＲＲＤＢファイルをＲＲＤＢ ２２２内に作成することが可能である。この１つまたは複数のＲＲＤＢファイルの内容は、患者監視装置２４０のタイプに応じて異なってよく、患者監視装置２４０のシリアル番号、モデル番号、製造元識別子、これらの組み合わせなどによって定義することが可能である。後で、ＲＲＤＢファイルの構造および内容の具体例を、図３および図４に関して説明する。
【００４９】
また、ＲＲＤＢ管理モジュール２２３は、ＲＲＤＢに格納された生理学的動向データを、患者監視装置２４０、看護師詰所システム２３０、および／または臨床担当者端末への送信のためにネットワーク管理モジュール２２１に供給することが可能である。また、ＲＲＤＢ管理モジュール２２３は、ＲＲＤＢ ２２２からの生理学的データを、図６Ｂに関して後述する目的のために、ジャーナル管理モジュール２２５に供給することが可能である。
【００５０】
ジャーナル管理モジュール２２５は、特定の実装では、患者監視装置２４０および看護師詰所システム２３０から医療イベントデータを受信し、このデータをジャーナルデータベース２２４に格納する。一実施形態では、ジャーナルデータベース２２４は、リレーショナルデータベースであるが、他の構造も可能である。イベントデータの各エントリは、それぞれ、イベントの発生時刻を示すタイムスタンプを有することが可能である。このタイムスタンプは、ジャーナルモジュール２４６または２３６、あるいはジャーナル管理モジュール２２５から提供可能である。また、ジャーナル管理モジュール２２５は、医療イベントの発生回数を示すイベントカウンタをジャーナルデータベース２２４に格納することが可能である。たとえば、一定時間内のアラームの発生回数、あるいは、臨床担当者がネットワーク端末に対してログオンまたはログオフした回数をカウントするカウンタを格納することが可能である。
【００５１】
有利なこととして、ジャーナル管理モジュール２２５は、特定の実施形態では、ジャーナルデータベース２２４内の医療データを分析して、臨床担当者および／または病院の能力の統計または指標を算出することが可能である。ジャーナル管理モジュール２２５は、これらの統計にアクセスするためのインターフェースを、看護師詰所システム２３０または別のコンピューティング装置のユーザに提供することが可能である。一実施例では、ジャーナル管理モジュール２２５は、アラームイベントとアラーム動作停止イベントとを分析して、アラームに対する臨床担当者の応答時間を調べることが可能である。ジャーナル管理モジュール２２５はさらに、看護師の昼夜シフトにおける臨床担当者の応答時間を調べることが可能である。ジャーナル管理モジュール２２５は、これらの統計のレポートを生成することによって、たとえば、どのシフトがよりよく機能するかを病院管理者が決定できるようにすることが可能である。
【００５２】
より一般的には、ジャーナル管理モジュール２２５は、ジャーナルデータベース２２４内のデータから導出された様々な統計を分析することにより、臨床担当者および／または病院の能力に関するレポートを生成することが可能である。レポートの一例として、導出された統計に少なくとも部分的に基づいて病院対病院（あるいは看護師詰所対看護師詰所など）の格付けを行う監視レポートカードがある。有利なこととして、病院管理者、臨床担当者などは、臨床担当者および病院の能力を向上させるために、これらの統計やレポートを用いることが可能である。
【００５３】
臨床ネットワーク環境２００の特徴の一部またはすべてを、個々の実施形態に適応させることが可能である。たとえば、ジャーナルモジュール２４６または２３６の一方または両方が、ジャーナル管理モジュール２２５の機能の一部またはすべてを実行してよい。同様に、１つまたは複数のジャーナルデータベース２２４を、患者監視装置２４０および／または看護師ワークステーション２３０に格納してよい。同様に、ＲＲＤＢモジュール２２４は、ＲＲＤＢ管理モジュール２２３の機能の一部またはすべてを実行してよく、ＲＲＤＢ ２２２は患者監視装置２４０に格納可能である。さらに、実装によっては、図１の臨床担当者端末１５０も同様に、ＲＲＤＢおよび／またはジャーナルモジュールを有してよい。他の実施形態では、他の多くの適応、構成、および組み合わせを実施してよい。
【００５４】
図３は、臨床ネットワーク環境、たとえば、臨床ネットワーク環境１００または２００において生理学的データを格納するＲＲＤＢファイル３００の実施形態を示す。特定の実施形態では、ＲＲＤＢファイル３００の構成のおかげで、上述のＭＭＳ １２０または２２０が、生理学的データの格納および取り出しを迅速に行うことが可能である。
【００５５】
特定の実施形態のＲＲＤＢファイル３００は、フラットなファイル構造を有するが、他の構造（リレーショナル構造など）も可能である。一実施形態では、１つのファイル３００が１人の患者に対応するが、１人の患者に対して複数のファイル３００を使用することも可能である。さらに、実装によっては、ファイル３００を複数の患者で共有することが可能である。ＲＲＤＢでは、生理学的情報をファイル３００内のレコード３６２に書き込む。特定の実施形態では、各レコード３６２は、ＲＲＤＢでは１行であるが、レコード３６２は複数行であってもよい。たとえば、各レコード３６２は、１つまたは複数の生理学的パラメータ、波形などの値を表す１つまたは複数の数字を含んでよい。さらに、実施形態によっては、アラームリミットおよび他の情報を各レコード３６２に格納することが可能である。
【００５６】
有利なこととして、特定の実施形態では、様々なレベルの詳細をＲＲＤＢファイル３００に格納することが可能である。たとえば、ファイル３００を、１人の患者に対して、または端末に対して、またはその端末の１つのパラメータまたはテクノロジーに対して、またはパラメータに対応するチャネルに対して、割り当てることが可能である。これらのファイルを割り当てるための基準の例を以下に示す。チャネルは、端末によって測定された値または値のセットであってよい。たとえば、ＳｐＯ２センサの場合は、ＳｐＯ２の読みを取得するために用いる光の中の様々な波長に対応する複数のチャネル、たとえば、赤チャネルおよび赤外（ＩＲ）チャネルがあってよい。他の光センサは、センサで用いる光の各波長ごとに１つのチャネルを有してよい（３つ以上であってよい）。
【００５７】
図２を再度参照すると、患者監視装置２４０のＲＲＤＢモジュール２４４は、先ほど述べたＲＲＤＢファイルの様々なタイプに対応する様々な量の生理学的情報を、ＲＲＤＢ ２２２に供給することが可能である。ＲＲＤＢモジュール２４４は、患者の健康状態に少なくとも部分的に基づいて詳細レベルを選択することが可能である。たとえば、患者の健康状態が比較的良い場合、ＲＲＤＢモジュール２４４は、ＲＲＤＢ ２２２に送信する情報の量を少なくすることが可能である。一方、患者の健康状態が比較的良くない場合（たとえば、病状が重い場合）、ＲＲＤＢモジュール２４４は、より細かい生理学的情報をＲＲＤＢ ２２２に送信することが可能である。また、他の実施形態では、ＲＲＤＢモジュール２４４は、他の要因、たとえば、生理学的信号の雑音の程度、信号の変動性などに基づいて、ＲＲＤＢ ２２２に送信する生理学的情報の量を適応させることも可能である。
【００５８】
より具体的に述べると、実施形態によっては、ＲＲＤＢモジュール２４４は、患者ごとに単一ファイルを開くことを、ＲＲＤＢ管理モジュール２２３に命令することが可能である。このファイルは、その患者につないだ各装置の比較的高レベルの詳細を含むことが可能である。患者の健康状態が比較的良い場合には、この設定で十分であろう。患者の健康状態が良くない場合、ＲＲＤＢモジュール２４４は、その患者につないだ各装置ごとに単一ファイルを作成することを、ＲＲＤＢ管理モジュール２２３に命令することが可能である。これらのファイルのそれぞれは、患者ごとの単一ファイルより詳細であることが可能である。さらに、健康状態がより悪い場合には、ＲＲＤＢモジュール２４４は、患者監視装置２４０で測定される各パラメータごとにファイルを作成すること、またはセンサの各チャネルごとにファイル（これはセンサからのローデータを含んでよい）を作成することを、ＲＲＤＢ管理モジュール２２３に命令することが可能である。このように、患者の健康状態が悪化した場合には、より多くの詳細を供給することが可能である。
【００５９】
ＲＲＤＢモジュール２４４は、ＲＲＤＢ ２２２に送信するデータの量および／またはＲＲＤＢ ２２２にデータを送信する頻度を、患者の健康状態に基づいて動的に調節することが可能である。一例として、患者のＳｐＨｂレベルが安全レベルを下回った場合（たとえば、アラームリミットから外れた場合）、ＲＲＤＢモジュール２４４は、より詳細な生理学的情報をＲＲＤＢ ２２２に送信すること、または、より頻繁に生理学的情報を送信することが可能である。ＲＲＤＢ管理モジュール２２３は、追加の詳細を受信すると、その、より詳細な生理学的情報を格納するために、新しいファイルを作成することが可能である。患者のＳｐＨｂが正常に戻れば、ＲＲＤＢモジュール２４４は、ＲＲＤＢ ２２２に送信する詳細のレベルを下げることが可能である。そして、ＲＲＤＢ管理モジュール２２３は、新しいファイルを作成して、その下がったレベルの詳細を格納すること、または既に作成されている低レベル詳細ファイルを使用することが可能である。このように、特定の実施形態では、ＲＲＤＢモジュール２４４およびＲＲＤＢ管理モジュール２２３は、ＲＲＤＢファイルの記憶領域の適応制御を行うことが可能である。したがって、特定の実施形態では、ＲＲＤＢを、適応ＲＲＤＢまたは動的ＲＲＤＢと見なすことができる。
【００６０】
さらに、特定の実施形態では、ＲＲＤＢモジュール２４４は、生理学的データの複数のストリームをＲＲＤＢ ２２２に送信することが可能である。異なるストリームが異なる細かさの生理学的データを有することが可能であり、ＲＲＤＢ ２２２内の別々のファイルに格納可能である。たとえば、生理学的データの各ストリームは、１つまたは複数のチャネルの生理学的情報を含むことが可能である。各ストリームは、ＲＲＤＢ ２２２内の１つまたは複数のファイルに対応可能である。
【００６１】
図３を再度参照すると、ＲＲＤＢは、所定の数のレコード３６２をファイル３００に格納することが可能である。ＲＲＤＢは、ファイル３００内の最後のレコード３６２ａにデータを書き込んだ後、自動的に最初のレコード３６２ｂにループバックしてレコード３６２ｂを上書きする。これが、「ラウンドロビン」という用語の所以である。レコード３６２は、図においてΔｔで示されている一定の（たとえば、等しい）時間間隔で格納可能である。各レコード３６２をＲＲＤＢに格納する際に、レコード３６２にタイムスタンプを付けることが可能である。したがって、Δｔは、任意の連続する２つのレコード３６２のタイムスタンプ値の差を表すことが可能である。代替として、ファイル３００のヘッダ部（図４を参照）が、ファイル３００に新しい値が記録された時刻を書き取らせる、あらかじめ定義された時間ステップを含むことが可能である。場合によっては、患者監視装置が、（たとえば、患者の健康状態が良いため）データの監視を中止したか、データの記録を不要と判断したことにより、データをＲＲＤＢに送信しないことがある。患者監視装置がデータ送信を中止した場合でも時間間隔構造が維持されるように、ファイル３００の１つまたは複数のレコード３６２に、生理学的情報の代わりに、ゼロまたは他の非データ値（たとえば、「ｎｏｔ ａ ｎｕｍｂｅｒ（非数）」の意味のＮａＮ）を格納することが可能である。
【００６２】
ファイル３００からレコード３６２を読み出す場合、先行のｋ個のレコード（たとえば、ｋΔｔ）のように、ｋ個のレコードを取得することをポインタなどに命令することが可能である。たとえば、先頭のｋ個のレコード３６２を取得する場合は、ＲＲＤＢ管理モジュール２２３（たとえば）がｋ個のレコード３６２を読み出す間に、ファイルポインタを、最新のｋ個のレコード３６２にわたって進めることが可能である。レコード３６２の任意の一部分を取得することが可能である（たとえば、最新のレコード３６２の一部分、さらにはレコード３６２のすべて）。さらに、レコード３６２の複数部分を読み出すことも可能である。たとえば、複数のパラメータのうちの特定のパラメータの値を、先行のｋ個のレコード３６２から読み出すことが可能である。
【００６３】
有利なこととして、ＲＲＤＢからは、リレーショナルデータベースに比べて桁違いの速さでレコード３６２を取得することが可能である。たとえば、一実施形態では、データベースの検索を、０次検索（ｚｅｒｏ−ｏｒｄｅｒ ｓｅａｒｃｈ）として実行することが可能である。したがって、医療情報動向を、臨床担当者端末、看護師詰所コンピュータなどへ迅速にストリーミングまたは別の方法で供給することが可能である。実装によっては、アラームの送信に関してＪＣＡＨＯ（Ｊｏｉｎｔ Ｃｏｍｍｉｓｓｉｏｎ ｏｎ ｔｈｅ Ａｃｃｒｅｄｉｔａｔｉｏｎ ｏｆ Ｈｅａｌｔｈｃａｒｅ Ｏｒｇａｎｉｚａｔｉｏｎｓ）から公布されたいくつかの規格に準拠するのに十分な速さで生理学的情報を読み取って臨床担当者端末に送信するように、ＲＲＤＢを構成することが可能である。したがって、たとえば、アラームの発生から５秒以内にアラームを臨床担当者に送信することが規格で要求されている場合は、アラーム通知とともに動向データを５秒以内に臨床担当者端末に提供するように、ＲＲＤＢを構成することが可能である。
【００６４】
図４は、ＲＲＤＢファイル４００のより詳細な実施形態を示す。ＲＲＤＢファイルは、ヘッダ４１０および複数のレコード４２０を含んでいる。ヘッダ４１０は、ＲＲＤＢ管理モジュール２２３が、たとえば、ファイル４００の読み書きや検索を行うために使用可能なデータを含んでいる。図示した実施形態では、ヘッダ４１０内の各フィールドをＸＭＬタグで示している。これは一実装に過ぎず、別の実施形態では変形可能である。
【００６５】
図示したヘッダ例４１０のフィールドは、開始時刻、終了時刻、ステップ間隔、パラメータ数、およびパラメータリストを含んでいる。図示した実施形態では、開始時刻および終了時刻を秒数で測定している（たとえば、Ｕｎｉｘ（登録商標） ｅｐｏｃｈ（１９７０年１月１日）からの秒数）。ステップ間隔（図示した実施形態では３０秒）は、レコード４２０をファイル４００に書き込む頻度を示している。パラメータ数（この例では７）は、監視されている生理学的パラメータの数を示している。パラメータリストは、監視されているパラメータに対応するパラメータ記述子のリストを含んでいる。ヘッダ４１０内の各フィールドは、ＲＲＤＢ管理モジュール２２３によって調節可能である。特定の実施形態では、含まれるフィールドの数は、これより多くても少なくてもよい。
【００６６】
図示した実施形態の各レコード４２０は、区切り記号（この例ではスペース）で区切られたパラメータ値を含む単一行である。たとえば、先頭のレコード４２０にあるパラメータ値は、９６、５５、８．９、１４、１４．１、０．５、および１．０である。これらの値は、ヘッダ４１０のパラメータリストにあるパラメータ記述子の順番に対応する。すなわち、値９６は、ＳＰＯ２パラメータ記述子に対応し、値５５は、ＢＰＭ（ビート毎分）パラメータ記述子に対応する。その他の値も同様である。
【００６７】
有利なこととして、特定の実施形態では、ヘッダ４１０のパラメータリストがパラメータ記述子を含むため、個々のレコード４２０にパラメータ記述子を含めることなく、レコード４２０を書き込むことが可能である。結果として、特定の実装では、ファイル４００は、パラメータ記述子をレコード４２０に含めた場合より、サイズを小さくすることが可能である。
【００６８】
図５Ａ〜図５Ｃは、ＲＲＤＢを用いて生理学的データを格納するプロセス５００の実施形態を示す。図５Ａは、生理学的データをＲＲＤＢに供給するプロセス５００Ａの一実施形態を示している。一実施形態では、プロセス５００Ａは、上述のどのＭＭＳによっても（たとえば、ＭＭＳ １２０または２２０によって）実装可能である。具体的には、プロセス５００Ａは、図２のＲＲＤＢ管理モジュール２２３によって実装可能である。代替として、少なくともいくつかのブロックは、患者監視装置２４０のＲＲＤＢモジュール２４４によって実装可能である。有利なこととして、特定の実施形態では、プロセス５００Ａは、臨床ネットワークを介してＭＭＳと通信する患者監視装置に対してＲＲＤＢファイルを作成することを可能にする。
【００６９】
ブロック５０２では、患者監視装置から識別情報を受信する。識別情報としては、たとえば、患者監視装置のシリアル番号、患者監視装置のモデル番号、患者監視装置の製造元、患者監視装置の１つまたは複数の相手先ブランド製造者（ＯＥＭ）モジュールの識別情報、これらの組み合わせなどが可能である。
【００７０】
ブロック５０４では、識別情報に少なくとも部分的に基づいて、患者監視装置に対応するパラメータ記述子を取り出す。各患者監視装置に対応するパラメータ記述子は、ＭＭＳ １２０または２２０上のファイルに格納可能である。たとえば、患者監視装置のシリアル番号ごとに一式の潜在的パラメータ記述子を格納することが可能であり、これらの記述子は、それぞれの患者監視装置で処理可能な潜在的パラメータに対応する。特定の実施形態では、パラメータ記述子は、拡張可能マークアップ言語（ＸＭＬ）記述子または同様のものである。
【００７１】
ブロック５０６では、識別されたパラメータ記述子を有するヘッダを持つＲＲＤＢファイルを作成する。ＲＲＤＢファイルのヘッダについては、既に、図４に関してその例を説明した。パラメータ記述子は、たとえば、図４に示したパラメータリストに挿入することが可能である。したがって、所与の患者監視装置に対応するパラメータリストは、ＲＲＤＢ管理モジュール２２３によって決定可能である。図５Ｂに関して後述するように、パラメータリストは、少なくとも部分的には、患者監視装置によって決定可能であってもよい。
【００７２】
ブロック５０８では、患者監視装置から生理学的データを受信する。ブロック５１０では、ヘッダを用いて、生理学的データをＲＲＤＢファイル内のロケーションにマッピングする。このマッピングは、少なくとも部分的には、図４に関して上述したような、データ内の記述子を用いて行うことが可能である。
【００７３】
図５Ｂは、生理学的データをＲＲＤＢに供給するプロセス５００Ｂの別の実施形態を示す。このプロセス５００Ｂは、患者監視装置（たとえば、１４０または２４０）によって実装可能である。具体的には、ＲＲＤＢモジュール２４４は、プロセス５００Ｂのいくつかのブロックを実行することが可能である。代替として、少なくともいくつかのブロックは、患者監視装置２４０のＲＲＤＢモジュール２４４によって実装可能である。有利なこととして、特定の実施形態では、プロセス５００Ｂは、患者監視装置で監視されるパラメータの変化に基づいてＲＲＤＢファイルを動的に作成することを可能にする。
【００７４】
ブロック５１２では、患者の１つまたは複数の生理学的パラメータに対応する生理学的データを取得する。このブロックは、上述の監視モジュール２４２で実行可能である。ブロック５１４では、パラメータ記述子を生理学的データに関連付けて、関連付けられた生理学的データを生成する。この関連付けは、ＲＲＤＢモジュール２４４によって実行可能である。この関連付けは、一実施形態では、生理学的データにＸＭＬタグを挿入することによって行うことが可能である。ブロック５１６では、関連付けられた生理学的データをＲＲＤＢに供給する。
【００７５】
この関連付けられた生理学的データが送信されると、一実施形態では、ＭＭＳが、生理学的データ内で識別されたパラメータ記述子を有するＲＲＤＢファイルを作成することが可能である。代替として、ＭＭＳは、上述のプロセス５００Ａに従ってＲＲＤＢファイルをあらかじめ作成しておくことが可能である。
【００７６】
判定ブロック５１８では、別の生理学的パラメータが測定されたかどうかを判定する。別の生理学的パラメータが測定された場合は、ブロック５１９で、別のパラメータ記述子を生理学的データに関連付け、ブロック５２０で、関連付けられた生理学的データを再度ＲＲＤＢに供給する。ブロック５１８〜５２０は、ＲＲＤＢモジュール２４４によって実装可能である。一例として、ブロック５１２で測定したパラメータに、ＳｐＯ２およびＥＣＧが含まれるとする。ブロック５１４で与えられるパラメータ記述子は、「ＳＰＯ２」および「ＥＣＧ」である。ブロック５１８で、臨床担当者が監視装置でのＳｐＨｂパラメータ測定を有効化した場合、ブロック５１９で生理学的データに関連付けられたパラメータ記述子は、「ＳＰＯ２」と「ＥＣＧ」と「ＳＰＨＢ」とを含むことになる。
【００７７】
この新しく関連付けられた生理学的データがブロック５２０で送信されると、ＭＭＳは、生理学的データ内で識別された新しいパラメータ記述子を有する新しいＲＲＤＢファイルを作成することが可能である。このように、患者監視装置は、ＲＲＤＢに供給される生理学的データおよび関連付けられた記述子を動的に調節することが可能である。
【００７８】
図５Ｃは、患者監視装置に対応するＲＲＤＢ記憶領域を動的に調節するプロセス５００Ｃの実施形態を示す。一実施形態では、プロセス５００Ｃは、上述のどのＭＭＳによっても（たとえば、ＭＭＳ １２０または２２０によって）実装可能である。具体的には、プロセス５００Ｃは、ＲＲＤＢ管理モジュール２２３によって実装可能である。代替として、少なくともいくつかのブロックは、患者監視装置２４０のＲＲＤＢモジュール２４４によって実装可能である。
【００７９】
図３に関して上述したように、ＲＲＤＢファイルのサイズをあらかじめ決定して、増えないようにすることが可能である。このようにサイズを一定にすると、生理学的動向データの記憶量をあらかじめ決定することが可能である。ＲＲＤＢファイルのサイズは、たとえば、患者が入院した時点で構成可能である。一例として、ＲＲＤＢのサイズが、７２時間分のデータに対応するとする。しかしながら、病状が重い患者の場合は、追加の動向データが必要になる可能性がある。ところが、ＲＲＤＢファイルが一定サイズであると、この例の７２時間が経過した後は動向データが上書きされる。有利なこととして、特定の実施形態では、プロセス５００Ｃは、追加の動向データをＲＲＤＢに書き込むことを可能にしている。したがって、特定の実施形態では、ＲＲＤＢを、適応ＲＲＤＢまたは動的ＲＲＤＢと見なすことができる。
【００８０】
ブロック５３２では、ＲＲＤＢファイルの初期サイズを割り当てる。初期ファイルのサイズは、患者の予定入院期間、患者の現在の健康状態などに基づいて選択可能である。代替として、すべての患者について、ファイルサイズをあらかじめ定義することも可能である。ブロック５３４では、患者監視装置から受信した生理学的データを分析して、患者の病状の重さを判定する。患者の病状の重さを判定するには、たとえば、患者のプレチスモグラフの変動性に対応する、患者のＰＶＩを分析する。ＰＶＩまたは変動性が高い患者については、追加の動向データが有用になる。病状の重さを判定する際に検討可能な他の値として、（上述のとおりに組み込まれている米国特許第７０２４２３３号明細書に記載の）データ信頼度指標、脈拍数、ＳｐＯ２変動性、および他の任意の生理学的パラメータの変形形態などがある。さらに、実施形態によっては、複数アラームまたは重篤アラームの履歴があれば病状が重いことを意味するように患者のアラーム履歴を評価することによって、病状の重さを判定することが可能である。
【００８１】
判定ブロック５３６で、患者の病状が著しく重いかどうかを判定する。患者の病状が著しく重い場合は、ブロック５３８で、ＲＲＤＢデータ用の追加の記憶領域を割り当てる。この初期記憶領域の割り当ては、新規ファイルを作成することなどではなく、ＲＲＤＢファイルの長さを拡張することによって可能である。一方、患者の病状が著しくは重くない場合、プロセス５００Ｃは終了する。
【００８２】
図６Ａは、医療イベントをジャーナルデータベースにジャーナルするプロセス６００Ａの実施形態を示す。一実施形態では、プロセス６００Ａは、上述のどのＭＭＳによっても（たとえば、ＭＭＳ １２０または２２０によって）実装可能である。具体的には、プロセス６００Ａは、ジャーナル管理モジュール２２５によって実装可能である。代替として、少なくともいくつかのブロックは、ジャーナルモジュール２３６、２４６によって実装可能である。有利なこととして、特定の実施形態では、プロセス６００Ａは、ジャーナルデータに基づいてレポートを生成することを容易にする。
【００８３】
ブロック６０２では、医療イベントをジャーナルデータベースにジャーナルする。ブロック６０４では、ユーザ（たとえば、臨床担当者）からレポートが要求されると、医療イベントに関する統計をジャーナルデータベースから取得する。この統計に含まれるのは、医療イベントのタイプ、頻度、継続時間、そのイベントに関連する臨床担当者または患者の識別情報、アラーム応答時間、これらの組み合わせなどである。
【００８４】
ブロック６０６で、医療イベント統計に関するレポートを生成する。ブロック６０８で、そのレポートを用いて、病院業務の改善の可能性がある領域をつきとめる。たとえば、レポートは、病院または病院の臨床担当者に対し、その能力に応じたスコアを割り当てる「監視レポートカード」であってよい。
【００８５】
図６Ｂは、ジャーナルデータベースのデータとＲＲＤＢのデータとを互いに関連付けるプロセス６００Ｂの実施形態を示す。一実施形態では、プロセス６００Ｂは、上述のどのＭＭＳによっても（たとえば、ＭＭＳ １２０または２２０によって）実装可能である。具体的には、プロセス６００Ｂは、ＲＲＤＢモジュール２２３およびジャーナル管理モジュール２２５によって実装可能である。代替として、少なくともいくつかのブロックは、ＲＲＤＢモジュール２４４およびジャーナルモジュール２３６、２４６によって実装可能である。有利なこととして、特定の実施形態では、プロセス６００Ｂは、ＲＲＤＢの生理学的情報と、医療イベントとを、時間的に相互に関連付けることを可能にする。このような、イベントと生理学的データとの再構築は、航空機の「ブラックボックス」技術のように、医療インシデントに至った臨床アクションをユーザが再生できるようにすることが可能である。
【００８６】
ブロック６０２では、ある期間に対応する、ジャーナルされた生理学的データをレビューする要求をユーザから受信する。ユーザは、患者の健康管理における問題の原因を探ろうとする臨床担当者、病院管理者などであってよい。たとえば、ユーザは、患者のＳｐＯ２が安全レベルを下回ったときに臨床担当者が対応できなかった理由を探ろうとすることが可能である。
【００８７】
ブロック６０４で、指定の期間に対応するジャーナルされたデータをジャーナルデータベースから取り出す。このブロックは、ジャーナル管理モジュール２２５によって実行可能である。ブロック６０６で、指定の期間に対応する生理学的データをＲＲＤＢから取り出す。このブロックは、ＲＲＤＢ管理モジュール２２３によって実行可能である。ブロック６０８では、ジャーナルデータと、生理学的データとを、時間に関して相互に関連付ける。この相互の関連付けは、タイムライン上の正しい時間シーケンスにおいて与えられた生理学的パラメータの値（必要に応じて波形を含む）に対して、医療イベントのタイムラインを再構築することを含むことが可能である。実施形態によっては、この、ＲＲＤＢ管理モジュール２２３とジャーナル管理モジュール２２５との間の調整を容易にするために、各データベース２２２、２２４のタイムスタンプを、データの格納時に同期させることが可能である。
【００８８】
ブロック６１０では、相互に関連付けられたデータを、ユーザへの表示のために出力する。この出力は、たとえば、生理学的情報の上に重ねられた、医療イベントのグラフィカルビュー（たとえば、波形）などであってよい。この相互に関連付けられたデータに対して、様々な表示形式が使用可能である。
【００８９】
図７は、患者を監視するためのグラフィカル・ユーザ・インターフェース（ＧＵＩ）７００の一例を示す。ＧＵＩ ７００は、看護師詰所システムなどに設けることが可能である。ＧＵＩ ７００を、臨床担当者端末上に表示させることも可能である。
【００９０】
ＧＵＩ ７００には、いくつかの表示領域がある。図示した実施形態では、ＧＵＩ ７００は、患者状態表示領域７１０を含んでいる。患者状態表示領域７１０は、院内または別の臨床場所にいる複数の患者の状態を示す。一実施形態では、患者状態表示領域７１０は、一診療科の患者の患者状態を表示する。有利なこととして、特定の実施形態では、患者状態表示領域７１０は、複数の患者の健康状態が「一目でわかる」ビューを提供する。
【００９１】
患者状態表示領域７１０は、複数の患者状態モジュール７１２を含んでいる。各患者状態モジュール７１２は、医療患者につなぐことが可能な患者監視装置に対応することが可能である。各患者状態モジュール７１２は、グラフィカル状態インジケータ７１４を表示することが可能である。画面７００では、グラフィカル状態インジケータ７１４の一例を、小さな患者監視装置アイコンで示している。グラフィカル状態インジケータ７１４は、患者監視装置の複数の状態のうちの１つを選択的に示すことが可能である。一実施形態では、グラフィカル状態インジケータ７１４は、患者監視装置の４つの可能な状態を示すことが可能である。これらには、アラーム状態、非アラーム状態、患者状況情報状態、および接続状態が含まれる。
【００９２】
様々な実装において、グラフィカル状態インジケータ７１４は、色、形状、その他を変化させて、患者監視装置の様々な状態のうちの１つを示す。たとえば、アラーム状態が存在する場合、グラフィカル状態インジケータ７１４は、赤色になってアラームを示すことが可能である。患者に関して使用可能な状況情報がない場合（図１を参照）、グラフィカル状態インジケータ７１４は、黄色に変わることが可能である。患者監視装置が患者またはネットワークにつながっていない場合、グラフィカル状態インジケータ７１４は、灰色に変わることが可能である。非アラーム状態であって、状況情報があり、患者監視装置が患者およびネットワークにつながっている場合、グラフィカル状態インジケータ７１４は、緑色に変わることが可能である。上述の実施形態の代わりに（または上述の実施形態との組み合わせで）、他の様々な色、シンボル、および／または形状を用いることが可能である。
【００９３】
有利なこととして、グラフィカル状態インジケータ７１４は、患者監視装置の状態を、一目でわかるように表示する。したがって、患者状態表示領域７１０においては、複数の患者に対応する複数のグラフィカル状態インジケータ７１４が、これらの患者に対応する患者監視装置についての一目でわかるビューを表示する。これにより、アラーム、接続状態、および状況情報に関して患者が持っているニーズを、臨床担当者は容易に知ることが可能である。
【００９４】
現行の看護師詰所コンピュータ用のグラフィカル・ユーザ・インターフェースは、各患者ごとに複数の波形または変化する生理学的パラメータの数字を表示する傾向がある。このような、患者情報の表示方式は、状況によっては、詰め込み過ぎで見にくく、混乱を招き、眠気すら誘う可能性がある。たとえば、夜間シフトで勤務中の看護師は、ディスプレイ上で他の複数の患者のインジケータの数字や波形などが変化している中でアラームに集中することが困難な場合がある。これに対し、本明細書に記載のグラフィカルインターフェースでは、グラフィカル状態インジケータ７１４がアラーム状態を示すと、このアラーム状態は、目立つように表示されて、臨床担当者にただちに認識されることが可能である。
【００９５】
さらに、グラフィカル状態インジケータ７１４によって、看護師が行うことが多い最初のレベルの分析が簡略化される。現行の装置では、多くの場合、看護師は、看護師詰所で波形を分析して患者の健康状態を判定しなければならない。これに対し、画面７００を用いた場合、看護師は、患者の波形または変化するパラメータを解釈する必要がまったくなく、アラームの有無を示すグラフィカル状態インジケータ７１４を頼りにすることが可能である。
【００９６】
特定の実施形態では、１回のマウスクリックまたは同様の操作で患者状態モジュール７１２を選択することが可能である。一実施形態では、患者状態モジュール７１２を選択することにより、患者監視装置ビュー領域７２０を表示することが可能である。患者監視装置ビュー領域７２０は、選択された患者状態モジュール７１２に対応する患者監視装置のビューを表示する。特定の実装では、患者監視装置ビュー領域７２０は、患者のベッドサイドにある実際の患者監視装置の画面のビューを表示することが可能である。これにより、臨床担当者は、患者の生理学的パラメータを、見慣れた表示形式で容易に認識することが可能である。図７の患者監視装置ビュー領域７２０は、患者から生理学的情報を受信している様子を示している。
【００９７】
特定の実装では、履歴ビュー領域７３０が、選択された患者監視装置状態モジュール７１２に対応する医療イベントデータを表示することが可能である。この医療イベントデータは、ジャーナルデータベースから取得して、ＧＵＩ ７００に含めることが可能である。履歴ビュー領域７３０は、たとえば、いつセンサを患者につないだか、またはいつ患者から外したか、いつアラームがアクティブだったか、患者がいつ病院または診療科に入院したか、などを表示することが可能である。図示していないが、履歴ビュー領域７３０は、ジャーナルされたデータの代わりに、または、ジャーナルされたデータに加えてＲＲＤＢから取得した動向データを表示するようにも構成可能である。
【００９８】
実施形態によっては、本明細書に記載のすべての方法におけるいくつかのアクション、イベント、またはファンクションは、別のシーケンスで実行したり、追加したり、マージしたり、まとめて除去したりすることが可能である（たとえば、記載したアクションまたはイベントのすべてが本方法の実施に必須というわけではない）。さらに、特定の実施形態では、複数のアクションまたはイベントを、順次実行するのではなく、同時に実行することが可能であり、これは、たとえば、マルチスレッド処理、割り込み処理、あるいは複数のプロセッサにより可能である。
【００９９】
本明細書で開示した実施形態に関連して記載した、各種の例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両者の組み合わせとして実装可能である。このハードウェアとソフトウェアとの互換性を明確に示すために、各種の例示的なコンポーネント、ブロック、モジュール、回路、およびステップを、主にそれらの機能性の観点から説明してきた。そのような機能性をハードウェアとして実装するか、ソフトウェアとして実装するかは、個々の用途、およびシステム全体に課せられた設計制約によって決まる。記載した機能性は、個々の用途ごとに様々な様式で実装可能であるが、そのような実装の決定は、本開示の範囲からの逸脱を引き起こすものと解釈されてはならない。
【０１００】
本明細書で開示した実施形態に関連して記載した、各種の例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブル論理素子、ディスクリートゲートまたはトランジスタ論理、ディスクリートハードウェア部品、または、本明細書に記載の機能を実行するように設計された、これらの任意の組み合わせにより、実装または実行が可能である。汎用プロセッサはマイクロプロセッサであってよいが、代替として、汎用プロセッサは、任意の従来型プロセッサ、コントローラ、マイクロコントローラ、または状態機械であってもよい。プロセッサは、コンピューティング装置同士の組み合わせ（たとえば、ＤＳＰとマイクロプロセッサとの組み合わせ）、複数のマイクロプロセッサ、ＤＳＰコアと組み合わされた１つまたは複数のマイクロプロセッサ、または他の任意のそのような構成として実装することも可能である。
【０１０１】
本明細書で開示した実施形態に関連して記載した方法またはアルゴリズムの各ステップは、ハードウェアの形で、またはプロセッサで実行されるソフトウェアモジュールの形で、あるいは両者の組み合わせの形で直接実施可能である。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、または他の任意の、当該技術分野では周知の形式の記憶媒体に常駐可能である。プロセッサが記憶媒体から情報を読み出したり、記憶媒体に情報を書き込んだりできるように、プロセッサに例示的記憶媒体を接続している。代替として、記憶媒体は、プロセッサと一体であってもよい。プロセッサおよび記憶媒体は、ＡＳＩＣに組み込まれてよい。ＡＳＩＣは、ユーザ端末内にあってよい。代替として、プロセッサおよび記憶媒体は、ユーザ端末内にディスクリート部品として存在してよい。
【０１０２】
本明細書で用いている条件付き語句（特に「ｃａｎ」、「ｃｏｕｌｄ」、「ｍｉｇｈｔ」、「ｍａｙ」、「ｅ．ｇ．，」など）は、特に断らない限り、あるいは、用いられている文脈で他の解釈がない限り、一般に、いくつかの実施形態では特定の特徴、要素、および／またはステップを含み、他の実施形態では含まない、ということを意味するものとする。したがって、このような条件付き語句は、１つまたは複数の実施形態において、特徴、要素、および／またはステップが何らかの形で必須であること、または、これらの特徴、要素、および／またはステップが任意の個々の実施形態において含まれるかもしくは実行されるべきであるかどうかを、作成者入力またはプロンプティングの有無にかかわらず、判定する論理を、１つまたは複数の実施形態が必ず含むことを意味することを一般に意図するものではない。
【０１０３】
ここまでの詳細説明において、新規な特徴を、各種実施形態に適用する形で図示し、説明し、指摘してきたが、例示した装置またはプロセスの形態および細部において様々な省略、置換、および変更を、本開示の趣旨から逸脱することなく行うことが可能であることが理解されよう。認識されるように、本明細書に記載の、本発明の特定の実施形態は、本発明で説明した特徴および利点のすべてを提供するわけではない形態で実施可能であり、これは、いくつかの特徴が、他の特徴とは切り離して利用または実践することが可能であるためである。本発明の範囲は、前述の説明によってではなく、添付の特許請求の範囲によって示されている。特許請求の範囲の等化物の意味および範囲に含まれるすべての変更は、特許請求の範囲に含まれるものとする。
【技術分野】
【０００１】
病院、老人ホーム、その他の患者介護施設は、典型的には、施設内の１つまたは複数のベッドサイドに患者監視装置を備えている。患者監視装置は、一般に、医療患者の生理学的パラメータ（血中酸素飽和度、呼吸数など）を取得および分析するためのセンサ、処理機器、ディスプレイなどを備えている。
【背景技術】
【０００２】
臨床担当者（医師、看護師、その他の医療スタッフなど）は、患者監視装置から取得された生理学的パラメータを用いて、病気の診断を行い、治療を処方する。また、臨床担当者は、様々な臨床状況にある患者を、それらの生理学的パラメータに関して監視することにより、患者に対して行っている治療のレベルを上げるかどうかを判断する。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
多くの患者監視装置は、特定の生理学的パラメータが安全閾値を超えたときにアラームをトリガするアラーム機能を備えている。アラームを引き起こす状況としては、たとえば、心拍数や呼吸数の減少、あるいは、低血中酸素飽和度などが挙げられる。アラームにより、臨床担当者は、生命を脅かしうる状況に迅速に対処することが可能である。アラームは、院内の、患者から離れた場所にいる臨床担当者にも、可聴的または可視的に、あるいはネットワーク送信で伝えられる。アラームや他の生理学的情報は、多くの場合、看護師や他の臨床担当者が複数の患者を一度に監視できる中央看護師詰所または同様の場所に送信される。
【課題を解決するための手段】
【０００４】
１つまたは複数の臨床担当者監視詰所と通信している複数の患者監視装置を有する多患者監視環境において、医療患者から取得された生理学的情報を格納する方法が、特定の実施形態では、ネットワークを介して患者監視装置から識別情報を受信するステップであって、患者監視装置は、医療患者につながれた１つまたは複数のセンサから取得された生理学的データを処理するように動作する１つまたは複数の処理装置を有する、前記ステップと、識別情報を受信して、識別情報に少なくとも部分的に基づいて、患者監視装置に対応する第１のパラメータ記述子を取り出すステップであって、各第１のパラメータ記述子は、患者監視装置によって測定可能なパラメータを識別することが可能である、前記ステップと、第１のパラメータ記述子を有するヘッダを有するラウンドロビンデータベース（ＲＲＤＢ）ファイルを作成するステップと、患者監視装置から生理学的データを受信するステップであって、生理学的データは、生理学的データを識別することが可能な第２のパラメータ記述子を有する、前記ステップと、患者監視装置から受信された第２のパラメータ記述子に少なくとも部分的に基づき、ヘッダ内の第１のパラメータ記述子を用いて、生理学的データをＲＲＤＢファイル内のロケーションにマッピングするステップと、を含む。
【０００５】
特定の実施形態では、複数の医療装置から医療データをジャーナルする方法が、臨床ネットワークを介して複数の医療装置からメッセージを受信するステップであって、医療装置は患者監視装置を有し、各患者監視装置は、医療患者につながれた１つまたは複数のセンサから受信される生理学的情報を処理することが可能な１つまたは複数の処理装置を有する、前記ステップと、メッセージを処理して、メッセージのそれぞれに記載された医療イベントを特定するステップであって、医療イベントは、臨床担当者と、医療装置のうちの選択された１つとの対話に応じて発生する第１の装置イベントと、臨床担当者と選択された医療装置との対話がなくても発生する第２の装置イベントと、のうちの１つまたは複数を含む、前記ステップと、１つまたは複数の医療イベントに関する情報を、物理的コンピュータ記憶装置を有するジャーナルデータベースに格納するステップと、医療イベントレポートの要求に対する応答として、ジャーナルデータベースに格納されている医療イベントに関する医療統計を取得するステップと、医療統計を含むレポートを生成するステップと、を含む。
【０００６】
さらに、各種実施形態では、医療患者から取得された生理学的情報のタイプを動的に調節する方法が、医療患者につながれた１つまたは複数のセンサで測定される生理学的信号を処理することが可能な１つまたは複数の処理装置を用いて、患者の１つまたは複数の第１の生理学的パラメータに対応する第１の生理学的データを取得するステップと、第１の生理学的データを、第１の生理学的データの中の１つまたは複数の第１の生理学的パラメータを説明することが可能な第１のパラメータ記述子と自動的に関連付けて、第１の関連付けられた生理学的データを生成するステップと、第１の関連付けられた生理学的データをラウンドロビンデータベースに供給するステップであって、第１のパラメータ記述子は、ラウンドロビンデータベース内の第１の生理学的データを説明することが可能であり、ラウンドロビンデータベースは物理的コンピュータ記憶装置を有する、前記ステップと、医療患者の１つまたは複数の第２の生理学的パラメータに対応する第２の生理学的データを取得するステップと、第２の生理学的データを第２のパラメータ記述子と自動的に関連付けて、第２の関連付けられた生理学的データを生成するステップと、第２の関連付けられた生理学的データをラウンドロビンデータベースに供給するステップと、を含むことが可能である。
【０００７】
医療患者から取得された生理学的情報を格納するシステムの各種実装は、ネットワーク管理モジュールおよびラウンドロビンデータベース（ＲＲＤＢ）コンポーネントを含み、ネットワーク管理モジュールは、ネットワークを介して患者監視装置から識別情報を受信するステップであって、患者監視装置は、医療患者につながれた１つまたは複数のセンサから取得された生理学的データを処理することが可能な１つまたは複数の処理装置を有する、前記ステップと、患者監視装置から生理学的データを受信するステップであって、生理学的データは、生理学的データを識別するように動作する第１のパラメータ記述子を含む、前記ステップと、を行うことが可能であり、ＲＲＤＢコンポーネントは、ネットワーク管理モジュールから識別情報を受信して、識別情報に少なくとも部分的に基づいて、患者監視装置に対応する第２のパラメータ記述子を取り出すステップであって、各第２のパラメータ記述子は、患者監視装置によって測定可能なパラメータを識別することが可能である、前記ステップと、第２のパラメータ記述子を含むヘッダを有するＲＲＤＢファイルを作成するステップと、患者監視装置から受信された第１のパラメータ記述子に少なくとも部分的に基づき、ヘッダ内の第２のパラメータ記述子を用いて、生理学的データをＲＲＤＢファイル内のロケーションにマッピングするステップと、を行うように動作する。
【０００８】
以下、各種実施形態を、添付図面を参照しながら説明する。これらの実施形態は、例としてのみ図示および説明するものであって、本開示の範囲の限定を意図するものではない。各図面において、類似の要素は類似の参照符号を有する。
【図面の簡単な説明】
【０００９】
【図１】臨床ネットワーク環境の実施形態を示すブロック図である。
【００１０】
【図２】図１の臨床ネットワーク環境のより詳細な実施形態を示すブロック図である。
【００１１】
【図３】図１または図２の臨床ネットワーク環境において生理学的データを格納するラウンドロビンデータベースファイルの実施形態を示すブロック図である。
【００１２】
【図４】図３のラウンドロビンデータベースファイルのより詳細な実施形態を示す図である。
【００１３】
【図５Ａ】ラウンドロビンデータベースを用いて生理学的データを格納するプロセスの実施形態を示すフローチャートである。
【図５Ｂ】ラウンドロビンデータベースを用いて生理学的データを格納するプロセスの実施形態を示すフローチャートである。
【図５Ｃ】ラウンドロビンデータベースを用いて生理学的データを格納するプロセスの実施形態を示すフローチャートである。
【００１４】
【図６Ａ】医療イベントをジャーナルデータベースにジャーナルするプロセスの実施形態を示すフローチャートである。
【図６Ｂ】ジャーナルデータベースのデータとラウンドロビンデータベースのデータとを相互に関連付けるプロセスの実施形態を示すフローチャートである。
【００１５】
【図７】図１の臨床ネットワーク環境において患者を監視するためのユーザインターフェースの一例のスクリーンショットである。
【発明を実施するための形態】
【００１６】
特定の実施形態では、生理学的動向データを迅速に格納および取得するシステムおよび方法を提供する。たとえば、医療患者から取得された生理学的情報をラウンドロビンデータベースに格納することが可能である。ラウンドロビンデータベースは、生理学的情報を、一定の時間間隔のレコードの系列として格納することが可能である。パラメータ記述子を用いて、レコード内のパラメータ値を識別することが可能である。パラメータ記述子を変更することによってパラメータ値を動的に更新することが可能であり、これによってデータベースがフレキシブルになる。さらに、データベースで使用するファイルのサイズを、患者の状態に応じて動的に調節することが可能である。
【００１７】
さらに、特定の実施形態では、生理学的監視装置の臨床ネットワークから取得された医療データをジャーナルデータベースに格納またはジャーナルすることが可能である。医療データは、臨床担当者と１つまたは複数の医療装置との対話に応じて発生する装置イベントを含むことが可能である。医療イベントデータは、装置が開始するイベント、たとえばアラームなども含んでよい。ジャーナルデータベースに格納された医療データを分析して、統計や指標を導出することが可能であり、これらを、臨床担当者および／または病院の能力の向上に用いることが可能である。
【００１８】
本明細書で用いている用語「ラウンドロビンデータベース」および「ＲＲＤＢ」は、本来の意味に加えて、本明細書で開示している独自の特性および特徴を有する、改良されたデータベース構造を表すことも可能である。これらの構造を、本明細書では、動的ＲＲＤＢまたは適応ＲＲＤＢと称することもある。
【００１９】
図１は、臨床ネットワーク環境１００の実施形態を示す。臨床ネットワーク環境１００は、多患者監視システム（ＭＭＳ）１２０を含んでおり、ＭＭＳ １２０は、ネットワーク１１０を介して、１つまたは複数の患者監視装置１４０、看護師詰所システム１３０、および臨床担当者端末１５０と通信している。特定の実施形態では、ＭＭＳ １２０は、患者監視装置１４０から取得された生理学的データを看護師詰所システム１３０および／または臨床担当者端末１５０に供給する。さらに、特定の実施形態では、ＭＭＳ １２０は、生理学的情報および医療イベント情報を、後で分析するために格納する。
【００２０】
臨床ネットワーク環境１００のネットワーク１１０は、どの病院、老人ホーム、患者介護センター、その他の臨床現場でも使用されているＬＡＮまたはＷＡＮ、無線ＬＡＮ（「ＷＬＡＮ」）、または他のタイプのネットワークであってよい。説明を簡単にするために、本明細書の以降では、病院の場合について臨床環境を説明するが、本明細書に記載の特徴は、他の臨床現場または臨床設定にも適用可能であることを理解されたい。実装によっては、ネットワーク１１０は、互いに離れていてもよい複数の病院または臨床現場にある装置をインターネットや専用線などで相互接続することが可能である。同様に、臨床ネットワーク環境１００の各種装置１２０、１３０、１４０、および１５０は、（たとえば、複数の病院に）地理的に分散していてよく、同じ場所に（たとえば、１か所の病院に）あってもよい。
【００２１】
患者監視装置１４０は、医療患者につないだセンサで検出される生理学的信号を監視するポイントオブケア（ＰＯＣ）計器などであってよい。患者監視装置１４０は、それらの信号を処理して、様々な生理学的パラメータのうちのいずれかを測定することが可能である。生理学的パラメータの一例が、血中酸素飽和度（ＳｐＯ２）である。後で、生理学的パラメータの他の例を、図２に関して説明する。
【００２２】
患者監視装置１４０は、生理学的情報をＭＭＳ １２０に供給することが可能である。また、患者監視装置１４０は、医療イベント、たとえばアラームなどの情報をＭＭＳ １２０に供給することも可能である。たとえば、生理学的パラメータが正常範囲から外れたことに対する応答として、アラームをトリガすることが可能である。また、センサが患者から外れたプローブオフ状態のような機器障害に関するアラートをアラームに含めることも可能である。後で、医療イベントの他の例を、図２に関して説明する。
【００２３】
各種実施形態では、患者監視装置１４０は、生理学的情報および医療イベントをＭＭＳ １２０に供給する。ＭＭＳ １２０については、後で詳述する。実装によっては、患者監視装置１４０は、この情報のうちの少なくともいくつかを看護師詰所システム１３０および臨床担当者端末１５０に直接供給することが可能である。
【００２４】
看護師詰所システム１３０は、看護師詰所に位置するデスクトップコンピュータ、ラップトップ、ワークステーションなどであってよい。１つの看護師詰所に、１つまたは複数の看護師詰所コンピュータ１３０を配置することが可能である。看護師詰所コンピュータ１３０は、ＭＭＳ １２０（または患者監視装置１４０）から受信した生理学的情報およびアラームデータを受信して表示することが可能である。特定の実施形態では、看護師詰所コンピュータ１３０は、生理学的情報および医療情報が一目でわかる合理化されたビューを提供するグラフィカル・ユーザ・インターフェース（ＧＵＩ）を採用している。後で、このＧＵＩの一例を、図７に関して説明する。
【００２５】
臨床担当者端末１５０は、臨床担当者が使用する任意の様々な端末であってよく、たとえば、ページャ、携帯電話、スマートフォン、携帯情報端末（ＰＤＡ）、ラップトップ、タブレットＰＣ、パーソナルコンピュータなどであってよい。実施形態によっては、臨床担当者端末１５０は、生理学的情報およびアラームを、ＭＭＳ １２０（または患者監視装置１４０）から受信することが可能である。生理学的データおよびアラームデータは、たとえば、アラームに対する応答として、特定の臨床担当者端末１５０に供給されることが可能である。臨床担当者端末１５０は、場合によっては、生理学的パラメータの値および波形を受信することが可能である。
【００２６】
ＭＭＳ １２０は、特定の実施形態では、ハードウェアおよび／またはソフトウェアを有してネットワーク１１０のネットワークトラフィックを管理する１つまたは複数の物理的コンピューティング装置、たとえばサーバなどを含む。このハードウェアおよび／またはソフトウェアは、論理的かつ／または物理的に、機能の異なる、複数の異なるサーバ１２０、たとえば、通信サーバ、Ｗｅｂサーバ、データベースサーバ、アプリケーションサーバ、ファイルサーバ、プロキシサーバなどに分割されていてよい。
【００２７】
ＭＭＳ １２０は、標準化されたプロトコル（ＴＣＰ／ＩＰなど）または独自プロトコルを用いて、患者監視装置１４０、看護師詰所コンピュータ１３０、および臨床担当者端末１５０と通信することが可能である。一実施形態では、患者監視装置１４０がＭＭＳ １２０と接続することを要求した場合、ＭＭＳ １２０は、患者監視装置１４０を認証してから、患者監視装置１４０につながっている患者のコンテキスト情報を患者監視装置１４０に与えることが可能である。コンテキスト情報には、特に、患者デモグラフィ、患者アラーム設定、およびその患者に対する臨床担当者の割り当てを含めることが可能である。参照によりその開示の全体が本明細書に組み込まれている、２００６年１２月４日に出願した米国特許出願第１１／６３３６５６号明細書（件名「Ｐｈｙｓｉｏｌｏｇｉｃａｌ ａｌａｒｍ ｎｏｔｉｆｉｃａｔｉｏｎ ｓｙｓｔｅｍ」）に、コンテキスト情報の例が記載されている。ＭＭＳ １２０は、このコンテキスト情報を、患者入院情報が備えてある看護師詰所システム１３０または他の院内コンピュータシステムから取得することが可能である。
【００２８】
ＭＭＳ １２０は、患者監視装置１４０に接続した時点で、生理学的情報および医療イベントを患者監視装置１４０から受信することが可能である。ＭＭＳ １２０は、生理学的情報およびイベントの少なくとも一部を看護師詰所システム１３０および／または臨床担当者端末１５０に供給することが可能である。たとえば、ＭＭＳ １２０は、複数の患者監視装置１４０に関連する生理学的データおよびアラームを看護師詰所システム１３０に供給することが可能であり、看護師詰所システム１３０では、看護師がそのデータおよび／またはアラームを評価して患者の治療方法を決定することが可能である。同様に、ＭＭＳ １２０は、無線ページ、電子メール、インスタントメッセージなどを臨床担当者端末１５０に送信して、生理学的データおよびアラームを臨床担当者に供給することが可能である。
【００２９】
有利なこととして、特定の実施形態では、ＭＭＳ １２０は、患者監視装置１４０から取得された生理学的情報をラウンドロビンデータベース（ＲＲＤＢ）１２４に格納することが可能である。各種実施形態のＲＲＤＢ １２２は、患者データの迅速な格納および取り出しを容易にする合理化されたデータベース構造を有する。したがって、特定の実施形態では、ＲＲＤＢ １２２を用いて、生理学的動向データを看護師詰所１３０および臨床担当者端末１５０に迅速に供給することが可能である。そこで、たとえば、臨床担当者が患者の特定の時間帯、たとえば、過去１時間の生理学的動向を見たい場合、臨床担当者は、看護師詰所コンピュータ１３０または臨床担当者端末１５０からＭＭＳ １２０に照会することが可能である。その後、ＭＭＳ １２０は、所望の時間帯に対応する生理学的情報をＲＲＤＢ １２２から取得することが可能である。有利なこととして、ＲＲＤＢ １２２は、動向データの取得を高速化することが可能であり、これは、院内監視システムで使用中のリレーショナルデータベースを用いて可能である。後で、ＲＲＤＢ １２２のさらなる利用法および最適化について説明する。
【００３０】
また、特定の実施形態では、ＭＭＳ １２０は、医療イベントの情報をジャーナルデータベース１２４にアーカイブまたは格納する。医療イベントは、患者監視装置１４０、看護師詰所システム１３０、臨床担当者端末１５０などの装置で記録されたイベントを含むことが可能である。特に、医療イベントは、臨床担当者と装置との対話に応じて発生する装置イベント、たとえば、臨床担当者が行うアラームの動作停止を含むことが可能である。また、医療イベントは、臨床担当者と装置との対話がなくても発生する装置イベント、たとえば、アラームそのものを含むことも可能である。後で、医療イベントのさらなる例を、図２に関して説明する。
【００３１】
ＭＭＳ １２０は、ジャーナルデータベース１２４に格納されている医療イベント情報を分析して、医療イベントに関する統計を導出することが可能である。たとえば、ＭＭＳ １２０は、アラームイベントとアラーム動作停止イベントとを分析して、アラームに対する臨床担当者の応答時間を調べることが可能である。これらの統計を用いて、ＭＭＳ １２０は、臨床担当者および／または病院の能力に関するレポートを生成することが可能である。有利なこととして、特定の実施形態では、これらの統計およびレポートを用いて、臨床担当者および病院の能力を向上させることが可能である。
【００３２】
たとえば、特定の状況では、これらのレポートは、患者監視装置１４０に関する問題の原因を病院が見つける助けになるであろう。以下のシナリオ例は、そのようなレポートの潜在的効能を示すことが可能である。ＳｐＯ２のアラームレベルは、傾向として、成人と新生児とで異なる。しかしながら、一部の臨床担当者は、このことを知らずに、新生児のＳｐＯ２監視装置を、成人のアラームレベルを含むように修正してしまうことがある。こうした変更は多くの間違いアラームを引き起こす可能性があり、これによって、臨床担当者は苛立ち、患者監視装置１４０の使用をやめる可能性がある。臨床担当者によるアラーム変更のような医療イベントをジャーナルし、ジャーナルしたデータを分析することにより、臨床担当者が新生児用監視装置のアラーム設定を不適切に調節していたことがわかる可能性がある。このような情報に基づいて、病院は、アラームのリミットを固定したり、臨床担当者をトレーニングしたりするなどの是正措置を講じることが可能である。
【００３３】
図示していないが、臨床ネットワーク環境１００に管理装置を設けてもよい。管理装置は、病院管理者やＩＴ担当者などが操作するコンピューティング装置であってよい。ＩＴ担当者は、管理装置を用いて、たとえば、複数の患者監視装置１４０、看護師詰所システム１３０、およびＭＭＳ １２０に変更を一斉に伝えることが可能である。また、ＩＴ担当者は、管理装置を用いて、サードパーティシステム、たとえば、電子医療記録（ＥＭＲ）システムをＭＭＳ １２０とインターフェースさせることも可能である。たとえば、サードパーティシステムを用いて、複数の監視装置のアラーム設定の変更を管理装置から行うことが可能である。管理者、ＩＴ担当者、および管理装置によって実行されるほとんどのアクションも、ジャーナルデータベース１２４にジャーナルすることが可能である。
【００３４】
図２は、臨床ネットワーク環境２００のより詳細な実施形態を示す。臨床ネットワーク環境２００は、ネットワーク２１０、患者監視装置２４０、看護師詰所システム２３０、ＭＭＳ ２２０、ＲＲＤＢ ２２２、およびジャーナルデータベース２２４を含んでいる。これらのコンポーネントは、図１に関して上述した機能性をすべて備えていることが可能である。説明を簡単にするために、患者監視装置２４０および看護師詰所システム２３０を１つずつ図示した。さらに、図示していないが、上述の臨床担当者端末１５０を臨床ネットワーク環境２００に含めることも可能である。
【００３５】
図示した、患者監視装置２４０の実施形態は、監視モジュール２４２、ＲＲＤＢモジュール２４４、およびジャーナルモジュール２４６を含んでいる。これらのモジュールのそれぞれは、ハードウェアおよび／またはソフトウェアを含んでよい。通信モジュールなどの他のコンポーネントも、図示していないが、様々な実装において、患者監視装置２４０に含めることが可能である。
【００３６】
監視モジュール２４２は、患者につないだ１つまたは複数のセンサで生成される生理学的信号を監視することが可能である。監視モジュール２４２は、それらの信号を処理して、様々な生理学的パラメータのうちのいずれかを測定することが可能である。たとえば、監視モジュール２４２は、脈拍数、プレチスモグラフ波形データ、灌流指数、生体組織の血液成分の値などの生理学的パラメータを測定することが可能である。生体組織の血液成分の値としては、たとえば、動脈血一酸化炭素飽和度（「ＨｂＣＯ」）、メトヘモグロビン飽和度（「ＨｂＭｅｔ」）、総ヘモグロビン（「ＨｂＴ」または「ＳｐＨｂ」）、動脈血酸素飽和度（「ＳｐＯ２」）、分数的動脈血酸素飽和度（「ＳｐａＯ２」）、酸素含量（「ＣａＯ２」）などがある。
【００３７】
さらに、監視モジュール２４２は、呼吸数、吸気時間、呼気時間、吸気対呼気比、吸気流、呼気流、一回換気量、毎分換気量、無呼吸継続時間、呼吸音、ラ音、いびき音、喘鳴、および音量の減少などの呼吸音の変化または空気流の変化を調べるために、音響センサから生理学的情報を取得することが可能である。さらに、場合によっては、監視モジュール２４２は、他の生理学的な音（たとえば、心拍（たとえば、プローブオフ検出の検出に役立つ）、心音（たとえば、Ｓ１、Ｓ２、Ｓ３、Ｓ４、および心雑音）、および心音の変化（たとえば、正常音から雑音への変化、あるいは体液過剰を示す分裂心音）を監視する。さらに、監視モジュール２４２は、心電図検査（ＥＣＧ）および他の多くの生理学的パラメータを介して、患者の電気的心臓活動を監視することが可能である。
【００３８】
実装によっては、患者監視装置１４０は、様々なデータ信頼度指標を測定することも可能であり、たとえば、参照によりその開示の全体が本明細書に組み込まれている米国特許第７０２４２３３号明細書（件名「Ｐｕｌｓｅ ｏｘｉｍｅｔｒｙ ｄａｔａ ｃｏｎｆｉｄｅｎｃｅ ｉｎｄｉｃａｔｏｒ」）に記載されているデータ信頼度指標を測定することが可能である。また、患者監視装置１４０は、灌流指数を測定することも可能であり、たとえば、参照によりその開示の全体が本明細書に組み込まれている米国特許第７２９２８８３号明細書（件名「Ｐｈｙｓｉｏｌｏｇｉｃａｌ ａｓｓｅｓｓｍｅｎｔ ｓｙｓｔｅｍ」）に記載されている灌流指数を測定することが可能である。さらに患者監視装置１４０は、プレチスモグラフ変動指数（ＰＶＩ）を測定することが可能であり、たとえば、参照によりその開示の全体が本明細書に組み込まれている米国特許出願公開第２００８／０１８８７６０号明細書（件名「Ｐｌｅｔｈｙｓｍｏｇｒａｐｈ ｖａｒｉａｂｉｌｉｔｙ ｐｒｏｃｅｓｓｏｒ」）に記載されているＰＶＩを測定することが可能である。本明細書に記載のパラメータは例に過ぎず、他の多くのパラメータも、実施形態によっては使用可能である。
【００３９】
特定の実施形態では、ＲＲＤＢモジュール２４４は、監視モジュール２４２から生理学的情報を受信し、その生理学的情報を、ネットワーク２１０を介してＭＭＳ ２２０に送信する。応答として、後で詳述するように、ＭＭＳ ２２０は、生理学的情報をＲＲＤＢ ２２２に格納することが可能である。有利なこととして、特定の実施形態では、ＲＲＤＢモジュール２４４は、生理学的情報を、パラメータ記述子に関連付けてから、ＭＭＳ ２２０に送信する。パラメータ記述子は、ＲＲＤＢモジュール２４４が、測定された各生理学的パラメータ値に関連付ける識別子であってよい。ＭＭＳ ２２０は、これらのパラメータ記述子を用いて、ＲＲＤＢモジュール２４４から受信した測定済みパラメータのタイプを識別することが可能である。
【００４０】
パラメータ記述子は、マークアップ言語仕様（拡張可能マークアップ言語（ＸＭＬ）仕様など）に従って生成される記述子であってよい。したがって、パラメータ記述子は、測定された生理学的値を囲むタグを含んでよい。これらのタグは、機械可読であっても人間可読であってもよい。たとえば、タグは、数値識別子（たとえば、「００１７」）や記述識別子（「ＳＰＯ２」や「ＳＰＨＢ」など）を含んでよい。各パラメータ記述子に関連付けられたＳｐＯ２センサおよびＳｐＨｂセンサからの生理学的情報の簡単なストリーム例を以下に示す。＜ＳＰＯ２＞９６＜／ＳＰＯ２＞＜ＳＰＨＢ＞１４．１＜／ＳＰＨＢ＞＜ＳＰＯ２＞９７＜／ＳＰＯ２＞＜ＳＰＨＢ＞１４．０＜／ＳＰＨＢ＞（さらに続く）。
【００４１】
一実施形態では、ＲＲＤＢモジュール２４４は、患者監視装置２４０で使用可能な事前定義済みパラメータ記述子のセットを（たとえば、データファイルの形で）格納していることが可能である。これらのパラメータ記述子は、患者監視装置２４０で測定可能な潜在的パラメータに対応してよい。ＲＲＤＢモジュール２４４から送信されるパラメータ記述子は、患者監視装置２４０で測定されるパラメータの特定のサブセットに依存してよい。
【００４２】
その後、患者監視装置２４０が追加の（または別の）パラメータを測定する場合、ＲＲＤＢモジュール２４０は、パラメータ記述子を動的に更新してＭＭＳ ２２０に送信することが可能である。同様に、患者監視装置２４０がいずれかのパラメータの測定を中止する場合、ＲＲＤＢモジュール２４４は、対応するパラメータ記述子の、ＭＭＳ ２２０への送信を中止することが可能である。
【００４３】
また、図示した実施形態では、患者監視装置２４０は、ジャーナルモジュール２４６を含んでいる。ジャーナルモジュール２４０は、患者監視装置２４０に関連する医療イベントを記録することが可能である。そのような医療イベントは、臨床担当者が開始するイベントを含むことが可能であり、たとえば、アラーム設定（たとえば、最大および最小許容パラメータ値）、監視対象パラメータのタイプ、患者監視装置２４０に接続したセンサのタイプなどの変更を含むことが可能である。ジャーナルモジュール２４６は、これらのイベントを記録するために、たとえば、キーロガーなどのように動作して、臨床担当者のボタン押し動作を記録することが可能である。また、ジャーナルモジュール２４６は、センサまたはケーブルが監視装置２４０などに接続されたタイミングを検出する電流感知回路を含むことが可能である。医療イベントには、臨床担当者が開始するイベントではないもの、たとえばアラームやアラートなども含まれてよい。また、管理装置（図示せず）からのイベント、たとえば、ネットワーク２１０経由での、ＥＭＲによるアラーム設定の更新も、医療イベントに含まれてよい。
【００４４】
ジャーナルモジュール２４６は、これらのイベントを、患者監視装置２４０においてローカルにログすることが可能である。さらに、またはイベントをローカルにログする代わりに、ジャーナルモジュール２４６は、イベントに関する情報をＭＭＳ ２２０に送信することが可能である。これを受けてＭＭＳ ２２０は、そのイベント情報をジャーナルデータベース２２４に格納することが可能である。
【００４５】
図示した実施形態では、患者監視クライアント２３２を有する看護師詰所システム２３０を示している。患者監視クライアント２３２は、看護師詰所システム２３０が生理学的情報およびアラーム情報を受信して表示することを可能にする。患者監視クライアント２３２は、ユーザ・インターフェース・モジュール２３４を含んでいる。ユーザ・インターフェース・モジュール２３４は、たとえば、複数の患者監視装置２４０に関連する生理学的情報、患者情報、および医療イベント情報を表示するソフトウェアを含むことが可能である。また、ユーザ・インターフェース・モジュール２３４は、臨床担当者が患者を入退院させたり、装置のアラームリミットを遠隔修正したりすることなどを可能にする。ユーザ・インターフェース・モジュール２３４で生成可能なユーザインターフェースの一例を、後で図７に関して説明する。
【００４６】
患者監視クライアント２３２はさらに、ジャーナルモジュール２３６を含んでいる。ジャーナルモジュール２３６は、患者監視クライアント２３２に関連する医療イベントを記録するソフトウェアを含むことが可能である。たとえば、ジャーナルモジュール２３６は、患者監視クライアント２３２にログインおよびログオフしている臨床担当者、これらのイベントの発生時刻、入院および退院イベント、および他の、臨床担当者のキーストローク、マウスクリック、患者監視クライアント２３２との対話などを記録することが可能である。ジャーナルモジュール２３６は、このイベント情報を看護師詰所システム２３０においてローカルにログしたり、かつ／または、このイベント情報をＭＭＳ ２２０に送信したりすることが可能である。
【００４７】
図示したように、ＭＭＳ ２２０は、ネットワーク管理モジュール２２１、ＲＲＤＢ管理モジュール２２３、およびジャーナル管理モジュール２２５を含むことが可能であり、これらはそれぞれ、１つまたは複数のソフトウェアコンポーネントを含むことが可能である。一実施形態では、ネットワーク管理モジュール２２１は、生理学的情報および医療イベントデータを含むメッセージを患者監視装置２４０から受信する。ネットワーク管理モジュール２２１は、このデータの少なくとも一部を、看護師詰所システム２３０および図１の臨床担当者端末１５０に供給することが可能である。また、ネットワーク管理モジュール２２１は、生理学的情報をＲＲＤＢ管理モジュール２２３に供給し、医療イベントデータをジャーナル管理モジュール２２５に供給することが可能である。
【００４８】
特定の実施形態では、ＲＲＤＢ管理モジュール２２３は、患者監視装置２４０から受信した生理学的情報をＲＲＤＢ ２２２に格納する。患者監視装置２４０が最初にＭＭＳ ２２０に接続されたとき、または別のときに、ＲＲＤＢ管理モジュール２２３は、その患者監視装置２４０に対応する１つまたは複数のＲＲＤＢファイルをＲＲＤＢ ２２２内に作成することが可能である。この１つまたは複数のＲＲＤＢファイルの内容は、患者監視装置２４０のタイプに応じて異なってよく、患者監視装置２４０のシリアル番号、モデル番号、製造元識別子、これらの組み合わせなどによって定義することが可能である。後で、ＲＲＤＢファイルの構造および内容の具体例を、図３および図４に関して説明する。
【００４９】
また、ＲＲＤＢ管理モジュール２２３は、ＲＲＤＢに格納された生理学的動向データを、患者監視装置２４０、看護師詰所システム２３０、および／または臨床担当者端末への送信のためにネットワーク管理モジュール２２１に供給することが可能である。また、ＲＲＤＢ管理モジュール２２３は、ＲＲＤＢ ２２２からの生理学的データを、図６Ｂに関して後述する目的のために、ジャーナル管理モジュール２２５に供給することが可能である。
【００５０】
ジャーナル管理モジュール２２５は、特定の実装では、患者監視装置２４０および看護師詰所システム２３０から医療イベントデータを受信し、このデータをジャーナルデータベース２２４に格納する。一実施形態では、ジャーナルデータベース２２４は、リレーショナルデータベースであるが、他の構造も可能である。イベントデータの各エントリは、それぞれ、イベントの発生時刻を示すタイムスタンプを有することが可能である。このタイムスタンプは、ジャーナルモジュール２４６または２３６、あるいはジャーナル管理モジュール２２５から提供可能である。また、ジャーナル管理モジュール２２５は、医療イベントの発生回数を示すイベントカウンタをジャーナルデータベース２２４に格納することが可能である。たとえば、一定時間内のアラームの発生回数、あるいは、臨床担当者がネットワーク端末に対してログオンまたはログオフした回数をカウントするカウンタを格納することが可能である。
【００５１】
有利なこととして、ジャーナル管理モジュール２２５は、特定の実施形態では、ジャーナルデータベース２２４内の医療データを分析して、臨床担当者および／または病院の能力の統計または指標を算出することが可能である。ジャーナル管理モジュール２２５は、これらの統計にアクセスするためのインターフェースを、看護師詰所システム２３０または別のコンピューティング装置のユーザに提供することが可能である。一実施例では、ジャーナル管理モジュール２２５は、アラームイベントとアラーム動作停止イベントとを分析して、アラームに対する臨床担当者の応答時間を調べることが可能である。ジャーナル管理モジュール２２５はさらに、看護師の昼夜シフトにおける臨床担当者の応答時間を調べることが可能である。ジャーナル管理モジュール２２５は、これらの統計のレポートを生成することによって、たとえば、どのシフトがよりよく機能するかを病院管理者が決定できるようにすることが可能である。
【００５２】
より一般的には、ジャーナル管理モジュール２２５は、ジャーナルデータベース２２４内のデータから導出された様々な統計を分析することにより、臨床担当者および／または病院の能力に関するレポートを生成することが可能である。レポートの一例として、導出された統計に少なくとも部分的に基づいて病院対病院（あるいは看護師詰所対看護師詰所など）の格付けを行う監視レポートカードがある。有利なこととして、病院管理者、臨床担当者などは、臨床担当者および病院の能力を向上させるために、これらの統計やレポートを用いることが可能である。
【００５３】
臨床ネットワーク環境２００の特徴の一部またはすべてを、個々の実施形態に適応させることが可能である。たとえば、ジャーナルモジュール２４６または２３６の一方または両方が、ジャーナル管理モジュール２２５の機能の一部またはすべてを実行してよい。同様に、１つまたは複数のジャーナルデータベース２２４を、患者監視装置２４０および／または看護師ワークステーション２３０に格納してよい。同様に、ＲＲＤＢモジュール２２４は、ＲＲＤＢ管理モジュール２２３の機能の一部またはすべてを実行してよく、ＲＲＤＢ ２２２は患者監視装置２４０に格納可能である。さらに、実装によっては、図１の臨床担当者端末１５０も同様に、ＲＲＤＢおよび／またはジャーナルモジュールを有してよい。他の実施形態では、他の多くの適応、構成、および組み合わせを実施してよい。
【００５４】
図３は、臨床ネットワーク環境、たとえば、臨床ネットワーク環境１００または２００において生理学的データを格納するＲＲＤＢファイル３００の実施形態を示す。特定の実施形態では、ＲＲＤＢファイル３００の構成のおかげで、上述のＭＭＳ １２０または２２０が、生理学的データの格納および取り出しを迅速に行うことが可能である。
【００５５】
特定の実施形態のＲＲＤＢファイル３００は、フラットなファイル構造を有するが、他の構造（リレーショナル構造など）も可能である。一実施形態では、１つのファイル３００が１人の患者に対応するが、１人の患者に対して複数のファイル３００を使用することも可能である。さらに、実装によっては、ファイル３００を複数の患者で共有することが可能である。ＲＲＤＢでは、生理学的情報をファイル３００内のレコード３６２に書き込む。特定の実施形態では、各レコード３６２は、ＲＲＤＢでは１行であるが、レコード３６２は複数行であってもよい。たとえば、各レコード３６２は、１つまたは複数の生理学的パラメータ、波形などの値を表す１つまたは複数の数字を含んでよい。さらに、実施形態によっては、アラームリミットおよび他の情報を各レコード３６２に格納することが可能である。
【００５６】
有利なこととして、特定の実施形態では、様々なレベルの詳細をＲＲＤＢファイル３００に格納することが可能である。たとえば、ファイル３００を、１人の患者に対して、または端末に対して、またはその端末の１つのパラメータまたはテクノロジーに対して、またはパラメータに対応するチャネルに対して、割り当てることが可能である。これらのファイルを割り当てるための基準の例を以下に示す。チャネルは、端末によって測定された値または値のセットであってよい。たとえば、ＳｐＯ２センサの場合は、ＳｐＯ２の読みを取得するために用いる光の中の様々な波長に対応する複数のチャネル、たとえば、赤チャネルおよび赤外（ＩＲ）チャネルがあってよい。他の光センサは、センサで用いる光の各波長ごとに１つのチャネルを有してよい（３つ以上であってよい）。
【００５７】
図２を再度参照すると、患者監視装置２４０のＲＲＤＢモジュール２４４は、先ほど述べたＲＲＤＢファイルの様々なタイプに対応する様々な量の生理学的情報を、ＲＲＤＢ ２２２に供給することが可能である。ＲＲＤＢモジュール２４４は、患者の健康状態に少なくとも部分的に基づいて詳細レベルを選択することが可能である。たとえば、患者の健康状態が比較的良い場合、ＲＲＤＢモジュール２４４は、ＲＲＤＢ ２２２に送信する情報の量を少なくすることが可能である。一方、患者の健康状態が比較的良くない場合（たとえば、病状が重い場合）、ＲＲＤＢモジュール２４４は、より細かい生理学的情報をＲＲＤＢ ２２２に送信することが可能である。また、他の実施形態では、ＲＲＤＢモジュール２４４は、他の要因、たとえば、生理学的信号の雑音の程度、信号の変動性などに基づいて、ＲＲＤＢ ２２２に送信する生理学的情報の量を適応させることも可能である。
【００５８】
より具体的に述べると、実施形態によっては、ＲＲＤＢモジュール２４４は、患者ごとに単一ファイルを開くことを、ＲＲＤＢ管理モジュール２２３に命令することが可能である。このファイルは、その患者につないだ各装置の比較的高レベルの詳細を含むことが可能である。患者の健康状態が比較的良い場合には、この設定で十分であろう。患者の健康状態が良くない場合、ＲＲＤＢモジュール２４４は、その患者につないだ各装置ごとに単一ファイルを作成することを、ＲＲＤＢ管理モジュール２２３に命令することが可能である。これらのファイルのそれぞれは、患者ごとの単一ファイルより詳細であることが可能である。さらに、健康状態がより悪い場合には、ＲＲＤＢモジュール２４４は、患者監視装置２４０で測定される各パラメータごとにファイルを作成すること、またはセンサの各チャネルごとにファイル（これはセンサからのローデータを含んでよい）を作成することを、ＲＲＤＢ管理モジュール２２３に命令することが可能である。このように、患者の健康状態が悪化した場合には、より多くの詳細を供給することが可能である。
【００５９】
ＲＲＤＢモジュール２４４は、ＲＲＤＢ ２２２に送信するデータの量および／またはＲＲＤＢ ２２２にデータを送信する頻度を、患者の健康状態に基づいて動的に調節することが可能である。一例として、患者のＳｐＨｂレベルが安全レベルを下回った場合（たとえば、アラームリミットから外れた場合）、ＲＲＤＢモジュール２４４は、より詳細な生理学的情報をＲＲＤＢ ２２２に送信すること、または、より頻繁に生理学的情報を送信することが可能である。ＲＲＤＢ管理モジュール２２３は、追加の詳細を受信すると、その、より詳細な生理学的情報を格納するために、新しいファイルを作成することが可能である。患者のＳｐＨｂが正常に戻れば、ＲＲＤＢモジュール２４４は、ＲＲＤＢ ２２２に送信する詳細のレベルを下げることが可能である。そして、ＲＲＤＢ管理モジュール２２３は、新しいファイルを作成して、その下がったレベルの詳細を格納すること、または既に作成されている低レベル詳細ファイルを使用することが可能である。このように、特定の実施形態では、ＲＲＤＢモジュール２４４およびＲＲＤＢ管理モジュール２２３は、ＲＲＤＢファイルの記憶領域の適応制御を行うことが可能である。したがって、特定の実施形態では、ＲＲＤＢを、適応ＲＲＤＢまたは動的ＲＲＤＢと見なすことができる。
【００６０】
さらに、特定の実施形態では、ＲＲＤＢモジュール２４４は、生理学的データの複数のストリームをＲＲＤＢ ２２２に送信することが可能である。異なるストリームが異なる細かさの生理学的データを有することが可能であり、ＲＲＤＢ ２２２内の別々のファイルに格納可能である。たとえば、生理学的データの各ストリームは、１つまたは複数のチャネルの生理学的情報を含むことが可能である。各ストリームは、ＲＲＤＢ ２２２内の１つまたは複数のファイルに対応可能である。
【００６１】
図３を再度参照すると、ＲＲＤＢは、所定の数のレコード３６２をファイル３００に格納することが可能である。ＲＲＤＢは、ファイル３００内の最後のレコード３６２ａにデータを書き込んだ後、自動的に最初のレコード３６２ｂにループバックしてレコード３６２ｂを上書きする。これが、「ラウンドロビン」という用語の所以である。レコード３６２は、図においてΔｔで示されている一定の（たとえば、等しい）時間間隔で格納可能である。各レコード３６２をＲＲＤＢに格納する際に、レコード３６２にタイムスタンプを付けることが可能である。したがって、Δｔは、任意の連続する２つのレコード３６２のタイムスタンプ値の差を表すことが可能である。代替として、ファイル３００のヘッダ部（図４を参照）が、ファイル３００に新しい値が記録された時刻を書き取らせる、あらかじめ定義された時間ステップを含むことが可能である。場合によっては、患者監視装置が、（たとえば、患者の健康状態が良いため）データの監視を中止したか、データの記録を不要と判断したことにより、データをＲＲＤＢに送信しないことがある。患者監視装置がデータ送信を中止した場合でも時間間隔構造が維持されるように、ファイル３００の１つまたは複数のレコード３６２に、生理学的情報の代わりに、ゼロまたは他の非データ値（たとえば、「ｎｏｔ ａ ｎｕｍｂｅｒ（非数）」の意味のＮａＮ）を格納することが可能である。
【００６２】
ファイル３００からレコード３６２を読み出す場合、先行のｋ個のレコード（たとえば、ｋΔｔ）のように、ｋ個のレコードを取得することをポインタなどに命令することが可能である。たとえば、先頭のｋ個のレコード３６２を取得する場合は、ＲＲＤＢ管理モジュール２２３（たとえば）がｋ個のレコード３６２を読み出す間に、ファイルポインタを、最新のｋ個のレコード３６２にわたって進めることが可能である。レコード３６２の任意の一部分を取得することが可能である（たとえば、最新のレコード３６２の一部分、さらにはレコード３６２のすべて）。さらに、レコード３６２の複数部分を読み出すことも可能である。たとえば、複数のパラメータのうちの特定のパラメータの値を、先行のｋ個のレコード３６２から読み出すことが可能である。
【００６３】
有利なこととして、ＲＲＤＢからは、リレーショナルデータベースに比べて桁違いの速さでレコード３６２を取得することが可能である。たとえば、一実施形態では、データベースの検索を、０次検索（ｚｅｒｏ−ｏｒｄｅｒ ｓｅａｒｃｈ）として実行することが可能である。したがって、医療情報動向を、臨床担当者端末、看護師詰所コンピュータなどへ迅速にストリーミングまたは別の方法で供給することが可能である。実装によっては、アラームの送信に関してＪＣＡＨＯ（Ｊｏｉｎｔ Ｃｏｍｍｉｓｓｉｏｎ ｏｎ ｔｈｅ Ａｃｃｒｅｄｉｔａｔｉｏｎ ｏｆ Ｈｅａｌｔｈｃａｒｅ Ｏｒｇａｎｉｚａｔｉｏｎｓ）から公布されたいくつかの規格に準拠するのに十分な速さで生理学的情報を読み取って臨床担当者端末に送信するように、ＲＲＤＢを構成することが可能である。したがって、たとえば、アラームの発生から５秒以内にアラームを臨床担当者に送信することが規格で要求されている場合は、アラーム通知とともに動向データを５秒以内に臨床担当者端末に提供するように、ＲＲＤＢを構成することが可能である。
【００６４】
図４は、ＲＲＤＢファイル４００のより詳細な実施形態を示す。ＲＲＤＢファイルは、ヘッダ４１０および複数のレコード４２０を含んでいる。ヘッダ４１０は、ＲＲＤＢ管理モジュール２２３が、たとえば、ファイル４００の読み書きや検索を行うために使用可能なデータを含んでいる。図示した実施形態では、ヘッダ４１０内の各フィールドをＸＭＬタグで示している。これは一実装に過ぎず、別の実施形態では変形可能である。
【００６５】
図示したヘッダ例４１０のフィールドは、開始時刻、終了時刻、ステップ間隔、パラメータ数、およびパラメータリストを含んでいる。図示した実施形態では、開始時刻および終了時刻を秒数で測定している（たとえば、Ｕｎｉｘ（登録商標） ｅｐｏｃｈ（１９７０年１月１日）からの秒数）。ステップ間隔（図示した実施形態では３０秒）は、レコード４２０をファイル４００に書き込む頻度を示している。パラメータ数（この例では７）は、監視されている生理学的パラメータの数を示している。パラメータリストは、監視されているパラメータに対応するパラメータ記述子のリストを含んでいる。ヘッダ４１０内の各フィールドは、ＲＲＤＢ管理モジュール２２３によって調節可能である。特定の実施形態では、含まれるフィールドの数は、これより多くても少なくてもよい。
【００６６】
図示した実施形態の各レコード４２０は、区切り記号（この例ではスペース）で区切られたパラメータ値を含む単一行である。たとえば、先頭のレコード４２０にあるパラメータ値は、９６、５５、８．９、１４、１４．１、０．５、および１．０である。これらの値は、ヘッダ４１０のパラメータリストにあるパラメータ記述子の順番に対応する。すなわち、値９６は、ＳＰＯ２パラメータ記述子に対応し、値５５は、ＢＰＭ（ビート毎分）パラメータ記述子に対応する。その他の値も同様である。
【００６７】
有利なこととして、特定の実施形態では、ヘッダ４１０のパラメータリストがパラメータ記述子を含むため、個々のレコード４２０にパラメータ記述子を含めることなく、レコード４２０を書き込むことが可能である。結果として、特定の実装では、ファイル４００は、パラメータ記述子をレコード４２０に含めた場合より、サイズを小さくすることが可能である。
【００６８】
図５Ａ〜図５Ｃは、ＲＲＤＢを用いて生理学的データを格納するプロセス５００の実施形態を示す。図５Ａは、生理学的データをＲＲＤＢに供給するプロセス５００Ａの一実施形態を示している。一実施形態では、プロセス５００Ａは、上述のどのＭＭＳによっても（たとえば、ＭＭＳ １２０または２２０によって）実装可能である。具体的には、プロセス５００Ａは、図２のＲＲＤＢ管理モジュール２２３によって実装可能である。代替として、少なくともいくつかのブロックは、患者監視装置２４０のＲＲＤＢモジュール２４４によって実装可能である。有利なこととして、特定の実施形態では、プロセス５００Ａは、臨床ネットワークを介してＭＭＳと通信する患者監視装置に対してＲＲＤＢファイルを作成することを可能にする。
【００６９】
ブロック５０２では、患者監視装置から識別情報を受信する。識別情報としては、たとえば、患者監視装置のシリアル番号、患者監視装置のモデル番号、患者監視装置の製造元、患者監視装置の１つまたは複数の相手先ブランド製造者（ＯＥＭ）モジュールの識別情報、これらの組み合わせなどが可能である。
【００７０】
ブロック５０４では、識別情報に少なくとも部分的に基づいて、患者監視装置に対応するパラメータ記述子を取り出す。各患者監視装置に対応するパラメータ記述子は、ＭＭＳ １２０または２２０上のファイルに格納可能である。たとえば、患者監視装置のシリアル番号ごとに一式の潜在的パラメータ記述子を格納することが可能であり、これらの記述子は、それぞれの患者監視装置で処理可能な潜在的パラメータに対応する。特定の実施形態では、パラメータ記述子は、拡張可能マークアップ言語（ＸＭＬ）記述子または同様のものである。
【００７１】
ブロック５０６では、識別されたパラメータ記述子を有するヘッダを持つＲＲＤＢファイルを作成する。ＲＲＤＢファイルのヘッダについては、既に、図４に関してその例を説明した。パラメータ記述子は、たとえば、図４に示したパラメータリストに挿入することが可能である。したがって、所与の患者監視装置に対応するパラメータリストは、ＲＲＤＢ管理モジュール２２３によって決定可能である。図５Ｂに関して後述するように、パラメータリストは、少なくとも部分的には、患者監視装置によって決定可能であってもよい。
【００７２】
ブロック５０８では、患者監視装置から生理学的データを受信する。ブロック５１０では、ヘッダを用いて、生理学的データをＲＲＤＢファイル内のロケーションにマッピングする。このマッピングは、少なくとも部分的には、図４に関して上述したような、データ内の記述子を用いて行うことが可能である。
【００７３】
図５Ｂは、生理学的データをＲＲＤＢに供給するプロセス５００Ｂの別の実施形態を示す。このプロセス５００Ｂは、患者監視装置（たとえば、１４０または２４０）によって実装可能である。具体的には、ＲＲＤＢモジュール２４４は、プロセス５００Ｂのいくつかのブロックを実行することが可能である。代替として、少なくともいくつかのブロックは、患者監視装置２４０のＲＲＤＢモジュール２４４によって実装可能である。有利なこととして、特定の実施形態では、プロセス５００Ｂは、患者監視装置で監視されるパラメータの変化に基づいてＲＲＤＢファイルを動的に作成することを可能にする。
【００７４】
ブロック５１２では、患者の１つまたは複数の生理学的パラメータに対応する生理学的データを取得する。このブロックは、上述の監視モジュール２４２で実行可能である。ブロック５１４では、パラメータ記述子を生理学的データに関連付けて、関連付けられた生理学的データを生成する。この関連付けは、ＲＲＤＢモジュール２４４によって実行可能である。この関連付けは、一実施形態では、生理学的データにＸＭＬタグを挿入することによって行うことが可能である。ブロック５１６では、関連付けられた生理学的データをＲＲＤＢに供給する。
【００７５】
この関連付けられた生理学的データが送信されると、一実施形態では、ＭＭＳが、生理学的データ内で識別されたパラメータ記述子を有するＲＲＤＢファイルを作成することが可能である。代替として、ＭＭＳは、上述のプロセス５００Ａに従ってＲＲＤＢファイルをあらかじめ作成しておくことが可能である。
【００７６】
判定ブロック５１８では、別の生理学的パラメータが測定されたかどうかを判定する。別の生理学的パラメータが測定された場合は、ブロック５１９で、別のパラメータ記述子を生理学的データに関連付け、ブロック５２０で、関連付けられた生理学的データを再度ＲＲＤＢに供給する。ブロック５１８〜５２０は、ＲＲＤＢモジュール２４４によって実装可能である。一例として、ブロック５１２で測定したパラメータに、ＳｐＯ２およびＥＣＧが含まれるとする。ブロック５１４で与えられるパラメータ記述子は、「ＳＰＯ２」および「ＥＣＧ」である。ブロック５１８で、臨床担当者が監視装置でのＳｐＨｂパラメータ測定を有効化した場合、ブロック５１９で生理学的データに関連付けられたパラメータ記述子は、「ＳＰＯ２」と「ＥＣＧ」と「ＳＰＨＢ」とを含むことになる。
【００７７】
この新しく関連付けられた生理学的データがブロック５２０で送信されると、ＭＭＳは、生理学的データ内で識別された新しいパラメータ記述子を有する新しいＲＲＤＢファイルを作成することが可能である。このように、患者監視装置は、ＲＲＤＢに供給される生理学的データおよび関連付けられた記述子を動的に調節することが可能である。
【００７８】
図５Ｃは、患者監視装置に対応するＲＲＤＢ記憶領域を動的に調節するプロセス５００Ｃの実施形態を示す。一実施形態では、プロセス５００Ｃは、上述のどのＭＭＳによっても（たとえば、ＭＭＳ １２０または２２０によって）実装可能である。具体的には、プロセス５００Ｃは、ＲＲＤＢ管理モジュール２２３によって実装可能である。代替として、少なくともいくつかのブロックは、患者監視装置２４０のＲＲＤＢモジュール２４４によって実装可能である。
【００７９】
図３に関して上述したように、ＲＲＤＢファイルのサイズをあらかじめ決定して、増えないようにすることが可能である。このようにサイズを一定にすると、生理学的動向データの記憶量をあらかじめ決定することが可能である。ＲＲＤＢファイルのサイズは、たとえば、患者が入院した時点で構成可能である。一例として、ＲＲＤＢのサイズが、７２時間分のデータに対応するとする。しかしながら、病状が重い患者の場合は、追加の動向データが必要になる可能性がある。ところが、ＲＲＤＢファイルが一定サイズであると、この例の７２時間が経過した後は動向データが上書きされる。有利なこととして、特定の実施形態では、プロセス５００Ｃは、追加の動向データをＲＲＤＢに書き込むことを可能にしている。したがって、特定の実施形態では、ＲＲＤＢを、適応ＲＲＤＢまたは動的ＲＲＤＢと見なすことができる。
【００８０】
ブロック５３２では、ＲＲＤＢファイルの初期サイズを割り当てる。初期ファイルのサイズは、患者の予定入院期間、患者の現在の健康状態などに基づいて選択可能である。代替として、すべての患者について、ファイルサイズをあらかじめ定義することも可能である。ブロック５３４では、患者監視装置から受信した生理学的データを分析して、患者の病状の重さを判定する。患者の病状の重さを判定するには、たとえば、患者のプレチスモグラフの変動性に対応する、患者のＰＶＩを分析する。ＰＶＩまたは変動性が高い患者については、追加の動向データが有用になる。病状の重さを判定する際に検討可能な他の値として、（上述のとおりに組み込まれている米国特許第７０２４２３３号明細書に記載の）データ信頼度指標、脈拍数、ＳｐＯ２変動性、および他の任意の生理学的パラメータの変形形態などがある。さらに、実施形態によっては、複数アラームまたは重篤アラームの履歴があれば病状が重いことを意味するように患者のアラーム履歴を評価することによって、病状の重さを判定することが可能である。
【００８１】
判定ブロック５３６で、患者の病状が著しく重いかどうかを判定する。患者の病状が著しく重い場合は、ブロック５３８で、ＲＲＤＢデータ用の追加の記憶領域を割り当てる。この初期記憶領域の割り当ては、新規ファイルを作成することなどではなく、ＲＲＤＢファイルの長さを拡張することによって可能である。一方、患者の病状が著しくは重くない場合、プロセス５００Ｃは終了する。
【００８２】
図６Ａは、医療イベントをジャーナルデータベースにジャーナルするプロセス６００Ａの実施形態を示す。一実施形態では、プロセス６００Ａは、上述のどのＭＭＳによっても（たとえば、ＭＭＳ １２０または２２０によって）実装可能である。具体的には、プロセス６００Ａは、ジャーナル管理モジュール２２５によって実装可能である。代替として、少なくともいくつかのブロックは、ジャーナルモジュール２３６、２４６によって実装可能である。有利なこととして、特定の実施形態では、プロセス６００Ａは、ジャーナルデータに基づいてレポートを生成することを容易にする。
【００８３】
ブロック６０２では、医療イベントをジャーナルデータベースにジャーナルする。ブロック６０４では、ユーザ（たとえば、臨床担当者）からレポートが要求されると、医療イベントに関する統計をジャーナルデータベースから取得する。この統計に含まれるのは、医療イベントのタイプ、頻度、継続時間、そのイベントに関連する臨床担当者または患者の識別情報、アラーム応答時間、これらの組み合わせなどである。
【００８４】
ブロック６０６で、医療イベント統計に関するレポートを生成する。ブロック６０８で、そのレポートを用いて、病院業務の改善の可能性がある領域をつきとめる。たとえば、レポートは、病院または病院の臨床担当者に対し、その能力に応じたスコアを割り当てる「監視レポートカード」であってよい。
【００８５】
図６Ｂは、ジャーナルデータベースのデータとＲＲＤＢのデータとを互いに関連付けるプロセス６００Ｂの実施形態を示す。一実施形態では、プロセス６００Ｂは、上述のどのＭＭＳによっても（たとえば、ＭＭＳ １２０または２２０によって）実装可能である。具体的には、プロセス６００Ｂは、ＲＲＤＢモジュール２２３およびジャーナル管理モジュール２２５によって実装可能である。代替として、少なくともいくつかのブロックは、ＲＲＤＢモジュール２４４およびジャーナルモジュール２３６、２４６によって実装可能である。有利なこととして、特定の実施形態では、プロセス６００Ｂは、ＲＲＤＢの生理学的情報と、医療イベントとを、時間的に相互に関連付けることを可能にする。このような、イベントと生理学的データとの再構築は、航空機の「ブラックボックス」技術のように、医療インシデントに至った臨床アクションをユーザが再生できるようにすることが可能である。
【００８６】
ブロック６０２では、ある期間に対応する、ジャーナルされた生理学的データをレビューする要求をユーザから受信する。ユーザは、患者の健康管理における問題の原因を探ろうとする臨床担当者、病院管理者などであってよい。たとえば、ユーザは、患者のＳｐＯ２が安全レベルを下回ったときに臨床担当者が対応できなかった理由を探ろうとすることが可能である。
【００８７】
ブロック６０４で、指定の期間に対応するジャーナルされたデータをジャーナルデータベースから取り出す。このブロックは、ジャーナル管理モジュール２２５によって実行可能である。ブロック６０６で、指定の期間に対応する生理学的データをＲＲＤＢから取り出す。このブロックは、ＲＲＤＢ管理モジュール２２３によって実行可能である。ブロック６０８では、ジャーナルデータと、生理学的データとを、時間に関して相互に関連付ける。この相互の関連付けは、タイムライン上の正しい時間シーケンスにおいて与えられた生理学的パラメータの値（必要に応じて波形を含む）に対して、医療イベントのタイムラインを再構築することを含むことが可能である。実施形態によっては、この、ＲＲＤＢ管理モジュール２２３とジャーナル管理モジュール２２５との間の調整を容易にするために、各データベース２２２、２２４のタイムスタンプを、データの格納時に同期させることが可能である。
【００８８】
ブロック６１０では、相互に関連付けられたデータを、ユーザへの表示のために出力する。この出力は、たとえば、生理学的情報の上に重ねられた、医療イベントのグラフィカルビュー（たとえば、波形）などであってよい。この相互に関連付けられたデータに対して、様々な表示形式が使用可能である。
【００８９】
図７は、患者を監視するためのグラフィカル・ユーザ・インターフェース（ＧＵＩ）７００の一例を示す。ＧＵＩ ７００は、看護師詰所システムなどに設けることが可能である。ＧＵＩ ７００を、臨床担当者端末上に表示させることも可能である。
【００９０】
ＧＵＩ ７００には、いくつかの表示領域がある。図示した実施形態では、ＧＵＩ ７００は、患者状態表示領域７１０を含んでいる。患者状態表示領域７１０は、院内または別の臨床場所にいる複数の患者の状態を示す。一実施形態では、患者状態表示領域７１０は、一診療科の患者の患者状態を表示する。有利なこととして、特定の実施形態では、患者状態表示領域７１０は、複数の患者の健康状態が「一目でわかる」ビューを提供する。
【００９１】
患者状態表示領域７１０は、複数の患者状態モジュール７１２を含んでいる。各患者状態モジュール７１２は、医療患者につなぐことが可能な患者監視装置に対応することが可能である。各患者状態モジュール７１２は、グラフィカル状態インジケータ７１４を表示することが可能である。画面７００では、グラフィカル状態インジケータ７１４の一例を、小さな患者監視装置アイコンで示している。グラフィカル状態インジケータ７１４は、患者監視装置の複数の状態のうちの１つを選択的に示すことが可能である。一実施形態では、グラフィカル状態インジケータ７１４は、患者監視装置の４つの可能な状態を示すことが可能である。これらには、アラーム状態、非アラーム状態、患者状況情報状態、および接続状態が含まれる。
【００９２】
様々な実装において、グラフィカル状態インジケータ７１４は、色、形状、その他を変化させて、患者監視装置の様々な状態のうちの１つを示す。たとえば、アラーム状態が存在する場合、グラフィカル状態インジケータ７１４は、赤色になってアラームを示すことが可能である。患者に関して使用可能な状況情報がない場合（図１を参照）、グラフィカル状態インジケータ７１４は、黄色に変わることが可能である。患者監視装置が患者またはネットワークにつながっていない場合、グラフィカル状態インジケータ７１４は、灰色に変わることが可能である。非アラーム状態であって、状況情報があり、患者監視装置が患者およびネットワークにつながっている場合、グラフィカル状態インジケータ７１４は、緑色に変わることが可能である。上述の実施形態の代わりに（または上述の実施形態との組み合わせで）、他の様々な色、シンボル、および／または形状を用いることが可能である。
【００９３】
有利なこととして、グラフィカル状態インジケータ７１４は、患者監視装置の状態を、一目でわかるように表示する。したがって、患者状態表示領域７１０においては、複数の患者に対応する複数のグラフィカル状態インジケータ７１４が、これらの患者に対応する患者監視装置についての一目でわかるビューを表示する。これにより、アラーム、接続状態、および状況情報に関して患者が持っているニーズを、臨床担当者は容易に知ることが可能である。
【００９４】
現行の看護師詰所コンピュータ用のグラフィカル・ユーザ・インターフェースは、各患者ごとに複数の波形または変化する生理学的パラメータの数字を表示する傾向がある。このような、患者情報の表示方式は、状況によっては、詰め込み過ぎで見にくく、混乱を招き、眠気すら誘う可能性がある。たとえば、夜間シフトで勤務中の看護師は、ディスプレイ上で他の複数の患者のインジケータの数字や波形などが変化している中でアラームに集中することが困難な場合がある。これに対し、本明細書に記載のグラフィカルインターフェースでは、グラフィカル状態インジケータ７１４がアラーム状態を示すと、このアラーム状態は、目立つように表示されて、臨床担当者にただちに認識されることが可能である。
【００９５】
さらに、グラフィカル状態インジケータ７１４によって、看護師が行うことが多い最初のレベルの分析が簡略化される。現行の装置では、多くの場合、看護師は、看護師詰所で波形を分析して患者の健康状態を判定しなければならない。これに対し、画面７００を用いた場合、看護師は、患者の波形または変化するパラメータを解釈する必要がまったくなく、アラームの有無を示すグラフィカル状態インジケータ７１４を頼りにすることが可能である。
【００９６】
特定の実施形態では、１回のマウスクリックまたは同様の操作で患者状態モジュール７１２を選択することが可能である。一実施形態では、患者状態モジュール７１２を選択することにより、患者監視装置ビュー領域７２０を表示することが可能である。患者監視装置ビュー領域７２０は、選択された患者状態モジュール７１２に対応する患者監視装置のビューを表示する。特定の実装では、患者監視装置ビュー領域７２０は、患者のベッドサイドにある実際の患者監視装置の画面のビューを表示することが可能である。これにより、臨床担当者は、患者の生理学的パラメータを、見慣れた表示形式で容易に認識することが可能である。図７の患者監視装置ビュー領域７２０は、患者から生理学的情報を受信している様子を示している。
【００９７】
特定の実装では、履歴ビュー領域７３０が、選択された患者監視装置状態モジュール７１２に対応する医療イベントデータを表示することが可能である。この医療イベントデータは、ジャーナルデータベースから取得して、ＧＵＩ ７００に含めることが可能である。履歴ビュー領域７３０は、たとえば、いつセンサを患者につないだか、またはいつ患者から外したか、いつアラームがアクティブだったか、患者がいつ病院または診療科に入院したか、などを表示することが可能である。図示していないが、履歴ビュー領域７３０は、ジャーナルされたデータの代わりに、または、ジャーナルされたデータに加えてＲＲＤＢから取得した動向データを表示するようにも構成可能である。
【００９８】
実施形態によっては、本明細書に記載のすべての方法におけるいくつかのアクション、イベント、またはファンクションは、別のシーケンスで実行したり、追加したり、マージしたり、まとめて除去したりすることが可能である（たとえば、記載したアクションまたはイベントのすべてが本方法の実施に必須というわけではない）。さらに、特定の実施形態では、複数のアクションまたはイベントを、順次実行するのではなく、同時に実行することが可能であり、これは、たとえば、マルチスレッド処理、割り込み処理、あるいは複数のプロセッサにより可能である。
【００９９】
本明細書で開示した実施形態に関連して記載した、各種の例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両者の組み合わせとして実装可能である。このハードウェアとソフトウェアとの互換性を明確に示すために、各種の例示的なコンポーネント、ブロック、モジュール、回路、およびステップを、主にそれらの機能性の観点から説明してきた。そのような機能性をハードウェアとして実装するか、ソフトウェアとして実装するかは、個々の用途、およびシステム全体に課せられた設計制約によって決まる。記載した機能性は、個々の用途ごとに様々な様式で実装可能であるが、そのような実装の決定は、本開示の範囲からの逸脱を引き起こすものと解釈されてはならない。
【０１００】
本明細書で開示した実施形態に関連して記載した、各種の例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブル論理素子、ディスクリートゲートまたはトランジスタ論理、ディスクリートハードウェア部品、または、本明細書に記載の機能を実行するように設計された、これらの任意の組み合わせにより、実装または実行が可能である。汎用プロセッサはマイクロプロセッサであってよいが、代替として、汎用プロセッサは、任意の従来型プロセッサ、コントローラ、マイクロコントローラ、または状態機械であってもよい。プロセッサは、コンピューティング装置同士の組み合わせ（たとえば、ＤＳＰとマイクロプロセッサとの組み合わせ）、複数のマイクロプロセッサ、ＤＳＰコアと組み合わされた１つまたは複数のマイクロプロセッサ、または他の任意のそのような構成として実装することも可能である。
【０１０１】
本明細書で開示した実施形態に関連して記載した方法またはアルゴリズムの各ステップは、ハードウェアの形で、またはプロセッサで実行されるソフトウェアモジュールの形で、あるいは両者の組み合わせの形で直接実施可能である。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、または他の任意の、当該技術分野では周知の形式の記憶媒体に常駐可能である。プロセッサが記憶媒体から情報を読み出したり、記憶媒体に情報を書き込んだりできるように、プロセッサに例示的記憶媒体を接続している。代替として、記憶媒体は、プロセッサと一体であってもよい。プロセッサおよび記憶媒体は、ＡＳＩＣに組み込まれてよい。ＡＳＩＣは、ユーザ端末内にあってよい。代替として、プロセッサおよび記憶媒体は、ユーザ端末内にディスクリート部品として存在してよい。
【０１０２】
本明細書で用いている条件付き語句（特に「ｃａｎ」、「ｃｏｕｌｄ」、「ｍｉｇｈｔ」、「ｍａｙ」、「ｅ．ｇ．，」など）は、特に断らない限り、あるいは、用いられている文脈で他の解釈がない限り、一般に、いくつかの実施形態では特定の特徴、要素、および／またはステップを含み、他の実施形態では含まない、ということを意味するものとする。したがって、このような条件付き語句は、１つまたは複数の実施形態において、特徴、要素、および／またはステップが何らかの形で必須であること、または、これらの特徴、要素、および／またはステップが任意の個々の実施形態において含まれるかもしくは実行されるべきであるかどうかを、作成者入力またはプロンプティングの有無にかかわらず、判定する論理を、１つまたは複数の実施形態が必ず含むことを意味することを一般に意図するものではない。
【０１０３】
ここまでの詳細説明において、新規な特徴を、各種実施形態に適用する形で図示し、説明し、指摘してきたが、例示した装置またはプロセスの形態および細部において様々な省略、置換、および変更を、本開示の趣旨から逸脱することなく行うことが可能であることが理解されよう。認識されるように、本明細書に記載の、本発明の特定の実施形態は、本発明で説明した特徴および利点のすべてを提供するわけではない形態で実施可能であり、これは、いくつかの特徴が、他の特徴とは切り離して利用または実践することが可能であるためである。本発明の範囲は、前述の説明によってではなく、添付の特許請求の範囲によって示されている。特許請求の範囲の等化物の意味および範囲に含まれるすべての変更は、特許請求の範囲に含まれるものとする。
【特許請求の範囲】
【請求項１】
１つまたは複数の臨床担当者監視詰所と通信している複数の患者監視装置を有する多患者監視環境において、医療患者から取得された生理学的情報を格納する方法であって、
ネットワークを介して患者監視装置から識別情報を受信するステップであって、前記患者監視装置は、医療患者につながれた１つまたは複数のセンサから取得された生理学的データを処理するように動作する１つまたは複数の処理装置を有する、前記ステップと、
前記識別情報を受信して、前記識別情報に少なくとも部分的に基づいて、前記患者監視装置に対応する第１のパラメータ記述子を取り出すステップであって、各第１のパラメータ記述子は、前記患者監視装置によって測定可能なパラメータを識別するように動作する、前記ステップと、
前記第１のパラメータ記述子を有するヘッダを有するラウンドロビンデータベース（ＲＲＤＢ）ファイルを作成するステップと、
前記患者監視装置から前記生理学的データを受信するステップであって、前記生理学的データは、前記生理学的データを識別するように動作する第２のパラメータ記述子を有する、前記ステップと、
前記患者監視装置から受信された第２のパラメータ記述子に少なくとも部分的に基づき、前記ヘッダ内の前記第１のパラメータ記述子を用いて、前記生理学的データを前記ＲＲＤＢファイル内のロケーションにマッピングするステップと、
を含む方法。
【請求項２】
前記第１および第２のパラメータ記述子は、拡張可能マークアップ言語（ＸＭＬ）仕様を実装する、請求項１に記載の方法。
【請求項３】
前記ヘッダ内の前記第１のパラメータ記述子を用いて、前記生理学的データを前記ＲＲＤＢファイル内のロケーションにマッピングするステップは、前記生理学的データを前記ＲＲＤＢファイルのレコードに格納することを含む、請求項１に記載の方法。
【請求項４】
前記ＲＲＤＢファイルの前記レコードは、前記第２のパラメータ記述子を含まない、請求項１に記載の方法。
【請求項５】
前記患者の病状の重さの判定に応じて、前記ＲＲＤＢファイルのサイズを動的に調節するステップをさらに含む、請求項１に記載の方法。
【請求項６】
前記患者の前記病状の重さを判定することは、プレチスモグラフ変動指数を分析することを含む、請求項５に記載の方法。
【請求項７】
前記患者の前記病状の重さを判定することは、データ信頼度指標を分析することを含む、請求項５に記載の方法。
【請求項８】
前記患者の病状の重さの判定に応じて、第２のＲＲＤＢファイルを動的に作成するステップをさらに含む、請求項１に記載の方法。
【請求項９】
前記患者監視装置から第３のパラメータ記述子を受信して、前記第３のパラメータ記述子を有する第２のヘッダを有する第２のＲＲＤＢファイルを自動的に作成するステップをさらに含む、請求項１に記載の方法。
【請求項１０】
複数の医療装置から医療データをジャーナルする方法であって、
臨床ネットワークを介して複数の医療装置からメッセージを受信するステップであって、前記医療装置は患者監視装置を有し、各患者監視装置は、医療患者につながれた１つまたは複数のセンサから受信される生理学的情報を処理するように動作する１つまたは複数の処理装置を有する、前記ステップと、
前記メッセージを処理して、前記メッセージのそれぞれに記載された医療イベントを特定するステップであって、前記医療イベントは、
臨床担当者と、前記医療装置のうちの選択された１つとの対話に応じて発生する第１の装置イベントと、
臨床担当者と前記選択された医療装置との対話がなくても発生する第２の装置イベントと、のうちの１つまたは複数を有する、前記ステップと、
前記１つまたは複数の医療イベントに関する情報を、物理的コンピュータ記憶装置を有するジャーナルデータベースに格納するステップと、
医療イベントレポートの要求に対する応答として、前記ジャーナルデータベースに格納されている前記医療イベントに関する医療統計を取得するステップと、
前記医療統計を有するレポートを生成するステップと、
を含む方法。
【請求項１１】
前記第１の装置イベントは、アラーム動作停止、アラームリミットの変更、看護師詰所システムに対する臨床担当者のログオンまたはログオフ、患者の入院、および患者の退院のうちの１つを含む、請求項１０に記載の方法。
【請求項１２】
前記第２の装置イベントはアラームを含む、請求項１０に記載の方法。
【請求項１３】
１つまたは複数の医療イベントの数を格納するように動作する１つまたは複数のイベントカウンタを前記ジャーナルデータベースに格納するステップをさらに含む、請求項１０に記載の方法。
【請求項１４】
前記医療イベントに関する医療統計を取得するステップは、選択されたイベントカウンタにアクセスすることを含む、請求項１３に記載の方法。
【請求項１５】
前記レポートを生成するステップは、監視レポートカードを生成することを含む、請求項１３に記載の方法。
【請求項１６】
前記レポートを生成するステップは、臨床担当者間でアラーム応答時間を比較することを含む、請求項１３に記載の方法。
【請求項１７】
前記レポートを生成するステップは、病院間でアラーム応答時間を比較することを含む、請求項１３に記載の方法。
【請求項１８】
医療患者から取得された生理学的情報のタイプを動的に調節する方法であって、
医療患者につながれた１つまたは複数のセンサで測定される生理学的信号を処理するように動作する１つまたは複数の処理装置を用いて、前記患者の１つまたは複数の第１の生理学的パラメータに対応する第１の生理学的データを取得するステップと、
前記第１の生理学的データを、前記第１の生理学的データの中の前記１つまたは複数の第１の生理学的パラメータを説明するように動作する第１のパラメータ記述子と自動的に関連付けて、第１の関連付けられた生理学的データを生成するステップと、
前記第１の関連付けられた生理学的データをラウンドロビンデータベースに供給するステップであって、前記第１のパラメータ記述子は、前記ラウンドロビンデータベース内の前記第１の生理学的データを説明するように動作し、前記ラウンドロビンデータベースは物理的コンピュータ記憶装置を有する、前記ステップと、
前記医療患者の１つまたは複数の第２の生理学的パラメータに対応する第２の生理学的データを取得するステップと、
前記第２の生理学的データを第２のパラメータ記述子と自動的に関連付けて、第２の関連付けられた生理学的データを生成するステップと、
前記第２の関連付けられた生理学的データを前記ラウンドロビンデータベースに供給するステップと、
を含む方法。
【請求項１９】
前記第１および第２のパラメータ記述子は、拡張可能マークアップ言語（ＸＭＬ）仕様を実装する、請求項１８に記載の方法。
【請求項２０】
前記第１の関連付けられた生理学的データをラウンドロビンデータベースに供給するステップは、前記関連付けられた生理学的データを、臨床ネットワークを介して多患者監視システムに送信することを含む、請求項１８に記載の方法。
【請求項２１】
所与の期間に対応する、複数の医療装置から受信された医療イベントおよび生理学的データを再構築するシステムであって、
ある期間に対応する、ジャーナルされた医療データと生理学的データとをレビューする要求をユーザから受信するように動作する１つまたは複数の物理的コンピューティング装置を有するサーバシステムであって、前記生理学的データは、１つまたは複数の患者監視装置から取得され、各患者監視装置は、医療患者につながれた１つまたは複数のセンサから受信される生理学的情報を処理するように動作する１つまたは複数の処理装置を有する、前記サーバシステムを有し、
前記サーバシステムは、
前記指定された期間に対応する前記ジャーナルされた医療データをジャーナルデータベースから取り出すステップであって、前記ジャーナルデータベースは、第１の物理的コンピュータ記憶装置を有し、前記ジャーナルされた医療データは、
臨床担当者と前記１つまたは複数の患者監視装置との対話に応じて発生する第１の装置イベントと、
臨床担当者と前記１つまたは複数の患者監視装置との対話がなくても発生する第２の装置イベントと、のうちの１つまたは複数を有する、前記ステップと、
前記指定された期間に対応する生理学的データを、第２の物理的コンピュータ記憶装置を有するラウンドロビンデータベースから取り出すステップと、
前記ジャーナルされた医療データと、前記生理学的データとを、時間に関して相互に関連付けるステップと、
前記相互に関連付けられた、ジャーナルされたデータと生理学的データとを、前記ユーザへの表示のために出力するステップと、を行うように構成された、
システム。
【請求項２２】
医療患者から取得された生理学的情報を格納するシステムであって、
ネットワーク管理モジュールであって、
ネットワークを介して患者監視装置から識別情報を受信するステップであって、前記患者監視装置は、医療患者につながれた１つまたは複数のセンサから取得された生理学的データを処理するように動作する１つまたは複数の処理装置を有する、前記ステップと、
前記患者監視装置から前記生理学的データを受信するステップであって、前記生理学的データは、前記生理学的データを識別するように動作する第１のパラメータ記述子を有する、前記ステップと、を行うように動作する前記ネットワーク管理モジュールと、
ラウンドロビンデータベース（ＲＲＤＢ）コンポーネントであって、前記ネットワーク管理モジュールから前記識別情報を受信して、
前記識別情報に少なくとも部分的に基づいて、前記患者監視装置に対応する第２のパラメータ記述子を取り出すステップであって、各第２のパラメータ記述子は、前記患者監視装置によって測定可能なパラメータを識別するように動作する、前記ステップと、
前記第２のパラメータ記述子を有するヘッダを有するＲＲＤＢファイルを作成するステップと、
前記患者監視装置から受信された第１のパラメータ記述子に少なくとも部分的に基づき、前記ヘッダ内の前記第２のパラメータ記述子を用いて、前記生理学的データを前記ＲＲＤＢファイル内のロケーションにマッピングするステップと、を行うように動作する前記ＲＲＤＢコンポーネントと、
を含むシステム。
【請求項２３】
前記第１および第２のパラメータ記述子は、拡張可能マークアップ言語（ＸＭＬ）仕様を実装する、請求項２２に記載のシステム。
【請求項２４】
前記ＲＲＤＢコンポーネントはさらに、前記ヘッダ内の前記第１のパラメータ記述子を用いて、前記生理学的データを前記ＲＲＤＢファイルのレコードに格納することにより、前記生理学的データを前記ＲＲＤＢファイル内のロケーションにマッピングするように動作する、請求項２２に記載のシステム。
【請求項２５】
前記ＲＲＤＢファイルの前記レコードは、前記第２のパラメータ記述子を含まない、請求項２２に記載の方法。
【請求項２６】
医療データベースに供給される生理学的情報を動的に調節する方法であって、
複数の患者の生理学的情報を格納するように動作する適応ラウンドロビンデータベース（ＲＲＤＢ）を設けるステップと、
患者監視装置と通信して、患者の第１の病状の重さの第１の表示を受信するステップであって、前記患者監視装置は、医療患者につながれた１つまたは複数のセンサから取得された生理学的データを処理するように動作する１つまたは複数の処理装置を有する、前記ステップと、
受信した前記第１の表示に対する応答として、第１の量の生理学的情報を前記適応ＲＲＤＢに供給するステップと、
前記患者の第２の病状の重さの第２の表示を受信するステップであって、前記第２の病状の重さは、前記第１の病状の重さより重い、前記ステップと、
受信した前記第２の表示に対する応答として、前記第１の量の生理学的情報より多い第２の量の生理学的情報を前記適応ＲＲＤＢに供給することによって、前記適応ＲＲＤＢに供給される前記データ量を適応させるステップと、
を含む方法。
【請求項２７】
前記患者の前記第１および第２の病状の重さを判定することは、プレチスモグラフ変動指数を分析することを含む、請求項２６に記載の方法。
【請求項２８】
前記患者の前記第１および第２の病状の重さを判定することは、データ信頼度指標を分析することを含む、請求項２６に記載の方法。
【請求項２９】
前記患者の前記第１および第２の病状の重さを判定することは、前記患者のアラーム履歴を分析することを含む、請求項２６に記載の方法。
【請求項３０】
第１の量の生理学的情報を前記適応ＲＲＤＢに供給するステップは、前記生理学的情報のための第１のＲＲＤＢファイルを作成することを含む、請求項２６に記載の方法。
【請求項３１】
前記適応ＲＲＤＢに供給される前記データ量を適応させるステップは、前記患者監視装置、前記患者監視装置によって監視されるパラメータ、および生理学的データのチャネルのうちの１つまたは複数に対応する１つまたは複数の追加ＲＲＤＢファイルを作成することを含む、請求項３０に記載の方法。
【請求項１】
１つまたは複数の臨床担当者監視詰所と通信している複数の患者監視装置を有する多患者監視環境において、医療患者から取得された生理学的情報を格納する方法であって、
ネットワークを介して患者監視装置から識別情報を受信するステップであって、前記患者監視装置は、医療患者につながれた１つまたは複数のセンサから取得された生理学的データを処理するように動作する１つまたは複数の処理装置を有する、前記ステップと、
前記識別情報を受信して、前記識別情報に少なくとも部分的に基づいて、前記患者監視装置に対応する第１のパラメータ記述子を取り出すステップであって、各第１のパラメータ記述子は、前記患者監視装置によって測定可能なパラメータを識別するように動作する、前記ステップと、
前記第１のパラメータ記述子を有するヘッダを有するラウンドロビンデータベース（ＲＲＤＢ）ファイルを作成するステップと、
前記患者監視装置から前記生理学的データを受信するステップであって、前記生理学的データは、前記生理学的データを識別するように動作する第２のパラメータ記述子を有する、前記ステップと、
前記患者監視装置から受信された第２のパラメータ記述子に少なくとも部分的に基づき、前記ヘッダ内の前記第１のパラメータ記述子を用いて、前記生理学的データを前記ＲＲＤＢファイル内のロケーションにマッピングするステップと、
を含む方法。
【請求項２】
前記第１および第２のパラメータ記述子は、拡張可能マークアップ言語（ＸＭＬ）仕様を実装する、請求項１に記載の方法。
【請求項３】
前記ヘッダ内の前記第１のパラメータ記述子を用いて、前記生理学的データを前記ＲＲＤＢファイル内のロケーションにマッピングするステップは、前記生理学的データを前記ＲＲＤＢファイルのレコードに格納することを含む、請求項１に記載の方法。
【請求項４】
前記ＲＲＤＢファイルの前記レコードは、前記第２のパラメータ記述子を含まない、請求項１に記載の方法。
【請求項５】
前記患者の病状の重さの判定に応じて、前記ＲＲＤＢファイルのサイズを動的に調節するステップをさらに含む、請求項１に記載の方法。
【請求項６】
前記患者の前記病状の重さを判定することは、プレチスモグラフ変動指数を分析することを含む、請求項５に記載の方法。
【請求項７】
前記患者の前記病状の重さを判定することは、データ信頼度指標を分析することを含む、請求項５に記載の方法。
【請求項８】
前記患者の病状の重さの判定に応じて、第２のＲＲＤＢファイルを動的に作成するステップをさらに含む、請求項１に記載の方法。
【請求項９】
前記患者監視装置から第３のパラメータ記述子を受信して、前記第３のパラメータ記述子を有する第２のヘッダを有する第２のＲＲＤＢファイルを自動的に作成するステップをさらに含む、請求項１に記載の方法。
【請求項１０】
複数の医療装置から医療データをジャーナルする方法であって、
臨床ネットワークを介して複数の医療装置からメッセージを受信するステップであって、前記医療装置は患者監視装置を有し、各患者監視装置は、医療患者につながれた１つまたは複数のセンサから受信される生理学的情報を処理するように動作する１つまたは複数の処理装置を有する、前記ステップと、
前記メッセージを処理して、前記メッセージのそれぞれに記載された医療イベントを特定するステップであって、前記医療イベントは、
臨床担当者と、前記医療装置のうちの選択された１つとの対話に応じて発生する第１の装置イベントと、
臨床担当者と前記選択された医療装置との対話がなくても発生する第２の装置イベントと、のうちの１つまたは複数を有する、前記ステップと、
前記１つまたは複数の医療イベントに関する情報を、物理的コンピュータ記憶装置を有するジャーナルデータベースに格納するステップと、
医療イベントレポートの要求に対する応答として、前記ジャーナルデータベースに格納されている前記医療イベントに関する医療統計を取得するステップと、
前記医療統計を有するレポートを生成するステップと、
を含む方法。
【請求項１１】
前記第１の装置イベントは、アラーム動作停止、アラームリミットの変更、看護師詰所システムに対する臨床担当者のログオンまたはログオフ、患者の入院、および患者の退院のうちの１つを含む、請求項１０に記載の方法。
【請求項１２】
前記第２の装置イベントはアラームを含む、請求項１０に記載の方法。
【請求項１３】
１つまたは複数の医療イベントの数を格納するように動作する１つまたは複数のイベントカウンタを前記ジャーナルデータベースに格納するステップをさらに含む、請求項１０に記載の方法。
【請求項１４】
前記医療イベントに関する医療統計を取得するステップは、選択されたイベントカウンタにアクセスすることを含む、請求項１３に記載の方法。
【請求項１５】
前記レポートを生成するステップは、監視レポートカードを生成することを含む、請求項１３に記載の方法。
【請求項１６】
前記レポートを生成するステップは、臨床担当者間でアラーム応答時間を比較することを含む、請求項１３に記載の方法。
【請求項１７】
前記レポートを生成するステップは、病院間でアラーム応答時間を比較することを含む、請求項１３に記載の方法。
【請求項１８】
医療患者から取得された生理学的情報のタイプを動的に調節する方法であって、
医療患者につながれた１つまたは複数のセンサで測定される生理学的信号を処理するように動作する１つまたは複数の処理装置を用いて、前記患者の１つまたは複数の第１の生理学的パラメータに対応する第１の生理学的データを取得するステップと、
前記第１の生理学的データを、前記第１の生理学的データの中の前記１つまたは複数の第１の生理学的パラメータを説明するように動作する第１のパラメータ記述子と自動的に関連付けて、第１の関連付けられた生理学的データを生成するステップと、
前記第１の関連付けられた生理学的データをラウンドロビンデータベースに供給するステップであって、前記第１のパラメータ記述子は、前記ラウンドロビンデータベース内の前記第１の生理学的データを説明するように動作し、前記ラウンドロビンデータベースは物理的コンピュータ記憶装置を有する、前記ステップと、
前記医療患者の１つまたは複数の第２の生理学的パラメータに対応する第２の生理学的データを取得するステップと、
前記第２の生理学的データを第２のパラメータ記述子と自動的に関連付けて、第２の関連付けられた生理学的データを生成するステップと、
前記第２の関連付けられた生理学的データを前記ラウンドロビンデータベースに供給するステップと、
を含む方法。
【請求項１９】
前記第１および第２のパラメータ記述子は、拡張可能マークアップ言語（ＸＭＬ）仕様を実装する、請求項１８に記載の方法。
【請求項２０】
前記第１の関連付けられた生理学的データをラウンドロビンデータベースに供給するステップは、前記関連付けられた生理学的データを、臨床ネットワークを介して多患者監視システムに送信することを含む、請求項１８に記載の方法。
【請求項２１】
所与の期間に対応する、複数の医療装置から受信された医療イベントおよび生理学的データを再構築するシステムであって、
ある期間に対応する、ジャーナルされた医療データと生理学的データとをレビューする要求をユーザから受信するように動作する１つまたは複数の物理的コンピューティング装置を有するサーバシステムであって、前記生理学的データは、１つまたは複数の患者監視装置から取得され、各患者監視装置は、医療患者につながれた１つまたは複数のセンサから受信される生理学的情報を処理するように動作する１つまたは複数の処理装置を有する、前記サーバシステムを有し、
前記サーバシステムは、
前記指定された期間に対応する前記ジャーナルされた医療データをジャーナルデータベースから取り出すステップであって、前記ジャーナルデータベースは、第１の物理的コンピュータ記憶装置を有し、前記ジャーナルされた医療データは、
臨床担当者と前記１つまたは複数の患者監視装置との対話に応じて発生する第１の装置イベントと、
臨床担当者と前記１つまたは複数の患者監視装置との対話がなくても発生する第２の装置イベントと、のうちの１つまたは複数を有する、前記ステップと、
前記指定された期間に対応する生理学的データを、第２の物理的コンピュータ記憶装置を有するラウンドロビンデータベースから取り出すステップと、
前記ジャーナルされた医療データと、前記生理学的データとを、時間に関して相互に関連付けるステップと、
前記相互に関連付けられた、ジャーナルされたデータと生理学的データとを、前記ユーザへの表示のために出力するステップと、を行うように構成された、
システム。
【請求項２２】
医療患者から取得された生理学的情報を格納するシステムであって、
ネットワーク管理モジュールであって、
ネットワークを介して患者監視装置から識別情報を受信するステップであって、前記患者監視装置は、医療患者につながれた１つまたは複数のセンサから取得された生理学的データを処理するように動作する１つまたは複数の処理装置を有する、前記ステップと、
前記患者監視装置から前記生理学的データを受信するステップであって、前記生理学的データは、前記生理学的データを識別するように動作する第１のパラメータ記述子を有する、前記ステップと、を行うように動作する前記ネットワーク管理モジュールと、
ラウンドロビンデータベース（ＲＲＤＢ）コンポーネントであって、前記ネットワーク管理モジュールから前記識別情報を受信して、
前記識別情報に少なくとも部分的に基づいて、前記患者監視装置に対応する第２のパラメータ記述子を取り出すステップであって、各第２のパラメータ記述子は、前記患者監視装置によって測定可能なパラメータを識別するように動作する、前記ステップと、
前記第２のパラメータ記述子を有するヘッダを有するＲＲＤＢファイルを作成するステップと、
前記患者監視装置から受信された第１のパラメータ記述子に少なくとも部分的に基づき、前記ヘッダ内の前記第２のパラメータ記述子を用いて、前記生理学的データを前記ＲＲＤＢファイル内のロケーションにマッピングするステップと、を行うように動作する前記ＲＲＤＢコンポーネントと、
を含むシステム。
【請求項２３】
前記第１および第２のパラメータ記述子は、拡張可能マークアップ言語（ＸＭＬ）仕様を実装する、請求項２２に記載のシステム。
【請求項２４】
前記ＲＲＤＢコンポーネントはさらに、前記ヘッダ内の前記第１のパラメータ記述子を用いて、前記生理学的データを前記ＲＲＤＢファイルのレコードに格納することにより、前記生理学的データを前記ＲＲＤＢファイル内のロケーションにマッピングするように動作する、請求項２２に記載のシステム。
【請求項２５】
前記ＲＲＤＢファイルの前記レコードは、前記第２のパラメータ記述子を含まない、請求項２２に記載の方法。
【請求項２６】
医療データベースに供給される生理学的情報を動的に調節する方法であって、
複数の患者の生理学的情報を格納するように動作する適応ラウンドロビンデータベース（ＲＲＤＢ）を設けるステップと、
患者監視装置と通信して、患者の第１の病状の重さの第１の表示を受信するステップであって、前記患者監視装置は、医療患者につながれた１つまたは複数のセンサから取得された生理学的データを処理するように動作する１つまたは複数の処理装置を有する、前記ステップと、
受信した前記第１の表示に対する応答として、第１の量の生理学的情報を前記適応ＲＲＤＢに供給するステップと、
前記患者の第２の病状の重さの第２の表示を受信するステップであって、前記第２の病状の重さは、前記第１の病状の重さより重い、前記ステップと、
受信した前記第２の表示に対する応答として、前記第１の量の生理学的情報より多い第２の量の生理学的情報を前記適応ＲＲＤＢに供給することによって、前記適応ＲＲＤＢに供給される前記データ量を適応させるステップと、
を含む方法。
【請求項２７】
前記患者の前記第１および第２の病状の重さを判定することは、プレチスモグラフ変動指数を分析することを含む、請求項２６に記載の方法。
【請求項２８】
前記患者の前記第１および第２の病状の重さを判定することは、データ信頼度指標を分析することを含む、請求項２６に記載の方法。
【請求項２９】
前記患者の前記第１および第２の病状の重さを判定することは、前記患者のアラーム履歴を分析することを含む、請求項２６に記載の方法。
【請求項３０】
第１の量の生理学的情報を前記適応ＲＲＤＢに供給するステップは、前記生理学的情報のための第１のＲＲＤＢファイルを作成することを含む、請求項２６に記載の方法。
【請求項３１】
前記適応ＲＲＤＢに供給される前記データ量を適応させるステップは、前記患者監視装置、前記患者監視装置によって監視されるパラメータ、および生理学的データのチャネルのうちの１つまたは複数に対応する１つまたは複数の追加ＲＲＤＢファイルを作成することを含む、請求項３０に記載の方法。
【図３】
【図４】
【図７】
【図１】
【図２】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図６Ａ】
【図６Ｂ】
【図４】
【図７】
【図１】
【図２】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図６Ａ】
【図６Ｂ】
【公表番号】特表２０１１−５０１２７４（Ｐ２０１１−５０１２７４Ａ）
【公表日】平成２３年１月６日（２０１１．１．６）
【国際特許分類】
【出願番号】特願２０１０−５２９１１７（Ｐ２０１０−５２９１１７）
【出願日】平成２０年１０月１０日（２００８．１０．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００８／０７９６４３
【国際公開番号】ＷＯ２００９／０４９２５４
【国際公開日】平成２１年４月１６日（２００９．４．１６）
【出願人】（５０３４２６９７２）マシモ コーポレイション (14)
【Ｆターム（参考）】
【公表日】平成２３年１月６日（２０１１．１．６）
【国際特許分類】
【出願日】平成２０年１０月１０日（２００８．１０．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００８／０７９６４３
【国際公開番号】ＷＯ２００９／０４９２５４
【国際公開日】平成２１年４月１６日（２００９．４．１６）
【出願人】（５０３４２６９７２）マシモ コーポレイション (14)
【Ｆターム（参考）】
[ Back to top ]