Understanding the connected, wireless medical device development process

Today I want to talk about the process for developing connected wireless medical devices.

Let’s take it one term at a time, starting with the end – medical devices. Any time you’re developing a medical device, you’re gonna wanna follow a process that, essentially, is dictated by FDA and is aligned with what’s given by ISO 13485.

That means it’s five or six steps around that: Generating user needs, understanding who the user is, What is the intended use? What are the indications? What are the user requirements? What does this product need to do for the user?

From there you can then generate design inputs, which are all the requirements – the system level requirements, the sub-system requirements. And usually you do that alongside development of an architecture for the product. Those go hand-in-hand because, depending on the architecture, you’ll have different sub-systems and different requirements for those sub-systems.

After that, you go through the actual engineering process – developing the device, writing code, doing schematics, doing layout, doing CAD drawings and prototyping, all of that.

And at the end of that phase what you have are design outputs, which are all of your drawings, your schematics, your source code, your packaging, anything that’s required for launching your product.

From that, you go through a design verification phase – ensuring that your design outputs meet your design inputs. In other words, for this thing that you’ve designed, each of the levels of sub-systems and then the product as a whole meets the requirements that you set up in your design inputs.

After that you’ve got your design validation phase – ensuring that the final product, the final design, meets the user needs.

The last phase of this would be transport and manufacturing. That’s where you take all your design outputs, you create what’s called the device master record, and you transfer that over to a contract manufacturer. Or, if you have manufacturing capabilities, you do that in-house. But you go through that whole process of taking all of these design outputs and transitioning them to manufacturing.

That’s generic product development. There’s some best practices within that that allow you to, ultimately, launch a better product.

You know, at Bold Type we like to use Agile, for example, in some of our software development, to split up the overall development into phases, and do some user testing over that period of time, be iterative about it, so that you eventually launch a better product.

But, from a general point of view, that’s what’s required for practically any medical device.

When it’s a wireless medical device, there are a couple of additional steps that you have to take. The first one is selecting the right architecture.

So let’s say you’re developing a blood pressure monitor that wirelessly connects to a cellular phone, and then that data goes to the cloud.

The first thing you have to do is select what type of wireless connectivity are you gonna have.

Is it gonna be Bluetooth, Bluetooth low energy? Is it going to be WiFi? Are you gonna go directly with a cellular technology, like a 4G, or an LT mobile, like LTM, which is a very low-power version of cellular, such that the data goes directly from the device all the way to a cell tower, and from the cell tower to the cloud.

That might be another approach, so you have to select the technology that you’re gonna use.

Then you have to develop the product. Importantly, during the verification test, there’s a couple of other tests that you’re gonna have to do, such as electromagnetic compatibility.

IEC 60601 is used for safety standards of electrical medical devices. And that’s a general one, but there are also some specific ones for things like electromagnetic compatibility – an extra test that you would have to do if it’s a wireless product.

And then, of course, FCC. You have to make sure that you’re not going to be violating FCC rules that get you in trouble. You wanna make sure that you’re not radiating outside of the bands that you’re supposed to be in, that your upper power isn’t too high, that your bandwidth isn’t too wide, or too narrow, those sorts of things. That’s the wireless piece of it, and then, last, there is a connected piece of it.

You’re connecting to the cloud, and you have to ensure that you’ve got proper cybersecurity. It’s really important, so make sure that you do proper risk analysis and mitigate for any potential risks.

It’s different if you’ve got something like I mentioned earlier, like a wireless blood pressure monitor, than if you’ve got a pacemaker. If somebody hacks the blood pressure monitor, the risks associated with that are not as high as if somebody hacks a pacemaker.

You have to do a proper risk analysis around that, and then put in place proper risk controls. You have to have the right architecture, and then you can incorporate features, like over-the-air software updates.

That’s a really valuable feature. It means that, after you launch a product, if there’s an update that you wanna make, if you wanna improve the functionality, if you want to fix a bug that you found, you don’t have to recall the product and bring it back.

You can do an over-the-air firmware update, or an over-the-air software update that improves the product while it’s in the field. And there’s some regulatory things that you have to keep in mind, but you don’t have to necessarily go through a new 510k to do that.

It’s one of those strong benefits, but you have to make sure you do it right, because if you do it wrong, you can effectively damage the product. You can brick it – make it such that the device no longer functions and you can’t update it. So it’s really important to get that right.

Those are some of the processes that you follow to develop connected wireless medical devices.

We strongly believe that if your device is not connected to the cloud, you risk obsolescence, and we should talk. I’m Jose Bohorquez at Bold Type.