HL7 FHIR Observationとは｜医療DXの中心を担うリソースを専門家が徹底解説
HL7 FHIR（Fast Healthcare Interoperability Resources）の中でも、最も利用頻度が高く、 医療データ交換の中心的役割を担うリソースが「Observation」です。 検査結果、バイタルサイン、スコアリング、デバイス測定値など、 医療現場で日々生成される“観察データ”のほぼすべてがObservationで表現されます。
本記事では、FHIR R4/R5の最新動向、JP Coreとの違い、実装パターン、検索APIの実務まで、 医療DXの専門家視点で体系的に解説します。
HL7 FHIR Observationとは何か
Observationの定義と役割
Observationは「患者・デバイス・その他の対象に対する測定や観察事実」を表すFHIRリソースです。 血液検査、尿検査、体温、血圧、SpO2、スコアリング（NEWS、SOFA）など、 医療データの大部分がObservationとして表現されます。
FHIR全体における位置づけ
Observationは単体で完結することは少なく、以下のリソースと密接に連携します：
- Patient：対象患者
- Encounter：測定が行われた診療文脈
- Device：測定に使用したデバイス
- DiagnosticReport：検査レポートの親リソース
R4/R5でのObservationの進化ポイント
R5ではObservationに関連する拡張が増え、bodyStructure や triggeredBy など、 より詳細な臨床文脈を表現できるようになりました。 これにより、画像診断やデバイス連携など、複雑なユースケースにも対応しやすくなっています。
Observationリソースの基本構造（R4ベース）
必須要素 status と code の意味
Observationの実装で最も重要なのがこの2つです。
- status：検査結果の状態（final / amended / cancelled など）
- code：何を測定したか（LOINCなどのコード体系を使用）
subject と effective[x] の重要性
subject は患者・デバイスなどの対象を示し、 effectiveDateTime や effectivePeriod は測定時刻を表します。 医療データの時系列分析では、この2つが正しく設定されていることが必須です。
value[x] の型と使い分け
Observationの値は value[x] で表現され、以下のように複数の型を取れます：
- valueQuantity（数値）
- valueCodeableConcept（コード）
- valueString（文字列）
- valueDateTime（時刻）
値が存在しない場合は dataAbsentReason を用いて、 「未実施」「測定不能」「患者拒否」などの理由を明示します。
補助要素（referenceRange / interpretation / performer）
基準範囲（referenceRange）や判定（interpretation）は検査結果の臨床的解釈に不可欠です。 また、performer には検査を実施した医療者や機器を紐づけます。
Observationの実装パターンと注意点
value[x] の型選択の実務判断
医療DXの現場では、データ分析やシステム連携を考慮して型選択を行います。 例えば、血糖値は valueQuantity、判定コメントは valueString、 病理診断の分類は valueCodeableConcept を使うなど、 データの性質に応じた選択が求められます。
データ欠損時の dataAbsentReason の使い方
欠損理由を明示することで、データ分析時に「ゼロ」と誤解されることを防ぎます。 これは医療AIモデルの精度にも直結する重要なポイントです。
複合データの表現（component / hasMember）
血圧（収縮期・拡張期）など複数値を持つ項目は component を使用します。 また、複数のObservationを束ねる場合は hasMember を利用します。
プロファイル適用時の制約（JP Core / 英国系）
JP Coreでは必須要素やコード体系が追加で定義されており、 国内システム間連携ではJP Core準拠が求められるケースが増えています。
Observationの検索・取得（実務でよく使う操作）
患者単位での検索（subject=）
/Observation?subject=Patient/123項目単位での検索（code=）
/Observation?code=LP1234-5期間指定での検索（date=）
/Observation?date=ge2024-01-01&date=le2024-01-31最新値取得 $lastn のユースケース
バイタルや検査結果の「最新セット」を取得する際に利用されます。
/Observation/$lastn?subject=Patient/123&max=5傾向確認・時系列分析のための取得方法
医療AIやダッシュボードでは、Observationの時系列データが重要な役割を果たします。 FHIRの検索APIは、こうした分析基盤との相性が非常に良い設計になっています。
R5におけるObservationの新要素と差分
追加された構造（bodyStructure / triggeredBy など）
R5では観察対象の部位や、観察が引き起こされたイベントを表現できるようになり、 よりリッチな臨床文脈を扱えるようになりました。
拡張ガイド・派生プロファイルの増加
R5ではObservation関連の派生ガイドが増加し、特定領域（デバイス連携、画像診断など）に特化したプロファイルが整備されています。
R4→R5でのコード体系・値セットの差分
値セットの更新により、より精緻な分類が可能になっています。 特に検査コード体系（observation-codes）の差分は実装時に確認が必要です。
国別・業界別プロファイルの比較
JP Core Observation Common の特徴
JP Coreでは、国内医療機関で一般的に使用される検査項目やコード体系に合わせた制約が追加されています。 これにより、国内システム間の相互運用性が向上します。
英国 Virtually Healthcare プロファイルの特徴
英国系プロファイルでは、NHSの要件に合わせた構造が定義されており、 特にデバイス連携や遠隔医療のユースケースに強みがあります。
国別プロファイルの差分が実装に与える影響
国別プロファイルの違いは、コード体系、必須要素、拡張の扱いに影響します。 グローバル展開する医療システムでは、これらの差分を吸収する設計が求められます。
Observation導入ステップ（医療機関・LIMS向け）
現状データの棚卸し（コード体系・項目粒度）
まずは既存システムの検査項目・コード体系・粒度を整理し、 Observationへのマッピング可能性を評価します。
FHIRマッピング設計（Observation中心）
Observationは検査データの中心となるため、value[x] の型選択、component構造、コード体系の統一が重要です。
PoCでの確認ポイント（value[x] / component / lastn）
PoCでは、検索APIの性能、最新値取得、時系列データの整合性などを重点的に確認します。
本番移行と運用設計（バージョン管理・R5対応）
FHIRはバージョン進化が早いため、R4→R5の差分を踏まえた運用設計が求められます。
FAQ（初心者〜実装者向け）
ObservationとDiagnosticReportの違いは？
DiagnosticReportは「検査レポート全体」、Observationは「個々の測定値」を表します。
valueQuantityとvalueStringはどう使い分ける？
数値はvalueQuantity、コメントや所見はvalueStringを使用します。
最新値だけ取得したい場合は？
$lastn を使用することで、最新の検査セットを効率的に取得できます。
JP Coreと標準FHIRのどちらを優先すべき？
国内システム連携ではJP Core準拠が推奨されますが、グローバル展開では標準FHIRとの整合性も重要です。
コメント