Large Cancer Assistant (LCA) Framework
- Large Cancer Assistant (LCA) is a modular, model-agnostic framework that decouples multimodal data ingestion, protocol routing, AI inference, and output packaging.
- It employs Algorithmic Impermeability to maintain invariant orchestration logic even when underlying diagnostic or remedy modules change.
- The framework standardizes clinical data using Entry Theory, enabling seamless integration with various protocol-specific AI services and downstream systems.
Large Cancer Assistant (LCA) denotes a model-agnostic orchestration framework for oncology clinical decision support that structurally decouples multimodal data ingestion, protocol routing, artificial-intelligence inference, and downstream output packaging. In its formal 2026 definition, LCA is not a monolithic diagnostic or therapeutic model; rather, it is an architectural layer that receives valid clinical histories, activates cancer-specific protocols, invokes abstract diagnostic and remedy modules under interface contracts, and emits a Standardized Intermediate Payload (SIP) together with human-readable wording. The framework is grounded in “Algorithmic Impermeability,” a design principle stating that orchestration logic must remain independent of the internal parameterization of black-box AI components (Marrakchi et al., 7 Jul 2026).
1. Formal definition and architectural scope
The LCA framework is formalized as the 7-tuple
where is the input space of valid clinical histories, is a finite protocol catalog, is the Data Preprocessing Module, is the Cancer Switching Module, and are abstract AI modules for diagnosis and remedy generation, and is the terminal Wordings Module (Marrakchi et al., 7 Jul 2026).
This definition positions LCA as an orchestration substrate rather than a foundation model, multimodal LLM, or single-task classifier. The distinction is central. The diagnostic and remedy modules are protocol-specific and can be implemented by heterogeneous systems, whereas preprocessing, routing, and payload assembly are specified independently of those systems. The framework is therefore described as post-hoc and model-agnostic: the orchestration layer is designed to remain stable even when underlying AI models are retrained, replaced, or diversified (Marrakchi et al., 7 Jul 2026).
A related misconception is to equate “Large Cancer Assistant” with an end-to-end conversational oncology model. Existing oncology systems associated with that broader label are heterogeneous. “Cancer-Answer” is a zero-shot GPT-3.5 Turbo question-answering system for GI-cancer queries with A1 and A2 evaluation metrics (Deroy et al., 2024); LungCURE and LCAgent target guideline-constrained lung-cancer staging and treatment reasoning across multimodal records (Hao et al., 8 Apr 2026); CATCH-FM is an EHR foundation model for cancer pre-screening (Sun et al., 30 May 2025); ONCOPILOT is a promptable CT foundation model for interactive 3D tumor segmentation (Machado et al., 2024). The 2026 LCA framework instead supplies an orchestration boundary within which such components could, in principle, be attached as protocol-specific modules or upstream/downstream services. This suggests that “LCA” functions best as an architectural term, with task models treated as replaceable constituents rather than as the definition of the system itself.
2. Entry Theory and multimodal standardization
LCA’s input formalism is built on “Entry Theory,” which uses a Geometric Deep Learning perspective to standardize heterogeneous medical data along two independent axes: a structural axis and a medical axis (Marrakchi et al., 7 Jul 2026).
On the structural side, a domain is defined as , where is a nonempty set and 0 is a group acting on 1. An entry is a signal 2 with group action
3
This abstraction is intended to cover 3D CT volumes, whole-slide histopathology images, token sequences, tabular laboratory data, and related modalities within a uniform signal-theoretic language (Marrakchi et al., 7 Jul 2026).
Independently, each entry carries a medical signature
4
where 5 denotes provenance, 6 denotes one or more usage categories, and 7 denotes certainty. A characterized entry is then
8
A clinical history is a finite ordered sequence of such characterized entries together with a patient identifier, written as 9 (Marrakchi et al., 7 Jul 2026).
The stated significance of this formalism is the independence of axes: structural properties such as geometry, topology, or sequence order are separable from medical semantics such as whether a datum is an observation, a diagnosis, or an inferred output. This permits preprocessing by provenance while preserving the medical signature. A plausible implication is that the same orchestration layer can ingest data types with radically different inductive biases without collapsing them into a single ad hoc schema too early in the pipeline.
3. Routing logic, abstract AI modules, and failure semantics
After preprocessing, LCA routes each case through the Cancer Switching Module (CSM). The CSM returns either a nonempty activation set 0 or 1 if evidence is insufficient (Marrakchi et al., 7 Jul 2026).
Two routing variants are defined. In Variant V1, a clinician or upstream system provides a declared protocol subset 2, and the CSM deterministically returns that set when valid. In Variant V2, a learned multi-protocol router 3 emits per-protocol confidence scores, which are thresholded at 4 to produce the activation set. If no protocol score crosses threshold, the module returns 5 (Marrakchi et al., 7 Jul 2026).
For each activated protocol 6, the diagnostic module 7 and remedy module 8 accept the preprocessed history plus 9 and emit either a characterized output or 0 if protocol-specific preconditions fail. The Wordings Module 1 then aggregates structured outputs and null states into a SIP and converts any 2 into a Supplementary Data Request (SDR) (Marrakchi et al., 7 Jul 2026).
This failure model is unusually explicit. The framework distinguishes precondition failure from inference failure. A precondition failure yields 3 and must generate an SDR. By contrast, CODE_FAIL is represented as a decision class and does not trigger an SDR. The distinction matters operationally because the orchestration layer is intended to preserve branch-local causality: a missing modality or malformed input should be surfaced as a targeted request for additional data, whereas a model-side runtime or prediction error belongs to a different error category (Marrakchi et al., 7 Jul 2026).
The modular semantics resonate with more task-specific oncology systems that decompose reasoning rather than treating it as a single forward pass. In LungCURE, for example, LCAgent separates multimodal evidence extraction, deterministic AJCC stage aggregation, feature extraction, scenario routing, and scenario-specific expert reasoning. On its benchmark of 1,000 clinician-labeled lung-cancer cases, this plugin raised Qwen3.5-397B performance from 61.5% to 66.3% TNM accuracy, from 35.2% to 59.3% treatment precision, and from 31.6% to 62.0% end-to-end precision in the Chinese image-input setting (Hao et al., 8 Apr 2026). This suggests a natural conceptual affinity between LCA’s orchestration layer and multi-stage clinical reasoning pipelines, although the two works define distinct systems.
4. Algorithmic Impermeability
Algorithmic Impermeability is the central invariant of LCA. Formally, if 4 and 5 are two parameterizations of protocol-specific AI modules that satisfy the same interface contracts, and if 6 denotes the orchestration-structural projection of the final payload—recording activation sets, invoked or halted protocols, schema, and SDR presence, but excluding actual inference content—then
7
The proof sketch given in the paper rests on three observations: 8, 9, and the SIP schema are parameter-free with respect to the AI models; branch-level 0 status is fixed by interface contracts and declared precondition-failure sets; and the Wordings Module merely assembles outputs into the same JSON structure (Marrakchi et al., 7 Jul 2026).
The immediate consequence is that the orchestration components do not need to be modified when an AI model is retrained or swapped, provided the model continues to satisfy the same input-output contract. Corollary 3 states this explicitly for 1, 2, and 3 (Marrakchi et al., 7 Jul 2026).
This property differentiates LCA from monolithic multimodal systems whose internal representation learning, routing, and output formatting are tightly coupled. In practical terms, the invariance claim is architectural rather than clinical: it guarantees stability of routing projection and schema, not stability of predicted diagnosis or therapy. The distinction is crucial because the paper’s empirical validation concerns orchestration behavior, not oncologic correctness.
5. Standardized Intermediate Payload and interoperability boundary
The sole external output of LCA is the Standardized Intermediate Payload. The SIP is designed to be always top-level, to reference inputs by identifier rather than embed heavy primary data, to exclude model identity strings, and to distinguish 4 from CODE_FAIL (Marrakchi et al., 7 Jul 2026).
Its schema records run metadata, input provenance, CSM execution details, optional top-level SDRs, and per-protocol outputs. Each protocol branch contains exactly three logical possibilities: a diagnostic output object or null, a remedy output object or null, and an SDR object or null. Input provenance retains entry-level medical signatures, while csm_execution stores routing variant, activation set, and routing parameters. Human-readable text is included as lcwm_narrative, but the authoritative machine-facing product is the SIP itself (Marrakchi et al., 7 Jul 2026).
The architectural consequence is a clean boundary between AI orchestration and hospital information systems. The LCA paper states that downstream translation of SIP into HL7 FHIR or openEHR is a separate engineering task rather than part of the core framework. The SIP therefore does not itself implement EMR interoperability; rather, it “natively” sets the stage for future interoperability by fixing a stable intermediate representation (Marrakchi et al., 7 Jul 2026).
This boundary is consistent with broader oncology AI trends. Local, privacy-preserving deployment is emphasized in open-source radiology extraction pipelines such as the llm_extractinator + qwen2.5-72b system for longitudinal Dutch CT report parsing, which achieved attribute-level accuracies of 93.7% for target lesions, 94.9% for non-target lesions, and 94.0% for new lesions while running locally without external API calls (Builtjes et al., 10 Mar 2026). It is also consistent with CT-centric foundation models such as ONCOPILOT, which integrate interactive segmentation and measurement into DICOM-compatible workflows (Machado et al., 2024). These works do not define SIP-like orchestration boundaries, but they illustrate the kind of protocol-local AI services that a separate orchestration layer could reference by contract.
6. Proof-of-concept validation and relation to the broader oncology assistant ecosystem
The LCA proof of concept validates orchestration logic across four technical scenarios, explicitly not clinical accuracy (Marrakchi et al., 7 Jul 2026).
In the nominal end-to-end flow, conducted over 5 runs, completion rate was 100%. Mean orchestration latencies were 6 ms, 7 ms, and 8 ms, for total orchestration overhead of approximately 0.042 ms and full pipeline latency of approximately 0.096 ms including stubs (Marrakchi et al., 7 Jul 2026).
In the impermeability scenario, two alternative diagnostic stubs satisfying the same lung-module interface were swapped across identical inputs. The structural projection 9 remained equal in 100% of runs, while diagnostic content differed in 100% of runs, directly illustrating the difference between invariant orchestration and variable model outputs (Marrakchi et al., 7 Jul 2026).
In the failure-safety scenario, corrupted CT inputs and missing modalities caused the diagnostic module to raise 0 and the Wordings Module to emit protocol-level SDRs, yielding 100% SDR recall under the injected anomalies. Empty histories with 1 were rejected as type errors before module execution, with 100% type-invariant rejection and no SDR production (Marrakchi et al., 7 Jul 2026).
In the multi-protocol scenario with 2, both branches executed independently in every run, branch independence was 100%, composite SIP validity was 100%, and the payload contained two protocol outputs in every case (Marrakchi et al., 7 Jul 2026).
The broader oncology literature illustrates what an ecosystem around such an orchestration framework might contain. CATCH-FM pre-screens cancer risk from longitudinal EHR code sequences and, at 99% specificity, reported sensitivity of approximately 0.737 for pancreatic, 0.690 for liver, and 0.633 for lung cancer with NPV greater than 0.989 (Sun et al., 30 May 2025). A blood-test DES model for lung-cancer detection reached AUC 3 and sensitivity 4, outperforming five pulmonologists by about 8.6 sensitivity points at matched specificity on a 200-sample hold-out comparison (Flyckt et al., 2024). A co-learning pipeline integrating 3D chest CT and clinical demographics reached AUC 0.787 on a hold-out test set, versus 0.635 for clinical-only and 0.687 for image-only models (Wang et al., 2019). Cancer-Answer, using zero-shot prompt engineering on GPT-3.5 Turbo, achieved maximum A1 and A2 values of 0.546 and 0.881 on GI-cancer queries (Deroy et al., 2024). These systems solve different tasks, but collectively they define a plausible component space—risk stratification, radiologic extraction, imaging biomarker generation, multimodal reasoning, and question answering—that an orchestration layer such as LCA is designed to keep modular.
A final misconception is that LCA already constitutes a clinically validated universal oncology assistant. The evidence does not support that reading. The 2026 paper validates routing invariance, failure safety, and execution semantics, and it states future directions such as probabilistic routing validation, additional interpretability branches, protocol extensibility, and downstream EMR translation. The framework’s contribution is therefore infrastructural: it specifies how oncology AI components can be standardized, routed, and isolated from volatile IT and model changes at scale (Marrakchi et al., 7 Jul 2026).