Every other application lets the model be wrong in private. Robotic ultrasound does not: the system has to perceive, decide, and press a probe against a patient, in real time, in the same second.
Most applications described as physical AI are still being evaluated where errors are inexpensive. A model picks the wrong bin in a warehouse, a gripper misses a part on a line, and the cost is a production cycle, not a patient. Robotic ultrasound does not offer that margin. It is the first clinical application in which a learned system has to close the entire loop, from image to decision to physical contact with a human body, continuously, while a clinician watches.
That is what makes robotic ultrasound the honest test. It is also why robotic ultrasound is worth building for.
Ultrasound is the imaging modality where the operator matters most. Image quality depends on where the probe is placed, at what angle it is held, and how hard it is pressed. Two sonographers scanning the same patient will not produce the same images, and the same sonographer will not reproduce their own scan six months later with the precision a longitudinal study requires. That variability is not a minor inconvenience. It limits reproducibility, it complicates follow-up, and it makes ultrasound harder to standardise than CT or MRI, both of which are far more constrained by the machine itself.
Ultrasound is also the modality under the most acute staffing pressure. Demand for diagnostic imaging continues to grow faster than the pool of trained sonographers, and unlike a scanner, an ultrasound examination cannot be run by a technologist who simply presses start.
A robot that holds a probe addresses both problems at once: a repeatable trajectory, a controlled contact force, and an image acquired under conditions that can be documented and reproduced. But only if the loop actually closes.
Robotic ultrasound is not a positioning problem. It is a contact problem with a perception problem inside it.
The system has to plan a trajectory over anatomy that moves, because the patient breathes. It has to maintain probe contact within a force window narrow enough to produce a usable image and gentle enough to remain comfortable and safe. It has to interpret what it is seeing well enough to determine whether the current view is diagnostic, and to adjust if it is not. And it has to register what it acquires against a prior volume, so the result means something in a clinical record rather than existing as an isolated image.
Each of those steps depends on the one before it, and all of them run while the arm is in contact with a person. There is no opportunity to fail quietly and retry.
This is the distinction that matters when physical AI is discussed in the abstract. Perception models are statistical. They generalise well, and they are wrong in ways that are difficult to predict in advance. That behaviour is acceptable, and even desirable, at the level of interpretation. It is not acceptable at the level of force applied to a patient. A clinical system therefore needs both layers: a learned layer that decides what to look at, and a deterministic layer that governs what the arm is permitted to do. Force limits, exclusion zones, and stop conditions are not a fallback for when the model fails. They are the reason the model is allowed to run at all.
ImFusion, based in Munich, builds the imaging and computer vision layer these systems require. The ImFusion SDK covers ultrasound processing, registration, segmentation, and machine learning, with GPU acceleration throughout. The ImFusion robotics framework adds the parts specific to this problem: a robotic ultrasound toolbox for trajectory planning and image recording, hand-eye calibration between the robot and its tracking or vision system, integration through ROS and MoveIt, and force control for the probe on robotic arms, where supported by the robot's interface. ImFusion technology is deployed in commercial systems from major medical device manufacturers, which is to say it has been through clinical validation and regulatory review before, not only through research.
KIMA is Kinova's medical robotics platform, launched in June 2026 to mark the company's twentieth year. The KIMA arm carries a 3 kg payload in a frame weighing under 13 kg, with a compact control unit that removes the conventional control box from the room entirely. KIMA software is developed to IEC 62304 Class C, with risk management to ISO 14971, and KIMA arms are designed, manufactured, and maintained under ISO 13485:2016 at Kinova's Boisbriand headquarters near Montreal, Quebec.
Those are the attributes that matter for this application specifically. Compliant, force-aware behaviour is what makes controlled probe contact possible. A light arm with a small footprint is what makes the system fit into a room that was not designed around it. And a documented quality file is what makes the difference between a system that demonstrates well and a system that can be submitted for clearance.
ImFusion joins QNX, RTI, MedAcuity, MPE, and Acontis in the KIMA partner ecosystem, which exists for a straightforward reason: an integrator building a robotic imaging system should be solving the clinical problem that makes their product distinctive, not rebuilding a calibration routine, a force controller, and a registration pipeline that already exist and have already been validated.
Honesty is more useful than enthusiasm here, so it is worth naming what remains open.
Reliability in the tail of the distribution is the governing constraint. A robotic ultrasound system that produces a diagnostic view in 95% of examinations is a strong result in a study and an unacceptable one in a clinic. Closing that remaining gap is typically more expensive than everything that preceded it.
Validation methods for learned components are still maturing. Existing standards assume deterministic behaviour, and a probe placement policy is not deterministic. The current answer is architectural: constrain the learned layer so tightly that its failures are bounded by construction.
And clinician trust has to be earned rather than assumed. A system whose reasoning cannot be followed will not be used, however well it performs on a benchmark.
None of this argues against the application. It argues for building it carefully, on components that were designed for clinical use from the start rather than adapted to it afterwards.
Robotic ultrasound will not be the largest market in medical robotics. It will be the one that establishes whether a learned system can be trusted to touch a patient, and that answer will shape everything built after it.
Building a robotic imaging system? Discover the KIMA platform or talk to our experts.
Robotic ultrasound is an imaging technique in which a robotic arm holds and positions the ultrasound probe, maintaining a controlled contact force against the patient so that examinations can be reproduced with a consistency a human operator cannot reliably achieve.
Robotic ultrasound requires a system to perceive an image, decide what to do, and apply physical force to a patient within the same continuous loop, in real time, which makes it the clinical application where the reliability of learned perception models is tested most directly.
ImFusion provides the medical imaging software layer, including the ImFusion SDK for ultrasound processing, registration, and segmentation, and a robotics framework offering a robotic ultrasound toolbox, hand-eye calibration, ROS and MoveIt integration, and probe force control where supported by the robot's interface.
KIMA is a purpose-built medical robotic arm from Kinova carrying a 3 kg payload in a frame under 13 kg, with software developed to IEC 62304 Class C, risk management to ISO 14971, and manufacturing under ISO 13485:2016 at Kinova's Boisbriand facility in Quebec.
