When the Instrument Becomes a Computer.
Regulatory strategy for laparoscopic and robotic surgery — where the device is now a software platform that happens to hold a scalpel.
Robotic Surgery Broke the Device Model Regulation Was Built On.
A surgical robot is a Class II device carrying a software stack, an imaging chain, a network connection, and an update cadence borrowed from consumer technology. The classical device framework assumes a product that leaves the factory finished. This one ships, learns, patches, and connects — and every one of those verbs is a regulatory event.
So a robotic program runs three files at once: the mechanical device file, the IEC 62304 software lifecycle file, and a cybersecurity file that section 524B made a condition of acceptance. We run them as one program, because the FDA reviews the platform, not the parts.
The device leaves the factory unfinished by design. Every update is a regulatory decision someone has to own.
One Platform, Three Submissions Living Inside It.
Sponsors think they are submitting a surgical device. The reviewer sees a mechanical system, a software product, and a networked asset — and reads all three.
Three files
Mechanics, software lifecycle, and cybersecurity — reviewed together, and only as strong as the weakest of the three.
The Mechanical Device
Instruments, articulation, force transmission, sterilisation, and the bench testing that proves the arm does what the surgeon asked.
The Software Lifecycle
IEC 62304 development records, verification, SOUP inventory, and a documentation level driven by your own safety classification.
The Cybersecurity File
Section 524B made an SBOM, a vulnerability management plan, and a patching commitment a condition of a valid submission, not a nice-to-have.
From a Trocar to an Autonomous Suggestion.
The specialty runs from simple access devices to AI that tells a surgeon what it sees — with the regulatory burden climbing steeply along the way.
Laparoscopic Instruments
Trocars, graspers, and insufflators in a deep predicate space where clearance is routine and the work is standards and sterilisation.
Robotic Systems
Class II systems carrying software, imaging, and networking — reviewed as platforms with a lifecycle, not products with a date.
Imaging & Navigation
Fluorescence, 3D, and navigation systems where the claim is what the surgeon can see and the evidence is what they can then do.
Surgical Intelligence
Software that identifies anatomy or flags risk — SaMD, with a PCCP question and a human-factors problem in real time.
Endoluminal Surgery
Where gastroenterology's scopes turn therapeutic and the reviewing division becomes genuinely ambiguous.
Tissue Extraction
The morcellation legacy: contained systems, boxed warnings, and a field permanently more careful about dissemination risk.
Morcellation harmed patients by functioning correctly. Risk analysis that only models failure misses the hazard entirely.
Morcellation Is Why the FDA Asks What Happens When It Goes Right.
Power morcellators did exactly what they were cleared to do: divide tissue for removal through a small incision. The hazard was not malfunction — it was that in a patient with an unsuspected uterine sarcoma, correct operation disseminated malignant tissue through the abdomen. A device performing to specification was upstaging cancers.
The FDA's response — safety communications, boxed warnings, contained-extraction requirements — reset how the agency reasons about minimally invasive access. The question is no longer only what happens if the device fails, but what the device does when it works in the wrong patient. We build that question into the risk file, because the reviewer already has.
You Are Not Launching a Device. You Are Adopting a Lifecycle.
Robotic and software-carrying surgical platforms commit a company to obligations that never close.
Cyber devices need an SBOM, a vulnerability plan, and a patching commitment — or the submission is refused before review.
A Predetermined Change Control Plan pre-authorises your update path, including model retraining. Without one, improvement means resubmission.
Your own software safety classification sets the documentation burden — and it is the first thing a reviewer will challenge.
Six Failure Modes We Are Brought In to Prevent.
Every one of these is a device company being surprised that it is now a software company.
No PCCP
Shipping a platform with no pre-authorised change path, then filing a new 510(k) for every improvement your competitors ship in a sprint.
Cybersecurity as documentation
Treating 524B as a paperwork annex rather than an architectural requirement, and being refused acceptance before substantive review.
Software classification too low
Claiming a Class B safety classification for software that can injure, and rebuilding the entire 62304 file after the reviewer disagrees.
Human factors under load
Validating usability in a calm lab when the device is used in a real theatre with a bleeding patient and a countdown.
Risk file models only failure
Analysing what happens when the device breaks and not what it does, correctly, in the wrong patient — the morcellation error.
Training as a control
Claiming surgeon training mitigates a hazard the design should have removed, and meeting a reviewer who has heard it before.
Regulatory Leadership for Surgery That Runs on Software.
Our MIS leads have taken robotic platforms through 510(k), negotiated PCCPs for AI-enabled functions, and built 524B-compliant cybersecurity files.
"A surgical robot is a software product with a sterile field attached. Companies that regulate it like an instrument spend the next five years resubmitting."
The discipline we bring across robotics, visualisation, surgical AI, and endoluminal platforms.
Building a Robotic or MIS Platform? Regulate It as Software From Day One.
Bring senior MIS regulatory leadership in while the architecture, the PCCP, and the cybersecurity design are still choices.
Senior-led. Embedded in your team. No junior hand-offs.