Outcomes Articles

Before You Sell Clinical Autonomy, Name the Task

October 26, 2026

About This Report

Featuring insights from Dr. Joseph Nathan, Will Mauldin, and Brian Tufts hosted by our CEO, Saul Marquez.

A surgeon repeating precise movements inside an eye has a clear reason to want greater consistency. The Outcomes Rocket conversation with Dr. Joseph Nathan, founder and CEO of ForSight Robotics, starts from that demanding work. It's a compelling reason to explore robotic assistance. It isn't, by itself, evidence that a robot should make the clinical decisions.

For a medtech team preparing a product demonstration, that distinction shapes the promise. A buyer needs to know which task the technology assists, what information it provides and where the clinician remains responsible. A broad claim of AI or autonomy can make those boundaries harder to see, even when the narrower capability is useful.

Test the product description against the work someone can observe. Three separate interviews offer distinct checks: the surgical task, the information a clinician can inspect and the difference between clinical analysis and implementation tools. Together they help a team describe a benefit precisely enough to evaluate without implying more independence than its evidence supports.

Define the Assisted Task and the Retained Responsibility

ForSight Robotics began with a problem Dr. Joseph Nathan understood firsthand. Trained in both engineering and medicine, Joseph had experienced the demands of ophthalmic surgery and recognized how much precision repetitive procedures require. During his Outcomes Rocket conversation, he described cataract surgery as a procedure in which surgeons must repeatedly execute the same movements and incisions. That consistency is important to the work, but maintaining it places considerable demands on the surgeon.

Joseph and his co-founders saw an opportunity to apply robotics to that challenge. The conversation emphasizes predictability and consistency as reasons to pursue robotic assistance, particularly in an anatomical space as small and delicate as the eye. Joseph also describes his own early surgical experience as difficult, reinforcing why a technology designed to support precise movements appealed to him.

Keep the intended improvement separate from the demonstrated result. The ForSight conversation discusses consistency and throughput as reasons to pursue robotic assistance, not as comparative outcomes established by the interview. A product brief should connect each claimed improvement to the evidence that actually supports it, rather than borrowing certainty from the clinical need.

That leaves an important responsibility question. Which surgical movements does the platform assist? What information does the surgeon receive? Which judgments and decisions remain with the surgeon? The interview establishes the clinical motivation, but it does not provide enough detail to assign the platform a specific level of autonomy or define every human responsibility during its operation.

For a medtech founder preparing a product brief, those questions should appear before the broad technology claims. Identify the specific task, describe the intended improvement, name the clinical decision that remains with the responsible professional and specify the evidence needed to support the benefit. This is an editorial test of the product description, not a claim about ForSight's approved uses.

The next step is to make the contribution visible enough that a clinician can tell what the software adds.

Show What the Clinician Can Inspect

A clinician looking at an ultrasound image already has information to interpret. Will Mauldin, co-founder and CEO of Rivanna Medical, described an approach that adds AI interpretation to that familiar view. In his Outcomes Rocket interview, Will explained how the company introduced ultrasound imaging and an AI overlay to support guidance for epidural and spinal anesthesia procedures.

The approach builds on something anesthesia clinicians already understand. They're accustomed to using conventional ultrasound for other needle-guided procedures, interpreting images and deciding how to proceed. Rivanna's approach allows clinicians to examine the ultrasound image alongside the software's interpretation, making the added information visible rather than asking them to accept an unexplained result.

That interaction helps distinguish several activities that can easily disappear under the label of AI. There's acquiring the image, interpreting what it shows, reviewing the software's contribution and deciding what action follows. Automation in image interpretation doesn't automatically establish that the technology controls the procedure or makes every clinical decision.

The Rivanna conversation describes clinicians initially comparing the ultrasound image and AI overlay, then giving the software interpretation more attention with experience. That observation makes adoption visible, but confidence and validated performance are different things. It does not establish a procedure count after which independent reliance is appropriate.

For a product demonstration, this suggests a useful review. Ask what the clinician can see, what information the software adds and which elements can be compared directly. Then identify the decision the clinician makes and the evidence supporting the claimed benefit. An understandable display can help buyers inspect the software's role, but the display itself doesn't prove that the interpretation is correct.

Even a clear interface does not tell the buyer where every use of AI sits inside the product and its deployment.

Separate the Clinical Model from the Tools Around It

A hospital can use sophisticated analytics without handing clinical decisions to AI. Brian Tufts, president and CEO of Ambient Clinical Analytics at the time of his Outcomes Rocket interview with Saul Marquez, described a system designed to detect potential patient deterioration and support critical-care workflows. The company's approach, developed from technology originating at Mayo Clinic, combines clinical analytics, decision support and workflow automation.

The Ambient conversation separates the rules-based clinical model from AI tools that could speed implementation or workflow analysis. An implementation tool and a patient-assessment model may sit near each other in a product story while doing different jobs. Calling both AI can obscure the question a clinical buyer actually needs answered: which technology is evaluating the patient's condition?

Consider the deterioration alerts discussed in the interview. Software identifies information that warrants attention and can help organize the response around a hospital's established protocols. Clinical assessment, decisions about care and the work required to implement the system remain distinct responsibilities. A product description should identify which activities the software performs and which require clinical judgment, rather than describing the entire process as autonomous.

The conversation also emphasizes validation and responsible implementation. Brian described the importance of established clinical evidence and structured processes when technology supports care for seriously ill patients. Those are reported characteristics and priorities, not independently verified proof of performance. A rules-based model still requires appropriate validation, monitoring and clinical oversight.

For product teams, the practical exercise is to examine each technology claim. Does AI perform the clinical analysis, assist implementation or support workflow automation? What evidence applies to that specific function? Identifying those boundaries makes the product easier to evaluate without implying more independence than the evidence establishes.

A narrower description can make a stronger promise when the buyer can see exactly which work it covers.

Rewrite the Promise in Terms Someone Can Test

Before making another claim about clinical autonomy, bring the product lead, clinical lead and commercial owner together. Put the current product description beside the demonstration and available evidence. Then write a short scope statement that a clinician or buyer can examine without guessing what the technology does.

The scope statement should make four things explicit:

Task: The specific clinical activity being assisted.
Contribution: The information, interpretation or action the software supplies.
Responsibility: The decision retained by the appropriate clinician.
Evidence: The documentation supporting this particular benefit and the limits that remain.

Write the statement for one function at a time. If a system interprets an image, describe that contribution separately from the clinician's decision and any physical action. If AI helps configure a workflow, don't let that implementation benefit become a claim that AI makes treatment decisions. Mark intended benefits as intended until the relevant evidence supports stronger language.

Compare that statement with the existing marketing copy. Remove or narrow claims the demonstration and evidence cannot support, and check product documentation before describing permitted uses.

The demanding surgical work that opened the discussion deserves a precise promise. A clinician should be able to point to the assisted task, inspect the contribution and understand the responsibility that remains. If the demonstration and the sales description imply different boundaries, resolve the difference before the next buyer conversation.

Before selling autonomy, make the task and the responsibility unmistakable.

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: Dr. Joseph Nathan, Founder and CEO of ForSight Robotics. Will Mauldin, Co-Founder and CEO of Rivanna Medical. Brian Tufts, President and CEO of Ambient Clinical Analytics.