|Oracle® Multimedia DICOM Developer's Guide
11g Release 2 (11.2)
|PDF · Mobi · ePub|
This chapter includes these sections:
Digital Imaging and Communications in Medicine (DICOM) is a medical imaging standard that was initiated by the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) to enhance the connectivity of radiological devices. Before the DICOM standard became widely adopted, each manufacturer had its own proprietary image format and communication protocol. This proliferation of formats and protocols made it almost impossible to produce third-party software to manage or study medical content, or to connect hardware devices from different manufacturers.
For the most part, the DICOM standard is developed by volunteers. Working groups formed by domain experts propose additions and changes to the existing standards, and the changes are approved by a balloting process. Typically, the National Electrical Manufacturers Association publishes a new version of the standard each year, and makes it available worldwide on its Web site. In addition, the Integrating the Healthcare Enterprise (IHE) initiative provides information about issues related to DICOM content and communication, and makes this information available on its Web site.
The following subsections provide introductory information about DICOM:
In 1985, the American College of Radiology and the National Electrical Manufacturers Association jointly published the ACR-NEMA medical imaging and communication standard to address the proliferation problem. In 1993, the ACR-NEMA standard was revised and renamed as the DICOM standard (Version 3.0). Since the release of Version 3.0, the DICOM standard has become the dominant standard for radiology imaging and communication. All major manufacturers now conform to the DICOM standard.
Today, any software component can take DICOM content from any manufacturer and manage that content with a uniform interface. The term DICOM content refers to standalone DICOM Information Objects that are encoded according to the data structure and encoding definitions of PS 3.10 of the DICOM standard (commonly referred to as DICOM Part 10 files). (In the DICOM standard, the phrase DICOM objects refers to DICOM content.)
The DICOM standard has two major areas of focus: the file format and the communication protocol. Content such as images and waveforms captured by medical devices is represented as information objects. Services such as get, find, and store operations can be defined on these information objects. The combination of services and information objects is a service object pair (SOP).
The DICOM standard (Part 5 and Part 6) defines different types of transfer syntax (or binary encoding rules) for sending objects across the network or encoding objects in files. Transfer syntax specifies the mapping of a DICOM object hierarchy into a binary stream.
The binary data can be stored on physical media such as tapes, CDs, or disks, and organized in accordance with the DICOM file hierarchy. It can also be exchanged over a network with the DICOM communication protocol. The DICOM communication protocol covers the upper three layers (Application, Presentation, and Session) of the Open Systems Interconnection (OSI) Seven Layer Model. The DICOM protocol is typically implemented on top of TCP/IP.
Note:The Oracle Multimedia DICOM feature deals with the storage, management, and manipulation of DICOM format medical images and other objects encoded into files. Oracle Multimedia does not support the DICOM communication protocol.
Messages exchanged between a DICOM server and a DICOM object involve operations such as these:
Grayscale image rendering
Storage and retrieval
Recently, the DICOM standard introduced Web access to DICOM objects (WADO). WADO deals primarily with HTTP access to DICOM objects.
DICOM content can include many different types of data, such as the following:
Patient administration information
Slices of 3-D volumes
DICOM content also contains standard attributes and private attributes. Standard attributes are defined and published in the DICOM standard. Private attributes are defined by and specific to private organizations, such as manufacturers and other enterprises. The DICOM data dictionary provides the definitions for DICOM standard and private attributes.
The Digital Imaging and Communications in Medicine (DICOM) feature was first introduced to Oracle Multimedia in Oracle Database 10g Release 2 (10.2). For that release, Oracle Multimedia DICOM enhanced the previous behavior of the Oracle Multimedia ORDImage object type by enabling Oracle Multimedia to recognize DICOM content and extract a subset of embedded DICOM attributes relating to patient, study, and series.
Oracle Database 11g Release 1 (11.1) continued to provide the same DICOM support in ORDImage, while introducing more complete DICOM support in a new ORDDicom object type. See Appendix F for information about migrating from DICOM support (in ORDImage objects) to the DICOM support that was introduced in Oracle Database 11g Release 1 (11.1).
The following subsections briefly introduce the support provided by the DICOM feature in Oracle Database 11g Release 2 (11.2):
Oracle Multimedia User's Guide for information about DICOM support for the ORDImage object type
With Oracle Database 11g Release 1 (11.1), Oracle Multimedia provided full support for the DICOM file format, which is universally recognized as the standard for medical imaging. Applications can now use Oracle Multimedia DICOM Java and PL/SQL APIs to store, manage, and manipulate DICOM content.
Customers can build large archives of medical content that are managed and secured using Oracle Database. Complete DICOM metadata support enables customers to index and search the archived DICOM content for research purposes. Central storage of DICOM content makes telemedicine practical. Incorporating DICOM content in a database enables customers to build electronic healthcare records applications, using application development tools from Oracle or others.
A new Oracle Multimedia object type, ORDDicom, natively supports DICOM content produced by medical devices. This object type holds the DICOM content and extracted metadata, and implements the methods to manipulate the DICOM content. A new Java proxy class, OrdDicom, provides access to the ORDDicom database object through JDBC in a Java application. For applications that store DICOM content directly in BLOBs or BFILEs, a relational interface is provided as a PL/SQL package (ORD_DICOM).
By presenting DICOM content stored in a database as objects, Oracle enables both rapid application development and easy, secure management of large archives of DICOM content.
Oracle Database 10g Release 2 (10.2) provided support for extracting the most important metadata as DICOM attribute tags into an XML document, and then indexing and searching these tags to find DICOM content that matched certain conditions. Oracle Database 11g Release 1 (11.1) extended that capability by supporting complete and extensible metadata extraction. Customers can extract metadata according to an Oracle-specified XML schema, or create and use their own schema definition to extract subsets of the standard DICOM attribute tags or private tags. The extracted metadata can then be stored in a table to facilitate DICOM content searching based on standard or private DICOM attributes.
This enhanced metadata extraction capability enables customers to build large archives of DICOM content. By customizing extracted XML metadata documents, customers can create highly specialized indexes to DICOM content based on standard and private DICOM attribute tags.
Oracle Database 11g Release 1 (11.1) provided support for conformance validation, enabling customers to verify that DICOM content adheres to a set of user-specified constraint rules.
DICOM content is generated by many devices. While most conform to the DICOM standard, some do not. It is important to be able to identify DICOM content that does not conform to the standard, or to the constraint rules for a particular organization or enterprise. Validating DICOM content for conformance can ensure the consistency of a DICOM archive. It enables a database to accept DICOM content from multiple sources and verify the integrity of the content.
Oracle Database 11g Release 1 (11.1) added methods and functions to copy and process DICOM content into DICOM content or other formats (for example: JPEG, GIF, PNG, and TIFF), and to copy and generate scaled versions and thumbnail images. In addition, that release provided a set of optional methods and functions to copy and process (for example: compress, scale, rotate, and crop) image content, during the conversion process.
Oracle Database 11g Release 2 (11.2) adds functions to copy and process DICOM content into video formats. Oracle Multimedia supports the processing of multiframe DICOM content to the Microsoft Video for Windows Audio Video Interleave (AVI) format. You can generate output in AVI format from multiframe DICOM content such as MRIs, CTs, and Ultrasound videos (see Section D.5).
To view medical images stored in the DICOM format in Web applications, you must create a copy of the images in formats that are compatible with the browsers that are currently used in the industry. Oracle Database 11g Release 1 (11.1) enabled customers to automatically copy, reformat, and deliver DICOM images to applications that require popular industry-standard image formats such as JPEG.
Oracle Database 11g Release 1 (11.1) added a method that makes new ORDDicom objects with DICOM content and extracted XML attributes anonymous, in accordance with the rules specified by an anonymity document. The anonymity document defines both the set of attributes to be made anonymous and the actions to make them anonymous.
This method can be used to generate new, anonymous ORDDicom objects, ensuring that users of a DICOM medical archive see only the DICOM content and metadata that they are authorized to see. For example, clinicians require full access to DICOM content and metadata for each patient they are treating. They must be able to view all the DICOM metadata included in DICOM content. Researchers, however, require only partial access to the same DICOM metadata for patients participating in a study. Patient privacy regulations require that this class of users not be permitted to view attributes and metadata included in ORDDicom objects that contain personally identifying information.
By providing anonymity services in the database, Oracle Database enables appropriate access for different classes of users of a DICOM medical archive.
Oracle Database 11g Release 1 (11.1) included the ability to generate new ORDDicom objects by combining digital images of various formats (for example: DICOM, JPEG, RAW, TIFF, and GIF) with an XML representation of the associated DICOM metadata. Oracle Database 11g Release 2 (11.2) supports the ability to generate new ORDDicom objects by combining digital video of MPEG format with an XML representation of the associated DICOM metadata. This operation results in well-formed and validated ORDDicom objects, which can be stored in a table in the database or delivered to a DICOM viewer. This feature is particularly useful for generating DICOM secondary capture images and video (see Section 3.2.7).
Storing and retrieving film-based medical images is expensive and prone to loss. Replacing film-based medical images with DICOM images reduces storage and retrieval costs, and reduces the risk of loss. Storing scanned images and digital video with their metadata in DICOM format can make non-DICOM images and video more useful.
New DICOM content can also be generated to correct metadata errors in the original DICOM content.
A key feature of DICOM support provided in Oracle Database 11g Release 1 (11.1) is that its run-time behavior is determined by a set of user-configurable documents. This set of documents is collectively managed by the data model repository. Administrators can update this data model repository to configure Oracle Multimedia DICOM for a particular database instance.
Hospitals must always be up and running. They cannot shut down the system for any of the following reasons:
To update to a new version of the DICOM standard
To incorporate private DICOM attribute tags for a new piece of equipment
To change their DICOM conformance rules
To modify the set of DICOM attribute tags they extract from each ORDDicom object or to change the XML encoding of the extracted attributes
To modify their DICOM anonymity rules
This design enables customers to upgrade Oracle Multimedia DICOM at any time, without interfering with a running DICOM archive.