Linking Whole-Slide Microscope Images with DICOM by Using JPEG2000 Interactive Protocol

We developed the JVSdicom software package to study the feasibility of linking JPEG2000 WSIs with a DICOM-based PACS by using JPIP. JVSdicom Compressor is used for creating DICOM-compatible JPEG2000 WSIs, which consist of the actual JPEG2000 image file and a supplementary DICOM file containing patient-related information. The supplementary DICOM file can be served using the JVSdicom Server, while the JPEG2000 image files are served using a separate JPIP server. Querying and retrieving images from the JVSdicom Server can be done using the JVSdicom Workstation, which handles conventional DICOM imagery directly but uses an external JPIP client application for JPEG2000 WSI viewing.

A complete, DICOM-compatible whole-slide imaging system can be constructed by combining JVSdicom with our previously described JPEG2000 viewing application (JVSview) and JPIP network serving application (JVSserv; Fig. 5). In this model system, a WSI scanner produces raw image data, which is processed by JVSdicom Compressor. JVSdicom Compressor produces a JPEG2000 file containing the actual WSI image data and a DICOM file containing the associated medical data (i.e., patient information) as well as some mandatory image properties, such as width and height. By default, the produced DICOM file contains anonymized DICOM entries, but it could be linked with a LIS or a HIS for retrieving patient information. A straightforward way to name the JPEG2000 WSI file is to use the microscope slide label identification string, which can be read automatically if bar-coded labels are used. The JPEG2000 WSI file is then moved into a JVSserv server, and the DICOM file is moved into a JVSdicom Server, which both are parts of the same PACS. Both files can be stored separately inside a server-specific storage area within the PACS. JVSdicom can also receive imagery from other imaging modalities, which are in turn linked with the LIS or HIS. End-users (e.g., pathologists or physicians) query the JVSdicom Server with a JVSdicom Workstation and retrieve patient-linked image objects. They can view and analyze conventional DICOM imagery within JVSdicom Workstation, while WSIs are opened with JVSview in another viewing window. The DICOM data is transmitted using the JPIP Referenced Transfer Syntax, and the JPEG2000 WSI data is transmitted via an auxiliary channel over JPIP. The system architecture makes it possible to use JVSserv separately outside the PACS, since WSIs do not contain any DICOM references.

An open issue with using JPEG2000 WSIs and JPIP is the image dimension restriction in the DICOM standard specification. Since image width and height tags are currently described using 16-bit values, oversized (width or height >65,535 pixels) WSIs will show false information with regards to these tags. However, since the definitive image width and height information are always also stored in the JPEG2000 code-stream header, the DICOM counterpart values can be bypassed. This requires the JPIP client software to use the code-stream values instead of the DICOM-specific values. The software described in this study follows this principle. In the future, if a DICOM Supplement equivalent to the CP 896 (to eliminate 16-bit image dimension restrictions) is introduced to the standard, the JPIP viewing software can also operate using the DICOM-specific image dimension tags. Current limitations for DICOM image object size due to 32-bit addressing (4 GB) do not affect JPEG2000 WSIs as long as they are stored in a separate JPIP server, such as the one described in this study. As such, the JPEG2000 standard does not limit individual file size and image dimensions, even in the largest future WSIs11,13.

The DICOM Working Group for pathology imaging (WG-26) is currently making an effort to consolidate pathology concepts and whole-slide imaging with DICOM34. WG-26 has recently finalized Supplement 122 (Specimen Module and Revised Pathology SOP Classes), introducing a new mechanism for pathology specimen identification in DICOM35. The new mechanism revises the concept of “specimen” within DICOM framework. Zwönitzer et al.36 have also proposed a similar approach. The scope of our study was to exemplify a DICOM WSI solution based on JPIP. Thus, the software described does not currently implement Supplement 122.

WG-26 has also recently started preparing a draft for a new DICOM Supplement for whole-slide imaging containing an IOD and SOP Classes for WSIs (as discussed in the WG-26 meetings)37. At its current state, the supplement utilizes a “pyramidal” approach in which the original resolution WSI is split into small image tiles (usually thousands of them). In addition, a number of successively lower resolution versions of the original tiles may be precomputed, creating a pyramid-shaped resolution structure. All the image tiles are stored as a conventional DICOM Series and accessed with the DICOM WSI object, which provides a mapping between the Series and the conceptual image pyramid. The pyramidal approach is similar to what various WSI scanner vendors have used in their web viewing solutions for several years. Prior to its finalization, the supplement draft is subject to changes.

Both approaches for whole-slide imaging in DICOM, the pyramidal and the JPIP-based, as described in this study, can be implemented with minor modifications to the existing standard specification. An advantage of the pyramidal approach is that WSIs are treated equal to other DICOM imagery residing within the same server. In the JPIP-based approach, an additional JPIP server must be set up within the PACS. However, a disadvantage of the pyramidal approach is that because WSIs are stored in a DICOM-specific data structure using lossy compression, as is required in virtual microscopy, relocating WSIs from the PACS (e.g., for teaching purposes) requires lossy recompression. This results in image quality degradation. In the JPIP-based approach, on the other hand, the JPEG2000 WSIs are not stored using a DICOM-specific data structure, making them directly interchangeable with non-DICOM systems. Moreover, since patient-related DICOM data is not embedded in the JPEG2000 WSI files, the same JPIP server can be readily used inside and outside of a PACS without the need for anonymization.

Since the DICOM standard specification already includes support for JPIP, the pyramidal approach and the JPIP-based approach for whole-slide imaging are not mutually exclusive and can be used simultaneously in the same PACS. Regardless of the approach, changes in existing PACS workstation software are also required because of the WSI-specific image viewing characteristics. At the time of preparation of this article, the detailed contents of the upcoming WG-26 WSI supplement, as well as its expected release date, are open. In the future, when the supplement is finalized and implemented in practice, comparisons between the two WSI approaches might turn out useful.