diff --git a/PW44_2026_GranCanaria/Projects/CastAStandardForRealTimeFrontEndIntegrationOfHealthcareApplication/README.md b/PW44_2026_GranCanaria/Projects/CastAStandardForRealTimeFrontEndIntegrationOfHealthcareApplication/README.md index e69f18e87..d41c91595 100644 --- a/PW44_2026_GranCanaria/Projects/CastAStandardForRealTimeFrontEndIntegrationOfHealthcareApplication/README.md +++ b/PW44_2026_GranCanaria/Projects/CastAStandardForRealTimeFrontEndIntegrationOfHealthcareApplication/README.md @@ -40,72 +40,29 @@ Standardize Real-Time Front-End Integration of Healthcare Application 1. Continue the development front-end integration of OHIF and Slicer. 2. Use the standard FHIRcast websocket hub messaging infrastructure for non-FHIR related data/events and real-time front-end intergration. 3. Enable multi-user workflows. +4. Invite and support 3D Slicer developers who want to connect to Cast/FHIRCast. ## Approach and Plan 1. Add Cast hub API to Slicer Web Server with a [AI prompt that generates the hub](https://github.com/mbellehumeur/cast/blob/main/cast-hub-ai-prompt). - - - image - - image - - image - - - -3. Add a Cast client to slicer with a [AI prompt that generates the client service](https://github.com/mbellehumeur/cast/blob/main/cast-hub-ai-prompt). - image - image +2. Add a Cast client to slicer with a [AI prompt that generates the client service](https://github.com/mbellehumeur/cast/blob/main/cast-hub-ai-prompt). - - - -4. Implement events: +3. Implement events: * patient-open/close * imagingstudy-open/close * annotation-update (measurements,markups,...) + * sceneview-update - One user drving three applications: - +4. Do some scene mirroring using scene-update OHIF/OHIF and OHIF/3DSlicver - - - Three users working on the same annotation: - - - - - -6. Add a trame-slicer viewport to OHIF with trame-react and configure hanging protocol. - * Have OHIF with trame-slicer hanging protocol open/close studies (PACS with advanced viewer scenario). - -7. Have a multi-user session with OHIF and Slicer (tumor board or attending/resident scenario). +5. Make a small tutorial. + * Use [Test bench for Project Week 44](https://cast-hub-g6abetanhjesb6cx.westeurope-01.azurewebsites.net/api/hub/admin) and [client](https://na-mic-projectweek44-g0g4a5c5dgc5dcf3.westeurope-01.azurewebsites.net/) + * Invite and support developers to connect their application. -# Cast -## A Standard for Real-Time Front-End Integration of Healthcare Application - - -## Table of Contents - -1. [Introduction](#introduction) -2. [Purpose and Scope](#purpose-and-scope) -3. [Architecture Overview](#architecture-overview) -4. [Core Concepts](#core-concepts) -5. [Protocol Specification](#protocol-specification) -6. [Event Types](#event-types) -7. [Data Formats](#data-formats) -8. [Security](#security) -9. [Implementation Guidelines](#implementation-guidelines) -10. [Examples](#examples) -11. [References](#references) - ---- ## Introduction @@ -132,8 +89,6 @@ Cast supports **bi-directional WebSocket communication**. This enables low-laten Cast also supports **collaborative multi-user workflows** through the hub's ability to group users together within sessions. The hub can coordinate multiple users, allowing them to share events and synchronize their applications in real-time. This enables scenarios such as tumor board meetings, where multiple radiologists and clinicians can simultaneously view and interact with the same DICOM study, with measurements, annotations, and navigation synchronized across all participants own viewers. -![Cast-conferencing 001](https://github.com/user-attachments/assets/f8c2c606-b43a-4c8e-9f2d-e29516a688b6) - The hub-based architecture provides **flexible integration** because applications do not need to connect directly to each other—they only need to reach the hub. This enables applications running on different platforms and locations to seamlessly participate in the same workflow. For example, a 3D Slicer application running on trame in the cloud can communicate with a mobile device application, a web-based viewer, or local camera control , all through the hub without requiring direct network connections between them. @@ -159,172 +114,86 @@ Cast serves as an umbrella standard that encompasses specialized "Cast" variants └──────────────────────────────────────────────────────────────────────────────────────────┘ ``` -**Cast Variants:** - -- **FHIRCast**: Specialized for FHIR resource context management and synchronization -- **DICOMCast**: Specialized for DICOM data exchange and imaging workflow synchronization -- **NAVICast**: Specialized for surgical navigation and real-time guidance systems -- **Other Variants**: The Cast framework is extensible, allowing for domain-specific variants. - -All Cast variants share the same core hub-based architecture, protocol, and infrastructure, but define specialized event types and payloads for their specific domains. This allows applications to participate in multiple Cast variants simultaneously, enabling comprehensive workflow integration across different healthcare domains. - ---- -## Purpose and Scope -### Purpose -Cast enables healthcare applications to: - -- **Distribute Events**: Share events of any type across multiple applications in real-time -- **Support Multiple Data Formats**: Handle FHIR resources, DICOM data, OpenEHR, proprietary formats, legacy data structures, and other healthcare standards -- **Support User Interactions**: Broadcast user interaction events for coordinated UI behavior -- **Enable Low-Latency Interactions**: Support bi-directional WebSocket communication for low-latency interactions, enabling immediate feedback and synchronized collaborative workflows -- **Support Collaborative Multi-User Workflows**: Enable the hub to group multiple users together in sessions, allowing them to share events and synchronize their applications in real-time for collaborative scenarios such as tumor review board meetings. -- **Enable Flexible Integration**: Provide hub-based connectivity where applications only need to connect to the hub (not to each other), enabling applications on different platforms (workstations, mobile devices, web browsers, servers) and locations to seamlessly participate in the same workflow - -### Scope - -This specification defines: - -- The Cast protocol for event distribution and synchronization -- Event types and their payloads -- Subscription and notification mechanisms -- Security requirements -- Data format specifications -- Implementation guidelines - -This specification does not define: - -- Specific user interface implementations -- Business logic for individual applications -- Data storage or persistence mechanisms -- Network transport protocols (though recommendations are provided) - ---- -## Architecture Overview -Cast employs a **hub-based publish-subscribe architecture** with the following key components: -### Components -#### Cast Hub -The Cast Hub is a centralized service that: +## Progress and Next Steps -- Manages subscriptions from applications -- Validates subscription requests -- Receives events from event publishers -- Broadcasts event notifications to all subscribed applications -- Maintains session state and manages connection lifecycle -- **Groups users together within sessions** to enable collaborative multi-user workflows, allowing multiple users to share events and synchronize their applications in real-time + -The hub infrastructure provides significant flexibility for integration because **clients do not need to connect directly to each other**—they only need to establish a connection to the hub. This architectural pattern offers several key advantages: -- **Simplified Connectivity**: Applications don't need to know about or maintain direct connections to other applications in the workflow. Each application only needs to connect to the hub, and from there, all other applications in the session can be reached automatically. +1. Describe specific steps you **have actually done**. -- **Platform and Location Independence**: Applications can run on different computers, operating systems, and platforms. For example, a 3D Slicer application running on a workstation can seamlessly communicate with a mobile device application, a web-based viewer, or a server-based PACS system—all through the hub without requiring direct network connections between them. -- **Network Simplification**: The hub acts as a single point of connectivity, eliminating the need for complex peer-to-peer networking, port forwarding, or direct IP address management between applications. -- **Scalability**: New applications can join a workflow session by simply connecting to the hub, without requiring changes to existing applications or network configurations. -#### Event Publisher -An Event Publisher is an application that: -- Publishes events to the Cast Hub -- Can publish any type of event (user interactions, data changes, workflow events, etc.) -- Examples include EHR systems, PACS viewers, clinical applications, and any system that needs to broadcast events +# Illustrations -#### Event Subscriber +Cast API in Web Server module: -An Event Subscriber is an application that: + image -- Subscribes to specific event types -- Receives event notifications from the Cast Hub -- Processes events and takes appropriate action (update UI, synchronize data, trigger workflows, etc.) -- Examples include clinical decision support tools, imaging viewers, documentation systems, and any application that needs to react to events +Accessing the admin and test client pages from the test workbench: + image -### Communication Flow +Cast admin page: -The hub-based architecture eliminates the need for direct peer-to-peer connections: +image -``` -┌─────────────┐ ┌──────────┐ ┌─────────────┐ -│ Event │───────▶│ Cast │────────▶│ Event │ -│ Publisher │ Event │ Hub │ Event │ Subscriber │ -│ (3D Slicer) │ │ │ │ (Mobile) │ -└─────────────┘ └──────────┘ └─────────────┘ - │ - │ - ┌────────────────────┼────────────────────┐ - │ │ │ - ┌────▼────┐ ┌─────▼─────┐ ┌────▼────┐ - │ Event │ │ Event │ │ Event │ - │Subscriber│ │ Publisher │ │Subscriber│ - │ (Web) │ │ (PACS) │ │(Workstation)│ - └─────────┘ └──────────┘ └─────────┘ -``` -**Key Points:** -- All applications connect **only to the hub** (no direct connections between applications) -- Applications can run on **different platforms** (workstations, mobile devices, web browsers, servers) -- Applications can be on **different networks** and locations -- The hub routes events to all subscribed applications automatically -**Flow:** -1. **Subscription Phase**: Applications subscribe to the Cast Hub for specific event types (each app only needs to know the hub's address) -2. **Event Publication**: Event Publisher publishes an event to the Cast Hub -3. **Event Broadcast**: Cast Hub broadcasts the event to all subscribed applications in the session -4. **Event Processing**: Subscribers receive the event and process it according to their needs -This architecture enables flexible integration scenarios, such as: -- A 3D Slicer application on a workstation communicating with a mobile tablet viewer -- A web-based EHR system coordinating with a server-based PACS -- Multiple applications across different networks collaborating in a single session ---- -## References +Test client: -### Related Standards -- **FHIRcast**: [http://hl7.org/fhir/fhircast.html](http://hl7.org/fhir/fhircast.html) - The foundational standard upon which Cast is based. Note: FHIRcast focuses on FHIR context management, while Cast extends beyond context to support any type of event including user interactions and DICOM data exchange (DICOMCast). -- **HL7 FHIR**: [http://hl7.org/fhir/](http://hl7.org/fhir/) - Fast Healthcare Interoperability Resources -- **WebSocket**: [RFC 6455](https://tools.ietf.org/html/rfc6455) - The WebSocket Protocol -- **DICOM**: [https://www.dicomstandard.org/](https://www.dicomstandard.org/) - Digital Imaging and Communications in Medicine +image +Conference portal: +image -## Progress and Next Steps - + One user driving three applications: + Three users working on the same annotation: -1. Describe specific steps you **have actually done**. - + + + + +_No response_ -# Illustrations - +# Background and References -_No response_ +## References +https://projectweek.na-mic.org/PW33_2020_GranCanaria/Projects/OHIFSlicerBridge/ -# Background and References +- **FHIRcast**: [http://hl7.org/fhir/fhircast.html](http://hl7.org/fhir/fhircast.html) - The foundational standard upon which Cast is based. Note: FHIRcast focuses on FHIR context management, while Cast extends beyond context to support any type of event including user interactions and DICOM data exchange (DICOMCast). +- **HL7 FHIR**: [http://hl7.org/fhir/](http://hl7.org/fhir/) - Fast Healthcare Interoperability Resources +- **WebSocket**: [RFC 6455](https://tools.ietf.org/html/rfc6455) - The WebSocket Protocol +- **DICOM**: [https://www.dicomstandard.org/](https://www.dicomstandard.org/) - Digital Imaging and Communications in Medicine