Schrödinger’s User Needs
Quantum Mechanics and Medical Device regulations have a lot in common.
Not going to spend too much time explaining quantum theory here, but Erwin Schrödinger created the allegory of a cat to better describe the idea of superposition; a particle can be in two different states at the same time, until viewed by an observer. In Schrödinger’s metaphor, he placed a cat and something radioactive in a box. The radioactive device could either kill, or not kill the cat.
The gist of the thought experiment was, if the box was not opened the cat was both alive and dead at the same time. I’m sure I did a bad job summarizing it, but if you want to know more, I defer to your personal astrophysicist, Neil deGrasse Tyson.
As your personal design control expert, I want to first lay out a key principle of design controls. Predictive testing. Namely, acceptance criteria must be established prior to executing any design control testing. It is clearly called out in the FDA Guide to Inspections of Quality Systems in its discussion on Design Verification. Page 39:
6. Confirm that acceptance criteria were established prior to the performance of verification and validation activities.
Verification and validation activities should be predictive rather then [sic] empiric. Acceptance criteria must be stated up front.
The reason for this is very clear, you don’t want companies to set their design inputs based upon how well their product performs. The company should set design inputs based on how the product needs to function. Ideally those functional requirements ensure that the product is safe and effective. If you are setting those design input requirements based upon how well the product performs, the company may be sacrificing safety and performance of their device.
Therefore, design inputs are very important to help ensure safety and effectiveness of medical devices. 21 CFR 820.30(c) describes them:
Design input. 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. The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements. The design input requirements shall be documented and shall be reviewed and approved by a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.
My bold emphasis was added above. You’ll see that as the regulations are written, the design input requirements need to address the intended use and user needs. You would then assume that maybe a prior clause talks about intended use and user needs, and you would be wrong. The only clause in design controls prior to design input is design and development planning, and trust me, that clause does not discuss intended use or user needs.
The FDA Design Controls Guidance has a very robust section on design inputs, but it also does not discuss user needs. It discusses how bad user needs can lead to bad design inputs and a bad design, but again does not talk about what is needed for a good user need. Just like the regulations, it just kind of assumes they exist. The celebrated waterfall image in the guidance shows that user needs are validated against the medical device, but it does not get into what a user need is.
The next place in the regulations where the terms intended use and user needs appear is design validation, 21 CFR 820.30(g), ”…Design validation shall ensure that devices conform to defined user needs and intended uses…” This is interesting, as it uses the word defined, which aligns with the previous discussion about predictive testing, in that you need to know what the user needs are before you validate them. But like I showed above, the design input section does not identify the need to define user needs, it just assumes that they exist.
For design verification it very much follows the concept of predictive testing. Early on you identify what the requirements are, and then later you test to demonstrate that the device meets those requirements. The regulation also identifies how to create and manage those design input requirements. This contrasts with design validation, where the regulations don’t identify a requirement to create user needs early in development, they just kind of expect the user needs to exist. The regulations even use the phrase defined user needs when executing design validation, without talking about how to create and manage user needs, in contrast with design input requirements. The regulations expect user needs to exist, without saying that user needs exist.
Essentially user needs both exist and do not exist at the same time, in a state of superposition. Very similar to Schrödinger’s Cat, both alive and dead at the same time.
I was curious to see if the FDA has issued any warning letters related to user needs. I reviewed 24 FDA warning letters going back to 2018 where there was a citation related to user needs. All but one used the phrase user need in relation to not properly validating the device, and not in relation to inadequate user needs. That one warning letter was really around the design change process, so I will choose to ignore it here, as is my prerogative.
So where does this get us? User needs are very important as they drive good design input requirements and are needed to perform predictive validation testing. But they are not important enough to be specifically called out in the regulations, nor cited as inadequate by the FDA. User needs both need to exist, and do not need to exist. They are the Schrödinger’s Cat of medical device regulations.
But honestly, this post is really a nitty gritty look into the minutia of the FDA design control regulations and has been an interesting thought experiment. As for the design control process, manufactures should develop, define, and document user needs as part of their design input development stage. User needs don’t need the same specificity that are essential in a design input requirement, but they do need to be validatable. That is, you can give the full medical device to a user with clear acceptance criteria to demonstrate that the user need was met.
Just be careful opening your design history file box during development, either your user needs are going to exist, or your entire project may just be dead.
Note: No cats were harmed in the writing of this article.
