# Presentation: 199171

## Overview of the Quality System Regulation for Medical Devices

**Jan Welch**
**Office of Compliance**
**April 21, 2004**

## Background

**Effective June 1, 1997, replacing the 1978 GMP for medical devices**
**Preamble to the 1997 regulation - VERY Important**
**Requirements are not prescriptive**
**Provides framework of basic requirements for manufacturers to follow**

## Bottom line ...It’s your Quality System!

**A manufacturer must develop a QS commensurate with:**
** ****risk presented by the device**

## Bottom line ...It’s your Quality System!

**A manufacturer must develop a QS commensurate with:**
**complexity of device and manufacturing processes**
**size and complexity of manufacturing facility**

## Quality Paradigms

**Quality Control -****Test/inspect components, finished products vs approved specifications**** **
**Quality Assurance -**** ****Manufacture quality into products**

## Quality Paradigms

**Quality System -****Design and manufacture quality into products, and includes specific CAPA requirements**

## Quality System

**Quality System**

**Design Controls**

**Material****Controls**

**Records,**** Documents, &**
**Change Controls**

**Equipment & **
**Facility Controls**

**Production & **
**Process Controls**

**Corrective &**
**Preventive**
**Actions**

**Management**

## “Establish” 21CFR 820.3(k)

**D****efine**
**D****ocument**
**Implement ****(D****o****)**

## Management Controls

**Appoint a management representative**
**Conduct management reviews**
**Ultimately responsible for the entire Quality System****	****	****	****	****	****	****	**

## Design Controls

**Class II**
**Class III**
**Class I per 21CFR 820.30(a)(2)**

## Design Control Impact

**Fact: On June 1, 1997 the Quality System Regulation became effective **

**Notes:**
Here's the first fact we're going to have to remember...on June 1, 1997 the Quality system Regulation became effective. Included in the QS Reg. is Subpart C "Design Controls"...21 CFR Part 820.30(a) - (j).

Now, since the term "Product" is defined in 820.3(r) to include other things besides "finished devices", here's where I made my first assumption...basically, I'm considering "Old Product" to refer to finished devices that were marketed prior to June 1, 1997 that today would be subject to the design controls spelled out in 820.30. 

## Design Controls

**Design Controls DO apply to products being reused**
**Must back engineer the devices design**
**Must design the process to meet device specifications**

## Types of “Product” 

**Types of “Product” **

**Medical Devices that were marketed prior to June 1, 1997 and ****have not**** changed**
**Medical Devices that were marketed prior to June 1, 1997 and ****have**** changed **

**Notes:**
Bearing that assumption in mind, we can refine "Old Product" even further...we need to do this because there are different considerations depending upon which "type" of "Old Product" we're talking about.

There are three categories of "Old Product" we are going to discuss...1. Devices that were on the market prior to June 1, 1997 and have not changed (remember, I consider this to mean no changes to the device, its packaging or its labeling); 2. Devices that were marketed prior to June 1, 1997 and have changed since that date; and finally, devices that were in some stage of development prior to and after June 1, 1997.  

## Types of “Product”

**Class II, Class III and applicable Class I medical devices that were     in development prior to ****and**** after****June 1, 1997**

## Obligations regarding medical devices that were marketed prior to June 1, 1997 and have changed?

**“****When changes are made to new or existing designs, the design controls of §820.30 must be followed to ensure that the changes are appropriate and that the device will continue to perform as intended.”**
**Preamble p. 52616, response to comment 64**

**Notes:**
Let's look at the second type of "Old Product" we are going to discuss...applicable pre-June 1, 1997 designed devices that were changed after the effective date of the Quality System Regulation.   

Again, the preamble sheds light on this topic...basically, changes made to devices subject to design controls must be made in accordance with design controls.  For example, if you decide to change an intended use of your device or add a new intended use, you will need a plan, and apply essentially all of the design control requirements of 820.30...new inputs will require new outputs, verification, validation, review etc.

## Anything else?

**“****Procedures must ensure that after the design requirements are established and approved, changes to the design, both pre-production and post-production are also reviewed, validated (or verified where appropriate), and approved.”**

**Notes:**
Here are a couple of additional statements on the subject of design change that appear within the preamble...read the bullet items.

## Anything else?

**“****The records of these changes create a history of the evolution of the design, which can be invaluable for failure investigation and for facilitating the design of future similar products.”                **
**Preamble p. 52621, response to comment 87****   **

## How much is enough?

**“****The evaluation and documentation should be in direct proportion to the significance of the change.”**
**Preamble p. 52621, response to comment 87**

**Notes:**
You may be thinking, "O.K., Rob, I know I have to apply design controls to every design change, but every design change is not the same with respect to its potential impact on the safety or effectiveness of the device, is there anything in the preamble that addresses this issue?"  

Just as you should design your quality system with the significance of your device in mind, you should apply the same good judgement when determining to what degree you apply the requirements of 820.30...For example, if you build cars and make a change to the antenna, you may not need the same degree of verification and validation activities as you would need to verify and validate a change to the car's braking system. Let's assume the antenna malfunctions, (this assumes the radio's on to begin with and not the CD player) the chances of the driver and passengers missing a public service announcement that could save their lives are probably pretty remote compared to the chances of the driver and passengers being seriously injured or killed if the braking system were to malfunction. Are there hazards and risks associated with both systems?...yes...Will an identical degree of design controls need to be applied for each?...most likely not.      

## Application of Design Controls

**RESEARCH**

**DEVELOPMENT**

- concept

- feasibility

- inputs

- plans

- outputs

- verification

- validation

- review

- change

- transfer

**Application of Design Controls**

**Notes:**
Let's look at this another way, using a tool first introduced (I believe) by Kim Trautman...these are basically an adulteration of Kim's "Hump" diagrams.

The x-axis represents time, so what we have here is a representation of a complete R&D project from concept to transfer. 

What we see is, design controls can begin at a number of points along the project timeline. A better way to think about it may be, design controls begin once and may be "re-applied" at a number of points along the project timeline. This is because  projects may run research and development activities concurrently.  You already may be developing certain units, modules or components of your device long before you're finished researching others. Using concurrent engineering, this means inputs may be developed at a number of points pretty far into that "Development" hump.  

You've already got a system for controlling changes, so theoretically, design control begins at the apex of the "Research" hump and the beginning of the "Development" hump.  But, if you think of change as a global control mechanism, you see that once you begin to solidify your inputs, design controls apply.  What may happen as the diagram illustrates is that different design control elements may come on line at different times and I'm not saying that what is illustrated is the only way to do things...For example, you may choose to establish a Design and Development Plan prior to solidifying your inputs...if this is the case the elements of 820.30(b) may be the first elements of design controls to be applied.    

This is not an easy subject to convey...

## Design Reviews

- Purpose
- Participants
- Timing

**Notes:**
Another important aspect that will be inspected in the Design Control subsystem is Design review...

With respect to "Purpose", we're going to ensure that Design Reviews provide feedback to designers on existing or emerging problems, we're going to confirm that reviews assess the progress of the design and we're also going to make sure reviews confirm that the design is ready to move to the next phase of development.  Basically, we're  gonna ensure that the proper channels of communication remain open and active. The term "active" includes ensuring action items resulting from Design Reviews are addressed.

Regarding "Participants", we will confirm that representatives of all functions concerned with the design stage being reviewed as well as an individual without direct responsibility for the design stage being reviewed and any specialists needed participate. 

Finally, Design Review "Timing"...we will confirm that Design Reviews are planned and conducted at appropriate stages of the device's design development.  For example, upon completion of a design stage or phase, or after completion of project milestones. 

## Design Verification

**Design *****Verification*****...**
**Is the product specifications being met  and can I prove it?**

**Notes:**
I'm gonna briefly touch on a couple of sets of definitions that historically have caused a bit of confusion...the first being Design Verification vs. Design Validation...
Let me preface this by saying that each one of these "Nutshell" definitions includes "...and can I prove it."  That's because all of the formal definitions of these terms from 820.3 of the QS Reg. include the term "objective evidence"...and we all know that objective evidence is "...information which can be proved true, based on facts obtained through observation, measurement, test, or other means."...the proof. 
Let's get back to Design Verification and Design Validation.  Design Verification is basically did my outputs meet my inputs. Does this necessarily mean that the device will meet the needs of the user for its intended use?  No...if you make a poor assumption early in your design project, this poor assumption may pollute the entire design process.  Let me give you an example, I can make a baseball bat out of aluminum.  I can verify the aluminum met specs., I can verify that the dimensions are dead on, and I can verify that a batter can hit baseballs with the bat.  I made the product right because it meets all of the specs. I established for it.  But what if my intended customers plan to use the bat in the major leagues and I didn't recognize that fact during discussions of inputs?  The major leagues require bats to be made of wood.  My aluminum bat would be useless to my intended customers.  I did not make the right product because it won't meet my customers' needs. 
Design Validation is the final step in confirming that the product will meet user needs for its intended purpose...Verification = outputs met inputs...Validation = confirmation the inputs were correct and comprehensive to begin with and your design process translated them appropriately to specifications.  

## Design Validation

**Design *****Validation*****...**
**	****Is the product meeting user needs and intended uses for all specifications, even after remanufacturing and can I prove it?**

## Design Validation vs. Process Validation

***Design***** Validation****...**
**Is the product meeting user needs and intended uses and can I prove it?**

**Notes:**
The next set of definitions I'd like to discuss is Design Validation and Process Validation.

As we just learned on the  previous slide, Design Validation is "Did I make the right product and can I prove it?"

Process Validation on the other hand, is establishing by objective evidence that a process consistently produces a result or product meeting its predetermined specifications.  That "predetermined specifications" thing is key...if you didn't capture user needs accurately and you went ahead and developed specifications, you could, theoretically, develop and validate a process that consistently produces a product to those inaccurate specifications.  So, you could do a real good job of validating a process which produces a product that doesn't meet user needs. 

The key here is Design Validation is making sure you've made the right product and Process Validation is making sure that you can make the right product (hopefully the right product anyway) again and again.  

## Design Validation vs. Process Validation

***Process***** Validation****...**
**	****Does the process consistently produce a result or product meeting predetermined specifications and can I prove it?**** **

## Define and Document Design Change Procedures

- Design
- Change
- Procedures

**Notes:**
The exception in this case is Design Change Procedures...we expect all manufacturers (subject to the design control requirements of the QS Reg.) to, at a minimum, establish and maintain Design Change Procedures.  The time to think about how a design change will be handled is not when you need to make one...it's kinda like "Complaint Handling Procedures", the time to start thinking about how to handle a complaint is not when the phone rings.  These procedures should be well thought out, developed and documented before you need them.

## Design Controls Helpful Hints...

**Understand the jargon **
**Use the results of Risk Analysis and management tools throughout the design control process**

**Notes:**
Here's my helpful hints section of this presentation...my first helpful hint is try to speak the same language.  There are a number of resources you can tap to get an idea of what FDA means when we say things like design input, output, review, validation, etc.  Those are all defined in the QS Reg. itself.  We also have put together a Glossary of Computerized System and Software Development Terminology so if you're not sure if your definition of Alpha or Beta testing is consistent with what FDA thinks Alpha and Beta testing is, you can look it up.  

The second helpful hint is use the results of risk analysis throughout your quality system, use it to tell yourself how much is enough for purchasing controls or acceptance activities, use it to prioritize failure investigations, etc...

And last but not least, be prepared to discuss what you've done to address Y2K (if applicable).  Are your devices ready? Is the software used to control your processes and quality system ready? 

## Production and Process Controls

**1. ****CAPA**** Indicators**
**2. Device Risk**
**3. Process Risk**

- CLEANING

- DECONTAMINATION

**TESTING**

- STERILIZATION

**Notes:**
Using the manufacturing of sterile plastic blood tubing sets or catheters as an example, the QSIT model for the selection of a process for inspection would look like this... 

There is a prioritized list of considerations to be used to select the process as illustrated in the middle of this slide.  From this prioritized list, we will target one particular process.  It may be a process requiring validation, it may not.  That means we will not necessarily review process validation during each and every QSIT inspection.  

Also, the investigators are advised not to select the same process every time they inspect your facility.  

## Plus...

-  Purchasing
-  Acceptance
-  Buildings & Equip.
-  Calibration
-  Personnel
-  Statistical Tech.’s
-  Others

**Notes:**
From those reviews, the investigator will note certain raw materials, equipment, and instruments and exercise a number  of other elements of your quality system using this information as a "springboard" or "linkage"...The investigator will look at purchasing controls and acceptance activities, maintenance, calibration, a whole bunch of other stuff based on that one process.  

## Automated Processes

- Requirements
- Validation Protocol
- Validation Activities
- Validation Results
- Change Controls

**Notes:**
Remember during my review of Design Controls I mentioned that the software validation of computer systems used in production or other elements of the quality system would be exercised in P&PC?  Well, here's the kind of stuff we'll be lookin' for regarding these types of systems...

## Is The Process Operating Within Specified Limits?

**If NO, then review...**
- Nonconforming Product Controls
- Resulting CAPA’s
- Equipment Adj., Cal. & Maint.
- Validation (where required)

**Notes:**
Something that may concern some people is a fear that if the investigator sees records that document the process is not or was not operating in accordance with the device master record, will he automatically assume the process is not in a state of control?  

The answer is "No", not automatically...we will determine if "YOU" had recognized the problem and whether "YOU" have taken the appropriate actions to control any nonconforming product, correct the problem and minimize the potential that the event will recur. We'll also look at a number of other potential causes of the nonconformances.  Now, if you never recognized the problem to begin with, that's a horse of a different color...

## Production andProcess Controls

**Validate processes if results cannot be fully verified by subsequent inspection and test**
**Validate software used in manufacturing and in the quality system**
**Control and monitor manufacturing processes**

## Corrective andPreventive Action

**Collect and analyze data to identify nonconforming product and other quality problems**
**Investigate cause**
**Identify and implement corrective and preventive action**

## Corrective and Preventive Action

**Verify or validate effectiveness**
**Communicate information about quality problems to staff**
**Forward information for management review**

## Have the CAPA requirements been “established”?

-     	**Defined**
**   ****	****Documented **
**   ****	****Implemented**

- §820.3(k)

**Notes:**
We call this principle the "Establish" rule.  The quality system regulation uses the term "establish" quite a bit...its even defined within the regulation and means "define, document (in writing or electronically), and implement."  The Guide basically instructs the investigator to employ an inspectional approach which reflects the "establish" rule...Has the firm defined the necessary Design Control procedures? Has the firm documented these procedures? And finally, by sampling records, plans, etc. and interviewing employees, determine have the procedures have been "implemented"?  You, as an engineer will likely be involved in all of these discussions...

Let me conclude my discussion of this topic by sharing a little advice...

## Staying informed ... 

**CAPA**

**Management**
**   ****Review**

**Audits**

**Staying informed ...**

## Who is responsible...

**“****FDA emphasizes that it is always **management’s** responsibility to ensure that all nonconformity issues are handled appropriately.”**
***Comment 165***

## Correction vs. Corrective Action

***“******Correction”*** refers to repair, rework, or adjustment and relates to the disposition of an **existing** nonconformity
***“******Corrective action”*** relates to the  elimination of the **causes** of an existing nonconformity

## “Healthy” CAPA subsystem procedures include provisions to ...

- 1.	Identify and correct **existing** nonconforming product or other quality problems (“Correction”);
- 2.	Identify and eliminate the **causes** of existing nonconforming product and other quality problems (“Corrective Action”); and,

## “Healthy” CAPA subsystem procedures include provisions to ...

**3.****	****Identify and eliminate the causes of **potential** nonconforming product and other quality problems (“Preventive Action”) **

## Quality Data Sources

**Feedback**

**External **
**Feedback**

**Quality Data Sources**

**CAPA**

## Internal Data Sources

- Acceptance Activities (Inspection and Test Data)
**component, in-process and final test**
**scrap/yield**

## Internal Data Sources

- Nonconforming product
**scrap, rework, UAI**
- Process monitoring
**process control data, control charts, SPC**

## Internal Data Sources

- Equipment monitoring
**calibration, maintenance**
- Device History Records
- Change Control Records

## Internal Data Sources

- Internal Audits
- 3rd Party Audits** **
**ISO**
**FDA**
- Supplier Audits
- Management Review Results

## External Data Sources

- Complaints & MDR’s
- Servicing
**warranty, non-warranty**
**field service reports**
**returns**
- Recalls
- Legal Claims

## Seeking Quality Data

- Solicit feedback to support continuous improvement
***Customer Feedback***
***Employee Feedback***
***ISO 9001:2000***
***Principles of Quality Management***

## CAPA Program

*PRO*** active**
**vs.**
*RE*** active**

## CAPA Program

**Single or multiple CAPA systems**
**internal audits**
**supplier audits**
**inspection and test data**
**nonconforming product**
**complaints and servicing**
***ALL***** must meet 820.100**

## CAPA Program

**Identify data sources**
**Document the problem**
**Establish a priority system**
**consider impact / risks and select items with major impact**
**proceed to items with less impact**

## CAPA Program

**Analyze the problem**
**root cause analysis**
**Develop an action plan**
**consider impact and need for...**
**short term corrective action**
**long term corrective action**

## CAPA Program

**Verification and Validation**
**analysis of data may lead to more than one solution, assure solution is appropriate**
**Implementation**
**tracking for on-time completion**

## CAPA Program

- Documentation and follow-up
**corrective action effective**
**adverse effect on product **
**records**
- Communicate changes
**to those directly responsible**
**management review**

## Close the loop...

**PLAN    DO    CHECK    ACT     **

## For Further Information

_**General**_
**www.fda.gov/cdrh/index.html**
_**Quality System Regulation**_
**www.fda.gov/cdrh/fr1007ap.pdf**
_**QSIT Guide**_
**www.fda.gov/ora/inspect_ref/****igs/qsit/qsitguide.pdf**