Case for Quality - AdvaMed · PDF fileCase for Quality Library ... area that you are in. ... Quality Functional Deployment model, QFD 2. Requirements Cascade 3

Case for Quality Library - Appendix B - Site navigation and instructions

If you see this icon by the AdvaMed logo on the page, that means this slide contains interactive, live links

Text In Blue If you see text in bold blue on the page, that means this text is an interactive link that will take you to anotherplace in the library.

If your computer mouse turns into a white pointed hand when you pass over a text or image on the page, that means that text or image has an interactive link that will take you to another place in the library.

If you see this pointer finger icon by a text or image on the page, clicking on the pointer finger icon willtake you to the related interactive link in another place in the library.

Clicking on the YELLOW arrow icon will take you BACK to the last page you were on.

Clicking on the GREEN arrow icon will take you to the NEXT sequencial page from where you were on.

Clicking on the BLUE arrow icon will take you to the MAIN Table of Contents page in the current libraryarea that you are in.

Clicking on the BLUE house icon will take you to the MAIN library page for the Case of Quality where youcan access other library areas.home

Clicking on the PURPLE location marker icon will take you to the Table of Contents (TOC)for the particular company presentation that you are in.

back

next

main

toc

Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts I

nto

CtQ

s

Category B:How Do You translate Customer

Requirements into CtQs?

Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts I

nto

CtQ

s

home

next

main

Category B:How Do You translate Customer

Requirements into CtQs?

http://advamed.org/res.download/759

nextbackmain home

Table of ContentsPractices to Translate Customer Requirements into CtQs

1. Quality Functional Deployment model, QFD2. Requirements Cascade3. Key Tools4. Risk Management5. Quality Tree model6. Design and Process CTQs7. CTQ Cascade model8. CTQ Flow-down model9. Managing Requirements10. Critical Parameter Management Process Model11. Critical Quality Attributes (CQA) Model

1. Quality Functional Deployment model, QFD2. Requirements Cascade3. Key Tools4. Risk Management5. Quality Tree model6. Design and Process CTQs7. CTQ Cascade model8. CTQ Flow-down model9. Managing Requirements10. Critical Parameter Management Process Model11. Critical Quality Attributes (CQA) Model

Practices to Translate Customer Requirements into CtQs


Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

Quality Function DeploymentModel

Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

home

next

back

main

toc

Quality Function DeploymentModel


BCompany:

nextbackmain hometoc

Tool/Method/Example Summary Tool/Example Name: Quality Function Deployment (QFD)

General Description:Process to translate Qualitative Customer requirements into Weighted &Prioritized Quantitative Design, Engineering and Manufacturing requirements

Glossary of terms: House of Quality – Common QFD matrix used to translate Qualitative

Customer Requirements into Quantitative Design requirements VOC – Voice of Customer

Typical Uses: New Product Development

Relevant FDA Regulations: 21 C.F.R. §§ 820.30(c) Design Input, (d) Design Output

Medical Devices 10,001 + employees Global

Tool/Example Name: Quality Function Deployment (QFD)

General Description:Process to translate Qualitative Customer requirements into Weighted &Prioritized Quantitative Design, Engineering and Manufacturing requirements

Glossary of terms: House of Quality – Common QFD matrix used to translate Qualitative

Customer Requirements into Quantitative Design requirements VOC – Voice of Customer

Typical Uses: New Product Development

Relevant FDA Regulations: 21 C.F.R. §§ 820.30(c) Design Input, (d) Design Output



FCompany:


Tool/Method/Example Summary Tool/Example Name: House of Quality (HofQ)

General Description:HofQ is a template used to Cascade requirements when utilizing QFD, including: Customer requirements vs. Design requirements Design requirements vs. Engineering design Engineering design vs. Product Characteristics Product characteristics vs. Manufacturing operations requirements Manufacturing operations requirements vs. Production/ controls

Glossary of terms: QFD, Quality Function Deployment, links the needs of the customer with product design,

manufacturing and service functions. Typical Uses:

HofQ is utilized during the design process to better understand 'true' customer needs and what‘value’ means from the customer's perspective

Relevant FDA Regulations: Applicable throughout design controls (21 C.F.R. § 820.30)

Hospital & Health Care 10,001 + employees Global

Tool/Example Name: House of Quality (HofQ)

General Description:HofQ is a template used to Cascade requirements when utilizing QFD, including: Customer requirements vs. Design requirements Design requirements vs. Engineering design Engineering design vs. Product Characteristics Product characteristics vs. Manufacturing operations requirements Manufacturing operations requirements vs. Production/ controls

Glossary of terms: QFD, Quality Function Deployment, links the needs of the customer with product design,

manufacturing and service functions. Typical Uses:

HofQ is utilized during the design process to better understand 'true' customer needs and what‘value’ means from the customer's perspective

Relevant FDA Regulations: Applicable throughout design controls (21 C.F.R. § 820.30)



ACompany: Medical Devices 1001-5000 employees North America


Tool/Method/Example Summary Tool/Example Name: QFD

General Description:QFD is used to translate customer needs (whats) into system parameters (hows)and to identify those system parameters which have the biggest impact oncustomer satisfaction

Glossary of terms: House of Quality: Also called QFD [Quality Function Deployment] is tool used

to systematically translate customer requirements into quantitativeparameters that can be used to develop a concept and select a productsolution.

Typical Uses: QFD is used translate needs statements into measureable requirements

Relevant FDA Regulations: Applicable to (21 C.F.R. § 820.30)

Tool/Example Name: QFD

General Description:QFD is used to translate customer needs (whats) into system parameters (hows)and to identify those system parameters which have the biggest impact oncustomer satisfaction

Glossary of terms: House of Quality: Also called QFD [Quality Function Deployment] is tool used

to systematically translate customer requirements into quantitativeparameters that can be used to develop a concept and select a productsolution.

Typical Uses: QFD is used translate needs statements into measureable requirements

Relevant FDA Regulations: Applicable to (21 C.F.R. § 820.30)









Core Process Using Quality FunctionDeployment

• House of Quality used to Cascade requirements– Customer requirements vs. Design requirements– Design requirements vs. Engineering design– Engineering design vs. Product Characteristics– Product characteristics vs. Manufacturing

operations requirements– Manufacturing operations requirements vs.

Production/ controls• Consider the “Other Voices” – Business & Process

• House of Quality used to Cascade requirements– Customer requirements vs. Design requirements– Design requirements vs. Engineering design– Engineering design vs. Product Characteristics– Product characteristics vs. Manufacturing

operations requirements– Manufacturing operations requirements vs.

Production/ controls• Consider the “Other Voices” – Business & Process





ROOF

Strong Synergy ++Synergy + Strong 9 Competition Key:

Weak Conflict X Medium 3

High Conflict XX Weak 1Machine

1Machine

2Machine

3

Customers' Desired Outcomes

Primary Want 1 2 3 4 5

ExcellentCompany Party 9 9 3 9 9 5.0

3 3 3 9 9 3.0

1 9 3 9 1.0

9 3 9 1.0

CTQ Priority 55 18 45 9 30 90 72 0 0 0 0 0 0 0 0 0 0 319% Importance 17 6 14 3 9 28 23

PREDICTIVE

MEASURES

=

CTQ'S

HOW IMPORTANT

Direction ofImprovement

CORRELATION ROOM 4

# cu

stom

er c

ompl

aint

s

# en

trée

optio

ns#

cu fe

et p

er p

erso

n

RELATIONSHIP KEY

tast

e ra

ting

nois

e le

vel

Impo

rtanc

e

taste rating

Secondary Want even

t sat

isfa

ctio

n sc

ore

Star

ratin

g of

faci

lty

# entrée options

event satisfaction score

# customer complaints

# cu feet per person

Star rating of facilty

QFD HOUSE 1

good foodgood music

able to converse withoutscreamingeasy to mingle around

noise level

ROOF: CORRELATION

CUSTOMER PERCEPTION:SATISFACTION LEVEL

PREDICTIVE MEASURES =CTQ'S

QFD Tool example

ROOF

Strong Synergy ++Synergy + Strong 9 Competition Key:

Weak Conflict X Medium 3

High Conflict XX Weak 1Machine

1Machine

2Machine

3

Customers' Desired Outcomes

Primary Want 1 2 3 4 5

ExcellentCompany Party 9 9 3 9 9 5.0

3 3 3 9 9 3.0

1 9 3 9 1.0

9 3 9 1.0

CTQ Priority 55 18 45 9 30 90 72 0 0 0 0 0 0 0 0 0 0 319% Importance 17 6 14 3 9 28 23

PREDICTIVE

MEASURES

=

CTQ'S

HOW IMPORTANT

Direction ofImprovement

CORRELATION ROOM 4

# cu

stom

er c

ompl

aint

s

# en

trée

optio

ns#

cu fe

et p

er p

erso

n

RELATIONSHIP KEY

tast

e ra

ting

nois

e le

vel

Impo

rtanc

e

taste rating

Secondary Want even

t sat

isfa

ctio

n sc

ore

Star

ratin

g of

faci

lty

# entrée options

event satisfaction score

# customer complaints

# cu feet per person

Star rating of facilty

QFD HOUSE 1

good foodgood music

able to converse withoutscreamingeasy to mingle around

noise level

ROOF: CORRELATION

CUSTOMER PERCEPTION:SATISFACTION LEVEL

PREDICTIVE MEASURES =CTQ'S



The 5 Core Principles1. Product design is simply the successive refinement of requirements

All specifications are simply means to communicate requirements to the next level ofhierarchy through an unbroken cascade.

2. Nothing is more important to success than managing requirementsRequirements must be complete, concise, unambiguous, measurable and wholly transparentto all participants. They are the basis for schedules, reviews, testing, metrics, regulatorysubmissions, customer satisfaction, and continuous improvement.

3. Mitigations and residual risks are requirements that must be managedAll failure modes, including use error & foreseeable misuse, must be traced to hazardoussituations & all hazardous situations must be traced to potential harms.

4. Evidence of conformance must identify the design configurationPrototypes are cost, not progress. Learning is progress. Configurations used for verificationmust include assessments showing the configuration tested is equivalent to the design beingreleased.

5. Program Management relies on standard work and objective metrics# +Δ requirements, # +Δ protocols w/GR&R, # +Δ protocols run, % +Δ req verified, % +Δprocesses w/capability estimated, % +Δ processes w/capability verified. Chronological hourssince last formal customer feedback, fever chart $$ vs plan.



1. Product design is simply the successive refinement of requirementsAll specifications are simply means to communicate requirements to the next level ofhierarchy through an unbroken cascade.

2. Nothing is more important to success than managing requirementsRequirements must be complete, concise, unambiguous, measurable and wholly transparentto all participants. They are the basis for schedules, reviews, testing, metrics, regulatorysubmissions, customer satisfaction, and continuous improvement.

3. Mitigations and residual risks are requirements that must be managedAll failure modes, including use error & foreseeable misuse, must be traced to hazardoussituations & all hazardous situations must be traced to potential harms.

4. Evidence of conformance must identify the design configurationPrototypes are cost, not progress. Learning is progress. Configurations used for verificationmust include assessments showing the configuration tested is equivalent to the design beingreleased.

5. Program Management relies on standard work and objective metrics# +Δ requirements, # +Δ protocols w/GR&R, # +Δ protocols run, % +Δ req verified, % +Δprocesses w/capability estimated, % +Δ processes w/capability verified. Chronological hourssince last formal customer feedback, fever chart $$ vs plan.

You are currently viewing a featured section of AdvaMed's Case for Quality Library. To view AdvaMed's Case for Quality website, click HERE. To view the full slide deck of AdvaMed's Design Control recommendations, click HERE.



www.advamed.org/caseforquality

http://advamed.org/res/925/case-for-quality-company-presentations

Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

Requirements Cascade

Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

home

next

back

main

toc




Tool/Method/Example Summary Tool/Example Name: Requirements Cascade DHF/DMR

General Description:A graphical representation of a requirements cascade where parent requirementsare translated to child requirements via a transfer function.

Glossary of terms: Transfer Function is a mathematical representation of the relationship

between a set of design factors and output variables. Typical Uses: Translates the sensitivities of the top-level requirement to lower-level

requirements through a relationship equation Relevant FDA Regulations: Applicable throughout the design control (21 C.F.R. § 820.30) and linkages to

DHF (21 C.F.R. § 820.30(j))

Tool/Example Name: Requirements Cascade DHF/DMR

General Description:A graphical representation of a requirements cascade where parent requirementsare translated to child requirements via a transfer function.

Glossary of terms: Transfer Function is a mathematical representation of the relationship

between a set of design factors and output variables. Typical Uses: Translates the sensitivities of the top-level requirement to lower-level

requirements through a relationship equation Relevant FDA Regulations: Applicable throughout the design control (21 C.F.R. § 820.30) and linkages to

DHF (21 C.F.R. § 820.30(j))



Requirement

REQ 1 REQ 2 REQ 3

f( )y

x

Requirements CascadeACompany: Medical Devices

1001-5000 employees North America


REQ 1-1 REQ 1-2 REQ 1-3 REQ 1-4

REQ 1-1 REQ 1-2 REQ 1-3

REQ 1-1 REQ 1-2

3 elements of a cascade• Parent requirement [y]• Child requirement [x]• Transfer function [f()]

• Y Requirements guide conceptdevelopment and selection

• Concepts dictate transfer functions• Design worksheets determine XsFrom “The METHOD,” multiple copyrights

2006-2013







Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

Key Tools

Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

home

next

back

main

toc


Key tools used By Phase

Concept– VOC

gathering

Definition• Monte Carlo

Models• KJ VOC

Analysis• QFD / HoQ• Concept Eval

& Selection -Pugh Matrix

Development• Critical Parameter

Management• Design /

Application FMEA• Measurement

Systems Analysis(MSA)

• Screening /Advanced DOE’s

• Transfer Functions: Defined, Ranked& Prioritized

• Monte Carlosimulations

Qualification• Critical Parameter

Management• Design Capability

Assessment• Mfg Capability

Assessment

BCompany: Medical Devices 10,001 + employees Global


Concept– VOC

gathering

Definition• Monte Carlo

Models• KJ VOC

Analysis• QFD / HoQ• Concept Eval

& Selection -Pugh Matrix

Development• Critical Parameter

Management• Design /

Application FMEA• Measurement

Systems Analysis(MSA)

• Screening /Advanced DOE’s

• Transfer Functions: Defined, Ranked& Prioritized

• Monte Carlosimulations

Qualification• Critical Parameter

Management• Design Capability

Assessment• Mfg Capability

Assessment



Company:


Tool/Method/Example Summary Tool/Example Name: Focus Groups, Feature Ranking, Online Survey, Feature Value-

Cost Analysis, Spider Maps, Conjoint Analysis

General Description:Tools to establish customer requirements and to rank them based on value points, costetc.

Glossary of terms: Importance scaling, sorting and scaling, forced ranking, feature trade-off Scatter

Plot, “Must Haves”, “Jewels”, “Peanuts”, “Black Hole” Typical Uses:

Tools to determine and analyze customer requirements (“VOC”) Relevant FDA Regulations:

N/A Relevant FDA Regulations:

These tie the VOC and marketing requirements to design inputs, including part riskclassification determination of CtQ in the design controls process.

I Medical Devices 10,001 + employees Global

Tool/Example Name: Focus Groups, Feature Ranking, Online Survey, Feature Value-Cost Analysis, Spider Maps, Conjoint Analysis

General Description:Tools to establish customer requirements and to rank them based on value points, costetc.

Glossary of terms: Importance scaling, sorting and scaling, forced ranking, feature trade-off Scatter

Plot, “Must Haves”, “Jewels”, “Peanuts”, “Black Hole” Typical Uses:

Tools to determine and analyze customer requirements (“VOC”) Relevant FDA Regulations:

N/A Relevant FDA Regulations:

These tie the VOC and marketing requirements to design inputs, including part riskclassification determination of CtQ in the design controls process.



ICompany:

nextbackmain home


toc

How Do You Translate CustomerRequirements into CtQs?

Through The Use of State of the Art Tools for Each DfX Pillar &A Phased Discipline approach to Design and Product Realization

DF CE = Customer Experience

DF R = Reliability

DF M = Manufacturability

DF S = Serviceability

DF C = Cost

DF “X”DF “X”



Company:


Tool/Method/Example Summary Tool/Example Name: Part Risk Classification, DFMEA, PFMEA, Pareto Analysis, Cause-and-Effect

Diagram, 2x5xWhy

General Description:Tools to classify parts as part of design outputs, identify critical to quality characteristics (CtQs),flow down of CtQs for part and process to manufacturing and suppliers via design transfer.

Glossary of terms: Product attributes critical to quality (parts, modules, features), Common failure modes, Top

risks of product failure Typical Uses:

To identify critical to quality features or process characteristics that are critical determinantsof quality, failure modes, risk management and risk mitigation

Relevant FDA Regulations: 21 C.F.R. §§ 820.30, 820.50, 820.70

Relevant FDA Regulations: These tie to design for customer experience, manufacturability, reliability, serviceability, and

value engineering. They also tie to process and product quality assurance, design innovationand software quality assurance.

I Medical Devices 10,001 + employees Global

Tool/Example Name: Part Risk Classification, DFMEA, PFMEA, Pareto Analysis, Cause-and-EffectDiagram, 2x5xWhy

General Description:Tools to classify parts as part of design outputs, identify critical to quality characteristics (CtQs),flow down of CtQs for part and process to manufacturing and suppliers via design transfer.

Glossary of terms: Product attributes critical to quality (parts, modules, features), Common failure modes, Top

risks of product failure Typical Uses:

To identify critical to quality features or process characteristics that are critical determinantsof quality, failure modes, risk management and risk mitigation

Relevant FDA Regulations: 21 C.F.R. §§ 820.30, 820.50, 820.70

Relevant FDA Regulations: These tie to design for customer experience, manufacturability, reliability, serviceability, and

value engineering. They also tie to process and product quality assurance, design innovationand software quality assurance.



ICompany:

nextbackmain home


toc

Supplier assurance – how to work with suppliers & flow downof CtQ’s

Process assurance – how to do process control and processvalidation of automated test systems

Product assurance – how to conduct post market surveillanceand enhance the customer experience

Design cycle and innovation assurance – how to control designprocesses (e.g., CMMI)

Software validation & assurance – how to ensure product SWis robust and bug-free

A Five Pillar QA Program Supports GoodDesign and DfX Practices

Supplier assurance – how to work with suppliers & flow downof CtQ’s

Process assurance – how to do process control and processvalidation of automated test systems

Product assurance – how to conduct post market surveillanceand enhance the customer experience

Design cycle and innovation assurance – how to control designprocesses (e.g., CMMI)

Software validation & assurance – how to ensure product SWis robust and bug-free



Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

Risk Management

Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

home

next

back

main

toc


Tool/Method/Example Summary Tool/Example Name: Risk Management, CTQ monitoring program

General Description:CTQ monitor program to predict and prevent unfavorable behavior

Glossary of terms: Risk Management, Fault Tree Analysis, Design FMEA, Use FMEA, Critical To

Quality, In Process Monitoring, Response Flow

Typical Uses: Patient Safety, Process Control, predict and prevent unfavorable behavior

Relevant FDA Regulations: 21 C.F.R. §§ 820.30 & 820.70

CCompany: Medical Devices 10,001 + employees Global


Tool/Example Name: Risk Management, CTQ monitoring program

General Description:CTQ monitor program to predict and prevent unfavorable behavior

Glossary of terms: Risk Management, Fault Tree Analysis, Design FMEA, Use FMEA, Critical To

Quality, In Process Monitoring, Response Flow

Typical Uses: Patient Safety, Process Control, predict and prevent unfavorable behavior

Relevant FDA Regulations: 21 C.F.R. §§ 820.30 & 820.70





Risk Management is integrated into designand development processas part of the PLCP.

Product Hazard Analysis uses:• Fault Tree Analysis• Design FMEA• Use FMEA

Level 3 represents unacceptable harm andlevel 0,1, & 2 drive verification & validationconfidence statements which must be met.

Risk Management is integrated into designand development processas part of the PLCP.

Product Hazard Analysis uses:• Fault Tree Analysis• Design FMEA• Use FMEA

Level 3 represents unacceptable harm andlevel 0,1, & 2 drive verification & validationconfidence statements which must be met.

Product Risk Index Matrix

Occ

urre

nce

of H

arm

5 1 2 2 3 3

4 1 1 2 3 3

3 0 1 2 2 3

2 0 0 1 2 2

1 0 0 0 1 2

1 2 3 4 5

Severity of Harm



What? CTQ is a potentially vulnerable failure mode or process that iskey to assure patient safety

Why? CTQ monitor program is recommended to predict and preventunfavorable behavior

CTQ Screening:- Failure Mode with high severity and RI (RI: 2 /Severity: 4/5) –link to Risk Managementprocesses.

- Vulnerable process - High Scrap, NCEPs and/or Complaints- Potentially affects patient safety

1. Perform a failuremode screeningaccording to the CTQdecision flow andcreate a preliminarylist

Options



CTQ Screening:- Failure Mode with high severity and RI (RI: 2 /Severity: 4/5) –link to Risk Managementprocesses.

- Vulnerable process - High Scrap, NCEPs and/or Complaints- Potentially affects patient safety

1. Perform a failuremode screeningaccording to the CTQdecision flow andcreate a preliminarylist

2. Discard and selectCTQs with properrationale

3. Propose andanalyze ideas formaking more robusteach selected CTQ

4. Create animplementation planfor the ideas selected

5. Follow up andupdate plan

IPM

Response Flow



• Translates User Needs into Design Inputso Assess Riskso Initiate Market Specificationo Develop product specifications

• Develop prototypes

o Identify possible design concepts, Test methods, designprototypes, evaluate prototypes

• Develop equipment & processo Assess process technology, develop and execute

equipment strategy• Define Supply Chaino Define supplier plan, define concept builds, establish

supply chain strategy

Translating User Needs into Design InputsCCompany: Medical Devices

10,001 + employees Global


• Translates User Needs into Design Inputso Assess Riskso Initiate Market Specification

oDevelop product specifications

•o Identify possible design concepts, Test methods, design

prototypes, evaluate prototypes• Develop equipment & processo Assess process technology, develop and execute

equipment strategy• Define Supply Chaino Define supplier plan, define concept builds, establish

supply chain strategy You are currently viewing a featured section of AdvaMed's Case for Quality Library. To view AdvaMed's Case for Quality website, click HERE. To view the full slide deck of AdvaMed's Design Control recommendations, click HERE.



http://advamed.org/res/925/case-for-quality-company-presentations

www.advamed.org/caseforquality

Tool/Method/Example Summary Tool/Example Name: Active Requirements Management (RM) Tool

General Description:This tool is utilized to ensure that the various (inputs) requirements are translatedinto predictive, measureable performance values. These outputs can be tracked onthe CTQ Scorecard. The Risk Flow Down model is utilized to ensure that risksassociated with a specific requirement have the appropriate mitigations.

Glossary of terms (specific to this tool/example): None unique

Typical Uses: These tools can be utilized during the design process to ensure requirements

are adequately translated to quantify performance values.

Relevant FDA Regulations: 21 C.F.R. §§ 820.30 design controls & FDA Preamble – comment 72.


Company:Fnextbackmain hometoc

Tool/Example Name: Active Requirements Management (RM) Tool

General Description:This tool is utilized to ensure that the various (inputs) requirements are translatedinto predictive, measureable performance values. These outputs can be tracked onthe CTQ Scorecard. The Risk Flow Down model is utilized to ensure that risksassociated with a specific requirement have the appropriate mitigations.

Glossary of terms (specific to this tool/example): None unique

Typical Uses: These tools can be utilized during the design process to ensure requirements

are adequately translated to quantify performance values.

Relevant FDA Regulations: 21 C.F.R. §§ 820.30 design controls & FDA Preamble – comment 72.



• Active RM allows flowing up process capability andpredicted performance to customer requirements

Market Req.

Product Req. + “Why” +Performance

Assembly Req. + Performance

Component Req. +Performance

Process Req + “Why” + Capability

Requirements Management (RM) Tools to Support PDP

Market Req.

Product Req.

Assembly Req.

Component Req.

Process Req.



Market Req.

Product Req. + “Why” +Performance

Assembly Req. + Performance

Component Req. +Performance

Process Req + “Why” + Capability

Market Req.

Product Req.

Assembly Req.

Component Req.

Process Req.

CTQ Flow down/up:What, Why, How, Cost?

CTQ Flow down/up:What









• FMEA table generated

• Requirement at each level of the flow down can have a failure

mode.

– Causes and Effects linked

– Transfer Functions

• Risks are connected to requirements and to each other

Risk Flow Down• FMEA table generated

• Requirement at each level of the flow down can have a failure

mode.

– Causes and Effects linked

– Transfer Functions

• Risks are connected to requirements and to each other



Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

Quality Tree Model

Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

home

next

back

main

toc


Company:

nextbackmain hometocD Medical Devices


Tool/Method/Example Summary Tool/Example Name: Quality Tree

General Description:Shows the flow down of customer requirements into Functional requirements, Design,and Process requirements in a hierarchical graphic format to help identify CTQs.

Glossary Of Terms: Functional Requirements – description or metrics that the device’s needs to perform

(functional output needs). Design Requirements – description or metrics that the device’s design to meet the functional

requirements. Process Requirements -description or metrics relative to how the device’s is manufactured to

meet the design and functional requirements.

Typical Uses: To help identify the flow down of requirements into critical design or process

outputs needed. CTQ’s and important aspects of the product are typically shownon this chart.

Relevant FDA Regulations : 21 C.F.R. §§ 820.30 (b), (c), (d), (e), and (f)

Tool/Example Name: Quality Tree

General Description:Shows the flow down of customer requirements into Functional requirements, Design,and Process requirements in a hierarchical graphic format to help identify CTQs.

Glossary Of Terms: Functional Requirements – description or metrics that the device’s needs to perform

(functional output needs). Design Requirements – description or metrics that the device’s design to meet the functional

requirements. Process Requirements -description or metrics relative to how the device’s is manufactured to

meet the design and functional requirements.

Typical Uses: To help identify the flow down of requirements into critical design or process

outputs needed. CTQ’s and important aspects of the product are typically shownon this chart.

Relevant FDA Regulations : 21 C.F.R. §§ 820.30 (b), (c), (d), (e), and (f)



Company:



Developing the Quality Tree

• Quality Tree should be developed by the team

• The project customer requirements, Engineering documentation andknowledge of the team are key inputs

• In sequence the following activities should occur Critical Customer Requirements are identified by the end of the Feasibility Functional Requirements are identified by the end of the Feasibility Design Requirements are identified in the Development Stage or earlier Process Requirements are identified in the Development Stage or earlier

• Quality Tree should be developed by the team

• The project customer requirements, Engineering documentation andknowledge of the team are key inputs

• In sequence the following activities should occur Critical Customer Requirements are identified by the end of the Feasibility Functional Requirements are identified by the end of the Feasibility Design Requirements are identified in the Development Stage or earlier Process Requirements are identified in the Development Stage or earlier



Company:



Quality Tree Format



Company:



Selecting Your CTQs• Once the full Quality Tree has been completed, the

team needs to make intelligent choices on whichCharacteristics should be labeled CTQ's.

• The Bottom line is assurance of quality as it relatesto Critical Customer Requirement(s)

• American Society for Quality (ASQ) definesassurance of quality as the planned and systematicactivities implemented in a quality system so thatquality requirements for a product or service will befulfilled.

• Once the full Quality Tree has been completed, theteam needs to make intelligent choices on whichCharacteristics should be labeled CTQ's.

• The Bottom line is assurance of quality as it relatesto Critical Customer Requirement(s)

• American Society for Quality (ASQ) definesassurance of quality as the planned and systematicactivities implemented in a quality system so thatquality requirements for a product or service will befulfilled.



Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

Design and Process CTQs

Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

home

next

back

main

toc


Company:

nextbackmain hometocE Medical Devices

1001-5000 employees Global

Design and Process CTQs

CustomerRequirements

Critical toCustomer

(CtC)Drivers Critical to

Design (CtD)Critical to

Process (CtP)

VOC

MarketAssessment

KOL

ReviewProcedures/Cases

Prototype

product

QFD

ProductDevelopment

Product Use

QFD

DesignSpecification

Design RiskAssessment

DesignVerification

ProcessRequirements

Process RiskAssessment

ProcessValidation

Process

VOC

MarketAssessment

KOL

ReviewProcedures/Cases

Prototype

product

QFD

ProductDevelopment

Product Use

QFD

DesignSpecification

Design RiskAssessment

DesignVerification

ProcessRequirements

Process RiskAssessment

ProcessValidation

CtQ

Key

Activ

ities



Company:



Translating Customer Requirements to CtQs:• The many customer requirements are distilled down to

the Critical to Customer (CtC) – VoC, KOL, MarketAssessments, product review

• The CtC are translated down to Key Drivers by the use ofDFQ and ranking

• Drivers are translated into Product Requirements• Product Requirements are translated into Product

Specifications (Critical to Design – CtD).• CtD are approved by the Project Approval Board and

reviewed at Gates 2 through 4 and During Design Reviews• CtD will drive the process development and the Critical to

Process (CtP) parameters to assure product design

• The many customer requirements are distilled down tothe Critical to Customer (CtC) – VoC, KOL, MarketAssessments, product review

• The CtC are translated down to Key Drivers by the use ofDFQ and ranking

• Drivers are translated into Product Requirements• Product Requirements are translated into Product

Specifications (Critical to Design – CtD).• CtD are approved by the Project Approval Board and

reviewed at Gates 2 through 4 and During Design Reviews• CtD will drive the process development and the Critical to

Process (CtP) parameters to assure product design



Company:



CtQ in Product Development



Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

CTQ Cascade Model

Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

home

next

back

main

toc


Company:

nextbackmain hometocF Hospital & Health Care


CTQ Cascade

User Issues

Customer Needs and Requirements

User Issues

Functions to Meet User Needs

Concepts to Meet the Functions

User Needs/Requirements



Company:



CTQ Cascade

Product RequirementsMeasureable Performance

Requirements


Architecture: Subcomponents?

Attributes/ Properties/ Specifications

Measureable PerformanceRequirements



Company:



CTQ Cascade

Process Requirements

Product Requirements



Critical Process Variables,Requirements

Equipment Requirements,Sources of Variation

Raw Material Properties,Specifications , Sources of Variation



Company:



CTQ Cascade




Risk Mitigation Strategies and Controls


Risks

Mitigations, Controls

Improve Chances of Success Proactively



Company:



CTQ Cascade



Verification and Validation

Specifications, Critical Testing





Company:



CTQ Cascade



Verification and Validation





Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

CTQ Flowdown Model

Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

home

next

back

main

toc


Company:

nextbackmain hometocG Medical Devices

5001-10,000 employees Global

Voice ofCustomer

Function

Parts

Critical to Quality (CTQ) Flow down

Parts

Dimensions

Capability

Match Capability Vs. Goal

Launch



Company:

nextbackmain hometocG Medical Devices

5001-10,000 employees Global

CTQ Flow DownMarketing RegulatoryRepairs

Therapy system shall deliver the prescribed negative pressure to the wound site whenpowered onVoice of the Customer

(User needs)

Technical Requirements Therapy unit shall maintain pressure within ±x mmHg of target pressureAccess Risk levelfrom Top Down*and Usability *perspective

ClinicalPost MarketSurveillance

ComplaintsFocus Groups

48

Technical Requirements

CTQ Characteristics

Part Drawings – (Link toDFMEA for Risk)

Therapy unit shall maintain pressure within ±x mmHg of target pressure

Therapy Unit, Canister, Dressing (e.g. drape), System Interactions (sub-assembly)

Drape adhesive propertiesPump Flow ratePump Diaphragm characteristics

Canister – Unit interface

Access Risk levelfrom Top Down*and Usability *perspective

Link to DFMECAfor Risk

Carry over toPFMEA

Link CTQs identified to Risk

•Top Down: evaluates the potential risks from the system level perspective, before finalizing the design. Mitigations from Top down should be used as an input tothe design.

• Usability risk analysis: evaluates the potential hazards related to the use or misuse of the product.



Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

Managing Requirements

Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

home

next

back

main

toc


Company:


Managing Requirements

ComponentReqs

H Medical Devices 10,001 + employees Global

Design ReviewTrace to Design

Outputs

ProcessPlanning

Matrix



Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

Critical Parameter ManagementProcess Model

Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

home

next

back

main

toc

Critical Parameter ManagementProcess Model


Company:

nextbackmain hometocK Medical Devices


MaterialSpecifications

ProductSpecifications

UFMEADFMEA

DesignQualifications& Validations

CustomerInput

PDP Process

Process Development

FeedbackLoops

InputCPM Process Model – Value Stream

CustomerComplaints

InspectionResults

TestingResults

Non-conformance

Reporting

ScrapReporting

PFMEAProcess &Assembly

Specifications

ProcessQualifications& Validations

Control & Monitoring

Risk Identification& Mitigation

Process Development

Critical Parameters are identified in Design and translatedthroughout the QMS and ultimately is used to focus control &monitoring and prioritized feedback loops.



Company:



CPM Process Model – Identification Targets - QE



UFMEADFMEA


CustomerInput

Each Quality Engineer hasbeen retrospectivelyidentifying theirCritical Parameters for theirassigned products

CustomerComplaints

InspectionResults

TestingResults

Non-conformance

Reporting

ScrapReporting

PFMEAProcess &Assembly

Specifications


Starting with complaints andworking to the left, criticalsafety, performance andcompliance parameters

identified

The identified Critical Parameters arethen:

1. Assessed for capability2. Mitigations defined3. Improvement plans created4. Controls & Monitors implemented



Company:



CPM Process Model – Identification Targets - DA

Customer



PFMEA

UFMEADFMEA

Process &Assembly


ProcessQualifications

CustomerInput

In a Prospective manner –the development team, ledby DA, identifies their CriticalParameters and rigorouslytests them.

CustomerComplaints

InspectionResults

TestingResults

Non-conformance

Reporting

ScrapReporting

PFMEAAssemblySpecifications

Qualifications& Validations

Starting with Customer Inputand working to the right,

critical safety, performanceand compliance parameters

identifiedThe identified Critical Parameters are then:1. Assessed for capability2. Risk assessed & Mitigations defined3. Specifications created4. Designs made robust5. Tested and optimized6. Deployed to commercialization

Transfer Function

CPyoutput = f(xinput)



Company:



CTQ’s (How Determined)• Review of field complaints for high severity items

impacting the patient.• Consulted with Product Surveillance for assistance with

interpreting complaints.• Cross-functional review of what constitutes high severity

complaints.

• Review of field complaints for high severity itemsimpacting the patient.

• Consulted with Product Surveillance for assistance withinterpreting complaints.

• Cross-functional review of what constitutes high severitycomplaints.

CustomerComplaints



InspectionResults

TestingResults

Non-conformance

Reporting

ScrapReporting

PFMEA

UFMEADFMEA

Process &Assembly

Specifications



CustomerInput



Company:



Example Product Deployment of CPM

• Critical Product and Process Parameters Capability and state of control

• Gap analysis Where we are now Improvement plans to achieve desired “State of Control”

• CPM will involve a reoccurring review of thecritical parameter and controls withadjustments made as necessary.

• Critical Product and Process Parameters Capability and state of control

• Gap analysis Where we are now Improvement plans to achieve desired “State of Control”

• CPM will involve a reoccurring review of thecritical parameter and controls withadjustments made as necessary.



Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

Critical Quality Attributes Model

Prac

tices

To T

rans

late

Cus

tom

erRe

quire

men

ts In

to C

tQs

home

next

back

main

toc


Company:

nextbackmain hometocJ Medical Devices


Identification of Critical QualityAttributes

1. Design Controls process (per QSR): Ensures thatDesign Inputs (including DI acceptance criteria) aredeveloped that comprehensively meet therequirements of the Intended Use and User Needs.

2. Risk Management process (per ISO 14971): ReviewsDesign Inputs to ensure that sufficient Design Inputshave been identified to address identified Hazards.

3. Design Controls process (per QSR): Ensures thatDesign Outputs (including quality attributes) aredeveloped that comprehensively meet therequirements of the Design Inputs.

1. Design Controls process (per QSR): Ensures thatDesign Inputs (including DI acceptance criteria) aredeveloped that comprehensively meet therequirements of the Intended Use and User Needs.

2. Risk Management process (per ISO 14971): ReviewsDesign Inputs to ensure that sufficient Design Inputshave been identified to address identified Hazards.

3. Design Controls process (per QSR): Ensures thatDesign Outputs (including quality attributes) aredeveloped that comprehensively meet therequirements of the Design Inputs.

Figure 2: Risk Management focus

MedicalDevice

Hazards



Company:



Critical Quality Attributes Critical Quality Attributes are product design specifications and are documented in

the DHF as:1. Design input acceptance criteria (in the Design I/O document) and/or2. Design output specifications/tolerances (in the DMR)

Intended Use/User Need

DI # DesignInput

DI Acceptance criteria DI Acceptancecriteria Justification

DO # Design Outputs(PN/ Feature)

1 1-1 xxxx Design Input Acceptancecriteria 1-1

xxxx xxxx 1-1-1 Design PN/Feature 1-1-1

1-1-2 Design PN/Feature 1-1-2

Design Spec/tolerance 1-1-1-1Design Spec/tolerance 1-1-1-2Design Spec/tolerance 1-1-1-3

Design Spec/tolerance 1-1-2-1Design Spec/tolerance 1-1-2-2Design Spec/tolerance 1-1-2-3

DMR (Design)1. Product drawings2. Label text & artwork3. Material specs4. Software code5. Product test specs

“Refinement of Design Input”(Product performance criteria)

Design Outputs

DIO Document



Company:



Design Input Acceptance Criteria Design Output Specs/Tolerances

Implant fixation force Implant actuation

sound Drill heat

(temperature) Drill metal debris rate

1. Implant thickness, Device color2. Product identification text on device3. Implant material4. Software platform/revision5. Drill torque, Voltage output, Sterility

Assurance Level, Device weight,Video resolution

1. Implant tip radius, Internalcomponent position

2. Warning text on device and IFU3. Internal component material4. Software code for voltage

calibration5. Internal power supply test

voltage, Software checksum,Implant hardness

Example Critical Quality Attributes

Design Outputs

Implant fixation force Implant actuation

sound Drill heat

(temperature) Drill metal debris rate

1. Implant thickness, Device color2. Product identification text on device3. Implant material4. Software platform/revision5. Drill torque, Voltage output, Sterility

Assurance Level, Device weight,Video resolution

1. Implant tip radius, Internalcomponent position

2. Warning text on device and IFU3. Internal component material4. Software code for voltage

calibration5. Internal power supply test

voltage, Software checksum,Implant hardness

DMR (Design)1. Product drawings2. Label text & artwork3. Material specs4. Software code5. Product test specs

Manufacturing has visibility of allproduct design specs in the DMR

DIO Document



Company:



Critical Quality Attributes– Critical CQA’s are critical product design specifications

• Critical CQA’s are product design specifications where being in-spec is considered “critical”for product quality

– Note: Expectation is that manufactured product will meet all product designspecifications (quality attributes) in the DMR, whether designated as “critical” or not• In accordance with QSR Subpart G, Production and Process Controls• The designation of a product design specification as “critical” merely conveys that the consequences of

being out of spec are severe, so additional focus is prudent during manufacturing, verification, etc.

– Critical CQA’s are critical product design specifications• Critical CQA’s are product design specifications where being in-spec is considered “critical”

for product quality

– Note: Expectation is that manufactured product will meet all product designspecifications (quality attributes) in the DMR, whether designated as “critical” or not• In accordance with QSR Subpart G, Production and Process Controls• The designation of a product design specification as “critical” merely conveys that the consequences of

being out of spec are severe, so additional focus is prudent during manufacturing, verification, etc.

Verify (Inspect) or Validate

QualityAttributes

CriticalQuality

Attributes

Verify (Inspect) or Validatewith more rigor



Company:



Identification and Classification of Critical CQA’s



Company:



Identify Critical CQAsFor a given quality attribute, if a significant departure from design toleranceis predicted to result in unacceptable product quality (i.e., major customerdissatisfaction and/or unacceptable risk), that quality attribute is identifiedas a CQA.

Note: For most quality attributes, a large, unlimited departure from designtolerance inevitably results in unacceptable product quality , but this doesnot imply that most quality attributes are CQA’s. The main purpose of CQAidentification is to highlight those quality attributes for which a slightdeparture from design tolerance has unacceptable consequences.

For a given quality attribute, if a significant departure from design toleranceis predicted to result in unacceptable product quality (i.e., major customerdissatisfaction and/or unacceptable risk), that quality attribute is identifiedas a CQA.

Note: For most quality attributes, a large, unlimited departure from designtolerance inevitably results in unacceptable product quality , but this doesnot imply that most quality attributes are CQA’s. The main purpose of CQAidentification is to highlight those quality attributes for which a slightdeparture from design tolerance has unacceptable consequences.



Company:



Identify Critical CQAsFor CQA identification purposes, the concept of a “significant departure”from design tolerance is interpreted as follows:

• For continuous quality attributes with linear design tolerance, asignificant departure from design tolerance should be defined asdeparture up to a factor of 2 from design tolerance (i.e., up to a 100%departure from design tolerance).

Reference: Juran, J.M. and Godfrey, A. B. (Eds.), Juran’s Quality Handbook, 5th edition,New York: McGraw-Hill (1999), Section 22.6-22.7

For CQA identification purposes, the concept of a “significant departure”from design tolerance is interpreted as follows:

• For continuous quality attributes with linear design tolerance, asignificant departure from design tolerance should be defined asdeparture up to a factor of 2 from design tolerance (i.e., up to a 100%departure from design tolerance).

Reference: Juran, J.M. and Godfrey, A. B. (Eds.), Juran’s Quality Handbook, 5th edition,New York: McGraw-Hill (1999), Section 22.6-22.7

5.30

5.20 5.40

5.10 5.50Significant departure from

Design tolerance(for CQA identification)

Design tolerance

Figure: Significant departure from a linear design tolerance

Length



Company:



Identify Critical CQAs• For discrete quality attributes, any departure from design tolerance may

be considered a significant departure, but project team personnel shouldsubjectively decide what constitutes a significant departure.

Example: For an implant, the color specification “green” might beconsidered a CQA if manufacturing that implant as any color other thangreen (e.g., “blue” or “red”) is predicted to result in unacceptable productquality.

• For discrete quality attributes, any departure from design tolerance maybe considered a significant departure, but project team personnel shouldsubjectively decide what constitutes a significant departure.

Example: For an implant, the color specification “green” might beconsidered a CQA if manufacturing that implant as any color other thangreen (e.g., “blue” or “red”) is predicted to result in unacceptable productquality.



Company:

backmain hometocJ Medical Devices


Identify Critical CQAsFor CQA identification purposes, the consequence of a significant departure fromdesign tolerance (i.e., the failure effect) is determined using any of the followingmethods or combination of methods:1. Judgment of engineering, quality assurance, clinical affairs, and/or marketing

personnel on the project team2. Inspection of Risk Management File info3. Inspection and analysis of field data, test data, theoretical models, NC/CAPA

information, standards, regulations, and/or literature for similar products

For CQA identification purposes, the consequence of a significant departure fromdesign tolerance (i.e., the failure effect) is determined using any of the followingmethods or combination of methods:1. Judgment of engineering, quality assurance, clinical affairs, and/or marketing

personnel on the project team2. Inspection of Risk Management File info3. Inspection and analysis of field data, test data, theoretical models, NC/CAPA

information, standards, regulations, and/or literature for similar products



Documents

Case for Quality - AdvaMed · PDF fileCase for Quality Library ... area that you are in. ... Quality Functional Deployment model, QFD 2. Requirements Cascade 3