Walking One Protocol End to End: RMP-RENAL-001 Kidney Ultrasound Assist

Why walk one protocol

Part 1 asked whether a humanoid robot could ever be a medical crewmember, and sketched a 13-part framework for protocols a robot could learn [9]. The library now holds dozens of conceptual drafts written in that format, each checked against a published schema [2].

This Part 2 follows one of them from start to finish: RMP-RENAL-001, Assisted diagnostic ultrasound for a suspected kidney stone (v0.7, AI-assisted clinical and source review on the protocol itself; conceptual; not for clinical use) [1]. The same protocol drives the ground flight surgeon live console simulation [10].

Kidney stone risk rises in flight, and ultrasound is the imaging available on board [7]. The protocol’s job is narrow: help humans get labeled kidney and bladder views into the medical record for a human to read. Everything else stays with people.

The cast: who decides what

On commercial flights, “flight surgeon” and “CMO” mean the operator’s designated medical authority and trained onboard responder. If no trained responder is aboard, this protocol is not used [1]. NASA programs plan for two CMOs per vehicle [3].

Communication delay: decide before you scan

After the crew confirms position (step S1), decision D1 asks: Is the delay Mars-class, or the link down? [1]

• No → live guidance from the flight surgeon is allowed (typical low Earth orbit case).
• Yes → no real-time guidance. The CMO follows the onboard checklist; images are store-and-forward only [1].

Mars one-way delay can reach about 21–23 minutes, with blackouts of about 2–3 weeks possible around solar conjunction [6]. That is why thresholds marked <set by clinical lead> or <set by validation> must be filled before flight, not improvised mid-scan [1][2].

You can feel the timing difference in the console by switching station, Moon and Mars delay presets [10].

Preconditions (nothing moves until these are true)

Encoded as preconditions with machine-checkable fields where possible [1][2]:

1. PRE-1 — A crewmember started the run (human_start == true) [V2 10174] [4].
2. PRE-2 — Patient consent recorded (voice or touch), logged.
3. PRE-3 — CMO present and able to take over [V2 10168], [V2 10164].
4. PRE-4 — Patient, caregiver and robot restrained [V2 7046].
5. PRE-5 — Ultrasound and gel checked; robot self-test passed [V2 10161].
6. PRE-6 — Link check: flight surgeon agrees, or link down / delay too long and the CMO proceeds under the checklist.

Consent also has an emergency path (CMO + flight surgeon decision, logged) and a withdrawal path: patient says stop → stop, retract probe, alert CMO [1].

Step-by-step: what the robot does

Actors in the YAML are crew, robot or ground [1].

Language the robot is allowed to use: “non-diagnostic”, “images acquired, for human review”, “flagged for human review”. Never: “normal”, “no stone”, “all clear”, “no problem found”, “negative”, or any diagnosis [1]. Ultrasound can miss ureteral stones; CT is the Earth reference test and is not available in flight [7].

What the robot must never do (lockouts)

Most of these are encoded in the YAML as fixed_rules / robot_lockouts and also appear in the library’s shared safety rules; the therapeutic-ultrasound ban is set through roles.robot_may_not and scope.locked_out rather than a lockout key of its own [1][11]:

• Never diagnose.
• Never give drug or fluid advice (no forced fluids for acute colic; treatment is a human decision) [1][7].
• Never start, stop or adjust oxygen or any medicine.
• Never self-start or self-restart.
• Never change its own protocol thresholds or limits.
• Never hand over a mismatched supply item as “verified”.
• Never use therapeutic ultrasound modes (stone propulsion and related methods are investigational and locked out of scope) [1][7].

Scope also locks out needle or nephrostomy guidance. An infected, blocked kidney needs urgent drainage plus antibiotics on Earth; from low Earth orbit that means planning evacuation — the flight surgeon decides, not the robot [1][8][3].

Failure modes and red flags

Stop rules (stop_rules in the YAML) fire mid-protocol [1]:

Red flags (red_flags) escalate to an URGENT flight-surgeon call — fever/unstable vitals, very low urine output, single kidney or bilateral swelling (human judgment), uncontrolled pain or vomiting, dipstick nitrites/leukocytes with symptoms, rising creatinine where measurable [1][8]. Thresholds marked <set by clinical lead> are intentional blanks until a human owner fills them [2].

“Mismatch” in the wider library usually means a supply or barcode check failed (see pharmacy protocols). In RENAL-001 the closest cousins are failed preconditions, failed image-quality gates (D2), and failed delivery (D4): the robot does not invent a workaround that skips the human [1].

Consent, privacy and the medical record

• Consent is a precondition; withdrawal is a stop rule [1].
• Images and logs are private medical data, encrypted, limited to the medical team [V1 6003], [V1 7003] [3].
• Every input, action, decision (with who decided) and hand-off is time-stamped [V2 10163], [V2 10164] [4].
• Mode changes and safety-limit events are announced as they happen [V2 10162].

That is deliberate: a delayed flight surgeon should be able to reconstruct the run without trusting the robot’s summary language.

How the YAML and schema encode the checks

The downloadable file is rmp-renal-001.yaml, validated against the schema (schema_version: 0.3) at build time [1][2]. Useful fields for readers of the file:

• max_autonomy: 2 — supervised rung ceiling [12].
• fixed_rules / robot_lockouts / result_language — hard behavioral limits, not prose footnotes.
• preconditions[].check — example: human_start == true.
• steps[], decisions[], stop_rules[], red_flags[] — ordered, IDed, with actor / decided_by / level.
• safety_limits[] — probe force, speed, session time, delay limit for live guidance (values set in validation).
• comms.loss_of_signal / comms.mars_delay — same X5/D1 policy in structured form.
• validation[] — simulation → training model → Earth analog → flight demonstration, each with pass criteria set in advance.
• change_control — new version numbers, re-validation after patient-touching changes, rollback; the robot never edits itself.
• signoff.each_run — flight surgeon when the link allows; otherwise CMO under checklist with later review.

If a field required by the schema is missing, the site build fails. That is the point of a robot-readable protocol: humans and machines share one source of truth.

Try the same run as a simulation

Open the ground console, pick a delay profile, and step through RMP-RENAL-001 as if you were the flight surgeon [10]. The 3D scene and command log are educational fiction; they exist to make delay and hand-offs visible, not to train clinical practice.

Where this sits in the library

• Full protocol page: RMP-RENAL-001 [1]
• Schema: protocol schema [2]
• Shared safety rules [11]
• Capabilities board (ultrasound assist sits under supervised imaging) [12]
• Clinical background: Kidney stone risk, Point-of-care ultrasound
• Series hub: Robotic and autonomous medical care

What comes next

• Part 3 (published): Testing robot care in simulation and Earth analogs, and who signs off — the validation ladder behind the YAML validation[] / signoff fields, analog limits and rung-by-rung approval.
• Part 4 (published): Walking RMP-PHARM-001 — barcode check, mismatch quarantine and logged two-step CMO override, always conceptual.
• Part 5 (published): Contingency AGI autonomy (2027–2033) — fallback rungs 4–5 when human support is unavailable or insufficient; this RENAL walk stays at supervised rung 2.
• Later: deeper walks of other published drafts (for example crew-held probe variants), always conceptual.

The earlier plan that called Part 2 “format and validation” alone is outdated: the schema and library already carry that format. This Part 2 uses the format by walking a live library entry instead; Part 3 explains how that format would be tested and signed off.