JP2010524050A - 無線医療デバイスネットワークに関する無線データ通信プロトコルおよび無線データ通信技術 - Google Patents

無線医療デバイスネットワークに関する無線データ通信プロトコルおよび無線データ通信技術 Download PDF

Info

Publication number
JP2010524050A
JP2010524050A JP2009548233A JP2009548233A JP2010524050A JP 2010524050 A JP2010524050 A JP 2010524050A JP 2009548233 A JP2009548233 A JP 2009548233A JP 2009548233 A JP2009548233 A JP 2009548233A JP 2010524050 A JP2010524050 A JP 2010524050A
Authority
JP
Japan
Prior art keywords
network
wireless
data communication
wireless data
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2009548233A
Other languages
English (en)
Inventor
ケザド ジェイ メータ
ザ サード ジョン ジェイ ミカ
ヒマンシュ パテル
シェルドン ビー モウバーグ
チャールズ トレ
ジェームズ ジョロタ
グレン オー スピタル
Original Assignee
メドトロニック ミニメド インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=56290953&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=JP2010524050(A) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority claimed from US11/671,174 external-priority patent/US20070255116A1/en
Priority claimed from US11/671,176 external-priority patent/US20070254593A1/en
Priority claimed from US11/671,172 external-priority patent/US8073008B2/en
Priority claimed from US11/671,170 external-priority patent/US20070253021A1/en
Priority claimed from US11/671,179 external-priority patent/US20070258395A1/en
Application filed by メドトロニック ミニメド インコーポレイテッド filed Critical メドトロニック ミニメド インコーポレイテッド
Publication of JP2010524050A publication Critical patent/JP2010524050A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/0002—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network
    • A61B5/0015—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network characterised by features of the telemetry system
    • A61B5/0022—Monitoring a patient using a global network, e.g. telephone networks, internet
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/145—Measuring characteristics of blood in vivo, e.g. gas concentration, pH value; Measuring characteristics of body fluids or tissues, e.g. interstitial fluid, cerebral tissue
    • A61B5/14532—Measuring characteristics of blood in vivo, e.g. gas concentration, pH value; Measuring characteristics of body fluids or tissues, e.g. interstitial fluid, cerebral tissue for measuring glucose, e.g. by tissue impedance measurement

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Biomedical Technology (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Bioethics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Signal Processing (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Physics & Mathematics (AREA)
  • Public Health (AREA)
  • Software Systems (AREA)
  • General Business, Economics & Management (AREA)
  • Epidemiology (AREA)
  • Primary Health Care (AREA)
  • Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Molecular Biology (AREA)
  • Surgery (AREA)
  • Animal Behavior & Ethology (AREA)
  • Veterinary Medicine (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Power Engineering (AREA)
  • Pathology (AREA)
  • Biophysics (AREA)
  • Infusion, Injection, And Reservoir Apparatuses (AREA)
  • Mobile Radio Communication Systems (AREA)
  • External Artificial Organs (AREA)

Abstract

本明細書で説明される液体注入システム（１０２）が、注入ポンプ（１２８）、ハンドヘルドモニタまたはハンドヘルドコントローラ（１３８）、生理学的センサ（１３０）、および臨床モニタまたは病院モニタ（１４０）などの、いくつかのローカル「身体ネットワーク」デバイスを含む。身体ネットワークデバイスは、互いの間でステータスデータ、生理学的情報、警告、制御信号、およびその他の情報をサポートするように構成されることが可能である。さらに、身体ネットワークデバイスは、身体ネットワークデバイスと、「外部」デバイス（１０４）、「外部」システム、または「外部」通信ネットワークとの間でステータスデータ、生理学的情報、警告、制御信号、およびその他の情報のネットワーク化された通信をサポートするように構成されることが可能である。ネットワーク化された医療デバイスは、医療デバイスネットワーク（１００）内のデータの効率的な通信のために、様々な無線データ通信プロトコルをサポートするように構成される。さらに、無線医療デバイスは、現在の動作条件、アプリケーション特有のデータ内容、またはその他の基準に応じて、いくつかの動的に調整可能な無線データ通信モードをサポートするように構成されることが可能である。

Description

本発明の実施形態は、一般に、患者の身体に液体を送り込む注入システムなどの医療デバイスおよび医療デバイスネットワークに関する。より詳細には、本発明の実施形態は、無線データ通信プロトコルと関係するシステムおよび技術、ならびに医療デバイスネットワーク環境において使用するのに適した無線データ通信機能特徴に関する。
本発明は、２００６年４月２８日に出願された米国特許出願第１１／４１４１６０号の一部継続出願である「Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｏｆ Ｄｅｖｉｃｅｓ ｉｎ ａ Ｍｅｄｉｃａｌ Ｄｅｖｉｃｅ Ｎｅｔｗｏｒｋ ａｎｄ Ｗｉｒｅｌｅｓｓ Ｄａｔａ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｔｅｃｈｎｉｑｕｅｓ Ｕｔｉｌｉｚｉｎｇ Ｄｅｖｉｃｅ Ｉｄｅｎｔｉｆｉｅｒｓ」という名称の２００７年２月５日に出願した米国特許出願第１１／６７１１７０号、２００６年４月２８日に出願された米国特許出願第１１／４１４１６０号の一部継続出願である「Ｓｕｂｎｅｔｗｏｒｋ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ａｎｄ Ｖａｒｉａｂｌｅ Ｔｒａｎｓｍｉｔ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｔｅｃｈｎｉｑｕｅｓ ｆｏｒ ａ Ｗｉｒｅｌｅｓｓ Ｍｅｄｉｃａｌ Ｄｅｖｉｃｅ Ｎｅｔｗｏｒｋ」という名称の２００７年２月５日に出願した米国特許出願第１１／６７１１７２号、２００６年４月２８日に出願された米国特許出願第１１／４１３９７４号の一部継続出願である「Ｂｒｏａｄｃａｓｔ Ｄａｔａ Ｔｒａｎｓｍｉｓｓｉｏｎ ａｎｄ Ｄａｔａ Ｐａｃｋｅｔ Ｒｅｐｅａｔｉｎｇ Ｔｅｃｈｎｉｑｕｅｓ ｆｏｒ ａ Ｗｉｒｅｌｅｓｓ Ｍｅｄｉｃａｌ Ｄｅｖｉｃｅ Ｎｅｔｗｏｒｋ」という名称の２００７年２月５日に出願した米国特許出願第１１／６７１１７４号、２００６年４月２８日に出願された米国特許出願第１１／４１３９５６号の一部継続出願である「Ｗｉｒｅｌｅｓｓ Ｄａｔａ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｆｏｒ ａ Ｍｅｄｉｃａｌ Ｄｅｖｉｃｅ Ｎｅｔｗｏｒｋ ｔｈａｔ Ｓｕｐｐｏｒｔｓ ａ Ｐｌｕｒａｌｉｔｙ ｏｆ Ｄａｔａ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｍｏｄｅｓ」という名称の２００７年２月５日に出願した米国特許出願第１１／６７１１７６号、２００６年４月２８日に出願された米国特許出願第１１／４１３９５６号の一部継続出願である「Ｗｉｒｅｌｅｓｓ Ｄａｔａ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ ａ Ｍｅｄｉｃａｌ Ｄｅｖｉｃｅ Ｎｅｔｗｏｒｋ」という名称の２００７年２月５日に出願した米国特許出願第１１／６７１１７０９号の利益を主張する。
無線データ通信能力を有するポータブル医療デバイスが、特に、継続的に、または頻繁に監視されなければならない状態を有する患者に関して、ますます普及してきている。例えば、糖尿病患者は、患者の身体、特に、患者の「ＢＧ」（血糖）レベルをバランスがとれた状態に保つように患者の毎日の生活スタイルを変更し、監視することを通常、要求される。１型糖尿病を有する個人、および２型糖尿病を有する一部の個人は、インスリンを使用してＢＧレベルを調整する。そのようにするのに、糖尿病患者は、栄養のある食事を適時に摂取すること、運動に参加すること、ＢＧレベルを毎日、監視すること、およびインスリン投与量を適宜、調整し、投与することを含め、厳密なスケジュールを定常的に守る。糖尿病患者は、２つ以上の別々のデバイス間のデータ通信を円滑にするようにネットワーク環境に配置された無線医療デバイスを利用することができる。
先行技術は、注入セットを介してインスリンの正確な、測定された投与量を送るように設計されたインスリンポンプシステムを含む（注入セットは、患者の皮下に挿入されたカニューレを終端とする小さい直径の管を通してインスリンを送る）。注射器の代わりに、患者は、単にインスリンポンプを作動させて、必要に応じて、例えば、患者の現在のＢＧレベルに応じて、インスリンボーラス(bolus)を投与することができる。患者は、試験ストリップメータ、連続グルコース測定システムなどのＢＧ測定デバイスを使用して、患者のＢＧレベルを測定することができる。ＢＧ測定デバイスは、患者の血液のサンプル、体液と接触するセンサ、光センサ、酵素センサ、または蛍光センサなどの様々な方法を使用して、患者のＢＧレベルを測定する。ＢＧ測定デバイスが、ＢＧ測定値を生成すると、この測定値が、ＢＧ測定デバイス上で表示される。連続グルコース監視システムは、患者のＢＧレベルをリアルタイムで監視することができる。
国際公開第０３／００１３２９ Ａ号パンフレット 国際公開第０３／０９４０９０ Ａ号パンフレット
また、インスリンポンプおよび連続グルコース監視デバイスは、そのような注入デバイスに関連するリモートコントロールデバイス、監視デバイスもしくはディスプレイデバイス、ＢＧメータ、および他のデバイスと通信するように構成されることも可能である。従来の注入システム内の個々のデバイスは、注入システムの動作をサポートする限られた量の有線データ通信または無線データ通信をサポートするように構成されることが可能である。例えば、連続グルコース監視センサが、注入システム内のＢＧモニタデバイスと通信するワイヤレス「ＲＦ」（無線周波数）送信機を含むことが可能である。別の例として、注入システムは、無線技術を使用して注入ポンプデバイスと通信するハンドヘルドリモートコントロールを含むことが可能である。しかし、従来の注入システムは、制御信号、監視信号、患者ステータス情報、生理学的データ、警告、作動命令、プログラミング信号、および他のデータ通信のルーティングが、一般に、注入システム自体から限られた近距離で、ローカルの動作環境内で行われるという点で、多少、孤立した、ローカルの仕方で動作する。さらに、多くの従来の注入システムは、ネットワークに構成されたデバイス間の効率的で、効果的な無線データ通信を円滑にする、いくつかのプロトコルを活用しない。
本明細書で説明される医療デバイスシステムの実施形態は、無線リンクを介したシステムデータの効率的なルーティングを可能にする、いくつかのＲＦデータ通信プロトコル、ＲＦデータ通信技法、およびＲＦデータ通信技術をサポートするように構成された無線デバイスを含む。この医療デバイスシステムは、無線ネットワークトポロジ（および／または有線ネットワークトポロジ）に構成された複数のデバイスを含む。さらに、「ローカル」エリアネットワークまたは「身体」エリアネットワークにおける無線医療デバイスが、ネットワーク化されたコンピュータ、セルラー電話機、パーソナルデジタルアシスタント、病院監視機器、ポケットベルデバイスなどの１つ以上の外部ネットワークデバイスと通信するように適切に構成されることが可能である。医療デバイスネットワーク内の無線ネットワーク通信は、デバイスステータス情報、生理学的な患者データ、警告、および／または警報を伝送することができる。さらに、医療デバイスネットワーク内の無線ネットワーク通信は、デバイスプログラミング命令、デバイス作動命令、較正パラメータ、警告／警報イネーブル信号または警告／警報ディセーブル信号、および／または他の制御パラメータなどの、ローカルシステム環境外部の外部デバイスを発信元とするデータを、ローカルシステムデバイスに伝送することが可能である。
いくつかの望ましいＲＦ動作機能が、医療デバイスネットワークにおけるデバイスを構成するための方法の実施形態によって実行されることが可能である。この方法は、医療デバイスネットワーク内のデバイスの配置の特性に関連する少なくとも１つの基本識別子を獲得すること、この少なくとも１つの基本識別子から、デバイスに関するキー（このキーは医療デバイスネットワーク内のデバイスを一意に識別する）を生成すること、およびデバイスにおいてキーの格納を開始することを含む。
また、望ましいＲＦ動作機能が、同期データ通信プロトコルを使用して互いの間でデータを通信するように構成された第１のデバイスと、第２のデバイスとを有する医療デバイスネットワークに関する通信方法の実施形態によって実行されることも可能である。この方法は、第１のデバイスにおいて、医療デバイスネットワーク内の第１のデバイスを一意で識別する第１のキー、および医療デバイスネットワーク内の第２のデバイスを一意で識別する第２のキーを保持すること、第２のデバイスにおいて、第１のキーと、第２のキーとを保持すること、第１のデバイスが、ある量のデータを第１のキーと一緒に伝送する、第２のデバイスを宛先とするデータパケットを伝送すること、および第２のデバイスが、第１のデバイスを宛先とする第２のキーを伝送する応答パケットを伝送することを含む。
また、いくつかの望ましいＲＦ動作機能が、医療デバイスネットワーク内の第１のデバイスを一意で識別する第１のキー、および医療デバイスネットワーク内の第２のデバイスを一意で識別する第２のキーを格納するように構成されたメモリを有する第１のデバイスと、第１のキーおよび第２のキーを格納するように構成されたメモリを有する、同期データ通信プロトコルを使用して第１のデバイスとデータを通信するように構成された第２のデバイスとを有する医療デバイスネットワークの実施形態によって実行されることも可能である。第１のデバイスは、第２のデバイスを宛先とするデータパケットを伝送するように構成される。このデータパケットは、ある量のデータを第１のキーと一緒に伝送する。第２のデバイスは、第１のデバイスを宛先とする応答パケットを伝送するように構成される。この応答パケットは、第２のキーを伝送する。
また、望ましいＲＦ動作機能が、非同期データ通信プロトコルを使用して互いの間でデータを通信するように構成された第１のデバイスと、第２のデバイスとを有する医療デバイスネットワークに関する通信方法の実施形態によって実行されることも可能である。この方法は、医療デバイスネットワーク内の第１のデバイスを一意で識別する第１のキー、および医療デバイスネットワーク内の第２のデバイスを一意で識別する第２のキーを保持すること、第２のデバイスにおいて、第１のキーと、第２のキーとを保持すること、第１のデバイスが、第１のキーおよび第２のキーと一緒にある量のデータを伝送する、第２のデバイスを宛先とするデータパケットを伝送すること、および第２のデバイスが、第１のキーおよび第２のキーを伝送する、第１のデバイスを宛先とする応答パケットを伝送することを含む。
また、いくつかの望ましいＲＦ動作機能が、同期データ通信プロトコルを使用して互いの間でデータを通信するように構成されたマスタデバイスと、スレーブデバイスとを有する医療デバイスネットワークに関する通信方法の実施形態によって実行されることも可能である。この方法は、マスタデバイスにおいて、医療デバイスネットワーク内のマスタデバイスを一意で識別する第１のキー、医療デバイスネットワーク内のスレーブデバイスを一意で識別する第２のキー、および医療デバイスネットワーク内の他のすべてのスレーブデバイスを一意で識別するさらなるキーを保持すること、スレーブデバイスにおいて、第１のキーおよび第２のキーを保持すること、スレーブデバイスが、ある量のデータを第１のキーと一緒に伝送する、マスタデバイスを宛先とするデータパケットを伝送すること、およびマスタデバイスが、スレーブデバイスを宛先とする応答パケットを伝送することを含む。
また、いくつかの望ましいＲＦ動作機能が、医療デバイスネットワークの実施形態によって実行されることも可能である。医療デバイスネットワークは、マスタデバイスを一意で識別する第１のキー、および医療デバイスネットワーク内のすべてのスレーブデバイスを一意で識別するさらなるキーを格納するように構成されたメモリを有するマスタデバイスと、第１のキー、および医療デバイスネットワーク内のスレーブデバイスを一意で識別する第２のキーを格納するように構成されたメモリを有する、同期データ通信プロトコルを使用してマスタデバイスとデータを通信するように構成されたスレーブデバイスと、を含む。スレーブデバイスは、第１のキーと一緒にある量のデータを伝送する、マスタデバイスを宛先とするデータパケットを伝送するように構成され、マスタデバイスは、スレーブデバイスを宛先とする応答パケットを伝送するように構成される。
いくつかの望ましいＲＦ動作機能が、医療デバイスネットワークを形成する複数の医療デバイスと、第１の同期タイミングスキームを使用して互いの間で通信するように構成された複数の医療デバイスの第１のサブセット（部分集合）を含む医療デバイスネットワーク内の第１のサブネットワークと、第２の同期タイミングスキームを使用して互いの間で通信するように構成された複数の医療デバイスの第２のサブセットを含む医療デバイスネットワーク内の第２のサブネットワークと、を有する医療デバイスネットワークの実施形態によって実行されることが可能である。医療デバイスネットワークは、第１の同期タイミングスキーム、および第２の同期タイミングスキームを調整して、第１のサブネットワークと第２のサブネットワークの同時の動作を可能にするように構成される。
また、また、いくつかの望ましいＲＦ動作機能が、同期データ通信プロトコルを使用して互いの間で通信するように構成された第１のデバイスと、第２のデバイスとを有する医療デバイスネットワークに関する通信方法の実施形態によって実行されることも可能である。この方法は、次のデータパケットが無線データ通信チャネルを介して第２のデバイスにいつ伝送されるかを第１のデバイスが動的に決定すること、および第１のデバイスが第２のデバイスに可変時間インジケータ（標識）を伝送することを含む。可変時間インジケータは、次のデータパケットが、無線データ通信チャネルを介していつ伝送されるかを示し、可変時間インジケータインジケータは、第２のデバイスを促して、可変時間インジケータによって指定されるとおりに次のデータパケットを受信するように第２のデバイス自身を構成するようにする。
また、医療デバイスシステムのある実施形態は、無線データ通信信号を使用することもできる。望ましいＲＦ動作機能が、医療デバイスシステム内の第１のデバイスと、医療デバイスシステム内の第２のデバイスとの間の無線データ通信チャネルを介して伝送されるデータフィールドを有する無線データ通信信号の実施形態を使用して実現されることが可能である。無線データ通信信号は、次のデータパケットが、無線データ通信チャネルを介していつ伝送されるかを示す可変時間インジケータを表すデータを含むデータパケットを含む。
いくつかの望ましいＲＦ動作機能が、共通の搬送周波数を使用して同期された仕方でデータを通信するように構成された複数のデバイスを有する無線医療デバイスネットワークに関する通信方法の実施形態によって実行されることも可能である。この方法は、無線医療デバイスネットワーク内の第１のデバイスが、無線医療デバイスネットワーク内の他の複数のデバイスにデータパケットをブロードキャストすること、第１のデバイスが、このデータパケットに応答して、これらの他のデバイスから応答パケットを擬似ランダムな順序で受信すること、および第１のデバイスが、これらの応答パケットを、これらの他のデバイスと互いに関係付けることを含む。
また、いくつかの望ましいＲＦ動作機能が、医療デバイスネットワークに関する通信方法の実施形態によって実行されることも可能である。この方法は、医療デバイスネットワーク内の第１のデバイスが、第１の無線データ通信リンクを介して、医療デバイスネットワーク内の宛先デバイスを宛先とするメッセージを受信すること、および第１のデバイスが、宛先デバイスに到達するように、医療デバイスネットワーク内で第２の無線データ通信リンクを介して、このメッセージを転送することを含む。
また、望ましいＲＦ動作機能が、医療デバイスネットワーク内の動作のために構成された無線デバイスの実施形態によって実行されることも可能である。この無線デバイスは、医療デバイスネットワーク内の宛先デバイスを宛先とするメッセージを、第１の無線リンクを介して受信するように構成された無線受信機モジュールと、この宛先デバイスに到達するように、医療デバイスネットワーク内で、第２の無線リンクを介して、このメッセージを転送するように構成された無線送信機モジュールとを含む。
また、望ましいＲＦ動作機能が、医療デバイスネットワークに関する通信方法の実施形態によって実行されることも可能である。この方法は、医療デバイスネットワーク内のブロードキャストデバイスが、少なくとも１つの無線データ通信リンクを介して、医療デバイスネットワーク内の複数の宛先デバイスを宛先とするメッセージを伝送すること、医療デバイスネットワーク内の第１の宛先デバイスにおいて、このメッセージを受信すること、および第１の宛先デバイスが、医療デバイスネットワーク内の第２の宛先デバイスに、無線データ通信リンクを介して、このメッセージを転送することを含む。
いくつかの望ましいＲＦ動作機能が、医療デバイスシステムに関する通信方法の実施形態によって実行されることが可能である。この方法は、医療デバイスシステム内の第１のデバイスと、医療デバイスシステム内の第２のデバイスとの間で第１の無線データ通信モードをサポートすること、第１のデバイスと、第２のデバイスとの間で第２の無線データ通信モードをサポートすること、第１の無線データ通信モードにおいて、確認されていない無線データパケットに応答して警報を生成すること、および第２の無線データ通信モードにおいて、無線データパケット確認ステータスにかかわらず、第１のデバイスと第２のデバイスとの間でベストエフォートのサービス品質を提供することを含む。
さらに、医療デバイスシステムのある実施形態は、医療デバイスシステム内の第１のデバイスと、医療デバイスシステム内の第２のデバイスとの間の無線データ通信チャネルを介して伝送されるデータフィールドを有する無線データ通信信号を使用することができる。この無線データ通信信号は、複数のサポートされる無線データ通信モードの中から選択された１つのモードを表すデータを含むデータフィールドを含む。それら複数の無線データ通信モードは、無線データ通信チャネルに関する異なる複数のＲＦリンク特性セットにそれぞれ対応する。
いくつかの望ましいＲＦ動作機能が、第１のデバイスと、第２のデバイスとを有する医療デバイスシステムに関する通信方法の実施形態によって実行されることが可能である。この方法は、第１のデバイスが、第２のデバイスとの無線データ通信セッションに関して同期無線データ通信モードと非同期無線データ通信モードの間で選択すること、および第２のデバイスにモード識別子を伝送することを含む。モード識別子は、同期無線データ通信モードまたは非同期無線データ通信モードを指定し、モード識別子は、第２のデバイスを促して、モード識別子によって指定されるとおりに同期無線データ通信モードまたは非同期無線データ通信モードをサポートするよう第２のデバイス自身を構成させる。
また、いくつかの望ましいＲＦ動作機能が、第１のデバイスと、第２のデバイスとを有する医療デバイスシステムに関する通信方法の実施形態によって実行されることも可能である。この方法は、第１のデバイスが、異なる周波数割り当てスキームにそれぞれが対応する、複数のサポートされる無線データ通信モードからある無線データ通信モードを選択すること、および第２のデバイスにモード識別子を伝送することを含む。モード識別子は、その無線データ通信モードを指定し、モード識別子は、第２のデバイスを促して、その無線データ通信モードをサポートするように第２のデバイス自身を構成するようにする。
また、いくつかの望ましいＲＦ動作機能が、第１のデバイスと、第２のデバイスとを有する医療デバイスシステムに関する通信方法の実施形態によって実行されることも可能である。この方法は、第１のデバイスと第２のデバイスとの間で無線データパケットが第１のタイミングスキームに従って交換される同期データ通信モードで動作すること、確認されていない無線データパケットに応答して、第１のタイミングスキームとは異なるそれぞれの再試行タイミングスキームにそれぞれが対応する、複数の再試行周期性設定から、ある指定された再試行周期性設定を選択すること、およびこの指定された再試行周期性設定を使用して、少なくとも１つの無線データパケットを再送することを含む。
本発明のより完全な理解は、同様の符号が、すべての図で同様の要素を参照する、添付の図に関連して考慮されると、詳細な説明、および特許請求の範囲を参照することによって得られることが可能である。
以下の詳細な説明は、単に例示的な性質のものであり、本発明の実施形態、またはそのような実施形態の応用および用途を限定することは意図していない。さらに、前述の技術分野、背景、簡単な説明、または以下の詳細な説明において提示される、明示される理論、または暗示される理論によって限定されるという意図はまったくない。
本発明の実施形態は、機能ブロック構成要素および／または論理ブロック構成要素、ならびに様々な処理ステップの点で、本明細書で説明されることが可能である。そのようなブロック構成要素は、指定された機能を実行するように構成された任意の数のハードウェア、ソフトウェア、および／またはファームウェアによって実現されることが可能であることを理解されたい。例えば、本発明の実施形態は、１つ以上のマイクロプロセッサ、または他の制御デバイスの制御下で様々な機能を実行することが可能な、様々な集積回路構成要素、例えば、メモリ要素、デジタル信号処理要素、論理要素、ルックアップテーブルなどを使用することが可能である。さらに、本発明の実施形態は、任意の数のデータ伝送プロトコルに関連して実施されることが可能であること、および本明細書で説明されるシステムは、本発明の１つの例示的な実施形態に過ぎないことが、当業者には理解されよう。
簡明のため、注入システム動作、インスリンポンプおよび／または注入セット動作、血糖感知および監視、信号処理、データ伝送、シグナリング、ネットワーク制御、およびシステムの他の機能上の態様（ならびにシステムの個々の動作する構成要素）と関係する従来の技術は、本明細書では詳細に説明されない可能性がある。送出デバイスとして使用されることが可能な注入セットの例は、本願に引用して援用する米国特許第４７２３９４７号、米国特許第４７５５１７３号、米国特許第５１７６６６２号、米国特許第５５８４８１３号、米国特許第６０５６７１８号、米国特許第６４６１３２９号、米国特許第６４７５１９５号、米国特許第６５２０９３８号、米国特許第６５８５６９５号、米国特許第６５９１８７６号、および米国特許第６６０７５０９号において説明されるが、以上には限定されない。注入ポンプおよび／または通信オプションの例は、本願に引用して援用する米国特許第４５６２７５１号、米国特許第４６８５９０３号、米国特許第５０８０６５３号、米国特許第５５０５７０９号、米国特許第５０９７１２２号、米国特許第６５５４７９８号、米国特許第６５５８３２０号、米国特許第６５５８３５１号、米国特許第６６４１５３３号、米国特許第６６５９９８０号、米国特許第６７５２７８７号、米国特許第６８１７９９０号、および米国特許第６９３２５８４号に記載されるタイプであることが可能であるが、そのようなタイプには限定されない。グルコース感知デバイスおよび／またはグルコース監視デバイスの例は、本願に引用して援用する米国特許第６４８４０４５号、米国特許第６８０９６５３号、米国特許第６８９２０８５号、および米国特許第６８９５２６３号に記載されるタイプであることが可能であるが、そのようなタイプには限定されない。さらに、本明細書に含まれる様々な図に示される、結び付ける線は、様々な要素間の例示的な機能上の関係、および／または物理的結合を表すことを意図している。多くの代替の、またはさらなる機能上の関係、または物理的接続が実施形態に存在することが可能であることに留意されたい。
以下の説明は、要素またはノードまたは特徴（機能）特徴特徴が、一緒に「接続されている」または「結合されている」ことについての述べる可能性がある。特に明記しない限り、本明細書で使用される「接続されている」とは、１つの要素／ノード／特徴が、別の要素／ノード／特徴に直接につながれている（またはそのような要素／ノード／特徴と直接に通信する）ことを意味し、これは、必ずしも機械的にではない。同様に、特に明記しない限り、「結合されている」とは、１つの要素／ノード／特徴が、別の要素／ノード／特徴に直接に、または間接的につながれている（またはそのような要素／ノード／特徴と直接に、または間接的に通信する）ことを意味し、これは、必ずしも機械的にではない。このため、概略ブロック図のそれぞれは、要素の１つの例示的な構成を示すが、介在するさらなる要素、デバイス、特徴、または構成要素が、デバイス、システム、またはネットワークの実施形態において存在することが可能である。
図１は、本発明の例示的な実施形態に従って構成されたネットワークベースの医療デバイスシステム１００の概略図である。この例において、システム１００は、ユーザの身体へのインスリンの注入を調整するインスリン注入システムである。しかし、本発明の態様は、他の医療デバイスシステムに関連して利用されることも可能である。簡単に言うと、システム１００は、１つ以上のネットワークデバイス１０４と（単方向または双方向）通信する１つ以上のローカルデバイスを有する。本明細書で使用されるネットワークデバイス１０４は、ローカル注入システム１０２内で使用されるローカルデータ通信プロトコルおよびローカルデータ通信技術を利用する必要がないため、ならびにローカル注入システム１０２内のローカルデバイスに物理的に近接している必要がないため、ローカル注入システム１０２の「外部」にある。所与のローカル注入システム１０２が、所与のネットワークデバイス１０４と通信する仕方は、システム１００の特定の構成、ローカルデバイスの特性、およびネットワークデバイス１０４の特性に応じて異なることが可能である。例えば、ネットワーク通信は、１つのデータ通信ネットワーク１０６を使用する、複数のデータ通信ネットワーク１０８／１１０を使用する、直接の無線接続もしくは有線接続１１２を使用するなどして、ルーティングされることが可能である。１つの例示的な実施形態において、ローカル注入システム１０２内の無線デバイスからのデータ（および／または異なるローカル注入システムに関連する無線デバイスからのデータ）が、ネットワークデバイス１０４に対するインターフェースの役割をする無線遠隔測定ルータデバイスによって収集されることが可能である。１つの例示的な無線遠隔測定ルータデバイスが、図２１に関連して後段でより詳細に説明される。
ローカル注入システム１０２内、および／またはローカル注入システム１０２内のデバイスと、ネットワークデバイス１０４との間で通信されるデータには、例えば、以下が含まれる、または以下を代表とすることが可能である。すなわち、ローカル注入システム１０２内のデバイスのいずれかと関係する、またはローカル注入システム１０２自体と関係する生理学的な患者データ、デバイスステータス情報、時刻と日付の情報、警報／警告ステータス、患者の操作／手術、患者のステータス、または患者の状態と関係する他の情報である。例えば、そのようなデータには、ボーラス情報、基礎情報、またはセンサ情報が含まれる、または代表となることが可能である。また、そのようなデータには、例えば例えば、リマインダ（思い出させるための合図）、イベントマーカ（食事、運動などに関する）、警報、通知などの、患者、介護者、またはローカルデバイスもしくはネットワークデバイス１０４へのアクセスを有する別の個人によって入力される情報（これらに限られるものではない）が含まれる、または代表となることも可能である。
一部の実施形態では、ローカル注入システム１０２内のデバイスは、適切に構成された中継（変換：translation)デバイス、中継システム、または中継アプリケーション１１３を介してネットワークデバイス１０４と通信することができる。例えば、そのような中継デバイス１１３が、ＵＳＢ、ＩＥＥＥ１３９４などの標準化されたデータ通信インターフェースを介して１つ以上のネットワークデバイス１０４に結合されている間、適切なＲＦデータ通信プロトコル（公開されていても、独自であってもよい）を使用してローカル注入システム１０２内のデバイスと通信するように構成されることが可能である。また、中継デバイス１１３には、患者または介護者が、あるデバイスから受信されたデータをポータブルストレージデバイスの中に保存し、そのストレージデバイスを、互換性のある任意のコンピューティングデバイス、例えば、医師のオフィスにおけるパーソナルコンピュータに物理的に運ぶことができるように、フラッシュメモリ能力が与えられることも可能である。１つの例示的な中継デバイスが、図１８〜図２０に関連して後段でより詳細に説明される。
本明細書で使用される「データ通信ネットワーク」は、発信元構成要素と宛先構成要素との間のデータ通信をサポートするように構成されたハードウェア、ソフトウェア、ファームウェア、および／または処理ロジックを含め、任意の数の物理的構成要素、仮想構成要素、または論理構成要素を表す。ただし、データ通信は、指定された１つ以上の通信媒体を介して指定された１つ以上の通信プロトコルに従って実行される。データ通信ネットワークによって利用される通信ハードウェアには、ＳＤＩＯ、ＵＳＢ対応の無線モジュールなどの機械的に着脱可能なユニットが含まれることが可能である。例えば、データ通信ネットワーク１０６には、例えばローカルエリアネットワークまたはワイドエリアネットワークなどのコンピュータネットワーク、ポケットベルネットワーク、セルラー遠隔通信ネットワーク、コードレス電話システム、８０２．１１ネットワーク（ＷｉＦｉ）、８０２．１６ネットワーク（ＷｉＭＡＸ）、インターネット、ＩＥＥＥ Ｐ１９０１ ＢＰＬ（Ｂｒｏａｄｂａｎｄ ｏｖｅｒ Ｐｏｗｅｒ Ｌｉｎｅｓ）、病院データ通信ネットワーク（ＷＭＴＳ、またはその他）、ホーム制御ネットワーク、ホームセキュリティシステム、またはホーム警報システムなどのホームネットワーク、公衆交換電話網、衛星通信ネットワークなどが含まれ得るが、これらに限られるものではない。実施形態において、ローカル注入システム１０２とネットワークデバイス１０４の間のネットワーク通信は、知られているネットワークインターフェース技術、または独自のネットワークインターフェース技術を使用して、２つ以上の異なるタイプのデータ通信ネットワークによってルーティングされることが可能である。
ネットワークベースの注入システム１００の柔軟な性質が、様々な外部デバイスおよびリモートネットワークデバイス１０４と通信するローカル注入システム１０２を表す図１に示される。ある実施形態では、ローカル注入システム１０２内のローカルデバイスは、臨床モニタまたは病院監視機器などの固定型監視デバイス１１４、ラップトップＰＣ、パームトップＰＣ、またはタブレットＰＣなどのポータブルコンピュータ１１６、デスクトップＰＣなどの固定型コンピュータ１１８、パーソナルデジタルアシスタント（ＰＤＡ）１２０（これはポータブル電子メールデバイスであってもよい）、スマートフォン１２２（これはポータブル電子メールデバイスであってもよい）、セルラー電話機もしくはコードレス電話機などの無線電話機１２４、さらなる１つ以上のコンピューティングデバイスまたはデータベース１２６に対するネットワーク通信の伝送をサポートするように適切に構成されることが可能である。後段でより詳細に説明されるとおり、これらのローカルデバイスは、ローカルネットワークインターフェースだけを介して通信する必要はなく、そのようなデバイスは、他の手段を使用して通信してもよい。可能なネットワークデバイス１０４の以上のリストは、網羅的なものではなく、システム１００の実施態様は、ローカル注入システム１０２の外部の他のネットワークシステム、ネットワーク機器、ネットワークコンピューティングデバイス、ネットワーク構成要素、およびネットワーク要素とのネットワーク通信に対応するように設計されることが可能である。
１つの実施形態では、ローカル注入システム１０２は、患者によってローカルで制御され、監視されるインスリン注入システムとして実現される。この実施例では、ローカル注入システム１０２は、少なくとも注入ポンプ１２８を含む。また、ローカル注入システム１０２は例えば、以下の構成要素のいずれを含むことも可能であるが、以下のものに限定されるわけではない。すなわち、連続グルコースセンサ（無線送信機を含むことが可能な）などの生理学的特性センサ１３０、ポータブルディスプレイデバイス１３２、リモートコントロールデバイス１３４、ＢＧメータ１３６もしくは他の生理学的特性メータ、注入ポンプ１２８のためのコマンド表示コントローラ１３８、および臨床モニタまたは病院モニタとして実現されることが可能なモニタデバイス１４０である。これらのローカルデバイスのそれぞれは、後段でより詳細に説明される。
図１に示されるとおり、これらのローカルデバイスは、ローカル注入システム１０２内のローカル通信（ローカル通信情報）を送受信するように構成されることが可能であり、ただし、そのようなローカル通信は、指定された１つ以上のローカルデータ通信プロトコルに従って送受信される。例えば、ローカル通信は、１つ以上の無線データ通信プロトコル（ＲＦ技術、赤外線技術、磁気誘導技術、または他の無線技術を利用することが可能な）を使用して、さらに／または１つ以上の有線データ通信プロトコルを使用して、ローカルデバイス間で交換されることが可能である。ローカル注入システム１０２は、任意の所与のローカルデバイスが、他の任意のローカルデバイスと通信することができるように、柔軟に構成されることが可能であり、２つのローカルデバイス間の通信リンクまたは通信パスは、単方向であっても、双方向であってもよい。図１は、各通信リンクまたは通信パスが双方向である（双方向矢印で表される）例示的な実施形態を示す。
注入ポンプ１２８が、例えば、注入セットを介して、ユーザの身体にインスリンなどの液体を送り込むように構成される。１つの例示的な実施形態によれば、注入ポンプ１２８は、中央ハブの役割をし、ローカル注入システムに関する処理ロジックおよびインテリジェンス（知能）のほとんどは、注入ポンプ１２８に存在する。一部の実施形態では、ローカル医療デバイスシステム、例えば、従来のインスリン注射療法に関連して利用される監視システムは、注入ポンプ１２８を含まなくてもよい。さらに、注入ポンプ１２８は、ディスプレイを含まなくてもよい。ディスプレイを欠くある実施形態では、ポータブルディスプレイデバイス１３２、リモートコントロールデバイス１３４、コマンドディスプレイコントローラ１３８、またはローカル注入システム１０２内の他の任意のデバイスが、注入ポンプ１２８のためのリモートディスプレイの役割をすることができる。リモートディスプレイに関する他の選択肢には、前述したネットワークデバイス１０４、例えば、無線電話機１２４、モニタデバイス１１４、ポータブルコンピュータ１１６、またはパーソナルデジタルアシスタント１２０のいずれかが含まれるが、以上には限定されない。
実際には、注入ポンプ１２８の動作は、コマンド表示コントローラ１３８（これは注入ポンプ１２８に関するハンドヘルドモニタ／コントローラとして実現されることが可能）によって、リモートコントロールデバイス１３４によって、さらに／またはモニタ１４０によって、遠隔制御されることが可能である。１つの例示的な実施形態では、ＢＧメータ１３６が、コントローラデバイスの機能を含み、両方の構成要素が単一の筐体を共用するようにされることが可能である。１つのそのようなＢＧメータが、内容を本願に引用して援用する「Ｃｏｎｔｒｏｌｌｅｒ Ｄｅｖｉｃｅ ｆｏｒ ａｎ Ｉｎｆｕｓｉｏｎ Ｐｕｍｐ」という名称の米国特許出願第１１／２０４６６７号において説明されている。注入ポンプ１２８の制御は、注入ポンプ１２８自体に配置された、適切に構成されたユーザインターフェースを介して可能でもある。
また、ローカル注入システム１０２は、患者の生理学的特性を測定するように適切に構成された生理学的特性センサ１３０を含むことも可能である。さらに、センサ１３０は、センサ１３０が、注入ポンプ１２８の動作を制御することができるようにする処理制御ロジックを含むことが可能である。そのような制御は、センサ１３０によって獲得された測定値に応じたものとすることが可能である。本明細書で説明される例示的なシステムにおいて、センサ１３０は、患者のＢＧレベルをリアルタイムで測定する連続ＢＧセンサである。センサ１３０は、ローカル注入システム１０２内の他のデバイスにユーザの生理学的データを伝送することを円滑にする無線送信機を含むことが可能である。代替として、センサ１３０は、モニタまたはユーザインターフェースに直接に結線されてもよい。また、センサ１３０は、投薬の監視およびプログラミングが、遠隔で実行されることが可能であるように、モニタ１４０にリンクされることも可能である。代替として、センサ１３０は、例えば、Ｂｌｕｅｔｏｏｔｈ、ＺｉｇＢｅｅなどを介して、外部ネットワーク空間におけるデバイスと直接に通信してもよい。
ローカルデバイスは、受信されたセンサデータを適切な仕方で処理することができる。例えば、ポータブルディスプレイデバイス１３２、リモートコントロールデバイス１３４、ＢＧメータ１３６、コマンド表示コントローラ１３８、モニタ１４０、または注入ポンプ１２８が、受信されたセンサデータから導き出された現在のＢＧレベルを表示し、さらに／または低いＢＧレベル、または高いＢＧレベルの場合に警告その他を示すことが可能である。別の例として、ＢＧメータ１３６または注入ポンプ１２８が、較正の目的で、受信されたセンサデータを処理することが可能である。さらに別の実施例として、注入ポンプ１２８が、受信されたセンサデータに応答して、ポンプ１２８の注入機構を作動させるように構成されることが可能である。さらに、センサデータは、ローカルデバイスの１つ以上において、さらに／またはネットワークデバイス１０４の１つ以上において処理されることも可能である。これに関して、システム１００は、センサデータの処理のために分散処理技術を利用してもよい。
ローカル注入システム１０２内のデバイスのいずれも、ローカル注入システム１０２内のデバイスのいずれかと関係する、またはローカル注入システム１０２自体と関係する、生理学的な患者データ、デバイスステータス情報、時刻と日付の情報、警報／警告ステータス、および患者の操作／手術、ステータス、または状態と関係する他の情報の表示を円滑にするディスプレイ、および関連する処理ロジックを含むことが可能である。ポータブルディスプレイデバイス１３２が、限られた機能を有する小型デバイスとして実現されることが可能である。これに関して、ポータブルディスプレイデバイス１３２は、キーホルダ、カラビナ、ペンダント、インスリンペン、クレジットカードディスプレイなどに組み込まれてもよい。他のローカルデバイスは、そのようなデバイスの特定の機能と関係する拡張されたディスプレイ能力を有することが可能である。例えば、ＢＧメータ１３６は、メータ１３６の測定機能に特有であるディスプレイ特徴を含むことが可能である。
ＢＧメータ１３６は、一般に、血液サンプルを分析することによってユーザのＢＧレベルを測定するように構成される。例えば、ＢＧメータ１３６は、血液サンプル試験ストリップを受けるためのレセプタクル（受け取り口）を含むことが可能である。これに関して、ユーザは、サンプルを分析するＢＧメータ１３６の中に試験ストリップを挿入し、この試験ストリップサンプルに対応するＢＧレベルを表示する。ＢＧメータ１３６は、ローカル注入システム１０２内の他のローカルデバイスに伝送するために、測定されたＢＧレベルを伝えるローカル通信を生成するように構成されることが可能である。特定の応用先に応じて、ＢＧメータ１３６は、注入ポンプ１２８に関する監視デバイスの機能、および／または注入ポンプ１２８に関するコントローラデバイスの機能を含むことも可能である。
コマンド表示コントローラ１３８は、好ましくはハンドヘルドモニタ／コントローラデバイスとして実現され、これは注入ポンプ１２８とは物理的に別個であるものの、ユーザが、注入ポンプ１２８の動作を監視し、制御することができるようにする。これにより、ユーザが、デバイスを物理的に扱うことなしに注入ポンプ１２８を操作することが可能になる。後段でより詳細に説明されるとおり、コマンド表示コントローラ１３８は、ローカル通信またはローカルコマンドを注入ポンプ１２８に伝送するための通信モジュールを含む。さらなる実施形態において、コマンド表示コントローラ１３８は、ローカル注入システム１０２内の注入ポンプ１２８または他の構成要素から送信されたローカル通信を受信することができる。例示的な実施形態において、コマンド表示コントローラ１３８は、ローカル注入システム１０２の外部のネットワークデバイスへのネットワーク通信、およびそのようなデバイスからのネットワーク通信を扱うためのネットワーク通信モジュールも含む。さらに、コマンド表示コントローラ１３８は、ユーザ入力に対処する、キー、ボタンなどの、コントローラ１３８の筐体上の１つ以上のユーザ入力要素を含むことが可能である。実施形態において、コマンド表示コントローラ１３８は、注入ポンプ１２８上に表示される情報の少なくとも一部分を同時に表示するように構成されることが可能な、コントローラ１３８の筐体上のディスプレイを含む。
個人的使用のための臨床モニタとして、または介護者使用のための病院モニタとして実現されることが可能なモニタ１４０は、注入ポンプ１２８（および、場合により、ローカル注入システム１０２内の他のデバイス）の遠隔監視を可能にする。本明細書で説明されるモニタ１４０、または他のモニタは、注入ポンプ１２８を利用しない応用例、例えば、患者データ（グルコースレベルなど）を監視する応用例において利用されてもよい。さらに、モニタ１４０は、注入ポンプ１２８、および／またはローカル注入システム１０２内の他のデバイスの遠隔プログラミングおよび遠隔制御を可能にするように適切に構成されることが可能である。これに関して、本明細書で使用される「モニタ」とは、一般に、モニタ専用デバイスまたはモニタ／コントローラデバイスを指すことが可能である。実際には、モニタ１４０は、注入システム１０２のポータブルデバイスまたはハンドヘルドデバイスと比べて比較的大きいデバイスである。リモートコントロールデバイス１３４、ポータブルディスプレイデバイス１３２、およびコマンド表示コントローラ１３８とは異なり、モニタ１４０は、多少固定的であり、ユーザによって携帯されないことが意図されている。例えば、臨床モニタは、患者のベッドの脇のナイトテーブル上に配置されることが可能であるのに対して、病院モニタは、患者の部屋の中の医療機器カート上、または医療機器スタンド上に配置されることが可能である。ローカル注入システム１０２の、より小型のポータブルデバイスとは異なり、モニタ１４０は、好ましくは、注入ポンプ１２８上に表示される情報の少なくとも一部分を同時に表示するように構成されることが可能な、大型で、読み取りやすいディスプレイ要素を含む。
コマンド表示コントローラ１３８に関連して前述したとおり、モニタ１４０は、ユーザが、注入ポンプ１２８を遠隔操作することを可能にするように構成されることも可能である。モニタ１４０は、ローカル注入システム１０２内のローカル通信を送信および／または受信するための通信モジュールを含むことが可能である。さらに、モニタ１４０は、ローカル注入システム１０２の外部のネットワークデバイスへのネットワーク通信、およびそのようなデバイスからのネットワーク通信を扱うためのネットワーク通信モジュールを含むことが可能である。さらに、モニタ１４０は、ユーザ入力に対処する、キー、ボタンなどの、モニタ１４０の筐体上の１つ以上のユーザ入力要素を含むことが可能である。
図１に示されるとおり、ローカル注入システム１０２は、ローカルデバイス間で可能な多くの通信パスを確立することができる。実施形態において、コントローラデバイス（例えば、リモートコントロールデバイス１３４、コマンド表示コントローラ１３８、およびモニタ１４０）が、注入ポンプ１２８と、ＢＧメータ１３６などのローカル注入システム１０２の他の構成要素との間で中継装置（トランスレータ）の役割をすることが可能である。例えば、コントローラデバイスは、ローカル注入システム１０２内の宛先デバイスの表示要件に適合させるために、注入ポンプ１２８から受信されたデータをどのように変換するのが最善であるかを決定する能力を有することが可能である。図１に示されるとおり、注入ポンプ１２８は、ＢＧメータ１３６と直接に通信することができる。一部の実施形態では、ローカル注入システム１０２は、注入ポンプ１２８と通信することができる複数のコントローラを含むことが可能である。他の実施形態では、任意の所与の時点で、１つのコントローラデバイスだけしか、注入ポンプ１２８と通信することができない。また、コントローラデバイス機能は、一部の実施形態において、注入ポンプ１２８に組み込まれることも可能である。さらに別の実施形態では、ＢＧメータ１３６が、コントローラデバイスに組み込まれて、両方の特徴が、単一のデバイス筐体を共用するようにされることが可能である。
図２は、本発明の例示的な実施形態に従って構成された例示的な臨床モニタ２００の正面図である。図１を参照すると、臨床モニタ２００が、ローカル注入システム１０４内に（モニタ１４０として）、さらに／またはネットワークデバイス１０４として（例えば、モニタ１１４として）配置されることが可能である。臨床モニタ２００は、インスリン注入ポンプの活動を監視するのに利用されることが可能であるが、そうである必要はない。臨床モニタ２００は、一般に、筐体２０２、筐体２０２を支持するスタンド２０４、ディスプレイ要素２０６、およびユーザインターフェース特徴２０８を含む。臨床モニタ２００の実施形態は、ＡＣ電源プラグ２１０、１つ以上のスピーカ２１２、１つ以上のローカルデバイスインターフェース２１４、および１つ以上のネットワークインターフェース２１６を含むことが可能である。
前述したとおり、臨床モニタ２００は、患者のナイトテーブル上などの、適切な場所に配置された幾分固定的な装備品として使用されることが意図されている。つまり、臨床モニタ２００は、ポータブル構成要素またはハンドヘルド構成要素であるように設計されていない。したがって、筐体２０２は、任意の知られているディスプレイ技術（例えば、陰極線管、ＬＣＤパネル、またはプラズマパネル）を利用することが可能である、比較的大型のディスプレイ要素２０６を収容するようなサイズであることが可能である。ディスプレイ要素２０６のサイズは、特定の応用例のニーズに合うように変化することが可能であり、通常のサイズは、対角１０インチから対角２０インチまでの範囲であることが可能である。また、筐体２０２は、警報通知または警告通知を生成するように作動させられることが可能な内蔵スピーカ２１２を収容するように構成されることも可能である。また、筐体２０２は、図２に示されるユーザインターフェース特徴２０８を収容するように設計されることも可能である。スタンド２０４は、筐体２０２を支持し、臨床モニタ２００のための安定した取り付け場所を提供するように適切に構成される。図２に示される例示的な実施形態において、スタンド２０４は、１つ以上のユーザインターフェース特徴２０８を収容するようにも構成される。ユーザインターフェース特徴２０８には、ユーザが、オプションを選択する、情報を入力する、またはそれ以外で臨床モニタ２００の動作を制御することを可能にするキーパッド、キー、ボタン、スイッチ、ノブ、タッチパッド、ジョイスティック、ポインティングデバイス、仮想書き込みタブレット、または任意のデバイス、構成要素、もしくはファンクションが含まれることが可能である。
臨床モニタ２００は、ディスプレイ要素２０６上で情報を表示するように適切に構成された処理ロジック、ディスプレイドライバ、およびメモリ（図２では図示せず）を含むことが可能である。実施形態において、臨床モニタ２００は、例えば、ＢＧレベル、ＢＧトレンドもしくはＢＧグラフ、または輸液情報などの、ユーザによって要求された情報を表示するように、注入ポンプによって行われた、命令された動作と関係する情報を表示するように、または注入ポンプに関するステータスデータを表示するように機能する。臨床モニタ２００は、注入ポンプから、またはローカル注入システム内の任意のデバイスから受信されたローカル通信の中で伝送された情報を表示するように構成されることが可能である。任意の時点で、ディスプレイ要素２０６は、注入ポンプ上に示されるのと実質的に同一の情報を示すことができ、この２つのディスプレイは、互いを模倣して、ユーザが、注入セットを介して患者の身体に通常、取り付けられている注入ポンプからではなく、臨床モニタ２００から、選択された情報を便利に見ることを選択できるようにすることが可能である。また、ディスプレイ要素２０６は、見ることを容易にするバックライトを含むことも可能である。このバックライトは、警告または警報のレベルに適切な色を点滅させることによって、視覚的インジケータの機能をさらに実行するユーザプログラマブルマルチカラーバックライトであることが可能である。また、このバックライトは、ユーザ選好に対処し、さらに／または異なる警告ステータスもしくは警報ステータスを示す可変の強度（自動または手動）を有することも可能である。
後段でより詳細に説明されるとおり、臨床モニタ２００は、臨床モニタ２００と、ローカル注入システム内の他のローカルデバイスとの間のデータ通信、および／または臨床モニタ２００と、ローカル注入システムの外部のネットワークデバイスとの間のデータ通信を円滑にする１つ以上の通信モジュール（図２に示さず）を含むことが可能である。例えば、ローカル通信モジュールは、ローカルデバイスインターフェースと協働して、ローカルデバイスからローカル通信を受信し、さらに／またはローカルデバイスにローカル通信を送信することができる。ローカル通信モジュールおよびローカルデバイスインターフェースは、無線データ通信プロトコルおよび／または有線データ通信プロトコルをサポートするように構成されることが可能である。ある実施形態では、ローカルデバイスインターフェース２１４は、ローカルデバイスに対する通信リンクを確立するデータ通信ケーブル、または任意の適切に構成された物理的構成要素に対する接続を円滑にする物理インターフェース（プラグ、ジャック、コネクタ、ＵＳＢポートなどの）を表すことが可能である。別の例として、ネットワーク通信モジュールは、ネットワークインターフェースと協働して、ネットワークデバイスからネットワーク通信を受信し、さらに／またはネットワークデバイスにネットワーク通信を送信することができる。ネットワーク通信モジュールおよびネットワークインターフェースは、無線データ通信プロトコルおよび／または有線データ通信プロトコルをサポートするように構成されることが可能である。ある実施形態では、ネットワークインターフェース２１６は、ネットワークデバイスに対する通信リンクを確立するデータ通信ケーブル、または任意の適切に構成された物理的構成要素に対処する物理インターフェース（プラグ、ジャック、コネクタ、ＵＳＢポートなどの）を表すことが可能である。また、臨床モニタ２００は、１つ以上の無線ローカルデバイスインターフェース、および１つ以上の無線ネットワークインターフェースを利用することも可能であるが、そのような無線インターフェースは、筐体２０２外部のポイントから見えないようにしてもよい。
図３は、本発明の例示的な実施形態に従って構成された例示的な病院モニタ３００の正面図である。病院モニタ３００は、臨床モニタ２００に類似し、両方のモニタは、いくつかの共有される特徴および機能を含む。簡明のため、そのような共通の特徴および機能を本明細書で冗長に説明することはしない。病院モニタ３００は、一般に、情報を適切な仕方で表示し、さらに／または処理するように構成される。そのような情報は、警報、警告、あるいは、そのような情報／データを最初に生成した、または処理した場所またはデバイスにかかわらず、図１に関して前述した情報タイプもしくはデータタイプのいずれかであることが可能である。一般に、図１を参照すると、病院モニタ３００は、ローカル注入システム１０２内に（モニタ１４０として）、さらに／またはネットワークデバイス１０４として（例えば、モニタ１１４として）配置されることが可能である。病院モニタ３００は、一般に、筐体３０２、ディスプレイ要素３０４、ユーザインターフェース特徴３０６、ＡＣ電源プラグ３０８、１つ以上のスピーカ（図３では隠れて見えない）、１つ以上のローカルデバイスインターフェース３１０、および１つ以上のネットワークインターフェース３１２を含む。この例示的な実施形態では、病院モニタ３００は、導管３１４を介して患者に液体を送る内蔵注入ポンプも含む。
病院モニタ３００は、患者の部屋の中のカートまたは機器ラックなどの、適切な場所に配置された幾分固定的な装備品として使用されることが意図されている。つまり、病院モニタ３００は、ポータブル構成要素またはハンドヘルド構成要素であるように設計されていない。病院モニタ３００は、実質的に、臨床モニタ２００に関連して前述したとおりに動作するように適切に構成される。しかし、臨床モニタ２００とは異なり、病院モニタ３００は、注入ポンプ、およびこの注入ポンプの動作と関係する制御機能を含むことが可能である。さらに、病院モニタ３００は、ネットワーク通信モジュールとネットワークインターフェースとを使用することが可能であり、これらは協働して、病院ネットワークデバイスからのネットワーク通信を受信し、さらに／または病院ネットワークデバイスにネットワーク通信を送信する。本明細書で使用される「病院ネットワーク」とは、発信元構成要素と宛先構成要素との間のデータ通信をサポートするように構成されたハードウェア、ソフトウェア、ファームウェア、および／または処理ロジックを含め、任意の数の物理的構成要素または論理構成要素を指し、ここで、データ通信は、病院環境のために確保された、または病院環境において利用される１つ以上の通信プロトコルに従って実行される。
図４Ａは、本発明の例示的な実施形態に従って構成されたハンドヘルドモニタ／コントローラ４００の正面図である。ハンドヘルドモニタ／コントローラ４００は、臨床モニタ２００に類似し、両方のモニタは、いくつかの共有される特徴および機能を含む。簡明のため、そのような共通の特徴および機能を本明細書で冗長に説明することはしない。図１を参照すると、ハンドヘルドモニタ／コントローラ４００は、ローカル注入システム１０２内に（コマンド表示コントローラ１３８またはリモートコントロールデバイス１３４として）、さらに／またはネットワークデバイス１０４として（例えば、パーソナルデジタルアシスタント１２０として）配置されることが可能である。ハンドヘルドモニタ／コントローラ４００は、一般に、筐体４０２、ディスプレイ要素４０４、ユーザインターフェース特徴４０６、１つ以上のスピーカ４０８、１つ以上のローカルデバイスインターフェース（図示せず）、および１つ以上のネットワークインターフェース（図示せず）を含む。
ハンドヘルドモニタ／コントローラ４００は、ユーザによって携帯されることが可能なポータブルデバイスおよびモバイルデバイスとして使用されることが意図されている。特定の実施形態において、ハンドヘルドモニタ／コントローラ４００は、患者の注入ポンプとの無線通信をサポートし、ハンドヘルドモニタ／コントローラ４００の遠隔測定範囲は、局所化される。ハンドヘルドモニタ／コントローラ４００は、実質的に、臨床モニタ２００に関連して前述したとおりに動作するように適切に構成される。例示的な実施形態は、無線ローカルデバイスインターフェースおよび無線ネットワークインターフェースを利用するものの、ハンドヘルドモニタ／コントローラ４００は、ローカル注入システム内の他のデバイス、および／またはローカル注入システムの外部のネットワークデバイスに対する直接の物理的接続に対処する有線インターフェースを含むことも可能である。
ハンドヘルドモニタ／コントローラ４００（および本明細書で説明されるその他のポータブルデバイス）の電力は、バッテリによって供給されることが可能である。バッテリは、使い捨てバッテリ、または充電可能なバッテリであることが可能である。バッテリが充電可能である場合、バッテリが、筐体４０２内に留まっている間に、デバイスを電気コンセント、ドッキングステーション、ポータブル充電器などに接続するためのハンドヘルドモニタ／コントローラ４００上のコネクタまたは他のインターフェースが、存在することが可能である。また、充電可能なバッテリは、外部充電のために筐体４０２から取り外し可能であってもよい。しかし、実際には、充電可能なバッテリを、筐体４０２内に密閉し、耐水性もしくは防水性のより高いコンポーネントを作り出してもよい。さらなる実施形態において、ハンドヘルドモニタ／コントローラ４００は、複数のタイプのバッテリに対応するように適合されることが可能である。例えば、ハンドヘルドモニタ／コントローラ４００は、充電可能なバッテリ、および（バックアップの目的、または緊急時の目的で）ＡＡバッテリ（単三電池）、ＡＡＡバッテリ（単四電池）、またはコインバッテリなどの容易に入手可能なバッテリタイプに対応するように構成されることが可能である。
図４Ｂは、本発明の別の例示的な実施形態に従って構成されたハンドヘルドモニタ／コントローラ４１０の正面図である。ハンドヘルドモニタ／コントローラ４１０は、ハンドヘルドモニタ／コントローラ４００に類似し、両方のデバイスは、いくつかの共有される特徴および機能を含む。簡明のため、そのような共通の特徴および機能を本明細書で冗長に説明することはしない。
ハンドヘルドモニタ／コントローラ４１０は、好ましくは、モニタ／コントローラ４１０が、無線ローカル通信および／または無線ネットワーク通信を扱うことを可能にする無線データ通信機能を含む。さらに、ハンドヘルドモニタ／コントローラ４１０は、ケーブルコネクタ、ジャック、プラグ、またはレセプタクルとして実現されることが可能な有線ネットワークインターフェースもしくはケーブル配線ネットワークインターフェース４１２を含むことが可能である。図４Ｂは、ハンドヘルドモニタ／コントローラ４１０のディスプレイ要素４１４上に表示される例示的な内容を示す。この内容は、ハンドヘルドモニタ／コントローラ４１０に関する１つの特定の「スクリーンショット」を表し、実際には、任意の数の異なる表示スクリーンが、デバイスの意図される機能および特徴に合うように生成されることが可能である。図４Ｂの例示的なスクリーンショットは、クロック表示、ＲＦ品クオリティインジケータインジケータ４１６、バッテリインジケータ４１８、注入ポンプの中に残っている液体の量を表す液体レベルインジケータ４２０、患者に関する現在のＢＧ値（この例では、「２４０」）、および推奨されるボーラス（この例では、「４．３」ユニット）を含む。また、ハンドヘルドモニタ／コントローラ４１０は、ユーザに案内または指示を与える１つ以上のプロンプトを表示することもできる。この実施例では、ディスプレイ要素４１４は、「続けるなら「ＯＫ」を押してください」というプロンプト表示を含む。ユーザは、「ＯＫ」を押して、推奨されるボーラスを投与するように注入ポンプを制御する作動要求などの、他のオプションを表示することができる。
図５は、本発明の例示的な実施形態に従って構成された医療デバイスシステムモニタ５００の概略図である。モニタ５００は、モニタ５００の特定の構成に依存して、臨床モニタ、病院モニタ、またはハンドヘルドモニタ／コントローラとして実現されることが可能である。この実施例において、モニタ５００は、一般に、ローカルデバイスインターフェース５０２、ローカル通信モジュール５０４、ディスプレイ要素５０６、１つ以上のユーザインターフェース特徴５０８、ネットワーク通信モジュール５１０、ネットワークインターフェース５１２、処理アーキテクチャ５１４、および適切な量のメモリ５１６を含む。モニタ５００は、病院モニタとして実装される場合、注入ポンプ５１８、および注入ポンプ５１８の動作を制御するポンプコントローラ５２０も含むことが可能である（これらの要素は、これらの要素のオプションとしての性質を示すように破線内に示される）。モニタ５００の要素は、バス５２２、または任意の適切な相互接続アーキテクチャを介して互いに結合されることが可能である。
モニタ５００（および本明細書で開示される他のデバイス、要素、および構成要素）に関連して説明される様々な例示的なブロック、モジュール、回路、および処理ロジックは、ハードウェア、コンピュータソフトウェア、ファームウェア、または以上の任意の組合せで実施されることが可能であることが当業者には理解されよう。ハードウェア、ファームウェア、およびソフトウェアの互換性および適合性を明らかに示すのに、様々な例示的な構成要素、ブロック、モジュール、回路、および処理ステップが、機能の点で一般的に説明されることが可能である。そのような機能が、ハードウェアとして実施されるか、ファームウェアとして実施されるか、またはソフトウェアとして実施されるかは、その実施形態に課せられる特定の応用上の制約、および設計上の制約に依存する。本明細書で説明される概念に精通している人々は、それぞれの特定の応用先に適切な仕方で、そのような機能を実施することができるが、そのような実施上の決定が、本発明の範囲からの逸脱を生じさせると解釈されるべきではない。
図５を再び参照すると、ディスプレイ要素５０６およびユーザインターフェース特徴５０８が、臨床モニタ２００、病院モニタ３００、およびハンドヘルドモニタ／コントローラ４００に関連して前段で説明された。簡単に言うと、ディスプレイ要素５０６は、モニタ５００が、生理学的な患者データ、ローカルデバイスステータス情報、クロック情報、警報、警告、およびモニタ５００によって受信される、または処理される任意の情報／データを表示することを可能にするように適切に構成される。例えば、ディスプレイ要素５０６は、モニタ５００が、警告信号または警報信号を伝える着信する通信（注入システム内のローカルデバイスからの、または注入システムの外部のネットワークデバイスからの）を受信すると、警告ステータスまたは警報ステータスを示すように制御されることが可能である。ユーザインターフェース特徴５０８は、ユーザが、モニタ５００の動作を制御することを可能にする。１つの例示的な実施形態では、ユーザインターフェース特徴５０８は、ユーザが、ローカル注入システム内のさらなる１つ以上のデバイス、例えば、注入ポンプの動作を制御することができるようにする。さらに、モニタ５００は、ユーザインターフェース特徴５０８が、ローカル注入システムの外部の１つ以上のネットワークデバイスの動作を制御するように操作されることが可能であるように構成されることが可能である。
処理アーキテクチャ５１４は、汎用プロセッサ、内容をアドレス指定することが可能なメモリ、デジタルシグナルプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ、任意の適切なプログラマブルロジックデバイス、ディスクリートのゲートロジックまたはトランジスタロジック、ディスクリートのハードウェア構成要素、または本明細書で説明される機能を実行するように設計された任意の組合せを使用して実装される、または実行されることが可能である。プロセッサは、マイクロプロセッサ、コントローラ、マイクロコントローラ、または状態マシンとして実現されることが可能である。さらに、プロセッサは、コンピューティングデバイスの組合せ、例えば、デジタルシグナルプロセッサとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、デジタルシグナルプロセッサコアと連携した１つ以上のマイクロプロセッサ、または他の任意のそのような構成として実施されてもよい。
実際には、処理アーキテクチャ５１４は、ローカル注入システム内の送信デバイスから受信されるローカル通信の中で伝送される着信する情報、データ、および内容を解釈し、処理するように適切に構成されればよい。図１を参照すると、送信デバイスは、別のモニタデバイスを含め、ローカル注入システム１０２内のデバイスのいずれであることも可能である。そのような着信する情報には、例えば、ＢＧレベル（較正された読み取り値、または生の測定された値）などの、ユーザの生理学的データ、送信するローカルデバイスのステータス情報（例えば、バッテリ寿命指示、電力オン／オフステータス、送信信号電力レベル、自己試験の結果を示す診断情報）、送信するローカルデバイスの動作と関係する警告信号（例えば、バッテリ電力低下警告、範囲外警告、較正リマインダ）、注入ポンプによってユーザに送られる液体の基礎レート、注入ポンプによってユーザに送られる液体のボーラスに関するボーラス情報、患者のための助言情報（手動で、またはネットワーク接続を介して遠隔で補給品を発注するようにという通知、医師の予約をスケジュールするようにというリマインダ、介護者による分析のためのデータダウンロードをスケジュールする、または自動的に実行するリマインダ、定期的な診断を実行するようにという通知）が含まれるが、これに限定されるものではない。
また、処理アーキテクチャ５１４は、ローカル注入システムの外部の発信元デバイスによって生成されたネットワーク通信の中で伝送される、着信する情報、データ、および内容を解釈し、処理するように構成されてもよい。図１を参照すると、発信元デバイスは、ネットワーク化されたモニタデバイスを含め、任意のネットワークデバイス１０４であってもよい。そのような着信するネットワーク情報には、例えば、注入システム内のローカルデバイスに関するプログラミングデータ、注入システム内の注入ポンプ、または別のローカルデバイスに関する作動命令、注入システム内のローカルデバイスに関するステータス要求、ユーザの生理学的データを求める要求、注入システム内のローカルデバイスに関する警告もしくは警報のイネーブル命令またはディセーブル命令（モニタ５００によって処理される、さらに／またはモニタ５００によって適切なローカルデバイスにルーティングされることが可能である）、患者のための助言情報（手動で、またはネットワーク接続を介して遠隔で補給品を発注するようにという通知、医師の予約をスケジュールするようにというリマインダ、介護者による分析のためのデータダウンロードをスケジュールする、または自動的に実行するリマインダ、定期的な診断を実行するようにという通知）が含まれるが、これに限定されるものではない。
メモリ５１６は、ＲＡＭメモリ、フラッシュメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、または当技術分野で知られている他の任意の形態の記憶媒体として実現されることが可能である。これに関して、メモリ５１６は、処理アーキテクチャ５１４が、メモリ５１６から情報を読み取ることができ、さらにメモリ５１６に情報を書き込むことができるように、処理アーキテクチャ５１４に結合されることが可能である。代替として、メモリ５１６は、処理アーキテクチャ５１４と一体であってもよい。例として、処理アーキテクチャ５１４およびメモリ５１６は、ＡＳＩＣ内に存在することが可能である。この実施例では、メモリ５１６は、ユーザのデバイスステータスデータ５２４および／または生理学的データ５２６を格納するのに利用されることが可能であり、ただし、そのようなデータは、ローカル通信を介して、ネットワーク通信を介して、または直接に（例えば、モニタ５００が、テストストリップから直接に、または直接ユーザ入力を介してＢＧデータを受信するように構成されている場合）モニタ５００に通信される。
モニタ５００は、ネットワーク接続を介してアクセス可能なリモートデータベースまたはリモートデータバンクと通信するように構成されることが可能である。例えば、図１を参照すると、システム１００内のネットワークデバイス１０４が、モニタ５００にデータを提供するネットワークデータベース１２６として実現されることが可能である。そのような実施形態において、モニタ５００は、必要に応じて、リモートデータベースからデータをダウンロードし、必要な場合、そのデータをメモリ５１６の中に格納する、またはそれ以外で、ダウンロードされたデータを適切な仕方で処理することができる。
モニタ５００のある実施形態は、任意の数のローカル通信モジュール５０４、および任意の数のローカルデバイスインターフェース５０２を使用することができる。簡明のため、本明細書で説明される実施例は、１つのローカル通信モジュール５０４、および１つのローカルデバイスインターフェース５０２を使用する。ローカル通信モジュール５０４およびローカルデバイスインターフェース５０２は、モニタ５００と、ローカル注入システム内のデバイス（例えば、図１に示される注入システム内のデバイスのいずれか）との間のローカル通信をサポートするように適切に構成される。特定の実施態様では、ローカル通信モジュール５０４およびローカルデバイスインターフェース５０２は、モニタ５００から１つ以上のローカルデバイスへの単方向通信、１つ以上のローカルデバイスからモニタ５００への単方向通信、またはモニタ５００と１つ以上のローカルデバイスとの間の双方向通信をサポートするように構成してもよい。このため、ローカルデバイスインターフェース５０２は、ローカル注入システム内の送信デバイスからローカル通信を受信し、さらに／またはローカル注入システム内の受信デバイスにローカル通信を送信するように構成されることが可能である。さらに、特定の実施態様に依存して、ローカル通信モジュール５０４およびローカルデバイスインターフェース５０２は、無線データ通信をサポートするように、有線／ケーブル配線データ通信をサポートするように、あるいはその両方をサポートするように構成されることが可能である。
ローカル通信の無線伝送のため、ローカル通信モジュール５０４およびローカルデバイスインターフェース５０２は、モニタ５００と通信するローカルデバイスによってもサポートされる１つ以上の無線データ通信プロトコルをサポートする。例えば、ＲＦ、ＩｒＤＡ（赤外線）、Ｂｌｕｅｔｏｏｔｈ、ＺｉｇＢｅｅ（およびＩＥＥＥ８０２．１５プロトコルのその他の変種）、ＩＥＥＥ８０２．１１（任意の変種）、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ、または他の任意の変種）、直接シーケンス拡散スペクトル、周波数ホッピング拡散スペクトル、セルラー／無線／コードレス遠隔通信プロトコル、無線ホームネットワーク通信プロトコル、ページングネットワークプロトコル、磁気誘導、衛星データ通信プロトコル、ＷＭＴＳ帯域において動作するものなどの無線病院ネットワークプロトコルもしくは医療施設ネットワークプロトコル、ＧＰＲＳ、および無線ＵＳＢの変種などの独自の無線データ通信プロトコルを含む、任意の数の適切な無線データ通信プロトコル、無線データ通信技術、または無線データ通信方法が、モニタ５００によってサポートされることが可能である。ある実施形態では、無線ローカルデバイスインターフェース５０２は、ＲＦフロントエンド、適切に構成された無線モジュール（スタンドアロンモジュールであることも、デバイスの他の機能、またはすべての機能と一体化されることも可能である）、無線送信機、無線受信機、無線トランシーバ、赤外線センサ、電磁トランスデューサなどの、ハードウェア、ソフトウェア、および／またはファームウェアを含むこと、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。
ケーブル、有線接続、または他の物理リンクを介するローカル通信の伝送のため、ローカル通信モジュール５０４およびローカルデバイスインターフェース５０２は、モニタ５００と通信するローカルデバイスによってもサポートされる１つ以上の有線／ケーブル配線データ通信プロトコルをサポートする。例えば、イーサネット（商標）、ホームネットワーク通信プロトコル、ＵＳＢ、ＩＥＥＥ１３９４（Ｆｉｒｅｗｉｒｅ）、病院ネットワーク通信プロトコル、および独自のデータ通信プロトコルを含む、任意の数の適切なデータ通信プロトコル、データ通信技術、またはデータ通信方法が、モニタ５００によってサポートされることが可能であるが、これに限定されるものでははない。ある実施形態では、有線／ケーブル配線ローカルデバイスインターフェース５０２は、適切に構成され、フォーマットされたポート、コネクタ、ジャック、プラグ、レセプタクル、ソケット、アダプタなどの、ハードウェア、ソフトウェア、および／またはファームウェアを含むこと、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。
モニタ５００のある実施形態は、任意の数の通信モジュール５１０、および任意の数のネットワークインターフェース５１２を使用することができる。簡明のため、説明される実施例は、１つのネットワーク通信モジュール５１０、および１つのネットワークインターフェース５１２を使用する。ネットワーク通信モジュール５１０およびネットワークインターフェース５１２は、モニタ５００と、ローカル注入システムの外部のネットワークデバイス（例えば、図１に示される１つ以上のネットワークデバイス１０４）との間のネットワーク通信をサポートするように適切に構成される。特定の実施形態に依存して、ネットワーク通信モジュール５１０およびネットワークインターフェース５１２は、モニタ５００から１つ以上のネットワークデバイスへの単方向通信、１つ以上のネットワークデバイスからモニタ５００への単方向通信、またはモニタ５００と１つ以上のネットワークデバイスとの間の双方向通信をサポートするように構成されることが可能である。このため、ネットワークデバイスインターフェース５１２は、発信元ネットワークデバイスからの着信するネットワーク通信を受信し、さらに／または受信するネットワークデバイスへの発信されるネットワーク通信の伝送を可能にするように構成されることが可能である。さらに、特定の実施形態に依存して、ネットワーク通信モジュール５１０およびネットワークインターフェース５１２は、無線データ通信をサポートするように、有線／ケーブル配線データ通信をサポートするように、あるいはその両方をサポートするように構成されることが可能である。
ネットワーク通信の無線伝送のために、ネットワーク通信モジュール５１０およびネットワークインターフェース５１２は、モニタ５００と通信するネットワークデバイスによってもサポートされる１つ以上の無線データ通信プロトコルをサポートする。例えば、前段でリストアップされた無線プロトコルを含む、任意の数の適切な無線データ通信プロトコル、無線データ通信技術、または無線データ通信方法が、モニタ５００によってサポートされることが可能であるが、これに限定されるものではない。ある実施形態では、無線ネットワークインターフェース５１２は、無線ローカルデバイスインターフェース５０２に関して前述したとおり、ハードウェア、ソフトウェア、および／またはファームウェアを含む、またはハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。
ケーブル、有線接続、または他の物理リンクを介するネットワーク通信の伝送のため、ネットワーク通信モジュール５１０およびネットワークインターフェース５１２は、モニタ５００と通信するネットワークデバイスによってもサポートされる１つ以上の有線／ケーブル配線データ通信プロトコルをサポートする。例えば、前段でリストアップされる有線プロトコルまたはケーブル配線ベースのプロトコルを含む、任意の数の適切なデータ通信プロトコル、データ通信技術、またはデータ通信方法が、モニタ５００によってサポートされることが可能である。ある実施形態では、有線／ケーブル配線ネットワークインターフェース５１２は、有線／ケーブル配線ローカルデバイスインターフェース５０２に関して前述したとおり、ハードウェア、ソフトウェア、および／またはファームウェアを含む、またはハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。
図６は、モニタ５００で使用するのに適した汎用ネットワークインターフェース６００の概略図である。説明を容易にするため、ネットワークインターフェース６００は、いくつかの無線データ通信態様および有線／ケーブル配線データ通信態様を含む一般的なインターフェースとして表される。ネットワークインターフェース６００は、図６に示されるとおりの複数のインターフェースを含む必要はなく、実際、ある実施形態は、１つの特定のタイプのインターフェースだけしか利用しないことが可能である。ネットワークインターフェース６００には、一般に、イーサネットインターフェース６０２、８０２．１１インターフェース６０４、Ｂｌｕｅｔｏｏｔｈ（商標）インターフェース６０６、ページングネットワークインターフェース６０８、セルラー遠隔通信ネットワークインターフェース６１０、病院ネットワークインターフェース６１２、コードレス遠隔通信ネットワークインターフェース６１４、ホームネットワークインターフェース６１６、衛星ネットワークインターフェース６１８、およびその他のネットワークインターフェース６２０が含まれる。
イーサネットインターフェース６０２は、ネットワーク通信モジュール５１０と協働して、１つ以上のネットワークデバイスとのイーサネット準拠のネットワークデータ通信に対応するように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。例えば、イーサネットインターフェース６０２には、Ｔ−５６８Ａイーサネットコネクタ、Ｔ−５６８Ｂイーサネットコネクタ、ＲＪ−４５コネクタ、またはイーサネットケーブルに適合する任意のコネクタが含まれることが可能である。
８０２．１１インターフェース６０４は、ネットワーク通信モジュール５１０と協働して、１つ以上のネットワークデバイスとの８０２．１１準拠のネットワークデータ通信に対応するように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。例えば、８０２．１１インターフェース６０４には、適切な無線モジュール、８０２．１１トランシーバカード、ＲＦフロントエンド、ＲＦアンテナ、および／または８０２．１１アクセスポイント機能が含まれることが可能である。
Ｂｌｕｅｔｏｏｔｈインターフェース６０６は、ネットワーク通信モジュール５１０と協働して、１つ以上のネットワークデバイスとのＢｌｕｅｔｏｏｔｈ準拠のネットワークデータ通信をサポートするように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。例えば、Ｂｌｕｅｔｏｏｔｈインターフェース６０６には、適切な無線モジュール、Ｂｌｕｅｔｏｏｔｈトランシーバ、ＲＦフロントエンド、および／またはＲＦアンテナが含まれることが可能である。
ページングネットワークインターフェース６０８は、ネットワーク通信モジュール５１０と協働して、ページングネットワークプロトコルに準拠するネットワーク通信をサポートするように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。例えば、ページングネットワークインターフェース６０８には、適切な無線モジュール、トランシーバカード、ＲＦフロントエンド、および／またはＲＦアンテナが含まれることが可能である。
セルラー遠隔通信ネットワークインターフェース６１０は、ネットワーク通信モジュール５１０と協働して、セルラー遠隔通信プロトコル（例えば、ＣＤＭＡ、ＧＳＭなど）に準拠するネットワーク通信に対応するように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。例えば、セルラー遠隔通信ネットワークインターフェース６１０には、適切な無線モジュール、トランシーバカード、ＲＦフロントエンド、および／またはＲＦアンテナが含まれることが可能である。
病院ネットワークインターフェース６１２は、ネットワーク通信モジュール５１０と協働して、病院ネットワークプロトコルに準拠するネットワーク通信をサポートするように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。実施形態において、病院ネットワークプロトコルは、無線データ通信プロトコルであっても、有線／ケーブル配線データ通信プロトコルであってもよい。これに関して、無線病院ネットワークインターフェース６１２には、適切な無線モジュール、トランシーバカード、ＲＦフロントエンド、ＲＦアンテナ、赤外線送信機、赤外線センサ、磁気誘導トランスデューサなどが含まれることが可能である。特定の配置に依存して、無線病院ネットワークインターフェース６１２は、本明細書で説明される、その他の無線／コードレスデータ通信プロトコルのいずれに準拠することも可能である。有線／ケーブル配線病院ネットワークインターフェース６１２には、適切に構成されたコネクタ、ソケット、ジャック、プラグ、またはアダプタが含まれることが可能である。さらに、特定の応用先に応じて、有線／ケーブル配線病院ネットワークインターフェース６１２は、本明細書で説明される、その他の有線／ケーブル配線データ通信プロトコルのいずれに準拠することも可能である。
コードレス遠隔通信ネットワークインターフェース６１４は、ネットワーク通信モジュール５１０と協働して、コードレス遠隔通信プロトコルに準拠するネットワーク通信をサポートするように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。そのようなプロトコルは、一般に、家庭のコードレス電話システムにおいて使用される。実際には、コードレス遠隔通信ネットワークインターフェース６１４には、適切な無線モジュール、コードレス電話基地局、トランシーバカード、ＲＦフロントエンド、および／またはＲＦアンテナが含まれることが可能である。
ホームネットワークインターフェース６１６は、ネットワーク通信モジュール５１０と協働して、ホームネットワークプロトコルに準拠するネットワーク通信をサポートするように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。そのようなホームネットワークプロトコルは、ホーム制御システム、既存の電話配線、または既存のＡＣ電力線を活用するホームコンピューティングネットワーク、ホームセキュリティシステムもしくはホーム警報システム、ホームエンターテイメントシステムなどに関連して利用されることが可能である。実施形態において、ホームネットワークプロトコルは、無線データ通信プロトコルであっても、有線／ケーブル配線データ通信プロトコルであってもよい。これに関して、無線ホームネットワークインターフェース６１６には、適切な無線モジュール、トランシーバ基地局、トランシーバカード、ＲＦフロントエンド、ＲＦアンテナ、赤外線送信機、赤外線センサ、磁気誘導トランスデューサなどが含まれることが可能である。特定の配置に依存して、無線ホームネットワークインターフェース６１６は、本明細書で説明される、その他の無線／コードレスデータ通信プロトコルのいずれに準拠することも可能である。有線／ケーブル配線ホームネットワークインターフェース６１６には、適切に構成されたコネクタ、ソケット、ジャック、プラグ、またはアダプタが含まれることが可能である。さらに、特定の応用先に応じて、有線／ケーブル配線ネットワークインターフェース６１６は、本明細書で説明される、その他の有線／ケーブル配線データ通信プロトコルのいずれに準拠することも可能である。
衛星ネットワークインターフェース６１８は、ネットワーク通信モジュール５１０と協働して衛星データ通信プロトコルに準拠するネットワーク通信に対応するように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。例えば、衛星ネットワークインターフェース６１８には、適切な無線モジュール、トランシーバカード、ＲＦフロントエンド、および／またはＲＦアンテナが含まれることが可能である。代替として（またはさらに）、衛星ネットワークインターフェース６１８には、別個の衛星ネットワーク機器、例えば、サテライトディッシュ（衛星アンテナ）または衛星トランシーバモジュールに対する有線／ケーブル配線接続を円滑にする、適切に構成されたコネクタ、ソケット、ジャック、プラグ、またはアダプタが含まれることが可能である。
実際には、ネットワークインターフェース６００は、前述した特定のタイプ以外の任意の数のネットワークインターフェース６２０を利用することができる。他のそのようなネットワークインターフェース６２０は、一般に知られているか、独自であるかにかかわらず、既存のデータ通信プロトコルに従ってネットワーク通信をサポートするように適切に構成されることが可能である。さらに、他のネットワークインターフェース６２０は、ネットワークインターフェース６００が、将来に開発される可能性がある無線データ通信プロトコルまたは有線データ通信プロトコルをサポートすることを可能にする。
図７は、モニタ５００で使用するのに適したネットワーク通信モジュール７００の概略図である。説明を容易にするため、ネットワーク通信モジュール７００は、様々なタイプのネットワーク通信を扱うための処理ロジックを含む一般的なモジュールとして表される。実際には、ネットワーク通信モジュール７００は、図７に示されるような様々なモードのネットワーク通信をサポートする必要はなく、実際、ある実施形態は、１つの特定のネットワーク通信フォーマットもしくはネットワーク通信タイプだけしか処理しないようにしてもよい。ネットワーク通信モジュール７００には、一般に、電子メール生成ロジック７０２、ポケットベルメッセージ生成ロジック７０４、テキストメッセージ生成ロジック７０６、ボイスメール生成ロジック７０８、電話ダイヤル呼び出しロジック７１０、警告／警報生成ロジック７１２、ウェブブラウザ／サーバ７１４、オーディオ信号／ファイル生成ロジック７１６、ビデオ信号／ファイル生成ロジック７１８、制御信号生成ロジック７２０、および他のネットワーク通信生成ロジック７２２が含まれる。
電子メール生成ロジック７０２は、ネットワーク通信を電子メールとして生成するように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。例えば、電子メール生成ロジック７０２は、宛先ネットワークデバイスを宛先とする通知、警告、警報、ステータスレポート、生理学的データ、または他の情報を伝える自動的電子メール、またはユーザによって作成された電子メールを生成することができる。実施形態において、電子メール生成ロジック７０２は、ウェブベースの電子メールシステムを含め、任意の適切な電子メールシステムまたは電子メール技術に適合することが可能である。
ポケットベルメッセージ生成ロジック７０４は、ネットワーク通信をポケットベルメッセージとして生成するように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。例えば、ポケットベルメッセージ生成ロジック７０４は、ポケットベルデバイス、または任意の適合する宛先ネットワークデバイスを宛先とする通知、警告、警報、ステータスレポート、生理学的データ、または他の情報を伝える自動的ポケットベルメッセージ、またはユーザによって作成されたポケットベルメッセージを生成することができる。実施形態において、ポケットベルメッセージ生成ロジック７０４は、ウェブベースのページングシステムを含め、任意の適切なポケットベルシステムまたはポケットベル技術に適合することが可能である。
テキストメッセージ生成ロジック７０６は、ネットワーク通信をテキストメッセージとして生成するように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。そのようなテキストメッセージは、既存の電話網、既存のポケットベル網、インターネット、ローカルエリアネットワーク、病院ネットワーク、ホームネットワークなどを介して伝送されることが可能である。例えば、テキストメッセージ生成ロジック７０６は、任意の適合する宛先ネットワークデバイスを宛先とする通知、警告、警報、ステータスレポート、生理学的データ、または他の情報を伝える自動的テキストメッセージ、またはユーザによって作成されたテキストメッセージを生成することができる。実施形態において、テキストメッセージ生成ロジック７０６は、任意の適切なテキストメッセージングアプリケーションまたはテキストメッセージング技術に適合することが可能である。
ボイスメール生成ロジック７０８は、ネットワーク通信をボイスメールメッセージとして生成するように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。例えば、ボイスメールメッセージ生成ロジック７０８は、任意の適合する宛先ネットワークデバイスを宛先とする通知、警告、警報、ステータスレポート、生理学的データ、または他の情報を伝える自動的ボイスメールメッセージ、またはユーザによって作成されたボイスメールメッセージを生成することができる。実施形態において、そのようなボイスメールメッセージは、電子添付ファイルとして伝送するのに適したオーディオファイルとして生成されることが可能である。受信すると、宛先ネットワークデバイスは、適切な再生機構、マルチメディアアプリケーションなどを使用して、このボイスメールメッセージを再生することができる。実施形態において、ボイスメール生成ロジック７０８は、任意の適切なボイスメッセージング、電話システム、またはマルチメディアアプリケーションに適合することが可能である。
電話ダイヤル呼び出しロジック７１０は、ネットワーク通信を発信される電話コールとして生成するように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。例えば、電話ダイヤル呼び出しロジック７１０は、必要に応じて、発信電話番号をダイヤル呼び出しして（自動的に、またはユーザ対話に応答して）、任意の適切な宛先ネットワークデバイスを宛先とする通知、警告、警報、ステータスレポート、生理学的データ、または他の情報を伝送するように構成されることが可能である。また、電話ダイヤル呼び出しロジック７１０は、ネットワーク通信モジュール７００の、その他の論理構成要素の１つ以上、例えば、ボイスメール生成ロジック７０８と協働して、いくつかのネットワーク通信の伝送を円滑にすることもできる。実施形態において、電話ダイヤル呼び出しロジック７１０は、任意の適切な電話システムまたは電話アプリケーションに適合することが可能である。
警告／警報生成ロジック７１２は、ネットワークデバイスに配信されることが意図される警告および／または警報を生成するように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。例えば、警告／警報生成ロジック７１２は、例えば、以下のいずれかを示す自動的な警告もしくは警報、またはユーザによって作成された警告もしくは警報を生成することができるが、これらに限定されるものではない。すなわち、ローカル注入システム内のデバイスのバッテリステータス、患者の生理学的特性が、所定の閾値を超えた場合、ローカル注入システム内の遠隔測定されるデバイスが、モニタの範囲から外れている場合、ローカル注入システム内の機器に関するスケジュールされた較正、または注入システムの運用と関係する任意のスケジュールされたイベント、である。実施形態において、警告／警報生成ロジック７１２は、ネットワーク通信モジュール７００のその他の論理構成要素、例えば、テキストメッセージ生成ロジック７０６と協働して、警告および警報のフォーマットおよびネットワーク伝送を円滑にすることができる。受信すると、宛先ネットワークデバイスは、適切な再生機構、マルチメディアアプリケーション、発光要素、スピーカなどを使用して、警告／警報を生成することができる。
ウェブブラウザ／サーバ７１４は、ネットワーク通信をマークアップ言語ドキュメント、例えば、ＨＴＭＬドキュメントとして生成するように構成されたソフトウェアアプリケーションを表す。さらに、ウェブブラウザ／サーバ７１４は、モニタデバイスが、インターネットを介してウェブページにアクセスすることを可能にする従来のウェブブラウズ能力を含むことが可能である。これに関して、ウェブブラウザ／サーバ７１４は、ネットワーク通信モジュール７００のその他の論理構成要素、例えば、電子メール生成ロジック７０２またはテキストメッセージ生成ロジック７０６と協働して、いくつかのネットワーク通信の送受信を円滑にすることができる。ウェブブラウザアプリケーションおよびウェブサーバアプリケーションは、周知であり、したがって、本明細書で詳細に説明することはしない。
オーディオ信号／ファイル生成ロジック７１６は、ネットワーク通信をオーディオ信号および／またはオーディオファイルとして生成するように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。オーディオ信号またはオーディオファイルは、モニタデバイスに（またはオーディオ信号またはオーディオファイルを作成するデバイス）にあらかじめプログラミングされることが可能である。代替として、オーディオ信号またはオーディオファイルは、モニタデバイスのユーザによって（またはモニタデバイスと通信するデバイスのユーザによって）作成されてもよい。例えば、オーディオ信号／ファイル生成ロジック７１６は、任意の適合する宛先ネットワークデバイスを宛先とする通知、警告、警報、ステータスレポート、生理学的データ、または他の情報を伝える自動的なオーディオ信号もしくはオーディオファイル、またはユーザによって作成されたオーディオ信号もしくはオーディオファイルを生成することができる。オーディオベースの警告／警報は、モニタデバイスによって、またはモニタデバイスと通信するデバイスによって自動的に開始されることが可能である。代替として、オーディオベースの警告／警報は、モニタデバイスにおける、またはモニタデバイスと通信するデバイスにおけるユーザ、患者、または介護者によって開始されてもよい。受信すると、宛先ネットワークデバイスは、適切な再生機構、マルチメディアアプリケーションなどを使用して、このオーディオ信号またはオーディオファイルを再生することができる。
本明細書で使用されるオーディオ信号とは、例えば、ストリーミングオーディオ信号、ブロードキャスト無線信号、または宛先ネットワークデバイスにおいてオーディオの生成を開始する制御信号であり、オーディオファイルは、宛先ネットワークデバイスによって受信され、解釈されるファイルを表す（宛先ネットワークデバイスは、その後、このオーディオファイルを実行してオーディオを生成する）。例えば、オーディオ信号／ファイル生成ロジック７１６は、ＭＰ３オーディオファイル、ＷＭＡオーディオファイルなどを生成するように構成されることが可能である。これに関して、オーディオ信号／ファイル生成ロジック７１６は、ネットワーク通信モジュール７００の、その他の論理構成要素の１つ以上、例えば、ボイスメール生成ロジック７０８または警告／警報生成ロジック７１２と協働して、いくつかのネットワーク通信の送受信を円滑にすることができる。
ビデオ信号／ファイル生成ロジック７１８は、ネットワーク通信をビデオ信号および／またはビデオファイルとして生成するように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。ビデオ信号またはビデオファイルは、モニタデバイスに（またはオーディオ信号またはオーディオファイルを作成するデバイス）にあらかじめプログラミングされることが可能である。代替として、ビデオ信号またはビデオファイルは、モニタデバイスのユーザによって（またはモニタデバイスと通信するデバイスのユーザによって）作成されてもよい。例えば、ビデオ信号／ファイル生成ロジック７１８は、任意の適合する宛先ネットワークデバイスを宛先とする通知、警告、警報、ステータスレポート、生理学的データ、または他の情報を伝える自動的なビデオ信号もしくはビデオファイル、またはユーザによって作成されたビデオ信号もしくはビデオファイルを生成することができる。ビデオベースの警告／警報は、モニタデバイスによって、またはモニタデバイスと通信するデバイスによって自動的に開始されることが可能である。代替として、ビデオベースの警告／警報は、モニタデバイスにおける、またはモニタデバイスと通信するデバイスにおけるユーザ、患者、または介護者によって開始されてもよい。受信すると、宛先ネットワークデバイスは、適切な再生機構、マルチメディアアプリケーションなどを使用して、このビデオ信号またはビデオファイルを再生することができる。
本明細書で使用されるビデオ信号とは、例えばストリーミングビデオ信号、ブロードキャストビデオ信号、または宛先ネットワークデバイスにおいてビデオの生成を開始する制御信号であることが可能であり、ビデオファイルは、宛先ネットワークデバイスによって受信され、解釈されるファイルを表す（宛先ネットワークデバイスは、その後、このビデオファイルを実行してビデオを生成する）。例えば、ビデオ信号／ファイル生成ロジック７１８は、ＭＰＥＧビデオファイル、ＪＰＧイメージファイルなどを生成するように構成されることが可能である。これに関して、ビデオ信号／ファイル生成ロジック７１８は、ネットワーク通信モジュール７００の、その他の論理構成要素の１つ以上、例えば、警告／警報生成ロジック７１２と協働して、いくつかのネットワーク通信の送受信を円滑にすることができる。
制御信号生成ロジック７２０は、ネットワーク通信を、受信するネットワークデバイスに関する制御信号として生成するように適切に構成されたハードウェア、ソフトウェア、および／またはファームウェアを含む、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。例えば、制御信号生成ロジック７２０は、通知、警告、警報、表示の生成を開始する、またはそれ以外で、任意の適合する宛先ネットワークデバイスの動作を制御する自動的制御信号、またはユーザによって作成された制御信号を生成することができる。そのような制御信号を受信すると、宛先ネットワークデバイスは、適切な仕方で、つまり、ディスプレイを作動させる、振動要素を作動させる、発光要素を作動させる、オーディオ応答もしくはビデオ応答を生成するなどして、応答する。実施形態において、制御信号生成ロジック７２０は、ネットワーク通信モジュール７００のその他の論理構成要素の１つ以上、例えば、警告／警報生成ロジック７１２と協働して、制御信号のフォーマット（書式設定）およびネットワーク伝送を円滑にすることができる。
実際には、ネットワーク通信モジュール７００は、前述した特定のタイプの代わりに、またはそのようなタイプに加えて、他のネットワーク通信生成ロジック７２２を利用してもよい。他のそのような論理構成要素は、一般に知られているか、独自であるかにかかわらず、様々な既存のフォーマットでネットワーク通信を生成するように適切に構成されることが可能である。さらに、他のそのような論理構成要素は、ネットワーク通信モジュール７００が、将来に開発される可能性があるさらなるフォーマットをサポートすることを可能にする。
図８は、本発明の例示的な実施形態に従って構成されたネットワークベースの医療デバイスシステム８００の概略図である。システム８００は、本明細書で説明されるデバイス、技術、および方法のいくつかを利用することが可能なシステムの１つの単純な実施形態を表す。膨大な数の代替の構成が、本発明の範囲内で構築され、動作させられることが可能である。例えば、システム８００は、以下では注入ポンプに関連して説明されるものの、注入ポンプは、本発明の実施形態のための要件ではない。
ネットワークベースの注入システム８００は、一般に、注入ポンプ８０２、モニタデバイス８０４（またはローカル注入システム内にあると定義される任意の適切なローカルデバイス）、およびネットワークデバイス８０６を含む。この例示的な実施形態において、モニタデバイス８０４およびネットワークデバイス８０６は、データ通信ネットワーク８０８において確立された任意の数のネットワーク通信リンクを介して互いに通信する。さらに、要件ではないものの、図８は、モニタデバイス８０４とネットワークデバイス８０６との間の双方向通信を示す。ネットワークデバイス８０６は、例えば、ネットワークベースのモニタ、ネットワーク化されたコンピュータ、セルラー電話機もしくは他の移動コンピューティングデバイス、図１に関連して説明される任意のネットワークデバイス１０４、または他の箇所で説明される任意のネットワークベースのデバイスであることが可能である。データ通信ネットワーク８０８は、例えば、インターネット、セルラー遠隔通信ネットワーク、ページングシステムネットワーク、ローカルエリアネットワークもしくはワイドエリアネットワーク、図１に関連して説明される任意の無線ネットワークもしくは有線ネットワーク、または他の箇所で説明される任意のネットワークである（またはそのようなネットワークを含む）ことが可能である。
図８に関連して詳細に説明されるとおり、モニタ８０４は、ローカルデバイスインターフェース８１０、ネットワークインターフェース８１２、および１つ以上の適切な通信モジュール８１４（例えば、ローカル通信モジュールおよび／またはネットワーク通信モジュール）を含むことが可能である。ネットワークデバイス８０６は、ネットワークインターフェース８１２との互換性のために構成されたネットワークインターフェース８１６、１つ以上の適切に構成された通信モジュール８１８、ディスプレイ要素８２０、およびユーザインターフェース機能８２２を含むことが可能である。ネットワークインターフェース８１６は、ネットワークインターフェース５１２に関連して前述し、さらにネットワークインターフェース６００に関連して前述したとおり構成されることが可能である。通信モジュール８１８は、ネットワーク通信モジュール５１０に関連して前述し、さらにネットワーク通信モジュール７００に関連して前述したとおり構成されることが可能である。通信モジュール８１８は、ネットワークデバイス８０６が、モニタデバイス８０４から受信されるネットワーク通信を受信し、処理し、解釈することを可能にするように構成される。さらに、通信モジュール８１８は、ネットワークデバイス８０６が、モニタデバイス８０４を宛先とする送出するネットワーク通信を処理し、生成し、送信することを可能にするように構成される。ユーザインターフェース機能８２２およびディスプレイ要素８２０は、ネットワークデバイス８０６のユーザが、注入ポンプ８０２もしくはモニタデバイス８０４において表示されることが可能なデータを遠隔で見ること、モニタデバイス８０４もしくは注入ポンプ８０２を遠隔制御すること、および／またはモニタデバイス８０４もしくは注入ポンプ８０２の動作パラメータを遠隔でプログラミングする、もしくは変更することができるようにする。
ネットワークベースの注入システム８００の一部の実施形態において、注入ポンプ８０２とモニタデバイス８０４は、第１のデータ通信プロトコルを使用して通信するのに対して、モニタデバイス８０４とネットワークデバイス８０６は、第２のデータ通信プロトコル（またはプロトコルの組合せ）を使用して通信する。注入ポンプ８０２とモニタデバイス８０４との間のローカル通信は、無線であっても、有線であってもよい１つ以上のローカル通信リンク８２４を介して伝送される。モニタデバイス８０４とネットワークデバイス８０６との間のネットワーク通信は、無線であっても、有線であってもよい１つ以上のネットワーク通信リンク８２６を介して伝送される。例えば、注入ポンプ８０２は、ローカル通信（ポンプステータス情報などの）をモニタデバイス８０４に送信することができ、ここで、ローカル通信は、Ｂｌｕｅｔｏｏｔｈデータ通信プロトコルに従って伝送される。さらに、注入ポンプ８０２は、同一のＢｌｕｅｔｏｏｔｈプロトコルを使用してモニタデバイス８０４から着信するデータを受信することができる。これに対して、モニタデバイス８０４は、ネットワーク通信（ポンプステータス情報、警告、または患者データなどの）をネットワークデバイス８０６に送信することができ、ここで、ネットワーク通信は、ＣＤＭＡなどのセルラー遠隔通信プロトコルに従って送信される。同様に、モニタデバイス８０４は、同一のＣＤＭＡプロトコルを使用してネットワークデバイス８０６から着信するデータを受信することができる。
図９は、例示的なネットワークベースの医療デバイスシステム監視プロセス９００を示す流れ図である。プロセス９００に関連して実行される様々なタスクは、ソフトウェアによって、ハードウェアによって、ファームウェアによって、あるいは任意の組合せによって実行されることが可能である。例示の目的で、プロセス９００の以下の説明は、図１〜図８に関連して前述した要素を参照する可能性がある。実施形態において、プロセス９００の諸部分が、説明されるシステムの様々な要素、例えば、ネットワークデバイス、または機能要素、または動作構成要素によって実行されることが可能である。プロセス９００は、任意の数のさらなるタスク、または代替のタスクを含むことが可能であり、図９に示されるタスクは、例示される順序で実行されなくてもよく、プロセス９００は、本明細書で詳細に説明されないさらなる機能を有する、より包括的な手続きまたはプロセスに組み込まれてもよいことを理解されたい。
監視プロセス９００は、ユーザの身体への液体の注入を制御する注入ポンプを有するローカル注入システムの外部にあるネットワークデバイスによって実行されることが可能である。プロセス９００は、例えば、ネットワークデバイスが、ローカル注入ポンプに関連するポンプデータを伝えるネットワーク通信を受信すると（タスク９０２）開始される。ネットワーク通信は、臨床モニタデバイス、病院モニタデバイス、生理学的特性メータ、リモートコントローラ、ハンドヘルドモニタ／コントローラ、注入ポンプ自体などの、ローカル注入システム内の任意の送信デバイスによって生成される（またはそのようなデバイスを発信元とする）ことが可能である。ポンプデータには、例えば、ユーザ／患者の生理学的データ、警報、警告、グラフまたはチャートデータ、注入ポンプによって送られる液体の基礎レート、注入ポンプによって送られる液体のボーラスに関するボーラス情報、または任意の適切にフォーマットされたテキスト情報、オーディオ情報、または視覚的情報を含め、注入ポンプおよび／または送信デバイスの動作、制御、プログラミング、またはステータスと関係する任意の情報またはコンテンツが含まれるが、これらに限定されるものではない。図５および図６に関連して前述したとおり、ネットワークデバイスは、例えば、イーサネットプロトコル、ＩＥＥＥ８０２．１１プロトコル（任意の変種）、Ｂｌｕｅｔｏｏｔｈプロトコル、ページングネットワークプロトコル、セルラー遠隔通信プロトコル（例えば、ＣＤＭＡまたはＧＳＭ）、コードレス遠隔通信プロトコル、ホームネットワークデータ通信プロトコル、衛星データ通信プロトコル、病院ネットワークプロトコル、あるいはネットワークデバイスが、無線通信リンク、ケーブル配線通信リンク、および／または有線通信リンクを介してネットワーク通信を受信することを可能にする任意の適切な無線データ通信プロトコルまたは有線／ケーブル配線データ通信プロトコルを含む、１つ以上の適切なデータ通信プロトコルに準拠してネットワーク通信を受信することができる。
実際には、ネットワークデバイスは、受信されたネットワーク通信を処理して、ネットワーク通信からポンプデータを抽出する（タスク９０４）。タスク９０４は、ネットワークデバイスに存在する適切に構成された通信モジュール、および／または適切に構成された処理アーキテクチャによって実行されることが可能である。そのような処理に応答して、ネットワークデバイスは、ネットワークデバイスにおける表示、再生、ブロードキャスト、またはレンダリングのためにポンプデータの表示を生成することができる（タスク９０６）。タスク９０６に関連して、ネットワークデバイスは、受信された生理学的データの表示を生成する、ローカルデバイスステータス情報の表示を生成する、警告または警報の表示を生成する、輸液の基礎レートの表示を生成する、ボーラス情報の表示を生成するなどのことを行うことができる。実施形態において、ネットワークデバイスは、例えば、可聴の警報、警告、記録、または可聴信号などの、ポンプデータの可聴の表現を生成すること、グラフまたはテキスト表示などの、ポンプデータの視覚的表現を生成すること、ネットワークデバイスの発光要素、例えば、インジケータライトまたは明滅するディスプレイスクリーンを作動させること、またはネットワークデバイスの振動要素を作動させることを含め、任意の適切な仕方でポンプデータの表示を生成することができる。
監視プロセス９００は、ネットワークデバイスが、ローカル注入システム内のデバイスにネットワーク通信を送り返すことができるものと想定する。これに関して、プロセス９００は、注入システム内のローカルデバイスに対応する１つ以上のデータ通信プロトコルを選択する、または決定することができる（タスク９０８）。タスク９０８は、ネットワークデバイスが、ローカルデバイスに適合する通信のために適切なプロトコルを利用することを確実にするように実行されることが可能である。また、ネットワークデバイスは、注入ポンプ、または注入システム内の別のローカルデバイスを宛先とする命令またはプログラミングパラメータを獲得する、または生成することもできる。そのような命令またはプログラミングパラメータは、ネットワークデバイスによって生成される、またはネットワークデバイスの操作者から獲得されることが可能である。ネットワークデバイスは、命令またはプログラミングパラメータを伝える適切に構成された制御通信を生成するように構成されることが可能である（タスク９１０）。特定のシステム配置、および特定の動作条件に依存して、例示的な制御通信には、例えば、以下が含まれることが可能である。すなわち、警告ディセーブル命令、注入ポンプまたは任意のローカルデバイスに関する作動命令、注入ポンプまたは任意のローカルデバイスに関するプログラミングパラメータ、またはソフトウェアプログラム（メインアプリケーションコード、またはモータ制御などの補助的機能コード、ＲＦ遠隔測定コードなど）のアップロードである。最終的に、ネットワークデバイスは、適切なフォーマットで、ローカルデバイスとの通信セッションのために利用される特定のデータ通信プロトコルに準拠して、制御通信を送信することができる（タスク９１２）。受信すると、受信するローカルデバイスは、この制御通信を適切な仕方で処理することができる。
本発明の代替の実施形態において、監視プロセス９００は、注入ポンプを含まない医療デバイスシステムに関連して使用されるように変形されることが可能である。例えば、プロセス９００のタスクは、例えば患者データ、モニタデータ、またはローカルシステム内のデバイスなどを発信元とする他の医療デバイス情報を伝えるネットワーク通信を受信して、処理する同等の仕方で実行されることが可能であり、そのようなデータは、ポンプデータを含まなくてもよい。
図１０は、例示的なネットワークベースの医療デバイスシステム通信プロセス１０００を表す流れ図である。プロセス１０００に関連して実行される様々なタスクは、ソフトウェアによって、ハードウェアによって、ファームウェアによって、あるいはソフトウェアとハードウェアとファームウェアの任意の組合せによって実行されることが可能である。例示の目的で、プロセス１０００の以下の説明は、図１〜図８に関連して前述した要素を参照する場合もある。実施形態において、プロセス１０００の諸部分は、説明されるシステムの様々な要素、例えば、注入システム内のローカルデバイス、あるいは機能要素または動作構成要素によって実行されることが可能である。プロセス１０００は、任意の数のさらなるタスク、または代替のタスクを含むことが可能であり、図１０に示されるタスクは、例示される順序で実行されなくてもよく、プロセス１０００は、本明細書で詳細に説明されないさらなる機能を有する、より包括的な手続きまたはプロセスに組み込まれてもよいことを理解されたい。
ネットワーク通信プロセス１０００は、ローカル医療デバイスシステム内、例えば、ユーザの身体への液体の注入を制御する注入ポンプを有するローカル注入システム内に存在する送信デバイスによって実行されることが可能である。例えば、送信デバイスは、臨床モニタデバイス、病院モニタデバイス、生理学的特性メータ、生理学的特性センサ送信機、リモートコントローラ、ハンドヘルドモニタ／コントローラ、注入ポンプ自体などの、ローカル注入システム内の任意のローカルデバイスであることが可能である。プロセス１０００は、例えば送信デバイスが、注入ポンプの動作と関係し、さらに／または別のローカルデバイスの動作と関係する通知（タスク１００２）を獲得する（内部で、別のデバイスから、またはユーザから）、または生成すると、始まることが可能である。本明細書で使用される通知とは、例えば、別のデバイスに転送されることが意図され、あるいは送信デバイスによる応答を呼び出すプロンプトまたはトリガとして利用される任意の信号、警告、警報、コンテンツ、データ、または情報であることが可能である。
ネットワーク通信プロセス１０００は、外部の受信デバイス（この実施例ではネットワークデバイスであり、これは通知先として意図された受信側である）を選択する、または決定することができる（タスク１００４）。さらに、プロセス１０００は、意図された外部の受信デバイスに対応する１つ以上のデータ通信プロトコルを選択する、または決定することができる（タスク１００６）。タスク１００６は、ローカルの送信デバイスが、ネットワークデバイスに適合する通信のために適切なプロトコルを利用することを確実にするように実行されることが可能である。図５および図６に関連して前述したとおり、ローカルデバイスは、例えば、以下に示す１つ以上の適切なデータ通信プロトコルに準拠してネットワーク通信を送信することができる。すなわち、イーサネットプロトコル、ＩＥＥＥ８０２．１１プロトコル（任意の変種）、Ｂｌｕｅｔｏｏｔｈプロトコル、ページングネットワークプロトコル、セルラー遠隔通信プロトコル（例えば、ＣＤＭＡまたはＧＳＭ）、コードレス遠隔通信プロトコル、ホームネットワークデータ通信プロトコル、衛星データ通信プロトコル、病院ネットワークプロトコル、あるいは、任意の適切な無線データ通信プロトコルまたは有線／ケーブル配線データ通信プロトコルであってローカルデバイスが、無線通信リンク、ケーブル配線通信リンク、および／または有線通信リンクを介してネットワーク通信を送信することを可能にするもの、である。但し、これらに限定されるものではない。
ローカルの送信デバイスは、通知を伝えるネットワーク通信を生成することができ（タスク１００８）、このネットワーク通信は、選択されたデータ通信プロトコルに適合する。実施形態によれば、ネットワーク通信は、注入ポンプおよび／または送信デバイスの動作、制御、プログラミング、またはステータスと関係する任意の情報または内容を含むことが可能であり、このような情報または内容には、例えば、ユーザ／患者の生理学的データ、警報、警告、グラフまたはチャートデータ、注入ポンプによって送られる液体の基礎レート、注入ポンプによって送られる液体のボーラスに関するボーラス情報、または任意の適切にフォーマットされたテキスト情報、オーディオ情報、または視覚的情報が含まれるが、これらに限定されるものではない。図７に関連して前述したとおり、ネットワーク通信は、例えば、様々なメッセージタイプ、ファイルタイプ、または信号タイプとしてフォーマットされる（またはそのようなタイプを含む）ことが可能であり、これらタイプには、例えば電子メールメッセージ、ポケットベルメッセージ、テキストメッセージ、ボイスメールメッセージ、受信するネットワークデバイスへの発信される電話コール、ウェブページなどのマークアップ言語ドキュメント、オーディオ信号、オーディオファイル、ビデオ信号、またはビデオファイルを含まれる。
最終的に、ローカルの送信デバイスは、ネットワーク通信を外部の受信デバイスに送信する（タスク１０１０）。ローカルデバイスは、タスク１００６中に選択されたネットワークデータ通信プロトコルに従ってネットワーク通信を送信する。１つの実施例において、ネットワーク通信は、送信される電話コールの中で伝送され、ローカルの送信デバイスは、宛先ネットワークデバイスに発信される電話コールを開始することによって、ネットワーク通信を送信する。他の例示的な実施形態において、タスク１０１０は、指定されたタイプおよびフォーマットを有するメッセージ、ファイル、および／または信号の伝送を表す。ネットワーク通信を受信すると、宛先ネットワークデバイスは、適切な仕方で、この通知を処理することができる。
本発明の代替の実施形態において、プロセス１０００は、注入ポンプを含まない医療デバイスシステムに関連して使用されるように変形されることが可能である。例えば、プロセス１０００のタスクは、患者データ、モニタデータ、またはローカルシステム内のデバイスを発信元とすることが可能な他の医療デバイス情報を伝えるネットワーク通信を処理して、送信するのと同等の仕方で実行されることが可能であり、そのような情報は、ポンプデータを含まなくてもよい。
図１１は、例示的なネットワークベースの注入ポンプ監視／制御プロセス１１００を示す流れ図である。プロセス１１００は、ネットワークベースの注入ポンプシステムを動作させるための１つの例示的な技術を表す。システムは、任意の数の代替の技術および方法をサポートすることができる可能性があり、プロセス１１００の以下の説明は、本発明の範囲または応用を限定することはまったく意図していない。プロセス１１００に関連して実行される様々なタスクは、ソフトウェアによって、ハードウェアによって、ファームウェアによって、あるいは任意の組合せによって実行されることが可能である。例示の目的で、プロセス１１００の以下の説明は、図１〜図８に関連して前述した要素を参照する場合がある。実施形態において、プロセス１１００の諸部分は、説明されるシステムの様々な要素、例えば、ローカルデバイス、注入ポンプ、ネットワークデバイス、あるいはどんな機能要素または動作コンポーネントによって実行されてもよい。プロセス１１００は、任意の数のさらなるタスク、または代替のタスクを含むことが可能であり、図１１に示されるタスクは、例示される順序で実行されなくてもよく、プロセス１１００は、本明細書で詳細に説明されないさらなる機能を有する、より包括的な手続きまたはプロセスに組み込まれてもよいことを理解されたい。
注入ポンプ監視／制御プロセス１１００は、注入ポンプの通常のローカル動作に関連して実行される（タスク１１０２）。プロセス１１００は、好ましくは、前段で詳細に説明されるとおり、ローカル注入システム内でポンプデータの通信をサポートする（タスク１１０４）。特に、タスク１１０４は、例えば、ローカル注入システム内の注入ポンプからモニタデバイスへのポンプデータの伝送、注入ポンプ以外のローカルデバイス間のポンプデータの伝送などに相当する。この実施例では、ローカルモニタデバイスが、ポンプデータを伝えるローカル通信を受信する（タスク１１０６）。ローカルモニタデバイスは、前述したとおり、臨床モニタ、病院モニタ、ハンドヘルドモニタ／コントローラ、または任意の適切に構成されたローカルデバイスであってもよい。必要な場合、ローカルモニタデバイスは、受信されたポンプデータを処理して（タスク１１０８）、どのように応答するのが最善であるかを決定する。
この実施例では、ローカルモニタデバイスは、受信されたポンプデータに応答して、ネットワーク通信を生成し、送信する（タスク１１１０）。ネットワーク通信は、ローカル注入システムの外部にある任意の適合するネットワークデバイスを宛先とすることが可能である。前述したとおり、ネットワーク通信は、好ましくは、宛先ネットワークデバイスによってもサポートされる選択されたネットワークデータ通信プロトコルに従って生成される。注入ポンプ監視／制御プロセス１１００は、外部ネットワークデバイスが、適切な仕方でネットワーク通信を受信して、処理する（タスク１１１２）ものと想定する。例えば、ネットワークデバイスは、注入ポンプを発信元とする警告または警報を生成することができる。
ネットワーク通信（例えば、この実施例では、警報）に応答して、ネットワークデバイスは、リモートユーザ入力を獲得することができる（タスク１１１４）。これに関して、リモートユーザ入力は、例えば、ネットワークデバイスに配置されたユーザインターフェース機能の操作に相当する。例えば、ネットワークデバイスのユーザは、ネットワークデバイス上の「ＤＩＳＡＢＬＥ」ボタンを入れることによって、警報をディセーブルにすることを選択することができる。別の例として、ネットワークデバイスのユーザは、ネットワークデバイス上の「ＡＣＴＩＶＡＴＥ」ボタンを入れることによって、ボーラスを遠隔で投与することを選択することができる。リモートユーザ入力に応答して、ネットワークデバイスは、ローカル注入システム内のターゲットデバイスを宛先とする適切に構成されたネットワーク制御通信を生成して、送信することができる（タスク１１１６）。この制御通信は、ターゲットデバイスによってもサポートされるある特定のデータ通信プロトコルに準拠するようにフォーマットされる。ターゲットデバイスは、タスク１１０６中の間に受信されるローカル通信を送信した（またはそのような通信の発信元であった）のと同一のローカルデバイスであってよいが、そうである必要は必ずしもない。
注入ポンプ監視／制御プロセス１１００は、宛先のターゲットデバイスが、適切な仕方でネットワーク制御通信を受信して、処理する（タスク１１１８）ものと想定する。一般に、ターゲットデバイスは、受信された制御通信を処理して、どのように応答するのが最善であるかを決定する。ターゲットデバイスが、注入ポンプである場合、プロセス１１００は、タスク１１２４に進むことが可能である。そうではない場合、プロセス１１００は、タスク１１２２に進むことが可能である。タスク１１２２中、ターゲットデバイスは、注入ポンプを宛先とするローカル制御通信を生成して、送信することができる。ターゲットデバイスは、ローカル注入システム内でサポートされるデータ通信プロトコルに従ってローカル制御通信を生成して、送信する。例として、タスク１１２２は、ターゲットデバイスが、注入デバイスとローカルで通信するローカルモニタデバイスである場合、実行されることが可能である。最終的に、注入ポンプは、適切な仕方でネットワーク制御通信またはローカル制御通信を受信して、処理する（タスク１１２４）。これに関して、タスク１１２４は、タスク１１１４中にネットワークデバイスにおいて獲得されたリモートユーザ入力に応答して実行される。実施形態において、ローカル注入ポンプは、適切な仕方で、この制御通信に応答する（タスク１１２６）。例えば、注入ポンプは、例えば、以下の仕方で反応することが可能である。すなわち、警報または警告をディセーブルにする、注入ポンプのソフトウェアまたはファームウェアを更新する、注入ポンプの基礎レートを変更する、ポンプを作動させて、ボーラスを投与する、ローカル警告／警報を生成する、較正ルーチンを実行するなどである。
この例示的な実施形態では、注入ポンプ監視／制御プロセス１１００は、注入ポンプの継続的な、または定期的な監視および制御を可能にする。したがって、図１１は、プロセス１１００をループとして表し、ここで、タスク１１２６は、注入ポンプの継続したローカル動作の目的で、タスク１１０２に戻る。
図１２〜図１７は、本発明の例示的な実施形態に従って構成されたモニタデバイス、コントローラデバイス、ネットワークデバイス、ディスプレイデバイス、および／またはその他の注入システムデバイスによって生成されることが可能なスクリーンショットである。例えば、これらのスクリーンショットのコンテンツは、臨床モニタ２００（図２参照）によって、病院モニタ３００（図３参照）によって、ハンドヘルドモニタ／コントローラ４００および４１０（図４参照）によって、ローカル注入システム１０２内のローカルデバイスのいずれか（図１参照）によって、さらに／またはネットワークベースの注入システム１００によって利用されるネットワークデバイス１０４のいずれか（図１参照）によって表示されることが可能である。
図１２は、ハンドヘルドモニタ、パーソナルデジタルアシスタント、無線電話機、キーホルダリモートコントロールなどの、比較的小さいデバイスで使用するのに適したスクリーンショットである。このスクリーンショットは、クロック表示、ＲＦ品質インジケータ１２０２、バッテリインジケータ１２０４、注入ポンプの中に残っている液体の量を表す液体レベルインジケータ１２０６、および推奨されるボーラス（この例では、４．３ユニット）を含む。また、このスクリーンショットは、「続けるには「ＯＫ」を押してください」というプロンプトも含む。ユーザは、「ＯＫ」を押して、推奨されるボーラスを投与するように注入ポンプを制御する作動要求などの、他のオプションを表示することができる。
図１３は、比較的小さいデバイスで使用するのに適した別のスクリーンショットである。このスクリーンショットは、適切に生成された警告または警報が付随することが可能な注意表示を含む。この場合、注意は、バッテリ電力低下状態、およびバッテリを交換するようにというリマインダを示すテキストを含む。本発明の例示的な実施形態では、そのような注意は、この注意を実際に表示するデバイス内のバッテリに関連するものであってもよいし、あるいはこの注意を実際に表示するデバイスによって監視されるリモートデバイス内のバッテリに関連するものであってもよい。これに関して、このスクリーンショットは、ネットワークモニタデバイスにおいて表示されることが可能であり、ここで、バッテリ電力低下注意は、ローカル注入ポンプデバイス内のバッテリ電力が低いことを示す。
図１４は、リモートコントロール、腕時計サイズのモニタ、ポータブル表示専用デバイスなどの小さいフォームファクタのデバイスで使用するのに適したスクリーンショットである。このスクリーンショットは、読み易さのためにそれ相応な大きさであるクロック表示を含む。また、このスクリーンショットは、適切に生成された警告または警報が付随することが可能である注意表示も含む。この場合、注意は、監視される注入ポンプに関するインスリン貯蔵量低下条件を示すテキストを含む。例示的な実施形態では、このスクリーンショットは、注入ポンプ自体の上で、ローカル注入システム内のリモートデバイス上で、さらに／またはネットワークベースの監視デバイス上で表示されることが可能である。
図１５〜図１７は、パーソナルデジタルアシスタント、無線電話機、またはポケットベルデバイスなどの、比較的小さいデバイスで使用するのに適した様々なスクリーンショットである。図１５の例示的なスクリーンショットは、グラフフォーマットでレンダリングされた、患者に関する履歴ＢＧデータ、およびクロック表示を含む。図１６のスクリーンショットは、インスリンポンプのインスリン貯蔵量の低レベルと関係する注意、ならびにクロック表示を含む。図１７のスクリーンショットは、デバイスに関する「メインメニュー」表示を表し、ここで、このメニューは、ユーザのためのいくつかのオプションを含む。例えば、デバイスは、例えば、「ボーラス設定」アイコン、「ボーラスウィザード」アイコン、「手動ボーラス」アイコン、および「ボーラス履歴」アイコンを含む、選択可能なメニューアイコンを表示してもよい。所与のアイコンの選択により、デバイスが、選択された特徴または機能と関係するさらなる情報またはオプションを提供する新たな表示スクリーンを生成させられるようにしてもよい。例えば、「ボーラス設定」アイコンは、ユーザが、使用中に作動させられることが可能なデバイスをある特定のボーラス値または複数のボーラス値に関してプログラミングすることを可能にし、デフォルトの値は、ユーザによって通常、消費される様々な食事炭水化物値に対応するように割り当てられることが可能であり、「ボーラスウィザード」アイコンは、ユーザが、その患者の現在の状態に適切であるインスリンのボーラスを計算することを可能にする機能を起動し、「手動ボーラス」アイコンは、ユーザが、デフォルトのボーラス値を逸脱することができるようにし、「ボーラス履歴」アイコンは、注入ポンプによる過去のボーラス供給の表示（グラフ、チャート、またはレポートなどの）を起動する。
この場合、特定の表示フォーマット、スクリーンショット内容、表示メニューツリー、およびその他の表示特性および表示機能は、特定のデバイス構成（コンフィギュレーション）、デバイスが、ネットワークデバイスであるか、または注入システム内のローカルデバイスであるか、および／またはデバイスが、無線デバイスであるかどうかに応じて異なっていてもよい。様々な図に示される例示的なスクリーンショットは、本発明の任意の実施形態の範囲または応用を限定する、または制限することを意図するものではない。
ネットワークベースの注入システム１００（図１参照）に関連して前述したとおり、データ通信変換（中継）デバイス１１３は、無線ローカルデバイスと、パーソナルコンピュータ、ネットワーク化された病院コンピュータ、介護者オフィスコンピュータなどのネットワークデバイス１０４との間の通信を円滑にするように利用されることが可能である。図１８は、本発明の１つの可能な実施形態に従って構成されたデータ通信変換デバイス１３００の斜視図である。この実施形態では、変換デバイス１３００は、無線ブリッジ機能およびメモリ記憶機能を提供する比較的小さいポータブルのデバイスである。変換デバイス１３００は、患者または介護者によって容易に携帯されることが可能であるように、便利なサイズであることが可能である。いくつかの実施形態では、変換デバイス１３００は、ポケットの中で携帯されるほど十分に小さい。
変換デバイス１３００は、以下により詳細に説明されるいくつかの機能構成要素を密閉する筐体１３０２を含む。この例示的な実施形態は、変換デバイス１３００のためのネットワークインターフェースポートの役割をする「ＵＳＢ」（ユニバーサルシリアルバス）コネクタ１３０４を含む。ネットワークインターフェースポートは、代替として、ＩＥＥＥ１３９４ポート、シリアルポート、パラレルポートなどであってもよい。ＵＳＢコネクタ１３０４は、知られているＵＳＢ規格に物理的および電気的に準拠するように構成され、そのような規格を本明細書で詳細に説明することはしない。代替の実施形態は、様々なネットワークインターフェース構成を利用することが可能であり、したがって、様々なネットワークインターフェースコネクタ、ネットワークインターフェースポート、ネットワークインターフェースカプラなどを利用することが可能である。ＵＳＢコネクタ１３０４は、そのようなネットワークインターフェースの１つの適切な実施形態に過ぎず、本発明の実施形態は、ＵＳＢ利用に限定されない。
また、変換デバイス１３００は、変換デバイス１３００が、ネットワークデバイスに接続されていない場合に、ＵＳＢコネクタ１３０４を保護する着脱可能なカバー１３０６を含んでいてもよい。カバー１３０６は、ユーザが、手でカバー１３０６を取り外すこと、および元に戻すことができるような仕方で、ＵＳＢコネクタ１３０４上および／または筐体１３０２上にはまるように設計されていてもよい。
図１９は、変換（中継）デバイス１３００の１つの例示的な実施形態の概略図である。この実施例では、変換デバイス１３００は、一般に、筐体１３０２、ネットワークインターフェースポート（例えば、ＵＳＢコネクタ１３０４）、無線通信モジュール１３０８、メモリ要素１３１０、処理アーキテクチャ１３１２、データフォーマットトランスレータ１３１４、およびネットワークインターフェース１３１６（例えば、ＵＳＢインターフェース）を含む。変換デバイス１３００の要素は、バス１３１８、または任意の適切な相互接続アーキテクチャを介して、互いに結合されることが可能である。例示的な実施形態では、筐体１３０２は、無線通信モジュール１３０８、メモリ要素１３１０、処理アーキテクチャ１３１２、およびデータフォーマットトランスレータ１３１４を密閉する。特定の実施形態であ、筐体１３０２は、ネットワークインターフェース１３１６の少なくとも一部分を密閉することも可能である。
処理アーキテクチャ１３１２は、汎用プロセッサ、コンテンツアドレス可能なメモリ、デジタルシグナルプロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、任意の適切なプログラマブルロジックデバイス、ディスクリートのゲートロジックまたはトランジスタロジック、ディスクリートのハードウェア構成要素、または本明細書で説明される機能を実行するように設計された任意の組合せを使用して実施される、または実行されることが可能である。プロセッサは、マイクロプロセッサ、コントローラ、マイクロコントローラ、または状態マシンとして実現されることが可能である。さらに、プロセッサは、コンピューティングデバイスの組合せ、例えば、デジタルシグナルプロセッサとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、デジタルシグナルプロセッサコアと連携した１つ以上のマイクロプロセッサ、または他の任意のそのような構成として実施されてもよい。変換デバイス１３００の例示的な実施形態では、データフォーマットトランスレータ１３１４は、処理アーキテクチャ１３１２内で実施されてもよい（ただし図１９は、これら２つを別々の論理要素として表す）。
実際には、処理アーキテクチャ１３１２は、変換デバイス１３００の様々なタスク、機能、および動作をサポートするように構成される。例えば、処理アーキテクチャ１３１２は、ローカル注入システム内の送信デバイスから受信されるローカル通信の中で伝送される着信する情報、データ、およびコンテンツを解釈し、処理するように適切に構成されることが可能である。同様に、処理アーキテクチャ１３１２は、ローカル注入システムの外部のネットワークデバイスから受信されるネットワーク通信の中で伝送される着信情報、着信データ、および着信コンテンツを解釈し、処理するように適切に構成されることが可能である。また、処理アーキテクチャ１３１２は、メモリ要素１３１０の中のデータの格納および取り出しを管理するように構成されることも可能である。さらに、処理アーキテクチャ１３１２は、ネットワークインターフェース１３１６を介してネットワークデバイスから受信される命令に応答して、さらに／または無線通信モジュール１３０８を介してローカルデバイスから受信される命令に応答して、データを処理するように構成されることが可能である。
１つの実施形態では、メモリ要素１３１０は、記憶能力を維持するのにバックアップバッテリを利用する電源付きメモリ構成であることが可能である。例示的な実施形態では、メモリ要素１３１０は、適切な量の記憶容量を有する不揮発性フラッシュメモリとして実現される。フラッシュメモリ、フラッシュメモリの選択回路、およびフラッシュメモリのプログラム／消去制御回路の設計および構成は、一般に知られており、メモリ要素１３１０のそのような従来の態様を本明細書で詳細に説明することはしない。代替の実施形態では、メモリ要素１３１０は、ＥＥＰＲＯＭメモリ、ランダムアクセスメモリ、レジスタ、小規模ハードディスク、着脱可能な媒体などを利用することができる。これに関して、メモリ要素１３１０は、処理アーキテクチャ１３１２が、メモリ要素１３１０から情報を読み取り、メモリ要素１３１０に情報を書き込むことができるように、処理アーキテクチャ１３１２に結合されることが可能である。代替として、メモリ要素１３１０および処理アーキテクチャ１３１２は、統合されたユニットとして実現されることも可能である。例として、処理アーキテクチャ１３１２およびメモリ要素１３１０は、ＡＳＩＣ内に存在することが可能である。後段でより詳細に説明されるとおり、メモリ要素１３１０は、注入システム内のローカルデバイスから受信される無線信号の中で伝送されるデータを格納するのに利用されることが可能である。さらに、メモリ要素１３１０は、注入システムの外部のネットワークデバイスから受信されるネットワーク通信信号の中で伝送されるデータを格納するのに利用されることが可能である。そのようなデータには、ローカルデバイスステータスデータ、ユーザの生理学的データ、センサデータ、警告／警報、ネットワークデバイスからの制御データ、変換デバイス１３００に関する動作命令、本明細書で説明されるローカルデータタイプまたはローカルデータコンテンツのいずれか、および／または本明細書で説明されるネットワークデータタイプまたはネットワークデータコンテンツのいずれかが含まれることが可能である。
無線通信モジュール１３０８は、注入システム内のデバイス、例えば、注入システム１００の前段の説明で述べられるローカルデバイスのいずれか（図１参照）との無線データ通信をサポートするように適切に構成される。例えば、ローカルデバイスは、注入ポンプ、または注入ポンプに関するモニタデバイスであることが可能である。特定の実施態様に依存して、無線通信モジュール１３０８は、ローカルデバイスからの単方向通信、または変換デバイス１３００とローカルデバイスとの間の双方向通信をサポートするように構成されることが可能である。このため、無線通信モジュール１３０８は、ローカル注入システム内の送信デバイスからローカル通信信号を受信し、さらに／またはローカル注入システム内の受信デバイスにローカル通信信号を送信するように構成されることが可能である。
無線通信モジュール１３０８は、１つ以上の無線データ通信プロトコル、および１つ以上の無線データ伝送スキームをサポートする無線モジュールを含むこと、またはそのような無線モジュールとして実現されることが可能である。ある実施形態では、無線通信モジュール１３０８は、ＲＦフロントエンド、適切に構成された無線モジュール（スタンドアロンモジュールであることも、変換デバイス１３００の他の機能、またはすべての機能と一体化されることも可能である）、無線送信機、無線受信機、無線トランシーバ、赤外線センサ、電磁トランスデューサなどの、ハードウェア、ソフトウェア、および／またはファームウェアを含むこと、またはそのようなハードウェア、ソフトウェア、および／またはファームウェアとして実現されることが可能である。この実施例では、変換デバイス１３００は、無線通信モジュール１３０８に結合されたアンテナ１３１８を含む。筐体１３０２の内部または外部に（あるいは一部は、筐体１３０２の内部に、また一部は、筐体１３０２の外部に）配置されることが可能なアンテナ１３１８は、無線通信モジュール１３０８の特定の設計に従って適切に構成される。
ローカル通信の無線伝送のために、無線通信モジュール１３０８は、変換デバイス１３００と通信するローカルデバイスによってもサポートされる１つ以上の無線データ通信プロトコルをサポートする。例えば、ＲＦ、ＩｒＤＡ（赤外線）、Ｂｌｕｅｔｏｏｔｈ、ＺｉｇＢｅｅ（およびＩＥＥＥ８０２．１５プロトコルのその他の変種）、ＩＥＥＥ８０２．１１（任意の変種）、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ、または他の任意の変種）、直接シーケンス拡散スペクトル、周波数ホッピング拡散スペクトル、セルラー／無線／コードレス遠隔通信プロトコル、無線ホームネットワーク通信プロトコル、ページングネットワークプロトコル、磁気誘導、衛星データ通信プロトコル、無線病院ネットワークプロトコル（ＷＭＴＳ帯域において動作するものなど）もしくは医療施設ネットワークプロトコル、ＧＰＲＳ、および無線ＵＳＢの変種などの独自の無線データ通信プロトコルを含む、任意の数の適切な無線データ通信プロトコル、無線データ通信技術、または無線データ通信方法が、通信モジュール１３０８および変換デバイス１３００によってサポートされることが可能である。
ネットワークインターフェース１３１６は、一般に、変換デバイス１３００と、１つ以上のネットワークデバイスとの間のネットワーク通信の伝送をサポートするように構成される。ネットワークインターフェース１３１６は、インターフェースロジック１３２０およびネットワークインターフェースポート１３０４を含むことが可能である。インターフェースロジック１３２０は、処理アーキテクチャ１３１２内で実施されてもよい（ただし図１９は、これら２つを別々の論理要素として表す）。この例示的な実施形態では、ネットワークインターフェース１３１６は、ＵＳＢインターフェースであり、インターフェースロジック１３２０は、ＵＳＢ規格およびＵＳＢ要件に準拠し、ネットワークインターフェースポート１３０４は、ＵＳＢポートまたはＵＳＢコネクタである。しかし、前述したとおり、代替の実施形態は、様々なネットワークインターフェース構成（例えば、ＩＥＥＥ１３９４）を利用することができ、したがって、様々なネットワークインターフェースコネクタ、ネットワークインターフェースポート、ネットワークインターフェースカプラなどを利用することができる。
ネットワークインターフェース１３１６は、注入システムの外部のデバイス、例えば、注入システム１００の前段の説明で述べられるローカルデバイスのいずれか（図１参照）とのデータ通信をサポートするように適切に構成される。例えば、ネットワークデバイスは、変換デバイス１３００との通信を管理するように操作されることが可能である、適切なホストアプリケーションを有するパーソナルコンピュータであることが可能である。パーソナルコンピュータは、患者によって所有される、介護者施設内に配置される、病院内に配置される、デバイス製造業者施設内に配置される、または別の場所に配置されることが可能である。例示的な実施形態では、ホストアプリケーションは、監視、診断サービス、患者データ分析、医療デバイスプログラミング、および／またはローカル注入システム内の１つ以上のデバイスに関連する他の機能を提供するように設計されたソフトウェアとして実現されることが可能である。特定の実施形態に依存して、ネットワークインターフェース１３１６は、変換デバイス１３００からの単方向通信、または変換デバイス１３００とネットワークデバイスとの間の双方向通信をサポートするように構成されることが可能である。このため、ネットワークインターフェース１３１６は、送信するネットワークデバイスからネットワーク通信信号を受信し、さらに／または受信するネットワークデバイスにネットワーク通信信号を送信するように構成されることが可能である。
ケーブル、有線接続、直接接続、またはその他の物理リンクを介するネットワーク通信信号の伝送のために、ネットワークインターフェース１３１６は、変換デバイス１３００と通信するネットワークデバイスによってもサポートされる１つ以上の有線／ケーブル配線データ通信プロトコルをサポートする。例えば、イーサネット、ホームネットワーク通信プロトコル、ＵＳＢ、ＩＥＥＥ１３９４（Ｆｉｒｅｗｉｒｅ）、病院ネットワーク通信プロトコル、および独自のデータ通信プロトコルを含む、任意の数の適切なデータ通信プロトコル、データ通信技術、またはデータ通信方法が、ネットワークインターフェース１３１６および変換デバイス１３００によってサポートされることが可能である。
ネットワーク通信信号の無線伝送のために、ネットワークインターフェース１３１６は、変換デバイス１３００と通信するネットワークデバイスによってもサポートされる１つ以上の無線データ通信プロトコルをサポートする。例えば、ＲＦ、ＩｒＤＡ（赤外線）、Ｂｌｕｅｔｏｏｔｈ、ＺｉｇＢｅｅ（およびＩＥＥＥ８０２．１５プロトコルのその他の変種）、ＩＥＥＥ８０２．１１（任意の変種）、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ、または他の任意の変種）、直接シーケンス拡散スペクトル、周波数ホッピング拡散スペクトル、セルラー／無線／コードレス遠隔通信プロトコル、無線ホームネットワーク通信プロトコル、ページングネットワークプロトコル、磁気誘導、衛星データ通信プロトコル、ＷＭＴＳ帯域において動作するものなどの無線病院ネットワークプロトコルもしくは医療施設ネットワークプロトコル、ＧＰＲＳ、および無線ＵＳＢの変種などの独自の無線データ通信プロトコルを含む（ただしこれらに限定されるものではない）、任意の数の適切な無線データ通信プロトコル、無線データ通信技術、または無線データ通信方法が、ネットワークインターフェース３１６および変換デバイス１３００によってサポートされることが可能である。
無線データ伝送に関連して、変換デバイス１３００は、動的周波数ホッピングを実行して、デバイス１３００の動作を最適化し、バッテリ電源の無線デバイスに関するバッテリ寿命を保存し、さらに／またはデバイス１３００が通信する相手のデバイスの複雑さに柔軟性をもたらすように構成されることが可能である。例えば、無線通信モジュール１３０８は、５チャネル（低出力）デバイスおよび５０チャネル（高出力）デバイスに動的に対応するように設計されることが可能である。このような状況において、変換デバイス１３００は、高品質の無線リンクが確立された場合に、低電力モードを利用して、バッテリ電力を節約することができる。他方、変換デバイス１３００は、パケット損失の増加、衝突の増加、または全体的に劣悪なサービス品質（ＱｏＳ）に応じて、高電力モードに切り替わることが可能である。
無線データ伝送に関連して、変換デバイス１３００は、指定された伝送周期性を有する同期リンクに関する再試行周期性をサポートするように構成されることも可能である。例えば、通常の動作中、同期無線リンクは、１分当たり１つのパケットを通信することができる。変換デバイス１３００は、逸せられたパケットに応じて、再試行手続きを開始するように構成されることが可能である。これに関して、変換デバイス１３００は、通常の動作モードと比べて、より高いレートで行われる再試行伝送（すなわち、逸せられたパケットの再送）をサポートすることができる。例えば、再試行パケット伝送は、１分に１回ではなく、２０秒毎に行われることが可能である。実際には、変換デバイス１３００および無線デバイスは、再試行パケットに対処するように周波数ホッピングスキームを適合させ、その後、通常の周波数ホッピングスキームを再開することができる。
ソフトウェアによって、ハードウェアによって、ファームウェアによって、あるいはソフトウェアとハードウェアとファームウェアの任意の組合せによって実現されることが可能なデータフォーマットトランスレータ１３１４は、無線通信モジュール１３０８とネットワークインターフェース１３１６との間でデータを再フォーマットするように適切に構成される。特定の実施形態に依存して、そのような再フォーマットは、無線通信モジュール１３０８を介して受信されるデータに関して、ネットワークインターフェース１３１６を介して受信されるデータに関して、あるいはその両方に関して行われることが可能である。例えば、変換デバイス１３００が、無線通信モジュール１３０８において無線通信信号を受信し、この無線通信信号からデータを抽出し、この抽出されたデータを適切な仕方で処理して、この抽出されたデータが、ネットワークインターフェース１３１６によって供給されるべきネットワーク通信信号の中で伝送されることが可能であるようにすることが望ましい場合がある。同様に、変換デバイス１３００が、ネットワークインターフェース１３１６においてネットワーク通信信号を受信し、このネットワーク通信信号からデータを抽出し、この抽出されたデータを適切な仕方で処理して、この抽出されたデータが、無線通信モジュール１３０８によって供給されるべき無線通信信号の中で伝送されることが可能であるようにすることが望ましい場合がある。
変換デバイス１３００は、無線通信モジュール１３０８と、ネットワークインターフェース１３１６との間でデータを暗号化するように構成されてもよい。データを暗号化することは、例えば、機密の情報、または取扱に慎重を要す売る情報が保護されたままであることを確実にするために望ましい可能性がある。この実施例では、データフォーマットトランスレータ１３１４が、１つ以上の知られている暗号化スキームまたは独自の暗号化スキームを使用して、データ暗号化を実行するように構成されることが可能である。代替として、変換デバイス１３００が、データ暗号化を実行する別個の暗号化エンジンまたは暗号化モジュールを含んでもよい。特定の実施形態では、データ暗号化は、抽出されたデータ（または抽出されたデータの任意の部分）に、取扱に慎重を要する／機密のデータ（またはそのようなデータの任意の部分）に、さらに／または通信信号全体（または通信信号の任意の部分）に適用されることが可能である。
変換デバイス１３００は、ローカルデバイスとネットワークデバイスとの間で無線ブリッジを提供し、変換デバイス１３００は、ある範囲のデータ伝送機能およびデータ格納機能をサポートすることができる。これに関して、図２０は、変換デバイス１３００によってサポートされることが可能である、例示的なデータ格納および変換プロセス１４００を表す流れ図である。プロセス１４００に関連して実行される様々なタスクは、ソフトウェアによって、ハードウェアによって、ファームウェアによって、あるいは任意の組合せによって実行されることが可能である。例示の目的で、プロセス１４００の以下の説明は、図１８および図１９に関連して前述した要素を参照する場合がある。実際には、プロセス１４００の諸部分が、説明されるシステムの様々な要素、例えば、無線通信モジュール１３０８、メモリ要素１３１０、処理アーキテクチャ１３１２、またはネットワークインターフェース１３１６によって実行されることが可能である。プロセス１４００は、任意の数のさらなるタスク、または代替のタスクを含むことが可能であり、図２０に示されるタスクは、例示される順序で実行されなくてもよく、プロセス１４００は、本明細書で詳細に説明されないさらなる機能を有する、より包括的な手続きまたはプロセスに組み込まれてもよいことを理解されたい。
データ格納および変換プロセス１４００は、例えば、変換デバイスのネットワークインターフェースを介して変換デバイスがネットワークデバイスに接続されると開始される（タスク１４０２）。この実施例では、タスク１４０２は、ＵＳＢ対応の変換デバイスを、変換デバイスのＵＳＢインターフェースを介してパーソナルコンピュータに結合することに関連する。この接続に応じ、プロセス１４００は、変換デバイスに電力を供給し、無線通信モジュールを初期化する（タスク１４０４）。従来の方法によれば、ＵＳＢインターフェースは、コンピュータから変換デバイスに動作電力を供給し、そのような動作電力は、無線通信モジュール、または変換デバイスの他の機能要素に通電するのに利用されることが可能である。この実施例では、コンピュータは、変換デバイスのマウント（装着）を検出し、コンピュータのホストアプリケーションを自動的に起動することによって応答する（タスク１４０６）。代替として、コンピュータは、ホストアプリケーションを手動で起動するようにユーザを促してもよい。
変換デバイスは、自動検出モードまたはスタンバイモードをサポートするように構成されることが可能であり、これらのモード中、変換デバイスは、無線伝送範囲内に入る適合するローカルデバイスを「リッスン」する。そのような自動デバイス検出モードは、十分な強度のリンクが確立されるまで、データの無線伝送を遅延させることによって、システムが、断続的なリンク、または信頼できないリンクに対処することを可能にするのに望ましい場合がある。また、そのような自動デバイス検出モードは、介護者オフィス環境において、患者が待合室に入るといつでも、システムがデータをダウンロードする（自動的に、または患者の承認後に）ことを可能にするのに望ましい場合もある。代替として、自動デバイス検出モードは、ユーザの自宅において、または他のそのような環境において、システムが、データを中央保管場所に直接にダウンロードし、またはＰＣなどの一時的な保持領域にダウンロードして、その後、このデータを、ウェブサーバなどの中央保管場所、または病院データベースに転送することが、自動的に、または患者の承認後に、できるようにするのに望ましい可能性もある。自動デバイス検出モードが、アクティブ状態である場合（クエリタスク１４０８）、変換デバイスは、ローカルデバイスが検出されているかどうかを判定する検査を行うことができる（クエリ・タスク１４１０）。変換デバイスが、範囲内のローカルデバイスを検出した場合、データ格納および変換プロセス１４００は、後段で説明される処理に進むことができる。検出しなかった場合、変換デバイスは、範囲内のローカルデバイスを検出するまで、アイドル状態であってもよく、あるいはプロセス１４００は、クエリタスク１４０８に戻ってもよい。自動デバイス検出モードが、アクティブ状態でない場合、または変換デバイスが、自己デバイス検出モードをサポートしない場合、クエリタスク１４０８の後にクエリタスク１４１２に進んでもよい。
データ格納および変換プロセス１４００は、クエリタスク１４１２を実行して、ホストアプリケーションのユーザが変換デバイスを制御下においたかどうかを判定することができる。ホスト制御が開始されていない場合、プロセス１４００は、クエリタスク１４０８に戻ってもよい。代替として、ホスト制御が開始されていない場合、プロセス１４００は、ホスト制御が生じるまで、アイドル状態であってもよい。しかし、ホスト制御が開始された場合、プロセス１４００は、後段で説明される処理に進むことが可能である。
実施態様および応用先に依存して、変換デバイスは、無線ローカルデバイスからデータを受信して、処理することができ、さらに／またはネットワークデバイスからデータを受信して、処理することができる。説明を容易にするため、データ格納および変換プロセス１４００は、（着信する無線通信信号を扱うことと関係する）サブプロセスＡと（着信するネットワーク通信信号を扱うことと関係する）サブプロセスＢとに恣意的に、わざと分けられる。変換デバイスのある実施形態は、両方のサブプロセスを同時に、または送信／受信衝突を回避する同期の仕方で実行するように適切に構成されることが可能である。これらのサブプロセスのいずれか、または両方が、図２０Ａに示されるとおり、クエリタスク１４１０またはクエリタスク１４１２の後に続くことが可能である。
サブプロセスＡ（図２０Ｂ参照）を参照すると、変換デバイスは、注入システム内のローカルデバイスから無線ローカルデータ通信信号を受信することができる（タスク１４１４）。１つの例示的な実施形態では、初期ハンドシェークルーチン中、またはパケット交換ルーチン中、接触を開始するデバイスは、伝送が、１回限り（ワンタイム）のパケット（要求されるだけの頻度で送信されることが可能である）であるか、この２つの通信するデバイス間で送受信されるパケットの時間同期を要求する同期リンクパケットであるかを示す。受信された無線ローカルデータ通信信号の中で伝送されたデータが、保存されるべき場合（クエリタスク１４１６）、変換デバイスは、そのデータを抽出して、デバイスの常駐メモリ要素の中に格納することができる（タスク１４１８）。タスク１４１８のデータ格納の後に、データ格納および変換プロセス１４００は、クエリタスク１４２０に進むことができる。無線ローカルデータ通信信号の中で伝送されるデータが、保存されるべきでない場合、プロセス１４００は、タスク１４１８を飛び越して、クエリタスク１４２０に進むことができる。
クエリタスク１４２０は、変換デバイスがデータのネットワーク伝送を実行すべきかどうかを判定することができる。変換デバイスは、メモリ要素の中に格納されたデータのネットワーク伝送、および／またはメモリ要素の中に格納される必要のないデータのネットワーク伝送をサポートするように適切に構成されることが可能である。例えば、変換デバイスは、注入システムの外部のネットワークデバイスに伝送するために、メモリ要素の中に格納されたデータを処理するように構成されることが可能である。この実施例では、そのようなネットワーク伝送は、ＵＳＢインターフェースを介する、変換デバイスからホストコンピュータへのデータの伝送に相当する。ネットワーク伝送が、開始されていない場合、データ格納および変換プロセス１４００は、タスク１４１４に戻り、変換デバイスが、無線通信信号を受信することを続けることができるようにしてもよい。しかし、ネットワーク伝送が開始されている場合、プロセス１４００は、クエリタスク１４２２に進むことが可能である。
クエリタスク１４２２は、変換デバイスが、データ暗号化を実行すべきかどうかを判定する。変換デバイスは、無線ローカルデータ通信信号の中で伝送されるデータを暗号化する、ネットワーク通信信号の中で伝送されるデータを暗号化する、さらに／またはメモリ要素の中に格納されたデータを暗号化するように適切に構成されることが可能である。例えば、変換デバイスは、ネットワークデバイスへの暗号化された伝送のために、メモリ要素の中に格納されたデータを暗号化することができ、ネットワークデバイスは、このデータを解読するのに適合した仕方で構成される。暗号化が実行されるべき場合、データ格納および変換プロセス１４００は、任意の適切なデータ暗号化技術を使用して、データ暗号化を実行する（タスク１４２４）。プロセス１４００は、暗号化を実行した後、クエリタスク１４２６に進んでもよい。データが暗号化されない場合、プロセス１４００は、タスク１４２４を飛び越して、クエリタスク１４２６に進むことができる。
クエリタスク１４２６は、変換デバイスが、ネットワークデバイスへの伝送のためにデータを再フォーマットすべきかどうかを判定する。例えば、データ格納および変換プロセス１４００は、ネットワークインターフェースに適合するように、無線ローカルデータ通信信号の中で伝送されるデータを再フォーマットすることができる（タスク１４２８）。プロセス１４００は、さらに（または代替として）、メモリ要素の中に格納されているデータを再フォーマットすることができる。そのような再フォーマットは、ネットワークインターフェースがネットワークデバイスにネットワーク通信を提供することができるようにするたねに望ましい場合があり、ここで、ネットワーク通信は、再フォーマットされたデータを伝送する。データを、所望される仕方で再フォーマットした後、変換デバイスは、ネットワーク通信信号を生成することができる（タスク１４３０）。タスク１４３０は、再フォーマットが必要ない、または望ましくないとクエリタスク１４２６が判定した場合に、実行されてもよい。この実施例では、ネットワーク通信信号は、無線ローカルデータ通信信号の中で伝送されたデータ、および／またはメモリ要素から取り出されたデータを含む。
最終的に、データ格納および変換プロセス４００は、ネットワークデバイスに伝送するために、ネットワークインターフェースに（タスク１４３０中に生成された）ネットワーク通信信号を提供する（タスク１４３２）。例示的な実施形態では、タスク１４３２は、ＵＳＢインターフェースを介するホストコンピュータへのデータの伝送をもたらす。タスク１４３２の後に、プロセス１４００は、終了してもよいし、またはクエリタスク１４０８などの、指定されたポイントに戻ってもよい。
サブプロセスＢ（図２０Ｃ参照）に戻ると、変換デバイスは、注入システムの外部のネットワークデバイスからネットワークデータ通信信号を受信することができる（タスク１４３４）。１つの例示的な実施形態では、初期ハンドシェーク中、またはパケット交換ルーチン中、接触を開始するデバイスは、伝送が１回限りのパケット（要求されるだけの頻度で送信されることが可能である）であるか、この２つの通信するデバイス間で送受信されるパケットの時間同期を要求する同期リンクパケットであるかを指示する。ネットワークデータ通信信号の中で伝送されるデータが保存されるべき場合（クエリタスク１４３６）、変換デバイスは、データを抽出して、デバイスの常駐メモリ要素の中に格納することができる（タスク１４３８）。その後、データ格納および変換プロセス１４００は、クエリタスク１４４０に進むことができる。ネットワークデータ通信信号の中で伝送されるデータが、保存されるべきでない場合、プロセス１４００は、タスク１４３８を飛び越して、クエリタスク１４４０に進むことができる。
クエリタスク１４４０は、変換デバイスが、データのローカル伝送を実行すべきかどうかを判定することができる。変換デバイスは、メモリ要素の中に格納されたデータのローカル伝送、および／またはメモリ要素の中に格納される必要のないデータのローカル伝送をサポートするように適切に構成されることが可能である。例えば、変換デバイスは、注入システム内のローカルデバイスに伝送するために、メモリ要素の中に格納されたデータを処理するように構成されることが可能である。この実施例では、そのようなローカル伝送は、無線通信モジュールを介する、変換デバイスからローカルデバイスへのデータの伝送に相当する。ローカル伝送が、開始されていない場合、データ格納および変換プロセス１４００は、受信されたネットワークデータ通信信号が、ネットワークデバイスからの動作命令または制御命令を伝送したかどうかを検査することができる（クエリタスク１４４２）。伝送した場合、変換デバイスは、そのような命令に応答して、メモリの中に格納されたデータを処理することができる（タスク１４４４）。これらの命令は、変換デバイスにおいて格納されたあるデータを求める要求、ローカルデバイスからデータを獲得するように変換デバイスに求める要求、変換デバイスおよび／またはローカルデバイスのためのプログラミングデータまたは構成データなどを含む、または示すことが可能である。タスク１４４４の後に、プロセス１４００は、終了する、あるいはタスク１４３４またはクエリタスク１４０８などの、指定されたポイントに戻ることが可能である。
ローカル伝送が開始されているとクエリタスク１４４０が判定した場合、データ格納および変換プロセス１４００は、クエリタスク１４４６に進むことができる。クエリタスク１４４６は、変換デバイスが、前述したとおり、データ暗号化を実行すべきかどうかを判定する。例えば、変換デバイスは、無線ローカルデバイスへの暗号化された伝送のために、受信されたネットワークデータ通信信号によって伝送されたデータ、および／またはメモリ要素の中に格納されたデータを暗号化することができ、無線ローカルデバイスは、このデータを解読するのに適合した仕方で構成される。暗号化が実行されるべき場合、プロセス１４００は、任意の適切なデータ暗号化技術を使用して、データ暗号化を実行する（タスク１４４８）。プロセス１４００は、データを暗号化した後、クエリタスク１４５０に進むことができる。データが暗号化されない場合、プロセス１４００は、タスク１４４８を飛び越して、クエリタスク１４５０に進むことができる。
クエリタスク１４５０は、変換デバイスが、無線ローカルデバイスに伝送するためにデータを再フォーマットすべきかどうかを判定する。例えば、データ格納および変換プロセス１４００は、無線データ通信モジュールに適合するように、ネットワークデータ通信信号の中で伝送されるデータを再フォーマットすることができる（タスク１４５２）。プロセス１４００は、さらに（または代替として）、メモリ要素の中に格納されているデータを再フォーマットすることができる。そのような再フォーマットは、無線通信モジュールが、ローカルデバイスにローカル無線通信信号を提供することができるようにするのに望ましい場合があり、ここで、その無線信号は、再フォーマットされたデータを伝送する。データを所望される仕方で再フォーマットした後、変換デバイスは、ローカル通信信号を生成することができる（タスク１４５４）。また、タスク１４５４は、再フォーマットが必要ない、または望ましくないとクエリタスク１４５０が判定した場合に実行されてもよい。この実施例では、ローカル通信信号は、ネットワークデータ通信信号の中で伝送されたデータ、および／またはメモリ要素から取り出されたデータを含む無線信号である。
最終的に、データ格納および変換プロセス１４００は、ローカルデバイスに伝送するために、無線通信モジュールにローカル通信信号（タスク１４５４中に生成された）を提供する（タスク１４５６）。この例示的な実施形態では、タスク１４５６は、無線通信モジュールを介するローカルデバイスへのデータの無線伝送をもたらす。タスク１４５６の後に、プロセス１４００は、終了する、またはクエリタスク１４０８などの、指定されたポイントに戻ることが可能である。
変換デバイス１３００、データ格納および変換プロセス１４００、および変換デバイス１３００によってサポートされる他のプロセスは、注入システムのユーザに、さらなる柔軟性および利便性を提供する。例えば、変換デバイス１３００は、注入ポンプから、または自動的ストレージを有する注入ポンプモニタから、デバイス１３００の内部フラッシュメモリに履歴データをダウンロードすることをサポートすることができる。そのようなダウンロードは、ホストアプリケーションによって駆動されることが可能であり、つまり、ホストコンピュータが、患者の介護者による後日の取り出し、および分析のために、フラッシュメモリにデータをダウンロードするよう変換デバイス１３００に命令することができる。患者履歴データは、許可された介護者コンピュータシステムだけしか、これらの履歴ファイルにアクセスすることができないように、暗号化されることが可能である。代替として、これらの履歴ファイルは、読み取り／書き込みアクセスが、介護者に与えられて、患者による読み取り専用であることが可能である。例示的な実施形態では、ホストアプリケーションは、患者または介護者が、変換デバイス１３００を介してローカルデバイスと通信しているかどうかを検出するように構成されることが可能である。したがって、変換デバイス１３００は、所望される場合、患者特有の機能、および／または介護者特有の機能をサポートするように構成されることが可能である。
注入システムの所与の配備に依存して、複数のローカルデバイスからデータを収集して、収集されたデータが、制御された仕方で格納される、処理される、ルーティングされる、またはそれ以外で管理されるようにすることが望ましい可能性がある。これに関して、図２１は、本発明の例示的な実施形態に従って構成された無線遠隔測定ルータ１５００の例示的なネットワーク展開の概略図である。無線遠隔測定ルータ１５００は、ネットワークベースの注入システム１００（図１参照）などの医療デバイスシステム内に配置されることが可能である。無線遠隔測定ルータ１５００は、ローカル注入システムなどのローカル医療デバイスシステム内の複数の無線デバイスと通信するように適切に構成される。無線遠隔測定ルータ１５００は、ローカル医療デバイスシステムの外部にあってもよい１つ以上のネットワークデバイスと通信するようにも構成される。例えば、無線遠隔測定ルータ１５００は、イーサネット接続を介して、さらに／または無線リンクを介して無線遠隔測定ルータに結合されたネットワークデバイスと通信することができる。
例示的な環境の柔軟性のある性質が、様々なデバイスと通信する無線遠隔測定ルータ１５００を示す図２１に示される。例示的な実施形態において、無線遠隔測定ルータ１５００は、例えば、以下のデバイス（ただしそれらに限定されるわけではない）、すなわち、複数の生理学的特性センサ送信機１５０２、無線パーソナルデジタルアシスタント１５０４、無線ラップトップコンピュータ１５０６、ネットワークモニタ１５０８、ネットワークコンピュータ１５１０、ネットワークパーソナルデジタルアシスタント１５１２、ネットワーク病院管理システム１５１４、およびネットワークプリンタ１５１６と通信するように適切に構成される。また、無線遠隔測定ルータ１５００は、注入システム１００の前段の説明において述べられた様々なローカルデバイスおよびネットワークデバイスとの通信をサポートするようにも構成される。
図２１は、５つの生理学的特性センサ送信機１５０２を示しているが、無線遠隔測定ルータ１５００は、任意の数のセンサ送信機をサポートすることができる（帯域幅、利用可能な電力、伝送範囲などの実際的な動作上の制約だけによってしか制限されない）。各生理学的特性センサ送信機１５０２は、患者の生理学的特性を測定するように適切に構成される。本明細書で説明される例示的な注入システムにおいて、各センサ送信機１５０２は、患者のグルコースレベルをリアルタイムで測定する連続グルコース（例えば、血糖）センサ送信機である。各センサ送信機１５０２は、患者によって着用されること、患者の皮膚に取り付けられること、患者の体内に埋め込まれることなどが意図される形態で実現されてもよい。各センサ送信機１５０２は、無線遠隔測定ルータ１５００への、さらに、場合によっては、ローカル注入システム内の他のデバイスへの、ユーザの生理学的センサデータの伝送を円滑にする無線送信機を含む。
無線遠隔測定ルータ１５００は、生理学的特性センサ送信機１５０２が範囲内に入る任意の環境に配置されることが可能である。無線遠隔測定ルータ１５００は、複数のセンサ送信機１５０２が、１名の個人によって使用されるシステム、および／または複数の個人を企図するシステム（各個人が、１つだけのセンサ送信機１５０２を使用する）をサポートすることができる。さらに、無線遠隔測定ルータ１５００は、様々なタイプのセンサ送信機をサポートするように適切に構成され、図２１に示される例示的な環境は、インスリン注入システム、またはいずれかの特定のタイプの医療デバイスシステムに限定されなくてもよい。無線遠隔測定ルータ１５００の例示的な応用例には、例えば、以下に示すものが含まれる。すなわち、１名の患者が、複数のセンサ送信機１５０２を有し、それら各送信機１５０２が、異なる生理学的特性を示すデータを提供するように構成されること、家族の複数のメンバがセンサ送信機１５０２を使用する自宅への配置、任意の数の学生に関する生理学的データを監視することが望ましい学校への配置、任意の数の患者に関する生理学的データを監視することが望ましい病院への配置、または患者識別の目的で及び／またはセンサ送信機１５０２からデータを獲得するのに、個別のセンサ送信機１５０２を識別することが望ましい介護者オフィス環境である。
生理学的特性センサ送信機１５０２および無線遠隔測定ルータ１５００は、特定のシステム、および／またはセンサ送信機１５０２の特定のタイプに応じて、単方向（図示されるとおり）であっても、双方向であってもよい各無線リンク１５１８を介して、無線データ通信をサポートするように適切に構成される。したがって、無線遠隔測定ルータ１５００は、複数のセンサ送信機１５０２をサポートすることができる適切に構成された無線通信モジュールを含む。
システムの要件ではないものの、無線リンク１５１８は、同一の無線データ通信プロトコル、および同一の無線データ通信スキームを使用して確立されてもよい。無線遠隔測定ルータ１５００は、無線リンク１５１８のために、例えば、ＲＦ、ＩｒＤＡ（赤外線）、Ｂｌｕｅｔｏｏｔｈ、ＺｉｇＢｅｅ（およびＩＥＥＥ８０２．１５プロトコルのその他の変種）、ＩＥＥＥ８０２．１１（任意の変種）、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ、または他の任意の変種）、直接シーケンス拡散スペクトル、周波数ホッピング拡散スペクトル、セルラー／無線／コードレス遠隔通信プロトコル、無線ホームネットワーク通信プロトコル、ページングネットワークプロトコル、磁気誘導、衛星データ通信プロトコル、無線病院ネットワークプロトコルもしくは医療施設ネットワークプロトコル（ＷＭＴＳ帯域において動作するものなど）、ＧＰＲＳ、および無線ＵＳＢの変種などの独自の無線データ通信プロトコルを含む、任意の数の適切な無線データ通信プロトコル、無線データ通信技術、または無線データ通信方法を利用することができる（ただし、これらに限られるものではない）。例示的な実施形態では、無線リンク１５１８は、産業設備用、科学設備用、および医療設備用に確保された９００〜９３０ＭＨｚ帯域で伝送される。別の例として、病院実施形態における無線リンク１５１８は、病院アプリケーションのために確保されたＷＭＴＳ帯域を利用することができる。センサデータのパッケージ化、誤り検出、セキュリティ、センサ送信機識別、およびその他のセンサデータ処理技術は、知られているプロトコル、または独自のプロトコルによって制御されることが可能である。
無線遠隔測定ルータ１５００は、イーサネット接続を介して（または任意の適切なデータ通信方法を介して）ネットワークデバイスと通信するように構成されることが可能である。図２１は、無線遠隔測定ルータ１５００をネットワークモニタ１５０８、ネットワークコンピュータ１５１０、ネットワークパーソナルデジタルアシスタント１５１２、ネットワーク病院管理システム１５１４、およびネットワークプリンタ１５１６にリンクするイーサネットデータ通信アーキテクチャを表す。もちろん、これらの例示的なネットワークデバイスは、網羅的ではなく、本発明の実施形態は、これらの実施例に限定されない。無線遠隔測定ルータ１５００とネットワークデバイスとの間の所与のリンクは、特定のシステム、および／またはネットワークデバイスの特定のタイプに応じて、単方向（いずれかの方向で）であっても、双方向であってもよい。例えば、無線遠隔測定ルータ１５００からネットワークプリンタ１５１６に至るリンクは、単方向であってもよく、無線遠隔測定ルータからネットワークモニタ１５０８に至るリンクは、単方向であってもよく、さらに他のリンクは、双方向であってもよい。
無線遠隔測定ルータ１５００は、無線パーソナルデジタルアシスタント１５０４や無線ラップトップコンピュータ１５０６などの、適合する無線デバイスとの無線通信をサポートするように構成されることが可能である。したがって、無線遠隔測定ルータ１５００は、無線リンク１５１８を受信する無線通信モジュールとは異なっていてもよい（ただし、異なることは必須ではない）、適切に構成された無線通信モジュールを含む。これに関して、図２１は、無線遠隔測定ルータ１５００と、これらの無線デバイスとの間の無線リンク１５２２を示す。無線遠隔測定ルータと無線デバイスとの間の所与の無線リンクは、特定のシステム、および／または無線デバイスの特定のタイプに応じて、いずれかの方向で単方向であっても、双方向（図２１に示されるとおり）であってもよい。実際には、無線リンク１５２２は、無線遠隔測定ルータ１５００が、ネットワークをバイパスして（すなわち、イーサネットデータ通信アーキテクチャ１５２０を横切ることなしに）、無線デバイスと直接に通信することを可能にする。
システムの要件ではないものの、無線リンク１５２２は、同一の無線データ通信プロトコル、および同一の無線データ通信スキームを使用して確立されることが可能である。この実施例では、無線遠隔測定ルータ１５００は、無線リンク１５２２のために１つの無線データ通信技術を利用し、無線リンク１５１８のために異なる無線データ通信技術を利用する。無線遠隔測定ルータ１５００は、無線リンク１５２２のために、以下に例示する任意の数の適切な無線データ通信プロトコル、無線データ通信技術、または無線データ通信方法を利用することができる。例えば、ＲＦ、ＩｒＤＡ（赤外線）、Ｂｌｕｅｔｏｏｔｈ、ＺｉｇＢｅｅ（およびＩＥＥＥ８０２．１５プロトコルのその他の変種）、ＩＥＥＥ８０２．１１（任意の変種）、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ、または他の任意の変種）、直接シーケンス拡散スペクトル、周波数ホッピング拡散スペクトル、セルラー／無線／コードレス遠隔通信プロトコル、無線ホームネットワーク通信プロトコル、ページングネットワークプロトコル、磁気誘導、衛星データ通信プロトコル、無線病院ネットワークプロトコルもしくは医療施設ネットワークプロトコル（ＷＭＴＳ帯域において動作するものなど）、ＧＰＲＳ、および無線ＵＳＢの変種などの独自の無線データ通信プロトコル等であるが、これらに限定されるものではない。データのパッケージ化、誤り検出、セキュリティ、およびその他のデータ処理技術は、知られているプロトコル、または独自のプロトコルによって制御されることが可能である。
１つの例示的な実施形態では、無線遠隔測定ルータ１５００は、ＨＴＭＬベースのセットアップ／管理／制御インターフェースを含み、このインターフェースは、ＨＴＭＬブラウザ機能と無線遠隔測定ルータ１５００に対する接続とを有する任意の許可されたコンピュータまたはデバイスを介してアクセスされることが可能である。例えば、管理者が、インターネット、および無線パーソナルデジタルアシスタント１５０４上、無線ラップトップコンピュータ１５０６上、ネットワークコンピュータ１５１０上、またはネットワークパーソナルデジタルアシスタント５１２上に存在する従来のウェブブラウザアプリケーションを介して、無線遠隔測定ルータ１５００にアクセスできようにしてもよい。制御インターフェースは、無線遠隔測定ルータ１５００のファームウェア／ソフトウェアの中に存在する１つ以上のＨＴＭＬページとして提供されることが可能である。制御インターフェースは、その特定の無線遠隔測定ルータ１５００に固有であるＩＰアドレスおよび／またはネットワークインターフェースカードを使用してアクセスされるようにしてもよい。パスワード保護およびファイアウォール保護が実施されて、外部からの濫用またはデータ盗難からの保護が提供されるようにしてもよい。
セットアップ手続きに関連して、無線遠隔測定ルータ１５００には、各生理学的特性センサ送信機１５０２のセンサ識別子が与えられてもよい。センサ識別子は、例えば、センサ送信機１５０２の通し番号、または動作環境内の異なるセンサ送信機１５０２を一意に区別する任意の情報であることが可能である。例示的な実施形態では、発信元センサ送信機１５０２によって生成された無線通信信号が、対応するセンサ識別子を伝送する。すると、無線遠隔測定ルータ１５００は、これらのセンサ識別子を適切な仕方で処理することができる。例えば、無線遠隔測定ルータ１５００は、発信元センサ送信機１５０２から無線通信信号を受信し、その無線通信信号に関するセンサ識別子を獲得して、または抽出して、その特定のセンサ識別子によって決定される、制御される、または規定される仕方で、その無線通信信号の中で伝送されるセンサデータを処理することができる。この技術は、無線遠隔測定ルータ１５００が、発信元センサ送信機１５０２、発信元の患者、センサ送信機タイプ、またはその他の関係のある情報を識別することを可能にする。次に、無線遠隔測定ルータ１５００は、そのセンサデータを適切な仕方で処理する、格納する、さらに／またはルーティングすることができる。別の例として、無線遠隔測定ルータ１５００は、第１のセンサ送信機１５０２ａから第１の無線通信信号を受信し、第２のセンサ送信機１５０２ｂから第２の無線通信信号を受信し、そのそれぞれの２つのセンサ識別子（異なるはずである）を獲得して、または抽出して、それらのセンサ識別子によって決定される、制御される、または規定される同期された仕方で、その２つの無線通信信号の中で伝送されるセンサデータを処理することができる。この技術は、無線遠隔測定ルータ１５００が、発信源に応じて、センサデータの受信、処理、格納、および／または伝送に優先順位を付けることを可能にする。
セットアップ手続きに関連して、無線遠隔測定ルータ１５００には、様々な宛先ネットワークデバイスに関するネットワーク識別子（例えば、ＩＰアドレスまたはネットワークインターフェースカード識別子）が提供されることが可能である。そのようなネットワーク識別子により、無線遠隔測定ルータ１５００は、受信されたセンサデータをどのように処理する、扱う、格納する、またはルーティングするかを決定することができるようになる。これに関して、無線遠隔測定ルータ１５００は、例えば、それらの異なるセンサ識別子を含むルックアップテーブル（または任意の適切なメモリ構造またはデータベース構造）、および各センサ識別子についての宛先ネットワーク識別子の対応リストを保持する、またはそのようなルックアップテーブルおよびリストにアクセスすることができる。このルックアップテーブルは、各センサ識別子に関する、対応する処理命令を含むことも可能である。
無線遠隔測定ルータ１５００は、一般に、センサデータを受信し、このセンサデータを１つ以上の宛先ネットワークデバイスにルーティングするように構成される。この実施例では、無線遠隔測定ルータ１５００は、複数の生理学的特性センサ送信機１５０２から複数の無線通信信号を受信し、それら各無線通信信号は、各センサ送信機１５０２によって生成されたセンサデータを伝送する。前述したとおり、各無線通信信号は、発信元センサ送信機１５０２を一意に識別するセンサ識別子を伝送してもよい。すると、無線遠隔測定ルータ１５００は、特定のアプリケーション、ならびに発信元センサ送信機１５０２のＩＤに応じて、受信された情報を適切な仕方で処理することができる。
無線遠隔測定ルータ１５００は、例えば、センサデータの少なくともいくらかを（無線遠隔測定ルータ１５００自体において、または無線遠隔測定ルータ１５００に結合されたネットワークデバイスに）格納すること、センサデータの少なくともいくらかを宛先ネットワークデバイスに転送すること、指定されたネットワークデータ通信プロトコルに適合するように無線通信信号の中で伝送されるデータを再フォーマットすること、またはセンサデータの少なくともいくらかを処理することを含め、受信されたセンサデータに対して１つ以上の動作を実行することができる。例示的な実施形態において、無線遠隔測定ルータ１５００は、システム環境内の別の場所で通常見られるいくらかの機能および処理インテリジェンスを含むことが可能である。例えば、無線遠隔測定ルータ１５００は、較正されていない患者グルコースレベルなどの、較正されていない生理学的特性データを受信して、そのデータを較正してから、宛先ネットワークデバイスにルーティングするように構成されてもよい。
ルーティング機能に関連して、無線遠隔測定ルータ１５００は、指定されたネットワークデータ通信プロトコルに準拠するネットワーク通信を生成することができる。ネットワーク通信は、格納されたセンサデータ、即時にルーティングされるリアルタイムセンサデータ、またはそのようなセンサデータの組合せを含むことが可能な、センサデータを伝送する。そして、無線遠隔測定ルータ１５００は、ネットワーク通信を１つ以上のネットワークデバイスに伝送することができる。無線遠隔測定ルータ１５００は、（あるプロトコルと伝送スキームの組合せを使用する）選択されたネットワークデータ通信プロトコルに従って、また、選択されたデータ通信技術に従って、ネットワーク通信を伝送する。例えば、無線遠隔測定ルータ１５００は、無線リンク１５１８上で受信されるデータと、（別のプロトコルと伝送スキームの組合せを使用する）イーサネットデータ通信アーキテクチャ１５２０を介して伝送されるデータとの間の変換デバイスとして機能することができる。別の例として、無線遠隔測定ルータ１５００は、（あるプロトコルと伝送スキームの組合せを使用する）無線リンク１５１８上で受信されるデータと、（別のプロトコルと伝送スキームの組合せを使用する）無線リンク１５２２を介して伝送されるデータとの間の変換デバイスとして機能することができる。
無線遠隔測定ルータ１５００は、前述した技術を使用してルーティングされることが可能な注意情報、誤り情報、警報情報、および警告情報（「診断情報」）を生成するように構成されることも可能である。この診断情報は、無線遠隔測定ルータ１５００自体において表示され、またはレンダリングされ、さらに／またはネットワークデバイスにおける表示またはレンダリングのためにルーティングされることが可能である。診断情報には、例えば、無線遠隔測定ルータ１５００の動作およびステータスと関係する情報、生理学的特性センサ送信機１５０２の動作またはステータスと関係する情報、ネットワークデバイスの動作またはステータスと関係する情報、あるいは前段でより詳細に説明される通知、警告、警報、またはステータスレポートのいずれかが含まれることが可能であるが、これらに限定されるものではない。
無線医療デバイスネットワークプロトコルおよび無線医療デバイスネットワーク機能
前述したデバイスのいずれかを含む医療デバイスが、ネットワーク環境内の無線データ通信をサポートするように適切に構成されることが可能である。特に明記しない限り、以下の実施例は、無線データが、適切にフォーマットされたデータパケットを使用する医療デバイス間で転送され、さらに、医療デバイス間の通信が、双方向（半２重または全２重）であるものと想定する。一般に、医療デバイスのネットワークは、任意の数（Ｎ）のデバイスを含み、ネットワーク内の医療デバイスのサブネットワークは、このＮ個のデバイスの任意のサブセット（部分集合）を含む。ネットワーク内の所与のデバイスは、複数のサブネットワークに共通であることが可能であり、すなわち、サブネットワークは、必ずしも相互排他的ではない。
前述したとおり、液体注入システムは、無線医療デバイスを有する医療デバイスネットワークの１つの実施例である。ここで、ネットワークデバイスは、例えば、注入ポンプ、生理学的特性センサ送信機、ポータブルディスプレイデバイス、リモートコントローラ、生理学的特性メータ、コントローラ、モニタデバイス、データ変換デバイス、無線遠隔測定ルータなどであってもよい。図２２は、無線データ通信能力および無線ネットワーキング能力を有する医療デバイス１６００の概略の、一般化された図である。デバイス１６００は、前述した無線医療デバイスのいずれかを表すことが可能である。したがって、デバイス１６００は、デバイス１６００の特定の用途および機能に特有である、いくつかのさらなる構成要素および／または代替の構成要素を含むことが可能である。一般に、デバイス１６００は、無線トランシーバモジュール１６０２、有線通信モジュール１６０４、処理アーキテクチャ１６０６、デバイス特有のハードウェア１６０８、ユーザインターフェース１６１０、および適切な量のメモリ１６１２を含むことが可能である。デバイス１６００の要素は、バス１６１４、または任意の適切な相互接続アーキテクチャを介して互いに結合されることが可能である。
無線トランシーバモジュール１６０２は、適切な無線データ通信リンクを使用して、無線データ通信信号を送受信するように適切に構成される。無線信号は、医療デバイスネットワーク内で転送されるべき所望される情報を表すデータを含むデータフィールドを含む。いくつかの実施形態では、無線信号は、所望されるデータフィールドを含むデータパケットを伝送する。これに関して、図２３は、サポートされる無線データ通信モードに対応する様々な動的リンクパラメータを表すデータフィールドを含むデータパケット１７００の一部分の図である。医療デバイス１６００の実施形態は、リンク信頼性設定１７０２、同期設定１７０４、周波数割り当て設定１７０６、再試行周期性設定１７０８、マスタ／スレーブ設定１７１０、および／または送信タイミングインジケータ１７１２と関係する動的リンクパラメータを処理するように構成されることが可能である。これらのリンクパラメータのいずれも、無線データ通信セッション中に動的に更新されることが可能である。さらに、データパケット１７００は、これらの動的リンクパラメータのすべてを伝送する必要はなく、図２３は、説明を容易にするために完全機能のバージョンを示す。これらのリンクパラメータのそれぞれは、後段でより詳細に説明される。
無線トランシーバモジュール１６０２は、医療デバイス１６００と、医療デバイスネットワーク内の他の適合する医療デバイスとの間で確立された無線通信チャネルを介して、無線信号を送信する（さらに／または受信する）ことができる。無線トランシーバモジュール１６０２は、ワイヤレス（ＲＦ）無線モジュールとして一体化された無線受信機モジュールと無線送信機モジュールを含むことが可能である。代替として、医療デバイス１６００は、別々の無線受信機モジュールと無線送信機モジュールを利用することができる。無線トランシーバモジュール１６０２は、無線モジュール１３０８（図１９参照）に関連して前述したとおり構成されることが可能である。
医療デバイス１６００は、有線通信モジュール１６０４を使用して、有線リンクまたはケーブル配線リンクを介するデータ通信をサポートすることができるようにしてもよい。したがって、有線通信モジュール１６０４は、ハードウェア、ソフトウェア、ファームウェア、処理ロジック、または以上の任意の組合せを利用して、医療デバイス１６００に関する所望される有線インターフェースを提供することができる。有線通信モジュール１６０４は、前述した有線データ通信プロトコル（例えば、モニタ５００の説明を参照されたい）のいずれかをサポートするように適切に構成されることが可能である。
処理アーキテクチャ１６０６は、一般に、前述したとおり構成される（例えば、処理アーキテクチャ５１４の説明を参照されたい）。この一般化された医療デバイス１６００に関して、処理アーキテクチャ１６０６は、デバイス特有の処理ロジック１６１６、ならびにデバイス１６００によってサポートされる特定の無線データ通信モジュールのための処理ロジック１６１８を含むことが可能である。デバイス特有の処理ロジック１６１６は、デバイス１６００の動作および機能と関係する処理能力を表す。例えば、デバイス１６００が、注入ポンプである場合、デバイス特有の処理ロジック１６１６は、ポンプ動作と関係する命令を含む。他方、デバイス１６００が患者モニタである場合、デバイス特有の処理ロジック１６１６は、モニタ動作と関係する命令を含む。処理ロジック１６１８は、本明細書で説明される様々な無線データ通信プロトコル、無線データ伝送プロトコル、および動的無線リンクパラメータと関係する様々な命令、制御ロジック、および処理能力を表す。実際には、処理ロジック１６１８の一部は、デバイス特有であることも可能である（ただし、必須ではない）。
デバイス特有のハードウェア１６０８は、医療デバイス１６００の特定の動作および機能と関係するハードウェアおよび／またはファームウェアを表す。例えば、デバイス１６００が、注入ポンプである場合、デバイス特有のハードウェア１６０８は、ポンプ機構を含む。他方、デバイス１６００が、ＢＧメータである場合、デバイス特有のハードウェア１６０８は、血液サンプルストリップまたは血液サンプルスティックのためのレセプタクルを含むことが可能である。
ユーザインターフェース１６１０は、医療デバイス１６００とのユーザ対話を可能にする任意の数の機能を含むことが可能である。ユーザインターフェース１６１０には、前述したユーザインターフェース要素（例えば、ユーザインターフェース２０８の説明を参照されたい）のいずれが含まれることも可能である。
メモリ１６１２は、メモリ５１６に関して前述したとおり実現されることが可能である。メモリ１６１２は、処理アーキテクチャ１６０６が、メモリ１６１２から情報を読み取ること、およびメモリ１６１２に情報を書き込むことができるように、処理アーキテクチャ１６０６に結合されることが可能である。代替として、メモリ１６１２は、処理アーキテクチャ１６０６と一体であってもよい。例として、処理アーキテクチャ１６０６およびメモリ１６１２は、ＡＳＩＣ内に存在してもよい。メモリ１６１２は、一般に、デバイス特有のデータ、ならびに後段でより詳細に説明される様々な無線データ通信モードをサポートするのに必要な任意のデータを格納するように構成される。
医療デバイス１６００（および／または医療デバイス１６００のネットワーク）は、本明細書で説明される様々なプロセスを実行するように適切に構成される。所与のプロセスは、ソフトウェアによって、ハードウェアによって、ファームウェアによって、あるいは任意の組合せによって実行されることが可能である。実施形態において、所与のプロセスの諸部分は、説明されるシステムまたはデバイスの異なる要素によって実行されることが可能である。さらに、説明されるプロセスは、任意の数のさらなるタスク、または代替のタスクを含むことが可能であり、図に示されるタスクは、例示される順序で実行される必要はなく、説明されるプロセスは、本明細書で詳細に説明されないさらなる機能を有する、より包括的な手続きまたはプロセスに組み込まれてもよいことを理解されたい。
本明細書で説明される医療デバイスネットワークは、無線データ通信リンクを使用して互いに通信するように構成された任意の数の無線デバイスを含む。そのようなデータ転送を円滑にするのに、ネットワーク内の各デバイスは、ネットワーク環境内で一意である（さらに、場合により、ネットワーク環境を超えて一意である）キーを使用して識別される。これに関して、図２４は、デバイスに関するキーを導き出すのに使用されることが可能である、例示的なキー生成プロセス１８００を示す流れ図である。デバイスに関してキーが生成されると、そのデバイスは、そのデバイスの一意キーを使用して、医療デバイスネットワークにおける動作のために構成される、初期化される、またはセットアップされる。
キー生成プロセス１８００を利用して、デバイスに関する少なくとも１つのベース識別子からデバイスキーが生成されることが可能であり、ここで、「ベース識別子」は、デバイスおよび／または医療デバイスネットワーク内のデバイスの配置(deployment)の特性に関連する任意の値、量、ビットストリング、または文字ストリングである。したがって、プロセス１８００は、例えば、そのようなベース識別子の１つまたは複数を獲得することによって始まる（タスク１８０２、１８０４、１８０６、１８０８）。デバイス自体がキーを生成する実施形態において、ベース識別子は、デバイスのユーザインターフェースを介して、デバイス自体のメモリから獲得されてもよいし、あるいは医療デバイスネットワーク内の別のデバイスから受信されてもよい。プログラミングデバイスがキーを生成する実施形態において、ベース識別子は、医療デバイスから、プログラミングデバイスのメモリから、または医療デバイスネットワーク内の別のデバイスから獲得されてもよい。
医療デバイスの通し番号が、キー生成プロセス１８００における１つのベース識別子として使用されることが可能である。したがって、プロセス１８００は、デバイスに関する通し番号を取得してもよい（タスク１８０２）。実際には、通し番号は、異なるデバイスタイプにわたって一意であっても、そうでなくてもよいが、通し番号は、所与のデバイスタイプに関して一意でなければならない。本明細書で使用される「デバイスタイプ」とは、医療デバイスネットワーク内で使用されることが可能な医療デバイスのグループ化または分類を表す。例えば、デバイスタイプは、以下のとおり、デバイスの主要な機能を識別することが可能である。すなわち、注入ポンプは、例えば第１のデバイスタイプであり、ＢＧセンサ送信機は、例えば第２のデバイスタイプであり、ＢＧメータは、例えば第３のデバイスタイプであるといった具合である。デバイスタイプは、プロセス１８００において別のベース識別子として使用されることも可能である。したがって、プロセス１８００は、デバイスに関するデバイスタイプ識別子を獲得することができる（タスク１８０４）。
さらに別の適切なベース識別子は、デバイスのユーザに関するユーザ識別子であり、ただし、ユーザ識別子は、デバイスの患者ユーザ、デバイスの介護者ユーザ、デバイスの親ユーザなどを識別することが可能である。したがって、キー生成プロセス１８００は、デバイスのユーザに関するユーザ識別子を取得してもよい（タスク１８０６）。実際には、ユーザ識別子は、異なるユーザクラスを互いに区別するのに使用されることが可能である（例えば、患者ユーザが、介護者ユーザとは異なるアクセス権を有することが可能である）。ユーザ識別子は、医療デバイスが注文された際に割り当てられる顧客ＩＤと同一である（またはそのようなＩＤから導き出される）ようにしてもよい。代替として、ユーザ識別子は、個人用ＩＤとして患者によってプログラミングされることも可能である。このユーザ識別子の１つの用途は、データダウンロードなどのいくつかの機能に関して、制限されたアクセスを介護者に与えることであってもよい。ユーザ識別子は、デバイス通し番号と併せて使用されるので、ユーザ識別子は、異なるユーザクラスを区別する比較的小さいストリング（文字列）として実現されることが可能である。例えば、患者対介護者のシナリオの場合に、この２つのユーザクラスを区別するのに、１ビットで十分である。
さらに別の適切なベース識別子は、医療デバイスネットワーク内のサブネットワークを区別するベース識別子であることが可能である。サブネットワークは、ネットワーク内の無線伝送の量を制限するように確立されることが可能であり、つまり、デバイスは、指定されたサブネットワーク内の他のデバイスとだけ通信するように構成されることが可能である。例えば、ある特定のサブネットワーク識別子が、医療デバイスネットワーク内のデバイスのサブセットに共通となる。Ｎ個の医療デバイスのネットワークに関して、サブネットワーク識別子は、異なるＮ−１個のサブネットワークに対応するのに十分なだけ大きくなければならない。したがって、キー生成プロセス１８００は、デバイスに関する１つ以上のサブネットワーク識別子を取得することができる（タスク１８０８）。もちろん、ネットワークが、サブネットワークをサポートしない場合、タスク１８０８は、省略される。
ベース識別子が取得された後、デバイスに関するキーは、ベース識別子の１つ以上から生成される／導き出されることが可能である（タスク１８１０）。いくつかの実施形態では、タスク１８１０は、複数のベース識別子からキーを導き出す。ベース識別子は、一意のキーを出力として生成する適切に設計されたアルゴリズムへの入力の役割をすることが可能である。実際的な実施形態において、キーは、適切な長さを有するビットのストリングとして実現される。様々なベース識別子、および計算されるキーに割り当てられるビットの数は、時とともに生成されるものと見込まれるシステムの数に対処して、一意性を確実にするのに十分なだけ大きい。キーは、一度、生成されると、ベース識別子の１つ以上の識別子の変更を反映するように、またはネットワーク再構成もしくはデバイス再構成を反映するように特に更新されない限り、固定されたままである。
また、キー生成プロセス１８００は、デバイスにおけるキーの格納を開始することもできる（タスク１８１２）。デバイス自体がキーを生成する実施形態では、タスク１８１２が、デバイスによって実行される。プログラミングデバイスがキーを生成する実施形態では、タスク１８１２は、プログラミングデバイスによって実行される。そのような実施形態では、プロセス１８００は、デバイスにおける格納のために、プログラミングデバイスからデバイスにキーを伝送することが可能である（タスク１８１４）。タスク１８１４は、タスク１８１４のオプションとしての性質を示すように破線内に示される。タスク１８１２に応答して、デバイスは、デバイスの内部メモリの中にキーを格納する（タスク１８１６）。いくつかの実施形態では、プロセス１８００は、医療デバイスネットワーク内の１つ以上の他のデバイスにキーを伝送することも可能である（タスク１８１８）。タスク１８１８は、タスク１８１８のオプションとしての性質を示すように破線内に示される。実施形態に依存して、タスク１８１８は、デバイス自体によって、さらに／またはプログラミングデバイスによって実行されることが可能である。例えば、タスク１８１８は、ネットワーク内の他のすべてのデバイスにキーを伝送することができる。代替の実施例として、タスク１８１８は、ネットワーク内の指定されたマスタデバイスにキーを伝送することが可能である。
様々な実施形態において、各医療デバイスは、ネットワーク内の他のデバイスのキーを使用してプログラミングされる能力を有する。また、デバイスは、ネットワーク内の別のデバイスからベース識別子の１つ以上を受信することができるようにしてもよい。プログラミングは、適切な備えを有するコンピュータデバイス（例えば、パーソナルコンピュータ）を使用して手動で、ローカルメモリストレージもしくはポータブルメモリストレージを介して、ネットワークアクセスを使用して、無線ＰＤＡを使用して、あるいは所望される機能およびユーザインターフェース機能を有する任意のデバイスを使用して、実行されることが可能である。実際、ネットワーク内の任意のデバイスが、そのようなプログラミング機能をサポートするように構成されることが可能である。代替として、キーおよび／またはベース識別子は、工場において、または介護者オフィスにおいてデバイスにあらかじめロードされることが可能である。
キーおよび／またはベース識別子は、適切な「組合せ(marrying)」機能を使用して、ネットワーク内の無線医療デバイスによって交換されることが可能である。例えば、組合せ機能は、第１のデバイスが、データに関して第２のデバイスに問い合わせ、第１のデバイスが、データを受信した後に、データを格納することができるように、手動で初期化されることが可能である。この組合せ機能は、その２つのデバイス間の容量検出を介して初期化されてもよい。組合せ機能が初期化されると、データは、容量結合自体を介して、ＲＦＩＤ伝送を介して、ネットワーク通信プロトコルによる独自の伝送、もしくは他のＲＦ伝送を介して、またはＢｌｕｅｔｏｏｔｈ、Ｚｉｇｂｅｅなどの他の何らかのＲＦデータ通信プロトコルを介して交換されることが可能である。
該当の２つのデバイスは、磁気検知を介して接続されて、その後、前段で説明されるとおり情報を交換することも可能である。データは、磁気接続を使用して転送されることも可能である。該当の２つのデバイスは、光検知（例えば、ＩＲ）を介して接続されて、その後、前段で説明されるとおり情報を交換することも可能である。データは、光接続を使用して転送されることも可能である。
無線医療デバイスネットワークは、特定のアプリケーション、ネットワークトポロジ、運用条件などのニーズに合うように様々なプロトコルを使用して、無線ネットワーク通信を扱うことができる。さらに、医療デバイスは、医療デバイスネットワーク内で無線データパケットを処理する際、デバイスキーを利用することが可能である。デバイスキーは、異なるプロトコル、デバイス特徴、および／または他の可変の特性（後段でより詳細に説明される）を区別する識別子の役割をすることが可能である。例えば、キーは、図２５〜図３０に示される様々なプロセスに関連して使用されることが可能である。
図２５は、無線医療デバイスネットワークにおいて使用するのに適した同期無線通信プロセス１９００を示す流れ図であり、図２６は、プロセス１９００によるデータパケット交換を示す図である。この実施例は、ネットワーク内の各無線医療デバイスが、その他のデバイスのキーの知識を有するものと想定する。これに関して、各デバイスは、医療デバイスネットワーク内で利用されるキーのテーブルを格納することが可能である。さらに、この実施例は、デバイスが、同期データ通信プロトコルを使用して無線データパケットを通信するものと想定する。図２６に示される簡単な実施例は、無線ネットワークトポロジにおいて動作するように構成された３つの医療デバイス、すなわち、ＫＥＹ１によって識別されるモニタ／コントローラ１９５０、ＫＥＹ２によって識別される生理学的センサ送信機１９５２、およびＫＥＹ３によって識別されるＢＧメータ１９５４を含む。実際には、任意のデバイスが、別のデバイスにデータを送信することができ、さらに、これに応じて、肯定応答または否定応答を受信することができることが可能である。以下の実施例は、説明を容易にするために簡略化されている。
同期無線通信プロセス１９００に関連して、デバイスキーのすべてが、この実施例において送信デバイスの役割をする第１のデバイスにおいて保持され（タスク１９０２）、デバイスキーのすべてが、この実施例において受信デバイスの役割をする第２のデバイスにおいて保持される（タスク１９０４）。実際には、ネットワーク内のデバイスによって送信される各データパケットは、送信デバイスのキーを含む。このため、第１のデバイスは、第２のデバイスを宛先とするデータパケットを送信し（タスク１９０６）、そのデータパケットは、第１のデバイスに関するキー、すなわち、「第１のキー」と一緒にある量のデータを伝送する。ある量のデータとは、任意のオーバヘッド（伝送制御等のために用いられる間接費的なデータ）でない関心対象のデータを表す。通常の動作中、第１のデバイスは、ネゴシエートされた同期送信スケジュールに従ってパケットを送信し、したがって、第２のデバイスは、いくつかの指定された時刻に第１のデバイスからパケットを受信することを予期する。
タスク１９０６で送信されたデータパケットは、第２のデバイスによって受信され（タスク１９０８）、第２のデバイスは、受信されたデータパケットのタイミングが、特定の同期設定に合っているかどうかを判定する（クエリタスク１９０９）。つまり、第２のデバイスは、受信されたデータパケットのタイミングおよび同期が正しいかどうか、つまり、予期されるとおりかどうかを検査する。正しい場合、受信されたデータパケットは、第２のデバイスを実際に宛先としていたこととなる。正しくない場合、受信されたデータパケットは、無視されるようにしてもよい（タスク１９１８）。受信されたデータパケットのタイミング特性が正しい場合、第２のデバイスは、受信されたパケットを処理して、第１のキーを抽出し、さらに／またはオーバヘッドでないデータを抽出する（タスク１９１０）。次に、第２のデバイスは、抽出されたキー、および／または抽出されたオーバヘッドでないデータを分析して、このデータパケットが第２のデバイスを宛先としていたかどうかを判定することができる（タスク１９１２）。前述したとおり、デバイスは、同期の仕方でデータを交換する。したがって、第２のデバイスは、指定された時間スケジュールに従って第１のデバイス（および、場合により、ネットワーク内の他のデバイス）からデータを受信することを予期する。抽出されたキーが、予期されるキー（この実施例では、第１のキー）と合致しない場合、第２のデバイスは、受信されたパケットが第２のデバイスを宛先としていなかったと判定する。実際には、第２のデバイスが、ＡＣＫまたはＮＡＫを行うのに、２つの事が生じる必要がある。第１に、メッセージの受信された時刻が、同期設定と合致しなければならない。合致しない場合、第２のデバイスは、そのメッセージを「リッスン」しているべきではなく、ＮＡＫは送信されない。第２に、そのメッセージが、同期タイミングに基づいて、第２のデバイスを宛先としているが、データが壊れている、または別のデバイスに向けられた有効なデータである場合、ＮＡＫが、送信される。このため、ＮＡＫは、タイミングが正しい場合に、壊れたデータ、または無効なデータに応じて生成される。タイミングが正しくない場合、受信されたメッセージは、無視されることが可能である。さらに、または代替として、抽出されたオーバヘッドでないデータが、予期されない特性を有する場合、第２のデバイスは、受信されたパケットが、第２のデバイスを宛先としていなかったと判定する。通常の条件下で、オーバヘッドでないデータは、あまり急速には変化しないいくつかの傾向特性を有することが可能である。抽出されたオーバヘッドでないデータが、異常に急な遷移、または理解不能な内容を有する場合、第２のデバイスは、その受信されたパケットが誤って受信されたものと考えることが可能である。
一部の実施形態では、ネットワーク内の医療デバイスは、いくつかのデバイスキーを無効なキーと指定することができ、ただし、無効なキーは、サポートされていないデバイス、またはブロックされているデバイスに対応する。例えば、第２のデバイスが、第１のキーを有効なキーと指定する場合（クエリタスク１９１４）、第２のデバイスは、第１のデバイスとの無線データ通信をサポートすることができる。したがって、第２のデバイスは、第１のデバイスを宛先とする適切な応答パケットを生成して、送信することができる（タスク１９１６）。応答パケットは、肯定応答メッセージ（ＡＣＫ）またはＮＡＫ（否定応答メッセージ）と一緒に、第２のデバイスに関するキー、すなわち、「第２のキー」を伝送する。例えば、第２のデバイスが、受信されたパケットは、第２のパケットを実際には宛先としていなかったと判定した場合、応答パケットは、ＮＡＫを含むことが可能である。しかし、クエリタスク１９１４が、第１のキーが無効なキーであると判定した場合、第２のデバイスは、さらなるアクションをまったく行うことなしに、その受信されたパケットを単に無視してもよい（タスク１９１８）。
図２６を参照すると、ＢＧメータ１９５４が、ＫＥＹ３およびデータペイロードを含むパケットをモニタ／コントローラ１９５０に送信すると、モニタ／コントローラ１９５０は、ＫＥＹ１、およびＡＣＫメッセージまたはＮＡＫメッセージを含むパケットで応答する。生理学的センサ送信機１９５２からモニタ／コントローラ１９５０に送信されるデータペイロード、およびＢＧメータ１９５４から生理学的センサ送信機１９５２に送信されるデータペイロードに関して、同様の送信／応答スキームを踏襲してもよい。様々な医療デバイス間の送信パケットおよび応答パケットのタイミングは、ネゴシエーションで決定された同期タイミングスキームによって制御される。
図２７は、無線医療デバイスネットワークにおいて使用するのに適した非同期無線通信プロセス２０００を示す流れ図であり、図２８は、プロセス２０００によるデータパケット交換を示す図である。この実施例は、ネットワーク内の各無線医療デバイスが、その他のデバイスのキーの知識を有するものと想定する。さらに、この実施例は、デバイスが、非同期データ通信プロトコルを使用して無線データパケットを通信するものと想定する。図２８に示される簡単な実施例は、無線ネットワークトポロジにおいて動作するように構成された３つの医療デバイス、すなわち、ＫＥＹ１によって識別されるモニタ／コントローラ２０５０、ＫＥＹ２によって識別される生理学的センサ送信機２０５２、およびＫＥＹ３によって識別されるＢＧメータ２０５４を含む。実際には、任意のデバイスが、別のデバイスにデータを送信することができ、さらに、これに応じて、肯定応答または否定応答を受信することができることが可能である。以下の実施例は、説明を容易にするために簡略化されている。
非同期無線通信プロセス２０００に関連して、デバイスキーのすべてが、この実施例において送信デバイスの役割をする第１のデバイスにおいて保持され（タスク２００２）、デバイスキーのすべてが、この実施例において受信デバイスの役割をする第２のデバイスにおいて保持される（タスク２００４）。実際には、ネットワーク内のデバイスによって送信される各データパケットは、送信デバイスのキー、および宛先とされる受信デバイスのキーを含む。このため、第１のデバイスは、第２のデバイスを宛先とするデータパケットを送信し（タスク２００６）、そのデータパケットは、第１のデバイスに関するキー、すなわち「第１のキー」、および第２のデバイスに関するキー、すなわち「第２のキー」と一緒にある量のデータを伝送する。ある量のデータとは、任意の、オーバヘッドでない関心対象のデータを表す。
タスク２００６において送信されたデータパケットは、第２のデバイスによって受信され（タスク２００８）、第２のデバイスは、この受信されたパケットを処理して、キーを抽出し、及び／またはオーバヘッドでないデータを抽出する（タスク２０１０）。次に、第２のデバイスは、第１のキーを分析して、送信デバイスを識別することができる（タスク２０１２）。例えば、第２のデバイスは、抽出されたキーをテーブルの中で調べて、受信されたパケットの発信元を特定することができる。このことは、受信されたパケットの後続の処理が、送信デバイスのＩＤに依存する実施形態において、望ましい可能性がある。また、第２のデバイスは、抽出された第２のキー、および／または抽出されたオーバヘッドでないデータを分析して、そのデータパケットが第２のデバイスを宛先としていたかどうかを判定することもできる（タスク２０１４）。抽出された第２のキーが、第２のデバイスのキーと合致しない場合、第２のデバイスは、受信されたパケットが第２のデバイスを宛先としていなかったと判定する。受信されたキーが、ネットワーク内のあるデバイスに関する有効なキーである場合、第２のデバイスは、その宛先とされる受信デバイスが、ＡＣＫまたはＮＡＫを行うものと理解して、そのメッセージを無視することができる。しかし、受信されたキーが、ネットワーク内のいずれのデバイスに関しても無効である場合、第２のデバイスは、ＮＡＫを生成する。さらに、または代替として、抽出されたオーバヘッドでないデータが、予期されない特性（前述した）を有する場合、第２のデバイスは、受信されたパケットが第２のデバイスを宛先としていなかったと判定する。
最終的に、第２のデバイスは、第１のデバイスを宛先とする適切な応答パケットを生成して、送信することができる（タスク２０１６）。応答パケットは、第１のキー、第２のキー、およびＡＣＫ／ＮＡＫメッセージを伝送する。例えば、第２のデバイスが、受信されたパケットが、実際には第２のデバイスを宛先としていなかったと判定した場合、応答パケットは、ＮＡＫを含むことが可能である。
図２８を参照すると、ＢＧメータ２０５４が、ＫＥＹ３、ＫＥＹ１、およびデータペイロードを含むパケットをモニタ／コントローラ２０５０に送信すると、モニタ／コントローラ２０５０は、ＫＥＹ１、ＫＥＹ３、およびＡＣＫメッセージまたはＮＡＫメッセージを含むパケットで応答する。生理学的センサ送信機２０５２からモニタ／コントローラ２０５０に送信されるデータペイロードに関して、同様の送信／応答スキームを踏襲してもよい。以上の仕方で発信元キーと宛先キーの両方を伝送することにより、医療デバイスネットワーク内の非同期パケット伝送が円滑になる。
医療デバイスネットワークの別の実施形態において、１つのデバイス（通常、モニタ／コントローラ、または液体注入システム内の注入ポンプ）が、マスタデバイスとして指定され、他のすべてのデバイスは、スレーブデバイスとして指定される。マスタデバイスは、ネットワーク内のデバイスのすべてのデバイスに関するキーの知識を有するのに対して、各スレーブデバイスは、自らのキー、およびマスタデバイスに関するキーだけの知識しか有さない。これに関して、図２９は、無線医療デバイスネットワークにおいて使用するのに適した同期マスタ／スレーブ無線通信プロセス２１００を示す流れ図であり、図３０は、プロセス２１００によるデータパケット交換を示す図である。この実施例は、デバイスが、同期データ通信プロトコルを使用して無線データパケットを通信するものと想定する。図３０に示される簡単な実施例は、無線ネットワークトポロジにおいて動作するように構成された３つの医療デバイス、すなわち、ＫＥＹ１によって識別されるモニタ／コントローラ２１５０、ＫＥＹ２によって識別される生理学的センサ送信機２１５２、およびＫＥＹ３によって識別されるＢＧメータ２１５４を含む。この場合、モニタ／コントローラ２１５０が、マスタデバイスである。実際には、任意のデバイスが、別のデバイスにデータを送信することができ、さらに、これに応答して、肯定応答または否定応答を受信することができるようにしてもよい。以下の実施例は、説明を容易にするために簡略化されている。
プロセス２１００に関連して、マスタデバイスキー（ＫＥＹＭ）および各スレーブデバイスキー（ＫＥＹＳ）を含むデバイスキーのすべてが、この実施例において受信デバイスの役割をするマスタデバイスにおいて保持される（タスク２１０２）。さらに、マスタデバイスキー、および各スレーブデバイスキーは、医療デバイスネットワーク内の各スレーブデバイスにおいて保持される（タスク２１０４）。この実施例では、スレーブデバイスの１つが、送信デバイスの役割をする。実際には、ネットワーク内のスレーブデバイスによって送信される各データパケットは、マスタデバイスのキーを含み、他のキーはまったく含まなくてもよい。このため、スレーブデバイスは、マスタデバイスを宛先とするデータパケットを送信し（タスク２１０６）、そのデータパケットは、マスタデバイスに関するキー、すなわち、「マスタキー」と一緒にある量のデータを伝送する。ある量のデータは、任意のオーバヘッドでない関心対象のデータを表す。通常の動作中、スレーブデバイスは、ネゴシエーションにより決定された同期送信スケジュールに従ってパケットを送信し、したがって、マスタデバイスは、いくつかの指定された時刻にスレーブデバイスからパケットを受信することを予期する。
タスク２１０６において送信されたデータパケットは、マスタデバイスによって受信され（タスク２１０８）、マスタデバイスは、この受信されたパケットを処理して、マスタキーを抽出し、さらに／またはオーバヘッドでないデータを抽出する（タスク２１１０）。次に、マスタデバイスは、抽出されたマスタキー、および／または抽出されたオーバヘッドでないデータを分析して、そのデータパケットがマスタデバイスを宛先としていたかどうかを判定することができる（タスク２１１２）。前述したとおり、デバイスは、同期的にデータを交換する。したがって、マスタデバイスは、指定された時間スケジュールに従ってスレーブデバイス（および、場合により、ネットワーク内の他のデバイス）からデータを受信することを予期する。抽出されたマスタキーが、予期されるキー（この実施例では、ＫＥＹ１）と合致しない場合、マスタデバイスは、受信されたパケットがマスタデバイスを宛先としていなかったと判定する。さらに、または代替として、抽出されたオーバヘッドでないデータが、予期されない特性（前述した）を有する場合、マスタデバイスは、受信されたパケットがマスタデバイスを宛先としていなかったと判定する。
最終的に、マスタデバイスは、スレーブデバイスを宛先とする適切な応答パケットを生成して、送信することができる（タスク２１１４）。応答パケットは、スレーブデバイスに関するキー、およびＡＣＫ／ＮＡＫメッセージを伝送する。例えば、マスタデバイスが、受信されたパケットが、マスタデバイスを実際には宛先としていなかったと判定した場合、応答パケットは、ＮＡＫを含むことが可能である。
この実施例において通信コーディネータまたはハブとして機能するマスタデバイスは、必要に応じて、データを（要求される場合には適切なデータ再フォーマットの後）他のスレーブデバイスに中継することができる（タスク２１１６）。例えば、ＢＧメータ２１５４が、モニタ／コントローラ２１５０にデータを送信することができ、すると、モニタ／コントローラ２１５０は、このデータを生理学的センサ送信機２１５２に転送することができる。マスタデバイスによって送信されるデータパケットは、任意のタイプのデータを伝送することができる。例えば、マスタデバイスによって送信されるデータパケットは、その他のデバイスが同期するマスタクロック時間を伝送してもよい。
図３０を参照すると、ＢＧメータ２１５４は、ＫＥＹ１（マスタキー）およびデータペイロードを含むパケットをモニタ／コントローラ２１５０に送信し、モニタ／コントローラ２１５０は、ＫＥＹ３（ＢＧメータ２１５４に関するスレーブキー）およびＡＣＫメッセージまたはＮＡＣメッセージを含むパケットで応答する。代替として、応答パケットは、キーをまったく含まなくてもよく、特定の応答タイムスロットは、発信元デバイスに対して応答するデバイスを識別する。生理学的センサ送信機２１５２からモニタ／コントローラ２１５０に送信されるデータペイロードに関して、同様の送信／応答スキームを踏襲してもよい。特に、このマスタ／スレーブスキームの下で、生理学的センサ送信機２１５２とＢＧメータ２１５４は、互いの間で無線データパケットを直接に通信することができず、マスタデバイスを介して互いに間接的に通信する。様々な医療デバイス間の送信パケットおよび応答パケットのタイミングは、ネゴシエーションにより決定される同期タイミングスキームによって支配される。
特に、同期通信に関して、ＡＣＫ／ＮＡＫパケットは、送信デバイスのキーを要求する必要がない。さらに、送信デバイスがＡＣＫ／ＮＡＫパケットと一緒にそのデバイスのキーを送信するシステム実施形態においては、非同期通信がサポートされるようにしてもよい。そのような実施形態では、応答のデバイスキーの伝送により、同期されたタイミングにまったく依拠する必要のない仕方で、マスタデバイスに対して、応答側のデバイスが識別される。
ネットワーク配置に依存して、ネットワーク内の各医療デバイスが、ネットワーク内の他のすべての医療デバイスと通信できることが必要ないようにしてもよい。あるデバイスが、ネットワーク内のデバイスのサブセットとだけ通信することが望ましい場合もある。これに関して、図３１は、医療デバイスネットワーク内の無線医療デバイスの２つのサブネットワークを示す図である。この簡略化された実施例では、ネットワークは、モニタ／コントローラ２２０２、生理学的センサ送信機２２０４、臨床モニタ２２０６、およびＢＧメータ２２０８を含む。サブネットワーク１は、モニタ／コントローラ２２０２、生理学的センサ送信機２２０４、および臨床モニタ２２０６を含み、サブネットワーク２は、モニタ／コントローラ２２０２およびＢＧメータ２２０８を含む。各デバイスは、そのデバイスが属する異なるサブネットワークを識別する１つ以上のコードまたは適切にフォーマットされたサブネットワークインジケータに関連付けられる。このため、この実施例では、モニタ／コントローラ２２０２は、異なる２つのサブネットワーク識別子を有する。
実際には、医療デバイスネットワーク内の異なるサブネットワークは、異なる同期タイミングスキームを利用して、パケット衝突を回避することができる。いくつかの実施形態では、医療デバイスネットワークは、異なる同期タイミングスキームを調整して、様々なサブネットワークの同時の動作を可能にする（例えば、複数のサブネットワークに共通であるデバイスに関する同時のパケット伝送を回避する）ように構成されることが可能である。効率を向上させ、不要なパケット伝送を減らすために、１つのサブネットワーク内の医療デバイスが、別のサブネットワーク内の医療デバイスとの通信を回避するように構成され、その別のサブネットワーク内の医療デバイスが、その１つのサブネットワーク内の医療デバイスとの通信を回避するように構成されることが可能である。この機能は、一実施形態では、以下の仕方で達せられることが可能である。所与のサブネットワーク内のデバイスは、そのサブネットワーク内の他のデバイスに対応する有効なデバイスキーのリストを保持し、そのサブネットワーク内に存在しないデバイスに対応する無効なデバイスキーのリストを保持する。その結果、そのサブネットワーク内のデバイスによって受信されるパケットは、有効なデバイスキーに関連付けられていなければならず、さもなければ、受信されたパケットは、破棄される、または無視される。
無線医療デバイスが、ネットワーク内の複数の宛先デバイスによる可能な受信のために、データパケットのブロードキャスト伝送を実行することが可能であるネットワーク配置もあり得る。この場合、受信デバイスは、指定された所定のシーケンス（順番）で、または擬似ランダムな順序で応答する（ＡＣＫ／ＮＡＫ）。１つ以上の受信デバイスからＮＡＫ応答があった場合、または応答がまったくない場合、送信デバイスは、すべてのデバイスにパケットを再送し、ＡＣＫ／ＮＡＫメッセージを再び待つことができる。そのような再送が、所定の回数の再試行の試みで繰り返されてから、ユーザに通知が行われるようにしてもよい。
図３２は、無線医療デバイスネットワークにおいて使用するのに適したブロードキャスト伝送プロセス２３００を示す流れ図であり、図３３は、プロセス２３００によるデータパケット交換を示す図である。この実施例は、ネットワークデバイスが、共通の搬送周波数を使用して、同期された仕方でデータを通信するように構成されるものと想定する。また、少なくとも以下の２つのシナリオも可能である。第１のシナリオでは、「中継（リピータ）」ネットワーク内のデバイス群は同一の周波数であることが可能であるが、それら各デバイスは、それぞれ互いに異なる周波数で患者によって保持されるデバイスと通信することができる。第２のシナリオでは、少なくとも１ペアのデバイスが通信できるように同一の周波数である限り、ネットワーク内のデバイス群は、異なる周波数であることが可能である。図３３において、送信デバイス２３５０は、第１の受信デバイス２３５２、および第２の受信デバイス２３５４を含め、複数の受信デバイスに無線データパケットをブロードキャストするように構成される。
ブロードキャスト伝送プロセス２３００に関連して、乱数発生器のインスタンシエーション（クラスから生成された具体例：インスタンス）が、各デバイスにおいて保持される（タスク２３０２）。図２２を参照すると、乱数発生器が、例えば、それぞれのデバイスの処理ロジック１６１８において実現されることが可能である。「同一の」乱数発生器が、各デバイスにおいて動作可能であり、したがって、同一の値が種（シード）として与えられた場合、乱数発生器の各インスタンシエーションは、同一の擬似乱数シーケンスを生成する。したがって、プロセス２３００は、初期化ステップとして、適切な共通の種の値を乱数発生器の各インスタンシエーションに与えることができる（タスク２３０４）。このことにより、プロセス２３００が、乱数発生器を使用してデバイスにおいて擬似ランダムの順序を導き出すことが可能になり（タスク２３０６）、ここで、この擬似ランダムの順序は、共通の種の値に応じて導き出される。
次に、送信デバイスが、適切な無線データ伝送プロトコルを使用して、無線医療デバイスネットワーク内の他の複数のデバイスにデータパケットをブロードキャストする（タスク２３０８）。図３３は、このブロードキャスト伝送が、時刻Ｔ０に行われることを示す。複数のデバイスが、ブロードキャストされたパケットを受信するものと想定すると、受信デバイスは、送信デバイスに返送するためにそれぞれの応答パケットを生成する（タスク２３１０）。その後、受信デバイスは、タイムスロットを使用して、さらに／または擬似ランダムな順序によって決定されるシーケンスを使用して、応答パケットを送信する（さらに、発信元デバイスは、これらの応答パケットを受信する）（タスク２３１２）。一実施形態では、この擬似ランダムな順序（ネットワークデバイスと共有される）を利用して、受信デバイスに関する異なる応答タイムスロットが導き出され、つまり、各受信デバイスは、そのデバイスの応答パケットを送信するための擬似ランダムに指定されたタイムスロットを有する。別の実施形態では、この擬似ランダムな順序を利用して、受信デバイスに関する送信シーケンスが導き出され、つまり、各受信デバイスは、そのデバイスの応答パケットを、指定されたシーケンスの順序で送信する。図３３は、第１の受信デバイス２３５２に関する応答が、時刻Ｔ１において送信されること、および第２の受信デバイス２３５４に関する応答が、時刻Ｔ２において送信されることを示す。
このため、送信デバイスは、乱数発生器に関する共通の種の値に基づく擬似ランダムな順序で応答パケットを受信する。送信デバイスも、乱数発生器（同一の種の値を有する）のインスタンシエーションを保持するので、受信された応答パケットを、受信デバイスと互いに関係付けることができる。このようにして、送信デバイスは、受信デバイスのＩＤを解決し、それに応じて、それぞれの応答パケットを処理することができる。
無線医療デバイスは、より広域にわたってメッセージを送信するために、「中継器（リピータ）」として機能するように適切に構成されることが可能である。実際には、そのような中継（リピータ）デバイスは、臨床モニタまたはリモートアナンシエータなどの比較的固定のデバイスで実現されることが可能である。医療デバイスネットワークは、ネットワーク環境内で無線メッセージを転送するように構成された任意の数の中継デバイスを含むことが可能である。さらに、この中継デバイスは、ＵＳＢリンクを介してＰＣに接続された変換（トランスレーション：中継）デバイスの役割をすることが可能である。この場合、中継デバイスは、ＰＣに接続されている場合、ＵＳＢインターフェースによって、または物理的ＵＳＢコネクタを介して電力を供給するＡＣアダプタを介して供給される電力で動作することができることが可能である。代替として、そのような中継／変換デバイスは、インターネットと直接に通信するように構成されることも可能であり（任意の適切なデータ通信技法またはデータ通信技術を使用して）、その場合、そのようなデバイスは、デバイス独自のＩＰアドレスを有する。
図３４は、無線医療デバイスネットワークにおいて使用するのに適した無線中継プロセス２４００を示す流れ図であり、図３５Ａは、プロセス２４００によるデータパケット交換を示す図である。図３５Ａに示される実施例は、発信元デバイス２４５０（すなわち、第１のデバイス）、第２のデバイス２４５２、宛先デバイス２４５４（すなわち、第３のデバイス）、第４のデバイス２４５６、および第５のデバイス２４５８を含む。この場合、発信元デバイス２４５０が、宛先デバイス２４５４を宛先とする無線メッセージまたは無線データパケットを送信する。プロセス２４００、およびプロセス２４００と同等の変種は、宛先デバイス２４５４にメッセージを転送するのに使用される。
無線中継プロセス２４００は、例えば、発信元デバイスが、宛先デバイスを宛先とするメッセージを生成することで開始される（タスク２４０２）。この実施形態では、メッセージは、無線データパケットを使用して伝送され、発信元デバイスは、適切な無線通信リンクを使用して、このメッセージを送信する。このメッセージは、例えば、医療デバイスネットワークに関する警報、ステータス情報、ユーザリマインダ、患者データ、または前述したデータタイプのいずれかを含む、任意のタイプのデータを含む、または伝送することが可能である。
発信元デバイスは、所定の順序付けられたシーケンス、擬似ランダムシーケンス、または医療デバイスネットワーク内の複数のデバイスに関する任意の適切なシーケンスに従って、メッセージを送信するように構成されることが可能である。図３５Ａに示される実施例では、順序付けられたシーケンスは、デバイス番号をたどる「循環」パスに対応する。このため、第４のデバイス２４５６が、発信元デバイスである場合、順序付けられたシーケンスは、以下のとおりである。すなわち、第５のデバイス２４５８、第１のデバイス２４５０、第２のデバイス２４５２、第３のデバイス２４５４、第４のデバイス２４５６である。第２のデバイス２４５２が、発信元デバイスである場合、順序付けられたシーケンスは、以下のとおりである。すなわち、第３のデバイス２４５４、第４のデバイス２４５６、第５のデバイス２４５８、第１のデバイス２４５０、第２のデバイス２４５２である。また、医療デバイスネットワーク内のデバイスのシーケンスは、ネットワーク全体にわたってルーティングされる無線パケットに関する転送順序を表すことも可能である。実際には、転送順序は、所望される任意のパスをたどることができ、ネットワーク内の１つ以上のデバイスが、そのパスから省かれることが可能である。さらに、転送パスは、冗長性のためにネットワーク内のあるデバイスに戻ることも可能である。
この実施例の目的で、第１のデバイス２４５０が、発信元デバイスであり、したがって、タスク２４０２は、第１のデバイス２４５０から第２のデバイス２４５２に無線データ通信リンク２４６０を介して、メッセージを伝送する。通常の動作条件下で、第２のデバイス２４５２は、無線データ通信リンク２４６０を介して、このメッセージを受信する。この実施例は、このメッセージが、第３のデバイス２４５４（すなわち、宛先デバイス）を宛先とするものと想定する。したがって、第２のデバイス２４５２は、このメッセージに関する中継／転送デバイスの役割をする。しかし、メッセージが、第２のデバイス２４５２を宛先とする場合、メッセージは、医療デバイスネットワーク内で転送されなくてもよい。
受信デバイス（この実施例では、第２のデバイス２４５２）は、このメッセージ、および／またはこのメッセージに関連するオーバヘッドデータを処理して、このメッセージに関する所望される転送順序を決定することができる（タスク２４０６）。前述したとおり、転送順序は、医療デバイスネットワーク内のデバイスのシーケンスを表し、転送順序は、医療デバイスネットワーク内の宛先デバイスの位置に基づくことが可能である。例えば、デバイスは、ネットワーク内の無線デバイス間で、より少ない「ホップ」を有するパスを有利にする仕方で転送順序を決定することができる。この実施形態では、転送順序は、所与のネットワークトポロジに関して固定であり、受信デバイスは、格納されたデバイスシーケンスを調べて、転送先のデバイスのＩＤを特定することができる。
次に、受信デバイスは、（必要な場合は）受信されたメッセージを転送のためにフォーマット（書式設定し）し、宛先デバイスに到達することが意図される適切な仕方で、受信されたメッセージを医療デバイスネットワーク内で転送する。受信デバイスは、無線データ通信リンクを介して、ネットワーク内の別のデバイスにメッセージを転送する（タスク２４０８）。ネットワークトポロジおよび転送順序に依存して、この別のデバイスは、宛先デバイス自体、または宛先デバイス「より前に」位置する中間デバイスであることが可能である。図３５Ａは、第２のデバイス２４５２が、受信されたメッセージを、無線データ通信リンク２４６２を介して第３のデバイス２４５４に転送する例を示す。この場合、第３のデバイス２４５４が、意図される宛先デバイスである。
一般に、転送されたメッセージは、医療デバイスネットワークの中を進むにつれ、各デバイスによって処理されることが可能である（タスク２４１０）。必要な場合、デバイスは、ペイロードデータを抽出し、このデータを適切な仕方で処理することができる。代替として、デバイスは、メッセージ転送の目的でオーバヘッドデータを分析してもよい。この実施例では、無線中継プロセス２４００は、デバイスのそれぞれがメッセージを処理するまで、医療デバイスネットワーク内でこのメッセージを転送する。このことは、意図される宛先デバイスが、このメッセージを既に受信し、処理している場合でも、行われることが可能である。したがって、このメッセージが、すべてのデバイスによって処理されてはいない場合（クエリタスク２４１２）、プロセス２４００は、タスク２４０８に再び入って、このメッセージのさらなる転送を開始することが可能である。すべてのデバイスによって処理されている場合、プロセス２４００は、終了する。図３５Ａを参照すると、メッセージは、第３のデバイス２４５４から第４のデバイス２４５６に、第４のデバイス２４５６から第５のデバイス２４５８に、さらに第５のデバイス２４５８から第１のデバイス２４５０に戻るように転送されることが可能である。第１のデバイス２４５０は、デバイス２４５０が、このメッセージの発信元であることを認識し、したがって、このメッセージを転送することなしに無視するように適切に構成されることが可能である。
無線中継プロセス２４００は、共通のメッセージ（例えば、モニタデバイスによって生成された警報メッセージ）が、複数のデバイスによって検出されて、転送される状況に対処するように変形されることが可能である。例えば、医療デバイスネットワーク内のデバイスの１つが、ネットワーク内の複数の宛先デバイスを宛先とする所与のメッセージに関する「ブロードキャストするデバイス」と指定されることが可能である。実際には、ブロードキャストメッセージは、ネットワーク内の１つ以上の宛先デバイスによって無線で受信されることが可能である。これが行われると、ブロードキャストメッセージを受信した任意の宛先デバイスが、他の１つ以上の宛先デバイスに、このメッセージを無線で転送することができる。特に、共通のブロードキャストメッセージが、医療デバイスネットワーク内の異なる転送パスを使用して、同時に転送されることが可能である。しかし、各デバイスは、そのデバイスが転送されたメッセージを既に受信しているか否かを判定することができるようにする、適切に構成された処理ロジックを有することが可能である。デバイスは、そのデバイスが共通のメッセージを既に受信している（さらに、転送している）と判定した場合、このメッセージを無視することを選択することができる。
ブロードキャストメッセージは、医療デバイスネットワークに関する警報を伝送することができる。警報を伝送する場合、この警報メッセージを受信する各宛先デバイスが、この警報メッセージに応答して警報指示を生成することが可能である。この警報指示は、所望される構成、およびユーザ設定に応じて、可聴の指示および／または視覚的指示であることが可能である。いくつかの実施形態では、本明細書で説明される無線中継技術は、警報終了（消音）メッセージを扱うのに利用されることも可能である。例えば、警報終了メッセージが、任意の適切な仕方で（通常、デバイスとのユーザ対話に応答して）、医療デバイスネットワーク内の第１のデバイスにおいて生成されることが可能である。警報終了メッセージは、第１のデバイスにおける警報が終了されるように、第１のデバイスによって処理されることが可能である。加えて、第１のデバイスは、その他のデバイスにおける関連する警報を終了させる目的で、ネットワーク内の１つ以上の宛先デバイスに警報終了メッセージを無線で転送することができる。このため、転送された警報終了メッセージは、別のデバイスにおいて無線で受信されることが可能であり、すると、この別のデバイスは、転送された警報終了メッセージに応答して、この別のデバイスの警報を終了させる。警報終了メッセージは、すべての警報が消音されるまで、このようにして転送されることが可能である。
患者によって保持される、または患者によって着用されるデバイスも、医療デバイスネットワークの一部であると考えることが可能であり、したがって、本明細書で説明されるメッセージ転送技術およびメッセージ中継技術の対象である。例えば、ネットワーク内の中継デバイス／アナンシエータデバイスにおいて警報を消音することにより、そのデバイスが、患者デバイスに関する警報終了メッセージを生成（または転送）させられるようにしてもよい。この警報終了メッセージを受信すると、患者デバイスは、患者デバイスの警報を終了させる（警報が依然としてアクティブ状態である場合）。同様に、患者デバイスにおいて警報を消音することにより、患者デバイスが、医療デバイスネットワーク内の１つ以上の宛先デバイスに関する警報終了メッセージを生成（または転送）させられる。その後、警報終了メッセージは、前述した仕方で、ネットワーク内で転送／ブロードキャストされることが可能である。
また、ネットワーク内のデバイスは、警報を鳴らさないように構成されることも可能である。このことは、夜間対日中などの、あらかじめプログラミングされた時間スケジュールで、またはいつでも必要に応じて、実行されることが可能である。必要に応じて実行されるシナリオにおいて、デバイスを誤って永久に消音することを防止するのに、デバイスは、規定された時刻に、あらかじめプログラミングされたモードに切り替わるように設計されることが可能である。
図３５Ｂは、無線医療デバイスネットワークに関連して実現されることが可能な、無線告知／中継システム２４８０を示す図である。前述したプロセス２４００が、システム２４８０の動作をサポートするように適切な仕方で変形されることが可能である。この場合、システム２４８０は、４つのアナンシエータ(annunciator)／中継器（リピータ）デバイス（符号２４８２、２４８４、２４８６、および２４８８によって識別される）を含む。所与のアナンシエータ／中継器は、臨床モニタなどの完全機能のデバイスであることも、ユーザインターフェースを有する、または有さない低減された機能のデバイスであることも可能である。任意の数のこれらのデバイスが、無線中継(リピータ）ネットワーク内で使用されることが可能である。図３５Ｂに示される実施例は、アナンシエータ／中継器２４８４によって受信されるメッセージ、通常、警報または警告を送信する、患者によって保持されるデバイス２４９０を含む。患者によって保持されるデバイス２４９０の位置は、アナンシエータ／中継デバイスに知られていないので、アナンシエータ／中継デバイスの１つ以上が、このメッセージを受信することが可能であることに留意されたい。
この場合、アナンシエータ／中継器２４８４は、リンクにおける次のデバイスにメッセージを転送する（中継する）といった具合である。各アナンシエータ／中継デバイスは、介護者の位置が知られていないので、適切な警報／警告を鳴らすことができる。受信するアナンシエータ／中継デバイスは、送信するアナンシエータ／中継デバイスにＡＣＫまたはＮＡＫで応答することができる。患者によって保持されるデバイス２４９０は、ＡＣＫ／ＮＡＫコマンドをリッスンして、ＡＣＫ／ＮＡＫコマンドに応答することができる。さらに、患者によって保持されるデバイスは、メッセージが送信されている間にその同じ位置にないようにしてもよく、したがって、患者によって保持されるデバイスは、好ましくは、そのチェーン（つらなり）における各アナンシエータ／中継デバイスと通信することができるように構成される。図３５Ｂで、患者によって保持されるデバイス２４９０が、ＡＣＫ／ＮＡＫメッセージをアナンシエータ／中継器２４８２から受信する。警報は、アナンシエータ／中継デバイスにおいて消音される（一時的に、または永久に）ことが可能である。これに関して、消音メッセージは、各アナンシエータ／中継デバイスによってチェーンにおける次のデバイスに送信される。さらに、患者によって保持されるデバイス２４９０は、警報消音コマンドをリッスンして、警報を生じさせる条件に、患者によって保持されるデバイス２４９０上で対応がなされるまで、警報を一時的に停止することによって、警報消音コマンドに応答することができる。
中継／転送機能は、独自のプロトコル、またはＺｉｇＢｅｅ、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉなどの市販のプロトコルを役立てることができる。さらに、アナンシエータ／中継デバイスのネットワークのためのプロトコルは、自己修復型であるように設計されて、いずれかのアナンシエータ／中継デバイスが動作不良を起こした場合、自己修復型メッシュネットワークの場合と同様に、ネットワーク化されたアナンシエータ／中継デバイスが、接続を維持することができるようにすることが可能である。さらに、ネットワークプロトコルは、いずれのデバイスが機能不全を起こしたかを特定することができ、その他のアナンシエータ／中継デバイスの１つを介して警報を鳴らすように構成される。また、アナンシエータ／中継デバイスは、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ、またはセルラーなどの別の通信プロトコルを備えて、本来的に、中継ネットワーク、または患者によって保持されるデバイス２４９０の一部ではないデバイスにメッセージを転送することも可能である。１つの好適な例は、患者によって保持されるデバイスが、第１の遠隔測定を介して、アナンシエータ／中継ネットワークにメッセージを送信し、アナンシエータ／中継ネットワークは、第２の遠隔測定を使用して、そのメッセージをアナンシエータ／中継ネットワーク内で転送し、さらに、指定された１つのアナンシエータ／中継器も、第３の遠隔測定（第２の遠隔測定、または第１の遠隔測定と同一であってもよい）を介して、そのメッセージを、セル電話機などの別のデバイスに転送する場合である。
中継ネットワークにおいて、患者によって保持されるデバイスの位置は知られていないものの、受信される信号強度によって、チェーンにおけるいずれの中継器が患者によって保持されるデバイスに最も近いかを特定することが可能である。最高の信号強度を有するデバイスが、チェーンにおける次の中継器へのメッセージの転送を開始する。このことは、中継ネットワークデバイスが、互いに定常的に通信していることを意味し、このことは、チェーンにおけるデバイスに障害が生じていないことを確実にすることに、いずれにしても当てはまる。
代替として、メッセージ転送は、チェーンにおけるデバイスが、事前設定された閾値を超える受信信号強度測定値を獲得した場合、トリガされることが可能である。これに関して、あるデバイスが、少なくとも閾値信号強度を有するメッセージを受信すると、そのデバイスは、メッセージの転送を開始することができる。２つ以上のデバイスがすべて、同一の信号強度を有するメッセージを受信した場合、転送スキームは、前述したスキームの１つに切り替わることが可能である。
医療デバイスネットワークに関するデバイスは、無線中継器／アナンシエータとデータ通信変換デバイス（図１８〜図２０、および関連する説明を参照されたい）の機能を組み合わせる仕方で、適切に構成されることが可能である。そのようなデバイスは、コンピュータに結合された場合にＵＳＢ接続によって、従来の家庭用ＡＣ電源によって、またはＵＳＢコネクタを有するＡＣアダプタもしくはＤＣアダプタによって電力を供給されることが可能である。このデバイスは、完全機能の構成要素（例えば、前述した臨床モニタもしくは病院モニタ）として構成されることも、最低限のユーザインターフェースを有する、またはユーザインターフェースをまったく有さない低機能の構成要素として構成されることも可能である。例えば、最低限のユーザインターフェースは、警報消音／終了ボタンを含み、さらに、場合により、オーディオ警報に関する音量制御要素を含むことが可能である。実際には、そのような複合デバイスが、パーソナルコンピュータ、または他の適切なコンピューティングデバイス（例えば、ＵＳＢ接続を使用する）を介してプログラミング可能である可能性がある。
本明細書で説明される無線医療デバイスの実施形態が、信頼できる無線リンク（欠落したパケット、または肯定応答のないパケットが、警報の生成をもたらす）と信頼できない無線リンク（欠落したパケット、または肯定応答のないパケットが、警報の生成をもたらさない）の両方を、動的に切り替わる仕方で、様々な基準に応じてサポートするように構成されることが可能である。実際には、信頼できないリンクは、例えば、「ベストエフォート」サービス品質に関連する。動的に切り替え可能な無線リンクの１つの例が、注入ポンプと、このポンプに関する臨床モニタとの間の無線リンクである。このリンクは、患者が眠っており、臨床モニタの近くにいる間、信頼できるリンクであるものの、日中、このリンクは、患者が臨床モニタの信頼できる範囲の外にいる可能性がある時間に対応するように、ベストエフォートリンクに切り替わることが可能である。患者（および注入ポンプ）が、臨床モニタの範囲内に戻ると、このリンクは、信頼できるリンクに戻るように切り替わることが可能であり、蓄積された患者データが、バッチモードで伝送されることが可能である。
例えば、図３６は、無線医療デバイスネットワークにおいて使用するのに適したリンク信頼性選択プロセス２５００を示す流れ図である。プロセス２５００は、信頼できるリンクと信頼できないリンクの両方をサポートするように構成された無線医療デバイスによって実行されることが可能である。プロセス２５００は、「信頼できるリンク」モード、または「信頼できないリンク」モードを選択することで始まることが可能である（タスク２５０２）。タスク２５０２は、医療デバイスシステムのユーザによって行われた選択に応答することが可能であり、この選択は、現在の動作条件に応答して医療デバイスによって自動的に開始されることが可能であり、あるいはこの選択は、システム内の別のデバイスによって行われて、送信デバイスに通信されることが可能である。例えば、特定の無線データ通信モードは、（１）デバイス間で転送されるべきデータに関連付けられた優先度、（２）デバイス間で転送されるべきデータに関連付けられたデータタイプカテゴリ、（３）所定のスケジュール、（４）送信出力基準、および／または（５）デバイス間の無線データ通信セッションに関するサービス品質測定値に応じて選択されることが可能である。項目（１）に関して、信頼できるリンクモードは、比較的高い優先度でマークが付けられたデータに関して選択されることが可能であるのに対して、信頼できないリンクモードは、比較的低い優先度でマークが付けられたデータに関して選択されることが可能である。項目（２）に関して、信頼できるリンクモードは、警報やイベントマーカなどの緊急の項目、または時間に厳しい項目に関して選択されることが可能であるのに対して、信頼できないリンクモードは、背景情報またはデバイスステータス情報に関して選択されることが可能である。項目（３）に関して、信頼できるリンクモードは、通常の睡眠時間中に選択されることが可能であるのに対して、信頼できないリンクモードは、通常の勤務時間中に選択されることが可能である。項目（４）に関して、信頼できるリンクモードは、比較的高い出力の伝送に関して選択されることが可能であるのに対して、信頼できないリンクモードは、比較的低い出力の伝送に関して選択されることが可能である。項目（５）に関して、信頼できるリンクモードは、デバイス間の無線チャネルが、比較的高い品質である場合に選択されることが可能であるのに対して、信頼できないリンクモードは、デバイス間の無線チャネルが、比較的低い品質である場合に選択されることが可能である。もちろん、無線データ通信モードの動的選択は、これらの例に限定される必要はなく、医療デバイスシステムの実施形態は、タスク２５０２中に行われる選択を支配する異なる基準を利用してもよい。
リンク信頼性モードが選択された後、送信デバイスは、選択されたモードにおける動作をサポートするように構成される（タスク２５０４）。これに関して、送信デバイスは、動的に選択可能なモードのいずれか（この例では、信頼できるリンクモードまたは信頼できないリンクモード）をサポートするように構成される。また、リンク信頼性選択プロセス２５００は、モード識別子を生成して、受信デバイスに送信することも可能である（タスク２５０６）。モード識別子は、選択された無線データ通信モードを指定し、または識別し、モード識別子は、選択されたモード（モード識別子によって指定される）をサポートするように自らを構成するよう、受信デバイスを促す。異なる２つのリンク信頼性モードだけしか利用可能でないこの実施例では、モード識別子は、単に、適切なフォーマットで伝送される１ビットフラグであってもよい。モード識別子は、データパケットの中でオーバヘッドとして伝送される、または少なくとも１つの初期ボンディングパケット（無線データ通信セッションの始めに送信されるパケット）の中で伝送されることが可能である。
無線医療デバイスが、選択されたリンク信頼性モードで動作していると、送信デバイスは、無線データパケットを生成して、受信デバイスに送信することができる（タスク２５０８）。送信デバイスが、送信済みのデータパケットのＡＣＫ（肯定応答）を受信した場合（クエリタスク２５１０）、タスク２５０８に再び入って、選択されたモードを使用して、さらなる無線データパケットの引き続きの伝送ができるようにされることが可能である。送信デバイスは、送信済みのデータパケットに関するＡＣＫメッセージを受信しない場合、信頼できるリンクモードが、現在、アクティブ状態であるかどうか確認することができる（クエリタスク２５１２）。デバイスが、信頼できるリンクモードで現在、動作している場合、無線データパケットが、逸せられている可能性があること、または無線リンクが信頼できなくなっていることをユーザに知らせる適切な警報が、生成される（タスク２５１４）。実際には、タスク２５１４は、肯定応答なしに指定された数のデータパケットが伝送されるまで、遅延されることが可能である。
信頼できないリンクモードが、現在、アクティブ状態であると、クエリタスク２５１２が判定した場合、デバイスは、無線データパケット肯定応答ステータスにかかわらず、ベストエフォートサービス品質を提供しつづける（タスク２５１６）。つまり、信頼できないリンクモードは、肯定応答のないパケットを許容し、デバイスは、肯定応答のないパケットに応答した特別な措置はまったく行わなくてもよい。実際、デバイスは、信頼できないリンクモードで動作している間、サービス品質警報の生成を防止する（タスク２５１８）ように適切に構成されることが可能である。この機能により、警報が、低い優先度のデータ項目に関して生成されないことが確実になる。
この実施例では、デバイスは、異なる無線データ通信モードの間で動的に切り替わることができ、そのような動的切り替えは、デバイス間の無線データ通信セッション中に行われてもよい。したがって、デバイスの一方または両方が、モードを切り替えることを決定した場合（クエリタスク２５２０）、リンク信頼性プロセス２５００は、タスク２５０４に再び入って、新たに選択されたモードにおける動作のために、送信デバイスを再構成することが可能である。現在のモードの切り替えが行われない場合、プロセス２５００は、タスク２５０８に再び入ることが可能である。
システム内の無線医療デバイスは、互いのある範囲内に入ると、信頼できないリンクモードから信頼できるリンクモードに自動的に切り替わるように構成されることが可能である。例えば、図３７は、無線医療デバイスネットワークにおいて使用するのに適した自動デバイス検出プロセス２６００を示す流れ図である。プロセス２６００は、デバイスが、信頼できないリンクモードにおける動作を既にサポートしているものと想定する（タスク２６０２）。デバイスの一方（または両方）が、デバイスが、信頼できるリンクモードに関する範囲内にあることを自動的に検出した場合（クエリタスク２６０４）、デバイスは、信頼できるリンクモードに切り替わることが可能である（タスク２６０６）。検出しなかった場合、デバイスは、引き続き信頼できないリンクモードで動作することができる。
信頼できないリンクモードから信頼できるリンクモードに切り替わると、自動デバイス検出プロセス２６００は、一方のデバイス、または両方のデバイスにおいて収集されていることが可能な、蓄積されたデータの転送を開始することができる（タスク２６０８）。このことにより、デバイスが信頼できないリンクモードで動作していた間に逸せられた可能性がある「補充」データで、デバイスが更新されることが可能になる。リンク信頼性選択プロセス２５００に関連して前述したとおり、無線医療デバイスは、信頼できるリンクモードと信頼できないリンクモードの間で動的に切り替わるように構成されることが可能である。したがって、現在のモードの切り替えが行われる場合（クエリタスク２６１０）、プロセス２６００は、タスク２６０２に再び入って、信頼できないリンクモードにおける動作をサポートすることが可能である。切り替えが行われない場合、プロセス２６００は、無線データ通信セッションが終わるまで、またはモードの切り替えが行われるまで、信頼できるリンクモードにおける動作を引き続きサポートすることが可能である（タスク２６１２）。
また、システム内の無線医療デバイスは、新たな互換性のあるデバイスの存在を、それらのデバイスが既存のデバイスのある範囲内にある場合に、自動的に検出するように構成されることも可能である。例えば、図３８は、無線医療デバイスネットワークにおいて使用するのに適した新規デバイス検出プロセス２７００を示す流れ図である。プロセス２７００は、第１のデバイスが、医療デバイスネットワーク内で既にアクティブ状態であるものと想定する。新たなデバイスが、信頼できるリンクモードに関する範囲内にあることを、第１のデバイスが自動的に検出した場合（クエリタスク２７０２）、プロセス２７００は、第１のデバイスと、その新たなデバイスとの間の無線データ通信セッションを確立し（タスク２７０４）、無線データ通信セッションは、この２つのデバイス間の無線データ転送のために信頼できるリンクモードを使用する。
新たなデバイスを検出し、新たなデバイスと接続した後、新規デバイス検出プロセス２７００は、この新たなデバイスにおいて格納されている可能性がある、蓄積されたデータの転送を開始する（タスク２７０６）。このことにより、この新たなデバイスに関する「補充(fill-in)」データで、第１のデバイスが更新されることが可能になる。リンク信頼性選択プロセスに関連して前述したとおり、無線医療デバイスは、信頼できるリンクモードと信頼できないリンクモードの間で動的に切り替わるように構成されることが可能である。したがって、現在のモードの切り替えが行われる場合（クエリタスク２７０８）、プロセス２７００は、無線データ通信セッションが終わるまで、またはモードの切り替えが再び行われるまで、信頼できないリンクモードにおける動作をサポートするようにデバイスを再構成することが可能である（タスク２７１０）。現在のモードの切り替えが行われない場合、プロセス２７００は、無線データ通信セッションが終わるまで、またはモードの切り替えが行われるまで、引き続き信頼できるリンクモードにおける動作をサポートすることができる（タスク２７１２）。
また、システム内の無線医療デバイスは、別のデバイスとの所与のデータ通信セッションに関して、同期無線データ通信モードと非同期無線データ通信モードの間で選択を行うように構成されることも可能である。非同期モードでは、無線データパケットは、任意の時刻に伝送されることが可能であり、同期モードでは、無線データパケットは、指定された同期スキームに従って送受信される。
図３９は、無線医療デバイスネットワークにおいて使用するのに適した同期プロトコル選択プロセス２８００を示す流れ図である。プロセス２８００は、同期データ通信プロトコルと非同期データ通信プロトコルをともにサポートするように構成された無線医療デバイスによって実行されることが可能である。プロセス２８００は、あるデバイスとの無線データ通信セッションに関して同期モードまたは非同期モードを選択することで始まることが可能である（タスク２８０２）。タスク２８０２は、医療デバイスシステムのユーザによって行われた選択に応じたものであってもよく、この選択は、現在の動作条件に応じて、送信する医療デバイスによって自動的に開始されることが可能であり、あるいはこの選択は、システム内の別のデバイスによって行われて、送信する医療デバイスに通信されることが可能である。例えば、特定の無線データ通信モードは、（１）デバイス間で転送されるべきデータに関連付けられた優先度、（２）デバイス間で転送されるべきデータに関連付けられたデータタイプカテゴリ、（３）所定のスケジュール、（４）送信出力基準、および／または（５）デバイス間の無線データ通信セッションに関するサービス品質測定値に応じて選択されることが可能である。これらの項目については、リンク信頼性選択プロセス２５００に関連して前述した。無線データ通信モードの選択は、これらの例に限定される必要はなく、医療デバイスシステムの実施形態は、タスク２８０２中に行われる選択を支配する異なる基準を利用してもよい。
同期モードが選択された後、送信デバイスは、選択されたモードにおける動作をサポートするように構成される（タスク２８０４）。これに関して、送信デバイスは、動的に選択可能なモードのいずれか（この実施例では、同期モードまたは非同期モード）をサポートするように構成される。また、同期プロトコル選択プロセス２８００は、受信デバイスによって処理されるようにモード識別子を含むパケットを作成することもできる（タスク２８０６）。モード識別子は、同期モードまたは非同期モードを指定し、または識別し、さらに、モード識別子は、選択されたモード（モード識別子によって指定された）をサポートするように自らを構成するよう、受信デバイスを促す。異なる２つの同期設定だけしか利用可能でないこの実施例では、モード識別子は、単に、適切なフォーマットで伝送される１ビットフラグであってもよい。送信デバイスが、モード識別子を有するパケットを、受信デバイスに送信する（タスク２８０８）。実際には、モード識別子は、データパケットの中でオーバヘッドとして伝送される、または少なくとも１つの初期ボンディングパケットの中で伝送されることが可能である。このパケットを受信すると、受信デバイスは、選択されたモードをサポートするように構成される（タスク２８１０）。
選択されたモードが、非同期モードである（クエリタスク２８１２の「いいえ」の分岐）場合、無線医療デバイスは、非同期無線データ転送をサポートする仕方で動作する（タスク２８１４）。そうではなく、選択されたモードが、同期モードである場合、デバイスは、デバイス間で転送されるデータに関する適切な送信／受信スケジュールをネゴシエートする、または選択することができる（タスク２８１６）。さらに、無線医療デバイスは、ネゴシエートされた送信／受信スケジュールに従って同期無線データ転送をサポートする仕方で動作する（タスク２８１８）。このスケジュールは、２つのデバイスに関する特定の送信タイムスロットおよび受信タイムスロットを指定して、各デバイスが、他方のデバイスにいつパケットを送信すべきか、および他方のデバイスからいつパケットを受信するものと予期すべきかを知る。
この実施例では、デバイスは、同期モードと非同期モードの間で動的に切り替わることが可能であり、そのような動的切り替えは、デバイス間の無線データ通信セッション中に行われることが可能である。したがって、デバイスの一方または両方が、モードを切り替えることを決定した場合（クエリタスク２８２０）、同期プロトコル選択プロセス２８００は、タスク２８０２（または、場合により、タスク２８１２）に再び入って、その新たなモードをサポートするようにデバイスを再構成することが可能である。モードを切り替えることを決定しなかった場合、クエリタスク２８２０に再び入って、プロセス２８００が、モード切り替え命令を引き続き監視することができるようになることが可能である。
また、システム内の無線医療デバイスは、別のデバイスとの所与の無線データ通信セッションに関する周波数割り当てスキームを選択するように構成されることも可能である。この機能により、医療デバイスネットワーク内のデバイスの複雑さに柔軟性が可能になる。ある実施形態は、任意の所与の無線データ通信リンクで使用されるように、異なる任意の数の周波数割り当てスキームをサポートし、スキームの１つを選択するように構成されることが可能である。１つの限定的でない例として、デバイスは、以下のオプション、すなわち、単一周波数／チャネルモード、５周波数／チャネルの低出力モード、および５０周波数／チャネルの高出力モードから選択を行うことができる。注入システムに関連して、生理学的センサ送信機と注入ポンプとの間の無線リンクは、５周波数／チャネルモードを利用して、バッテリ電力を節約することができるが、パケット損失またはパケット衝突がより多い時間中、デバイスは、５０周波数／チャネルモードに切り替わって、より高い送信出力を実現することができる。
図４０は、無線医療デバイスネットワークにおいて使用するのに適した動的周波数ホッピングプロセス２９００を示す流れ図である。プロセス２９００は、異なる複数の周波数割り当て（例えば、周波数ホッピング）スキームをサポートするように構成された無線医療デバイスによって実行されることが可能である。プロセス２９００に関連して、無線医療デバイスは、別のデバイスとの現在の無線データ通信セッションに関するサービス品質測定値を獲得することができる（タスク２９０２）。タスク２９０２は、タスク２９０２のオプションとしての性質を示すように破線内に示され、サービス品質測定値は、周波数割り当てスキームの選択を支配するのに利用されることが可能なオプションのパラメータを表す。
動的周波数ホッピングプロセス２９００は、サポートされる複数のモードから所望される無線データ通信モードを選択する（タスク２９０４）のに利用され、ただし、サポートされる各モードは、異なる周波数割り当てスキームに対応する。タスク２９０４は、医療デバイスシステムのユーザによって行われた選択に応じたものであってもよい。この選択は、現在の動作条件に応じて送信する医療デバイスによって自動的に開始されることが可能であり、あるいはこの選択は、システム内の別のデバイスによって行われて、送信する医療デバイスに通信されることが可能である。例えば、特定の周波数割り当てスキームは、（１）デバイス間で転送されるべきデータに関連付けられた優先度、（２）デバイス間で転送されるべきデータに関連付けられたデータタイプカテゴリ、（３）所定のスケジュール、（４）送信出力基準、および／または（５）デバイス間の無線データ通信セッションに関するサービス品質測定値に応答して選択されることが可能である。これらの項目については、リンク信頼性選択プロセス２５００に関連して前述した。周波数割り当てスキームの選択は、これらの例に限定される必要はなく、医療デバイスシステムの実施形態は、タスク２９０４中に行われる選択を支配する異なる基準を利用してもよい。
周波数割り当てスキームが選択された後、送信デバイスは、選択されたモードにおける動作をサポートするように構成（セットアップ）される（タスク２９０６）。これに関して、送信デバイスは、複数の周波数割り当てスキームのいずれか、つまり、この実施例では、単一周波数／チャネルモード、５周波数／チャネルモード、または５０周波数／チャネルモードを動的に選択可能な仕方でサポートすることができる。また、動的周波数ホッピングプロセス２９００は、受信デバイスによって処理されるようにモード識別子を含むパケットを作成することもできる（タスク２９０８）。モード識別子は、選択された動作モードを指定し、または識別し、さらに、モード識別子は、選択されたモード（モード識別子によって指定された）をサポートするように自らを構成するよう、受信デバイスを促す。異なる３つの周波数割り当てスキームが利用可能であるこの実施例では、モード識別子は、単に、適切なフォーマットで伝送される２ビットフラグであることが可能である。送信デバイスが、モード識別子を有するパケットを、受信デバイスに送信する（タスク２９１０）。実際には、モード識別子は、データパケットの中でオーバヘッドとして伝送される、または少なくとも１つの初期ボンディングパケットの中で伝送されることが可能である。このパケットを受信すると、受信デバイスは、選択されたモードをサポートするように構成（セットアップ）される（タスク２９１２）。
最終的に、両方のデバイスが、選択された無線データ通信モードに従って、さらに指定された周波数割り当てスキームに従って無線データ転送をサポートするようにセットアップされる（タスク２９１４）。この実施例では、異なるモードの間で動的に切り替わることが可能であり、そのような動的切り替えは、デバイス間の無線データ通信セッション中に行われることが可能である。したがって、デバイスの一方または両方が、モードを切り替えることを決定した場合（クエリタスク２９１６）、動的周波数ホッピングプロセス２９００は、タスク２９０４（または、場合により、タスク２９１４）に再び入って、その新たなモードをサポートするようにデバイスを再構成することが可能である。モードを切り替えることを決定しない場合、クエリタスク２９１６に再び入って、プロセス２９００が、引き続きモード切り替え命令を監視することができるようになることが可能である。
実際には、同期無線リンクは、指定された伝送周期性（例えば、パケット当たり６０秒）で動作する。送信デバイスは、パケットを、そのパケットが逸せられた、または肯定応答のなかった場合、再送する（再試行する）ことができる。さらに、２つのデバイスは、再試行（リトライ）パケットが、指定された再試行周期性（例えば、再試行パケット当たり２０秒）で送信される、ある特定の再試行同期スキームに従うことが可能である。これに関して、本明細書で説明される無線医療デバイスは、同期リンクのためにデバイスのパケット再送（再試行）設定を調整するように構成されることも可能である。例えば、デバイスは、現在の動作条件、および／または転送されるべきデータの特性に基づいて、ある特定の再試行周期性を選択することができる。この選択は、データ伝送信頼性、電力節約、利用可能な帯域幅などの様々な基準によって制御されることが可能である。さらに、両方のデバイスが、再試行パケットに関して、ネゴシエートされた仕方（例えば、動的周波数ホッピングプロセス２９００に関連して前述した）で、デバイスの周波数ホッピングスキームを適合させ、その無線リンクに関して通常のサービス品質が再開されると、ベースライン周波数ホッピングスキームに戻ることが可能である。
図４１は、無線医療デバイスネットワークにおいて使用するのに適した再試行周期性選択プロセス３０００を示す流れ図である。プロセス３０００は、異なる複数の再試行周期性設定をサポートするように構成された無線医療デバイスによって実行されることが可能である。プロセス３０００は、無線データパケットが第１のタイミングスキームに従って交換される同期無線データ通信モードで動作することから始まる（タスク３００２）。この実施例に関して、第１のタイミングスキームは、通常の動作条件、およびデバイスによって利用される無線リンクに関する少なくとも公称サービス品質に関連する通常のパケット伝送周期性を表す。このため、第１のタイミングスキームは、デバイスに関する第１の送信／受信周期に対応する。この通常の動作モードは、肯定応答のないデータパケットが生じるまで維持される（クエリタスク３００４）。これに関して、送信デバイスは、肯定応答のないデータパケットを示すＮＡＫメッセージを受信することが可能であり、送信デバイスは、受信デバイスから再試行要求を受信することが可能であり、あるいは送信デバイスは、ある期間内に何らかのタイプの応答メッセージを受信しない場合、送信されたデータパケットが受信されなかったものと見なすことが可能である。
データパケットが、肯定応答のないままである場合（クエリタスク３００４）、再試行周期性選択プロセス３０００は、複数のサポートされる設定から所望される再試行周期性設定を選択し（タスク３００６）、ここで、サポートされる各設定は、第１の（通常の）伝送タイミングスキームとは異なるそれぞれの再試行タイミングスキームに対応する。実際的な実施形態では、各再試行周期性設定は、通常の条件下でパケット伝送のために利用される第１の送信／受信周期性より短い、異なる送信／受信周期に対応する。タスク３００６は、医療デバイスシステムのユーザによって行われた選択に応じたものであってもよい。この選択は、現在の動作条件に応じて送信する医療デバイスによって自動的に開始されることが可能であり、あるいはこの選択は、システム内の別のデバイスによって行われて、送信する医療デバイスに通信されることが可能である。例えば、特定の再試行周期性設定は、（１）デバイス間で転送されるべきデータに関連付けられた優先度、（２）デバイス間で転送されるべきデータに関連付けられたデータタイプカテゴリ、（３）所定のスケジュール、（４）送信出力基準、および／または（５）デバイス間の無線データ通信セッションに関するサービス品質測定値に応じて選択されることが可能である。これらの項目については、リンク信頼性選択プロセス２５００に関連して前述した。代替として、再試行周期性設定は、データパケットに関して実行される再試行の試みの回数に応答して選択されてもよい。例えば、再試行周期の長さは、失敗したパケット伝送の試みの回数に比例して短くなってもよく、これにより、伝送に肯定応答があるまで、または送信機がもはや、再試行の試みを行わないことを決定するまで、再試行パケット伝送の頻度が増大する。再試行周期性設定の選択は、これらの例に限定される必要はなく、医療デバイスシステムの実施形態は、タスク３００６中に行われる選択を支配する異なる基準を利用してもよい。
デバイスが、同期無線データ通信プロトコルを使用して通信しているものと想定すると、選択された再試行タイミングスキームに適合する適切な周波数ホッピングスキームを選択する（サポートされる複数の周波数ホッピングスキームから）ことが必要である場合もある（タスク３００８）。例えば、動的周波数ホッピングプロセス２９００、またはプロセス２９００の適切な変種が、タスク３００８に関連して利用されることが可能である。適切な周波数割り当てスキームの選択により、デバイスが、指定された再試行周期性設定を使用して、ネットワーク通信をサポートすることが可能になる。
再試行周期性設定および周波数ホッピングスキームが選択された後、送信デバイスは、選択されたモードにおける動作をサポートするように構成（セットアップ）される（タスク３０１０）。これに関して、送信デバイスは、複数の再試行タイミングスキームのいずれも、動的に選択可能な仕方でサポートすることができる。また、再試行周期性選択プロセス３０００は、受信デバイスによって処理されるようにモード識別子を含むパケットを作成することもできる（タスク３０１２）。モード識別子は、選択された再試行周期性設定を指定し、または識別し、さらに、モード識別子は、選択されたモード（モード識別子によって指定された）をサポートするように自らを構成するよう、受信デバイスを促す。送信デバイスが、モード識別子を有するパケットを、受信デバイスに送信する（タスク３０１４）。実際には、モード識別子は、データパケットの中でオーバヘッドとして伝送されるか、またはペイロードをまったく有さない動的リンクパラメータを伝送するパケットの中で伝送されることが可能である。このパケットを受信すると、受信デバイスは、選択されたモードをサポートするように構成（セットアップ）される（タスク３０１６）。
最終的に、両方のデバイスが、指定された再試行タイミングスキームをサポートするようにセットアップされる。したがって、送信デバイスは、指定された再試行周期性設定を使用して、少なくとも１つの無線データパケットを再送することができる（タスク３０１８）。この実施例では、一方のデバイス、または両方のデバイスが、サービス品質閾値を満たす動作条件を検出した場合（クエリタスク３０２０）、再試行周期性選択プロセス３０００は、タスク３００２に再び入って、通常のタイミングスキームおよびベースライン再試行タイミングスキームが、後に伝送されるデータパケットのために再び利用されるようになってもよい。つまり、システムは、第１のタイミングスキームに戻るように切り替わり、さらに、システムの通常の再試行周期性設定に戻るように切り替わる。閾値サービス品質が満たされない場合（クエリタスク３０２０）、プロセス３０００は、終了する、またはそれ以外で、適切な仕方で進むことが可能である。例えば、クエリタスク３００４に再び入って、再試行タイミングスキームの動的な調整ができるようにされることが可能である。代替として、現在の再試行タイミングスキームが、ある期間にわたって、あるいは指定された量だけサービス品質が向上する、または低下するまで、維持されてもよい。
また、本明細書で説明される無線医療デバイスは、例えば、特定の生理学的データ（例えば、上昇傾向または下降傾向）、警報に応答しないこと、生理学的パラメータの変化を認識しないことなどの、様々な基準に基づいて、変化する、伝送の合間の期間をもたらすように構成されることも可能である。伝送されるパケットは、所望の期間（この期間のあと、次のデータパケットが送信される）を受信デバイスに通知するためのフィールド、を提供することが可能である。このことは、両方のデバイスが、共通のクロックを使用して同期されるものと想定すると、時間差または指定された時間を使用して実施されることが可能である。代替として、共通のクロックを使用する時間同期は、タイムスタンプがデータと一緒に送信される場合、必要ない可能性がある。その場合、時間の分解能（例えば、マイクロ秒単位）が、次のデータパケットをいつ予期すべきかを知るために、同一である必要がある。
例えば、図４２は、無線医療デバイスネットワークにおいて使用するのに適した送信タイミング選択プロセス３１００を示す流れ図である。プロセス３１００は、無線医療デバイスが、同期的にデータを交換するものと想定する。プロセス３１００は、可変の送信／受信タイミングスキームをサポートするように構成された無線医療デバイスによって実行されることが可能である。プロセス３１００に関連して、送信デバイスが、次の無線データパケットが、受信デバイスにいつ送信されるかを動的に決定する（タスク３１０２）。次に、送信デバイスは、次のデータパケットが、無線データ通信チャネルを介していつ送信されるかを示す可変時間インジケータ（標識）を生成する、または選択することができる。一部の実施形態では、可変時間インジケータは、次のパケットに関するある特定の送信時刻を示す。別の実施形態では、可変時間インジケータは、ある特定の期間を示し、ただし、次のデータパケットは、その指定された期間の後に送信される。
可変時間インジケータの選択は、医療デバイスシステムのユーザによって行われた選択に応じたものであってもよく、この選択は、現在の動作条件に応答して送信する医療デバイスによって自動的に開始されることが可能であり、あるいはこの選択は、システム内の別のデバイスによって行われて、送信する医療デバイスに通信されることが可能である。例えば、特定の可変時間インジケータは、（１）デバイス間で転送されるべきデータに関連付けられた優先度、（２）デバイス間で転送されるべきデータに関連付けられたデータタイプカテゴリ、（３）所定のスケジュール、（４）送信出力基準、および／または（５）デバイス間の無線データ通信セッションに関するサービス品質測定値に応答して選択されることが可能である。これらの項目については、リンク信頼性選択プロセス２５００に関連して前述した。代替として、可変時間インジケータは、デバイス間で転送されるデータの傾向特性に応答して選択されてもよい。例えば、傾向特性が、デバイス間で転送されるデータの比較的高い変化率を表す場合、可変の時間インジケータは、次のデータパケットがいつ伝送されるかに対応する、比較的短い期間を示すことが可能である。他方、傾向特性が、デバイス間で転送されるデータの比較的低い変化率を表す場合、可変時間インジケータは、次のデータパケットがいつ伝送されるかに対応する、比較的長い期間を示すことが可能である。もちろん、可変時間インジケータの選択は、これらの例に限定される必要はなく、医療デバイスシステムの実施形態は、可変時間インジケータの選択を支配する異なる基準を利用してもよい。このスキームの１つの実際的な利点は、ＲＦ「オン」時間を短縮することによって電力消費を低減することである。また、他の実際的な利点が、このスキームから引き出されることも可能である。
可変時間インジケータが選択された後、送信デバイスは、可変時間インジケータによって指定されるとおり、指定された送信時刻に、または指定された期間の後に、次のデータパケットを送信するように自らを構成する（タスク３１０４）。また、送信タイミング選択プロセス３１００は、受信デバイスによって処理されるように可変時間インジケータを含むパケットを作成し（タスク３１０６）、そのパケットを、受信デバイスに送信することもできる（タスク３１０８）。実際には、可変時間インジケータは、データパケットの中でオーバヘッドとして伝送されること、または少なくとも１つの初期ボンディングパケットの中で伝送されること、またはペイロードをまったく有さない動的リンクパラメータを伝送するパケットの中で伝送されることが可能である。可変時間インジケータは、可変時間インジケータによって指定されるとおり次のデータパケットを受信するように自らを構成するよう、受信デバイスを促す。したがって、このパケットを受信すると、受信デバイスは、可変時間インジケータに応じて構成（セットアップ）される（タスク３１１０）。
送信デバイスは、後続のパケットに関する送信時間を動的な仕方で調整することができる。したがって、図４２は、タスク３１０２に戻るようにつながるタスク３１１０を示す。特に、タイミングは、伝送される各パケットに関して調整されなくてもよく、送信タイミング選択プロセス３１００は、現在のタイミングスキームを変更するまでに、任意の数のパケット伝送にわたって、選択された送信タイミングスキームを保つことができる。
代替の実施形態では、受信デバイス（第２のデバイス）は、第１のデバイスからデータパケットを受信し、データ分析を実行し、この分析に応答して、次のデータパケット伝送のためのある期間、またはある特定の時刻を決定する。その後、受信デバイスは、ＡＣＫメッセージを生成して、次の伝送に対応する選択された期間、または特定の時刻とともに送信デバイス（第１のデバイス）に返送する。実際には、次の伝送のための選択された期間、または特定の時刻は、ＡＣＫメッセージ自体の中で、または別個のデータパケットの中で伝送されることが可能である。
図２３を再び参照すると、前述した動的リンクパラメータの１つまたは複数が、適切にフォーマットされたデータパケット１７００の中に配置されたデータフィールドを有する無線データ通信信号を介して、伝送されることが可能である。この場合、動的リンクパラメータは、無線医療デバイス間で使用される無線データ通信プロトコル／リンクの調整をもたらす様々なモード識別子および変数のいずれかである。
データパケット１７００は、例えば、２つのデバイス間で無線データ通信セッションを開始するのに使用される初期ボンディングパケットであることが可能である。前述したとおり、データパケット１７００は、以下の動的リンクパラメータ、すなわち、リンク信頼性設定１７０２、同期設定１７０４、周波数割り当て設定１７０６、再試行周期性設定１７０８、マスタ／スレーブ設定１７１０、および／または送信タイミングインジケータ１７１２の１つ以上に対応するデータまたはデータフィールドを含むことが可能である。特定のシステムアプリケーションに依存して、これらのリンクパラメータの１つ以上が、無線データ通信セッション中に動的に更新されることが可能である。データパケット１７００の中に含まれるデータは、サポートされる複数の無線データ通信モードの選択された１つを表し、ただし、各モードは、デバイス間の無線データ通信チャネルに関する異なる無線リンク特性セット、または異なるＲＦリンク特性セットに対応する。
本明細書で説明される実施例に関して、図２３に示されるデータフィールドは、前述した様々なパラメータおよびインジケータに対応する。このため、リンク信頼性設定１７０２は、リンク信頼性選択プロセス２５００（図３６参照）に関連してより詳細に前述したとおり、信頼できるリンクモード、または信頼できないリンクモードを指定する。さらに、同期設定１７０４は、同期プロトコル選択プロセス２８００（図３９参照）に関連してより詳細に前述したとおり、同期無線データ通信モードまたは非同期無線データ通信モードを指定する。本明細書で説明される実施例に関して、周波数割り当て設定１７０６は、動的周波数ホッピングプロセス２９００（図４０参照）に関連してより詳細に説明されるとおり、複数のサポートされる周波数ホッピングスキームの１つを指定する。さらに、再試行周期性設定１７０８は、再試行周期性選択プロセス３０００（図４１参照）に関連してより詳細に前述したとおり、複数のサポートされる再試行タイミングスキームの１つを指定する。本明細書で説明される実施例に関して、マスタ／スレーブ設定１７１０は、マスタ／スレーブ通信プロセス２１００（図２９および図３０参照）に関連してより詳細に前述したとおり、データパケット１７００の発信元であるデバイスに関するマスタデバイスステータスまたはスレーブデバイスステータスを指定する。さらに、送信タイミングインジケータ１７１２は、送信タイミング選択プロセス３１００（図４２参照）に関連してより詳細に前述したとおり、次のパケットがいつ送信されるかを指定する。
少なくとも１つの例示的な実施形態が、以上の詳細な説明において提示されてきたが、膨大な数の変種が存在することを理解されたい。また、本明細書で説明される例示的な実施形態および諸実施形態は、本発明の範囲、適用可能性、または構成を限定することをまったく意図していないことも理解されたい。むしろ、以上の詳細な説明は、説明される実施形態または諸実施形態を実施するための便利なロードマップを当業者に提供する。本発明の範囲を逸脱することなく、要素の機能および構成の様々な変更が行われることが可能であり、ただし、本特許出願を出願した時点における、知られている等価物の範囲、および予見できる等価物の範囲を含む本発明の範囲は、特許請求の範囲によって規定されることを理解されたい。
本発明の例示的な実施形態に従って構成されたネットワークベースの注入システムを示す概略図である。 本発明の例示的な実施形態に従って構成された臨床注入システムモニタを示す正面図である。 本発明の例示的な実施形態に従って構成された病院注入システムモニタを示す正面図である。 本発明の例示的な実施形態に従って構成されたハンドヘルド注入システムモニタ／コントローラを示す正面図である。 本発明の例示的な実施形態に従って構成されたハンドヘルド注入システムモニタ／コントローラを示す正面図である。 本発明の例示的な実施形態に従って構成された注入システムモニタを示す概略図である。 図５に示される注入システムモニタで使用するのに適したネットワークインターフェースを示す概略図である。 図５に示される注入システムモニタで使用するのに適したネットワーク通信モジュールを示す概略図である。 本発明の例示的な実施形態に従って構成されたネットワークベースの注入システムを示す概略図である。 例示的なネットワークベースの注入システム監視プロセスを表す流れ図である。 例示的なネットワークベースの注入システム通信プロセスを表す流れ図である。 例示的なネットワークベースの注入ポンプ監視／制御プロセスを表す流れ図である。 本発明の例示的な実施形態に従って構成されたモニタデバイス、コントローラデバイス、ネットワークデバイス、ディスプレイデバイス、および／または他の注入システムデバイスによって生成されることが可能なスクリーンショットである。 本発明の例示的な実施形態に従って構成されたモニタデバイス、コントローラデバイス、ネットワークデバイス、ディスプレイデバイス、および／または他の注入システムデバイスによって生成されることが可能なスクリーンショットである。 本発明の例示的な実施形態に従って構成されたモニタデバイス、コントローラデバイス、ネットワークデバイス、ディスプレイデバイス、および／または他の注入システムデバイスによって生成されることが可能なスクリーンショットである。 本発明の例示的な実施形態に従って構成されたモニタデバイス、コントローラデバイス、ネットワークデバイス、ディスプレイデバイス、および／または他の注入システムデバイスによって生成されることが可能なスクリーンショットである。 本発明の例示的な実施形態に従って構成されたモニタデバイス、コントローラデバイス、ネットワークデバイス、ディスプレイデバイス、および／または他の注入システムデバイスによって生成されることが可能なスクリーンショットである。 本発明の例示的な実施形態に従って構成されたモニタデバイス、コントローラデバイス、ネットワークデバイス、ディスプレイデバイス、および／または他の注入システムデバイスによって生成されることが可能なスクリーンショットである。 本発明の例示的な実施形態に従って構成されたデータ通信変換デバイスを示す斜視図である。 本発明の例示的な実施形態に従って構成されたデータ通信変換デバイスを示す概略図である。 例示的なデータ格納および変換プロセスを表す流れ図である。 例示的なデータ格納および変換プロセスを表す流れ図である。 例示的なデータ格納および変換プロセスを表す流れ図である。 本発明の例示的な実施形態に従って構成された無線遠隔測定ルータの例示的なネットワーク配置を示す概略図である。 無線データ通信能力と、無線ネットワーキング能力とを有する医療デバイスの概略を示す一般化された図である。 サポートされる無線データ通信モードに対応する様々な動的リンクパラメータを表すデータフィールドを含むデータパケットの一部分を示す図である。 例示的なキー生成プロセスを示す流れ図である。 無線医療デバイスネットワークにおいて使用するのに適した同期無線通信プロセスを示す流れ図である。 図２５に示されるプロセスによるデータパケット交換を表す図である。 無線医療デバイスネットワークにおいて使用するのに適した非同期無線通信プロセスを示す流れ図である。 図２７に示されるプロセスによるデータパケット交換を表す図である。 無線医療デバイスネットワークにおいて使用するのに適した同期マスタ／スレーブ無線通信プロセスを示す流れ図である。 図２９に示されるプロセスによるデータパケット交換を表す図である。 医療デバイスネットワーク内の無線医療デバイスの２つのサブネットワークを表す図である。 無線医療デバイスネットワークにおいて使用するのに適したブロードキャスト伝送プロセスを示す流れ図である。 図３２に示されるプロセスによるデータパケット交換を表す図である。 無線医療デバイスネットワークにおいて使用するのに適した無線中継プロセスを示す流れ図である。 図３４に示されるプロセスによるデータパケット交換を表す図である。 無線告知／中継プロセスおよび無線告知／中継システムを表す図である。 無線医療デバイスネットワークにおいて使用するのに適したリンク信頼性選択プロセスを示す流れ図である。 無線医療デバイスネットワークにおいて使用するのに適した自動デバイス検出プロセスを示す流れ図である。 無線医療デバイスネットワークにおいて使用するのに適した新規デバイス検出プロセスを示す流れ図である。 無線医療デバイスネットワークにおいて使用するのに適した同期プロトコル選択プロセスを示す流れ図である。 無線医療デバイスネットワークにおいて使用するのに適した動的周波数ホッピングプロセスを示す流れ図である。 無線医療デバイスネットワークにおいて使用するのに適した再試行周期性選択プロセスを示す流れ図である。 無線医療デバイスネットワークにおいて使用するのに適した送信タイミング選択プロセスを示す流れ図である。

Claims (129)

  1. 医療デバイスネットワーク内のデバイスを構成するための方法（１８００）であって、
    前記医療デバイスネットワーク内の前記デバイスの配置の特性に関連する少なくとも１つのベース識別子を獲得すること（１８０２、１８０４、１８０６、１８０８）、
    前記少なくとも１つのベース識別子から、前記医療デバイスネットワーク内の前記デバイスを一意に識別する、前記デバイスに関するキーを生成すること（１８１０）、および
    前記デバイスにおいて前記キーの格納を行うこと（１８１２）を含むことを特徴とする方法（１８００）。
  2. 請求項１に記載の方法（１８００）であって、
    前記少なくとも１つのベース識別子は、前記デバイスに関する通し番号を含むことを特徴とする方法（１８００）。
  3. 請求項１に記載の方法（１８００）であって、
    前記少なくとも１つのベース識別子は、前記デバイスに関するデバイスタイプ識別子を含むことを特徴とする方法（１８００）。
  4. 請求項１に記載の方法（１８００）であって、
    前記少なくとも１つのベース識別子は、前記デバイスのユーザに関するユーザ識別子を含むことを特徴とする方法（１８００）。
  5. 請求項４に記載の方法（１８００）であって、
    前記ユーザ識別子は、前記デバイスの患者ユーザを前記デバイスの介護者ユーザと区別することを特徴とする方法（１８００）。
  6. 請求項１に記載の方法（１８００）であって、
    前記少なくとも１つのベース識別子は、前記デバイスに関するサブネットワーク識別子を含み、前記サブネットワーク識別子は、前記医療デバイスネットワーク内のデバイスのサブセットに共通であることを特徴とする方法（１８００）。
  7. 請求項１に記載の方法（１８００）であって、
    前記生成するステップ（１８１０）は、
    前記デバイスに関する通し番号、
    前記デバイスに関するデバイスタイプ、
    前記デバイスのユーザに関する、前記デバイスの患者ユーザを前記デバイスの非患者ユーザと区別するユーザ識別子、および
    前記デバイスに関する、前記医療デバイスネットワーク内のデバイスのサブセットに共通であるサブネットワーク識別子、
    の中の２つ以上から前記キーを導き出すことを特徴とする方法（１８００）。
  8. 請求項７に記載の方法（１８００）であって、
    前記通し番号、前記デバイスタイプ識別子、前記ユーザ識別子、および前記サブネットワーク識別子の中の前記２つ以上を、前記デバイスのユーザインターフェースを介して獲得することをさらに含むことを特徴とする方法（１８００）。
  9. 請求項１に記載の方法（１８００）であって、
    前記デバイスが、前記獲得するステップ（１８０２、１８０４、１８０６、１８０８）、前記生成するステップ（１８１０）、および前記格納を行うステップ（１８１２）を実行することを特徴とする方法（１８００）。
  10. 請求項９に記載の方法（１８００）であって、
    前記獲得するステップ（１８０２、１８０４、１８０６、１８０８）は、前記デバイスにより、前記医療デバイスネットワーク内の別のデバイスから前記少なくとも１つのベース識別子を受信するステップ、を含むことを特徴とする方法（１８００）。
  11. プログラミングデバイスが、前記獲得するステップ（１８０２、１８０４、１８０６、１８０８）、前記生成するステップ（１８１０）、および前記格納を行うステップ（１８１２）を実行する請求項１に記載の方法（１８００）であって、
    前記プログラミングデバイスから前記デバイスに前記キーを送信するステップ（１８１４）をさらに含むことを特徴とする方法（１８００）。
  12. 請求項１に記載の方法（１８００）であって、前記医療デバイスネットワーク内の別のデバイスに前記キーを送信するステップ（１８１８）をさらに含むことを特徴とする方法（１８００）。
  13. 同期データ通信プロトコルを使用して互いに通信するように構成された第１のデバイスと第２のデバイスとを有する医療デバイスネットワークのための通信方法（１９００）であって、
    前記第１のデバイスにおいて、前記医療デバイスネットワーク内の前記第１のデバイスを一意に識別する第１のキーと、前記医療デバイスネットワーク内の前記第２のデバイスを一意に識別する第２のキーとを保持するステップ（１９０２）、
    前記第２のデバイスにおいて、前記第１のキーおよび前記第２のキーを保持するステップ（１９０４）、
    前記第１のデバイスが、前記第１のキーと一緒にある量のデータを伝送するでーたぱけっとであって前記第２のデバイスを宛先とするデータパケット、を送信するステップ（１９０６）、および
    前記第２のデバイスが、前記第２のキーを伝送する応答パケットであって前記第１のデバイスを宛先とする応答パケットを送信するステップ（１９１６）、
    を含むことを特徴とする通信方法（１９００）。
  14. 請求項１３に記載の方法（１９００）であって、
    前記応答パケットは、前記データパケットの肯定応答を伝送することを特徴とする方法（１９００）。
  15. 請求項１３に記載の方法（１９００）であって、
    前記応答パケットは、前記データパケットの否定応答を伝送することを特徴とする方法（１９００）。
  16. 請求項１３に記載の方法（１９００）であって、
    前記第２のデバイスが、前記データパケットを受信するステップ（１９０８）、
    前記第２のデバイスが、前記データパケットから前記第１のキーを抽出するステップ（１９１０）、および
    前記第２のデバイスが、前記第１のキーを分析して、前記データパケットが前記第２のデバイスを宛先としているかどうかを判定するステップ（１９１２）、
    をさらに含むことを特徴とする方法（１９００）。
  17. 請求項１３に記載の方法（１９００）であって、
    前記第２のデバイスにおいて、前記医療デバイスネットワーク内の第３のデバイスを一意に識別する第３のキーを保持するステップ（１９０４）、
    前記第２のデバイスが、前記第３のキーを無効なキーと指定するステップ、および
    前記第２のデバイスが、前記第３のキーを伝送する受信されたデータパケットを無視するステップ（１９１８）、
    をさらに含むことを特徴とする方法（１９００）。
  18. 請求項１３に記載の方法（１９００）であって、
    前記第２のデバイスが、前記データパケットを受信するステップ（１９０８）、
    前記第２のデバイスが、前記量のデータを抽出するステップ（１９１０）、および
    前記第２のデバイスが、前記量のデータを分析して、前記データパケットが前記第２のデバイスを宛先としていたかどうかを判定するステップ（１９１２）、
    をさらに含むことを特徴とする方法（１９００）。
  19. 請求項１３に記載の方法（１９００）であって、
    前記第２のデバイスが、前記データパケットを受信するステップ（１９０８）、および
    前記第２のデバイスが、前記データパケットのタイミング特性に基づいて、前記データパケットが前記第２のデバイスを宛先としていたかどうかを判定するステップ（１９０９）、
    をさらに含むことを特徴とする方法（１９００）。
  20. 医療デバイスネットワーク内の第１のデバイス（１９５４）を一意に識別する第１のキー、および前記医療デバイスネットワーク内の第２のデバイス（１９５０）を一意に識別する第２のキーを格納するように構成されたメモリを有する該第１のデバイス（１９５４）と、
    同期データ通信プロトコルを使用して前記第１のデバイス（１９５４）とデータを通信するように構成され、前記第１のキー、および前記第２のキーを格納するように構成されたメモリを有する第２のデバイス（１９５０）と、
    を含む医療デバイスネットワークであって、
    前記第１のデバイス（１９５４）は、前記第２のデバイス（１９５０）を宛先とする、前記第１のキーと一緒にある量のデータを伝送するデータパケットを送信するように構成され、前記第２のデバイス（１９５０）は、前記第１のデバイス（１９５４）を宛先とする、前記第２のキーを伝送する応答パケットを送信するように構成されることを特徴とする医療デバイスネットワーク。
  21. 請求項２０に記載の医療デバイスネットワークであって、
    前記第１のキー、前記第２のキー、および医療デバイスネットワーク内の第３のデバイスを一意で識別する第３のキーを格納するように構成されたメモリを有する第３のデバイスをさらに含み、前記第２のデバイス（１９５０）の前記メモリは、前記第３のキーを格納するように構成され、前記第２のデバイス（１９５０）は、前記第３のキーを無効なキーと指定し、前記第２のデバイス（１９５０）は、前記第３のキーを伝送する受信されたデータパケットを無視することを特徴とする医療デバイスネットワーク。
  22. 非同期データ通信プロトコルを使用して互いの間でデータを通信するように構成された第１のデバイスと第２のデバイスとを有する医療デバイスネットワークのための通信方法（２０００）であって、
    前記第１のデバイスにおいて、前記医療デバイスネットワーク内の前記第１のデバイスを一意で識別する第１のキーと、前記医療デバイスネットワーク内の前記第２のデバイスを一意で識別する第２のキーとを保持するステップ（２００２）、
    前記第２のデバイスにおいて、前記第１のキーおよび前記第２のキーを保持するステップ（２００４）、
    前記第１のデバイスが、前記第２のデバイスを宛先とする、前記第１のキーおよび前記第２のキーと一緒にある量のデータを伝送するデータパケットを送信するステップ（２００６）、および
    前記第２のデバイスが、前記第１のデバイスを宛先とする、前記第１のキーおよび前記第２のキーを伝送する応答パケットを送信するステップ（２０１６）、
    を含むことを特徴とする通信方法（２０００）。
  23. 請求項２２に記載の方法（２０００）であって、
    前記応答パケットは、前記データパケットの肯定応答を伝送することを特徴とする方法（２０００）。
  24. 請求項２２に記載の方法（２０００）であって、
    前記応答パケットは、前記データパケットの否定応答を伝送することを特徴とする方法（２０００）。
  25. 請求項２２に記載の方法（２０００）であって、
    前記第２のデバイスが、前記データパケットを受信するステップ（２００８）、
    前記第２のデバイスが、前記データパケットから前記第１のキーを抽出するステップ（２０１０）、および
    前記第２のデバイスが、前記第１のキーを分析して前記第１のデバイスを識別するステップ（２０１２）、
    をさらに含むことを特徴とする方法（２０００）。
  26. 請求項２２に記載の方法（２０００）であって、
    前記第２のデバイスが、前記データパケットを受信するステップ（２００８）、
    前記第２のデバイスが、前記量のデータを抽出するステップ（２０１０）、および
    前記第２のデバイスが、前記量のデータを分析して、前記データパケットが前記第２のデバイスを宛先としていたかどうかを判定するステップ（２０１４）、
    をさらに含むことを特徴とする方法（２０００）。
  27. 同期データ通信プロトコルを使用して互いの間でデータを通信するように構成されたマスタデバイスとスレーブデバイスとを有する医療デバイスネットワークのための通信方法（２１００）であって、
    前記マスタデバイスにおいて、前記医療デバイスネットワーク内の前記マスタデバイスを一意で識別する第１のキーと、前記医療デバイスネットワーク内の前記スレーブデバイスを一意で識別する第２のキーと、前記医療デバイスネットワーク内の他のすべてのスレーブデバイスをそれぞれ識別するさらなるキー群とを保持するステップ（２１０２）、
    前記スレーブデバイスにおいて、前記第１のキーおよび前記第２のキーを保持するステップ（２１０４）、
    前記スレーブデバイスが、前記マスタデバイスを宛先とする、前記第１のキーと一緒にある量のデータを伝送するデータパケットを送信するステップ（２１０６）、および
    前記マスタデバイスが、前記スレーブデバイスを宛先とする応答パケットを送信するステップ（２１１４）、
    を含むことを特徴とする通信方法（２１００）。
  28. 請求項２７に記載の方法（２１００）であって、
    前記応答パケットは、前記第２のキーを伝送することを特徴とする方法（２１００）。
  29. 請求項２７に記載の方法（２１００）であって、
    前記応答パケットは、前記データパケットの肯定応答を伝送することを特徴とする方法（２１００）。
  30. 請求項２７に記載の方法（２１００）であって、
    前記応答パケットは、前記データパケットの否定応答を伝送することを特徴とする方法（２１００）。
  31. 請求項２７に記載の方法（２１００）であって、
    前記マスタデバイスが、前記データパケットを受信するステップ（２１０８）、
    前記マスタデバイスが、前記データパケットから前記第１のキーを抽出するステップ（２１１０）、および
    前記マスタデバイスが、前記第１のキーを分析して、前記データパケットが前記マスタデバイスを宛先としていたかどうかを判定するステップ（２１１２）、
    をさらに含むことを特徴とする方法（２１００）。
  32. 請求項２７に記載の方法（２１００）であって、
    前記マスタデバイスが、前記データパケットを受信するステップ（２１０８）、
    前記マスタデバイスが、前記ある量のデータを抽出するステップ（２１１０）、および
    前記マスタデバイスが、前記ある量のデータを分析して、前記データパケットが前記マスタデバイスを宛先としていたかどうかを判定するステップ（２１１２）、
    をさらに含むことを特徴とする方法（２１００）。
  33. マスタデバイス（２１５０）を一意に識別する第１のキー、および医療デバイスネットワーク内のすべてのスレーブデバイス（２１５２、２１５４）をそれぞれ識別するさらなるキー群を格納するように構成されたメモリを有する該マスタデバイス（２１５０）と、
    同期データ通信プロトコルを使用して前記マスタデバイス（２１５０）とデータを通信するように構成され、前記第１のキーと、前記医療デバイスネットワーク内のスレーブデバイス（２１５２、２１５４）を一意に識別する第２のキーを格納するように構成されたメモリを有する該スレーブデバイス（２１５２、２１５４）とを含む医療デバイスネットワークであって、
    前記スレーブデバイス（２１５２、２１５４）は、前記マスタデバイス（２１５０）を宛先とする、前記第１のキーと一緒にある量のデータを伝送するデータパケットを送信するように構成され、前記マスタデバイス（２１５０）は、前記スレーブデバイス（２１５２、２１５４）を宛先とする応答パケットを送信するように構成されることを特徴とする医療デバイスネットワーク。
  34. 請求項３３に記載の医療デバイスネットワークであって、
    前記応答パケットは、前記第２のキーを伝送することを特徴とする医療デバイスネットワーク。
  35. 請求項３３に記載の医療デバイスネットワークであって、
    前記応答パケットは、前記データパケットの肯定応答を伝送することを特徴とする医療デバイスネットワーク。
  36. 請求項３３に記載の医療デバイスネットワークであって、
    前記応答パケットは、前記データパケットの否定応答を伝送することを特徴とする医療デバイスネットワーク。
  37. 請求項３３に記載の医療デバイスネットワークであって、
    前記マスタデバイス（２１５０）は、
    前記データパケットを受信し、
    前記ある量のデータを抽出し、
    前記ある量のデータを分析して、前記データパケットが前記マスタデバイス（２１５０）を宛先としていたかどうかを判定するように構成されることを特徴とする医療デバイスネットワーク。
  38. 医療デバイスネットワークを形成する複数の医療デバイス（２２０２、２２０４、２２０６、２２０８）と、
    前記医療デバイスネットワークにおける第１のサブネットワークであって、第１の同期タイミングスキームを使用して互いの間で通信するように構成された前記複数の医療デバイス（２２０２、２２０４、２２０６、２２０８）の第１のサブセットを含む第１のサブネットワークと、
    前記医療デバイスネットワークにおける第２のサブネットワークであって、第２の同期タイミングスキームを使用して互いの間で通信するように構成された前記複数の医療デバイス（２２０２、２２０８）の第２のサブセットを含む第２のサブネットワークと、
    を含む医療デバイスシステムであって、
    前記医療デバイスネットワークは、前記第１の同期タイミングスキームおよび前記第２の同期タイミングスキームを調整して、前記第１のサブネットワークと前記第２のサブネットワークの同時の動作を可能にするように構成されることを特徴とする医療デバイスシステム。
  39. 請求項３８に記載の医療デバイスシステムであって、
    前記第１のサブネットワーク内の前記医療デバイス（２２０２、２２０４、２２０６）は、第１のサブネットワーク識別子に関連付けられ、前記第２のサブネットワーク内の前記医療デバイス（２２０２、２２０８）は、第２のサブネットワーク識別子に関連付けられることを特徴とする医療デバイスシステム。
  40. 請求項３９に記載の医療デバイスシステムであって、
    前記第１のサブネットワーク内の前記医療デバイス（２２０２、２２０４、２２０６）は、前記第１のサブネットワーク識別子を格納し、前記第２のサブネットワーク内の前記医療デバイス（２２０２、２２０８）は、前記第２のサブネットワーク識別子を格納することを特徴とする医療デバイスシステム。
  41. 請求項３８に記載の医療デバイスシステムであって、
    前記第１のサブネットワーク内の前記医療デバイス（２２０２、２２０４、２２０６）は、前記第２のサブネットワーク内の前記医療デバイス（２２０２、２２０８）との通信を回避するように構成され、前記第２のサブネットワーク内の前記医療デバイス（２２０２、２２０８）は、前記第１のサブネットワーク内の前記医療デバイス（２２０２、２２０４、２２０６）との通信を回避するように構成されることを特徴とする医療デバイスシステム。
  42. 請求項３８に記載の医療デバイスシステムであって、
    前記複数の医療デバイスの少なくとも１つは、前記第１のサブネットワークと前記第２のサブネットワークの両方に共通であることを特徴とする医療デバイスシステム。
  43. 同期データ通信プロトコルを使用して互いの間で通信するように構成された第１のデバイスと第２のデバイスとを有する医療デバイスネットワークのための通信方法（３１００）であって、
    前記第１のデバイスが、無線データ通信チャネルを介して第２のデバイスに次のデータパケットがいつ送信されるか、を動的に決定するステップ（３１０２）、および
    前記第１のデバイスが、前記第２のデバイスに可変時間インジケータを送信するステップ（３１０８）、
    を含み、前記可変時間インジケータは、前記無線データ通信チャネルを介して、前記次のデータパケットがいつ送信されるかを示し、前記可変時間インジケータは、前記可変時間インジケータによって指定されるとおり前記次のデータパケットを受信するように自らを構成するよう、前記第２のデバイスを促すことを特徴とする通信方法（３１００）。
  44. 請求項４３に記載の方法（３１００）であって、
    前記第１のデバイスが、前記可変時間インジケータによって指定されるとおり前記次のデータパケットを送信するように自らを構成するステップ（３１０４）、をさらに含むことを特徴とする方法（３１００）。
  45. 請求項４３に記載の方法（３１００）であって、
    前記第１のデバイスが、前記第１のデバイスと前記第２のデバイスの間で転送されるべきデータに関連付けられた優先度に応じて、前記可変時間インジケータを選択するステップ、をさらに含むことを特徴とする方法（３１００）。
  46. 請求項４３に記載の方法（３１００）であって、
    前記第１のデバイスが、前記第１のデバイスと前記第２のデバイスの間で転送されるべきデータに関連付けられたデータタイプカテゴリに応じて前記可変時間インジケータを選択するステップ、をさらに含むことを特徴とする方法（３１００）。
  47. 請求項４３に記載の方法（３１００）であって、
    前記第１のデバイスが、前記第１のデバイスと前記第２のデバイスの間で転送されるべきデータの傾向特性に応じて前記可変時間インジケータを選択するステップ、をさらに含むことを特徴とする方法（３１００）。
  48. 請求項４７に記載の方法（３１００）であって、
    前記選択するステップは、
    前記傾向特性が、前記第１のデバイスと前記第２のデバイスの間で転送される前記データの比較的高い変化率を表す場合、前記次のデータパケットがいつ送信されるかに対応する比較的短い期間を示す第１の時間インジケータを選択するステップ、および
    前記傾向特性が、前記第１のデバイスと前記第２のデバイスの間で転送される前記データの比較的低い変化率を表す場合、前記次のデータパケットがいつ送信されるかに対応する比較的長い期間を示す第２の時間インジケータを選択するステップ、
    を含むことを特徴とする方法（３１００）。
  49. 請求項４３に記載の方法（３１００）であって、
    前記第１のデバイスが、送信出力基準に応じて前記可変時間インジケータを選択するステップ、をさらに含むことを特徴とする方法（３１００）。
  50. 請求項４３に記載の方法（３１００）であって、
    前記第１のデバイスが、サービス品質測定値に応じて前記可変時間インジケータを選択するステップ、をさらに含むことを特徴とする方法（３１００）。
  51. 医療デバイスシステム内の第１のデバイスと、医療デバイスシステム内の第２のデバイスとの間の無線データ通信チャネルを介して送信されるデータフィールドを有する無線データ通信信号であって、
    前記無線データ通信チャネルを介して、次のデータパケットがいつ送信されるかを示す可変時間インジケータ（１７１２）を表すデータを含むデータパケット（１７００）を含むことを特徴とする無線データ通信信号。
  52. 請求項５１に記載の無線データ通信信号であって、
    前記可変時間インジケータ（１７１２）は、前記第１のデバイスと前記第２のデバイスの間の無線データ通信セッション中に動的に更新可能であることを特徴とする無線データ通信信号。
  53. 請求項５１に記載の無線データ通信信号であって、
    前記可変時間インジケータ（１７１２）は、前記第１のデバイスと前記第２のデバイスの間で転送されるべきデータに関連付けられた優先度に応じて、動的に更新可能であることを特徴とする無線データ通信信号。
  54. 請求項５１に記載の無線データ通信信号であって、
    前記可変時間インジケータ（１７１２）は、前記第１のデバイスと前記第２のデバイスの間で転送されるべきデータに関連付けられたデータタイプカテゴリに応じて、動的に更新可能であることを特徴とする無線データ通信信号。
  55. 請求項５１に記載の無線データ通信信号であって、
    前記可変時間インジケータ（１７１２）は、前記第１のデバイスと前記第２のデバイスの間で転送されるデータの傾向特性に応じて、動的に更新可能であることを特徴とする無線データ通信信号。
  56. 請求項５５に記載の無線データ通信信号であって、
    前記傾向特性が、前記第１のデバイスと前記第２のデバイスの間で転送される前記データの比較的高い変化率を表す場合、前記可変時間インジケータ（１７１２）は、前記次のデータパケットがいつ送信されるかに対応する比較的短い期間を示し、
    前記傾向特性が、前記第１のデバイスと前記第２のデバイスの間で転送されるべき前記データの比較的低い変化率を表す場合、前記可変時間インジケータ（１７１２）は、前記次のデータパケットがいつ送信されるかに対応する比較的長い期間を示すことを特徴とする無線データ通信信号。
  57. 請求項５１に記載の無線データ通信信号であって、
    前記可変時間インジケータ（１７１２）は、送信出力基準に応じて、動的に更新可能であることを特徴とする無線データ通信信号。
  58. 請求項５１に記載の無線データ通信信号であって、
    前記可変時間インジケータ（１７１２）は、サービス品質測定値に応じて、動的に更新可能であることを特徴とする無線データ通信信号。
  59. 請求項５１に記載の無線データ通信信号であって、
    前記可変時間インジケータ（１７１２）は、前記次のデータパケットがいつ送信されるかに対応する期間を示すことを特徴とする無線データ通信信号。
  60. 請求項５１に記載の無線データ通信信号であって、
    前記可変時間インジケータ（１７１２）は、前記次のデータパケットがいつ送信されるかに対応する送信時刻を指定することを特徴とする無線データ通信信号。
  61. 共通の搬送周波数を使用して同期された仕方で通信するように構成された複数のデバイスを有する無線医療デバイスネットワークのための通信方法（２３００）であって、
    前記無線医療デバイスネットワーク内の第１のデバイスが、前記無線医療デバイスネットワーク内の複数の他のデバイスにデータパケットをブロードキャストする捨て婦（２３０８）、
    前記第１のデバイスが、前記データパケットに応じて前記他のデバイスから応答パケットを、擬似ランダムな順序で受信するステップ（２３１２）と、および
    前記第１のデバイスが、前記応答パケットを前記他のデバイスと互いに関係付けるステップ、
    を含むことを特徴とする通信方法（２３００）。
  62. 請求項６１に記載の方法（２３００）であって、
    前記第１のデバイス、および前記他のデバイスのそれぞれにおいて乱数発生器のインスタンシエーションを保持するステップ（２３０２）、
    前記乱数発生器のインスタンシエーションに共通の種の値を与えるステップ（２３０４）、および
    前記乱数発生器の前記それぞれのインスタンシエーションに基づいて、さらに前記共通の種の値に応じて、前記第１のデバイス、および前記他のデバイスのそれぞれにおいて前記擬似ランダムな順序を導き出すステップ（２３０６）、
    をさらに含むことを特徴とする方法（２３００）。
  63. 請求項６１に記載の方法（２３００）であって、
    前記他のデバイスのそれぞれにより、前記擬似ランダムな順序によって決定された異なるタイムスロットでそれぞれの応答パケットを送信するステップ、をさらに含むことを特徴とする方法（２３００）。
  64. 請求項６１に記載の方法（２３００）であって、
    前記他のデバイスのそれぞれにより、前記擬似ランダムな順序によって決定されたシーケンスで、それぞれの応答パケットを送信するステップ、をさらに含むことを特徴とする方法（２３００）。
  65. 請求項６１に記載の方法（２３００）であって、
    前記データパケットは、前記他のデバイスが同期するマスタクロック時刻を伝送することを特徴とする方法（２３００）。
  66. 医療デバイスネットワークのための通信方法（２４００）であって、
    前記医療デバイスネットワーク内の第１のデバイスが、第１の無線データ通信リンクを介して、前記医療デバイスネットワーク内の宛先デバイスを宛先とするメッセージを受信するステップ（２４０４）、および
    前記第１のデバイスが、第２の無線データ通信リンクを介して前記医療デバイスネットワーク内で前記メッセージを前記宛先デバイスに到達するように転送すること（２４０８）を含むことを特徴とする通信方法（２４００）。
  67. 請求項６６に記載の方法（２４００）であって、
    前記第１のデバイスは、前記メッセージを前記宛先デバイスに転送することを特徴とする方法（２４００）。
  68. 請求項６６に記載の方法（２４００）であって、
    前記第１のデバイスは、前記メッセージを、前記医療デバイスネットワーク内の第２のデバイスに転送することを特徴とする方法（２４００）。
  69. 請求項６８に記載の方法（２４００）であって、
    前記第２のデバイスが、前記医療デバイスネットワーク内で前記メッセージを前記宛先デバイスに到達するように転送することをさらに含むことを特徴とする方法（２４００）。
  70. 請求項６６に記載の方法（２４００）であって、
    前記メッセージに関する転送順序を決定するステップ（２４０６）をさらに含み、前記転送順序は、前記医療デバイスネットワーク内のデバイスのシーケンスを表し、前記転送順序は、前記医療デバイスネットワーク内の前記宛先デバイスの位置に基づくことを特徴とする方法（２４００）。
  71. 請求項６６に記載の方法（２４００）であって、
    前記医療デバイスネットワークは、前記第１のデバイスおよび前記宛先デバイスを含む複数のデバイスを含み、前記第１のデバイスは、前記複数のデバイスに関する順序付けられたシーケンスに従って、前記メッセージを転送することを特徴とする方法（２４００）。
  72. 請求項６６に記載の方法（２４００）であって、
    前記医療デバイスネットワークは、前記第１のデバイスおよび前記宛先デバイスを含む複数のデバイスを含む方法（２４００）であって、
    前記複数のデバイスのそれぞれが、前記メッセージを処理するまで、前記医療デバイスネットワーク内で前記メッセージを転送すること（２４１２）をさらに含むことを特徴とする方法（２４００）。
  73. 請求項６６に記載の方法（２４００）であって、
    前記メッセージは、前記医療デバイスネットワークに関する警報を伝送することを特徴とする方法（２４００）。
  74. 医療デバイスネットワークにおける動作のために構成された無線デバイス（１６００）であって、
    第１の無線リンクを介して、前記医療デバイスネットワーク内の宛先デバイスを宛先とするメッセージを受信するように構成された無線受信機モジュール（１６０２）と、
    前記宛先デバイスに到達するように、第２の無線リンクを介して前記医療デバイスネットワーク内で前記メッセージを転送するように構成された無線送信機モジュール（１６０２）と、
    を含むことを特徴とする無線デバイス（１６００）。
  75. 請求項７４に記載の無線デバイス（１６００）であって、
    前記宛先デバイスに転送するために前記メッセージをフォーマットするように構成された処理アーキテクチャであって前記無線受信機モジュール（１６０２）および前記無線送信機モジュール（１６０２）に結合された処理アーキテクチャ（１６０６）、をさらに含むことを特徴とする無線デバイス（１６００）。
  76. 請求項７４に記載の無線デバイス（１６００）であって、
    前記医療デバイスネットワーク内の第２のデバイスに転送するために前記メッセージをフォーマットするように構成された処理アーキテクチャであって前記無線受信機モジュール（１６０２）および前記無線送信機モジュール（１６０２）に結合された処理アーキテクチャ（１６０６）、をさらに含むことを特徴とする無線デバイス（１６００）。
  77. 請求項７４に記載の無線デバイス（１６００）であって、
    前記メッセージに関する転送順序を決定するように構成された処理アーキテクチャであって前記無線受信機モジュール（１６０２）および前記無線送信機モジュール（１６０２）に結合された処理アーキテクチャ（１６０６）をさらに含み、前記転送順序は、前記医療デバイスネットワーク内のデバイスのシーケンスを表し、前記転送順序は、前記医療デバイスネットワーク内の前記宛先デバイスの位置に基づくことを特徴とする無線デバイス（１６００）。
  78. 請求項７４に記載の無線デバイス（１６００）であって、
    前記メッセージは、前記医療デバイスネットワークに関する警報を伝送することを特徴とする無線デバイス（１６００）。
  79. 請求項７４に記載の無線デバイス（１６００）であって、
    前記無線受信機モジュールと前記無線送信機モジュールは、無線トランシーバモジュール（１６０２）に一体化されていることを特徴とする無線デバイス（１６００）。
  80. 請求項７４に記載の無線デバイス（１６００）であって、
    物理データ通信リンクを介してコンピューティングデバイスと通信するように構成されたネットワーク通信モジュール（１６０４）をさらに含むことを特徴とする無線デバイス（１６００）。
  81. 請求項８０に記載の無線デバイス（１６００）であって、
    前記ネットワーク通信モジュール（１６０４）は、前記物理データ通信リンクを介する伝送のために前記メッセージを再フォーマットするように構成されることを特徴とする無線デバイス（１６００）。
  82. 医療デバイスネットワークのための通信方法（２４００）であって、
    前記医療デバイスネットワーク内のブロードキャストするデバイスが、前記医療デバイスネットワーク内の複数の宛先デバイスを宛先とするメッセージを、少なくとも１つの無線データ通信リンクを介して送信するステップ（２４０２）、
    前記医療デバイスネットワーク内の第１の宛先デバイスにおいて前記メッセージを受信するステップ（２４０４）、および
    前記第１の宛先デバイスが、転送無線データ通信リンクを介して、前記医療デバイスネットワーク内の第２の宛先デバイスに前記メッセージを転送するステップ（２４０８）、
    を含むことを特徴とする通信方法（２４００）。
  83. 前記メッセージは、前記医療デバイスネットワークに関する警報を伝送する請求項８２に記載の方法（２４００）であって、
    前記医療デバイスネットワーク内の少なくとも１つの宛先デバイスにより、前記メッセージを受信するステップ、および
    前記少なくとも１つの宛先デバイスのそれぞれにより、前記メッセージに応じて、警報指示を生成するステップ、
    をさらに含むことを特徴とする方法（２４００）。
  84. 請求項８３に記載の方法（２４００）であって、
    前記少なくとも１つの宛先デバイスのうちの第１のデバイスにおいて警報終了メッセージを生成するステップ、
    前記警報終了メッセージに応じて、前記少なくとも１つの宛先デバイスのうちの前記第１のデバイスにおいて前記警報指示を終了するステップ、および
    前記少なくとも１つの宛先デバイスのうちの第２のデバイスに前記警報終了メッセージを無線で転送するステップ、
    をさらに含むことを特徴とする方法（２４００）。
  85. 請求項８４に記載の方法（２４００）であって、
    前記少なくとも１つの宛先デバイスのうちの前記第２のデバイスにおいて、転送された警報終了メッセージを受信するステップ、および
    前記転送された警報終了メッセージに応じて、前記少なくとも１つの宛先デバイスのうちの前記第２のデバイスにおいて前記警報指示を終了するステップ、
    をさらに含むことを特徴とする方法（２４００）。
  86. 医療デバイスシステムのための通信方法（２５００）であって、
    前記医療デバイスシステム内の第１のデバイスと、前記医療デバイスシステム内の第２のデバイスとの間で第１の無線データ通信モードをサポートすること、
    前記第１のデバイスと前記第２のデバイスの間で第２の無線データ通信モードをサポートすること、
    前記第１の無線データ通信モードにおいて、肯定応答のない無線データパケットに応じて警報を生成すること（２５１４）、および
    前記第２の無線データ通信モードにおいて、無線データパケット肯定応答ステータスにかかわらず、前記第１のデバイスと前記第２のデバイスの間でベストエフォートサービス品質を提供すること（２５１６）、
    を含むことを特徴とする通信方法（２５００）。
  87. 請求項８６に記載の方法（２５００）であって、
    前記第１のデバイスと前記第２のデバイスの間で転送されるべきデータに関連付けられた優先度に応じて、前記第１の無線データ通信モードまたは前記第２の無線データ通信モードを選択すること、をさらに含むことを特徴とする方法（２５００）。
  88. 請求項８６に記載の方法（２５００）であって、
    前記第１のデバイスと前記第２のデバイスの間で転送されるべきデータに関連付けられたデータタイプカテゴリに応じて、前記第１の無線データ通信モードまたは前記第２の無線データ通信モードを選択すること、をさらに含むことを特徴とする方法（２５００）。
  89. 請求項８６に記載の方法（２５００）であって、
    所定のスケジュールに応じて、前記第１の無線データ通信モードまたは前記第２の無線データ通信モードを選択すること、をさらに含むことを特徴とする方法（２５００）。
  90. 請求項８６に記載の方法（２５００）であって、
    前記第１のデバイスと前記第２のデバイスの間の無線データ通信セッション中に、前記第１の無線データ通信モードと前記第２の無線データ通信モードとの間で動的な切り替えを行うこと（２５２０）、をさらに含むことを特徴とする方法（２５００）。
  91. 請求項８６に記載の方法（２５００）であって、
    前記第２のデータ通信モードに入っている間、サービス品質警報の生成を防止すること（２５１８）、をさらに含むことを特徴とする方法（２５００）。
  92. 請求項８６に記載の方法（２５００）であって、
    前記第１のデバイスが、前記第２のデバイスにモード識別子を送信すること（２５０６）をさらに含み、前記モード識別子は、前記第１の無線データ通信モードまたは前記第２の無線データ通信モードを指定し、前記モード識別子は、前記第２のデバイスに、前記モード識別子によって指示されるとおり前記第１の無線データ通信モードまたは前記第２の無線データ通信モードをサポートするように自らを構成するよう促すことを特徴とする方法（２５００）。
  93. 請求項９２に記載の方法（２５００）であって、
    前記送信するステップ（２５０６）は、少なくとも１つの初期ボンディングパケットの中で前記モード識別子を送信することを特徴とする方法（２５００）。
  94. 請求項８６に記載の方法（２５００）であって、
    前記第２の無線データ通信モードにおいて、前記第１のデバイスが、前記第１の無線データ通信モードに関する範囲内に前記第２のデバイスが存在すると、自動的に検出すること（２６０４）、および
    前記検出するステップに応じて、前記第１の無線データ通信モードに切り替えること（２６０６）、
    をさらに含むことを特徴とする方法（２５００）。
  95. 請求項８６に記載の方法（２５００）であって、
    前記第２の無線データ通信モードにおいて、前記第１のデバイスが、前記第１の無線データ通信モードに関する範囲内に適合するデバイスが存在すると、自動的に検出すること（２７０２）、および
    前記検出するステップに応じて、前記第１のデバイスと前記適合するデバイスの間で無線データ通信セッションを確立し、前記無線データ通信セッションは、前記第１の無線データ通信モードを使用すること（２７０４）、
    をさらに含むことを特徴とする方法（２５００）。
  96. 請求項９５に記載の方法（２５００）であって、
    前記無線データ通信セッションを確立した後、前記第１のデバイスと前記適合するデバイスの間で、蓄積された患者データの転送を開始すること（２７０６）、をさらに含むことを特徴とする方法（２５００）。
  97. 医療デバイスシステム内の第１のデバイスと、医療デバイスシステム内の第２のデバイスとの間の無線データ通信チャネルを介して伝送されるデータフィールドを有する無線データ通信信号（１７００）であって、
    サポートされる複数の無線データ通信モードのうちの選択された１つを表すデータを含むデータフィールドを含み、前記複数の無線データ通信モードの各々は、前記無線データ通信チャネルに関する異なるＲＦ（無線周波数）リンク特性セットにそれぞれ対応する、むことを特徴とする無線データ通信信号（１７００）。
  98. 請求項９７に記載の無線データ通信信号（１７００）であって、
    前記データフィールドは、リンク信頼性設定（１７０２）を表すデータを含み、前記リンク信頼性設定（１７０２）は、第１の無線データ通信モードまたは第２の無線データ通信モードを指定し、前記第１の無線データ通信モードにおいて、前記医療デバイスシステムは、肯定応答のない無線データパケットに応じて警報を生成し、前記第２の無線データ通信モードにおいて、前記医療デバイスシステムは、無線データパケット肯定応答ステータスにかかわらず、前記第１のデバイスと前記第２のデバイスの間でベストエフォートサービス品質を提供する、ことを特徴とする無線データ通信信号（１７００）。
  99. 請求項９７に記載の無線データ通信信号（１７００）であって、
    前記データフィールドは、同期設定（１７０４）を表すデータを含み、前記同期設定（１７０４）は、同期無線データ通信モードまたは非同期無線データ通信モードを指定することを特徴とする無線データ通信信号（１７００）。
  100. 請求項９７に記載の無線データ通信信号（１７００）であって、
    前記データフィールドは、周波数割り当て設定（１７０６）を表すデータを含み、前記周波数割り当て設定（１７０６）は、サポートされる複数の周波数ホッピングスキームの１つを指定することを特徴とする無線データ通信信号（１７００）。
  101. 請求項９７に記載の無線データ通信信号（１７００）であって、
    前記データフィールドは、再試行周期性設定（１７０８）を表すデータを含み、前記再試行周期性設定（１７０８）は、サポートされる複数の再試行タイミングスキームの１つを指定することを特徴とする無線データ通信信号（１７００）。
  102. 請求項９７に記載の無線データ通信信号（１７００）であって、
    前記データフィールドは、マスタ／スレーブ設定（１７１０）を表すデータを含み、前記マスタ／スレーブ設定（１７１０）は、前記無線データ通信信号（１７００）の発信元であるデバイスに関するマスタデバイスステータスまたはスレーブデバイスステータスを指定することを特徴とする無線データ通信信号（１７００）。
  103. 請求項９７に記載の無線データ通信信号（１７００）であって、
    前記データフィールドは、前記第１のデバイスと前記第２のデバイスの間で転送されるべきデータに関連付けられた優先度に応じて、動的に更新可能であることを特徴とする無線データ通信信号（１７００）。
  104. 請求項１０３に記載の無線データ通信信号（１７００）であって、
    前記データフィールドは、前記第１のデバイスと前記第２のデバイスの間で転送されるべきデータに関連付けられた優先度に応じて、動的に更新可能であることを特徴とする無線データ通信信号（１７００）。
  105. 請求項１０３に記載の無線データ通信信号（１７００）であって、
    前記データフィールドは、前記第１のデバイスと前記第２のデバイスの間で転送されるべきデータに関連付けられたデータタイプカテゴリに応じて、動的に更新可能であることを特徴とする無線データ通信信号（１７００）。
  106. 請求項１０３に記載の無線データ通信信号（１７００）であって、
    前記データフィールドは、所定のスケジュールに応じて、動的に更新可能であることを特徴とする無線データ通信信号（１７００）。
  107. 請求項１０３に記載の無線データ通信信号（１７００）であって、
    前記データフィールドは、送信出力基準に応じて、動的に更新可能であることを特徴とする無線データ通信信号（１７００）。
  108. 請求項１０３に記載の無線データ通信信号（１７００）であって、
    前記データフィールドは、サービス品質測定値に応じて、動的に更新可能であることを特徴とする無線データ通信信号（１７００）。
  109. 請求項１０３に記載の無線データ通信信号（１７００）であって、
    前記データフィールドは、肯定応答のない無線データパケットに応じて、動的に更新可能であることを特徴とする無線データ通信信号（１７００）。
  110. 請求項９７に記載の無線データ通信信号（１７００）であって、
    前記データフィールドは、少なくとも１つの初期ボンディングパケットの中で伝送されることを特徴とする無線データ通信信号（１７００）。
  111. 第１のデバイスと、第２のデバイスとを有する医療デバイスシステムのための通信方法（２８００）であって、
    前記第１のデバイスが、前記第２のデバイスとの無線データ通信セッションのために同期無線データ通信モードと非同期無線データ通信モードの間で選択を行うステップ（２８０２）、
    前記第２のデバイスにモード識別子を送信し（２８０８）、前記モード識別子は、前記同期無線データ通信モードまたは前記非同期無線データ通信モードを指定し、前記モード識別子は、前記第２のデバイスに、前記モード識別子によって指示されるとおり、前記同期無線データ通信モードまたは前記非同期無線データ通信モードをサポートするように自らを構成するよう（２８１０）促すステップを含むことを特徴とする通信方法（２８００）。
  112. 請求項１１１に記載の方法（２８００）であって、
    前記第１のデバイスが、前記モード識別子によって指示されるとおり、前記同期無線データ通信モードまたは前記非同期無線データ通信モードをサポートするように自らを構成するステップ（２８０４）をさらに含むことを特徴とする方法（２８００）。
  113. 請求項１１１に記載の方法（２８００）であって、
    前記選択するステップ（２８０２）は、前記第１のデバイスと前記第２のデバイスの間で転送されるべきデータに関連付けられたデータタイプカテゴリに応じて、前記同期無線データ通信モードまたは前記非同期無線データ通信モードを選択するステップ、を特徴とする方法（２８００）。
  114. 請求項１１１に記載の方法（２８００）であって、
    前記同期無線データ通信モードと前記非同期無線データ通信モードの間で動的に切り替えを行うステップ（２８２０）をさらに含むことを特徴とする方法（２８００）。
  115. 請求項１１１に記載の方法（２８００）であって、
    前記送信するステップ（２８０８）は、少なくとも１つの初期ボンディングパケットの中で前記モード識別子を送信するステップを特徴とする方法（２８００）。
  116. 請求項１１１に記載の方法（２８００）であって、
    前記モード識別子が、前記同期無線データ通信モードを指定する場合、前記第１のデバイスと前記第２のデバイスの間で転送されるデータに関する送信／受信スケジュールをネゴシエーションするステップ（２８１６）、および
    前記送信／受信スケジュールに従って前記第１のデバイスと前記第２のデバイスの間で同期無線データ転送をサポートするステップ（２８１８）、
    をさらに含むことを特徴とする方法（２８００）。
  117. 第１のデバイスと、第２のデバイスとを有する医療デバイスシステムのための通信方法（２９００）であって、
    前記第１のデバイスが、異なる周波数割り当てスキームにそれぞれが対応するサポートされる複数の無線データ通信モードの中から１つの無線データ通信モードを選択すること（２９０４）、および
    前記第２のデバイスにモード識別子を送信し（２９１０）、前記モード識別子は、前記無線データ通信モードを指定し、前記モード識別子は、第２のデバイスに、選択された前記無線データ通信モードをサポートするように自らを構成するよう（２９１２）促すことを含むことを特徴とする通信方法（２９００）。
  118. 請求項１１７に記載の方法（２９００）であって、
    前記第１のデバイスが、選択された前記無線データ通信モードをサポートするように自らを構成すること（２９０６）をさらに含むことを特徴とする方法（２９００）。
  119. 請求項１１７に記載の方法（２９００）であって、
    前記選択するステップ（２９０４）は、前記第１のデバイスと前記第２のデバイスとの間で転送されるべきデータに関連付けられたデータタイプカテゴリに応じて、前記無線データ通信モードを選択することを特徴とする方法（２９００）。
  120. 請求項１１７に記載の方法（２９００）であって、
    前記選択するステップ（２９０４）は、送信出力基準に応答して、前記無線データ通信モードを選択することを特徴とする方法（２９００）。
  121. 請求項１１７に記載の方法（２９００）であって、
    前記第１のデバイスと前記第２のデバイスの間の現在の無線データ通信セッションに関するサービス品質測定値を獲得すること（２９０２）をさらに含み、前記選択するステップ（２９０４）は、前記サービス品質測定値に応じて、前記無線データ通信モードを選択することを特徴とする方法（２９００）。
  122. 請求項１１７に記載の方法（２９００）であって、
    前記サポートされる無線データ通信モードの間で動的に切り替えを行うこと（２９１６）をさらに含むことを特徴とする方法（２９００）。
  123. 請求項１１７に記載の方法（２９００）であって、
    前記送信するステップ（２９１０）は、少なくとも１つの初期ボンディングパケットの中で前記モード識別子を送信することを特徴とする方法（２９００）。
  124. 請求項１１７に記載の方法（２９００）であって、
    前記サポートされる無線データ通信モードは、
    単一周波数／チャネルモード、
    ５周波数／チャネルの低電力モード、および
    ５０周波数／チャネルの高電力モードを含むことを特徴とする方法（２９００）。
  125. 第１のデバイスと、第２のデバイスとを有する医療デバイスシステムのための通信方法（３０００）であって、
    前記第１のデバイスと前記第２のデバイスの間で、無線データパケットが第１のタイミングスキームに従って交換される同期データ通信モードで動作するステップ（３００２）、
    肯定応答のない無線データパケットに応じて、前記第１のタイミングスキームとは異なるそれぞれの再試行タイミングスキームにそれぞれが対応する複数の再試行周期性設定から、指定された再試行周期性設定を選択するステップ（３００６）、および
    前記指定された再試行周期性設定を使用して少なくとも１つの無線データパケットを再送するステップ（３０１８）、
    を含むことを特徴とする通信方法（３０００）。
  126. 請求項１２５に記載の方法（３０００）であって、
    前記第１のタイミングスキームは、第１の送信／受信周期に対応し、前記再試行周期性設定のそれぞれは、前記第１の送信／受信周期より短いそれぞれの送信／受信周期に対応することを特徴とする方法（３０００）。
  127. 請求項１２５に記載の方法（３０００）であって、
    サポートされる複数の周波数ホッピングスキームから、前記指定される再試行周期性設定に適合する、指定された周波数ホッピングスキームを選択するステップ（３００８）をさらに含むことを特徴とする方法（３０００）。
  128. 請求項１２５に記載の方法（３０００）であって、
    前記少なくとも１つの無線データパケットを再送した後、サービス品質閾値を満たす動作条件を検出するステップ（３０２０）、および
    前記検出するステップに応じて、前記第１のタイミングスキームに戻るように切り替えを行うステップ、
    をさらに含むことを特徴とする方法（３０００）。
  129. 請求項１２５に記載の方法（３０００）であって、
    前記第１のデバイスが、前記第２のデバイスにモード識別子を送信するステップ（３０１４）をさらに含み、前記モード識別子は、前記指定された再試行周期性設定を示し、前記モード識別子は、前記第２のデバイスに、前記指定された再試行周期性設定をサポートするように自らを構成するよう（３０１６）促すことを特徴とする方法（３０００）。
JP2009548233A 2007-02-05 2007-04-26 無線医療デバイスネットワークに関する無線データ通信プロトコルおよび無線データ通信技術 Pending JP2010524050A (ja)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US11/671,174 US20070255116A1 (en) 2006-04-28 2007-02-05 Broadcast data transmission and data packet repeating techniques for a wireless medical device network
US11/671,176 US20070254593A1 (en) 2006-04-28 2007-02-05 Wireless data communication for a medical device network that supports a plurality of data communication modes
US11/671,172 US8073008B2 (en) 2006-04-28 2007-02-05 Subnetwork synchronization and variable transmit synchronization techniques for a wireless medical device network
US11/671,170 US20070253021A1 (en) 2006-04-28 2007-02-05 Identification of devices in a medical device network and wireless data communication techniques utilizing device identifiers
US11/671,179 US20070258395A1 (en) 2006-04-28 2007-02-05 Wireless data communication protocols for a medical device network
PCT/US2007/067562 WO2008097316A1 (en) 2007-02-05 2007-04-26 Wireless data communication protocols and techniques for a wireless medical device network

Publications (1)

Publication Number Publication Date
JP2010524050A true JP2010524050A (ja) 2010-07-15

Family

ID=56290953

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009548233A Pending JP2010524050A (ja) 2007-02-05 2007-04-26 無線医療デバイスネットワークに関する無線データ通信プロトコルおよび無線データ通信技術

Country Status (4)

Country Link
EP (1) EP2132678B2 (ja)
JP (1) JP2010524050A (ja)
CA (1) CA2644635A1 (ja)
WO (1) WO2008097316A1 (ja)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014513612A (ja) * 2011-03-30 2014-06-05 サノフィ−アベンティス・ドイチュラント・ゲゼルシャフト・ミット・ベシュレンクテル・ハフツング 注射デバイス
US8855550B2 (en) 2011-01-14 2014-10-07 Covidien Lp Wireless relay module having emergency call functionality
US8897198B2 (en) 2011-01-14 2014-11-25 Covidien Lp Medical device wireless network architectures
US8903308B2 (en) 2011-01-14 2014-12-02 Covidien Lp System and method for patient identification in a remote monitoring system
US9020419B2 (en) 2011-01-14 2015-04-28 Covidien, LP Wireless relay module for remote monitoring systems having power and medical device proximity monitoring functionality
JP2015531092A (ja) * 2012-05-24 2015-10-29 デカ・プロダクツ・リミテッド・パートナーシップ 電子患者介護用のシステム、方法、および装置
CN105144170A (zh) * 2013-02-05 2015-12-09 德卡产品有限公司 用于无线控制医疗装置的装置、方法和系统
USD746441S1 (en) 2013-09-13 2015-12-29 Covidien Lp Pump
US9495511B2 (en) 2011-03-01 2016-11-15 Covidien Lp Remote monitoring systems and methods for medical devices
US9596989B2 (en) 2009-03-12 2017-03-21 Raytheon Company Networked symbiotic edge user infrastructure
US9699816B2 (en) 2012-09-13 2017-07-04 Covidien Lp Docking station for an enteral feeding pump
KR20170122140A (ko) * 2016-04-26 2017-11-03 길재소프트 주식회사 초음파 영상기기의 연동장치 및 방법, 이와 연결되는 스마트 단말기
CN110047571A (zh) * 2013-08-21 2019-07-23 美敦力迷你迈德公司 医疗设备和相关更新方法及系统
WO2019189175A1 (ja) * 2018-03-27 2019-10-03 大研医器株式会社 薬液注入システム、薬液注入装置、薬液注入方法及びプログラム
JP2022100345A (ja) * 2018-04-19 2022-07-05 ベクトン・ディキンソン・アンド・カンパニー デバイス接続を識別するためのシステム、方法、およびコンピュータプログラム製品
US11524107B2 (en) 2010-01-22 2022-12-13 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US11810653B2 (en) 2010-01-22 2023-11-07 Deka Products Limited Partnership Computer-implemented method, system, and apparatus for electronic patient care
US12033737B2 (en) 2013-08-21 2024-07-09 Medtronic Minimed, Inc. Streamed communication of updated control information to a medical device via an intermediate device

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9123077B2 (en) 2003-10-07 2015-09-01 Hospira, Inc. Medication management system
US8065161B2 (en) 2003-11-13 2011-11-22 Hospira, Inc. System for maintaining drug information and communicating with medication delivery devices
AU2007317669A1 (en) 2006-10-16 2008-05-15 Hospira, Inc. System and method for comparing and utilizing activity information and configuration information from mulitple device management systems
WO2009026289A2 (en) 2007-08-20 2009-02-26 Hmicro, Inc. Wearable user interface device, system, and method of use
US8926509B2 (en) 2007-08-24 2015-01-06 Hmicro, Inc. Wireless physiological sensor patches and systems
US20110019824A1 (en) 2007-10-24 2011-01-27 Hmicro, Inc. Low power radiofrequency (rf) communication systems for secure wireless patch initialization and methods of use
US8611319B2 (en) 2007-10-24 2013-12-17 Hmicro, Inc. Methods and apparatus to retrofit wired healthcare and fitness systems for wireless operation
US8117481B2 (en) 2008-06-06 2012-02-14 Roche Diagnostics International Ag Apparatus and method for processing wirelessly communicated information within an electronic device
US8132037B2 (en) 2008-06-06 2012-03-06 Roche Diagnostics International Ag Apparatus and method for processing wirelessly communicated data and clock information within an electronic device
US8315885B2 (en) 2009-04-14 2012-11-20 Baxter International Inc. Therapy management development platform
US8271106B2 (en) 2009-04-17 2012-09-18 Hospira, Inc. System and method for configuring a rule set for medical event management and responses
EP2315146B1 (en) * 2009-10-01 2015-08-12 BlackBerry Limited Method and apparatus for monitoring and controlling a medical device using a wireless mobile communication device
US9035744B2 (en) 2009-10-01 2015-05-19 Blackberry Limited Method and apparatus for monitoring and controlling a medical device using a wireless mobile communication device
US9020827B2 (en) 2009-10-16 2015-04-28 Baxter International Inc. Peritoneal dialysis optimized using a patient hand-held scanning device
US11210611B2 (en) 2011-12-21 2021-12-28 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US10044791B2 (en) * 2010-01-22 2018-08-07 Deka Products Limited Partnership System, method, and apparatus for communicating data
US11164672B2 (en) 2010-01-22 2021-11-02 Deka Products Limited Partnership System and apparatus for electronic patient care
US11881307B2 (en) 2012-05-24 2024-01-23 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US20110313789A1 (en) 2010-01-22 2011-12-22 Deka Products Limited Partnership Electronic patient monitoring system
US20120050046A1 (en) * 2010-09-01 2012-03-01 Harris Corporation Systems and methods for monitoring physical, biological and chemical characteristics of a person, animal, object and/or surrounding environment
WO2012040106A1 (en) * 2010-09-20 2012-03-29 Kopin Corporation Wireless video headset with spread spectrum overlay
ITVI20110101A1 (it) * 2011-04-21 2012-10-22 Studio Tecnico Per Ind Gianfranco Bigaran Apparato medicale
CA2852271A1 (en) 2011-10-21 2013-04-25 Hospira, Inc. Medical device update system
US10563681B2 (en) 2011-12-21 2020-02-18 Deka Products Limited Partnership System, method, and apparatus for clamping
WO2013179204A1 (en) 2012-05-31 2013-12-05 Koninklijke Philips N.V. Measurement device
WO2014055486A1 (en) 2012-10-01 2014-04-10 Cooper Technologies Company System and method for support of one-way endpoints in two-way wireless networks
WO2014138446A1 (en) 2013-03-06 2014-09-12 Hospira,Inc. Medical device communication method
US20150066531A1 (en) 2013-08-30 2015-03-05 James D. Jacobson System and method of monitoring and managing a remote infusion regimen
US9662436B2 (en) 2013-09-20 2017-05-30 Icu Medical, Inc. Fail-safe drug infusion therapy system
US10311972B2 (en) 2013-11-11 2019-06-04 Icu Medical, Inc. Medical device system performance index
JP2016537175A (ja) 2013-11-19 2016-12-01 ホスピーラ インコーポレイテッド 注入ポンプ自動化システムおよび方法
US9699708B2 (en) 2014-01-17 2017-07-04 Cooper Technologies Company Dynamically-selectable multi-modal modulation in wireless multihop networks
CA2945647C (en) 2014-04-30 2023-08-08 Hospira, Inc. Patient care system with conditional alarm forwarding
US9724470B2 (en) 2014-06-16 2017-08-08 Icu Medical, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
EP3180717B1 (en) * 2014-08-11 2020-07-22 Ascensia Diabetes Care Holdings AG Reconfigurable measurement system
US9539383B2 (en) 2014-09-15 2017-01-10 Hospira, Inc. System and method that matches delayed infusion auto-programs with manually entered infusion programs and analyzes differences therein
WO2016189417A1 (en) 2015-05-26 2016-12-01 Hospira, Inc. Infusion pump system and method with multiple drug library editor source capability
WO2017051429A1 (en) * 2015-09-22 2017-03-30 Smartron India Private Limited System and method for switching communication protocol between two devices
WO2018013842A1 (en) 2016-07-14 2018-01-18 Icu Medical, Inc. Multi-communication path selection and security system for a medical device
EP3665926A4 (en) * 2017-08-11 2021-08-04 Apple Inc. PROCESS AND APPARATUS FOR RECOVERY AFTER BEAM FAILURE
CN107995690B (zh) * 2017-10-27 2023-04-18 欧普照明股份有限公司 主从工作模式控制方法及装置
US10964428B2 (en) 2018-07-17 2021-03-30 Icu Medical, Inc. Merging messages into cache and generating user interface using the cache
NZ771914A (en) 2018-07-17 2023-04-28 Icu Medical Inc Updating infusion pump drug libraries and operational software in a networked environment
US10861592B2 (en) 2018-07-17 2020-12-08 Icu Medical, Inc. Reducing infusion pump network congestion by staggering updates
WO2020018389A1 (en) 2018-07-17 2020-01-23 Icu Medical, Inc. Systems and methods for facilitating clinical messaging in a network environment
US10692595B2 (en) 2018-07-26 2020-06-23 Icu Medical, Inc. Drug library dynamic version management
CA3107315C (en) 2018-07-26 2023-01-03 Icu Medical, Inc. Drug library management system
CN113098748B (zh) * 2020-03-31 2023-04-18 国网浙江省电力有限公司电力科学研究院 一种基于双模通信的抄表方法及抄表系统

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030009154A1 (en) * 2001-06-20 2003-01-09 Whitman Michael P. Method and system for integrated medical tracking
WO2003094090A2 (en) * 2002-04-30 2003-11-13 Baxter International Inc. System and method for identifying data streams associated with medical equipment
AU2004224345B2 (en) * 2003-03-21 2010-02-18 Welch Allyn, Inc. Personal status physiologic monitor system and architecture and related monitoring methods
JP2006065690A (ja) * 2004-08-27 2006-03-09 Ntt Docomo Inc デバイス認証装置、サービス制御装置、サービス要求装置、デバイス認証方法、サービス制御方法及びサービス要求方法

Cited By (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9596989B2 (en) 2009-03-12 2017-03-21 Raytheon Company Networked symbiotic edge user infrastructure
US11524107B2 (en) 2010-01-22 2022-12-13 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US12070572B2 (en) 2010-01-22 2024-08-27 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US11810653B2 (en) 2010-01-22 2023-11-07 Deka Products Limited Partnership Computer-implemented method, system, and apparatus for electronic patient care
US8855550B2 (en) 2011-01-14 2014-10-07 Covidien Lp Wireless relay module having emergency call functionality
US8897198B2 (en) 2011-01-14 2014-11-25 Covidien Lp Medical device wireless network architectures
US8903308B2 (en) 2011-01-14 2014-12-02 Covidien Lp System and method for patient identification in a remote monitoring system
US9020419B2 (en) 2011-01-14 2015-04-28 Covidien, LP Wireless relay module for remote monitoring systems having power and medical device proximity monitoring functionality
US9495511B2 (en) 2011-03-01 2016-11-15 Covidien Lp Remote monitoring systems and methods for medical devices
JP2014513612A (ja) * 2011-03-30 2014-06-05 サノフィ−アベンティス・ドイチュラント・ゲゼルシャフト・ミット・ベシュレンクテル・ハフツング 注射デバイス
JP2020114387A (ja) * 2012-05-24 2020-07-30 デカ・プロダクツ・リミテッド・パートナーシップ 監視クライアントとベースとの間の通信のための方法およびシステム
JP2017130208A (ja) * 2012-05-24 2017-07-27 デカ・プロダクツ・リミテッド・パートナーシップ 電子患者介護用のシステム、方法、および装置
JP7479414B2 (ja) 2012-05-24 2024-05-08 デカ・プロダクツ・リミテッド・パートナーシップ 監視クライアントとベースとの間の通信のための方法およびシステム
JP2015531092A (ja) * 2012-05-24 2015-10-29 デカ・プロダクツ・リミテッド・パートナーシップ 電子患者介護用のシステム、方法、および装置
JP2019050001A (ja) * 2012-05-24 2019-03-28 デカ・プロダクツ・リミテッド・パートナーシップ 電子患者介護用のシステム、方法、および装置
JP2022105331A (ja) * 2012-05-24 2022-07-13 デカ・プロダクツ・リミテッド・パートナーシップ 監視クライアントとベースとの間の通信のための方法およびシステム
JP7030864B2 (ja) 2012-05-24 2022-03-07 デカ・プロダクツ・リミテッド・パートナーシップ 監視クライアントとベースとの間の通信のための方法およびシステム
US9699816B2 (en) 2012-09-13 2017-07-04 Covidien Lp Docking station for an enteral feeding pump
JP2016512442A (ja) * 2013-02-05 2016-04-28 デカ・プロダクツ・リミテッド・パートナーシップ 医療デバイスの無線制御のためのデバイス、方法およびシステム
CN105144170A (zh) * 2013-02-05 2015-12-09 德卡产品有限公司 用于无线控制医疗装置的装置、方法和系统
US12033737B2 (en) 2013-08-21 2024-07-09 Medtronic Minimed, Inc. Streamed communication of updated control information to a medical device via an intermediate device
CN110047571A (zh) * 2013-08-21 2019-07-23 美敦力迷你迈德公司 医疗设备和相关更新方法及系统
CN110047571B (zh) * 2013-08-21 2023-10-27 美敦力迷你迈德公司 医疗设备和相关更新方法及系统
USD746441S1 (en) 2013-09-13 2015-12-29 Covidien Lp Pump
USD844130S1 (en) 2013-09-13 2019-03-26 Kpr U.S., Llc Pump base
KR20170122140A (ko) * 2016-04-26 2017-11-03 길재소프트 주식회사 초음파 영상기기의 연동장치 및 방법, 이와 연결되는 스마트 단말기
KR102018298B1 (ko) 2016-04-26 2019-09-05 길재소프트 주식회사 초음파 영상기기의 연동장치 및 방법, 이와 연결되는 스마트 단말기
JP7062483B2 (ja) 2018-03-27 2022-05-06 大研医器株式会社 薬液注入システム
US11964125B2 (en) 2018-03-27 2024-04-23 Daiken Medical Co., Ltd. Drug solution injection system, drug solution injection device, drug solution injection method, and program
JP2019170452A (ja) * 2018-03-27 2019-10-10 大研医器株式会社 薬液注入システム、薬液注入装置、薬液注入方法及びプログラム
WO2019189175A1 (ja) * 2018-03-27 2019-10-03 大研医器株式会社 薬液注入システム、薬液注入装置、薬液注入方法及びプログラム
JP7397117B2 (ja) 2018-04-19 2023-12-12 ベクトン・ディキンソン・アンド・カンパニー デバイス接続を識別するためのシステム、方法、およびコンピュータプログラム製品
US11967423B2 (en) 2018-04-19 2024-04-23 Becton, Dickinson And Company System, method, and computer program product for identifying device connections
JP2022100345A (ja) * 2018-04-19 2022-07-05 ベクトン・ディキンソン・アンド・カンパニー デバイス接続を識別するためのシステム、方法、およびコンピュータプログラム製品

Also Published As

Publication number Publication date
EP2132678B2 (en) 2018-04-04
EP2132678A1 (en) 2009-12-16
CA2644635A1 (en) 2008-08-14
WO2008097316A1 (en) 2008-08-14
EP2132678B1 (en) 2014-11-05

Similar Documents

Publication Publication Date Title
EP2132678B1 (en) Wireless data communication protocols and techniques for a wireless medical device network
US8095692B2 (en) Identification of devices in a medical device network and wireless data communication techniques utilizing device identifiers
US8073008B2 (en) Subnetwork synchronization and variable transmit synchronization techniques for a wireless medical device network
US20120016305A1 (en) Wireless data communication protocols for a medical device network
US20110110281A1 (en) Broadcast data transmission and data packet repeating techniques for a wireless medical device network
US20070254593A1 (en) Wireless data communication for a medical device network that supports a plurality of data communication modes
US8348885B2 (en) Remote monitoring for networked fluid infusion systems
US7942844B2 (en) Remote monitoring for networked fluid infusion systems
US20070253380A1 (en) Data translation device with nonvolatile memory for a networked medical device system
CN109644327B (zh) 用于传感器系统和接收器之间的无线数据通信的方法和用于无线数据通信的系统
KR101585364B1 (ko) 전력 및 의료 디바이스 근접성 모니터링 기능을 가진 원격 모니터링 시스템들을 위한 무선 중계 모듈
US20060247505A1 (en) Wireless sensor system
EP2856767B2 (en) Measurement device
US20140142963A1 (en) System and Method for Providing Patient Care
KR20140105011A (ko) 의료 디바이스들을 위한 원격 모니터링 시스템들 및 방법들
AU2012205516A1 (en) Medical device wireless network architectures
CA3191092A1 (en) Automatic pairing of devices to a communication gateway
Bluetooth Health Device Profile
REmotE-monItoRInG Works in Progress