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.

    image

    image

    image

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

    image

  3. Implement events:

    • patient-open/close
    • imagingstudy-open/close
    • annotation-update (measurements,markups,…)

One user drving three applications:

Three users working on the same annotation:

  <iframe width="800" height="400" src="https://youtube.com/embed/O-M0Y9JHcoQ" >
  </iframe>
  1. 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).
  2. Have a multi-user session with OHIF and Slicer (tumor board or attending/resident scenario).

Cast

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

Table of Contents

  1. Introduction
  2. Purpose and Scope
  3. Architecture Overview
  4. Core Concepts
  5. Protocol Specification
  6. Event Types
  7. Data Formats
  8. Security
  9. Implementation Guidelines
  10. Examples
  11. References

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.

Cast-conferencing 001

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)│    │
│  └──────────────────┘  └──────────────────────┘  └──────────────────┘  └────────────┘    │
│                                                                                          │
└──────────────────────────────────────────────────────────────────────────────────────────┘

Cast 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:

Scope

This specification defines:

This specification does not define:

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:

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:

Event Publisher

An Event Publisher is an application that:

Event Subscriber

An Event Subscriber is an application that:

Communication Flow

The hub-based architecture eliminates the need for direct peer-to-peer connections:

┌─────────────┐         ┌──────────┐         ┌─────────────┐
│   Event     │───────▶│   Cast   │────────▶│   Event     │
│  Publisher  │  Event  │   Hub    │  Event  │ Subscriber  │
│ (3D Slicer) │         │          │         │  (Mobile)   │
└─────────────┘         └──────────┘         └─────────────┘
                              │
                              │
         ┌────────────────────┼────────────────────┐
         │                    │                    │
    ┌────▼────┐         ┌─────▼─────┐        ┌────▼────┐
    │  Event  │         │   Event   │        │  Event  │
    │Subscriber│        │ Publisher │        │Subscriber│
    │  (Web)   │        │  (PACS)   │        │(Workstation)│
    └─────────┘         └──────────┘        └─────────┘

Key Points:

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:

References

Progress and Next Steps

  1. Describe specific steps you have actually done.

Illustrations

No response

Background and References

No response