Optical techniques are core to many of today’s medical devices—from pulse-flow oximeters to laser scalpels, and OCT retinal imagers to fluorescence-guided surgery. They will be core to tomorrow’s emerging technologies. I’ve seen highly successful optical efforts and few pitfalls that appear time and time again along the path to a successful product. This article highlights pitfalls most relevant to optical medical devices, but many are equally applicable to medical devices with no optics other than indicator lights—or even devices with no optics at all.

1. Don't Get Distracted

Scope creep is a danger in any project, and medical device development is no exception. It’s exciting to imagine identifying the optical “Swiss-army knife” that will revolutionize vast swaths of medicine. However, particularly in light of this first point, it is probably better to identify the technology’s one application where it can make the most successful first impact. Otherwise, you will run the risk of making the device overly complex.

As a concrete case in point, designing an optical instrument for use in a single region of the electromagnetic spectrum is commonplace: whether it be in the UV, the infrared (IR), or the visible. However, designing an optical product that images in visible light and infrared will require more substantial optical design and/or drive up cost. For example, “broadband” anti-reflection coatings exist for UV, visible, and IR applications—however, the design demands for simultaneous performance in multiple spectral regions are very challenging. Similarly, a large part of optical design is compensating for the fact that lenses bend different colors of light differently—that is to say, making the design achromatic. Coming up with an achromatic design that focuses red, green, and blue light onto a camera sensor at the same time is a pretty standard design exercise. Adding an ultraviolet wavelength to the mix will, at best, drive up design and parts cost and, at worst, may require adding an additional optical subsystem, or a mechanical focus adjustment and multiple exposures.

It could be this broad-spectrum imaging is a key differentiator of the product in a targeted market. In that case, broad-spectrum performance is a key requirement. But if the target application is identifying some particular dermatalogical illness, I’d caution against adding IR imaging to enable other applications down the road—at least without a cold, dispassionate examination of the business case.

2. De-risk the Right Things at the Right Time

Remember, in the long term, money spent early in the development schedule is “more expensive” (in terms of available cash reserves and/or investment dilution) than money spent later on. On the other hand, money spent without success is also expensive. For that reason, identify key technical risks early, and plan to de-risk them in order of their capacity to invalidate the technical approach. Usually, these risks are fundamental rather than straightforward design. For example, is your idea to optically image tumors going to be derailed by diffuse scattering of the light on the way to and from said tumor? Be brutally honest with yourself, without being defeatist.

Ideally, you may be able to quantify the risk sufficiently to enable a decision merely through a search for similar products, through the research literature, or by paper or computer analysis. These methods are relatively inexpensive. However, it may be necessary to build a physical device to obtain sufficient clarity of the impact on your product’s development.
If you need to build something physical:

• Clearly understand the particular risk you’re trying to quantify.
• Try to answer the question with a focused “breadboard build” specifically designed to address that particular question as quickly and cheaply as possible. This effort may be particularly easy with optical risks: there exist a plethora of optics component suppliers who essentially supply “Lego” for optical breadboard builds.
• Resist the urge to design a prototype to do anything other than quantify identified risk—at least, without very rigorous discussion of potential benefits. At this stage too, scope creep is attractive, pernicious, and very rarely helpful.

 
When you’ve moved on to system design, ensure you build system-level prototypes. Rather than quantifying key elements of the design, these prototypes de-risk the interactions between different system parts, and later, proposed production techniques. No matter how smart and creative your team is, and how diligent your systems engineer is, the odds are good the “whole will be more than the sum of the parts.” The odds are also good that the “more” is not in your favor.

3. A Breadboard Prototype Is Not a Product

Proof-of-concept prototypes should be designed to maximize focused, quick, and efficient learnings. A product is manufacturable and reliable in the field. If you’ve built a working system using an optical breadboard and free-space optics (optical Lego), it is extremely unlikely it will be amenable to cost-effective production in any volume. If your prototype system requires half a week to assemble by a team of engineers—or worse yet, a single expert—it is not amenable to production in any volume. Manufacturable products have been designed for cost and cycle time from a very early stage, with calibration, repeatability, and the manufacturing techs’ sanity considered all the way through.

4. Pick the Mix of Hardware and Software Solutions that Work for an Optical Diagnostic Technique, and Your Team

The past few years have seen a revolution in the interplay between traditional imaging optics and software. Witness so-called “light-field cameras,” computational holography, and even smartphone cameras. As a simple example, you can choose to satisfy dynamic range requirements in a sensor either through judicious sensor choice or through software combination of multiple image exposures. Another example would be improving the lens design to improve the imaging resolution, vs. clever computational interpolation techniques.

When making architectural decisions, bear in mind the allowable acquisition time, power, and volume-claim budgets. If you want a handheld product, a graphics card simply may not fit regardless of how much your favorite computational imaging technique may require it. Also, be mindful of your design team’s composition: do you have the additional software resources with the expertise to implement novel imaging algorithms¹?
 
At the end of the day, you may be better off having the optical designer spend more time leveraging 400 years of optical system design than having the software engineer implement this year’s most popular image enhancement algorithm.

5. Be Aware of the Difference Between a Device and a Product

A new or improved technique to diagnose or treat illness is tremendously exciting. Still, there is a lot of difference and a long, long road between a technique, a device, and a product. A device physically implements a technique; a product is device that actually sells in sufficient volume to gain a foothold in the market. Ideally, this road is traversed without developers and manufacturers going bankrupt. It takes a lot of money to proceed from technique to product, and people have to eat. Further, at every instance an infusion of cash is required—the originators and early backers dilute their ownership. Keep this reality in mind.

It’s important to identify a market segment for your product. Consider not only the medical need for the device, but also the business constraints in which the device will be sold. Despite their passion for patient health, it is asking a lot of a medical practice to adopt a technology that hurts the bottom line. Will your device save labor or materials costs? Does it incur a substantial up-front investment? Does it enable a different workflow through shorter treatment time or ability to be used by personnel with lower levels of training? When selling into the U.S. market: Does it have a Medicare billing code, and is it cost-effective given the remuneration level for that code?
 
Admittedly, there is nothing in the above particular to optically based medical devices, but the point is so fundamental it bears repeating.
 
Most of the above advice is just good practice. However, it’s remarkable how easy it is for a team member or whole team to lose sight of this in the furor of the design cycle. Keep them constantly in mind, and your road to a successful product will be a far less rocky one.

Reference
¹ Note that many image-processing algorithms—including some of Google’s pixel imaging core—are available online. However, your team will still likely be the ones debugging any issues with your particular application!

---

Brian King is Principal Optical Systems Engineer at StarFish Medical. Previously Manager of Optical Engineering and Systems Engineering at Cymer Semiconductor, Brian was an Assistant Professor at McMaster University. Brian holds a B.Sc in Mathematical Physics from SFU, and an M.S. and Ph.D. in Physics from the University of Colorado at Boulder.