FHIR ImagingStudyとDICOMweb：メタデータはFHIR、ピクセルはDICOM、そして例

簡単な回答: ImagingStudy は、「この患者がこの日にCT検査を受け、そのシリーズとインスタンスUIDはこれらで、画像はあちらにあります」という情報を示すFHIRリソースです。DICOMweb は、その「あちら」にあたる、ピクセルデータを保持するアーカイブのRESTインターフェースです。FHIRは説明とレポートを運び、DICOMは画像を運びます。ImagingStudyは、connectionType が dicom-wado-rs である Endpoint リソースを参照し、ビューアがこの2つを組み合わせて使用します。

ImagingStudyに含まれるもの

FHIRのImagingStudyリソースには、1回の画像検査に関するメタデータが含まれます。DICOMのStudy Instance UIDが識別子として、ステータス、対象となる患者、診察、開始時間、依頼されたServiceRequest、DICOM DCMボキャブラリからのモダリティコード、シリーズとインスタンスの数、画像が存在するEndpoint、そして各シリーズとそのインスタンス、UIDが含まれます。ピクセルデータは含まれません。

• identifier: DICOM Study Instance UID を urn:oid:1.2.840… の形式で、urn:dicom:uid をシステムとして示します。
• status: registered, available, cancelled, entered-in-error, unknown のいずれか。
• subject: 患者情報。encounter（診察）、started（開始日時）、referrer（紹介元）、basedOn（依頼されたServiceRequest）なども含まれます。
• modality: DICOM独自の語彙（CT, MR, US, CR, DX…）からのコードで、システムは http://dicom.nema.org/resources/ontology/DCM です。
• numberOfSeries: シリーズ数。
• numberOfInstances: インスタンス数。
• endpoint: 画像を取得する場所。
• series[]: 各シリーズについて、Series Instance UID、モダリティ、体部位、instance[]（SOP Instance UIDとSOP Class UIDを含む）が含まれます。

含まれないもの: ピクセルデータ、ウィンドウ設定、完全なDICOMヘッダー、レポートテキスト。レポートは DiagnosticReport リソースで、imagingStudy がこちらを参照します。

有効なFHIR R4の例

有効なFHIR R4のImagingStudyの例には、システムurn:dicom:uidを持つStudy Instance UIDが識別子として、ステータスがavailable、DICOM DCMコードシステムからのCTモダリティ、患者、開始時間、シリーズとインスタンスの数、connectionTypeがdicom-wado-rsのEndpointへの参照、そしてUID、体部位、SOP Class UIDを持つシリーズのエントリが含まれます。

{
  "resourceType": "ImagingStudy",
  "id": "ct-chest-2026-03",
  "identifier": [{"system": "urn:dicom:uid", "value": "urn:oid:1.2.840.113619.2.55.3.2831164356.781.1710415000.1"}],
  "status": "available",
  "modality": [{"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT"}],
  "subject": {"reference": "Patient/example"},
  "started": "2026-03-14T09:12:00+01:00",
  "numberOfSeries": 2,
  "numberOfInstances": 412,
  "endpoint": [{"reference": "Endpoint/pacs-dicomweb"}],
  "series": [{
    "uid": "1.2.840.113619.2.55.3.2831164356.781.1710415000.2",
    "number": 1,
    "modality": {"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT"},
    "bodySite": {"system": "http://snomed.info/sct", "code": "51185008", "display": "Thoracic structure"},
    "numberOfInstances": 410,
    "instance": [{
      "uid": "1.2.840.113619.2.55.3.2831164356.781.1710415000.3",
      "sopClass": {"system": "urn:ietf:rfc:3986", "code": "urn:oid:1.2.840.10008.5.1.4.1.1.2"},
      "number": 1
    }]
  }]
}

SOP Class UID 1.2.840.10008.5.1.4.1.1.2 は CT Image Storage です。Endpointは以下のようになります。

{
  "resourceType": "Endpoint",
  "id": "pacs-dicomweb",
  "status": "active",
  "connectionType": {"system": "http://terminology.hl7.org/CodeSystem/endpoint-connection-type", "code": "dicom-wado-rs"},
  "payloadType": [{"text": "DICOM WADO-RS"}],
  "address": "https://pacs.example-hospital.org/dicomweb"
}

ビューアは、この2つから取得URLを構築します: {Endpoint.address}/studies/{StudyInstanceUID}。その後、メタデータとフレームを取得するために WADO-RS を呼び出します。

ImagingStudyリソースを作成するのは誰か

ImagingStudyリソースは通常、PACSまたはVNAの前面にあるFHIRファサード、または統合エンジンによって、検査が完了した際に作成されます。これは、HL7 v2 ORUまたはDICOM MPPSメッセージによってトリガーされることがよくあります。一部のアーカイブでは、QIDO-RSクエリからオンザフライで生成されます。スキャナー自体はImagingStudyリソースを作成しません。

通常はスキャナではありません。PACSやVNAの前面にあるFHIRファサード、またはインテグレーションエンジンが、検査が完了したとき（多くの場合、HL7 v2 ORUまたはDICOM MPPSメッセージによってトリガーされます）にImagingStudyを作成し、numberOfInstances を同期させます。一部のアーカイブは、QIDO-RSクエリからオンザフライでImagingStudyを生成します。ご自身のプロジェクトで手動で作成する場合、UIDはアーカイブと完全に一致させる必要があります。一文字でも異なると、ビューアは空のスタディを表示します。

ビューアを壊す間違い

FHIR ImagingStudyを読み取るビューアを壊す間違いは以下の通りです。Study UIDをidentifierではなくidに入力する、DICOM以外のモダリティコードを使用する、間違ったconnectionTypeでDICOMwebサーバーを指すEndpointを指定する、画像が変更された後にシリーズとインスタンスの数を最新の状態にしない、そしてDICOMアーカイブではなくFHIR Binaryにピクセルデータを期待することです。

• Study UID を id ではなく identifier に入れる。FHIRのIDはサーバーが割り当てるもので、OIDとは限りません。
• モダリティにSNOMEDやローカルリストのコードを使用し、DICOM DCMコードシステムを使用しない。
• DICOMwebサーバーを指す connectionType が hl7-fhir-rest のEndpoint、またはその逆。
• シリーズ数とインスタンス数を一度だけカウントし、画像が追加または削除されたときに更新しない。
• FHIR Binaryにピクセルデータを期待する。FHIR仕様自体が、画像はBinaryではなくDICOMに属すると述べています。

Anpherosのレコード内

Anpheros Platformは、ImagingStudyやDICOMデータをホストしません。放射線科の所見は、DiagnosticReportまたはDocumentReference（コードとテキストを含むレポート）として到着します。病院がビューアリンクを公開している場合、DocumentReferenceはその添付URLとしてそれを運ぶことができます。画像は、病院のアーカイブ内に、そのアクセスルールに従って保持されます。

関連ページ

• DICOMwebについて
• DICOMタグについて
• DocumentReference vs DiagnosticReport vs Binary
• PACS vs RIS vs VNA
• CTスキャンレポートについて
• 開発者向け: DICOM vs FHIR

情報源

• HL7 FHIR R4: ImagingStudy
• HL7 FHIR R4: Endpoint
• HL7 FHIR R4: endpoint-connection-type コードシステム
• DICOM PS3.16: DCM管理用語（CID 29 Acquisition Modality）
• DICOM PS3.18: Web Services

よくある質問

FHIRサーバーは画像自体を保存できますか？

技術的にはBinaryは任意のバイトを保持できますが、FHIR仕様では画像に対して推奨されておらず、ビューアはそのようには機能しません。画像はDICOMアーカイブに保持され、FHIRはそれにポインタを置きます。

ImagingStudyでFHIR R5で何が変わりましたか？

R5は形状を維持し、命名を整理し（例: procedure が procedureReference と procedureCode に取って代わる）、体部位の処理を調整しています。R4は、多くのアーカイブや国のプロファイルが使用するバージョンとして残っています。

レポートは画像にどのようにリンクしますか？

DiagnosticReport.imagingStudy は ImagingStudy を参照します。DiagnosticReport.media は、主要な画像をMediaリソースとして運ぶことができます。ImagingStudy は、完全なスタディのために Endpoint を参照します。

DICOMwebが既にある場合、ImagingStudyは必要ですか？

他のFHIRコンシューマー（例えば患者アプリ、ケアプラン、研究エクスポートなど）がスタディの存在を知る必要がある場合にのみ必要です。放射線科ビューア単体であれば、QIDO-RSとWADO-RSで動作します。

Anpheros Daily

Anpheros Dailyで試してみる

スキャンや検査レポートをAnpheros Dailyに一元管理し、次回の受診時に提示できるようにしておきましょう。

アプリでの使い方 →

iPhoneとMacAndroidブラウザで開く →

作成者

Anpherosチーム

Anpherosは、患者が管理し、あらゆるクリニックと共有できる医療記録を、EUを拠点とするHL7 FHIR R4プラットフォーム上で構築しています。これらのガイドは、ご自身の健康を理解し整理するのに役立ちますが、医師の代わりになるものではありません。

Anpherosについて →