「DICOM」の版間の差分

2016年7月11日 (月) 10:16時点における最新版

DICOM公式ロゴ

オープンソース DICOMビューア OsiriXを用いてCurved MPRを作成

DICOM（読み：だいこむ、語源：Digital Imaging and COmmunication in Medicine）とは、医用画像にまつわる標準規格で、主に放射線科領域における各種検査装置（モダリティ機器やPACS）が用いる医用画像フォーマットを筆頭に、検査機器間のファイル転送や患者情報や検査情報のやりとりなどの通信プロトコルを定義した規格である。

概要[編集 | ソースを編集]

DICOMと一言でいっても、DICOMが定める範囲は非常に広く、検査機器が生成する画像フォーマット（DICOMファイル）や、その画像をやりとりする通信プロトコル（DICOM通信）、患者情報や検査情報の通信（MWM）など様々なものがある。

DICOM規格は米国における独自規格であり、ISOなどが定める世界標準規格ではなかったが、世界的に事実上のデファクトスタンダードとなっていた。2006年にISOは「ISO 12052:2006」という名称のもと、ISOでは医用画像などに関する規格化を行わず、その全権をDICOMに委ねるとする参照規格と定められ、標準規格として認められるに至っている。

現代では一般的な写真カメラがデジタル化したように、レントゲン写真もデジタル化し、フィルムではなく画像ファイルとして保存されるようになり、ファイルサーバーで管理され、その受け渡しもネットワーク越しに行われるようになった。

DICOMでは、その画像ファイルのフォーマットやネットワーク越しの受け渡し方法などを規格化したもので、CT（コンピュータ断層撮影）やMR（核磁気共鳴画像法）、CR（コンピュータX線撮影）などの医用画像機器（モダリティ）で撮影した医用画像のフォーマットをはじめ、それらの画像データをどのように他のモダリティやPACS、ドライイメージャーなどで送受信するか、高精細モニターの初期設定はどうあるべきか、などが細かく規格化されている。

もともとはヒト（人間）のために作られた規格であるが、動物病院をはじめ、医療の枠をこえて飛行機などの非破壊検査でも使われ始めており、DICOM規格もそれらに対応すべく拡張が続けられている。

利点と欠点[編集 | ソースを編集]

DICOM画像[編集 | ソースを編集]

読影を行うという意味では高精細モニターが写真フィルムに比べ画質が大幅に劣ることから敬遠される傾向があった。たとえばレントゲン写真をみるためのシャウカステンは輝度3000～15000カンデラ、写真フィルム自体のコントラストは20000諧調くらいある。2013年現在の最高スペックの高精細モニターをもってしても一桁性能が違うというのが実情である。

ただDICOM画像はウィンドウレベル変換などの写真フィルムとは異なる見方ができ、画像解析や再構成も容易であり、可搬性や保管性なども圧倒的に優れているなど、写真フィルムにはない利点も多々ある。

DICOM通信[編集 | ソースを編集]

DICOM通信を用いることでDICOM画像をネットワーク越しに簡単にやりとりできるため、遠隔医療・遠隔読影も普及の兆しを見せている。

ただし遠隔医療における施設間の連携は、学閥・医局の繋がりが総てと言っていいほど強いので、最近流行りのパブリック・クラウド的な商業サービス化にたどり着くには何十年もかかると思われる。

またDICOM画像には画像データの他にもDICOMタグとして非常にデリケートな患者の個人情報を大量に含んでおり、医療機関を結ぶネットワークのセキュリティも問題視されることが多い。

問題点[編集 | ソースを編集]

初期のDICOM規格ではOSI参照モデルに準拠した製品を想定し、IEEE 1284（通称セントロニクス、パラレル・プリンタ端子として有名）やRS-232Cによる2点間通信を筆頭に、コンピュータ創世記に考案された多種多様な通信方式をサポートできるようになっていた（現在はTCP/IPを残し、他は全て廃止された）。

その一方で、世間一般ではOSI参照モデルではなく、インターネットやイントラネットで用いられているDARPAモデル（≒インターネット・プロトコル）に準拠した製品が普及してしまった。なお、OSI参照モデルとDARPAモデルを対照表にしている文献も多々見受けられるが、インターネット技術の標準化策定組織であるIETFは再三にわたりインターネット・プロトコルがOSIに準拠する事は意図しない間違った情報であると述べている。

このためDICOMでは追加仕様としてTCP/IPサポートが追加されたのだが、その際にTCP/IP上でOSI参照モデルをカプセル化（ほぼエミュレーション）するという手法を採用した。これにより既存のシステムはTCP/IPの単純な処理を実装するだけで対応できるという利点もあったが、その一方で純粋なDARPAモデル準拠製品ではネットワークカード上の専用ハードウェア（LAN端子に直結する半導体）で超高速に処理されるパケットの並び替えや再送処理などが行われず、全てDICOM通信を実装する各ソフトウェアによって行われることとなり、CPUへの負荷が高く、通信速度も出ないなどという問題を抱えることになった。

また、HTTPなどの多くのシステムが採用する通信プロトコルではなく、完全にDICOM独自の通信プロトコルを採用しているため、ルーターやファイアーウォールなどは初期設定で通信を拒絶するようになっていることが多く、遠隔読影はもとより部門間で異なるネットワークを構成しているような施設ではこれらの設定変更が問題となることが多い。

ただ、このような幅広い間口を用意したことで普及を促進したのも事実である。現在はパソコンを中心としたコンピュータの想像を絶する進化と、医療機器の進化の遅さも相まって、いずれも問題にならないレベルに達している。唯一の残された問題点は、ニッチな市場性と、新規参入の難しさくらいである。

これらの問題に対処するため、他社システムとの通信には互換性の高いDICOMを用いるが、自社製品間では利便性の高いHTTPをベースとした独自プロトコルを採用するシステムも増えつつある。ただしDICOM関連の実装が二の次となっているシステムも少なからず存在し、そのようなシステムを導入することでデータ移行が事実上不可能な状況に陥るケースも見受けられるため、採用には細心の注意を払う必要がある。

内包データ形式[編集 | ソースを編集]

DICOMは医用画像向けの規格であり、一般的にはCT等から発生する生データや、それらをランレングス圧縮やJPEG、JPEG2000といったで圧縮形式で画像データが内包されている。

DICOM規格で規定しているデータ種別には、RFC2557（MHTML）およびXMLによるプレーン・テキスト形式が存在し、それらの形式を用いてBASE64などでエンコード（カプセル化）を行えば（データ変換しておけば）、事実上どんなデータでも内包できる。ただし、そのような実装を行っているソフトは非常に稀であり、心電図の心音を音声ファイルとして格納している例が確認されている程度である。

画像ファイルフォーマットとしてのDICOM[編集 | ソースを編集]

「DICOMファイル」の項目を参照。

ネットワークプロトコルとしてのDICOM[編集 | ソースを編集]

「DICOM通信」の項目を参照。

歴史[編集 | ソースを編集]

「DICOM/歴史」の項目を参照。

詳細[編集 | ソースを編集]

DICOM関連ソフトウェア[編集 | ソースを編集]

CTN - RSNAおよびNEMA公式のC言語で開発されたオープンソースのDICOMライブラリ
DCMTK - C++で開発されたオープンソースの高機能DICOMライブラリおよびツールキット
OsiriX - オープンソースの高機能DICOMビューアー（簡易的なDICOMサーバー機能もある）

参考文献[編集 | ソースを編集]

この項目「DICOM」は、医学に関連した書きかけの項目です。加筆・訂正などをして下さる協力者を求めています（ポータル医学と医療／ウィキプロジェクト医学）。

@@ 14行目: / 14行目: @@
 もともとは[[ヒト]]（[[人間]]）のために作られた規格であるが、[[動物病院]]をはじめ、医療の枠をこえて飛行機などの非破壊検査でも使われ始めており、DICOM規格もそれらに対応すべく拡張が続けられている。
-== 画像ファイルフォーマットとしてのDICOM ==
-「[[DICOMファイル]]」の項目を参照。
-== ネットワークプロトコルとしてのDICOM ==
-「[[DICOM通信]]」の項目を参照。
 == 利点と欠点 ==
 === DICOM画像 ===
@@ 34行目: / 27行目: @@
 また[[DICOM画像]]には画像データの他にも[[DICOMタグ]]として非常にデリケートな[[患者]]の個人情報を大量に含んでおり、[[医療機関]]を結ぶネットワークのセキュリティも問題視されることが多い。
-== 歴史 ==
+== 問題点 ==
-DICOMの正式な規格名は「'''DICOM 3.0'''」である。
+初期のDICOM規格では[[OSI参照モデル]]に準拠した製品を想定し、[[IEEE 1284]]（通称[[セントロニクス]]、パラレル・プリンタ端子として有名）や[[RS-232C]]による2点間通信を筆頭に、コンピュータ創世記に考案された多種多様な通信方式をサポートできるようになっていた（現在は[[TCP/IP]]を残し、他は全て廃止された）。
-=== 20世紀 ===
+その一方で、世間一般では[[OSI参照モデル]]ではなく、[[インターネット]]や[[イントラネット]]で用いられている[[DARPAモデル]]（≒インターネット・プロトコル）に準拠した製品が普及してしまった。なお、OSI参照モデルとDARPAモデルを対照表にしている文献も多々見受けられるが、インターネット技術の標準化策定組織である[[IETF]]は再三にわたりインターネット・プロトコルがOSIに準拠する事は意図しない間違った情報であると述べている。
-世紀の医用画像業界は大手[[モダリティメーカー]]による支配下にあった。大手[[モダリティメーカー]]による独自規格が乱立し、メーカー間どころか、自社システム間ですら他部署が作ったので互換性がないという状況で、何かしらのシステムを導入するたびに大規模な相互接続システムの開発が行われていた。
-ここ最近の無名フリーソフトにも遙かに劣る今では考えられないほどショボいスタンドアローンの医用画像ワークステーション（医用画像ビューア専用パソコン）ですら1台1億円を越え、その医用画像ビューアで見るために[[モダリティ機器]]からフロッピーディスクに画像データを書き出すシステムも特注開発で1[[モダリティ]]あたり数千万円という恐ろしい世界が出来上がっていた。
+このためDICOMでは追加仕様としてTCP/IPサポートが追加されたのだが、その際にTCP/IP上でOSI参照モデルをカプセル化（ほぼエミュレーション）するという手法を採用した。これにより既存のシステムはTCP/IPの単純な処理を実装するだけで対応できるという利点もあったが、その一方で純粋なDARPAモデル準拠製品ではネットワークカード上の専用ハードウェア（LAN端子に直結する半導体）で超高速に処理されるパケットの並び替えや再送処理などが行われず、全て[[DICOM通信]]を実装する各ソフトウェアによって行われることとなり、CPUへの負荷が高く、通信速度も出ないなどという問題を抱えることになった。
-メーカーにしてみれば、それはユーザーの囲い込みであり、一度導入されてしまえば他社への乗り換えは事実上不可能、かつ何かしらを導入するたびに大規模な連携システムの開発が行われ、莫大な金が動く非常に儲かる商売であり、当然その利権を手放そうとはせず、その混沌は日々加速していった。
+また、[[HTTP]]などの多くのシステムが採用する通信プロトコルではなく、完全にDICOM独自の通信プロトコルを採用しているため、[[ルーター]]や[[ファイアーウォール]]などは初期設定で通信を拒絶するようになっていることが多く、[[遠隔読影]]はもとより部門間で異なるネットワークを構成しているような施設ではこれらの設定変更が問題となることが多い。
-=== 革命前夜 ===
+ただ、このような幅広い間口を用意したことで普及を促進したのも事実である。現在は[[パソコン]]を中心とした[[コンピュータ]]の想像を絶する進化と、[[医療機器]]の進化の遅さも相まって、いずれも問題にならないレベルに達している。唯一の残された問題点は、ニッチな市場性と、新規参入の難しさくらいである。
-その混沌とした医用画像業界に終止符を打つべく、[[米国放射線学会]] (ACR) が主導し、1981年から医用画像フォーマットの標準化を目指す医用画像規格の開発が始められた。
-ただ、ACRは[[放射線科医]]を中心とする利用者側の団体であり、単独で発表したところで、利権に塗れた世界中のメーカーの連合などに潰されてしまうのは目に見えていた。
+これらの問題に対処するため、他社システムとの通信には互換性の高いDICOMを用いるが、自社製品間では利便性の高いHTTPをベースとした独自プロトコルを採用するシステムも増えつつある。ただしDICOM関連の実装が二の次となっているシステムも少なからず存在し、そのようなシステムを導入することで[[データ移行]]が事実上不可能な状況に陥るケースも見受けられるため、採用には細心の注意を払う必要がある。
-そこでACRは[[北米電子機器工業会]] (NEMA)の助けを借り、[[ACR-NEMA]] 1.0を1985年に発表、続けて[[ACR-NEMA]] 2.0を1988年発表した。
+== 内包データ形式 ==
+DICOMは[[医用画像]]向けの規格であり、一般的には[[CT]]等から発生する生データや、それらを[[ランレングス圧縮]]や[[JPEG]]、[[JPEG2000]]といったで圧縮形式で画像データが内包されている。
-この時点では世界が動くことはなかったが、生き残った。
+DICOM規格で規定しているデータ種別には、[[RFC2557]]（[[MHTML]]）および[[XML]]による[[プレーン・テキスト]]形式が存在し、それらの形式を用いて[[BASE64]]などでエンコード（[[カプセル化]]）を行えば（データ変換しておけば）、事実上どんな[[データ]]でも内包できる。ただし、そのような実装を行っているソフトは非常に稀であり、[[心電図]]の[[心音]]を音声ファイルとして格納している例が確認されている程度である。
-=== DICOM 3.0 ===
+== 画像ファイルフォーマットとしてのDICOM ==
-その後、1992年の[[北米放射線学会]]でDICOM3.0を大々的に発表したのを切っ掛けに一気に流れが変わった。この時点でも大手[[モダリティメーカー]]を動かすことは出来なかったが、その存在が一気に世界中の[[医療従事者]]に知られることとなった。欧州を中心としたフリーソフト[[Osiris]]の登場や、日本における[[J-MAC SYSTEM]]の登場と低価格市場の開拓など、大きな波が生まれようとしていた。
+「[[DICOMファイル]]」の項目を参照。
-この際、ACR-NEMA 2.0から仕様が劇的に大規模化したことを受け、ACR-NEMA 3.0からDICOM 3.0 (1993年)と名称変更された。また、併せて新たに[[DICOM Standards Committee]]という団体が設立され、規格制定および追加・変更はそちらに移管された。
+== ネットワークプロトコルとしてのDICOM ==
+「[[DICOM通信]]」の項目を参照。
-なお、1993年のDICOM 3.0の制定から規格変更が行われていないわけではなく、以降はDICOM 3.0 2009などと改訂年度が末尾に付くようになった。改訂に際しては「廃止」と「追加」のみが行われており、「変更」は行われていない。このため、DICOM規格の改定が行われても、既存システムに影響が出ることはなく、その時点での[[適合性宣言書]] ([[コンフォーマンス・ステートメント]])の改訂を必要としない。ただし、希に例外的な改変があるので注意が必要である。
+== 歴史 ==
+「[[DICOM/歴史]]」の項目を参照。
-=== 世界標準 ===
-本当の意味でDICOMが世界を動かしたのは2003年3月23日の出来事である。
-年3月23日、米国政府は以下のような発表を行った。<ref>http://aspe.hhs.gov/datacncl/hixs.htm</ref>
- この命令は即日発効である。
- すべての連邦機関は次の規格を採用しなければならない。
- Digital Imaging and COmmunication in Medicine、DICOM。
- これは医療に関わるデジタル画像と診断情報を、さまざまなメーカーのデバイスや、
- 医療スタッフの使うワークステーションから検索および取得を可能にするものである。
-世界最大の市場である米国で商売したければ、必ずDICOMに準拠しろという命令が発効されたのである。
-大手[[モダリティメーカー]]も動かないわけには行かなくなった。
-あとはご存じの通り。
-== 問題点 ==
-初期のDICOM規格ではOSI参照モデルに準拠した製品を想定し、IEEE 1284（通称セントロニクス、パラレル・プリンタ端子として有名）やRS-232Cによる2点間通信を筆頭に、コンピュータ創世記に考案された多種多様な通信方式をサポートできるようになっていた（現在はTCP/IPを残し、他は全て廃止された）。
-その一方で、世間一般ではOSI参照モデルではなく、インターネットやイントラネットで用いられているDARPAモデル（≒インターネット・プロトコル）に準拠した製品が普及してしまった。なおOSI参照モデルとDARPAモデルを対照表にしている文献も多々見受けられるが、インターネット技術の標準化策定組織であるIETFは再三にわたりインターネット・プロトコルがOSIに準拠する事は意図しない間違った情報であると述べている。
-このためDICOMでは追加仕様としてTCP/IPサポートが追加されたのだが、その際にTCP/IP上でOSI参照モデルをシミュレートするという手法を採用した。これにより既存のシステムはTCP/IPの単純な処理だけを実装するだけで対応できるという利点もあったが、その一方で純粋なDARPAモデル準拠製品ではネットワークカード上の専用ハードウェアで超高速に処理されるパケットの並び替えや再送処理などが全てソフトウェアによって行われることとなり、CPUへの負荷が高く、通信速度も出ないなどという問題を抱えることになった。
-また、HTTPなどの多くのシステムが採用する通信プロトコルではなく、完全にDICOM独自の通信プロトコルを採用しているため、ルーターやファイアーウォールなどは初期設定で通信を拒絶するようになっていることが多く、[[遠隔読影]]はもとより部門間で異なるネットワークを構成しているような施設ではこれらの設定変更が問題となることが多い。
-ただ、このような幅広い間口を用意したことで普及を促進したのも事実である。現在はパソコンを中心としたコンピュータの想像を絶する進化と、[[医療機器]]の進化の遅さも相まって、いずれも問題にならないレベルに達している。唯一の残された問題点は、ニッチな市場性と、新規参入の難しさくらいである。
-これらの問題に対処するため、他社システムとの通信には互換性の高いDICOMを用いるが、自社製品間では利便性の高いHTTPをベースとした独自プロトコルを採用するシステムも増えつつある。ただしDICOM関連の実装が二の次となっているシステムも少なからず存在し、そのようなシステムを導入することで[[データ移行]]が事実上不可能な状況に陥るケースも見受けられるため、採用には細心の注意を払う必要がある。
-== 内包データ形式 ==
-DICOMは[[医用画像]]向けの規格であり、一般的には[[CT]]等から発生する生データや、それらをランレングス圧縮や、JPEG、JPEG2000といったで圧縮形式で画像データが内包されている。
-DICOM規格で規定しているデータ種別には、RFC2557（MHTML）およびXMLによるプレーン・テキスト形式が存在し、それらの形式をもちいてカプセル化を行えば（データ変換しておけば）、事実上どんなデータでも内包できる。ただし、そのような実装を行っているソフトは非常に稀であり、[[心電図]]の[[心音]]を音声ファイルとして格納している例が確認されている程度である。
 == 関連用語 ==
@@ 103行目: / 62行目: @@
 * [[DICOMファイル]]
 * [[DICOM通信]]
+* [[DICOMタグ]]
 == DICOM関連ソフトウェア ==