健康監視システムのためのアーキテクチャ
アーキテクチャは、個々のシステムコンポーネントを個別に、すなわち異なるモジュールとして開発および試験し、後に標準化された電気および通信インタフェースにより統合することを可能とする。これらのモジュールは、健康状態の監視および／または薬物の送達のための統合システム等、任意の数の機能を提供する異なる製品を形成するように任意に組み合わせることができる。該アーキテクチャはまた、ユーザがすでに製品を購入した後でも、製品を動的に更新し、そのユーザに最新世代の技術を提供するためのアプローチを提供する。特に、この実施形態は、製品が現場で旧式となった場合、製品のソフトウェアを更新しアップグレードすることができる遠隔ネットワークへの接続を提供するためにも、通信インタフェースを使用する。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本願は、２００７年５月３０日に出願された米国特許仮出願第６０／９３２，２８６号、２００７年１２月１０日に出願された米国特許仮出願第６１／０１２，７２１号、および２００７年１２月１０日に出願された米国特許仮出願第６１／０１２，７１８号の優先権を主張し、これらの内容全体は、参照することによって本明細書に組み込まれる。
【０００２】
技術分野
本発明は、概して、ヘルスケア装置を開発するための方法およびシステムに関する。より具体的には、本発明の方法およびシステムは、健康状態の監視および／または薬物の送達のための統合システムを形成するために容易にアセンブルされる、異なる機能を有するモジュールの任意の組み合わせを可能とするアーキテクチャを提供する。また、該方法およびシステムは、現場での動作中、モジュールが動的に更新されるのを可能とするアーキテクチャを提供する。
【背景技術】
【０００３】
体液中の分析物の定量は、特定の生理的状態の診断および維持において、非常に重要である。例えば、糖尿病を有する個人は、体液中のグルコースレベルを頻繁に調べる。そのような試験の結果は、食事中のグルコース摂取量を調整するため、および／またはインスリンもしくは他の薬物を投与する必要があるかを判断するために使用することができる。
【０００４】
血糖システム等の診断システムは、個人からの血液試料中のグルコース値を計算するために、測定器もしくは機器を用いてもよい。そのような機器は、試料中のグルコースとの反応からの電流または色等の出力を測定することによって動作する。試験結果は、一般的に、測定器によって表示および保存される。基本的なシステムによって、ユーザは、キーパッドまたは他の対話型コンポーネントを介して、測定器から直接試験結果にアクセスすることができる。
【０００５】
しかし、他の診断システムは、ユーザが試験結果を処理および管理できるようにするための、より高度な機能性を提供する。例えば、いくつかのシステムは、ユーザが血糖測定器から従来のデスクトップ型パーソナルコンピュータ（ＰＣ）等の処理装置に試験結果をロードし、データ管理アプリケーションで結果を処理および表示できるようにしている。しかし、血糖測定器からの結果を編成するためにＰＣ技術の処理力を使用することは、診断システムが異なる技術を診断プロセスに組み込むことでより多くの機能性を提供する方法の単なる一例である。
【０００６】
異なる技術および機能の統合によって、極めて高度で非常に有用な診断システムを生み出すことができるが、そのようなシステムの市場への導入は、産業における製品設計および開発に対する現在のアプローチにより遅れている。例えば、多機能製品の設計に対する現在のアプローチは、異なる非標準的技術により様々な機能要素を相互接続する複雑なシステムアーキテクチャを使用する。そのため、機能要素は、特定の最終製品および考慮される他の機能要素とともに開発されなければならない。換言すると、複雑なアーキテクチャは、機能要素間の依存性をもたらし、それにより各要素は、独立して、および／または並行して開発することができない。したがって、より多くのコンポーネントが追加され複雑性が増加するにつれて、開発プロセスはより多くの時間を必要とする。
【０００７】
また、最終統合製品は、様々な技術の特徴および利点を提供し得るが、これらの技術の急速な変化は、特に製品開発がそのように長期間を要するため、最終製品が市場に導入される前に最終製品が旧式となってしまうことがある。換言すると、製品開発に対する現在のアプローチでは、製品のユーザが最新世代の技術を確実に有することが困難である。より多くの機能性のために統合製品のコストが比較的高くなり得るが、消費者は、それらの技術が急速に旧式となり得る場合、そのような製品を購入する理由を見出せなくなる可能性がある。
【０００８】
上記状況を鑑みて、医療装置の高品質基準を満たしながら異なる技術的コンポーネントを単一製品に統合するプロセスを単純化する設計および開発アプローチの必要性がある。特に、コンポーネント間のインタフェースを単純化し、したがって、コンポーネントの数にかかわらず、コンポーネントの異なる組み合わせが容易かつ確実に統合され得るようにするアプローチの必要性がある。さらに、ユーザに最新の技術を提供するために、最終製品が動的に、また継続的に更新され得るようにするアプローチの必要性がある。
【発明の概要】
【０００９】
本明細書に記載の実施形態は、個々のシステムコンポーネントを個別に、すなわち異なるモジュールとして開発および試験し、後に標準化された電気および通信インタフェースにより統合することを可能とするアーキテクチャを提供することにより、上で特定された必要性に対応する。これらのモジュールを任意に組み合わせて、健康状態の監視および／または薬物の送達のための統合システム等、任意の数の機能を提供する異なる製品を形成することができる。
【００１０】
アーキテクチャは、製品の開発サイクルを短縮化し、製品をより迅速に消費者に紹介することを可能とするが、実施形態はまた、ユーザがすでに製品を購入した後でも、製品を動的に更新し、ユーザに最新世代の技術を提供するためのアプローチを提供する。特に、実施形態は、製品が現場で旧式となった場合、製品のソフトウェアを更新しアップグレードすることができる遠隔ネットワークへの接続を提供するためにも、通信インタフェースを使用する。このプロセスは、フィールドアップグレードとして知られている。
【００１１】
インタフェースおよび通信プロトコルは、異なるコンポーネントとシステムの残りとの間の接続を容易にするように設計されているため、実施形態はまた、不正な個人または装置がシステムに接続して、システムにより収集、保存、処理され得る個人の医療情報等のデータのセキュリティを侵害することができないようにする機能性も提供する。この基礎を成すセキュリティ機能性により、個人情報への不正なアクセスに関する懸念を必要とすることなく、無線通信などの特定の技術を医療診断システムのコンポーネントとして実装することができる。
【００１２】
さらに、アセンブルされた製品と関連した重要な医学的機能のために、実施形態は、例えばフィールドアップグレード中に製品に転送された任意のデータが、製品により保存されているデータまたはソフトウェアを破壊せず、また製品が期待通りに動作し続けるように、検証手順を使用する。
【００１３】
本発明のさらに他の態様、機能、および利点は、本発明を実施するために想定される最良の形態を含む、数多くの例示的な実施形態および実施を説明することによって、以下の詳細な説明から容易に理解できるであろう。また、本発明は、他の実施形態、および異なる実施形態も可能であり、そのいくつかの詳細は、すべて本発明の精神および範囲から逸脱することなく、様々な点において修正することができる。したがって、図面および説明は、本質的に説明のためのものであって、制限的なものではないと見なされる。本発明は、本発明の精神および範囲に入るすべての修正、均等物、および代替物を対象とする。
【図面の簡単な説明】
【００１４】
【図１Ａ】本発明の態様によるアーキテクチャの図である。
【図１Ｂ】本発明の態様による別のアーキテクチャの図である。
【図２Ａ】本発明の態様によるアーキテクチャにより使用され得る例示的なセキュリティ対策を示す図である。
【図２Ｂ】本発明の態様によるアーキテクチャにより使用され得る別の例示的なセキュリティ対策を示す図である。
【図２Ｃ】本発明の態様によるアーキテクチャにより使用され得るさらなる例示的なセキュリティ対策を示す図である。
【図２Ｄ】本発明の態様によるアーキテクチャにより使用され得るさらに別の例示的なセキュリティ対策を示す図である。
【図３】本発明の態様によるアーキテクチャを使用する例示的な糖尿病管理システムの図である。
【図４】本発明の態様によるアーキテクチャの別の図である。
【図５】本発明の態様によるアーキテクチャを使用する診断システムの例である。
【図６】本発明の態様によるアーキテクチャを使用する診断システムの別の例である。
【図７】本発明の態様によるアーキテクチャを使用する診断システムのさらに別の例である。
【図８】本発明の態様によるフィールドアップグレード可能なアーキテクチャを示す。
【図９】本発明の態様によるフィールドアップグレードの使用例である。
【００１５】
例示的な実施形態の説明
本明細書に記載の実施形態は、個々のシステムコンポーネントまたはモジュールが、（異なるモジュールとして）独立して開発および検証され、後に標準化された電気および通信インタフェースにより統合されることを可能とするシステムアーキテクチャを提供する。標準化されたインタフェースは、任意の数の機能を提供する異なる製品を形成するためのこれらのモジュールの組み合わせおよび構成を容易にする。アーキテクチャは、コンポーネントの固定された組み合わせを形成するために使用することができるが、アプローチは、異なるコンポーネントを容易に除去またはシステムに追加し得る、再構成可能または拡張可能な組み合わせも可能とする。さらに、以下にさらに説明するように、アーキテクチャは、モジュールが製品内に統合された後に、モジュールを動的に更新するためのアプローチを提供する。
【００１６】
図１Ａは、本発明の態様によるモジュールアーキテクチャの概念図である。図１Ａに示すように、モジュールアーキテクチャシステム１は、それぞれ健康監視および送達システムの機能性を提供する複数のモジュール３０Ａ、３０Ｂ、３０Ｃ、および３０Ｄに接続された中央エンジン１０を含む。中央エンジン１０は、モジュール３０Ａ、３０Ｂ、３０Ｃ、および３０Ｄを効果的なシステムとして機能させることができる。例えば、中央エンジン１０は、モジュール３０Ａ、３０Ｂ、３０Ｃ、および３０Ｄ間での情報の通信を可能にする。例えば、モジュール３０Ｄは、中央エンジン１０を介して他のモジュール３０Ａ、３０Ｂ、および３０Ｃから受信したデータを処理するソフトウェアを有するコンピュータ装置であってもよい。図１Ａにさらに示すように、中央エンジン１０のインタフェース要素２２Ａ、２２Ｂ、２２Ｃ、および２２Ｄは、それぞれのインタフェース要素２４Ａ、２４Ｂ、２４Ｃ、および２４Ｄに接続して、中央エンジン１０とモジュール３０Ａ、３０Ｂ、３０Ｃ、および３０Ｄとの間の通信を確立する。インタフェースは、有線、すなわち物理的な通信、および／または無線通信を提供し得る。有利なことには、インタフェースアーキテクチャの集中型編成は、互いに別個に開発および試験され得るモジュール３０Ａ、３０Ｂ、３０Ｃ、および３０Ｄの統合を容易にする。さらに、中央エンジン１０のインタフェース要素２２Ａ、２２Ｂ、２２Ｃ、および２２Ｄは、同じ通信プロトコルに従う必要はないが、インタフェース要素２２Ａ、２２Ｂ、２２Ｃ、および２２Ｄは、中央エンジン１０が所与のモジュールとの適合性をより有し得るように、最も広く用いられている標準プロトコルを使用することができる。
【００１７】
図１Ａのモジュール３０Ａ、３０Ｂ、３０Ｃ、および３０Ｄはすべて、互いに情報を通信することができるが、中央エンジン１０に接続されたモジュールはその他のモジュールのすべてと通信する必要はないことが想定される。実際には、モジュールは、任意の他のモジュール（すべてのモジュールを含む）から通信可能に隔離してもよい。例えば、特定のモジュール上のデータおよび／またはソフトウェアの性質は、極めて敏感となり得るため、モジュールはデータのセキュリティおよび／または完全性を高めるために他のモジュールから隔離してもよい。
【００１８】
一実施形態において、中央エンジン１０は、マザーボード上に実装され、各モジュールは、ドーターボード上に別個に実装される。ドーターボードは、システムに統合される単一のマザーボードに接続し得るように標準化されている。換言すると、他のモジュールに対応するボードとの特定のインタフェースを、新たなモジュールが実装されるたびに開発する必要はない。この標準化されたアプローチにより、市販の既製（ＣＯＴＳ）ハードウェアをマザーボードおよびドーターボードに使用することがより実行可能となる。有利なことには、ＣＯＴＳハードウェアの使用は、特定用途向け集積回路（ＡＳＩＣ）アプローチよりも必要な開発時間が短い。
【００１９】
いくつかの実施形態において、マザーボードおよびドーターボードは、物理的に、別個の回路基板上に存在し得る。他の実施形態において、マザーボードおよびドーターボードは、同じ回路基板上に全て物理的に統合され得る。さらなる実施形態において、マザーボードおよびドーターボードの組み合わせは、同じ回路基板上に物理的に統合され得るが、他のドーターボードは別個の回路基板上に存在する。さらに、いくつかの実施形態において、マザーボードおよびドーターボードは、同じ回路基板上か否かにかかわらず、すべて同じ筐体またはケース内に配置され得る。一方、他の実施形態において、ドーターボードの一部またはすべてが、マザーボードの筐体とは別個の１つ以上の筐体内に配置され得る。一般に、実施形態のコンポーネントは、異なる回路基板上、または異なる筐体内等のアセンブリに関し、様々な程度の物理的統合がなされ得る。物理的構成におけるこの変化に対応するため、ドーターボードをマザーボードに接続するために２つ以上のインタフェース型が必要となることもあるが、上述したように、中央エンジンとモジュールとの間のインタフェースは、同じ通信プロトコルに従う必要はない。マザーボードと関連したインタフェース要素は、中央エンジンが所与のモジュールと適合性をより有し得るように、最も広く用いられている標準プロトコルを使用することができる。
【００２０】
標準化されたインタフェースを使用した集中型アーキテクチャは、適合モジュールの開発を容易にする。システムに機能性を追加する際、アーキテクチャとの統合は、適合インタフェース要素を使用することによって容易に達成される。さらに、新しいモジュールは、中央エンジン１０とのインタフェースが１つだけ必要となるため、他のモジュールと独立して開発することができる。換言すると、新たなモジュールがシステム内の他のモジュールと通信しなければならない場合でも、新たなモジュールは他のモジュールと直接接続するように設計される必要がないため、他のモジュールの通信構成は新たなモジュールの重要な設計上の考慮点とはならない。したがって、中央エンジン１０と容易に接続する追加のモジュールを独立して開発する能力により、このアーキテクチャを使用するシステムは柔軟で再構成可能となり得る。例えば、そのようなシステムは、新たなモジュールで拡張され得るか、または既存のモジュールの新たなバージョンでアップグレードされ得る。
【００２１】
図１Ａは、モジュール３０Ａ、３０Ｂ、３０Ｃ、および３０Ｄに接続された単一の中央エンジン１０を有する実施形態を示すが、いくつかの実施形態において、中央エンジン１０はまた、図１Ｂに示すように、副中央エンジン４０に接続されていてもよい。図１Ｂに示すように、中央エンジン１０は、対応するインタフェース要素２２Ａ／２４Ａ、２２Ｂ／２４Ｂ、および２２Ｃ／２４Ｃを介して、モジュール３０Ａ、３０Ｂ、および３０Ｃに接続されている。一方、中央エンジン４０は、対応するインタフェース要素５２Ａ／５４Ａ、５２Ｂ／５４Ｂ、および５２Ｃ／５４Ｃを介して、モジュール６０Ａ、６０Ｂ、および６０Ｃに接続されている。モジュール３０Ａ、３０Ｂ、および３０Ｃと同様に、モジュール６０Ａ、６０Ｂ、および６０Ｃは、中央エンジン４０との単一のインタフェースのみを必要とするモジュールアーキテクチャに従い、他のモジュールから独立して開発され得る。図１Ｂにさらに示すように、中央エンジン１０は、インタフェース要素２２Ｄおよび５２Ｄを介して中央エンジン４０に接続され得る。他のインタフェース要素と同様に、インタフェース要素２２Ｄおよび５２Ｄは、有線、すなわち物理的な通信、または無線通信を提供し得る。いくつかの実施形態において、中央エンジン１０は、中央エンジン４０のホスト機能を担う。例えば、ユニバーサルシリアルバス（ＵＳＢ）通信プロトコルに従い中央エンジン１０が中央エンジン４０と接続する場合、標準ＵＳＢは、２つのシステム間のホスト−スレーブ関係を必要とする。
【００２２】
図１Ｂの実施形態において、中央エンジン１０は、モジュール６０Ａ、６０Ｂ、および６０Ｃにより提供される機能性にアクセスすることができ、逆に、中央エンジン４０は、モジュール３０Ａ、３０Ｂ、および３０Ｃにより提供される機能性にアクセスすることができる。得られる組み合わせが、６つのモジュール３０Ａ、３０Ｂ、３０Ｃ、６０Ａ、６０Ｂ、および６０Ｃに接続された単一の中央エンジンのように機能し得るにもかかわらず、中央エンジン１０および４０は、別個に開発され得る。したがって、モジュールのセットの開発は、別個のサブセットに有利に編成することができる。例えば、医療診断システムは、血糖測定器等の重要な医療装置だけでなく、心拍数モニタ等のその他の種類の装置も含んでいてもよい。重要な医療装置は、開発中、非常に厳しい製品検証を必要とし、また政府規制の対象となり得る。一方、他の種類の装置は、同じ種類または同じレベルの検証を必要としない可能性がある。したがって、重要な医療装置に関与するモジュールは、他の種類のヘルスケア装置と比較して、製品開発において非常に異なるスケジュールおよびガイドラインを有し得る。したがって、この場合、モジュールを２つの製品開発グループに編成することが有利となり得る。また、新たな機能を含めるために重要な医療装置に関与する製品が再開発または更新される度に、政府規制は、その新たな特徴が比較的重要となり得ない場合にも、製品の再検証を要求し得る。例えば、すでに血糖測定器に接続されている中央エンジンに心拍数モニタが追加される場合、新たなモジュールが比較的重要でないヘルスケア装置であっても、多額のコストおよび労力を投じてシステム全体が再検証されなければならない場合がある。しかしながら、心拍数モニタに接続される副中央エンジンに接続する能力を中央エンジンがすでに有している場合、血糖測定器に接続された中央エンジンは変更されないままとなり得る。換言すると、副中央エンジンにより他のヘルスケア装置および他の特徴に関与する新たなモジュールを展開することは、主中央エンジンと関連したアーキテクチャを変更することなく製品全体を拡張する手法を提供する。さらに、副中央エンジンと関連したアーキテクチャのいかなる検証も、主中央エンジンと関連したアーキテクチャに影響を与えることなく行うことができる。
【００２３】
本明細書に記載のアーキテクチャの利点は、新たなモジュールがシステムとインタフェースをとって通信およびデータ交換を確立することができる容易性であるが、個人医療データのセキュリティに関する問題は、健康データを測定および保存する個人試験装置等の医療装置との適合性が高い通信技術の使用を妨げている。これらの問題に対処するために、本発明の態様による実施形態は、不正な個人または装置がシステムに接続していかなる個人医療情報のセキュリティも侵害できないようにするための一助となる機能性を提供する。中央エンジン１０は、セキュリティ対策を提供する機能を有してもよい。代替として、または追加として、特殊なセキュリティ機能を有するコンポーネントまたはモジュールを使用してシステムセキュリティを強化してもよい。そのようなセキュリティ機能性により、個人情報への不正アクセスに関する懸念を高めることなく、無線通信などの特定の技術を医療診断システムのコンポーネントとして実装することができる。
【００２４】
図２Ａ〜Ｄは、本発明の態様によるアーキテクチャにより使用され得るセキュリティ技術の例を示す。図２Ａに示すように、モジュール３０が中央エンジン１０とインタフェースをとるか、またはシステムを通してデータにアクセスしようとする際に、中央エンジン１０は、ユーザにユーザＩＤおよびパスワード、個人識別番号（ＰＩＮ）、または他の認証情報をプロンプトしてもよい。モジュール３０は、セキュリティプロンプトに対する応答がシステムに保存された認証情報に一致する場合、接続またはデータアクセスを唯一許可される。例えば、モジュール３０は、中央エンジン１０に接続された血糖測定器からの試験データをアップロードするデータ管理プログラムを実行するＰＣであってもよい。プログラムがインタフェース接続を介した通信を試みるか、データへのアクセスを試みる際、ユーザはユーザＩＤおよびパスワードをサブミットしなければならない。認証情報は、ＰＣまたは中央エンジン１０上のユーザインタフェース、例えばキーパッドまたはキーボードにより入力することができる。中央エンジン１０を通してデータにアクセスするためにモジュール３０が頻繁に使用される場合、ユーザは、繰り返し認証情報を入力するのを不便と感じる可能性がある。したがって、いくつかの実施形態は、ユーザが特定のモジュール３０からの認証間の期間を（ゼロから無限に）設定できるようにすることができる。中央エンジン１０は、期間を追跡するために、モジュール３０の一意の識別子、例えば装置ＩＤを記録する。例えば、最後の認証から特定の時間、例えば１日が経過した場合、セキュリティプロンプトが必要となり得る。代替として、ユーザは、第１の認証後、すべてのさらなるセキュリティプロンプトを生じさせないようにすることができる。この代替例の場合、第１の認証は、モジュール３０からのその後のすべてのアクセスを許可するための中央エンジン１０への登録として機能する。
【００２５】
図２Ｂに示すように、モジュール３０の一意の識別子、例えば装置ＩＤを中央エンジン１０に登録してもよい。この一意の識別子は、ユーザにより入力されるか、または、図２Ａに示す認証プロセスが初めて完了した際に記録され得る。代替として、モジュール３０の登録は、初期設定の、例えば出荷時設定のプロセスを通して達成され得る。この代替例の場合、初期設定後に追加のモジュールの登録を禁止し、それによりシステム中のモジュールの数を固定してもよい。モジュール３０が後にデータに接続またはアクセスしようとすると、中央エンジン１０は自動的にモジュール３０を認識してアクセスを許可する。
【００２６】
図２Ａおよび２Ｂの実施形態において、モジュール３０は、一方向プロセスで認証または登録される。換言すると、中央エンジン１０は、モジュール３０によって認証されるかまたは登録される必要はない。対照的に、図２Ｃに示すように、中央エンジン１０およびモジュール３０の両方が、互いに登録を必要とする。中央エンジン１０とモジュール３０との間に任意の通信が発生する前に、そのペアのための一意の識別子の整合が必要である。このペア整合は、２つの装置間の無線通信に特に適用することができる。プロセスは恣意的な不正アクセスを防止し、また２つの異なるシステム間の干渉も防止する。例えば、ユーザがある環境、例えば病院または診療所内におり、他の者が類似の無線検体試験装置、例えば血糖測定器等を使用している場合、ペア整合は、別の者の血糖測定器が誤ってユーザの診断システムと通信して間違ったデータを提供するのを防止する。
【００２７】
データセキュリティは、図２Ｄに示すように、通信中に暗号化データを使用することによって強化してもよい。これはまた、いかなる傍受されたデータも読み取り不可能となるように、無線通信に特に適用することができる。データ暗号化は、秘密暗号鍵を使用して達成され得る。
【００２８】
データセキュリティは、中央エンジン１０によりすべてのデータがアーキテクチャのメモリ内に格納され、接続されたいかなるモジュールにも転送されないようにすることにより、さらに強化することができる。したがって、ユーザは、例えば、公共のコンピュータを使用してシステムとインタフェースをとることができるが、他者がアクセスする公共のコンピュータにはデータが転送されない。
【００２９】
図３は、本明細書に記載のアーキテクチャアプローチから形成され得る糖尿病管理システム１００の限定されない例を示す。糖尿病管理システム１００は、血糖濃度および／または他の対象の検体の測定値の監視および記録に盛んに関わる個人に有利である。
【００３０】
図３に示すように、糖尿病管理システム１００は、血糖測定器（ＢＧＭ）３１０、連続グルコース監視（ＣＧＭ）モジュール３２０、インスリン送達装置３３０、および、演算装置３７０を含み、演算装置３７０は、糖尿病管理ソフトウェア３７５を含み得る。モジュール３１０、３２０、３３０、および３７０は、以下にさらに説明するように、本明細書に記載のアーキテクチャアプローチを使用して統合され、糖尿病管理システム１００に健康監視および送達機能を提供する。特に、ＢＧＭ３１０は、血液試料中の血糖濃度のポイントインタイムの測定を提供し、ＣＧＭモジュール３２０は、血糖濃度の連続測定を提供し、インスリン送達装置３３０は、ユーザにインスリンを送達する。
【００３１】
また、演算装置３７０は、ソフトウェア３７５を実行してモジュール３１０、３２０、および３３０からデータを受信し、高度なデータ処理および管理能力を提供する。演算装置３７０は、デスクトップ型またはラップトップ型パーソナルコンピュータ（ＰＣ）、ハンドヘルド型またはポケットパーソナルコンピュータ（ＨＰＣ）、互換性のある携帯情報端末（ＰＤＡ）、および高性能携帯電話等の様々な処理装置から選択され得る。処理装置は、様々なオペレーティングシステムおよび構成を使用し得る。例えば、演算装置３７０が、デスクトップ型またはラップトップ型パーソナルコンピュータである場合、オペレーティングシステムは、あるバージョンのＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）であってもよい。あるいは、演算装置３７０がＰＤＡである場合、オペレーティングシステムは、Ｐａｌｍ， Ｉｎｃ．，のＰＡＬＭ（登録商標）ハンドヘルド、またはＲｅｓｅａｒｃｈ ｉｎ Ｍｏｔｉｏｎ ＬｉｍｉｔｅｄのＢｌａｃｋｂｅｒｒｙ（登録商標）装置に対応してもよい。一般に、演算装置３７０は、任意の数のプログラムされた命令を受信および実行することができるプロセッサを含む。
【００３２】
演算装置３７０上のデータ管理ソフトウェア３７５は、例えば、モジュール３１０および３２０によって測定されるデータを受信および処理するプログラムもしくはコンピュータコードの集まりであってもよい。ソフトウェア３７５は、ユーザが所望する方法で、この入力を処理および／または表示する。この情報は、例えば、ユーザ、在宅医療提供者（ＨＣＰ）、および／または医師によって使用されてもよい。モジュール３１０および３２０からの測定データは、例えば、人の血液もしくは他の体液中のグルコースおよび／または他の検体の濃度を含み得る。有利なことには、ソフトウェア３７５は、１日に何度も（例えば、１日に約６回〜約１０回）試験するユーザによって要求され得る、高度な表示およびデータ処理を提供することができる。例えば、ソフトウェア３７５は、Ｂａｙｅｒ ＨｅａｌｔｈＣａｒｅ ＬＬＣ（Ｔａｒｒｙｔｏｗｎ， Ｎｅｗ Ｙｏｒｋ）から入手可能なＷＩＮＧＬＵＣＯＦＡＣＴＳ（登録商標）糖尿病管理ソフトウェアと類似する製品を含んでもよい。そのため、ソフトウェア３７５は、血糖測定システムから試験結果を受信および保存し、試験回数および食事指標等の他の試験情報を受信および保存し、電子ログブックに試験結果を追跡記録し、平均を計算して異常値の試験結果の統計分析を提供し、試験結果を要約してフィードバックを提供し、カスタマイズ可能なグラフィカルユーザインタフェースを提供し、試験結果の分かりやすいチャートおよびグラフを表示し、ユーザ固有の目標範囲に対する試験結果を追跡記録し、予測分析を提供しかつ／またはファックス、電子メール等を介してデータをヘルスケア専門家に送信する、完全なツールキットを提供し得る。前述のように、ソフトウェア３７５がモジュール３１０および３２０から演算装置３７０にデータをアップロードせず、データが常に単一の中央保存装置内に格納されれば、セキュリティが強化される。
【００３３】
以下でさらに説明するように、ソフトウェアまたはプログラムされた命令の使用は、演算装置３７０に限定されない。さらに、本発明の実施形態の使用は、特定のモジュール３１０、３２０、３３０、および３７０を使用していない。図４は、他のモジュール３００を備えたより広範なシステム図である。例えば、図４に示すように、経時的にグルコース調節を監視するＡ１Ｃモジュール３４０は、糖尿病管理システム内でも使用され得る。モジュール３００はまた、血圧および心拍数モニタ等の他の健康監視モジュール３５０を含む。実際には、モジュール３００は、体温測定、血圧測定、心拍数測定、慢性閉塞性肺疾患（ＣＯＰＤ）の分析のための呼吸測定、ラシックス（Ｌａｓｉｘ）使用を分析するための体重測定等の検体試験を必要としない健康データを測定および／または記録し得る。さらなるシステムにおいて、他の実用的な装置モジュール３６０は、トレーニングモジュール、他のシステムへのさらなる接続を提供する接続性モジュール、およびユーザのシステム体験を向上または強化する他のモジュールを含み得る。例えば、ゲームモジュールまたは音楽プレーヤモジュール等の娯楽またはメディアモジュールを、本明細書に記載のシステムと組み合わせることが想定される。例えば、娯楽機能の提供は、糖尿病等の健康状態を定期的に監視できるように、患者、特に若い患者が、どこに行こうとも診断システムを携帯することを促すことができる。さらに、いくつかのシステムにおいて、アーキテクチャはまた、本発明に記載のアーキテクチャに統合される追加のカスタムまたは特殊モジュールがユーザまたは第三者により開発され得るように、オープンソースコードを用いることができる。したがって、あらゆる種類の機能性を提供する無限の様々なモジュールが使用され得る。
【００３４】
図３に示すように、システム１００は、アーキテクチャのための中央エンジン１１０、例えばデジタルエンジンを含み、モジュール３００が容易かつ効果的に組み合わせられ得るようにする。例えば、中央エンジン１１０、ＢＧＭ３１０、ＣＧＭモジュール３２０、およびインスリン送達装置３３０を効果的に組み合わせて、人工膵臓を創出することができる。代替として、中央エンジン１１０、ＢＧＭ３１０、およびＣＧＭ３２０を組み合わせて、内蔵ＢＧＭユニットを備えるＣＧＭを形成することができる。あるいは、さらなる例として、中央エンジン１１０、ＢＧＭ３１０、およびインスリン送達装置３３０を組み合わせて、内蔵ＢＧＭユニットを備えるポンプ制御器を形成することができる。
【００３５】
再び図４を参照すると、中央エンジン１１０は、プロセッサ１１２および電力管理要素１１４を含み得る。プロセッサ１１２は、任意の数のプログラムされた命令を受信および実行することができ、マイクロコントローラ、マイクロプロセッサ、デジタル信号プロセッサ等であってよい。プロセッサ１１２により実行されるプログラムされた命令は、内蔵されていても、保存装置２５０、接続されたモジュール３００、またはインターネットウェブサイト等の別のソースから読み出し可能であってもよい。プロセッサ１１２は、モジュール３００との通信を一元的に管理する。いくつかの場合において、プロセッサ１１２はまた、いくつかのモジュール３００の動作を処理するソフトウェアを実行し得る。さらに、プロセッサ１１２は、モジュール３００に、以下にさらに説明するユーザインタフェース２２０等の共通リソースまたは機能へのアクセスを提供してもよい。
【００３６】
電力管理要素１２０は、電源から、プロセッサ１１２および独自の電源を有しないモジュール３００に電力を分配する。電力管理システム１１４は、例えば、システムがアイドル状態である場合に電力消費を最小にするためにスタンバイモードに入るように構成され得る。さらに、充電式電池を用いる場合には、電力管理システム１１４は、電池の充電にも対処することができる。
【００３７】
また図４に示すように、中央エンジン１１０は、通信インタフェース２１０およびユーザインタフェース２２０という２つの異なるカテゴリに分けることができる入力／出力インタフェース２００に接続されている。通信インタフェース２１０は、中央エンジン１１０とモジュール３００との間のデータの交換を統御する。一般に、通信インタフェース２１０は、有線および／または無線通信に対応することができる。有線通信は、例えば、ユニバーサルシリアルバス（ＵＳＢ）接続による通信を含む。無線通信としては、例えば、無線周波数（ＲＦ）リンク（例えば短距離ＲＦテレメトリ等）、赤外線（ＩＲ）リンク、および／またはＷｉ−Ｆｉが挙げられる。いくつかの既知のＲＦ技術としては、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）無線技術、Ｚｉｇｂｅｅ、Ｚ−Ｓｅｎｓｅ（登録商標）技術、ＦｉｔＳｅｎｓｅ、およびＢｏｄｙＬＡＮ（登録商標）システムが挙げられる。他の通信技術またはプロトコルを使用してもよいことが理解される。
【００３８】
再び図３を参照すると、有線または物理的接続２１２が、中央エンジン１１０と演算装置３７０との間に存在し、一方、無線接続２１４が、中央エンジン１１０とＣＧＭモジュール３２０およびインスリン送達装置３３０との各間に存在する。ＢＧＭ３１０は筐体１０１内で中央エンジン１１０とアセンブルされていることに留意されたい。したがって、中央エンジン１１０とＢＧＭ３１０との間のインタフェースは、有線接続（図示せず）を伴う。実際には、図３に示すように、モジュール３００は、中央エンジン１１０およびその他のモジュール３００に対して任意の好適な配置で組み合わせることができる。ＢＧＭ３１０と同様に、同じ筐体内で中央エンジン１１０とアセンブルされ得るモジュール３００もあれば、別個の筐体内に設けられ、中央エンジン１１０から遠隔に配置され得るモジュール３００もある。また、本明細書に記載の他の構成に加えて、例えば、回路コンポーネントの形態を有するいくつかのモジュール３００は、中央エンジン１１０の回路コンポーネントとして、同じプリント基板アセンブリ（ＰＣＢＡ）上で、インタフェース２１０を提供する回路接続によりアセンブルされてもよい。
【００３９】
図５は、中央エンジン１１０とモジュール３００、つまりＢＧＭ３１０との間の接続のさらなる例を示す。図３とは異なり、図５のＢＧＭ３１０は、中央エンジン１１０とともに筐体１０１内に配置されていないが、図５を参照して記載される説明は、図３の構成にも同等に適用することができる。
【００４０】
図５を参照すると、試験センサ３１６を有するＢＧＭ３１０が示されている。試験センサ３１６は、ＢＧＭ３１０を使用して分析される流体試料を受け入れるように構成されている。分析され得る検体は、グルコース、脂質状態（例えば、コレステロール、トリグリセリド、ＬＤＬ、およびＨＤＬ）、微量アルブミン、ヘモグロビンＡ１Ｃ、フルクトース、乳酸塩、またはビリルビンを含む。他の検体情報（例えば検体濃度）もまた決定し得ることが想定される。検体は、例えば、全血試料、血清試料、血漿試料、ＩＳＦのような他の体液（間質液）および尿、ならびに非体液中のものであってもよい。
【００４１】
試験センサ３１６は、流体試料を受け入れるための流体受け入れ領域を含む。例えば、ユーザは、指または体の他の領域に刺して皮膚表面で血液試料を得るためのランセットまたは穿刺装置を用いてもよい。次いでユーザは、試験センサ３１６を試料と接触させて配置することによって、この血液を採取してもよい。流体受け入れ領域は、試料と反応して試料中の検体濃度を示す試薬を含んでもよい。
【００４２】
試験センサ３１６は、電気化学試験センサであってもよい。電気化学試験センサは、典型的には、複数の電極と、酵素を含む流体受け入れ領域と、を含む。液体受け入れ領域は、電極パターンのコンポーネントによって、流体試料（例えば、血液）中の対象の検体（例えば、グルコース）を、生成される電流の観点から電気化学的に測定可能な化学種に変換するための試薬を含む。試薬は、典型的には、例えば、検体およびフェリシアン化物塩等の電子受容体と反応し、電極によって検出することができる、電気化学的に測定可能な種を生成する、グルコース酸化酵素等の酵素を含む。グルコース脱水素酵素等のグルコースと反応させるために他の酵素が使用され得ることが想定される。一般に、酵素は、流体試料の検体（例えば、検体濃度）に関する情報の判断を支援するために、所望の検体または試験される検体と反応するように選択される。別の検体の濃度を測定する場合、検体と反応させるのに適切な酵素が選択される。
【００４３】
あるいは、試験センサ３１６は、光学試験センサであってもよい。光学試験センサシステムは、例えば、検体濃度を測定するための透過分光法、拡散反射法、または蛍光分光法等の技術を使用してもよい。試薬と検体との間の反応により、試料の色が変化するので、指示試薬システムおよび体液の試料中の検体を反応させて、色反応を生成する。光の変化の度合いが、体液中の検体濃度を示す。試料の色の変化を評価して、透過光の吸収レベルを測定する。
【００４４】
本明細書に説明する実施形態によって使用され得る、いくつかの市販される試験センサとしては、Ｂａｙｅｒ ＨｅａｌｔｈＣａｒｅ ＬＬＣ（Ｔａｒｒｙｔｏｗｎ， Ｎｅｗ Ｙｏｒｋ）から市販されるものが挙げられる。これらの試験センサとしては、Ａｓｃｅｎｓｉａ（登録商標）ＣＯＮＴＯＵＲ（登録商標）血糖監視システム、Ａｓｃｅｎｓｉａ（登録商標）ＢＲＥＥＺＥ（登録商標）およびＢＲＥＥＺＥ（登録商標）２血糖監視システム、ならびにＡｓｃｅｎｓｉａ（登録商標）Ｅｌｉｔｅ（登録商標）およびＥｌｉｔｅ（登録商標）ＸＬ血糖監視システムで使用されるものが挙げられるが、これらに限定されない。上に例示したものに加え、他の試験センサが、本発明の方法およびシステムに組み込まれ得ることが想定される。
【００４５】
図５に示すように、ＢＧＭ３１０は、試験センサ３１６を受け入れ、係合する。ＢＧＭ３１０は、試験センサ３１６によって採取された試料の検体の濃度を測定するための反応検出システムを含む。例えば、反応検出システムは、電気化学試験センサの電気化学反応を検出するための電極との接点を含んでもよい。あるいは、反応検出システムは、光学試験センサの色反応を検出するための光検出器を含んでもよい。反応検出システムによって測定された電気化学反応または色反応から検体の実際の濃度を計算するため、および概して、試料を試験するための手順を制御するために、ＢＧＭ３１０は、測定アルゴリズムに従ってプログラムされた命令を実行し得る少なくとも１つのプロセッサ３１２を用いる。プロセッサ３１２によって処理されたデータは、メモリ３１３に保存されてもよい。さらに、ＢＧＭ３１０は、ディスプレイを含むユーザインタフェース３１５を有してもよく、これは、例えば、液晶ディスプレイであってもよい。また、ユーザがＢＧＭ３１０と対話できるようにするために、押しボタン、スクロールホイール、タッチ画面、またはこれらの任意の組み合わせも、ユーザインタフェース３１５の一部として提供されてもよい。表示部は、典型的には、試験結果に関する情報、試験手順、および／またはユーザによって入力された信号に応答する情報を示す。
【００４６】
ＢＧＭ３１０は、試験結果を保存し、試験結果を表示するためのユーザインタフェース３１５を提供することができるが、演算装置４００上のデータ管理ソフトウェア３７５は、試験結果および関連情報を管理、処理、ならびに表示するためのより高度な機能を提供する。したがって、ＢＧＭ３１０により収集された試験関連データは、データ管理ソフトウェア３７５による使用のために、中央エンジン１１０を介して演算装置３７０に通信され得る。図５に示すように、ＢＧＭ３１０は、エンジンインタフェース要素１１１を介してＢＧＭ３１０が中央エンジン１１０と接続することを可能にする、ＢＧＭインタフェース要素３１１を含む。さらに、中央エンジン１１０はエンジンインタフェース要素１１６に接続されており、一方、エンジンインタフェース要素１１６は演算装置３７０のコンピュータインタフェース要素３７６に接続されている。ＢＧＭインタフェース要素３１１、コンピュータインタフェース要素３７６、ならびにエンジンインタフェース要素１１１および１１６は、装置を適合させ適切なデータ接続を可能とするために、上述のインタフェース技術を使用することができる。例えば、エンジンインタフェース１１１およびＢＧＭインタフェース３１１は、Ｂｌｕｅｔｏｏｔｈ（登録商標）無線を介して接続することができ、一方、エンジンインタフェース１１１は、ＵＳＢポートへの接続によりコンピュータインタフェース３７６に接続することができる。したがって、ＢＧＭ３１０および演算装置３７０は適合するインタフェースを有していない可能性があるが、図５のアーキテクチャは、それらの間でのデータ交換を可能とすることが容易に理解される。さらに、ＢＧＭ３１０の開発は、演算装置３７０のＵＳＢインタフェースとの直接的な適合性にかかわらず達成され得ることもまた、容易に想定される。
【００４７】
前述したように、中央エンジン１１０は、演算装置３７０またはいくつかの他の電源との接続を介して充電可能な電源を含み得る、電源管理部１１４を有する。中央エンジン１１０およびＢＧＭ３１０が接続されると、充電式電池は電力管理部３１４を介して充電され得る。
【００４８】
前述したように、図５中のＢＧＭ３１０は、プログラムされた命令を実行することができる少なくとも１つのプロセッサ３１２を使用する。さらに、ＢＧＭ３１０は、ユーザによる対話を可能とするために、ユーザに情報を提示するディスプレイ、および押しボタン、スクロールホイール、タッチスクリーン、またはこれらの任意の組み合わせを含むユーザインタフェース３１５を有していてもよい。そのようなコンポーネントにより、ＢＧＭ３１０は、試料を試験するための全手順を全般的に制御し、試験結果を計算する。実際には、図５を参照して記載される説明は、ＢＧＭ３１０によりすでに計算された試験結果が、後にどのように演算装置３７０等の他のモジュールと共有され得るかを概説している。しかしながら、中央エンジン１１０のプロセッサ１１２はまたさらに広範な機能を提供し得ることが想定される。事実、健康監視および送達システムにおける処理は、様々な様式で、中央エンジン１１０を含むコンポーネント間に分配され得ることがさらに想定される。
【００４９】
例えば、図６は、実質的にすべての処理を扱う他のコンポーネントを必要とするセンサ受容モジュール３８０を示す。ＢＧＭ３１０と同様に、センサ受容モジュール３８０は、試験センサ３１６を受容するように構成されている。しかしながら、センサ受容モジュール３８０は、試験手順を管理または試験結果を計算するためのプロセッサを有していない。また、センサ受容モジュール３８０は、ユーザと通信するためのユーザインタフェースを有しない。一般に、センサ受容モジュール３８０は、単に試験センサ３１６を受容し、診断システムの残りとの物理的接続のためのインタフェース要素３８１を提供するように設計されている。結果として、試験センサ３１６上の試験試料の分析は、センサ受容モジュール３８０がインタフェース要素３８１を介して試料を分析するためのプロセッサを有する装置と接続した際にのみ可能である。
【００５０】
図６に示すように、センサ受容モジュール３８０のインタフェース要素３８１はインタフェース要素１１１に接続され、一方、インタフェース要素１１１はデジタルセンサ１１０に接続されている。センサ受容モジュール３８０および中央エンジン１１０は、ＵＳＢホスト機能等のホスト機能が中央エンジン１１０により使用されることを必要とし得ることに留意されたい。一実施形態において、デジタルセンサ１１０もまた、演算装置３７０のインタフェース要素３７６に接続されている。センサ受容モジュール３８０、中央エンジン１１０、および演算装置３７０間のインタフェースは、上記ＵＳＢまたはＢｌｕｅｔｏｏｔｈ（登録商標）技術等、いずれのインタフェース技術をも使用することができる。したがって、演算装置３７０は、図５のＢＧＭ３１０上のプロセッサ３１２に類似した様式で、試料を試験し、試験結果を計算するための手順を制御するためにソフトウェア３７７を実行することができる。動作中、センサ受容モジュール３８０、中央エンジン１１０、および演算装置３７０は、図６に示すように接続されている。試験センサ３１６は、血液試料等の流体試料を採取するために使用される。例えば、試験センサ３１６が電気化学試験センサである場合、センサ受容モジュール３８０システムは、試験センサ３１６上で試料と試薬との間で生じる電気化学反応からの電気信号を受信するための電気接点を含み得る。センサ受容要素３８０と中央エンジン１１０との間の接続は、中央エンジン１１０が電気化学反応からの電気信号を受信するように、電気センサを含む回路に接続されている。次いで、計測アルゴリズムを使用して信号を処理しかつ試験結果を決定するために、この信号を演算装置３７０に送ることができる。演算装置３７０上のユーザインタフェースを使用して、試験結果を表示するかまたはユーザからの指示を受けることができる。
【００５１】
他の技術を使用してセンサ受容モジュール３８０からの信号を通信することができることが理解される。例えば、試験センサ３１６は、光学試験センサであってもよく、センサ受容システム３８０は、色反応を検出するための光学検出器を含んでもよい。センサ受容モジュール３８０が試験センサ３１６からの信号を受信または処理するためにいかなる電力でも必要とする場合、中央エンジン１１０との接続により電力を引き出すことができる。
【００５２】
代替として、別の実施形態において、システムに演算装置３７０が使用されていないため、センサ受容モジュール３８０が図７に示すように中央エンジン１１０にのみ接続されている。したがって、試験結果計算は、中央エンジン１１０のプロセッサ１１２により完了され、試験結果は中央エンジン１１０に接続されたユーザインタフェース上に表示される。図７に示すように、ユーザインタフェース１１５は、筐体１０１内に組み込まれてもよい。
【００５３】
試験プロセスを制御し結果を決定するための測定ソフトウェア２５３は、図７に示すような保存装置２５０を介して利用可能となり得る。図４に示すように、保存装置２５０は、別の種類の入力／出力インタフェース２００とやりとりする。保存装置２５０は、ユニバーサルシリアルバス（ＵＳＢ）フラッシュ装置またはメモリカード等のフラッシュ記憶装置であってもよい。ＵＳＢフラッシュ装置は、サムドライブ、ハンディドライブ、フラッシュスティック、またはジャンプドライブとしても知られている。メモリカードは、ＰＣカード（ＰＣＭＣＩＡ）、コンパクトフラッシュ（ＣＦ）、スマートメディア（ＳＭ／ＳＭＣ）、メモリスティック（ＭＳ）、マルチメディアカード（ＭＭＣ）、セキュアデジタル（ＳＤ）、ｘＤピクチャーカード（ｘＤ）、インテリジェントスティック（ｉＳｔｉｃｋ）、エクスプレスカード、またはこれらのいくつかの変形を含む、様々な形式を有し得る。フラッシュ記憶装置は、保存装置２５０に電力が提供されない場合であっても測定ソフトウェア２５３と関連したソフトウェアが保存装置２５０内に維持され得るように、不揮発性メモリを使用することができる。いくつかの実施形態において、保存装置２５０内のメモリは、メモリ上に格納された測定ソフトウェア２５３が直接実行され得るように、ＮＯＲフラッシュメモリ等の直接実行型（ＸＩＰ）メモリを含み得る。また、保存装置２５０は、フロッピーディスクまたは光学ディスク（ＣＤ、ＤＶＤ、Ｂｌｕ−ｒａｙディスク）等の他の保存メディアを使用し得る。
【００５４】
保存装置２５０は、図７に示すように、筐体１０１内で中央エンジン１１０とアセンブルされてもよく、または、外部モジュール（例えばモジュール３００）と類似の様式で中央エンジン１１０に接続されていてもよい。特に後者の場合、保存装置２５０は、通信インタフェース２１０とインタフェースをとり、中央エンジン１１０に接続されていてもよい。インタフェースは、保存装置２５０と中央エンジン１１０との間のデータ通信を可能とし、測定ソフトウェア２５３、またはその他の任意のソフトウェアが中央エンジン１１０と使用されることを許可する。特に、保存装置２５０は、インタフェース要素２１０と適合するインタフェース要素を有する。いくつかの実施形態において、保存装置インタフェース要素は、インタフェース要素２１０と物理的に係合してシリアルハードウェアインタフェースを形成する。例えば、保存装置２５０はＵＳＢフラッシュドライブであってもよく、保存装置インタフェース要素は、中央エンジン１１０に対する通信インタフェース要素２１０として機能するＵＳＢポートに受容されるＵＳＢコネクタであってもよい。
【００５５】
さらなる例として、保存装置２５０は、インタフェース要素として機能する一連の端子を有するセキュアデジタル（ＳＤ）メモリカードであってもよく、通信インタフェース２１０は、メモリカードの端子を受容する拡張スロットであってもよい。この例では、中央エンジン１１０および保存装置２００は、セキュアデジタルＩ／Ｏ（ＳＤＩＯ）インタフェース仕様に適合し得る。異なるインタフェース仕様を有するその他のメモリカード形式が使用し得ることが想定される。しかしながら、ＰＤＡ、ＨＰＣおよび高性能携帯電話等の多くのホストはＳＤＩＯに適合する拡張スロットを含むため、ＳＤＩＯを有することが有利である。
【００５６】
図７の中央エンジン１１０は、図６の例では、演算装置３７０の役割を満たしているため、より高性能の処理装置が必要となり得る。例えば、いくつかの実施形態は、ハンドヘルド型もしくはポケットパーソナルコンピュータ（ＨＰＣ）、適合携帯情報端末（ＰＤＡ）、または高性能携帯電話を使用し得る。上述のように、これらの処理装置は、様々なオペレーティングシステムおよび構成を使用し得る。例えば、演算装置３７０がＰＤＡである場合、オペレーティングシステムは、Ｐａｌｍ， Ｉｎｃ．製ＰＡＬＭ（登録商標）ハンドヘルド機器、またはＲｅｓｅａｒｃｈ ｉｎ Ｍｏｔｉｏｎ Ｌｉｍｉｔｅｄ製Ｂｌａｃｋｂｅｒｒｙ（登録商標）装置のシステムと一致し得る。有利には、ＰＡＬＭ（登録商標）ハンドヘルド機器およびＢｌａｃｋｂｅｒｒｙ（登録商標）装置は、センサ受容モジュール３８０から収集された結果に対し確実に高度データ管理ソフトウェアを実行するために十分な処理力を備えた携帯型装置を提供する。また、そのような装置は、高度グラフィック表示能力を提供する、高機能ユーザインタフェースを提供する。さらに、これらのハンドヘルド型装置は、インターネット等の外部ネットワークに接続するため、新たなソフトウェアまたはソフトウェアアップグレード／パッチを容易にインストールすることができる。さらに、電気通信ネットワークへの接続により、監視または評価のために試験結果が容易に医師および他のヘルスケア専門家に伝送されることが可能となる。多くの消費者はこれらのまたは類似した装置をすでに持ち歩いているため、糖尿病管理システム等の診断システムの多くのユーザは、すでに所有し常に持ち歩いている装置にシステムを便利に組み込むだろう。
【００５７】
実施形態は、異なる種類のハードウェア上に位置し得る多くの異なる種類のモジュール３００を使用し得るため、通信インタフェース２１０は、一般に、２種類以上の通信技術またはプロトコルに対応しなければならない。しかしながら、中央エンジン１１０と様々なモジュール３００との間に最も広範囲の適合性を提供しながら通信インタフェース２１０の数を最小にするために、通信インタフェース２１０は、広く用いられ、標準化されたインタフェース技術、例えばＵＳＢまたはＢｌｕｅｔｏｏｔｈ（登録商標）技術を使用することができる。好ましくは、通信インタフェース２１０は、モジュール３００と中央エンジン１１０との間の通信を確立するために必要な構成の量を最小にする技術を使用する。実際には、ＵＳＢ接続性等のいくつかの通信技術は、プラグアンドプレイ（ＰｎＰ）能力を提供する。これらの実施形態において、モジュール３００は物理的に、例えば従来のＵＳＢポートを介して接続される。次いで、それに応答して、中央エンジン１１０は即座にモジュール３００を認識し、モジュール３００との即座の通信を確立する。
【００５８】
通信インタフェース２１０は、モジュール３００間の通信を提供するだけでなく、外部ネットワークとのセキュアな通信を可能とする。したがって、実施形態は、製品が現場で旧式となった場合、中央エンジンおよび／またはモジュール３００に、ソフトウェアに対する更新、アップグレード、または追加をダウンロードするために、外部ネットワークへの接続を使用することができる。換言すると、実施形態は、フィールドアップグレード可能なソフトウェア機能を提供し得る。有利なことに、実施形態は、製造者または認証された第三者により提供された、またはそれらが購入したプログラムファイルを使用することにより、ユーザが、例えば中央エンジン１１０および／またはモジュール３００用のソフトウェア等、統合システムにおけるあらゆるソフトウェア／ファームウェアを更新できるようにする。ユーザが直接的な援助のために製造者または第三者に連絡することを必要とせずに、既存のシステムソフトウェアをより新しいバージョンで更新もしくはパッチすることができ、または、システムに新しいソフトウェアを追加することができる。新しいソフトウェアにより、ユーザは、システムの機能性をカスタマイズおよび／または拡張することができる。いくつかの場合において、製品は、本質的に新製品に変換され得る。フィールドアップグレードは、すでに製品を購入しているユーザに対し、最新の製品機能を利用可能とする。さらに、フィールドアップグレードは、既存の製品を、他の新たにリリースされた付属品または装置と適合させる。例えば、糖尿病管理システムにおいて、ＢＧＭ３１０が血糖濃度に関して血液を試験するために試験センサを使用し、ＢＧＭ製造者が正確性または試験時間を改善する新たな試験センサを開発する場合、実施形態は、ＢＧＭ３１０が新たな試験センサを認識することができるように、ユーザが装置内のファームウェアをアップグレードすることを可能とする。
【００５９】
中央エンジンは、ダウンロードエンジンと組み合わせてフィールドアップグレード検証の側面を管理することができる。以下でさらに説明するダウンロードエンジンは、外部ネットワーク上の例えばフィールドアップグレードサーバ等のサーバから通信インタフェースを介してシステムコンポーネントを受信し、検証および展開のためにシステムコンポーネントを配信することができる。追加として、または代替として、外部ネットワーク上のサーバは、フィールドアップグレードプロセスの側面を管理することができる。
【００６０】
また、モジュール３００と関連した重要な医学的機能のために、実施形態は、いかなるフィールドアップグレードも製品により保存されているデータまたはソフトウェアを破壊せず、また製品が期待通りに動作し続けるようにするために、新たなソフトウェアまたは構成情報を使用する前に検証手順を使用する。例えば、チェックサムルーチンを使用して、データまたはソフトウェアが完全にダウンロードに成功したか否かを確認することができる。例えば、中央エンジン１１０は、関連したデータ更新ファイル（ＤＵＦ）、またはソフトウェアのダウンロードを確実に成功させる他のコンポーネントに従いダウンロードを検証することができる。さらなるデータセキュリティのために、フィールドアップグレードプロセスは、データ暗号化／復号化を使用することができる。
【００６１】
図９に示した例示的な実施形態において、適切な外部ネットワークにおけるフィールドアップグレードサーバとの接続が確立されると（動作５０２）、既存のシステムコンポーネント、例えばソフトウェアまたは構成情報に対する利用可能なフィールドアップグレードが識別される（動作５０４）。サーバへの接続は、ネットワークへの接続が確立され得た際に自動的にトリガされてもよく、または、ユーザが手動でフィールドアップグレードサーバとの接続を開始してもよい。利用可能なフィールドアップグレードを識別するために、中央エンジンまたはサーバは、バージョン管理プログラムを使用して、フィールドアップグレードサーバ上に保存されたより新しいまたは異なるバージョンと適合し、また置き換え可能なアーキテクチャ内のシステムコンポーネントを決定することができる。次いで新しいシステムコンポーネントが、フィールドアップグレードサーバから、既存のシステムコンポーネントを保存しているメモリ領域とは別個のメモリ、すなわちデータ保存領域にダウンロードされる。メモリの領域は、フィールドアップグレード操作専用に特化され得る。換言すると、少なくとも検証が完了するまで、既存のシステムコンポーネントは削除または上書きされずに保存される。新しいシステムコンポーネントは、システムチェック（動作５０８）で検証され、ダウンロードが成功して、システムが適切に動作している場合、新しいシステムコンポーネントは通常のシステム動作に展開される。したがって、フィールドアップグレードが失敗した場合、システムの旧バージョンがまた利用可能であり、リカバリまたは復元オプションを提供する。新しいシステムコンポーネントは、失敗したフィールドアップグレードとともに除去される。いくつかの実施形態において、新バージョンは、その新バージョンが検証された後にメモリ内の旧バージョンを置き換えることができる。他の実施形態において、１つ以上の旧バージョンが検証後でも保存され、ユーザは、より古いバージョンが好ましい場合には、システムコンポーネントの１つ以上の旧バージョンを復元するオプションを有することができる。
【００６２】
図８を参照して例示的な実施形態を説明する。図８の実施形態において、糖尿病管理システム４００は、流体試料を採取するモジュール４０２、４０３、４０４、および４０５を含み得る。デジタルエンジン４０６は各モジュール、ユーザインタフェース４１３、メモリ４０７、およびダウンロードエンジン４０８を制御する。ダウンロードエンジン４０８は、通信モジュールのうちの１つ、デジタルエンジン４０６、およびメモリ４０７の間のインタフェースを提供する。通信モジュールは、例えば演算装置ＵＳＢポートとシステム４０１との間の通信を提供するＵＳＢインタフェース４０９を含み得る。通信モジュールはまた、システム４００と、演算装置、携帯電話、および／またはシステム４００と通信可能なその他の装置との間の無線通信を提供する、Ｂｌｕｅｔｏｏｔｈインタフェース４１０を含み得る。さらに、Ｗｉ−Ｆｉインタフェース４１１は、無線ネットワークとシステム４００との間の通信を提供する。さらに、イーサネットインタフェース４１１は、ローカルエリアネットワークとシステム４００との間の通信を提供する。各通信モジュールは、ユーザの指示のもとで、現場において測定器のソフトウェアをアップグレード／更新するために使用することができる。ユーザの要求に応じて、新機能のための新しいファームウェア、現在のシステム機能の動作を更新するための新しいファームウェア、ユーザインタフェース言語、画面更新およびカスタマイズ、ゲームおよびその他のスタンドアロン型アプリケーション、ゲージならびにその他のソフトウェアまたは構成設定／更新といった機能もまた、ダウンロードすることができる。
【００６３】
例えば、ユーザインタフェースは、多くの言語で通信することができるが、ユーザがそのシステムの動作をカスタマイズするために必要なときに言語ファイルをダウンロードできるため、それらの言語のために必要なすべてのデータがローカルで保存されている必要はない。また、ユーザは、画面上に表示するカスタム写真をインストールすることにより、または製造者もしくは認証された第三者により利用可能となっている表示レイアウトをダウンロードすることにより、ユーザインタフェース表示の外観をカスタマイズすることができる。さらに、ユーザは、システム４００が体液を分析するために使用されていないときにシステムプロセッサ上で実行および操作可能なスタンドアロン型アプリケーション（ゲーム等）をインストールすることにより、システムの動作をカスタマイズすることができる。また、ユーザは、結果が数値表示、擬似アナログゲージ、定性的フィードバック等として提示され得るように、体液分析結果が表示される様式を変更するソフトウェアをインストールすることにより、システム動作をカスタマイズすることができる。
【００６４】
再び図４を参照すると、入力／出力インタフェース２００はまた、概してモジュール３００に試験結果等の情報をユーザに対し表示させる、ユーザインタフェース２２０を含む。モジュール３００は、通信インタフェース２１０を介してそのような情報を中央エンジン１１０に伝送することができ、一方、中央エンジン１１０は、情報を表示インタフェース２２０上に提示することができる。通信の集中的処理が好ましい場合もあるが、モジュール３００は、ある場合には、表示インタフェース２２０と直接インタフェースをとることができる。図２に示すように、表示インタフェースは、グラフィック液晶ディスプレイ（ＬＣＤ）または有機発光ダイオード（ＯＬＥＤ）、セグメントＬＣＤまたはＯＬＥＤ、ＭＰ４再生等を含み得る。
【００６５】
また、入力／出力インタフェース２００は、音声信号を介して、ユーザへ、およびユーザから情報を通信させることができる。例えば、入力／出力インタフェース２００は、音声情報をユーザに通信するために、音声合成器、ＭＰ３再生等を含み得る。さらに、入力／出力インタフェース２００はまた、ユーザからの音声情報を受信するための音声認識機構を含み得る。
【００６６】
さらに、ユーザインタフェース２００は、ユーザがシステムに情報または命令を入力できるようにし得る。例えば、ユーザは、操作中、モジュール３００のうちの１つをガイドするために、単純なプロンプトに応答するか、またはメニュー選択を行うことが求められるようにすることができる。あるいは、さらなる例として、ユーザは、試験結果等の情報を検索するために命令を入力し、また情報を表示インタフェース２２０上に提示することを求めることができる。例えば、入力を提供するための機構としては、キーパッド、タッチスクリーン、サムホイール等が挙げられる。
【００６７】
図７に示すように、ユーザインタフェース１１５は、中央エンジン１１０および対応する通信インタフェース２１０がアセンブルされる筐体１０１内に組み込むことができる。したがって、筐体１０１は、健康監視および送達システムのための携帯型装置１０１を形成し得る。図３を参照しながら前述したように、ＢＧＭ３１０等のいくつかのモジュール３００を装置内に組み込むことができ、一方ＣＧＭ３２０およびインスリン送達モジュール３３０等の他のモジュールを、通信インタフェース２１０を通して携帯型装置１０１に外部的に接続することができる。デジタルエンジン３１０に接続されたモジュール３００は、インタフェースへのアクセスを有する。
【００６８】
アーキテクチャを使用するシステムは、様々な種類の電子ネットワークおよび通信をサポートする。モジュール３００は、例えば、携帯電話での活動を提供するために使用され得る。他の実施形態は、代替として、または追加として、道路ナビゲーション、人物追跡、および時刻サービス等の民生アプリケーションに広く利用されるようになったグローバルポジショニングシステム（ＧＰＳ）技術を使用することができる。技術がより発達するにつれて、この技術を消費者製品および医療装置に統合するコストが顕著に削減されている。ＧＰＳ受信器チップセットが現在市場で入手可能であり、消費者装置または医療装置と容易に統合して、装置の位置、速度および、標準時間に関する情報を提供することができる。したがって、ＧＰＳは、健康状態の監視および／または薬物の送達のための統合システムを形成するためにアーキテクチャを使用するシステムの機能性を高めるために提供され得る。
【００６９】
ＧＰＳにより、例えば、糖尿病管理システムは、グルコース試験と関連した追加の情報を提供することができる。正確なタイムスタンプおよび位置は、読取値と関連させることができる。従来の測定器により生成される誤ったタイムスタンプは、複数の測定器からの読取値がダウンロードされて１つのデータベースファイルにマージされる際、または測定器と同期した現地時間を有しないコンピュータもしくはウェブサーバにアップロードされる際の、混乱および困難の元であった。患者の動きおよび運動を自動的に追跡することができ、患者のログの労力を大幅に容易にする。データは、距離および速度を含み得る。この情報は、運動、食事、薬物および血糖試験頻度等に関する患者の日々の活動の計画立案に使用することができる。また、これは、読取パターンと日々の活動との間の相関関係の総合的分析も可能とする。さらに、患者は非常事態であり得る。
【００７０】
ＧＰＳで得られる追加の時刻、位置、および物理的活動情報は、記録された食事、薬物情報と組み合わせて、患者の日々の血糖パターンに対するより正確な予測を行うように糖尿病管理システムを支援することができる。糖尿病管理システムは、患者が所定の範囲内で自分の血糖レベルを制御するのを手助けする、日々の活動のリアルタイムな推奨を行うことができる。そのようにして、システムは、毎日正しい時点で正しい数の試験を受けることを患者に思い出させることができる。
【００７１】
したがって、グルコース読取値が正しいタイムスタンプと関連し得るように、ＧＰＳを使用してシステムの装置のリアルタイムクロック（ＲＴＣ）をＵＭＴと高精度で同期させることができる。ＧＰＳ機能性の電力が考慮点となり得るため、ＧＰＳ受信器は、装置の結晶品質に応じて、１日に１度または週に１度だけ起動が必要とされ得る。ＧＰＳが毎回０．１７５ｍＡｈｒの電力（Ｔｒｉｍｂｌｅチップセットを使用するＸｅｍｉｃｓ ＸＥ１６００受信器に基づく計算）を消費し、装置が１日に１度ＧＰＳ計測を行うと仮定すると、ＧＰＳ関連計算のために１年で６３．９ｍＡｈｒが消費され、これは大まかに言って通常の携帯電話の電池容量の約１０〜２０％である。
【００７２】
前述のように、統合監視／送達システムのいくつかの携帯型実施形態は、高度なデータ管理のために演算装置３７０と接続することができる。この状況は、患者の動きおよび活動を追跡するためにＮＡＶＳＹＳ ＧＰＳレコーダモデル（ＴｒａｃｋＴａｇ）を携帯型装置に適用する機会を提供する。ＧＰＳレコーダは、衛生信号の処理を行わずにそのスナップショットを撮るだけであるため、膨大な量の電力を節約することができる。装置がＧＰＳスナップショットを１５０秒に１回撮ると仮定すると、一年でこのＧＰＳレコーダは約２８０ｍＡｈｒしか消費せず、これは大まかに言って、通常の携帯電話の電池容量の約５０％未満である。装置が夜はスナップショットの撮影を停止することができれば、さらなるエネルギーが保存され得る。ＴｒａｃｋＴａｇアプローチの代償は、必要な装置上のメモリの必要量である。どのスナップショットも約１５ｋｂｙｔｅであるため、上記スナップショット速度では、年間約２００，０００スナップショットとなり、約３Ｇｂｙｔｅのメモリが必要である。当然ながら、ＧＰＳデータが装置からコンピュータにダウンロードされ処理されると、装置メモリは解放され再利用され得る。１Ｇｂｙｔｅメモリでは、携帯型装置の位置の追跡が４ヶ月可能と思われる。現代のフラッシュメモリ技術を用いれば、１Ｇｂｙｔｅ装置メモリは、容易に対応され得る。
【００７３】
ＧＰＳ機能性は、組込み型の中心機能となり得る。しかしながら、よりモジュール式の例では、ＧＰＳ機能性は、接続されたモジュール、すなわち取り外し可能なＧＰＳ受信器により提供され得る。実際には、ＧＰＳ受信器モジュールが時間および位置情報を保存するための独自のメモリを有する場合、ＧＰＳは、ＤＭ装置と常に接続されている必要はないことが可能である。ＧＰＳ受信器は、装置クロックが同期されなければならない頻度およびＧＰＳ受信器メモリの利用可能性に応じて、１日に１度または数日に１度、システムと接続され得る。有利には、取り外し可能なＧＰＳ受信器モジュールの使用は、中央エンジン１１０のハードウェア／ソフトウェア設計およびシステムのその他の側面に対する影響を最小にした。さらに、電力管理が容易になる。
【００７４】
本発明は、様々な修正および代替形態が可能であるが、その特定の実施形態および方法を一例として図面に示し、本明細書において詳細に説明してきた。しかしながら、本発明は、開示された特定の形状または方法に限定されるものではなく、また、それとは反対に、本発明の精神および範囲に含まれるすべての修正、均等物、ならびに代替物を対象とすることを意図することが理解されるべきである。
【技術分野】
【０００１】
関連出願の相互参照
本願は、２００７年５月３０日に出願された米国特許仮出願第６０／９３２，２８６号、２００７年１２月１０日に出願された米国特許仮出願第６１／０１２，７２１号、および２００７年１２月１０日に出願された米国特許仮出願第６１／０１２，７１８号の優先権を主張し、これらの内容全体は、参照することによって本明細書に組み込まれる。
【０００２】
技術分野
本発明は、概して、ヘルスケア装置を開発するための方法およびシステムに関する。より具体的には、本発明の方法およびシステムは、健康状態の監視および／または薬物の送達のための統合システムを形成するために容易にアセンブルされる、異なる機能を有するモジュールの任意の組み合わせを可能とするアーキテクチャを提供する。また、該方法およびシステムは、現場での動作中、モジュールが動的に更新されるのを可能とするアーキテクチャを提供する。
【背景技術】
【０００３】
体液中の分析物の定量は、特定の生理的状態の診断および維持において、非常に重要である。例えば、糖尿病を有する個人は、体液中のグルコースレベルを頻繁に調べる。そのような試験の結果は、食事中のグルコース摂取量を調整するため、および／またはインスリンもしくは他の薬物を投与する必要があるかを判断するために使用することができる。
【０００４】
血糖システム等の診断システムは、個人からの血液試料中のグルコース値を計算するために、測定器もしくは機器を用いてもよい。そのような機器は、試料中のグルコースとの反応からの電流または色等の出力を測定することによって動作する。試験結果は、一般的に、測定器によって表示および保存される。基本的なシステムによって、ユーザは、キーパッドまたは他の対話型コンポーネントを介して、測定器から直接試験結果にアクセスすることができる。
【０００５】
しかし、他の診断システムは、ユーザが試験結果を処理および管理できるようにするための、より高度な機能性を提供する。例えば、いくつかのシステムは、ユーザが血糖測定器から従来のデスクトップ型パーソナルコンピュータ（ＰＣ）等の処理装置に試験結果をロードし、データ管理アプリケーションで結果を処理および表示できるようにしている。しかし、血糖測定器からの結果を編成するためにＰＣ技術の処理力を使用することは、診断システムが異なる技術を診断プロセスに組み込むことでより多くの機能性を提供する方法の単なる一例である。
【０００６】
異なる技術および機能の統合によって、極めて高度で非常に有用な診断システムを生み出すことができるが、そのようなシステムの市場への導入は、産業における製品設計および開発に対する現在のアプローチにより遅れている。例えば、多機能製品の設計に対する現在のアプローチは、異なる非標準的技術により様々な機能要素を相互接続する複雑なシステムアーキテクチャを使用する。そのため、機能要素は、特定の最終製品および考慮される他の機能要素とともに開発されなければならない。換言すると、複雑なアーキテクチャは、機能要素間の依存性をもたらし、それにより各要素は、独立して、および／または並行して開発することができない。したがって、より多くのコンポーネントが追加され複雑性が増加するにつれて、開発プロセスはより多くの時間を必要とする。
【０００７】
また、最終統合製品は、様々な技術の特徴および利点を提供し得るが、これらの技術の急速な変化は、特に製品開発がそのように長期間を要するため、最終製品が市場に導入される前に最終製品が旧式となってしまうことがある。換言すると、製品開発に対する現在のアプローチでは、製品のユーザが最新世代の技術を確実に有することが困難である。より多くの機能性のために統合製品のコストが比較的高くなり得るが、消費者は、それらの技術が急速に旧式となり得る場合、そのような製品を購入する理由を見出せなくなる可能性がある。
【０００８】
上記状況を鑑みて、医療装置の高品質基準を満たしながら異なる技術的コンポーネントを単一製品に統合するプロセスを単純化する設計および開発アプローチの必要性がある。特に、コンポーネント間のインタフェースを単純化し、したがって、コンポーネントの数にかかわらず、コンポーネントの異なる組み合わせが容易かつ確実に統合され得るようにするアプローチの必要性がある。さらに、ユーザに最新の技術を提供するために、最終製品が動的に、また継続的に更新され得るようにするアプローチの必要性がある。
【発明の概要】
【０００９】
本明細書に記載の実施形態は、個々のシステムコンポーネントを個別に、すなわち異なるモジュールとして開発および試験し、後に標準化された電気および通信インタフェースにより統合することを可能とするアーキテクチャを提供することにより、上で特定された必要性に対応する。これらのモジュールを任意に組み合わせて、健康状態の監視および／または薬物の送達のための統合システム等、任意の数の機能を提供する異なる製品を形成することができる。
【００１０】
アーキテクチャは、製品の開発サイクルを短縮化し、製品をより迅速に消費者に紹介することを可能とするが、実施形態はまた、ユーザがすでに製品を購入した後でも、製品を動的に更新し、ユーザに最新世代の技術を提供するためのアプローチを提供する。特に、実施形態は、製品が現場で旧式となった場合、製品のソフトウェアを更新しアップグレードすることができる遠隔ネットワークへの接続を提供するためにも、通信インタフェースを使用する。このプロセスは、フィールドアップグレードとして知られている。
【００１１】
インタフェースおよび通信プロトコルは、異なるコンポーネントとシステムの残りとの間の接続を容易にするように設計されているため、実施形態はまた、不正な個人または装置がシステムに接続して、システムにより収集、保存、処理され得る個人の医療情報等のデータのセキュリティを侵害することができないようにする機能性も提供する。この基礎を成すセキュリティ機能性により、個人情報への不正なアクセスに関する懸念を必要とすることなく、無線通信などの特定の技術を医療診断システムのコンポーネントとして実装することができる。
【００１２】
さらに、アセンブルされた製品と関連した重要な医学的機能のために、実施形態は、例えばフィールドアップグレード中に製品に転送された任意のデータが、製品により保存されているデータまたはソフトウェアを破壊せず、また製品が期待通りに動作し続けるように、検証手順を使用する。
【００１３】
本発明のさらに他の態様、機能、および利点は、本発明を実施するために想定される最良の形態を含む、数多くの例示的な実施形態および実施を説明することによって、以下の詳細な説明から容易に理解できるであろう。また、本発明は、他の実施形態、および異なる実施形態も可能であり、そのいくつかの詳細は、すべて本発明の精神および範囲から逸脱することなく、様々な点において修正することができる。したがって、図面および説明は、本質的に説明のためのものであって、制限的なものではないと見なされる。本発明は、本発明の精神および範囲に入るすべての修正、均等物、および代替物を対象とする。
【図面の簡単な説明】
【００１４】
【図１Ａ】本発明の態様によるアーキテクチャの図である。
【図１Ｂ】本発明の態様による別のアーキテクチャの図である。
【図２Ａ】本発明の態様によるアーキテクチャにより使用され得る例示的なセキュリティ対策を示す図である。
【図２Ｂ】本発明の態様によるアーキテクチャにより使用され得る別の例示的なセキュリティ対策を示す図である。
【図２Ｃ】本発明の態様によるアーキテクチャにより使用され得るさらなる例示的なセキュリティ対策を示す図である。
【図２Ｄ】本発明の態様によるアーキテクチャにより使用され得るさらに別の例示的なセキュリティ対策を示す図である。
【図３】本発明の態様によるアーキテクチャを使用する例示的な糖尿病管理システムの図である。
【図４】本発明の態様によるアーキテクチャの別の図である。
【図５】本発明の態様によるアーキテクチャを使用する診断システムの例である。
【図６】本発明の態様によるアーキテクチャを使用する診断システムの別の例である。
【図７】本発明の態様によるアーキテクチャを使用する診断システムのさらに別の例である。
【図８】本発明の態様によるフィールドアップグレード可能なアーキテクチャを示す。
【図９】本発明の態様によるフィールドアップグレードの使用例である。
【００１５】
例示的な実施形態の説明
本明細書に記載の実施形態は、個々のシステムコンポーネントまたはモジュールが、（異なるモジュールとして）独立して開発および検証され、後に標準化された電気および通信インタフェースにより統合されることを可能とするシステムアーキテクチャを提供する。標準化されたインタフェースは、任意の数の機能を提供する異なる製品を形成するためのこれらのモジュールの組み合わせおよび構成を容易にする。アーキテクチャは、コンポーネントの固定された組み合わせを形成するために使用することができるが、アプローチは、異なるコンポーネントを容易に除去またはシステムに追加し得る、再構成可能または拡張可能な組み合わせも可能とする。さらに、以下にさらに説明するように、アーキテクチャは、モジュールが製品内に統合された後に、モジュールを動的に更新するためのアプローチを提供する。
【００１６】
図１Ａは、本発明の態様によるモジュールアーキテクチャの概念図である。図１Ａに示すように、モジュールアーキテクチャシステム１は、それぞれ健康監視および送達システムの機能性を提供する複数のモジュール３０Ａ、３０Ｂ、３０Ｃ、および３０Ｄに接続された中央エンジン１０を含む。中央エンジン１０は、モジュール３０Ａ、３０Ｂ、３０Ｃ、および３０Ｄを効果的なシステムとして機能させることができる。例えば、中央エンジン１０は、モジュール３０Ａ、３０Ｂ、３０Ｃ、および３０Ｄ間での情報の通信を可能にする。例えば、モジュール３０Ｄは、中央エンジン１０を介して他のモジュール３０Ａ、３０Ｂ、および３０Ｃから受信したデータを処理するソフトウェアを有するコンピュータ装置であってもよい。図１Ａにさらに示すように、中央エンジン１０のインタフェース要素２２Ａ、２２Ｂ、２２Ｃ、および２２Ｄは、それぞれのインタフェース要素２４Ａ、２４Ｂ、２４Ｃ、および２４Ｄに接続して、中央エンジン１０とモジュール３０Ａ、３０Ｂ、３０Ｃ、および３０Ｄとの間の通信を確立する。インタフェースは、有線、すなわち物理的な通信、および／または無線通信を提供し得る。有利なことには、インタフェースアーキテクチャの集中型編成は、互いに別個に開発および試験され得るモジュール３０Ａ、３０Ｂ、３０Ｃ、および３０Ｄの統合を容易にする。さらに、中央エンジン１０のインタフェース要素２２Ａ、２２Ｂ、２２Ｃ、および２２Ｄは、同じ通信プロトコルに従う必要はないが、インタフェース要素２２Ａ、２２Ｂ、２２Ｃ、および２２Ｄは、中央エンジン１０が所与のモジュールとの適合性をより有し得るように、最も広く用いられている標準プロトコルを使用することができる。
【００１７】
図１Ａのモジュール３０Ａ、３０Ｂ、３０Ｃ、および３０Ｄはすべて、互いに情報を通信することができるが、中央エンジン１０に接続されたモジュールはその他のモジュールのすべてと通信する必要はないことが想定される。実際には、モジュールは、任意の他のモジュール（すべてのモジュールを含む）から通信可能に隔離してもよい。例えば、特定のモジュール上のデータおよび／またはソフトウェアの性質は、極めて敏感となり得るため、モジュールはデータのセキュリティおよび／または完全性を高めるために他のモジュールから隔離してもよい。
【００１８】
一実施形態において、中央エンジン１０は、マザーボード上に実装され、各モジュールは、ドーターボード上に別個に実装される。ドーターボードは、システムに統合される単一のマザーボードに接続し得るように標準化されている。換言すると、他のモジュールに対応するボードとの特定のインタフェースを、新たなモジュールが実装されるたびに開発する必要はない。この標準化されたアプローチにより、市販の既製（ＣＯＴＳ）ハードウェアをマザーボードおよびドーターボードに使用することがより実行可能となる。有利なことには、ＣＯＴＳハードウェアの使用は、特定用途向け集積回路（ＡＳＩＣ）アプローチよりも必要な開発時間が短い。
【００１９】
いくつかの実施形態において、マザーボードおよびドーターボードは、物理的に、別個の回路基板上に存在し得る。他の実施形態において、マザーボードおよびドーターボードは、同じ回路基板上に全て物理的に統合され得る。さらなる実施形態において、マザーボードおよびドーターボードの組み合わせは、同じ回路基板上に物理的に統合され得るが、他のドーターボードは別個の回路基板上に存在する。さらに、いくつかの実施形態において、マザーボードおよびドーターボードは、同じ回路基板上か否かにかかわらず、すべて同じ筐体またはケース内に配置され得る。一方、他の実施形態において、ドーターボードの一部またはすべてが、マザーボードの筐体とは別個の１つ以上の筐体内に配置され得る。一般に、実施形態のコンポーネントは、異なる回路基板上、または異なる筐体内等のアセンブリに関し、様々な程度の物理的統合がなされ得る。物理的構成におけるこの変化に対応するため、ドーターボードをマザーボードに接続するために２つ以上のインタフェース型が必要となることもあるが、上述したように、中央エンジンとモジュールとの間のインタフェースは、同じ通信プロトコルに従う必要はない。マザーボードと関連したインタフェース要素は、中央エンジンが所与のモジュールと適合性をより有し得るように、最も広く用いられている標準プロトコルを使用することができる。
【００２０】
標準化されたインタフェースを使用した集中型アーキテクチャは、適合モジュールの開発を容易にする。システムに機能性を追加する際、アーキテクチャとの統合は、適合インタフェース要素を使用することによって容易に達成される。さらに、新しいモジュールは、中央エンジン１０とのインタフェースが１つだけ必要となるため、他のモジュールと独立して開発することができる。換言すると、新たなモジュールがシステム内の他のモジュールと通信しなければならない場合でも、新たなモジュールは他のモジュールと直接接続するように設計される必要がないため、他のモジュールの通信構成は新たなモジュールの重要な設計上の考慮点とはならない。したがって、中央エンジン１０と容易に接続する追加のモジュールを独立して開発する能力により、このアーキテクチャを使用するシステムは柔軟で再構成可能となり得る。例えば、そのようなシステムは、新たなモジュールで拡張され得るか、または既存のモジュールの新たなバージョンでアップグレードされ得る。
【００２１】
図１Ａは、モジュール３０Ａ、３０Ｂ、３０Ｃ、および３０Ｄに接続された単一の中央エンジン１０を有する実施形態を示すが、いくつかの実施形態において、中央エンジン１０はまた、図１Ｂに示すように、副中央エンジン４０に接続されていてもよい。図１Ｂに示すように、中央エンジン１０は、対応するインタフェース要素２２Ａ／２４Ａ、２２Ｂ／２４Ｂ、および２２Ｃ／２４Ｃを介して、モジュール３０Ａ、３０Ｂ、および３０Ｃに接続されている。一方、中央エンジン４０は、対応するインタフェース要素５２Ａ／５４Ａ、５２Ｂ／５４Ｂ、および５２Ｃ／５４Ｃを介して、モジュール６０Ａ、６０Ｂ、および６０Ｃに接続されている。モジュール３０Ａ、３０Ｂ、および３０Ｃと同様に、モジュール６０Ａ、６０Ｂ、および６０Ｃは、中央エンジン４０との単一のインタフェースのみを必要とするモジュールアーキテクチャに従い、他のモジュールから独立して開発され得る。図１Ｂにさらに示すように、中央エンジン１０は、インタフェース要素２２Ｄおよび５２Ｄを介して中央エンジン４０に接続され得る。他のインタフェース要素と同様に、インタフェース要素２２Ｄおよび５２Ｄは、有線、すなわち物理的な通信、または無線通信を提供し得る。いくつかの実施形態において、中央エンジン１０は、中央エンジン４０のホスト機能を担う。例えば、ユニバーサルシリアルバス（ＵＳＢ）通信プロトコルに従い中央エンジン１０が中央エンジン４０と接続する場合、標準ＵＳＢは、２つのシステム間のホスト−スレーブ関係を必要とする。
【００２２】
図１Ｂの実施形態において、中央エンジン１０は、モジュール６０Ａ、６０Ｂ、および６０Ｃにより提供される機能性にアクセスすることができ、逆に、中央エンジン４０は、モジュール３０Ａ、３０Ｂ、および３０Ｃにより提供される機能性にアクセスすることができる。得られる組み合わせが、６つのモジュール３０Ａ、３０Ｂ、３０Ｃ、６０Ａ、６０Ｂ、および６０Ｃに接続された単一の中央エンジンのように機能し得るにもかかわらず、中央エンジン１０および４０は、別個に開発され得る。したがって、モジュールのセットの開発は、別個のサブセットに有利に編成することができる。例えば、医療診断システムは、血糖測定器等の重要な医療装置だけでなく、心拍数モニタ等のその他の種類の装置も含んでいてもよい。重要な医療装置は、開発中、非常に厳しい製品検証を必要とし、また政府規制の対象となり得る。一方、他の種類の装置は、同じ種類または同じレベルの検証を必要としない可能性がある。したがって、重要な医療装置に関与するモジュールは、他の種類のヘルスケア装置と比較して、製品開発において非常に異なるスケジュールおよびガイドラインを有し得る。したがって、この場合、モジュールを２つの製品開発グループに編成することが有利となり得る。また、新たな機能を含めるために重要な医療装置に関与する製品が再開発または更新される度に、政府規制は、その新たな特徴が比較的重要となり得ない場合にも、製品の再検証を要求し得る。例えば、すでに血糖測定器に接続されている中央エンジンに心拍数モニタが追加される場合、新たなモジュールが比較的重要でないヘルスケア装置であっても、多額のコストおよび労力を投じてシステム全体が再検証されなければならない場合がある。しかしながら、心拍数モニタに接続される副中央エンジンに接続する能力を中央エンジンがすでに有している場合、血糖測定器に接続された中央エンジンは変更されないままとなり得る。換言すると、副中央エンジンにより他のヘルスケア装置および他の特徴に関与する新たなモジュールを展開することは、主中央エンジンと関連したアーキテクチャを変更することなく製品全体を拡張する手法を提供する。さらに、副中央エンジンと関連したアーキテクチャのいかなる検証も、主中央エンジンと関連したアーキテクチャに影響を与えることなく行うことができる。
【００２３】
本明細書に記載のアーキテクチャの利点は、新たなモジュールがシステムとインタフェースをとって通信およびデータ交換を確立することができる容易性であるが、個人医療データのセキュリティに関する問題は、健康データを測定および保存する個人試験装置等の医療装置との適合性が高い通信技術の使用を妨げている。これらの問題に対処するために、本発明の態様による実施形態は、不正な個人または装置がシステムに接続していかなる個人医療情報のセキュリティも侵害できないようにするための一助となる機能性を提供する。中央エンジン１０は、セキュリティ対策を提供する機能を有してもよい。代替として、または追加として、特殊なセキュリティ機能を有するコンポーネントまたはモジュールを使用してシステムセキュリティを強化してもよい。そのようなセキュリティ機能性により、個人情報への不正アクセスに関する懸念を高めることなく、無線通信などの特定の技術を医療診断システムのコンポーネントとして実装することができる。
【００２４】
図２Ａ〜Ｄは、本発明の態様によるアーキテクチャにより使用され得るセキュリティ技術の例を示す。図２Ａに示すように、モジュール３０が中央エンジン１０とインタフェースをとるか、またはシステムを通してデータにアクセスしようとする際に、中央エンジン１０は、ユーザにユーザＩＤおよびパスワード、個人識別番号（ＰＩＮ）、または他の認証情報をプロンプトしてもよい。モジュール３０は、セキュリティプロンプトに対する応答がシステムに保存された認証情報に一致する場合、接続またはデータアクセスを唯一許可される。例えば、モジュール３０は、中央エンジン１０に接続された血糖測定器からの試験データをアップロードするデータ管理プログラムを実行するＰＣであってもよい。プログラムがインタフェース接続を介した通信を試みるか、データへのアクセスを試みる際、ユーザはユーザＩＤおよびパスワードをサブミットしなければならない。認証情報は、ＰＣまたは中央エンジン１０上のユーザインタフェース、例えばキーパッドまたはキーボードにより入力することができる。中央エンジン１０を通してデータにアクセスするためにモジュール３０が頻繁に使用される場合、ユーザは、繰り返し認証情報を入力するのを不便と感じる可能性がある。したがって、いくつかの実施形態は、ユーザが特定のモジュール３０からの認証間の期間を（ゼロから無限に）設定できるようにすることができる。中央エンジン１０は、期間を追跡するために、モジュール３０の一意の識別子、例えば装置ＩＤを記録する。例えば、最後の認証から特定の時間、例えば１日が経過した場合、セキュリティプロンプトが必要となり得る。代替として、ユーザは、第１の認証後、すべてのさらなるセキュリティプロンプトを生じさせないようにすることができる。この代替例の場合、第１の認証は、モジュール３０からのその後のすべてのアクセスを許可するための中央エンジン１０への登録として機能する。
【００２５】
図２Ｂに示すように、モジュール３０の一意の識別子、例えば装置ＩＤを中央エンジン１０に登録してもよい。この一意の識別子は、ユーザにより入力されるか、または、図２Ａに示す認証プロセスが初めて完了した際に記録され得る。代替として、モジュール３０の登録は、初期設定の、例えば出荷時設定のプロセスを通して達成され得る。この代替例の場合、初期設定後に追加のモジュールの登録を禁止し、それによりシステム中のモジュールの数を固定してもよい。モジュール３０が後にデータに接続またはアクセスしようとすると、中央エンジン１０は自動的にモジュール３０を認識してアクセスを許可する。
【００２６】
図２Ａおよび２Ｂの実施形態において、モジュール３０は、一方向プロセスで認証または登録される。換言すると、中央エンジン１０は、モジュール３０によって認証されるかまたは登録される必要はない。対照的に、図２Ｃに示すように、中央エンジン１０およびモジュール３０の両方が、互いに登録を必要とする。中央エンジン１０とモジュール３０との間に任意の通信が発生する前に、そのペアのための一意の識別子の整合が必要である。このペア整合は、２つの装置間の無線通信に特に適用することができる。プロセスは恣意的な不正アクセスを防止し、また２つの異なるシステム間の干渉も防止する。例えば、ユーザがある環境、例えば病院または診療所内におり、他の者が類似の無線検体試験装置、例えば血糖測定器等を使用している場合、ペア整合は、別の者の血糖測定器が誤ってユーザの診断システムと通信して間違ったデータを提供するのを防止する。
【００２７】
データセキュリティは、図２Ｄに示すように、通信中に暗号化データを使用することによって強化してもよい。これはまた、いかなる傍受されたデータも読み取り不可能となるように、無線通信に特に適用することができる。データ暗号化は、秘密暗号鍵を使用して達成され得る。
【００２８】
データセキュリティは、中央エンジン１０によりすべてのデータがアーキテクチャのメモリ内に格納され、接続されたいかなるモジュールにも転送されないようにすることにより、さらに強化することができる。したがって、ユーザは、例えば、公共のコンピュータを使用してシステムとインタフェースをとることができるが、他者がアクセスする公共のコンピュータにはデータが転送されない。
【００２９】
図３は、本明細書に記載のアーキテクチャアプローチから形成され得る糖尿病管理システム１００の限定されない例を示す。糖尿病管理システム１００は、血糖濃度および／または他の対象の検体の測定値の監視および記録に盛んに関わる個人に有利である。
【００３０】
図３に示すように、糖尿病管理システム１００は、血糖測定器（ＢＧＭ）３１０、連続グルコース監視（ＣＧＭ）モジュール３２０、インスリン送達装置３３０、および、演算装置３７０を含み、演算装置３７０は、糖尿病管理ソフトウェア３７５を含み得る。モジュール３１０、３２０、３３０、および３７０は、以下にさらに説明するように、本明細書に記載のアーキテクチャアプローチを使用して統合され、糖尿病管理システム１００に健康監視および送達機能を提供する。特に、ＢＧＭ３１０は、血液試料中の血糖濃度のポイントインタイムの測定を提供し、ＣＧＭモジュール３２０は、血糖濃度の連続測定を提供し、インスリン送達装置３３０は、ユーザにインスリンを送達する。
【００３１】
また、演算装置３７０は、ソフトウェア３７５を実行してモジュール３１０、３２０、および３３０からデータを受信し、高度なデータ処理および管理能力を提供する。演算装置３７０は、デスクトップ型またはラップトップ型パーソナルコンピュータ（ＰＣ）、ハンドヘルド型またはポケットパーソナルコンピュータ（ＨＰＣ）、互換性のある携帯情報端末（ＰＤＡ）、および高性能携帯電話等の様々な処理装置から選択され得る。処理装置は、様々なオペレーティングシステムおよび構成を使用し得る。例えば、演算装置３７０が、デスクトップ型またはラップトップ型パーソナルコンピュータである場合、オペレーティングシステムは、あるバージョンのＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）であってもよい。あるいは、演算装置３７０がＰＤＡである場合、オペレーティングシステムは、Ｐａｌｍ， Ｉｎｃ．，のＰＡＬＭ（登録商標）ハンドヘルド、またはＲｅｓｅａｒｃｈ ｉｎ Ｍｏｔｉｏｎ ＬｉｍｉｔｅｄのＢｌａｃｋｂｅｒｒｙ（登録商標）装置に対応してもよい。一般に、演算装置３７０は、任意の数のプログラムされた命令を受信および実行することができるプロセッサを含む。
【００３２】
演算装置３７０上のデータ管理ソフトウェア３７５は、例えば、モジュール３１０および３２０によって測定されるデータを受信および処理するプログラムもしくはコンピュータコードの集まりであってもよい。ソフトウェア３７５は、ユーザが所望する方法で、この入力を処理および／または表示する。この情報は、例えば、ユーザ、在宅医療提供者（ＨＣＰ）、および／または医師によって使用されてもよい。モジュール３１０および３２０からの測定データは、例えば、人の血液もしくは他の体液中のグルコースおよび／または他の検体の濃度を含み得る。有利なことには、ソフトウェア３７５は、１日に何度も（例えば、１日に約６回〜約１０回）試験するユーザによって要求され得る、高度な表示およびデータ処理を提供することができる。例えば、ソフトウェア３７５は、Ｂａｙｅｒ ＨｅａｌｔｈＣａｒｅ ＬＬＣ（Ｔａｒｒｙｔｏｗｎ， Ｎｅｗ Ｙｏｒｋ）から入手可能なＷＩＮＧＬＵＣＯＦＡＣＴＳ（登録商標）糖尿病管理ソフトウェアと類似する製品を含んでもよい。そのため、ソフトウェア３７５は、血糖測定システムから試験結果を受信および保存し、試験回数および食事指標等の他の試験情報を受信および保存し、電子ログブックに試験結果を追跡記録し、平均を計算して異常値の試験結果の統計分析を提供し、試験結果を要約してフィードバックを提供し、カスタマイズ可能なグラフィカルユーザインタフェースを提供し、試験結果の分かりやすいチャートおよびグラフを表示し、ユーザ固有の目標範囲に対する試験結果を追跡記録し、予測分析を提供しかつ／またはファックス、電子メール等を介してデータをヘルスケア専門家に送信する、完全なツールキットを提供し得る。前述のように、ソフトウェア３７５がモジュール３１０および３２０から演算装置３７０にデータをアップロードせず、データが常に単一の中央保存装置内に格納されれば、セキュリティが強化される。
【００３３】
以下でさらに説明するように、ソフトウェアまたはプログラムされた命令の使用は、演算装置３７０に限定されない。さらに、本発明の実施形態の使用は、特定のモジュール３１０、３２０、３３０、および３７０を使用していない。図４は、他のモジュール３００を備えたより広範なシステム図である。例えば、図４に示すように、経時的にグルコース調節を監視するＡ１Ｃモジュール３４０は、糖尿病管理システム内でも使用され得る。モジュール３００はまた、血圧および心拍数モニタ等の他の健康監視モジュール３５０を含む。実際には、モジュール３００は、体温測定、血圧測定、心拍数測定、慢性閉塞性肺疾患（ＣＯＰＤ）の分析のための呼吸測定、ラシックス（Ｌａｓｉｘ）使用を分析するための体重測定等の検体試験を必要としない健康データを測定および／または記録し得る。さらなるシステムにおいて、他の実用的な装置モジュール３６０は、トレーニングモジュール、他のシステムへのさらなる接続を提供する接続性モジュール、およびユーザのシステム体験を向上または強化する他のモジュールを含み得る。例えば、ゲームモジュールまたは音楽プレーヤモジュール等の娯楽またはメディアモジュールを、本明細書に記載のシステムと組み合わせることが想定される。例えば、娯楽機能の提供は、糖尿病等の健康状態を定期的に監視できるように、患者、特に若い患者が、どこに行こうとも診断システムを携帯することを促すことができる。さらに、いくつかのシステムにおいて、アーキテクチャはまた、本発明に記載のアーキテクチャに統合される追加のカスタムまたは特殊モジュールがユーザまたは第三者により開発され得るように、オープンソースコードを用いることができる。したがって、あらゆる種類の機能性を提供する無限の様々なモジュールが使用され得る。
【００３４】
図３に示すように、システム１００は、アーキテクチャのための中央エンジン１１０、例えばデジタルエンジンを含み、モジュール３００が容易かつ効果的に組み合わせられ得るようにする。例えば、中央エンジン１１０、ＢＧＭ３１０、ＣＧＭモジュール３２０、およびインスリン送達装置３３０を効果的に組み合わせて、人工膵臓を創出することができる。代替として、中央エンジン１１０、ＢＧＭ３１０、およびＣＧＭ３２０を組み合わせて、内蔵ＢＧＭユニットを備えるＣＧＭを形成することができる。あるいは、さらなる例として、中央エンジン１１０、ＢＧＭ３１０、およびインスリン送達装置３３０を組み合わせて、内蔵ＢＧＭユニットを備えるポンプ制御器を形成することができる。
【００３５】
再び図４を参照すると、中央エンジン１１０は、プロセッサ１１２および電力管理要素１１４を含み得る。プロセッサ１１２は、任意の数のプログラムされた命令を受信および実行することができ、マイクロコントローラ、マイクロプロセッサ、デジタル信号プロセッサ等であってよい。プロセッサ１１２により実行されるプログラムされた命令は、内蔵されていても、保存装置２５０、接続されたモジュール３００、またはインターネットウェブサイト等の別のソースから読み出し可能であってもよい。プロセッサ１１２は、モジュール３００との通信を一元的に管理する。いくつかの場合において、プロセッサ１１２はまた、いくつかのモジュール３００の動作を処理するソフトウェアを実行し得る。さらに、プロセッサ１１２は、モジュール３００に、以下にさらに説明するユーザインタフェース２２０等の共通リソースまたは機能へのアクセスを提供してもよい。
【００３６】
電力管理要素１２０は、電源から、プロセッサ１１２および独自の電源を有しないモジュール３００に電力を分配する。電力管理システム１１４は、例えば、システムがアイドル状態である場合に電力消費を最小にするためにスタンバイモードに入るように構成され得る。さらに、充電式電池を用いる場合には、電力管理システム１１４は、電池の充電にも対処することができる。
【００３７】
また図４に示すように、中央エンジン１１０は、通信インタフェース２１０およびユーザインタフェース２２０という２つの異なるカテゴリに分けることができる入力／出力インタフェース２００に接続されている。通信インタフェース２１０は、中央エンジン１１０とモジュール３００との間のデータの交換を統御する。一般に、通信インタフェース２１０は、有線および／または無線通信に対応することができる。有線通信は、例えば、ユニバーサルシリアルバス（ＵＳＢ）接続による通信を含む。無線通信としては、例えば、無線周波数（ＲＦ）リンク（例えば短距離ＲＦテレメトリ等）、赤外線（ＩＲ）リンク、および／またはＷｉ−Ｆｉが挙げられる。いくつかの既知のＲＦ技術としては、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）無線技術、Ｚｉｇｂｅｅ、Ｚ−Ｓｅｎｓｅ（登録商標）技術、ＦｉｔＳｅｎｓｅ、およびＢｏｄｙＬＡＮ（登録商標）システムが挙げられる。他の通信技術またはプロトコルを使用してもよいことが理解される。
【００３８】
再び図３を参照すると、有線または物理的接続２１２が、中央エンジン１１０と演算装置３７０との間に存在し、一方、無線接続２１４が、中央エンジン１１０とＣＧＭモジュール３２０およびインスリン送達装置３３０との各間に存在する。ＢＧＭ３１０は筐体１０１内で中央エンジン１１０とアセンブルされていることに留意されたい。したがって、中央エンジン１１０とＢＧＭ３１０との間のインタフェースは、有線接続（図示せず）を伴う。実際には、図３に示すように、モジュール３００は、中央エンジン１１０およびその他のモジュール３００に対して任意の好適な配置で組み合わせることができる。ＢＧＭ３１０と同様に、同じ筐体内で中央エンジン１１０とアセンブルされ得るモジュール３００もあれば、別個の筐体内に設けられ、中央エンジン１１０から遠隔に配置され得るモジュール３００もある。また、本明細書に記載の他の構成に加えて、例えば、回路コンポーネントの形態を有するいくつかのモジュール３００は、中央エンジン１１０の回路コンポーネントとして、同じプリント基板アセンブリ（ＰＣＢＡ）上で、インタフェース２１０を提供する回路接続によりアセンブルされてもよい。
【００３９】
図５は、中央エンジン１１０とモジュール３００、つまりＢＧＭ３１０との間の接続のさらなる例を示す。図３とは異なり、図５のＢＧＭ３１０は、中央エンジン１１０とともに筐体１０１内に配置されていないが、図５を参照して記載される説明は、図３の構成にも同等に適用することができる。
【００４０】
図５を参照すると、試験センサ３１６を有するＢＧＭ３１０が示されている。試験センサ３１６は、ＢＧＭ３１０を使用して分析される流体試料を受け入れるように構成されている。分析され得る検体は、グルコース、脂質状態（例えば、コレステロール、トリグリセリド、ＬＤＬ、およびＨＤＬ）、微量アルブミン、ヘモグロビンＡ１Ｃ、フルクトース、乳酸塩、またはビリルビンを含む。他の検体情報（例えば検体濃度）もまた決定し得ることが想定される。検体は、例えば、全血試料、血清試料、血漿試料、ＩＳＦのような他の体液（間質液）および尿、ならびに非体液中のものであってもよい。
【００４１】
試験センサ３１６は、流体試料を受け入れるための流体受け入れ領域を含む。例えば、ユーザは、指または体の他の領域に刺して皮膚表面で血液試料を得るためのランセットまたは穿刺装置を用いてもよい。次いでユーザは、試験センサ３１６を試料と接触させて配置することによって、この血液を採取してもよい。流体受け入れ領域は、試料と反応して試料中の検体濃度を示す試薬を含んでもよい。
【００４２】
試験センサ３１６は、電気化学試験センサであってもよい。電気化学試験センサは、典型的には、複数の電極と、酵素を含む流体受け入れ領域と、を含む。液体受け入れ領域は、電極パターンのコンポーネントによって、流体試料（例えば、血液）中の対象の検体（例えば、グルコース）を、生成される電流の観点から電気化学的に測定可能な化学種に変換するための試薬を含む。試薬は、典型的には、例えば、検体およびフェリシアン化物塩等の電子受容体と反応し、電極によって検出することができる、電気化学的に測定可能な種を生成する、グルコース酸化酵素等の酵素を含む。グルコース脱水素酵素等のグルコースと反応させるために他の酵素が使用され得ることが想定される。一般に、酵素は、流体試料の検体（例えば、検体濃度）に関する情報の判断を支援するために、所望の検体または試験される検体と反応するように選択される。別の検体の濃度を測定する場合、検体と反応させるのに適切な酵素が選択される。
【００４３】
あるいは、試験センサ３１６は、光学試験センサであってもよい。光学試験センサシステムは、例えば、検体濃度を測定するための透過分光法、拡散反射法、または蛍光分光法等の技術を使用してもよい。試薬と検体との間の反応により、試料の色が変化するので、指示試薬システムおよび体液の試料中の検体を反応させて、色反応を生成する。光の変化の度合いが、体液中の検体濃度を示す。試料の色の変化を評価して、透過光の吸収レベルを測定する。
【００４４】
本明細書に説明する実施形態によって使用され得る、いくつかの市販される試験センサとしては、Ｂａｙｅｒ ＨｅａｌｔｈＣａｒｅ ＬＬＣ（Ｔａｒｒｙｔｏｗｎ， Ｎｅｗ Ｙｏｒｋ）から市販されるものが挙げられる。これらの試験センサとしては、Ａｓｃｅｎｓｉａ（登録商標）ＣＯＮＴＯＵＲ（登録商標）血糖監視システム、Ａｓｃｅｎｓｉａ（登録商標）ＢＲＥＥＺＥ（登録商標）およびＢＲＥＥＺＥ（登録商標）２血糖監視システム、ならびにＡｓｃｅｎｓｉａ（登録商標）Ｅｌｉｔｅ（登録商標）およびＥｌｉｔｅ（登録商標）ＸＬ血糖監視システムで使用されるものが挙げられるが、これらに限定されない。上に例示したものに加え、他の試験センサが、本発明の方法およびシステムに組み込まれ得ることが想定される。
【００４５】
図５に示すように、ＢＧＭ３１０は、試験センサ３１６を受け入れ、係合する。ＢＧＭ３１０は、試験センサ３１６によって採取された試料の検体の濃度を測定するための反応検出システムを含む。例えば、反応検出システムは、電気化学試験センサの電気化学反応を検出するための電極との接点を含んでもよい。あるいは、反応検出システムは、光学試験センサの色反応を検出するための光検出器を含んでもよい。反応検出システムによって測定された電気化学反応または色反応から検体の実際の濃度を計算するため、および概して、試料を試験するための手順を制御するために、ＢＧＭ３１０は、測定アルゴリズムに従ってプログラムされた命令を実行し得る少なくとも１つのプロセッサ３１２を用いる。プロセッサ３１２によって処理されたデータは、メモリ３１３に保存されてもよい。さらに、ＢＧＭ３１０は、ディスプレイを含むユーザインタフェース３１５を有してもよく、これは、例えば、液晶ディスプレイであってもよい。また、ユーザがＢＧＭ３１０と対話できるようにするために、押しボタン、スクロールホイール、タッチ画面、またはこれらの任意の組み合わせも、ユーザインタフェース３１５の一部として提供されてもよい。表示部は、典型的には、試験結果に関する情報、試験手順、および／またはユーザによって入力された信号に応答する情報を示す。
【００４６】
ＢＧＭ３１０は、試験結果を保存し、試験結果を表示するためのユーザインタフェース３１５を提供することができるが、演算装置４００上のデータ管理ソフトウェア３７５は、試験結果および関連情報を管理、処理、ならびに表示するためのより高度な機能を提供する。したがって、ＢＧＭ３１０により収集された試験関連データは、データ管理ソフトウェア３７５による使用のために、中央エンジン１１０を介して演算装置３７０に通信され得る。図５に示すように、ＢＧＭ３１０は、エンジンインタフェース要素１１１を介してＢＧＭ３１０が中央エンジン１１０と接続することを可能にする、ＢＧＭインタフェース要素３１１を含む。さらに、中央エンジン１１０はエンジンインタフェース要素１１６に接続されており、一方、エンジンインタフェース要素１１６は演算装置３７０のコンピュータインタフェース要素３７６に接続されている。ＢＧＭインタフェース要素３１１、コンピュータインタフェース要素３７６、ならびにエンジンインタフェース要素１１１および１１６は、装置を適合させ適切なデータ接続を可能とするために、上述のインタフェース技術を使用することができる。例えば、エンジンインタフェース１１１およびＢＧＭインタフェース３１１は、Ｂｌｕｅｔｏｏｔｈ（登録商標）無線を介して接続することができ、一方、エンジンインタフェース１１１は、ＵＳＢポートへの接続によりコンピュータインタフェース３７６に接続することができる。したがって、ＢＧＭ３１０および演算装置３７０は適合するインタフェースを有していない可能性があるが、図５のアーキテクチャは、それらの間でのデータ交換を可能とすることが容易に理解される。さらに、ＢＧＭ３１０の開発は、演算装置３７０のＵＳＢインタフェースとの直接的な適合性にかかわらず達成され得ることもまた、容易に想定される。
【００４７】
前述したように、中央エンジン１１０は、演算装置３７０またはいくつかの他の電源との接続を介して充電可能な電源を含み得る、電源管理部１１４を有する。中央エンジン１１０およびＢＧＭ３１０が接続されると、充電式電池は電力管理部３１４を介して充電され得る。
【００４８】
前述したように、図５中のＢＧＭ３１０は、プログラムされた命令を実行することができる少なくとも１つのプロセッサ３１２を使用する。さらに、ＢＧＭ３１０は、ユーザによる対話を可能とするために、ユーザに情報を提示するディスプレイ、および押しボタン、スクロールホイール、タッチスクリーン、またはこれらの任意の組み合わせを含むユーザインタフェース３１５を有していてもよい。そのようなコンポーネントにより、ＢＧＭ３１０は、試料を試験するための全手順を全般的に制御し、試験結果を計算する。実際には、図５を参照して記載される説明は、ＢＧＭ３１０によりすでに計算された試験結果が、後にどのように演算装置３７０等の他のモジュールと共有され得るかを概説している。しかしながら、中央エンジン１１０のプロセッサ１１２はまたさらに広範な機能を提供し得ることが想定される。事実、健康監視および送達システムにおける処理は、様々な様式で、中央エンジン１１０を含むコンポーネント間に分配され得ることがさらに想定される。
【００４９】
例えば、図６は、実質的にすべての処理を扱う他のコンポーネントを必要とするセンサ受容モジュール３８０を示す。ＢＧＭ３１０と同様に、センサ受容モジュール３８０は、試験センサ３１６を受容するように構成されている。しかしながら、センサ受容モジュール３８０は、試験手順を管理または試験結果を計算するためのプロセッサを有していない。また、センサ受容モジュール３８０は、ユーザと通信するためのユーザインタフェースを有しない。一般に、センサ受容モジュール３８０は、単に試験センサ３１６を受容し、診断システムの残りとの物理的接続のためのインタフェース要素３８１を提供するように設計されている。結果として、試験センサ３１６上の試験試料の分析は、センサ受容モジュール３８０がインタフェース要素３８１を介して試料を分析するためのプロセッサを有する装置と接続した際にのみ可能である。
【００５０】
図６に示すように、センサ受容モジュール３８０のインタフェース要素３８１はインタフェース要素１１１に接続され、一方、インタフェース要素１１１はデジタルセンサ１１０に接続されている。センサ受容モジュール３８０および中央エンジン１１０は、ＵＳＢホスト機能等のホスト機能が中央エンジン１１０により使用されることを必要とし得ることに留意されたい。一実施形態において、デジタルセンサ１１０もまた、演算装置３７０のインタフェース要素３７６に接続されている。センサ受容モジュール３８０、中央エンジン１１０、および演算装置３７０間のインタフェースは、上記ＵＳＢまたはＢｌｕｅｔｏｏｔｈ（登録商標）技術等、いずれのインタフェース技術をも使用することができる。したがって、演算装置３７０は、図５のＢＧＭ３１０上のプロセッサ３１２に類似した様式で、試料を試験し、試験結果を計算するための手順を制御するためにソフトウェア３７７を実行することができる。動作中、センサ受容モジュール３８０、中央エンジン１１０、および演算装置３７０は、図６に示すように接続されている。試験センサ３１６は、血液試料等の流体試料を採取するために使用される。例えば、試験センサ３１６が電気化学試験センサである場合、センサ受容モジュール３８０システムは、試験センサ３１６上で試料と試薬との間で生じる電気化学反応からの電気信号を受信するための電気接点を含み得る。センサ受容要素３８０と中央エンジン１１０との間の接続は、中央エンジン１１０が電気化学反応からの電気信号を受信するように、電気センサを含む回路に接続されている。次いで、計測アルゴリズムを使用して信号を処理しかつ試験結果を決定するために、この信号を演算装置３７０に送ることができる。演算装置３７０上のユーザインタフェースを使用して、試験結果を表示するかまたはユーザからの指示を受けることができる。
【００５１】
他の技術を使用してセンサ受容モジュール３８０からの信号を通信することができることが理解される。例えば、試験センサ３１６は、光学試験センサであってもよく、センサ受容システム３８０は、色反応を検出するための光学検出器を含んでもよい。センサ受容モジュール３８０が試験センサ３１６からの信号を受信または処理するためにいかなる電力でも必要とする場合、中央エンジン１１０との接続により電力を引き出すことができる。
【００５２】
代替として、別の実施形態において、システムに演算装置３７０が使用されていないため、センサ受容モジュール３８０が図７に示すように中央エンジン１１０にのみ接続されている。したがって、試験結果計算は、中央エンジン１１０のプロセッサ１１２により完了され、試験結果は中央エンジン１１０に接続されたユーザインタフェース上に表示される。図７に示すように、ユーザインタフェース１１５は、筐体１０１内に組み込まれてもよい。
【００５３】
試験プロセスを制御し結果を決定するための測定ソフトウェア２５３は、図７に示すような保存装置２５０を介して利用可能となり得る。図４に示すように、保存装置２５０は、別の種類の入力／出力インタフェース２００とやりとりする。保存装置２５０は、ユニバーサルシリアルバス（ＵＳＢ）フラッシュ装置またはメモリカード等のフラッシュ記憶装置であってもよい。ＵＳＢフラッシュ装置は、サムドライブ、ハンディドライブ、フラッシュスティック、またはジャンプドライブとしても知られている。メモリカードは、ＰＣカード（ＰＣＭＣＩＡ）、コンパクトフラッシュ（ＣＦ）、スマートメディア（ＳＭ／ＳＭＣ）、メモリスティック（ＭＳ）、マルチメディアカード（ＭＭＣ）、セキュアデジタル（ＳＤ）、ｘＤピクチャーカード（ｘＤ）、インテリジェントスティック（ｉＳｔｉｃｋ）、エクスプレスカード、またはこれらのいくつかの変形を含む、様々な形式を有し得る。フラッシュ記憶装置は、保存装置２５０に電力が提供されない場合であっても測定ソフトウェア２５３と関連したソフトウェアが保存装置２５０内に維持され得るように、不揮発性メモリを使用することができる。いくつかの実施形態において、保存装置２５０内のメモリは、メモリ上に格納された測定ソフトウェア２５３が直接実行され得るように、ＮＯＲフラッシュメモリ等の直接実行型（ＸＩＰ）メモリを含み得る。また、保存装置２５０は、フロッピーディスクまたは光学ディスク（ＣＤ、ＤＶＤ、Ｂｌｕ−ｒａｙディスク）等の他の保存メディアを使用し得る。
【００５４】
保存装置２５０は、図７に示すように、筐体１０１内で中央エンジン１１０とアセンブルされてもよく、または、外部モジュール（例えばモジュール３００）と類似の様式で中央エンジン１１０に接続されていてもよい。特に後者の場合、保存装置２５０は、通信インタフェース２１０とインタフェースをとり、中央エンジン１１０に接続されていてもよい。インタフェースは、保存装置２５０と中央エンジン１１０との間のデータ通信を可能とし、測定ソフトウェア２５３、またはその他の任意のソフトウェアが中央エンジン１１０と使用されることを許可する。特に、保存装置２５０は、インタフェース要素２１０と適合するインタフェース要素を有する。いくつかの実施形態において、保存装置インタフェース要素は、インタフェース要素２１０と物理的に係合してシリアルハードウェアインタフェースを形成する。例えば、保存装置２５０はＵＳＢフラッシュドライブであってもよく、保存装置インタフェース要素は、中央エンジン１１０に対する通信インタフェース要素２１０として機能するＵＳＢポートに受容されるＵＳＢコネクタであってもよい。
【００５５】
さらなる例として、保存装置２５０は、インタフェース要素として機能する一連の端子を有するセキュアデジタル（ＳＤ）メモリカードであってもよく、通信インタフェース２１０は、メモリカードの端子を受容する拡張スロットであってもよい。この例では、中央エンジン１１０および保存装置２００は、セキュアデジタルＩ／Ｏ（ＳＤＩＯ）インタフェース仕様に適合し得る。異なるインタフェース仕様を有するその他のメモリカード形式が使用し得ることが想定される。しかしながら、ＰＤＡ、ＨＰＣおよび高性能携帯電話等の多くのホストはＳＤＩＯに適合する拡張スロットを含むため、ＳＤＩＯを有することが有利である。
【００５６】
図７の中央エンジン１１０は、図６の例では、演算装置３７０の役割を満たしているため、より高性能の処理装置が必要となり得る。例えば、いくつかの実施形態は、ハンドヘルド型もしくはポケットパーソナルコンピュータ（ＨＰＣ）、適合携帯情報端末（ＰＤＡ）、または高性能携帯電話を使用し得る。上述のように、これらの処理装置は、様々なオペレーティングシステムおよび構成を使用し得る。例えば、演算装置３７０がＰＤＡである場合、オペレーティングシステムは、Ｐａｌｍ， Ｉｎｃ．製ＰＡＬＭ（登録商標）ハンドヘルド機器、またはＲｅｓｅａｒｃｈ ｉｎ Ｍｏｔｉｏｎ Ｌｉｍｉｔｅｄ製Ｂｌａｃｋｂｅｒｒｙ（登録商標）装置のシステムと一致し得る。有利には、ＰＡＬＭ（登録商標）ハンドヘルド機器およびＢｌａｃｋｂｅｒｒｙ（登録商標）装置は、センサ受容モジュール３８０から収集された結果に対し確実に高度データ管理ソフトウェアを実行するために十分な処理力を備えた携帯型装置を提供する。また、そのような装置は、高度グラフィック表示能力を提供する、高機能ユーザインタフェースを提供する。さらに、これらのハンドヘルド型装置は、インターネット等の外部ネットワークに接続するため、新たなソフトウェアまたはソフトウェアアップグレード／パッチを容易にインストールすることができる。さらに、電気通信ネットワークへの接続により、監視または評価のために試験結果が容易に医師および他のヘルスケア専門家に伝送されることが可能となる。多くの消費者はこれらのまたは類似した装置をすでに持ち歩いているため、糖尿病管理システム等の診断システムの多くのユーザは、すでに所有し常に持ち歩いている装置にシステムを便利に組み込むだろう。
【００５７】
実施形態は、異なる種類のハードウェア上に位置し得る多くの異なる種類のモジュール３００を使用し得るため、通信インタフェース２１０は、一般に、２種類以上の通信技術またはプロトコルに対応しなければならない。しかしながら、中央エンジン１１０と様々なモジュール３００との間に最も広範囲の適合性を提供しながら通信インタフェース２１０の数を最小にするために、通信インタフェース２１０は、広く用いられ、標準化されたインタフェース技術、例えばＵＳＢまたはＢｌｕｅｔｏｏｔｈ（登録商標）技術を使用することができる。好ましくは、通信インタフェース２１０は、モジュール３００と中央エンジン１１０との間の通信を確立するために必要な構成の量を最小にする技術を使用する。実際には、ＵＳＢ接続性等のいくつかの通信技術は、プラグアンドプレイ（ＰｎＰ）能力を提供する。これらの実施形態において、モジュール３００は物理的に、例えば従来のＵＳＢポートを介して接続される。次いで、それに応答して、中央エンジン１１０は即座にモジュール３００を認識し、モジュール３００との即座の通信を確立する。
【００５８】
通信インタフェース２１０は、モジュール３００間の通信を提供するだけでなく、外部ネットワークとのセキュアな通信を可能とする。したがって、実施形態は、製品が現場で旧式となった場合、中央エンジンおよび／またはモジュール３００に、ソフトウェアに対する更新、アップグレード、または追加をダウンロードするために、外部ネットワークへの接続を使用することができる。換言すると、実施形態は、フィールドアップグレード可能なソフトウェア機能を提供し得る。有利なことに、実施形態は、製造者または認証された第三者により提供された、またはそれらが購入したプログラムファイルを使用することにより、ユーザが、例えば中央エンジン１１０および／またはモジュール３００用のソフトウェア等、統合システムにおけるあらゆるソフトウェア／ファームウェアを更新できるようにする。ユーザが直接的な援助のために製造者または第三者に連絡することを必要とせずに、既存のシステムソフトウェアをより新しいバージョンで更新もしくはパッチすることができ、または、システムに新しいソフトウェアを追加することができる。新しいソフトウェアにより、ユーザは、システムの機能性をカスタマイズおよび／または拡張することができる。いくつかの場合において、製品は、本質的に新製品に変換され得る。フィールドアップグレードは、すでに製品を購入しているユーザに対し、最新の製品機能を利用可能とする。さらに、フィールドアップグレードは、既存の製品を、他の新たにリリースされた付属品または装置と適合させる。例えば、糖尿病管理システムにおいて、ＢＧＭ３１０が血糖濃度に関して血液を試験するために試験センサを使用し、ＢＧＭ製造者が正確性または試験時間を改善する新たな試験センサを開発する場合、実施形態は、ＢＧＭ３１０が新たな試験センサを認識することができるように、ユーザが装置内のファームウェアをアップグレードすることを可能とする。
【００５９】
中央エンジンは、ダウンロードエンジンと組み合わせてフィールドアップグレード検証の側面を管理することができる。以下でさらに説明するダウンロードエンジンは、外部ネットワーク上の例えばフィールドアップグレードサーバ等のサーバから通信インタフェースを介してシステムコンポーネントを受信し、検証および展開のためにシステムコンポーネントを配信することができる。追加として、または代替として、外部ネットワーク上のサーバは、フィールドアップグレードプロセスの側面を管理することができる。
【００６０】
また、モジュール３００と関連した重要な医学的機能のために、実施形態は、いかなるフィールドアップグレードも製品により保存されているデータまたはソフトウェアを破壊せず、また製品が期待通りに動作し続けるようにするために、新たなソフトウェアまたは構成情報を使用する前に検証手順を使用する。例えば、チェックサムルーチンを使用して、データまたはソフトウェアが完全にダウンロードに成功したか否かを確認することができる。例えば、中央エンジン１１０は、関連したデータ更新ファイル（ＤＵＦ）、またはソフトウェアのダウンロードを確実に成功させる他のコンポーネントに従いダウンロードを検証することができる。さらなるデータセキュリティのために、フィールドアップグレードプロセスは、データ暗号化／復号化を使用することができる。
【００６１】
図９に示した例示的な実施形態において、適切な外部ネットワークにおけるフィールドアップグレードサーバとの接続が確立されると（動作５０２）、既存のシステムコンポーネント、例えばソフトウェアまたは構成情報に対する利用可能なフィールドアップグレードが識別される（動作５０４）。サーバへの接続は、ネットワークへの接続が確立され得た際に自動的にトリガされてもよく、または、ユーザが手動でフィールドアップグレードサーバとの接続を開始してもよい。利用可能なフィールドアップグレードを識別するために、中央エンジンまたはサーバは、バージョン管理プログラムを使用して、フィールドアップグレードサーバ上に保存されたより新しいまたは異なるバージョンと適合し、また置き換え可能なアーキテクチャ内のシステムコンポーネントを決定することができる。次いで新しいシステムコンポーネントが、フィールドアップグレードサーバから、既存のシステムコンポーネントを保存しているメモリ領域とは別個のメモリ、すなわちデータ保存領域にダウンロードされる。メモリの領域は、フィールドアップグレード操作専用に特化され得る。換言すると、少なくとも検証が完了するまで、既存のシステムコンポーネントは削除または上書きされずに保存される。新しいシステムコンポーネントは、システムチェック（動作５０８）で検証され、ダウンロードが成功して、システムが適切に動作している場合、新しいシステムコンポーネントは通常のシステム動作に展開される。したがって、フィールドアップグレードが失敗した場合、システムの旧バージョンがまた利用可能であり、リカバリまたは復元オプションを提供する。新しいシステムコンポーネントは、失敗したフィールドアップグレードとともに除去される。いくつかの実施形態において、新バージョンは、その新バージョンが検証された後にメモリ内の旧バージョンを置き換えることができる。他の実施形態において、１つ以上の旧バージョンが検証後でも保存され、ユーザは、より古いバージョンが好ましい場合には、システムコンポーネントの１つ以上の旧バージョンを復元するオプションを有することができる。
【００６２】
図８を参照して例示的な実施形態を説明する。図８の実施形態において、糖尿病管理システム４００は、流体試料を採取するモジュール４０２、４０３、４０４、および４０５を含み得る。デジタルエンジン４０６は各モジュール、ユーザインタフェース４１３、メモリ４０７、およびダウンロードエンジン４０８を制御する。ダウンロードエンジン４０８は、通信モジュールのうちの１つ、デジタルエンジン４０６、およびメモリ４０７の間のインタフェースを提供する。通信モジュールは、例えば演算装置ＵＳＢポートとシステム４０１との間の通信を提供するＵＳＢインタフェース４０９を含み得る。通信モジュールはまた、システム４００と、演算装置、携帯電話、および／またはシステム４００と通信可能なその他の装置との間の無線通信を提供する、Ｂｌｕｅｔｏｏｔｈインタフェース４１０を含み得る。さらに、Ｗｉ−Ｆｉインタフェース４１１は、無線ネットワークとシステム４００との間の通信を提供する。さらに、イーサネットインタフェース４１１は、ローカルエリアネットワークとシステム４００との間の通信を提供する。各通信モジュールは、ユーザの指示のもとで、現場において測定器のソフトウェアをアップグレード／更新するために使用することができる。ユーザの要求に応じて、新機能のための新しいファームウェア、現在のシステム機能の動作を更新するための新しいファームウェア、ユーザインタフェース言語、画面更新およびカスタマイズ、ゲームおよびその他のスタンドアロン型アプリケーション、ゲージならびにその他のソフトウェアまたは構成設定／更新といった機能もまた、ダウンロードすることができる。
【００６３】
例えば、ユーザインタフェースは、多くの言語で通信することができるが、ユーザがそのシステムの動作をカスタマイズするために必要なときに言語ファイルをダウンロードできるため、それらの言語のために必要なすべてのデータがローカルで保存されている必要はない。また、ユーザは、画面上に表示するカスタム写真をインストールすることにより、または製造者もしくは認証された第三者により利用可能となっている表示レイアウトをダウンロードすることにより、ユーザインタフェース表示の外観をカスタマイズすることができる。さらに、ユーザは、システム４００が体液を分析するために使用されていないときにシステムプロセッサ上で実行および操作可能なスタンドアロン型アプリケーション（ゲーム等）をインストールすることにより、システムの動作をカスタマイズすることができる。また、ユーザは、結果が数値表示、擬似アナログゲージ、定性的フィードバック等として提示され得るように、体液分析結果が表示される様式を変更するソフトウェアをインストールすることにより、システム動作をカスタマイズすることができる。
【００６４】
再び図４を参照すると、入力／出力インタフェース２００はまた、概してモジュール３００に試験結果等の情報をユーザに対し表示させる、ユーザインタフェース２２０を含む。モジュール３００は、通信インタフェース２１０を介してそのような情報を中央エンジン１１０に伝送することができ、一方、中央エンジン１１０は、情報を表示インタフェース２２０上に提示することができる。通信の集中的処理が好ましい場合もあるが、モジュール３００は、ある場合には、表示インタフェース２２０と直接インタフェースをとることができる。図２に示すように、表示インタフェースは、グラフィック液晶ディスプレイ（ＬＣＤ）または有機発光ダイオード（ＯＬＥＤ）、セグメントＬＣＤまたはＯＬＥＤ、ＭＰ４再生等を含み得る。
【００６５】
また、入力／出力インタフェース２００は、音声信号を介して、ユーザへ、およびユーザから情報を通信させることができる。例えば、入力／出力インタフェース２００は、音声情報をユーザに通信するために、音声合成器、ＭＰ３再生等を含み得る。さらに、入力／出力インタフェース２００はまた、ユーザからの音声情報を受信するための音声認識機構を含み得る。
【００６６】
さらに、ユーザインタフェース２００は、ユーザがシステムに情報または命令を入力できるようにし得る。例えば、ユーザは、操作中、モジュール３００のうちの１つをガイドするために、単純なプロンプトに応答するか、またはメニュー選択を行うことが求められるようにすることができる。あるいは、さらなる例として、ユーザは、試験結果等の情報を検索するために命令を入力し、また情報を表示インタフェース２２０上に提示することを求めることができる。例えば、入力を提供するための機構としては、キーパッド、タッチスクリーン、サムホイール等が挙げられる。
【００６７】
図７に示すように、ユーザインタフェース１１５は、中央エンジン１１０および対応する通信インタフェース２１０がアセンブルされる筐体１０１内に組み込むことができる。したがって、筐体１０１は、健康監視および送達システムのための携帯型装置１０１を形成し得る。図３を参照しながら前述したように、ＢＧＭ３１０等のいくつかのモジュール３００を装置内に組み込むことができ、一方ＣＧＭ３２０およびインスリン送達モジュール３３０等の他のモジュールを、通信インタフェース２１０を通して携帯型装置１０１に外部的に接続することができる。デジタルエンジン３１０に接続されたモジュール３００は、インタフェースへのアクセスを有する。
【００６８】
アーキテクチャを使用するシステムは、様々な種類の電子ネットワークおよび通信をサポートする。モジュール３００は、例えば、携帯電話での活動を提供するために使用され得る。他の実施形態は、代替として、または追加として、道路ナビゲーション、人物追跡、および時刻サービス等の民生アプリケーションに広く利用されるようになったグローバルポジショニングシステム（ＧＰＳ）技術を使用することができる。技術がより発達するにつれて、この技術を消費者製品および医療装置に統合するコストが顕著に削減されている。ＧＰＳ受信器チップセットが現在市場で入手可能であり、消費者装置または医療装置と容易に統合して、装置の位置、速度および、標準時間に関する情報を提供することができる。したがって、ＧＰＳは、健康状態の監視および／または薬物の送達のための統合システムを形成するためにアーキテクチャを使用するシステムの機能性を高めるために提供され得る。
【００６９】
ＧＰＳにより、例えば、糖尿病管理システムは、グルコース試験と関連した追加の情報を提供することができる。正確なタイムスタンプおよび位置は、読取値と関連させることができる。従来の測定器により生成される誤ったタイムスタンプは、複数の測定器からの読取値がダウンロードされて１つのデータベースファイルにマージされる際、または測定器と同期した現地時間を有しないコンピュータもしくはウェブサーバにアップロードされる際の、混乱および困難の元であった。患者の動きおよび運動を自動的に追跡することができ、患者のログの労力を大幅に容易にする。データは、距離および速度を含み得る。この情報は、運動、食事、薬物および血糖試験頻度等に関する患者の日々の活動の計画立案に使用することができる。また、これは、読取パターンと日々の活動との間の相関関係の総合的分析も可能とする。さらに、患者は非常事態であり得る。
【００７０】
ＧＰＳで得られる追加の時刻、位置、および物理的活動情報は、記録された食事、薬物情報と組み合わせて、患者の日々の血糖パターンに対するより正確な予測を行うように糖尿病管理システムを支援することができる。糖尿病管理システムは、患者が所定の範囲内で自分の血糖レベルを制御するのを手助けする、日々の活動のリアルタイムな推奨を行うことができる。そのようにして、システムは、毎日正しい時点で正しい数の試験を受けることを患者に思い出させることができる。
【００７１】
したがって、グルコース読取値が正しいタイムスタンプと関連し得るように、ＧＰＳを使用してシステムの装置のリアルタイムクロック（ＲＴＣ）をＵＭＴと高精度で同期させることができる。ＧＰＳ機能性の電力が考慮点となり得るため、ＧＰＳ受信器は、装置の結晶品質に応じて、１日に１度または週に１度だけ起動が必要とされ得る。ＧＰＳが毎回０．１７５ｍＡｈｒの電力（Ｔｒｉｍｂｌｅチップセットを使用するＸｅｍｉｃｓ ＸＥ１６００受信器に基づく計算）を消費し、装置が１日に１度ＧＰＳ計測を行うと仮定すると、ＧＰＳ関連計算のために１年で６３．９ｍＡｈｒが消費され、これは大まかに言って通常の携帯電話の電池容量の約１０〜２０％である。
【００７２】
前述のように、統合監視／送達システムのいくつかの携帯型実施形態は、高度なデータ管理のために演算装置３７０と接続することができる。この状況は、患者の動きおよび活動を追跡するためにＮＡＶＳＹＳ ＧＰＳレコーダモデル（ＴｒａｃｋＴａｇ）を携帯型装置に適用する機会を提供する。ＧＰＳレコーダは、衛生信号の処理を行わずにそのスナップショットを撮るだけであるため、膨大な量の電力を節約することができる。装置がＧＰＳスナップショットを１５０秒に１回撮ると仮定すると、一年でこのＧＰＳレコーダは約２８０ｍＡｈｒしか消費せず、これは大まかに言って、通常の携帯電話の電池容量の約５０％未満である。装置が夜はスナップショットの撮影を停止することができれば、さらなるエネルギーが保存され得る。ＴｒａｃｋＴａｇアプローチの代償は、必要な装置上のメモリの必要量である。どのスナップショットも約１５ｋｂｙｔｅであるため、上記スナップショット速度では、年間約２００，０００スナップショットとなり、約３Ｇｂｙｔｅのメモリが必要である。当然ながら、ＧＰＳデータが装置からコンピュータにダウンロードされ処理されると、装置メモリは解放され再利用され得る。１Ｇｂｙｔｅメモリでは、携帯型装置の位置の追跡が４ヶ月可能と思われる。現代のフラッシュメモリ技術を用いれば、１Ｇｂｙｔｅ装置メモリは、容易に対応され得る。
【００７３】
ＧＰＳ機能性は、組込み型の中心機能となり得る。しかしながら、よりモジュール式の例では、ＧＰＳ機能性は、接続されたモジュール、すなわち取り外し可能なＧＰＳ受信器により提供され得る。実際には、ＧＰＳ受信器モジュールが時間および位置情報を保存するための独自のメモリを有する場合、ＧＰＳは、ＤＭ装置と常に接続されている必要はないことが可能である。ＧＰＳ受信器は、装置クロックが同期されなければならない頻度およびＧＰＳ受信器メモリの利用可能性に応じて、１日に１度または数日に１度、システムと接続され得る。有利には、取り外し可能なＧＰＳ受信器モジュールの使用は、中央エンジン１１０のハードウェア／ソフトウェア設計およびシステムのその他の側面に対する影響を最小にした。さらに、電力管理が容易になる。
【００７４】
本発明は、様々な修正および代替形態が可能であるが、その特定の実施形態および方法を一例として図面に示し、本明細書において詳細に説明してきた。しかしながら、本発明は、開示された特定の形状または方法に限定されるものではなく、また、それとは反対に、本発明の精神および範囲に含まれるすべての修正、均等物、ならびに代替物を対象とすることを意図することが理解されるべきである。
【特許請求の範囲】
【請求項１】
ヘルスケアデータを管理するためのシステムであって、
ヘルスケア機能を提供する少なくとも１つのモジュールと、
前記少なくとも１つのモジュールを制御する中央エンジンと、
遠隔サーバへの接続を提供する１つ以上の通信インタフェースであって、前記遠隔サーバは、前記少なくとも１つのモジュールまたは前記中央エンジンに対応する１つ以上のプログラムコンポーネントを格納する、通信インタフェースと、
前記１つ以上の通信インタフェースを介して前記遠隔サーバから前記１つ以上のプログラムコンポーネントを受信し、前記少なくとも１つのモジュールまたは前記中央エンジンとの使用のために前記１つ以上のプログラムコンポーネントを配信するように構成されたダウンロードエンジンと、を備えるシステム。
【請求項２】
前記ダウンロードエンジンが前記１つ以上のプログラムコンポーネントを受信する前に、前記１つ以上のプログラムコンポーネントが前記少なくとも１つのモジュールまたは前記中央エンジンに適合するか否かを決定する、バージョン管理コンポーネントをさらに備える、請求項１に記載のシステム。
【請求項３】
前記１つ以上のプログラムコンポーネントは、前記少なくとも１つのモジュールまたは前記中央エンジン上で稼動しているソフトウェアのより古いバージョンを、前記ソフトウェアの更新されたバージョンと置き換える、請求項１に記載のシステム。
【請求項４】
前記ソフトウェアの前記より古いバージョンを復元する復旧コンポーネントをさらに備える、請求項３に記載のシステム。
【請求項５】
前記ソフトウェアの前記更新されたバージョンは、前記ソフトウェアの前記より古いバージョンとは別個の記憶領域にダウンロードされ、前記ソフトウェアの前記より古いバージョンは、復元可能な状態を維持する、請求項４に記載のシステム。
【請求項６】
前記ソフトウェアの前記より古いバージョンは、検証コンポーネントが、前記ソフトウェアの前記更新されたバージョンが不正確に動作しているか、または適切にダウンロードされなかったと決定した場合に復元される、請求項４に記載のシステム。
【請求項７】
前記１つ以上のプログラムコンポーネントは、前記少なくとも１つのモジュールまたは前記中央エンジン上で稼動しているソフトウェアのためのパッチを提供する、請求項１に記載のシステム。
【請求項８】
前記１つ以上のプログラムコンポーネントは、前記少なくとも１つのモジュールまたは前記中央エンジンにより実行される新しい機能を提供する、請求項１に記載のシステム。
【請求項９】
前記１つ以上のプログラムコンポーネントは、前記少なくとも１つのモジュールまたは前記中央エンジン上で稼動しているソフトウェアのための構成情報を含む、請求項１に記載のシステム。
【請求項１０】
前記ダウンロードエンジンは、前記１つ以上のプログラムコンポーネントを受信および配信するために、ユーザにより手動でトリガされる、請求項１に記載のシステム。
【請求項１１】
前記ダウンロードエンジンは、前記遠隔サーバへの通信が確立され得る際に、前記１つ以上のプログラムコンポーネントを識別するために自動的にトリガされる、請求項１に記載のシステム。
【請求項１２】
前記１つ以上のインタフェースは、ＵＳＢインタフェース、無線周波数（ＲＦ）インタフェース、Ｗｉ−Ｆｉインタフェース、およびイーサネットインタフェースのうちの少なくとも１つを含む、請求項１に記載のシステム。
【請求項１３】
前記ダウンロードエンジンが無線ネットワークの範囲内にあるときに前記遠隔サーバへの通信が確立される、請求項１に記載のシステム。
【請求項１４】
前記１つ以上のプログラムコンポーネントが展開される前に、前記１つ以上のプログラムコンポーネントを検証するように構成されたデータ検証コンポーネントをさらに備える、請求項１に記載のシステム。
【請求項１５】
前記データ検証コンポーネントは、前記１つ以上のプログラムコンポーネントが破壊されていないか否かを決定する、請求項１４に記載のシステム。
【請求項１６】
前記データ検証コンポーネントは、チェックサムルーチンで、前記１つ以上のプログラムコンポーネントが前記ダウンロードエンジンを介して前記遠隔サーバから完全に転送されたか否かを決定する、請求項１４に記載のシステム。
【請求項１７】
前記１つ以上のプログラムコンポーネントは、前記データ検証が、前記１つ以上のプログラムコンポーネントが破壊されていると決定した場合に除去される、請求項１４に記載のシステム。
【請求項１８】
ヘルスケアデータを管理するためのシステムであって、
主ヘルスケア機能を提供する少なくとも１つのモジュールの第１のセットと、
前記少なくとも１つのモジュールの第１のセットを制御するための第１の中央エンジンと、
副ヘルスケア機能を提供する少なくとも１つのモジュールの第２のセットと、
前記少なくとも１つのモジュールの第２のセットを制御するための第２の中央エンジンと、
前記第１の中央エンジンと前記第２の中央エンジンとの間の接続を提供する通信インタフェースと、を備えるシステム。
【請求項１９】
前記第１の中央エンジンは、第１の開発プロセスに従い、前記少なくとも１つのモジュールの第１のセットとアセンブルされ、前記第２の中央エンジンは、第２の開発プロセスに従い、前記少なくとも１つのモジュールの第２のセットとアセンブルされる、請求項１８に記載のシステム。
【請求項２０】
前記通信インタフェースは、ＵＳＢインタフェース、無線周波数（ＲＦ）インタフェース、Ｗｉ−Ｆｉインタフェース、およびイーサネットインタフェースのうちの少なくとも１つである、請求項１８に記載のシステム。
【請求項２１】
前記中央エンジンは、マザーボード上に実装され、前記少なくとも１つのモジュールは、ドーターボード上に別個に実装され、前記ドーターボードは、前記マザーボードとの接続のために標準化されている、請求項１８に記載のシステム。
【請求項２２】
ヘルスケアデータを管理するための方法であって、
第１の開発プロセスに従い、第１の中央エンジンと、主ヘルスケア機能を提供する少なくとも１つのモジュールの第１のセットとの第１のアセンブリを開発するステップであって、前記第１の中央エンジンは、前記少なくとも１つのモジュールの第１のセットを制御する、ステップと、
第２の開発プロセスに従い、第２の中央エンジンと、副ヘルスケア機能を提供する少なくとも１つのモジュールの第２のセットとの第２のアセンブリを開発するステップと、
前記第１のアセンブリと前記第２のアセンブリとを、通信インタフェースを介して接続するステップと、を含む方法。
【請求項１】
ヘルスケアデータを管理するためのシステムであって、
ヘルスケア機能を提供する少なくとも１つのモジュールと、
前記少なくとも１つのモジュールを制御する中央エンジンと、
遠隔サーバへの接続を提供する１つ以上の通信インタフェースであって、前記遠隔サーバは、前記少なくとも１つのモジュールまたは前記中央エンジンに対応する１つ以上のプログラムコンポーネントを格納する、通信インタフェースと、
前記１つ以上の通信インタフェースを介して前記遠隔サーバから前記１つ以上のプログラムコンポーネントを受信し、前記少なくとも１つのモジュールまたは前記中央エンジンとの使用のために前記１つ以上のプログラムコンポーネントを配信するように構成されたダウンロードエンジンと、を備えるシステム。
【請求項２】
前記ダウンロードエンジンが前記１つ以上のプログラムコンポーネントを受信する前に、前記１つ以上のプログラムコンポーネントが前記少なくとも１つのモジュールまたは前記中央エンジンに適合するか否かを決定する、バージョン管理コンポーネントをさらに備える、請求項１に記載のシステム。
【請求項３】
前記１つ以上のプログラムコンポーネントは、前記少なくとも１つのモジュールまたは前記中央エンジン上で稼動しているソフトウェアのより古いバージョンを、前記ソフトウェアの更新されたバージョンと置き換える、請求項１に記載のシステム。
【請求項４】
前記ソフトウェアの前記より古いバージョンを復元する復旧コンポーネントをさらに備える、請求項３に記載のシステム。
【請求項５】
前記ソフトウェアの前記更新されたバージョンは、前記ソフトウェアの前記より古いバージョンとは別個の記憶領域にダウンロードされ、前記ソフトウェアの前記より古いバージョンは、復元可能な状態を維持する、請求項４に記載のシステム。
【請求項６】
前記ソフトウェアの前記より古いバージョンは、検証コンポーネントが、前記ソフトウェアの前記更新されたバージョンが不正確に動作しているか、または適切にダウンロードされなかったと決定した場合に復元される、請求項４に記載のシステム。
【請求項７】
前記１つ以上のプログラムコンポーネントは、前記少なくとも１つのモジュールまたは前記中央エンジン上で稼動しているソフトウェアのためのパッチを提供する、請求項１に記載のシステム。
【請求項８】
前記１つ以上のプログラムコンポーネントは、前記少なくとも１つのモジュールまたは前記中央エンジンにより実行される新しい機能を提供する、請求項１に記載のシステム。
【請求項９】
前記１つ以上のプログラムコンポーネントは、前記少なくとも１つのモジュールまたは前記中央エンジン上で稼動しているソフトウェアのための構成情報を含む、請求項１に記載のシステム。
【請求項１０】
前記ダウンロードエンジンは、前記１つ以上のプログラムコンポーネントを受信および配信するために、ユーザにより手動でトリガされる、請求項１に記載のシステム。
【請求項１１】
前記ダウンロードエンジンは、前記遠隔サーバへの通信が確立され得る際に、前記１つ以上のプログラムコンポーネントを識別するために自動的にトリガされる、請求項１に記載のシステム。
【請求項１２】
前記１つ以上のインタフェースは、ＵＳＢインタフェース、無線周波数（ＲＦ）インタフェース、Ｗｉ−Ｆｉインタフェース、およびイーサネットインタフェースのうちの少なくとも１つを含む、請求項１に記載のシステム。
【請求項１３】
前記ダウンロードエンジンが無線ネットワークの範囲内にあるときに前記遠隔サーバへの通信が確立される、請求項１に記載のシステム。
【請求項１４】
前記１つ以上のプログラムコンポーネントが展開される前に、前記１つ以上のプログラムコンポーネントを検証するように構成されたデータ検証コンポーネントをさらに備える、請求項１に記載のシステム。
【請求項１５】
前記データ検証コンポーネントは、前記１つ以上のプログラムコンポーネントが破壊されていないか否かを決定する、請求項１４に記載のシステム。
【請求項１６】
前記データ検証コンポーネントは、チェックサムルーチンで、前記１つ以上のプログラムコンポーネントが前記ダウンロードエンジンを介して前記遠隔サーバから完全に転送されたか否かを決定する、請求項１４に記載のシステム。
【請求項１７】
前記１つ以上のプログラムコンポーネントは、前記データ検証が、前記１つ以上のプログラムコンポーネントが破壊されていると決定した場合に除去される、請求項１４に記載のシステム。
【請求項１８】
ヘルスケアデータを管理するためのシステムであって、
主ヘルスケア機能を提供する少なくとも１つのモジュールの第１のセットと、
前記少なくとも１つのモジュールの第１のセットを制御するための第１の中央エンジンと、
副ヘルスケア機能を提供する少なくとも１つのモジュールの第２のセットと、
前記少なくとも１つのモジュールの第２のセットを制御するための第２の中央エンジンと、
前記第１の中央エンジンと前記第２の中央エンジンとの間の接続を提供する通信インタフェースと、を備えるシステム。
【請求項１９】
前記第１の中央エンジンは、第１の開発プロセスに従い、前記少なくとも１つのモジュールの第１のセットとアセンブルされ、前記第２の中央エンジンは、第２の開発プロセスに従い、前記少なくとも１つのモジュールの第２のセットとアセンブルされる、請求項１８に記載のシステム。
【請求項２０】
前記通信インタフェースは、ＵＳＢインタフェース、無線周波数（ＲＦ）インタフェース、Ｗｉ−Ｆｉインタフェース、およびイーサネットインタフェースのうちの少なくとも１つである、請求項１８に記載のシステム。
【請求項２１】
前記中央エンジンは、マザーボード上に実装され、前記少なくとも１つのモジュールは、ドーターボード上に別個に実装され、前記ドーターボードは、前記マザーボードとの接続のために標準化されている、請求項１８に記載のシステム。
【請求項２２】
ヘルスケアデータを管理するための方法であって、
第１の開発プロセスに従い、第１の中央エンジンと、主ヘルスケア機能を提供する少なくとも１つのモジュールの第１のセットとの第１のアセンブリを開発するステップであって、前記第１の中央エンジンは、前記少なくとも１つのモジュールの第１のセットを制御する、ステップと、
第２の開発プロセスに従い、第２の中央エンジンと、副ヘルスケア機能を提供する少なくとも１つのモジュールの第２のセットとの第２のアセンブリを開発するステップと、
前記第１のアセンブリと前記第２のアセンブリとを、通信インタフェースを介して接続するステップと、を含む方法。
【図１Ａ】
【図１Ｂ】
【図２Ａ】
【図２Ｂ】
【図２Ｃ】
【図２Ｄ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図９】
【図８】
【図１Ｂ】
【図２Ａ】
【図２Ｂ】
【図２Ｃ】
【図２Ｄ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図９】
【図８】
【公表番号】特表２０１０−５３１００８（Ｐ２０１０−５３１００８Ａ）
【公表日】平成２２年９月１６日（２０１０．９．１６）
【国際特許分類】
【出願番号】特願２０１０−５１０３４４（Ｐ２０１０−５１０３４４）
【出願日】平成２０年５月２９日（２００８．５．２９）
【国際出願番号】ＰＣＴ／ＵＳ２００８／００６８１４
【国際公開番号】ＷＯ２００８／１５０４２８
【国際公開日】平成２０年１２月１１日（２００８．１２．１１）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
２．ＺＩＧＢＥＥ
３．フロッピー
【出願人】（５０７０２１７５７）バイエル・ヘルスケア・エルエルシー (33)
【氏名又は名称原語表記】Ｂａｙｅｒ ＨｅａｌｔｈＣａｒｅ ＬＬＣ
【Ｆターム（参考）】
【公表日】平成２２年９月１６日（２０１０．９．１６）
【国際特許分類】
【出願日】平成２０年５月２９日（２００８．５．２９）
【国際出願番号】ＰＣＴ／ＵＳ２００８／００６８１４
【国際公開番号】ＷＯ２００８／１５０４２８
【国際公開日】平成２０年１２月１１日（２００８．１２．１１）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
２．ＺＩＧＢＥＥ
３．フロッピー
【出願人】（５０７０２１７５７）バイエル・ヘルスケア・エルエルシー (33)
【氏名又は名称原語表記】Ｂａｙｅｒ ＨｅａｌｔｈＣａｒｅ ＬＬＣ
【Ｆターム（参考）】
[ Back to top ]