Outcomes Articles

The Robot Arm Works. Who Proves the Medical System Does?

October 26, 2026

About This Report

Featuring insights from Silke Wendt and Corey Ryan, Stan Schneider, and Anekant Jain hosted by our CEO, Saul Marquez.

The same supplier's robotic motion technology can support hair transplants, rehabilitation or spinal-screw alignment. Those applications do not ask the same thing of a finished medical system. In their Outcomes Rocket conversation, KUKA's Silke Wendt and Corey Ryan draw the boundary: they supply the arm and motion-control features, while customers build the medical application.

For a robotics founder or quality leader, that boundary matters when supplier evidence becomes part of a product claim. An arm's capability does not establish the performance of everything connected to it. Neither does a working data connection or a successfully manufactured component. The missing evidence can sit between contributions that each look convincing on their own.

Make the whole-system claim explicit before assembling its proof. Start with the motion component, follow the information needed to coordinate the system, then examine repeatable manufacture. The three interviews help separate those jobs so the product team can identify what each source of evidence supports and name who owns what remains unproven.

Separate Motion Capability from the Medical Application

Silke Wendt, who works in global medical marketing at KUKA, and Corey Ryan, Director of Medical Robotics at KUKA Robotics USA, describe supplying motion capabilities to medical-device developers. Customers build the applications. KUKA provides robotic arms and software features that control movement. The distinction is central to the joint interview, not a division inferred from either person's title.

The applications mentioned in the interview include minimally invasive surgery and bone cutting as well as rehabilitation and spinal-screw alignment. Each has its own clinical objective and operating conditions. Knowing that an arm can deliver controlled movement is useful, but it doesn't answer what the complete device achieves for its intended use. That question belongs in the application-level evidence.

The joint interview emphasizes that the clinical experience and treatment application come from the customer integrating the technology. That arrangement can spare a medical-device developer the work of creating motion-control technology from scratch. It also creates an important evidence boundary. A supplier's documentation may establish particular capabilities of the arm or its software, while the application developer still needs evidence connecting those capabilities to the behavior of the finished device.

For the team responsible for that application, a useful review starts with three questions. What exactly is the robotic component expected to do? Under what conditions must it perform that function? What evidence demonstrates that its contribution supports the intended medical application?

Those questions are an editorial approach to examining evidence, not a responsibility allocation supplied by KUKA or a shortcut around applicable regulatory requirements. The actual claims and acceptance criteria depend on the product.

Even clearly defined components must behave together. Once the arm becomes part of a larger application, another evidence question emerges at the connections between components: whether the required information reaches the right place when the system needs it.

Show What the Connected System Must Establish

Consider the difference between information arriving and information arriving in time to be useful. A sensor, algorithm and actuator may each function, yet the application still depends on their coordinated behavior. That is where the evidence question moves from the individual component to the connection.

Stan Schneider, CEO of Real-Time Innovations, explains this coordination challenge in his Outcomes Rocket interview. His company develops software that connects intelligent algorithms with sensors and actuators. Stan describes three practical concerns: discovering what information is available, determining what information a system receives, and ensuring it arrives when needed.

Timing matters because robotic systems operate through feedback loops. Information that eventually reaches the correct destination may still arrive too late for the behavior the application requires. The relevant timing limits, acceptable responses and evidence needed to substantiate them must come from the qualified product team, rather than a supplier's general description of its technology.

Stan also distinguishes a working prototype from a system ready for production. He identifies a substantial gap between prototype functionality and production operation, including the evidence needed to support system behavior beyond the demonstration. A successful demonstration establishes what happened under those particular conditions. It doesn't automatically establish how the complete application will behave across its intended operating requirements.

For the integration team, that raises a practical review question: which connected behaviors remain untested by the individual suppliers' evidence? The team must identify what information each component needs, when it needs it, how the system should respond and who is responsible for substantiating those requirements. Human control and approval boundaries also need to remain explicit where applicable.

Even a coordinated system leaves another question. Can the physical output be manufactured repeatedly under the intended conditions, rather than demonstrated successfully once?

Keep Manufacturing Evidence in Its Proper Role

The last evidence boundary is physical repeatability. Producing one acceptable part can demonstrate a technical possibility. A manufacturing process must support acceptable output under the conditions the product actually requires, not only the conditions of its best demonstration.

In his Outcomes Rocket conversation, Anekant Jain, Manager, Polymer Technologies at EOS, explains to Saul Marquez how industrial additive manufacturing differs from simply printing a part. The conversation identifies qualification, scalability, yield, turnaround and uptime as considerations in assessing whether a manufacturing process can support ongoing production.

That distinction matters as medical-device developers explore customized implants, orthotics and prosthetics. New manufacturing methods can make different shapes and individualized designs possible. Yet producing a promising design doesn't establish whether the process can reliably reproduce acceptable parts, particularly when materials, production volumes or manufacturing conditions change.

For the product team, the practical review begins with the intended output. What characteristics must each part meet? What evidence demonstrates that the manufacturing process can repeatedly deliver those characteristics? Who is responsible for evaluating changes that could affect the result?

These are questions for the relevant manufacturing and quality experts, who must establish product-specific requirements and acceptance criteria. The EOS conversation identifies the considerations but does not provide validated performance results for a particular medical application.

There is also a boundary that manufacturing evidence cannot cross on its own. Consistently producing an acceptable component does not establish how the finished medical device behaves in clinical use or whether it meets applicable safety and effectiveness requirements.

Motion capability, connected-system behavior and repeatable manufacture can each have credible supporting evidence. The remaining proof cannot be supplied simply by adding those claims together. Someone must own the complete application's claim.

Assign the Whole-Application Proof

Before treating supplier evidence as a complete case, bring the final product's application, systems and quality owners together with the people responsible for component and manufacturing evidence. Their job is to identify what each contribution establishes and what remains unproven.

Create a responsibility map with four entries for every important claim:

Claim: What must the component, connection, manufacturing process or complete application demonstrate?
Evidence: What documentation or testing supports that claim?
Boundary: What does the available evidence leave unproven?
Owner: Who is accountable for the remaining demonstration and for reassessment when designs or interfaces change?

The central claim is whether the finished robotic medical application performs as intended and meets its applicable safety, performance and clinical requirements. None of the supplier descriptions establishes that alone.

Use the map to assign unresolved work and determine the next evaluation through the appropriate engineering, clinical and regulatory processes. A completed map organizes responsibility. It doesn't establish product safety or effectiveness.

If the gap is timing, assign the connected-system evaluation. If it is repeatability, assign the manufacturing investigation. If the complete application's claim still lacks support, make that gap visible before another supplier document is treated as the missing answer.

A capable robot arm is a contribution to the proof. It is not the conclusion.

About the Conversations

These are three separate Outcomes Rocket conversations, not a shared case study. During the time of recording, the guest names and titles were as follows: Silke Wendt, Global Marketing, Medical Robotics at KUKA. Corey Ryan, Director of Medical Robotics at KUKA Robotics USA. Stan Schneider, CEO of Real-Time Innovations. Anekant Jain, Manager, Polymer Technologies at EOS.