(57)【要約】  個人健康空間において、エージェント・デバイスに応答してマネージャ・デバイスの適応的構成変更を可能にするシステムおよび方法。マネージャ・デバイスは、エージェント・デバイスへの照会およびエージェント・デバイスからの照会に応答してそれ自体を構成することができる。この構成は、エージェント・デバイスの複雑度に基づくことができる。エージェント・デバイスは、標準フレームワークと高度フレームワークとの間で変化することができる。２つのデバイス間の通信は、有線接続または無線接続上で行われる。【選択図】図３
2010518891.tif 000002
【特許請求の範囲】
【請求項１】
個人健康空間内で用いるために構成された可搬型エージェント・デバイスであって、患者と関連した生理学的データを入手し、１つ以上のフレームワーク内において動作する、エージェント・デバイスと、
前記生理学的データを受信するために前記エージェント・デバイスと通信するマネージャ・デバイスであって、患者に呈示するためまたは他のデバイスに送信するために前記生理学的データを処理し、前記エージェント・デバイスへの照会および前記エージェント・デバイスからの照会に応答して構成可能な、マネージャ・デバイスと、
を備えた、システム。
【請求項２】
請求項１記載のシステムにおいて、前記１つ以上のフレームワークは、標準フレームワークと高度フレームワークとを含む、システム。
【請求項３】
請求項１記載のシステムにおいて、前記エージェント・デバイスとマネージャ・デバイスとの間の通信は、有線接続または無線接続を経由する、システム。
【請求項４】
請求項１記載のシステムにおいて、前記マネージャ・デバイスは、前記エージェント・デバイスの複雑度に基づいて構成可能である、システム。
【請求項５】
請求項１記載のシステムにおいて、前記エージェント・デバイスは、更に、患者に関する活動情報を入手する、システム。
【請求項６】
個人健康データ送信システムであって、
個人患者健康管理空間内において患者から生理学的データを入手するように各々構成された複数のエージェント・デバイスであって、標準エージェント・デバイスと高度エージェント・デバイスとを含み、前記標準エージェント・デバイスは、前記高度エージェント・デバイスと比べデータ収集能力が限られた、複数のエージェント・デバイスと、
前記複数のエージェント・デバイスの１つ以上から前記生理学的データを受信するように各々構成された複数のマネージャ・デバイスであって、標準マネージャ・デバイスと高度マネージャ・デバイスとを含み、前記標準マネージャ・デバイスは、前記高度マネージャ・デバイスと比べデータ通信能力が限られた、複数のマネージャ・デバイスと、
を備えた、個人健康データ送信システム。
【請求項７】
請求項６記載のシステムにおいて、標準エージェント・デバイスは標準ペイロードをサポートし、前記ペイロード構造の数値およびフォーマットを指定するために、デバイス／データ特殊化に頼る、システム。
【請求項８】
請求項７記載のシステムにおいて、前記数値は、脈拍酸素濃度計からのＳＰ０２および脈拍数を含む、システム。
【請求項９】
請求項７記載のシステムにおいて、高度ペイロードは、前記標準ペイロード以外にもペイロードを含む、システム。
【請求項１０】
請求項９記載のシステムにおいて、高度ペイロードは、前記複数のマネージャ・デバイスの１つ以上が、前記高度ペイロード内にある情報を解析することを可能にする自己記述子によってサポートされる、システム。
【請求項１１】
個人健康データ送信システムであって、
個人健康空間内において用いるために構成された標準エージェント・デバイスであって、患者と関連した生理学的データを入手する、標準エージェント・デバイスと、
前記生理学的データの前記マネージャ・デバイスへの伝達に先立つ前記標準エージェント・デバイスの記述を含むマネージャ・デバイスであって、前記記述が、前記通信を容易にするために、前記標準エージェント・デバイスに関するデータ送信情報を含む、マネージャ・デバイスと、
を備えた、個人健康データ送信システム。
【請求項１２】
請求項１１記載のシステムにおいて、前記マネージャ・デバイスは、患者に呈示するためまたは他のデバイスに送信するために、前記生理学的データを処理する、システム。
【請求項１３】
請求項１１記載のシステムにおいて、前記マネージャ・デバイスは高度エージェントとも通信する、システム。
【請求項１４】
請求項１３記載のシステムにおいて、前記高度エージェント・デバイスは、データ送信の前に、自己記述が可能である、システム。
【請求項１５】
請求項１４記載のシステムにおいて、前記マネージャ・デバイスは、前記高度エージェント・デバイスへの照会および前記高度エージェント・デバイスからの照会に応答して構成可能である、システム。
【請求項１６】
請求項１３記載のシステムにおいて、前記マネージャ・デバイスが後続のデータ・ストリームをどのように処理するか決定するために、前記高度エージェント・デバイスから前記マネージャ・デバイスに自己記述子を送る、システム。
【請求項１７】
請求項１６記載のシステムにおいて、前記自己記述子は、デバイス記述を含む、システム。
【請求項１８】
請求項１６記載のシステムにおいて、前記自己記述子は、ペイロード記述を含む、システム。
【請求項１９】
請求項１８記載のシステムにおいて、前記ペイロード記述は、ペイロードサイズ情報を含む、システム。
【請求項２０】
個人健康データ送信システムであって、
個人健康空間内において用いるために構成された複数のエージェント・デバイスであって、各々、患者と関連した生理学的データを入手する、複数のエージェント・デバイスと、
前記複数のエージェント・デバイスの１つ以上から前記生理学的データを受信するように各々構成された複数のマネージャ・デバイスであって、前記複数のエージェント・デバイスおよび前記複数のマネージャ・デバイスは、標準化フレームワークと高度フレームワークとを含む規定フレームワーク内で動作し、前記標準化フレームワークは、データ送信についての最小の数値およびフォーマット集合によって定められ、前記マネージャ・デバイスが、自己記述の必要なく、前記標準化フォーマット内で動作するエージェント・デバイスと通信するように構成された、複数のマネージャ・デバイスと、
を備えた、個人健康データ送信システム。
【請求項２１】
請求項２０記載のシステムにおいて、高度エージェント・デバイスが、前記複数のマネージャ・デバイスの１つ以上に、能力を自己記述する、システム。
【請求項２２】
請求項２０記載のシステムにおいて、高度エージェント・デバイスが、標準化エージェント・デバイスによって伝達される標準化データ以外にもデータを伝達する、システム。
【請求項２３】
請求項２０記載のシステムにおいて、前記高度フレームワーク内のマネージャ・デバイスは、前記標準化フレームワーク内におけるマネージャ・デバイスの能力以外にも能力を含む、システム。
【請求項２４】
請求項２３記載のシステムにおいて、前記高度フレームワーク内の前記マネージャ・デバイスは、エージェント・デバイスの区別が可能である、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本願は、３５Ｕ．Ｓ．Ｃ１１９（ｅ）に基づき、２００７年１月３日に出願した仮米国特許出願第６０／８７８，５７１号の優先権を主張する。
【０００２】
本発明は、データ通信に関し、更に特定すれば、個人健康空間(personal health space)内における１対のデバイス間で伝達する医療関係データに関する。
【発明の概要】
【０００３】
本発明は、個人健康空間内において、エージェント・デバイスに応答するマネージャ・デバイスの適応的構成を可能にするシステムおよび方法を対象とする。マネージャ・デバイスは、エージェント・デバイスへの照会およびエージェント・デバイスからの照会に応答してそれ自体を構成することができる。この構成は、エージェント・デバイスの複雑度に基づくことができる。エージェント・デバイスは、標準的なフレームワークと高度フレームワークとの間で様々に変化することができる。マネージャ・デバイスとエージェント・デバイスとの間の通信は、有線接続または無線接続上で行われる。
【０００４】
以上では、以下に続く本発明の詳細な説明をより深く理解できるようにするために、本発明の特徴および技術的利点の概要をどちらかと言うと広く述べた。本発明の特許請求項を形成する本発明の追加の特徴および利点については、以下で説明する。尚、開示する概念および具体的な実施形態は、本発明の同じ目的を遂行するために他の構造を修正または設計するための基礎として容易に利用することができることは当業者には認められてしかるべきである。また、このような同等な構造は、添付した特許請求の範囲に明記する本発明の主旨および範囲から逸脱しないことも、当業者には認められてしかるべきである。本発明の特徴であると確信する新規の特徴は、その編成および動作方法に関してであるが、他の目的および利点と共に、添付図面と合わせて検討すれば以下の説明からより深く理解できよう。しかしながら、図の各々は、例示および説明の目的で提示するに過ぎず、本発明の限度の定義として意図しているのではないことは、言うまでもないのは明らかであろう。
【図面の簡単な説明】
【０００５】
本発明の一層の完全を期した理解のために、これより添付図面と関連付けて、以下の説明を参照する。図面において、
【０００６】
【図１】図１は、一実施形態によるシステムを示すブロック図である。
【図２】図２は、一実施形態によるデータ・フローを示す、フロー・チャートである。
【図３】図３は、標準的な脈拍Ｏｘとマネージャ・デバイスとの間における相互作用の図である。
【図４】図４は、高度脈拍Ｏｘとマネージャ・デバイスとの間における相互作用の図である。
【発明を実施するための形態】
【０００７】
本発明のアーキテクチャについて詳細に論ずる前に、個人健康（ＰＨ）デバイスの一般的な動作環境、および診療空間(clinical space)と個人健康空間との間におけるデータ・フローの微妙な相違について説明するのは有用である。比較を容易にするために、データ・フローは、医療診断（例えば、脈拍、収縮期圧、デバイス精度、デバイス解像度等）を行うために必要なデータ、および医療データ周囲のメセージング・ラッパ(messaging wrapper)（例えば、取り込み／設定メセージング・デバイス能力／属性等）のような連携メタデータに分割することができる。
・診療医療データ対ＰＨ医療データ
【０００８】
介護提供者は、一般に、データの医療的な面を区別したがらない。具体的には、介護提供者は、一般に、このデータが家庭、診療所、病院、または他の任意の場所のどこで捕獲したのか区別する必要がない。介護提供者は、一般に、データおよびデバイスの効果的な診断および相互動作可能性を可能にするために、収集した医療データの品質、信頼性、安全性、および命名法が同一であることを望む。
・診療関連メタデータ対ＰＨ関連メタデータ
【０００９】
診療環境では、エージェント・デバイス（例えば、脈拍酸素濃度計）が異なる部屋および／または患者間で頻繁に用いられる。エージェント・デバイスによって捕獲されたデータは、エージェント・デバイスが部屋および患者間で変化するに連れて、数個の異なるマネージャ・デバイス（例えば、生存徴候モニタ）上に表示することができる。
これらのデバイスの使用を様々な異なる用途および患者状態に拡大する環境においてこれらが相互に動作するためには、何らかの「人工知能」をエージェント・デバイスおよびマネージャ・デバイスに用意する。このインテリジェンスの目標は、エージェント・デバイスとマネージャ・デバイスとの間にリンクまたはその他の接続がセットアップされる毎に、これらのデバイスがそれら自体を適正に識別することを保証することである。実施形態によっては、デバイスが、用途による要件に応じて、それら自体を再構成して、しかるべきデータを送信することができる。しかしながら、ＰＨ空間におけるエージェント・デバイスは、患者の家庭において非常に小さいリストのマネージャ・デバイス（例えば、家庭用ＰＣ、セット・トップ・ボックス、セル・フォン等）に通信する可能性が高く、したがって再構成可能性については、必要性が限られる。ＰＨ空間において用いられるエージェント・デバイスは、診療環境におけるエージェント・デバイスと比較すると、比較的簡素にすることができる。一旦エージェント・デバイスが後続のセッションのためにそれ自体をマネージャ・デバイスに導入すると、しなければならないのは、ポールされたときにデータを送信することだけである。
【００１０】
尚、診療上の設定では、デバイスは一般に、訓練を受けた有能な専門家によって取り扱われ手入れが行われる(service)。一方、ＰＨ空間では、デバイスは、患者または訓練や認識能力が限られているその他の人でも用いることができる程に単純であることが望ましい。
【００１１】
図１は、本発明の態様を実現することができる環境を示すブロック図である。システム１００は、個人健康エージェント・デバイス１１０、有線または無線送受信機１２０、マネージャ・デバイス１３０、および第２有線または無線送受信機１４０を含む。この説明は１つのエージェント・デバイス１１０および１つのマネージャ・デバイス１３０に言及するが、本発明は、１つよりも多いエージェント・デバイス１１０またはマネージャ・デバイス１３０を用いても実現可能であることは、当業者であれば容易に認められよう。
【００１２】
個人健康エージェント・デバイス１１０は、一実施形態では、脈拍酸素濃度計である。しかしながら、体温計、血圧モニタ、心電図（ＥＫＧ）、脳波図（ＥＥＧ）、体重計、あるいは人または動物に適したその他の生理および活動監視デバイスのような、その他のデバイスでも用いることができる。しかしながら、実施形態によっては、個人健康エージェント・デバイス１１０は、静脈内薬剤の流れを許容または制御するというような、ある種の医療的処置を患者に提供するように構成することもできる。前述のように、ＰＨエージェント・デバイス１１０は、比較的単純でよく、所望の機能を実行しマネージャ・デバイス１３０と通信するための最少量の構造または動作上のオーバーヘッドだけでよい。ＰＨエージェント・デバイス１１０の具体的なコンポーネントは、エージェント・デバイス１１０の機能性に応じて様々である。
【００１３】
個人健康エージェント・デバイス１１０の動作は、２つの異なるフレームワーク、即ち、標準フレームワークおよび高度フレームワークに分割することができる。標準フレームワークでは、エージェント・デバイス１１０は、所定のフォーマットとした最小のデータ集合を伝達することができる。例えば、キログラムまたはポンドを単位とした体重を伝達するように体重計を構成する。
【００１４】
高度フレームワークでは、エージェント・デバイス１１０は、最小のデータ集合に加えて、追加データを送信するように構成される。追加データは、例えば、エージェント・デバイス１１０同士で区別することができる。一例では、エージェント・デバイス１１０は、マネージャ・デバイス１３０に対してその属性を自己記述するように構成されている。実施形態によっては、この識別は大域的な一意の識別子（ＧＵＩＤ）を用いて行うことができ、あるいは階層的手法を用いて行うことができる。しかしながら、他の識別方法を用いることもできる。実施形態によっては、エージェント・デバイス１１０には高度な機能性が設けられる。例えば、体重計は、マネージャ・デバイス１３０に、キログラムまたはポンド単位の体重、および体脂肪率データを伝達するように構成することができる。
【００１５】
マネージャ・デバイス１３０は、エージェント・デバイス１１０からの信号を処理する。一実施形態では、マネージャ・デバイス１３０はパーソナル・コンピュータである。しかしながら、他の実施形態では、マネージャ・デバイス１３０は、セル・フォン、セット・トップ・ボックス、パーソナル・ディジタル・アシスタント、あるいはエージェント・デバイス１１０からの情報を処理し、表示し、または上流デバイスに転送することができる他の任意のデバイスとすることもできる。マネージャ・デバイス１３０は、エージェント・デバイス１１０から情報を受信し、一例では、その情報を、医療要員が読むことができる、読み取り可能な表示に変換する。しかしながら、別の実施形態では、マネージャ・デバイス１３０は受信した情報をプロトコルに変換して遠隔サイトに送り、そこでデータを検討することもできる。加えて、実施形態によっては、標準フレームワークまたは高度フレームワークのいずれかにおけるエージェント・デバイス１１０の動作からの情報を扱うようにマネージャ・デバイス１３０を構成する場合もある。
【００１６】
送受信機デバイスを利用して、エージェント・デバイス１１０とマネージャ・デバイス１３０との間で通信を行う。エージェント・デバイス１１０は送受信機１２０を有し、マネージャ・デバイス１３０は送受信機１４０を有する。本論述は送受信機１２０および１４０に言及するが、これらは送信機、受信機、またはその任意の組み合わせでも可能であることは、当業者であれば認められよう。送受信機１２０および１４０は、周知の無線プロトコルまたは有線プロトコルのいずれでも利用することができる。例えば、送受信機１２０および１４０は、Bluetooth、ＩＲ、ＩＥＥＥ８０２．１１、ＧＰＲＳ、ＧＳＭ、ＷＭＴＳ、ＩＥＥＥ８０２．１５．４（ＺｉｇＢｅｅ）、ＵＳＢ、またはエージェント・デバイス１１０とマネージャ・デバイス１３０との間でデータを送信するための他の任意のプロトコルも用いることができる。
【００１７】
前述のフレームワークの利点には、標準的な命名法の使用、デバイス・フォーマットおよび能力の自己記述、連続的（streaming）転送モード、一時的(episodic) 転送モードまたは一括転送モード、ならびに低オーバーヘッドが含まれる。
【００１８】
前述のように、エージェント・デバイス１１０は、実施形態によっては、標準フレームワークまたは高度フレームワークの中で動作することができる。以下の論述の目的に合わせて、エージェント・デバイス１１０は人または動物における血液の酸素投与レベルを決定することができる脈拍酸素濃度計とする。標準フレームワークでは、脈拍酸素濃度計は、連続的ＳｐＯ２および一時的ＳｐＯ２、ならびに脈拍データを供給する。高度フレームワークでは、脈拍酸素濃度計は、連続的ＳｐＯ２および一時的ＳｐＯ２、脈拍データ、ならびに脈拍品質、平均心拍間時間(beat to beat average)またはその他のメトリックを供給する。
【００１９】
標準フレームワークでは、エージェント・デバイス１１０とマネージャ・デバイス１３０との間でデータを送信する前に、データ・フロー相互作用を定める。データ・フロー相互作用をセットアップするために、エージェント・デバイス１１０およびマネージャ・デバイス１３０は初期接続をセットアップする。この接続を行った後、双方のデバイス１１０および１３０は接続指示を出し、必要であれば、それらの広域一意識別し（ＧＵＩＤ）またはその他の識別手段を交換する。一旦接続がセットアップされＩＤが交換されたなら、マネージャ・デバイス１３０はエージェント・デバイス１１０からの分類情報を要求する。エージェント・デバイス１１０が標準フレームワークで動作しているので、標準脈拍酸素濃度計というような、そのデバイス部類を回答する。次いで、マネージャ・デバイス１３０は、関連する命名法および統語構造(syntax)が標準脈拍酸素濃度計に入手可能か否か確認するためにチェックする。一旦このチェックが完了したなら、マネージャ・デバイス１３０は脈拍酸素濃度計１１０にそのペイロード・データを送る指令を送る。この時点において、サービス品質（ＱｏＳ）の取り決めを含む、一連の取り決めまたはその他の通信プロトコルが生ずる。この追加の取り決めが完了すると、エージェント・デバイス１１０およびマネージャ・デバイス１３０は双方ともペイロード・データを送信および受信する準備が整う。エージェント・デバイス１１０がペイロード・データを発生した後、エージェント・デバイス１１０はデータ・ペイロードをマネージャ・デバイス１３０に送信する。次いで、マネージャ・デバイス１３０はこのデータを処理し、他に必要な動作があればいずれでも実行する。デバイスの意図的なまたは意図しない切断の場合、種々の理由で起こる可能性があるが、エージェント・デバイスおよびマネージャ・デバイスは互いに再接続しようとする。再接続の間、デバイスは再度それらの固体情報(identification)を交換する。再識別、および接続が条件を満たすことを確認するチェックの後、エージェント・デバイス１１０はマネージャ・デバイス１３０に応答するか、またはデフォルトのペイロードをマネージャ・デバイス１３０に返送しようとする。
【００２０】
高度フレームワークは、標準フレームワークと同様に接続をセットアップする。しかしながら、完璧を期す目的に合わせて、再度そのプロセスを繰り返す。一層明らかにこのプロセスを参照するために、図２は、一実施形態にしたがって、接続の間に実行するステップ、および高度フレームワークにおけるデータ・フローを示す流れ図である。ステップ２１０において、トランスポート・レイヤはエージェント・デバイスとマネージャ・デバイスとの間に接続をセットアップし、接続指示を双方のデバイスに供給する。このステップにおいて、双方のデバイス１１０および１３０に互いのＧＵＩＤ（例えば、BluetoothＭＡＣアドレス等）も伝える。
【００２１】
ステップ２１５において、マネージャ・デバイス１３０はエージェント・デバイスの分類を要求する。エージェント・デバイス１１０が、血圧のような別の生理種別もサポートする場合、分類は、それに応じて、血圧が標準かまたは高度かを、連続的かまたは一時的(episodic)かと共に示す。エージェント・デバイス１１０は、ステップ２２０において、その部類リストを返送して回答する。
【００２２】
マネージャ・デバイス１３０は、エージェント・デバイス１１０の能力を解析し処理することができるか否か確認するためにチェックする。これをステップ２２５に示す。マネージャ・デバイス１３０が高度機構を解釈することができる場合、マネージャ・デバイス１３０は、ステップ２３０において、特定のデータ集合（この例では、拡張ペイロードＰ１）について、エージェント・デバイス１１０からの自己記述子を要求する。エージェント・デバイス１１０は、Ｐ１についてのその自己記述子を回答する。自己記述子は、ペイロード・フォーマット、ペイロード・フォーマット内に埋め込まれているメトリック、および特定のメトリック各々についてのあらゆる支援情報を記述する。これをステップ２３５に示す。
【００２３】
マネージャ・デバイス１３０は、自己記述子を検討し、統語構造および命名法が準拠していることを確認する。続いて、マネージャ・デバイス１３０に常駐するアプリケーションが、どのペイロード（この場合、ペイロードＰ１が望ましい）かについてエージェント・デバイス１１０に指図し、そのアプリケーションに必要なサービス品質（以後「ＱｏＳ」）を指定する。これをステップ２４０に示す。
【００２４】
エージェント・デバイス１１０およびマネージャ・デバイスは、容認可能なＱｏＳについて取り決める。これをステップ２４５に示す。
【００２５】
エージェント・デバイス１１０は、続いて、停止要求がなされるまで、ペイロードＰ１を送信する。これをステップ２５０に示す。接続に意図した欠落または意図しない欠落があった場合、有線または無線トランスポート・プロトコルはリンクを再度開始する責務がある。一旦リンクがセットアップされたなら、エージェント・デバイスおよびマネージャ・デバイスは、自己記述子を再度送ることなく、これらが以前に接続されていたことを（ＧＵＩＤに基づいて）認識する。次いで、エージェント・デバイス１１０はデフォルト・ペイロードのマネージャ・デバイス１３０への返信に移る。実施形態によっては、マネージャ・デバイス１３０から受信した信号に応答して、エージェント・デバイス１１０が異なるペイロード、例えば、ペイロードＰ２を送ることができる。
【００２６】
図３は、標準エージェント・デバイス１１０（脈拍酸素濃度計）とマネージャ・デバイス１３０との間における相互作用を示す。
【００２７】
図４は、ＳｐＯ２データを転送するための、高度エージェント・デバイス１１０（脈拍酸素濃度計）とマネージャ・デバイス１３０との間における相互作用を示す。
【００２８】
トランスポート・レイヤ４００は、エージェント・デバイス１１０とマネージャ・デバイス１３０との間に接続をセットアップし、接続指示を双方のデバイスに供給する。また、互いの大域一意ＩＤ（例えば、Bluetooth ＭＡＣアドレス等）も双方のデバイスに伝える。
【００２９】
マネージャ・デバイス１３０は、ステップ４１２において、エージェント・デバイスの分類を要求する。デバイスが他の生理種別、例えば、血圧もサポートする場合、分類は、それに応じて、ＢＰが標準かまたは高度かを、連続的かまたは一時的かと共に指示する。エージェント・デバイス１１０は、ステップ４１４において、回答しその部類を返送する。マネージャ・デバイス１３０は、ステップ４１６において、それが高度能力を解析することができるか否か確認するためにチェックする。実際にそうである場合、マネージャ・デバイス１３０は、ステップ４１８において、特定のデータ集合（この例では、連続的ペイロードＰ１）に付いての自己記述子を要求する。エージェント・デバイス１１０は、ステップ４２０において、Ｐ１に対するその自己記述子を回答する。自己記述子は、ペイロード・フォーマットおよびメトリックを記述する。マネージャ・デバイス１３０は、自己記述子を検討して、統語構造および命名法が準拠することを確認する。マネージャ・デバイスに常駐するアプリケーションは、当該アプリケーションに必要なＱｏＳを指定する。エージェント・デバイスおよびマネージャ・デバイスは、ステップ４２２において、容認可能なＱｏＳを取り決める。ステップ４２４において、エージェント・デバイス１１０は、続いて、ペイロードＰ１を送信し、そうするのを止めるように要求されるまで続ける。
【００３０】
接続に意図した欠落または意図しない欠落があった場合、トランスポート・レイヤはリンクを再開し、接続指示を供給する責務がある。一旦リンクが設定された場合、エージェント１１０およびマネージャ１３０はここでは、以前にこれらが接続したステップ４２６において（トランスポートＩＤに基づいて）再接続するので、自己記述子を再度送ることなく、エージェントは、ステップ４２８に進んでデフォルト・ペイロードを送信する。
【００３１】
ステップ４３０に示すように、マネージャ・デバイスが、任意の時点において、それが要求したデータを変更したい場合、別の要求を送ることと選択することができる。セッションは、ステップ４３２において閉鎖される。
【００３２】
本発明の適応的な側面を最適化するために、一例では、マネージャ・デバイス１３０は、標準エージェント・デバイスによって伝達されたデータを、「ドライバ」や自己記述を必要とせずに認識し解釈する。高度エージェント・デバイス１１０は、その能力、特に標準デバイス・フォーマットとの相違を自己記述する必要がある。また、マネージャ・デバイス１３０を標準および高度に分類することもできる。標準マネージャ・デバイスは、インテリジェンスが制限されており、エージェント・デバイスにおける標準能力とでなければ通信することができない。高度マネージャ・デバイスは、標準マネージャ・デバイスの能力の上に、更にそれを超えていく選択肢を有し、デバイスの区別、改良を容易にし、改革を促進する。表１は、標準および高度エージェント・デバイスとマネージャ・デバイスとの間の相違の内訳を手短に示す。
【表１】
2010518891.tif 000003
【００３３】
実施形態によっては、標準ペイロードが標準エージェント・デバイス１１０によってサポートされており、データ（例えば、ＳｐＯ２、脈拍Ｏｘにおける心拍数）およびペイロード構造のフォーマットを指定するために、デバイス／データ特殊化(specialization)に頼る場合もある。別の実施形態では、高度ペイロードは、標準ペイロードにつけ加えたペイロードであり、マネージャ・デバイス１３０に情報を解析させる自己記述子によってサポートされる。
【００３４】
これより、標準フレームワーク・エージェント・デバイス１１０を再度参照し、エージェント・デバイスについての連続的属性についてここで論ずる。エージェント・デバイス１１０の標準能力はマネージャ・デバイス１３０には分かっているので、エージェント・デバイス１１０がその既往を接続プロセスの間に自己記述する必要はない。デバイスがそれ自体の記述をマネージャ・デバイス１３０に与える必要がないので、測定特性の詳細なリストをデバイス特殊化ファイルにおいて提供することができる。表２は、一実施形態による一例であり、脈拍酸素濃度計エージェント・デバイス１１０が提供することができるデータの一部を略述する。
【表２】
2010518891.tif 000004
【００３５】
これより高度フレームワークを再度参照すると、高度能力を有するエージェント・デバイス１１０は、その能力およびその送信プロトコルまたはその他の属性の双方を送信した後でなければ、いずれのペイロードも送らない。
【００３６】
高度エージェント・デバイス１１０では、標準化した命名法（例えば、ＩＳＯ／ＩＥＥＥ１１０７３−１０１０１命名法）を利用して、自己記述子を一連の表として記述することができ、拡張子は、時間同期イベント報告のような、広範囲にわたる脈拍酸素濃度計および能力に関する。しかしながら、他の手法を用いることもできる。自己記述子は、マネージャ・デバイス１３０が後続のデータ・ストリームをどのように処理するか決定するために、エージェント・デバイス１１０からマネージャ・デバイス１３０に送ることができる。
【００３７】
一実施形態では、自己記述子は、デバイス記述（そのモデル、チャネル数、ＱｏＳ能力等に関する）、およびサイズ、場所、またはその他の情報を含むペイロード記述を含む。
【００３８】
自己記述子の利点の１つは、これを「静的パッチ」(static patch)として実施できることである。静的パッチは、基本的には、デバイスおよびその能力を照会する。一例では、自己記述子を送るのは、高度エージェント・デバイス１１０がそれ自体をマネージャ・デバイス１３０に最初に紹介するとき（または具体的に尋ねられるまで）だけである。これは、ＸＭＬまたはその他の標準化した記述プロトコルには、容易に移植することができる。
【００３９】
以下の表は、記述メッセージとして送る自己記述属性を提案する。現在定められていない用語または未定の用語は、これらの表では斜字体となっている。これらの表は、現在用いられている製品と同様の脈拍酸素濃度計の一例の医療データ属性の殆どを記述する。表の一部は、特定の酸素濃度計を記述するために必要とされるデータの例を与えるために提示する。尚、フォーマットはＩＳＯ−ＩＥＥＥ１１０７３−１０２０１（ドメイン情報モデル）およびＩＳＯ／ＩＥＥＥ１１０７３−１０１０１（命名法）における素材(material)と同様であるが、内容は必ずしも論述の対象となる特定のモデルに完全に該当することは意図していないことを注記しておく。この論述の範囲を制限するために、これらの属性は、連続的ペイロードに適用可能とし、一時的ペイロード・タイプ、ペイロードＰ１およびＰ２を例として提示する。
連続的ＳｐＯ２についての属性−主要
【００４０】
表３は、酸素濃度計の最も広く用いられている酸素飽和測定を報告するための属性を記述する。各メトリックには仕様が関連し、属性キーは通常関連値を有する。この場合、仕様キーはニモニックMDC_ATTR_METRIC_SPECNであり、その関連値はMDC_METRIC_O2_SAT_NORMである。尚、このニモニック値は現在の命名法の拡張であることを注記しておく。次の属性は、データ・ペイロードにおける特定のエレメントの場所に関する。これ以上の詳細については、以下で論ずるペイロード・フォーマットを参照のこと。尚、このメトリック内では、メトリック・タイプを２バイト整数／端数値対として記述することが言外に含まれており、最初のバイトが整数部であり、２番目のバイトが１／１０単位で表す端数部であることを注記しておく。データ・タイプを仕様によって暗示的に記述することにより、リストのサイズを縮小することができる。加えて、標準データ・タイプについて確定しているどの属性もこの表に代入することができる。暗示的に記述した最後のエレメントは、確定したMDC_ATTR_TIME_PD_AVG属性の修正であり、平均値を計算する際に用いられる時間間隔を記述する。別の平均化式を表現する必要がある場合、属性表が大きくなるという代償を払うが、その属性も含むことができる。
【００４１】
表３は、ＳｐＯ２の主要な表現である。メトリック仕様が暗示的にデータ・サイズ、タイプ、および平均化方法を記述する場合、この表のサイズを小さくすることができる。再度注記するが、繰り返し間隔は適用できないので、デフォルト値を０と見なし、必要でない限り含まれないこととする。
【表３】
2010518891.tif 000005
連続的ＳｐＯ２についての属性−緩速挙動(slow-acting) 
【００４２】
この第２メトリックは、ＳｐＯ２における素早い変化を抑制することが有利な状況において用いるために提供可能なＳｐＯ２計算を記述する。尚、バイト位置は変化することを注記しておく。この場合も、データ・タイプおよび計算方法を暗示的に記述するためにMDC_METRIC_O2_SAT_LONG仕様を用いる。
【表４】
2010518891.tif 000006
連続的ＳｐＯ２についての属性−高速挙動（fast-acting)  
【００４３】
更に別のＳｐＯ２測定方法では、ＳｐＯ２における極度に素早い変化も表現することが可能である。これ以降の表では、測定情報はメトリック仕様値に言外に含まれていることを仮定する。この表では、追加の（そして任意の）キー＝値対が、ここではデータ・サイズおよびデータ・タイプに関して含まれることは注記に値する。これらは、仕様のデフォルト・キー／値の対が、明示的属性によっていかにして無効にされ得るかという例として示されている。
【表５】
2010518891.tif 000007
連続的ＳｐＯ２についての属性−心拍間（フィルタ処理せず）
追加の計算を用いない場合を表現するために、表５を送ることができる。
【表６】
2010518891.tif 000008
連続的ＳｐＯ２についての属性−主要である他に表示に適している
ＳｐＯ２は、読むことができるような方法で表示しなければならない。最後の属性、メトリック更新間隔は、マネージャ・デバイス１３０に、酸素濃度計がこの値を所定の周期性で更新することを伝えるために提案する。
【表７】
2010518891.tif 000009
連続的ＳｐＯ２についての属性−緩速挙動であるが表示に適している
【００４４】
同様に、表示に適した緩速挙動ＳｐＯ２も、そのように表示することができる。
【表８】
2010518891.tif 000010
連続的脈拍数についての属性−主要
【００４５】
様々な方法で脈拍数を測定して表示する。次の４つの表（表９から表１２）は、ＳｐＯ２測定に類似している。
【表９】
2010518891.tif 000011
連続的脈拍数についての属性−緩速挙動
【表１０】
2010518891.tif 000012
連続的脈拍数についての属性−主要である他に表示の目的に適している
【表１１】
2010518891.tif 000013
連続的脈拍数についての属性−緩速挙動であるが表示の目的に適している
【表１２】
2010518891.tif 000014
連続的脈拍振幅についての属性
【００４６】
実施形態によっては、脈拍酸素濃度計が脈拍品質の何らかの尺度を表現することが有用な場合がある。音調(note)の属性はMD_ATTR_MODE_MSMTであり、異なる販売業者が彼ら自身の２バイト・メトリック測定値を提供することを可能にする。ここでは、データ記述を更に多くすることが妥当な場合もある。これは、MDC_METRIC_PULSE_QUAL属性によって暗示的に定められる２バイトは、脈拍発生ステータス、特徴化ニモニック、またはインデックス数値の組み合わせとして用いることができるからである。
【表１３】
2010518891.tif 000015
連続的時間同期イベント報告についての属性
【００４７】
この属性は、時間同期イベント報告についてのキー・オブジェクトである。３バイトのMDC_TYPE_EVENTRECと称するデータ記述は、PULSE_OCCURREDのようなイベント・タイプと、イベントが発生したオフセットをミリ秒で示す２バイトとの組み合わせであると見なすことができる。尚、データ・ブロック値２つのイベントの容量があるので、これはメトリック繰り返し間隔を利用することを注記しておく。
【表１４】
2010518891.tif 000016
連続的巡回冗長チェック（ＣＲＣ）についての属性
【００４８】
データ・ブロックは、最小限のオーバーヘッドで保護すべきである。ブロック全体に対して単純なＣＲＣ１６を用いれば、ブロックにとって十分な保護となる。
【表１５】
2010518891.tif 000017
連続的コマンド承認についての属性
【００４９】
個人健康医療デバイスの構成設定および制御に用いられるコマンド構造は、過度に複雑である必要はない。脈拍酸素濃度計のような、このようなデバイスに送られるコマンドはいずれも、当該コマンドの適正な受信および処理の承認として、データ・パケットにおいてエコーすることが想像される。コマンドのメカニズムの論述は、本文書の範囲には入らない。
【表１６】
2010518891.tif 000018
連続的デバイス・アラームについての属性
【００５０】
ＳｐＯ２心拍数限度の境界からの離別(leaving)、バッテリの故障、またはセンサの故障というような、デバイス特定アラーム情報について、ここで記述することができる。
【表１７】
2010518891.tif 000019
連続的デバイス・ステータスについての属性
【００５１】
トランスポート・ネットワーク内における同期の通知のような、デバイス特定ステータス情報は、このデータ記録におけるビットマップ内部で表現することができる。
【表１８】
2010518891.tif 000020
連続的センサ接続情報についての属性
【００５２】
実施形態によっては、センサに関する情報をこのデータ・レコードに入れることができる。
【表１９】
2010518891.tif 000021
連続的センサ記述情報についての属性
【００５３】
望ましければ、実施形態によっては、センサに関する追加情報も、このデータ・レコードに入れることができる。
【表２０】
2010518891.tif 000022
連続的時間報告についての属性
【００５４】
以下の２つの属性は、時間およびデータ情報を読み出すことができる場所を記述するために用いられる。
【表２１】
2010518891.tif 000023
連続的日付報告についての属性
【表２２】
2010518891.tif 000024
連続的体積変動記録データ・サンプルについての属性
【００５５】
体積変動記録データは、連続的データ・フォーマットと最も密接に一致するデータ・タイプである。ここで、データ・ブロックでは５バイト毎に属性を繰り返すことを注記しておく。これがどのように関係するのか確認するためには、以下のペイロード・フォーマットを参照のこと。
【表２３】
2010518891.tif 000025
連続的フレーム・カウンタについての属性
【００５６】
望ましければ、自走フレーム・カウンタについて記述することができる。
【表２４】
2010518891.tif 000026
【００５７】
ＳｐＯ２および脈拍数に対するアラーム限度設定値を報告するための追加属性は、簡潔性のために含まれていないが、同様に記述する。
連続的ＳｐＯ２についてのペイロード
【００５８】
連続的データ送信のための固定サイズ・データ・ブロックには多くの利点がある。１つの利点は、波形データを発生する測定デバイスがサンプリング・ポイントのいずれをもバッファする必要がなく（おそらくは、バッファすることができない）、捕獲が行われたほぼ直後にこれらを送ることである。固定ブロック・フォーマットに対する別の利点は、特定のデータ・レイアウトを予知した旧来のマネージャ・デバイス自体が自己記述メカニズムの詳細に関与する必要がなく、オフセット２および７に位置するような、同期バイトを探し、更にオフセット８においてフレーム・カウンタを探せば、旧来のマネージャ・デバイスに、それが正しい位置でデータを呼んでいることの正当な信頼度を与えることである。今後の開発または内部診断の使用のために、予約してある数バイトを用いることができる。
【００５９】
高度エージェント・デバイス１１０では、前述の例におけるペイロード・タイプＰ１は、連続的データ・フォーマットを表し、これまでの属性定義を用いて記述した表として表示することができる。
【表２５】
2010518891.tif 000027
標準デバイスについての一時的属性
【００６０】
デバイスの仕様においてデバイスの標準能力はよく分かるので、これらの要件のみを固守するデバイスは自己記述する必要がない。しかしながら、実施形態によっては、このデバイスも自己記述することができる。
高度デバイスについての一時的属性
【００６１】
一時的データが要求されたとき、ＳｐＯ２および脈拍数の一方のタイプのみ、ならびに脈拍振幅、アラームおよびステータス・データ・エレメントだけを送ればよい。尚、以下の表では、新たな位置付けを反映するために、バイト位置が変化していることを注記しておく。以下の表は、一時的データ・フォーマットが選択されたときに、送られることになる。これらは、本質的に、連続的データ・フォーマットの部分集合であり、パケット・サイズが小さくなったことを反映するために、バイト位置の配置が変化している。
高度一時的ＳｐＯ２についての属性
【表２６】
2010518891.tif 000028
高度一時的脈拍数についての属性
【表２７】
2010518891.tif 000029
高度一時的脈拍振幅についての属性
この表は以下を示す。
【表２８】
2010518891.tif 000030
高度一時的アラームについての属性
【００６２】
表２９において、アラーム・エンティティが２バイト値であることを暗示的に示すメトリック仕様が呈示されている。加えて、アラームまたはステータス・ワードは、多くの場合ビット指向定義(bit-oriented definitions)を有する。以下に様々な任意の例を与える。多くは１ビット定義であり、一例は、近接して位置しない３ビット値をどのように記述するかを示す。追加のビット指向定義が含まれていない場合、この表も７バイトとなる。最悪の場合、表における１６個の１ビット定義が各々７バイトを用いると、基礎のアラーム・エンティティに加えて、１１２バイトを消費することになる。
【表２９】
2010518891.tif 000031
【００６３】
どのステータス情報も以下の表において表現することができる。簡潔さのために、ＳｐＯ２に適用可能な１ビット指向定義を、追加の多ビットおよび１ビット・フィールド例と共に含ませてある。このステータス・ビットは、配信しているＳｐＯ２は、各平均化フィルタによって、その最大能力まで計算および処理されていることを示す。
【表３０】
2010518891.tif 000032
一時的ヘッダのサイズ
【００６４】
あらゆるアラーム・ビットおよびステータス・ビットを一意に定義すると仮定すると、記述全体を送信するためには３４８バイトを要する。アラームおよびステータスを疎に配置すると、記述全体を送信するために必要なバイト数は減少する。
【表３１】
2010518891.tif 000033
一時的ＳｐＯ２についてのペイロード
【００６５】
この例におけるタイプＰ２についてのペイロード、一時的フォーマットは以下のように表示することができる。
【表３２】
2010518891.tif 000034
メッセージング・フォーマット
【００６６】
本発明のメッセージング方式は、コンピュータ結合デバイス(computer-bound device)が実現できる程に単純であり、しかも双方向通信や、エージェント・デバイス１１０が適法であるが形成に問題があるペイロードをマネージャ・デバイス１３０に送ることを防止するための誤りチェックを可能にする程に柔軟であることを意図している。
【００６７】
一実施形態では、５つのパケット・タイプがある。これら５つのパケット・タイプは、接続（ＣＮＣ）、部類（ＣＬＳ）、通信（ＣＯＭ）、確認（ＣＦＭ）、および制御（ＣＴＬ）を含む。これらのパケット・タイプは、本文書において先に論じた「データ・フロー相互作用」との整合を取ることを意図している。一実施形態によれば、パケット・フォーマットは、ヘッダ・ブロック、ペイロード・ブロック、および任意のＣＲＣブロックを含む。ヘッダ・ブロックは、２バイトから成り、パケット・タイプ、パケット長、および数個のフラグを記述するフィールドを有する。
【００６８】
一実施形態では、メッセージ・フォーマットは多数の有効TYPEフィールドを含む。これらの有効TYPEフィールドは、3'b001−ＣＮＣ、3'b010−ＣＬＳ、3'b011−ＣＯＭ、3'b100−ＣＬＴ、および3'b101−ＣＦＭを含む。実施形態によっては、RSVDビットを1'b0にセットしなければならない。
【００６９】
ＣＲＣビットをセットするのは、特定のパケットの任意の巡回冗長チェックがイネーブルされているときである。一実施形態では、１種類のみのＣＲＣ方法（ＣＲＣ１６のような）が許されており、これらのバイトはＬＥＮフィールドに含まれる。
【００７０】
一実施形態では、ＡＣＫビットをセットするのは、確認パケットが要求されたときである。TYPEが3'b101（ＣＦＭ）にセットされたときには、パケットはこのビットをセットすることが許されない。しかしながら、別の実施形態では、ＣＦＭパケットがこのビットを用いることができる。ＡＣＫビットがセットされているＣＦＭパケットは、通例、直前のパケットが適正な回答を受信し、ＡＣＫビットがクリアされたＣＦＭパケットはＮＯＡＣＫと同義とすることができることを意味する。
【００７１】
ＬＥＮフィールドは、このヘッダの後に続くバイト数を宣言する。実施形態によっては、ＬＥＮ値は０から１０２３までの値を取ることができる。
接続パケット・サイズ
【００７２】
先に論じたように、エージェント・デバイス１１０はＣＮＣパケットをマネージャ・デバイス１３０に送る。一実施形態では、起こる(transpire)可能性がある接続トランザクションには３種類ある。これらの接続トランザクションは、エージェント・デバイス１１０が利用可能な任意のマネージャ・デバイス１３０に接続したいときであって、マネージャ・デバイス（トランザクションＩＤを有していない）(INTROサブタイプ）とは決して通信したことがない場合、エージェント・デバイス１１０が最後に知ったマネージャ・デバイスと接続することを欲しトランザクションＩＤ（HAVE_IDサブタイプ）を有する場合、あるいはエージェント・デバイス１１０がトランザクションＩＤを有するが、最後に知ったマネージャ・デバイス１３０と通信しようとするのを諦めたい、または新たなマネージャ・デバイスと初めからやり直したい場合を含むことができる。実施形態によっては、長い通信タイムアウトのために同じマネージャ・デバイスと通信したいエージェント・デバイス１１０と、新たな会話または接続を開始したいエージェント・デバイス１１０との間に区別がある。
【００７３】
初期ＣＮＣパケットの中にある情報は、エージェント・デバイス１１０がサポートするプロトコルのレベルも含むとよい。
【００７４】
接続の間に、マネージャ・デバイス１３０が、エージェント・デバイスが保持するトランザクションＩＤと一致するトランザクションＩＤで応答した場合、直前に送った（またはデフォルト）ものを送ればよい。
【００７５】
逆に、マネージャ・デバイス１３０は、エージェント・デバイスを１日１回の読み取りのために起動させたい場合、ＣＮＣパケットを送ることができる。しかしながら、１時間に１回または３０分毎というような、他の時間間隔も用いることができる。すると、エージェント・デバイス１１０は、送ろうとするペイロードに対して正しいトランザクションＩＤで応答する必要がある。
【００７６】
メッセージ・タイプの多くは状態遷移を含む。これらの状態遷移は、ペイロード・ブロックの先頭に置かれるサブフィールドとして表現される。これは、基本的なデータ・フォーマットをできるだけ簡単に保つためである。
分類パケット・タイプ
【００７７】
これは、更なる識別および可能な後続の自己記述についての照会が行われる場合である。ＣＮＣパケット・タイプの場合のように、ペイロードの先頭には、分類の各段階に適用可能なサブタイプ・フィールドを収容する。これらの分類の例を２つ示す。
・REQ_CLASS  （マネージャ・デバイス−＞エージェント・デバイス）
・RSP_CLASS  （エージェント・デバイス−＞マネージャ・デバイス）
【００７８】
エージェント・デバイス１１０が多機能デバイスである場合、複数のRSP_CLASSメッセージで応答する必要がある場合もある。これらの分類は、プロトコル・エラーを報告することができる様々なＣＦＭパケットを用いることができる。しかしながら、他のパケット・タイプも用いることができる。
通信パケット・タイプ
【００７９】
生理学的情報を収容するデータ・ペイロードは、このパケット・タイプで送る。ＣＮＣおよびＣＬＳパケット・タイプと同様、ペイロードの先頭には、送ろうとしているペイロードのタイプを宣言する（分類段階において何を要求しているかに基づいて）サブタイプ・フィールドを収容する。
制御パケット・タイプ
【００８０】
このパケットは、様々な目的に用いることができる。例えば、このパケットは、エージェント・デバイスが、停電が差し迫っていることを非同期にマネージャ・デバイスに警告するためや、エージェント・デバイスが、エージェント・デバイス上の制御ボタンによってユーザが直接アラーム設定の構成を変更したことを、マネージャ・デバイスに警告するために用いることができる。また、マネージャ・デバイス１３０は、例えば、新たなアラーム設定に応答するようにエージェント・デバイスをプログラムによって構成しなおすために、このトランザクション・タイプを開始することもできる。また、制御パケットは、通信パケットを開始および停止するため、ならびにサービス品質（ＱｏＳ）を取り決めるためにも用いることができる。
確認パケット・タイプ
【００８１】
一実施形態では、ＣＦＭパケットは２つの形態を取ることができる。第１の形態は、ＡＣＫ／ＮＯＡＣＫとして、即ち、発信元にプロトコル・エラーまたはＣＲＣエラーを通知するためにある。ＡＣＫ／ＮＯＡＣＫフォーマットは、ヘッダ・ブロックのみから成ることができる（ＬＥＮフィールドは０とすればよい）。それ以外では、確認パケットは、１１０７３−１０１０１命名法の用語（通信パケットからの）を用いて、リターン・ステータスを置くことができ、MDC_CC_COMM_ERRORまたはMDC_CC_CRC_ERRORのような障害を記述する。
【００８２】
以上、本発明およびその利点について詳しく説明したが、添付した特許請求の範囲に定める本発明の主旨および範囲から逸脱することなく、種々の変更、代替、および変形を行うことができるのは言うまでもない。更に、本願の範囲は、本明細書に記載した特定的な実施形態のプロセス、機械、製造、物質の組成、手段、方法、およびステップに限定することは意図していない。本発明の開示から、現在存在するまたは今後開発され、本明細書に記載した対応する実施形態と実質的に同じ機能を実行するまたは実質的に同じ結果が得られる、プロセス、機械、製造、物質の組成、手段、方法、またはステップも、本発明にしたがって利用してもよいことは、当業者には容易に認められよう。したがって、添付した特許請求の範囲は、このようなプロセス、機械、製造、物質の組成、手段、方法、またはステップをその範囲に含むことを意図するものとする。
【図１】
2010518891.tif 000035
【図２】
2010518891.tif 000036
【図３】
2010518891.tif 000037
【図４】
2010518891.tif 000038
【国際調査報告】
2010518891.tif 000039