Presentation of Processed Images - Brief Proposal

1. Proposed Workitem: Presentation of Processed Images Profile

• Proposal Editor: Michael Planchart
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiology

2. The Problem

Summary and Background

Novel and advanced products based on sophisticated algorithmic software for pattern recognition and which leverage artificial intelligence are currently being produced by several hi-tech companies.

These products generally obtain images produced by acquisition modalities (e.g. CR, DR, CT, MRI) manufactured by various vendors (e.g. Agfa, Fuji, GE, McKesson, Philips, SIEMENS). The images obtained are then processed by the Algorithmic Server and one or more outputs are generated:

1. DICOM object with resulting processed image,
2. DICOM object with original image with Series 6000 overlay tags (in the case of CAD),
3. DICOM object with original image plus a Structured Report (in the case of CAD),
4. Pre-processed image for on-demand consumption, the final processing and conversion to DICOM would be performed upon request,

Most of the resulting DICOM objects could typically be stored in the PACS server.

Many healthcare organizations do NOT want to store the processed images contained in DICOM objects, and especially when they are of the CAD type, on their PACS citing various reasons (e.g. legal reasons, storage capacity, and technical limitations).

In some special cases, such as the one of Computer Aided Detection (CAD), alternate outputs may be produced (e.g. DICOM object with Series 6000 overlay tags, Structured Reports (SR)).

Almost all of the Algorithmic Servers are DICOM conformant devices. They have capabilities of receiving DICOM objects from the modalities and storing them at the PACS. They may also have the DICOM Q/R or WADO capability that allows the PACS viewing workstation to move the DICOM objects to its local storage. The Algorithmic Server could also provide response to DICOM C-Move and C-Get commands from the workstation.

There is also the possibility of these devices producing pre-processed state outputs that are later completed on demand.

Some outputs that the Algorithmic Server generates are in a pre-processed stage. The server keeps these objects stored locally until requested by an on-demand artifact that is installed on the PACS viewing workstation. This on-demand artifact can be an integral part of the workstation application or it can be external to it in the form of a specialized service.

1. What is the Integration Problem we are trying to solve?

Albeit we use many examples that refer to Chest x-ray images and CR/DR modalities, our problem belongs to a wider domain and to many other types of images and modalities as well.

PACS viewing workstations have been designed and developed to satisfy a limited number of use cases that are based on the different modalities from which they receive images. These new advanced image processing technologies being introduced were not anticipated several years ago. Now with the advancement of software and hardware they are being developed by many companies worldwide.

Albeit most PACS viewing workstations have capabilities of configuring hanging protocols to order the way the images display on the workstation they don’t have features to add new images in a harmonious way to the clinical workflow of the radiologist.

Simple Advanced Processed Image Problem

For example, in the case of Digital Chest X-rays of Lungs, introducing a new image in the physicians existing hanging protocol which is primarily configured to display the AP/PA and lateral side by side can cause undesired effects when adding a new processed image to the stack. In some cases when a series stacked behavior is expected, after the introduction of a new image it could cause an undesired “round-robin” behavior. In other cases the radiologist simply may not want an additional image to be displayed, but they would prefer to be notified of the image in some way and then invoke the presentation of it at will, as in the case of an on demand process.

Special Chest X-Ray Lung Cancer CAD Problem

Chest X-Ray Lung CAD devices process the digital images of AP and PA projections (frontal chest) obtained from the DR and/or CR modalities to detect nodules or abnormalities and to identify and mark the coordinates of the regions of interest (ROI). These modalities, after being properly configured, use the DICOM C-Store to transfer the images to the Lung CAD device.

The default workflow is that the images acquired by the aforementioned modalities are pushed directly to the PACS server and in parallel to the CAD device for processing and then they are automatically stored as processed DICOM objects at the PACS server using the DICOM 3.0 protocol.

The CAD processed output is delivered with one or more DICOM objects (e.g. DICOM objects containing images with burnt markers, or images with series 5000 and/or 6000 overlay tags, and/or Lung CAD Structured Reports) to the PACS server.

Most vendor image viewer workstations do not have a feature to display the CAD markers as overlays atop of the original images therefore the CAD device has to store a DICOM image at the PACS server.

The PACS image viewing workstations that do provide such a feature is done generally by means of toggling on/off the circles by using the mouse wheel, or another means of input, and by reading the series 5000 and/or 6000 overlay tags contained in the DICOM object stored at the PACS server and this latter case is considered the ideal one but unfortunately not many viewers provide this capability.

Many radiologists have expressed concerns about storing the DICOM objects with the CAD markers on the PACS server often claiming future legal liability concerns. Some PACS administrators mention that they don’t have enough space to store the additional images processed by the CAD device. For these reasons the CAD images would not be available on the PACS server for retrieval by the viewing workstation.

It is well known from the experience of Mammography CAD experiments with the existing Post Processing Workflow (PWF) profile that it doesn’t conform to an accepted solution. As stated in the Mammography CAD Workflow – Detailed Proposal the PWF profile has created the inconvenience of customers demanding of CAD vendors an inefficient and impractical solution.

Special (On Demand) Advanced Processed Chest X-Ray Problem

The advanced image processing device stores a pre-processed image that will be stored on the local persistent repository of the device. When the radiologist encounters a patient on his worklist the PACS viewing workstation should be able to alert him of the images stored on the devices. The radiologist would by means of some artifact request the image to be transferred to the workstation for review. The processing device would complete the image transformation and then convert it to a DICOM object which will later be transmitted to the PACS viewing workstation.

Creating a profile, or more likely several profiles, which would be implemented by the PACS vendors in their viewing workstations to enable the harmonious display of the post-processed images integrated with the radiologists’ workflow and hanging protocols. This would include simple processed images, simple and complex CAD outputs, and on demand request of pre-processed images which become post-processed images that are delivered to the workstation preferably leveraging the DICOM protocol.

After many discussions with PACS vendors this seems to be the most viable option for all parties involved.

3. Key Use Case

Use Case #1 –Simple Advanced Processed Image

Leveraging the DICOM 3.0 protocol the advanced image processing Algorithmic Server is connected to the CR/DR modalities, or any other type, and to the PACS server. The server receives the images from the modalities in parallel as the PACS server does. The server processes the image and later stores it at the PACS. The PACS viewing workstation retrieves the processed image and displays it along with the PA/AP image according to the Hanging Protocol which would most likely be in the same stack.

For many radiologists this use case is typical and well accepted. In other cases they want the image to not interfere with their accustomed hanging protocol and this is where the profile has to define a way for the PACS viewing workstation to under request of the radiologist to display the image. The Algorithmic Server could provide services to the PACS viewing workstation responding to the DICOM C-Move or C-Get commands.

Use Case #2 –Special (On Demand) Advanced Processed Images

Leveraging the DICOM 3.0 protocol the advanced image Algorithmic Server is connected to the CR/DR modalities, or any other type, and to the PACS server. The Algorithmic Server receives the images from the modalities in parallel as the PACS server does. The Algorithmic Server pre-processes the image and later stores it at a local persistent repository in a format that can be of any specific existing storage technology or a proprietary one.

The PACS viewing workstation, through an on demand artifact, requests the pre-processed image, the device completes the processing and converts it to a DICOM object, the PACS viewing workstation receives it and displays it along with the other images according to the Hanging Protocol.

For many radiologists this use case is typical and well accepted. In other cases they want the image to not interfere with their accustomed hanging protocol and this is where the profile has to define a way for the PACS viewing workstation, under an action performed by the radiologist to display the image(s).

Use Case #3 – Non-storage mode – CAD results are not stored in the PACS Server

The CAD subsystem of the Algorithmic Server receives the images directly from the modalities in parallel as the PACS server does. The CAD subsystem of the Algorithmic Server stores the processed images in a separate server that has the similar capabilities, but more limited, as a PACS server. This technique requires a client-side artifact that is aware of the patient being selected by the PACS image viewer and then queries and retrieves the DICOM image that contains the related CAD image.

4. Standards & Systems

Existing standards and mechanisms to consider include:

Existing IHE Profiles, DICOM, HL7

5. Discussion

Why IHE is the venue to solve the problem and what should IHE do to solve it?

IHE has proven to succesfully develop profiles that harmonize the DICOM and HL7 standards to solve many integration problems where vendors were using disparate approaches.

Currently vendors are using various techniques to integrate advanced processing images with their PACS viewing workstations. Each uses a different approach and are incompatible among each other.

A profile, or set of them, would help map an approach that could be adopted by all the vendors in the way they consume and display these images. IHE has the clout to do this.