JP2008165684A - 個人健康空間における医療デバイス・データのフローのための適応型フレームワーク - Google Patents

Abstract

【課題】 個人健康空間においてエージェントに応じてマネージャの適応型構成を可能にするシステムおよび方法。
【解決手段】 マネージャは、エージェントへのクエリおよびエージェントからのクエリに応答して、それ自体を構成することができる。この構成は、エージェントの複雑度のレベルに基づいている。エージェントは、標準フレームワークと高度フレームワークとの間で変更することができる。２つのデバイス間の通信は、ワイヤレス接続を通じて行われる。
【選択図】 図１

Description

本発明は、個人健康空間(personal health space)においてエージェントに応答してマネージャの適応型構成を可能にするシステムおよび方法に関する。この構成は、エージェントの複雑性のレベルに基づく。エージェントは、標準的フレームワークと高度フレームワークとの間で可変とすることができる。２台のデバイス間の通信は、ワイヤレス接続を通じて行われる。

以上に述べたことは、以下に続く本発明の詳細な説明をより良く理解できるようにするために、本発明の特徴および技術的利点を、どちらかと言うと広義に概説した。本発明の特許請求の範囲の主題となる、本発明の追加の特徴および利点も以下で説明する。尚、開示する概念および具体的な実施形態は、本発明の同じ目的を遂行するためのその他の構造を修正または設計する際の基準として用意に利用してもよいことは、当業者には認められてしかるべきである。また、このような同等の構造は、添付した特許請求の範囲に明記されている発明の精神および範囲から逸脱するのではないことも、当業者は了解してしかるべきである。本発明の特色であると確信する新規の特徴は、その編成および動作方法の双方について、更に別の目的および利点と共に、以下の説明を添付図面と合わせて検討することにより、一層理解が深まるであろう。しかしながら、図面の各々は、例示および説明のみを目的とするのであり、本発明の範囲の定義とは見なさないことは、わざわざ言うまでもないことである。

本発明の理解を完全な水準まで近づけるためにこれより添付図面と関連付けて以下の説明を参照する。
本発明のアーキテクチャを詳細に論ずる前に、個人健康（ＰＨ）デバイスが動作する一般的な環境、および臨床空間と個人健康空間との間におけるデータ・フローの微妙な差について論ずることは、それだけの価値がある。比較を用意にするために、医療診断を行う際に必要なデータ（例えば、脈拍、収縮期圧、デバイス精度、デバイス分解能等）のような医療データと、医療データ周囲のメッセージング・ラッパ(messaging wrapper)（例えば、取得／設定メッセージング、デバイス能力／属性等）のような関連メタ・データとに、データ・フローを分割することができる。

・臨床医療データ対ＰＨ医療データ
ケア・プロバイダ(care provider)は、一般に、データの医療的側面を差別したがらない。ケア・プロバイダは、一般に、このデータを取得したのは自宅、クリニック(clinic)、病院または他のいずれかの場所のどこであったか区別する必要がない。ケア・プロバイダは、一般に、収集した医療データの品質、信頼性、安全性、および命名法が同一であり、データおよびデバイスの有効な診断ならびに相互運用性が可能であることを望む。

・臨床関連メタ・データ対ＰＨ関連メタ・データ
臨床環境では、エージェント（例えば、パルスオキシメータ）は部屋および／または患者を頻繁に変える。このエージェントによって取得したデータは、エージェントが部屋および患者間で変化するに連れて、数個の異なるマネージャ（例えば、生存徴候モニタ）上に表示することができる。これらのデバイスが、数個の異なる用途および患者の状態にそれらの使用を拡大する環境において相互運用するために、エージェントおよびマネージャに何らかの「人工知能」を設ける。この知能は、リンクまたはその他の接続がエージェントおよびマネージャ間で設定したときにはいつでも、デバイスが適性にそれら自体を識別することを保証する。ある実施形態では、用途が必要とするのであれば、それに応じてデバイスはそれら自体を再構成し、しかるべきデータを送信することができる。しかしながら、ＰＨ空間におけるエージェントは、患者の自宅における非常に少数のマネージャに通信するので、再構成可能性(re-configurability)の要望が限定される可能性が高い。ＰＨ空間において用いられるエージェントは、臨床環境におけるエージェントと比較すると、相対的に単純にすることができる。一旦エージェントが後続のセッションのためにそれ自体をマネージャに導入したなら、ポールされたときにデータを送信するだけでよい。

尚、臨床設定では、デバイスは、訓練を受けた有能な職業人によって扱われ運用されるのが一般的であることを記しておく。一方、ＰＨ空間では、これらのデバイスは、訓練および認識能力が限られている患者またはその他の人が用いることができる程度に十分に単純でなければならない。

図１は、本発明を実現することができる環境を示すブロック図である。システム１００は、個人健康エージェント１１０、ワイヤレス・トランシーバ１２０、マネージャ１３０、および第２ワイヤレス・トランシーバ１４０を含む。本開示は単一のエージェント１１０および単一のマネージャ１３０に言及するが、本発明は１つよりも多いエージェントまたはマネージャを用いても実現可能であることは、当業者には容易に認められよう。

個人健康エージェント１１０は、一実施形態では、パルスオキシメータである。しかしながら、体温計、血圧モニタ、心電図（ＥＫＧ）、脳波図（ＥＥＧ）、体重計、またはその他にいずれの物理化学監視デバイスのような、他のデバイスも使用可能である。しかしながら、ある実施形態では、個人健康エージェントは、静脈内薬剤(intravenous drug)の流れを許容または制御するというように、患者に対してある種の医療処置を与えるように構成することができる。前述のように、ＰＨエージェント１１０は、比較的単純なデバイスであり、マネージャ１３０との通信の所望の機能を実行するために必要な最少量の構造しか含んでいない。ＰＨエージェント１１０の具体的な構成要素は、エージェント１１０の機能性に応じて様々である。ある実施形態では、個人健康エージェント１１０を２つの異なるフレームワーク、標準および高度に分割することができる。

標準的なフレームワークでは、エージェント１１０は、最小限の数値集合、例えば、キログラムおよびポンド単位で通信するように構成した体重計の値を、所定のフォーマットで通信することができる。

高度フレームワークでは、エージェント１１０は、最小限の数値集合に加えて、エージェントを区別することができる追加の数値を提供するように構成されている。ある実施形態では、この識別は、全域一意識別子（ＧＵＩＤ）を用いて行うことができ、あるいは階層手法を用いて行うことができる。しかしながら、他の識別方法を用いることもできる。ある実施形態では、エージェント１１０には高度機能性が構成されている。例えば、体重計は、キログラムおよびポンド単位の体重、ならびに体脂肪率をマネージャ１３０に通信するように構成されている。

マネージャ１３０は、エージェント１１０からの信号を処理することができれば、いずれのデバイスでもよい。一実施形態では、マネージャはパーソナル・コンピュータである。しかしながら、他の実施形態では、マネージャはセル・フォーン、セット・トップ・ボックス、パーソナル・ディジタル・アシスタント、あるいはエージェント１１０からの情報を処理または表示することができるのであればその他のいずれのデバイスでも可能である。マネージャ１３０は、受信した情報を取り込み、この情報を読み取り可能な表示に変換して、医療要員が読むことができるようにする。しかしながら、他の実施形態では、マネージャ１３０は受信した情報をプロトコルに変換し、更にリモート・サイトに送って、ここでデータを検討することもできる。加えて、ある実施形態では、マネージャ１３０は標準フレームワークまたは高度フレームワークのいずれでも、エージェント１１０の動作からの情報を処理するように構成されている。

エージェント１１０とマネージャ１３０との間で通信するために、各デバイス上にはトランシーバが設けられている。エージェント１１０はトランシーバ１２０を有し、マネージャ１３０はトランシーバ１４０を有する。本論述はトランシーバ１２０および１４０に言及するが、これらは送信機、受信機、またはそのいずれの組み合わせでも可能であることは、当業者には認められよう。トランシーバ１２０および１４０は、公知のワイヤレス・プロトコルであればいずれでも利用することができる。例えば、トランシーバ１２０および１４０は、Bluetooth、ＩＲ、ＧＰＲＳ、ＧＳＭ、あるいはエージェントとマネージャとの間でデータを送信するためのプロトコルであれば他のいずれでも可能である。

先に論じたように、エージェント１１０は、ある実施形態では、標準フレームワークまたは高度フレームワークを取ることができる。以下の論述の趣旨上、エージェント１１０をパルスオキシメータとする。パルスオキシメータは、人または動物における血液の酸素化を判定することができる。標準フレームワークでは、パルスオキシメータは、ストリーミング(streaming)、ならびに偶発的ＳｐＯ２および脈拍データを提供する。高度フレームワークでは、パルスオキシメータは、ストリーミング、ならびに偶発的ＳｐＯ２、ＨＲデータ、そして脈拍の品質(pulse quality)、秒単位の平均、またはその他のメトリック(metric)というような、別のメトリックを提供する。

標準フレームワークでは、エージェント１１０およびマネージャ１３０間でデータを送信する前に、データ・フロー相互作用(interaction)を作成する必要がある。データ・フロー相互作用を設定するために、エージェント１１０およびマネージャ１３０は初期接続を設定する。この接続を設定した後、デバイス１１０および１３０は接続指示を与え、それらの広域一意識別子（ＧＵＩＤ）またはその他の識別手段を交換する。一旦接続が設定され、ＩＤが交換されたなら、マネージャ１３０はジェージェント１１０からの分類情報を要求する。エージェント１１０が標準フレームワークで動作していると、標準パルスオキシメータというような、そのデバイス分類を回答する。次いで、マネージャ１３０は、標準パルスオキシメータ１１０に命名法およびシンタックスが利用可能か否かチェックして確認する。一旦このチェックを完了したなら、マネージャ１３０はデータのペイロードをパルスオキシメータ１１０に送る。一連のネゴシエーションまたはその他の通信プロトコルが、この時点において行われる。エージェント１１０が必要なデータを発生した後、エージェント１１０はペイロードをマネージャ１３０に返送する。次いで、マネージャはこのデータを処理し、更に他のあらゆる必要な動作も実行する。種々の理由で起こる可能性がある、デバイスの作為的または無作為の切断の場合、エージェントおよびマネージャは互いに再接続しようとする。再接続の間、デバイスは再度それらの識別を交換する。再識別、および接続が首尾良く行われたことを確認するためのチェックの後、エージェント１１０はデフォルトのペイロードをマネージャ１３０に再送するか、または送信しようとする。

高度フレームワークは、標準フレームワークと同様に接続を設定する。しかしながら、完璧を期する目的のため、このプロセスを再度繰り返す。このプロセスに対する関連を明確化するため、図２は、一実施形態にしたがって、高度フレームワークにおける接続およびデータ・フローの間に実行するステップを示すフロー図である。ステップ２１０において、トランスポート・レイヤは、エージェントとマネージャとの間に接続を設定し、接続指示を双方のデバイスに与える。このステップにおいて、双方のデバイス１１０および１３０に互いのＧＵＩＤ（例えば、Bluetooth ＭＡＣアドレス等）も伝達する。

ステップ２１５において、マネージャ１３０はエージェント分類を要求する。エージェント１１０が、血圧のような他の生理的タイプをサポートする場合、分類は、それに応じて、ＢＰは標準かまたは高度かを、ストリーミングまたは偶発的(episodic)と共に示す。エージェント１１０は、ステップ２２０において、その分類を返答する。

マネージャ１３０は、先進能力を解析することができるか確認するためにチェックする。これをステップ２２５に示す。マネージャ１３０が先進機構(advanced feature)を可能である場合、マネージャ１３０は、ステップ２３０において、特定のデータ集合（この例では、ストリーミング・ペイロードＰ１）に対する自己記述子を要求する。エージェントは、Ｐ１に対するその自己記述子を回答する。自己記述子は、ペイロード・フォーマットおよびメトリックスを記述する。これをステップ２３５に示す。

マネージャはこの自己記述子を検討し、シンタックスおよび命名法が一致していることの確証を得る。マネージャ１３０に常駐するアプリケーションが、そのアプリケーションに必要なＱｏＳを指定する。これをステップ２４０に示す。

エージェントおよびマネージャは、容認可能なＱｏＳを取り決める。これをステップ２４５に示す。
エージェントは、ペイロードＰ１の送信に移り、それを停止するように要求するまで送信する。これをステップ２５０に示す。接続に作為的なまたは無作為の中断(drop)があった場合、トランスポート・レイヤはリンクを再初期化し接続指示を与える責務がある。一旦リンクが設定されたなら、エージェントおよびマネージャはこの時点で、依然に接続されていたことを回想する（トランスポートＩＤに基づいて）ので、自己記述子を再送することなく、続いてエージェントはデフォルトのペイロードをマネージャ１３０に返送する。ある実施形態では、マネージャがいずれかの時点において、それが要求したデータを変更したい場合、他の要求を送ることを選択することができる。

本発明の適応型機構を達成するために、マネージャは、「ドライバ」や自己記述を必要とせずに、標準エージェントによって通信されるデータを理解する。高度エージェントの場合、それらの能力、特に、標準デバイス・フォーマットとの相違を自己記述しなければならない場合がある。また、マネージャも標準および高度に分類される。標準マネージャはインテリジェンスが制限されており、エージェントにおける標準能力と通信することができるに過ぎない。高度マネージャは、標準マネージャの能力を超えて、更に高くなる選択肢を有し、デバイスの区別、改良をし易くして、改革を促進する。表１は、標準および高度エージェントならびにマネージャ間の相違を端的に細分して示す。

ある実施形態では、標準ペイロードは標準エージェントによってサポートされ、デバイス／データ特殊化を拠り所としてペイロード構造の数値（例えば、パルスオキシメータにおけるＳｐ０２、ＩＩＲ）およびフォーマットを指定する。別の実施形態では、高度ペイロードは、標準ペイロードに追加するペイロードであり、マネージャが情報を解析することを可能にする自己記述子によってサポートされる。

ここで再度標準フレームワーク・エージェント１１０に言及し、エージェントのストリーミング属性についてこれより論ずる。エージェント１１０の標準能力はマネージャ１３０には知られているので、エージェント１１０が接続プロセスの間にそれ自体を自己記述する必要はない。デバイスがそれ自体の記述をマネージャ１３０に提供する必要がないので、測定特性の詳細なリストを、デバイス特殊化ファイル内に設けることができる。表２は、一実施形態による一例であり、パルスオキシメータ・エージェント１１０が提供することができるデータの一部の概要を示す。

表２の構造および機能は、本論述において後に概要を示す、ストリーミング・ペイロード記述の文脈では一層明確となると考えられる。
ここで再度高度フレームワークに言及すると、高度能力を有するエージェント１１０が、その能力や、いずれのペイロードを送る前にどのようにしてそのデータを送るかについて送信する。

高度エージェント１１０では、既存のＩＳＯ／ＩＥＥＥ１１０７３〜１０１０１命名法を利用して、自己記述子を一連のテーブルとして記述し、パルスオキシメータのより広い範囲に関連する拡張部、ならびに時間同期イベント報告のような能力を有するとよい。しかしながら、他の手法を用いることもできる。後続のデータ・ストリームをどのようにして処理するかをマネージャが知るために、自己記述子をエージェント１１０からマネージャ１３０に送ることができる。

一実施形態では、自己記述子は、デバイス記述（そのモデル、チャネル数、ＱｏＳ能力等に関する）、およびサイズ、場所またはその他の情報を含むペイロード記述を含む。
自己記述子の利点の１つは、それを「スタティック・パッチ」(static patch)として実現できることである。スタティック・パッチは、基本的に、デバイスおよびその能力を紹介する。この自己記述子は、先進エージェント１１０が最初にマネージャ１３０に自己紹介するときだけ送ればよい（または特に要請されるまで）。これは、ＸＭＬまたはその他の標準化されている記述プロトコルに容易に移植することができる。

以下の表は、記述メッセージとして送る自己記述属性を提案する。これらの表では、現在未定義または未解決の命名法をイタリック体で示している。これらの表は、現在用いられている製品と同様のパルスオキシメータの一例の医療データ属性の殆どを記載している。表の一部は、特定の酸素濃度計を記述する際に必要なデータの例をあげるために設けられている。尚、フォーマットは、ＩＳＯ／ＩＥＥＥ１１０７３〜１０２０１（ドメイン情報モデル）およびＩＳＯ／ＩＥＥＥ１１０７３〜１０１０１（命名法）における素材と同様であるが、内容は必ずしも論述対象の特定モデルに完全に一致するように意図している訳でもないことを記しておく。本論述の範囲を限定するために、これらの属性は、ストリーミング・ペイロードおよび偶発性ペイロード・タイプに適用可能であり、ペイロードＰ１およびＰ２は一例として提示するものとする。

ストリーミングＳｐＯ２についての属性 − 正常平均(normal averaging)
表３は、酸素濃度計の最も広く用いられている酸素飽和測定を報告するための属性を記述している。各メトリックには、仕様が添付されており、属性キーは、通常、連携値を有する。この場合、指定キーは、ニモニックMDC＿ATTR＿METRIC＿SPECNであり、その関連値はMDC＿METRIC＿O2＿SAT＿NORMである。尚、このニモニック値は現命名法の延長であることを記しておく。次の属性は、データ・ペイロードにおける個々の要素の場所に関連する。これ以上の詳細については、以下で論ずるペイロード・フォーマットを参照のこと。尚、このメトリックの内部では、メトリック・タイプを２バイトの整数／分数値対として記述し、最初のバイトが整数部分であり、２番目のバイトが分数部分であり、十進法で表されていることが言外に含まれていることを記しておく。指定によってデータ・タイプを暗示的に記述することにより、リストのサイズを小さくすることができる。加えて、標準データ・タイプについて確定している属性であればいずれでもこの表において置き換えることができる。暗示的に記述する最後の要素は、確定しているMDC＿ATTR＿TIME＿PD＿AVG属性の修正であり、平均値を計算する際に用いられる時間間隔を記述する。この場合、直前の４回の拍動に基づいて平均を計算している。別の平均式を表す必要がある場合、属性表が大きくなることを覚悟の上で、この属性を含ませることもできる。

表３は、メトリック指定が暗示的にデータ・サイズ、タイプ、および平均化方法を記述する場合に、正常平均したＳｐＯ２であり、表を小さくすることができる。尚、繰り返し間隔は適用できないので、デフォルト値を０と考え、必要でなければ含ませないことも記しておく。

ストリーミングＳｐＯ２についての属性−長期平均化
この第２のメトリックは、ＳｐＯ２計算を記述し、８拍動平均化方法に基づいている。尚、バイト位置が変化することに注意すること。この場合も、MDC＿METRIC＿O2＿SAT＿LONG指定を用いて、データ・タイプおよび平均化方法を暗示的に記述する。

ストリーミングＳｐＯ２についての属性−非スルー限定(non-slew limited)
ＳｐＯ２の更に別の測定方法は、ＳｐＯ２の非常に素早い変化を表すことを可能にする。これ以降の表は、測定情報がメトリック指定値に暗示的に含まれていることを仮定する。この表では、データ・サイズおよびデータ・タイプに関する追加の（そして任意の）キー−値値がここに含まれることは注目に値する。これらを、どのようにして指定が、明示的属性によって無効とされた(override)デフォルトのキー／値対を有することができるかの一例として示す。

ストリーミングＳｐＯ２についての属性−拍動毎（平均化しない）
平均化を用いない場合を表すために、表５を用いることができる。

ストリーミングＳｐＯ２についての属性−高速平均化（データ取得時に非スルー限定を採用）

ストリーミングＳｐＯ２についての属性−正常平均するが、表示のために１．５秒毎に更新する。しかしながら、他の時間を用いることもできる。
ＳｐＯ２は、読み取り可能な方法で表示しなければならない。最終属性、メトリック更新間隔を提示して、酸素濃度計が１．５秒毎にこの値を更新することをマネージャ１３０に伝える。

ストリーミングＳｐＯ２についての属性−長期平均するが、表示のために１．５秒毎に更新する。
同様に、表示保持を伴う長期平均は、以下のように表示することができる。

ストリーミング脈拍についての属性−正常平均化
脈拍は、数種類の方法で測定し表示する。以下の４つの表（表９から表１２）は、ＳｐＯ２測定に類似する。

ストリーミング脈拍についての属性−長期平均

ストリーミング脈拍についての属性−正常平均するが１．５秒毎に更新する

ストリーミング脈拍についての属性−長期平均するが１．５秒毎に更新する

ストリーミング・パルス振幅についての属性
ある実施形態では、パルスオキシメータがパルス品質の何らかの尺度を表すと有用である。ノイズの属性はMD＿ATTR＿MODE＿MSMTであり、これによって、異なるベンダが彼ら自身の２バイト・メトリック測定値を提供することが可能となる。ここでは、データ記述が多い方が適している場合もある。何故なら、MDC＿METRIC＿PULSE＿QUAL属性が暗示的に規定する２バイトは、パルス発生ステータス、特徴化ニモニック、またはインデックス・ニモニックと組み合わせて用いることができるからである。

ストリーミング時間同期イベントの報告についての属性
この属性は、時間同期イベント報告についてのキー・オブジェクトである。３バイトのMDC＿TYPE＿EVENTRECと命名したデータ記述は、PULSE＿OCCURREDのようなイベント・タイプの、イベントが発生した場合のミリ秒単位のオフセットを示す２バイトとの組み合わせと見なすことができる。尚、データ・ブロック毎に２つのイベントの容量があるので、これはメトリック報告間隔を利用することを記しておく。

ストリーミング巡回冗長チェック（ＣＲＣ）についての属性
データ・ブロックは、最小限のオーバーヘッドで保護しなければならない。イベント・ブロックに単純なＣＲＣ１６を用いれば、ブロックの保護には十分である。

ストリーミング・コマンド承認についての属性
個人健康医療デバイスの構成および制御に用いられるコマンド構造は、過度に複雑である必要はない。いずれのコマンドでも、パルスオキシメータのようなデバイスに送られる場合には、データ・パケットにおいて、適正な受信およびそのコマンドの処理の承認としてエコーされることが予見される。コマンドの機構についての論述は、本文書の範囲外のことである。

ＳｐＯ２脈拍範囲の限界離脱、バッテリ消耗、またはセンサ故障のようなデバイス特定のアラーム情報をここに記述することができる。

ストリーミング・デバイス・ステータスについての属性
トランスポート・ネットワーク内における同期の通知のようなデバイス特定のステータス情報は、このデータ・レコードのビットマップの中で表すことができる。

ストリーミング・センサ接続情報についての属性
センサについての情報は、ある実施形態では、このデータ・レコードの中に配置することができる。

ストリーミング・センサ記述情報についての属性
望ましければ、ある実施形態では、センサについての情報を増大してこのデータ・レコードの中に配置することができる。

ストリーミング時間報告についての属性
以下の２つの属性は、どこで時間およびデータ情報を検索することができるかを記述するために用いられる。

ストリーミング日付報告についての属性

ストリーミング・プレチスモグラフ・データ・サンプルについての属性
プレチスモグラフ(plethysmographic)データは、ストリーミング・データ・フォーマットと最も近く一致するデータ・タイプである。尚、データ・ブロック内では５バイト毎にこの属性が繰り返されることをここで記しておく。これがどのように関係するかについては、以下のペイロード・フォーマットを参照のこと。

ストリーミング・フレーム・カウンタについての属性
望ましければ、自由継続フレーム・カウンタを記述することができる。

簡潔性のために含ませないが、ＳｐＯ２および脈拍についてのアラーム限度設定値を報告するための追加属性も同様に記述する。

ストリーミングＳｐＯ２についてのペイロード
ストリーミング・データ送信のための固定サイズ・データ・ブロックは多くの利点を有する。
１つの利点は、波形データを発生する測定デバイスが、サンプル点のいずれもバッファする必要がない（そして恐らくはできない）ことである。これらは、取得された後殆ど直ちに送られる。固定ブロック・フォーマットに対する別の利点は、特定のデータ・レイアウトの予知を行う旧来のマネージャ・デバイス自体が自己記述機構の詳細に関わる必要がないことである。オフセット２および７に位置するバイトのような同期バイトを探し、オフセット８におけるフレーム・カウンタを探せば、旧来のマネージャに、正しい位置でデータを読み取っていることの合理的な確信を与える。今後の開発または内部診断の仕様のために、数個の予約バイトを用いてもよい。

高度エージェント１１０では、ストリーミング・ｒデータ・フォーマットを表すペイロード・タイプＰ１は、以前の属性定義を用いて記述した表のように見える場合がある。

標準的デバイスについての偶発的属性
デバイスの標準的能力はデバイスの特殊化では周知であるので、これらの要件のみに固執するデバイスは自己記述する必要はない。しかしながら、ある実施形態では、デバイスは自己記述することができる。
高度デバイスについての偶発的属性
偶発的データが要求された場合、１種類のＳｐＯ２および脈拍、ならびにパルス振幅、警報およびステータス・データ要素だけを送ればよい。尚、以下の表では、新たな位置付けを反映するために、バイト位置が変化していることを記しておく。以下の表は、偶発的データ・フォーマットが選択されたときに送られる。これらは、本質的に、ストリーミング・ｒデータ・フォーマットの部分集合であり、パケット・サイズが小さくなることを反映するために、バイト位置の選定(byte position location)が変化している。
高度偶発的ＳｐＯ２についての属性

高度偶発的脈拍についての属性

高度偶発的パルス振幅についての属性
この表は、以下の項目を示す。

高度偶発的アラームについての属性
表２９において、メトリック指定を用いて、アラーム・エンティティが２バイト値であることを暗示的に示している。加えて、アラームまたはステータス・ワードがビット方位定義を有することが多い。以下に数個の任意の例を提示する。多くは１ビット定義であり、不連続に位置付けられた３ビット値をどのように記述するかを示す例が１つある。追加のビット方位定義が含まれていない場合、この表も７バイトである。最悪の場合、１６個の１ビット定義が、各々、表における７バイトの用いると、基準アラーム・エンティティに加えて、１１２バイトを消費することになる。

いずれのステータス情報でも、以下の表において表すことができる。簡潔性のために、ＳｐＯ２に適用可能な１ビット方位定義が、追加の多ビットおよび１ビットのフィールド例と共に含まれている。このステータス・ビットは、配信するＳｐＯ２があらゆる平均化フィルタによってその最大能力まで計算および処理されたことを示す。

偶発的ヘッダのサイズ
あらゆるアラームおよびステータス・ビットが一意に定義されていると仮定すると、記述全てを送信するには３４８バイトを要する。アラームおよびステータスが散在的に配されている場合、記述全てを送信するために必要なバイトは減少する。

偶発的ＳｐＯ２のペイロード
本例におけるタイプＰ２のペイロードでは、偶発的フォーマットは以下のように出現するとよい。

メッセージング・フォーマット
本発明のメッセージング方式は、計算向けデバイスが実現できる程度に単純でありながら、双方向通信およびエラー・チェックを可能としエージェント１１０が合法的であるが誤形成(malformed)されたペイロードをマネージャ１３０に送ることを防止できる程度に柔軟性があることを意図している。

一実施形態では、５つのパケット・タイプがある。これら５つのパケット・タイプは、接続（ＣＮＣ）、分類（ＣＬＳ）、通信（ＣＯＭ）、確認（ＣＦＭ）、および制御（ＣＴＬ）を含む。これらのパケット・タイプは、本文書において先に論じた「データ・フロー相互作用）と整合することを意図している。一実施形態によれば、パケット・フォーマットは、ヘッダ・ブロック、ペイロード、および任意のＣＲＣブロックを含む。ヘッダ・ブロックは、２バイトから成り、パケット・タイプ、パケット長、および数個のフラグを記述するフィールドを有する。

一実施形態では、メッセージ・フォーマットは多数の有効なTYPEフィールドを含む。これら有効なTYPEフィールドは、3'b001 - CNC, 3'b010 - CLS, 3'b011 - COM, 3'b100-CTL,および3'b101-CFMを含む。ある実施形態では、RSVDビットを1'b0に設定しなければならない。

ＣＲＣビットがセットされるのは、特定のパケットが任意の巡回冗長チェックをイネーブルしている場合である。一実施形態では、ＣＲＣ方法は１タイプのみ（ＣＲＣ１６のような）が許され、これらのバイトはLENフィールドに含まれる。

一実施形態では、ＡＣＫビットがセットされるのは、確認パケットを必要とする場合である。TYPEが3'b101(CFM)に設定されている場合、パケットはこのビットをセットしておくことが許されない。しかしながら、他の実施形態では、CFMパケットがこのビットを用いることができる。ＡＣＫビットがセットされているＣＦＭパケットは、通例、直前のパケットが適正な応答を受信したことを意味し、ＡＣＫビットがクリアされているＣＦＭパケットは、ＮＯＡＣＫと同義とすることができる。

ＬＥＮフィールドは、このヘッダに続くバイト数を宣言する。ある実施形態では、ＬＥＮ値は０から１０２３までの範囲とすることができる。
接続：
先に論じたように、エージェント１１０はＣＮＣパッケージをマネージャ１３０に送る。一実施形態では、３種類の接続トランザクションが生じることができる。これらの接続トランザクションは、エージェント１１０が利用可能なマネージャ１３０であればいずれとでも接続することを望み、マネージャとは全く通信したことがない場合（トランザクションＩＤを有していない）（INTROサブタイプ）、エージェント１１０が最後に知ったマネージャと接続することを望み、トランザクションＩＤを有する場合（HAVE＿IDサブタイプ）、あるいはエージェント１１０がトランザクションＩＤを有するが、最後に知ったマネージャ１３０と通信しようとすることを諦めたい、または新たなマネージャと最初からやり直したい場合を含むことができる。ある実施形態では、長い通信タイムアウトのために同じマネージャと通信したいエージェント１１０と、新たな会話または接続を開始したいエージェント１１０との間には区別がある。

初期ＣＮＣパケット内にある情報は、エージェント１１０がサポートするプロトコルのレベルも含むとよい。
接続の間に、マネージャ１３０が、エージェントが保持するトランザクションＩＤと一致するトランザクションＩＤで応答した場合、以前に送ったもの（またはデフォルト）を送ればよい。

逆に、マネージャ１３０は、１日１回の読み取りのためにエージェントを起動したいときに、ＣＮＣパケットを送ることができる。しかしながら、１時間に１回、または３０分毎というような、他の時間期間も用いることができる。次いで、エージェント１１０は、送られるペイロードに対して正しいトランザクションＩＤで応答する必要がある。

注目すべき１項目は、これらメッセージ・タイプの多くが状態遷移を含むことである。これらの状態遷移は、ペイロード・ブロックの先頭に配置されている、サブフィールドとして表される。これは、基本データ・フォーマットをできるだけ簡素に抑えるためである。
分類：
これは、更に別の識別および可能な後続の自己記述のためのクエリが行われるところである。ＣＮＣパケット・タイプと同様、ペイロードの先頭は、分類の各段階に適用可能なサブタイプ・フィールドを収容する。これらの分類の例を２つ示す。

・REQ＿CLASS（マネージャ−＞エージェント）
・RSP＿CLASS（エージェント−＞マネージャ）
エージェント１１０が多機能デバイスである場合、多数のRESP＿CLASSメッセージで応答する必要がある場合もある。これらの分類は、プロトコル・エラーを報告することができる種々のＣＦＭパケットを用いる可能性が最も高い。しかしながら、他のパケット・タイプも用いることができる。
パケット通信：
生理的情報を収容するデータ・ペイロードは、このパケット・タイプで送られる。ＣＮＣおよびＣＬＳパケット・タイプと同様、ペイロードの先頭には、どのタイプのペイロードが送られているかを宣言する（分類段階において何が主張されるかに基づいて）サブタイプ・フィールドを収容する。
制御：
このパケットは数種類の目的に用いることができる。例えば、このパケットは、エージェントが非同期でマネージャに、停電が差し迫っていることを警告するために用いることができ、エージェントがマネージャに、ユーザが直接エージェント上の制御ボタンによって警報設定を構成し直したことを警告するために用いることができる。また、エージェント１３０は、例えば、新たな警報設定に応答するようにエージェントをプログラミングによって再構成するために、このトランザクション・タイプを開始することができる。また、制御パケットは、パケット通信を開始または停止するため、さらにはサービス品質（ＱｏＳ）を協議するために用いることもできる。
パケット確認：
一実施形態では、ＣＦＭパケットは２つの形態を取ることができる。第１形態は、ＡＣＫ／ＮＯＡＣＫのように、即ち、プロトコルまたはＣＲＣエラーをイニシエータ(initiator)に通知するためである。ＡＣＫ／ＮＯＡＣＫフォーマットは、ヘッダ・ブロックのみから成ることができる（ＬＥＮフィールドを０とすればよい）。それ以外の場合、パケット確認は、MDC＿CC＿COMM ERRORまたはMDC＿CC＿CRC＿ERRORのような、障害を記述する（通信パッケージからの）１１０７３〜１０１０１命名法の用語を用いて、リターン・ステータスを置くことができる。

以上、本発明およびその利点を詳細に説明したが、添付した特許請求の範囲によって定義した発明の趣旨および範囲から逸脱することなく、種々の変更、置換、および改変を行うことができる。更に、本願の範囲は、明細書に記載したプロセス、マシン、製造、物質の組成、手段、方法、およびステップの特定の実施形態に限定されることを意図してはいない。本発明の開示から当業者であれば容易に認められるように、現在存在する、あるいは今後開発され、個々に記載した対応する実施形態と実質的に同じ機能を実行する、または実質的に同じ結果を達成する、プロセス、マシン、製造、物質の組成、手段、方法、またはステップも、本発明にしたがって利用可能である。したがって、添付した特許請求の範囲は、その範囲に、このようなプロセス、マシン、製造、物質の組成、手段、方法、またはステップも含むことを意図している。

図１は、一実施形態によるシステムを示すブロック図である。 図２は、一実施形態によるデータ・フローを示すフロー・チャートである。

符号の説明

１１０ 個人健康エージェント
１２０ ワイヤレス・トランシーバ
１３０ マネージャ

Claims (1)

1. 実質的に添付図面を参照して先に記載したような医療システム。

Images