Could a Humanoid Robot Be a Medical Crewmember? A Thought Experiment

Why this matters

Crew time is scarce. Astronauts’ days are tightly scheduled. NASA built its station robots partly to take over simple tasks that “require a great deal of crew time” [6] and so crews can spend less time on routine chores [7].

Missions are getting longer and farther away. The station is due to retire around 2030, with commercial stations planned to follow [19]. Missions to the Moon and Mars will last months to years.

Distance changes how care works. Today’s approach on the space station is to stabilize a seriously ill crewmember and bring them home [10]. NASA’s standard requires evacuation to be available when a problem is beyond onboard care [3]. Farther out, that stops being realistic:

• Signal delay. On a crewed Mars mission, a one-way radio signal can take more than 20 minutes (NASA: up to 21–23 minutes), with the longest delays while the crew is at Mars. There can also be communication blackouts of about 2–3 weeks in NASA’s example missions [1]. When the planets are closest, the delay is about 3 minutes one way: the closest distance is about 54.6 million km [32], divided by the speed of light, which is the method NASA’s fact sheet uses [1].
• No quick ride home. NASA lists distance from Earth as one of the five hazards of human spaceflight [2].
• More onboard care. NASA-STD-3001 already says onboard medical capability must be sized to mission length and return time [3]. A robot is one possible way to add skilled hands without adding crew.

What has already flown or been tested

Only verified precedents are listed. None of these robots treated a patient.

What these tell us. Robots can work alongside crews in weightlessness. Ground experts can guide non-experts, and remote control works over short delays. Software alone has guided untrained crew through kidney and bladder ultrasound without help from the ground [25], which is the closest real precedent to the example protocol below. Medical tasks with robots have only been shown on models and simulators.

A ladder of capability

A widely cited framework for medical robots describes six levels of autonomy, from 0 (no autonomy) to 5 (full autonomy). The levels in between are robot assistance, task autonomy, conditional autonomy and high autonomy [14]. For spaceflight we use three practical rungs. The higher levels are out of scope here.

What a robot might do at each rung (a thought experiment, not a recommendation). A shorter, scannable version for nine care domains is on the capabilities board:

Why first response is hard in weightlessness. A European guideline for cardiopulmonary resuscitation (CPR) in microgravity recommends a specific body position for immediate chest compressions. When the patient is restrained on the station’s medical restraint system, it recommends a “handstand” position. It also advises airway management only when at least two rescuers are present and the patient is restrained [15]. NASA requires equipment to restrain the patient, the caregiver and supplies [4]. That guideline is written for human rescuers only. We found no flight or analog study of chest compressions given by a robot (our search was not exhaustive), and compression force conflicts with the low force limits a care robot would need for patient contact. A robot that can anchor itself might one day help hold a patient steady, but that idea is speculative and untested.

Why the humanoid shape fits, and where it falls short

Why a human-like body fits. Spacecraft are built for human hands and bodies: handrails, hatches, switches, drawers, medical kits. NASA started Robonaut so that a robot could help astronauts where “another pair of hands would be helpful,” or do jobs too dangerous or too routine for crew [6]. NASA’s standard even notes that hatches may be designed to let robots move through while still fitting crew [4]. A humanoid robot can, in principle, use the same tools, kits and restraints as the crew, without a second set of equipment.

The limits.

• Dexterity and touch. Ultrasound, wound care and surgery rely on fine control and a sense of pressure. Surgical skill in reduced gravity is largely unaffected provided the operator, patient and instruments are restrained [10]. Autonomous surgery has been shown only in animals on Earth [30], and a 2026 review says robotic autonomy has not reached the point where systems can make independent decisions without operator control [10].
• Reliability. There is no repair shop on the way to Mars. Robonaut 2 stopped working after its 2014 leg upgrade. A wiring fault proved very difficult to repair in orbit, and the robot was returned to Earth in 2018 for repair [24]. Reviews of space surgery call for systems that are compact, multifunctional, adaptable and reliable [10] [17].
• Mass, volume and power. Every kilogram and watt is budgeted. Size, weight and power are major barriers for space surgical systems [10]. A humanoid robot is far heavier than a 2-pound surgical robot.
• Failure modes. A robot can freeze, misread a scene or act on a bad sensor. NASA requires the human to be able to take over safely, and requires the robot to stay safe if no one does [4].
• Skill loss and over-trust. Higher automation can improve routine performance but worsen performance when the automation fails, and reduce awareness of what is happening [16]. NASA’s standard warns about this trade-off and the loss of crew skills [4].
• Sterility and containment. Fluids and debris behave differently in weightlessness, and a 2026 review says the means of containing them must be planned for in space surgery; it also notes that blood tends to stay at the wound, so fluid management may be less difficult than once expected [10]. A robot also has to be cleaned and kept from carrying germs between tasks.

How this changes with each kind of mission

Human, ethical and regulatory questions

• Who decides. NASA’s standard says the human operator has ultimate authority and should remain in command, able to override or shut down the robot [4]. NASA medical operations already set out who has authority for care and evacuation decisions [18]. A care robot has to fit into that chain of command, not create a new one.
• Liability. Under the Outer Space Treaty, countries are internationally responsible for national activities in space, including those of private companies, and must authorize and supervise them [22]. We found no law or rule that settles who is liable if a care robot harms a patient in space: the operator, the robot maker, the software developer, the supervising clinician or the crew. The 1972 Liability Convention does not help here: it does not apply to damage a launching country’s space object causes to that country’s own nationals, or to foreign nationals taking part in operating it (Article VII) [31]. Injuries to crew therefore fall outside it.
• Consent. FAA rules require operators to tell spaceflight participants in writing about known and unknown risks of launch and reentry, and that the U.S. Government has not certified the vehicle as safe [21]. Those rules do not address consent to robotic medical care. Consent would need to cover which tasks the robot may do, at what autonomy level, and what happens if the patient cannot consent.
• Crew trust. NASA requires decision aids to explain their reasoning, show the consequences of actions and say when a problem is beyond them. The goal is trust that matches what the system can really do [4]. Trust has to be earned in training, not assumed on the day of an emergency.
• Privacy of medical data. A care robot is a moving camera and sensor platform. NASA treats medical communications as private and requires secure handling of medical records [3]. Recordings from a robot need the same protection, and rules on who may review them.
• Who regulates.
  • NASA sets health and design requirements for its own programs (NASA-STD-3001). These are not regulations for commercial flights.
  • The FAA (Federal Aviation Administration) licenses launch and reentry. Congress currently bars it from regulating the safety of people on board, except in limited cases, until January 1, 2028 [20].
  • The FDA (U.S. Food and Drug Administration) regulates medical devices on Earth. It has guidance on planned updates to AI-enabled device software (a “predetermined change control plan”) [23], which matters for robots that learn. We found no FDA framework written specifically for medical devices or robots used in spaceflight.
  • Plainly: today, no rule set covers a robot giving medical care in space. Programs would rely on their own standards, contracts and consent processes.

Toward protocols robots can learn

Later articles in this series will write protocols that a robot can learn from, follow and be audited against. Here is the framework they will use. NASA’s Section 10.6 rules give a starting point: they are general automation requirements, not medical-device or patient-contact requirements, and they do not address whether a treatment works, patient-contact force or sterility [4].

What a robot-readable clinical protocol needs

1. Identity and scope. Name, version, intended mission types, the conditions it covers, and the highest autonomy rung it allows.
2. Roles. Who holds medical authority (the flight surgeon on the ground; the crew medical officer acts under delegated care [18]), who leads on board, who supervises, and what the robot may and may not do. This follows NASA’s requirement that the system make clear whether the human or the machine is expected to act at each moment [4].
3. Preconditions. Consent recorded, patient and robot restrained, equipment checked, communications status known.
4. Required sensor inputs. What the robot must sense before and during each step (for example camera view, probe position and contact force, vital signs from the telemetry stream). The protocol also says what to do if an input is missing or out of range.
5. Structured steps. Short, numbered, machine-checkable actions with clear success criteria. Free-text judgment calls are kept for humans.
6. Decision points. Explicit branches (if this, then that), each tagged with who decides: robot, crew or ground.
7. Stop and escalate rules. Conditions that force a pause, a hand-back to a human, or an urgent call to the ground. These include “the patient says stop,” pain, unstable vital signs, loss of communications and the robot’s own faults. They match NASA’s requirements for safe mode, failure recovery and decision aids that admit their limits [4].
8. Safety limits. Hard limits on force, speed, reach and duration that the robot cannot exceed. NASA’s standard asks for internal checks against excessive speed, force and torque [4].
9. Logs and audit. Every input, decision, action and hand-off is time-stamped and kept, shared with crew and ground, and protected as medical data [4] [3].
10. Links to requirements. Each rule cites the NASA-STD-3001 requirement it serves (see the “Requirements referenced” box below), so reviewers can trace the protocol to the standard.
11. Validation. The protocol is tested first in simulation, then on training models and in Earth analogs (such as undersea habitats [13]), then in parabolic flight or on a station. Each stage has pass and fail criteria set in advance.
12. Human sign-off levels. Who must approve the protocol before use (clinical lead, flight surgeon or medical authority, safety board, program), and who must approve each run at each autonomy rung. Restarting after an emergency stop is always a human decision [4].
13. Change control for learning. How the robot’s skills may be updated after deployment, what must be re-validated, and how to roll back. The FDA’s change-control approach for AI-enabled devices is one model to borrow from [23].

Example skeleton (conceptual, not for clinical use)

protocol: RMP-RENAL-001            # library ID; first published as ASSIST-US-RENAL-001
title: Assist with diagnostic ultrasound for a suspected kidney stone
version: 0.2-conceptual            # NOT FOR CLINICAL USE
max_autonomy: rung-2               # supervised: human starts, watches, can stop
scope: diagnostic imaging only
  # LOCKED OUT: ultrasonic stone propulsion, burst-wave lithotripsy, and needle
  # or nephrostomy guidance. These are investigational and out of scope.
roles:
  medical_authority: flight surgeon (ground)
    # the crew medical officer (CMO) acts under delegated care
  lead_onboard: crew medical officer
  robot: position and hold probe; capture and label images; never diagnoses;
         gives no treatment, fluid or medication advice
treatment:                         # decided by humans only, never by the robot
  - pain relief (anti-inflammatory first), anti-nausea medicine, tamsulosin:
    decided by the CMO and flight surgeon
  - no forced or high-volume fluids for acute colic
preconditions:
  - patient consent recorded (voice or touch confirmation, logged)
  - if the patient cannot consent: proceed only on a CMO and flight surgeon
    emergency decision, logged
  - CMO present and able to take over at any moment     # [V2 10168] [V2 10164]
  - patient, caregiver and robot restrained             # [V2 7046]
  - ultrasound and gel checked; robot self-test passed   # status per [V2 10161]
  - link check: flight surgeon agrees to this run, OR link down / delay too
    long -> CMO proceeds under the pre-approved onboard checklist
inputs_required:
  - ultrasound image stream (quality score)
  - probe position and contact force
  - patient vital signs (heart rate, blood pressure, temperature)
  - urine output and urine dipstick result   # entered by CMO; robot records only
  - communications status and current delay
safety_limits:
  probe_force_max: <set by validation>
  probe_speed_max: <set by validation>
  session_time_max: <set by validation>
  delay_max_for_live_guidance: <set by validation>
steps:
  1: confirm patient position and expose scan areas
  2: right kidney views -> auto-check image quality
  3: left kidney, same views as right for side-by-side comparison
  4: bladder views, including the ureteral jet on each side
  5: optional color Doppler "twinkle" views
     # twinkle may be harder to see at high cabin CO2 (animal data only)
  6: label images, attach to medical record (secured per [V1 7003]);
     send to flight surgeon live, or store-and-forward if no link
decision_points:
  - image quality low after <N> attempts -> hand probe control to CMO or ground
  - collecting system looks swollen (possible blockage) -> flag for human
    review; robot does not interpret
  - scan without findings -> report "non-diagnostic", never "normal" or "no stone"
    # ultrasound can miss stones in the ureter, and swelling may not show yet
    # early in a blockage. CT is the reference test on Earth but is not
    # available in flight.
  - Mars-class delay -> no real-time guidance; onboard checklist plus
    store-and-forward only
stop_and_escalate:
  - patient says stop, or pain increases  -> stop, retract probe, alert CMO
  - temperature >= <set by clinical lead>, shaking chills or unstable vitals
                                          -> stop; URGENT call to flight surgeon
    # Suspected infected, blocked kidney: needs urgent drainage plus
    # antibiotics. From low Earth orbit this means planning evacuation to
    # definitive care [V1 3007]. Onboard drainage (nephrostomy) is not an
    # established capability. The flight surgeon decides antibiotics and
    # evacuation; the robot does not.
  - no or very low urine output                     -> URGENT call to flight surgeon
  - known single kidney, or swelling on both sides
    (as judged by a human reviewer)                 -> URGENT call to flight surgeon
  - pain or vomiting not controlled by onboard medicines -> URGENT call
  - dipstick positive for nitrite or leukocytes, with symptoms -> URGENT call
  - rising creatinine, where it can be measured     -> URGENT call
  - loss of link, or delay > <set by validation>
                -> robot holds safe state; CMO decides whether to continue
                   under the onboard checklist; log for flight surgeon
                   # [V2 10172] [V2 10173]
  - force or speed limit reached        -> protective stop        # [V2 10172]
  - robot fault or human override       -> safe state; human restart only
                                     # [V2 10165] [V2 10168] [V2 10173] [V2 10174]
  - CMO asked to take over but does not respond (for example, the CMO is the
    patient) -> robot stays in safe state; the next named crewmember answers
                                     # [V2 10173] [V2 7045]
logging:
  - all inputs, actions, decisions and hand-offs, time-stamped   # [V2 10163]
  - stored and sent as private medical data                      # [V1 6003] [V1 7003]
validation_before_use:
  - simulation -> ultrasound training model -> analog crew -> flight demo
sign_off:
  protocol: clinical lead + flight surgeon (medical authority) + safety board
  each_run: flight surgeon agreement when the link allows; otherwise the CMO
            under the pre-approved onboard checklist, with flight surgeon
            review of images and logs at the next contact

Where the clinical content comes from: medical authority and the crew medical officer’s role follow NASA’s medical operations brief [18]. The imaging steps, the limits of ultrasound, the lack of CT in flight, onboard urine dipstick testing, and evacuation rather than onboard nephrostomy from low Earth orbit follow NASA’s 2024 renal stone evidence report [26]. Urgent drainage of an infected, blocked kidney follows European urology guidelines [27]. Ultrasonic stone propulsion is still in clinical trials [28] [26]. Forced fluids have no reliable evidence of benefit in acute colic [29]. The safe-default rules cite NASA-STD-3001 Volume 2 [V2 10172], [V2 10173] and [V2 10174] [4].

Full protocol page: this example now has its own page in the protocol library, RMP-RENAL-001, written in the full 13-part format with a step-by-step view and a downloadable YAML file checked against the protocol schema. Eleven more draft protocols use the same format; see the library.

Try it: the ground flight surgeon live console runs this example protocol as a simulation, at station, Moon and Mars communication delays (simulated data; not for clinical use).

Why an infected, blocked kidney is an emergency, and how kidney stones are handled in spaceflight: see Kidney stone risk and Point-of-care ultrasound.

What comes next in this series

• Part 2: a full protocol format, with machine-readable fields and validation criteria.
• Part 3: a first set of protocols (restraint and CPR support, assisted ultrasound, wound care), each traced to NASA-STD-3001 and current clinical guidance.
• Part 4: how to test robot care in simulation and Earth analogs, and who signs off at each autonomy rung.

See the series hub for updates, and the protocol library for the full list of planned protocols, organized by body system.