# FHIR vs HL7 v2: 実用的な違い

> 開発者向けに HL7 v2 メッセージと FHIR リソースを比較：フォーマット、トランスポート、両者における同一の検査結果、翻訳の落とし穴、そして Anpheros が v2 を受け入れる場所。

Source: https://developers.anpheros.com/ja/guides/fhir-vs-hl7-v2

**HL7 v2 は 1980 年代後半から病院システム間で交換されてきたメッセージフォーマットです — 「患者入院」や「検査結果準備完了」といったパイプ区切りのイベントがネットワーク接続を介してシステム間でプッシュされます — 一方、HL7 FHIR は Web API 標準であり、アプリケーションは HTTPS を介して JSON で Patient や Observation といったリソースを読み書きします。** これらは一度選択したら終わりというものではありません。多くの病院は内部で v2 を使用し続けており、新しいアプリケーションや患者向け API は FHIR を使用し、統合作業では一方を他方に翻訳することがよくあります。このページでは、コードを書く際に重要なポイントで両者を比較し、同じデータを両者で示し、Anpheros が v2 を受け入れる場所について説明します。

## 並列比較

| | HL7 v2 | HL7 FHIR R4 |
|---|---|---|
| スタイル | イベント駆動型メッセージ (入院、オーダー、結果) | 作成、読み取り、更新、検索するリソース |
| フォーマット | 改行で区切られたテキストセグメント、フィールドは`\|`、コンポーネントは`^` | JSON (または XML) |
| トランスポート | 通常、病院ネットワーク内の TCP 上の MLLP | HTTPS REST |
| クエリ | 限定的。システムは主にプッシュ | 検索パラメータ、`_include`、履歴 |
| セキュリティ | ネットワークレベル (VPN、プライベートリンク) | OAuth 2.0 / SMART on FHIR、TLS、スコープ |
| 柔軟性 | 多くのオプションフィールドとローカル Z セグメント。すべてのインターフェースはネゴシエートされる | 基本リソースとプロファイル (US Core, IPS, European IGs) |
| 一般的なユーザー | 病院内の EHR、ラボ、放射線科、請求システム | アプリ、患者アクセス API、組織間連携、AI |

最も一般的な v2 メッセージ:

| メッセージ | 意味 | 最も近い FHIR リソース |
|---|---|---|
| ADT^A01, A03, A08 | 患者の入院、退院、更新 | `Patient`, `Encounter` |
| ORM / OML | テストのオーダー | `ServiceRequest` |
| ORU^R01 | 結果準備完了 | `Observation`, `DiagnosticReport` |
| SIU | スケジューリング | `Appointment` |
| MDM | ドキュメント | `DocumentReference` |

## 両方における同じ検査結果

ORU^R01 の結果行（OBX セグメント）：

```
OBX|1|NM|2093-3^Cholesterol^LN||212|mg/dL|<200|H|||F|||20261002074500
```

HL7 FHIR R4 Observation での同じ結果。Anpheros がメッセージをインポートした後に保存する形式：

```json
{
  "resourceType": "Observation",
  "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory"}]}],
  "code": {"coding": [{"system": "http://loinc.org", "code": "2093-3", "display": "Cholesterol [Mass/volume] in Serum or Plasma"}], "text": "Cholesterol"},
  "effectiveDateTime": "2026-10-02T07:45:00Z",
  "valueQuantity": {"value": 212.0, "unit": "mg/dL"},
  "interpretation": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation", "code": "H"}]}],
  "referenceRange": [{"high": {"value": 200.0, "unit": "mg/dL"}}]
}
```

フィールドごとの対応：OBX-3 は `code` に、OBX-5 および OBX-6 は `valueQuantity` に、OBX-7 は `referenceRange` に、OBX-8 は `interpretation` に、OBX-11 は `status` に、OBX-14 は `effectiveDateTime` になります。HL7 は、セグメント、データ型、および語彙のマッピングを含む公式の [HL7 Version 2 to FHIR](https://build.fhir.org/ig/HL7/v2-to-fhir/) 実装ガイドを公開しています。

## 翻訳で間違いが起こる場所

- **タイムゾーン。** v2 のタイムスタンプ（例: `20261002074500`）はオフセットを持たないことが多く、送信者のゾーンを知る必要があります。FHIR は、時間が存在する場合には常にゾーンを要求します。（Anpheros はゾーンのない v2 タイムを UTC として読み取ります。オフセットがある場合は送信してください。）
- **ローカルコード。** 多くのラボでは、LOINC の代わりに独自のコードを OBX-3 に設定します。適切な翻訳では、ローカルコードを削除するのではなく、保持し、可能な場合は LOINC にマッピングします。
- **繰り返し送信。** v2 の送信者は、タイムアウト時に再送信します。結果ごとに安定した識別子がないと、FHIR ストアは重複でいっぱいになります。
- **すべてがオプション。** 同じフィールドが空であったり、繰り返されたり、2 つの送信者によって異なる方法で使用されたりする可能性があります。FHIR 側を検証してください。[FHIR R4 validator](https://developers.anpheros.com/tools/fhir-validator) は、翻訳されたリソースに何が欠けているかを示します。
- **修正。** v2 の結果ステータス `C`（修正済み）は、既存の Observation を更新し、その履歴を保持すべきであり、2 番目の Observation を作成すべきではありません。

## いつ、どれを使用するか

- **病院内、既存システム間:** 通常、システム間では v2 が使用されます。インテグレーションエンジンがメッセージをルーティングおよび変換します。
- **アプリケーション、患者アクセス API、または組織をまたぐものを作成する場合:** FHIR を OAuth および同意と組み合わせて使用します。
- **AI または分析へのデータ提供:** FHIR はクエリ可能で、コード化され、バージョン管理されているため、適しています。
- **両方:** 一般的な実運用パターンとして、ラボまたは EHR から v2 を受信し、FHIR として保存し、アプリケーションに FHIR として提供します。

## Anpheros の位置づけ

Anpheros は、患者記録を FHIR R4 として保存し、HL7 v2 メッセージタイプを 1 つ受け付けます。それは **ORU^R01 ラボ結果**で、HTTPS 経由で [ラボコネクタ](https://developers.anpheros.com/ja/guides/lab-connector) (`POST /v1/patients/{id}/labs/import` と `Content-Type: x-application/hl7-v2+er7`) に送信されます。各 OBX は、LOINC コード、参照範囲、解釈を含むラボの Observation になります。レポート ID はプロビナンスに保持され、再送信されたレポートはスキップされます。新しい値を持つ修正された結果 (OBX-11 = `C`) は、ステータス `amended` の新しい Observation として保存されます。元の結果はそのまま保持されるため、ソースが修正を送信する場合は、以前の Observation に `entered-in-error` をマークするか、FHIR API を介して更新してください。実例は [Lab results API](https://developers.anpheros.com/ja/guides/lab-results-api) です。

他の v2 メッセージ (ADT、オーダー、スケジューリング) は受け付けず、MLLP でリッスンせず、v2 を送信しません。それらの場合、Anpheros の前面にある統合エンジンが FHIR に変換し、API を介して書き込みます。

## よくある質問

### FHIR は HL7 v2 を置き換えますか？
すぐには置き換わりません。v2 は、多くの病院で引き続き基盤として使用されています。これは、v2 が機能し、既存のシステムに組み込まれているためです。FHIR は、アプリ、患者アクセス、組織間の交換などで v2 の周りで成長しており、両者は共存し、しばしば相互に変換されます。

### MLLP とは何ですか？
Minimal Lower Layer Protocol の略です。TCP 接続上で v2 メッセージをフレーム化する簡単な方法で、各メッセージの開始文字と終了文字、および確認応答 (ACK) が返されます。FHIR は代わりに HTTPS を使用します。

### HL7 v2 メッセージを FHIR に自動変換できますか？
ほとんどの場合可能です。HL7 の v2-to-FHIR 実装ガイドには標準マッピングが記載されており、インテグレーションエンジンがそれを実装しています。ローカルコード、Z セグメント、タイムゾーン、および各送信者がオプションフィールドをどのように使用するかについては、手動での作業が必要になる場合があります。

### Anpheros は HL7 v2 を受け入れますか？
はい、検査結果については可能です。ラボコネクタに HTTPS 経由で投稿された ORU^R01 メッセージは、FHIR Observation になります。その他の v2 メッセージタイプおよび MLLP 接続はサポートされていません。

## 関連情報

- [HL7 v2 から FHIR へのマッピング](https://developers.anpheros.com/ja/guides/hl7-v2-to-fhir-mapping): セグメントとフィールドのマッピング、およびコンバーター
- [検査結果 API: HL7 v2, FHIR, および LOINC](https://developers.anpheros.com/ja/guides/lab-results-api)
- [FHIR レコードへの検査結果のインポート方法](https://developers.anpheros.com/ja/guides/import-lab-results-fhir)
- [医療データ相互運用性](https://developers.anpheros.com/ja/guides/interoperability)
- [DICOM vs FHIR: 画像データと臨床データ](https://developers.anpheros.com/ja/guides/dicom-vs-fhir)
- [FHIR プラットフォーム](https://developers.anpheros.com/ja/guides/fhir)