Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ layout: pw45-project

permalink: /:path/

project_title: 'Cast interface module for 3D Slicer: Service Providers, Image Display client and
project_title: 'Cast interface module for 3D Slicer: Resource Servers, Image Display client and
Hub.'
category: Infrastructure
presenter_location:
Expand All @@ -21,11 +21,11 @@ key_investigators:
<!-- Add a short paragraph describing the project. -->


Cast interface Module for 3D Slicer: Service Providers, Image Display client and Hub.
Cast interface Module for 3D Slicer: Resource Servers, Image Display client and Hub.

Service Providers: Service providers subscribe to all user topics for dicom events and send back results to the user. Each service provider connects with its own product name and onMessage script. The script handles producing the results from the DICOM files received. The service connects to the hub in the cloud and can service the clients even when the service is not in the cloud.
Resource servers: Resource servers subscribe to all user topics for dicom/nifti events and send back results to the user throuh the hub. Each server has its own onMessage script. The script handles producing the results from the DICOM files received and publishes a dicom-send event back to the user topic.

Image Display Client: The image display client provide a PACS client type interface to the 3D slicer viewer. Supported events are ImagingStudy-open, Imaging-Study-close and request for sceneview.
Image Display Client: The image display client provide a PACS client type interface to the 3D slicer viewer. Supported events should be ImagingStudy-open, Imaging-Study-close, dicom-send and request for sceneview.

Hub: The hub is the server that distributes the messages and handles the data transfer requests over the websocket connection to each client.

Expand All @@ -38,22 +38,19 @@ Hub: The hub is the server that distributes the messages and handles the data tr
<!-- Describe here WHAT you would like to achieve (what you will have as end result). -->


- Provide cloud access to 3D slicer processing services to viewers without running 3D slicer in the cloud. Only the hub needs to be in the cloud and 3D slicer can connect to the hub and provide the services from anywhere.
- Finish the request for request SCENEVIEW started in project week 44.
- Add an image display client to the 3D slicer viewer.
- Provide cloud access to 3D slicer processing services to viewers without running 3D slicer in the cloud. Only the hub needs to be in the cloud. 3D Slicer can connect to the hub and provide the services from anywhere through the websocket connection.
- Finish the request for SCENEVIEW started in project week 44 by adding an image display client to the 3D slicer viewer.
- Support 3D Slicer developers who want to connect to cast / FHIRcast.





## Approach and Plan

<!-- Describe here HOW you would like to achieve the objectives stated above. -->



Implement SCENEVIEW request in the Slicer client
- Implement reource servers with existing 3D slicer modules such as Total Segmentator or Skull Stripper.
- Implement SCENEVIEW request in the Slicer client



Expand All @@ -74,24 +71,28 @@ Online example:
<!-- Add pictures and links to videos that demonstrate what has been accomplished. -->


VolView using a segmentation service provider:
VolView using a segmentation resource server:

<!-- should be https://youtu.be/AXadJl0u8g8 -->
<iframe width="800" height="500" src="https://www.youtube.com/embed/AXadJl0u8g8?si=d2dmwfyggzZY5NsB" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

<iframe width="800" height="500" src="https://www.youtube.com/embed/hxk0FvQMyb8?si=d2dmwfyggzZY5NsB" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>


Cast Interface Module:

<img width="800" alt="Image" src="https://github.com/user-attachments/assets/64fc6b9c-85c2-46cb-af95-a9e68d2ebbd9" />
<img width="756" height="804" alt="image" src="https://github.com/user-attachments/assets/edaccdd0-3c25-4dce-b356-b375af9d97fd" />




Cast hub:

<img width="800" alt="Image" src="https://github.com/user-attachments/assets/70e48177-4cbd-4dc9-a723-8593c6fa67ef" />
<img width="1253" height="892" alt="image" src="https://github.com/user-attachments/assets/e99f55c1-0448-4bf9-97c4-55424eb3ca2d" />




# Background and References
# Background

<!-- If you developed any software, include link to the source code repository.
If possible, also add links to sample data, and to any relevant publications. -->
Expand All @@ -100,15 +101,17 @@ Cast hub:
What is Cast?
Cast is an offshoot of FHIRcast (<https://fhircast.hl7.org/>). FHIRcast is the standard replacing Epic’s file drop interface for integration with PACS and reporting systems. It provides a secure messaging infrastructure using a hub with websocket subscriptions.

Cast differs to FHIRcast in the following way:
Cast differs to FHIRcast in it;s goals and features.

Goal:

Mission:
Cast is focused on desktop integration of healthcare applications. It is not restricted to a specific data format. Cast is also not restricted to a specific authentication mechanism; it expects that apps will authenticate with the customer's system. Cast aims to provide a general framework that can support all use cases by adding data types with verbs (events), for example, nifti-send.




Features:

In addition to FHIRcast events, the cast hub allows the following:

- Request data from applications such as worklist context, report content, DICOM instance, DICOM tag, JPEG/PNG screenshots, scene views, etc.
Expand Down Expand Up @@ -137,17 +140,53 @@ For testing and development, the hub provides a test mock auth endpoint that ass
Hub availability and complexity are possibly the main obstacle to the deployment of this technology; therefore the hub is kept as simple as possible and only handles message handling. The cast_api.py script used for Volview server and 3D slicer is @2000 lines and the admin.html portal as well.


The cast hub does not support context management. That strategy was tried 30 years ago with CCOW ( <https://en.wikipedia.org/wiki/CCOW> ) and failed. Context is to be retrieved from the relevant applications directly through the request mechanism.
The cast hub does not support context management. Context is to be retrieved from the relevant applications directly through the request mechanism. In cast, the hub is a routing appliance only. It does not look at event data; it has no storage or database; only distribution logic. The context management paradigm was tried 30 years ago with CCOW ( <https://en.wikipedia.org/wiki/CCOW> ). We have to acknowledge that today all advanced radiology integrations function without a context management server. They manage with events obtained through a combination of file drops, postMessages, URL with parameters, EXEs with command-line parameters and socket to to socket.

There is value to being able to obtain real-time information from other applications in the workfow. For example, knowing the "sceneview" status of an Image Display application or the current content of the report editor. This is different than what a FHIRcast hub would know since it is relies on getting events which are not generated for each keystoke/click.

## Security Benefits for Service Providers

This architecture protects service providers by eliminating direct inbound internet exposure entirely.

Each resource server establishes only **outbound encrypted connections** to the Cast Hub, which functions exclusively as a lightweight **routing and session coordination appliance**. Because no inbound ports need to be opened on hospital or enterprise networks, the resource servers remain protected behind existing firewalls and are never directly reachable from the public internet.

The Cast Hub maintains:

- No persistent storage
- No database
- No long-term data retention
- No exposed clinical infrastructure

This significantly reduces the overall attack surface and minimizes operational security risk. It also simplifies providing reources since the IT department does not need to open ports on their router. Since the resource servers are not on the internet, you will get shared keys for the auth server. The hub can use domain name certificates.


<img width="1536" height="1024" alt="image" src="https://github.com/user-attachments/assets/04cd3c0b-58e4-41c6-85e3-9c40db579a9a" />




<https://projectweek.na-mic.org/PW44_2026_GranCanaria/Projects/CastAStandardForRealTimeFrontEndIntegrationOfHealthcareApplication/>

In theory, the hub can be cloud deployed as a serverless application. In practice, many of those low cost offerings do not support websocket services and a docker based offering is necessary like Azure WebApps or AWS elastic beanstalk.

For high availibity deployment a hot stand-by configuraiton can be configured. The "reset server" button in the hub admin portal allows testing workflow behavior during failover.

VolView cast interface:

<img width="800" alt="Image" src="https://github.com/user-attachments/assets/a2913844-0202-40bb-b52c-4cf45d26fc82" />
<img width="800" height="500" alt="image" src="https://github.com/user-attachments/assets/d187a192-ee2d-4a70-90ba-7a3885ecba11" />


VTK-JS worklist cast client example:
<iframe width="800" height="500" src="https://www.youtube.com/embed/MUagLJ5HHG0?si=ciSN9c_wLSfpc3X9" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
<iframe width="600" height="500" src="https://www.youtube.com/embed/MUagLJ5HHG0?si=ciSN9c_wLSfpc3X9" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>


# References

Total segmentation:
https://pubs.rsna.org/doi/10.1148/ryai.230024

Skull stripper:
Wasserthal J., Meyer M., , Hanns-Christian Breit H.C., Cyriac J., Shan Y., Segeroth, M.: TotalSegmentator: robust segmentation of 104 anatomical structures in CT images. https://arxiv.org/abs/2208.05868