JP2021062275A

JP2021062275A - 医療デバイスの無線制御のためのデバイス、方法およびシステム

Info

Publication number: JP2021062275A
Application number: JP2021008634A
Authority: JP
Inventors: カメンディーン; Dean Kamen; エム．カーウィンジョン; John M Kerwin; エー．デュランドケビン; A Durand Kevin; アール．ラニエールジュニアグレゴリー; R Lanier Gregory Jr; ビー．グレイラリー; Larry B Gray; ダブリュー．リビニウスグレッグ; W Rivinius Gregg; エム．ガイジェラルド; M Guay Gerald; ディー．ペレットボブ; D Peret Bob; エイチ．マーフィーコリン; h murphy Colin; ブルンバーグジュニアデイビッド; Blumberg David Jr
Original assignee: Deka Products LP
Current assignee: Deka Products LP
Priority date: 2011-12-21
Filing date: 2021-01-22
Publication date: 2021-04-22
Also published as: US20210252215A1; CA3149410A1; JP2023037008A; US9662438B2; MX2014007752A; US10786621B2; EP2793974A4; US20120238851A1; EP3662943B1; WO2013096789A8; EP2793974A1; CA2859561A1; JP2015506738A; CA2859561C; US20180104406A1; EP4166168A1; MX359858B; JP2017109141A; WO2013096789A1; JP6636697B2

Abstract

【課題】医療デバイスの無線制御のためのデバイス、方法およびシステムを提供する。【解決手段】医療デバイスシステムは、第１の医療デバイス１８０２および第２の医療デバイス１８０４，１８０６を含む。タッチスクリーンを含む、遠隔インターフェース１８００もまた、含まれる。遠隔インターフェースは、第１の医療デバイスおよび第２の医療デバイスと無線通信する。遠隔インターフェースは、ユーザインターフェースを第１の医療デバイスおよび第２の医療デバイスに提供するように構成される。遠隔インターフェースは、タッチスクリーンを通して、ユーザ入力を受信するように構成される。【選択図】図１８

Description

本開示は、医療デバイスに関し、より具体的には、少なくとも１つの医療デバイスを制御するためのシステムに関する。

生物学的製剤を含む、多くの潜在的に貴重な薬剤または化合物は、吸収率の悪さ、肝代謝、または他の薬剤動態学的要因により、経口で有効ではない。加えて、いくつかの治療化合物は、経口で吸収することができるが、頻繁に投与されることを必要とすることがあり、患者が所望のスケジュールを維持することは困難である。このような場合、非経口送達がしばしば採用されるか、または採用することができる。

皮下注射、筋肉内注射、および静脈内（ＩＶ）投与等の、薬剤送達ならびに他の流体および化合物の効果的な非経口経路は、針またはスタイレットによる皮膚の穿刺を含む。インスリンは、何百万人もの糖尿病患者によって自己注射される、治療流体の実施例である。非経口送達された薬剤のユーザは、ある期間にわたって必要な薬剤／化合物を自動的に送達する装着タイプデバイスから利益を享受し得る。

この目的を達成するために、治療薬の制御された放出のための携帯タイプかつ装着タイプのデバイスを設計する取り組みが行われてきた。そのようなデバイスは、カートリッジ、シリンジ、またはバッグ等のリザーバを有すること、および電子的に制御されることが知られている。これらのデバイスは、誤動作率を含む、多数の欠点を抱えている。これらのデバイスのサイズ、重量、および費用を削減することも、継続的課題である。加えて、これらのデバイスはしばしば、皮膚に適用し、適用のための頻繁な再配置という課題をもたらす。

単一ユーザにとって、複数の医療デバイスを同時に管理することは、課題を呈する。その１つとして、ハードウェアが挙げられ、多くの医療デバイスの場合、専用インターフェースを含み、無線で制御される医療デバイスに対する、複数の「コントローラ」または「ハンドヘルド」は、論理的課題を呈する。第１に、種々のインターフェースが、１つのインターフェースから別のインターフェースおよびマスタに注意を向けることは困難であり得る。第２に、複数のデバイスを再充電することは、課題を呈し得、第３に、複数のコントローラとともに、医療デバイスを搬送することは、課題を呈する。

本発明の一側面によると、医療デバイスシステムが、開示される。医療デバイスシステムは、第１の医療デバイスおよび第２の医療デバイスを含む。システムはまた、タッチスクリーンを含む、遠隔インターフェースを含む。遠隔インターフェースは、第１の医療デバイスおよび第２の医療デバイスと無線通信する。遠隔インターフェースは、ユーザインターフェースを第１の医療デバイスおよび第２の医療デバイスに提供するように構成される。遠隔インターフェースは、タッチスクリーンを通して、ユーザ入力を受信するように構成される。また、充電デバイスも、含まれる。充電デバイスは、少なくとも第１の医療デバイスおよび遠隔インターフェースを受容するように構成され、充電デバイスは、第１の医療デバイスバッテリを再充電するように構成され、充電デバイスは、遠隔インターフェース内のインターフェースバッテリを再充電するように構成される。充電デバイスは、パーソナルコンピュータに接続され、パーソナルコンピュータは、情報を遠隔インターフェースに提供する。

本発明の本側面のいくつかの実施形態は、以下のうちの１つ以上を含んでもよい。第１の医療デバイスは、注入ポンプである。第１の医療デバイスはさらに、少なくとも１つの使い捨て部分および少なくとも２つの再使用可能部分を含み、２つの再使用可能部分はそれぞれ、少なくとも１つの使い捨て部分に接続するように構成される。充電デバイスは、第１の医療デバイスの少なくとも２つの再使用可能部分のうちの少なくとも１つを受容するように構成される。第２の医療デバイスは、少なくとも１つの送信機を備える、持続的グルコースモニタシステムであって、少なくとも１つの送信機は、遠隔インターフェースと無線通信する。システムはさらに、遠隔インターフェースと無線通信する、第３の医療デバイスを含む。遠隔インターフェースは、ユーザインターフェースを第３の医療デバイスに提供するように構成される。第３の医療デバイスは、少なくとも１つの血中グルコースメータである。システムではさらに、無線通信は、無線周波数通信である。第１の医療デバイスおよび遠隔インターフェースは、近距離通信を使用してペアリングされる。および／または遠隔インターフェースは、少なくとも１つのカメラをさらに備える。

本発明の一側面によると、医療デバイスシステムが、開示される。医療デバイスシステムは、第１の医療デバイスと、第１の医療デバイスと無線通信する、第２の医療デバイスとを含む。システムはまた、タッチスクリーンを含む、遠隔インターフェースを含む。遠隔インターフェースは、第１の医療デバイスと無線通信し、遠隔インターフェースは、ユーザインターフェースを第１の医療デバイスおよび第２の医療デバイスに提供するように構成される。遠隔インターフェースは、タッチスクリーンを通して、ユーザ入力を受信す
るように構成される。システムはまた、第１の医療デバイスおよび遠隔インターフェースを受容するように構成される、充電デバイスを含む。充電デバイスは、第１の医療デバイスバッテリを再充電するように構成され、かつ充電デバイスは、遠隔インターフェース内のインターフェースバッテリを再充電するように構成される。充電デバイスは、パーソナルコンピュータに接続され、パーソナルコンピュータは、情報を遠隔インターフェースに提供する。

本発明の本側面のいくつかの実施形態は、以下のうちの１つ以上を含んでもよい。第１の医療デバイスは、注入ポンプである。第１の医療デバイスはさらに、少なくとも１つの使い捨て部分および少なくとも２つの再使用可能部分を含み、２つの再使用可能部分はそれぞれ、少なくとも１つの使い捨て部分に接続するように構成される。充電デバイスは、第１の医療デバイスの少なくとも２つの再使用可能部分のうちの少なくとも１つを受容するように構成される。第２の医療デバイスは、少なくとも１つの送信機を含む、持続的グルコースモニタシステムを含み、少なくとも１つの送信機は、第１の医療デバイスと無線通信する。第２の医療デバイスは、第１の医療デバイスと無線通信する、血中グルコースメータを含む。第１の医療デバイスおよび遠隔インターフェースは、近距離通信を使用してペアリングされる。第１の医療デバイスおよび第２の医療デバイスは、近距離通信を使用してペアリングされる。

本発明の一側面によると、注入ポンプシステムが、開示される。注入ポンプシステムは、注入ポンプの少なくとも１つの使い捨て部分と、注入ポンプの少なくとも２つの再使用可能部分であって、注入ポンプの２つの再使用可能部分はそれぞれ、少なくとも１つの使い捨て部分に接続するように構成される、再使用可能部分とを含む。システムはまた、タッチスクリーンを含む、遠隔インターフェースを含み、遠隔インターフェースは、少なくとも２つの再使用可能部分のうちの少なくとも１つと無線通信し、遠隔インターフェースは、ユーザ指示を少なくとも２つの再使用可能部分のうちの少なくとも１つに提供するように構成され、遠隔インターフェースは、タッチスクリーンを通して、ユーザ入力を受信するように構成される。システムはまた、少なくとも２つの再使用可能部分および遠隔インターフェースのうちの少なくとも１つを受容するように構成される、充電デバイスを含む。充電デバイスは、少なくとも２つの再使用可能部分のうちの少なくとも１つのポンプバッテリを再充電するように構成され、充電デバイスは、遠隔インターフェース内のイン
ターフェースバッテリを再充電するように構成される。充電デバイスは、パーソナルコンピュータに接続され、パーソナルコンピュータは、情報を遠隔インターフェースに提供する。

本発明の本側面のいくつかの実施形態は、以下のうちの１つ以上を含んでもよい。システムはさらに、少なくとも１つの送信機を含む、持続的グルコースモニタシステムを含み、少なくとも１つの送信機は、遠隔インターフェースと無線通信する。システムはさらに、少なくとも１つの血中グルコースメータを含み、血中グルコースメータは、遠隔インターフェースと無線通信する。少なくとも１つの再使用可能部分および遠隔インターフェースは、近距離通信を使用してペアリングされる。遠隔インターフェースはさらに、少なく
とも１つの加速度計を含む。遠隔インターフェースはさらに、少なくとも１つのカメラを含む。

本発明の一側面によると、注入ポンプシステムが、開示される。注入ポンプシステムは、注入ポンプと、注入ポンプを制御するための指示を含む、注入ポンプと無線通信する、遠隔インターフェースデバイスとを含み、指示は、セキュアなウェブポータルと同期されてもよい。

本発明の本側面のいくつかの実施形態は、以下のうちの１つ以上を含んでもよい。システムはさらに、送信機を含む、持続的グルコースモニタシステムを含み、送信機は、遠隔インターフェースデバイスと無線通信する。システムはさらに、血中グルコースメータを含み、血中グルコースメータは、遠隔インターフェースデバイスと無線通信する。無線通信は、無線周波数（「ＲＦ」）通信である。注入ポンプおよび遠隔インターフェースデバイスは、近距離通信を使用してペアリングされる。システムはさらに、少なくとも１つの加速度計を含む。

本発明の一側面によると、医療デバイスシステムが、開示される。医療デバイスシステムは、第１の医療デバイスと、第１の医療デバイスと無線通信する、第２の医療デバイスとを含み、第２の医療デバイスは、第１の医療デバイスを制御するための指示を含み、指示は、セキュアなウェブポータルと同期されてもよい。

本発明の本側面のいくつかの実施形態は、以下のうちの１つ以上を含んでもよい。第１の医療デバイスは、注入ポンプであって、第２の医療デバイスは、遠隔インターフェースデバイスである。注入ポンプおよび遠隔インターフェースデバイスは、近距離通信を使用してペアリングされる。第１の医療デバイスは、持続的グルコースモニタセンサであって、第２の医療デバイスは、遠隔インターフェースデバイスである。注入ポンプおよび遠隔インターフェースデバイスは、近距離通信を使用してペアリングされる。第１の医療デバ
イスは、血中グルコースメータであって、第２の医療デバイスは、遠隔インターフェースデバイスである。注入ポンプおよび遠隔インターフェースデバイスは、近距離通信を使用してペアリングされる。

本発明の一側面によると、２つの医療デバイス間の通信のための方法が、開示される。本方法は、第１の医療デバイスが、無線信号とともに、音響信号を第２の医療デバイスに送信するステップと、音響信号を使用して、第１の医療デバイスと第２の医療デバイスとの間の距離を計算するステップと、計算された距離が所定の閾値を超えるかどうか判定するステップと、計算された距離が所定の閾値を超える場合、ユーザに通知するステップと
を含む。

本発明の本側面のいくつかの実施形態は、以下のうちの１つ以上を含んでもよい。第１の医療デバイスは、遠隔インターフェースであって、第２の医療デバイスは、注入ポンプである。第１の医療デバイスは、遠隔インターフェースであって、第２の医療デバイスは、持続的グルコースモニタセンサ／送信機である。第１の医療デバイスは、遠隔インターフェースであって、第２の医療デバイスは、血中グルコースメータである。

本発明のこれらの側面は、排他的であることを意味するものではなく、本発明の他の特徴、側面、および利点は、添付の請求項および付随の図面と併せて熟読されることによって、当業者に容易に明白となるであろう。

本発明のこれらおよび他の特徴ならびに利点は、図面とともに、以下の発明を実施するための形態を熟読することによってより理解されるであろう。
例えば、本明細書は、以下を提供する。
（項目１）
医療デバイスシステムであって、
第１の医療デバイスと、
第２の医療デバイスと、
タッチスクリーンを備える遠隔インターフェースであって、上記遠隔インターフェースは、上記第１の医療デバイスおよび上記第２の医療デバイスと無線通信し、上記遠隔インターフェースは、ユーザインターフェースを上記第１の医療デバイスおよび上記第２の医療デバイスに提供するように構成され、上記遠隔インターフェースは、タッチスクリーンを通して、ユーザ入力を受信するように構成されている、遠隔インターフェースと、
少なくとも上記第１の医療デバイスおよび上記遠隔インターフェースを受容するように構成された充電デバイスであって、上記充電デバイスは、第１の医療デバイスバッテリを再充電するように構成され、上記充電デバイスは、上記遠隔インターフェース内のインターフェースバッテリを再充電するように構成され、上記充電デバイスは、パーソナルコンピュータに接続され、上記パーソナルコンピュータは、情報を上記遠隔インターフェースに提供する、充電デバイスと
を備える、システム。
（項目２）
上記第１の医療デバイスは、注入ポンプである、項目１に記載のシステム。
（項目３）
上記第１の医療デバイスは、少なくとも１つの使い捨て部分および少なくとも２つの再使用可能部分をさらに備え、上記２つの再使用可能部分のそれぞれは、上記少なくとも１つの使い捨て部分に接続するように構成されている、項目２に記載のシステム。
（項目４）
上記充電デバイスは、上記第１の医療デバイスの上記少なくとも２つの再使用可能部分のうちの少なくとも１つを受容するように構成されている、項目３に記載のシステム。
（項目５）
上記第２の医療デバイスは、少なくとも１つの送信機を備える持続的グルコースモニタシステムであり、上記少なくとも１つの送信機は、上記遠隔インターフェースと無線通信する、項目１に記載のシステム。
（項目６）
上記遠隔インターフェースと無線通信する第３の医療デバイスをさらに備える、項目１に記載のシステム。
（項目７）
上記遠隔インターフェースは、ユーザインターフェースを上記第３の医療デバイスに提供するように構成されている、項目６に記載のシステム。
（項目８）
上記第３の医療デバイスは、少なくとも１つの血中グルコースメータである、項目７に記載のシステム。
（項目９）
さらに、上記無線通信が無線周波数通信であることを備える、項目１に記載のシステム。
（項目１０）
上記第１の医療デバイスおよび上記遠隔インターフェースは、近距離通信を使用してペアリングされる、項目１に記載のシステム。
（項目１１）
上記遠隔インターフェースは、少なくとも１つのカメラをさらに備える、項目１に記載のシステム。
（項目１２）
医療デバイスシステムであって、
第１の医療デバイスと、
上記第１の医療デバイスと無線通信する第２の医療デバイスと、
タッチスクリーンを備える遠隔インターフェースであって、上記遠隔インターフェースは、上記第１の医療デバイスと無線通信し、上記遠隔インターフェースは、ユーザインターフェースを上記第１の医療デバイスおよび上記第２の医療デバイスに提供するように構成され、上記遠隔インターフェースは、タッチスクリーンを通して、ユーザ入力を受信するように構成されている、遠隔インターフェースと、
上記第１の医療デバイスおよび上記遠隔インターフェースを受容するように構成された充電デバイスであって、上記充電デバイスは、第１の医療デバイスバッテリを再充電するように構成され、上記充電デバイスは、上記遠隔インターフェース内のインターフェースバッテリを再充電するように構成され、上記充電デバイスは、パーソナルコンピュータに接続され、上記パーソナルコンピュータは、情報を上記遠隔インターフェースに提供する、充電デバイスと
を備える、システム。
（項目１３）
上記第１の医療デバイスは、注入ポンプである、項目１２に記載のシステム。
（項目１４）
上記第１の医療デバイスは、少なくとも１つの使い捨て部分および少なくとも２つの再使用可能部分をさらに備え、上記２つの再使用可能部分のそれぞれは、上記少なくとも１つの使い捨て部分に接続するように構成されている、項目１３に記載のシステム。
（項目１５）
上記充電デバイスは、上記第１の医療デバイスの上記少なくとも２つの再使用可能部分のうちの少なくとも１つを受容するように構成されている、項目１３に記載のシステム。
（項目１６）
上記第２の医療デバイスは、少なくとも１つの送信機を備える持続的グルコースモニタシステムを備え、上記少なくとも１つの送信機は、上記第１の医療デバイスと無線通信する、項目１２に記載のシステム。
（項目１７）
上記第２の医療デバイスは、上記第１の医療デバイスと無線通信する血中グルコースメータを備える、項目１２に記載のシステム。
（項目１８）
上記第１の医療デバイスおよび上記遠隔インターフェースは、近距離通信を使用してペアリングされる、項目１２に記載の注入ポンプシステム。
（項目１９）
上記第１の医療デバイスおよび上記第２の医療デバイスは、近距離通信を使用してペアリングされる、項目１２に記載の注入ポンプシステム。
（項目２０）
注入ポンプシステムであって、
注入ポンプの少なくとも１つの使い捨て部分と、
注入ポンプの少なくとも２つの再使用可能部分であって、注入ポンプの上記２つの再使用可能部分のそれぞれは、上記少なくとも１つの使い捨て部分に接続するように構成されている、少なくとも２つの再使用可能部分と、
タッチスクリーンを備える遠隔インターフェースであって、上記遠隔インターフェースは、上記少なくとも２つの再使用可能部分のうちの少なくとも１つと無線通信し、上記遠隔インターフェースは、ユーザ指示を上記少なくとも２つの再使用可能部分のうちの上記少なくとも１つに提供するように構成され、上記遠隔インターフェースは、タッチスクリーンを通して、ユーザ入力を受信するように構成されている、遠隔インターフェースと、
上記少なくとも２つの再使用可能部分および上記遠隔インターフェースのうちの少なくとも１つを受容するように構成された充電デバイスであって、上記充電デバイスは、上記少なくとも２つの再使用可能部分のうちの上記少なくとも１つのポンプバッテリを再充電するように構成され、上記充電デバイスは、上記遠隔インターフェース内のインターフェースバッテリを再充電するように構成され、上記充電デバイスは、パーソナルコンピュータに接続され、上記パーソナルコンピュータは、情報を上記遠隔インターフェースに提供する、充電デバイスと、
を備える、注入ポンプシステム。
（項目２１）
少なくとも１つの送信機を備える持続的グルコースモニタシステムをさらに備え、上記少なくとも１つの送信機は、上記遠隔インターフェースと無線通信する、項目２０に記載の注入ポンプシステム。
（項目２２）
少なくとも１つの血中グルコースメータをさらに備え、上記血中グルコースメータは、上記遠隔インターフェースと無線通信する、項目２０に記載の注入ポンプシステム。
（項目２３）
上記少なくとも１つの再使用可能部分および上記遠隔インターフェースは、近距離通信を使用してペアリングされる、項目２０に記載の注入ポンプシステム。
（項目２４）
上記遠隔インターフェースは、少なくとも１つの加速度計をさらに備える、項目２０に記載の注入ポンプシステム。
（項目２５）
上記遠隔インターフェースは、少なくとも１つのカメラをさらに備える、項目２０に記載の注入ポンプシステム。

図１Ａは、注入ポンプのある実施形態の分解図である。図１Ｂは、注入ポンプのある実施形態の分解図である。図２は、注入ポンプおよび第２の再使用可能部分のある実施形態の分解図である。図３は、外部注入セットを示す、注入ポンプ使い捨て部分の一実施形態の斜視図である。図４Ａおよび４Ｂは、注入ポンプのある実施形態を描写する。図５Ａ−５Ｃは、注入ポンプのある実施形態を描写する。図５Ａ−５Ｃは、注入ポンプのある実施形態を描写する。図５Ａ−５Ｃは、注入ポンプのある実施形態を描写する。図５Ｄは、再使用可能部分のある実施形態の分解図である。図５Ｅは、再使用可能部分のある実施形態の分解図である。図５Ｆは、再使用可能部分のある実施形態の分解図である。図５Ｇ−５Ｉは、防塵カバーの一実施形態を示す。図５Ｇ−５Ｉは、防塵カバーの一実施形態を示す。図５Ｇ−５Ｉは、防塵カバーの一実施形態を示す。図６は、遠隔インターフェースのある実施形態の図である。図７は、遠隔インターフェースのある実施形態の図である。図７は、遠隔インターフェースのある実施形態の図である。図８は、システムのある実施形態の図である。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図８Ｂ−８Ｒは、システムのある実施形態の高レベル概略図および流れ図の種々の図を描写する。図９Ａは、本デバイスの一実施形態内に含まれ得る、マルチプロセッサ制御構成のある実施形態を図式的に描写する。図９Ｂは、いくつかの実施形態における、本デバイスの一実施形態内に含まれ得る、マルチプロセッサ制御構成のある実施形態を図式的に描写する。図１０Ａおよび１０Ｂは、マルチプロセッサ機能性の一実施形態を図式的に描写する。図１０Ａおよび１０Ｂは、マルチプロセッサ機能性の一実施形態を図式的に描写する。図１１は、マルチプロセッサ機能性の一実施形態を図式的に描写する。図１２は、マルチプロセッサ機能性の一実施形態を図式的に描写する。図１２Ａ−１２Ｅは、一実施形態による、種々のソフトウェア層を図式的に描写する。図１２Ａ−１２Ｅは、一実施形態による、種々のソフトウェア層を図式的に描写する。図１２Ａ−１２Ｅは、一実施形態による、種々のソフトウェア層を図式的に描写する。図１２Ａ−１２Ｅは、一実施形態による、種々のソフトウェア層を図式的に描写する。図１２Ａ−１２Ｅは、一実施形態による、種々のソフトウェア層を図式的に描写する。図１３は、システムの一実施形態の例証である。図１４は、システムの一実施形態の例証である。図１５Ａ−１５Ｂは、システムの一実施形態における、充電ステーションの一実施形態の例証である。図１６Ａ−１６Ｆは、システムの一実施形態による、バッテリ充電器／充電ステーションのある実施形態の種々の図を描写する。図１６Ａ−１６Ｆは、システムの一実施形態による、バッテリ充電器／充電ステーションのある実施形態の種々の図を描写する。図１６Ａ−１６Ｆは、システムの一実施形態による、バッテリ充電器／充電ステーションのある実施形態の種々の図を描写する。図１６Ａ−１６Ｆは、システムの一実施形態による、バッテリ充電器／充電ステーションのある実施形態の種々の図を描写する。図１６Ａ−１６Ｆは、システムの一実施形態による、バッテリ充電器／充電ステーションのある実施形態の種々の図を描写する。図１６Ａ−１６Ｆは、システムの一実施形態による、バッテリ充電器／充電ステーションのある実施形態の種々の図を描写する。図１７は、システムの種々の要素の相互接続の一実施形態を図式的に描写する。図１８は、システムの一実施形態の例証である。図１９は、システムの一実施形態の例証である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図２０Ａ−３０は、システムの一実施形態による、遠隔インターフェースの種々のスクリーンショットの実施形態である。図３１は、２Ｄバーコードのある実施形態である。図３２は、遠隔インターフェースおよび２Ｄバーコードを使用して、基礎プロファイルをプログラミングするためのシステムのある実施形態である。図３３は、２Ｄバーコード内に埋め込まれ得る、ある実施形態情報である。図３４は、カメラを使用して、遠隔インターフェースにプログラムされ得る、基礎プロファイルのある実施例である。

定義
本説明および付随の請求項に使用されるように、以下の用語は、文脈によって別様に要求されない限り、以下に示される意味を有するものとする。

「遠隔インターフェース」は、制限ではないが、医療デバイスを含み得る、デバイスと無線通信するためのデバイスを意味するものとする。

「デバイス」は、制限ではないが、医療デバイス（制限ではないが、注入ポンプおよび／またはマイクロ注入ポンプ、薬物送達ポンプおよび／または装置、センサ、測定デバイスおよび／または測定器、血圧モニタ、ＥＣＧモニタ、丸剤ディスペンサ、パルスオキシメトリモニタ、ＣＯ^２カプノメータ、点滴バッグ、滴下流メータ、温度モニタ、腹膜透析機械（制限されないが、自宅用腹膜透析機械を含む）、血液透析機械（制限されないが、自宅用血液透析機械を含む）、ならびに医療ケアを送達、取扱、および／または判定するように構成される、任意の他の医療デバイスまたはデバイスを含む）を含む、任意の医療デバイスを意味するものとする。

デバイスの「入力」は、デバイスおよび／または遠隔インターフェースのユーザおよび／または他のオペレータ／介護者が、デバイスおよび／または遠隔インターフェースの機能を制御し得る、任意の機構を含む。ユーザ入力は、機械的配列（例えば、スイッチ、プッシュボタン、ジョグホイール）、電気配列（例えば、スライダ、タッチスクリーン）、遠隔インターフェースと通信するための無線インターフェース（例えば、無線周波数（「ＲＦ」）、赤外線（「ＩＲ」）、ＢＬＵＥＴＯＯＴＨ（登録商標））、音響インターフェース（例えば、音声認識を伴う）、コンピュータネットワークインターフェース（例えば、ＵＳＢポート）、光／光波画像（制限されないが、カメラ入力および／またはカメラを使用して捕捉された画像を含む）、音波、および／または他のタイプのインターフェースを含んでもよい。

以下に論じられる、いわゆる「ボーラスボタン」等の入力の文脈における「ボタン」は、所望の機能を果たすことが可能である、任意のタイプのユーザ入力であってもよく、プッシュボタン、スライダ、スイッチ、タッチスクリーン、および／またはジョグホイールに制限されない。

「アラーム」は、警告が、ユーザおよび／または第三者／オペレータ／介護者に対して発生され得る、任意の機構を含む。アラームは、音声アラーム（例えば、スピーカ、ブザー、音声発生器）、視覚アラーム（例えば、ＬＥＤ、ＬＣＤ画面、画像）、触知アラーム（例えば、振動要素）、無線信号（例えば、遠隔インターフェースまたは介護者への無線伝送）、および／または他の機構を含んでもよい。アラームは、冗長機構（例えば、２つの異なるオーディオアラーム）または相補的機構（例えば、オーディオアラーム、触知アラーム、および無線アラーム）、および／または音量および／または強度を増加させる機構（例えば、漸増アラームシーケンス）を含む、同時に、並行して、またはシーケンスとして、複数の機構を使用して発生されてもよい。

「流体」は、流動ラインまたは流体ラインを通して流動可能な物質、例えば、液体を意味するものとする。

「ユーザ」は、医療治療の一部またはその他としてかにかかわらず、デバイスから治療を受容する、またはそれに接続される、人または動物、および／またはデバイスをプログラミングする、または別様にデバイスと相互作用し、治療を与える、および／または情報をデバイスから収集することに関与する、制限ではないが、医師および／または医療提供者および／または随伴者および／または両親および／または保護者を含み得る、介護者または第三者を含む。

「カニューレ」は、流体をユーザに注入可能な使い捨てデバイスを意味するものとする。カニューレは、本明細書で使用されるように、従来のカニューレ／可撓性チューブまたは針を指し得る。

「使い捨て」は、固定持続時間の間、使用され、次いで、廃棄および交換されることが意図される、部品、デバイス、部分、またはその他を指す。

「再使用可能」は、無制限の使用持続時間を有することが意図される、部分を指す。

「音響式体積測定」は、米国特許第５，３４９，８５２号および第５，６４１，８９２号、ならびに２００７年２月９日出願の米国特許出願第１１／７０４，８９９号「ＦｌｕｉｄＤｅｌｉｖｅｒｙＳｙｓｔｅｍｓａｎｄＭｅｔｈｏｄｓ」（２００７年１０月４日公開の現米国特許公報第ＵＳ−２００７−０２２８０７１−Ａ１号）（弁理士整理番号Ｅ７０）、および２００８年１２月３１日出願の米国特許出願第１２／３４７，９８５号「ＩｎｆｕｓｉｏｎＰｕｍｐＡｓｓｅｍｂｌｙ」（２００９年１２月３日公開の現米国特許公報第ＵＳ−２００９−０２９９２７７号）（弁理士整理番号Ｇ７５）（それぞれ、参照することによって、その全体として本明細書に組み込まれる）に説明されるもの等の音響式技法、ならびに他の技法を使用する、関連体積の定量的測定を意味するものとする。

本明細書に説明されるデバイス、方法、およびシステムの種々の実施形態の例示的使用は、糖尿病を患う人々へのインスリンの送達のためのものであるが、他の使用として、任意の流体の送達、任意の病状および／または状態の感知、および／または医療治療および／または医療ケアの提供が挙げられる。流体は、制限ではないが、疼痛に苦しむ人への鎮痛薬、癌患者への化学療法、および代謝障害に患う患者への酵素を含んでもよい。種々の治療薬流体は、制限ではないが、小分子、天然産物、ペプチド、タンパク質、核酸、炭水化物、ナノ粒子懸濁液、および関連付けられた薬学的容認可能担体分子を含んでもよい。療法的活性分子は、デバイスの安定性を改善するように修正されてもよい（例えば、ペプチドまたはタンパク質のペグ化によって）。本明細書の例証的実施形態は、薬物送達用途について説明するが、本実施形態は、ラボ・オン・チップ用途および毛細管クロマトグラフィ等の高処理量分析測定のための試薬の液体分注を含む、他の用途に使用されてもよい。以下の説明の目的のために、用語「治療薬」、「インスリン」、または「流体」は、同義的に使用されるが、しかしながら、他の実施形態では、前述のような任意の流体が、使用されてもよい。したがって、本明細書に含まれるデバイス、システム、方法、およびその説明は、治療薬との併用に制限されない。

デバイスのいくつかの実施形態は、糖尿病を患う人々および／またはその介護者によって使用するために適合される。したがって、これらの実施形態では、デバイス、方法およびシステムは、糖尿病に患う人々（ユーザと称される）の膵島ベータ細胞の作用を補完または置換する、インスリンを送達するように協働する。インスリン送達のために適合された実施形態は、流体送達の基礎レベルならびに流体送達のボーラスレベルの両方を提供することによって、膵島ベータ細胞の作用の置換を模索する。基礎レベル、ボーラスレベル、およびタイミングは、遠隔インターフェースユーザインターフェースを使用することによって、または直接、デバイス上のユーザインターフェースを使用することによって、ユーザによって設定されてもよい。加えて、基礎および／またはボーラスレベルは、例示的実施形態では、遠隔インターフェースと一体タイプである、または無線通信し得る、１つ以上のグルコースメータおよび／またはグルコースモニタ（すなわち、デバイス）の出力に応答して、トリガあるいは調節されてもよい。他の実施形態では、遠隔インターフェースは、制限ではないが、血液試料を受容する、および／または血液試料、例えば、血液グルコース細片を受容するように構成される、デバイスを受容する、血中グルコースメータ／デバイスを含み得る、１つ以上の検体監視デバイスを含んでもよい。いくつかの実施形態では、ボーラスは、デバイス上、すなわち、注入ポンプ上および／または遠隔インターフェース上に位置する、指定されたボタンまたは他の入力手段を使用して、ユーザによってトリガされてもよい。さらに他の実施形態では、ボーラスまたは基礎は、デバイス上（例えば、注入ポンプ上および／または遠隔インターフェース上）のいずれかに位置するユーザインターフェースを通して、プログラムまたは管理されてもよい。

種々の実施形態全体を通して、本明細書の画面および画面のタイプに与えられる名称ならびに種々の特徴に与えられる適切な名称に関して、これらの用語は、異なり得、かつ説明目的のためのものである。本説明は、これらの名称に制限されない。

本明細書に説明されるデバイス、システム、および方法は、注入ポンプを制御するために使用されてもよい。本説明の目的のために、ユーザインターフェースおよび注入ポンプの種々の実施形態は、インスリンポンプ、すなわち、インスリンを注入するポンプを参照して説明され得る。しかしながら、ユーザインターフェースは、注入ポンプ上にあってもよく、および／または遠隔インターフェースおよび遠隔インターフェースが通信する医療デバイスは、任意の医療デバイスであってもよく、すなわち、注入ポンプに制限されないことを理解されたい。加えて、説明が、注入ポンプ「画面」に関する場合、本「画面」はまた、遠隔インターフェース上に現れてもよく、または注入ポンプの代わりに、遠隔インターフェース上に現れてもよい。

本説明によって想定される注入ポンプは、制限されないが、治療薬流体（制限ではないが、インスリンを含む）を含む、任意の流体を圧送し得る、ポンプを含む。したがって、本説明が、インスリンに関する実施形態を説明する場合、これは、単に、説明目的のためだけに意味されるものであって、インスリンに制限されることを意図しない。他の流体もまた、想定される。いくつかの実施形態では、本明細書に説明される方法、システム、およびデバイスは、他の流体送達デバイス、例えば、当技術分野において公知のペンおよび／または注射器と併用されてもよい。

本明細書に説明されるデバイスを制御するためのシステムは、任意の１つ以上のデバイスのために使用されてもよく、いくつかの実施形態では、デバイスは、流体を送達し得る、および／またはカニューレを通してユーザに流体を送達するように構成され得る、注入ポンプおよび／または注入ポンプシステムを含んでもよい。説明目的のためだけに、少なくとも１つのインスリンポンプを含み得る、注入ポンプシステムが、本明細書に説明される。しかしながら、システムは、１つ以上の注入ポンプおよび／またはインスリンポンプシステムとの併用に制限されず、むしろ、任意のデバイスおよび／または任意の１つ以上のデバイスと併用されてもよい。

次に、図１Ａおよび１Ｂを参照すると、デバイス１００の一実施形態が、示される。デバイス１００は、例証的実施形態では、任意の注入ポンプであり得る、注入ポンプであるが、しかしながら、いくつかの実施形態では、２００７年１０月４日公開の米国公報第ＵＳ−２００７−０２２８０７１号（Ｅ７０）または２００９年１２月３日公開の米国公報第ＵＳ−２００９−０２９９２７７−Ａ１号（弁理士整理番号Ｇ７５）に図示および説明される、注入ポンプの実施形態のうちの１つであってもよい。しかしながら、上記で議論されるように、種々の他の実施形態では、デバイスは、任意の医療デバイスであってもよく、いくつかの実施形態では、１つ以上のデバイスが、システム内に含まれる。

デバイス１００は、再使用可能部分１０２および使い捨て部分１０４を含む。種々の実施形態では、使い捨て部分１０４は、リザーバおよび流体ライン、すなわち、注入ポンプの「湿潤」構成要素を含む。いくつかの実施形態では、使い捨て部分１０４は、タブ１１６を含む。

再使用可能部分１０２は、リザーバ内の流体を、リザーバから、カニューレ（図示されないが、図３に３０８として示される）に接続され得る、管類１０６に圧送させるように構成される、機械的および電気構成要素１０８を含む。いくつかの実施形態では、再使用可能部分１０２は、係止リングアセンブリ１１０と、係止リングアセンブリ１１０の回転を促進し得る、位置決め突起８０８とを含んでもよい。再使用可能部分１０２は、使い捨て部分１０４に取り外し可能に係合されてもよく、これは、例えば、制限されないが、螺着、捻転係止、または圧縮嵌合構成、または他の構成によってもたらされ得る。いくつかの実施形態では、再使用可能部分１０４は、使い捨て部分１０２に対して適切に位置付けられてもよく、係止リングアセンブリ１１０は、再使用可能部分１０４を使い捨て部分１０２に取り外し可能に係合させるように回転されてもよい。

加えて、例えば、使い捨て筐体アセンブリ１０４のタブ１１６に対する、突起１１２の位置は、再使用可能部分１０２が、使い捨て部分１０４と完全に係合されたことの検証を提供してもよい。例えば、図４Ａに示されるように、再使用可能部分４０２が、使い捨て部分１０４と適切に整合されると、突起４１２は、タブ４１６に対して、第１の位置に整合され得る。係止リングアセンブリ４１０の回転（図４Ａにおける矢印によって示される回転方向）によって、完全に係合された状態を達成すると、突起４１２は、図４Ｂに示されるように、タブ４１６に対して、第２の位置に整合され得る。

次に、また、図２を参照すると、システムのいくつかの実施形態では、システムは、１つ以上のデバイスを含んでもよく、いくつかの実施形態では、システムは、２つのデバイス２００、２０２を含んでもよい。システムのいくつかの実施形態では、システムは、２つの再使用可能部分２００、２０２および少なくとも１つの使い捨て部分２０４を含んでもよい。再使用可能部分２００、２０２および使い捨て部分２０４は、いくつかの実施形態では、前述のデバイス１００の実施形態であってもよい。システムのいくつかの実施形態では、システムは、それぞれ、再充電可能電力デバイス、例えば、再充電可能バッテリを含み得る、２つの再使用可能部分２００、２０２を含んでもよい。したがって、いくつかの実施形態では、一方の再使用可能部分２００は、使い捨て部分２０４に接続され、ユーザによって使用されるが、他方の再使用可能部分２０２は、再充電されてもよい。したがって、いくつかの実施形態では、システムは、他のデバイスが使用中、再充電または点検され得る、バックアップデバイスを含んでもよい。

また、図３を参照すると、いくつかの実施形態では、使い捨て部分３００は、管類３０２に接続されたオス型コネクタ３０４を含み得る、管類３０２を含む。オス型コネクタ３０４は、いくつかの実施形態では、メス型コネクタ３０６に接続されるように構成される。オス型コネクタ３０４とメス型コネクタ３０６の想定される接続は、管類３０２からカニューレ３０８、したがって、リザーバからカニューレへの流体路を提供する。カニューレ３０８は、カニューレ接着剤パッド３１０によって、ユーザ上の定位置に保持されてもよい。管類３０２、オス型コネクタ３０４、メス型コネクタ３０６、カニューレ３０８、およびカニューレ接着剤パッド３１０は、集合的に、注入セット３１２と称されてもよい。いくつかの実施形態では、再使用可能部分３００は、いくつかの実施形態では、例えば、使い捨て接着パッチ（使い捨て部分３００の下側表面に接続され、接着剤が、暴露され、次いで、ユーザに取着され得る）または面ファスナーパッチであり得る、パッチ３１４によって、ユーザ上に保持されてもよい。使い捨てパッチが、面ファスナーパッチ（例えば、ＶＥＬＣＲＯＵＳＡＩｎｃ．（Ｍａｎｃｈｅｓｔｅｒ，ＮＨ）によって提供される面ファスナーシステム等）である実施形態では、使い捨て部分３００の下側表面は、相補的フックまたはループ表面を含んでもよい。

次に、また、図５Ａ−５Ｆを参照すると、いくつかの実施形態では、再使用可能部分５００は、ユーザコマンド（例えば、ボーラス送達の場合、遠隔インターフェースとのペアリングまたは同等物）を受信するように構成される、入力スイッチアセンブリを含んでもよい。入力スイッチアセンブリは、いくつかの実施形態では、本体５２０の開口部５２６内に配置され得る、ボタン８２４を含んでもよい。示されるように、例えば、図５Ｂでは、係止リングアセンブリ５０６は、係止リングアセンブリ５０６が、本体５２０に対して回転されることを可能にするように構成され得る一方、依然として、ボタン５２４への容易なアクセスを提供する、半径方向スロット５２８を含んでもよい。

依然として、図５Ａ−５Ｆを参照すると、電気制御アセンブリ５１６は、印刷回路基板５３０と、いくつかの実施形態では、再充電可能バッテリであり得る、バッテリ５３２とを含んでもよい。印刷回路基板５３０は、圧送済みおよび／または圧送中の注入可能流体の量を監視ならびに制御するための種々の制御電子機器を含んでもよい。例えば、電気制御アセンブリ５１６は、分注されたばかりの注入可能流体の量を測定し、ユーザによって要求された用量に基づいて、十分な注入可能流体が分注されたかどうか判定してもよい。十分な注入可能流体が分注されていない場合、電気制御アセンブリ５１６は、より多くの注入可能流体が圧送されるべきであることを判定し得る。電気制御アセンブリ５１６は、任意の付加的必要用量が圧送され得るように、適切な信号を機械的制御アセンブリ５１２に提供してもよく、または電気制御アセンブリ５１６は、付加的用量が次の用量とともに分注され得るように、適切な信号を機械的制御アセンブリ５１２に提供してもよい。代替として、多過ぎる注入可能流体が分注された場合、電気制御アセンブリ５１６は、より少ない注入可能流体が次の用量において分注され得るように、適切な信号を機械的制御アセンブリ５１２に提供してもよい。電気制御アセンブリ５１６は、１つ以上のマイクロプロセッサを含んでもよい。例示的実施形態では、電気制御アセンブリ５１６は、３つのマイクロプロセッサを含んでもよい。１つのプロセッサ（例えば、制限ではないが、ＣｈｉｐｃｏｎＡＳ（Ｏｓｌｏ，Ｎｏｒｗａｙ）から利用可能なＣＣ２５１０マイクロコントローラ／無線周波数（「ＲＦ」）送受信機を含んでもよい）は、遠隔インターフェースと通信するための無線通信専用であってもよい。２つの付加的マイクロプロセッサ（その実施例として、制限ではないが、ＴｅｘａｓＩｎｓｔｒｕｍｅｎｔｓＩｎｃ．（Ｄａｌｌａｓ，Ｔｅｘａｓ）から利用可能なＭＳＰ４３０マイクロ遠隔インターフェースが挙げられ得る）は、コマンドの発行および実施専用であってもよい（例えば、ある用量の注入可能流体を分注するため、体積測定デバイスからのフィードバック信号を処理するため、および同等物）。

図５Ｃに示されるように、ベースプレート５１８は、例えば、再充電可能バッテリ５３２のための電気制御アセンブリ５１６に電気的に連結され得る、電気接点５３４へのアクセスを提供してもよい。ベースプレート５１８は、使い捨て筐体アセンブリ５０４の協働特徴（例えば、タブ）を介して、使い捨て筐体アセンブリ５０４との適切な整合を促進するように構成され得る、１つ以上の特徴（例えば、開口部５３６、５３８）を含んでもよい。加えて、ベースプレート５１８は、弁アセンブリ５１４および電気制御アセンブリ５１６を搭載するため、ならびに弁アセンブリ５１４（図５Ｄ−５Ｆに示される）によって使い捨て部分５０４へのアクセスを提供するための種々の特徴を含んでもよい。

係止リングアセンブリ５０６は、例えば、再使用可能部分５００および使い捨て部分５０４を係合／係脱させるために、係止リングアセンブリ５０６の把持ならびに捻転を促進し得る、例えば、エラストマーまたはテクスチャ加工された材料を含み得る、グリップインサート５４０、５４２を含んでもよい。加えて、係止リングアセンブリ５０６は、いくつかの実施形態では、磁石５４４であり得るが、他の実施形態では、電気接点または他の感知構成要素であり得る、１つ以上の感知構成要素を含んでもよい。種々の実施形態では、感知構成要素は、再使用可能部分５００の１つ以上の構成要素（例えば、ホール効果センサ）と相互作用し、例えば、噛合構成要素（例えば、いくつかの実施形態では、制限ではないが、使い捨て部分５０４、充電ステーション、または充填ステーションのうちの１つ以上を含んでもよい）の性質、および／または再使用可能部分５００が噛合構成要素と係合適切に係合されているかどうかの表示を提供してもよい。いくつかの実施形態では、ホール効果センサ（図示せず）は、ポンプ印刷回路基板５３０上に位置してもよい。ホール効果センサは、係止リングアセンブリ５０６が、閉鎖位置に回転されると、それを検出してもよい。したがって、いくつかの実施形態では、ホール効果センサは、磁石５４４とともに、係止リングアセンブリ５０６が閉鎖位置に回転されたかどうかを判定するためのシステムを提供してもよい。

感知構成要素（磁石）５４４は、再使用可能部分構成要素、すなわち、いくつかの実施形態では、ホール効果センサとともに、再使用可能部分５００が、意図された構成要素またはデバイスに適切に取着されたかどうかの判定を提供するように協働してもよい。いくつかの実施形態では、係止リングアセンブリ５０６は、制限ではないが、使い捨て部分５０４、防塵カバー（図示せず）、またはバッテリ充電器（図示せず）を含み得る、構成要素に取着されていない場合、旋回しなくてもよい。したがって、感知構成要素５４４は、再使用可能部分５００とともに、多くの有利な安全性特徴を注入ポンプシステムに提供するように機能し得る。これらの特徴は、制限ではないが、以下のうちの１つ以上を含んでもよい。システムが、使い捨て部分５０４、防塵カバー、または充電器に取着されていることを検出しない場合、システムは、ユーザに、再使用可能部分５００、例えば、弁および圧送構成要素が、汚染または破損を被り得、再使用可能アセンブリの完全性を損なわせ得ることを通知、警告、またはアラームしてもよい。したがって、システムは、ユーザに、潜在的再使用可能完全性の脅威を警告するための完全性アラームを提供し得る。また、システムが、再使用可能アセンブリが防塵カバーに取着されていることを感知する場合、システムは、電源をオフにする、または電力を低減し、電力を節約してもよい。これは、再使用可能部分が、相互作用する必要がある構成可能に接続していない場合、電力のより効率的使用を提供し得る。

再使用可能部分５００は、使い捨て筐体アセンブリ、防塵カバー、またはバッテリ充電器／バッテリ充電ステーションを含むが、それらに制限されない、いくつかの異なる構成要素に取着してもよい。いずれの場合も、ホール効果センサは、係止リングアセンブリ５０６が、閉鎖位置にある、したがって、再使用可能部分５００が、使い捨て部分５０４、防塵カバー、またはバッテリ充電器／バッテリ充電ステーション（または、種々の実施形態では、別の構成要素）に取り外し可能に係合されていることを検出してもよい。注入ポンプシステムは、前述の参照された特許公報および特許に説明されるもの等のＡＶＳシステムを使用することによって、または電子接点によって、そこに取着されている構成要素を判定してもよい。次に、また、図５Ｇ−５Ｉを参照すると、防塵カバー（例えば、防塵カバー５３９）の一実施形態が、示される。例示的実施形態では、防塵カバー５３９は、再使用可能部分５００の係止リングアセンブリ５０６が、防塵カバー５３９に取り外し可能に係合し得るように、特徴５４１、５４３、５４５、５４７を含んでもよい。加えて、防塵カバー５３９はさらに、再使用可能部分５００の弁作用および圧送特徴を収容するための陥凹領域５８４９を含んでもよい。例えば、防塵カバーに関して、ＡＶＳシステムは、使い捨て部分ではなく、防塵カバーが、再使用可能部分に接続されていることを判定してもよい。ＡＶＳシステムは、ルックアップテーブルまたは他の比較データを使用して、測定データと特徴的防塵カバーまたは空の使い捨て部分のデータを比較して、区別してもよい。バッテリ充電器に関して、バッテリ充電器は、いくつかの実施形態では、電気接点を含んでもよい。再使用可能部分が、バッテリ充電器に取着されると、注入ポンプアセンブリ電子システムは、接触が行なわれたことを感知し得、したがって、再使用可能部分が、バッテリ充電器に取着されていることを示すであろう。

注入ポンプの種々の実施形態は、注入可能流体を含有するように構成される、リザーバアセンブリを含んでもよい、またはそれに類似してもよい。いくつかの実施形態では、リザーバアセンブリは、２００９年３月３日発行の米国特許第７，４９８，５６３号「ＯｐｔｉｃａｌＤｉｓｐｌａｃｅｍｅｎｔＳｅｎｓｏｒｆｏｒＩｎｆｕｓｉｏｎＤｅｖｉｃｅｓ」（弁理士整理番号Ｄ７８）（参照することによって、全体として本明細書に組み込まれる）、および／または２００７年１２月１１日発行の米国特許第７，３０６，５７８号「ＬｏａｄｉｎｇＭｅｃｈａｎｉｓｍｆｏｒＩｎｆｕｓｉｏｎＰｕｍｐ」（弁理士整理番号Ｃ５４）、２００９年１０月９日出願のＰＣＴ出願第ＰＣＴ／ＵＳ２００９／０６０１５８号「ＩｎｆｕｓｉｏｎＰｕｍｐＡｓｓｅｍｂｌｙ」（２０１０年４月１５日公開の現公報第ＷＯ２０１０／０４２８１４号）（弁理士整理番号Ｆ５１ＷＯ）、および／または２００８年１０月１０日出願の米国特許出願第１２／２４９，８８２号「ＩｎｆｕｓｉｏｎＰｕｍｐＡｓｓｅｍｂｌｙ」（２０１０年４月１５日公開の現米国特許公報第ＵＳ−２０１０−００９４２２２号）（弁理士整理番号Ｆ５１）、および／または２０１１年３月３０日出願の米国特許出願第１３／０７６，０６７号「ＩｎｆｕｓｉｏｎＰｕｍｐＭｅｔｈｏｄｓ，ＳｙｓｔｅｍｓａｎｄＡｐｐａｒａｔｕｓ」（２０１１年９月２２日公開の現米国特許公報第ＵＳ−２０１１−０２３０８３７号（弁理士整理番号Ｉ７０）、および／または２０１１年３月３０日出願の米国特許出願第１３／１２１，８２２号「ＩｎｆｕｓｉｏｎＰｕｍｐＡｓｓｅｍｂｌｙ」（２０１１年８月２５日公開の現米国特許公報第ＵＳ−２０１１−０２０８１２３号）（弁理士整理番号Ｉ７３）（全て、参照することによって、その全体として本明細書に組み込まれる）に説明されるものに類似するリザーバアセンブリであってもよい。

いくつかの実施形態では、注入ポンプの種々の実施形態は２００７年１２月１１日発行の米国特許第７，３０６，５７８号「ＬｏａｄｉｎｇＭｅｃｈａｎｉｓｍｆｏｒＩｎｆｕｓｉｏｎＰｕｍｐ」（弁理士整理番号Ｃ５４）、２００８年１０月１０日出願の米国特許出願第１２／２４９，８８２号「ＩｎｆｕｓｉｏｎＰｕｍｐＡｓｓｅｍｂｌｙ」、（２０１０年４月１５日公開の現米国特許公報第ＵＳ−２０１０−００９４２２２号）（弁理士整理番号Ｆ５１）、および２００８年１０月１０日出願の米国特許出願第１２／２４９，８９１号「ＩｎｆｕｓｉｏｎＰｕｍｐＡｓｓｅｍｂｌｙ」（２００９年４月１６日公開の現米国特許公報第ＵＳ−２００９−００９９５２３号）（弁理士整理番号Ｇ４６）（全て、参照することによって、その全体として本明細書に組み込まれる）に説明される１つ以上を含んでもよい、またはそれらに類似してもよい。

いくつかの実施形態では、いくつかの実施形態では、前述のもの等の注入ポンプであり得る、デバイスは、遠隔インターフェースとワイヤレス無線周波数（「ＲＦ」）通信するためのハードウェアを含む。しかしながら、種々の実施形態では、デバイスは、任意のデバイスであってもよく、注入ポンプに制限されない。システムのいくつかの例示的実施形態では、デバイスは、制限ではないが、ユーザへの視覚表示を含む、少なくとも１つの画面または他のディスプレイのうちの１つ以上を含み得る、ディスプレイアセンブリを含んでもよい。しかしながら、図１Ａ−５Ｆに示されるもの等、他の実施形態では、デバイスは、ディスプレイアセンブリを含まなくてもよい。これらの実施形態では、ディスプレイアセンブリは、遠隔インターフェース上に含まれてもよい。システムのいくつかの実施形態では、デバイスが、ディスプレイを含む場合でも、システムは、ディスプレイもまた含む、遠隔インターフェースを含んでもよい。遠隔インターフェースのいくつかの実施形態が、図６、７、７Ａ、および８に示される。

図１Ａ−５Ｉに示される注入ポンプシステムだけではなく、また、システムと併用され得る、他のデバイスも参照すると、デバイスは、デバイスが動作するために要求され得る１つ以上のプロセスを実行する、１つ以上のプロセッサと称され得る、処理論理（図示せず）を含んでもよい。処理論理は、１つ以上のマイクロプロセッサ（図示せず）、１つ以上の入力／出力遠隔インターフェース（図示せず）、およびキャッシュメモリデバイス（図示せず）を含んでもよい。１つ以上のデータバスおよび／またはメモリバスは、１つ以上のサブシステムとの処理論理を相互接続するために使用されてもよい。

システムが、ユーザとデバイスとの間の相互作用を要求する場合、相互作用は、遠隔インターフェース上またはデバイス上のいずれかにおいて、入力を使用して達成されてもよく、例えば、いくつかの実施形態では、デバイスが、注入ポンプである場合、デバイス上の入力は、注入ポンプ上のスイッチアセンブリであってもよい。

処理論理は、いくつかの実施形態では、入力をユーザから受信するために使用される。ユーザは、ボタン／スイッチアセンブリ、スライダアセンブリ、制限されないが、容量スライダ（例えば、２００７年１２月４日出願の米国特許出願第１１／９９９，２６８号「ＭｅｄｉｃａｌＤｅｖｉｃｅＩｎｃｌｕｄｉｎｇａＳｌｉｄｅｒＡｓｓｅｍｂｌｙ」（２００８年７月２４日公開の現米国特許公報第ＵＳ−２００８−０１７７９００号）（弁理士整理番号Ｆ１４）（参照することによって、全体として本明細書に組み込まれる）に説明される任意のスライダを含むが、それらに制限されないものを含み得る）、ジョグホイール、オーディオ入力、触知入力、および／またはタッチスクリーンうちの１つ以上を含むが、それらに制限されない、１つ以上の入力デバイスまたはアセンブリを使用してもよい。いくつかの実施形態では、デバイスは、加えて、入力を内部システムから受信してもよい。これらの内部システムは、例えば、デバイスが注入ポンプである実施形態では、制限ではないが、閉塞検出プロセス、確認プロセス、および体積測定技術、例えば、音響体積感知（「ＡＶＳ」）うちの１つ以上を含んでもよい。これらの入力を使用して、いくつかの実施形態では、注入ポンプであり得る、デバイスは、出力、例えば、制限されないが、ユーザへの注入流体送達を含む、出力を生成してもよく、および／またはこれらの入力は、制限ではないが、ユーザへのコメント、警告、アラーム、または警報のうちの１つ以上を含み得る、出力を生成してもよい。入力は、したがって、直接、ユーザからデバイス、直接、デバイスシステムから処理論理、または別のデバイスまたは遠隔インターフェースからデバイスのいずれかに行なわれる。ユーザ相互作用経験は、したがって、制限ではないが、ディスプレイ上でのテキストおよび／またはグラフィックの読取／視認を含む、ディスプレイ（デバイス自体または遠隔インターフェースまたは両方のいずれか上）との相互作用、例えば、タッチスクリーンを通したディスプレイとの直接相互作用、１つ以上のボタン、スライダ、ジョグホイール、または他の入力との相互作用、１つ以上のグルコース細片リーダとの相互作用、ならびに触覚または聴覚、１つ以上の振動モータ、および／またはオーディオシステムのいずれかを通した感知のうちの１つ以上を含むが、それらに限定されない。したがって、用語「ユーザインターフェース」は、ユーザが、デバイスと相互作用し、デバイスからの情報を制御および／または受信するために使用される、システム、方法、およびデバイスの全てを包含するために使用される。

次に、図６および７Ａ−７Ｂを参照すると、注入ポンプシステムのいくつかの実施形態では、注入ポンプは、遠隔インターフェース６００、７００を使用して、遠隔で制御されてもよい。遠隔インターフェースの２つの実施形態が、示されるが、しかしながら、種々の他の実施形態では、遠隔インターフェースは、無線および／または遠隔通信を介してを含む、デバイスと相互作用可能な任意のタイプのデバイスであってもよい。遠隔インターフェース６００、７００は、いくつかの実施形態では、図１Ａ−５Ｉに関して本明細書に図示および説明されるものに類似する注入ポンプを含み得る、デバイスの機能性の全部または一部を含んでもよい。上記で議論されるように、説明の目的のために、デバイスは、注入ポンプとして説明され得るが、しかしながら、本開示は、注入ポンプに制限されない。また、本明細書に説明されるシステム、方法、および装置は、任意のデバイスと併用されてもよい。

前述の注入ポンプのいくつかの実施形態では、注入ポンプは、遠隔インターフェース６００、７００を使用して構成されてもよい。これらの実施形態では、注入ポンプは、注入ポンプと遠隔インターフェース６００、７００との間の通信（例えば、有線または無線）
を可能にし、したがって、遠隔インターフェース６００、７００が、注入ポンプを遠隔で制御することを可能にする、テレメトリ回路（図示せず）を含んでもよい。遠隔インターフェース６００、７００（また、テレメトリ回路（図示せず）を含み得、かつ注入ポンプと通信可能であり得る）は、ディスプレイアセンブリ６０２、７０２と、入力制御デバイス（ジョグホイール６０６、スライダアセンブリ６１０、またはデバイスへの入力のための別の従来のモード等）、および／またはスイッチアセンブリ６０４、６０８、７０４のうちの１つ以上を含み得る、少なくとも１つの入力アセンブリとを含んでもよい。したがって、遠隔インターフェース６００は、図６に示されるように、ジョグホイール６０６およびスライダアセンブリ６１０を含むが、いくつかの実施形態は、ジョグホイール６０６またはスライダアセンブリ６１０のいずれかの１つのみ、あるいはデバイスへの入力のための別の従来のモードを含んでもよい。ジョグホイール６０６を有する実施形態では、ジョグホイール６０６は、少なくとも部分的に、ホイール、リング、ノブ、または同等物の移動に基づいて、制御信号を提供するために、回転式エンコーダまたは他の回転式変換器に連結され得る、ホイール、リング、ノブ、または同等物を含んでもよい。

いくつかの実施形態では、遠隔インターフェースはタッチスクリーンを含んでもよく、そのような実施形態では、図７Ａおよび７Ｂに描写されるように、タッチスクリーンは、遠隔インターフェース７００の機能を示す、１つ以上のアイコン７０６、７１０を含んでもよい。いくつかの実施形態では、１つ以上のアイコン７０６、７１０は、デバイスと通信するように構成される、起動アプリケーションに関連してもよい。図７Ａに示されるように、いくつかの実施形態では、１つ以上のアイコン７０６は、いくつかの実施形態では、医療デバイス（例えば、医療デバイス１、医療デバイス２、医療デバイス３）アプリケーションであり得る、１つ以上のデバイスを示してもよい。しかしながら、種々の実施形態では、３つ未満または４つ以上のアイコン７０６が、遠隔インターフェース７００上に含まれてもよい。また、図７Ａに示されるように、いくつかの実施形態では、遠隔インターフェース７００は、遠隔インターフェース７００の別の機能性に関連する起動アプリケーションに関連するアイコン７１０を含んでもよい（少なくとも１つのデバイスとの通信に加えて）。いくつかの実施形態では、これらとして、制限ではないが、ウェブブラウザの起動、携帯電話または携帯電話機能性の起動、および／またはＭＰ３または他の「オーディオ」プレーヤ機能性の起動が挙げられ得る。いくつかの実施形態では、ユーザが、遠隔インターフェース７００の種々の機能および／またはアプリケーションを「起動」することが望ましくあり得る。いくつかの実施形態では、非デバイス関連機能性は、起動されるまで、休止状態であってもよく、および／または「スリープ」させてもよい。これは、制限されないが、バッテリ寿命の延長、および／または１つ以上のデバイスと通信するための遠隔インターフェース７００の使用に関して、混乱の防止および／または動作の減速を含む、多くの理由から望ましくあり得る。いくつかの実施形態では、デバイスが、遠隔インターフェース７００とペアリングされると（以下により詳細に説明されるように）、アプリケーションは、自動的に、起動されてもよい。いくつかの実施形態では、遠隔インターフェース７００上のデバイスに関するアイコン７０６は、「アプリケーション」が、ディスプレイ７０２上で「最小化」されているが、アプリケーションが、アクティブであることを示してもよい。したがって、いくつかの実施形態では、アイコン７０６を使用したデバイスに関連するアプリケーションの起動は、必要でなくてもよく、遠隔インターフェース７００が、デバイスとペアリングされると、自動化されてもよい。図７Ｂを参照すると、いくつかの実施形態では、遠隔インターフェース７００は、ディスプレイアセンブリ上に、メモおよび／またはタグをログブックに追加するためのリンクである、種々のボタンを含んでもよい。したがって、いくつかの実施形態では、ユーザが、ボタンの１つを
タップすると、メモが、開かれもよく、ユーザは、メモをログブックに追加してもよい。いくつかの実施形態では、アイコンのタップは、自動的に、その事象をログブック内に登録してもよい。

遠隔インターフェースの種々の実施形態は、基礎比率、ボーラスアラーム、送達制限、ユーザプロファイル等を事前にプログラムする能力を含み、ユーザが、履歴、ログブック等を閲覧し、ユーザ選好を確立することを可能にしてもよい。いくつかの実施形態では、遠隔インターフェースはまた、グルコース細片リーダを含んでもよい。しかしながら、種々の実施形態では、遠隔インターフェースが、注入ポンプではなく、他のデバイスと通信する場合、遠隔インターフェースの能力は、異なってもよい。

使用時、いくつかの実施形態では、遠隔インターフェース６００、７００は、遠隔インターフェース６００、７００と注入ポンプとの間に確立される無線通信チャネルを使用して、注入ポンプアセンブリと通信してもよい。故に、ユーザは、遠隔インターフェース６００、７００を使用して、注入ポンプをプログラム／構成してもよい。いくつかの実施形態では、遠隔インターフェース６００、７００と注入ポンプとの間の通信の一部または全部は、向上されたレベルのセキュリティを提供するように、暗号化されてもよい。

ユーザインターフェースの種々の実施形態では、ユーザインターフェースは、ユーザ確認および／またはユーザ入力を要求してもよい。いくつかの実施形態では、ユーザインターフェースは、デバイスとの種々の相互作用の効果を把握することを確実にすることに焦点が当てられる。多くの実施例は、ユーザにユーザの作用の結果を通信するデバイスの本説明全体を通して提示されるであろう。これらの特徴は、ユーザが、その作用を理解していることを確実にし、したがって、ユーザにさらなる安全性をもたらす。そのような実施例の１つは、ユーザが、値が変化した後、画面上の戻るボタンを押下する場合、ユーザインターフェースが、「変更を取り消しますか？」とういう確認画面を表示させることである。ユーザが、「はい」を選択する場合、種々の実施形態では、ユーザインターフェースは、任意の保留中の変更を廃棄し、確認画面を閉じ、前の画面（すなわち、ユーザが戻るボタンを押下した画面の前の画面）に戻る。作用選択が、「変更を取り消しますか？」確認画面上において、「いいえ」であるとき、ユーザは、実施形態に応じて、改行ボタンまたはその他を押下し、ユーザインターフェースは、確認画面を閉じ、保留中の変更を伴う画面に戻る。本特徴は、ユーザが、変更が実装されたと仮定するが、実際は、そうではないという結果を防止する。したがって、本特徴は、そのような状況を防止し、ユーザが、変更が実装されていないことを理解することを確実にする。これは、ユーザ確認および／または入力を要求するユーザインターフェースの多くの実施例のうちの１つにすぎない。

加えて、また、図８を参照すると、デバイスのいくつかの実施形態では、デバイス８００は、遠隔インターフェース８０２によって構成されてもよい。いくつかの実施形態では、デバイス８００は、デバイス８００と少なくとも１つの遠隔インターフェース８０２との間の通信（例えば、有線または無線）を可能にし、したがって、遠隔インターフェース８０２が、デバイス８００と遠隔で通信することを可能にする、テレメトリ回路（図示せず）を含んでもよい。遠隔インターフェース８０２（また、テレメトリ回路（図示せず）を含み、デバイス８００と通信可能であってもよい）は、種々の実施形態では、ディスプレイアセンブリ８０４および少なくとも１つの入力アセンブリ８０６を含んでもよい。入力アセンブリ８０６は、いくつかの実施形態では、少なくとも１つのスイッチアセンブリを含んでもよく、いくつかの実施形態では、制限ではないが、前述の入力アセンブリのうちの１つ以上のいずれかを含んでもよい。したがって、いくつかの実施形態では、入力アセンブリは、ジョグホイール、複数のスイッチアセンブリ、容量スライダ、または同等物を含んでもよい。

遠隔インターフェース８０２は、デバイスに命令する、および／または情報をデバイスから受信する能力を含んでもよい。いくつかの実施形態では、遠隔インターフェース８０２は、履歴を閲覧し、アラームを受信および閲覧し、制限、例えば、送達制限をプログラムし、および／またはユーザ選好を確立するための能力を含んでもよい。いくつかの実施形態では、遠隔インターフェース８０２は、ユーザが、電力状態、送達状態、読み取られた値、アラーム状態、デバイスの進捗度、および／またはデバイスから遠隔インターフェース８０２に通信され得る、任意の他のデータを含み得る、デバイスの状態を閲覧することを可能にしてもよい。いくつかの実施形態では、遠隔インターフェース８０２は、グルコース細片リーダおよび／または温度表示デバイス、および／または治療および／または診断を行なう、および／または医療サービスをユーザに提供するために所望され得る、他の医療機能性を含んでもよい。

いくつかの実施形態では、遠隔インターフェース８０２は、遠隔インターフェース８０２とデバイス８００との間に確立された無線通信チャネル８０８を介して、指示をデバイス８００に提供してもよい。故に、ユーザは、遠隔インターフェース８０２を使用して、デバイス８００をプログラム／構成してもよい。遠隔インターフェース８０２とデバイスとの間の通信の一部または全部は、向上されたレベルのセキュリティを提供するために、暗号化されてもよい。

遠隔インターフェース８０２とデバイス８００との間の通信は、標準通信プロトコルを利用して達成されてもよい。さらに、デバイス８００内に含まれる種々の構成要素の間の通信が、同じプロトコルを使用して達成されてもよい。そのような通信プロトコルの一例は、ＤＥＫＡＲｅｓｅａｒｃｈ＆Ｄｅｖｅｌｏｐｍｅｎｔ（Ｍａｎｃｈｅｓｔｅｒ，ＮＨ）によって開発されたＰａｃｋｅｔＣｏｍｍｕｎｉｃａｔｉｏｎＧａｔｅｗａｙＰｒｏｔｏｃｏｌ（ＰＣＧＰ）である。上記で議論されるように、いくつかの実施形態では、注入ポンプであり得る、デバイス８００は、１つ以上の電気構成要素を含み得る、電気制御アセンブリ５１６を含んでもよい。例えば、電気制御アセンブリ５１６は、複数のデータプロセッサ（例えば、スーパーバイザプロセッサおよびコマンドプロセッサ）と、デバイス８００が遠隔インターフェース８０２と通信することを可能にするための無線プロセッサとを含んでもよい。したがって、遠隔インターフェース８０２は、１つ以上の電気構成要素を含んでもよく、その実施例として、遠隔インターフェース８０２がデバイス８００と通信することを可能にするためのコマンドプロセッサおよび無線プロセッサが挙げられ得るが、それらに制限されない。そのようなシステムの一例の高レベル線図が、図８Ｂに示される。

これらの電気構成要素のそれぞれは、異なる構成要素の提供業者から製造されてもよく、したがって、固有の（すなわち、一意の）通信コマンドを利用してもよい。したがって、標準通信プロトコルの使用を通して、そのような異種構成要素間の効率的な通信が達成されてもよい。

ＰＣＧＰは、パケットを構築し、ルーティングするために、デバイス８００および遠隔インターフェース８０２内のプロセッサ上で使用されてもよい、融通性のある拡張可能なソフトウェアモジュールであってもよい。ＰＣＧＰは、種々のインターフェースを抽象化してもよく、各プロセッサ上で実行されている種々のアプリケーションに統一アプリケーションプログラミングインターフェース（ＡＰＩ）を提供してもよい。ＰＣＧＰはまた、種々のドライバに適応インターフェースを提供してもよい。例証的目的のみで、ＰＣＧＰは、所与のプロセッサについて図８Ｃに図示された概念構造を有してもよい。

ＰＣＧＰは、周期的冗長検査（ＣＲＣ）を利用することによって、データ完全性を確保してもよい。ＰＣＧＰはまた、保証された送達状態を提供してもよい。非制限的実施例として、全ての新規メッセージが返信を有するべきである。そのような返信が時間内に返送されない場合、メッセージがタイムアウトしてもよく、ＰＣＧＰがアプリケーションに対する否定応答返信メッセージ（すなわち、ＮＡＣＫ）を生成してもよい。したがって、メッセージ返信プロトコルは、アプリケーションがメッセージの送信を再試行すべきかどうかをアプリケーションに知らせてもよい。

いくつかの実施形態では、ＰＣＧＰはまた、所与のノードからのインフライトメッセージの数を制限してもよく、メッセージ送達に決定論的手法を提供するように、ドライバレベルで流量制御機構と連結されてもよく、パケットをドロップすることなく、個々のノードに異なる分量のバッファを持たせてもよい。ノードにバッファがなくなると、ドライバは、他のノードに背圧を提供し、新規メッセージの送信を防止してもよい。

ＰＣＧＰは、データコピーを最小限化するために、共有バッファプール方式を使用してもよく、かつ相互排除を回避してもよく、これは、アプリケーションへのメッセージを送信／受信するために使用されるＡＰＩにはわずかに影響を及ぼし、ドライバにはさらに大きな影響を及ぼし得る。ＰＣＧＰは、ルーティングおよびバッファ所有権を提供する、「ブリッジ」ベースクラスを使用してもよい。主要なＰＣＧＰクラスは、ブリッジベースクラスから下位分類されてもよい。いくつかの実施形態では、ドライバは、ブリッジクラスから導出されるか、または導出ブリッジクラスと通信するか、あるいはそれを所有してもよい。

いくつかの実施形態では、ＰＣＧＰは、いくつかの呼び出しが再入可能であり、複数スレッド上で作動することができるように、共有データを保護するためにセマフォを使用することによって、オペレーティングシステムの有無を問わず、埋め込み環境で稼働するように設計されてもよい。そのような実装の１つの非制限的例証的実施例の１つが、図８Ｄに示される。ＰＣＧＰは、両方の環境で同じ方法で動作してもよいが、特定のプロセッサタイプ（例えば、ＡＲＭ９／ＯＳバージョン）に対する呼び出しのバージョンがあってもよい。したがって、いくつかの実施形態では、機能性は同じであってもよいが、例えば、ＡＲＭ９ＮｕｃｌｅｕｓＯＳ環境に合せた、わずかに異なる呼び出しを伴うオペレーティングシステム抽象化層があってもよい。

図８Ｅも参照すると、ＰＣＧＰは、以下を行ってもよい。
・複数の送信／返信呼び出しが生じることを可能にする
・異なるインターフェース上のＲＸおよびＴＸについて非同期的に作動する複数のドライバを有する、および／または
・送信／受信のためのパケット順序付け、およびメッセージ送信の決定論的タイムアウトを提供する

いくつかの実施形態では、各ソフトウェアオブジェクトは、使用する次のバッファをバッファマネジャに求めてもよく、次いで、そのバッファを別のオブジェクトに与えてもよい。バッファは、ある独占オーナから別のオーナに自動的に渡ってもよく、キューは、シーケンス番号別にバッファを順序付けることによって、自動的に発生してもよい。いくつかの実施形態では、バッファがもはや使用されていないときは、バッファはリサイクルされてもよい（例えば、オブジェクトが、バッファを自身に与えようとするか、または後で再割り当てするようにバッファマネジャに対して解放する）。したがって、いくつかの実施形態では、データは、概して、コピーされる必要がなく、ルーティングは、単純にバッファオーナバイトを上書きする。

ＰＣＧＰのそのような実装は、種々の有益性を提供し得、その実施例は、以下を含み得るが、それらに制限されない。
・メッセージがバッファに入ると、アプリケーションによって転送または受信されるまでメッセージがそこで存続し得るため、バッファの欠如によるメッセージのドロップが不可能であり得る。
・ドライバ、ＰＣＧＰ、およびバッファのペイロードセクションにアクセスするためにオフセットが使用されるため、データがコピーされなくてもよい。
・ドライバは、１バイト（すなわち、バッファ所有権バイト）を上書きすることによって、メッセージデータの所有権を交換してもよい。
・単一のバッファオーナがバッファを同時に使用すること、または新規シーケンス番号を獲得することを望み得るときだけに、相互排除が必要とされ得るため、再入可能呼び出しを除く複数の排除の必要性がなくてもよい。
・アプリケーションライターが信頼性のあるシステムを実装するように従うためのルールがより少なくあり得る。
・ドライバからバッファ管理システムの外へデータをプッシュ／プルするように提供された、一式の呼び出しがあるため、ドライバは、ＩＳＲ／プッシュ／プル／およびポーリングしたデータモデルを使用してもよい。
・ドライバがコピー、ＣＲＣ、または何らかのチェックを行わなくてもよいが、宛先バイトおよびＣＲＣならびに他のチェックが後でＩＳＲホットパスから行われ得るため、ドライバは、ＴＸおよびＲＸ以外、ほとんど稼働しなくてもよい。
・バッファマネジャがシーケンス番号別にアクセスを順序付け得るため、キューの順序付けが自動的に生じ得る。
・小さなコード／可変専有エリアが利用されてもよい、すなわち、ホットパスコードが小さくてもよく、オーバーヘッドが低くなり得る。

図８Ｆに示されるように、メッセージを送信する必要があるときに、ＰＣＧＰは、迅速にパケットを構築してもよく、それをバッファ管理システムに挿入してもよい。バッファ管理システムの中に入ると、「ｐａｃｋｅｔＰｒｏｃｅｓｓｏｒ」への呼び出しは、プロトコルの規則を適用してもよく、ドライバ／アプリケーションにメッセージを与えてもよい。

新規メッセージを送信する、または返信を送信するために、ＰＣＧＰは、以下のうちの１つ以上を行なってもよい。
・例えば、パケット長が合法であること、宛先が正しいこと等を確認するように、呼び出し引数をチェックする。
・ダウンリンクが、リンク、ペア等を確立するためにＰＣＧＰが無線プロセッサによって使用されることを可能にしてもよい、およびＰＣＧＰが（タイムアウトする代わりに）機能していないリンク上で通信しようとしているときにアプリケーションに通知してもよい、いくつかの実施形態では、無線リンクでない限り、ダウンしているリンク上でメッセージを送信しようとすることを回避する。
・新規メッセージのシーケンス番号を取得する、または既存のメッセージの既存のシーケンス番号を利用する。
・パケットを構築し、ペイロードデータをコピーし、ＣＲＣに書き込み、（この時点以降）パケットの完全性がＣＲＣによって保護されてもよい。および／または
・返信または新規メッセージとして、メッセージをバッファマネジャに与え、このバッファをバッファマネジャに入れることが、待機状態の送信メッセージの最大数を超えるかどうかを確かめる。

また、図８Ｇ−８Ｈを参照すると、いくつかの実施形態では、相互排除を回避するように、および送信／返信またはドライバ呼び出しに多大な作業を行うことを回避するように、１つのスレッドに主要な作業の全てを行うことによって、ＰＣＧＰが稼働してもよい。「ｐａｃｋｅｔＰｒｏｃｅｓｓｏｒ」呼び出しは、返信、新規送信メッセージ、および受信メッセージにプロトコル規則を適用する必要があってもよい。返信メッセージは、単純に送られてもよいが、新規メッセージおよび受信メッセージには、メッセージを送るための規則があってもよい。それぞれの場合において、ソフトウェアは、パケットを処理することができなくなるまで、正しい種類のメッセージがプロトコル規則を適用することが可能である間に、ループしてもよい。

新規メッセージの送信は、いくつかの実施形態では、以下の規則のうちの１つ以上に従ってもよい。
・２つだけのメッセージが、ネットワーク上の許可された「インフライト」であってもよい。および／または
・応答に一致し、タイムアウトに対処するように、インフライトメッセージに関する十分なデータが記憶されてもよい。
メッセージの受信は、以下の規則に従ってもよい。
・一致する応答が「インフライト」情報スロットをクリアしてもよいため、新規パケットを送信することができる。
・一致しない応答がドロップされてもよい。
・新規メッセージは、プロトコルに対するものであってもよい（例えば、このノードに対するネットワーク統計を取得／クリアする）。
・メッセージを受信するために、バッファがアプリケーションに与えられてもよく、コールバックを使用してもよい。および／または
・バッファが解放されるか、またはアプリケーションによって所有されたままであってもよい。
したがって、いくつかの実施形態では、ＰＣＧＰは、以下のように構成されてもよい。
コールバック機能は、ペイロードデータアウトをコピーしてもよく、または戻る前にそれを完全に使用してもよい。
・コールバック機能は、戻る前にそれを完全に行うまたは使用するペイロードデータをコピーしてもよい。
・コールバック機能は、バッファを所有してもよく、バッファおよびペイロードアドレスによるバッファのペイロードを参照してもよく、メッセージは、後で処理されてもよい。
・アプリケーションは、受信したメッセージについてＰＣＧＰシステムをポーリングしてもよい、および／または
・アプリケーションは、事象を設定するためにコールバックを使用し、次いで、受信メッセージについてポーリングしてもよい。

通信システムは、制限数のバファを有してもよい。ＰＣＧＰにバッファがなくなると、ドライバは、新規パケットを受信することを止めてよく、アプリケーションは、アプリケーションが新規パケットを送信できないことを告げられてもよい。このことを回避し、最適な性能を維持するために、アプリケーションは、１つ以上の手順を行おうとしてもよく、その例は、以下を含み得るが、それらに制限されない。ａ）アプリケーションは、ＰＣＧＰを無線状態で最新の状態に保ってもよい。具体的には、いくつかの実施形態では、リンクがダウンし、ＰＣＧＰが認識していない場合、ＰＣＧＰは、送信する新規メッセージを受け取り、待ち行列に入れてもよく（または、最適にメッセージをタイムアウトしなくてもよい）、これは、送信キューを妨害し、リンクを最適に使用することからアプリケーションを遅延させる場合がある。ｂ）アプリケーションは、「タイムアウトをデクリメントする」を定期的に呼び出してもよい。最適には、いくつかの実施形態では、アプリケーションは、プロセッサがスリープしていない限り、２０〜１００ミリ秒ごとに、「タイムアウトをデクリメントする」を呼び出してもよい。一般に、メッセージは、速く移動する（数ミリ秒）、遅く移動する（数秒）、または全く移動しない。タイムアウトは、いくつかの実施形態では、バッファおよび帯域幅を解放するようにドロップされるべきである「インフライト」メッセージを除去しようとする試行である。これをあまり頻繁に行わないと、新規メッセージが送信されるとき、またはアプリケーションが新規メッセージを待ち行列に入れるときを遅延させる場合がある。
ｃ）アプリケーションは、スリープに入る前に保留中の行うべき作業があるかどうかをＰＣＧＰに尋ねてもよい。したがって、いくつかの実施形態では、ＰＣＧＰに行うべき作業がない場合、ドライバアクティビティがシステム、ひいては、ＰＣＧＰをウェークアップしてもよく、したがって、新規パケットがシステムに進入するまで、ＰＣＧＰは、「ｐａｃｋｅｔＰｒｏｃｅｓｓｏｒ」または「タイムアウトをデクリメントする」への呼び出しを必要としない。いくつかの実施形態では、これを行うことに失敗すると、タイムアウト状態により、送信／転送／受信が成功するはずだったメッセージがドロップされる場合がある。
ｄ）アプリケーションは、受信メッセージを無期限に持ち続けるべきではない。メッセージシステムは迅速な返信に依存する。アプリケーションがＰＣＧＰバッファを共有していれば、メッセージを持ち続けることは、ＰＣＧＰバッファを持ち続けることを意味する。いくつかの実施形態では、受信ノードの受信は、送信ノードに、低速または高速無線通信のために構成されたタイムアウトがあるかどうかを認識していない。このことは、ノードがメッセージの受信に応じて、ネットワークの高速タイムアウト速度を測定するべきであることを意味する。および／または
ｅ）アプリケーションは、「ｐａｃｋｅｔＰｒｏｃｅｓｓｏｒ」を頻繁に呼び出してもよい。いくつかの実施形態では、呼び出しは、アプリケーションによって待ち行列に入れられた新規メッセージを送信させてもよく、新規メッセージの受信に対処してもよい。呼び出しはまた、バッファを再割り当てさせてもよく、あまり頻繁に呼び出さないと、メッセージトラフィックを遅延させる場合がある。

図８Ｉに示されるように、いくつかの実施形態では、ある時点で、ＲＸドライバは、インターフェースの反対側からメッセージを受信するように求められてもよい。いくつかの実施形態では、メッセージがドロップされないことを確実にするために、ＲＸドライバは、新規メッセージを記憶するために利用可能なバッファがあるかどうかをバッファマネジャに尋ねてもよい。次いで、ドライバは、バッファポインタを求めてもよく、受信データでバッファを充填し始めてもよい。完全なメッセージが受信されると、ＲＸドライバは、パケットをルーティングする機能を呼び出してもよい。ルーティング機能は、パケットヘッダにおける宛先バイトを検査してもよく、いくつかの実施形態では、以下のうちの１つ以上を行なう：他のドライバおよび／またはアプリケーションにオーナを変更してもよく、および／またはパケットが不良であることを検出してもよく、かつバッファを解放することによってパケットをドロップしてもよい。

ＰＣＧＰＲＸオーバーヘッドは、次の利用可能なバッファを求めること、およびルート機能を呼び出すことから成ってもよい。そのような機能を果たすコードの非制限的実施例は、以下の通りである。
＠Ｒｅｃｅｉｖｅｒｅｑｕｅｓｔ
ｕｉｎｔ８ｉ＝０，＊ｐ；
ｉｆ（Ｂｒｉｄｇｅ：：ｃａｎＲｅｃｅｉｖｅＦｌｏｗＣｏｎｔｒｏｌ（））
｛
ｐ＝Ｂｒｉｄｇｅ：：ｎｅｘｔＢｕｆｆｅｒＲＸ（）；
ｗｈｉｌｅ（ｎｏｔｄｏｎｅ）｛ｐ［ｉ］＝ｔｈｅｎｅｘｔｂｙｔｅ；｝
Ｂｒｉｄｇｅ：：ｒｏｕｔｅ（ｐ）；
｝

ドライバは、次の送信するバッファへのポインタをバッファマネジャに求めることによって、ＴＸを行ってもよい。次いで、ＴＸドライバは、パケットを受け取ることができるかどうかをインターフェースの反対側に尋ねてもよい。反対側がパケットを拒否する場合、ＴＸドライバは、その状態が変化していないため、バッファに何もしなくてもよい。そうでない場合、ドライバは、パケットを送信してもよく、かつバッファをリサイクル／解放してもよい。そのような機能を果たすコードの非制限的実施例は、以下の通りである。
ｕｉｎｔ８＊ｐ＝Ｂｒｉｄｇｅ：：ｎｅｘｔＢｕｆｆｅｒＴＸ（）；
ｉｆ（ｐ！＝（ｕｉｎｔ８＊）０）
｛
ｓｅｎｄｔｈｅｂｕｆｆｅｒｐ；
Ｂｒｉｄｇｅ：：ｒｅｃｙｃｌｅ（ｐ）；
｝

最大メッセージシステムタイムアウト時間を超えたパケットを転送することを回避するために、いくつかの実施形態では、ｎｅｘｔＢｕｆｆｅｒを求めることにより、解放するバッファをスキャンし得る、ＢｕｆｆｅｒＭａｎａｇｅｒ：：ｆｉｒｓｔ（ｕｉｎｔ８ｏｗｎｅｒ）関数を呼び出してもよい。したがって、タイムアウトの可能性がない完全ＴＸバッファは、バッファを所有するスレッド上で解放されてもよい。いくつかの実施形態では、ＴＸを行っている（すなわち、次のＴＸバッファを探しながら）ブリッジは、処理のために次のＴＸバッファを受信する前に期限切れになるＴＸバッファの全てを解放してもよい。

図８Ｊ−８Ｌに示されるように、いくつかの実施形態では、バッファ割り当てプロセス中に、使用可能とマークされたバッファは、新規パケットを受信するようにドライバへ、またはＴＸに対する新規ペイロードを受信するようにＰＣＧＰに転送されてもよい。「使用可能」からの割り当ては、「ｐａｃｋｅｔＰｒｏｃｅｓｓｏｒ」機能によって行われてもよい。「ｐａｃｋｅｔＰｒｏｃｅｓｓｏｒ」呼び出しの間の送信および受信の数は、いくつのＬＴ＿Ｄｒｉｖｅｒ＿ＲＸ、ＧＴ＿Ｄｒｉｖｅｒ＿ＲＸ、およびＰＣＧＰ＿Ｆｒｅｅバッファを割り当てる必要があるかを決定してもよい。ＬＴ＿Ｄｒｉｖｅｒは、ノードアドレスよりも少ないアドレスを取り扱うドライバを表してもよい。ＧＴ＿Ｄｒｉｖｅｒは、ノードアドレスよりも多いアドレスを取り扱うドライバを表してもよい。

ドライバがパケットを受信すると、ドライバは、ルータに渡されるＲＸバッファにデータを入れてもよい。次いで、ルータは、バッファをＰＣＧＰ＿Ｒｅｃｅｉｖｅまたは他のドライバのＴＸ（図示せず）に再割り当てしてもよい。バッファが明らかに無効なデータを含有する場合、バッファは使用可能状態に移行してもよい。

ルータがＴＸに対するバッファをマークした後、ドライバは、バッファがＴＸであることを発見してもよく、かつメッセージを送信してもよい。メッセージを送信した後、ドライバにＲＸバッファが不足していれば、バッファは即座にＲＸバッファになってもよく、または、バッファが再割り当てのために解放されてもよい。

「ｐａｃｋｅｔＰｒｏｃｅｓｓｏｒ」呼び出し中、ＰＣＧＰは、ルータがＰＣＧＰ＿Ｒｅｃｅｉｖｅとしてマークした全てのバッファを処理してもよい。この時点で、データが作用を受けてもよいため、ＣＲＣおよび他のデータアイテムがチェックされてもよい。データが破損されていれば、統計値がインクリメントされてもよく、バッファが解放されてもよい。そうでない場合、バッファは、アプリケーションによって所有されているとマークされてもよい。アプリケーションによって所有されているとマークされたバッファは、ＰＣＧＰの使用のためにリサイクルされるか、またはバッファマネジャによる再割り当てのために解放されてもよい。

いくつかの実施形態では、アプリケーションが新規メッセージを送信したいときは、再入可能な分かりやすい／相互排除様式で行われてもよい。バッファが割り当てられてもよい場合、ＰＣＧＰは、バッファを使用中とマークしてもよい。使用中とマークされると、送信または返信機能の呼び出しの発動によって所有されているため、この機能を呼び出す他のスレッドのいずれも、このバッファを捕らえてはいけない。誤差チェックを行い、メッセージを作成するプロセスの残りは、孤立競合状態相互排除保護コードの外側で行われてもよい。バッファは、使用可能状態に遷移してもよく、または、有効な充填したＣＲＣチェックされたバッファになり、ルータに渡されてもよい。いくつかの実施形態では、これらのバッファは、即座に送られなくてもよく、後でメッセージを送ることができるように待ち行列に入れられてもよい（プロトコル規則が許容すると仮定する）。返信メッセージが通常の送信メッセージよりも高い優先度で送られてもよく、返信メッセージには、いくつ／いつ送ることができるかを制限する規則がなくてもよいため、返信メッセージは、新規送信メッセージとは異なってマークされてもよい。

いくつかの実施形態では、ＰＣＧＰは、流量制御と協働し、流量制御は、インターフェースの反対側にバッファが欠けている（これが送信ノード上で背圧を引き起こす場合がある）ため、バッファが決してドロップされないように、１つのノードから別のノードへのメッセージの転送について交渉してもよい。

流量制御は、共有バッファ形式の一部であってもよい。いくつかの実施形態では、最初の２バイトは、ドライバが決してパケットバイトをシフトする必要がないように、ドライバのために留保されてもよい。２バイトは、１バイトがＤＭＡ長−１であり、第２のバイトがメッセージの流れを制御するものであるように、使用されてもよい。これらの同じ２バイトは、ＰＣＧＰメッセージがＲＳ２３２上で伝送される場合に、バイトを同期化してもよい。種々の他の構成およびサイズが、種々の実施形態では、使用されてもよい。

いくつかの実施形態では、パケットが「インフライト」であるときに、パケットは、その宛先の途中でドライバによって送信される、宛先によって処理される、または応答として返送されるプロセスにあってもよい。
典型的な遅延は、以下の通りである。

したがって、いくつかの実施形態では、メッセージは、往復を迅速に完了する（例えば、＜５０ｍｓ）、ゆっくりと完了する（例えば、１秒以上）、または全く完了しない傾向がある。

種々の実施形態では、ＰＣＧＰは、全てのタイムアウトに２つの異なる時間（初期化において設定される）を使用してもよく、１つは、ＲＦリンクが高速ハートビートモードであるときに対するもので、もう１つは、ＲＦリンクが低速モードであるときに対するものである。しかしながら、他の実施形態では、ＰＣＧＰは、３つ以上または２つ未満の異なる時間を使用してもよい。いくつかの実施形態では、メッセージがインフライトであり、リンク状態が高速から低速に変化する場合、タイムアウトが調整されてもよく、高速と低速との間の差が、パケットに対する有効期限カウンタに追加されてもよい。前後への付加的な遷移のいずれも、メッセージに対する有効期限に影響を及ぼしてはいけない。

いくつかの実施形態では、ＰＣＧＰ内のバッファ割り当てを監視するために使用される、低速タイムアウトの２倍の長さであり得る、第２のタイムアウトがある。したがって、例えば、流量制御またはハードウェア破損により、メッセージがドライバ内に「取り残され」、送信されていない場合、バッファは、バッファマネジャによって解放されてもよく、バッファをドロップさせる。「新規」メッセージについては、これは、パケットがすでにタイムアウトし、メッセージが送達されなかったという返信がすでにアプリケーションに与えられたことを意味してもよく、バッファを解放させる。ドライバが、送信される必要のあるバッファに対するバッファマネジャをポーリングするため、次に障害物を取り除くときに、送信することができるメッセージがドライバに渡されるように、バッファが解放される。返信メッセージについては、返信が単純にドロップされてもよく、送信ノードがタイムアウトしてもよい。

いくつかの実施形態では、ＰＣＧＰメッセージングシステムは、ヘッダ情報およびペイロードを含有するメッセージをパスしてもよい。しかしながら、種々の実施形態では、ＰＣＧＰメッセージングシステムは、異なる情報を含有するメッセージをパスしてもよい。ＰＣＧＰの外側では、ヘッダは、呼び出し署名の中の一式のデータアイテムであってもよい。いくつかの実施形態では、しかしながら、ＰＣＧＰ内部には、一貫したドライバが使用しやすいバイトレイアウトがあってもよい。いくつかの実施形態では、ドライバは、以下のように、ＰＣＧＰパケットの中に、またはＰＣＧＰパケットの前にバイトを挿入してもよい。
・ＤＥ、ＣＡ：ＲＳ２３２とともに使用するための同期バイトで、０ｘＤＥ、０ｘＣＡまたは０ｘ５Ａ、０ｘＡ５の公称値。
・ＬＤ：ドライバＤＭＡ長バイトで、サイズバイトまたは同期バイトを含まない合計サイズである、このＤＭＡ転送においてドライバがプッシュ配信している量に等しい。
・Ｃｍｄ：流量制御のために使用される、ドライバコマンドおよび制御バイト。
・ＬＰ：ＰＣＧＰパケット長で、常に、バイト＋ＣＲＣサイズにおいて合計ヘッダ＋ペイロードサイズである。ＬＤ＝ＬＰ＋１である。
・Ｄｓｔ：宛先アドレス。
・Ｓｒｃ：ソースアドレス。
・Ｃｍｄ：コマンドバイト。
・Ｓｃｄ：サブコマンドバイト。
・ＡＴ：アプリケーションタグは、アプリケーションによって定義され、ＰＣＧＰにとって重要性を持たない。これは、アプリケーションが、メッセージに、例えば、メッセージの起源となったスレッド等、さらなる情報を添付することを可能にする。
・ＳｅｑＮｕｍ：３２ビットのシーケンス番号が、送信された新規メッセージに対してＰＣＧＰによってインクリメントされ、番号が切り上げられず、トークンの役割を果たし、エンディアンネスが無関係であることを保証する。
・ＣＲＣ１６：ＰＣＧＰヘッダおよびペイロードの１６ビットＣＲＣ。

ペイロードがなく、ｃｍｄ＝１、ｓｕｂｃｍｄ＝２であるメッセージの例は、以下の通りである。
０ｘＤＥ，０ｘＣＡ，０ｘＣ，０ｘ５，０ｘ１４，１，２，０，０，０，０，０ｘ１，ｃｒｃｈｉｇｈ，ｃｒｃｌｏｗ．
０ｘ０Ｄ，ｃｍｄ，０ｘＣ，０ｘ５，０ｘ１４，１，２，０，０，０，０，０ｘ１，ｃｒｃｈｉｇｈ，ｃｒｃｌｏｗ．
この方法論には、いくつかの利点があり得、その例は、以下を含み得るが、それらに制限されない。
・種々の実施形態では、ハードウェアＤＭＡエンジンの大部分は、いくつの追加バイトを動かすのかを定義するために、第１のバイトを使用してもよく、したがって、この方法論では、ドライバおよびＰＣＧＰは、バッファを共有してもよい。
・ドライバ間で流量制御情報を渡すように、ＤＭＡ長の直後にバイトが提供されてもよい。
・ドライバ長および「Ｃｍｄ」バイトがＣＲＣ領域の外側にあり得るため、それらは、ドライバによって改変されてもよく、ドライバ輸送機構によって所有されてもよく、ドライバは、無効な長さについて警戒してもよい。
・ＣＲＣ保護される、別個のＰＧＣＰパケット長バイトがあってもよい。したがって、アプリケーションは、そのペイロード長が正しいことを信頼してもよい。
・シーケンス番号のエンディアンネスは、同様に、偶然３２ビットの整数である、一致させられ得るバイトパターンすぎないため、関連性がなくてもよい。
・シーケンス番号は、共有バッファプール長の縁に整列した、４バイトであってもよい。
・メッセージストリームをデバッグしながら、ユーザがケーブルをあちこちに動かしてもよく、インターフェースの両側が再同期化してもよいように、オプションのＲＳ２３２同期バイトがあってもよい。
・アプリケーション、ドライバ、およびＰＣＧＰは、バッファを共有してもよく、それらをポインタによって解放してもよい。

いくつかの実施形態では、ＰＣＧＰは、事象駆動タイプソフトウェア設計でなくてもよいが、サブクラスが書き込まれる方法によって、事象駆動タイプアーキテクチャで使用されてもよい。データは、（図８Ｍ−８Ｎに示されるように）概念的にクラス間で交換されてもよい。

いくつかの実施形態では、ドライバにおけるいくつかの事象モデルは、ドライバをウェークしてもよく、メッセージを受信してもよく、（ドライバまたはＰＣＧＰへのブリッジを通して）新規メッセージの新規オーナにメッセージを送るバッファマネジャの中へ、ブリッジを通してメッセージを渡してもよい。

以下は、いくつかの例示的事象を要約する。

以下の例示的実施例は、全ての送信されたメッセージ、返信、またはＮＡＣＫを生成したｄｅｃタイムアウトの後に、ＰＣＧＰタスクをウェークアップするように、どのようにＰＣＧＰ事象モデルがＮｕｃｌｅｕｓと連動し得るかを示す。
ｃｌａｓｓＰｃｇｐＯＳ：ｐｕｂｌｉｃＰｃｇｐ
｛
ｖｉｒｔｕａｌｖｏｉｄｓｃｈｅｄｕｌｅＰａｃｋｅｔＰｒｏｃｅｓｓｏｒ（ｖｏｉｄ）
｛
ＯＳ＿ＥｖｅｎｔＧｒｐ＿Ｓｅｔ（ｇ＿ＲＣＶＥｖＧｒｐｓ［ＥＶＧ＿ＲＦ＿ＴＡＳＫ］．ｐＥｖｇＨａｎｄｌｅ，
ＲｆＲａｄｉｏＴｘＥｖｅｎｔ，ＯＳ＿ＥＶ＿ＯＲ＿ＮＯ＿ＣＬＥＡＲ）；
｝
｝

以下は、ドライバ事象がどのように稼働するかを例証する、事象ベースの疑似コードドライバである。ＤｒｉｖｅｒがＢｒｉｄｇｅを下位分類し、ｈａｓＭｅｓｓａｇｅｓＴｏＳｅｎｄおよびｆｌｏｗＣｏｎｔｒｏｌＴｕｍｅｄＯｆｆを無効にして、ＴＸおよびＲＸ機能がすでに作動していない場合、それらを作動するように予定する。
ｃｌａｓｓＳＰＩ＿Ｄｒｉｖｅｒ：ｐｕｂｌｉｃＢｒｉｄｇｅ
｛
ｖｉｒｔｕａｌｖｏｉｄｈａｓＭｅｓｓａｇｅｓＴｏＳｅｎｄ（）
｛
Ｔｒｉｇｇｅｒ＿ＩＳＲ（ＴＸ＿ＩＳＲ，ｔｈｉｓ）；
｝
ｖｉｒｔｕａｌｖｏｉｄｆｌｏｗＣｏｎｔｒｏｌＴｕｒｎｅｄＯｆｆ（）
｛
Ｔｒｉｇｇｅｒ＿ＩＳＲ（ＲＸ＿ＩＳＲ，ｔｈｉｓ）；
｝
ｓｔａｔｉｃｖｏｉｄＴＸ＿ＲｅｔｒｙＴｉｍｅｒ（）
｛
Ｔｒｉｇｇｅｒ＿ＩＳＲ（ＴＸ＿ＩＳＲ，ｔｈｉｓ）；
｝
ｓｔａｔｉｃｖｏｉｄＴＸ＿ＩＳＲ（Ｂｒｉｄｇｅ ^＊ｂ）
｛
ＤｉｓａｂｌｅＩＳＲｓ（）；
ｄｏ
｛
ｕｉｎｔ８ ^＊ｐ＝ｂ−＞ｎｅｘｔＢｕｆｆｅｒＴＸ（）；
ｉｆ（ｐ＝＝ｎｕｌｌ）ｂｒｅａｋ；
ｉｆ（ｂ−＞＿ｂｕｆｆｅｒＭａｎａｇｅｒ−＞ｂｕｆｆｅｒＴｉｍｅｄＯｕｔ（ｐ
）＝＝ｆａｌｓｅ）
｛
ｉｆ（ＯｔｈｅｒＳｉｄｅＳＰＩ＿ＦｌｏｗＣｏｎｔｒｏｌ（）＝＝ｆａｌｓｅ
）
｛
ＴｒｉｇｇｅｒＴＸ＿ＲｅｔｒｙＴｉｍｅｒｉｎ２０ｍｓｅｃ．
ｂｒｅａｋ；
｝
ｓｅｎｄ（ｐ）；
｝
ｆｒｅｅ（ｐ）；
｝ｗｈｉｌｅ（ｔｒｕｅ）；
ＥｎａｂｌｅＩＳＲｓ（）；
｝
ｓｔａｔｉｃｖｏｉｄＲＸ＿ＩＳＲ（Ｂｒｉｄｇｅ ^＊ｂ）
｛
ＤｉｓａｂｌｅＩＳＲｓ（）；
ｄｏ
｛
ｕｉｎｔ８^＊ｐ＝ｂ−＞ｎｅｘｔＢｕｆｆｅｒＲＸ（）；
ｉｆ（ｐ＝＝ｎｕｌｌ）ｂｒｅａｋ；
ｕｉｎｔｉ；
ｗｈｉｌｅ（ｎｏｔｄｏｎｅｒｅｃｅｉｖｉｎｇ）
ｐ［ｉ＋＋］＝ｇｅｔＣｈａｒ（）；
ｂ−＞ｒｏｕｔｅ（ｐ）；
｝ｗｈｉｌｅ（ｔｒｕｅ）；
ＥｎａｂｌｅＩＳＲｓ（）；
｝
｝

制限されないが、１つ以上の統計が、ＰＣＧＰによってサポートされてもよい。
・送信されたパケットの数
・受信されたパケットの数
・ＣＲＣ誤差
・タイムアウト
・利用不可能なバッファ（バッファがなくなった）

種々の実施形態では、ＰＣＧＰは、複数の処理環境中で作動するように設計されてもよい。ほとんどのパラメータは、試験、および性能のランタイム微調整を促進するため、ランタイム構成されてもよい。他のパラメータは、コンパイル時間であってもよく、例えば、コンパイル時間において静的に行われなければならないメモリ割り当てを改変する、あらゆるものであってもよいが、依然として、その他のパラメータが、種々の実施形態では使用されてもよい。

以下は、ＰＣＧＰが実装される場所を変動させ得る、コンパイル時間構成の数の定義であり得る。
・ドライババイト数：ドライバに対する共通バッファスキームに留保される、２バイトであってもよいが、いくつかの実施形態では、これは、ＲＦプロトコル等の他のドライバに適応するコンパイル時間オプションであってもよい。
・ＲＸドライババッファ数：そのプロセッサ／トラッフィクフロー等に所望されるバッファの数に同調されてもよい。
・ＰＣＧＰＲＸバッファ数：そのプロセッサ／トラッフィクフロー等に所望されるバッファの数に同調されてもよい。
・バッファの総数：そのプロセッサに所望されるバッファの数に同調されてもよい。

いくつかの実施形態では、ＣＲＣは、データ完全性を確保するために使用されてもよい。いくつかの実施形態では、ＣＲＣが無効であれば、それはアプリケーションに送達されなくてもよく、ＣＲＣ誤差が追跡されてもよい。メッセージは、最終的にタイムアウトしてもよく、発信元によって再試行されてもよい。

同様に、メッセージが送達されなかったときに送達されたとメッセージングシステムがアプリケーションに知らせる場合、これは、システムにとって望ましくあり得ない。ボーラス停止コマンドが、そのようなコマンドの実施例である。これは、治療法を変更するためにアプリケーションによって必要とされ得る、メッセージの要求／アクションシーケンスによって軽減され得る。いくつかの実施形態では、遠隔インターフェース８０２は、デバイス８００アプリケーションからマッチングコマンドを受信し、送達されたメッセージを検討してもよい。

いくつかの実施形態では、（図８Ｏに示されるように）ＡＲＭ９上のＮｕｃｌｅｕｓＯＳシステムにＰＣＧＰをインターフェース接続する参照方法を使用してもよい。

図８Ｐに示されるように、ｐｃｇｐＯＳ．ｃｐｐファイルは、ＰＣＧＰノードインスタンス（Ｐｃｇｐ、Ｂｒｉｄｇｅ等）のインスタンスを作成してもよく、Ｃ＋＋コードに「Ｃ」言語インターフェースを提供する、「Ｃ」リンク可能な一式の関数呼び出しを、ｐｃｇｐＯＳ．ｈを通して提供してもよい。これは、作用を受けるオブジェクトとしての「Ｃ」コードが暗示的であることを単純化し得る。
いくつかの実施形態では、以下の一般規則が適用されてもよい。
・ＰＣＧＰは、全てのノード上で作動してもよい。任意のドライバが、一般的ドライバインターフェースをサポートしてもよい。
・競合状態が許容されなくてもよい。
・スレーブプロセッサとマスタプロセッサとの間のＳＰＩポート上で半二重をサポートしてもよい。
・成功するか、または失敗／偽を戻すため、データ転送が試行されなくてもよい。
・低オーバーヘッド（浪費された時間、処理、帯域幅）を必要としてもよい。
・ＤＭＡ（高速）ＳＰＩクロック比率で動作するＣＣ２５１０をサポートしてもよい。

いくつかの実施形態では、受信側に、パケットを配置するための空のバッファが現在ない場合、ＳＰＩ流量制御は、データが送信されることを防止してもよい。いくつかの実施形態では、これは、送信する許可を求め、そうする許可が与えられたことを示す応答を待機することによって、達成されてもよい。いくつかの実施形態では、別の方法が、現在空いたバッファがなく、後で転送を試行するべきであると相手側に示すために使用されてもよい。

いくつかの実施形態では、全ての伝送は、長さバイト自体を含まない、送信されるバイトの数を示す長さバイトで開始してもよい。長さに続くのは、送信されているコマンドを示す単一バイトであってもよい。

いくつかの実施形態では、パケットの実際の伝送は、コマンドバイトについては、パケットの長さプラス１であってもよく、それに続いて、添付されたメッセージに対するコマンドバイト、最終的にパケット自体がある。しかしながら、他の実施形態では、パケットの伝送は、異なってもよい。

送信されるコマンドバイトに加えて、流量制御ラインと呼ばれる追加ハードウェアラインが、従来の４つのＳＰＩ信号に追加されてもよい。本ラインは、事前設定された遅延なしで、可能な限り迅速にプロトコルが作動することを可能にするために使用されてもよい。それはまた、送信されるのを待機しているパケットがあることを、スレーブプロセッサがマスタプロセッサに伝えることを可能にし、したがって、マスタプロセッサが状態についてスレーブプロセッサにポーリングする必要性を排除する。

以下の例示的コマンド値が、いくつかの実施形態では、使用されてもよい。
マスタプロセッサによって送信されるコマンド：

スレーブプロセッサによって送信されるコマンド：

図８Ｑに図示されるように、スレーブプロセッサが、マスタプロセッサに送信するパケットを有するとき、スレーブプロセッサは、送信されるのを待機している保留中のパケットがあることを、（例えば、流量制御ラインをアサートすることによって）マスタプロセッサに通知してもよい。そうすることにより、マスタプロセッサ上のＩＲＱをもたらしてもよく、その時点で、マスタプロセッサが、スレーブプロセッサからメッセージを回収するときを決定してもよい。パケットの回収は、マスタプロセッサの判断で遅延させられてもよく、マスタプロセッサは、スレーブプロセッサから回収する前に、スレーブプロセッサへのパケットの送信を試行することを決定してもよい。

いくつかの実施形態では、マスタプロセッサは、スレーブプロセッサＭ＿ＣＴＳコマンドを送信することによって、回収を開始してもよい。これは、いくつかの実施形態では、パケット自体とともにＳ＿ＭＳＧ＿ＡＰＰＥＮＤＥＤコマンドを送信することによって、スレーブプロセッサが応答するまで、反復されるものである。流量制御ラインは、パケットが送信された後に解除されてもよい。予期しないときに、Ｍ＿ＣＴＳコマンドがスレーブプロセッサによって受信された場合、Ｍ＿ＣＴＳコマンドは無視されてもよい。

図８Ｒに図示されるように、いくつかの実施形態では、マスタプロセッサが、スレーブプロセッサに送信するパケットを有するとき、マスタプロセッサは、Ｍ＿ＲＴＳコマンドを送信することによって転送を開始してもよい。Ｍ＿ＲＴＳコマンドを受信すると、いくつかの実施形態では、スレーブプロセッサに現在、保留中の送信パケットがあれば、スレーブプロセッサは、送信許可信号として再利用されてもよいように、流量制御ラインを下げる。次いで、スレーブプロセッサは、パケットを受信するようにＳＰＩＤＭＡを準備するプロセスであることをマスタプロセッサに伝えてもよく、その間に、マスタプロセッサは、バス上でバイトの時間を測定することを止めてもよく、スレーブプロセッサが受信の準備を終了することを可能にしてもよい。

いくつかの実施形態では、次いで、スレーブプロセッサは、（ＣＴＳ信号として使用されている）流量制御ラインを上昇させることによって、全パケットを受信する準備ができていることを示してもよい。ＣＴＳ信号を受信すると、マスタプロセッサは、続けて、パケット自体とともにＭ＿ＭＳＧ＿ＡＰＰＥＮＤＥＤコマンドを送信してもよい。

転送の完了後、スレーブプロセッサは、流量制御ラインを下げてもよい。パケットが転送の開始時に保留中であった、または、パケットが受信されているときに送信がスレーブプロセッサ上で発生した場合、スレーブプロセッサは、保留中のパケットがあることを示している流量制御ラインを再アサートしてもよい。

再度、図８を参照すると、デバイス８００は、ユーザ（図示せず）が、少なくとも１つのタスク、およびいくつかの実施形態では複数のタスクを行うことを可能にしてもよい、電気制御アセンブリ５１０（図５Ｄ）に連結されるスイッチアセンブリ８１０を含んでもよい。そのようなタスクの１つの例証的実施例は、デバイス８００が、注入ポンプである、または他の薬物送達デバイスである、実施形態では、ディスプレイアセンブリを使用しない、注入可能流体（例えば、インスリン）のボーラス用量の投与である。遠隔インターフェース８０２は、ユーザが、インスリンのボーラス用量を投与するように、デバイス８００を有効化／無効化／構成することを可能にしてもよい。

ディスプレイアセンブリ８０４は、少なくとも部分的には、ユーザがディスプレイアセンブリ８０４上にレンダリングされたメニューベースの情報を操作することを可能にするように構成されてもよい。実施例は、ディスプレイアセンブリ８０４が、タッチスクリーンであるものであり得る。いくつかの実施形態では、タッチスクリーン／ディスプレイアセンブリ８０４は、例えば、メニューのハイライトされた部分が「上向きに」または「下向きに」スクロールする比率が、起点に対するユーザの指の変位に応じて、変動するように構成されてもよい。したがって、いくつかの実施形態では、例えば、ユーザが、「上向きに」急スクロールすることを所望する場合、ユーザは、その指をディスプレイアセンブリ８０４の上部近傍に位置付けてもよい。同様に、ユーザが、「下向きに」急スクロールすることを所望する場合、ユーザは、その指をディスプレイアセンブリ８０４の底部近傍に位置付けてもよい。加えて、ユーザがゆっくりと「上向き」にスクロールすることを所望する場合、ユーザは、起点に対してわずかに「上向き」に指を位置付けてもよい。さらに、ユーザがゆっくりと「下向き」にスクロールすることを所望する場合、ユーザは、起点に対してわずかに「下向き」に指を位置付けてもよい。適切なメニューアイテムがハイライトされると、ユーザは、例えば、ハイライトされたメニューアイテムの近傍のいずれかにおいて、画面を所定の回数タッチすることによって、および／またはいくつかの実施形態では、遠隔インターフェース８０２上に含まれ得る、１つ以上のスイッチアセンブリ８０６を使用することによってのいずれかによって、ハイライトされたメニューアイテムを選択してもよい。

上記で議論されるように、前述の注入ポンプデバイスの一実施形態では、デバイス８００は、遠隔インターフェース８０２と通信するために使用されてもよい。そのような遠隔インターフェース８０２が利用されるとき、デバイス８００および遠隔インターフェース８０２は、定期的に相互にコンタクトをとり、２つのデバイスが、依然として、相互に通信していることを確実にしてもよい。例えば、デバイス８００は、遠隔インターフェース８０２に「ｐｉｎｇ」を送り、遠隔インターフェース８０２が存在し、アクティブであることを確実にしてもよい。さらに、遠隔インターフェース８０２は、デバイス８００に「ｐｉｎｇ」を送り、デバイス８００が、依然として、存在し、アクティブであることを確実にしてもよい。デバイス８００および遠隔インターフェース８０２のうちの１つが、他方と通信を確立できない場合、通信を確立できない一方（すなわち、デバイス８００または遠隔インターフェース８０２のいずれか）は、「分離」アラームを発報してもよい。例えば、遠隔インターフェース８０２が、ユーザの車内に残される一方、デバイス８００は、ユーザのポケット内にあると仮定する。したがって、定義された期間後、デバイス８００は、「分離」アラームを発報し始め、インターフェース８０２との通信を確立できないことを示してもよい。いくつかの実施形態では、ユーザは、スイッチアセンブリ８１０を使用することによって、肯定応答する、および／または「分離」アラームを無音化してもよい。

種々の実施形態では、ユーザは、遠隔インターフェース８０２が、デバイス８００と通信していない間、デバイス８００のスイッチアセンブリ８１０を使用して、流体の送達を定義および投与してもよく、デバイス８００は、デバイス８００内に記憶されるログファイル（図示せず）内に投与されたボーラスインスリン用量に関する情報を記憶してもよい。このログファイル（図示せず）は、デバイス８００内に含まれる不揮発性メモリ（図示せず）内に記憶されてもよい。デバイス８００と遠隔インターフェース８０２との間に確立される通信に応じて、デバイス８００は、デバイス８００のログファイル（図示せず）内に記憶された投与されたボーラスインスリン用量に関する情報を遠隔インターフェース８０２に提供してもよい。

さらに、いくつかの実施形態では、ユーザが、遠隔インターフェース８０２をデバイス８００から分離することを予期すると、ユーザは、デバイス８００および遠隔インターフェース８０２を「分離」モードに構成し、したがって、前述の「分離」アラームの発生を排除してもよい。しかしながら、いくつかの実施形態では、遠隔インターフェース８０２およびデバイス８００は、相互に通信する状態に戻ると、デバイス８００および遠隔インターフェース８０２が、自動的に、「分離」モードから解除され得るように、相互に「ｐｉｎｇ」を送り続けてもよい。

さらに、いくつかの実施形態では、ユーザが、航空機で旅行することを予期する場合、ユーザは、遠隔インターフェース８０２を使用して、デバイス８００および遠隔インターフェース８０２を「航空機」モードに構成してもよく、デバイス８００および遠隔インターフェース８０２はそれぞれ、あらゆるデータ伝送を一時停止させる。「航空機」モードにある間、デバイス８００および遠隔インターフェース８０２は、データを受信し続けてもよく、またはそうでなくてもよい。

いくつかの実施形態では、スイッチアセンブリ８１０は、制限ではないが、再使用可能部分５０２のバッテリ寿命のチェック、再使用可能部分５０２と遠隔インターフェース８０２のペアリング、および／または注入可能流体のボーラス用量の投与の中断のうちの１つ以上を含み得る、付加的機能を行なうために使用されてもよい。

また、図９Ａを参照すると、上記で議論されるように、いくつかの実施形態では、例えば、デバイス８００の安全性を向上させるために、電気制御アセンブリ５１６は、２つの別個かつ個別のマイクロプロセッサ、すなわち、スーパーバイザプロセッサ９００およびコマンドプロセッサ９０２を含んでもよい。具体的には、コマンドプロセッサ９０２は、制限されないが、ポンプ駆動信号の発生等の機能を果たしてもよく、例えば、形状記憶アクチュエータの機能性を制御する、継電器／スイッチアセンブリを制御してもよい。コマンドプロセッサ９０２は、いくつかの実施形態では、形状記憶アクチュエータであり得る、ポンプアクチュエータ９２２、９２４に印加される電圧信号の状態（例えば、電圧レベル）に関するフィードバックを信号調整器９０８から受信してもよい。コマンドプロセッサ９００は、継電器／スイッチアセンブリ９０４、９０６から独立して、継電器／スイッチアセンブリ９１０を制御してもよい。故に、例えば、注入事象が所望されると、スーパーバイザプロセッサ９００およびコマンドプロセッサ９０２は両方とも、注入事象が、適切であることに合意しなければならず（固有またはユーザ選択／事前プログラムされる、および／または計画的であるとき、注入事象用量がシステムの任意の設定制限を超えないかどうかを含んでもよい）、両方とも、その個別の継電器／スイッチを作動させなければならない。スーパーバイザプロセッサ９００およびコマンドプロセッサ９０２のいずれかが、その個別の継電器／スイッチを作動しない場合、注入事象は、生じないであろう。故に、スーパーバイザプロセッサ９００およびコマンドプロセッサ９０２の使用および生じなければならない協働および同時発生を通して、デバイス８００の安全性が、向上される。

いくつかの実施形態では、スーパーバイザプロセッサ９００は、コマンドプロセッサ９０２が適切ではないときに送達することを防止してもよく、また、コマンドプロセッサ９０２が送達するべきときに送達していない場合、アラームしてもよい。スーパーバイザプロセッサ９００は、例えば、コマンドプロセッサ９０２が間違ったスイッチを作動させた場合、またはコマンドプロセッサが過剰に長く電力を印加しようとした場合、継電器／スイッチアセンブリを非アクティブ化してもよい。

スーパーバイザプロセッサ９００は、送達されるべき流体の量の計算を冗長的に行なってもよい（すなわち、コマンドプロセッサ９０２の計算の二重チェック）。いくつかの実施形態では、コマンドプロセッサ９０２は、送達スケジュールを判定してもよく、スーパーバイザプロセッサ９００は、それらの計算を冗長的にチェック／確認してもよい。

スーパーバイザプロセッサ９００は、コマンドプロセッサ９０２が、正しい計算を行い得るように、プロファイル（例えば、デバイスに事前にプログラム／事前に入力された送達プロファイルおよび／またはユーザ選好）をＲＡＭ内に冗長的に保持してもよいが、不良ＲＡＭを有する場合、コマンドに誤った結果を生じさせるであろう。したがって、スーパーバイザプロセッサ９００は、プロファイル／ユーザ選好、例えば、基礎プロファイル等のローカルコピーを使用して、二重にチェック／確認する。

スーパーバイザプロセッサ９００は、デバイスによって行なわれる１つ以上の計算、例えば、ＡＶＳ測定を、ＡＶＳ計算および適用された安全性チェックを検討することによって二重チェックしてもよい。デバイスのいくつかの実施形態では、例えば、ＡＶＳ測定が行なわれるたびに、スーパーバイザプロセッサ９００は、二重チェックを行なう。

図９Ｂも参照すると、スーパーバイザプロセッサ９００およびコマンドプロセッサ９０２のうちの１つ以上は、注入ポンプ／デバイス８００の種々の部分に診断を行ってもよい。例えば、分圧器９１２、９１４は、例えば、形状記憶アクチュエータ９２２の遠位端において感知される、電圧（それぞれ、Ｖ１およびＶ２）を監視するように構成されてもよい。継電器／スイッチアセンブリ９０４、９１０に印加される信号を知った上で、電圧Ｖ１およびＶ２の値は、（例証的な診断表９１６に示されるのと同様の様式で）図９Ｂに示される回路の種々の構成要素に診断が行われることを可能にする。

上記で議論され、図９Ａ−９Ｂに図示されるように、デバイス８００の安全性を向上させるために、電気制御アセンブリ９１０は、複数のマイクロプロセッサ（例えば、スーパーバイザプロセッサ９００およびコマンドプロセッサ９０２）を含んでもよく、そのそれぞれは、作用をもたらすために（例えば、デバイス８００が、薬物の送達をもたらす場合、作用は、例えば、ある用量の注入可能流体の送達であってもよい）、相互作用し、同時動作することが要求されてもよい。マイクロプロセッサ９００、９０２が相互作用／同時動作できなかった場合、注入可能流体の用量の送達／作用が失敗する場合があり、１つ以上のアラームがトリガされてもよく、したがって、デバイス８００の安全性および信頼性を向上させる。

経時的に、送達された流体の体積が、要求されるもの未満または超であることを指し得る、誤差、例えば、体積誤差を追跡する、マスタアラームが利用されてもよい。したがって、誤差の合計が大きくなりすぎれば、マスタアラームが開始され、システムに異常があるかもしれないことを示してもよい。したがって、マスタアラームは、行われている総体積比較および判明した相違を示してもよい。マスタアラームを開始するために必要とされる相違の典型的な値は、前述の注入ポンプを含む実施形態では、１．００ミリリットルであってもよい。マスタアラームは、漏洩方式で合計を監視してもよい（すなわち、不正確性は、時間的水平線を有する）。

図１０Ａ−１０Ｂも参照すると、注入可能流体の用量の送達中の、複数のマイクロプロセッサ間のそのような相互作用の１つのそのような例証的実施例が示されている本実施例では、相互作用は、注入ポンプによるある用量の注入可能流体の送達の際に行なわれる。具体的には、コマンドプロセッサ９０２が、最初に、体積センサチャンバ内の注入可能流体の初期体積を判定してもよい９００。次いで、コマンドプロセッサ９０２は、スーパーバイザプロセッサ９００に「ポンプ電力要求」メッセージを提供してもよい１００２。「ポンプ電力要求」メッセージの受信に応じて１００４、スーパーバイザプロセッサ９００が、例えば、継電器／スイッチ９１０を励起してもよく１００６（したがって、形状記憶アクチュエータ９２２を励起する）、コマンドプロセッサ９０２に「ポンプ電力オン」メッセージを送信してもよい１００８。「ポンプ電力オン」メッセージの受信に応じて１０１０、コマンドプロセッサ９０２は、例えば、ポンプアセンブリを作動させてもよく１０１２（継電器／スイッチ９０４を励起させ、これによって、弁アセンブリ５１４を励起させることによって）、その間、スーパーバイザプロセッサ９００は、例えば、ポンプアセンブリの作動を監視してもよい１０１４。

ポンプアセンブリの作動が完了すると、コマンドプロセッサ９０２が、スーパーバイザプロセッサ９００に「ポンプ電力オフ」メッセージを提供してもよい１０１４。「ポンプ電力オフ」メッセージの受信１０１６に応じて、スーパーバイザプロセッサ９００は、継電器／スイッチ９１０を脱励起し１０１８、「ポンプ電力オフ」メッセージをコマンドプロセッサ９０２に提供してもよい１０２０。「ポンプ電力オフ」メッセージの受信に応じて１０２２、コマンドプロセッサ９０２が、ポンプアセンブリ（いくつかの実施形態では、弁アセンブリ５１４を含んでもよい）によって圧送された注入可能流体の分量を測定してもよい１０２４。これは、体積センサチャンバ内の現在の分量を測定し、それを上記で（ステップ１０００で）判定された分量と比較することによって、達成されてもよい。判定されると１０２４、コマンドプロセッサ９０２が、スーパーバイザプロセッサ９００に「弁開放電力要求」メッセージを提供してもよい１０２６。「弁開放電力要求」メッセージの受信に応じて１０２８、スーパーバイザプロセッサ９００が、継電器／スイッチ９１０を励起してもよく１０３０（したがって、形状記憶アクチュエータ９２４を励起する）、コマンドプロセッサ９０２に「弁開放電力オン」メッセージを送信してもよい１０３２。「弁開放電力オン」メッセージの受信に応じて１０３４、コマンドプロセッサ９０２が、例えば、（継電器／スイッチ９０６を励起することによって）測定弁アセンブリを作動させてもよく１０３６、その間に、スーパーバイザプロセッサ９００が、例えば、測定弁アセンブリの作動を監視してもよい１０３８。

測定弁アセンブリの作動が完了すると、コマンドプロセッサ９０２が、スーパーバイザプロセッサ９００に「弁電力オフ」メッセージを提供してもよい１０４０。「弁電力オフ」メッセージの受信に応じて１０４２、スーパーバイザプロセッサ９００が、継電器／スイッチ９１０を脱励起し１０４４、コマンドプロセッサ９０２に「弁電力オフ」メッセージを提供してもよい１０４６。

「弁電力オフ」メッセージの受信に応じて１０４８、コマンドプロセッサ９０２が、スーパーバイザプロセッサ９００に「弁閉鎖電力要求」メッセージを提供してもよい１０５０。「弁閉鎖電力要求」メッセージの受信に応じて１０５２、スーパーバイザプロセッサ９００が、継電器／スイッチ９１０を励起してもよく１０５４（したがって、形状記憶アクチュエータを励起する）、コマンドプロセッサ９０２に「電力オン」メッセージを送信してもよい１０５６。「電力オン」メッセージの受信に応じて１０５８、コマンドプロセッサ９０２が、形状記憶アクチュエータを励起するように構成される、励起継電器／スイッチ（図示せず）を作動させてもよく１０６０、その間に、スーパーバイザプロセッサ９００が、例えば、形状記憶アクチュエータの作動を監視してもよい１０６２。

種々の実施形態では、形状記憶アクチュエータが、電気接点を使用して第１端に固着されてもよい。形状記憶アクチュエータの他方の端は、ブラケットアセンブリに接続されてもよい。形状記憶アクチュエータがアクティブ化されると、形状記憶アクチュエータは、ブラケットアセンブリを前方に引き、弁アセンブリを解放してもよい。そのようなものとして、測定弁アセンブリは、形状記憶アクチュエータを介してアクティブ化されてもよい。測定弁アセンブリがアクティブ化されると、ブラケットアセンブリは、アクティブ化位置で測定弁アセンブリに自動でで掛け金を掛けてもよい。形状記憶アクチュエータを作動させることにより、ブラケットアセンブリを前方に引き、弁アセンブリを解放してもよい。形状記憶アクチュエータがもはやアクティブ化されないと仮定して、ブラケットアセンブリが測定弁アセンブリを解放すると、測定弁アセンブリが非アクティブ化状態になってもよい。したがって、形状記憶アクチュエータを作動させることによって、測定弁アセンブリが非アクティブ化状態になってもよい。

形状記憶アクチュエータの作動が完了すると、コマンドプロセッサ９０２が、スーパーバイザプロセッサ９００に「電力オフ」メッセージを提供してもよい１０６４。「電力オフ」メッセージの受信に応じて１０６６、スーパーバイザプロセッサ９００が、継電器／スイッチ９１０を脱励起し１０６８、コマンドプロセッサ９０２に「電力オフ」メッセージを提供してもよい１０７０。「電力オフ」メッセージの受信に応じて１０７２、コマンドプロセッサ９０２が、体積センサチャンバ内の注入可能流体の分量を判定してもよく、したがって、コマンドプロセッサ９０２が、この測定された分量を、上記で（ステップ１０２４で）判定された分量と比較して、ユーザに送達された注入可能流体の分量を判定することを可能にする１０７４。

ユーザに送達された注入可能流体の分量１０７４が、基礎／ボーラス注入事象に対して指定される注入可能流体の分量より少ない場合、（ループ１０７６を介して）上記の手順が反復されてもよい。

図１１を参照すると、今回は、注入可能流体の用量のスケジューリング中の、プロセッサ９００、９０２間の相互作用の別の例証的実施例が示されている。コマンドプロセッサ９０２は、（それぞれ）基礎スケジューリングメッセージまたはボーラス要求メッセージの受信について監視してもよい１１００、１１０２。これらのメッセージのうちのいずれか一方を受信すると１１００、１１０２、コマンドプロセッサ９０２が、所望の送達体積を設定してもよく１１０４、スーパーバイザプロセッサ９００に「送達要求」メッセージを提供してもよい１１０６。「送達要求」メッセージの受信に応じて１１０８、スーパーバイザプロセッサ９００が、コマンドプロセッサ９０２によって定義される体積１１０４を検証してもよい１１１０。検証されると１１１０、スーパーバイザプロセッサ９００が、コマンドプロセッサ９０２に「送達容認」メッセージを提供してもよい１１１２。「送達容認」メッセージの受信に応じて１１１４、コマンドプロセッサ９０２は、遠隔インターフェース（例えば、上記で議論され、図６−８に図示される遠隔インターフェース）を更新し１１１６、注入可能流体の基礎／ボーラス用量の送達を実行してもよい１１１８。コマンドプロセッサ９０２は、（上記で議論され、かつ図１０Ａ−１０Ｂに図示されるように）ユーザに送達された注入可能流体の総分量を監視し、更新してもよい１１２２。適切な分量の注入可能流体がユーザに送達されると、コマンドプロセッサ９０２が、スーパーバイザプロセッサ９００に「送達終了」メッセージを提供してもよい１１２４。「送達終了」メッセージの受信に応じて１１２６、スーパーバイザプロセッサ９００が、ユーザに送達された注入可能流体の総分量を更新してもよい１１２８。ユーザに送達された注入可能流体の総分量１１１８が、上記で（ステップ１１０４で）定義された分量より少ない場合、（ループ１１３０を介して）上記で議論される注入プロセスが反復されてもよい。

図１２も参照すると、（上記で説明されるように）体積センサアセンブリを介した体積測定を達成しながら、スーパーバイザプロセッサ９００およびコマンドプロセッサ９０２が相互作用し得る方式の実施例が示されている。

具体的には、コマンドプロセッサ９０２が、体積センサアセンブリを初期化し１２５０、体積センサアセンブリからデータを収集し始めてもよく１２５２、そのプロセスは、例えば、２００９年１２月３日公開の米国公報第ＵＳ−２００９−０２９９２７７−Ａ１号（弁理士整理番号Ｇ７５）に説明されるように、上記の正弦波掃引で利用される各周波数について反復されてもよい。データが特定の掃引周波数について収集されるたびに、データ点メッセージがコマンドプロセッサ９０２から提供されてもよく１２５４、これは、スーパーバイザプロセッサ９００によって受信されてもよい１２５６。

正弦波掃引全体についてデータ収集１２５２が完了すると、コマンドプロセッサ９０２が、デバイス８００の注入によって送達される注入可能流体の体積を推定してもよい１２５８。コマンドプロセッサ９０２は、スーパーバイザプロセッサ９００に体積推定メッセージを提供してもよい１２６０。この体積推定メッセージの受信に応じて１２６２、スーパーバイザプロセッサ９００が、体積推定メッセージをチェック（すなわち、確認）してもよい１２６４。チェック（すなわち、確認）されると、スーパーバイザプロセッサ９００が、コマンドプロセッサ９０２に検証メッセージを提供してもよい１２６６。スーパーバイザプロセッサ９００から受信されると１２６８、コマンドプロセッサ９０２が、体積センサアセンブリによって送達された注入可能流体の用量に対する測定状態を設定してもよい。

上記で議論されるように（かつ図１Ａ−５Ｉを一時的に参照すると）、注入ポンプシステムの種々の実施形態および構成要素は、遠隔インターフェース８０２を使用して構成されてもよい（図６−８参照）。遠隔インターフェース８０２を介して構成可能であるとき、注入ポンプ８００は、注入ポンプと、例えば、遠隔インターフェース８０２との間の通信（例えば、有線または無線）を可能にし、したがって、遠隔インターフェース８０２が、注入ポンプ８００と遠隔で通信することを可能にする、テレメトリ回路（図示せず）を含んでもよい。遠隔インターフェース８０２（同様にテレメトリ回路（図示せず）を含んでもよく、注入ポンプ８００と通信可能であってもよい）の種々の実施形態は、ディスプレイアセンブリ（６０２、７０２、８０４）および少なくとも１つの入力アセンブリ６０８、６０４、６１０、６０６、７０４、７０２、８０４、８０６）、を含んでもよいが、しかしながら、種々の実施形態では、ディスプレイアセンブリはまた、入力アセンブリとしての役割を果たしてもよい。

本明細書で使用されるとき、用語「遠隔インターフェース」は、遠隔インターフェースの任意の実施形態を指す。しかしながら、図８に示される実施形態は、以下では、例証目的のために使用されるが、説明は、図８に示される遠隔インターフェースのその実施形態に制限されない。

いくつかの実施形態では、遠隔インターフェース８０２は、２つのプロセッサを含んでもよく、１つのプロセッサ（例えば、ＣｈｉｐｃｏｎＡＳ（Ｏｓｌｏ，Ｎｏｒｗａｙ）から入手可能なＣＣ２５１０マイクロコントローラインターフェース／ＲＦ送受信機を含んでもよいが、それに制限されない）は、無線通信、例えば、デバイス８００と通信するための無線通信専用であってもよい。遠隔インターフェース８０２内に含まれる第２のプロセッサ（ＨｏｌｄｉｎｇｓＰＬＣ（ＵｎｉｔｅｄＫｉｎｇｄｏｍ）製造のＡＲＭ９２０ＴおよびＡＲＭ９２２Ｔを含んでもよいが、それらに制限されない）は、コマンドプロセッサであってもよく、例えば、デバイス８００の構成と関連付けられたデータ処理タスクを行なってもよい。しかしながら、種々の他の実施形態では、以下に説明されるように、遠隔インターフェース８０２は、種々のプロセッサおよび／または通信プロトコルおよび／または通信のための種々のアンテナを含んでもよい。

さらに、上記で議論されるように、電気制御アセンブリ５１６の一実施形態は、３つのマイクロプロセッサを含んでもよい。１つのプロセッサ（例えば、ＣｈｉｐｃｏｎＡＳ（Ｏｓｌｏ，Ｎｏｒｗａｙ）から入手可能なＣＣ２５１０マイクロ遠隔インターフェース／ＲＦ送受信機を含んでもよいが、それに制限されない）は、例えば、遠隔インターフェース８０２と通信するために、無線通信に専念してもよい。２つの追加マイクロプロセッサ（例えば、スーパーバイザプロセッサ１８００およびコマンドプロセッサ１８０２）は、（上記で議論されるように）注入可能流体の送達を達成してもよい。スーパーバイザプロセッサ１８００およびコマンドプロセッサ１８０２の例は、ＴｅｘａｓＩｎｓｔｒｕｍｅｎｔｓＩｎｃ．（Ｄａｌｌａｓ，Ｔｅｘａｓ）から入手可能なＭＳＰ４３０マイクロ遠隔インターフェースを含んでもよいが、それに制限されない。

ＯＳは、優先度にかかわらず、次のタスクを実行することが可能になる前に、全てのタスクが完了するまで実行するという点で、非割り込みタイプスケジューリングシステムであってもよい。加えて、コンテキスト切替は行われてなくてもよい。タスクが実行を完了すると、実行が現在予定されている、最高優先度のタスクが、実行されてもよい。いずれのタスクも実行が予定されていない場合、ＯＳがプロセッサ（例えば、スーパーバイザプロセッサ９００および／またはコマンドプロセッサ９０２）を低電力休止モードにしてもよく、次のタスクが予定されると、ウェークしてもよい。ＯＳは、主要ループコードを管理するためだけに使用されてもよく、割り込みに基づいた機能性が影響されないままにしてもよい。

いくつかの実施形態では、ＯＳは、Ｃ＋＋言語を利用するように書かれてもよい。インヘリタンスならびに仮想関数は、タスクの容易な作成、スケジューリング、および管理を可能にする設計の重要な要素であってもよい。

ＯＳインフラストラクチャのベースには、システム時間を追跡する能力があってもよく、プロセッサを低電力モード（ＬＰＭ、休止モードとしても知られている）にする能力を制御する。この機能性は、全てのシステムクロックの制御および構成とともに、ＳｙｓＣｌｏｃｋｓクラスによってカプセル化されてもよい。

ＳｙｓＣｌｏｃｋｓクラスは、プロセッサ（例えば、スーパーバイザプロセッサ９００および／またはコマンドプロセッサ９０２）をＬＰＭにしてエネルギー消費を低減する機能性を含有してもよい。ＬＰＭである間、低速リアルタイムクロックが実行され続けてもよい一方で、ＣＰＵコアおよびほとんどの周辺機器を実行する、高速システムクロックが無効にされてもよい。

いくつかの実施形態では、プロセッサをＬＰＭにすることは、常に、提供されたＳｙｓＣｌｏｃｋｓによって行われてもよい。この機能は、ＬＰＭになるとき、またはＬＰＭではなくなるときはいつでも一貫性をもたらす、全ての必要な電力低下および電力増加シーケンスを含有してもよい。ＬＰＭからのウェークは、低速クロックに基づく任意の割り込みによって開始されてもよい。

ＯＳは、秒数、ミリ秒数、および時刻の３つの時間の局面を追跡してもよい。秒数に関して、ＳｙｓＣｌｏｃｋｓは、プロセッサがリセットから脱するときに始めて、秒をカウントしてもよい。秒数カウンタは、低速システムクロックに基づいてもよく、したがって、プロセッサがＬＰＭであるか、または全電力であるかどうかにかかわらず、インクリメントしてもよい。結果として、これが、プロセッサが休止からウェークして、以前に予定されたタスクを実行する境界である。タスクが、割り込み処理ルーチン（ＩＳＲ）の直後に実行される予定であれば、ＩＳＲが、終了時にプロセッサをＬＰＭからウェークさせてもよく、タスクが即座に実行されてもよい。ミリ秒数に関して、電力オンになってから秒数をカウントすることに加えて、ＳｙｓＣｌｏｃｋｓは、プロセッサが全電力モードである間にミリ秒数もカウントしてもよい。高速クロックがＬＰＭ中に停止させられるため、ミリ秒カウンタはインクリメントしなくてもよい。したがって、タスクがミリ秒数に基づいて実行される予定であるときはいつでも、プロセッサがＬＰＭにならなくてもよい。時刻に関して、時刻は、特定の時点以降の秒数（例えば、２００８年１月１日、および／またはいくつかの実施形態では、ＰＯＳＩＸ標準時間１９７１年１月１日以降の秒数）のようにＳｙｓＣｌｏｃｋｓ内に表されてもよい。

ＳｙｓＣｌｏｃｋｓクラスは、コマンドおよびスーパーバイザプロジェクトコードベースの全体を通して使用される、有用な機能性を提供してもよい。コード遅延は、ハードウェアが安定すること、またはアクションが完了することを可能にするために必要であってもよい。ＳｙｓＣｌｏｃｋｓは、秒数に基づく遅延、またはミリ秒数に基づく遅延の２つの形態の遅延を提供してもよい。遅延が使用されると、プロセッサは、現在のコード経路を続ける前に所望の時間が経過するまで、単純に待機してもよい。この時間の間、ＩＳＲのみが実行されてもよい。ＳｙｓＣｌｏｃｋｓは、必要な機能性の全てを提供して、現在の時刻を設定または回収してもよい。

用語「タスク」とは、より複雑なスケジューリングシステムと関連付けられてもよく、したがって、ＯＳ内で、タスクは、マネージド関数（ＭａｎａｇｅｄＦｕｎｃｔｉｏｎｓ）によって表され、かつマネージド関数と呼ばれてもよい。ＭａｎａｇｅｄＦｕｎｃクラスは、所望の機能性を管理し、予定に入れるために必要な制御要素および機能性の全てを提供する、抽象タイプベースクラスであってもよい。

ＭａｎａｇｅｄＦｕｎｃベースクラスは、５つの制御要素を有してもよく、２つがスケジューリング操作要素関数であり、１つがマネージド機能性を含有し得る、純粋仮想実行関数である。ＭａｎａｇｅｄＦｕｎｃ制御要素の全ては、導出クラスから隠されてもよく、作成中に導出クラスによって直接設定されるのみであってもよく、したがって、使用を簡略化し、注入ポンプ８００の安全性を向上させる。

いくつかの実施形態では、関数ＩＤは、作成時に設定されてもよく、決して変更されなくてもよい。全ての関数ＩＤは、単一の．ｈファイル内で定義されてもよく、ベースＭａｎａｇｅｄＦｕｎｃコンストラクタは、同じＩＤが２つ以上のマネージド関数に使用されてはならないことを強制的に履行してもよい。ＩＤはまた、割り当てられた関数ＩＤに基づいて（他の関数に対する）関数の優先度を定義してもよく、より高い優先度の関数は、割り当てられたより低い関数ＩＤである。実行が現在予定されている、最高優先度のタスクは、より低い優先度のタスクの前に実行されてもよい。

全ての他の制御要素は、実行されるべきであるとき、および（実行時に）以前に設定された時間量で関数が再び予定に入れられるべきであれば、関数の現在の予定された状態を表すために使用されてもよい。これらの制御および状態の操作は、周知のメンバ関数のみを通してであるが、可能になってもよい（したがって、全ての設定に安全性制御を履行する）。

マネージド関数のスケジューリングを制御するために、設定開始および設定反復関数が使用されてもよい。これらのメンバ関数のそれぞれは、反復設定を構成または無効化する、ならびに、マネージド関数が秒数、ミリ秒数、または時刻によって予定に入れられる、非アクティブ状態であるかどうかを制御する能力を可能にする、単純インターフェースであってもよい。

インヘリタンスを通して、導出クラスを作成し、スケジューリング制御を受ける必要があるコードを含有する純粋仮想「実行」関数を定義することによって、マネージド関数の作成が行われてもよい。ＭａｎａｇｅｄＦｕｎｃベースクラスコンストラクタは、関数の一意のＩＤに基づいてもよいが、始動時にデフォルト制御値を設定するためにも使用されてもよい。

例えば、始動してから３０秒後、かつその後１５秒ごとに実行される関数を作成するために、例えば、所望のコードが仮想実行関数に入れられ、３０秒の開始時間である、秒数状態によって予定に入れられる関数ＩＤ、および１５秒の反復設定が、コンストラクタに提供される。

以下は、マネージド関数の作成に関する、例証的なコードの実施例である。この特定の実施例では、デバイス８００の始動後１秒で初めて実行し、その後１０秒ごとに実行することが予定される、「ハートビート」関数が作成される。
＃ｉｎｃｌｕｄｅ “ＭａｎａｇｅｄＦｕｎｃ．ｈ”
／／ＴｈｅＳｅｎｄＧｏｏｄＦｕｎｃｉｓａ “ｈｅａｒｔｂｅａｔ” ｓｔａｔｕｓｍｅｓｓａｇｅ
ｃｌａｓｓＳｅｎｄＧｏｏｄＦｕｎｃ：ｐｕｂｌｉｃＭａｎａｇｅｄＦｕｎｃ
｛
ｐｕｂｌｉｃ：
／／Ｉｎｉｔｉａｌｉｚｅｔｈｅｍａｎａｇｅｄｆｕｎｃｔｏｒｕｎ２
ｓｅｃｏｎｄｓａｆｔｅｒｓｔａｒｔｕｐ
／／ａｎｄｒｅｐｅａｔｅｖｅｒｙｓｅｃｏｎｄ．
ＳｅｎｄＧｏｏｄＦｕｎｃ（）：
ＭａｎａｇｅｄＦｕｎｃ（ＩＰＣ＿ＳＥＮＤ＿ＧＯＯＤ，ＳＣＨＥＤＵＬＥＤ＿ＳＥＣ，１，ｔｒｕｅ，１０）｛｝；
〜ＳｅｎｄＧｏｏｄＦｕｎｃ（）｛｝；
ｐｒｏｔｅｃｔｅｄ：
ｖｏｉｄｅｘｅｃｕｔｅ（ｖｏｉｄ）；
｝；
ｖｏｉｄＳｅｎｄＧｏｏｄＦｕｎｃ：：ｅｘｅｃｕｔｅ（ｖｏｉｄ）
｛
／／＜＜ｃｏｄｅｔｏｓｅｎｄｔｈｅｈｅａｒｔｂｅａｔ＞＞
｝
ＳｅｎｄＧｏｏｄＦｕｎｃｇ＿ｓｅｎｄＧｏｏｄＦｕｎｃ；
／／ｔｏｍａｎｉｐｕｌａｔｅｔｈｅｈｅａｒｔｂｅａｔｔｉｍｉｎｇｓｉｍｐｌｙｃａｌｌ：
／／ｇ＿ｓｅｎｄＧｏｏｄＦｕｎｃ．ｓｅｔＦｕｎｃＳｔａｒｔ（…）ｏｒｇ＿ｓｅｎｄＧｏｏｄＦｕｎｃ．ｓｅｔＲｅｐｅａｔ（ … ）

マネージド関数の実際の実行は、ＳｌｅｅｐＭａｎａｇｅｒクラスによって制御され、実施されてもよい。ＳｌｅｅｐＭａｎａｇｅｒは、マネージド関数の実際の優先順位リストを含有してもよい。この関数の優先順位リストは、マネージド関数作成プロセスによって自動的にデータ投入されてもよく、各関数が適正に作成され、一意のＩＤを有することを確実にしてもよい。

ＳｌｅｅｐＭａｎａｇｅｒクラスの主要な役割は、その「管理」関数を、プロセッサの主要ループから、および／または永久ｗｈｉｌｅループから繰り返し呼び出させることであり得る。管理の各呼び出し時に、ＳｌｅｅｐＭａｎａｇｅｒは、ＳｌｅｅｐＭａｎａｇｅｒが全ての予定された関数を使い果たすまで実行されることが予定される、全ての関数を実行し、そのときに、ＳｌｅｅｐＭａｎａｇｅｒは、プロセッサをＬＰＭにしてもよい。プロセッサがＬＰＭからウェークすると、プロセッサが再びＬＰＭになる準備ができるまで、管理関数が再入力されてもよい（このプロセスは、例えば、ユーザによって、またはシステムによって停止されるまで、反復されてもよい）。

プロセッサが長期間にわたって（例えば、アナログ／デジタル変換がサンプリングされている間）全電力モードで保たれなければならない場合、ＳｌｅｅｐＭａｎａｇｅｒは、ＬＰＭになることを無効にする機能性を提供してもよい。ＬＰＭが無効になっている間、管理関数は、引き続き、予定されたタスクを検索してもよい。

ＳｌｅｅｐＭａｎａｇｅｒはまた、スケジューリングを操作し、関数の一意のＩＤの使用を通して任意のマネージド関数の設定を反復する、インターフェースを提供してもよく、これは、所望のＭａｎａｇｅｄＦｕｎｃオブジェクトへの直接アクセス、またはそれの不必要な知識がなくても、コードの任意のセクションが、任意の必要なスケジューリングを行うことを可能にしてもよい。

デバイス８００および遠隔インターフェース８０２内に含まれる無線回路は、遠隔インターフェース８０２とデバイス８００との間の無線通信をもたらしてもよい。いくつかの実施形態では、内部８０５１マイクロ遠隔インターフェースを伴う、２．４ＧＨｚ無線通信チップ（例えば、ＴｅｘａｓＩｎｓｔｒｕｍｅｎｔｓＣＣ２５１０無線送受信機）が、無線通信に使用されてもよい。

無線リンクは、リンク可用性、待ち時間、およびエネルギーの３つのオブジェクトのバランスを保ってもよい。

リンク可用性に関して、遠隔インターフェース８０２は、デバイス８００に命令するための一次手段を提供してもよく、遠隔インターフェース８０２のグラフィカルユーザインターフェース（ＧＵＩ）（ディスプレイアセンブリ８０４）を介して、詳細なフィードバックをユーザに提供してもよい。待ち時間に関して、通信システムは、遠隔インターフェース８０２からデバイス８００に（その逆も同様）にデータを送達する、少ない待ち時間を提供するように設計されてもよい。エネルギーに関して、遠隔インターフェース８０２およびデバイス８００は両方とも、無線通信のための最大エネルギー消費を有してもよい
。

無線リンクは、半二重通信をサポートしてもよい。いくつかの実施形態では、遠隔インターフェース８０２は、全ての通信を開始する、無線リンクのマスタであってもよい。これらの実施形態では、デバイス８００は、通信に応答するだけであってもよく、決して通信を開始しなくてもよい。そのような無線通信システムの使用は、向上したセキュリティ、簡略化された設計（例えば、航空機利用のため）、および無線リンクの協調制御の種々の利点を提供し得る。他の実施形態では、デバイス８００は、ある作用を引き起こしてもよいが、通信は、遠隔インターフェース８０２によって引き起こされてもよい。

図１２も参照すると、上記で議論される、無線通信システムの種々のソフトウェア層の１つの例証的実施例が示されている。
いくつかの実施形態では、遠隔インターフェース８０２およびデバイス８００に含まれる無線プロセッサは、ＳＰＩポートと２．４ＧＨｚ無線リンクとの間（その逆も同様）で、メッセージングパケットを転送してもよい。いくつかの実施形態では、無線は、常にＳＰＩスレーブであってもよい。デバイス８００上では、無線プロセッサ（ＰＲＰ）９１８（図９Ａ−９Ｂ参照）が、いくつかの実施形態では、ＳＰＩポートを経由して、上流（すなわち、コマンドプロセッサ９００およびスーパーバイザプロセッサ９０２）にある、２つの付加的ノード（付加的ノードの数は、種々の実施形態では、異なってもよい）にサービス提供してもよい。いくつかの実施形態では、遠隔インターフェース８０２上で、無線プロセッサ９１８（ＣＲＰ）は、上流または下流のいずれか一方にあり得るＳＰＩポート上で２つの追加ノードを使用可能にしてもよく、例えば、いくつかの実施形態では、上記の遠隔制御プロセッサ（ＵＩ）および持続的グルコースモニタ（ＣＧＭ）および／または血液グルコースモニタ（ＢＧＭ）である。

メッセージングシステムは、ネットワーク中の種々のノード間で、メッセージの通信を可能にしてもよい。遠隔インターフェース８０２のＵＩプロセッサ、および、例えば、スーパーバイザプロセッサ９００は、２つのシステム無線上でモード切替の一部を構成し、開始するために、メッセージングシステムを使用してもよい。それはまた、ネットワーク中の他のノードに無線およびリンク状態情報を伝えるために、無線によって使用されてもよい。

いくつかの実施形態では、遠隔インターフェース８０２の無線が、デバイス８００からチャネル統計を収集すること、または、デバイス８００の無線のマスタチャネルリストを更新することを所望すると、遠隔インターフェース８０２の無線がシステムメッセージを使用してもよい。新しい更新されたリストを発効させるための同期化は、タイミングの不確定性を除去するために、ハートビートメッセージでフラグを使用してもよい。

無線通信システムは、メッセージングソフトウェアと互換性があるように、Ｃ＋＋で書かれてもよい。いくつかの実施形態では、各無線ノードに対処するために、４バイト無線シリアル番号が使用されてもよい。デバイス「可読」シリアル番号列と無線シリアル番号との間で１対１の翻訳を提供するために、ハッシュテーブルが使用されてもよい。ハッシュテーブルは、同様の可読シリアル番号を伴うデバイスまたは遠隔インターフェースが、一意の論理アドレスを有する可能性が高いように、よりランダム化された、例えば、８ビット論理アドレスを提供してもよい。いくつかの実施形態では、デバイス８００と遠隔インターフェース８０２との間の無線シリアル番号は、それぞれが無線プロトコルにおいて有する一意の役割により、一意である必要がなくてもよい。

遠隔インターフェース８０２の無線シリアル番号およびデバイス８００の無線シリアル番号は、いくつかの実施形態では、遠隔インターフェース８０２の無線シリアル番号のみを含んでもよいＲＦペアリング要求メッセージを除いて、全ての無線パケットに含まれてもよく、したがって、それがペアリングされる遠隔制御アセンブリ／注入ポンプアセンブリとしか発生しないことを確実にする。ＣＣ２５１０は、１バイト論理ノードアドレスをサポートしてもよく、受信パケットをフィルタにかけるレベルを提供するために、論理ノードアドレスとして無線シリアル番号の１バイトを使用することが有利であってもよい。

基板上の他のシステムによる、遠隔インターフェース８０２の基板上の雑音干渉を防止するために、Ｑｕｉｅｔ＿Ｒａｄｉｏ信号が、遠隔インターフェース８０２のＵＩプロセッサによって使用されてもよい。Ｑｕｉｅｔ＿Ｒａｄｉｏがアサートされると、遠隔インターフェース８０２の無線アプリケーションが、デバイス８００の無線にメッセージを送信して、所定の期間にわたって無線休眠（ＲａｄｉｏＱｕｉｅｔ）モードをアサートしてもよい。いくつかの実施形態では、Ｑｕｉｅｔ＿Ｒａｄｉｏ特徴は、遠隔インターフェース８０２のＰＣ基板上で測定される雑音干渉レベルに基づいて、必要とされなくてもよい。この期間中、遠隔インターフェース８０２の無線は、最大で１００ｍｓにわたって休止モード２のままであってもよい。遠隔インターフェース８０２の無線は、Ｑｕｉｅｔ＿Ｒａｄｉｏ信号がアサート停止された、または最大期間が満了したときに、休止モード２から脱してもよい。遠隔インターフェース８０２のＵＩプロセッサは、事象をアサートする必要がある前に、少なくとも１つの無線通信の間隔で、Ｑｕｉｅｔ＿Ｒａｄｉｏをアサートしてもよい。遠隔インターフェース８０２の無線は、この休眠期間中に通信がシャットダウンされることを、デバイス８００の無線に通知してもよい。周期的無線リンクプロトコルは、Ｑｕｉｅｔ＿Ｒａｄｉｏが必要とされない限りＱｕｉｅｔ＿Ｒａｄｉｏ特徴を収容する、状態ビット／バイトを有してもよい。

無線ソフトウェアは、同じプロセッサ上でメッセージングシステムおよび無線ブートローダと一体化してもよく、スループット試験を使用して検証されてもよい。無線ソフトウェアは、全て同じプロセッサ（例えば、ＴＩＣＣ２５１０）上で、メッセージングシステム、ＤＭＡを使用するＳＰＩドライバ、および無線ブートローダと一体化してもよい。

いくつかの実施形態では、遠隔インターフェース８０２の無線は、３日でわずか３２ｍＡｈを消費するように構成されてもよい（１日あたり１００分の高速ハートビートモード通信を仮定する）。いくつかの実施形態では、デバイス８００の無線は、３日でわずか２５ｍＡｈを消費するように構成されてもよい（１日あたり１００分の高速ハートビートモード通信を仮定する）。しかしながら、これらの構成は、実施形態全体を通して異なってもよく、いくつかの実施形態では、述べられた実施例を上回る、または下回ってもよい。

通信を再取得する最大時間は、接続要求モードおよび取得モードを含み、＜６．１秒であってもよいが、しかしながら、種々の他の実施形態では、最大時間は、より短いまたは長くてもよい。いくつかの実施形態では、遠隔インターフェース８０２の無線は、電力を節約し、ユーザにとっての待ち時間を最小限化するために、高速ハートビートモードまたは低速ハートビートモード設定を有利に使用してもよい。取得モードになる、デバイス８００と遠隔インターフェース８０２との間の差異は、通信が最大待ち時間内に復旧され得ることを確実にするのに十分頻繁に、デバイス８００が取得モードになる必要があることであり得る。しかしながら、遠隔インターフェース８０２は、低速ハートビートモードであり、ハートビートが失われたときに、デバイス８００とともに取得モードになる頻度を変化させてもよい。いくつかの実施形態では、遠隔インターフェース８０２の無線には、ユーザＧＵＩ相互作用の知識があってもよいが、デバイス８００にはなくてもよい。

遠隔インターフェース８０２の無線は、両方の無線に対するハートビート期間を設定してもよい。いくつかの実施形態では、期間は、活動に応じて電力およびリンク待ち時間を最適化するために、選択可能であってもよい。所望のハートビート期間は、遠隔インターフェース８０２の無線からデバイス８００の無線へと、各ハートビートにおいて伝達されてもよい。これは、どのモードになるかを判定する他の条件により、デバイス８００のハートビート比率を独占的に確立しない場合がある。高速ハートビートモードであるとき、遠隔インターフェース８０２の無線は、データパケットを送信または受信することが可能であれば、ハートビート期間を２０ｍｓに設定してもよく、したがって、データが活発に交換されているときに、少ない待ち時間の通信を提供する。

高速ハートビートモードであるとき、遠隔インターフェース８０２の無線は、データパケットが無線上で両方向性に最後に交換されてから４つのハートビート後に、ハートビート期間を６０ｍｓに設定してもよい。データパケットが送信または受信された後に、無線ハートビート期間を短く保つことにより、任意のデータ応答パケットも、少ないリンク待ち時間を使用して提供され得ることを確実にする。低速ハートビートモードであるとき、ハートビート比率は、それぞれ、オンラインまたはオフライン状態に応じて、２．００秒または６．００秒であってもよい。しかしながら、種々の実施形態では、これらの値は、異なってもよい。

デバイス８００は、遠隔インターフェース８０２の無線によって設定されるハートビート比率を使用してもよい。遠隔インターフェース８０２の無線は、いくつかの実施形態では、制限されないが、１つ以上のメッセージングシステムを介して、以下のモード要求をサポートしてもよい。
・ペアリングモード
・接続モード
・取得モード（所望のペアリングされた注入ポンプアセンブリ１００、１００’、４００、５００の無線シリアル番号を含む）
・同期モード−高速ハートビート
・同期モード−低速ハートビート
・ＲＦオフモード
注入ポンプアセンブリ１００、１００’、４００、５００の無線は、メッセージングシステムを介して、以下のモード要求をサポートしてもよい。
・ペアリングモード
・取得モード
・ＲＦオフモード

いくつかの実施形態では、無線は、ローカル無線シリアル番号を得るために、システムメッセージを使用してもよい。遠隔インターフェース８０２上で、無線は、遠隔インターフェース８０２のＵＩプロセッサからシリアル番号を得てもよい。無線は、システムメッセージを使用して、ペアリングされた無線シリアル番号を記憶してもよい。
遠隔インターフェース８０２およびデバイス８００の無線は、いくつかの実施形態では、制限されないが、１つ以上の以下の状態が変化するときは、常時、メッセージングシステムを使用して、状態メッセージを遠隔インターフェース８０２およびコマンドプロセッサ９０２のＵＩプロセッサに発行してもよい。
・高速オンライン：接続成功
・高速オンライン：取得モードから高速ハートビートモードへの変更
・低速オンライン：高速ハートビートから低速ハートビートへの変更要求の成功
・オフライン：ハートビート交換の不足による、検索同期モードへの自動変更
・高速オンライン：低速ハートビートから高速ハートビートへの変更要求の成功
・オフライン：帯域幅が同期モードで１０％を下回る
・オンライン：帯域幅が検索同期モードで１０％を上回る
・オフライン：ＲＦオフモードへの変更要求の成功

いくつかの実施形態では、無線構成メッセージは、無線再試行の数を構成するために使用されてもよい。このメッセージは、メッセージングシステム上で送信されてもよい。いくつかの実施形態では、遠隔インターフェース８０２のＵＩプロセッサは、遠隔インターフェース８０２の無線およびデバイス８００の無線の両方に、このコマンドを送信して、これらの無線設定を構成する。

いくつかの実施形態では、無線構成メッセージには、２つのパラメータ、すなわち、ＲＦ再試行の数（例えば、値は０から１０であってもよい）、および無線オフラインパラメータ（例えば、値は帯域幅の割合で１から１００であってもよい）があってもよい。しかしながら、種々の他の実施形態では、３つ以上または２つ未満のパラメータが存在してもよい。

遠隔インターフェース８０２およびデバイス８００の両方の無線アプリケーションは、メッセージングシステムがＲＦ再試行の数および無線オフラインパラメータを構成することを可能にする、ＡＰＩを有してもよい。

いくつかの実施形態では、制限されないが、以下のパラメータのうちの１つ以上が、無線ハードウェア構成に推奨されてもよい。
・基礎無線仕様
・ＭＳＫ
・２５０ｋｂｐｓ以上の無線通信比率
・最大８４個のチャネル
・１０００ｋＨｚのチャネル間隔
・８１２ｋＨｚのフィルタ帯域幅
・マンチェスター符号化方式がない
・データ消去
・４バイトプリアンブル
・４バイト同期（単語）
・パケットに付加されたＣＲＣ
・パケットに付加されたＬＱＩ（リンク品質インジケータ）
・有効化された自動ＣＲＣフィルタリング

いくつかの実施形態では、順方向誤差補正（ＦＥＣ）が、使用されても、されなくてもよい。順方向誤差補正（ＦＥＣ）は、有効信号動的範囲を約３ｄＢ増加させるために使用されるが、ＦＥＣは、固定パケットサイズを必要とし、同一固定サイズメッセージのための無線ビット数を倍にし、したがって、これは、いくつかの実施形態では、望ましくない場合がある。

いくつかの実施形態では、無線は、（ペアリングモードを除いて）公称動作条件下で１．８３メートルの距離内で機能してもよい。いくつかの実施形態では、無線が公称動作条件下で７．３２メートルの距離内で機能することが目標であってもよい。いくつかの実施形態では、伝送電力レベルは、（ペアリングモードを除いて）０ｄＢｍであってもよく、ペアリングモードの伝送電力レベルは、−２２ｄＢｍであってもよい。デバイス８００の所望の無線ノードアドレスが、ペアリングモードの遠隔インターフェース８０２によって把握されていない場合があるため、デバイス８００および遠隔インターフェース８０２の両方は、いくつかの実施形態では、別の注入ポンプアセンブリと偶発的にペアリングする可能性を低減するために、より低い伝送電力を使用してもよい。しかしながら、種々の他の実施形態では、デバイス８００または遠隔インターフェース８０２のいずれかは、より低い伝送電力を使用してもよい。

いくつかの実施形態では、ＡＥＳ暗号化は、全てのパケットに使用されてもよいが、例えば、ＴｅｘａｓＩｎｓｔｒｕｍｅｎｔｓＣＣ２５１０無線送受信機を使用する実施形態では、本送受信機は、本機能性を含むため、必要とされなくてもよい。ＡＥＳ暗号化が使用される実施形態では、固定キーは、固定キーがキーを渡すことなく暗号化を可能にする迅速な方法を提供することを含む、多くの理由から、望ましくあり得るため、固定キーが利用されてもよい。しかしながら、いくつかの実施形態では、キー交換が、デバイス８００内に提供されてもよい。いくつかの実施形態では、固定キーは、固定キーデータ以外の他の変数を伴わない、１つの別個のヘッダソースに含有されてもよく、したがって、ファイルのリードアクセスのより容易な管理を可能にする。
いくつかの実施形態では、無線ソフトウェアは、制限されないが、以下の８つのモードのうちの１つ以上をサポートしてもよい。
・ペアリングモード
・ＲＦオフモード
・接続モード
・取得モード
・高速ハートビートモード
・低速ハートビートモード
・検索同期モード
・同期化取得モード
これらの全ては、図１２Ｂ−１２Ｃに図式的に描写される。

ペアリングは、遠隔インターフェース８０２と、デバイス８００との間で無線シリアル番号を交換するプロセスであってもよい。遠隔インターフェース８０２は、デバイス８００がそのシリアル番号を把握しているとき、デバイス８００と「ペアリング」されてもよい。デバイス８００は、遠隔インターフェース８０２がそのシリアル番号を把握しているとき、遠隔インターフェース８０２と「ペアリング」されてもよい。
いくつかの実施形態では、ペアリングモード（その一実施形態は、図１２Ｄに図式的に描写される）は、以下４つのメッセージがＲＦリンク上で交換されることを要求してもよい（しかしながら、種々の実施形態は、ＲＦリンクを経由して、交換されるより多い、少ない、メッセージが交換される、または交換されないことを要求してもよい）。
・ＲＦペアリング要求（遠隔インターフェース８０２から任意のデバイス８００にブロードキャストされる）
・ＲＦペアリング肯定応答（デバイスから遠隔インターフェース８０２）
・ＲＦペアリング確認要求（遠隔インターフェース８０２からデバイス８００）
・ＲＦペアリング確認肯定応答（デバイス８００から遠隔インターフェース８０２）

加えて、遠隔インターフェース８０２は、ＲＦペアリング中断メッセージを使用して、随時、ペアリングプロセスを中断してもよい（遠隔インターフェース８０２からデバイス８００）。いくつかの実施形態では、ペアリングモードは、メッセージングシステムデータ転送をサポートしなくてもよい。

いくつかの実施形態では、デバイス８００の無線は、ペアリングモード要求メッセージの受信に応じて、ペアリングモードになってもよい。いくつかの実施形態では、デバイス８００に取着された使い捨て部分が存在せず、ユーザが、所定の時間量、例えば、６秒（実施形態全体を通して異なり得る）の間、デバイス８００のスイッチアセンブリ８１０を押下し、システムに、ペアリングモードが要求されたことを示す場合、無線にペアリングモードになるよう要求することは、デバイス８００上のスーパーバイザプロセッサ９００の責任であってもよい。デバイス８００の無線は、ペアリングモードに対する適切な伝送電力レベルを設定してもよい。いくつかの実施形態では、デバイス８００は、１度に１つの遠隔インターフェース８０２とのみペアリングされてもよい。

いくつかの実施形態では、近距離通信（「ＮＦＣ」）プロトコルが使用され、デバイス８００および遠隔インターフェース８０２がペアリングされていることを識別してもよい。例えば、ＮＦＣを使用して、ユーザは、デバイスがペアリングモードにある間、遠隔インターフェース８０２の使い捨て部分にタッチしてもよく、これは、ペアリングプロトコルをトリガし得、すなわち、デバイス８００および遠隔インターフェース８０２がペアリングされていることが、識別される。いくつかの実施形態では、遠隔インターフェース８０２上に位置する、カメラが使用され、デバイス８００上の２Ｄバーコードの画像を捕捉し、本画像および／または画像識別を使用して、デバイス８００を識別してもよい。いくつかの実施形態では、デバイス８００は、認識のために、ＮＰＣプロトコルにおいて使用され得る、ＲＦＩＤ送信機を含んでもよい。

いくつかの実施形態では、ペアリングモードにある間、第１の有効なＲＦペアリング要求メッセージの受信に応じて、デバイス８００の無線は、ペアリングモードの持続時間にわたって、遠隔インターフェース８０２のシリアル番号を使用し、デバイス８００の無線シリアル番号を含有する、ＲＦペアリング肯定応答メッセージで応答してもよい。

いくつかの実施形態では、デバイス８００の無線は、ＲＦペアリング要求が受信されない場合、所定の時間量、例えば、２．０±０．２秒後に自動的にペアリングモードからタイムアウトしてもよい。デバイス８００の無線は、ＲＦペアリング要求が受信されない場合、自動的に、例えば、２．０±０．２秒後、ペアリングモードからタイムアウトしてもよい。いくつかの実施形態では、本時間は、２．０±０．２秒未満または超であってもよい。いくつかの実施形態では、デバイス８００の無線は、ＲＦペアリング肯定応答を伝送した後に、ペアリング要求受信メッセージを発行してもよい。スーパーバイザプロセッサ９００への本メッセージは、ペアリング確認プロセス中にユーザへのフィードバックを可能にするであろう。デバイス８００の無線は、自動的に、ＲＦペアリング確認要求が受信されない限り、ＲＦペアリング肯定応答を伝送してから、例えば、１．０±０．１秒後に自動的にペアリングモードからタイムアウトしてもよい。いくつかの実施形態では、本時間は、１．０±０．１秒秒未満または超であってもよい。いくつかの実施形態では、デバイス８００の無線は、ＲＦペアリング要求メッセージを受信した後にＲＦペアリング確認要求メッセージが受信される場合、ペアリング無線シリアル番号の記憶メッセージを発行してもよい。このアクションは、遠隔インターフェース８０２の無線シリアル番号をデバイス８００の不揮発性メモリに記憶してもよく、デバイス８００の既存のペアリングデータに上書きしてもよい。

デバイス８００の無線は、ペアリング無線シリアル番号の記憶メッセージからの肯定応答が受信された後に、ＲＦペアリング確認肯定応答を伝送し、ペアリングモードを終了してもよい。いくつかの実施形態では、これは、デバイス８００上のペアリングモードからのデフォルト終了であってもよく、ユーザによって接続モードまたはペアリングモードになるまで、デバイス８００の電力を低下させてもよい。

いくつかの実施形態では、デバイス８００の無線が、ペアリング確認要求メッセージの正常受信に応じて、ペアリングモードを終了する場合、デバイス８００の無線は、新しくペアリングされた遠隔インターフェース８０２に戻ってもよく、ペアリング完了成功メッセージをコマンドプロセッサ９０２に送信してもよい。いくつかの実施形態では、デバイス８００の無線は、ＲＦペアリング中断メッセージの受信に応じて、ペアリングモードを終了してもよい。デバイス８００の無線は求メッセージの受信に応じて、ペアリングモードを終了してもよい。いくつかの実施形態では、これは、コマンドプロセッサ９０２またはスーパーバイザプロセッサ９００が、デバイス８００上でローカルにペアリングプロセスを中断することを可能にし得る。

いくつかの実施形態では、遠隔インターフェース８０２の無線は、ペアリングモード要求メッセージの受信に応じて、ペアリングモードになってもよい。いくつかの実施形態で
は、無線が適切な条件下でペアリングモードになることを要求することが、遠隔インターフェース８０２のＵＩプロセッサの責任であってもよい。遠隔インターフェース８０２の無線は、ペアリングモードに対する適切な伝送電力レベルを設定してもよい。いくつかの実施形態では、遠隔インターフェース８０２の無線は、ＲＦペアリング肯定応答が受信されるか、またはペアリングが中断されるまで、ＲＦペアリング要求を伝送してもよい。

いくつかの実施形態では、遠隔インターフェース８０２の無線は、ペアリングモードになってから、所定の時間、例えば、３０．０±１．０秒以内にＲＦペアリング肯定応答メッセージが受信されない場合、ペアリングモードを自動的に中断してもよい。しかしながら、種々の実施形態では、所定の時間は、３０．０±１．０秒超または未満であってもよい。いくつかの実施形態では、ペアリングモードにある間、最初の有効ＲＦペアリング肯定応答メッセージの受信に応じて、遠隔インターフェース８０２の無線は、デバイス８００のシリアル番号を含む、ペアリング成功メッセージを遠隔インターフェース８０２のＵＩプロセッサに送信してもよく、ペアリングモードの持続時間にわたってそのシリアル番号を使用してもよい。このメッセージは、遠隔インターフェース８０２のＵＩプロセッサがユーザに所望のデバイス８００のシリアル番号を確認させるための手段を提供してもよい。いくつかの実施形態では、遠隔インターフェース８０２の無線がデバイス８００から複数の応答（単一のペアリング要求に関して）を受信した場合、最初の有効なものが使用
されてもよい。

いくつかの実施形態では、遠隔インターフェース８０２の無線は、ペアリングモードである間にＲＦペアリング肯定応答が受信された後に、ＲＦペアリング確認肯定応答メッセージを容認するのみであってもよい。遠隔インターフェース８０２の無線は、遠隔インターフェース８０２のＵＩプロセッサからペアリング確認要求メッセージの受信に応じて、ＲＦペアリング確認メッセージを伝送してもよい。

いくつかの実施形態では、遠隔インターフェース８０２の無線は、デバイス８００をペアリングリストに追加する前に、デバイス８００がペアリングを確認することをチェックしてもよい。いくつかの実施形態では、遠隔インターフェース８０２の無線は、ＲＦペアリング完了メッセージが受信される場合、ペアリング無線シリアル番号の記憶メッセージを発行してもよい。このアクションは、遠隔インターフェース８０２のＵＩプロセッサがデバイス８００の新規シリアル番号を記憶し、成功したペアリングのユーザフィードバックを提供することを可能にしてもよい。ペアリングされた注入ポンプアセンブリのリストを管理することは、遠隔インターフェース８０２のＵＩプロセッサの責任であってもよい。したがって、システムのいくつかの実施形態では、システムは、２つ以上のデバイスを含んでもよく、２つ以上のデバイスはそれぞれ、遠隔インターフェース８０２とペアリングされてもよい。しかしながら、いくつかの実施形態では、ペアリングされたデバイスの一方のデバイスが、任意の所与の時間において、遠隔インターフェース８０２と併用されることが望ましくあり得る。したがって、これらの実施形態では、初期ペアリングプロセスが完了し、遠隔インターフェース８０２は、ペアリングされたデバイスのそのリスト上のデバイスを含むと、ユーザは、遠隔インターフェース８０２に、使用のためのその持続
時間（所定の時間量）の間、通信が所望されるデバイスを示す。

いくつかの実施形態では、遠隔インターフェース８０２の無線は、ペアリング中断要求メッセージを送信し、ペアリング中断要求メッセージの受信に応じて、ペアリングモードを終了してもよい。これは、遠隔インターフェース８０２のＵＩプロセッサが、遠隔インターフェース８０２および肯定応答されたデバイス８００の両方でペアリングプロセスを中断することを可能にしてもよい。

接続要求モードでは、遠隔インターフェース８０２の無線が、そのペアリングデバイスリストの中の各デバイス８００を取得し、その「接続準備完了」状態を回復しようとしてもよい。その一実施形態が、図１２Ｅに図式的に描写される、「接続」プロセスは、いくつかの実施形態では、遠隔インターフェース８０２が、使用される準備ができ得る、そのペアリングされたデバイスのうちの１つを迅速に識別することを可能にし得る。遠隔インターフェース８０２の無線は、複数のデバイス、例えば、いくつかの実施形態では、注入ポンプの最大６つのペアリングされた再使用可能部分と接続要求モードを行なうことが可能であってもよい。接続要求モードは、遠隔インターフェース８０２上でのみサポートされてもよく、特殊な形態の取得モードであってもよい。接続要求モードでは、遠隔インターフェース８０２は、第１のデバイスと接続して応答してもよい。しかしながら、各メッセージは、特定のデバイスシリアル番号にダイレクトされてもよい。

いくつかの実施形態では、遠隔インターフェース８０２の無線は、接続モードになると、最新のペアリングされたデバイスのシリアル番号のリストを取得してもよい。遠隔インターフェース８０２の無線は、接続モード要求メッセージの受信に応じて、接続モードになってもよい。ペアリングデバイスとの通信を所望するときに、無線が接続モードになることを要求することが、遠隔インターフェース８０２のＵＩプロセッサの責任であってもよい。遠隔インターフェース８０２の無線は、該当する場合、「接続準備完了」である、第１のデバイスの無線シリアル番号を含有する接続評価メッセージを、遠隔８０２インターフェースのＵＩプロセッサに発行してもよい。遠隔インターフェース８０２の無線は、接続要求モードになってから、所定の時間量、例えば、３０秒以内に、接続査定メッセージを発生させてもよい。しかしながら、所定の時間量は、種々の実施形態では、３０秒未満または超であってもよい。いくつかの実施形態では、遠隔インターフェース８０２の無線は、接続評価肯定応答の受信時に接続要求モードを終了し、高速ハートビートモードに遷移してもよい。遠隔インターフェース８０２の無線は、遠隔インターフェース８０２のＵＩプロセッサから接続要求中断メッセージの受信に応じて、接続要求モードを終了してもよい。

遠隔インターフェース８０２上では、特定のペアリングされたデバイスを見出すために、取得モードが使用されてもよい。いくつかの実施形態では、遠隔インターフェース８０２の無線は、ＲＦＲＵＴ（ａＲｅｙｏＵＴｈｅｒｅ）パケットを所望のペアリングデバイスに送信してもよい。デバイスが、ＲＦＲＵＴメッセージを受信する場合、遠隔インターフェース８０２の無線に応答してもよい。いくつかの実施形態では、複数のチャネルは、取得モードアルゴリズムで使用され、遠隔インターフェース８０２の無線が、ペアリングされたデバイスを見出す機会を改善してもよい。

遠隔インターフェース８０２の無線は、ＲＦオフモードである間に、取得モード要求または高速ハートビートモード要求メッセージの受信に応じて、取得モードになってもよい。遠隔インターフェース８０２の無線は、検索同期モードである間に、取得モード要求または高速ハートビートモード要求メッセージの受信に応じて、同期化取得モードになってもよい。ＲＦリンクがオフラインであり、遠隔インターフェース８０２がデバイスとの通信を所望するときに、無線が取得モードになることを要求することが、遠隔インターフェース８０２のＵＩプロセッサの責任であってもよい。

いくつかの実施形態では、特に、デバイスが、注入ポンプであるそれらの実施形態では、遠隔インターフェース８０２の無線は、１つのペアリングされた注入ポンプ８００とのみ通信してもよい（ペアリングおよび接続モードを除いて）。いくつかの実施形態では、通信が喪失されると、遠隔インターフェース８０２のＵＩプロセッサは、通信を復旧しようとするために、（電力予算によって制限される、なんらかの周期率で）取得モードを使用してもよい。
いくつかの実施形態では、デバイス８００は、以下の状態のうちの１つ以上の下、取得モードになってもよいが、種々の他の実施形態では、付加的状態が、取得モードをトリガしてもよい。
・無線オフモードであって、取得モードが要求されてもよいとき
・ハートビートの不足により検索同期モードがタイムアウトするとき

取得モードになると、デバイス８００の無線は、最後に記憶されたペアリング遠隔インターフェース８０２のシリアル番号を得てもよい。デバイス８００の無線は、（「ペアリング要求」モードである間を除いて）それが「ペアリング」されている遠隔インターフェース８０２と通信するのみであってもよい。デバイス８００の無線は、遠隔インターフェース８０２との同期化の取得が成功すると、取得モードから高速ハートビートモードに遷移してもよい。デバイス８００の取得モードは、いくつかの実施形態では、６．１秒以内に同期化を取得することが可能であってもよく、これは、取得モードであるときに、デバイス８００が、常に少なくとも約６秒ごとにリスニングしていてもよいことを示してもよい。しかしながら、種々の実施形態では、リスニングは、より短いまたは長い持続時間であってもよい。

いくつかの実施形態では、データパケットは、デバイス８００および遠隔インターフェース８０２が、同期モードで、かつオンラインであるときに、例えば、ペアリングデバイス８００と遠隔インターフェース８０２との間で送信されてもよい。２つのデバイスは、データパケットが交換される前に、ハートビートパケットを介して同期化してもよい。各無線は、ハートビート交換後に、既知の時間間隔でデータパケットを送信してもよい。デバイス８００は、パケットの受信を予期するタイミングを調整してもよい。いくつかの実施形態では、無線は、各ハートビート上で各方向に１つのデータパケットをサポートしてもよい。無線は、無線がオフラインであれば、高速ハートビートモード要求に否定応答を提供してもよい。遠隔インターフェース８０２の無線は、低速ハートビートモードであり、無線がオンラインである間に、高速ハートビートモードのシステム要求が受信される場合、高速ハートビートモードに変更してもよい。

取得モードから高速ハートビートモードに遷移すると、遠隔インターフェース８０２の無線は、マスタチャネルリストメッセージを送信してもよい。マスタチャネルリストは、遠隔インターフェース８０２の無線によって構築され、過去の性能に基づいて周波数ホッピングチャネルの選択を可能にするように、デバイス８００の無線に送信されてもよい。高速ハートビートモードまたは低速ハートビートモードであるときに、周期的ハートビートメッセージが遠隔インターフェース８０２の無線とデバイス８００の無線との間で交換されてもよい。これらのメッセージの周期性は、ハートビート比率におけるものであってもよい。ハートビートメッセージは、データパケット転送が行われることを可能にしてもよく、また、状態情報を交換してもよい。いくつかの実施形態では、２つの無線が、休眠モード、データ可用性、バッファ可用性、ハートビート比率、および以前のチャネル性能の状態情報を交換してもよいが、しかしながら、他の実施形態では、付加的情報またはより少ない情報が、交換されてもよい。いくつかの実施形態では、電力を節約するために、ハートビートメッセージのパケットサイズを小さく保つことが、目標であってもよい。これらの実施形態では、無線は、同期モードであるときに、８２バイトの最大データパケットサイズを提供してもよい。メッセージングシステムは、例えば、最大６４バイトのパケットペイロードサイズをサポートするように設計されてもよい。この最大サイズは、最小メッセージタイプと非断片化メッセージとの間の最適なトレードオフとして、選択されてもよい。いくつかの実施形態では、８２バイトは、パケットオーバーヘッドを含む、メッセージングシステムの最大パケットサイズであってもよい、しかしながら、種々の実施形態では、本最大パケットサイズは、大きいまたは小さくてもよい。

いくつかの実施形態では、メッセージングシステムは、無線プロトコルがそれに受信無線パケットを送信することを可能にする、ＡＰＩを有する。メッセージングシステムはまた、無線ネットワーク上での伝送のために、無線プロトコルがパケットを得ることを可能にする、ＡＰＩを有してもよい。メッセージングシステムは、無線プロトコルとＳＰＩポートとの間のパケットルーティングに関与してもよい。データパケットは、処理のためにメッセージングシステムに与えられてもよい。メッセージングシステムは、無線プロトコルが、無線ネットワーク上で送信されることを待機しているデータパケットの数のカウントを得ることを可能にする、ＡＰＩを有してもよい。無線プロトコルは、各ハートビートにおいてメッセージングシステムに問い合せを行い、データパケットが無線ネットワーク上で送信するために利用可能であるかどうかを判定してもよい。往復メッセージ待ち時間を最小限化するように、ハートビートが送信される直前に、ソフトウェアがメッセージの可用性をチェックすることが望ましくてもよい。

無線プロトコルは、１つの受信無線データパケットをバッファリングすること、およびメッセージングシステムにパケットをパスすることが可能であってもよい。いくつかの実施形態では、無線プロトコルは、データパケットの受信時に、メッセージングシステムにデータパケットを送信してもよい。メッセージシステムは、適正な宛先ノードに無線データパケットを送ることに関与してもよい。無線プロトコルは、メッセージングシステムからの１つのパケットをバッファリングすることが可能であってもよい。

無線プロトコルは、送信無線へのＲＦＡＣＫ返信パケットを介して、ＲＦリンク上での有効なデータパケットの受信を肯定応答することに関与してもよい。ＲＦＡＣＫパケットは、ソースおよび宛先無線シリアル番号、ＲＦＡＣＫコマンド識別、および肯定応答されているデータパケットのシーケンス番号を含有してもよい。

いくつかの実施形態では、無線データパケットを伝送する無線は、ＲＦＡＣＫが受信されず、再試行カウントが許容される最大ＲＦ再試行以内であれば、同じシーケンス番号とともに、次のハートビート上で、その無線データパケットを再伝送してもよい。干渉が、特定の周波数上の伝送を妨害する場合、いくつかの実施形態では、ＲＦ再試行は、同じパケットが、異なる周波数において次の機会で再伝送されることを可能にする。シーケンス番号は、短い時間枠でパケットを一意的に識別する手段を提供する。無線パケット再試行の数は、無線構成コマンドを使用して構成可能であってもよい。より多くの再試行を許容にすることにより、交換されているパケットの確率を増加させてもよいが、往復メッセージのさらなる待ち時間を導入する。電力増加時の無線再試行のデフォルト数は、１０であってもよい（すなわち、メッセージをドロップする前の最大伝送試行）。しかしながら、本最大数は、種々の実施形態では異なってもよい。

いくつかの実施形態では、１バイト（モジュロ２５６）無線シーケンス番号が、ＲＦリンク上の全ての無線データパケットに含まれてもよい。肯定応答されない場合、データパケット伝送を再試行することに無線が関与し得るため、シーケンス番号は、データパケットが重複するかどうかを２つの無線が把握するための方法を提供してもよい。伝送されたシーケンス番号は、それぞれの新規無線データパケットについてインクリメントされてもよく、ロールオーバーすることが可能になってもよい。以前に受信が成功したデータパケットと同じシーケンス番号とともに（かつ同じ方向で）、データパケットの受信が成功すると、データパケットが肯定応答されてもよく、受信されたデータパケットが廃棄されてもよい。これは、ネットワークに導入される前に、ＲＦプロトコルによって生成された重複パケットを除去してもよい。極限状況下で、同じシーケンス番号とともに、連続した複数のデータパケットがドロップされる必要があり得る状態が起こり得る場合があることに留意されたい。

いくつかの実施形態では、ハートビートが欠落する場合、遠隔インターフェース８０２の無線およびデバイス８００の無線は、それぞれ、後続ハートビートを送信し、リスニングしようとしてもよい。遠隔インターフェース８０２の無線およびデバイス８００の無線は、ハートビートが２秒間欠落する場合、高速ハートビートモードまたは低速ハートビートモードから検索同期モードへ自動的に変化してもよい。２秒が全てのチャネルを次々と切り替えるのに十分な時間を許容するため、これは、無線が同期化情報を使用し続けることを可能にすることによって、リンクが失われたときに電力消費を最小限化してもよい。

いくつかの実施形態では、無線は、以下のモードであるときにオンラインと見なされてもよい。
・高速ハートビートモード
・低速ハートビートモード
いくつかの実施形態では、これらは、メッセージングシステムトラフィックが交換されてもよい、唯一の状態であり得る。全ての他の状態は、オフラインと見なされてもよい。

無線は、リセットからのコード実行の開始時に、無線オフモードに初期化してもよい。コードが最初に無線プロセッサ上で実行すると、初期状態は、無線が動作中となることを要求する前に、他のプロセッサがセルフテストを行うことを可能にするように、無線オフモードであってもよい。この要件は、休止モードからウェークするときにモードを定義することを意図しない。無線は、無線オフモードに設定されると、ＲＦ通信を中止してもよい。遠隔インターフェース８０２上で、このモードは、ＲＦ放出を抑制するための航空機上、すなわち、航空機モードでの使用を意図してもよい。デバイス８００が、遠隔インターフェース８０２（航空機モードで伝送を中止する）からの伝送にしか応答しないため、無線オフモードは、充電するとき、デバイス８００上でのみ使用されてもよい。

いくつかの実施形態では、コマンドプロセッサ９０２は、航空機モード、したがって、ウォークアウェイ警告を生成しないように、ＲＦが遠隔インターフェース８０２上で意図的にオフにされたことを通知されてもよい。しかしながら、これは、デバイス８００の無線から完全に隠されてもよい。

いくつかの実施形態では、遠隔インターフェース８０２の無線およびデバイス８００の無線は、検索同期モードである間に、データ帯域幅を再確立するために、周期的にハートビートを交換しようとしてもよい。遠隔インターフェース８０２の無線は、ハートビートの交換が成功せず、所定の時間周期、例えば、検索同期モードの２０分後に、無線オフモードに遷移してもよい。

いくつかの実施形態では、デバイスの無線は、ハートビートの交換が成功せず、所定の時間量、例えば、検索同期モードの２０分後に、取得モードに遷移してもよい。いくつかの実施形態では、事前同意されたタイムスロット中にリスニングすることは、ＲＦリンクを再確立するための、デバイス８００の電力の最も効率的な使用である。通信の喪失後、結晶耐性および温度ドリフトが、経時的にデバイス８００の受信時間枠を拡張することを必要とし得る。長期間（例えば、５〜２０分）にわたって、通信喪失後、検索同期モードにとどまっていることにより、消費される瞬時電力に、デバイス８００の無線に割り当てられた平均電力を超えさせる場合がある。遠隔インターフェース８０２の無線は、その時間枠を拡張することを強いられなくてもよいため、検索同期モードにとどまっていることは、非常に電力効率が良くあり得る。取得モードは、遠隔インターフェース８０２により多くの電力を消費してもよい。いくつかの実施形態では、遠隔インターフェース８０２の無線およびデバイス８００の無線の両方で電力消費のバランスを保つために、２０分が妥協として使用されてもよいが、しかしながら、本時間は、実施形態に伴って異なってもよい。

遠隔インターフェース８０２の無線およびデバイス８００の無線は、あるハートビート群の所定のパーセンテージ、例えば、最後の５つのハートビートのうちの３つの交換が成功する場合、低速ハートビートモードに遷移してもよい。次いで、所定の間隔、例えば、約６秒ごとに、５つのハートビートのバースト（または、実施形態に応じて、それ以上、またはそれ未満）が試行されてもよい。これらの所定のパーセンテージ、例えば、これらのうちの３つが成功する場合、帯域幅が低速ハートビートに遷移するのに十分と仮定されてもよい。デバイス８００の無線は、例えば、６．１秒の待ち時間を伴う検索同期モードである間に、取得可能であってもよいが、しかしながら、本待ち時間は、実施形態に伴って異なってもよい。本実施形態では、これは、デバイス８００が、検索同期モードであるとき、常に、少なくとも約６秒ごとにリスニングしていてもよいことを示し得る。

無線プロトコル性能統計が、無線のトラブルシューティングを推進するため、および無線性能を評価するために、所望され得る。いくつかの実施形態では、以下の無線性能統計は、無線プロトコルによってデータ構造内で維持されてもよい。しかしながら、これらは、単に、一実施形態であって、これらは、実施形態全体を通して異なってもよい。いくつかの実施形態は、統計を使用しなくてもよく、あるいはより多い、少ない、または異なる統計を使用してもよい。

いくつかの実施形態では、チャネルごとに、以下の追加無線性能統計のうちの１つ以上を収集するために、＃ｄｅｆｉｎｅＤＥＢＵＧオプション（コンパイラオプション）が使用されてもよい（１６ビット数）が、しかしながら、種々の他の実施形態では、付加的情報もまた、収集されてもよい。
・欠落ホップの数
・良好ＣＣＡカウント
・不良ＣＣＡカウント
・平均ＲＳＳＩ（良好ＲＸパケットのみについて累積される）
・周波数ホップリストカウントからのドロップ
・取得モードカウント（このチャネル上で見出された１対）

いくつかの実施形態では、デバッグオプションが、エンジニアリング専用統計を収集するために使用されてもよい。プロセッサ性能、電力、およびメモリが許容する場合、本情報をランタイムに維持することが望ましくあり得る。無線統計は、メッセージングシステムに利用可能になってもよい。

いくつかの実施形態では、リンク品質は、遠隔インターフェース８０２上で使用／閲覧可能であって、携帯電話と同様に、無線リンク品質のバーインジケータを提供することを意図してもよい。リンク品質は、遠隔インターフェース８０２およびデバイス８００の両方に利用可能であってもよい。いくつかの実施形態では、リンク品質状態は、無線リンクの品質の１バイトインジケータから成ってもよい。

いくつかの実施形態では、無線は、各ハートビートごとに周波数を変化させてもよい。適応擬似乱数周波数ホッピングアルゴリズムが、同期モードのために使用されてもよく、ハートビートが、検索同期モードにおいて試行される。いくつかの実施形態では、周波数ホッピングに、例えば、６４のチャネルを使用することが目標であってもよい。しかしながら、周波数ホッピングを使用する他の実施形態では、６４超または未満のチャネルが、使用されてもよい。いくつかの実施形態では、アルゴリズムは、周波数ホッピングに関して、遠隔インターフェース８０２上でチャネルリストを適応的に発生させるように開発されてもよい。遠隔インターフェース８０２の無線は、マスタチャネルリストを構築、維持、配信してもよい。いくつかの実施形態では、以前のチャネル統計および過去の性能情報が、性能要件を満たすために、必要に応じてメッセージングシステムを使用して、遠隔インターフェース８０２の無線によって、デバイス８００の無線から取得されてもよい。デバイス８００および遠隔インターフェース８０２の両方の観点からチャネルリストを作成することによって、両ユニットの無線干渉環境が、考慮されてもよい。無線は、望ましいＲＦ環境において動作している間、ホッピングチャネルを適応的に選択し、往復メッセージ待ち時間を満たしてもよい。

次に、また、図１３を参照すると、いくつかの実施形態では、システムは、注入ポンプの少なくとも２つの再使用可能部分１３００、１３０８と、注入ポンプの少なくとも１つの使い捨て部分１３１０とを含んでもよい。いくつかの実施形態では、再使用可能部分１３００、１３０８は、再充電可能バッテリ５３２を含む。いくつかの実施形態では、２つの使い捨て部分は、図１３に１３０２として示される実施形態および／または図６−８に６００、７００、８０２として示される任意の１つ以上を含み得る、同一の遠隔インターフェースにペアリングされてもよい。いくつかの実施形態では、ユーザは、前述のように、再使用可能部分１３０８と使い捨て部分１３１０を接続するように、使い捨て部分１３１０に一致させながら、矢印１３１６の方向に、再使用可能部分１３０８を回転させることによって、再使用可能部分１３０８を使い捨て部分１３１０に接続してもよい。第２の再使用可能部分１３００は、再充電エリア１３０６内の電気接点（図示せず）を通して、再充電ステーション１３０４に接続することによって、再充電ステーション１３０４上にドッキングされてもよい。ユーザが、睡眠中、または別様に、長時間周期の間、例えば、３時間、単一エリア内に留まっている間、遠隔インターフェース１３０２は、スロット１３１８内の電気接点（図示せず）を通して、再充電ステーション１３０４に接続することにより、遠隔インターフェース１３０２を再充電ステーション１３０４上にドッキングすることによって、再充電されてもよい。いくつかの実施形態では、電気接点は、遠隔インターフェース１３０２がスロット１３１８内に配置されると、遠隔インターフェース１３０２と連結するように構成され得る、ＵＳＢプラグであってもよい。ＵＳＢプラグは、遠隔インターフェース１３０２へ／からのデータ転送ならびに遠隔インターフェース１３０２の充電を可能にしてもよい。いくつかの実施形態では、ユーザは、第２の再使用可能部分１３００を再充電しながら、一方の再使用可能部分１３０８を使用してもよい。

次に、図１４Ａ−１４Ｅを参照すると、注入ポンプシステムの別の実施形態が、示される。システムは、遠隔インターフェース１４０２と、１つの再使用可能部分１４００と、第２の再使用可能部分１４０６と、少なくとも１つの使い捨て部分１４０８と、遠隔イン
ターフェース１４０２を充電し、および／または１つまたは２つの使い捨て部分１４００、１４０６を充填するための充電ステーション１４０４とを含んでもよい。いくつかの実施形態では、充電ステーションは、２００７年１０月４日公開の米国公報第ＵＳ−２００７−０２２８０７１号（弁理士整理番号Ｅ７０）および２００９年１２月３日公開の米国公報第ＵＳ−２００９−０２９９２７７号（弁理士整理番号Ｇ７５）ならびに２０１０年１２月２９日出願の米国特許出願第１２／９８１，２８３号「ＩｎｆｕｓｉｏｎＰｕｍｐＡｓｓｅｍｂｌｙ」（弁理士整理番号Ｉ４１）（参照することによって、全体として本明細書に組み込まれる）のうちの１つ以上に図示および／または説明されるものに示される任意の充電ステーション、または任意の充電ステーションに類似してもよい。図１３に関して上記で議論されるように、充電ステーションは、遠隔インターフェース１４０２がスロット１４１４内に配置されると、遠隔インターフェース１４０２と連結するように構成され得る、ＵＳＢプラグを含んでもよい。ＵＳＢプラグは、遠隔インターフェース１４０２へ／からのデータ転送ならびに遠隔インターフェース１４０２の充電を可能にしてもよい。

次に、図１５Ａ−１５Ｂを参照すると、充電ステーション１５００の別の実施形態が、示される。示されるように、いくつかの実施形態では、充電ステーション１５００は、再使用可能部分のための充電エリア１５０４と、ＵＳＢプラグを含み得る、遠隔インターフェースのための充電エリア１５０２とを含んでもよい。いくつかの実施形態では、充電ステーション１５００は、ＵＳＢポート１５０８を含んでもよく、いくつかの実施形態では、ミニＵＳＢポートを含み、いくつかの実施形態では、ＵＳＢ１５０６を通して、再使用可能部分および／または遠隔インターフェースを充電するために、充電ステーション１５００が、電力を受容することを可能にしてもよい。加えて、および／または代替として、ＵＳＢポート１５０８は、遠隔インターフェースおよび／または再使用可能部分へ／からのデータ転送のため、および／またはコンピュータあるいは他のデバイスおよび／または他のコンピュータタイプ装置への接続によって、構成されてもよい。ＵＳＢポートを含む実施形態では、遠隔インターフェースが充電されている間、システムは、パーソナルコンピュータおよび／またはウェブポータルを呼び出し、アップデートされたソフトウェアをチェックし、アップデートされたソフトウェアが利用可能である場合、ソフトウェアアップデートをダウンロードしてもよい。これらのアップデートは、次いで、ペアリングに応じて、再使用可能部分に転送されてもよい。

次に、また、図１６Ａ−１６Ｆを参照すると、上記で議論されるように、再使用可能部分１６０２は、例えば、再充電可能バッテリを含み得る、バッテリ１６３２を含んでもよい。バッテリ充電器１６００は、バッテリ１６３２を再充電するように構成されてもよい。バッテリ充電器１６００は、上部プレート１６０４を有する、筐体１６０２を含んでもよい。上部プレート１６０４は、概して、再使用可能筐体アセンブリ１６０２の電気接点１６３４に電気的に連結されるように構成される、１つ以上の電気接点１６０６を含んでもよい。電気接点１６０６は、制限ではないが、電気接点パッド、バネ偏向電気接点部材、または同等物を含んでもよい。加えて、上部プレート１６０４は、再使用可能筐体アセンブリ１６０２のベースプレート１６１８内の開口部１６３６、１６３８と噛合するように構成され得る、整合タブ１６０８、１６１０を含んでもよい（例えば、図５Ｃに示されるように）。整合タブ１６０８、１６１０および開口部１６３６、１６３８の協働は、バッテリ充電器１６００の電気接点１６０６が、再使用可能筐体アセンブリ１６０２の電気接点１６３４と電気的に連結し得るように、再使用可能筐体アセンブリ１６０２が、バッテリ充電器１６００と整合されることを確実にし得る。

バッテリ充電器１６００は、再使用可能部分１６０２に取り外し可能に係合するように構成されてもよい。例えば、使い捨て部分と同様の様式で、バッテリ充電器１６００は、１つ以上の係止タブ（例えば、係止タブ１６１２、１６１４）を含んでもよい。係止タブ（例えば、係止タブ１６１２、１６１４）は、係止リングアセンブリ１６０６のタブ１６４２、１６４４、１６４６、１６４８によって係合されてもよい。したがって、再使用可能部分１６０２は、図１６Ｃに示されるように、係止リング１６０６を第１の係止解除位置に伴う、バッテリ充電器１６００と整合されてもよい（整合タブ１６０８、１６１０を介して）。係止リング１６０６は、矢印１６１６の方向に、バッテリ充電器１６００に対して回転され、図１６Ｄに示されるように、係止リング１６０６のタブ１６４２、１６４４、１６４６、１６４８と、バッテリ充電器１６００の係止タブ（例えば、係止タブ１６１２、１６１４）を取り外し可能に係合してもよい。

いくつかの実施形態では、バッテリ充電器１６００は、例えば、いくつかの実施形態では、再使用可能部分１６０２の圧送および弁作用構成要素を収容するための隙間を提供し得る、陥凹領域１６１８を含んでもよい。また、図１６Ｅ−１６Ｆを参照すると、バッテリ充電器１６００は、再使用可能部分１６０２の再充電バッテリ１６３２のために、電流を電気接点１６０６（それによって、電気接点１６３４を介して、再使用可能部分１６０２）に提供してもよい。いくつかの実施形態では、完全係合された再使用可能部分を示す信号が提供されないと、電流は、電気接点１６０６に提供されなくてもよい。そのような実施形態によると、短絡回路（例えば、異物が電気接点１６０６に接触することによって生じる）および再使用可能部分１６０２への損傷（例えば、電気接点１６０６と電気接点１６３４との間の不適切な初期整合から生じる）と関連付けられたリスクが、低減され得る。加えて、いくつかの実施形態では、バッテリ充電器１６００は、バッテリ充電器が、再使用可能部分１６０２を充電していないとき、不必要に電流を引き込まなくてもよい。

依然として、図１６Ｅ−１６Ｆを参照すると、バッテリ充電器１６００は、下側筐体部分１６２４および上部プレート１６０４を含んでもよい。印刷回路基板１６２２（例えば、電気接点１６０６を含んでもよい）は、上部プレート１６０４と下側筐体部分１６２４との間に含まれる空洞内に配置されてもよい。

依然として、図１６Ａ−１６Ｆを参照すると、いくつかの実施形態では、バッテリ充電器１６００は、壁充電器および／またはコンピュータおよび／またはパーソナルコンピュータおよび／または遠隔インターフェースと連結するように構成され得る、ＵＳＢプラグ１６５０を含んでもよい。ＵＳＢプラグ１６５０は、バッテリ充電器１６００を使用して、コンピュータ／遠隔インターフェース１４０２へ／からのデータ転送ならびに再使用可能部分１６０２の充電への電力の提供を可能にし得る。

また、図１７を参照すると、注入ポンプシステムの種々の部品が、相互に接続／通信する様式の一例証的実施例が示される。例えば、バッテリ充電器１７０４は、例えば、いくつかの実施形態では、ＲＳ２３２フォーマットデータを、例えば、Ｉ２Ｃフォーマットデータに変換する、バス変換装置１７０２を介して、コンピューティングデバイス１７００（いくつかの実施形態では、パーソナルコンピュータ、またはパーソナルコンピュータと類似方式で使用され得る、任意のデバイス、例えば、制限されないが、タブレットであってもよい）に連結されてもよい。バス変換装置１７０２は、上記の変換を達成する、パススループログラムを実行してもよい。バッテリ充電器１７０４は、（上記で説明される）電気接点１６０６を介して、無線プロセッサ１７１８に連結されてもよい。次いで、無線プロセッサ１７１８は、例えば、ＲＳ２３２バスを介して、スーパーバイザプロセッサ９００およびコマンドプロセッサ９０２に連結されてもよい。無線プロセッサ１７１８は、いくつかの実施形態では、スーパーバイザプロセッサ９００およびコマンドプロセッサ９０２によってアクセス可能なフラッシュメモリの更新を、無線プロセッサ１７１８が制御／編成することを可能にする、更新プログラムを実行してもよい。したがって、上記の連結の使用を通して、計算デバイス１７００によって得られるソフトウェア更新が、スーパーバイザプロセッサ９００およびコマンドプロセッサ９０２によってアクセス可能なフラッシュメモリ（図示せず）にアップロードされてもよい。上記のソフトウェア更新は、いくつかの実施形態では、スクリプトプロセスによって自動的に呼び出されてもよい、コマンドラインプログラムであってもよい。

次に、図１８および図１９を参照すると、デバイス、遠隔インターフェース、およびパーソナルコンピュータ（いくつかの実施形態では、１つ以上のウェブポータルおよび／または１つ以上のセキュアなウェブポータルへのアクセスを有する）間の通信の２つの実施形態が、示される。図１８では、遠隔インターフェース１８００は、注入ポンプ１８０２と、いくつかの実施形態では、血中グルコースメータ１８０６および持続的グルコースモニタセンサ／送信機１８０４を含み得る、２つの他のデバイスと通信する。いくつかの実施形態では、通信は、無線通信であって、ＲＦ通信、例えば、前述のようなＲＦ通信プロトコルを使用してもよく、および／またはＢＬＵＥＴＯＯＴＨ（登録商標）または他の非専用プロトコルを使用してもよい。いくつかの実施形態では、遠隔インターフェース１８００は、パーソナルコンピュータ１８０８と無線通信するが、しかしながら、いくつかの実施形態では、遠隔インターフェース１８００は、ＵＳＢ接続および／または他の有線接続を介して、パーソナルコンピュータ１８０８に接続されてもよい。いくつかの実施形態では、遠隔インターフェース１８００およびパーソナルコンピュータ１８０８は、ウェブ／インターネット接続１８１０を介しておよび／または遠隔インターフェース１８００が情報をインターネットにアップロードし、かつパーソナルコンピュータ１８０８が情報をインターネットからダウンロードすることによって、通信してもよい。

図１９では、遠隔インターフェース１９００は、注入ポンプ１９０２と通信する。注入ポンプ１９０２は、いくつかの実施形態では、血中グルコースメータ１９０６および／または持続的グルコースモニタセンサ／送信機１９０４を含み得、いくつかの実施形態では、２つの持続的グルコースモニタセンサであり得る、２つの他のデバイスと通信する。いくつかの実施形態では、通信は、無線通信であって、ＲＦ通信、例えば、前述のようなＲＦ通信プロトコルを使用してもよく、および／またはＢＬＵＥＴＯＯＴＨ（登録商標）、あるいは低エネルギーＢＬＵＥＴＯＯＴＨ（登録商標）を含むが、それらに制限されない、他の非専用プロトコルを使用してもよい。いくつかの実施形態では、遠隔インターフェース１９００と無線通信する、注入ポンプ１９０２は、２つのデバイス１９０４、１９０６から受信した情報を遠隔インターフェース１９００に通信してもよい。遠隔インターフェース１９００は、したがって、遠隔インターフェース１９００が、いくつかの実施形態では、ディスプレイを含むため、視覚ＵＩとしての役割を果たす。いくつかの実施形態では、遠隔インターフェース１９００は、パーソナルコンピュータ１９０８（いくつかの実施形態では、少なくとも１つのウェブポータルおよび／またはセキュアなウェブポータルへのアクセスを有する）と無線通信するが、しかしながら、いくつかの実施形態では、遠隔インターフェース１９００は、ＵＳＢ接続および／または他の有線接続を介して、パーソナルコンピュータ１９０８に接続されてもよい。いくつかの実施形態では、遠隔インターフェース１９００およびパーソナルコンピュータ１９０８は、ウェブ／インターネット接続１９１０を介して、および／または遠隔インターフェース１９００が情報をインターネットにアップロードし、パーソナルコンピュータ１９０８が、情報をインターネットからダウンロードすることを介して、通信してもよい。

図１８および１９の両方に関して、直接または間接的にのいずれかで、遠隔インターフェースと通信する、３つのデバイスが示されるが、システムは、３つのデバイスに制限されず、いくつかの実施形態では、４つ以上のデバイスを含んでもよい。加えて、いくつかの実施形態では、システムは、遠隔インターフェース１９００と通信する１つのデバイスを含んでもよい。また、１つのパーソナルコンピュータが、図１８および１９に図示されるが、他の実施形態では、１つ以上のパーソナルコンピュータが、情報を遠隔インターフェースから受信するために使用されてもよい。加えて、バッテリ充電器および充電ステーションに関して上記で議論されるように、いくつかの実施形態では、注入ポンプおよび／または遠隔インターフェースは、充電ステーションに接続されてもよく、ＵＳＢ接続を介して、アップロードおよび／またはダウンロードする、および／またはパーソナルコンピュータと通信されてもよい。

上記で議論されるように、注入ポンプ実施形態の種々の実施形態では、システムは、２つ以上の再使用可能部分を含んでもよい。これらの場合には、いくつかの実施形態では、一方の再使用可能部分が使用中、他方は、再充電器上にあってもよい。第１の再使用可能部分が、前述のように、使用中、治療薬が、スーパーバイザプロセッサおよびコマンドプロセッサによって投与されてもよい。再使用可能部分による作用は、遠隔インターフェースに通信される。再使用可能部分を「切り替える」ために（充電器上の再使用可能部分が、使用中の再使用可能部分となる、またはその逆となるように）、使用中、第１の再使用可能部分から情報をアップロードしたコントローラは、第２の再使用可能部分上のメモリが、第１の再使用可能部分と同一のメモリの全てを含むように、種々のログを第２の再使用可能部分上にダウンロードする。これは、ペアリングプロセスの間に行なわれる。プロセスのあるステップでは、ポンプアクティブ化後、いくつかの実施形態では、遠隔インターフェースが接続モードにある間、ユーザが再使用可能部分上のスイッチアセンブリを押下することによって行なわれる。本ステップの間、プロファイルおよびユーザ療法構成が、第２の再使用可能ポンプに転送され、および／または再使用可能部分不揮発性メモリと同期される。

本ステップが完了すると、いくつかの実施形態では、第２の再使用可能部分は、内部化後、遠隔インターフェースが、基礎プロファイルが正しいことを検証するように、基礎プロファイルを遠隔インターフェースに返送する。本ステップは、第２の再使用可能部分が、正しい情報を情報したことを確認し得る。いくつかの実施形態では、ディスプレイは、ユーザに、基礎プロファイルを示してもよく、ユーザは、確認してもよい。

したがって、療法投与に関して前述のように、注入ポンプは、全決定を完了し、注入可能流体の送達を制御する。遠隔インターフェースは、注入ポンプへのインターフェースであって、いくつかの実施形態では、デバイス（例えば、注入ポンプ）および／またはユーザと相互作用する多様な機会を伴う、向上したユーザインターフェース（例えば、ディスプレイ画面）を提供する。

療法に関連する情報は、したがって、コントローラ上および再使用可能部分／注入ポンプ不揮発性メモリ内の両方に記憶される。したがって、再使用可能部分と遠隔インターフェースとの間の接続プロセスの間、遠隔インターフェースは、再使用可能部分がアップデートされた情報を含有することを確認してもよい。遠隔インターフェースが、再使用可能部分がアップデートされた情報を含有していないと判定する場合、遠隔インターフェースは、情報をアップデートし、および／または再使用可能部分の不揮発性メモリをアップデートされた情報と同期させる。したがって、種々の実施形態では、全ての療法情報および／またはプロファイルは、注入ポンプの再使用可能部分および遠隔インターフェース上の両方に記憶されてもよい。

上記で議論されるように、デバイス８００（いくつかの実施形態では、注入ポンプである）は、注入可能流体をユーザに送達するように構成されてもよい。さらに、注入ポンプ８００は、連続および／または複数回、および／または離散注入事象および／または単回注入事象を含み得る、注入事象を介して、注入可能流体を送達してもよい。注入事象のうちのいくつかは、制限されないが、ボーラス、拡張ボーラス、基礎量、一時的基礎量、組み合わせボーラスのうちの１つ以上を含んでもよい。当技術分野で公知のように、基礎注入事象とは、例えば、ユーザによって、またはシステムによって、停止されるまで反復されてもよい、所定の間隔（例えば、３分ごと）での注入可能流体の少量の反復注入を指す。さらに、基礎注入比率は、事前にプログラムされてもよく、事前にプログラムされた時間枠に対する指定比率、例えば、午前６時〜午後３時までは毎時０．５０単位の比率、午後３時〜午後１０時までは毎時０．４０単位の比率、および午後１０時〜午前６時までは毎時１．０単位の比率を含んでもよく、および／または、例えば、１時間に０．５０単位、次いで、２時間に１．０単位、次いで、３０分間に０．０５単位という、事前にプログラムされた時間枠を含んでもよい。いくつかの実施形態では、基礎比率は、一定、例えば、毎時１．０単位のままであるように事前にプログラムされてもよく、時間枠全体を通して変化しなくてもよい。基礎比率は、別様に変更されない限り、定期的に／毎日および／または特定の日に反復されてもよい。これらの事前にプログラムされた基礎比率は、基礎プロファイルと称されてもよい。

一時的基礎比率は、所定の時間枠の間の既存の基礎プロファイル／基礎比率の修正を指す。例えば、既存の基礎プロファイルが、午前６時から午前１０までは２．０単位の比率を含む場合、一時的基礎比率は、そのパーセンテージあたりで２．０単位比率を増減のいずれかを行なうことによって、例えば、所定の時間周期、例えば、３０分にわたって、比率を２０％減少させることによって、パーセンテージあたりで２．０単位の比率を修正することが要求され得る。いくつかの事例では、一時的基礎は、基礎プロファイル比率より高いかまたは低いかのいずれかの１００％の修正を含んでもよく、したがって、いくつかの事例では、一時的基礎比率は、所定の時間周期の間、毎時０．００単位であってもよい。

当技術分野において公知のように、ボーラスは、通常ボーラスとして送達されるとき、典型的には、デバイスが流体を送達することができる比率で送達される、所定の流体の体積である。いくつかの実施形態では、所定の体積、例えば、２０単位以上のボーラス体積は、「通常ボーラス」比率よりゆっくり送達されてもよく、これは、例えば、組織中への吸収の目的のために、ユーザによって所望され得る。しかしながら、いずれの場合も、典型的には、ボーラス事象は、短い時間周期にわたって、例えば、いくつかの実施形態では、１０分以下で送達される。

さらに、当技術分野で公知のように、拡張ボーラス注入事象は、所定の時間周期（例えば、３時間）にわたって、所定の間隔（例えば、３分ごと）での少量の注入可能流体の反復注入において送達される所定の流体体積を指し得る。いくつかの拡張ボーラス注入事象は、通常ボーラスとして送達される注入可能流体の所定の体積（すなわち、通常ボーラスとして送達される拡張ボーラス体積の合計のあるパーセンテージ）に続いて、拡張ボーラス注入事象として（すなわち、所定の時間周期にわたって）送達される所定の体積の残りの体積を含んでもよい。

拡張ボーラス注入事象は、基礎注入事象と同時に発生してもよい。種々の実施形態では、種々のタイプの注入事象の送達の同時制御は、２０１０年７月１５日出願の米国特許出願第１２／８３７，１９号「Ａｐｐａｒａｔｕｓ，ＳｙｓｔｅｍｓａｎｄＭｅｔｈｏｄｓｆｏｒＡｎＩｎｆｕｓｉｏｎＰｕｍｐＡｓｓｅｍｂｌｙ」（２０１１年６月１６日公開の現米国特許公報第ＵＳ−２０１１−０１４４５７４号）（弁理士整理番号Ｉ２３）（参照することによって、全体として本明細書に組み込まれる）に説明されるようなものであってもよい。

本明細書に図示および説明される注入ポンプの種々の実施形態、ならびにまた注入ポンプの種々の実施形態は、制限されないが、２００９年３月３日発行の米国特許第７，４９８，５６３号「ＯｐｔｉｃａｌＤｉｓｐｌａｃｅｍｅｎｔＳｅｎｓｏｒｆｏｒＩｎｆｕｓｉｏｎＤｅｖｉｃｅｓ（弁理士整理番号Ｄ７８）；２００７年１２月１１日発行の米国特許第７，３０６，５７８号「ＬｏａｄｉｎｇＭｅｃｈａｎｉｓｍｆｏｒＩｎｆｕｓｉｏｎＰｕｍｐ」（弁理士整理番号Ｃ５４）；２００９年１０月９日出願のＰＣＴ出願第ＰＣＴ／ＵＳ２００９／０６０１５８号「ＩｎｆｕｓｉｏｎＰｕｍｐＡｓｓｅｍｂｌｙ」（２０１０年４月１５日公開の現公報第ＷＯ２０１０／０４２８１４号）（弁理士整理番号Ｆ５１ＷＯ）；２０１１年３月３０日出願の米国特許出願第１３／０７６，０６７号「ＩｎｆｕｓｉｏｎＰｕｍｐＭｅｔｈｏｄｓ，ＳｙｓｔｅｍｓａｎｄＡｐｐａｒａｔｕｓ」（２０１１年９月２２公開の現米国特許公報第ＵＳ−２０１１−０２３０８３７）（弁理士整理番号Ｉ７０）；２０１１年３月３０日出願の米国特許出願第１３／１２１，８２２号「ＩｎｆｕｓｉｏｎＰｕｍｐＡｓｓｅｍｂｌｙ」、（２０１１年８月２５日公開の現米国特許公報第ＵＳ−２０１１−０２０８１２３号）（弁理士整理番号Ｉ７３）；２００７年２月９日出願の米国特許出願第１１／７０４，８９９号「ＦｌｕｉｄＤｅｌｉｖｅｒｙＳｙｓｔｅｍｓａｎｄＭｅｔｈｏｄｓ」（２００７年１０月４日公開の現米国特許公報第ＵＳ−２００７−０２２８０７１−Ａ１号）（弁理士整理番号Ｅ７０）；２００８年１２月３１日出願の米国特許出願第１２／３４７，９８５号「ＩｎｆｕｓｉｏｎＰｕｍｐＡｓｓｅｍｂｌｙ」（２００９年１２月３日公開の現米国特許公報第ＵＳ−２００９−０２９９２７７−Ａ１号）（弁理士整理番号Ｇ７５）；２００９年９月１５日出願の米国特許出願第１２／５６０，１０６号「ＳｙｓｔｅｍｓａｎｄＭｅｔｈｏｄｓｆｏｒＦｌｕｉｄＤｅｌｉｖｅｒｙ」（２０１０年７月２２日公開の現米国特許公報第ＵＳ−２０１０−０１８５１４２−Ａ１号）（弁理士整理番号Ｇ４７）；２０１０年７月１５日出願の米国特許出願第１２／８３７，１９３号「Ａｐｐａｒａｔｕｓ，ＳｙｓｔｅｍｓａｎｄＭｅｔｈｏｄｓｆｏｒＡｎＩｎｆｕｓｉｏｎＰｕｍｐＡｓｓｅｍｂｌｙ」（２０１１年６月１６日公開の現米国特許公報第ＵＳ−２０１１−０１４４５７４号）（弁理士整理番号Ｉ２３）；および２０１１年１月２１日出願の米国特許出願第１３／０１１，３８４号「ＭｅｔｈｏｄａｎｄＳｙｓｔｅｍｆｏｒＳｈａｐｅ−ＭｅｍｏｒｙＡｌｌｏｙＷｉｒｅＣｏｎｔｒｏｌ」（２０１１年１２月８日公開の現米国特許公報第ＵＳ−２０１１−０３００００１号）（弁理士整理番号Ｉ４８）（全て、参照することによって、その全体として本明細書に組み込まれる）のうちの１つ以上に類似する、またはそこに説明される、それらの装置、方法、デバイスおよびシステムを含んでもよく、ならびに種々のデバイスの種々の実施形態では、遠隔インターフェースが、使用されてもよい。いくつかの実施形態では、遠隔インターフェースは、専用デバイスまたは非専用デバイスであってもよく、図６−８に関して前述のものを含んでもよい。しかしながら、いくつかの実施形態では、遠隔インターフェースは、制限ではないが、Ｍｏｔｏｒｏｌａ，Ｉｎｃ．（Ｓｃｈａｕｍｂｕｒｇ，Ｉｌｌｉｎｏｉｓ，Ｕ．Ｓ．Ａ．）によるＤＲＯＩＤＲＡＺＥＲ；ＨＴＣ（Ｔａｏｙｕａｎ３３０，Ｔａｉｗａｎ）による、ＨＴＣＧＯＯＧＬＥＮｅｘｕｓｏｎｅ；ＳＡＭＳＵＮＧＣｏｒｐｏｒａｔｉｏｎによるＳＡＭＳＵＮＧＮｅｘｕｓＳ；およびＣＡＳＩＯＣＯＭＰＵＴＥＲＣＯ．，ＬＴＤ．（東京、日本）によるＣＡＳＩＯＧ’ｚＯｎｅＣｏｍｍａｎｄｏを含み得る、オープンソースオペレーティングシステム、例えば、ＡＮＤＲＯＩＤ（登録商標）オペレーティングシステムを使用して実行され得る、多機能ウェブ接続／ウェブ対応デバイス、例えば、ＧＯＯＧＬＥＡＮＤＲＯＩＤ（登録商標）タイプデバイスまたは任意の他のデバイスであってもよい。いくつかの実施形態では、遠隔インターフェースは、タブレットまたは他のパーソナルコンピューティングデバイスであってもよく、および／またはいくつかの実施形態では、遠隔インターフェースは、任意のいわゆる「スマートフォン」タイプのデバイスであってもよい。したがって、種々の実施形態では、遠隔インターフェースは、ＧＰＳ、加速度計、電話、ウェブ接続、カメラ、電子メール等を含むが、それらに制限されない、周辺機器を含んでもよい。

次に、また、図１８および図１９を参照すると、いくつかの実施形態では、遠隔インターフェース１８００、１９００は、制限されないが、ウェブベースのセキュアなポータルを通して、および／または電子メールを通して、および／または無線通信プロトコルを介してを含む、制限ではないが、アプリケーションをダウンロードする、ソフトウェアアップデートをダウンロードする、情報をアップロードする、および／または情報を種々の機械に送信する能力を含み得る、ウェブ接続された遠隔インターフェースの能力であってもよい、あるいはそれを有してもよい。したがって、種々の実施形態では、遠隔インターフェースアプリケーションは、任意の対応デバイス上で実行されてもよく、いわゆる専用デバイスに制限されない。さらに、いくつかの実施形態では、遠隔インターフェースは、例えば、無線周波数（「ＲＦ」）通信を使用して、制限ではないが、注入ポンプ１８０２、１９０２および／または持続的グルコースモニタ送信機／センサ１８０４、１９０４（「ＣＧＭ」）および／またはＢＬＵＥＴＯＯＴＨ（登録商標）または他の通信プロトコル対応血中グルコースメータ１８０６、１９０６および／または任意の他の医療デバイスおよび／または患者ケアデバイスあるいは任意の他のデバイスの１つ以上を含み得る、１つ以上のデバイスと通信するために、ＢＬＵＥＴＯＯＴＨ（登録商標）対応またはその他に対応するものであってもよい。

図１８−１９は、パーソナルコンピュータ１８０８、１９０８、注入ポンプ１８０２、１９０２、血中グルコースメータ１８０６、１９０６および／またはＣＧＭ１８０４、１９０４と通信する、遠隔インターフェース１８００、１９００を図示するが、種々の実施形態では、遠隔インターフェース１８００、１９００は、パーソナルコンピュータ１８０８、１９０８（いくつかの実施形態では、ウェブポータルであってもよい）、注入ポンプ１８０２、１９０２、血中グルコースメータ１８０６、１９０６および／またはＣＧＭ１８０４、１９０４、および／または制限されないが、医療デバイスを含む、任意の他のデバイスのうちの任意の１つ以上のいずれか１つのうちの１つ以上と通信してもよい。さらに、いくつかの実施形態では、パーソナルコンピュータ１８０８、１９０８（いくつかの実施形態では、ウェブポータルであってもよい）、注入ポンプ１８０２、１９０２、血中グルコースメータ１８０６、１９０６および／またはＣＧＭ１８０４、１９０４のうちの１つ以上はまた、遠隔インターフェース１８００、１９００との通信に加え、パーソナルコンピュータ１８０８、１９０８（いくつかの実施形態では、ウェブポータルであってもよい）、注入ポンプ１８０２、１９０２、血中グルコースメータ１８０６、１９０６および／またはＣＧＭ１８０４、１９０４のうちの１つ以上と通信してもよい。いくつかの実施形態では、遠隔インターフェース１８００、１９００は、本明細書に説明されない１つ以上のデバイスと通信してもよいが、しかしながら、遠隔インターフェース１８００、１９００は、任意のデバイスと通信してもよいことを理解されたい。さらに、通信は、一方向および／または双方向通信として定義されてもよい。いくつかの実施形態では、ウェブポータルは、セキュアなウェブポータルであってもよい。

いくつかの実施形態では、遠隔インターフェースデバイス１８００、１９００は、データをセキュアなウェブページ／ウェブポータル／パーソナルコンピュータ１８０８、１９０９と共有してもよい。本共有されるデータは、いくつかの実施形態では、所定のおよび／または事前にプログラムされた間隔において、自動的に、転送されてもよい１８１０、１９１０（すなわち、同期される）。いくつかの実施形態では、遠隔インターフェース１８００、１９００からのデータは、いくつかの実施形態では、情報が共有されないことを確実にする、パスワードで保護されたアプリケーションによって、セキュアなウェブページ／ウェブポータル／パーソナルコンピュータ１８０８、１９０８にアップロードされる。いくつかの実施形態では、遠隔インターフェース１８００、１９００からの情報は、セキュア化されたウェブページ上に記憶されてもよく、したがって、情報は、要求に応じて、代用遠隔インターフェースおよび／または第２の遠隔インターフェースおよび／または他のデバイスにダウンロードされてもよい。したがって、いくつかの実施形態では、本システムは、遠隔インターフェース１８０８、１９０８が、故障および／または紛失に応じて、容易に交換されることを可能にする。上記で議論されるように、いくつかの実施形態では、セキュアなウェブページおよび／またはデータの転送は、パスワードまたは他のタイプのセキュリティによって、セキュア化される。

さらに、セキュアなウェブポータル／パーソナルコンピュータ１８０８、１９０８は、ユーザによって、注入ポンプ療法、ＣＧＭデータおよび／またはグルコースメータデータ（ならびに、いくつかの実施形態では、同一の場所において、遠隔インターフェース１８００、１９００および／またはセキュアなウェブページ／パーソナルコンピュータ１８０８、１９０８のいずれかに接続された付加的デバイス）を検討するために利用されてもよい。さらに、セキュアなウェブページ／パーソナルコンピュータ１８０８、１９０８は、食品ライブラリ、および／またはユーザによって、例えば、パーソナルコンピュータ上でカスタマイズされ、次いで、いくつかの実施形態では、自動的に、遠隔インターフェース１８００、１９００と同期される、ユーザカスタマイズ可能療法を含んでもよい。いくつかの実施形態では、ユーザは、ＣＧＭおよび／または注入ポンプおよび／または他のデータを編集および／または事象と「タグ付け」してもよい。これらの編集は、リアルタイムで、すなわち、事象が生じている間、または後で入力されてもよい。これらの事象は、いくつかの実施形態では、次いで、ユーザによって「命名」されてもよく、いくつかの実施形態では、療法計画が、ユーザによって、これらの事象のそれぞれに対して、事前にプログラムされてもよい。例えば、ユーザが、ピザを食している場合、ユーザは、与えられた療法と摂取されている食品を関連付けてもよく、制限ではないが、スライスの数およびスライスの原料の表示、例えば、「Ｓａｌ’ｓＰｉｚｚａ、チーズ、２切れ」を含んでもよい。したがって、ユーザは、これを遠隔インターフェース１８００、１９００に入力してもよく、いくつかの実施形態では、後で、ＣＧＭおよび／またはポンプおよび／またはグルコースメータデータを検討しながら、ユーザは、「Ｓａｌ’ｓＰｉｚｚａ、チーズ、２切れ」を食しているときに使用されるべき療法を設計してもよい。ユーザは、本事象を命名してもよく、療法が、本名称と関連付けられてもよい。したがって、ユーザは、「Ｓａｌ’ｓＰｉｚｚａ、チーズ、２切れ」事象を随時選択し、遠隔インターフェース１８００、１９００が、ピザと関連付けられた保存された療法を施行することを承認してもよい。いくつかの実施形態では、事象は、食品ライブラリにリンクされてもよく、したがって、ユーザは、食品ライブラリからのアイテムを含むにつれて、遠隔インターフェース１８００、１９００は食品アイテムと療法および／またはＣＧＭおよび／または血中グルコースメータデータを「リンク」させてもよい。上記で議論されるように、ソフトウェアおよび／またはプロファイルへの変更は、パーソナルコンピュータ（および／またはセキュアなウェブページ）１８０８、１９０８を使用して、ユーザによって行なわれてもよく、これらの変更は、遠隔インターフェース１８００、１９００上にアップロードされてもよ
い。これらの変更が、パーソナルコンピュータ（および／またはセキュアなウェブページ）１８０８、１９０８から遠隔インターフェース１８００、１９００にアップロードされると、次いで、制限されないが、注入ポンプ１８０２、１９０２を含む、遠隔インターフェース１８００、１９００に接続された他のデバイス上にダウンロードされてもよい。

いくつかの実施形態では、ウェブページではなく、遠隔インターフェース１８００、１９００上に、例えば、食品ライブラリ、および／または、直接、遠隔インターフェースデバイス上で行なわれ得る、ユーザカスタマイズ可能療法推奨に関して上記で議論されるような類似機能性を含む、専用アプリケーションが存在してもよい。これらの実施形態のうちのいくつかでは、専用アプリケーションは、例えば、いくつかの実施形態では、セキュアなウェブデータベースであり得る、ウェブデータベースから情報をダウンロードすることによって、遠隔インターフェース１８００、１９００にアップデートされてもよい。

したがって、ユーザは、事後事象分析および設計を行い、および／または分析に基づいて、療法に変更を行ってもよい。いくつかの実施形態では、ユーザは、本情報を使用して、傾向を調べ、基礎および／またはボーラスプロファイルを修正してもよい。いくつかの実施形態では、分析は、セキュアなウェブページ１８０８、１９０８を用いて、あるいはそれを通して、医師および／または介護者によって、完了されてもよい。いくつかの実施形態では、ユーザは、具体的事象および／または摂取食品に対して、データベースを「フィルタリング」し、その介護者とともに、または単独で、それらを分析し、基礎および／またはボーラスプロファイルを判定し、具体的事象および／または食品アイテムとリンクさせてもよい。したがって、いくつかの実施形態では、ユーザは、遠隔インターフェース１８００、１９００（または、セキュアなウェブページ１８０８、１９０８）を使用して、例えば、「Ｓａｌ’ｓＰｉｚｚａ、チーズ、２切れ」の全事象をフィルタリングし、療法、事象の時間ならびにその事象に対するＣＧＭプロファイルおよび／または血液メータ示度値の両方を分析してもよい。

いくつかの実施形態では、遠隔インターフェース１８００、１９００は、収集されたＣＧＭおよび／またはポンプおよび／またはグルコースメータデータと、ユーザによって入力された情報の両方から、ユーザ習慣を学習してもよい。アプリケーションおよび／またはソフトウェアは、療法変更を推奨してもよく、それらの推奨は、ユーザによって承諾または拒否されてもよい。

いくつかの実施形態では、ＣＧＭおよび／または注入ポンプおよび／または血中グルコースメータデータおよび／または事象データは、ユーザとユーザの医師および／または医療提供者との間で設定されたセキュアなウェブポータル１８０８、１９０８に配信されてもよい。いくつかの実施形態では、ユーザの医師および／または医療提供者によって使用されるセキュアなウェブポータルは、ユーザのセキュアなウェブポータルと別個であってもよい。したがって、いくつかの実施形態では、ポータルは、ユーザが、ユーザの医師および／または医療提供者によってアクセスされるセキュアなウェブポータル１８０８、１９０８からダウンロードされ、および／または遠隔インターフェース１８００、１９００と同期されるのに先立って、推奨された変更等を承諾または拒否のいずれかを行なうことを要求してもよい。

いくつかの実施形態では、ＣＧＭセンサ１８０４、１９０４は、直接、注入ポンプ１８０２、１９０２および／または遠隔インターフェース１８００、１９００と通信してもよい（図１８および１９参照）。いくつかの実施形態では、ＣＧＭセンサ１８０４、１９０４は、一方または他方と通信してもよく、いくつかの実施形態では、ＣＧＭセンサ１８０４、１９０４は、注入ポンプ１８０２、１９０２および遠隔インターフェース１８００、１９００の両方と通信してもよい。いくつかの実施形態では、安全臨界情報、例えば、アラームが、直接、注入ポンプ１８０２、１９０２に通信されてもよく、遠隔インターフェース１８００、１９００は、単に、ディスプレイとして使用されてもよい。

次に、また、図７を参照すると、いくつかの実施形態では、遠隔インターフェース１８００、１９００は、いくつかの実施形態では、ユーザによってカスタマイズ可能であり得る、少なくとも１つの加速度計ならびに複数のボタン７０６、７１０を含有する少なくとも１つの画面を含んでもよい。ボタン７０６、７１０は、いくつかの実施形態では、例えば、制限されないが、事象に関する情報を入力し、および／または単に、遠隔インターフェース５２４に、事象が生じていることを示すために、直接、特定の画面にナビゲートするために使用されてもよい。いくつかの実施形態では、本情報は、記憶され、療法／注入ポンプ情報および／またはＣＧＭおよび／または血中グルコースメータ情報と同期する能力を含み得る、セキュアなウェブページおよび／またはその他に送信されてもよい。

いくつかの実施形態では、情報は、安全性監視サービスのための遠隔インターフェース１８００、１９００に送信されてもよい。サービスは、監視を行い、データが、問題が存在し得ることを示す、例えば、低血液グルコースが示されるとき、および／または注入ポンプ警告／アラームおよび／またはＣＧＭ警告／アラームが確認されていない、例えば、アラーム／警告が、制限ではないが、アラーム／警告の受信を肯定応答するためのボタン押下および／または画面タッチを含み得る、ユーザによって肯定応答／承認がされていないとき、電話をかける、および／または遠隔インターフェース１８００、１９００にテキスト（例えば、「大丈夫ですか？」）を送ってもよい。例えば、いくつかの実施形態では、ユーザが、サービスコールおよび／またはテキストに応答しない場合、サービスは、次いで、救急サービスおよび／または両親または保護者および／または緊急連絡先に電話をかけてもよい。いくつかの実施形態では、遠隔インターフェース１８００、１９００内のＧＰＳが、ユーザを測位してもよく、したがって、救急隊員に委託され、ユーザの場所に派遣されてもよい。いくつかの実施形態では、サービスが、両親または救急隊員または緊急連絡先と連絡がとれた場合、サービスはまた、現在のＣＧＭおよび／またはポンプデータを検討のために送信してもよい。

上記で議論されるように、いくつかの実施形態では、遠隔インターフェース１８００、１９００は、ウェブ対応であってもよく（および／または遠隔インターフェース１８００、１９００上にダウンロードされる、または遠隔インターフェース１８００、１９００によってアクセスされるかのいずれかであり得る、データベースへのアクセスを有する）、いくつかの実施形態では、ユーザは、遠隔インターフェース１８００、１９００を使用して、メニューおよび／または栄養情報に容易にアクセスしてもよい。いくつかの実施形態では、本情報は、ボーラス計算機および／またはその他に「自動入力」され、炭水化物、脂肪含量等を計算し、適切な療法の判定を支援してもよい。いくつかの実施形態では、実際の計算は、デバイス（いくつかの実施形態では、注入ポンプ１８０２、１９０２であってもよい）上で行なわれてもよいが、遠隔インターフェース１８００、１９００が、ユーザが情報を入力するためのユーザインターフェースであってもよい。

いくつかの実施形態では、遠隔インターフェース１８００、１９００、セキュアなウェブページ１８０８、１９０８および注入ポンプ１８０２、１９０２は、いくつかの実施形態では、１２８ビット暗号化を用いて、暗号化されてもよい。しかしながら、他の実施形態では、暗号化は、異なってもよい。

いくつかの実施形態では、遠隔インターフェース１８００、１９００は、一連の音声表示、すなわち、音を通して、注入ポンプ１８０２、１９０２および／またはＣＧＭセンサ１８０２、１９０２５３２および／または血中グルコースメータ１８０６、１９０６を含み得る、デバイスとペアリングしてもよい。音は、各遠隔インターフェース１８００、１９００に個別化される、および／または一意であってもよく、これは、遠隔インターフェース１８００、１９００をユーザのデバイスにペアリングする際の安全性を増加させ得る。いくつかの実施形態では、ペアリングは、ＮＦＣ（近距離通信）を使用して、すなわち、デバイスおよび遠隔インターフェース１８００、１９００を近距離内で十分に近接して保持し、その２つが通信およびペアリングし得る、すなわち、通信可能となることによって達成されてもよい。

いくつかの実施形態では、遠隔インターフェースディスプレイ／画面は、ユーザに、予定された送達軌跡とともに、送達された実際の体積を示してもよい。これは、注入ポンプによって送達される流体の量に対するユーザ認識を増加させ、したがって、ユーザが、より知識に基づいた療法決定を行なうことを可能にし得る。さらに、送達された実際の体積は、医療介護提供者が、基礎レベル、インスリンと炭水化物の比等を微調整または遂行するのに有用となり得る。

いくつかの実施形態では、遠隔インターフェースは、医療デバイスではなく、通常のデバイスであるように見えるため、遠隔インターフェースは、療法を変更するために要求される、パスワード保護を含んでもよい。例えば、「療法画面」（この用語は、制限されないが、インスリン／薬物感度、炭水化物と薬物の比、薬物の持続時間、基礎プロファイル、ボーラス要求、食品ライブラリ情報、血液グルコース画面等を含む、療法への任意の変更を行うことが可能な任意の画面を指すために使用され得る）を開くために、ユーザは、いくつかの実施形態では、パスワードを入力することが要求されてもよい。いくつかの実施形態では、指紋またはその他が、使用されてもよい。いくつかの実施形態では、「タップコード」、すなわち、ある間隔において遠隔インターフェースに印加される力が、使用されてもよい（例えば、遠隔インターフェース１８００、１９００が、少なくとも１つの加速度計を含み得る実施形態では、具体的コードにおけるデバイスのタップは、情報を伝達し得る。いくつかの実施形態では、少なくとも１つの加速度計を有する遠隔インターフェース１８００、１９００に加えて、またはその代わりに、注入ポンプ１８０２、１９００２が、少なくとも１つの加速度計を含んでもよい）。

遠隔インターフェースが、ウェブ対応および／またはＢＬＵＥＴＯＯＴＨ（登録商標）対応である、いくつかの実施形態では、１つ以上のデバイス（例えば、ＣＧＭセンサ／送信機１８０４、１９０４、注入ポンプ１８０２、１９０２、血中グルコースメータ１８０６、１９０６）が、問題を被る場合、ユーザは、直接、その特定のデバイスに関するエンジニアリングログを製造業者に送信してもよい。これは、ユーザが問題を被っているデバイスを製造業者に郵送する必要性をなくし得るため、望ましくあり得る。製造業者は、受信に応じて、製造業者が問題の原因を判定すると、アラームまたはその他を止めるためのコードまたはその他をユーザに推奨してもよい。いくつかの実施形態では、遠隔インターフェースは、医療情報ではなく、エンジニアリングログのみを製造業者に送信するように事前にプログラムされたプロトコルを含んでもよい。これは、ユーザが、そのセキュアな医療情報を製造業者に非意図的に送信しないように確実にし得る。したがって、遠隔インターフェース１８００、１９００は、いくつかの実施形態では、遠隔インターフェース１８００、１９００に接続されたデバイスの全てに関するログおよび／または情報を含む。したがって、デバイスの交換は、デバイスが、ユーザによって、最小「設定」時間を伴って使用され得るように、かつ代用デバイスが、交換された古いデバイス通り機能し得る／構成され得るように、遠隔インターフェース１８００、１９００から、ログ、ユーザプロファイル、ユーザ選好等をダウンロードすることによって達成されてもよい。

いくつかの実施形態では、画面、例えば、「スクリーンショット」を、遠隔インターフェース１８００、１９００から、サービス担当者および／または製造業者に送信することが望ましくあり得る、すなわち、サービス担当者は、例えば、ウェブチャットおよび／または電話のいずれかを介して、デバイスに関する任意の問題について議論しながら、画面を確認可能であってもよい。

いくつかの実施形態では、製造業者は、遠隔インターフェース１８００、１９００に、デバイスの補正に関する指示のための「ビデオ」またはウェブサイトへのリンクを送信してもよい。いくつかの実施形態では、「ビデオ」または他の動画は、遠隔インターフェース１８００、１９００自体で利用可能であってもよく、これは、制限ではないが、デバイス１８０２、１９０２、１８０４、１９０４、１８０６、１９０６および／またはデバイスの遠隔インターフェース１８００、１９００に関するアラームおよび／または他の作用に応対するユーザおよび／または介護者に、示す／説明するおよび／または「段階的に説明」するためのビデオまたは動画を含み得る（例えば、いくつかの実施形態の図２９Ａ−２９Ｆ参照）。

さらに、いくつかの実施形態では、遠隔インターフェース１８００、１９００は、制限ではないが、医療情報を含み得る、セキュアな情報を送信するための承認されたアドレスのリストをコンパイルする能力を含んでもよい。したがって、ユーザが、正しくない電子メールアドレスまたはウェブアドレス等を非意図的に入力する場合、遠隔インターフェース１８００、１９００は、ユーザが、例えば、承認されたアドレスリスト上の新しいアドレスの入力を含み得る、さらなるステップを伴わずに、セキュアな情報を送信可能とならないように防止してもよい。いくつかの実施形態では、リストの改変は、パスワードまたはその他（タップ、指紋等）で保護されてもよい。

いくつかの実施形態では、制限ではないが、現在のグルコース示度値を含み得る、デバイス（すなわち、ＣＧＭセンサ／送信機１８０４、１９０４および／または注入ポンプ１８０２、１９０２および／または血中グルコースメータ１８０６、１９０６）のうちの１つ以上の状態は、遠隔インターフェース１８００、１９００に接続されたイヤホンおよび／または遠隔インターフェース１８００、１９００上のスピーカを通した音声音を通して示されてもよい。

いくつかの実施形態では、デバイス１８０２、１９０２、１８０４、１９０４、１８０６、１９０６は、デバイスのうちの１つ以上の近接性を示すための無線信号、いわゆる「雷鳴と閃光」と連結される、音響信号を使用して、遠隔インターフェース１８００、１９００と通信してもよい。いくつかの実施形態では、メッセージは、第１のデバイスによって、無線信号を使用して、第２のデバイスに送信されてもよい。本無線信号は、同時に、超音波「チャープ」と連結されてもよい。これは、デバイス間の距離を判定および／または計算するために使用されてもよい。本方法は、例えば、遠隔インターフェース１８００、１９００によって送信されるメッセージおよび／またはそれによって行なわれる要求が、デバイスから適切な距離にあることを確実にするために使用されてもよく、これは、デバイスの遠隔インターフェース１８００、１９００のユーザが、メッセージを送信しているかどうかを示し得る、あるいは別の（すなわち、非ユーザ）遠隔インターフェースおよび／またはデバイスが、メッセージを送信しているかどうかを示し得る。これは、遠隔インターフェース１８００、１９００によって、デバイスのうちの１つ以上の通信および制御の安全性を確実にするために使用されてもよい。例えば、ユーザが、信号／通信をその遠隔インターフェース１８００、１９００からその注入ポンプ１８０２、１９０２に送信している場合、これは、遠隔インターフェース１８００、１９００が、注入ポンプ１８０２、１９０２から特定の距離、例えば、４フィートを上回る可能性はないため、ユーザが、注入ポンプ１８０２、１９０２を装着していることを確実にし得る。したがって、システムが、前述の説明される方法を使用して、遠隔インターフェース１８００、１９００が、注入ポンプ１８０２、１９０２から閾値（いくつかの実施形態では、製造業者および／またはユーザのいずれかによって、事前決定および／または事前設定されてもよく、閾値は、いくつかの実施形態では、例えば、ユーザ独自の測定値および／または管類の長さに基づいてもよい）距離を上回ると判定および／または計算する場合、遠隔インターフェース１８００、１９００は、ユーザに警告／アラームおよび／または通知してもよい。いくつかの実施形態では、アラーム／警告はまた、未確認デバイスが注入ポンプ１８０２、１９０２と通信を試みていることを記すメッセージを含んでもよい。したがって、これは、遠隔インターフェース１８００、１９００が、受信されている通信および／またはシステム内のデバイスに伝送されている通信が、「承認されたデバイス」、すなわち、ユーザがシステム内に組み込んだ、すなわち、遠隔インターフェース１８００、１９００にペアリングされた、デバイスおよび／または遠隔インターフェース１８００、１９００とペアリングされ得る別のデバイスにペアリングされたデバイスによるものであるかどうかを判定する方法の１つであり得る。

いくつかの実施形態では、承認されていないデバイスと承認されたデバイスとの間の通信を管理する方法は、以下のようであってもよい。遠隔インターフェース１８００、１９００が、メッセージを送信するとき、デバイスと遠隔インターフェース１８００、１９０
０との間に、無線および応答の既知の遅延が存在する。例えば、デバイス１８０２、１９０２、１８０４、１９０４、１８０６、１９０６が、メッセージを受信してから、メッセージを送信するまでの時間の間の遅延が、測定され、往復時間を判定し得る。これは、遠隔インターフェース１８００、１９００とデバイス１８０２、１９０２、１８０４、１９０４、１８０６、１９０６との間の距離を判定するために使用されてもよい。測定された距離が、距離が事前にプログラムされた閾値を上回ることを示す場合、遠隔インターフェース１８００、１９００は、いくつかの実施形態では、例えば、ユーザに警告および／またはアラームしてもよい。

いくつかの実施形態では、遠隔インターフェース１８００、１９００からウェブポータル／パーソナルコンピュータ１８０８、１９０９にアップロードされた情報はまた、電子カレンダ、例えば、制限されないが、ＯＵＴＬＯＯＫカレンダまたはその他と同期されてもよい。したがって、ユーザの生活における事象が、システムに接続されたデバイス１８０２、１９０２、１８０４、１９０４、１８０６、１９０６のデータにリンクされてもよい。これは、生じた事象を示し、分析のために、データに関連性および広がりをもたらすために望ましくあり得る。また、ユーザが、遠隔インターフェース１８００、１９００に事象を入力していない場合があっても、事象が、電子カレンダ上にある場合、事象が、検討および分析のために、自動的に、データとともに入力されてもよい。例えば、ユーザのカレンダが、「サッカーの練習」を示し得るが、サッカーの練習の間、ユーザが、遠隔インターフェース１８００、１９００上に事象を示していなかった場合、遠隔インターフェース１８００、１９００からウェブポータル／パーソナルコンピュータ１８０８、１９０８へのデータのアップロードに応じて、遠隔インターフェース１８００、１９００からのデータは、例えば、送達された流体の量（基礎比率であってもよい）および血液グルコースデータ、例えば、ＣＧＭセンサ／送信機１８０４、１９０４からのデータおよび／または血中グルコースメータ１８０６、１９０６からのデータを表すエリアの上方に、例えば、デバイスからの情報およびデータを容易に閲覧するように設計されたソフトウェアプログラムに、事象「サッカーの練習」を組み込んでもよい。したがって、ユーザは、一代表的グラフでは、例えば、薬物送達データ、ＣＧＭ、および血液グルコースデータとともに、ユーザがその時間に行なっていたことの表示を閲覧してもよい。

したがって、ユーザは、遠隔インターフェース１８００、１９００をパーソナルコンピュータ１８０８、１９０８に接続し、および／または、いくつかの実施形態では、データを遠隔インターフェース１８００、１９００からウェブポータルまたはその他にアップロードしてもよい。いくつかの実施形態では、これは、遠隔インターフェース１８００、１９００の「再充電」の間、達成されてもよく、これは、いくつかの実施形態では、パーソナルコンピュータ１８０８、１９０８へのＵＳＢ接続を使用して行なわれてもよく、充電／再充電に加えて、遠隔インターフェース１８００、１９００は、データを同期および／またはパーソナルコンピュータ１８０８、１９０８および／またはウェブポータルからアップロード／ダウンロードし得る。本時点において、システムは、デバイスのうちの１つ以上および／または遠隔インターフェース１８００、１９００のためのソフトウェアアップデートが利用可能であることを判定してもよい。ユーザは、「アップデートをダウンロードする」を選択してもよく、これらは、再び、充電のとき、および／または遠隔インターフェース１８００、１９００が、直接または間接的にのいずれかにおいて、パーソナルコンピュータ１８０８、１９０８および／またはシステム専用に設計されたウェブポータルに接続される任意の時間に、遠隔インターフェース１８００、１９００にダウンロードされてもよい。上記で議論されるように、遠隔インターフェース１８００、１９００は、種々のデバイスと通信可能である。したがって、ソフトウェアアップデートは、遠隔インターフェース１８００、１９００によって、任意の１つ以上のデバイスに通信されてもよい。これは、制限されないが、データ／情報をデバイスの全てからアップロードし、および／またはアップデートおよび／またはアプリケーションをパーソナルコンピュータおよび／またはインターネット／ウェブポータルからデバイスのいずれかにダウンロードする両方のために、遠隔インターフェース１８００、１９００をパーソナルコンピュータ／ウェブポータル１８０８、１９０８に接続する必要のみあることを含む、多くの利点を有する。これは、１つの接続から全デバイスを効率的かつ容易にアップデートする能力、および／または１つの場所において、全デバイスからのデータの全てを閲覧する能力、および／または遠隔インターフェースを通して、情報および／または設定をパーソナルコンピュータ／ウェブポータルからデバイスのいずれかにダウンロードする能力を含むが、それらに制限されない、多くの理由から、望ましくあり得る。

したがって、いくつかの実施形態では、パーソナルコンピュータ／ウェブポータルは、随時、制限されないが、遠隔インターフェースを含む、全デバイスからの全情報を含有するため、新しい「遠隔インターフェース」が、システムに導入されてもよい。これは、新しい遠隔インターフェースをパーソナルコンピュータ／ウェブポータルに接続し、システムに関する全情報を遠隔インターフェースにダウンロードすることによって達成されてもよい。いくつかの実施形態では、これは、最初に、古い遠隔インターフェースが、「承認されたデバイス」から除去されることを要求し得るが、しかしながら、他の実施形態では、システムは、ユーザからの許可によって、付加的遠隔インターフェースを「許容」してもよい。したがって、システムは、デバイスに通信可能であって、パーソナルコンピュータおよび／またはウェブポータルに接続可能である、任意のインターネット接続され、および／または遠隔のインターフェースに、全情報およびアプリケーションをダウンロードする能力を含む。

これはまた、遠隔インターフェースが、任意のアプリケーションをインターネットからシステム内の任意のデバイスにダウンロードすることを可能にする。したがって、システムの種々の実施形態では、ユーザは、任意の装置（パーソナルコンピュータおよび／またはウェブポータルに無線通信し、接続する能力等のいくつかのパラメータを含む）を種々のデバイス、例えば、注入ポンプを制御し、および／またはデータをＣＧＭセンサ／送信機、および／または他の検体センサ、および／または他のデバイスから受信し、および／または制御し得る、デバイスにすることができる。いくつかの実施形態では、遠隔インターフェースおよび／または遠隔インターフェース上の１つ以上のアプリケーションは、パスワードまたはその他で保護されてもよく、１つ以上のデバイスとペアリングされる、例えば、注入ポンプおよび／またはＣＧＭセンサおよび／または１つ以上の他のデバイスとペアリングされる。

いくつかの実施形態では、遠隔インターフェース上の情報は、アップロードされ、および／または、制限されないが、パスワードで保護され得る、インターネットサイト（ウェブポータル）へのデータのアップロードを含め、別のデバイスおよび／またはコンピュータおよび／または機械と同期されてもよい。したがって、ユーザは、任意のデバイスからの情報にアクセスしてもよく、および／または任意のデバイス専用アプリケーションを含む、情報を任意のデバイスにダウンロードしてもよく、したがって、ユーザ情報は、制限されないが、履歴、好ましい設定等の情報を含め、任意のデバイスにダウンロードされてもよい。

システムのいくつかの実施形態では、血中グルコースメータ１８０６、１９０６が、含まれてもよく、これは、ユーザインターフェースではなく、細片リーダおよび機能するための最小構成要素のみを含み得る。いくつかの実施形態では、血中グルコースメータ１８０６、１９０６は、遠隔インターフェース１８００、１９００と通信し、遠隔インターフェース１８００、１９００ディスプレイは、示度値を示し、および／またはいくつかの実施形態では、遠隔インターフェース１８００、１９００は、制限ではないが、血中グルコースメータ１８０６、１９０６示度値のグラフィカル表現および／または履歴データならびにユーザ選好等を含み得る、血中グルコースメータ１８０６、１９０６より広範囲の機能を含む。

システムは、上記で議論されるように、注入ポンプシステムの例示的形態をとるが、種々の実施形態では、デバイスは、任意の医療デバイスを含む、任意のデバイスであってもよく、および／または示される図に表されるデバイスの数を上回るまたは下回ってもよい。

上記で議論されるように、種々の実施形態では、遠隔インターフェース１８００、１９００は、タブレットコンピュータまたは多機能ウェブ接続／ウェブ対応デバイスを含んでもよく、例えば、いくつかの実施形態では、遠隔インターフェースは、ＤＲＯＩＤＲＡＺＥＲであってもよい。いくつかの実施形態では、１つ以上の周辺機器は、遠隔インターフェースが、システム内のデバイスのうちの１つ以上、例えば、医療デバイスと通信している間、オフにされてもよく、および／または「スリープ」してもよい。いくつかの実施形態では、アンテナおよび／または無線通信ソフトウェアは、例えば、前述のような、または参照することによって組み込まれる情報のいずれかにおける、専用バージョンに修正されてもよい。いくつかの実施形態では、無線通信は、遠隔インターフェースデバイス自体内にあるもの、例えば、ＢＬＵＥＴＯＯＴＨ（登録商標）低エネルギー無線通信プロトコルであってもよい。いくつかの実施形態では、本通信プロトコルとともに、変換装置が、システム内のデバイスのうちの１つ以上上の専用プロトコルに変化するために含まれてもよい。いくつかの実施形態では、メッセージングは、本明細書で論じられるプロトコルを通して、または類似プロトコルを通して、および／または遠隔インターフェースデバイスからのプロトコルを使用して、達成されてもよい。

遠隔インターフェースは、したがって、種々の実施形態では、カラータッチスクリーンを含み得る、ディスプレイアセンブリを含む。いくつかの実施形態では、遠隔インターフェースは、加えて、少なくとも１つのスイッチアセンブリを含む。いくつかの実施形態では、遠隔インターフェースは、１つ以上のデバイスのための動画化された「設定」指示を含む。加えて、いくつかの実施形態では、遠隔インターフェースは、制限ではないが、アラーム状態をチェックおよび／または確認し、および／またはそこから復元するためのユーザへの指示を含み得る、アラーム復元および／またはアラーム動画を含む。これらの動画は、制限ではないが、文書／文字指示および／または音声指示を含んでもよい。いくつかの実施形態では、グラフィカルユーザインターフェースは、異なる状態を表すための異なる色背景、例えば、アラームのための「赤色」、アイドル状態のための「青色」、送達／作用のための「緑色」等を提示してもよい。いくつかの実施形態では、前述の機能のうちの１つ以上は、加えて、制限ではないが、音声指示、ビープ音等を含み得る、音／音声を含んでもよい。

次に、図２０Ａ−３０を参照すると、注入ポンプ、例えば、本明細書に説明される注入ポンプの実施形態のうちの１つ用の遠隔インターフェースのためのグラフィカルユーザインターフェースのいくつかの実施形態としての役割を果たす、種々の「スクリーンショット」が、描写される。いくつかの実施形態では、血中グルコースメータ用の遠隔インターフェースのためのスクリーンショットが、示される。いくつかの実施形態では、画面は、指示インターフェースとして使用されてもよい。

次に、図２０Ａ−２２Ｈを参照すると、いくつかの実施形態では、遠隔インターフェースは、デバイスに関するある作用を行なうための方法をユーザに実証するための動画および／または写真／グラフィカル指示を含んでもよい。いくつかの実施形態では、これらの動画および／または写真／グラフィカル指示は、ナレーションおよび／または音声を含んでもよく、および／またはテキストならびに文書指示を含んでもよい。図２０Ａ−２２Ｈは、注入ポンプを設定するためのグラフィカルユーザインターフェース（ＧＵＩ）のいくつかの実施形態および／または実施形態の実施例を含む。これらの実施例は、例証的スクリーンショットとして示され、種々の実施形態は、示される文字および／または写真に限定されない。また、スクリーンショットの順序は、実施形態全体を通して異なってもよい。加えて、いくつかの実施形態では、種々のスクリーンショットは、以下のボタン：「戻る（ｂａｃｋ）」、「中止（ｃａｎｃｅｌ）」、および／または「次へ（ｎｅｘｔ）」ボタンのうちの１つ以上を含んでもよい。これらの実施形態では、任意の画面上において、ユーザは、戻る、画面を中止する、および／または次の画面に進むことを選択してもよい。動画が含まれる、いくつかの実施形態では、動画は、ユーザが、ボタン、例えば、戻る、中止、および／または次へを選択するまで、無限に再生してもよい。いくつかの実施形態では、ボタンは、ハイライトされる、および／またはハイライト解除されてもよい（図中に点線として表されてもよい）。

次に、図２０Ａ−２０Ｍを参照すると、使い捨て部分（リザーバとも称され得る）を充填し、使い捨て部分に呼水を差すためのグラフィカル指示が、示される。図２０Ａを参照すると、いくつかの実施形態は、ユーザに、その手を洗浄するように指示する、少なくとも１つの画面を含む。いくつかの実施形態では、その手を洗浄するユーザを示す、少なくとも１つの画面が含まれ、ユーザに、その手を石鹸およびお湯で洗浄するように指示してもよい。いくつかの実施形態では、画面は、その手を石鹸および水で洗浄するユーザを示す、動画を含んでもよい。図２０Ｂを参照すると、いくつかの実施形態は、ユーザに、使い捨て部分のカバーおよび蓋を除去するように指示する、少なくとも１つの画面を含む。いくつかの実施形態では、画面は、使い捨て部分を示してもよい。本実施形態では、画面は、パッケージング内の使い捨て部分の実施形態を示し、ユーザに、カバーおよび蓋をパッケージから除去するように指示する。いくつかの実施形態では、本実施形態は、動画であって、いくつかの実施形態では、グラフィカル動画は、パッケージから除去されているカバーおよび蓋を示す。次に、図２０Ｃを参照すると、いくつかの実施形態は、パッケージの基部が蓋に取り付けられる様子を示す、少なくとも１つのスクリーンショットを含む。いくつかの実施形態では、本実施形態は、動画であって、いくつかの実施形態では、グラフィカル動画は、蓋に取り付けられるパッケージの基部を示す。次に、図２０Ｄを参照すると、いくつかの実施形態は、清浄される（注入可能流体の）バイアルを示す、少なくとも１つの画面を含む。本実施形態では、画面は、バイアルおよびアルコール消毒綿の実施形態を示し、ユーザに、インスリンバイアルの上部をアルコール消毒綿で清浄するように指示する。いくつかの実施形態では、本実施形態は、アルコール消毒綿で清浄されているバイアルの動画である。次に、図２０Ｅを参照すると、いくつかの実施形態は、パッケージ内の注射器を示す、少なくとも１つの画面を含む。本実施形態では、画面は、パッケージ内の注射器の実施形態を示し、ユーザに、注射器をパッケージから除去し、針を接続するように指示する。いくつかの実施形態では、本実施形態は、パッケージから除去される注射器および接続される針の動画である。次に、図２０Ｆを参照すると、いくつかの実施形態は、注射器およびバイアルを示す、少なくとも１つの画面を含む。本実施形態では、画面は、バイアルおよび注射器の実施形態を示し、ユーザに、注射器を最大３日分の供給量のインスリンで充填するように指示する。リザーバは、最大３ｍＬを保持することができる。注射器内のいかなる気泡も除去する。いくつかの実施形態では、本実施形態は、バイアルからのインスリンで充填される注射器の動画である。

次に、図３０を参照すると、いくつかの実施形態では、流体で充填された（「充填された」とは、必ずしも、容量を意味するものではなく、「充填された」とは、注射器および／またはリザーバに装填された任意の体積の流体を指すために使用され得る）注射器と、ユーザによって保持され、注射器の写真を撮影する、注射器の近傍に置かれた遠隔インターフェースの実施形態を示し得る、少なくとも１つの画面が、含まれてもよい。いくつかの実施形態では、本実施形態は、遠隔インターフェースおよび注射器の動画であって、遠隔インターフェースは、注射器の写真を撮影する。いくつかの実施形態では、少なくとも１つの画面は、ユーザに、注射器の写真を撮影するように指示してもよい。いくつかの実施形態では、ユーザが、本画面に到達すると、遠隔インターフェースは、ユーザが、次いで、ディスプレイアセンブリ内のファインダを確認し、充填された注射器の写真を撮影し得るように、自動的に、カメラモードに入ってもよい。いくつかの実施形態では、遠隔インターフェースは、写真が容認可能であるかどうか確認してもよい。いくつかの実施形態では、遠隔インターフェースが、「充填された注射器の写真を撮影する」画面から、カメラモードに入ると、カメラモードは、「オートフォーカス」モードになってもよく、および／またはいくつかの実施形態では、本タスク専用に設計される、パターン認識ソフトウェアが、注射器内の流体レベルを判定し得るような解像度で写真を撮影するように設計された専用カメラモードになってもよい。いくつかの実施形態では、本認識ソフトウェアは、２Ｄバーコードを読み取るために使用されるソフトウェアに類似してもよい。いくつかの実施形態では、遠隔インターフェース上のカメラは、他の目的のために、例えば、例えば、使い捨て部分および／または再使用可能部分上の２Ｄバーコードを走査するために（例えば、いくつかの実施形態では、これは、遠隔インターフェースとペアリングされたデバイスのために使用されてもよい）、および／またはシステムが注入ポンプを含むかどうか、インスリンおよび／または注入可能流体バイアルおよび／またはシステムの種々の実施形態において使用され得る他の周辺機器上の２Ｄバーコードを走査するために、使用されてもよい。

次に、また、図３１−３４を参照すると、いくつかの実施形態では、基礎プロファイルが、遠隔インターフェース３００４内のカメラと、制限されないが、２Ｄバーコード（その実施例は、例証目的のためだけに与えられる、図３１のアイテム３０００および図３２のアイテム３００２を参照されたい）を含む、バーコード３０００を使用して、遠隔インターフェースに入力されてもよい。種々の実施形態では、２Ｄバーコードは、ユーザの医師による処方箋によって生成されてもよい。いくつかの実施形態では、２Ｄバーコードは、ユーザに通信されてもよく、その通信機構は、制限ではないが、２Ｄバーコードのハードコピーを提供する、および／または２Ｄバーコードを、例えば、電子メール内および／またはセキュアなウェブポータル上に提供することを含んでもよい。種々の実施形態では、遠隔インターフェース３００４内のカメラは、２Ｄバーコード３０００、３００２を読み取る。２Ｄバーコードは、バーコード読取ソフトウェアによって読み取られると、遠隔インターフェースによって必要とされる情報を提供し、基礎プロファイルをプログラムする、２Ｄバーコード内に埋め込まれた埋込処方箋基礎プロファイルを含む。含まれ得る２Ｄバーコード内に含まれる情報の実施例は、図３３に３００６として示される。情報は、制限ではないが、ユーザの氏名、生年月日、プロファイルタイプ、プロファイルの有効期限、および時間枠別に与えられる毎時比率のうちの１つ以上を含んでもよい。いくつかの実施形態では、２Ｄバーコードが、有効期限を含む場合、遠隔インターフェースは、ユーザが、上記で議論されるように、その医師に、アップデートされた基礎プロファイル２Ｄバーコードを入力するように促し得るように、有効期限が近づくと、ユーザに警告／アラームしてもよい。種々の実施形態では、プロファイルの有効性が切れると、遠隔インターフェースは、アップデートされたプロファイル処方箋が入力されない限り、圧送を停止してもよい。種々の実施形態では、ユーザは、例えば、制限ではないが、平日、週末、運動、シックデイ等を含み得る、それぞれ、異なる基礎プロファイルを含む、複数の２Ｄバーコードを受信してもよい。いくつかの実施形態では、単一２Ｄバーコードが、２つ以上の基礎プロファイルをエンコードしてもよい。種々の実施形態では、前述のシステムは、３Ｄバーコードを使用してもよく、他の実施形態では、システムは、ＱＲコード（登録商標）、すなわち、「クイックレスポンスコード」を使用してもよい。本システムは、手動プログラミングエラーの事例を防止または減少させる（例えば、ユーザが処方箋を手動で入力する場合、複写エラーがあり得る）ことを含むが、それらに制限されない、多くの理由から、有益であり得る。しかしながら、２Ｄバーコードを使用して、プログラミングエラーは、排除され、したがって、システムは、手動入力より安全であり得る。加えて、システムは、電子メールで送られ得る、および／またはユーザに電子的に、例えば、セキュアなウェブポータルにおいて利用可能であり得る、処方箋に有益であり得る。いくつかの実施形態では、システムは、ユーザに、システムが２Ｄバーコードを読み取る前に、パスコード／パスワードを入力することを要求してもよい。これは、処方箋バーコードが、誤った遠隔インターフェースに読み取られ、プログラムされないように防止するために有益であり得る。いくつかの実施形態では、遠隔インターフェース３００４が、２Ｄバーコード３０００、３００２を読み取ると、遠隔インターフェース３００４は、ユーザが検討するために、基礎プロファイルをグラフィカル形態で表示してもよい。

次に、また、図３４を参照すると、いくつかの実施形態では、遠隔インターフェース３００４は、カメラを使用して、例えば、紙上または電子形式で提示されるかどうかにかかわらず、基礎プロファイル３００８の写真をグラフィカル形態で撮影してもよい。遠隔インターフェース３００４は、いくつかの実施形態では、基礎プロファイル３００８のパラメータを認識し得、意図された基礎プロファイル３００８が、自動的に、遠隔インターフェース３００４に入力されるように、基礎プロファイル３００８を遠隔インターフェース３００４にプログラムし得る、認識ソフトウェアを含んでもよい。本システムは、手動プログラミングエラーの事例を防止または減少させる（例えば、ユーザが処方箋を手動で入力する場合、複写エラーがあり得る）ことを含むが、それらに制限されない、多くの理由から、有益であり得る。しかしながら、遠隔インターフェース３００４によって読み取られる基礎プロファイル３００８を使用して、プログラミングエラーは、排除され、したがって、システムは、手動入力より安全であり得る。いくつかの実施形態では、遠隔インターフェース３００４が、基礎プロファイル３００４を読み取ると、遠隔インターフェース３００４は、ユーザが検討するために、基礎プロファイル３００８をグラフィカル形態で表示してもよい。いくつかの実施形態では、システムは、システムが基礎プロファイル３００８を読み取る前に、パスコード／パスワードを入力することを要求してもよい。これは、処方箋基礎プロファイルが、ユーザの同意なく、遠隔インターフェースに読み取られ、プログラムされないように防止するために有益であり得る。

次に、図２０Ｇを参照すると、いくつかの実施形態は、ユーザに、基部リザーバを充填するように指示する、少なくとも１つの画面を含む。いくつかの実施形態では、画面は、リザーバパッケージの中の充填補助具内の注射器の実施形態を示し、ユーザに、注射器を充填補助具内に挿入し、インスリンを基部リザーバに移すように指示し得る（注射器はまだ除去されない）。いくつかの実施形態では、本実施形態は、充填補助具内に挿入される注射器と、プランジャを基部に向かって移動させ、インスリンを基部リザーバに移す動画である。

次に、図２０Ｈを参照すると、いくつかの実施形態は、泡を充填されたリザーバから除去する注射器を示す、少なくとも１つの画面を含む。本実施形態では、画面は、リザーバパッケージの中の充填補助具内の注射器の実施形態を示し、ユーザに、リザーバの泡をチェックし、いかなる気泡も注射器内に引き戻すように指示する。いくつかの実施形態では、本実施形態は、ユーザがリザーバ泡をチェックし、気泡を注射器内に引き戻す動画である。

次に、図２０Ｉを参照すると、いくつかの実施形態は、注射器および「鋭利物」容器を示す、少なくとも１つの画面を含む。本実施形態では、画面は、ユーザが注射器を鋭利物容器に隣接して保持する実施形態を示し、ユーザに、注射器を除去し、針を鋭利物容器内に廃棄するように指示する。いくつかの実施形態では、本実施形態は、ユーザが注射器を除去し、針を鋭利物容器内に廃棄する動画である。

図２０Ｊを参照すると、いくつかの実施形態では、ユーザに、リザーバ体積を入力するように要求する画面が、含まれてもよい。いくつかの実施形態では、図２０Ｊに示されるように、キーパッドが、含まれてもよく、ユーザは、ディスプレイが、単位として、いくつかの実施形態では、リザーバに移された流体の体積を反映するように、適切な数字ボタンをタッチしてもよい。いくつかの実施形態では、システムは、入力された体積を充填された注射器の画像から判定された体積と比較してもよい。いくつかの実施形態では、２つの体積が、誤差の閾値、例えば、＋または−０．５単位以内である場合、システムは、一方または他方のいずれかに依拠してもよく、いくつかの実施形態では、ユーザ入力（例えば、図２０Ｊにおけるキーパッド上の単位入力）に依拠してもよい。いくつかの実施形態では、遠隔インターフェースは、２つの数字の間の差異が閾値を超える場合、ユーザに、再入力を促す、または「間違いないですか？」と尋ねてもよい。これは、リザーバに移された流体の体積の確認のために望ましくあり得る。

次に、図２０Ｋを参照すると、いくつかの実施形態では、ユーザインターフェースは、リザーバ体積とともに、少なくとも１つの確認画面を含んでもよく、いくつかの実施形態では、「リザーバ体積を修正する」ためのボタンを含んでもよく、これは、いくつかの実施形態では、異なる体積値を入力するための画面、例えば、図２０Ｊに示される画面にユーザを導いてもよい。

次に、図２０Ｌを参照すると、いくつかの実施形態は、ユーザに、使い捨て部分に呼水を差すように指示する、少なくとも１つの画面を含む。本実施形態では、画面は、使い捨て部分／リザーバ上の充填補助具を押下する親指／手と、注入セットコネクタのキャプションを示し、インスリンの液滴が、注入セットコネクタから可視となるまで、ユーザに、充填補助具上の呼水ボタンを長押しするように指示する。いくつかの実施形態では、本実施形態は、インスリンの液滴が、注入セットコネクタから可視となるまで、充填補助具上の呼水ボタンを長押しする親指／手の動画である。

次に、図２０Ｍを参照すると、いくつかの実施形態は、ユーザに、充填補助具を除去するように指示する、少なくとも１つの画面を含む。本実施形態では、画面は、使い捨て部分／リザーバ上の充填補助具を回転させる手を示し、ユーザに、充填補助具を反時計回りに回転させることによって、充填補助具を基部から除去し、充填補助具を廃棄するように指示する。いくつかの実施形態では、本実施形態は、充填補助具を反時計回りに回転させることによって、充填補助具を基部から除去し、充填補助具を廃棄する手の動画である。

次に、図２０Ｎを参照すると、いくつかの実施形態は、ユーザに、ポンプを基部に取り付けるように指示する、少なくとも１つの画面を含む。本実施形態では、画面は、ポンプを基部に取り付けるユーザを示し、「ロック」および「ロック解除」位置アイコンの拡大図であり得る、挿絵／キャプションを含み、ユーザに、最初に、保護防塵カバーまたは充電器を除去し、次いで、ポンプを基部に取り付け、ロック位置に回転させるように指示する。ポンプは、基部が定位置にあることを検出すると、確認トーンを再生するであろう。いくつかの実施形態では、本実施形態は、最初に、保護防塵カバーまたは充電器を除去し、次いで、ポンプを基部に取り付け、ロック位置に回転させる手の動画である。

次に、図２０Ｏを参照すると、いくつかの実施形態は、ユーザに、ポンプボタンを押下するように指示する、少なくとも１つの画面を含む。本実施形態では、画面は、再使用可能部分上のポンプボタンを押下するユーザを示し、ユーザに、ポンプボタンを長押しすることによって、ポンプをアクティブ化するように指示する。ポンプボタンは、アクティブ化されると、音を再生するであろう。いくつかの実施形態では、本実施形態は、ポンプボタンを長押しすることによって、ポンプをアクティブ化する手の動画である。

次に、図２０Ｐを参照すると、いくつかの実施形態は、ユーザに、ポンプがアクティブ化されたことを示す、少なくとも１つの画面を含む。本実施形態では、画面は、ポンプ振動または音の再生を示し、ユーザに、ポンプがアクティブ化されたことを示し、次のボタンを押下し、設定に進むように指示する。

次に、図２０Ｑを参照すると、いくつかの実施形態は、ユーザに、ポンプ試験を開始させることを要求する、少なくとも１つの画面を含む。本実施形態では、画面は、ユーザに、カニューレが管類セットに接続されていないことを確認するように指示する注意標識を示す（ポンプ試験は、少量のインスリンを送達するであろう）。画面上のボタンは、ユーザが、注意に従ってから、ポンプ試験を開始するために押下すべきことを示す。

次に、図２０Ｒを参照すると、いくつかの実施形態は、ポンプが、ポンプ自己試験を行なっていることを記す、少なくとも１つの画面を含む。本実施形態では、画面は、ユーザに、カニューレが管類セットに接続されていないことを確認するように指示する注意標識を示し（ポンプ試験は、少量のインスリンを送達するであろう）、また、ポンプが、ポンプ自己試験を行なっていることを示す。試験は、概して、約１分かかるであろう。

次に、図２０Ｓを参照すると、いくつかの実施形態は、ポンプ試験が完了したことを記す、少なくとも１つの画面を含む。本実施形態では、画面は、「チェックマーク」を示し、ユーザに、試験に合格したことを示し（ポンプおよび基部が、適切に機能している）、「次へ」ボタンを押し、次に進むように指示する。いくつかの実施形態では、「戻る」ボタンは、ハイライト解除された状態となり、いくつかの実施形態では、システムが、次へ進むまたは中断することを示唆することを示してもよい。図２０Ｔを参照すると、いくつかの実施形態は、ユーザに、製造業者の指示に従って、注入セットを挿入するように指示する、少なくとも１つの画面を含む。

次に、図２１Ａを参照すると、いくつかの実施形態は、ユーザに、ＶＥＬＣＲＯをポンプに取り付けるように指示する、少なくとも１つの画面を含む。前述のように、いくつかの実施形態では（例えば、図３に関して説明および図示されるように）、使い捨て部分は、いくつかの実施形態では、ＶＥＬＣＲＯファスナーシステムを含み得る、接着パッチを含んでもよい。本実施形態では、画面は、使い捨て部分の裏面上のパッチの裏当てに触れているユーザを示し、ユーザに、裏当てを除去し、小さい方のＶＥＬＣＲＯパッチを基部の裏面に取り付けるように指示する。いくつかの実施形態では、本実施形態は、裏当てを除去し、小さい方のＶＥＬＣＲＯパッチを基部の裏面に取り付ける手の動画である。

次に、図２１Ａを参照すると、いくつかの実施形態は、ユーザに、ＶＥＬＣＲＯをポンプに取り付けるように指示する、少なくとも１つの画面を含む。前述のように、いくつかの実施形態では（例えば、図３に関して説明および図示されるように）、使い捨て部分は、いくつかの実施形態では、ＶＥＬＣＲＯファスナーシステムを含み得る、接着パッチを含んでもよい。本実施形態では、画面は、使い捨て部分の裏面上のパッチの裏当てに触れているユーザを示し、ユーザに、裏当てを除去し、小さい方のＶＥＬＣＲＯパッチを基部の裏面に取り付けるように指示する。いくつかの実施形態では、本実施形態は、裏当てを除去し、小さい方のＶＥＬＣＲＯパッチを基部の裏面に取り付ける手の動画を含む。

次に、図２１Ｂを参照すると、いくつかの実施形態は、ユーザに、パッチをユーザの身体に取り付けるように指示する、少なくとも１つの画面を含む。前述のように、いくつかの実施形態では（例えば、図３に関して説明および図示されるように）、使い捨て部分は、いくつかの実施形態では、身体に取り付ける、ＶＥＬＣＲＯファスナーシステムを含み得る、接着パッチを含んでもよい。本実施形態では、画面は、大きい方のパッチの裏当ておよび大きい方のパッチに触れているユーザを示し、ユーザに、裏当を除去し、大きい方のＶＥＬＣＲＯパッチをその身体に取り付け、次に、ポンプをＶＥＬＣＲＯに取り付けるように指示する。いくつかの実施形態では、本実施形態は、裏当てを除去し、大きい方のＶＥＬＣＲＯパッチを身体に取り付け、ポンプをパッチに取り付ける手の動画である。

次に、図２１Ｃを参照すると、いくつかの実施形態は、ユーザに、注入セットキャップを除去するように指示する、少なくとも１つの画面を含む。本実施形態では、画面は、注入セットキャップを除去するユーザを示し、ユーザに、注入セット上の２つのタブを圧搾し、保護キャップを除去するように指示する。いくつかの実施形態では、本実施形態は、注入セット上の２つのタブを圧搾し、保護キャップを除去する手の動画である。

次に、図２１Ｄを参照すると、いくつかの実施形態は、ユーザに、注入セットを接続するように指示する、少なくとも１つの画面を含む。本実施形態では、画面は、注入セットをカニューレに接続するユーザを示し、ユーザに、注入セットをカニューレに接続するように指示する。いくつかの実施形態では、本実施形態は、注入セットをカニューレに接続する手の動画である。

次に、図２２Ａを参照すると、いくつかの実施形態は、カニューレに呼水を差すための少なくとも１つの画面を含む。本実施形態では、画面は、呼水体積を示し、カニューレ呼水を開始するためのボタンを含み、カニューレ呼水体積が正しいことを検証し、次いで、カニューレ呼水開始ボタンを押下するように指示する。画面上のボタンは、ユーザが、カニューレ呼水を開始するために押下すべきことを示す。

次に、図２２Ａを参照すると、いくつかの実施形態は、進行中のカニューレ呼水を示すための少なくとも１つの画面を含む。本実施形態では、画面は、送達された呼水の体積および総呼水体積を示し、呼水を停止するためのボタンを含む。画面はまた、要求される総呼水体積のうちの送達された体積を表す、状態バーを含む。

次に、図２２Ｂを参照すると、いくつかの実施形態は、カニューレ呼水が終了したことを確認するための少なくとも１つの画面を含む。図２２Ｄを参照すると、いくつかの実施形態は、設定が完了したことを確認するための少なくとも１つの画面を含み、基礎量を開始するためのボタンを含む。いくつかの実施形態では、本画面は、自動的に、設定が完了した後に現れ、これは、制限されないが、ユーザに、注入ポンプに基づく基礎量を開始するように再認識させることを含む、多くの理由から有益であり得る。

次に、図２３Ａを参照すると、いくつかの実施形態は、基礎プロファイルをプログラムするための少なくとも１つの画面を含む。示される実施形態では、基礎プロファイルをプログラムするために、ユーザは、いくつかの実施形態では、体積（毎時単位）であり得る、比率と、開始および終了時間とを入力する。種々の実施形態では、ユーザは、種々の曜日用（例えば、月曜日のプロファイル等）、および／または平日用、および／または週末用の基礎プロファイルを作成してもよく、および／または事象（例えば、スキー）用のカスタムプロファイルを作成してもよい。

次に、図２３Ｂを参照すると、いくつかの実施形態は、２４時間周期のグラフィカル表現と、また、確認時現在の比率の表示の両方を含み得る、１日の基礎プロファイルを視覚的に検討するための少なくとも１つの画面を含む。

次に、図２３Ｃおよび２３Ｄを参照すると、いくつかの実施形態は、例えば、２４時間周期の時間の範囲の間、各比率を含むボタンを含む、少なくとも１つの基礎プロファイル画面を含む。いくつかの実施形態では、ユーザは、時間の範囲のうちの１つを表し、ユーザをその特定の時間枠を編集するための画面に導く、ボタンを選択してもよい。いくつかの実施形態では、画面は、加えて、現在の基礎プロファイルおよび現在の時間枠両方のグラフィカル表現を上部に含んでもよい。

次に、図２４Ａおよび２４Ｂを参照すると、いくつかの実施形態では、遠隔インターフェースは、血中グルコースメータに無線で接続されるか、および／または血中グルコースメータを含むかのいずれかであってもよい。ユーザが、血液グルコースの読取を行なうと、いくつかの実施形態では、図２４Ａに示される画面は、自動的に、可視となる。いくつかの実施形態では、画面は、例えば、図２４Ａに示されるように、自動的に、時刻に基づいて、可能性として考えら得る「タグ」（画面ボタンは、「昼食」を示す）を表す、ボタンを含んでもよい。しかしながら、ユーザは、本タグを編集してもよい。例えば、ユーザは、ボタン「追加／編集」を選択してもよく、ユーザは、図２４Ｂに示されるものに類似する画面に導かれてもよい。メモおよびタグ編集画面は、カスタム編集のためのエリア（すなわち、編集ボックス）を含んでもよく、ユーザは、編集ボックスにコメントをタイプしてもよい。タグリストは、ユーザが、パーソナルコンピュータ／ウェブポータルを使用することによって、または遠隔インターフェースを使用することによってのいずれかによって、ユーザ設定に事前にプログラムされ得る、カスタムタグを含んでもよい。いくつかの実施形態では、ＧＵＩのための設定は、編集され得る、デフォルトリストを含んでもよい。

次に、図２５Ａおよび２５Ｂを参照すると、いくつかの実施形態は、図２５Ａに示されるように、ユーザが、血液グルコース示度値を手動で入力する、画面を含んでもよい。いくつかの実施形態では、入力し、「次へ」を選択後、例えば、図２５Ｂに示されるようなラベル画面が、ユーザが、ラベルを選択することを可能にしてもよい。ラベルリストは、ユーザが、パーソナルコンピュータ／ウェブポータルを使用することによって、または遠隔インターフェースを使用することによってのいずれかによって、ユーザ設定に事前にプログラムされ得る、カスタムタグを含んでもよい。いくつかの実施形態では、ＧＵＩのための設定は、編集され得る、デフォルトラベルを含んでもよい。

いくつかの実施形態では、例えば、図２５Ａに示されるもの等の画面を使用して、血液グルコース値を手動で入力することに応じて、ユーザインターフェースは、ユーザが摂取すべき炭水化物の量を示してもよい。例えば、ユーザが、「４０ｍｇ／ｄＬ」を入力する場合、システムは、ユーザプロファイルに関して入力される補正情報（すなわち、その医療介護提供者とともにユーザによって判定され得る、低血液グルコースレベル／低血糖症を治療するために使用される炭水化物の量）を使用することによって、低血糖症を治療するための炭水化物の量を算出してもよい。いくつかの実施形態では、遠隔インターフェースは、具体的指示とともに、例えば、１５個のスキットルズ（ｓｋｉｔｔｌｅｓ）（例えば、または任意の他の菓子、すなわち、グルコースアイテム）および４オンスのリンゴジュース（しかしながら、いくつかの実施形態では、これらは、異なってもよい）（全て、遠隔インターフェースまたはパーソナルコンピュータ／ウェブポータルのいずれかを通して、ユーザによって、ユーザプロファイルに入力されてもよい）とともに、低血糖症を治療するように事前にプログラムされてもよく、ユーザインターフェースは、低血糖症グルコース数値（数値は、システムに事前にプログラムされてもよい）の入力に応じて、食品、例えば、１５個のスキットルズおよび／または４オンスのリンゴジュースの写真をユーザに示してもよい。いくつかの実施形態では、ユーザは、同様に、文字および／または写真の形態でＧＵＩ上にユーザに提示され得る、付加的提案を要求してもよい。これは、低血糖症事象の迅速かつ容易な治療を含むが、それらに制限されない、多くの理由から、望ましくあり得る（ユーザは、低血糖症事象を治療するために食すべき食品を迅速に把握し、および／またはユーザは、友人または別の人物に、写真を示し、その食品の提供を要求してもよい）。いくつかの実施形態では、これは、特に、ユーザが現地の言語を話せない国において、有益となり得る。

次に、図２５Ｃを参照すると、いくつかの実施形態は、いくつかの実施形態では、時間およびグルコース示度値のリストを含み得る、少なくとも１つのグルコース履歴画面を含んでもよい。いくつかの実施形態では、付加的情報は、このような画面上において容易に利用可能となり得るが、あるいはユーザがある示度値を選択する場合、より詳細、例えば、食した食品および／または活動および／またはラベルおよび／またはタグ、もしくはユーザが示度値にタグ付けまたはラベル付けした任意の他の表示を伴う別の画面が、含まれ得るかのいずれかとなる。いくつかの実施形態では、「グラフ」タブは、血液グルコース値のグラフを閲覧するために、グルコース画面からアクセス可能であってもよい。いくつかの実施形態では、グラフは、双方向であってもよく、ユーザは、その入力のためのさらなる詳細および／または時間周期等を含む画面にユーザを導く、グラフ上の点または場所をタッチしてもよい。いくつかの実施形態では、ＧＵＩは、同一のグラフ上に、持続的グルコースモニタ（ＣＧＭ）、血中グルコースメータ（ＢＧＭ）、および注入ポンプ体積を示してもよい。

いくつかの実施形態では、グラフィカルユーザインターフェースは、ボーラスをプログラムするための１つ以上の画面を含んでもよい。次に、図２６Ａ−２６Ｄを参照すると、いくつかの実施形態では、ユーザは、上記で議論されるように、ユーザによるカスタム入力（遠隔インターフェースを使用するか、および／または食品ライブラリをウェブからダウンロードするか、および／またはパーソナルコンピュータおよび／またはウェブポータル上でカスタム入力を完了し、遠隔インターフェースにダウンロード／それと同期させるかのいずれか）を含み得る、および／またはデフォルト入力を含み得る、食品ライブラリからの品を入力選択してもよい。いくつかの実施形態では、ユーザは、食品ライブラリ画面にナビゲートし（例えば、いくつかの実施形態では、画面は、図２６Ｋおよび２６Ｌに示される画面に類似し得る）、食品を選択する、および／または「キーパッド」を選択し、食品を検索画面にタイプしてもよく、次いで、別の画面、例えば、いくつかの実施形態では、図２６Ａに示されるもの、またはそれに類似するものが、ユーザに、食品の量を入力することを要求してもよい。いくつかの実施形態では、画面はまた、例えば、制限ではないが、炭水化物、脂肪、および／またはカロリーのうちの１つ以上を含み得る、食品の栄養値の表示を含んでもよい。いくつかの実施形態では、食品が、食品ライブラリから選択されない場合、確認画面は、いくつかの実施形態では、図２６Ｍに示される画面の実施形態に類似し得るものをユーザに示すであろう。

いくつかの実施形態では、ユーザは、いくつかの実施形態では、図２６Ｄに示されるものに類似し得る、キーパッドを使用して、炭水化物量を入力してもよい。いくつかの実施形態では、ユーザが、食品アイテムを入力すると、ユーザは、例えば、図２６Ｊに示される画面に示されるものと類似するボタンを使用して、付加的アイテムの追加に戻ってもよく、そこで、ユーザは、「食品／炭水化物追加」ボタンを選択してもよい。ユーザが、ボーラスのために、食品アイテムを含む、全炭水化物を追加すると、ユーザは、「ＯＫ」を選択してもよく、図２６Ｂに示されるものに類似し得る、画面が、ユーザに、遠隔インターフェースが注入ポンプと無線通信を確立していることを示してもよい。

いくつかの実施形態では、ユーザは、炭水化物または食品アイテムおよび量の入力ではなく、ボーラスのために要求されるインスリンの単位を入力することを選択してもよい。いくつかの実施形態では、これは、例えば、図２６Ｎに示される画面に類似し得る、キーパッド画面を使用して達成されてもよい。ユーザが、要求される体積を入力すると、ユーザは、「ＯＫ」を選択してもよく、図２６Ｂに示されるものに類似し得る、画面が、ユーザに、遠隔インターフェースが、注入ポンプと無線通信を確立していることを示してもよい。

いくつかの実施形態では、ボーラスプロセスの間、遠隔インターフェースは、最新の血中グルコースメータ結果を含む、画面を示してもよく、いくつかの実施形態では、ユーザに、試験が行なわれた時間と、また、試験からの経過時間を示してもよい。いくつかの実施形態では、画面は、図２６Ｈにおける画面に類似してもよい。いくつかの実施形態では、画面は、ユーザに、ボーラス計算機が、ボーラスの補正部分に対して、本最新のグルコース試験を使用することを所望するかどうか確認するように指示してもよい。ユーザは、いくつかの実施形態では、「いいえ、再試験する」を選択してもよく、その場合、ユーザインターフェースは、血中グルコースメータ画面を開いてもよい。いくつかの実施形態では、ユーザは、「いいえ、補正ボーラスをスキップする」を選択してもよく、その場合、ボーラス計算機は、その値を使用せず、自動的に、ユーザを血中グルコースメータ画面に導かないであろう。いくつかの実施形態では、ユーザは、「ＯＫ」を選択してもよく、ボーラスプロセスが、継続してもよい。

いずれの場合も、ユーザが、制限ではないが、炭水化物値、食品アイテム、血液グルコース値、および／または要求されるインスリン体積の単位のうちの１つ以上を含み得る、ボーラスに関して入力を所望する情報の全てを入力すると、ユーザインターフェースは、いくつかの実施形態では、ボーラスカテゴリのそれぞれに対する推奨、例えば、食事ボーラス（食品用）、補正ボーラス（グルコース用）を示し、ユーザに、残留ボーラス量（いくつかの実施形態では、残留インスリン量またはＩＯＢとも称され得る）を示し、推奨される総ボーラスを示す、例えば、図２６Ｉに示される実施形態に類似し得る、概要画面を提示する。ユーザは、本ウィンドウからナビゲートし、例えば、画面の「総ボーラス」エリアをタッチし、単位あたり値を調節することによって、送達されるべき総ボーラスを調節してもよい。いくつかの実施形態では、これは、キーパッドを使用して行なわれてもよい。いくつかの実施形態では、これは、いくつかの実施形態では、図２６Ｇに示されるものに類似し得る、スライド調節ＧＵＩを使用して行なわれてもよい。本実施形態では、推奨される総量、例えば、３．５１単位が、「ボーラス量修正」ボックス２６００内に示される。ユーザは、スライダ２６０２を移動させることによって、総体積を調節してもよい。例えば、ユーザが、スライダ２６０２を左に向かってスライドさせるにつれて、ボーラス量修正ボックス２６００内の総量は、減少し、減少したパーセンテージが、ボーラス量修正ボックス２６００内に表される。例えば、ユーザが、スライダ２６０２を右に向かってスライドさせるにつれて、ボーラス量修正ボックス２６００内の総量は、増加し、増加したパーセンテージが、ボーラス量修正ボックス２６００内に表される。これは、制限されないが、ユーザが、推奨されるボーラス量を所与のパーセンテージだけ増減させることを所望する場合、例えば、運動前の間、２０％減少させる、および／または病気の間、４０％増加させる場合、ボーラス量修正ボックス２６００が、ユーザにとって、本計算を容易にすることを含む、多くの理由から、望ましくあり得る。送達されるべき体積が判定されると、いくつかの実施形態では、ユーザインターフェースは、ユーザが〜を判定することを可能にする画面を提示する。

しかしながら、ユーザが、推奨検討画面から進むことを所望する場合、ユーザは、いくつかの実施形態では、「次へ」ボタンを使用して、ナビゲートしてもよい。ユーザが、ボーラス量修正画面からナビゲートする場合、ユーザは、いくつかの実施形態では、「ＯＫ」ボタンを使用してもよい。いくつかの実施形態では、ユーザは、ユーザが、ボーラスが送達される方法、すなわち、通常、拡張、または組み合わせを判定することを可能にする画面に導かれるであろう。次に、図２６Ｅおよび２６Ｆを参照すると、送達されるべきインスリンの総体積は、いくつかの実施形態では、ユーザが、少なくとも、拡張ボーラスとして送達されるべきパーセンテージを追加するように修正しない限り、デフォルトとして、通常ボーラスとして送達されてもよい。いくつかの実施形態では、図２６Ｅに示される画面の入力に応じて、通常２６０４は、推奨される総量を含み得、拡張２６０８は、０．００単位を含み得る。送達されるべき総単位２６０６は、スライダ２６１０下に示されてもよい。通常２６０４および拡張２６０８はまた、いくつかの実施形態では、その方式、すなわち、通常または拡張のいずれかで送達されるであろう合計のパーセンテージを表す、パーセンテージを含んでもよい。

ユーザは、スライダ２６１０を移動させることによって、通常２６０４および拡張２６０８として送達され得る総体積を調節してもよい。例えば、ユーザが、スライダ２６１０を左に向かってスライドさせるにつれて、総量および通常２６０４内の合計のパーセンテージが増加し、総量および拡張２６０８内の総量のパーセンテージが減少する。しかしながら、例えば、ユーザが、スライダ２６１０を右に向かってスライドさせるにつれて、総量および拡張２６０８内の合計のパーセンテージが増加し、総量および通常２６０４内の合計のパーセンテージが減少する。これは、制限されないが、ユーザが、特定のパーセンテージを拡張として送達することを所望する場合、例えば、ユーザが、８０％を拡張として送達することを所望する場合、ユーザが、拡張２６０８内のパーセンテージが「８０％」を示すまで、スライダ２６１０を右にスライドさせ得ることを含め、多くの理由から、望ましくあり得る。また、ユーザが、特定の体積、例えば、１．０単位を通常として送達することを所望する場合（これは、制限されないが、ユーザが、補正ボーラスに起因する合計の体積を通常として送達することを所望する場合を含む、多くの状況において所望され得る）、ユーザは、通常２６０４内の体積が１．００単位になるまで、スライダ２６１０を右に向かってスライドさせてもよい。いくつかの実施形態では、通常２６０４および／または拡張２６０８下の増減量に関するスライダ２６１０の方向は、異なってもよい。

次に、図２６Ｆを参照すると、ボーラスの任意のパーセンテージまたは体積が、拡張として送達されるべきと選択される場合、いくつかの実施形態では、図２６Ｆに示されるものに類似する画面が、通常および拡張ボーラス量画面から「次へ」を選択後、ユーザに提示されてもよい。ユーザは、拡張体積（図２６Ｅから）が拡張ボーラスとして送達されるべき時間量を入力してもよい。いくつかの実施形態では、ユーザが、スライダ２６１２を右にスライドさせるにつれて、拡張ボーラスのための時間が増加し、ユーザが、スライダ２６１２を左にスライドさせるにつれて、拡張ボーラスのための時間が、減少する。いくつかの実施形態では、時間の増減に関するスライダ２６１２の方向は、異なってもよい。いくつかの実施形態では、図２６Ｆに示されるもの等の持続時間画面は、デフォルト時間、例えば、１時間として開き、ユーザが修正することを可能にしてもよい。いくつかの実施形態では、デフォルトは、最新のプログラムされた拡張ボーラスであってもよい。

ユーザが、ボーラス体積の送達のための方法をプログラムすると、ユーザは、いくつかの実施形態では、「ＯＫ」を選択してもよく、例えば、いくつかの実施形態では、図２６Ｃに図示されるものに類似する、ボーラス設定検討画面が、可視となってもよい。いくつかの実施形態では、ボーラス設定検討画面は、送達されるべき総ボーラス量、送達の方法、通常として送達されるべき合計の体積、および拡張として送達されるべき合計の体積を提供し、拡張として送達されるべき体積が存在する場合、拡張ボーラスの持続時間が、示されてもよい。ユーザは、したがって、ボーラス体積および送達の方法を明確に検討する機会を有する。いくつかの実施形態では、ボーラス送達を開始するために、ユーザは、「確認」ボタンを「スライド」させなければならない。これは、潜在的に、「確認」ボタンの偶発的または非意図的タップの発生を減少させることを含むが、それらに制限されない、多くの理由から、望ましくあり得る。したがって、中止ボタンを使用して、「中止」するための作用、すなわち、タップは、「確認」と、すなわち、スライドと完全に異なる作用である。また、「中止」ボタンから非常に異なる場所にある、「確認」ボタンおよびスライドの場所は、非意図的中止を防止し得る。したがって、本方法は、非意図的中止と、また、中止が所望されたときの非意図的送達を減少させ得る。また、いくつかの実施形態では、「次へ」または「ＯＫ」ボタンの場所は、多くの画面上において、類似場所にある。したがって、療法変更が行なわれるとき、非意図的確認を防止するために、いくつかの実施形態では、システムは、異なる作用、例えば、タッチ／タップではなく、スライドを要求し、加えて、いくつかの実施形態では、スライドの開始は、「次へ」または「ＯＫ」ボタンと反対側にある。

制限されないが、以下を含む、ボーラス体積をプログラムする本方法には、多くの利点がある。ユーザは、最初に、ボーラスの体積を判定し、次いで、その後、送達の方法を判定してもよい。したがって、ユーザは、ユーザが総ボーラスの食品ボーラス部分を拡張ボーラスとしておよび総ボーラスの補正部分を通常ボーラスとして送達することを所望し得る、いくつかの状況において、前述のように、例えば、炭水化物／食品および／または血液グルコース値を入力する前に、ボーラスが「拡張」されることを決定する必要はない。また、図２６Ｇ、２６Ｅ、および２６Ｆに示されるスライダ実施形態は、ユーザが、パーセンテージ変更ならびに任意の所与の時間における総体積を閲覧することを可能にする。本方法は、したがって、誤計算を防止し、インスリン療法のより綿密な微調整およびカスタマイズを可能にし得る。また、ユーザが、拡張ボーラスとして送達されるべきボーラス体積の部分の入力後、拡張ボーラスの持続時間をプログラミングすることに関して、ユーザは、持続時間を修正する前に、送達を「確認」する可能性が低くなり得る。

次に、図２７Ａ、２７Ｂ、２７Ｃ、および２７Ｅを参照すると、種々の実施形態では、ユーザインターフェースは、ユーザが作用を中止する種々の機会を含む。いくつかの実施形態では、ボタン「中止」が押下されると、ユーザが中止を所望することを確認する、別の画面が現れる。これは、例えば、ユーザが中止ボタンを非意図的にタップする場合、ユーザが、中止ではなく、継続する機会を有するため、望ましくあり得る。

次に、図２７Ｆおよび２７Ｇを参照すると、いくつかの実施形態では、ボーラスがアクティブである、例えば、前述の実施例では、ボーラスの一部は、通常として送達され得、一部は、拡張として送達され得る間、ユーザインターフェースは、アクティブ送達の状態を示す、「送達中」画面を含んでもよい。例えば、いくつかの実施形態では、図２７Ｆに示されるように、送達された体積および送達されるべき総体積２７１６が、示されてもよく、状態バー２７１４は、送達されるべき総体積の関数として、送達された体積を表す。加えて、いくつかの実施形態では、送達中画面はまた、プロファイル名、例えば、「平日」と、事前にプログラムされた基礎比率、例えば、０．８２単位／時間の両方を示し得る、現在の基礎プロファイル２７１８を含んでもよい。

いくつかの実施形態では、ボーラスがアクティブである間、ユーザインターフェースのためのホーム画面は、ボーラス送達状態画面または送達中画面に変わってもよく、例えば、いくつかの実施形態では、図２７Ｆに示される送達中画面に類似してもよい。いくつかの実施形態では、アクティブボーラスが送達されているときは常に、ホーム画面（いくつかの実施形態では、前述のように、送達中画面に類似してもよい）は、フリーズし、タイムアウトしない。

いくつかの実施形態では、注入ポンプが送達中である間、送達中画面および／またはユーザインターフェースの種々の画面は、ユーザに、送達が生じていることを視覚的に示すための異なるスプラッシュスクリーンおよび／または背景画面を含んでもよい。いくつかの実施形態では、背景は、送達中を示す「緑色」であってもよい。しかしながら、これは、一実施形態にすぎず、注入ポンプ状態を示す、および／または区別するための他の実施形態が、使用されてもよい。

依然として、図２７Ｆを参照すると、いくつかの実施形態では、注入ポンプが、ボーラスを送達している間、「ボーラス停止」ボタン２７２０が、送達画面上に含まれてもよい。いくつかの実施形態では、ボーラス停止ボタン２７２０は、画面の残りと異なる色であってもよく、例えば、いくつかの実施形態では、ボーラス停止ボタン２７２０は、赤色であってもよい。

次に、図２７Ｇを参照すると、いくつかの実施形態では、アクティブボーラスが送達されている間、ユーザが、「基礎停止」を選択する場合、基礎停止ポップアップ画面２７２２が現れ、ユーザに、基礎インスリンの送達を停止することを所望することを確認し、ユーザに、これはまた、現在のボーラス送達を停止することになることを再認識させてもよい。いくつかの実施形態では、注入ポンプは、ユーザが、ボーラスも停止しない限り、基礎を停止することを可能にしなくてもよく、これは、ユーザが、基礎インスリンの送達の停止を所望する場合、全インスリン送達を停止すべきであることを示し得るため、望ましくあり得る。基礎停止ポップアップ画面２７２２は、「基礎停止」のためのプロセスを開始することを選択するとき、ユーザが認識していない場合、ボーラス送達が進行中であることを再認識させる。

次に、図２７Ｈおよび２７Ｉを参照すると、いくつかの実施形態では、アクティブボーラスが送達されている間、ユーザが、「ボーラス停止」を選択する場合、基礎停止ポップアップ画面２７２４が現れ、ユーザに、基礎インスリンの送達の停止を所望することを確認してもよい。いくつかの実施形態では、注入ポンプは、基礎も停止させない限り、ユーザが、ボーラスを停止することを可能にしなくてもよく、これは、ユーザが、ボーラスインスリンの送達の停止を所望する場合、全インスリン送達を停止すべきであることを示し得るため、望ましくあり得る。図２７Ｈを参照すると、いくつかの実施形態では、ユーザが、ボーラスの中止を選択する場合、中止の確認画面が現れ、プログラムされた総体積のうちの送達された単位２７２６を示してもよい。

次に、図２８Ａを参照すると、ホーム画面の実施形態が、示される。示される実施形態では、ホーム画面は、いくつかの異なる情報を示し、いくつかの実施形態では、ホーム画面上の情報の量は、異なってもよい。しかしながら、いくつかの実施形態では、例えば、注入ポンプが送達中であるという、注入ポンプ状態の表示２８００；アクティブ基礎プロファイルの表示２８０２；残ボーラス量の表示２８０４；いくつかの実施形態では、最後の結果の時間を含む、最後のグルコース結果の表示２８０６；リザーバ内に残っているインスリンの体積２８０８；ポンプバッテリの残り寿命のパーセンテージ２８１０；バッテリ値２８１４（バッテリレベル表示を含んでもよい）；現在の時間２８１８；接続状態２８１６；およびそのページが存在するユーザインターフェースのセクション２８１２の情報が、ホーム画面上に含まれてもよいが、しかしながら、種々の他の実施形態では、その情報のうちの１つ以上および／または付加的情報が、含まれてもよい。

いくつかの実施形態では、上記で議論されるように、注入ポンプが送達中である間、画面は、その状態を容易に示す、バックスプラッシュ、アイコン、または他の表示を含んでもよく、例えば、ページのバックスプラッシュは、状態に応じて、異なる色であってもよい。いくつかの実施形態では、送達中状態は、緑色であってもよく、グルコース状態は、橙色であってもよく、アラーム状態は、赤色であってもよく、アイドル状態は、青色であってもよい。これらの実施形態では、画面に関係なく、注入ポンプの状態は、ユーザによって学習されてもよい。アラーム状態画面の実施形態は、図２９Ａ−２９Ｆに見出され得、アイドル画面の実施形態は、図２８Ｃに見出され得る。いくつかの実施形態では、注入ポンプがアイドル中であるとき、これは、送達がないことを示し、多くの状況では、長時間である場合、望ましくない場合がある。したがって、いくつかの実施形態では、注入ポンプが、アイドル状態であるとき、ホーム画面は、アイドル状態２８２８を示し、アイドル状態ホーム画面は、「基礎開始」２８３０のための大ボタンを含む。

いくつかの実施形態では、１つ以上の画面は、特定の画面、例えば、ホーム２８１２、グルコース２８２０、ボーラスまたは基礎２８２２、ログブック２８２４、および／または設定２８２６にナビゲートするためのアイコンボタンを含んでもよい。これらの画面の一実施形態の実施例は、ホーム（図２９Ａ）、グルコース（図２８Ｂ）、インスリン（例えば、ボーラスまたは基礎）（図２８Ｄ−２８Ｇ）、ログブック（図２８Ｈ）、および／または設定（図２８Ｉ）のように示される。

次に、インスリン画面の実施形態、図２８Ｄ−２８Ｇを参照すると、いくつかの実施形態では、インスリン画面は、制限されないが、ボーラス計算機２８３０、ボーラスプログラム２８３２、基礎プログラム２８３４、および基礎停止２８３６のボタンのうちの１つ以上を含む。いくつかの実施形態では、インスリン画面はまた、体積および時間を含み得る、最後のボーラス２８３８、ならびに比率およびプロファイル名を含み得る、現在アクティブである基礎プロファイル２８４０の表示を含んでもよい。

次に、図２９Ａ−２９Ｆを参照すると、閉塞検出アラームの実施形態が、示される。いくつかの実施形態では、上記で議論されるように、アラーム状態は、異なるバックスプラッシュ／背景または色に変換してもよく、すなわち、画面のバックスプラッシュは、アラーム状態を示すために赤色であってもよい。いくつかの実施形態では、アラーム状態が、システムによって感知されると、システムは、ユーザが、アラーム状態を復元および／または確認するのを支援する、一連のＧＵＩ画面を提供してもよい。例えば、図２９Ａでは、いくつかの実施形態では、画面は、インスリンの流動が遮断されており、したがって、閉塞状態が存在することを示してもよい。いくつかの実施形態では、ユーザは、「次へ」を選択してもよく、ＧＵＩは、ユーザに、推奨される措置を段階的に説明してもよい。例えば、いくつかの実施形態では、例えば、図２９Ｂでは、画面は、ユーザに、その血液グルコースをチェックすることを再認識させてもよい。図２９Ｃおよび２９Ｄを参照すると、画面は、ユーザに、ポンプ試験を開始するように指示してもよい（例えば、閉塞が、使い捨て部分またはカニューレ内であるかどうか判定するため）。ポンプ試験は、いくつかの実施形態では、使い捨て部分が閉塞を有するかどうか判定してもよい。ポンプ試験を開始する前に、いくつかの実施形態では、画面は、ユーザに、管類セットから分断することを再認識させる。次に、図２９Ｅおよび２９Ｆを参照すると、いくつかの実施形態では、システムは、閉塞が使い捨て部分内ではないと判定してもよく、ユーザに、カニューレを交換することを再認識させてもよい。いくつかの実施形態では、システムは、自動的に、いくつかの実施形態では、前述のものを含み、いくつかの実施形態では、ユーザに、新しいカニューレに接続すること（および、新しいカニューレに呼水を差す等）を再認識させる、動画を含む、一連の画面を開始してもよい。いくつかの実施形態では、システムが、閉塞が使い捨て部分にあると判定する場合、システムは、ユーザに、使い捨て部分を交換するように指示してもよい。

システムの種々の実施形態は、したがって、１つ以上のデバイスおよび遠隔インターフェースを含む。いくつかの実施形態では、遠隔インターフェースは、ウェブポータルおよび／またはパーソナルコンピュータと接続するように構成され、それらと通信してもよい。いくつかの実施形態では、遠隔インターフェースは、パーソナルコンピュータであってもよい。

いくつかの実施形態では、システムは、再充電装置、および／または遠隔インターフェースを再充電するため、および／または１つ以上のデバイスを再充電するためのデバイスを含む。いくつかの実施形態では、再充電の間、デバイスおよび／または遠隔インターフェースは、ソフトウェアアップデート／ソフトウェアダウンロードを受信し、および／またはデータベースと同期させてもよい。いくつかの実施形態では、再充電デバイスおよび／または充電器は、パーソナルコンピュータへのＵＳＢ接続を含み、接続は、データポートおよび／または充電装置として使用されてもよい。

いくつかの実施形態では、システムは、注入ポンプおよび／または他のデバイスの少なくとも２つの再使用可能部分を含み、いくつかの実施形態では、両方とも、情報を受信し、および／または遠隔インターフェースと通信するように構成される。いくつかの実施形態では、２つの再使用可能部分の１つ目が、再充電されている間、２つの再使用可能部分の２つ目が、使用中であってもよい。１つ目の再使用可能部分から２つ目の再使用可能部分への交換は、２つ目の再使用可能部分が、使用されると、アップデートされた情報を含むように、遠隔インターフェースが、データを２つ目の再使用可能部分と同期することを含んでもよい。いくつかの実施形態では、再使用可能部分はそれぞれ、不揮発性メモリを含み、デバイスに命令する１つ以上のプロセッサに関する、全制御および命令能力を含んでもよい。したがって、いくつかの実施形態では、遠隔インターフェースは、ユーザインターフェースとして使用されてもよく、コマンド、指示、およびプロファイルは、遠隔インターフェースを使用して、ユーザによって入力されてもよいが、しかしながら、それらのコマンドは、デバイスに送信され、いくつかの実施形態では、遠隔インターフェースによって、デバイスが情報を正しく受信したことを確認後、デバイスは、全作用を命令し、例えば、注入ポンプは、注入可能流体の送達を命令する。

いくつかの実施形態では、ユーザが第１の再使用可能部分から第２の再使用可能部分に使用を変更するために、ユーザは、遠隔インターフェースに、再使用可能部分の変更を所望することを示してもよい。第１の再使用可能部分は、使用中、現在の残インスリン量および／または残ボーラス量（ＩＯＢとも称され得る）情報を遠隔インターフェースに送信する。遠隔インターフェースは、本情報を受信し、ＩＯＢ情報に関して、時間の計測を開始する。第２の再使用可能部分が、遠隔インターフェースに接続されると、遠隔インターフェースは、タイムスタンプとともに、ＩＯＢ情報を第２の再使用可能部分に送信する。第２の再使用可能部分は、ＩＯＢ情報に関する時間を確認する。再使用可能部分が、タイムスタンプが一致しないことを見出す場合（いくつかの実施形態では、第１の再使用可能部分のバッテリが適切に機能していない、および／または充電器に置かれたときに、１００％充電が切れていた指標であり得る）、メッセージが、遠隔インターフェースに送信され、時間が一致していないことをユーザに示す。ユーザは、正しい時間を入力し、本時間を遠隔インターフェースおよび再使用可能部分の両方に対して入力してもよい。しかしながら、タイムスタンプが一致する場合、第２の再使用可能部分は、ＩＯＢ情報に依拠してもよく、したがって、ＩＯＢ計算は、第１の再使用可能部分から第２の再使用可能部分に交換中でも、継続し得る。タイムスタンプが一致しない事例では、いくつかの実施形態では、ＩＯＢ情報は、削除されてもよく、計算が、新しい設定時間において０から開始し、ユーザは、遠隔インターフェースを使用して、それを通知される。

遠隔インターフェースは、少なくとも１つのデバイスと通信するために使用されてもよい。いくつかの実施形態では、遠隔インターフェースは、種々のデバイスと通信するために使用されてもよい。これは、制限されないが、ユーザの親しみやすさを含む、多くの理由から、望ましくあり得る。単一遠隔インターフェースを使用して、そのソフトウェアプラットフォームが設計されてもよく、多くの実施形態では、単一ユーザが、有意な学習時間を伴わずに、種々のデバイスのための種々のソフトウェア／アプリケーションを習得し得るように、性質上、類似するように設計される。加えて、遠隔インターフェースは、ＵＳＢを介して、パーソナルコンピュータに接続される間、および／またはウェブポータルに接続される間のいずれかにおいて、通信し得るデバイスの全てのための全ソフトウェアアップデートをダウンロードしてもよく、次いで、これらのアップデートをデバイス自体に転送してもよい。これは、制限されないが、能率的プロセスにおいて、デバイスを維持する、および効率的様式においてデバイスをアップデートするためを含む、多くの理由から、有益であり得る。

加えて、いくつかの実施形態では、パーソナルコンピュータ上にロードされる、および／またはウェブポータルを通してアクセスされ得る、種々のソフトウェアアプリケーションを使用して、ユーザは、種々のプロファイルを構成し、および／または１つの場所において、デバイスに関する種々のデータを検討してもよい。情報および／またはプロファイルに行なわれる変更は、遠隔インターフェース上にダウンロードされてもよい。任意の関連変更が、次いで、デバイスに無線で通信される。いくつかの実施形態では、デバイス自体が、パーソナルコンピュータへのＵＳＢ接続を介して、情報を受信してもよい。

いくつかの実施形態では、遠隔インターフェースは、デバイスの制御を支援する画像を捕捉するために使用されてもよい。例えば、いくつかの実施形態では、ユーザは、遠隔インターフェース（および、ユーザインターフェース）が、充填された注射器内の流体の体積に関してユーザ入力された情報の検証、および／または充填された注射器内の流体の体積の判定のいずれかを行い得るように、遠隔インターフェース上のカメラを使用して、充填された注射器の写真を撮影するように指示されてもよい。これは、制限されないが、リザーバ内に装填される流体のほぼ正しい体積（いくつかの実施形態では、ユーザのさらなる安全性につながり得る）を含む、多くの理由から、有益であり得る。いくつかの実施形態では、注入ポンプは、リザーバ内に残留する流体の体積を判定し、体積が、特定の、いくつかの実施形態では、事前にプログラムされた体積未満であるとき、ユーザにアラームする。これらの実施形態では、ユーザは、体積が完全に枯渇する前に、リザーバを変更（すなわち、充填されたリザーバと交換）してもよい。したがって、これは、ユーザが薬剤が全くない事象を被らないように防止する。したがって、リザーバに移されたとして、ユーザによって、正しくない流体の体積が入力される場合、リザーバ内の流体の体積の計算は、不正確となり得る。これは、制限されないが、リザーバに移される流体の体積が、より高い数値に誤計算される場合、リザーバが、計算されたよりも早く枯渇し得、したがって、ユーザに、予想外な様式において、薬剤がなくなり得ることを含む、所望の多くの理由から、望ましくあり得ない。しかしながら、リザーバに移される流体の体積が、より低い数値に誤計算される場合、リザーバは、計算されたよりもゆっくり枯渇し得、したがって、ユーザは、リザーバを早期に交換し、したがって、未使用流体を廃棄し得る。

いくつかの実施形態では、カメラは、前述のように使用されてもよいが、カメラは、遠隔インターフェースの周辺デバイスの一部であってもよい。いくつかの実施形態では、周辺デバイスは、画像を遠隔インターフェースに転送してもよく、遠隔インターフェースは、遠隔インターフェースのカメラによって提供された場合と同様に、画像を処理してもよい。

本発明の原理が、本明細書に説明されたが、本説明は、本発明の範囲に関する制限としてではなく、一例にすぎないことが、当業者によって理解されるはずである。本明細書に図示および説明される例示的実施形態に加え、他の実施形態も、本発明の範囲内で想定される。当業者による修正および代用も、本発明の範囲内であると見なされる。

Claims

医療デバイスの無線制御のためのデバイス、方法およびシステム。