5 DICOM Application Development

5.4.1 Selecting DICOM Attributes

This section shows how to access DICOM attributes from the DICOM content that you loaded in Section 5.3.

After the table medical_image_table is populated and metadata has been extracted, you can access metadata using SQL queries. Example 5-4 demonstrates how to select extracted DICOM metadata from the DICOM content.

1.     SOP_INSTANCE_UID.
2.     SOP_CLASS_UID
3.     STUDY_INSTANCE_UID
4.     SERIES_INSTANCE_UID.
5.     Content length (number of bytes of DICOM content)
6.     Patient Name, Patient ID, and Modality from DICOM metadata
 
 
select id,
       t.dicom.getSOPInstanceUID() as SOP_Instance_UID
from medical_image_table t;
 
select id,
       t.dicom.getSOPClassUID() as SOP_Class_UID
from medical_image_table t;
 
select id,
       t.dicom.getStudyInstanceUID() as Study_Instance_UID
from medical_image_table t;
 
select id,
       t.dicom.getSeriesInstanceUID() as Series_Instance_UID
from medical_image_table t;
 
select id,
       t.dicom.getcontentlength() as content_Length
from medical_image_table t;

select m.id, t.PATIENT_NAME, t.PATIENT_ID, t.MODALITY
from medical_image_table m,
  xmltable
    (xmlnamespaces
      (default 'http://xmlns.oracle.com/ord/dicom/metadata_1_0'),
           '/DICOM_OBJECT'
       passing m.dicom.metadata
       columns
         patient_name varchar2(100)
                   path './*[@name="Patient''''s Name"]/VALUE',
         patient_id   varchar2(100)
                   path './*[@name="Patient ID"]',
         modality     varchar2(100)
                   path './*[@name="Modality"]'
    ) t ;

Running Example 5-4 generates the following output:

ID SOP_INSTANCE_UID
-- -------------------------------------------------------
 1 1.2.392.200036.9116.2.2.2.1762676206.1077529882.102147
 
ID SOP_CLASS_UID
-- -------------------------------------------------------
 1 1.2.840.10008.5.1.4.1.1.2
 
ID STUDY_INSTANCE_UID
-- -------------------------------------------------------
 1 1.2.392.200036.9116.2.2.2.1762929498.1080638122.365416
 
ID SERIES_INSTANCE_UID
-- -------------------------------------------------------
 1 1.2.392.200036.9116.2.2.2.1762929498.1080638122.503288
 
ID CONTENT_LENGTH
-- ---------------
 1   525974
 
ID PATIENT_NAME                    PATIENT_ID      MODALITY
--- ------------------------------ ----------      ----------
 1 CANCIO   2HR                    A-02-013        CT 

5.4.2 Creating Thumbnail Images and Changing Image Formats

This section demonstrates some image processing operations that can be invoked within the database.

As an example, to create a JPEG thumbnail image from a DICOM image, you generate a new ORDImage object from the ORDDicom object. Before you can complete this task, you must describe the desired properties of the new ORDImage object.

The following description generates a JPEG thumbnail image of size 75x100 pixels:

'fileFormat=jfif fixedScale=75 100'

The code segment shown in Example 5-5 defines the procedure generate_thumb(), which performs these tasks:

• Populates the column imageThumb of the table medical_image_table with the identifier source_id.

• Generates an ORDImage object in the column by invoking the processCopy( ) method on the ORDDicom object in the source row.

The code statements in Example 5-5 where these tasks are performed are highlighted in bold.

-- Set Data Model Repository
execute ordsys.ord_dicom.setDataModel();
 
create or replace procedure generate_thumb(source_id number, verb varchar2) is
    dcmSrc    ordsys.orddicom;
    imgDst    ordsys.ordimage;
begin
  select dicom, imageThumb into dcmSrc, imgDst from medical_image_table
         where id = source_id for update;
  dcmSrc.processCopy(verb, imgDst);
 
  update medical_image_table set imageThumb = imgDst where id = source_id;
  commit;
end;
/
 
 
-- Create a JPEG thumbnail image for our test DICOM
execute generate_thumb(1, 'fileFormat=jfif fixedScale=75 100');
 
-- look at our handiwork
column t.imageThumb.getFileFormat() format A20;
select id, t.imageThumb.getWidth(), t.imageThumb.getHeight(), 
       t.imageThumb.getFileFormat() 
from medical_image_table t;

Running Example 5-5 generates the following output:

ID  T.IMAGETHUMB.GETWIDTH() T.IMAGETHUMB.GETHEIGHT() T.IMAGETHUMB.GETFILE
--- ----------------------- ------------------------ ----------------------
 1              75                      100            JFIF

5.4.3 Making Anonymous Copies of ORDDicom Objects

This section shows how to protect patient privacy by making ORDDicom objects anonymous.

To make ORDDicom objects anonymous, you must create a new ORDDicom object in which certain user-specifiable DICOM attributes have either been removed or overwritten in both the new DICOM content and the associated ORDDicom object metadata. An XML anonymity document specifies which DICOM attributes to remove or replace and what action to take to make each attribute anonymous.

The default anonymity document, ordcman.xml, is loaded during installation. You can create a customized anonymity document, but that topic is beyond the scope of this example. This example uses the default anonymity document.

The code segment in Example 5-6 defines the procedure generate_anon(), which performs these tasks:

• Selects the original content dicom and the column anonDicom of the table medical_image_table with the identifier source_id.

• Generates an ORDDicom object in the column anonDicom by calling the makeAnonymous( ) method on the dicom in the source row.

If you run this code segment, replace the temporary UID for the variable dest_sop_instance_uid in the procedure generate_anon with a globally unique UID.

The code statement in Example 5-6 where the makeAnonymous( ) method is called is highlighted in bold.

-- Set Data Model Repository
 
execute ordsys.ord_dicom.setDataModel();
 
create or replace procedure generate_anon(source_id number) is
    dcmSrc    ordsys.orddicom;
    anonDst   ordsys.orddicom;
    dest_sop_inst_uid varchar2(128) := '1.2.3';
 
begin
  select dicom, anonDicom into dcmSrc, anonDst from medical_image_table
         where id = source_id for update;
  dcmSrc.makeAnonymous(dest_sop_inst_uid, anonDst);
  update medical_image_table set anonDicom = anonDst where id = source_id;
  commit;
end;
/
 
-- Generate an Anonymous Copy of our test DICOM
execute generate_anon(1);

select m.id, t.PATIENT_NAME, t.PATIENT_ID
from medical_image_table m,
  xmltable
   (xmlnamespaces
     (default 'http://xmlns.oracle.com/ord/dicom/metadata_1_0'),
          '/DICOM_OBJECT'
      passing m.anondicom.metadata
      columns
        patient_name varchar2(100)
                  path './*[@name="Patient''''s Name"]/VALUE',
        patient_id   varchar2(100)
                  path './*[@name="Patient ID"]'
   ) t ;

Running Example 5-6 generates the following output:

ID PATIENT_NAME                    PATIENT_ID
--- ------------------------------ ----------
 1  anonymous                      anonymous

5.4.4 Checking the Conformance of ORDDicom Objects

This section shows how to check the conformance of ORDDicom objects against a set of user-specified constraint rules. Constraint rules are specified in one or more constraint documents. These XML documents specify attribute relationships and semantic constraints that cannot be expressed by the DICOM metadata schema.

A default constraint document, ordcmct.xml, is loaded during installation. You can create a customized constraint document, but that topic is beyond the scope of this example. This example uses the default constraint document.

The code segment in Example 5-7 defines the procedure check_conform(), which performs these tasks:

• Selects the original content dicom of the table medical_image_table with the identifier source_id.

• Displays a line of output text, which indicates either of these conditions for the DICOM content:

  • Conformance valid

    isconformanceValid(OracleOrdObject): 1

  • Not conformance valid

    isconformanceValid(OracleOrdObject): 0

-- Set Data Model Repository
execute ordsys.ord_dicom.setDataModel();
 
create or replace procedure check_conform(source_id number) is
    dcmSrc    ordsys.orddicom;
begin
  select dicom into dcmSrc from medical_image_table
         where id = source_id;
  dbms_output.put_line('isconformanceValid(OracleOrdObject): ' ||
    dcmSrc.isConformanceValid('OracleOrdObject'));
end;
/
show errors;

Running Example 5-7 generates the following output:

SQL> execute check_conform(1) ;
isconformanceValid(OracleOrdObject): 1

The value of 1 indicates that the DICOM content used in this example was valid because it conformed to the Oracle default constraint rules. If the DICOM content had not been valid, running the example would have returned a value of 0. And, one or more constraint messages generated during the previous conformance validation would have been found in the view orddcm_conformance_vld_msgs.

The following code segment shows the description of this view:

SQL> describe orddcm_conformance_vld_msgs;

 Name                         Null?          Type
 ----------------------    -------------    ---------------------
 SOP_INSTANCE_UID                            VARCHAR2(128 CHAR)
 RULE_NAME                  NOT NULL         VARCHAR2(64 CHAR)
 MESSAGE                                     VARCHAR2(1999 CHAR)
 MSG_TYPE                   NOT NULL         VARCHAR2(20 CHAR)
 MSG_TIME                   NOT NULL         TIMESTAMP(6)

You can query this view to examine any constraint messages that are generated during conformance validation. Because the DICOM content used in this example conformed with the Oracle constraint rules, there are no messages in the orddcm_conformance_vld_msgs view.

select * from orddcm_conformance_vld_msgs;

Thus, invoking the preceding select query generates the following output:

no rows selected

See Section 3.2.8 for information about what to do if your DICOM content does not conform to the constraint rules defined for your organization. See DICOM Repository Public Views for information about the view orddcm_conformance_vld_msgs.

5.4.5 Handling Oracle Multimedia DICOM Exceptions in PL/SQL

Possible errors that can occur during run time should always be handled in your application. This practice enables the program to continue its operation even when it encounters a run-time error. This practice also enables you to know what went wrong during program operation. Proper error handling practices ensure that, whenever possible, you are always able to recover from an error while running an application. In addition, proper error handling provides you with the information you need so you always know what went wrong.

When handling exceptions, PL/SQL uses exception blocks. For example, in PL/SQL, the exception can appear as:

BEGIN
<some program logic>
EXCEPTION
     WHEN OTHERS THEN
     <some exception logic>
END;

When you design, code, and debug your application, you are aware of the places in your program where processing might stop due to a failure to anticipate an error. Those are the places in your program where you must add exception handling blocks to handle the potential errors.

5.5.1 Setting Up Your Environment Variables

Before you can begin using Oracle Multimedia DICOM Java API, you must set up your environment to compile and run Java programs. First, you must specify the environment variable CLASSPATH. In addition, you must ensure that this variable includes the appropriate Oracle Java libraries for the Oracle Multimedia and other features that you intend to use.

5.5.2 Importing Oracle Java Classes into Your Application

After setting up your environment variables and including the appropriate Oracle Java libraries, you must include the appropriate import statements in your Java application before using Oracle Multimedia DICOM Java API.

Execute the following statements to import the required classes from the oracle.ord.dicom.* package and the oracle.ord.im.* package:

import oracle.ord.dicom.OrdDicom;
import oracle.ord.im.OrdImage;

Along with the standard JDBC classes included in the java.sql package, you must also import the Oracle JDBC extension class oracle.jdbc.OracleResultSet, with the following statement:

import oracle.jdbc.OracleResultSet;

5.5.3 Handling Oracle Multimedia DICOM Exceptions in Java

Possible errors that can occur during run time should always be handled in your application. This practice enables the program to continue its operation even when it encounters a run-time error. This practice also enables you to know what went wrong during program operation. Proper error handling practices ensure that, whenever possible, you are always able to recover from an error while running an application. In addition, proper error handling provides you with the information you need so you always know what went wrong.

When handling exceptions, Java uses the try/catch block. For example, in Java, the exception can appear as:

try {
    //<some program logic>)
}
catch (exceptionName a) {
//Exception logic
}
finally {
//Execute logic if try block is executed even if an exception is caught
}

When you design, code, and debug your application, you are aware of the places in your program where processing might stop due to a failure to anticipate an error. Those are the places in your program where you must add exception handling blocks to handle the potential errors.