The History of Design Controls

Transcription

1 OCTOBER 5, 2016 The History of Design Controls P R E S E N T E D B Y : Joseph P. Sener, P.E. V.P. Quality, Device Engineering Hospira, a Pfizer Company

2 Agenda The evolution of Engineering to System Engineering Looking beyond 21CFR Cutting through the clutter of regulations to common sense and proper engineering judgment Assess system robustness through Peer Review 2

3 The evolution of Engineering The first engineer was Imhotep 2500 B.C.E. His clarity and science was so strong he was made a demi-god after his death Engine er is French for one who operates an engine (of warfare). The definition dates from Civil Engineering is the second oldest engineering profession after military engineering to distinguish non-military from military. 3

4 The evolution of Engineering Traditionally we had Mechanicals or Electricals Now there are more than 22 different engineering disciplines without dilution The Project Engineer would have a primary discipline but would need to know just enough The evolution is to Systems Engineering The Licensed Professional Engineer is not discipline specific Aerospace Agricultural Architectural Biomedical Biomechanical Civil Construction Environmental Industrial Computer Electrical Electronics Eng. Technology Engineering Mgmt Mechanical Mechatronics Project Mgmt Robotics Software Structural Systems Forensic 4

5 Professional Engineering License The licensing of engineers began in Wyoming in 1907 to protect the public from untrained individuals practicing engineering and surveying. Today, all states and territories license professional engineers to protect the public health, safety, and welfare. While every licensed professional engineer has expertise in certain areas, such as civil, electrical, or mechanical, they are licensed as a professional engineer rather than a professional civil engineer or a professional electrical engineer. Every professional engineer has an ethical obligation to practice only in their areas of competence. 5

6 6 NASA Systems Engineering Handbook

7 Systems Engineering Hierarchy 7 NASA Systems Engineering Handbook

8 vs ISO CFR (a) General (b) Design and Development Planning (c) Design Input (d) Design Output (e) Design Review (f) Design Verification (g) Design Validation (h) Design Transfer (i) Design Changes (j) Design History File ANSI/ASQC Q General Design and Development Planning Organizational and technical interfaces Design Input Design Output Design Review Design Verification Design Validation Design Changes 8

9 But what do they say? Be plan full Describe the interfaces between the organizational elements Update the plans as they evolve Make sure the input requirements (DI) are appropriate and address intended use (and foreseeable misuse) Make sure design outputs (DO) allow an adequate evaluation of conformance to DI Have formal documented reviews of the design with the right people there Verify DO to DI Validate using production equivalents to assure conformance to user needs and intended uses Assure designs are translated into production specs Create a DHF 9

10 is a Structure Be plan full Describe the interfaces between the organizational elements Update the plans as they evolve Make sure the input requirements (DI) are appropriate and address intended use (and foreseeable misuse) Make sure design outputs (DO) allow an adequate evaluation of conformance to DI Have formal documented reviews of the design with the right people there Verify DO to DI Validate using production equivalent to assure conformance to user needs and intended uses Assure designs are translated into production specs Create a DHF 10

11 Design Assumptions what do the FDA and our customers assume? Good, sound engineering judgment is used Requirements are complete and unambiguous Proper engineering disciplines are engaged in the design process Our engineers are experts in the design of our product Engineers are motivated to do good work Our designs are robust! But HOW IS THAT TESTED? 11

12 Testing our Assumptions We hire good people Assure they have a track record of good engineering judgment We perform good robust (and challenging) peer reviews We use the peer review feedback for personnel feedback The FDA will periodically visit and test design controls but typically that investigator is not a design control expert When there is a big problem, we get to see a national expert 12

13 A Case Study How would we characterize the design of a pump set using flow restriction? The first answer we got was a sample size of 3! a) Get a minimum sample of 20 b) Perform a test of flow restriction using a constant orifice (pump cassette) c) Using the data from b perform a test for normality d) Determine appropriate confidence window for sample size (99/95) e) Using an appropriate tool, perform a Monte Carlo analysis to determine appropriate sample size at the confidence window in d above f) Perform the associated testing and determine the flow value mean and standard deviation Notice, we wont find the highlighted terms anywhere in ! 13

14 Peer Review In the end, we should not assume that any one designer or design team has all the answers We can t cover all the contingencies in procedures Conduct in-process peer reviews with appropriate subject matter experts to assess validity, quality, and consistency of the evolving system with the stakeholder objectives and with previous analyses. 1 Peer reviews are designed to assure the best minds in the organization agree with the technical approach (we use chief engineers) They are not necessarily fun. INCOSE. (2015). Systems Engineering Handbook, A guide for systems lifecycle processes and activities. (D. D. Walden, Ed.) San Diego, CA: Wiley. 14

15 Conclusion 21CFR is a structure for our Quality Management System It CANNOT be the definition of how we perform good engineering It is our job as engineers to deliver good science and good engineering judgment and the regulations cannot promise that Peer reviews help us assure we have the very best design possible 15

16 Thanks for your time and attention Any Questions? 16