Draft Status
Draft - team will hold off on page creation
Category
Infrastructure
Key Investigators
- Martin Bellehumeur (Radical Imaging, Germany)
Project Description
Cast interface Module for 3D Slicer: Service Providers, 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.
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.
Hub: The hub is the server that distributes the messages and handles the data transfer requests over the websocket connection to each client.
Objective
- 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.
- Support 3D Slicer developers who want to connect to cast / FHIRcast.
Approach and Plan
Implement SCENEVIEW request in the Slicer client
Progress and Next Steps
No response
Illustrations
Cast Interface Module
Cast hub
Background and References
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:
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. For cast, desktop integration is what happens after authentication/authorization and it aims to provide a general framework that can support all use cases just by adding data types with verbs (events).
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.
-
Support for binary files transfer; therefore payloads other than FHIR/JSON, such as DICOM, PNG, NIFTi, openEHR, OpenIGTLink.
-
Group topics for multi-user workflows, such as tumor boards or interventional procedures.
Support for IHE roles.
-
Support three additional subscription data:
-- subscriber.product.name,
-- subscriber.product.version,
-- subscriber.actors
-
Support four additional event data:
-- subscriber.name
-- subscriber.actor
-- target.actor
-- target.product.name
For testing and development, the hub provides a test mock auth endpoint that assigns a user when none is provided. A “single-user” mode is available for stand-alone applications that do not use authentication. The hub mock auth endpoints are the same as keycloak to facilitate integration.
Not supported:
The cast hub does not support context management in the hub. 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.
Hub availability and complexity could be the main obstacle to the deployment of this technology; therefore the hub is kept as simple as possible and only deals with message handling. The cast_api.py script used for Volview server and 3D slicer is @2000 lines and the admin.html portal as well.
https://projectweek.na-mic.org/PW44_2026_GranCanaria/Projects/CastAStandardForRealTimeFrontEndIntegrationOfHealthcareApplication/
VolView cast interface:
VTK-JS worklist cast client example:
<iframe width="420" height="315" src="https://youtu.be/MUagLJ5HHG0">
</iframe>
https://youtu.be/MUagLJ5HHG0
Draft Status
Draft - team will hold off on page creation
Category
Infrastructure
Key Investigators
Project Description
Cast interface Module for 3D Slicer: Service Providers, 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.
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.
Hub: The hub is the server that distributes the messages and handles the data transfer requests over the websocket connection to each client.
Objective
Approach and Plan
Implement SCENEVIEW request in the Slicer client
Progress and Next Steps
No response
Illustrations
Cast Interface Module
Cast hub
Background and References
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:
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. For cast, desktop integration is what happens after authentication/authorization and it aims to provide a general framework that can support all use cases just by adding data types with verbs (events).
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.
Support for binary files transfer; therefore payloads other than FHIR/JSON, such as DICOM, PNG, NIFTi, openEHR, OpenIGTLink.
Group topics for multi-user workflows, such as tumor boards or interventional procedures.
Support for IHE roles.
Support three additional subscription data:
-- subscriber.product.name,
-- subscriber.product.version,
-- subscriber.actors
Support four additional event data:
-- subscriber.name
-- subscriber.actor
-- target.actor
-- target.product.name
For testing and development, the hub provides a test mock auth endpoint that assigns a user when none is provided. A “single-user” mode is available for stand-alone applications that do not use authentication. The hub mock auth endpoints are the same as keycloak to facilitate integration.
Not supported:
The cast hub does not support context management in the hub. 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.
Hub availability and complexity could be the main obstacle to the deployment of this technology; therefore the hub is kept as simple as possible and only deals with message handling. The cast_api.py script used for Volview server and 3D slicer is @2000 lines and the admin.html portal as well.
https://projectweek.na-mic.org/PW44_2026_GranCanaria/Projects/CastAStandardForRealTimeFrontEndIntegrationOfHealthcareApplication/
VolView cast interface:
VTK-JS worklist cast client example:
<iframe width="420" height="315" src="https://youtu.be/MUagLJ5HHG0"> </iframe>https://youtu.be/MUagLJ5HHG0