JP2022119892A - 医療監視データを表示するシステム - 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 (14)

1. 医療データを表示するシステムであって、
   前記システムは、電子ハードウェアを含んでいる第１の医療機器を備え、
   前記電子ハードウェアは、
   生理学的センサから生理学的信号を受信し、
   前記生理学的信号に基づいて、患者に関連する第１の生理学的パラメータの第１の生理学的パラメータ値を決定し、
   ディスプレイの第１の部分に、前記第１の生理学的パラメータの対応する波形と共に、表示のため前記第１の生理学的パラメータ値を出力し、
   患者に関連する第２の生理学的パラメータの第２の生理学的パラメータ値を受信し、
   前記ディスプレイの第２の部分に、表示のため前記第２の生理学的パラメータ値を出力し、
   前記第２の生理学的パラメータ値をディスプレイの第１の部分からディスプレイの第２の部分にドラッグ・アンド・ドロップする第１のユーザ入力を受信することに応答して、第１および第２の生理学的パラメータの対応する波形をディスプレイの同じ部分で互いに重ね合わせる、
   ように構成されている、システム。
2. 前記第１の生理学的パラメータ値は、前記第１の生理学的パラメータの対応する波形とともに出力され、ディスプレイの第１の部分の第１のセクションに表示され、
   前記第２の生理学的パラメータ値は、前記第２の生理学的パラメータの対応する波形なしで、ディスプレイの第２の部分に表示するために出力され、
   前記第１の医療機器は、
   前記ディスプレイの第２の部分からディスプレイの第１の部分に前記第２の生理学的パラメータ値をドラッグ・アンド・ドロップする第２のユーザ入力を受信することに応答して、前記第２の生理学的パラメータ値を、前記第２の生理学的パラメータの対応する波形とともに、前記ディスプレイの第１の部分の第１のセクションに隣接する前記ディスプレイの第１の部分の第２のセクションに表示させる、
   ように構成される、請求項１に記載のシステム。
3. 前記第１の医療機器は、
   前記第２の生理学的パラメータに関連するアラーム状態の決定に応じて、表示された第２の生理学的パラメータ値および第２の生理学的パラメータの対応する波形を囲む前記ディスプレイの第１の部分の第２のセクションを強調表示する、
   ように構成される、請求項２に記載のシステム。
4. 前記第１の医療機器は、
   前記ディスプレイの第１の部分に、前記第１の生理学的パラメータを含む、表示された各生理学的パラメータに関連するそれぞれのアラーム限界の表示を出力し、前記アラーム限界の表示は、生理学的パラメータのそれぞれの関連する表示値に隣接して表示され、前記第２の生理学的パラメータ値は、対応するアラーム限界の表示なしに、前記ディスプレイの第２の部分に表示され、
   前記第２の生理学的パラメータ値を前記ディスプレイの第２の部分からディスプレイの第１の部分にドラッグ・アンド・ドロップする第２のユーザ入力を受信したことに応答して、前記ディスプレイの第１の部分の第２のセクションに、前記第２の生理学的パラメータ値に隣接して、前記第２の生理学的パラメータに関連するアラーム限界の表示をする、
   ように構成される、請求項３に記載のシステム。
5. 前記第１の医療機器は、
   前記第１の医療機器が第３の生理学的パラメータ値を処理して表示可能な出力値を生成することができないように、前記第１の医療機器によって使用されないプロトコルに従ってフォーマットされた第３の生理学的パラメータ値を第２の医療機器から取得し、
   前記第３の生理学的パラメータ値を前記第１の医療機器から翻訳モジュールに送り、
   前記第１の医療機器の前記翻訳モジュールから翻訳されたパラメータデータを受信し、翻訳されたパラメータデータは、前記第１の医療機器によって表示するために処理することができ、
   表示のため、翻訳されたパラメータデータから第３の生理学的パラメータ値を出力する、
   ように構成される、請求項１に記載のシステム。
6. 前記第１の医療機器は、
   前記翻訳されたパラメータデータから前記第1の生理学的パラメータ値と前記第３の生理学的パラメータ値を出力して、同じディスプレイに表示する、
   ように構成される、請求項５に記載のシステム。
7. 前記第１の医療機器は、
   前記翻訳されたパラメータデータから前記第３の生理学的パラメータ値を、前記第１の医療機器のディスプレイとは別のディスプレイを有する補助デバイスに出力する、
   ように構成される、請求項５に記載のシステム。
8. 医療データを表示する方法であって、
   前記方法は、デジタル論理回路を含む第１の医療機器によって、
   生理学的センサから生理学的信号を受信し、
   前記生理学的信号に基づいて、患者に関連する第１の生理学的パラメータの第１の生理学的パラメータ値を決定し、
   ディスプレイの第１の部分に、前記第１の生理学的パラメータの対応する波形と共に、表示のため前記第１の生理学的パラメータ値を出力し、
   患者に関連する第２の生理学的パラメータの第２の生理学的パラメータ値を受信し、
   前記ディスプレイの第２の部分に、表示のため前記第２の生理学的パラメータ値を出力し、
   前記第２の生理学的パラメータ値を前記ディスプレイの第１の部分から前記ディスプレイの第２の部分にドラッグ・アンド・ドロップする第１のユーザ入力を受信することに応答して、第１および第２の生理学的パラメータの対応する波形を前記ディスプレイの同じ部分で互いに重ね合わせる、
   方法。
9. 前記第１の生理学的パラメータ値は、前記第１の生理学的パラメータの対応する波形とともに出力され、前記ディスプレイの第１の部分の第１のセクションに表示され、
   前記第２の生理学的パラメータ値は、前記第２の生理学的パラメータの対応する波形なしで、前記ディスプレイの第２の部分に表示するために出力され、
   前記方法は、前記デジタル論理回路を含む前記第１の医療機器によって、
   前記ディスプレイの第２の部分からディスプレイの第１の部分に前記第２の生理学的パラメータ値をドラッグ・アンド・ドロップする第２のユーザ入力を受信することに応答して、前記第２の生理学的パラメータ値を、前記第２の生理学的パラメータの対応する波形とともに、前記ディスプレイの第１の部分の第１のセクションに隣接するディスプレイの第１の部分の第２のセクションに表示させる、請求項８に記載の方法。
10. 前記方法は、前記デジタル論理回路を含む前記第１の医療機器によって、
    前記第２の生理学的パラメータに関連するアラーム状態の決定に応じて、表示された第２の生理学的パラメータ値および第２の生理学的パラメータの対応する波形を囲む前記ディスプレイの第１の部分の第２のセクションを強調表示する、請求項９に記載の方法。
11. 前記方法は、前記デジタル論理回路を含む前記第１の医療機器によって、
    前記ディスプレイの第１の部分に、前記第１の生理学的パラメータを含む、表示された各生理学的パラメータに関連するそれぞれのアラーム限界の表示を出力し、前記アラーム限界の表示は、生理学的パラメータのそれぞれの関連する表示値に隣接して表示され、前記第２の生理学的パラメータ値は、対応するアラーム限界の表示なしに、前記ディスプレイの第２の部分に表示され、
    前記第２の生理学的パラメータ値を前記ディスプレイの第２の部分からディスプレイの第１の部分にドラッグ・アンド・ドロップする第２のユーザ入力を受信したことに応答して、前記ディスプレイの第１の部分の第２のセクションに、第２の生理学的パラメータ値に隣接して、第２の生理学的パラメータに関連するアラーム限界の表示をする、請求項１０に記載の方法。
12. 前記方法は、前記デジタル論理回路を含む前記第１の医療機器によって、
    前記第１の医療機器が第３の生理学的パラメータ値を処理して表示可能な出力値を生成することができないように、前記第１の医療機器によって使用されないプロトコルに従ってフォーマットされた第３の生理学的パラメータ値を第２の医療機器から取得し、
    前記第３の生理学的パラメータ値を前記第１の医療機器から翻訳モジュールに送り、
    前記第１の医療機器の前記翻訳モジュールから翻訳されたパラメータデータを受信し、翻訳されたパラメータデータは、前記第１の医療機器によって表示するために処理することができ、
    表示のため、翻訳されたパラメータデータから第３の生理学的パラメータ値を出力する、請求項８に記載の方法。
13. 前記方法は、前記デジタル論理回路を含む前記第１の医療機器によって、
    前記翻訳されたパラメータデータから前記第1の生理学的パラメータ値と前記第３の生理学的パラメータ値を出力して、同じディスプレイに表示する、請求項１２に記載の方法。
14. 前記方法は、前記デジタル論理回路を含む前記第１の医療機器によって、
    前記翻訳されたパラメータデータから前記第３の生理学的パラメータ値を、前記第１の医療機器のディスプレイとは別のディスプレイを有する補助デバイスに出力する、請求項１２に記載の方法。

Images