This chapter uses code examples to show how to manage configuration documents in the DICOM data model repository. The code examples are written in PL/SQL to match the ORD_DICOM_ADMIN package, which is provided in PL/SQL only.
Oracle Multimedia DICOM provides capabilities for several administrative operations related to the data model repository. For example, administrators can review the Oracle-defined configuration documents in the DICOM data model repository before determining whether to add custom configuration documents for a particular organization (Steps 2 and 4 in Section 11.2 describe this process). Using views or invoking data model utility functions, administrators can obtain attributes and other detailed information about these configuration documents. Working with the procedures and functions in the ORD_DICOM_ADMIN package, administrators can insert, update, export, or delete configuration documents from the repository. Administrators of the DICOM data model repository are assigned the ORDADMIN role.
This chapter includes these sections:
See Chapter 12 for reference information about the ORD_DICOM_ADMIN package.
For additional examples, articles, and other information about Oracle Multimedia DICOM and Oracle Multimedia, see the Oracle Multimedia Software section of the Oracle Technology Network Web site at
http://www.oracle.com/technology/products/multimedia/
The following sample session shows the steps for inserting a mapping document and a constraint document into the repository. This sample assumes that the following prerequisite tasks have been completed:
The directory object (DICOMDIR) has been created, and the administrator has been granted READ access.
The metadata schema associated with the mapping document has been registered with Oracle XML DB as a global XML schema.
Perform the following steps to insert a mapping document and a constraint document into the repository:
Prepare the data model for editing and lock it to prevent other administrators from making changes at the same time. For example:
exec ord_dicom_admin.editDataModel();
The data model remains locked until you publish the changes, perform a rollback operation, or exit the session.
Optionally, you can enter the following command to query the orddcm_documents view:
select * from orddcm_documents order by doc_id asc;
Review the list of documents.
First, insert the sample mapping document (sample_map.xml), as follows:
exec ord_dicom_admin.insertDocument('sample_map.xml', 'MAPPING',
xmltype(bfilename('DICOMDIR', 'sample_map.xml'), nls_charset_id('AL32UTF8')));
See Example 2-1 for the sample mapping document (sample_map.xml).
Then, insert the sample constraint document (sample_ct.xml), as follows:
exec ord_dicom_admin.insertDocument('sample_ct.xml', 'CONSTRAINT',
xmltype(bfilename('DICOMDIR', 'sample_ct.xml'), nls_charset_id('AL32UTF8')));
See Example 2-3 for the sample constraint document (sample_ct.xml).
Optionally, you can enter the following command to query the orddcm_documents view:
select * from orddcm_documents order by doc_id asc;
Review the list of documents to ensure that the inserted documents appear.
As another option, you can enter the following command to query the orddcm_document_refs view, and then review the document references:
select * from orddcm_document_refs order by doc_name, ref_by_doc_name asc;
At this point, you can run administrative tests as needed. In addition, you can call the rollbackDataModel( ) procedure to terminate the operation without publishing the changes. Or, you can continue with the next step.
Publish the changes and unlock the data model, as follows:
exec ord_dicom_admin.publishDataModel();
The data model includes the inserted configuration documents.
The following sample session shows the steps for updating a mapping document in the repository. This sample assumes that the following prerequisite tasks have been completed:
The directory object (DICOMDIR) has been created, and the administrator has been granted READ and WRITE access.
The referenced metadata schema associated with the mapping document has been registered with Oracle XML DB as a global XML schema.
See Oracle XML DB Developer's Guide for information about registering XML schemas.
Perform the following steps to update a mapping document in the repository:
As in Section 11.1, prepare the data model for editing and lock it to prevent other administrators from making changes at the same time. For example:
exec ord_dicom_admin.editDataModel();
The data model remains locked until you publish the changes, perform a rollback operation, or exit the session.
Optionally, you can enter the following command to query the orddcm_documents view:
select * from orddcm_documents order by doc_id asc;
Review the list of documents.
Export the sample mapping document (sample_map.xml) from the repository into a specified file (sample_map_export.xml) for editing. For example:
exec ord_dicom_admin.exportDocument('sample_map.xml', 'DICOMDIR',
'sample_map_export.xml');
See Example 2-1 for the sample mapping document (sample_map.xml).
The sample_map_export.xml file is available for editing with an XML editor.
Delete the existing mapping document (sample_map.xml) from the repository, as follows:
exec ord_dicom_admin.deleteDocument('sample_map.xml');
The repository no longer includes the sample mapping document.
Optionally, you can enter the following command to query the orddcm_documents view:
select * from orddcm_documents order by doc_id asc;
Review the list of documents to ensure that the deleted document no longer appears.
Use an XML editor to edit the file that was exported in Step 2. Then, save the changes and check the permissions on the file before inserting it into the repository.
Insert the edited document (sample_map_edited.xml) into the repository, as follows:
exec ord_dicom_admin.insertDocument('sample_map_edited.xml', 'MAPPING',
xmltype(bfilename('DICOMDIR', 'sample_map_edited.xml'),
nls_charset_id('AL32UTF8')));
Optionally, you can enter the following command to query the orddcm_documents view:
select * from orddcm_documents order by doc_id asc;
Review the list of documents to ensure that the updated document appears.
At this point, you can test your changes, run the extractMetadata( ) method on the edited mapping document to retrieve metadata from the embedded DICOM content as XML code, and then store it in a database table for searching or viewing. In addition, you can call the rollbackDataModel( ) procedure to terminate the operation without publishing the changes. Or, you can continue with the next step.
As in Section 11.1, publish the changes and unlock the data model, as follows:
exec ord_dicom_admin.publishDataModel();
The data model includes the updated configuration document.
The following sample session shows the steps for deleting a constraint document from the repository. This sample assumes that the following prerequisite task has been completed:
The directory object (DICOMDIR) has been created, and the administrator has been granted WRITE access.
Perform the following steps to delete a constraint document from the repository:
As in Section 11.1, prepare the data model for editing and lock it to prevent other administrators from making changes at the same time. For example:
exec ord_dicom_admin.editDataModel();
The data model remains locked until you publish the changes, perform a rollback operation, or exit the session.
Optionally, you can enter the following command to query the orddcm_documents view:
select * from orddcm_documents order by doc_id asc;
Review the list of documents.
Export the sample constraint document (sample_ct.xml) from the repository into a specified file (sample_ct_export.xml) for editing. For example:
exec ord_dicom_admin.exportDocument('sample_ct.xml', 'DICOMDIR',
'sample_ct_export.xml');
See Example 2-3 for the sample constraint document (sample_ct.xml).
Optionally, you can enter the following command to query the orddcm_document_refs view, which shows the list of documents that are referenced by other documents in the repository:
select * from orddcm_document_refs order by doc_name, ref_by_doc_name asc;
Review the list of documents to check the references for the constraint document that you intend to delete.
Delete the sample constraint document (sample_ct.xml), as follows:
exec ord_dicom_admin.deleteDocument('sample_ct.xml');
The repository no longer includes the sample constraint document.
Optionally, you can enter the following command to query the orddcm_documents view:
select * from orddcm_documents order by doc_id asc;
Review the list of documents to ensure that the deleted document no longer appears.
At this point, you can call the rollbackDataModel( ) procedure to terminate the operation without publishing the changes. Or, you can continue with the next step.
Publish the changes and unlock the data model, as follows:
exec ord_dicom_admin.publishDataModel();
The data model does not include the deleted configuration document.
This section describes two different approaches you can take to insert a stored tag list document into the repository:
Section 11.4.1 describes how to insert a stored tag list document with a known set of attribute tags.
Follow the example in this section to create, and then insert, your own stored tag list document if you believe that you know the full set of attribute tags that all the constraint and mapping documents in your repository are likely to use.
Section 11.4.2 describes how to generate and insert a stored tag list document from an existing repository that is populated with constraint and mapping documents.
Follow the examples in this section if you have an existing repository and want to generate, and then insert, a stored tag list document from tags used by your existing constraint and mapping documents.
Select the appropriate approach to take advantage of the storage and performance benefits of the stored tag list feature.
The following subsections describe each approach:
You can create your own stored tag list document, and then insert it into the repository. Include all the attribute tags to be defined in the constraint and mapping documents in the repository in your document. Example 11-1 is a sample file (sample_stl.xml) that you can insert as the stored tag list document.
Example 11-1 Inserting a Stored Tag List Document with Known Attribute Tags
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) 2008, Oracle. All rights reserved.
NAME
sample_stl.xml - sample stored tag list
-->
<ATTRIBUTE_TAG_LIST xmlns="http://xmlns.oracle.com/ord/dicom/attributeTag_1_0"
xmlns:dt="http://xmlns.oracle.com/ord/dicom/datatype_1_0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/ord/dicom/attributeTag_1_0
http://xmlns.oracle.com/ord/dicom/attributeTag_1_0">
<DOCUMENT_HEADER>
<dt:DOCUMENT_CHANGE_LOG>
<dt:DOCUMENT_MODIFIER>ORACLE</dt:DOCUMENT_MODIFIER>
<dt:DOCUMENT_MODIFICATION_DATE>2009-02-25</dt:DOCUMENT_MODIFICATION_DATE>
<dt:DOCUMENT_VERSION>1.0</dt:DOCUMENT_VERSION>
</dt:DOCUMENT_CHANGE_LOG>
</DOCUMENT_HEADER>
<ATTRIBUTE_TAG>00020002</ATTRIBUTE_TAG>
<ATTRIBUTE_TAG>00020003</ATTRIBUTE_TAG>
<ATTRIBUTE_TAG>00100010</ATTRIBUTE_TAG>
</ATTRIBUTE_TAG_LIST>
This approach assumes that the following prerequisite task has been completed:
The directory object (DICOMDIR) has been created, and the administrator has been granted READ access.
Perform the following steps to insert a stored tag list document with a known set of attribute tags into the repository:
As in Section 11.1, prepare the data model for editing and lock it to prevent other administrators from making changes at the same time. For example:
exec ord_dicom_admin.editDataModel();
The data model remains locked until you publish the changes, perform a rollback operation, or exit the session.
At this point, to see which documents are stored in the repository, enter the following command to query the orddcm_documents view:
select doc_name from orddcm_documents order by doc_id asc;
Insert the sample stored tag list document file (sample_stl.xml), as follows:
exec ord_dicom_admin.insertDocument(
'sample_stl.xml',
'STORED_TAG_LIST',
xmltype(bfilename('DICOMDIR', 'sample_stl.xml'),
nls_charset_id('AL32UTF8') ) );
Publish the changes and unlock the data model, as follows:
exec ord_dicom_admin.publishDataModel;
The data model includes the inserted configuration documents.
If you have an existing repository that is populated with constraint and mapping documents, you can generate a stored tag list document from tags used by your existing constraint and mapping documents, make changes to the tags as needed, and insert the stored tag list document into the repository.
To enforce specific rules for the attributes you want to include in your stored tag list, insert a preference document that defines those attribute rules. Example 11-2 shows a preference document (sample_pf.xml) that enforces the mandate attribute tags rule for mapping and constraint documents. The code statements where this operation is performed are highlighted in bold.
Example 11-2 Sample Preference Document for the Mandate Attribute Tags Rule
<?xml version="1.0" encoding="UTF-8"?> <DICOM_RUNTIME_PREFERENCES xmlns="http://xmlns.oracle.com/ord/dicom/preference_1_0" xmlns:dt="http://xmlns.oracle.com/ord/dicom/datatype_1_0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/ord/dicom/preference_1_0 http://xmlns.oracle.com/ord/dicom/preference_1_0"> <DOCUMENT_HEADER> <dt:DOCUMENT_CHANGE_LOG> <dt:DOCUMENT_MODIFIER>Developer 1</dt:DOCUMENT_MODIFIER> <dt:DOCUMENT_MODIFICATION_DATE>2009-02-20</dt:DOCUMENT_MODIFICATION_DATE> <dt:DOCUMENT_VERSION>0.2</dt:DOCUMENT_VERSION> <dt:MODIFICATION_COMMENT> enable MANDATE_ATTR_TAGS_IN_STL</dt:MODIFICATION_COMMENT> </dt:DOCUMENT_CHANGE_LOG> </DOCUMENT_HEADER> <PREFERENCE_DEF> <PARAMETER>MANDATE_ATTR_TAGS_IN_STL</PARAMETER> <DESCRIPTION> allowed values true or false</DESCRIPTION> <VALUE>true</VALUE> </PREFERENCE_DEF> </DICOM_RUNTIME_PREFERENCES>
Because the value of the MANDATE_ATTR_TAGS_IN_STL parameter is set to true, all the tags used by the constraint and mapping documents are listed in the stored tag list document. See Section 10.2.6.3 for more information about defining this parameter in preference documents.
This approach assumes that the following prerequisite task has been completed:
The directory object (DICOMDIR) has been created, and the administrator has been granted READ and WRITE access.
Perform the following steps to generate and insert a stored tag list document into the repository:
As in Section 11.1, prepare the data model for editing and lock it to prevent other administrators from making changes at the same time. For example:
exec ord_dicom_admin.editDataModel();
The data model remains locked until you publish the changes, perform a rollback operation, or exit the session.
Optionally, you can enter the following command to query the orddcm_documents view:
select doc_name from orddcm_documents order by doc_id asc;
Review the list of documents to see which documents exist in your repository.
Generate and export the stored tag list document to the sample stored tag list document file (sample_stl.xml), as shown in Example 11-3:
Example 11-3 Generating and Exporting a Stored Tag List Document to a File
--
-- Generate a tag list document and store in sample_stl.xml
-- in DICOMDIR
--
-- A stored tag list document must include all tags used by
-- mapping and constraint documents in the repository
-- to enforce the mandate_attr_tags_in_stl rule using a
-- preference document.
--
-- Use the 'ALL' option to ensure that the generated tag list
-- document contains all the tags used by mapping and constraint
-- documents.
--
set serveroutput on;
declare
fid UTL_FILE.FILE_TYPE;
buf VARCHAR2(32767);
bytesLeft INTEGER;
pos INTEGER;
chunk INTEGER;
xml_clob CLOB;
xt XMLType;
BEGIN
xt := ORD_DICOM_ADMIN.generateTagListDocument('ALL');
if (xt is null) then
dbms_output.put_line('Repository has no documents');
dbms_output.put_line('Tag list document is null');
return;
end if;
-- write xml document to file using UTL_FILE
-- let UTL_FILE report errors for directory and filename
fid := utl_file.fopen( 'DICOMDIR', 'sample_stl.xml', 'w', 32767 );
-- Read from clob and write to file
select XMLSerialize(document xt as clob) into xml_clob from dual;
bytesLeft := dbms_lob.getLength( xml_clob );
pos := 1;
WHILE bytesLeft > 0 loop
chunk := 32767;
IF bytesLeft < chunk THEN
chunk := bytesLeft;
END IF;
dbms_lob.read(xml_clob, chunk, pos, buf );
utl_file.put( fid, buf);
utl_file.fflush(fid);
bytesLeft := bytesLeft - chunk;
pos := pos + chunk;
end loop;
utl_file.fclose( fid );
--free the temporary blob returned by xmltype
if(dbms_lob.isTemporary(xml_clob) <> 0) then
dbms_lob.freeTemporary(xml_clob);
end if;
exception
WHEN OTHERS then
-- free temp lobs
if(dbms_lob.isTemporary(xml_clob) <> 0) then
dbms_lob.freeTemporary(xml_clob);
end if;
raise; -- original exception
END;
/
Use an XML editor to edit the stored tag list document file that was exported in Step 2. Make changes to the tags as needed, save the changes, and check the permissions on the file before inserting it into the repository.
Insert the generated stored tag list document (sample_stl.xml), as follows:
ord_dicom_admin.insertDocument(
'sample_stl.xml',
'STORED_TAG_LIST',
xmltype(bfilename('DICOMDIR', 'sample_stl.xml'),
nls_charset_id('AL32UTF8') ) );
To enforce the mandate attribute tags rule, insert a preference document with the value of the MANDATE_ATTR_TAGS_IN_STL parameter set to true, as follows:
exec ord_dicom_admin.insertDocument(
'sample_pf.xml',
'PREFERENCE',
xmltype(bfilename('DICOMDIR', 'sample_pf.xml'),
nls_charset_id('AL32UTF8') ) );
See Example 11-2 for a sample preference document that enforces this rule.
|
Note: If the MANDATE_ATTR_TAGS_IN_STL parameter is set totrue in your preference document, and you attempt to insert any mapping or constraint documents that contain tags that are not listed in your stored tag list document, those documents are not inserted into the repository. See Section 10.2.6.3 for more information about this preference parameter. |
Optionally, you can enter the following command to query the orddcm_documents view:
select * from orddcm_documents order by doc_id asc;
Review the list of documents.
Publish the changes and unlock the data model, as follows:
exec ord_dicom_admin.publishDataModel;
This document summarizes the new features, enhancements, APIs, and Oracle Database support introduced with Oracle Multimedia DICOM in the current release.
Oracle Database 11g Release 2 (11.2) adds the following DICOM enhancements, which are described in this guide.
Oracle Multimedia DICOM now supports recursive calls within constraint definitions. See Section 10.2.2.4 for more information and examples about how to use this enhancement.
Oracle Multimedia DICOM now provides the ability to limit the list of DICOM attributes extracted by the setProperties( ) method, thus improving performance and reducing storage requirements. See Section 3.2.10 for more information about this enhancement.
Oracle Multimedia DICOM now includes the Oracle Multimedia Mid-Tier Java API, which enables the extraction of DICOM metadata outside of Oracle Database by a client tool or in the middle tier. This enhancement provides these benefits:
Enables users to write Java applications for extracting DICOM metadata outside of Oracle Database.
Facilitates the extraction of DICOM metadata attributes on which data is partitioned before the data is loaded into the database.
See Section 2.9 for more information about this enhancement.
Oracle Multimedia DICOM now provides DICOM value locator type syntax to enable users to reference DICOM metadata tags used in the DICOM configuration documents and that refer to private attribute definers. See General Format for DICOM Value Locators for complete reference information. See Section 10.2.1.5, Section 10.2.2.5, and Section 10.2.3.6, for more information about using DICOM value locators in anonymity, constraint, and mapping documents, respectively.
|
See Also: Oracle Multimedia Mid-Tier Java API Reference for reference information about DICOM value locators in the mid-tier Java API |
Oracle Multimedia DICOM now provides wildcard character syntax to enable iteration through all the components in a single predicate. See General Format for DICOM Value Locators for reference information about the wildcard character. See Section 10.2.2.5 for more information about this enhancement.
These new preference parameters can be used in a preference document to define the run-time behavior of Oracle Multimedia DICOM:
BINARY_SKIP_INVALID_ATTR
Oracle Multimedia DICOM now supports the ability to specify whether to include or skips invalid attributes and their values in the binary output of DICOM content when making a copy of the DICOM Part 10 file. See Section 10.2.6.1 for more information about defining this preference parameter in a preference document.
MANDATE_ATTR_TAGS_IN_STL
Oracle Multimedia DICOM now supports the ability to specify whether to enforce the rule that all tags used by the constraint and mapping documents must be listed in the stored tag list document. See Section 10.2.6.3 for more information about defining this preference parameter in a preference document.
MAX_RECURSION_DEPTH
Oracle Multimedia DICOM now supports the ability to specify the maximum level of recursion to use when evaluating recursive constraint macros during conformance validation. See Section 10.2.6.4 for more information about defining this preference parameter in a preference document. See Section 10.2.2.4 for samples of recursive constraint macros.
SPECIFIC_CHARACTER_SET
Oracle Multimedia DICOM now supports the ability to specify a character set to override the default (ISO-IR 6 or ASCII) when the Specific Character Set attribute (0008,0005) is missing. See Section 10.2.6.5 for more information about defining this preference parameter in a preference document.
SQ_WRITE_LEN
Oracle Multimedia DICOM now supports the ability to specify how the method writeMetadata( ) encodes DICOM sequence (SQ) types. See Section 10.2.6.6 for more information about defining this preference parameter in a preference document.
See Section 10.1.6 and Section 10.2.6 for more information about preference documents. See Section B.8 for a listing of the preference document schema that constrains preference documents.
Oracle Multimedia DICOM now supports the processing of multiframe DICOM content such as MRIs, CTs, and Ultrasound videos to the data format Microsoft Video for Windows Audio Video Interleave (AVI). See Section D.5 for more information about this enhancement.
Oracle Multimedia DICOM now supports the DEFLATE compression format. See Section D.1.1 for more information about this enhancement.
Oracle Multimedia DICOM now supports the writing of DICOM images with the RLE compression format. See Section D.1.3 and Table D-2 for more information about this enhancement.
Oracle Multimedia DICOM now supports YBR photometric interpretation. See Table D-1 for more information about this enhancement.
Oracle Multimedia DICOM now supports the encoding of multibit monochrome raw content. See Table D-2 for more information about this enhancement.
Oracle Data Pump Utilities support is now available for the DICOM data model repository. See Section 9.9 for guidelines and examples that use the Oracle Data Pump commands expdp and impdp to perform export and import operations on the DICOM data model repository.
|
See Also: Oracle Database Utilities for more information about the Oracle Data Pump Export and Import utilities |
This appendix lists the names of the DICOM configuration documents. These documents are loaded into the DICOM data model repository when Oracle Multimedia DICOM is installed.
The DICOM configuration documents are as follows:
Anonymity document (ordcman.xml)
Constraint document (ordcmct.xml, ordcmcmd.xml, ordcmcmc.xml)
Mapping document (ordcmmp.xml)
Preference document (ordcmpf.xml)
Private Dictionary document (ordcmpv.xml)
Standard Dictionary document (ordcmsd.xml)
Stored tag list document (optional)
UID Definition document (ordcmui.xml)
The latest versions of these documents are available as files in the ord/xml directory under <ORACLE_HOME> when Oracle Multimedia DICOM is installed.
The DICOM configuration documents are associated with one or more DICOM XML schemas. See Appendix B for information about these XML schemas.
This part contains user and reference information for developers of DICOM applications.
Part II includes these chapters:
anonymity document
An XML document that specifies the set of attributes to be made anonymous, and defines the actions required to make those attributes anonymous.
application conformance
The semantic consistency of DICOM content with regard to application-specific constraint rules, which can be stronger or weaker than rules in the DICOM standard. Administrators can define constraint documents to include user-defined rules that are specific to a particular organization.
configuration document
A unique document for each database instance that is applicable to all DICOM content stored in the database. Configuration documents are managed by the repository. Examples include private and standard dictionary documents, mapping documents, constraint documents, and preference documents.
conformance validation
The process of checking the conformance of DICOM content against a set of constraint documents that define rules with which to validate conformance. Oracle extends conformance validation to DICOM metadata documents as well.
constraint document
An XML document that defines a collection of rules to validate the conformance of DICOM content, according to the DICOM standard and other organization-wide guidelines. Constraint documents specify the relationships and semantic constraints of attributes that are not expressed by the DICOM metadata schema. Constraint documents are based on the SOP class specification defined in Part 3 of the DICOM standard. Administrators can define constraint documents to include user-defined rules that are specific to a particular organization.
constraint macro
A simplified definition of a complex constraint rule. Constraint macros can be defined as global macros, and follow the same predicate definition grammar as constraint rules. Constraint macros can include predicate operands, which can contain macro parameters that are replaced with parameter values when the macro is invoked. Constraint macros can also be recursive, which is useful when specifying validation requirements for hierarchical or recursive structured DICOM content.
constraint predicate
A definition of a condition that operates on individual attributes or sets of attributes in the DICOM content. A constraint 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.
constraint rule
A collection of rules to validate the conformance of DICOM content according to the DICOM standard. These rules are defined in constraint documents, which specify the relationships and semantic rules of attributes that are not expressed by the DICOM metadata schema. Administrators can define constraint documents to include user-defined rules that are specific to a particular organization.
data model repository
A set of collectively managed, user-configurable documents that defines the run-time behavior of Oracle Multimedia DICOM. Administrators can update the repository to configure Oracle Multimedia DICOM for a particular database instance.
DICOM attribute tag
An encoded representation of the metadata within DICOM content that can be used with XML schemas. DICOM attribute tags include standard tags, which are supported by the DICOM standard, and user-defined private tags. DICOM attribute tags contain a group number and an element number.
DICOM conformance validator
A utility that checks the syntactical and semantic consistency of DICOM content in accordance with constraint rules specified in the data model repository.
DICOM content
Multiple standalone DICOM Information Objects that are structured and encoded as defined in Part 10 of the DICOM standard (commonly referred to as DICOM Part 10 files). For more information, see the DICOM standard on the NEMA Web site at
DICOM data type definition schema
An XML schema that defines the value representations (DICOM data types) provided in Part 5 of the DICOM standard. This data type definition schema is strongly coupled with the DICOM parser. It is designed by Oracle, the content is fixed, and it ships with Oracle Multimedia.
DICOM image
Any DICOM content that can be decomposed into 2-D pixel arrays. Examples include a video segment, a volume scan, and a single-frame dental image.
DICOM metadata document
An XML document that contains the metadata, as encoded attributes, extracted from DICOM content. Oracle provides methods to build a metadata document from DICOM content. Each metadata schema requires a mapping document that defines how attributes from the DICOM content are to be mapped into an XML document that conforms to the schema. In addition, each metadata schema references the DICOM data type definition schema.
DICOM Part 10 file
A standalone DICOM Information Object, which is constructed in accordance with the data structure and encoding definitions specified in Part 10 of the DICOM standard. For more information, see the DICOM standard on the NEMA Web site at
DICOM standard
The dominant standard for radiology imaging and communication to which all major manufacturers conform. The DICOM standard is primarily developed and maintained by working groups of domain experts. A new version is usually published once a year. The standard is available worldwide from the National Electrical Manufacturers Association (NEMA) Web site at
DICOM value locator
A DICOM type that identifies an attribute in the DICOM content, either at the root level or from the root level down. Each level in the tree hierarchy is represented by a sublocator.
DICOM volume scan
A set of images gathered in a single imaging operation. These images can be stored as separate slices in multiple ORDDicom objects. Or, they can be stored as single ORDDicom multiframe objects.
DICOM XML encoder
A utility that converts the in-memory structure of the extracted DICOM attributes into an XML document.
Digital Imaging and Communications in Medicine (DICOM)
A medical imaging standard initiated by the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) to enhance the connectivity of radiological devices.
image processor
A utility that includes Java Advanced Imaging (JAI). This utility provides support for operations such as producing thumbnail-size images and converting between DICOM and other supported image formats. When used with Oracle Multimedia DICOM methods, this utility supports import and export operations between the database and operating system files (external file storage).
information object
An object-oriented representation of a real world entity in DICOM. Examples include images and waveforms captured by imaging devices.
manifest document
An XML file that is created when exporting a set of configuration documents from a DICOM repository, and used when importing a set of configuration documents into a DICOM repository. For each configuration document within the set to be imported, the manifest document specifies the name of the configuration document, the document type, and the load order. The default manifest document is ordcmmft.xml. This document conforms to the registered XML schema ordcmmft.xsd.
mapped attribute
A part of a DICOM data element whose XML path is explicitly defined in a mapping document.
unmapped attribute
A part of a DICOM data element whose XML path is not explicitly defined in a mapping document.
mapping document
An XML document that defines how each attribute maps to a particular element of a DICOM XML metadata document. This document determines the structure of the extracted XML representation of the DICOM metadata.
metadata encoding
The process of encoding the extracted DICOM attributes into a DICOM metadata document.
metadata schema
The XML schema document that constrains the DICOM metadata document. This schema references the DICOM data type definition schema. Oracle supports customization of the metadata schema for each instance of the database. Oracle ships a default metadata schema with Oracle Multimedia. Administrators can update the default metadata schema and the corresponding mapping document to define a schema that is specific to the database instance.
nonscalar attribute
A property of DICOM value locators that exists when the last attribute tag in an array is specified as DICOM type SQ, OW, OB, OF, or UN.
Oracle interMedia
In Oracle Database 11g Release 1 (11.1), the name Oracle interMedia was changed to Oracle Multimedia.
ORDDicom database object
A database object used to encapsulate DICOM content and extracted attributes. The database object has public member methods that permit the querying and processing of ORDDicom objects.
preference document
An XML document that defines a set of run-time parameters, such as specifying whether Oracle Multimedia DICOM skips invalid attributes and their values in the binary output of DICOM content when making a copy of DICOM content. Oracle ships a default preference document with Oracle Multimedia. Administrators can update the default preference document to change the run-time behavior. For example, administrators can specify whether to validate XML documents used in DICOM functions and procedures or cause attributes larger than a specified size to be omitted when encoding attributes into XML.
private attributes
A set of attributes defined by an organization and encoded in DICOM content according to the encoding rules set by that organization for those attributes. Private attributes can add modality-specific, manufacturer-specific, or site-specific information to DICOM content. Private attributes are not administered by the DICOM standard, and they are generally not known or used by any organization other than the one that defined the private attributes.
private dictionary document
A document that lists the private attributes in the data dictionary. A data dictionary can contain one or more private dictionary documents. Each private dictionary document contains the definitions for a set of private attributes and the UID of the organization that defined the private attributes. Private dictionary documents can be published by Oracle or a third party. DICOM administrators can add new private dictionary documents to the data dictionary as they become available. Private dictionary documents enable users to extend the standard dictionary document definitions by adding manufacturer-specific or enterprise-specific attributes to DICOM content. Private dictionary documents are constrained by private dictionary schemas.
repository
A library used to store documents that are applicable to all ORDDicom objects stored in a database instance. Administrators can access the repository and update the documents stored in it. Changes made to these documents change the outcome of the affected Oracle Multimedia DICOM methods and procedures. Examples of documents stored in the repository include mapping documents, data dictionary documents, and constraint documents. At run time, a specified method is used to query the repository to obtain the latest copy of these documents. For example, a DICOM administrator can update an attribute definition in a data dictionary document and change its data type from DA (date) to DT (date time). From that point forward, after setting to the new data model the parser interprets the attribute as an instance of the DT data type, and the metadata encoder encodes the attribute as DT in all future metadata documents.
scalar attribute
A property of DICOM value locators in an array of attribute tags for supported DICOM types.
schema validation
The process of using an XML schema definition to validate an XML document that is constrained by the schema. Schema validation enables users to confirm the correctness of data types, data formats, and data hierarchies. Schema validation applies to XML documents only. It does not apply to DICOM content.
SOP class
A service object pair (SOP) class. This class is used to model a category of information object and a set of operations associated with that information object.
standard attributes
The set of attributes defined by the DICOM Standards Committee, which is published in Part 6 of the DICOM standard. Standard attributes can be modified or deprecated by the DICOM Standards Committee in the future. The number of standard attributes increases each year as the DICOM standard expands to include new areas of technology.
standard dictionary document
A document that lists the attributes defined by the DICOM standard. The DICOM standard dictionary document is converted from Part 6 of the DICOM standard. The DICOM Standards Committee expects to publish this document in XML format in the future. Oracle software releases include a copy of the standard dictionary document tied to a particular release of the DICOM standard. Administrators can update this standard dictionary document to reflect the most recent changes made by the DICOM Standards Committee.
standards conformance
The syntactical and semantic consistency of DICOM content with regard to the DICOM standard. The default constraint document that Oracle ships with Oracle Multimedia defines rules that enforce conformance with parts of the DICOM standard.
stored tag list document
An optional XML document that specifies the DICOM attributes to be extracted from the embedded DICOM content and stored in the XML metadata attribute of the ORDDicom object when the setProperties( ) method is called. Generally, stored tag list documents contain the attribute tags used in mapping and constraint documents.
transfer syntax
Encoding rules for medical imaging that specify how to encode DICOM content into a binary stream. These rules also specify how to compress the data content. Supported DICOM compression schemes (codecs) include RLE, JPEG, and JPEG2000.
UID definition document
An XML document that lists unique identifiers (UIDs) defined by the DICOM standard or a private organization. Rather than defining the DICOM content UIDs, UID definition documents contain a registry of standard UIDs that classify the DICOM content and express standard semantics.
unique identifier (UID)
A 64-byte, dot-concatenated, numeric string (similar to an IP address). The UID is based on an ISO object identifier (OID). It is commonly constructed with a root that uniquely identifies the organization producing the DICOM content, and a suffix that uniquely identifies the DICOM content within that organization.
value multiplicity
A constraint rule that specifies how many times the value of an attribute can be repeated. It is part of the standard attribute specification (defined in Part 6 of the DICOM standard).
value representation
The data type, as defined by the DICOM standard. The DICOM standard defines standard data types in Part 5. See the XML schema ordcmrdt.xsd (available in the ord/dicom/xml/xsd directory under <ORACLE_HOME>) for more information about the data types supported by Oracle Multimedia DICOM.
XML mapping document
An XML document used to define how to map DICOM attributes to elements in the DICOM metadata document. The XML mapping document is used by the metadata encoder to produce a DICOM metadata document. Because the metadata document is constrained by the metadata schema, the XML mapping document must match the metadata schema. Oracle Multimedia defines a default mapping document that coincides with the DICOM metadata schema. Administrators can update the mapping document and the corresponding metadata schema to define a schema that is specific to each database instance.
DICOM Developer's Guide
11g Release 2 (11.2)
E10778-03
August 2010
Oracle Multimedia DICOM enables Oracle Database to store, manage, and retrieve DICOM content such as single-frame and multiframe images, waveforms, slices of 3-D volumes, video segments, and structured reports in an integrated fashion with other enterprise information. Oracle Multimedia DICOM extends Oracle Database reliability, availability, and data management to media objects in medical applications.
Oracle Multimedia DICOM supports Digital Imaging and Communications in Medicine, the standard for medical images.
Oracle Multimedia DICOM Developer's Guide, 11g Release 2 (11.2)
E10778-03
Copyright © 2007, 2010, Oracle and/or its affiliates. All rights reserved.
Primary Author: Sue Pelski
Contributors: Rob Abbott, Melliyal Annamalai, Janet Blowney, Fengting Chen, Dongbai Guo, Dong Lin, Susan Mavris, Valarie Moore, David Noblet, James Steiner, Yingmei Sun, Manjari Yalavarthy, Jie Zhang
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
This software is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications which may create a risk of personal injury. If you use this software in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use of this software. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software in dangerous applications.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.
This software and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.
Oracle Multimedia DICOM provides a relational interface, which is defined in the ORD_DICOM PL/SQL package. This package provides the same features as those provided by the ORDDicom object interface, in the relational environment. The DICOM relational interface adds Oracle Multimedia support to medical image data stored in BLOBs and BFILEs, rather than in the ORDDicom object type.
Application developers who create medical imaging applications without using the Oracle Multimedia ORDDicom object type to store and manage medical image data in relational tables can use the Oracle Multimedia DICOM relational interface to manage their medical image data. In addition, application developers who do not want to migrate their existing medical image applications to use Oracle Multimedia ORDDicom objects can use this relational interface to manage their medical image data.
The ORD_DICOM package is defined in the ordcpksp.sql file. After installation, this file is available in the Oracle home directory at:
<ORACLE_HOME>/ord/im/admin (on Linux and UNIX)
<ORACLE_HOME>\ord\im\admin (on Windows)
This chapter describes the functions and procedures in the DICOM relational interface. See Table 3-1 for information about other DICOM application programming interfaces (APIs).
This chapter contains these sections:
The functions and procedures for the DICOM relational interface described in this chapter show examples based on the MEDICAL_IMAGE_REL table, which these examples create in the Product Media (PM) sample schema. See Section 8.1.2 when reading through these examples.
Before using DICOM relational interface functions and procedures, you must load some data into the table. For example, you can use SQL*Loader or the importFrom( ) procedure. Substitute your DICOM files for those in the examples.
Issue the following statements before executing the examples, where c:\mydir\work is the directory where the user pm can find the DICOM files:
CREATE OR REPLACE DIRECTORY DICOMDIR as 'c:\mydir\work'; GRANT READ, WRITE ON DIRECTORY DICOMDIR TO pm;
|
Note: At the beginning of each database session, call the setDataModel( ) procedure. See the setDataModel( ) Procedure for more information. |
Before loading data into the table, you must create the table and columns where the data is to be stored. The following PL/SQL code segment creates the MEDICAL_IMAGE_REL table with five columns.
CONNECT pm
Enter password: password
CREATE TABLE MEDICAL_IMAGE_REL
(
id integer primary key,
blob_src blob,
bfile_src bfile,
image_src ordsys.ordimage,
blob_dest blob
);
COMMIT;
where:
blob_src: the source DICOM content in the BLOB.
bfile_src: the source DICOM content in the BFILE.
image_src: the source DICOM content in the ORDImage object.
blob_dest: the destination DICOM content in the BLOB.
The ORD_DICOM package defines these DICOM relational functions:
Format
extractMetadata( data IN BFILE, extractOption IN VARCHAR2 DEFAULT 'ALL', docName IN VARCHAR2 DEFAULT 'ordcmmp.xml') RETURN SYS.XMLTYPE
Description
Returns the DICOM metadata as an XML document for a specified mapping document. The default mapping document refers to the default metadata namespace http://xmlns.oracle.com/ord/dicom/metadata_1_0.
Parameters
The input DICOM content stored in a BFILE.
A string that specifies the types of metadata to extract from the DICOM content. Valid values are: ALL, MAPPED, and STANDARD. The default is ALL.
When the value of the extractOption parameter is ALL, all attributes in the DICOM content are extracted. When the value is set to MAPPED, only mapped attributes are extracted. And, when the value is set to STANDARD, only attributes that conform to the DICOM standard and mapped attributes are extracted.
The name of the mapping document. The default mapping document ordcmmp.xml is loaded during installation.
Pragmas
None.
Exceptions
None.
Usage Notes
Use the preference parameter XML_SKIP_ATTR to specify size limits for DICOM attributes to be omitted when encoding into XML. See Section 10.2.6.8 for more information about this preference parameter.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against a specific XML schema that is registered with Oracle XML DB. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Extract metadata from the DICOM content stored in a BFILE:
declare src bfile; metadata xmltype; begin select bfile_src into src from medical_image_rel where id = 1 for update; metadata := ord_dicom.extractMetadata(src, 'all', 'ordcmmp.xml'); end; /
Format
extractMetadata( data IN BLOB, extractOption IN VARCHAR2 DEFAULT 'ALL', docName IN VARCHAR2 DEFAULT 'ordcmmp.xml') RETURN SYS.XMLTYPE
Description
Returns the DICOM metadata as an XML document for a specified mapping document. The default mapping document refers to the default metadata namespace http://xmlns.oracle.com/ord/dicom/metadata_1_0.
Parameters
The input DICOM content stored in a BLOB.
A string that specifies the types of metadata to extract from the DICOM content. Valid values are: ALL, MAPPED, and STANDARD. The default is ALL.
When the value of the extractOption parameter is ALL, all attributes in the DICOM content are extracted. When the value is set to MAPPED, only mapped attributes are extracted. And, when the value is set to STANDARD, only attributes that conform to the DICOM standard and mapped attributes are extracted.
The name of the mapping document. The default mapping document ordcmmp.xml is loaded during installation.
Pragmas
None.
Exceptions
None.
Usage Notes
Use the preference parameter XML_SKIP_ATTR to specify size limits for DICOM attributes to be omitted when encoding into XML. See Section 10.2.6.8 for more information about this preference parameter.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against a specific XML schema that is registered with Oracle XML DB. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Extract metadata from the DICOM content stored in a BLOB:
declare src blob; metadata xmltype; begin select blob_src into src from medical_image_rel where id = 1 for update; metadata := ord_dicom.extractMetadata(src, 'all', 'ordcmmp.xml'); end;
Format
extractMetadata( data IN ORDSYS.ORDImage, extractOption IN VARCHAR2 DEFAULT 'ALL', docName IN VARCHAR2 DEFAULT 'ordcmmp.xml') RETURN SYS.XMLTYPE
Description
Returns the DICOM metadata as an XML document for a specified mapping document. The default mapping document refers to the default metadata namespace http://xmlns.oracle.com/ord/dicom/metadata_1_0.
Parameters
The input DICOM content stored in an ORDImage object.
A string that specifies the types of metadata to extract from the DICOM content. Valid values are: ALL, MAPPED, and STANDARD. The default is ALL.
When the value of the extractOption parameter is ALL, all attributes in the DICOM content are extracted. When the value is set to MAPPED, only mapped attributes are extracted. And, when the value is set to STANDARD, only attributes that conform to the DICOM standard and mapped attributes are extracted.
The name of the mapping document. The default mapping document ordcmmp.xml is loaded during installation.
Pragmas
None.
Exceptions
None.
Usage Notes
Use the preference parameter XML_SKIP_ATTR to specify size limits for DICOM attributes to be omitted when encoding into XML. See Section 10.2.6.8 for more information about this preference parameter.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against a specific XML schema that is registered with Oracle XML DB. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Extract metadata from the DICOM content stored in an ORDImage object:
declare src ordimage; metadata xmltype; begin select image_src into src from medical_image_rel where id = 1 for update; metadata := ord_dicom.extractMetadata(src, 'all', 'ordcmmp.xml'); end; /
Format
isAnonymous( src IN BFILE, anonymityDocName IN VARCHAR2 DEFAULT 'ordcman.xml') RETURN INTEGER
Description
Determines whether the input DICOM content is anonymous, using a specified anonymity document. This function returns a value of 1 if the data is anonymous; otherwise it returns a value of 0.
Parameters
The input DICOM content stored in a BFILE.
The name of the anonymity document. The default name is ordcman.xml.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Check if the DICOM content stored in a BFILE is anonymous:
select ord_dicom.isAnonymous(t.bfile_src, 'ordcman.xml') from medical_image_rel t where id = 1;
Format
isAnonymous( src IN BLOB, anonymityDocName IN VARCHAR2 DEFAULT 'ordcman.xml') RETURN INTEGER
Description
Determines whether the input DICOM content is anonymous, using a specified anonymity document. This function returns a value of 1 if the data is anonymous; otherwise it returns a value of 0.
Parameters
The input DICOM content stored in a BLOB.
The name of the anonymity document. The default name is ordcman.xml.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Check if the DICOM content stored in a BLOB is anonymous:
select ord_dicom.isAnonymous(t.blob_src, 'ordcman.xml') from medical_image_rel t where id = 1;
Format
isAnonymous( src IN ORDSYS.ORDImage, anonymityDocName IN VARCHAR2 DEFAULT 'ordcman.xml') RETURN INTEGER
Description
Determines whether the input DICOM content is anonymous, using a specified anonymity document. This function returns a value of 1 if the data is anonymous; otherwise it returns a value of 0.
Parameters
The input DICOM content stored in an ORDImage object.
The name of the anonymity document. The default name is ordcman.xml.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Check if the DICOM content stored in an ORDImage object is anonymous:
select ord_dicom.isAnonymous(t.image_src, 'ordcman.xml') from medical_image_rel t where id = 1;
Format
isConformanceValid( src IN BFILE, constraintName IN VARCHAR2 ) RETURN INTEGER
Description
Performs a conformance validation check to determine whether the input DICOM content conforms to a specified set of constraints identified by the constraintName parameter. This method returns a value of 1 if conformance is valid; otherwise it returns a value of 0.
This method also logs error messages from the constraint documents, which can be viewed by querying the public view orddcm_conformance_vld_msgs. The public view orddcm_constraint_names contains the list of constraint names.
Parameters
The input DICOM content stored in a BFILE.
The name of the constraint to be used for conformance validation checking.
Pragmas
None.
Exceptions
None.
Usage Notes
If this method is called from a SQL query, ensure that the constraint rule definition does not contain any <ACTION> elements.
Use the preference parameter EXP_IF_NULL_ATTR_IN_CONSTRAINT to indicate whether to throw exceptions when encountering missing attributes or null attribute values during conformance validation. See Section 10.2.6.2 for more information about this preference parameter.
Examples
Delete any existing conformance validation messages. Check if the DICOM content stored in a BFILE is conformance valid. Then, show any new conformance validation messages that are generated.
-- clear the previous conformance validation messages
delete from orddcm_conformance_vld_msgs;
-- conformance validate the DICOM content
declare
src bfile;
begin
select bfile_src into src from medical_image_rel where id = 1;
dbms_output.put_line('isConformanceValid(PatientModule) ' ||
ord_dicom.isConformanceValid(src, 'PatientModule'));
end;
/
-- get the logged conformance validation messages
select message, msg_time time from orddcm_conformance_vld_msgs
where rule_name='PatientModule';
Format
isConformanceValid( src IN BLOB, constraintName IN VARCHAR2 ) RETURN INTEGER
Description
Performs a conformance validation check to determine whether the input DICOM content conforms to a specified set of constraints identified by the constraintName parameter. This method returns a value of 1 if conformance is valid; otherwise it returns a value of 0.
This method also logs error messages from the constraint documents, which can be viewed by querying the public view orddcm_conformance_vld_msgs. The public view orddcm_constraint_names contains the list of constraint names.
Parameters
The input DICOM content stored in a BLOB.
The name of the constraint to be used for conformance validation checking.
Pragmas
None.
Exceptions
None.
Usage Notes
If this method is called from a SQL query, ensure that the constraint rule definition does not contain any <ACTION> elements.
Use the preference parameter EXP_IF_NULL_ATTR_IN_CONSTRAINT to indicate whether to throw exceptions when encountering missing attribtues or null attribute values during conformance validation. See Section 10.2.6.2 for more information about this preference parameter.
Examples
Delete any existing conformance validation messages. Check if the DICOM content stored in a BLOB is conformance valid. Then, show any new conformance validation messages that are generated.
-- clear the previous conformance validation messages
delete from orddcm_conformance_vld_msgs;
-- conformance validate the DICOM content
declare
src blob;
begin
select blob_src into src from medical_image_rel where id = 1;
dbms_output.put_line('isConformanceValid(PatientModule) ' ||
ord_dicom.isConformanceValid(src, 'PatientModule'));
end;
/
-- get the logged conformance validation messages
select message, msg_time time from orddcm_conformance_vld_msgs
where rule_name='PatientModule';
Format
isConformanceValid( src IN ORDSYS.ORDImage, constraintName IN VARCHAR2 ) RETURN INTEGER
Description
Performs a conformance validation check to determine whether the input DICOM content conforms to a specified set of constraints identified by the constraintName parameter. This method returns a value of 1 if conformance is valid; otherwise it returns a value of 0.
This method also logs error messages from the constraint documents, which can be viewed by querying the public view orddcm_conformance_vld_msgs. The public view orddcm_constraint_names contains the list of constraint names.
Parameters
The input DICOM content stored in an ORDImage object.
The name of the constraint to be used for conformance validation checking.
Pragmas
None.
Exceptions
None.
Usage Notes
If this method is called from a SQL query, ensure that the constraint rule definition does not contain any <ACTION> elements.
Use the preference parameter EXP_IF_NULL_ATTR_IN_CONSTRAINT to indicate whether to throw exceptions when encountering missing attributes or null attribute values during conformance validation. See Section 10.2.6.2 for more information about this preference parameter.
Examples
Delete any existing conformance validation messages. Check if the DICOM content stored in an ORDImage object is conformance valid. Then, show any new conformance validation messages that are generated.
-- clear the previous conformance validation messages
delete from orddcm_conformance_vld_msgs;
-- conformance validate the DICOM content
declare
src ordimage;
begin
select image_src into src from medical_image_rel where id = 1;
dbms_output.put_line('isConformanceValid(PatientModule) ' ||
ord_dicom.isConformanceValid(src, 'PatientModule'));
end;
/
-- get the logged conformance validation messages
select message, msg_time time from orddcm_conformance_vld_msgs
where rule_name='PatientModule';
The ORD_DICOM package defines these DICOM relational procedures:
|
Note: In this section, <unique-UID> represents a 64-byte, dot-concatenated, numeric string that represents a globally unique identifier for DICOM content worldwide. The UID is commonly constructed with a root that uniquely identifies the organization producing the DICOM content, and a suffix that uniquely identifies the DICOM content within that organization. For some examples in this section, you must replace <unique-UID> with the appropriate UID. |
Format
createDicomImage( src IN BFILE, metadata IN SYS.XMLTYPE, dest IN OUT NOCOPY BLOB)
Description
Creates a DICOM image from a source image and DICOM metadata.
Parameters
The source raster image stored in a BFILE.
DICOM metadata stored in data type XMLType. The metadata must include all standard and private attributes. It must include a new SOP instance UID for the destination DICOM image, ensuring that the destination DICOM content is globally unique.
An empty BLOB in which to store the DICOM image created from the source image and metadata.
Pragmas
None.
Exceptions
None.
Usage Notes
See Appendix C for information about the encoding rules that support image content processing.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Create a DICOM image from a source BFILE and DICOM metadata:
declare
src bfile;
dest blob;
metadata xmltype;
begin
metadata := xmltype(bfilename('DICOMDIR', 'wm_meta.xml'),
nls_charset_id('AL32UTF8'),
'http://xmlns.oracle.com/ord/dicom/metadata_1_0');
select bfile_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.createDicomImage(src, metadata, dest);
end;
/
Format
createDicomImage( src IN BLOB, metadata IN SYS.XMLTYPE, dest IN OUT NOCOPY BLOB)
Description
Creates a DICOM image from a source image and DICOM metadata.
Parameters
The source raster image stored in a BLOB.
DICOM metadata stored in data type XMLType. The metadata must include all standard and private attributes. It must include a new SOP instance UID for the destination DICOM image, ensuring that the destination DICOM content is globally unique.
An empty BLOB in which to store the DICOM image created from the source image and metadata.
Pragmas
None.
Exceptions
None.
Usage Notes
See Appendix C for information about the encoding rules that support image content processing.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Create a DICOM image from a source BLOB and DICOM metadata:
declare
src blob;
dest blob;
metadata xmltype;
begin
metadata := xmltype(bfilename('DICOMDIR', 'wm_meta.xml'),
nls_charset_id('AL32UTF8'),
'http://xmlns.oracle.com/ord/dicom/metadata_1_0');
select blob_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.createDicomImage(src, metadata, dest);
end;
/
Format
createDicomImage( src IN ORDSYS.ORDImage, metadata IN SYS.XMLTYPE, dest IN OUT NOCOPY BLOB)
Description
Creates a DICOM image from a source image and DICOM metadata.
Parameters
The source raster image stored in an ORDImage object.
DICOM metadata stored in data type XMLType. The metadata must include all standard and private attributes. It must include a new SOP instance UID for the destination DICOM image, ensuring that the destination DICOM content is globally unique.
An empty BLOB in which to store the DICOM image created from the source image and metadata.
Pragmas
None.
Exceptions
None.
Usage Notes
See Appendix C for information about the encoding rules that support image content processing.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Create a DICOM image from a source ORDImage object and DICOM metadata:
declare
src ordimage;
dest blob;
metadata xmltype;
begin
metadata := xmltype(bfilename('DICOMDIR', 'wm_meta.xml'),
nls_charset_id('AL32UTF8'),
'http://xmlns.oracle.com/ord/dicom/metadata_1_0');
select image_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.createDicomImage(src, metadata, dest);
end;
/
Format
export( src IN BLOB, dest_type IN VARCHAR2, dest_location IN VARCHAR2, dest_name IN VARCHAR2)
Description
Exports DICOM content in a BLOB to a specified destination. The data remains in the source BLOB when it is copied to the destination.
Parameters
The source location of the DICOM content.
The type of the destination (only FILE is supported).
The location of the destination (must be a valid Oracle directory object).
The name of the destination file.
Pragmas
None.
Exceptions
None.
Usage Notes
The export( ) procedure writes only to a database directory object that the user has privilege to access. That is, you can access a directory object that you have created using the SQL statement CREATE DIRECTORY, or one to which you have been granted READ and WRITE access.
For example, the following SQL*Plus commands create a directory object and grant the user pm permission to read and write to any file within the directory c:\mydir\work:
CONNECT sys as sysdba
Enter password: password
CREATE OR REPLACE DIRECTORY DICOMDIR AS 'c:\mydir\work';
GRANT READ,WRITE ON DIRECTORY DICOMDIR TO pm;
See Section 8.1 for more information about these directory and table definitions.
Examples
Export DICOM content from a BLOB to a specified file:
declare src blob; begin select blob_src into src from medical_image_rel where id = 1; ord_dicom.export(src, 'FILE', 'DICOMDIR', 'exported.dcm'); end; /
Format
importFrom( dest IN OUT NOCOPY BLOB, source_type IN VARCHAR2, source_location IN VARCHAR2, source_name IN VARCHAR2)
Description
Imports DICOM content from a specified source into a BLOB.
Parameters
The storage destination of the imported DICOM file.
The type of the source (only FILE is supported).
The location of the source (must be a valid Oracle directory object).
The name of the source file.
Pragmas
None.
Exceptions
None.
Usage Notes
The importFrom( ) procedure reads only from a database directory object that the user has privilege to access. That is, you can access a directory object that you have created using the SQL statement CREATE DIRECTORY, or one to which you have been granted READ access.
For example, the following SQL*Plus commands create a directory object and grant the user pm permission to read any file within the directory c:\mydir\work:
CONNECT sys as sysdba
Enter password: password
CREATE OR REPLACE DIRECTORY DICOMDIR AS 'c:\mydir\work';
GRANT READ ON DIRECTORY DICOMDIR TO pm;
See Section 8.1 for more information about these directory and table definitions.
Examples
Import the DICOM content into a BLOB:
declare dest blob; begin select blob_dest into dest from medical_image_rel where id = 1 for update; ord_dicom.importFrom(dest, 'file', 'DICOMDIR', 'example.dcm'); end; /
Format
makeAnonymous( src IN BFILE, dest_sop_instance_uid IN VARCHAR2, dest IN OUT NOCOPY BLOB, anonymityDocName IN VARCHAR2 DEFAULT 'ordcman.xml')
Description
Removes patient identifying information from the source DICOM content after copying it into another DICOM content BLOB, based on a specified anonymity document.
Parameters
The input DICOM content stored in a BFILE.
The SOP instance UID of the destination DICOM content. It must ensure that the destination DICOM content is globally unique.
An empty BLOB in which to store the anonymous DICOM content.
The name of the anonymity document. The default name is ordcman.xml.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Remove patient identifying information from the embedded DICOM content stored in a BFILE:
|
Note: Replace <unique-UID> with the UID that identifies the organization producing the DICOM content and the DICOM content within that organization. |
declare
src bfile;
dest blob;
dest_sop_instance_uid varchar2(128) := '<unique-UID>';
begin
select bfile_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.makeAnonymous(src, dest_sop_instance_uid, dest, 'ordcman.xml');
end;
/
Format
makeAnonymous( src IN BLOB, dest_sop_instance_uid IN VARCHAR2, dest IN OUT NOCOPY BLOB, anonymityDocName IN VARCHAR2 DEFAULT 'ordcman.xml')
Description
Removes patient identifying information from the source DICOM content after copying it into another DICOM content BLOB, based on a specified anonymity document.
Parameters
The input DICOM content stored in a BLOB.
The SOP instance UID of the destination DICOM content. It must ensure that the destination DICOM content is globally unique.
An empty BLOB in which to store the anonymous DICOM content.
The name of the anonymity document. The default name is ordcman.xml.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Remove patient identifying information from the embedded DICOM content stored in a BLOB:
|
Note: Replace <unique-UID> with the UID that identifies the organization producing the DICOM content and the DICOM content within that organization. |
declare
src blob;
dest blob;
dest_sop_instance_uid varchar2(128) := '<unique-UID>';
begin
select blob_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.makeAnonymous(src, dest_sop_instance_uid, dest, 'ordcman.xml');
end;
/
Format
makeAnonymous( src IN ORDSYS.ORDImage, dest_sop_instance_uid IN VARCHAR2, dest IN OUT NOCOPY BLOB, anonymityDocName IN VARCHAR2 DEFAULT 'ordcman.xml')
Description
Removes patient identifying information from the source DICOM content after copying it into another DICOM content BLOB, based on a specified anonymity document.
Parameters
The input DICOM content stored in an ORDImage object.
The SOP instance UID of the destination DICOM content. It must ensure that the destination DICOM content is globally unique.
An empty BLOB in which to store the anonymous DICOM content.
The name of the anonymity document. The default name is ordcman.xml.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Remove patient identifying information from the embedded DICOM content stored in an ORDImage object:
|
Note: Replace <unique-UID> with the UID that identifies the organization producing the DICOM content and the DICOM content within that organization. |
declare
src ordimage;
dest blob;
dest_sop_instance_uid varchar2(128) := '<unique-UID>';
begin
select image_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.makeAnonymous(src, dest_sop_instance_uid, dest, 'ordcman.xml');
end;
/
Format
processCopy( src IN BFILE, command IN VARCHAR2, dest IN OUT NOCOPY BLOB)
Description
Reads the DICOM content that is input from the source BFILE, writes it to the destination BLOB, and then performs the specified processing operations on the destination BLOB. The original DICOM content that was input remains unchanged.
Parameters
The input DICOM content stored in the source BFILE.
A command string that accepts a processing operator as input. Valid values include: fileFormat, frame, contentFormat, compressionFormat, cut, scale, and rotate. See Appendix D for information about processing operators.
An empty BLOB in which to store the destination content.
Pragmas
None.
Exceptions
None.
Usage Notes
See Appendix C for information about the encoding rules that support DICOM content processing. See Appendix D for more information about DICOM processing.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Copy the DICOM content from a BFILE into a BLOB and then process it:
declare
src bfile;
dest blob;
begin
select bfile_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.processCopy(src, 'fileFormat=jpeg maxScale=100 100', dest);
end;
/
Format
processCopy(src IN BFILE, command IN VARCHAR2, dest_sop_instance_uid IN VARCHAR2, dest IN OUT NOCOPY BLOB, metadata IN SYS.XMLTYPE DEFAULT NULL)
Description
Reads the DICOM content that is input from the source BFILE, writes it to the destination BLOB, performs the specified processing operations on the destination BLOB, and then updates it with the new metadata. The original DICOM content that was input remains unchanged.
Parameters
The input DICOM content stored in the source BFILE.
A command string that accepts a processing operator as input. Valid values include: frame, contentFormat, compressionFormat, cut, scale, and rotate. See Appendix D for information about processing operators.
The SOP instance UID of the destination DICOM content. It must ensure that the destination DICOM content is globally unique.
An empty BLOB in which to store the destination content.
The new metadata to be written into the new DICOM content.
Pragmas
None.
Exceptions
None.
Usage Notes
See Appendix C for information about the encoding rules that support DICOM content processing. See Appendix D for more information about DICOM processing.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Copy the DICOM content from a BFILE into a BLOB with a specified SOP instance UID and then process it:
|
Note: Replace <unique-UID> with the UID that identifies the organization producing the DICOM content and the DICOM content within that organization. |
src bfile;
dest blob;
dest_sop_instance_uid varchar2(128) := '<unique-UID>';
begin
select bfile_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.processCopy(
src, 'CompressionFormat=jpeg', dest_sop_instance_uid, dest);
end;
/
Format
processCopy( src IN BLOB, command IN VARCHAR2, dest IN OUT NOCOPY BLOB)
Description
Reads the DICOM content that is input from the source BLOB, writes it to the destination BLOB, and then performs the specified processing operations on the destination BLOB. The original DICOM content that was input remains unchanged.
Parameters
The input DICOM content stored in the source BLOB.
A command string that accepts a processing operator as input. Valid values include: fileFormat, frame, contentFormat, compressionFormat, cut, scale, and rotate. See Appendix D for information about processing operators.
An empty BLOB in which to store the destination content.
Pragmas
None.
Exceptions
None.
Usage Notes
See Appendix C for information about the encoding rules that support DICOM content processing. See Appendix D for more information about DICOM processing.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Copy the DICOM content from a BLOB into another BLOB and then process it:
src blob;
dest blob;
begin
select blob_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.processCopy(src, 'fileFormat=jpeg maxScale=100 100' dest);
end;
/
Format
processCopy(src IN BLOB, command IN VARCHAR2, dest_sop_instance_uid IN VARCHAR2, dest IN OUT NOCOPY BLOB, metadata IN SYS.XMLTYPE DEFAULT NULL)
Description
Reads the DICOM content that is input from the source BLOB, writes it to the destination BLOB, performs the specified processing operations on the destination BLOB, and then updates it with the new metadata. The original DICOM content that was input remains unchanged.
Parameters
The input DICOM content stored in the source BLOB.
A command string that accepts a processing operator as input. Valid values include: frame, contentFormat, compressionFormat, cut, scale, and rotate. See Appendix D for information about processing operators.
The SOP instance UID of the destination DICOM content. It must ensure that the destination DICOM content is globally unique.
An empty BLOB in which to store the destination content.
The new metadata to be written into the new DICOM content.
Pragmas
None.
Exceptions
None.
Usage Notes
See Appendix C for information about the encoding rules that support DICOM content processing. See Appendix D for more information about DICOM processing.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Copy the DICOM content from a BLOB into another BLOB with a specified SOP instance UID and then process it:
|
Note: Replace <unique-UID> with the UID that identifies the organization producing the DICOM content and the DICOM content within that organization. |
declare
src blob;
dest blob;
dest_sop_instance_uid varchar2(128) := '<unique-UID>';
begin
select blob_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.processCopy(
src, 'CompressionFormat=jpeg', dest_sop_instance_uid, dest);
end;
/
Format
processCopy( src IN ORDSYS.ORDImage, command IN VARCHAR2, dest IN OUT NOCOPY BLOB)
Description
Reads the DICOM content that is input from the source ORDImage object, writes it to the destination BLOB, and then performs the specified processing operations on the destination BLOB. The original DICOM content that was input remains unchanged.
Parameters
The input DICOM content stored in the source ORDImage object.
A command string that accepts an image processing operator as input. Valid values include: fileFormat, frame, contentFormat, compressionFormat, cut, scale, and rotate. See Appendix D for information about image processing operators.
An empty BLOB in which to store the destination content.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this method to get a non-DICOM image that is suitable for presentation on the Web from the embedded DICOM content.
See Appendix C for information about the encoding rules that support image content processing. See Appendix D for more information about DICOM processing.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Copy the DICOM content from an ORDImage object into a BLOB and then process it:
declare
src ordimage;
dest blob;
begin
select image_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.processCopy(src, 'fileFormat=jpeg maxScale=100 100' dest);
end;
/
Format
processCopy(src IN ORDSYS.ORDImage, command IN VARCHAR2, dest_sop_instance_uid IN VARCHAR2, dest IN OUT NOCOPY BLOB, metadata IN SYS.XMLTYPE DEFAULT NULL)
Description
Reads the DICOM content that is input from the source ORDImage object, writes it to the destination BLOB, performs the specified processing operations on the destination BLOB, and then updates it with the new metadata. The original DICOM content that was input remains unchanged.
Parameters
The input DICOM content stored in the source ORDImage object.
A command string that accepts an image processing operator as input. Valid values include: frame, contentFormat, compressionFormat, cut, scale, and rotate. See Appendix D for information about image processing operators.
The SOP instance UID of the destination DICOM image. It must ensure that the destination DICOM content is globally unique.
An empty BLOB in which to store the destination content.
The new metadata to be written into the new DICOM content.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this method to get a non-DICOM image that is suitable for presentation on the Web fr#)om the embedded DICOM content.
See Appendix C for information about the encoding rules that support image content processing. See Appendix D for more information about DICOM processing.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Copy the DICOM content from an ORDImage object into a BLOB with a specified SOP instance UID and then process it:
|
Note: Replace <unique-UID> with the UID that identifies the organization producing the DICOM content and the DICOM content within that organization. |
declare
src ordimage;
dest blob;
dest_sop_instance_uid varchar2(128) := '<unique-UID>';
begin
select image_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.processCopy(
src, 'CompressionFormat=jpeg', dest_sop_instance_uid, dest);
end;
/
Format
writeMetadata( src IN BFILE, metadata IN SYS.XMLTYPE, dest IN OUT NOCOPY BLOB),
Description
Writes or modifies the current DICOM content with the metadata provided by making a copy of the existing DICOM content in the destination BLOB, and then modifying the metadata. The original DICOM content remains unchanged. The attributes in the destination DICOM content are copied from the metadata that was input.
Parameters
The input DICOM content stored in a BFILE.
The input metadata stored in data type XMLType. In the destination DICOM content, the input metadata is used to update the values for attributes that are identical to attributes in the source DICOM content, or to add any new attributes. The metadata must conform to the default metadata schema with the namespace http://xmlns.oracle.com/ord/dicom/metadata_1_0. The SOP instance UID in the metadata must ensure that the destination DICOM content is globally unique.
An empty BLOB in which to store the new DICOM content with the new metadata.
Pragmas
None.
Exceptions
None.
Usage Notes
See Appendix C for information about the encoding rules that support metadata extraction.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Use the preference parameter SQ_WRITE_LEN to specify how the DICOM sequence (SQ) types are encoded. See Section 10.2.6.6 for more information about this preference parameter.
Examples
Write the new metadata to the copy of the DICOM content in the destination BLOB:
declare
src bfile;
dest blob;
metadata xmltype;
begin
metadata := xmltype(bfilename('DICOMDIR', 'wm_meta.xml'),
nls_charset_id('AL32UTF8'),
'http://xmlns.oracle.com/ord/dicom/metadata_1_0');
select bfile_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.writeMetadata(src, metadata, dest);
end;
/
Format
writeMetadata( src IN BLOB, metadata IN SYS.XMLTYPE, dest IN OUT NOCOPY BLOB),
Description
Writes or modifies the current DICOM content with the metadata provided by making a copy of the existing DICOM content in the destination BLOB, and then modifying the metadata. The original DICOM content remains unchanged. The attributes in the destination DICOM content are copied from the metadata that was input.
Parameters
The input DICOM content stored in a BLOB.
The input metadata stored in data type XMLType. In the destination DICOM content, the input metadata is used to update the values for attributes that are identical to attributes in the source DICOM content, or to add any new attributes. The metadata must conform to the default metadata schema with the namespace http://xmlns.oracle.com/ord/dicom/metadata_1_0. The SOP instance UID in the metadata must ensure that the destination DICOM content is globally unique.
An empty BLOB in which to store the new DICOM content with the new metadata.
Pragmas
None.
Exceptions
None.
Usage Notes
See Appendix C for information about the encoding rules that support metadata extraction.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Use the preference parameter SQ_WRITE_LEN to specify how the DICOM sequence (SQ) types are encoded. See Section 10.2.6.6 for more information about this preference parameter.
Examples
Write the new metadata to the copy of the DICOM content in the destination BLOB:
declare
src blob;
dest blob;
metadata xmltype;
begin
metadata := xmltype(bfilename('DICOMDIR', 'wm_meta.xml'),
nls_charset_id('AL32UTF8'),
'http://xmlns.oracle.com/ord/dicom/metadata_1_0');
select blob_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.writeMetadata(src, metadata, dest);
end;
/
Format
writeMetadata( src IN ORDSYS.ORDImage, metadata IN SYS.XMLTYPE, dest IN OUT NOCOPY BLOB),
Description
Writes or modifies the current DICOM content with the metadata provided by making a copy of the existing DICOM content in the destination BLOB, and then modifying the metadata. The original DICOM content remains unchanged. The attributes in the destination DICOM content are copied from the metadata that was input.
Parameters
The input DICOM content stored in an ORDImage object.
The input metadata stored in data type XMLType. In the destination DICOM content, the input metadata is used to update the values for attributes that are identical to attributes in the source DICOM content, or to add any new attributes. The metadata must conform to the default metadata schema with the namespace http://xmlns.oracle.com/ord/dicom/metadata_1_0. The SOP instance UID in the metadata must ensure that the destination DICOM content is globally unique.
An empty BLOB in which to store the new DICOM content with the new metadata.
Pragmas
None.
Exceptions
None.
Usage Notes
See Appendix C for information about the encoding rules that support metadata extraction.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Use the preference parameter SQ_WRITE_LEN to specify how the DICOM sequence (SQ) types are encoded. See Section 10.2.6.6 for more information about this preference parameter.
Examples
Write the new metadata to the copy of the DICOM content in the destination BLOB:
declare
src ordimage;
dest blob;
metadata xmltype;
begin
metadata := xmltype(bfilename('DICOMDIR', 'wm_meta.xml'),
nls_charset_id('AL32UTF8'),
'http://xmlns.oracle.com/ord/dicom/metadata_1_0');
select image_src, blob_dest into src, dest from medical_image_rel
where id = 1 for update;
ord_dicom.writeMetadata(src, metadata, dest);
end;
/
This part contains user and reference information for administrators of the DICOM data model repository.
Part III includes these chapters:
This appendix briefly describes some sample SQL and PL/SQL scripts and an Oracle Application Express sample application that you can use with Oracle Multimedia DICOM. Table E-1 lists the name and the URL path of these sample programs, starting from this URL for the Oracle Technology Network (OTN) Products Web site
http://www.oracle.com/technology/products/
Table E-1 Oracle Multimedia DICOM Sample Programs
| Name | URL Path from OTN Products Web Site |
|---|---|
|
Managing DICOM Format Data in Oracle Database 11g |
|
|
DICOM Image Archive Demonstration |
|
This appendix includes these sections:
The sample scripts in Chapter 5 are provided to help you learn to develop applications using Oracle Multimedia DICOM to upload to the database, retrieve from it, and manipulate DICOM content.
Some sample scripts were extracted from the tutorial Managing DICOM Format Data in Oracle Database 11g, and adapted for this manual. You can find this tutorial, and other examples, on the Oracle Multimedia Web page of the Oracle Technology Network Web site as follows:
Start from the Oracle Technology Network Products Web site at
http://www.oracle.com/technology/products/
Then, enter the URL path for the DICOM tutorial, as listed in Table E-1.
Select Oracle Multimedia DICOM Tutorial under Quick Picks to go to the Web page Managing DICOM Format Data in Oracle Database 11g.
See Chapter 5 for more information about using these sample scripts with Oracle Multimedia DICOM.
The Oracle Multimedia DICOM Image Archive Demonstration sample application in Chapter 6 demonstrates the features of Oracle Multimedia DICOM to help you build custom applications. This sample application includes two user interfaces. The interface DICOM Image Archive is for clinicians and researchers; the interface DICOM Image Archive Administration is for administrators only.
This sample application, along with other packaged applications and sample code, is available on the Oracle Application Express Web page of the Oracle Technology Network Web site as follows:
Start from the Oracle Technology Network Products Web site at
http://www.oracle.com/technology/products/
Then, enter the URL path for the DICOM Image Archive Demonstration, as listed in Table E-1.
Select DICOM Image Archive Demonstration under Packaged Applications to download the Oracle Multimedia DICOM Image Archive Demonstration sample application.
See Chapter 6 for more information about using this sample application.
Oracle Multimedia provides the ORDDicom object type, which supports the storage, management, and manipulation of DICOM format medical images and other data. The ORDDicom object is intended as an object that is written only once. To generate a new ORDDicom object by image processing or compression, create a new ORDDicom object, ORDImage object, or BLOB.
The ORDDicom object type is defined in the ordcspec.sql file. After installation, this file is available in the Oracle home directory at:
<ORACLE_HOME>/ord/im/admin (on Linux and UNIX)
<ORACLE_HOME>\ord\im\admin (on Windows)
This chapter describes the attributes, constructors, and methods in the ORDDicom object interface. See Table 3-1 for information about other DICOM application programming interfaces (APIs).
This chapter contains these sections:
The examples in this chapter use the MEDICAL_IMAGE_OBJ table, which these examples create in the Product Media (PM) sample schema. See Section 7.1.2 when reading through these examples.
Before using ORDDicom methods, you must load some data into the table. For example, you can use the SQL*Loader utility, a Java client, or the import( ) method. Substitute your DICOM files for those in the examples.
|
Note: If you manipulate the DICOM content itself (by either directly modifying the BLOB or changing the external source), call the setProperties( ) method to ensure that the object attributes stay synchronized. You must also ensure that the update time is modified. Otherwise, the object attributes will not match the DICOM content.See the setProperties( ) method for more information. |
Issue the following statements before executing the examples, where c:\mydir\work is the directory where the user pm can find the DICOM files:
CREATE OR REPLACE DIRECTORY DICOMDIR as 'c:\mydir\work'; GRANT READ, WRITE ON DIRECTORY DICOMDIR TO pm;
|
Note: At the beginning of each database session, call the setDataModel( ) procedure. See the setDataModel( ) Procedure for more information. |
Before loading data into the table, you must create the table and columns where the data is to be stored. The following PL/SQL code segment creates the MEDICAL_IMAGE_OBJ table with five columns.
CONNECT pm
Enter password: password
CREATE TABLE MEDICAL_IMAGE_OBJ
(
id integer primary key,
dicom_src ordsys.orddicom,
dicom_dest ordsys.orddicom,
image_dest ordsys.ordimage,
blob_dest blob
);
COMMIT;
where:
dicom_src: the source DICOM content in the ORDDicom object.
dicom_dest: the destination DICOM content in the ORDDicom object.
image_dest: the destination DICOM content in the ORDImage object.
blob_dest: the destination DICOM content in the BLOB.
The ORDDicom object type supports the storage, management, and manipulation of DICOM format medical images and other data. The attributes for this object type are defined as follows in the ordcspec.sql file:
------------------- -- TYPE ATTRIBUTES ------------------- SOP_INSTANCE_UID VARCHAR2(128), SOP_CLASS_UID VARCHAR2(64), STUDY_INSTANCE_UID VARCHAR2(64), SERIES_INSTANCE_UID VARCHAR2(64), source ORDDataSource, metadata SYS.XMLType, contentLength INTEGER, flag INTEGER, extension BLOB,
where:
SOP_INSTANCE_UID: the SOP instance UID of the embedded DICOM content.
SOP_CLASS_UID: the SOP class UID of the embedded DICOM content.
STUDY_INSTANCE_UID: the study instance UID of the embedded DICOM content.
SERIES_INSTANCE_UID: the series instance UID of the embedded DICOM content.
source: the original DICOM content stored within the database, under transaction control as a BLOB (recommended), or stored in an operating system-specific file in a local file system with pointer stored in the database.
metadata: the XML metadata document extracted from the embedded DICOM content.
contentLength: the length of the embedded DICOM content, in number of bytes.
flag: an Oracle reserved attribute.
extension: an Oracle reserved attribute.
This section describes these ORDDicom constructor functions:
The ORDDicom object can be constructed using these constructors in a SQL statement or PL/SQL program.
The ORDDicom object has embedded BLOB attributes. BLOB locators must be initialized before they can be accessed. Thus, newly constructed ORDDicom objects (unless constructed from a temporary BLOB) must be inserted into a table before you can call object member methods on these ORDDicom objects.
Format
ORDDicom(SELF IN OUT NOCOPY ORDDicom, data IN BLOB, setproperties IN INTEGER DEFAULT 0) RETURN SELF AS RESULT
Description
Constructs an ORDDicom object from a BLOB. The data stored in the BLOB is copied into the ORDDicom object when the constructed ORDDicom object is inserted or updated into a table. The metadata conforms to the XML schema defined by the default mapping document.
Parameters
Embedded DICOM content stored in a BLOB.
Indicator flag that determines whether the DICOM attributes are extracted from the embedded DICOM content. If the value is 1, the DICOM attributes are extracted into the metadata attribute of the constructed ORDDicom object, and the attributes of the ORDDicom object are populated. If the value is 0, no DICOM attributes are extracted. The default is 0.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this constructor to create an ORDDicom object when the DICOM content is stored in either a temporary or a persistent BLOB.
Examples
Create an ORDDicom object from a BLOB:
SQL> desc blob_tbl;
Name Null? Type---------------------- -------- --------------------
ID NUMBER(38)DATA BLOB
insert into medical_image_obj (id, dicom_src)
select s.id, ORDDicom(s.data) from blob_tbl s;
Format
ORDDicom(SELF IN OUT NOCOPY ORDDicom, data IN ORDImage, setproperties IN INTEGER DEFAULT 0) RETURN SELF AS RESULT
Description
Constructs an ORDDicom object from an ORDImage object that has either a local source (BLOB) or a file source (BFILE). If the DICOM content is stored originally in the BLOB of the ORDImage object, the data is copied into the BLOB in the ORDDicom object source attribute when the constructed ORDDicom object is inserted or updated into a table. If the DICOM content is stored originally as a BFILE source of the ORDImage object, the srcType, srcLocation, and srcName parameters from the ORDImage source are copied into the source attribute of the ORDDicom object. The metadata conforms to the XML schema defined by the default mapping document.
Parameters
Embedded DICOM content stored in an ORDImage object.
Indicator flag that determines whether the DICOM attributes are extracted from the embedded DICOM content. If the value is 1, the DICOM attributes are extracted into the metadata attribute of the constructed ORDDicom object, and the attributes of the ORDDicom object are populated. If the value is 0, no DICOM attributes are extracted. The default is 0.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this constructor to create an ORDDicom object when the DICOM content is stored in an ORDImage object. Or, use this constructor to migrate an ORDImage object to an ORDDicom object.
Examples
Create an ORDDicom object from an ORDImage object:
SQL> desc image_tbl;
Name Null? Type---------------------- -------- --------------------
ID NUMBER(38)IMAGE ORDIMAGE
insert into medical_image_obj (id, dicom_src)
select s.id, ORDDicom(s.image) from image_tbl s;
Format
ORDDicom( SELF IN OUT NOCOPY ORDDicom, source_type IN VARCHAR2 DEFAULT 'LOCAL', source_location IN VARCHAR2 DEFAULT NULL, source_name IN VARCHAR2 DEFAULT NULL, setproperties IN INTEGER DEFAULT 0 ) RETURN SELF AS RESULT
Description
Constructs an ORDDicom object from a specific source. By default, the value of the source_type parameter is set to LOCAL, which means that the source of the data is stored locally in the database in a BLOB. With the default values, an empty object with a local source is constructed. If the value of the source_type parameter is set to FILE, an ORDDicom object is constructed with the source stored as an external FILE. The metadata conforms to the XML schema defined by the default XML mapping document.
Parameters
The type of the source. Valid values are: FILE or LOCAL. The default is LOCAL.
The directory location of the source (used for source_type=FILE).
The file name of the source (used for source_type=FILE).
Indicator flag that determines whether the DICOM attributes are extracted from the embedded DICOM content. If the value is 1, the DICOM attributes are extracted into the metadata attribute of the constructed ORDDicom object, and the attributes of the ORDDicom object are populated. If the value is 0, no DICOM attributes are extracted. The default is 0.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this constructor to create an ORDDicom object when the DICOM content is stored in the file system. Use the empty constructor when uploading DICOM content from a client, such as a Web browser or a Java application. Or, use the empty constructor as a destination object for methods such as processCopy( ), makeAnonymous( ), and writeMetadata( ).
Examples
Example 1:
Create an ORDDicom object from a file without populating the object attributes:
insert into medical_image_obj (id, dicom_src)
values (1, ORDDicom('FILE', 'DICOMDIR', 'example.dcm'));
Example 2:
Create an ORDDicom object from a file with the setProperties flag set:
insert into medical_image_obj (id, dicom_src)
values (2, ORDDicom('FILE', 'DICOMDIR', 'example.dcm', 1));
Example 3:
Create an empty ORDDicom object:
insert into medical_image_obj (id, dicom_src)
values (3, ORDDicom());
This section presents reference information about these ORDDicom methods:
|
Note: In this section, <unique-UID> represents a 64-byte, dot-concatenated, numeric string that represents a globally unique identifier for DICOM content worldwide. The UID is commonly constructed with a root that uniquely identifies the organization producing the DICOM content, and a suffix that uniquely identifies the DICOM content within that organization. For some examples in this section, you must replace <unique-UID> with the appropriate UID. |
Format
export(SELF IN ORDDicom, dest_type IN VARCHAR2, dest_location IN VARCHAR2, dest_name IN VARCHAR2)
Description
Exports embedded DICOM content to a specified destination. The data remains in the source BLOB when it is copied to the destination.
Parameters
The type of the destination (only FILE is supported).
The location of the destination (must be a valid Oracle directory object).
The name of the destination file.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this method to export the embedded DICOM content to the local file system.
The export( ) method writes only to a database directory object that the user has privilege to access. That is, you can access a directory object that you have created using the SQL statement CREATE DIRECTORY, or one to which you have been granted READ and WRITE access.
For example, the following SQL*Plus commands create a directory object and grant the user pm permission to read and write any file within the directory c:\mydir\work:
CONNECT sys as sysdba
Enter password: password
CREATE OR REPLACE DIRECTORY DICOMDIR AS 'c:\mydir\work';
GRANT READ,WRITE ON DIRECTORY DICOMDIR TO pm;
See Section 7.1 for more information about these directory and table definitions.
Examples
Export embedded DICOM content to a specified file:
declare
obj orddicom;
begin
select dicom_src into obj from medical_image_obj where id = 1;
obj.export('FILE', 'DICOMDIR', 'exported.dcm');
end;
/
Format
extractMetadata( extractOption IN VARCHAR2 DEFAULT 'ALL', docName IN VARCHAR2 DEFAULT 'ordcmmp.xml') RETURN SYS.XMLTYPE
Description
Returns the DICOM metadata as XML code for a specified mapping document. The default mapping document refers to the default metadata namespace http://xmlns.oracle.com/ord/dicom/metadata_1_0. The metadata attribute of the ORDDicom object is not affected.
Parameters
A string that specifies the types of metadata to extract from the DICOM content. Valid values are: ALL, MAPPED, and STANDARD. The default is ALL.
When the value of this parameter is ALL, all the attributes in the embedded DICOM content are extracted. When the value is set to MAPPED, only mapped attributes are extracted. And, when the value is set to STANDARD, only attributes that conform to the DICOM standard and mapped attributes are extracted.
The name of the mapping document. The default mapping document ordcmmp.xml is loaded during installation. This document refers to the default metadata namespace http://xmlns.oracle.com/ord/dicom/metadata_1_0.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this method to retrieve metadata from the embedded DICOM content as XML code, and then store it in a database table for searching or viewing.
Use the preference parameter XML_SKIP_ATTR to specify size limits for DICOM attributes to be omitted when encoding into XML. See Section 10.2.6.8 for more information about this preference parameter.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against a specific XML schema that is registered with Oracle XML DB. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Extract metadata from the embedded DICOM content:
declare
obj orddicom;
metadata xmltype;
begin
select dicom_src into obj from medical_image_obj where id = 1;
-- extract all the metadata using the default mapping document.
metadata := obj.extractMetadata();
-- extract the standard metadata using the default mapping document.
metadata := obj.extractMetadata('standard');
-- extract the standard metadata by specifying the mapping document.
metadata := obj.extractMetadata('standard', 'ordcmmp.xml');
end;
/
Format
getAttributeByName(attributeName IN VARCHAR2, definerName IN VARCHAR2 DEFAULT 'DICOM') RETURN VARCHAR2 DETERMINISTIC PARALLEL_ENABLE
Description
Returns the value of a DICOM attribute, as a VARCHAR2 string, for DICOM attributes other than SQ type attributes. For SQ type attributes, this method returns a segment of XML code, as a VARCHAR2 string. Use this method to get a single attribute from the embedded DICOM content.
Parameters
The name of a specified attribute.
The name of the attribute definer. The default name is DICOM.
Pragmas
None.
Exceptions
None.
Usage Notes
See Section 3.2.4 for more information about the best methods to use for searching and retrieving DICOM attributes.
Examples
Return the name of a specified DICOM attribute:
declare
obj orddicom;
res varchar2(4000);
begin
select dicom_src into obj from medical_image_obj where id = 1;
obj.setProperties;
-- Patient ID attribute, this will return patient ID value
res := obj.getAttributeByName('Patient ID');
dbms_output.put_line('Patient ID attribute: ' || res);
-- attribute in SQ type, this will return an xml segment.
res := obj.getAttributeByName('Source Image Sequence');
dbms_output.put_line('Source Image Sequence attribute: ' || res);
end ;
/
Format
getAttributeByTag(tag IN VARCHAR2, definerName IN VARCHAR2 DEFAULT 'DICOM') RETURN VARCHAR2 DETERMINISTIC PARALLEL_ENABLE
Description
Returns the value of a DICOM attribute, as a VARCHAR2 string, for DICOM attributes other than SQ type attributes. For SQ type attributes, this method returns a segment of XML code, as a VARCHAR2 string. Use this method to get a single attribute of the embedded DICOM content.
Parameters
The code value used to specify a DICOM attribute or item tag, as a hexadecimal string.
The name of the attribute definer. The default name is DICOM.
Pragmas
None.
Exceptions
None.
Usage Notes
See Section 3.2.4 for more information about the best methods to use for searching and retrieving DICOM attributes.
Examples
Return the tag of a specified DICOM attribute:
declare
obj orddicom;
res varchar2(4000);
begin
select dicom_src into obj from medical_image_obj where id = 1;
obj.setProperties;
-- Patient ID attribute, this will return patient ID value
res := obj.getAttributeByTag('00100020');
dbms_output.put_line('Patient ID attribute: ' || res);
-- attribute in SQ type, this will return an xml segment.
res := obj.getAttributeByTag('00082112');
dbms_output.put_line('Source Image Sequence attribute: ' || res);
end ;
/
Format
getContent( ) RETURN BLOB DETERMINISTIC
Description
Returns the embedded DICOM content stored in the source attribute of the ORDDicom object. This method returns the BLOB handle, or a null value if the DICOM content has not been imported.
Parameters
None.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Return the content of the source attribute for the ORDDicom object:
select t.dicom_src.getContent() from medical_image_obj t;
Format
getContentLength( ) RETURN INTEGER DETERMINISTIC PARALLEL_ENABLE
Description
Returns the length of the embedded DICOM content. This method returns the value of the contentLength attribute of the ORDDicom object.
Parameters
None.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Return the value of the contentLength attribute for the ORDDicom object:
select t.dicom_src.getContentLength() from medical_image_obj t;
Format
getSeriesInstanceUID( ) RETURN VARCHAR2 DETERMINISTIC PARALLEL_ENABLE,
Description
Returns the value of the SERIES_INSTANCE_UID attribute of the ORDDicom object.
Parameters
None.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Return the value of the SERIES_INSTANCE_UID attribute for the ORDDicom object:
select t.dicom_src.getSeriesInstanceUID() from medical_image_obj t;
Format
getSOPClassUID( ) RETURN VARCHAR2 DETERMINISTIC PARALLEL_ENABLE,
Description
Returns the value of the SOP_CLASS_UID attribute of the ORDDicom object.
Parameters
None.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Return the value of the SOP_CLASS_UID attribute for the ORDDicom object:
select t.dicom_src.getSOPClassUID() from medical_image_obj t;
Format
getSOPInstanceUID( ) RETURN VARCHAR2 DETERMINISTIC PARALLEL_ENABLE
Description
Returns the value of the SOP_INSTANCE_UID attribute of the ORDDicom object.
Parameters
None.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Return the value of the SOP_INSTANCE_UID attribute for the ORDDicom object:
select t.dicom_src.getSOPInstanceUID() from medical_image_obj t;
Format
getSourceInformation( ) RETURN VARCHAR2 DETERMINISTIC PARALLEL_ENABLE
Description
Returns the source information from the source attribute of the ORDDicom object as a URL in the form "source_type://source_location/source_name".
Parameters
None.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Return the source information for the ORDDicom object:
select t.dicom_src.getSourceInformation() from medical_image_obj t;
Format
getSourceLocation( ) RETURN VARCHAR2 DETERMINISTIC PARALLEL_ENABLE
Description
Returns the source location from the source attribute of the ORDDicom object.
Parameters
None.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Return the source location for the ORDDicom object:
select t.dicom_src.getSourceLocation() from medical_image_obj t;
Format
getSourceName( ) RETURN VARCHAR2 DETERMINISTIC PARALLEL_ENABLE
Description
Returns the source name from the source attribute of the ORDDicom object.
Parameters
None.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Return the source name for the ORDDicom object:
select t.dicom_src.getSourceName() from medical_image_obj t;
Format
getSourceType( ) RETURN VARCHAR2 DETERMINISTIC PARALLEL_ENABLE
Description
Returns the source type from the source attribute of the ORDDicom object.
Parameters
None.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Return the source type for the ORDDicom object:
select t.dicom_src.getSourceType() from medical_image_obj t;
Format
getStudyInstanceUID( ) RETURN VARCHAR2 DETERMINISTIC PARALLEL_ENABLE,
Description
Returns the value of the STUDY_INSTANCE_UID attribute of the ORDDicom object.
Parameters
None.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Return the value of the STUDY_INSTANCE_UID attribute for the ORDDicom object:
select t.dicom_src.getStudyInstanceUID() from medical_image_obj t;
Format
import(SELF IN OUT NOCOPY ORDDicom, setproperties IN INTEGER DEFAULT 1)
Description
Imports DICOM content from the current source. This method assumes that the source attributes have been set in the ORDDicom object by passing the source_type, source_location, and source_name parameters to the constructor.
Parameters
Indicator flag that determines whether the DICOM attributes are extracted into the metadata attribute of the ORDDicom object. If the value is 1, the DICOM attributes are extracted into the metadata attribute of the ORDDicom object, and the attributes of the ORDDicom object are populated. If the value is 0, no DICOM attributes are extracted. The default is 1.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this method when the ORDDicom object is constructed from a source other than a BLOB, and must be imported into a BLOB.
The import( ) method reads only from a database directory object that the user has privilege to access. That is, you can access a directory object that you have created using the SQL statement CREATE DIRECTORY, or one to which you have been granted READ access.
For example, the following SQL*Plus commands create a directory object and grant the user pm permission to read any file within the directory c:\mydir\work:
CONNECT sys as sysdba
Enter password: password
CREATE OR REPLACE DIRECTORY DICOMDIR AS 'c:\mydir\work';
GRANT READ ON DIRECTORY DICOMDIR TO pm;
Assuming that the DICOM object is inserted as follows:
insert into medical_image_obj (id, dicom_src) values
(1, ORDDicom('FILE', 'DICOMDIR', 'imported.dcm');
The user pm can import DICOM content from the imported.dcm file in this directory using the import( ) method of the ORDDicom object:
obj.import();
See Section 7.1 for more information about these directory and table definitions.
Examples
Import the DICOM attributes:
declare
obj orddicom;
begin
select dicom_src into obj from medical_image_obj where id = 1 for update;
if (obj.isLocal() = 0) then
obj.import();
end if;
update medical_image_obj set dicom_src = obj where id = 1;
end;
/
Format
isAnonymous(anonymityDocName IN VARCHAR2 DEFAULT 'ordcman.xml') RETURN INTEGER
Description
Determines whether the embedded DICOM content is anonymous using a specified anonymity document, which is stored in the data model repository. This method returns a value of 1 if the data is anonymous; otherwise it returns a value of 0.
Parameters
The name of the anonymity document. The default name is ordcman.xml.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this method before calling the makeAnonymous( ) method to find out whether patient identifying information has been removed from the embedded DICOM content (see also the makeAnonymous( ) method).
Examples
Check if the embedded DICOM content is anonymous:
select t.dicom_src.isAnonymous('ordcman.xml') from medical_image_obj t;
Format
isConformanceValid( constraintName IN VARCHAR2 ) RETURN INTEGER
Description
Performs a conformance validation check to determine whether the embedded DICOM content conforms to a specific set of constraints identified by the constraintName parameter. This method returns a value of 1 if conformance is valid; otherwise it returns a value of 0.
This method also logs error messages from the constraint documents, which can be viewed by querying the public view orddcm_conformance_vld_msgs. The public view orddcm_constraint_names contains the list of constraint names.
Parameters
The name of the constraint to be used for conformance validation checking.
Pragmas
None.
Exceptions
None.
Usage Notes
If this method is called from a SQL query, ensure that the constraint rule definition does not contain any <ACTION> elements.
Use the preference parameter EXP_IF_NULL_ATTR_IN_CONSTRAINT to indicate whether to throw exceptions when encountering missing attributes or null attribute values during conformance validation. See Section 10.2.6.2 for more information about this preference parameter.
Examples
Check if the ORDDicom objects are conformance valid. Then, show any conformance validation messages that are generated.
declare
cursor dicom_src_cur is
select dicom_src from medical_image_obj order by id;
begin
for rec in dicom_src_cur loop
dbms_output.put_line('isConformanceValid(PatientModule): ' ||
rec.dicom_src.isConformanceValid('PatientModule'));
end loop;
end;
/
select t1.id, t2.message, t2.msg_time time
from medical_image_obj t1, orddcm_conformance_vld_msgs t2
where t1.dicom_src.sop_instance_uid = t2.sop_instance_uid and
t2.rule_name = 'PatientModule';
Format
isLocal( ) RETURN INTEGER DETERMINISTIC PARALLEL_ENABLE
Description
Returns the local status of the source. If the DICOM content is stored in the source BLOB, the object is defined as local. If the DICOM content is stored externally in an operating system-specific file, the object is defined as not local. This method returns a value of 1 if the object is local; otherwise it returns a value of 0.
Parameters
None.
Pragmas
None.
Exceptions
None.
Usage Notes
None.
Examples
Check if the DICOM content is local:
select t.dicom_src.isLocal() from medical_image_obj t;
declare
obj orddicom;
begin
select dicom_src into obj from medical_image_obj where id = 1 for update;
if (obj.isLocal() = 0) then
obj.import();
end if;
update medical_image_obj set dicom_src = obj where id = 1;
end;
/
Format
makeAnonymous(SELF IN ORDDicom, dest_SOP_INSTANCE_UID IN VARCHAR2, dest IN OUT NOCOPY ORDDicom, anonymityDocName IN VARCHAR2 DEFAULT 'ordcman.xml')
Description
Removes patient identifying information from the ORDDicom object after copying it into another ORDDicom object, based on a specified anonymity document. Both the embedded DICOM content and the metadata attribute in the destination ORDDicom object are made anonymous.
Parameters
The SOP instance UID of the destination ORDDicom object. It must ensure that the destination DICOM content is globally unique.
An empty ORDDicom object in which to store the anonymous ORDDicom object.
The name of the anonymity document. The default name is ordcman.xml.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this method to remove patient identifying information from the embedded DICOM content for use in data sharing and research.
Examples
Remove patient identifying information from the destination ORDDicom object:
|
Note: Replace <unique-UID> with the UID that identifies the organization producing the DICOM content and the DICOM content within that organization. |
declare
obj_src orddicom;
obj_dest orddicom;
dest_sop_instance_uid varchar2(128) := '<unique-UID>';
begin
select dicom_src, dicom_dest into obj_src, obj_dest
from medical_image_obj where id = 1 for update;
obj_src.makeAnonymous(dest_sop_instance_uid, obj_dest, 'ordcman.xml');
update medical_image_obj set dicom_dest = obj_dest where id = 1;
end;
/
Format
processCopy(SELF IN ORDDicom, command IN VARCHAR2, dest IN OUT NOCOPY BLOB)
Description
Copies the ORDDicom object that is input into the destination BLOB, and then performs the specified processing operations on the destination BLOB. The original ORDDicom object that was input remains unchanged.
Parameters
A command string that accepts a processing operator as input. Valid values include: frame, contentFormat, fileFormat, compressionFormat, cut, scale, and rotate. See Appendix D for information about processing operators.
The destination BLOB that contains the output of the process command on the ORDDicom object.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this method to process an ORDDicom object into a BLOB after copying it from the ORDDicom object. In this case, the output in the BLOB is image or video content.
See Appendix C for information about the encoding rules that support DICOM content processing. See Appendix D for more information about DICOM processing.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Copy the DICOM content into a BLOB and then process it:
declare
obj orddicom;
dest blob;
begin
select dicom_src, blob_dest into obj, dest
from medical_image_obj where id = 1 for update;
obj.processCopy('fileFormat=jpeg maxScale=100 100', dest);
end;
/
Format
processCopy(SELF IN ORDDicom, command IN VARCHAR2, dest_SOP_INSTANCE_UID IN VARCHAR2, dest IN OUT NOCOPY ORDDicom, metadata IN SYS.XMLTYPE DEFAULT NULL)
Description
Copies the ORDDicom object that is input into a destination ORDDicom object, then performs the specified processing operations on the destination ORDDicom object and updates it with the new metadata. The original ORDDicom object that was input remains unchanged.
Parameters
A command string that accepts a processing operator as input. Valid values include: compressionFormat, frame, contentFormat, cut, scale, and rotate. See Appendix D for information about processing operators.
The SOP instance UID of the destination ORDDicom object. It must ensure that the destination DICOM content is globally unique.
An empty ORDDicom object in which to store the new DICOM content with the new metadata.
The new metadata to be written into the new DICOM content.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this method to process DICOM content into a destination ORDDicom object after copying it from the source ORDDicom object. In this case, the output is image or video content.
See Appendix C for information about the encoding rules that support DICOM content processing. See Appendix D for more information about DICOM processing.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Copy the DICOM content into an ORDDicom object and then process it:
|
Note: Replace <unique-UID> with the UID that identifies the organization producing the DICOM content and the DICOM content within that organization. |
declare
obj_src orddicom;
obj_dest orddicom;
dest_sop_instance_uid varchar2(128) := '<unique-UID>';
begin
select dicom_src, dicom_dest into obj_src, obj_dest
from medical_image_obj where id = 1 for update;
obj_src.processcopy('compressionFormat=jpeg',
dest_sop_instance_uid,
obj_dest);
update medical_image_obj set dicom_dest = obj_dest where id = 1;
end;
/
Format
processCopy(SELF IN ORDDicom, command IN VARCHAR2, dest IN OUT NOCOPY ORDImage)
Description
Copies the ORDDicom object that is input into the destination ORDImage object, and then performs the specified processing operations on the destination ORDImage object. The original ORDDicom object that was input remains unchanged.
Parameters
A command string that accepts an image processing operator as input. Valid values include: frame, contentFormat, fileFormat, compressionFormat, cut, scale, and rotate. See Appendix D for information about image processing operators.
An empty ORDImage object in which to store the new, processed ORDImage object without the DICOM metadata.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this method to get a non-DICOM image that is suitable for presentation on the Web from the embedded DICOM content.
See Appendix C for information about the encoding rules that support image content processing. See Appendix D for more information about DICOM processing.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Copy the DICOM content into an ORDImage object and then process it:
declare
obj_src orddicom;
obj_dest ordimage;
begin
select dicom_src, image_dest into obj_src, obj_dest
from medical_image_obj where id = 1 for update;
obj_src.processcopy('fileFormat=jpeg maxScale=100 100', obj_dest);
update medical_image_obj set image_dest = obj_dest where id = 1;
end;
/
Format
setProperties(SELF IN OUT NOCOPY ORDDicom)
Description
Sets the attributes of the ORDDicom object. The attributes of the ORDDicom object are populated and the embedded DICOM content attributes are extracted into the metadata attribute of the ORDDicom object. The XML metadata conforms to the default metadata schema namespace http://xmlns.oracle.com/ord/dicom/metadata_1_0.
If the repository contains a stored tag list document, the XML metadata contains only the DICOM attributes specified by the stored tag list. Otherwise, the XML metadata contains all the attributes from the embedded DICOM content.
Parameters
None.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this method to populate ORDDicom object attributes and to get the metadata from the embedded DICOM content.
Use the preference parameter XML_SKIP_ATTR to specify size limits for DICOM attributes to be omitted when encoding into XML. See Section 10.2.6.8 for more information about this preference parameter.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against a specific XML schema that is registered with Oracle XML DB. See Section 10.2.6.7 for more information about this preference parameter.
Examples
Set the attributes of the ORDDicom object:
declare obj orddicom; begin select dicom_src into obj from medical_image_obj where id = 1 for update; obj.setProperties(); update medical_image_obj set dicom_src = obj where id = 1; end; /
Format
writeMetadata(SELF IN ORDDicom, metadata IN SYS.XMLTYPE, dest IN OUT NOCOPY ORDDicom)
Description
Modifies the current ORDDicom object with the metadata provided by making a copy of the existing ORDDicom object in the destination ORDDicom object, and then modifying the metadata. The original ORDDicom object remains unchanged. The attributes in the embedded DICOM content of the destination ORDDicom object are copied from the metadata that was input.
Parameters
The input metadata stored in data type XMLType. In the destination ORDDicom object, the input metadata is used to update the values for attributes that are identical to attributes in the source ORDDicom object, or to add any new attributes. The metadata must conform to the default metadata schema with the namespace http://xmlns.oracle.com/ord/dicom/metadata_1_0. The SOP instance UID in the metadata must ensure that the destination DICOM content is globally unique.
An empty ORDDicom object in which to store the new embedded DICOM content with the new metadata.
Pragmas
None.
Exceptions
None.
Usage Notes
Use this method to update attributes in the embedded DICOM content.
In addition, you can use this method to add private attributes to the embedded DICOM content.
See Appendix C for information about the encoding rules that support metadata extraction.
Use the preference parameter VALIDATE_METADATA to specify whether the XML documents are validated against the Oracle default DICOM metadata schema. See Section 10.2.6.7 for more information about this preference parameter.
Use the preference parameter SQ_WRITE_LEN to specify how the DICOM sequence (SQ) types are encoded. See Section 10.2.6.6 for more information about this preference parameter.
Examples
Write the new metadata to the copy of the embedded DICOM content:
declare
obj_src orddicom;
obj_dest orddicom;
metadata xmltype;
begin
metadata := xmltype(bfilename('DICOMDIR', 'wm_meta.xml'),
nls_charset_id('AL32UTF8'),
'http://xmlns.oracle.com/ord/dicom/metadata_1_0');
select dicom_src, dicom_dest into obj_src, obj_dest
from medical_image_obj where id = 1 for update;
obj_src.writeMetadata(metadata, obj_dest);
update medical_image_obj set dicom_dest = obj_dest where id = 1;
end;
/
This part contains supplementary information related to the Oracle Multimedia DICOM feature.
Part IV includes these appendixes:
This chapter describes Oracle Multimedia DICOM at a conceptual level.
This chapter includes these sections:
Oracle Multimedia DICOM enables Oracle Database to store, manage, and retrieve DICOM content such as single-frame and multiframe images, waveforms, slices of 3-D volumes, video segments, and structured reports.
The Oracle Multimedia DICOM architecture defines the framework (see Figure 2-1) through which DICOM content is supported in the database. This DICOM content can then be securely shared across multiple applications written with popular languages and tools, easily managed and administered by relational database management and administration technologies, and offered on a scalable database that supports thousands of users.
Figure 2-1 shows the Oracle Multimedia DICOM architecture from a two-tier perspective:
Database tier (Oracle Database)
Client tier (Thick Clients)
In the database tier, using Oracle Multimedia DICOM, Oracle Database holds DICOM content in tables. As illustrated, DICOM content stored in a column of a table can include DICOM data such as X-rays, ultrasound images, and magnetic resonance images. In the table, a separate column stores a JPEG thumbnail image of the DICOM image. Another column stores the XML metadata documents associated with each image. Within a Java Virtual Machine (JVM), there is a server-side DICOM data model repository and a DICOM parser, a DICOM XML encoder, a DICOM conformance validator, and an image processor. The DICOM parser extracts metadata from DICOM content. The DICOM XML encoder maps the extracted DICOM attributes into an XML document, in accordance with the mapping rules defined in the data model repository. The DICOM conformance validator checks the syntactical and semantic consistency of DICOM content in accordance with the constraint rules specified in the data model repository. The image processor includes Java Advanced Imaging (JAI), and provides image processing for operations such as producing thumbnail-size images and converting between DICOM and other supported image formats. Using Oracle Multimedia DICOM methods enables import and export operations between the database and external file storage systems. The double-sided arrow connecting Oracle Database with External File Storage in Figure 2-1 shows this type of data communication.Through JDBC calls, thick clients can access the content stored in an Oracle database and perform procedures such as image processing outside of the database. Other means of interacting with Oracle Database, such as the OCI call interface, can also be used to access DICOM content stored in an Oracle database. These types of data access can also be used to integrate Oracle Database with third-party media processors.
In the client tier, the ability to access ORDDicom objects in the database is supported through Oracle Multimedia DICOM Java API. Oracle Multimedia DICOM Java API supplies direct access to ORDDicom objects from Java applications.
Figure 2-1 Oracle Multimedia DICOM Architecture
|
See Also:
|
When using the object interface, you must create an ORDDicom object in a table before you can perform Oracle Multimedia DICOM operations on DICOM content. Oracle Multimedia defines the ORDDicom object type, which is similar to a Java or C++ class, to contain DICOM content.
Figure 2-2 shows an ORDDicom object at a very high level. Items in Figure 2-2 are numbered to help identify the items in this description. An instance of an ORDDicom object type (Item 1) consists of methods and attributes. Methods are functions or procedures that can be performed on the ORDDicom object, such as makeAnonymous( ) and setProperties( ). The attributes include the following:
Extracted DICOM attributes represented as an XML metadata document (Item 2)
The DICOM content (Item 3), which is the original DICOM content in unmodified form stored within the database, under transaction control as a BLOB (recommended), or stored in an operating system-specific file in a local file system with pointers stored in the database
Certain frequently accessed general attributes (Item 4), such as SOP Class UID, which are extracted and stored for ease of access and indexing
Miscellaneous attributes (Item 5) that are meant for Oracle internal use
Similar to the NUMBER or BLOB data types, you can use the ORDDicom data type as the data type of a table column.
Figure 2-3 shows the structure of a simple table in a medical database that contains an ORDDicom object. Items in Figure 2-3 are numbered to help identify the items in this description. Item 1 represents the medical image database. Item 2 represents a simple medical image table managed by the database. This table contains two columns: ID (Item 3) and Image (Item 4). Item 3 represents the identifier for a specified DICOM image in the database. Item 4 represents the DICOM content in the database, which can be stored as an ORDDicom object (Item 5). Thus, the column type for the Image column is ORDDicom.
Figure 2-3 Table in a Medical Image Database
Oracle Multimedia DICOM is designed with a model-driven software architecture. Thus, the run-time behavior of Oracle Multimedia DICOM is controlled by a domain-specific data model. The DICOM data model is a collection of XML documents that are managed in the data model repository. DICOM administrators can manage and modify the DICOM data model. The XML documents that comprise the data model can be inserted and deleted at run time when multiple user sessions are accessing the data model. Changes to the data model are protected with database transaction semantics, and each user session can refresh to the latest data model when necessary or desired.
Figure 2-4 illustrates the principles of model-driven software architecture using the DICOM metadata extraction feature. The items above the dotted line show the portions of the data model that are related to the metadata extraction feature. The items below the dotted line show the software run-time components of the extract metadata feature that access the data model. A line that connects an item of the data model and an item of the run-time component shows the run-time access to the corresponding item that is managed by the data model repository.
At design time, DICOM administrators can change the DICOM data model. Publishing these changes affects the run-time behavior of the extract metadata feature, and other DICOM operations.
Figure 2-4 shows three components of the data model. Items in Figure 2-4 are numbered to help identify the items in this description. Item 1 represents the DICOM data dictionary, which provides the definitions for DICOM standard and private attributes. Item 2 represents a mapping document, which describes how an attribute is to be mapped into an XML document. Item 3 represents a sample DICOM XML metadata schema, which defines the structure and data type of an XML document that is used to store DICOM attributes. The lines connecting elements of Item 2 and Item 3 show the mapping between a DICOM attribute stored in DICOM content and an XML element stored in an XML document that conforms to the XML schema.
The process of converting DICOM content (Item 4) into an XML metadata document (Item 8) is shown in the bottom half of Figure 2-4. Solid lines connecting items show the flow of data between run-time components. Two of the attributes of the sample DICOM content are shown in Item 5. The first attribute contains the attribute tag (0010,0010), the data type PN, the length in bytes 12, and the value Joe Smith. This attribute is encoded in the DICOM content, although its data type might not be encoded in the DICOM content. The parser (Item 6) can find an attribute definition by looking it up in the DICOM data dictionary (Item 1) using the attribute tag (0010,0010). The attribute definition determines the interpretation of the DICOM content. The result is passed to an XML encoder (Item 7). Similarly, the XML encoder looks up the data model (Item 2) to find the XML encoding guidelines for the attribute, and produces an XML document accordingly. Finally, an XML schema validator (Item 9) can validate the generated document against the XML metadata schema (Item 3).
In Figure 2-4, everything that controls the run-time behavior is part of the data model, which can be configured by a DICOM administrator.
Figure 2-4 DICOM Model-Based Parsing Details
A key feature of Oracle Multimedia DICOM is that its run-time behavior is determined by a set of user-configurable documents (a data model). This set of documents is managed collectively in the data model repository. Administrators can update the data model repository to configure Oracle Multimedia DICOM for a particular database instance. With this design, customers can perform tasks such as upgrading Oracle Multimedia DICOM to a new version of the DICOM standard or adding new conformance validation rules at any time, without interfering with a running DICOM archive. Each database has its own set of configuration documents. Each organization or enterprise can customize the installed configuration documents according to its needs.
The following subsections describe these DICOM data model repository concepts:
The set of configuration documents that comprises the data model repository includes anonymity documents, constraint documents, mapping documents, preference documents, private and standard dictionary documents, stored tag list documents, and UID definition documents. Each configuration document comes with an XML schema definition. Other documents can be added to the repository as needed.
Oracle ships a set of default configuration documents with each software release. All schemas corresponding to the default documents are registered during installation. All schemas are fixed and must not be modified for a database installation.
Table 2-1 lists the document type, the default XML document name, and the XML schema definition name for each type of document in the data model repository.
Table 2-1 Configuration Documents and Their XML Schemas
| Document Type | Default XML Document | XML Schema Definition |
|---|---|---|
|
Anonymity |
|
|
|
Constraint |
|
|
|
Mapping |
|
|
|
Preference |
|
|
|
Private Dictionary |
|
|
|
Standard Dictionary |
|
|
|
Stored Tag List |
None |
|
|
UID Definition |
|
|
An anonymity document is an XML document that specifies the set of attributes to be made anonymous, and defines the actions required to make those attributes anonymous. 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.
A constraint document is an XML document that defines a collection of rules that check the conformance of DICOM content, according to the DICOM standard. The constraint document specifies attribute relationships and semantic constraints that cannot be expressed by the DICOM metadata schema. The default constraint documents, ordcmct.xml, ordcmcmd.xml, and ordcmcmc.xml, show a sample set of validation rules defined in accordance with a subset of Part 3 of the DICOM standard.
A mapping document is an XML document that defines how each attribute maps to a particular element in a DICOM XML metadata document. This document determines the structure of the extracted XML representation of the DICOM metadata. The default mapping document, ordcmmp.xml, defines the mapping from DICOM content to XML, which is represented as a flat list where all XML encoded DICOM attributes are included under the root element <DICOM_OBJECT>.
A preference document is an XML document that defines run-time parameters, such as the size limits for DICOM attributes to omit when encoding to XML or whether to validate XML documents used in DICOM functions and procedures. The default preference document is ordcmpf.xml.
A private dictionary document is an XML document that enables users to extend the standard dictionary document definitions by adding manufacturer-specific or enterprise-specific attributes to DICOM content. The default private dictionary document, ordcmpv.xml, defines Oracle private attributes.
A standard dictionary document is an XML document that lists the standard attributes defined in Part 6 of the DICOM standard, and that can be used to reflect updates to the DICOM standard. The default standard dictionary document is ordcmsd.xml.
A stored tag list document is an optional XML document that specifies the DICOM attributes to be extracted from the embedded DICOM content and stored in the XML metadata attribute of the ORDDicom object when the setProperties( ) method is called. Generally, stored tag list documents contain the attribute tags used in mapping and constraint documents.
A UID definition document is an XML document that lists unique identifiers (UIDs) defined by the DICOM standard or a private organization. The UID is based on an ISO object identifier (OID). Rather than defining the DICOM content UIDs, the UID definition document contains a registry of standard UIDs that classify the DICOM content and express standard semantics. The default UID definition document, ordcmui.xml, lists UIDs defined by Part 6 of the DICOM standard.
See Appendix A and Appendix B, respectively, for more information about the installed configuration documents and their related XML schema definitions.
Administrators can manage configuration documents using the data model repository interface.
The data model repository must be loaded before any Oracle Multimedia DICOM methods, procedures, or functions are invoked. Loading the repository is accomplished through a DICOM package interface, using the setDataModel( ) procedure.
Figure 2-5 uses a Unified Modeling Language (UML) sequence diagram to show the state of the DICOM data model repository in its installed state and in various states after being updated. Also shown are two administrator sessions and two user sessions working with one data model repository. The numbered items in Figure 2-5 represent various components of, or operations on, the data model repository. The numbered items in the following list correspond to the numbered items in Figure 2-5, respectively.
Data Model States:
In Item 10, all the boxes in this column represent the data model repository in the following states:
State 0: the installed version.
State 1: the version that includes updates from the Admin Session 1 editing session XG1.
State 2: the version that includes updates from the Admin Session 1 editing session XG1 and the Admin Session 2 editing session XG2.
State 3: the version that includes updates from the Admin Session 1 editing sessions XG1 and XG3 and updates from the Admin Session 2 editing session XG2.
Administrator Sessions:
Item 1: All boxes in this column represent tasks performed by Admin Session 1.
Item 6: All boxes in this column represent tasks performed by Admin Session 2.
Item 2: Admin Session 1 calls the editDataModel( ) procedure to begin editing session XG1. This locks the installed version of the data model (State 0) and prevents other administrators from editing the data model. During this time, users can view only the installed version of the data model (State 0). Admin Session 1 edits the data model.
Item 3: Admin Session 1 completes editing session XG1 and calls the publishDataModel( ) procedure to publish the changes to the data model. The data model is updated to State 1 and the lock is released. Other administrators can now lock the data model for editing. And, other users can now view the updated data model by calling the setDataModel( ) procedure.
Item 7: Admin Session 2 calls the editDataModel( ) procedure to begin editing session XG2. This locks the data model (State 1) and prevents other administrators from editing the data model. During this time, users can view State 1 of the data model. Admin Session 2 edits the data model.
Item 8: Admin Session 2 completes editing session XG2 and calls the publishDataModel( ) procedure to publish the changes to the data model. The data model is updated to State 2 and the lock is released.
Item 4: Admin Session 1 calls the editDataModel( ) procedure to begin editing session XG3. This locks the data model (State 2) and prevents other administrators from editing the data model. During this time, users can view State 2 of the data model. Admin Session 1 edits the data model.
Item 9: Admin Session 2 calls the editDataModel( ) procedure to begin editing session XG4. Because Admin Session 1 has locked the data model, Admin Session 2 cannot obtain the lock, and the call to the editDataModel( ) procedure fails.
Item 5: Admin Session 1 completes editing session XG3 and calls the publishDataModel( ) procedure to publish the changes to the data model. The data model is updated to State 3 and the lock is released.
User Sessions:
Item 11: All boxes in this column represent tasks performed by User Session 1.
Item 15: All boxes in this column represent tasks performed by User Session 2.
Item 12: User Session 1 calls the setDataModel( ) procedure to load the data model. The data model is still at the installed version (State 0) because Admin Session 1 has not yet published the changes for editing session XG1.
Item 16: User Session 2 calls the setDataModel( ) procedure to load the data model. The data model is at State 1, which reflects the published changes from editing session XG1.
Item 13: User Session 1 calls the setDataModel( ) procedure again. The data model is now at State 1, which reflects the published changes from editing session XG1.
Item 17: User Session 2 calls the setDataModel( ) procedure again. The data model is still at State 1 because Admin Session 2 has not yet published the changes for editing session XG2.
Item 14: User Session 1 calls the setDataModel( ) procedure again. The data model is now at State 2, which reflects the published changes from editing sessions XG1 and XG2.
Item 18: User Session 2 calls the setDataModel( ) procedure again. The data model is now at State 3, which reflects the published changes from editing sessions XG1, XG2, and XG3.
As shown in Figure 2-5, the setDataModel( ) procedure is invoked during user sessions. Applications must call this procedure at the beginning of each database session to load the repository from the database into memory structures. This procedure can also be called whenever the application requires the new data model changes. This procedure is available to users through the DICOM data model utility in the ORD_DICOM package interface.
See Chapter 12 for more information about the data model repository administration interface. See Chapter 4 for more information about the DICOM data model utility in the ORD_DICOM package interface.
Extracting metadata from DICOM content involves several operations using an XML metadata schema and a mapping document.
A DICOM metadata document is an XML document that contains the metadata extracted from DICOM content. Optionally, each metadata document can be constrained by an XML schema. Each XML metadata schema has a matching XML mapping document.
The mapping of DICOM content to the DICOM metadata document is defined by a mapping document. The mapping document defines how attributes from the DICOM content are to be mapped into an XML document that conforms to the schema. Like other configuration documents, mapping documents are managed by the DICOM data model repository (see Section 2.4).
Oracle provides a default XML metadata schema (ordcmmd.xsd) and a matching XML mapping document (ordcmmp.xml). Application designers who create their own metadata schemas must ensure that their schema definition and mapping documents are compatible. They must also ensure that their data type definitions are compatible with the Oracle data type definitions (ordcmmddt.xsd).
The following subsections describe these key extraction and mapping concepts:
Figure 2-6 shows the components involved in the metadata extraction and XML mapping process. Each numbered item in Figure 2-6 represents a component in this process.
Figure 2-6 DICOM Metadata Extraction and XML Mapping
The input is DICOM content (Item 1) in binary format, which can be stored in an ORDDicom object, or directly in a BLOB or a BFILE. The output is an XML metadata document (Items 7 and 8). The layout of the metadata document is specified by the mapping document (Item 3). Metadata extraction uses a mapping option parameter that specifies which group of attributes to include in the output metadata document. The solid lines connecting items (Items 4, 5, and 6) show the flow of data from the DICOM content to the XML metadata document. Item 3 can also be interpreted as a processing engine that performs metadata extraction according to the specifications of the mapping document.
The DICOM content (Item 1) encodes a DICOM data element (Item 2) in binary code. At run time, the parser reads the binary stream of DICOM content, and builds a representation of the DICOM data element (Item 2) in memory. To map the in-memory representation of each DICOM attribute into an XML element, the XML encoder looks up the definition of the attribute in the mapping document (Item 3) that is stored in the data model repository.
For example, the first entry of this mapping document maps the DICOM attribute Patient's Name (0010,0010) to the XML path /DICOM/Patient/Name, where Name is a subelement of the Patient element, and Patient is the child element of the document root element DICOM.
Attributes that are part of a DICOM data element and whose XML paths are explicitly defined in a mapping document are called mapped attributes. Attributes that are part of a DICOM data element but whose XML paths are not explicitly defined in a mapping document are called unmapped attributes.
Based on the mapping document, each DICOM metadata document can contain two sections: a mapped section and an optional, unmapped section. In the mapped section (Item 7), attributes are organized according to a predefined hierarchy. Attributes in the mapped section can be addressed with a fixed XPath query. In the unmapped section (Item 8), attributes are sorted by attribute tag and listed by value representation. Attributes in the unmapped section can be addressed by an XPath query of the element tag in the following form:
/DICOM/Other/VR_TYPE(tag=='HHHHHHHH')
In this query, HHHHHHHH is the hexadecimal attribute tag, and /DICOM/Other is the specified path for the unmapped section. See Section 10.2.3 for information about how to create a your own mapping document.
The mapping option of the extract metadata function specifies which group of attributes to include in the output XML metadata document. The three mapping options are mapped, standard, or all.
If the extract option is mapped (Item 4), then only mapped attributes are included in the XML metadata document. This option is useful when the application using the metadata document has a fixed set of required attributes. The resulting metadata document (Item 7) has a well-defined tree structure.
If the extract option is standard (Item 5), then all mapped attributes and all unmapped attributes that are defined by the DICOM standard are extracted into the XML metadata document. Private attributes whose mappings are not defined are excluded from the output. This option is useful when an application such as a full-text search can use all standard attributes that are included in the DICOM content.
If the extract option is all (Item 6), then all attributes that are included in the DICOM content are extracted and encoded into the XML metadata document. This option provides lossless mapping of DICOM attributes from binary to XML.
|
Note: Attributes whose binary length exceeds the user-specified limit are not included in the XML metadata document. See Section 10.2.6 for more information about specifying these limits within a preference document. |
If the mapping option is all or standard, then unmapped attributes of the DICOM data element are stored under the XML element Other (Item 8). The resulting XML document can be stored in a database table, indexed, and queried using keywords or XPath query statements. To define alternative mapping structures and element names for mapped and unmapped sections, see Section 10.2.3.
Using an XML mapping document to extract mapped metadata, you can generate an XML metadata document. Example 2-1 shows a sample XML mapping document (sample_map.xml).
Example 2-1 Sample XML Mapping Document
<?xml version="1.0" encoding="UTF-8"?>
<XML_MAPPING_DOCUMENT xmlns="http://xmlns.oracle.com/ord/dicom/mapping_1_0"
xmlns:dt="http://xmlns.oracle.com/ord/dicom/datatype_1_0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/ord/dicom/mapping_1_0
http://xmlns.oracle.com/ord/dicom/mapping_1_0">
<DOCUMENT_HEADER>
<dt:DOCUMENT_CHANGE_LOG>
<dt:DOCUMENT_MODIFIER>Dongbai Guo</dt:DOCUMENT_MODIFIER>
<dt:DOCUMENT_MODIFICATION_DATE>2006-01-13</dt:DOCUMENT_MODIFICATION_DATE>
<dt:DOCUMENT_VERSION>0.0</dt:DOCUMENT_VERSION>
<dt:MODIFICATION_COMMENT>Sample mapping document for metadata schema definition
1</dt:MODIFICATION_COMMENT>
</dt:DOCUMENT_CHANGE_LOG>
</DOCUMENT_HEADER>
<NAMESPACE>http://xmlns.oracle.com/ord/dicom/metatest1</NAMESPACE>
<ROOT_ELEM_TAG>DICOM_OBJECT</ROOT_ELEM_TAG>
<UNMAPPED_ELEM>OTHER_ATTRIBUTES</UNMAPPED_ELEM>
<MAPPED_ELEM>KEY_ATTRIBUTES</MAPPED_ELEM>
<MAPPED_PATH occurs="true" notEmpty="true" writeTag="true" writeDefiner="true"
writeName="true" writeRawValue="true">
<ATTRIBUTE_TAG>00020002</ATTRIBUTE_TAG>
<PATH>MEDIA_STORAGE_SOP_CLASS_UID</PATH>
</MAPPED_PATH>
<MAPPED_PATH occurs="true" notEmpty="true">
<ATTRIBUTE_TAG>00020003</ATTRIBUTE_TAG>
<PATH>MEDIA_STORAGE_SOP_INSTANCE_UID</PATH>
</MAPPED_PATH>
<MAPPED_PATH writeTag="true" writeDefiner="true" writeName="true" writeRawValue="true">
<ATTRIBUTE_TAG>00100010</ATTRIBUTE_TAG>
<PATH>PATIENT_NAME</PATH>
</MAPPED_PATH>
</XML_MAPPING_DOCUMENT>
In Example 2-1, the DICOM standard attribute SOP_CLASS_UID that has the DICOM attribute tag (0002,0002) maps to the XML metadata element MEDIA_STORAGE_SOP_CLASS_UID at the XML tree location /DICOM_OBJECT/KEY_ATTRIBUTES/. Similarly, the DICOM standard attribute SOP_INSTANCE_UID (0002,0003) maps to the XML metadata element MEDIA_STORAGE_SOP_INSTANCE_UID. The DICOM standard attribute study date (0008,0020) has not been listed by the XML mapping document. Thus, if it exists in the DICOM content, it appears in the unmapped section of the DICOM metadata document under the XML tree location (/DICOM_OBJECT/OTHER_ATTRIBUTES).
Example 2-2 shows a sample XML metadata document that can be generated by extracting mapped metadata using the XML mapping document shown in Example 2-1.
Example 2-2 Sample XML Metadata Document
<?xml version="1.0" encoding="DEC-MCS"?>
<DICOM_OBJECT xmlns="http://xmlns.oracle.com/ord/dicom/metatest1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/ord/dicom/metatest1
http://xmlns.oracle.com/ord/dicom/metatest1">
<KEY_ATTRIBUTES>
<MEDIA_STORAGE_SOP_CLASS_UID definer="DICOM" tag="00020002"
name="Media Storage SOP Class UID">1.2.840.10008.5.1.4.1.1.1</MEDIA_STORAGE_SOP_CLASS_UID>
<MEDIA_STORAGE_SOP_INSTANCE_UID tag="00020003" definer="DICOM"
name="media storage SOP instance UID">1.3.6.1.4.1.5962.1.1.10.1.2.20040119072730.12322
</MEDIA_STORAGE_SOP_INSTANCE_UID>
<PATIENT_NAME definer="DICOM" tag="00100010" name="Patient's Name">
<NAME type="unibyte">
<FAMILY>CompressedSamples</FAMILY>
<GIVEN>RG2</GIVEN>
</NAME>
<VALUE>CompressedSamples^RG2</VALUE>
</PATIENT_NAME>
</KEY_ATTRIBUTES>
</DICOM_OBJECT>
Validating DICOM content involves verifying that the data conforms to a specified set of constraint rules.
There are several advantages of implementing conformance validation in the database instead of in the middle tier or the application tier. First, validating DICOM content can ensure the integrity and consistency of archived DICOM content by enabling a database to accept DICOM content from all sources and to check the integrity of that content. With this feature, the database can act as the centralized data store, connecting a variety of DICOM content sources while enforcing enterprise data constraint rules. Large organizations or government branches can establish their own sets of constraint rules that are more or less restrictive than the rules in the DICOM standard, and then enforce conformance with those constraint rules. In new areas, such as life sciences, where the DICOM standard is still being developed, constraint rules can serve as transitional tools to enforce a conventional representation of the DICOM content, thereby simplifying future transition to the DICOM standard. Finally, database systemwide conformance can greatly simplify enterprise (application) integration and data mining.
DICOM constraint documents define one or more constraint rules to check the conformance of DICOM content according to the DICOM standard or the guidelines for a particular organization or enterprise. Example 2-3 shows a sample constraint document (sample_ct.xml).
Example 2-3 Sample Constraint Document
<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright (c) 2007, Oracle. All rights reserved.
NAME
sample_ct.xml - Oracle Multimedia DICOM sample constraint document
-->
<CONFORMANCE_CONSTRAINT_DEFINITION xmlns="http://xmlns.oracle.com/ord/dicom/constraint_1_0"
xmlns:dt="http://xmlns.oracle.com/ord/dicom/datatype_1_0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/ord/dicom/constraint_1_0
http://xmlns.oracle.com/ord/dicom/constraint_1_0">
<GLOBAL_RULE name="findJoeSmith">
<PREDICATE>
<DESCRIPTION>An example to find an object that has (patientName="Joe Smith"
AND patientSex=="M")</DESCRIPTION>
<LOGICAL operator="and">
<PREDICATE>
<RELATIONAL operator="eq">
<ATTRIBUTE_TAG>00100010</ATTRIBUTE_TAG>
<XML_VALUE>
<dt:PERSON_NAME>
<dt:NAME>
<dt:FAMILY>Smith</dt:FAMILY>
<dt:GIVEN>Joe</dt:GIVEN>
</dt:NAME>
</dt:PERSON_NAME>
</XML_VALUE>
</RELATIONAL>
</PREDICATE>
<PREDICATE>
<RELATIONAL operator="eq">
<ATTRIBUTE_TAG>00100040</ATTRIBUTE_TAG>
<XML_VALUE>
<dt:CODE_STRING>M</dt:CODE_STRING>
</XML_VALUE>
</RELATIONAL>
</PREDICATE>
</LOGICAL>
</PREDICATE>
<ACTION action="log" when="true">Found Joe Smith</ACTION>
</GLOBAL_RULE>
</CONFORMANCE_CONSTRAINT_DEFINITION>
After a constraint document has been inserted into the repository, users can validate DICOM content against the global constraint rules defined in the constraint document. (Global constraint rules are defined with the <GLOBAL_RULE> tag.) For example, users can check whether the DICOM content conforms to the global constraint rule named findJoeSmith, in Example 2-3.
ORDDicom objects can be processed and converted to other image formats. In addition, new ORDDicom objects can be created from existing ORDDicom objects. Figure 2-7 shows these operations.
The following text describes Figure 2-7 and discusses each of the components. The numbered items in the following text correspond to the numbered items in Figure 2-7. The lines connecting the items in Figure 2-7 show the direction for the flow of data.
The image converter (Item 2) can take DICOM content, specifically a DICOM image (Item 1), and processing commands (Item 3), and convert the DICOM content into an image (Item 4) of another format that is supported by Oracle Multimedia (for example: JPEG or GIF formats) for display in a Web browser or an application.
This process can also be reversed. Using an image such as an ORDImage object storing a JPEG file, TIFF file, or other supported image file (Item 4) and a DICOM metadata document (Item 5), the image converter can merge the two items and produce DICOM content that can be used to create a new ORDDicom object (Item 1). Similarly, the image converter (Item 2) can copy and convert the DICOM content (Item 4) and an XML metadata document (Item 5) into a new ORDDicom object (Item 1). Common uses of this type of process can include lossless compression on the converted image to save disk space, translation into a different type of transfer syntax to enable cross-platform image exchanging, or metadata updating.
When processing, the embedded image content can contain one or more frames. Depending on the processing command for frames, the image converter can read the pixel content of one or all the frames in an image. After the embedded DICOM image is written to an ORDImage object or a BLOB in a format such as GIF or JPEG, you can use existing Oracle Multimedia features to display the converted image on the Web with Oracle Multimedia JavaServer Pages (JSP) tag libraries or other tools.
In addition, multiframe DICOM images, such as MRIs, CTs, and Ultrasound videos, can be processed and converted to the Microsoft Video for Windows Audio Video Interleave (AVI) format. See Chapter 3 and Appendix D for more information about these and other DICOM processing operations.
Government regulations, such as the Health Insurance Portability and Accountability Act (HIPAA) in the U. S., mandate the protection of confidential data about patients. Sharing DICOM content with external resources often requires making confidential patient data anonymous. Making DICOM content anonymous in the database avoids exposing confidential patient data outside of the database, simplifying the protection of that information.
The process of making DICOM content anonymous can be customized using the data model repository. Users can create different anonymity documents in XML. Each anonymity document lists a set of attributes to be made anonymous, and the type of actions to be taken to make the attributes anonymous. Supported actions are remove and replace. The remove action is the default action that deletes an attribute or sets it to zero length in the DICOM content and in the ORDDicom object attributes. The replace action replaces an attribute with a string, which can either be empty or contain a user-defined string in the DICOM content and in the ORDDicom object attributes. Example 2-4 shows a sample anonymity document.
Example 2-4 Sample Anonymity Document
<?xml version="1.0" encoding="UTF-8"?> <!-- Copyright (c) 2006, 2007, Oracle. All rights reserved. --> <ANONYMITY_RULE_DOCUMENT xmlns="http://xmlns.oracle.com/ord/dicom/anonymity_1_0" xmlns:dt="http://xmlns.oracle.com/ord/dicom/datatype_1_0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/ord/dicom/anonymity_1_0 http://xmlns.oracle.com/ord/dicom/anonymity_1_0"> <DOCUMENT_HEADER> <dt:DOCUMENT_CHANGE_LOG> <dt:DOCUMENT_MODIFIER>Dongbai Guo</dt:DOCUMENT_MODIFIER> <dt:DOCUMENT_MODIFICATION_DATE>2006-02-06</dt:DOCUMENT_MODIFICATION_DATE> <dt:DOCUMENT_VERSION>0.1</dt:DOCUMENT_VERSION> <dt:MODIFICATION_COMMENT>Sample anonymity document</dt:MODIFICATION_COMMENT> <dt:BASE_DOCUMENT>Test Document</dt:BASE_DOCUMENT> <dt:BASE_DOCUMENT_RELEASE_DATE>2004-01-01</dt:BASE_DOCUMENT_RELEASE_DATE> <dt:BASE_DOCUMENT_DESCRIPTION>Same as ordcman.xml from label 070321</dt:BASE_DOCUMENT_DESCRIPTION> </dt:DOCUMENT_CHANGE_LOG> </DOCUMENT_HEADER> <PRIVATE_ATTRIBUTES action="remove"></PRIVATE_ATTRIBUTES> <UNDEFINED_STANDARD_ATTRIBUTES action="remove"></UNDEFINED_STANDARD_ATTRIBUTES> <UNDEFINED_PRIVATE_ATTRIBUTES action="remove"></UNDEFINED_PRIVATE_ATTRIBUTES> <INDIVIDUAL_ATTRIBUTE> <ATTRIBUTE_TAG>00100010</ATTRIBUTE_TAG> <DESCRIPTION>Patient Name</DESCRIPTION> <ANONYMITY_ACTION action="replace">Smith^Joe</ANONYMITY_ACTION> </INDIVIDUAL_ATTRIBUTE> <INDIVIDUAL_ATTRIBUTE> <ATTRIBUTE_TAG>00100020</ATTRIBUTE_TAG> <DESCRIPTION>Patient ID</DESCRIPTION> <ANONYMITY_ACTION action="replace">madeAnonymous</ANONYMITY_ACTION> </INDIVIDUAL_ATTRIBUTE> <INDIVIDUAL_ATTRIBUTE> <ATTRIBUTE_TAG>00100030</ATTRIBUTE_TAG> <DESCRIPTION>Patient Birth Date</DESCRIPTION> <ANONYMITY_ACTION action="remove"></ANONYMITY_ACTION> </INDIVIDUAL_ATTRIBUTE> </ANONYMITY_RULE_DOCUMENT>
|
See Also:
|
Oracle Multimedia enables the extraction of DICOM metadata outside the database by a client tool or in the middle tier. This feature enables the extraction of DICOM metadata before the data is loaded into the database, facilitating metadata-based partitioning of DICOM data in the database.
Partitioning supports very large tables and indexes by enabling you to reorganize them into smaller, and thus more usable, chunks called partitions. Partitioning can make your data more available, easier to manage, and faster to query.
You can include DICOM metadata attributes in the partition key, a set of one or more columns that determines the partition in which each row in a partitioned table is stored. To ensure that data is stored in the correct partition, you must provide values for the partition key when the data is loaded.
Oracle Multimedia DICOM includes the Oracle Multimedia Mid-Tier Java API. This client application programming interface for the middle tier enables developers to write Java applications to extract DICOM metadata outside of Oracle Database. This API enables the extraction of DICOM attributes that constitute the partition key before the data is loaded into the database.
|
See Also:
|
This guide describes how to use the Digital Imaging and Communications in Medicine (DICOM) feature of Oracle Multimedia, which ships with Oracle Database.
In Oracle Database 11g Release 1 (11.1), the name Oracle interMedia was changed to Oracle Multimedia. The feature remains the same, only the name has changed. References to Oracle interMedia were replaced with Oracle Multimedia although, some references to Oracle interMedia or interMedia might still appear in graphical user interfaces, code examples, and related documents in the Documentation Library for Oracle Database 11g Release 2 (11.2).
This information in this guide is organized as follows:
| Title | Contents |
|---|---|
| Part I, "DICOM Common Usage and Reference" | Introductory, conceptual, user, and reference information, which is common to administrators and developers of DICOM applications |
| Part II, "DICOM Development Usage and Reference" | User and reference information for developers of DICOM applications |
| Part III, "DICOM Administration Usage and Reference" | User and reference information for administrators of the DICOM data model repository |
| Part IV, "DICOM Appendixes" | Supplementary information about Oracle Multimedia DICOM |
The sample code in this guide might not match the code shipped with Oracle Database Examples media. To run examples that are shipped with Oracle Database Examples media on your system, use the files provided with Oracle Database Examples media. Do not attempt to compile and run the code in this guide.
For information about Oracle Database and the features and options that are available to you, see Oracle Database New Features Guide.
This guide is for application developers and administrators who are interested in storing, retrieving, and manipulating DICOM format medical images and other objects in a database.
Our goal is to make Oracle products, services, and supporting documentation accessible to all users, including users that are disabled. To that end, our documentation includes features that make information available to users of assistive technology. This documentation is available in HTML format, and contains markup to facilitate access by the disabled community. Accessibility standards will continue to evolve over time, and Oracle is actively engaged with other market-leading technology vendors to address technical obstacles so that our documentation can be accessible to all of our customers. For more information, visit the Oracle Accessibility Program Web site at http://www.oracle.com/accessibility/.
Accessibility of Code Examples in Documentation
Screen readers may not always correctly read the code examples in this document. The conventions for writing code require that closing braces should appear on an otherwise empty line; however, some screen readers may not always read a line of text that consists solely of a bracket or brace.
Accessibility of Links to External Web Sites in Documentation
This documentation may contain links to Web sites of other companies or organizations that Oracle does not own or control. Oracle neither evaluates nor makes any representations regarding the accessibility of these Web sites.
Access to Oracle Support
Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/support/contact.html or visit http://www.oracle.com/accessibility/support.html if you are hearing impaired.
|
Note: For information added after the release of this guide, see the onlineREADME.txt file under your <ORACLE_HOME> directory. Depending on your operating system, this file may be in
See your operating system-specific installation guide for more information. |
For more information about using Oracle Multimedia in a development environment, see the following documents in the Oracle Database Online Documentation Library:
For more information about using XML, see Oracle XML DB Developer's Guide.
For more information about medical imaging standards, see the documentation provided by the National Electrical Manufacturers Association (NEMA).
For reference information about Oracle Multimedia Java classes in Javadoc format, see the following Oracle API documentation (also known as Javadoc) in the Oracle Database Online Documentation Library:
For more information about Java, including information about Java Advanced Imaging (JAI), see the API documentation provided by Oracle.
Many of the examples in this guide are based on the database user PM and the tables MEDICAL_IMAGE_OBJ and MEDICAL_IMAGE_REL, which are created in the Product Media (PM) sample schema. See Oracle Database Sample Schemas for information about how these schemas are installed and how you can use them.
The following text conventions are used in this guide:
| Convention | Meaning |
|---|---|
| boldface | Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary. |
| italic | Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values. |
monospace | Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter. |
Syntax descriptions are provided in this guide for various SQL, PL/SQL, or other command-line constructs in graphic form or Backus Naur Form (BNF). See Oracle Database SQL Reference for information about how to interpret these descriptions.
ordcrpsp.sql file, 12ordcspec.sql file, 7