# DICOM と FHIR：画像データと臨床データ

> DICOM は医療画像を、FHIR はそれらを取り巻む臨床データを扱います。それぞれの役割、ImagingStudy と DiagnosticReport の連携、そしてどこに何を保存すべきかについて説明します。

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

**DICOM と FHIR は競合するものではありません。DICOM は医療画像（X線、CT、MRI のピクセルおよび技術的なメタデータ）の標準であり、HL7 FHIR はそれらを取り巻む臨床データ（オーダー、放射線科医のレポート、所見、患者情報など）の標準です。** 一般的な画像ワークフローでは両方が使用されます。スキャナーと PACS は DICOM を使用し、病院や患者向けアプリケーションは FHIR を使用します。FHIR リソースは DICOM スタディをコピーするのではなく、それにリンクします。このページでは、各標準の範囲、連携方法、そして Anpheros のような FHIR バックエンドが何を保存すべきで、何を保存すべきでないかについて説明します。

## 短い回答

| | DICOM | HL7 FHIR R4 |
|---|---|---|
| 運ぶもの | 画像とそのメタデータ（モダリティ、部位、スライス間隔、デバイス、UID） | 臨床データ：患者、オーダー、レポート、観察結果、薬剤… |
| 通常のサイズ | スタディあたりメガバイトからギガバイト | リソースあたりキロバイト |
| データの単位 | Study → Series → Instance、グローバルに一意なUIDで識別 | リソース（Patient, ServiceRequest, ImagingStudy, DiagnosticReport…）と参照 |
| 転送 | DIMSEネットワークサービス（C-STORE, C-FIND, C-MOVE）およびDICOMweb REST（QIDO-RS, WADO-RS, STOW-RS） | HTTPS上のREST（JSONまたはXML） |
| 保存場所 | PACSまたはベンダーニュートラルアーカイブ（VNA） | EHR、FHIRサーバー、ヘルスデータプラットフォーム |
| 読み取るもの | レントゲンビューア、AI画像モデル、モダリティ | 臨床アプリ、患者アプリ、分析、テキストと値に基づくAI |

## DICOMの目的

DICOM (Digital Imaging and Communications in Medicine) は、画像がどのようにエンコードされ、画像機器間でどのように交換されるかを定義します。各画像ファイルは、ピクセルデータの隣に、患者および検査の識別子、モダリティ (`CT`, `MR`, `DX`, `US`…)、取得パラメータ、ピクセル間隔など、数百の属性を持つヘッダーを運びます。画像は、スタディ内のシリーズ内のインスタンスとしてグループ化され、それぞれに `2.25.181945…` のようなUIDが付与されるため、同じスタディをどのアーカイブでも再度見つけることができます。

DICOMweb は DICOM を HTTP にもたらしました: 検査を検索するための `QIDO-RS`、それらを取得するための `WADO-RS`、それらを保存するための `STOW-RS`。これにより、画像は Web ビューアやクラウドサービスから到達可能になりますが、ペイロードは依然として DICOM です。

DICOM が得意としないのは、臨床的なストーリーです。なぜその検査がオーダーされたのか、放射線科医は何を結論付けたのか、どの問題に関連しているのか、そしてそれが検査結果や投薬とどのように関連しているのか。それは FHIR の仕事です。

## FHIR が画像処理に関して行うこと

FHIR R4 には、画像処理ワークフローの各ステップに対応するリソースがあります。

- **ServiceRequest** — オーダー：「胸部X線、2方向、肺炎疑い」。
- **ImagingStudy** — DICOM スタディの概要（UID、モダリティ、シリーズ数、インスタンス数、部位）と、画像を取得できる場所（例：DICOMweb WADO-RS アドレス）を示す `endpoint`。ピクセルは含まれません。
- **DiagnosticReport** — 放射線科医のレポート：コード、ステータス、結論、発行日時、およびオプションで、元のレポートを PDF として `presentedForm` に含めることができます。`imagingStudy` はこれをスタディにリンクします。
- **Observation** — クエリ可能な個々の所見または測定値（例：結節のサイズ）。
- **DocumentReference** — PDF レポートや JPEG としてエクスポートされたキー画像などのドキュメント。

PACS のスタディを指す ImagingStudy（有効な FHIR R4 構造）：

```json
{
  "resourceType": "ImagingStudy",
  "status": "available",
  "subject": {"reference": "Patient/example"},
  "identifier": [{"system": "urn:dicom:uid", "value": "urn:oid:2.25.181945102383749012843512396725468820"}],
  "started": "2026-10-03T10:20:00-05:00",
  "modality": [{"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "DX"}],
  "numberOfSeries": 1,
  "numberOfInstances": 2,
  "endpoint": [{"reference": "Endpoint/pacs-wado"}],
  "series": [{
    "uid": "2.25.30584718293846127394857102938475",
    "modality": {"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "DX"},
    "bodySite": {"system": "http://snomed.info/sct", "code": "51185008", "display": "Thoracic structure"},
    "numberOfInstances": 2,
    "instance": [{"uid": "2.25.11223344556677889900112233445566",
                  "sopClass": {"system": "urn:ietf:rfc:3986", "code": "urn:oid:1.2.840.10008.5.1.4.1.1.1.1"}}]
  }]
}
```

同じスタディのレポートを DiagnosticReport として（[FHIR R4 バリデーター](https://developers.anpheros.com/tools/fhir-validator) を通過します）：

```json
{
  "resourceType": "DiagnosticReport",
  "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v2-0074", "code": "RAD", "display": "Radiology"}]}],
  "code": {"coding": [{"system": "http://loinc.org", "code": "36643-5", "display": "XR Chest 2 Views"}], "text": "Chest X-ray, 2 views"},
  "subject": {"reference": "Patient/example"},
  "effectiveDateTime": "2026-10-03T10:20:00-05:00",
  "issued": "2026-10-03T15:05:00-05:00",
  "performer": [{"display": "Springfield Imaging Center"}],
  "conclusion": "No acute cardiopulmonary abnormality.",
  "presentedForm": [{"contentType": "application/pdf", "url": "https://imaging.springfield-hospital.test/reports/RPT-8812.pdf", "title": "Radiology report"}]
}
```

## 両者の連携方法

```
 modality (X-ray, CT, MR) ──DICOM──► PACS / VNA ◄──DICOMweb (WADO-RS)── image viewer, AI image model
                                         ▲
                     ImagingStudy.endpoint│ (where the images are)
                                         │
 order (ServiceRequest) ──► study ──► report (DiagnosticReport) ──► patient record (FHIR)
                                                                       │
                                     patient app, clinic system, AI assistant (text and values)
```

システムをシンプルに保つための原則：**画像は画像アーカイブに保管し、臨床記録にはレポート、重要な所見、そして画像のポインターを保持します。** DICOMスタディを臨床データベースにコピーすると、ほとんどの読者にとって記録がより有用になるわけでもないのに、ストレージとプライバシーのリスクが増大します。

他の標準規格が病院間のギャップを埋めます。IHEプロファイル（組織間で画像ドキュメントを共有するためのXDS-Iなど）や、放射線ビューアとレポートアプリケーションを同じ患者とスタディに同期させるためのFHIRcastなどです。

## 画像、相互運用性、およびAI

医療画像におけるAI（検出、セグメンテーション、トリアージ）は、通常、画像部門または専門プラットフォーム内でDICOMピクセルデータを扱います。患者や医師が記録全体について推論するのを支援するAI（「前回の胸部X線検査は何を示しており、咳や抗生物質とどのように関連していますか？」）は、レポート、所見、およびその他の臨床データ（FHIRが扱うもの）を扱います。どちらの種類のAIも、インフラストラクチャに同じものを必要とします。それは、コード、時間、および記録された出所を持つデータです。

## Anpheros の位置づけ

Anpheros は、各患者の記録を HL7 FHIR R4 として保存します。画像に関しては、以下のようになります。

- **保存されるもの:** 放射線科レポートは `DiagnosticReport` として、元のレポートまたはキー画像は `DocumentReference` (ドキュメントあたり最大 25 MiB) として、所見は `Observation` として、オーダーは `ServiceRequest` として保存されます。各書き込みには来歴が付随し、患者はどのアプリケーションがそれを読み取れるかを決定できます。
- **保存されないもの:** DICOM スタディ。Anpheros は PACS ではなく、DICOMweb インターフェースを持たず、現時点では `ImagingStudy` リソースをサポートしていないため、画像をインデックス化したり提供したりすることはできません。画像は読み取ったり解釈したりしません。

Anpheros Daily アプリでは、患者は画像レポートを写真撮影またはアップロードして、記録の他の部分と並べてドキュメントとして保持できます。アプリケーションを開発する開発者やクリニックの統合担当者にとって、実用的な分割は次のようになります。画像を画像システムに保持し、レポートと所見を患者の FHIR レコードに書き込みます。[クリニックシステムを FHIR バックエンドと統合する方法](https://developers.anpheros.com/ja/guides/integrate-clinic-systems-fhir) は、1 つのトランザクションで訪問とそのドキュメントを書き込む方法を示しており、[DiagnosticReport の例](https://developers.anpheros.com/tools/fhir-examples/diagnostic-report) はレポートの構造を示しています。

## よくある質問

### DICOMとFHIRの違いは何ですか？
DICOMは医療画像とその技術的なメタデータをエンコードおよび交換します。FHIRは、オーダー、レポート、観察結果、投薬などの臨床データを交換します。実際には、FHIRリソースは画像スタディを記述および参照し、画像自体はDICOMに残ります。

### FHIRは医療画像を保存できますか？
FHIRは、小さな画像を添付ファイル（DocumentReferenceまたはMediaのキー画像）として運ぶことができますが、完全な診断スタディ向けには設計されていません。ImagingStudyリソースはDICOMスタディを記述し、取得できる場所を指します。ピクセルはPACSまたはアーカイブに残ります。

### DICOMwebとは何ですか？
DICOM標準のRESTfulな部分です。QIDO-RSは検索、WADO-RSは取得、STOW-RSはHTTP経由でのスタディの保存に使用されます。FHIR ImagingStudyはDICOMwebエンドポイントを指すことができます。

### どのFHIRリソースに放射線レポートが含まれますか？
DiagnosticReport。放射線カテゴリ、検査のLOINCコード、結論、および必要に応じて、`presentedForm`のPDFとしての元のレポートが含まれます。検索可能でなければならない測定値は、個別のObservationsになります。

### AnpherosはDICOMをサポートしていますか？
いいえ。Anpherosは、患者のFHIR R4レコードに、画像に関する臨床サイド（レポート、所見、ドキュメント、オーダー）を保存します。DICOM画像を保存、提供、または解釈せず、現時点ではImagingStudyをサポートしていません。

## 関連情報

- [医療データ相互運用性](https://developers.anpheros.com/ja/guides/interoperability): FHIR に関する標準規格
- [FHIR プラットフォーム](https://developers.anpheros.com/ja/guides/fhir): Anpheros が格納する 26 種類の FHIR リソース
- [FHIR とカスタム医療データベースの比較](https://developers.anpheros.com/ja/guides/fhir-vs-custom-database)
- [検査結果 API](https://developers.anpheros.com/ja/guides/lab-results-api): 検査レポートにおける同様のパターン
- [クリニックシステムと FHIR バックエンドの統合方法](https://developers.anpheros.com/ja/guides/integrate-clinic-systems-fhir)