Haptic medicine

Physical feedback, with clear boundaries.

Different hardware provides different feedback. Wearable vibration and force resistance require distinct simulation contracts.

bHaptics integration installed · physical output and advanced hardware unverified

Discuss your use case Explore the complexes

01 / Simulation architecture

Four levels of interaction.

The hardware roadmap moves from headset and controller cues to wearables, gloves and procedure-specific force peripherals.

01 Headset and controller feedback
02 Wearable body haptics
03 Advanced haptic gloves
04 Specialist force-feedback peripherals

02 / Simulation architecture

Feedback needs a meaningful source.

A cue should be driven by a known simulation event. Advanced applications may include instrument contact, palpation or procedural resistance after a suitable model and hardware are developed.

Recorded event-to-device mappings
Device-specific calibration
Explicit separation of vibration and force feedback

03 / Simulation architecture

A validation pathway.

No clinically validated force simulation is claimed. Each procedure, device and feedback model needs its own evaluation.

Hardware behavior and repeatability
Biomechanical and sensory model validation
Expert assessment of training relevance

A clear development boundary

Orthopedics is the initial prototype focus. Specialty scope, advanced physiology, institutional authoring and multiplayer describe the platform direction. No clinical validation or regulatory approval is claimed.

See what exists today

Architecture in context

Equipment needs a simulation contract.

Device state, contact events and authorized procedures must provide a meaningful source for physical feedback. The explorer below is an illustrative interface, with no device connection.

Concept studyFunctional device concept · planned integration

MEDIVERSE / MONITORP-001 · Synthetic

Synthetic observation feed

Heart rate: 92bpm
SpO₂: 97%
Respiratory rate: 18/min

Synthetic timeline14:02

Device / Patient monitor

Observations with a patient context.

A planned monitor is intended to read the patient's physiological state, with trends and alarms that have a simulation context.

The website readouts share the fixed synthetic timeline. Alarm logic and physiological coupling are planned.

This is a website concept explorer. It does not control a patient or medical device.

Questions for an evaluation

Scope the model before deployment.

Define the clinical task, available hardware, intended learners and required evidence before deciding which capabilities belong in an institutional evaluation.

01Can multiple clinicians train together?

Mixed human and AI teamwork is part of the design. A synchronized multiplayer experience is planned; the current prototype provides shared-backend foundations rather than a completed multi-user product.

02Can hospitals create custom scenarios?

Educator authoring is planned for patients, conditions, objectives, teams, complications and rubrics. It is intended to reduce reliance on Unreal source changes, but a production authoring interface is not yet available.

03Can AESORYX run privately or on-premises?

Local inference is used in the current prototype. Private cloud and on-premises delivery are deployment directions to assess with institutions; a production deployment package has not been established.

04Is AESORYX clinically validated or a medical device?

No clinical validation, regulatory approval or clinical decision-support status is claimed. The current work is a simulation prototype. Clinical judgment, patient care and regulated device use require separate governance and evidence.

For institutions building what comes next

Build the next generation
of medical simulation.

Start with your specialty, your team and a concrete learning or research objective.

Request a demo Contact AESORYX