DICOM今昔物語

＜特集＞DICOMの過去・現在・未来
1.DICOMの過去～DICOMの歴史
DICOM今昔物語

	シーメンス旭メディテック株式会社メディカル・ソリューション・マーケティング本部 HSグループ森　周平　先生

　初めて「ダイコム」という「言葉」を耳にしたのは、何年前だったろう? 今から10年程前に、当時米国の電気製造業の工業会に関連のあった外国人から「その音」を聴いた記憶が微かに残っている。確か、自社のMR装置と他社の装置のデータ接続をするというプランについて議論をしていた夕暮れの会議室でのことだった。その頃は、画像撮像装置から画像保存装置や画像処理装置に画像データを送信するときの経路として、コンピュータとモニタやプリンタなどの周辺機器を接続するために使われる接続線を利用することが主流であり、現在のようなネットワーク(Ethernetなど) 接続はあまり用いられていなかった。
　このような接続は常に一対一であることから、接続の都度、新たなソフトウエア開発が必要になり、お金も時間も無駄に費やされていた。
　そんな厄介な状況に困惑していた者にとって、「ダイコム」は福音以外のなにものでもなかった。

　CT装置の実用化がスタートした1970年代以降、MR装置の臨床現場への応用、PACS(Picture Archiving and Communication System)の試みなど、医療画像のデジタル化は急激に進んだ。もともと画像のデジタル化は画質や撮像効率の向上が目的とされてきたが、 3D処理を始めとする画像処理や画像保存についてもデジタル化のメリットが期待されるようになってきた。当然、撮像装置ベンダーも処理装置や保存装置を供給しているケースもあったが、異なるベンダーの装置で処理や保存を行いたい要求も増えていた。
　しかし、当初は撮像装置から処理・保存装置へのデータ接続には二つの壁が存在していた。その壁のひとつめは、画像データの形式だった。
　データの形式は各ベンダーによって異なり、さらに形式自体が各ベンダーの内部情報となっていたため、データのやり取りをするためには、ベンダー間で守秘義務契約を交わしたうえで形式に関する内部情報を開示し、形式変換のソフトウエア開発を行うことが必要であった。
　こうしたなか、米国において北米放射線学会(ACR:American College of Radiology)と電機製造業の工業会(NEMA: National Electrical Manufacturers Association)が共同して、医療における画像データの形式についての標準化を目的に、 1983年にACR-NEMA委員会を立ち上げた。この委員会メンバーの尽力により、2年後の1985年には最初の画像データの形式に関するスタンダード ACR-NEMA Ver.1規格が生まれた。この規格を使うことで、異なるベンダー間でもデータ形式についての接続性を確保することができるようになったわけである。これだけでも、医療画像データの有効利用にはかなりの利便性がもたらされたのだが、データ接続のためにはデータ形式の統一だけでは不足であり、データ通信のための手順も規格化する必要があると議論されるように至った。この通信手順がふたつめの壁だったわけである。
　とりあえず一対一の装置間の通信手順が検討されスタンダードとなったのが1988年に発表されたACR-NEMA Ver.2と呼ばれるものであった。しかし時代はすでにインターネットの台頭期を迎えており、ネットワークによる複数対複数の通信が当然となっていたため、一対一の通信は時代遅れの方法とされ、この規格による通信手順はほとんど使われなかったといえる。そこで、ACR-NEMA委員会はネットワーク上での通信手順の規格化の検討を始めた。このスタンダードが、データ形式はACR-NEMA Ver.2規格をベースとしつつ、通信手順の標準化を含めた「ダイコム」(DICOM)規格である。
　“DICOM”とは、”Digital Imaging and COmmunications in Medicine”のそれぞれ頭文字をとったもので、一般的に日本では「医療におけるデジタル画像と通信」と訳されている。ちなみに、”DICOM3.0”と呼ばれることもあるが、ACR-NEMA Ver.1およびVer.2という経緯からの名残りであり、いわゆる”DICOM”とまったく同一のものである。1992年にはDICOM規格の暫定版が作成され、宣伝、普及のためにシカゴで行われた北米放射線学会(RSNA:Radiological Society of North America)のInfoRADで暫定版を利用した異なるベンダー間の接続のデモンストレーションが行われた。そして1年後の1993年には、正式にDICOM規格としてパート1より9が発行されたのである。
　パート1は概論、2が適合性となっており具体的な通信手順およびデータ形式についての規定は3から8までとなっている。それぞれのパートで何が記されているかを簡単に表すと、3では扱うデータの種類、4はデータ接続の各種機能、5でデータの構造、 6がデータの名前や意味をまとめたデータ辞書、7では実際の電文の交換方法、8でネットワーク手順ということになる。パート9はというと、ACR-NEMA Ver.2で規格化された一対一の通信を使用する方法が規定されているのだが、これは単に規格として前バージョン(ACR-NEMA Ver.2)との整合性を保つだけのためのものであったため、実際に使われることはなく現在は規格から外されている。

　もう少しDICOMの規格自体を詳しく見てみよう。DICOMの中で「つぼ」といえるのは、パートでいうと3と4になる。 3では「何」を、4では「どうする」のかが規定されているのだが、「何」という中身はCTやMRといった画像データを、「どうする」つまり、送受信するのか、データ検索するのか、フィルミングするのかといったことが決められている。 DICOMでは「何」というのを「オブジェクト」と表現し、「どうする」というのを「サービス」と呼んでいる。多くの日本人は、「サービス」というと「奉仕する」というようなイメージを抱いてしまうが、DICOMでいうところの「サービス」は、単に機能とか動作といったような意味合いである。たとえばA社のCT装置から、B社の画像処理装置に画像データを送信する場合、「何」というのは「CT画像オブジェクト」であり、「どうする」というのは「ストレージサービス」となる。さらに、「サービス」には「する側」と「される側」が存在することから、DICOMではそれぞれのサービスについて「する側」をサービスクラスプロバイダー(SCP: Service Class Provider)、「される側」をサービスクラスユーザー(SCU: Service Class User)としている。 CT装置から画像処理装置に画像データを送信するケースでは、CT装置がストレージサービスクラス(Storage Service Class)のSCU、画像処理装置がStorage Service ClassのSCPということになる。ストレージというのは「保存」という意味であるから、「保存」というサービスを「する側」が受信側であり、SCPと呼ばれるのである。その他、データ検索にはクエリー・リトリーブサービスクラス (Query/Retrieve Service Class、Q/Rと略される場合もある)、フィルミングにはプリントサービスクラス(Print Service Class)が用いられる。画像処理装置から画像サーバにデータ検索をかける場合は、処理装置がQuery/Retrieve ServiceのSCU、サーバがQuery/Retrieve ServiceのSCPとなり、 CT装置からレーザーイメージャーにフィルミングする場合は、CT装置がPrint Service ClassのSCU、レーザーイメージャーがPrint Service Classの SCPということになる。

　1993年のDICOM規格(パート1より9)発行ののち、国内では「ダイコム」という言葉だけが独り歩きしていた時期がある。とくに装置間のデータ接続に多くの苦労を重ねてきた人たちは、まだ得体の知れぬ「ダイコム」に過大な期待をかけ、「ダイコム」はすべてを解決するといった幻想を抱いてしまっていたのである。「DICOM万能主義」とでもいえば良いのだろうか。 DICOM規格書は膨大な量の文書である。具体的な内容が記されているパート3から8だけでも、そのページ数は1,132ページにものぼる。これだけ広範な規格であるから、すべての範囲をカバーする「DICOM対応」装置というのはあり得ず、一般的に規格の一部をサポートしているだけで「DICOM対応」と称されている。このことが「DICOM万能主義者」たちを、不幸に陥れたのである。つまり、「DICOM対応装置」を二つ買い入れて接続してみたが、うまく繋がらないということが起こったのである。
　二つの「DICOM対応装置」がサポートしているDICOM規格の範囲が一致していなければ、接続できないことがある。この二つの装置を、CR装置と画像処理装置と想定してみよう。 CR装置から画像処理装置に画像を送信しようとするとき、CR装置はStorage Service ClassのSCUを、また画像処理装置はStorage Service ClassのSCPをサポートしている必要がある。どちらの装置もそれぞれSCU、SCPをサポートしていても、かりに画像処理装置が CT/MR画像専用の場合、CR画像という「オブジェクト」をサポートしていないので接続はできないことになる。したがって、二つの「DICOM対応装置」の間で画像送信を行う場合、それぞれが同じオブジェクトおよび同じStorage Service Classをサポートし、送信側がSCU、受信側がSCPの役割を持っていなければ接続できないのである。
　「DICOM対応装置」を考えるとき、どのオブジェクト、Service Classをサポートし、どのような役割(SCUなのかSCPなのか)を持っているのかがたいへん重要である。こうした重要な情報が記されている文書が、コンフォーマンス・ステートメント(Conformance Statement)であり、その記述方法などが記されているのが、DICOM規格パート2(適合性)である。基本的には、「DICOM対応装置」にはすべてこの文書が付帯されることになっているので、二つの「DICOM対応装置」間の接続性を検討するときは、それぞれのConformance Statementを照合することから始めることとなる。

　何年も前の話になるが、ビデオテープの記録方式で”β(ベータ)”方式と”VHS”方式が競い合っていた時期がある。周知のとおり”VHS”方式がスタンダードの地位を得て、いまどきビデオテープの購入時に記録方式を確認する人は皆無である。現在、医療画像に関連する装置でDICOMに対応していない装置は消滅しつつある。何年か先には、装置間の接続に関して誰も”DICOM”という”Word”さえ口にしなくなるだろう。それほど、”DICOM”は当たり前のことになるからである。