1. DICOM開発者ガイド
  2. DICOM共通の使用方法およびリファレンス
  3. Oracle Multimedia DICOMの概念

2 Oracle Multimedia DICOMの概念

この章では、Oracle Multimedia DICOMについて概念レベルで説明します。

注:

DICOMのOracle Multimediaサポートは、Oracle Database 12cリリース2 (12.2)では非推奨になりました。将来のリリースではサポートされなくなる可能性があります。できるだけ早く、非推奨となった機能の使用を停止することをお薦めします。

この章では、次の内容を説明します。

2.1 Oracle Multimedia DICOMのアーキテクチャ

Oracle Multimedia DICOMを使用すると、単一フレームおよびマルチフレームの画像、波形図、3D断面図、ビデオ映像、構造化レポートなどのDICOMコンテンツを、Oracle Databaseで保存、管理および検索できます。

Oracle Multimedia DICOMのアーキテクチャは、データベースでのDICOMコンテンツのサポートに使用されるフレームワークを定義します。このDICOMコンテンツは、一般的な言語とツールで作成された複数のアプリケーション間での安全な共有、リレーショナル・データベース管理などテクノロジによる容易な管理、数千人規模のユーザーをサポートするスケーラビリティの高いデータベースでの提供が可能になります。

次の図は、データベースの観点からOracle Multimedia DICOMアーキテクチャを示しています。

図2-1 Oracle Multimedia DICOMのアーキテクチャ

図2-1の説明が続きます
図2-1「Oracle Multimedia DICOMのアーキテクチャ」の説明

Oracle Databaseは、Oracle Multimedia DICOMを使用して、DICOMコンテンツを表に保持します。図に示されているように、表の列に格納されているDICOMコンテンツにはレントゲン、超音波画像、および磁気レゾナンスイメージなどのDICOMデータなどが含まれます。表内の独立した列には、DICOMイメージのJPEGサムネイル・イメージが格納されます。別の列には、各イメージに関連付けられているXMLメタデータ・ドキュメントが格納されます。Java仮想マシン(JVM)内には、サーバー側のDICOMデータ・モデル・リポジトリおよびDICOMパーサー、DICOM XMLエンコーダ、DICOM規格準拠バリデータ、イメージ・プロセッサが存在します。DICOMパーサーは、DICOMコンテンツからメタデータを抽出します。DICOM XMLエンコーダは、データ・モデル・リポジトリで定義されたマッピング・ルールに従って、抽出されたDICOM属性をXMLドキュメントにマップします。DICOM規格準拠のバリデータは、データ・モデル・リポジトリで指定されている制約ルールに従って、DICOMコンテンツの構文およびセマンティクスの一貫性をチェックします。イメージ・プロセッサは、サムネイルサイズの画像作成や、DICOMと他のサポート対象の画像形式間の変換など、画像処理の操作をサポートします。

Oracle Multimedia DICOMのプロシージャおよびメソッドを使用すると、データベースと外部のファイル・ストレージ・システム間でインポート操作およびエクスポート操作を実行できます。Oracle Databaseと外部ファイル・ストレージを結ぶ両方向矢印は、このデータ移動を示します。

関連項目:

2.2 Oracle Multimedia DICOMの記憶域

オブジェクト・インタフェースを使用する場合は、DICOMコンテンツに対してOracle Multimedia DICOM操作を実行する前に、表内にORDDicomオブジェクトを作成する必要があります。Oracle Multimediaでは、DICOMコンテンツを保持するためにJavaまたはC++クラスと同様のORDDicomオブジェクト型を定義します。

図2-2に、ORDDicomオブジェクトの概要を示します。この説明で示す項目を特定するために、図2-2内の項目には番号が付けられています。ORDDicomオブジェクト型(項目1)のインスタンスは、メソッドおよび属性で構成されます。メソッドとは、ORDDicomオブジェクトに対して実行可能なファンクションまたはプロシージャのことで、makeAnonymous( )やsetProperties( )などがあります。属性には次のものがあります。

  • XMLメタデータ・ドキュメント(項目2)として表現される、抽出されたDICOM属性

  • DICOMコンテンツ(項目3)(BLOB(推奨)としてトランザクション制御下でデータベース内に格納されているか、データベースに格納されているポインタとともに、ローカル・ファイル・システム内のオペレーティング・システム固有のファイルに格納されている、形式を変更していない元のDICOMコンテンツ)

  • 頻繁にアクセスされる特定の一般属性(項目4)(アクセスおよび索引付けを容易にする目的で抽出および格納される、SOPクラスのUIDなど)

  • その他の属性(項目5)(Oracle内部での使用を目的としたもの)

図2-2 ORDDicomオブジェクト

図2-2の説明が続きます
図2-2「ORDDicomオブジェクト」の説明

NUMBERデータ型またはBLOBデータ型と同様に、ORDDicomデータ型は表の列のデータ型として使用できます。

図2-3は、ORDDicomオブジェクトが保存される医療用データベース内の単純な表の構造を示します。この説明で示す項目を特定するために、図2-3内の項目には番号が付けられています。項目1は医用画像のデータベースを表します。項目2はデータベースによって管理される単純な医用画像の表を表します。この表には、2つの列:ID(項目3)とイメージ(項目4)が格納されています。項目3はデータベース内の特定のDICOMイメージの識別子を表します。項目4は、データベース内のDICOMコンテンツを表し、これらはORDDicomオブジェクト(項目5)として格納できます。このため、イメージ列の列タイプは、ORDDicomです。

図2-3 医用画像データベースの表

図2-3の説明が続きます
図2-3「医用画像データベースの表」の説明

2.3 モデル駆動型の設計

Oracle Multimedia DICOMは、モデル駆動型ソフトウェア・アーキテクチャを使用して設計されています。したがって、Oracle Multimedia DICOMの実行時の動作はドメイン固有のデータ・モデルによって制御されます。DICOMデータ・モデルは、データ・モデル・リポジトリで管理されるXML文書のコレクションです。DICOMデータ・モデルの管理および修正は、DICOM管理者が実行できます。データ・モデルを構成するXMLドキュメントは、複数のユーザー・セッションがデータ・モデルにアクセスしている実行時に挿入および削除できます。データ・モデルに対する変更は、データベース・トランザクション・セマンティックで保護されており、各ユーザー・セッションは必要に応じて最新のデータ・モデルにリフレッシュできます。

図2-4に、DICOMメタデータ抽出機能を使用するモデル駆動型ソフトウェア・アーキテクチャの原理を示します。点線の上にある項目は、データ・モデルのメタデータ抽出機能に関連する部分です。点線の下にある項目は、メタデータ抽出機能のソフトウェア実行時のコンポーネントで、データ・モデルにアクセスするものです。データ・モデルの項目と実行時のコンポーネントの項目をつなぐ線は、データ・モデル・リポジトリで管理される対応項目が実行時にアクセスされることを表します。

設計時に、DICOM管理者はDICOMデータ・モデルを変更できます。これらの変更をパブリッシュすると、メタデータ抽出機能および他のDICOM操作の実行時の動作に影響を与えます。

図2-4は、データ・モデルの3つのコンポーネントを示します。この説明で示す項目を特定するために、図2-4内の項目には番号が付けられています。項目1は、DICOM標準属性およびプライベート属性の定義を示すDICOMデータ・ディクショナリです。項目2はマッピング・ドキュメントを示し、XMLドキュメントへの属性のマップ方法が記述されています。項目3は、サンプルのDICOM XMLメタデータ・スキーマを表し、ここでDICOM属性の格納に使用されるXMLドキュメントの構造とデータ型が定義されます。項目2と項目3の要素を接続する線は、DICOMコンテンツに格納されているDICOM属性と、XMLスキーマに準拠するXMLドキュメントに格納されているXML要素間のマッピングを示しています。

DICOMコンテンツ(項目4)をXMLメタデータ・ドキュメント(項目8)に変換する処理は、図2-4の下半分に示されています。項目間をつなぐ実線は、実行時のコンポーネント間のデータの流れを示しています。項目5には、サンプルのDICOMコンテンツに含まれる2つの属性が示されています。最初の属性には、属性タグ(0010,0010)、データ型PN、バイト長12および値Joe Smithが含まれています。この属性はDICOMコンテンツ内でエンコーディングされていますが、そのデータ型はDICOMコンテンツでエンコーディングされない場合もあります。パーサー(項目6)では、属性タグ(0010,0010)を使用してDICOMデータ・ディクショナリ(項目1)を参照することにより、属性定義が検索されます。属性定義によってDICOMコンテンツの解釈方法が決まります。その結果はXMLエンコーダ(項目7)に渡されます。同様に、XMLエンコーダでは、データ・モデル(項目2)を参照して属性のXMLエンコーディング・ガイドラインが検索され、そのガイドラインに従ってXML文書が生成されます。最後に、生成された文書のXMLメタデータ・スキーマ(項目3)の検証が、XMLスキーマ・バリデータ(項目9)によって実行されます。

図2-4に示すように、実行時の動作に影響するものは、DICOM管理者が構成可能なデータ・モデルにすべて含まれています。

図2-4 DICOMモデルに基づいた解析の詳細

図2-4の説明が続きます
図2-4「DICOMモデルに基づいた解析の詳細」の説明

2.4 DICOMデータ・モデル・リポジトリ

Oracle Multimedia DICOMの重要な機能は、ユーザーによる構成が可能なドキュメント・セット(データ・モデル)を使用して実行時の動作を決定できる点です。このドキュメント・セットは、データ・モデル・リポジトリでまとめて管理されます。管理者は、データ・モデル・リポジトリを更新して、特定のデータベース・インスタンスのOracle Multimedia DICOMを構成できます。この設計により、DICOMアーカイブを稼働させたまま、Oracle Multimedia DICOMを新しいバージョンのDICOM標準規格にアップグレードしたり、その準拠を検証する新しいルールを追加するなどのタスクをいつでも実行できます。各データベースには専用の構成ドキュメント・セットがあります。各組織や企業では、必要に応じてインストール済の構成ドキュメントをカスタマイズできます。

この項は、次のトピックで構成されています。

2.4.1 リポジトリ内の構成ドキュメント

データ・モデル・リポジトリを構成する構成ドキュメント・セットには、匿名ドキュメント、制約ドキュメント、マッピング・ドキュメント、プリファレンス・ドキュメント、プライベートおよび標準のディクショナリ・ドキュメント、ストアド・タグ・リスト・ドキュメントおよびUID定義ドキュメントが含まれます。各構成ドキュメントにはXMLスキーマ定義が付属します。必要に応じて、その他のドキュメントをリポジトリに追加することもできます。

Oracleには、ソフトウェア・リリースごとにデフォルトの構成ドキュメント・セットが同梱されています。デフォルトのドキュメントに対応するすべてのスキーマは、インストール中に登録されます。すべてのスキーマは固定されたものであるため、データベース・インストールに合わせて変更しないでください。

表2-1に、データ・モデル・リポジトリに含まれるドキュメント・タイプ、ドキュメント・タイプ別のデフォルトXML文書名およびXMLスキーマ定義名を示します。

表2-1 DICOM構成ドキュメントおよび対応するXMLスキーマ

ドキュメント・タイプ デフォルトXMLドキュメント XMLスキーマ定義

匿名

ordcman.xml

ordcman.xsd

制約

ordcmct.xml

ordcmcmd.xml

ordcmcmc.xml

ordcmct.xsd

マッピング

ordcmmp.xml

ordcmmp.xsd

プリファレンス

ordcmpf.xml

ordcmpf.xsd

プライベート・ディクショナリ

ordcmpv.xml

ordcmpv.xsd

標準ディクショナリ

ordcmsd.xml

ordcmsd.xsd

ストアド・タグ・リスト

なし

ordcmstl.xsd

UID定義

ordcmui.xml

ordcmui.xsd

注:

これらのXMLドキュメントの最新バージョンは、<ORACLE_HOME>のord/xmlディレクトリでファイルとして提供されています。これらのXMLスキーマの最新バージョンは、<ORACLE_HOME>のord/xml/xsdディレクトリでファイルとして提供されています。

匿名ドキュメントは、匿名化する一連の属性と、それらの属性の匿名化に必要なアクションを定義するXMLドキュメントです。デフォルトの匿名ドキュメント(ordcman.xml)には、DICOM標準規格のPart 15「Basic Application Level Confidentiality Profile」に定義された属性のサブセットが記述されています。

制約ドキュメントは、DICOM標準規格に従ってDICOMコンテンツの準拠性をチェックするルールのコレクションを定義するXMLドキュメントです。制約ドキュメントでは、DICOMメタデータ・スキーマでは表現できない属性間の関係およびセマンティックの制約を指定します。デフォルトの制約ドキュメント(ordcmct.xml、ordcmcmd.xmlおよびordcmcmc.xml)には、DICOM標準規格のPart 3のサブセットに従って定義された検証ルールのサンプル・セットが記述されています。

マッピング・ドキュメントは、各属性をDICOM XMLメタデータ・ドキュメント内の特定の要素にマップする方法を定義するXMLドキュメントです。このドキュメントによって、DICOMメタデータの抽出後のXML表現の構造が決定されます。デフォルト・マッピングのドキュメント、ordcmmp.xmlは、DICOMコンテンツからXMLへのマッピングを定義し、XMLでエンコードされたすべてのDICOM属性がルート要素<DICOM_OBJECT>に組み込まれたフラット・リストとして示されます。

プリファレンス・ドキュメントは、XMLへのエンコーディング時に削除されるDICOM属性に対するサイズ制限、DICOM関数およびプロシージャで使用されるXMLドキュメントを検証するかどうかなどの、ランタイム・パラメータを定義するXMLドキュメントです。デフォルトのプリファレンス・ドキュメントは、ordcmpf.xmlです。

プライベート・ディクショナリ・ドキュメントはXMLドキュメントであり、これを使用するとユーザーは、メーカー固有または企業固有の属性をDICOMコンテンツに追加して、標準ディクショナリ・ドキュメントの定義を拡張できます。デフォルトのプライベート・ディクショナリ・ドキュメント(ordcmpv.xml)には、Oracleのプライベート属性が定義されています。

標準ディクショナリ・ドキュメントは、DICOM標準規格のパート6で定義されている標準の属性をリストし、DICOM標準規格の更新を反映するために使用できるXMLドキュメントです。デフォルトの標準ディクショナリ・ドキュメントはordcmsd.xmlです。

ストアド・タグ・リスト・ドキュメントはオプションのXML文書であり、setProperties()メソッドが呼び出されたときに、埋込みDICOMコンテンツから抽出し、ORDDicomオブジェクトのXMLメタデータ属性に格納するDICOM属性を指定します。一般に、ストアド・タグ・リスト・ドキュメントは、マッピング・ドキュメントおよび制約ドキュメントで使用される属性タグを含みます。

UID定義ドキュメントは、DICOM標準規格または民間団体によって定義されている一意識別子(UID)がリストされているXMLドキュメントです。UIDはISOオブジェクト識別子(OID)に基づいています。UID定義ドキュメントは、DICOMコンテンツUIDを定義するのではなく、DICOMコンテンツを分類し、標準セマンティクスを表す標準のUIDのレジストリが組み込まれています。デフォルトのUID定義ドキュメント(ordcmui.xml)には、DICOM標準規格のPart 6に定義されているUIDが記述されています。

関連項目:

2.4.2 リポジトリ内の管理者セッションおよびユーザー・セッション

管理者は、データ・モデル・リポジトリのインタフェースを使用して構成ドキュメントを管理できます。

データ・モデル・リポジトリは、Oracle Multimedia DICOMのメソッド、プロシージャまたはファンクションをコールする前にロードする必要があります。リポジトリのロードは、DICOMパッケージ・インタフェースからsetDataModel( )プロシージャを使用して実行します。

図2-5は、Unified Modeling Language(UML)のシーケンス図を使用して、DICOMデータ・モデル・リポジトリのインストール時の状態と更新後の様々な状態を示しています。また、1つのデータ・モデル・リポジトリで処理を行っている2つの管理者セッションと2つのユーザー・セッションも示しています。図2-5の番号付きの項目は、データ・モデル・リポジトリの各種コンポーネント、またはデータ・モデル・リポジトリ上で実行される操作を表します。次に示す番号付きの項目は、図2-5の番号付き項目にそれぞれ対応しています。

データ・モデルの状態:

項目10の列にあるすべてのボックスは、データ・モデル・リポジトリの次の状態を表します。

  • 状態0: インストール時のバージョン。

  • 状態1: 管理者セッション1の編集セッションXG1からの更新を含むバージョン。

  • 状態2: 管理者セッション1の編集セッションXG1、および管理者セッション2の編集セッションXG2からの更新を含むバージョン。

  • 状態3: 管理者セッション1の編集セッションXG1およびXG3からの更新と、管理者セッション2の編集セッションXG2からの更新を含むバージョン。

管理者セッション:

  • 項目1: この列にあるボックスはすべて、管理者セッション1によって実行されるタスクを表しています。

  • 項目6: この列にあるボックスはすべて、管理者セッション2によって実行されるタスクを表しています。

  • 項目2: 管理者セッション1が、editDataModel( )プロシージャをコールして編集セッションXG1を開始します。これによりインストール時のバージョンのデータ・モデル(状態0)はロックされ、他の管理者は、そのデータ・モデルを編集できなくなります。この間、ユーザーが参照できるのはインストール時のバージョンのデータ・モデル(状態0)のみです。管理者セッション1がデータ・モデルを編集します。

  • 項目3: 管理者セッション1が、編集セッションXG1を完了して、publishDataModel( )プロシージャをコールし、変更をデータ・モデルに公開します。データ・モデルは状態1に更新され、ロックが解除されます。これで、他の管理者がデータ・モデルを編集するためにロックできるようになります。また、他のユーザーは、setDataModel( )プロシージャをコールして更新済のデータ・モデルを参照できるようになります。

  • 項目7: 管理者セッション2が、editDataModel( )プロシージャをコールして編集セッションXG2を開始します。これによりデータ・モデル(状態1)はロックされ、他の管理者は、そのデータ・モデルを編集できなくなります。この間、ユーザーは状態1のデータ・モデルを参照できます。管理者セッション2がデータ・モデルを編集します。

  • 項目8: 管理者セッション2が、編集セッションXG2を完了して、publishDataModel( )プロシージャをコールし、データ・モデルへの変更を公開します。データ・モデルは状態2に更新され、ロックが解除されます。

  • 項目4: 管理者セッション1が、editDataModel( )プロシージャをコールして編集セッションXG3を開始します。これによりデータ・モデル(状態2)はロックされ、他の管理者は、そのデータ・モデルを編集できなくなります。この間、ユーザーは状態2のデータ・モデルを参照できます。管理者セッション1がデータ・モデルを編集します。

  • 項目9: 管理者セッション2が、editDataModel( )プロシージャをコールして編集セッションXG4を開始します。管理者セッション1によってデータ・モデルがロックされているため、管理者セッション2はロックを取得できず、editDataModel( )プロシージャのコールは失敗します。

  • 項目5: 管理者セッション1が、編集セッションXG3を完了して、publishDataModel( )プロシージャをコールし、データ・モデルへの変更を公開します。データ・モデルは状態3に更新され、ロックが解除されます。

ユーザー・セッション:

  • 項目11: この列にあるボックスはすべて、ユーザー・セッション1によって実行されるタスクを表しています。

  • 項目15: この列にあるボックスはすべて、ユーザー・セッション2によって実行されるタスクを表しています。

  • 項目12: ユーザー・セッション1が、setDataModel( )プロシージャをコールしてデータ・モデルをロードします。まだ管理者セッション1は編集セッションXG1の変更をパブリッシュしていないため、データ・モデルはインストール時のバージョン(状態0)のままです。

  • 項目16: ユーザー・セッション2が、setDataModel( )プロシージャをコールしてデータ・モデルをロードします。データ・モデルは状態1になっており、パブリッシュ済の編集セッションXG1の変更が反映されています。

  • 項目13: ユーザー・セッション1が、再度、setDataModel( )プロシージャをコールします。データ・モデルは状態1になっており、パブリッシュ済の編集セッションXG1の変更が反映されています。

  • 項目17: ユーザー・セッション2が、再度、setDataModel( )プロシージャをコールします。まだ管理者セッション2が編集セッションXG1の変更をパブリッシュしていないため、データ・モデルは状態1のままです。

  • 項目14: ユーザー・セッション1が、再度、setDataModel( )プロシージャをコールします。データ・モデルは状態2になっており、編集セッションXG1およびXG2のパブリッシュ済の変更が反映されています。

  • 項目18: ユーザー・セッション2が、再度、setDataModel( )プロシージャをコールします。データ・モデルは状態3になっており、編集セッションXG1、XG2およびXG3のパブリッシュ済の変更が反映されています。

図2-5 DICOMデータ・モデル・リポジトリ

図2-5の説明が続きます
図2-5「DICOMデータ・モデル・リポジトリ」の説明

図2-5に示すように、setDataModel( )プロシージャはユーザー・セッション中にコールされます。アプリケーションは各データベース・セッションの初めにこのプロシージャをコールして、リポジトリをデータベースからメモリー構造内にロードする必要があります。また、このプロシージャは、アプリケーションでデータ・モデルの新しい変更が必要な場合にいつでもコールできます。ユーザーは、ORD_DICOMパッケージ・インタフェースに含まれるDICOMデータ・モデル・ユーティリティを介して、このプロシージャを使用できます。

データ・モデル・リポジトリ管理インタフェースの詳細は、「ORD_DICOM_ADMINパッケージのリファレンス」を参照してください。ORD_DICOMパッケージ・インタフェースのDICOMデータ・モデル・ユーティリティの詳細は、「DICOMデータ・モデル・ユーティリティ・リファレンス」を参照してください。

2.4.3 CDBのDICOMデータ・モデル・リポジトリ

マルチテナント・コンテナ・データベース(CDB)には、各プラガブル・データベース(PDB)に固有の個別DICOMデータ・モデルがあります。メタデータは同じですが、DICOMデータ・モデル内のデータは大きく異なる場合があります。特定のPDB内のユーザー・ドキュメントは、CDB内の他のPDBには表示されません。

関連項目:

2.5 DICOMコンテンツからのメタデータの抽出

DICOMコンテンツからメタデータを抽出する操作には、XMLメタデータ・スキーマおよびマッピング・ドキュメントを使用するいくつかの操作が含まれます。

DICOMメタデータ・ドキュメントは、DICOMコンテンツから抽出されたメタデータを含むXML文書です。オプションで、XMLスキーマを使用して各メタデータ・ドキュメントに制約を付けることができます。各XMLメタデータ・スキーマには、対応するXMLマッピング・ドキュメントがあります。

DICOMコンテンツとDICOMメタデータ・ドキュメントのマッピングは、マッピング・ドキュメントで定義します。マッピング・ドキュメントでは、DICOMコンテンツの属性をスキーマ準拠のXMLドキュメントにマップする方法が定義されます。他の構成ドキュメントと同様に、マッピング・ドキュメントはDICOMデータ・モデル・リポジトリによって管理されます(「DICOMデータ・モデル・リポジトリ」を参照)。

Oracleには、デフォルトのXMLメタデータ・スキーマ(ordcmmd.xsd)と、対応するXMLマッピング・ドキュメント(ordcmmp.xml)が用意されています。アプリケーションの設計者が独自のメタデータ・スキーマを作成する場合は、スキーマ定義とマッピング・ドキュメントに互換性を持たせる必要があります。また、作成したデータ型定義は、Oracleデータ型定義(ordcmmddt.xsd)との互換性を持つことも必要です。

次の各項では、これらの主要な抽出およびマッピングの概念について説明します。

2.5.1 メタデータ抽出およびXMLマッピング・プロセスの概要

図2-6に、メタデータの抽出およびXMLマッピングの処理の対象となるコンポーネントを示します。 図2-6の各番号付き項目は、この処理で使用されるコンポーネントを表します。

図2-6 DICOMメタデータの抽出とXMLマッピング

図2-6の説明が続きます
図2-6「DICOMメタデータの抽出とXMLマッピング」の説明

入力は、バイナリ形式のDICOMコンテンツ(項目1)で、ORDDicomオブジェクト内、またはBLOBまたはBFILEに直接、格納できます。出力はXMLメタデータ・ドキュメント(項目7と8)です。メタデータ・ドキュメントのレイアウトは、マッピング・ドキュメント(項目3)によって指定されます。メタデータ抽出では、出力メタデータ・ドキュメントに含める属性のグループを指定するマッピング・オプション・パラメータが使用されます。実線の接続項目(項目4、5および6)は、DICOMコンテンツからXMLメタデータ・ドキュメントへのデータのフローを示しています。項目3は、マッピング・ドキュメントの仕様に従ってメタデータ抽出を実行する処理エンジンとして解釈することもできます。

DICOMコンテンツ(項目1)には、DICOMデータ要素(項目2)がバイナリ・コードでエンコーディングされています。実行時に、DICOMコンテンツのバイナリ・ストリームがパーサーによって読み取られ、メモリー内にDICOMデータ要素(項目2)の表現が構築されます。各DICOM属性のメモリー内表現をXML要素にマップするために、データ・モデル・リポジトリに格納されたマッピング・ドキュメント(項目3)内の属性定義がXMLエンコーダによって参照されます。

たとえば、このマッピング・ドキュメントの最初のエントリでは、DICOM属性Patient's Name (0010,0010)がXMLパス/DICOM/Patient/Nameにマップされます。このパスの、NameはPatient要素のサブ要素であり、Patientはドキュメント・ルート要素DICOMの子要素です。

DICOMデータ要素に含まれる属性で、そのXMLパスがマッピング・ドキュメントに明示的に定義されているものはマップ済属性と呼ばれます。DICOMデータ要素に含まれる属性で、そのXMLパスがマッピング・ドキュメントに明示的に定義されていないものはアンマップ属性と呼ばれます。

マッピング・ドキュメントに基づき、各DICOMメタデータ・ドキュメントには、マップ済セクションとオプションのアンマップ・セクションの2つのセクションが含まれる可能性があります。マップ済セクション(項目7)では、属性は事前定義された階層に従って編成されます。マップ済セクション内の属性は、固定のXPath問合せでアドレッシングできます。アンマップ・セクション(項目8)では、属性が属性タグによってソートされ、値表現を使用してリストされます。アンマップ・セクションにある属性は、次の書式の要素タグを使用するXPath問合せでアドレッシングできます。

/DICOM/Other/VR_TYPE(tag=='HHHHHHHH')

この問合せのHHHHHHHHは16進の属性タグで、/DICOM/Otherはアンマップ・セクションに指定されたパスです。独自のマッピング・ドキュメントを作成する方法の詳細は、「マッピング・ドキュメントおよびメタデータXMLスキーマの作成について」を参照してください。

メタデータ抽出機能のマッピング・オプションでは、出力するXMLメタデータ・ドキュメントに含める属性グループを指定します。マッピング・オプションは、mapped(マップ済)、standard(標準)、all(すべて)の3つです。

抽出オプションがmapped(項目4)の場合は、マップ済属性のみがXMLメタデータ・ドキュメントに組み込まれます。メタデータ・ドキュメントを使用するアプリケーションで必要となる属性セットが確定している場合は、このオプションが有効です。結果のメタデータ・ドキュメント(項目7)は、明確なツリー構造になります。

抽出オプションがstandard(項目5)の場合は、DICOM標準規格で定義されているすべてのマップ済属性とアンマップ属性がXMLメタデータ・ドキュメントに抽出されます。マッピングが定義されていないプライベート属性は、出力から除外されます。このオプションは、フルテキスト検索を実行するアプリケーションなどで、DICOMコンテンツに含まれるすべての標準属性を使用できる場合に有益です。

抽出オプションがall(項目6)の場合は、DICOMコンテンツに含まれるすべての属性が抽出され、XMLメタデータ・ドキュメントにエンコーディングされます。このオプションを使用すると、すべてのDICOM属性をバイナリからXMLにマッピングできます。

注:

ユーザー指定の制限を超えるバイナリ長の属性は、XMLメタデータ・ドキュメントに含まれません。プリファレンス・ドキュメント内でこれらの制限を指定する方法の詳細は、「プリファレンス・ドキュメントの作成について」を参照してください。

マッピング・オプションがallまたはstandardの場合は、DICOMデータ要素のアンマップ属性がXML要素Other (項目8)に格納されます。結果のXML文書は、データベースの表に格納して索引付けし、キーワードまたはXPath問合せ文を使用して問い合せることができます。マップ済およびアンマップのセクションの代替マッピング構造と要素名を定義する際は、「マッピング・ドキュメントおよびメタデータXMLスキーマの作成について」を参照してください。

2.5.2 抽出およびマッピング・プロセスで使用されるサンプルXMLドキュメント

XMLマッピング・ドキュメントを使用してマップ済メタデータを抽出して、XMLメタデータ・ドキュメントを生成できます。例2-1に、XMLマッピング・ドキュメントの例(sample_map.xml)を示します。

例2-1では、DICOM属性タグ(0002,0002)を持つDICOM標準属性SOP_CLASS_UIDが、XMLツリーの場所/DICOM_OBJECT/KEY_ATTRIBUTES/のXMLメタデータ要素MEDIA_STORAGE_SOP_CLASS_UIDにマップされます。同様に、DICOM標準属性SOP_INSTANCE_UID(0002,0003)は、XMLメタデータ要素MEDIA_STORAGE_SOP_INSTANCE_UIDにマップされます。DICOM標準属性の検査日(0008,0020)は、このXMLマッピング・ドキュメントに記述されていません。したがって、DICOMコンテンツに検査日が含まれている場合は、XMLツリーの下でDICOMメタデータ・ドキュメントのアンマップ・セクション(/DICOM_OBJECT/OTHER_ATTRIBUTES)に表示されます。

例2-2は、例2-1に示すXMLマッピング・ドキュメントを使用してマップ済メタデータを抽出した場合に、生成される可能性のあるXMLメタデータ・ドキュメントの例を示しています。

例2-1 XMLマッピング・ドキュメントの例

<?xml version="1.0" encoding="UTF-8"?>
<XML_MAPPING_DOCUMENT xmlns="http://xmlns.oracle.com/ord/dicom/mapping_1_0"
 xmlns:dt="http://xmlns.oracle.com/ord/dicom/datatype_1_0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://xmlns.oracle.com/ord/dicom/mapping_1_0
 http://xmlns.oracle.com/ord/dicom/mapping_1_0">
  <DOCUMENT_HEADER>
    <dt:DOCUMENT_CHANGE_LOG>
      <dt:DOCUMENT_MODIFIER>Developer</dt:DOCUMENT_MODIFIER>
      <dt:DOCUMENT_MODIFICATION_DATE>2006-01-13</dt:DOCUMENT_MODIFICATION_DATE>
      <dt:DOCUMENT_VERSION>0.0</dt:DOCUMENT_VERSION>
      <dt:MODIFICATION_COMMENT>Sample mapping document for metadata schema definition
1</dt:MODIFICATION_COMMENT>
    </dt:DOCUMENT_CHANGE_LOG>
  </DOCUMENT_HEADER>
 
  <NAMESPACE>http://xmlns.oracle.com/ord/dicom/metatest1</NAMESPACE>
  <ROOT_ELEM_TAG>DICOM_OBJECT</ROOT_ELEM_TAG>
  <UNMAPPED_ELEM>OTHER_ATTRIBUTES</UNMAPPED_ELEM>
  <MAPPED_ELEM>KEY_ATTRIBUTES</MAPPED_ELEM>
 
  <MAPPED_PATH occurs="true" notEmpty="true" writeTag="true" writeDefiner="true" 
    writeName="true" writeRawValue="true">
    <ATTRIBUTE_TAG>00020002</ATTRIBUTE_TAG>
    <PATH>MEDIA_STORAGE_SOP_CLASS_UID</PATH>
  </MAPPED_PATH>
 
  <MAPPED_PATH occurs="true" notEmpty="true">
    <ATTRIBUTE_TAG>00020003</ATTRIBUTE_TAG>
    <PATH>MEDIA_STORAGE_SOP_INSTANCE_UID</PATH>
  </MAPPED_PATH>
 
  <MAPPED_PATH writeTag="true" writeDefiner="true" writeName="true" writeRawValue="true">
    <ATTRIBUTE_TAG>00100010</ATTRIBUTE_TAG>
    <PATH>PATIENT_NAME</PATH>
  </MAPPED_PATH>
 
</XML_MAPPING_DOCUMENT>

例2-2 XMLメタデータ・ドキュメントの例

<?xml version="1.0" encoding="DEC-MCS"?>
<DICOM_OBJECT xmlns="http://xmlns.oracle.com/ord/dicom/metatest1"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://xmlns.oracle.com/ord/dicom/metatest1
 http://xmlns.oracle.com/ord/dicom/metatest1">
 
  <KEY_ATTRIBUTES>
 
    <MEDIA_STORAGE_SOP_CLASS_UID definer="DICOM" tag="00020002" 
     name="Media Storage SOP Class UID">1.2.840.10008.5.1.4.1.1.1</MEDIA_STORAGE_SOP_CLASS_UID>
 
    <MEDIA_STORAGE_SOP_INSTANCE_UID tag="00020003" definer="DICOM" 
     name="media storage SOP instance UID">1.3.6.1.4.1.5962.1.1.10.1.2.20040119072730.12322
    </MEDIA_STORAGE_SOP_INSTANCE_UID>
 
    <PATIENT_NAME definer="DICOM" tag="00100010" name="Patient&apos;s Name">
 
      <NAME type="unibyte">
 
        <FAMILY>CompressedSamples</FAMILY>
 
        <GIVEN>RG2</GIVEN>
 
      </NAME>
 
      <VALUE>CompressedSampleŝRG2</VALUE>
 
    </PATIENT_NAME>
 
  </KEY_ATTRIBUTES>
 
</DICOM_OBJECT>

2.6 DICOMコンテンツの検証

DICOMコンテンツの検証には、指定した制約ルール・セットにデータが準拠しているかどうかの確認が含まれます。

中間層またはアプリケーション層ではなく、データベースへの準拠検証の実装には、いくつかのメリットがあります。最初に、DICOMコンテンツを検証すると、データベースではあらゆるソースからのDICOMコンテンツを受け入れ、そのコンテンツの整合性の確認を実現できるため、アーカイブ済のDICOMコンテンツの整合性と一貫性を保証できます。この機能を使用すると、データベースは、様々なDICOMコンテンツを接続すると同時にエンタープライズ・データ制約ルールを適用することで、一元的なデータ・ストアとして機能できます。大規模な組織または行政当局の機関は、DICOM標準規格のルール・セットの制約性をある程度調整して、独自のルール・セットを設定して、それらの制約ルールへの準拠を強制できます。ライフ・サイエンスなどの新しい領域では、DICOM標準規格が開発途中ですが、制約ルールはDICOMコンテンツの規約に応じた表現を強制的に適用するための過渡的な手段として利用でき、将来のDICOM規格への移行を簡素化できます。最後に、データベース・システム全体を準拠させることで、企業(アプリケーション)の統合とデータ・マイニングを大幅に簡略化できます。

DICOM制約ドキュメントでは、DICOM標準規格または特定の組織や企業のガイドラインに従って、DICOMコンテンツの準拠性をチェックする1つ以上の制約ルールを定義します。例2-3は、制約ドキュメントの例(sample_ct.xml)を示しています。

リポジトリに制約ドキュメントを挿入すると、ユーザーは制約ドキュメント内に定義されたグローバル制約ルールに対してDICOMコンテンツを検証できます。(グローバル制約ルールは<GLOBAL_RULE>タグを使用して定義します。)たとえば例2-3に示すように、ユーザーはfindJoeSmithという名前のグローバル制約ルールにDICOMコンテンツが準拠しているかをチェックできます。

例2-3 制約ドキュメントの例

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright (c) 2007, Oracle. All rights reserved.
  NAME
  sample_ct.xml - Oracle Multimedia DICOM sample constraint document
-->
 
<CONFORMANCE_CONSTRAINT_DEFINITION xmlns="http://xmlns.oracle.com/ord/dicom/constraint_1_0"
 xmlns:dt="http://xmlns.oracle.com/ord/dicom/datatype_1_0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://xmlns.oracle.com/ord/dicom/constraint_1_0
 http://xmlns.oracle.com/ord/dicom/constraint_1_0">

     <GLOBAL_RULE name="findJoeSmith">
        <PREDICATE>
            <DESCRIPTION>An example to find an object that has (patientName="Joe Smith" 
              AND patientSex=="M")</DESCRIPTION>
            <LOGICAL operator="and">
                <PREDICATE>
                    <RELATIONAL operator="eq">
                        <ATTRIBUTE_TAG>00100010</ATTRIBUTE_TAG>
                        <XML_VALUE>
                            <dt:PERSON_NAME>
                                <dt:NAME>
                                    <dt:FAMILY>Smith</dt:FAMILY>
                                    <dt:GIVEN>Joe</dt:GIVEN>
                                </dt:NAME>
                            </dt:PERSON_NAME>
                        </XML_VALUE>
                    </RELATIONAL>
                </PREDICATE>
                <PREDICATE>
                    <RELATIONAL operator="eq">
                        <ATTRIBUTE_TAG>00100040</ATTRIBUTE_TAG>
                        <XML_VALUE>
                            <dt:CODE_STRING>M</dt:CODE_STRING>
                        </XML_VALUE>
                    </RELATIONAL>
                </PREDICATE>
            </LOGICAL>
        </PREDICATE>
        <ACTION action="log" when="true">Found Joe Smith</ACTION>
     </GLOBAL_RULE>
</CONFORMANCE_CONSTRAINT_DEFINITION>

2.7 画像変換と新しいDICOMコンテンツの作成

ORDDicomオブジェクトは、加工したり他の画像形式に変換することができます。また、既存のORDDicomオブジェクトから新しいORDDicomオブジェクトを作成することもできます。図2-7に、これらの操作を示します。

図2-7 画像変換処理

図2-7の説明が続きます
図2-7「画像変換処理」の説明

次に、図2-7とその各コンポーネントについて説明します。次の説明で使用している番号付きの項目は、図2-7の番号付き項目に対応しています。図2-7内の項目をつなぐ実線は、データの流れる方向を表します。

画像コンバータ(項目2)では、DICOMコンテンツ(具体的にはDICOM画像)(項目1)および処理コマンド(項目3)を取得し、Webブラウザやアプリケーションで表示できるように、Oracle Multimediaでサポートされている別の形式(JPEGまたはGIF形式など)の画像(項目4)にDICOMコンテンツを変換できます。

この処理は逆方向にも実行できます。JPEGファイル、TIFFファイル、またはサポート対象の他の画像ファイル(項目4)が格納されたORDImageオブジェクトなどのイメージとDICOMメタデータ・ドキュメント(項目5)を使用して、画像コンバータで2つの項目をマージして、新しいORDDicomオブジェクト(項目1)の作成に使用可能なDICOMコンテンツを生成できます。同様に、画像コンバータ(項目2)では、DICOMコンテンツ(項目4)とXMLメタデータ・ドキュメント(項目5)をコピーして新しいORDDicomオブジェクト(項目1)に変換できます。このタイプの処理が一般的に使用されるのは、ディスク領域を節約するために変換済の画像に対して可逆圧縮を行う場合や、クロス・プラットフォームの画像交換ができるように異なるタイプの転送構文に変換する場合、メタデータを更新する場合などです。

処理中、埋込み画像には1つ以上のフレームを含めることができます。画像コンバータでは、フレームに対する処理コマンドに応じて、画像に含まれる1つまたはすべてのフレームのピクセル・コンテンツを読み取ることができます。埋め込まれたDICOM画像がGIFまたはJPEGなどの形式でORDImageオブジェクトまたはBLOBに書き込まれると、変換後のイメージをWebで表示できます。

さらに、MRI、CT、超音波ビデオなど、マルチフレームのDICOM画像を処理して、Windows Audio Video Interleave (AVI)形式のMicrosoftビデオに変換できます。これらの詳細、および他のDICOM処理操作の詳細は、「DICOM開発の概要」および「DICOMの処理およびサポートされている形式」を参照してください。

2.8 DICOMコンテンツの匿名化

米国の医療保険の相互運用性と説明責任に関する法令(HIPAA)などの政府規制では、患者に関する個人データの保護が義務付けられています。外部リソースとDICOMコンテンツを共有する際は、多くの場合、患者の個人データを匿名化することが要求されます。データベース内でDICOMコンテンツを匿名化することにより、患者の個人データがデータベースの外部に露出することを防ぎ、この情報の保護を簡略化できます。

DICOMコンテンツを匿名化するプロセスは、データ・モデル・リポジトリを使用してカスタマイズできます。ユーザーは、XML内で複数の匿名ドキュメントを作成できます。各匿名ドキュメントでは、匿名化する一連の属性と、それらの属性を匿名化するために実行されるアクションのタイプがリストされます。サポートされるアクションは、removeとreplaceです。removeアクションはデフォルトのアクションで、属性を削除するか、DICOMコンテンツおよびORDDicomオブジェクト属性で属性の長さをゼロに設定します。replaceアクションは属性を文字列に置換します。この文字列は、空にするか、またはDICOMコンテンツおよびORDDicomオブジェクト属性内のユーザー定義文字列を含めることができます。例2-4は、匿名ドキュメントの例を示しています。

関連項目:

米国のHIPAA規制の詳細は、http://www.hhs.gov/ocr/privacy/index.htmlを参照してください。

例2-4 匿名ドキュメントの例

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright (c) 2006, 2007, Oracle. All rights reserved.  -->
<ANONYMITY_RULE_DOCUMENT xmlns="http://xmlns.oracle.com/ord/dicom/anonymity_1_0"
 xmlns:dt="http://xmlns.oracle.com/ord/dicom/datatype_1_0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://xmlns.oracle.com/ord/dicom/anonymity_1_0
 http://xmlns.oracle.com/ord/dicom/anonymity_1_0">
 <DOCUMENT_HEADER>
  <dt:DOCUMENT_CHANGE_LOG>
   <dt:DOCUMENT_MODIFIER>Developer</dt:DOCUMENT_MODIFIER>
   <dt:DOCUMENT_MODIFICATION_DATE>2006-02-06</dt:DOCUMENT_MODIFICATION_DATE>
   <dt:DOCUMENT_VERSION>0.1</dt:DOCUMENT_VERSION>
   <dt:MODIFICATION_COMMENT>Sample anonymity document</dt:MODIFICATION_COMMENT>
   <dt:BASE_DOCUMENT>Test Document</dt:BASE_DOCUMENT>
   <dt:BASE_DOCUMENT_RELEASE_DATE>2004-01-01</dt:BASE_DOCUMENT_RELEASE_DATE>
   <dt:BASE_DOCUMENT_DESCRIPTION>Same as ordcman.xml from label 070321</dt:BASE_DOCUMENT_DESCRIPTION>
  </dt:DOCUMENT_CHANGE_LOG>
 </DOCUMENT_HEADER>
 <PRIVATE_ATTRIBUTES action="remove"></PRIVATE_ATTRIBUTES>
 <UNDEFINED_STANDARD_ATTRIBUTES action="remove"></UNDEFINED_STANDARD_ATTRIBUTES>
 <UNDEFINED_PRIVATE_ATTRIBUTES action="remove"></UNDEFINED_PRIVATE_ATTRIBUTES>
 <INDIVIDUAL_ATTRIBUTE>
  <ATTRIBUTE_TAG>00100010</ATTRIBUTE_TAG>
  <DESCRIPTION>Patient Name</DESCRIPTION>
  <ANONYMITY_ACTION action="replace">SmitĥJoe</ANONYMITY_ACTION>
 </INDIVIDUAL_ATTRIBUTE>
 <INDIVIDUAL_ATTRIBUTE>
  <ATTRIBUTE_TAG>00100020</ATTRIBUTE_TAG>
  <DESCRIPTION>Patient ID</DESCRIPTION>
  <ANONYMITY_ACTION action="replace">madeAnonymous</ANONYMITY_ACTION>
 </INDIVIDUAL_ATTRIBUTE>
 <INDIVIDUAL_ATTRIBUTE>
  <ATTRIBUTE_TAG>00100030</ATTRIBUTE_TAG>
  <DESCRIPTION>Patient Birth Date</DESCRIPTION>
  <ANONYMITY_ACTION action="remove"></ANONYMITY_ACTION>
 </INDIVIDUAL_ATTRIBUTE>
</ANONYMITY_RULE_DOCUMENT>