Outcomes Articles

Your Device Passed Testing. Is It Ready for Real Life?

October 14, 2026

About This Report

Featuring insights from Scott Phillips, Justin Barad, and Beth McCombs hosted by our CEO, Saul Marquez.

Doctors received an eye-testing device that had lost its installed software while sitting in inventory. Scott Phillips, founder of StarFish Medical, described the failure of a historical PDA-based pachymeter, used to measure corneal thickness. Brief recharging and reprogramming checks had looked promising. The battery then discharged in distribution inventory, and the program disappeared before the device reached doctors.

The team supplied software on CDs so customers could reload it through computer synchronization, a workaround for that particular device at that time. The earlier checks had missed a condition the product would face before use. Scott also corrected the terminology during the interview: he described the battery issue as arguably verification rather than the broader validation language in the question.

As your next medical device launch approaches, encouraging technical results and a distribution plan can make the product feel ready to ship. What happens while it sits in storage? What have clinicians practiced, and what can the receiving site support? Answering those questions now may take more work, but discovering the gaps after delivery leaves the receiving team to deal with them.

Test the Conditions the Device Will Actually Face

What conditions will this device encounter before a clinician ever uses it?

Depending on the product, that could mean time spent in storage, changes in battery charge, handling during distribution or preparation at the receiving facility. The appropriate assessments depend on the device and its intended use. A meaningful review begins by asking which plausible failure modes the team has considered, what evidence exists for them and what remains uncertain.

Scott also discussed the importance of development phase gates. He recalled situations in which clients believed their projects were further along than they actually were, even though fundamental feasibility questions remained unresolved. A decision to move forward should reflect what has been demonstrated, with explicit criteria for unresolved work rather than optimism about how close the product feels to completion.

One practical recommendation from Scott was to get technical teams into the environments where their products will actually be used. He described opportunities to observe surgery centers, air ambulances and other clinical settings. Engineers make numerous design decisions that never appear explicitly in a specification, and firsthand observation can inform those choices. This is especially useful when a team has designed around assumptions about how users will prepare, handle or position the product.

Give Clinicians a Chance to Practice Before First Use

During his orthopedic surgery training, Justin Barad recalled a fellow resident who completed a hand-surgery rotation without encountering a single case involving a common wrist fracture. The rotation lasted two months, but those particular injuries simply didn't arrive while the resident was there. He moved on without the expected experience.

Completing a rotation or attending a training session doesn't necessarily establish that someone has practiced the specific skills a new medical device requires. When experience depends on which cases happen to appear, two clinicians can finish similar training with different levels of exposure. A launch team should understand what the intended users have actually practiced, particularly when a product introduces unfamiliar techniques or steps.

Justin, an orthopedic surgeon and founder of Osso VR, saw repeatable simulation as one way to address that variability. Instead of depending entirely on opportunities in the operating room, clinicians could practice procedures in a simulated environment and have their performance assessed. Simulation provides a more consistent opportunity to rehearse tasks, although the appropriate approach still depends on the product and intended clinical activity.

He described an early UCLA pilot comparing medical students who received VR training with students who received traditional instruction. Both groups subsequently performed simulated procedures using anatomical training models called sawbones, with their performance evaluated by a blinded assessor. Justin reported stronger simulated performance among the VR-trained students, while research connecting that training to patient outcomes was still being planned. The pilot measured simulated skills, not complication rates, independent clinical competence or safe first use with patients.

What has the clinician demonstrated beyond attending the training?

For a launch team, that question helps distinguish documented exposure from evidence of relevant preparation. Depending on the device, the answer might involve observed practice with specific tasks, appropriate assessment and additional supervised preparation. There is no universal number of training cases or simulation sessions established by Justin's interview, and a simulated score cannot substitute for the clinical judgments or qualifications required in the intended setting.

Justin also described what he called the one-and-done phenomenon, where a clinician has a poor initial experience with new technology and decides against using it again. He identified inadequate preparation as one possible contributor. That's an explanation of a potential adoption problem, not a measured rate of rejection or proof that a disliked device was safe. Training cannot compensate for genuine device defects or inappropriate design.

Make Sure the Receiving Team Can Support It

Beth McCombs, speaking as executive vice president and chief technology officer at BD, emphasized the importance of observing what happens on the clinical floor. She described spending time with customers beyond the executive level to understand actual workflows before deciding which problems a new technology should address. That observation can reveal work that isn't obvious during a technical demonstration.

Her account of BD's work with Scripps Health provides a useful example. The vascular-access initiative combined a portfolio of products with clinician training and standardized practices. It involved choosing appropriate products, establishing how catheters would be managed after placement and helping clinicians follow those practices consistently. The intervention therefore included decisions and behaviors outside the product itself.

Beth described favorable findings from that initiative, but the account concerned multiple products and changes in practice. Those outcomes cannot be attributed to one catheter, and the original study would need examination before treating the reported figures as independently verified clinical evidence. For a launch team, the relevant observation is the importance of identifying the complete intervention being implemented.

The implementation question becomes especially concrete when technology connects several departments. Beth traced medication management from central and hospital pharmacies through the hospital floor to the patient's bedside. A product serving that journey may depend on inventory processes, existing systems and responsibilities distributed across different teams. Every handoff can create preparation or support work that someone must own.

Who will do the implementation work when the product arrives?

Beth identified hospital IT capacity as a constraint on implementing connected systems. She described customers assembling reports from separate sites into Excel spreadsheets and explained BD's ambition to make information easier to access through a common platform. Those are proposed advantages, not evidence that local IT work disappears or that every system will integrate automatically. Receiving organizations still need to evaluate the implementation demands they can support.

Decide What Must Be Ready Before Launch

Before approving the next stage of a medical device launch, bring the people responsible for its first use into the same review. That includes the launch and product leads, engineering and quality teams, intended clinical users, training representatives and the receiving organization's workflow, IT and support owners, as appropriate.

Use a first-use readiness checklist to examine:

Realistic storage and use conditions.
The evidence supporting the device's performance.
Clinician preparation and demonstrated skills.
The receiving site's workflow and support capacity.

For every gap, name an owner and the evidence or corrective work needed. This review draws on Scott's, Justin's and Beth's separate experiences. It is not a jointly tested protocol, a regulatory-complete release gate or a substitute for qualified technical, clinical and regulatory review.

Let the findings determine the next stage. Proceed within the supported scope when the necessary evidence and preparation are sufficient. Limit deployment when only narrower use is supported. Resolve specific gaps before expanding.

At the next launch review, ask the device, training and receiving-site owners to show what is ready for first use. Leave with a record of what has been demonstrated, who owns each remaining gap and whether the next stage will proceed, be limited or wait for corrective work. Make that decision before the product arrives.

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: Scott Phillips, President at StarFish Medical. Justin Barad, Founder and CEO at Osso VR. Beth McCombs, Executive Vice President and Chief Technology Officer at BD.