An ecosystem by Gatai Inc.
AESORYX / MediVerseSimulation · Education · ResearchGatai Inc. ↗
Gatai Inc. / AESORYX / MediVerse

Enter a hospital that remembers.

MediVerse is the application at the center of AESORYX: a persistent medical world where simulated patients, teams, facilities and equipment share one continuing context.

In development · Orthopedics is the initial prototype focus. Other complexes and advanced capabilities are planned.

Discuss your use case Explore the complexes
MEDIVERSE / WORLD MODEL Persistent architecture
CARE TEAMCLINICAL INTAKECONTINUING PATIENT
01 / Connected hospitalConcept visualization
PATIENT MV–001Identity stays. Care evolves.
AssessmentTreatmentRecovery
Beyond an isolated encounter

A patient's story can continue.

The intended experience begins with a person, carries their history through care and returns to them over time. Persistent case state exists in the prototype; autonomous hospital activity and complete longitudinal workflows remain development work.

01 / Simulation architecture

A place with operational state

Patient locations, beds, appointments, staff, investigations and equipment belong to the same world model. A transfer or handover should have a recorded context.

  • Connected departments and resources
  • Versioned actions and event history
  • Queues, shifts and institutional operations planned
02 / Simulation architecture

People with responsibilities

Doctors, nurses, technicians, patients and relatives inhabit the world with different roles and access to information. A conversation does not grant universal knowledge.

  • Persistent identity and relevant memory
  • Assigned-patient context
  • Professional hierarchy and role boundaries
03 / Simulation architecture

Care that has a consequence

Important actions must be checked by authoritative simulation logic. The complete device and physiology models are intended to make consequences traceable and suitable for evaluation.

  • Intent → validation → recorded action
  • One patient across specialties
  • Explicit limits on current clinical fidelity
Architecture in context

Explore the connected hospital.

Select a department to see how its work contributes to the same patient's continuing record. This is a facility concept, not a product capture.

Concept studyMediVerse · connected facility schematic
6 connected hospital departments. Select a department below to explore its planned workflow.CONNECTED CARE / SHARED PATIENT IDENTITYN
Department 01

Emergency

Arrival → assessment

Triage, observation and escalation connect the arrival of a patient with the next appropriate team.

Care teams · assessment spaces · handovers

Illustrative layout. Department workflows are part of the planned specialty complex architecture.

Architecture in context

One patient. Several specialties.

An illustrative hip-fracture journey may also involve diabetes, atrial fibrillation, heart failure, anticoagulation, osteoporosis or kidney disease. The design treats these as one person's connected context.

Concept studyThree interconnected twins · planned architecture
Human physiology: Cardiovascular, Respiratory, Metabolic, Neurological, Musculoskeletal, Renal connect to patient state.CardiovascularRespiratoryMetabolicNeurologicalMusculoskeletalRenalTWIN / 01PATIENT STATEState → observation → consequence
Layer 01

One connected human state.

The planned physiological twin connects body systems, injury, disease and recovery. Observations are intended to follow the simulated patient state.

All three layers refer to the same persistent patient and medical world.

Planned multidisciplinary pathway

Orthopedics · Internal medicine · Cardiology · Anesthesiology · Nursing · Radiology · Laboratory medicine · Pharmacy · Physiotherapy · Rehabilitation
Longitudinal care

From arrival to the next encounter.

The same simulated identity is intended to travel through prehospital care, assessment, investigation, treatment, recovery and follow-up. Select a stage to explore the proposed pathway.

Concept studyIllustrative patient pathway · planned longitudinal continuity
Encounter 01 / Same patient identity

Home / accident

A patient story begins before arrival.

Continuing record
Identity, history and circumstances
Connected team
Patient · relatives
1 of 16
Continuity across time

Leave the encounter. Return to the person.

The following story illustrates the intended persistent experience. It does not claim that every phase is implemented in the current prototype.

01 / Simulation architecture

First encounter

A patient arrives after an accident. The team records an assessment, requests imaging and coordinates specialist review within a shared clinical context.

  • History and findings
  • Investigation requests
  • Assigned care team
02 / Simulation architecture

Continuing admission

A later session can return to the same identity and recorded decisions. The roadmap adds ongoing investigations, changing clinical state and cross-shift activity.

  • Pending work and handovers
  • Patient and family conversations
  • Treatment and recovery context
03 / Simulation architecture

Recovery and follow-up

The intended journey continues into mobility, rehabilitation and another encounter. The patient retains a story rather than becoming a new scenario instance.

  • Function and recovery goals
  • Longitudinal observations
  • Linked follow-up encounters
Architecture in context

An intelligent medical population.

Explore the roles that shape what a person knows, which task they can undertake and when they should involve another team.

Concept studyIntelligent population · planned role and permission model
Persistent identity / Clinical

Nurse

Permitted context
Assigned patients, recorded observations and the nursing care context.
Role-specific task
Observe, record and hand over changes in the patient's condition.
Communication & escalation
Escalate concerns to the appropriate clinician.
A person inhabits a role, a care team and a continuing world. This explorer demonstrates the architecture; it is not a live AI conversation.
Functional equipment

A device should participate in care.

The planned device layer connects monitors, ventilators, defibrillators, infusion pumps, anesthesia equipment and diagnostic workflows with modeled patient state. Equipment geometry alone does not establish this behavior.

Concept studyFunctional device concept · planned integration
MEDIVERSE / MONITORP-001 · Synthetic
Synthetic observation feed
Decorative synthetic waveform, not an ECG interpretation.
Heart rate
92bpm
SpO₂
97%
Respiratory rate
18/min
ILLUSTRATIVE INTERFACE / NO DEVICE CONNECTION
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.

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
Events make the environment matter

A world with work in progress.

Institutional events are intended to connect operational and clinical state. The roadmap includes ambulance arrivals, available beds, completed results, shift changes, transfers, equipment alarms and deterioration events.

01 / Simulation architecture

Immersive interaction

Desktop and Unreal Engine XR environments present the same simulation context. Input should serve the task, with device-specific testing and accessible alternatives.

  • Spatial interaction and selected grab objects
  • Hand and controller foundations
  • Body and gaze interfaces planned
02 / Simulation architecture

Team-based medicine

Human participants and AI colleagues are intended to coordinate around the same patient. Shared-backend checks exist; synchronized multiplayer is planned.

  • Role-specific responsibility
  • Clinical handover and escalation
  • Shared situational awareness
03 / Simulation architecture

Learning from the record

The proposed review layer connects conversations, decisions, observations and consequences with educational objectives.

  • Recognition and intervention timing
  • Communication and safety checks
  • Instructor rubrics and assessment validation
The application, clearly explained

MediVerse questions.

01What is AESORYX?

AESORYX is the product ecosystem of Gatai Inc. (g-atai.com), encompassing MediVerse, a persistent medical-world application. The platform is currently in development, with an orthopedic prototype as its initial focus.

02What is MediVerse?

MediVerse is the application through which users enter the simulated medical world. Its intended architecture connects patients, intelligent people, facilities, functional devices and clinical workflows.

03What is an Intelligent Logic Twin?

It is the operational model of the medical world: people, patient locations, resources, permissions, orders and events. It determines what is happening and which actions may change state.

04What 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.

05How does AI medical simulation work?

An agent receives role-appropriate context and can explain or propose an action. Authoritative simulation logic validates important actions before they alter patient state. Conversation alone does not commit a clinical intervention.

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

07Which specialties does MediVerse support?

Orthopedics is the initial prototype focus. This site describes the planned scope of 26 Specialty Complexes. A specialty page is a design scope, not a claim that the entire complex is operational.

08Does 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.

09Does 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.

10How are simulated patients generated?

The design combines identity, history, conditions, risk factors, physiology and communication context. Broad generative patient authoring is planned and should preserve internal clinical consistency.

11Does a patient persist between sessions?

Persistent case state is present in the development backend. A continuously evolving institution, cross-session social continuity and the complete longitudinal care journey are being developed.

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

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

14Is 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.

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