Designing a Clinical Intelligence Layer for Complex Oncology Care: A Reference Architecture Illustrated by Sarcoma and SHAPEHub

Abstract

Background: Healthcare information systems are effective at documenting encounters but remain less capable of representing evolving patient states, coordinating cross-disciplinary decisions, and reconnecting decisions with longitudinal outcomes and value. This Perspective derives a reference architecture for a clinical intelligence layer positioned between source systems and accountable care delivery. Methdology: Using a design-science approach, we combined requirements from learning health systems, semantic interoperability, clinical workflow modelling, value-based healthcare, and the sequence-sensitive characteristics of sarcoma care. We abstracted two complementary cross-domain design patterns—risk-aware common representation and ontology-driven workflow—and translated them into healthcare-specific requirements. Results: The resulting architecture contains seven layers: (1) source integration and provenance; (2) a canonical semantic model; (3) longitudinal patient-state representation; (4) analytics and scenario reasoning; (5) workflow-embedded decision support; (6) outcome and value feedback; and (7) network learning and governance. We additionally specify a minimal formal information model, a bitemporal knowledge-state model distinguishing clinical/effective time from information-availability time, provenance and contradiction semantics, analytic validation gates, and a synthetic architectural verification using four pre-specified patient trajectories comprising 18 synthetic records. All nine pre-specified architectural invariants were satisfied, including correct historical-state reconstruction, preservation of superseded versions, recommendation–patient decision–treatment separation, mixed temporal granularity, and zero retrospective information leakage. Conclusions: SHAPEHub is presented as an implementation-informed sarcoma exemplar rather than as a validated product. The proposed layer is intended to complement—not replace—electronic health records, interoperability standards, common data models, registries, and disease-specific applications. Further technical validation in production-like environments, together with workflow, safety, and clinical validation, remains necessary before claims of utility or transferability can be made.

1. Introduction

Digital medicine has advanced rapidly, but most progress remains layer-specific. Electronic health records (EHRs) digitize documentation; interoperability standards facilitate exchange; common data models support analysis; registries organize disease-specific variables; and artificial intelligence produces an expanding catalogue of predictions. These components are important, yet they do not by themselves create an operational representation of the patient pathway. In complex care, the central unresolved problem is not simply whether data exist, but whether the system can reconstruct what was known at a particular time, which options were considered, why a recommendation was made, whether it was executed, and which patient-relevant outcomes followed [1,2,3,4,5,6].

This gap is particularly consequential in multidisciplinary oncology. A patient may pass through radiology, pathology, surgery, radiation oncology, medical oncology, rehabilitation, surveillance, and palliative care. Source systems typically record local encounters and reports, whereas clinical responsibility is distributed across a longitudinal sequence. The same intervention can have different meaning depending on disease state, prior treatment, knowledge available at the time, anticipated morbidity, patient preference, and the alternatives that remained feasible. Episode-centered documentation therefore preserves events but often loses the decision context required for learning.

The missing capability can be described as a clinical intelligence layer: a semantic, longitudinal, workflow-aware layer that sits above heterogeneous source systems and below accountable clinical action. Its proposed role is not to replace the EHR or automate professional judgement. It is to make the patient pathway visible, measurable, comparable, and governable; to connect state, decision, execution, and outcome; and to preserve the provenance and uncertainty needed for audit. In the terminology developed in our earlier framework refinement, value-based healthcare supplies the goal system, the integrated practice unit supplies an organizational form, the patient pathway becomes the unit of governance, and the clinical intelligence layer supplies the operating architecture [7,8,9,10,11,12,13]. This architectural role complements a recently proposed rare-cancer operating model in which the governed clinical system—not the digital platform—is the primary intervention, while digital infrastructure functions as the instrumentation layer that makes decisions, pathway performance, and learning observable and auditable [14].

Cross-domain platforms offer useful, but deliberately bounded, architectural precedents. BlackRock’s Aladdin illustrates how heterogeneous inputs can be brought into a common, risk-aware representation that supports whole-system state awareness, scenario analysis, and coordinated workflow [15]. Palantir’s Foundry ontology illustrates how domain objects, relationships, permissions, states, and actions can be represented in an operational model rather than left as disconnected records [16]. We use these platforms only as design analogies. They are neither clinical comparators nor evidence of effectiveness, and no product equivalence, endorsement, or technological dependency is implied. Their relevance lies in the abstract principles they expose; healthcare must additionally incorporate clinical accountability, patient preference, consent, safety, outcome and value measurement, and professional responsibility.

The current manuscript reformulates this argument as a biomedical-informatics design contribution. Its objectives are to: (i) define the problem and boundary of a clinical intelligence layer; (ii) derive explicit design requirements; (iii) present a seven-layer reference architecture; (iv) demonstrate its meaning using sarcoma and SHAPEHub; and (v) specify how such an architecture should be evaluated before clinical claims are made. The intended contribution is a testable reference architecture, not a promotional description of a software product.

2. Materials and Methods

2.1. Design Objective and Scope

We treated the clinical intelligence layer as a design-science artefact: a purposeful architecture constructed to address an identified organizational and informatics problem [17,18]. The scope was pathway-level intelligence for complex, longitudinal, multidisciplinary care. The artefact was not intended to define a complete technical implementation, a universal clinical ontology, or an autonomous decision-making system. It specifies logical functions, information objects, boundaries, and evaluation requirements that can be implemented using different technologies.

The unit of analysis is the patient pathway rather than the encounter, document, institution, or isolated prediction. The architecture must represent both clinical state and knowledge state because decisions are made on information available at the time, not on facts learned retrospectively. It must also distinguish recommendation, patient decision, and delivered treatment. This separation is necessary for valid pathway audit, implementation analysis, and later causal inference.

2.2. Conceptual Derivation

The architecture was derived through five design steps aligned with established design-science methodology [17,18]. First, we formulated the problem as a discontinuity between documentation infrastructure and accountable pathway management. Second, we specified objectives from learning-health-system theory, clinical workflow and guideline representation, semantic interoperability, value-based healthcare, and governance [1,2,7,8,19,20]. Third, we abstracted cross-domain patterns from publicly available descriptions of integrated risk and ontology-driven operational platforms [15,16]. Fourth, we translated these patterns into healthcare-specific layers and information objects. Fifth, we used sarcoma care as a stringent domain demonstration and defined an evaluation framework that separates architectural plausibility from empirical validation.

Architecture development was iterative rather than independent of implementation experience. Established informatics concepts and published literature, prior Swiss Sarcoma Network (SSN) pathway and governance work, and practical experience during SHAPEHub (Luzern, Switzerland) development jointly informed the proposed requirements and layer structure. There is partial personnel overlap between the SSN clinical-governance environment and the Shape4PM/SHAPEHub development environment; clinical requirements and implementation experience could therefore inform one another. SHAPEHub is consequently treated as an implementation-informed exemplar and not as independent validation evidence for the reference architecture.

This was a purposive conceptual synthesis rather than a systematic review. Sources were selected to represent foundational design-science methods, learning health systems, interoperability and common data models, computer-interpretable workflow, digital twins, clinical AI evaluation, value-based healthcare, sarcoma pathway governance, and the authors’ prior work. The absence of a systematic search is acknowledged as a limitation; the manuscript’s claims concern architectural coherence and testability, not completeness of the literature.

2.3. Cross-Domain Architectural Antecedents

The cross-domain step was used to make otherwise implicit architectural functions more explicit, not to import the objectives or governance of finance or industrial operations into medicine. We examined public descriptions of two mature platform logics because each addresses a structural problem also encountered in complex healthcare: how to create a coherent representation across heterogeneous sources, and how to connect that representation to accountable workflow and action [15,16]. The analysis was therefore pattern-based rather than product-based.

BlackRock’s Aladdin was used as the antecedent for integrated, risk-aware representation. Its relevant design logic is the construction of a common operating environment in which heterogeneous assets and exposures can be interpreted as parts of a whole system, with shared definitions, state awareness, scenario analysis, and performance attribution [15]. Translated to healthcare, the analogous requirement is not financial risk management but a longitudinal representation in which diseases, interventions, competing risks, functional consequences, and uncertainty can be interpreted across the complete patient pathway rather than within isolated encounters or departmental systems.

Palantir’s Foundry ontology was used as the antecedent for ontology-driven operations. Its relevant design logic is the explicit representation of domain objects, relationships, states, permissions, and actions so that analytics can be embedded within operational workflows rather than remain detached outputs [16]. Translated to healthcare, this supports a model in which patients, tumors, observations, multidisciplinary recommendations, treatment exposures, outcomes, and tasks are represented as auditable objects and state transitions. The healthcare translation is necessarily more restrictive: patient preference, consent, evidence quality, safety, equity, professional responsibility, and clinical override are constitutive requirements. Aladdin and Palantir therefore serve only as conceptual antecedents; they are not compared with SHAPEHub as products and provide no evidence for clinical validity or benefit.

2.4. Requirements Elicitation

Requirements were elicited by triangulating established informatics frameworks, recurrent failure modes in complex clinical pathways, and the sarcoma-stress test (Table 1). The resulting eight requirements are proposed as a candidate minimum set for pathway-level clinical intelligence. They are neither claimed to be exhaustive nor sufficient for every clinical domain; each is instead linked to an identified failure mode, an architectural response, and a pre-specified validation question so that it can be challenged, extended, or falsified during implementation and external evaluation [9,10,12,13,21,22].

Table 1. Requirements traceability matrix for pathway-level clinical intelligence. The requirements are a candidate minimum set and are not claimed to be exhaustive or sufficient for all clinical domains.

Requirement	Evidence/Trigger	Failure Mode	Architectural Response	Validation Question
R1. Semantic continuity [3,4,5,6,19]	Semantic interoperability; FHIR/OMOP; multi-institution data	Equivalent concepts acquire incompatible meanings across systems/sites.	Canonical vendor-neutral representation with explicit mappings, terminology, applicability, versioning, and provenance.	Can clinically equivalent source concepts map reproducibly while preserving source meaning and lineage?
R2. Temporal fidelity [23,24]	Sequence-sensitive oncology; temporal modelling; late-arriving data	Later knowledge leaks retrospectively into earlier decisions or clinically relevant times are conflated.	Separate clinical/effective time, information/availability time, decision time, treatment time, and provenance timestamps.	Can an as-known-then state be reconstructed without future information leakage?
R3. State-dependent meaning [25]	Longitudinal care; state-model/digital-twin concepts	The same code is interpreted identically despite different disease/treatment/care states.	Represent disease, knowledge, treatment, response, recurrence/metastatic, function, symptom, and care-phase states.	Can point events, interval states, and different temporal granularities coexist without collapsing distinct states?
R4. Decision-context preservation [26,27]	MDT/CDS/guideline workflow; auditability	Recommendations are stored without options, evidence, uncertainty, preference, or contemporaneous knowledge.	Represent question, knowledge-state reference, options, evidence, uncertainty, expected benefit/harm, preference, and rationale.	Can the documented decision state reproduce the information and rationale explicitly recorded at the decision?
R5. Recommendation–execution separation [13,14]	Implementation science; real-world treatment exposure	Advice, patient choice, scheduling, and delivered treatment are conflated.	Store recommendation, patient decision, plan, delivery, deviation, and reason as distinct linked objects/states.	Can recommendation, patient choice, delivery, and deviation be reconciled independently?
R6. Workflow embeddedness [3,26,27,28]	SMART/CDS/CIG workflow literature; dashboard failure	Analytics remain detached from accountable workflow.	Integrate case assembly, missingness detection, task logic, action/override, and reassessment into workflow.	Does the architecture support accountable action without excessive burden or false alerts?
R7. Outcome and value closure [1,2,7,14]	VBHC; LHS; PROMs/cost	Outcomes and resource use are detached from the states and decisions that preceded them.	Reconnect outcomes, harms, PROM/PREM, treatment burden, preference, and resource use with explicit denominators and case mix.	Can consequences be linked back to prior pathway states without implying causal attribution by default?
R8. Governed learning [19,29,30]	LHS governance; FAIR/provenance; federated networks	Access, model change, definitions, and institutional responsibility are afterthoughts.	Make provenance, permissions, consent, audit, model/terminology versioning, override, and institutional accountability architectural components.	Can every derived output and change be traced, audited, and governed across institutions?

2.5. Architecture Synthesis and Domain Demonstration

The requirements were grouped into seven logical layers. Layer boundaries were chosen so that source exchange, semantic interpretation, longitudinal state, analytics, workflow action, outcome feedback, and governance could be evaluated independently while remaining connected. Figure 1 positions the proposed layer within the wider information ecosystem. Figure 2 presents the resulting reference architecture. The results further specify a minimal formal information model and bitemporal model (Figure 3) and a worked synthetic sarcoma verification scenario (Figure 4). The core representational and temporal rules were subsequently executed in a minimal technology-agnostic reference implementation using synthetic records, as described in Section 2.7. This verification is independent of the current SHAPEHub implementation and does not constitute clinical validation.

Figure 1. Position of a clinical intelligence layer between heterogeneous source systems and accountable care. The figure locates a clinically accountable intelligence layer that reconstructs pathway state, captures decision context, and reconnects care to outcomes and value. Aladdin and Palantir inform only the abstract design logics of risk-aware common representation and ontology-driven workflow; the figure does not imply product equivalence, endorsement, or comparative validation.

Figure 2. Seven-layer reference architecture. Clinical intelligence requires more than data aggregation: it depends on a canonical semantic model, longitudinal patient-state representation, workflow-embedded decision support, explicit outcome/value feedback, and governed network learning. Security, privacy, provenance, data quality, version control, human accountability, auditability, uncertainty, override logic, and safety monitoring are cross-cutting requirements rather than optional modules.

Figure 3. Minimal formal information and bitemporal model. Source evidence supports versioned clinical assertions that define or update longitudinal patient states and inform decision context, recommendation, patient decision, treatment exposure, and outcomes. Provenance is attached to every assertion and transition. Clinical/effective time records when an assertion pertains to the patient, whereas information-availability time records when that version became available. This separation permits reproducible ‘as-known-then’ and ‘as-known-now’ reconstructions without retrospective information leakage.

Figure 4. Worked synthetic sarcoma verification scenario demonstrating bitemporal reconstruction and version preservation. A reference-pathology result pertains to the Day-8 biopsy but becomes available only after the Day-12 MDT. The historical ‘as-known-then’ view therefore excludes it, whereas the later current view incorporates the updated pathology and revised recommendation while retaining the historical MDT context. This scenario was executed in the technology-agnostic reference implementation as part of the synthetic architectural verification; it does not constitute evidence of current SHAPEHub functionality or clinical validity.

2.6. Evaluation Framework and Claims Boundary

Because a coherent architecture can still fail clinically, we defined evaluation domains before proposing implementation claims. The framework distinguishes technical validity, semantic and temporal fidelity, workflow utility, safety, fairness and equity, patient-centered value, and governance. Fairness is treated first as a system-level property—such as subgroup- or site-specific differences in data completeness, information latency, semantic mapping, pathway access, and workflow uptake—and, if predictive models are introduced, additionally as an algorithmic evaluation problem [31]. The framework also distinguishes staged maturity: documentation, harmonization, workflow awareness, evaluative learning, decision support, and network learning. Failure criteria are pre-specified for semantic fidelity, historical reconstruction, provenance/version preservation, recommendation–execution separation, workflow burden, safety, equity, and transferability. No real-world patient-level data were analyzed for this Perspective. Synthetic records were generated and analyzed solely for architectural verification of the specified information and temporal logic; this verification is not evidence of SHAPEHub clinical validity or production performance.

2.7. Synthetic Architectural Verification

To determine whether the core representational and temporal logic of the proposed architecture was computationally executable, we implemented a minimal technology-agnostic reference model using synthetic event records. The reference implementation did not use SHAPEHub code, production interfaces, or real-world patient data. Each synthetic record contained an object type, concept/value, clinical/effective time, information-availability time, source, temporal precision, version, and, where applicable, relation and decision identifiers.

Four scenarios were specified before execution: (A) a standard chronological pathway; (B) a late-arriving reference-pathology result pertaining to an earlier biopsy and followed by a revised MDT recommendation, patient decision, and treatment exposure; (C) a preliminary pathology assertion superseded by expert review while preserving both versions; and (D) mixed temporal granularity combining date-level outpatient observations with minute-level observations. Across the four trajectories, 18 synthetic records were used.

Nine architectural invariants were tested: chronological reconstruction; exclusion of information not yet available from a historical ‘as-known-then’ view; inclusion of late information in the current view; zero retrospective information leakage; preservation of superseded versions; resolution to the superseding current assertion without deletion of history; separation of recommendation, patient decision, and treatment exposure; preservation of source temporal granularity; and correct application of pre-specified canonical mappings. Expected outputs were defined before execution and compared with reconstructed outputs. The complete synthetic records, pre-specified expected and observed outputs, and minimal reference implementation are provided as Supplementary Files S1–S3. The minimal reference implementation was written in Python 3.13.5. using standard-library data structures.

3. Results

3.1. Problem Formulation: The Missing Operational Layer

The design process identified a recurrent structural discontinuity. Source systems answer “what was documented?”; registries answer “which variables were collected?”; analytic environments answer “what patterns are present?”; and conventional decision-support tools answer a defined prediction or rule question. Complex care additionally requires an answer to “what state was the patient in, what did the team know, what decision was made, how was it implemented, and what happened next?” The clinical intelligence layer is the architecture required to preserve this chain.

This chain is clinically consequential because validity depends on sequence (Figure 2). A pathology result cannot legitimately influence a decision made before the tissue was obtained. A margin cannot be treated as a baseline confounder when it occurs after treatment selection. A surveillance intervention cannot be interpreted without knowing prior recurrence state and treatment reserve. An outcome cannot be attributed to a recommendation if the recommendation was not delivered. A pathway-aware architecture therefore imposes temporal and semantic discipline before advanced analytics are introduced.

3.2. The Seven Layers

3.2.1. Layer 1—Source Integration and Provenance

The first layer ingests or references data from EHRs, radiology, pathology, operative systems, radiation and systemic therapy systems, multidisciplinary meeting documentation, PROM/PREM platforms, administrative records, and cost systems. FHIR can provide a standards-based exchange interface, while local adapters remain necessary when source systems are proprietary or structurally heterogeneous [3,5]. The essential requirement is not maximal ingestion, but faithful reconstruction of the pathway with source lineage, timestamps, transformation rules, uncertainty, and original temporal precision preserved.

A production architecture should separate identifiers and clinical content according to purpose and access. Direct identifiers may remain within an institutional clinical zone, whereas pseudonymized longitudinal data can support quality assessment and approved analytics. Data minimization, consent or other lawful basis, retention, and export controls must be specified for each processing purpose rather than assumed globally.

3.2.2. Layer 2—Canonical Semantic Model

The canonical semantic model is specified as a minimal formal information model rather than a universal clinical ontology. It separates source observations or documents, versioned clinical assertions, longitudinal patient states, decision context, recommendation, patient decision, treatment exposure, outcome/burden, and provenance. FHIR resources and the OMOP Common Data Model offer important exchange and analytical structures, but neither automatically supplies the complete disease-specific pathway and decision semantics required for multidisciplinary decision governance [3,4,5,6]. The clinical intelligence layer therefore maps external standards into a canonical core while preserving the ability to exchange or analyze data through those standards.

A source observation or document should not be silently promoted to immutable clinical truth. Instead, it supports one or more versioned assertions carrying clinical status, uncertainty, valid time, availability time, verification state, source, responsible human or software agent, and transformation or model version. Assertions may refine, contradict, or supersede one another without erasing historical versions. These provenance requirements are compatible with FHIR Provenance concepts, while clinically explicit contradiction and supersession semantics are specified at the canonical layer [29,30]. A field that is not applicable remains distinct from a missing value; a suspected diagnosis remains distinct from a confirmed diagnosis; and an MDT recommendation remains distinct from delivered care.

3.2.3. Layer 3—Longitudinal Patient-State Representation

The third layer represents the patient as a trajectory rather than a static row. Relevant state dimensions include disease state, knowledge state, treatment state, response state, recurrence or metastatic phenotype, functional state, symptom burden, and care phase. We distinguish the system-available knowledge state K(t)—the set of versioned assertions available through the relevant clinical information environment by time t—from the documented decision knowledge state KD(t,d), the subset explicitly presented, cited, discussed, or captured in association with decision d. KD(t,d) is therefore a subset of K(t). Neither state is equivalent to what an individual clinician actually noticed, understood, remembered, or believed; clinician cognition should not be inferred solely from EHR availability.

Longitudinal representation uses a clinically adapted bitemporal model, drawing on the established distinction between valid time and transaction time in temporal information systems [23]. For clinically consequential assertions, the architecture operationalizes this distinction as clinical/effective time and information-availability time. FHIR Observation provides an analogous distinction between the clinically relevant effective time and issued, the time at which that version became available to providers [29]. It permits an ‘as-known-now’ reconstruction that incorporates subsequent evidence and an ‘as-known-then’ reconstruction restricted to information available at a specified historical decision time. Late-arriving information may revise the current interpretation of an earlier event, but it must not leak retrospectively into an earlier decision context.

The architecture preserves source temporal granularity rather than forcing all data onto a single time scale. Point events, interval states, date-only records, and high-frequency observations may coexist; aggregation or down-sampling creates derived views while source precision and provenance remain traceable. This allows, for example, a pathology report linked to a specimen event, sparse outpatient PROM observations, and higher-frequency perioperative data to contribute to the same longitudinal pathway without implying equivalent sampling frequency.

3.2.4. Layer 4—Analytics and Scenario Reasoning

Layer 4 separates analytic functions by inferential target rather than by computational technique. Descriptive reconstruction asks what occurred; prediction estimates the probability of future outcomes conditional on observed information; causal analysis estimates contrasts between intervention strategies under explicit identifying assumptions; and simulation generates trajectories under a specified structural model. These outputs are not interchangeable. Prediction performance does not establish causal validity, and a patient-specific simulation does not become a clinically credible digital twin merely because it is individualized. Each mode therefore advances through a distinct validation gate before it can influence care [8,13,20,25].

Scenario reasoning should remain bounded (Table 2). Predictive models require pre-specified outcomes and horizons, calibration, external or temporal validation, subgroup performance assessment, transportability evaluation, and drift monitoring [32,33]. Causal analyses require an explicit estimand, time zero, intervention strategies, and a bias-control plan consistent with target-trial principles [34]. Simulation requires verified implementation, context-of-use validation, and uncertainty quantification. Workflow decision support additionally requires human-factors evaluation, override logic, safety monitoring, and prospective or silent-mode evaluation proportionate to clinical influence [8].

Table 2. Analytic modes and minimum validation gates before clinical influence.

Mode	Question	Typical Output	Minimum Gate
Descriptive/reconstruction	What was documented, when, and what pathway/state sequence occurred?	Timeline, completeness, conformance, observed distributions	Mapping and temporal fidelity; provenance; missingness; reproducible reconstruction.
Predictive	What is likely to occur for this patient or state?	Risk/probability or predicted trajectory	Pre-specified outcome/horizon; discrimination and calibration; external/temporal validation; subgroup performance; transportability; drift monitoring.
Causal estimation	What would differ under intervention strategy A versus B?	Causal contrast/treatment-effect estimand	Explicit estimand and time zero; intervention strategies; confounding assumptions; positivity/consistency; sensitivity/bias-control plan.
Simulation/digital twin	What trajectories are generated under specified modelled scenarios?	Simulated states or outcomes	Verified implementation; validated structural assumptions for context of use; uncertainty quantification; prospective comparison when clinically consequential.
Workflow decision support	What information or action should be surfaced at a real decision?	Alert, option display, missingness prompt, bounded recommendation	Upstream semantic/temporal validity; human-factors/usability testing; override logic; safety monitoring; controlled prospective evaluation where appropriate.

3.2.5. Layer 5—Workflow-Embedded Decision Support

The fifth layer converts representation into accountable workflow. Initial functions are deliberately prosaic: assembling the complete case for an MDT, identifying critical missing information, displaying the current state and prior sequence, capturing the indication and alternatives, and reconciling recommendation with execution. These functions may create more value and less risk than introducing an opaque prediction model prematurely.

A structured decision object should include the clinical question, intended failure mode to be modified, disease and patient context, options considered, evidence and uncertainty, expected absolute benefit and harm, functional and treatment-burden implications, patient preference, recommendation strength, responsible team, and planned reassessment. The system should support legitimate disagreement and override. Its role is to make reasoning traceable, not to force consensus.

3.2.6. Layer 6—Outcome and Value Feedback

The sixth layer closes the loop between prior decisions and observed consequences. Outcomes include survival, recurrence, metastatic progression, toxicity, complications, function, quality of life, symptoms, patient experience, utilization, and episode cost. Value-based healthcare is therefore the goal system, not an isolated dashboard module [7,9]. Patient-centered value should be represented as a multidimensional profile rather than assumed to be a universal scalar: disease control or survival, function, quality of life and symptoms, toxicity and complications, treatment burden, patient preference, and resource use or cost remain distinct but linkable dimensions. When these dimensions conflict, the system should expose the trade-off and uncertainty rather than apply an implicit weighting scheme. If a composite utility or value score is later used, its weighting method, perspective, time horizon, and role of patient preferences must be explicit and separately validated.

Feedback must not collapse into performance ranking. Observed differences may reflect selection, referral, biology, documentation, access, treatment delivery, or surveillance. The platform should support drill-down to case context, explicit ‘not applicable’ logic, and explanation rather than reward simplistic league tables. Outcome feedback becomes clinically useful when it identifies where a pathway may have deviated, which patient group may be underserved, and which uncertainty should become the next learning question.

Valid outcome feedback therefore requires explicit denominators, applicability rules, capture-completeness disclosure, case-mix and complexity stratification, and balancing measures; otherwise, an intelligence layer risks producing “dashboard medicine” rather than valid learning [14]. Equity should also be monitored at the information-system level. Candidate signals include subgroup- and site-specific differences in data completeness, information latency, semantic mapping fidelity, pathway access, workflow uptake, and recommendation–execution divergence. If predictive or decision-support models are introduced, calibration and task-relevant error rates should additionally be assessed across pre-specified clinically relevant subgroups and institutions.

3.2.7. Layer 7—Network Learning and Governance

The final layer supports learning across institutions while preserving local accountability and data sovereignty. A federated-by-default model allows approved analyses to be brought to harmonized local data, with movement of patient-level data treated as an explicit exception. Governance must define controller and processor roles from actual decision-making, not labels; separate scientific priority, data access, technology operation, funding, and publication decisions; and maintain audit trails for access, transformation, model versions, outputs, and overrides.

Governance is part of model validity. Ontologies encode which objects exist, metrics encode what counts as success, and workflow rules allocate power. Changes to these components require clinical, methodological, patient, legal, and institutional oversight proportionate to their influence. The stronger the system’s role in decision-making, the stronger the requirements for validation, surveillance, incident response, portability, and independent review.

At the operating-system level, this governance can be expressed as a closed-loop cycle of capture, harmonization, benchmarking, learning, authorized implementation, and re-measurement, with explicit ownership, validity gates, and escalation mechanisms [14]. Fairness and equity are governance responsibilities rather than properties delegated solely to an algorithm. Unequal data visibility, delayed information availability, differential access to specialist review, or unequal uptake of an intelligence-layer function can produce inequity even when no predictive model is used. Governance should therefore review subgroup and institutional signals together with case mix, denominator integrity, uncertainty, and potential remediation rather than infer unfairness from an isolated metric.

3.3. Core Information Objects and State Transitions

The architecture becomes implementable when each layer is grounded in explicit information objects. Table 3 provides a minimum conceptual set. These objects are not intended to replace existing standards or constitute a universal ontology; they identify pathway semantics that an implementation must preserve. Figure 3 summarizes the relationship between source evidence, versioned assertions, patient states, decision and treatment objects, outcomes, provenance, and bitemporal reconstruction.

Table 3. Minimum conceptual information model for pathway-level clinical intelligence.

Object	Minimum Attributes	Core Relations	Purpose
Patient/care context	Patient pseudonym; institution; care team; consent/authority; relevant baseline context	has_disease; has_episode; participates_in_decision	Defines whose pathway is represented and under which governance context.
Clinical event	Event type; valid/event time; source; location; temporal precision	produces_observation; triggers_state_transition	Separates point events from persistent states.
Observation/document	Content; source; author/performer; effective time; issued/available time; version	supports_assertion; generated_by	Preserves source evidence rather than treating extracted facts as source-free truth.
Clinical assertion	Concept; value; status; uncertainty; valid time; availability time; verification state	supported_by; contradicts; refines; supersedes	Allows provisional, conflicting, and later-corrected information to coexist with full traceability.
Patient state	State type; start/end interval; certainty; derivation	derived_from_assertion; prior_state; next_state	Represents disease, knowledge, treatment, response, recurrence, function, symptoms, and care phase.
Decision context	Clinical question; K(t)/KD(t,d) reference; options; evidence; uncertainty; preference; rationale	informed_by; considers_option; results_in_recommendation	Preserves the contemporaneous documented decision context.
Recommendation	Option; strength; intended benefit/failure mode; team; reassessment rule	accepted_by/rejected_by; planned_as	Keeps expert recommendation separate from patient choice.
Patient decision	Choice; consent/refusal; preference; time	responds_to_recommendation; leads_to_plan	Separates informed choice from MDT advice.
Treatment exposure	Modality; intent; timing; delivered dose/intensity; completion; deviation; reason	implements; deviates_from; precedes_outcome	Captures what was actually delivered.
Outcome/burden	Survival/recurrence; toxicity; function; PROM/PREM; treatment burden; utilization; cost	follows_state; follows_exposure; evaluated_against_decision	Closes the loop without implying causal attribution by default.
Provenance/governance	Source ID; transformation/model version; agent; access; audit; override	was_derived_from; generated_by; attributed_to; supersedes	Makes every derived representation traceable and reviewable.

3.4. Sarcoma and SHAPEHub as an Implementation-Informed Exemplar

Sarcoma is an unusually demanding demonstration domain. It comprises many rare entities with different biological behavior, requires specialist pathology and imaging, and often depends on the sequence of biopsy, staging, MDT review, surgery, radiotherapy, systemic therapy, surveillance, and recurrence management. Early deviations can constrain later options and affect local control, metastatic risk, function, toxicity, and cost [9,10,12,13,21,22]. No single institution can rely on volume alone, which increases the need for harmonized network learning.

Within this domain, SHAPEHub can be described as an implementation-informed exemplar of the reference architecture. Its intended role is to connect structured and unstructured clinical data, a canonical sarcoma model, longitudinal pathway states, MDT workflow, outcome and PROM collection, resource use, and governed network analysis. The architecture and implementation experience developed iteratively rather than independently: established informatics concepts, published SSN pathway/governance work, and practical SHAPEHub development informed one another. Because there is partial personnel overlap between the SSN clinical-governance environment and the Shape4PM/SHAPEHub development environment, SHAPEHub cannot serve as independent validation evidence for the architecture. Its clinical utility, safety, cost-effectiveness, and transportability remain to be tested independently.

A minimum sarcoma implementation would be expected to represent suspicion and referral, imaging before biopsy, biopsy planning and execution, expert pathology review, pretreatment MDT discussion, treatment intent and anticipated margin, delivered surgery and pathological margin, radiation and systemic therapy exposure, recurrence and metastatic phenotype, functional and patient-reported outcomes, and follow-up state. It should explicitly distinguish anticipated from achieved margin, de novo from metachronous metastasis, and recommendation from delivery. These distinctions are proposed as prerequisites for valid pathway quality assessment and later comparative analyses rather than as currently validated SHAPEHub capabilities.

3.5. Staged Evaluation and Maturity Model

A clinical intelligence system should advance through maturity stages rather than be declared “intelligent” on the basis of integration or a model demonstration (Table 4). The evaluation sequence begins with semantic, temporal, and provenance validity, proceeds through workflow usefulness and safety, and only then tests decision and patient impact. DECIDE-AI and related evaluation principles are relevant when algorithmic decision support is introduced, but non-AI workflow functions also require human-factors and implementation evaluation [8].

Table 4. Staged maturity and evaluation model. Advancement should be gated by evidence from the preceding stage.

Maturity Stage	Principal Capability	Minimum Evaluation Questions
0. Documentation baseline	Source systems and narrative records	Map current data flows, duplication, latency, missingness, temporal precision, and governance gaps.
1. Harmonized pathway model	Canonical variables, provenance, terminology, and longitudinal event/state reconstruction	Concept coverage; mapping accuracy; temporal fidelity, including information-availability time; historical-view retrieval; retrospective leakage; contradiction/version preservation.
2. Workflow-aware platform	MDT case assembly, missingness alerts, state timeline, recommendation–execution reconciliation	Case-preparation time; clinician workload; usability; alert precision; unresolved missingness; adoption and override reasons.
3. Evaluative learning system	Outcome/PROM/value feedback and pathway comparison	Denominator integrity; follow-up completeness; case-mix handling; subgroup/site equity signals; interpretability; unintended metric effects.
4. Decision-support system	Calibrated prediction or option comparison in silent mode, then assisted use	Calibration/validation; subgroup performance; transportability; human factors; safety events; decision concordance; prospective utility.
5. Network intelligence	Federated multi-institution learning and monitored model updating	Cross-site semantic consistency; privacy and access audit; model drift; update governance; portability; equitable benefit sharing.

3.6. Synthetic Architectural Verification

All nine pre-specified architectural invariants were satisfied across the four synthetic trajectories (Table 5). The standard pathway was reconstructed in the expected clinical order. In the late-arriving pathology scenario illustrated in Figure 4, the expert pathology result pertaining to the Day-8 biopsy was absent from the Day-12 historical ‘as-known-then’ state because it did not become available until later, but it was present in the subsequent current view. No future information appeared in an earlier historical state, corresponding to zero observed retrospective information leakage in the pre-specified scenarios.

Table 5. Results of the synthetic architectural verification. Passing a criterion indicates that the minimal reference implementation reproduced the pre-specified expected behavior under controlled synthetic conditions; it does not constitute clinical validation.

Verification Criterion	Expected Behavior	Observed Result
Chronological pathway reconstruction	Correct clinical/effective-time sequence	Passed
Historical “as-known-then” reconstruction	Late information excluded before availability	Passed
Current-view update	Late information included after availability	Passed
Retrospective information leakage	0	0 observed
Version preservation/supersession	Earlier and revised versions retained	Passed
Current assertion resolution	Superseding version current; history preserved	Passed
Recommendation–patient decision–treatment separation	Distinct objects retained	Passed
Mixed temporal granularity	Source precision retained	Passed
Canonical mapping fidelity	18/18 mappings correct	18/18

In the supersession scenario, both the preliminary and expert pathology assertions remained retrievable, while the expert assertion resolved as the current version through an explicit supersession relation rather than deletion of the earlier record. Recommendation, patient decision, and treatment exposure remained separate objects. Date-level and minute-level observations retained their original temporal precision. All 18 pre-specified synthetic records mapped to their intended canonical concepts. These results demonstrate that the specified information and temporal logic are computationally executable under controlled synthetic conditions. They do not establish semantic validity on real clinical data, workflow utility, clinical safety, generalizability, patient benefit, or production performance of SHAPEHub.

4. Discussion

4.1. Principal Contribution

The principal contribution is not the novelty of each constituent layer. FHIR/SMART provides mature exchange and application-integration mechanisms; OMOP provides a standardized observational data model and analytic ecosystem; computer-interpretable guideline frameworks formalize decision logic and workflow; digital-twin frameworks emphasize dynamic state representation and simulation; and Learning Health System frameworks define socio-technical cycles from data to knowledge to performance. The proposed contribution is their pathway-centered integration around a set of explicit requirements that are not consistently co-specified across these frameworks: bitemporal reconstruction of what was known when a decision was made, preservation of decision context and uncertainty, separation of recommendation from patient choice and delivered treatment, reconnection of decisions to longitudinal outcomes and value, and governance of provenance, versioning, access, and learning. The architecture is therefore presented as complementary rather than superior to existing standards and frameworks.

The architecture also clarifies what a clinical intelligence system is not. It is not synonymous with an EHR, a common data model, a registry, a business-intelligence dashboard, an AI model, or a digital twin. Each can be a component. The defining property is the governed integration of longitudinal representation, accountable workflow, and feedback. This distinction is important because the term “platform” can conceal very different levels of semantic and clinical maturity. The present reference architecture and the previously described rare-cancer operating model address different but interdependent levels of the same system. The operating model specifies how a governed network converts measurement into authorized pathway change and re-measurement, whereas the present architecture specifies the semantic, longitudinal, analytical, and workflow capabilities required from the digital intelligence layer that supports that process [14]. Whether this integration provides incremental value over a materially simpler stack is an empirical question rather than an assumed property.

The cross-domain antecedents sharpen this distinction. Aladdin contributes the abstract idea of a shared, risk-aware representation through which heterogeneous elements can be interpreted within a common system state; Palantir contributes the ontology-driven bridge from representation to permissions, workflow, and action [15,16]. The proposed clinical intelligence layer combines these principles but changes their normative center: the object is the patient pathway, the optimization target is patient-centered value rather than portfolio return or operational throughput, and every action remains bounded by consent, evidence, uncertainty, safety, auditability, and professional accountability. These analogies support architectural derivation only and do not constitute product comparison, endorsement, or validation.

4.2. Relationship to Existing Informatics Categories

Existing informatics frameworks address substantial parts of the problem, but their primary design purposes differ (Table 6). FHIR supports standardized exchange, and SMART on FHIR supports substitutable applications, but interoperability does not by itself define disease-specific pathway semantics [3,5]. OMOP standardizes observational data for reproducible multi-database analyses but is not primarily a real-time multidisciplinary workflow model [4,6]. Computer-interpretable guideline and decision-support models can formalize temporal logic, decisions, workflow, exceptions, and execution [26,27], whereas Learning Health System frameworks emphasize the socio-technical cycle linking data, knowledge, implementation, and governance.

Table 6. Functional comparison with adjacent informatics frameworks. “Not intrinsic” means not a required or primary design function; it does not imply that the framework cannot be extended to support the function.

Framework/Family	Established Strengths	Functions not Intrinsic/Uniformly Specified	Relationship to Proposed Layer
FHIR + SMART/CDS Hooks [3,5,28]	Standards-based exchange; reusable resources/APIs; app launch/authorization; workflow-triggered CDS can be integrated.	Disease-specific canonical pathway model, historical decision-time knowledge state, recommendation–execution semantics, and value/learning governance are not intrinsic.	Exchange and application-integration substrate for the proposed layer.
OMOP/OHDSI [4,6]	Standardized observational data structure, vocabularies, and reproducible multi-database analytics.	Live multidisciplinary workflow, MDT decision objects, patient preference, and as-known-at-decision reconstruction are not primary design functions.	Analytic/network-research substrate; selected data may map into/out of OMOP.
Computer-interpretable guidelines/CDS [26,27]	Formal clinical knowledge, temporal logic, decision rules, workflow, exception handling, and execution.	Complete longitudinal outcome/value closure and multi-institution pathway governance are variable rather than constitutive.	Strong overlap with Layers 4–5, embedded within broader state/outcome/governance architecture.
Medical digital twins [25]	Dynamic patient/system representation; model updating; prediction/simulation in stronger definitions.	Historical decision-context reconstruction, recommendation–execution separation, and governance/value are not consistently mandatory.	Potential downstream capability once state estimation, simulation, uncertainty, and validation are sufficient.
Learning Health Systems [1,2]	Socio-technical learning cycles linking data, knowledge, implementation, re-measurement, communities, and governance.	Usually less prescriptive about patient-level canonical objects, bitemporal knowledge state, or explicit MDT recommendation–execution semantics.	The proposed layer is an informatics/operational substrate for pathway-level LHS functions; it does not replace the LHS.
Proposed architecture	Pathway-centered source provenance, canonical semantics, longitudinal state, bounded analytics, workflow support, outcome/value feedback, and network governance.	Not clinically or externally validated; no claim of superiority, completeness, or universal transferability.	Incremental hypothesis: co-specification of bitemporal decision context, recommendation–execution separation, outcome/value closure, and governed learning may improve pathway intelligence.

Digital-twin concepts emphasize dynamic state and simulation [25]. The proposed architecture provides prerequisites for such work but intentionally avoids labelling every longitudinal representation a digital twin. A clinically credible digital twin would require validated state estimation, explicit intervention or scenario models, quantified uncertainty, a defined context of use, and prospective evaluation. Similarly, a predictive model embedded in the architecture remains a prediction model; connectivity to workflow does not by itself establish clinical utility.

4.3. Why Sarcoma Is a Stringent Stress-Test Domain

Sarcoma concentrates the structural difficulties that increasingly characterize modern medicine: rarity, heterogeneous biology, specialist interpretation, path dependence, treatment sequencing, distributed expertise, and trade-offs between disease control, function, toxicity, quality of life, and cost. This makes it a high-resolution test of whether an architecture can preserve context rather than merely aggregate data. Success in sarcoma would not by itself demonstrate generalizability, but failure to preserve these sequence-sensitive distinctions would challenge the adequacy of the architecture even within its motivating domain.

Adaptation to other rare cancers, multimodal oncology, transplantation, complex inflammatory disease, or longitudinal chronic care is a hypothesis requiring external evaluation. Transfer should be assessed at the level of the proposed stable architectural core while disease objects, states, decision rules, outcomes, and governance are adapted locally. Generalizability should therefore be tested through semantic portability, historical-state fidelity, workflow fit, and independent implementation rather than inferred from literal replication of a sarcoma data dictionary.

4.4. Risks and Design Constraints

The first risk is false precision. Rich data and polished interfaces can create confidence that exceeds the evidence. Every analytic output should expose uncertainty, applicability, missingness, and validation state. The second risk is encoded power. Ontologies determine which states and outcomes are visible; metrics determine what is rewarded; and workflow rules determine who can act. These design choices require governance and the ability to contest or revise them. A related equity risk arises when some patient groups or institutions are systematically less visible because data arrive later, map less reliably, or are less completely captured. Such system-level inequity can occur before any AI model is introduced. A third risk is metric gaming. When pathway indicators become targets, documentation may improve without care improving, or institutions may avoid difficult patients. A fourth risk is automation overreach. The architecture should operate as a co-pilot and learning substrate, not an opaque decider. A fifth risk is vendor or model lock-in. Canonical definitions, mappings, and export mechanisms should be portable, and institutions should retain access to their data and audit history if a supplier exits.

Privacy and cybersecurity risks increase with the power of the integration layer. Role-based access, least privilege, pseudonymization, key management, encryption, logging, incident response, retention, and processor governance are not peripheral technical details. They define whether a platform is trustworthy enough to enter clinical workflow. Jurisdiction-specific legal and ethical review remains necessary.

4.5. Limitations

This Perspective remains primarily a reference-architecture study. It does not report a systematic review, formal ontology validation, usability testing, a production implementation of the proposed bitemporal timeline, prospective implementation, or patient outcomes. Requirements were influenced by sarcoma, prior SSN work, and practical SHAPEHub development, which may overemphasize rare-cancer and multidisciplinary-network needs. The partial overlap in personnel between the SSN clinical-governance environment and the Shape4PM/SHAPEHub development environment, together with the authors’ disclosed governance and/or financial relationships, creates a potential for favorable framing and means that SHAPEHub cannot be treated as independent validation evidence. We therefore restrict claims to design intent, make development provenance explicit, pre-specify validation and falsification criteria, and identify independent external evaluation as a necessary future step.

A further limitation is that the seven layers are logical rather than necessarily deployable as separate software components. Implementations may combine layers or distribute them across systems. The requirements set is a candidate minimum rather than an exhaustive ontology of clinical intelligence. The synthetic architectural verification demonstrates executability of selected architectural invariants under controlled conditions, but it does not establish semantic validity on real clinical data, workflow utility, safety, generalizability, patient benefit, or production performance. The architecture will be useful only if independent teams can map their designs to it, identify missing functions, reconstruct historical decision states reproducibly, and determine whether the proposed distinctions improve semantic fidelity, workflow, safety, equity, and patient-relevant outcomes.

4.6. Implementation and Research Agenda

The most credible implementation sequence begins with a limited canonical core and user-centered stabilization of the longitudinal workflow, not with advanced AI. The present synthetic verification addresses only the executability of selected information and temporal invariants. The next validation stage should test mapping reliability, temporal accuracy, historical-state retrieval, critical missingness, contradiction/version preservation, and recommendation–execution concordance against independently reviewed clinical records and in production-like technical environments. The acceptance criterion for retrospective information leakage should remain zero. Mixed temporal granularity and late-arriving information should be included explicitly in these tests.

Only after these foundations are stable should outcome feedback and comparative analytics be introduced. Prediction models should undergo external or temporal validation, calibration assessment, subgroup analysis, and prospective silent-mode testing. Causal analyses should pre-specify estimands and target-trial components rather than infer treatment effects from descriptive dashboards. Decision-support studies should predefine intended users, decisions, failure modes, override pathways, and safety monitoring [8]. Network deployment should test semantic consistency, federated analysis, data sovereignty, subgroup/site equity, and whether institutional variation reflects care, case mix, access, or measurement. Patient representatives should participate in outcome selection, preference capture, interface design, governance, and evaluation.

For SHAPEHub specifically, the next scientific milestone should be an openly described and sufficiently stable minimum information model, followed by the technical validation sequence above and then prospective user/workflow evaluation. Independent evaluation will be particularly important given the partial SSN–Shape4PM personnel overlap. Evidence against the architecture would include failure to preserve clinically distinct semantics, inability to reconstruct a historical decision-time knowledge state without retrospective leakage, loss of provenance or prior versions, inability to distinguish recommendation from patient choice and delivered care, or failure to maintain comparable meaning across institutions. Its incremental-utility hypothesis would also be challenged if a materially simpler baseline stack achieved equivalent or better pre-specified pathway-reconstruction and workflow outcomes with lower burden, complexity, or risk.

5. Conclusions

Healthcare has mature systems for documentation and growing capabilities in prediction, but complex care still lacks a consistently specified, clinically accountable layer that links longitudinal patient state, multidisciplinary reasoning, treatment execution, outcomes, value, and network learning. This Perspective proposes a seven-part reference architecture and makes its burden of proof explicit through requirements traceability, a minimal formal information model, bitemporal decision-context reconstruction, analytic validation gates, and a controlled synthetic architectural verification.

Sarcoma provides a rigorous stress-test domain, and SHAPEHub provides one implementation-informed exemplar rather than validation evidence. The architecture is intentionally technology-agnostic and is designed to complement EHRs, interoperability standards, common data models, registries, clinical decision-support tools, and analytic environments. Its governing triad is unchanged: patient value becomes the mission, the patient pathway becomes the unit of governance, and clinical intelligence becomes the operating layer. Whether this integration is technically robust, transferable, safe, and incrementally useful compared with simpler existing stacks must now be determined empirically.