Reference designs for medical device development are a great way to ramp up a project faster and more cost effectively. At work, we’ve adopted a strategy of developing our own reference designs of subsystems that we believe will be useful in future projects.

A reference design is an implementation of a technology – such as a mechanism or circuit – that can be used to demonstrate and test its applicability to a particular use. Our intent is that they can be copied, modified and incorporated freely into our clients’ product designs to speed development and leverage our internal expertise.

Rapid Prototyping

A ready library of reference designs allows faster development of experiments and proof-of-concept prototypes for early de-risking of a proposed architecture. It also enables putting a development environment together with minimal effort to get the design team started as fast as possible.

When we start developing an architecture for a new medical device, it is often challenging to select a candidate technology with confidence that it will meet all the requirements. If the tech is already implemented in a vanilla form as a reference design, we can more quickly evaluate it and confidently move forward.

Focus on the Application

With most projects, there is time spent simply implementing what I call table stakes tech. These are components and subsystems which are necessary for a product but not really specific to the application. An example of this is a CPU system to support a GUI. Ideally, a medical device development team will focus most of their time on the application specific technology, not the table stakes.

De-risk Early

One big advantage of developing reference designs is de-risking some tech early, before you’re on the critical path of a medical device development program. Similarly, we can explore the level of difficulty in harnessing a particular tech, which allows us to better estimate a program cost that is going to use it.

Often there are all sorts of gotchas involved with getting a handle on a specific technology. This is normal, but if we can successfully work through these in advance and capture the results in a working and reusable implementation, then our device development will go much more smoothly and predictably.

Interestingly, we often overlook the risks associated with table stakes tech. We fall into trap of thinking that a particular tech is well understood in industry and therefore low risk to us. We forget that harnessing that tech, getting experience with that tech, is still tricky, even if it’s not the primary focus of the product.

Control the Stack

By having control over the complete design, we can deploy it in any way we want in product designs without being encumbered by IP issues.

The difference between using an internal reference designs and other off the shelf (OTS) solutions is that we have complete control over the whole stack. We can customize any aspect of the tech without running into licensing issues. An OTS quick fix may solve an immediate problem but may not be compatible with the business needs in the future. In addition, by knowing the design inside and out and being able to customize it at whatever level is required, we can much more confidently apply it in novel ways that might otherwise not be possible.

So what are they good for?

Our reference designs are great for early exploration of the applicability of some tech. If I’m worried about using a particular circuit or mechanism in a product, I can quickly check them out. For instance, if I’m worried that a CPU might not have the processing capability for some complex algorithm and I happened to have a reference design handy, I can quickly lash up an experiment to shed some light on that concern.

Reference designs are also great for quickly building test jigs. Let’s say a concern is raised about the longevity of a bushing and I happen to have an internal reference design that can automate the control and cycling of a motor, then I can whip up an automated wear test experiment.

Reference designs allow for quick incorporation of a technology into a product design and the design reuse can happen at many levels: directly with hardware, at a design level by reusing components, by cut-and-paste by copying and modifying design files or simply by inspiration. They leverage all the experience and testing that went into the design development.

Reference Designs are also a great platform for improvement. As we learn, develop and use them, we invariably figure out enhancements. These learnings then lead to an evolution of our reference designs, giving us more experience and confidence in their application.

What are they not?

One thing to keep in mind is that reference designs are not intended to be subcomponents of production medical devices. We always assume that the technology may get used in a product, but it will always involve customization. The needs of every medical device are always very different and hard to predict. It would be mostly impossible to define reference designs so that they perfectly suit every device design. I can imagine a day when we’ve developed a few designs to the point where they could be used directly as a subcomponent of a medical device, but that’s not really the intent. The designs are primarily for a head-start in prototyping. The expectation is always that they will be customized, adapted and assimilated into a specific medical device design.

Another thing to remember is that no matter how confident we are in the capabilities of our designs, invariably they will get pushed out of our comfort zone in many applications. That’s okay, so long as we recognize this and test them for suitability when we’re worried. Just because they’ve proved to be great in the past does not mean they necessarily will be great for the next device development program that comes along.

Finally, the way we develop and use reference designs, they will never be finished. That’s part of the magic of this approach. We will always improve upon them. We will always think of new ways to expand their capabilities. That way we leverage the technology exponentially; we build upon them as platforms and incorporate more and more table stakes tech.

Examples

We have a number of internal reference designs for medical device development in various stages of development. The most advanced one we call the StarFish Data Acquisition System. We abbreviate it SFDQ for short. The SFDQ consists of PCB with a micro and firmware, a bunch of analog and digital IOs, some high-power half-bridge outputs, high resolution ADCs and a few other bells and whistles. The system also includes an extensible, multi-drop communication protocol and a PC application for automating control, display and logging of information. We’ve deployed the SFDQ in all sorts of ways in proof-of-concept prototypes: directly in its PCB form, by cut-and-paste of PCB layouts and also just using snippets of it, like compiling the firmware onto a different MCU target and schematic reuse with a totally custom layout.

Another example is a CPU-module reference design that we use as an early software development platform and as a basis for product specific custom PCBs. This allows us to get GUI development up and running as quickly as possible and reduce the number of common first-spin PCB issues for these sorts of higher complexity boards.

One of our newer reference designs is for proof-of-concept microfluidic system development including the assay, the cartridge and the reader. The goal here is to allow our clients to dig into their assay development as quickly as possible and focus on the custom aspects from the beginning. We have a standard cartridge form, interface and build process, as well as automated actuation and quantification hardware. There’s a ton of breadth here depending on the assay type and detection strategy but we’re targeting the commonalities first and working quickly to increase the capabilities.

Yet another family of reference designs we’ve had success with is a web connectivity platform. The goal here is to provide capabilities related to allowing our instruments and client-side applications to communicate in a cyber-secure and developer-friendly way.

We have a bunch of other designs too, some of which are in very early development. If I’ve learned anything with this approach, it’s how powerful it has proved to be. I’m always looking for new possibilities that we can develop and de-risk and thereby allow us to efficiently and predictably develop great medical devices. Hopefully I’ll have a bunch more examples to talk about in the future!

So far, our reference design strategy has been really working. We can ramp up a project faster and more cost effectively than ever, with confidence that our table stakes tech is solid. Creating working prototypes has never been more efficient. I’m really excited to identify new opportunities to apply this approach. I’d love to hear from readers about their reference designs and experiences.