When does the ‘R’ end and the ‘D’ begin for medical device companies?
Some manufacturers have difficulty in determining where research ends and development begins. – Design Control Guidance for Medical Device Manufacturers (1997)
Yeah- no kidding!
The FDA doesn’t approve napkin sketches – I think we all know this by now. But those napkin sketches do represent a critical step in the overall development of a novel medical device or technology. “Research and Development” – ye olde R&D – is a ubiquitous term in our industry that gets tossed around in everything from regulatory submissions to McKinsey company market reports. Here’s the catch: usually, its being used incorrectly!
Research and Development ≠ Research!
From large companies to small start-ups developing products for the first time, a big question usually arises while trying to develop quality management system processes for design and development:
When does research end and when does development begin?
For those of you seasoned (and not so seasoned) medtech pros: when put more bluntly, when do I need to initiate design controls?
Design Controls Initiation
Before I dive into the good stuff, let me just address the question with a very simple answer: design controls are initiated when an organization feels confident that a new concept is technically feasible and could be developed into a safe and effective product within the constraints of the company.
In a nutshell, design controls as prescribed by 21 CFR 820.30 (Subpart C) are applied to a medical device development project when the design is – excuse my super simple language – “good enough” to be controlled. The company defines “good enough”. Put simply, I consider there to be two distinctions and overarching philosophies in product development.
- Prove to yourself that the concept is feasible and works and is worth pursing (Feasibility, Proof of Concept, Etc.)
- Prove to the FDA that this feasible concept is safe and effective (Design Controls per 21 CFR 820.30).
The ‘R’ in R&D directly addresses proving to yourself that a certain core technology, function, or new feature “works”. At this point, a company’s focus is on rapid prototyping and iterations to test various embodiments of the IP or idea that catalyzed the new project in the first place. In fact, if you read the FDA’s 1997 Design Controls guidance, it reads:
“In some cases, the marketing staff, who maintain close contact with customers and users, determine a need for a new product, or enhancements to an existing product. Alternatively, the idea for a new product may evolve out of a research or clinical activity. In any case, the result is a concept document specifying some of the desired characteristics of the new product.”
The research and activities that go into demonstrating that the product idea is feasible/ proven is often an initial stage in a company design and development SOP (Proof of Concept Stage/ Phase, Feasibility Stage/ Phase, etc.). This involves investigating more than just the technical viability of a prospective product and includes analysis of the business case, market, and reimbursement potential. In parallel, technical information is gathered through testing and research in order to refine the product concept and ultimately develop prototypes. The end result is a meeting of the minds at a company with a thumbs up – or thumbs down – indicating that the product is sufficiently de-risked and feasible to enable full scale development, the ‘D’.
Development of a feasible idea is what’s really regulated under Design Controls. In fact, one way to look at is that the ‘R’ is the “rehearsal” and the ‘D’ is the “showtime.” Prototypes developed during ‘rehearsal’ won’t cut it – they haven’t been sufficiently vetted! The FDA summarizes it well:
“[…] manufacturers should avoid falling into the trap of equating the prototype design with a finished product design. Prototypes at this stage lack safety features and ancillary functions necessary for a finished product, and are developed under conditions which preclude adequate consideration of product variability due to manufacturing.
You’ve researched, tested and prototyped the concept – now its time to fully develop the concept into a tangible product developed in accordance with the FDA’s requirements for showing that the design was progressed through a series of stages characterized by increased scrutiny and control. Only when this rigorous quality management system process is applied to the development of a medical device can a manufacturer claim that a device is safe and effective.
Design control begins with the development of design inputs. Doesn’t it make sense then that everything that precedes design inputs is the ‘R’ in R&D? The design inputs represent an attempt by the manufacturer to specify how the product must look, feel, perform and function , made possible by the due diligence performed in the ‘R’ phase of R&D.
The philosophy of ‘R’ vs. ‘D’ – turned into practical tips.
Here are some tips on how to turn the philosophy described herein regarding R vs. D into some practical actions for medical device manufacturers.
1) Distinguish between ‘R’ and ‘D’ in your product development process.
A clear demarcation between research and development within your product development process is useful for deciding the extent of deliverables and activities and tasks associated with either stage. Some companies call this a ‘Feasibility’ or ‘Proof of Concept’ or ‘Concept Confirmation’ stage. Again, the major key in this stage of product development is to overcome a burden of proof that a product should be developed and commercialized.
The only aspects of this stage that should be included in a design history file (DHF) should be those assumptions that necessary for developing design inputs. For example: if the product involves a brand new core technology, it may be useful to include some of the core technology “proof that it works” within the DHF – but only to the extent that it is not already captured in downstream design input and design verification documentation already!
Speaking of the DHF….
2) Ensure that the design history file captures the ‘D’ and only the most critical of the ‘R’.
The DHF represents the records of the design control process. Thus, the DHF should be primarily comprised of ‘D’ stage documents including design planning, design inputs, design outputs, design verification/ validation, design transfer and design changes- as well as design reviews at various points to confirm that the design is progressing appropriately.
3) Burden of proof in ‘R’ is to the company; Burden of proof in ‘D’ is to the regulators.
This is not 100% true because obviously demonstrating that a core technology is safe and feasible will often yield outputs that regulators need to see in order to approve products. However, in general, proof of concept / feasibility stages should convince internal company stakeholders that there is an idea worth pursuing. Refining that idea into an actual safe and effective product through the design control process is the proof that regulators are looking for through examination of submission data and the design history file.
Research and development is not one big bucket of activities that have the same level of activity and rigor, but rather, distinct phases of the product development process that are governed by different needs. The research needed to convince a company to pursue a product may come from marketing, internal stakeholders or from external market pressures. Once the decision is made that a product is feasible, utilizing a quality management system process for design controls is crucial for ensuring that design mistakes and potential safety issues are caught earlier in the process. The data during development becomes the DHF that is reviewed by regulators in order to make decisions on marketing clearance/ approval.
If you’re still unsure about when ‘R’ ends and ‘D’ begins, we would love to help!
Medgineering is a medical device consulting firm specializing in risk management, design controls and DHF, quality management system work and FDA remediation. Visit www.medgineering.com for additional information.