Report on the 2025 DICOM WSI Connectathon

Abstract

Implementation of a standard such as Digital Imaging and Communications in Medicine (DICOM) is key to all aspects of interoperability in whole-slide imaging. But the devil is in the details, so practical testing and demonstration of specific features are needed to show the path forward for practical clinical deployment, select the appropriate profile of features, and identify gaps and opportunities for improvement. The most recent Connectathon was conducted for this purpose, as a virtual Internet-mediated event. Thirty-two (32) implementers in the role of Acquisition Manager (AP-LIS) (2), Acquisition Modality (scanner) (9), Image Manager/Archive (PACS, IMS, or VNA) (7), Image Display (viewer) (15), and Evidence Creator (annotation source) (8) participated. The AP-LIS provided HL7 V2 metadata identifying and describing patients and specimens in response to a slide barcode-based query, which was then incorporated by the scanner into standard DICOM whole-slide microscopy images, which were encoded as tiled pyramids using the TILED_FULL pattern. These images were transferred to the archive using the standard DICOM protocol, and made available for virtual microscopy viewing using the standard DICOMweb mechanisms for query and retrieval of metadata and selected frames. Human and algorithm generated annotations were produced and stored in the standard DICOM annotation format, and transferred and retrieved for display, also using the standard DICOMweb mechanisms.

Background

After a slow start,¹ digitization of tissue-containing microscope slides, for the purpose of primary diagnosis by pathologists in routine practice, using an electronic display rather than a conventional microscope, is growing in popularity.² Early clinical devices for whole-slide imaging (WSI) released to the market³ have followed the precedent established by research-only devices, which utilized proprietary file formats for the storage and exchange of the digital images.⁴ Such a proliferation of incompatible proprietary formats potentially threatens interoperability.⁵ Academic and commercial research applications can also benefit from standardization, particularly if commonly used libraries support standards.

Interoperability can be difficult to define in a meaningful manner that is not overly simplistic. It includes not only the interchange of information but also the ability to make use of it.⁶ Interoperability in healthcare information technology (IT) has been described as having technical, syntactic, semantic, and organizational aspects.⁷ For the purposes of this report, we consider as being addressed:

• •technical interoperability of basic data exchange, by standard communication protocols, such as Digital Imaging and Communications in Medicine (DICOM) protocols for the transport of and access to, images and associated information;
• •syntactic interoperability, by the standard DICOM file format and encoding, including standard compression schemes used in DICOM (such as Joint Photographic Experts Group (JPEG)), as well as standard metadata APIs and resource representation for DICOMweb services;
• •semantic interoperability, at two levels: by the standard DICOM Information Object Definitions (IODs), such as the Whole-Slide Microscopy Image IOD⁸ and the Microscopy Bulk Simple Annotations IOD,⁹ and by the use of standard codes to describe specimens (such as the Systemized Nomenclature of Medicine - Clinical Terms (SNOMED CT) codes used for specimen preparation in DICOM attributes¹⁰);
• •organizational interoperability, by the use of DICOM persistent objects that are self-describing (contain sufficient internal identifying and descriptive metadata¹¹), such that they can be exchanged using standard protocols with other sites within the same organization, between organizations (such as for referrals and consultations), and with external third-party service providers of storage (such as cloud-based archives) and applications (such as of computational pathology (CP) artificial intelligence (AI) services).

The DICOM WSI Connectathons are intended to explore and evaluate the suitability of various generic and WSI-specific features of the DICOM Standard to thoroughly address all four of these aspects of interoperability. Though regulatory agencies, such as the US Food and Drug Administration (FDA), have not yet defined a process for separation of components of the end-to-end pixel pathway,¹² as a matter of policy, they do recognize the importance of interoperability and the role of the DICOM standard for that purpose.13, 14

Achieving real-world interoperability requires more than just a nebulous statement of intent to conform to a standard. The specific features of the standard to be used need to be defined for specific use cases. Those features need to be tested and demonstrated to work. Traditionally, the venue for both “profiling” the standards required, and providing evidence of successful implementation, has been a “Connectathon”. The current Integrating the Healthcare Enterprise (IHE) definition is “an event that is centered on an open consensus-built interoperability … specification”.¹⁵ Connectathons have a history for interoperability testing that long pre-dates their use for healthcare IT.16, 17

Though the DICOM standard was first extended to support WSI18, 19 in 2010, implementation was slow²⁰: the first Connectathon to demonstrate its utility was not conducted until 2017.²¹ That first event proved particularly critical. It not only added some momentum for the participants but it also allowed them to interact in a pre-competitive manner, and served as an opportunity to explore some potential optimizations of the standard, before it became more widely implemented. The most crucial of the lessons learned, that led to additions to the standard, was the so-called “tiled full” mechanism.²² This allowed omission of the verbose description of the location of every tile, and established an implicit order and location of the tiles for suitable use cases. Subsequent DICOM Working Group 26 Connectathon events23, 24 allowed more implementers to participate, provided a forum for confirming the feasibility of other improvements, and also tested other features, such as annotations.

By 2025, the feasibility of DICOM as a WSI file format, the DICOM protocol for storage of the images from the scanner to the archive, and the efficacy of the DICOMweb protocol for virtual microscopy viewing of DICOM images in the archive²⁵ had been well-established. However, beyond using DICOM as merely “yet another file format”, to encode the tile pixel data and a minimal set of structural information (so-called “naked” DICOM²⁶), in a practical clinical deployment there is also a need to:

• 1.Provide additional metadata to identify and describe the patient, the case, and the specimen, including detailed specimen preparation information.²⁷
• 2.Link to a reliable source of such metadata such that it can be obtained and incorporated in the image attributes.
• 3.Provide a means to describe annotations made on images, whether they be created by humans or algorithms (such as AI-based CP).

This necessary additional information, and the means of communication using standard protocols and formats, had already been defined. Specifically:

• •The IHE Digital Pathology Workflow – Image Acquisition (DPIA)²⁸ describes the Health Level Seven (HL7) V2 messages between an Anatomic Pathology Laboratory Information System (AP-LIS) (acting as an Acquisition Manager), and a WSI slide scanner acting as an (Acquisition Modality), containing the identifying and descriptive slide acquisition metadata.
• •The DICOM Microscopy Bulk Simple Annotations IOD⁹ defines a means of communicating vector graphic annotations, potentially in extremely large numbers, in an efficient manner, but still leveraging the basic DICOM information structure.

Accordingly, given the growing interest in using DICOM WSI for routine clinical deployments, the intense interest in annotations for both training and using WSI for CP AI, and the potential interest of some LIS vendors to provide metadata, these features were addressed in the 2025 DICOM WSI Connectathon. This report will summarize the design and conduct of the event, as well as describe the results of the experience.

Methods

The Connectathon was conducted virtually (over the Internet with no face-to-face on-premise component) during the Spring (Northern Hemisphere) over a 4-month period. There was no cost to participate. Project management was supported by the Digital Pathology Association (DPA),²⁹ and travel to the European Congress of Digital Pathology (ECDP) for the coordinator was supported by the European Society of Digital and Integrative Pathology (ESDIP).³⁰

A Connectathon consists of participants who provide hardware and software that serves in the role of actors, and which communicate with their peers by means of transactions. The actors may correspond directly to a single system that a customer might purchase and install, or represent only part of such a system, or combine multiple parts. Regardless, the actor is defined to have a particular functionality that is appropriate for the use case. Transactions are defined by selecting and potentially specializing existing standard transactions provided by HL7 and DICOM standards. In our case, we used the IHE DPIA Profile²⁸ as the basis for defining actors and transactions, but extended and specialized its current version in a number of ways to address our specific use cases.³¹

For the purpose of our Connectathon, the following actors were defined:

• •Acquisition Manager—i.e., AP-LIS to provide identifying and descriptive metadata.
• •Acquisition Modality—i.e., the slide scanner.
• •Image Manager/Archive—i.e., the Picture Archiving and Communications System (PACS) or Image Management System (IMS).
• •Image Display—i.e., the viewer (of WSI and annotations).
• •Evidence Creator—i.e., the creator of annotations (human- or machine-generated).

For the transactions, only DICOM format images and annotations were selected, both traditional DICOM Message Service Element (DIMSE) and http-based DICOMweb transactions were permitted. The HL7 V2 messages specified by DPIA were transmitted by Minimum Lower Layer Protocol (MLLP). The DPIA definitions of the HL7 messages were supplemented by a well-defined HL7 message field to DICOM attribute mapping.³² This mapping included patient, specimen and slide identification and description information, including but not limited to appropriate coded entries for each of fixation, embedding, and staining (e.g., to cover formalin-fixed paraffin-embedded (FFPE) hematoxylin and eosin (HE) aspects of specimen preparation.

The overall outline of the Connectathon actors and transactions is illustrated in Fig. 1.

Fig. 1.

Overall outline of the Connectathon actors and transactions.

After consultation with the Acquisition Modality participants, it was determined that the only query-based transactions (LAB-81 initiated) would be supported, with information returned in LAB-80 transactions, but without any expectation that scanners would cache broadcast LAB-80 transmissions for unsolicited messages.

For the simplicity of testing, because no individually identifiable information was to be exchanged, all connections were expected to be unencrypted (plain text) and without authentication mechanisms. In a real-world deployment, secure connections would be required beyond the confines of an organization (if not within) as a matter of good security practice. Secure DICOMweb connections were not prohibited. Participants that were receiving connections were permitted to restrict them, for example, based on such parameters as Internet Protocol (IP) address.

Overall, the goal of the methodology was to establish, for each set of transactions between actors, does it work, and is it compliant? Though emphasis was placed on implementing the standard correctly, no exhaustive programmatic testing of compliance with all the required supported features was planned, however, beyond automated validation of persistent DICOM objects. Participants were expected to document their capabilities in a standard DICOM Conformance Statement,³³ which was shared with other participants. No formal review of Conformance Statement completeness and veracity, or compliance with the standard template, was planned.

The performance of individual peer-to-peer tests was tracked at the aggregate level, and was an iterative process over the duration of the event. In other words, only ultimate success or failure was recorded for each type of transaction between two actors, regardless of how many attempts were made, or how many examples of each transaction was executed.

Acquisition Manager (AP-LIS) requirements

Acquisition Manager actors were required to support the IHE PaLM Digital Pathology Image Acquisition (DPIA) profile described in the DPIA TI Revision 1.3 document²⁸ in the Acquisition Manager Role using the specified transactions. They had to respond to an Imaging Work Order Step Query [LAB-81] HL7 V2 message for a single specimen identified by the QPD-3 Glass Slide Identifier, initiated by an Acquisition Modality (scanner). They were to then respond with an Imaging Work Order Step Broadcast [LAB-80] HL7 V2 message for the matched specimen (only). They were required to include the specific messages, segments, and fields that were defined in the mapping document.³² The LAB-81 query would be received on a connection opened by the Acquisition Modality. The LAB-80 response was to be returned by the Acquisition Manager on a new connection opened to the pre-configured Acquisition Modality identified by the MSH-3 Sending Application in the LAB-81 query request, and NOT on the same connection as the LAB-81 query. This pattern of connection establishment was confirmed by HL7 specialists to be appropriate for the message types used.

In order to support the Connectathon activities, the Acquisition Manager participants needed to pre-populate their database with sufficient information to support matching with the slides used by the Acquisition Modalities that were to be scanned during the testing; this communication was coordinated by the project manager using a shared spreadsheet.

Successful participation was defined as ingestion of the tabulated metadata pre-supplied by Acquisition Modality participants, response to LAB-81 queries with a sufficient LAB-80 response matching the supplied identifier.

Acquisition Modality (slide scanner) requirements

Because it was the intent of the Connectathon to explore various use cases, three modes of operation of the Acquisition Modality actors were recognized, in order to maximize the number of tests between peers that could be performed, even if a complete implementation of all transactions was not supported:

• 1.An Acquisition Modality could implement the transactions with the Acquisition Manager, as specified (“DPIA” mode).
• 2.An Acquisition Modality could operate in a so-called “no LIS” mode, without a connection to an Acquisition Manager, and either omit, or include from out-of-band sources, identifying or descriptive metadata.
• 3.An Acquisition Modality could leverage the services of a third-party Metadata Enrichment tool, produce “naked” DICOM files without the required metadata, and have the third-party middleware perform the transactions with the Acquisition Manager and the Image manager/Archive on its behalf, the end result being as if the combination was operating in the “DPIA” mode.

Fig. 2 illustrates the use of the Metadata Enrichment tool.

Fig. 2.

Use of the metadata enrichment tool.

To distinguish images produced by scanners in the various modes, in addition to a convention of including the scanner participant's organization name in the PatientName DICOM attribute value, they were also requested to specify the mode as “DPIA” or “NOLIS”.

Acquisition Modalities (or the Metadata Enrichment tool) operating in the DPIA mode were required to send an Imaging Work Order Step Query [LAB-81] transaction (MLLP HL7 V2 message) to the (pre-configured, if more than one participant) Acquisition Manager, using the identifier extracted from the barcode in the scanned slide label image as the QPD-3 Glass Slide Identifier, and use the information in the Imaging Work Order Step Query [LAB-81] response HL7 V2 message to populate the DICOM metadata as defined in the mapping document.³² The same pattern of connection establishment that has been described for the Acquisition Manager was required to be used; in particular, there was a need for the Acquisition Modality to accept a separate inbound connection from the Acquisition Manager to receive the LAB-81 reply to the query request.

Acquisition Modalities were expected to then generate DICOM VL Whole-Slide Microscopy Image Storage objects that were fully compliant with the IOD in the current standard,⁸ with the following additional restrictions and requirements:

• •Only one DICOM series of WS images was to be created per slide acquisition; i.e., images from different slides (or the same slide scanned multiple times) were not to be mixed in the same Series; this meant that each scan action would generate a new set of UIDs, including a new SeriesInstanceUID.
• •An image with the slide label visible in the pixel data was to be included; this could be an image of the label only, or an overview image of the entire slide including the label; the information in this image was to be sufficient to extract a query key for the HL7 request to the Acquisition Manager, as stored in DICOM BarcodeValue.
• •As the DPIA profile requires, the DIMSE C-STORE operation was to be used to transmit the images to the Image manager/Archive actor; optionally the DICOMweb STOW-RS could also be tested.
• •Optionally, DIMSE Storage Commitment transactions could be used, to confirm archival before local deletion, but were not required (unlike in the IHE DPIA profile, which requires them in conjunction with external storage); DICOMweb Storage Commitment was not tested.
• •
  Only true color brightfield images were to be sent, and further:

  • o
    As the DICOM standard requires, the PhotometricInterpretation needed to be appropriate to the compression method used, which is typically RGB (if there has been no color component transformation, which there is not required to be), YBR_FULL_422 (for baseline JPEG) or YBR_ICT (for JPEG 2000).
  • o
    Only lossy compressed images were to be sent for the high-resolution and intermediate resolution layers of the pyramid: only baseline JPEG, and JPEG 2000 transfer syntaxes were to be used; the top layer, label and overview images could be sent uncompressed.
  • o
    Optionally, participants could agree to experiment with JPEG XL transfer syntaxes.
• •
  A multi-resolution pyramid was required to be sent.

  • o
    This was not required to be decimated by a factor of 2, nor even by a regular factor, but multiple layers were expected (typically 3–5 depending on the area of the tissue scanned but more were permitted).
• •
  Only DimensionOrganizationType TILED_FULL³⁴ images were to be sent.

  • o
    I.e., no sparse images; a full raster scan of all tiles in the whole-slide regions was to be sent with the tiles in the standard pre-defined order, and the PerFrameFunctionalGroupsSequence was not be to be present.
• •
  Only single Z-plane images were to be sent.

  • o
    Optionally, participants could arrange with peers to send multiple Z-plane images, as long as they could be clearly distinguished in the archives from the single plane images, because they were not expected to be viewable by all consumers.
• •
  Concatenations were not to be used.

  • o
    I.e., each pyramid layer was to be entirely in a single SOP instance, and not chunked; no Concatenation reassembly was to be expected of the archive or viewer.
• •An ICC Profile was to be present in the single OpticalPathSequence Item (as required by the standard), and when applied by the Image Manager/Archive or the Image Display, could be expected to produce the appearance intended by the scanner manufacturer.
• •The WholeSlideMicroscopyImageFrameTypeSequence was to be present in the SharedFunctionalGroupsSequence.
• •
  The specimen preparation details appropriate to the specific labelled slide was required to be present:

  • o
    The SpecimenPreparationSequence was not allowed to be empty, and was required to contain sufficient coded content entries to describe the fixation, embedding and staining; the expected content was described in the mapping document.³²
  • o
    The source of the data was to be either the AP-LIS, or out-of-band in a pre-configured table as described earlier.

The Acquisition Modality participants were to submit scanned DICOM images of slides to all configured Image Manager/Archives for retrieval, rendering and annotation by other registered participants. In addition, the stored scanned images would be validated by the project manager for compliance with the standard IOD and the expected Connectathon-specific attributes using dciodvfy,³⁵ which was modified to include a WG26SP2025 specific profile invoked by a command line option. During the event, as feedback was received from other participants and validation results, Acquisition Modality participants were to provide corrected updated or replacement images, coordinate removal of prior incorrect images with the project manager and Image Manager/Archive participants, and notify peers about with a brief description of the changes incorporated and the issues resolved, by e-mail and using a Google Group established for Connectathon-related communications.

Successful participation in the NO-LIS mode consisted of sending a compliant set of images for each scanned slide with C-STORE or STOW-RS requests, ±sending a Storage Commitment request. In the DPIA mode, actors were evaluated on additionally querying for metadata with a LAB-81 request, accepting a connection for the LAB-80 response, matching the LAB-80 response to the slide identifier and then including the corresponding information in the DICOM image metadata in a compliant manner.

Image Manager/Archive requirements

In order to support receipt of images and annotations from other actors, Image Manager/Archive actors were required to support DIMSE C-STORE operations for the following SOP Classes from the specified actors:

• •VL Whole-Slide Microscopy Image Storage (from Acquisition Modalities);
• •Microscopy Bulk Simple Annotations Storage (from Evidence Creators);

for the following lossy compressed Transfer Syntaxes:

• •JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression.
• •JPEG 2000 Image Compression.

Optionally, participants could agree to experiment with other transfer syntaxes (e.g., JPEG XL).

If an Image Manager/Archive did not support DIMSE C-STORE operations, but did support DICOMweb STOW-RS for the required SOP Classes, then a third party C-STORE to STOW bridge could be used, such as the open source Google healthcare-dicom-web-adapter,³⁶ but it would be the Image Manager/Archive participant's responsibility to deploy/implement such an adapter if needed. This is illustrated in Fig. 3.

Fig. 3.

Use of C-STORE STOW bridge.

In order to support viewing of images and annotations by Image Display and Evidence Creator actors, Image Manager/Archive actors were required to support query and retrieval by DICOMweb http-based transactions, consistent with the transactions required by DPIA,²⁸ but with additional constraints. Specifically:

• •
  For the Study Retrieve Transaction (WADO-RS):

  • o
    Both the Retrieve Pixel Data and Retrieve Rendered resources were to be supported to allow for frame level retrieval of the original compressed encoded pixel data as stored on the server or regardless of the form (transfer syntax) of the original encoded pixel data.
  • o
    image/jpeg, and image/jp2 (pixeldata) and image/png (rendered) media types were to be supported.
• •
  For the Study Search Transaction (QIDO-RS):

  • o
    All resources required by the standard³⁷ for a native implementation were to be supported, including all and specified study, series, and instance resources
  • o
    All query keys required by the standard³⁸ for the appropriate resource were be supported.

Also highlighted in the technical requirements document³¹ were various common errors or ambiguities in the standard that have been resolved, such as misuse of the application/octet-stream media type for compressed pixel data, use of the appropriate single part or multi-part responses, support of the “*/*” Accept header, correct encoding of retrieved metadata without File Meta Information (group 0002) data elements, and support of the Bulkdata URI mechanism to de-reference large binary blobs in the metadata, such as for ICCProfile. The need to support Cross-Origin Resources Sharing (CORS)³⁹ headers was emphasized, and required for GET, POST, and OPTIONS operations.

DIMSE query and retrieval support was not required or tested.

Optionally, DIMSE Storage Commitment transactions could be supported, but were not required (unlike in the IHE DPIA profile, which requires them).

The Image Manager/Archive participants were required to make their configuration information for their Internet-accessible DIMSE and DICOMweb endpoints, and the project manager coordinated the sharing of this information. The Internet-accessible endpoints needed to remain accessible for the duration of the testing. There was no requirement for these end-points to be public. There was also no requirement that a single endpoint be used for different DICOMweb features (e.g., query and retrieval).

Image Manager/Archive actors were evaluated on successfully receiving images and annotations with C-STORE or STOW-RS, responding to Storage Commitment requests, and responding to queries and retrieval requests for images and annotations.

If an Image Manager/Archive supported the inbound storage transactions but did not support DICOMweb query and retrieval, the participant was still evaluated, but would be flagged as only partially successful (“Hotel California Effect”).⁴⁰

Image Display (Viewer) requirements

The term “display” here is used in the sense of image viewing software only, and does not mean the physical hardware monitor to render the images from the viewer. The Connectathon was performed virtually, and there was no physical access to monitors (color-calibrated or otherwise) provided to peer participants or the project manager. Nor was there a requirement for remote access to a virtualized viewing environment.

It was not the intent of the Connectathon to explore the quality of the user experience, but rather to assure the interoperability of the encoding mechanism, sufficient to support the following features.

As specified in the IHE DPIA profile, Image Display actors were expected to use:

• •the DICOMweb Study Search Transaction (QIDO-RS) to search Image Manager/Archive systems for images (and optionally, annotation) objects;
• •the Study Retrieve Transaction (WADO-RS) to retrieve images and metadata from Image Manager/Archive systems.

In particular, the Retrieve Metadata resources could be used to retrieve any necessary metadata beyond what was available from the query transaction, and frame pixel data could be retrieved in either original form using Retrieve Pixel Data resources or rendered form using Retrieve Rendered resources.

Image Displays were required to provide the usual “virtual microscopy” viewing experience⁴¹ to the user, including but not limited to the ability to zoom in and out, and pan.

Additionally, the viewer was required to at least display the following DICOM image metadata, if present, whether in coded entries or plain text strings (or both):

• •Patient identifiers and description.
• •Specimen identifiers and description (including anatomy, fixation, embedding and staining.
• •Slide identifiers and description.

The ICC Profile present in the DICOM images was expected to be applied, in order to have the viewer render the image in the manner that the scanner vendor intended. Specifically, the ICC Profile could be applied client side, by retrieving the ICCProfile attribute value from the metadata (using BulkDataURI, if necessary), and then use it in the color rendering pipeline applied to the original pixel data. Or, in the case of rendered pixel data, by specifying the appropriate iccprofile query parameter, the origin server could be instructed to either return the profile in the compressed pixel data stream, or to apply implement color rendering on the server side and return a rendered image in one of the specified standard color spaces. Optionally, the viewer could also provide the user with control over whether the ICC Profile is applied or not (e.g., to demonstrate its effect).

Optionally, if annotations were to be supported, Image Displays were expected to be able to support query, retrieval, and rendering of Annotations on the referenced Image, and to:

• •Indicate the presence of annotations at any level of zoom selected by the user, even though they might not be fully rendered (e.g., as an outline) except at or close to the layer on which they are specified (e.g., for large numbers of annotations on a high-resolution layer, when zoomed out, some form of heat map or clustering could be used).
• •Use outlines or shading or a combination of both, with or without some means of user control over the choice.
• •Support multiple Annotation objects and multiple Annotation groups in a single object that are associated with one image, and allow the user to select and render any of the Annotation objects, whether simultaneously or separately.
• •Support all GraphicType values specified in the standard.

The Image Display participants were expected to monitor the availability of images +/‐ annotations available in the various Image Manager/Archives from the various Acquisition Modalities +/‐ Evidence Creators, and to record the result of successful or unsuccessful display in a collaborative spreadsheet provided by the project manager.

Image Display participants were required to self-certify that queried for and retrieve images +/‐ annotations from Image Manager/Archives, and displayed them in the expected manner, with only minor, if any, issues. As mentioned earlier, there was no third-party verification of this request, though participants were encouraged to send screenshots of successful display events. Viewers were expected to test with images and annotations from multiple Acquisition Modalities and Evidence Creators, stored on multiple Image Manager/Archives.

Evidence creator requirements

The term “evidence creator” is inherited from other IHE technical frameworks (especially radiology) though it is not formally defined, but means an actor that creates additional information related to acquired images. In the context of this Connectathon, we use the term to apply to an actor that creates annotations on WSI, whether the source of those annotations is a human operation or the output of an algorithm, or some semi-automated combination of the two.

Though DICOM defines various different IODs for recording annotations, some of which are general purpose and some of which are specific to an application, some of which record rasterized bit planes or label maps rather than vector graphic outlines, for the purposes of WSI, one particularly important IOD is the Microscopy Bulk Simple Annotations IOD.⁹ It is designed to support very large numbers of graphic annotations such as may be produced by an algorithm operating on a relatively high-resolution layer of a WSI. This does not prevent it also being used for human-generated annotations, which are typically fewer in number per slide. An Evidence Creator may operate independently, and query for and retrieve images, process them and store its results as DICOM ANN objects to the Image Manager/Archive. Or, it may be grouped with an Image Display actor, allowing for interactive annotation while the images being annotated are displayed.

For the purposes of the Connectathon, the only specific requirements were to create one or more DICOM Annotation objects per slide that were:

• •encoded using the Microscopy Bulk Simple Annotations IOD⁹;
• •used only 2D (referenced image relative) coordinates (rather than 3D physical offsets in slide-relative frame of reference);
• •was of any one of the permitted GraphicType values;
• •could contain multiple annotation groups.

The preferred method to submit the Annotation objects was using the DIMSE C-STORE or DICOMweb STOW-RS protocol.

Optionally, DIMSE Storage Commitment transactions could be supported, but were not required.

Logistically, Evidence Creator submissions were managed, communicated, and validated in a similar manner to the images produced by Acquisition Modalities.

Evidence Creators were evaluated on their ability to create compliant annotations and send them to the Image Manager/Archives successfully with C-STORE or STOW-RS, +/‐ Storage Commitment. Annotations could be made on images supplied to the Image Manager/Archives by Acquisition Modalities during this Connectathon, on images from previous events that had been pre-populated in the Image Manager/Archives, or in the case that the annotations were results of highly specific algorithms that applied only to particular types of images, on their own DICOM WSI images. In addition, the stored annotations would be validated by the project manager for compliance with the standard IOD using dciodvfy.³⁵

Results

Only successful results are reported, not failures or lack of attempts, for whatever reason. More groups initially registered than actually participated. The following table outlines the overall results:

Actor	Registered	Participated	Successful
Acquisition Manager	3	2	2 (100%)
Acquisition Modality	11	9	9 (100%) / 7 (78%)a
Image Manager/Archive	11	7	7 (100%)
Image Display	20	15	15 (100%) / 12 (80%) / 11 (73%)b
Evidence Creator	19	8	8 (100%) / 7 (87%)c

^aNine Acquisition Modalities sent images to Image Managers/Archives, of which seven were fully DICOM compliant or contained only minor errors.

^bRetrieved from 15 Image Managers/Archives, 12 reported displaying images from various Acquisition Modalities, 11 reported displaying annotations from various Evidence Creators.

^cEight Evidence Creators sent annotations to Image Managers/Archives, of which seven were fully DICOM compliant or contained only minor errors.

A complete list of participants, and the actor role in which they participated, follows:

Participant	Acquisition Manager	Acquisition Modality	Image Manager/Archive	Image Display	Evidence Creator
3DHISTECH		✔
Agfa			✔
AixMed					✔
AstraZeneca				✔
BMD			✔	✔
caMicroscope				✔
Gestalt				✔	✔
Google			✔
Grundium		✔
Hamamatsu		✔
Hologic		✔			✔
Huron		✔
IDC				✔
Identify.bio					✔
Infinitt			✔	✔
J4Care			✔	✔
Leica		✔
Meditecs	✔
MGB				✔
NCKU-ALOVAS				✔	✔
NTUNHS				✔	✔
PathQA		✔
Philips				✔
Pramana		✔
Proscia			✔
Radical Imaging				✔
SCC	✔
Siemens			✔
Song Yi System		✔
Techcyte				✔	✔
Visiopharm				✔	✔
Voicebrook				✔
Total - 32	2	9	7	15	8

Acquisition Manager results

Successful DPIA LAB-80 and LAB-81 transactions were achieved by the two (100%) participating Acquisition Manager actors as described in the following table:

Acquisition Manager ->\/ Acquisition Modality	Meditecs	SCC
3DHISTECH	✔
Hamamatsu	✔	✔
Hologic	✔	∼b
Leica	✔	✔
Pramanaa	✔	✔
Song Yi System	∼c	✔
Total	5 + 1 partial	4 + 1 partial

^aUsing the CitiusTech metadata enrichment tool.

^bSome issues were observed by SCC parsing some message segments and not all barcode values were available.

^cSome difficulties were observed with proving IP addressed access for the scanner inbound connection.

Acquisition Modality results

Overall, there were 9 (100%) successful Acquisition Modality participants, as summarized in the following table that summarizes successful transactions and whether or not the stored images were compliant with the standard and the additional image-specific requirements for this Connectathon:

Acquisition Modality	Transactions			Compliance
	C-STORE	STOW-RS	Storage commitment	NO LIS	DPIA
3DHISTECH	✔	✔		✔	✔
Grundium		✔		✔
Hamamatsu	✔		✔	✔	✔
Hologic	✔			✔	∼a
Huron	✔				∼b
Leica	✔		✔	∼c	∼b
PathQA	✔			∼d
Pramana	✔				✔e
Song Yi System	✔		✔	∼c	∼f

^aUsed text not coded values.

^bThere were major errors in the coded specimen description.

^cThere were minor errors.

^dThere were minor errors in the equipment description.

^eUsing the CitiusTech metadata enrichment tool.

^fUnfilled coded specimen description.

Some Image Manager/Archive coerce data element values in inbound objects, and may change values or add additional information, and not do so in a compliant manner; any such errors introduced by the Image Manager/Archive are not included here.

Eight (89%) of Acquisition Modalities used C-STORE, 2 (22%) used C-STOW, and 1 (11%) used both. Three (33%) performed Storage Commitment. Five (56%) were able to send completely compliant DICOM instances in either or both NO-LIS or DPIA mode, an additional 2 (22%) had only minor errors, for a total of 7 (78%) with no or only minor errors in compliance. Two (22%) had major errors in the coded specimen description in the DPIA mode.

Image Manager/Archive results

There were seven Image Manager/Archive participants, all of which (100%) were able to receive images from both Acquisition Modalities and Evidence Creators. Only 6 (86%) were able to respond to DICOMweb query/retrieve requests from Image Displays.

Image Manager/Archive	From Acquisition Modality				From Evidence Creator
	C-STORE	STOW-RS	Total	Storage commitment	C-STORE	STOW-RS	Total
Agfa	6	0	6	2	2	0	2
BMD	6	0	6	1	2	1	3
Google	7	1	8	3	2	5	7
Infinitt	8	1	9	2	2	4	6
J4Care	6	1	7	3	3	5	8
Proscia	7	1	8	3	1	4	5
Siemens	7	0	7	3	1	0	1

Image Display results

Fifteen (100%) Image Display participants were able to perform DICOMweb query and retrieval from Image Manager/Archives, 12 (80%) reported being able to display images from various specific Acquisition Modalities, and 11 (73%) reported being able to display annotations from various specific Evidence Creators, as shown in the following table:

Image Display	With Image Manager/Archive	From Acquisition Modality	From Evidence Creator
AstraZeneca	3	Not reported	Not reported
BMD	4	7	Not reported
caMicroscope	3	Not reported	Not reported
Gestalt	5	8	5
IDC	2	7	7
Infinitt	5	9	8
J4Care	5	7	3
MGB	3	8	6
NCKU-ALOVAS	3	9	7
NTUNHS	3	8	7
Philips	4	9	Not reported
Radical Imaging	5	8	6
Techcyte	5	9	4
Visiopharm	6	8	6
Voicebrook	1	Not reported	2

^aPartial success is not reported.

^bSuccess displaying images from a particular Acquisition Modality that registered but did not participate, but whose images from a previous event were present in the archives for annotation purposes, are not included.

Some examples of screenshots of Image Display activities are included in Fig. 4.

Fig. 4.

Examples of screenshots of Image Display activities. The individual participants responsible for the viewers and the source images and annotations are not intentionally not identified.

Evidence Creator results

There were eight (100%) successful Evidence Creator participants, as summarized in the following table:

Acquisition Modality	Transactions		Compliance	On images from Acquisition Modalitiesd,e
	C-STORE	STOW-RS
AixMed		✔	✔	Not reported
Gestalt		✔	✔	8
Hologic	✔		✔	1c
Identify.bio	✔		✔	Not reported
NCKU-ALOVAS		✔	∼a	9
NTUNHS		✔	∼b	8
Techcyte		✔	✔	Not reported
Visiopharm		✔	✔	7

^aThere were minor errors in the algorithm identification.

^bThere were various UID, point list and algorithm identification errors.

^cThis Evidence Creator works only on images from their own Acquisition Modality (specific algorithm).

^dSuccess annotating images from a particular Acquisition Modality that registered but did not participate, but whose images from a previous event were present in the archives for annotation purposes, are not included in the count of Acquisition Modalities.

^eThe count of Acquisition Modalities does not include Evidence Creators that supplied their own images from other sources.

Issues propagated by data elements copied from images (e.g., study- or specimen-related compliance errors) were not included in these results.

Two (25%) of Evidence Creators used C-STORE, 6 (75%) used C-STOW, and none used both. Storage Commitment of annotations was not tested. Six (75%) were able to send completely compliant DICOM instances, an additional 1 (12%) had only minor errors, for a total of 7 (87%) with no or only minor errors in compliance. One (12%) had major errors.

Discussion

Two major features distinguish this DICOM WSI Connectathon event from those that have been conducted previously:

• 1.There was participation by AP-LIS vendors, so that the HL7 transactions and the mapping to the DICOM metadata according to the DPIA profile could be tested for the first time.
• 2.The number of participants (33) was considerably larger than in any previous WG 26 Connectathon.

Another key feature, which though not novel, was very important to the success of the event, was the fact that it was conducted virtually (over the Internet with no physical face-to-face meeting) and over a long period of time (4 months). The extended online format fostered a collaborative environment among vendors, enabling them to share insights, troubleshoot together, and collectively work toward the overarching goal of promoting adoption of DICOM. Specifically, it allowed for development, testing and continuous improvement of new features, such as the AP-LIS connections to the scanners, and the incorporation of the received metadata in the DICOM images. It also helped considerably with refinement of well understood existing capabilities, particularly with respect to issues that have been improved in the standard over time, and that are subject to variation depending on the deployment pattern (such as CORS headers). Contrast this approach with what has occurred in the past at face-to-face events (whether in conjunction with trade shows and scientific meetings,²¹ or dedicated events like IHE Connectathons¹⁷), which only last for a few days or at most a working week. Such events give little opportunity for significant code development and change. In future, a hybrid event, with both virtual Internet-mediated peer-to-peer testing in preparation for a final show-and-tell at a physical meeting might be desirable.

Overall, there was good follow-through by those who registered, with the vast majority of registrants actually participating for the entirety of the event. There was less participation by registered Evidence Creators than other actors. This may be because of an aggressive recruiting drive to engage potential participants, who may have underestimated the level of effort required. Still though, we considered it a success that we had eight annotation sources actually participate.

The unexpectedly large number of participants had a downside, in that there were insufficient resources available to more actively monitor the image display capability; as a consequence, the participants had to self-certify their success and were requested to provide evidence in the form of screenshots. Also, the project management methodology and artefacts (such as result tracking spreadsheets) evolved over time to meet the unexpected demand. Confusion over how to complete these, degraded the amount of detail and precision available in the results. Only the relatively automated test reviews were largely unaffected by this factor, such as the scripted use of dciodvfy, though manual review of the reports from the validation tools was still time consuming. A previous Connectathon⁴² used remote viewing interactive sessions with participants to evaluate viewer behavior, but that level of effort (particularly involving multiple human evaluators) was not feasible on this occasion, for 15 viewers with images from 9 scanners and 8 sources of annotations.

There were a number of other logistical problems observed, which could be handled better in a future event with better planning and tracking methodology (preferably automated). These particularly relate to identifying, tracking and managing the DICOM objects as they move through the process:

• 1.As tests were repeated, it was difficult to keep the Image Manager/Archives “clean” and to identify those images that were current, as opposed to those from prior unsatisfactory tests that had been superseded.
• 2.Though a naming convention for PatientName that specifically identified the participant that scanned images was established, the same could not be done for annotations, because the PatientName is the same for the images and the annotations. Therefore, it was difficult (using conventional queries) for an Image Display to establish which annotations were created by which Evidence Creator when looking for samples to display. Certainly, Manufacturer and ManufacturerModelName can be used to identify the Evidence Creator in the annotations (rather than copying the values from the annotated images), but this was apparently not obvious, and was not documented in the project plan. Further, even though this information may be available from a query, and is certainly present in the retrieved metadata, not all Image Displays show Manufacturer and ManufacturerModelName in their user interface for annotation selection. Overall, this issue made tracking Image Display success harder than it needed to be.
• 3.To facilitate early participation by Evidence Creators before Acquisition Modalities came on-line during the event, the decision was made to pre-load the Image Manager/Archives with images and annotations from the previous event. This turned out to be confusing, and it became difficult to distinguish who made what annotations on which images and when.

As during previous Connectathons,21, 23 considerable useful information was gleaned with respect to practical aspects of implementation of the standards (DICOM, HL7, and the DPIA profile). Particular patterns of failure modes were identified and resolved, and where necessary areas for clarification or improvement of the relevant standards were identified.

Unsurprisingly, this event being the first test of it, the most challenging aspect of compliance across participant categories was the communication and use of metadata between the Acquisition Manager and the Acquisition Modality. Everyone's understanding of the DPIA profile was considerably enhanced by the active participation of AP-LIS vendors, the assistance from the developers of the Metadata Enrichment tool, the experience gained by the scanner vendors adapting to a new pattern of query for and retrieval of HL7 metadata coupled (with the unanticipated need to support in-bound connections from the AP-LIS to the scanner), and the need to implement a mapping HL7 V2 message fields to DICOM attribute values. We were fortunate to have the assistance of IHE PaLM group members to help clarify ambiguities, and resolve uncertainties, as the event proceeded. Specifically, several patterns of initial failures related to metadata communication were identified:

• 1.As mentioned, in-bound connections from AP-LIS to scanners containing query responses were unexpected and provided challenging to resolve (and also have network configuration static IP address and access control security implications). IHE HL7 experts confirmed that this was the intended and appropriate pattern, however.
• 2.There was surprising difficulty getting the usual HL7 and DICOM caret (‘^’) delimiters in PatientName fields handled correctly and consistently between the supplied metadata to pre-load the AP-LIS, the messages from the AP-LIS, what the scanners mapped into the DICOM attribute values, and then how the Image Manager/Archives provided them in DICOMweb query responses. These delimiters are used to separate components of the name (first name, last name, etc.) and need to be handled correctly and consistently. The standards are unambiguous about this (even though there are slight differences between HL7 and DICOM that require special handling,⁴³ which were not the root cause for the discrepancies observed).
• 3.Some Acquisition Modalities had difficulty extracting and recognizing the coded descriptions of specimen preparation (fixation, embedding, and staining), and then populating the corresponding DICOM code sequence attribute values correctly. To some extent, these problems were a result of insufficient time to perfect the implementation. However, some weaknesses in the DPIA profile related to how these are described (specifically, coded values that need to be recognized as stains versus other substances in SPM-6, as opposed to potentially using name-value pairs in OBX-3/OBX-5), and will be addressed in a future revision to DPIA.⁴⁴

One other aspect of DPIA participation from an AP-LIS perspective is the matter of supporting queries from the scanner, rather than broadcasting every order and expecting all scanners to cache the information in advance of needing it. For the Connectathon, we chose to only implement the query model, a preference expressed by the scanner vendors, but this prevented participation by AP-LIS vendors that do not support the queries that are required by DPIA. Adding query support to some systems is non-trivial.⁴⁵ Going forward, it may be useful to introduce another middleware actor, which caches unsolicited LAB-80 broadcasts and is capable of responding to LAB-81 queries from scanners when a slide barcode has been detected, such as is illustrated in Fig. 5.

Fig. 5.

Broadcast caching query proxy.

This would be analogous to the “broker” device that was popular in radiology to address a similar “impedance mismatch” between IS and scanners, before its functions were adopted into commercial IS offerings.⁴⁶ Such a caching proxy could be combined with the metadata enrichment tool, if the latter is also needed.

Though it is required by the DPIA profile, we did not evaluate the compliance of the LAB-82 status update messages to the AP-LIS.

Another pattern of failures observed were the initial difficulties with network configuration issues in general, particularly for those actors accepting inbound connections such as Image Manager/Archives and required pre-configuration, whether it be callers with static IP addresses, firewall settings, need for certificates or authentication tokens, as well as CORS-related issues. Though these issues were expected and resolvable, they did cause some delays. In future, better initial documentation and guidance is needed, if mimicking security features of real-world deployments. Some DICOMweb servers used different end-points for different services (such as query and retrieval), which caused problems for user agents that did not anticipate a need to configure these separately. Problems with the use of Internet connections related to the transfer of large objects were anticipated, and were easily proactively addressed, or remediated, by appropriate timeout configurations. When moving from testing to a production clinical environment, this experience emphasizes how important it is to compare the network configuration requirements described in the DICOM Conformance Statements for each communicating peer, to match the capabilities specified therein, and to establish a common agreement on provision of appropriate security mechanisms. Appropriate network provisioning and configuration, especially with respect to characteristics affecting large object transfer, need to be realistically established.

It is also vital to consider security requirements in a production deployment, especially for confidentiality of data in transit, authentication, and access control, which were not specifically tested in this event. Certainly, DICOMweb transactions over the public network need to be secured with Transport Layer Security (TLS), as is the norm for most modern Hypertext Transfer Protocol (HTTP) transactions. When DICOM and HL7 transactions are performed over a nominally physically secure network inside an institution's walls, there may still be a need to conduct those over a logically secure connection, whether it be via a secure TLS connection, over a Virtual Private Network (VPN), managed by network micro-segmentation, or some other means. The principles of Zero Trust may be applicable. When transactions involve human participants, such as during image viewing, appropriate authentication, and access control mechanisms are required. Fully explicating the necessary security requirements is beyond the scope of this article, but testing appropriate mechanisms may be a suitable focus for future Connectathon events.

With respect to the overall pattern of DICOM WSI pixel data encoding and the required TILED_FULL pyramidal representation, few failures were observed, and good compliance was obtained either initially, or at worst, after several iterations. The requirements were clearly explicated in the technical specification for the event,³¹ which narrowed the permutations and combinations permitted by the underlying standard. A common error initially encountered was to not configure the scanner to use the TILED_FULL pattern, for those scanners that give the user or installer a choice, and particularly for those devices for which TILED_FULL is not the default. In general, the Image Display participants had few, if any, difficulties displaying the images, once acquired in the prescribed form. The automated validation tool dciodvfy reported few compliance issues with respect to the overall organization. As described in the Methods section, dciodvfy was augmented with a specific option to look for the pattern defined for use in the Connectathon, over and above compliance with the underlying, more flexible, standard.

Beyond validating that the DICOM WSIs contained an ICC Profile in the expected attribute, there was no mechanical validation of the correctness of that ICC Profile performed. Nor was there any formal effort to evaluate the effect of using the profile or not in the viewing software. Evaluating color reproducibility of the entire pixel pathway is difficult to accomplish in a virtual setting without physical access to the display device. The quantitative evaluation of scanner and viewer performance in this respect, and as separate components, and the development of automated tools to make use of the DICOM pixel data and ICC Profiles, is the subject of on-going work by other groups, as part of a collaboration between the DPA and FDA. Informally, for some of those viewers that supported it, turning application of the ICC Profile on and off resulted in a clearly distinguishable visible change, particularly for the images that contained ICC profiles generated from a scan of a color calibration slide.⁴⁷

The quality and DICOM compliance of the annotations generated by Evidence Creators was satisfying, given that these are a relatively recent addition to the standard, though they have been tested in previous events.⁴⁸ A common failure mode observed was that of an initial mistake by some Evidence Creators of placing ANN objects in the same Series as the images, which is not permitted by the standard; once identified, this mistake was easily rectified by all the participants, in subsequent iterations. Overall, the successful participation of Evidence Creators, and Image Displays capable of displaying their annotations, bodes well for the future development, training and deployment of AI-based CP, which has been until now plagued by the problem of proprietary formats for images and annotations, and the lack of harmonization of metadata describing specimen preparation, spatial resolution, and color consistency information, both in training, validation and inference phases.

Only 13 of the 32 participants provided Conformance Statements as requested, though there was no concerted effort by the project manager to improve this number. An informal review of their contents revealed that many failed to partially or fully comply with the DICOM standard requirements for these documents. Some were arguably sufficient for evaluation of prototype implementations, but many would need significant improvement to adequately document a commercial implementation to be useful to customers and integrators. It was premature at the time of the Connectathon to request and review IHE Integration Statements, but as the IHE DPIA profile matures to include greater image-specific requirements and particularly new named options, those will become useful documents.

In future, DICOM WG 26 plans to continue to hold Connectathons, though the emphasis may shift to address testing of best practices for more complex use cases, such as multiple Z-planes, multispectral imaging (such as for multiplex immunofluorescence), new compression schemes, in particular JPEG-XL, and extensions to the annotation capabilities (to include holes, using a mutual exclusivity approach). The attention to AP-LIS integration and population of the corresponding DICOM attribute values, may shift to the more formal IHE Connectathons, though are not likely to be out of scope for WG 26 events. To this end, DICOM WG 26 is collaborating with the IHE PaLM Technical Committee to develop change proposals for DPIA that address improvements to the encoding of staining,⁴⁴ formalizing the HL7 to DICOM mapping,⁴⁹ adding named options to the profile to formalize the use of TILED_FULL pyramids and baseline lossy JPEG compression,⁵⁰ as well as addressing workflow related issues such as indicating when a scan is complete and what constitutes the complete set of images for a scan.⁵¹ Improving the specificity of the IHE profiles adds a level of formality and documentation that is difficult to address in the underlying standards.

Overall though, the remarkable level of participation by multiple actors, and the successful results achieved, bode well for the future of DICOM as a means of achieving true interoperability at multiple levels in practical clinical deployments.

Updated examples of HL7 messages⁴⁴ and a DICOM metadata template⁴⁹ have been provided in the corresponding DPIA Correction Proposals (CPs).

Code availability

The open-source code of the Metadata Enrichment tool will be made available at GitHub.

The open-source code for the healthcare-dicom-web-adapter is available at [healthcare-dicom-web-adapter].

The validation software used (dciodvfy and related utilities) is available at Clunie.³⁵

Some of the participants were open source tool developers, and their respective sites are:

• •
  IDC Slim Viewer

  • o
    Code site: http://github.com/ImagingDataCommons/slim
  • o
    Citation⁵²:
• •
  OHIF Viewer

  • o
    Code site: http://github.com/OHIF/Viewers
  • o
    Citation⁵³:
• •
  Dicom-microscopy-viewer Library

  • o
    Code site: http://github.com/ImagingDataCommons/dicom-microscopy-viewer
  • o
    Citation²⁵:
• •
  Dicoogle

  • o
    Code site: http://github.com/dicoogle/dicoogle
  • o
    Citation⁵⁴:
• •
  caMicroscope

  • o
    Code site: http://github.com/camicroscope/caMicroscope
  • o
    Documentation: http://camicroscope.org/
• •
  Mainecoon

  • o
    Code site: https://github.com/cylab-tw/mainecoon
  • o
    Citation⁵⁵:

Declaration of competing interest

David Clunie is the owner of PixelMed Publishing, editor of the DICOM standard (under a NEMA contract), the project manager of the DICOM WG 26 WSI 2025 Connectathon (under a DPA contract), and a funded consultant on various Leidos-managed NCI contracts as well as contracts with various commercial medical device companies that involve DICOM subject matter.

Mohannad Hussain is an independent consultant, providing services to Radical Imaging as well as other commercial and non-profit entities, including Technical Project Manager of Testing, IHE International, and Technical Advisor, Society of Imaging Informatics in Medicine (SIIM).

Data availability

Representative DICOM images and annotations from the event have been publicly shared at the NEMA datasets site: http://tinyurl.com/WG26SP2025Images.