| Oracle Multimedia DICOM開発者ガイド 11g リリース1（11.1） E05685-01 |
|
 戻る |
 次へ |
この章では、Oracle Multimedia DICOMについて概念レベルで説明します。
この章は、次の項で構成されています。
DICOMアプリケーションの開発に固有の情報は、第II部「DICOMの開発」を参照してください。
DICOMデータ・モデル・リポジトリの管理の詳細は、第III部「DICOMの管理」を参照してください。
Oracle Multimedia DICOMを使用すると、単一フレームおよび複数フレームの画像、波形図、3D断面図、ビデオ映像、構造化レポートなどのDICOMコンテンツを、Oracle Databaseで保存、管理および検索できます。
データベースでDICOMコンテンツをサポートするためのフレームワーク（図2-1を参照）は、Oracle Multimedia DICOMのアーキテクチャで定義されます。 これにより、一般的な言語およびツールで記述された複数のアプリケーション間でDICOMコンテンツを安全に共有できます。また、リレーショナル・データベース管理および管理テクノロジによって簡単に管理し、数千のユーザーをサポートするスケーラブルなデータベースで利用できます。
図2-1に、データベース層（Oracle Database）およびクライアント層（Thickクライアント）の2層の観点からOracle Multimedia DICOMアーキテクチャを示します。
データベース層では、Oracle Multimedia DICOMを使用して、DICOMコンテンツがOracle Databaseの表に保持されます。 図に示すとおり、表の列に格納されたDICOMコンテンツには、X線画像、超音波画像、磁気共鳴画像などのDICOMデータを含めることができます。 表の個別の列には、DICOM画像のJPEGサムネイル画像が格納されます。 別の列には、各画像に関連付けられたXMLメタデータ・ドキュメントが格納されます。 Java仮想マシン（JVM）内には、サーバー側のDICOMデータ・モデル・リポジトリの他に、DICOMパーサー、DICOM XMLエンコーダ、DICOM準拠バリデータおよび画像プロセッサがあります。 DICOMパーサーは、DICOMコンテンツからメタデータを抽出します。 DICOM XMLエンコーダは、データ・モデル・リポジトリに定義されたマッピング・ルールに従って、抽出されたDICOM属性をXML文書にマッピングします。 DICOM準拠バリデータは、DICOMコンテンツの構文およびセマンティックの一貫性を、データ・モデル・リポジトリに指定された制約ルールに照らしてチェックします。 画像プロセッサには、Java Advanced Imaging（JAI）が含まれており、サムネイルサイズの画像生成や、DICOMと他のサポートされている画像形式間における変換などの操作で画像処理を行います。 Oracle Multimedia DICOMメソッドを使用すると、データベースと外部のファイル記憶域システム間のインポートおよびエクスポートが可能です。 このタイプのデータ通信は、図2-1に、Oracle Databaseと外部のファイル記憶域をつなぐ双方向の矢印で示されています。ThickクライアントからはJDBCコールを介してOracle Databaseに格納されたコンテンツにアクセスでき、画像処理などのプロシージャをデータベースの外側で実行できます。 Oracle Databaseと通信するOCIコール・インタフェースなどの他の方法を使用しても、Oracle Databaseに格納されたDICOMコンテンツにアクセスできます。 このようなタイプのデータ・アクセスを使用して、Oracle Databaseとサード・パーティのメディア・プロセッサを統合することもできます。
JAIの詳細は、次のURLでSun社のJavaに関するWebサイトを参照してください。
クライアント層では、データベースのORDDicomオブジェクトにアクセスするために、Oracle Multimedia DICOM Java APIを使用する方法がサポートされています。 Oracle Multimedia DICOM Java APIにより、JavaアプリケーションからORDDicomオブジェクトに直接アクセスできます。
JavaでOracle Multimedia DICOMを使用する方法の詳細は、『Oracle Multimedia DICOM Java API Reference』を参照してください。
Oracle Multimedia全体のアーキテクチャは、『Oracle Multimediaユーザーズ・ガイド』の図1-1を参照してください。
オブジェクト・インタフェースを使用する場合は、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内部での使用を目的としたもの）
NUMBERデータ型またはBLOBデータ型と同様に、ORDDicomデータ型は表の列のデータ型として使用できます。
図2-3に、ORDDicomオブジェクトを格納する医用データベースの簡単な表の構造を示します。 説明で示す項目を特定するために、図2-3内の項目には番号が付けられています。 項目1は、医用画像データベースです。 項目2は、このデータベースで管理される医用画像の簡単な表です。 この表には、ID（項目3）および画像（項目4）の2つの列があります。 項目3は、データベース内の特定のDICOM画像を示す識別子です。 項目4は、データベース内のDICOMコンテンツです。これは、ORDDicomオブジェクト（項目5）として格納できます。 そのため、Image列の型はORDDicomになります。
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管理者が構成可能なデータ・モデルにすべて含まれています。
Oracle Multimedia DICOMの重要な機能は、ユーザーによる構成が可能なドキュメント・セット（データ・モデル）を使用して実行時の動作を決定できる点です。 このドキュメント・セットは、データ・モデル・リポジトリでまとめて管理されます。 管理者は、データ・モデル・リポジトリを更新して、特定のデータベース・インスタンスのOracle Multimedia DICOMを構成できます。 この設計により、DICOMアーカイブを稼働させたまま、Oracle Multimedia DICOMを新しいバージョンのDICOM標準規格にアップグレードしたり、その準拠を検証する新しいルールを追加するなどのタスクをいつでも実行できます。 各データベースには専用の構成ドキュメント・セットがあります。 各組織や企業では、必要に応じてインストール済の構成ドキュメントをカスタマイズできます。
データ・モデル・リポジトリを構成する構成ドキュメント・セットには、匿名ドキュメント、制約ドキュメント、マッピング・ドキュメント、プリファレンス・ドキュメント、プライベートおよび標準ディクショナリ・ドキュメントおよびUID定義ドキュメントが含まれます。 各構成ドキュメントにはXMLスキーマ定義が付属します。 必要に応じて、その他のドキュメントをリポジトリに追加することもできます。
Oracleには、ソフトウェア・リリースごとにデフォルトの構成ドキュメント・セットが同梱されています。 デフォルトのドキュメントに対応するすべてのスキーマは、インストール中に登録されます。 すべてのスキーマは固定されたものであるため、データベース・インストールに合わせて変更しないでください。
表2-1に、データ・モデル・リポジトリに含まれるドキュメント・タイプ、ドキュメント・タイプ別のデフォルトXML文書名およびXMLスキーマ定義名を示します。
表2-1 構成ドキュメントおよび対応するXMLスキーマ
| ドキュメント・タイプ | デフォルトXML文書 | XMLスキーマ定義 |
|---|---|---|
|
匿名 |
|
|
|
制約 |
|
|
|
マッピング |
|
|
|
プリファレンス |
|
|
|
プライベート・ディクショナリ |
|
|
|
標準ディクショナリ |
|
|
|
UID定義 |
|
|
匿名ドキュメントは、匿名化する一連の属性と、それらの属性を匿名化するために実行するアクションを指定するXML文書です。 デフォルトの匿名ドキュメント（ordcman.xml）には、DICOM標準規格のPart 15「Basic Application Level Confidentiality Profile」に定義された属性のサブセットが記述されています。
制約ドキュメントは、DICOM標準規格に対するDICOMコンテンツの準拠をチェックするためのルールのコレクションを定義するXML文書です。 制約ドキュメントでは、DICOMメタデータ・スキーマでは表現できない属性間の関係およびセマンティックの制約を指定します。 デフォルトの制約ドキュメント（ordcmct.xml、ordcmcmd.xmlおよびordcmcmc.xml）には、DICOM標準規格のPart 3のサブセットに従って定義された検証ルールのサンプル・セットが記述されています。
マッピング・ドキュメントは、各属性をXMLメタデータ・ドキュメント・ツリーの特定の要素にマップする方法を定義するXML文書です。 このドキュメントによって、DICOMメタデータの抽出されたXML表現の構造が決まります。 デフォルトのマッピング・ドキュメント（ordcmmp.xml）では、DICOMコンテンツからXML表現へのマッピングをフラット・リストとして定義します。このリストには、XMLでエンコーディングされたすべてのDICOM属性がルート要素<DICOM_OBJECT>の下に含まれます。
プリファレンス・ドキュメントは、ランタイム・パラメータを定義するXML文書です。たとえば、DICOMコンテンツを処理する際の警告メッセージを記録する方法などを定義します。 デフォルトのプリファレンス・ドキュメントはordcmpf.xmlです。
プライベート・ディクショナリ・ドキュメントは、メーカー独自または企業独自のDICOMコンテンツの属性を定義できるようにするXML文書です。 デフォルトのプライベート・ディクショナリ・ドキュメント（ordcmpv.xml）には、Oracleのプライベート属性が定義されています。
標準ディクショナリ・ドキュメントは、DICOM標準規格のPart 6に定義されている標準属性を記述するXML文書です。 デフォルトの標準ディクショナリ・ドキュメントはordcmsd.xmlです。
UID定義ドキュメントは、各DICOMデータ型の一意識別子（UID）を記述するXML文書です。 UIDは、DICOMコンテンツを全世界で一意に識別するISOオブジェクト識別子（OID）に基づいています。 UIDは、通常、DICOMコンテンツを作成する組織を一意に識別するルートと、組織内のDICOMコンテンツを一意に識別する接尾辞で構成されます。 デフォルトのUID定義ドキュメント（ordcmui.xml）には、DICOM標準規格のPart 6に定義されているUIDが記述されています。
インストールされる構成ドキュメント、およびそれらに関連するXMLスキーマ定義の詳細は、付録Aおよび付録Bをそれぞれ参照してください。
管理者は、データ・モデル・リポジトリのインタフェースを使用して構成ドキュメントを管理できます。
データ・モデル・リポジトリは、Oracle Multimedia DICOMのメソッド、プロシージャまたはファンクションをコールする前にロードする必要があります。 リポジトリのロードは、DICOMパッケージ・インタフェースからsetDataModel( )プロシージャを使用して実行します。
図2-5では、インストール時の状態と更新後の様々な状態におけるDICOMデータ・モデル・リポジトリの状態を、Unified Modeling Language（UML）のシーケンス図を使用して示しています。 また、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に示すように、setDataModel( )プロシージャはユーザー・セッション中に頻繁にコールされます。 すべてのユーザーは、それぞれのデータベース・セッションの初めにこのプロシージャをコールして、リポジトリをデータベースからメモリー構造内にロードする必要があります。 また、データ・モデルの新しい変更をアプリケーションで確認する必要がある場合には、いつでもこのプロシージャをコールできます。 ユーザーは、DICOMパッケージ・インタフェースに含まれるDICOMデータ・モデル・ユーティリティを介して、このプロシージャを使用できます。
データ・モデル・リポジトリの管理インタフェースの詳細は、第III部「DICOMの管理」を参照してください。 DICOMパッケージ・インタフェースに含まれるDICOMデータ・モデル・ユーティリティの詳細は、第4章を参照してください。
DICOMコンテンツからメタデータを抽出する操作には、XMLメタデータ・スキーマおよびマッピング・ドキュメントを使用するいくつかの操作が含まれます。
DICOMメタデータ・ドキュメントは、DICOMコンテンツから抽出されたメタデータを含むXML文書です。 オプションで、XMLスキーマを使用して各メタデータ・ドキュメントに制約を付けることができます。 各XMLメタデータ・スキーマには、対応するXMLマッピング・ドキュメントがあります。
DICOMコンテンツとDICOMメタデータ・ドキュメントのマッピングは、マッピング・ドキュメントで定義します。 マッピング・ドキュメントでは、DICOMコンテンツの属性をスキーマ準拠のXML文書にマップする方法を定義します。 他の構成ドキュメントと同様に、マッピング・ドキュメントはDICOMデータ・モデル・リポジトリ（2.4項を参照）で管理されます。
Oracleには、デフォルトのXMLメタデータ・スキーマ（ordcmmd.xsd）と、対応するXMLマッピング・ドキュメント（ordcmmp.xml）が用意されています。 アプリケーションの設計者が独自のメタデータ・スキーマを作成する場合は、スキーマ定義とマッピング・ドキュメントに互換性を持たせる必要があります。 また、作成したデータ型定義は、Oracleデータ型定義（ordcmmddt.xsd）との互換性を持つことも必要です。
図2-6に、メタデータの抽出およびXMLマッピングの処理の対象となるコンポーネントを示します。 図2-6の各番号付き項目は、この処理で使用されるコンポーネントを表します。
入力はバイナリ形式のDICOMコンテンツ（項目1）です。これは、ORDDicomオブジェクトに格納するか、BLOBまたはBFILEに直接格納することができます。 出力はXMLメタデータ・ドキュメント（項目7および8）です。 メタデータ・ドキュメントのレイアウトは、マッピング・ドキュメント（項目3）で指定します。 メタデータの抽出では、マッピング・オプション・パラメータを使用して、出力するメタデータ・ドキュメントに含める属性グループを指定します。 図2-6内の項目をつなぐ実線は、データの流れを表します。 項目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問合せでアドレッシングできます。 アンマップ・セクションでは、属性は属性タグでソートされ、その値表現を使用してリストされます。 アンマップ・セクションにある属性は、次の書式の要素タグを使用するXPath問合せでアドレッシングできます。
/DICOM/Other/VR_TYPE(tag=='HHHHHHHH')
この問合せのHHHHHHHHは16進の属性タグで、/DICOM/Otherはアンマップ・セクションに指定されたパスです。 独自のマッピング・ドキュメントの作成方法は、11.2.3項を参照してください。
メタデータ抽出機能のマッピング・オプションでは、出力するXMLメタデータ・ドキュメントに含める属性グループを指定します。 マッピング・オプションは、mapped（マップ済）、standard（標準）、all（すべて）の3つです。
抽出オプションがmappedの場合（項目4）は、マップ済属性のみがXMLメタデータ・ドキュメントに含まれます。 メタデータ・ドキュメントを使用するアプリケーションで必要となる属性セットが確定している場合は、このオプションが有効です。 結果のメタデータ・ドキュメント（項目7）は、明確なツリー構造になります。
抽出オプションがstandardの場合（項目5）は、DICOM標準規格で定義されているすべてのマップ済属性とアンマップ属性がXMLメタデータ・ドキュメントに抽出されます。 マッピングが定義されていないプライベート属性は、出力から除外されます。 このオプションが有効なのは、フルテキスト検索を実行するアプリケーションなどで、DICOMコンテンツに含まれるすべての標準属性が使用される場合です。
抽出オプションがallの場合（項目6）は、DICOMコンテンツに含まれるすべての属性が抽出され、XMLメタデータ・ドキュメントにエンコーディングされます。 このオプションを使用すると、すべてのDICOM属性をバイナリからXMLにマッピングできます。
|
注意: ユーザー指定の制限を超えるバイナリ長の属性は、XMLメタデータ・ドキュメントに含まれません。 これらの制限をプリファレンス・ドキュメントで指定する方法の詳細は、11.2.6項を参照してください。 |
マッピング・オプションがallまたはstandardの場合、アンマップ属性のDICOMデータ要素はXML要素Other（項目8）の下に格納されます。 結果のXML文書は、データベースの表に格納して索引付けし、キーワードまたはXPath問合せ文を使用して問い合せることができます。 マップ済セクションおよびアンマップ・セクションに、別のマッピング構造と要素名を定義する方法は、11.2.3項を参照してください。
例2-1に、XMLマッピング・ドキュメントの例（sample_map.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>Dongbai Guo</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>
この例では、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-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's Name">
<NAME type="unibyte">
<FAMILY>CompressedSamples</FAMILY>
<GIVEN>RG2</GIVEN>
</NAME>
<VALUE>CompressedSamples^RG2</VALUE>
</PATIENT_NAME>
</KEY_ATTRIBUTES>
</DICOM_OBJECT>
DICOMコンテンツの検証には、指定した制約ルール・セットにデータが準拠しているかどうかの確認が含まれます。
中間層（アプリケーション層）ではなくデータベースに準拠の検証を実装することには、いくつかのメリットがあります。 まず、DICOMコンテンツを検証することで、アーカイブ済のDICOMコンテンツの整合性と一貫性を確保できます。これは、あらゆるソースからDICOMコンテンツをデータベースに受け入れ、データベースでコンテンツの整合性をチェックできるようにすることによって実現されます。 この機能により、データベースを集中化されたデータ・ストアとして動作させることができ、企業データの制約ルールを適用しながら様々なDICOMコンテンツ・ソースへの接続が可能になります。 大規模な組織や行政部門では、DICOM標準規格より多少厳しい独自の制約ルール・セットを設定し、その制約ルールへの準拠を適用することができます。 生命科学などのDICOM標準規格がまだ整備途中の新しい分野では、制約ルールはDICOMコンテンツの従来の表現を適用する暫定ツールとして動作するため、将来のDICOM標準規格への移行が簡略化されます。 データベース・システム全体を準拠させることにより、最終的には、企業（アプリケーション）の統合およびデータ・マイニングを大幅に簡略化できます。
DICOM制約ドキュメントでは、DICOMコンテンツがDICOM標準規格または特定の組織や企業のガイドラインに準拠しているかをチェックするための1つ以上の制約ルールを定義します。 例2-3に、インストール時の制約ドキュメントの1つ（ordcmct.xml）を示します。
例2-3 制約ドキュメントの例
<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright (c) 2007, Oracle. All rights reserved.
NAME
ordcmct.xml - Oracle Multimedia DICOM default 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">
<DOCUMENT_HEADER>
<dt:DOCUMENT_CHANGE_LOG>
<dt:DOCUMENT_MODIFIER>Dongbai Guo</dt:DOCUMENT_MODIFIER>
<dt:DOCUMENT_MODIFICATION_DATE>2007-04-09</dt:DOCUMENT_MODIFICATION_DATE>
<dt:DOCUMENT_VERSION>1.0</dt:DOCUMENT_VERSION>
<dt:MODIFICATION_COMMENT>Oracle default constraint rules</dt:MODIFICATION_COMMENT>
</dt:DOCUMENT_CHANGE_LOG>
</DOCUMENT_HEADER>
<EXTERNAL_RULE_INCLUDE name="ImagePixelMacro">
A subset of Image Pixel Macro defined in DICOM standard,
PS 3.3-2007, Table C.7-11b
</EXTERNAL_RULE_INCLUDE>
<EXTERNAL_RULE_INCLUDE name="GeneralStudyModule">
A subset of General Study Module defined in DICOM standard,
PS 3.3-2007, Table C.7-3
</EXTERNAL_RULE_INCLUDE>
<EXTERNAL_RULE_INCLUDE name="GeneralSeriesModule">
A subset of General Series Module defined in DICOM standard,
PS 3.3-2007, Table C.7-5a
</EXTERNAL_RULE_INCLUDE>
<EXTERNAL_RULE_INCLUDE name="SOPCommonModule">
A subset of SOP Common Module defined in DICOM standard,
PS 3.3-2007, Table C.12-1
</EXTERNAL_RULE_INCLUDE>
<GLOBAL_RULE name="OracleOrdDicomImage">
<PREDICATE>
<GLOBAL_RULE_REF>ImagePixelMacro</GLOBAL_RULE_REF>
</PREDICATE>
<ACTION action="warning" when="false">missing mandatory image attribute</ACTION>
</GLOBAL_RULE>
<GLOBAL_RULE name="OracleOrdObject">
<PREDICATE>
<GLOBAL_RULE_REF>SOPCommonModule</GLOBAL_RULE_REF>
</PREDICATE>
<PREDICATE>
<GLOBAL_RULE_REF>GeneralSeriesModule</GLOBAL_RULE_REF>
</PREDICATE>
<PREDICATE>
<GLOBAL_RULE_REF>GeneralStudyModule</GLOBAL_RULE_REF>
</PREDICATE>
</GLOBAL_RULE>
</CONFORMANCE_CONSTRAINT_DEFINITION>
リポジトリに制約ドキュメントを挿入すると、ユーザーは制約ドキュメント内に定義されたグローバル制約ルールに対してDICOMコンテンツを検証できます。 （グローバル制約ルールは<GLOBAL_RULE>タグを使用して定義します。） たとえば、ユーザーは、DICOMコンテンツがOracleOrdDicomImageというインストール済のグローバル制約ルールに準拠しているかどうかをチェックできます。
ORDDicomオブジェクトは、加工したり他の画像形式に変換することができます。 また、既存のORDDicomオブジェクトから新しいORDDicomオブジェクトを作成することもできます。 図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画像がORDImageオブジェクト、またはGIFやJPEGなどの形式のBLOBに書き込まれた後は、変換済の画像を既存のOracle Multimedia機能を使用してOracle Multimedia JSPタグ・ライブラリまたは他のツールでWeb上に表示できます。
米国におけるHealth Insurance Portability and Accountability Act（HIPAA）などの政府の規制により、患者の個人データの保護が義務づけられています。 外部のリソースとDICOMコンテンツを共有する場合は、患者の個人データを匿名化することが多く求められます。 データベース内でDICOMコンテンツを匿名化することにより、患者の個人データがデータベースの外部に露出することを防ぎ、個人情報の保護を簡略化することができます。
米国におけるHIPAA規制の詳細は、次に示すHIPAAのWebサイトを参照してください。
DICOMコンテンツを匿名化する処理は、データ・モデル・リポジトリを使用してカスタマイズできます。 ユーザーは様々な匿名ドキュメントをXMLで作成できます。 各匿名ドキュメントには、匿名化する一連の属性と、それらの属性を匿名化するために実行するアクションのタイプを記述します。 サポートされているアクションは削除と置換です。 削除アクション（デフォルトのアクション）は、属性を削除するか、またはDICOMコンテンツおよびORDDicomオブジェクトの属性の長さを0（ゼロ）に設定します。 置換アクションでは、属性が文字列に置き換えられます。使用する文字列は、空にすることも、DICOMコンテンツおよびORDDicomオブジェクト属性に含まれるユーザー定義の文字列にすることもできます。 例2-4に、匿名ドキュメントの例を示します。
例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>Dongbai Guo</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">Smith^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>
