1.Proposed Work Item: Modification of APW to Better Support Digital Pathology

Brief Proposal Template

1.Proposed Work Item: Modification of APW to better support Digital Pathology

A. RAD-16 Retrieve ImageModification

B. Additional Workflow Considerations

▪Proposal Editor: Ph.D. Marcial Garcia Rojo / David de Mena Garcia

▪Editor:

▪Date: September 20, 2017

▪Version: 1.1

▪Domain: PathologyPALM

2.The Problem

The message used by the IHE Anatomic Pathology Technical Framework for the Retrieve Image is based in the IHE Radiology Technical Framework. It’s defined by RAD-16: Retrieve Image. This message is defined in RAD TF-1:2.4, specified in RAD-TF-2:4.16.

In the Technical Framework of Radiology it’s indicated inDICOM 2011 PS 3.4: Storage Services Class and DICOM 2011 PS 3.4 Query/Retrieve Service Class as a Referenced Standards, and also the DICOM 2011 PS 3.4, Annex C for the detailed descriptive semantics. The SOP for Study Root and Patient Root shall be supported as it’s indicated in the RAD-TF-2:4.16.4.1

As it’s noted, tThe Whole Slide Microscopic Image SOP Class defined in the DICOM Supplement 145 proposed proposes for storing WSI images for Pathology in DICOM to store theas individual “tiles” of a single WSI pyramid level. These tiles are represented as individual frames in a DICOM multi-frame image object. Although DICOM does not specify display application behavior, the Class provides sufficient information for an application to navigate through all frames of images in the series.

But the multi-frame retrieval is defined in DICOM in PS3.4 Annex Y, whisch is not the Referenced Standards for the RAD-16, and basically involves the normal C-MOVE or C-GET operations but with additional Frame Range Keys (DICOM in PS 3.4 Annex Y.32 and DICOM in PS 3.4 Annex Y.6).

So, it’s not possible, with the actual Anatomic Pathology Technical Framework , to retrieve only a single frame of a DICOM image (i.e. a single tile of one level of a WSI). but wThis requires profile implementors to receive e need to take the completed image (i.e. level), which is problematic due to the scope of data involved in a WSI and defeats the design goals inherent in the DICOM specification to allow implementors to efficiently management regions of interest at a specific layer.what makes very difficult, due the “weight” of the image, the management.

3. Key Use Case

When it’s needed to navigate in a Whole Slide Microscopy Image, we can found some pre-complicated slow resolution image called levels. Every level, as well the baseline image, are not composite comprised ofby a single image but for a quantity of tiles. Every level is stored as an image of a DICOM series image and every tile a frame in every image.

For a normal behavior review byof the pathologist, the image is viewed as whole and then it’smade zoom over the different levels, but only in a particular zonelimited region of interest. So it’s only needed to take the tiles of this concrete smaller scope need belevel and zone to shownwhat to the pathologist wants to see. As the image tends to be very large (over 1Gbhundreds of megabytes as average), requiring software implementations to retrieve more information that what is necessary will degrade system performance getting the whole image will considerably slow down the diagnosis process.

4. Standards and Systems

IHE PAD –TF-1

IHE RAD-TF-2:4.16

DICOM 2011 PS 3.4, Annex C

DICOM 2011 PS 3.4, Annex Y

DICOM Supplement 145

5. Discussion

We proposeto modify the RAD-16 with a PaLM-16, analogue to the actual RAD-16 but having the DICOM 2011 PS 3.4, Annex Yas referenced standards. So the C-MOVE will support multi-frame retrieve. We also suggest adding a Whole Slade Microscopy Image Profile section, analogue to the other Profile section, to specify the SOP that the agent shall support.