FDA's 2026 Draft RASD Guidance: What UK Surgical Robotics Companies Need to Know

On 25 September 2026 FDA issued Robotically-Assisted Surgical Devices: Premarket Submissions as a draft guidance, open for comment and marked “Not for Implementation”. For a UK company planning a US launch, the main points are a precise definition of a RASD with clear exclusions, an expectation of fail-safe behaviour if teleoperation fails, training that covers theatre staff as well as surgeons, and specific conditions for using clinical data gathered outside the US. The analysis below draws only on FDA texts in our FDA surgical robotics and SaMD base. The base does not cover MHRA requirements, UKCA or CE marking, and holds no earlier FDA RASD guidance to compare against.

A draft, and what that means in practice

Until it is finalised, the document is FDA's proposal, not its settled position. Comments are due within 60 days of the Federal Register notice announcing it. Even in final form, FDA guidance consists of nonbinding recommendations unless it cites legal requirements, and the draft itself says alternative approaches can be discussed with FDA. For planning purposes, many teams treat a draft as a strong signal of what reviewers will ask. Check the status on fda.gov before you rely on any specific recommendation.

Is your system a RASD?

The draft defines a RASD as a teleoperated, software-controlled system with a leader/follower architecture, used under the direct control or supervision of a qualified practitioner, to position and control instruments in open, minimally invasive or endoluminal procedures. It may include some automated functions.

• Excluded: pre-operative planning and stereotaxic systems, with examples under 21 CFR 882.4560 (product codes OLO, HAW and PGW).
• Not addressed: robots placing interventional devices such as catheters; remotely teleoperated systems, where the console is in a different room from the patient-side unit; and autonomous robots performing significant parts of a procedure independently.
• If in doubt: FDA asks you to contact it through the Q-Submission Programme.

Engineering expectations: teleoperation, control and stops

The draft states that “RASDs should have fail-safe operation in the event of teleoperation faults (e.g., cable disconnection, electromagnetic interference)”. Its non-clinical test programme then covers total system latency under worst-case conditions (FDA recommends at least three systems), motion scaling and tremor filtering, control stability under accidental jolts, fault detection and recovery to a safe state, timed emergency removal to give access to the patient, and safety stops verified by measuring residual travel.

The draft also lists device-description items FDA expects: kinematic and connection diagrams, the reach and degrees of freedom of each arm, an emergency/safety stop button, emergency patient-access and removal procedures, and separate sections for capability-enhancing features such as tremor reduction, motion scaling or visual magnification.

Training and human factors for the whole theatre team

The draft asks for a validated training programme, summarised in the submission, and says: “The training program and competency expectations should not only focus on surgeons, but also include other OR staff, such as bedside assistants and surgical scrub nurses, who interact with RASDs.” Training should be reviewed when interfaces change or new user groups are added, and success criteria should be explicit.

In the human factors section, validation testing should include several user groups where they work on the robot simultaneously, in a realistic environment. It should also consider negative knowledge transfer from other robotic systems, instrument exchanges and port switching, reprocessing, and emergency procedures such as conversion to open or laparoscopic surgery and power loss. FDA's 2016 final human factors guidance, also in the base, defines a critical task as one that, if performed incorrectly or not at all, would or could cause serious harm, including compromised medical care.

Using UK clinical data in a US submission

For new RASDs, clinical data are “often needed”. Where investigations outside the US support a US submission, the draft points to 21 CFR 812.28. It then sets two comparability tests:

1. non-US patient cohorts should have similar demographic characteristics and comorbidities to the intended US population;
2. non-US investigators and surgeons should have similar training, experience and practice patterns to the targeted US users.

The data should also reflect use in a typical US operating room, and should show how different user groups interact with the system and whether training works. The draft's nine recommended endpoints are length of stay, intraoperative adverse events, transfusion rate, conversion rate, 30-day post-operative adverse events, readmissions and reoperations, mortality and operative time. Building them into UK protocols early avoids re-analysis later.

This paradigm supports adding procedures, not claims about treating a specific disease or condition. FDA encourages a Q-Submission to agree the choice.

Software, cyber and labelling: quick reference

• Software: generally the Enhanced Documentation Level under FDA's premarket software guidance; Basic requires a scientific rationale.
• Cybersecurity: section 524B applies if the robot is a cyber device. Testing should include the robot communicating with a compromised hospital network.
• AI/ML features: risk assessment, a Q-Submission, and a Predetermined Change Control Plan if post-authorisation changes are expected.
• Labelling: prominent emergency withdrawal procedures, learning-curve information, a summary of in vivo data, a statement that disease-treatment outcomes were not evaluated, and “MR Unsafe” unless testing shows otherwise.

One further point concerns software that is not itself a device function. If you add features such as procedure timers or video recording, the draft asks you to assess whether they share computational resources or data with the device functions and could degrade their performance. If so, consider whether the submission needs more documentation. Under FDA's multiple function device policy, FDA may assess that impact.

To test your design file against the draft, ask the base questions such as “What must a RASD manufacturer demonstrate about system behaviour if teleoperation signal transmission fails?”

Practical next steps for UK teams

Because the draft is open for comment, UK companies can still influence it as well as prepare for it. The steps below follow directly from the draft's text; how far each applies to your device is a question for FDA, ideally through a Q-Submission.

1. Confirm that your system meets the draft's RASD definition and is not in an excluded or unaddressed category.
2. Run a gap analysis of your verification evidence against the teleoperation, system control, kinematics and reliability sections, with worst-case latency testing on at least three production systems.
3. Map each theatre role to training content and to human factors validation scenarios, including scenarios where several roles work at once.
4. Write your UK or European clinical protocols around the nine recommended endpoints and plan the comparability evidence for US patients and surgeons.
5. Prepare the cybersecurity file on the assumption that FDA will expect penetration testing across every connected element, including back-end servers, cloud services and update channels.
6. Draft the labelling elements the guidance lists, including the statement that disease-treatment outcomes were not evaluated.
7. Decide whether to submit comments within the 60-day window after the Federal Register notice.

Source: FDA draft guidance on Robotically-Assisted Surgical Devices. This article explains a draft FDA document and is not regulatory advice.