| Oracle® Multimedia DICOM Developer's Guide 11g Release 1 (11.1) Part Number B28416-01 |
|
|
View PDF |
| Oracle® Multimedia DICOM Developer's Guide 11g Release 1 (11.1) Part Number B28416-01 |
|
|
View PDF |
Administrators can perform a number of repository management tasks, including creating their own configuration documents. This chapter describes the characteristics of configuration documents and provides instructions on how to write configuration documents that are specific to a particular organization or enterprise. See Chapter 8 for information about other repository management tasks.
This chapter includes the following sections:
Note:
In this chapter, names of attributes for XML elements appear in monospace type.After installation, the Oracle Multimedia DICOM data model repository contains the following set of default configuration documents:
Anonymity (ordcman.xml) - This document defines the actions required to make specific DICOM attributes anonymous.
Constraint (ordcmct.xml, ordcmcmd.xml, ordcmcmc.xml) - These documents define the rules to check the conformance of DICOM content, with respect to the DICOM standard and other organization-wide guidelines.
Mapping (ordcmmp.xml) - This document defines how each DICOM attribute maps to an element of the DICOM metadata document.
Standard Dictionary (ordcmsd.xml) - This document lists the registry of DICOM data elements, as defined by the DICOM standard.
Private Dictionary (ordcmpv.xml) - This document includes a registry of private data elements, as defined by equipment manufacturers or enterprises.
Preference (ordcmpf.xml) - This document includes the run-time preference values for Oracle Multimedia DICOM features.
UID Definition (ordcmui.xml) - This document lists and categorizes the registry of DICOM unique identifiers (UIDs), as defined by the DICOM standard.
Each type of configuration document has a specific set of characteristics, which are described briefly in the following sections. See Chapter 8 for more information about inserting, updating, and deleting configuration documents. See Chapter 10 for examples of these processes.
Anonymity documents have the following characteristics:
No other document types depend on anonymity documents.
There are no dependencies between anonymity documents.
Anonymity documents depend on the standard and private dictionary documents.
There is no maximum limit on the number of anonymity documents in the repository.
Changes made to anonymity documents affect the results of the isAnonymous( ) and makeAnonymous( ) methods.
Constraint documents have the following characteristics:
No other document types depend on constraint documents.
There may be dependencies between constraint documents.
Constraint documents depend on the standard and private dictionary documents as well as the preference document.
There is no limit on the number of constraint documents in the repository.
Constraint documents can be written in such a way that later constraint documents depend on previously inserted constraint documents. As an example using installed constraint documents, ordcmct.xml depends on ordcmcmd.xml, and both of those documents depend on ordcmcmc.xml.
The isConformanceValid( ) method depends on the specified constraint rule and the DICOM content. If the constraint rule (defined in a constraint document) is changed, the DICOM content may be validated differently.
The EXP_IF_NULL_ATTR_IN_CONSTRAINT parameter in the preference document is used to specify whether to raise an exception when it encounters a null value for the attributes specified in the constraint rules. If the parameter is set to true, the isConformanceValid( ) method raises an exception; otherwise, the predicate that was encountered is evaluated to false.
Mapping documents have the following characteristics:
No other document types depend on mapping documents.
There are no dependencies between mapping documents.
Mapping documents depend on the standard and private dictionary documents as well as the preference document.
There is no limit on the number of mapping documents in the repository.
Changes made to mapping documents affect the results of the extractMetadata( ) method, when the mapping document is used as a parameter.
If a mapping document specifies a metadata XML namespace, the metadata XML schema that corresponds to that mapping document must be registered and consistent with the mapping document to enable the extractMetadata( ) method to function correctly.
Extracted metadata is schema validated only if both of the following conditions exist:
The mapping document provides an XML schema namespace.
The value of the VALIDATE_METADATA parameter in the preference document is true (the default).
Standard dictionary documents have the following characteristics:
One standard dictionary document (ordcmsd.xml) is installed by Oracle.
Changes to standard dictionary documents must be limited to updates in the DICOM standard.
There is no limit on the number of standard dictionary documents in the repository.
Private dictionary documents have the following characteristics:
One private dictionary document (ordcmpv.xml) is installed by Oracle.
There is no limit on the number of private dictionary documents in the repository.
Preference documents have the following characteristics:
A maximum of two (one Oracle-defined and one user-defined) preference documents are allowed in the repository. The installed, Oracle-defined preference document (ordcmpf.xml) includes Oracle-fixed parameter names and lists of values. The user-defined preference document can update the default preference document values that were set in the Oracle-defined preference document.
Changes to values in preference documents change the behavior of DICOM methods, functions, and procedures. Specifically, preference values that are defined in the user-defined preference document override the default values defined in the Oracle-defined preference document.
UID definition documents have the following characteristics:
A maximum of two (one Oracle-defined and one user-defined) UID definition documents are allowed in the repository. The installed, Oracle-defined UID definition document (ordcmui.xml) includes the UID definitions listed in Part 6 of the DICOM standard.
Changes to user-defined UID definition documents must be limited to updates in the DICOM standard or additions of new UID values.
Note:
Existing UID values must not be changed.Administrators can create one or more configuration documents to support specific applications or organizations. The following subsections describe how to create each type of configuration document.
Anonymity documents specify the set of attributes to be made anonymous, and the actions to be taken to make those attributes anonymous. In the ORDDicom object, anonymity documents are used by the methods isAnonymous( ) and makeAnonymous( ) to create new objects in which personally identifying information has been removed or replaced.
The XML schema ordcman.xsd defines the XML schema that constrains anonymity documents. (See Section B.1 for a listing of the anonymity document schema ordcman.xsd.)
The default anonymity document, ordcman.xml, lists a subset of the attributes defined in the Basic Application Level Confidentiality Profile in Part 15 of the DICOM standard. These attributes are either removed or replaced with the string "anonymous" in the DICOM content. In addition, the default anonymity document removes all undefined standard attributes and all private attributes from the DICOM content.
Within each anonymity document, the <ANONYMITY_ACTION> element includes an action attribute. The value of the action attribute can apply to a single attribute or to a set of attributes within that anonymity document. Global actions apply to a set of attributes, such as all private attributes.
The following table lists the values that are allowed for the action attribute:
| Value | Description |
|---|---|
none |
No action is taken. The unchanged value of the specified attribute or the set of attributes appears in the resulting DICOM content. |
remove |
The default value. The specified attribute or the set of attributes is removed from the resulting DICOM content.
Note: Some imaging applications may depend on certain attributes (for example: |
replace |
The attribute value is replaced by the specified value in the resulting DICOM content. The specified replacement value must be a string representation that matches the data type of the tag as defined by the <VR> element in the data dictionaries.
Note: This action value is not allowed for global actions. For example: The standard tag The standard tag |
Attributes in anonymity documents can be standard or private. Standard and private attributes can be either defined or undefined. Defined standard attributes are defined in the DICOM standard and in the standard dictionary in the data model repository. Defined private attributes are defined by and specific to a particular organization. Defined private attributes known to Oracle Multimedia are defined in the private dictionary in the data model repository. Undefined attributes are defined in neither the standard dictionary nor the private dictionary in the data model repository.
The <INDIVIDUAL_ATTRIBUTE> element defines the action taken to make a defined standard or private attribute anonymous. For private attributes, the action specified in this element always overrides the global action defined by the <PRIVATE_ATTRIBUTES> element. In addition, standard or private attributes that are undefined cannot be specified as <INDIVIDUAL_ATTRIBUTE> element values in an anonymity document.
The following table describes the elements that define the global actions in the anonymity document:
| Element | Description |
|---|---|
| <PRIVATE_ATTRIBUTES> | Specifies the action performed on all defined and undefined private attributes.
Note: The action for a private attribute defined by the <INDIVIDUAL_ATTRIBUTE> element always overrides the global action defined by the <PRIVATE_ATTRIBUTES> element. |
| <UNDEFINED_STANDARD_ATTRIBUTES> | Specifies the action performed on all standard attributes that are not defined in the standard dictionaries in the data model repository.
A DICOM attribute tag contains a group number and an element number. A standard attribute tag is identified by an even-numbered group number. |
| <UNDEFINED_PRIVATE_ATRIBUTES> | Specifies the action performed on all private attributes that are not defined in the private dictionaries in the data model repository.
Note: The action value defined by this element takes precedence over the action value defined by the <PRIVATE_ATTRIBUTES > element. |
Examples of valid values for an <ATTRIBUTE_TAG> element are as follows: 00100010, 00100010(DICOM), 10871100(PRIVATE ORG).
Note:
Currently, only the following values are allowed for the definer name in a private attribute:The uppercase and lowercase letters A-Z
The numbers 0-9
The characters: '.', ' ' (space), and '/'
The following subsections contain examples that show how to create anonymity documents.
This example shows how to replace the standard attribute Patient's Name with specified values that make that attribute anonymous in the resulting DICOM content. The XML statements where these actions are defined are highlighted in bold.
<INDIVIDUAL_ATTRIBUTE> <ATTRIBUTE_TAG>00100010</ATTRIBUTE_TAG> <DESCRIPTION>Patient's Name </DESCRIPTION> <ANONYMITY_ACTION action="replace">anonymous</ANONYMITY_ACTION> </INDIVIDUAL_ATTRIBUTE>
The <ATTRIBUTE_TAG> value 00100010 is defined in the standard dictionary in the data model repository. If the definer name is not specified in the <ATTRIBUTE_TAG> value, the default value of "DICOM" is assumed. The value of the 00100010 tag is replaced with the value "anonymous" in the resulting DICOM content.
The following example defines the standard attribute tag 00100010 in the standard dictionary:
<STANDARD_ATTRIBUTE_DEFINITION> <TAG>00100010</TAG> <NAME>Patient's Name</NAME> <VR>PN</VR> <VM>1</VM> </STANDARD_ATTRIBUTE_DEFINITION>
This tag definition represents the standard attribute Patient's Name, of data type PN as defined by the <VR> element. The <VR> element is the value representation element used to specify standard data types, as defined by the DICOM standard (in Part 5). The data type PN is defined in the XML schema ordcmrdt.xsd. The replacement value for the attribute Patient's Name must be a string representation of the value defined by the <VR> element.
This example shows how to replace the private attribute 10871100(PRIVATE ORG) with specified values that make that attribute anonymous in the resulting DICOM content. The XML statements where these actions are defined are highlighted in bold.
<INDIVIDUAL_ATTRIBUTE> <ATTRIBUTE_TAG>10871100(PRIVATE ORG)</ATTRIBUTE_TAG> <DESCRIPTION>Media Type </DESCRIPTION> <ANONYMITY_ACTION action="replace"> replaced</ANONYMITY_ACTION> </INDIVIDUAL_ATTRIBUTE>
The <ATTRIBUTE_TAG> value 10871100 with the definer name PRIVATE ORG must be defined in a private dictionary in the data model repository. The value of the private attribute 10871100(PRIVATE ORG) is replaced with the specified value in the resulting DICOM content.
In the following example, assume that the private dictionary tag 10871100 is defined as follows:
<PRIVATE_ATTRIBUTE_DEFINITION> <TAG>10871100</TAG> <NAME>Media Type</NAME> <DEFINER>PRIVATE ORG</DEFINER> <VR>CS</VR> <VM>1</VM> </PRIVATE_ATTRIBUTE_DEFINITION>
This tag definition represents the private attribute 10871100(PRIVATE ORG), of data type CS and name Media Type as defined by the <VR> element. The data type CS is defined in the XML schema ordcmrdt.xsd as xs:token of length 16. The replacement value must be a string representation that conforms to the value defined by the <VR> element.
These examples show how to make a number of private attributes anonymous by removing or replacing those attributes with specified values that make them anonymous in the resulting DICOM content.
Note:
Keep the following guidelines in mind:The action value for a specified private attribute defined by the <INDIVIDUAL_ATTRIBUTE> element always overrides the global action defined by the <PRIVATE_ATTRIBUTES> element.
The global action specified by the <UNDEFINED_PRIVATE_ATTRIBUTES> element overrides the global action defined by the <PRIVATE_ATTRIBUTE> element.
The following example uses the action value remove to remove all the private attributes in the resulting DICOM content.
<PRIVATE_ATTRIBUTES action="remove"></PRIVATE_ATTRIBUTES> <UNDEFINED_PRIVATE_ATTRIBUTES action="remove" />
The following example uses the action value remove to remove all the undefined private attributes from the resulting DICOM content. And, this example uses the action value replace to replace the value of the tag for the defined private attribute 10871100(PRIVATE ORG) with the string "anonymous" in the resulting DICOM content. The XML statements where these actions are defined are highlighted in bold.
<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>
The following example uses the action value none to include all defined private attributes in the resulting DICOM content. And, this example uses the action value remove to remove all undefined private attributes from the resulting DICOM content.
<PRIVATE_ATTRIBUTES action="none"></PRIVATE_ATTRIBUTES> <UNDEFINED_PRIVATE_ATTRIBUTES action="remove" />
The following example uses the action value remove to remove all the defined private attributes from the resulting DICOM content. And, this example uses the action value none to include all undefined private attributes in the resulting DICOM content.
<PRIVATE_ATTRIBUTES action="remove"></PRIVATE_ATTRIBUTES> <UNDEFINED_PRIVATE_ATTRIBUTES action="none" />
Constraint documents define one or more constraint rules. The XML schema ordcmct.xsd defines the XML schema that constrains constraint documents. (See Section B.2 for a listing of the constraint document schema ordcmct.xsd.)
The default constraint documents (ordcmct.xml, ordcmcmd.xml, ordcmcmc.xml), are XML representations of the rules to check the conformance of DICOM content, with respect to the DICOM standard and other organization-wide guidelines.
At run time, users can invoke a PL/SQL or Java function to check the conformance of DICOM content with respect to one or more invokable constraint rules. Each invokable constraint rule is defined as a global rule (using the <GLOBAL_RULE> element). Global rules are constraint rules that define requirements to be met by the DICOM content.
Constraint rules can comprise individual predicates. Predicates define conditions on DICOM content. A predicate can be a logical statement, a relational statement that compares values, a function call evaluation that returns a Boolean type, or a reference to other predicate definitions. Predicate definitions are recursive. For example, when used as a logical statement, a predicate includes the logical OR of two other predicates. Each of the other predicates, in turn, can be a relational predicate.
Constraint macros can be used to simplify the definition of complex constraint rules. Each constraint macro can be defined as a global macro (using the <GLOBAL_MACRO> element). Constraint macros follow the same predicate definition grammar as constraint rules. They differ from constraint rules in that the predicate operands in constraint macros can contain macro parameters rather than the fixed values contained in constraint rules. The macro parameters in a constraint macro are replaced with parameter values when the macro is invoked (using the <INVOKE_MACRO> element).
Constraint definitions can be separated into multiple constraint document files, with each constraint file defining one or more constraint rules or constraint macros. Global rules and global macros can reference other internal and external global rules and global macros. Internal rules and internal macros are defined within the same constraint file. External rules and external macros are imported from other constraint document files that define those rules and macros. Before referencing a set of external constraint rules or external constraint macros in your constraint file, you must specify those rules or macros in your file (using the <EXTERNAL_RULE_INCLUDE> element or the <EXTERNAL_MACRO_INCLUDE> element, respectively). In addition, DICOM administrators must insert the referenced constraint document files into the repository before inserting the referencing constraint files.
In the XML constraint schema ordcmct.xsd, <ACTION> elements are defined to associate conformance validation messages with a predicate, a constraint rule, or a constraint macro. If predicates are evaluated to the conditions specified in the <ACTION> elements associated with the predicates, you can see these messages after conformance validation by querying the information view orddcm_conformance_vld_msgs. (See orddcm_conformance_vld_msgs in Chapter 4 for reference information about this information view.)
The following subsections contain examples that show how to create constraint documents.
This example shows how to construct a simple constraint rule that checks two conditions required by the SOP Common Module, which is defined in the DICOM standard, in PS 3.3-2007, Table C.12-1. The following table shows the SOP Class UID and SOP Instance UID conditions as they are defined in the SOP Common Module of the DICOM standard.
| Attribute Name | Tag | Type | Attribute Description |
|---|---|---|---|
| SOP Class UID | (0008,0016) | 1 | Uniquely identifies the SOP Class. See C.12.1.1.1 for further explanation. See also PS 3.4. |
| SOP Instance UID | (0008,0018) | 1 | Uniquely identifies the SOP Instance. See C.12.1.1.1 for further explanation. See also PS 3.4. |
The two entries in the preceding table indicate that the attributes SOP Class UID (0008,0016) and SOP Instance UID (0008,0018) must exist and cannot be empty.
The following predicate checks whether the attribute SOP Class UID (0008,0016) is not empty:
<PREDICATE>
<BOOLEAN_FUNC operator="notEmpty">
<ATTRIBUTE_TAG>00080016</ATTRIBUTE_TAG>
</BOOLEAN_FUNC>
</PREDICATE>
The following predicate checks whether the attribute SOP Instance UID (0008,0018) is not empty:
<PREDICATE>
<BOOLEAN_FUNC operator="notEmpty">
<ATTRIBUTE_TAG>00080018</ATTRIBUTE_TAG>
</BOOLEAN_FUNC>
</PREDICATE>
Checking whether both of these attributes are not empty is equivalent to doing a logical AND operation for the two preceding predicates. The prescribed way to undertake this operation is to define another predicate that performs a logical AND operation on the preceding two predicates, as follows:
<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>
A simpler way to define predicates having logical AND relations is by omitting the outer predicate. Thus, taking the complete constraint rule from the constraint document ordcmcmd.xml, the global rule SOPCommonModule can be defined as follows:
<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>
Each global rule must have a unique name. Furthermore, each global rule can include an optional <DESCRIPTION> element to provide descriptive information about that rule.
The preceding example shows how to define predicates that represent logical relations or Boolean functions. Predicates that represent relational relations can be defined similarly.
This example shows how to construct constraint rules hierarchically by referencing other external constraint rules, as well as how to reference external constraint rules.
The constraint document ordcmct.xml defines the global rule OracleOrdObject. This constraint rule is defined as the logical AND of three constraint rules: SOPCommonModule, GeneralSeriesModule, and GeneralStudyModule, as shown in the following example:
<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>
These three constraint rules are defined in the constraint document ordcmcmd.xml and imported into the DICOM constraint document ordcmct.xml by the following external rule statement:
<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>
In Example 2, the global rule OracleOrdObject references the global rule SOPCommonModule that is defined in Example 1. Other constraint rules can also reference the global rule SOPCommonModule. In this way, constraint documents can be written in a modular and structured fashion.
This example shows how to construct a constraint macro that checks whether or not a DICOM attribute is a code sequence attribute by following the first two conditions required by the Code Sequence Macro, which is defined in the DICOM standard, in PS 3.3-2007, Table 8.8-1. The following table shows the Code Value and Coding Scheme Designator conditions as they are defined in the Code Sequence Macro of the DICOM standard.
| Attribute Name | Tag | Type | Attribute Description |
|---|---|---|---|
| Code Value | (0008,0100) | 1C | See Section 8.1. Required if a sequence item is present. |
| Coding Scheme Designator | (0008,0102) | 1C | See Section 8.2. Required if a sequence item is present. |
The two entries in the preceding table indicate that the mandatory child attributes Code Value (0008,0100) and Coding Scheme Designator (0008,0102) must not be empty.
The following global macro definition (see the constraint document ordcmcmc.xml) checks whether the attributes Code Value (0008,0100) and Coding Scheme Designator (0008,0102) are not empty:
<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>
Predicates that are included in constraint macros include operands that contain parameters. These parameters must be defined in <PARAMETER_DECLARATION> elements. When the parameters are referenced in these operands, the parameters must be preceded by the dollar sign symbol and enclosed within braces as in: ${ }. In the preceding example, the parameter CodeAttr represents the code sequence to be examined. Thus, checking whether the code value of the parameter CodeAttr is not empty is equivalent to checking whether the parameter ${CodeAttr}.00080100 is not empty.
Constraint macros can be invoked by one or more constraint rules, with the macro parameters being set to different values. To invoke a constraint macro, you must specify the name of the macro with the name value pairs of all the parameters for that macro.
The following example shows the definition for the global rule GeneralSeriesModule (in the constraint document ordcmcmd.xml), which invokes the constraint macro CodeSequenceMacro. The code segment where this macro is invoked is highlighted in bold.
<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>
Because the constraint macro CodeSequenceMacro is defined in a different constraint file, it is imported in the beginning of the constraint document ordcmcmd.xml, as follows:
<EXTERNAL_MACRO_INCLUDE name="CodeSequenceMacro"> Defines a code sequence macro</EXTERNAL_MACRO_INCLUDE>
When users check whether the DICOM content conforms to the constraint rule GeneralSeriesModule, the DICOM content is checked against the constraint macro CodeSequenceMacro, where the parameter CodeAttr is substituted as 00400260. Specifically, the predicate to check the <ATTRIBUTE_TAG> element ${CodeAttr}.00080100 not empty becomes 00400260.00080100 not empty. And, the <ATTRIBUTE_TAG> element ${CodeAttr}.00080102 not empty becomes 00400260.00080102 not empty.
If the constraint macro CodeSequenceMacro with the parameter CodeAttr substituted as 00400260 evaluates to false on the DICOM content, the information view orddcm_conformance_vld_msgs contains the message "missing attribute 00400260.00080100 or 00400260.00080102" for the DICOM content. These conformance validation messages can be used to provide information about specific attributes in the DICOM content that do not conform to the constraint rules.
Mapping documents define how the DICOM attributes are mapped into an XML document. The metadata XML document can be constrained by an XML schema, or it can be a well-formed XML document with no XML schema constraints.
The XML schema ordcmmp.xsd defines the XML schema that constrains mapping documents. (See Section B.5 for a listing of the mapping document schema ordcmmp.xsd.)
The following subsections contain examples that show how to create mapping documents and corresponding metadata schemas.
Each mapping document must include a root element and a namespace declaration, similar to the following:
<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">
The remaining elements in the mapping document, in order of appearance, are as follows:
<dt:DOCUMENT_HEADER>: This element is optional. It is used to keep the update record of the XML document. If this element is specified, add the following namespace declaration to the root element:
namespace: xmlns:dt=http://xmlns.oracle.com/ord/dicom/datatype_1_0"
See Section B.3 for details about the data type definition schema ordcmrdt.xsd.
<NAMESPACE>: This mandatory element specifies the namespace of the metadata XML document. This namespace should match the target namespace of the corresponding metadata schema. If this element is empty, the extracted metadata XML is not schema constrained.
<ROOT_ELEM_TAG>: This mandatory element specifies the root element name of the metadata XML document.
<UNMAPPED_ELEM>: This element specifies the XML path to the element that is the parent element of all the unmapped attributes. This XML path is relative to the root element (specified by the element <ROOT_ELEM_TAG>) of the metadata XML. If this element is omitted or empty, the parent element of the unmapped attributes is the root element of the metadata XML document. See Section 2.5 for information about unmapped attributes.
<MAPPED_ELEM>: This element specifies the XML path to the element that is the parent element of all the mapped attributes. This XML path is relative to the root element of the metadata XML (specified by the element <ROOT_ELEM_TAG>). If this element is omitted or empty, the parent element of the mapped attributes is the root element of the metadata XML document. See Section 2.5 for information about mapped attributes.
<MAPPED_PATH>: This element specifies the XML path to a mapped attribute. This XML path is relative to the parent element of the mapped attributes as defined by the element <MAPPED_ELEM>. This element can be used multiple times within a mapping document to specify the XML paths to all the mapped attributes. The order of appearance of each <MAPPED_PATH> element reflects the order of appearance of the mapped attributes in a metadata XML document. Within the <MAPPED_PATH> element, the <ATTRIBUTE_TAG> and <PATH> elements are used to define each mapped attribute tag and its XML path, respectively. See Section B.5 in Appendix B of this guide for details about the mapping document schema.
During the process of extracting DICOM metadata and encoding it into an XML document, a mapping document is used to encode the DICOM attributes into an XML document, and an XML schema is used to validate the encoded metadata XML document. To extract DICOM metadata into a schema-valid XML document, the mapping document and the XML schema definition for the metadata XML document must be synchronized.
The general rules for creating an XML schema for a metadata XML document that is specific to a particular application are as follows:
The order of the elements defined in the XML schema must match the order of the mapped XML paths for those elements.
The XML schema must use data types that are either compatible with or less restrictive than the data types defined by Oracle in the schema ordcmmddt.xsd.
To extract unmapped DICOM attributes into the XML document, the parent element of the unmapped attributes must be defined as type DATASET_T (as in the schema ordcmmddt.xsd).
If the attributes writeTag, writeName, writeDefiner, and writeRawValue of the <MAPPED_PATH> element are set to "true" in the mapping document, the XML schema must define the corresponding attributes tag, name, definer, and rawValue for each element that is described by the <MAPPED_PATH> element in the mapping document.
If the attribute occurs of the <MAPPED_PATH> element in the mapping document is set to "false" either implicitly or explicitly, the XML schema definition of the element must set the attribute minOccurs to "0".
If the attribute notEmpty of the <MAPPED_PATH> element in the mapping document is set to "false", the XML schema definition for the element must set the attribute xsi:nillable to "true". Otherwise, the element defined by the <MAPPED_PATH> element must allow an empty value.
See Section B.6 for details about the data type definition schema ordcmmddt.xsd.
This section describes how to create a mapping document and a well-formed metadata XML document with no XML schema constraints. For applications that require only a well-formed metadata XML document, the mapping document can contain an empty <NAMESPACE> element because the extracted metadata does not need to conform to any XML schema.
This section includes examples for a mapping document, followed by the resulting metadata XML document. Appropriate XML statements are highlighted in bold to show where the main actions take place in both the mapping document and the related XML document. Descriptions of each bolded XML statement follow the examples.
The following example of a mapping document shows an empty <NAMESPACE> element. This example also shows the values to be specified for the occurs, notEmpty, writeTag, writeDefiner, and writeName attributes in the <MAPPED_PATH> element to define the extracted metadata XML document. If these attributes are not specified, they are set to "false", the default value.
<?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>
The following example shows the resulting metadata XML document whose XML metadata was extracted with the value of the extractOption parameter in the extractMetadata( ) method set to 'MAPPED':
<?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>
In the preceding examples, these actions take place:
In the mapping document, the <NAMESPACE> element is empty. As a result, the resulting extracted XML document does not include the default namespace declaration because it is not constrained by an XML schema.
The <ROOT_ELEM_TAG> element in the mapping document matches the root element tag (shown in the <DICOM_OBJECT> element) in the extracted XML document.
In the mapping document, the value of the notEmpty attribute of the <MAPPED_PATH> element for the DICOM attribute with tag 00100040 is "false". In the extracted XML document, the value of the xsi:nil attribute in the <BIRTH_DATE> element is set to "true" because this DICOM attribute is empty in the DICOM content.
In the mapping document, the <MAPPED_PATH> element for the DICOM attribute with tag 00200010, the writeTag, writeName, and writeDefiner attributes are set to "true". In the extracted XML document, the child element <ID> under the <STUDY> element has corresponding definer, tag, and name attributes.
In the mapping document, the <MAPPED_PATH> element for the DICOM attribute with tag 00081080 uses the default value ("false") for the occurs attribute. Because this DICOM attribute does not exist in the DICOM content, the element <ADMITTING_DIAGNOSES_DESCRIPTION> does not exist in the extracted XML document.
See extractMetadata( ) in Chapter 5 for reference information about this method and the supported values for the extractOption parameter.
This section describes how to create a mapping document and a metadata XML document with XML schema constraints, discarding the unmapped section. This example can be used in applications that require only the DICOM attributes defined in the mapped section of the XML metadata as well as in metadata XML documents with XML schema constraints.
This section includes examples for a mapping document, an XML schema, and the resulting metadata XML document constrained by the schema. Appropriate XML statements are highlighted in bold to show where the main actions take place in both the mapping document and the related XML document. Descriptions of each bolded XML statement follow the examples.
The extractMetadata( ) method of the ORDDicom object can extract all or part of the metadata into an XML document based on the value of the extractOption parameter (See extractMetadata( ) in Chapter 5).
The following example of a mapping document shows how to specify the namespace of the metadata XML document in a mapping document so that the metadata document can be constrained by an XML schema.
<?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>
This mapping document differs from the mapping document in Section 11.2.3.3 as follows:
The <NAMESPACE> element contains a value.
The <UNMAPPED_ELEM> and the <MAPPED_ELEM> elements are empty, thus the mapped path is relative to the <ROOT_ELEM_TAG> element.
The following example shows the XML schema definition for this mapping document:
<?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>
In the preceding examples, the following elements and data types are defined:
The namespace declaration of the metadata XML schema has the same value as the <NAMESPACE> element in the mapping document.
For the <MAPPED_PATH> element in the mapping document that has the value of the notEmpty attribute set to "false" either explicitly, as for tag 00100030, or implicitly using the default value, as for tag 00800030, the corresponding element defined in the XML schema has the value of the nillable attribute set to "true", as in the <BIRTH_DATE> element and the <TIME> element.
Any <MAPPED_PATH> element in the mapping document that has the value of the occurs attribute set to "false" either explicitly, as for tag 00100040, or implicitly using the default value, as for tag 00800030, the corresponding element defined in the XML schema must have the value of the attribute minOccurs set to "0", as in the <SEX> element and the <TIME> element.
The data type defined in the XML schema must be compatible with the data type defined by Oracle in the schema ordcmmddt.xsd. In Example 2, the "PERSON_NAME" data type definition is copied from the schema ordcmmddt.xsd, while the "ID_TYPE" data type is defined so that the <ID> element under the <STUDY> element can have the tag, definer, and name attributes. The "ID_TYPE" data type is compatible with the "SH_ATTR_T" data type defined by Oracle. The <SEX> element is defined to use the "xs:string" data type, which is compatible with the Oracle-defined data type "CS".
The <UNMAPPED_ELEM> element is empty in the mapping document, and the root element <DICOM_OBJECT> of the metadata XML is not defined as the "DATASET_T" type. With this schema constraint, a valid metadata XML document can include a mapped section only. Thus, if the application attempts to extract metadata using a value of "ALL" or "STANDARD" for the extractOption parameter, the attempt will return the following error:
ORA-53259: cannot extract metadata that conforms to the schema definition
The following example shows the resulting metadata XML document whose XML metadata was extracted with the value of the extractOption parameter in the extractMetadata( ) method set to 'MAPPED':
<?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>
This section describes how to create a mapping document and a metadata XML document with XML schema constraints, including the unmapped section.
This section includes examples for a mapping document, an XML schema, and the resulting metadata XML document constrained by the schema. Appropriate XML statements are highlighted in bold to show where the main actions take place in both the mapping document and the related XML document. Descriptions of each bolded XML statement follow the examples.
The following example of a mapping document shows how to include a sequence type attribute in the mapped section.
<?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>
This mapping document differs from the mapping document in Section 11.2.3.4 as follows:
The <UNMAPPED_ELEM> and <MAPPED_ELEM> elements are not empty.
There is a <MAPPED_PATH> element for tag 00081084, which is of DICOM sequence type.
The following example shows how to define the unmapped root element in the XML schema to include the unmapped section in the extracted metadata XML document. This example also shows how to use Oracle-defined data types from the schema 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>
In the preceding examples, the following actions take place:
Instead of defining its own data types as in Section 11.2.3.4, this XML schema uses the Oracle-defined data types by copying the schema ordcmmddt.xsd into an application-specific XSD file and then changing the namespace declaration, as in this XML segment:
<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">
This data type XML schema is registered with Oracle XML DB using the following namespace URL:
"http://www.mycompany.com/dicom/datatype_3"
Then, this registered namespace URL is included in the metadata XML schema.
Because the Oracle-defined data types are included in the XML schema, they can be referenced directly, as shown in the <NAME>, <ADMITTING_DIAGNOSES_CODE_SEQUENCE>, and <OTHER_ATTRIBUTES> elements.
The <OTHER_ATTRIBUTES> element is defined as type "DATASET_T" to enable the inclusion of all unmapped DICOM attributes under this element when a value of "ALL" or "STANDARD" is passed to the extractMetadata( ) method for the extractOption parameter. Because the minOccurs attribute is defined as "0", when the value "MAPPED" is passed to the extractMetadata( ) method, only the mapped section is included in the extracted XML document.
The following example shows the resulting metadata XML document whose XML metadata was extracted with the value of the extractOption parameter in the extractMetadata( ) method set to 'MAPPED':
<?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>
The following example shows the resulting metadata XML document whose XML metadata was extracted with the value of the extractOption parameter in the extractMetadata( ) method set to 'ALL':
<?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>
Standard dictionary documents are XML representations of the data dictionary defined by the DICOM standard.
The XML schema ordcmsd.xsd defines the XML schema that constrains standard dictionary documents. (See Section B.9 for a listing of the standard dictionary document schema ordcmsd.xsd. See the text included within the <xs: annotation> element for a detailed description of the schema elements.)
The default standard dictionary document ordcmsd.xml is an XML representation of the data dictionary defined in Part 6 of the DICOM standard.
The XML schema ordcmrdt.xsd defines the DICOM standard data types and Oracle extensions to those data types, which are used by all the other DICOM XML schemas. (See Section B.3 for a listing of the data type definition schema ordcmrdt.xsd.)
Note:
Standard dictionary documents must not include any other attributes, such as attributes defined by manufacturers of modalities or organizations other than NEMA.Through the Oracle Technology Network, Oracle may release new standard dictionary documents along with installation instructions for DICOM administrators. These new standard dictionary documents would reflect new releases of, or addendum to, the DICOM standard.
The following subsections contain examples that show how to create standard dictionary documents.
The standard attribute definition in the standard dictionary allows two types of attribute tags: simple tags and wildcard tags. An attribute tag value consists of the group number followed by an element number.
A simple attribute tag is 4-byte hexadecimal number which consists of a group number followed by an element number (for example: 10871100).
A wildcard attribute tag represents a set of hexadecimal numbers. It also consists of a group number followed by an element number, where portions of the value are replaced by the character x or X (for example: 1087xx00).
Each standard attribute in the standard dictionary document is represented by a <STANDARD_ATTRIBUTE_DEFINITION> element. Each standard attribute listed in the XML document corresponds to a related tag that is defined in the Part 6 of the DICOM standard.
Note:
The definer name"DICOM" and the UID "1.2.840.10008.1" are reserved by Oracle to refer to DICOM standard attributes.Definition Using a Simple Attribute Tag - Example 1
This example shows how to define a standard attribute with a simple attribute tag. The XML statements where this action is defined are highlighted in bold.
<STANDARD_ATTRIBUTE_DEFINITION> <TAG>00080008</TAG> <NAME>Image Type</NAME> <VR>CS</VR> <VM>1-n</VM> </STANDARD_ATTRIBUTE_DEFINITION>
In Example 1, the <TAG> element represents the hexadecimal value of the attribute tag 00080008, which is defined by the DICOM standard. This attribute tag value consists of a group number, followed by an element number. The <NAME> element represents the name of the attribute tag that is defined by the DICOM standard. The <VR> element represents the value representation of the attribute tag that is defined by the DICOM standard. The <VM> element represents the value multiplicity of the attribute tag defined by the DICOM standard. (See the type <VR_T> and the type <VM_T> listed in the XML schema ordcmrdt.xsd for more information about the value representation and value multiplicity data types supported by Oracle Multimedia DICOM.)
Definition Using a Wildcard Attribute Tag - Example 2
This example shows how to define a standard attribute with a wildcard attribute tag. The XML statements where this action is defined are highlighted in bold.
<STANDARD_ATTRIBUTE_DEFINITION>
<TAG>60xx0010</TAG>
<NAME>Overlay Rows</NAME>
<VR>US</VR>
<VM>1</VM>
</STANDARD_ATTRIBUTE_DEFINITION>
In Example 2, the standard attribute definition contains the wildcard tag 60xx0010.
Standard attributes included in the standard dictionary document are retired in the DICOM standard when they are no longer needed.
This example shows the definition of a standard attribute as retired. The XML statement where this action is defined is highlighted in bold.
<STANDARD_ATTRIBUTE_DEFINITION>
<TAG>00080010</TAG>
<NAME>Recognition Code</NAME>
<VR>CS</VR>
<VM>1</VM>
<RETIRED>true</RETIRED>
</STANDARD_ATTRIBUTE_DEFINITION>
In Example 3, for the <RETIRED> element a value of true indicates that the attribute is retired and corresponds to the RET value used in the DICOM standard. Oracle recommends providing the <VR> and <VM> element values for a retired attribute to enable the metadata to be extracted from the DICOM content.
Private dictionary documents are XML documents that list the attributes defined by modality manufacturers or organizations other than NEMA.
Private organizations or manufacturers of modalities can include attributes that are specific to their particular organizations in their DICOM content. These private attributes must be defined in a private dictionary document and stored in the data model repository to enable Oracle Multimedia to process metadata associated with the private attributes in the DICOM content.
The XML schema ordcmpv.xsd defines the XML schema that constrains private dictionary documents. (See Section B.8 for a listing of the private dictionary document schema ordcmpv.xsd.)
The default private dictionary document ordcmpv.xml lists the private attributes defined by Oracle.
The XML schema ordcmrdt.xsd defines the DICOM standard data types and Oracle extensions to those data types, which are used by all the other DICOM XML schemas. (See Section B.3 for a listing of the data type definition schema ordcmrdt.xsd.)
The following subsections contain examples that show how to create private dictionary documents.
The private attribute definition in the private dictionary allows three types of attribute tags: simple tags, wildcard tags, and range tags. An attribute tag value consists of the group number followed by an element number.
A simple attribute tag is 4-byte hexadecimal number which consists of a group number followed by an element number (for example: 10871100).
A wildcard attribute tag represents a set of hexadecimal numbers. It also consists of a group number followed by an element number, where portions of the value are replaced by the character x or X (for example: 1087xx00).
A range attribute tag represents a range of hexadecimal numbers. It consists of two simple attribute tags that define a range of values. The starting range value must be less than the ending range value.
Each private attribute in the private dictionary document is represented by a <PRIVATE_ATTRIBUTE_DEFINITION> element.
Note:
Keep these additional guidelines in mind:Do not use wildcard attribute tags within range attribute tags.
The definer name "DICOM" and the UID "1.2.840.10008.1" are reserved by Oracle to refer to DICOM standard attributes. Do not use them in private dictionaries.
Oracle recommends associating all DICOM private attributes in the DICOM content with a UID-qualified name.
The value of a tag-definer pair must be unique within the private dictionary document.
Definition Using a Simple Attribute Tag - Example 1
This example shows how to define a private attribute with a simple attribute tag. The XML statements where this action is defined are highlighted in bold.
<PRIVATE_ATTRIBUTE_DEFINITION> <TAG>FFFF1001</TAG> <NAME>locator macro tag</NAME> <DEFINER>ORACLE</DEFINER> <VR>SQ</VR> <VM>1</VM> </PRIVATE_ATTRIBUTE_DEFINITION>
In Example 1, the <TAG> element represents the hexadecimal value of the attribute tag FFFF1001. The <NAME> element represents the name of the organization defining the tag, ORACLE. The <VR> element represents the value representation of the attribute tag. The <VR> element is defined as type VR_T in the XML schema ordcmrdt.xsd. The <VR> element value must be one of the values that are listed for type <VR_T> in the XML schema ordcmrdt.xsd. The <VM> element represents the value multiplicity of the attribute tag. The <VM> element is defined as type VM_T in the XML schema ordcmrdt.xsd. The <VM> element value must be one of the values listed for type VM_T in the XML schema ordcmrdt.xsd. (See the type <VR_T> and the type <VM_T> listed in the XML schema ordcmrdt.xsd for more information about the value representation and value multiplicity data types supported by Oracle Multimedia DICOM.)
Definition Using a Wildcard Attribute Tag - Example 2
This example shows how to define a private attribute with a wildcard attribute tag. The XML statements where this action is defined are highlighted in bold.
<PRIVATE_ATTRIBUTE_DEFINITION> <TAG>0119XX00</TAG> <NAME>PRIVATE TAG1</NAME> <DEFINER>PRIVATE_ORG</DEFINER> <VR>IS</VR> <VM>1</VM> </PRIVATE_ATTRIBUTE_DEFINITION>
In Example 2, the private attribute definition contains the wildcard tag 0119XX00 and the definer name PRIVATE_ORG.
Definition Using a Range Attribute Tag - Example 3
This example shows how to define a private attribute with a range attribute tag. The XML statements where this action is defined are highlighted in bold.
<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>
In Example 3, the private attribute definition contains a range tag that specifies all tag ranges from A0110010 to A01AAA10. The definer name 1.2.840.423 is a UID value.
Note:
An attribute definition cannot match another attribute definition of the same tag-definer pair within a private dictionary document.The following XML segment shows an example of an attribute definition that is not allowed in the private dictionary:
<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>
In the preceding XML segment, the tag-definer pair (01191100, PRIVATE_ORG) matches the tag-definer pair (0119XX00, PRIVATE_ORG).
An attribute definer refers to the definer name and UID of an organization defining private attributes.
The <ATTRIBUTE_DEFINERS> element is an optional element that represents all the private definer names and definer UIDs used in a private dictionary document.
Note:
The definer name"DICOM" and the UID "1.2.840.10008.1" are reserved by Oracle to refer to DICOM standard attributes. Do not use them in private dictionaries.The <ATTRIBUTE_DEFINERS> element is of type ATTR_DEFINERS_T. This type is defined in the XML schema ordcmrdt.xsd.
The following example shows how to define attribute definers:
<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>
In Example 4, the prefix dt is mapped to the namespace http://xmlns.oracle.com/ord/dicom/datatype_1_0 where the <ATTR_DEFINER> element is defined. The value of the <dt:NAME> element represents the name of the private organization. The value of the <dt:UID> element represents the UID of the private organization.
Private attributes included in private dictionary documents can be retired when they are no longer needed.
The following example shows how to define a private attribute as retired. The XML statement where this action is defined is highlighted in bold.
<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>
For the <RETIRED> element, a value of true indicates that the attribute is retired and corresponds to the RET value used in the DICOM standard. Oracle recommends providing the <VR> and <VM> element values for a retired attribute to enable the metadata to be extracted from the DICOM content.
Preference documents are XML documents that list the set of preferences that define the run-time behavior of Oracle Multimedia DICOM.
The XML schema ordcmpf.xsd defines the XML schema that constrains preference documents. (See Section B.7 for a listing of the preference document schema ordcmpf.xsd. See the text included within the <xs: annotation> element for a detailed description of the preference parameters and their valid values.)
The default preference document ordcmpf.xml includes the default values for the run-time preference parameters for Oracle Multimedia DICOM.
Each preference value in a preference document is defined by a < PREFERENCE_DEF> element.
Note:
Keep these additional guidelines in mind:A maximum of two (one Oracle-defined and one user-defined) preference documents are allowed in the repository.
Changes to values in preference documents change the behavior of DICOM methods, functions, and procedures. Specifically, preference values that are defined in the user-defined preference document override the default values defined in the Oracle-defined preference document ordcmpf.xml.
All preference parameter names and their associated values are defined by Oracle. User-defined preference documents can change the values of the Oracle-defined preference parameters.
The following subsection contains an example that shows how to create preference documents.
This example shows how to define the VALIDATE_METADATA preference parameter in a preference document. The XML statements where this action is defined are highlighted in bold.
<PREFERENCE_DEF>
<PARAMETER>VALIDATE_METADATA</PARAMETER>
<DESCRIPTION>Validate XML Metadata document</DESCRIPTION>
<VALUE>true</VALUE>
</PREFERENCE_DEF>
In Example 1, the <PARAMETER> element specifies the Oracle-defined parameter VALIDATE_METADATA.
The <VALUE> element represents the value of the parameter VALIDATE_METADATA, which is passed to the extractMetadata( ) method. The extractMetadata( ) method accepts a mapping document as input. The mapping document contains a namespace parameter (which can be empty). If an XML schema is registered at the namespace specified in the mapping document, and the value of the VALIDATE_METADATA parameter is true, the extractMetadata( ) method validates the resulting XML document against the designated XML schema. If the value of the VALIDATE_METADATA parameter is false, the resulting XML document is not validated against the schema.
UID definition documents are XML representations of the unique identifiers (UIDs) defined by the DICOM standard. The UID definitions are used by Oracle Multimedia DICOM to parse the DICOM content.
The XML schema ordcmui.xsd defines the XML schema that constrains UID definition documents. (See Section B.10 for a listing of the UID definition document schema ordcmui.xsd. See the text included within the <xs: annotation> element for a detailed description of the attributes used in the schema.)
The default UID definition document ordcmui.xml includes the UIDs listed in Part 6 of the DICOM standard.
Each UID definition in a UID definition document is defined by a <UID_DEF> element.
Note:
Keep these additional guidelines in mind:A maximum of two (one Oracle-defined and one user-defined) UID definition documents are allowed in the repository.
Changes in user-defined UID definition documents must be limited to updates in the DICOM standard or additions of new UID values. See Part 5 of the DICOM standard for more information on creating privately defined unique identifiers.
Existing UIDs defined by the DICOM standard can be changed only to include updates in the DICOM standard.
The following subsections contain examples that show how to create UID definitions in UID definition documents.
This example shows how to define a storage class UID definition. The XML statements where this action is defined are highlighted in bold.
<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>
In Example 1, the <UID> element value 1.2.840.10008.5.1.4.1.1.2 represents a UID value that is defined by the DICOM standard. The <NAME> element value CT Image Storage represents the UID name that is defined by the DICOM standard. The value of the classification attribute "storageClass" in the <UID_DEF> element corresponds to the UID type SOP Class defined by the DICOM standard. The value of the contentType attribute "image" indicates that the DICOM content contains pixel data.
This example shows how to define a UID definition for transfer syntax as retired. The XML statements where this action is defined are highlighted in bold.
<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>
In Example 2, the <UID> element value 1.2.840.10008.1.2.4.52 represents a UID value that is defined by the DICOM standard. The <NAME> element value JPEG Extended (Process 3 and 5) (Retired) represents the UID name that is defined by the DICOM standard. The value of the classification attribute "transferSyntax" corresponds to the UID type Transfer Syntax defined by the DICOM standard. The values of the attributes isCompressed, isEVR (explicit VR), and isLE (little endian) are derived from the transfer syntax definitions listed in Part 5 of the DICOM standard. The value of the retired attribute "true" indicates that this UID definition is retired.
