Outcomes Articles

Your Pilot Worked. Can the Next Hospital Use It?

October 14, 2026

About This Report

Featuring insights from Tina Joros, Hans Notenboom, and Mike Baird hosted by our CEO, Saul Marquez.

A Philips team connected patient-monitoring data to Google Glass in a matter of weeks. The display, intended for an anesthesiologist, brought together live vital signs, patient information and workflow details. Hans Notenboom recalled how exciting it was to see those pieces come together. Then he started asking what it would take to make the technology work inside a real hospital.

If you're planning medtech pilot expansion, that is the meeting to prepare for. The demo may have supporters and the next hospital may be interested. The buyer still has to purchase the service, connect it to existing systems and fit it into clinicians' working day.

Before the next commitment, follow those requirements from contract to clinical use. Who can finish the agreement? Which connections have to work? Can an ordinary user complete the task without the pilot's champion stepping in? The next hospital needs answers before it signs.

Can the Next Customer Actually Buy It?

A working integration doesn't automatically mean a company can get it into a customer's hands. In her 2018 Outcomes Rocket conversation, Tina Joros described a problem the Allscripts developer program uncovered after several years of operation. Allscripts later transitioned its branding to Veradigm, but this account concerns the earlier program. Companies were interested in connecting their applications through its APIs, yet relatively few became full partners with solutions available to customers.

When Tina's team reviewed the numbers, she reported that about 9% of interested companies had become signed partners. Some were only exploring, and others weren't a good fit. There were also companies Allscripts approved that ultimately chose not to proceed.

The team examined its contracts, pricing and partnership arrangements. Tina described a 14-month review that led to changes introduced in January 2017, including simplified click-through agreements and usage-based API pricing instead of upfront connection costs. She reported 225 signups in the first ten months of the revised program. Signups are not completed deployments, and the interview doesn't establish that the changes alone caused them.

For a founder preparing the next hospital agreement, this is a useful investigative approach. Look at where a qualified customer stops making progress. Are legal revisions going back and forth for terms that could be settled more clearly upfront? Does the proposed pricing fit the way that organization intends to use the technology? Has anyone identified who can approve the relationship, who will initiate implementation and who handles problems when something changes?

Those questions may have different answers for a hospital purchasing a clinical product than for a software developer entering an API partnership. Her experience shows why the commercial route needs to be designed around the real participants rather than left for them to negotiate after enthusiasm has built.

She also described educating sales, services, support, marketing and finance employees about how the developer program worked. A signed agreement can authorize the next implementation. It cannot establish that the solution is ready for that hospital's systems.

Will It Work Across the Hospital?

A patient-monitoring device might capture information correctly and display it where someone can see it. A hospital still needs that information to fit with records, clinical tasks and decisions occurring across its systems. A successful connection to one display answers a narrower question than whether the complete workflow is ready.

Hans described this broader challenge during his 2019 Outcomes Rocket conversation about innovation at Philips. He explained the company's approach to combining hardware, software and services instead of considering monitoring devices on their own. That included how patient information moves across hospital settings, how other systems contribute relevant data and how the resulting information supports staff working with patients.

Consider a system designed to identify a concerning change in someone's condition. An algorithm might produce a useful score or alert, but the appropriate nurse or physician still has to receive it, understand its significance and decide what to do. Hans was explicit that predictive tools could assist clinicians while clinical action remained their responsibility. The presence of a prediction is not evidence that a better patient outcome has occurred.

Which patient records, monitoring systems and workflow tools need to exchange information? What information is required at each point? Who maintains those connections? Which clinical team receives the output, and what action is expected?

Hans also encouraged looking beyond technical performance when assessing a solution. What changes for patients and staff? What happens to hospital operations? What are the financial implications? The interview did not establish a hospital-wide implementation or measured clinical benefit from that demonstration.

Completing the technical connections brings you closer to implementation, but it doesn't settle whether clinicians can incorporate the service into ordinary work.

Can Clinicians Use It Without the Champion?

A clinician already has patients to see, records to update and decisions to make throughout the day. Asking that clinician to open another application, learn a separate process or document information twice can make a useful technology difficult to adopt. The original pilot team may be willing to work around those steps. Colleagues who weren't involved in designing the pilot have their regular responsibilities to meet.

Mike Baird described this problem during his January 2020 Outcomes Rocket conversation about telehealth at American Well, now branded Amwell. He explained that programs often begin with a clinical champion who recognizes an opportunity, secures resources and gathers support to get a service started.

His team's work with electronic health records offered one response. Rather than expecting every physician or nurse to navigate a separate telehealth system, Mike wanted virtual visits available within the EHR session clinicians already used. The idea was straightforward: when the service is appropriate, a clinician should be able to initiate it from the existing workflow instead of interrupting the work to log into another application.

A clinician who helped build the pilot may be willing to work around an extra login or unfamiliar process. A physician doing an occasional virtual consultation may not have that time or familiarity. Plan for both, then test the task with someone who wasn't part of the pilot.

Mike also talked about incentives and the reasons clinicians would choose to participate. He distinguished consumer video visits from clinical telehealth in hospitals, clinics, nursing homes and schools. Licensing, provider skill, equipment and intended use can all change what successful operation requires. A smartphone visit is not the same workflow as a hospital consultation involving examination cameras or other specialized equipment.

For the next deployment, follow the ordinary user's actual steps. Who initiates the service, where do they access it and what must they document? Who handles technical problems, training, scheduling and ongoing support? The answers show whether the operation can continue without the clinical champion coordinating every exception. They also give the customer something concrete to test before wider deployment.

Put the Expansion Terms on One Page

Before approving another deployment, bring the people responsible for purchasing, integrating and using the solution into the same conversation. That includes the founder or commercial lead, the hospital's purchasing representative, an IT or integration owner, someone responsible for implementation and a clinician familiar with the intended workflow. Bring in legal, finance or compliance when their approval is necessary.

Give everyone a one-page expansion review with three things to check:

Agreement: Purchasing and pricing requirements, the people who can approve them, and the route to a completed agreement.
Connections: Systems that must connect, information moving between them, and who will deliver and maintain each interface.
Daily use: Changes to clinical work, training and support, and who will handle them after the pilot.

For each requirement, name an accountable owner, the resources needed and evidence that it is ready. This is a recommended review method drawn from three separate conversations, not a framework the guests developed together.

If implementation requires a particular interface, training or ongoing support, the customer needs to understand that before signing. If clinicians must change how they document or initiate a service, the hospital needs an actual plan, someone responsible for it and enough resources to carry it out. Otherwise, the next deployment may inherit responsibilities nobody agreed to handle.

The review should produce a decision. Approve expansion when essential terms, responsibilities and requirements are established. Test a narrower deployment when a specific integration or workflow remains uncertain. Delay the broader commitment when critical requirements are unresolved. A signed agreement, a functioning technical interface and evidence of routine clinical use establish different things, and each needs its own appropriate check.

The Google Glass demonstration came together in weeks. Hans's account shows why that wasn't the end of the work: hospital use brought questions about systems, staff and implementation. Identify those dependencies while you and the buyer can still change the scope, resources and agreement.

Before promising the next site, ask a purchasing representative, an integration owner and a clinician outside the original pilot to walk through the expansion review. Record what each can complete, what remains unresolved and who will resolve it. Make the next commitment match that evidence, so the service can operate without depending on the person who made the first pilot possible.

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: Tina Joros, General Manager of the Open Business Unit at Allscripts. Hans Notenboom, Philips. Mike Baird, President of Customer Solutions at American Well.