1. No category

岐阜県診療放射線技師会
医療情報研究会 様
診療放射線技師に必要なＤＩＣＯＭの知識
コニカミノルタヘルスケア株式会社
名古屋支店 ソリューショングループ
鳥居 大樹
目次
ＤＩＣＯＭの歴史
ＤＩＣＯＭ通信について
ＤＩＣＯＭ規格について
施設間電子媒体運用の課題『ＰＤＩ／ＩＨＥ』
目次
ＤＩＣＯＭの歴史
ＤＩＣＯＭ通信について
ＤＩＣＯＭ規格について
施設間電子媒体運用の課題『ＰＤＩ／ＩＨＥ』
ＤＩＣＯＭの歴史
１９７０年代
ＣＴの実用化、ＭＲやＤＳＡの市場導入による画像診断電子化時代の到来
・最優先テーマは機器の性能向上
１９８０年代
医療情報のデジタル化が急速に普及、各機器間でのデータの情報共有化
有効利用の要望が高まる。
・メーカー独自の方式でデータ交換
問題点
①接続のための専用開発が必要、長い期間とコスト
②機器の更新やシステム拡張の際は再度設計のやり直し
③制約事項が多く、自由度の高い機器の選択ができない 標準化必要
ＤＩＣＯＭの歴史
１９８３年
ＡＣＲ（米国放射線学会）とＮＥＭＡ（米国電気機器工業会）が合同で
ＡＣＲ－ＮＥＭＡ委員会を結成
１９８５年
ＡＣＲ－ＮＥＭＡ規格（Ｖｅｒ１．０）を発表
１９８８年
ＡＣＲ－ＮＥＭＡ規格（Ｖｅｒ２．０）を発表
機器同士１：１での通信方法が標準化
ＤＩＣＯＭの歴史
１９９０年代
複数機器の接続によるネットワークの時代へ移行
医療分野でもデータの多様化による同様の仕組みを要望
通信設計思想を抜本的に変更
１９９３年
ＤＩＣＯＭ規格として承認
・設計思想が根本的に異なるためＡＣＲ－ＮＥＭＡ規格（Ｖｅｒ３．０）ではなく
現在はＤＳＣ（ＤＩＣＯＭ Ｓｔａｎｄａｒｄｓ Ｃｏｍｍｉｔｔｅｅ）がサポート
ＤＩＣＯＭとは
Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｉｎ Ｍｅｄｉｃｉｎｅ
■ 標準的なネットワーク環境に適応した規格
■ 情報交換の媒体としてネットワークだけでなくオフラインメディアも可能
■ 扱う情報は医療画像に関連するものが中心
■ オープン規格であり、インターネットで無償
で入手可能。※印刷すると3000項以上
ＤＩＣＯＭの特徴
■ 『オブジェクト指向』 の概念に基づき定義
・扱われる医用情報の構造を細部にわたって明確に定義
■ コンフォーマンス・ステートメント（適合性宣言）
・製造者はサポート範囲について明確に宣言する
■ 追加/拡張/修正を継続的に実施
ＤＩＣＯＭ規格内容
■ ＤＩＣＯＭ規格はパートで構成されている
Ｐａｒｔ
Ｐａｒｔ
Ｐａｒｔ
Ｐａｒｔ
Ｐａｒｔ
Ｐａｒｔ
Ｐａｒｔ
Ｐａｒｔ
Ｐａｒｔ
Ｐａｒｔ
Ｐａｒｔ
Ｐａｒｔ
Ｐａｒｔ
Ｐａｒｔ
１ ：Ｉｎｔｒｏｄｕｃｔｉｏｎ ａｎｄ Ｏｖｅｒｖｉｅｗ （序文と概要）
２ ：Ｃｏｎｆｏｒｍａｎｃｅ （適合性）
基
３ ：Ｉｎｆｏｒｍａｔｉｏｎ Ｏｂｊｅｃｔ Ｄｅｆｉｎｉｔｉｏｎｓ （情報オブジェクト定義）
本
４ ：Ｓｅｒｖｉｃｅ Ｃｌａｓｓ Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ （サービスクラス仕様）
部
分
５ ：Ｄａｔａ Ｓｔｒｕｃｔｕｒｅｓ ａｎｄ Ｅｎｃｏｄｉｎｇ （データ構造と符号化）
６ ：ＤａｔａＤｉｃｔｉｏｎａｒｙ （データ辞書）
７ ：Ｍｅｓｓａｇｅ Ｅｘｃｈａｎｇｅ （メッセージ交換）
８ ：Ｎｅｔｗｏｒｋ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｕｐｐｏｒｔ ｆｏｒ Ｍｅｓｓａｇｅ Ｅｘｃｈａｎｇｅ（メッセージ交換のためのネットワーク通信サポート）
９ ：Ｐｏｉｎｔ-ｔｏ-Ｐｏｉｎｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｕｐｐｏｒｔ ｆｏｒ Ｍｅｓｓａｇｅ Ｅｘｃｈａｎｇｅ（２点通信サポート） ・・・ リタイヤ
１０：Ｍｅｄｉａ Ｓｔｏｒａｇｅ ａｎｄ Ｆｉｌｅ Ｆｏｒｍａｔ ｆｏｒ Ｍｅｄｉａ Ｉｎｔｅｒｃｈａｎｇｅ
（可搬メディアの論理的データ構造を定義）
１１：Ｍｅｄｉａ Ｓｔｏｒａｇｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｆｉｌｅｓ
（モダリティ別にデータの詳細を定義）
１２：Ｍｅｄｉａ Ｆｏｒｍａｔｓ ａｎｄ Ｐｈｙｓｉｃａｌ Ｍｅｄｉａ ｆｏｒ Ｍｅｄｉａ Ｉｎｔｅｒｃｈａｎｇｅ
（各種メディアに合わせた物理的データ構造を定義）
１３：Ｐｒｉｎｔ Ｍａｎａｇｅｍｅｎｔ Ｐｏｉｎｔ-ｔｏ-Ｐｏｉｎｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｕｐｐｏｒｔ（２点間通信印刷管理サポート）・・・ リタイヤ
１４：Ｇｒａｙｓｃａｌｅ Ｓｔａｎｄａｒｄ Ｄｉｓｐｌａｙ Ｆｕｎｃｔｉｏｎ（グレースケール標準表示関数）
・
・
目次
ＤＩＣＯＭの歴史
ＤＩＣＯＭ通信について
ＤＩＣＯＭ規格について
施設間電子媒体運用の課題『ＰＤＩ／ＩＨＥ』
院内におけるＤＩＣＯＭ通信
病院情報
システム
（ＨＩＳ）
ＰＣ端末
（ｸﾗｲｱﾝﾄ）
情報参照
ＷＥＢ
検査情報
ＨＬ－７
放射線情報
システム
（ＲＩＳ）
実施情報
ＨＬ－７
情報参照
ＷＥＢ
画像サーバ
（ＰＡＣＳ）
画像検索
オーダ情報
撮影装置 ＤＩＣＯＭ
画像送信
ＤＩＣＯＭ
実施情報
ＤＩＣＯＭ
（ﾓﾀﾞﾘﾃｨ）
ドライプリンタ
画像送信
ＤＩＣＯＭ
画像送信
ＤＩＣＯＭ
ワーク
ステーション
ＤＩＣＯＭ通信 ＡＥ（Ａｐｐｌｉｃａｔｉｏｎ Ｅｎｔｉｔｙ）
ＡＥ
ＤＩＣＯＭ通信を行うアプリケーションの実体を示す。（誰であるかの宣言）
ＡＥタイトル
ＡＥを識別するために名づけられた名前
通信設定上はＡＥタイトルでお互いの機器を識別する。
【通信を開始する側】
今から画像送信しても
良いですか？
【通信を受け入れ側】
CRさんから連絡が来た
画像サーバ
（ＰＡＣＳ）
撮影装置
（ﾓﾀﾞﾘﾃｨ）
Ｃａｌｌｉｎｇ ＡＥ
DICOM通信は通信を開始する側から呼びかけ
（Calling AE）てからスタートする。
Ｃａｌｌｅｄ ＡＥ
ＤＩＣＯＭ通信 ＡＥ（Ａｐｐｌｉｃａｔｉｏｎ Ｅｎｔｉｔｙ）
今まで使った言葉でＤＩＣＯＭ通信を開始するとこんなイメージ
モダリティ
AE［ KM_CR_1 ］
こちらは［ KM_CR_001］です。
［ I_PACS 001］ 様に
CR画像保存サービスを
ILの型式（符号化）で
送りたいのですが・・・？
Calling AE Title
Called AE Title
SOP Class
Transfer Syntax
サーバ
AE:［ I_PACS001 ］
①アソシエーション確立の要求
②アソシエーション確立の応答
アソシエーションが
確立したら次の対応
Calling AE Title
Called AE Title
SOP Class
Transfer Syntax
［ I_PACS 001］ です。
［KM_CR_001］様専用で
CT画像保存サービスを受付け可能です。
ILの型式（符号化）で送って下さい。
13
ＤＩＣＯＭ通信 サービスクラス
★DICOM アソシエーションが確立したら、下記のサービス（実際の通信）が可能になります。
【画像系】
Storage
Management
画像送信（保管・転送）
Print Management
プリント送信・受信
Query/Retrieve
問合せ／取得
Storage Commitment
保存委託
Modality WorkList Management
（MWM）
検査情報の取得／管理
（ﾜｰｸﾘｽﾄ管理）
Modality Performed
Procedure Step （MPPS）
検査の実施状況の管理
（実施済み手続きステップ）
【情報系】
「●× Management」 は
DICOMの会話をした時に、きっ
と耳にした事があると思います。
14
院内におけるＤＩＣＯＭ通信
病院情報
システム
（ＨＩＳ）
ＰＣ端末
（ｸﾗｲｱﾝﾄ）
情報参照
ＷＥＢ
検査情報
ＨＬ－７
放射線情報
システム
（ＲＩＳ）
実施情報
ＨＬ－７
情報参照
ＷＥＢ
画像サーバ
（ＰＡＣＳ）
画像検索
オーダ情報
MWM
撮影装置 ＤＩＣＯＭ
実施情報
ＤＩＣＯＭ
MPPS
画像送信
ＤＩＣＯＭ
STORAGE
（ﾓﾀﾞﾘﾃｨ）
ドライプリンタ
画像送信
ＤＩＣＯＭ
RRINT
画像送信
ＤＩＣＯＭ
Q/R
ワーク
ステーション
ＤＩＣＯＭ通信（Ｓｔｏｒａｇｅ Ｓｅｒｖｉｃｅ Ｃｌａｓｓ）
装置間で画像を転送する機能
画像サーバ
（ＰＡＣＳ）
撮影装置
（ﾓﾀﾞﾘﾃｨ）
画像送信
ＳＣＵ
ＳＣＵ
Ｓｅｒｖｉｃｅ Ｃｌａｓｓ Ｕｓｅｒ（サービスクラスユーザ）
ＤＩＣＯＭサービスを利用する側の呼び方
ＳＣＰ
Ｓｅｒｖｉｃｅ Ｃｌａｓｓ Ｐｒｏｖｉｄｅｒ（サービスクラスプロバイダ）
ＤＩＣＯＭサービスを提供する側の呼び方
ＳＣＰ
ＤＩＣＯＭ通信（Ｑｕｅｒｙ/Ｒｅｔｒｉｅｖｅ Ｓｅｒｖｉｃｅ Ｃｌａｓｓ）
医用情報について問い合わせ/検索、画像転送機能
ワーク
ステーション
画像サーバ
（ＰＡＣＳ）
①対象患者の検査リスト要求
②検査リスト提供
③対象検査の画像要求
ＳＣＵ
④画像提供
ＳＣＰ
ＤＩＣＯＭ通信（Ｐｒｉｎｔ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｉｃｅ Ｃｌａｓｓ）
撮影装置、診断装置とドライプリンタを接続し
『画像プリント』する機能
撮影装置
（ﾓﾀﾞﾘﾃｨ）
ドライプリンタ
画像送信
画像サーバ
（ＰＡＣＳ）
ＳＣＵ
ＳＣＰ
ＤＩＣＯＭ通信（Ｍｏｄａｌｉｔｙ Ｗｏｒｋｌｉｓｔ Ｍａｎａｇｅｍｅｎｔ）
検査リストの取得、管理
撮影装置
（ﾓﾀﾞﾘﾃｨ）
検査リスト検索
放射線情報
システム
（ＲＩＳ）
検査リスト送信
ＳＣＵ
ＳＣＰ
患者ＩＤ、日付、モダリティ種等の条件をトリガーに
登録された検査リストを取得する
ＤＩＣＯＭ通信（Ｍｏｄａｌｉｔｙ Ｐｅｒｆｏｒｍｅｄ Ｐｒｏｃｅｄｕｒｅ Ｓｔｅｐ）
検査の実施状況の管理
撮影装置
（ﾓﾀﾞﾘﾃｨ）
検査結果の送信
放射線情報
システム
（ＲＩＳ）
了解
ＳＣＵ
検査終了通知を送信する
（実行撮影条件を送信することも可能）
ＳＣＰ
ＤＩＣＯＭ通信（Ｍｏｄａｌｉｔｙ Ｗｏｒｋｌｉｓｔ Ｍａｎａｇｅｍｅｎｔ）
X線管球
X線発生装置
実施情報返信
＜管電圧・管電流・曝射時間又はmAs値＞
①MWM
②撮影条件送信
X線コントローラ
③実施情報送信
コンソール
RIS端末
④MPPS
（実施情報送信）
セットキーの運用は正確には実施情報を送信できない
【例】
RISコード：両手関節正面
右手関節２Ｒ
→
撮影コード：右手関節正面
→
撮影コード：左手関節正面
→
撮影コード：右手関節正面
→
撮影コード：右主関節側面
目次
ＤＩＣＯＭの歴史
ＤＩＣＯＭ通信について
ＤＩＣＯＭ規格について
施設間電子媒体運用の課題『ＰＤＩ／ＩＨＥ』
ＤＩＣＯＭの情報モデル
患者（Ｐａｔｉｅｎｔ）
検査（Study）
ＣＴ検査
コニカ 太郎
検査インスタンスＵＩＤ
シリーズ シリーズインスタンスＵＩＤ #1 （スカウト）
画像（image） SOPインスタンスＵＩＤ #1
シリーズ シリーズインスタンスＵＩＤ #2 （肺野条件）
画像（image） SOPインスタンスＵＩＤ #01
画像（image） SOPインスタンスＵＩＤ #02
画像（image） SOPインスタンスＵＩＤ #03
シリーズ シリーズインスタンスＵＩＤ #3 （縦隔条件）
画像（image） SOPインスタンスＵＩＤ #11
画像（image） SOPインスタンスＵＩＤ #12
画像（image） SOPインスタンスＵＩＤ #13
検査（Study）
検査（Study）
ＣＴ検査
ＣＲ検査
検査インスタンスＵＩＤ
検査インスタンスＵＩＤ
患者→検査→ｼﾘｰｽﾞ→画像の順番で
格納されている
ＤＩＣＯＭコンフォーマンスとは？
DICOM Conformance Statement ＝ 適合性宣言書
［略してシーエスとも呼ぶ事もある］
・各装置がサポートしているDICOM機能の範囲を明記した説明書
・宣言書を発行する事はDICOM規格に準拠している事を表す
・転送構文や圧縮の使用について記載される
コンフォーマンス取得先
http://www.konicaminolta.jp/healthcare/attached/dicom.html
ＤＩＣＯＭコンフォーマンスの読み方
プリント管理サービスクラス
ﾄﾞﾗｲﾌﾟﾘﾝﾀ
【読み方】
●点線より左側が装置自信を表す
●点線より右側がその装置と情報交換する
相手側の装置を指す
●矢印の向きが情報の送信方向を表す
保存サービスクラス
PACS
【わかる事】
●どのサービスクラスに対応しているか？
RIS
基本ワークリスト管理サービスクラス
検査管理サービスクラス
◆ 拡張文字集合のサポート
ISO-IR 100
ISO-IR 6
ISO-IR 13
ISO-IR 87
（ラテン1）
（ASCII文字）
（半角ｶﾀｶﾅ）
（漢字）
【わかる事】
●どの文字種をサポート出来るか？
※ もしも IR87と書いて無ければ漢字は使えません
ＤＩＣＯＭコンフォーマンスの読み方
プリント管理サービスクラス
ﾄﾞﾗｲﾌﾟﾘﾝﾀ
撮影装置
保存サービスクラス
PACS
保存サービスクラス
RIS
基本ワークリスト管理サービスクラス
RIS
検査管理サービスクラス
保存サービスクラス
PACS
RIS
基本ワークリスト管理サービスクラス PACS
保存委託サービスクラス
検査管理サービスクラス
PACS
問い合わせ/取得サービスクラス
ﾄﾞﾗｲﾌﾟﾘﾝﾀ
プリント管理サービスクラス
ＤＩＣＯＭデータ例
TAG ［ﾀｸﾞ］
→ DICOMデータ要素（データエレメント）の属性を識別する。
各データ要素を格納する荷札の様な物。
全てのデータ要素は属性を識別する「TAG」が付く。
「グループ番号,エレメント番号」 の2つの16進数で表される。
グループ
情報
0008
画像に関する情報
（検査日時、受付番号など）
0010
患者に関する情報
（名前,生年月日など）
0018
収集に関する情報
（検査部位など）
0020
画像付帯情報
0028
画像表示に関する情報
7FE0
画像データ そのものの情報
（検査ｲﾝｽﾀﾝｽUID,検査ID）
【番外】
※ ﾌﾟﾗｲﾍﾞｰﾄTAGとは
各ﾓﾀﾞﾘﾃｨﾒｰｶで独自のｵﾘｼﾞﾅﾙﾃﾞｰﾀを
扱う時に使用。
ｸﾞﾙｰﾌﾟ番号が奇数で表現される。
例 （0011,0010）
（ｳｨﾝﾄﾞ中心,幅 など）
但し、施設外や二次利用を考えると
ﾌﾟﾗｲﾍﾞｰﾄTAGは利用しない方がベター
27
ＤＩＣＯＭ規格
VR ・・・ 値の表現方法を宣言
VM ・・・ タグ内にいくつのデータを持つか
タイプ ・ 必須項目か？省略可能か？
タグ
属性名
VR
VM
タイプ
（0010,0010）
患者の名前
PN
１
2
グループ番号
エレメント番号
【例】
VR PN ・・・ 人名を格納出来ます。
VM １ ・・・ １つだけデータを持てます。
タイプ 2 ・・・ 項目が必須だが、値が不明ならば
空欄で送っても構わない。
ＤＩＣＯＭ規格（例）
【ＶＲ】 には どんな宣言があるのか？
ＰＮ
ＬＯ
ＳＨ
ＳＴ
ＬＨ
ＤＡ
ＴＭ
ＵＩ
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
格納するタグ（箇所）により
0010,0010「患者名」
0032,1032「依頼側医師名」
0008,1070「操作者名」
などになります
人名を格納
値を64文字まで格納
値を16文字まで格納
テキストを1024文字まで格納可能
テキストを10240文字まで格納可能
日付を表す文字列が 「YYYYMMDD」型式で格納
時刻を表す文字列が 「HHMMDD」型式で格納
UID “0”~”9”と”.”の組合わせ 64文字を格納
【ＶＭ】 には どんな表現があるのか？
●数値で表した数だけデータ要素に格納されます。
例
『１』 ・・・・ 250
『２』 ・・・・ 512¥1024
『１-３』 ・・・ 123 の時もあれば 123¥456¥789 など格納要素の個数が可変する
ＤＩＣＯＭ規格（例）
【例】
検査ｲﾝｽﾀﾝｽUID
SOPｲﾝｽﾀﾝｽUID
などが該当します。
【タイプ】 とは？
●そのタグ情報が必須 か 不要か？ を宣言している
『１』 ・・・
『２』 ・・・
『３』 ・・・
＊『ｃ』・・・
必須項目でデータ要素も空欄は認められない
必須項目であるが、データ要素は不明の場合は空欄でも良い
データ要素が無い場合は項目ごと省略して構わない。
条件付きで必須
【例】
（0028、2110)で非可逆圧縮画像を
宣言した場合は、（0028,2112）に
圧縮率を定義する。
など。
【例】
患者名
受付番号
生年月日
依頼医師
ＤＩＣＯＭ ＴＡＧの呼称とサンプル（例）
TAG
属性名
ＶＲ
サンプルデータ
（0008,0005）
特定文字集合
ＣＳ
¥ISO 2022 IR87¥ISO 2022IR13
（0008,0016）
SOPクラスUID
ＵＩ
1.2.840.100008.5.1.4.1.1.1
（0008,0018）
SOPインスタンスUID
ＵＩ
1.2.392.200036.9107.638.9002.2014090
（0008,0020）
検査日付
ＤＡ
20140906
（0008,0030）
検査時刻
ＴＭ
154519
（0008,0050）
受付番号
ＳＨ
1234567890123456
（0008,1010）
ステーション名
ＳＨ
CS-7_U001
（0010,0010）
患者氏名
ＰＮ
KONIKA＾TAROU=コニカ＾太郎=ｺﾆｶ＾ﾀﾛｳ
（0010,0020）
患者ID
ＬＯ
1234567
（0010,0030）
患者誕生日
ＤＡ
19730103
ＣＳ
ＵＩ
ＤＡ
ＴＭ
ＳＨ
ＰＮ
ＬＯ
・・・
・・・
・・・
・・・
・・・
・・・
・・・
16文字
値を64文字まで格納
8文字固定『ＹＹＹＹＭＭＤＤ』（日付）
16文字『HHMMSS』
16文字
64文字人名を格納
64文字を格納
こんな感じで格納されています
ＤＩＣＯＭ ＴＡＧの呼称とサンプル（一般撮影）
TAG
属性名
ＶＲ
サンプルデータ
（0018,0015）
検査部位
ＣＳ
CHEST
（0018,0060）
ＫＶＰ
ＤＳ
90
（0018,1150）
照射時間
ＩＳ
30
（0018,1151）
Ｘ線管電流
ＩＳ
200
（0020,000D）
検査インスタンスUID
ＵＩ
1.2.392.20045.6960.4.7.100060.20
（0020,000E）
シリーズインスタンスUID
ＵＩ
1.2.392.20036.9107.307.1042960.2
（0020,0010）
検査ＩＤ
ＳＨ
1234567890123456
（0020,0062）
画像側性
ＣＳ
R
（0028,0010）
横行
ＵＳ
1996
（0028,0011）
縦列
ＵＳ
（0028,0030）
画素間隔
ＤＳ
1572
こんな感じで格納されています
0.175¥0.175
ＤＩＣＯＭ ＴＡＧの呼称とサンプル（ＣＴ）
TAG
属性名
ＶＲ
サンプルデータ
（0008,1030）
検査記述
ＬＯ
ＡＢＤ
（0018,0060）
ＫＶＰ
ＤＳ
120
（0018,1150）
照射時間
ＩＳ
854
（0018,1151）
Ｘ線管電流
ＩＳ
376
（0020,000D）
検査インスタンスUID
ＵＩ
1.2.392.20045.6960.4.7.100060.20
（0020,000E）
シリーズインスタンスUID
ＵＩ
1.2.392.20036.9107.307.1042960.2
（0020,0010）
検査ＩＤ
ＳＨ
1234567890123456
（0020,1041）
スライス位置
ＣＳ
82.709999
（0028,0010）
横行
ＵＳ
512
（0028,0011）
縦列
ＵＳ
512
（0028,0030）
画素間隔
ＤＳ
0.742188¥0.742188
ＤＩＣＯＭ規格（Ｔａｇ置換）
施設運用の効率化を行う目的でＤＩＣＯＭタグのカスタマイズ
１） 検診運用において、自動発番された患者ＩＤを検査ＩＤや受付番号
に置き換えたい
２） ＰＡＣＳ運用において、異なるベンダー間のタグ番号を１つに集約する
例） 検査部位 依頼科等
３） 撮影コンソール上で病棟、病室番号を表示できるようにする。
ＲＩＳ端末
モダリティ
ＰＡＣＳ
ＤＩＣＯＭ規格（Ｔａｇ置換）
ＤＩＣＯＭ タグ
撮影装置
ＰＡＣＳ
患者ＩＤ（００１０，００２０）
２０１４０９０６００１
正規患者ＩＤ
検査ＩＤ（００２０，００１０）
２０１４０９０６００１
受付番号（０００８，００５０）
２０１４０９０６００１
ＤＩＣＯＭ タグ
Ｘ線ＴＶ
検査部位(0018,0015)
検査記述(0008,1030)
ＰＡＣＳ
chest
UP_GI
ＤＩＣＯＭ タグ
ＲＩＳ
病棟（0032,1033）
8F病棟
病室ｺｰﾄﾞ（0040,2009）
815
患者ｺﾒﾝﾄ（0010,4000）
ＣＲ装置
CR装置（CHEST） X線TV（UP_GI）
コンソール
8F病棟815
ＤＩＣＯＭ規格（Ｔａｇ置換）
【メリット】
１） 施設内で必要な情報をＰＡＣＳ管理できる。
２） 部位情報リスト、オーバーレイの視認性改善
３） 施設運用の改善
【注意点】
１） ＤＩＣＯＭ違反を発生させないこと
２） ＤＩＣＯＭタグ情報の確認
ＤＩＣＯＭ Ｐａｒｔ１４ グレースケール画像表示関数
ＧＳＤＦ（グレースケール画像の表示のための標準表示関数）
フイルム表示画像
８ｂｉｔモニター表示
ＤＩＣＯＭ Ｐａｒｔ１４ グレースケール画像表示関数
８ｂｉｔモニタのグレースケール
元のグレースケール
なめらか
とび
つぶれ
ばらつきはモニターのメーカー機種によって様々
ＤＩＣＯＭ Ｐａｒｔ１４ グレースケール画像表示関数
ＧＳＤＦ（グレースケール画像の表示のための標準表示関数）
図6 JND：最小弁別閾
(どこまで階調が見分けられるか
Look-Up Table （LUT）
目次
ＤＩＣＯＭの歴史
ＤＩＣＯＭ通信について
ＤＩＣＯＭ規格について
施設間電子媒体運用の課題『ＰＤＩ／ＩＨＥ』
電子媒体運用（デジタル化）による効果 ＜メリット＞
半切フィルム ２５８円／枚
フィルム袋
３０円／枚
１０枚分であれば・・
→ ２６１０円
ＣＤ－Ｒ
２０円／枚
１枚当たり半切画像データ
３０枚分以上書き込み可能
消耗品の節約
フィルム・フィルム袋
マウス操作のみで患者変更
各種計測、画像処理が行えます
オリジナル画像
拡大・縮小、階調処理、心胸比計測、ｅｔｃ・・
業務効率化
各施設間のネットワークを構築
する事で、簡便に画像の送受信が
可能です
クリニック
病院
専門病院
オンライン連携
41
電子媒体運用（デジタル化）による効果 ＜問題点＞
他院からの依頼データを直接院内ネットワーク
上の端末で読み取るとウィルス感染の恐れが
あります。
院内ネットワークより遮断されたパソコンにてウィルス
チェック後データ読み込みを実施する事を推奨します。
依頼データ
ウィルス感染
ウィルス感染
他院持ち込みデータを院内ＰＡＣＳに保存したいが
取り込むことができない。
ＤＩＣＯＭ規格違反で取り込めない
データ容量が多く取り込めない
ＰＡＣＳ
他院画像取込
ＤＩＣＯＭ規格運用の課題
■ ＤＩＣＯＭは規格を定義するもので運用は規定していない
・ＤＩＣＯＭデータを解釈するためのソフトウエアが必要です。
・提供先の環境はわからない。
・ＤＩＣＯＭ形式以外のデータもＣＤ－Ｒに保存
『ＤＩＣＯＭ』の使い方を定める必要性
そこでＩＨＥが
ＩＨＥとは医療情報の円滑な連携を可能とするため、
規格の使い方を提案しているガイドラインです。
ＰＤＩ （Ｐｏｒｔａｂｌｅ Ｄａｔａ ｆｏｒ Ｉｍａｇｉｎｇ）
■ ＰＤＩとは・・・ＩＨＥで提供されているガイドラインで可搬媒体による画像関連情報を
交換する仕組みを規定した規格です。
利点
画像、診療情報を確実に交換、参照できることを目的としています。
画像、診療情報はＤＩＣＯＭ規格である。
可搬媒体はＣＤ－Ｒメディアである。（ＤＶＤ，ＵＳＢも対象）
◎ コスト削減
◎ 特殊ソフト/端末の必要性無し
◎ 地域医療連携の推進
CD・DVDと言った可搬型媒体にデータだけではなく、DICOM画像を表示する為の
ビューイングソフトを一緒に書き込みする
画像表示用の専門システムが無い施設でもでも画像参照可能
PDI標準規格採用による他院紹介患者対応
検査画像をメディアに
保存して運用
病院
診療所
紹介画像取り込みシステムの必要性
ＤＩＣＯＭデータなら問題ないのでは？
１、ＤＩＣＯＭとＰＤＩの仕様を満たさない事例
・ビューイングソフト付＝ＰＤＩ形式とは限らない
・ＰＤＩ形式はメディアに書き込む際のコンテンツを規格したもの
２、ＤＩＣＯＭ規格の不備、違反
・施設内運用上のカスタマイズで発生した規格違反
・ＰＤＩはＤＩＣＯＭ違反をチェックするものではない
３、運用上の課題
・施設間のやりとりでＳＯＰの重複エラー
・非ＤＩＣＯＭ画像の格納
紹介画像取り込みシステムの必要性
ブラウザによる
参照の仕組み
画像ビューワ、非
DICOM情報
紹介画像取り込みシステムの必要性
ＤＩＣＯＭデータなら問題ないのでは？
DICOM規格違反が理由で、付属のビューワであれば読み込めるのに、PACSに
送信できない場合があります。
⇒ DICOMには、登録する項目（TAG）とそこに登録するデータ
フォーマットが定義されています。
ServiceClass ⇒ TAG ⇒ VR（型） VM（数）
ＤＩＣＯＭ規格違反について
１、ＶＲエラー
・検査日付（0008,0020）
・検査記述（0008,1030）
正しい書式 YYYYMMDD 20140906 2014.09.06
正しい書式 64バイト
64バイト以上の文字列
２、定義語エラー
・0008,0060（モダリティ）
・0018,0015（検査部位）
『CR』 『RF』
『CHEST』 『LSPINE』
『MEG』 『DR』
『PET_CT』 『UP_GI』
３、ＶＭエラー
・検査記述（0008,1030）
データ数は１つのみ定義
・シリーズ記述（0008,103E） データ数は１つのみ定義
○○○￥○○○
２つ存在は違反
※赤字規格違反例
施設間データ運用
以下の事項を満たすものが望ましい。
【依頼元】
１、メディアに書き込む前にデータのチェック
２、運用中のシステムがＤＩＣＯＭ違反を放置していないか確認
３、ＰＤＩにきちんと準拠した実装。
【依頼先】
１、診療の継続性を優先すべき
２、不整合データの修正機能
３、患者情報はＩＲＷＦに準拠して整合性を確保
まとめ ＤＩＣＯＭの課題
１、『ＤＩＣＯＭ＝万能』という誤解
・DICOMであれば何でもでき、何でもつながるの誤解
２、一部のサポートでもＤＩＣＯＭ対応
・ＤＩＣＯＭフルサポートは通常ありえないので、正しいといえば正しい
・ドライイメージャはＳｔｏｒａｇｅ－ＳＣＵ/ＳＣＰは不要
・撮影モダリティにＳｔｏｒｅｇｅ－ＳＣＵは必要だが、ＳＣＰは不要
３、ＤＩＣＯＭ規格は常に進歩している
・既存の装置は進化しない。
・機器更新で搭載した新機能を運用できない可能性もあり
ご静聴ありがとうございました。