ISO/IEEE 11073 個人健康データ標準

ISO/IEEE 11073 個人用健康機器 (PHD)規格は、体重計、血圧計、血糖値計などの個人用健康機器 (PHD) の相互運用性を扱う規格のグループです。この規格は、以前の IEEE11073 規格の作業に基づいていますが、個人用 (病院用ではなく) の機器に重点が置かれ、通信モデルが簡素化されている点で、以前の作業とは異なります。

人口動態の変化（多くの先進国で急速に高齢化が進んでいる）と慢性疾患（糖尿病や心臓病など）の増加により、テクノロジーを活用して医療従事者の負担を軽減し、高齢者や虚弱者に有用なツールを提供する方法、特に人々が自宅で自分の症状に対処するのにテクノロジーがどのように役立つかを問う人が増えています。このことが、人々が自宅で自分の症状をモニターし、そのデバイスが取得した情報を医療従事者やその他の介護者に提供できる「個人用健康デバイス」の開発につながっています。

互換性のないシステムにより、有用な個人用健康機器の展開が遅れるのではないかという懸念から、相互運用性を確保する動きが活発化しています。Continua Alliance は、この個人用健康機器市場の成長促進を目指す企業および団体のグループです。彼らはIEEE Standards Associationと連携しており、IEEE-EMBS傘下の11073 Personal Health Data Working Group は、機器の相互運用性を確保するためのデータ形式と通信の標準を策定しています。

IEEE 11073-20601-2008 では、この規格について次のように述べています。

...[個人用健康機器の]情報プロファイルを相互運用可能な伝送形式に変換し、個人用遠隔医療機器やコンピューティング エンジン (携帯電話、パソコン、個人用健康機器、セットトップ ボックスなど) との間で情報を交換できるようにするための、オープンに定義された独立した標準の必要性に対処します。

IEEE 11073パーソナルヘルスデバイス規格^[1]ファミリーは、単一の「フレームワーク」規格に基づいています。

• IEEE Std 11073-20601 - アプリケーション プロファイル - 最適化された交換プロトコル
• IEEE Std 11073-20601a - アプリケーション プロファイル - 最適化された交換プロトコル (修正)

そして、いくつかの「デバイス特化」標準があります。現在、次の標準が存在します。

• IEEE Std 11073-10404 - デバイスの特殊化 - パルスオキシメータ
• IEEE Std 11073-10407 - デバイスの特殊化 - 血圧モニター
• IEEE Std 11073-10408 - デバイスの特殊化 - 温度計
• IEEE Std 11073-10415 - デバイスの特殊化 - 計量スケール
• IEEE Std 11073-10417 - デバイスの特殊化 - グルコースメーター
• IEEE Std 11073-10420 - デバイスの特殊化 - 体組成分析装置
• IEEE Std 11073-10421 - デバイスの特殊化 - ピークフロー
• IEEE Std 11073-10441 - デバイスの特殊化 - 心血管フィットネスおよび活動モニター
• IEEE Std 11073-10442 - デバイスの特殊化 - 筋力トレーニング機器
• IEEE Std 11073-10471 - デバイスの専門化 - 自立生活活動ハブ
• IEEE Std 11073-10472 - デバイスの特殊化 - 薬剤モニター

IEEE 11073-20601 は、汎用データ型、メッセージ タイプ、および通信モデルを定義するフレームワーク標準です。これは、特定の種類の個人用健康デバイスのデータ モデルを定義するだけでよい、任意の数の (比較的小規模な)「デバイス特化」標準 (体温計の IEEE 11073-10408 標準など) をサポートします。

このモジュール方式により 、新しいタイプのデバイスのサポートを追加することが比較的容易になります。次のようなデバイス特化標準が現在準備中です。^{[いつ? ]}

• IEEE P11073-10406 - デバイスの特殊化 - 基本的な ECG (1 ～ 3 誘導)
• IEEE P11073-10413 - デバイスの特殊化 - 呼吸数モニター
• IEEE P11073-10418 - デバイスの特殊化 - INR (血液凝固)
• IEEE P11073-10419 - デバイスの特殊化 - インスリンポンプ

既存の規格の改訂:

• IEEE Std 11073-10404 - デバイスの特殊化 - パルスオキシメータ (改訂版)
• IEEE Std 11073-10417 - デバイスの特殊化 - グルコースメーター (改訂版)
• IEEE Std 11073-10441 - デバイスの特殊化 - 心血管フィットネスおよび活動モニター (3D 加速度計 / 身体活動モニター データを追加するための改訂)

アーキテクチャ上の決定には以下が含まれます。

• 「エージェント」と「マネージャー」の間でポイントツーポイント接続が確立されます。
• トランスポートに依存しません (新しい通信チャネルへの移行を容易にするため)。
• オブジェクト指向の哲学 (コードの再利用を容易にし、新しいデバイスの導入を簡素化します)。
• エージェントは自己記述型です (そのため、マネージャーはエージェントの特性を理解できます)。
• 拡張可能（新しいタイプのエージェントや、既に定義されているエージェントのカスタム特殊化を網羅）
• ASN.1 は、データ構造とメッセージを表すために使用されます (メッセージの解析を簡素化するため)。

IEEE 11073 システム モデル全体は 3 つの主要コンポーネントに分かれており、各コンポーネントは IEEE 11073-20601 で個別に扱われ、この記事の後半でそれぞれ詳細に扱われます。

• ドメイン情報モデルは、エージェントをオブジェクトのセットとして表します。各オブジェクトには 1 つ以上の属性があります。属性は、マネージャーに伝達される測定データとステータス データを表します。
• サービス モデルは、DIM からデータを交換するためにエージェントとマネージャー間で送信される Get、Set、Action、Event Report などのコマンドを提供します。
• 通信モデルは、接続、関連付け、および操作に関連する状態を含む、エージェントとマネージャの状態マシンを確立します。通信モデルは、ドメイン情報モデルで使用される抽象データモデリングを、通信モデルを使用して転送するためのバイナリメッセージ形式に変換します。

IEEE 11073 PHD 標準には、「エージェント」と「マネージャ」の概念があります。エージェントとマネージャは、複数のエージェント層とマネージャ層を持つ交互に配置されたアーキテクチャで動作する場合があります。

• エージェントは個人用健康デバイスであり、一般的には小型で安価なバッテリー駆動のデバイスであり、ディスプレイやその他のユーザー インターフェイスがほとんどありません。
• マネージャーは通常、配信元から指定されたクラスのシンクに情報を自律的に伝達するための、より大きなコンピューティング リソースと必要なルーティング機能を備えた小型コンピューターまたはスマートフォンです。

エージェントと管理者間のすべての通信は、患者を運ぶ看護師自身が移動する主体であるため、モバイルかつ自律的であることが望ましい。エージェントがデータをより有能な管理者に送信すると、データは管理者で処理および表示され、その後、イントラネットを通じて介護者や医療専門家に転送される可能性がある。インターネット経由の転送は技術的には実行可能であるが、データのセキュリティとプライバシー保護のレベルは低くなる。

標準では、各エージェントが一度に 1 つのマネージャと通信することを前提としています。マネージャは複数のエージェントと通信できます。通信は双方向で行われるため、トランザクションのセキュリティを確保できます。マネージャは、送信されたエージェントのオブジェクト (データ) のコピーを独自に保持できますが、階層化されたサーバー アーキテクチャによって法的に安全なアーカイブが提供されます。

IEEE 11073 PHD 標準では、エージェントとマネージャー間で送信されるメッセージが定義されていますが、それらのメッセージをどのように移動するかは定義されていません。

3 つのトランスポートが定義されました。

将来的には他のものが定義される可能性があります。

IEEE 11073 標準ファミリは、オブジェクト指向のシステム管理パラダイムを使用します。データ (測定値、状態など) は、オブジェクト アクセス サービス プロトコルを使用してアクセスおよび操作される情報オブジェクトの形式でモデル化されます。ただし、エージェントまたはマネージャをオブジェクト指向プログラミング言語を使用して実装する必要があるわけ ではありません。

このアプローチにより柔軟性が確保され、新しいデバイス特化標準を簡単に追加できるようになります。すべてのエージェントは「医療機器システム」オブジェクトのインスタンスであり、IEEE 11073-20601 フレームワーク標準で事前定義された他のオブジェクトの適切な組み合わせが含まれます。

エージェントは、1 つ以上の標準構成を実装することも、拡張 (カスタム) 構成を実装することもできます。エージェントは、最初にマネージャと関連付けられるときに、その構成を宣言します。通常、マネージャは、この構成コードを持つエージェントのオブジェクト モデルを既に認識しています。これは、マネージャが最初にこの知識を与えられたか、以前にこのエージェントと関連付けられていて、そのオブジェクト モデルを既に学習しているためです。マネージャがこの構成を認識していない場合、マネージャはエージェントにその特性を説明するように要求します (オブジェクトをリストすることによって)。

標準構成の使用、および新しい構成のエージェントが初めて登場したときにオブジェクト モデルを交換することにより、エージェントがマネージャーに関連付けるときに必要なデータ交換が大幅に削減されます。

各オブジェクトとそのすべての属性は、抽象構文記法 1 ( ASN.1 ) を使用して正式に定義されます。ASN.1 は、マシン固有のエンコード手法に依存しないオブジェクトの構造を記述するための一連の正式な規則を提供します。

ASN.1 オブジェクトは、基本エンコーディング ルール(BER)のサブセットである医療機器エンコーディング ルール (MDER) を使用してバイナリ データ ストリームに変換されます。MDER を使用すると、エージェントは定義済みの送信テンプレート (「定型メッセージ」) を保存し、送信前に固定位置と可変部分のみを変更できます。

IEEE 11073 システム モデル全体は、ドメイン情報モデル (DIM)、サービス モデル、通信モデルの 3 つの主要コンポーネントに分かれています。これら 3 つのモデルは連携して、データの表現、データ アクセスとコマンド方法の定義、エージェントからマネージャへのデータの通信を行います。これらを順番に検討します。

IEEE 11073 標準では、エージェントをオブジェクトのセットとして表現します (オブジェクト指向プログラミングの意味で)。

各オブジェクトには 1 つ以上の属性があります。属性は、マネージャに伝達される測定データと、エージェントの動作を制御し、エージェントの状態を報告する要素を記述します。属性だけでなく、オブジェクトは、マネージャがエージェントと対話できるメソッド (GET や SET など) を持つことができます。また、エージェントはイベントを生成できます。通常、イベントは、データが変更されたことをマネージャに通知します。

IEEE 11073-20601 では、次のクラス (オブジェクトとしてインスタンス化される) が定義されています。

• 医療機器システム (MDS) – 各エージェントには 1 つの MDS オブジェクトがあり、エージェントを識別してそのステータスを報告します。MDS オブジェクトの属性は、マネージャーに対してそのオブジェクトを識別し、時間とステータスを表し、その他の情報を提供します。MDS には、以下のクラスで表されるオブジェクトが 0 個以上含まれています。
• メトリック クラスは、測定値、ステータス、コンテキスト データを表すすべてのオブジェクトの基本クラスです。ただし、メトリック クラス自体はインスタンス化されません。代わりに、数値、リアルタイム サンプル配列、列挙クラスの基本クラスとして使用されます。

各オブジェクトにはさまざまな属性があり、必須のものとオプションのものがあります。これらの属性には、タイムスタンプ、説明文字列、有効性、単位などがあります。

• 数値 – 単一の測定値を表します。標準では、実際の測定値に適した 2 つの形式の浮動小数点データが定義されています。1 つは 32 ビットで、もう 1 つは 16 ビットです。数値オブジェクトは、どちらの形式でもデータを返すことができます。また、データ値自体 (コンテキストによって測定値の種類を推測できる場合) として、または単位とステータス情報とともにデータを返すことができます。配列や単一の値も可能です。
• リアルタイム サンプル配列 – 連続したサンプルまたは波形を表します。RTSA オブジェクトには、サンプル間の間隔、サンプル数、解像度、各データ値に適用されるスケールとオフセットに関する情報が含まれます。
• 列挙 – ステータス情報 (コード) または注釈 (テキスト) を表します。たとえば、これらのオブジェクトは、転倒、家の中の人の場所、または煙警報器の状態に関する情報を報告するために使用できます。
• 永続メトリック ストア - エージェントによって取得された大量のデータを (階層的に) 表します。各 PM ストア オブジェクトには、メタデータ (データに関するデータ) と、データを含む 0 個以上の PM セグメントが含まれます。
• PM セグメント – 各 PM セグメント オブジェクトには、メタデータ (データに関するデータ) と 0 個以上のエントリが含まれます。各エントリには、測定値を含む 1 つ以上の要素が含まれます。保存できるデータに関しては、かなりの柔軟性があります。
• スキャナ – スキャナ オブジェクトは、エージェントで行われている測定を監視し、マネージャに報告する「イベント」を生成できます。イベントは、定期的なレポート、またはアラームに値する異常な読み取りによってトリガーされるレポートです。メトリック クラスと同様に、スキャナ オブジェクトはクラスの階層で表されます。スキャナ クラスは、それ自体がインスタンス化されることはありません。むしろ、構成可能なスキャナ クラスの基本クラスとして使用され、この基本クラスは、実際にインスタンス化される 2 つのクラスの基本クラスです。
  • 設定可能なスキャナ - 自身はインスタンス化されない - 次の基本クラス:
    • エピソード構成可能スキャナー - これらのオブジェクトは、一定の時間間隔で区切られていないデータまたはイベントのレポートを送信するために使用されます。
    • 定期的に設定可能なスキャナー - これらのオブジェクトは、一定の時間間隔で区切られたデータまたはイベントのレポートを送信するために使用されます。

以下の図 (IEEE 11073-20601 標準に基づく) は、UML クラス図として表現された IEEE 11073 パーソナル ヘルス デバイス ドメイン情報モデルを示しています。MDS オブジェクト (およびそれに含まれるオブジェクト) はエー​​ジェントに属しますが、マネージャーはエージェントに問い合わせることで独自の表現を構築できます。

要約すると、エージェントは MDS オブジェクトとして表され、1 つ以上のメトリックまたは PM ストア オブジェクト (データを表す) を含み、スキャナ オブジェクトを通じてイベントを生成できます。

下の図は、IEEE 11073-10415 で定義された体重計のドメイン情報モデルという実際の例を示しています。これは、すべての体重計に MDS オブジェクトと体重数値オブジェクトがあることを示しています。オプションで体重と体格指数の数値オブジェクトがあります。

各オブジェクトとそのすべての属性は、抽象構文記法 1 ( ASN.1 ) を使用して正式に定義されます。

「サービス モデル」は、エージェントとマネージャー間で渡されるメッセージに関するものです。標準では、メッセージと、そのメッセージが発生するタイミングを定義します。

メッセージの種類は次のとおりです。

• エージェントとマネージャー間の「関連付け」の設定と解除に関連するメッセージ。
• マネージャーがエージェントのドメイン情報モデル (DIM) の情報にアクセスするためのメッセージ。エージェントの属性を読み取ったり、エージェントの動作の一部を制御したりします。
• エージェントからマネージャーに送信される、データを含むメッセージ。これらは「イベント」と呼ばれます。イベント メッセージはマネージャーまたはエージェントによって開始され、構成情報の報告と測定値の転送の両方に使用されます。

サービス モデルは、エージェントがマネージャに構成情報を渡すための柔軟で効率的な方法を定義します。これにより、マネージャはエージェントが所有するオブジェクトの独自の画像を構築できます。

エージェントは、関連付け (または「検出」) 段階で自分自身を説明できることに注意することが重要です。エージェントは、マネージャが認識している可能性のある標準構成、または非標準構成を持っていることを通知します。いずれの場合も、マネージャは、構成プロセス中にエージェントにそのすべてのオブジェクト (および機能) を説明するように要求できます。エージェントは、アプリケーションの要求に応じて、単純にも複雑にもできます。このようにして、マネージャはエージェントのすべてのオブジェクトのマップを作成します。これにより、プラグ アンド プレイ機能が提供されます。

サービス モデルでは、エージェントがマネージャーに測定データ値を渡すための柔軟かつ効率的な方法も定義します。

通信モデルは、1 つ以上のエージェントがポイントツーポイント接続を介して単一のマネージャと通信するトポロジをサポートします。IEEE 11073 標準はトランスポートに依存せず、標準の範囲外の何らかのメカニズムによってエージェントとマネージャの間にトランスポート層 (Bluetooth や Zigbee など) を確立できることを前提としています。

各ポイントツーポイント接続では、動的なシステム動作が接続状態マシンによって定義されます。接続状態マシンは、接続、関連付け、および操作に関連する状態を含む、エージェントとマネージャーのペアが通過する状態とサブ状態を定義します。通信モデルは、測定データ送信のさまざまな操作手順を含む、それぞれの状態の開始、終了、およびエラー条件も詳細に定義します。

通信モデルのもう 1 つの機能は、DIM で使用される抽象データ モデリング (オブジェクトの ASN.1 表現) を「転送構文」に変換することです。医療機器エンコード ルール (MDER) と呼ばれる変換プロセスは、オブジェクトに含まれるデータを取得し、通信モデルを使用して送信されるバイナリ メッセージにエンコードします (その他のエンコード ルールもオプションで使用できます)。送信後、メッセージは明確にデコードされ、オブジェクトとそのデータが抽出されます。

MDER ルールは BER ルールのサブセットであることに注意してください。この MDER でエンコードされたオブジェクトの ASN.1 表現は、マシンに依存しないデータ交換方法として XML を使用するのと概念的に似ています (実際、XER 転送構文は ASN.1 オブジェクトを XML で転送します)。ただし、違いは、MDER メッセージは同等の XML メッセージよりもはるかに小さく、マシンが内部データ構造との間で変換するのがはるかに簡単であることです。

このセクションでは、エージェントとマネージャ間で行われるやり取りの一部を示します。UML シーケンス図で示されるやり取りは次のとおりです。

• エージェントが、その構成を認識しないマネージャーに初めて関連付けられました。
• すでに構成を理解しているマネージャーに関連付けられているエージェント。
• マネージャーはエージェント内のスキャナー オブジェクトを初期化します。エージェントはイベントが発生するとデータを送信します。
• 永続メトリック ストアにアクセスして、以前に保存されたデータを読み取ります。

以下の UML シーケンス図は、体重計の PHD エージェントと IEEE 11073 マネージャ (携帯電話や PC など) の間で通常渡されるメッセージを示しています。体重計が初めてオンになり、エージェント (体重計) が関連付け要求 (デバイスを IEEE 11073 PHD デバイスとして識別) を送信しますが、この例ではマネージャはエージェントを認識しません。

そのため、エージェントは、含まれるすべてのオブジェクトの詳細とそれらの静的属性 (この場合は、体重、身長、およびボディマス指数オブジェクト) を含む構成レポートを送信します。マネージャーは、(最上位の) MDS オブジェクトの詳細も要求します。通常、このデータはすべて、将来の参照用に保存されます。

次に、エージェントは測定データ (確認済みイベント レポート内) を送信し、マネージャーから切断します。

次の UML シーケンス図は、2 回目の計量器の動作を示しています。この場合、マネージャーはエージェントを認識しているため、以前に保存した (または他の方法で取得した) 構成データを使用します。

次に、エージェントは測定データ (確認済みイベント レポート内) を送信し、マネージャーから切断します。

スキャナー オブジェクト クラスは、複数のメトリックを 1 つのメッセージ ペイロードに効率的にグループ化できる強力な構造です。スキャナーは、パラメータを監視し、必要に応じてマネージャーに通知を送信する PHD 内のオブジェクトと考えてください。スキャナーは、他の複数のオブジェクトからの測定値を 1 つのメッセージで報告できます。スキャナーには、エピソディック (何らかのイベントが発生したときに通知を送信) と定期的 (一定の間隔で通知を送信) の 2 種類があります。

すべてのエージェントがスキャナー オブジェクトを持っているわけではありません。体重計にはありませんが、パルスオキシメーターにはあります。

パルスオキシメーターのコンテキストでは、エピソード スキャナーを実装して、心拍ごとにイベント レポートをマネージャーに送信できます。周期スキャナーを実装して、たとえば 5 秒ごとに傾向データを含むイベント レポートを送信できます。他のオブジェクトと同様に、スキャナー イベント レポートに含まれるデータは構成フェーズで指定されます。エージェントは送信するデータをかなり柔軟に定義できますが、マネージャーはどのような構成でも理解できます。

スキャナ イベント レポートは、帯域幅の点で非常に効率的になるように設計されています。各イベント レポートで返されるパラメータは構成時に定義されているため、各レポートではオブジェクトを識別してデータ値を渡すだけで済みます。エージェントは、マネージャからの確認応答が必要かどうかを指定できます。マネージャはスキャナを有効または無効にできます (したがって、イベント レポートを送信するかどうかを制御できます)。

次の UML シーケンス図は、スキャナ オブジェクトの操作を示しています。マネージャは SET コマンドを使用してスキャナを起動します (その後、停止します)。その間、エージェントはループし、測定値を含むイベント レポートを送信します。構成によっては、これらのイベント レポートに確認応答が必要な場合があります。スキャナは、通常、患者が監視されている間、数分間または数時間実行されます。

エピソードスキャナーと定期スキャナーのシーケンス図は同じです。

次の UML シーケンス図は、永続メトリック ストア (PM-Store) の動作を示しています。

PM-Store は、シンプルなファイル システムを実装する柔軟な方法を提供します。すべてのエージェントに永続メトリック ストア オブジェクトがあるわけではありません。体重計にはありませんが、パルス オキシメーターにはあります。

この場合、1 つ (または複数) の PM-Store オブジェクトを使用して、タイムスタンプ付きの SpO2 および脈拍数の測定値を保存します。実際のデータは、1 つ以上の PM-Segment オブジェクトに含まれます。この場合、各 PM-Segment オブジェクトには、1 つの継続的なモニタリング セッションからのデータが含まれます。PM-Store オブジェクトは、データを非常に効率的に保存できるほどシンプルですが、デバイスが測定できるあらゆる種類のデータを保存できるほど柔軟です。すべての IEEE 11073 オブジェクトと同様に、エージェントは構成フェーズで PM-Store オブジェクトと PM-Segment オブジェクトの構成を報告するため、マネージャーはデータ形式に関する事前の知識を必要としません。

エージェントは、PM セグメント要素に測定データを入力します。マネージャは、エージェントに問い合わせて、保存されているデータを調べ、対象の PM セグメント オブジェクトごとに、エージェントにデータの送信を開始するように指示します。エージェントは、PM セグメント データを管理可能なサイズのチャンクに分割し、イベント レポートとして連続して送信できます。

マネージャーはエージェントからデータを安全に取得すると、再利用のために PM セグメントをクリアすることがあります。

• 11073.org IEEE 11073 標準グループの Web サイト
• Signove は、オープンソースの IEEE 11073-20601 スタック実装である Antidote (Wayback Machineで 2011-09-26 にアーカイブ) を提供しています。
• Continua Alliance - 相互運用可能な個人用健康機器の業界団体