JP2019202156A - 医療監視データを表示するシステム - Google Patents

Abstract

【課題】患者を治療もしくは監視する様々な医療機器を協調させる解決策を提供する。【解決手段】第１の医療機器は、第２の医療機器から生理学的パラメータ値を受信できる。第２の生理学的パラメータ値は、第１の医療機器が第２の生理学的パラメータ値を処理して表示可能な出力値を生成することができないように、第１の医療機器によって使用されていないプロトコルに従ってフォーマットされることがある。第１の医療機器は、第１の医療機器から別個の翻訳モジュールに生理学的パラメータデータを渡し、第１の医療機器で翻訳モジュールから翻訳済みのパラメータデータを受信することができる。翻訳済みのパラメータデータは、第１の医療機器による表示のため処理され得る。第１の医療機器は、第１の医療機器もしくは補助機器への表示のため、翻訳済みのパラメータデータから値を出力することができる。【選択図】図２５

Description

相互参照

本出願は、２０１３年１０月１１日付けで出願された、“Ｓｙｓｔｅｍ ｆｏｒ Ｄｉｓｐｌａｙｉｎｇ Ｍｅｄｉｃａｌ Ｍｏｎｉｔｏｒｉｎｇ Ｄａｔａ”と題する米国仮出願第６１／８８９，９７２号の通常出願であり、かつ、２０１２年１０月１２日付けで出願された米国出願第１３／６５１，１６７号の一部継続出願でもあり、この米国出願は、以下の米国仮特許出願のそれぞれの通常出願である。
番号 日付 名称
61/547,077 2011年10月13日 Visual Correlation of Physiological Information
61/547,577 2011年10月14日 Visual Correlation of Physiological Information
61/597,120 2012年2月9日 Visual Correlation of Physiological Information
61/703,773 2012年9月20日 Medical Monitoring Hub

上記出願の全てが参照により全体がそのまま本明細書に組み込まれる。

本開示は、概して、患者監視機器に係わり、具体的には、患者監視および医療データ通信ハブに関する。

現在の患者監視環境は、特定の患者のための多種多様の監視および治療努力に役立つ高性能、かつ、多くの場合に電子式の医療機器で混み合っている。概して、これらの機器の全部ではないが多くは、異なる製造業者から提供され、多くのものは、携帯型機器であることがある。これらの機器は、相互に通信しないことがあり、各々は、独自のコントロール、ディスプレイ、アラーム、構成などを含むことがある。問題を複雑にしているのは、介護者は、多くの場合に、これらの機器からのあらゆる種類の測定および使用データを特定の患者に関連付けることを望む、ということである。それ故に、患者情報エントリは、多くの場合に、各機器に現れる。時には、機器の相違点により、介護者の再検討のため、単に各機器からの用紙を印刷し、患者のファイルに保管する必要性が生じる。

このような機器相違点の結果として、多くの場合に、ディスプレイおよびアラームが至る所に置かれ、無秩序状態であると考えられる体験をもたらす介護者環境が生じる。このような無秩序状態は、介護者の注意散漫が望ましくない術後環境を含み、および、患者の注意散漫もしくは心の動揺が望ましくないことがある回復もしくは監視環境を含む多くの状況において患者にとって有害である可能性がある。

様々な製造業者は、特有のシステムが達成できる様々な監視もしくは治療努力を高めるために、マルチモニタ機器もしくはモジュール拡張する機器を製造する。しかしながら、医療機器技術は、発展するので、このようなマルチモニタ機器は、設置された途端に陳腐化し始める。

この開示は、監視対象である患者に対する監視の中心としての医療監視ハブの実施形態について記載する。ハブは、患者の近くにある他の医療機器と通信するため設定可能な医療ポートおよびシリアルポートを含む可能性がある。その上に、ハブは、携帯型患者モニタと通信する可能性がある。モニタは、ハブとドッキング接続されたとき、ドッキング解除されたときとは異なる表示図形を提供することがある。表示図形は、解剖学的情報を含む可能性がある。ハブは、多くの場合に莫大な量の電子医療データを集め、これを監視対象である患者に関連付け、いくつかの実施形態では、データを患者の医療記録に渡す。

開示のいくつかの態様は、デジタル論理回路を有する第１の医療機器が生理学的センサから患者と関係している生理学的信号を受信し、生理学的信号に基づいて第１の生理学的パラメータ値を取得し、表示のため第１の生理学的パラメータ値を出力することを記載する。第１の医療機器はまた、第１の医療機器が表示可能な出力値を生成するために第２の生理学的パラメータ値を処理できないように、第１の医療機器以外の第２の医療機器から、第１の医療機器によって使用されないプロトコルに従ってフォーマットされた第２の生理学的パラメータ値を受信する可能性がある。第１の医療機器は、第１の医療機器から別個の翻訳モジュールに生理学的パラメータデータを渡し、第１の医療機器で翻訳モジュールから第１の医療機器による表示のため処理され得る翻訳済みのパラメータデータを受信し、表示のため翻訳済みのパラメータデータから第２の値を出力する可能性がある。第１の医療機器は、たとえば、監視ハブ、携帯型生理学的モニタ、もしくは多数患者監視システムでもよく、第２の医療機器は、輸液ポンプ、人工呼吸器などでもよい。

開示を要約する目的のため、いくつかの態様、利点および新規性のある特徴について本明細書で検討されている。必ずしも全てではないが、このような態様、利点もしくは特徴は、発明の何らかの特定の実施形態において具現化されるものであることが理解されるべきであり、当業者は、本明細書における開示からこのような態様、利点もしくは特徴の無数の組み合わせを認めるであろう。

以下の図面および関連した説明は、本開示の実施形態を例示するために記載され、特許請求の範囲を限定するものではない。

本開示の実施形態による例示的な医療監視ハブの斜視図を示す図である。たとえば、例示的なドッキング接続された携帯型患者モニタと一体となったハブを示す。 医療ポートの組および非侵襲的血圧入力と一体となったハブを示す。 様々な例示的な体温センサが取り付けられているハブを示し、全てが本開示の様々な実施形態によるものである。

本開示の実施形態による、図１のハブを含む例示的な監視環境の簡略ブロック図である。

本開示の実施形態による、図１のハブの簡略化された例示的なハードウェアブロック図である。

本開示の実施形態による、図１のハブの例示的な着脱式ドッキングステーションの斜視図である。

本開示の実施形態による、図１のハブからドッキング解除された例示的な携帯型患者モニタの斜視図である。さらに、図５は、例示的な代替ドッキングステーションを示す。

従来の患者機器の電気的絶縁原理の簡略ブロック図である。

本開示の実施形態による、例示的なオプションの患者機器絶縁システムの簡略ブロック図である。 同様に本開示の実施形態による、図７Ａのシステムのための例示的なオプションの非絶縁電力レベルの追加を示す図である。

本開示の実施形態による、簡略化された例示的なユニバーサル医療コネクタ構成プロセスを示す図である。

従来の絶縁要件より断面において小さいサイズおよび形状を有する例示的なユニバーサル医療コネクタの簡略ブロック図である。

本開示の実施形態による、例示的なユニバーサル医療コネクタ用の例示的な計器側チャンネル入力を示している図１のハブの側面の斜視図である。

本開示の実施形態による、例示的な雄型および嵌め合わせ雌型ユニバーサル医療コネクタの様々な図である。

本開示の実施形態による、図１のハブ用のチャンネルシステムの簡略ブロック図である。

本開示の実施形態による、例示的な論理チャンネル構成を示す図である。

本開示の実施形態による、ケーブルを構築し、チャンネルを構成する簡略化された例示的なプロセスを示す図である。

本開示の実施形態による、入力チャンネルを形成するために例示的な装着されたボードインケーブルを含む図１のハブの斜視図である。

本開示の実施形態による、例示的な計器側シリアルデータ入力を表している図１のハブの裏側の斜視図である。

図１６のシリアルデータ接続を介して通信する例示的な監視環境を示す図である。 本開示の実施形態による、図１のハブの例示的な接続性表示を示す図である。

本開示の実施形態による、簡略化された例示的な患者データ・フロー・プロセスを示す図である。

図１９Ａ〜１９Ｊは、本開示の実施形態による、図１のハブとドッキング接続された図１の携帯型患者モニタ用の解剖学的図形の例示的な表示を示す図である。

それぞれ、本開示の実施形態による、図１のハブのディスプレイにデータ分離およびデータ重なり合いを表している測定データの例示的な表示を示す図である。

それぞれ、本開示の実施形態による、図１の携帯型患者モニタのディスプレイにデータ分離およびデータ重なり合いを表している測定データの例示的な表示を示す図である。

本開示の実施形態による例示的なアナログ表示標識を示す図である。

本発明の実施形態に従って、意識モニタの深部が図１のハブのチャンネルポートに接続されているとき、たとえば、図２３Ａ〜２３Ｄにおけるデータ提示、体温センサおよび血圧センサが図１のハブと通信しているとき、図２３Ｅにおけるデータ提示、および、音響センサが図１のハブとさらに通信しているとき、図２３Ｆにおけるデータ提示を示している測定データの例示的な表示を示す図である。

図１のハブを含む監視環境の別の実施形態を示す図である。

翻訳メッセージ取扱プロセスの実施形態を示す図である。

測定データの表示を含んでいる付加的なハブ表示例を示す図である。 測定データの表示を含んでいる付加的なハブ表示例を示す図である。

翻訳モジュールを介して互いに通信する第１の医療機器例および第２の医療機器例を示す図である。

翻訳モジュールおよび通信バスを介して互いに通信する第１の医療機器例および第２の医療機器例を示す図である。

翻訳モジュールによって受信された入力メッセージ例を示す図である。

フィールドに構文解析されている入力メッセージのメッセージ・ヘッダ・セグメント例を示す図である。

図４１Ｂの構文解析されたメッセージ・ヘッダ・セグメントのエンコードされたバージョン例を示す図である。

図４１Ａの入力メッセージに基づく翻訳モジュールの出力メッセージ例を示す図である。

入力メッセージと、翻訳ジュールに関連付けられた翻訳ルールとの比較とに基づいて、出力メッセージを発生させる翻訳プロセス例を示す図である。

翻訳モジュールが第１のＨＬ７フォーマットを有する病院情報システム（「ＨＩＳ」）から第２のＨＬ７フォーマットを有する対象となる受信側医療機器へのＨＬ７メッセージの通信を実現しやすくする翻訳プロセス例を示す図である。

翻訳モジュールが、第１のＨＬ７フォーマットを有する医療機器から第２のＨＬ７フォーマットを有するＨＩＳへのＨＬ７メッセージの通信を実現しやすくする翻訳プロセス例を示す図である。

翻訳モジュールによって使用されるように翻訳ルールを手動で構成するメッセージング実装ツールからのスクリーンショット例を示す図である。

翻訳モジュールによって行われ得る自動ルール構成プロセス例を示す図である。 翻訳モジュールによって行われ得る自動ルール構成プロセス例を示す図である。

Ｈ７プロトコルを利用するメッセージのため翻訳モジュールによって行われ得る自動ルール構成プロセス例を示す図である。 Ｈ７プロトコルを利用するメッセージのため翻訳モジュールによって行われ得る自動ルール構成プロセス例を示す図である。

上記「図面の簡単な説明」は、一般に本開示の様々な実施形態に言及するが、当業者は、本明細書における開示からこのような実施形態が相互排他的ではないことを認めるものである。むしろ、当業者は、そのような実施形態のいくつかまたはすべての無数の組み合わせを認識するであろう。

Ｉ． 序論
少なくとも前述のことに基づいて、患者を治療もしくは監視する様々な医療機器を協調させる解決策が必要とされる。このような解決策の実施形態は、機器空間の至る所でシームレスに患者識別情報を提供すべきであり、このような解決策の実施形態は、必ずしも度重なるソフトウェア更新を要求することなく、将来の技術のため発展すべきである。加えて、このような解決策の実施形態は、必要に応じて患者電気的絶縁を含むことがある。

その結果、本開示は、特定の患者に対する患者監視および治療活動の中心である患者監視ハブに関係する。レガシー再プログラミングを必要とすることがないレガシー機器との患者監視ハブインターフェースの実施形態は、ソフトウェア更新を必要とすることなく将来の機器とのインターフェースを柔軟に行い、オプションの患者電気的絶縁を提供する。実施形態では、ハブは、広範囲の測定パラメータもしくはそれ以外の決定されたパラメータに関する情報を介護者に動的に提供する大型ディスプレイを含む。その上、実施形態では、ハブは、携帯型患者モニタのためのドッキングステーションを含む。携帯型患者モニタは、ドッキングステーションを介して、もしくは、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ、Ｚｉｇｂｅｅなどを含む本明細書における開示から、当業者に既知である様々な無線パラダイムを介してハブと通信することがある。

さらに他の実施形態では、携帯型患者モニタは、ドッキング接続されたとき、このモニタの画面を変更する。ドッキング解除された表示標識は、一部において、もしくは、全部において、ハブの大型動的ディスプレイに移動させられ、ドッキング接続されたディスプレイは、監視対象である身体部分の１つ以上の解剖学的図形を提示する。たとえば、ディスプレイは、これがドッキング接続されたとき、心臓、肺、脳、腎臓、腸、胃、他の臓器、指、消化器系、もしくは他の身体部分を提示することがある。実施形態では、解剖学的図形は、アニメーション化されると有利である。実施形態では、アニメーションは、概して、測定されたパラメータの挙動に追従し、たとえば、肺は、測定された呼吸数、および／または、呼吸サイクルの決定された吸気部とおおよそ相関関係で膨張し、同様に、呼吸サイクルの呼気部に従って収縮する。心臓は、脈拍数に従って鼓動することがあり、分かっている現実の心収縮パターンなどにおおよそ従って鼓動することがある。さらに、実施形態では、測定されたパラメータが介護者に警告する必要を示唆するとき、色による変化する深刻度は、心臓、肺、脳などのような１つ以上の表示された図形に関連付けられることがある。さらに他の実施形態では、身体部分は、測定機器を患者の測定部位に取り付ける場所、時もしくはやり方についてのアニメーションを含むことがある。たとえば、モニタは、ＣＣＨＤスクリーニング処置もしくはグルコースストリップ読み取りプロトコル、前額部センサ、指もしくは足指センサ、１個以上の電極、音響センサ、および耳センサ、カニューレセンサの適用などのアニメーションによる指示を提供することがある。

本開示は、特定の患者に対する監視活動の中心であるように構成されている医療監視ハブに関係する。実施形態では、ハブは、ハブの前面上の設置面積の大半を占める約１０（１０）インチ型ディスプレイのような大型の読みやすいディスプレイを備える。このディスプレイは、設計上の制約に依存してより大型であること、もしくは、より小型であることがあり得る。しかしながら、携帯性および現行の設計目標のため、好ましいディスプレイは、ドッキング接続可能な携帯型患者モニタのうち１台の垂直実装面積におおよそ比例した大きさである。他の検討事項は、当業者によって本明細書における開示から分かる。

ディスプレイは、数値形式もしくは図形形式で、観察下に置かれている患者の多種多様の監視対象であるパラメータに対する測定データを提供し、様々な実施形態では、ハブにおいて受信されているデータおよび情報のタイプに依存して自動的に構成される。実施形態では、ハブは、可動、携帯型、および搭載可能であるので、ハブは、介護者環境の内部の都合のよいエリアに置くことができる。たとえば、ハブは、唯一の筐体の内部に集められる。

実施形態では、ハブは、携帯型患者モニタがドッキング接続されている、もしくは、ハブからドッキング解除されている間にこの携帯型患者モニタからデータを受信することがあると有利である。オキシメーターもしくＣＯオキシメーターのようなは典型的な携帯型患者モニタは、光学および／または音響センサ、電極などから出力された信号から得られた多数の生理学的パラメータに対する測定データを提供できる。生理学的パラメータは、例を挙げると、酸素飽和度と、カルボキシヘモグロビンと、メトヘモグロビンと、総ヘモグロビンと、グルコースと、ｐＨと、ビリルビンと、飽和分率と、脈拍数と、呼吸数と、呼吸サイクルのコンポーネントと、灌流指数を含む灌流の指標と、信号品質および／または信頼度と、プレチスモグラフデータと、健康の指標もしくは健康指数または他の測定データの組み合わせと、呼吸に反応する聴覚情報と、病気識別もしくは診断と、血圧と、患者および／または測定部位体温と、鎮静深度と、臓器もしくは脳酸素化と、水和と、代謝反応測定量と、これらの組み合わせなどとを含むが、これらに限定されることはない。他の実施形態では、ハブは、輸液ポンプなどと併せて、閉ループ薬物投与を達成するために十分なデータを出力することがある。

実施形態では、ハブは、監視環境内にあり、様々な方法で患者と相互作用している他の機器と通信する。たとえば、ハブは、他の機器もしくはハブの再プログラミングを必要とすることなく他の機器からシリアルデータを受信すると有利である。これらの他の機器には、ポンプと、人工呼吸器と、上記パラメータの何らかの組み合わせを監視するあらゆる種類のモニタと、ＥＣＧ／ＥＥＧ／ＥＫＧ機器と、電子患者ベッドなどとが含まれる。さらに、ハブは、他の医療機器もしくはハブの再プログラミングを必要とすることなく他の医療機器からチャンネルデータを受信すると有利である。機器がチャンネルデータを通じて通信するとき、ハブは、この機器からの測定情報を組み入れるために大型ディスプレイを変更することがあると有利である。その上、ハブは、機器からのナースコール状況が適切なナースコール・システムに確実に渡されるようにナースコール・システムにアクセスする。

ハブは、着信患者測定および治療データを監視対象である患者に関連付けるのに有利にするために病院システムとも通信する。たとえば、ハブは、無線もしくはそれ以外の方法で、サーバもしくはサーバの一群のような多数患者監視システムと通信することがあり、この多数患者監視システムは、次に、たとえば、入院、退院、転院（「ＡＤＴ」）システム、および／または、電子医療記録（「ＥＭＲ」）システムのような介護者のデータ管理システムと通信する。ハブは、ハブの中を流れるデータを監視対象である患者に関連付け、それによって、介護者が環境内の各機器を患者に関連付けることなく介護者のデータ管理システムに渡されるように電子測定および治療情報を提供すると有利である。

実施形態では、ハブは、再構成可能である着脱式ドッキングステーションを含むと有利である。ドッキングステーションは、様々な患者監視機器に適合するように追加の積層型ドッキングステーションをドッキング接続することがある。その上、ドッキングステーション自体は、モジュール化されるので、基本のドッキング接続可能な携帯型患者モニタがこれのフォームファクタを変更する場合、取り外されることがある。それ故に、ハブは、このハブのドッキングステーションがどのように構成されるかにおいて柔軟性がある。

実施形態では、ハブは、このハブが受信、処理、および／または、患者に関連付ける、および／または、他の機器およびシステムと通信するデータの一部もしくは全部を記憶する大型メモリを含む。メモリの一部もしくは全部は、取り外し可能なＳＤメモリを備えることがあると有利である。

ハブは、少なくとも（１）携帯型モニタからデータを獲得するためにドッキングステーションと、（２）チャンネルデータを獲得するために革新的なユニバーサル医療コネクタと、（３）出力データを獲得するためにＲＪポートのようなシリアルデータコネクタと、（４）イーサネット、ＵＳＢ、およびナース・コール・ポートと、（５）携帯型モニタからデータを獲得するために無線機器と、（６）当業者に知られている他の有線もしくは無線の通信機構とを介して他の機器と通信する。ユニバーサル医療コネクタは、オプションの電気的絶縁型電力および通信を提供すると有利であり、絶縁要件より断面が小さくなるように設計される。コネクタおよびハブは、ハブのため使用可能であり、かつ、表示可能であるように他の機器からのデータを翻訳もしくは構成するのに有利にするために通信する。実施形態では、ソフトウェア開発キット（「ＳＤＫ」）は、機器製造業者の機器から出力されたデータの挙動および意味を規定もしくは定義するために機器製造業者に提供される。出力が定義されたとき、この定義は、ユニバーサル医療コネクタのケーブル側に存在するメモリの中へプログラムされ、相手先ブランド製造（「ＯＥＭ」）として機器プロバイダに供給される。ケーブルが機器とハブとの間に接続されるとき、ハブは、データを理解し、機器もしくはハブへのソフトウェア更新を必要とすることなく表示および処理目的のためデータを使用することができる。実施形態では、ハブは、スキーマを取り決めることができ、付加的な圧縮および／または暗号化を追加することでさえも可能である。ユニバーサル医療コネクタの使用を通じて、ハブは、測定および治療データを効果的および効率的に、監視環境に秩序をもたらす単一の表示および警告システムに体系化する。

ハブがチャンネルパラダイムに従って他の機器からデータを受信し、追跡するとき、ハブは、患者測定もしくは治療データの仮想チャンネルを作り出すために処理を行うことがあると有利である。一実施形態では、仮想チャンネルは、測定対象ではないパラメータ、すなわち、たとえば、様々な測定対象であるもしくは他のパラメータからのデータ処理の結果を含むことがある。このようなパラメータの実施例は、監視対象である患者の健康の全般的な指標となる様々な測定対象であるパラメータから得られた健康インジケータを含む。健康パラメータの実施例は、本開示の譲受人によるものであり、参照によって本明細書に組み込まれる米国特許出願第１３／２６９，２９６号、１３／３７１，７６７号および１２／９０４，９２５号に開示されている。データをチャンネルおよび仮想チャンネルに体系化することにより、ハブは、着信データおよび仮想チャンネルデータを時間に関して同期化することがあると有利である。

ハブは、ＲＪコネクタのようなシリアル通信ポートを介してシリアルデータも受信する。シリアルデータは、監視対象である患者に関連付けられ、前述の複数患者サーバシステムおよび／または介護者バックエンドシステムに渡される。シリアルデータを受信することを通じて、介護者は、個別の機器を患者に関連付ける必要と、できるだけ病院システムとの通信とを回避して、介護者環境内の、多くの場合に様々な製造業者からの機器を特定の患者に関連付けると有利である。このような関連付けは、患者に関する略歴および人口統計学的情報を各機器に入力して費やす介護者の時間を短縮するので、不可欠である。さらに、実施形態では、ＳＤＫを通じて、機器製造業者は、機器製造業者の機器の何らかの測定遅延に関連付けられた情報を提供すると有利であることがあり、それによって、ハブが患者に関連付けられたシリアル着信データおよび他のデータを時間に関してさらに同期化させると有利である。

実施形態では、携帯型患者モニタがドッキング接続され、独自のディスプレイを含むとき、ハブは、これのディスプレイ設置可能面積を効果的に増大させる。たとえば、実施形態では、携帯型患者モニタは、今度はハブディスプレイ上に複製されることがある携帯型患者モニタの測定および／または治療データを単に表示し続けることがあり、または、ドッキング接続されたディスプレイは、付加的な情報を提供するためにこれの表示を変えることがある。実施形態では、ドッキング接続されたディスプレイは、ドッキング接続されたとき、たとえば、測定および／または治療されている心臓、肺、臓器、脳、もしくは他の身体部分の解剖学的図形データを提示する。図形データは、測定データと同様に、および、呼応してアニメーション化することがあると有利である。たとえば、肺は、測定対象である呼吸数、および／または、呼吸サイクルの決定された吸気／呼気部分におおよそ相関して膨張することがあり、心臓は、脈拍数に従って鼓動することがあり、分かっている実際の心臓収縮パターンにおおよそ従って鼓動することがあり、脳は、変化する鎮静深度に基づいて色もしくは活動を変えることがあるなどである。実施形態では、測定対象であるパラメータが介護者を変える必要性を指示するとき、色が変化する深刻度は、心臓、肺、脳、臓器、循環系もしくはこれの一部分、呼吸器系もしくはこれの一部分、他の身体部分などのような１つ以上の表示された図形に関連付けられることがある。さらに他の実施形態では、身体部分は、測定機器を取り付ける場所、時もしくはやり方についてのアニメーションを含むことがある。

ハブは、付加的な視覚情報を介護者に提供するためにパラメータ表示をさらに重ね合わせることがあると有利である。このような重ね合わせは、ユーザ定義可能および構成可能であることがある。表示は、アナログらしいアイコンもしくは図形標識を組み込むことがある。

明瞭にするために、現実の実装法の全てが本明細書において記載されているとは限らない。当業者は、当然ながら、このような現実の実装法の開発では（いずれの開発プロジェクトの場合においても見られるように）、多数の実装法に固有の決定が、実装法毎に変わることがあるシステムおよびビジネス関連制約の順守のような開発者に固有の目標およびサブ目標を達成するために行われなければならないことを理解するであろう。さらに、このような開発努力は、複雑であり、かつ、時間を要するかもしれないが、それにもかかわらず、本開示の利益を得る当業者にとって機器エンジニアリングに着手するルーティンであることが理解されるであろう。

本開示の完全な理解を容易にするために、詳細な説明の残りの部分は、類似する参照数字が全体を通じて類似する符号を用いて言及される図面を参照して本開示を説明する。

ＩＩ． ハブ実施形態例
図１Ａは、本開示の実施形態による例示的なドッキング接続された携帯型患者モニタ１０２と一体になった例示的な医療監視ハブ１００の斜視図を含む監視環境を示す。ハブ１００は、ディスプレイ１０４と、実施形態では、携帯型患者モニタ１０２と機械的および電気的に結合するように構成されているドッキングステーション１０６とを含み、それぞれが可動、搭載可能、および携帯型の筐体１０８に収容されている。筐体１０８は、水平平面の上に載るように構成されたほぼ直立の傾斜した形状を有するが、筐体１０８は、多種多様の位置および土台に取り付けることができ、多種多様の形状およびサイズを備えることができる。

実施形態では、ディスプレイ１０４は、数値、図形、波形、もしくは他の表示標識１１０で多種多様の測定および／または治療データを提示することがある。実施形態では、ディスプレイ１０４は、筐体１０８の前面の大半を占有するが、当業者は、ディスプレイ１０４がタブレットもしくは卓上水平構成、ラップトップのような構成などを備えることがあることを理解するであろう。
他の実施形態は、表示情報およびデータを卓上コンピュータ、スマートホン、テレビ、もしくは当業者に分かる何らかの表示システムに通信することを含むことがある。図１Ａの直立傾斜構成は、容易に見えるやり方で表示情報を介護者に提示する。

図１Ｂは、筐体１０８、ディスプレイ１０４、および携帯型モニタがドッキング接続されていないドッキングステーション１０６を含むハブ１００の実施形態の斜視側面図を表している。さらに表されているのは、非侵襲的血圧のためのコネクタである。

実施形態では、筐体１０８は、たとえば、図１Ｃに表された機器のような血圧モニタ、温度センサ１１２などの付加的な医療機器を保持するために窪み部もしくは切り込み部をさらに含むことがある。

図１Ａの携帯型患者モニタ１０２は、カリフォルニア州アーバイン所在のＭａｓｉｍｏ Ｃｏｒｐｏｒａｔｉｏｎから市販されている、および／または、米国特許出願公開第２００２／０１４０６７５号明細書、第２０１０／０２７４０９９号明細書、第２０１１／０２１３２７３号明細書、第２０１２／０２２６１１７号明細書、第２０１０／００３００４０号明細書、米国特許出願第６１／２４２，７９２号明細書、第６１／３８７４５７号明細書、第６１／６４５，５７０号明細書、第１３／５５４，９０８号明細書、および米国特許第６，１５７，８５０号明細書、第６，３３４，０６５号明細書などに開示されているもののようなオキシメーター、ＣＯオキシメーター、呼吸モニタ、鎮静深度モニタ、非侵襲的血圧モニタ、バイタルサインモニタなど備えることがあると有利である。モニタ１０２は、発光および光検出回路を含む光学センサ、音響センサ、指穿刺傷から血液パラメータを測定する機器、腕帯、人工呼吸器などのような種々の非侵襲的および／または低侵襲的機器と通信することがある。モニタ１０２は、図１９Ａ〜１９Ｊを参照して後述される独自の表示標識１１６を提示する独自のディスプレイ１１４を含むことがある。表示標識は、モニタ１０２のドッキング状態に基づいて変化することがあると有利である。ドッキング解除されているとき、表示標識は、パラメータ情報を含むことがあり、たとえば、重力センサもしくは加速度計に基づいて向きを変えることがある。

実施形態では、ハブ１００のドッキングステーション１０６は、ハブ１００の動きがモニタ１０２を傷つけることがあり得る形でモニタを機械的に取り外すことがないように、機械ラッチ１１８、または、機械的解除可能なキャッチを含む。

特定の携帯型患者モニタ１０２に関連して開示されているが、当業者は、本明細書における開示から、ハブ１００とドッキング接続することがあると有利である多数の様々な医療機器を認識するであろう。さらに、ドッキングステーション１０６は、モニタ１０２と電気的に、機械的ではなく、接続する、および／または、モニタと無線通信することがあると有利である。

図２は、本開示の実施形態による、図１のハブ１００を含む例示的な監視環境２００の簡略ブロック図を示す。図２に表されているように、環境は、たとえば、オキシメトリ光学センサ、音響センサ、血圧センサ、呼吸センサなどのような１台以上の患者センサ２０２と通信する携帯型患者モニタ１０２を含むことがある。実施形態では、たとえば、ＮＩＢＰセンサもしくはシステム２１１と体温センサもしくはセンサシステム２１３のような付加的なセンサは、ハブ１００と直接通信することがある。センサ２０２、２１１および２１３は、使用されているとき、典型的に、測定部位で患者に実際には装着されていないとしても、監視対象である患者に近接している。

開示されているとおり、携帯型患者モニタ１０２は、実施形態では、ドッキング接続されているときドッキングステーション１０６を介して、また実施形態では、ドッキング解除されているときハブ１００と無線で通信するが、このようなドッキング接続されていない通信は、必須ではないハブ１００は、たとえば、米国特許出願公開第２０１１／０１０５８５４号明細書、第２０１１／０１６９６４４号明細書、および第２００７／０１８０１４０号明細書に開示されているような１台以上のマルチ患者監視サーバ２０４もしくはサーバシステムと通信する。概して、サーバ２０４は、ＥＭＲシステムおよび／またはＡＤＴシステムのような介護者バックエンドシステム２０６と通信する。サーバ２０４は、プッシュ、プルもしくは組み合わせ技術を用いて、人口統計学的情報、課金情報などのような、患者入院時に入力された患者情報を取得することがあると有利である。ハブ１００は、監視対象である患者を介護者バックエンドシステム２０６にシームレスに関連付けるためにこの情報にアクセスする。無線、有線、モバイルもしくは他のコンピューティングネットワークなどを含む、サーバ２０４と監視ハブ１００との間の通信は、本明細書における開示から当業者に認識できることがある。

図２は、ハブのシリアルデータポート２１０およびチャンネルデータポート２１２を介して通信するハブ１００をさらに表している。上記開示のとおり、シリアルデータポート２１０は、電子患者ベッドシステム２１４と、閉ループ制御系を含む灌流ポンプシステム２１６と、人工呼吸器システム２１８と、血圧もしくは他のバイタルサイン測定システム２２０などを含む多種多様の患者医療機器からのデータを提供することがある。同様に、チャンネルデータポート２１２は、上記機器のいずれか、および、他の医療機器を含む多種多様の患者医療機器からのデータを提供することがある。たとえば、チャンネルデータポート２１２は、ＳＥＤＬｉｎｅから市販されているような意識深度モニタ２２２、脳もしくは他の臓器のオキシメーター機器２２４、非侵襲的血圧もしくは音響機器２２６などからデータを受信することがある。実施形態では、チャンネル機器は、処理アルゴリズムとこれらのアルゴリズムを遂行する信号処理機器とが、一部の実施形態では、付加的な表示技術を持たないケーブルもしくはケーブルコネクタ内に収容されたボードに搭載されているボードインケーブル（「ＢＩＣ」）解決策を含むことがある。ＢＩＣ解決策は、ハブ１００のディスプレイ１０４に表示されるように、これの測定対象であるパラメータデータをチャンネルポート２１２へ出力する。実施形態では、ハブ１００は、たとえば、タブレット、スマートホン、もしくは他のコンピューティングシステムのような他のシステムと通信するＢＩＣ解決策として完全もしくは部分的に形成されることがあると有利である。

単一のドッキングステーション１０６に関連して開示されているが、環境２００は、後続のドッキングステーションが、図５に関連して検討されるように、異なった携帯型患者モニタに対するフォームファクタを変えるために第１のドッキングステーションに機械的および電気的にドッキング接続する積層型ドッキングステーションを含むことがある。このような積層は、３台以上のドッキングステーションを含むことがあり、携帯型機器上の結合機械構造体との機械的コンプライアンスのためフォームファクタを増減することがある。

図３は、本開示の実施形態による、図１のハブ１００の簡略化された例示的なハードウェアブロック図を示す。図３に表されているように、ハブ１００の筐体１０８は、計器ボード３０２、ディスプレイ１０４と、メモリ３０４と、シリアルポート２１０、チャンネルポート２１２、イーサネットポート３０５、ナース・コール・ポート３０６、標準的なＵＳＢなどを含む他の通信ポート３０８を含む様々な通信接続部と、ドッキングステーションインターフェース３１０とを位置決めし、および／または、取り囲む。計器ボード３０２は、ボード間通信を含む本明細書に記載された通信および機能を可能にするために通信相互接続部、配線、ポートなどを含む１つ以上の基板を備える。コアボード３１２は、主パラメータ、信号、他のプロセッサ（群）およびメモリを含み、携帯型モニタボード（「ＲＩＢ」）３１４は、モニタ１０２および１台以上のプロセッサのための患者電気的絶縁を含み、チャンネルボード（「ＭＩＤ」）３１６は、オプションの患者電気的絶縁および電源３１８を含むチャンネルポート２１２との通信を制御し、ラジオボード３２０は、無線通信のため構成されたコンポーネントを含む。付加的に、計器ボード３０２は、１台以上のプロセッサおよびコントローラと、バスと、あらゆる種類の通信接続性およびエレクトロニクス部品と、メモリと、ＥＰＲＯＭリーダを含むメモリリーダと、本明細書における開示から当業者に認識できる他のエレクトロニクス部品とを含むことがあると有利である。各ボードは、上記指定されたタスクおよび他のタスクを遂行するために、位置決めおよび支持のための基板と、通信のための相互接続部と、コントローラを含む電子コンポーネントと、論理機器と、ハードウェア／ソフトウェア組み合わせなどを備える。

当業者は、本明細書における開示から、計器ボード３０２は、多数のやり方で体系化された多数の電子コンポーネントを備えることがあることを認識するであろう。上記開示されたような様々なボードを使用して、体系化および区分化を複雑なシステムにもたらすと有利である。

図４は、本開示の実施形態による、図１のハブ１００の例示的な着脱式ドッキングステーション４００の斜視図を示す。図４に表されているように、ドッキングステーション４００は、モニタ１０２がドッキング接続されたとき、堅牢な機械的支持を設けるために携帯型患者モニタ１０２への機械的対合を行う。ドッキングステーション４００は、携帯型モニタ１０２の筐体の外面と同じように成形された空洞４０２を含む。ステーション４００は、ハブ１００への通信を行う１つ以上の電気コネクタ４０４をさらに含む。ボルトを使って取り付けられるものとして表されているが、ドッキングステーション４００は、スナップフィットすることがあり、可動式タブもしくはキャッチを使用することがあり、磁気的に付着することがあり、または、本明細書における開示から当業者に知られている種々のアタッチメント機構部もしくはアタッチメント機構部の組み合わせを利用することがある。実施形態では、ドッキングステーション４００のアタッチメントは、ドッキング接続されたとき、十分に堅牢なアタッチメントであるべきであり、たとえば、ハブ１００が誤ってぶつけられるなどのことがあった場合、モニタ１０２およびドッキングステーション４００が無傷のままであるべきであるように、モニタ１０２およびドッキングステーションは、計器を傷つけ得るような形で誤って取り外されるおそれがあってはならない。

ハブ１００の筐体１０８は、ドッキングステーション４００を収容する空洞４０６をさらに含む。携帯型患者モニタ１０２のフォームファクタへの変化が現れる範囲で、ドッキングステーション４００は、着脱可能および交換可能であると有利である。ドッキングステーション４００と同様に、ハブ１００は、筐体１０８の空洞４０６の内部に、ドッキングステーション４００への電気通信を行う電気コネクタ４０８を含む。実施形態では、ドッキングステーション４００は、米国特許出願公開第２００２／０１４０６７５号明細書に開示されているような独自のマイクロコントローラおよび処理能力を含む。他の実施形態では、ドッキングステーション４００は、電気コネクタ４０８まで通信を渡す。

図４は、以下に詳述されるユニバーサル医療コネクタとしてチャンネルポート２１２のための開口部を含む筐体１０８をさらに表している。

図５は、本開示の実施形態による、図１のハブ１００からドッキング解除された例示的な携帯型患者モニタ５０２および５０４の斜視図を示す。図５に表されているように、モニタ５０２は、取り外されることがあり、モニタ５０４のような他のモニタが設けられることがある。ドッキングステーション１０６は、元のドッキングステーション１０６と機械的に対合し、モニタ５０４と機械的に対合する可能性があるフォームファクタを提示する付加的なドッキングステーション５０６を含む。実施形態では、モニタ５０４は、ハブ１００の積層型ドッキングステーション５０６および１０６と機械的および電気的に対合する。本明細書における開示によって、および、本明細書における開示から当業者によって容易に理解され得るように、ドッキングステーションの積層可能な機能は、多種多様の患者監視機器をチャージする、多種多様の患者監視機器と通信する、および多種多様の患者監視機能とインターフェースをとる極度に柔軟性のある機構部をハブ１００に提供する。前述のとおり、ドッキングステーションは、積層されることがあり、もしくは、他の実施形態では、取り外される、および、交換されることがある。

図６は、従来の患者電気的絶縁原理の簡略ブロック図を示す。図６に表されているように、ホスト機器６０２は、概して、通信および電力を介して患者機器６０４に関連付けられる。患者機器６０４は、患者に近接した、もしくは、接続された、センサなどのようなエレクトロニクス部品を備えることがよくあるので、ある特定の安全要件は、たとえば、ホスト機器に接続された電力グリッドからのエネルギーの電気サージが患者までの電気路を見つけるべきではないことを定める。このことは、概して、当該技術分野において知られた用語であり、かつ、本明細書ではホスト機器６０２と患者機器６０４との間の直接的な中断なしの電気路の除去を含む「患者絶縁」と呼ばれる。このような絶縁は、たとえば、電力導体６０８および通信導体６１０上の絶縁機器６０６を介して達成される。絶縁機器６０６は、変成器、光エネルギーを放出および検出する光学機器などを含むことができる。特に電力導体上にある絶縁機器の使用は、コンポーネントの観点で高くつき、サイズの観点で高くつき、電力を枯渇させる可能性がある。従来から、絶縁機器は、患者機器６０４に組み込まれているが、患者機器６０４は、徐々に小さくなる傾向があり、必ずしも全ての機器が絶縁を組み込むとは限らない。

図７Ａは、本開示の実施形態による例示的なオプションの患者絶縁システムの簡略ブロック図を示す。図７Ａに表されているように、ホスト機器６０２は、絶縁機器６０６を介して絶縁型患者機器６０４と通信する。しかしながら、特定の患者機器に関連付けられたメモリ７０２は、この機器が絶縁型電力を必要とするかどうかをホスト６０２に通知する。ある種類の腕帯、灌流ポンプ、人工呼吸器などのような患者機器７０８が絶縁型電力を必要としない場合、ホスト６０２は、信号路７１０を介して、非絶縁型電力を提供することができる。この電力は、絶縁型電力導体６０８を介して高い費用効果で提供される電力よりはるかに高くなることがある。実施形態では、非絶縁型患者機器７０８は、絶縁型通信を受信するので、通信は、典型的に、より低い電圧にあり、法外なコストはかからない。当業者は、本明細書における開示から、通信が絶縁されないこともあり得ることが分かるであろう。従って、図７Ａは、ホスト６０２と多種多様の潜在的な患者機器６０４、７０８との間でオプションの患者絶縁を行う患者絶縁システム７００を表している。実施形態では、ハブ１００は、類似したオプションの患者絶縁原理を組み込むチャンネルポート２１２を含む。

図７Ｂは、本開示の実施形態による図７Ａのシステムに対する例示的なオプションの非絶縁電力レベルを示す。図７Ｂに表されているように、ホスト６０２が、患者機器６０４は、自己絶縁型患者機器７０８を備え、それ故に、絶縁型電力を必要としない、ということを理解すると、ホスト６０２は、別個の導体７１０を介して電力を供給する。電力は、絶縁されていないので、メモリ７０２は、２つ以上の電圧もしくは電力レベルから選択されることがある電力要件をホスト６０２に供給することもある。図７Ｂでは、ホスト６０２は、約１２ボルトかそれ以上であり、広範囲の電圧を有することがあり得るような高電力、または、約２４ボルトかそれ以上であり、広範囲の電圧を有することがあり得るような超高電力を患者機器７０８に供給する。当業者は、電源電圧が実質的にあらゆる機器７０８の具体的なニーズを満たすように変えることができると有利であること、および／または、メモリが広範囲の非絶縁型電力を患者機器７０８に供給するホスト６０２に情報を供給することがあり得ることを認めるであろう。

さらに、メモリ７０２を使用して、ホスト６０２は、未使用電源が絶縁型電力であるか、または、より高電圧の非絶縁型電源であるかとは無関係に、この未使用電源を有効にしないことだけを決定することがあり、それによって、ホストの効率を高める。

図８は、本開示の実施形態による、簡略化された例示的なユニバーサル医療コネクタ構成プロセス８００を示す。図８に表されているように、プロセスは、ケーブルが上記に開示されているようにオプションの患者絶縁を組み込むユニバーサル医療コネクタに装着されるステップ８０２を含む。ステップ８０４では、ホスト機器６０２もしくはハブ１００は、より詳しくは、チャンネルデータボード３１６、もしくは、計器ボードのＥＰＲＯＭリーダは、メモリ７０２に記憶されたデータを読み取り、ステップ８０６では、接続機器が絶縁型電力を必要とするか否かを決定する。ステップ８０８において、絶縁型電力が必要とされるとき、ハブ１００は、絶縁型電力を有効にすることがあり、ステップ８１０において、絶縁型通信を有効にすることがあると有利である。ステップ８０６では、絶縁型電力が必要とされないとき、ハブ１００は、単に、オプションのステップ８１２において、非絶縁型電力を有効にすることがあり、通信が絶縁されたままである実施形態では、ステップ８１０は、絶縁型通信を有効にする。他のオプションの実施形態では、ステップ８０６において、絶縁型電力が必要とはされないとき、ハブ１００は、ステップ８１４において、患者機器７０８のため必要とされる電力量を決定するためにメモリ７０２からの情報を使用することがある。たとえば、他の接続されている機器もまた接続された電力を使用しているために十分な電力が利用できないとき、ステップ８１６では、この旨を示すメッセージが表示され、電力は供給されない。十分な電力が利用できるとき、オプションのステップ８１２は、非絶縁型電力を有効にすることがある。代替的に、オプションのステップ８１８は、メモリ７０２がより高いもしくはより低い電力が望ましいことを示すか否かを決定することがある。より高い電力が望ましいとき、ハブ１００は、ステップ８２０においてより高い電力を有効にすることがあり、そうではないとき、ステップ８２２においてより低い電力を有効にすることがある。ハブ１００は、ステップ８１０において、次に、絶縁型通信を有効にする。実施形態では、ハブ１００は、ステップ８１８において、単に、必要とされる電力量を決定し、少なくとも十分な電力を自己絶縁型機器７０８に供給することがある。

当業者は、本明細書における開示から、ハブ１００は、十分な電力が利用できるかどうかを確認しないことがあること、または、メモリ７０２からの情報に基づいて１つ、２つ、もしくは多くのレベルの非絶縁型電圧を供給することがあることを認めるであろう。

図９Ａおよび９Ｂは、従来の絶縁要件より断面において小さいサイズおよび形状を有する例示的なユニバーサル医療コネクタ９００の簡略ブロック図を示す。実施形態では、コネクタ９００は、一方の側部９１０の非絶縁型信号をもう一方の側部９２０の絶縁型信号から物理的に分離するが、これらの側部は、逆転されることもあり得る。これらの分離の間のギャップは、患者絶縁を管理する安全規制によって少なくとも部分的に規定されることがある。実施形態では、これらの側部９１０および９２０の間の距離は、非常に小さいように見えることがある。

図９Ｂにおける異なる斜視図から分かるように、コネクタの間の距離「ｘ」は、小さく見える。しかしながら、このギャップは、この距離が導体間に非直接路を取り込む原因となる。たとえば、短絡は、経路９０４を進まなければならないものであり、この距離は、このような経路の距離が、「ｘ」より大きいので、このような安全規制の範囲内である、もしくは、安全規制を越える。非直線路９０４がコネクタの至る所に、たとえば、半田が様々なピンをＰＣＢボードに接続するボードコネクタ側などに現れることは、注目に値する。

図１０は、図１のハブ１００の側部の斜視図を示し、例示的なユニバーサル医療コネクタとして例示的な計器側チャンネル入力１０００を表している。図１０に表されているように、入力は、非絶縁型側部９１０と、絶縁型側部９２０と、ギャップとを含む。実施形態では、メモリ７１０は、非絶縁型側部上のピンを介して通信する。

図１１Ａ〜１１Ｋは、本開示の実施形態による、例示的な雄型および対合雌型ユニバーサル医療コネクタの様々な図を示す。たとえば、図１１Ｇ１および１１Ｇ２は、様々な好ましいが、必須ではないサイジングを表し、図１１Ｈは、メモリ７０２のような電子コンポーネントのコネクタへの組み込みを表している。図１１Ｉ〜１１Ｋは、ケーブルがユニバーサル医療コネクタにつながるときの配線図およびケーブル自体のケーブル敷設詳細を示す。

図１２は、本開示の実施形態による、図１のハブ用のチャンネルシステムの簡略ブロック図を示す。図１２に表されているように、上記図１１に表されているコネクタのような雄型ケーブルコネクタは、ＥＰＲＯＭのようなメモリを含む。メモリは、ハブ１００が受信することを期待できるデータの型と、このデータを受信する方法とを記述する情報を記憶すると有利である。ハブ１００のコントローラは、データを受信する方法と、可能であれば、データをディスプレイ１０４に表示する、必要に応じて警告を出すなどの方法とを取り決めるためにＥＰＲＯＭと通信する。たとえば、医療機器供給業者は、ハブ提供者と連絡を取り、医療機器供給業者の機器から出力されるデータの型を記述する方法を供給業者に指導するソフトウェア開発者キット（「ＳＤＫ」）を受信することがある。ＳＤＫを使って作業した後、マップ、画像、もしくは他の翻訳ファイルが、前述の電力要件および絶縁要件と共にＥＰＲＯＭにロードされることがあると有利である。チャンネルケーブルがチャンネルポート２１２を介してハブ１００に接続されたとき、ハブ１００は、ＥＰＲＯＭを読み取り、ハブ１００のコントローラは、着信データに対処する方法を取り決める。

図１３は、図１２のＥＰＲＯＭに記憶されることがある例示的な論理チャンネル構成を示す。図１３に表されているように、各着信チャンネルは、１つ以上のパラメータを記述する。各パラメータは、ハブ１００が着信データに関して知るべきことを何でも記述する。たとえば、ハブ１００は、データがストリーミングデータと、波形データと、既に決定されたパラメータ測定データと、データの範囲と、データ配信の速度と、データの単位と、単位の幅と、表示色と、警告計算のための複雑なアルゴリズムを含む警告パラメータおよび閾値と、パラメータ値駆動型である他のイベントと、これらのものもしくは類似したものの組み合わせとであるかどうかを知りたいことがある。付加的に、パラメータ情報は、パラメータもしくはハブ１００によって受信された他のデータに亘るデータ同期化もしくはデータ同期化の近似に役立つ機器遅延時間を含むことがある。実施形態では、ＳＤＫは、着信データの型および順序を自己記述するスキームを機器供給業者に提示する。実施形態では、情報は、圧縮および／または暗号化を着信データストリームに適用すべきか否かを決定するためにハブ１００と取り決めると有利である。

このようなオープン・アーキテクチャは、上記に開示されているように、表示、処理、およびデータ管理のため、機器製造業者の機器の出力をハブ１００にポーティングする能力をこれらの機器製造業者に与えると有利である。ケーブルコネクタを介する実装法によって、機器製造業者は、これらの機器製造業者の機器の再プログラミングを回避するというよりはむしろ、ケーブルコネクタを介して既存の出力がどのようにフォーマットされるかをハブ１００に知らせるだけである。さらに、ハブ１００によって既に理解されている言語でデータを記述することにより、ハブ１００は、「ハブにとって新しい」医療機器からデータを受け入れるためのソフトウェア更新も回避する。

図１４は、本開示の実施形態によるチャンネルを構成する簡略化された例示的なプロセスを示す。図１４に表されているように、ハブ提供者は、ステップ１４０２において、機器製造者にＳＤＫを提供し、機器製造業者は、続いて、ステップ１４０４において、これらの機器製造業者の機器から出力データチャンネルを自己記述するためにＳＤＫを使用する。実施形態では、ＳＤＫは、開発を指導する一連の質問であり、他の実施形態では、ＳＤＫは、データの挙動を記述するために言語およびスキーマを提供する。

機器提供者がデータを記述すると、ハブ提供者は、ステップ１４０５において、二値画像もしくは他のファイルを作成して、ケーブルコネクタの内部のメモリに記憶するが、ＳＤＫは、画像を作成し、単にこの画像をハブ提供者に通信することがある。ケーブルコネクタは、ステップ１４１０において、ＯＥＭ部品として提供者に提供されることがあり、提供者は、ステップ１４１２において、提供者の機器上の出力ポートと機械的および電気的に対合するようにケーブルを構築し、製造する。

介護者が、一方の端部が機器提供者のシステムに結合し、もう一方の端部がハブ１００とハブのチャンネルポート２１２でぴったり合うようにＯＥＭ化されている適切に製造されたケーブルを有すると、ステップ１４５２において、介護者は、機器の間にハブを接続することができる。ステップ１４５４において、ハブ１００は、メモリを読み取り、絶縁型もしくは非絶縁型電力を供給し、ケーブルコントローラとハブ１００とは、データ配信のためのプロトコルもしくはスキーマを取り決める。実施形態では、ケーブル上のコントローラは、プロトコルを取り決めることがあり、代替的な実施形態では、ハブ１００のコントローラは、特定のプロトコルに関してハブ上の他のプロセッサと取り決めをする。プロトコルが定められると、ハブ１００は、合理的な形で着信データストリームを使用し、表示し、およびその他の方法で処理することができる。

本明細書に記載されたユニバーサル医療コネクタの使用を通じて、ハブ１００への数え切れないほどの機器の接続は、各機器へのソフトウェア更新を必然的に伴うのとは対照的に、ケーブルコネクタの簡単なプログラミングによって達成される。

図１５は、本開示の実施形態による入力チャンネルを形成するために例示的な装着されたボードインケーブル（「ＢＩＣ」）を含む図１のハブの斜視図を示す。図１５に表されているように、ＳＥＤＬｉｎｅ意識深度ボードは、表示および介護者再検討のため適切な患者センサからハブ１００にデータを通信する。前述のとおり、ボードの提供者は、ボードのデータチャンネルを記述するためにＳＤＫを使用するだけでよく、ハブ１００は、データを介護者に提示する方法が分かっている。

図１６は、例示的なシリアルデータ入力を表している、図１のハブ１００の裏側の斜視図を示す。実施形態では、入力は、ＲＪ４５ポートなどを含む。当該技術において理解されるように、これらのポートは、コンピュータ、ネットワーク、ルータ、スイッチ、およびハブで見られるデータポートに類似するデータポートを含む。実施形態では、複数のこれらのポートは、様々な機器からのデータをハブ１００において識別された特定の患者に関連付けるために使用される。図１６は、スピーカ、ナースコールコネクタ、イーサネットコネクタ、ＵＳＢ群、電源コネクタ、および医療用接地つまみをさらに表している。

図１７Ａは、本開示の実施形態による、図１のハブ１００のシリアルデータ接続を介して通信する例示的な監視環境を示す。図に表され、かつ、前述されているように、ハブ１００は、電子ベッド、灌流ポンプ、人工呼吸器、バイタルサインモニタなどを含む、監視環境の内部の様々な機器からデータを集めるためにシリアルデータポート２１０を使用することがある。これらの機器から受信されたデータと、チャンネルポート２１２を介して受信されたデータとの間の差は、ハブ１００がこのデータのフォーマットもしくは構造を知らないかも知れないことである。ハブ１００は、このデータからの情報を表示すること、または、計算もしくは処理中にこのデータを使用することがない。しかしながら、ハブ１００を介してデータをポーティングすることは、このデータを、上記サーバ２１４およびバックエンドシステム２０６を含む介護者システムのチェーン全体で特別に監視されている患者に関連付けると好都合である。実施形態では、ハブ１００は、着信データをハブ１００からのデータと同期化することを試みるために着信データに関する十分な情報を決定することがある。

図１７Ｂにおいて、制御画面は、受信されているデータの型についての情報を提供することがある。実施形態では、データに隣接している緑色光は、機器への接続、および、接続がどのシリアル入力で行われているかを示す。

図１８は、本開示の実施形態による、簡略化された例示的な患者データ・フロー・プロセスを示す。図に表されているように、患者がステップ１８０２で介護者環境に収容されると、患者に関するデータは、介護者バックエンドシステム２０６に投入される。サーバ２１４は、ステップ１８０４でこの情報を獲得もしくは受信し、その後、ハブ１００からアクセスできるようにすることがあると有利である。介護者がステップ１８０６でハブ１００を患者に割り当てるとき、介護者は、単に現在利用可能な患者データを見て、現在監視対象である特定の患者を選択する。ハブ１００は、ステップ１８０８で、次に、受信および決定する測定、監視および治療データを患者に関連付ける。介護者は、機器が（１）ドッキングステーション、（２）ユニバーサル医療コネクタ、（３）シリアルデータコネクタ、もしくは（４）当業者に知られている他の通信メカニズムを用いてハブ１００を介して通信している限り、別の機器を患者に再び関連付ける必要はない。ステップ１８１０で、受信された、処理された、および／または決定されたデータの一部もしくは全部は、前述のサーバシステムに渡される。

図１９Ａ〜１９Ｊは、本開示の実施形態による、図１のハブ１００とドッキング接続された携帯型患者モニタ用の解剖学的図形の例示的な表示を示す。図１９Ａに表されているように、心臓、肺および呼吸器系が表されているが、脳は、強調表示されていない。それ故に、介護者は、意識深度監視もしくは脳オキシメトリシステムが携帯型患者モニタ接続もしくはチャンネルデータポートを介してハブ１００と現在通信していないことを容易に決定できる。しかしながら、音響もしくは他の呼吸器官データおよび心臓データは、ハブ１００に通信されている、もしくは、ハブ１００によって測定されている可能性が高い。さらに、介護者は、ハブ１００が強調された身体部分に関して警告データを受信していないことを容易に決定できる。実施形態では、強調された部分は、現在測定対象である挙動を表すためにアニメーション化することがあり、あるいは、代替的に、所定の形式でアニメーション化することがある。

図１９Ｂは、健康の指標を表している仮想チャンネルの追加を表している。図１９Ｂに表されているように、この指標は、「１００」まで徐々に増大する深刻度スケールで「３４」であるので肯定的である。健康指標は、問題を明らかにするために陰影を付けられることもある。図１９Ｂと対照的に、図１９Ｃは、問題になっている、もしくは、問題になっていた健康数値と、アラーム中の心臓図形とを表している。このようにして、ハブ１００上の、または、そうでなければ、患者を監視もしくは治療する別の機器もしくはシステム上の患者アラームに応答する介護者は、バイタルサインおよび心臓機能に関連する他のパラメータの再検討が患者を診断および／または治療するために必要とされることを直ちに決定できる。

図１９Ｄおよび１９Ｅは、強調された身体部分に組み入れられている脳を表し、ハブ１００が、たとえば、鎮静深度データもしくは脳オキシメトリデータなどの脳機能に関連するデータを受信していることを意味する。図１９Ｅは、図１９Ｃに類似したアラーム中の心臓機能を付加的に表している。

図１９Ｆでは、腎臓のようなさらなる臓器が監視対象とされているが、呼吸器系は、監視されていない。図１９Ｇでは、アラーム中の心臓機能が表され、図１９Ｈでは、アラーム中の循環器系が表されている。図１９Ｉは、肺、心臓、脳および腎臓と共に健康指標を表している。図１９Ｊは、アラーム中の肺、心臓、および循環器系を健康指標と共に表している。さらに、図１９Ｊは、たとえば、心臓が緊急のため赤色を警報し、循環器系が警戒のため黄色を警報するような深刻度コントラストを表している。当業者は、本明細書における開示から適切である他の色スキームを認めるであろう。

図２０Ａ〜２０Ｃは、本開示の実施形態による、データ分離および測定データをそれぞれ表す例示的な表示を示す。図２１Ａおよび２１Ｂは、本開示の実施形態による、データ分離およびデータ重なり合いをそれぞれ同様に表す測定データの例示的な表示を示す。

たとえば、音響センサからの音響データは、呼吸音データを供給することがあると有利であり、プレチスモグラフおよびＥＣＧもしくは他の信号は、別個の波形で提示することもできる（図２０Ａ、画面キャプチャの一番上）。モニタは、呼吸数、呼気流、一回換気量、分時換気量、無呼吸時間、呼吸音、ラ音、いびき音、喘鳴、および、量の減少もしくは気流の変化のような呼吸音の変化といった、患者の種々の呼吸パラメータのいずれかを決定することがある。加えて、いくつかの事例では、システムは、プローブオフ検出に役立つ心拍、心音（Ｓ１、Ｓ２、Ｓ３、Ｓ４、および心雑音）、および、標準対心雑音のような心音の変化もしくは体液過剰を示す分裂心音などの他の生理学的な音を監視する。

複数の生理学的信号の間に視覚的な相関関係を与えることは、信号がいくつかの観測可能な生理学的な相関関係を有するある程度の数の重要な利益をもたらすことができる。このような相関関係の一実施例として、プレチスモグラフの信号の形態（たとえば、エンベロープおよび／またはベースライン）の変化は、患者血液もしくは他の流体レベルを示す可能性がある。しかも、これらの変化は、血液量減少もしくは他の流体レベル関連条件を検出するために監視され得る。脈波変動指標は、たとえば、流体レベルの指標を与えることがある。そして、プレチスモグラフ信号の形態の変化は、呼吸に相関関係がある。たとえば、プレチスモグラフ信号のエンベロープおよび／またはベースラインの変化は、息をすることに相関関係がある。これは、少なくとも部分的に、呼吸中の心臓と肺との間の機械的関係および相互作用のような人間の解剖学的構造の態様が原因である。

このようにして、プレチスモグラフ信号と呼吸信号との間の重ね合わせ（図２０Ｂ）は、これらから導出されたプレチスモグラフ信号もしくは信号群の変動性の指標、たとえば、脈波変動指標をオペレータに与える可能性がある。たとえば、吸気および呼気を表す呼吸信号のバーストがプレチスモグラフエンベロープにおける山および谷の変化と相関関係がある場合、これは、プレチスモグラフ変化が実際には呼吸に起因し、いくつかの他の外的要因に起因しないという視覚的な指標を監視要員に与える。同様に、呼吸信号のバーストがプレチスモグラフエンベロープにおける山および谷とぴったり合う場合、このことは、呼吸信号のバーストが患者呼吸音に起因し、いくつかの他の非標的音（たとえば、患者無呼吸音もしくは非患者音）に起因しない、という指標を監視要員に与える。

モニタは、信号を処理し、２つの信号の間の相関関係の閾値レベルが存在するか否かを決定し、または、相関関係を評価するように構成されることもある。しかしながら、たとえば、互いに重ね合わされた信号を表すことなどによって、相関関係の視覚的な指標を付加的に設けることにより、ディスプレイは、連続的、直観的、および容易に観測可能な特定の生物学的な相関関係の基準をオペレータに提供する。たとえば、重ね合わされた信号を見ることにより、ユーザは、そうでなければ、確かめることができないかもしれない、長期間に亘る相関関係の傾向を観測することができる。

モニタは、プレチスモグラフ信号および呼吸信号に代えて、もしくは、プレチスモグラフ信号および呼吸信号に加えて種々の他の種類の信号を視覚的に相関させることができる。たとえば、図２０Ｃは、別の監視ディスプレイ例のスクリーンショットを表現する。図２０Ｃの右上部分に表されているように、ディスプレイは、プレチスモグラフ信号と、ＥＣＧ信号と、呼吸信号とを重ね合わせる。他の構成では、４種類以上の信号が互いに重ね合わされることがある。

一実施形態では、ハブ１００は、ユーザが互いに重ね合わせるために信号を一緒に通り抜けさせることができるインターフェースを全く提供しない。たとえば、タッチ・スクリーン・インターフェースを使用して呼吸信号をプレチスモグラフ信号の上にドラッグできることがある。逆に、ユーザは、同様にタッチ・スクリーン・インターフェースを使用して、信号を分離できることもある。別の実施形態では、モニタは、ユーザが押すことができるボタン、または、前述のとおり、ユーザが信号を重ね合わせる、および、分離することを可能にさせる何らかの他のユーザ・インターフェースを含む。図２１Ａおよび２１Ｂは、同様の信号の分離および連結を表している。

ある構成では、プレチスモグラフ信号と呼吸信号との間に相関関係を与えるのに加えて、モニタは、２つの信号の間の相関関係を決定するために呼吸信号およびプレチスモグラフ信号を処理するようにさらに構成されている。たとえば、モニタは、プレチスモグラフ信号のエンベロープおよび／またはベースラインの変化の山および谷が、呼吸信号におけるバーストに対応するか否かを決定するために信号を処理することがある。そして、相関の閾値レベルが存在する、もしくは、存在しない、と決定することに応答して、モニタは、何らかの指標をユーザに提供することがある。たとえば、モニタは、図形指標（たとえば、脈波変動指標インジケータの色の変化）、可聴アラーム、または他の指標を提供することがある。モニタは、決定を行う際に１つ以上のエンベロープ検出器もしくは他の適切な信号処理構成部品を利用することがある。

ある実施形態では、システムは、図形指標に代えて、もしくは、図形指標に加えて、患者の呼吸音の可聴の指標をさらに提供することがある。たとえば、モニタは、スピーカを含むことがあり、もしくは、イヤホン（たとえば、無線イヤホン）が監視要員に提供され、患者音声の可聴出力を提供することがある。このような能力を有するセンサおよびモニタの例は、米国特許出願公開第２０１１／０１７２５６１号明細書に記載され、参照により本明細書に組み込まれる。

前述の利益に加えて、音響信号およびプレチスモグラフ信号を両方共に上記方式で同じディスプレイに供給することにより、監視要員が呼吸のない呼吸休止イベント、音響信号を劣化させる可能性がある高周囲雑音、不適切なセンサ配置などをより一層容易に検出することが可能になる。

図２２Ａ〜２２Ｂは、本開示の実施形態による、例示的なアナログ表示標識を示す。図２２Ａおよび２２Ｂに表されているように、スクリーンショットは、他のデータに加えて、様々な生理学的パラメータの健康インジケータを表示する。各健康インジケータは、アナログインジケータおよび／またはデジタルインジケータを含む可能性がある。健康インジケータがアナログおよびデジタルインジケータを含む実施形態では、アナログおよびデジタルインジケータは、横並び、上、下、転置などのかなり多数のフォーメーションで配置される可能性がある。図示された実施形態では、アナログインジケータは、デジタルインジケータより上に、および、デジタルインジケータの両方の横に配置される。図２２Ｂにより明瞭に表されているように、アナログ表示は、着色された警告セクション、グラフ上の位置を示すダッシュ記号、および、グラフを形成する定量化情報を指定するデジタル情報を含むことがある。図２２Ｂでは、たとえば、脈拍数ＰＲグラフは、毎分約５０から約１４０の拍動を表し、このグラフは、ニュートラルであるか、もしくは、警告になり始めているが、これらの数値の外側で、グラフは、深刻な状態を示すために着色されている。それ故に、ダッシュ記号が円弧に沿って進むのにつれて、介護者は、許容可能、警告、および、極端の範囲内で現在測定値が降下する場所を容易に確かめることができる。

健康インジケータの各アナログインジケータは、監視対象である生理学的パラメータの測定されたレベルに基づいて円弧を動き回るダイヤルを含む可能性がある。測定された生理学的パラメータレベルが増加するのにつれて、ダイヤルは、時計回りに動くことができ、測定された生理学的パラメータレベルが減少するのにつれて、ダイヤルは、反時計回りに動くことができ、逆の場合も同様である。このようにして、ユーザは、アナログインジケータを見ることによって患者の状態を迅速に決定することができる。たとえば、ダイヤルが円弧の中心にあるとき、観測者は、現在の生理学的パラメータ測定値が正常であることを確信でき、ダイヤルが極端に左もしくは右へ傾斜している場合、観測者は、生理学的パラメータのレベルの深刻度を迅速に評価し、適切な処置を講じることができる。他の実施形態では、正常なパラメータ測定値は、ダイヤルが右寄りもしくは左寄りであるときなどに示される可能性がある。

いくつかの実施形態では、ダイヤルは、ドット、ダッシュ記号、矢印などとして実装される可能性があり、円弧は、必要に応じて、円、螺旋、ピラミッド形、もしくは他の形状として実装される可能性がある。さらに、現在の生理学的パラメータ測定レベルに基づいて、円弧全体が照らし出される可能性があり、もしくは、円弧の一部分だけが照らし出される可能性がある。さらに、円弧は、現在の生理学的パラメータレベルに基づいて変色する、もしくは、強調表示される可能性がある。たとえば、ダイヤルが閾値レベルに接近するのにつれて、円弧および／またはダイヤルは、緑色から、黄色、赤色に変わる、より明るく輝く、点滅する、拡大される、ディスプレイの中心へ動くなどの可能性がある。

異なる生理学的パラメータは、異常状態を示す異なる閾値を有する可能性がある。たとえば、いくつかの生理学的パラメータは、上側下側閾値レベルということがあり、他の生理学的パラメータは、上側閾値もしくは下側閾値だけを有することがある。従って、各健康インジケータは、監視対象である生理学的パラメータに基づいて調節される可能性がある。たとえば、ＳｐＯ２健康インジケータは、条件を満たすときにアラームを作動させる下側閾値を有する可能性があり、呼吸数健康インジケータは、下側および上側の両方の閾値を有する可能性があり、いずれかの条件を満たすとき、アラームが作動される。各生理学的パラメータに対する閾値は、典型的な期待閾値および／またはユーザ指定閾値に基づく可能性がある。

デジタルインジケータは、生理学的パラメータの現在レベルの数値表現を提供する可能性があり、デジタルインジケータは、実際のレベルもしくは正規化されたレベルを示すことがあり、患者状態の深刻度を迅速に評価するために使用される可能性もある。いくつかの実施形態では、表示は、監視対象である各生理学的パラメータに対する複数の健康インジケータを含む。ある実施形態では、表示は、監視対象である生理学的パラメータの個数より少数の健康インジケータを含む。このような実施形態では、健康インジケータは、様々な監視対象である生理学的パラメータの間を循環する可能性がある。

図２３Ａ〜２３Ｆは、たとえば、意識深度モニタが図１のハブのチャンネルポートに接続されているとき、図２３Ａ〜２３Ｄにおけるデータ表現を表している測定データの例示的な表示を示す。図２３Ａ〜２３Ｃに表されているように、ハブ１００は、たとえば、カリフォルニア州アーバイン所在のＭａｓｉｍｏ Ｃｏｒｐ．から市販されているＳＥＤＬｉｎｅ機器からの様々な情報を表すために、このハブのディスプレイ１０４を大まかに分岐させると有利である。図２３Ｄでは、ハブ１００は、スウェーデンのＰＨＡＳＥＩＮ ＡＢから市販され、たとえば、患者の呼吸に関する情報を提供する、付属Ｐｈａｓｅｉｎ機器を含む。ハブ１００は、ＳｅｄＬｉｎｅ情報も含むので、ハブ１００は、ディスプレイ１０４を適切に分割している。図２３Ｅでは、体温センサおよび血圧センサは、図１のハブと通信し、ハブ１００は、これらのセンサのため適切な表示可能面積を作り出す。図２３Ｆでは、音響センサは、図１のハブ、ならびに、上記血圧センサおよび体温センサとも通信する。従って、ハブ１００は、各付属機器からのデータを収容するために表示可能面積を調節する。

本明細書における用語「および／または」は、本開示では、Ａだけ、Ｂだけ、ＡおよびＢを両方共に、または、ＡもしくはＢを択一的に含む最広義の、最小限の限定の意味を有する。本明細書において使用されているように、Ａ、Ｂ、「および」Ｃのうち「少なくとも１つ」は、非排他的論理和を使用して、論理的なＡまたはＢまたはＣを意味するように解釈されるべきである。

用語「プレチスモグラフ」は、（通常は、臓器もしくは身体全体が含有している血液もしくは空気の量の差異から生じる）臓器もしくは身体全体の内部の容積変化に反応するデータを含む、当該技術において知られているこの用語の通常の広義の意味を含む。

ＩＩＩ． 付加的な監視環境実施形態
図２４は、図１のハブ１００を含む監視環境２０００の別の実施形態を示す。監視環境２０００は、図２の監視環境２００の特徴全てと、前述の他の特徴のいずれかと、を含むことがある。その上、監視環境２０００は、マルチ患者監視システム２０４の別の実施形態、すなわち、マルチ患者監視システム（ＭＭＳ）２００４を表現する。ＭＭＳ ２００４は、シリアルデータを受信し、シリアルデータを監視ハブ１００によって認識可能なフォーマットに翻訳し、シリアルデータを（他の機器の中でことによると）監視ハブ１００に供給することができる翻訳モジュール２００５を含む。さらに表されているのは、ＭＭＳ ２００４、監視ハブ１００、もしくは、ＰＰＭ １０２と有線もしくは無線で通信することがある補助機器２０４０である。

前述のとおり、ハブ１００は、患者のベッド２１４、灌流ポンプ２１６、人工呼吸器２１８、および他のバイタルサインモニタ２２０を含む多種多様の医療器具からシリアルデータを受信することがある。ハブ１００は、これらの供給源からのシリアルデータをＭＭＳ ２００４に渡すことができる。前述のとおり、ＭＭＳ ２００４は、その後、シリアルデータをＥＭＲシステムもしくはＡＤＴシステムのような介護者バックエンドシステム２０６に格納することがある。

このシリアルデータを供給する医療器具は、ハブ１００によって元々認識できないことがある多種多様の独自仕様プロトコル、メッセージング基盤などを使用することがある。従って、ハブ１００は、この医療器具からパラメータ値もしくは他のデータを読み取る元々の能力を持たないことがあり、その結果として、これらの機器からのパラメータ値もしくは他のデータを表示する能力を持たないことがある。しかしながら、ＭＭＳ ２００４における翻訳モジュール２００５は、これらの機器からシリアルデータを受信し、シリアルデータを監視ハブ１００によって認識可能なフォーマットに翻訳し、シリアルデータを監視ハブ１００に供給することができると有利である。監視ハブ１００は、この場合、翻訳済みの情報からパラメータ値および他のデータを読み取り、これらの値もしくはデータを前述のディスプレイのいずれかのようなディスプレイに出力することができる。

実施形態では、翻訳モジュール２００５は、シリアルデータをあるフォーマットから別のフォーマットに翻訳もしくは変換するために１つ以上の翻訳ルールをシリアルデータに適用する。シリアルデータは、一実施形態では、ヘルス・レベル・セブン（「ＨＬ７」）プロトコルに従ってフォーマットされることがある。ＨＬ７プロトコルは、医療コンピュータシステムおよび機器の間の臨床メッセージの通信のためのメッセージングフレームワークを提供するために開発されている。しかしながら、ＨＬ７標準は、非常に柔軟性があり、ガイドラインのフレームワークを提供するだけである。その結果、全てＨＬ７に準拠する医療機器もしくは臨床コンピュータシステムは、それでもなお互いに通信できないことがある。たとえば、医療器具２１４〜２２０は、各々がＨＬ７プロトコルの１つのバージョンを実装することがあるが、これらの実装法は、監視ハブ１００によって実装されたＨＬ７プロトコルとは異なることがある。従って、監視ハブ１００は、監視ハブおよび医療器具の両方がＨＬ７標準を使用するとしても、医療器具２１４〜２２０からのメッセージを構文解析できない、もしくは、読み取れないことがある。さらに、翻訳モジュール２００５は、いくつかの実施形態では、ハブ１００および医療器具２１４〜２２０によって実装されたＨＬ７プロトコル以外の共通標準の異なった実装法の間で翻訳することがある。

共通電子医療通信プロトコルを異なった実装法（たとえば、ＨＬ７メッセージの異なったフォーマッティング）の間で翻訳するのに加えて、翻訳モジュール２００５は、異なった通信プロトコルに従う入力メッセージと出力メッセージとの間でさらに翻訳することができる。いくつかの実施形態では、翻訳モジュール２００５は、たとえば、１つの医療通信プロトコルからのメッセージ応答し、別個の医療通信プロトコルに翻訳するする能力がある。たとえば、翻訳モジュール２００５は、ＨＬ７プロトコル、ＩＳＯ １１０７３プロトコル、他のオープンプロトコル、もしくは、独自仕様のプロトコルに従って送信されたメッセージの間の通信を容易化することができる。その結果、翻訳モジュール２００５は、ＨＬ７プロトコルに従って送信された入力メッセージを異なったプロトコルに従う出力メッセージに翻訳することができ、逆もまた同様である。ある実施形態では、翻訳モジュール２００５は、
「翻訳モジュール実施形態」という表題のセクションに、さらに、開示が全体として参照によって本明細書に組み込まれる、２０１３年９月１９日付けで出願された「Ｍｅｄｉｃａｌ Ｍｏｎｉｔｏｒｉｎｇ Ｓｙｓｔｅｍ」と題する米国特許出願１４／０３２，１３２号明細書により詳しく後述される翻訳特徴のいずれかを実装することができる。

有利であるのは、ある実施形態では、翻訳モジュール２００５が翻訳済みのシリアルデータをハブ１００もしくはＰＰＭ １０２に返すことができることである。翻訳済みのデータは、ハブ１００もしくはＰＰＭ １０２によって読み取り可能なフォーマットであるので、ハブ１００もしくはＰＰＭ １０２は、医療器具２１４〜２２０からのデータをハブ１００もしくはＰＰＭ １０２のディスプレイ上に出力できる。その上、翻訳モジュール２００５は、翻訳済みのデータを（携帯電話機、タブレット、もしくはポケットベルなどの）臨床機器および後述される補助機器２０４０といった、ハブ１００以外の機器に供給することができる。さらに、医療器具２１４〜２２０によって供給されたシリアルデータは、アラーム通知を含むことがあるので、翻訳モジュール２００５は、これらのアラーム通知をハブ１００もしくはＰＰＭ １０２に渡すことができる。ハブ１００もしくはＰＰＭ １０２は、その結果、これらのアラーム通知に応答して視覚的アラームもしくは可聴アラームを発生させることができる。さらに、翻訳モジュール２００５は、たとえば、病院ネットワークもしくは（インターネットのような）広域ネットワークを介してアラーム通知を臨床機器に供給することができる。その上、翻訳モジュール２００５は、アラーム通知を補助機器２０４０に供給することができる。

翻訳モジュール２００５は、翻訳モジュール２００５の翻訳ルールを単一の場所で維持し、更新することが役に立つことがあるので、ＭＭＳ ２００４に実装されるものとして表されている。しかしながら、他の実施形態では、翻訳モジュール２００５は、ハブ１００もしくはＰＰＭ １０２に同様に（もしくは代わりに）実装されることがある。従って、ハブ１００もしくはＰＰＭ １０２は、ハブ１００もしくはＰＰＭ １０２のディスプレイへの出力用のシリアルデータを翻訳するために内部の翻訳モジュール２００５にアクセスすることができる。

補助機器２０４０は、物理的なコンピュータハードウェア、ディスプレイなどを有するコンピューティング機器である可能性がある。たとえば、補助機器２０４０は、臨床医によって使用される、タブレット、ラップトップ、携帯電話機もしくはスマートホン、携帯情報端末（ＰＤＡ）、（たとえば、スマートウォッチもしくはスマートメガネといった）ウェアラブルコンピュータなどのようなハンドヘルド型コンピューティング機器でもよい。補助機器２０４０は、単純に、コンピュータモニタもしくはデジタルテレビのような表示機器であることもある。実施形態では、補助機器２０４０は、ハブ１００、ＰＰＭ １０２、もしくはＭＭＳ ２００４に第２の画面機能性を提供する。従って、補助機器２０４０は、無線で、もしくは有線接続を介してハブ１００、ＭＲＳ ２００４、もしくはＰＰＭ １０２と通信することができる。

第２の画面機器として、補助機器２０４０は、ハブ１００（もしくはＰＰＭ １０２）の表示、または、異なるバージョンのハブ１００（もしくはＰＰＭ １０２）表示の少なくとも一部分の複製を表現することができる。たとえば、補助機器２０４０は、ハブ１００、ＰＰＭ １０２、もしくはＭＭＳ ２０４０からの生理学的パラメータデータ、傾向データ、または、波形を受信し、パラメータデータ、傾向データ、もしくは波形を表示することができる。補助機器２０４０は、ハブ１００、ＰＰＭ １０２、もしくはＭＭＳ ２００４が利用できるどのような情報でも出力することができる。補助機器２０４０の一つの使用法は、患者の部屋から遠く離れている間に（もしくは、患者の部屋の中にいるときでも）ハブ１００、ＰＰＭ １０２、もしくはＭＭＳ ２００４からのデータを見るために臨床医によって使用可能な臨床機器のようなものである。臨床医は、実施形態においてハブ１００もしくはＰＰＭ １０２に表示された生理学的パラメータに関する情報より詳細な情報を見るために補助機器２０４０を使用できる（たとえば、図３９を参照のこと）。たとえば、補助機器２０４０は、臨床医がパラメータ活動をより厳密に調べるために傾向もしくは波形を拡大表示できるようにする拡大表示機能性などを含むことがある。

ハブ１００もしくはＰＰＭ １０２の表示の少なくとも一部分を複製する１つの理由例は、異なった臨床医が外科手術中にデータについて同じ見方を行えるようにすることである。いくつかの外科手術では、たとえば、２人の麻酔専門医が患者を監視し、一方の麻酔専門医は、患者の脳機能および脳酸素化を監視し、もう一方は、患者の末梢酸素化を監視する。前述されているような脳センサは、患者に装着され、提示のためハブ１００もしくはＰＰＭ １０２へ出力される脳監視および酸素化データを第１の麻酔専門医に供給することがある。指もしくは足指／足センサも患者に装着され、データをハブ１００もしくはＰＰＭ １０２へ出力することができる。ハブ１００もしくはＰＰＭ １０２は、このデータを補助機器２０４０に送信することができ、第２の麻酔専門医は、患者の末梢手足における酸素化を観測するためにこのデータを監視することができる。第２の麻酔専門医は、不十分な末梢酸素化値の深刻度もしくは深刻度の欠如を解釈するのに役立てるために、脳における酸素化を知る必要があることもある。しかしながら、多くの外科手術では、手術の一部としてカーテンもしくはスクリーンが患者の上に置かれ、第２の麻酔専門医によるハブ１００もしくはＰＰＭ １０２の視野を遮る。従って、ハブ１００もしくはＰＰＭ １０２は、これの表示の少なくとも一部分の複製を補助機器２０４０へ出力することができるので、第２の麻酔専門医は、脳機能もしくは酸素化を監視することができる。

一実施形態では、補助機器は、ハブ１００のディスプレイより大きい表示面積を有する。たとえば、ハブ１００は、およそ１０インチのような比較的小さいディスプレイを有することがあるが、補助機器２０４０は、４０インチもしくはそれより大きいディスプレイを有するテレビモニタなどであるかもしれない（どのようなサイズのディスプレイでも補助機器２０４０のため使用されることがある）。実施形態では、テレビとしての補助機器２０４０は、プロセッサ、メモリ、および無線もしくは有線ネットワーキングインターフェースなどを含むハードウェアモジュールを含むことができる。プロセッサは、メモリから、生理学的パラメータ、傾向、および波形をテレビのディスプレイに表示するプログラムを含んでプログラムを実行することができる。テレビモニタは、ハブ１００の実施形態より大型であるため、補助機器２０４０のテレビモニタバージョンは、いくつかの実施形態における患者波形および傾向のより精密な細部を表示することができる（たとえば、図３９を参照のこと）。

別の実施形態では、補助機器２０４０は、本明細書に記載された表示のいずれかの一部分を表示することがあり、ハブ１００は、本明細書に記載された表示の別の部分を表示することがある。たとえば、補助機器２０４０は、図１９Ａ〜１９Ｊに関連して前述された解剖学的グラフのいずれかを表示することがあり、ハブ１００は、図２０Ａ〜２３Ｆに関連して前述されたパラメータ表示のいずれかを表示する（逆もまた同様である）。同様に、補助機器２０４０は、翻訳モジュール２００５から受信した翻訳済みのデータを表示することがあり、一方ハブ１００は、チャンネルデータを表示することがある（逆もまた同様である）。別の実施形態では、補助機器２０４０は、翻訳済みのデータおよびチャンネルデータの両方を表示することができる（たとえば、図３８を参照のこと）。

さらに別の実施形態では、補助機器２０４０は、監視ハブ１００の機能性のいずれかを含む生理学的パラメータの少なくとも一部の処理を行うことができる。たとえば、補助機器２０４０は、翻訳モジュール２００５を含み、この翻訳モジュールの特徴を行うことがある。

図２５は、翻訳メッセージ取扱プロセス２１００の実施形態を示す。プロセス２１００は、前述の翻訳モジュール２００５によって、または、他のコンピューティングシステムによって実装される可能性がある。実施形態では、ブロック２５０２で、翻訳モジュール２００５は、ハブ１００（もしくはＰＰＭ １０２）から、ハブ１００（もしくはＰＰＭ １０２）と元々から互換性のない医療機器からのメッセージを含むメッセージを受信する。ブロック２５０４で、翻訳モジュール２００５は、ハブ１００（もしくはＰＰＭ １０２）によって処理され得る翻訳済みの出力メッセージを生成するために１つ以上の翻訳ルールに基づいてメッセージを翻訳する。ブロック２５０６で、翻訳モジュールは、翻訳済みの出力メッセージをハブ１００（もしくはＰＰＭ １０２）での、または、補助機器２０４０での表示のためハブ１００に供給する。ハブ１００（もしくはＰＰＭ １０２）は、翻訳済みのデータを補助機器２０４０へ向けることがあり、または、補助機器２０４０は、翻訳モジュール２００５から直接的に翻訳済みのデータを受信することがある。

たとえば、一実施形態では、デジタル論理回路を有する第１の医療機器は、生理学的センサから患者に関連付けられた生理学的信号を受信し、生理学的信号に基づく第１の生理学的パラメータ値を取得し、表示のため第１の生理学的パラメータ値を出力する。第１の医療機器はまた、第１の医療機器が表示可能な出力値を生成するために第２の生理学的パラメータ値を処理できないように、第１の医療機器以外の第２の医療機器から、第１の医療機器によって使用されないプロトコルに従ってフォーマットされた第２の生理学的パラメータ値を受信する可能性がある。第１の医療機器は、第１の医療機器から別個の翻訳モジュールへ生理学的パラメータデータを渡し、第１の医療機器で翻訳モジュールから、第１の医療機器により表示のため処理することができる翻訳済みのパラメータデータを受信し、表示のため翻訳済みのパラメータデータから第２の値を出力することができる。第１の医療機器は、たとえば、ハブ１００、ＰＰＭ １０２、もしくはＭＭＳ ２００４でもよく、第２の医療機器は、灌流ポンプ２１６もしくは人工呼吸器２１８などでもよい。

図２６〜３８および４６〜７１は、測定データの表示を含むさらなるハブ表示例を示す。これらの表示の１つずつは、補助機器２０４０によって実装されることがあるが、同様の表示が直接的にハブ１００（もしくはＰＰＭ １０２）へ出力されることもある。例示された図は、タッチスクリーン機能性を含むタブレットコンピュータのため実装されているものとして表現される。タッチスクリーン機能性は、オプションであり、キーボード、マウス、トラックホイールなどのような他の適切な入力機器によって置き換えられることがある。

図２６を参照すると、図示されたユーザ・インターフェースは、補助機器２０４０に接続されている機器を表現する。図示された機器は、監視ハブ１００の実施形態である可能性がある「Ｏｍａｒ’ｓ Ｈａｗｋ」である。補助機器２０４０は、本実施形態では、ハブ１００からデータを受信するように、ハブ１００に無線接続されている。補助機器は、他の実施形態では、ＭＭＳ ２００４もしくはＰＰＭ １０２に無線接続されることもあり得る。

図２７は、補助機器２０４０上のデフォルトのパラメータ表示を表現する。パラメータ値は、表示の上部に波形と共に表され、（ＳｐＨｂ、ＳｐＭｅｔ、ＰＶＩなどのような）他のパラメータは、対応する波形を伴わずに表示の下部に表されている。表示の下部にあるこれらのパラメータはいずれも、これらの波形を表示させるために表示の上部にドラッグ・アンド・ドロップされることがある。たとえば、図２８は、ＳｐＨｂパラメータが表示の上部にドラッグ・アンド・ドロップされ、ＳｐＨｂ波形とアラーム限界（１８および７）上の付加的な詳細とを表示させる点を除いて、表示の図２７における表示と同様の表示を表現する。同様に、図２９は、ＳｐＭｅｔパラメータが表示の上部にドラッグ・アンド・ドロップされ、これの波形とアラーム限界（３）とを表示させる点を除いて、図２８と同じ表示を表している。

図２７〜２９の表示の各々では、時間窓ボタンが右上隅に表されている。この時間窓ボタンは、図２７〜２９において「１時間」と書かれているが、時間窓を変更するためにユーザによって選択されることがあり、表示に表される傾向もしくは波形データの窓に影響を与えることができる。この時間窓ボタンのユーザ選択と、１０分窓への変更が図３０に表されている。同図から分かるように、図３０における波形は、前の図に表されるより小さい時間窓で表されている。

図３１は、本明細書における他の場所に記載された他の積み重ねられた波形に類似した、積み重ねられたＳｐＯ２および呼吸波形を含んでいる、波形が積み重ねられた図２９の表示の別のバージョンを表している。図３２は、脈拍数（ＰＲ）およびＳＰＭｅｔ（メトヘモグロビン）パラメータがアラーム状態であるとして強調表示されている図２９に類似した表示を表している。アラーム状態は、実施形態では、パラメータ値および波形の周りに赤色ボックスとして、または、ボックスの少なくとも一部分を着色する赤色透明で表現される可能性がある。赤色ボックスもしくは透明は、実施形態では、点滅することもあり、可聴アラームが鳴動することがある。アラーム状態を表現する他の方法が他の実施形態において使用される。

図３３は、ユーザがパラメータ（本実施形態では、ＳｐＨｂもしくは総ヘモグロビン）に対するアラーム限界を調節できるようにするポップアップ・インターフェースを表している。ポップアップ・インターフェースは、ユーザが可能なパラメータ限界値の間を素早くスクロールし、選択できるようにするスクロールホイールを含む。

図３４〜３８は、図２６〜３３の縦長の表示とは対照的に横長の表示図を表している。これらの横長の表示図は、（タブレットなどのような）補助機器２０４０を横長の向きまで回転させることにより利用できるようにされることがある。図２７〜２９に関連して前述されたものに類似して、図３４は、第１のパラメータの組を表し、図３５および３６は、付加的なドラッグ・アンド・ドロップ型パラメータをこれらの波形および付加的なアラーム限界詳細と共に追加する。図３７は、積み重ねられたパラメータ波形と、積み重なっているＳｐＯ２波形および呼吸波形を表現している。図３８は、両方のチャンネルパラメータ（たとえば、ＳｐＯ２、ＰＲ（脈拍数）、およびＲＲａ（音響的に測定された呼吸数））を表現し、同時に、ポンプおよびベントからのパラメータを含んでいる翻訳済みのシリアルデータパラメータ２２１０も表している。これらの翻訳済みのシリアルデータパラメータ２２１０は、ハブ１００を介して、もしくは、ＭＭＳ ２００４から直接的に、翻訳モジュール２００５から受信されていることがある。

再び図２４を参照すると、前述のとおり、ハブ１００もしくはＰＰＭ １０２は、表示の少なくとも一部分の複製を補助機器２０４０へ出力することができる。他の実施形態では、ハブ１００もしくはＰＰＭ １０２は、ハブ１００もしくはＰＰＭ １０２に表された全パラメータの部分集合に関するデータを補助機器２０４０へ出力することができる。たとえば、ハブ１００もしくはＰＰＭ １０２は、臨床医が補助機器２０４０に表示された１つ以上のパラメータだけを確認するためにハブもしくはＰＰＭに表示されたパラメータのうち１つ以上を選択する機能性を提供することがある。このようにすると、ハブ１００もしくはＰＰＭ １０２上より少数のパラメータが補助機器２０４０のディスプレイに表示されることになるので、補助機器２０４０が選択された１つ以上のパラメータに関するより一層の詳細を表示できるようになる。

図３９は、１つのパラメータ、すなわち、呼吸数に関するデータを表現する補助機器２０４０の１つの表示例を表現する。ハブ１００もしくはＰＰＭ １０２の主表示とは異なって、図３９に表された表示は、呼吸数の現在値２２１５、最近の傾向２２３０、および小さい波形のみではなくそれ以上を含む。その上、表示は、監視対象である患者の（たとえば、過去数日間の）過去最高および最低のヒストグラム２２２０を表現する。その上、ハブ１００もしくはＰＰＭ １０２の主表示に表された波形より大きい詳細な波形２２４０が表され、患者の呼吸状態についてのより一層詳細な理解をユーザに与えることがある。ユーザは、波形２２４０（もしくは表示の他の局面）を拡大表示することを選ぶことがあり、表示の他の要素などの代わりに表示を一杯に満たすために波形２２４２を拡大させる。その他のグラフ、表、波形、およびデータが呼吸パラメータのため補助機器ディスプレイ２０４０に表されることがある。当然ながら、呼吸数以外のパラメータは、補助機器２０４０上の詳細な表示のため選択されることもある。

ＩＶ． 翻訳モジュール実施形態
図４０Ａ〜４５Ｄに関して記載された以下の特徴はいずれも図２４の翻訳モジュール２００５によって、または、図２４に関して前述された機器のいずれかと一緒に実装される可能性がある。

医療費は、増加し続け、手頃な価格の高品質患者介護の要求も増えている。医療費は、病院情報システムの有効性を高めることにより削減される可能性がある。健康施設の効率に影響を与えることがある１つの要因は、健康施設で用いられた様々な臨床コンピュータシステムが、情報を交換するために相互に作用し得る範囲である。

病院、患者介護施設、健康管理提供業者組織は、典型的に、電子健康管理情報の管理のための多種多様の臨床コンピュータシステムを含む。全体的なＩＴもしくは管理基盤の医療コンピュータシステムの各々は、特定のカテゴリもしくは患者介護方法の態様を遂行するのに役立つ可能性がある。たとえば、病院は、患者監視システム、医療文書および／または画像化システム、患者管理システム、電子医療記録システム、電子実務管理システム、（薬局および請求書作成のような）営業および財務システム、および／または、通信システムなどを含む可能性がある。

病院もしくは他の患者介護施設における介護の質は、ＩＴ基盤全体における（もしくは、同じ病室の内部であっても、たとえば図１および２４を参照のこと）異なった臨床コンピュータシステムの各々が互いに効率的に通信することができる場合、改良されることがあり得る。これにより、１つの臨床コンピュータシステムによって収集された患者データをこのような患者データから恩恵を受けることがあり得る別の臨床コンピュータシステムと交換することが可能になり得る。たとえば、これにより、利用可能な情報全ての完全な分析に基づいて、患者介護に関係する決定が行われ、措置が講じられることが可能になり得る。

現行の実務では、個別の臨床コンピュータシステムは、異なった供給業者によって提供される可能性があり、多くの場合、異なった供給業者によって提供されている。その結果、個別の臨床コンピュータシステムは、独自ネットワーク、または、通信基盤、独自通信プロトコルなどを使用して実装されることがあり、病院内で使用される様々な臨床コンピュータシステムは、必ずしもいつでも互いに効率的に通信できるとは限らない。

医療機器および医療システム供給業者は、時には、自分たちの市場占有率を高め、かつ、付加的な製品、システムおよび／またはアップグレード版を健康管理提供者に売りつけるために、他の供給業者の医療機器およびシステムと効率的に通信することができない独自システムを開発する。それ故に、健康管理提供者は、使用される個別の臨床コンピュータシステムの種類毎に利用できる最良の技術を選択するのではなく、企業規模もしくはシステム規模の購買意思決定を行わざるを得ない。

このことが起こる一例は、患者監視のため利用可能な救命技術の分野にある。たとえば、多くの異なった生理学的パラメータを監視する様々なベッドサイド機器は、異なった供給業者もしくは提供者から入手可能である。１つの提供者は、特定の生理学的パラメータを監視するクラス最高の機器を提供することがあるが、別のこのような提供者は、別の生理学的パラメータのためのクラス最高の機器を提供することがある。従って、いくつかの状況では、病院が２つ以上の製造業者からの監視機器を使用する自由を有することは、望ましいかもしれないが、これは、異なった製造業者からの機器がインターフェースをとること、および、患者情報を交換することができない場合、可能ではないかもしれない。従って、手頃な価格の、高品質患者介護を提供する能力は、損なわれる可能性がある。その上、各病院もしくは患者介護施設は、これの臨床コンピュータネットワーク環境のため独自の通信プロトコルを実装することもあるので、情報の交換は、さらに妨げられる可能性がある。

前述のとおり、ヘルス・レベル・セブン（「ＨＬ７」）プロトコルが、医療コンピュータシステムおよび機器の間の臨床メッセージの通信のためのメッセージングフレームワークを提供するために開発されている。ＨＬ７通信プロトコルは、様々なＨＬ７に準拠した医療コンピュータシステムが互いに通信するために使用することができるある程度の数の規格、ガイドライン、および方法を指定する。

ＨＬ７通信プロトコルは、多くの医療機器製造業者によって採用されている。しかしながら、ＨＬ７規格は、極めて柔軟性があり、ガイドラインのフレームワーク（たとえば、高水準のメッセージ論理構造）を提供するだけであり、その結果として、各医療機器もしくは医療システムの製造業者もしくは供給業者は、少し異なったやり方でＨＬ７プロトコルを実装することがあるが、それでもなおＨＬ７に準拠したままである。たとえば、ＨＬ７メッセージのフォーマットは、本明細書においてより一層十分に記述されているように、実装法毎に異なる可能性がある。いくつかの事例では、１つの実装法のＨＬ７メッセージは、別のＨＬ７実装法に従うメッセージに含まれていない情報内容を含む可能性もある。従って、全てＨＬ７に準拠する医療機器もしくは臨床コンピュータシステムは、それでもなお互いに通信できないことがある。

その結果として、確立された通信プロトコル（たとえば、ＨＬ７）の種々の許容実装法を使用する医療機器もしくはシステム間の医療メッセージの通信を改善することができ、それによって、多数の臨床コンピュータシステムの統合を通じて患者介護の質を高める翻訳モジュールが提供される可能性がある。

図４０Ａは、翻訳モジュール２４１５を介して互いに通信する第１の医療機器２４０５および第２の医療機器２４１０を示す。第１の医療機器２４０５は、許容電子医療通信プロトコルの第１の許容フォーマットもしくは実装法に従ってメッセージを送信および受信するように構成され、第２の医療機器２４１０は、電子医療通信プロトコルの第２の許容フォーマットもしくは実装法に従って送信および受信するように構成されている。いくつかの実施形態では、第１および第２のプロトコルフォーマットは、ＨＬ７通信プロトコルの異なる実装法である。ＨＬ７に加えて他の電子医療通信プロトコルも使用される可能性がある。

翻訳モジュール２４１５は、第１の医療機器２４０５から第１のプロトコルフォーマットを有する入力メッセージを受信し、第２の医療機器２４１０への第２のプロトコルフォーマットを有する出力メッセージを発生させる。翻訳モジュール２４１５は、第２の医療機器２４１０から第２のプロトコルフォーマットを有する入力メッセージも受信し、第１の医療機器２４０５への第１のプロトコルフォーマットを有する出力メッセージを発生させる。このようにして、翻訳モジュール２４１５は、第１の医療機器２４０５および第２の医療機器２４１０が、各機器によって実装された通信器具もしくはプロトコルへの修正を必ずしも要求することなく、効率的かつシームレスに互いに通信できるようにする。

ある実施形態では、翻訳モジュール２４１５は、たとえば、入力メッセージ内の情報に基づいて、または、様々な機器によって使用されるプロトコルフォーマットを記憶するデータベースを参照することによって、入力メッセージの意図された受信側によって期待されるプロトコルフォーマットを決定し、その後、意図された受信側機器もしくはシステムによって使用されるプロトコルフォーマットに基づいて出力メッセージを発生させる。出力メッセージは、翻訳モジュール２４１５によってアクセス可能である翻訳ルール２４２０の集合との比較、および、この翻訳ルールの集合の適用に基づいて発生させられる可能性がある。

翻訳ルール２４２０は、共通プロトコルの範囲内のフォーマッティング実装法の間に起こり得る差異の対処方法を左右するルールを含む可能性がある。電子医療通信プロトコルのフォーマッティング実装差異の実施例は、特定のフィールドが必要であるか、もしくは、オプションであるか、メッセージの部分（たとえば、セグメント、フィールド、コンポーネント、サブコンポーネント）の繰返し性、メッセージの部分のシーケンス（たとえば、フィールドもしくはコンポーネントの順序）、メッセージの特定の部分が含まれているか否か、メッセージもしくはメッセージの部分の長さ、および、メッセージの様々な部分のため使用されるデータ型とは無関係に、たとえば、データフィールドを分離するために使用される区切り文字もしくはセパレータ文字を含む。

ある実施形態では、翻訳ルール２４２０は、第１のＨＬ７実装法に従う入力メッセージを第２のＨＬ７実装法に従う出力メッセージに翻訳するために実行されるべき追加、削除、交換、および／または修正を定義する。出力メッセージは、たとえば、入力メッセージとは異なるフォーマッティングを有する可能性があるが、入力メッセージの実体もしくは内容の全部もしくは一部を維持する。

共通電子医療通信プロトコルの異なる実装法（たとえば、ＨＬ７メッセージの異なるフォーマッティング）の間の翻訳に加えて、翻訳モジュール２４１５は、異なる通信プロトコルに従う入力メッセージと出力メッセージとの間で翻訳することも可能である。いくつかの実施形態では、翻訳モジュール２４１５は、たとえば、１つの医療通信プロトコルからのメッセージに応答し、別個の医療通信プロトコルに翻訳する能力がある。たとえば、翻訳モジュール２４１５は、ＨＬ７プロトコル、ＩＳＯ １１０７３プロトコル、他のオープンプロトコル、および／または、独自プロトコルに従って送信されたメッセージ間の通信を実現しやすくすることができる。その結果、ＨＬ７プロトコルに従って送信された入力メッセージは、異なるプロトコルに従う出力メッセージに翻訳される可能性があり、逆もまた同様である。

翻訳モジュール２４１５の動作および翻訳ルール２４２０は、より詳細に後述される。翻訳モジュール２４１５を含むシステムアーキテクチャの様々な実施形態を次に説明する。

ある実施形態では、第１の医療機器２４０５、第２の医療機器２４１０、および翻訳モジュール２４１５は、共通通信ネットワークへの接続を介して、または、直接的に（ケーブル経由もしくは無線で）、たとえば、ハブ１００、ＰＰＭ １０２、および／またはＭＭＳ ２００４を介して、通信結合されている。いくつかの実施形態では、翻訳モジュール２４１５は、第１の医療機器２４０５と第２の医療機器２４１０との間の全てのメッセージが翻訳モジュール２４１５を介して送付されるように、（通信ネットワークの有無とは無関係に）第１の医療機器２４０５と第２の医療機器２４１０との間に通信結合され得る。

第１および第２の医療機器２４０５、２４１０と翻訳モジュール２４１５とは、たとえば、前述の図１もしくは２４の監視環境の一部分に含まれる可能性がある。第１の医療機器２４０５は、たとえば、灌流ポンプ（群）２１６もしくは人工呼吸器２１８でもよく、第２の医療機器２４１０は、たとえば、監視ハブ１００、ＰＰＭ １０２、ＭＭＳ ２００４、もしくは補助機器２０４０でもよい。翻訳モジュール２４１５は、翻訳モジュール２００５の実装例である。

ある実施形態では、翻訳モジュール２４１５は、病院環境の内部の多数のネットワークに渡る通信を実現しやすくする可能性がある。他の実施形態では、翻訳モジュール２４１５は、病院もしくは臨床ネットワーク環境の外側に広がる１つ以上のネットワークに渡るメッセージの通信を実現しやすくする可能性がある。たとえば、翻訳モジュール２４１５は、金融機関、保険業者、政府機関、外部薬局、他の病院、養護施設、もしくは、患者介護施設、医院などとの通信インターフェースを提供することができる。

いくつかの実施形態では、図４０の翻訳モジュール２４１５は、たとえば、図２４に関して前述した環境２０００のコンポーネントである可能性がある。たとえば、翻訳モジュール２４１５は、病院ネットワークもしくは他のネットワーク、または、前述の監視環境と通信結合される可能性がある。このような実施形態では、翻訳モジュール２４１５は、たとえば、ベッドサイド医療モニタ機器、看護監視ステーション、（電子医療記録を記憶することがある）病院もしくは臨床情報システム、および／または、多くの他の医療機器およびシステムの間で、生理学的パラメータ測定値、生理学的パラメータ傾向情報、および、生理学的パラメータアラーム状態を含む患者監視情報の交換を実現しやすくすることができる。翻訳モジュール２４１５は、臨床もしくは病院ネットワーク環境の内部で、医療機器およびシステムの各々が、たとえば、ＨＬ７通信プロトコルのような電子医療通信プロトコルの異なった実装法を使用することがある様々な医療機器およびシステムの間でシームレス通信を可能にすることができる。

ある実施形態では、翻訳モジュール２４１５は、患者監視サブシステムの一部である第１の医療機器と、患者監視システム２００の一部ではない、もしくは、外部にある第２の医療機器との間で通信を実現しやすくすることもできる。従って、翻訳モジュール２４１５は、（ＨＩＳもしくはＣＩＳからの患者情報更新メッセージ、状態問い合わせメッセージなどのような）外部で発生させられた医療メッセージに応答し、（患者モニタもしくは看護監視ステーションからのイベント報告メッセージ、アラーム通知メッセージなどのような）外部報告メッセージを発生させる能力がある可能性がある。

別の実施形態では、第１および第２の医療機器２４０５、２４１０は、通信バス２４２１を介して互いに通信する。通信バス２４２１は、インターネット、病院ＷＬＡＮ、ＬＡＮ、パーソナル・エリア・ネットワークなどを含む前述の通信ネットワーク、システム、および方法のうちいずれか１つ以上を含む可能性がある。たとえば、前述のネットワークのいずれでも前述の第１および第２の医療機器２４０５、２４１０を含む複数の医療機器の間で通信を実現しやすくするために使用される可能性がある。１つのこのような実施形態が図４０Ｂに示される。

図４０Ｂでは、第１の医療機器２４０５は、メッセージを通信バス２４２１に供給する。メッセージは、第２の医療機器２４１０による受信が意図されているが、第１および第２の医療機器２４０５、２４１０は、異なる通信プトロコルフォーマットに従って通信するので、第２の医療機器２４１０は、メッセージを処理することができない。

翻訳モジュール２４１５は、このようなメッセージのため通信バス２４２１を監視する。翻訳モジュールは、メッセージを受信し、第１の医療機器２４０５が第２の医療機器２４１０と通信しようと試みていることを決定する。翻訳モジュール２４１５は、メッセージ翻訳が第１の医療機器２４０５と第２の医療機器２４１０との間の通信を実現しやすくするものであることを決定する。翻訳モジュール２４１５は、その結果、翻訳モジュール２４２０に記憶された適切な翻訳ルールを利用する。翻訳モジュール２４２０は、メモリ、ＥＰＲＯＭ、ＲＡＭ、ＲＯＭなどを含むことができる。

翻訳モジュール２４１５は、本明細書に記載された方法のいずれかに従って第１の医療機器２４０５からのメッセージを翻訳する。一旦翻訳されると、翻訳モジュール２４１５は、翻訳済みのメッセージを通信バス２４２１に配信する。第２の医療機器２４１０は、翻訳済みのメッセージを受信し、適切に応答する。たとえば、第２の医療機器は、機能を行うこと、および／または、第１の医療機器２４０５との通信を試みることがある。翻訳モジュール２４１５は、同様の方法で第２の医療機器２４１０から第１の医療機器２４０５への通信を実現しやすくする。

第１の医療機器２４０５および第２の医療機器２４１０は、たとえば、病院ネットワークもしくはハブ１００、ＰＰＭ １０２、および／またはＭＭＳ ２００４に通信結合されている医療機器もしくはシステムのいずれかである可能性がある。これらの医療機器もしくはシステムは、たとえば、（ベッドサイド患者モニタのような）ポイント・オブ・ケア機器、データ記憶ユニットもしくは患者記録データベース、病院もしくは臨床情報システム、（看護監視ステーションのような）集中監視ステーション、および／または、（ポケットベル、携帯電話機、スマートホン、形態情報端末（ＰＤＡ）、ラップトップ、タブレットＰＣ、パーソナルコンピュータ、ポッドなどのような）臨床医機器を含む可能性がある。

いくつかの実施形態では、第１の医療機器２４０５は、生理学的パラメータ（たとえば、酸素飽和度、脈拍数、血圧など）を追跡するため患者に通信結合している患者モニタであり、第２の医療機器２４１０は、病院情報システム（「ＨＩＳ」）もしくは臨床情報システム（「ＣＩＳ」）である。いくつかの実施形態では、患者モニタは、ＨＩＳもしくはＣＩＳによって保持される患者の電子医療記録と共に包含するため、患者の監視中に発生させられた生理学的パラメータ測定値、生理学的パラメータアラーム、もしくは他の生理学的パラメータ測定情報をＨＩＳもしくはＣＩＳに通信することができる。

いくつかの実施形態では、本明細書に記載されているように、第１の医療機器２４０５は、ＨＩＳもしくはＣＩＳであり、第２の医療機器２４１０は、看護監視ステーションである。しかしながら、翻訳モジュール２４１５は、病院もしくは他の患者介護施設で使用される多種多様の医療機器およびシステムの間で通信を実現しやすくすることができる。たとえば、翻訳モジュール２４１５は、患者生理学的パラメータ監視機器の間で、監視機器と看護監視ステーションとの間などで通信を実現しやすくすることができる。

翻訳モジュール２４１５を使用して、本明細書に記載されているシステム（たとえば、生理学的監視システム２００）のような患者監視サブシステムは、ＨＩＳがＨＬ７プロトコルの異なる実施、もしくは、いくつかの他の電子医療通信プロトコルを使用するとしても、データをＨＩＳにプッシュすること、もしくは、ＨＩＳからデータをプルすることができる。

ある実施形態では、患者監視サブシステムは、所定の間隔でデータをプッシュ／プルように構成される可能性がある。たとえば、患者モニタもしくは臨床監視ステーションは、周期的な間隔でＨＩＳから自動的に患者データをダウンロードすることができるので、患者データは、患者が患者モニタに接続されているときに既に利用可能である。ＨＩＳから送信された患者データは、患者の登録時に受信された入院／退院／転院（「ＡＤＴ」）情報を含むことができる。ＡＤＴメッセージは、たとえば、患者が入院、退院、転院、もしくは登録されたこと、患者情報が更新もしくは統合されたこと、または転院もしくは退院が取り消されたことを補助システムに知らせるために、病院情報システムによって起動される可能性がある。

他の実施形態では、患者監視サブシステムは、ＨＩＳが問い合わせによって懇願されているときに限り、ＨＩＳへデータをプッシュする／ＨＩＳからデータをプルするように構成される可能性がある。たとえば、臨床医は、ＨＩＳ上にある患者の電子医療記録に記憶された情報を要求することがある。

さらに他の実施形態では、患者監視サブシステムは、予期しないイベントに応答してＨＩＳへデータをプッシュする／ＨＩＳからデータをプルするように構成される可能性がある。たとえば、監視対象である患者の生理学的パラメータは、アラーム状態に入る可能性があり、このことは、患者の電子医療記録に記憶するためＨＩＳへ自動的に送信される可能性がある。さらに他の実施形態では、メッセージをＨＩＳへおよびＨＩＳから通信すべきときを決定する上記方法もしくは代替的な方法のいずれかの組み合わせが利用される可能性がある。

翻訳モジュール２４１５に関与するメッセージの通信のためのシステムアーキテクチャ例およびトリガー例が記載されている。今度は、翻訳モジュールの動作を参照すると、図２５Ａ〜２５Ｄは、翻訳プロセスの異なったフェーズもしくはステップでの医療メッセージ例を示す。翻訳プロセスは、図２６、２７Ａおよび２７Ｂに関連してより詳細に後述される。

図４１Ａは、ＨＩＳから翻訳モジュール２４１５によって受信されたＡＤＴ入力メッセージ例２５０５を示す。ＡＤＴ入力メッセージ２５０５は、ＨＬ７通信プロトコルに従って実装され、病院への患者の入院に関連している情報を格納している。ＡＤＴメッセージ２５０５は、メッセージ・ヘッダ・セグメント２５０６、イベント・セグメント、患者識別セグメント、患者診察セグメント、役割セグメント、診断セグメント、および多数のカスタムセグメントをはじめとして多数のセグメントを含む。

いくつかの実施形態では、メッセージ・ヘッダ（「ＭＳＨ」）セグメント２５０６は、メッセージがどのようにして送信されているか、フィールド区切り文字およびエンコーディング文字、メッセージ型、発信側および受信側などを定義する。ＭＳＨ文字列の後の最初の記号もしくは文字は、フィールド区切りもしくはセパレータ（本メッセージでは、「キャレット」記号）を定義することができる。次の４個の記号もしくは文字は、エンコーディング文字を定義することができる。１番目の記号は、コンポーネント区切り（「〜」）を定義し、２番目の記号は、繰り返し区切り（「｜」）を定義し、３番目の記号は、エスケープ区切り（「＼」）を定義し、４番目の記号は、サブコンポーネント区切り（「＆」）を定義する。これらの区切りの全ては、ＨＬ７実装法の間で変わる可能性がある。

いくつかの実施形態では、ヘッダ・セグメント例２５０６は、送信アプリケーション（「ＶＡＦＣ ＰＩＭＳ」）、受信アプリケーション（「ＮＰＴＦ−５０８」）、メッセージの日付／時刻（「２００９１１２０１０４６０９−０６００」）、メッセージ型（「ＡＤＴ−Ａ０１」）、メッセージ制御ＩＤ（「５８１０３」）、処理ＩＤ（「Ｐ」）、および国コード（「ＵＳＡ」）をさらに含む。連続的なキャレット記号によって表現されているように、ヘッダ・セグメントは、多数の空フィールドも格納している。

図４１Ｂは、識別されたフィールド区切り（キャレット記号）に基づいてフィールドもしくは要素に構文解析された後のメッセージ・ヘッダ・セグメント２５０６を示す。ある実施形態では、構文解析された入力メッセージは、拡張スタイルシート言語変換（ＸＳＬＴ）ルールに従って変換されるように構成されているＸＭＬメッセージを備える。

ある実施形態では、構文解析された入力メッセージは、エンコードされる可能性がある。図４１Ｃは、（たとえば、ユニコード変換フォーマット−８（「ＵＴＦ−８」）エンコーディングスキームを使用して）エンコードされた後の入力メッセージの構文解析されたメッセージ・ヘッダ・セグメントを示す。

エンコードされたメッセージ・ヘッダ・セグメントは、メッセージの中で使用される可能性がある様々なデータ型の一部を表している。たとえば、３番目の構文解析されたフィールドの送信アプリケーション（「ＶＡＦＣ ＰＩＭＳ」）および５番目の構文解析されたフィールドの受信アプリケーション（「ＮＰＴＦ−５０８」）は、階層指定子（「ＨＤ」）名前データ型を使用して表現される。日付／時刻フィールド（７番目の構文解析されたフィールド）は、タイムスタンプ（「ＴＳ」）データ型を使用して表現される。処理ＩＤフィールド（１１番目の構文解析されたフィールド）は、処理タイプ（「ＰＴ」）データ型を使用して表現される。データ型識別子を含まないフィールドは、文字列（「ＳＴ」）データ型を使用して表現される。他の考え得るデータ型は、たとえば、コード化要素、構造化数値、タイミング量、テキストデータ、日付、エントリ識別子、コード化値、数値、およびシーケンス識別を含む。セグメントの様々なフィールドもしくは属性のため使用されたデータ型は、フォーマッティング実装法の間で変わる可能性がある。

図４１Ｄは、図４１Ａの入力メッセージ例２５０５に基づく翻訳モジュール２４１５からの出力メッセージ例２５１０を示す。出力メッセージ２５１０は、メッセージ肯定応答セグメント２５１２を含む。

次に翻訳モジュールの動作を考えると、翻訳モジュール２４１５は、たとえば、翻訳ルール２４２０の集合の適用に基づいて入力メッセージを反映している出力メッセージを作成、発生、もしくは生成することができる。いくつかの実施形態では、翻訳モジュール２４１５は、たとえば、出力メッセージを形成するために、翻訳ルール２４２０の集合との比較、もしくは、翻訳ルール２４２０の集合の適用に基づいて入力メッセージを翻訳、変換、転換、再フォーマット、構成、変更、再構成、修正、適応、変更、もしくは調節することができる。いくつかの実施形態では、翻訳モジュール２４１５は、たとえば、翻訳ルール２４２０の集合との比較、および、翻訳ルール２４２０の集合の適用に基づいて、入力メッセージの内容を持ち続けるが、新しいフォーマッティング実装法を有する出力メッセージで置換もしくは代替することができる。

図４２は、入力メッセージ、および、翻訳モジュール２４１５に関連付けられた翻訳ルール２４２０の集合との比較に基づいて、出力メッセージを発生させる翻訳プロセス２６００を示す。翻訳プロセス２６００は、翻訳モジュール２４１５が第１の医療機器から入力メッセージを受信するブロック２６０２から始まる。

ブロック２６０４において、翻訳モジュール２４１５は、入力メッセージのフォーマッティング実装法と、出力メッセージのため使用されるべきフォーマッティング実装法とを決定する。ある実施形態では、入力メッセージは、フォーマッティング実装法を表す１つ以上の識別子を含む可能性がある。いくつかの実施形態では、フォーマッティング実装法の決定は、たとえば、使用された区切り文字もしくはエンコーディング文字、フィールド順序、セグメント、フィールド、もしくはコンポーネントの繰返し性、フィールドのデータ型、または他の実装差異を識別することによってメッセージ自体を分析することにより行われる可能性がある。ある実施形態では、翻訳モジュール２４１５は、フォーマッティング実装法の決定に役立てるために（図４１Ｂに表されているように）メッセージの内容からフォーマッティングを分離する、もしくは、構文解析することができる。いくつかの実施形態では、翻訳モジュール２４１５は、翻訳モジュール２４１５がインターフェースを取るように構成されている各機器によって使用される実装法を記憶するデータベースを参照することにより入力メッセージのフォーマットティング実装法を決定する。

ある実施形態では、出力メッセージによって使用されるフォーマッティング実装法の決定は、入力メッセージからも決定される可能性がある。たとえば、入力メッセージは、意図された受信側アプリケーション、施設、システム、機器、および／または宛先を識別するフィールドを含む可能性がある。入力メッセージは、送信されているメッセージの型（たとえば、ＡＤＴメッセージ）を識別するフィールドを代わりに含む可能性があり、翻訳モジュール２４１５は、送信されているメッセージの型、および／または、送信側アプリケーション、機器、もしくはシステムから適切な受信側を決定する可能性がある。翻訳モジュール２４１５は、その後、入力メッセージの意図された受信側によって要求されたフォーマッティング実装法を決定することができる。

決定ブロック２６０５では、翻訳モジュール２４１５は、ルール集合が入力メッセージの識別されたフォーマッティング実装法から出力メッセージのため使用されるべき識別されたフォーマッティング実装法への翻訳のため構成されているか否かを決定する。ルール集合は、翻訳モジュールソフトウェアの実装前に手動で構成されていることがあり、または、入力メッセージの受信前に自動的に構成されていることがある。ルール集合が既に構成されている場合、翻訳プロセス２６００は、ブロック２６０６に進む。ルール集合が構成されていない場合、ルール集合は、ブロック２６０７で構成される。ルール集合の構成が図４４および４５Ａ〜２４５９Ｄに関連して後述されるように行われる可能性がある。
翻訳プロセス２６００は、その後、ブロック２６０８に進む。

ブロック２６０６で、翻訳モジュール２４１５は、入力メッセージの決定されたフォーマッティング実装法と出力メッセージのフォーマッティング実装法との間の翻訳を左右する翻訳ルール２４２０の集合から予め構成されたルールを識別する。いくつかの実施形態では、予め構成されたルールの識別は、手動で行われる可能性がある。

ブロック２６０８で、翻訳モジュール２４１５は、翻訳ルール２４２０の構成されたルール集合（群）に基づいて出力メッセージを発生させる。ある実施形態では、出力メッセージは、入力メッセージの全部もしくは少なくとも一部を持ち続けるが、入力メッセージの意図された受信側によって期待され、かつ、サポートされたフォーマットを有する。

翻訳ルール２４２０は、たとえば、一方向ルールおよび／または双方向ルールを含む可能性がある。一方向ルールは、たとえば、第１の医療機器（たとえば、２４０５）から第２の医療機器（たとえば、２４１０）へのメッセージの場合に適用されることがあるが、第２の医療機器から第１の医療機器へのメッセージの場合に適用されないルールである可能性がある。たとえば、一方向ルールは、たとえば、ＨＬ７通信プロトコルの２つの異なったフォーマッティング実装法のためのフィールドの間で使用される区切りの相違に対処することもあり得る。翻訳モジュール２４１５は、フィールド区切りが入力メッセージの意図された受信側によってサポートされているか否かを決定するためにフィールド区切りルールを適用することができる。入力メッセージのフィールド区切りが意図された受信側によってサポートされていない場合、フィールド区切りルールは、入力メッセージのフィールド区切りを意図された受信側によってサポートされるフィールド区切りで置換することができる。

たとえば、入力医療機器からの入力メッセージは、フィールド区切りもしくはセパレータとして「キャレット」記号（「＾」）を使用するフォーマッティング実装法を含む可能性がある。しかしながら、意図された受信側医療機器によって認識されたフォーマッティング実装法は、フィールド区切りとして「パイプ」記号（「｜」）を使用することがある。翻訳モジュール２４１５は、翻訳ルール２４２０の集合から意図された受信側医療機器によって認識されたフォーマッティング実装法で使用されるフィールド区切り記号を識別し、入力メッセージで使用されたキャレットフィールド区切り記号の代わりにパイプフィールド区切り記号を使用する入力メッセージに基づいて出力メッセージを発生させることができる。キャレット記号の代わりにパイプ記号を用いるルールは、この場合、パイプ記号をフィールド区切りとして認識する受信側機器に送信されるメッセージだけに適用できるであろう。このルールは、キャレット記号をフィールド区切りとして認識することが知られている受信側機器を対象としているメッセージの場合にキャレット記号がパイプ記号によって代用されるべきであることを示す補完ルールが付随することがあり得る。

別の一方向ルールは、異なったフォーマッティング実装法の間で、あるフィールドの有無に対処することができる。たとえば、入力医療機器からの入力メッセージは、意図された受信側医療機器によって認識されないものであるフィールドを含むことがあり得る。翻訳モジュール２４１５は、認識されていない、もしくは、サポートされていないフィールドを含んでいない出力メッセージを発生させることができる。入力メッセージが意図された受信側医療機器によって期待されるフィールドを含んでいない状況では、翻訳ルール２４２０の集合は、ヌルエントリ若しくは空「」文字列を意図された受信側医療機器によって期待されるフィールドに挿入するため、および／または、期待されるフィールドの欠如を受信側機器に警告するためのルールを含む可能性がある。送信側機器は、受信側機器がメッセージのある部分をサポートしていないことを翻訳モジュール２４１５によってさらに通知されることがある。

他の一方向ルールは、たとえば、一方のデータ型の別のデータ型（たとえば、文字列（「ＳＴ」）からテキストデータ（「ＴＸ」）、または、構造化数値（「ＳＮ」）から数値（「ＮＭ」））への転換と、メッセージの様々な部分の長さの増減とを実現しやすくすることができる。一方向ルールは、メッセージの部分の繰返し性の差異に対処するためにも使用される可能性がある。たとえば、翻訳モジュール２４１５は、このような繰り返されるインスタンスがもしあるとすれば、受信側機器によっていくつサポートされるかを決定するために、フィールド繰返し性ルールをメッセージのセグメント、フィールド、コンポーネント、もしくはサブコンポーネントの繰り返されるインスタンスに適用し、必要に応じて、繰り返されるインスタンスを削除もしくは追加することができる。たとえば、患者識別セグメントの電話番号フィールドは、自宅、職場、および携帯電話番号のエントリを許すために繰り返し可能なフィールドである。

双方向ルールも使用することができる。このようなルールは、どちらの機器が送信側であり、どちらが受信側であるかとは無関係に、第１および第２の医療機器（たとえば、２４０５、２４１０）の間のメッセージに同様に適用できる。双方向ルールは、たとえば、シーケンスの変化に対処するためにも使用することができる。ある実施形態では、入力医療機器からの入力メッセージは、名コンポーネントが姓コンポーネントより前に現れる患者名前フィールドもしくはフィールド群を含む可能性がある。しかしながら、意図された受信側医療機器は、姓コンポーネントが名コンポーネントより前に現れる実装法を期待していることがある。従って、翻訳ルール２４２０の集合は、２台の医療機器もしくは２つのフォーマッティング実装法の間で通信するとき、名コンポーネントおよび姓コンポーネントの順序を入れ替えるための双方向ルールを含む可能性がある。概して、フィールド順序ルールは、フィールド、コンポーネント、もしくはサブコンポーネントが意図された受信側のため正しい順序であるか否かを決定し、必要に応じてこれらを再配置するために適用される可能性がある。他の双方向ルールは、たとえば、フォーマッティング実装法の間の他の連続的な差異、または、他のタイプの差異に対処するために組み入れられる可能性がある。

翻訳ルール２４２０は、合成ルールをさらに含む可能性がある。たとえば、合成ルールは、ルールが別のルールの結果に依存する可能性があるｉｆ−ｔｈｅｎ形式のルールのシーケンスを含む可能性がある。いくつかの翻訳ルール２４２０は、計算および論理（たとえば、ブール論理もしくはファジィ論理）などを採用することがある。

前述のとおり、病院ベースの通信ネットワークを介して通信されたメッセージは、ＨＬ７プロトコルを採用する可能性がある。図４３Ａおよび４３Ｂは、ＨＬ７メッセージが病院ベースの通信ネットワークもしくは臨床ネットワークを介してＨＩＳと医療機器との間で通信される翻訳プロセス２７００Ａ、２７００Ｂを示す。翻訳プロセス２７００Ａ、２７００Ｂは、第１および第２のＨＬ７フォーマットの間の「翻訳」を左右するルールが既に構成されていると仮定して説明される。

図４３Ａは、翻訳モジュール２４１５が、第１のＨＬ７フォーマットを有するＨＩＳから、患者モニタもしくは臨床医監視ステーションのような第２のＨＬ７フォーマットを有する意図された受信側医療機器への、図４１ＡのＡＤＴメッセージのようなＨＬ７メッセージの通信を実現しやすくする翻訳プロセス２７００Ａを示す。

翻訳プロセス２７００Ａは、翻訳モジュール２４１５がＨＩＳから第１のＨＬ７フォーマットを有する入力メッセージを受信するブロック２７０１で始まる。ある実施形態では、入力メッセージは、たとえば、電子医療記録データベースからの患者の入院に関する情報、および／または、患者識別および患者病歴情報を含む。

ブロック２７０３で、翻訳モジュール２４１５は、入力メッセージのフォーマッティング実装法および出力メッセージのため使用されるべきフォーマッティング実装法を決定する。これらの決定は、図４２のブロック２６０４に関連して前述された決定と同様の方法で行われる可能性がある。

ブロック２７０５で、翻訳モジュール２４１５は、入力メッセージの決定されたＨＬ７フォーマットと出力メッセージのＨＬ７フォーマットとの間の翻訳を作用するルールを識別し、識別されたルールに基づいて第２のＨＬ７フォーマットを有する出力メッセージを発生させる。ある実施形態では、出力メッセージは、ＨＳによって送信された入力メッセージの内容を持ち続けるが、入力メッセージの意図された受信側によって期待され、サポートされるフォーマットを有する。

ブロック２７０７で、翻訳モジュール２４１５は、病院ベースの通信ネットワークを介して出力メッセージを意図された受信側へ出力することができる。ある実施形態では、意図された受信側は、受信成功を承認する、もしくは、エラーが発生したことを報告する肯定応答メッセージを病院情報システムに返信することができる。

図４３Ｂは、翻訳モジュール２４１５が、患者モニタのような、第１のＨＬ７フォーマットを有する医療機器から、第２のＨＬ７フォーマットを有するＨＩＳへの、ＨＬ７メッセージの通信を実現しやすくする翻訳プロセス２７００Ｂを示す。たとえば、患者モニタは、患者の電子医療記録に記憶するために、患者アラームデータのような報告イベントデータｍをＨＩＳに送信することができる。

翻訳プロセス２７００Ｂは、翻訳モジュール２４１５が医療機器から第１のＨＬ７フォーマットを有する入力メッセージを受信するブロック２７０２から始まる。ある実施形態では、入力メッセージは、ＨＩＳに関連付けられた電子医療記録データベースへの記憶のため、監視対象である患者の１つ以上の生理学的パラメータに関する患者監視データもしくはアラームデータを含む。

ブロック２７０４で、翻訳モジュール２４１５は、入力メッセージのフォーマッティング実装法および出力メッセージのため使用されるべきフォーマッティング実装法を決定する。これらの決定は、図４２のブロック２６０４に関連して前述された決定と同様の方法で行われる可能性がある。

ブロック２７０６で、翻訳モジュール２４１５は、入力メッセージの決定されたＨＬ７フォーマットと出力メッセージのＨＬ７フォーマットとの間の翻訳を左右するルールを識別し、識別されたルールに基づいて第２のＨＬ７フォーマットを有する出力メッセージを発生させる。ある実施形態では、出力メッセージは、医療機器によって送信された入力メッセージの内容を持ち続けるが、ＨＩＳによって期待され、サポートされたフォーマットを有する。

ブロック２７０８で、翻訳モジュール２４１５は、病院ベースの通信ネットワークを介して出力メッセージを病院情報システムへ出力することができる。ある実施形態では、ＨＩＳは、受信成功を承認する、もしくは、エラーが発生したことを報告する肯定応答メッセージを医療機器に返信することができる。

図４２、４３Ａおよび４３Ｂは、翻訳モジュール２４１５の動作を記述した。図４４および４５Ａ〜４５Ｄは、翻訳ルール２４２０の構成の記述を例示するために使用される。

翻訳ルール２４２０は、１つ以上のスタイルシート、階層関係データ構造体、テーブル、リスト、他のデータ構造体、これらの組み合わせ、および／または、同様のものとして実装される可能性がある。ある実施形態では、翻訳ルール２４２０は、翻訳モジュール２４１５の内部のローカルメモリに記憶される可能性がある。他の実施形態では、翻訳ルール２４２０は、翻訳モジュール２４１５に通信結合されている外部メモリもしくはデータ記憶機器に記憶される可能性がある。

翻訳モジュール２４１５は、単一のルール集合もしくは多数のルール集合を含む可能性がある。たとえば、翻訳モジュール２４１５は、医療機器／システム毎に、および／または、ネットワークに結合された、もしくは、ネットワークに結合される能力がある医療機器／システムの可能な通信ペア毎に、各別個のルール集合を含む可能性がある。いくつかの実施形態では、翻訳モジュール２４１５は、たとえば、ＨＬ７プロトコルのような医療通信プロトコルの下で許容されたフォーマッティング実装法の可能なペア毎に、別個のルール集合を含む可能性がある。

ある実施形態では、翻訳ルール２４２０は、たとえば、図４４に示されたメッセージング実装ソフトウェアツール２８００を使用して手動で入力される可能性がある。たとえば、特定の病院ネットワークのためのソフトウェア開発者は、病院ネットワークに結合されている、もしくは、結合される可能性がある機器および／またはシステムによって使用されるプロトコル・メッセージ・フォーマットを決定し、その後、機器および／またはシステムによってサポートもしくは認識された様々なプロトコル・メッセージ・フォーマットの間の「翻訳」を実現しやすくするためにルールを手動で入力することができる。

図４４は、翻訳モジュール２４１５によって使用されるべき翻訳ルール２４２０を手動で構成するメッセージング実装ソフトウェアツール２８００からのスクリーンショット例を示す。メッセージング実装ソフトウェアツール２８００からのスクリーンショットは、ＨＬ７のような電子医療通信プロトコルのフォーマッティング実装法の間で異なることがある様々なパラメータを示す。スクリーンショットは、ユーザが、異なるＨＬ７実装法の間で転換を行う翻訳ルールを定義する、もしくは、定義するために使用される情報を入力することができるエリアも含む。いくつかの実施形態では、メッセージング実装ソフトウェアツール２８００は、たとえば、様々な医療機器の既知の通信プロトコル実装法に基づいて、種々の予め構成されたルール集合を記憶する。このような実施形態では、ユーザは、機器製造業者、型番などの識別情報を入力することによって、このような機器に関わる通信で使用されるべき１つ以上の翻訳ルール２４２０を構成することがある。この識別情報に基づいて、メッセージング実装ツール２８００は、この機器との通信のため予め構成された翻訳ルールの集合を識別することができる。

他の実施形態では、翻訳ルール２４２０は、自動的に発生させられる可能性がある。たとえば、ルールの新しい集合もしくは多数の集合の自動発生は、新たに認識されたネットワーク上の「通信」医療機器もしくはシステムの検出によって始動される可能性がある。ある実施形態では、ルールの新しい集合もしくは多数の集合の自動発生は、第１のメッセージがネットワークに結合された新しい「通信」医療機器もしくはシステムから受信された、もしくは、これらの医療機器もしくはシステムに送信された時点に起こる可能性がある。さらに他の実施形態では、ルール集合の自動発生は、予め存在するルールの集合を更新すること、もしくは、動的に修正することを含む。

翻訳ルールセットの自動発生は、種々の方法で実行される可能性がある。たとえば、いくつかの実施形態では、翻訳モジュール２４１５は、たとえば、ネットワーク上で認識された新しい機器のメーカーおよびモデルに基づいて、予め構成された翻訳ルール２４２０の集合の使用を自動的に起動することができる。ある実施形態では、翻訳モジュール２４１５は、図４５Ａの自動ルール構成プロセス２９００Ａによって示されるように、新しい機器もしくはシステムから１つ以上のメッセージを要求し、その後、実装されているフォーマッティングの型を決定するためにメッセージを分析することができる。自動ルール構成プロセス２９００Ａは、翻訳モジュール２４１５がネットワーク上で検出された医療機器もしくはシステムから１つ以上のメッセージを受信するブロック２９０１から始まる。メッセージは、意図された受信側医療機器もしくはシステムへ送信し次第、あるいは、翻訳モジュール２４１５、または、ネットワークに結合された別の医療機器もしくはシステ
ムによって送信された問い合わせに応答して、受信される可能性がある。

ブロック２９０３で、翻訳モジュール２４１５は、たとえば、メッセージを分析することによって、もしくは、どんな通信プロトコル／フォーマットがネットワーク上の各医療機器もしくはシステムによって実装されているかを示すデータベースを参考にすることによって、１つ以上の受信されたメッセージのプロトコルを決定する。ある実施形態では、翻訳モジュール２４１５は、ＨＬ７のような単一の共通プロトコルを使用して実装された医療メッセージに対処するように構成されている。その結果、受信されたメッセージがサポートされていない、もしくは、認識されていないプロトコルを使用して実装されているという決定が行われた場合、翻訳モジュールは、検出された医療機器もしくはシステムから受信されたメッセージを無視する、警報もしくは忠告を出力する、または、メッセージが翻訳されることなく送信できるようにする可能性がある。

ブロック２９０５で、翻訳モジュール２４１５は、受信されたメッセージ（群）のフォーマッティング実装法を決定する。ある実施形態では、受信されたメッセージは、フォーマッティング実装法を表す１つ以上の識別子を含む可能性がある。他の実施形態では、フォーマッティング実装法の決定は、たとえば、フィールド順序、使用された区切り文字もしくはエンコーディング文字、または、他の実装差異をチェックすることによってメッセージ自体を分析することにより行われる可能性がある。ある実施形態では、翻訳モジュール２４１５は、フォーマッティング実装法の決定に役立つようにメッセージの内容からフォーマッティングを分離もしくは構文解析することができる。

ブロック２９０７で、翻訳モジュール２４１５は、検出された医療機器もしくはシステムから受信された、および／または、検出された医療機器もしくはシステムに送信されたメッセージに対処するために１つ以上のルールもしくはルール集合を構成する。ある実施形態では、ルールの構成は、新しいルールの作成もしくは発生を伴う。他の実施形態では、ルールの構成は、既存のルールの変更もしくは更新を伴う。構成されたルールもしくはルール集合は、翻訳ルール２４２０に取り込まれる。新しい機器もしくはシステムによって使用されたフォーマッティング実装法のためのルールの集合が既に存在している場合、新しい翻訳ルールの構成は、必要とはされないことがある。その代わり、既存の翻訳ルールは、新しい機器もしくはシステムに関与する通信で用いられるこの新しい機器もしくはシステムに関連付けられる可能性がある。他の実施形態では、翻訳モジュール２４１５は、新しい機器もしくはシステムのため具体的に適合させられた新しいルールの集合を作成することができる、または、識別されたわずかなフォーマッティング差異に基づいて既存のルールの集合を修正することができる。

他の実施形態では、翻訳モジュール２４１５は、機器もしくはシステムによって使用される通信プロトコルおよび実装法を識別するのに役立つことがあるテストメッセージ（群）を発生させることができる。たとえば、翻訳モジュールは、新たに検出された機器もしくはシステムに特定の措置を講じさせる（たとえば、情報を記憶させる）ためにテストメッセージを発生させ、その後、テストメッセージが理解されたか否か、もしくは、どのようにしてテストメッセージが理解されたかを決定するために、新たに検出された機器によって講じられた措置に関する問い合わせ情報を発生させる。これは、図４５Ｂの自動ルール構成プロセス２９００Ｂによって示されている。

自動ルール構成プロセス２９００Ｂは、翻訳モジュール２４１５が１つ以上のテストメッセージ、または、初期化メッセージをネットワーク上で検出された遠隔機器もしくはシステムに送信するブロック２９０２から始まる。テストメッセージは、たとえば、遠隔機器もしくはシステムに特定の措置を講じる（たとえば、患者情報を記憶する）ことを命令するように構成される可能性がある。ある実施形態では、テストメッセージは、遠隔機器もしくはシステムによって認識された、もしくは、サポートされたフォーマッティングの型を表す応答を発生させるように構成される可能性がある。他の実施形態では、テストメッセージは、特定のフォーマッティング実装法をサポートする機器もしくはシステムだけがテストメッセージを理解し、テストメッセージに従って作用するように構成される可能性がある。

ブロック２９０４で、翻訳モジュール２４１５は、テストメッセージが理解されたか否かを決定するために、遠隔機器もしくはシステムに送信されたテストメッセージに基づいて講じられた措置に関する情報を受信することを遠隔機器もしくはシステムに問い合わせる。たとえば、テストメッセージが遠隔機器もしくはシステムに患者情報を特定の場所に記憶することを命令する場合、翻訳モジュール２４１５は、テストメッセージが理解されたか否かを決定するためにこの場所からの情報を問い合わせることができる。テストメッセージが理解されていない場合、翻訳モジュール２４１５は、たとえば、テストメッセージが理解されているという決定が行われるまで、既知のフォーマッティング実装法についてのテストメッセージを送信し続ける。

ブロック２９０６で、翻訳モジュール２４１５は、受信された情報に基づいてプロトコルおよびフォーマッティング実装法を決定する。一例として、ある実施形態では、テストメッセージは、患者名前情報を記憶する命令を含むことができる。テストメッセージは、名コンポーネントと後に続く姓コンポーネントとを有する患者名前フィールドを含むことができる。翻訳モジュール２４１５は、その後、患者姓を返信することを遠隔機器もしくはシステムに問い合わせることができる。患者姓もしくは患者名が返信されたか否かに依存して、この問い合わせは、遠隔機器若しくはシステムによって使用されているフォーマッティング実装法におけるフィールドの順序に関する情報を決定するのに役立つ可能性がある。別の例として、テストメッセージは、検出された機器もしくはシステムに繰り返されるコンポーネントのインスタンスを記憶することを命令することができる。翻訳モジュール２４１５は、その後、もしあるとしたら、どれが記憶されたかを調べるために、繰り返されたインスタンスを返送することを機器もしくはシステムに問い合わせることができる。この繰返し性情報は、あるフィールドがシステムのための遠隔機器によって使用されているフォーマッティング実装法において繰り返されることが許可されているか否かを決定し、許可されている場合、許されている繰り返しインスタンスの回数を決定するのにも役立つ可能性がある。

ブロック２９０８で、翻訳モジュール２４１５は、検出された医療機器もしくはシステムから受信された、および／または、検出された医療機器もしくはシステムに送信されたメッセージに対処するために１つ以上のルールを構成する。たとえば、ルールは、本明細書に記載されているように、第１の医療機器によって使用されたメッセージフォーマットから、第２の医療機器によって使用されたメッセージフォーマットへ転換することができる。ある実施形態では、ルールの構成は、新しいルールの作成もしくは発生を伴う。他の実施形態では、ルールの構成は、既存のルールの変更もしくは更新を伴う。新しい機器もしくはシステムによって使用されるフォーマッティング実装に対するルールの集合が既に存在する場合、新しい翻訳ルールの構成は、必要ではないことがある。その代わり、既存の翻訳ルールは、新しい機器もしくはシステムに関与する通信で用いられる新しい機器もしくはシステムに関連付けられる可能性がある。

図２９Ｃおよび２９Ｄは、ＨＬ７プロトコルを利用するメッセージに対して翻訳モジュール２４１５によって行われる自動ルール構成プロセスを示す。ＨＬ７プロトコルは、たとえば、管理プロセス、物流プロセス、財務プロセス、および臨床プロセスをサポートするため電子メッセージを通信するために使用され得る。たとえば、ＨＬ７メッセージは、様々な健康管理システムの間で、ＡＤＴメッセージのような、患者人口統計学的および診察情報を交換するために使用される患者管理メッセージを含む可能性がある。

図４５Ｃに示された自動ルール構成プロセス２９００Ｃは、図４５Ａに示されたプロセス２９００Ａに類似している。ブロック２９１１で、翻訳モジュール２４１５は、ＨＬ７医療機器から１つ以上のメッセージを受信する。ブロック２９１５で、翻訳モジュール２４１５は、受信された１つ以上のメッセージから、ＨＬ７医療機器のフォーマッティング実装法を決定する。前述のとおり、フォーマッティング実装法の決定は、たとえば、フィールド順序もしくはシーケンス、フィールド区切り文字、繰返し性、カーディナリティ、および他のＨＬ７実装差異をチェックすることによって行われる可能性がある。

ブロック２９１７で、翻訳モジュール２４１５は、ＨＬ７医療機器から受信された、および／または、ＨＬ７医療機器に送信されたメッセージに対処するために１つ以上のルールを構成する。ある実施形態では、ルールの構成は、検出されたフォーマッティング実装法のための新しいルールの作成もしくは発生を伴う。他の実施形態では、ルールの構成は、既存のルールの動的な変更もしくは更新を伴う。新しいＨＬ７医療機器によって使用されるフォーマッティング実装法に対するルールの集合が既に存在する場合、新しい翻訳ルールの構成は、必要とはされないことがある。その代わり、既存の翻訳ルールは、新しいＨＬ７医療機器に関与する通信で用いるためこの新しいＨＬ７医療機器に関連付けられる可能性がある。

図４５Ｄに示された自動ルール構成プロセス２９００Ｄは、図４５Ｂに示されたプロセス２９００Ｂに類似している。ブロック２９１２で、翻訳モジュール２４１５は、１つ以上のテスト、ダミー、もしくは初期化メッセージをＨＬ７医療機器に送信する。他の実施形態では、翻訳モジュール２４１５は、１つ以上のテストメッセージを別のＨＬ７医療機器から新しいＨＬ７医療機器に送信させることができる。前述のとおり、テストメッセージは、ＨＬ７機器がテストメッセージを理解するか否かを決定するように構成された既知のＨＬ７フォーマットを有するメッセージを含む可能性がある。テストメッセージは、たとえば、テストＡＤＴメッセージを含む可能性がある。

ブロック２９１４で、翻訳モジュール２４１５は、テストメッセージに応答して講じられた措置に関する情報もしくは記憶された情報を受信することをＨＬ７医療機器に問い合わせる。ブロック２９１６で、翻訳モジュール２４１５は、受信された情報に基づいてＨＬ７機器のフォーマッティング実装法を決定する。ある実施形態では、翻訳モジュール２４１５は、テストメッセージもしくはメッセージ群が適切に理解されたか否かを決定するために受信された情報を分析することができる。テストメッセージがどれも適切に理解されていない場合、翻訳モジュール２４１５は、他の既知のＨＬ７フォーマットを有する付加的なテストメッセージを送信し、ブロック２９１４および２９１６を繰り返すことができる。

ブロック２９１８で、翻訳モジュール２４１５は、検出されたＨＬ７医療機器から受信された、および／または、検出されたＨＬ７医療機器に送信されたメッセージに対処するために１つ以上の翻訳ルールを構成する。ある実施形態では、翻訳ルールの構成は、新しい翻訳ルールの作成もしくは発生を伴う。他の実施形態では、ルールの構成は、既存のルールの変更もしくは更新を伴う。新しいＨＬ７医療機器によって使用されるフォーマッティング実装法に対する翻訳ルールの集合が既に存在する場合、新しい翻訳ルールの構成は、必要とはされないことがある。その代わり、既存の翻訳ルールは、新しいＨＬ７医療機器に関与する通信で用いるためにこの新しいＨＬ７医療機器に関連付けられる可能性がある。

前述の自動ルール構成プロセスは、翻訳モジュール２４１５によるネットワーク機器もしくはシステムの検出によって始動させられる可能性がある。図４５Ａ〜４５Ｄにおいて参照された医療機器は、図１もしくは２４に示された機器もしくはシステムのいずれでも含むことができる。

いくつかの実施形態では、翻訳ルールの自動生成は、翻訳モジュール２４１５を含むメッセージング・サブシステム・ソフトウェアの実装後およびコンパイル後に行うことができると有利である。ある実施形態では、翻訳ルール２４２０の自動発生もしくは動的修正は、翻訳モジュールソフトウェアを再コンパイルもしくは再構築する必要なしに行われる可能性がある。この特徴は、健康管理環境において使用されるソフトウェアの検証に関する米国食品医薬品局（「ＦＤＡ」）の要件に効率的に適合する観点から有利である可能性がある。

たとえば、医療機器製造業者が、病院に実装されるべき特定の医療機器もしくはシステム（たとえば、本明細書に記載されているように、患者監視システム）、または、他の患者介護施設と、病院で既に実装されている他の機器もしくはシステム（たとえば、ＨＩＳもしくはＣＩＳ）との間の通信を実現しやすくするために翻訳モジュール２４１５を使用することを計画している状況を考える。実装されるべき新しい医療機器の動作のため必要とされるソフトウェアはどれでも、たとえば、病院における他の既存の機器もしくはシステムのＨＬ７実装法が未だに分かっていないという事実にもかかわらず、病院での実装前にＦＤＡ準拠について少なくとも部分的に検証されていることがある。たとえば、他の病院機器からメッセージを受信することに依存した、新しい医療機器のためのソフトウェアの態様はどれでも、期待されるメッセージフォーマットが受信されるとき、完全かつ正確に動作することができるものとして実装前に検証される可能性がある。その後、医療機器が病院で実装されると、ソフトウェアの検証は、翻訳モジュール２４１５が期待されたフォーマットのメッセージを新たに実装された機器に供給する能力をもつことを明らかにすることによって完了する可能性がある。このようにして、ＦＤＡ検証作業は、より多くの部分が、現場より制御された形で簡単に実行され得る実装前時間枠に分配される可能性がある。

その上、翻訳モジュール２４１５は、たとえば、医療機器もしくはシステムが、異なる病院に実装され、これらの病院の既存の機器が、たとえば、ＨＬ７プロトコルの異なる実装法を使用することが見込まれるとき、ストリームラインＦＤＡ検証にさらに役立つ可能性がある。通常では、この種の状況は、新しい医療機器のためのソフトウェアの機能性全体が各病院で完全に検証されるという要件を課すことがあり得る。しかしながら、翻訳モジュール２４１５が新しい医療機器と病院の既存の機器との間でインターフェースを取るために使用される場合、ソフトウェア機能性の多くは、今記載されたように、実装前の単一の時点で検証されることがあり得るかもしれない。その後、各病院で実装されると、医療機器のためのソフトウェア検証は、正しいメッセージフォーマットが翻訳モジュール（この翻訳モジュールのための翻訳ルールは、現場でカスタマイズ可能である）から受信されることを検証することによって完了する可能性がある。このことは、現場での検証手続を著しく効率化させるという結果を生じることがあり、これにより現場でカスタマイズ可能な翻訳ルールの使用によって救命医療技術をより素早く患者に届けるためにより効率的なＦＤＡ順守が可能になるので有利であろう。

Ｖ． 実施形態例
ある実施形態では、医療監視ハブ上の出力のため医療データ翻訳を提供するシステムは、生理学的センサから患者に関連付けられた生理学的信号を受信することと、生理学的信号に基づいて生理学的パラメータを計算することと、表示のため生理学的パラメータの第１の値を監視ハブに供給することとが可能であるプロセッサを備える携帯型生理学的モニタを含むことができる。監視ハブは、携帯型生理学的モニタを受け入れることが可能であるドッキングステーションを含むことができる。監視ハブは、携帯型生理学的モニタから生理学的パラメータの第１の値を受信することと、表示のため生理学的パラメータの第１の値を出力することと、携帯型生理学的モニタ以外の医療機器から、監視ハブにより元々から読み取り可能もしくは表示可能であるプロトコル以外のプロコルに従ってフォーマットされた生理学的パラメータデータを受信することと、生理学的パラメータデータを翻訳モジュールに渡すことと、翻訳モジュールから、監視ハブにより読み取り可能および表示可能であり得る翻訳済みのパラメータデータを受信することと、表示のため翻訳済みのパラメータデータから第２の値を出力することと、が可能である。

前の段落のシステムは、以下の特徴：監視ハブが、生理学的パラメータの第１の値および翻訳済みのパラメータデータからの第２の値を別個のディスプレイに出力するようにさらに構成されていることと、監視ハブが、翻訳済みのパラメータデータからの第２の値を監視ハブのディスプレイとは別個のディスプレイを有する補助機器へ出力するようにさらに構成されていることと、補助機器がテレビ、タブレット、電話機、ウェアラブルコンピュータ、およびラップトップからなる群より選択されることと、生理学的パラメータデータが灌流ポンプからのデータを含むことと、生理学的パラメータデータが人工呼吸器からのデータを含むことと、翻訳モジュールが第１のヘルス・レベル・セブン（ＨＬ７）フォーマットから第２のＨＬ７フォーマットに生理学的パラメータデータを翻訳するように構成されていることと、のいかなる一部の組み合わせとも組み合わせることができる。

ある実施形態では、医療監視ハブ上の出力のため医療データ翻訳を提供する方法は、デジタル論理回路を備える第１の医療機器の制御下で、生理学的センサから患者に関連付けられた生理学的信号を受信することと、生理学的信号に基づいて第１の生理学的パラメータ値を取得することと、表示のため第１の生理学的パラメータ値を出力することと、第１の医療機器が表示可能な出力値を生成するために第２の生理学的パラメータ値を処理できないように、第１の医療機器以外の第２の医療機器から、第１の医療機器によって使用されないプロトコルに従ってフォーマットされた第２の生理学的パラメータ値を受信することと、第１の医療機器から別個の翻訳モジュールに生理学的パラメータデータを渡すことと、第１の医療機器で翻訳モジュールから、第１の医療機器によって表示のため処理され得る翻訳済みのパラメータデータを受信することと、表示のため翻訳済みのパラメータデータから第２の値を出力することと、を含むことができる。

前の段落の方法は、以下の特徴：第１のヘルス・レベル・セブン（ＨＬ７）フォーマットから第２のＨＬ７フォーマットにメッセージを少なくとも翻訳することにより、メッセージを翻訳することをさらに含むことと、メッセージが生理学的モニタからのデータを含む可能性があることと、メッセージが灌流ポンプもしくは人工呼吸器からのデータを含む可能性があることと、メッセージが病院ベッドからのデータを含む可能性があることと、のいかなる一部の組み合わせとも組み合わせることができる。

ある実施形態では、医療監視ハブ上の出力のため医療データ翻訳を提供するシステムは、患者に関連付けられた第１の生理学的パラメータ値を取得することと、表示のため第１の生理学的パラメータ値を出力することと、第１の医療機器が表示可能な出力値を生成するために第２の生理学的パラメータ値を処理できないように、第１の医療機器以外の第２の医療機器から、第１の医療機器によって使用されないプロコルに従ってフォーマットされた第２の生理学的パラメータ値を受信することと、第１の医療機器から翻訳モジュールに生理学的パラメータデータを渡すことと、第１の医療機器で翻訳モジュールから、第１の医療機器による表示のため処理され得る翻訳済みのパラメータデータを受信することと、表示のため翻訳済みのパラメータデータから第２の値を出力することと、が可能である電子ハードウェアを含んでいる第１の医療機器を含むことができる。

前の段落のシステムは、以下の特徴：第１の医療機器が生理学的パラメータの第１の値および翻訳済みのパラメータデータからの第２の値を同じディスプレイ上に出力することも可能であることと、第１の医療機器が生理学的パラメータの第１の値および翻訳済みのパラメータデータからの第２の値を別個のディスプレイ上に出力することも可能であることと、第１の医療機器が翻訳済みのパラメータデータからの第２の値を補助機器へ出力することも可能であることと、補助機器がテレビモニタであることが可能であることと、補助機器がタブレット、電話機、ウェアラブルコンピュータ、およびラップトップからなる群より選択されることが可能であることと、第１の医療機器が翻訳モジュールを含むことが可能であることと、第１の医療機器がネットワークを介して生理学的パラメータデータを翻訳モジュールに渡すことも可能であることと、生理学的パラメータデータが灌流ポンプもしくは人工呼吸器からのデータを含むことが可能であることと、のいかなる一部の組み合わせとも組み合わせることができる。

ＶＩ． 用語集
本明細書に記載された変形以外の多くの他の変形は、本開示から明らかであろう。たとえば、実施形態に依存して、本明細書に記載されたアルゴリズムの作用、イベント、もしくは機能は、異なったシーケンスで行われる可能性があり、全体で追加、統合、もしくは削除される可能性がある（たとえば、記載された作用もしくはイベントが全てアルゴリズムの実施のため必要であるとは限らない）。さらに、ある実施形態では、作用もしくはイベントは、逐次的ではなく、たとえば、マルチスレッド処理、割り込み処理、または、マルチ・プロセッサもしくはマルチ・プロセッサ・コアを用いて、または、他の並列アーキテクチャ上で同時に行われる可能性がある。その上、様々なタスクもしくはプロセスが一斉に機能することができる様々なマシンおよび／またはコンピューティングシステムによって行われる可能性がある。

必ずしも全てのこのような利点が本明細書に開示された実施形態のうち特定の実施形態により実現されるとは限らないことが理解されるべきである。それ故に、本明細書に開示された実施形態は、本明細書において教示もしくは示唆されることがあるとおりに必ずしも他の利点を実現することなく、本明細書において教示されたとおりに１つの利点もしくは利点のグループを実現もしくは最適化する形で具現化もしくは実施され得る。

本明細書に開示された実施形態に関連して記載された様々な例示的な論理ブロック、モジュール、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、もしくは両者の組み合わせとして実装される可能性がある。このハードウェアおよびソフトウェアの互換性を明瞭に例示するために、様々な例示的なコンポーネント、ブロック、モジュール、およびステップがこれらの機能性の観点から概略的に前述されている。このような機能性がハードウェアとして実装されるか、もしくは、ソフトウェアとして実装されるかは、特定の用途と、システム全体に課された設計上の制約とに依存する。記載された機能性は、特定の用途毎に様々な方法で実装される可能性があるが、このような実装法決定は、本開示の範囲からの逸脱を引き起こすものとして解釈されるべきではない。

本明細書に開示された実施形態に関連して記載された様々な例示的な論理ブロックおよびモジュールは、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）もしくは他のプログラマブル論理デバイス、ディスクリートゲートもしくはトランジスタ論理回路、ディスクリート・ハードウェア・コンポーネント、または、本明細書に記載された機能を実行するように設計されたこれらのいずれかの組み合わせのようなマシンによって実装もしくは実行される可能性がある。汎用プロセッサは、マイクロプロセッサである可能性があるが、代替案では、プロセッサは、コントローラ、マイクロコントローラ、もしくは状態マシン、またはこれらの組み合わせなどである可能性がある。プロセッサは、コンピュータ実行可能な命令を処理するように構成されている電気回路もしくはデジタル論理回路を含む可能性がある。別の実施形態では、プロセッサは、コンピュータ実行可能な命令を処理することなく論理演算を実行するＦＰＧＡもしくは他のプログラマブルデバイスを含む。プロセッサは、コンピューティング機器の組み合わせ、たとえば、ＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと併用した１台以上のマイクロプロセッサ、または他のこのような構成として実装される可能性もある。コンピューティング環境は、例を挙げると、限定されることなく、電化製品の内部のマイクロプロセッサ、メインフレームコンピュータ、デジタル信号プロセッサ、携帯型コンピューティング機器、機器コントローラ、もしくは計算エンジンに基づくコンピュータシステムを含んでいるいずれかのタイプのコンピュータシステムを含む可能性がある。

本明細書に開示された実施形態に関連して記載された方法、プロセス、もしくはアルゴリズムのステップは、ハードウェアで直接的に、１台以上のメモリ機器に記憶され、１台以上のプロセッサによって実行されるソフトウェアモジュールで、または、これら２つの組み合わせで具現化される可能性がある。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、または他の形式の非一時的なコンピュータ読み取り可能な記憶媒体、媒体群、もしくは、当該技術分野において知られている物理的なコンピュータストレージに存在する可能性がある。記憶媒体例は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される可能性がある。代替案では、記憶媒体は、プロセッサに一体化される可能性がある。記憶媒体は、揮発性もしくは不揮発性である可能性がある。プロセッサおよび記憶媒体は、ＡＳＩＣに存在する可能性がある。

数ある中でも、「ｃａｎ（〜できる）」、「ｍｉｇｈｔ（〜かもしれない）」、「ｍａｙ（〜することがある）」、「たとえば」などのような本明細書において使用された条件付きの言葉は、特に断らない限り、または、使用された文脈の範囲内で違った形で理解されない限り、ある実施形態がある特徴、要素、および／または状態を含み、他の実施形態は、ある特徴、要素および状態を含まないということを伝達するように一般に意図されている。それ故に、このような条件付きの言葉は、特徴、要素、および／または状態が１つ以上の実施形態に対して多少なりとも必要とされていること、または、１つ以上の実施形態が、作成者入力もしくはプロンプティングの有無にかかわらず、これらの特徴、要素、および／または状態がいずれかの特定の実施形態において含まれているか、もしくは、実行されるべきであるかを決定する論理を必ず含んでいることを暗示するようには一般に意図されていない。用語「ｃｏｍｐｒｉｓｉｎｇ（備える）」、「ｉｎｃｌｕｄｉｎｇ（含む）」、「ｈａｖｉｎｇ（有する）」などは、同義語であり、オープンエンド形式で包括的に使用され、追加の要素、特徴、作用、動作などを除外することがない。同様に、用語「ｏｒ（または）」は、これの両立的な意味で使用されるので（かつ、これの排他的な意味では使用されないので）、たとえば、要素のリストを接続するために使用されたとき、用語「ｏｒ（または）」は、リストの中の要素の１つ、一部、もしくは全部を意味する。さらに、本明細書において使用されるように用語「ｅａｃｈ（各々の）」は、これの通常の意味を有する他に、要素の集合の中で、用語「ｅａｃｈ（各々の）」が適用されるいずれかの部分集合を意味する可能性がある。

「Ｘ、Ｙ、またはＺのうち少なくとも１つ」という言い回しのような選言的な言葉は、特に断らない限り、項目、用語などを表現するために一般に使用された文脈を使って違った形で理解されない限り、Ｘ、Ｙ、もしくはＺのいずれか、または、これらのいずれかの組み合わせ（たとえば、Ｘ、Ｙ、および／またはＺ）であることがある。従って、このような選言的な言葉は、ある実施形態がＸのうち少なくとも１つ、Ｙのうち少なくとも１つ、もしくはＺのうち少なくとも１つがそれぞれ存在することを必要とすることを暗示するように一般に意図されることがなく、かつ、暗示すべきではない。

特に断らない限り、「ａ」もしくは「ａｎ」のような冠詞は、１つ以上の記載された項目を含むように一般に解釈されるべきである。その結果、「〜ように構成された機器」のような言い回しは、１つ以上の列挙された機器を含むように意図されている。このような１つ以上の列挙された機器は、規定された列挙を実施するために集合的に構成される可能性もある。たとえば、「列挙Ａ、ＢおよびＣを実施するように構成されたプロセッサ」は、列挙Ａを実施するように構成され、列挙ＢおよびＣを実施するように構成された第２のプロセッサと併せて動作する第１のプロセッサを含む可能性がある。

以上の詳細な説明は、様々な実施形態に適用されたとおりに新規特徴について明らかにし、説明し、指摘しているが、例示された機器もしくはアルゴリズムの形式および細部についての様々な省略、置換、および変更が本開示の趣旨から逸脱することなく行われ得ることが分かるであろう。本明細書に記載された発明のある実施形態は、いくつかの特徴が互いに別々に使用もしくは実施される可能性があるので、本明細書に記載された特徴および利点の必ずしも全部をもたらさない形式の範囲内で具現化され得ることが認められるであろう。

さらに、本明細書において挙げられたあらゆる刊行物、特許、および特許出願は、各々の個別の刊行物、特許、もしくは特許出願が参照によって組み込まれるように具体的かつ個別に指し示されたのと同じ程度まで参照によって本明細書に組み込まれる。

Claims (28)

1. 医療監視ハブ上の出力のため医療データを提供する方法であって、
   デジタル論理回路を備える第１の医療機器の制御下で、
   患者に関連付けられた生理学的信号を生理学的センサから受信することと、
   前記生理学的信号に基づいて第１の生理学的パラメータ値を取得することと、
   対応する第１の生理学的パラメータの波形と共に、表示のため前記第１の生理学的パラメータ値を出力することと、
   前記患者に関連づけられた前記第２の生理学的パラメータ値を受信することと、
   対応する第２の生理学的パラメータの波形を伴わずに、表示のため前記第２の生理学的パラメータ値を出力すること、
   第２の生理学的パラメータ値をディスプレイの第１の部分からディスプレイの第２の部分にドラッグするユーザ入力を受け取ることに応答して、第２の生理学的パラメータ値を第２の生理学的パラメータの対応する波形と共に、第１の生理学的パラメータ値と第１の生理学的パラメータの対応する波形とに隣接して表示することと、を含む方法。
2. 前記第１の医療機器以外の第２の医療機器から、前記第１の医療機器によって使用されていないプロトコルに従って、前記第１の医療機器が第３の生理学的パラメータ値を処理して表示可能な出力値を生成することができないように、フォーマットされた第３の生理学的パラメータ値を取得することと、
   前記第３の生理学的パラメータ値を前記第１の医療機器から翻訳モジュールに送ることと、
   前記第１の医療機器で前記翻訳モジュールから、前記第１の医療機器によって表示のため処理され得る翻訳済みのパラメータデータを受信することと、
   表示のため前記翻訳済みのパラメータデータから前記第３の生理学的パラメータ値を出力することと、をさらに含む、請求項１に記載の方法。
3. 第１のヘルス・レベル・セブン（ＨＬ７）フォーマットから第２のＨＬ７フォーマットに前記第３の生理学的パラメータ値を翻訳することにより前記翻訳済みのパラメータデータを決定することをさらに含む、請求項２に記載の方法。
4. 前記第３の生理学的パラメータ値は、生理学的モニタからのデータを含む、請求項３に記載の方法。
5. 前記第３の生理学的パラメータ値は、灌流ポンプもしくは人工呼吸器からのデータを含む、請求項３に記載の方法。
6. 前記第３の生理学的パラメータ値は、病院ベッドからのデータを含む、請求項３に記載の方法。
7. 同じディスプレイに表示するため、第１、第３の生理学的パラメータ値と前記翻訳済みのパラメータデータからの前記第３の生理学的パラメータ値を出力すること、を含む請求項２に記載の方法。
8. 前記翻訳済みのパラメータデータからの前記第３の生理学的パラメータ値を、前記第１の医療機器のディスプレイとは別個のディスプレイを備える補助機器に出力することと、を含む、請求項２に記載の方法。
9. 前記補助機器は、前記別個のディスプレイに、前記第１の医療機器のディスプレイに映される波形よりも大きい、詳細波形を表示するように構成される、請求項８に記載の方法。
10. 前記補助機器は、前記詳細な波形を拡大表示するユーザの入力を受信したことに応じて、前記別個のディスプレイの他の要素の代わりに前記別個のディスプレイを一杯に満たすために前記詳細な波形を拡大するように構成される、請求項９に記載の方法。
11. 前記ディスプレイに、表示された波形の時間窓を変更するためにユーザによって選択可能な時間窓ボタンを前記ディスプレイに表示することを含む、請求項１に記載の方法。
12. 第２の生理学的パラメータ値をディスプレイの第１の部分からディスプレイの第２の部分にドラッグ・アンド・ドロップするユーザ入力を受け取ることに応答して、前記第２の生理学的パラメータ値に関連づけられたアラーム限界を表示させること、をさらに含む請求項１に記載の方法。
13. 前記アラーム限界は、調整可能なアラーム限界を含む、請求項１３に記載の方法。
14. 医療監視ハブ上の出力のため医療データを提供するシステムであって、
    前記システムは、第１の医療機器を備え、
    前記第１の医療機器は、
    患者に関連付けられた第１の生理学的パラメータ値を取得し、
    対応する第１の生理学的パラメータの波形と共に、表示のため前記第１の生理学的パラメータ値を出力し、
    前記患者に関連づけられた前記第２の生理学的パラメータ値を受信し、
    対応する第２の生理学的パラメータの波形を伴わずに、表示のため前記第２の生理学的パラメータ値を出力し、
    第２の生理学的パラメータ値をディスプレイの第１の部分からディスプレイの第２の部分にドラッグ・アンド・ドロップするユーザ入力を受け取ることに応答して、第２の生理学的パラメータ値を第２の生理学的パラメータの対応する波形と共に、第１の生理学的パラメータ値と第１の生理学的パラメータの対応する波形とに隣接して表示する、ように構成されている電子ハードウェアを備える、システム。
15. 前記第１の医療機器は、さらに、
    前記第１の医療機器以外の第２の医療機器から、前記第１の医療機器によって使用されていないプロトコルに従って、前記第１の医療機器が第３の生理学的パラメータ値を処理して表示可能な出力値を生成することができないように、フォーマットされた第３の生理学的パラメータ値を取得し、
    前記第３の生理学的パラメータ値を前記第１の医療機器から翻訳モジュールに送り、
    前記第１の医療機器で前記翻訳モジュールから、前記第１の医療機器によって表示のため処理され得る翻訳済みのパラメータデータを受信し、
    表示のため前記翻訳済みのパラメータデータから前記第３の生理学的パラメータ値を出力する、ように構成されている、請求項１４に記載のシステム。
16. 前記第１の医療機器は、表示のため前記翻訳済みのパラメータデータから、前記第１の生理学的パラメータおよび前記第３の生理学的パラメータ値を、同じディスプレイに出力するようにさらに構成されている、請求項１５に記載のシステム。
17. 前記第１の医療機器は、前記第１の生理学的パラメータおよび表示のため前記翻訳済みのパラメータデータからの前記第３の生理学的パラメータ値を、別個のディスプレイ上に出力するようにさらに構成されている、請求項１６に記載のシステム。
18. 前記第１の医療機器は、前記翻訳済みのパラメータデータからの前記第３の生理学的パラメータ値を、別個のディスプレイを備える補助機器へ出力するようにさらに構成されている、請求項１７に記載のシステム。
19. 前記補助機器は、テレビモニタである、請求項１８に記載のシステム。
20. 前記補助機器は、タブレット、電話機、ウェアラブルコンピュータ、およびラップトップからなる群より選択される、請求項１８に記載のシステム。
21. 前記補助機器は、前記別個のディスプレイに、前記第１の医療機器の前記ディスプレイに表された波形より大きい詳細な波形を表示するように構成される、請求項１８に記載のシステム。
22. 前記補助機器は、前記詳細な波形を拡大表示するユーザの入力を受信したことに応じて、前記別個のディスプレイの他の要素の代わりに前記別個のディスプレイを一杯に満たすために前記詳細な波形を拡大するように構成される、請求項２１に記載のシステム。
23. 前記第１の医療機器は、前記翻訳モジュールを備える、請求項１５に記載のシステム。
24. 前記第１の医療機器は、ネットワークを介して前記生理学的パラメータデータを前記翻訳モジュールに渡すようにさらに構成されている、請求項１５に記載のシステム。
25. 前記生理学的パラメータデータは、灌流ポンプもしくは人工呼吸器からのデータを含む、請求項１５に記載のシステム。
26. 前記ディスプレイに、波形表示の時間窓を変更するための、ユーザによって選択可能な時間窓ボタンを表示する、ように構成される、請求項１４に記載のシステム。
27. 第２の生理学的パラメータ値をディスプレイの第１の部分からディスプレイの第２の部分にドラッグ・アンド・ドロップするユーザ入力を受け取ることに応答して、前記第２の生理学的パラメータ値に関連づけられたアラーム限界を表示させる、ように構成される、請求項１４に記載のシステム。
28. 前記アラーム限界は、調整可能なアラーム限界を含む、請求項２７に記載のシステム。
    

Images