# Presentation: 199127

## Overview of the Quality System Regulation for Medical Devices

**Tonya A. Wilbon**
**Office of In Vitro Diagnostic Device Evaluation and Safety**
**April 19, 2006**

## Outline

**Background**
**Documents used**
**Definitions**
**7 Major Subsystems approach to a Quality System**

## 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**

## Documents Used:

**Preamble to the final rule published 1996 in the Federal Register**
**21 CFR 820**
**“****Quality System Information for Certain Premarket Application Reviews: Guidance for Industry and FDA Staff”**
**QSIT Guide**
**Compliance Program (7383.001) **

## Definitions:

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

## Definitions cont.:

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

## 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**

## 7 Subsystems of a Quality System

**7 Subsystems of a** **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)**
**(*****On June 1, 1997, the Quality System Regulation became effective)***

## Design Controls

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

## 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.

## 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 Inputs

**Design Inputs**

**Design Input means the physical and performance requirements of a device that are used as a basis for device design**
**Ensure requirements are appropriate and address intended use of a device and the needs of the user**

**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 Output

**Design output means the results of a design effort at each phase and the end of the total design effort**
**Consists of the device, its packaging and labeling, and the device master record**

## 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*****...**
**Are 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

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

## Design Transfer

**Ensure the device design is correctly translated into production specifications**

## 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

**Develop processes that are adequate to produce devices that meet specifications and validate those processes if results cannot be fully verified by subsequent inspection and test**
**Monitor and control the manufacturing processes**

## 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...

## 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...

## 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*
**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**
**Quality Audit Reports**
*Internal Audits *
*3**rd** Party Audits (ISO, FDA)*
*Management Review Results*
*Supplier Audits*

## 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

**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**

## Thank you...........

**Jan Welch**
**GMP Expert, Office of Compliance**
**                                         **