Outcomes Articles

Your AI Demo Looks Great. Can Clinicians Actually Use It?

October 13, 2026

About This Report

Featuring insights from Outcomes Rocket podcast interviews with Komeil Nasrollahi, Jeff Norton, and Ganesh Padmanabhan hosted by our CEO, Saul Marquez.

To use the diagnostic-AI tool, clinicians had to leave their usual software, enter information somewhere else, and return to compare results. Komeil Nasrollahi says it never scaled. His team had been eager to bring it to market, but had overlooked the work it added.

You may have a hospital buyer ready to expand. But if the demo depends on a clinician doing extra work afterward, what's ready to scale? For a founder working on clinical AI commercialization, that question belongs in the agreement.

Walk through the existing task with a clinician, then repeat it with the AI included. Record the added work, keep the clinical checks the task requires, and assign an owner and resources to each unfinished integration or support need. Give the hospital that plan to review before more users inherit the work.

Komeil was Senior Director of Innovation and Venture Partnerships at Siemens Healthineers when he described the unnamed startup in his Outcomes Rocket conversation. His lesson was to include clinicians alongside the startup and enterprise partner. Distribution could help the technology reach customers, but the workflow still needed to fit the people using it.

Follow the Clinician's Work Before You Sell the Expansion

Ask a clinician to start in the usual application, not the screen where your product looks strongest. Follow the task through information gathering, review, decision, and documentation. Then repeat it with the AI included.

Record who prepares the demonstration's data and transfers its results. If a vendor employee performs a step hospital staff would have to repeat after purchase, include it in the proposed workflow. Otherwise, the buyer is seeing a process that depends on help its employees may not have.

Suppose your product prepares information faster, but someone must copy the output into another system. Perhaps a separate dashboard requires locating the same record again. The task can improve inside your application while work increases elsewhere. Include both effects in the comparison.

The user still owns the original responsibilities. If your tool adds a dashboard without removing anything, enthusiasm won't create more time in the clinician's day. Give users room to point that out while the design can still change.

Separate avoidable duplication from necessary review. Copying identical information between applications is different from checking a clinical fact. Identify which connections could remove repeated entry and which checks must remain. Those findings define what the implementation offer needs to cover.

Put Integration, Data, and Implementation Into the Offer

A subscription price doesn't tell the hospital what it will take to deploy the software. Jeff Norton approached that issue from healthcare finance. At the time of his Outcomes Rocket episode, he was Vice President of Business Development at Multiview Financial.

Jeff describes examining processes and establishing dependable data before adding automation. His invoice example is concrete: software captures information that an employee would otherwise enter into a financial system. That illustrates removing repetitive financial entry. It doesn't establish that clinical review can safely disappear.

His month-end reporting example ties speed to a specific purpose: getting financial information to decision makers sooner. The organization needs to examine how its reports are produced, not just how quickly software performs one activity. Agree on the intended operational result before choosing what to automate.

He also identifies data conversion, security, protected health information, organizational changes, and agreed outcomes as purchasing considerations. For your deployment, specify which systems provide the data, who supplies access, and who tests the connections. Include hospital staff time, training, and support alongside the vendor's fee.

Can your team demonstrate the product under the conditions hospital employees will actually encounter? Jeff encourages buyers to check that advertised use cases function as described. Show what happens when information is incomplete or an interface is unavailable, rather than relying entirely on prepared examples.

Raising another dependency can feel uncomfortable when the buyer is ready to expand. But leaving it vague assigns work to someone later. Agree on what both organizations will deliver before treating the installation as complete.

Build Trust Without Removing Necessary Clinical Checks

Ganesh Padmanabhan describes nurses reading AI-generated summaries with citations, then opening the original charts anyway. Introduced as founder and CEO of Autonomize AI in his separate Outcomes Rocket episode, he discusses assembling information for nurses and medical directors while they retain judgment.

For a founder expecting faster review, that behavior can be frustrating. Ganesh identifies trust and change management as reasons anticipated handling-time improvements may take longer to appear. His account doesn't establish a universal adoption timetable or guarantee that verification will eventually disappear.

Why would a clinician stop checking the source just because the summary looks convincing? The user may be learning the system, looking for missing context, or performing required review. A citation helps locate evidence. It doesn't independently establish that the summary is complete or appropriate for a decision.

Make necessary verification easier. Observe what users check and why, then distinguish navigation problems from information gaps and appropriate safeguards. Don't build the expansion forecast around clinicians abandoning checks the task still requires.

He also describes narrow improvements in care management and patient messaging that leave connected processes fragmented. A faster task can still depend on information scattered across systems. That helps explain why users need the supporting records, not simply a polished summary.

Ganesh also gives a wheelchair prior-authorization example involving an employee with years of operational knowledge. Some context lives in experienced staff, not just databases. Work with those staff to identify rules, exceptions, and the response when information is insufficient. Connecting a language model to records doesn't settle those decisions.

Give the Hospital a Deployment Plan It Can Review

Bring the workflow comparison into the expansion meeting as a deployment brief. The hospital should be able to examine five subjects:

User workflow: Added tasks, removed duplication, and required human review.
Technical dependencies: Source systems, access, integration, conversion, and security.
Trust and verification: Supporting evidence, training, discrepancies, and escalation.
Implementation investment: Vendor effort, hospital staff time, and ongoing support costs.
Ownership and evaluation: Named leads, acceptance criteria, unresolved problems, and expansion conditions.

Attach people to those commitments. Ganesh describes collaboration among technology, clinical, compliance, IT operations, and business teams, sometimes with experts embedded at the customer. That isn't a mandatory staffing formula. It shows why an engineer cannot independently settle every operational or clinical requirement.

Identify who delivers each interface, who provides access, and who confirms that the resulting workflow is appropriate. Have the employees supplying time agree to the commitment. A commercial agreement shouldn't quietly assign responsibilities to people who weren't involved in planning.

Evaluate actual use, including recurring problems, manual workarounds, and necessary verification. Accounts and functioning interfaces don't establish sustained adoption. Use the findings to decide whether to expand now, approve a limited next stage, or wait for specified work. A smaller next step may be disappointing, but it gives the teams a defined problem to resolve.

Write down what must change before the next expansion decision and who will demonstrate it. That might mean completing an interface or establishing a dependable process for exceptions. A delay with specific conditions gives your team something to deliver, rather than another meeting about whether users are ready.

Before You Promise the Next Rollout

Komeil's account doesn't tell us what a different rollout would have achieved. It does give you a concrete question for the next expansion meeting: what will the clinician have to do that the demo didn't show?

Before you agree to the next rollout, have a clinician, your implementation lead, and the hospital's IT and operational representatives complete the user sequence together. Include missing information, source checks, and exceptions. Put an owner and an agreed cost or resource commitment beside each unfinished integration, training, and support requirement.

Use that record to decide the scope of the next agreement. Keep required checks in the plan and resolve who will handle the extra work. If those commitments are still missing, agree to a defined next step that makes them testable before promising the broader rollout.

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: Komeil Nasrollahi, Senior Director of Innovation and Venture Partnerships at Siemens Healthineers. Jeff Norton, Vice President of Business Development at Multiview Financial. Ganesh Padmanabhan, Founder and CEO of Autonomize AI.