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. Real-time integration of OHIF, Slicer , 6DOF controllers, navigation controllers.
  2. Multi-user workflows.

Approach and Plan

  1. Add the Cast hub api to the Slicer Web Server module.
  2. Add an entry for the Cast hub in the Web Server static page for hub admin page.
  3. Update the “DICOM Database Browser” OHIF client with the Cast client extension in the Web Server static page.
  4. Add a Cast client to Slicer and controller devices.
  5. Have a multi-user (tumor board like) session with OHIF and Slicer.

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

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:

Core Concepts

Events

Events are notifications that represent any occurrence of interest in a healthcare application. Events have:

Events can represent:

Sessions

A Session represents a logical grouping of applications and users working together. All applications in a session can publish and subscribe to events within that session.

Sessions enable collaborative multi-user workflows where the Cast Hub groups multiple users together, allowing them to share events and synchronize their applications in real-time. For example, in a tumor review board meeting, multiple radiologists and clinicians can join the same session, and when one participant navigates to a specific DICOM study or makes a measurement, all other participants’ viewers are automatically synchronized to the same view and measurement.

Sessions can be:

Subscriptions

A Subscription is a request from an application to receive notifications for specific event types. Subscriptions include:

Protocol Specification

Transport

Cast supports multiple transport mechanisms:

Base URL Structure

https://{hub-host}/cast/{version}/

Example:

https://cast.example.com/cast/v1/

API Endpoints

Subscribe to Events

POST /cast/v1/subscribe

Request Body:

{
  "eventTypes": ["patient-open", "study-view"],
  "callbackUrl": "https://app.example.com/cast/callback",
  "sessionId": "session-12345"
}

Response:

{
  "subscriptionId": "sub-67890",
  "expires": "2024-12-31T23:59:59Z"
}

Unsubscribe from Events

DELETE /cast/v1/subscribe/{subscriptionId}

Publish Event

POST /cast/v1/event

Request Body:

{
  "eventType": "patient-open",
  "timestamp": "2024-01-15T10:30:00Z",
  "source": "ehr-system",
  "sessionId": "session-12345",
  "payload": {
    "patientId": "pat-001",
    "patientName": "John Doe",
    "mrn": "MRN-12345"
  }
}

WebSocket Protocol

Cast’s WebSocket protocol supports full bi-directional communication, enabling applications to both publish and receive events over the same connection. This is a key differentiator from FHIRcast, which does not support bi-directional WebSockets. The bi-directional capability enables low-latency “gaming style” interactions where events can be exchanged with minimal delay, supporting real-time collaborative workflows.

For WebSocket connections, the protocol uses JSON messages:

Subscribe Message:

{
  "action": "subscribe",
  "eventTypes": ["patient-open", "study-view"],
  "sessionId": "session-12345"
}

Publish Event Message (Client to Hub):

{
  "action": "publish",
  "eventType": "patient-open",
  "timestamp": "2024-01-15T10:30:00Z",
  "source": "ehr-system",
  "sessionId": "session-12345",
  "payload": {
    "patientId": "pat-001",
    "patientName": "John Doe"
  }
}

Event Notification Message (Hub to Client):

{
  "eventType": "patient-open",
  "timestamp": "2024-01-15T10:30:00Z",
  "source": "ehr-system",
  "sessionId": "session-12345",
  "payload": {
    "patientId": "pat-001",
    "patientName": "John Doe"
  }
}

Applications can simultaneously send events to the hub and receive events from other applications over the same WebSocket connection, enabling true real-time bidirectional communication with minimal latency.

Event Types

Cast defines a set of standard event types, but also supports custom event types for extensibility. Unlike FHIRcast, which focuses on FHIR context events, Cast supports any type of event including user interactions, data exchanges, and workflow events.

Standard Event Types

User Interaction Events

Payload Example:

{
  "elementId": "patient-search-button",
  "elementType": "button",
  "coordinates": {"x": 150, "y": 200},
  "timestamp": "2024-01-15T10:30:00Z"
}

Patient Events

The exiuting FHIRcast events are:

Payload Example:

{
  "patientId": "pat-001",
  "patientName": "John Doe",
  "dateOfBirth": "1980-01-15",
  "mrn": "MRN-12345",
  "identifiers": [
    {
      "system": "http://hospital.example.com/mrn",
      "value": "MRN-12345"
    }
  ]
}

Custom Event Types

Applications can define custom event types using the format:

{domain}:{event-name}

Examples:

radiology:worklist-update
pharmacy:medication-review
user:mouse-move
workflow:task-completed
dicom:image-annotation-added

The Cast Hub will attempt to provide data in the preferred format, falling back to available formats if necessary.

Security

Security is paramount in healthcare applications. Cast implements multiple security measures to protect Protected Health Information (PHI).

Authentication

Cast authentication:

  1. Applications authenticate with the enterprise authentication server
  2. Access tokens are required for all API calls
  3. Tokens are validated on each request
  4. Token refresh mechanisms are supported

Authorization

Authorization is enforced at multiple levels:

Transport Security

All communications must use:

Data Protection

Compliance

Cast implementations should comply with:

References

Progress and Next Steps

  1. Describe specific steps you have actually done.

Illustrations

No response

Background and References

No response