_かたろう会

放射線治療を陰で支える

DICOM

ー 個別対応から標準化 ー

平成27年9月12日（土）

本日の話題

• 放射線治療部門を取り巻く現状

•

DICOMとDICOM RT

• 事例紹介からそれぞれの情報について

• 不具合事例

• 現時点で検討されている規格拡張

放射線治療特有の事情

• 複数の装置（マルチベンダー連携）

– 治療計画用画像取得システム、治療計画システム、QAシステム、患者 位置照合システム、放射線治療装置、放射線治療管理システムなど、 複数の装置が用いられ、必ずしも同じベンダーによる製品とは限らな い – 治療計画装置、治療装置は輸入製品が主で、国産の情報システムと の連携の際に問題が起きる事がある

• 治療スケジュール

– 複数回に分割して照射が行われるために、これに伴うスケジュール管 理が必要

• 患者の体型や体位の変化

– 複数回の照射における照射位置の再現性、治療効果判定などで多く の画像情報が必要とされる

放射線治療で用いられるモダリティ

• 一般に「モダリティ：

Modality」という言葉は、CT、CR、MRなど

の画像取得装置（システム）を指す。よってここではそれらの

画像取得装置を画像モダリティ、放射線治療を行うために用

いられる装置を放射線治療モダリティと呼ぶ

• やり取りされる際に用いられる

ITインフラ（LAN、WAN、WiFi他）

やセキュリティ対策、利用される端末（

PC、UNIX、Tablet）など

と、やり取りされる情報並びに手段については異なるレイヤー

として捉える

• 画像モダリティ、治療モダリティ間の連携は標準化された規格

があるものについてはそれを利用し、不十分なものは拡張や

カスタマイズで対応し、無いものについては独自方式にて対

応

個別化？標準化？

• 新製品、新しい技術では個別対応が必須

– 何らかの決め事が無いとシステムとして成立しない – 同様のものが多く出回るようになると複数の基準が出来てしまう フォーマットの乱立→個別対応→相互利用が困難

• 標準化

– 製品仕様や方式、フォーマットなどをそろえる、互換性を考慮 → エンドユーザーの選択肢を拡大 – 最低限の項目について検討

• 個別化

– 標準化ではカバーしきれない部分を補完 – 次なる標準化への足掛かり

• 個別対応

→ 標準化 → 個別化

行いたいことは患者の治療

• 画像モダリティ、治療モダリティを利用して、患者

を治療する事が目的

– 各機器の操作担当者は治療行為に専念したい

• 各機器間連携や情報の活用は出来た方が便利

– 必ずしも中身を知らなくても使える

• 仕組みや中身を知っていると

– トラブル発生時にソリューションを見つけやすい

– やりたいことと出来る事の落としどころを判断しやす

い

– 二次利用する時に便利

本日の話題

• 放射線治療部門を取り巻く現状

•

DICOMとDICOM RT

• 事例紹介からそれぞれの情報について

• 不具合事例

• 現時点で検討されている規格拡張

DICOM RTって何？

• 「

DICOM RT規格」というものは存在しない

•

DICOMにおける放射線治療分野の情報につ

いてまとめたものの総称

• 装置固有の情報を、同じカテゴリーのものの

やり取りをしやすいように定められている

• あくまでも

DICOMの一部なので、基本的なお

約束は

DICOMに準ずるが、放射線治療の常

識を考慮している

そもそも

DICOMって何？

• 「

Digital Imaging and Communication of Medicine：医療におけるデ

ジタル画像と通信」の略語

• デファクトスタンダード（

de facto：ラテン語）、つまり業界における事

実上の標準

• 規格機関から追認する形でのスタンダード

•

ACR（米国放射線学会）とNEMA（米国電気製品工業会）の共同で

開発され、

ACR-NEMA V1.0（1985）、ACR-NEMA v2.0（1988）を経て

1990年ごろからDICOMとして名称を変えて現在に至る。

•

ACR-NEMA v3.0に相当する出発点から、DICOM3（ダイコムスリー）

や

DICOM 3.0などと当初は呼ばれていた

• 当初は、「

CT」、「MR」、「CR」についての標準化が目的で、対象画

像の種類、画像以外の情報の標準と拡張が進んでいる

DICOMのお約束

• 取扱いたい情報のフォーマットの規定

– 情報を分類して「

Object：オブジェクト」として利用

– オブジェクト間連携をきめる

– オブジェクトの書式や必須・排他などの決め事をする

• やりとりする方式の規定

– やりとりしたい方式（サービス）を明確にする

– もの（オブジェクト）と情報そのもの（電文）のやりとりを区分

•

ITインフラについてはスコープ外

• オブジェクト、サービス、やり取りするための基本情報（

AE

タイトル、ポート番号）を明確にする

• 適合内容や適合範囲を

DICOM Conformance Statement

DICOM規格

• 始まりは

CT、MR、CRといった画像モダリティ

– 画像、検査などのなごりが現在でも和訳として残って

いる

• 既定の集合体

–

PS 3.1からPS 3.20の20巻構成による本文

– 補足する

Supplement

– 改訂提案である

CP（Correction Proposal）

• 全てを理解している人、全てに対応する製品は

存在しない

• 基本ルール、本文の該当箇所、関連する

Supplement等を理解すれば事足りる

DICOM Standard

• DICOM標準規格の各巻PS3.1-PS3.20

– PS3.1 Introduction and Overview – PS3.2 Conformance

– PS3.3 Information Object Definitions – PS3.4 Service Class Specifications – PS3.5 Data Structures and Encoding – PS3.6 Data Dictionary

– PS3.7 Message Exchange

– PS3.8 Network Communication Support for Message Exchange – PS3.9 Retired

– PS3.10 Media Storage and File Format for Media Interchange – PS3.11 Media Storage Application Profiles

– PS3.12 Formats and Physical Media – PS3.13 Retired

– PS3.14 Grayscale Standard Display Function

– PS3.15 Security and System Management Profiles – PS3.16 Content Mapping Resource

– PS3.17 Explanatory Information

– PS3.18 Web Access to DICOM Persistent Object (WADO) – PS3.19 Application Hosting

DICOM Standard (Cont.)

• DICOM標準規格の各巻PS3.1-PS3.20(日本語名称） – PS3.1 序文と概論 – PS3.2 適合性（コンフォーマンス） – PS3.3 情報オブジェクト定義 – PS3.4 サービスクラス仕様 – PS3.5 データ構造と符号化 – PS3.6 データ辞書 – PS3.7 メッセージ交換 – PS3.8 メッセージ交換のためのネットワーク通信サポート – PS3.9 リタイア（メッセージ交換のための二点間通信サポート） – PS3.10 媒体相互交換のための媒体保存とファイルフォーマット – PS3.11 媒体保存応用プロファイル – PS3.12 媒体フォーマットと物理媒体 – PS3.13 リタイア（プリント管理二点間通信サポート） – PS3.14 グレイスケール標準表示関数 – PS3.15 セキュリティとシステム管理プロファイル – PS3.16 コンテンツマッピングリソース – PS3.17 説明的情報 – PS3.18 DICOM保持オブジェクトへのウェブアクセス (WADO)

DICOMとDICOM RT

•

DICOM RTとは

–

DICOMにおける、放射線治療分野の情報について規定されて

いるものの総称（通称）

–

DICOM規格における、Modalityのひとつとして定義されており、

(0008,0060)Modalityの値に「RTｘｘｘ」等として記述

• ベンダーや装置（システム）固有のフォーマット・プロトコルによる情

報のやり取りから、共通仕様に基づく情報交換への移行を目的

•

2015年2月現在では、PS3.1からPS3.20の20巻による本文と、各種

補遺（

Supplement）及び改訂提案（CP）によって規格化されている

– 最新版は、DICOM 2015c

DICOM

DICOM RT

放射線治療の種類

• 放射線治療は、以下に大別する事が出来ます

– リニアックによる外部照射（X線・電子線） – 粒子線による外部照射（粒子線・重粒子線） – リモートアフターローディングシステムによる腔内・組織内照射（密封小 線源治療：Brachytherapy） – シード線源による組織内照射（密封小線源治療Brachytherapy）

CT/MR

放射線治療関連機器連携

• CT/MR/PET … などの画像モダリティ

• CT Sim/Image Fusion System/TPS等の計画系システム • TU（LINAC/Afterloader/Ion Therapy)などの治療装置

TPS R&V LINAC

CT / MR Object RT Plan

CT Sim

DICOM Storage SCP/SCU

CT Object RT Structure Set RT Plan RT Plan Treatment Record RT Structure RT Plan RT Dose RT Image Archive

DICOM RTの開発の履歴

No Supplement 適用範囲 オブジェクト

11 Radiotherapy

Information Object

治療計画情報 RT Structure Set、RT Plan、 RT Dose、RT Image

29 Radiotherapy

Treatment Record and Media Extentions

照射記録 _{RT Beam Record、RT} Brachy Record、RT Treatment Summary 102 Radiotherapy

Extention for Ion Therapy

粒子線拡張 _{RT ION Plan。RT ION} Record 74 Utilization of Worklist in Tadiotherapy Treatment Delivery （外部照射） 照射スケジュール、 実施の指示、進捗管 理 RT Treatment Delivery Instruction（Beam、Ion Beam）

本日の話題

• 放射線治療部門を取り巻く現状

•

DICOMとDICOM RT

• 事例紹介からそれぞれの情報について

• 不具合事例

• 現時点で検討されている規格拡張

治療計画を送りたい

•

Case 1 治療計画装置で作成した治療計画をLINACへ

送りたい

– 「

RT Plan」というオブジェクトでやり取りする

例） Pinnacleで作成した治療計画をMosaiqへ送る 例） Oncentraで作成した治療計画をmHDRへ送る

•

Case 2 IMRTのためのパラメータを保存したい

– 「

RT Plan」と「RT Structure Set」を用いる

•

Case 3 CT Simulatorで作成したビームセットアップを

使って線量計算は計画装置でしたい

DICOM RT Plan

• Beam Setup情報などの治療装置に対する計画情報

• (0008,0016)SOP Class UIDは、1.2.840.10008.5.1.4.1.1.481.5

• (0008,0060)Modalityの値はRTPLAN

• DICOM RT Structure Set IODを参照

• CT Simulatorにて作成されるBeam Setupなどの様な幾何学的設定情報の

みのGeometric Planの場合と、TPSにて計算されたMU値を含むDosimetric

Planの場合があり、いずれもRT Planとして扱う

• 放射線治療の種類により、組み込まれるModuleが異なる

– RT Beams Module：External Beamの場合

DICOM RT Plan

• 想定されている利用目的

– 治療装置へ照射情報を提供 – 治療計画関連装置（計画装置、RT Viewer、QA機器など）での相互利用

•

IMRT等の計画における目的関数などの情報を含みうる

•

DRR等のRT Imageはこれを参照

BEV/DRRや透視画像はどうなの？

•

Case 1 治療計画装置上で見えているBEV（DRR)をLINACへ

送って位置照合で使いたい

– 「

RT Image」というオブジェクトでやり取りする

–

CRなどの画像と異なり、「RT Plan」のどの門の画像かといった

ひもづき情報を持っている

•

Case 2 IMRTのFuluence Mapの扱いは？

– 「

RT Image」が利用可能

•

Case 3 小線源治療用画像の角度情報をオンラインで使

いたい

DICOM RT Image

• 放射線治療に関連するデバイスによって作成される画像情報

• (0008,0016)SOP Class UIDは、1.2.840.10008.5.1.4.1.1.481.1

• (0008,0060)Modalityの値はRTIMAGE • (0008,0008)Image Typeとしては次のタイプが規定されています – DRR ＝ TPS等にて作成されたBEV等のDRR – PORTAL ＝ EPIDによって取得された画像 – SIMULATOR ＝ コンベンショナルなシミュレータ画像 – RADIOGRAPH ＝ ラジオグラフィー – BLANK ＝ イメージピクセルがバックグラウンドの値として扱う – FLUENCE ＝ フルエンスマップ

•

Pixel Spacingは撮像面における情報として記録

•

Gantry Angle等の照射角度情報等を含む

• DICOM CR、SC画像等との違いは、RT Plan等の情報（ガントリーアングル、コ リメータアングル等）を参照して対応可能とするような情報を有しているか 否か

DICOM RT Image

• 想定されている利用場面

– 「絵」としてのバイナリデータに加えて、ガントリーアングル

等の情報や参照される

RT PlanのBeamを特定する情報を有

するため、画像自体の空間的位置を付帯情報としてもつ

–

EPID、DRR等の保存時に照射情報とのひもづけを支援

•

RT Planと連動する事によって意味を持つ

– 放射線治療部門で取得した

CR画像をRT ImageとしてTagを

書き換えて保存する運用は本来の意味とは異なる

じゃあ輪郭情報は？

•

Case 1 他の装置で作成した輪郭情報を利用したい

– 「

RT Structure Set」というオブジェクトでやり取りする

例） Velocityで作成した輪郭をMonacoへ送る 例） Eclipseで作成した輪郭情報をXioへ送る

•

Case 2 ROIの属性情報を残したい

– 「

RT Structure Set」で制定されている内容ならば可能

•

Case 3 ３DのROIを送ったら体積が違う

– 「

RT Structure Set」に書き込む、逆に読み込む際にそれぞ

れのシステムのお約束に従う事による違いは出る

DICOM RT Structure Set

•

Target、VOIなどの輪郭情報やPOIとしての座標情報

•

(0008,0016)SOP Class UIDは、1.2.840.10008.5.1.4.1.1.481.3

•

(0008,0060)Modalityの値はRTSTRUCT

•

DICOM CT Image IODを参照

•

(3006,0042)Contour Geometric Typeにて次のタイプが規定され

ています

– POINT ＝ 単一の点としての情報

– OPEN_PLANAR ＝ 同一平面上の閉じない曲線

– OPEN_NONPLANAR = 非同一平面上の閉じない曲線

– CLOSED_PLANAR ＝ 同一平面上の閉じた曲線

• （

3006,00A4)RT ROI Interpreted TypeにてROIのタイプを定義

– EXTERNAL ＝ 体輪郭

– PTV/CTV/GTV ＝ それぞれPTV/CTV/GTVを示す

– ORGAN ＝ 臓器、いわゆるVOI

DICOM RT Structure Set

• 想定されている利用目的

– 放射線治療領域を「医師」が客観的に理解可能な形式で指定する – RT Planにて照射野を決定するための情報を別途保存 – DVH評価を行う際に、RT DoseにDVHモジュールを組み込む場合の参照 元 – Target、VOIなどの輪郭情報やPOIとしての座標情報

• 対応した

CTスライス上に輪郭を構成するためのポイン

ト情報

– CTスライス上に乗っていないと、別のシステムにて表示・利用が出来な い場合や、ずれたり値が異なる場合がある

•

Volumeに対しては実装次第

– あくまでも

2Dの輪郭の元になる輪郭点の情報の集合体

⇒ 直線補間、曲線補間、またポリゴン作成等など利用するシステムの実装により 面積、体積の表示が異なりうる

線量分布情報はどうなるの？

•

Case 1 線量計算が終わって表示されている線量分布を

他の装置で使いたい

– 「

RT Dose」というオブジェクトでやり取りする

•

Case 2 RT Viewerで見たい

– 「

RT Dose」及び関連する情報をやりとりする事で利用可能

– 線量分布そのものの利用（線量合算など）と、線量評価目的

（ビームのウェイトを変えたいなど）とで都合がいい保存方法が

異なる

•

Case 3 DVHはいっしょに送れるの？

– 「

RT Dose」に組み込まれる情報として規定はされているが、送

り方と受け取って解釈する方法によって変わる事がある

DICOM RT Dose

• TPS等によって計算された線量情報

• (0008,0016)SOP Class UIDは、1.2.840.10008.5.1.4.1.1.481.2

• (0008,0060)Modalityの値はRTDOSE

• DICOM RT Plan、RT Structure Setを参照

• (3004,000A)Dose Summation Typeでは以下のタイプが定義されています

– PLAN = RT Planによる計算線量（Planとしての合算） – FRACTION = RT Planの1フラクション分としての計算線量

– BEAM = RT Planに含まれるビームの門ごとの計算線量

– BRACHY = RT Planにて一つ以上のBrachy Application Setupによる 計算線量

– CONTROL_POINT = ビームにおける一つ以上のコントロールポイントに対する計 算線量

• RT DVH Moduleを含む場合、参照するROIやDVH Type

DICOM RT Dose

• 通常は

RT Planしか参照する情報は無い

– どの画像上に乗るのかが間接的にしかわからない

•

RT DVH Moduleを含む場合、参照するROIに関連するRT

Structure SetのSOP Instance UIDが記述

– この場合でも直接参照する画像の情報はない

•

Dose Summation TypeがPlan DoseやBrachy Doseでは通常の

持ち方をするが、

Beam Doseなどの場合にはマルチフレーム

の構造となる

– ファイルは一つだけれど、複数の情報を持っている

– つまり１シートのみのExcelと複数シートのExcelとどちらも１ファイルみた

RT Objectの関連

• RT DoseはRT Structure SetとRT Planを参照 • RT PlanはRT Structure Setを参照

• RT Structure SetはCT等のImageを参照 • RT ImageはRT Planを参照 • データの作成順や流れ順は下記の→の逆になります RT Dose RT Plan RT Image RT Structure Set CT Image 参照Object

放射線治療の種類ごとの情報

外部照射 粒子線治療 HDR RALS _Seed治療 Image CT MR/PET RT Image他 CT MR/PET RT Image他 2D：RT Image/CR 3D: CT/US US/CT/MR 輪郭情報 _{RT SS RT SS RT SS RT SS}

治療計画情報 _{RT Plan（Beam） RT ION Beam PLAN RT Plan(Brachy) RT Plan(Brachy)}

線量情報 _{RT Dose} (Bram/Fraction/Pla n/Control point) RT Dose (Bram/Fraction/Pla n/Control point) RT Dose(Brachy) RT Dose(Brachy) 照射記録 RT Beam Treatment

CT/MR

放射線治療関連機器連携

• CT/MR/PET … などの画像モダリティ

• CT Sim/Image Fusion System/TPS等の計画系システム • TU（LINAC/Afterloader/Ion Therapy)などの治療装置 TPS R&V LINAC CT / MR Object RT Plan CT Sim CT Object RT Structure Set RT Plan RT Plan Treatment Record RT Structure RT Plan RT Dose RT Image Archive

IOD：情報オブジェクト定義

• IOD：Information Object Definition （情報オブジェクト定義）

– 取り扱っている情報がどういったものなのかについて定義するもの （例：_{CT画像、輪郭情報など）}

– 詳細についてはPS 3.3にて記述

• 各IODはIODモジュールの複合にて構成

– Patient Module、RT Dose Moduleなど

– ほぼ全てのオブジェクトにおいて、どの患者に属する情報なのかが必要な ので_{Patient Moduleは組み込まれる} • 情報オブジェクトに組み込むModuleは、必須のものとオプションのもの、 あるModuleがある場合には必須などの規定 • 各オブジェクトは、独立しているものと、参照しているオブジェクトを特定 しているものがある – 独立例：CT、MRなどの画像モダリティ

– 参照例：RT Structure SetはCT画像を参照、RT PlanはRT Structureを参照な ど

• 個々の情報にはTag(gggg,eeee), Attribute Name(属性名）、Type（必須 かどうか）があり、それぞれの書式や値の制限がある

• Tagは（グループ、エレメント）で示され、16進数（４ケタ、４ケタ）であらわ される

Data Set

•

Data SetはData Elementの複合体（PS3.5より）

•

Data Elementは以下で構成

– Tag 属性（gggg,eeee） – （VR） 値の表記 – Value Length 値の長さ – Value 値 Data Set Data Element Tag Value

Length Value Field optional field - dependent on negotiated Transfer Syntax

VR

Data Elem.Data Elem. Data Elem. Data Elem. order of transmission

Tagの並び

• Tag（gggg、eeee）が昇順にてオブジェクト生成

– 各IODがどのような情報が記載されているかについては、それぞれのIOD及び

Conformance Statementにて記載されているが、オブジェクト生成の際にそれらのTagが 昇順にてデータ化されて保存される

⇒ Dump情報を読み解く際に、PS 3.3記載事項やConformance Statementの該当の箇所を 探して参照する • 既定されているTag グループは偶数 – 基本的には偶数のグループ、エレメントにて既定されている – Privateエレメントについては奇数が用いられている – PrivateエレメントはConformance Statementにて記載 ⇒ _{A社のシステムのあるTagとB社のシステムのあるTagが同じTagを別の目的で使っている} 可能性はありうるので運用や利用時には注意が必要

IODのつくり

• IODは複数のModuleの組み合わせで構成 • IODによって必須、オプション、排他などがある • Moduleは複数のData Setで構成

IE Module Reference Usage

Patient Patient C.7.1.1 M Clinical Trial Subject C.7.1.3 U Study General Study C.7.2.1 M Patient Study C.7.2.2 U Clinical Trial Study C.7.2.3 U Series RT Series C.8.8.1 M Clinical Trial Series C.7.3.2 U Equipment General Equipment C.7.5.1 M Structure Set Structure Set C.8.8.5 M ROI Contour C.8.8.6 M RT ROI Observations C.8.8.8 M Approval C.8.8.16 U SOP Common C.12.1 M

Attribute Name Tag Type Attribute Description

Structure Set Label (3006,0002) 1 User-defined label for Structure Set. Structure Set Name (3006,0004) 3 User-defined name for Structure Set. Structure Set Description (3006,0006) 3 User-defined description for Structure Set. Instance Number (0020,0013) 3 A number that identifies this object

instance.

Structure Set Date (3006,0008) 2 Date at which Structure Set was last modified.

例）RT Structure Set IOD

シーケンス

• 情報の入れ子構造 – １つ以上の同等の情報の組み合わせの記載が必要な場合に、シーケンスとして情報が 記載される – 例） ビームが１門のRT Planであればその門の情報が、複数門の場合には１門目の情 報に続いて２門目以降の情報が同じフォーマットで繰り返される。そのため１門であって もシーケンス構造で記録され、門数１として記録される – RT Structure Setにおいて、輪郭はこのシーケンスにて、ROI１、ROI２と次々に情報が記録 される

DICOM オブジェクトの基本的な概念構造

• Patient ：対象となる患者 • Study ：Patientにひもづき一つ以上 – 診断では「検査」と訳されるが、一連の情報をまとめる単位 • Series ：Studyにひもづき一つ以上 – 日本語でも「シリーズ」。Study下のオブジェクトをまとめる単位 • Object ：個々の情報の実体

DICOM RT Objectの概要

• DICOM PS 3.3のAにてそれぞれのオブジェクトの概要が、 C.8.8にて各IODの詳細が記述されている

活用事例

• 基本的には、その装置固有のデータ形式で

の利用の方が、行った全てのデータが保存さ

れ、動作も速い

• システム更新や多施設間連携の時には標準

化されていた方が手間がほとんどない

• 独自仕様は便利だが汎用性に乏しい

• 標準化が済んでいる部分だけの利用でも有

益

DICOM RTに対応すればOK？

• 注意が必要なのは、

DICOM RTは総称なので、具体的に明示しな

いと誤解を生じる余地が多い

• 各システムは適合宣言書で適合性を一方的に宣言している

– 必ずしも接続性を保証しない

•

DICOM的に違反でなくても運用上困る事がある

– 患者名、患者IDはDICOMではNULLでも違反ではない

– Targetを書いていなくてもRT Structure Setは成立

• ある程度の独自拡張がゆるされている

– 規格化が済んでいない独自のデータ保存が可能

• 関連する

DICOM情報の対応も必要

– Registration関連情報やスケジュール管理など

•

DICOM以外でも情報連携では規格がある

– HL7（電文）のやり取り

本日の話題

• 放射線治療部門を取り巻く現状

•

DICOMとDICOM RT

• 事例紹介からそれぞれの情報について

• 不具合事例

• 現時点で検討されている規格拡張

不具合事例

• Case 1：治療計画は出来ているのにR&Vが受け取らない – 装置名称の情報が計画装置とR&Vとが一致していない （RT Planの中のMachine Nameが一致しているかどうか） • Case 2：計画装置Aと計画装置Bとで同じ輪郭の表示や値が異なる – ２D情報のスタックとしてRT Structure Setは保存されているので、それ をどう表示や表現をするかはそれぞれのシステムに依存 • Case 3：計画装置Cから計画装置Dへ輪郭を送ったら表示がずれる – 古いDICOM（ピクセルの左上が座標）と今のDICOM（ピクセルの中心 が座標）のそれぞれ異なる基準で作られたプログラム間のやり取りの 際に発生。画像に対して左上、右下方向に半ピクセル分ずれる

不具合事例２

• Case 4：一方では普通に表示出来ている内容がもう一方で表示されな かったりおかしな表示をする – システム固有の機能を使った情報は、もう一方は理解が出来ない • Case 5：輪郭情報が送れる時と送れない時がある – 大量のROI数、細かすぎる輪郭形状などでデータサイズの制限を超 えた場合にDICOMヘッダー情報が割愛されて読めなくなる場合があ る • Case 6：DICOM違反をしていないデータを送っても受け取ってもらえない – 一方ではオプションだったり概念が無い情報が、もう一方では必須の 場合に起こりえる

不具合事例３

• Case 7：計画装置で表示されている線量分布が、受け取り側で一切表示 されない。通信でRT Doseは送っていてエラーは無い – ３D計算をしていない場合、計画装置上では線量分布が表示されていても、 線量についてのバイナリデータ（ピクセルデータ）が無いRT Doseが作られて やり取りした場合に起こりうる – 一方では合算線量、もう一方は門ごとの線量の取扱いをする場合 – RT Doseは絶対線量で送られているが、受け取り側が相対線量表示の何％ が何Gyに相当するかの割り当てをしていない場合 – 受け取り・表示側のシステムで、線量を非表示設定にしていた • Case 8：DVHが正しく表示されない – 送り手側はそのシステムのアルゴリズムでカーブを表示しているが、送り出 す際にビンデータで送っていたり、その細かさが違う場合に起こりえる • Case 9：色がおかしい – カラー表示の情報を送っていなかったり、HWやOS固有の情報を利用してい る場合に起こりえる

DICOMとIHE

•

DICOMは情報の入れ物とやり取りを規格として

規定するが、運用についてはスコープ外

– 放射線治療に関しては、

WG7（Radiotherapy）が検討

• 業務のワークフローで

DICOMやHL7といった規格

をどう使うかのガイドラインを制定して接続実証

試験を行うのが

IHE

– 放射線治療は、

IHE-RO（Radiation Oncology）が検討

•

IHE-ROがワークフローを検討する際に標準化が

済んでいない新しい装置や技術について、

DICOM WG7に対して規格の拡張を要請

–

SupplementやCPとして提案

IHE-ROの既定・検討中のプロファイル

BRTO MMRO ARTI・ TPPC IPDW DPDW QAPV DCOM

Basic Radiatino Therapy Object Multi Modality Registration for RT

Suppl. Advanced RT Object Interoperation Treatment Planning Plan Contents

Dose Composing Profile

Integrated Positioning and Delivery Profile Discrete Positioning and Delivery Profile Quality Assurance with Plan Veto

IHE-RO統合プロファイル

• BRTO（シンプルな3D外部照射治療計画）

– 旧名称 NTPL-S（Normal Treatment Planning - Simple）

– 3D外部照射治療計画を、輪郭作成、照射野作成、線量計算、線量分布表示のパート に分割して制定

– マルチベンダー環境化、かつ中央DICOM Archiveを用いての環境でのプロファイル

• MMR-RO（Multimodality Registration）

– 放射線治療計画のマルチモダリティ環境への適合

• ARTI(Advanced RT Object Interoperability) – TPPC(Treatment Planning - Plan Content)

• DCOM(Dose Composing) – 線量合算

• DPDW(Discrete Positioning and Delivery) • IPDW(Integrated Positioning and Delivery)

– 患者のセットアップと照射

• QAPV(Quality Assurance with Plan Veto ) – Planの差し戻しを視野に入れた、照射前のPlan検証 • ・・・

スムーズな運用のために

•

IHE-ROはConnectathon（コネクタソン）と呼ばれる接続性の実証試

験を行っているので、その結果は一つの目安として使える

– 例 Pinnacleで作った輪郭を元にして、Eclipseでビームをセットアップ

して、Oncentraで線量計算して、Focalで分布を表示する

• 事前に接続する両者の

DICOM Conformance Statementから予想さ

れる問題点を挙げ、確認をしたり運用での対応を検討する

• 個別にインターフェースを作成しても、バージョンアップや多施設

連携の際に障害となりうる

• 仕様書等で、「

DICOM RTに対応する事」などは範囲が広すぎて問

題のタネとなってしまうので、より具体的に要望事項をまとめる

– 例 ×「導入するシステムはDICOM RTに対応する事」 ○「導入するシステムは、○○のシステムにおいて作成した 輪郭情報をDICOMを用いてやり取り出来る事」 ○「IHE-ROのBRTOプロファイルのContourerの機能を有する事」

本日の話題

• 放射線治療部門を取り巻く現状

•

DICOMとDICOM RT

• 事例紹介からそれぞれの情報について

• 不具合事例

• 現時点で検討されている規格拡張

放射線治療情報の現状と今後

• 画像診断において複数の画像を同時に利用する事が、

Image

Fusion・Image Registrationとして普及した事から、放射線治療にお

いても、検査時期の異なる

CT画像の同時利用や、CT、MR、PETなど

の異なる画像を用いて治療（計画）が普及

•

IMRT、VMATなどの腫瘍に限定的に照射出来るシステムが普及し、

照射前や照射時の位置照合のための画像の利用が増加

•

Image Guided Radiotherapy（IGRT：画像誘導放射線治療）に対応し

た治療システムが普及してきたため、放射線治療で用いられる画

像が増加

• 治療装置、治療用

X線シミュレータ共に、CBCT（Cone Beam CT）を作

成する事が出来るようになり、

KV-CBCTのみならずMV-CBCTも作成

する事が出来るシステムの増加

• さらなる機器連携のための規格そのものの拡張が検討

近年の

RT関連のDICOM拡張

•

Supplement 73 ＆ １１２

– Spatial Registration（Supp. ７３） • リジッドレジストレイション – Deformable Registration（Supp. 112） • 変形を伴うレジストレイション

•

Supplement 96 & 74

– Unified Worklist and Procedure Step(Supp.96)

• 汎用実施予約を進捗管理

– Utilization of Worklist in Radiotherapy Treatment Delivery（Supp. 74)

• 患者の位置照合と照射の実施 （→ IGRT関連）

•

Supplement 147（関連）

– Second Generation Radiotherapy

Image Registration/Image Fusion

• Image Registration

– あるDataset（Image Set、Frame Of Reference)と、これとは異なる Datasetとが空間的にどのような位置関係になるかを合わせる行 為 – CT-CT、CT-MR、CT-MR-PETなど – (0008,0060)Modalityの値はREG • Image Fusion – Image Registrationを行った複数のDatasetをOverlayなどで表示す る方法 • 2D-2Dの例も準拠 – 例：DRR-EPID、XP-LG/EPID、DRR-LG

• DICOM規格、PS3.17 Explanatory Information ANNEX O

Registration

• IHE-RO Technical Framework Vol.1

– MMRO、MMRO II、MMRO III

DICOM Registration関連

• 二つの画像モダリティによる関連付けに関する情報

• (0008,0016)SOP Class UIDは、1.2.840.10008.5.1.4.1.1.66.1

– Deformable Spatial Registrationの場合はSOP Class UIDの末尾が１→３

• (0008,0060)Modalityの値はREG

• 利用するDICOM Image Seriesを参照

• 二つのイメージセットを平行移動と回転のみで関連付けるもの（いわゆる

Rigid Registration）がSpatial Registration、任意のPixel/Voxelの変形を伴って

関連付けるもの（いわゆるDeformable Registration）をDeformable Spatial

Registrationとされている

• Registrationの種類により、組み込まれるModuleが異なる

– Spatial Registration Module：Rigid Registrationの場合 – Def. Spatial Reg. Module：Deform. Registrationの場合

放射線治療における

Registration

•

Rigid、Deformableのいずれにしても計算には多かれ少なか

れ時間を要する

•

Registrationエンジン／アルゴリズムを実装しているシステム

のみで、いわゆる

Fusionを取り扱うシステムは診断系で市場

に製品として出ている

• 画像のみでは治療では不十分（輪郭：

RT Structureや線量：

RT Doseまでの活用が求められる

– Registration画像をベースとしてContouringを行う事だけでも意義はあ る

–

Deformableの場合にはResamplingによる再利用

•

REGの活用

– 結果のみを呼び出して利用する事で時間短縮と再現性

ワークフロー管理

•

MWM（モダリティワークリスト）とMPPS（モダリティ進捗

状況管理）は画像モダリティを想定

•

MWMとMPPSを包括して、UWPS（汎用ワークリストと

進捗管理）の枠組みが規定されている

– むりくり

MWMでやろうとするのでは無く、MWMからUWPS

への移行や対応を検討

• 放射線治療の実施について、

Supplement 74にてワー

クフロー管理の枠組みが提供されている

• 包括的な治療情報の管理の前段階として準備されて

いる

–

RISとR&Vの連携、スケジュール管理システム主導の治療

関連行為の実施

新しい装置や技術への対応

• 既存の

RTオブジェクトでは取り扱えない装置

が市場にて利用されてきている

• 既存の枠組みでは取扱いが困難な技術が放

射線治療現場で取り扱われている

• 包括的な院内情報と部門情報の連携が進ん

できている

Second Generation Radiotherapy

•

Supplement 147

• 従来の

DICOM RTの拡張

– 従来のRTオブジェクトの定義では記述できない、新たな治療技術/治 療装置に対応するために大幅に改定 – 包括的な放射線治療関連情報の管理 – ワークフロー管理 – 既存のテクニック・実装との互換性 – 既存のRTオブジェクトから新たなRTオブジェクトへの上位互換性 – 互換性のため既存のRTオブジェクトへのCPが多数出てきている

•

DICOMホームページにて特設ページあり

– http://dicom.nema.org/Dicom/News/april2014/DicomWG6_april2014 .html

Second Generation Radiotherapy

• 従来のRT Object関連を1G RT、新たなものを2G RTとも呼ばれている

• 当初、Supplement 147で拡張が始まったが、Supplementとしては大きくな

りすぎてしまったため、以下の６つに分割し制定中

– Sup 147 2nd Gen RT Prescription and Segment Annotation – Sup 175 2nd Gen RT C-Arm Radiations

– Sup 176 2nd Gen RT New RT Radiations – Sup 177 2nd Gen RT Dose Objects

– Sup 178 2nd Gen RT RT Course

– Sup 179 2nd Gen RT RT Explanatory (Part 17)

（全体像を把握するためには、Sup 147と179から入り、178へと移りその他の各 論に入ると理解しやすい）

２

GRTのポイント

•

RT Course

– 治療全体を包括管理

•

RT Physician Intent

– 治療目的を明示

•

RT Segmentation

–

3DでのROI情報の取扱い

•

RT Radiation Set

–

RT Planの後継

•

RT Patient Setup

–

Patient Positioning/Verificationについて

Second Generation RT

IODs Modules RT Cours e RT Phys Intent RT Rad Set RT Seg Props Tomo Rad C-Arm Ph Rad C-Arm El Rad Multi-Fixed Rad Rob Rad Multi-Axial Rad Tomo Rec C-Arm Ph Rec Multi Fixed Rec Rob Rec Multi Axial Rec RT Dose Img RT Dose Hist RT Dose Samp RT Pat Setup RT Rad Set Deliv Patient M M M M M M M M M M M M M M M M M M M M Clinical Trial Subject U U U U U U U U U U U U U U U U U U U U General Study M M M M M M M M M M M M M M M M M M M M Patient Study U U U U U U U U U U U U U U U U U U U U

Clinical Trial Study U U U U U U U U U U U U U U U U U U U U

General Series M M M M M M M M M M M M M M M M M M M M RT Course M RT Prescription Reference C RT Treatment Phase C IODs Modules RT Dose RT Struc Set RT Plan RT Beam Rec RT Brachy Rec RT Sum RT Ion Plan RT Ion Beams Treat Rec RT Beams Delivery Inst Patient M M M M M M M M M Clinical Trial Subject U U U U U U U U U General Study M M M M M M M M M Patient Study U U U U U U U U U Clinical Trial Study U U U U U U U U U General Series M RT Dose _M

DICOM PS3.3 A.1.4 Table A.1.3（DICOM 2015c）

参考情報

•

DICOM Standard Committee

http://medical.nema.org/

•

JIRA（日本画像医療システム工業会）

http://www.jira-net.or.jp/index.htm

– DICOMの世界

最後に

• より高精度な治療へ

– 技術の進歩と学術的な発展から、より高精度な治療が可

能となってきている

– システムのブラックボックス化が進む

– 「道具」を適正に効果的に利用する必要が高まる

•

IT技術の利用

–

TPSの中にしか無い情報から、汎用情報へ

– 独立検証、二次利用のためには、これらの情報を把握し

て適正に利用

• 知らなくても治療行為は行えるが、知っていると出来

る事が広がり、理解していると利用範囲が広がる