You guys are hitting one of my pet topics here, so feel free to just skip, but I can't help saying my piece.
This is EXACTLY what happens when a bunch of regulators and QA/RA professionals try to integrate systems engineering and robust design practices into standards in regulations. You get a bunch of the principles sort of right and then jumble the jargon to confuse even those who do understand the concepts. Then you promulgate it such that everyone thinks it is a "regulatory requirement" and not an actual attempt to help design good practices.
As even a semi-trained systems engineer can tell you, there are a variety of "Voices" [aka User Requirements] including Voice of the Customer, Voice of the Business and what my original business called "Voice of the Application." [others call this different names and sometimes split it differently]
Voice of Customer is exactly what it says - what is it the customer wants/requires that you are designing the product to deliver. Usually not everything a customer might possibly want, but what is within the realm of the product you can deliver.
Voice of the Application - this consists of things you must do but you can't control. Follow laws that apply. Deal with conditions in the use environment in which the product will be used etc. Generally true "regulations" and laws sit in this bucket.
Voice of the Business - this is a huge box and often broken down into things like Voice of Manufacturing, Voice of Service, Voice of Regulatory etc. In its purest form, standards should sit here - they are voluntary requirements that can make some aspect of the business, including the regulatory process, easier.
Thus, "must have a cleared 510(k)" is a legal or VoA requirement, while "must meet ISO 10993" is a business requirement. However, I know a lot of MedTech companies actually treat standards as either their own bucket, or roll it into VoA, simply because they are so pervasive across our industry, and while you CAN legally do things other ways, most often the hassle isn't worth it.
In robust design, all of these "Voices" get translated into requirements. Usually there are tools that also help you weight these requirements, so that when conflicts arise, designers know which ones take precedence. The requirements then get deconstructed to lower level requirements, and in complex products, assigned to one or more specific subsystems. The requirements around the relationships between the subsystems are captured in interface documents that then feed lower level requirements. Additional lower level requirements may also enter as design decisions are made [think - hey we decided to ETO sterilize, rather than some other type of sterilization, so now all the ETO standards become requirements]
In the end, all these requirements drive a specification (functional, dimensional etc), manufacturing process requirement etc. Then one verifies that all these specifications meet the requirements, across the various levels. However, a good systems engineer knows that "verification does NOT equal test" - yes, sometimes statistical testing is the best way to verify a requirement is met, but other times simple inspection by a trained person is sufficient. Still other times that verification may be inspections of ongoing materials.
And finally, you validate that the top level requirements and/or the "voices" were met. One could argue a top level VoA requirement of "must have cleared 510(k)" is validated by the actual clearance.
All this is well established best practices in systems engineering, as are many other robust practices like how to actually write a good requirement and capture the "voices" appropriately. I am positive this best practice is what the original design controls intended to capture. But since obviously few of those authors were trained in the practices, and even those had to take "public comment" along the way from people who had no understanding of it, we instead end up with a bunch of differing and sometimes conflicting terminology, that leads an entire generation of med tech employees to think of these a "quality systems" or "regulatory requirements," rather than robust design practices; which in turn leads to regression to the mean (or worse) in many engineering departments and does as much to hurt the implementation of robust design practices as it helps. And finally leads auditors who clearly are not trained in robust design practices to ask nonsensical questions such as the finding which started this thread....
OK, done ranting....
------------------------------
Ginger Glaser RAC
Chief Technology Officer
MN
------------------------------
Original Message:
Sent: 23-Oct-2019 08:32
From: Ary Saaman
Subject: Regulatory requirements in Design Inputs - Audit Deficiency
I think it is more a matter of history than of irony … .
The Quality System Regulation was published in October 1996 and does not contain verbiage explicitly requesting that "regulatory requirements" be part of Design Input. Nor did EN 46001:1996 contain such verbiage.
ISO 13485:2003 @ 7.3.2 states that Design and Development Inputs shall include applicable statutory and regulatory requirements.
And as said previously, ISO 13485:2016 @ 7.3.3 requires that Design and Development Inputs shall include applicable regulatory requirements and standards.
All of this probably reflects the increased reliance on the use of International Standards (as published or as adopted/adapted as Consensus Standards by FDA or Harmonized Standards by the EU) for demonstrating safety and performance of medical devices to the regulators. Also FDA's ASCA (pilot) program fits within this scheme of increased reliance on International Standards.
On a side note : the Quality System Regulation does have a definition of "specification" as per 820.3(y) : Specification means any requirement with which a product, process, service, or other activity must conform.
Enough for today … with kindest regards,
------------------------------
Ary Saaman
Director, Regulatory Affairs
Lausanne
Switzerland
Original Message:
Sent: 22-Oct-2019 14:32
From: Julie Omohundro
Subject: Regulatory requirements in Design Inputs - Audit Deficiency
Agree about the terminology. It's a mess. And yes, as Arthur notes, almost certainly US-based.
As for 7.3.3., yet another good reason to resist replacing the QSR with the standard, IMO.
PS. Is there a certain irony here, with the standard calling for inclusion of regulatory requirements, while the regulation does not?
------------------------------
Julie Omohundro, ex-RAC (US, GS), still an MBA
Principal Consultant
Class Three, LLC
Mebane, North Carolina, USA
919-544-3366 (T)
434-964-1614 (C)
julie@class3devices.com
Original Message:
Sent: 22-Oct-2019 09:21
From: Ary Saaman
Subject: Regulatory requirements in Design Inputs - Audit Deficiency
Two short notes from my end as a small contribution to this thread :
Note 1 : ISO 13485:2016, @ 7.3.3 (b) states that Design and Development shall include applicable regulatory requirements and standards.
Note 2 : indeed, the different terminologies used do not necessarily help clarify the issue. I prefer to use as much as possible the terminology from international standards and/or FDA regulations and guidance documents rather than proprietary or legacy terms such as "User Requirements Specifications" or "Product Requirements Specifications". Personally, I already have an issue with the term "Specification", which for me means something that is specified with sufficient detail for someone "skilled-in-the art" to understand it. In this approach, the term "Specification" may be used in relation to Inputs as well as to Outputs. E.g., SRS = Software Requirements Specification means that the software inputs are documented with sufficient detail for the programmer to unambiguously perform his programming tasks. And, e.g., Design Output Specifications contain a detailed enough description for production staff to unambiguously understand what product they have to build (and for the sake of clarity I would always use the term "Design Output Specifications" rather than "Design Specifications").
With kindest regards,
------------------------------
Ary Saaman
Director, Regulatory Affairs
Lausanne
Switzerland
Original Message:
Sent: 18-Oct-2019 00:54
From: Anonymous Member
Subject: Regulatory requirements in Design Inputs - Audit Deficiency
This message was posted by a user wishing to remain anonymous
Hi ,
We received a deficiency from a mock audit and MDSAP stage 2 on not including clear regulatory requirements in the Product requirement specification . Its not possible to actually state all the regulations into the PRS ? Is there an easier way , if we could reference a regulatory matrix defining the requirements of the MDSAP countries and EU , would that be enough ? Its difficult to keep this up to date with the changing regulations and go through the change process each time a new country is added or a new requirement / standard becomes effective..
Can you suggest how are you managing this requirement ?
Thanks,