基礎からの DICOM PACS そして外部保存北海道情報大学医療情報学部上杉正人

(1)

第

2

会場

2

日目 共催：イーサイトヘルスケア株式会社

基礎からの

DICOM

，

PACS

そして外部保存

7月17日（日） 8: 20∼8: 50 座長：松尾義朋（イーサイトヘルスケア） 上杉正人（北海道情報大 医療情報学部） モーニングセミナー

2

(2)

基礎からの

DICOM

PACSそして外部保存

2016.7.17

北海道情報大学　医療情報学部

上杉　正人

(3)

DICOMの歴史と特徴

DICOMの基礎とPACS

(4)

DICOM規格の歴史

1970 1980 1990 2000

1993年　DICOM ver3.0

1983年　医療画像規格委員会結成（米国） 1985年　ACR-NEMA Ver1.0 1988年　ACR-NEMA Ver2.0 1976年　John Keys　SPECT開発 1972年　Hounsfield　CT開発 1978年　NMRによる初の人体画像撮影に成功 1983年　最初の臨床機であるFCR101が発売 PACSの普及 1989年　北海道大学病院　PACS稼働

(5)

DICOM規格の誕生の背景

• 1970年代のデジタル画像診断装置の普及

• 当時は診断装置ごとの接続方法が異なり、接続のための費用と時間が膨大であった。 • ユーザ、ベンダーともに負担であった。

• 装置間での共通利用のための標準規格が求められた

。

• 1993年 RSNA(北米放射線学会）で規格として承認される

• DICOMは毎年見直しされ

、

改善が行われている

。

(6)

DICOMの特徴

• _{ネットワーク}

環境に対応している

•  イーサネットなど

• _{オブジェクト指}

向に基づいて情報が定義されている

•  患者情報や検査情報がオブジェクトとして画像の先頭（ヘッダー）に記述されている

• _{コンフォーマンス・ステートメント}

（適合性宣言書）によりサポート

範囲を明確にしている

•  DICOM装置がどのような機能（サービスクラス）を実装しているか文書化されている。 •  機器を接続する前にサービスが利用できるか確認することができる

• _{追加・拡張}

が継続的に行われている

。

•  Part 1からPart20から構成されている。 •  これまで多くの補遺（Supplements）が提示され、追加・拡張が行われている。 5

(7)

DICOM規格はどこにあるの？

http://dicom.nema.org/

http://www.jira-net.or.jp/dicom/

dicom_data_02_01.html

(8)

DICOM規格の概要

The DICOM Standard 2015

DICOM Part 1: Introduction and Overview DICOM Part 2: Conformance

DICOM Part 3: Information Object Definitions DICOM Part 4: Service Class Specifications DICOM Part 5: Data Structures and Encoding DICOM Part 6: Data Dictionary

DICOM Part 7: Message Exchange

DICOM Part 8: Network Communication Support for Message Exchange DICOM Part 10: Media Storage and File Format for Media Interchange DICOM Part 11: Media Storage Application Profiles

DICOM Part 12: Media Formats and Physical Media for Media Interchange DICOM Part 14: Grayscale Standard Display Function

DICOM Part 15: Security and System Management Profiles DICOM Part 16: Content Mapping Resource

DICOM Part 17: Explanatory Information DICOM Part 18: Web Services

DICOM Part 19: Application Hosting

DICOM Part 20: Imaging Reports using HL7 Clinical Document Architecture

検査画像に関する情報オブジェクトが定義されている DICOMデータにどのように情報を格納するか定義されている DICOMタグ情報が定義されている

DICOM規格はPart 1からPart 20から構成されているが、ただしPart9（1対1通信）、 Part13（1対1のプリント通信）は廃止されている。

(9)

(10)

サービスクラスと情報オブジェクト

DICOMでは「何をするか」（サービス）と「対象となるデータ」（情報オブジェクト）の組み

合わせで機能が定義されている。

サービス名機能概要 Storage Service Class 装置間で画像転送し、保存するサービス Print Management Service Class 画像をプリントするサービス Modality Worklist Management Service Class 検査情報を管理するサービス Query/Retrieve Service Class 画像検索と転送をするサービス

○サービスクラス（何をするか）

・PS3.4で定義されている。

・サービスを提供する側：SCP（Service Class Provider）

・サービスを利用する側：SCU（Service Class User）

・サービスを提供する側と利用する側を明確に分けて定義している。

例）

(11)

サービスクラスと情報オブジェクト 

DICOM機器の接続

Storage Service Class SCU Storage Service Class SCP Query / Retrieve Service Class SCP Query / Retrieve Service Class SCU Print Service Class SCU Print Service Class SCP DICOM画像を保存管理する DICOM画像を検索表示 DICOM画像を印刷 l 「DICOM対応機器」同士であっても、サポート範囲が異なれば　　通信（データ交換）できない。 PACSサーバ画像参照端末レーザーイメージャー SCU : Service Class of User SCP : Service Class of Provider

(12)

サービスクラスと情報オブジェクト 

情報オブジェクト定義

○情報オブジェクト（対象データ）

・PS3.3（Information Object Deﬁnition, IOD）で定義されている

・画像検査などにかかわるすべのデータが対象である

。

・CT画像

、

CR画像

、

患者情報

、

検査情報

、

構造化レポート

、

etc

IE（Informa)on　En)ty)

情報実体 Module Reference Usage

PaEent 　PaEent C.7.1.1 必須

Study 　General Study _PaEent Study C.7.2.1 _C.7.2.2 _{オプション}必須

Series 　_{General Series} _C.7.3.1 必須 image 　_{General Image} _C.7.6.1 必須　Image Pixel C.7.6.3 必須　Contrast/Bolus C.7.6.4 条件により必須例）CT画像のIOD

AOribute Name Tag Type ---

Study Instance UID （0020,000D） 1 Study Date （0008,0020） 2 Study Time （0008,0030） 2 ・・・・・・・・・・（・・・・,・・・・）・

(13)

DICOM画像はData Elementから構成される

Data Elementは次の４つの情報を含んでいる

。

Tagはグループ番号（_{2バイト）とエレメント番号（2バイト）の16進数で構成される} 値に付けられたタグで、タグから値の意味を特定することができる VR（_{Value RepresentaEon）には2バイトの文字列が入る} 明示的に値の表現形を示す。数値、文字、日付など VL （Value Length）にはVFに入るデータの長さが16進数で保存される氏名やコメントなどの長さ（可変長）を表すことができる VF（ Value Field ）に必要な情報が保存されている実際に検査日や患者氏名などが入る VF　可変長値そのもの

Data Element Data Element Data Element Data Element Data Element Data Element

Tag

0010,0020 “LO”

VR

VL

10

Value Feild

0123456789

Data Element

の最後に画素データが含まれている

・・・・・最後のデータエレメントに画素データが格納される

(14)

互換性の保証 Data Element Type

○各Data Elementが必須かどうかを定義している

。

・CT画像であればCTのIODに必須のData Elementが含まれなければなら

ない。

・ベンダー間の相互接続性や画像表示の一貫性を担保することができる。

Type 説明例１必須項目、有効なデータを含めなくてはならない _{Study Instance UID} ２必須項目であるが、有効なデータがない場合は空のデータを含めること PaEent Name PaEent ID ３オプション。なくてもよい。また、からのデータを入れてもよい。 PaEent Comment １C 条件によってType１となる属性。 Pixel Spacing ２C 条件によって_{Type2となる属性} _Laterality

(15)

Data Elementの情報表現を明示的に示す

VR(Value Representation）

○VRはデータの取りうる値を2文字で表す

。

・PS3.5（Data Structures and Encoding）で定義されている

。

・VF（Value Field）に格納される情報を定義する

。

VR名 定義・使用可能な文字値の長さ_{/データ種} CS（Code String）大文字のアルファベット、“_{0”-“9”、スペース、”_”　（例）モダリ} ティ名_”MR” 最大_{16バイト/文字列} DA（Date） YYYYMMDDで表される日付文字列　（例）検査日“20160716” 8バイト固定/文字列 TM（Time) HHMMSS.FFFFFFで表す文字列　（例）検査時間“_{131526.000000”} 最大_{14バイト/文字列} PN（Person Name）人名　（例）_{Kobe^Taro=神戸^太郎=こうべ^たろう} 構成要素グループごとに最大_{64文字/文字列} DS(Decimal String）固定または浮動小数点を表す文字列（例）スライス厚“_12.399” 最大16バイト/文字列 UI（Unique IdenEﬁer）識別子（例）_{SOP instance UID} “1.2.392.200054.1.21000001.1.6.1” 最大_{64バイト/文字列} US（Unsigned short）符号なし16ビットの整数　（例）画像の縦横の画素数 2バイト固定/数値 OB（Other Byte String）バイト列　（例）画像データ別定義_{/バイト列}

(16)

DICOMオブジェクト

世界にひとつの検査

、

ひとつの画像

○検査や画像が重複しないようにUIDでDICOM画像は管理されている

・他院から持ち込まれた画像も自院の画像と重複することはない

。

DICOMの定義 説明患者（0010, 0020）　PaEent ID 施設内で一意に管理される検査（0020, 000D）　Study Instance UID 世界に一つしかない番号で検査を区別するシリーズ（_{0020, 000E）　Series Instance UID 世界に一つしかない番号でシリーズを区別する} 画像（_{0008, 0018）　SOP instance UID} 世界に一つしかない番号で画像を区別する

SOP instance UIDの例

1.3.12.2.1107.5.6.1.7520.30000015041304542343700000002 root 組織を表す常に同じ値 suffix 組織ごとにルールに則って発番する

(17)

DICOMのタグと値

検査基本情報と患者情報

Tag 項目値 0008, 0008 画像タイプ _{'ORIGINAL\PRIMARY\TOMO\EMISSION'} 0008, 0016 SOP Class UID '1.2.840.10008.5.1.4.1.1.20' 0008, 0018 SOP Instance UID '1.3.12.2.1107.5.6.1.7520.300000150413045 42343700000002' 0008,　0020 検査日 _'20150413' 0008, 0030 検査時間 '095142.265000' 0008, 0050 アクセッション番号 '5000002748447000' 0008, 0060 モダリティ _'NM' 0008, 0070 製造者 'SIEMENS NM' 0008, 1030 検査記述 'Brain Scan' 0008, 1090 製造モデル名 _'IP2' 0010, 0010 患者名 _KANJA^SHINEI 0010, 0020 患者ID 1234567890 0010, 0030 患者誕生日 19570412 0010, 0040 患者性別 _M

CT

画像に対してユニークな番号が付与されるオーダ番号が入り_HISと連携を撮ることができる

(18)

DICOMのタグと値

CT検査（収集）情報

それぞれの検査に特化した検査情報が格納されている

msec mA Head First-Supine mm

(19)

DICOMのタグと値

CT画像情報

1画素のサイズ（縦/横mm）画像の縦の画素数最後のデータエレメント。このタグの次に画像のデータエレメント。画素値が524Kバイト続く 1画素のビット数 16bit = 2バイト画像表示のための出ディフォルトの_WC=40と WW=88 画素の最低値を黒として解釈する

(20)

DICOM通信の３つのステップ

Step1：アソシエーション確立要求 Step2：画像転送要求 Step1：アソシエーション確立応答 Step2：画像送信　C-Store Step3：アソシエーション解放要求 Step3：アソシエーション解放ワークステーションからQ/Rして画像を受信するワークステーション Q/R SCU PACS Q/R SCP ①_PASC AE Etle に通信の確立要求　 ②許可している AEか？サポートしているサービスクラスか？ ③画像の転送要求と受信確認　 ④画像の送信 ⑥アソシエーションの解放して転送を終了する　 ⑤アソシエーションの解放を要求

(21)

DICOM通信

Transfer Syntax（転送構文）

VRの有無

、

圧縮の有無（圧縮手法）やバイト並びなどを転送構文で示す

。

VR データ形式 UID名 UID値

なし _{Raw（非圧縮） Implicit VR LiOle Endian}（DICOM default Transfer

Syntax） 1.2.840.10008.1.2 あり Raw（非圧縮） Explicit VR LiOle Endian 1.2.840.10008.1.2.1 JPEG JPEG Baseline（非可逆8ビット圧縮のdefault） 1.2.840.10008.1.2.50 JPEG Extended（非可逆12ビット圧縮のdefault） 1.2.840.10008.1.2.51 JPEG　Lossless Non-Hierarchical 1.2.840.10008.1.2.57 Non-Hierarchical、First-OderPredicEon 可逆_{JPEG圧縮のdefault} 1.2.840.10008.1.2.70 JPEG-LS JPEG-LS Lossless Image Compression 1.2.840.10008.1.2.80 JPEG-LS Lossy image Compression 1.2.840.10008.1.2.81 JPEG 2000 JPEG2000 Image Compression(Lossless) 1.2.840.10008.1.2.90 JPEG 2000 Image Compression 1.2.840.10008.1.2.91

(22)

適合宣言書（Conformance Statement）

○DICOM規格の何をサポートしてるか文書で表したもの

・サポートしているSOP Classとその役割（SCP, SCU）

・サポートしているSOP ClassとTransfer Syntaxの組み合わせ

・モダリティの場合

、

生成するデータエレメントのリストとその内容

・Q/RやMWMをサポートする装置の場合

、

検索条件や返却するデ

ータエレメントのリストとその内容

etc

○適合宣言書を見ることにより

、

DICOM機器のサポート範囲を把握す

ることができ

、

DICOM機器を接続する前に接続可否が理解できる

。

・接続時のコストや期間を短縮することが可能になった

。

(23)

オーダからDICOM画像が呼び出せる理由

○オーダ時に発行されるオーダ番号がDICOM MWMを介して

DICOM画像のTagのAccession Numberに格納される

。

オーダ発行 OrdNum:20160716123456 Study：Abd-CT PtID：9812345 PtNm：JCR＾TARO 画像生成 AccessionNum:20160716123456 クエリ OrdNum:20160716123456 ➡Accession Number RIS PACS HIS DICOM MWM DICOM Storage

(24)

DICOMは完璧か？

○SOP/Study Insrance UIDが変わることがある

。

・画像の検像時に画像の修正などを行うとUIDが変わる

・DICOMのタグを修正するとUIDが変わる

→紹介施設から持ち込まれた画像のPｔIDやモダリティ名を修正する

とUIDが変わる

。

→その患者が紹介施設に戻るとき

、

DICOM画像をCDに保存して持

たせる

。

→紹介施設側で別検査として同じ画像が保存される問題がある

○長い歴史の中でDICOM規格の解釈が変化してきた

・マンモグラフィのモダリティは過去にはCR、現在はMGが使われる

・撮影方向MLO/CCの情報が入るタグも異なる

→マンモビュワが判断しながら正しく表示する

。

(25)

(26)

PACSの普及と画像発生量の増加

大学病院では

、

20年間で10倍に画像発生量が増加している

。

画像発生量に占めるCTの割合が大きい

。

(27)

高性能CTの普及と画像発生量の増加

高性能のCTが普及している（図左）

。

1検査当りの画像枚数が7年間で約2倍に増加している（図右）

。

Medical ImageLab社よりデータを提供

読影医の負担が増加している

。

膨大の画像の管理の負担が増加している

。

出典　日本医用画像管理学会、Essential 医用画像情報管理（2015）

(28)

外部保存の背景

○医療情報を外部に保存するための整備などが進んでいる

・2010 外部保存の規制緩和

「診療録等の保存を行う場所について」に一部改訂（厚生労働省）

・2005∼ ガイドラインの整備

「医療情報システムの安全管理に関するガイドライン」他

・2011 東日本大震災

医療情報の毀損

BCPとして外部保存を検討する

(29)

外部保存サービス

東日本大震災（⇩）以降多くのシステムベンダーから提供さ

れている

(30)

３つの外部保存サービス

①バックアップ型

②ハイブリット型

③クラウド

_PACS型

オンプレス_{PACSにて通常運用する} バックアップとして外部に保存する災害時にバックアップから復旧するオンプレミス_{PACSの画像保存容量を最適化} する Long Eme archiveとして外部保存を利用する過去画像は外部保存から取得する画像の保存だけでなくサーバアプリケーション、画像ビューワも外部のサービスを利用する

外部保存サービスの利用の仕方により３つに分類することができる

。

(31)

外部保存とそれに連携するサービス

• 外部に画像を預けることで、地域画像連携や遠隔読影のサービスを受けるこ

とができる。

(32)

外部保存への不安？？？

• アンケート調査「放射線画像の保管管理における外部保存の利用状況の調査と問題点の検討」日本医用画像管理学会（2015） •  n=89の回答のうち外部保存を利用した12施設の回答外部保存利用前には「ネットワークのパフォーマンス」、「サポート体制」や「セキュリティ」などの不安があった。外部保存導入後は「安心感」、「画像管理からの解放」や「高速アクセス」が導入効果として挙げられている。

(33)

まとめ

• DICOMの歴史と特徴

• 画像診断装置デジタル化と装置間での画像の共通利用 • ネットワークの普及

• DICOMの基礎とPACS

• サービスクラスと情報オブジェクト • Data Element（Tag, VR, VL, VF） • 適合性宣言 • PACSとオーダ連携 • DICOMは完璧か

• 外部保存の基礎

• 画像の増加（読影の負担、画像管理の負担） • 外部保存サービスと利用施設のアンケート結果の紹介

基礎からの DICOM PACS そして外部保存 北海道情報大学医療情報学部上杉正人

2

2

基礎からの

DICOM

，

PACS

そして外部保存

2

基礎からの

DICOM

PACSそして外部保存

2016.7.17

北海道情報大学 医療情報学部

上杉 正人

目 次

DICOMの歴史と特徴

DICOMの基礎とPACS

DICOM規格の歴史

1993年 DICOM ver3.0

DICOM規格の誕生の背景

•

1970年代のデジタル画像診断装置の普及

•

装置間での共通利用のための標準規格が求められた

。

•

1993年 RSNA(北米放射線学会）で規格として承認される

•

DICOMは毎年見直しされ

、

改善が行われている

。

DICOMの特徴

•

ネットワーク

環境に対応している

•

オブジェクト指

向に基づいて情報が定義されている

•

コンフォーマンス・ステートメント

（適合性宣言書）によりサポート

範囲を明確にしている

•

追加・拡張

が継続的に行われている

。

DICOM規格はどこにあるの？

http://dicom.nema.org/

http://www.jira-net.or.jp/dicom/

dicom_data_02_01.html

DICOM規格の概要

The DICOM Standard 2015

サービスクラスと情報オブジェクト

DICOMでは「何をするか」（サービス）と「対象となるデータ」（情報オブジェクト）の組み

合わせで機能が定義されている。

○サービスクラス（何をするか）

・PS3.4で定義されている。

・サービスを提供する側：SCP（Service Class Provider）

・サービスを利用する側：SCU（Service Class User）

・サービスを提供する側と利用する側を明確に分けて定義している。

例）

サービスクラスと情報オブジェクト

DICOM機器の接続

サービスクラスと情報オブジェクト

情報オブジェクト定義

○情報オブジェクト（対象データ）

・PS3.3（Information Object Deﬁnition, IOD）で定義されている

・画像検査などにかかわるすべのデータが対象である

。

・CT画像

、

CR画像

、

患者情報

、

検査情報

、

構造化レポート

基礎からの DICOM PACS そして外部保存北海道情報大学医療情報学部上杉正人

北海道情報大学　医療情報学部

上杉　正人

目次

1993年　DICOM ver3.0

_{ネットワーク}

_{オブジェクト指}

_{コンフォーマンス・ステートメント}

_{追加・拡張}

サービスクラスと情報オブジェクト 

サービスクラスと情報オブジェクト 