Rethinking surgeon feedback in surgical R&D

In ophthalmic surgery, surgeons are often clear about what they want from a new technology. But in my experience, what they ask for is not always the same as what they need. A surgeon may come with a proposed feature, an instrument modification or a different way for a surgical system to behave. That input is invaluable, and I use it as a conversation starter to learn which problem they’re addressing.

Our job in R&D is to understand the clinical or workflow problem behind the request. Is it unique to one surgeon or representative of a broader unmet need? Does the challenge originate with the technology itself, or with setup, usability, staffing or another part of the surgical workflow? And can we address it in a way that is safe, scalable and relevant across different surgical environments?

Answering those questions requires more than collecting surgeon feedback at specific points in development. It requires a closed-loop system in which observation, engineering, testing and clinical feedback continuously inform one another.

Clinical problem vs. feature request

One of the easiest mistakes in surgical R&D is taking a product proposed by a surgeon and implementing it as is instead of translating a surgeon’s request into a product requirement and identifying the best solution.

Medical professionals understand the clinical environment in ways engineers cannot easily replicate inside a development facility, although there have been huge advances in recreating operating rooms or clinics instead of using a basic wet lab. An “everything but the patient” setting allows engineers to recreate surgical procedures, including interaction with the staff. In fact, it can be highly beneficial to have the surgeon focus 100% on solving the problem at hand instead of, rightly so, paying most of the attention to the well-being of the patient in the operating room. Development teams have to consider many factors beyond the basic ability to achieve a stated goal, in particular human factors, manufacturability, regulatory requirements, economics, serviceability and whether a solution can ultimately scale across different customers and markets in a cost-effective manner.

We need to determine whether the underlying problem is broadly relevant before deciding how to solve it. In fact, the answer may be a new surgical instrument or functionality within a capital equipment platform, but it could also be a simpler user interface, a change in setup or an improvement somewhere else in the workflow. The problem should determine the solution, not the other way around.

That is also why observing ophthalmic surgery firsthand remains so important. Surgeon feedback is only one part of the picture. Each member of the surgical team interacts with technologies differently, and their experience can expose friction that may not be apparent when evaluating the clinical function of a device alone.

The operating room can tell us things that the conference room cannot; a workflow that functions extremely well in a high-volume surgery center with a cohesive, experienced team, for example, may behave differently in a hospital where staffing and experience levels vary. This leads to different requirements that R&D teams need to understand.

Closing the loop before it’s too late

Surgeon engagement should not be treated as a single milestone in the development process; it should continue as the technology evolves. At BVI, our development approach increasingly emphasizes multiple opportunities to test assumptions: identifying a clinical or workflow need, observing existing procedures, developing potential solutions, putting those solutions in front of users and using what we learn to refine the next iteration.

A prototype does not always need to be technically complete to answer an important development question. If we are designing a graphical user interface, for example, we can evaluate whether surgeons and staff intuitively understand how to navigate a workflow before every underlying capability is finalized. Similarly, an early instrument or system concept can help us understand whether our assumptions about setup, interaction or procedural flow hold up when placed in the hands of users. The sooner an assumption fails, the more useful that failure becomes.

I cannot think of a single example in which the first proposed solution became the final implementation without meaningful iteration. In fact, one of the paradoxes of R&D is that the simplest final solutions can require the greatest amount of development work; early concepts often become complicated because we are trying to accommodate multiple possibilities. It takes engineering discipline, repeated observation and collaboration with users to distill that complexity into something robust and intuitive. This reminds me of a famous sentiment attributed to the French mathematician and philosopher Blaise Pascal in 1657: “I would have written a shorter letter, but I did not have the time.” Brevity and simplicity take effort and ingenuity.

Simplicity and efficiency are especially important in ophthalmic surgery, where technology is used within a highly coordinated environment and small workflow decisions can be repeated across many procedures. The sophistication of the engineering should not create unnecessary complexity for the user; ideally, R&D absorbs complexity so the surgical team does not have to.

The same principle applies beyond the device itself to packaging, storage, setup and logistics. These areas may not generate the same attention as a new surgical capability, but they influence how efficiently a technology fits into the operating room. If an innovation improves one part of a procedure while introducing unnecessary complexity elsewhere, we need to question whether we have improved the overall experience.

The art of deciding what not to do

One of the most important responsibilities in R&D is knowing when not to add something. New technologies constantly expand what is technically possible. That is exciting, but it also creates a temptation to deploy technology because it is available rather than because it solves a meaningful problem.

There is a useful analogy in modern cars. Touchscreens are sophisticated, reliable and increasingly affordable, but that does not mean every physical control should become a touchscreen function. If adjusting something simple suddenly requires navigating through several menus, the technology may be more advanced while the user experience has become worse. Surgical technology requires similar discipline.

I sometimes describe innovation as drilling a tunnel from two ends. From one direction, engineers are evaluating emerging technologies and asking what new capabilities they make possible. From the other, surgeons and surgical teams are identifying clinical and workflow problems that need better solutions. The most successful innovation happens when those tunnels meet. Without that connection, R&D risks producing one of two outcomes: an important unmet need for which we have no practical solution, or an impressive technology addressing a problem that does not meaningfully exist.

This is why a closed-loop surgeon feedback system is so important to the future of ophthalmic surgical R&D. It creates a continuous exchange between what is clinically needed and what is technically possible. Surgeons and their teams help us understand the problem, while engineers translate that understanding into potential solutions and users challenge those solutions in realistic environments, and what we learn goes back into development.

The objective is not to give surgeons every feature they request, nor should engineers determine in isolation what the future of ophthalmic surgery needs. Our responsibility is to create the conditions where clinical experience and engineering expertise continuously enrich each other and to keep iterating until what we build does not simply add technology to the operating room but makes surgery and the workflow around it meaningfully better, benefiting all stakeholders, including patients, the ultimate customers.

Mikhail Boukhny, Ph.D., is chief technology officer at BVI Medical. Boukhny brings over 25 years of leadership experience in Surgical Ophthalmology. Until 2018 he lead Alcon’s Surgical Instrumentation R&D in Cataract, Vitreoretinal, Refractive and Diagnostics areas. Mikhail has grown through the ranks at Alcon, developing many breakthrough products, including Torsional ultrasound and Centurion Vision System.