2 Oracle Multimedia DICOMの概念

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

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

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

• Oracle Multimedia DICOMの記憶域

• モデル駆動型の設計

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

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

• DICOMコンテンツの検証

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

• DICOMコンテンツの匿名化

• パーティション化のためのDICOMメタデータの抽出

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「Oracle Multimedia DICOMのアーキテクチャ」の説明

Oracle Multimedia DICOMを使用して、Oracle Databaseは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と外部ファイル・ストレージを結ぶ両方向矢印は、このデータ移動を示します。

関連項目:

• Oracle Multimediaの概要と完全なアーキテクチャの説明は、Oracle Multimediaユーザーズ・ガイドを参照してください。

• Javaプログラム言語でOracle Multimedia DICOMを使用する方法の詳細は、Oracle Multimedia DICOM Java APIリファレンスを参照してください。

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「ORDDicomオブジェクト」の説明

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

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

図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「DICOMモデルに基づいた解析の詳細」の説明

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

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

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

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

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

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

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

データ・モデル・リポジトリを構成する構成ドキュメント・セットには、匿名ドキュメント、制約ドキュメント、DICOMプロトコル・ドキュメント、マッピング・ドキュメント、プリファレンス・ドキュメント、プライベートおよび標準ディクショナリ・ドキュメント、格納タグ・リスト・ドキュメントおよび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
DICOMプロトコル	なし脚注1	ordcmdp.xsd
マッピング	ordcmmp.xml	ordcmmp.xsd
プリファレンス	ordcmpf.xml	ordcmpf.xsd
プライベート・ディクショナリ	ordcmpv.xml	ordcmpv.xsd
標準ディクショナリ	ordcmsd.xml	ordcmsd.xsd
格納タグ・リスト	なし	ordcmstl.xsd
UID定義	ordcmui.xml	ordcmui.xsd

^脚注1

DICOM_PROTOCOLのドキュメント・タイプにデフォルトのXMLドキュメントは存在しません。ユーザーがDICOM画像およびメタデータを格納するには、カスタム表を1つ以上作成する必要があります。次に、これらの表を使用するようにDICOMプロトコル・アダプタを構成するために、DICOMプロトコル・ドキュメントを設計する必要があります。

注意:

これらの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プロトコル・ドキュメントは、DICOM画像およびメタデータをOracle Database内に格納する場所を管理する、ユーザーによる構成が可能なパラメータの名前付きコンテナとして使用されるXMLドキュメントです。Oracle Databaseに接続するように構成されるOracle DICOMプロトコル・アダプタの各インスタンスには、DICOMプロトコル・ドキュメントが関連付けられている必要があります。たとえば、DICOMプロトコル・ドキュメントordcmdp.xmlは、Oracle Databaseに接続するように構成されたOracle DICOMプロトコル・アダプタの1つのインスタンスについて、Oracle Databaseとの間でDICOM画像およびメタデータの格納、問合せおよび取得を行う場所を定義します。

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

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

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

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

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

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

インストール済の構成ドキュメントとその関連するXMLスキーマ定義の詳細は、DICOM構成ドキュメントおよびDICOM XMLスキーマをそれぞれ参照してください。

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

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

データ・モデル・リポジトリは、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 DICOMデータ・モデル・リポジトリ

図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データ・モデル内のデータが大きく異なる場合があります。1つのPDB内のユーザー・ドキュメントは、CDB内の他のPDBには表示されません。

関連項目:

• マルチテナント・アーキテクチャの詳細は、『Oracle Database概要』を参照してください。

• CDBおよびPDBの管理の詳細は、『Oracle Database管理者ガイド』を参照してください

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)との互換性を持つことも必要です。

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

• メタデータの抽出およびXMLマッピングの処理の概要

• 抽出およびマッピングの処理に使用されるサンプルのXMLドキュメント

2.5.1 メタデータの抽出およびXMLマッピングの処理の概要

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

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

図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で、DICOMコンテンツがfindJoeSmithというグローバル制約ルールに準拠しているかどうかをチェックできます。

例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)では、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画像を処理してMicrosoft社のWindows用のAudio Video Interleave (AVI)形式のビデオに変換できます。これらの詳細およびその他のDICOM処理操作の詳細は、DICOMの開発の概要およびDICOMの処理およびサポートされる形式を参照してください。

2.8 DICOMコンテンツの匿名化

米国の医療保険の相互運用性と説明責任に関する法律(Health Insurance Portability and Accountability Act、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>

2.9 パーティション化のためのDICOMメタデータの抽出

Oracle Multimediaはクライアント・ツールまたは中間層を使用することでデータベースの外部のDICOMメタデータの抽出を実行できます。この機能により、データベースにデータをロードする前にDICOMメタデータを抽出できるため、データベース内でDICOMデータのメタデータベースのパーティション化を円滑化できます。

パーティション化では、非常に大規模な表や索引でもパーティションと呼ばれる小さく管理が容易な単位に分解することで、サポートされます。パーティション化によって、データが利用性が向上し、管理の容易化および問合せ時間の短縮を実現できます。

DICOMメタデータ属性をパーティション・キーに含めることができます。パーティション・キーは、パーティション表の各行が格納されるパーティションを決定する1つ以上の列のセットです。データを確実に正しいパーティションに格納するには、データのロード時にパーティション・キーの値を指定する必要があります。

Oracle Multimedia DICOMにはOracle Multimedia Mid-Tier Java APIが含まれています。この中間層用のクライアント・アプリケーション・プログラミング・インタフェースを使用すると、開発者はOracle Databaseの外部でDICOMメタデータを抽出するJavaアプリケーションを記述できます。このAPIを使用すると、データがデータベースにロードされる前に、パーティション・キーを構成するDICOM属性を抽出できます。

関連項目:

• 参照情報については、Oracle Multimedia Mid-Tier Java APIリファレンスを参照してください。

• パーティション化の詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。