Digital Imaging and Communications in Medicine Whole Slide Imaging Connectathon at Digital Pathology Association Pathology Visions 2017

Abstract

As digital pathology systems for clinical diagnostic work applications become mainstream, interoperability between these systems from different vendors becomes critical. For the first time, multiple digital pathology vendors have publicly revealed the use of the digital imaging and communications in medicine (DICOM) standard file format and network protocol to communicate between separate whole slide acquisition, storage, and viewing components. Note the use of DICOM for clinical diagnostic applications is still to be validated in the United States. The successful demonstration shows that the DICOM standard is fundamentally sound, though many lessons were learned. These lessons will be incorporated as incremental improvements in the standard, provide more detailed profiles to constrain variation for specific use cases, and offer educational material for implementers. Future Connectathon events will expand the scope to include more devices and vendors, as well as more ambitious use cases including laboratory information system integration and annotation for image analysis, as well as more geographic diversity. Users should request DICOM features in all purchases and contracts. It is anticipated that the growth of DICOM-compliant manufacturers will likely also ease DICOM for pathology becoming a recognized standard and as such the regulatory pathway for digital pathology products.

INTRODUCTION

The use of digital pathology for diagnostic work has been rapidly expanding in regions without major regulatory obstacles.[1,2,3,4,5] The first clearance to market in the United States, although of a closed proprietary system,[6] will undoubtedly accelerate this pace. Like all technologic advancements, economies of scale and commoditization are inevitable, and for digital pathology to be scalable, components need to be standardized in terms of their functionality and their interfaces.[7] Interoperability will be a fundamental requirement. At the very least, for the referral of cases between sites with different systems, the ability to export to and import from a standard format using a standard protocol is essential.

More than three decades of experience with radiology and cardiology digital imaging systems have shown that they evolved from turnkey monolithic single vendor solutions to mature, off-the-shelf components that can be mixed and matched by the customer to produce best-of-breed solutions. Such advancement would not have been possible without the use of the digital imaging and communications in medicine (DICOM) standard.[8,9,10,11,12] Currently, the success of DICOM is being leveraged by other specialties, particularly the so-called “visible light” specialties such as ophthalmology, dermatology, surgical and gastrointestinal endoscopy, as well as generic medical photography.[13] This expansion is being fueled by the recognition that enterprise-wide solutions are required for affordability, scalability, robustness, reliability, security, privacy, and utility.[14]

Digital pathology has been late to the “enterprise imaging” party for a multitude of reasons.[15] Indeed, despite the publication of DICOM Supplement 145[16,17] in 2010, there has been a lack of motivation to implement it, and a lack of tools to support its use, as well as intellectual property barriers.[18,19] These hurdles have all recently been overcome, and the confluence of need and availability resulted in the feasibility of a public demonstration.

THE CONNECTATHON

DICOM working group (WG) 26 conducted a Digital Pathology Connectathon, hosted by the Digital Pathology Association at the 2017 Pathology Visions conference. Over the course of several days, three acquisition devices (Leica-Aperio, Philips, and Roche-Ventana), one picture archiving and communication system image server (Pathcore) and two viewers (Pathcore and AidPath) revealed the use of their systems to communicate DICOM whole slide images exported from the aforementioned scanners to a server, and thence interactively viewed, exclusively using the DICOM format and protocols. The traditional DICOM C-STORE was used for transmission of images from scanners to the server. The DICOMweb query (QIDO-RS) and retrieve (WADO-RS) transactions were used between viewers and the server to retrieve images and tile metadata and to selectively fetch only those tiles needed from the appropriate resolution layer for the interactive pan and zoom functionality of the virtual microscopy viewers.

The relatively seamless experience demonstrated to attendees belied the nontrivial effort that had gone on behind the scenes leading up to the event itself. Despite exhaustive planning over many months, up to the very last moment developers were tweaking and improving their code, output, and protocols to make sure that not only was interoperability revealed but also that different manufacturer's systems that appeared to be working together were working for the right reasons. Several alternative ways of implementing the standard were explored until a consensus of what viewers needed and what scanners could produce was achieved.

While this editorial is not the place to exhaustively discuss all technical details, it is worthwhile summarizing some of the major observations and agreements attained that are necessary to achieve interoperability in the real world in order for DICOM to be used for clinical applications in the future.

1. Image compression schemes used in DICOM need to be constrained. Initially, it was expected that support of the Joint Photographic Experts Group (JPEG) compressed tiles would be sufficient, but it became clear that JPEG 2000 support was also required to allow some scanners to participate. Both participating viewers achieved this

2. DICOM enables but does not explicitly require, a pyramid of multiple layers of different resolution to be encoded. It is legal to only store the highest resolution layer, with the expectation that recipients will be able to down-sample as required. This proved to be a barrier for the participating viewers, and hence, a third party tool was developed at the last minute to perform down-sampling images from one scanner

3. DICOM allows sparse representation of tiles, which means that the position (coordinates) of every tile on the glass slide needs to be described. The consequence of this for nonsparse representations (every tile imaged and stored, even if empty of tissue) is that the tiles can be encoded in any order since the position is explicitly defined. This position information is bulky and can be slow to transmit and interpret given that there may be hundreds of thousands of tiles. Viewers would like to assume not only a nonsparse representation but also a standard, predictable encoding order, to avoid the delay in sending and parsing the metadata. Further, scanner implementers needed to expend considerable effort getting the position coordinates correctly

4. Since some DICOM whole slide image (WSI) files can be quite large, a mechanism for sending them in pieces (of a so-called “concatenation”) exists. One scanner vendor had implemented this, but the archive did not support it. There is no consensus yet on whether or not the use of this feature should be promoted or discouraged

5. A required feature in DICOM is the presence of an International Color Consortium (ICC) profile[20] to facilitate consistent display of color on receiving systems. In other words, the colors displayed in all viewers of the same slide should appear the same, if the same calibrated monitors are used, or the viewers are shown side by side on the same monitor. The viewers used did not implement color management (i.e., ignored the ICC profiles), so color consistency was not achieved

6. There was a lack of consensus about what metadata should be provided in query responses, as opposed to what is left for metadata retrieval, beyond the minimum required by the DICOM standard and supported in nonWSI archives.

From the perspective of an implementer, the availability of existing DICOM toolkits to build appropriate DICOM WSI files and to store them over the network considerably reduced the development burden. This illustrates the value of building on an existing well-established standard. The incremental effort required was mostly centered on pathology and slide specific issues, such as the slide-specific metadata, encoding order and description of the tiles. On the viewer to server interface side, the use of modern DICOMweb services, which are Hypertext Transfer Protocol based rather than using a DICOM-specific network protocol, considerably simplified the implementation. The QIDO-RS and WADO-RS services are simple Uniform Resource Locator requests and allow access to metadata in eXtensible Markup Language or JavaScript Object Notation formats and direct access to the compressed tile pixel data payload as ordinary JPEG or JPEG 2000 files.[21,22,23]

After the demonstration was completed, a panel with representatives of the participants was held, that was well-attended and stimulated pertinent questions and a lively discussion [Figure 1]. A regulatory panel discussion followed at which industry and regulator representatives frankly considered the issues of opening up closed architectures by using components with standard DICOM interfaces.

Figure 1.

Dan Hosseinzadeh, co-chair of the digital imaging and communications in medicine pathology working group, presenting at the 2017 pathology visions conference

FINAL THOUGHTS

Even skeptical attendees seemed pleasantly surprised by the performance and quality achieved, which is designed to be comparable to the experience of using a proprietary viewer. Many vendors that were unable to participate in the first Connectathon have expressed interest in joining for the next one. That said, the lessons learned need to be incorporated into updates to the DICOM Standard, more detailed description of the requirements is warranted for participation in future Connectathon events (probably in the form of “profiles” for specific use cases), as well educational material. Work is already in progress within WG 26 to optimize the performance of nonsparse tiles encoded in a standard order.[24]

How should users interpret the success of the Connectathon, and how should it influence their purchasing decisions? Clearly, we have been able to demonstrate that the use of DICOM as a standard interface is feasible. However, that does not mean that a commercial product purchased today will be able to use DICOM in a high volume production setting. There is a practical difference in each product between exporting single slides as DICOM, as opposed to routinely transmitting every slide as DICOM. Only clearly articulated customer demand will motivate the vendors to invest effort in this area.

Further, such production workflows require the provision of reliable metadata for identification and description of the slides, automation of which requires as yet undefined choices of interface standards.[25] This will be the next technical improvement to be a focus of future Connectathon events. Ongoing interactions with the appropriate Integrating the Healthcare Enterprise Pathology and Laboratory Medicine group are also necessary to address workflow issues. In the interim, it is recommended that customers include the appropriate language in their request for proposals and eventually contracts to motivate mutual investment efforts in this area even if a vendor cannot offer practical DICOM connectivity immediately.

A demonstration of the technical feasibility of interoperability does not resolve regulatory issues regarding safety and efficacy for generic diagnostic applications, particularly in the United States (US),[26,27] and presumably the European Union (EU) with the new In vitro diagnostic regulations[28] and medical device regulations.[29] It remains to be seen how the US Food and Drug Administration and the EU will regulate interoperating components rather than monolithic systems.

A common question was whether or not there exists a standard format for annotations, whether this can be employed for user annotation as part of the medical record, and if the user identified hot spots can be communicated to analysis tools, or the encoding, visualization and archiving of the output of analysis tools. DICOM does provide various generic solutions for annotations, including segmentations, presentation states and structured reports, which are used in other specialties where quantitation is a requirement.[30] Which choices, for which use cases, and how scalable the existing DICOM solutions will be for very large numbers of annotations, remains to be seen. If necessary, DICOM can add WSI-specific annotation features. This is expected to be the second priority for the expansion of future Connectathon functionality, especially when there is greater participation by analysis tool implementers. For now, analysis tools may at least benefit from the use of a standard DICOM input format for the images from all scanner vendors. Upcoming Connectathon events will also likely require color management to be implemented in viewers.

CONCLUSION

It is fair to say that digital pathology is here to stay, that DICOM for digital pathology is also here, and that given that the industry players are committed, the path forward is clear and unambiguous. It remains for pathologists and their support teams to come to terms with both the short- and long-term ramifications of digital pathology deployment and the vital need to demand standards-based interoperability from the very start.

Resources

The images that were produced for and during the Connectathon are available to be downloaded from “ftp://medical.nema.org/medical/dicom/datasets/WG26/WG26Demo2017/”. Note that as described in the documentation, there are various deficiencies in the DICOM encoding of some files, which will be addressed for future events.

Financial support and sponsorship

Nil.

Conflicts of interest

There are no conflicts of interest.