第31回 ＩＨＥ勉強会（初級編）in東京

DICOM超入門- DICOMは放射線画像だけじゃない 日本画像医療システム工業会(JIRA) DICOM委員会
鈴木 真人

日本ＩＨＥ協会 普及推進委員会

1

IHE Workshop in Tokyo
Oct. 8, 2011

はじめに…
この資料は 医用画像を扱う実務に携われている方々に対して 業界デファクトスタンダードであるDICOM規格と 日常業務の定形化を進める IHEのプロファイル との関連を分かりやすく説明するものです。
IHE プロファイル・DICOM規格 ともに一部分だけのご紹介となります。全容は各自 ご確認願います。
ご紹介する規格やガイドラインは日々更新されています。実務の設計に際してはそれぞれのH.P.から最新版をダウンロードしてお使い下さい。
2

IHE Workshop in Tokyo
Oct. 8, 2011

日常業務の定形化
１） 日常業務の定形化
２） IHEの SWF
３） DICOM規格の読み方
４） Q&A

3

IHE Workshop in Tokyo
Oct. 8, 2011

日常業務の定形化

１『 いろんな種類の医用画像がDICOMで統一的に扱えます 』
大体 正しいです。 なぜなら DICOMが①モダリティ別に ヘッダ情報をタグと呼ばれる単位に分解して 必須・オプションを 定義した。（画像情報の共通理解）②モダリティに関わらず 通信の手順を定義した。
（画像の共有）4

IHE Workshop in Tokyo
Oct. 8, 2011

日常業務の定形化

２でも ここで 基本的な疑問が・・・
実際の現場では（１） 画像だけ統一しても さほど 楽にならない（２） 相手に届くだけでは 不十分。
目的は 届けることではない。
5

IHE Workshop in Tokyo
Oct. 8, 2011

日常業務の定形化

３（1) 改めて 皆さんの仕事を客観的に見ると超音波室やCT室 で （中途半端なオンライン環境を仮定）①受付から検査依頼用紙が回ってきて②情報を手入力して 患者さんを受け入れて③撮影して 確認して④画像を見たい人に送って⑤消耗品や撮影枚数をノートに記帳して⑥データの整理（消去など）をして次の患者さんを待つ
6

IHE Workshop in Tokyo
Oct. 8, 2011

日常業務の定形化

４

でも 現実は①受付から検査依頼用紙が回ってきて詳細情報も知りたい たとえば今日 造影が何件あるのか②患者情報を入力して 患者さんを受け入れて紙でもらうのは 面倒 だし キーボード入力で間違える時も ・・・③撮影して 確認して前回と同じポジションと言われても・・・④画像を見たい人に送ってフィルム焼いて届けるよりは オンラインで楽になりました⑤消耗品や撮影枚数をノートに記帳して造影剤や画像枚数は自動で集計して欲しい⑥データの整理（消去など）をして 次の検査に備える

本当に届いたか心配だから 画像がなかなか消せない
7

IHE Workshop in Tokyo
Oct. 8, 2011

日常業務の定形化

５できることなら①次の患者さんの情報がコンソールに簡単に入ってくれて②なんなら 一日分の検査内容もリストで確認できて③前回の画像を見ながら 位置合わせができて④動画もThin Sliceも自動で それぞれのサーバに配送されて⑤消耗品や所要時間、検査キャンセルも自動で報告されて⑥装置内の画像を消してよいか 確実にわかる
8と さらに便利ですね・・・・
IHE Workshop in Tokyo
Oct. 8, 2011

日常業務の定形化

６①次の患者さんの情報がコンソールに簡単に入ってくれてDICOMのMWMを使うと かなり便利になります②なんなら 一日分の検査内容もリストで確認できてこれも MWMの機能で実現できます③前回の画像を見ながら 位置合わせができてDICOM Q/Rで過去画像を引っ張ってくれば可能です④動画もThin Sliceも自動で それぞれのサーバに配送されてDICOM Storage を使って 装置が工夫すれば可能⑤消耗品や所要時間、検査キャンセルも自動で報告されてDICOMのMPPSという情報交換手段があります⑥装置内の画像を消してよいか 確実にわかる

DICOM Commitment機能を使えば 自動化も可能です
9

IHE Workshop in TokyoOct. 8, 2011

日常業務の定形化

７

ここまでのご説明のまとめ
１） 日常業務をステップに分解して 機能を単純に分けると標準的な機能で置き換えられる部分が見えてきます。
２） DICOMは 業務の一部分を自動化・省力化するための手段として 有効に働きます。

10

IHE Workshop in Tokyo
Oct. 8, 2011

IHEのSWF
１） 日常業務の定形化

２） IHEの SWF
３） DICOM規格の読み方
４） Q&A

11

IHE Workshop in Tokyo
Oct. 8, 2011

IHEのSWF

１

実は 先ほど例として示した ① から ⑥ までのステップを一連の作業として
１）登場人物を決め （ 予約する人、検査する人、患者本人、）

２） 作業内容を決め （予約する、検査する、検査を受ける、）
３） 名前をつけて （例えば“予約を前提とした一般検査”）定義したものがあります。
このようなものを IHEの統合プロファイル と呼びます。
12

IHE Workshop in Tokyo
Oct. 8, 2011

IHEのSWF

２

IHE の SWF (Scheduled Work Flow ) では
① 受付が患者さんを新患で登録して②予約を取る人が 予約を入れて③予約を実施する人が 検査装置に情報を渡して④検査する人が 検査して 画像を送って⑤読影する人が 読影結果を報告して⑥検査結果を知りたい人が 検査の終了を確認して⑦患者さんが 会計して 終わりの 一連の流れ（の中心部分）を定義しています。
13

IHE Workshop in Tokyo
Oct. 8, 2011

IHEのSWF

３

IHE-J H.P より転載

14

IHE Workshop in Tokyo
Oct. 8, 2011

IHEのSWF

４①受付が患者さんを新患で登録して（初診受付で患者さんの情報を入力してアクセス可能にする）

１） IHEが決めたデータ種別を
２）IHEが決めた形式で 患者データベースに登録する
１） ： HL7が定めている患者情報の項目に対応

２）： HL7 が定めているフォーマットでサーバと通信
15

IHE Workshop in Tokyo
Oct. 8, 2011

IHEのSWF

５② 予約を入れる人が 予約を入れて（外来の医師が HIS端末でCT検査を予約する）
１） IHEが決めたデータ種別を
２）IHEが決めた形式で 予約データベースに入れる
１） ： HL7が定めている検査予約に必要な項目
２）： HL7 が定めているフォーマットでサーバと通信
16

IHE Workshop in Tokyo
Oct. 8, 2011

IHEのSWF

６④ 検査する人が 検査を完了して 画像を送って（CTの検査を行い 画像をPACSに送信する）
１）IHEが決めた付帯情報をつけた画像を
２）IHEが決めた方法でPACSに送る
１）： DICOM のCT必須タグ＋IHEが決めた追加タグ２）： DICOM の Storage コマンドで画像をPACSに送る
17

IHE Workshop in Tokyo
Oct. 8, 2011

IHEのSWF

７⑤ 読影する人は 読影結果を報告して
１） 読影する画像を選択して
２） 読影レポートを書いて 検査依頼元に送る（見えるようにする）

１）： DICOMのQ/Rで読影画像を検索する
２）： レポートはDICOM SRのフォーマットでレポートサーバに Storage され、依頼科からアクセス可能になる
18

IHE Workshop in Tokyo
Oct. 8, 2011

IHEのSWF

８⑥ 結果を知りたい人が 検査の終了を確認して⑦ 患者さんが 会計して 終わり（ ⑥ と ⑦ は SWFに含まれませんが、実務では必要なステップになります）

１） 依頼医師はレポートと画像を見て 目的を達成する
２） 放射線科（病院）は検査終了を確認し費用を請求する
１）： DICOM Q/Rで見たい画像とレポートを呼出し表示する
２）： DICOM MPPSの情報が消耗品の請求に利用される
19

IHE Workshop in Tokyo
Oct. 8, 2011

IHEのSWF

９

IHE-J H.P より転載

20

IHE Workshop in Tokyo
Oct. 8, 2011

IHEのSWF

１０

ここまでのご説明のまとめ（１） 日常の業務の流れをステップに分解し 定形化したものを IHEの統合プロファイルと呼び、 代表的なものにSWF（Scheduled Work Flow)があります。

（２） 定形化された日常業務は DICOMを含む いくつかの規格を組み合わせて実現することが可能です。

21

IHE Workshop in Tokyo
Oct. 8, 2011

DICOM規格の読み方
１） 日常業務の定形化
２） IHEの SWF

３） DICOM規格の読み方
４） Q&A

22

IHE Workshop in Tokyo
Oct. 8, 2011

DICOM規格の読み方

１

超簡単に言うと DICOMは 医用画像・情報についてオブジェクト

 どの画像・情報をCT画像
検査情報

マンモ画像 患者情報
被ばく情報 レポート

 どうしたいか保存して探して印刷して送っての組み合わせを定義して装置ごとに実装・宣言するサービス

SOP （サービスオブジェクトペア）
コンフォーマンス ステートメント （Ｃ／Ｓ）

23

IHE Workshop in Tokyo
Oct. 8, 2011

DICOM規格の読み方

２

DICOMでは ヘッダ情報はタグの集まりとして扱われます
一つのDICOM Object（一枚の画像 ・ 一人の患者情報）

データ
要素

データ
要素

データ
要素

データ
要素

患者氏名
Tag（0010,0010)

VR

PN

データ
要素

生年月日
Value
Length56

画像も一つのデータ要素

データ
要素

データ
要素

性別

画像ピクセル

Value Field

Yamada^Tarou=山田^太郎＝やまだ^たろう

24

IHE Workshop in Tokyo
Oct. 8, 2011

DICOM規格の読み方

３

規格書 PS3.4ではサービスを定義しています。
 オブジェクト とサービスの組み合わせがDICOMの機能になる。

（SOP： Service Object Pair： サービスオブジェクトペア)
 サービスのリストは PS3.4の目次を見れば載っている
Storage・Print・MWM・MPPS その他
 サービスには利用者 と 提供者 がいる。
利用者 ：Ｓｅｒｖｉｃｅ Ｃｌａｓｓ Ｕｓｅｒ ： ＳＣＵ
提供者 ： Ｓｅｒｖｉｃｅ Ｃｌａｓｓ Ｐｒｏｖｉｄｅｒ ： ＳＣＰ
 SOPに番号（UID：Unique IDentifier ）を振って簡単に認識できるようにしてある。（SOP Class UID）
CT Image の Storage ：1.2.840.10008.5.1.4.1.1.2
25

IHE Workshop in Tokyo
Oct. 8, 2011

DICOM規格の読み方

４

規格書 ＰＳ３．５では PS3.3オブジェクトのデータ構造と表現方式を詳細定義しています。
Common Module
CT Image
ObjectSOP Instance UID(0008,0018)

必須

SOP Class UID(0008,0016)

必須

II：

SOP Common Module
Patient Module
Image Info. Module：Image Pixel Module

Patient Module
Patient Name

(0010,0010)

任意PN

Patient ID(0010,0020)

任意LO

Patient Birth date

(0010,0030)

任意DA

必須

OW：

Pixel Module
Pixel Data26

(7FE0,0010)

IHE Workshop in Tokyo
Oct. 8, 2011

DICOM規格の読み方

５

ここまでのご説明のまとめ（１） ＤＩＣＯＭ通信は オブジェクト（PS3.3) とサービス（PS3.4)の組み合わせで定義される。
（２）オブジェクトはモジュールから、モジュールはタグから構成される。（PS3.5)（３） モダリティ別に 必須となるタグが定義されている。
（PS3.5)（３）個々のオブジェクト（データ）には ユニークな番号が振られる。 （SOP Instance UID)
27

IHE Workshop in Tokyo
Oct. 8, 2011

Q& A
１） 日常業務の定形化
２） IHEの SWF
３） DICOM規格の読み方

４） Q&A28

IHE Workshop in Tokyo
Oct. 8, 2011

Q&A

１

Q１) DICOM と IHE で業務の効率が自動的にあがるの？？
A１) ミスを減らしたり、効率を上げる手段にはなり得ますが 最後は人間系のこまやかさが必要となります。 IHEのプロファイルに合わない 細かい違いは ローカルルールで回避する必要も。
例１）氏名やIDの手入力を間違えて検査した（二度と探し出せない、他人と間違えて読影）
これは MWMの採用でかなり減らせるでしょう
例２） 読影端末に Thin Slice ３０００枚のCT画像を送りつけた（ 指定しないと すべての画像を転送するようになっている）
読影者の手間を考えて 気をまわしてあげることが必要
29

IHE Workshop in Tokyo
Oct. 8, 2011

Q&A２

Q2) IHE を採用しておけば 面倒な法的問題はクリアされる ？？
A2) まず 医用情報保存の３原則 が守られていること
１） 真正性・データが改ざん・消去されていないこと
・作成と保存の責任が明確になっていること
２） 見読性・必要な時にすぐ提示できること
３）保存性・法令が決めた期間 情報を安全に保管すること
個人情報なので機密性も必要、 ほかにも順守事項あり。
これらを確保するのは システム運用 。 運用者が決めるものです。
IHEだから自動的に安全というわけではない。
30

IHE Workshop in Tokyo
Oct. 8, 2011

Q&A３

Q3) もっと 深く知りたいが 情報源などを紹介して欲しい

・オーダや検査結果・投薬に強みを持つ HL7 ： www.hl7.jp/
・ＤＩＣＯＭが外部参照しているデータの制定団体
・ ICD : International Statistical Classification of Diseases and Related
Health Problems http://www.mhlw.go.jp/toukei/sippei/index.html
・ SNOMED-CT：Systematized Nomenclature of Medicine-Clinical Terms
http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html

・ JJ1017：予約, 会計, 照射録 情報連携指針 V3.2
http://www.jira-net.or.jp/commission/system/fr_information_03-06.html
・HL7やDICOMを組み合わせて運用を考える IHE http://www.ihe-j.org

・DICOM規格書の原文と和訳 http://www.jira-net.or.jp/dicom/index.html
31

IHE Workshop in Tokyo
Oct. 8, 2011

Q&A４

Q4) DICOMを採用して 不便になることはない ？
A4) あまりないと思いますが、 機能がありすぎて良く言えば どこまで利用すべきか 判断に困る
悪く言えば 八方美人でとりとめがなくなる可能性
システム設計者の腕の見せ所 となります
・圧縮方法 採用しすぎ => 送信側 受信側 で一致しないと使えない・PDI のメディア種類ありすぎ => 結局 IHEではCD-Rだけを採用した
・必須タグ が 常識と違う =>患者氏名とIDが無くても DICOM的にはOK・プライベートタグが 逃げ道に =>画像より大きいプライベートタグも問題なし
・規格内容が毎年変わる => 対応年度が違うとつながらない可能性

その他 もろもろ
32

IHE Workshop in Tokyo
Oct. 8, 2011

Q&A

５

ほかに ご質問 ありますか ？

33

IHE Workshop in Tokyo
Oct. 8, 2011

Questions ?

WWW.IHE-J.ORG
IHE Workshop in Tokyo

34

Oct. 8, 2011