こんな悩みはありませんか？
「血圧計はBLP、体温計はHTP、パルスオキシメータはPLX…。ヘルスケア機器のBLE開発をしていると、新しいセンサーを載せるたびに『また種別ごとの専用プロファイルか』と感じる」
私自身、ヘルスケア機器のBLE通信ソフトを長く担当してきて、この「デバイス種別ごとに専用プロファイルがある」世界を当然のものとして受け入れてきました。
その前提を作り変えようとしているのが GHS（Generic Health Sensor） です。Bluetooth SIGが策定した比較的新しい規格で、プロファイル仕様（GHSP v1.0）は 2023年6月13日に採択されました。
この記事を読めば、次の3つがクリアになります。
1. GHSが「デバイス種別ごとのプロファイル乱立」をなぜ・どう解決するのか
2. なぜ「実装を種別横断で再利用できる」のか（実務者の視点で）
3. GHSが電子カルテ（FHIR）連携まで見据えている理由
GATTやCharacteristicの基本があやしい方は、先に [BLEの基本構造【GAP / GATT / Service / Characteristic】を読むとスムーズです。
GHSとは何か（最短の定義）
一言で言うと、GHSは 「デバイス種別からデータの運び方を切り離した、汎用ヘルスセンサー用のBLEプロファイル」 です。
Bluetooth SIGの資料では、次のように定義されています。
– GHSは、IEEE 11073-10206 が定義する ACOM（abstract and generic information content model） ——パーソナルヘルスデバイス（PHD）が提供するデータの抽象・汎用モデル——を、
– Bluetooth GATT上に具体実装したもの
つまり「測定値の意味を表すデータモデル（ACOM）」と「それをBLEで運ぶ仕組み（GATT）」を組み合わせた規格、と捉えると分かりやすいです。
なぜ生まれたか——「乱立」を実務者の視点で分解する
GHSの価値は、従来のアプローチが抱えていた課題を知ると腹落ちします。よく「プロファイルの乱立」と一言で語られますが、実装する立場でこれを分解すると、痛みの正体が見えてきます。
図1：デバイス種別ごとに専用プロファイル（BLP=Blood Pressure Profile / HTP=Health Thermometer Profile / PLX=Pulse Oximeter）が存在し、それぞれ通信方式もデータ構造も異なっていた。
① 種別ごとに「通信方式」も「データ構造」も違った
血圧計プロファイル（BLP）、体温計プロファイル（HTP）、パルスオキシメータプロファイル（PLX）……これらは、それぞれで次の2つが別物でした。
| 違っていたもの | 具体的には |
| 通信方式 | どんなGATTサービス・キャラクタリスティックで構成するか |
| データ構造 | 測定値をどう表現するか |
血圧計を実装した経験は、次に体温計を作るときにそのままは使えません。
② 「デバイス側」と「アプリ側」の両方が、種別ごとに実装する必要があった
ここが実務でいちばん効いてくるポイントです。ある種別に対応するには、次の両方が必要でした。
– デバイス側（センサー） が、そのプロファイルの通信方式・データ構造を実装
– スマホ／ゲートウェイ側（コレクター） も、同じプロファイルを個別に実装
新しいセンサーが1つ増えるたびに、「規格策定 → デバイス実装 → アプリ実装 → 相互接続テスト → 認証」という一連の作業が、両側 × 種別数だけ発生していたわけです。この掛け算が、ヘルスケアBLE開発の地味だが重い負担でした。
GHSの発想転換：意味と運びを分ける
GHSはこの構造を、「測定値の意味（データモデル＝ACOM）」と「運び方（GATT）」を分離することで解きます。ポイントは2つです。
① 運び方は共通化する。 データを運ぶ土台は、種別によらず共通の GHS Service（GHSS） に一本化します。血圧計だろうと体温計だろうと、BLEでのやり取りの仕組み自体は同じものを使います。
② 種別の違いは「意味」の側（ACOM）で表す。 では「これは血圧なのか、体温なのか」はどこで区別するのでしょうか。ここで ACOM が効いてきます。ACOM では、測定値（Observation）の一つひとつに標準の識別子コードが付いていて、それが「何の測定値か」を表します。この識別子コードが、IEEE 11073-10101 が定める MDC（Medical Device Communication）コードです。
つまり、種別の違いは「専用プロファイル」ではなく「データに付いた MDC コード」で表現します。共通の通信路（GHSS/GATT）＋データ側の MDC コード——この組み合わせによって、種別ごとに専用プロファイルを作らなくて済むようになる、というわけです。
これを図にすると、旧来との違いがはっきりします。
図2：旧来は種別ごとにデバイス側・コレクター側の両方が個別実装を持つ必要があった。GHSは通信を共通化し、種別の違いをMDCコードで表現することで、実装を種別横断で再利用できる。
– データを運ぶ土台は、種別によらず共通の GHS Service（GHSS）
– 「これは血圧なのか体温なのか」といった種別・項目の違いは、IEEE 11073-10101 の MDC（Medical Device Communication）コード——測定値（Observation）に付く標準の識別子——で表現する
Before / After を並べると、こう変わります。
| 旧プロファイル（Before） | GHS（After） | |
| 通信方式 | 種別ごとに別物 | 共通（GHSS/GATT）に一本化 |
| 種別の区別 | プロファイルそのものが別 | MDCコードで表現 |
| 実装 | 両側 × 種別数だけ必要 | 共通の1実装を再利用 |
| 種別追加時 | 規格策定〜認証を一式やり直し | 通信スタックは再利用できる |
実際、実装ガイドには「GHS実装を他のセンサー種別でも再利用可能にする方法」という章がわざわざ設けられています。新しいセンサー種別を足すときに、通信スタックを一から作り直さなくてよい——これがGHSの一番のねらいです。
もうひとつの狙い：電子カルテ（EHR/FHIR）まで見据えている
GHSを単なる「BLEの通信規格」と捉えると、その射程を見誤ります。Bluetooth SIGはGHSを、エンドツーエンド（E2E）のヘルスケアシステムの一部として設計しています。
鍵になるのが、医療データ交換の標準である HL7 FHIR との連携です。
図3：GHSはACOM（意味）をGATT（運び方）に載せてBLEで伝送する。その値はFHIRのObservationに1対1でマッピングでき、電子カルテ／クラウドまで一気通貫でつながる。
– ACOMのオブジェクトは FHIRリソースに素直に変換できるよう設計されている
– とくに GHSのObservationは、FHIRのObservationデータ要素と1対1でマッピングされる
– 米国では ONC（Office of the National Coordinator for Health IT）が電子カルテ（EHR）でのFHIR採用を強く推奨している
実装者として重要なのは、BLEで測定値を受け取って終わり、ではなく、その値がそのまま電子カルテ側のデータモデルに乗るように設計されている点です。「センサーからクラウド・カルテまで一気通貫」で考えられている——ここは医療機器×BLEをやってきた人ほど価値が分かる部分だと思います。
なぜ今、日本の技術者が知っておくべきか
GHSはまだ新しく、日本語での実務解説はほとんど見当たりません。裏を返せば、早く理解しておくほど有利な領域です。
さらに、ヘルスデータを扱う以上、GHSはセキュリティ・プライバシーとも密接です（実装ガイドにはSecure Connections Onlyモードの推奨などが明記されています）。医療機器サイバーセキュリティの規制——EU CRAやIEC 81001-5-1、FDAのガイダンス——とも接点があり、「通信 × セキュリティ × 規制」をまたいで語れる、数少ない実務領域でもあります。
まとめ
GHSがやったことを3行でまとめます。
1. 種別ごとに乱立していたプロファイル（BLP/HTP/PLX…）を、共通の汎用プロファイルに集約した
2. 「測定値の意味（ACOM）」と「運び方（GATT）」を分離し、種別の違いはMDCコードで表現するようにした
3. さらに FHIR/EHR連携まで見据え、センサーからカルテまでを一気通貫で設計した
デバイス種別が増えても通信スタックを作り直さず、測定値がそのまま電子カルテのデータモデルに乗る——医療機器×BLEをやってきた人ほど、この設計思想の価値は実感しやすいはずです。
参考（一次資料）
– Bluetooth SIG『Generic Health Sensor Profile（GHSP）』v1.0（2023-06-13 採択）
– Bluetooth SIG『Generic Health Sensor Design and Implementation Guide』v2（2024-07-02）
– IEEE 11073-10206（ACOM）／ IEEE 11073-10101（MDC nomenclature）
– HL7 FHIR
この記事はBluetooth SIGの公開仕様・実装ガイド、およびIEEE/HL7の公開情報をもとに構成しています。
コメント