Stream Orchestration Subsystem for Variable-Length Message Routing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing stream orchestration systems for healthcare environments are inflexible and inefficient due to reliance on fixed-length messages, stateless architectures, and limited interoperability, leading to cumbersome, time-consuming, and costly clinical tasks.

Innovation Solution

The implementation of a stream orchestration subsystem that uses a polyglot stream orchestration language (SOL) to manage variable-length message streams, enabling flexible routing and session management across multiple client devices and services.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of manufacture

If fixed-length messages are used in stream orchestration systems, then message format simplicity is improved, but bandwidth efficiency and flexibility deteriorate

Engineering Contradiction:
Improvemessage format simplicityVSAvoidbandwidth efficiency
Core Design Contradiction:
Ease of manufactureVSLoss of energy

Solution Approach 1:

The system transitions from fixed-length messages to variable-length messages, allowing the message structure to dynamically adapt to the actual data size. This enables efficient bandwidth utilization by sending only the necessary amount of data without padding, while maintaining structured formatting through defined schemas for different message types in healthcare workflows.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The message length parameter is changed from fixed to variable, allowing messages to be optimized based on the actual information content. The system defines different message formats with variable fields that can be adjusted according to the specific healthcare data being transmitted, improving bandwidth efficiency while maintaining format simplicity through standardized schemas.

Inventive Principle:
Principle #35Parameter changes

2Device complexity

If stateless architectures are used, then system complexity is reduced, but session management capability and interoperability deteriorate

Engineering Contradiction:
Improvesystem complexityVSAvoidsession management capability
Core Design Contradiction:
Device complexityVSAdaptability or versatility

Solution Approach 1:

The system introduces session identifiers as intermediary elements that enable stateful session management while maintaining the simplicity of stateless message processing. Each message includes a session identifier that allows the system to track and manage related messages within a healthcare workflow without requiring complex state storage, enabling multi-device collaboration while keeping the architecture relatively simple.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Device complexity

If limited interoperability is used, then system complexity is reduced, but flexibility and adaptability in healthcare environments deteriorate

Engineering Contradiction:
Improvesystem complexityVSAvoidflexibility in healthcare environments
Core Design Contradiction:
Device complexityVSAdaptability or versatility

Solution Approach 1:

The system implements a universal message format with defined schemas that can accommodate multiple healthcare data types and workflows. The message structure is designed to be multi-functional, supporting different message types (e.g., patient data, clinical notes, diagnostic information) within a single standardized framework, enabling broad interoperability across diverse healthcare devices and systems without requiring separate protocols for each use case.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS20250097304A1Session management for variable-length message streams
Publication Date: 2025.03.20 ORACLE INT CORP
  • US20250097304A1 patent drawing
  • US20250097304A1 patent drawing
  • US20250097304A1 patent drawing

AI summary

Techniques are disclosed for session management for variable-length message streams. In an example method, a computing system establishes a first session by receiving, from a first computer system, registration information including a first session identifier and a specification of a channel; determining a stream orchestration instance for the channel; and joining the first computer system to the first session for the stream orchestration instance based on the first session identifier. The computing system receives, from a second computer system, a message including context information, the context information including the first session identifier. The computing system identifies the first session based on the first session identifier, the first session having one or more member computer systems. The computing system outputs the message to at least one of the one or more member computer systems of the first session.