A Beginner’s Guide to Design Controls for Connected Medical Devices

Are you developing a new, connected medical device?

If so, (or if you’re developing any other kind of medical device), you’ll need a good grasp of design controls. FDA is the origin of the term “design controls” and you’ll find their requirements in 820.30. However, most other regulatory bodies have regulations in the same vein as design controls – for ISO, you’ll find similar requirements under 13485:2016, 7.3 -Design and Development, for example.

Design controls form part of your quality management system requirements, which are an essential part of the medical device development journey. Ultimately, your design controls help to prove that you’ve developed a safe, effective device.

Here’s what you need to know

What are design controls?

Design controls are a formalized approach to developing medical devices that encompass user needs, design inputs, design outputs, design verification, and design validation.

These represent several layers of documentation requirements, so one best practice is to have a traceability matrix that shows the relationships between each of these design controls. Having a clear map helps to prove to the FDA (or other regulatory bodies) that you’ve met regulatory requirements and followed best practices to develop a safe, effective device.

Do you need design controls?

First of all, not every medical device requires design controls, although any developers can certainly use them as a clear internal system. In terms of regulatory requirements, most Class I devices don’t require design controls, while all Class II and Class III devices do.

Where do you sit as a connected medical device? This hinges on your product’s intended use, indications for use, and level of associated risk. You need to be absolutely clear on these things early in the process so you can define your device class and initiate design controls as soon as possible.

For example, while Class I devices might be exempt from design controls, they’re also limited in terms of the claims they can make. In general, Class I represents low-risk devices that promote general health and wellness. An app that provides data on your sleep patterns might fall under this because it’s not claiming to treat sleep issues or give health-critical advice.

On the other hand, the Apple Watch is an example of a connected device that is classified as Class II. This is due to its irregular heart rhythm warnings and EKG functionality, but it can also be seen as a strategic move. Taking the time and effort to go through Class II approval means Apple has design controls in place and could choose to make lateral moves within the category.

Core components of design controls

Every medical device begins with an idea. Sometimes that involves a quick, “back of the napkin” drawing while you come up with your initial idea, but as soon as you decide to go ahead with development, it’s important to formalize your documentation.

Let’s say your connected device is home-health related, but you want to be in a position to expand and offer additional indications for use later (like Apple Watch). It makes sense to assume you’ll need design controls in place, including the following:

User needs

You need to clearly define the needs of your users and how your medical device will meet those needs. The idea is that you should always start with the user and ensure you fully understand their needs, before getting into any engineering.

A common mistake is to make assumptions about user needs – if you’re not the target user, how will you really know what those needs are? As this Greenlight Guru article indicates, dig deep. Sometimes you need to look below the surface of what a user thinks they need…

Design and development planning

You’ll find design and development planning under section b) of FDA’s 820.30, and section 7.3.2 of the ISO requirements. Both are similar in terms of intention. Here’s an extract of the FDA’s requirements:

• Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation.
• The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process.
• The plans shall be reviewed, updated, and approved as design and development evolve.

That second point basically translates to mean you’ll create a plan that shows exactly how you will manage each of the design control components throughout the development process.

Design inputs

These are the exact specifications of your product, including what it will do and how. Your user needs should lead directly into design inputs and you should look upon your design inputs as absolutely critical to the success of your development.

It’s important that design inputs are measurable. While you might have a user need that says something like “we need to keep better track of patient blood pressure,” “better” is a subjective term. Consider other sources of information to inform design inputs too, such as regulations and competitor products.

Any connectivity components of your device should be considered carefully as part of design inputs. Will your device collect data and send it somewhere else for analysis? Will it analyze data and send alerts to patients or physicians? How will it connect – with WiFi or Bluetooth?

Design outputs

These document the exact components, parts, and processes required to assemble your finished medical device. You’d give these documents to anyone who is going to be manufacturing your device for you. It’s a bit like a recipe for your device.

Design review

You (or your team) are required to conduct design reviews at various points throughout the design process. These require formal sign-off and are an opportunity to review your design requirements and check that your development is on-track.

Design verification

Design verification relies on you having completed design inputs and design outputs. The goal of design verification is to prove that your design outputs meet your design inputs. In other words, has your device been correctly designed? Does your device work as intended?

Design validation

Design validation is about proving you’ve designed the right medical device. What we mean by that is, your device meets user needs and intended uses. Validation involves product testing and should have a robust plan in place. Your design validation plan should have goals for validation and list how you’re going to test to see if you’ve achieved what you laid out with user needs and intended uses.

Design transfer

As soon as your device goes into production, you will go through design transfer. For example, your design outputs become the basis of your Device Master Record (DMR), which holds the records of your device specifications.

Your product lifecycle

One thing that’s important to note about design controls is that they apply to the entire lifecycle of your product, from design through to active production. Your connected device is bound to have software updates, for example, and all of this information must be documented.

Final thoughts

To be in the best position to both comply with regulations and produce a safe, effective medical device, developers should be across these various components of design controls early on. Your life will be much easier if you document as you go, rather than having to painstakingly work backward to build up documentation that you need for approval.

For connected devices, your design also has to take into account things like cybersecurity. It’s important to have a secure platform to protect data collected by your device.

Galen Data can help by providing a secure, compliant cloud platform so that you don’t have to start from scratch when building connectivity into your device. Contact us today about how we can help you.