MEDTECH
Understand the patient and device state.
During the treatment session.
Xpdeep models make evolving patient and device-state estimates structurally understandable and report when the current case leaves known conditions. Where relevant, a separate inference can propose a feasible adjustment under stated constraints. The clinician or authorized device system determines the action.
THE CLINICIAN OR AUTHORIZED DEVICE SYSTEM DETERMINES THE ACTION
01 PATIENT / DEVICE STATE
A treatment session is not one data point.
Its state evolves minute by minute.
Medical devices generate temporal signals that reflect both the patient state and the machine state.
Xpdeep can read which variables, temporal windows and signal morphology carry the model output.
ILLUSTRATIVE · SYNTHETIC SESSION SIGNALS
- MULTIVARIATE SESSION SIGNALS
- STRUCTURAL READING
- CURRENT STATE ESTIMATE
An explained estimate gives the clinician or authorized device system an inspectable view of state during the session.
02 DOMAIN
A clinical or device model should know
when the current case has moved
beyond what it learned.
Xpdeep can expose not only that the model has moved outside its trained domain, but which variables and temporal patterns drove that departure, whether the case remains inside known conditions.
TECHNICAL BOUNDARY: Domain information is a decision input, not clinical authorization. The clinician or authorized device system determines the action inside and outside the learned domain.
03 FEASIBLE ADJUSTMENT · WHERE RELEVANT
Where relevant, a feasible adjustment
under the device’s constraints.
On supported time-series and tabular models, a separate inference can compute a minimal feasible parameter change under stated constraints, with the structural justification of its predicted effect. The clinician or authorized device system acts according to the manufacturer’s validated rules.
IMPORTANT BOUNDARY
Structural, not automatically causal.
Minimal means minimal feasible under the specified constraints and optimization procedure, not a unique global optimum.
04 PROGRAMME EVIDENCE · SESSION-BASED TREATMENT DEVICE
A patient-state profile
you can inspect during the session.
DATA
Real session data read minute by minute from a treatment device.
MODELS
Two models built on real session data: one made patient-state profiles structurally understandable; the other computed feasible device-parameter interventions and explained their predicted effect.
PLATFORM
Core model capabilities used in the programme are live.
Decisions remain with the clinician or the authorized device system. These results do not establish clinical effectiveness, improved patient outcomes, regulatory approval, production deployment or authorized autonomous device operation.
05 DEVICE INTEGRATION
The model can become part of the device
without becoming a black box.
- DEVICE SIGNALS
- XPDEEP MODEL
- PREDICTION + EXPLANATION + DOMAIN STATE
- DEVICE / CLINICIAN DECISION
WHERE APPLICABLE ON TEMPORAL / TABULAR STAGES → CONSTRAINED INTERVENTION → STRUCTURAL JUSTIFICATION
POTENTIAL VALUE SURFACES
- Explained adjustments during the session
- Explained device-adjustment inputs
- Device-function differentiation
- Intelligence that can be integrated across the installed base
- Customer-defined clinical or device KPIs
EMBEDDED
The intelligence can travel with the device.
The same model architecture can be deployed in cloud, on-premises or embedded environments. Each target requires adaptation, profiling and integration; deployed configurations need not generate explanations at runtime.
- Prediction, with explanation where retained.
- Where relevant: domain state.
- Where relevant: prescriptive output on temporal / tabular stages.
- Controlled model evolution under the manufacturer’s change control.
POTENTIAL ECONOMIC SURFACE: Intelligence that can be integrated across the installed base.
CLINICAL, ENGINEERING AND REGULATORY VALIDATION
What the manufacturer validates, and where the evidence stands.
RELEVANT DATA AND MODEL TYPES
- Physiological time series and treatment-session signals
- Device-state and machine-parameter data
- Relevant tabular clinical data
- Separately, learned image and video models where applicable (no image-level prescription)
WHAT THE CUSTOMER MEASURES OR VALIDATES
- Model behaviour under its design controls and risk management
- Clinical evaluation, verification and validation
- Its regulatory and certification path
- Device integration and any model change under its change control
PUBLISHABLE EVIDENCE AND MATURITY
- PROGRAMME RESULT
- Two models built on real treatment-session data: patient-state estimation, and explained device-parameter adjustment.
- NOT CLAIMED
- Clinical effectiveness, regulatory approval, production deployment, improved patient outcomes or authorized autonomous device operation.
MedTech engineering boundaries.
EXPAND
- Clinician or authorized device-system control applies inside and outside the learned domain.
- Prescription applies to temporal and tabular stages; image-level prescription not available; under study.
- “Explainable abstention” is not a live capability.
- Structural integration requires read access to the PyTorch architecture and weights, or a Native model.
- The customer’s surrounding system defines and authorizes actions.
- Attributed domain state covers the retained model inputs; alone, it does not authorize action or establish system safety.
- Structural justification does not automatically establish physical causality.
- Minimal means minimal feasible under the stated constraints and optimization procedure.
- Targeted editing and controlled correction require Native mode.
- Regulatory approval, clinical validation and certification remain with the customer and relevant authorities.
- Reduced requalification scope requires application-specific evidence and acceptance.
START WITH ONE FUNDED MEDTECH PROBLEM
Start with a patient-state, device-state
or treatment-function problem.
PATIENT STATE
A temporal model tied to session or physiological state
DEVICE STATE
A learned model tied to equipment or treatment behaviour
TREATMENT FUNCTION
A device function that depends on a better-characterized state or a constrained adjustment
EMBEDDED MODEL
A model intended to run on the device or across the installed base
Agree a clinical, product or engineering success criterion at scoping.
Phase 1 is a funded engagement, typically three to six months, on a consequential model, decision, function or programme you have prioritized. Agree the economic, operational, quality, mission, product or assurance success criterion at scoping; work on your data within your engineering environment and constraints.
Xpdeep supplies model-level technology and repeatable software deployment, not a replacement engineering lifecycle. Your teams and implementation partners can integrate and validate the model using your own tools and test processes.
01 →
One funded problem
A model, engineering problem, product function, subsystem or decision the business already owns.
02 →
Agreed criterion
Data, duration, success criterion and validation method defined at scoping.
03 →
Evidence on your application
Results assessed through the customer’s validation process; a side-by-side model comparison is one possible method.
04
Define the extension
Identify the possible Phase 2 scope at the start; use Phase 1 evidence to determine its scope.