Building medical devices and software for the diabetes industry takes an incredible amount of planning from day one. There are so many things to consider in terms of meeting regulations, managing risk, and ensuring quality results, that many developers often forget to consider their user needs.
This is unfortunate because defining your end user needs early on in the process can be highly beneficial in helping you design a quality device. The goals of the end user are not, in themselves, design inputs. But they do provide actionable insights to allow you to create inputs that drive successful device development.
In this article, we’ll look at the importance of defining diabetes medical device user needs before development begins. Then we’ll look at five considerations to help you better define your user needs. Putting these into action will help you develop a product that is instantly marketable to the intended audience.
Why Defining User Needs for Medical Devices is Important
User needs outline how a medical device should function in terms of its intended use. The FDA sees user needs as the basis for all design controls. From this starting point, you can set design controls that will naturally cascade down into the other steps within the process.
In short, defining user needs is important in order to build the device to meet your intended use in a way that works for the intended user. But the benefits of taking time to consider user needs before development begins has far more advantages than just that.
Here are a few of the most important things that defining user needs accomplishes:
- It focuses the device product design and development processes. Having a concrete idea of user needs ensures that the device creation and build are as effective and efficient as possible.
- It ensures the team sees a unified vision for the device. User needs set clear expectations of what the device is supposed to do or accomplish. This helps keep everyone focused on the same goals.
- It improves the performance and quality of the end product. It’s easy to get distracted and want to add more functionality to a product as it becomes a reality. Defined user needs help create a final product that performs better for the intended user by forcing focused developmental goals.
- It makes design validation easier. Defined user needs help set concrete goals. Having concrete goals makes it easier to know if your intended design has been achieved.
- It streamlines regulatory approval. When the end product stays in line with set user needs, it makes regulatory approval easier to achieve by providing a clear definition of what the product is intended to do and who should use it.
- It ensures a market exists. By creating a clear picture of your user before you start building, you ensure someone will want it when it’s done. This makes for a more successful market launch and ensures more satisfied users.
What to Consider to Define Medical Device User Needs
In order to turn user needs into actionable steps used to create design inputs and controls requires early evaluation of these needs. The following five questions will help you better define the user needs for your device in order to efficiently create a more effective product.
WHAT will the device be used for?
One simple way to think about what your device will be used for is to define its “intended use.” In other words, what, very specifically, is the device meant to do?
A continuous glucose monitor, for instance, is meant to replace finger stick blood glucose readings for diabetes treatment decisions. A mobile medical device (MMD) that combines multiple device metrics may be meant to inform diabetes treatment decisions.
What the device will be used for doesn’t tell you who the user will be. And it doesn’t tell you what the user’s needs are in any specific terms. But what it does do is tell you how the device will be useful and this will help inform who the device will be useful for.
You will need to submit a very clear and concise “intended use” statement on your 510(k) submission. Defining this detail early on in development will make the approval process that much easier.
WHO will use the device?
The intended use of a medical device tells you what it does and gives you an idea of who might use it. The “indications for use” for the device clearly state who it is made for. These two definitions seem similar but have important distinctions.
To get an idea of what those are, let’s take a look at the intended use and indications for use verbiage for the Omnipod 5 ACE Pump.
- Intended Use: the subcutaneous delivery of insulin, at set and variable rates, for the management of diabetes mellitus in persons requiring insulin.
- Indications for Use: individuals with type 1 diabetes mellitus in persons 2 years of age and older.
While the intended use tells us the device helps in treating diabetes, the indications for use define who, exactly, should use the product. Once you have this defined you can start painting a picture of your end user and begin defining their needs.
To do this, look beyond the broad user definition required by the FDA. Omnipod, for instance, won’t be the first choice for all people with type 1 over the age of two. But it will likely be the first choice for active youth and young adults living with type 1 diabetes. The further you define this optimal user, the easier it will be to create a product they will love.
Here are some questions to ask and answer about the most likely future users of your product:
- What is their age range?
- Will your device be preferred by males or females?
- Where does your user live?
- Are they more likely to have diabetic complications or additional health problems? What would these be?
- What is their income range?
- Are they likely to be insured?
- What is their average education?
Once you’ve answered these questions consider how these answers inform your user’s ability to interact with and use your device. Translating these characteristics into user needs is the most important step in this process.
WHERE will the device be used?
Who your user is isn’t the only thing that will determine their needs, however. You also need to consider where this device will be used. After all, your optimal user will have different requirements for an inpatient device compared to a device they use in their daily lives.
Diabetes medical tech and medical software can be used in hospitals, outpatient facilities, or at home. Within these categories, you can further define where and how the device will be used. Is it going to travel on or with the person or is it used infrequently? Is it disposable or long-lasting?
The answers to these questions will determine how durable, conspicuous, big/small, loud/quiet, and more your device should be in order to meet the user needs.
What TYPE of device will it be?
This is probably the one question you’ve put the most thought into regardless of how much you’ve considered user needs. You know what you’re making. Maybe it’s a CGM, a pump, a tracking app, or something never seen before. But have you considered how what your device is will play into the end user needs?
Consider how the end user will interact with the device. Will they use their smartphone, a receiver, or maybe a connected device? Does the device require Bluetooth or wifi connectivity? Is it highly customizable or is the user interface simplistic?
Fifteen percent of medical error deaths are caused by medical device user interface problems, according to a Johns Hopkins study. This is why thinking about not just what your device will be but how your user will control it is so important.
What INTEROPERABILITY needs should be considered?
So many devices created today are made substantially better through interoperability with other devices the user has. In fact, given how tech-heavy diabetes care has gotten, interoperability is quickly becoming a make-or-break situation.
If your physical device can connect to apps the user already has, they will be more likely to choose it over a competitor. If your software can work with a range of different devices, then all the better. But don’t just set your interoperability goals for connecting to the obvious. Consider what else the user might want their device to interact with.
Pumps and CGMs communicating is now the standard. But what about software that also connects Fitbits and pulse monitors? Or behavioral motion sensors that automatically insert meal events on CGM graphs?
If your user could use it then it’s worth considering during development.
Interoperability with a range of products and software requires quality software development kits and a component architecture design. Understanding your need—based on the user needs—early on can help you decide on the best build for your device.
Understanding User Needs Early Makes for Safer Products
By and large, major recalls in the diabetes medical device industry occur when developers fail to fully consider user needs. If you don’t have a definitive picture of who will use your device and how early on in the process, you will miss potential avenues for error. These could be as simple as not creating durable enough housing. Or as complex as failing to consider a potential command input pattern error.
When creating devices designed to help people with diabetes live better, you have to take the time to look at every possible user need. While time intensive up front, doing so will pay off in the long run. Not only will you end up with a better product that is already prepared for approval, but you’ll know with a high degree of certainty that a market exists for it.