ヘッダーをスキップ
Oracle Multimedia DICOM開発者ガイド
11g リリース1(11.1)
E05685-01
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

11 構成ドキュメントの作成

管理者は、独自の構成ドキュメントの作成など、多くのリポジトリ管理タスクを実行できます。 この章では、構成ドキュメントの特性について説明し、特定の組織または企業に固有の構成ドキュメントを記述する手順を示します。 他のリポジトリ管理タスクの詳細は、第8章を参照してください。

この章は、次の項で構成されています。


注意:

この章では、XML要素の属性名を固定幅フォントで示します。

11.1 構成ドキュメントの特性

インストールが完了すると、Oracle Multimedia DICOMデータ・モデル・リポジトリには、次のデフォルトの構成ドキュメント・セットが含まれます。

構成ドキュメントは、タイプごとに固有の特性があります。それぞれの特性については、次の各項で簡単に説明します。 構成ドキュメントの挿入、更新および削除の詳細は、第8章を参照してください。 これらの処理の例は、第10章を参照してください。

11.1.1 匿名ドキュメントの特性

匿名ドキュメントには次の特性があります。

  • 他のタイプのドキュメントが匿名ドキュメントに依存することはありません。

  • 匿名ドキュメント間には、依存性がありません。

  • 匿名ドキュメントは、標準ディクショナリ・ドキュメントおよびプライベート・ディクショナリ・ドキュメントに依存します。

  • リポジトリ内に保持できる匿名ドキュメントの数に上限はありません。

  • 匿名ドキュメントに対する変更は、isAnonymous( )メソッドおよびmakeAnonymous( )メソッドの結果に影響します。

11.1.2 制約ドキュメントの特性

制約ドキュメントには次の特性があります。

  • 他のタイプのドキュメントが制約ドキュメントに依存することはありません。

  • 制約ドキュメント間には、依存性がある場合があります。

  • 制約ドキュメントは、標準ディクショナリ・ドキュメントおよびプライベート・ディクショナリ・ドキュメントに加えて、プリファレンス・ドキュメントにも依存します。

  • リポジトリ内に保持できる制約ドキュメントの数に上限はありません。

  • 後から挿入する制約ドキュメントは、先に挿入した制約ドキュメントに依存するように記述できます。 たとえば、インストール済の制約ドキュメントを例に取ると、ordcmct.xmlordcmcmd.xmlに依存し、これらのドキュメントは両方ともordcmcmc.xmlに依存します。

  • isConformanceValid( )メソッドは、指定された制約ルールおよびDICOMコンテンツに依存します。 (制約ドキュメントに定義された)制約ルールが変更されると、DICOMコンテンツに対して異なる検証が行われる可能性があります。

  • 制約ルールで指定されている属性にNULL値が検出された場合に例外を発生させるかどうかは、プリファレンス・ドキュメント内のEXP_IF_NULL_ATTR_IN_CONSTRAINTパラメータで指定します。 このパラメータをtrueに設定すると、isConformanceValid( )メソッドで例外が発行されます。それ以外の場合、検出された条件はfalseと評価されます。

11.1.3 マッピング・ドキュメントの特性

マッピング・ドキュメントには次の特性があります。

  • 他のタイプのドキュメントがマッピング・ドキュメントに依存することはありません。

  • マッピング・ドキュメント間には、依存性がありません。

  • マッピング・ドキュメントは、標準ディクショナリ・ドキュメントおよびプライベート・ディクショナリ・ドキュメントに加えて、プリファレンス・ドキュメントにも依存します。

  • リポジトリ内に保持できるマッピング・ドキュメントの数に上限はありません。

  • マッピング・ドキュメントがextractMetadata( )メソッドのパラメータとして使用されている場合、マッピング・ドキュメントに対する変更は、extractMetadata( )メソッドの結果に影響します。

  • マッピング・ドキュメントにメタデータXML名前空間が指定されている場合に、extractMetadata( )メソッドが正しく機能するには、そのマッピング・ドキュメントに対応するメタデータXMLスキーマがマッピング・ドキュメントに登録済で、マッピング・ドキュメントと整合性が取れている必要があります。

  • 抽出されたメタデータは、次の条件が両方とも満たされる場合にのみ、スキーマ検証が行われます。

    • マッピング・ドキュメントにXMLスキーマの名前空間が指定されている。

    • プリファレンス・ドキュメント内のVALIDATE_METADATAパラメータ値がtrue(デフォルト)である。

11.1.4 標準ディクショナリ・ドキュメントの特性

標準ディクショナリ・ドキュメントには次の特性があります。

  • 1つの標準ディクショナリ・ドキュメント(ordcmsd.xml)が、Oracleによってインストールされます。

  • 標準ディクショナリ・ドキュメントへの変更は、DICOM標準規格を更新する目的のみに制限する必要があります。

  • リポジトリ内に保持できる標準ディクショナリ・ドキュメントの数に上限はありません。

11.1.5 プライベート・ディクショナリ・ドキュメントの特性

プライベート・ディクショナリ・ドキュメントには次の特性があります。

  • 1つのプライベート・ディクショナリ・ドキュメント(ordcmpv.xml)が、Oracleによってインストールされます。

  • リポジトリ内に保持できるプライベート・ディクショナリ・ドキュメントの数に上限はありません。

11.1.6 プリファレンス・ドキュメントの特性

プリファレンス・ドキュメントには次の特性があります。

  • リポジトリ内には、最大2つ(Oracle定義およびユーザー定義を1つずつ)のプリファレンス・ドキュメントを保持できます。 インストール済のOracle定義のプリファレンス・ドキュメント(ordcmpf.xml)には、Oracle固定のパラメータ名と値のリストが含まれています。 ユーザー定義のプリファレンス・ドキュメントでは、Oracle定義のプリファレンス・ドキュメントに設定されているデフォルトのプリファレンス・ドキュメント値を更新できます。

  • プリファレンス・ドキュメント内の値を変更すると、DICOMメソッド、ファンクションおよびプロシージャの動作が変わります。 具体的には、Oracle定義のプリファレンス・ドキュメントに定義されたデフォルト値が、ユーザー定義のプリファレンス・ドキュメントに定義されたプリファレンス値によって上書きされます。

11.1.7 UID定義ドキュメントの特性

UID定義ドキュメントには次の特性があります。

  • リポジトリ内には、最大2つ(Oracle定義およびユーザー定義を1つずつ)のUID定義ドキュメントを保持できます。 インストール済のOracle定義のUID定義ドキュメント(ordcmui.xml)には、DICOM標準規格のPart 6に記述されているUID定義が含まれています。

  • ユーザー定義のUID定義ドキュメントに対する変更は、DICOM標準規格の更新または新しいUID値の追加を行う目的のみに制限する必要があります。


注意:

既存のUID値は変更しないでください。

11.2 構成ドキュメントの記述方法

管理者は、特定のアプリケーションまたは組織に対応する1つ以上の構成ドキュメントを作成できます。 次の各項では、構成ドキュメントの作成方法をタイプ別に説明します。

11.2.1 匿名ドキュメントの作成

匿名ドキュメントでは、匿名化する一連の属性と、それらの属性を匿名化するために実行するアクションを指定します。 ORDDicomオブジェクトの匿名ドキュメントは、isAnonymous( )メソッドおよびmakeAnonymous( )メソッドによって、個人を特定する情報を削除または置換した新しいオブジェクトを作成する場合に使用されます。

XMLスキーマordcman.xsdには、匿名ドキュメントに制約を加えるXMLスキーマが定義されています。 (匿名ドキュメントのスキーマordcman.xsdの記述内容は、B.1項を参照してください。)

デフォルトの匿名ドキュメント(ordcman.xml)には、DICOM標準規格のPart 15「Basic Application Level Confidentiality Profile」に定義された属性のサブセットが記述されています。 これらの属性は、DICOMコンテンツでは削除されるか、"anonymous"という文字列に置換されます。 また、デフォルトの匿名ドキュメントでは、未定義の標準属性、およびプライベート属性がDICOMコンテンツからすべて削除されます。

各匿名ドキュメントの<ANONYMITY_ACTION>要素には、1つのaction属性が含まれます。 action属性の値は、匿名ドキュメントに含まれる単一の属性または一連の属性に適用できます。 グローバル・アクションは、一連の属性(すべてのプライベート属性など)に適用されます。

次の表に、action属性として使用できる値を示します。

説明
none アクションは実行されません。 結果のDICOMコンテンツには、指定された属性または一連の属性の値が変更されずにそのまま表示されます。
remove デフォルト値です。 指定された属性または一連の属性が結果のDICOMコンテンツから削除されます。

注意: 一部の画像アプリケーションには、特定の属性(SOP_INSTANCE_UIDSOP_CLASS_UIDなど)に依存するものもあります。 このような場合は、removeアクションのかわりにreplaceアクションを使用して、適切な値を指定してください。

replace 結果のDICOMコンテンツに含まれる属性値は、指定した値で置換されます。 指定する置換値は、データ・ディクショナリの<VR>要素で定義されたタグのデータ型と一致する文字列表現であることが必要です。

注意: このアクション値は、グローバル・アクションには指定できません。

次に例を示します。

標準タグ00100022はPatient ID(患者ID)を表し、データ・ディクショナリでの<VR>値はCS (CODE_STRING)です。 データ型CSは、xs:token of length 16としてXMLスキーマordcmrdt.xsdに定義されています。 置換値は、この定義に準拠する文字列表現であることが必要です。

標準タグ00081160はReferenced Frame Number(参照先フレーム番号)を表し、<VR>値はIS (INTEGER_STRING)です。 データ型ISは、xs:integerとしてXMLスキーマordcmrdt.xsdに定義されています。 置換値は、この定義に準拠する文字列表現であることが必要です。


匿名ドキュメント内の属性は、標準属性でもプライベート属性でもかまいません。 標準属性またはプライベート属性は、定義済の場合も未定義の場合もあります。 定義済の標準属性は、DICOM標準規格、およびデータ・モデル・リポジトリ内の標準ディクショナリで定義されています。 定義済のプライベート属性は、特定の組織によって定義された固有の属性です。 Oracle Multimediaで既知の定義済のプライベート属性は、データ・モデル・リポジトリ内のプライベート・ディクショナリで定義されています。 未定義の属性は、データ・モデル・リポジトリ内の標準ディクショナリまたはプライベート・ディクショナリのいずれにも定義されていません。

<INDIVIDUAL_ATTRIBUTE>要素には、定義済の標準属性またはプライベート属性を匿名化するために実行するアクションを定義します。 プライベート属性の場合は、<PRIVATE_ATTRIBUTES>要素で定義されたグローバル・アクションより、この要素に指定されたアクションが常に優先されます。 また、未定義の標準属性またはプライベート属性を<INDIVIDUAL_ATTRIBUTE>要素の値として匿名ドキュメントに指定することはできません。

次の表では、匿名ドキュメントのグローバル・アクションを定義する要素を説明します。

要素 説明
<PRIVATE_ATTRIBUTES> 定義済および未定義のすべてのプライベート属性に対して実行するアクションを指定します。

注意: <INDIVIDUAL_ATTRIBUTE>要素で定義したプライベート属性に対するアクションは、<PRIVATE_ATTRIBUTES>要素で定義したグローバル・アクションよりも常に優先されます。

<UNDEFINED_STANDARD_ATTRIBUTES> データ・モデル・リポジトリ内の標準ディクショナリで定義されていないすべての標準属性に対して実行するアクションを指定します。

DICOM属性タグには、グループ番号および要素番号が含まれます。

標準属性タグは偶数のグループ番号で識別されます。

<UNDEFINED_PRIVATE_ATRIBUTES> データ・モデル・リポジトリ内のプライベート・ディクショナリで定義されていないすべてのプライベート属性に対して実行するアクションを指定します。

注意: この要素で定義したアクション値は、<PRIVATE_ATTRIBUTES >要素で定義したアクション値よりも優先されます。


<ATTRIBUTE_TAG>要素の有効な値の例は、0010001000100010(DICOM)10871100(PRIVATE ORG)などです。


注意:

プライベート属性の定義者名として現在使用できるのは、次の値のみです。
  • 大/小文字のアルファベット: AからZ

  • 数字: 0から9

  • 文字: '.'' '(空白)および'/'


次の各項では、匿名ドキュメントの作成方法の例を示します。

11.2.1.1 標準属性の匿名化: 例1

この例では、指定した値で標準属性Patient's Nameを置換し、この属性を結果のDICOMコンテンツで匿名化する方法を示します。 これらのアクションを定義するXML文は、太字で強調表示しています。

<INDIVIDUAL_ATTRIBUTE>
   <ATTRIBUTE_TAG>00100010</ATTRIBUTE_TAG>
   <DESCRIPTION>Patient's Name </DESCRIPTION>
   <ANONYMITY_ACTION action="replace">anonymous</ANONYMITY_ACTION>
</INDIVIDUAL_ATTRIBUTE>

<ATTRIBUTE_TAG>値00100010は、データ・モデル・リポジトリ内の標準ディクショナリに定義されています。 定義者名が<ATTRIBUTE_TAG>値に指定されていない場合は、デフォルト値の"DICOM"が使用されます。 00100010タグの値は、結果のDICOMコンテンツでは値"anonymous"で置換されます。

次の例は、標準ディクショナリの標準属性タグ00100010を定義しています。

<STANDARD_ATTRIBUTE_DEFINITION>
   <TAG>00100010</TAG>
   <NAME>Patient's Name</NAME>
   <VR>PN</VR>
   <VM>1</VM>
</STANDARD_ATTRIBUTE_DEFINITION>

このタグ定義では、<VR>要素で定義されているように、データ型がPNの標準属性Patient's Nameを示しています。 <VR>要素は、DICOM標準規格(Part 5)で定義されているように、標準データ型の指定に使用される値表現の要素です。 データ型PNは、XMLスキーマordcmrdt.xsdに定義されています。 属性Patient's Nameを置換する値は、<VR>要素で定義された値の文字列表現であることが必要です。

11.2.1.2 プライベート属性の匿名化: 例2

この例では、指定した値でプライベート属性10871100(PRIVATE ORG)を置換し、この属性を結果のDICOMコンテンツで匿名化する方法を示します。 これらのアクションを定義するXML文は、太字で強調表示しています。

<INDIVIDUAL_ATTRIBUTE>
   <ATTRIBUTE_TAG>10871100(PRIVATE ORG)</ATTRIBUTE_TAG>
   <DESCRIPTION>Media Type </DESCRIPTION>
   <ANONYMITY_ACTION action="replace"> replaced</ANONYMITY_ACTION>
</INDIVIDUAL_ATTRIBUTE>

定義者名PRIVATE ORGを指定した<ATTRIBUTE_TAG>値10871100は、データ・モデル・リポジトリ内のプライベート・ディクショナリに定義されている必要があります。 プライベート属性10871100(PRIVATE ORG)の値は、結果のDICOMコンテンツでは指定した値で置換されます。

前述の例では、プライベート・ディクショナリ・タグ10871100が次のように定義されていることを想定しています。

<PRIVATE_ATTRIBUTE_DEFINITION>
  <TAG>10871100</TAG>
  <NAME>Media Type</NAME>
  <DEFINER>PRIVATE ORG</DEFINER>
  <VR>CS</VR>
  <VM>1</VM>
</PRIVATE_ATTRIBUTE_DEFINITION>

このタグ定義では、<VR>要素で定義されているように、データ型がCSで、名前がMedia Typeのプライベート属性10871100(PRIVATE ORG)を示しています。 データ型CSは、xs:token of length 16としてXMLスキーマordcmrdt.xsdに定義されています。 置換値は、<VR>要素で定義された値に準拠する文字列表現であることが必要です。

11.2.1.3 すべてのプライベート属性の匿名化: 例3

ここに示す例では、多くのプライベート属性を削除したり、指定した値で置換することによって、それらの属性を結果のDICOMコンテンツで匿名化する方法を示します。


注意:

次のガイドラインに留意してください。
  • <INDIVIDUAL_ATTRIBUTE>要素で定義した特定のプライベート属性に対するアクション値は、<PRIVATE_ATTRIBUTES>要素で定義したグローバル・アクションよりも常に優先されます。

  • <UNDEFINED_PRIVATE_ATTRIBUTES>要素で定義したグローバル・アクションは、<PRIVATE_ATTRIBUTE>要素で定義したグローバル・アクションよりも優先されます。


次の例では、アクション値removeを使用して、結果のDICOMコンテンツに含まれるプライベート属性をすべて削除します。

<PRIVATE_ATTRIBUTES action="remove"></PRIVATE_ATTRIBUTES>
<UNDEFINED_PRIVATE_ATTRIBUTES action="remove" />

次の例では、アクション値removeを使用して、結果のDICOMコンテンツから未定義のプライベート属性をすべて削除します。 また、この例では、アクション値replaceを使用して、結果のDICOMコンテンツに含まれる定義済のプライベート属性10871100(PRIVATE ORG)のタグ値を"anonymous"で置換します。 これらのアクションを定義するXML文は、太字で強調表示しています。

<PRIVATE_ATTRIBUTES action="remove"></PRIVATE_ATTRIBUTES>
<INDIVIDUAL_ATTRIBUTE>
    <ATTRIBUTE_TAG>10871100(PRIVATE ORG)</ATTRIBUTE_TAG>
    <DESCRIPTION>Media Type </DESCRIPTION>
     <ANONYMITY_ACTION action="replace"> anonymous</ANONYMITY_ACTION>
</INDIVIDUAL_ATTRIBUTE>

次の例では、アクション値noneを使用して、定義済のプライベート属性をすべて結果のDICOMコンテンツに含めます。 また、この例では、アクション値removeを使用して、結果のDICOMコンテンツから未定義のプライベート属性をすべて削除します。

<PRIVATE_ATTRIBUTES action="none"></PRIVATE_ATTRIBUTES>
<UNDEFINED_PRIVATE_ATTRIBUTES action="remove" />

次の例では、アクション値removeを使用して、結果のDICOMコンテンツから定義済のプライベート属性をすべて削除します。 また、この例では、アクション値noneを使用して、すべての未定義のプライベート属性を結果のDICOMコンテンツに含めます。

<PRIVATE_ATTRIBUTES action="remove"></PRIVATE_ATTRIBUTES>
<UNDEFINED_PRIVATE_ATTRIBUTES action="none" />

11.2.1.4 未定義の標準属性の匿名化: 例4

この例では、アクション値removeを使用して、結果のDICOMコンテンツから未定義の標準属性をすべて削除します。

<UNDEFINED_STANDARD_ATTRIBUTES action="remove" />

11.2.2 制約ドキュメントの作成

制約ドキュメントでは、1つ以上の制約ルールを定義します。 XMLスキーマordcmct.xsdには、制約ドキュメントに制約を加えるXMLスキーマが定義されています。 (制約ドキュメントのスキーマordcmct.xsdの記述内容は、B.2項を参照してください。)

デフォルトの制約ドキュメント(ordcmct.xmlordcmcmd.xmlordcmcmc.xml)では、DICOM標準規格およびその他の全組織的なガイドラインに対してDICOMコンテンツの準拠を検証するルールがXMLで表現されています。

実行時に、ユーザーは、コール可能な1つ以上の制約ルールにDICOMコンテンツが準拠しているかを検証するために、PL/SQLまたはJavaファンクションをコールできます。 各コール可能な制約ルールは、(<GLOBAL_RULE>要素を使用して)グローバル・ルールとして定義されます。 グローバル・ルールは、DICOMコンテンツで満たされる必要のある要件を定義した制約ルールです。

制約ルールは複数の個別の条件で構成できます。 条件では、DICOMコンテンツの状態を定義します。 条件には、論理文、値を比較するリレーショナル文、ブール型を戻すファンクション・コール評価、または他の条件定義への参照を指定できます。 条件定義は再帰的です。 たとえば、条件を論理文として使用する場合、条件には他の2つの条件の論理ORが含まれます。 その他の各条件には、同様にリレーショナル条件を指定できます。

複雑な制約ルールの定義を簡略化するには、制約マクロを使用できます。 各制約マクロは、(<GLOBAL_MACRO>要素を使用して)グローバル・マクロとして定義できます。 制約マクロで条件を定義するときの構文の記述方法は、制約ルールと同じです。 制約マクロが制約ルールと異なる点は、制約ルールでは条件オペランドに固定値を含みますが、制約マクロではマクロ・パラメータを含めることができるという点です。 制約マクロのマクロ・パラメータは、(<INVOKE_MACRO>要素を使用して)マクロがコールされたときに、パラメータ値と置換されます。

制約定義は、複数の制約ドキュメント・ファイルに分割して、各制約ファイルで1つ以上の制約ルールまたは制約マクロを定義することができます。 グローバル・ルールおよびグローバル・マクロは、内部および外部の他のグローバル・ルールおよびグローバル・マクロを参照できます。 内部ルールおよび内部マクロは、同じ制約ファイル内に定義します。 外部ルールおよび外部マクロは、それらのルールおよびマクロが定義された他の制約ドキュメント・ファイルからインポートします。 一連の外部制約ルールまたは外部制約マクロを制約ファイル内で参照する前に、(それぞれ<EXTERNAL_RULE_INCLUDE>要素または<EXTERNAL_MACRO_INCLUDE>要素を使用して)それらのルールまたはマクロをファイルに指定する必要があります。 また、DICOM管理者は、参照元の制約ドキュメント・ファイルをリポジトリに挿入する前に、参照先の制約ファイルを挿入する必要があります。

XML制約スキーマordcmct.xsdでは、<ACTION>要素を使用して、準拠の検証メッセージを条件、制約ルールまたは制約マクロに関連付けます。 条件に関連付けられた<ACTION>要素に指定された条件に対して条件を評価する場合は、準拠を検証した後で情報ビューorddcm_conformance_vld_msgsを問い合せて、メッセージを確認できます。 (この情報ビューのリファレンス情報は、第4章orddcm_conformance_vld_msgsを参照してください。)

次の各項では、制約ドキュメントの作成方法の例を示します。

11.2.2.1 単純な制約ルールの定義: 例1

この例では、SOP共通モジュールで必要とされる2つの条件をチェックする単純な制約ルールの作成方法を示します(SOP共通モジュールは、DICOM標準規格のPS 3.3-2007のTable C.12-1に定義されています)。次の表に、DICOM標準規格のSOP共通モジュールに定義されているSOP Class UIDの条件およびSOP Instance UIDの条件を示します。

属性名 タグ タイプ 属性の説明
SOP Class UID (0008,0016) 1 SOPクラスを一意に識別します。 詳細は、C.12.1.1.1を参照してください。 PS 3.4も参照してください。
SOP Instance UID (0008,0018) 1 SOPインスタンスを一意に識別します。 詳細は、C.12.1.1.1を参照してください。 PS 3.4も参照してください。

前述の表の2つのエントリは、属性SOP Class UID (0008,0016)およびSOP Instance UID (0008,0018)が存在する必要があり、空にすることができないことを示しています。

次の条件は、SOP Class UID (0008,0016)属性が空でないかどうかをチェックします。

    <PREDICATE>
      <BOOLEAN_FUNC operator="notEmpty">
        <ATTRIBUTE_TAG>00080016</ATTRIBUTE_TAG>
      </BOOLEAN_FUNC>
    </PREDICATE>

次の条件は、SOP Instance UID (0008,0018)属性が空でないかどうかをチェックします。

   <PREDICATE>
      <BOOLEAN_FUNC operator="notEmpty">
        <ATTRIBUTE_TAG>00080018</ATTRIBUTE_TAG>
      </BOOLEAN_FUNC>
    </PREDICATE>

これら両方の属性が空でないかどうかをチェックすることは、前述の2つの条件を論理AND演算するのと同じことです。 この演算が実行されるようにするには、次のように、前述の2つの条件を論理AND演算する別の条件を定義します。

 <PREDICATE>
    <LOGICAL operator="and">
     <PREDICATE>
      <BOOLEAN_FUNC operator="notEmpty">
        <ATTRIBUTE_TAG>00080016</ATTRIBUTE_TAG>
      </BOOLEAN_FUNC>
    </PREDICATE>
    <PREDICATE>
      <BOOLEAN_FUNC operator="notEmpty">
        <ATTRIBUTE_TAG>00080018</ATTRIBUTE_TAG>
      </BOOLEAN_FUNC>
    </PREDICATE>
   </LOGICAL>
</PREDICATE>

外側の条件を省略すると、論理ANDの関係を持つ条件をより簡単に定義できます。 したがって、制約ドキュメントordcmcmd.xmlの制約ルール全体を使用すると、グローバル・ルールSOPCommonModuleは次のように定義できます。

  <GLOBAL_RULE name="SOPCommonModule">
    <DESCRIPTION>
      A subset of SOP Common Module defined in DICOM standard,
      PS 3.3-2007, Table C.12-1
    </DESCRIPTION>
    <PREDICATE>
      <BOOLEAN_FUNC operator="notEmpty">
        <ATTRIBUTE_TAG>00080016</ATTRIBUTE_TAG>
      </BOOLEAN_FUNC>
    </PREDICATE>
    <PREDICATE>
      <BOOLEAN_FUNC operator="notEmpty">
        <ATTRIBUTE_TAG>00080018</ATTRIBUTE_TAG>
      </BOOLEAN_FUNC>
    </PREDICATE>
  </GLOBAL_RULE>

各グローバル・ルールには、一意の名前を指定する必要があります。 さらに、各グローバル・ルールにオプションの<DESCRIPTION>要素を含め、ルールの説明を記述できます。

前述の例は、論理関係またはブール・ファンクションを表現する条件の定義方法を示しています。 リレーショナルな関係を表現する条件も、同様に定義できます。

11.2.2.2 他の制約ルールのインポートによる制約ルールの定義: 例2

この例では、外部の制約ルールを参照する方法と、外部の他の制約ルールを参照して階層状の制約ルールを作成する方法を示します。

制約ドキュメントordcmct.xmlには、グローバル・ルールOracleOrdObjectが定義されています。 この制約ルールは、次に示すように、SOPCommonModuleGeneralSeriesModuleおよびGeneralStudyModuleの3つの制約ルールの論理ANDとして定義されています。

 <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>

これら3つの制約ルールは制約ドキュメントordcmcmd.xmlに定義されており、次に示す外部ルール文によってDICOM制約ドキュメントordcmct.xmlにインポートされます。

 <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>

例2では、グローバル・ルールOracleOrdObjectから、例1で定義したグローバル・ルールSOPCommonModuleを参照しています。グローバル・ルールSOPCommonModuleは、他の制約ルールからも参照できます。 このように、制約ドキュメントはモジュール化したり構造化して記述できます。

11.2.2.3 制約マクロの定義および参照: 例3

この例では、DICOM属性が、コード・シーケンス・マクロで必要とされる最初の2つの条件に従ったコード・シーケンス属性であるかどうかをチェックする制約マクロの作成方法を示します(コード・シーケンス・マクロは、DICOM標準規格のPS 3.3-2007のTable 8.8-1に定義されています)。次の表に、DICOM標準規格のコード・シーケンス・マクロに定義されているCode ValueとCoding Scheme Designatorの条件を示します。

属性名 タグ タイプ 属性の説明
Code Value (0008,0100) 1C Section 8.1を参照。 シーケンス項目が存在する場合は必須。
Coding Scheme Designator (0008,0102) 1C Section 8.2を参照。 シーケンス項目が存在する場合は必須。

前述の表の2つのエントリは、必須の子属性Code Value (0008,0100)およびCoding Scheme Designator (0008,0102)を空にすることができないことを示しています。

次のグローバル・マクロ定義(制約ドキュメントordcmcmc.xmlを参照)では、属性Code Value (0008,0100)およびCoding Scheme Designator (0008,0102)が空でないかどうかがチェックされます。

  <GLOBAL_MACRO name="CodeSequenceMacro">
   <DESCRIPTION>
     A subset of Code Sequence Macro defined in DICOM standard,
     PS 3.3-2007, Table 8.8-1
   </DESCRIPTION>
  <PARAMETER_DECLARATION>CodeAttr</PARAMETER_DECLARATION>
  <PREDICATE>
   <DESCRIPTION>Code value must not be empty</DESCRIPTION>
   <BOOLEAN_FUNC operator="notEmpty">
    <ATTRIBUTE_TAG>${CodeAttr}.00080100</ATTRIBUTE_TAG>
   </BOOLEAN_FUNC>
  </PREDICATE>
  <PREDICATE>
   <DESCRIPTION>Coding scheme designator must not be empty</DESCRIPTION>
   <BOOLEAN_FUNC operator="notEmpty">
    <ATTRIBUTE_TAG>${CodeAttr}.00080102</ATTRIBUTE_TAG>
   </BOOLEAN_FUNC>
  </PREDICATE>
 </GLOBAL_MACRO>

制約マクロに含まれる条件には、パラメータを持つオペランドが含まれます。 これらのパラメータは、<PARAMETER_DECLARATION>要素で定義する必要があります。 これらのオペランドでパラメータを参照する場合は、${ }のように、ドル記号を付けた括弧でパラメータを囲む必要があります。 前述の例では、パラメータCodeAttrがチェック対象のコード・シーケンスを表します。 したがって、パラメータCodeAttrのコード値が空でないかどうかをチェックすることは、パラメータ${CodeAttr}.00080100が空でないかどうかをチェックするのと同じことです。

制約マクロは、マクロ・パラメータに異なる値を設定した、1つ以上の制約ルールからコールされることがあります。 制約マクロをコールするには、マクロ名と、そのマクロの全パラメータの名前/値ペアを指定する必要があります。

次の例は、(制約ドキュメントordcmcmd.xmlに含まれる)グローバル・ルールGeneralSeriesModuleの定義を示しています。このグローバル・ルールでは、制約マクロCodeSequenceMacroがコールされます。 このマクロをコールする部分は、太字で強調表示しています。

<GLOBAL_RULE name="GeneralSeriesModule">
    <DESCRIPTION>
      A subset of General Series Module defined in DICOM standard,
      PS 3.3-2007, Table C.7-5a
    </DESCRIPTION>
    <PREDICATE>
      <BOOLEAN_FUNC operator="notEmpty">
        <ATTRIBUTE_TAG>00080060</ATTRIBUTE_TAG>
      </BOOLEAN_FUNC>
      <ACTION action="warning" when="false">
        missing attribute 00080060
      </ACTION>
    </PREDICATE>
    <PREDICATE>
      <BOOLEAN_FUNC operator="notEmpty">
        <ATTRIBUTE_TAG>0020000E</ATTRIBUTE_TAG>
      </BOOLEAN_FUNC>
      <ACTION action="warning" when="false">
        missing attribute 0020000E
      </ACTION>
    </PREDICATE>
    <PREDICATE>
      <LOGICAL operator="derive">
        <PREDICATE>
          <BOOLEAN_FUNC operator="notEmpty">
            <ATTRIBUTE_TAG>00400260</ATTRIBUTE_TAG>
          </BOOLEAN_FUNC>
        </PREDICATE>
        <PREDICATE>
          <INVOKE_MACRO>
            <MACRO_NAME>CodeSequenceMacro</MACRO_NAME>
            <PARAMETER>
              <NAME>CodeAttr</NAME>
              <VALUE>00400260</VALUE>
            </PARAMETER>
          </INVOKE_MACRO>
          <ACTION action="warning" when="false">
            missing attribute 00400260.00080100 or 00400260.00080102
          </ACTION>
        </PREDICATE>
      </LOGICAL>
    </PREDICATE>
    <ACTION action="warning" when="false">
      GeneralSeriesModule is not satisfied
    </ACTION>
  </GLOBAL_RULE>

制約マクロCodeSequenceMacroは別の制約ファイルで定義されているため、制約ドキュメントordcmcmd.xmlの先頭で、次のようにインポートしています。

<EXTERNAL_MACRO_INCLUDE name="CodeSequenceMacro">
Defines a code sequence macro</EXTERNAL_MACRO_INCLUDE>

DICOMコンテンツが制約ルールGeneralSeriesModuleに準拠しているかどうかをユーザーがチェックする場合は、制約マクロCodeSequenceMacroに照らしてDICOMコンテンツがチェックされます。このとき、パラメータCodeAttr00400260に置換されます。 具体的には、<ATTRIBUTE_TAG>要素をチェックする条件${CodeAttr}.00080100 not emptyは、00400260.00080100 not emptyになります。 また、<ATTRIBUTE_TAG>要素${CodeAttr}.00080102 not emptyは、00400260.00080102 not emptyになります。

パラメータCodeAttr00400260に置換した制約マクロCodeSequenceMacroがDICOMコンテンツでfalseと評価される場合は、情報ビューorddcm_conformance_vld_msgsに、DICOMコンテンツに対するメッセージ「missing attribute 00400260.00080100 or 00400260.00080102」が含まれます。 これらの準拠の検証メッセージを使用して、DICOMコンテンツに含まれる、制約ルールに準拠していない特定の属性に関する情報を確認できます。

11.2.3 マッピング・ドキュメントとメタデータXMLスキーマの作成

マッピング・ドキュメントでは、DICOM属性をXML文書にマップする方法を定義します。 メタデータXML文書は、XMLスキーマで制約を加えることも、XMLスキーマの制約を指定せずに整形式XML文書にすることも可能です。

XMLスキーマordcmmp.xsdには、マッピング・ドキュメントに制約を加えるXMLスキーマが定義されています。 (マッピング・ドキュメントのスキーマordcmmp.xsdの記述内容は、B.5項を参照してください。)

次の各項では、マッピング・ドキュメントおよびそれに対応するメタデータ・スキーマの作成方法の例を示します。

11.2.3.1 マッピング・ドキュメントの構造

各マッピング・ドキュメントには、次に示すように、ルート要素および名前空間宣言を含める必要があります。

<XML_MAPPING_DOCUMENT xmlns="http://xmlns.oracle.com/ord/dicom/mapping_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">

次に、マッピング・ドキュメントの残りの要素を、出現する順に示します。

  • <dt:DOCUMENT_HEADER>: この要素はオプションです。 XML文書の更新レコードを保持するために使用します。 この要素を指定する場合は、次の名前空間宣言をルート要素に追加してください。

    namespace: xmlns:dt=http://xmlns.oracle.com/ord/dicom/datatype_1_0"
    

    データ型定義のスキーマordcmrdt.xsdの詳細は、B.3項を参照してください。

  • <NAMESPACE>: メタデータXML文書の名前空間を指定する必須要素です。 この名前空間は、対応するメタデータ・スキーマのターゲットの名前空間と一致している必要があります。 この要素が空の場合、抽出されたメタデータXMLはスキーマの制約を受けません。

  • <ROOT_ELEM_TAG>: メタデータXML文書のルート要素名を指定する必須要素です。

  • <UNMAPPED_ELEM>: すべてのアンマップ属性の親要素である要素へのXMLパスを指定する要素です。 このXMLパスは、メタデータXMLの(<ROOT_ELEM_TAG>要素で指定する)ルート要素に対する相対パスです。 この要素を省略または空にした場合は、メタデータXML文書のルート要素がアンマップ属性の親要素になります。 アンマップ属性の詳細は、2.5項を参照してください。

  • <MAPPED_ELEM>: すべてのマップ済属性の親要素である要素へのXMLパスを指定する要素です。 このXMLパスは、メタデータXMLの(<ROOT_ELEM_TAG>要素で指定する)ルート要素に対する相対パスです。 この要素を省略または空にした場合は、メタデータXML文書のルート要素がマップ済属性の親要素になります。 マップ済属性の詳細は、2.5項を参照してください。

  • <MAPPED_PATH>: マップ済属性へのXMLパスを指定する要素です。 このXMLパスは、<MAPPED_ELEM>要素で定義されたマップ済属性の親要素に対する相対パスです。 すべてのマップ済属性へのXMLパスを指定するには、この要素をマッピング・ドキュメント内で複数回使用します。 各<MAPPED_PATH>要素が出現する順番は、メタデータXML文書内でマップ済属性が出現する順番に対応します。 <MAPPED_PATH>要素内では、<ATTRIBUTE_TAG>要素と<PATH>要素を使用して、各マップ済属性のタグとXMLパスをそれぞれ定義します。 マッピング・ドキュメントのスキーマの詳細は、このマニュアルの付録BのB.5項を参照してください。

11.2.3.2 メタデータXMLスキーマの構造

DICOMメタデータを抽出してXML文書にエンコーディングする処理では、DICOM属性をXML文書にエンコーディングするためにマッピング・ドキュメントが使用され、エンコーディング済のメタデータXML文書を検証するためにXMLスキーマが使用されます。 DICOMメタデータをスキーマ妥当性のあるXML文書に抽出するには、メタデータXML文書用のマッピング・ドキュメントとXMLスキーマ定義が同期している必要があります。

特定のアプリケーションに固有のメタデータXML文書に対して、XMLスキーマを作成する際の一般的なルールは次のとおりです。

  • XMLスキーマの要素は、マップされた要素のXMLパスと同じ順番で定義する必要があります。

  • XMLスキーマでは、スキーマordcmmddt.xsdにOracleで定義されたデータ型と互換性があるか、またはOracle定義のデータ型より制約が緩いデータ型を使用する必要があります。

  • アンマップDICOM属性をXML文書に抽出する場合は、アンマップ属性の親要素が(スキーマordcmmddt.xsdと同様に)DATASET_T型として定義されている必要があります。

  • マッピング・ドキュメントで<MAPPED_PATH>要素の属性writeTagwriteNamewriteDefinerおよびwriteRawValue"true"に設定する場合は、マッピング・ドキュメントの<MAPPED_PATH>要素で記述した各要素に対応する属性tagnamedefinerおよびrawValueをXMLスキーマで定義する必要があります。

  • マッピング・ドキュメントで<MAPPED_PATH>要素の属性occursを、暗黙的または明示的に"false"に設定する場合は、その要素のXMLスキーマ定義で属性minOccurs"0"に設定する必要があります。

  • マッピング・ドキュメントで<MAPPED_PATH>要素の属性notEmpty"false"に設定する場合は、その要素のXMLスキーマ定義で属性xsi:nillable"true"に設定する必要があります。 "true"に設定しない場合は、<MAPPED_PATH>要素で定義された要素に空の値を許可する必要があります。

データ型定義のスキーマordcmmddt.xsdの詳細は、B.6項を参照してください。

11.2.3.3 スキーマ制約を指定しないメタデータ用のマッピング・ドキュメント: 例1

この項では、XMLスキーマ制約を指定しないマッピング・ドキュメントおよび整形式メタデータXML文書を作成する方法を説明します。 整形式メタデータXML文書のみを必要とするアプリケーションの場合は、抽出されたメタデータがXMLスキーマに準拠している必要はないため、マッピング・ドキュメントに空の<NAMESPACE>要素を含めることができます。

この項では、マッピング・ドキュメントの例を示し、その後に結果のメタデータXML文書を示します。 マッピング・ドキュメントおよびそれに関連するXML文書の両方で主なアクションが実行される部分を示すために、該当するXML文を太字で強調表示しています。 太字で表示した各XML文の説明は、例の後にあります。

次のマッピング・ドキュメントの例は、空の<NAMESPACE>要素を示しています。 また、抽出されるメタデータXML文書を定義するために、<MAPPED_PATH>要素のoccursnotEmptywriteTagwriteDefinerおよびwriteNameの各属性に指定する値も示しています。 これらの属性が指定されていない場合は、デフォルト値の"false"が属性に設定されます。

<?xml version="1.0" encoding="UTF-8"?>
<XML_MAPPING_DOCUMENT
    xmlns="http://xmlns.oracle.com/ord/dicom/mapping_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">
  <NAMESPACE></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">
    <ATTRIBUTE_TAG>00100010</ATTRIBUTE_TAG>
    <PATH>PATIENT/NAME</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH occurs="true" notEmpty="true">
    <ATTRIBUTE_TAG>00100020</ATTRIBUTE_TAG>
    <PATH>PATIENT/ID</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH occurs="true" notEmpty="false">
    <ATTRIBUTE_TAG>00100030</ATTRIBUTE_TAG>
    <PATH>PATIENT/BIRTH_DATE</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH occurs="false" notEmpty="false">
    <ATTRIBUTE_TAG>00100040</ATTRIBUTE_TAG>
    <PATH>PATIENT/SEX</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH writeTag="true" writeDefiner="true" writeName="true">
    <ATTRIBUTE_TAG>00200010</ATTRIBUTE_TAG>
    <PATH>STUDY/ID</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH>
    <ATTRIBUTE_TAG>00080030</ATTRIBUTE_TAG>
    <PATH>STUDY/TIME</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH>
    <ATTRIBUTE_TAG>00081080</ATTRIBUTE_TAG>
    <PATH>STUDY/ADMITTING_DIAGNOSES_DESCRIPTION</PATH>
  </MAPPED_PATH>

</XML_MAPPING_DOCUMENT>

次の例は、extractMetadata( )メソッドのextractOptionパラメータ値を'MAPPED'に設定して抽出されたXMLメタデータのメタデータXML文書を示しています。

<?xml version="1.0" encoding="DEC-MCS"?>
<DICOM_OBJECT xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <KEY_ATTRIBUTES>
    <PATIENT>
      <NAME>
        <NAME type="unibyte">
          <FAMILY>CANCIO   2HR A-02-013</FAMILY>
        </NAME>
        <VALUE>CANCIO   2HR A-02-013</VALUE>
      </NAME>
      <ID>ISRSCT610b</ID>
      <BIRTH_DATE xsi:nil="true"/>
      <SEX xsi:nil="true"/>
    </PATIENT>
    <STUDY>
      <ID definer="DICOM" tag="00200010" name="Study ID">352</ID>
      <TIME>18:48:41.000000</TIME>
    </STUDY>
  </KEY_ATTRIBUTES>
</DICOM_OBJECT>

前述の例では、次のアクションが実行されます。

  • マッピング・ドキュメントでは、<NAMESPACE>要素が空です。 そのため、抽出されたXML文書はXMLスキーマの制約を受けず、結果のXML文書にはデフォルトの名前空間宣言が含まれません。

  • マッピング・ドキュメントの<ROOT_ELEM_TAG>要素は、抽出されたXML文書の(<DICOM_OBJECT>要素で示されている)ルート要素タグと一致します。

  • マッピング・ドキュメントでは、タグが00100040のDICOM属性に対する<MAPPED_PATH>要素のnotEmpty属性値に"false"が指定されています。 DICOMコンテンツのこのDICOM属性は空であるため、抽出されたXML文書では、<BIRTH_DATE>要素のxsi:nil属性の値に"true"が設定されています。

  • マッピング・ドキュメントでは、タグが00200010のDICOM属性に対する<MAPPED_PATH>要素のwriteTagwriteNameおよびwriteDefiner属性が"true"に設定されています。 抽出されたXML文書では、<STUDY>要素の下の子要素<ID>に、対応するdefinertagおよびname属性が含まれています。

  • マッピング・ドキュメントでは、タグが00081080のDICOM属性に対する<MAPPED_PATH>要素で、occurs要素にデフォルト値("false")が使用されています。 このDICOM属性はDICOMコンテンツ内に存在しないため、抽出されたXML文書には要素<ADMITTING_DIAGNOSES_DESCRIPTION>がありません。

extractMetadata( )メソッド、およびextractOptionパラメータに使用できる値のリファレンス情報は、第5章extractMetadata( )を参照してください。

11.2.3.4 スキーマ制約とマップ済セクションを指定したメタデータ用のマッピング・ドキュメント: 例2

この項では、XMLスキーマ制約を指定したマッピング・ドキュメントおよびメタデータXML文書を、アンマップ・セクションを除外して作成する方法を説明します。 この例は、XMLスキーマ制約を指定したメタデータXML文書で、XMLメタデータのマップ済セクションに定義されているDICOM属性のみを必要とするアプリケーションに使用できます。

この項では、マッピング・ドキュメント、XMLスキーマ、およびスキーマで制約されたメタデータXML文書の結果の例を示します。 マッピング・ドキュメントおよびそれに関連するXML文書の両方で実行される主なアクションの部分を示すために、該当するXML文を太字で強調表示しています。 太字で表示した各XML文の説明は、例の後にあります。

ORDDicomオブジェクトのextractMetadata( )メソッドでは、extractOptionパラメータの値に基づいて、全部または一部のメタデータをXML文書に抽出できます(第5章extractMetadata( )を参照)。

次のマッピング・ドキュメントの例は、メタデータ・ドキュメントをXMLスキーマで制約するために、メタデータXML文書の名前空間をマッピング・ドキュメントに指定する方法を示しています。

<?xml version="1.0" encoding="UTF-8"?>
<XML_MAPPING_DOCUMENT
    xmlns="http://xmlns.oracle.com/ord/dicom/mapping_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">
  <NAMESPACE>http://www.mycompany.com/dicom/example2</NAMESPACE>
  <ROOT_ELEM_TAG>DICOM_OBJECT</ROOT_ELEM_TAG>
  <UNMAPPED_ELEM></UNMAPPED_ELEM>
  <MAPPED_ELEM></MAPPED_ELEM>

  <MAPPED_PATH occurs="true" notEmpty="true">
    <ATTRIBUTE_TAG>00100010</ATTRIBUTE_TAG>
    <PATH>PATIENT/NAME</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH occurs="true" notEmpty="true">
    <ATTRIBUTE_TAG>00100020</ATTRIBUTE_TAG>
    <PATH>PATIENT/ID</PATH>
  </MAPPED_PATH>
  <MAPPED_PATH occurs="true" notEmpty="false">
    <ATTRIBUTE_TAG>00100030</ATTRIBUTE_TAG>
    <PATH>PATIENT/BIRTH_DATE</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH occurs="false" notEmpty="false">
    <ATTRIBUTE_TAG>00100040</ATTRIBUTE_TAG>
    <PATH>PATIENT/SEX</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH writeTag="true" writeDefiner="true" writeName="true">
    <ATTRIBUTE_TAG>00200010</ATTRIBUTE_TAG>
    <PATH>STUDY/ID</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH>
    <ATTRIBUTE_TAG>00080030</ATTRIBUTE_TAG>
    <PATH>STUDY/TIME</PATH>
  </MAPPED_PATH>

   <MAPPED_PATH>
    <ATTRIBUTE_TAG>00081080</ATTRIBUTE_TAG>
    <PATH>STUDY/ADMITTING_DIAGNOSES_DESCRIPTION</PATH>
  </MAPPED_PATH>

</XML_MAPPING_DOCUMENT>

このマッピング・ドキュメントは、次の点で11.2.3.3項のマッピング・ドキュメントと異なります。

  • <NAMESPACE>要素に値が含まれている。

  • <UNMAPPED_ELEM>要素と<MAPPED_ELEM>要素が空であるため、マップ済のパスは<ROOT_ELEM_TAG>要素に対する相対パスになる。

次の例は、このマッピング・ドキュメントに対するXMLスキーマ定義を示しています。

<?xml version="1.0" encoding="UTF-8"?>
 <xs:schema
    xmlns="http://www.mycompany.com/dicom/example2"
    xmlns:xdb="http://xmlns.oracle.com/xdb"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.mycompany.com/dicom/example2"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">
   <xs:element name="DICOM_OBJECT">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="PATIENT">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="NAME" type="PERSON_NAME"/>
              <xs:element name="ID" type="xs:string"/>
              <xs:element name="BIRTH_DATE"  type="xs:date" nillable="true"/>
              <xs:element name="SEX"  type="xs:string" minOccurs="0"
                  nillable="true"/>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
        <xs:element name="STUDY">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="ID" type = "ID_TYPE" minOccurs="0"
                  nillable="true"/>
              <xs:element name="TIME"  type="xs:time" minOccurs="0"
                  nillable="true"/>
              <xs:element name="ADMITTING_DIAGNOSES_DESCRIPTION"  type="xs:string"
                  minOccurs="0" nillable="true"/>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:complexType name="PERSON_NAME">
    <xs:sequence>
      <xs:element name="NAME">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="FAMILY" type="xs:string" minOccurs="0"
                nillable="true"/>
            <xs:element name="GIVEN" type="xs:string" minOccurs="0"
                nillable="true"/>
            <xs:element name="MIDDLE" type="xs:string" minOccurs="0"
                nillable="true"/>
            <xs:element name="PREFIX" type="xs:string" minOccurs="0"
                nillable="true"/>
            <xs:element name="SUFFIX" type="xs:string" minOccurs="0"
                nillable="true"/>
          </xs:sequence>
          <xs:attribute name="type" default="unibyte">
            <xs:simpleType>
              <xs:restriction base="xs:token">
                <xs:enumeration value="unibyte"/>
                <xs:enumeration value="ideographic"/>
                <xs:enumeration value="phonetic"/>
              </xs:restriction>
            </xs:simpleType>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <xs:element name="VALUE" minOccurs="0" nillable="true">
        <xs:simpleType>
          <xs:restriction base="xs:token">
            <xs:maxLength value="64"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:element>
   </xs:sequence>
  </xs:complexType>
  <xs:complexType name="ID_TYPE">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="tag" type="xs:string"/>
        <xs:attribute name="definer" type="xs:string"/>
        <xs:attribute name="name" type="xs:string"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
</xs:schema>

前述の例では、次の要素およびデータ型が定義されています。

  • メタデータのXMLスキーマの名前空間宣言には、マッピング・ドキュメントの<NAMESPACE>要素と同じ値が含まれます。

  • マッピング・ドキュメントの<MAPPED_PATH>要素のnotEmpty属性が、タグ00100030のように明示的に"false"に設定されているか、またはタグ00800030のようにデフォルト値を使用して暗黙的に"false"に設定されている場合、対応する要素のXMLスキーマ定義では、<BIRTH_DATE>要素および<TIME>要素のように、nillable属性の値を"true"に設定します。

  • マッピング・ドキュメントの<MAPPED_PATH>要素のoccurs属性が、タグ00100040のように明示的に"false"に設定されているか、またはタグ00800030のようにデフォルト値を使用して暗黙的に"false"に設定されている場合、対応する要素のXMLスキーマ定義では、<SEX>要素および<TIME>要素のように、minOccurs属性の値を"0"に設定する必要があります。

  • XMLスキーマで定義するデータ型は、スキーマordcmmddt.xsdにOracleで定義されたデータ型と互換性がある必要があります。 例2の"PERSON_NAME"データ型の定義はスキーマordcmmddt.xsdからコピーされます。また、"ID_TYPE"データ型は<STUDY>要素の下の<ID>要素にtagdefinerおよびnameの各属性を含むことができるように定義されています。 "ID_TYPE"データ型は、Oracleによって定義済の"SH_ATTR_T"データ型と互換性があります。 <SEX>要素は"xs:string"データ型を使用するように定義されており、このデータ型はOracle定義のデータ型"CS"と互換性があります。

  • マッピング・ドキュメントの<UNMAPPED_ELEM>要素は空になっており、メタデータXMLのルート要素<DICOM_OBJECT>は"DATASET_T"型として定義されていません。 このスキーマ制約を使用した場合に、妥当なメタデータXML文書に含めることができるのは、マップ済セクションのみです。 したがって、extractOptionパラメータの値に"ALL"または"STANDARD"を指定して、アプリケーションでメタデータを抽出しようとすると、次のエラーが戻されます。

    ORA-53259: スキーマ定義に準拠しているメタデータを抽出できません

次の例は、extractMetadata( )メソッドのextractOptionパラメータ値を'MAPPED'に設定して抽出されたXMLメタデータのメタデータXML文書を示しています。

<?xml version="1.0" encoding="DEC-MCS"?>
<DICOM_OBJECT xmlns="http://www.mycompany.com/dicom/example2"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.mycompany.com/dicom/example2
  http://www.mycompany.com/dicom/example2">
  <PATIENT>
    <NAME>
      <NAME type="unibyte">
        <FAMILY>CANCIO   2HR A-02-013</FAMILY>
      </NAME>
      <VALUE>CANCIO   2HR A-02-013</VALUE>
    </NAME>
    <ID>ISRSCT610b</ID>
    <BIRTH_DATE xsi:nil="true"/>
    <SEX xsi:nil="true"/>
  </PATIENT>
  <STUDY>
    <ID definer="DICOM" tag="00200010" name="Study ID">352</ID>
    <TIME>18:48:41.000000</TIME>
  </STUDY>
</DICOM_OBJECT>

11.2.3.5 スキーマ制約を指定したメタデータ用のマッピング・ドキュメント: 例3

この項では、XMLスキーマ制約を指定したマッピング・ドキュメントおよびメタデータXML文書を、アンマップ・セクションを含めて作成する方法を説明します。

この項では、マッピング・ドキュメント、XMLスキーマ、およびスキーマで制約されたメタデータXML文書の結果の例を示します。 マッピング・ドキュメントおよびそれに関連するXML文書の両方で実行される主なアクションの部分を示すために、該当するXML文を太字で強調表示しています。 太字で表示した各XML文の説明は、例の後にあります。

次のマッピング・ドキュメントの例は、マップ済セクションにあるシーケンス・タイプの属性を含める方法を示しています。

<?xml version="1.0" encoding="UTF-8"?>
<XML_MAPPING_DOCUMENT
    xmlns="http://xmlns.oracle.com/ord/dicom/mapping_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">
  <NAMESPACE>http://www.mycompany.com/dicom/example3</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">
    <ATTRIBUTE_TAG>00100010</ATTRIBUTE_TAG>
    <PATH>PATIENT/NAME</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH occurs="true" notEmpty="true">
    <ATTRIBUTE_TAG>00100020</ATTRIBUTE_TAG>
    <PATH>PATIENT/ID</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH occurs="true" notEmpty="false">
<ATTRIBUTE_TAG>00100030</ATTRIBUTE_TAG>
    <PATH>PATIENT/BIRTH_DATE</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH occurs="false" notEmpty="false">
    <ATTRIBUTE_TAG>00100040</ATTRIBUTE_TAG>
    <PATH>PATIENT/SEX</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH writeTag="true" writeDefiner="true" writeName="true">
    <ATTRIBUTE_TAG>00200010</ATTRIBUTE_TAG>
    <PATH>STUDY/ID</PATH>
  </MAPPED_PATH>

  <MAPPED_PATH>
    <ATTRIBUTE_TAG>00081084</ATTRIBUTE_TAG>
    <PATH>
      STUDY/ADMITTING_DIAGNOSES_CODE_SEQUENCE
    </PATH>
  </MAPPED_PATH>

</XML_MAPPING_DOCUMENT>

このマッピング・ドキュメントは、次の点で11.2.3.4項のマッピング・ドキュメントと異なります。

  • <UNMAPPED_ELEM>要素と<MAPPED_ELEM>要素が空ではない。

  • タグ00081084に対する<MAPPED_PATH>要素があり、DICOMシーケンス・タイプが指定されている。

次の例は、アンマップのルート要素をXMLスキーマに定義して、アンマップ・セクションを抽出されたメタデータXML文書に含める方法を示しています。 また、Oracle定義のデータ型をスキーマordcmmddt.xsdから使用する方法も示しています。

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="http://www.mycompany.com/dicom/example3"
           xmlns:xdb="http://xmlns.oracle.com/xdb"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.mycompany.com/dicom/example3"
           elementFormDefault="qualified"
           attributeFormDefault="unqualified">
  <xs:include schemaLocation="http://www.mycompany.com/dicom/datatype_3"/>
  <xs:element name="DICOM_OBJECT">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="KEY_ATTRIBUTES">
          <xs:complexType>
            <xs:sequence>
             <xs:element name="PATIENT">
               <xs:complexType>
                 <xs:sequence>
                   <xs:element name="NAME" type="PN">
                   </xs:element>
                   <xs:element name="ID" type="xs:string">
                   </xs:element>
                   <xs:element name="BIRTH_DATE" type="xs:date" nillable="true">
                   </xs:element>
                   <xs:element name="SEX" type="xs:string" minOccurs="0"
                       nillable="true">
                   </xs:element>
                 </xs:sequence>
               </xs:complexType>
             </xs:element>
             <xs:element name="STUDY">
               <xs:complexType>
                 <xs:sequence>
                   <xs:element name="ID" type="SH_ATTR_T" minOccurs="0"
                       nillable="true"/>
                   <xs:element name="ADMITTING_DIAGNOSES_CODE_SEQUENCE" type="SQ"
                       nillable="true" minOccurs="0"/>
                 </xs:sequence>
               </xs:complexType>
             </xs:element>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
        </xs:element>
        <xs:element name="OTHER_ATTRIBUTES" type="DATASET_T" minOccurs="0"
            maxOccurs="unbounded">
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

前述の例では、次のアクションが実行されます。

  • このXMLスキーマでは、11.2.3.4項のように独自のデータ型を定義するのではなく、スキーマordcmmddt.xsdをアプリケーション固有のXSDファイルにコピーしてOracle定義のデータ型を使用し、このXMLセグメントで名前空間宣言を変更しています。

    <xs:schema
    xmlns="http://www.mycompany.com/dicom/example3"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:xdb="http://xmlns.oracle.com/xdb"
    targetNamespace="http://www.mycompany.com/dicom/example3"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">
    

    このデータ型のXMLスキーマは、次の名前空間URLを使用してOracle XML DBに登録されています。

    "http://www.mycompany.com/dicom/datatype_3"
    

    したがって、この登録済の名前空間URLは、メタデータXMLスキーマに含まれます。

  • Oracle定義のデータ型はXMLスキーマに含まれるため、<NAME>、<ADMITTING_DIAGNOSES_CODE_SEQUENCE>および<OTHER_ATTRIBUTES>の各要素で示すように、データ型を直接参照できます。

  • <OTHER_ATTRIBUTES>要素は、extractMetadata( )メソッドのextractOptionパラメータ値として"ALL"または"STANDARD"が渡された場合に、アンマップのすべてのDICOM属性をこの要素の下に含めることができるように、"DATASET_T"型として定義されています。 minOccurs属性が"0"に定義されているため、extractMetadata( )メソッドにパラメータ値"MAPPED"が渡されると、抽出されたXML文書にはマップ済セクションのみが含まれます。

次の例は、extractMetadata( )メソッドのextractOptionパラメータ値を'MAPPED'に設定して抽出されたXMLメタデータのメタデータXML文書を示しています。

<?xml version="1.0" encoding="DEC-MCS"?>
<DICOM_OBJECT xmlns="http://www.mycompany.com/dicom/example3"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.mycompany.com/dicom/example3
   http://www.mycompany.com/dicom/example3">
  <KEY_ATTRIBUTES>
    <PATIENT>
      <NAME>
        <NAME type="unibyte">
          <FAMILY>CANCIO   2HR A-02-013</FAMILY>
        </NAME>
        <VALUE>CANCIO   2HR A-02-013</VALUE>
      </NAME>
      <ID>ISRSCT610b</ID>
      <BIRTH_DATE xsi:nil="true"/>
      <SEX xsi:nil="true"/>
    </PATIENT>
    <STUDY>
      <ID definer="DICOM" tag="00200010" name="Study ID">352</ID>
      <ADMITTING_DIAGNOSES_CODE_SEQUENCE>
        <ITEM>
          <SHORT_STRING tag="00080100" definer="DICOM" name="Code Value"
             offset="692" length="0"/>
          <SHORT_STRING tag="00080102" definer="DICOM" name="Coding Scheme
             Designator" offset="700" length="0"/>
          <SHORT_STRING tag="00080103" definer="DICOM" name="Coding Scheme
             Version" offset="708" length="0"/>
          <LONG_STRING tag="00080104" definer="DICOM" name="Code Meaning"
             offset="716" length="0"/>
          <CODE_STRING tag="00080105" definer="DICOM" name="Mapping Resource"
             offset="724" length="0"/>
          <DATE_TIME tag="00080106" definer="DICOM" name="Context Group Version"
             offset="732" length="0" xsi:nil="true" rawValue=""
               byteOrderLE="true"/>
          <DATE_TIME tag="00080107" definer="DICOM" name="Context Group Local
               Version" offset="740" length="0" xsi:nil="true" rawValue=""
               byteOrderLE="true"/>
          <CODE_STRING tag="0008010B" definer="DICOM" name="Context Group
               Extension Flag" offset="748" length="0"/>
          <UNIQUE_ID tag="0008010D" definer="DICOM" name="Context Group Extension
               Creator UID" offset="756" length="0" xsi:nil="true" rawValue=""
               byteOrderLE="true"/>
          <CODE_STRING tag="0008010F" definer="DICOM" name="Context Identifier"
               offset="764" length="0"/>
        </ITEM>
      </ADMITTING_DIAGNOSES_CODE_SEQUENCE>
    </STUDY>
  </KEY_ATTRIBUTES>
</DICOM_OBJECT>

次の例は、extractMetadata( )メソッドのextractOptionパラメータ値を'ALL'に設定して抽出したXMLメタデータのメタデータXML文書を示しています。

<?xml version="1.0" encoding="DEC-MCS"?>
<DICOM_OBJECT xmlns="http://www.mycompany.com/dicom/example3"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.mycompany.com/dicom/example3
   http://www.mycompany.com/dicom/example3">
  <KEY_ATTRIBUTES>
    <PATIENT>
      <NAME>
        <NAME type="unibyte">
          <FAMILY>CANCIO   2HR A-02-013</FAMILY>
        </NAME>
        <VALUE>CANCIO   2HR A-02-013</VALUE>
      </NAME>
      <ID>ISRSCT610b</ID>
      <BIRTH_DATE xsi:nil="true"/>
      <SEX xsi:nil="true"/>
    </PATIENT>
    <STUDY>
      <ID definer="DICOM" tag="00200010" name="Study ID">352</ID>
      <ADMITTING_DIAGNOSES_CODE_SEQUENCE>
        <ITEM>
          <SHORT_STRING tag="00080100" definer="DICOM" name="Code Value"
             offset="692" length="0"/>
          <SHORT_STRING tag="00080102" definer="DICOM" name="Coding Scheme
             Designator" offset="700" length="0"/>
          <SHORT_STRING tag="00080103" definer="DICOM" name="Coding Scheme
             Version" offset="708" length="0"/>
          <LONG_STRING tag="00080104" definer="DICOM" name="Code Meaning"
             offset="716" length="0"/>
          <CODE_STRING tag="00080105" definer="DICOM" name="Mapping Resource"
             offset="724" length="0"/>
          <DATE_TIME tag="00080106" definer="DICOM" name="Context Group Version"
             offset="732" length="0" xsi:nil="true" rawValue=""
             byteOrderLE="true"/>
          <DATE_TIME tag="00080107" definer="DICOM" name="Context Group Local
             Version" offset="740" length="0" xsi:nil="true" rawValue=""
             byteOrderLE="true"/>
          <CODE_STRING tag="0008010B" definer="DICOM" name="Context Group
             Extension Flag" offset="748" length="0"/>
          <UNIQUE_ID tag="0008010D" definer="DICOM" name="Context Group Extension
             Creator UID" offset="756" length="0" xsi:nil="true" rawValue=""
             byteOrderLE="true"/>
          <CODE_STRING tag="0008010F" definer="DICOM" name="Context Identifier"
             offset="764" length="0"/>
        </ITEM>
      </ADMITTING_DIAGNOSES_CODE_SEQUENCE>
    </STUDY>
  </KEY_ATTRIBUTES>
  <OTHER_ATTRIBUTES>
    <OTHER_BYTE tag="00020001" definer="DICOM" name="File Meta Information
       Version" offset="156" length="2">AQA=

</OTHER_BYTE>
    <UNIQUE_ID tag="00020002" definer="DICOM" name="Media Storage SOP Class UID"
       offset="166" length="26">1.2.840.10008.5.1.4.1.1.2</UNIQUE_ID>
    <UNIQUE_ID tag="00020003" definer="DICOM" name="Media Storage SOP Instance
       UID" offset="200" length="54">1.2.392.200036.91</UNIQUE_ID>
    <UNIQUE_ID tag="00020010" definer="DICOM" name="Transfer Syntax UID"
       offset="262" length="18">1.2.840.10008.1.2</UNIQUE_ID>
    <UNIQUE_ID tag="00020012" definer="DICOM" name="Implementation Class UID"
       offset="288" length="16">1.2.804.114118.3</UNIQUE_ID>
<APPLICATION_ENTITY tag="00020016" definer="DICOM" name="Source Application Entity
    Title" offset="326" length="0" xsi:nil="true" rawValue="" byteOrderLE="true"/>
    <CODE_STRING tag="00080008" definer="DICOM" name="Image Type" offset="334"
       length="22">ORIGINAL</CODE_STRING>
    <CODE_STRING tag="00080008" definer="DICOM" name="Image Type" offset="334"
       length="22">PRIMARY</CODE_STRING>
    <CODE_STRING tag="00080008" definer="DICOM" name="Image Type" offset="334"
       length="22">AXIAL</CODE_STRING>
    <UNIQUE_ID tag="00080016" definer="DICOM" name="SOP Class UID" offset="364"
       length="26">1.2.840.10008.5.1.4.1.1.2</UNIQUE_ID>
    <UNIQUE_ID tag="00080018" definer="DICOM" name="SOP Instance UID" offset="398"
       length="54">1.2.392.200036.91</UNIQUE_ID>
    <DATE tag="00080020" definer="DICOM" name="Study Date" offset="460"
   length="8">2004-02-23</DATE>
    <DATE tag="00080022" definer="DICOM" name="Acquisition Date" offset="476"
   length="8">2004-02-23</DATE>
    <DATE tag="00080023" definer="DICOM" name="Content Date" offset="492"
   length="8">2004-02-23</DATE>
    <TIME tag="00080030" definer="DICOM" name="Study Time" offset="508"
   length="14">18:48:41.000000</TIME>
    <TIME tag="00080032" definer="DICOM" name="Acquisition Time" offset="530"
   length="14">18:50:52.100000</TIME>
    <TIME tag="00080033" definer="DICOM" name="Content Time" offset="552"
   length="14">18:50:52.725000</TIME>
    <SHORT_STRING tag="00080050" definer="DICOM" name="Accession Number"
   offset="574" length="4">352</SHORT_STRING>
    <CODE_STRING tag="00080060" definer="DICOM" name="Modality" offset="586"
   length="2">CT</CODE_STRING>
    ……………………….

    <SHORT_STRING tag="00400253" definer="DICOM" name="Performed Procedure Step
      ID" offset="1742" length="4">351</SHORT_STRING>
    <OTHER_WORD tag="7FE00010" definer="DICOM" name="Pixel Data" offset="1766"
      length="524288" truncated="true" xsi:nil="true" endian="little"/>
  </OTHER_ATTRIBUTES>
</DICOM_OBJECT>

11.2.4 標準ディクショナリ・ドキュメントの作成

標準ディクショナリ・ドキュメントは、DICOM標準規格で定義されているデータ・ディクショナリのXML表現です。

XMLスキーマordcmsd.xsdには、標準ディクショナリ・ドキュメントに制約を加えるXMLスキーマが定義されています。 (標準ディクショナリ・ドキュメントのスキーマordcmsd.xsdの記述内容は、B.9項を参照してください。 スキーマ要素の詳細は、<xs: annotation>要素に含まれているテキストを参照してください。)

デフォルトの標準ディクショナリ・ドキュメントordcmsd.xmlは、DICOM標準規格のPart 6に定義されているデータ・ディクショナリのXML表現です。

XMLスキーマordcmrdt.xsdには、DICOM標準規格のデータ型と、これらのデータ型に対するOracleの拡張機能が定義されています。ここで定義されているデータ型は他のすべてのDICOM XMLスキーマで使用されます。 (データ型定義のスキーマordcmrdt.xsdの記述内容は、B.3項を参照してください。)


注意:

標準ディクショナリ・ドキュメントには、NEMA以外のモダリティ・メーカーや組織で定義された属性など、標準規格以外の属性を含めないでください。

新しい標準ディクショナリ・ドキュメントは、DICOM管理者向けのインストール手順とともに、Oracle Technology Networkを通じてOracleからリリースされます。 この新しい標準ディクショナリ・ドキュメントには、DICOM標準規格の新しいリリース内容、または追加項目が反映されます。

次の各項では、標準ディクショナリ・ドキュメントの作成方法の例を示します。

11.2.4.1 標準属性の定義: 例1および例2

標準ディクショナリで標準属性を定義する際には、単純タグおよびワイルドカード・タグの2種類の属性タグを使用できます。 属性タグの値は、グループ番号の後に要素番号を付けて構成します。

単純属性タグは、グループ番号の後に要素番号が続く形で構成される4バイトの16進数です(例: 10871100)。

ワイルドカード属性タグは、一連の16進数を表します。 ワイルドカード属性タグも、グループ番号の後に要素番号が続く形で構成されており、値の一部が文字xまたはXで置き換えられています(例: 1087xx00)。

標準ディクショナリ・ドキュメント内の各標準属性は、<STANDARD_ATTRIBUTE_DEFINITION>要素で表現されます。 XML文書に記述された各標準属性は、DICOM標準規格のPart 6に定義されている関連タグに対応しています。


注意:

定義者名"DICOM"およびUID"1.2.840.10008.1"は、DICOM標準規格の属性を表すものとしてOracleで予約されています。

単純属性タグによる定義: 例1

この例では、単純属性タグで標準属性を定義する方法を示します。 このアクションを定義するXML文は、太字で強調表示しています。

<STANDARD_ATTRIBUTE_DEFINITION>
   <TAG>00080008</TAG>
   <NAME>Image Type</NAME>
   <VR>CS</VR>
   <VM>1-n</VM>
</STANDARD_ATTRIBUTE_DEFINITION>

例1の<TAG>要素は、DICOM標準規格で定義されている属性タグの16進値00080008を表しています。 この属性タグの値は、グループ番号の後に要素番号を続けた形で構成されます。 <NAME>要素は、DICOM標準規格で定義されている属性タグの名前を表します。 <VR>要素は、DICOM標準規格で定義されている属性タグの値表現を表します。 <VM>要素は、DICOM標準規格で定義されている属性タグの値の多重度を表します。 (Oracle Multimedia DICOMでサポートされる値表現および値多重度のデータ型については、XMLスキーマordcmrdt.xsdに記述されている<VR_T>型および<VM_T>型を参照してください。)

ワイルドカード属性タグによる定義: 例2

この例では、ワイルドカード属性タグで標準属性を定義する方法を示します。 このアクションを定義するXML文は、太字で強調表示しています。

<STANDARD_ATTRIBUTE_DEFINITION>
   <TAG>60xx0010</TAG>
   <NAME>Overlay Rows</NAME>
   <VR>US</VR>
   <VM>1</VM>
</STANDARD_ATTRIBUTE_DEFINITION>

例2の標準属性の定義には、ワイルドカード・タグ60xx0010が含まれています。

11.2.4.2 標準属性の廃止: 例3

標準ディクショナリ・ドキュメントに含まれる標準属性がDICOM標準規格で使用されなくなると、その属性は廃止になります。

この例では、廃止になった標準属性の定義を示します。 このアクションを定義するXML文は、太字で強調表示しています。

<STANDARD_ATTRIBUTE_DEFINITION>
   <TAG>00080010</TAG>
   <NAME>Recognition Code</NAME>
   <VR>CS</VR>
   <VM>1</VM>
   <RETIRED>true</RETIRED>
</STANDARD_ATTRIBUTE_DEFINITION>

例3の<RETIRED>要素の値trueは、その属性が廃止であることを示します。この値は、DICOM標準規格で使用されるRET値に対応しています。 廃止の属性には<VR>要素および<VM>要素を指定して、DICOMコンテンツからメタデータを抽出できるようにすることをお薦めします。

11.2.5 プライベート・ディクショナリ・ドキュメントの作成

プライベート・ディクショナリ・ドキュメントは、NEMA以外のモダリティ・メーカーまたは組織で定義された属性が記述されているXML文書です。

プライベート組織またはモダリティ・メーカーは、それぞれの組織に特有の属性を各DICOMコンテンツに含めることができます。 これらのプライベート属性は、プライベート・ディクショナリ・ドキュメントに定義してデータ・モデル・リポジトリに格納し、DICOMコンテンツ内のプライベート属性に関連付けられたメタデータをOracle Multimediaで処理できるようにする必要があります。

XMLスキーマordcmpv.xsdには、プライベート・ディクショナリ・ドキュメントに制約を加えるXMLスキーマが定義されています。 (プライベート・ディクショナリ・ドキュメントのスキーマordcmpv.xsdの記述内容は、B.8項を参照してください。)

デフォルトのプライベート・ディクショナリ・ドキュメントordcmpv.xmlには、Oracleで定義されたプライベート属性が記述されています。

XMLスキーマordcmrdt.xsdには、DICOM標準規格のデータ型と、これらのデータ型に対するOracleの拡張機能が定義されています。ここで定義されているデータ型は他のすべてのDICOM XMLスキーマで使用されます。 (データ型定義のスキーマordcmrdt.xsdの記述内容は、B.3項を参照してください。)

次の各項では、プライベート・ディクショナリ・ドキュメントの作成方法の例を示します。

11.2.5.1 プライベート属性の定義: 例1から3

プライベート・ディクショナリでプライベート属性を定義する際には、単純タグ、ワイルドカード・タグおよび範囲タグの3種類の属性タグを使用できます。 属性タグの値は、グループ番号の後に要素番号を付けて構成します。

単純属性タグは、グループ番号の後に要素番号が続く形で構成される4バイトの16進数です(例: 10871100)。

ワイルドカード属性タグは、一連の16進数を表します。 ワイルドカード属性タグも、グループ番号の後に要素番号が続く形で構成されており、値の一部が文字xまたはXで置き換えられています(例: 1087xx00)。

範囲属性タグは、16進数の範囲を表します。 範囲属性タグは、値の範囲を定義する2つの単純属性タグで構成されます。 範囲の始まりの値は、範囲の終わりの値より小さい値である必要があります。

プライベート・ディクショナリ・ドキュメント内の各プライベート属性は、<PRIVATE_ATTRIBUTE_DEFINITION>要素で表現されます。


注意:

次の追加のガイドラインに留意してください。
  • 範囲属性タグ内では、ワイルドカード属性タグを使用しないでください。

  • 定義者名"DICOM"およびUID"1.2.840.10008.1"は、DICOM標準規格の属性を表すものとしてOracleで予約されています。 これらをプライベート・ディクショナリで使用しないでください。

  • DICOMコンテンツ内のすべてのDICOMプライベート属性には、UIDで修飾された名前を関連付けることをお薦めします。

  • タグ/定義者ペアの値は、プライベート・ディクショナリ・ドキュメント内で一意であることが必要です。


単純属性タグによる定義: 例1

この例では、単純属性タグでプライベート属性を定義する方法を示します。 このアクションを定義するXML文は、太字で強調表示しています。

<PRIVATE_ATTRIBUTE_DEFINITION>
  <TAG>FFFF1001</TAG>
  <NAME>locator macro tag</NAME>
  <DEFINER>ORACLE</DEFINER>
  <VR>SQ</VR>
  <VM>1</VM>
 </PRIVATE_ATTRIBUTE_DEFINITION>

例1の<TAG>要素は、属性タグの16進値FFFF1001を表しています。 <NAME>要素は、タグを定義する組織の名前ORACLEを表します。 <VR>要素は、属性タグの値表現を表します。 <VR>要素は、VR_T型としてXMLスキーマordcmrdt.xsdに定義されています。 <VR>要素の値は、<VR_T>型の値としてXMLスキーマordcmrdt.xsdにリストされている値のいずれかであることが必要です。 <VM>要素は、属性タグの値の多重度を表します。 <VM>要素は、VM_T型としてXMLスキーマordcmrdt.xsdに定義されています。 <VM>要素の値は、VM_T型の値としてXMLスキーマordcmrdt.xsdにリストされている値のいずれかであることが必要です。 (Oracle Multimedia DICOMでサポートされる値表現および値多重度のデータ型については、XMLスキーマordcmrdt.xsdに記述されている<VR_T>型および<VM_T>型を参照してください。)

ワイルドカード属性タグによる定義: 例2

この例では、ワイルドカード属性タグでプライベート属性を定義する方法を示します。 このアクションを定義するXML文は、太字で強調表示しています。

<PRIVATE_ATTRIBUTE_DEFINITION>
   <TAG>0119XX00</TAG>
   <NAME>PRIVATE TAG1</NAME>
   <DEFINER>PRIVATE_ORG</DEFINER>
   <VR>IS</VR>
   <VM>1</VM>
</PRIVATE_ATTRIBUTE_DEFINITION>

例2のプライベート属性定義には、ワイルドカード・タグ0119XX00と定義者名PRIVATE_ORGが含まれています。

範囲属性タグによる定義: 例3

この例では、範囲属性タグでプライベート属性を定義する方法を示します。 このアクションを定義するXML文は、太字で強調表示しています。

<PRIVATE_ATTRIBUTE_DEFINITION>
   <TAG_RANGE>
      <dt:STARTING_TAG>A0110010</dt:STARTING_TAG>
      <dt:ENDING_TAG>A01AAA10</dt:ENDING_TAG>
    </TAG_RANGE>
   <NAME>Private Tag</NAME>
   <DEFINER>1.2.840.423</DEFINER>
   <VR>ST</VR>
   <VM>1</VM>
</PRIVATE_ATTRIBUTE_DEFINITION>

例3のプライベート属性定義には、A0110010からA01AAA10までのすべてのタグ範囲を指定する範囲タグが含まれています。 定義者名1.2.840.423はUID値です。


注意:

プライベート・ディクショナリ・ドキュメント内の他のタグ/定義者ペアの属性定義と一致する属性の定義はできません。

次のXMLセグメントは、プライベート・ディクショナリで使用できない属性定義の例を示しています。

<PRIVATE_ATTRIBUTE_DEFINITION>
  <TAG>0119XX00</TAG>
  <NAME>private tag</NAME>
  <DEFINER>PRIVATE_ORG</DEFINER>
  …
 </PRIVATE_ATTRIBUTE_DEFINITION>

<PRIVATE_ATTRIBUTE_DEFINITION>
  <TAG>01191100</TAG>
  <NAME>private tag</NAME>
  <DEFINER>PRIVATE_ORG</DEFINER>
  …
 </PRIVATE_ATTRIBUTE_DEFINITION>

前述のXMLセグメントでは、タグ/定義者ペア(01191100, PRIVATE_ORG)が、タグ/定義者ペア(0119XX00, PRIVATE_ORG)と一致しています。

11.2.5.2 属性定義者の定義: 例4

属性定義者とは、プライベート属性を定義する組織の定義者名とUIDを指します。

<ATTRIBUTE_DEFINERS>要素は、プライベート・ディクショナリ・ドキュメント内で使用されるすべてのプライベート定義者名と定義者UIDを表すオプションの要素です。


注意:

定義者名"DICOM"およびUID"1.2.840.10008.1"は、DICOM標準規格の属性を表すものとしてOracleで予約されています。 これらをプライベート・ディクショナリで使用しないでください。

<ATTRIBUTE_DEFINERS>要素は、ATTR_DEFINERS_T型です。この型は、XMLスキーマordcmrdt.xsdで定義されています。

次の例は、属性定義者の定義方法を示しています。

<ATTRIBUTE_DEFINERS>
  <dt:ATTR_DEFINER>
   <dt:NAME>1.2.1234.12345.123456.2.0</dt:NAME>
   <dt:UID>1.2.1234.12345.123456.2.0</dt:UID>
  </dt:ATTR_DEFINER>
  <dt:ATTR_DEFINER>
   <dt:NAME>PRIVATE ORG</dt:NAME>
   <dt:UID>1.2.123.1234</dt:UID>
  </dt:ATTR_DEFINER>
 </ATTRIBUTE_DEFINERS>

例4の接頭辞dtは、<ATTR_DEFINER>要素が定義されている名前空間http://xmlns.oracle.com/ord/dicom/datatype_1_0にマップされています。 <dt:NAME>要素の値は、プライベート組織の名前を表します。 <dt:UID>要素の値は、プライベート組織のUIDを表します。

11.2.5.3 プライベート属性の廃止: 例5

プライベート・ディクショナリ・ドキュメントに含まれるプライベート属性が不要になった場合は、廃止にすることができます。

次の例は、プライベート属性を廃止として定義する方法を示しています。 このアクションを定義するXML文は、太字で強調表示しています。

<PRIVATE_ATTRIBUTE_DEFINITION>
   <TAG>01191100</TAG>
   <NAME>locator macro tag</NAME>
   <DEFINER>PRIVATE_ORG</DEFINER>
   <VR>SQ</VR>
   <VM>1</VM>
   <RETIRED>true</RETIRED>
</PRIVATE_ATTRIBUTE_DEFINITION>

<RETIRED>要素の値trueは、その属性が廃止であることを示します。この値は、DICOM標準規格で使用されるRET値に対応しています。 廃止の属性には<VR>要素および<VM>要素を指定して、DICOMコンテンツからメタデータを抽出できるようにすることをお薦めします。

11.2.6 プリファレンス・ドキュメントの作成

プリファレンス・ドキュメントは、Oracle Multimedia DICOMの実行時の動作を定義するプリファレンス・セットが記述されたXML文書です。

XMLスキーマordcmpf.xsdには、プリファレンス・ドキュメントに制約を加えるXMLスキーマが定義されています。 (プリファレンス・ドキュメントのスキーマordcmpf.xsdの記述内容は、B.7項を参照してください。 プリファレンス・パラメータおよびパラメータの有効な値の詳細は、<xs: annotation>要素に含まれているテキストを参照してください。)

デフォルトのプリファレンス・ドキュメントordcmpf.xmlには、Oracle Multimedia DICOMを実行する際のプリファレンス・パラメータのデフォルト値が含まれています。

プリファレンス・ドキュメント内の各プリファレンス値は、<PREFERENCE_DEF>要素で定義します。


注意:

次の追加のガイドラインに留意してください。
  • リポジトリ内には、最大2つ(Oracle定義およびユーザー定義を1つずつ)のプリファレンス・ドキュメントを保持できます。

  • プリファレンス・ドキュメント内の値を変更すると、DICOMメソッド、ファンクションおよびプロシージャの動作が変わります。 具体的には、Oracle定義のプリファレンス・ドキュメントordcmpf.xmlに定義されたデフォルト値が、ユーザー定義のプリファレンス・ドキュメントに定義されたプリファレンス値によって上書きされます。

  • すべてのプリファレンス・パラメータ名およびパラメータに関連付けられた値は、Oracleによって定義済です。 ユーザー定義のプリファレンス・ドキュメントを使用して、Oracle定義のプリファレンス・パラメータの値を変更できます。


次の項では、プリファレンス・ドキュメントの作成方法の例を示します。

11.2.6.1 プリファレンスの定義: 例1

この例は、プリファレンス・ドキュメントでVALIDATE_METADATAプリファレンス・パラメータを定義する方法を示しています。 このアクションを定義するXML文は、太字で強調表示しています。

  <PREFERENCE_DEF>
    <PARAMETER>VALIDATE_METADATA</PARAMETER>
    <DESCRIPTION>Validate XML Metadata document</DESCRIPTION>
    <VALUE>true</VALUE>
 </PREFERENCE_DEF>

例1の<PARAMETER>要素では、Oracle定義のパラメータVALIDATE_METADATAを指定しています。

<VALUE>要素は、パラメータVALIDATE_METADATAの値を表します。この値がextractMetadata( )メソッドに渡されます。 extractMetadata( )メソッドでは、入力としてマッピング・ドキュメントを受け入れます。 マッピング・ドキュメントには、namespaceパラメータが含まれます(空にすることもできます)。 マッピング・ドキュメントで指定された名前空間にXMLスキーマが登録されており、VALIDATE_METADATAパラメータの値がtrueの場合、extractMetadata( )メソッドでは、指定されたXMLスキーマに対して結果のXML文書が検証されます。 VALIDATE_METADATAパラメータの値がfalseの場合、結果のXML文書はスキーマに対して検証されません。

11.2.7 UID定義ドキュメントの作成

UID定義ドキュメントは、DICOM標準規格で定義されている一意識別子(UID)のXML表現です。 Oracle Multimedia DICOMでは、UID定義を使用してDICOMコンテンツが解析されます。

XMLスキーマordcmui.xsdには、UID定義ドキュメントに制約を加えるXMLスキーマが定義されています。 (UID定義ドキュメント・スキーマordcmui.xsdの記述内容は、B.10項を参照してください。 スキーマで使用される属性の詳細は、<xs: annotation>要素に含まれているテキストを参照してください。)

デフォルトのUID定義ドキュメント(ordcmui.xml)には、DICOM標準規格のPart 6に記述されているUIDが含まれています。

UID定義ドキュメント内の各UID定義は、<UID_DEF>要素で定義します。


注意:

次の追加のガイドラインに留意してください。
  • リポジトリ内には、最大2つ(Oracle定義およびユーザー定義を1つずつ)のUID定義ドキュメントを保持できます。

  • ユーザー定義のUID定義ドキュメントに対する変更は、DICOM標準規格の更新または新しいUID値の追加を行う目的のみに制限する必要があります。 定義済の一意識別子を独自に作成する方法については、DICOM標準規格のPart 5を参照してください。

  • DICOM標準規格で定義されている既存のUIDは、DICOM標準規格での更新を反映する場合のみ変更できます。


次の各項では、UID定義ドキュメントのUID定義を作成する方法の例を示します。

11.2.7.1 UID定義の定義: 例1

この例は、記憶域クラスのUID定義を定義する方法を示しています。 このアクションを定義するXML文は、太字で強調表示しています。

 <UID_DEF classification="storageClass" contentType="image">
    <UID>1.2.840.10008.5.1.4.1.1.2</UID>
    <NAME>CT Image Storage</NAME>
  </UID_DEF>

例1の<UID>要素の値1.2.840.10008.5.1.4.1.1.2は、DICOM標準規格で定義されているUID値を表しています。 <NAME>要素の値CT Image Storageは、DICOM標準規格で定義されているUID名を表しています。 <UID_DEF>要素のclassification属性の値"storageClass"は、DICOM標準規格で定義されているUID型のSOPクラスに対応しています。 contentType属性の値"image"は、DICOMコンテンツにピクセル・データが含まれることを示しています。

11.2.7.2 UID定義の廃止: 例2

この例は、転送構文のUID定義を廃止として定義する方法を示しています。 このアクションを定義するXML文は、太字で強調表示しています。

 <UID_DEF classification="transferSyntax" isCompressed="true" isEVR="true"
          isLE="true" retired="true">
    <UID>1.2.840.10008.1.2.4.52</UID>
    <NAME>JPEG Extended (Process 3 and 5) (Retired)</NAME>
  </UID_DEF>

例2の<UID>要素の値1.2.840.10008.1.2.4.52は、DICOM標準規格で定義されているUID値を表しています。 <NAME>要素の値JPEG Extended (Process 3 and 5) (Retired)は、DICOM標準規格で定義されているUID名を表しています。 classification属性の値"transferSyntax"は、DICOM標準規格で定義されているUID型の転送構文に対応しています。 isCompressedisEVR(明示的なVR)およびisLE(リトル・エンディアン)の各属性値は、DICOM標準規格のPart 5に記述されている転送構文の定義から導出されたものです。 retired属性の値"true"は、このUID定義が廃止されていることを示しています。