Edit this page

NA-MIC Project Weeks

Back to Projects List

Cast - A Standard for Real-Time Front-End Integration of Healthcare Application

Key Investigators

Project Description

Standardize Real-Time Front-End Integration of Healthcare Application

Objective

  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.

Approach and Plan

  1. Add Cast hub API to Slicer Web Server with a AI prompt that generates the hub.

  2. Add a Cast client to slicer with a AI prompt that generates the client service.

  3. Implement events:
    • patient-open/close
    • imagingstudy-open/close
    • annotation-update (measurements,markups,…)
    • scene-update
  4. Do some scene mirroring using scene-update OHIF/OHIF and OHIF/3DSlicver

  5. Have a multi-user session with OHIF and Slicer (tumor board or attending/resident scenario).

Introduction

Cast is a standard protocol for real-time client to client event communication across healthcare applications. Built upon the foundational architecture of FHIRCast, Cast extends beyond FHIR-specific data and context management to support a wide range of healthcare data formats, user interactions, controller inputs and event types. DICOM, DICOMweb, FHIR and HL7v2 are server to server and client to server protocols.

Cast is a client to client protocol. Client to client protocols differ because they often deal with temporary objects such as user interactions. Even when FHIR or DICOM data exchange is exchanged, it is usually to refer an existing object or initiate a new object that may or may not be saved to the server. For example, a DICOM annotation can be communicated but may or may not become part of a DICOM structured report.

Cast serves as an umbrella standard that encompasses specialized variants such as FHIRCast (for FHIR context management), DICOMCast (for DICOM data exchange), NAVICast (for surgical navigation), and other domain-specific implementations. All variants share the same core infrastructure while defining specialized event types for their domains (see Cast Ecosystem below).

Background

Healthcare environments sometimes involve multiple specialized applications working together to support clinical workflows. These applications need to communicate and coordinate in real-time, sharing events such as user interactions, data exchanges, state changes, and workflow transitions. A typical scenario is radiology reporting where a worklist, viewer, reporting and EMR integrate to produce the diagnostic report. This workflow is defined in the IHE Integrated Reporting Applications profile.

FHIRcast provides a solid foundation for FHIR-based context management, focusing specifically on synchronizing FHIR resource context across applications. However, the healthcare ecosystem includes many non-FHIR data formats, such as DICOM, openEHR and use cases that extend beyond context management such has navigation controllers, VR controllsers, joysticks and footswitches. Cast addresses this by providing a flexible, extensible framework that supports:

Cast supports bi-directional WebSocket communication. This enables low-latency, “gaming style” interactions where applications can exchange events in real-time with minimal delay, supporting use cases such as collaborative viewing, synchronized navigation, and interventional workflows that require immediate feedback and coordination.

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.

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.

Cast Ecosystem

Cast serves as an umbrella standard that encompasses specialized “Cast” variants for different healthcare domains and use cases:

┌──────────────────────────────────────────────────────────────────────────────────────────┐
│                                                                                          │
│                                    Cast                                                  │
│                              (Core Standard)                                             │
│                                                                                          │
│  ┌──────────────────┐  ┌──────────────────────┐  ┌──────────────────┐  ┌────────────┐    │
│  │                  │  │                      │  │                  │  │            │    │
│  │   FHIRCast       │  │     DICOMCast        │  │    NAVICast      │  │   Other    │    │
│  │                  │  │                      │  │                  │  │   Cast     │    │
│  │ FHIR Context     │  │ DICOM Data Exchange  │  │   Surgical       │  │ Variants   │    │
│  │   Management     │  │    (Front-end)       │  │   Navigation     │  │            │    │
│  │                  │  │                      │  │                  │  │(Extensible)│    │
│  └──────────────────┘  └──────────────────────┘  └──────────────────┘  └────────────┘    │
│                                                                                          │
└──────────────────────────────────────────────────────────────────────────────────────────┘

References

Progress and Next Steps

  1. Describe specific steps you have actually done.

Illustrations

image image image

image

image

One user driving three applications:

Three users working on the same annotation:

No response

Background and References

No response