Digital Imaging and Communications in Medicine (DICOM) is a standard specifying an imaging file format and a networking protocol to be used in the medical imaging domain. Picture Archiving and Communications Systems (PACS) are designed to store and transfer medical images in the DICOM format using DICOM network protocol.
Medical imaging devices (such as CT scanners and X-ray machines) communicate with one or more PACS to store images. Health care professionals then review images using a DICOM viewer application to query PACS to retrieve relevant patient information.
DICOM support has been integrated into Oracle WebCenter Content to give Content Server users access to DICOM images. This integration allows images originally stored in a PACS or on the local file system to be managed using Content Server. The DICOM support that has been integrated is based on the functionality of Oracle Multimedia DICOM, a feature of Oracle Database.
The software that provides the Oracle Multimedia DICOM and WebCenter Content integration is available on the Oracle Technology Network at the following location:
http://www.oracle.com/technetwork/middleware/webcenter/content/downloads/index.html
This section discusses the following topics:
The DICOM support that is integrated with Oracle WebCenter Content is based on Oracle Multimedia DICOM, which is a feature of Oracle Database that enables the efficient management and retrieval of image, audio, video, and medical imaging data in Oracle Database. Oracle Multimedia's comprehensive support for DICOM content includes a rich set of security, conformance, metadata, and processing features to enable open, scalable archives and applications in healthcare and life sciences.
DICOM functionality with Oracle WebCenter Content allows Content Server users to import images from PACS or a local file system, extract metadata associated with images, and generate thumbnail views to store in WebCenter Content. Users can also access DICOM images stored in a PACS via a WADO (Web Access to DICOM Persistent Objects)-compliant URL
The DICOM metadata extracted from the images is mapped to custom metadata fields in Content Server. From there, it can be managed as needed by users. This provides a unified view of a set of PACS with a common interface for searching and retrieval of image information and metadata.
DICOM support in WebCenter Content has two main elements:
When the Oracle DICOM protocol adapter is configured to manage a set of DICOM clients (such as PACS), the adapter periodically queries the set of managed clients to check for new DICOM images. As new images are discovered, the adapter retrieves the images and checks them into Content Server using the Oracle DICOM component for WebCenter.
Depending on the configuration, the following types of content may be checked in:
the original DICOM image
a non-DICOM preview image (such as a .jpeg file) of the original image
an XML representation of the metadata stored in the original DICOM image
After images are stored in Content Server, they can be accessed through standard services or from the DICOM adapter via the DICOM network protocol.
The Oracle DICOM protocol adapter suite communicates with DICOM clients, such as viewers or PACS. It interacts with WebCenter Content to perform operations based on these communications to store, query, and retrieve images from the content server repository.
The suite is comprised of three WebLogic applications that run in the mid-tier on the WebLogic Application Server. These applications communicate with PACS, viewers, and other DICOM clients:
The Oracle DICOM protocol adapter, which is the core application of the suite. It serves as a bridge between standard DICOM clients (such as PACS and DICOM viewers) and WebCenter Content.
The Oracle DICOM crawler, which is a scheduled service of the adapter. It periodically queries a set of PACS using the DICOM protocol to import new DICOM images and/or DICOM metadata into WebCenter Content.
The Oracle DICOM WADO proxy, which is a service used to retrieve DICOM images from remote DICOM clients (such as PACS) via a WADO-formatted URL.
A Content Server entry is always created for DICOM images on checkin. The suite can be configured to manage only the metadata of DICOM images that are checked in or can be configured to manage the actual image as well. It can also be configured to manage a WADO link to point to the location of the original image.
For more details, see Chapter 2, "Installing and Configuring the Oracle DICOM Protocol Adapter."
When the Oracle DICOM component for WebCenter is installed and enabled on the Content Server, it is used to manage the storage and processing of images in the repository by implementing a checkin filter. The DICOM component is a collection of Content Server services that allow users to check in and process DICOM content and to configure the behavior of the DICOM check-in service.
For more details, see Chapter 3, "Installing and Configuring the Oracle DICOM Component for WebCenter."
The Content Server serves as a centralized repository for DICOM images or for images plus metadata. This differs from traditional methods of DICOM usage where images may be scattered among a number of PACS.
There are two common usage scenarios:
the user consolidates all DICOM images and image metadata from PACS into Content Server.
the user consolidates only DICOM image metadata into Content Server.
In both scenarios, the Oracle DICOM crawler can be configured with the connection details of all the PACS used for importing. Associated with each PACS in the configuration will be a DICOM query that serves as a filter restricting which images will be returned from the PACS. For example, the Crawler might be configured to query a PACS on a daily basis and to retrieve all images added to the PACS since the day before.
The Oracle DICOM component for WebCenter would also be configured to include metadata mapping for those elements the user wants to retain in Content Server when the image is imported.
See Section 2.4, "Sample Configuration Scenarios" for details about how to configure these two scenarios.
The DICOM crawler can be configured to manage a given set of DICOM clients (for example, PACS). For each DICOM client in the set, the DICOM crawler must periodically query the client to find new images that may have been added since the last query. This type of polling is necessary because the DICOM protocol does not specify a mechanism to register for asynchronous notifications of events, such as the addition of new images.
Due to this architectural constraint, the DICOM crawler is expected to scale to manage sets of DICOM clients of size less than 100 clients. At higher loads, there is risk of unnecessary traffic clogging up the network as a result of querying all the DICOM clients, even when there are no real updates.