AESORYX / Development status

A clear boundary between prototype and direction.

This page describes the present development foundation and the work still needed for the broader MediVerse vision. Product diagrams explain architecture; they are not evidence of clinical validation.

Initial orthopedic prototype · wider specialty platform in development

Discuss your use case Explore the complexes

Current scope

What has been built. What needs evaluation.

The website is independent of the simulation runtime. Its interactive illustrations use concept graphics and synthetic data rather than live patients or a production medical system.

Current MediVerse development status and limits
Capability	Status	Boundary
Orthopedic clinical backend	Prototype	Persistent synthetic case state, versioned actions and role checks. One hip-fracture workflow is implemented; the wider case catalog is scope, not a completed clinical engine.
Immersive medical environment	Prototype	A fresh Unreal Engine 5.8 project contains a connected city and three hospital campuses. Selected equipment has grab components; this does not establish procedural behavior.
Intelligent people	Prototype	Ten people are connected to a route and dialogue foundation. Navigation has runtime diagnostics; comprehensive crowd behavior, scheduling and clinical task execution still need development.
Local AI and dialogue	Prototype	Local inference, role-appropriate context and dialogue speech synthesis have been exercised. Streaming speech input, lip synchronization, visual perception and broad multilingual orchestration remain planned.
Hand and controller interaction	Foundation	Meta XR and interaction components are integrated. Connected-device calibration and physical hand/controller tests remain necessary.
Haptic feedback	Unverified hardware	bHaptics integration is installed. Physical output, advanced gloves and procedure-specific force feedback have not been validated.
Multi-system physiology	Planned	Current clinical values and mechanics are synthetic proxies. Connected cardiovascular, respiratory, renal, metabolic and other system models require implementation and evaluation.
Functional medical devices	Planned	Equipment controls, alarms and readings are intended to communicate with modeled patient state. Visual assets are not evidence of a complete device model.
Specialty Complexes	Scope defined	Orthopedics is the initial focus. The catalog describes additional specialties and workflows without claiming their full implementation.
Multiplayer and institutional tooling	Planned	Shared-backend foundations exist. Synchronized participants, educator authoring, institutional administration and production deployment require further work.
Clinical and educational evidence	To be established	No clinical validation, regulated medical-device status, institutional adoption or improved patient outcomes are claimed.

01 / Simulation architecture

Technical verification

Compile, integration and local runtime checks establish specific behavior under test. They do not establish suitability for a clinical procedure or all connected hardware.

State and authorization checks
Actual movement and device checks
Failure handling and reproducibility

02 / Simulation architecture

Purpose-specific validation

Define the intended lesson, workflow or research use before choosing a fidelity target. Patient models, procedural interactions and assessment tools each need appropriate review.

Model and hardware assumptions
Expert clinical and educational review
Measured task-specific outcomes

03 / Simulation architecture

Institutional readiness

An institutional deployment requires more than a local prototype. Infrastructure, governance, security, support and evaluation arrangements must be established.

Deployment and data-access decisions
Operational support and resilience
Defined use boundaries

Questions about scope

Discuss the capability you actually need.

01What is a physiological twin?

It is a computational representation of a simulated patient’s connected physiological and clinical state. The current prototype uses synthetic orthopedic proxies; multi-system and clinically validated models are future work.

02Can 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.

03Does MediVerse support haptics?

The prototype includes an installed bHaptics integration and an XR interaction foundation. Physical device output, advanced gloves and force-feedback procedures require integration and validation. Vibration is not force feedback.

04Does MediVerse simulate medical devices?

Functional medical devices are part of the roadmap. The intended device layer connects controls, alarms and readings to modeled patient state. Existing equipment visuals do not establish device behavior or clinical fidelity.

05Can 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.

06Is 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