医療情報の標準化 •  システム同士が会話（通信）するための「標準語」を定めなければならない。多くのベンダが「共通に」使うべき医療情報の標準を定めることが大事である。 Ø  DICOM Michio Kimura, MD, PhD, FACMI, Hamamatsu University Michio Kimura, MD, PhD, FACMI, Hamamatsu University Ø  HL7 Ø  IHE DICOMによる機器の接続 A社放射線部門システム実施情報＜数千万円＞独自規格 CT装置マルチベンダシステムを比較的容易に実現できるようになった DICOM 患者情報検査オーダ B社 CT装置画像データ C社 PACS × A社放射線部門システム DICOM DICOM策定後独自規格 ×B社 × D社ワークステーション実施情報＜数十万円＞ DICOM DICOM 独自規格患者情報検査オーダ D社ワークステーション × 独自規格 DICOM策定前画像データ C社 PACS DICOM ［ダイコム］ •  Digital Imaging and Communications in Medicine •  ACR（米国放射線学会）とNEMA（米国電気機器工業会）が合同で制定した医療情報交換のための標準規格。 •  医療分野における通信プロトコルのデファクトスタンダード（事実上の標準）のひとつとなっている。 •  情報交換の媒体としてネットワークまたはオフラインメディア（CD、DVD等の可搬媒体）を使用する。 •  医用画像のやり取りのみでなく、画像検査全体に関わるワークフローの改善を目的として拡張が進められている。 •  DICOMはオープンな規格であり、企画書はインターネットから無償で入手可能。病院情報システム（HIS） HIS server 検査オーダ情報患者情報検査オーダ情報レポート情報を WEB配信検査実施情報 HL7 放射線情報システム（RIS） PC端末診療情報 RIS端末画像管理システム（PACS） DICOM DICOM 患者情報検査オーダ情報 Modality Image/Report Viewer レポート情報 RIS server モダリティ画像情報を WEB配信画像情報 DICOM 検査実施情報画像情報 Report Server DICOM Image Server DICOM規格の構成 DICOM規格書は、複数のパートから構成されている。 DICOM規格書は、現在、以下の20のパート（分冊）からなる Part 1 : Introduction and Overview（序文と概要） Part 2 : Conformance（適合性） Part 3 : Information Object Definitions（情報オブジェクト定義） Part 4 : Service Class Specifications（サービスクラス仕様） Part 5 : Data Structures and Encoding（データ構造と符号化） Part 6 : Data Dictionary（データ辞書） Part 7 : Message Exchange（メッセージ交換） Part 8 : Network Communication Support for Message Exchange （メッセージ交換のためのネットワーク通信サポート） Part 9 : Point-to-Point Communication Support for Message Exchange （メッセージ交換のための２点間通信サポート） Part 10 : Media Storage and File Format for Media Interchange （可搬電子媒体を用いたデータ交換のための保存とファイルフォーマット） Part 11 : Media Storage Application Profiles （可搬電子媒体保存応用プロファイル） Part 12 : Media Formats and Physical Media for Media Interchange （可搬電子媒体を用いたデータ交換のための媒体フォーマットと物理媒体） Part 13 : Print Management Point-to-Point Communication Support （プリンタ管理２点間通信サポート） Part 14 : Grayscale Standard Display Function （グレースケール標準表示関数） Part 15 : Security Profiles（セキュリティ・プロファイル） Part 16 : Content Mapping Resource（コード等のマッピング） Part 17 : Explanatory Information（説明情報） Part 18 : Web Access to DICOM Persistent Object （DICOMオブジェクトへのWebアクセス） Part 19 : Application Hosting （アプリケーションホスティング） Part 20 : Transformation of DICOM to and from HL7 Standards （HL7標準への、そしてHL7標準からのDICOM変換） DICOM規格の成り立ち最新のDICOMは、20巻（リタイアを除くと１8 巻）のDICOM Base Standard（規格書本体）と、複数のSupplement（補遺）および Correction Proposal（修正提案）からなる。 DICOM Base Standard （規格書本体）＋ Supplement （補遺）＋ Correction Proposal （修正提案）これらの規格書は、毎年、更新・追加されている。 1対1の機器同士を接続し通信させる方法の標準化 1985年 ACR-NEMA300 -1985 (Ver.1.0） 1988年 ACR-NEMA300 -1988 (Ver.2.0） 1993 ACR-NEMA（Ver.3.0) とならずに「DICOM」と名付けられる。複数台のコンピュータ＆機器をつないだネットワーク通信に対応した標準化 DICOMの特徴 1)  標準的なネットワーク環境（イーサネット等）に対応している。 ü OSI参照モデルに準じるかたで通信プロトコルを定めている。 ü 既に国際的に普及している規格をサポートすることは、システムの信頼性と普遍性を高め、製造者の開発負担を最小限に抑える。 2)  オブジェクト指向に基づいて情報が定義されている。 ü オブジェクト指向はコンピュータプログラミング手法のひとつ。 ü 扱われる医用情報の構造が細部に渡って明確に定義された。（曖昧さの排除） 3)  Conformance Statement（適合性宣言書：コンフォーマンス・ステートメント）によるサポート範囲の明確化が必要である。 1)  可搬電子媒体を利用したオフライン通信が可能である。 ü ネットワーク通信だけでなく電子媒体への画像データ記録について定めている。 2)  追加／拡張／修正が継続的に行われている。 ü 新機能の追加や比較的大きな変更は、Supplement（補遺）を作成 ü 比較的小さな変更は、Correction Proposal（修正提案）を作成［OSI参照モデル］アプリケーション層［TCP/IPモデル］アプリケーション通信サービスの提供 FTP, NFS, TELNET, などアプリケーション層プレゼンテーション層データ表現と形式の管理（HTTP, SMTP など） SOCKET セッション層通信モード（半二重／全二重、同期）の管理トランスポート層通信品質が不十分な時の処理トランスポート層（TCP）ネットワーク層データ通信網の管理インターネット層（IP）データリンク層物理層伝送路の誤り時の処理伝送路の情報ビットを送る物理媒体ネットワークインタフェース層（Ethernet など） TCP／IP •  TCPは、Transmission Control Protocol の略称である。 •  IPは、 Internet Protocol の略称である。 •  プロトコルとは、コンピュータ同士のデータのやり取りの方法を厳格に定めた規格（規約）のことである。 •  TCP/IPは、インターネットで標準的に用いられる通信プロトコル（通信手順）で、TCPとIPを組み合わせたものである。 •  TCP/IPは、通信の世界において事実上の標準となっている。 •  TCPは、配達（人）の仕様のようなものである。 •  IPは、送付人・受取人を明確にする仕様のようなものである。 •  はがきで例をとると、宛先（住所）がIP、実際に配達するのが TCPの役割である。 DICOM通信モデル DICOMはTCP/IPより上位層のみを規定（標準的なネットワーク環境に適合）アプリケーション層 DICOM セッション／トランスポート／ネットワーク層（STN） DICOMデータリンク層 DICOM物理層（50ピン） DICOM Point-to-Pointモデル［リタイア］アプリケーション層（DICOM上位層）プレゼンテーション層セッション層トランスポート層（TCP）トランスポート層インターネット層（IP）ネットワーク層ネットワークインタフェース層（Ethernet, FDDI, etc）データリンク層 DICOM Networkモデル［現実のDICOM通信モデル］物理層 OSI参照モデル DICOMの情報モデルとオブジェクト DICOMは、対象とする画像データや情報をオブジェクト（object）として定義し、それらに対する操作・処理をサービス（service）として定義して実行する。　→　「オブジェクト指向」モデルに基づくサービスオブジェクト対 Service Object Pair （SOP） Object Service 情報オブジェクト定義（データ）操作コマンド（サービス）＋ Information Object Definition（IOD）例：CT画像何を例：格納するどうする DICOM規格：SOP 機能別必須条件データ別必須条件転送情報取得ほか CT画像患者情報ほかメディア規格（データ交換） CD-R DVD DICOM 通信方式 DICOM メディア一般的なネットワーク通信（TCP/IP）オブジェクトとしてのDICOMデータ Ø  IODはDICOMにおけるさまざまな通信操作の対象として位置づけられる。 Ø  IODには、要素を定義する属性群が定められている。 Ø  DICOMでは、要素のある「側面」を表す一塊の属性を「情報モジュール」と呼び、その組み合わせによってIODを定義する。 Ø  情報モジュールは、複数の属性とそれら属性に対する実際の値で構成される。（例えば、属性＝患者氏名、実際の値＝“新潟太郎”） Ø  属性は2つの4桁の数字の組みで定義される。 Ø  例えば、検査IDは（0020，0010）、受付番号は（0008，0050）などである。この数字の組みを「タグ」という。 Ø  情報モジュールの属性のぞれぞれに実際の値、例えば、具体的な患者名や検査日付、担当医指名などが設定されると、具体的な実例として対応するオブジェクトが定義されることになる。 Ø  このような実例を「インスタンス」と呼ぶ。情報モジュールの概念情報実体情報モジュール属性画像要素モジュール患者情報患者モジュール検査情報一般患者検査検査モジュールモジュールシリーズ情報一般参照一般検査シリーズフレーム装置モジュールモジュールモジュール実例（画像）情報行／列サイズ濃淡解釈画像造影/ 一般画像画像要素プレーンポーラスモジュールモジュールモジュールモジュールオーバレイ VOI SOP 画像プレーン LUT 共通モジュールモジュールモジュールモジュール DICOM規格：オブジェクトのデータ構造 CT Image Object SOP Common Module Patient Module SOP Class ID (0008, 0016) 必須 SOP Instance UID (0008, 0018) 必須 Patient Name (0010, 0010) 任意 Patient ID (0010, 0020) 任意 Patient Birth data (0010, 0030) 任意： Image Info. Module ： : Rows (0028, 0010) 必須 Columns (0028, 0011) 必須 Pixel Spacing (0028, 0030) 必須 (7FE0, 0010) 必須 Image Pixel Module ： Pixel Data : : : ヘッダー Tag　［タグ］（もともとは荷札の意味） •  DICOMデータエレメント（データ要素）の属性を識別するためのもの •  2つの16進数（グループ番号とエレメント番号）の組み合わせで表現される •  全てのデータエレメントには、それらを識別するための「タグ」が付けられる Tag　（タグ） Attribute Name　（属性名）（ 0010　，　0010 ） Patient’s Name　（患者氏名）（ 0010　，　0020 ） Patient ID　（患者識別子）（ 0010　，　0030 ） Patient’s Birth Data　（患者生年月日）グループ番号（0010：患者情報グループ）エレメント番号固有識別子（Unique Identifier：UID）すべての画像にはユニークな番号が振られる SOP Instance UIDの振り方の例国際標準化機構 ISO 1. 所属加盟機関（経済産業省） 2. 国日本 392. 団体日本画像医療システム工業会（JIRA） 20036. 企業東芝メディカルシステムズ（株） 9116 装置機種固有識別番号 : 任意 : : 東芝製CT装置のSOP Instance UID（画像ID） 1.2.392.20036.9116.XXXX.YYYY.ZZZZ CT Image StorageのSOP Class UIDは1.2.840.10008.5.1.4.1.1.2 データ要素　data element ひとつのDICOM object （一枚の画像・一人の患者情報）伝送の順序 Data Element Tag （グループ番号）（エレメント番号）属性タグ (0010, 0010) (7FE0, 0010) Data Element VR Data Element Value Length 以降に続くValue Fieldのデータ長 value representation（値表現）暗黙的VR：値表現を省略する明示的VR：値表現を省略しない・・・・・・ Value Field 具体的なデータ値例：氏名、画素値など DICOM基本用語① AE　［エー・イー］ Application Entity ［アプリケーション・エンティティ」の略。 DICOM通信を行うアプリケーションの実体。そのAEを識別するために付けられる名前を AE Title という。通信を開始する（呼びかける）側のAEを Calling AE と呼ぶ。通信を受け入れる（呼ばれる）側のAEを Called AE と呼ぶ。お話しませんか Calling AE Called AE DICOM基本用語② Abstract Syntax　［アブストラクト・シンタックス］ DICOMでは、SOP Classに相当する。（抽象構文） SOP Classとは、保存や検索などのサービスと、それらで使われる値（IOD）を規定したもののことである。いわゆる、DICOMプロトコルの「内部」で使われるコマンドとデータの定義のことである。 SOP Classを1つ以上使って実際に使えるサービス（機能化）したものをService Classという。 Abstract Syntax = DICOM SOP Classの例 CT Image Storage SOP Class CT画像保存SOPクラス MR Image Storage SOP Class MR画像保存SOPクラス Ultrasound Image Storage SOP Class 超音波画像保存SOPクラス ◯◯　Image Storage SOP Class ◯◯画像保存SOPクラス Modality Worklist Information Model – FIND SOP Class モダリティ・ワークリスト情報取得SOP Class DICOM基本用語③ Transfer Syntax　［トランスファー・シンタックス］（転送構文） DICOMで通信するデータの符号化方法の定義。データを送る際には、相手がサポートする符号化方法を用いる必要がある。デフォルト DICOM Transfer Syntax の例 Implicit VR Little Endian 暗黙的VRリトル・エンディアン（非圧縮） Explicit VR Little Endian 明示的VRリトル・エンディアン（非圧縮） Explicit VR Big Endian 明示的VRビッグ・エンディアン（非圧縮） JPEG Lossless JPEG（可逆圧縮） JPEG Lossy JPEG（非可逆圧縮） DICOM基本用語④ Association Negotiation　［アソシエーション・ネゴシエーション］ AE同士が取り交わすDICOM通信の最初のフェーズ。要求するサービスの種別や符号化方法等に関する折衝を Association Negotiation （アソシエーション折衝）、折衝の成立を Association Establishment （アソシエーション確立）という。この折衝の成立によりDICOM通信路が確立され、以降、 AE間でデータのやり取りが可能となる。一連のデータ通信の最後には、 Association Release （アソシエーション解放）により、通信路を解放（通信終了）する。 DICOM通信の流れ Association Negotiation アソシエーション折衝 Association Establishment アソシエーション確立モダリティ AE DICOM Message Data Association Release アソシエーション解放画像サーバ AE Association Negotiation モダリティ私は××と申します。 ○○さんに、 □□のサービスを、 △△か▲▲の書式（符号化）でお願いしたいのですが… ← Calling AE Title ← Called AE Title ← SOP Class ← Transfer Syntax 画像サーバアソシエーション確立要求アソシエーション確立応答 Acceptor Requestor Calling AE Title → Called AE Title → SOP Class → Transfer Syntax → ○○です。 ××さんに、 □□のサービスを提供します。書式は△△でお願いします。交渉成立アソシエーション確立 DICOMの機能 DICOMの機能は、操作の対象となる「情報オブジェクト定義（IOD）」とそれに対するサービスの組み合わせによって定義される。・SCU （Service Class User）　［サービスクラス利用者］ DICOMのサービスを利用する（要求する）側の呼び方。・SCP （Service Class Provider）　［サービスクラス提供者］ DICOMのサービスを提供する側の呼び方。画像を送りますので、保存してください。 SCU 画像を受け取って保存します。 Storage Service Class SCP サービスクラス　Service Class DICOMで提供されるサービスの種別のこと DICOM Service Classの例 Verification Service Class 交信確認 Basic Worklist Management Service Class 基本ワークリスト管理 Study Management Service Class スタディ（検査）管理 Storage Service Class データ保存 Storage Commitment Service Class データ保存委託 Query / Retrieve Service Class データ問合せ／検索（取得） Print Management Service Class プリント出力管理 Verification　−交信確認 DICOM語で話せますか？＝ ※ 装置の据付時やトラブル発生時などの接続確認に用いられることが多い。もしもし、聞こえますか？モダリティ SCU 画像サーバはい。聞こえますよ。＝ DICOM語で話せますよ！ SCP Basic Worklist Management −基本ワークリスト管理 Modality Worklist Management （MWM）本日のCT（※）の予約検査リストをください。 RIS モダリティ SCU 本日、予約されている検査は、 10時00分　◯◯◯◯さん　頭部 10時30分　◯◯◯◯さん　腹部 11時00分　◯◯◯◯さん　胸部：　SCP ※ 種々の条件（ex. 日付、患者ID、モダリティ種別など）で検査リストの検索をかけることが可能。 Study Management −スタディ（検査）管理 Modality Performed Procedure Step （MPPS）モダリティ SCU 検査を開始します。患者氏名　：◯◯◯◯ 撮影部位　：頭部撮影開始時刻：10時00分：検査が終了しました。撮影終了時刻：10時20分撮影条件：　・・・：　了解！ RIS SCP 了解！ Storage　−データ保存画像（※）を送りますので保存してください。モダリティ SCU 画像サーバ画像（※）を受け取りました。保存します。 SCP ※ Storage Service の対象となるデータは画像に限らない。レポートデータ、波形データ等も Storage Service の対象オブジェクトとなる。 Storage Commitment −データ保管委託指定した画像を確実に保管してください。（ローカルディスクから削除したいのです）モダリティ要求を受け付けました。指定された画像を確かにお預かりしました。（確実に保管します） SCU よろしくお願いします。画像サーバ SCP Query/Retrieve −データ問合せ／検索（取得）以下の条件で画像検索してください。患者ID　： P1000392A 検査UID　：1.2.3.456.789 シリーズUID ：1.2.3.456.789.2 画像ビューア／ワークステーション画像サーバはい。検索結果です。画像UID　：1.2.3.456.789.2.1 画像UID　：1.2.3.456.789.2.2 ・・・ SCU では、この画像を送ってください。画像UID　：1.2.3.456.789.2.2 はい。お望みの画像を送ります。 SCP 病院情報システム（HIS） HIS server 患者情報検査オーダ情報放射線情報システム（RIS）検査オーダ情報患者情報検査オーダ情報 MWM Modality 画像情報を WEB配信レポート情報を WEB配信検査実施情報画像管理システム（PACS） Image/Report Viewer RIS端末 Query/ Retrieve （Report） RIS server モダリティ PC端末診療情報 MPPS 検査実施情報 Storage （Image）画像情報画像保存委託画像情報レポート情報 Query/ Retrieve （Image） Storage （Report） Report Server Image Server Storage Commitment 留意すべきこと残念ながら・・・ DICOMは万能ではない。 •  「DICOM対応機器」同士であっても、サポート範囲が異なれば、通信（データ交換）できない。サポート範囲の明確化が必要→コンフォーマンス・ステートメント −「DICOMフルサポート」の機器は存在しない •  DICOMは、システムの運用そのものを規定していない −良く言えば柔軟、悪く言えば曖昧（いわゆるケースばいケース） −「つながる」だけでは運用できない −システムの運用仕様を明確にした上で、「DICOMをどう使うか」が重要 −とはいえ、個々の装置に対する要求仕様を明確にすることは容易ではない。一つの有用なアプローチ IHE OSI参照モデルの7階層物理層ー第1層通信するデータを電気信号に変換して送り出し、伝送し、受信するハードウェア。具体的にはネットワークインタフェースやケーブルのこと。データリンク層ー第2層ネットワーク層から指示されたコンピュータと通信する物理的な経路を確立し、通信中のデータが正しく送られているかチェックし、エラー次はデータを再送する。ネットワーク上の機器を一意に識別するためのMACアドレスが該当する。ネットワーク層ー第3層複雑に組み合わさったネットワークでも相手先のコンピュータにデータを確実に通信を行う働きする。Internet protocolによって実現される。→ IPアドレストランスポート層ー第4層セッション層から渡されたデータを相手に確実に送り届ける層。相手からの応答や伝達確認を行いながら伝送するTCP（transmission control protocol）や確認を省略して高速にデータ転送するUDP（user datagram protocol）などがある。セッション層ー第5層相手のコンピュータとのコネクションを確立させたり、不要になったらコネクションを解放したりする。また、通信量をコントロールし、ネットワーク全体のスループットを向上させる機能を持つ。プレゼンテーション層ー第6層データの変換や加工を行い、ネットワーク通信に使用するデータとユーザが理解できるデータのインタフェースを行う。アプリケーション層ー第7層ネットワークを利用するユーザに色々なサービスを提供する。 MACアドレス（Media Access Control address） MACアドレスは，NIC（Network Interface Card）の ROMに書き込まれている物理アドレスであり，NICごとに固有のアドレスである． MACアドレスの例 00:04:26:B5:FC:24 イーサネットアドレスともよばれ，48ビットで構成される．通常，16進数で表記され，前半の24ビットは，製造メーカに割り振られた番号，後半の24ビットは，そのメーカが個別に管理し割り振ったシリアル番号である． IPアドレス（IPv4）の構造ネットワークでつながったPCを特定するための住所のようなもの【物理的なIPアドレスの範囲】 0.0.0.0 ～ 255.255.255.255 ただし，0と255は使用しない