Tips For Developing Medical Device User Needs, Intended Uses, And Design Inputs
By Byron Larson, president, Toltec Ventures
The FDA’s Design Control Guidance for Medical Device Manufacturers states, “Development of a solid foundation of requirements is the single most important design control activity.” This concept is likely to be self-evident to experienced medical device practitioners. However, what exactly is meant by the term “requirements”?
From FDA’s design control regulation point of view, a clue is given in the Design Input section of the Quality System Regulation – 21 CFR 820.30(c), which reads “Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient.” And Section 820.3(f) defines design input as “the physical and performance requirements of a device that are used as a basis for device design.”
Further, the Design Verification section of the Quality System Regulation – 21 CFR 820.30(f) explains that, “Design verification shall confirm that the design output meets the design input requirements.”
Last but not least: “Design validation shall ensure that devices conform to defined user needs and intended uses and shall include testing of production units under actual or simulated use conditions”, from the Design Validation section of the Quality System Regulation – 21 CFR 820.30(g).
Additional context can be found in a recent FDA design control presentation [PDF]:
Design Verification:Design Validation:
- Design output meets design input
- “Did I make the product right?”
- Design output meets user needs and intended use(s)
- “Did I make the right product?”
How Can We Meet These Needs?
While the regulations are clear about needing requirements targeting user needs and intended uses and separate verifiable design inputs, the regulations are deliberately vague about how to construct requirements in the real world. Industry is required to have design control quality system procedures, which define how your company specifies requirements for your medical device project.
There is no explicit regulation on how many requirement documents to create. There is no standard in terms of naming convention, either. This is where your quality system procedures need to give clarity.
Naming Convention For User Needs And Intended Uses
First, look at naming convention. Within the medical device industry, user needs and intended uses reside inside of documents with many different names: User Needs And Intended Uses Document, User Requirements Document, Marketing Requirements Document, Customer Requirements Document, a chapter in a Product Requirements Specification, a chapter in a System Requirements Specification, and most surely several names that are not listed here. The important point is not the name of the document where the user needs and intended uses reside, but that you know what they are, where they are, and how treat them.
Naming Convention For Design Input Requirements
Similarly, verifiable “design input requirements” are placed inside of documents with names like Design Input Requirements , Design Input Specification, System / Engineering Requirements Specification, a chapter in a Product Requirements Specification, a chapter in a System Requirements Specification, and so on. In this case, the name of the document is also less important than knowing where the verifiable design input requirements exist, knowing what they are, how treat them, and how they differ from the user needs and intended uses.
Number Of (Product-Level) Requirements Documents For A Device
At a medical device product level, there are two common practices for constructing requirements. The first is to use a single requirements document that captures user needs and intended uses, as well as verifiable design input requirements. An example of this would be a product requirements specification that had a section focused on user needs and intended uses and another section focused on the design inputs targeted for verification.
The second common method is to have two separate documents. An example here would be a user needs and intended uses requirements document as well as a separate engineering requirements specification that once again addresses design inputs that require verification.
How Do User Needs And Intended Uses Relate To Design Input?
At the most abstract level, user needs and intended uses need to be validated. Separately, design verification needs to show the design inputs meet design outputs. However, these basic regulatory needs do not explicitly show us the link between user needs and intended uses and design inputs.
Many practitioners in the industry do make assumptions about this relationship. For example, many companies attempt to trace every user need and intended use to a separately developed verifiable design input derived from the user need/intended use. This can be done, and it is clearly one way to show separation of requirements targeted for verification versus those targeted for validation.
Are User Needs And Intended Uses Considered A Subset Of Design Inputs?
The Design Input portion of 21 CFR Part 820.20(c) states, “Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient.” In this context, it is not always logical to contrive a link between the two. One can successfully keep a group of requirements targeted for validation separate from a group of requirements targeted for verification and not attempt define a traceable derivation of one to the other. This, again, is an area where the design control procedures in the quality system need to spell out the methodology.
The product-level design inputs are the basis of the engineering design of the medical device. As a result, lower-level specifications (software, mechanical, electrical/electronic) need to use the design inputs as their basis.
What Guidelines Are Important To Take Into Account When Constructing Requirements?
First and foremost, user needs and intended uses need to be possible to validate. While these are usually somewhat less prescriptive than lower-level requirements, they still need to be measureable or testable. Similarly, the verification based “design inputs” need to be possible to verify in an explicit way. However, there is more to take into account than V&V. Are the requirements possible to use for design? Are they comprehensive? Are they clear and unambiguous? Are they attainable? Are tolerances supplied where appropriate? Is there too little detail? Is there too much detail? Is implementation being specified (“how”) instead of “what” the medical device is supposed to do? All of these aspects are important.
How Do These Needs Differ With Different Types Of Medical Devices?
A collective set of medical device requirements should look different for different types of medical devices. For example, the quantity, style, levels, etc. of requirements documents for an MRI machine compared to a surgeon’s glove should look different. Requirements management becomes exponentially more challenging when the medical device becomes more complex.
With a medical device like a surgeon’s glove, one can have separate documents for user needs and intended uses, design inputs, and engineering drawings. Everything can be shown to be tied together in a nice traceability matrix. Regulatory intent can be defined on a document-by-document basis.
For an MRI machine, we have product-level requirements — some user needs and intended uses, some design inputs targeting verification and the design of the machine. Further, we may have subsystem requirements, functional subassembly requirements, software requirements, and eventually our lowest-level engineering drawings for mechanical and electrical components, as well as the source code of the machine. In total, this medical device could easily have five layers of requirements and specifications.
Further, some of the requirements documents (the software, for example) can have several hundred, if not thousands, of requirements. This device needs a strong dose of systems engineering thought to go along with the regulatory needs covered by each of its requirements/specifications. The number of document layers, the rules you have for traceability, and where and how your test program will be conducted are considerations with far-reaching consequences in this example.
In summary, your medical device project and your procedures must address the thought processes conveyed within the Design Control section of the Quality System Regulation. There are different ways to do this, and ideally you will optimize based on the characteristics of the types of medical devices you develop. For example, if there is a natural relationship between higher- and lower-level requirements, a natural testing methodology, and/or a natural way to optimize requirements/specifications for design, then it would often make sense to let those considerations help shape your design control procedures.
About The Author
Byron Larson is founder and president of Toltec Ventures LLC Inc., a consulting company specializing in medical device product development. Before the formation of Toltec Ventures, he was president of Toltec International Inc., and prior to that he held several engineering and engineering management roles while at Gambro AB and COBE Laboratories Inc. Larson has received BS and MS degrees in mechanical engineering and is a registered professional engineer in the state of Colorado. He can be contacted at byron.larson@toltec.biz.