(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-02-05
(45)【発行日】2024-02-14
(54)【発明の名称】1つ以上のリモートデバイスとの医療用デバイス通信のためのシステム、装置、及び方法
(51)【国際特許分類】
H04W 12/50 20210101AFI20240206BHJP
H04W 84/10 20090101ALI20240206BHJP
H04W 4/00 20180101ALI20240206BHJP
H04W 12/08 20210101ALI20240206BHJP
H04W 88/04 20090101ALI20240206BHJP
【FI】
H04W12/50
H04W84/10 110
H04W4/00 110
H04W12/08
H04W88/04
(21)【出願番号】P 2021538287
(86)(22)【出願日】2019-12-20
(86)【国際出願番号】 US2019067865
(87)【国際公開番号】W WO2020142270
(87)【国際公開日】2020-07-09
【審査請求日】2022-09-15
(32)【優先日】2018-12-31
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】595117091
【氏名又は名称】ベクトン・ディキンソン・アンド・カンパニー
【氏名又は名称原語表記】BECTON, DICKINSON AND COMPANY
(74)【代理人】
【識別番号】110001243
【氏名又は名称】弁理士法人谷・阿部特許事務所
(72)【発明者】
【氏名】トニー ハイ グエン
【審査官】吉村 真治▲郎▼
(56)【参考文献】
【文献】特表2017-528212(JP,A)
【文献】特開2016-097055(JP,A)
【文献】特表2015-514449(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04B 7/24- 7/26
H04W 4/00-99/00
(57)【特許請求の範囲】
【請求項1】
医療用デバイスを制御するためのデバイスであって、
RF信号を前記医療用デバイスと交換するように構成された無線周波数(RF)回路と、
メモリデバイスと、
前記RF回路及び前記メモリデバイスに接続され、前記RF回路を介して、前記医療用デバイスとRF信号を交換するための少なくとも2つの無線通信プロトコルのうちの選択された1つを使用するように構成された処理デバイスと、を備え、
前記少なくとも2つの無線通信プロトコルは、前記デバイスと前記医療用デバイスとをペアリングして、構成データと、医療用デバイス操作データと、前記医療用デバイスを操作するための制御信号とから選択されたセキュア情報をセキュアに送信するために、前記処理デバイスによって使用される第1の通信プロトコルと
、1つ以上のデバイスとペアリングし、前記セキュア情報より低いセキュリティを要求する医療用デバイスデータ及び通知から選択された情報
を1つ以上の他のデバイスに送信するために、前記処理デバイスによって使用される第2の通信プロトコルと、
を含
み、
前記デバイスは、前記デバイスと前記医療用デバイスとの間で前記セキュア情報を交換するために前記第1の通信プロトコルが必要とされることを示すメタデータを持つ前記セキュア情報を提供することによって、前記構成データから選択された前記セキュア情報、前記医療用デバイス操作データ、及び制御信号を前記第1の通信プロトコルを介した通信に制限し、前記第1の通信プロトコルを利用しない前記1つ以上の他のデバイスに対する前記セキュア情報の通信を排除するように構成される、
デバイス。
【請求項2】
前記デバイスは、ハンドヘルドと、前記医療用デバイスのための専用コントローラと、前記医療用デバイスの制御を実行するために、そこに記憶される医療用デバイス制御アプリケーションを有するスマートフォンとのグループから選択される、
請求項1に記載のデバイス。
【請求項3】
前記第1の通信プロトコルは、前記医療用デバイスのペアリングを、前記医療用デバイスの操作を制御するための前記デバイスのみに制限する、
請求項1に記載のデバイス。
【請求項4】
前記第1の通信プロトコルは、Bluetooth(登録商標) Low Energy(BLE)通信プロトコルである、
請求項3に記載のデバイス。
【請求項5】
前記BLE通信プロトコルは、ブロードキャストモードを有しない、
請求項4に記載のデバイス。
【請求項6】
前記第1の通信プロトコルは、前記医療用デバイスに特化しており、前記1つ以上の他のデバイスによって前記デバイスとペアリングするためには使用不可能である、
請求項3に記載のデバイス。
【請求項7】
前記第2の通信プロトコルは、前記1つ以上の他のデバイスとペアリングするために前記デバイスによって使用される標準Bluetooth(登録商標)プロトコルであり、前記1つ以上の他のデバイスを発見するためのブロードキャストモードを備える、
請求項
3に記載のデバイス。
【請求項8】
前記デバイスは、前記医療用デバイスとペアリングして信号を交換するための前記第1の通信プロトコルと、前記1つ以上の他のデバイスとペアリングして信号を交換するための前記第2の通信プロトコルとを使用することによって、統合疾病管理(IDM)システム内のハブとして動作するように構成され、前記医療用デバイスは、投薬デバイスであり、前記1つ以上の他のデバイスは、血糖値モニタと、炭水化物トラッキングデバイスと、身体運動トラッキングデバイスとで構成されるグループから選択される、
請求項1に記載のデバイス。
【請求項9】
前記医療用デバイスに関するデータを他のデバイスに通過させるためのポータルアプリケーションをさらに備え、前記ポータルアプリケーションは、前記医療用デバイスから送信されるデータを受信し、それを他のデバイスに提供し、かつ前記デバイスで前記データを記憶しないように構成される、
請求項1に記載のデバイス。
【請求項10】
前記処理デバイスは、前記
RF信号の送信を要求する操作のタイプ及び前記
RF信号を介して送信される情報のタイプから選択された基準に依存して、前記RF回路を介して
RF信号を送信するために、前記第1の通信プロトコル及び前記第2の通信プロトコルのどちらを使用するかを決定するように構成される、
請求項1に記載のデバイス。
【請求項11】
前記操作のタイプは、医療用デバイス制御コマンドを送信すること、医療用デバイス構成パラメータを設定すること、医療用デバイスステータスデータを要求すること、医療用デバイスログデータを要求すること、前記医療用デバイスからのセキュアデータを要求すること、及び前記1つ以上の他のデバイスにデータを送信することから選択され、
前記処理デバイスは、前記第1の通信プロトコルを使用して、医療用デバイス制御コマンドを送信すること、医療用デバイス構成パラメータを設定すること、及び前記医療用デバイスからのセキュアデータを要求すること、から選択された前記操作のタイプを実行し、前記第2の通信プロトコルを使用して、医療用デバイスステータスデータを要求すること、医療用デバイスログデータを要求すること、及び前記1つ以上の他のデバイスにデータを送信すること、から選択された前記操作のタイプを実行するように構成される、
請求項10に記載のデバイス。
【請求項12】
前記1つ以上の他のデバイスは、スマートウォッチ、ポータブルモニタリングデバイス、Bluetooth(登録商標)対応リストバンドデバイス、血糖値モニタ、炭水化物トラッキングデバイス、及び身体運動トラッキングデバイスで構成されるグループから選択される、
請求項1に記載のデバイス。
【請求項13】
前記処理デバイスに接続されたグラフィカルユーザインターフェース(GUI)を含むユーザインターフェースをさらに備え、
前記処理デバイスは、医療用デバイス操作アプリケーション、血糖値モニタアプリケーション、炭水化物トラッキングアプリケーション、及び身体運動トラッキングアプリケーションから選択されたスマートフォンアプリケーションと、投薬管理アプリケーションと、統合型疾病管理アプリケーションとに対応するデバイスアプリケーションアイコンと、スマートフォンアプリケーションのそれぞれに対するBluetooth(登録商標)対応及びBluetooth(登録商標)非対応から選択されたユーザ選択設定のための少なくとも1つのアプリケーション構成プロンプトを表示する少なくとも1つの画面に前記GUIを表示するように構成される、
請求項1に記載のデバイス。
【請求項14】
医療用デバイスであって、
前記医療用デバイスとは異なる1つ以上のデバイスとRF信号を交換するように構成された無線周波数(RF)回路と、
メモリデバイスと、
前記RF回路及び前記メモリデバイスに接続され、前記RF回路を介して、RF信号を前記1つ以上のデバイスと交換するための少なくとも2つの無線通信プロトコルのうちの選択された1つを使用するように構成された処理デバイスと、を備え、
前記少なくとも2つの無線通信プロトコルは、
前記医療用デバイスと前記1つ以上のデバイスとをペアリングして、構成データと、医療用デバイス操作データと、前記医療用デバイスの操作するための制御信号と、から選択されたセキュア情報をセキュアに交換するために、前記処理デバイスによって使用される第1の通信プロトコルと、
前記医療用デバイスと前記1つ以上のデバイスとをペアリングして、前記セキュア情報より低いセキュリティを要求する医療用デバイスデータ及び通知から選択された情報を前記1つ以上のデバイスに送信するために、前記処理デバイスによって使用される第2の通信プロトコルと、
を含
み、
前記医療用デバイスは、前記デバイスと前記医療用デバイスとの間で前記セキュア情報を交換するために前記第1の通信プロトコルが必要とされることを示すメタデータを含むように前記セキュア情報が決定されるとき、前記構成データ、前記医療用デバイス操作データ、及び前記制御信号から選択された前記セキュア情報を前記第1の通信プロトコルを介した通信に制限し、前記第1の通信プロトコルを利用しない前記1つ以上の他のデバイスに対する前記セキュア情報の通信を排除するように構成され、
前記医療用デバイスは、前記医療用デバイスから前記1つ以上のデバイスへとセキュリティの低い情報を通信するために前記第2の通信プロトコルを利用することができることを示すメタデータを持つ、前記医療用デバイスデータ及び前記通知から選択されたセキュリティが低い情報のデータを提供するように構成される、
医療用デバイス。
【請求項15】
前記1つ以上のデバイスは、ハンドヘルドと、前記医療用デバイスのための専用コントローラと、前記医療用デバイスの制御を実行するために、そこに記憶される医療用デバイス制御アプリケーションを有するスマートフォンとのグループから選択される、
請求項14に記載のデバイス。
【請求項16】
前記第1の通信プロトコルは、前記医療用デバイスのペアリングを、前記医療用デバイスの操作を制御するための、前記1つ以上のデバイスのうちの選択された1つのみに制限する、
請求項14に記載のデバイス。
【請求項17】
前記第1の通信プロトコルは、Bluetooth(登録商標) Low Energy(BLE)通信プロトコルである、
請求項16に記載のデバイス。
【請求項18】
前記BLE通信プロトコルは、ブロードキャストモードを有しない、
請求項17に記載のデバイス。
【請求項19】
前記第1の通信プロトコルは、前記医療用デバイス及び前記1つ以上のデバイスのうちの選択された1つに特化しており、前記1つ以上の他のデバイスのうちの残りのものによって前記医療用デバイスとペアリングするためには使用不可能である、
請求項16に記載のデバイス。
【請求項20】
前記第2の通信プロトコルは、前記1つ以上の他のデバイスとペアリングするために前記医療用デバイスによって使用される標準Bluetooth(登録商標)プロトコルであり、前記1つ以上の他のデバイスを発見するためのブロードキャストモードを備える、
請求項14に記載のデバイス。
【発明の詳細な説明】
【技術分野】
【0001】
本明細書の例示的実施形態は、ウェアラブル又はポータブル医療用デバイスと他のデバイスとの間の通信のための、及び、リモートデバイスからの医療用デバイス制御信号の通信の改良されたセキュリティのためのシステム、方法、及び装置に関する。
【背景技術】
【0002】
糖尿病などの健康状態の、より良く、より便利な患者管理についての患者及びヘルスケア提供者の要望の増加に伴い、オンボディ又はウェアラブルデバイスに対する、及び、ボディエリアネットワーク(BAN)医療用デバイス(例えば、オンボディデバイスのための無線コントローラ、及び、健康状態管理アプリ及び/又はヘルス/フィットネスアプリを持つスマートフォン又はスマートウォッチ)に対する需要が増加している。例えば、ウェアラブル医療用デバイスの1つのタイプは、例えば、患者の皮膚に装着されるウェアラブル投薬デバイス(例えば、カニューレ又は針が患者の皮膚に挿入されたパッチポンプ)、又は患者のベルトに接続可能なポンプデバイスであり、ポンプから、皮下のカニューレを持つ接着性マウントへと伸びている配管を持つ注入液セットを有する。
【0003】
ウェアラブル医療用デバイスは、無線で、別体の専用コントローラ又はスマートフォン(例えば、無線で、様々な操作のためのウェアラブル医療用デバイスとインターフェースするように構成されたアプリを持つスマートフォン)と通信することができる。Bluetooth(登録商標) Smartとして市場に出回っている、Bluetooth(登録商標) Low Energy(BLE)は、ウェアラブル医療用デバイスのケースでよくありうるような、コインセルバッテリなどの電源で動作するデバイスを含むデバイスを無線で接続するための効果的な低電力プロトコルを提供する無線技術である。
【0004】
ウェアラブル医療用デバイス、特に、薬剤を患者の身体に搬送するデバイスを無線で制御することに伴う懸念は、中間者(MITM)及び盗聴攻撃に対する無線制御通信リンクのセキュリティである。特に懸念されることは、医療用デバイスの制御が他のデバイスによって望ましくない変更を受ける悪意ある攻撃又は意図しない攻撃に対するウェアラブル医療用デバイスのセキュリティである。他の懸念は、ウェアラブル医療用デバイスに記憶されている、及び、ボディエリアネットワーク内、ローカルエリアネットワーク(LAN)、ワイドエリアネットワーク(WAN)、及び/又はインターネット内の他のデバイスと共有されている、あるタイプの患者情報のプライバシーの保護に関して存在する。
【発明の概要】
【0005】
以下で説明される例示的な実施形態によって問題が解決され、追加的な利点が実現される。
【0006】
例示的な実施形態のある態様は、医療用デバイスを制御するためのデバイスであって、RF信号を医療用デバイスと交換するように構成された無線周波数(RF)回路と、メモリデバイスと、RF回路及びメモリデバイスに接続され、RF回路を介して、医療用デバイスとRF信号を交換するための少なくとも2つの無線通信プロトコルのうちの選択された1つを使用するように構成された処理デバイスと、を備え、少なくとも2つの無線通信プロトコルは、デバイスと医療用デバイスとをペアリングして、構成データと、医療用デバイス操作データと、医療用デバイスを操作するための制御信号とから選択されたセキュア情報を安全に送信するために、処理デバイスによって使用される第1の通信プロトコルと、医療用デバイスとは異なる1つ以上のデバイスとペアリングして、セキュア情報より低いセキュリティを要求する医療用デバイスデータ及び通知から選択された情報を1つ以上の他のデバイスに送信するために、処理デバイスによって使用される第2の通信プロトコルと、を含む。
【0007】
例示的な実施形態の態様によれば、デバイスは、ハンドヘルドと、医療用デバイスのための専用コントローラと、医療用デバイスの制御を実行するために、そこに記憶された医療用デバイス制御アプリケーションを有するスマートフォンとのグループから選択される。
【0008】
例示的な実施形態の態様によれば、第1の通信プロトコルは、医療用デバイスのペアリングを、医療用デバイスの操作を制御するためのデバイスのみに制限する。例えば、第1の通信プロトコルは、Bluetooth(登録商標) Low Energy(BLE)通信プロトコルである。さらに、BLE通信プロトコルは、ブロードキャストモードを有しない。
【0009】
例示的な実施形態の態様によれば、第1の通信プロトコルは、医療用デバイスに特化しており、1つ以上の他のデバイスによってデバイスとペアリングするためには使用不可能である。
【0010】
例示的な実施形態の態様によれば、第2の通信プロトコルは、1つ以上の他のデバイスとペアリングするためにデバイスによって使用される標準Bluetooth(登録商標)プロトコルであり、1つ以上の他のデバイスを発見するためのブロードキャストモードを備える。
【0011】
例示的な実施形態の態様によれば、デバイスは、医療用デバイスとペアリングして信号を交換するための第1の通信プロトコルと、1つ以上の他のデバイスとペアリングして信号を交換するための第2の通信プロトコルとを使用することによって、統合疾病管理(IDM)システム内のハブとして動作するように構成され、医療用デバイスは、投薬デバイスであり、1つ以上の他のデバイスは、血糖値モニタと、炭水化物トラッキングデバイスと、身体運動トラッキングデバイスとで構成されるグループから選択される。
【0012】
例示的な実施形態の態様によれば、デバイスは、医療用デバイスに関するデータを他のデバイスに通過させるためのポータルアプリケーションをさらに備え、ポータルアプリケーションは、医療用デバイスから送信されるデータを受信し、それを他のデバイスに提供し、かつデバイスでデータを記憶しないように構成される。
【0013】
例示的な実施形態の態様によれば、処理デバイスは、信号の送信を要求する操作のタイプ及び信号を介して送信される情報のタイプから選択された基準に依存して、RF回路を介して信号を送信するために、第1の通信プロトコル及び第2の通信プロトコルのどちらを使用するかを決定するように構成される。例えば、操作のタイプは、医療用デバイス制御コマンドを送信すること、医療用デバイス構成パラメータを設定すること、医療用デバイスステータスデータを要求すること、医療用デバイスログデータを要求すること、医療用デバイスからのセキュアデータを要求すること、及び1つ以上の他のデバイスにデータを送信することから選択可能である。処理デバイスは、第1の通信プロトコルを使用して、医療用デバイス制御コマンドを送信すること、医療用デバイス構成パラメータを設定すること、及び医療用デバイスからのセキュアデータを要求すること、から選択された操作のタイプを実行し、第2の通信プロトコルを使用して、医療用デバイスステータスデータを要求すること、医療用デバイスログデータを要求すること、及び1つ以上の他のデバイスにデータを送信すること、から選択された操作のタイプを実行するように構成される。
【0014】
例示的な実施形態の態様によれば、1つ以上の他のデバイスは、スマートウォッチ、ポータブルモニタリングデバイス、Bluetooth(登録商標)対応リストバンドデバイス、血糖値モニタ、炭水化物トラッキングデバイス、及び身体運動トラッキングデバイスで構成されるグループから選択される。
【0015】
例示的な実施形態の態様によれば、デバイスは、処理デバイスに接続されたグラフィカルユーザインターフェース(GUI)を含むユーザインターフェースをさらに備える。処理デバイスは、医療用デバイス操作アプリケーション、血糖値モニタアプリケーション、炭水化物トラッキングアプリケーション、及び身体運動トラッキングアプリケーションから選択されたスマートフォンアプリケーションと、投薬管理アプリケーションと、統合型疾病管理アプリケーションとに対応するデバイスアプリケーションアイコンと、スマートフォンアプリケーションのそれぞれに対するBluetooth(登録商標)対応及びBluetooth(登録商標)非対応から選択されたユーザ選択設定のための少なくとも1つのアプリケーション構成プロンプトを表示する少なくとも1つの画面にGUIを表示するように構成される。
【0016】
例示的な実施形態によれば、医療用デバイスであって、医療用デバイスとは異なる1つ以上のデバイスとRF信号を交換するように構成された無線周波数(RF)回路と、メモリデバイスと、RF回路及びメモリデバイスに接続され、RF回路を介して、RF信号を1つ以上のデバイスと交換するための少なくとも2つの無線通信プロトコルのうちの選択された1つを使用するように構成された処理デバイスと、を備え、少なくとも2つの無線通信プロトコルは、医療用デバイスと1つ以上のデバイスとをペアリングして、構成データと、医療用デバイス操作データと、医療用デバイスを操作するための制御信号とから選択されたセキュア情報を安全に交換するために、処理デバイスによって使用される第1の通信プロトコルと、医療用デバイスと1つ以上のデバイスとをペアリングして、セキュア情報より低いセキュリティを要求する医療用デバイスデータ及び通知から選択された情報を1つ以上のデバイスに送信するために、処理デバイスによって使用される第2の通信プロトコルと、を含む。
【0017】
例示的な実施形態の態様によれば、1つ以上のデバイスは、ハンドヘルドと、医療用デバイスのための専用コントローラと、医療用デバイスの制御を実行するために、そこに記憶された医療用デバイス制御アプリケーションを有するスマートフォンとのグループから選択される。
【0018】
例示的な実施形態の態様によれば、第1の通信プロトコルは、医療用デバイスのペアリングを、医療用デバイスの操作を制御するための、1つ以上のデバイスのうちの選択された1つのみに制限する。
【0019】
例示的な実施形態の態様によれば、第1の通信プロトコルは、Bluetooth(登録商標) Low Energy(BLE)通信プロトコルである。例えば、BLE通信プロトコルは、ブロードキャストモードを有しない。
【0020】
例示的な実施形態の態様によれば、第1の通信プロトコルは、医療用デバイス及び1つ以上のデバイスのうちの選択された1つに特化しており、1つ以上の他のデバイスのうちの残りのものによって医療用デバイスとペアリングするためには使用不可能である。
【0021】
例示的な実施形態の態様によれば、第2の通信プロトコルは、1つ以上の他のデバイスとペアリングするために医療用デバイスによって使用される標準Bluetooth(登録商標)プロトコルであり、1つ以上の他のデバイスを発見するためのブロードキャストモードを備える。
【0022】
追加の及び/又は他の態様、及び例示的な実施形態の利点については、以下の説明に記載されるか、又は説明から明らかになるか、又は発明の実施によって学ばれうる。本発明は、ペアリングされるデバイスと、上記の態様の1つ以上、及び/又はそれらの特徴及び組み合わせの1つ以上を有する同じものを操作するための方法とを含みうる。本発明は、例えば、添付の特許請求の範囲に記載されるように、上記の態様の1つ以上の特徴及び/又は組み合わせを含みうる。
【図面の簡単な説明】
【0023】
上記及び/又は他の態様、そして、例示的実施形態の利点は、添付の図面と併せて、以下の詳細な説明から、より容易に理解されるであろう。
【0024】
【
図1】例示的な実施形態による、医療用デバイス及びコントローラを示す。
【
図2A】例示的な実施形態による、医療用デバイスのブロック図である。
【
図2B】例示的な実施形態による、
図1のコントローラのブロック図である。
【
図2C】例示的な実施形態による、他のデバイスのブロック図である。
【
図3】例示的な実施形態による、医療用デバイスから送信される例示的な信号、及びコントローラの例示的なスキャニングウィンドウの図である。
【
図4】例示的な実施形態による、医療用デバイスから送信される例示的な信号、及びコントローラの例示的なスキャニングウィンドウの図である。
【
図5】例示的な実施形態による、医療用デバイスから送信される例示的な信号、及びコントローラの例示的なスキャニングウィンドウの図である。
【
図6A】例示的な実施形態による、コントローラとペアリングされた医療用デバイス、及び他のデバイスとペアリングされたコントローラの第1のユースケースを示す。
【
図6B】例示的な実施形態による、コントローラとペアリングされた医療用デバイス、及び他のデバイスとペアリングされたコントローラの第1のユースケースを示す。
【
図7】例示的な実施形態による、コントローラとペアリングされた医療用デバイス、及び他のデバイスとペアリングされたコントローラの第1のユースケースを示す。
【
図8A】例示的な実施形態による、
図6A、
図6B、
図7のコントローラの例示的なグラフィカルユーザインターフェース画面である。
【
図8B】例示的な実施形態による、
図6A、
図6B、
図7のコントローラの例示的なグラフィカルユーザインターフェース画面である。
【
図8C】例示的な実施形態による、
図6A、
図6B、
図7のコントローラの例示的なグラフィカルユーザインターフェース画面である。
【
図8D】例示的な実施形態による、
図6A、
図6B、
図7のコントローラの例示的なグラフィカルユーザインターフェース画面である。
【
図8E】例示的な実施形態による、
図6A、
図6B、
図7のコントローラの例示的なグラフィカルユーザインターフェース画面である。
【
図10】例示的な実施形態による、スマートフォンであり、かつ他のデバイスとペアリングされることが可能なコントローラにペアリングされた医療用デバイスの第2のユースケースを示す。
【
図11】例示的な実施形態による、スマートフォンであり、かつ他のデバイスとペアリングされることが可能なコントローラにペアリングされた医療用デバイスの第2のユースケースを示す。
【
図12A】例示的な実施形態による、
図10及び
図11のコントローラの例示的なグラフィカルユーザインターフェース画面を示す。
【
図12B】例示的な実施形態による、
図10及び
図11のコントローラの例示的なグラフィカルユーザインターフェース画面を示す。
【
図12C】例示的な実施形態による、
図10及び
図11のコントローラの例示的なグラフィカルユーザインターフェース画面を示す。
【
図12D】例示的な実施形態による、
図10及び
図11のコントローラの例示的なグラフィカルユーザインターフェース画面を示す。
【
図12E】例示的な実施形態による、
図10及び
図11のコントローラの例示的なグラフィカルユーザインターフェース画面を示す。
【
図13】例示的な実施形態による、医療用デバイスから、トラブルシューティング及び問題の診断のための製造者、製品サポートチーム、又はサービスカスタマサポート社員にデータを送信するためのセキュア通信システムの図である。
【
図14】例示的な実施形態による、医療用デバイス、医療用デバイスコントローラ、及び他のデバイスをインターコネクトすることを含む例示的なインフォマティクス強化システムである。
【
図15】スマートフォン上の統合型疾病管理(IDM)アプリケーションの例示的なグラフィカルユーザインターフェース画面である。
【
図16】スマートフォン上の統合型疾病管理(IDM)アプリケーションの例示的なグラフィカルユーザインターフェース画面である。
【
図17】スマートフォン上の統合型疾病管理(IDM)アプリケーションの例示的なグラフィカルユーザインターフェース画面である。
【
図18】スマートフォン上の統合型疾病管理(IDM)アプリケーションの例示的なグラフィカルユーザインターフェース画面である。
【
図19】スマートフォン上の統合型疾病管理(IDM)アプリケーションの例示的なグラフィカルユーザインターフェース画面である。
【
図20】スマートフォン上の統合型疾病管理(IDM)アプリケーションの例示的なグラフィカルユーザインターフェース画面である。
【
図21】スマートフォン上の統合型疾病管理(IDM)アプリケーションの例示的なグラフィカルユーザインターフェース画面である。
【
図22】スマートフォン上の統合型疾病管理(IDM)アプリケーションの例示的なグラフィカルユーザインターフェース画面である。
【
図23】スマートフォン上の統合型疾病管理(IDM)アプリケーションの例示的なグラフィカルユーザインターフェース画面である。
【0025】
図面を通じて、同様の参照番号は、同様の要素、機能、及び構造を参照することが理解されるだろう。
【発明を実施するための形態】
【0026】
ここで、添付の図面に示された例示的な実施形態が詳細に参照されるだろう。
【0027】
ウェアラブル医療用デバイスが他のデバイスと安全に通信し、望まないMIIM盗聴又は乗っ取りを回避する、以下で説明される例示的な実施形態によって、問題が解決され、利点が実現される。さらに、以下で説明される例示的な実施形態は、医療用デバイスが1つ以上の他のデバイスと通信するときに個人データプライバシー侵害の尤度を最小化する。
【0028】
図1を参照すると、ウェアラブル医療用デバイス12と、ディスプレイ24又は他のユーザインターフェースを持つコントローラ14とを有する例示的な投薬システム10が示されている。本明細書で説明されるように、例示的な実施形態によれば、医療用デバイス12は、専用コントローラ14と共に、又はコントローラ14として動作するように構成されたアプリ14を持つスマートフォンと共に使用可能であり、医療用デバイスは、また、そのコントローラ14を介して、例示的な第1のユースケース(例えば、
図6A、
図6B、及び
図7)及び例示的な第2のユースケース(例えば、
図10及び
図11)に関連して以下で説明される追加機能を提供する他のデバイス16、又はスマートフォンアプリ16と接続可能である。これらの他のデバイス16又はスマートフォンアプリ16は、例えば、
図14に示された例示的な統合型疾病管理(IDM)システム内に示されるような血糖値メータ、スマートウォッチ、身体モニタなど、1つ以上のBANデバイスに関連付けられうる。医療用デバイス12、専用無線コントローラ(WC)14、又はスマートフォン内のデバイス制御アプリ14と、追加機能(例えば、IDM機能)を提供する他のデバイス16又はスマートフォンアプリ16とは、相互に、及び、オプションでLAN、WAN又はインターネットクラウド内の追加デバイスとの、通信リンクを有するように構成される一方、個人データプライバシー侵害の尤度、及び、医療用デバイス12の制御が意図せず他のデバイスによって変更される悪意ある攻撃又は意図しない妨害などのMITM及び盗聴アタックを最小化する。例えば、例示的な実施形態に関連して以下で説明されるように、医療用デバイス12及びコントローラ14は、投薬などのセキュア制御操作のためにセキュアなBLEベースのイントラデバイス通信プロトコルを使用し、標準インターデバイスBluetooth(登録商標)プロトコル(例えば、レガシーClassic Bluetooth(登録商標))は、医療用デバイス12と、単に情報(例えば、ステータスデータ又はログデータ又は投薬量)を交換するだけのコントローラデバイス14及び/又はデバイス16(例えば、Bluetooth(登録商標)イアピース又はスマートウォッチ)とをペアリングするために使用可能であるが、医療用デバイス12構成又は投与操作(例えば、ボーラス量を指定又は設定すること、又はポンプ搬送操作を開始又は終了することは行わない)を制御しない。
【0029】
医療用デバイス12は、例えば、インスリン治療を必要とする2型糖尿病(T2DM)を持つ患者の管理のために、設定され及び可変の基礎(24時間周期)レート及びボーラス(オンデマンド)投与でのインスリンの継続的な皮下搬送用に構成される、単一患者への使用のための使い捨てのインスリン搬送デバイス(IDD)12でありうる。しかし、医療用デバイス12は、任意のオンボディ医療用デバイス(例えば、ウェアラブル注入ポンプ又は連続血糖計)又はBAN医療用デバイス(例えば、ハンドヘルド血糖計、健康状態管理アプリを持つスマートフォン、オンボディデバイスのための専用無線コントローラ、スマートウォッチ、又は、ウェアラブルフィットネス及び健康モニタ)でありうることが理解されよう。しかし、医療用デバイス12は、流体搬送のほかにも他のアプリケーションのために使用されることが可能であり、また、医療用デバイス12が投薬デバイスである場合、それは、任意のタイプの流体を搬送するために使用することが可能であり、インスリン搬送に限定されないことも理解されよう。
【0030】
IDD12は、従来の複雑なインスリンポンプに代わる、目立たない、シンプルで費用効果の高いインスリン搬送を必要とする、毎日複数回の注射(MDI)を行う多くの2型患者の満たされないニーズに対応する。
図1、
図2A、及び
図2Bを続けて参照すると、IDD12は、T2DMを持つ患者による使用のための高度なインスリン搬送システムであるシステム10の一部である。IDD12は、通常、ターゲットユーザが居住する全ての環境で1日24時間使用するように構成される。IDD12は、3日間(84時間まで)、患者ユーザがIDDを装着できるように構成される。IDD12は、4つの主要な機能、即ち、ユーザが設定した毎日の基礎インスリンレートを提供すること、ユーザが設定したボーラスインスリン量を提供すること、手動ボーラスインスリン投与を提供すること、及びシステムステータス及び通知を生成すること、を有する。以下で説明するように、IDD12は、Bluetooth(登録商標) Low Energy(BLE)インターフェースを通じて、そのコントローラ(即ち、以下では、無線コントローラ(WC14)と称する)と無線で通信する。IDD操作データに加え、IDD12は、それがIDDの問題(例えば、メモリの破損、少量又は空のリザーバ)を検出した場合に、WC14にフィードバックを送信する。WC14は、毎日の基礎インスリンレートで、患者に対するボーラス又は食物投与インスリン量を搬送するように、IDD12をプログラムするように構成される。WC14は、また、システム10についてのステータス情報を提供するように構成される。WC14は、また、データ交換のために外部デバイス16のBLE無線接続デバイスインターフェース(BWCDI)への接続を可能にする。そのため、WC14は、IDD12データが、BWCDIを介して外部デバイス16に送信できるようにするオプション機能を有しうる。
【0031】
図2Aに示した例示的な実施形態では、IDD12は、ポンピング機構52、(例えば、マッチ回路及びアンテナを有するRF回路54を介した)WCとの無線通信、及びポンプ操作を制御するように構成されたマイクロコントローラ60を有する。IDDは、プログラムされた薬剤搬送に加え、手動での薬剤搬送のためのボーラスボタン64を有する。ポンピング機構52は、カニューレ68を介して、IDDを装着している患者に搬送される液状の薬剤(例えば、インスリン)を格納するためのリザーバ76と、カニューレを通じてリザーバから指定量の薬剤を制御可能に搬送するためのポンプ72とを備える。リザーバ76は、注射器を使用してセプタム(septum)78を介して満たされる。IDDは、カニューレ68を患者に挿入するための手動挿入機構66を有する。しかし、プロセッサ60は、カニューレ68を患者に配置するように、挿入機構66の動作を自動化するためのオプションの駆動回路を操作するように構成されうる。さらに、IDD12は、例えば、オプションで、閉塞検出のために流体センサ74又は圧力センサ70を提供することができる。LED62は、例えば、リザーバプライミングの間など、1つ以上のポンプ操作の間、オンになるように又は点灯するようにマイクロコントローラ60によって操作されうる。IDD12は、58で示されるようなバッテリ又はレギュレータによって給電される。IDD12を始動する(例えば、電源をオンにしてWC12とのペアリングを開始する)とき、ボーラスボタン64は、ユーザによってアクティブ化されたときに、省電力シェルフモードからIDD12を起動させるウェイクアップボタンとして構成されうる。
【0032】
図2Bに示された例示的な実施形態では、WC14は、1)WCメインプロセッサ(WCMP)30と、WC通信プロセッサ(WCCP)32とを有するデュアルマイクロプロセッサコンポーネントとして実装されうる。しかし、WC14は、単一プロセッサデバイスとして構成されうることが理解されよう。2つのプロセッサ30、32は、シリアルペリフェラルインターフェース(SPI)を通じて互いに通信する。2つのプロセッサ30、32は、また、2つの割り込みピンM_REQ_INT及びS_REQ_INTを通じて互いに割り込むことができる。
【0033】
図2Bを参照すると、WCMP30は、タッチスクリーン24を持つLCDディスプレイ、1つ以上のボタン28、オプションのインジケータ26(例えば、スピーカ、振動回路、LED、ブザー)などのユーザインターフェース(UI)コンポーネントに接続される。WCCP32は、無線周波数(RF)コンポーネント38(例えば、アンテナ及びマッチ回路)に接続され、主にIDD12とのWC14の無線通信を担う。しかし、RFコンポーネント38は、異なる通信プロトコルを介して他のデバイス16と通信するために、1つ以上のアンテナ及び関連回路を備えうることが理解されよう。WC14は、電源用の交換可能なアルカリ電池34を除いて、現場サービスができない(即ち、ユーザによって検査、調整、置換、又はメンテナンスされるべきパーツがない)ように設計されている。不揮発性メモリ(例えば、フラッシュメモリ)36は、搬送日及び時刻及び量など、IDD12から受信される搬送及びステータスデータを記憶するためにWC内に提供される。
【0034】
図2Bを続けて参照すると、容量型タッチスクリーン24を持つLCDは、視覚的な及びグラフィカルなユーザへの出力(例えば、システム情報、命令、視覚的な通知、ユーザ設定、データ出力など)を描写することによって、及び、ユーザが入力(例えば、IDDのペアリング及びセットアップ及び投与、及び設定パラメータなどのようなデバイス操作入力)を行うための視覚的なインターフェースを提供することによって、ユーザのための視覚インターフェースとしての役割を果たしている。容量型タッチスクリーン24を持つWCディスプレイは、その表示エリア上での少なくとも単一のタッチジェスチャを検出する。例えば、タッチスクリーンは、ユーザ触覚入力(タップ、スワイプ、及びボタン押下)を認識し、UIスクリーン及びアプリケーション内でのナビゲーションを可能にするように構成される。タッチスクリーン24は、特定のシステム機能(即ち、IDD12のセットアップ及びWC14とのペアリング、インスリン投与、投与履歴をユーザに提供すること、そして、IDDの非アクティブ化、及び他のIDDとの置換など)の実行を促進する。WC14は、また、ユーザによってアクティブ化されたときに、省電力スリープモードからWC14を起動させるデバイスウェイクアップボタンなどのボタン28を含みうる。WC14は、また、低バッテリステータスを示す(例えば、残りの使用が12時間又はそれより少ないときの低バッテリステータスを示す)ためのLED26を有しうる。
【0035】
IDD12とのWC14の無線周波数(RF)インターフェースは、例えば、Bluetooth(登録商標) Low Energy又はBLEベースの通信プロトコルに基づくけれども、他の無線通信プロトコルも使用可能である。例示的な投薬システム10では、WC14及びIDD12は、10フィート又は約3メートルまでの距離以内で、2400MHzから2480MHzスペクトルのISMバンドを使用して無線で通信する。WC14はIDD12と通信する一方、IDDは屋外で身体に装着される。WC14は、セントラルデバイス又はマスタであり、IDD12は、ペリフェラルデバイス又はスレーブである。WCMP30がIDD12に情報を送信したいとき、又はIDD12から情報を取り出したいときはいつでも、それは、WCCP32と相互作用してそのようにし、順番に、
図2A及び
図2Bにそれぞれ示されたように、RF回路54及び38それぞれを介して、BLEリンクを跨いでIDD12と通信する。
【0036】
図2Cは、例示的なデバイス16を示すブロック図である。デバイス16は、例えば、スマートフォン、スマートウォッチ、他のBluetooth(登録商標)対応無線デバイス16のうちの、Bluetooth(登録商標)対応ヘルス及び/又はフィットネスモニタリングデバイス、Bluetooth(登録商標)対応ヘッドセット又はイアピースでありうる。デバイス16は、統合された又は別々のコンポーネントでありうるプロセッサ及びメモリ80を備える。デバイス16は、例えば、Bluetooth(登録商標)無線通信インターフェース84、及びオプションのセルラ通信インターフェース82を有しうる。デバイス16は、また、マイクロフォン88、タッチスクリーン86又はキーパッド又は他のユーザ入力デバイス、オーディオ信号出力デバイス(例えば、スピーカ又はブザー)90、及び/又は振動回路92のうちの1つ以上のような異なるユーザインターフェースを有しうる。WC14は、BLEリンクを跨いで、例えば、RF回路及びBLE無線インターフェースそれぞれを介して、デバイス16と通信する。
【0037】
例えば、参照によって本明細書に組み込まれる、共有されたPCT公開出願WO 2018/183036 及びWO 2018/183038で説明されているように、例示的な実施形態の態様によれば、WC14(例えば、そのWCCP32)及びIDD12は、特定のイントラデバイスペアリングプロトコルと、WC14が意図しないIDD12にペアリングするか、又は、逆に、意図するIDD12が意図しないWC14にペアリングするというリスクを軽減するための様々な操作と、に従って通信することができる。本明細書で定義されるように、「イントラデバイス」とは、WC14が、1つの特定の医療用デバイス12(例えば、IDD12)とペアリングされて結合されることを称している。意図しないペアリングシナリオが、意図しないポンピング機構52の操作又は制御のいずれかを引き起し、潜在的に、患者に有害となりうるインスリンの過剰投与を引き起こす可能性がある。例示的な実施形態の他の態様によれば、WC14は、また、より多くのユビキタス通信プロトコル(例えば、異なる通信可能なデバイス16によって、より共通して使用されるプロトコル)に従って他のデバイス16と通信し、医療用デバイス制御コマンドよりもセンシティブでないデータをWC14が様々なデバイス16に送信することができる。本明細書で定義されるように、「インターデバイス」とは、WC14が、選択されたIDD12の情報を1つ以上の他のデバイス16に送信できることを称している。
【0038】
例えば、Bluetooth(登録商標) Smartとして市場に流通しているBluetooth(登録商標) Low Energy(BLE)は、Classic Bluetooth(登録商標)デバイスと時々称されるレガシーBluetooth(登録商標)デバイスに比べて電力消費が非常に低い、2.4GHzから2.4835GHzの周波数範囲で動作する無線デバイスの間で、パケットベースの無線ネットワークを構築するための無線技術である。Bluetooth(登録商標) Smart仕様に従順な低電力無線デバイスは、それらがボタン又はコインバッテリで長い時間期間動作することが期待されるため、ヘルスケアアプリケーションにとって有利である。Bluetooth(登録商標) Smart Readyデバイスは、Bluetooth(登録商標) Smartデバイスに加え、レガシーClassic Bluetooth(登録商標)デバイスとも通信可能な二重のプロトコルスタックを持つ無線デバイスである。例えば、IDD12制御アプリ16を持つスマートフォンは、それが、例えば、IDD12がポンプ操作データを交換でき及び制御コマンドを受信できるデバイス14を制限する特定のイントラデバイスペアリングプロトコルを使用してペアリングを許可するBluetooth(登録商標) Smart動作を有するIDD12などのパーソナルデバイスに加え、アクティビティモニタ又は連続血糖値モニタ(CGM)などのレガシーClassic Bluetooth(登録商標)デバイス16と通信できるように、Bluetooth(登録商標) Smart Ready動作を有することができる。
【0039】
ここで、IDD12とWC14とをペアリングするための特定のイントラデバイスペアリングプロトコルの説明例が
図3、
図4、及び
図5を参照しながら説明しよう。例示的な実施形態では、以下で説明するように、イントラデバイスペアリングプロトコルは、特定の広告(advertising)及びスキャニングウィンドウ期間を有し、対応するイントラデバイスペアリングソフトウェアが、安全な結合関係のためにIDD12及びWC14に提供される。
図3、
図4、及び
図5を参照して説明されるタイミングは、説明目的のためのものであり、タイミング仕様は設計及び特定のデバイスペアリングアプリケーションに使用される入力に依存して異なりうることが理解されよう。以下でも論じされるように、インターデバイスで、レガシーClassic Bluetooth(登録商標)ペアリングプロトコルを使用可能で、共通して使用される、様々なデバイス16を代わりに、例えば、搬送デバイスの制御通信より低いセキュリティを要求する通信に使用することができ、従って、IDD12とWC14との間のような結合関係はない。
【0040】
イントラデバイスペアリングの前の例示的なIDD12の広告及びWC14のスキャニングが
図3に示されている。ウェイクアップする際、ペアリングの前に、106で示されているように250ms(+/-10%)毎に、IDD12は、IDDスタートアップ広告データパケット100を広告し、3ms(+/-10%)の間、WC14からの可能な応答を待つ。WCMP30の要求時、WCCP32は、746ms(+/-10%)104毎に、約505ms(+/-10%)スキャニングウィンドウ102の間、IDDの広告をスキャニングすることを開始することによって通信を開始する。スキャニング時間期間104の終端で、WCCP32が、トランスポートレイヤタイムアウト期間内にいずれの広告パケット100も検出しない場合、WCCPは、スキャニングを停止し、送信タイムアウトエラーコードを持つNACK応答を送信する。WCCP32はスリープiに移行し、広告は検出されない。
【0041】
WC14は、特定のタイプのデバイス12がその近隣にあるかどうかを決定することができる。WC14が、指定されたIDD識別情報を有するデバイス又はIDDとのみペアリングし、指定されたIDD識別情報を有する他のデバイスとはしないように構成できるように、例えば、IDD12のスタートアップ広告データは、IDD識別情報(例えば、選択された動的な及び/又は静的なパラメータ、又は、製造者及び/又はモデル又は他の特徴などのデバイスのタイプを識別する値)を含みうる。従って、IDD12のスタートアップ広告データが、例えば、その特定の製造者に関するIDD識別情報を有するとWCCP32が決定する場合、WC14は、広告IDD12とペアリングすることができる。そうでない場合、WCCP32は、スキャニングを続ける。
【0042】
ペアリング後の例示的なIDD12の広告及びWC14のスキャニングが
図4に示されている。イントラデバイスペアリングの後、オプションで、IDD12がアクティブにポンピングしていないとき、IDDは、選択されたインターバル108(例えば、1秒(+/-10%)毎)でIDD周期データパケット100を広告する。IDD周期データパケットは、ユーザへの通知の生成を必要とするコンディションを示すか又はそれ以外の通知の要求を示すアラートコード又は他のデータと共に提供されうる。各広告100の後、IDD12は、30ms(+/-10%)の間、WC14からの可能な応答を待つ。ペアリングの後、WCMP30の要求で、WCCP32は、746ms(+/-10%)104毎に、505ms(+/-10%)スキャニングウィンドウ102の間、IDDの広告をスキャニングすることを開始することによって通信を開始する。
【0043】
ポンピングの間の例示的なIDD12の広告及びWC14のスキャニングが
図5に示されている。IDD12が、インスリンなどの薬剤を搬送している場合、それは、オプションで、500ms毎に、2秒間、投与ストローク112の終わりで、広告することができる。それは
図6に示されてないけれども、IDDの吸引(aspirate)期間110と、投与(dispense)期間112との間のブレイクタイムの期間、IDD12は、可能ならば、さらに広告することにトライする。IDD12がポンピングしているとき、WCMP30の要求で、WCCP32は、746ms(+/-10%)104毎に、505ms(+/-10%)スキャニングウィンドウ102の間、IDDの広告をスキャニングすることを開始することによって通信を開始する。
【0044】
図3、
図4、及び
図5の説明例では、イントラデバイス無線プロトコルはWC14によって実装され、それのペアリングされたIDD12は、IDD12が、インスリンを搬送するための又は投与量を設定するための無線コマンドなど、ペアリングされたWC14からの制御コマンドのみ許可するように、そして、センシティブなデバイスデータ又は情報をペアリングされたWC14にのみ送信するように構成する。この結合された、WC12とIDD14との間の特定のイントラデバイス通信関係は、安全及びセキュリティ上の理由のため、他のデバイスがIDD12の操作を制御できないこと及びセンシティブなデータ及び情報を受信できないことを保証し、この結合された、特定のイントラデバイス通信関係は、IDDが非アクティブ化されるまで続く。IDDの非アクティブ化の後、WC14は、新たなIDD12とのペアリングが自由になる。しかし、好適には、任意の所与の時間で、WC14は、1つのIDD12とのペアリングのみが許可される。専用無線コントローラとは対照的に、WC14がスマートフォンである場合、スマートフォンは、スマートフォンのペアリングを制御して、1つのIDD12だけが同時に結合関係となるようにする医療用デバイス制御アプリ14で構成されうる。
【0045】
しかし、標準又はレガシーClassic Bluetooth(登録商標)プロトコルは、IDD12によって、WC又はスマートフォン14とペアリングするために、及び、オプションで、他のデバイス16(例えば、スマートウォッチ、又はBluetooth(登録商標)対応ヘッドセット又はイアピース)とペアリングするために使用されうること、或いは、
図3、
図4及び
図5に関連して上で説明されたイントラデバイスペアリングプロトコルと同じ結合関係制限を必要としない単なる医療用デバイスステータス又はログデータを交換するために、WC14によって、他のデバイス16とペアリングするために使用されることが理解されよう。例えば、IDD12が単に、通知がWC14又は他のデバイス16で生成されることを要求するためにBluetooth(登録商標)リンクを使用している場合、従って、IDD12がセンシティブなIDD動作ステータスデータを送信すること又はコマンドを受信することを行っていない場合、一般的なインターデバイスプロトコル(例えば、レガシーClassic Bluetooth(登録商標))が、同じプロトコルもサポートする他のデバイス14、16とペアリングして、それによる通知を要求するために使用されうる。センシティブでない情報を送信するために、そのようなレガシーClassic Bluetooth(登録商標)対応接続は、IDD12がペアリングされるデバイス16を制限すること、又は、特定の非標準的なインターバルを要求することを必要とせず、従って、安全でセキュアな医療用デバイス操作のために必要とされるセキュリティのレベルを有する無線接続のための特定のイントラデバイスプロトコルをサポートする、IDD12及びWC14、及び/又は他のデバイス16のソフトウェアを要求しない。言い換えると、IDD12及びWC14は、セキュアな投薬制御操作のためにセキュアなイントラデバイスBLEベース通信プロトコルを使用することができ、そして、一般的なインターデバイス及び標準Bluetooth(登録商標)プロトコル(例えば、レガシーClassic Bluetooth)は、IDD12と、単にIDD操作問題に関する通知の要求を受信し、或いは、ステータス又はログデータをIDD12から収集するデバイス14及び/又はデバイス16(例えば、Bluetooth(登録商標)イアピース又はスマートウォッチ)と、をペアリングするために使用することができる。
【0046】
医療用デバイス12、専用コントローラ14、及び医療用デバイスコントローラアプリ14を持つスマートフォンはそれぞれ、少なくとも2つの異なるレベルのセキュリティ要件を有することを特徴とするデータ又は信号をそれぞれ交換するための、少なくとも2つの異なる無線通信プロトコルを実装するように構成される。例えば、
図2A、
図2B、及び
図2Cを参照すると、医療用デバイス12内のRFコンポーネント54、専用コントローラ14内のRFコンポーネント38、又はスマートフォン内の同様のRFコンポーネントは、2つの異なる無線通信プロトコルを適応させるのに必要な場合にアンテナ及びマッチング回路を備えうる。同様に、医療用デバイス12、コントローラ14、又はスマートフォンのための医療用デバイスコントロールアプリ14は、操作のタイプ及び交換される情報のタイプによって、いつ2つの異なる無線通信プロトコルを使用するかを決定するようにプログラムされるか又は別の方法で構成される。例えば、医療用デバイス12及びコントローラ又はコントロールアプリ14は、医療用デバイスの構成及び制御動作、及び関連データ及び信号(例えば、投与量の設定、投与動作を開始及び終了するためのコマンド)を制約し、2つの異なる無線通信プロトコルのうちのよりセキュアなものを介して通信するようにプログラムされるか又は別の方法で構成される。よりセキュアな通信を要求する、構成及び制御操作に関するデータは、メタデータで供給され又は指定されたメモリ位置に記憶されることが可能であり、2つの通信プロトコルのうちのよりセキュアなものが、医療用デバイスと、コントローラ又はコントロールアプリ14との間でそれを交換するために、そして、特定のイントラデバイスプロトコルなどと同じセキュア無線プロトコルも使用しないデバイス16に対するそれの通信を排除するために必要とされる、ことを示す。同様に、デバイス12の設定及び制御データよりセンシティブでないと指定されているデバイス12のログ又は履歴データ又は通知は、メタデータで提供され又は指定されたメモリ位置に記憶され、2つの通信プロトコルのうちのよりセキュアでないものが、医療用デバイス12からコントローラ又はコントロールアプリ14及び/又はデバイス16への、及び/又は、コントローラ又はコントロールアプリ14からデバイス16へのデータを通信するために使用されうる、ことを示す。
【0047】
例示的な実施形態によれば、
図6A、
図6B、及び
図7を参照すると、スマートフォン16は、WC14が、選択されたIDD12の履歴データ(例えば、デバイス12のステータス又はログデータ)をスマートフォン16に中継するが、リアルタイム操作又は制御データは中継しない、例示的なモバイル中継ユースケース又はシナリオに従って使用するように構成され、スマートフォン16は、中継された情報を、WC14からデバイス16及びオプションでクラウドベースシステム94に送信するが、IDD12の操作制御には参加しない。IDD12及び/又はWC14がスマートフォン16で操作できるようにすることによって多くの利点が実現される。例えば、スマートフォン16は、IDD投与データ又はIDDステータスログのバックアップファイルを受信して記憶することによってストレージとIDD12及び/又はWC14の接続性とを増やすことができ、それによって、IDD12及び/又はWC14の複雑性及びコストを低減する。また、スマートフォン16のセルラ無線インターフェース82は、IDD12及び/又はWC14が、ワイドエリアネットワークに接続することを可能にする。例えば、スマートフォンは、IDD12及び/又はWC14をクラウドコンピューティングリソース(例えば、
図7でクラウド94によって表現されているような、インターネットを介した独自の疾病管理システム)に接続することができる。従って、スマートフォン16は、IDDインフォマティクス(例えば、IDDの履歴ボーラス投与量)を、IDD12のデータをユーザの健康に有益なアクションに変換することによって接続を通じてカスタマに価値を提供するデジタルヘルス又は他のIDMパートナーに提供することができる。例えば、スマートフォンアプリ16は、医師、家族、又は支払人によってレビューできるほか、健康状態の健康指導を提供することができる、IDD12データと他の疾病又は患者関連データとの統合されたビューを提供することができる。言い換えると、
図6A、
図6B、及び
図7に示された例示的な実施形態では、IDD12の制御(例えば、構成及びボーラス投与量の設定)は、WC14に残り、スマートフォン16は、単に、非操作的なIDD12の情報をWC14から受信する。
【0048】
図7を参照すると、IDD12、WC14、及びスマートフォン16は、Bluetooth(登録商標)プロトコル信号を交換するために互いに近接している必要がある。WC14は、イントラデバイスBluetooth(登録商標)技術を使用して、IDD12の操作情報を交換する(例えば、IDD12のステータス情報を受信し、IDD12に制御信号を提供する)ためのIDD12用の専用ハンドヘルドコントローラであり、ペアリングして、インターデバイスBluetooth(登録商標)技術を使用してIDD12データの履歴をスマートフォン16に中継するように構成される。次に、スマートフォン16は、例えば、WiFi及び/又はセルラ通信を介して、データを指定されたクラウドベースリソース94にプッシュする。この追加操作を達成するために、WC14は、イントラデバイスBluetooth(登録商標)技術を使用してIDD12とWC14との間の通信を行うために使用される上述した回路及びプログラム可能なロジック操作に加え、Bluetooth(登録商標)トランスポンダと、アンテナと、レガシーClassic Bluetooth(登録商標)などの標準プロトコルを介してインターデバイス通信を行うためのプログラム可能なロジック操作とを提供できる。IDD12には、同様に、Bluetooth(登録商標)トランスポンダと、
図6Bに示すように直接的に、又は、
図6A及び
図6Bに示すようにWC14を介して間接的に、デバイス(16)とのインターデバイス通信に参加するためのブロードキャストモードを追加するプログラム可能なロジック操作とが提供される。
【0049】
WC14によってIDD12に送信される例示的なIDD12の操作情報は、基礎レート、ボーラス投与(即ち、食物投与)ボリューム、ボーラス搬送キャンセルコマンド、及びデバイスステータス照会でありうるが、これらに限定されない。IDD12によってWC14に送信される例示的なIDD12の操作情報は、搬送される時間及びリザーバ流体(例えば、インスリン)の量、ボーラスボタン64のアクティブ化、リザーバ空き信号、及びIDDステータス及びエラーステータスでありうるが、これらに限定されない。上で言及したように、IDD12の操作情報は、IDD12とWC14との間で交換され、上述したイントラデバイスBluetooth(登録商標)技術(例えば、32ビット暗号化を使用し及びオープンブロードキャストを使用しないBLEを介したセキュアなペアリング)を使用することによってセキュアである。
【0050】
例示的なモバイル中継ユースケースについて、
図6A、
図6B、及び
図7に示した例示的な実施形態に続けて関連し、専用ハンドヘルドWC14で生成される例示的なGUI画面が、
図8Aから
図8Eに示されている。WC14は、イントラデバイスプロトコルを介したペアリングに続いてIDD12を構成するようにプログラムされる。例えば、WC14は、搬送される食物ボーラス量を設定することができる。WC14は、また、ステータス信号をIDD12から受信し(例えば、IDD12は、現在、搬送しており、また、搬送量、IDD12内のリザーバ76は、空に近いか又は空であり、IDD12のリザーバ76内の流体は、期限に近いか又は期限切れであり、IDD12で動作エラーが発生している)、そして、搬送量情報に基づいて食物投与サマリ、及びIDDログファイル(例えば、IDDウェイクアップ、ボタン64の押下などの日付及び時刻)を生成しうる。
図8Aは、リザーバ76流体の搬送が進行していることを示すIDD12ステータス信号をWC14が受信しているときに生成されうるWC14上の例示的なIDD搬送ステータス画面を示す。
図8Bは、WC14上の例示的なIDDステータスエラー画面を示し、それによって、IDD12は、空のリザーバ76又はIDD故障などの選択されたIDDステータスコンディションを示すIDD12からのステータス信号を受信することに応じて、WC14によって非アクティブ化される。
図8C、
図8D、及び
図8Eは、IDD12から受信される投与搬送情報のログを使用してWC14によって生成されうるWC14上の例示的な食物投与情報画面を示す。
【0051】
例示的なモバイル中継ユースケースについて、
図6B、
図6B、及び
図7に示した例示的な実施形態に続けて関連し、スマートフォン16で生成される例示的なGUI画面が
図9A及び
図9Bに示されている。スマートフォン16は、投与履歴データを受信できるが、ステータス照会又は構成データ又は搬送キャンセルコマンドをIDD12に送信することなど、IDD操作情報をWC14又はIDD12と交換することはしない。例えば、スマートフォン16は、WC14から受信された履歴を使用して、
図9A及び
図9Bに示した食物投与サマリ画面などの画面を生成しうるが、任意のリアルタイムIDD操作情報を使用して画面を生成することはない。例えば、毎日の投与(例えば、
図8A)は、
図9Aのスマートフォン16画面内に、毎日の投与プロットを生成するために使用でき、WC14から受信される7日、14日、30日平均(例えば、
図8B及び
図8C)は、
図9Bのスマートフォン16画面内に、7日、14日、30日平均を生成するために使用できる。
【0052】
他の例示的な実施形態によれば、
図10及び
図11を参照すると、スマートフォン16は、例示的なモバイルコントローラユースケース、又はスマートフォン16がWC14として動作する(即ち、IDD12とのリアルタイム操作データの交換を使用するIDD12の操作制御に参加する)シナリオに従って使用するように構成され、スマートフォン16は、IDD12操作情報よりもセンシティブでない情報を他のデバイス16、及びオプションでクラウドベースシステム94に送信できる。言い換えると、スマートフォン16には、医療用デバイス制御アプリ14(例えば、iPhone及び/又はAndroid)内のIDD12のWC操作制御オペレーションが提供され、そして、IDD12データがデバイス16又は記載されたインターフェース(例えば、クラウド)にプッシュされるようにプログラムされる。医療用デバイス制御アプリ14は、スマートフォン16を制御して、上記のイントラデバイスBluetooth(登録商標)技術(例えば、32ビット暗号化を使用し及びオープンブロードキャストを使用しないBLEを介したセキュアペアリング)を使用して安全なIDD12との操作情報の交換を実行する。スマートフォンは、また、異なるインターデバイス通信プロトコル(例えば、レガシーClassic Bluetooth(登録商標))を使用して、IDD12操作情報よりセンシティブでない情報を、クラウドベースシステム94などの他のデバイス16に送信するように構成される。
図10及び
図11のモバイルコントローラユースケースにおける医療用デバイス制御アプリ16について、スマートフォン16で生成される例示的なGUI画面が、
図12Aから
図12Eに示されており、それらは、独自の表示構成パラメータを有しうる専用WC14のGUI画面に代えて、スマートフォンGUI画面としてフォーマットされていること以外、
図8Aから
図8Eに示された画面に類似している。例示的なモバイルコントローラユースケースについて、スマートフォンは、また、
図9A及び
図9Bに示した画面を生成できる。
【0053】
他の例示的な実施形態によれば、
図6A及び
図7に関連して説明された(即ち、例示的なモバイル中継ユースケースに従って動作するように構成された)スマートフォン16は、また、スマートフォン16のユーザが、搬送されるインスリンの単位数などIDD12の操作情報を調整することを許可する追加的な機能を持つようにプログラムされうる。例えば、ユーザは、IDD12を制御するWC14操作(例えば、投与量設定)の全て又は一部だけについて
図10及び
図11に示した例示的な実施形態に関連して上記のように実装されうる、WC14を介して又は医療用デバイス制御アプリ14を持つスマートフォン16を間接的に介して、IDD12の基礎又はボーラスインスリン投与を調整できる。例えば、
図10及び
図11の例示的なモバイルコントローラユースケースに従って使用されるスマートフォン16は、(例えば、32ビット暗号化を使用し及びオープンブロードキャストを使用しないBLEを介したセキュアペアリングなどの上記のようなイントラデバイスBluetooth(登録商標)技術を使用する)WC14とのセキュア通信のための通信プロトコルを使用するように構成される。しかし、スマートフォン16の医療用デバイス制御アプリ14によってWC14と通信するために使用されるイントラデバイスBluetooth(登録商標)技術は、IDD12とWC14との通信に使用される上述した制約(例えば、広告インターバル、及びスキャニングのためのウィンドウ、及び
図3~
図5に示したようなIDD電力抑制)を有する必要がない。スマートフォン16は、また、異なるインターデバイス通信プロトコル(例えば、レガシーClassic Bluetooth(登録商標))を使用して、IDD12操作情報よりもセンシティブでない情報をクラウドベースシステム94に送信するモバイル中継ユースケース用に構成される。例えば、モバイル中継ユースケースでは、スマートフォン16は、スマートフォン16のIDMアプリと患者の血糖値モニタとをペアリングしてBGレベルをトラッキングし、また、インスリン投与を取得するなど、インターコネクトされた糖尿病管理(IDM)システムとの協働を可能にするために、(例えば、Bluetooth(登録商標)又は非BAN接続のための他の無線通信プロトコルを使用する)LAN/WANとインターコネクトすることができる。
【0054】
医療用デバイス12(例えば、IDD)に関連したスマートフォン接続の他の利点は、他の例示的な実施形態に従って、
図13に関連して実現される。現在、医療用デバイスからの非常に限定されたシステムデータ(例えば、デバイス12のデータ又は患者が生成したデータ)が、製造者又はリモートトラブルシューティングのための製品サポートチームで使用可能である。カスタマサポートモードは、通常、(例えば、パスワードを介して)エンドユーザ122で使用可能であり、一部の情報は、概して126で示されるように、カスタマサービス社員124に電話を介して中継される。しかし、データは、非常に限定されており、度々、医療用デバイス12の不具合又は故障の診断を助けることにはならず、エンドユーザは、詳細解析及びトラブルシューティングのために、その製造者にデバイス12を送り返さねばならないことになる。デバイスをその製造者に返却するための、そのような要求は、多くのチャレンジを与える。例えば、ユーザ122は、解析のためにデバイス12を製造者に送り返すことを全く行わないことを選択するかもしれない。ユーザ122がデバイス12を製造者に返却することを選んだ場合、ユーザは、デバイス12を除染しなくてはならないことがある。また、デバイス12を運送するための特別なパッケージングが必要になるかもしれず、それは製造者に対するコストを増加させる。また、解析及びトラブルシューティングのために物理的にデバイス12をその製造者に運送することは、デバイス12の問題の診断の遅延を引き起こし、デバイスが使用できない間、患者の治療が遅延する可能性がある。
【0055】
例示的な実施形態によれば、デバイス12のデータを、カスタマサービス社員124がリモートで見ることを許可するスマートフォン16用のパススルーポータルアプリ128が提供される。デバイス12のデータはセンシティブ(即ち、プライバシー保護及び/又はデバイス操作に対する悪意ある攻撃に対するセキュリティを要求する)でありうるので、医療用デバイス12からのデータは、スマートデバイス(例えば、スマートフォン16)のポータルアプリ128を通過するが、スマートデバイス上には保存されない。ポータルアプリ128は、代替として、スマートフォン16を介して医療用デバイス12のデータをクラウド94に中継し、データは、リモート診断のためにクラウド94に存在する。ポータルアプリは、例えば、上記のイントラデバイスBluetooth(登録商標)技術(例えば、32ビット暗号化を使用し及びオープンブロードキャストを使用しないBLEを介したセキュアペアリング)を使用して、ポータルアプリ128とデバイス12との間でデータを交換するように構成されうる。同様に、クラウド94は、同じイントラデバイスBluetooth(登録商標)技術(例えば、32ビット暗号化を使用し及びオープンブロードキャストを使用しないBLEを介したセキュアペアリング)を使用して、ポータルアプリ128とデータを交換するように構成されるクラウドコンピューティングデバイスを有しうる。医療用デバイスとクラウド94との間で安全にセンシティブなデバイスデータを中継するためのポータルアプリ、及び、カスタマサービス社員124によるクラウド94上のデータへの安全なアクセスは、カスタマサービス社員124が、カスタマサービスコールの間、医療用デバイス12のシステムデータのスナップショットを見ることを可能にする。
【0056】
上記のように、医療用デバイス12からのシステムデータは、エンドユーザ122のスマートデバイス(例えば、スマートフォン16)に、モバイルアプリ128を介して送信される。ユーザのデバイス16にダウンロードされると、このアプリ128は、スマートフォン16に、そして次に、
図13の130で示されるようなWi-Fi又はセルラ通信を使用するクラウド84を介して製造者に、デバイス12のデータを送信すること、を承認するようにユーザ122に要求することができる。アプリ128は、一般に、パススルーモードをサポートし、あらゆるデータをスマートフォン16上に記憶しないポータルである。デバイス12のデータは、代替として、クラウド94に記憶され、カスタマサービス社員124がそれを見てユーザ122のデバイス12のトラブルシューティングを行う。従って、パススルーアプリ128は、医療用デバイス12の問題をリアルタイムに診断することを容易にする。
【0057】
例えば、エンドユーザ122は、フリーダイヤルを介してカスタマサービス124に電話をかける(ステップ1)。カスタマサービス社員124が、ユーザ122によって最初に提供されるデータを使用して、最初の電話でデバイス12の診断又は問題を解決できない場合(ステップ2)、カスタマサービス担当者124は、より詳細な解析のために、デバイス12それ自体に代えて、医療用デバイス12のデータを送信するための承認をエンドユーザ122から得る(ステップ3)。カスタマサービス担当者124は、ユーザ122に、インターネット(例えば、Google Play又はiPhone App Store)からユーザのスマートデバイス上にアプリ128をダウンロードするように指示することができる(ステップ4)。カスタマサービス担当者124及び/又はアプリ128を介して提供される指示は、ユーザ122が、デバイス12のデータを、スマートデバイス16を介して、カスタマサービス担当者がアクセス可能なセキュアサーバ94に送信するために必要なステップを完了することをアシストする(ステップ5)。カスタマサービス担当者124は、次に、デバイス12のデータの詳細なデータ解析を実行することができ(ステップ6)、エンドユーザに、解決策又は少なくとも診断及び/又はエンドユーザ122へのフィードバックを、電話を終える前など、リアルタイムに提供することができる(ステップ7)。
【0058】
図14は、モバイルIDMアプリケーション及びデバイス接続の使用を通じてコンシューマヘルス体験を改善するIDMシステム140などの例示的なインフォマティクス拡張システム内の他のデバイスに接続されたスマートフォン16を伴う、IDD12及びWC14の例示的な実施形態を示す。システム140は、高度にパーソナライズされた関連コンテンツ体験を各ユーザに提供し、体験は、そのユーザの患者の旅程に合うようにカスタマイズされる。例えば、実用的な洞察は、医療/健康デバイスデータの受動的な追跡及びそのデータへの便利なアクセスから得られうる。
図14に示すように、WC14は、IDD12及び血糖(BG)メータや16aで表されたその対応するスマートフォンアプリなどの他のBANデバイスとの安全な無線通信(例えば、イントラデバイスBLE技術を使用するもの)のためのBAN内のハブとして動作するように構成されうる。WC14は、また、異なるインターデバイス通信プロトコル(例えば、ブロードキャストモードを持つBLE)を使用して、IDD12からの通知及び履歴データをスマートフォン16に通信するように構成されうる。加えて、WC14は、同じ又はさらに別のインターデバイス通信プロトコルを使用して、他のデバイスのデータのうち、IDD12及びBDメータ16bの履歴データを送信し、そして、医療又は患者のデータを医師/ヘルスケア提供者(MD/MCP)のコンピュータ又は16cで示されたコンピュータシステム、及び/又は、外部の医療サービスシステム142内のユーザに関連付けられたMD/HCP、薬局及び介護者に対応するデバイス16d、16e、…、16nから受信しうる。IDD12は、WC14としてスマートフォンで操作されうるし、従って、また、他の例示的な実施形態に従ってハブとしても動作しうることを理解されよう。IDMシステム140の利点は、スマートフォン16のIDMアプリでのベストプラクティス、コツ、及び洞察へのアクセス、並びに統合された健康及び/又は疾病管理コーチングサービス及び双方向通信を介したリスクトライアリングなどの改善されたカスタマ体験である。加えて、IDMシステム140は、その他の機能のうち、一貫性のある完全な臨床データセット(例えば、接続されたメーター16bから報告されるBG値)、投与及び滴定アルゴリズム、ケアプラン順守モニタリング及び統合緊急医療応答(EMR)計画)への便利なアクセスを提供する。
【0059】
図15は、スマートフォン16にダウンロードされ、インストールされたIDD12の制御アプリ及びIDMアプリをそれぞれ開いてアクセスするためのアイコン150及び152を有するスマートフォン16上で生成された例示的なGUIホーム画面148である。他のアイコン(図示せず)は、BGモニタ、運動モニタリングアプリ、炭水化物トラッカ、薬物搬送ペンからデータをキャプチャするためのアプリなどのような様々な医療/健康アプリに提供されうる。
【0060】
図16は、データを交換するためにBluetooth(登録商標)を介して他のデバイス16と接続できるスマートフォン16上の医療/健康アプリをユーザが選択できるようにする、スマートフォン16上に生成された、接続された医療/健康デバイスの例示的な設定画面154である。例えば、ユーザは、GUIトグルボタン156を使用して、スマートフォン16のBluetooth(登録商標)機能をオン又はオフすることができる。接続されたデバイスアプリのリストは、ペンアプリ、ポンプアプリ(例えば、IDD12のためのもの)、BGメータアプリ、Fitbitアプリ、及びIDMアプリのように、画面154に現れる。列挙された各アプリは、そのビューを拡大するための選択ボタン158を有し、Bluetooth(登録商標)接続のための、即ち、アプリに対し、その対応する接続デバイスと無線で信号を交換することを許可し、そして、IDMアプリに対し、クラウド94又は他のリモートIDMコンピュータに情報を転送することを許可するための、トグルボタン160を示す。
【0061】
図17は、接続されたBGデバイスからのグルコースデータ、IDD12及び/又は接続されたペンからの投与データ、及び(例えば、接続されたFitbitからの)活動データを示す、スマートフォン16上で生成された例示的なIDMアプリホーム画面164である。
図18は、対応するデータポイント(例えば、投与の履歴、又はBG値、又は消費された炭水化物、及び/又は活動レベル)を一覧表示することによって、他の画面上又はポップアップダイアログボックス内に、画面ビューを拡大するために選択されうるMyData、BG、及びLOGをそれぞれ選択するためのボタン168、170、及び172を有する他の例示的なIDMアプリホーム画面166である。画面166は、また、例えば、予測分析と、機械学習モジュールと、それに限定されないが、以下のもの、即ち、日付、時間、及びBGの読み取り値及び搬送薬剤の量又はレベル、ユーザの活動レベルに関連する情報、気分又は一般的な健康状態の兆候、摂取した炭水化物などの食事データ、そして、チャットボットの問い合わせ及び応答を含むIDMアプリとのユーザインタラクションの履歴、のいずれかなどのユーザデータとを使用して生成された、ユーザへのメッセージを提供するセクション174を含む。メッセージは、ユーザが、もっと教えてボタン182をアクティブ化することによって受信することを選択することができる選択情報を提供するためのオファーでありうる。
【0062】
図18の例示的なIDMアプリホーム画面166は、また、ボタン176のアクティブ化に応じてスマートフォン16上で生成できる
図19の例示的なチャットダイアログ画面180に示されるように、ユーザの問い合わせのための英数字テキストが入力できる、画面特徴178を生成させるために選択できる、IDMに尋ねるボタン176を備える。
【0063】
図20~
図23の例示的な画面は、例えば、もっと教えてボタン182(例えば、
図18の画面166を参照)のアクティブ化、又は、
図19に示された画面180内の画面部分178に入力された対応する問い合わせに応じて、IDD12に関する情報を提供する。
図20~
図23は、ユーザに、例えば、WC14の特徴の紹介、IDD12パッケージングに提供される項目、及びIDD12を装填すること、ユーザの皮膚にIDD12を適用すること、ボーラス又は食物投与を設定し、手動でボタンをアクティブ化してボーラス投与を開始するためにIDD12を使用することを行うためにそれらをどのように使用するかを提供するそれぞれの画面又は画面内の動画再生のそれぞれの部分である。
【0064】
例示的な実施形態によれば、保護された健康情報(PHI)及び個人の特定可能情報(PII)及び他の種類の個人データ及びセンシティブデータのセキュリティは、そのようなデータを送信することも取得することもしないようにIDD12及びWC14を設定することによって維持される。例えば、IDD12及びWC14は、セキュア通信プロトコルを使用するデバイス間で、構成データ(例えば、投与量)のみ送信するように構成される。さらに、IDD12及びWC14は、構成データを記憶するが、PII又はPHIは記憶しないように構成される。IDD12及びWCが他のデバイスと通信する場合、デバイス16又はそのアプリは、また、デバイスを制限して、システム10内の接続デバイス12、14、及び16から取得される構成又はステータス又はログデータを記憶し、PII又はPHIは一切記憶しないように構成される。
【0065】
例示的な実施形態によれば、IDD12及びWC14に関するセキュリティは、接続デバイス16がIDD又はWCのステータスをモニタリングすることを許可しないことによって維持されうる。代替として、WC14は、BWCDIとのセキュアなペアリング後にのみ、ログファイルのみをBWCDIに送信することに制限されるように構成される。
【0066】
例示的な実施形態によれば、IDD12は、メンテナンス又はプッシュ更新を受信しないように構成される。例えば、IDD12は、使い捨てであり、そのライフサイクルの間、更新が必要ないように構成される。加えて、WC14は、また、サービス処理に関して制限されるように構成される。例えば、初期配布の後、WCは、現場サービスができない(即ち、ユーザによって検査、調整、置換、又はメンテナンスされることが許されるパーツがない)ように設計される。
図13の例示的な実施形態を参照して説明されたように、医療用デバイス12から製造者、製品サポートチーム、又はサービスカスタマサポート社員へのシステムデータのセキュア通信は、一般的なシステム問題のリモートトラブルシューティング及び診断を提供し、及び/又は、患者及び/又は介護者へのシステムの適切な使用及びメンテナンスを強化するためのパススルーアプリ128を介して提供されうる。加えて、システム10は、保存されたカスタマデータを使用して、電子メール、音声メール、又はダイレクトメールでカスタマに連絡するなどの適切な方法で、内部プロセスを使用して、カスタマに直接、寿命の終わり及びサポートの終わりの通知を提供することができる。代替的に又は追加的に内部プロセス。
【0067】
IDDコントローラ操作及び他のデバイス通信のためのスマートフォンアプリ14及び16は、それぞれ、スマートフォン14又は16、又は他の接続されたデバイス16で、キャプチャされ、送信され、そして記憶されるデータを同様に制限する。例示的な実施形態によれば、システム10は、潜在的なMITM攻撃へのシステム耐性を高めるため、デバイス固有の、IDD12とWC14とをペアリングするためのBluetooth(登録商標)ペアリングアウトオブバンド(OOB)アソシエーションモデルを使用する。さらに、WC14では承認又は認証が要求されない。言い換えると、デバイス14にアクセスする誰もがデバイス14を使用し、そして制御することができ、それは人的要素理由(例えば、使いやすさのための患者及び介護者の好み)のために有利である。
【0068】
この開示は、その適用において、以下の説明に記載されるか又は図面に示される構成の詳細及びコンポーネントの配置に限定されないことが当業者によって理解されよう。本明細書の実施形態は、他の実施形態が可能であり、様々な方法で実施又は実行可能である。また、本明細書で使用される表現及び用語は、説明を目的とするものであり、限定としてみなされるべきではないことが理解されよう。本明細書における「含む」「備える」又は「有する」及びそれらの変形の使用は、その後に記載される項目及びその均等物、並びに追加の項目を包含することを意味する。特に限定されない限り、本明細書における用語「接続」「結合」及び「取り付け」及びそれらの変形は広く使用され、直接的及び間接的な接続、結合、及び取り付けを包含する。加えて、用語「接続」及び「結合」及びそれらの変形は、物理的又は機械的な接続又は結合に限定されない。さらに、上、下、底面、及び上面などの用語は相対的なものであり、説明を容易にするために使用されるが、それに限定されるものではない。
【0069】
例示的な実施形態に従って使用された例示的なデバイス、システム、及び方法のコンポーネントは、少なくとも部分的に、デジタル電子回路、アナログ電子回路、又はコンピュータハードウェア、ファームウェア、ソフトウェア、又はそれらの組み合わせで実装されうる。これらのコンポーネントは、例えば、プログラマブルプロセッサ、コンピュータ、又は複数のコンピュータなどのデータ処理装置による実行するために又はその動作を制御するために、情報キャリア内に、或いは、マシン可読ストレージデバイス内に明確に組み込まれる、コンピュータプログラム、プログラムコード、又はコンピュータ命令などのコンピュータプログラム製品として実装できる。
【0070】
コンピュータプログラムは、コンパイル又はインタプリタ言語を含む任意形式のプログラミング言語で記述でき、それは、スタンドアロンプログラム、又はモジュール、コンポーネント、サブルーチン又はコンピューティング環境での使用に適した他のユニットを含む任意の形式で展開できる。コンピュータプログラムは、1つのサイトで1つのコンピュータ又は複数のコンピュータ上で、又は複数のサイトを跨いで分散されて通信ネットワークによってインターコネクトされたものの上で実行されるように展開されうる。また、例示的な実施形態を達成するための機能プログラム、コード、及びコードセグメントは、例示的な実施形態が関係する当該分野のプログラマーによって本発明の範囲内であると容易に理解できる。例示的な実施形態に関連する方法ステップは、(例えば、入力データを操作すること及び/又は出力を生成することによって)機能を実行するためのコンピュータプログラム、コード、又は命令を実行する1つ又は複数のプログラマブルプロセッサによって実行できる。方法ステップはまた、例示的な実施形態の装置によって実行することができ、例示的な実施形態の装置は、特定目的ロジック回路、例えば、FPGA(field programmable gate array)又はASIC(application-specific integrated circuit)として実装できる。
【0071】
本明細書に開示される実施形態に関連して説明される様々な例示的な論理ブロック、モジュール、及び回路は、本明細書で説明された機能を実行するように設計された、汎用プロセッサ、デジタル信号プロセッサ(DSP)、ASIC、FPGA、又は他のプログラマブル論理デバイス、ディスクリートゲート又はトランジスタロジック、ディスクリートハードウェアコンポーネント、又はそれらの任意の組み合わせで実装又は実行されてよい。汎用プロセッサは、マイクロプロセッサであってよいが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、又はステートマシンであってよい。プロセッサはまた、コンピューティングデバイスの組み合わせ、例えば、DSPとマイクロプロセッサの組み合わせ、複数のマイクロプロセッサ、DSPコアと組み合わせた1つ以上のマイクロプロセッサ、又は任意の他のそのような構成として実装されてよい。
【0072】
コンピュータプログラムの実行に適したプロセッサは、例として、汎用及び特定目的マイクロプロセッサの両方、及び任意の種類のデジタルコンピュータの任意の1つ以上のプロセッサを含む。一般に、プロセッサは、読み取り専用メモリ又はランダムアクセスメモリ又はその両方から命令及びデータを受信するだろう。コンピュータの主要な要素は、命令を実行するためのプロセッサと、命令及びデータを記憶するための1つ以上のメモリデバイスである。一般に、コンピュータはまた、データを記憶するための1つ以上の大容量ストレージデバイス、例えば、磁気、光磁気ディスク、又は光ディスクを含むか、又は、そこからデータを受信するか又はそこへデータを送信するか又はその両方を行うように動作可能に結合される。コンピュータプログラム命令及びデータを実装するのに適した情報キャリアは、例として、半導体メモリデバイス、例えば、電気的にプログラム可能な読み取り専用メモリ又はROM(EPROM)、電気的に消去可能なプログラム可能なROM(EEPROM)、フラッシュメモリデバイス、及びデータストレージディスク(例えば、磁気ディスク、内蔵ハードディスク、又はリムーバブルディスク、光磁気ディスク、及びCD-ROM及びDVD-ROMディスク)を含む、全ての形態の不揮発性メモリを含む。プロセッサ及びメモリは、特定目的の論理回路によって追加されるか又はそこに組み込まれうる。
【0073】
当業者は、情報及び信号が、任意の様々な異なる技術及び技能を使用して表現されてよいことを理解するだろう。例えば、上記の説明を通じて参照されることがあるデータ、命令、コマンド、情報、信号、ビット、シンボル、及びチップは、電圧、電流、電磁波、磁場又は粒子、光場又は粒子、又はそれらの任意の組み合わせによって表現されうる。
【0074】
上記の説明及び図は、例としてのみ意図されており、以下の特許請求の範囲に記載されるものを除いて、いかなる方法でも限定することを意図しない。当業者は、上で説明した様々な例示的な実施形態の様々な要素の様々な技術的態様を多くの他の方法で容易に組み合わせることができることに特に留意されたい。