JP2016537738A - 医療データ重要度およびリソース状態に基づく通信デバイスリソースの割り当て - Google Patents

Abstract

他のデータに加えて医療データを処理および通信するように構成された通信デバイスのリソースを管理するための方法およびデバイスが開示される。システムおよびデバイスは、少なくとも1つの信号に基づいて、医療モードに切り替えるかどうかを決定するステップを含む方法を実施することができる。医療モードに切り替えることを決定することに応答して、通信デバイスは医療モードに切り替えられ得る。通信デバイスによって使用される複数のリソースに関連付けられたリソース状態は、通信デバイスによって管理される医療データに関連付けられた医療データ重要度に対して比較検討され得る。方法は、複数のリソースのうちの1つのリソースをスライディング優先度スケール上に割り当てるステップを含むことができる。割り当てるステップは、他のデータよりも医療データに優先的に複数のリソースのうちの1つのリソースを割り当てるステップを含むことができる。

Description

関連出願
本出願は、その内容全体がすべての目的のために参照により本明細書に組み込まれている、「Mobile Communication Device Resource Allocation Based On Medical Data Criticality and Resource Status」と題する、2013年9月3日に出願した、米国仮出願第61/873,155号の非仮特許出願である。

スマートフォンまたはフィーチャーフォンなどの現代的な通信デバイスは、医療データとインターフェースすることまたは医療データを管理することに固有ではない様々な機能を実行する。また、そのような通信デバイスは、一般的に、それらが設計された機能を実行するために必要な様々なリソースを備えている。そのようなリソースは、電源(たとえば、バッテリ)、無線(セルラー、GPS、Wi-Fi、Bluetooth(登録商標)など)、プロセッサ、内部機能(たとえば、アプリケーション)、メモリ、センサ、ディスプレイ、インターフェース、周辺機器、および通信デバイスに利用可能なリモートネットワーク要素を含むことができる。リソースは、デバイスの様々な機能を実行するために共有され得る。たとえば、セルラー電話に関して、ショートメッセージサービス(SMS)を介して送信されるテキストメッセージは、音声通話中に到着する可能性があり、両方の機能は、セルラーアンテナと、中央プロセッサと、バッテリとを共有する。同様に、通信デバイスは、GPS追跡を実行し、かつビデオストリーミングセッションを維持する間、リソースを共有することができる。リソース使用の衝突が通信デバイスの異なる機能間で生じたとき、これらの共有されるリソースは負担がかけられる可能性があり、これは性能に影響を及ぼす可能性がある。加えて、通信デバイスが完了するための複数のタスクを有するが、それらすべてを完了するために所与のリソースでは十分でないとき、単純に、先着順にタスクを完了することができる。また、バッテリ電力が不足してきたとき、通信デバイスリソース管理システムは、事前定義されたリソース優先度に基づいてリソースを割り当てることができる。したがって、従来の通信デバイスは、多くの医療用途をサポートするにはあまり適していない。

様々な実施形態は、他のデータに加えて医療データを処理および通信するように構成された通信デバイスのリソースを管理するための方法、システム、およびデバイスを含む。システムおよびデバイスは、少なくとも1つの信号に基づいて医療モードに切り替えるかどうかを決定するステップを含む方法を実施することができる。医療モードに切り替えることを決定するステップに応答して、通信デバイスは医療モードに切り替えられ得る。通信デバイスによって使用される複数のリソースに関連付けられたリソース状態は、通信デバイスによって管理される医療データに関連付けられた医療データ重要度に対して比較検討され得る。方法は、スライディング優先度スケールに複数のリソースのうちの1つのリソースを割り当てるステップを含むことができる。割り当てるステップは、複数のリソースのうちの1つのリソースを、他のデータよりも医療データに優先的に割り当てるステップを含むことができる。

さらなる実施形態は、オン信号およびオフ信号のうちの一方である少なくとも1つの信号を含むことができる。加えて、少なくとも1つの信号は、常時オン信号および常時オフ信号のうちの一方であり得る。また、切り替えるかどうかを決定するステップは、手動制御、複数のリソースからの入力に基づいて医療モードまたは通常モードに自動的に切り替わる第1のプロセッサ制御、および複数のリソースからのシグナリングと工場設定とに基づいて医療モードまたは通常モードに切り替わる第2のプロセッサ制御のうちの1つに基づくことができる。リソース状態を比較検討するステップは、通信デバイスとは別のリモートリソースによって実行され得る。

さらなる実施形態は、様々な方法で複数のリソースを割り当てるステップを含むことができる。医療データの少なくとも第1の部分は、通信デバイスの第1のオンボードリソースに転送され得る。加えて、医療データの少なくとも第2の部分は、通信デバイスの第2のオンボードリソースからリモートリソースに転送され得る。リソースの使用の所定の部分は、医療データを管理するために利用可能であると保証され得る。加えて医療データは、通信デバイスの第3のオンボードリソースの使用に関して他のデータよりも優先され得る。リソースは、医療データの管理専用にされ得、他のデータのために使用されることを防止され得る。リソースが医療データを管理するために使用される専用のリソースであるとき、医療データはリソースに転送され得る。また、複数のリソースは、他のデータを管理するために使用されることを防止され得る。

さらなる実施形態は、専用リソースが医療データのために使用され、他のデータのために使用されることを抑制される医療モードに切り替わるデバイスに応答してアクティブ化され得る、1つまたは複数の専用リソースを有する通信デバイスを含むことができる。そのような専用リソースは、医療関連データを処理し、分析し、記憶し、および/または送信することに専用であり、排他的に使用される、医療モードプロセッサ、医療モードメモリ、および/または医療モードトランシーバもしくはモデムの形態であり得る。また、通信デバイスのリソースまたは通信デバイスそれ自体は、システムオンチップ(SOC)であり得、または医療グレードSOCでさえあり得る。この方法では、様々な実施形態の動作を実行するためにソフトウェア命令を用いて構成された、メモリ、モデム、センサインターフェース、およびプロセッサは結合され得、SOC上に一緒に集積され得る。加えて、無線および電源のうちの少なくとも一方は、SOC上に集積され得る。

さらなる実施形態は、ユーザの状態に関連付けられた複数のデータを通信デバイスの推論エンジンにおいて、受信するステップを含む方法を実施するシステムおよび装置を含むことができる。医療データ重要度は、複数のデータを組み合わせることによって決定され得、リソース割り当ては、決定された医療データ重要度に少なくとも部分的に基づいて決定され得る。複数のデータは、少なくとも2つの異なるタイプのデータを含むことができる。また、複数のデータは、環境データ、コンテキストデータ、生理学的および生物学的データ、医療記録データ、長期履歴健康データ、直接入力データ、個々の健康リスクデータ、個人ゲノムデータ、行動データ、および公衆警告のうちの少なくとも1つを含むことができる。

さらなる実施形態では、医療データ重要度を決定するステップは、医療データ重要度に対応する重要度インジケータを生成するステップを含むことができる。重要度インジケータを生成するステップは、患者に関連付けられた長期履歴健康データを、ユーザに取り付けられたセンサから得られた少なくとも1つの時間的特性と比較するステップを含むことができる。少なくとも1つの時間的特性において変化が検出されたとき、重要度インジケータは、既定の低い値から高い値に変更され得る。さらに、重要度インジケータは、通信デバイスのオンボードリソースまたはリモートリソースに提供され得る。リソース割り当ての決定は、とるべき少なくとも1つのアクションの指標を生成するステップを含むことができる。特定の期間の間に少なくとも1つのアクションを完了するために必要なリソースが決定され得る。したがって、医療モードにおけるリソース割り当ては、決定された必要なリソースに基づいて決定され得る。医療データ重要度に関連付けられた情報は、臨床決定支援システムおよび知識支援システムのうちの少なくとも1つと交換され得る。また、医療データ重要度を決定するステップまたはリソース割り当てを決定するステップのうちの少なくとも1つは、状態機械を使用して実行され得る。

さらなる実施形態では、他の回路に加えて、専用プロセッサ、メモリ、およびモデムは、SOCとして、または、医療モード機能を与えるために任意のデバイス内に実装され得る専用医療モードSOCとして実装され得る。そのような医療モードSOCはまた、本明細書に説明されているように、SOCがインストールされるデイバスのリソースを割り当てるステップを含む、状態が適切な医療モードにおいて動作する1つまたは複数の実施形態の方法を実行するようにそのプロセッサを構成するためのプロセッサ実行可能命令を含むことができる。そのようなSOCは、小型の再充電可能電池などの専用バックアップ電源を含むことさえできる。この実施形態は、単にデバイスの回路内にSOCを含めることによって、多種多様なデバイスが医療モード能力/機能を用いて構成されることを可能にする。この実施形態はまた、専用メモリ内にそのような情報を記憶することによって医療データの保護を可能にし、情報はプライバシー標準/要件および/または政府規制(たとえば、米国の医療保険の携行性と責任に関する法律(HIPAA:Health Insurance Portability and Accountability Act))の遵守を満たすために、SOCアーキテクチャによって暗号化され得、またはデバイス回路の残りの部分から分離され得る。通信デバイス内にそのような実施形態の専用医療モードSOCを実装することはまた、医療機器のために確立された政府の許認可要件を満たすために要求され得るような、安全性、信頼性、およびトレーサビリティの政府の基準を満たすまたはそれらに準拠するために必要であり得る、専用の処理、メモリ、通信、および他のリソースを提供する。集積されたSOC内に規制遵守に関する構成要素およびソフトウェアを実装することによって、この実施形態は、規制医療関連の機能(たとえば、医療関連センサおよび条件の監視および報告)を実行することができる通信デバイスの設計、製造、および許認可を簡略化することができる。

さらなる実施形態は、上記の方法に対応する様々な動作を実行するようにプロセッサ実行可能ソフトウェア命令を用いて構成されたプロセッサを有する通信デバイスを含むことができる。

さらなる実施形態は、上記の方法動作に対応する機能を実行するための様々な手段を有する通信デバイスを含むことができる。

さらなる実施形態は、通信デバイスのプロセッサに上記の方法動作に対応する様々な動作を実行させるように構成されたプロセッサ実行可能命令を記憶している非一時的プロセッサ可読記憶媒体を含むことができる。

本明細書に組み込まれ、本明細書の一部を構成する添付図面は、本発明の例示的な実施形態を例示し、上記の一般的な説明および以下の詳細な説明と共に、本発明の特徴を説明するのに役立つ。

様々な実施形態の機能を示す通信システムのブロック図である。 様々な実施形態と共に使用するのに適した通信デバイスの構成要素ブロック図である。 様々な実施形態と共に使用するのに適したサーバの構成要素ブロック図である。 様々な実施形態と共に使用するのに適した専用リソースを有するタブレットコンピュータの構成要素ブロック図である。 様々な実施形態と共に使用するのに適したシステムオンチップのアーキテクチャ図である。 様々な実施形態と共に使用するのに適した取り外し可能なシステムオンチップを含む通信デバイスの構成要素ブロック図である。 医療モードオーバライドを受信することに応答してリソースを割り当てるための代替的な実施形態の方法を示すプロセスフロー図である。 医療データ重要度が存在するかどうかを決定するための実施形態の方法を示すプロセスフロー図である。 様々な実施形態による様々なシナリオのための通信フロー図である。 データを区別するための実施形態の方法を示すプロセスフロー図である。

様々な実施形態が、添付図面の参照と共に詳細に説明される。可能な限り、同じ参照番号が、同じまたは同様の部分を指すために、図面全体を通して使用される。特定の例および実施態様になされる参照は例示目的のためであり、本発明の範囲または特許請求の範囲を限定するものではない。本開示の範囲から逸脱することなく、代替実施形態が考案され得る。加えて、本開示の周知の要素は、本開示の関連する詳細を不明瞭にしないように、詳細には説明されず、または省略される。

「通信デバイス」または「電子デバイス」という用語は、任意のまたはすべてのセルラー電話、スマートフォン、パーソナルもしくはモバイルマルチメディアプレーヤ、携帯情報端末、ラップトップコンピュータ、パーソナルコンピュータ、タブレットコンピュータ、スマートブック、パームトップコンピュータ、ワイヤレス電子メール受信機、マルチメディアインターネット対応セルラー電話、電化製品、医療デバイス、ワイヤレスセンサもしくはデータコントローラ(たとえば、グルコース計、血圧センサ、脈拍センサ、ペースメーカー、加速度計、天候/大気センサ、または、ユーザの状態および/もしくは健康を監視するためのセンサ)、ならびに、ワイヤレス通信経路を確立し、ワイヤレス通信経路を介して、そのいくつかの例が本明細書でさらに説明されるモバイル通信ネットワークとの間でデータを送信/受信するためのプログラマブルプロセッサ、メモリ、および回路を含む同様のパーソナル電子デバイスなどの、任意の電子デバイスを指すために、互換的に使用される。加えて、「通信デバイス」または「電子デバイス」という用語は、本明細書で使用されるとき、専用リソースとして、またはより一般的に、より大きいシステムの一部として動作するように構成された、特定の埋め込み回路(たとえば、SOC)またはより大きいシステムの構成要素などの、別個のサブシステムを指すことがある。

「医療モード」および「動作の医療モード」という用語は、通信デバイスが、1つまたは複数の入力を受信し、1つまたは複数の入力に基づいて適切なリソース割り当てを決定するように構成された動作の状態を指すために、互換的に使用される。1つまたは複数の入力は、通信デバイスが処理および通信しているデータの重要度の程度と、そのデータを処理および通信するために通信デバイスに利用可能なリソースを定量化する入力とを含むことができる。いくつかの実施形態では、通信デバイスは、医療データを処理および/または通信するために他のデータよりも優先的に1つまたは複数のリソースを割り当てることができる。通信デバイスは、いくつかの方法において、通常モードから医療モードに切り替えるかどうかを決定することができる。たとえば、通信デバイスは、手動制御(たとえば、ユーザインターフェースを介して手動で入力されたユーザ入力)に基づいて、医療モードに切り替えることを決定することができる。別の例として、通信デバイスは、工場設定によって、通常モードまたは医療モードのいずれかにハードワイヤードされる。さらに別の例として、通信デバイスは、1つまたは複数の自動入力(たとえば、環境から得られる状況情報)に基づいて、医療モードに切り替えることを決定することができる。さらなる例として、通信デバイスは、1つまたは複数のリソースから受信した少なくとも1つの信号(たとえば、手動でもしくはシグナリングを介して入力された、オンボードリソース、リモートリソース、または医療提供者からの入力信号)に基づいて、医療モードに切り替えることを決定することができる。医療モードでは、通信デバイスは、スライディングスケールに沿ってリソース割り当てを決定するために、リソース状態に対して医療データ重要度を比較検討することができる。スライディングスケールは、リソースが医療データの処理および/または通信専用である一方の端(すなわち、「高重要度モード」)から、リソースが医療データの処理および/または通信に優先的に専用ではない別の端(すなわち、「非重要モード」)までの条件を含むことができる。

「医療データ」という用語は本明細書では、非一時的プロセッサ可読記憶媒体内に記憶され得、それに対する動作がプロセッサによって実行され得る、量、特性、または記号によって表される医療および/または健康管理情報を指すために使用される。医療データは、健康、健康管理、ウェルネス、フィットネス、および医学に関連する情報、または、病気もしくは怪我の治療に関する情報を指し、具体的には、通信デバイスの特定のユーザに関連付けられた医療情報を指す。それはまた、ユーザの状態に関連し、かつユーザの医療ウェルネスに直接影響を与える可能性がある空気の質、温度、および湿度などの環境情報に関連し、たとえば、空気の質は喘息患者に影響を与え、空気の温度は慢性心臓病患者に影響を与える。医療データはまた、患者の現在の地理的位置または活動(たとえば、立っている、歩いている、または転倒している)についての情報を含む、患者の状況および位置についての情報を含む。医療データは、毎日の平均血圧値、平均心拍数、平均の毎日のエネルギー消費、および心拍変動など、測定されクラウドおよび/または通信デバイスに記憶された、ユーザの健康記録ならびにユーザの長期医療データを含むことができる。ユーザの健康に責任がある医療従事者および介護者からの直接指示および入力も、通信デバイスのユーザの医療データとして考えられる。通信デバイスを用いて管理される医療データによって表される患者の健康および/またはウェルネスに関する医師が注目する情報は、医療データと考えられ得る。また、医療データと考えられない、通信デバイスに関連して使用されるあらゆるデータは、本明細書では「他のデータ」と呼ばれる。さらに、「医療データを管理している」、「医療データを管理する」、および「医療データの管理」という表現は、本明細書では、送達、取得、ストリーミング、記憶、処理、および/またはデータ制御などを介する医療データの管理および調整を指すために使用される。

「医療データ重要度」という用語は本明細書では、その医療データの重要さのレベルを示す、通信デバイスによって管理される医療データ内の情報を指すために使用される。重要さのそのレベルは、医療データの要素に起因する値によって測定され得、この値は、本明細書では「重要度インジケータ」と呼ばれる。重要度インジケータは、直接重要度インジケータ(すなわち、すぐに明らかな)または間接重要度インジケータ(すなわち、中間計算または分析を必要とするもの)として医療データにおいて識別され得る。直接重要度インジケータまたは指標は、値の形態における関連する医療データの重要度を反映するように設計されたコード、フラグ、または他の形式の信号の形態であり得る。間接重要度インジケータまたは間接重要度の表示は、関連する医療データを測定するために使用される事前定義された値に相関させることができる医療データの1つまたは複数の可変要素を表すことができる。また、間接重要度インジケータは、値が決定され得る前に、他の情報と一緒に、比較、相関、または分析される必要もあり得る。たとえば、生理学的または生物学的医療情報は、医療データ内で示される間接重要度インジケータの値を決定する際に、時刻、時期、位置、活動、具体的な医療読み取り値、以前の健康履歴などの、他の情報と組み合わされ得る。重要度インジケータは、医療データ重要度が存在するかどうか、またはどれくらいのリソースが割り当てられるべきか、もしくは割り当てられ得るのかを決定する際に、リソース状態に与えられた重み付けと一緒に使用され得る測定医療データの重み付けを提供することができる。

「重要なリソースの制約」という用語は、通信デバイスによる医療データの処理または通信を損なう可能性があるまたは損なうおそれがあるリソース制約のレベルを指すために使用される。リソース制約は、少なくとも1つのアクションを実行することにより制限または制約される通信デバイスのリソースの状態を指す。リソースの状態はリソース状態によって測定され得、リソース状態は制約の程度を反映または定量化する1つまたは複数の制約値を含む。リソース状態は、重要なリソース制約が存在するかどうか、またはどれくらいのリソースが割り当てられるべきか、もしくは割り当てられ得るかを決定する際に、重要度インジケータに与えられた重み付けと一緒に使用され得る利用可能なリソースの重み付けを提供することができる。

本明細書で使用されるとき、通信デバイスに関連して、「リソース」または「デバイスリソース」という用語は、通信デバイスによって使用され得るハードウェア、ソフトウェア、および/または任意の他の資産を指すために互換的に使用される。リソースは、リモートリソースおよび/またはオンボードリソースを含むことができる。リモートリソースは、通信デバイスから物理的に離れたハードウェア、または、通信デバイスから物理的に離れたプロセッサによって実行もしくは部分的に実行されるソフトウェアを指す。オンボードリソースは、通信デバイスに物理的に結合されたハードウェア、または、通信デバイスのオンボードプロセッサもしくは構成要素上で実行または部分的に実行されるソフトウェアを指す。リソースは、リモートであろうとオンボードであろうと、通信デバイスに利用可能な、電源、プロセッサ、機能(たとえば、ソフトウェアプロセス)、メモリ、無線、通信ポート、特定のデータ容量を有するワイヤレスネットワーク、入力デバイス(たとえば、センサ、キーボード、ボタン、またはタッチスクリーン)、または出力デバイス(たとえば、ディスプレイもしくはスピーカ)のうちの少なくとも1つであり得る。たとえば、リソースは、プロセッサリソース、メモリリソース、電力リソース、ネットワークリソース、セキュリティリソース、およびプライバシーリソースを含む。プロセッサリソースおよびメモリリソースは、計算ハードウェアおよびソフトウェアを含むことができ、ネットワークリソースは、ワイヤレスネットワークおよび利用可能なネットワークリソースへの接続を含むことができ、電力リソースは、利用可能なバッテリ電力を含むことができ、セキュリティリソースは、暗号化/復号化機能と、高レベルオペレーティングシステムによってアクセスできないセキュア信頼ゾーンと、プライベートデータを記憶するためのセキュアメモリとを含むことができる。たとえば、ネットワーク接続が突然失われた場合、通信デバイスは、心電図(EKG)データを、リモートサーバに安全に送信するのではなく、ローカルデバイス内に一時的に記憶し始めることができる。その場合には、ネットワークリソースが不足しているとき、システムは、メモリリソースおよびセキュリティリソース、すなわち、EKGデータおよび任意の個人情報を記憶するための暗号化されたメモリ部分の割り当てを必要とすることになり、ここで、メモリのその部分は、たとえば、高レベルオペレーティングシステムによってアクセスすることができない。そのようなメモリは、医療データのために専用にすることができる。

様々な実施形態は、医療データの送信、処理、生成、および/または記憶のための通信デバイス内におけるリソースの利用可能性の保護、最適化を支援することができる。通信デバイスに関連付けられたリソースのおよび医療データからの指標はリソース割り当てを決定し、それに応答して、他のデータよりも高い優先度を医療データに与えるために使用され得る。医療データに優先度を与えることは、多目的通信デバイスが、患者にとって非常に重要である可能性がある医療関連機能を実行するために使用されることを可能にする。様々な実施形態のシステム、方法、およびデバイスは、他のデータよりも医療データを適切に優先させるように構成された通信デバイスの1つまたは複数のリソースを管理することを可能にする。

スマートフォンおよびタブレットなどの通信デバイスは、様々な機能を実行することができる高性能の計算および通信プラットフォームである。医療データを処理し、ルーティングするためのハブとして通信デバイスを使用することは、医療従事者、患者、および医療施設に特に有用であり得る。しかしながら、通信デバイスのための現代的なリソース割り当てアルゴリズムは、それらが実行する機能を、処理されるデータのタイプに基づいて区別しない。したがって、現在のリソース割り当てシステムを使用する通信デバイスは、重要な医療データを通信する診断機器と互換性がある。

たとえば、スマートフォンがセンサとして、または、医療データを送信するセンサのためのハブとして使用され、接続が制限されている場合、従来の通信デバイスは、電話着信を受信したとき、医療データまたは電話着信のいずれかの相対的重要性にかかわらず、そのようなデータの送信を中断することになる。しかしながら、医療データを通信することが、他のタイプのデータを送信または受信することよりも重要である状況が存在し得る。このように、現代的なリソース割り当てアルゴリズムは、非医療データよりも医療データの送信および処理を優先しないので、政府機関は一般的に、重要な医療データの送信および/または処理のためのスマートフォンアプリケーションの使用を規制する。

ワイヤレス無線を備え、患者装着型心電図(EKG)モニタに接続されたタブレットコンピュータの例を考える。そのタブレットコンピュータは、医療提供者またはリモート監視サービスにEKGデータを連続的にストリーミングするように構成され得る。EKG読み取り値に関係なく、リソース管理アルゴリズムのアクションによるその連続的なデータアルゴリズムにおける中断は、医療提供者への不必要な警告をトリガする可能性がある。また、完全な中断がなくても、ストリーミング医療データは、通信デバイスの他のデータとリソースを競合する可能性があり、このように制限された電力、制限された接続、または制限されたプロセッサ利用可能性を経験する可能性がある。これは、医療データの処理のためのリソースの利用可能性に対する重要なリソース制約の例を示す。

図1は、通信システム100を介して通信デバイス110に利用可能であり得るリソースを示す。通信デバイス110は、様々な実施形態に従って医療データおよび非医療データを管理するように構成され得る。医療データおよび/または非医療データを管理する際、通信デバイス110は、オンボードリソースを用いて医療データを処理/記憶することができ、または、ワイヤードもしくはワイヤレス接続を介して、ローカル周辺デバイスおよび/もしくはリモートネットワークリソースなどのリモートリソースにアクセスすることができる。図1は、通信デバイス110と関連するリモートリソースの様々な例を含む。

ローカル周辺デバイスは通信デバイス110に近接するリモートリソースであり得、ワイヤード接続または近距離ワイヤレス接続によって(たとえば、USB、FireWire、Bluetooth(登録商標)、ANT+(登録商標)、Zigbee(登録商標)などを介して)接続され得る。周辺デバイスは、一般的に、中間通信ネットワークを介さずに通信デバイスと直接通信する。また、周辺デバイスはワイヤード接続を介して通信デバイス110に結合され得るが、周辺機器は一般に通信デバイスから離されているので、周辺デバイスはオンボードリソースから区別される。

周辺デバイスは、心拍数モニタ122または手首装着型デバイス124のような、ユーザ10によって装着される構成要素を含むことができ、または、気象センサ126のような、通信デバイス110と直接通信する近くの構成要素を含むことができる。追加の周辺デバイスは、通信デバイス110のリソースとして利用可能であり得る。たとえば、周辺デバイスはさらに、血圧モニタと、脈拍計と、温度計(皮膚温度計など)と、心臓モニタと、グルコース計と、接続されたカメラと、医療関連データを収集する、通信する、記憶する、または処理することに関連付けられた事実上任意のデバイスとを含むことができる。加えて、周辺デバイスは、追加のまたは補助的なメモリ、プロセッサ、電力、通信、その他のソースを含むことができる。任意のリソースと同様に、周辺デバイスは、通信デバイス110が医療モードに切り替わる必要があるかどうかを決定するために使用され得る医療モードオーバライドまたは制約値を、維持することができ、および/または、接続された通信デバイスに送信することができる。加えて、周辺デバイスは、通信デバイス110のリソースとして、リソース割り当ての一部などの、通信デバイスからの制御または入力を受信することができる。

リモートネットワークリソースは、セルラー通信、または、インターネットへのアクセスを提供するローカルルータなどの接続の組合せなどの長距離無線接続を介して通信デバイス110に利用可能であり得る。セルラー接続は、通信デバイスが信号112を介して1つまたは複数の基地局130と通信することを可能にする。そのような基地局130は、今度はインターネット140に結合され得、任意の数のリモートネットワークリソースへのアクセスを通信デバイス110に提供する。代替的には、リモートネットワークリソースは、インターネット140へのアクセスを提供するワイヤード接続を介して利用可能であり得る。

リモートネットワークリソースはまた、医療データの更新、処理、記憶、および報告などの、様々なサービスを提供することができる1つまたは複数のサーバ150、152、154を含むことができる。そのようなネットワークリソースは、通信デバイス110によって処理される医療データへの安全なアクセスを可能にする適切なプロビジョニングを提供され得る。サーバ150、152、154は、通信デバイス110から送信される医療データまたはリソース割り当て指示を収集するように構成された、医師または施設によって維持されるサーバなどの、任意の数の利用可能なリモートネットワークリソースを表す。

代替的には、リモートネットワークリソースは、気象サービス、薬局、または医療情報の他のソースなどの、通信デバイス110にデータを供給するデータプロバイダを含むことができる。インターネット140を介するアクセスを用いて、1つの一次サーバ150は、他のサーバ152、154と直接通信することができ、通信デバイス110への排他的な接続を有することができる。

代替的には、様々なリモートネットワークリソースは、冗長性を提供するために通信デバイス110への代替の接続経路を有することができる。任意のリソースと同様に、リモートネットワークリソースは、通信デバイス110が医療モードに切り替わる必要があるかどうかを決定するために使用され得る医療モードオーバライドまたは制約値を、を維持することができ、および/または、接続された通信デバイスに送信することができる。

サーバ150、152、154はメモリとプロセッサとを含むことができ、通信デバイス110から受信したデータを記憶またはバッファリングするためのそれ自体のデータベースを維持することができる。サーバ150、152、154はまた、通信デバイス110が医療モードにされるべきかどうか、または、任意の他の緊急のアクションもしくはアラームが患者もしくは医療提供者に通信されるべきかどうかを決定するために、データを閾値(すなわち、アラーム)設定と比較するなどの受信した医療データに対するいくつかの分析を実行することができる。サーバ150、152、154はまた、プロビジョニングおよびデバイス管理ソフトウェア、データプラン契約管理ソフトウェア、セルラーオペレータ接続インターフェース機能、セルラー課金機能、ならびに顧客サポートサービスを用いて構成され得る。多くの他のリソースとは異なり、各サーバは、それ自体のメモリ、プロセッサ、または、それが通信デバイスのための機能を実行するために使用する通信手段などの様々なサブリソースを含むことができる。したがって、各サーバは、その全体的な状態、またはそれらのサブリソースのいずれかの状態に関する制約値を、維持することができ、および/または、接続された通信デバイスに送信することができる。同様に、各サーバは、通信デバイスを医療モードにするための医療モードオーバライドを送信することができる。

一実施形態では、通信デバイス110は、従来の通信デバイスとしてだけでなく、機械対機械(M2M)健康管理デバイスのための医療データゲートウェイまたはハブとしても機能することができる。一実施形態では、システム100は、政府の規則および規制に準拠するために必要なものなどの必要なプロトコルを使用して、許可された健康管理プロバイダ、支払者、および患者と、電子医療データが安全かつ確実に交換されることを可能にするデータセンタおよびクラウドサービスを含むリモートネットワークリソースにエンドツーエンド暗号化プロセスが影響力を行使するように構成され得る。たとえば、心拍数モニタ122または手首装着型デバイス124からの医療データは、通信デバイス110を介して、サーバ150、152、154などの1つまたは複数のリモートネットワークリソースに伝達され得る。

一実施形態では、通信デバイスが医療モードにあるとき、オンボードまたはリモートプロセッサ(すなわち、ターゲットリソース)は、医療データをスケジュールされた時間に指定先サーバにアップロードする前に、永続的ストレージに一時的に保存するように構成され得る。オンボードまたはリモートプロセッサ上に存在するデータ記憶モジュール(DSM)は、この記憶されたデータを体系的な方法で編成することができ、それをファイルシステム内に永続的に記憶することができ、記憶された医療データを管理するために適切なファイルハウスキーピング動作を実行することができる。DSMによって実行されるタスクは、医療データを記憶することと、データ転送をトリガすることと、ファイルサイズを監視することと(DSMは、ファイルシステムへの医療データの書き込み中にデバイスファイルサイズをチェックし必要に応じてファイルを移動することによってデバイスのファイルサイズが予め設定された制限を超えた場合、転送を自動的にトリガすることができる)、ファイルの経過期間をチェックすること(たとえば、構成マネージャによって提供される適切なパラメータを使用して、DSMは長時間データを送信していないデバイスのファイルシステムを(タイマーを使用して)監視することができ、「古くなった」データファイルを検出し、迅速にアップロードすることができる)、ファイルシステムの整合性を維持すること(たとえば、DSMは、永続的なリストにファイル名を書き込み、このリストをモニタし、再起動後にファイルシステムに対してリストをチェックし、不一致をアップロードすることによって、すべての作成されたファイルの整合性を追跡し続けることができる)とを含むことができる。

図2は、恒久的外側ハウジング201内に含まれるか、恒久的外側ハウジング201に直接取り付けられた通信デバイス200および様々なオンボードリソースを示す。たとえば、通信デバイス200は、内部メモリ220および222に結合されたプロセッサ210、ならびに医療データのための専用プロセッサおよび追加の専用構成要素270などの追加プロセッサを含むことができる。内部メモリ220および222は、揮発性メモリまたは不揮発性メモリであり得、またセキュアメモリもしくは暗号化メモリ、または非セキュアメモリもしくは非暗号化メモリ、またはそれらの任意の組合せであり得る。

プロセッサ210はまた、ユーザインターフェース、無線、または通信ポートなどの、様々な入力および/または出力構成要素に結合され得る。タッチスクリーンディスプレイ230(たとえば、抵抗感知タッチスクリーン、静電容量感知タッチスクリーン、赤外線感知タッチスクリーンなど)、スピーカ232、マイクロフォン234、カメラ236、または物理的ボタン238および239などのユーザインターフェース。そのようなタッチスクリーンディスプレイ230は、スクリーン表示を出力するために使用され得、または、ユーザ入力を受信するために使用され得る。しかしながら、通信デバイス200のディスプレイは、タッチスクリーン機能を有する必要はない。

通信デバイス200の無線は、プロセッサ210に結合されたワイヤレスデータリンクおよび/またはセルラー電話トランシーバ242に接続され得る、電磁放射を送信および受信するための1つまたは複数のアンテナ240を含むことができる。周辺デバイスまたはワイヤード通信リンクにデータケーブルを接続し、これらと通信するための、Micro-Bポート250などの1つまたは複数の通信ポートが設けられ得る。通信ポートの数は、恒久的外側ハウジング201の物理的設計と、通信デバイス200が構成される特定の市場または用途とに応じて、様々な実施形態の間で異なってもよい。

加えて、通信デバイスは、他のオンボードリソースのための電源としてバッテリ260を含むことができる。代替的には、電源コードを使用して、通信デバイス200は、外部電源にプラグインされ得、外部電源はまた、バッテリ260を充電するために使用され得る。

専用構成要素270内のプロセッサは、医療データを管理するために排他的に使用される、医療モードプロセッサ、医療モードSOC、または医療モードコアプロセッサであり得る。このように、特定のおよび/または恒久的な構成要素は、医療データと、医療関連処理(たとえば、医療センサからのデータを処理する、医学的状態を決定する、医療データを報告する)を実行することとに専用とされ得る。また、そのような専用構成要素270は、他の構成要素から「密封」され得、これは医療データを他のデータから隔離する、恒久的な制約が設けられることを意味する。そのような専用構成要素270は、セキュリティ、プライバシーを提供し、規制遵守問題および要件を満たす医療グレード構成要素であり得る。

任意のリソースと同様に、リソースを割り当てるために通信デバイスが医療モードにあるときを決定するために使用され得る各オンボードリソースのための制約値が決定され、維持され得る。このように、制約値は、制約値が所定の有意性の値に達したとき、オンボードリソースが負担をかけられた、衝突を有する、または利用不可能であるときを反映することができる。

一実施形態では、通信デバイスは、分析および応答モジュール(ARM)を含むことができる。ARMは、通信デバイスによって受信された他のデータから医療データを区別するためおよび/またはそれに応じてリソースを割り当てるために、アルゴリズムおよび他の分析を適用することができる。ARMは、通信デバイスの位置、通信デバイスに接続された1つまたは複数のリソースからの入力、および/または他の考慮事項などの様々な要因に基づいて、どのアルゴリズムおよび他の分析を受信したデータに適用するのかに対するコンテキスト依存決定を行うことができる。ARMはまた、他の通信デバイスモジュールと通信することができる。

図3は、上記で説明した様々な実施形態においてリモートリソースとして使用され得るサーバ300を示す。そのようなサーバ300は、典型的には、揮発性メモリ302と、ディスクドライブ303などの大容量不揮発性メモリとに結合されたプロセッサ301を含む。サーバ300はまた、プロセッサ301に結合されたフロッピー（登録商標）ディスクドライブおよび/またはコンパクトディスク(CD)などの、1つまたは複数のリムーバブルディスクドライブ304を含むことができる。サーバ300は加えて、インターネットなどのネットワーク回路とのデータ接続を確立するための、プロセッサ301に結合されたネットワークアクセス接続307を含むことができる。

図4は、様々な実施形態においておよび/または様々な実施形態と共に実施され得るタブレットコンピュータ400の形態の別の通信デバイスを示す。たとえば、ワイヤレスデバイス400は、内部メモリ420および422に結合されたプロセッサ410を含み得る。内部メモリ420および422は、揮発性メモリまたは不揮発性メモリであってもよく、またセキュアメモリおよび/もしくは暗号化メモリ、または非セキュアメモリおよび/もしくは非暗号化メモリ、またはそれらの任意の組合せであってもよい。

プロセッサ410はまた、ユーザインターフェース、無線、および通信ポートなどの、様々な入力および/または出力構成要素に結合され得る。タッチスクリーンディスプレイ430(たとえば、抵抗感知タッチスクリーン、静電容量感知タッチスクリーン、赤外線感知タッチスクリーンなど)、スピーカ432、マイクロフォン434、カメラ436、または1つもしくは複数の物理的ボタン438などのユーザインターフェース。そのようなタッチスクリーンディスプレイ430は、スクリーン表示を出力するために使用され得、または、ユーザ入力を受信するために使用され得る。しかしながら、タブレットコンピュータ400のディスプレイは、タッチスクリーン機能を有する必要はない。

通信デバイス400の無線は、プロセッサ410に結合されたワイヤレスデータリンクおよび/またはセルラー電話トランシーバに接続され得る、電磁放射を送信および受信するための1つまたは複数のアンテナ440を含むことができる。周辺デバイスまたはワイヤード通信リンクにデータケーブルを接続し、これらと通信するための、1つまたは複数の通信ポートが設けられ得る。通信ポートの数は、恒久的外側ハウジング401の物理的設計と、タブレットコンピュータ400が構成される特定の市場または用途とに応じて、様々な実施形態の間で異なってもよい。

加えて、タブレットコンピュータ400は、他のリソースのための電源(ソース)としてバッテリ460を含むことができる。代替的には、電源コードを使用して、タブレットコンピュータ400は外部電源にプラグインされ得、外部電源はまた、バッテリ460を充電するために使用され得る。これらの要素のいずれかは、オンボードリソースとみなされる。

さらに、タブレットコンピュータ400は、オンボードプロセッサ470、オンボードメモリ472、および補足のオンボードバッテリ474の形態のバックアップ電源を含む、様々な専用リソースを追加で含む。そのような専用リソースは、医療データを管理することによって、および医療データを管理するために排他的に使用され得る。専用リソースはまた、タブレットコンピュータ400が医療モードにあるときに使用するために予約され得る。各専用リソースは、使用するために個別に選択され得、または、2つ以上が適宜に使用され得る。これらの専用リソースは、医療モード外の他のデータのために使用されることが制限されない、上述のオープンリソース(すなわち、非専用リソース)から隔離され得る。加えて、専用リソースは互いに安全にリンクされ得、おそらく、オープンリソースと選択的にデータを交換する。専用リソースは、ソフトウェアの更新、ウイルス、またはオープンリソースに対する様々な変更によって影響されなくてよい、通信デバイスの医療サブシステムとして機能することができる。このように、オープンソースはまた、専用サブシステムの動作に干渉しない。そのようなサブシステムは、政府の規則および規制を用いて構成され得、政府の規則および規制に準拠し得る。加えて、医療データのプライバシー、データ保持、およびセキュリティを保証するために、医療データは、ユーザ、リソース、および任意の識別された状態または指標に固有の識別情報でタグ付けされ得る。

本明細書における実施形態による優先割り当てから起こる制約から離れて、オープンリソースは望ましい場合、医療データおよび他のデータによって自由に使用され得る。このように、第1のプロセッサ、第1のメモリ、第1の無線および第1の電源はオープンリソースであり得、第2のプロセッサ、第2のメモリ、第2の無線および第2の電源は通信デバイスの専用リソースであり得る。さらに、専用メモリは、暗号化メモリであり得る。第2のプロセッサ、メモリ、および第2の電源は別個であり得、デバイス上で動作する高レベルオペレーティングシステムによってアクセスできなくてよい。代替的には、通信デバイスは、すべてのこれらの示された専用リソースを有する必要はなく、または、追加の専用リソースを有することができる。

医療機器に課せられた規則または規制に準拠するために、様々な実施形態のオンボードリソースおよび/またはリモートリソースは、「医療グレード」リソースであり得る。医療グレードリソースは、保健局および/または規制当局による医療機器のために必要とされる基準を満たすことができ、またはそれらの基準の下で開発される。たとえば、U.S. Food and Drug AdministrationおよびEuropean Commission Directorate General for Health and Consumersなどの政府当局/機関は、医療グレードリソースとして資格を与えることができる最低基準を課すことができる。そのような基準は、典型的には、具体的には生命を危うくする状況における医療用途の緊急性により、商用グレード機器よりも安全性および信頼性についてより高い要件を課す。加えて、そのような当局/機関は、患者および医療データの記憶および通信について医療グレード機器に固有の要件を課す、セキュリティおよび/またはプライバシー規則、規制、および/または基準(すなわち、HIPAA)を公布する可能性がある。医療グレードリソース構成要素を提供することによって、様々な実施形態は、高優先度医療データならびに通常の使用と一致する非医療データを処理するのに適格とされる多目的通信デバイスが販売されることを可能にする。したがって、様々な実施形態において、1つまたは複数の専用リソースは、医療モードリソースとして機能するように構成された医療グレードリソースであり得る。たとえば、医療モードプロセッサまたは医療モードSOCは、医療デバイスのための基準に準拠した医療グレードデバイスであり得る。

図5は、様々な実施形態の医療モード機能を有するそのようなデバイスを提供するために様々なコンピューティングデバイス内に実装され得る医療モードSOC内で使用され得る、例示的なシステムオンチップ(SOC)500のアーキテクチャを示すアーキテクチャ図である。SOC500は、デジタル信号プロセッサ(DSP)502、モデムプロセッサ504、グラフィックスプロセッサ506、および医療モードアプリケーション処理を処理するために構成されたアプリケーションのプロセッサ508などのいくつかの異種のプロセッサを含むことができる。SOC500は、1つまたは複数の異種のプロセッサ502、504、506、508と共に動作する医療モード暗号化モジュール510を含むことができる。医療モード暗号化モジュール510は、患者の情報および医療データを保護するための規制要件に準拠する暗号化技術を実装するように構成された暗号化モジュールであり得る。SOC500はまた、1つまたは複数の異種のプロセッサ502、504、506、508に接続された1つまたは複数のコプロセッサ(たとえば、ベクトルコプロセッサ)を含むことができる。各プロセッサ502、504、506、508は1つまたは複数のコアを含むことができ、各プロセッサ/コアは、他のプロセッサ/コアから独立して動作を実行することができる。たとえば、SOC 500は、第1のタイプのオペレーティングシステム(たとえば、FreeBSD、LINUX（登録商標）、OS Xなど)を実行するプロセッサ、および第2のタイプのオペレーティングシステム(たとえば、Microsoft Windows（登録商標） 8)を実行するプロセッサを含み得る。

SOC500はまた、患者の情報、センサデータ、センサ履歴データ、医学的状態、医師の指図、機能の選択などの医療データを記憶するための専用メモリ512を含むことができる。医療データは、収集/公開に対するプライバシーおよび政府の規制のより高い基準(たとえば、HIPAA)の対象となるので、メモリ512は、SOCがSOCアーキテクチャによってインストールされたデバイスの残りから隔離され得る。たとえば、専用メモリ512は、一般的に非医療アプリケーションにアクセス可能ではないメモリパーティション内に医療データを記憶することができる。また医療データは、専用メモリ512上に暗号化された形式において記憶され得、また、暗号化された形式においてデバイス内の異なるチップ間で通信され得る。

SOC500はまた、医療センサデータの管理、アナログ-デジタル変換、ワイヤレスデータ送信、ならびにゲームおよび動画のための符号化された音声信号の処理などの他の特殊な動作の実行のための、アナログ回路およびカスタム回路514を含むことができる。SOC500はさらに、電圧レギュレータ、発振器、位相ロックループ、周辺ブリッジ、データコントローラ、メモリコントローラ、システムコントローラ、アクセスポート、タイマー、ならびにSOC500が医療モード動作専用になることを可能にするSOC上のプロセッサおよび他の回路をサポートするために使用される他の同様の構成要素などの、システム構成要素およびリソース516を含むことができる。

システム構成要素516およびカスタム回路514は、カメラ、電子ディスプレイ、ワイヤレス医療センサ、ワイヤレス対応医療デバイス、外部トランシーバなどの周辺デバイスとインターフェースする回路を含むことができる。プロセッサ502、504、506、508は、1つまたは複数のメモリ要素512、システム構成要素、ならびにリソース516およびカスタム回路514と、相互接続/バスモジュール524を介して相互接続され得、相互接続/バスモジュール524は、再構成可能な論理ゲートのアレイを含むことができ、および/またはバスアーキテクチャ(たとえば、CoreConnect、AMBAなど)を実装することができる。通信は、高性能ネットワークオンチップ(NoCs)などの高度な相互接続によって提供され得る。

SOC500はさらに、クロック518および電圧レギュレータ520などのSOCの外部のリソースと通信するための入力/出力インターフェース回路を含むことができる。SOCの外部のリソース(たとえば、クロック518、電圧レギュレータ520)は、内部のSOCプロセッサ/コア(たとえば、DSP 502、モデムプロセッサ504、グラフィックスプロセッサ506、アプリケーションプロセッサ508など)のうちの2つ以上によって共有され得る。

SOC500はまた、医療センサ、ユーザインターフェース要素(たとえば、入力ボタン、タッチスクリーンディスプレイなど)、マイクロフォンアレイ、物理的状態を監視するためのセンサ(たとえば、位置、方向、動き、方位、振動、圧力など)、カメラ、コンパス、GPS受信機、通信回路(たとえば、Bluetooth(登録商標)、WLAN、WiFiなど)、および、現在の電子デバイスの他の周知の構成要素(たとえば、加速度計など)からセンサデータを収集するのに適したハードウェアおよび/またはソフトウェア構成要素を含むことができる。加えて、SOC500は、医療データを処理するための専用の「医療グレードSOC」であり得る。SOC500はまた、本明細書で説明したようにSOC500がインストールされたデバイスのリソースを割り当てることを含む、状態が適切な医療モードにおいて動作する1つまたは複数の実施形態の方法を実行するようにその医療モードプロセッサ508を構成するためのプロセッサ実行可能命令をメモリ512内に記憶することができる。SOC500は、小型の再充電可能電池(図示せず)などの、専用バックアップ電源を含むことができる。SOC500それ自体、ならびにその個々のハードウェア構成要素および/またはソフトウェア構成要素は、たとえば、暗号化機能および/またはプライバシー保護機能を提供するセキュリティリソースとみなされ得、または、通信デバイスの必須リソースとさえみなされ得る。したがって、SOC500またはその個々の構成要素のリソース状態は、医療モードにあるときなど、リソース割り当てを決定するときに考慮され得る。

医療モードSOC500は、多種多様なデバイスが、デバイスの回路内にSOCを単に含めることによって、医療モード能力/機能を用いて構成されることを可能にする。通信デバイス内にそのような実施形態の専用医療モードSOC500を実装することはまた、政府の許認可、または医療機器のために確立された他の要件を満たすために要求され得るような、安全性、信頼性、およびトレーサビリティの基準を満たす、またはそれらの基準に準拠するために必要であり得る、専用の処理、メモリ、通信、および他のリソースを提供する。組み込まれたSOC内に規制準拠関連の構成要素およびソフトウェアを実装することによって、この実施形態は、規制医療関連機能(たとえば、医療関連センサおよび状態の監視および報告)を実行することができる通信デバイスの設計、製造、および許認可を簡略化することができる。医療モードSOC500は、それがインストールされたデバイスが動作の医療モードにあるとき、具体的に動作する専用ハードウェアであり得る。また、動作の医療モードにあるとき、医療モードSOC500は独立型システムとして動作することができ、それがインストールされたデバイスの他のハードウェア/ソフトウェアと共に動作することができ、そのような他のハードウェア/ソフトウェアの制御を引き継ぐことができる。

図6は、取り外し可能な医療モードSOC601を含む通信デバイス600の構成要素ブロック図である。取り外し可能な医療モードSOC601は、様々なコンピューティングデバイスに様々な実施形態の医療モード機能を提供するために、そのようなデバイス内に実装され得る。上記で説明した図5の医療モードSOC500と同様に、取り外し可能な医療モードSOC601は、プロセッサ、メモリ、および/または電源などの、それ自体のハードウェア構成要素および/またはソフトウェア構成要素を含むことができる。そのようなハードウェア構成要素および/またはソフトウェア構成要素は、プロセッサ652、ユーザインターフェースコントローラ654、および内部メモリ656を含むことができる、通信デバイス600の他のハードウェア構成要素またはソフトウェア構成要素と同様および/または重複であり得る。通信デバイス600は、取り外し可能な医療モードSOC601のチップ接続インターフェース622に結合するためのデバイス接続インターフェース662を含むことができる。接続インターフェース622、662は、1つのタイプの接続を受け入れるように単独で構成され得、または共通のもしくは独自の様々なタイプの物理的接続および通信接続を受け入れるように構成され得る。取り外し可能な医療モードSOC601は、通信デバイス600の恒久的外側ハウジング655内にインストールされた構成要素として図6に示されている。代替的には、デバイス接続インターフェース662は、USB、FireWire、Thunderbolt、またはPCIe接続などを介して、外部/周辺デバイスとして、取り外し可能な医療モードSOC601を受け入れるための外部接続ポートであり得る。取り外し可能な医療モードSOC601は、CPUの専用コアであり得る。

図7は、他のデータに加えて、医療データを処理および通信するように構成され得る通信デバイスのリソースを管理する実施形態の方法700を示す。通信デバイスが医療モードにおいて動作するかどうかを最初に決定することを可能にすることは、デバイスがデフォルトで医療モードにおいて動作するシナリオと比較して、任意のリソースの消費を排除することができる、最小限にすることができる、および/または回避することができる。

ブロック702では、通信デバイス上に設けられ得る医療モードスイッチから信号が受信され得る。医療モードスイッチは、通信デバイスの構成要素であり得、または通信デバイスに医療モードオーバライドを通信することができるリモートリソースの部分であり得る。通信デバイスのプロセッサは、このように通信デバイスが医療モードにおいて動作すべきかまたはすべきではないのかを示す、医療モードスイッチからの信号の形態などにおける医療モードオーバライドを受信することができる。通信デバイスを動作の医療モードに導く医療モードオーバライドは、「オン信号」であり得る。対照的に、通信デバイスを動作の医療モードにおいて動作しないように導く(すなわち、通信デバイスを通常モード760において動作するように導く)医療モードオーバライドは、「オフ信号」であり得る。いくつかの実施形態では、通信デバイスが専用医療通信デバイスである場合、通信デバイスを動作の医療モードに導く医療モードオーバライドは、常時「オン信号」であり得る(たとえば、プリセットまたはハードワイヤードされ得る)。代替的には、通信デバイスが専用医療通信デバイスである場合、ブロック702および704は図7から省略され得、デバイスは医療モードにおいてのみ動作することができる。そのようなデバイスは、医療モード監視の必要性が常にある医師または患者と共に有用性を見出すであろう。対照的に、医療モードオーバライドが常に「オフ信号」(たとえば、工場設定)である場合、通信デバイスは、単に通常モード760において動作するデバイスになる。たとえばそのようなデバイスは、単に医療データを優先的に扱わない任意の現代的な通信デバイスとして動作することができる。

いくつかの実施形態では、通信デバイス自体の構成要素として、医療モードスイッチは、通信デバイスのユーザインターフェース(たとえば、オン/オフボタンまたはタッチスクリーンアイコン)を介してアクセス可能な手動制御を含むことができる。そのような手動制御は、ユーザ、健康管理提供者、または他の許可された個人が、そのユーザインターフェースを介して通信デバイスとインターフェースすることによって、医療モードを手動で「オン」または「オフ」することを可能にする。手動制御は、通信デバイス自体のユーザ設定に組み込まれ得る。加えて、手動制御は、他のリソースが医療モードスイッチとして機能することを阻止するまたは可能にするなどの、高度なオプションを含むことができる。

手動制御に加えて、様々な他のリソースが、オン信号、オフ信号、有効/無効手動制御、または有効/無効自動化制御を提供する、医療モードスイッチとして機能することができる。当業者は、リソースが、図8に関して医療データ重要度を決定するための情報を提供する下記で説明するものなどの、オンボードリソースおよび/またはリモートリソースを含むことが可能であることを理解するであろう。したがって、リソースは、外部/内部刺激(たとえば、コマンド、スイッチ、コネクタ)、ソフトウェア、ネットワーク/構成要素接続、データソース(たとえば、センサベース)、周期的または少なくとも1つの時間的特定(たとえば、時間、周波数など)、位置ベース(たとえば、GPS、高度、高度計、花粉/汚染レベルを使用する)、健康管理決定/指令、ユーザ活動(たとえば、寝ている、起きている、活動している、ストレスを受けている)などを含む、医療モード切り替え信号を生成または伝達することができる。加えて、推論エンジンは、医療モード切り替え信号を生成するための様々な入力を考慮することができる。

いくつかの実施形態では、医療モードスイッチは、たとえば、環境データ、コンテキストデータ、ユーザ設定、および/またはそれらの任意の組合せなどの様々なリソースからの入力に基づいて、医療モードまたは通常モードに自動的に切り替える制御であり得る。いくつかの場合には、通信デバイスのオンボードリソースは、医療モードに入るように通信デバイスのプロセッサにシグナリングすることができる。たとえば、通信デバイスのユーザ設定は、非常に低下しているオンボードバッテリなどの重大なリソース制約に応答して、医療モードオーバライドをトリガすることができる。さらなる例として、医療グレードSOCはアクティブ化されたとき、または通信デバイス内にインストールされていることに応答して、医療モードオーバライドを自動的にシグナリングするように構成され得る。同様に、リモートリソースは、通信デバイスにおいて医療モードを遠隔的にオンまたはオフにするための医療モードスイッチを含むことができる。たとえば、認可された医療提供者は、テスト結果を受信した後、医療モードをアクティブ化する信号を送信することができる。さらなる例として、特定のユーザに危険な状態を検出する大気圧センサは、通信デバイスのオンボードプロセッサによって認識される信号を送信することによって、医療モードを遠隔的にアクティブにすることができる。

他の実施形態では、医療モードスイッチは、通信デバイスの内部および/または外部の1つまたは複数のリソースからのシグナリング(たとえば、データストリームに埋め込まれたシグナリング)に基づいて、医療モードまたは通常モードに切り替える制御であり得る。シグナリングは、たとえば、環境データ、コンテキストデータ、生理学的および生物学的データ、健康記録データ、長期履歴データ、直接入力データ、個々の健康リスクデータ、人口データ、個人のゲノムデータ、行動データ、公衆警告、および/またはそれらの任意の組合せのうちの少なくとも1つを含むことができる。2つ以上のソースが医療モード切り替え信号を送信/提供することができる実施形態では、衝突するおよび/または重複するシグナリングに対処するための階層が設けられ得る。たとえば、ユーザの手動医療モードオーバライドは、すべての他のリソースに対する医療モード決定を制御することができる。さらなる例として、プロセッサは、ユーザが花粉アレルギーのためのアレルギー薬を服用していることを知っている医師からの指示を受信することに応答して、通信デバイスを医療モードにする高花粉数に関連付けられた入力を取り消すことができる。

決定ブロック704において、プロセッサは、通信デバイスを動作の医療モードに導く医療モードオーバライドが受信されたかどうかを決定することができる。医療モードオーバライドオフ信号が受信された(すなわち、決定ブロック704=「Off」)ことに応答して、ブロック760において、プロセッサは、通信デバイスを通常モードに維持する/切り替えることができる。通常モードにおいて、通信デバイスのプロセッサは、医療データに優先処理を適用しなくてもよく、またはリソース割り当てを選択しなくてもよい。医療モードオーバライドオン信号が受信されたことを決定する(すなわち、決定ブロック704=「On」)ことに応答して、ブロック730において、プロセッサは、通信デバイスによって管理される医療データに関連付けられた医療データ回路に対して、通信デバイスによって使用される複数のリソースに関連付けられたリソース状態を比較検討することができる。

ブロック710において、通信デバイスは、通信デバイスによって使用される複数のリソースのうちの少なくとも1つの状態(すなわち、リソース状態)を決定することができる。この決定は、プロセッサ、メモリ、ネットワーク、電源、および/またはセキュリティなどの、現在使用中および利用可能なリソースを含むことができる。リソース状態を決定するために、通信デバイスのプロセッサは、状態情報を能動的に取得する(すなわち、プロセッサによって開始される要求に応答してリソース状態を受信する)ことができ、または、受動的に取得する(たとえば、各リソースもしくは中間ソースからプッシュ通知を受信する)ことができる。個々のリソースのリソース状態は、どれくらい多くのリソースが利用可能であるか(量もしくは率)、またはどれくらい制約されたリソースが最低レベルもしくは正常レベルの制約に関係するのかのいずれかを表す制約値を含むことができる。たとえば、利用可能なメモリ、バッテリ充電、無線接続、またはプロセッサ負荷の割合は、各々、それらに関連するリソースの制約値とみなされ得る。また、リソース状態は、リソースが利用可能かどうか、またはリソースの状況(たとえば、使用するためのその準備)を示すことができる。したがって、ブロック710において決定されるリソース状態は、リソースが利用可能であり続けるもしくは利用可能であり続けることになるかどうか、どれくらい長くリソースがそうなるか、どれくらい多くのリソースがそうなるか、どのようなレベルでリソースがそうなるか、および/またはどのような率でリソースがそうなるか、を示すことができる。複数のリソースの状態が受信される場合、個々の状態は、その複数のリソースの各々のために受信され得る。

一実施形態では、重要なリソースの制約は、そのリソースの第1の制約閾値に違反する制約値を示す単一のリソース状態から識別され得る。第1の制約閾値は、それが適用されるリソースに特定の個別的制限であり得る。加えて、重要なリソースの制約は、リソース状態の組合せが、リソース状態の組合せに関連付けられたそれぞれのリソース状態の個々の第2の制約閾値に違反する制約値を示すとき、識別され得る。第2の制約閾値は、リソースの組合せのリソースごとに異なってよい。また、第2の制約閾値の各々は、同じリソースの第1の制約閾値と異なってもよい。第1の制約閾値と第2の制約閾値との間の違いは、医療データを処理する通信デバイスの能力を損なう可能性がある重要なリソースの制約の相反する組合せのため、存在し得る。このように、それらのそれぞれの第1の制約閾値を個別に満たさない可能性がある2つ以上のリソースは、それらの制約値がそれらのより容易に違反される第2の制約閾値に両方とも違反するので、重要なリソースの制約を示すために一緒に識別可能であり得る。

各第1の制約閾値は、リソースに関連付けられた状況を反映するように選択された所定の重要性の数値であり得、それに応答して、その特定のリソースの状態に基づいて他のデータを上回る優先度が医療データに与えられ得る。たとえば、通信デバイスのバッテリの第1の制約閾値は、25パーセント(25%)の利用可能な電力であり得る。25パーセント(25%)以下であると測定されたそのバッテリの電力の任意のレベルは、単独で重要なリソースの制約を反映することができる。そのような制約閾値は、医療データが排他的に通信または処理される、または追加もしくは代替の電力を探すなどの救済アクションをとるのに十分長く続くと予測される、特定の期間必要な電力の蓄えのレベルに関連するので、選択され得る。

同様に、10パーセント(10%)の利用可能なオンボードメモリ容量は、概略でその容量が医療データを記憶または処理するための排他的な蓄えとして必要とされるので、オンボードメモリのための第1の制約閾値として指定され得る。したがって、23パーセント(23%)を示すそのメモリの利用可能な記憶容量の測定は、第1の制約閾値にまだ達していないそのメモリに対応する。

さらなる例として、プロセッサまたはソフトウェアアプリケーション(オンボードまたはリモート)の計算能力は、その値が違反されたとき、重要なリソースの制約が存在するように、それに関連付けられた第1の制約閾値を有することができる(たとえば、中央処理ユニットが、100%の能力で1分よりも長く動く)。

同様の制約閾値は、医療データを処理するために必要な無線または計算要件閾値を使用して、接続レベルのために決定され得る。このように、リソースは、衝突を有する、医療データを完全に処理するにはあまりに抑制されている、不足している、または何か制限を受けていることによって重要なリソースの制約が存在することを個別に示すことができる。

加えて、リソースは、「必須リソース」とみなされ得、これは、通信デバイスの特定の機能および/または通信デバイス自体を動作するために必須だとみなされ得るまたは必要とみなされ得るリソースを指す。そのような必須リソースは、他のリソースよりも容易に違反される制約閾値を有し得る。たとえば、バッテリは、代替の電源なしで通信デバイスにおける機能を実行するために、通信デバイスのための必須リソースとみなされ得る。同様に、機密の医療データを処理するためのセキュリティ/プライバシー要件を満たすために、暗号化モジュールまたは安全な通信接続の利用可能性は、必須リソースとみなされ得る。したがって、そのような必須リソースのセキュリティレベルはさらに、重要なリソースの制約が存在するかどうかを決定する際に考慮され得る。

各第2の制約閾値は、リソースの特定の組合せに関連付けられた状況を反映するように選択された所定の重要性の数値であり得、それに応答して、その特定のリソースの組合せの状態に基づいて他のデータを上回る優先度が医療データに与えられるべきである。たとえば、通信デバイスのバッテリのための第2の制約閾値は、30秒間の90パーセント(90%)よりも上の能力で動作するプロセッサのための第2の制約閾値との組合せにおける30パーセント(30%)の利用可能な電力であり得る。組合せの両方の第2の制約閾値が違反された場合、重要なリソースの制約は存在するように示され得る。その同じバッテリのための第1の制約閾値は25パーセント(25%)であり得、その同じプロセッサのための第1の制約閾値は、1分間の100パーセント(100%)の能力であり得る。したがって、そのバッテリおよびプロセッサのための第2の制約閾値は両方とも、第1の制約閾値の一方または両方に違反することなく、違反される可能性がある。

加えて、プロセッサの制約閾値に関して上述したように、単一の制約閾値は、単一のリソースに対する2つ以上の所定の重要性の値(たとえば、プロセッサの場合には持続時間および能力)に関連付けられ得る。したがって、両方の値は、重要なリソースの制約の存在を示すために、指定された制約閾値を超える必要がある。さらにリソースは、重要なリソースの制約の2つ以上のタイプを有することができ、したがって、同じリソースの異なる態様のための2つ以上の制約値を有することができる。このように、これらの制約値のいずれかに違反することは、重要なリソースの制約が存在することを別々に示すように指定され得る。たとえば、プロセッサは、処理能力に関連付けられた一次の第1の制約閾値と処理速度に関連付けられた二次の第1の制約閾値とを有することができる。

リモートリソースとオンボードリソースの両方がリソース状態を示すことができるが、オンボードリソースとは異なり、リモートリソースの状態は、通信デバイスとのそれらの接続への依存関係を有する。接続それ自体がリソースであるその接続の状態は、それが接続するリモートリソースの状態に影響を及ぼす。たとえば、リモートネットワークサーバは、そのサーバ自体がダウンしているので、中間リモートリソース(たとえば、そのサーバへのリモートネットワーク接続)がダウンしているので、オンボードリソースがダウンしている(たとえば、そのサーバに達するために使用されるオンボードWi-Fi接続が動作していない)ので、利用不可能になる可能性がある。それにもかかわらず、重要なリソース制約が存在するかどうかを決定する際、リモートリソースの状態が制約閾値に違反した理由は重要ではない可能性があり、そうなったということにすぎない。代替的には、通信デバイスのリソースを管理する方法は、リモートリソースの利用可能性または状態が重要になった理由を考慮する第3の制約閾値を組み込むことができる。

いくつかの実施形態では、通信デバイスのトランシーバエンジンまたは通信リソースは、医療モードにおいて情報、命令、または制御を提供または受信するために、他のリソース(たとえば、1つもしくは複数のデバイス、または1つもしくは複数のデバイスのシステムオンチップ)と通信するように構成され得る。たとえば、リモートリソースとして設定された電化製品(たとえば、コーヒーメーカーまたは電子レンジ)は、それがオンになっていることを通信することができるが、通信デバイスは、ユーザがその電化製品を使用するべきではないと決定することができる(たとえば、ユーザがコーヒーを飲むべきではない、または、電子レンジが患者体内の外科用インプラントに干渉する可能性があると決定する)。したがって、ユーザが電化製品を使用する機会を有する前に、電化製品をオフにするために、トランシーバエンジンを介してコマンドが送信され得る。別の例として、電化製品と通信デバイスとの間の通信が確立されていないとき(たとえば、通信デバイスが医療モードになっていなかった、通信デバイスがオフにされていた、または通信デバイスが別の場所にあった)、ユーザが電化製品を使用した場合、ユーザがより後の時間に通信デバイスに接続すると、電化製品は、ユーザが以前に電化製品を使用したことを、トランシーバエンジンを介して通信デバイスに通信することができる。結果として、通信デバイスは、この通信を受信することに基づいて、1つまたは複数のアクションを実行することができる(たとえば、コーヒーを飲むことに対してユーザに助言する警告を表示する、または医師のオフィスにメッセージを送信する)。

ブロック720では、通信デバイスによって処理される医療データは、医療データ、具体的には、開始医療データセットの重要度(すなわち、医療データ重要度)を決定するためにチェックされ得る。医療データ重要度は、医療データから(すなわち、直接または間接的に)識別された重要度インジケータから決定され得る。また、医療データ重要度は、データの重要度および医療データ自体の結果とるべき必要があるアクションのために必要なリソースを考慮することができる。図8に関して下記で説明するように、様々な重要度インジケータが、医療データ重要度を決定するために使用され得る。重要度インジケータに関連付けられた値は、医療データに与えられる重み付けを確立する。その重要度インジケータ値が、優先順位付けデータ重要度に関連付けられた所定の値を超えた場合、医療データは、単独でより高い重要度モードを確立することができる。

ブロック730において、通信デバイスのプロセッサは、通信デバイスによって管理される医療データに関連付けられた医療データ優先度に対して、通信デバイスによって使用される複数のリソースに関連付けられたリソース状態を比較検討することができる。推論エンジンは、リソース状態と、重要度インジケータと、要求されたアクションによって必要とされる医療データを管理するためのリソースとを分析することができる。

ブロック750において、インターフェースエンジンを適用するプロセッサは、スライディング優先度スケールにおける「医療データ」およびそのそれぞれのアクションと「他のデータ」との間のリソースの相対的な割り当てを決定することができる。スライディング優先度スケールは、優先割り当てに関連付けられた1つまたは複数のリソースのために他のデータに勝って医療データに与えられるべき優先度の程度を定義することができる。スライディング優先度スケールの決定が、医療モードにある通信デバイスに応答してブロック750において行われると、非重要モード765において開始することができる。非重要モード765は、リソースは優先的に割り当てられないが(たとえば、通信デバイスは通常モードをエミュレートしている)、通信デバイスが1つまたは複数のリソースから受信した入力に基づいて、優先的なリソース割り当てを依然として決定することができるモードであり得る。スライディング優先度スケールの他方の端は、通信デバイスのプロセッサが、医療データおよびその関連するリソースに最も高いレベルの優先度を割り当てることができる高重要モード770を含むことができる。ブロック750における推論エンジンの決定は、ブロック710からの決定されたリソース状態と、ブロック720からの決定された医療データ重要度とを考慮することができる。

いくつかの実施形態では、記憶リソースおよび処理リソースを含む追加のリモートリソース(たとえば、図1のリモートリソース)は、通信デバイスに利用可能であり得る。そのような実施形態では、医療データに割り当てられた優先リソースは、リモート記憶またはリモート処理のためのリモートリソースに医療データの1つまたは複数の部分を送信するために必要な電力リソースを含むことができる。これらの実施形態では、通信デバイスは、リモートリソースからそのようなリモート処理の結果を受信するための追加の電力リソースを割り当てることができる。したがって、ブロック750の優先リソース割り当ての決定は、通信デバイスにローカルに利用可能なリソースと、通信デバイスにリモートに利用可能なリソースとの間のトレードオフ(たとえば、通信デバイスにおける利用可能な電力リソースに対してリモートリソースを利用する必要性のバランスをとる)を算定することができる。

医療データ重要度を決定することの一例は、図8に示されている。いくつかの実施形態では、図8は、方法700(図7)の医療データ重要度を決定するブロック720のより詳細な図を表すことができる。医療データ重要度は、推論エンジンによって、ユーザの状態および健康に関連する多数の異なるタイプのデータ(すなわち、少なくとも2つの異なるタイプのデータ)などの、ユーザの状態に関連付けられた複数のデータを結合または融合することによって決定され得る。いくつかの実施形態では、推論エンジンは、医療データ重要度を決定するために、ユーザに関連付けられたリアルタイムと非リアルタイムの両方の入力データ(たとえば、ユーザの環境もしくはコンテキストに関連付けられたデータ、またはユーザに属するデータ)を結合または融合することができる。

リアルタイム入力データは、たとえば、環境データ801、コンテキストデータ802、生理学的および生物学的データ803、任意の他の適切なリアルタイム入力データ、および/またはそれらの任意の組合せなどの、ユーザに関連付けられた任意の適切なタイプのリアルタイムデータを含むことができる。たとえば、空気の質、温度、および/または湿度などの環境データ801は、医療データ重要度を決定するために使用され得る。空気の質および温度は、喘息患者に重要であり得る。さらに、医療データ重要度はまた、ユーザのコンテキスト802、たとえば、ユーザの地理的位置(すなわち、GPSベースまたは高度計)、たとえば、ユーザによって装着されたセンサもしくは装着型通信デバイス上のセンサによって推論される、ユーザが休んでいるか、歩いているか、走っているか、または転倒しているかに依存することができる。加えて、医療データ重要度は、身体に装着されたセンサから(たとえば、心拍数および血圧データ)、通信デバイスのオンボードのセンサから、または、(たとえば、Bluetooth(登録商標)などの短距離接続を介して、もしくは、インターネットもしくは通信ネットワークなどの長距離接続を介した通信デバイスと通信するセンサ)リモートセンサからなど、センサから得られた生理学的および生物学的データ803に依存することができる。

非リアルタイム入力データは、たとえば、健康記録データ804、長期履歴健康データ805、個人のゲノムおよび行動データ809、任意の他の適切な非リアルタイム入力データ、ならびに/またはそれらの任意の組合せなどの、ユーザに関連付けられた任意の適切なタイプの非リアルタイムデータを含むことができる。たとえば、長期医療データ804、すなわち、ユーザの医療記録からのデータ(たとえば、撮像、臨床結果、薬)と、長期履歴健康データ805、すなわち、ユーザの身体装着型センサからの履歴データ(たとえば、血圧測定値の毎週もしくは毎日の平均、毎週のエネルギー消費プロフィール、毎日の平均心拍数値、または心拍数変動)の両方は、医療データの重要度を決定する際に使用され得る。別の例として、推論エンジンは、医療データの重要度を決定するために、個人のゲノムデータおよび行動データ809を使用することができる。いくつかの場合において、ゲノムデータ809は、健康記録データ804に含まれ得る。

医療データ重要度を決定するために推論エンジンによって使用され得る、ユーザに関連付けられた他のタイプの入力データは、個人の個々の健康リスク評価データ807、たとえば、心臓病の高いリスク、および/または直接入力806を含むことができる。直接入力806は、医療従事者、ユーザの介護者、またはユーザ自身さえから、直接的で、タイムリーで、現在の指令および入力を提供する。ある日、あまり体調の良くないユーザについて、たとえば、その情報をシステムに入力する手段を有することができる。これらのタイプのデータは、リアルタイムと非リアルタイムの両方、および/またはそれらの組合せであり得る。

いくつかの実施形態では、ユーザに関連付けられた入力データを使用することに加えて、推論エンジンは、医療データ重要度を決定するために、ユーザに関連付けられていない関連データ(たとえば、リアルタイム、非リアルタイム、またはそれらの組合せ)を使用することができる。たとえば、推論エンジンは、ユーザに相当する患者からの実際の人口データ808を使用することができる。別の例として、推論エンジンは、特定のユーザおよびそのユーザの状態に関連する、疾病対策センター(CDC: Centers for Disease Control)からのものなどの、公衆警告810を使用することができる。

すべてのこの情報は、医療データ重要度を決定するために、推論エンジン811によって使用され得る。たとえば、推論エンジン811は、医療データ重要度に対応する重要度インジケータを生成することができる。重要度インジケータは次いで、通信デバイスの別の構成要素に、および/またはリモートソースに提供され得る。

いくつかの実施形態では、推論エンジン811は、医療データ重要度に少なくとも部分的に基づいて、リソース要求を決定することができる。たとえば、推論エンジン811は、行うべき少なくとも1つのアクションの指標を生成することができる。別の例として、これらのアクションをタイムリーに、正常に行うために必要なリソースの推定が決定され得る。そのような情報は次いで、医療モードにおけるリソース割り当てを決定するために使用され得る。たとえば、ユーザに関連する過去の医療関連データおよび現在の医療関連データは、医療データの重要度を推論するために考慮され得る。過去であっても現在であっても、医療関連データは、推論エンジン811によって結合および/または融合された任意の1つまたは複数の上記のタイプのデータを含むことができる。

一例として、推論エンジン811は、身体に装着されたEKGおよびHRモニタから来るデータを観察および分析することができ、所定の閾値よりも上の心拍数の不規則性の上昇を検出することができる。いくつかの場合では、推論エンジン811は、比較に際し、長期履歴健康データ805に記憶された最近の過去のEKGに対するEKG信号の時間的特性の変化、たとえば、時間に対するその形状の変化を検出することができる。別の例として、推論エンジン811は、ユーザが現在安静にしていると決定するために、生理学的および生物学的データ803から利用可能な装着型活動センサデータをポーリングすることができる。しかしながら、推論エンジン811は、長期履歴健康データ805のデータから、ユーザが安静にする直前の最後の2〜3時間において、より高いレベルの身体活動を行っていたと決定することができる。さらに、健康記録データ804は、ユーザが心臓病の病歴を有することを示すことができる。推論エンジン811は、この利用可能な情報を融合することができ、ユーザが心臓発作にかかっている可能性があることを推測することができる。その結果、推論エンジン811は、重要度インジケータの値を既定の低い値から高い値に変更することができる。

加えて、推論エンジン811は、通信デバイスによって行われるべきアクションを識別することができ、このアクションは、この例では、その既定の値からより高い値にEKGセンサのサンプリングレートを増加させることと、ユーザの介護者に警告メッセージを送信することと、より頻繁にサンプリングされたEKG信号および心拍数情報をユーザの循環器専門医に送信し始めることとを含むことができる。推論エンジン811は加えて、次の重要な時間においてすべてのこれらのアクションを正常に実行し、図7のブロック720の出力として重要度インジケータと共にこの情報を提供するために必要な重要なバッテリおよび通信リソース(たとえば、通信デバイスによって確立される必要があるワイヤレスネットワークの帯域幅および待ち時間)を予測することができる。

いくつかの実施形態では、推論エンジン811は、状態機械(たとえば、決定論的規則ベースおよび/または統計的状態機械)を利用して、データ、たとえば、801〜810などの利用可能なリソースからのデータを分析することができ、医療データ重要度の決定を推論し、高い医療重要度に応答して行われる必要があるアクションの重要なリソース要件を予測することができる。推論エンジンの規則ベースおよび統計的状態機械は、オフライン、オンライン、または部分的オフラインおよびオンラインで訓練され得る。加えて、推論エンジン811はまた、医療データ重要度を決定する際、以下で説明するように、臨床決定支援システム(CDSS: clinical decision support system)および知識支援システム(KSS: knowledge support system)と情報を交換することができる。

推論エンジン811は、リモートリソースとしてアクセスされるおよび/またはオンボードリソースとして更新されるCDSS/KSSに結合され得る。CDSS/KSSは、患者データに基づいて診断を決定するなどの意思決定タスクを有する医師および他の医療従事者を支援するように設計された対話型システムであり得る。CDSS/KSSは、改善された健康管理のための臨床医による健康の選択肢に影響を与えるために、健康観察を健康知識とリンクさせることができる。このように、CDSS/KSSは、ケース特有のアドバイスを生成するために、複数の患者/ユーザ関連データを使用するアクティブ知識システムであり得る。

プロセッサは、受信した信号が、デバイスを動作の医療モードにする医療モード信号などの直接重要度インジケータを含んでいるかどうかを決定することができる。直接重要度インジケータを含む医療データに応答して、通信デバイスは、オンボード分析が実行されるべきか決定することになる。直接重要度インジケータは、医療データに埋め込まれたまたは医療データに追加された識別可能なコードであり得る。また、直接重要度インジケータは、医療データに与えられる重みである制約値に関連付けられた多くのコードのうちの1つであり得る。1つまたは複数のそのようなコードの識別は、値が所定の優先順位付けデータ重要度値を超えた場合、その識別のユーザのためのカスタマイズをトリガすることができる。

医療モード信号などの医療データに含まれる直接重要度インジケータは、オンボードもしくはリモートリソース、ユーザ、医療従事者、介護者、または他の当事者などの、1つまたは複数の様々なソースから来る可能性がある。リソースは、連続的に、または満たされている特定の条件に応答して、直接重要度インジケータを生成するように構成され得る。また、ユーザは、優先順位付けデータ重要度を超える直接重要度インジケータを入力するために、通信デバイス上にインストールされたアプリケーションを用いることができる。同様に、確立することを望む、医療従事者、介護者、または医療データ管理に関連するエージェントは、優先順位付けデータ重要度を超える値を有する直接重要度インジケータを通信デバイスに送信/入力することができる。このように、ユーザ、医療従事者、介護者、または医療データに関連するエージェントは、通信デバイスを強制的に医療モードにすることを能動的に選択することができる。

そのような優先順位付けデータ重要度の単独の存在は、優先度処理を必要とするようなデータの特定のセットと、特にリソースの優先割り当てとを確立することができる。たとえば、読み取り値(すなわち、医療データ)を通信デバイスに送信する医療デバイス(たとえば、EKGセンサまたは血圧センサ)は、危険な状況を検出し、フラグまたは警告メッセージ(すなわち、直接重要度インジケータ)をそのデバイスによって生成されたデータ内に含むように構成され得る。同様に、汚染レベル、UVレベル、および化学物質または他の環境条件の存在などの、他の要素または状況を測定するリソースは、直接重要度インジケータの形態で通信デバイスに外部入力の送信をトリガすることができる。重要度インジケータが、優先順位付けデータ重要度に関連付けられた閾値を超えた場合、デバイスは、医療データ単独から得られた情報に基づいて、医療モードにおいて動作することができる。

プロセッサは、直接重要度インジケータが医療データ内に含まれているかどうかを決定することができる。直接重要度インジケータが医療内に含まれているという決定に応答して、プロセッサは、優先リソース割り当てに関してさらに決定を行うことができる。直接重要度インジケータが医療データ内に含まれていないという決定に応答して、プロセッサは、医療データ内の間接インジケータから医療データ重要度を測定するために、医療データがオンボードリソースによって処理され得るかどうかを決定することができる。加えて、通信デバイスは、誰が、または何のリソースが直接重要度インジケータを通信デバイスに送信/入力することができ、またはデバイスを医療モードにすることができるのかについての制約を用いて設計され得る。このように、入力を受信する前に、特に通信デバイスが医療モードにおいて動作するかどうかの制御を放棄する前に、通信デバイスのプロセッサは、適切なパスワード、デジタル証明書、認定書、および/または承認を要求することができる。

オンボードリソースが医療データを分析するために利用可能ではないという決定、または、医療データを分析するためのオンボード処理がこのタイプの分析を必要とする医療データの特定のセットと互換性がないという決定に応答して、プロセッサは、通信デバイスが医療モードにおいて動作すべきかどうかを確認するために、医療データがリモートリソースによって分析され得るかどうかを決定することができる。オンボードリソースが医療データを分析するために利用可能であるという決定に応答して、医療データは、オンボードで分析され得る。分析はまた、ユーザ、医療従事者、または第三者へのメッセージの生成をもたらすことができる。たとえば、メッセージは、警告、緊急の医療問題の識別、または状況に対する適切な医療対応のための指針でさえあり得る。そのようなメッセージは、テキストインジケータまたは他の視覚的インジケータを使用するユーザに表示され得、アラームのような可聴音として出力され得、またはリモートリソースに送信され得る。

たとえば、オンボードプロセッサは、データが受信されたリソースのタイプに基づいて医療データを分析するために、アルゴリズムまたは他の分析を使用することができる。このように、グルコース計から受信したデータは、糖尿病のための適切なアルゴリズムのスクリーニングを適用するために認識され得る。その後、糖尿病の発見は特定の重要度インジケータ値に関連付けられ得、この値は、通信デバイスを医療モードにするのに十分なほど高い可能性がある。同様に、オンボードプロセッサは、データの心臓モニタからの受信を決定することができ、不整脈のためのスクリーニングを行うためにアルゴリズムを用いることができ、これは間接重要度インジケータを生成することもできる。医療データ重要度を測定するそのような間接重要度インジケータは、特に個人の医療履歴、ならびに現在/最近の医療読み取り値および関連情報を考慮して、通信デバイスのユーザにカスタマイズされ得る。

加えて、コンテキストアウェアネスは、医療データ重要度を測定するための医療データの分析に組み込まれ得る。このように、いくつかの医学的に重要な条件が共存していると決定する場合、おそらく通信デバイスのユーザのための優先順位付けデータ重要度に達する適切な重要度インジケータが使用され得る。たとえば、花粉数の閾値、心拍数の閾値、血糖/血圧の閾値、グルコースもしくは他の生体測定読み取り値の閾値、またはこれらの値の変動もしくは変化のレベルのための閾値さえ、医療データの分析において考慮され得、重要度インジケータに値を与えるために使用され得る。また、複数のリソースからの医療データ、または単一のリソースからのデータの別個のセットは、医療データ重要度を測定するために医療データを分析する際に一緒に考慮され得る。たとえば、医療データは、ユーザに関する過去のデータにアクセスすることによって分析され得、過去のデータは、間接重要度インジケータと比較または相関され得る。

間接重要度インジケータは、ルックアップテーブル、相互相関行列、優先順位付けアルゴリズム、またはキーワード、コード、もしくは条件を重要度インジケータとして取り扱われ得る値と関連付ける複合体データベース機能を介して識別され得る。このように、いくつかのテキスト、文字、または、医療データに含まれる一連の記号さえ、医療データの特定のセットに重みを割り当てるための間接重要度インジケータに情報を変換するデータベースからのコードに一致させられ得る。

通信デバイスが医療モードにおいて動作すべきであるという決定に応答して、プロセッサは、優先リソース割り当てを決定することができる。通信デバイスが医療モードにおいて動作するべきではないという決定に応答して、プロセッサは、優先順位付けデータ重要度が医療データ内で間接的に示されていかどうかを確認するために、医療データがリモートリソースによって分析され得るかどうかを決定することができる。

代替として、通信デバイスが医療モードにおいて動作するべきであるという間接的な決定に応答して、プロセッサは、優先順位付けデータ重要度が医療データ内で間接的に示されていかどうかを確認するために、医療データがリモートリソースによってさらに分析され得るかどうかを決定することができる。そのような代替は、優先順位付けデータ重要度の存在を確立する際に冗長性を提供する。同様に、冗長なオンボードリソースまたは複数の冗長なリモートリソースは、より正確な結果を達成するために使用され得る。

リモートリソースが医療データを分析するために利用可能であるという決定に応答して、医療データは、処理するためにそのリモートリソースに送信され得る。リモートリソースが医療データを分析するために利用可能ではないという決定、または、医療データを分析するためのリモートリソースがこのタイプの分析を必要とする医療データの特定のセットと互換性がないという決定に応答して通信デバイスのプロセッサは、通常モードに設定され得る。このように、医療データに優先のリソース割り当ては、実行される必要はなく、または医療データに優先する以前に設定されたリソース割り当ては除去され得る(すなわち、他のデータに制限されていないリソース)。

医療データは、分析されるためにネットワークサーバなどのリモートリソースに送信され得る。リモートリソースによって受信されると、医療データは、優先順位付けデータ重要度の間接重要度インジケータを識別するために分析され得る。分析オンボードリソースと同様に、リモートリソースは、データが受信されたリソースのタイプに基づいて分析されている医療データに対して実行するためにアルゴリズムおよび他の分析を使用することができる。また、リモートリソースは、拡張された処理能力へのアクセス、より複雑な分析、および通信デバイスに利用不可能またはアクセス不可能なさらなるリソースへのアクセスを有することができる。それにもかかわらず、リモート分析は、間接重要度インジケータ、特に、優先順位付けデータ重要度を示すものを識別することを試みることができる。また、優先順位付けデータ重要度の間接重要度インジケータは、個人の病歴、ならびに現在/最近の医療読み取り値および関連する情報を考慮して、通信デバイスの特定のユーザに対してカスタマイズされ得る。さらなる例として、コンテキストアウェアネスは、優先順位付けデータ重要度に関連付けられた間接重要度インジケータを識別するための医療データの分析に組み込まれ得る。また、複数のリソースからの医療データ、または単一のリソースからのデータの別個のセットは、優先順位付けデータ重要度が存在することを確立するために医療データを分析するためのリモート処理に送信され得る。

通常モードにおいて、他のデータに優先する医療データへのリソース割り当ては実行される必要はない。代替的には、データの同じまたは関連する要素に対応する医療データに優先的な以前のリソース割り当ては、除去または変更され得る。たとえば、オンボードプロセッサが重要なリソース制約を経験していると以前に決定された場合、そのプロセッサは医療モードにあるので、医療データのみを処理するように割り当てられている可能性がある。同じプロセッサがその重要なリソース制約をもはや経験していないというその後の決定は、他のデータを管理することからそのプロセッサを非制限的にすることを保証することができる。同様に、以前の優先リソース割り当ては、識別された重要なリソース制約または優先順位付けデータ重要度が解決されたら(すなわち、もはや識別不可能である)、変更または完全に除去され得る。

通信デバイスが医療モードにおいて動作すべきであるという決定に応答して、プロセッサは、優先リソース割り当てを決定することができる。どのリソースが医療データのために優先的に割り当てられるリソースであるかについての決定は、何が決定を生じたのか、または決定に寄与したのかに基づき得る。また、決定される優先的に割り当てられるリソースは、最も極端なリソース制約または医療データ重要度に基づき得る。実施形態のリソース節約アルゴリズムは、医療データのための優先的なリソースの割り当てに関して決定を行うことができる。医療データが優先されたとき、通信デバイスの選択されたリソースの他のデータのための使用は、十分なリソースが医療データの管理のために利用されることを保証するために、制限または制約され得る。

通信デバイスが医療モードにあるべきであるという決定に応答して、オンボードプロセッサまたはリモートプロセッサは、識別された対応する医療問題についての対するガイダンスのためのデータベースにさらにアクセスすることができる。一実施形態では、データベースは異なる識別された医療問題に応答して、表示するように警告する、医療提供者がメッセージを送るまたは電話をかける、指示を聴覚的または視覚的に出力するなど、ユーザまたはユーザの代理の誰かが行うべきアクションに関する詳細を提供することができる。また、特定の識別された医療問題または状況に基づいて、オンボードプロセッサまたはリモートプロセッサは、行う予めプログラムされたアクションを選択することができる。さらに、オンボードプロセッサまたはリモートプロセッサは、最寄りの病院への行き方についての指示、どのような薬を服用するのかについての指示、または単に医療提供者が状況を電話または通知されている指示の形態で、ユーザまたはユーザの代理の誰かにガイダンスを提供することができる。警告、指示、およびガイダンスは、点滅する光、ディスプレイ上のテキストベースメッセージ、ビデオディスプレイ、オーディオ指示、または通信デバイスのそばにいる誰かに知覚可能な任意の他の指示を含む、様々な方法で提示され得る。また、オンボードプロセッサまたはリモートプロセッサは、識別された医療問題または状況に基づいて、適切な所定の応答として示された場合、当局、医師、家族などに通知することができる。加えて、トランシーバまたは通信リソースは医療モードへの切り替えに応答して、情報、指示、または制御を提供するために、他のリソースと通信することができる。たとえば、リモートリソースとして設定された電化製品(たとえば、コーヒーメーカーまたは電子レンジ)はオンになっていることを通信することができるが、推論エンジンは、ユーザがその電化製品を使用すべきではないと決定する(たとえば、ユーザがコーヒーを飲むべきではない、または電子レンジが患者体内の外科用インプラントに干渉する可能性があると決定する)ことができ、したがって電化製品をオフにするためにコマンドが送信され得る。

時には、医師、介護者、または通信デバイスユーザ(すなわち、患者)でさえ、通信デバイスによって管理される医療デバイスを使用することを望む、または必要とする可能性がある。たとえば、医師または介護者は、ネットワーク接続が失われたとき、または接続レベルが低すぎるとき、医療データへのローカルアクセスを望む/必要とする可能性がある。医師または介護者は、患者の病歴、バイタルサイン、または医療データにおける傾向へのアクセスを必要とする可能性があり、これらは通信デバイスによって収集および/または編集され得る。そのようなアクセスは、通信デバイスのユーザインターフェースを介して直接達成され得、またはデバイス間のデータリンクを介して達成され得る。このように、適切な承認を用いて(すなわち、セキュリティおよび/またはプライバシー基準/要件に準拠して)、医師または介護者は医療データへのアクセスを許可され得、または通信デバイス全体への制御さえ与えられ得る。加えて、通信デバイスは、病歴のそのようなアクセス部分を作り、医師または介護者によるそのようなアクセスの記録を維持および/または送信することができる。

様々なプロセッサの決定は、特定の順序で実行されるように様々な実施形態において説明されているが、順序は、変更され得ること、および/またはリソースが優先的に割り当てられる前に、より多くが実行され得ることを理解すべきである。加えて、医療モードがオンになったまたはオフになったいずれかの決定時に、ユーザまたは他の外部エンティティに助言するために、警告が生成され得る。また、デバイスが医療モードにされた原因、タイミング、および含意の記録は、データベースの一部であるものを含む、オンボードメモリまたはリモートメモリ内に記録され得る。

図9は、医療データが様々な実施形態のリソース間で通信される方法の4つの異なるシナリオにおける通信フローを示す。様々なシナリオにおいて、医療データはリソース間で通信される。そのような医療データは、シグナリング情報と、識別コードと、医療情報、リソース、および通信の管理に関係付けられた他の要素とを含むことができる。いくつかのリソースは単に、医療データをほとんどまたはまったく変更せずに別のリソースにその医療データを伝えるが、他のリソースは医療データをかなり変更する可能性がある。それにもかかわらず、同じシナリオにおける各リソース間では、通信される医療データは、医療データに任意の実質的な変化があるかどうかにかかわらず、異なる参照番号で参照される。

シナリオAでは、元の医療データは、医療データ931を通信デバイス910の第1のオンボード無線911に送信する周辺センサ922から開始する。第1のオンボード無線911は医療データ932を中央処理装置(CPU)914に内部的に通信することができ、CPU914は処理の後、医療データ941をユーザインターフェース912のディスプレイに通信し、医療データ942をオンボードメモリ916に通信する。加えて、CPU914は、医療データ943を第2のオンボード無線919に通信することができ、第2のオンボード無線919は、医療データ944を長距離通信基地局924に伝達する。長距離通信基地局924は、さらなる通信ネットワーク、インターネットなどを介して、医療データ945を他の基地局に、それがリモートネットワークサーバ926に達するまで通信することができる。シナリオAにおける通信は様々な状況を表すことができる。たとえば、シナリオAは、センサ読み取り値が周辺センサ922から通信デバイスに送信された状況を表すことができる。そのような読み取り値は、重要度インジケータまたは他の情報を含むことができる。通信デバイスによって受信され処理されると、ユーザにはユーザインターフェース912のディスプレイを介して通知され得、医療提供者にリモートネットワークサーバ926を介して通知され得る。

シナリオBでは、元の医療データは、医療データ951を長距離通信基地局924に送信するリモートネットワークサーバ926から開始する。長距離通信基地局924は、医療データ952を第2のオンボード無線919に伝達することができ、第2のオンボード無線919は、医療データ953を、データを処理および/または分析するCPU914に通信することができる。CPU914は、医療データ954を、記憶するためのオンボードメモリ916に通信することができ、医療データ955をオンボードメモリ916から受信することができる。加えて、CPU914は、医療データ961をユーザインターフェース912のディスプレイに通信することができ、拡張医療データ962をオンボードメモリ916に再び通信することができる。さらに、CPU914は、拡張医療データ963を第2のオンボード無線919に通信することができ、第2のオンボード無線919は医療データ964を長距離通信基地局924に伝達することができる。長距離通信基地局924は、その様々な通信チャネルを介して、医療データ965を、それがリモートネットワークサーバ926に達するまで通信することができる。

シナリオBにおける通信は様々な状況を表すことができる。たとえば、シナリオBは、ユーザに関する更新情報を受信した後、リモートネットワークサーバ926がその情報を通信デバイスに送信する状況を表すことができる。通信デバイスは、その情報をそれ自体のデータベース内の追加情報と比較した後、その情報を間接重要度インジケータとして認識する。その後、ユーザにはユーザインターフェース912のディスプレイを介して通知され得、医療提供者にはリモートネットワークサーバ926を介して通知され得る。

シナリオCでは、元の医療データは、医療データ971を通信デバイス910の第1のオンボード無線911に送信する周辺センサ922から開始する。第1のオンボード無線911は、医療データ972をCPU914に内部的に通信することができ、CPU914は、処理した後、医療データ973をオンボードメモリ916に通信することができる。加えて、CPU914は、医療データ974を第2のオンボード無線919に通信することができ、第2のオンボード無線919は、医療データ975を長距離通信基地局924に伝達することができる。長距離通信基地局924は、医療データ976をリモートネットワークサーバ926に通信することができ、リモートネットワークサーバ926は、データをさらに処理することができる。処理後、リモートネットワークサーバ926は、医療データ981を長距離通信基地局924に送信することができる。長距離通信基地局924は、医療データ982を第2のオンボード無線919に伝達することができ、第2のオンボード無線919は医療データ983を、データを処理、分析、または単に受信することができるCPU914に通信することができる。CPU914は、医療データ984を、記憶するためのオンボードメモリ916に通信することができ、医療データ985をユーザインターフェース912のディスプレイに通信することができる。

シナリオCにおける通信は様々な状況を表すことができる。たとえば、シナリオCは、センサ読み取り値が周辺センサ972から通信デバイスを介してリモートネットワークサーバ926まですべて送信される状況を表すことができる。そのような読み取り値は、分析後にリモートネットワークサーバ926によって識別される重要度インジケータを含むことができる。リモートネットワークサーバ926は次いで、その結果を通信デバイス910に送信し戻すことができるので、ユーザにはユーザインターフェース912のディスプレイと、オンボードメモリ916に記憶された情報とを介して通知され得る。

シナリオDでは、元の医療データは、ユーザインターフェース912からの入力として開始し、医療データ991としてCPU914に通信される。CPU914は、医療データ992をユーザインターフェース912のディスプレイに通信することができ、医療データ993をオンボードメモリ916に通信することができる。さらに、CPU914は、医療データ994を第2のオンボード無線919に通信することができ、第2のオンボード無線919は、医療データ995を長距離通信基地局924に伝達することができる。長距離通信基地局924は、医療データ996がリモートネットワークサーバ926に達するまで、その様々なチャネルを介して通信することができる。

シナリオDにおける通信は様々な状況を表すことができる。たとえば、シナリオDは、ユーザが通信デバイスを「医療モード」に切り替えることを決定する状況を表すことができ、この状況は、オーバライドが入力される(すなわち、入力)を意味する。通信デバイスは、リソースを適切に割り当てた後、ユーザディスプレイ上に医療モード状態を示すことができ、リモートネットワークサーバ926を介して医療提供者に通知することができる。

図10は、他のデータから医療データを区別するための実施形態の方法1000を示す。ブロック1005において、通信デバイスのプロセッサはデータを分析し、したがって識別するプロセスを開始または継続することができ、このプロセスは連続的に、周期的に、選択的に、または他の方法で実行され得る。データの特定のセットが医療データであるかまたはないかに関する決定は、医療モードにされている通信デバイスに直接応答して起こり得る。代替的にはおよび/または加えて、データは医療データであると決定されると、優先順位付けデータ重要度を示す重要度インジケータなどの1つまたは複数のインジケータを含むことができる。

決定ブロック1010において、分析されているデータのソースは、そのソースから来るデータが医療データであるか否かを決定するために、プロセッサのためにチェックおよび/または使用され得る。これは、特に医療データのみを取り扱うデータのソースに適用可能である。たとえば、心臓モニタのような医療センサから来るデータは医療データを排他的に取り扱うことができ、したがってそのソースからのすべてのデータは医療データとみなされ得る。医療データソースに由来する当のデータを決定することに応答して(すなわち、決定ブロック1010=「Yes」)、ブロック1050において、そのデータは、プロセッサによって医療データとして処理される。それ以外の場合、医療データソースに由来する当のデータを決定しないこと、または、それが非医療データソースから来たデータであると肯定的に決定され得るのに応答して(すなわち、決定ブロック1010=「No」)、決定ブロック1020において、プロセッサは、ユーザ/外部医療データ指示が受信されているかどうかを決定することができる。

決定ブロック1020では、プロセッサは、外部の直接医療データ指示が受信されているかどうかを決定することができ、外部の直接医療データ指示は、ユーザ入力または他の外部ソースからであり得る。外部の直接医療データ指示は、データがどのような情報を含むのかにかかわらず、すべてのデータまたはデータの特定のセットのいずれかを医療データとして指定することを表す入力である。このタイプの指示は、処理されているデータが非医療ソースから来た、または任意の他の医療データインジケータを含まなかったとしても、オーバライドとして作用することができる。外部の直接医療データ指示が受信されているという決定に応答して(すなわち、決定ブロック1020=「Yes」)、プロセッサはブロック1050において、そのデータを医療データとして処理することができる。それ以外の場合、外部の直接医療データ指示が受信されていないという決定に応答して(すなわち、決定ブロック1020=「No」)、プロセッサは決定ブロック1030において、データ自体が、それが医療データであることの直接医療データインジケータを含むかどうかを決定することができる。

通信デバイスによって処理されるデータは、それが医療データであることの直接重要度インジケータを含むことができる。そのような直接重要度インジケータは、直接重要度インジケータを表すデータ内に埋め込まれたパラメータまたは値であり得る。加えて、そのようなパラメータはまた、医療データの異なるセットまたはタイプを優先順位付けするために使用される値を含むことができる。このように、医療データの第1のタイプは、医療データの第2のタイプよりも優先され得る。さらなる態様によれば、医療データのための測定基準は、他の医療データを含むデバイスによって処理される他のデータと比較して医療データがどれくらい重要であるのかを測定または決定するために使用され得る。

それが医療データであることの直接重要度インジケータを含むデータは、特に、医療データを排他的に提供しない可能性があるデータのソースに適用可能である。代替的には、この技術は、データが医療データとして処理されることを示すおよび/または保証するために、医療データソースによって使用され得る。当のデータが直接医療データインジケータを含むという決定に応答して(すなわち、決定ブロック1030=「Yes」)、プロセッサは、ブロック1050において、そのデータを医療データとして扱うことができる。それ以外の場合、当のデータが直接医療データインジケータを含まないという決定に応答して(すなわち、決定ブロック1030=「No」)、プロセッサは決定ブロック1040において、ローカルな分析または外部の分析が、データが医療データであることを示すかどうかを決定することができる。

決定ブロック1040において、プロセッサは、データの特定のセットが医療データであるという間接重要度インジケータを探すことができ、この決定は、通信デバイスにおいてローカルに行われ得、および/または何らかのリモートリソースから行われ得る。たとえば、オンボードプロセスは、処理されているデータが心拍数のパターンであることを決定し、そのようなデータが医療データであるという指示を生成するために、アルゴリズムおよび他の分析をデータに適用することができる。代替的には、医療提供者によって動作されるサーバなどのリモートソースは受信したデータを分析することができ、そのようなデータが医療データとして処理されるべきであるという指示を生成することができる。当のデータが医療データとして処理されるべきであることを示すローカルまたは外部の分析と、そのような指示が受信されたこととに応答して(すなわち、決定ブロック1040=「Yes」)、プロセッサはブロック1050において、そのデータを医療データとして扱うことができる。それ以外の場合、外部の分析の指示が受信されていないという決定に応答して、または受信した分析インジケータが、当のデータが医療データではないことを反映している場合(すなわち、決定ブロック1040=「No」)、プロセッサはブロック1045において、当のデータを「他のデータ」(すなわち、非医療データ)として扱うことができる。代替的には、ローカルまたはリモートの分析は、データの特定のセットが実際は医療データであるが、特別な処理を保証する医療データではないと結論を下すことができ、これは報告されている医療データ指示をもたらさない可能性がある。

プロセッサが、医療データを他のデータから区別し、ブロック1050においてそれを明確に医療データとして扱うと、プロセッサは医療モードにあるときなどに、その医療データに優先的にリソースを割り当てることができる。このように、通信デバイスは、他のデータよりも医療データ処理およびアプリケーションを優先させるように構成され得る。また、ブロック1050において処理される医療データのさらなる分析は、優先度のさらなる指示を明らかにすることができる。たとえば、データのリモートソースがそのデータを医療データとして識別するリモート重要度インジケータを送信するが、データ自体は、その際に冗長な指示を含む状況を考える。

一実施形態では、オンボードプロセッサまたはリモートプロセッサは、受信した医療データ(たとえば、位置センサデータ、加速度計データ、外気温度データ、クロック入力など)に基づいてコンテキストを決定することができる。プロセッサは、分析の結果および/または結果に応答して行われるアクションを適合させるために、医療データに適用されるアルゴリズムおよび他の分析を修正し、および適合させるために、決定されたコンテキストを使用することができる。一例として、遠隔地で確認された、差し迫った医療問題は、健康管理提供者または救急医療提供者に対して出される警告をもたらすことができる。

一実施形態では、医療データはセット(すなわち、データの別個のグループ)にさらに分割され得る。また、データのセットは、第1の医療データセットが第2の医療データセットよりも階層の上位になるように、重要度の階層を有するように指定され得る。

通信デバイスが医療モードにあり医療データが優先されるとき、リソース節約アルゴリズムは、様々な要因によって駆動されるリソースを割り当てることができる。たとえば、リソースの状態、医療データの内容、および/または外部の直接インジケータは医療データの優先度を上昇させることができ、またはリソースの優先割り当てを起こすことができる。

リソースの割り当ては、通信デバイスを動作の医療モードに導く医療データ入力の受信に応答して起こり得る。重要なリソース制約が存在するという決定に応答して、プロセッサは、重要なリソース制約を確立するリソースに取って代わる1つまたは複数の代替のリソースが利用可能であるかどうかを決定することができる。重要なリソース制約が存在しないという決定に応答して、プロセッサは、データを優先するかどうかを決定することができる。代替のリソースが利用可能ではないという決定に応答して、プロセッサは、1つまたは複数のターゲットリソースの重要リソース制約割り当てを決定することができる。代替のリソースが利用可能であるという決定に応答して、適切な利用可能な代替のリソースが、医療データの優先処理のためにプロセッサによって指定され得る。適切で利用可能な代替のリソースは、状況に応じてオンボードリソースおよび/またはリモートリソースを含むことができる。たとえば、医療データが記憶のためのリモートネットワークメモリの位置に転送されるように、その制約閾値よりもかなり上のその制約値によって示されるように、オンボードメモリがほぼいっぱいであるシナリオを考える。さらなる例として、リモートプロセッサが医療データの第1のセットを処理して既にビジーである(すなわち、高い制約値によって示されるように、通信デバイスによって処理されるさらなる医療データを処理するように負担をかけられている)シナリオを考え、これは、医療データの第2のセットがローカルに処理するためにオンボードプロセッサに転送されるように、動作の医療モードをトリガする。このように、医療データは、処理するための代替リソースに転送され得る。また、任意の関連するリソースは、選択された代替リソースが医療データの管理を引き継ぐまたは支援するのを容易にするために更新され得る。

プロセッサは、リソース制約値および医療データ重要度インジケータに与えられた重みをトリガする条件に基づいて、スライディングスケールリソース割り当てを決定することができる。たとえば、実施形態のリソース節約アルゴリズムは、医療アプリケーションの安全性要件および有効性要件に対するリソースの利用可能性のバランスを取るスライディングスケールに沿った医療データの管理をサポートするために、リソースを部分的に転送することができる(たとえば、リソースがより制約されるようになったとき、医療データのためのCPUの20%および帯域幅の50%は、100%に増加する)。このように、医療データを通信デバイスのリモートリソースまたはオンボードリソースに転送することは、優先的にリソースを割り当てることの一部であり得る。

どのリソースが医療データのために優先的に割り当てられ得るのかに関する決定は、様々なシナリオの下でそのようなリソースを識別する、ローカルプロセッサまたはおそらくはリモートプロセッサによって実行される推論エンジンからもたらされ得る。そのような推論エンジンは広い範囲の条件と、1つまたは複数の利用可能なリソースのリソース状態と、他の関連情報とを考慮することができる可能性がある。たとえば、オンボードプロセッサなどの特定のリソースは、他のデータのために使用されることが抑制され得る。このように、医療モードにあるとき、医療データとみなされないデータは、そのオンボードプロセッサによって処理されない可能性がある。代替的には、同じ例において、プロセッサが、たとえば処理能力の20パーセント(20%)などの限られた割合で他のデータのために使用され得るように、抑制が制限され得る。このように、リソースの所定の部分は、医療データが適切に管理されるのを確実にするために利用可能にされ得る。一般的に専用リソースとして医療データのために排他的に確保され得るリソースが、他のデータのために限定された割合で使用されることが許可される状況さえ存在する。

リソース割り当ての別の方式は、単に他のデータよりも医療データを優先させることができる。このように、医療データがほとんどまたはまったく通信デバイスによって管理されていない場合、制約は他のデータにほとんどまたはまったく加えられない。通信デバイスが突然大量の医療データを受信した場合、医療データは他のデータよりも優先され得るので、他のデータは処理されるのを待機しなければならない。

代替リソースは単に、重大なリソース制約を有するリソースに取って代わることができる。また、2つ以上のリソースが、制約されたリソースに取って代わる必要がある可能性がある。したがって、代替リソースの状況およびリソース状態は、プロセッサが割り当てレベルを決定するときに考慮され得る。リソース割り当ての決定はリソースベースであり得る(すなわち、識別されている重要なリソース制約からトリガされ得る)。したがって、推論エンジンは、どのリソースがそのような状況下で使用されることになるかについての所定の指示を有することができる。たとえば、無線、プロセッサ、メモリ、および/または電源は、代替の同様のリソースが利用可能ではない、リソースベースの医療モードの場合に使用するために指定され得る。推論エンジンは、重要なリソース制約に関連する様々な状況を処理するようにプログラムされ得る。また、特別なアクションが特定の重要なリソース制約に関連する、ある状況の下で行われ得る。そのようなアクションは、様々な状況に対する所定の応答でプログラムされた推論エンジンによって制御され得る。たとえば、通信デバイスのための主要な電源および/またはバックアップ電源が非常に低下している場合、その電力がなくなったら、通信デバイスのすべてのオンボードリソースは追加の電力が得られるまで利用不可能になる。したがって、通信デバイスは、テキスト、もしくは点滅/明滅する光などの他の視覚的メッセージ、および/または音声信号を介して、ユーザ、医療提供者、または他のエンティティに警告するように構成され得る。このように、通信デバイスが最後に近い残りの電力(すなわち、仮想的瀕死の呼吸)を使用する前に、遭難信号が、ユーザ、他のエンティティ、および/またはリモートソースに出力または送信され得る。同様に、ユーザ、他のエンティティ、および/またはリモートリソースに、他の重要なリソース制約が通知され得る。通知は、住所または全地球測位システム座標などの、通信デバイスの位置を含むことさえできる。選択状況下では、リモートリソースは、通常は通信デバイスに送られる医療データを別のリモートリソースにリダイレクトすることができる。加えて、そのような推論エンジンは再構成可能であり得るので、アクションは必要に応じてカスタマイズまたは変更され得る。

リソース割り当ての決定は、優先順位付きデータ重要度に基づき得る(すなわち、重要度インジケータの結果としてトリガされ得る)。したがって、推論エンジンは、優先順位付きデータ重要度を考慮することができ、どのようなリソースがそのような状況下で影響を受けることになるかについての特定の所定の指定を使用することができる。たとえば、無線、プロセッサ、メモリ、および/または電源は、医療モードにおいて動作するとき、医療データのために優先的に割り当てられるように指定され得る。割り当てのためのリソースが決定されると、各リソースのための優先措置のレベルがプロセッサによって決定され得る。そのような優先措置は、他のデータを超えて医療データに与えられる、排他性を含むことができる優先度であり得る。また、優先措置は、制限(たとえば、数パーセントの帯域幅、処理能力、メモリ使用量、または電力消費)を有することができるので、ターゲットリソースの使用は、医療データによって完全には引き継がれない。その後、プロセッサはさらなるリソース割り当てが必要かどうかを決定することができる。

リソース割り当ての決定は、リソース状態と医療データ重要度の両方を比較検討した結果であり得る。通信デバイスは、重要なリソース制約も優先順位付けデータ重要度も確立されていないという事実にもかかわらず、医療モードにおいて動作していることができる。この場合には、リソース状態および医療データ重要度にそれぞれ与えられる重みをさらに考慮するスライディングスケールがさらに使用され得る。また、リソース割り当ての所定の指定は、スライディングに沿って様々なシナリオのために確立され得、スケールの一方の端はリソース状態によってより強く影響され、スケールの他方の端は医療データ重要度によって影響される。

指定/決定されているリソース割り当てに応答して、プロセッサは、適切で状況に特に適した割り当てのレベルを決定することができる。たとえば、セルラー無線を介した受信が何らかの理由で失われた状況を考える。通信デバイス内のセルラー無線は、接続の不足、または低すぎる接続レベルに基づいて、動作の医療モードをトリガすることができる。医療データを通信するための代替の無線がない場合、すべての医療データはセルラー通信接続が再開するまで、たとえばオンボードプロセッサおよび/またはメモリに転送されなければならない。このように、接続を失っている通信デバイスは接続を得るまで、またはオンボードメモリからのより直接的な修正のために、医療データを収集および記憶するために働くことができる。

必要とされる割り当てのレベルは、決定された状況に依存することができる。たとえば、決定は、優先度またはおそらくは排他性が特定の指定されたリソースに関して医療データに与えられる必要があるかどうかに関して行われ得る。そのような優先度/排他性は、抑制されたリソースの代わりに代替のリソースの使用が医療データと他のデータの両方を処理することができる場合、必要ではない可能性がある。たとえば、ダウンしており、利用不可能であるが、代替の冗長なサーバが通信デバイスによる使用のための利用可能である、遠隔通信提供者のサーバなどの、リモートネットワークリソースを考える。そのような状況下では、医療データの処理に優先度が与えられる必要はなく、リモートサーバに対するすべてのデータ処理は代替サーバにリダイレクトされ得る。

他のデータを超える医療データのリソースによる優先措置は、完全な優先度、制限された優先度、または排他性さえも含むことができる。したがって、優先措置は制限(たとえば、数パーセントの帯域幅、処理能力、メモリ使用量、または電力消費)を有することができるので、ターゲットリソースの使用は医療データによって完全には引き継がれない。たとえば、通信デバイスによって処理され、医療データであると決定されたデータは、無線、プロセッサ、メモリ、および電力などのリソースに対する他のデータを超える第1の優先度を得ることができる。第1の優先度は、医療データが、他のデータと同時に起こる前に、処理、送信、および/または格納されることを意味する。代替的には、1つまたは複数のリソースの所定の割合が医療データを処理する際に使用するために予約され得るが、リソースはそれ以外の場合、他のデータを処理するために使用され得る。同様に、第1の優先度は、ターゲットリソースの所定の割合のみに適用され得る。それにもかかわらず、割り当てのレベルが決定されると、プロセッサはさらなるリソース割り当てが必要であるかどうかを決定することができる。

オプションで、プロセッサは、デバイスが医療モードでまたは医療モード外で動作すべきであることを示唆することになる(たとえば、閾値量よりも多く変化することによる)状態の変化を監視するために、デバイスの状態(たとえば、バッテリレベル、信号強度など)、ならびにユーザの状態についての情報(たとえば、医療的含意を有することができるセンサデータまたは活動)を監視することができる。たとえば、通信デバイスが患者の心拍数または血糖読み取り値を監視し送信する中間の優先度の医療モードにあるとき、倒れている人と一致している可能性があるような、突然の加速度計読み取り値および/または助けを求めて叫んでいるユーザを検出する音声認識アルゴリズムは、現在の医療モードリソース割り当てが変更された状況に適していないことを示す可能性がある。別の例として、プロセッサは、バッテリが現在のリソース割り当てモードにおいて消耗していることを決定することができ、デバイスがバッテリで動作する時間を延長しながら、継続的な患者の最も重要なパラメータの監視/報告を確実にするために、新しいリソース割り当てが必要であることを決定することができる。プロセッサが、デバイスまたはユーザの状態が変化したことを決定するのに応答して、リソース割り当てプロセスは、プロセッサによって再び開始され得る。このように、通信デバイスは、ユーザのおよびデバイスの現在の状況の変化に応答して適切なリソース割り当てを達成するために、状態の変化に反応することができる。

前述の方法の説明およびプロセスフロー図は、単に例示的な例として提示され、様々な実施形態のステップが提示された順序で実行されなければならないことを必要とする、または意味することは意図されていない。当業者によって理解されるように、前述の実施形態におけるステップの順序は、任意の順序において実行され得る。「その後」、「次いで」、「次に」などの単語は、ステップの順序を制限することを意図しておらず、これらの単語は単に、方法の説明を通じて読者を導くために使用される。さらに、たとえば、冠詞「a」、「an」、または「the」を用いる、単数形における特許請求の範囲の要素への任意の参照は、要素を単数形に限定するものとして解釈されるべきではない。さらに、「複数」という単語は、本明細書では、1つよりも多くの要素を指すことを意図している。複数は、わずか2つの要素、多数の要素、またはその間の任意の数を含むことができる。「例示的」という単語は、本明細書では「例、事例、または実例として役立つこと」を意味するために使用される。「例示的」または「例」として本明細書に記載された任意の実施態様は、必ずしも他の実施態様よりも好ましいまたは有利であるものとして解釈されるべきではない。加えて、「第1の」および「第2の」という単語、または同様の言い回しの使用は、本明細書では、様々な記載の要素を区別する明確な目的のためであることが意図されており、特許請求の範囲を要素の特定の順序または階層に限定することは意図されていない。たとえば、特許請求の範囲で使用される場合、「第1のオンボードリソース」、「第2のオンボードリソース」、および「第3のオンボードリソース」という用語は、同じまたは個別のオンボードリソースを指すことができる。同様に、特許請求の範囲において使用される場合、「医療データの第1の部分」および「医療データの第2の部分」という表現は、医療データの同じまたは別個の部分を指すことができる。

本明細書で使用される場合、「コンピュータ」、「タブレットコンピュータ」、および「コンピューティングデバイス」という用語は、公知であるまたは将来に開発される任意のプログラマブルコンピュータシステムを指す。コンピュータシステムは、本明細書で説明されるプロセスを実行するためのソフトウェア命令によって構成され得る。

本明細書で使用される場合、「コンポーネント」、「モジュール」、および「システム」などの用語は、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、実行中のソフトウェアを問わず、コンピュータ関連のエンティティを指すことが意図されている。たとえば、構成要素は、これらに限定はしないが、プロセッサ上で実行されているプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行のスレッド、プログラム、および/またはコンピュータとすることができる。実例として、サーバ上で動作するアプリケーションとサーバの両方は構成要素であり得る。1つまたは複数の構成要素は、プロセスおよび/または実行のスレッド内に常駐することができ、構成要素は、1つのコンピュータ上に局在化され得、および/または2つ以上のコンピュータ間で分散され得る。

通信デバイスは、一般的に、動作を実行する相互接続された物理的電子構成要素で構成された様々なタイプの電子ハードウェア(単に「ハードウェア」とも呼ばれる)を含む。ハードウェアは、センサ、ディスプレイ、プロセッサ、メモリ、無線、電源、インターフェース、および他の周辺構成要素などのオンボード構成要素を含むことができる。しばしば、バッテリは電力ソースとして使用されるが、様々な実施形態は、何らかの点でデバイスに利用可能である場合、リソースの点からリモートまたはオンボードの電力のソースを電力ソースであるとみなす。たとえば、コンセントへのワイヤード電気接続はリモート電力リソースであり得、太陽電池などの他の内部または外部リソースはオンボード電力リソースであり得る。

加えて、通信デバイスは、その各々がリソースとみなされ得る1つまたは複数の様々なタイプの無線を含むことができる。無線は、遠隔通信ネットワークなどを介してリモートネットワーク要素と、ならびにデバイスに近接したセンサまたはデータ収集装置などのローカルリソースと通信するために使用され得る。本明細書で使用される場合、「無線」という用語は、たとえば、電磁波による信号のワイヤレス送信および/または受信のために使用される1つまたは複数の構成要素を指す。オーディオ、ビデオ、テキストなどを含むデータの様々な形態は、無線を使用して通信され得る。無線を使用して通信されるデータは抽出され、その元の形態に変換され得る。無線は、セルラー、全地球測位システム(GPS)、Wi-Fi、Bluetooth(登録商標)、ANT、ZigBeeなどの、様々な技術および/またはプロトコルのうちの1つまたは複数を使用する送信機および/または受信機を含むことができる。

リソースとみなされ得る様々な実施形態におけるプロセッサは、本明細書に記載の様々な実施形態の機能を含む様々な機能を実行するためにソフトウェア命令(アプリケーション)によって構成され得る、任意のプログラマブルマイクロプロセッサ、マイクロコンピュータ、コントローラ、マイクロコントローラ、状態機械、または複数のプロセッサチップであり得る。いくつかのデバイスにおいて、ワイヤレス通信機能専用の1つのプロセッサ、および他のアプリケーションを実行する専用の1つのプロセッサなどの、複数のプロセッサが設けられ得る。プロセッサは、本明細書に記載の機能を実行するように設計された、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、ディスクリートゲートもしくはトランジスタロジック、ディスクリートハードウェア構成要素、またはそれらの任意の組合せであり得る。また、本明細書で開示された実施形態に関連して説明された様々な例示的なロジック、論理ブロック、モジュール、および回路を実装するために使用されるハードウェアは、プロセッサを用いて実装または実行され得る。代替的には、いくつかのステップまたは方法は、所与の機能に固有の回路によって実行され得る。

本明細書に開示された実施形態に関連して説明された様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得る。ハードウェアおよびソフトウェアのこの互換性を明確に示すために、様々な例示的構成要素、ブロック、モジュール、回路、およびステップがそれらの機能の観点から全体的に上記で説明されている。そのような機能がハードウェアまたはソフトウェアのいずれとして実装されるのかは、システム全体に課される特定の用途および設計に依存する。当業者は、説明された機能を各々の特定の用途のために様々な方法で実装することができるが、そのような実装の決定は、本発明の範囲からの逸脱を引き起こすものとして解釈されるべきではない。

ソフトウェアにおいて実装される場合、機能は、非一時的コンピュータ可読媒体または非一時的プロセッサ可読媒体上に1つまたは複数の命令またはコードとして記憶され得る。本明細書で開示された方法またはアルゴリズムのステップは、非一時的コンピュータ可読またはプロセッサ可読記憶媒体上に常駐することができるプロセッサ実行可能ソフトウェアモジュールにおいて具体化され得る。非一時的コンピュータ可読またはプロセッサ可読記憶媒体は、コンピュータまたはプロセッサによってアクセスされ得る任意の記憶媒体であり得る。例として、そのような非一時的コンピュータ可読またはプロセッサ可読媒体は、これらに限定はしないが、RAM、ROM、EEPROM、フラッシュメモリ、CD-ROMもしくは他の光ディスク(disc)記憶装置、磁気ディスク(disk)記憶装置もしくは他の磁気記憶デバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を含むことができる。ディスク(disk)およびディスク(disc)は、本明細書で使用される場合、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー（登録商標）ディスク(disk)、およびブルーレイディスク(disc)を含み、ここで、ディスク(disk)は通常データを磁気的に再生し、ディスク(disc)はデータをレーザを用いて光学的に再生する。上記の組合せはまた、非一時的コンピュータ可読およびプロセッサ可読媒体の範囲内に含まれる。加えて、方法またはアルゴリズムの動作は、コンピュータプログラム製品に組み込まれ得る非一時的プロセッサ可読媒体および/またはコンピュータ可読媒体上のコードおよび/または命令の1つまたは任意の組合せもしくはセットとして常駐することができる。

典型的には、ソフトウェアアプリケーションは、それらがアクセスされプロセッサ内にロードされる前に内部メモリに記憶され得る。いくつかの通信デバイスにおいて、プロセッサは、アプリケーションソフトウェア命令を記憶するために十分な内部メモリを含むことができる。いくつかのデバイスにおいて、セキュアメモリは、プロセッサに結合された別個のメモリチップ内で専用であり得る。多くのデバイスにおいて、内部メモリは、揮発性メモリ、もしくはフラッシュメモリなどの不揮発性メモリ、または両方の混合物であり得る。この説明の目的のため、メモリに対する全体的な参照は、内部メモリ、デバイスに差し込まれるリムーバブルメモリ、およびプロセッサ自体の中のメモリを含む、プロセッサによってアクセス可能なすべてのメモリを指す。

開示された実施形態の前述の説明は、任意の当業者が本発明を作成または使用することを可能にするために提供される。これらの実施形態に対する様々な修正は当業者には容易に明らかとなり、本明細書で定義した一般的な原理は、本発明の要旨または範囲から逸脱することなく他の実施形態に適用され得る。したがって、本発明は、本明細書に示す実施形態に限定されることを意図しておらず、以下の特許請求の範囲、ならびに本明細書で開示する原理および新規の特徴と一致する最も広い範囲を与えられるべきである。

10 ユーザ
100 通信システム
110 通信デバイス
112 信号
122 心拍数モニタ
124 手首装着型デバイス
126 気象センサ
130 基地局
140 インターネット
150 サーバ
152 サーバ
154 サーバ
200 通信デバイス
201 恒久的外側ハウジング
210 プロセッサ
220 内部メモリ
222 内部メモリ
230 タッチスクリーンディスプレイ
232 スピーカ
234 マイクロフォン
236 カメラ
238 物理的ボタン
239 物理的ボタン
240 アンテナ
242 トランシーバ
250 Micro-Bポート
260 バッテリ
270 専用構成要素
300 サーバ
301 プロセッサ
302 揮発性メモリ
303 ディスクドライブ
304 リムーバブルディスクドライブ
307 ネットワークアクセス接続
400 タブレットコンピュータ、ワイヤレスデバイス
401 恒久的外側ハウジング
410 プロセッサ
420 内部メモリ
422 内部メモリ
430 タッチスクリーンディスプレイ
432 スピーカ
434 マイクロフォン
436 カメラ
438 物理的ボタン
440 アンテナ
460 バッテリ
470 オンボードプロセッサ
472 オンボードメモリ
474 オンボードバッテリ
500 システムオンチップ(SOC)
502 デジタル信号プロセッサ(DSP)
504 モデムプロセッサ
506 グラフィックプロセッサ
508 アプリケーションのプロセッサ
510 医療モード暗号化モジュール
512 専用メモリ
514 アナログ回路およびカスタム回路
516 リソース
518 クロック
520 電圧レギュレータ
524 相互接続/バスモジュール
600 通信デバイス
601 医療モードSOC
622 チップ接続インターフェース
652 プロセッサ
654 ユーザインターフェースコントローラ
655 恒久的外側ハウジング
656 内部メモリ
662 デバイス接続インターフェース
801 環境データ
802 コンテキストデータ
803 生理学的および生物学的データ
804 健康記録データ
805 長期履歴健康データ
806 直接入力
807 個人の個々の健康リスク評価データ
808 ユーザに相当する患者からの実際の人口データ
809 個人のゲノムおよび行動データ
810 公衆警告
811 推論エンジン
910 通信デバイス
911 オンボード無線
912 ユーザインターフェース
914 中央処理装置(CPU)
916 オンボードメモリ
919 第2のオンボード無線
922 周辺センサ
924 長距離通信基地局
926 リモートネットワークサーバ
931 医療データ
932 医療データ
941 医療データ
942 医療データ
943 医療データ
944 医療データ
945 医療データ
951 医療データ
952 医療データ
953 医療データ
954 医療データ
955 医療データ
961 医療データ
962 拡張医療データ
963 拡張医療データ
964 医療データ
965 医療データ
971 医療データ
972 医療データ
973 医療データ
974 医療データ
975 医療データ
976 医療データ
981 医療データ
982 医療データ
983 医療データ
984 医療データ
985 医療データ
991 医療データ
992 医療データ
993 医療データ
994 医療データ
995 医療データ
996 医療データ

Claims (30)

1. 通信デバイスのリソースを管理する方法であって、前記通信デバイスが、他のデータに加えて医療データを処理および通信するように構成され、前記方法が、
   少なくとも1つの信号に基づいて、医療モードに切り替えるかどうかを決定するステップと、
   前記医療モードに切り替えることを決定することに応答して、前記医療モードに切り替えるステップと、
   前記通信デバイスによって管理される前記医療データに関連付けられた医療データ重要度に対して、前記通信デバイスによって使用される複数のリソースに関連付けられたリソース状態を比較検討するステップと、
   前記複数のリソースをスライディング優先度スケール上に割り当てるステップと
   を含む方法。
2. 前記割り当てるステップが、前記複数のリソースのうちの1つのリソースを、前記他のデータよりも前記医療データに優先的に割り当てるステップをさらに含む、請求項1に記載の方法。
3. 前記少なくとも1つの信号が、オン信号およびオフ信号のうちの1つである、請求項1に記載の方法。
4. 前記少なくとも1つの信号が、常時オン信号および常時オフ信号のうちの1つである、請求項1に記載の方法。
5. 前記切り替えるかどうかを決定するステップが、
   手動制御と、
   前記複数のリソースからの入力に基づいて、前記医療モードまたは通常モードに自動的に切り替える第1のプロセッサ制御と、
   前記複数のリソースからのシグナリングに基づいて、前記医療モードまたは前記通常モードに切り替える第2のプロセッサ制御と、
   工場設定と
   のうちの1つに基づく、請求項1に記載の方法。
6. リソース状態を比較検討するステップが、前記通信デバイスとは別のリモートリソースによって実行される、請求項1に記載の方法。
7. 前記複数のリソースを割り当てるステップが、
   前記通信デバイスの第1のオンボードリソースに前記医療データの少なくとも第1の部分を転送するステップ、または、
   前記通信デバイスのリモートリソースに第2のオンボードリソースから前記医療データの少なくとも第2の部分を転送するステップのうちの少なくとも1つを含む、請求項1に記載の方法。
8. 前記複数のリソースを割り当てるステップが、
   前記リソースの使用の所定の部分が前記医療データを管理するために利用可能であることを保証するステップ、または、
   前記医療データが前記通信デバイスの第3のオンボードリソースの使用に関して前記他のデータよりも優先されることを保証するステップののうちの少なくとも1つを含む、請求項1に記載の方法。
9. 前記複数のリソースを割り当てるステップが、前記リソースを、前記医療データを管理することに排他的に専用とし、前記リソースが前記他のデータのために使用されることを防止するステップを含む、請求項1に記載の方法。
10. 前記複数のリソースを割り当てるステップが、前記医療データを前記リソースに転送するステップを含み、前記リソースが、前記医療データを管理するために排他的に使用される専用リソースである、請求項1に記載の方法。
11. 前記複数のリソースを割り当てるステップが、前記複数のリソースが前記他のデータを管理するために使用されることを防止するステップを含む、請求項1に記載の方法。
12. 前記医療モードへの切り替えを決定することに応答して専用リソースをアクティブ化するステップをさらに含み、前記専用リソースが前記医療データのために使用され、前記他のデータのために使用されることを抑制される、請求項1に記載の方法。
13. 前記アクティブ化された専用リソースが、前記リソース状態および前記医療データに与えられた組み合わされた重み付けに基づいて、制限された程度に前記他のデータのために使用される、制限12に記載の方法。
14. 前記アクティブ化された専用リソースが、前記通信デバイスのオンボードのシステムオンチップ(SOC)である、請求項12に記載の方法。
15. 前記SOCが、医療グレードSOCである、請求項14に記載の方法。
16. 他のデータに加えて医療データを処理および通信するように構成された通信デバイスであって、前記通信デバイスが、
    メモリと、
    前記メモリに結合されたプロセッサとを備え、前記プロセッサが、プロセッサ実行可能命令を用いて、
    少なくとも1つの信号に基づいて、医療モードに切り替えるかどうかを決定するステップと、
    前記医療モードに切り替えることを決定することに応答して、前記医療モードに切り替えるステップと、
    前記通信デバイスによって管理される前記医療データに関連付けられた医療データ重要度に対して、前記通信デバイスによって使用される複数のリソースに関連付けられたリソース状態を比較検討するステップと、
    前記複数のリソースをスライディング優先度スケール上に割り当てるステップと
    を含む動作を実行するように構成された、通信デバイス。
17. 前記メモリおよび前記プロセッサが、システムオンチップ(SOC)上で互いに結合および集積された、請求項16に記載の通信デバイス。
18. 前記SOC上で結合および集積された無線、または、
    前記SOC上で結合および集積された電源の少なくとも1つをさらに備える、請求項17に記載の通信デバイス。
19. メモリに結合された、通信デバイスのプロセッサに、他のデータに加えて医療データを処理および通信するための動作を実行させるように構成されたプロセッサ実行可能命令を記憶している非一時的プロセッサ可読記憶媒体であって、前記動作が、
    少なくとも1つの信号に基づいて、医療モードに切り替えるかどうかを決定するステップと、
    前記医療モードに切り替えることを決定することに応答して、前記医療モードに切り替えるステップと、
    前記通信デバイスによって管理される前記医療データに関連付けられた医療データ重要度に対して、前記通信デバイスによって使用される複数のリソースに関連付けられたリソース状態を比較検討するステップと、
    前記複数のリソースをスライディング優先度スケール上に割り当てるステップと
    を含む、非一時的プロセッサ可読記憶媒体。
20. 通信デバイスのリソースを管理する方法であって、前記通信デバイスが、他のデータに加えて医療データを処理および通信するように構成され、前記方法が、
    前記通信デバイスの推論エンジンで、ユーザの状況に関連付けられた複数のデータを受信するステップと、
    前記複数のデータを組み合わせることによって、医療データ重要度を決定するステップと、
    前記医療データ重要度に少なくとも部分的に基づいて、リソース要件を決定するステップと
    を含む方法。
21. 前記複数のデータが、少なくとも2つの異なるタイプのデータに関連付けられている、請求項20に記載の方法。
22. 前記複数のデータが、環境データ、コンテキストデータ、生理学的および生物学的データ、医療記録データ、長期履歴健康データ、直接入力データ、個々の健康リスクデータ、個人ゲノムデータ、行動データ、または公衆警告の少なくとも1つを含む、請求項20に記載の方法。
23. 前記医療データ重要度を決定するステップが、前記医療データ重要度に対応する重要度インジケータを生成するステップを含む、請求項20に記載の方法。
24. 前記重要度インジケータを生成するステップが、
    患者に関連付けられた長期履歴健康データを、ユーザに装着されたセンサから得られた少なくとも1つの時間的特性と比較するステップと、
    前記少なくとも1つの時間的特性の変化を検出するステップと、
    前記重要度インジケータを既定の低い値から高い値に変更するステップと
    を含む、請求項23に記載の方法。
25. 前記重要度インジケータを前記通信デバイスのオンボードリソースに提供するステップをさらに含む、請求項24に記載の方法。
26. 前記重要度インジケータをリモートリソースに提供するステップをさらに含む、請求項24に記載の方法。
27. 前記リソース要件を決定するステップが、行うべき少なくとも1つのアクションの指示を生成するステップを含む、請求項24に記載の方法。
28. 特定の期間の間に少なくとも1つのアクションを完了するために必要なリソースを決定するステップと、
    前記決定された必要なリソースに基づいて、医療モードでのリソース割り当てを決定するステップと
    をさらに含む、請求項20に記載の方法。
29. 前記医療データ重要度に関連付けられた情報を、臨床決定支援システムまたは知識支援システムの少なくとも1つと交換するステップをさらに含む、請求項20に記載の方法。
30. 前記医療データ重要度を決定するステップ、または前記リソース要件を決定するステップの少なくとも1つが、状態機械を使用して実行される、請求項20に記載の方法。

Images