This appendix describes two options for migrating data and application code from the DICOM support (in ORDImage objects) that was introduced in Oracle Database 10g Release 2 (10.2) to the DICOM support that was introduced in Oracle Database 11g Release 1 (11.1). The following table summarizes the migration options:
| Migration Option | How It Works |
|---|---|
| Option 1 | Uses the data in the original ORDImage objects with the DICOM relational interface. This option has less impact on existing applications than Option 2. (See Section F.2.) |
| Option 2 | Uses a copy of the data with the ORDDicom object type interface. This option takes full advantage of the DICOM and SecureFiles LOBs features. (See Section F.3.) |
This appendix includes these sections:
DICOM Support in ORDImage Objects (Deprecated)
The DICOM support in ORDImage objects that was introduced in Oracle Database 10g Release 2 (10.2) is deprecated in Oracle Database 12c Release 1 (12.1), and may be desupported in a future release. Oracle recommends these actions:
Write new medical imaging applications to use the DICOM support that was introduced in Oracle Database 11g Release 1 (11.1). This support is documented in this guide.
Migrate existing medical imaging applications from the DICOM support in ORDImage objects to the DICOM support that was introduced in Oracle Database 11g Release 1 (11.1). This appendix describes the migration process.
See Oracle Multimedia Reference for complete information about deprecated API components.
The examples in this appendix are based on the table imageTable. This table is defined as follows:
imageTable( id integer,
image ordsys.ordimage,
thumb ordsys.ordimage
where:
image: the name of the ORDImage column
thumb: the name of the thumbnail image column
You can leave the data in the original ORDImage objects and use the DICOM relational interface to access the DICOM functions. Using this migration option does not require copying of your existing DICOM content.
The disadvantages of using this migration option are:
You are most likely not using the rearchitected and better performing SecureFiles LOBs.
You must rewrite the parts of your application that access Oracle Multimedia. (To take full advantage of the DICOM and SecureFiles LOBs features, use the migration option explained in Section F.3.)
To use this migration option:
Leave your data in ORDImage columns.
Use the ORD_DICOM relational package to access DICOM features (see DICOM Relational Interface Reference).
The following code segment shows this migration process, using ORDImage objects to store DICOM content.
execute ORD_DICOM.setDataModel; alter table imageTable add (metadata sys.xmltype); declare img ordsys.ordimage; thb ordsys.ordimage; ctx raw(64) := null; meta sys.xmltype; begin insert into imageTable (id, image, thumb) values (1, ordsys.ordimage(), ordsys.ordimage()) returning image, thumb into img, thb; img.importFrom(ctx, 'file','DICOMDIR','example.dcm'); ORD_DICOM.processCopy(img, 'fileFormat =jfif maxScale=100 100', thb.source.localData); meta := ORD_DICOM.extractMetadata(img.getContent, 'ALL'); ...
In this example, the highlighted lines of code show the following operations:
First line in bold: Shows how to load the DICOM data model repository, which is used by the DICOM methods, procedures, and functions.
Second and third lines in bold: Show how to modify the ORDImage table (imageTable) by adding a column to store DICOM metadata as an XML document.
Fourth and fifth lines in bold: Show how to generate a JPEG thumbnail image from the original DICOM image, using the processCopy( ) procedure in the ORD_DICOM package (relational interface).
Last line in bold: Shows how to extract all attributes of the embedded DICOM content, using the extractMetadata( ) function in the ORD_DICOM package (relational interface).
You can copy data into the ORDDicom object type and rewrite your application to use ORDDicom methods. Using this migration option enables you to take full advantage of the features and performance of the ORDDicom object type and SecureFiles LOBs.
The disadvantages of using this migration option are:
You must copy your existing DICOM content into an ORDDicom object type.
You must rewrite the parts of your application that access Oracle Multimedia.
To use this migration option:
Copy your data into ORDDicom objects.
Modify your application to use the ORDDicom methods.
Step 1: Copying Your Data into ORDDicom Objects
This example uses sample code to show how you can copy your data into ORDDicom objects.
-- Add new dicomImage column to table
alter table imageTable add
(dicomImage ORDSYS.ORDDICOM)
pctfree 60
lob (dicomimage.source.localdata) store as securefile
(nocache disable storage in row);
-- Copy DICOM images from image column to dicomImage column
update imageTable t set t.dicomImage = new orddicom(t.image);
-- After copying, drop the original image column if desired
alter table imagetable drop column image;
Assuming that you have an existing table (imageTable) with an ORDImage column (image), the preceding example performs these actions:
Adds a DICOM image column (dicomImage) to store DICOM content as type ORDDicom.
Updates the table by copying the DICOM content from the image column into the new dicomImage column.
Removes the image column from the table.
Step 2: Modifying Your Application to Use ORDDicom Methods
This code segment uses an existing application that has been rewritten to use the ORDDicom object type.
declare dcm ordsys.orddicom; thb ordsys.ordimage; ctx raw(64) := null; begin insert into imageTable(id, dicomImage, thumb) values (1, ordsys.orddicom('file', 'DICOMDIR','example.dcm'), ordsys.ordimage()) returning dicomImage, thumb into dcm, thb; dcm.import(1); dcm.processCopy('fileFormat =jfif maxScale=100 100', thb); thb.setProperties(); . . .
In this example, the highlighted lines of code show the following operations:
First line in bold: Shows how to use a variable declaration for the ORDDicom object (dcm).
Second line in bold: Shows how to insert a row into a table with an ORDDicom object pointing to a DICOM file in the local file system.
Third line in bold: Imports the DICOM image from the local file system into the SecureFiles LOB in the ORDDicom object. Because the parameter (1) is passed, the setProperties( ) method is automatically called to extract all attributes in the embedded DICOM content into attributes of the ORDDicom object.
Last two lines in bold: Show how to generate a JPEG thumbnail image from a DICOM image. (This code is similar to the syntax for Oracle Database 10g Release 2.)
See Also:
Oracle Multimedia Reference for more information about ORDImage methods
Determining whether to migrate your application by using either the new DICOM relational interface or the new ORDDicom object type depends on your situation and the kinds of applications that exist in your environment. For example, if you have extensive data and limited resources, the migration option of copying your existing DICOM content into an ORDDicom object type might prove too costly and inconvenient. Instead, you might choose to forego the new DICOM and SecureFiles LOBs benefits in favor of speedily migrating your application, with limited impact on the existing data. In contrast, if you have limited data in ORDImage objects, you might choose to rewrite your applications and copy your existing data into the ORDDicom object type to enable access to all the new DICOM and SecureFiles LOBs benefits.