RMP-EGR-001 Medical evacuation preparation: package records, images and logs for handover

1 · Identity and scope

After the flight surgeon (or the CMO under the onboard checklist) decides on a medical evacuation, the robot alerts the flight surgeon that preparation has started, builds a hand-over package from the recorded entries only, laid out in the SBAR order (Situation, Background, Assessment, Recommendation) with the assessment and recommendation quoted from the CMO and flight surgeon, shows it to the CMO for read-back, brings the transfer kit by a checked kit fetch, clears and stows loose items along the route on the commander's command, and sends the package only to the receiving team the flight surgeon names. Preparation never delays care: any change in the crewmember stops it.

Why this protocol was chosen. NASA-STD-3001 Volume 1 requires that medical evacuation is available for illness or injury beyond the care available onboard (V1 3007), with plans and vehicles to transport a severely ill or injured crewmember to a suitable medical facility (V1 3008). NASA technical brief OCHMO-TB-051 describes the landing-site and transport medical support, including transfer to a definitive medical care facility. On Earth, the WHO patient safety solution on hand-overs recommends a standard method such as SBAR, time for questions with read-back, and information on status, medicines, treatment plans and significant changes. A robot that pulls the record together frees the CMO to look after the crewmember. Open question for review: what the package must contain for each vehicle and receiving team, and how the read-back works when the link is down.

Autonomy: Max rung 2 for supervised packaging of records, a checked kit fetch of the transfer kit, and route clearing. The robot never decides on evacuation, never moves or straps in the crewmember, and never writes its own assessment.

Related: RMP-EGR-002 · RMP-EGR-003 · RMP-EGR-004 · RMP-CARD-001 · RMP-MSK-001 · RMP-GI-001 · RMP-PHARM-001

2 · Roles

Medical authority

Flight surgeon (ground). Holds medical authority for every run.

Onboard lead

Crew medical officer (CMO), acting under delegated care; uses the pre-approved onboard checklist when there is no link.

Others

• Second trained CMO: receives every alert and takes over if the CMO is the patient
• Vehicle commander: leads the vehicle procedure and the transfer
• Receiving medical team: named by the flight surgeon
• Other crew: help as the commander or CMO directs

Commercial flights

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. (NASA-STD-3001 requires two CMOs per vehicle for NASA programs [V1 3006]; FAA rules set no medical standards for spaceflight participants.) [9]

3 · Preconditions and consent

• PRE-1 The CMO or commander started the protocol by command after the flight surgeon (or the CMO under the onboard checklist) decided on an evacuation.human_start == trueV2 10174
• PRE-2 Robot self-test passed; kit stowage locations known.V2 10161V2 7059
• PRE-3 Robot and supplies restrained when not moving.V2 7046
• PRE-4 Link status known. The crew never wait for the robot before acting.link_state in [live, delayed, down]

Consent

The crewmember agrees to the record going to the receiving team; the CMO confirms.

Emergency consent

If the crewmember cannot agree, the record goes to the receiving team the flight surgeon names, as for any medical transfer.

Withdrawal

The crewmember can ask for parts of the record to be held back; the CMO and flight surgeon decide what care needs.

4 · Required sensor inputs

5–6 · Steps and decision points

Each step names who acts. Decision points sit after the step they follow and say who decides: Robot Crew Ground. Any stop rule in section 7 can interrupt any step.

1. S1RobotRung 2

   Tell the flight surgeon and the CMO that evacuation preparation has started (URGENT if a red flag is already stated). Every URGENT alert goes to the CMO and the flight surgeon at the same time (queued for the flight surgeon if the link is down). If the CMO is the patient, is busy treating, or does not answer, the alert goes to the second trained CMO, or the crewmember named before flight [V1 3006]. An URGENT alert that is not acknowledged within <set by validation> seconds is repeated and sent to the next named crewmember.

   Done when: Notice acknowledged, or escalated.

   V2 10174V1 6003V1 3006

2. S2RobotRung 2

   Build the hand-over package from recorded entries only, in SBAR order: Situation (the decision and reason as stated), Background (protocols run, alerts and times), Assessment (quoted from the CMO and flight surgeon), Recommendation (quoted from the flight surgeon); add vital signs as displayed, images, medicines as recorded by RMP-PHARM-001 on a clock-time timeline, and allergies as recorded. Mark it "DRAFT – NOT READ BACK".

   Done when: Draft package built; gaps shown as "not recorded".

   V1 7001V1 3007

3. S3RobotRung 2

   On the CMO's command, run a checked kit fetch of the transfer medical kit and portable monitor: check the kit ID and seal before hand-over, and quarantine a kit whose ID or seal does not match (no hand-over; the CMO is told). Any medicine goes only through RMP-PHARM-001. If an URGENT red flag has fired or a human states an emergency, bring it instead as an emergency fetch: This is an emergency fetch on a human command (CMO): no barcode check runs before hand-over and nothing waits for one. The robot reads the kit's own label and seal status only if that adds no delay, says "EMERGENCY FETCH – NOT VERIFIED (CMO command)", and "seal not intact" if so, and hands the kit over anyway. The fetch is logged as an override: time, who asked, the reason as stated, kit ID and seal status. It never says "verified".

   Done when: Kit within reach after a matched ID and seal, or quarantined, or emergency fetch logged.

   Limit: <set by validation>

   V2 7046V2 7059

   D1DecisionRobot decides

   Which kit fetch was it, and what did the checked kit fetch show?

   • EMERGENCY FETCH (an URGENT red flag had fired, or a crewmember or the CMO stated an emergency) → Hand-over already done as an emergency fetch, logged as an override; reconciled afterwards (not a check before use).
   • KIT ID AND SEAL MATCH → Hand the kit over closed; log "KIT ID AND SEAL MATCH. Not a check of the contents." and the clock time.
   • MISMATCH, seal not intact or CANNOT VERIFY → Shown with the reason. No hand-over under this protocol: the kit stays sealed in quarantine (the RMP-PHARM-001 default), and the robot never hands it over unprompted or to anyone but the CMO. The robot does not offer or suggest an override. Only if the CMO explicitly makes the two-step override request inside RMP-PHARM-001 can the kit go to the CMO, logged there as an override with the reason, and flagged to the flight surgeon. If the need becomes an emergency, a crewmember or the CMO states it and the emergency fetch applies.No hand-over
4. S4Crew

   The CMO and crew prepare the crewmember and restrain them for transfer under the vehicle procedure; the commander leads the transfer.

   Done when: Human-led preparation.

   V1 3008V2 7046

5. S5RobotRung 2

   On the commander's command, clear and stow loose items along the transfer route, then hold out of the route.

   Done when: Route clear; robot out of the route.

   V2 7055

6. S6RobotRung 2

   Show the package to the CMO for read-back; record each correction the CMO states as a new version (earlier versions kept), then mark it "read back by the CMO". Log any change the crewmember or CMO reports.

   Done when: Package read back, or still marked DRAFT – NOT READ BACK.

   V1 7003

   D2DecisionRobot decides

   Checked after every answer and at any point in the run (even mid-question or mid-step): does any answer, reading or observation meet a red flag?

   • Yes → Stop the current question or step at once and apply the action listed for each matching red flag (URGENT alert, flag, or stop), with the answer or reading itself, never a cause. Every URGENT alert goes to the CMO and the flight surgeon at the same time (queued for the flight surgeon if the link is down). If the CMO is the patient, is busy treating, or does not answer, the alert goes to the second trained CMO, or the crewmember named before flight [V1 3006]. An URGENT alert that is not acknowledged within <set by validation> seconds is repeated and sent to the next named crewmember.
   • No → Continue.
   D3DecisionRobot decides

   Did the crewmember answer when asked how they feel?

   • Yes → Continue.
   • Declined explicitly (the crewmember says no to a question) → Log "declined" for that question only; the alert already sent stands.
   • No response, or the answer does not make sense → URGENT: log "no response" (never "declined"); the CMO, or the second trained CMO if the CMO is the patient, checks the crewmember in person at once.
   D4DecisionCrew decides

   Has the CMO read back the package?

   • Yes → Marked "read back by the CMO".
   • No, or not yet → Stays marked "DRAFT – NOT READ BACK"; it is still sent if the flight surgeon asks.
7. S7RobotRung 2

   After any URGENT alert: After an URGENT alert the robot does not leave on its own: it stays at its rest position in the module, with its screen and voice link available, until a human has taken over or tells it to go. It never follows, blocks or touches anyone. It keeps time-stamping what humans say they did, and repeats the alert if it is not acknowledged.

   Done when: Robot at rest in the module until a human releases it; alert acknowledged or escalated.

   V2 10173V1 3006

8. S8Ground

   The flight surgeon names the receiving team and facility and confirms the package recipients [V1 3007, V1 3008]; with no link, the CMO follows the onboard checklist and the package is stored for forwarding.

   Done when: Recipients named, or package stored.

   V1 3007V1 3008

   D5DecisionGround decides

   Who is the receiving team, and when is the transfer?

   • Link live → Flight surgeon decides; robot logs.
   • Link down or delay too long → The CMO decides under the pre-approved onboard checklist; the flight surgeon reviews the log at the next contact.
9. S9RobotRung 2

   Send the package only to the receiving team the flight surgeon named, as private medical data; if the flight surgeon asks before read-back, send it marked "DRAFT – NOT READ BACK" (care never waits for the read-back).

   Done when: Package delivered or queued.

   V1 6003V1 7003

10. S10RobotRung 2

    Only after the CMO or flight surgeon has placed an order, run RMP-PHARM-001 for the ordered item (fetch, barcode match to every order field, recipient check). This protocol adds nothing to that check, never suggests an order, and never hands anything over outside RMP-PHARM-001.

    Done when: RMP-PHARM-001 run logged with its result, or none ordered.

    V2 7059

    D6DecisionRobot decides

    What did RMP-PHARM-001 show for the ordered item?

    • MATCH TO ORDER → RMP-PHARM-001 completes its own recipient check and hand-over; this protocol only logs "MATCH TO ORDER. Not a dose, interaction or allergy review." and the clock time.
    • MISMATCH or CANNOT VERIFY on any field, or a failed scan or recipient check → MISMATCH or CANNOT VERIFY shown with the fields named. No hand-over under this protocol: the item stays sealed in the NOT VERIFIED bag in quarantine (the RMP-PHARM-001 default), and the robot never hands it over unprompted or to anyone but the CMO. The robot does not offer or suggest an override. Only if the CMO explicitly makes the two-step override request inside RMP-PHARM-001 can the item go to the CMO, logged there as an override with the reason and the mismatched fields, and flagged to the flight surgeon.No hand-over
11. S11RobotRung 2

    When the CMO says the event is over, run RMP-PHARM-001 reconciliation on each kit fetched: record the items the CMO or crew state were used, the remaining contents against the kit list, seal status and expiry, labelled "inventory reconciliation after emergency use – not a check before use". Flag the override to the flight surgeon and the pharmacy lead, and show each kit as "opened – not restocked" until a human restocks and reseals it.

    Done when: Reconciliation recorded; kit shown as opened – not restocked until resealed.

    V2 7059

7 · Stop and escalate rules, red flags

Red flags

The robot reports the sign or value only, never what it means. Numeric thresholds are placeholders for the clinical lead.

8 · Safety limits

9 · Logs and audit

• LOG-1 Every input, robot action, decision (with who made it) and hand-off, time-stamped to the second.V2 10163V2 10164
• LOG-2 Mode changes and safety-limit events are announced to the operator as they happen and logged.V2 10162V2 10172
• LOG-3 Records are stored and sent as private medical data, encrypted, with access limited to the medical team.V1 6003V1 7003
• LOG-4 Results are kept in a permanent, retrievable format so the flight surgeon can see trends.V1 7001
• LOG-5 Each package version, read-back status, corrections as stated, recipients named and send times, changes in the crewmember during preparation.
• LOG-6 Each URGENT alert, who received it, the time it was acknowledged (or the escalation to the next named crewmember), and the time a human released the robot.V2 10163
• LOG-7 Each emergency fetch as an override (time, who asked, reason as stated, kit ID, seal status) and the later inventory reconciliation, labelled "not a check before use".V2 7059
• LOG-8 Each RMP-PHARM-001 run started from this protocol: order ID, result (MATCH TO ORDER, MISMATCH or CANNOT VERIFY with the fields), quarantine, and any CMO override logged by RMP-PHARM-001 (reason and mismatched fields), at clock time. No running counter of doses.V2 7059
• LOG-9 Each checked kit fetch: time, who asked, kit ID, seal status and result (KIT ID AND SEAL MATCH, MISMATCH, seal not intact or CANNOT VERIFY), and any quarantine.V2 7059

10 · Links to NASA-STD-3001

IDs as published in Volume 1 Revision C [4] and Volume 2 Revision F [5]. NASA-STD-3001 binds NASA programs; it is not a regulation for commercial flights. Its robot rules are general automation requirements, not medical-device rules.

11 · Validation

1. Simulation. Scripted evacuations with missing records, conflicting allergies, a change mid-preparation, CMO as patient, lost link. Pass: Nothing sent to an unnamed recipient; no robot-written assessment.
2. Training model. Hand-over drills with a receiving team using the package. Pass: Receiving team rate the package as complete or gaps clearly marked.
3. Earth analog. Analog evacuation drills. Pass: Preparation never delays care.
4. Flight use under flight surgeon supervision. First use in drills. Pass: No safety events.

No stage has been run. Pass and fail criteria must be fixed in advance by the clinical lead and safety board.

12 · Human sign-off

Before any use

• Clinical lead for the specialty (sets every clinical threshold marked <set by clinical lead>)
• Flight surgeon, as medical authority
• Robotics and medical-device safety board
• Program approval for the mission

Each run

Started by the CMO or commander after an evacuation decision. The flight surgeon names the recipients.

Restart after a stop

Human only. After any emergency or protective stop, a crewmember must restart the robot; the robot never restarts itself.

None of these sign-offs has happened. This is a Draft v0.3.

13 · Change control for learning

• Every change gets a new version number and a written reason; earlier versions are kept.
• Any change to steps, thresholds, limits or software that touches the patient repeats validation from the simulation stage before use.
• Software and learned-skill updates follow a pre-agreed change plan (what may change, how it is tested, how to roll back), modeled on the FDA predetermined change control plan approach.
• If a new version misbehaves, the robot rolls back to the last validated version and the event is reviewed by the flight surgeon and safety board.
• The robot never changes its own protocol, thresholds or limits.

Change-plan model: FDA guidance [8].

Loss of signal and Mars delay

Live link

Low Earth orbit: the package goes to the receiving team when the flight surgeon names it.

Loss of signal

• Only the robot pauses non-essential motion and tells the CMO; it resumes offline only on the CMO's confirmation. Crew care never waits for the link or the robot.
• The package is stored for forwarding; the CMO follows the onboard checklist.

Mars-class delay

• Evacuation from Mars-class distances may not be possible in time; the package supports onboard care and the later hand-over.

[7]

Sources

1. NASA OCHMO. Crew Medical Support for Entry, Descent, and Landing. Technical Brief OCHMO-TB-051. www.nasa.gov/wp-content/uploads/2026/05/ochmo-tb-051-crew-me… Supports: Flight surgeons are present at the landing site; launch and landing sites need medical capability for contingencies; depending on the location, transport may be by ground, water or air, with rescue vehicles able to give advanced trauma life support until transfer to a definitive medical care facility (DMCF) [V1 3013, V1 3014]. Read Oct 21, 2026.
2. WHO Collaborating Centre for Patient Safety Solutions. Communication During Patient Hand-Overs. Patient Safety Solutions, volume 1, solution 3 (2007). cdn.who.int/media/docs/default-source/patient-safety/patient… Supports: Suggested actions: a standardized approach to hand-over, including SBAR (Situation, Background, Assessment, Recommendation); time to ask and answer questions, with repeat-back and read-back; information on status, medications, treatment plans, advance directives and significant changes; exchange limited to what is needed for care. Read Oct 21, 2026.
3. Kleinman ME, Buick JE, Huber N, et al. Part 7: Adult Basic Life Support: 2025 American Heart Association Guidelines for Cardiopulmonary Resuscitation and Emergency Cardiovascular Care. Circulation. 2025;152(16_suppl_2):S448-S478. PMID 41122888. doi:10.1161/CIR.0000000000001369 Supports: Hand-off to cardiac arrest support when the crewmember is unresponsive or not breathing normally.
4. NASA. NASA-STD-3001, Space Flight Human-System Standard, Volume 1: Crew Health, Revision C (2023). www.nasa.gov/wp-content/uploads/2023/11/nasa-std-3001-vol-1-… Supports: NASA-STD-3001 Vol 1 Rev C: V1 3007 (medical evacuation), V1 3008 (transport plans and vehicles), V1 3006, V1 6003, V1 7001, V1 7003.
5. NASA. NASA-STD-3001, Volume 2: Human Factors, Habitability, and Environmental Health (Rev F, 2026), including Section 10.6 Automated and Robotic Systems. standards.nasa.gov/standard/NASA/NASA-STD-3001_VOL_2 Supports: NASA-STD-3001 Vol 2 Rev F: V2 7055, V2 7046, V2 7059, and Section 10.6 automated and robotic systems.
6. NASA OCHMO. Medical Operations. Technical Brief OCHMO-TB-044 (2025). www.nasa.gov/wp-content/uploads/2025/08/ochmo-tb-044-medical… Supports: The crew surgeon keeps medical authority when care is delegated; crew medical officers train on the JSC 48522 medical checklist.
7. NASA. Mars communications disruption and delay (fact sheet, 2023 Moon to Mars Architecture Concept Review). www.nasa.gov/wp-content/uploads/2024/01/mars-communications-… Supports: One-way Earth-Mars delay up to about 21-23 minutes, plus blackouts of about 2-3 weeks near solar conjunction.
8. U.S. Food and Drug Administration. Marketing submission recommendations for a predetermined change control plan for artificial intelligence-enabled device software functions (guidance). www.fda.gov/regulatory-information/search-fda-guidance-docum… Supports: A model for planning, validating and rolling back software updates.
9. U.S. Code of Federal Regulations, Title 14, Part 460: Human space flight requirements. www.ecfr.gov/current/title-14/chapter-III/subchapter-C/part-… Supports: Federal rules for crew and spaceflight participants on licensed commercial flights; they set no medical standards for spaceflight participants.

Checked on 2026-10-20: links opened (HTTP 200 or publisher redirect), DOIs and PubMed IDs matched, NASA documents read in full text. The framework comes from Part 1.